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