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 22.214.171.124. 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.
The Monitoring Events feature is intended for monitoring of specific events in 3GPP system and making such monitoring event information available via the Service Capability Exposure Function (SCEF). The architecture and related functions to support Monitoring Events are defined in TS 23.682.
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.
Support of UEs in Enhanced Coverage is specified in TS 36.300.
If the UE's usage setting is "voice centric" as defined in TS 23.221, it shall not operate in CE mode B.
If the UE supports CE mode B and UE's usage setting is set to "voice centric" in the Attach or TAU request message then the MME shall indicate to eNodeB that CE mode B is restricted. If the UE supports CE mode B and UE's usage setting is set to "data centric" in the Attach or TAU request message then, based on operator's policy and the Enhanced Coverage Restricted parameter (see clause 4.3.28), the MME shall indicate to eNodeB that CE mode B is not restricted.
The MME keeps the CE mode B Restricted parameter in the MM Context. The MME shall send the CE mode B Restricted parameter to the eNodeB via S1 signalling indicating whether the UE is "restricted" or "not restricted" for the use of CE mode B, e.g. in PAGING, INITIAL CONTEXT SETUP REQUEST, HANDOVER REQUEST, PATH SWITCH REQUEST ACKNOWLEDGE, CONNECTION ESTABLISHMENT INDICATION, and DOWNLINK NAS TRANSPORT message carrying the TAU ACCEPT message.
If the UE supports CE mode B and the CE mode B Restricted parameter stored in the MME's MM context is set to "not restricted", the MME shall use the extended NAS timer settings for the UE as specified in TS 24.301.
Support of UEs in Enhanced Coverage is specified in TS 36.300.
The usage of Enhanced Coverage may require use of extensive resources (e.g. radio and signalling resources) from the network. This feature enables the operator to prevent specific subscribers from using Enhanced Coverage.
The UE indicates its capability of support for restriction of use of Enhanced Coverage in Attach and TAU procedure for the RAT it is camping on to the MME. MME receives Enhanced Coverage Restricted parameter from the HSS. This parameter is kept as part of subscription data in the HSS and specifies per PLMN whether the enhanced coverage functionality is restricted or not for the UE. For roaming UEs, if HSS doesn't provide any Enhanced Coverage Restricted parameter or the provided Enhanced Coverage Restricted parameter is in conflict with the roaming agreement, the MME uses default Enhanced Coverage Restricted parameter locally configured in the VPLMN based on the roaming agreement with the subscriber's HPLMN. The UE shall assume that restriction for use of Enhanced Coverage is same in the equivalent PLMNs. If the UE includes the support for restriction of use of Enhanced Coverage, MME sends Enhanced Coverage Restricted parameter to the UE in the Attach/TAU Accept message. The UE shall use the value of Enhanced Coverage Restricted parameter to determine if enhanced coverage feature is restricted or not.
The UE assumes Enhanced Coverage is allowed unless explicitly restricted by the network for a PLMN. NB-IoT cells also broadcast the support of restriction of use of Enhanced Coverage as defined in TS 36.331).
If the MME has sent the Enhanced Coverage Restricted parameter to the UE, the MME provides an Enhanced Coverage Restricted parameter to the eNodeB via S1 signalling during paging, and whenever the UE context is established in RAN, e.g. during service request procedure, attach procedure, and TAU procedure.
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 126.96.36.199 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 188.8.131.52.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.
Unlicensed spectrum aggregation in EPS can use either LTE Licensed-Assisted Access (LAA) that is using the Carrier Aggregation (CA) RAN configuration defined in TS 36.300, or LWA/LWIP aggregation using WLAN or NR-U as secondary RAT that is using the Dual Connectivity architecture defined in clause 4.3.2a and TS 36.300.
If the UE has Access Restriction for Unlicensed Spectrum in the form of LAA, LWA/LWIP, or NR-U (either signalled from the HSS, or, locally generated by VPLMN policy in the MME) the MME signals this to the E-UTRAN as part of Handover Restriction List.
An eNodeB supporting aggregation with unlicensed spectrum in the form of LAA, LWA/LWIP, or NR-U checks whether the UE is allowed to use unlicensed spectrum. If the UE is not allowed to use Unlicensed Spectrum, the eNodeB shall not establish dual connectivity or carrier aggregation (CA) with LTE in unlicensed spectrum in the form of LAA, WLAN as a secondary RAT in the form of LWA/LWIP, or NR-U as a secondary RAT.
At inter-RAT handover from GERAN/UTRAN, the Access Restriction for Unlicensed Spectrum is either already in the MME's UE context, or is obtained from the HSS during the subsequent Tracking Area Update procedure (i.e. not from the source SGSN or source RAN). In both inter-RAT handover cases, any Access Restriction for use of Unlicensed Spectrum is then signalled to the E-UTRAN.
This clause describes subscription information handling in order to support operating Aerial UE function over E-UTRAN as defined in TS 36.300 and TS 36.331.
The eNodeB supporting Aerial UE function handling uses the per user information supplied by the MME to determine whether or not to allow the UE to use Aerial UE function.
Support of Aerial UE function is stored in the user's subscription information in HSS. HSS transfers this information to the MME via Update Location message during Attach and Tracking Area Update procedures. Home Operator may revoke user's subscription authorisation for operating Aerial UEs at any time.
MME that supports Aerial UE function provides the user's subscription information on Aerial UE authorisation to the eNodeB via the S1 AP Initial Context Setup Request during Attach, Tracking Area Update and Service Request procedures.
For the intra and inter MME S1 based handover (intra RAT) or Inter-RAT handover to E-UTRAN, the Aerial UE subscription information for the user is included in the S1-AP UE Context Modification Request message sent to the target eNodeB after the handover procedure.
For X2-based handover, the Aerial UE subscription information for the user is sent to target eNodeB as follows:
If the source eNodeB supports Aerial UE function and the user's Aerial UE subscription information is included in the UE context, the source eNodeB shall include the information in the X2-AP Handover Request message to the target eNodeB.
The MME shall send the Aerial UE subscription information to the target eNodeB in the Path Switch Request Acknowledge message.
If the Aerial UE subscription information has changed, the updated Aerial UE subscription information is included in the S1-AP UE Context Modification Request message sent to the eNodeB.
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 184.108.40.206-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;
UE Context setup/modification procedure is enhanced to provide IAB authorized indication to eNodeB and IAB-donor gNB.
After attached or registered, the IAB-node remains in ECM-CONNECTED state. 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.
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.
In the Attach procedure (as specified in clause 220.127.116.11), 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 18.104.22.168, 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 22.214.171.124. 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 126.96.36.199 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:
Alternative IMSI value = [MCC] [MNC] [(MSIN value + Accepted IMSI Offset) mod (MSIN address space)]
where: the MCC, MNC and MSIN value are the fields of the UE's IMSI as defined in TS 23.003.
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 188.8.131.52 and 184.108.40.206.
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:
all paging is restricted, or
all paging is restricted, except paging for voice service (MMTel voice or CS domain voice), or
all paging is restricted, except for certain PDN Connection(s), or
all paging is restricted, except for certain PDN Connection(s) and voice service (MMTel voice or CS domain voice).