Tdoc List
2018-01-19 11:16
TDoc | Title | Source | Type | For | Agenda | Avail | Treated | Decision | Wdrn | Replaced-by | Replaces |
---|---|---|---|---|---|---|---|---|---|---|---|
R3‑180001 | Discussion on Non-3GPP Access support in NGAP | Nokia, Nokia Shanghai Bell | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180002 | RAN3-AH-1801 meeting Agenda | Chairman | agenda |
3Approval of the Agenda
| Yes |
No
| available | No | |||
R3‑180003 | Reply LS on supporting non-3GPP access in NGAP | 3GPP SA WG2, Nokia | LS in |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180004 | LS reply on multiple SCTP associations | 3GPP SA WG2, Intel | LS in |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180005 | LS reply on N2 requirements and procedures | 3GPP SA WG2, Intel | LS in |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180006 | LS on handling concurrent running of security procedures | 3GPP SA WG3, Ericsson | LS in |
10.5Radio Access Network connected to 5G-CN
| Yes |
No
| available | No | |||
R3‑180007 | Further Discussion on the Default QoS Profile | ZTE | discussion |
10.1.2Default QoS
| 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‑180008 | Further Clarification and pCR for PDU Session/QoS Flow Failure Relevant Handling | ZTE | pCR |
10.1.5Others
| 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 |
10.1.5Others
| 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‑180010 | Capturing NW Slice Relevant Agreements in TS37.340 | ZTE | draftCR |
10.2.1.1Corrections, Clarifications
| Yes |
No
| available | No | |||
R3‑180011 | NW Slice Temporarily Unavailable | ZTE | discussion |
10.2.2Slice Unavailability
| Yes |
NoProposal: NW Slice temporarily unavailable indication is not needed. Remove FFS of temporarily unavailable status from TS 38.413.
| available | No | |||
R3‑180012 | Further Consideration on SN Release | ZTE | discussion |
10.8.2.1General
| Yes |
No
| available | No | |||
R3‑180013 | Correction of SN Release in TS37.340 | ZTE | draftCR |
10.8.2.1General
| Yes |
No
| available | No | |||
R3‑180014 | Further Consideration on MR-DC Mobility Procedures | ZTE | discussion |
10.8.2.2Stage 2
| Yes |
No
| available | No | |||
R3‑180015 | Reply LS on PRB grid in the NR | 3GPP RAN1, Huawei | LS in |
8.1New Incoming LSs
| Yes |
No
| available | No | |||
R3‑180016 | Response LS on required information for NSA on X2. | 3GPP RAN1, Nokia | LS in |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| 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 |
8.1New Incoming LSs
| Yes |
No
| available | No | |||
R3‑180018 | LS reply on UE RF related parameters, capabilities and features for NR | 3GPP RAN4, NTT Docomo | LS in |
8.1New Incoming LSs
| Yes |
No
| available | No | |||
R3‑180019 | LS on interworking mechanisms between 5G System and legacy RATs | 3GPP RAN, NEC | LS in |
8.1New Incoming LSs
| Yes |
No
| available | No | |||
R3‑180020 | LS on Removal of 'over LTE' limitation from Mission Critical Specifications | 3GPP SA1, Politie | LS in |
8.1New Incoming LSs
| 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 |
8.1New Incoming LSs
| Yes |
No
| available | No | |||
R3‑180022 | LS on User Plane Security Policy | 3GPP SA3, Huawei | LS in |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180023 | Reply LS on cooperation on Network Slicing | 3GPP SA5, Huawei | LS in |
8.1New Incoming LSs
| 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 |
8.1New Incoming LSs
| Yes |
No
| available | No | |||
R3‑180025 | Correction of MR-DC Combined Mobility in TS37.340 | ZTE | draftCR |
10.8.2.2Stage 2
| Yes |
No
| available | No | |||
R3‑180026 | Further Discussion on Mode Change between Single and Two NG-U tunnels | ZTE | discussion |
10.8.2.2Stage 2
| Yes |
No
| available | No | |||
R3‑180027 | Correction of Mode Change between Single and Two NG-U tunnels in TS37.340 | ZTE | draftCR |
10.8.2.2Stage 2
| Yes |
No
| available | No | |||
R3‑180028 | Correction on Split SRB configuration | ZTE | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180029 | Correction of Split SRB configuration in TS37.340 | ZTE | draftCR |
10.8.2.2Stage 2
| No |
No
| reserved | No | |||
R3‑180030 | Correction of Split SRB configuration in TS36.423 | ZTE | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180031 | Consideration on SCG configuration in case of option 2x configuration | ZTE | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180032 | Correction of SCG configuration in case of option 2x configuration in TS37.340 | ZTE | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180033 | Correction of UL link configuration in TS36.423 | ZTE | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180034 | Further Discussion on QoS Flow to DRB Mapping in MR-DC@5GC | ZTE | discussion |
10.8.2.3Control of Various NGEN-DC DRB Options
| Yes |
No
| available | No | |||
R3‑180035 | Further Discussion and pCR on MR-DC@5GC Specific Xn Messages Structures | ZTE | discussion |
10.8.2.3Control of Various NGEN-DC DRB Options
| Yes |
No
| available | No | |||
R3‑180036 | Correction of QoS Flow to DRB Mapping in MR-DC@5GC in TS37.340 | ZTE | draftCR |
10.8.2.3Control of Various NGEN-DC DRB Options
| Yes |
No
| available | No | |||
R3‑180037 | Further Discussion and Stage2 pCR for SN Initiated SN Modification Procedure | ZTE | discussion |
10.8.2.5Change between NGEN-DC DRB Options (Bearer Type Change)
| Yes |
No
| available | No | |||
R3‑180038 | Stage3 pCR for SN Initiated SN Modification Procedure | ZTE | pCR |
10.8.2.5Change between NGEN-DC DRB Options (Bearer Type Change)
| Yes |
No
| available | No | |||
R3‑180039 | Consideration on Multi-Connectivity with Dual/Multiple gNB-DUs | ZTE | discussion |
10.9.3Centralized Retransmission
| Yes |
No
| available | No | |||
R3‑180040 | Correction of Multi-Connectivity with Dual/Multiple gNB-DUs in TS38.401 | ZTE | draftCR |
10.9.3Centralized Retransmission
| Yes |
No
| available | No | |||
R3‑180041 | Rapporteur Cleanups for TS37.340 (RAN3 Part) | ZTE | discussion |
10.11Stage 2 Updates
| Yes |
No
| available | No | |||
R3‑180042 | Rapporteur Updates of TS 38.414 to v031 | ZTE | discussion |
10.12.4TS 38.414/424 NG/Xn Data transport
| Yes |
No
| available | No | |||
R3‑180043 | Correction of TS37.340 for Single Tx Hamonic Issues | ZTE | draftCR |
10.14LTE-NR Coexistence Aspects
| Yes |
No
| available | No | |||
R3‑180044 | Correction on S1AP for the secondary RAT data volume reporting | ZTE | draftCR |
10.8.5Others
| Yes |
No
| available | No | |||
R3‑180045 | Correction on X2AP for the secondary RAT data volume reporting | ZTE | draftCR |
10.8.5Others
| Yes |
No
| available | No | |||
R3‑180046 | CN Area Update in Inactive State | ZTE | discussion |
10.6.5Others
| Yes |
No
| available | No | |||
R3‑180047 | Analysis on NGAP support for multiple-SCTP associations | Nokia, Nokia Shanghai Bell | pCR |
10.5.1Multiple SCTP Associations and Related Mechanisms
| 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 |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180049 | Discussion on AMF management | Nokia, Nokia Shanghai Bell | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180050 | Discussion on Overload Control in NGAP | Nokia, Nokia Shanghai Bell | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180051 | TP for NGAP Overload Control | Nokia, Nokia Shanghai Bell | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180052 | A new AMBR solution for MR-DC | Nokia, Nokia Shanghai Bell | discussion | Discussion |
10.8.2.7UE AMBR
| Yes |
No
| available | No | ||
R3‑180053 | Correction of the UE ID in the RRC Transfer | Nokia, Nokia Shanghai Bell | draftCR | Agreement |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180054 | Addition of the report type in the RRC Transfer | Nokia, Nokia Shanghai Bell | draftCR | Agreement |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180055 | Signaling at PDCP-Count wraparound in Secondary Node | Nokia, Nokia Shanghai Bell | discussion | Discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180056 | Correction of counter Check procedure for EN-DC | Nokia, Nokia Shanghai Bell | draftCR | Agreement |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180057 | RLC re-establishment indication at switching on a split bearer | Nokia, Nokia Shanghai Bell | discussion | Discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180058 | Addition of the indication of the RLC re-establishment | Nokia, Nokia Shanghai Bell | draftCR | Agreement |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180059 | Editorial corrections of X2AP | Nokia, Nokia Shanghai Bell | draftCR | Agreement |
31.3.1Essential Corrections
| No |
Yes
| withdrawn | Yes | ||
R3‑180060 | Cleanup of reference/defintions | InterDigital, Huawei | discussion | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180061 | Cleanup of reference/definitions for 38.410 | Interdigital | pCR | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180062 | Cleanup of reference/definitions for 38.412 | Interdigital Asia LLC | pCR | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180063 | Cleanup of reference/definitions for 38.413 | Interdigital Asia LLC | pCR | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180064 | Cleanup of reference/definitions for 38.414 | Interdigital Asia LLC | pCR | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180065 | Cleanup of reference/definitions for 38.420 | Interdigital Asia LLC | pCR | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180066 | Cleanup of reference/definitions for 38.422 | Interdigital Asia LLC | pCR | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180067 | Cleanup of reference/definitions for 38.423 | Interdigital Asia LLC | pCR | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180068 | Cleanup of reference/definitions for 38.424 | Interdigital Asia LLC | pCR | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180069 | Cleanup of reference/definitions for 38.455 | Interdigital Asia LLC | pCR | Agreement |
10.15Others
| Yes |
No
| available | No | ||
R3‑180070 | Correction of QoS Profile for TS 38.413 | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.1.1Content QoS Flow Level Parameters
| 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 |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | ||
R3‑180072 | Correction of Delay Critical GBR in TS 38.413 | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.1.1Content QoS Flow Level Parameters
| 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 |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | ||
R3‑180074 | Text Proposal for most probable QoS profile | Nokia, Nokia Shanghai Bell, Intel Corporation, LG Electronics, Huawei | pCR | Agreement |
10.1.2Default QoS
| Yes |
No
| available | No | ||
R3‑180075 | Reply LS on default DRB establishment for PDU session | Nokia, Nokia Shanghai Bell | LS out | Agreement |
10.1.2Default QoS
| Yes |
No
| available | No | ||
R3‑180076 | Choice of 5GS container | Nokia, Nokia Shanghai Bell | discussion | Approval |
10.1.4NG/Xn/F1 UP Encapsulation Header
| 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 |
10.1.4NG/Xn/F1 UP Encapsulation Header
| Yes |
No
| available | No | ||
R3‑180078 | LS on defining GTP extension header for 5GS container | Nokia, Nokia Shanghai Bell | LS out | Agreement |
10.1.4NG/Xn/F1 UP Encapsulation Header
| Yes |
No
| available | No | ||
R3‑180079 | Configuration of default AMF set in 38.300 | Nokia, Nokia Shanghai Bell | draftCR | Agreement |
10.2.1.1Corrections, Clarifications
| Yes |
No
| available | No | ||
R3‑180080 | Configuration of default AMF set in 38.413 | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.2.1.1Corrections, Clarifications
| Yes |
No
| available | No | ||
R3‑180081 | Text Proposal for Configuration of Network Slicing over NG | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.2.1.2Configuration, NG/Xn Setup, Config Update, Context Setup
| 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 |
10.2.1.2Configuration, NG/Xn Setup, Config Update, Context Setup
| Yes |
No
| available | No | ||
R3‑180083 | Text Proposal for Slice information in Path Switch Request | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.2.1.3Mobility, DC
| 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‑180084 | Correction of slice temporarily unavailable | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.2.2Slice Unavailability
| 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‑180085 | Text Proposal for multiple SCTP for TS 38.412 | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.5.1Multiple SCTP Associations and Related Mechanisms
| 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‑180086 | Handover and Redirection of Emergency Services | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.5.2.1Common Aspects
| Yes |
No
| available | No | ||
R3‑180087 | Correction of 5G to 4G handover | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.5.2.3Inter-System Specifics, 5G->4G
| 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 | ||
R3‑180088 | Text Proposal for Stage 2 Data forwarding | Nokia, Nokia Shanghai Bell | draftCR | Endorsement |
10.5.5.1Common Aspects
| Yes |
No
| available | No | ||
R3‑180089 | Finalization of 5G to 4G Data forwarding | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.5.5.2NG-Based Handover Aspects
| 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‑180090 | Conclusion and Text Proposal for data forwarding at 4G to 5G Handover | Nokia, Nokia Shanghai Bell | draftCR | Agreement |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | ||
R3‑180091 | Text Proposal for data forwarding at 4G to 5G Handover | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | ||
R3‑180092 | Assistance Information for RAN Paging Priority | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
No
| available | No | ||
R3‑180093 | Text Proposal for Paging Priority | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
No
| available | No | ||
R3‑180094 | Text Proposal for Xn Assistance Data for RAN Paging | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.6.3NG-RAN Paging
| Yes |
No
| available | No | ||
R3‑180095 | Text Proposal for Rapporteur’s update for TS 38.410 | Nokia, Nokia Shanghai Bell | pCR | Agreement |
10.11.4TS 38.410/420 NG/Xn General aspects and principles
| Yes |
No
| available | No | ||
R3‑180096 | Rapporteur update for TS 38.413 | Nokia, Nokia Shanghai Bell | pCR |
10.12.3.1TS 38.413 NG Application Protocol (NGAP)
| Yes |
No
| available | No | |||
R3‑180097 | MDT and Trace support in NG-RAN | Nokia, Nokia Shanghai Bell, Huawei | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180098 | NG interface management procedures | Nokia, Nokia Shanghai Bell | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180099 | Impacts of flexible length gNB ID on NGAP procedures | Nokia, Nokia Shanghai Bell | pCR |
10.5.3NG-RAN Node Identification on NG and Xn
| 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‑180100 | Stage 2 for PWS support (TS 38.410) | Nokia, Nokia Shanghai Bell, AT&T, Huawei, one2many | pCR |
10.4Support for PWS
| 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 | |||
R3‑180101 | On the need for explicit signalling of gNB length | Qualcomm Incorporated | discussion | Approval |
10.5.3NG-RAN Node Identification on NG and Xn
| Yes |
NoProposal 1: There is no need for explicit signalling of the gNB ID length.
| available | No | ||
R3‑180102 | Stage 2 alignment for NSA Energy Savings | Qualcomm Incorporated | draftCR | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180103 | On open issues in TS 38.425 | Qualcomm Incorporated | discussion | Discussion |
10.9User Plane
| Yes |
No
| available | No | ||
R3‑180104 | Bearer and flow offloading for MR-DC with 5GC | LG Electronics, KT Corp. | discussion |
10.8.2.3Control of Various NGEN-DC DRB Options
| Yes |
No
| available | No | |||
R3‑180105 | Discussion on multiple SCTP associations | ZTE Corporation | discussion |
10.5.1Multiple SCTP Associations and Related Mechanisms
| 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‑180106 | RAN Paging Handling | Qualcomm Incorporated | discussion | Discussion |
10.6.3NG-RAN Paging
| Yes |
No
| available | No | ||
R3‑180107 | Slice Rejection Handling in Xn Handover | Qualcomm Incorporated | pCR | Approval |
10.2.1.3Mobility, DC
| 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‑180108 | VoNR Feature Plan | Qualcomm Incorporated | discussion | Discussion |
10.5.6Others
| Yes |
No
| available | No | ||
R3‑180109 | UE radio capability handling | Qualcomm Incorporated | discussion | Approval |
10.5.6Others
| Yes |
No
| available | No | ||
R3‑180110 | UE capability Indication (P-CR 38.413) | Qualcomm Incorporated | pCR | Approval |
10.5.6Others
| Yes |
No
| available | No | ||
R3‑180111 | UE capability Indication (P-CR 38.410) | Qualcomm Incorporated | pCR | Approval |
10.5.6Others
| Yes |
No
| available | No | ||
R3‑180112 | NG Paging Procedure | Qualcomm Incorporated | discussion | Discussion |
10.5.6Others
| Yes |
No
| available | No | ||
R3‑180113 | Paging procedure (P-CR 38.413) | Qualcomm Incorporated | pCR | Approval |
10.5.6Others
| Yes |
No
| available | No | ||
R3‑180114 | Feedback of MCG split SRB | Qualcomm Incorporated | pCR | Approval |
10.8.2.4Control of NGEN-DC SRB Options
| Yes |
No
| available | No | ||
R3‑180115 | LTE-NR coordination for inter-modulation issue | Qualcomm Incorporated | discussion | Discussion |
10.14.2Others
| Yes |
No
| available | No | ||
R3‑180116 | TP on multiple SCTP associations for TS38.300 | ZTE Corporation | draftCR |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180117 | LTE-NR coordination for inter-modulation issue | Qualcomm Incorporated | pCR | Approval |
10.14.2Others
| No |
Yes
| withdrawn | Yes | ||
R3‑180118 | Multiple SCTP associations support for TS38.413 | ZTE Corporation | draftCR |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180119 | Corrections for UE Context Management | ZTE Corporation | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180120 | TPs for XnAP for MDT and Trace support in NG-RAN | Huawei, Nokia, Nokia Shanghai Bell | pCR | Approval |
10.5.6Others
| Yes |
No
| available | No | ||
R3‑180121 | Corrections on UE Context Management for TS38.473 | ZTE Corporation | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180122 | Security issue for UE Initial Access | ZTE Corporation | discussion |
10.10.3UE Initial Access, State Transitions
| Yes |
No
| available | No | |||
R3‑180123 | QoS information transfer over F1 interface | ZTE Corporation | discussion |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180124 | Update on QoS information transfer for TS38.473 | ZTE Corporation | draftCR |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180125 | Corrections for RRC Message Transfer for TS38.473 | ZTE Corporation | draftCR |
10.10.3UE Initial Access, State Transitions
| Yes |
No
| available | No | |||
R3‑180126 | Left issues on Inactive UE over F1 interface | ZTE Corporation | discussion |
10.10.3UE Initial Access, State Transitions
| Yes |
No
| available | No | |||
R3‑180127 | Discussion on Bearer Management over E1 interface | ZTE Corporation | discussion |
23.3E1 Application Protocol (E1AP)
| Yes |
No
| available | No | |||
R3‑180128 | Further consideration on E1 interface setup | ZTE Corporation | discussion |
23.3E1 Application Protocol (E1AP)
| Yes |
No
| available | No | |||
R3‑180129 | Discussion on security key generation over E1 interface | ZTE Corporation | discussion |
23.4Security Aspects
| Yes |
No
| available | No | |||
R3‑180130 | Draft LS on security key generation for CP/UP separation | ZTE Corporation | LS out |
23.4Security Aspects
| Yes |
No
| available | No | |||
R3‑180131 | Further discussion on data retransmission indication | ZTE Corporation | draftCR |
10.9.1Fast Retransmission
| Yes |
No
| available | No | |||
R3‑180132 | Discussion on PCell/PScell/Scell management in CU-DU deployment | ZTE Corporation | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180133 | Discussion on Load Management over F1 interface | ZTE Corporation | discussion |
10.10.8Others
| Yes |
No
| available | No | |||
R3‑180134 | Discussion on Inter-DU Mobility with Dual Connectivity | ZTE Corporation | draftCR |
10.10.4Mobility Aspects
| Yes |
No
| available | No | |||
R3‑180135 | Consideration on fast duplication activation and deactivation over F1 | ZTE Corporation | discussion |
10.9.2PDCP Duplication
| Yes |
No
| available | No | |||
R3‑180136 | Left FFS on paging over F1 | ZTE Corporation | discussion |
10.10.5Paging
| Yes |
No
| available | No | |||
R3‑180137 | Discussion on SCG failure | CATT | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180138 | Support of SCG failure handling | CATT | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180139 | NW slicing for high layer functional split | ZTE Corporation | discussion |
10.10.1General
| Yes |
No
| available | No | |||
R3‑180140 | Handling of DL signallings | CATT | draftCR |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
No
| available | No | |||
R3‑180141 | TP for 38.413 on DL signalling handling | CATT | pCR |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
No
| available | No | |||
R3‑180142 | Content of RAN Paging | CATT | pCR |
10.6.3NG-RAN Paging
| Yes |
No
| available | No | |||
R3‑180143 | Data forwarding for inter system HO from EPS to 5GS | CATT | draftCR |
10.5.5.2NG-Based Handover Aspects
| 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 |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | |||
R3‑180145 | TP for 36.413 to support handover from EPS to 5GS | CATT | draftCR |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | |||
R3‑180146 | Data forwarding for Xn Handover | CATT | draftCR |
10.5.5.2NG-Based Handover Aspects
| 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 |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | |||
R3‑180148 | EN-DC X2 setup and configuration update leftovers | Huawei | discussion | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180149 | Stage 3 CR for EN-DC X2 setup and configuration update leftovers | Huawei | draftCR | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180150 | En-gNB X2 TNL Address Discovery | Huawei | discussion | Approval |
31.3.3TNL Address Discovery for Option 3
| Yes |
No
| available | No | ||
R3‑180151 | Stage 2 CR for en-gNB X2 TNL address discovery | Huawei | draftCR | Approval |
31.3.3TNL Address Discovery for Option 3
| Yes |
No
| available | No | ||
R3‑180152 | Stage 3 CR for en-gNB X2 TNL address discovery | Huawei | draftCR | Approval |
31.3.3TNL Address Discovery for Option 3
| Yes |
No
| available | No | ||
R3‑180153 | NG-RAN node Xn-C TNL address discovery | Huawei | discussion | Approval |
10.3.1TNL Address Discovery for NG-RAN
| No |
Yes
| withdrawn | Yes | ||
R3‑180154 | Xn setup and NG-RAN node configuration update | Huawei | discussion | Approval |
10.3.2NG/Xn Setup
| 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‑180155 | The Presence of RRC Inactive Assistance Information | Huawei | pCR | Approval |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
No
| available | No | ||
R3‑180156 | DL signalling handling in INACTIVE state | Huawei | discussion | Approval |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
No
| available | No | ||
R3‑180157 | RAN Paging Priority handling | Huawei | pCR | Approval |
10.6.3NG-RAN Paging
| Yes |
No
| available | No | ||
R3‑180158 | Text proposals for NGAP for RAN Paging Priority handling | Huawei | pCR | Approval |
10.6.3NG-RAN Paging
| Yes |
No
| available | No | ||
R3‑180159 | Periodic RNA update without anchor gNB relocation | Huawei | discussion | Approval |
10.6.4UE Context Transfer
| Yes |
No
| available | No | ||
R3‑180160 | Introduction of Retrieve UE Context messages | Huawei | pCR | Approval |
10.6.4UE Context Transfer
| Yes |
Yes
| revised | No | R3‑180506 | |
R3‑180161 | RRC Reconfiguration Complete Indication to DU | CATT | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180162 | Support of UE Reconfiguration Complete Message | CATT | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180163 | Support of UE Reconfiguration Complete Message | CATT | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180164 | TP for 38.401 BL on UE Reconfiguration Completion procedure | CATT | draftCR |
10.10.1General
| Yes |
No
| available | No | |||
R3‑180165 | AS Security handling | Nokia, Nokia Shanghai Bell | discussion |
23.4Security Aspects
| Yes |
No
| available | No | |||
R3‑180166 | Discussion on SgNB initiated SgNB Modification procedure | CATT | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180167 | Correction on SgNB initiated SgNB Modification procedure | CATT | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180168 | Correction on SgNB initiated SgNB Modification procedure | CATT | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180169 | Discussion on intra-DU handover | CATT | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180170 | Correction on intra-DU handover | CATT | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180171 | Rapporteur editorial updates to 38.421 | CATT | pCR |
10.12.1TS 38.411/421 NG/Xn Layer 1
| Yes |
No
| available | No | |||
R3‑180172 | Corrections on UE Context Setup procedure | Nokia, Nokia Shanghai Bell | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180173 | Corrections on UE Context Setup procedure | Nokia, Nokia Shanghai Bell | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180174 | Maximum number of F1 logical connections | Nokia, Nokia Shanghai Bell | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180175 | Maximum number of F1 logical connections | Nokia, Nokia Shanghai Bell | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180176 | Corrections on NR U-plane protocol | Nokia, Nokia Shanghai Bell | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180177 | Corrections on NR U-plane protocol | Nokia, Nokia Shanghai Bell | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180178 | Correction on the definition of ProtocolIE-ContainerList | Nokia, Nokia Shanghai Bell | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180179 | Discussion on UE Context Management procedure | CATT | draftCR |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180180 | TP for TS 38.473 on UE Context Management procedure | CATT | draftCR |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180181 | Discussion on Downlink Data Delivery Status transfer | CATT | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180182 | Correction on Downlink Data Delivery Status transfer | CATT | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180183 | Consideration on UE context management procedures for EN-DC | CATT | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180184 | Correction on UE context management procedures for EN-DC | CATT | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180185 | Correction on the definition of ProtocolIE-ContainerList | Nokia, Nokia Shanghai Bell | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180186 | Load management | Nokia, Nokia Shanghai Bell | draftCR |
10.10.8Others
| Yes |
No
| available | No | |||
R3‑180187 | TP of Load management (TS 38.473) | Nokia, Nokia Shanghai Bell | draftCR |
10.10.8Others
| Yes |
No
| available | No | |||
R3‑180188 | QoS handling for F1 | Nokia, Nokia Shanghai Bell | draftCR |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180189 | TP of QoS handling for F1 (TS 38.473) | Nokia, Nokia Shanghai Bell | draftCR |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180190 | User inactivity monitoring | Nokia, Nokia Shanghai Bell | draftCR |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180191 | TP on support of delta configuration during handover procedure | CATT | draftCR |
10.10.4Mobility Aspects
| Yes |
No
| available | No | |||
R3‑180192 | Discussion on V1 leftover issues | Huawei, China Unicom | pCR |
12.2CU-DU Interface, Functions, and Procedures
| Yes |
No
| available | No | |||
R3‑180193 | TP for 38.413 on QoS parameter update | CATT | pCR |
10.1.1Content QoS Flow Level Parameters
| 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 |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | |||
R3‑180195 | TP for 38.413 on status of Notification Control | CATT | pCR |
10.1.1Content QoS Flow Level Parameters
| 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 |
10.1.1Content QoS Flow Level Parameters
| 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 |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | |||
R3‑180198 | TP for 38.413 on Slice unavailable | CATT | pCR |
10.2.2Slice Unavailability
| 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 | |||
R3‑180199 | Discussion on Slice mobility issue | CATT | discussion |
10.2.1.4Mobility Across RAs
| 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‑180200 | TP for 38.470 on Notification Control | CATT | draftCR |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | |||
R3‑180201 | Discussion on data forwarding when DC offloading | CATT | discussion |
10.8.2.6Data Forwarding
| Yes |
No
| available | No | |||
R3‑180202 | TP for 38.473 on Notification Control | CATT | draftCR |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | |||
R3‑180203 | Stage 2 CR for NG-RAN node Xn-C TNL address discovery | Huawei | draftCR | Approval |
10.3.1TNL Address Discovery for NG-RAN
| 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‑180204 | Stage 2 CR for Xn setup and NG-RAN node configuration update | Huawei | draftCR | Approval |
10.3.2NG/Xn Setup
| Yes |
NoThis is the corresponding CR for Xn setup and NG-RAN node configuration update as discussed in R3-180154.
| available | No | ||
R3‑180205 | Stage 2 CR for DL signalling handling in INACTIVE state | Huawei | draftCR | Approval |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
No
| available | No | ||
R3‑180206 | Stage 2 CR for Periodic RNA update without anchor gNB relocation | Huawei | draftCR | Approval |
10.6.4UE Context Transfer
| Yes |
No
| available | No | ||
R3‑180207 | Criticality Diagnostics for Transaction ID | Nokia, Nokia Shanghai Bell | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180208 | Criticality Diagnostics for Transaction ID | Nokia, Nokia Shanghai Bell | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180209 | Bearer type decision and change for NGEN-DC DRB options | LG Electronics, KT Corp. | draftCR |
10.8.2.5Change between NGEN-DC DRB Options (Bearer Type Change)
| Yes |
No
| available | No | |||
R3‑180210 | Issues on AMBR for Option 7 family | LG Electronics | draftCR |
10.8.2.7UE AMBR
| Yes |
No
| available | No | |||
R3‑180211 | Corrections to UP protocol | Qualcomm UK Ltd | draftCR | Approval |
10.9User Plane
| No |
Yes
| withdrawn | Yes | ||
R3‑180212 | Corrections to NR UP protocol | Qualcomm Incorporated | draftCR | Approval |
10.9User Plane
| Yes |
No
| available | No | ||
R3‑180213 | Add NR UE Security Capabilities to DL NAS Transport message | Qualcomm Incorporated, Vodafone | draftCR | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180214 | Introduction of stage 2 text for Data Forwarding | Nokia, Nokia Shanghai Bell | discussion | Approval |
10.5.5.1Common Aspects
| 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‑180215 | Finalization of Data Forwarding at 4g to 5g Handover | Nokia, Nokia Shanghai Bell | discussion | Approval |
10.5.5.2NG-Based Handover Aspects
| 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‑180216 | LTE-NR coordination for inter-modulation issue | Qualcomm Incorporated | draftCR | Approval |
10.14.2Others
| Yes |
No
| available | No | ||
R3‑180217 | On the definition of RNA and design of the RRC-INACTIVE feature | Qualcomm Incorporated | discussion | Discussion |
10.6.4UE Context Transfer
| Yes |
No
| available | No | ||
R3‑180218 | Stage 2 corrections for NSA ANR | Nokia, Nokia Shanghai Bell | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180219 | Corrections on NSA ANR | Nokia, Nokia Shanghai Bell | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180220 | Handling of remaining stage 3 FFSs for NSA ANR | Nokia, Nokia Shanghai Bell | other |
31.3.1Essential Corrections
| Yes |
Yes
| revised | No | R3‑180500 | ||
R3‑180221 | X2 support for supplementary UL carrier | Nokia, Nokia Shanghai Bell | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180222 | Support for supplementary UL carrier | Nokia, Nokia Shanghai Bell | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180223 | TNL address discovery based on intermediate node, for option 3 | Nokia, Nokia Shanghai Bell | discussion |
31.3.3TNL Address Discovery for Option 3
| Yes |
No
| available | No | |||
R3‑180224 | Signalling for cell resource coordination | Nokia, Nokia Shanghai Bell, AT&T | discussion |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| Yes |
No
| available | No | |||
R3‑180225 | E-UTRA - NR Cell Resource Coordination | Nokia, Nokia Shanghai Bell, AT&T | draftCR |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| Yes |
No
| available | No | |||
R3‑180226 | E-UTRA - NR Cell Resource Coordination | Nokia, Nokia Shanghai Bell, AT&T | draftCR |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| Yes |
No
| available | No | |||
R3‑180227 | UE-AMBR derivation in NG procedures | LG Electronics | pCR |
10.1.5Others
| 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 |
10.1.5Others
| 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 | |||
R3‑180229 | Discussion on Reroute NAS Request | Nokia, Nokia Shanghai Bell | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180230 | Correction on supporting partial cell list | CATT | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180231 | Consideration on 5GS container for QFI | Huawei | discussion |
10.1.4NG/Xn/F1 UP Encapsulation Header
| 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 |
10.1.4NG/Xn/F1 UP Encapsulation Header
| Yes |
No
| available | No | |||
R3‑180233 | Issues on system information management function | LG Electronics, KT Corp. | draftCR |
10.10.2System Information
| Yes |
No
| available | No | |||
R3‑180234 | QoS aspect in UE context management function | LG Electronics, KT Corp. | draftCR |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180235 | Stage 3 on QoS aspect in UE context management function | LG Electronics, KT Corp. | draftCR |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180236 | Supplementary uplink (SUL) information for NR cells over X2/Xn/F1 | Samsung | draftCR | Approval |
10.3.2NG/Xn Setup
| 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 |
10.3.2NG/Xn Setup
| Yes |
No
| available | No | ||
R3‑180238 | PDCP duplication activation and deactivation over F1 | Samsung | draftCR | Approval |
10.9.2PDCP Duplication
| Yes |
No
| available | No | ||
R3‑180239 | PDCP duplication support over X2 | Samsung | draftCR | Approval |
10.9.2PDCP Duplication
| Yes |
No
| available | No | ||
R3‑180240 | Radio link outage/resume for DL and UL | Samsung | draftCR | Approval |
10.9.3Centralized Retransmission
| Yes |
No
| available | No | ||
R3‑180241 | UE attached indication for mobility procedure | Samsung | draftCR | Approval |
10.10.4Mobility Aspects
| Yes |
No
| available | No | ||
R3‑180242 | Stage 2 TP for TS38.470 on UE attached indication for mobility procedure | Samsung | draftCR | Approval |
10.10.4Mobility Aspects
| Yes |
No
| available | No | ||
R3‑180243 | Stage 3 TP for TS38.473 on UE attached indication for mobility procedure | Samsung | draftCR | Approval |
10.10.4Mobility Aspects
| Yes |
No
| available | No | ||
R3‑180244 | UE context management update considering parameters over X2 for EN-DC | Samsung | draftCR | Approval |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180245 | Supplementary uplink (SUL) information for NR cells over F1 | Samsung | draftCR | Approval |
10.10.8Others
| Yes |
No
| available | No | ||
R3‑180246 | Supplementary uplink (SUL) addition and release over F1 | Samsung | draftCR | Approval |
10.10.8Others
| Yes |
No
| available | No | ||
R3‑180247 | Open issues on Data forwarding for Inter-system handover from 5GS to EPS | Samsung | pCR | Approval |
10.5.5.2NG-Based Handover Aspects
| 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 |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | ||
R3‑180249 | Data forwarding for Inter-system handover from EPS to 5GS | Samsung | draftCR | Approval |
10.5.5.2NG-Based Handover Aspects
| 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 |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | ||
R3‑180251 | Stage 2 change to support data forwarding for inter-system handover from EPS to 5GS | Samsung | draftCR | Approval |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | ||
R3‑180252 | Stage 2 TP on RRC Inactive Transition Report | Samsung | draftCR | Approval |
10.6.5Others
| Yes |
No
| available | No | ||
R3‑180253 | Stage 3 TP on RRC Inactive Transition Report | Samsung | pCR | Approval |
10.6.5Others
| Yes |
No
| available | No | ||
R3‑180254 | Rapporteur’s update to TS38.425v100 | Samsung | draftCR | Approval |
10.9.4Others
| Yes |
No
| available | No | ||
R3‑180255 | TP for TS 38.420 on Xn-U | Samsung | pCR | Approval |
10.1.4NG/Xn/F1 UP Encapsulation Header
| Yes |
No
| available | No | ||
R3‑180256 | TP for TS 37.340 on Xn-U | Samsung | draftCR | Approval |
10.1.4NG/Xn/F1 UP Encapsulation Header
| Yes |
No
| available | No | ||
R3‑180257 | Data Forwarding in NG Based Handover | Samsung | pCR | Approval |
10.5.5.2NG-Based Handover Aspects
| 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‑180258 | Data Forwarding in Xn Based Handover | Samsung | pCR | Approval |
10.5.5.3Xn-Based Handover Aspects
| 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‑180259 | Dual Connectivity establishment in new QoS framework | Samsung | pCR | Approval |
10.8.2.3Control of Various NGEN-DC DRB Options
| Yes |
No
| available | No | ||
R3‑180260 | Security Aspects for CU-UP | Samsung | discussion | Approval |
23.4Security Aspects
| Yes |
No
| available | No | ||
R3‑180261 | TNL Address Discovery in Option 3 | Samsung | discussion | Approval |
31.3.3TNL Address Discovery for Option 3
| Yes |
No
| available | No | ||
R3‑180262 | Handover Type in Handover Reqired message | Samsung R&D Institute UK | pCR | Approval |
10.5.2.1Common Aspects
| No |
No
| reserved | No | ||
R3‑180263 | Discussion on AMF management | Huawei | discussion |
10.5.1Multiple SCTP Associations and Related Mechanisms
| 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‑180264 | [DRAFT] LS on handover type from NG-RAN to 5GC | Samsung R&D Institute UK | LS out | Approval |
10.5.2.1Common Aspects
| No |
No
| reserved | No | ||
R3‑180265 | Control of non GBR QoS flows | Huawei | pCR |
10.1.1Content QoS Flow Level Parameters
| 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‑180266 | Discussion on Allowed NSSAI in NG-RAN | LG Electronics | pCR |
10.2.1.2Configuration, NG/Xn Setup, Config Update, Context Setup
| 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‑180267 | Inter-registration area mobility considering network slice | LG Electronics | pCR |
10.2.1.4Mobility Across RAs
| 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‑180268 | Considering slice information in SN modification procedure | LG Electronics | pCR |
10.2.1.3Mobility, DC
| 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‑180269 | Further consideration on RRC Inactive Assistance Information | LG Electronics | pCR |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
No
| available | No | |||
R3‑180270 | Correction on UL configuration | NTT DOCOMO INC. | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180271 | Stage 3 TP on CN selective awareness for RRC-INACTIVE state | LG Electronics | pCR |
10.6.5Others
| Yes |
No
| available | No | |||
R3‑180272 | CR for UL configuration | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180273 | Stage 2 TP on CN selective awareness for RRC-INACTIVE state | LG Electronics | draftCR |
10.6.5Others
| Yes |
No
| available | No | |||
R3‑180274 | Clarification on resource coordination | NTT DOCOMO INC. | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180275 | CR for Clarification on resource coordination | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180276 | Addition of cause | NTT DOCOMO INC. | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180277 | CR for addition of cause | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180278 | Neccesary addition on resource coodination | NTT DOCOMO INC. | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180279 | CR on neccesary addition on resource coodination | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180280 | clarification and correction on S1 for EN-DC | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180281 | clarification and correction on X2 for EN-DC | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180282 | TNL address discovery for Option 3 | LG Electronics | discussion |
31.3.3TNL Address Discovery for Option 3
| Yes |
No
| available | No | |||
R3‑180283 | 5GS User Plane Protocol | Samsung | discussion | Approval |
10.1.4NG/Xn/F1 UP Encapsulation Header
| 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 |
10.1.4NG/Xn/F1 UP Encapsulation Header
| Yes |
No
| available | No | ||
R3‑180285 | User inactivity monitoring in CU-DU architecture | Samsung, KT | draftCR | Approval |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180286 | TP for TS 38.473 on user inactivity monitoring | Samsung, KT | draftCR | Approval |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180287 | Discussion on UE Attached Indication procedure | LG Electronics | discussion |
10.10.1General
| Yes |
No
| available | No | |||
R3‑180288 | Update of QoS parameters | Huawei | pCR |
10.1.1Content QoS Flow Level Parameters
| 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‑180289 | Essential corrections for EN-DC | Huawei, Nokia, Nokia Shanghai Bell | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180290 | Rapporteur cleanup for 38.401v15.0.0 | NEC | draftCR | Decision |
10.11Stage 2 Updates
| Yes |
No
| available | No | ||
R3‑180291 | Baseline CR to capture remaining FFS of TS 38.401 | NEC | draftCR | Decision |
10.11Stage 2 Updates
| Yes |
No
| available | No | ||
R3‑180292 | mandatory/optional IEs in 36.423 | NEC | discussion | Decision |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180293 | Activation/Deactivation indication in EN-DC X2 | NEC | discussion | Decision |
31.3.1Essential Corrections
| 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 |
10.10.8Others
| Yes |
No
| available | No | ||
R3‑180295 | Spare field and future extension | NEC | discussion | Decision |
10.9.4Others
| Yes |
No
| available | No | ||
R3‑180296 | Adding MeNB UE X2AP ID Extension | NEC | draftCR | Decision |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180297 | NR Frequency and Time Resource Granularity | NEC | discussion | Decision |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| Yes |
No
| available | No | ||
R3‑180298 | TP on QoS flow level parameters for TS 38.413 | NEC | pCR | Decision |
10.1.1Content QoS Flow Level Parameters
| 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 |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | ||
R3‑180300 | RLC Mode indication in F1AP | NEC | draftCR | Decision |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180301 | Data forwarding during Xn Handover | Huawei | other |
10.5.5.3Xn-Based Handover Aspects
| 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 |
10.5.5.3Xn-Based Handover Aspects
| Yes |
No
| available | No | |||
R3‑180303 | Feature supporting over V1 | Huawei | discussion | Agreement |
12.3Others
| Yes |
No
| available | No | ||
R3‑180304 | Baseline CR to capture remaining FFS over X2 for EN-DC | Huawei, Nokia, Nokia Shanghai Bell | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180305 | Removal of unnecessary limitation on discarding | NTT DOCOMO INC. | discussion |
10.9.2PDCP Duplication
| Yes |
No
| available | No | |||
R3‑180306 | CR on Removal of unnecessary limitation on discarding | NTT DOCOMO INC. | draftCR |
10.9.2PDCP Duplication
| Yes |
No
| available | No | |||
R3‑180307 | clarification and correction on U-plane for EN-DC | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180308 | Applicability on AMBR for F1 | NTT DOCOMO INC. | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180309 | CR for applicability on AMBR for F1 | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180310 | Cell activation over configuration update | NTT DOCOMO INC. | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180311 | CR on Cell activation over configuration update | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180312 | clarification and correction on F1 for EN-DC | NTT DOCOMO INC. | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180313 | Further consideration on mechanism for simultaneously releasing multiple UE contexts | NTT DOCOMO INC. | discussion | Approval |
10.8.2.8Others
| Yes |
No
| available | No | ||
R3‑180314 | Further consideration on how to acquire status of re-transmitted packets | NTT DOCOMO INC. | discussion |
10.9.3Centralized Retransmission
| Yes |
No
| available | No | |||
R3‑180315 | CR on how to acquire status of re-transmitted packets | NTT DOCOMO INC. | draftCR |
10.9.3Centralized Retransmission
| Yes |
No
| available | No | |||
R3‑180316 | Further consideration on data existence indication for split bearer | NTT DOCOMO INC. | discussion | Approval |
10.9.3Centralized Retransmission
| Yes |
No
| available | No | ||
R3‑180317 | CR on data existence indication for split bearer | NTT DOCOMO INC. | draftCR |
10.9.4Others
| Yes |
No
| available | No | |||
R3‑180318 | Load management on X2 and F1 | NTT DOCOMO INC. | discussion | Approval |
10.10.8Others
| Yes |
Yes
| revised | No | R3‑180372 | |
R3‑180319 | TNL address discovery for NSA | NTT DOCOMO INC. | discussion | Approval |
31.3.3TNL Address Discovery for Option 3
| Yes |
No
| available | No | ||
R3‑180320 | Inter-system handover from EPS to 5GS | KT Corp. | discussion |
10.5.5Data Forwarding (both intra- and inter-system)
| 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‑180321 | Data forwarding for NG Handover | Huawei | other |
10.5.5.2NG-Based Handover Aspects
| 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 |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | |||
R3‑180323 | Security Aspects of CP-UP Split Architecture | Vodafone Group Plc | discussion | Decision |
23.4Security Aspects
| Yes |
No
| available | No | ||
R3‑180324 | [DRAFT]LS on security issue for CP-UP separation | Samsung R&D Institute UK | LS out | Approval |
23.4Security Aspects
| Yes |
No
| available | No | ||
R3‑180325 | Discussion on RAN support of edge computing in NR | CMCC | discussion | Decision |
10.15Others
| Yes |
No
| available | No | ||
R3‑180326 | Clarification on slice availability | CMCC | discussion | Decision |
10.2.2Slice Unavailability
| 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‑180327 | Discussion on backhaul signaling exchange for NR frame structure | CMCC | discussion | Decision |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| Yes |
No
| available | No | ||
R3‑180328 | Discussion on reference QoS profile for default DRBs | CMCC | pCR | Approval |
10.1.2Default QoS
| Yes |
NoProposal 1: CN to include the reference QoS profile in the NAS-level QoS profiles configured to RAN
| available | No | ||
R3‑180329 | List of FFSs for MR-DC (For Information) | ZTE | other |
10.8.2.1General
| Yes |
No
| available | No | |||
R3‑180330 | QoS management over F1 | CMCC | discussion | Decision |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180331 | Introduction of DRB ID for EN-DC | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180332 | Considerations on HRL | Huawei | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180333 | Clarification on HRL for EN-DC | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180334 | Clarification on HRL for EN-DC | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180335 | Clarification on HRL for EN-DC | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180336 | Clarification on HRL for EN-DC | Huawei | pCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180337 | Clarifications on the QoS parameters | Huawei | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180338 | Handling inconsistency in QoS parameters | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180339 | Further considerations on secondary RAT data volume reporting | Huawei | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180340 | LTE-NR UL sharing in overlapping and adjacent spectrum | Huawei, Vodafone | discussion |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| Yes |
No
| available | No | |||
R3‑180341 | Support of LTE-NR coexistence over X2 | Huawei, Vodafone | draftCR |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| Yes |
No
| available | No | |||
R3‑180342 | pCR to 38.473 on PDCP duplication | Huawei | other | Approval |
10.9.2PDCP Duplication
| Yes |
No
| available | No | ||
R3‑180343 | Further discussions on QoS info transfer over F1 | Huawei | other | Approval |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180344 | pCR to 38.473 on QoS info transfer over F1 | Huawei | other | Approval |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180345 | CR to 38.473 on the introduction of UE AMBR over F1 | Huawei | draftCR | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180346 | pCR to 38.473 on Paging delivery over F1 | Huawei | other | Approval |
10.10.5Paging
| Yes |
No
| available | No | ||
R3‑180347 | System information delivery over F1 interface | Huawei | discussion | Decision |
10.10.2System Information
| Yes |
No
| available | No | ||
R3‑180348 | CR to BL 38.473 on System information delivery over F1 interface | Huawei | other | Approval |
10.10.2System Information
| Yes |
No
| available | No | ||
R3‑180349 | Further discussion on RRC reestablishment | Huawei | other | Approval |
10.10.3UE Initial Access, State Transitions
| Yes |
No
| available | No | ||
R3‑180350 | Discussions on Security handling for CP-UP separation | Huawei | discussion | Decision |
23.4Security Aspects
| 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 |
23.4Security Aspects
| Yes |
No
| available | No | ||
R3‑180352 | Further discussions on UE context management | Huawei | discussion | Approval |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180353 | Further discussions on UE context management related with EN-DC operation | Huawei | discussion | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180354 | CR to 38.473 on UE context management procedure related with EN-DC operation | Huawei | draftCR | Decision |
31.3.1Essential Corrections
| 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 |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180356 | pCR to 38.473 on the introduction of HandoverPreparationInformation for SA operation | Huawei | other | Approval |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180357 | Further discussions on the content of serving cell info | Huawei | discussion | Approval |
10.10.1General
| Yes |
No
| available | No | ||
R3‑180358 | Presence of gNB-DU system information in F1 setup request | Huawei | discussion | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180359 | CR to 38.473 on the presence of gNB-DU system information | Huawei | draftCR | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180360 | Presence of UE radio capability in CU to DU RRC information | Huawei | discussion | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180361 | CR to 38.473 on the presence of UE Radio capabilities | Huawei | draftCR | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180362 | Discussions on the presence of serving cell info in F1 Setup | Huawei | discussion | Decision |
31.3.1Essential Corrections
| 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 |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180364 | Further discussion on measurement gap configuration | Huawei | discussion | Decision |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180365 | CR to 38.473 on measurement gap configuration | Huawei | draftCR | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180366 | CR to 38.473 on gNB-CU behaviour without DU to CU RRC information | Huawei | draftCR | Approval |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180367 | Further discussions on confirmation to gNB-DU about completion of RRC messages | Huawei | discussion | Decision |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180368 | Cause values for QoS flow offloading | Huawei | pCR |
10.8.2.1General
| Yes |
No
| available | No | |||
R3‑180369 | Support of SN counter check | Huawei | pCR |
10.8.2.1General
| Yes |
No
| available | No | |||
R3‑180370 | User Plane security impact on NG interface | Huawei | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180371 | User Plane security impact on Xn interface | Huawei | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180372 | Load management on X2 and F1 | NTT DOCOMO INC. | discussion | Approval |
10.10.8Others
| Yes |
No
| available | No | R3‑180318 | |
R3‑180373 | [Draft] Reply LS on User Plane Security Policy | Huawei | LS out |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180374 | Support of QoS and slice for MR-DC with 5GC Alt1 | Huawei | pCR |
10.8.2.1General
| Yes |
No
| available | No | |||
R3‑180375 | Support of QoS and slice for MR-DC with 5GC Alt2 | Huawei | pCR |
10.8.2.1General
| Yes |
No
| available | No | |||
R3‑180376 | Discussions on Energy Efficiency leftovers | Huawei, Qualcomm Incorporated | discussion | Approval |
10.8.2.8Others
| Yes |
No
| available | No | ||
R3‑180377 | QoS parameters to align with SA2 | Ericsson | pCR |
10.1.1Content QoS Flow Level Parameters
| 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 |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | |||
R3‑180379 | Notification Control and QoS flow release | Ericsson | pCR |
10.1.1Content QoS Flow Level Parameters
| 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 |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | |||
R3‑180381 | Delay critical GBR QoS flows – stage 3 solution | Ericsson | pCR |
10.1.1Content QoS Flow Level Parameters
| 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 |
10.1.1Content QoS Flow Level Parameters
| Yes |
No
| available | No | |||
R3‑180383 | Further Discussion on QoS setting for default DRBs | Ericsson | discussion | Agreement |
10.1.2Default QoS
| 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‑180384 | Slice configuration at NG and Xn Setup | Ericsson | pCR |
10.2.1.2Configuration, NG/Xn Setup, Config Update, Context Setup
| 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 |
10.2.1.2Configuration, NG/Xn Setup, Config Update, Context Setup
| Yes |
No
| available | No | |||
R3‑180386 | Mobility procedures for Slicing | Ericsson | pCR |
10.2.1.3Mobility, DC
| 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 |
10.2.1.3Mobility, DC
| Yes |
No
| available | No | |||
R3‑180388 | Support of multiple signalling TNL associations per AMF | Ericsson | discussion | Agreement |
10.5.1Multiple SCTP Associations and Related Mechanisms
| 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 |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180390 | Support of multiple signalling TNL associations per AMF | Ericsson | draftCR |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180391 | Support of multiple signalling TNL associations per AMF – TP for 38.401 | Ericsson | other |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180392 | Support of multiple signalling TNL associations per AMF – TP for 38.413 | Ericsson | pCR |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180393 | Support of multiple signalling TNL associations per AMF – TP for 38.423 | Ericsson | pCR |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180394 | [DRAFT] reply LS on N2 requirements and procedures (To: SA2) | Ericsson | LS out |
10.5.1Multiple SCTP Associations and Related Mechanisms
| Yes |
No
| available | No | |||
R3‑180395 | NG handover | Ericsson | pCR |
10.5.2.1Common Aspects
| 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 |
10.5.2.1Common Aspects
| Yes |
NoProposal 1: RAN3 to include a PDU session failed to setup list in Path Switch Request.
| available | No | |||
R3‑180397 | TAC Extension for NR and NG-RAN | Ericsson | pCR |
10.5.3NG-RAN Node Identification on NG and Xn
| 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 |
10.5.3NG-RAN Node Identification on NG and Xn
| 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 |
10.5.3NG-RAN Node Identification on NG and Xn
| Yes |
No
| available | No | |||
R3‑180400 | Handling of End Marker in HO and DC | Ericsson | discussion | Agreement |
10.5.5.2NG-Based Handover Aspects
| 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 |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | |||
R3‑180402 | Corrections to PDU Session Resource information | Ericsson | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180403 | RRC_INACTIVE – NG-RAN aspects | Ericsson | discussion | Agreement |
10.6.1NG-RAN Area Concepts for RRC_INACTIVE Mode
| Yes |
No
| available | No | ||
R3‑180404 | NG based UE context retrieval and RAN paging | Ericsson | draftCR |
10.6.1NG-RAN Area Concepts for RRC_INACTIVE Mode
| Yes |
No
| available | No | |||
R3‑180405 | On Coexistence between RRC inactive and dual connectivity | Ericsson | pCR |
10.6.5Others
| Yes |
No
| available | No | |||
R3‑180406 | Support of RRC_INACTIVE and MR-DC with 5GC | Ericsson | draftCR |
10.6.5Others
| Yes |
No
| available | No | |||
R3‑180407 | [DRAFT] reply LS on coexistence between RRC inactive and dual connectivity (To: SA2, RAN2, Cc:-) | Ericsson | LS out |
10.6.5Others
| Yes |
No
| available | No | |||
R3‑180408 | PDU session split at UPF | Ericsson | pCR |
10.8.2.3Control of Various NGEN-DC DRB Options
| Yes |
No
| available | No | |||
R3‑180409 | Handling of UE UL-AMBR | Ericsson | discussion | Agreement |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180410 | Handling of UE UL-AMBR | Ericsson | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180411 | Keeping a stable PDCP anchor | Ericsson | discussion | Agreement |
10.8.5Others
| Yes |
No
| available | No | ||
R3‑180412 | Keeping a stable PDCP anchor – draft CR for 37.340 | Ericsson | draftCR |
10.8.5Others
| Yes |
No
| available | No | |||
R3‑180413 | Support for keeping a stable PDCP anchor at HO and inter-node resume | Ericsson | draftCR |
10.8.5Others
| Yes |
No
| available | No | |||
R3‑180414 | Support for keeping a stable PDCP anchor at Path Switch | Ericsson | draftCR |
10.8.5Others
| Yes |
No
| available | No | |||
R3‑180415 | Support for keeping a stable PDCP anchor at HO | Ericsson | draftCR |
10.8.5Others
| Yes |
No
| available | No | |||
R3‑180416 | Keeping a stable PDCP anchor – TP for 38.413 | Ericsson | pCR |
10.8.5Others
| 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 |
10.8.5Others
| Yes |
No
| available | No | |||
R3‑180418 | Support for keeping a stable PDCP anchor at HO and inter-node resume | Ericsson | draftCR |
10.8.5Others
| Yes |
No
| available | No | |||
R3‑180419 | F1 TNL associations | Ericsson | other |
10.10.1General
| Yes |
No
| available | No | |||
R3‑180420 | TP for F1 TNL associations | Ericsson | other |
10.10.1General
| Yes |
No
| available | No | |||
R3‑180421 | Cells information from gNB-DU to gNB-CU | Ericsson | other |
10.10.1General
| Yes |
No
| available | No | |||
R3‑180422 | System information delivery | Ericsson | other |
10.10.2System Information
| Yes |
No
| available | No | |||
R3‑180423 | System information exchange over F1 | Ericsson | other |
10.10.2System Information
| Yes |
No
| available | No | |||
R3‑180424 | Corrections to Inactive to Other State procedures over F1 | Ericsson | other |
10.10.3UE Initial Access, State Transitions
| Yes |
No
| available | No | |||
R3‑180425 | UE radio capabilities over F1 | Ericsson | other |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180426 | Cell information over F1 | Ericsson | other |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180427 | UE context Setup over the F1 | Ericsson | other |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180428 | UE Reject Indication and gNB-DU admission result | Ericsson | other |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180429 | Further analysis on inactivity monitoring | Ericsson | other |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180430 | Creation of signalling connection | Ericsson | other |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180431 | RRC Container in UE Context Setup Request | Ericsson | other |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180432 | RLC Mode indication | Ericsson | other |
10.10.7UE Context Management
| Yes |
No
| available | No | |||
R3‑180433 | Introduction of UE Reconfiguration Complete procedure | Ericsson | discussion | Agreement |
10.10.7UE Context Management
| Yes |
No
| available | No | ||
R3‑180434 | Notification control over F1 | Ericsson | other |
10.10.8Others
| Yes |
Yes
| revised | No | R3‑180504 | ||
R3‑180435 | LTE-NR radio resource allocation coordination | Ericsson | discussion | Agreement |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| Yes |
No
| available | No | ||
R3‑180436 | Time plan for WI on separation of CP and UP for split option 2 | Ericsson | discussion | Agreement |
23.1E1 General Principles
| Yes |
Yes
| revised | No | R3‑180505 | |
R3‑180437 | Security for split CU | Ericsson | discussion | Agreement |
23.4Security Aspects
| Yes |
No
| available | No | ||
R3‑180438 | [DRAFT] LS on security for CU-CP/UP separation | Ericsson | LS out |
23.4Security Aspects
| Yes |
No
| available | No | |||
R3‑180439 | Change of GTP TEID when UE resumes in same node | Ericsson | discussion | Agreement |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180440 | Change of GTP TEID when UE resumes in same node | Ericsson | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180441 | On Coexistence between suspend and dual connectivity | Ericsson | discussion | Agreement |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180442 | Support of suspend in EN-DC | Ericsson | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180443 | Support of suspend in EN-DC | Ericsson | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180444 | [DRAFT] reply LS on Coexistence between suspend and dual connectivity | Ericsson | LS out |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180445 | Correction on Transaction ID | Ericsson | discussion | Agreement |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180446 | CR for correction on Transaction ID | Ericsson | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180447 | Discussions on FFS IEs in X2 Setup | Ericsson | discussion | Agreement |
31.3.1Essential Corrections
| Yes |
No
| available | No | ||
R3‑180448 | Correction on UE-AMBR for EN-DC | LG Electronics | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180449 | TP for TS 38.411 | LG Electronics | pCR |
10.12.1TS 38.411/421 NG/Xn Layer 1
| Yes |
No
| available | No | |||
R3‑180450 | Delay Critical GBR indication from 5GC | Intel Corporation, Huawei | pCR | Agreement |
10.1.1Content QoS Flow Level Parameters
| 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 | ||
R3‑180451 | Most probable QoS profile indication from 5GC | Intel Corporation, Nokia, Nokia Shanghai Bell, Huawei, LGE | discussion | Decision |
10.1.2Default QoS
| 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‑180452 | Consideration for mobility across different RAs | Intel Corporation | discussion | Decision |
10.2.1.4Mobility Across RAs
| 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‑180453 | Consideration on RAN-Based Notification Area | Intel Coporation | discussion | Decision |
10.6.1NG-RAN Area Concepts for RRC_INACTIVE Mode
| No |
Yes
| withdrawn | Yes | ||
R3‑180454 | Consideration on RAN-Based Notification Area | Intel Coporation | draftCR | Agreement |
10.6.1NG-RAN Area Concepts for RRC_INACTIVE Mode
| Yes |
No
| available | No | ||
R3‑180455 | Flow Control enhancements for uplink PDCP duplication | Intel Corporation | discussion | Decision |
10.9.2PDCP Duplication
| Yes |
No
| available | No | ||
R3‑180456 | Flow Control enhancements for uplink PDCP duplication | Intel Corporation | draftCR | Agreement |
10.9.2PDCP Duplication
| Yes |
No
| available | No | ||
R3‑180457 | Flow Control enhancement for DRX | Intel Corporation | discussion | Decision |
10.9.4Others
| Yes |
No
| available | No | ||
R3‑180458 | Flow Control enhancement for DRX | Intel Corporation | draftCR | Agreement |
10.9.4Others
| Yes |
No
| available | No | ||
R3‑180459 | NG-AP Paging Procedure and Signaling | Intel Corporation | pCR | Agreement |
10.5.6Others
| Yes |
No
| available | No | ||
R3‑180460 | F1-AP Paging Procedure and Signaling | Intel Corporation | draftCR | Agreement |
10.10.5Paging
| Yes |
No
| available | No | ||
R3‑180461 | [DRAFT] LS on NAS level information in paging | Intel Corporation | LS out | Agreement |
10.5.6Others
| Yes |
No
| available | No | ||
R3‑180462 | On multiple SCTP associations for NG-C | Intel Corporation | pCR | Agreement |
10.5.1Multiple SCTP Associations and Related Mechanisms
| 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‑180463 | On multiple SCTP associations for F1-C | Intel Corporation | draftCR | Agreement |
10.10.1General
| Yes |
No
| available | No | ||
R3‑180464 | Considerations on supporting multiple SCTP associations in NG-c | Qualcomm Incorporated | discussion | Discussion |
10.5.1Multiple SCTP Associations and Related Mechanisms
| 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 | ||
R3‑180465 | Clarification on Allowed NSSAI in 38.413 | Huawei | pCR |
10.2.1.5Others
| 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 |
10.2.1.5Others
| 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 | |||
R3‑180467 | Xn Slice available information | Huawei | pCR |
10.2.1.2Configuration, NG/Xn Setup, Config Update, Context Setup
| 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 |
10.2.1.2Configuration, NG/Xn Setup, Config Update, Context Setup
| 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 |
10.2.1.2Configuration, NG/Xn Setup, Config Update, Context Setup
| Yes |
No
| available | No | |||
R3‑180470 | NG based mobility | Huawei | pCR |
10.2.1.3Mobility, DC
| 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‑180471 | Xn based mobility for inter-RA case | Huawei | draftCR |
10.2.1.4Mobility Across RAs
| 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 | |||
R3‑180472 | [DRAFT] LS regarding Xn based handover across different Registration Areas | Huawei | LS out |
10.2.1.3Mobility, DC
| Yes |
No
| available | No | |||
R3‑180473 | Xn based mobility | Huawei | draftCR |
10.2.1.3Mobility, DC
| 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 |
10.2.1.3Mobility, DC
| Yes |
No
| available | No | |||
R3‑180475 | TP for 38.413 for Xn based mobility signalling | Huawei | pCR |
10.2.1.3Mobility, DC
| Yes |
No
| available | No | |||
R3‑180476 | Temporarily unavailable slice | Huawei | pCR |
10.2.2Slice Unavailability
| 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‑180477 | NG Reset | Huawei | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180478 | NG overload control | Huawei | pCR |
10.5.6Others
| Yes |
No
| available | No | |||
R3‑180479 | Slice Information Exchange over NG | Huawei | pCR |
10.2.1.2Configuration, NG/Xn Setup, Config Update, Context Setup
| 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 | |||
R3‑180480 | Baseline CR to TS 38.470 covering agreements of RAN3#98 | Huawei | draftCR |
10.11Stage 2 Updates
| Yes |
No
| available | No | |||
R3‑180481 | Baseline CR to TS 38.473 covering agrements of RAN3#98 | Huawei | draftCR |
10.12.3Application Protocol
| Yes |
No
| available | No | |||
R3‑180482 | Enhanced ASN.1 coding | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180483 | Criticality for UE context management | Huawei | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180484 | Criticality for UE context management | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180485 | Transaction ID in F1AP | Huawei | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180486 | Transaction ID in F1AP | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180487 | Adding cause in context modification required | Huawei | discussion |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180488 | Adding cause in context modification required | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180489 | Rapporteur suggested updates to 38.473 | Huawei | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180490 | Data forwarding aspects for intra-system ACTIVE mobility and DC bearer type change | Ericsson | discussion |
10.5.5.1Common Aspects
| 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 |
10.5.5.2NG-Based Handover Aspects
| Yes |
No
| available | No | |||
R3‑180492 | Data forwarding aspects for intra-system ACTIVE mobility – TP for XnAP | Ericsson | pCR |
10.5.5.3Xn-Based Handover Aspects
| Yes |
No
| available | No | |||
R3‑180493 | Data forwarding aspects for intra-system ACTIVE mobility – TP for 37.340 | Ericsson | draftCR |
10.5.5.4Dual Connectivity Related Aspects
| Yes |
No
| available | No | |||
R3‑180494 | Removing data forwarding from the corresponding node for EN-DC | Ericsson | draftCR |
10.5.5.5Others
| Yes |
No
| available | No | |||
R3‑180495 | Removing data forwarding from corresponding node for MR-DC – XnAP TP | Ericsson | pCR |
10.5.5.5Others
| Yes |
No
| available | No | |||
R3‑180496 | PDU Session, QoS flow and DRB control for NG-RAN DC | Ericsson | pCR |
10.8.2.3Control of Various NGEN-DC DRB Options
| Yes |
No
| available | No | |||
R3‑180497 | Bearer harmonization in NG-RAN - XnAP TP | Ericsson | pCR |
10.8.2.4Control of NGEN-DC SRB Options
| No |
No
| reserved | No | |||
R3‑180498 | X2AP corrections for agreed EN-DC BL CR | Ericsson | draftCR |
31.3.1Essential Corrections
| Yes |
No
| available | No | |||
R3‑180499 | Signaling support for LTE-NR Coexistence in Overlapping and Adjacent Spectrum | AT&T | discussion | Agreement |
10.14.1LTE-NR Coexistence in Overlapping and Adjacent Spectrum
| Yes |
No
| available | No | ||
R3‑180500 | Handling of remaining stage 3 FFSs for NSA ANR | Nokia, Nokia Shanghai Bell | other |
31.3.1Essential Corrections
| Yes |
No
| available | No | R3‑180220 | ||
R3‑180501 | Use case for NG Paging Relay and NG context fetch ? | Nokia, Nokia Shanghai Bell | discussion | Approval |
10.6.4UE Context Transfer
| Yes |
No
| available | No | ||
R3‑180502 | On the reference QoS profile for the default DRBs | China Telecommunications | agenda | Discussion |
10.1.2Default QoS
| 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 |
10.1.2Default QoS
| Yes |
No
| available | No | |||
R3‑180504 | Notification control over F1 | Ericsson | other |
10.10.8Others
| Yes |
No
| available | No | R3‑180434 | ||
R3‑180505 | Time plan for WI on separation of CP and UP for split option 2 | Ericsson, KT, Vodafone | discussion | Agreement |
23.1E1 General Principles
| Yes |
No
| available | No | R3‑180436 | |
R3‑180506 | Introduction of Retrieve UE Context messages | Huawei | pCR | Approval |
10.6.4UE Context Transfer
| Yes |
No
| available | No | R3‑180160 | |
R3‑180507 | Way Forward on inactive aspects | Huawei, Nokia, CATT, Qualcomm Incorporated, NEC, Deutsche Telekom, Nokia Shanghai Bell,Samsung | discussion | Decision |
10.6.1NG-RAN Area Concepts for RRC_INACTIVE Mode
| 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 |
10.10.3UE Initial Access, State Transitions
| Yes |
No
| available | No |