5.17 Interworking and Migration

23.5013GPPRelease 18System architecture for the 5G System (5GS)TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.17.1 Support for Migration from EPC to 5GC

5.17.1.1 General

Clause 5.17.1 describes the UE and network behaviour for the migration from EPC to 5GC.

Deployments based on different 3GPP architecture options (i.e. EPC based or 5GC based) and UEs with different capabilities (EPC NAS and 5GC NAS) may coexist at the same time within one PLMN.

It is assumed that a UE that is capable of supporting 5GC NAS procedures may also be capable of supporting EPC NAS (i.e. the NAS procedures defined in TS 24.301 [13]) to operate in legacy networks e.g. in the case of roaming.

The UE will use EPC NAS or 5GC NAS procedures depending on the core network by which it is served.

In order to support smooth migration, it is assumed that the EPC and the 5GC have access to a common subscriber database, that is HSS in the case of EPC and the UDM in the case of 5GC, acting as the master data base for a given user as defined in TS 23.002 [21]. The PCF has access to the UDR that acts as a common subscriber database for a given user identified by a SUPI using the Nudr services defined in TS 23.502 [3].

Figure 5.17.1.1-1: Architecture for migration scenario for EPC and 5G CN

A UE that supports only EPC based Dual Connectivity with secondary RAT NR:

– always performs initial access through E-UTRA (LTE-Uu) but never through NR;

– performs EPC NAS procedures over E-UTRA (i.e. Mobility Management, Session Management etc) as defined in TS 24.301 [13].

A UE that supports camping on 5G Systems with 5GC NAS:

– performs initial access either through E-UTRAN that connects to 5GC or NR towards 5GC;

– performs initial access through E-UTRAN towards EPC, if supported and needed;

– performs EPC NAS or 5GC NAS procedures over E-UTRAN or NR respectively (i.e. Mobility Management, Session Management etc) depending on whether the UE requests 5GC access or EPC access, if the UE also supports EPC NAS.

When camping on an E-UTRA cell connected to both EPC and 5GC, a UE supporting EPC NAS and 5GC NAS shall select a core network type (EPC or 5GC) and initiate the corresponding NAS procedure as specified in TS 23.122 [17].

In order to support different UEs with different capabilities in the same network, i.e. both UEs that are capable of only EPC NAS (possibly including EPC based Dual Connectivity with secondary NR) and UEs that support 5GC NAS procedures in the same network:

– eNB that supports access to 5GC shall broadcast that it can connect to 5GC. Based on that, the UE AS layer indicates "E-UTRA connected to 5GC" capability to the UE NAS layer. In addition the eNB broadcasts the supported CIoT 5GS Optimisations that the UE uses for selecting a core network type.

– It is also expected that the UE AS layer is made aware by the UE NAS layer whether a NAS signalling connection is to be initiated to the 5GC. Based on that, UE AS layer indicates to the RAN whether it is requesting 5GC access (i.e. "5GC requested" indication). The RAN uses this indication to determine whether a UE is requesting 5GC access or an EPC access. RAN routes NAS signalling to the applicable AMF or MME accordingly.

NOTE: The UE that supports EPC based Dual Connectivity with secondary RAT only does not provide this "5GC requested" indication at Access Stratum when it performs initial access and therefore eNB uses the "default" CN selection mechanism to direct this UE to an MME

The 5GC network may steer the UE from 5GC based on:

– Core Network type restriction (e.g. due to lack of roaming agreements) described in clause 5.3.4.1.1;

– Availability of EPC connectivity;

– UE indication of EPC Preferred Network Behaviour; and

– Supported Network Behaviour.

The UE that wants to use one or more of these functionalities not supported by 5G System, when in CM-IDLE may disable all the related radio capabilities that allow the UE to access 5G System. The triggers to disable and re-enable the 5GS capabilities to access 5G System in this case are left up to UE implementation.

5.17.1.2 User Plane management to support interworking with EPS

In order to support the interworking with EPC, the SMF+PGW-C provides information over N4 to the UPF+PGW-U related to the handling of traffic over S5-U. Functionality defined in TS 23.503 [45] for traffic steering control on SGi-LAN/N6 can be activated in UPF+PGW-U under consideration of whether the UE is connected to EPC or 5GC.

When the UE is connected to EPC and establishes/releases PDN connections, the following differences apply to N4 compared to when the UE is connected to 5GC:

– The CN Tunnel Info is allocated for each EPS Bearer.

– In addition to the Service Data Flow related information, the SMF+PGW-C shall be able to provide the GBR and MBR values for each GBR bearer of the PDN connection to the UPF+PGW-U.

If the UE does not have preconfigured rules for associating an application to a PDN connection (i.e. the UE does not have rules in UE local configuration and is not provisioned with ANDSF rules), the UE should use a matching URSP rule as defined in TS 23.503 [45], if available, to derive the parameters, e.g. APN, for the PDN connection establishment and associating an application to the PDN connection.

NOTE: The mapping between the parameters in the URSP rules and the parameters used for PDN connection establishment is defined in TS 24.526 [110].

5.17.1.3 QoS handling for home routed roaming

During mobility from EPS to 5GS, the handling of QoS constraints in V-SMF is specified in clauses 4.11.1.2.2 and 4.11.1.3.3 of TS 23.502 [3] and follows the same principle as described in clause 5.7.1.11.

5.17.2 Interworking with EPC

5.17.2.1 General

Interworking with EPC in this clause refers to mobility procedures between 5GC and EPC/E-UTRAN, except for clause 5.17.2.4. Network slicing aspects for EPS Interworking are specified in clause 5.15.7

In order to interwork with EPC, the UE that supports both 5GC and EPC NAS can operate in single-registration mode or dual-registration mode:

– In single-registration mode, UE has only one active MM state (either RM state in 5GC or EMM state in EPC) and it is either in 5GC NAS mode or in EPC NAS mode (when connected to 5GC or EPC, respectively). UE maintains a single coordinated registration for 5GC and EPC. Accordingly, the UE maps the EPS-GUTI to 5G GUTI during mobility between EPC and 5GC and vice versa following the mapping rules in Annex B. To enable re-use of a previously established 5G security context when returning to 5GC, the UE also keeps the native 5G-GUTI and the native 5G security context when moving from 5GC to EPC.

– In dual-registration mode, UE handles independent registrations for 5GC and EPC using separate RRC connections. In this mode, UE maintains 5G-GUTI and EPS-GUTI independently. In this mode, UE provides native 5G-GUTI, if previously allocated by 5GC, for registrations towards 5GC and it provides native EPS-GUTI, if previously allocated by EPC, for Attach/TAU towards EPC. In this mode, the UE may be registered to 5GC only, EPC only, or to both 5GC and EPC.

Dual-registration mode is intended for interworking between EPS/E-UTRAN and 5GS/NR. A dual-registered UE should not send its E-UTRA connected to 5GC and E-UTRAN radio capabilities to NR access when connected to 5GS/NR to avoid being handed over to 5GC-connected E-UTRA or to E-UTRAN.

NOTE 1: This is to prevent the dual registered UE from being connected to the same E-UTRA cell either connected to EPC or 5GC simultaneously using separate RRC connections via single RAN node as a result of handover. If a dual- registered UE implementation chooses to send its E-UTRA capability when connected to 5GS/NR, the UE and the network behaviour when UE enters a 5GC-connected E-UTRA is not further specified. If however the UE is registered with 5GS/NR only, the UE can send its E-UTRA capability in order to allow inter-RAT handover to E-UTRA/5GC and Dual Connectivity with multiple RATs.

If a dual-registered UE had not sent its E-UTRA connected to 5GC and E-UTRAN radio capabilities to 5GS and the UE needs to initiate emergency services, it shall locally re-enable its E-UTRA connected to 5GC and E-UTRAN radio capabilities in order to perform domain selection for emergency services as defined in TS 23.167 [18].

NOTE 2: However even in this case, the UE is still not expected to connect to E-UTRAN/EPC and E-UTRA/5GC simultaneously using separate RRC connection via single RAN node as a result of the domain selection for emergency services.

The support of single registration mode is mandatory for UEs that support both 5GC and EPC NAS.

During E-UTRAN Initial Attach, UE supporting both 5GC and EPC NAS shall indicate its support of 5G NAS in UE Network Capability described in clause 4.11.1.5.2 of TS 23.502 [3].

During registration to 5GC, UE supporting both 5GC and EPC NAS shall indicate its support of EPC NAS.

NOTE 3: This indication may be used to give the priority towards selection of SMF+PGW-C for UEs that support both EPC and 5GC NAS.

If the UE supports 5GC NAS, at PDN connection establishment in EPC, the UE may allocate a PDU Session ID and sends it via PCO, regardless of N1 mode status (i.e. enabled or disabled) in the UE.

NOTE 4: UE providing a PDU Session ID at PDN connection establishment even when N1 mode is disabled allows for IP address preservation during EPC to 5GC mobility once the UE re-enables N1 mode.

NOTE 5: For the case the MME has selected a standalone PGW for a PDN connection, if the UE re-enables N1 mode and reports the change in UE Network Capability, the MME can initiate PDN disconnection with reactivation required as described in clause 4.11.0a.8 of TS 23.502 [3] to allow selection of SMF+PGW-C thus session continuity at EPC to 5GC mobility.

If the EPC supports "Ethernet" PDU Session Type, and the 5GSM Capabilities indicate that the UE supports Ethernet PDN type in EPC, then PDU Session type "Ethernet" is transferred to EPC as "Ethernet". Otherwise, PDU Session types "Ethernet" and "Unstructured" are transferred to EPC as "non-IP" PDN type (when supported by UE and network). If the UE or EPC does not support Ethernet PDN type in EPC, the UE sets the PDN type to non-IP when it moves from 5GS to EPS and after the transfer to EPS, and the UE and the SMF shall maintain information about the PDU Session type used in 5GS, i.e. information indicating that the PDN Connection with "non-IP" PDN type corresponds to PDU Session type Ethernet or Unstructured respectively. This is done to ensure that the appropriate PDU Session type will be used if the UE transfers to 5GS.

PDN type "non-IP" is transferred to 5GS as "Unstructured" PDU Session type if it is successfully transferred.

It is assumed that if a UE supports Ethernet PDU Session type and/or Unstructured PDU Session type in 5GS it will also support non-IP PDN type in EPS. If this is not the case, the UE shall locally delete any EBI(s) corresponding to the Ethernet/Unstructured PDU Session(s) to avoid that the Ethernet/Unstructured PDU Session(s) are transferred to EPS.

MTU size consideration for PDU Sessions and PDN Connections towards a SMF+PGW-C follows the requirements in clause 5.6.10.4.

Networks that support interworking with EPC, may support interworking procedures that use the N26 interface or interworking procedures that do not use the N26 interface. Interworking procedures with N26 support provides IP address continuity on inter-system mobility to UEs that support 5GC NAS and EPC NAS and that operate in single registration mode. Networks that support interworking procedures without N26 shall support procedures to provide IP address continuity on inter-system mobility to UEs operating in both single-registration mode and dual-registration mode. In such networks, AMF shall provide the indication that interworking without N26 is supported to UEs during initial Registration in 5GC or MME may optionally provide the indication that interworking without N26 is supported in the Attach procedure in EPC as defined in TS 23.401 [26].

If the network does not support interworking with EPC, network shall not indicate support for "interworking without N26" to the UE.

When the HSS+UDM is required to provide the subscription data to the MME, for each APN, only one SMF+PGW-C FQDN and associated APN is provided to the MME according to TS 23.401 [26].

For interworking without N26 interface:

– if the PDU session supports interworking, the SMF+PGW-C stores the SMF+PGW-C FQDN to SMF context in HSS+UDM when the SMF is registered to HSS+UDM.

– For an APN, the HSS+UDM selects one of the stored SMF+PGW-C FQDN based on operator’s policy.

For interworking with N26 interface:

– For a DNN, AMF determines PDU session(s) associated with 3GPP access in only one SMF+PGW-C supporting EPS interworking via EBI allocation procedure as described in clause 4.11.1.4.1 of TS 23.502 [3].

– If the network supports EPS interworking of non-3GPP access connected to 5GC, the AMF serving 3GPP access notifies the UDM to store the association between DNN and SMF+PGW-C FQDN which supports EPS interworking as Intersystem continuity context, to avoid MME receiving inconsistent SMF+PGW-C FQDN from AMF and HSS+UDM.

– The AMF updates Intersystem continuity context if the SMF+PGW-C and DNN association is changed due to the AMF selecting another SMF+PGW-C for EPS interworking for the same DNN.

– If the SMF+PGW-C FQDN and associated DNN exists in Intersystem continuity context, the HSS+UDM provides MME with SMF+PGW-C FQDN and associated APN.

It does not assume that the HSS+UDM is aware of whether N26 is deployed in the serving network. The HSS+UDM check the Intersystem continuity context first. If no SMF+PGW-C FQDN associated with an DNN exists in Intersystem continuity context, the HSS+UDM selects one of the SMF+PGW-C FQDN for the APN from SMF context based on operator’s policy.

In entire clause 5.17.2 the terms "initial attach", "handover attach" and "TAU" for the UE procedures in EPC can alternatively be combined EPS/IMSI Attach and combined TA/LA depending on the UE configuration defined in TS 23.221 [23].

If a UE in MICO mode moves to E-UTRAN connected to EPC and any of the triggers defined in clause 5.4.1.3 occur, then the UE shall locally disable MICO mode and perform the TAU or Attach procedure as defined in clause 5.17.2. The UE can renegotiate MICO when it returns to 5GS during (re-)registration procedure.

IP address preservation for IP PDU sessions cannot be ensured on subsequent mobility from EPC/E-UTRAN to GERAN/UTRAN to a UE that had initially registered in 5GS and moved to EPC/E-UTRAN.

NOTE 6: The SMF+PGW-C might not include the GERAN/UTRAN PDP Context anchor functionality. Also, 5GC does not provide GERAN/UTRAN PDP Context parameters to the UE when QoS Flows of PDU Session are setup or modified in 5GS. Hence, the UE might not be able to activate the PDP contexts when it transitions to GERAN/UTRAN.

IP address preservation for IP PDU sessions cannot be ensured on subsequent mobility from EPC/E-UTRAN to 5GS for a 5GS NAS capable UE that had initially established a PDP context via GERAN/UTRAN and moved to EPC/E-UTRAN. IP address preservation for IP PDU session mobility between EPC/E-UTRAN and 5GS may be re-ensured as specified in clause 5.17.2.4 when UE moves from GERAN/UTRAN into EPC/E-UTRAN.

NOTE 7: The PGW acting as a GGSN might not support SMF+PGW-C functionality. GPRS does not support 5GS parameters transfer between UE and SMF+PGW-C (e.g. providing of PDU session ID and 5GS QoS information).

When a PDU session is moved from 5GS to EPS, the SMF+PGW-C keeps the registration and subscription in HSS+UDM until the corresponding PDN connection is released.

The SMF+PGW-C receives notification of subscription update regarding the 5G parameters (e.g. DNNs, S-NSSAIs) which are associated with the established PDN connection(s) connecting via EPS. If the subscription regarding DNN, QoS profile or PDN connection type associated with the PDN connection is updated, then the MME receives the subscription update and triggers corresponding actions according to TS 23.401 [26]. If the SMF+PGW-C receives subscription updates (e.g. change of 5GS Subscribed NSSAI) from the UDM the SMF+PGW-C triggers corresponding actions for the PDN connection. This may include (depending on the modified parameter) to:

– update the UPF (e.g. for a change of Framed Route information); or

– release the PDN connection with an appropriate cause (e.g. for change of EPS/5GS interworking support, for subscription removal of S-NSSAI associated with the PDN connection);

– do nothing about changes to DNN and/or PDU Session type that are handled by the MME.

If header compression is used for Control Plane CIoT EPS/5GS Optimisations and when the UE moves from EPS to 5GS or from 5GS to EPS, the UE may initiate the PDU Session Modification Procedure or UE requested bearer resource modification procedure to renegotiate the header compression configuration and to establish the compression context between the UE and MME/SMF, see TS 23.401 [26] and TS 24.501 [47].

If the UE is moving from 5GS to EPS and the RAT type is also moving from a "broadband" RAT (e.g. NR or WB-E-UTRA) to NB-IoT in EMM-IDLE state, the UE should set the mapped EPS bearer context for which the EPS bearer is a dedicated EPS bearer to state BEARER CONTEXT INACTIVE as for NB-IoT UEs in EPS only support the default bearers. In addition, UE shall locally deactivate the related bearers according to the maximum number of supported UP resources and send the latest bearer context status in the TAU Request.

If APN Rate Control is used when the UE moves from EPC to 5GC then the P-GW/SCEF and UE store the current APN Rate Control Status for an APN. If while connected to 5GC the last PDU Session to a DNN that is the same as the APN identified in the APN Rate Control Status is released then the APN Rate Control Status may be stored in the AMF in addition to the Small Data Rate Control Status and the UE discards the APN Rate Control Status. The APN Rate Control Status is stored in the AMF so it can be provided to the MME during mobility to EPC and subsequently applied at establishment of a new first PDN Connection to the same APN, if valid. The APN Rate Control Status is provided to the UPF+PGW-U if a first new PDU Session is established towards the DNN that is the same as the APN identified in the APN Rate Control Status if the UE moves back to EPC, taking into account its validity period.

The UE may be provided with initial APN Rate Control parameters by the SMF when a first new PDU Session is established for a DNN and S-NSSAI that supports interworking with EPS and the DNN matches an APN. The SMF provides the APN Rate Control Status for the APN that matches the DNN, if available at the SMF, otherwise the configured APN Rate Control parameters for the APN that matches the DNN are provided as the initially applied parameters. If the initially applied parameters differ from the configured APN Rate Control parameters and the first APN Rate Control validity period expires, the UE is updated with the configured APN Rate Control parameters once the UE has moved to EPC.

NOTE 8: If the APN Rate Control Status is provided to a UPF+PGW-U it is not used for Small Data Rate Control while the UE is connected to 5GC, it is only used as the APN Rate Control Status if the UE moves to EPC.

NOTE 9: Encoding of APN and DNN specified in TS 23.003 [19] allows the comparison of EPS APN and 5GS DNN.

If a Service Gap timer is running in the AMF when the UE moves from 5GC to EPC, the AMF stops the running Service Gap timer. If the UE returns to 5GC from EPC the AMF provides the Service Gap Time to the UE as described in clause 5.31.16.

If a Service Gap timer is running in the MME when the UE moves from EPC to 5GC, the MME stops the running Service Gap timer. If the UE returns to E-UTRAN connected to EPC from 5GC the MME provides the Service Gap Time to the UE as described in TS 23.401 [26].

If a Service Gap timer is running in the UE when the UE moves to from 5GC to EPC and if Service Gap Time is received from the MME, the UE stores the received Service Gap Time for later use when the timer needs to be started next time, and the Service Gap timer that was started before the system change is kept running in the UE and applied for EPC. If a Service Gap timer is running in the UE when the UE moves to 5GC and if Service Gap Time is received from the AMF, the UE stores the received Service Gap Time for later use when the timer needs to be started next time, and the Service Gap timer that was started before the system change is kept running in the UE and applied in 5GS.

For UE currently served by EPC, a SMF+PGW-C may support L2TP tunnelling on N6, as described in clause 5.8.2.16.

5.17.2.2 Interworking Procedures with N26 interface

5.17.2.2.1 General

Interworking procedures using the N26 interface, enables the exchange of MM and SM states between the source and target network. The N26 interface may be either intra-PLMN or inter-PLMN (e.g. to enable inter-PLMN mobility). When interworking procedures with N26 is used, the UE operates in single-registration mode. For the 3GPP access, the network keeps only one valid MM state for the UE, either in the AMF or MME. For the 3GPP access, either the AMF or the MME is registered in the HSS+UDM.

The support for N26 interface between AMF in 5GC and MME in EPC is required to enable seamless session continuity (e.g. for voice services) for inter-system change.

The UE’s subscription may include restriction for Core Network Type (EPC) and RAT restriction for E-UTRA. If so, the UDM provides these restrictions to the AMF. The AMF includes RAT and Core Network type restrictions in the Handover Restriction List to the NR. The AMF and NR use these restrictions to determine if mobility of the UE to EPS or E-UTRA connected to EPS should be permitted. When the UE moves from 5GS to EPS, the SMF determines which PDU Sessions can be relocated to the target EPS, e.g. based on capability of the deployed EPS, operator policies for which PDU Session, seamless session continuity should be supported etc. The SMF can release the PDU Sessions that cannot be transferred as part of the handover or Idle mode mobility. However, whether the PDU Session is successfully moved to the target network is determined by target EPS.

Similarly, the UE’s subscription may include restriction for Core Network Type (5GC) and RAT restriction for NR. If so, the HSS provides these restrictions to the MME. The MME includes RAT and Core Network type restrictions in the Handover Restriction List to the E-UTRAN. The MME and E-UTRAN use these restrictions to determine if mobility of the UE to 5GS or NR connected to 5GS should be permitted. If the SMF+PGW-C receives the PDU session ID from UE via PCO and know 5GC is not restricted for the PDN connection by user subscription, the SMF+PGW-C sends the mapped QoS parameters to UE. When the UE moves from EPS to 5GS, for the case when the MME has selected SMF+PGW-C even for PDN connections that cannot be relocated to the target 5GS, the SMF+PGW-C determines which PDN Connections can be relocated to the target 5GS, e.g. based on capability of the deployed 5GS, subscription and operator policies for which PDN Connection, seamless session continuity should be supported etc. The SMF+PGW-C and NG-RAN can reject the PDN Connections that cannot be transferred as part of the handover or Idle mode mobility.

For the case when the MME has selected standalone P-GW for a PDN connection for which session continuity is not supported and the AMF cannot retrieve the address of the corresponding SMF during EPS to 5GS mobility, the AMF does not move the PDN connection to 5GS.

NOTE 1: When applying the AMF planned removal procedure or the procedure to handle AMF failures (see clause 5.21.2) implementations are expected to update the DNS configuration to enable MMEs to discover alternative AMFs if the MME tries to retrieve a UE context from an AMF that has been taken out of service or has failed. This addresses the scenario of UEs performing 5GS to EPS Idle mode mobility and presenting a mapped GUTI pointing to an AMF that has been taken out of service or has failed.

In the case of mobility from 5GS to EPS, if the MME lacks certain capability, e.g. MME not supporting 15 EPS bearers, the 5GC shall not transfer the UE EPS bearers and/or EPS PDN connections that are not supported by the EPC network. If the MME does not support 15 EPS bearers, the AMF determines which EBIs cannot be transferred to EPS, and retrieves the EPS bearer contexts from the SMF+PGW-C for the EBIs that can be transferred to EPS.

NOTE 2: How the AMF determines which EBIs can be transferred to EPS is according to local configuration, e.g. according to DNN, S-NSSAI, ARP associated with an EBI.

In the case of mobility from 5GS to EPS, if the mobility is triggered by the PCF when it determines to modify the RFSP Index value to indicate a change in priority from 5G access to E-UTRAN access for the UE as specified in TS 23.503 [45], the PCF may, based on operator policy, include a validity time in the message sent to the AMF. If the AMF receives RFSP in Use Validity Time and selects the RFSP Index in use identical to the authorized RFSP Index as specified in clause 5.3.4.3, then the AMF provides the MME the RFSP in Use Validity Time, which indicates the time by which the RFSP Index in use will be used in the MME as specified in clause 4.11.1.5.8 of TS 23.502 [3].

NOTE 3: The RFSP in Use Validity Time is to allow the UE to stay in EPS for a period of time to avoid the potential ping-pong issue (i.e., 5GS keeps sending the UE to EPS based on authorized RFSP Index from PCF, and the EPS keeps sending the UE back to 5GS immediately based on the subscribed RFSP Index.

Editor’s note: Whether PCF needs to be aware the modified RFSP index indicates a change of priority from 5GC to EPC is FFS.

5.17.2.2.2 Mobility for UEs in single-registration mode

When the UE supports single-registration mode and network supports interworking procedure with the N26 interface:

– For idle mode mobility from 5GS to EPS, the UE performs either TAU or Attach procedure with EPS GUTI mapped from 5G-GUTI sent as old Native GUTI, as described in clause 4.11.1.3.2.1 of TS 23.502 [3] and indicates that it is moving from 5GC. The UE includes in the RRC message a GUMMEI mapped from the 5G-GUTI and indicates it as a native GUMMEI and should in addition indicate it as "Mapped from 5G-GUTI". The MME retrieves the UE’s MM and SM context from 5GC. For connected mode mobility from 5GS to EPS, either inter-system handover or RRC Connection Release with Redirection to E-UTRAN is performed. At inter-system handover, the AMF selects target MME based on 2 octet TAC format used in the Target ID as specified in TS 38.413 [34]. During the TAU or Attach procedure the HSS+UDM cancels any AMF registration associated with the 3GPP access (but not AMF registration associated with the non-3GPP access): an AMF that was serving the UE over both 3GPP and non-3GPP accesses does not consider the UE as deregistered over non 3GPP access.

– For the first TAU after 5GC initial Registration, the UE and MME for the handling of UE Radio Capabilities follow the procedures as defined in clause 5.11.2 of TS 23.401 [26] for first TAU after GERAN/UTRAN Attach.

NOTE 1: MMEs supporting interworking with N26 interface are not required to process the indication from the UE that it is moving from 5GC and will assume that the UE is moving from another MME.

– For idle mode mobility from EPC to 5GC, the UE performs mobility Registration procedure with the 5G GUTI mapped from EPS GUTI and indicates that it is moving from EPC. The UE derives GUAMI from the native 5G-GUTI and includes GUAMI in the RRC message to enable RAN to route to the corresponding AMF (if available). If the UE holds no native 5G-GUTI, then the UE provides in the RRC message a GUAMI mapped from the EPS GUTI and indicates it as "Mapped from EPS". The AMF and SMF retrieve the UE’s MM and SM context from EPC. For connected mode mobility from EPC to 5GC, either inter-system handover or RRC Connection Release with Redirection to NG-RAN is performed. At inter-system handover, the MME selects target AMF based on TAC used in the Target ID as specified in TS 38.413 [34]. During the Registration procedure, the HSS+UDM cancels any MME registration.

NOTE 2: During a transition period, the source eNB may be configured via O&M to know that the MME is not upgraded and thus supports only 2 octet TAC. The Target ID for the NG-RAN node is set as "Target eNB ID" in the existing IEs as defined in TS 38.413 [34].

For both idle mode and connected mode mobility from EPC to 5GC:

– The UE includes the native 5G-GUTI as an additional GUTI in the Registration request; the AMF uses the native 5G-GUTI to retrieve MM context identified by the 5G-GUTI from old AMF or from UDSF (if UDSF is deployed and the old AMF is within the same AMF set).

– If this is the first mobility event for a PDU Session that was established while being connected to EPC, the UE shall trigger the PDU Session Modification procedure and:

– should indicate the support of Reflective QoS to the network (i.e. SMF) if the UE supports Reflective QoS functionality. If the UE indicated support of Reflective QoS, the network may provide a Reflective QoS Timer (RQ Timer) value to the UE;

– shall indicate the number of supported packet filters for signalled QoS rules, if the UE supports more than 16 packet filters for the PDU Session. The network shall store this information so that subsequent mobility events do not require another signalling of it.

– should indicate the support of Multi-homed IPv6 PDU session to the network (i.e. SMF) if the UE supports Multi-homed IPv6 PDU session. If the UE indicated support of Multi-homed IPv6 PDU session, the network shall consider that this PDU session is supported to use multiple IPv6 prefixes.

– should provide the UE Integrity Protection Maximum Data Rate to the network (i.e. SMF). The network shall consider that the maximum data rate per UE for user-plane integrity protection supported by the UE is valid for the lifetime of the PDU session.

5.17.2.3 Interworking Procedures without N26 interface

5.17.2.3.1 General

For interworking without the N26 interface, IP address preservation is provided to the UEs on inter-system mobility by storing and fetching SMF+PGW-C and corresponding APN/DNN information via the HSS+UDM. In such networks AMF also provides an indication that interworking without N26 is supported to UEs during Initial Registration in 5GC or MME may optionally provide an indication that interworking without N26 is supported in the Attach procedure in EPC as defined in TS 23.502 [3] and TS 23.401 [26]. The UE provides an indication that it supports Request Type flag "handover" for PDN connectivity request during the attach procedure as described in clause 5.3.2.1 of TS 23.401 [26] and during initial Registration and Mobility Registration Update in 5GC.

NOTE 1: The UE support of Request Type flag "handover" for PDN connectivity request during the attach procedure is needed for IP address preservation in the case of interworking without N26.

The indication that interworking without N26 is valid for the entire Registered PLMN and for PLMNs equivalent to the Registered PLMN that are available in the Registration Area. The same indication is provided to all UEs served by the same PLMN. UEs that operate in interworking without N26 may use this indication to decide whether to register early in the target system. UEs that only support single registration mode may use this indication as described in clause 5.17.2.3.2. UE that support dual registration mode uses this indication as described in clause 5.17.2.3.3.

Interworking procedures without N26 interface use the following two features:

1. When UE performs Initial Attach in EPC (with or without "Handover" indication in PDN CONNECTIVITY Request message) and indicates that it is moving from 5GC, the MME indicates to the HSS+UDM not to cancel the registration of AMF, if any.

2. When UE performs Initial Registration in 5GC and indicates that it is moving from EPC, the AMF indicates to the HSS+UDM not to cancel the registration of MME, if any.

To support mobility both for single and dual registration mode UEs, the following also are supported by the network:

3. When PDU Session are created in 5GC, the SMF+PGW-C which supports EPS interworking stores the SMF+PGW-C FQDN along with DNN in the HSS+UDM.

4. The HSS+UDM provides the information about dynamically allocated SMF+PGW-C and APN/DNN information to the target CN network. If there are multiple SMF+PGW-C serving the UE for the same DNN which support EPS interworking in 5GS, the HSS+UDM select one of them according to operator’s policy and provides together with the associated APN to the MME.

5. When PDN connections are created in EPC, the MME stores the SMF+PGW-C and APN information in the HSS+UDM.

NOTE 2: Items 3, 4 and 5 are also supported in networks that support interworking with N26 procedures. This enables a VPLMN that does not deploy N26 interface to provide IP address preservation to roamed-in single-registration mode UEs from a HPLMN that only supports interworking with N26 procedures.

When the network serving the UE supports 5GS-EPS interworking procedures without N26 interface, the SMF shall not provide the UEs with mapped target system parameters of the target system when UE is in the source network.

A UE that operates in dual registration mode ignores any received mapped target system parameters (e.g. QoS parameters, bearer IDs/QFI, PDU Session ID, etc.).

5.17.2.3.2 Mobility for UEs in single-registration mode

When the UE supports single-registration mode and network supports interworking procedure without N26 interface:

– For mobility from 5GC to EPC, the UE with at least one PDU Session established in 5GC may either:

– if supported and if it has received the network indication that interworking without N26 is supported, perform Attach in EPC with a native EPS GUTI, if available, otherwise with IMSI with Request type "Handover" in PDN CONNECTIVITY Request message (clause 5.3.2.1 of TS 23.401 [26]) and indicating that the UE is moving from 5GC and subsequently moves all its other PDU Session using the UE requested PDN connectivity establishment procedure with Request Type "handover" flag (clause 5.10.2 of TS 23.401 [26]), or.

– perform TAU with 4G-GUTI mapped from 5G-GUTI sent as old Native GUTI (clause 5.3.3 of TS 23.401 [26]) indicating that it is moving from 5GC, in which case the MME instructs the UE to re-attach. IP address preservation is not provided in this case.

– for the first TAU after 5GC initial Registration, the UE and MME for the handling of UE Radio Capabilities follow the procedures as defined in clause 5.11.2 TS 23.401 [26] for first TAU after GERAN/UTRAN Attach.

NOTE 1: The first PDN connection may be established during the E-UTRAN Initial Attach procedure (see TS 23.401 [26]).

NOTE 2: At inter-PLMN mobility to a PLMN that is not an equivalent PLMN the UE always uses the TAU procedure.

– For mobility from 5GC to EPC, the UE with no PDU Session established in 5GC

– performs Attach in EPC (clause 5.3.2.1 of TS 23.401 [26]) indicating that the UE is moving from 5GC.

– For mobility from EPC to 5GC, the UE performs Mobility Registration Update in 5GC with 5G-GUTI mapped from EPS GUTI and a native 5G-GUTI, if available, as Additional GUTI and indicating that the UE is moving from EPC. In this case, the AMF determines that old node is an MME, but proceeds as if the Registration is of type "initial registration". The UE may either:

– if supported and if it has received the network indication "interworking without N26 supported", move all its PDN connections from EPC using the UE initiated PDU Session Establishment procedure with "Existing PDU Sessions" flag (clause 4.3.2.2.1 of TS 23.502 [3]), or

– re-establish PDU Sessions corresponding to the PDN connections that it had in EPS. IP address preservation is not provided in this case.

NOTE 3: The additional native 5G-GUTI enables the AMF to find the UE’s 5G security context (if available).

NOTE 4: When single-registration mode UE uses interworking procedures without N26, the registration states during the transition period (e.g. while UE is transferring all PDU Sessions / PDN Connections on the target side) are defined in Stage 3 specifications.

– If the network determines that the UE is changing RAT type, if the UE requests to relocate the PDU session from EPC to 5GC or 5GC to EPC, the SMF/MME uses the "PDU session continuity at inter RAT mobility" or "PDN continuity at inter-RAT mobility" information, respectively, in the subscription to determine whether to maintain the PDU session/PDN connection (if being handed over) or reject the PDU session request, with the relevant cause.

– If the UE requested to move the PDU session and the "PDN continuity at inter RAT mobility" information indicated "disconnect the PDN connection with a reactivation request" the network should provide a suitable cause code to the UE so that it can request a new PDU session.

5.17.2.3.3 Mobility for UEs in dual-registration mode

To support mobility in dual-registration mode, the support of N26 interface between AMF in 5GC and MME in EPC is not required. A UE that supports dual registration mode may operate in this mode when it receives an indication from the network that interworking without N26 is supported.

For UE operating in dual-registration mode the following principles apply for PDU Session transfer from 5GC to EPC:

– UE operating in Dual Registration mode may register in EPC ahead of any PDU Session transfer using the Attach procedure indicating that the UE is moving from 5GC without establishing a PDN Connection in EPC if the EPC supports EPS Attach without PDN Connectivity as defined in TS 23.401 [26]. Support for EPS Attach without PDN Connectivity is mandatory for UE supporting dual-registration procedures.

NOTE 1: Before attempting early registration in EPC the UE needs to check whether EPC supports EPS Attach without PDN Connectivity by reading the related SIB in the target cell.

– UE performs PDU Session transfer from 5GC to EPC using the UE initiated PDN connection establishment procedure with "handover" indication in the PDN Connection Request message (clause 5.10.2 of TS 23.401 [26]).

– If the UE has not registered with EPC ahead of the PDU Session transfer, the UE can perform Attach in EPC with "handover" indication in the PDN Connection Request message (clause 5.3.2.1 of TS 23.401 [26]).

– UE may selectively transfer certain PDU Sessions to EPC, while keeping other PDU Sessions in 5GC.

– UE may maintain the registration up to date in both 5GC and EPC by re-registering periodically in both systems. If the registration in either 5GC or EPC times out (e.g. upon mobile reachable timer expiry), the corresponding network starts an implicit detach timer.

NOTE 2: Whether UE transfers some or all PDU Sessions on the EPC side and whether it maintains the registration up to date in both EPC and 5GC can depend on UE capabilities that are implementation dependent. The information for determining which PDU Sessions are transferred on EPC side and the triggers can be pre-configured in the UE and are not specified in this Release of the specification. The UE does not know before-hand, i.e. before trying to move a given PDU session to EPC, whether that PDU session can be transferred to EPC.

For UE operating in dual-registration mode the following principles apply for PDN connection transfer from EPC to 5GC:

– UE operating in Dual Registration mode may register in 5GC ahead of any PDN connection transfer using the Registration procedure indicating that the UE is moving from EPC (clause 4.2.2.2.2 of TS 23.502 [3]).

– UE performs PDN connection transfer from EPC to 5GC using the UE initiated PDU Session Establishment procedure with "Existing PDU Session" indication (clause 4.3.2.2.1 of TS 23.502 [3]).

– UE may selectively transfer certain PDN connections to 5GC, while keeping other PDN Connections in EPC.

– UE may maintain the registration up to date in both EPC and 5GC by re-registering periodically in both systems. If the registration in either EPC or 5GC times out (e.g. upon mobile reachable timer expiry), the corresponding network starts an implicit detach timer.

NOTE 3: Whether UE transfers some or all PDN connections on the 5GC side and whether it maintains the registration up to date in both 5GC and EPC can depend on UE capabilities that are implementation dependent. The information for determining which PDN connections are transferred on 5GC side and the triggers can be pre-configured in the UE and are not specified in this Release of the specification. The UE does not know before-hand, i.e. before trying to move a given PDN connection to 5GC, whether that PDN connection can be transferred to 5GC.

NOTE 4: If EPC does not support EPS Attach without PDN Connectivity the MME detaches the UE when the last PDN connection is released by the PGW as described in clause 5.4.4.1 of TS 23.401 [26] (in relation to transfer of the last PDN connection to non-3GPP access).

When sending a control plane request for MT services (e.g. MT SMS) the network routes it via either the EPC or the 5GC. In absence of UE response, the network should attempt routing the control plane request via the other system.

NOTE 5: The choice of the system through which the network attempts to deliver the control plane request first is left to network configuration.

5.17.2.3.4 Redirection for UEs in connected state

When the UE supports single-registration mode or dual-registration mode without N26 interface:

– If the UE is in CM-CONNECTED state in 5GC, the NG-RAN may perform RRC Connection Release with Redirection to E-UTRAN based on certain criteria (e.g. based on local configuration in NG-RAN, or triggered by the AMF upon receiving Handover Request message from NG-RAN).

– If the UE is in ECM-CONNECTED state in EPC, the E-UTRAN may perform RRC Connection release with redirection to NG-RAN based on certain criteria (e.g. based on local configuration in E-UTRAN, or triggered by the MME upon receiving handover request from E-UTRAN).

5.17.2.4 Mobility between 5GS and GERAN/UTRAN

IP address preservation upon direct mobility between 5GS and GERAN/UTRAN is not supported.

Upon mobility from 5GS to GERAN/UTRAN (e.g. upon leaving NG-RAN coverage) the UE shall perform the A/Gb mode GPRS Attach procedure or Iu mode GPRS Attach procedure (see TS 23.060 [56]).

As a UE option, to support IP address preservation at mobility from EPC to 5GS for PDN connections without 5GS related parameters, a 5GS capable UE may:

– Following mobility from GERAN/UTRAN to EPS, release those PDN connection(s) and re-establish them as specified in clause 4.11.1.5.4.1 of TS 23.502 [3] so that they support interworking to 5GS.

NOTE 1: It is recommended that a UE using this option does not do this behaviour after every change to EPS in PLMNs that do not support 5GS, nor for APNs that do not support mobility to 5GS; and, that such a UE supports storage of the 5GS related parameters while in GERAN/UTRAN. Whether and how the UE is aware of which PLMNs support 5GS and which APNs do not support mobility to 5GS is out of scope of this specification.

To support mobility from EPC to 5GS to EPC to GERAN/UTRAN for PDN connections established in EPC:

NOTE 2: For the use of N7 or N40 interfaces while the UE is in GERAN/UTRAN access, the SMF+PGW-C selected by the MME (using the existing selection procedures described in clause 4.11.0a of TS 23.502 [3] and clause 4.3.8 of TS 23.401 [26]) needs to support functionality (e.g. signalling of GERAN/UTRAN cell identification over N7) specified in Annex L.

– in signalling sent on the N26 interface, the MME should send the TI and BSS Container in the EPS Bearer Context (see Table 7.3.1-3 of TS 29.274 [101]), if there is any, of the EPS bearer to the SMF (V-SMF / I-SMF) via the AMF in the Bearer Context within the PDN Connection IE in the Forward Relocation Request and Context Response messages (TS 29.274 [101]); the SMF (V-SMF / I-SMF) should store the TI and BSS Container and the SMF (V-SMF / I-SMF) should provide the TI and BSS Container to the AMF (as part of a procedure to deliver SM context to AMF) so that the AMF sends the TI and BSS Container of the related EPS bearer in the Bearer Context within the EPS PDN Connection information in any subsequent Forward Relocation Request and Context Response message sent to an MME.

NOTE 3: At mobility from EPC, the SMF+PGW-C / V-SMF / I-SMF receives the TI and BSS Container as part of the UE EPS PDN Connection information from the AMF and stores the TI. At mobility to EPC, the SMF+PGW-C / V-SMF / I-SMF provides the AMF with the TI and BSS Container as part of the UE EPS PDN Connection information. The SMF+PGW-C / V-SMF / I-SMF is not meant to understand the TI/BSS Container nor to use it for any other purpose than providing it back to AMF.

NOTE 4: GERAN/UTRAN Mobility Management Bearer Synchronisation procedures will release any dedicated QoS Flows established in 5GS.

NOTE 5: When the UE access the network via GERAN/UTRAN over Gn/Gp interface, Secondary PDP Context Activation Procedure is not supported.

IP address preservation at mobility from EPC to GERAN/UTRAN for PDU sessions established in 5GS is not supported.

With regard to interworking between 5GS and the Circuit Switched domain when the GERAN or UTRAN network is operating in NMO II (i.e. no Gs interface between MSC and SGSN):

– upon mobility from 5GS to GERAN/UTRAN, the UE shall either:

– act as if it is returning after a loss of GERAN/UTRAN coverage (and e.g. only perform a periodic LAU if the periodic LAU timer has expired), or,

– perform a Location Update to the MSC. If the UE is registered for IMS voice and is configured, using Device Management or initial provisioning, to perform additional mobility management procedures when it has moved from a RAT that supports IMS voice over PS sessions to one that does not (see TS 23.060 [56]), it shall follow this option.

Upon mobility from GERAN/UTRAN to 5GS (e.g. upon selecting an NG-RAN cell) the UE shall perform the Registration procedure of "initial registration" type as described in TS 23.502 [3]. The UE shall indicate a 5G-GUTI as UE identity in the Registration procedure if it has a stored valid native 5G-GUTI (e.g. from an earlier registration in the 5G System). Otherwise the UE shall indicate a SUCI.

If a UE in MICO mode moves to GERAN/UTRAN and any of the triggers defined in clause 5.4.1.3 occur, then the UE shall locally disable MICO mode and perform the A/Gb mode GPRS Attach procedure or Iu mode GPRS Attach procedure (see TS 23.060 [56]). The UE can renegotiate MICO when it returns to 5GS during (re-)registration procedure.

In Single Registration mode, expiry of the periodic RAU timer, or, the periodic LAU timer shall not cause the UE to change RAT.

The 5G SRVCC from NG-RAN to UTRAN is specified in the TS 23.216 [88]. After the 5G SRVCC to UTRAN, all the PDU sessions of the UE are released.

5.17.2.5 Secondary DN authentication and authorization in EPS Interworking case

Secondary authentication/authorization by a DN-AAA server during the establishment of a PDN connection over 3GPP access to EPC, is supported based on following principles:

– It is optional for the UE to support EAP-based secondary authentication and authorization by DN-AAA over EPC,

– A SMF+PGW-C shall be used to serve DNN(s) requiring secondary authentication/authorization by a DN-AAA server,

– For secondary authentication/authorization by a DN-AAA server, the SMF+PGW-C runs the same procedures with PCF, UDM and DN-AAA and uses the same corresponding interfaces regardless of whether the UE is served by EPS or 5GS,

– The interface towards the UE is different (usage of NAS for EPS instead of NAS for 5GS) between the EPS and 5GS cases.

This is further specified in Annex H of TS 23.502 [3].

In this Release, EAP based Secondary authentication by a DN-AAA server during the establishment of a PDN connection over non-3GPP access to EPC is not supported.

5.17.3 Interworking with EPC in presence of Non-3GPP PDU Sessions

When a UE is simultaneously connected to the 5GC over a 3GPP access and a non-3GPP access, it may have PDU Sessions associated with 3GPP access and PDU Sessions associated with non-3GPP access. When inter-system handover from 5GS to EPS is performed for PDU Sessions associated with 3GPP access, the PDU Sessions associated with non-3GPP access are kept anchored by the network in 5GC and the UE may either:

– keep PDU Sessions associated with non-3GPP access in 5GS (5GC+N3IWF or TNGF) (i.e. the UE is then registered both in EPS and, for non-3GPP access, in 5GS); or

– locally or explicitly release PDU Sessions associated with non-3GPP access; or

– once in EPS, transfer PDU Sessions associated with non-3GPP access to E-UTRAN by triggering PDN connection establishment with Request Type "Handover", as specified in TS 23.401 [26].

5.17.4 Network sharing support and interworking between EPS and 5GS

The detailed description for supporting network sharing and interworking between EPS and 5GS is described in clauses 4.11.1.2.1, 4.11.1.2.2, 4.11.1.3.2 and 4.11.1.3.3 of TS 23.502 [3].

5.17.5 Service Exposure in Interworking Scenarios

5.17.5.1 General

Clause 4.3.5 shows the Service Exposure Network Architecture in scenarios where for EPC-5GC Interworking is required.

In scenarios where interworking between 5GS and EPC is possible, the network configuration is expected to associate UEs with SCEF+NEF node(s) for Service Capability Exposure. The SCEF+NEF hides the underlying 3GPP network topology from the AF (e.g. SCS/AS) and hides whether the UE is served by 5GC or EPC.

If the service exposure function that is associated with a given service for a UE is configured in the UE’s subscription information, then an SCEF+NEF identity shall be used to identify the exposure function. For example, if a UE is capable of switching between EPC and 5GC, then the SCEF ID that is associated with any of the UE’s APN configurations should point to an SCEF+NEF node.

For external exposure of services related to specific UE(s), the SCEF+NEF resides in the HPLMN. Depending on operator agreements, the SCEF+NEF in the HPLMN may have interface(s) with NF(s) in the VPLMN.

The SCEF+NEF exposes over N33 the same API as the SCEF supports over T8. If CAPIF is not supported, the AF is locally configured with the API termination points for each service. If CAPIF is supported, the AF obtains the service API information from the CAPIF core function via the Availability of service APIs event notification or Service Discover Response as specified in TS 23.222 [64].

The common state information shall be maintained by the combined SCEF+NEF node in order to meet the external interface requirements of the combined node. The common state information includes at least the following data that needs to be common for the SCEF and NEF roles of SCEF+NEF:

– SCEF+NEF ID (must be the same towards the AF).

– SCEF+NEF common IP address and port number.

– Monitoring state for any ongoing monitoring request.

– Configured set of APIs supported by SCEF+ NEF.

– PDN Connection/PDU Session State and NIDD Configuration Information, including Reliable Data Service state information.

– Network Parameter Configuration Information (e.g. Maximum Response Time and Maximum Latency).

The SCEF+NEF need not perform the same procedures for the configuration of monitoring events towards the HSS+UDM twice. For example, if the HSS+UDM is deployed as a combined node, a monitoring event only need to be configured by the SCEF+NEF just once.

The SCEF+NEF may configure monitoring events applicable to both EPC and 5GC using only 5GC procedures towards UDM. In this case, the SCEF+NEF shall indicate that the monitoring event is also applicable to EPC (i.e. the event must be reported both by 5GC and EPC) and may include a SCEF address (i.e. if the event needs to be configured in a serving node in the EPC and the corresponding notification needs to be sent directly to the SCEF). If the HSS and UDM are deployed as separate network entities, UDM shall use HSS services to configure the monitoring event in EPC as defined in TS 23.632 [102]. The UDM shall return an indication to SCEF+NEF of whether the configuration of the monitoring event in EPC was successful. In the case that the UDM reports that the configuration of a monitoring event was not possible in EPC, then the SCEF+NEF may configure the monitoring event using EPC procedures via the HSS as defined in TS 23.682 [36].

NOTE 1: The SCEF+NEF uses only 5GC procedures to configure monitoring events in EPC and 5GC.

NOTE 2: In terms of the CAPIF, the SCEF+NEF is considered a single node.

5.17.5.2 Support of interworking for Monitoring Events

5.17.5.2.1 Interworking with N26 interface

In addition to the interworking principles documented in clause 5.17.2.2, the following applies for interworking with N26:

– When UE moves from EPS to 5GS, when the AMF registers in UDM, if no event subscription via UDM is available, the AMF indicates the situation to the UDM, and in this case the UDM can decide if the event subscriptions should be provisioned, otherwise if the AMF has event subscription information, after the registration procedure is completed, the AMF may inform the UDM of the currently subscribed events, and UDM will do synchronization if needed.

– When UE moves from 5GS to EPS, the MME gets monitoring event configuration from HSS during as part of mobility procedure as specified in clause 4.11.1.3.2 of TS 23.502 [3].

5.17.5.2.2 Interworking without N26 interface

In addition to the interworking principles documented in clause 5.17.2.3, the additional behaviour at EPS to 5GS mobility in clause 5.17.5.2.1 also applies.

When SCEF+NEF performs the procedure of monitoring via the AMF as described in clause 4.15.3.2.4 ("Exposure with bulk subscription") in TS 23.502 [3], if the AMF determines the interworking without N26 interface is supported, during mobility from 5GS to EPS, the AMF shall subscribe on behalf of SCEF+NEF for UDM+HSS notification of MME ID as described in clause 7.1.2 to trigger the SCEF+NEF to configure the monitoring request to the new MME. For single-registration mode, when UE’s mobility from 5GS to EPS happens and Serving MME sends Update Location Request to the UDM+HSS, the UDM+HSS provides Serving MME ID to the SCEF+NEF which is the notification endpoint based on the subscription request from AMF. Then the SCEF+NEF performs the procedure of configuring monitoring via the MME for the same Monitoring Events as described in clause 5.6.2.1 of TS 23.682 [36].

When SCEF+NEF performs the procedure of monitoring via the UDM+HSS as described in clause 4.15.3.2.2 of TS 23.502 [3], when UE’s mobility between 5GS and EPS happens, the UDM+HSS performs the procedure of configuring monitoring at the MME as described in clause 5.6.1.1 of TS 23.682 [36] and at the AMF as described in clause 4.15.3.2.1 of TS 23.502 [3].

5.17.5.3 Availability or expected level of a service API

A service related with common north-bound API may become unavailable due to UE being served by a CN node not supporting the service. If the availability or expected level of support of a service API associated with a UE changes, for example due to a mobility between 5GC and EPC, the AF shall be made aware of the change.

NOTE 1: If CAPIF is supported and the service APIs become (un)available for the 5GC or EPC network, the AF obtains such information from the CAPIF core function.

If the SCEF+NEF receives the subscription request from the AF for the availability or expected level of support of a service API, the SCEF+NEF subscribes a CN Type Change event for the UE or Group of UEs to the HSS+UDM. If the HSS+UDM receives the subscription for CN Type Change event, the HSS+UDM includes the latest CN type for the UE or Group of UEs in the response for the subscription. If the HSS+UDM detects that the UE switches between being served by the MME and the AMF, the CN Type Change event is triggered, and the HSS+UDM notifies the latest CN type for the UE or Group of UEs to the SCEF+NEF. Based on the CN type information, the SCEF+NEF can determine the availability or expected level of support of a given service. The AF will be informed of such information via a subscription/notification service operation. The AF can subscribe for the availability or expected level of support of a service API with report type indicating either One-time report or Continuous report. If there is no CN type information for the UE in the SCEF+NEF, the SCEF+NEF subscribes monitoring event for a new CN Type Change event for the UE or Group of UEs to the HSS+UDM, otherwise, SCEF+NEF determines the CN type locally in the following conditions:

– If the AF subscribes with report type indicating One-time report, the SCEF+NEF may consider the Freshness Timer of the latest CN type information for the UE or Group of UEs. The Freshness Timer is a parameter that is configured based on local SCEF+NEF policy. When a subscription request with One-time report type is received the SCEF+NEF checks if there is the latest CN type information received from the HSS+UDM for the indicated UE ID or External Group ID. If the elapsed time for the CN type information since the last reception is less than the Freshness Timer, then the SCEF+NEF may respond to the AF with the latest CN type information in order to avoid repeated query to HSS+UDM.

– The SCEF+NEF has established a direct connection with MME or AMF or SMF.

When the UE or all members of a Group of UEs are being served by a MME, EPC is determined as CN type. When the UE or all members of a Group of UEs are being served by an AMF, 5GC is determined as CN type. When the UE is registered both in EPC and 5GC, or some members of a Group of UEs are registered in EPC while some members are registered in 5GC, 5GC+EPC is determined as CN type.

NOTE 2: If 5GC+EPC is determined as the CN type serving the UE or the group of UEs, the SCEF+NEF determines that service APIs for both 5GC and EPC are available to the UE or the group of UEs.

5.17.6 Void

5.17.7 Configuration Transfer Procedure between NG-RAN and E-UTRAN

5.17.7.1 Architecture Principles for Configuration Transfer between NG-RAN and E-UTRAN

The purpose of the Configuration Transfer between NG-RAN and E-UTRAN is to enable the transfer the RAN configuration information between the gNB and eNodeB via MME and AMF.

In order to make the information transparent for the MME and AMF, the information is included in a transparent container. The source and target RAN node addresses, which allows the Core Network nodes to route the messages. The mechanism depicted in Figure 5.17.7.1-1.

Figure 5.17.7.1-1: Configuration Transfer between gNB and E-UTRAN basic network architecture

The NG-RAN transparent containers are transferred from the source NG-RAN node to the destination E-UTRAN node and vice versa by use of Configuration Transfer messages.

An ENB Configuration Transfer message is used from the E-UTRAN node to the MME over S1 interface as described in TS 36.413 [100], the destination RAN node includes the en-gNB Identifier and may include a TAI associated with the en-gNB. If MME is aware that the en-gNB serves cells which provide access to 5GC, the MME relays the request towards a suitable AMF via inter-system signalling based on a broadcast 5G TAC. An AMF Configuration Transfer message is used from the AMF to the NG-RAN over N2 interface.

A Configuration Transfer message is used by the gNB node to the AMF over N2 interface for the reply, and a Configuration Transfer Tunnel message is used to tunnel the transparent container from AMF to MME over the N26 interface. MME relays this reply to the target eNB using a MME CONFIGURATION TRANSFER message. Transport of the RAN containers in E-UTRAN is specified in TS 23.401 [26].

Each Configuration Transfer message carrying the transparent container is routed and relayed independently by the core network node(s). Any relation between messages is transparent for the AMF and MME, i.e. a request/response exchange between applications, for example SON applications, is routed and relayed as two independent messages by the AMF and MME.

5.17.7.2 Addressing, routing and relaying

5.17.7.2.1 Addressing

All the Configuration Transfer messages contain the addresses of the source and destination RAN nodes.

An gNB node is addressed by the Target NG-RAN node identifier as described in TS 38.413 [34].

An eNodeB is addressed by the Target eNodeB identifier as described in TS 36.413 [100].

5.17.7.2.2 Routing

The source RAN node sends a message to its core network node including the source and destination addresses.

MME uses the destination address to route the message to the correct AMF via N26 interface. AMF uses the destination address to route the message to the correct MME via N26 interface.

The AMF connected to the destination RAN node decides which RAN node to send the message to, based on the destination address.

The MME connected to the destination RAN node decides which RAN node to send the message to, based on the destination address.

5.17.7.2.3 Relaying

The AMF performs relaying between N2 and N26 messages as described in TS 38.413 [34] and TS 29.274 [101].

The MME performs relaying between S1 and N26 message as described in TS 36.413 [100] and TS 29.274 [101].