Content for  TS 23.501  Word version:  18.5.0

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) 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. 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.

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.

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. 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 NR as secondary RAT) 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.

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.

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 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, if available, to derive the parameters, e.g. APN, for the PDN connection establishment and associating an application to the PDN connection.

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 and follows the same principle as described in clause 5.7.1.11.

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.

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. During registration to 5GC, UE supporting both 5GC and EPC NAS shall indicate its support of EPC 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. 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. 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. 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.
• 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 PGW-C+SMF 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. 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. 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. 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. 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 and TS 24.501. 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. 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. 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.

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). 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 so that they support interworking to 5GS.

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

• 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), 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); 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.

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), 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. 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). 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. After the 5G SRVCC to UTRAN, all the PDU sessions of the UE are released.

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. 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.

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. 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. 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.

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. 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.

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.

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, 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. 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.