Tdoc List
2018-01-22 08:55
| 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 |
NoProposal 1: Capture the support for non-3GPP access in Stage-3.
| 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 |
NoProposal 1: MN is not allowed to refuse the SN Release Required message from SN in Release 15.
Proposal 2a: In case MN has already initiated the SN change and configured the target SN, then the source SN shall always follow MN’s release request based on proper cause value, e.g. SCG mobility.
Proposal 2b: In case MN has already initiated the Inter-MN handover with SN change or MN to eNB Change, then the source SN shall always follow MN’s release request based on proper cause value, e.g. MCG mobility.
Proposal 3: Upon receiving SN Release Reject message, MN shall not refuse the SN Change Required message in following certain period of time per own implementation.
| available | No | |||
| R3‑180013 | Correction of SN Release in TS37.340 | ZTE | draftCR |
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 |
NoProposal 1: “EN-DC to gNB change” with single RRC reconfiguration and full configuration can be supported in this version of the protocol, following the normal inter-system HO procedure.
Proposal 2: “Inter-RAT MN to ng-eNB/gNB Change” with single RRC reconfiguration and full configuration, i.e. from NGEN-DC to gNB or from NE-DC to ng-eNB Change can be supported in this version of the protocol.
Proposal 3: gNB to EN-DC change with single RRC reconfiguration and full configuration can be supported in this version of the protocol.
Proposal 4: Inter-RAT ng-eNB/gNB to MN Change with single RRC reconfiguration and full configuration, i.e. from gNB to NGEN-DC or from ng-eNB to NE-DC Change can be supported in this version of the protocol.
| available | No | |||
| R3‑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 |
NoProposal 1: Both MN and SN may trigger the change of PDU session between single and two NG-U tunnel terminations at the NG-RAN.
Proposal 2: MN decides whether the secondary NG-U tunnels are to be setup or released.
| available | No | |||
| R3‑180027 | Correction of Mode Change between Single and Two NG-U tunnels in TS37.340 | ZTE | draftCR |
10.8.2.2Stage 2
| Yes |
No
| available | No | |||
| R3‑180028 | Correction on Split SRB configuration | ZTE | discussion |
31.3.1Essential Corrections
| Yes |
NoProposal 1: Clarify in Stage 3 specification that the MN can initiate a split SRB release during a SN modification procedure.
Proposal 2: Clarify in Stage 3 specification that the MN can initiate a split SRB establishment during a SN modification procedure.
| 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 |
NoProposal 1: For the case of SN terminated split bearer to/from SN terminated MCG bearer change, the SN triggers it by using the SN initiated SN modification procedure and then the MN cannot reject it.
| 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 |
NoProposal 1: During the DRB initial setup process (no data forwarding is needed), MN semi-statically allocates a set of DRB ids to be used by SN, and MN/SN decides the mapping of concerned QoS Flows on MCG/SCG side independently.
Proposal 2: During DRB level lossless offloading, MN/SN should inform the peer side about the “original mapping info of concerned QoS Flows on MCG/SCG side” (so peer side can follow that mapping for lossless purpose), and the receiving SN/MN can consequently allocate and feedback the corresponding DL/UL data forwarding GTP TEID to the initiating node.
Proposal 3: During QoS Flow level offloading (may be loss), MN/SN needs not to inform the peer side about the “original mapping info of concerned QoS Flows on MCG/SCG side” (so peer side performs the local remapping independently), but the receiving SN/MN can still consequently allocate and feedback the corresponding DL/UL data forwarding GTP TEID to the initiating node.
Proposal 4: MN can inform SN the DL GTP TEID info for each SN terminated split bearer in step 5: SN reconfiguration Complete message.
| available | No | |||
| R3‑180035 | Further Discussion and pCR on MR-DC@5GC Specific Xn Messages Structures | ZTE | discussion |
10.8.2.3Control of Various NGEN-DC DRB Options
| Yes |
NoProposal 1a: In order to reflect the “one-to-many mapping” relation between one PDU Session and DRBs of different types, the QoS Flow level info for each QoS Flow of each PDU Session should be included in MR-DC specific Xn messages e.g. “S-NODE ADDITION REQUEST/ACKNOWLEDGE” message.
Proposal 1b: The existing IE “QoS Flow Level QoS Parameters” should replace the original fake IE “PDU session Level QoS Parameters”, associated to each QFI in each PDU Session.
Proposal 2a: For DRB initial setup, MN can only decide the mapping between locally anchored QoS Flows and DRBs on MN side, meanwhile telling SN which QoS Flows are to be offloaded to SN side, as well as their associated DRB bearer type.
Proposal 2b: SN may need to tell MN the mapping outcome of locally anchored QoS Flows and DRBs on SN side.
Proposal 3a: To update the message structure of “S-NODE ADDITION REQUEST/ACKNOWLEDGE” firstly, based on above principles.
Proposal 3b: Once P3a is agreed and consolidated, similar changes will be applied for other MR-DC@5GC specific Xn messages in TS38.423.
| available | No | |||
| R3‑180036 | Correction of QoS Flow to DRB Mapping in MR-DC@5GC in TS37.340 | ZTE | draftCR |
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 |
NoProposal 1: When the info of DRB (SCG split bearer) No. and QoS Flow mapping is updated on SN side, SN may need to actively inform MN about that change with SN initiated modification procedure.
Proposal 2: SN is able to trigger one step direct bearer type change from SCG bearer to SCG split bearer with SN initiated SN modification procedure alone, but not direct bearer type change from SCG split bearer to SCG bearer.
Proposal 3: New IE “PDU sessions To Be Modified List” should be included in S-NODE MODIFICATION REQUIRED message, and new IE “M-NG-RAN node GTP Tunnel Endpoint List” should be also included in S-NODE MODIFICATION CONFIRM message.
Proposal 4: To endorse the TPs in Annex below.
| available | No | |||
| R3‑180038 | Stage3 pCR for SN Initiated SN Modification Procedure | ZTE | pCR |
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 |
NoProposal 1: To clarify whether “Centralized Retransmission” between gNB-DUs can be supported together with EN-DC, where UE needs to support more than two MAC entities/independent RLs.
Proposal 2a: In Release 15, UE can be configured with at least two gNB-DUs, to support “special split bearer type”, i.e. switching mode operation as in intra-NR/inter-DU DC mode.
Proposal 2b: In Release 15, it is FFS whether UE can be configured with at least two gNB-DUs, to support other bearer type operation as generalized in intra-NR/inter-DU DC mode. The exact working model is FFS.
Proposal 3: In Release 15, for “Centralized Retransmission” mode between gNB-DUs, all configured RLs/CGs should be kept active and cannot be deactivated.
| 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 |
NoProposal 1: For the AMF change with Xn Interface scenario, the TgNB shall not send RRCconnectionresume Msg to the UE before the TAMF gets the UE NAS context, even though TgNB can get the UE AS context from the SgNB over Xn.
Proposal 2: RAN2/3 should discuss the CN Area Update procedure in INACTIVE State for the AMF change with Xn interface scenario.
Proposal 3: If the TgNB cannot connect to the SAMF, as baseline it can respond to the RRCConnectionresumerequest with RRCConnectionSetup message directly, and the UE should indicate upper layer upon receiving RRCConnectionSetup message.
Proposal 4: For the scenario of AMF change with Xn interface, to take the CN update procedure as shown in Figure 5 as enhancement.
Proposal 5: To ask RAN2 to include the 5G-GUTI in the RRCConnectionresumerequest message.
Proposal 6: For the scenario of AMF change without Xn interface, to take the CN update procedure as shown in the Figure 6 as enhancement.
| available | No | |||
| R3‑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 |
NoProposal 1: Introduce a new NGAP procedure to inform NG-RAN node that an AMF will be unavailable.
| available | No | |||
| R3‑180050 | Discussion on Overload Control in NGAP | Nokia, Nokia Shanghai Bell | pCR |
10.5.6Others
| Yes |
NoProposal 1: Introduce Overload Start procedure, and Overload Stop procedure in NGAP.
Proposal 2: The overload control related to slice needs to wait for SA2 clarification. It can be introduced later once SA2 clarifies it.
| available | No | |||
| R3‑180051 | TP for NGAP Overload Control | Nokia, Nokia Shanghai Bell | pCR |
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 |
NoProposal 1: Since only the solution based on the exchange of the consumed throughput enables solving both problems identified in the past, it should be enabled in MR-DC.
Proposal 2: The reporting of the consumed throughput should be based on the user plane signaling in a dedicated tunnel.
Proposal 3: The above solution should be applied to EN-DC, too.
| available | No | ||
| 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 |
NoProposal 1: include a Paging Priority IE (values 1-256) in DL NAS Transport message and all relevant NGAP initiating messages.
Proposal 2: include PPI in the QoS profile to enable Paging Policy Differentiation done by NG-RAN for RRC_ inactive state to be aligned with Paging Policy Differentiation in 5GC.
| available | No | ||
| R3‑180093 | Text Proposal for Paging Priority | Nokia, Nokia Shanghai Bell | pCR | Agreement |
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 |
NoProposal 1: agree the following Text Proposal to remove the FFS on Xn Assistance Data for Paging IE and include only the Paging Attempt Information IE.
| available | No | ||
| R3‑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 |
NoProposal 1: MDT is not supported by NG/Xn interfaces in Rel-15.
Proposal 2: Trace shall be supported by NG/Xn interfaces in Rel-15.
| available | No | |||
| R3‑180098 | NG interface management procedures | Nokia, Nokia Shanghai Bell | pCR |
10.5.6Others
| Yes |
NoProposal 1: For the NG SETUP FAILURE message, the S1 SETUP FAILURE message from TS 36.413 can be reused as baseline.
Proposal 2: For the NG RESET message, the RESET message from TS 36.413 can be reused as baseline.
Proposal 3: For the NG RESET ACKNOWLEDGE message, the RESET ACKNOWLEDGE message from TS 36.413 can be reused as baseline.
Proposal 4: For the ERROR INDICATION message, the ERROR INDICATION message from TS 36.413 can be reused as baseline.
| available | No | |||
| R3‑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 |
NoProposal 1: Add a statement that absence of an IE changes the position of subsequent IEs on octet level.
Proposal 2: Define one SN field only, which contains either “Highest transmitted” or “Highest delivered” PDCP SN. A flag can indicate presence of this IE (not present when PDUs have not been transmitted), and a second flag indicates the type.
Proposal 3: Modify text on actions of the PDCP entity to consider feedback on “successfully transmitted PDCP SN”.
Proposal 4: RAN3 is requested to discuss whether there is need for further enhancement of the feedback in case of outage for RLC AM bearers.
| 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 |
NoProposal 1): Both DRB level and Flow level offloading should be supported for MR-DC with 5GC.
Proposal 2): DRB level offloading should be supported for both MN terminated bearers and SN terminated bearers, for which the DRB level configuration information of the concerned flows in MN should be transmitted to SN.
Proposal 3): Flow level lossless offloading should be supported, for which Xn signaling enhancement is needed.
| available | No | |||
| R3‑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 |
NoProposal 1: RAN Paging failure handling of DL user plane data: DL data is discarded. the NG-RAN node may keep the N2 connection active or initiate the N2 connection release procedure based on local configuration in NG-RAN.
Proposal 2: A Unified mechanism for DL signalling from AMF (includes DL class 1 Signalling and DL NAS PDU) triggered RAN paging: old NG-RAN responds to AMF with failure cause: UE context transfer, AMF re-starts the procedure after Path switch to Serving NG-RAN.
Proposal 3: RAN Paging failure handling of DL NAS PDU: RAN node shall initiate the NAS signalling connection release procedure to move the UE to CM-IDLE state and indicate to the AMF NAS NON DELIVERY INDICATION with non-delivered NAS PDU contained.
Proposal 4: RAN Paging failure handling of DL class 1 Message: RAN node shall initiate the N2 connection release procedure to move the UE to CM-IDLE state and indicate to the AMF with failure cause
Proposal 5: For UE context release command triggered RAN paging, UE context release can be indicated as a cause in Xn: Retrieve UE context response message to notify serving NG-RAN release UE after context retrieval.
Proposal 6: Unified procedure for UE context release command triggered RAN Paging for normal case and failure case: Old NG-RAN responds with UE context release complete to AMF before receiving retrieve UE context request from new NG-RAN
Proposal 7: when UE in RRC INACTIVE, if RAN has received Location reporting control from AMF with reporting type indication single stand-alone report, the RAN shall perform RAN Paging before report the location to AMF, If reporting type indicating continuously reporting whenever the UE changes cell, the RAN shall send a Location Report message to AMF including UE’s last known location with time stamp.
| available | No | ||
| R3‑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 |
NoProposal 1: Basic functionality for VoNR call setup and operation shall be supported in R15.
Proposal 2: Basic functionality for VoNR to VoLTE handover/fallback shall be supported in R15.
Proposal 3: Performance optimization purpose features shall be supported in R15 on best effort basis.
Proposal 4: VoNR specific MDT/SON is not supported in R15.
Proposal 5: Voice specific features which have been defined for several years but never commercially deployed are not supported in R15.
Proposal 6: Among the performance optimization features, commercially deployed VoLTE features should be prioritized based on user experience gain, e.g. call setup success rate, mobility reliability, power, coverage, voice quality.
| available | No | ||
| R3‑180109 | UE radio capability handling | Qualcomm Incorporated | discussion | Approval |
10.5.6Others
| Yes |
NoProposal 1: UE radio capability is uploaded to CN with UE CAPABILITY INFO INDICATION procedure.
Proposal 2: RAN may compose full UE radio capability from multiple partial UE radio capability reporting. The uploaded UE radio capability always overwrites the cached UE radio capability in CN.
Proposal 3: UE radio paging capability is generated by RAN and uploaded to CN in UE CAPABILITY INFO INDICATION procedure.
Proposal 4: UE radio paging capability shall be included in CN paging on NG-C and RAN paging on Xn-C.
Proposal 5: UE radio capabilities are coordinated between Master node and Secondary node of DC/MR-DC in MN to SN container and SN to MN container.
| available | No | ||
| R3‑180110 | UE capability Indication (P-CR 38.413) | Qualcomm Incorporated | pCR | Approval |
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 |
NoProposal 1: Agree the NG Paging parameters proposed in last column of table 1.
Proposal 2: Agree the associated TP
| available | No | ||
| R3‑180113 | Paging procedure (P-CR 38.413) | Qualcomm Incorporated | pCR | Approval |
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 |
NoProposal 1: Add secondary EUTRA Cell ID and associated UL Coordination Information, DL Coordination Information into MeNB Resource Coordination Information, for case 1 and 3.
Proposal 2: Add secondary NR Cell ID and associated UL Coordination Information, DL Coordination Information into SgNB Resource Coordination Information, for case 2 and 4.
| 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 |
NoProposal1: It is proposed to use F1 UL/DL RRC message transfer messages to complete the AS security info exchange over air interface before CU trigger the UE context management procedure towards DU.
Proposal2:To approve the corresponding stage2 TP update on Initial UE access for TS38.401 as below.
| available | No | |||
| R3‑180123 | QoS information transfer over F1 interface | ZTE Corporation | discussion |
10.10.7UE Context Management
| Yes |
NoProposal1: It is proposed to adopt the following principles:
- CU perform QoS flow to DRB mapping;
- CU signals DRB QoS config per DRB level
or QoS flow profile per DRB level together with QoS flow to DRB mapping list;
- DU decides DRB QoS config and signals a list of admitted/failed DRBs.
Proposal2:To approve the above QoS related IE structure in UE CONTEXT SETUP REQUEST message/UE CONTEXT MODIFY REQUEST message.
| 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 |
NoProposal1:Add Context Release Indication IE over the DL RRC MESSAGE TRANSFER message from CU to DU to indicate to release the UE context in DU side.
Proposal1: Approve the above updates to BL CR for TS38.473.
| available | No | |||
| R3‑180126 | Left issues on Inactive UE over F1 interface | ZTE Corporation | discussion |
10.10.3UE Initial Access, State Transitions
| Yes |
NoProposal1:Update the signalling flow on RRC connected to RRC inactive with one-step F1 UE context release.
Proposal2:Update the signalling flow on RRC inactive to other states as above.
Proposal3:To approve the corresponding stage2 TP update on Inactive UE for TS38.401 as below.
| available | No | |||
| R3‑180127 | Discussion on Bearer Management over E1 interface | ZTE Corporation | discussion |
23.3E1 Application Protocol (E1AP)
| Yes |
NoProposal1: Both CU-C and CU-U can trigger Bearer Management Procedure over E1 interface.
Proposal3: The following messages are proposed to be used for Bearer Management Procedure:
| available | No | |||
| R3‑180128 | Further consideration on E1 interface setup | ZTE Corporation | discussion |
23.3E1 Application Protocol (E1AP)
| Yes |
NoProposal1: The E1 interface setup can be initiated by both the CU-CP and the CU-UP.
Proposal2: During E1 setup procedure, the above mentioned info need to be considered to be exchanged between CU-CP and CU-UP:
The CU-CP side: CU-CP ID;
The CU-UP side: CU-UP ID, CU-UP capability Info.
| available | No | |||
| R3‑180129 | Discussion on security key generation over E1 interface | ZTE Corporation | discussion |
23.4Security Aspects
| Yes |
NoProposal: RAN3 is kindly suggested to send an LS to SA3 and RAN2 to clarify the mechanism for AS security activation and configuration.
| 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 | pCR |
10.9.1Fast Retransmission
| Yes |
NoProposal1:The explicit indication method is proposed to be used to identify the retransmitted packets with DL_USER_DATA.
Proposal2: The DDDS mechanism should be enhanced to support the retransmission packet handling, which can make the PDCP packet retransmission more efficient.
| 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 |
NoProposal1: It is proposed that load management over F1 interface should be initiated by gNB-CU.
| 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 |
NoProposal 1: Fast activation and deactivation of PDCP UL/DL duplication should be supported in CU-DU split architecture.
Proposal 2: Whether CU or DU node determines activation/deactivation of PDCP AM/UM duplication, it is based on the channel quality detected by DU.
Proposal 3: When the channel quality of the two legs are not good, the NW should activate duplication and deliver PDCP PDUs to both legs. In other cases, the NW should deactivate duplication.
Proposal 4: For the intra-DU duplication (i.e. CA based duplication), DU makes the final decision on activation/deactivation by channel quality of both legs. One F1 message “Duplication Command” is introduced to request the CU to activate/deactivate duplication in the case of DL duplication.
Proposal 5: For the intra-DU duplication(i.e. CA based duplication), the CU should perform activation/deactivation duplication according to the received “Duplication Command”.
Proposal 6: RAN3 is kindly asked to approve the above signalling flow for intra-DU CA based activation/deactivation procedure( be applied to both UL/DL duplication).
Proposal 7: For the intra-CU inter DU duplication (i.e. DC based duplication), if the activation commands from both legs are received in some period, then the CU should perform duplication activation . Otherwise, if the deactivation command is received on either leg, then the CU should perform duplication deactivation operation.
Proposal 8: RAN3 is kindly asked to approve the above signalling flow for inter-DU/intra-CU based activation/deactivation procedure( be applied to both UL/DL duplication).
Proposal 9: For DRB duplication , introducing duplication command over F1-U is preferred.
| available | No | |||
| R3‑180136 | Left FFS on paging over F1 | ZTE Corporation | discussion |
10.10.5Paging
| Yes |
NoProposal 1: Legacy UE identity Index value IE could be reuse as input parameter for PF/PO calculation. The FFS of UE Identity Index value IE could be removed.
Proposal 2: S-TMSI could be as UE Paging Identity, but it is pending by RAN2. We suggest to remove the FFS of UE paging identity IE, and add a note “pending to RAN2”.
Proposal 3: For CN paging, the gNB-CU should include UE specific CN DRX in F1 paging message, and in the case of RAN-based paging the gNB-CU only need to include the shortest cycle of the UE specific CN DRX and UE specific RAN DRX cycle. The FFS of Paging DRX IE could be removed.
Proposal 4: The FFS of Paging Priority IE could be removed.
Proposal5: The FFS of Cell-ID List IE could be removed.
Proposal6: The TP for 38.473 is provided in Annex.
| available | No | |||
| R3‑180137 | Discussion on SCG failure | CATT | discussion |
31.3.1Essential Corrections
| Yes |
NoProposal 1: It is proposed for MN to forward the measResultSCG-r15 included in SCGFailureInformation message to SN in case of SCG failure in both RRC Transfer message and SgNB Release Request message.
Proposal 2: It depends on RAN2 decision i.e. whether failureType IE exists in FailureReportSCG-ToOtherRAT on whether failureType IE should be introduced in RRC Transfer message and SgNB Release Request message.
| 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 |
NoProposal 1: In case of supporting network slicing, the slice related information (e.g. S-NSSAI) needs to be included in F1 SETUP and gNB-DU Configuration Update procedure.
Proposal 2: RAN3 to consider TA based approach or Cell based approach to support slices information transmission over F1 interface.
Proposal 3: In case of supporting PDU session related slices, the slice related information (e.g. S-NSSAI) needs to be added per DRB with F1AP UE Context management procedures.
Proposal 4: Add network slicing support in running TS 38.470 CR.
| available | No | |||
| R3‑180140 | Handling of DL signallings | CATT | draftCR |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
NoProposal 1: Non-UE associated DL signalling should not trigger RAN paging, while the UE associated DL signalling may trigger RAN paging procedure.
Proposal 2: Upon receiving the NG connection release command from AMF, gNB could release the resources related to the NG connection without triggering RAN paging.
Proposal 3: If the paged UE accesses from the anchor gNB, the anchor shall send corresponding response message to AMF to indicate the DL signalling has been successfully handled.
Proposal 4: If the paged UE accesses from the gNB other than the anchor, the anchor shall send corresponding failure message to AMF with a specific cause value, e.g. “UE context transfer” , AMF may resend the DL signalling to the new gNB after the path switch procedure triggered by the new gNB is completed.
Proposal 5: If RAN paging is triggered by DL class 1 signalling and the RAN paging is failed, the RAN node shall initiate the UE context release procedure, and may response failure to the DL signalling before the NG connection release.
Proposal 6: Discuss and agree the stage 2 TP as in the section 5 below.
Proposal 7: Discuss and agree the stage 3 TP in [3].
| available | No | |||
| R3‑180141 | TP for 38.413 on DL signalling handling | CATT | pCR |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
NoProposal 4: If the paged UE accesses from the gNB other than the anchor, the anchor shall send corresponding failure message to AMF with a specific cause value, e.g. “UE context transfer” , AMF may re-send the DL signalling to the new gNB after the path switch procedure triggered by the new gNB is completed.
| available | No | |||
| R3‑180142 | Content of RAN Paging | CATT | pCR |
10.6.3NG-RAN Paging
| Yes |
NoProposal 1: It’s essential to prioritize RAN paging to guarantee the high priority services in case of massive UEs are under paging.
Proposal 2: The serving gNB will generate the paging priority for RAN paging, and this will be provided to the neighbor gNBs in the RAN paging message.
Proposal 3: The gNBs nearby should apply the same/similar paging policy.
Proposal 4: Remove the IE Assistance Data for Paging from RAN Paging.
Proposal 5: Discuss and agree the stage 3 TP for RAN paging in section 5.
| available | No | |||
| R3‑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.3Xn-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.3Xn-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 |
NoProposal 1: It is proposed to capture the procedural text for EN-DC X2 setup into stage 3 spec.
Proposal 2: If the eNB requires a new cell list for a neighbour en-gNB by EN-DC configuration update message, it will replace the old one by the new cell list.
Proposal 3: It is proposed to capture the NR Neighbour Information handling into the EN-DC X2 setup section.
Proposal 4: It is proposed to capture the eNB handling for en-gNB’s served NR cell information update into the EN-DC configuration update section.
| 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 |
NoProposal: it is proposed RAN3 to consider the two options above to support en-gNB X2 TNL address discovery.
| 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 |
NoProposal: change the RRC Inactive Assistance Information IE to Optional in relevant NGAP messages.
| available | No | ||
| R3‑180156 | DL signalling handling in INACTIVE state | Huawei | discussion | Approval |
10.6.2Assistance Information for RAN Paging and RRC_INACTIVE Handling
| Yes |
NoProposal 1: For DL Class1 signalling triggered RAN paging, if the UE responds in the anchor gNB, the anchor gNB could initiate corresponding Uu procedure for the DL signalling, and send successful response to AMF.
Proposal 2: For Non AMF Initiated UE Context Release DL class 1 signalling triggered RAN paging, if the UE responds paging in a new gNB, the anchor gNB could indicate a failure response to the AMF with an appropriate cause such as “UE context transfer in INACTIVE state”.
Proposal 3: If AMF Initiated UE Context Release Request is received for RRC_INACTIVE UEs, RAN paging should be initiated to avoid potential UE state mismatch and implicit detachment.
Proposal 4: For AMF Initiated UE Context Release Request triggered RAN paging, if the UE responds paging in a new gNB, the anchor gNB could indicate a release indication in Retrieve Context Response message to the new gNB and respond AMF with UE Context Release Complete.
Proposal 5: For DL NAS PDU triggered RAN paging, if the UE responds paging in anchor gNB, the anchor gNB could send the NAS PDU to the UE.
Proposal 6: For DL NAS PDU triggered RAN paging, if the UE responds paging in a new gNB, the anchor gNB could send the NAS PDU back to the AMF via NAS NON DELIVERY INDICATION message.
| available | No | ||
| R3‑180157 | RAN Paging Priority handling | Huawei | pCR | Approval |
10.6.3NG-RAN Paging
| Yes |
NoProposal 1: It is proposed to remove the FFS for RAN paging priority IE in XnAP spec.
Proposal 2: It is proposed to include service priority in all relevant NGAP messages, which may include:
- PDU SESSION RESOURCE SETUP REQUEST
- PDU SESSION RESOU RCE RELEASE COMMAND
- PDU SESSION RESOURCE MODIFY REQUEST
- UE CONTEXT RELEASE COMMAND
- UE CONTEXT MODIFICATION REQUEST
- DOWNLINK NAS TRANSPORT
| available | No | ||
| R3‑180158 | Text proposals for NGAP for RAN Paging Priority handling | Huawei | pCR | Approval |
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 |
NoProposal 1: It is proposed RAN3 to capture the procedure of periodic RNAU without anchor relocation in stage 2 spec
| 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 |
NoProposal 1: F1-AP UE Reconfiguration Complete message, which aims to inform the DU about the completion of UE RRC connection reconfiguration, shall be introduced at least when NR RRC reconfiguration procedure is performed via another RAN node and there is no random access procedure towards the considered DU.
Proposal 2: For case 2?4, it is optimal to reuse F1-AP UE Reconfiguration Complete message to inform the DU about the successful completion of the RRC Connection Reconfiguration.
| 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 |
NoProposal 1: It is proposed to agree on the following principle for security key handling.
- Since one UE can be served by multiple CU-UPs (for different services), it is better that CU-CP does the key co-ordinations. Thus, all the air interface security keys (Ciphering and Integrity protection) derivations are located in CU-CP.
- Security algorithm selection is located at CU-CP and selected algorithm is communicated to CU-UP(s).
- The security keys (Ciphering and Integrity protection) for the DRBs are derived at the CU-CP and communicated to the CU-UP(s) via E1-AP Bearer Setup.
- CU-UP(s) requests the CU-CP for new keys (Key refresh) when required.
Proposal 2: Unless RAN3 sees fundamental difference from Dual Connectivity or other existing mechanisms in RAN, RAN3 should proceed with their specification work. No official LS to SA3 seems not necessary at this point.
| available | No | |||
| R3‑180166 | Discussion on SgNB initiated SgNB Modification procedure | CATT | discussion |
31.3.1Essential Corrections
| Yes |
NoProposal 1: It is proposed to update the stage 2/3 TS as alternative 1 to reflect that PDCP change indication is not needed in the SgNB Modification request message following a SN initiate SN modification procedure.
Proposal 2: It is proposed to update the stage 2 TS to reflect the scenario that MN decides to perform bearer type change and the SN needs to provide the respective RRC information.
| 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 |
NoProposal 1:It is proposed to specify in the spec that gNB-CU would send DL PDCP PDUs to the gNB-DU with the previous DL GTP TEID until it performs PDCP re-establishment or PDCP data recovery, and use the new DL GTP TEID starting with the PDCP re-establishment or data recovery.
Proposal 2: It is proposed to specify in the spec that gNB-CU would send DL PDCP PDUs to the gNB-DU with the previous DL GTP TEID until it performs PDCP re-establishment or PDCP data recovery, and use the new DL GTP TEID starting with the PDCP re-establishment or data recovery.
| 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 |
NoProposal 1: For DRX Cycle IE description, it is proposed to change to “the gNB-DU shall use the provided value from the gNB-CU.”
Proposal 2: For PSCell ID IE, it is proposed to change the IE name to “PCell ID IE” as mandatory in UE Context Setup Request message, and description to “PCell Identifier in gNB, and PSCell identifier in case of SgNB.”
Proposal 3: It is proposed to add C-RNTI IE in UE Context Setup Response message.
Proposal 4: It is proposed to allow gNB-DU to reselect different PSCell or PCell from the one indicated by gNB-CU, and introduce PCell IE in UE Context Setup/Modification Response messages.
Proposal 5: It is proposed to agree on the CR provided in [1] for TS 38.473.
| 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 |
NoProposal 1: For maxnoofIndividualF1ConnectionsToReset, it is proposed to change the value to 65536.
Proposal 2: It is proposed to agree on the CR provided in [1] for TS 38.473.
| 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 |
NoProposal 1: For initial DDDS triggering, it is proposed to add text “As soon as the corresponding node detects the successful lower layer configuration and UE attachment for the corresponding data bearer, the corresponding node shall send initial DL DATA DELIVERY STATUS frame to the node hosting the NR PDCP entity.” in TS 38.425.
Proposal 2: For Spare bit field handling, it is proposed to add text “If the receiver recognizes the unknown spare field is set to “1”, it shall release the data bearer.” in TS 38.425.
Proposal 3: It is proposed to agree on the CR provided in [1] for TS 38.425.
| 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 |
NoProposal: Agree on the ProtocolIE-ContainerList to be defined as a list of ProtocolIE-Container instead of ProtocolIE-SingleContainer as provided in the corresponding CR [1] for TS 38.473.
| available | No | |||
| R3‑180179 | Discussion on UE Context Management procedure | CATT | draftCR |
10.10.7UE Context Management
| Yes |
NoProposal 1: It is proposed to include QoS flow level information in the UE Context Setup Request, UE Context Setup Response, UE Context Modification Request and UE Context Modification Response message.
Proposal 2: In case the DU cannot admit all the QoS flows for one DRB, the CU will keep the mapping relation unchanged and just remove the failed QoS flows from the corresponding DRB.
Proposal 3: It is proposed to include RRC-Container IE in the UE Context Setup Request message.
Proposal 4: It is proposed to remove the Mobility Control Info IE in the UE Context Setup Response message.
Proposal 5: It is proposed to include RRC Container IE in the UE Context Modification Confirm message.
Proposal 6: It is proposed to introduce new UE Context Modification Refuse message for unsuccessful case.
Proposal 7: It’s proposed to agree the text proposal for the Stage 2 and Stage 3 TS in the [2].
| 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 |
NoProposal: Consider the release or re-establish of RLC entity as the triggering condition of Downlink Data Delivery Status frame with the last DL status report indicator.
| 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 |
NoProposal 1: The CU entity can not only add a SCell, but also delete a Scell, correspondingly the SCell To Be removed List IE should be introduced to the UE Context Modification Request message.
Observation 2: Allowing two nodes to change PSCell at the same time can cause RRM decision conflict, resulting in unnecessary signalling redundancy.
Proposal 2: The selection and change of PSCell should be decided by only one node.
Proposal 3: Introduce a PScell ID IE in UE Context Modifciation Response/UE Context Setup Response message.
Proposal 4:Introduce a PScell ID IE in UE Context Modification Required message.
Proposal 5: Include UE-AMBR IE in the UE Context Setup Request and UE Context Modification Request message.
Proposal 6: Include RLC mode IE in the UE Context Setup Request and UE Context Modification Request message.
| 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 |
NoProposal 1: It is proposed to support load management function over F1-C for both direction by indicating such request and related parameters to the other node.
- Overloaded at gNB-CU: gNB-DU should reject or limit the RRCConnectionRequest messages from the UEs. gNB-CU should indicate such request and related parameters. However, special handling (i.e. exceptional acceptance) should be supported for Emergency calls, High Priority Access calls, Mobile Terminating calls.
- Overloaded at gNB-DU: gNB-CU should not send or limit UE CONTEXT SETUP REQUEST, UE CONTEXT MODIFICATION REQUEST, PAGING messages to the gNB-DU. gNB-DU should indicate such request and related parameters. Same principle for special handling mentioned in Overloaded at gNB-CU should be applied.
Proposal 2: It is proposed to agree on the TP for TS 38.470 and TS 38.473 provided in the Annex and [1], respectively.
| 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 |
NoProposal 1: It is proposed to agree on Option 1: gNB-CU signals QoS profile per DRB level, gNB-DU either accepts or rejects.
Proposal 2: It is proposed to agree on the TP for TS 38.470 and TS 38.473 provided in the Annex and [1], respectively.
| 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 |
NoProposal 1: It is proposed to support user inactivity monitoring in the node hosting NR PDCP.
Proposal 2: It is proposed to agree on TP for TS 38.401 provided in the Annex.
| available | No | |||
| R3‑180191 | TP on support of delta configuration during handover procedure | CATT | draftCR |
10.10.4Mobility Aspects
| Yes |
NoProposal 1: It is proposed to introduce HandoverPreparationInformation IE in CU to DU container to enable delta configuration during handover procedure.
Proposal 2:It is proposed to change the Prensence of UE Radio capabilities IE as Optional.
Propsoal 3:It is proposed to update the semantic description of UE Radio capabilities as UE-CapabilityRAT-Container, as defined in TS 38.331 [8].
Proposal 2: It is proposed to introduce a new procedure for gNB-CU to request low layer configuration in gNB-DU for the specific UE.
| available | No | |||
| R3‑180192 | Discussion on V1 leftover issues | Huawei, China Unicom | pCR |
12.2CU-DU Interface, Functions, and Procedures
| Yes |
NoProposal 1: remove eNB-DU management function in V1 interface functions.
Proposal 2: Further discuss how to support Load Management function over V1 interface after F1 discussion.
Proposal 3: remove the “Editor Note: the support of Initial UE access is FFS.” in RRC Message Transfer Procedures.
| 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 |
NoProposal 1: Data forwarding for fresh data through PDU session tunnel during some QoS flows of DRB offloading.
Proposal 2: Data forwarding for PDCP SDU(SDAP PDU) with SDAP header through PDU session tunnel during some QoS flows of DRB offloading.
Proposal 3: PDCP SDUs with SN and PDCP SDU(SDAP PDU) without SDAP header is transmitted through DRB in the source node during some QoS flows of DRB offloading.
Proposal 4: Data forwarding mechanism may follow above P1/P2/P3 when all the QoS flows of the DRB offloading and the DRB is kept in source node.
Proposal 5: Data forwarding mechanism may follow Xn HO when all the QoS flows of the DRB offloading and the DRB is released in source node.
| available | No | |||
| 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 |
NoProposal 1: Introduce the text “This ID shall be copied from the request message.” in the semantic description of existing Transaction ID IE in any response message for Class 1.
Proposal 2: Introduce Transaction ID IE in Criticality Diagnostics IE.
Proposal 3: Add the text “or not terminated (e.g. transaction ID unknown in response message)” in the section 10.4 of TS 38.413 to support Transaction ID.
| 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 |
NoProposal 1): To adopt the same principles of EN-DC to MR-DC on UE-AMBR.
Proposal 2): MN decides the split of session AMBR and indicates the portion of session AMBR to be respected by the SN.
Proposal 3): The split result of session AMBR for MN and SN is not indicated to AMF/SMF/UPF.
Proposal 4): To adopt the Stage 2 change for TS 37.340.
| available | No | |||
| R3‑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 |
NoProposal 1: Operation in larger areas with context kept in RAN, and without strict Xn support requirement, should be the object of further study (with target release FFS). For RRC-INACTIVE, it should be assumed that the RNA has Xn support in the normal case.
| available | No | ||
| R3‑180218 | Stage 2 corrections for NSA ANR | Nokia, Nokia Shanghai Bell | discussion |
31.3.1Essential Corrections
| Yes |
NoProposal 1: Clarify in TS 36.300 that the eNB keeps its X2 connected en-gNBs updated about its cell list when there is any configuration change.
Proposal 2: Clarify in TS 36.300 that the en-gNB, for NR cells already signalled to the eNB, keeps its X2 connected eNBs updated when there is any configuration change.
Proposal 3: Enable the described nominal mechanism in stage 2 and stage 3.
Proposal 4: Leave out, for the time being, description of “NoHO” attribute from section 22.3.4a.
Proposal 5: Introduce a new NRT attribute “No EN-DC”.
| 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 |
NoProposal: Add NR-ARFCN for SUL to EN-DC X2 Setup and EN-DC Configuration Update procedures (FDD and TDD).
| 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 |
NoProposal 1: Use a symmetric registration scheme and bi-directional message routing function for TNL discovery based on ‘intermediate node’.
Proposal 2: In stage 3, enhance the existing X2AP Message Transfer to support en-gNB ID.
Proposal 3: In stage 3, enhance EN-DC X2 setup to transfer TNL information.
| 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 |
NoProposal 1: The signalling should support use case where only UL is shared (overlapping spectrum), and use case where both DL and UL are shared (overlapping spectrum).
Proposal 2: Introduce a new class 1 procedure which could be named E-UTRA-NR Cell Resource Coordination procedure, composed of EUTRA-NR RESOURCE REQUEST and EUTRA-NR RESOURCE RESPONSE messages.
Proposal 3: Turn WA1 and WA2 into agreements for expression of LTE PUSCH and PDSCH resources.
Proposal 4: Await RAN2 progress for TDD UL/DL configuration, with WA to align X2 signaling on definition in TS 38.331.
| 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 |
NoProposal: update Reroute NAS Request to align with SA2.
| 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 |
NoProposal 1: Broadcast Time Interval IE should be included into the F1 Setup Response message.
Proposal 2: Broadcast Time Interval IE can be contained into the System Information Delivery procedure.
Proposal 3: When other SI has to be modified based on the situation of radio interface, the gNB-DU should trigger the gNB-DU Configuration Update procedure to provide the gNB-CU with the information which can assist the SI modification.
Proposal 4: It is proposed to agree the TP for TS 38.473
| available | No | |||
| R3‑180234 | QoS aspect in UE context management function | LG Electronics, KT Corp. | draftCR |
10.10.7UE Context Management
| Yes |
NoProposal 1: Option 3 should be adopted to establish the DRB.
Proposal 2: It is proposed to agree the TP for TS 38.470.
| 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 |
NoProposal 1: for UL PDCP duplication, the decision of activation/deactivation can be made by DU (e.g., CA case), and the CU is unnecessary to know the decision.
Proposal 2: for DL PDCP duplication, DU can send the PDCP duplication activation/deactivation indication to CU, and the final decision is made by CU.
| available | No | ||
| R3‑180239 | PDCP duplication support over X2 | Samsung | draftCR | Approval |
10.9.2PDCP Duplication
| Yes |
NoProposal 1: CA duplication can be applied to MN terminated SCG bearer.
Proposal 2: two DL/UL tunnels can be set up for MN terminated SCG bearer to support CA duplication.
| available | No | ||
| R3‑180240 | Radio link outage/resume for DL and UL | Samsung | draftCR | Approval |
10.9.3Centralized Retransmission
| Yes |
NoProposal: the radio link outage/resume can be indicated by differentiating DL and UL.
| available | No | ||
| R3‑180241 | UE attached indication for mobility procedure | Samsung | draftCR | Approval |
10.10.4Mobility Aspects
| Yes |
NoProposal: the target gNB-DU can indicate the gNB-CU that UE has successfully attached. After that, the gNB-CU starts the DL data transmission to the target gNB-DU.
| 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 |
NoProposal 1: the CU needs inform DU the RLC mode optionally.
Proposal 2: the CU can send an indication, e.g., whether to schedule the UL or not for a radio bearer, to DU.
Proposal 3: the CU can send the Minimum Requested E-RAB Level QoS Parameters to DU, and DU can response CU with the Admitted QoS Parameter.
| 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 |
NoProposal 1: the gNB-CU decides whether to configure SUL or non-SUL or both to the UE.
Proposal 2: the gNB-DU decides the carrier used for, e.g., contention free RA procedure, PUSCH, if both SUL and non-SUL are configured to the UE.
| 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 |
NoProposal1: the exiting procedure is reused to support the transition report initiation and cancellation:
- Initial UE Context Setup procedure, UE Context Modification procedure,
- Path Switch Request procedure, NG Handover Request procedure.
Proposal2: A new class2 message is needed for RRC_inactive transtion report.
Proposal3: Define stage2 to reflect the SA2 agreement.
| available | No | ||
| R3‑180253 | Stage 3 TP on RRC Inactive Transition Report | Samsung | pCR | Approval |
10.6.5Others
| Yes |
No
| available | No | ||
| R3‑180254 | Rapporteur’s update to TS38.425v100 | Samsung | draftCR | Approval |
10.9.4Others
| Yes |
NoThis paper provides the following updates to TS38.425 v1.0.0.
- Add the abbreviation of “MR-DC” in section 3.2.
MR-DC is used in the spec but not defined.
- In section 5.4.2.1 bullet c, delete the reference to section 5.2 but add the clear description about the minimum desired buffer size.
As in the list from “a” to “e”, only “c” refers to 5.2. It’s better to make the sentence self-explaining instead of getting the full context by referencing another section.
- Replace “data bearer” to “data radio bearer”. Because flow control is per data radio bearer. Change DRB to “data radio bearer” as well for consistent.
- Other editorial changes.
| 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 |
NoProposal 1: SN may re-map an offloaded QoS flows to another (potentially new) DRB.
Proposal 2: MN should have a freedom in deciding which individual QoS flows it wants to offload to SN (i.e. only certain QoS flows from a DRB could be moved to SN). Same applies to SN and SCG split bearers.
Proposal 3: For SCG split bearer, MN allocates Xn tunneling for DL data transmission according to new mapping and includes the information in the S-NODE RECONFIGURATION COMPLETE.
Proposal 4: For SCG split bearer, new mapping information is added in the S-NODE ADDITION REQUEST ACK message and S-NODE MODIFICATION REQUEST ACK message.
| available | No | ||
| R3‑180260 | Security Aspects for CU-UP | Samsung | discussion | Approval |
23.4Security Aspects
| Yes |
NoProposal It is proposed to send a LS to ask SA3 about security issue for option 1.
| available | No | ||
| R3‑180261 | TNL Address Discovery in Option 3 | Samsung | discussion | Approval |
31.3.3TNL Address Discovery for Option 3
| Yes |
NoProposal 1 If proxy eNB is introduced and is not the same entity of MeNB in EN-DC, the proxy eNB is only used for TNL Address retrieval. It is not used for subsequent X2AP procedures of EN-DC.
Proposal 2 If proxy eNB is introduced, it is better to define two new messages instead of changing the existing message defined for HeNB.
Proposal 3 It is proposed No specification impact for the eNB to get IP address of gNB.
| 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 |
NoProposal 1: The inclusion of the RRC Inactive Assistance information IE in Initial Context Setup Request, Handover Request, and Path Switch Request Acknowledge message should be optional field in TS 38.413.
Proposal 2: It is proposed to agree the text proposal in the appendix of this contribution.
| available | No | |||
| R3‑180270 | Correction on UL configuration | NTT DOCOMO INC. | discussion |
31.3.1Essential Corrections
| Yes |
NoProposal1: RAN3 to add indication on UL configuration from the corresponding node to the node hosting PDCP via C-plane to request UL configuration.
| available | No | |||
| R3‑180271 | Stage 3 TP on CN selective awareness for RRC-INACTIVE state | LG Electronics | pCR |
10.6.5Others
| Yes |
NoProposal 1: RRC state reporting procedure should be defined to support the CN selective awareness for the RRC state transition.
Proposal 2: It is proposed to agree the text proposal in the appendix of this contribution.
| available | No | |||
| R3‑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 |
NoProposal 1: It is proposed to agree the text proposal in the appendix of this contribution.
| available | No | |||
| R3‑180274 | Clarification on resource coordination | NTT DOCOMO INC. | discussion |
31.3.1Essential Corrections
| Yes |
NoProposal 1: RAN3 to clarify that each bit indicates two PRBs in a subframe.
Proposal 2: RAN3 to clarify that the bitstring firstly goes to frequency domain and apply only corresponding DL/UL subframes.
Proposal 3: RAN3 to clarify that all PRBs in all DL subframes are intended to be used for transmission if DL Coordination Information is not included.
| 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 |
NoProposal: RAN3 to add cause for MCG mobility and SCG mobility.
| 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 |
NoProposal1: RAN3 to allow to include several MeNB Resource Coordination Information in gNB addition request.
Proposal2: RAN3 to allow eNB to indicate UE dedicated resource to gNB.
Proposal3: RAN3 to allow to include SCell DL resource coordination information in resource coordination information.
| 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 |
NoProposal): To use only the OAM configuration and DNS query mechanism for option 3 in Release-15.
| 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 |
NoProposal 1: Agree that gNB-DU should be able to manage the user inactivity timer and report the user inactivity event to CP in gNB-CU.
Proposal 2: Agree that CP in gNB-CU may configure the user inactivity timer value.
Proposal 3: Agree on the TP for TS 38.470.
| available | No | ||
| R3‑180286 | TP for TS 38.473 on user inactivity monitoring | Samsung, KT | draftCR | Approval |
10.10.7UE Context Management
| Yes |
NoProposal 1: Agree that gNB-DU should be able to manage the user inactivity timer and report the user inactivity event to CP in gNB-CU.
Proposal 2: Agree that CP in gNB-CU may configure the user inactivity timer value.
| available | No | ||
| R3‑180287 | Discussion on UE Attached Indication procedure | LG Electronics | discussion |
10.10.1General
| Yes |
NoProposal: It is unnecessary for the gNB-DU to indicate that the UE has successfully attached to the gNB-CU.
| 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 |
NoProposal 1: It is proposed to introduce the deactivation indication in EN-DC X2 setup procedure, i.e. to enable an en-gNB to inform its neighbour eNB a deactivated served NR cell at EN-DC X2 setup Request and response.
Proposal 2: eNB shall not ask en-gNB to activate a cell in EN-DC X2 setup response
Proposal 3: It is proposed to add NR Deactivation Indication IE in to the Served NR Cells To Add IE in EN-DC CONFIGURATION UPDATE message
Proposal 4: The same deactivation indication also to be in EN-DC Configuration Update Acknowledge from en-gNB to MeNB.
Proposal 5: The existing NR Deactivation Indication IE in EN-DC CONFIGURATION UPDATE message should be updated to include the value “activated”, potentially to rename the IE
| 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 |
NoProposal 1 : it is proposed to define the cell load information report from gNB-DU to gNB-CU.
Proposal 2: it is proposed to define in F1AP set of Resource Status Report procedures. The report from gNB-DU to gNB-CU is the basic as a starting for Rel-15 including Composite Available Capacity.
| available | No | ||
| R3‑180295 | Spare field and future extension | NEC | discussion | Decision |
10.9.4Others
| Yes |
NoProposal principle 1: it is proposed to agree a principle that, any new extension field shall not be added in the middle place of the PDU Type frame.
Proposal principle 2: it is proposed to agree a principle to introduce New IE Flags at the end of the PDU Type frame in the NG User Plane protocol (38.425). This IE Flag is to be introduced when first extension that need more bit or octet space in the frame.
| 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 |
NoProposal: Signaling of bitmaps with NR-PRB-level granularity (for frequency resources) and NR-symbol-level granularity (for time resources) can be used for resource coordination in LTE-NR coexistence scenarios.
| 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 |
NoProposal: RAN3 to remove unnecessary limitation on the usage that the discarding is for DL PDCP duplication.
| 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 |
NoProposal: RAN3 to add IE for UL AMBR.
| 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 |
NoProposal1: RAN3 to clarify that the gNB-DU shall initiate the gNB-DU Configuration Update procedure towards the gNB-CU if the gNB-DU fails to activate some cell(s)
Proposal2: RAN3 to allow DU to report “Cells Failed to be Deactivated List” in GNB-CU CONFIGURATION ACHKNOWLEDGE.
Proposal 3: RAN3 to define DU to report current status of activation/deactivation by gNB-DU configuration update
| 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 |
NoProposal 1: It is proposed to support the partial reset in the X2/Xn Reset procedure like the S1/F1 Reset procedure.
| available | No | ||
| R3‑180314 | Further consideration on how to acquire status of re-transmitted packets | NTT DOCOMO INC. | discussion |
10.9.3Centralized Retransmission
| Yes |
NoProposal 1: Define “retransmitted indication” in spare bit of PDU
Proposal 2: Introduce new IEs i.e. Delivered PDCP SN of retransmitted packets and Transmitted PDCP SN of retransmitted packets
| 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 |
NoProposal 1: Define indication from the node hosting PDCP to corresponding node i.e. “data exists” and “No data exists” for the bearer.
| 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 |
Nowe propose following WF.
WF1: RAN3 to introduce C-plane solution(s) for TNL address discovery.
WF2: RAN3 to narrow down C-plane solution(s) in RAN3# 99 based on comparison of each option.
| available | No | ||
| R3‑180320 | Inter-system handover from EPS to 5GS | KT Corp. | discussion |
10.5.5.2NG-Based Handover Aspects
| 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 |
NoProposal 1: Finer granularity of LADN service area configuration should be studied and specified.
Proposal 2: It is proposed to discuss the RAN assisted LADN service area detection and activation procedure as proposed.
| 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 |
NoProposal 1: Signalling that exchanged among gNBs should include the explicit DL/UL switching periodicity applied by the cell.
Proposal 2: Signalling that exchanged among gNBs for NR frame structure should provide a pattern which covers the DL and UL resources upper bound that the gNB can use.
Proposal 3: The DL and UL resources assigned by the gNB to the UE, which includes the resources that assigned by both cell-specific and UE-specific signalling, can only be chosen in the corresponding DL and UL resources that covered by the upper bound that exchanged among gNBs.
| 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 |
NoProposal 1: gNB-CU performs QoS flow to DRB mapping and decides QoS configuration for DRB
Proposal 2: gNB-CU signals DRB level QoS configurations to the gNB-DU over F1, and then the gNB-DU follows the DRB level QoS profile or rejects the DRB.
| 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 |
NoProposal: Capture in the abnormal conditions to ensure that the same serving PLMN value in HRL for the SgNB Addition Preparation and MeNB initiated SgNB Modification procedures.
| 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 |
NoProposal: The case where the values of QCI and ARP in the Full E-RAB Level QoS Parameters IE and Maximum MCG Admittable E-RAB Level QoS Parameters IE are not consistent, should be captured as abnormal conditions.
| 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 |
NoProposal 1: Secondary RAT Data Volume Report procedure shall be performed only for SCG bearer and split bearer.
Proposal 2: When count the data volume from secondary RAT, the data forwarded to MeNB should be excluded.
Proposal 3: For CA duplication, the same data should not be counted for twice.
Proposal 4: It needs operator input on how to count the duplicated data when DC duplication is configured.
| 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 |
NoProposal 1: UE specific TDM pattern should be exchanged between MeNB and SgNB for the UL sharing from UE perspective.
Proposal 2: Reuse the TDM pattern of single Tx for UL sharing from UE perspective.
| 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 |
NoProposal 1 It is proposed that gNB-DU determines the LogicalChannelIdentity for the primary path.
Proposal 2 It is proposed that gNB-DU provides LogicalChannelIdentity for the primary path over F1-interface.
Proposal 3 it is proposed that gNB-DU provides the mapping relationship between F1-U tunnel and LogicalChannelIdentity over F1 interface.
Proposal 4 If more than one UL GTP Tunnel Endpoint for one DRB are provided, it is proposed that the first UL GTP Tunnel Endpoint in the IE “Tunnels to Be Setup Item IEs” is associated with the primary path.
Proposal 5 It is proposed that gNB-DU makes the decision of activation/deactivation UL PDCP duplication.
| available | No | ||
| R3‑180343 | Further discussions on QoS info transfer over F1 | Huawei | other | Approval |
10.10.7UE Context Management
| Yes |
NoProposal 1 It is proposed that gNB-CU determines the DRB QoS based on the QoS flow information and the mapping between QoS flows and radio bearers.
Proposal 2 It is suggested to transfer QoS profile per-traffic flow from gNB-CU to gNB-DU over F1 interface.
Proposal 3 It is suggested to allow gNB-DU to accept or reject the addition of one DRB.
Proposal 4 It is proposed the gNB-CU provide both UE Aggregate Maximum Bit Rate and PDU session Aggregate Maximum Bit Rate to the gNB-DU.
Proposal 4bis It is proposed to include UE Aggregate Maximum Bit Rate IE and PDU session Aggregate Maximum Bit Rate IE into both F1AP message: UE CONTEXT SETUP REQUEST and UE CONTEXT MODIFICATION REQUEST.
Proposal 5 It is propose to add PDU session ID to be Setup/ Modified list into UE context management messages.
Proposal 6 It is suggested to reuse UE Aggregate Maximum Bit Rate IE and PDU session Aggregate Maximum Bit Rate IE for both NSA and SA operation.
Proposal 7 The S-NSSAI shall be included as one parameter of each PDU session in the related UE context management messages via F1 interface.
| available | No | ||
| R3‑180344 | pCR to 38.473 on QoS info transfer over F1 | Huawei | other | Approval |
10.10.7UE Context Management
| Yes |
NoProposal 1 It is proposed that gNB-CU determines the DRB QoS based on the QoS flow information and the mapping between QoS flows and radio bearers.
Proposal 2 It is suggested to transfer QoS profile per-traffic flow from gNB-CU to gNB-DU over F1 interface.
Proposal 3 It is suggested to allow gNB-DU to accept or reject the addition of one DRB.
Proposal 4 It is proposed the gNB-CU provide both UE Aggregate Maximum Bit Rate and PDU session Aggregate Maximum Bit Rate to the gNB-DU.
Proposal 4bis It is proposed to include UE Aggregate Maximum Bit Rate IE and PDU session Aggregate Maximum Bit Rate IE into both F1AP message: UE CONTEXT SETUP REQUEST and UE CONTEXT MODIFICATION REQUEST.
Proposal 5 It is propose to add PDU session ID to be Setup/ Modified list into UE context management messages.
Proposal 6 It is suggested to reuse UE Aggregate Maximum Bit Rate IE and PDU session Aggregate Maximum Bit Rate IE for both NSA and SA operation.
| 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 |
NoProposal 1: To introduce a list of UE Identity Index values and UE Paging identities in the paging message over F1.
Proposal 2: There is no need to introduce an explicit SI change/update indication over F1.
Proposal 3: It is proposed RAN3 agree the text proposals in the Annex part.
| available | No | ||
| R3‑180347 | System information delivery over F1 interface | Huawei | discussion | Decision |
10.10.2System Information
| Yes |
NoProposal 1 It is proposed that gNB-DU decides whether MSG1 or MSG 3 can be used to transmit SI request.
Proposal 2 It is proposed that area ID and the corresponding cell group for the associated SI/SIB should be determined by gNB-CU.
Proposal 2bis It is proposed that gNB-CU should provide area ID associated with SI/SIB to the gNB-DU, however the stage 3 details of area ID depends on RAN2 progress.
Proposal 3 It is proposed that gNB-DU determines the scheduling information of other SI, including SIB type, validity information, periodicity, SI-window information and SI-SIB mapping.
Proposal 3bis It is proposed that gNB-CU provides scheduling related information from NGC to the gNB-DU, e.g., Repetition Period, Extended Repetition Period, and Number of Broadcasts Requested for ETWS warning.
Proposal 4 It is proposed gNB-CU to provide SIB messages and gNB-DU to encode the final SI message.
Proposal 5 It is proposed to remove the Broadcast Time Interval IE in the baseline TS 38.473.
| 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 |
NoProposal 1 It is proposed RAN3 to agree the proposed call-flow for the RRC connected reestablishment procedure.
Proposal 2 It is proposed to agree the TP for TS 38.401 in the annex.
| available | No | ||
| R3‑180350 | Discussions on Security handling for CP-UP separation | Huawei | discussion | Decision |
23.4Security Aspects
| Yes |
NoProposal 1 It is proposed RAN3 discuss the security handling procedure.
Proposal 2 It is proposed RAN3 discuss which node to perform key update due to PDCP count wrap around.
Proposal 3 It is suggested to also ask SA3 if Counter Check will be supported for NR stand-alone
| 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 |
NoProposal 1 Iit is proposed to introduce Target Cell ID into UE CONTEXT SETUP/MODIFICATION REQUEST, and HandoverPreparationInformation into CU to DU RRC information.
Proposal 2 It is proposed to introduce HandoverPreparationInformation IE into CU to DU RRC information.
Proposal 3 Iit is proposed to remove MobilityControlInfo IE in UE CONTEXT SETUP RESPONSE.
Proposal 4 It is proposed other parameters in DRX-config are determined by gNB-DU.
| available | No | ||
| R3‑180353 | Further discussions on UE context management related with EN-DC operation | Huawei | discussion | Approval |
31.3.1Essential Corrections
| Yes |
NoProposal 1 It is proposed that PSCell/SCell change can only be triggered by the gNB-CU.
Proposal 1A It is proposed to add SCell to be Removed list IE into F1AP message UE CONTEXT MODICIATION REQUEST.
Proposal 1B It is proposed RAN3 discuss whether there is a need to add SCell failed to be setup list IE into F1AP message UE CONTEXT SETUP RESPONSE and UE CONTEXT MODIFICATION RESPONSE.
Proposal 2 It is proposed to add SCellIndex IE associated with SCell ID into UE Context Setup/Modification Request message.
Proposal 3 It is proposed that gNB-DU provides CellGroupConfig with full configuration indication if full configuration is applied.
| 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 |
NoProposal 1: It is proposed RAN3 discuss the possibility to include RAN2 defined IE of “ServingCellConfigCommon” in F1 SETUP REQUEST message.
| available | No | ||
| R3‑180358 | Presence of gNB-DU system information in F1 setup request | Huawei | discussion | Approval |
31.3.1Essential Corrections
| Yes |
NoProposal 1 It is proposed that gNB-CU indicates gNB-DU which cell should be barred in gNB-CU CONFIGURATION UPDATE.
Proposal 2 It proposed to remove gNB-DU system information IE in F1 SETUP REQUEST.
| 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 |
NoProposal 1 It is proposed to change the presence of “UE Radio capabilities” from mandatory to optional.
| 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 |
NoProposal: To make the IE “gNB-DU Served Cells List” as OPTIONAL.
| 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 |
NoProposal 1 It is proposed that gapoffset of FR2 is determined by gNB-DU and provided to gNB-CU as part of DU to DU RRC information.
Proposal 2 Before gNB-DU providing gapoffset of FR2, it should be discussed whether a request from gNB-CU is needed or not.
| 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 |
NoProposal 1: It is proposed RAN3 agree to introduce a mechanism of letting gNB-DU know a successful reconfiguration operation.
Proposal 2: It is proposed RAN3 discuss whether the rejection of RRC connection request by gNB-CU should be indicated to gNB-DU.
| available | No | ||
| R3‑180368 | Cause values for QoS flow offloading | Huawei | pCR |
10.8.2.1General
| Yes |
NoProposal: The above list of cause values should be included for each rejected QoS flow.
| available | No | |||
| R3‑180369 | Support of SN counter check | Huawei | pCR |
10.8.2.1General
| Yes |
No
| available | No | |||
| R3‑180370 | User Plane security impact on NG interface | Huawei | pCR |
10.5.6Others
| Yes |
NoProposal 1. From RAN3 perspective, 5GC needs to inform RAN whether the integrity protection and ciphering are needed or not during PDU session establishment.
Proposal 2. Indicators of integrity protection and ciphering activation are needed per PDU session in the PDU SESSION RESOURCE SETUP message.
| available | No | |||
| R3‑180371 | User Plane security impact on Xn interface | Huawei | pCR |
10.5.6Others
| Yes |
NoProposal: During Handover Preparation procedure, the indicators of integrity protection and ciphering activation are needed in HANDOVER REQUEST message.
| available | No | |||
| R3‑180372 | Load management on X2 and F1 | NTT DOCOMO INC. | discussion | Approval |
10.10.8Others
| Yes |
NoProposal1: Info reporting from gNB to provide knowledge to eNB about the load of NR carriers (exact contents FFS) should be supported over X2.
Proposal2: If the info reporting from gNB to provide knowledge to eNB about the load of NR carriers require info reporting from gNB-DU to gNB-CU (exact contents FFS), this should be supported over F1.
Proposal3: Info reporting from gNB-DU to provide knowledge to gNB-CU about the load of NR cells (exact contents FFS) should be supported over F1.
Proposal4: RAN3 to take contents in RESOURCE STATUS UPDATE currently defined in X2 as starting point of further discussing on exact contents of info reporting to provide knowledge about the load of NR carriers and NR cells
| 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 |
NoProposal: Capture one of the two alternatives in TS 38.423.
| available | No | |||
| R3‑180375 | Support of QoS and slice for MR-DC with 5GC Alt2 | Huawei | pCR |
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- RAN3 to agree that the Deactivation Indication is used to allow reactivation on request of the peer node
- RAN3 to confirm that the status of a cell which failed to be reactive needs to be updated
- MCC to minute “when Cell Activation Response message should be sent is let to implementation”
- MCC to minute “the timing of the initiation of Configuration Update messages towards other eNBs is also left to implementation”.
- X2AP LTE Legacy, X2AP EN-DC and XnAP NG-RAN Cell Activation procedures should be aligned
| 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 |
NoProposal 1 It is proposed to modify NGAP so that if a UE Context is requested in RAN, it also corresponds to a request to allocate resources for at least one PDU Session. Proposed NGAP modifications are in the Annex of this contribution.
| available | No | |||
| R3‑180403 | RRC_INACTIVE – NG-RAN aspects | Ericsson | discussion | Agreement |
10.6.1NG-RAN Area Concepts for RRC_INACTIVE Mode
| Yes |
NoProposal 1 It is proposed to introduce NG based RAN paging and UE Context retrieval as proposed in R3-180404.
| available | No | ||
| R3‑180404 | NG based UE context retrieval and RAN paging | Ericsson | draftCR |
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 |
NoIt is proposed to further discuss this topic in future meeting and to liaise back to SA2 our findings (see R3-180407).
It is also proposed to discuss the TP for 38.423 provided in the Annex, which covers a new class 2 procedure to indicate activity (on a per UE and a per DRB level) and additions to the MN initiated S-NG-RAN node Modification procedure.
| available | No | |||
| R3‑180406 | Support of RRC_INACTIVE and MR-DC with 5GC | Ericsson | draftCR |
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 |
NoThe summary of Text Proposal:
• In PDU session resource setup request/modify request, add the additional GTP-U tunnel information for splitting PDU session in UPF for uplink.
• In PDU session resource setup response/modify response, add information of which QoS flows in the PDU session are setup in SN, also include the additional GTP-U tunnel information for downlink.
Proposal 1: RAN3 to discuss and agree the proposed TP for supporting the PDU session splits at UPF.
| available | No | |||
| R3‑180409 | Handling of UE UL-AMBR | Ericsson | discussion | Agreement |
31.3.1Essential Corrections
| Yes |
NoConclusion 1: In order to allow flexible increase of UL throughput over each of the UL radio links participating in a UE DC split bearer configuration, monitoring and enforcement of the UL UE AMBR shall be performed in the node hosting the PDCP termination of the UL split bearer, i.e. at the gNB-CU-UP
| 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 |
NoIt is proposed to introduce the possibility to inform the logical RAN node, that finally becomes host of the PDCP entity in one of the outlined scenarios, about the possibility to keep the GTP-U termination point at RAN for the RAN-CN UP interface.
| 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 |
NoProposal 1: Agree on the proposed mechanism for establishing and releasing additional SCTP associations and remove the FFS from the BL CR for TS 38.473.
Proposal 2: Agree on the proposed mechanism for distributing the UE-associated messages over the multiple SCTP associations:
If the establishment of the UE-associated logical F1-conneciton is initiated by the gNB-DU:
- The gNB-DU sends the UL RRC Message Transfer message on any SCTP association. To guide the gNB-DU decision, the gNB-CU may optionally provide weight factors. The gNB-CU may reply on a different SCTP association. The following signalling is on the SCTP association selected by the gNB-CU.
If the establishment of the UE-associated logical F1-conneciton is initiated by the gNB-CU:
- The gNB-CU sends the UE Context Setup Request message on any SCTP association. The following signalling is on the SCTP association selected by the gNB-CU.
Proposal 3: Agree on the stage-2 TP describing the solution in R3-180420.
| 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 |
NoProposal 1 Include TAC in the F1AP Served Cells Information IE.
Proposal 2 Include TAI and the list of supported slices per TAI in the F1AP Served Cells Information IE.
| available | No | |||
| R3‑180422 | System information delivery | Ericsson | other |
10.10.2System Information
| Yes |
NoProposal 1 Include an RRC container in the “System Information Delivery Command” message to carry MSG4. This enables the gNB-DU to transparently send MSG4 to the UE to acknowledge the SI request.
Proposal 2 The O&M configures a default broadcast time interval for the Other SI in the gNB-DU.
Proposal 3 RAN3 is kindly to agree with the text proposal for the BL CR to TS 38.401 in Annex I.
| available | No | |||
| R3‑180423 | System information exchange over F1 | Ericsson | other |
10.10.2System Information
| Yes |
NoProposal 1 The gNB-CU System Information IE includes the SI message that contains all the other SIBs, as defined in TS 38.331. Note: further details on the definition of SI message is pending progress in RAN2.
Proposal 2 RAN3 is kindly asked to agree with the text proposal in Annex I.
| available | No | |||
| R3‑180424 | Corrections to Inactive to Other State procedures over F1 | Ericsson | other |
10.10.3UE Initial Access, State Transitions
| Yes |
NoConclusion 1: There is no need of an F1: UE Context Setup procedure when the UE moves from Inactive to Active to perform a Registration Area Update or RAN Notification Area Update.
| available | No | |||
| R3‑180425 | UE radio capabilities over F1 | Ericsson | other |
10.10.7UE Context Management
| Yes |
NoProposal 1: Clarify that the UE Radio Capabilities IE includes the UE-CapabilityRAT-ContainerList, as defined in TS 38.331 [2].
| available | No | |||
| R3‑180426 | Cell information over F1 | Ericsson | other |
10.10.7UE Context Management
| Yes |
NoProposal 1: Introduce a choice between: (1) a Cell ID IE, (2) a PCell ID IE, (3) and a PSCell ID IE in the F1AP UE Context Setup Request and the F1AP UE Context Modification Request messages.
Proposal 2: The Target Cell ID IE in the F1AP UE Context Setup Request message is not required.
| available | No | |||
| R3‑180427 | UE context Setup over the F1 | Ericsson | other |
10.10.7UE Context Management
| Yes |
NoConclusion 1: Adopting a solution where a gNB-CU decides the QoS configuration of DRBs to be served by a scheduler in the gNB-DU hinders the deployment of multivendor gNB-CU/gNB-DU systems and may result in DRB establishment failures that delay UP bearer establishment
Conclusion 2: It is proposed that, as part of the DRB information sent by gNB-CU to gNB-DU in the F1: UE CONTEXT SETUP REQUEST, the gNB-CU includes a mapping of DRB to traffic flows and QoS policy information for each traffic flow
Conclusion 3: It is proposed that the gNB-DU derives the best DRB’s RRM and scheduling policy that can fulfil QoS requirements for all the traffic flows mapped to a DRB
Conclusion 4: It is proposed to use the F1: UE CONTEXT SETUP FAILURE when the full UE context cannot be setup at the gNB-DU
| available | No | |||
| R3‑180428 | UE Reject Indication and gNB-DU admission result | Ericsson | other |
10.10.7UE Context Management
| Yes |
NoProposal 1: Introduce a new gNB-DU Admission Result IE in the Initial UE RRC Message Transfer.
Proposal 2: Introduce a new UE Reject Indication IE in the DL RRC Message Transfer.
Proposal 3: A description of how to interpret the results of the gNB-DU and gNB-CU admission should be given in TS38.473
| available | No | |||
| R3‑180429 | Further analysis on inactivity monitoring | Ericsson | other |
10.10.7UE Context Management
| Yes |
NoProposal 1: Introduce an Acitvity Reporting IE in the F1AP UE Context Setup Request message to request the gNB-DU to monitor and report inactivty for this UE.
Proposal 2: Introduce a new Class 2, gNB-DU initiated, and UE-associated F1AP procedure to report UE inactivity from gNB-DU to gNB-CU.
Proposal 3: RAN3 is kindly asked to agree on the text proposal in Annex I.
| available | No | |||
| R3‑180430 | Creation of signalling connection | Ericsson | other |
10.10.7UE Context Management
| Yes |
NoProposal 1: RAN3 is kindly asked to agree with the text proposal in Annex I.
| available | No | |||
| R3‑180431 | RRC Container in UE Context Setup Request | Ericsson | other |
10.10.7UE Context Management
| Yes |
NoProposal 1 RAN3 is kindly to agree with the text proposal in Annex I.
| available | No | |||
| R3‑180432 | RLC Mode indication | Ericsson | other |
10.10.7UE Context Management
| Yes |
NoProposal 1: Include the RLC mode for each DRB in the F1AP UE Context Setup Request and F1AP UE Context Modification Request messages.
Proposal 2: RAN3 is kindly asked to agree with the text proposal in Annex I.
| available | No | |||
| R3‑180433 | Introduction of UE Reconfiguration Complete procedure | Ericsson | discussion | Agreement |
10.10.7UE Context Management
| Yes |
NoProposal 1 An F1-AP UE Reconfiguration Complete message is not required.
| 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 |
NoProposal 1: the LTE-NR spectrum-sharing mechanism should give precedence to the LTE peer, implying that the eNB should have the final word in resource division between the RATs. The LTE cell-level signalling should not be affected by the coexistence, to maintain compatibility with legacy LTE UEs.
Proposal 2: due to the existence of always-on LTE control/reference signals, certain resources inside the part of the grid assigned to NR are still to be used for LTE control/reference signal transmissions. The LTE should indicate these resource allocation exclusions to NR.
Proposal 3: symbol-level granularity is required for LTE to indicate the position of its always-on signals to NR, because some LTE control signals do not use the entire PRB in which they are transmitted, so these unused REs can still be used for NR transmissions.
Proposal 4: PRB granularity in resource allocation indication should be supported, to account for the situations where certain LTE cell-level signals are turned off. This would enable the eNB to indicate to the gNB that an entire PRB, the portion of which is normally assigned to an LTE cell-level signal, is free for use by NR, due to the aforementioned LTE cell-level signal being muted at that particular occasion.
Proposal 5: the signalling to exchange cell level resource configuration between LTE and NR should be considered seldom, due to the semi-static nature of the resource configuration exchanged.
| 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 |
NoProposal 1 The CU-CP should select the UP-security algorithms and inform CU-UP during DRB setup. Which algorithm to use is based on operator configuration.
Proposal 2 The CU-CP should derive all keys from the KgNB and then forward the user plane keys (i.e. Kupenc, Kupint) to the CU-UP during DRB setup and at KgNB re-fresh. The CU-CP should ensure that the same user plane keys are not reused in different UP security domains.
Proposal 3 The agreed solution should be verified with SA3
Proposal 4 The CU-CP should be able to request UL/DL PDCP status report from the CU-UP at any time.
Proposal 5 The CU-CP should be responsible for triggering key refresh when needed.
Proposal 6 No functionality is needed in CU-UP to monitor or report PDCP COUNT wrap around.
Proposal 7 Assuming that the CU-CP should be able to request UL/DL PDCP status report from the CU-UP at any time, the CU-CP can be responsible for triggering Counter Check procedures.
Proposal 8 The CU-CP will be responsible for Counter Check procedures, no specific CU-UP functionality is needed.
Proposal 9 It is proposed to add the text in section 8 capturing the proposals in this contribution to the stage 2 description for CU/UP separation.
Proposal 10 An LS should be sent to SA3 to confirm the agreed solution.
| 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 |
NoProposal 1 the MeNB can use path switch in order to change the GTP TEIDs
| 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 |
NoIt is proposed to further discuss this topic in future meeting and to liaise back to SA2 our findings (see R3-180444).
It is also proposed to discuss the TP for 36.423 and 37.340 provided in R3-180442 and R3-1704.
| 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 |
NoProposal 1: Remove the restriction about running parallel Configuration Update procedures over the F1 interface.
Proposal 2: Introduce the Transaction ID in the Configuration Update messages, to avoid the risk of mis-configurations when running parallel procedures.
Proposal 3: Employ the same ASN.1 encoding for the Transaction ID as in TS 38.455 [1] and TS 25.423 [2] and agree on the text proposal in R3-180445.
| 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 |
NoProposal 1: It is proposed not to include the List of NR Carriers IE in the X2: EN-DC X2 Setup and EN-DC Configuration Update procedures.
Proposal 2: It is proposed not to include the Cell Assistance Information IE in the X2: EN-DC X2 Setup and EN-DC Configuration Update procedures.
Proposal 3: It is proposed not to include the SMTC Configuration TDD IE, Bandwidth Part Information IE, Subframe Assignment IE, Special Subframe Info IE in the Served NR Cell Information IE
| 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- Spec name alignment on “NG-RAN”
- Adding reference
- Change of abbreviations on NG-RAN
| 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 |
NoProposal 1: For UL PDCP duplication, there should be a mechanism to prevent unnecessary transfer of already successfully received uplink PDCP PDUs at the node hosting PDCP entity from the corresponding node, which may devour/dominate the interface resources considering high data rate in NR.
Proposal 2: The node hosting PDCP entity to notify a UL PDCP SN within the existing DL User Data frame so that the unnecessary transfer of uplink PDCP PDUs can be avoided from the corresponding node.
| 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 |
NoProposal 1: RAN3 to define an indication in the DDDS frame that can inform the node hosting PDCP entity that the DRX-configured UE has entered into an OFF period in the corresponding node.
| 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 |
NoProposal 1: NG-AP Paging message shall carry at least: UE Identity Index Value, UE Paging Identity, Paging DRX, Paging Priority, and TAI List.
Proposal 2: NG-AP Paging message shall also carry: UE Radio Capability and Recommended Cells, encoded similarly to S1-AP.
Proposal 3: to discuss RAN3 preference access associated to the PDU session” and PDU Session ID encoding in NG-AP and liaise RAN2, CT1 and SA2 on this matter.
| available | No | ||
| R3‑180460 | F1-AP Paging Procedure and Signaling | Intel Corporation | draftCR | Agreement |
10.10.5Paging
| Yes |
NoProposal 1: the same F1-AP procedure is used for both CN and RAN paging.
Proposal 2: to add FFS on “NAS level” information encoding and UE identity.
| 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 |
NoProposal 1: in order to minimize standardization and implementation efforts it is proposed to align the multiple TNL address functionality on the F1 interface with the NG interface.
Proposal 2: to agree on the following principles:
1. Support for multiple SCTP associations on NG-C and F1-C is aligned to the extent possible, including IE naming
2. Only functionality available on the NG-C is considered for F1-C
3. NG-C functionality is taken as a baseline; removal of certain functions should be justified
| 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 |
NoProposal 1: We propose that RAN3 discuss a reset solution and select one or both of the following methods:
a) reset can indicate an S-NSSAI list and all PDU sessions related to the indicated S-NSSAIs are reset.
b) reset can indicate a list of UE contexts and which PDU sessions for each UE context that should be reset.
| available | No | |||
| R3‑180478 | NG overload control | Huawei | pCR |
10.5.6Others
| Yes |
NoProposal 1: Confirm the transfer of relative AMF Capacity IE in NG setup response.
Proposal 2: Add the transfer of relative AMF Capacity IE in AMF CONFIGURATION UPDATE message.
Proposal 3: Add the overload start and overload stop message in TS 38.413.
Proposal 4: Add the S-NSSAI information into the overload start message in TS 38.413.
Proposal 5: Add the traffic load reduction indication for the S-NSSAI(s) into the overload start message in TS 38.413.
| available | No | |||
| 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 |
NoProposal 1: Correct the criticality as discussed above for SCell To Be Setup List IE, Resource Coordination Transfer Container IE and RRC-Container IE
| 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 |
NoProposal 1: Proposal: remove procedural text preventing parallel configuration update messages
Proposal 2: Add transaction ID to configuration update messages
Proposal 3: Introduce text in section 10 similar to LPPA mentioning transaction ID and include the transaction ID in the Criticality Diagnostics IE.
Proposal 4: Refer to S1AP instead of NGAP in section 10
| 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.1Common 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 |
NoProposal 1 It is proposed to restructure DC message to enable configuration of mulitple DC bearers in a single message
Proposal 2 It is proposed to re-structure Addition/Modification message along SDAP location (MN or SN)
Stage 3 aspects for XnAP are covered in the Annex of this paper, covering the Addition aspects only. It is proposed to agree on the TP provided.
| available | No | |||
| 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 |
NoProposal 1: Support indication of NR resources to support coexistence on co-channel spectrum:
• RB-level granularity for frequency allocation
• Symbol-level granularity for time allocation
• NR Rate Matching Resource Sets as defined by NR RRC IEs
Proposal 2: Support explicit signaling of SFN values should be supported to be exchanged between eNB and gNB.
Proposal 3: LTE MBSFN Subframe configuration should be exchanged to support DL sharing based on MBSFN subframes.
Proposal 4: Support indication of LTE DRS, CSI-RS, SRS, and PUCCH configurations based on LTE RRC Ies.
| available | No | ||
| R3‑180500 | Handling of remaining stage 3 FFSs for NSA ANR | Nokia, Nokia Shanghai Bell | other |
31.3.1Essential Corrections
| Yes |
NoProposal 1: Not include List of NR Carriers, but mandate that the en-gNB provides at least one NR cell per served carrier frequency.
Proposal 2: Encode NR ARFCN as INTEGER(0..3266667), pending confirmation from RAN4 and RAN2.
Proposal 3: Not include the Subframe Assignment IE in the Served NR Cell Information IE.
Proposal 4: Not include the Special Subframe Info IE in the Served NR Cell Information IE.
Proposal 5: Include the ‘Partial List’ choice tag in Cell Assistance Information.
| 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 |
NoProposal 1: Not introduce NG Context Fetch and NG Paging Relay in release 15.
However, to address the questions of some operators, it is proposed to for release 16:
Proposal 2: Discuss how to conduct the study of use case 2 (i.e. the case of UEs which have relaxed CP latency requirement and have a low Tx/speed ratio in order to reduce their radio signalling compared to idle mode) in release 16 i.e. as part of a separate WID/TEI16?
Proposal 3: at least include in the above release 16 study and compare the 4 candidate solutions mentioned in this paper for addressing the use case 2.
| available | No | ||
| R3‑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 |
NoProposal 1: Introduce a Notification Control IE for each DRB to setup/modify in the F1AP UE Context Setup Request and in the F1AP UE Context Modification Request messages.
Proposal 2: Introduce a F1AP “Notify” procedure to report that the QoS for a bearer associated with Notification Control can no longer (or again) be fulfilled. The F1AP “Notify” procedure should be: Class 2, gNB-DU initiated and UE-associated.
| 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 |
NoProposal 1: RAN3 is kindly asked to endorse the proposed time plan.
| 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 |
NoProposal 1: Define RAN Notification Area as List of Cells and List of RAN areas in Rel-15.
Proposal 2: Agree that Xn should be available in RAN notification area in Rel-15.
Proposal 3: Further discussion on if and how to support TAI List as RAN Notification Area in Rel-16.
Proposal 4: When the UE moves out of RNA and there is no Xn between the new gNB and the last serving gNB, fall back solution will be used by the new gNB to perform establishment of a new RRC connection.
Proposal 5: Further discuss whether any optimization of the scenario where the UE moves out of the RNA is needed.
| available | No | ||
| R3‑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 |
NoProposal 1: For the state transition from the RRC_INACTIVE to the RRC-INACTIVE or RRC_IDLE state, the F1 UE Context Release procedure should be performed.
Proposal 2: It is proposed to agree the text proposals in the appendix of this contribution.
| available | No |