TDoc list

Tdoc List

2018-01-19 16:43

Agenda	Topic	TDoc	Title	Source	Type	For	Avail	Treated	Decision	Wdrn	Replaced-by	Replaces
1	Opening of the meeting (Monday 9:00)
2	Reminder
2.1	IPR declaration
2.2	Statement of antitrust compliance
2.3	Responsible IT behavior
2.4	Additional reminders
3	Approval of the Agenda	R3‑180002	RAN3-AH-1801 meeting Agenda	Chairman	agenda		Yes	No	available	No
4	Approval of the minutes from previous meetings
5	Documents for immediate consideration
6	Organizational topics
7	General, protocol principles and issues
8	Incoming LSs
8.1	New Incoming LSs	R3‑180015	Reply LS on PRB grid in the NR	3GPP RAN1, Huawei	LS in		Yes	No	available	No
		R3‑180017	Reply LS on supported features by 5GC for E-UTRA connected to 5G CN	3GPP RAN2, Nokia	LS in		Yes	No	available	No
		R3‑180018	LS reply on UE RF related parameters, capabilities and features for NR	3GPP RAN4, NTT Docomo	LS in		Yes	No	available	No
		R3‑180019	LS on interworking mechanisms between 5G System and legacy RATs	3GPP RAN, NEC	LS in		Yes	No	available	No
		R3‑180020	LS on Removal of 'over LTE' limitation from Mission Critical Specifications	3GPP SA1, Politie	LS in		Yes	No	available	No
		R3‑180021	Reply LS to CN node selection for LTE features when E-UTRA is connected to 5G CN	3GPP SA2, Nokia	LS in		Yes	No	available	No
		R3‑180023	Reply LS on cooperation on Network Slicing	3GPP SA5, Huawei	LS in		Yes	No	available	No
		R3‑180024	Liaison response to 3GPP RAN (reply to RP-172097/oLS-3GPPRAN)	ITU-T Study Group 15, Microsemi	LS in		Yes	No	available	No
8.2	LSin received during the meeting
8.3	Left over LSs / pending actions
9	Corrections to Rel-14 or earlier releases
9.1	3G
9.2	LTE
10	NR Radio Access Technology (RAN1-led) WI
10.1	QoS
10.1.1	Content QoS Flow Level Parameters	R3‑180070	Correction of QoS Profile for TS 38.413	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal 1: there is no impact on RAN3 protocol for the Averaging Window for AMBR. Proposal 2: correct the flow Averaging Window in TS 38.413 to make sure that an Averaging Window value can also be signaled over NGAP in the case of GBR flows using standardized QoS Characteristics. Proposal 3: correct the Priority Level in TS 38.413 to make sure that a Priority Level value can also be signaled over NGAP in the case of GBR flows using standardized (or pre-configured) QoS characteristics. Proposal 4: add the Maximum Packet Loss Rate QoS parameter to the QoS Profile at the GBR QoS Flow Information level. Proposal 5: add the Maximum Data Burst Volume to the 5G QoS Characteristics.	available	No
		R3‑180071	Correction of QoS Profile for TS 38.423	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	No	available	No
		R3‑180072	Correction of Delay Critical GBR in TS 38.413	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal 1: agree that Delay critical GBR flows are rather to be seen as a sub-type or attribute of GBR flows. Proposal 2: signal the Delay critical attribute directly as an information element of the GBR QoS Flow Information IE. Proposal 3: agree the Text Proposal below to introduce a Delay critical attribute for a GBR flow.	available	No
		R3‑180073	Correction of Delay Critical GBR in TS 38.423	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	No	available	No
		R3‑180193	TP for 38.413 on QoS parameter update	CATT	pCR		Yes	NoProposal 1: It is proposed to include Priority Level as optional in the QoS flow level parameter Proposal 2: It is proposed to include Averaging window as optional in the QoS flow level parameter Proposal 3: It is proposed to include Maximum Data Burst Volume as optional in the QoS flow level parameter Proposal 4: It is proposed to include Maximum Data Burst Volume as optional in the Non-standardised QoS Flow Descriptor	available	No
		R3‑180194	TP for 38.423 on QoS parameter update	CATT	pCR		Yes	No	available	No
		R3‑180195	TP for 38.413 on status of Notification Control	CATT	pCR		Yes	NoProposal 1: Define the status of notification control information (e.g. not fulfilled and fulfilled)	available	No
		R3‑180196	Discussion on Notification Control	CATT	discussion		Yes	NoProposal 1: For Dual connectivity case, if a QoS flow is configured with notification control, the SN node may send S-node Modification Notify message to the MN node. Proposal 2: For CU-DU case, if a QoS flow is configured with notification control, the DU may send UE Context Modification Notify message to the CU. Proposal 3: It’s proposed to agree the corresponding TP for stage2 and Stage3 TS in [2], [3] and [4].	available	No
		R3‑180197	TP for 38.423 on Notification Control	CATT	pCR		Yes	No	available	No
		R3‑180200	TP for 38.470 on Notification Control	CATT	draftCR		Yes	No	available	No
		R3‑180202	TP for 38.473 on Notification Control	CATT	draftCR		Yes	No	available	No
		R3‑180265	Control of non GBR QoS flows	Huawei	pCR		Yes	NoProposal 1 Change the QoS Flow Level QoS Parameters IE to be mandatory in the PDU Session Setup Request Transfer IE.	available	No
		R3‑180288	Update of QoS parameters	Huawei	pCR		Yes	NoProposal 1: Add Maximum Packet Loss Rate into QoS flow Level QoS parameters IE. Proposal 2: Add Maximum Data Burst Volume into Non-standardised QoS Flow Descriptor IE. Proposal 3: Add Maximum Data Burst Volume into QoS flow Level QoS parameters IE.	available	No
		R3‑180298	TP on QoS flow level parameters for TS 38.413	NEC	pCR	Decision	Yes	NoProposal 1: RAN3 to discuss whether to support the Notification Control feature, or send an LS to SA2 requesting further clarification on the use and/or definition of the Notification Control feature. Proposal 2: The Notification Control parameter should apply to GBR QoS flows. Proposal 3: The Maximum Packet Loss Rate UL and DL should be included in the QoS flow level parameters. Proposal 4: The Maximum Data Burst Volume should be included in the non-standardized QoS flow descriptor. Proposal 5: RAN3 is requested to agree the Text Proposal for TS 38.413.	available	No
		R3‑180299	TP on QoS flow level parameters for TS 38.423	NEC	pCR	Decision	Yes	No	available	No
		R3‑180377	QoS parameters to align with SA2	Ericsson	pCR		Yes	NoProposal 1: RAN3 to update the specification so that Notification Control is only valid for GBR QoS flow parameters. Proposal 2: RAN3 to update the specification to indicate the Average Window applies only to GBR QoS flow. Proposal 3: change “GBR bearers” to “GBR QoS flows” in QoS Flow Level QoS Parameters. Remove the “Criticality” and the “Assigned Criticality” columns.	available	No
		R3‑180378	QoS parameters to align with SA2	Ericsson	pCR		Yes	No	available	No
		R3‑180379	Notification Control and QoS flow release	Ericsson	pCR		Yes	NoProposal 1: RAN3 to include a class 2 procedure in Xn, to indicate when the GBR QoS requirement can no longer be fulfilled or be fulfilled again. Proposal 2: RAN3 to include a class 2 procedure in F1, to indicate from DU to CU when the GBR QoS requirement can no longer be fulfilled or be fulfilled again. Proposal 3: The class 2 Notify procedure in Xn should be defined to be sent from on NG-RAN node to another NG-RAN node, decoupled from the MN node and SN node role. Proposal 4: RAN3 to agree to use “PDU Session Resource Notify” procedure only be used for Notification purpose, to indicate from NG-RAN node to 5GC when the GBR QoS requirement can no longer be fulfilled or be fulfilled again. Proposal 5: RAN3 to agree to modify the “PDU Session Resource Modify Indication” procedure to handle the NG-RAN node initiated release of certain QoS flows or PDU sessions.	available	No
		R3‑180380	Notification Control	Ericsson	pCR		Yes	No	available	No
		R3‑180381	Delay critical GBR QoS flows – stage 3 solution	Ericsson	pCR		Yes	NoProposal 1: RAN3 to introduce a “Delay Critical GBR” indication in GBR QoS Flow Information, as presented in this paper and in [3]. Proposal 2: RAN3 to include a new IE Maximum Data Burst Volume.	available	No
		R3‑180382	Delay critical GBR QoS flows – stage 3 solution	Ericsson	pCR		Yes	No	available	No
		R3‑180450	Delay Critical GBR indication from 5GC	Intel Corporation, Huawei	pCR	Agreement	Yes	NoProposal 1: RAN3 to extend the Resource Type IE enumeration to include “Delay critical GBR” within the Non-standardised QoS Flow Descriptor IE in TS 38.413 for the delay critical GBR indication from 5GC.	available	No
10.1.2	Default QoS	R3‑180007	Further Discussion on the Default QoS Profile	ZTE	discussion		Yes	NoProposal 1: SA2 should confirm whether CN is able to provide the reference QoS profile tailored to the characteristics of the PDU session. Proposal 2: NG-RAN needs not to know the reference QoS profile from CN. Proposal 3: Even if CN may provide the reference QoS profile, there is no specified association relation between the reference QoS profile and default DRB.	available	No
		R3‑180074	Text Proposal for most probable QoS profile	Nokia, Nokia Shanghai Bell, Intel Corporation, LG Electronics, Huawei	pCR	Agreement	Yes	No	available	No
		R3‑180075	Reply LS on default DRB establishment for PDU session	Nokia, Nokia Shanghai Bell	LS out	Agreement	Yes	No	available	No
		R3‑180328	Discussion on reference QoS profile for default DRBs	CMCC	pCR	Approval	Yes	NoProposal 1: CN to include the reference QoS profile in the NAS-level QoS profiles configured to RAN	available	No
		R3‑180383	Further Discussion on QoS setting for default DRBs	Ericsson	discussion	Agreement	Yes	NoProposal 1: RAN3 to agree that the QoS profile setting on DRBs is totally a RAN decision. There is no need for any additional QoS profile signalled from CN.	available	No
		R3‑180451	Most probable QoS profile indication from 5GC	Intel Corporation, Nokia, Nokia Shanghai Bell, Huawei, LGE	discussion	Decision	Yes	NoProposal 1: 5GC to indicate the “most probable” QoS profile (suitable to meet the most probable traffic to expect over that PDU session) among the NAS-level QoS profiles configured to RAN at the PDU session set-up, which can help RAN better serve the most of the traffics.	available	No
		R3‑180502	On the reference QoS profile for the default DRBs	China Telecommunications	agenda	Discussion	Yes	NoProposal: To indicate the optional reference QoS profile configured to RAN at the PDU session set-up which can be chosen by RAN as baseline for establishing the default DRB.	available	No
		R3‑180503	TP for optional Reference QoS Profile	China Telecommunications	agenda		Yes	No	available	No
10.1.3	Reflective QoS
10.1.4	NG/Xn/F1 UP Encapsulation Header	R3‑180076	Choice of 5GS container	Nokia, Nokia Shanghai Bell	discussion	Approval	Yes	NoProposal 1: decide that the 5GS container is specified in a separate specification and therefore sent as a separate GTP extension header container (solution 2 here-above). Proposal 2: open tdoc [5] to have a first discussion on an attempt to have a generic protocol specification applying to any interface referencing it. Proposal 3: agree on the above way forward and send the corresponding LS to CT4 in [6].	available	No
		R3‑180077	Draft Specification for 5GS container	Nokia, Nokia Shanghai Bell	discussion	Approval	Yes	No	available	No
		R3‑180078	LS on defining GTP extension header for 5GS container	Nokia, Nokia Shanghai Bell	LS out	Agreement	Yes	No	available	No
		R3‑180231	Consideration on 5GS container for QFI	Huawei	discussion		Yes	NoProposal 1: The 5GS container should be a separate GTP extension header used in NG-U. Proposal 2: The 5GS container should be put in first place among the multiple GTP-U extension headers in NG-U.	available	No
		R3‑180232	[DRAFT] LS on Consideration on 5GS Container for QFI	Huawei	LS out		Yes	No	available	No
		R3‑180255	TP for TS 38.420 on Xn-U	Samsung	pCR	Approval	Yes	No	available	No
		R3‑180256	TP for TS 37.340 on Xn-U	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180283	5GS User Plane Protocol	Samsung	discussion	Approval	Yes	NoProposal 1: The NG-U, the Xn-U and the NG-UP protocol is used to convey QFI and RQI for each transferred user data packet. Proposal 2: RAN3 agrees on developing the 5GS User Plane specification which covers the NG-U, the Xn-U and the N9 interface. Proposal 3: One byte field in the extension header can convey both RQI and QFI. RAN2 and SA2 shall confirm the exact length of QFI. Proposal 4: RQI field is included only in downlink direction from UPF to NG-RAN, but not in uplink direction from NG-RAN to UPF. Proposal 5: If RQA is not configured for a specific QoS flow, NG-RAN ignores RQI field sent with the user data packet for the QoS flow.	available	No
		R3‑180284	TP for 5GS UP	Samsung	discussion	Approval	Yes	No	available	No
10.1.5	Others	R3‑180008	Further Clarification and pCR for PDU Session/QoS Flow Failure Relevant Handling	ZTE	pCR		Yes	NoProposal 1: To define and include new SMF container: “PDU Session Failed to Setup Response Transfer” within IE “PDU Session Resource Failed to Setup List” as below. Proposal 2: To define and include new SMF container: “PDU Session Resource Failed To Modify Response Transfer” in IE “PDU Session (Resource) Failed To Modify List” as below. Proposal 3: To define and include IE “QoS Flows Failed To Release List” in IE “PDU Session Release Response Transfer” if partial PDU Session release is allowed as below. Proposal 4: To clarify the exact cases/reasons for “PDU Session Resource/QoS Flow Failed to Release” case.	available	No
		R3‑180009	Further Discussion on Tunnel Building in PDU Session Split@UPF Case	ZTE	discussion		Yes	NoProposal 1: For one PDU Session Split@UPF, there are always two UL GTP-U TEIDs in the UPF. Proposal 2: The two UL GTP-U TEIDs in the UPF belong to the same GTP-U protocol entity, associated with the same IP and transport layer address. Proposal 3: The two DL GTP-U TEIDs in the NG-RAN belong to different GTP-U protocol entity (one in MN, and the other in SN), associated with different IP and transport layer addresses.	available	No
		R3‑180227	UE-AMBR derivation in NG procedures	LG Electronics	pCR		Yes	NoProposal 1: The subscribed UE-AMBR should be provided to the gNB using the following NGAP messages: - Initial Context Setup Request - Downlink NAS Transport - Handover Request Proposal 2: The changed subscribed UE-AMBR should be provided to the gNB using the NGAP UE Context Modification Request message. Proposal 3: The Session-AMBR for PDU sessions which is transparent to the AMF should be provided to the gNB. Proposal 4: It is proposed to agree the TPs for TS 38.413.	available	No
		R3‑180228	UE-AMBR derivation in Xn procedure	LG Electronics	pCR		Yes	NoProposal 1: The subscribed UE-AMBR and Session-AMBR for PDU sessions should be transmitted through XnAP Handover Request message. Proposal 2: It is proposed to agree the TPs for TS 38.423.	available	No
10.2	Realization of Network Slicing
10.2.1	Signaling, Mobility Issues
10.2.1.1	Corrections, Clarifications	R3‑180010	Capturing NW Slice Relevant Agreements in TS37.340	ZTE	draftCR		Yes	No	available	No
		R3‑180079	Configuration of default AMF set in 38.300	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	No	available	No
		R3‑180080	Configuration of default AMF set in 38.413	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	No	available	No
10.2.1.2	Configuration, NG/Xn Setup, Config Update, Context Setup	R3‑180081	Text Proposal for Configuration of Network Slicing over NG	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal: agree the flexible format of the Network Slice Support IE presented in the Text Proposal below for TS 38.413 allowing to not necessarily always send the plain full list of supported S-NSSAI(s) and the “mirror” Text Proposal in [6] for TS 38.423.	available	No
		R3‑180082	Text Proposal for Configuration of Network Slicing over Xn	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	No	available	No
		R3‑180266	Discussion on Allowed NSSAI in NG-RAN	LG Electronics	pCR		Yes	NoProposal 1: The Allowed NSSAI should be provided by the AMF in Initial Context Setup Request message. Proposal 2: It is proposed to agree the text proposals in the appendix of this contribution.	available	No
		R3‑180384	Slice configuration at NG and Xn Setup	Ericsson	pCR		Yes	NoProposal 1: It is proposed that the AMF signals a TAI Slice Support List in the NG Setup Response Proposal 2: it is proposed that the TAI Slice Support List IE signalled by a RAN node in the Xn Setup Request/Response consists of the list of slices per TA signalled to the RAN node by the connected AMFs and supported by the RAN Proposal 3: - The TAI Slice Support List included in the NG: RAN Configuration Update may consist of an overall list of S-NSSAIs supported by the RAN per TA. Namely, this may not be the list of slices enabled (by CN) for the TA. - The TAI Slice Support List included in the NG: AMF Configuration Update consists of the list of slices enabled for the TA by the AMF. - The TAI Slice Support List IE signalled by a RAN node in the Xn: NG-RAN Node Configuration Update consists of the list of slices per TA signalled to the RAN node by the connected AMFs and supported by the RAN	available	No
		R3‑180385	Slice configuration at Xn Setup	Ericsson	pCR		Yes	No	available	No
		R3‑180467	Xn Slice available information	Huawei	pCR		Yes	NoProposal 1: Signalling SD only in over Xn does not bring any benefits. Proposal 2: The S-NSSAI list IE should be included in the NG-RAN node configuration update procedure. Proposal 3: Define the S-NSSAI information element, and update the Slice Support List accordingly in 38.423.	available	No
		R3‑180468	Ng Slice available information	Huawei	pCR		Yes	NoProposal 1: The AMF slice support IE is a TA level, i.e., the AMF provides those supported S-NSSAI per TA to the RAN during NG interface setup/update procedure. Proposal 2: Remove the editor note on the separate codepoint of “SD only” from 38. 413. Proposal 3: The gNB is configured with its supported slices per TA and different configurations by the OAM, which should be explicitly captured in 38.300.	available	No
		R3‑180469	TP for 38.300 on Slice available information	Huawei	draftCR		Yes	No	available	No
		R3‑180479	Slice Information Exchange over NG	Huawei	pCR		Yes	NoProposal 1: A simple solution shall be introduced to get the slice availability information of neighboring cells in case of absence of Xn interface. Proposal 2: It is proposed to consider that gNB retrieves unknown slice availability information of neighbouring cells from the AMF. Proposal 3: The slice availability information from AMF to gNB should be in TA granularity, i.e., the AMF provides the supported S-NSSAIs per neighbouring TA(s) to the gNB during NG interface setup procedure.	available	No
10.2.1.3	Mobility, DC	R3‑180083	Text Proposal for Slice information in Path Switch Request	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal: agree the Text Proposal below for the presence of S-NSSAI in the Path Switch Request and Path Switch Request Acknowledge messages.	available	No
		R3‑180107	Slice Rejection Handling in Xn Handover	Qualcomm Incorporated	pCR	Approval	Yes	NoProposal 1: Add rejected S-NSSAI list and cause into Path Switch Request. Proposal 2: Agree the TP for proposal 1.	available	No
		R3‑180268	Considering slice information in SN modification procedure	LG Electronics	pCR		Yes	NoProposal 1: Add rejected S-NSSAI list and cause into Path Switch Request. Proposal 2: Agree the TP for proposal 1.	available	No
		R3‑180386	Mobility procedures for Slicing	Ericsson	pCR		Yes	NoProposal 1: it is proposed that, in cases of UE mobility involving PDU Sessions associated to network slices not supported at target NG RAN, the source NG RAN triggers an NG handover Proposal 2: it is proposed to allow the NG: PATH SWITCH RESPONSE to provide slice information per PDU Session to be switched, upon decision of such information by the AMF Proposal 3: It is proposed to use NG based mobility in cases of handovers of UEs with active network slices from NG RAN nodes supporting network slicing to NG RAN nodes not supporting network slicing	available	No
		R3‑180387	Mobility procedures for Slicing	Ericsson	pCR		Yes	No	available	No
		R3‑180470	NG based mobility	Huawei	pCR		Yes	NoProposal 1: All PDU sessions handled by NG-RAN shall be included in the Handover Required message. Proposal 2: The S-NSSAI of each PDU session may be included in the Handover Required message. Proposal 3: A flag indication or cause value indicating “slice not supported” shall be introduced in NR.	available	No
		R3‑180472	[DRAFT] LS regarding Xn based handover across different Registration Areas	Huawei	LS out		Yes	No	available	No
		R3‑180473	Xn based mobility	Huawei	draftCR		Yes	NoProposal 1: All PDU sessions handled by the source NG-RAN shall be included in Handover Request message. Proposal 2: Target NG-RAN node shall check the slice availability of each PDU session for admission control. Proposal 3: Target NG-RAN node shall check the resource availability for each slice for admission control. Proposal 4: Not admitted PDU sessions shall be informed to the source NG-RAN node with cause value or flag indication. Proposal 5: List of rejected PDU sessions shall be included in the Path Switch Request message. Proposal 6: Remove the FFS and confirm S-NSSAI carried in the Path Switch Request and Path Switch Request ACK message.	available	No
		R3‑180474	TP for 38.423 for Xn based mobility signalling	Huawei	pCR		Yes	No	available	No
		R3‑180475	TP for 38.413 for Xn based mobility signalling	Huawei	pCR		Yes	No	available	No
10.2.1.4	Mobility Across RAs	R3‑180199	Discussion on Slice mobility issue	CATT	discussion		Yes	NoProposal 1: Target Node send the HO Ack include PDU Sessions Not Admitted List with No slice Resources Available to the source node if slice level resource shortage when Xn HO Proposal 2: All the PDU sessions may be released and trigger the allowed S-NSSAI change procedure if the target node does not support any severed slice in source node Proposal 3: Xn Handover should be performed when inter Registration Area mobility in connected mode. The PDU session of not supported slice may be removed via Xn handover.	available	No
		R3‑180267	Inter-registration area mobility considering network slice	LG Electronics	pCR		Yes	NoProposal 1: The Xn-based handover should be triggered when the Xn connectivity is available and UE moves across different registration areas. Proposal 2: By using the Path switch procedure, the accepted and rejected S-NSSAIs needs to be exchanged between the target gNB and AMF. Proposal 3: It is proposed to agree the text proposals in the appendix of this contribution.	available	No
		R3‑180452	Consideration for mobility across different RAs	Intel Corporation	discussion	Decision	Yes	NoProposal 1: RAN3 to allow Xn based HO across different RAs via slice removal. Proposal 2: If RAN3 decides to allow, then inform SA2 via LS about the decision.	available	No
		R3‑180471	Xn based mobility for inter-RA case	Huawei	draftCR		Yes	NoProposal 1: Xn based handover shall be supported for active mode mobility across different Registration Areas (i.e., regardless of slice availability).	available	No
10.2.1.5	Others	R3‑180465	Clarification on Allowed NSSAI in 38.413	Huawei	pCR		Yes	NoProposal 1: To include Allowed NSSAI in INITIAL CONTEXT SETUP REQUEST message. Proposal 2: To include Allowed NSSAI in NG signaling during HO, i.e. HANDOVER REQUEST message from AMF to target NG-RAN node.	available	No
		R3‑180466	Clarification on Allowed NSSAI in 38.423	Huawei	pCR		Yes	NoProposal: To include Allowed NSSAI in Xn signaling during HO, i.e. HANDOVER REQUEST from source NG-RAN node to target NG-RAN node.	available	No
10.2.2	Slice Unavailability	R3‑180326	Clarification on slice availability	CMCC	discussion	Decision	Yes	NoProposal 1: Differentiated slice configurations on neighbouring RAN nodes should be supported. Proposal 2: Differentiated slice configurations on RAN nodes within RA should be supported.	available	No
		R3‑180011	NW Slice Temporarily Unavailable	ZTE	discussion		Yes	NoProposal: NW Slice temporarily unavailable indication is not needed. Remove FFS of temporarily unavailable status from TS 38.413.	available	No
		R3‑180084	Correction of slice temporarily unavailable	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal 1: agree the Text Proposal below to remove the FFS on signaling from gNB to AMF of a RAN slice temporarily unavailable.	available	No
		R3‑180476	Temporarily unavailable slice	Huawei	pCR		Yes	NoProposal 1: Remove the FFS sentence regarding the temporally unavailable status of S-NSSAI from NG setup and Configuration update message. Proposal 2: No need to send LS to SA2 for the clarification of temporally unavailable S-NSSAI.	available	No
		R3‑180198	TP for 38.413 on Slice unavailable	CATT	pCR		Yes	NoProposal 1: Remove “FFS if temporarily unavailable status of S-NSSAI need to be considered” from NG SETUP REQUEST Proposal 2: RAN slices time based unavailable need to be considered.	available	No
10.3	Support of Self-Organising Network (SON) functions
10.3.1	TNL Address Discovery for NG-RAN	R3‑180203	Stage 2 CR for NG-RAN node Xn-C TNL address discovery	Huawei	draftCR	Approval	Yes	NoIn NG-RAN, both ng-eNB and gNB connects to 5GC via a common NG interface. NG-RAN node Xn-C TNL address discovery through 5GC becomes feasible. Therefore, there is no need to evaluate any other alternatives like we did for option 3. In RAN3 #95bis meeting, RAN3 agreed that principles of ANR and automated interface setup (X2, S1) in LTE are the baseline of 5G system (Xn, NG). The stage 3 part of 5GC based NG-RAN node Xn-C TNL address discovery was agreed in R3-171337. However, the stage 2 description is still missing.	available	No
		R3‑180153	NG-RAN node Xn-C TNL address discovery	Huawei	discussion	Approval	No	Yes	withdrawn	Yes
10.3.2	NG/Xn Setup	R3‑180154	Xn setup and NG-RAN node configuration update	Huawei	discussion	Approval	Yes	NoProposal 1: Exchange of full list of served cells between two neighbouring NG-RAN nodes shall be supported. Proposal 2: RAN3 to agree that cell level parameters are grouped into multiple served cell information groups and exchanged between NG-RAN nodes based on explicit indication from the initiating node.	available	No
		R3‑180204	Stage 2 CR for Xn setup and NG-RAN node configuration update	Huawei	draftCR	Approval	Yes	NoThis is the corresponding CR for Xn setup and NG-RAN node configuration update as discussed in R3-180154.	available	No
		R3‑180236	Supplementary uplink (SUL) information for NR cells over X2/Xn/F1	Samsung	draftCR	Approval	Yes	NoProposal: the SUL carrier frequency and bandwidth information should be provided in the served cell information.	available	No
		R3‑180237	Supplementary uplink (SUL) information for NR cells over Xn	Samsung	pCR	Approval	Yes	No	available	No
10.4	Support for PWS	R3‑180100	Stage 2 for PWS support (TS 38.410)	Nokia, Nokia Shanghai Bell, AT&T, Huawei, one2many	pCR		Yes	NoProposal 1: The following PWS-related procedures in S1AP should be used as baseline for NGAP: Write-Replace Warning, Kill, PWS Restart Indication, and PWS Failure Indication. Proposal 2: The Kill procedure in S1AP should be renamed to PWS Cancel procedure in NGAP.	available	No
10.5	Radio Access Network connected to 5G-CN	R3‑180006	LS on handling concurrent running of security procedures	3GPP SA WG3, Ericsson	LS in		Yes	No	available	No
10.5.1	Multiple SCTP Associations and Related Mechanisms	R3‑180004	LS reply on multiple SCTP associations	3GPP SA WG2, Intel	LS in		Yes	No	available	No
		R3‑180005	LS reply on N2 requirements and procedures	3GPP SA WG2, Intel	LS in		Yes	No	available	No
		R3‑180047	Analysis on NGAP support for multiple-SCTP associations	Nokia, Nokia Shanghai Bell	pCR		Yes	NoProposal 1: Introduce a new NGAP procedure to release the UE-TNLA-Binding. Proposal 2: Update Stage-2 to remove the Association deactivation from the AMF management section, and add a new section for NGAP TNLA Binding Release. Proposal 3: Update AMF Configuration Update procedure to 1) include weight factor for each TNL association. 2) indicate whether a TNL association is only used for UE-associated signalling, or non-UE associated signalling, or both. Proposal 4: Update RAN Configuration Update procedure to indicate new SCTP endpoints to be added in the NG-RAN node, and the existing SCTP endpoints to be removed in the NG-RAN node. Proposal 5: Update Stage-2 to support triangular redirection.	available	No
		R3‑180048	TP for multiple-SCTP association support	Nokia, Nokia Shanghai Bell	pCR		Yes	No	available	No
		R3‑180085	Text Proposal for multiple SCTP for TS 38.412	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal 1: turn the WA into agreement that multiple SCTP associations are used per gNB-AMF pair. Assuming proposal 1 agreed, we also propose the following rules to use these SCTP associations: - The gNB shall always be the initiator of the SCTP association (please note does not prevent AMF to send the SCTP INIT for the restart case as per RFC 4960); - One pair of streams shall be reserved for the non-UE associated procedures over at least one SCTP association (several possible); FFS whether multiple streams could be used. - A single UE associated signalling transaction shall use one SCTP association and one SCTP stream and the association/stream should not be changed during a UE-associated signalling transaction unless TNL binding update is triggered as defined in TS 23.502. Proposal 2: agree the following principles for TS 38.412 on the usage of SCTP associations and streams. Besides, for each SCTP association the support of multi-homing should be specified again, as per today TS 36.412 for LTE, for the failure case of an individual IP routing path. Proposal 3: agree the multi-homing support per SCTP association.	available	No
		R3‑180105	Discussion on multiple SCTP associations	ZTE Corporation	discussion		Yes	NoProposal1: If AMF initiates to release the N2AP UE-TNLA-binding for only a subset of the served UEs , the implicit way is preferred. Proposal2: In order to respect the requirement from SA2, the AMF’s TNL address may be provided from source NG-RAN node to target NG-RAN node during Xn handover preparation as optional behaviour. Proposal3: The handling of the common NGAP procedures related NGAP nonUE-TNLA-binding is similar as NGAP-UE-TNLA-binding, it is AMF who decides which TNLA is used for the current ongoing non-UE associated signaling. Proposal4: During NG Setup Procedure and AMF configuration Update procedure, the AMF needs to signal the the weight factor of each newly added TNL association, or update the weight factor of each current TNL associations.	available	No
		R3‑180116	TP on multiple SCTP associations for TS38.300	ZTE Corporation	draftCR		Yes	No	available	No
		R3‑180118	Multiple SCTP associations support for TS38.413	ZTE Corporation	draftCR		Yes	No	available	No
		R3‑180263	Discussion on AMF management	Huawei	discussion		Yes	NoProposal 1: A new procedure AMF STATUS INDICATION should be defined to indicate a specific AMF unavailability from AMF to NG RAN. Proposal 2: AMF reselection within the same AMF set function should be performed after receiving AMF unavailability indication. Proposal 3: Additionally, the target AMF information e.g. target AMF name associated with GUAMI should be provided to NG RAN. Proposal 4: The target AMF sends the indication to NG RAN that the old GUAMI(s) are now served by target AMF by AMF Configuration Update procedure. Proposal 5: It is up to RAN to detect the AMF failure Proposal 6: The backup AMF information e.g. the AMF name associated with each GUAMI should be sent from AMF to NG RAN in NG Setup procedure. Proposal 7: It is proposed that AMF Name IE is mandatory in NG SETUP RESPONSE. Proposal 8: gNB provides the Globle RAN Node ID on each TNLA to AMF, so that AMF can associate the gNB identity with the TNLA.	available	No
		R3‑180388	Support of multiple signalling TNL associations per AMF	Ericsson	discussion	Agreement	Yes	NoProposal 1 It is proposed to add protocol support for an explicit NG-RAN triggered NGAP-level confirmation after a successful TNLA establishment. Proposal 2 We conclude from that and propose to agree on the following principles 1. The AMF selects TNLAs for non-UE associated signalling, for initial (UL) N2 messages and subsequent UE associated signalling. If the AMF does not indicate anything all TNLAs are allowed to be used for any kind of signalling. 2. Paging is allowed to be sent on all TNLAs. 3. The NG-RAN cannot select the use of TNLAs. 4. The principle of using different SCTP streams for UE-associated and non-UE associated signalling as foreseen for EPS can be kept. 5. Weight Factors are introduced on a per AMF and per TNL association basis. Proposal 3 It is proposed to liaise to SA2 to abstain from introducing an explicit per UE NGAP-UE TNLA binding release.	available	No
		R3‑180389	Support of multiple signalling TNL associations per AMF – TP for 38.412	Ericsson	pCR		Yes	No	available	No
		R3‑180390	Support of multiple signalling TNL associations per AMF	Ericsson	draftCR		Yes	No	available	No
		R3‑180391	Support of multiple signalling TNL associations per AMF – TP for 38.401	Ericsson	other		Yes	No	available	No
		R3‑180392	Support of multiple signalling TNL associations per AMF – TP for 38.413	Ericsson	pCR		Yes	No	available	No
		R3‑180393	Support of multiple signalling TNL associations per AMF – TP for 38.423	Ericsson	pCR		Yes	No	available	No
		R3‑180394	[DRAFT] reply LS on N2 requirements and procedures (To: SA2)	Ericsson	LS out		Yes	No	available	No
		R3‑180462	On multiple SCTP associations for NG-C	Intel Corporation	pCR	Agreement	Yes	NoProposal 1: to define a flag for each “AMF TNL to be Setup Item IE” indicating whether that TNL address can be used for UE-associated signalling, non-UE associated signalling or both. Proposal 2: to define a new non-UE associated NG-AP message to release or update a UE-TNLA binding for a group of UEs. Proposal 3: to signal 32 bit integer weight factor for every TNL association.	available	No
		R3‑180464	Considerations on supporting multiple SCTP associations in NG-c	Qualcomm Incorporated	discussion	Discussion	Yes	NoProposal 1: Consider whether a NGAP initialization procedure is required (as the first message(s) in a new TNLA). Proposal 2: Consider whether a NGAP UE-associated binding release procedure is required. Proposal 3: Consider whether a TNLA index / identifier is required, and if so, whether this should uniquely identify an AMF endpoint irrespective of gNB peer. Proposal 4: RAN3 to discuss whether explicit support for RAN virtualization should also be considered when designing the NG protocol support for multiple TNLAs.	available	No
10.5.2	NG-Based RRC_ACTIVE Mode Mobility (Handover)
10.5.2.1	Common Aspects	R3‑180086	Handover and Redirection of Emergency Services	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	No	available	No
		R3‑180395	NG handover	Ericsson	pCR		Yes	NoProposal 1: Clarify how the source to target and target to source transparent container are used, depending on Inter/Intra system. Proposal 2: discuss and agree the Source gNB to Target gNB Transparent Container and Target gNB to Source gNB Transparent Container.	available	No
		R3‑180396	Correction on Path Switch Request	Ericsson	pCR		Yes	NoProposal 1: RAN3 to include a PDU session failed to setup list in Path Switch Request.	available	No
		R3‑180262	Handover Type in Handover Reqired message	Samsung R&D Institute UK	pCR	Approval	No	No	reserved	No
		R3‑180264	[DRAFT] LS on handover type from NG-RAN to 5GC	Samsung R&D Institute UK	LS out	Approval	No	No	reserved	No
10.5.2.2	Intra-System Specifics
10.5.2.3	Inter-System Specifics, 5G->4G	R3‑180087	Correction of 5G to 4G handover	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal 1: remove the editor’s note on the E-RABs Information List IE and add a statement for inclusion of the optional IE. Proposal 2: add the missing specification related to incomplete description of timer handling. Proposal 3: add the missing specification related to signalling PDU sessions not admitted at target side. Proposal 4: discuss the addition of gNB cell ID in the source eNB to target eNB container.	available	No
10.5.2.4	Inter-System Specifics, 4G->5G
10.5.3	NG-RAN Node Identification on NG and Xn	R3‑180101	On the need for explicit signalling of gNB length	Qualcomm Incorporated	discussion	Approval	Yes	NoProposal 1: There is no need for explicit signalling of the gNB ID length.	available	No
		R3‑180099	Impacts of flexible length gNB ID on NGAP procedures	Nokia, Nokia Shanghai Bell	pCR		Yes	NoProposal 1: In the UPLINK RAN CONFIGURATION TRANSFER message (used for TNL address discovery), the initiating NG-RAN node includes the Global gNB ID and TAI of the target (i.e. same as LTE). Proposal 2: In the HANDOVER REQUIRED message, the source gNB includes the Global gNB ID and TAI of the target (i.e. same as LTE).	available	No
		R3‑180397	TAC Extension for NR and NG-RAN	Ericsson	pCR		Yes	NoProposal 1: Introduce in NGAP a CHOICE between the Legacy TAC IE and an Extended TAC IE, defined as OCTET STRING (SIZE(3)). Proposal 2: Agree the TP below and the related TP for Stage 2 in [3]. Proposal 3: RAN3 should liaise RAN2 and SA2 [4] to receive feedback on extending the TAC with a CHOICE for NG-RAN.	available	No
		R3‑180398	TAC Extension for NR and NG-RAN – Stage 2	Ericsson	draftCR		Yes	NoThe operator's choices for TAI allocation in the network may influence or (in the worst case) constrain network performance. Extending the TAC for NR and NG-RAN gives maximum deployment flexibility for operators while maintaining backwards compatibility with already deployed networks.	available	No
		R3‑180399	[DRAFT] LS on Extending TAC for NR and NG-RAN (To: RAN2, SA2)	Ericsson	LS out		Yes	No	available	No
10.5.4	Roaming and Access Restrictions for RRC_ACTIVE Mobility
10.5.5	Data Forwarding (both intra- and inter-system)
10.5.5.1	Common Aspects	R3‑180088	Text Proposal for Stage 2 Data forwarding	Nokia, Nokia Shanghai Bell	draftCR	Endorsement	Yes	No	available	No
		R3‑180214	Introduction of stage 2 text for Data Forwarding	Nokia, Nokia Shanghai Bell	discussion	Approval	Yes	NoProposal 1: correct the WA for case A/ into A) PDCP SDUs (with SN assigned but not acked by UE) -> per-DRB-level tunneling Proposal 2: for the fresh incoming packets (after PDCP SN freeze) it is source gNB implementation choice whether to forward them as PDCP SDUs w/o SN or as SDAP SDUs. In the first case, the packets shall be forwarded over DRB tunnels and in the second case over a PDU session tunnel.	available	No
		R3‑180490	Data forwarding aspects for intra-system ACTIVE mobility and DC bearer type change	Ericsson	discussion		Yes	NoProposal 1 Acknowledge from a RAN3 point of view that support of lossless intra-5G system handover, i.e. support of data forwarding of PDCP PDUs, in-sequence delivery and duplication avoidance, is not supported in Rel-15, if QoS flow-to-DRB re-mapping occurs at the target NG-RAN node. Proposal 2 Agree that support of data forwarding of PDCP PDUs, in-sequence delivery and duplication avoidance is not supported in Rel-15 for MR-DC with 5GC in case of bearer type change and mobility scenarios that involve re-locating the PDCP entity of a DRB, if QoS flow-to-DRB re-mapping occurs at the “target” NG-RAN node hosting PDCP. Proposal 3 Acknowledge the Working Assumption established for Xn HO for MR-DC with 5GC, whenever applicable, i.e. all bearer type change and mobility scenarios where the logical NG-RAN node hosting PDCP is changed. Proposal 4 Acknowledge the Working Assumption established for Xn HO for NG HO with direct data forwarding. Proposal 5 Align principles for direct and indirect NG based HO. Proposal 6 Establish the working assumption that QoS flow-to-DRB mapping information is provided within an inter-node RRC message to the target NG-RAN node in case of mobility scenarios and MR-DC bearer type change scenarios, i.e. in an XnAP/NGAP transparent way. Proposal 7 It is proposed to include within NG handover messages data forwarding information per PDU Session with the possibility to provide per-DRB data forwarding information. Proposal 8 The source NG-RAN node shall indicate on a per DRB basis, whether data forwarding shall be applied. Proposal 9 It is proposed to acknowledge this agreement and to include data forwarding information within PDU Session related information in the Handover Required message. Proposal 10 No protocol support is provided for data forwarding of DL SDAP PDUs. Further it is proposed to agree on the TP for 37.340 in R3-180493 and on the TP for XnAP in R3-180492 and the TP for NGAP in R3-180491.	available	No
		R3‑180491	Data forwarding aspects for intra-system ACTIVE mobility – TP for NGAP	Ericsson	pCR		Yes	No	available	No
10.5.5.2	NG-Based Handover Aspects	R3‑180257	Data Forwarding in NG Based Handover	Samsung	pCR	Approval	Yes	NoProposal 1: It is proposed RAN3 to adopt a method that avoiding transfer DRB ID to AMF/SMF/UPF. Proposal 2: It is proposed RAN3 to adopt “DL forwarding” proposal for per-QoS flow. Proposal 3: It is proposal target NG-RAN node indicates Data Forwarding Accepted for each QoS Flow that DL forwarding IE is set to “DL forwarding proposed”.	available	No
		R3‑180321	Data forwarding for NG Handover	Huawei	other		Yes	NoProposal 1: Same data forwarding approach is used for Xn handover and NG handover. Proposal 2: DRB id in source gNB will be used to identify the indirect forwarding tunnel in NGC. Proposal 3: The source gNB should indicate the PDU sessions requested to handover to SMF. Proposal 4: The source gNB should indicate the DL forwarding proposed indicator for PDU sessions and associated DRBs in the Source to Target Transparent Container. Proposal 5: The SMF should send the Transport Layer Information of data forwarding for PDU sessions and associated DRBs to the source gNB.	available	No
		R3‑180322	Data forwarding for NG Handover	Huawei	pCR		Yes	No	available	No
		R3‑180400	Handling of End Marker in HO and DC	Ericsson	discussion	Agreement	Yes	NoProposal 1: During handover the UPF sends one or more "end marker" per PDU sessions/tunnel on the old path to the source NG-RAN node before it releases the user plane towards the source NG-RAN. Proposal 2: For direct data forward, the source NG-RAN node forwards the end marker per forwarded DRB /tunnel to the target NG-RAN node.	available	No
		R3‑180401	Correction on Handling of End Marker in HO and DC	Ericsson	draftCR		Yes	No	available	No
		R3‑180247	Open issues on Data forwarding for Inter-system handover from 5GS to EPS	Samsung	pCR	Approval	Yes	NoProposal: Agree Qos flow list accepted for data forwarding in Handover Command message.	available	No
		R3‑180248	Text proposal to stage 2 on inter-system handover from 5GS to EPS	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180089	Finalization of 5G to 4G Data forwarding	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal 1: agree the corrections above as reflected by tdoc [1] as a starting point by adding an SM Info container in the tabular format of the HO Command message and the missing procedural text. Proposal 2: agree that the forwarding granularity at the source side corresponds to E-RAB level. Proposal 3: add into the SM Info container of the HO Command message the indication of which QoS flows have been selected to be forwarded by source gNB over the forwarding tunnel of the PDU session.	available	No
		R3‑180320	Inter-system handover from EPS to 5GS	KT Corp.	discussion		Yes	NoProposal 1: To minimize the modification of eNB and S1AP, QoS flow-to-E-RAB mapping information shall be provided to the target NG-RAN node for inter-system handover from EPS to 5GS. Proposal 2: It is preferred that the indirect data forwarding from EPS to 5GS shall be performed per E-RAB by modifying the Source to Target Transparent Container IE for intra-system handover.	available	No
		R3‑180090	Conclusion and Text Proposal for data forwarding at 4G to 5G Handover	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	No	available	No
		R3‑180091	Text Proposal for data forwarding at 4G to 5G Handover	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	No	available	No
		R3‑180215	Finalization of Data Forwarding at 4g to 5g Handover	Nokia, Nokia Shanghai Bell	discussion	Approval	Yes	NoProposal 1: align with SA2 and select solution 2 for the 4g to 5g inter-system handover. Proposal 2: agree the Text Proposal below for TS 38.300 describing the key data forwarding principles for the 4g to 5g inter-system handover.	available	No
		R3‑180249	Data forwarding for Inter-system handover from EPS to 5GS	Samsung	draftCR	Approval	Yes	NoProposal 1: it is proposed to agree the following proposals for handover from EPS to 5GS: - The source RAN node proposes data forwarding; the target node confirms - Tunnel granularity between gNB and UPF is per-PDU-session-tunnel - Tunnel granularity for data forwarding between eNB and SGW is per-E-RAB Proposal 2: It is proposed for RAN3 to select one option between solution 2a and solution 3.	available	No
		R3‑180250	Support of data forwarding for inter-system handover from EPS to 5GS (Solution 3)	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180251	Stage 2 change to support data forwarding for inter-system handover from EPS to 5GS	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180143	Data forwarding for inter system HO from EPS to 5GS	CATT	draftCR		Yes	NoProposal 1: Similar to inter system data forwarding from 5GS to EPS, some basic principles for inter system data forwarding from EPS to 5GS as discussed above should be agreed and captured in the stage 2. Proposal 2: adopt solution 2 for data forwarding from EPS to 5GS to limit the impact to EPS. Proposal 3: Discuss and agree the stage 2 TP in section 5. Proposal 4: Discuss and agree the stage 3 TPs for 38.413[4] and 36.413[5].	available	No
		R3‑180144	TP for 38.413 on data forwarding from EPS to 5GS	CATT	pCR		Yes	No	available	No
		R3‑180145	TP for 36.413 to support handover from EPS to 5GS	CATT	draftCR		Yes	No	available	No
10.5.5.3	Xn-Based Handover Aspects	R3‑180258	Data Forwarding in Xn Based Handover	Samsung	pCR	Approval	Yes	NoProposal 1: PDCP SDU without SN is forwarded in the per-DRB tunneling. Proposal 2: Only per-PDU tunneling is established for data forwarding in case of target RAN node configure a different mapping. Proposal 3: It is proposed RAN3 to adopt “DL forwarding” proposal for per-QoS flow. Proposal 4: It is proposal target NG-RAN node indicates Data Forwarding Accepted for each QoS Flow that DL forwarding IE is set to “DL forwarding proposed”.	available	No
		R3‑180146	Data forwarding for Xn Handover	CATT	draftCR		Yes	NoProposal 1: For lossless handover, DL PDCP SDUs should be forwarded in DRB level tunnel for Xn Handover. Proposal 2: In case of the target NG-RAN node does not use the same DRB configuration as the source NG-RAN node, only PDU session level tunnels are needed for data forwarding. Proposal 3: Discuss and agree the stage 2 TP in section 5. Proposal 4: Discuss and agree the TP for 38.423 in [2].	available	No
		R3‑180147	TP for 38.423 on Data forwarding for Xn Handover	CATT	pCR		Yes	No	available	No
		R3‑180301	Data forwarding during Xn Handover	Huawei	other		Yes	NoProposal 1: The DL PDCP SDUs without SN should be forwarded in DRB level. Proposal 2: The QFI and RQI (if any) of the forwarded DL SDAP SDU should be in the encapsulated header. Proposal 3: For DL PDCP SDU, the maximum PDCP COUNT is used to mark the last PDCP SDU in the forwarding data. Proposal 4: The end marker received from UPF is used to mark the last SDAP SDU in the forwarding data.	available	No
		R3‑180302	Xn Data forwarding and QoS Parameters Update for Xn Handover	Huawei	pCR		Yes	No	available	No
		R3‑180492	Data forwarding aspects for intra-system ACTIVE mobility – TP for XnAP	Ericsson	pCR		Yes	No	available	No
10.5.5.4	Dual Connectivity Related Aspects	R3‑180493	Data forwarding aspects for intra-system ACTIVE mobility – TP for 37.340	Ericsson	draftCR		Yes	No	available	No
10.5.5.5	Others	R3‑180494	Removing data forwarding from the corresponding node for EN-DC	Ericsson	draftCR		Yes	No	available	No
		R3‑180495	Removing data forwarding from corresponding node for MR-DC – XnAP TP	Ericsson	pCR		Yes	No	available	No
10.5.6	Others	R3‑180022	LS on User Plane Security Policy	3GPP SA3, Huawei	LS in		Yes	No	available	No
		R3‑180003	Reply LS on supporting non-3GPP access in NGAP	3GPP SA WG2, Nokia	LS in		Yes	No	available	No
		R3‑180001	Discussion on Non-3GPP Access support in NGAP	Nokia, Nokia Shanghai Bell	pCR		Yes	No	available	No
		R3‑180049	Discussion on AMF management	Nokia, Nokia Shanghai Bell	pCR		Yes	NoProposal 1: Introduce a new NGAP procedure to inform NG-RAN node that an AMF will be unavailable.	available	No
		R3‑180050	Discussion on Overload Control in NGAP	Nokia, Nokia Shanghai Bell	pCR		Yes	NoProposal 1: Introduce Overload Start procedure, and Overload Stop procedure in NGAP. Proposal 2: The overload control related to slice needs to wait for SA2 clarification. It can be introduced later once SA2 clarifies it.	available	No
		R3‑180051	TP for NGAP Overload Control	Nokia, Nokia Shanghai Bell	pCR		Yes	No	available	No
		R3‑180097	MDT and Trace support in NG-RAN	Nokia, Nokia Shanghai Bell, Huawei	pCR		Yes	NoProposal 1: MDT is not supported by NG/Xn interfaces in Rel-15. Proposal 2: Trace shall be supported by NG/Xn interfaces in Rel-15.	available	No
		R3‑180098	NG interface management procedures	Nokia, Nokia Shanghai Bell	pCR		Yes	NoProposal 1: For the NG SETUP FAILURE message, the S1 SETUP FAILURE message from TS 36.413 can be reused as baseline. Proposal 2: For the NG RESET message, the RESET message from TS 36.413 can be reused as baseline. Proposal 3: For the NG RESET ACKNOWLEDGE message, the RESET ACKNOWLEDGE message from TS 36.413 can be reused as baseline. Proposal 4: For the ERROR INDICATION message, the ERROR INDICATION message from TS 36.413 can be reused as baseline.	available	No
		R3‑180108	VoNR Feature Plan	Qualcomm Incorporated	discussion	Discussion	Yes	NoProposal 1: Basic functionality for VoNR call setup and operation shall be supported in R15. Proposal 2: Basic functionality for VoNR to VoLTE handover/fallback shall be supported in R15. Proposal 3: Performance optimization purpose features shall be supported in R15 on best effort basis. Proposal 4: VoNR specific MDT/SON is not supported in R15. Proposal 5: Voice specific features which have been defined for several years but never commercially deployed are not supported in R15. Proposal 6: Among the performance optimization features, commercially deployed VoLTE features should be prioritized based on user experience gain, e.g. call setup success rate, mobility reliability, power, coverage, voice quality.	available	No
		R3‑180109	UE radio capability handling	Qualcomm Incorporated	discussion	Approval	Yes	NoProposal 1: UE radio capability is uploaded to CN with UE CAPABILITY INFO INDICATION procedure. Proposal 2: RAN may compose full UE radio capability from multiple partial UE radio capability reporting. The uploaded UE radio capability always overwrites the cached UE radio capability in CN. Proposal 3: UE radio paging capability is generated by RAN and uploaded to CN in UE CAPABILITY INFO INDICATION procedure. Proposal 4: UE radio paging capability shall be included in CN paging on NG-C and RAN paging on Xn-C. Proposal 5: UE radio capabilities are coordinated between Master node and Secondary node of DC/MR-DC in MN to SN container and SN to MN container.	available	No
		R3‑180110	UE capability Indication (P-CR 38.413)	Qualcomm Incorporated	pCR	Approval	Yes	No	available	No
		R3‑180111	UE capability Indication (P-CR 38.410)	Qualcomm Incorporated	pCR	Approval	Yes	No	available	No
		R3‑180112	NG Paging Procedure	Qualcomm Incorporated	discussion	Discussion	Yes	NoProposal 1: Agree the NG Paging parameters proposed in last column of table 1. Proposal 2: Agree the associated TP	available	No
		R3‑180113	Paging procedure (P-CR 38.413)	Qualcomm Incorporated	pCR	Approval	Yes	No	available	No
		R3‑180120	TPs for XnAP for MDT and Trace support in NG-RAN	Huawei, Nokia, Nokia Shanghai Bell	pCR	Approval	Yes	No	available	No
		R3‑180229	Discussion on Reroute NAS Request	Nokia, Nokia Shanghai Bell	pCR		Yes	NoProposal: update Reroute NAS Request to align with SA2.	available	No
		R3‑180370	User Plane security impact on NG interface	Huawei	pCR		Yes	NoProposal 1. From RAN3 perspective, 5GC needs to inform RAN whether the integrity protection and ciphering are needed or not during PDU session establishment. Proposal 2. Indicators of integrity protection and ciphering activation are needed per PDU session in the PDU SESSION RESOURCE SETUP message.	available	No
		R3‑180371	User Plane security impact on Xn interface	Huawei	pCR		Yes	NoProposal: During Handover Preparation procedure, the indicators of integrity protection and ciphering activation are needed in HANDOVER REQUEST message.	available	No
		R3‑180373	[Draft] Reply LS on User Plane Security Policy	Huawei	LS out		Yes	No	available	No
		R3‑180402	Corrections to PDU Session Resource information	Ericsson	pCR		Yes	NoProposal 1 It is proposed to modify NGAP so that if a UE Context is requested in RAN, it also corresponds to a request to allocate resources for at least one PDU Session. Proposed NGAP modifications are in the Annex of this contribution.	available	No
		R3‑180459	NG-AP Paging Procedure and Signaling	Intel Corporation	pCR	Agreement	Yes	NoProposal 1: NG-AP Paging message shall carry at least: UE Identity Index Value, UE Paging Identity, Paging DRX, Paging Priority, and TAI List. Proposal 2: NG-AP Paging message shall also carry: UE Radio Capability and Recommended Cells, encoded similarly to S1-AP. Proposal 3: to discuss RAN3 preference access associated to the PDU session” and PDU Session ID encoding in NG-AP and liaise RAN2, CT1 and SA2 on this matter.	available	No
		R3‑180461	[DRAFT] LS on NAS level information in paging	Intel Corporation	LS out	Agreement	Yes	No	available	No
		R3‑180477	NG Reset	Huawei	pCR		Yes	NoProposal 1: We propose that RAN3 discuss a reset solution and select one or both of the following methods: a) reset can indicate an S-NSSAI list and all PDU sessions related to the indicated S-NSSAIs are reset. b) reset can indicate a list of UE contexts and which PDU sessions for each UE context that should be reset.	available	No
		R3‑180478	NG overload control	Huawei	pCR		Yes	NoProposal 1: Confirm the transfer of relative AMF Capacity IE in NG setup response. Proposal 2: Add the transfer of relative AMF Capacity IE in AMF CONFIGURATION UPDATE message. Proposal 3: Add the overload start and overload stop message in TS 38.413. Proposal 4: Add the S-NSSAI information into the overload start message in TS 38.413. Proposal 5: Add the traffic load reduction indication for the S-NSSAI(s) into the overload start message in TS 38.413.	available	No
10.6	Intra NG-RAN mobility in RRC_INACTIVE (mode)
10.6.1	NG-RAN Area Concepts for RRC_INACTIVE Mode	R3‑180403	RRC_INACTIVE – NG-RAN aspects	Ericsson	discussion	Agreement	Yes	NoProposal 1 It is proposed to introduce NG based RAN paging and UE Context retrieval as proposed in R3-180404.	available	No
		R3‑180404	NG based UE context retrieval and RAN paging	Ericsson	draftCR		Yes	No	available	No
		R3‑180454	Consideration on RAN-Based Notification Area	Intel Coporation	draftCR	Agreement	Yes	No	available	No
		R3‑180507	Way Forward on inactive aspects	Huawei, Nokia, CATT, Qualcomm Incorporated, NEC, Deutsche Telekom, Nokia Shanghai Bell,Samsung	discussion	Decision	Yes	NoProposal 1: Define RAN Notification Area as List of Cells and List of RAN areas in Rel-15. Proposal 2: Agree that Xn should be available in RAN notification area in Rel-15. Proposal 3: Further discussion on if and how to support TAI List as RAN Notification Area in Rel-16. Proposal 4: When the UE moves out of RNA and there is no Xn between the new gNB and the last serving gNB, fall back solution will be used by the new gNB to perform establishment of a new RRC connection. Proposal 5: Further discuss whether any optimization of the scenario where the UE moves out of the RNA is needed.	available	No
		R3‑180453	Consideration on RAN-Based Notification Area	Intel Coporation	discussion	Decision	No	Yes	withdrawn	Yes
10.6.2	Assistance Information for RAN Paging and RRC_INACTIVE Handling	R3‑180092	Assistance Information for RAN Paging Priority	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal 1: include a Paging Priority IE (values 1-256) in DL NAS Transport message and all relevant NGAP initiating messages. Proposal 2: include PPI in the QoS profile to enable Paging Policy Differentiation done by NG-RAN for RRC_ inactive state to be aligned with Paging Policy Differentiation in 5GC.	available	No
		R3‑180093	Text Proposal for Paging Priority	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	No	available	No
		R3‑180140	Handling of DL signallings	CATT	draftCR		Yes	NoProposal 1: Non-UE associated DL signalling should not trigger RAN paging, while the UE associated DL signalling may trigger RAN paging procedure. Proposal 2: Upon receiving the NG connection release command from AMF, gNB could release the resources related to the NG connection without triggering RAN paging. Proposal 3: If the paged UE accesses from the anchor gNB, the anchor shall send corresponding response message to AMF to indicate the DL signalling has been successfully handled. Proposal 4: If the paged UE accesses from the gNB other than the anchor, the anchor shall send corresponding failure message to AMF with a specific cause value, e.g. “UE context transfer” , AMF may resend the DL signalling to the new gNB after the path switch procedure triggered by the new gNB is completed. Proposal 5: If RAN paging is triggered by DL class 1 signalling and the RAN paging is failed, the RAN node shall initiate the UE context release procedure, and may response failure to the DL signalling before the NG connection release. Proposal 6: Discuss and agree the stage 2 TP as in the section 5 below. Proposal 7: Discuss and agree the stage 3 TP in [3].	available	No
		R3‑180141	TP for 38.413 on DL signalling handling	CATT	pCR		Yes	NoProposal 4: If the paged UE accesses from the gNB other than the anchor, the anchor shall send corresponding failure message to AMF with a specific cause value, e.g. “UE context transfer” , AMF may re-send the DL signalling to the new gNB after the path switch procedure triggered by the new gNB is completed.	available	No
		R3‑180155	The Presence of RRC Inactive Assistance Information	Huawei	pCR	Approval	Yes	NoProposal: change the RRC Inactive Assistance Information IE to Optional in relevant NGAP messages.	available	No
		R3‑180156	DL signalling handling in INACTIVE state	Huawei	discussion	Approval	Yes	NoProposal 1: For DL Class1 signalling triggered RAN paging, if the UE responds in the anchor gNB, the anchor gNB could initiate corresponding Uu procedure for the DL signalling, and send successful response to AMF. Proposal 2: For Non AMF Initiated UE Context Release DL class 1 signalling triggered RAN paging, if the UE responds paging in a new gNB, the anchor gNB could indicate a failure response to the AMF with an appropriate cause such as “UE context transfer in INACTIVE state”. Proposal 3: If AMF Initiated UE Context Release Request is received for RRC_INACTIVE UEs, RAN paging should be initiated to avoid potential UE state mismatch and implicit detachment. Proposal 4: For AMF Initiated UE Context Release Request triggered RAN paging, if the UE responds paging in a new gNB, the anchor gNB could indicate a release indication in Retrieve Context Response message to the new gNB and respond AMF with UE Context Release Complete. Proposal 5: For DL NAS PDU triggered RAN paging, if the UE responds paging in anchor gNB, the anchor gNB could send the NAS PDU to the UE. Proposal 6: For DL NAS PDU triggered RAN paging, if the UE responds paging in a new gNB, the anchor gNB could send the NAS PDU back to the AMF via NAS NON DELIVERY INDICATION message.	available	No
		R3‑180205	Stage 2 CR for DL signalling handling in INACTIVE state	Huawei	draftCR	Approval	Yes	No	available	No
		R3‑180269	Further consideration on RRC Inactive Assistance Information	LG Electronics	pCR		Yes	NoProposal 1: The inclusion of the RRC Inactive Assistance information IE in Initial Context Setup Request, Handover Request, and Path Switch Request Acknowledge message should be optional field in TS 38.413. Proposal 2: It is proposed to agree the text proposal in the appendix of this contribution.	available	No
10.6.3	NG-RAN Paging	R3‑180094	Text Proposal for Xn Assistance Data for RAN Paging	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	NoProposal 1: agree the following Text Proposal to remove the FFS on Xn Assistance Data for Paging IE and include only the Paging Attempt Information IE.	available	No
		R3‑180106	RAN Paging Handling	Qualcomm Incorporated	discussion	Discussion	Yes	NoProposal 1: RAN Paging failure handling of DL user plane data: DL data is discarded. the NG-RAN node may keep the N2 connection active or initiate the N2 connection release procedure based on local configuration in NG-RAN. Proposal 2: A Unified mechanism for DL signalling from AMF (includes DL class 1 Signalling and DL NAS PDU) triggered RAN paging: old NG-RAN responds to AMF with failure cause: UE context transfer, AMF re-starts the procedure after Path switch to Serving NG-RAN. Proposal 3: RAN Paging failure handling of DL NAS PDU: RAN node shall initiate the NAS signalling connection release procedure to move the UE to CM-IDLE state and indicate to the AMF NAS NON DELIVERY INDICATION with non-delivered NAS PDU contained. Proposal 4: RAN Paging failure handling of DL class 1 Message: RAN node shall initiate the N2 connection release procedure to move the UE to CM-IDLE state and indicate to the AMF with failure cause Proposal 5: For UE context release command triggered RAN paging, UE context release can be indicated as a cause in Xn: Retrieve UE context response message to notify serving NG-RAN release UE after context retrieval. Proposal 6: Unified procedure for UE context release command triggered RAN Paging for normal case and failure case: Old NG-RAN responds with UE context release complete to AMF before receiving retrieve UE context request from new NG-RAN Proposal 7: when UE in RRC INACTIVE, if RAN has received Location reporting control from AMF with reporting type indication single stand-alone report, the RAN shall perform RAN Paging before report the location to AMF, If reporting type indicating continuously reporting whenever the UE changes cell, the RAN shall send a Location Report message to AMF including UE’s last known location with time stamp.	available	No
		R3‑180142	Content of RAN Paging	CATT	pCR		Yes	NoProposal 1: It’s essential to prioritize RAN paging to guarantee the high priority services in case of massive UEs are under paging. Proposal 2: The serving gNB will generate the paging priority for RAN paging, and this will be provided to the neighbor gNBs in the RAN paging message. Proposal 3: The gNBs nearby should apply the same/similar paging policy. Proposal 4: Remove the IE Assistance Data for Paging from RAN Paging. Proposal 5: Discuss and agree the stage 3 TP for RAN paging in section 5.	available	No
		R3‑180157	RAN Paging Priority handling	Huawei	pCR	Approval	Yes	NoProposal 1: It is proposed to remove the FFS for RAN paging priority IE in XnAP spec. Proposal 2: It is proposed to include service priority in all relevant NGAP messages, which may include: - PDU SESSION RESOURCE SETUP REQUEST - PDU SESSION RESOU RCE RELEASE COMMAND - PDU SESSION RESOURCE MODIFY REQUEST - UE CONTEXT RELEASE COMMAND - UE CONTEXT MODIFICATION REQUEST - DOWNLINK NAS TRANSPORT	available	No
		R3‑180158	Text proposals for NGAP for RAN Paging Priority handling	Huawei	pCR	Approval	Yes	No	available	No
10.6.4	UE Context Transfer	R3‑180159	Periodic RNA update without anchor gNB relocation	Huawei	discussion	Approval	Yes	NoProposal 1: It is proposed RAN3 to capture the procedure of periodic RNAU without anchor relocation in stage 2 spec	available	No
		R3‑180206	Stage 2 CR for Periodic RNA update without anchor gNB relocation	Huawei	draftCR	Approval	Yes	No	available	No
		R3‑180217	On the definition of RNA and design of the RRC-INACTIVE feature	Qualcomm Incorporated	discussion	Discussion	Yes	NoProposal 1: Operation in larger areas with context kept in RAN, and without strict Xn support requirement, should be the object of further study (with target release FFS). For RRC-INACTIVE, it should be assumed that the RNA has Xn support in the normal case.	available	No
		R3‑180501	Use case for NG Paging Relay and NG context fetch ?	Nokia, Nokia Shanghai Bell	discussion	Approval	Yes	NoProposal 1: Not introduce NG Context Fetch and NG Paging Relay in release 15. However, to address the questions of some operators, it is proposed to for release 16: Proposal 2: Discuss how to conduct the study of use case 2 (i.e. the case of UEs which have relaxed CP latency requirement and have a low Tx/speed ratio in order to reduce their radio signalling compared to idle mode) in release 16 i.e. as part of a separate WID/TEI16? Proposal 3: at least include in the above release 16 study and compare the 4 candidate solutions mentioned in this paper for addressing the use case 2.	available	No
		R3‑180506	Introduction of Retrieve UE Context messages	Huawei	pCR	Approval	Yes	No	available	No		R3‑180160
		R3‑180160	Introduction of Retrieve UE Context messages	Huawei	pCR	Approval	Yes	Yes	revised	No	R3‑180506
10.6.5	Others	R3‑180046	CN Area Update in Inactive State	ZTE	discussion		Yes	NoProposal 1: For the AMF change with Xn Interface scenario, the TgNB shall not send RRCconnectionresume Msg to the UE before the TAMF gets the UE NAS context, even though TgNB can get the UE AS context from the SgNB over Xn. Proposal 2: RAN2/3 should discuss the CN Area Update procedure in INACTIVE State for the AMF change with Xn interface scenario. Proposal 3: If the TgNB cannot connect to the SAMF, as baseline it can respond to the RRCConnectionresumerequest with RRCConnectionSetup message directly, and the UE should indicate upper layer upon receiving RRCConnectionSetup message. Proposal 4: For the scenario of AMF change with Xn interface, to take the CN update procedure as shown in Figure 5 as enhancement. Proposal 5: To ask RAN2 to include the 5G-GUTI in the RRCConnectionresumerequest message. Proposal 6: For the scenario of AMF change without Xn interface, to take the CN update procedure as shown in the Figure 6 as enhancement.	available	No
		R3‑180252	Stage 2 TP on RRC Inactive Transition Report	Samsung	draftCR	Approval	Yes	NoProposal1: the exiting procedure is reused to support the transition report initiation and cancellation: - Initial UE Context Setup procedure, UE Context Modification procedure, - Path Switch Request procedure, NG Handover Request procedure. Proposal2: A new class2 message is needed for RRC_inactive transtion report. Proposal3: Define stage2 to reflect the SA2 agreement.	available	No
		R3‑180253	Stage 3 TP on RRC Inactive Transition Report	Samsung	pCR	Approval	Yes	No	available	No
		R3‑180271	Stage 3 TP on CN selective awareness for RRC-INACTIVE state	LG Electronics	pCR		Yes	NoProposal 1: RRC state reporting procedure should be defined to support the CN selective awareness for the RRC state transition. Proposal 2: It is proposed to agree the text proposal in the appendix of this contribution.	available	No
		R3‑180273	Stage 2 TP on CN selective awareness for RRC-INACTIVE state	LG Electronics	draftCR		Yes	NoProposal 1: It is proposed to agree the text proposal in the appendix of this contribution.	available	No
		R3‑180405	On Coexistence between RRC inactive and dual connectivity	Ericsson	pCR		Yes	NoIt is proposed to further discuss this topic in future meeting and to liaise back to SA2 our findings (see R3-180407). It is also proposed to discuss the TP for 38.423 provided in the Annex, which covers a new class 2 procedure to indicate activity (on a per UE and a per DRB level) and additions to the MN initiated S-NG-RAN node Modification procedure.	available	No
		R3‑180406	Support of RRC_INACTIVE and MR-DC with 5GC	Ericsson	draftCR		Yes	No	available	No
		R3‑180407	[DRAFT] reply LS on coexistence between RRC inactive and dual connectivity (To: SA2, RAN2, Cc:-)	Ericsson	LS out		Yes	No	available	No
10.7	Void
10.8	Dual Connectivity Options
10.8.1	Void
10.8.2	E-UTRA-NR DC via 5G-CN where the E-UTRA is the master
10.8.2.1	General	R3‑180012	Further Consideration on SN Release	ZTE	discussion		Yes	NoProposal 1: MN is not allowed to refuse the SN Release Required message from SN in Release 15. Proposal 2a: In case MN has already initiated the SN change and configured the target SN, then the source SN shall always follow MN’s release request based on proper cause value, e.g. SCG mobility. Proposal 2b: In case MN has already initiated the Inter-MN handover with SN change or MN to eNB Change, then the source SN shall always follow MN’s release request based on proper cause value, e.g. MCG mobility. Proposal 3: Upon receiving SN Release Reject message, MN shall not refuse the SN Change Required message in following certain period of time per own implementation.	available	No
		R3‑180013	Correction of SN Release in TS37.340	ZTE	draftCR		Yes	No	available	No
		R3‑180329	List of FFSs for MR-DC (For Information)	ZTE	other		Yes	No	available	No
		R3‑180368	Cause values for QoS flow offloading	Huawei	pCR		Yes	NoProposal: The above list of cause values should be included for each rejected QoS flow.	available	No
		R3‑180369	Support of SN counter check	Huawei	pCR		Yes	No	available	No
		R3‑180374	Support of QoS and slice for MR-DC with 5GC Alt1	Huawei	pCR		Yes	NoProposal: Capture one of the two alternatives in TS 38.423.	available	No
		R3‑180375	Support of QoS and slice for MR-DC with 5GC Alt2	Huawei	pCR		Yes	No	available	No
10.8.2.2	Stage 2	R3‑180014	Further Consideration on MR-DC Mobility Procedures	ZTE	discussion		Yes	NoProposal 1: “EN-DC to gNB change” with single RRC reconfiguration and full configuration can be supported in this version of the protocol, following the normal inter-system HO procedure. Proposal 2: “Inter-RAT MN to ng-eNB/gNB Change” with single RRC reconfiguration and full configuration, i.e. from NGEN-DC to gNB or from NE-DC to ng-eNB Change can be supported in this version of the protocol. Proposal 3: gNB to EN-DC change with single RRC reconfiguration and full configuration can be supported in this version of the protocol. Proposal 4: Inter-RAT ng-eNB/gNB to MN Change with single RRC reconfiguration and full configuration, i.e. from gNB to NGEN-DC or from ng-eNB to NE-DC Change can be supported in this version of the protocol.	available	No
		R3‑180025	Correction of MR-DC Combined Mobility in TS37.340	ZTE	draftCR		Yes	No	available	No
		R3‑180026	Further Discussion on Mode Change between Single and Two NG-U tunnels	ZTE	discussion		Yes	NoProposal 1: Both MN and SN may trigger the change of PDU session between single and two NG-U tunnel terminations at the NG-RAN. Proposal 2: MN decides whether the secondary NG-U tunnels are to be setup or released.	available	No
		R3‑180027	Correction of Mode Change between Single and Two NG-U tunnels in TS37.340	ZTE	draftCR		Yes	No	available	No
		R3‑180029	Correction of Split SRB configuration in TS37.340	ZTE	draftCR		No	No	reserved	No
10.8.2.3	Control of Various NGEN-DC DRB Options	R3‑180034	Further Discussion on QoS Flow to DRB Mapping in MR-DC@5GC	ZTE	discussion		Yes	NoProposal 1: During the DRB initial setup process (no data forwarding is needed), MN semi-statically allocates a set of DRB ids to be used by SN, and MN/SN decides the mapping of concerned QoS Flows on MCG/SCG side independently. Proposal 2: During DRB level lossless offloading, MN/SN should inform the peer side about the “original mapping info of concerned QoS Flows on MCG/SCG side” (so peer side can follow that mapping for lossless purpose), and the receiving SN/MN can consequently allocate and feedback the corresponding DL/UL data forwarding GTP TEID to the initiating node. Proposal 3: During QoS Flow level offloading (may be loss), MN/SN needs not to inform the peer side about the “original mapping info of concerned QoS Flows on MCG/SCG side” (so peer side performs the local remapping independently), but the receiving SN/MN can still consequently allocate and feedback the corresponding DL/UL data forwarding GTP TEID to the initiating node. Proposal 4: MN can inform SN the DL GTP TEID info for each SN terminated split bearer in step 5: SN reconfiguration Complete message.	available	No
		R3‑180035	Further Discussion and pCR on MR-DC@5GC Specific Xn Messages Structures	ZTE	discussion		Yes	NoProposal 1a: In order to reflect the “one-to-many mapping” relation between one PDU Session and DRBs of different types, the QoS Flow level info for each QoS Flow of each PDU Session should be included in MR-DC specific Xn messages e.g. “S-NODE ADDITION REQUEST/ACKNOWLEDGE” message. Proposal 1b: The existing IE “QoS Flow Level QoS Parameters” should replace the original fake IE “PDU session Level QoS Parameters”, associated to each QFI in each PDU Session. Proposal 2a: For DRB initial setup, MN can only decide the mapping between locally anchored QoS Flows and DRBs on MN side, meanwhile telling SN which QoS Flows are to be offloaded to SN side, as well as their associated DRB bearer type. Proposal 2b: SN may need to tell MN the mapping outcome of locally anchored QoS Flows and DRBs on SN side. Proposal 3a: To update the message structure of “S-NODE ADDITION REQUEST/ACKNOWLEDGE” firstly, based on above principles. Proposal 3b: Once P3a is agreed and consolidated, similar changes will be applied for other MR-DC@5GC specific Xn messages in TS38.423.	available	No
		R3‑180036	Correction of QoS Flow to DRB Mapping in MR-DC@5GC in TS37.340	ZTE	draftCR		Yes	No	available	No
		R3‑180104	Bearer and flow offloading for MR-DC with 5GC	LG Electronics, KT Corp.	discussion		Yes	NoProposal 1): Both DRB level and Flow level offloading should be supported for MR-DC with 5GC. Proposal 2): DRB level offloading should be supported for both MN terminated bearers and SN terminated bearers, for which the DRB level configuration information of the concerned flows in MN should be transmitted to SN. Proposal 3): Flow level lossless offloading should be supported, for which Xn signaling enhancement is needed.	available	No
		R3‑180259	Dual Connectivity establishment in new QoS framework	Samsung	pCR	Approval	Yes	NoProposal 1: SN may re-map an offloaded QoS flows to another (potentially new) DRB. Proposal 2: MN should have a freedom in deciding which individual QoS flows it wants to offload to SN (i.e. only certain QoS flows from a DRB could be moved to SN). Same applies to SN and SCG split bearers. Proposal 3: For SCG split bearer, MN allocates Xn tunneling for DL data transmission according to new mapping and includes the information in the S-NODE RECONFIGURATION COMPLETE. Proposal 4: For SCG split bearer, new mapping information is added in the S-NODE ADDITION REQUEST ACK message and S-NODE MODIFICATION REQUEST ACK message.	available	No
		R3‑180408	PDU session split at UPF	Ericsson	pCR		Yes	NoThe summary of Text Proposal: • In PDU session resource setup request/modify request, add the additional GTP-U tunnel information for splitting PDU session in UPF for uplink. • In PDU session resource setup response/modify response, add information of which QoS flows in the PDU session are setup in SN, also include the additional GTP-U tunnel information for downlink. Proposal 1: RAN3 to discuss and agree the proposed TP for supporting the PDU session splits at UPF.	available	No
		R3‑180496	PDU Session, QoS flow and DRB control for NG-RAN DC	Ericsson	pCR		Yes	NoProposal 1 It is proposed to restructure DC message to enable configuration of mulitple DC bearers in a single message Proposal 2 It is proposed to re-structure Addition/Modification message along SDAP location (MN or SN) Stage 3 aspects for XnAP are covered in the Annex of this paper, covering the Addition aspects only. It is proposed to agree on the TP provided.	available	No
10.8.2.4	Control of NGEN-DC SRB Options	R3‑180114	Feedback of MCG split SRB	Qualcomm Incorporated	pCR	Approval	Yes	No	available	No
		R3‑180497	Bearer harmonization in NG-RAN - XnAP TP	Ericsson	pCR		No	No	reserved	No
10.8.2.5	Change between NGEN-DC DRB Options (Bearer Type Change)	R3‑180037	Further Discussion and Stage2 pCR for SN Initiated SN Modification Procedure	ZTE	discussion		Yes	NoProposal 1: When the info of DRB (SCG split bearer) No. and QoS Flow mapping is updated on SN side, SN may need to actively inform MN about that change with SN initiated modification procedure. Proposal 2: SN is able to trigger one step direct bearer type change from SCG bearer to SCG split bearer with SN initiated SN modification procedure alone, but not direct bearer type change from SCG split bearer to SCG bearer. Proposal 3: New IE “PDU sessions To Be Modified List” should be included in S-NODE MODIFICATION REQUIRED message, and new IE “M-NG-RAN node GTP Tunnel Endpoint List” should be also included in S-NODE MODIFICATION CONFIRM message. Proposal 4: To endorse the TPs in Annex below.	available	No
		R3‑180038	Stage3 pCR for SN Initiated SN Modification Procedure	ZTE	pCR		Yes	No	available	No
		R3‑180209	Bearer type decision and change for NGEN-DC DRB options	LG Electronics, KT Corp.	draftCR		Yes	No	available	No
10.8.2.6	Data Forwarding	R3‑180201	Discussion on data forwarding when DC offloading	CATT	discussion		Yes	NoProposal 1: Data forwarding for fresh data through PDU session tunnel during some QoS flows of DRB offloading. Proposal 2: Data forwarding for PDCP SDU(SDAP PDU) with SDAP header through PDU session tunnel during some QoS flows of DRB offloading. Proposal 3: PDCP SDUs with SN and PDCP SDU(SDAP PDU) without SDAP header is transmitted through DRB in the source node during some QoS flows of DRB offloading. Proposal 4: Data forwarding mechanism may follow above P1/P2/P3 when all the QoS flows of the DRB offloading and the DRB is kept in source node. Proposal 5: Data forwarding mechanism may follow Xn HO when all the QoS flows of the DRB offloading and the DRB is released in source node.	available	No
10.8.2.7	UE AMBR	R3‑180210	Issues on AMBR for Option 7 family	LG Electronics	draftCR		Yes	NoProposal 1): To adopt the same principles of EN-DC to MR-DC on UE-AMBR. Proposal 2): MN decides the split of session AMBR and indicates the portion of session AMBR to be respected by the SN. Proposal 3): The split result of session AMBR for MN and SN is not indicated to AMF/SMF/UPF. Proposal 4): To adopt the Stage 2 change for TS 37.340.	available	No
		R3‑180052	A new AMBR solution for MR-DC	Nokia, Nokia Shanghai Bell	discussion	Discussion	Yes	NoProposal 1: Since only the solution based on the exchange of the consumed throughput enables solving both problems identified in the past, it should be enabled in MR-DC. Proposal 2: The reporting of the consumed throughput should be based on the user plane signaling in a dedicated tunnel. Proposal 3: The above solution should be applied to EN-DC, too.	available	No
10.8.2.8	Others	R3‑180313	Further consideration on mechanism for simultaneously releasing multiple UE contexts	NTT DOCOMO INC.	discussion	Approval	Yes	NoProposal 1: It is proposed to support the partial reset in the X2/Xn Reset procedure like the S1/F1 Reset procedure.	available	No
		R3‑180376	Discussions on Energy Efficiency leftovers	Huawei, Qualcomm Incorporated	discussion	Approval	Yes	No	available	No
10.8.3	Void
10.8.4	NR-E-UTRA DC via 5G-CN where the NR is the master
10.8.5	Others	R3‑180044	Correction on S1AP for the secondary RAT data volume reporting	ZTE	draftCR		Yes	No	available	No
		R3‑180045	Correction on X2AP for the secondary RAT data volume reporting	ZTE	draftCR		Yes	No	available	No
		R3‑180411	Keeping a stable PDCP anchor	Ericsson	discussion	Agreement	Yes	No	available	No
		R3‑180412	Keeping a stable PDCP anchor – draft CR for 37.340	Ericsson	draftCR		Yes	No	available	No
		R3‑180413	Support for keeping a stable PDCP anchor at HO and inter-node resume	Ericsson	draftCR		Yes	No	available	No
		R3‑180414	Support for keeping a stable PDCP anchor at Path Switch	Ericsson	draftCR		Yes	No	available	No
		R3‑180415	Support for keeping a stable PDCP anchor at HO	Ericsson	draftCR		Yes	No	available	No
		R3‑180416	Keeping a stable PDCP anchor – TP for 38.413	Ericsson	pCR		Yes	No	available	No
		R3‑180417	Support for keeping a stable PDCP anchor at bearer type change or MN change or SN change	Ericsson	draftCR		Yes	No	available	No
		R3‑180418	Support for keeping a stable PDCP anchor at HO and inter-node resume	Ericsson	draftCR		Yes	No	available	No
10.9	User Plane	R3‑180103	On open issues in TS 38.425	Qualcomm Incorporated	discussion	Discussion	Yes	No	available	No
		R3‑180212	Corrections to NR UP protocol	Qualcomm Incorporated	draftCR	Approval	Yes	No	available	No
		R3‑180211	Corrections to UP protocol	Qualcomm UK Ltd	draftCR	Approval	No	Yes	withdrawn	Yes
10.9.1	Fast Retransmission	R3‑180131	Further discussion on data retransmission indication	ZTE Corporation	draftCR		Yes	No	available	No
10.9.2	PDCP Duplication	R3‑180135	Consideration on fast duplication activation and deactivation over F1	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180238	PDCP duplication activation and deactivation over F1	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180239	PDCP duplication support over X2	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180305	Removal of unnecessary limitation on discarding	NTT DOCOMO INC.	discussion		Yes	No	available	No
		R3‑180306	CR on Removal of unnecessary limitation on discarding	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180342	pCR to 38.473 on PDCP duplication	Huawei	other	Approval	Yes	No	available	No
		R3‑180455	Flow Control enhancements for uplink PDCP duplication	Intel Corporation	discussion	Decision	Yes	No	available	No
		R3‑180456	Flow Control enhancements for uplink PDCP duplication	Intel Corporation	draftCR	Agreement	Yes	No	available	No
10.9.3	Centralized Retransmission	R3‑180039	Consideration on Multi-Connectivity with Dual/Multiple gNB-DUs	ZTE	discussion		Yes	No	available	No
		R3‑180040	Correction of Multi-Connectivity with Dual/Multiple gNB-DUs in TS38.401	ZTE	draftCR		Yes	No	available	No
		R3‑180240	Radio link outage/resume for DL and UL	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180314	Further consideration on how to acquire status of re-transmitted packets	NTT DOCOMO INC.	discussion		Yes	No	available	No
		R3‑180315	CR on how to acquire status of re-transmitted packets	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180316	Further consideration on data existence indication for split bearer	NTT DOCOMO INC.	discussion	Approval	Yes	No	available	No
10.9.4	Others	R3‑180254	Rapporteur’s update to TS38.425v100	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180295	Spare field and future extension	NEC	discussion	Decision	Yes	No	available	No
		R3‑180317	CR on data existence indication for split bearer	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180457	Flow Control enhancement for DRX	Intel Corporation	discussion	Decision	Yes	No	available	No
		R3‑180458	Flow Control enhancement for DRX	Intel Corporation	draftCR	Agreement	Yes	No	available	No
10.10	High layer functional split
10.10.1	General	R3‑180139	NW slicing for high layer functional split	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180164	TP for 38.401 BL on UE Reconfiguration Completion procedure	CATT	draftCR		Yes	No	available	No
		R3‑180287	Discussion on UE Attached Indication procedure	LG Electronics	discussion		Yes	No	available	No
		R3‑180357	Further discussions on the content of serving cell info	Huawei	discussion	Approval	Yes	No	available	No
		R3‑180419	F1 TNL associations	Ericsson	other		Yes	No	available	No
		R3‑180420	TP for F1 TNL associations	Ericsson	other		Yes	No	available	No
		R3‑180421	Cells information from gNB-DU to gNB-CU	Ericsson	other		Yes	No	available	No
		R3‑180463	On multiple SCTP associations for F1-C	Intel Corporation	draftCR	Agreement	Yes	No	available	No
10.10.2	System Information	R3‑180233	Issues on system information management function	LG Electronics, KT Corp.	draftCR		Yes	No	available	No
		R3‑180347	System information delivery over F1 interface	Huawei	discussion	Decision	Yes	No	available	No
		R3‑180348	CR to BL 38.473 on System information delivery over F1 interface	Huawei	other	Approval	Yes	No	available	No
		R3‑180422	System information delivery	Ericsson	other		Yes	No	available	No
		R3‑180423	System information exchange over F1	Ericsson	other		Yes	No	available	No
10.10.3	UE Initial Access, State Transitions	R3‑180122	Security issue for UE Initial Access	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180125	Corrections for RRC Message Transfer for TS38.473	ZTE Corporation	draftCR		Yes	No	available	No
		R3‑180126	Left issues on Inactive UE over F1 interface	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180349	Further discussion on RRC reestablishment	Huawei	other	Approval	Yes	No	available	No
		R3‑180424	Corrections to Inactive to Other State procedures over F1	Ericsson	other		Yes	No	available	No
		R3‑180508	Further clarification on transition from RRC-INACTIVE to other RRC states (TP to BL CR for 38.401)	LG Electronics	other		Yes	No	available	No
10.10.4	Mobility Aspects	R3‑180134	Discussion on Inter-DU Mobility with Dual Connectivity	ZTE Corporation	draftCR		Yes	No	available	No
		R3‑180191	TP on support of delta configuration during handover procedure	CATT	draftCR		Yes	No	available	No
		R3‑180241	UE attached indication for mobility procedure	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180242	Stage 2 TP for TS38.470 on UE attached indication for mobility procedure	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180243	Stage 3 TP for TS38.473 on UE attached indication for mobility procedure	Samsung	draftCR	Approval	Yes	No	available	No
10.10.5	Paging	R3‑180136	Left FFS on paging over F1	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180460	F1-AP Paging Procedure and Signaling	Intel Corporation	draftCR	Agreement	Yes	No	available	No
		R3‑180346	pCR to 38.473 on Paging delivery over F1	Huawei	other	Approval	Yes	No	available	No
10.10.6	Void
10.10.7	UE Context Management	R3‑180123	QoS information transfer over F1 interface	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180124	Update on QoS information transfer for TS38.473	ZTE Corporation	draftCR		Yes	No	available	No
		R3‑180179	Discussion on UE Context Management procedure	CATT	draftCR		Yes	No	available	No
		R3‑180180	TP for TS 38.473 on UE Context Management procedure	CATT	draftCR		Yes	No	available	No
		R3‑180188	QoS handling for F1	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180189	TP of QoS handling for F1 (TS 38.473)	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180190	User inactivity monitoring	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180234	QoS aspect in UE context management function	LG Electronics, KT Corp.	draftCR		Yes	No	available	No
		R3‑180235	Stage 3 on QoS aspect in UE context management function	LG Electronics, KT Corp.	draftCR		Yes	No	available	No
		R3‑180244	UE context management update considering parameters over X2 for EN-DC	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180285	User inactivity monitoring in CU-DU architecture	Samsung, KT	draftCR	Approval	Yes	No	available	No
		R3‑180286	TP for TS 38.473 on user inactivity monitoring	Samsung, KT	draftCR	Approval	Yes	No	available	No
		R3‑180300	RLC Mode indication in F1AP	NEC	draftCR	Decision	Yes	No	available	No
		R3‑180330	QoS management over F1	CMCC	discussion	Decision	Yes	No	available	No
		R3‑180343	Further discussions on QoS info transfer over F1	Huawei	other	Approval	Yes	No	available	No
		R3‑180344	pCR to 38.473 on QoS info transfer over F1	Huawei	other	Approval	Yes	No	available	No
		R3‑180352	Further discussions on UE context management	Huawei	discussion	Approval	Yes	No	available	No
		R3‑180355	CR to BL 38.473 on inter-gNB-DU or intra-gNB-DU handover case for SA operation	Huawei	other	Approval	Yes	No	available	No
		R3‑180356	pCR to 38.473 on the introduction of HandoverPreparationInformation for SA operation	Huawei	other	Approval	Yes	No	available	No
		R3‑180367	Further discussions on confirmation to gNB-DU about completion of RRC messages	Huawei	discussion	Decision	Yes	No	available	No
		R3‑180425	UE radio capabilities over F1	Ericsson	other		Yes	No	available	No
		R3‑180426	Cell information over F1	Ericsson	other		Yes	No	available	No
		R3‑180427	UE context Setup over the F1	Ericsson	other		Yes	No	available	No
		R3‑180428	UE Reject Indication and gNB-DU admission result	Ericsson	other		Yes	No	available	No
		R3‑180429	Further analysis on inactivity monitoring	Ericsson	other		Yes	No	available	No
		R3‑180430	Creation of signalling connection	Ericsson	other		Yes	No	available	No
		R3‑180431	RRC Container in UE Context Setup Request	Ericsson	other		Yes	No	available	No
		R3‑180432	RLC Mode indication	Ericsson	other		Yes	No	available	No
		R3‑180433	Introduction of UE Reconfiguration Complete procedure	Ericsson	discussion	Agreement	Yes	No	available	No
10.10.8	Others	R3‑180133	Discussion on Load Management over F1 interface	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180186	Load management	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180187	TP of Load management (TS 38.473)	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180245	Supplementary uplink (SUL) information for NR cells over F1	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180246	Supplementary uplink (SUL) addition and release over F1	Samsung	draftCR	Approval	Yes	No	available	No
		R3‑180294	Target Cell selection in gNB-CU for EN-DC and cell load reporting from gNB-DU	NEC	discussion	Decision	Yes	No	available	No
		R3‑180372	Load management on X2 and F1	NTT DOCOMO INC.	discussion	Approval	Yes	No	available	No		R3‑180318
		R3‑180504	Notification control over F1	Ericsson	other		Yes	No	available	No		R3‑180434
		R3‑180318	Load management on X2 and F1	NTT DOCOMO INC.	discussion	Approval	Yes	Yes	revised	No	R3‑180372
		R3‑180434	Notification control over F1	Ericsson	other		Yes	Yes	revised	No	R3‑180504
10.11	Stage 2 Updates	R3‑180290	Rapporteur cleanup for 38.401v15.0.0	NEC	draftCR	Decision	Yes	No	available	No
		R3‑180291	Baseline CR to capture remaining FFS of TS 38.401	NEC	draftCR	Decision	Yes	No	available	No
		R3‑180480	Baseline CR to TS 38.470 covering agreements of RAN3#98	Huawei	draftCR		Yes	No	available	No
		R3‑180041	Rapporteur Cleanups for TS37.340 (RAN3 Part)	ZTE	discussion		Yes	No	available	No
10.11.1	Void
10.11.2	Void
10.11.3	Void
10.11.4	TS 38.410/420 NG/Xn General aspects and principles	R3‑180095	Text Proposal for Rapporteur’s update for TS 38.410	Nokia, Nokia Shanghai Bell	pCR	Agreement	Yes	No	available	No
10.11.5	Void
10.12	Stage 3 Updates
10.12.1	TS 38.411/421 NG/Xn Layer 1	R3‑180449	TP for TS 38.411	LG Electronics	pCR		Yes	No	available	No
		R3‑180171	Rapporteur editorial updates to 38.421	CATT	pCR		Yes	No	available	No
10.12.2	TS 38.412/422 NG/Xn Signaling transport
10.12.3	Application Protocol	R3‑180481	Baseline CR to TS 38.473 covering agrements of RAN3#98	Huawei	draftCR		Yes	No	available	No
10.12.3.1	TS 38.413 NG Application Protocol (NGAP)	R3‑180096	Rapporteur update for TS 38.413	Nokia, Nokia Shanghai Bell	pCR		Yes	No	available	No
10.12.3.2	TS 38.423 Xn Application Protocol (XnAP)
10.12.3.3	Void
10.12.3.4	Void
10.12.3.5	Void
10.12.3.6	TS 38.455 NR Positioning Protocol A (NRPPa)
10.12.4	TS 38.414/424 NG/Xn Data transport	R3‑180042	Rapporteur Updates of TS 38.414 to v031	ZTE	discussion		Yes	No	available	No
10.12.5	Void
10.13	Positioning Support
10.13.1	Transport of Positioning Messages Between 5G-CN and NG-RAN Hosting E-UTRA
10.13.2	Transport of Positioning Messages Between 5G-CN and NG-RAN Hosting NR
10.13.3	NR CID and Cell Portions
10.14	LTE-NR Coexistence Aspects	R3‑180043	Correction of TS37.340 for Single Tx Hamonic Issues	ZTE	draftCR		Yes	No	available	No
10.14.1	LTE-NR Coexistence in Overlapping and Adjacent Spectrum	R3‑180016	Response LS on required information for NSA on X2.	3GPP RAN1, Nokia	LS in		Yes	No	available	No
		R3‑180224	Signalling for cell resource coordination	Nokia, Nokia Shanghai Bell, AT&T	discussion		Yes	No	available	No
		R3‑180225	E-UTRA - NR Cell Resource Coordination	Nokia, Nokia Shanghai Bell, AT&T	draftCR		Yes	No	available	No
		R3‑180226	E-UTRA - NR Cell Resource Coordination	Nokia, Nokia Shanghai Bell, AT&T	draftCR		Yes	No	available	No
		R3‑180297	NR Frequency and Time Resource Granularity	NEC	discussion	Decision	Yes	No	available	No
		R3‑180327	Discussion on backhaul signaling exchange for NR frame structure	CMCC	discussion	Decision	Yes	No	available	No
		R3‑180340	LTE-NR UL sharing in overlapping and adjacent spectrum	Huawei, Vodafone	discussion		Yes	No	available	No
		R3‑180341	Support of LTE-NR coexistence over X2	Huawei, Vodafone	draftCR		Yes	No	available	No
		R3‑180435	LTE-NR radio resource allocation coordination	Ericsson	discussion	Agreement	Yes	No	available	No
		R3‑180499	Signaling support for LTE-NR Coexistence in Overlapping and Adjacent Spectrum	AT&T	discussion	Agreement	Yes	No	available	No
10.14.2	Others	R3‑180115	LTE-NR coordination for inter-modulation issue	Qualcomm Incorporated	discussion	Discussion	Yes	No	available	No
		R3‑180216	LTE-NR coordination for inter-modulation issue	Qualcomm Incorporated	draftCR	Approval	Yes	No	available	No
		R3‑180117	LTE-NR coordination for inter-modulation issue	Qualcomm Incorporated	pCR	Approval	No	Yes	withdrawn	Yes
10.15	Others	R3‑180060	Cleanup of reference/defintions	InterDigital, Huawei	discussion	Agreement	Yes	No	available	No
		R3‑180061	Cleanup of reference/definitions for 38.410	Interdigital	pCR	Agreement	Yes	No	available	No
		R3‑180062	Cleanup of reference/definitions for 38.412	Interdigital Asia LLC	pCR	Agreement	Yes	No	available	No
		R3‑180063	Cleanup of reference/definitions for 38.413	Interdigital Asia LLC	pCR	Agreement	Yes	No	available	No
		R3‑180064	Cleanup of reference/definitions for 38.414	Interdigital Asia LLC	pCR	Agreement	Yes	No	available	No
		R3‑180065	Cleanup of reference/definitions for 38.420	Interdigital Asia LLC	pCR	Agreement	Yes	No	available	No
		R3‑180066	Cleanup of reference/definitions for 38.422	Interdigital Asia LLC	pCR	Agreement	Yes	No	available	No
		R3‑180067	Cleanup of reference/definitions for 38.423	Interdigital Asia LLC	pCR	Agreement	Yes	No	available	No
		R3‑180068	Cleanup of reference/definitions for 38.424	Interdigital Asia LLC	pCR	Agreement	Yes	No	available	No
		R3‑180069	Cleanup of reference/definitions for 38.455	Interdigital Asia LLC	pCR	Agreement	Yes	No	available	No
		R3‑180325	Discussion on RAN support of edge computing in NR	CMCC	discussion	Decision	Yes	No	available	No
11	Study on CU-DU lower layer split for New Radio SI
11.1	Functionality and CU-DU Lower Layer Split
11.2	Evaluation Criteria for Lower Layer Split Options
11.3	Feasibility of a Standardized Interface for Lower Layer Split
11.4	Others
12	Study on eNB(s) Architecture Evolution for E-UTRAN and NG-RAN SI
12.1	Potential CU-DU Functional Split for the eNB
12.2	CU-DU Interface, Functions, and Procedures	R3‑180192	Discussion on V1 leftover issues	Huawei, China Unicom	pCR		Yes	No	available	No
12.3	Others	R3‑180303	Feature supporting over V1	Huawei	discussion	Agreement	Yes	No	available	No
13	Further NB-IoT enhancements (RAN1-led) WI
13.1	Early data transmission
13.2	UE differentiation
13.3	Others
14	Even further enhanced MTC for LTE (RAN1-led) WI
14.1	Early data transmission
14.2	Others
15	UE positioning accuracy enhancements for LTE (RAN2-led) WI
15.1	Assistance Data Broadcast Procedure
15.2	Information to Be Signaled over LPPa
15.3	Others
18	Other WI/SIs with impact on RAN3
18.1	Rapporteur SID summarize
18.2	Band completion
18.3	Others
19	Void
20	Enhancing LTE CA Utilization WI
21	Signalling reduction to enable light connection for LTE (RAN2-led) WI
23	WI on Separation of CP and UP for Split Option 2
23.1	E1 General Principles	R3‑180505	Time plan for WI on separation of CP and UP for split option 2	Ericsson, KT, Vodafone	discussion	Agreement	Yes	No	available	No		R3‑180436
		R3‑180436	Time plan for WI on separation of CP and UP for split option 2	Ericsson	discussion	Agreement	Yes	Yes	revised	No	R3‑180505
23.2	E1 Signaling Transport
23.3	E1 Application Protocol (E1AP)	R3‑180127	Discussion on Bearer Management over E1 interface	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180128	Further consideration on E1 interface setup	ZTE Corporation	discussion		Yes	No	available	No
23.4	Security Aspects	R3‑180165	AS Security handling	Nokia, Nokia Shanghai Bell	discussion		Yes	No	available	No
		R3‑180260	Security Aspects for CU-UP	Samsung	discussion	Approval	Yes	No	available	No
		R3‑180323	Security Aspects of CP-UP Split Architecture	Vodafone Group Plc	discussion	Decision	Yes	No	available	No
		R3‑180324	[DRAFT]LS on security issue for CP-UP separation	Samsung R&D Institute UK	LS out	Approval	Yes	No	available	No
		R3‑180350	Discussions on Security handling for CP-UP separation	Huawei	discussion	Decision	Yes	No	available	No
		R3‑180351	Draft LS to SA3 on open issues of security handling for CP-UP separation v03	Huawei	LS out	Approval	Yes	No	available	No
		R3‑180437	Security for split CU	Ericsson	discussion	Agreement	Yes	No	available	No
		R3‑180438	[DRAFT] LS on security for CU-CP/UP separation	Ericsson	LS out		Yes	No	available	No
		R3‑180129	Discussion on security key generation over E1 interface	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180130	Draft LS on security key generation for CP/UP separation	ZTE Corporation	LS out		Yes	No	available	No
31	Corrections to Rel-15 and TEI15
31.1	3G
31.2	LTE.
31.3	EN-DC
31.3.1	Essential Corrections	R3‑180274	Clarification on resource coordination	NTT DOCOMO INC.	discussion		Yes	No	available	No
		R3‑180275	CR for Clarification on resource coordination	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180278	Neccesary addition on resource coodination	NTT DOCOMO INC.	discussion		Yes	No	available	No
		R3‑180279	CR on neccesary addition on resource coodination	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180332	Considerations on HRL	Huawei	discussion		Yes	No	available	No
		R3‑180333	Clarification on HRL for EN-DC	Huawei	draftCR		Yes	No	available	No
		R3‑180334	Clarification on HRL for EN-DC	Huawei	draftCR		Yes	No	available	No
		R3‑180335	Clarification on HRL for EN-DC	Huawei	draftCR		Yes	No	available	No
		R3‑180336	Clarification on HRL for EN-DC	Huawei	pCR		Yes	No	available	No
		R3‑180441	On Coexistence between suspend and dual connectivity	Ericsson	discussion	Agreement	Yes	No	available	No
		R3‑180442	Support of suspend in EN-DC	Ericsson	draftCR		Yes	No	available	No
		R3‑180443	Support of suspend in EN-DC	Ericsson	draftCR		Yes	No	available	No
		R3‑180444	[DRAFT] reply LS on Coexistence between suspend and dual connectivity	Ericsson	LS out		Yes	No	available	No
		R3‑180166	Discussion on SgNB initiated SgNB Modification procedure	CATT	discussion		Yes	No	available	No
		R3‑180167	Correction on SgNB initiated SgNB Modification procedure	CATT	draftCR		Yes	No	available	No
		R3‑180168	Correction on SgNB initiated SgNB Modification procedure	CATT	draftCR		Yes	No	available	No
		R3‑180500	Handling of remaining stage 3 FFSs for NSA ANR	Nokia, Nokia Shanghai Bell	other		Yes	No	available	No		R3‑180220
		R3‑180218	Stage 2 corrections for NSA ANR	Nokia, Nokia Shanghai Bell	discussion		Yes	No	available	No
		R3‑180219	Corrections on NSA ANR	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180339	Further considerations on secondary RAT data volume reporting	Huawei	discussion		Yes	No	available	No
		R3‑180161	RRC Reconfiguration Complete Indication to DU	CATT	discussion		Yes	No	available	No
		R3‑180162	Support of UE Reconfiguration Complete Message	CATT	draftCR		Yes	No	available	No
		R3‑180163	Support of UE Reconfiguration Complete Message	CATT	draftCR		Yes	No	available	No
		R3‑180053	Correction of the UE ID in the RRC Transfer	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	No	available	No
		R3‑180483	Criticality for UE context management	Huawei	discussion		Yes	No	available	No
		R3‑180484	Criticality for UE context management	Huawei	draftCR		Yes	No	available	No
		R3‑180487	Adding cause in context modification required	Huawei	discussion		Yes	No	available	No
		R3‑180488	Adding cause in context modification required	Huawei	draftCR		Yes	No	available	No
		R3‑180353	Further discussions on UE context management related with EN-DC operation	Huawei	discussion	Approval	Yes	No	available	No
		R3‑180354	CR to 38.473 on UE context management procedure related with EN-DC operation	Huawei	draftCR	Decision	Yes	No	available	No
		R3‑180183	Consideration on UE context management procedures for EN-DC	CATT	discussion		Yes	No	available	No
		R3‑180184	Correction on UE context management procedures for EN-DC	CATT	draftCR		Yes	No	available	No
		R3‑180172	Corrections on UE Context Setup procedure	Nokia, Nokia Shanghai Bell	discussion		Yes	No	available	No
		R3‑180173	Corrections on UE Context Setup procedure	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180308	Applicability on AMBR for F1	NTT DOCOMO INC.	discussion		Yes	No	available	No
		R3‑180309	CR for applicability on AMBR for F1	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180448	Correction on UE-AMBR for EN-DC	LG Electronics	draftCR		Yes	No	available	No
		R3‑180345	CR to 38.473 on the introduction of UE AMBR over F1	Huawei	draftCR	Approval	Yes	No	available	No
		R3‑180409	Handling of UE UL-AMBR	Ericsson	discussion	Agreement	Yes	No	available	No
		R3‑180410	Handling of UE UL-AMBR	Ericsson	draftCR		Yes	No	available	No
		R3‑180485	Transaction ID in F1AP	Huawei	discussion		Yes	No	available	No
		R3‑180486	Transaction ID in F1AP	Huawei	draftCR		Yes	No	available	No
		R3‑180207	Criticality Diagnostics for Transaction ID	Nokia, Nokia Shanghai Bell	discussion		Yes	No	available	No
		R3‑180208	Criticality Diagnostics for Transaction ID	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180445	Correction on Transaction ID	Ericsson	discussion	Agreement	Yes	No	available	No
		R3‑180446	CR for correction on Transaction ID	Ericsson	draftCR		Yes	No	available	No
		R3‑180482	Enhanced ASN.1 coding	Huawei	draftCR		Yes	No	available	No
		R3‑180178	Correction on the definition of ProtocolIE-ContainerList	Nokia, Nokia Shanghai Bell	discussion		Yes	No	available	No
		R3‑180185	Correction on the definition of ProtocolIE-ContainerList	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180102	Stage 2 alignment for NSA Energy Savings	Qualcomm Incorporated	draftCR	Approval	Yes	No	available	No
		R3‑180439	Change of GTP TEID when UE resumes in same node	Ericsson	discussion	Agreement	Yes	No	available	No
		R3‑180440	Change of GTP TEID when UE resumes in same node	Ericsson	draftCR		Yes	No	available	No
		R3‑180031	Consideration on SCG configuration in case of option 2x configuration	ZTE	discussion		Yes	No	available	No
		R3‑180032	Correction of SCG configuration in case of option 2x configuration in TS37.340	ZTE	draftCR		Yes	No	available	No
		R3‑180132	Discussion on PCell/PScell/Scell management in CU-DU deployment	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180213	Add NR UE Security Capabilities to DL NAS Transport message	Qualcomm Incorporated, Vodafone	draftCR	Approval	Yes	No	available	No
		R3‑180280	clarification and correction on S1 for EN-DC	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180289	Essential corrections for EN-DC	Huawei, Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180148	EN-DC X2 setup and configuration update leftovers	Huawei	discussion	Approval	Yes	No	available	No
		R3‑180149	Stage 3 CR for EN-DC X2 setup and configuration update leftovers	Huawei	draftCR	Approval	Yes	No	available	No
		R3‑180498	X2AP corrections for agreed EN-DC BL CR	Ericsson	draftCR		Yes	No	available	No
		R3‑180304	Baseline CR to capture remaining FFS over X2 for EN-DC	Huawei, Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180447	Discussions on FFS IEs in X2 Setup	Ericsson	discussion	Agreement	Yes	No	available	No
		R3‑180054	Addition of the report type in the RRC Transfer	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	No	available	No
		R3‑180055	Signaling at PDCP-Count wraparound in Secondary Node	Nokia, Nokia Shanghai Bell	discussion	Discussion	Yes	No	available	No
		R3‑180056	Correction of counter Check procedure for EN-DC	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	No	available	No
		R3‑180057	RLC re-establishment indication at switching on a split bearer	Nokia, Nokia Shanghai Bell	discussion	Discussion	Yes	No	available	No
		R3‑180058	Addition of the indication of the RLC re-establishment	Nokia, Nokia Shanghai Bell	draftCR	Agreement	Yes	No	available	No
		R3‑180221	X2 support for supplementary UL carrier	Nokia, Nokia Shanghai Bell	discussion		Yes	No	available	No
		R3‑180222	Support for supplementary UL carrier	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180137	Discussion on SCG failure	CATT	discussion		Yes	No	available	No
		R3‑180138	Support of SCG failure handling	CATT	draftCR		Yes	No	available	No
		R3‑180230	Correction on supporting partial cell list	CATT	draftCR		Yes	No	available	No
		R3‑180270	Correction on UL configuration	NTT DOCOMO INC.	discussion		Yes	No	available	No
		R3‑180272	CR for UL configuration	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180331	Introduction of DRB ID for EN-DC	Huawei	draftCR		Yes	No	available	No
		R3‑180337	Clarifications on the QoS parameters	Huawei	discussion		Yes	No	available	No
		R3‑180338	Handling inconsistency in QoS parameters	Huawei	draftCR		Yes	No	available	No
		R3‑180281	clarification and correction on X2 for EN-DC	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180276	Addition of cause	NTT DOCOMO INC.	discussion		Yes	No	available	No
		R3‑180277	CR for addition of cause	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180292	mandatory/optional IEs in 36.423	NEC	discussion	Decision	Yes	No	available	No
		R3‑180293	Activation/Deactivation indication in EN-DC X2	NEC	discussion	Decision	Yes	No	available	No
		R3‑180296	Adding MeNB UE X2AP ID Extension	NEC	draftCR	Decision	Yes	No	available	No
		R3‑180028	Correction on Split SRB configuration	ZTE	discussion		Yes	No	available	No
		R3‑180030	Correction of Split SRB configuration in TS36.423	ZTE	draftCR		Yes	No	available	No
		R3‑180033	Correction of UL link configuration in TS36.423	ZTE	draftCR		Yes	No	available	No
		R3‑180176	Corrections on NR U-plane protocol	Nokia, Nokia Shanghai Bell	discussion		Yes	No	available	No
		R3‑180177	Corrections on NR U-plane protocol	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180307	clarification and correction on U-plane for EN-DC	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180181	Discussion on Downlink Data Delivery Status transfer	CATT	discussion		Yes	No	available	No
		R3‑180182	Correction on Downlink Data Delivery Status transfer	CATT	draftCR		Yes	No	available	No
		R3‑180489	Rapporteur suggested updates to 38.473	Huawei	draftCR		Yes	No	available	No
		R3‑180169	Discussion on intra-DU handover	CATT	discussion		Yes	No	available	No
		R3‑180170	Correction on intra-DU handover	CATT	draftCR		Yes	No	available	No
		R3‑180174	Maximum number of F1 logical connections	Nokia, Nokia Shanghai Bell	discussion		Yes	No	available	No
		R3‑180175	Maximum number of F1 logical connections	Nokia, Nokia Shanghai Bell	draftCR		Yes	No	available	No
		R3‑180310	Cell activation over configuration update	NTT DOCOMO INC.	discussion		Yes	No	available	No
		R3‑180311	CR on Cell activation over configuration update	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180312	clarification and correction on F1 for EN-DC	NTT DOCOMO INC.	draftCR		Yes	No	available	No
		R3‑180358	Presence of gNB-DU system information in F1 setup request	Huawei	discussion	Approval	Yes	No	available	No
		R3‑180359	CR to 38.473 on the presence of gNB-DU system information	Huawei	draftCR	Approval	Yes	No	available	No
		R3‑180360	Presence of UE radio capability in CU to DU RRC information	Huawei	discussion	Approval	Yes	No	available	No
		R3‑180361	CR to 38.473 on the presence of UE Radio capabilities	Huawei	draftCR	Approval	Yes	No	available	No
		R3‑180362	Discussions on the presence of serving cell info in F1 Setup	Huawei	discussion	Decision	Yes	No	available	No
		R3‑180363	CR to 38.473 on the presence of gNB-DU Served Cells List in F1 Setup	Huawei	other	Approval	Yes	No	available	No
		R3‑180364	Further discussion on measurement gap configuration	Huawei	discussion	Decision	Yes	No	available	No
		R3‑180365	CR to 38.473 on measurement gap configuration	Huawei	draftCR	Approval	Yes	No	available	No
		R3‑180366	CR to 38.473 on gNB-CU behaviour without DU to CU RRC information	Huawei	draftCR	Approval	Yes	No	available	No
		R3‑180119	Corrections for UE Context Management	ZTE Corporation	discussion		Yes	No	available	No
		R3‑180121	Corrections on UE Context Management for TS38.473	ZTE Corporation	draftCR		Yes	No	available	No
		R3‑180059	Editorial corrections of X2AP	Nokia, Nokia Shanghai Bell	draftCR	Agreement	No	Yes	withdrawn	Yes
		R3‑180220	Handling of remaining stage 3 FFSs for NSA ANR	Nokia, Nokia Shanghai Bell	other		Yes	Yes	revised	No	R3‑180500
31.3.2	QCI for EPC-Based ULLC
31.3.3	TNL Address Discovery for Option 3	R3‑180319	TNL address discovery for NSA	NTT DOCOMO INC.	discussion	Approval	Yes	No	available	No
		R3‑180282	TNL address discovery for Option 3	LG Electronics	discussion		Yes	No	available	No
		R3‑180261	TNL Address Discovery in Option 3	Samsung	discussion	Approval	Yes	No	available	No
		R3‑180223	TNL address discovery based on intermediate node, for option 3	Nokia, Nokia Shanghai Bell	discussion		Yes	No	available	No
		R3‑180150	En-gNB X2 TNL Address Discovery	Huawei	discussion	Approval	Yes	No	available	No
		R3‑180151	Stage 2 CR for en-gNB X2 TNL address discovery	Huawei	draftCR	Approval	Yes	No	available	No
		R3‑180152	Stage 3 CR for en-gNB X2 TNL address discovery	Huawei	draftCR	Approval	Yes	No	available	No
32	Rel-15 Specification Review
32.1	Editorial
32.2	ASN.1
33	Any other business
34	Closing of the meeting (Friday 17:00)