Content for  TS 23.401  Word version:  18.6.0

This feature enables an operator to deploy multiple DCNs within a PLMN with each DCN consisting of one or multiple CN nodes. Each DCN may be dedicated to serve specific type(s) of subscriber. This is an optional feature and enables DCNs to be deployed for one or multiple RATs (e.g. GERAN, UTRAN, E-UTRAN, WB-E-UTRAN and NB-IoT). There can be several motivations for deploying DCNs, e.g. to provide DCNs with specific characteristics/ functions or scaling, to isolate specific UEs or subscribers (e.g. M2M subscribers, subscribers belonging to a specific enterprise or separate administrative domain, etc.). A DCN comprises of one or more MME/SGSN and it may comprise of one or more SGW/PDN-GW/PCRF. This feature enables subscribers to be allocated to and served by a DCN based on subscription information ("UE Usage Type"). The feature in this clause handles both DCN selections without any specific UE functionality, i.e. it works also with UEs of earlier releases and UE assisted DCN selection. The main specific functions are for routing and maintaining UEs in their respective DCN. The following deployment scenarios are supported for DCN:

• DCNs may be deployed to support one RAT only, (e.g. only dedicated MMEs are deployed to support E-UTRAN and dedicated SGSNs are not deployed), to support multiple RATs, or to support all RATs.
• Networks deploying DCNs may have a default DCN, which is managing UEs for which a DCN is not available or if sufficient information is not available to assign a UE to a DCN. One or multiple DCNs may be deployed together with a default DCN that all share the same RAN.
• The architecture supports scenarios where the DCN is only deployed in a part of the PLMN e.g. only for one RAT or only in a part of the PLMN area. Such heterogeneous or partial deployment of DCNs may, depending on operator deployment and configuration, result in service with different characteristics or functionality, depending on whether the UE is inside or outside the service area or RAT that supports the DCN.
• Even if the DCN is not deployed to serve a particular RAT or service area of PLMN, the UE in that RAT or service area may still be served by a PDN-GW from the DCN.

High level overview for supporting DCNs is provided below. Details are captured in appropriate clauses of this specification, TS 23.060 and TS 23.236.

• An optional subscription information parameter ("UE Usage Type") is used in the selection of a DCN. An operator configures which of his DCN(s) serves which UE Usage Type(s). The HSS provides the "UE Usage Type" value in the subscription information of the UE to the MME/SGSN. Both standardized and operator specific values for UE Usage Type are possible.
• The serving network selects the DCN based on the operator configured (UE Usage Type to DCN) mapping, other locally configured operator's policies and the UE related context information available at the serving network, e.g. information about roaming. UEs with different UE Usage Type values may be served by the same DCN. Moreover, UEs that share the same UE Usage Type value may be served by different DCNs.
• If the configuration shows no DCN for the specific "UE Usage Type" value in the subscription information, then the serving MME/SGSN serves the UE by the default DCN or selects a DCN using serving operator specific policies.
• Some subscribers may be configured without "UE Usage Type" value. In this case, the MME/SGSN may select the DCN that serves the UE using locally configured operator's policies and the UE related context information available at the serving network (other than UE provided DCN-ID). The MME/SGSN performs procedures described in clauses 5.19.1 and 5.19.2.
• The "UE Usage Type" is associated with the UE (describing its usage characteristic), i.e. there is only one "UE Usage Type" per UE subscription.
• For each DCN, one or more CN nodes may be configured as part of a pool.
• For MME, the MMEGI(s) identifies a DCN within the PLMN. For SGSNs, a group identifier(s) identifies a DCN within the PLMN. That is, the group of SGSNs that belong to a DCN within a PLMN. This identifier may have the same format as NRI (e.g. an NRI value that does not identify a specific SGSN node in the serving area) in which case it is called "Null-NRI" or it may have a format independent of NRI, in which case it is called "SGSN Group ID". The "Null-NRI" or "SGSN Group ID" is provided by an SGSN to RAN which triggers the NNSF procedure to select an SGSN from the group of SGSNs corresponding to the Null-NRI/SGSN Group ID (see clause 5.19.1).
• The dedicated MME/SGSN that serves the UE selects a dedicated S-GW and P-GW based on UE Usage Type.
• At initial access to the network if sufficient information is not available for RAN to select a specific DCN, the RAN may selects a CN node from the default DCN. A redirection to another DCN may then be required.
• To redirect a UE from one DCN to a different DCN, the redirection procedure via RAN, described in clause 5.19.1, is used to forward the NAS message of the UE to the target DCN.
• All selection functions are aware of DCN(s), including the network node selection function (NNSF) of RAN nodes, for selecting and maintaining the appropriate DCN for the UEs.

This feature is to reduce the need for DECOR reroute by using an indication (DCN-ID) sent from the UE and used by RAN to select the correct DCN. The DCN-ID shall be assigned to the UE by the serving PLMN and is stored in the UE per PLMN ID. Both standardized and operator specific values for DCN-ID are possible. The UE shall use the PLMN specific DCN-ID whenever a PLMN specific DCN-ID is stored for the target PLMN. The HPLMN may provision the UE with a single default standardized DCN-ID which shall be used by the UE only if the UE has no PLMN specific DCN-ID of the target PLMN. When a UE configuration is changed with a new default standardized DCN-ID, the UE shall delete all stored PLMN specific DCN-IDs. The UE provides the DCN-ID to RAN at registration to a new location in the network, i.e. in Attach, TAU and RAU. RAN selects serving node (MME or SGSN) based on the DCN-ID provided by the UE and configuration in RAN. For E-UTRAN the eNodeB is configured with DCNs supported by the connected MMEs at the setup of the S1 connection. For UTRAN and GERAN the BSS/RNC is configured with the DCNs supported in the connected SGSN via O&M. Both standardized DCN-IDs and PLMN specific DCN-IDs can in the RAN configuration be assigned to the same network. If information provided by the UE (e.g. GUTI, NRI, etc.) indicates a node (MME or SGSN) for attach/TAU/RAU and a serving node (MME or SGSN) corresponding to the UE information can be found by the RAN node, the normal node selection shall take precedence over the selection based on DCN-ID. At registration the MME/SGSN may check if the correct DCN is selected. The check is performed as specified in clause 4.3.25.1. If the MME/SGSN concludes that the selected DCN is not the correct DCN, a DECOR reroute is performed and the SGSN/MME in the new DCN assigns a new DCN-ID to the UE. The serving MME/SGSN can also assign a new DCN-ID to the UE if e.g. the DCN-ID in the UE has become obsolete or when the UE Usage Type has been updated in the subscription information leading to a change of DCN. This is performed as part of the GUTI Reallocation procedure.

In the case of roaming, if the HPLMN of the visiting UE does not support DCNs, i.e. doesn't provide the UE Usage Type, the serving MME/SGSN may select the DCN that serves the UE using operator specific policies based on other subscription or UE provided information. In the case of roaming, if the HPLMN provides the UE Usage Type parameter to the VPLMN, this parameter is provided irrespective of its value (standardized or operator specific). The handling of the UE Usage Type parameter in the VPLMN is based on operator policies, e.g. roaming agreements. If the UE assisted DCN selection feature is supported:

• If the UE has a DCN-ID for the VPLMN the UE shall send that PLMN specific DCN-ID to the RAN, and
• If the UE has no PLMN specific DCN-ID for this VPLMN and if the UE has a pre-provisioned default standardized DCN-ID it shall send the pre-provisioned default standardized DCN-ID to the RAN.

If the network supports the MOCN configuration for network sharing (see TS 23.251), each network sharing operator has separate CN(s). Mechanisms for selection of serving operator for supporting and non-supporting UEs are defined in TS 23.251. Each of the sharing operators may deploy one or more DCNs. If Selected PLMN information is provided by the UE, the RAN selects the CN operator based on this provided information and then DECOR rerouting may, if needed, be initiated within the CN of the selected operator. If the UE assisted DCN selection feature is supported and both the Selected PLMN information and DCN-ID is provided by the UE, the RAN first selects the CN operator followed by selection of a DCN supported by the selected CN operator. If Selected PLMN information is not provided by the UE (may only happen in GERAN and UTRAN), the network initiates MOCN redirection, including CS/PS coordination, to select a CN operator that can serve the UE. After this, DECOR rerouting is initiated if needed. The serving node in the selected DCN ends the MOCN redirection. If the UE assisted DCN selection feature is supported and Selected PLMN information is not provided by the UE, the network initiates CN operator selection and after the CN operator selection is concluded the DCN is selected based on the UE provided DCN-ID. As the PLMN information included in the RAI is the Common PLMN (refer to TS 23.251), which does not reflect the selected CN operator, the network may also return the PLMN ID of the selected CN operator. When the UE receives the NAS Accept message, the UE associates the DCN-ID with both the PLMN ID of the selected CN operator and the Common PLMN IDs. The functions for redirecting or maintaining UEs in specific DCNs are configured to work within the CNs of the same operator.

Support of UEs in Enhanced Coverage is specified in TS 36.300. Whenever S1 is released and Information for Enhanced Coverage is available for the UE, the eNodeB sends it to the MME as described in clause 5.3.5. The MME stores the received Information for Enhanced Coverage and includes it in every subsequent Paging message for all eNodeBs selected by the MME for paging. If Enhanced Coverage is restricted for the UE as described in clause 4.3.28, the MME sends the Enhanced Coverage Restricted parameter as defined in TS 36.413.

This feature, when activated by the user, prevents transport via 3GPP access of all IP packets, Ethernet data and non-IP data except for those related to 3GPP PS Data Off Exempt Services. The 3GPP PS Data Off Exempt Services are a set of operator services, defined in TS 23.221, that are the only allowed services when the 3GPP PS Data Off feature has been activated by the user. UEs may be configured with up to two lists of 3GPP PS Data Off Exempt Services and the list(s) are provided to the UEs by HPLMN via Device Management or UICC provisioning. When the UE is configured with two lists, one list is valid for the UEs camping in the home PLMN and the other list is valid for any VPLMN the UE is roaming in. When the UE is configured with a single list, without an indication to which PLMNs the list is applicable, then this list is valid for the home PLMN and any PLMN the UE is roaming in. The UE discovers whether a PDN-GW supports 3GPP PS Data Off feature at initial attach and during the establishment of a PDN connection via the presence of the 3GPP PS Data Off Support Indication in the Create Session response message. The UE shall report its 3GPP PS Data Off status in PCO (Protocol Configuration Option) to PDN-GW during Initial Attach procedure as described in clause 5.3.2.1 and UE requested PDN connectivity procedure as described in clause 5.10.2. If 3GPP PS Data Off is activated, the UE prevents the sending of uplink IP packets, Ethernet data and non-IP data except for those related to 3GPP PS Data Off Exempt Services, based on the pre-configured list of Data Off Exempt Services. For those PDN-GWs that indicated support for the 3GPP PS Data Off feature during PDN connection setup and at Initial Attach, the UE shall report immediately a change of its 3GPP PS Data Off status in PCO by using Bearer Resource Modification procedure as described in clause 5.4.5, this also applies to the scenario of inter-RAT mobility procedure to E-UTRAN and also to scenarios where the 3GPP PS Data Off status is changed when the session management back-off timer is running as specified in clause 4.3.7.4.2. If the UE has not received any 3GPP PS Data Off Support Indication during the establishment of the PDN connection, it shall not report any change of its 3GPP PS Data Off Status for this PDN connection. The additional behaviour of the PDN-GW for 3GPP PS Data Off is controlled by local configuration or policy from the PCRF as defined in TS 23.203.

Integrated access and backhaul (IAB) enables wireless in-band and out-of-band relaying of NR Uu access traffic via NR Uu backhaul links. At high level, IAB has the following characteristics:

• IAB uses the CU/DU architecture defined in TS 38.401, and the IAB operation via F1 (between IAB-donor and IAB-node) is invisible to the EPC.
• IAB performs relaying at layer-2, and therefore does not require a local S/P-GW;
• IAB supports multi-hop backhauling;
• IAB supports dynamic topology update, i.e. the IAB-node can change the parent node, e.g. another IAB-node, or the IAB-donor, during operation, for example in response to backhaul link failure or blockage.

Figure 4.3.32.1-1 shows the IAB reference architecture with two backhaul hops, when connected to EPC, where both the IAB-node and the UE connect to the EPC with Dual Connectivity as defined in TS 37.340.

Each relay, referred to as IAB-node, consists of a gNB-DU function and a UE function (referred to as IAB-UE). The gNB-DU in the IAB-node is responsible for providing NR Uu access to UEs and child IAB-nodes. The corresponding gNB-CU function resides on the IAB-donor gNB (referred to as IAB-donor-CU), which controls IAB-node gNB-DU via the F1 interface. When a UE connects to EPC via an IAB-node, the gNB-DU of the IAB-node appears as a normal secondary gNB to the UE. When the IAB-UE of another IAB-node connects to EPC via the IAB-node, the gNB-DU of the IAB-node also appears as a secondary gNB to the IAB-UE. The IAB-UE function reuses UE procedures to connect to:

• the gNB-DU on a parent IAB-node or IAB-donor for access and backhauling;
• the gNB-CU on the IAB-donor via RRC for control of the access and backhaul link;
• EPC, e.g. MME,
• OAM system via a PDN connection (based on implementation).

In IAB operation, the IAB-UE interacts with the EPC using procedures defined for UE. The IAB-node gNB-DU only interacts with the IAB-donor-CU and follows the CU/DU design defined in TS 38.401. For the IAB-UE operation, the existing UE authentication methods as defined in TS 33.401 apply. For EPC, only USIM based methods are allowed. The following aspects of EPS are enhanced to support the IAB operation:

• the Attach procedure as defined in clause 5.3.2 is enhanced to indicate IAB-node's capability to the MME:
  • the IAB-node provides an IAB-indication to the eNodeB when the IAB-node establishes the RRC connection. If the IAB-indication is received, the eNodeB selects an MME that supports IAB, and includes the IAB-indication in the INITIAL UE MESSAGE so that the MME can perform IAB authorization;
• the UE Subscription data as defined in clause 5.7.1 is enhanced to include the authorization information for the IAB operation;
• Authorization procedure during the UE attach procedure is enhanced to perform verification of IAB subscription information;
• If the IAB operation is not authorized, the MME may reject the IAB-UE's attach request or detach the IAB-UE, or the MME may initiate UE Context setup/Modification procedure by providing IAB authorized indication with the value set to "not authorized" to the eNodeB, but the IAB-UE is in the EMM-REGISTERED state.
• If the IAB operation is authorized, UE Context setup/modification procedure is enhanced to provide IAB authorized indication with the value set to "authorized" to eNodeB and IAB-donor gNB.

After attached or registered, the IAB-node remains in ECM-CONNECTED state if the IAB operation is authorized. In the case of radio link failure, the IAB-UE uses existing UE procedure to restore the connection with the network. The IAB-UE uses the Detach procedure defined in clause 5.3.8 to disconnect from the network.

Control plane and user plane protocol stacks for IAB operation are defined in TS 38.300.

For UEs, all existing NR intra-RAT mobility and dual-connectivity procedures are supported with IAB. During UE mobility or dual-connectivity procedures, backhaul channels including IAB layer may be updated. This update is carried out by the IAB-donor-CU and signalled to the IAB-nodes via RRC and/or F1-C. The update is transparent to the UE.

IAB-donor has all the information regarding the UE and the IAB-node and corresponding mapping of the bearers. The PDN connection for the UE and IAB-node are separate from IAB-node onwards to the core network. Therefore, the existing charging mechanism as defined in clause 5.7A can be used to support IAB.

A network and a Multi-USIM UE may support one or more of the following features for Multi-USIM UE operation:

• Connection Release, as described in clause 4.3.33.2.
• Paging Cause Indication for Voice Service, as described in clause 4.3.33.3.
• Reject Paging Request, as described in clause 4.3.33.4.
• Paging Timing Collision Control, as described in clause 4.3.33.5.
• Paging Restriction, as described in clause 4.3.33.6.

In the Attach procedure (as specified in clause 5.3.2.1), or in the Tracking Area Update procedure (as specified clause 5.3.3), when a Multi-USIM UE has more than one USIM active, supports and intends to use one or more Multi-USIM specific features, it indicates to the MME the corresponding Multi-USIM feature(s) are supported. Based on the received indication of supported Multi-USIM features from the UE, the MME shall indicate to the UE the support of the Multi-USIM features based on the Multi-USIM features supported by network and any preference policy by the network, if available. When a UE returns to having only one USIM active from a Multi-USIM UE that previously indicated to the network it supported Multi-USIM feature(s), the UE shall indicate all the Multi-USIM features are not supported to the network for that USIM. The MME shall only indicate the support of Paging Restriction feature together with the support of either Connection Release feature or Reject Paging Request feature. The Multi-USIM UE includes the support of individual features for Connection Release, Paging Cause Indication for Voice Service, Reject Paging Request and Paging Restrictions as specified in clause 5.11.3. The network shall not indicate support for any Multi-USIM feature to the UE as part of the Emergency Attach procedure or as part of Tracking Area Update for Emergency attached UE. A Multi-USIM UE shall use a separate IMEI for each USIM when it registers with the network.

A Multi-USIM UE may request to be released to ECM-IDLE state for a USIM due to activity on another USIM if both the UE and the network indicate to each other the Connection Release feature is supported. A Multi-USIM UE indicates that it requests to be released to ECM-IDLE state for the USIM by initiating the Service Request procedure (using Extended Service Request message) or a Tracking Area Update procedure if the UE needs to perform Tracking Area Update at the same time with this network (including the case where the Tracking Area Update is performed due to mobility to a Tracking Area outside the current Tracking Area List, i.e. before detecting whether the network supports the feature in the new Tracking Area, provided that the network has already indicated support for Connection Release feature in the current Tracking Area List), by including a Release Request indication. If supported by the UE and network, the UE may also provide, together with the Release Request indication, Paging Restriction Information, as specified in clause 4.3.33.6, which requests the network to restrict paging.

A Multi-USIM UE and the network may support the Paging Cause Indication for Voice Service feature. The MME that supports Paging Cause Indication for Voice Service feature should provide a Voice Service Indication in the S1AP Paging message for the MMTel voice service, only if the UE indicates the Paging Cause Indication for Voice Service feature is supported. The MME determines the downlink data triggering the paging is related to a MMTel voice service based on the Paging Policy Indicator as specified in clause 4.9 for MMTel voice. Upon reception of the Voice Service Indication in S1AP Paging Message, an eNodeB that supports the Paging Cause Indication for Voice Service should include the Voice Service Indication the Uu Paging message to the UE. A UE that supports the Paging Cause Indication for Voice Service feature is capable of differentiation between Paging from a network that does not support the Paging Cause Indication for Voice Service feature and Uu Paging without the Voice Service Indication. How the UE distinguishes the Paging from a RAN that does not support the Paging Cause Indication for Voice Service feature and Paging without the Voice Service Indication is defined in TS 36.331. The UE determines whether the Paging Cause Indication for Voice Service feature is supported in the current Tracking Area by EPC based on the MUSIM capability exchange with the MME, see clause 4.3.33.1. The UE determines that the Paging Cause Indication for Voice Service feature is supported if it is supported by both the RAN, as indicated in the received Uu Paging message, and by EPC, as indicated in the MUSIM capability exchange with the MME. The UE uses the Paging Cause Indication for Voice Service as described in TS 24.301 and TS 36.331.

A Multi-USIM UE may respond to a page for a USIM with an indication to the MME that the UE does not accept the paging and requests to be released to ECM-IDLE state after sending this response, if both UE and network indicate to each other the Reject Paging Request feature is supported. Upon being paged, the Multi-USIM UE attempts to send an Extended Service Request message to the paging network including the Reject Paging Indication as the response to the paging, unless it is unable to do so, e.g. due to UE implementation constraints. In addition to the Reject Paging Indication, the UE may include Paging Restriction Information as specified in clause 4.3.33.6 in the Extended Service Request message, if the Paging Restrictions are supported by UE and network.

To avoid possible paging occasion collision and to enhance the likelihood that paging is received successfully for different USIMs, a Multi-USIM UE may provide, for at least one USIM, a Requested IMSI Offset value that is used for the determination of paging occasions. Upon reception of a Requested IMSI Offset value from UE in Attach Request or Tracking Area Update Request, a supporting MME provides an Accepted IMSI Offset value to the UE in the Attach Accept or Tracking Area Update Accept message to acknowledge it supports the feature and provide the accepted value. The Accepted IMSI Offset Value may be different from the Requested IMSI Offset provided by the UE. The Alternative IMSI value, determined as below, is stored in the UE context in the MME. If the UE does not provide any Requested IMSI Offset value in Attach Request or Tracking Area Request, the MME removes any stored Alternative IMSI value in the UE context. The UE and the network use the Accepted IMSI Offset to determine the paging occasion. The UE and MME use the Accepted IMSI Offset value to calculate the Alternative IMSI value that is determined based on UE's IMSI as follows: The MME uses the Alternative IMSI value to compute the UE Identity Index Value. The MME sends the UE Identity Index Value to RAN in the Paging message (see TS 36.413) for RAN to derive the paging occasions according to TS 36.304. The UE uses the Alternative IMSI value for the determination of paging occasions as specified in TS 36.304.

A Multi-USIM UE and the network may support Paging Restriction. A Multi-USIM UE, if the MME indicates that the network supports Paging Restriction feature, may indicate Paging Restriction Information in an Extended Service Request or a Tracking Area Update Request (including the case where the Tracking Area Update is performed due to mobility to a Tracking Area outside the current Tracking Area List, i.e. before detecting whether the network supports the feature in the new Tracking Area, provided that the network has already indicated support for Paging Restrictions in the current Tracking Area List), as specified in clauses 4.3.33.2 and 4.3.33.4. The MME may accept or reject the Paging Restriction Information requested by the UE. If the MME accepts the Paging Restriction Information from the UE, the MME stores the Paging Restriction Information from the UE in the UE context. If the MME rejects the Paging Restriction Information the MME removes any stored Paging Restriction Information from the UE context and discards the UEs requested Paging Restriction Information. The MME informs the UE about the acceptance/rejection of the requested Paging Restriction Information in the Tracking Area Update Accept or Service Accept message. If the UE does not provide Paging Restriction Information in the Extended Service Request message or the Tracking Area Update Request message, or if the UE initiates the Service Request procedure, the MME removes any stored Paging Restriction Information from the UE context. The Paging Restriction Information may indicate any of the following:

1. all paging is restricted, or
2. all paging is restricted, except paging for voice service (MMTel voice or CS domain voice), or
3. all paging is restricted, except for certain PDN Connection(s), or
4. all paging is restricted, except for certain PDN Connection(s) and voice service (MMTel voice or CS domain voice).