Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 37.340  Word version:  18.2.0

Top   Top   Up   Prev   Next
1…   4…   4.2…   4.3…   5…   7…   8…   9   10…   10.2…   10.2.2…   10.3…   10.3.2   10.4…   10.5…   10.5.2   10.6   10.7…   10.8…   10.9…   10.10…   10.11…   10.12…   10.12.2   10.13…   10.14…   10.15   10.16…   10.17…   10.18…   10.19…   10.20   11…   A   B…

 

11  Service related aspectsp. 128

11.1  Roaming and Access Restrictionsp. 128

The principles for conveying roaming and access restriction info for EN-DC are described in TS 36.300.
For MR-DC with 5GC, SCG (re)selection at the SN is based on roaming and access restriction information in SN. If roaming and access restriction information is not available at the SN, the SN shall consider that there is no restriction for SCG (re)selection. Therefore, the MN needs to convey the latest roaming and access restriction information as received from the Core Network or another NG-RAN node to the SN via XnAP messages.
Up

11.2  Support of Network Sharingp. 128

E-UTRAN and NG-RAN aspects of network sharing are specified in TS 36.300 and TS 38.300.

11.3  ARPI/SPID Handling from MN |R16|p. 128

Usage of the Subscriber Profile ID for RAT/Frequency Priority (SPID) and the Additional RRM Policy Index (ARPI) in E-UTRAN is specified in TS 36.300 and applies to EN-DC. Therefore, the MN needs to convey the up-to-date ARPI/SPID information to the SN via X2AP messages.

12  X2/Xn Interface related aspectsp. 128

Stage 2 specification for X2-C procedures for EN-DC is contained in TS 36.300.
Xn-C procedures for MR-DC with 5GC are specified in TS 38.423.
X2-U procedures for EN-DC and Xn-U procedures for MR-DC with 5GC are specified in TS 38.425.

13  Other aspectsp. 128

13.1  Interference avoidance for in-device coexistencep. 128

IDC solution as described in TS 36.300 and TS 38.300 is extended to address EN-DC/NR-DC operation. For the FDM solution, the list of NR carriers or NR frequency ranges suffering from IDC problems is signalled in IDC report. For the TDM solution, a periodic pattern can be signalled per-CG in IDC report. In EN-DC, the MN can configure the UE to report FDM assistance information with affected carriers. In NR-DC, the MN can configure the UE to report FDM assistance information with affected carriers/frequency ranges and/or TDM assistance information. For both EN-DC and NR-DC, the SN can configure the UE to report FDM assistance information with affected carriers/frequency ranges and/or TDM assistance information to the SN via SRB1 or SRB3, if SRB3 is configured and the SCG is activated. The network can also configure autonomous denial per-CG for the UE to solve IDC problems. The requirement on RRM/RLM/CSI measurements in different phases of IDC interference defined in TS 36.300 is applicable except that for NR serving cell, the requirements in TS 38.133 and TS 38.101-1, TS 38.101-2, TS 38.101-3 apply.
Up

13.2  Sidelink |R16|p. 128

NR Sidelink Communication, V2X Sidelink Communication, NR Sidelink Discovery and Ranging/Sidelink Positioning cannot be configured in MR-DC in this release.

13.3  SCG UE history information |R17|p. 129

The MN stores and correlates the UE History Information from MN and SN(s) as long as the UE stays in MR-DC, forwards UE History Information and optional UE History Information from the UE to its connected SNs. The resulting information is then used by SN for dual-connectivity operation. The SN is in charge of collecting SCG UE history information and providing the collected information to the MN.
If the UE stays in a PSCell for a duration exceeding the maximum value of the Time Stay parameter, the SN may store the PSCell information with consecutive entries using the same PSCell identity. The total stay time in this PSCell is the sum of stay time for all consecutive PSCell with the same identity.
The SN shall provide the collected SCG UE history information, if available, to the MN in the following procedures:
  • the SN Release, and SN initiated SN Change procedures
  • the MN initiated SN Modification procedure if requested by the MN in this procedure
  • the SN initiated SN modification procedure upon PSCell change if subscribed in the SN Addition procedure
When the target NG-RAN node receives the SCG UHI from the source NG-RAN node via Handover Request message for CHO, the target NG-RAN node updates the time UE stayed in cell of the latest PSCell entry (i.e. the source PSCell) when the UE successfully accesses to a candidate cell of the target NG-RAN node. The updated value of the time UE stayed in the source PSCell is equal to the value received from the source NG-RAN node during the Handover Preparation plus the time from receiving Handover Request message from the source NG-RAN node to receiving RRC Reconfiguration Complete message from the UE.
When the target SN receives the SCG UHI from the MN via SN Addition Request message for CPC, the target SN updates the time UE stayed in the cell of the latest PSCell entry (i.e. the source PSCell) when the UE successfully accesses to a candidate cell of the target SN. The updated value of the time UE stayed in the latest PSCell is equal to the value received from the MN via the SN Addition Request message plus the time from receiving SN Addition Request message from the MN to receiving SN Reconfiguration Complete from the MN.
Up

13.4  Application Layer Measurement Collection |R18|p. 129

13.4.1  Overviewp. 129

The QoE Measurement Collection function as described in TS 38.300 is extended to address the NR-DC operation.
For a UE in (NG)EN-DC and NE-DC, only the MN can configure the QoE configuration.

13.4.2  SRB5p. 129

SRB5 is supported in NR-DC, but not in EN-DC, NGEN-DC and NE-DC.
The decision to establish SRB5 is taken by the SN, which provides the SRB5 configuration using an SN RRC message. SRB5 establishment and release can be done at Secondary Node Addition and Secondary Node Change. SRB5 reconfiguration can be done at Secondary Node Modification procedure.
SRB5 is used to send RRC messages (i.e., MeasurementReportAppLayer message) including application layer measurement report information directly to the SN.
SRB5 is modelled as one of the SRBs defined in TS 38.331 and uses the NR-DCCH logical channel type.
When the SCG is released, SRB5 is released.
Up

13.4.3  QoE Measurement Configurationp. 129

13.4.3.1  QoE Measurement Collection Activation and Reporting in NR-DCp. 129

For a UE in NR-DC, either the MN or the SN can generate QoE configuration(s) and transmit the configuration to the UE. If both the MN and the SN send QoE configurations to the UE, the MN and the SN do not use the same set of application layer measurement configuration identities, which means there is a unique ID for QoE configurations across MN and SN.
For a UE in NR-DC, the MN and the SN may coordinate QoE measurement collection activation and reporting as follows:
For management-based QoE activation, the MN:
  • Allocates the application layer measurement configuration ID for QoE measurement configurations to be configured at UEs served by the MN and the SN, and indicates it to the SN if needed;
  • Determines whether the MN or the SN sends the QoE configuration to the UE, in case the SN inquires the MN.
  • Can inform the SN that a UE is configured with a management-based QoE.
For management-based QoE measurement configurations received directly by the SN from OAM, the SN may perform UE selection. For a selected UE, the SN indicates to the MN the QoE reference of the management-based QoE configuration and, separately for the QoE reports and RAN visible QoE reports, the SN indicates whether it is going to receive the corresponding reports directly using SRB5 or via the MN (using SRB4). Upon receiving the coordination request, the MN can decide and notify the SN whether the MN sends the QoE and RAN Visible QoE configuration to the UE, or whether the SN should send the configuration(s) to the UE. The SN can send a QoE and/or a RAN Visible QoE measurement configuration directly to the UE via SRB3, or in a transparent container to the MN, which then sends the configuration to the UE via SRB1.
For management-based QoE configurations received directly by the MN from the OAM and for signalling-based QoE configurations, the MN can only send the configuration to the UE via SRB1, and the UE can send the QoE reports via SRB4 or SRB5. The MN should inform the SN that the UE is configured with the management-based QoE/RAN visible QoE measurement configuration. When the MN has released the management-based QoE/RAN visible QoE measurement configuration, the MN should inform the SN.
For a UE in NR-DC, both SRB4 and SRB5 can be configured simultaneously for QoE reporting. The network explicitly and separately indicates to the UE whether to send encapsulated QoE reports and RAN visible QoE reports via SRB4 or SRB5, per QoE reference. The SRB for QoE reporting can be changed during the QoE measurement session. The command for changing the SRB used for reporting may be sent to the UE by the node that configured that specific QoE configuration. The node that currently receives the QoE reports via the Uu interface can request from the peer node that the QoE reporting path is changed to the peer node per QoE reference. The change of QoE reporting path needs to be approved by both nodes serving the UE.
If encapsulated QoE reports (sent in measReportAppLayerContainer) cannot be sent because the SRB configured for the such reporting is not available, the UE continues to store the reports until the SRB is available or until the QoE configuration is released.
If the MN has configured the UE with QoE measurements, and if the UE is configured to send the QoE reports to the SN, then, if the MN decides that the SN forwards the reports directly to the MCE, the MN should indicate to the SN the QoE reference, the MCE IP address and the application layer measurement configuration ID.
If the SN has configured the UE with QoE measurements, and if the UE is configured to send the QoE reports to the MN, then, if the SN decides that the MN forwards the reports directly to the MCE, the SN should indicate to the MN the QoE reference and the MCE IP address.
QoE reports can be transferred between the MN and the SN via the RRC TRANSFER message.
If the SN has released a QoE configuration of a UE, the SN should inform the MN.
When SCG is deactivated, for QoE configurations configured to use SRB5 for QoE reporting, it is up to network implementation whether to reconfigure the reporting leg to SRB4, release the QoE configuration or pause the QoE reporting. For UL data arrival on SRB5 while the SCG is deactivated, the UE does not indicate to the MN that it has QoE report to transmit over SRB5 for the purpose of SCG activation.
When the SCG is released, the UE releases all the QoE measurements configured by the SCG and discards the unsent QoE reports configured to be reported via SRB5.
In order to allow the transmission of application layer measurement reports which exceed the maximum PDCP SDU size, the network can inform the UE whether the MN allows RRC segmentation of MeasurementReportAppLayer message via SRB4 and whether the SN allows RRC segmentation of MeasurementReportAppLayer message via SRB5.
Up

13.4.3.2  RAN Overload Handlingp. 131

In NR-DC, when RAN overload happens in the node which receives the QoE reports from the UE, the node may either determine to pause the QoE reporting from the UE as specified in TS 38.300 or the node may coordinate with its peer node to reconfigure the QoE reporting path and offload one or more of the QoE sessions, by sending the QoE Reporting Path Request in the QMC Coordination Request IE, via the MN-initiated and SN-initiated SN modification procedure. The peer node may approve the reconfiguration of the QoE reporting leg of the one or more QoE sessions, by sending the QoE Reporting Path Response in the QMC Coordination Response IE in the response message for SN modification.
When the peer node is not able to accept the Reporting Path Request of one or more QoE sessions, the node that is overloaded in NR-DC may pause the QoE reporting from the UE for those QoE sessions as specified in TS 38.300.
When neither the MN nor the SN is able to receive the QoE reports due to RAN overload, the network can indicate to the UE to pause QoE reporting, as specified in TS 38.300.
Up

13.4.3.3  Support for RAN visible QoE measurements and reporting in NR-DCp. 131

Either the MN or the SN can generate and send a RAN visible QoE configuration to the UE. The gNB that has initially configured a UE in NR-DC with a RAN visible QoE configuration can modify and release the RAN visible QoE configuration as long as the UE is connected to this gNB. The gNB that configures the encapsulated QoE measurements to UE is referred to as the RAN visible QoE-configuring gNB, and the peer node is referred to as the non-RAN visible QoE-configuring gNB. Upon mobility, the RAN visible QoE-configuring gNB may be changed.
The UE may send RAN visible QoE reports to the network using either SRB4 or SRB5. In addition, the gNB that received a RAN visible QoE report can forward the report to the other gNB (the SN or the MN). QoE reports and RAN visible QoE reports pertaining to the same QoE Reference can be sent over the same SRB or they can be sent over different SRBs. If RAN visible QoE reports cannot be sent because the SRB configured for RAN visible QoE measurement reporting is not available, the UE discards the RAN visible QoE report.
The RAN visible QoE-configuring gNB can configure RAN visible QoE measurements at a UE without a priori knowledge about which gNB(s) will provide the bearer(s) for a future application session. During the lifetime of an application session, to ensure that the RAN visible QoE reports are sent to the gNB(s) that provide the bearer(s) which carry the data flow(s) associated with the RAN visible QoE measurement result in a RAN visible QoE report, the gNB receiving the RAN visible QoE reports determines the bearer(s) used to deliver the application session data flow(s) and the associated gNB (s). The determination may be based on the PDU session ID(s) and the QoS flow ID(s) indicated in a received RAN visible QoE report.
When the RAN visible QoE-configuring gNB receives a RAN visible QoE measurement report and determines that the non-RAN Visible QoE-configuring gNB provides at least one bearer for the application session, the RAN Visible QoE-configuring gNB indicates that to the non-RAN Visible QoE-configuring gNB. The non-RAN Visible QoE-configuring gNB can then, if needed, indicate to the RAN visible QoE-configuring gNB its preference with respect to the reporting path for the subsequent RAN visible QoE reports and its preferred RAN visible QoE configuration parameters.
If a gNB receives a RAN visible QoE report from a UE in NR-DC, and determines that the bearer(s) for the application session data flow(s) is (are) also provided by the other gNB, or only, provided by the other gNB, the gNB that received the RAN visible QoE measurement report may forward the received RAN visible QoE report to the other gNB. The RAN visible QoE reports can be transferred between the MN and the SN via the RRC TRANSFER message. The RAN visible QoE configuration may also be modified or released.
Up

13.4.4  QoE Measurement Continuity for Mobilityp. 131

For ongoing sessions, QoE measurement continuity is ensured during mobility in NR-DC, e.g., during inter-MN handover (with/without SN change) and SN change scenarios.
To ensure QoE measurement continuity during SN change, the SN-initiated SN modification procedure and/or the MN-initiated SN modification procedure can be used to provide the information about the SN-associated QMC configurations to the MN. The MN can then transfer this information to the new SN during the SN Addition procedure.
To ensure QoE measurement continuity during inter-MN handover with SN change, the source SN should provide the information about the SN-associated QMC configurations to the source MN. During the handover procedure, the target MN is provided with all the information that the source MN has about the SN-associated QMC configuration.
If the MN configured the UE with QoE measurements, every subsequent MN serving the UE can configure and release the RAN visible QoE measurements.
Up

Up   Top   ToC