Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 38.300  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   4…   4.7…   5…   5.3…   5.4…   6…   6.2…   6.6…   7…   8…   9…   9.2.2…   9.2.2.5…   9.2.3…   9.2.3.2…   9.2.3.3…   9.2.4…   9.2.6…   9.3…   10…   11…   15…   15.5…   16…   16.2…   16.3…   16.4…   16.8…   16.9…   16.10…   16.12…   16.12.5…   16.12.6…   16.12.6.3   16.12.7   16.13…   16.14…   16.15…   16.18…   16.19…   16.21…   16.21.3…   17…   18…   19   20…   21…   A…   B…   C…   G…

 

9.3  Inter RATp. 114

9.3.1  NR-E-UTRA mobility: Intra 5GCp. 114

9.3.1.1  Cell Reselectionp. 114

Cell reselection is characterised by the following:
  • Cell reselection between NR RRC_IDLE and E-UTRA RRC_IDLE is supported;
  • Cell reselection from NR RRC_INACTIVE to E-UTRA RRC_IDLE is supported.

9.3.1.2  Handoverp. 114

Inter RAT mobility is characterised by the following:
  • The Source RAT configures Target RAT measurement and reporting.
  • The source RAT decides on the preparation initiation and provides the necessary information to the target RAT in the format required by the target RAT:
    • For handover preparation from E-UTRA to NR, the source RAT issues a handover preparation request message to the target RAT passing a transparent RRC container with necessary information to prepare the handover at the target side. The information for the target RAT is the same type as specified in clause 9.2.3.2.1 including the current QoS flow to DRB mapping applied to the UE and RRM configuration.
    • The details of RRM configuration are the same type as specified for NR in clause 9.2.3.2.1 including beam measurement information for the listed cells if the measurements are available.
  • Radio resources are prepared in the target RAT before the handover.
  • The RRC reconfiguration message from the target RAT is delivered to the source RAT via a transparent container, and is passed to the UE by the source RAT in the handover command:
    • The inter-RAT handover command message carries the same type of information required to access the target cell as specified for NR baseline handover in clause 9.2.3.2.1.
  • The in-sequence and lossless handover is supported for the handover between gNB and ng-eNB.
  • Both Xn and NG based inter-RAT handover between NG-RAN nodes is supported. Whether the handover is over Xn or CN is transparent to the UE.
  • In order to keep the SDAP and PDCP configurations for in-sequence and lossless inter-RAT handover, delta-configuration for the radio bearer configuration is used.
Up

9.3.1.3  Measurementsp. 115

Inter RAT measurements in NR for this use case are limited to E-UTRA.
Whether a measurement is non-gap-assisted or gap-assisted depends on the capability of the UE and the current operating frequency:
  • For E-UTRA Inter RAT measurement, if the measurement gap requirement information is reported by the UE, a measurement gap configuration may be provided according to the information. Otherwise, a measurement gap configuration is always provided when:
    • The UE only supports per-UE measurement gaps; or
    • The UE supports per-FR measurement gaps and at least one of the NR serving cells is in FR1.
Up

9.3.2  NR-E-UTRA mobility: From 5GC to EPCp. 115

9.3.2.1  Cell Reselectionp. 115

Cell reselection is characterised by the following:
  • Cell reselection between NR RRC_IDLE and E-UTRA RRC_IDLE is supported;
  • Cell reselection from NR RRC_INACTIVE to E-UTRA RRC_IDLE is supported.

9.3.2.2  Handover and redirectionp. 115

The source NG-RAN node decides between handover or redirection to EPS based on radio criteria and availability of the N26 interface.
Inter RAT handover is characterised by the following:
  • The Source RAT configures Target RAT measurement and reporting.
  • The source RAT decides on the preparation initiation and provides the necessary information to the target RAT in the format required by the target RAT.
  • Radio resources are prepared in the target RAT before the handover.
  • The RRC reconfiguration message from the target RAT is delivered to the source RAT via a transparent container, and is passed to the UE by the source RAT in the handover command.
  • In-sequence and lossless handovers are not supported.
  • Security procedures for handover to E-UTRA/EPC should follow E-UTRA handover procedures.
Up

9.3.2.3  Measurementsp. 115

Inter RAT measurements in NR for this use case are limited to E-UTRA.
Whether a measurement is non-gap-assisted or gap-assisted depends on the capability of the UE and the current operating frequency:
  • For E-UTRA Inter RAT measurement, if the measurement gap requirement information is reported by the UE, a measurement gap configuration may be provided according to the information. Otherwise, a measurement gap configuration is always provided when:
    • The UE only supports per-UE measurement gaps; or
    • The UE supports per-FR measurement gaps and at least one of the NR serving cells is in FR1.
Up

9.3.2.4  Data Forwarding for the Control Planep. 116

Control plane handling for inter-System data forwarding from 5GS to EPS follows the following key principles:
  • Only forwarding of downlink data is supported.
  • PDU session information at the serving NG-RAN node contains mapping information per QoS Flow to a corresponding E-RAB.
  • At handover preparation, the source NG-RAN node shall decide which mapped E-RABs are proposed to be subject to data forwarding and provide this information in the source-to-target container to the target eNB. Based on availability of direct data forwarding path the source NG-RAN node may request to apply direct data forwarding by indicating direct data forwarding path availability to the 5GC.
  • The target eNB assigns forwarding TEID/TNL address(es) for the E-RAB(s) for which it accepts data forwarding.
  • In case of indirect data forwarding, a single data forwarding tunnel is established between the source NG-RAN node and UPF per PDU session for which at least data for a single QoS Flow is subject to data forwarding.
  • In case of direct data forwarding, the source NG-RAN node receives a TEID/TNL address for each E-RAB accepted for data forwarding as assigned by the target eNB.
Up

9.3.2.5  Data Forwarding for the User Planep. 116

In case of indirect data forwarding, user plane handling for inter-System data forwarding from 5GS to EPS follows the following key principles:
  • For the QoS flows accepted for data forwarding, the NG-RAN node initiates data forwarding to the UPF by the corresponding PDU session data forwarding tunnel(s).
  • The UPF maps forwarded data received from the per PDU session data forwarding tunnel(s) to the mapped EPS bearer(s) removing the QFI.
  • Handling of end marker packets:
    • The source NG-RAN node receives one or several end marker packets per PDU session from the UPF. When there are no more data packets to be forwarded for QoS flows mapped to an E-RAB, the source NG-RAN node sends one or several end markers including one QFI (by means of the PDU Session User Plane protocol TS 38.415) of those QoS flows mapped to that E-RAB and sends the end marker packets to the UPF over the PDU session tunnel. From the included QFI in the end markers and its mapping to an EPS bearer ID, the UPF knows which EPS bearer tunnel it needs to forward the end-markers to the SGW. The QFI is removed in the end marker packets sent to the SGW.
In case of direct data forwarding, user plane handling for inter-System data forwarding from 5GS to EPS follows the following key principles:
  • For the QoS flows accepted for data forwarding, the source NG-RAN node maps data received from the NG-U PDU session tunnel to the respective E-RAB data forwarding tunnel and forwards each user packet as PDCP SDU without PDCP SN and QFI information.
  • The source NG-RAN node receives one or several GTP-U end marker packets per PDU session from the UPF and replicates the end marker packets into each E-RAB data forwarding tunnel when no more user data packets are to be forwarded over that tunnel.
Up

9.3.3  NR-E-UTRA mobility: From EPC to 5GCp. 117

9.3.3.1  Data Forwarding for the Control Planep. 117

Control plane handling for inter-System data forwarding from EPS to 5GS follows the following key principles:
  • Only forwarding of downlink data is supported.
  • The target NG-RAN node receives in the Handover Request message the mapping between E-RAB ID(s) and QoS Flow ID(s). It decides whether to accept the data forwarding for E-RAB IDs proposed for forwarding within the Source NG-RAN Node to Target NG-RAN Node Transparent Container. Based on availability of direct data forwarding path the source eNB may request to apply direct data forwarding by indicating direct data forwarding availability to the CN.
  • In case of indirect data forwarding:
    • The target NG-RAN node assigns a TEID/TNL address for each PDU session for which at least one QoS flow is involved in the accepted data forwarding.
    • The target NG-RAN node sends the Handover Request Acknowledge message in which it indicates the list of PDU sessions and QoS flows for which it has accepted the data forwarding.
    • A single data forwarding tunnel is established between the UPF and the target NG-RAN node per PDU session for which at least data for a single QoS Flow is subject to data forwarding.
    • The source eNB receives in the Handover Command message the list of E-RAB IDs for which the target NG-RAN node has accepted data forwarding of corresponding PDU sessions and QoS flows.
  • In case of direct data forwarding:
    • The source eNB indicates direct path availability to the CN. The source eNB's decision is indicated by the CN to the target NG-RAN node.
    • The target NG-RAN node assigns a TEID/TNL address for each E-RAB it accepted for data forwarding.
    • The source eNB receives in the Handover Command message the list of E-RAB IDs for which the target NG-RAN node has accepted data forwarding.
Up

9.3.3.2  Data Forwarding for the User Planep. 117

In case of indirect data forwarding, user plane handling for inter-System data forwarding from EPS to 5GS follows the following key principles:
  • For each E-RAB accepted for data forwarding, the source eNB forwards data to the SGW in the corresponding E-RAB tunnel and the SGW forwards the received data to the UPF in the E-RAB tunnel.
  • The UPF maps the forwarded data received from an E-RAB tunnel to the corresponding mapped PDU session tunnel, adding a QFI value (by means of the PDU Session User Plane protocol TS 38.415).
  • The target NG-RAN node maps a forwarded packet to the corresponding DRB based on the received QFI value. It prioritizes the forwarded packets over the fresh packets for those QoS flows.
  • Handling of end marker packets:
    • The UPF/PGW-U sends one or several end marker packets to the SGW per EPS bearer. The SGW forwards the received end markers per EPS bearer to the source eNB. When there are no more data packets to be forwarded for an E-RAB, the source eNB forwards the received end markers in the EPS bearer tunnel to the SGW and the SGW forwards them to the UPF. The UPF adds one QFI (by means of the PDU Session User Plane protocol TS 38.415) among the QoS flows mapped to that E-RAB to the end markers and sends those end markers to the target NG-RAN node in the per PDU session tunnel. When the target NG-RAN node receives an end marker with a QFI added, the target NG-RAN node starts to transmit the data packets of all QoS flows mapped to the corresponding E-RAB received from the core network towards the UE.
In case of direct data forwarding, user plane handling for inter-System data forwarding from EPS to 5GS follows the following key principles:
  • For each E-RAB accepted for data forwarding, the source node forwards data to the target NG-RAN node in the corresponding E-RAB data forwarding tunnel.
  • Until a GTP-U end marker packet is received, the target NG-RAN node prioritizes the forwarded packets over the fresh packets for those QoS flows which are involved in the accepted data forwarding.
Up

9.3.4  NR-UTRA mobility |R16|p. 118

9.3.4.1  Handover with SRVCC operationp. 118

The source NR node decides to handover the UE with ongoing IMS voice from NR to UTRAN according the following principles:
  • The source NR node determines that the UE supports UTRA and requests the UE to send its UTRA radio access capabilities to the NG-RAN;
  • The source NR node configures target RAT measurement and reporting;
  • The source NR node determines based on the radio conditions and the indication that SRVCC operation is possible that handover to UTRAN should be initiated;
  • The source NR node initiates the handover preparation only for the ongoing IMS voice and provides the indication to AMF that the handover is towards UTRAN together with the target UTRAN Node ID. The source NR node also provides an indication to the target UTRAN that the incoming handover originates from 5G. The SRVCC proceeds as specified in TS 23.216;
  • The source NR node ensures that the size of the source-to-target container does not exceed the limits that can be handled by the interfaces involved in the handover;
  • Radio resources are prepared in the target RAT before the handover;
  • The RRC reconfiguration message from the target RAT is delivered to the source NR node via a transparent container and is passed to the UE by the source NR node in the handover command;
  • In-sequence and lossless handovers are not supported;
  • Only voice bearer is handed over to target RAT;
  • Security procedures for handover to UTRA follows the procedures as specified in TS 33.501;
  • Only handover to UTRA-FDD is supported.
Up

9.3.4.2  Measurementsp. 118

Inter RAT measurements are performed for UTRA.
For a UE configured with UTRA Inter RAT measurements, a measurement gap configuration is always provided when:
  • The UE only supports per-UE measurement gaps; or
  • The UE supports per-FR measurement gaps and at least one of the NR serving cells is in FR1.

9.4  Roaming and Access Restrictionsp. 119

The roaming and access restriction information for a UE includes information on restrictions to be applied for subsequent mobility action during CM-CONNECTED state. It may be provided by the AMF and also may be updated by the AMF later.
It includes the forbidden RAT, the forbidden area and the service area restrictions as specified in TS 23.501. It also includes serving PLMN/SNPN and may include a list of equivalent PLMNs or a list of equivalent SNPNs. It may also include PNI-NPN mobility restrictions (i.e. list of CAGs allowed for the UE and whether the UE can also access non-CAG cells). The gNB shall consider that roaming or access to CAG cells is only allowed if PNI-NPN mobility information is available for the UE.
Upon receiving the roaming and access restriction information for a UE, if applicable, the gNB should use it to determine whether to apply restriction handling for subsequent mobility action, e.g., handover, redirection.
If the roaming and access restriction information is not available for a UE at the gNB, the gNB shall consider that there is no restriction for subsequent mobility actions except for the PNI-NPN mobility as described in TS 23.501.
Only if received over NG or Xn signalling, the roaming and access restriction information shall be propagated over Xn by the source gNB during Xn handover. If the Xn handover results in a change of serving PLMN (to an equivalent PLMN), the source gNB shall replace the serving PLMN with the identity of the target PLMN and move the serving PLMN to the equivalent PLMN list, before propagating the roaming and access restriction information. If the Xn handover results in a change of serving SNPN (to an equivalent SNPN), the source gNB shall replace the serving SNPN with the identity of the target SNPN and move the serving SNPN to the equivalent SNPN list, before propagating the roaming and access restriction information.
If NG-RAN nodes with different versions of the XnAP or NGAP protocol are deployed, information provided by the 5GC within the NGAP Mobility Restriction List may be lost in the course of Xn mobility. In order to avoid such loss of information at Xn handover or UE context retrieval due to a source NG-RAN node or an old NG-RAN node not able to recognise the entire content, the source NG-RAN node or the old NG-RAN node may provide an 5GC Mobility Restriction List Container to the target NG-RAN node or the new NG-RAN node, containing the Mobility Restriction List as received from the 5GC. The target NG-RAN node or the new NG-RAN node shall use the information contained in the 5GC Mobility Restriction List Container as the Mobility Restriction List, except for the Serving PLMN/SNPN and the Equivalent PLMNs/SNPNs, which the NG-RAN node shall use from the XnAP Mobility Restriction List. The 5GC Mobility Restriction List Container may be propagated at future Xn handover and UE context retrieval.
Up

Up   Top   ToC