During a registration procedure with 5GS registration type IE set to "emergency registration", the AMF shall not check for mobility and access restrictions, regional restrictions or subscription restrictions, or CAG restrictions when processing the REGISTRATION REQUEST message.
If the initial registration request is accepted by the network, the AMF shall send a REGISTRATION ACCEPT message to the UE.
For each of the information elements: 5GMM capability, S1 UE network capability, and UE security capability, the AMF shall store all octets received from the UE in the REGISTRATION REQUEST message, up to the maximum length defined for the respective information element.
The AMF shall assign and include a TAI list as a registration area the UE is registered to in the REGISTRATION ACCEPT message. The AMF shall not assign a TAI list containing both tracking areas in NB-N1 mode and tracking areas not in NB-N1 mode. The UE, upon receiving a REGISTRATION ACCEPT message, shall delete its old TAI list and store the received TAI list. If the REGISTRATION REQUEST message was received over non-3GPP access, the AMF shall include a single TAI in the TAI list.
The AMF may include service area restrictions in the Service area list IE in the REGISTRATION ACCEPT message. The UE, upon receiving a REGISTRATION ACCEPT message with the service area restrictions shall act as described in subclause 5.3.5.
The AMF may also include a list of equivalent PLMNs in the REGISTRATION ACCEPT message. Each entry in the list contains a PLMN code (MCC+MNC). The UE shall store the list as provided by the network, and if the initial registration procedure is not for emergency services, the UE shall remove from the list any PLMN code that is already in the forbidden PLMN list as specified in subclause 5.3.13A. In addition, the UE shall add to the stored list the PLMN code of the registered PLMN that sent the list. The UE shall replace the stored list on each receipt of the REGISTRATION ACCEPT message. If the REGISTRATION ACCEPT message does not contain a list, then the UE shall delete the stored list. The AMF of a PLMN shall not include a list of equivalent SNPNs.
If the ESI bit of the 5GMM capability IE of the REGISTRATION REQUEST message is set to "equivalent SNPNs supported", the AMF of a SNPN may include a list of equivalent SNPNs in the REGISTRATION ACCEPT message. If the initial registration request is for onboarding services in SNPN, the AMF shall not include a list of equivalent SNPNs in the REGISTRATION ACCEPT message. Each entry in the list contains an SNPN identity. The UE shall store the list as provided by the network. If the initial registration procedure is not for emergency services and is not the initial registration for onboarding services in SNPN, the UE shall remove from the list any SNPN identity that is already in:
the "permanently forbidden SNPNs" list or the "temporarily forbidden SNPNs" list, if the SNPN is not an SNPN selected for localized services in SNPN (see TS 23.122); or
the "permanently forbidden SNPNs for access for localized services in SNPN" list or the "temporarily forbidden SNPNs for access for localized services in SNPN" list, if the SNPN is an SNPN selected for localized services in SNPN (see TS 23.122).
The UE shall add to the stored list the SNPN identity of the registered SNPN that sent the list. The UE shall replace the stored list on each receipt of the REGISTRATION ACCEPT message. If the REGISTRATION ACCEPT message does not contain a list, then the UE shall delete the stored list. The AMF of an SNPN shall not include a list of equivalent PLMNs.
If the initial registration procedure is not for emergency services, the UE is not registered for disaster roaming services, and if the PLMN identity of the registered PLMN is a member of the forbidden PLMN list as specified in subclause 5.3.13A, any such PLMN identity shall be deleted from the corresponding list(s).
If the Service area list IE is not included in the REGISTRATION ACCEPT message, any tracking area in the registered PLMN and its equivalent PLMN(s) in the registration area, or in the registered SNPN, is considered as an allowed tracking area as described in subclause 5.3.5.
If the REGISTRATION REQUEST message contains the LADN indication IE, based on the LADN indication IE, UE subscription information, UE location and local configuration about LADN and:
if the LADN indication IE includes requested LADN DNNs, the UE subscribed DNN list includes the requested LADN DNNs or the wildcard DNN, and the LADN service area of the requested LADN DNN has an intersection with the current registration area, the AMF shall determine the requested LADN DNNs included in the LADN indication IE as LADN DNNs for the UE;
if no requested LADN DNNs included in the LADN indication IE and the wildcard DNN is included in the UE subscribed DNN list, the AMF shall determine the LADN DNN(s) configured in the AMF whose LADN service area has an intersection with the current registration area as LADN DNNs for the UE; or
if no requested LADN DNNs included in the LADN indication IE and the wildcard DNN is not included in the UE subscribed DNN list, or if the UE subscribed DNN list does not include any of the DNN's in the LADN indication IE, the AMF shall determine the LADN DNN(s) included in the UE subscribed DNN list whose LADN service area has an intersection with the current registration area as LADN DNNs for the UE.
If the LADN indication IE is not included in the REGISTRATION REQUEST message, the AMF shall determine the LADN DNN(s) included in the UE subscribed DNN list whose service area has an intersection with the current registration area as LADN DNNs for the UE, except for the wildcard DNN included in the UE subscribed DNN list.
If the UE supports WUS assistance information and the AMF supports and accepts the use of WUS assistance information for the UE, then the AMF shall determine the negotiated UE paging probability information for the UE, store it in the 5GMM context of the UE, and if the UE is not performing the initial registration for emergency services, the AMF shall include it in the Negotiated WUS assistance information IE in the REGISTRATION ACCEPT message. The AMF may consider the UE paging probability information received in the Requested WUS assistance information IE when determining the negotiated UE paging probability information for the UE.
If the UE sets the NR-PSSI bit to "NR paging subgrouping supported" in the 5GMM capability IE in the REGISTRATION REQUEST message and the AMF supports and accepts the use of PEIPS assistance information for the UE, then the AMF shall determine the Paging subgroup ID for the UE, store it in the 5GMM context of the UE, and shall include it in the Negotiated PEIPS assistance information IE in the REGISTRATION ACCEPT message or in the Updated PEIPS assistance information IE in the CONFIGURATION UPDATE COMMAND message as part of the registration procedure. The AMF may consider the UE paging probability information received in the Requested PEIPS assistance information IE when determining the Paging subgroup ID for the UE.
If the UE set the UN-PER bit to "unavailability period supported" in the 5GMM capability IE in the REGISTRATION REQUEST message and the AMF supports and accepts the use of unavailability period for the UE, then the AMF shall set the UN-PER bit to "unavailability period supported" in the 5GS network feature support IE in the REGISTRATION ACCEPT message. Furthermore, if the AMF is able to determine an unavailability period duration for the UE based on satellite coverage availability information (see TS 23.401), the AMF shall store the determined unavailability period duration and provide the determined unavailability period duration to the UE by including the unavailability period duration in the Unavailability configuration IE in the REGISTRATION ACCEPT message. If the AMF is able to determine the start of unavailability period based on satellite coverage availability information (see TS 23.401), the AMF shall store the determined start of unavailability period and provide the determined start of unavailability period to the UE by including the start of unavailability period in the Unavailability configuration IE in the REGISTRATION ACCEPT message. The AMF may determine the periodic registration update timer value based on the network determined unavailability period duration, a network determined start of the unavailability period or a discontinuous coverage maximum time offset value or any combination of them.
The AMF shall include the LADN information which consists of the determined LADN DNNs for the UE and LADN service area(s) available in the current registration area in the LADN information IE of the REGISTRATION ACCEPT message.
If the UE has set the LADN-DS bit to "LADN per DNN and S-NSSAI supported" in the 5GMM capability IE of the REGISTRATION REQUEST message and the extended LADN information is available for the UE, the AMF shall include the extended LADN information which consists of the determined LADN DNNs for the UE, the S-NSSAIs associated with the determined LADN DNNs for the UE and in the allowed NSSAI or partially allowed NSSAI, and LADN service area(s) available in the current registration area in the Extended LADN information IE in the Registration accept type 6 IE container IE of the REGISTRATION ACCEPT message.
If:
the UE does not support LADN per DNN and S-NSSAI;
the UE is subscribed to the LADN DNN for a single S-NSSAI only; and
the AMF has the extended LADN information but no LADN information;
the AMF may decide to provide the LADN service area for that LADN DNN of the extended LADN information as the LADN information and include the LADN information in the LADN information IE of the REGISTRATION ACCEPT message.
If the UE does not support LADN per DNN and S-NSSAI and the AMF has neither the LADN information nor the extended LADN information, the AMF shall not provide any LADN information to the UE.
The UE, upon receiving the REGISTRATION ACCEPT message with the LADN information, shall store the received LADN information. The UE, upon receiving the REGISTRATION ACCEPT message with the Extended LADN information in the Registration accept type 6 IE container IE, shall store the received extended LADN information. If there exists one or more LADN DNNs which are included in the LADN indication IE of the REGISTRATION REQUEST message and are not included in the LADN information IE and Extended LADN information IE in the Registration accept type 6 IE container IE of the REGISTRATION ACCEPT message, the UE considers such LADN DNNs as not available in the current registration area.
The 5G-GUTI reallocation shall be part of the initial registration procedure. During the initial registration procedure, if the AMF has not allocated a new 5G-GUTI by the generic UE configuration update procedure, the AMF shall include in the REGISTRATION ACCEPT message the new assigned 5G-GUTI together with the assigned TAI list.
If the UE has set the CAG bit to "CAG supported" in the 5GMM capability IE of the REGISTRATION REQUEST message and the AMF needs to update the "CAG information list" stored in the UE, the AMF shall include the CAG information list IE or the Extended CAG information list IE in the REGISTRATION ACCEPT message.
If the UE does not support extended CAG information list, the CAG information list shall not be included in the Extended CAG information list IE.
If a 5G-GUTI or the SOR transparent container IE is included in the REGISTRATION ACCEPT message, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
If the Operator-defined access category definitions IE, the Extended emergency number list IE, the CAG information list IE or the Extended CAG information list IE are included in the REGISTRATION ACCEPT message, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
If the UE has set the RCMAP bit to "Sending of REGISTRATION COMPLETE message for negotiated PEIPS assistance information supported" in the 5GMM capability IE of the REGISTRATION REQUEST message and if the Negotiated PEIPS assistance information IE is included in the REGISTRATION ACCEPT message, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
If the UE is not in NB-N1 mode and the UE has set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message, the AMF may include either a UE radio capability ID IE or a UE radio capability ID deletion indication IE in the REGISTRATION ACCEPT message. If the UE radio capability ID IE or the UE radio capability ID deletion indication IE is included in the REGISTRATION ACCEPT message, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
The AMF shall include the MICO indication IE in the REGISTRATION ACCEPT message only if the MICO indication IE was included in the REGISTRATION REQUEST message, the AMF supports and accepts the use of MICO mode. If the AMF supports and accepts the use of MICO mode, the AMF may indicate "all PLMN registration area allocated" in the MICO indication IE in the REGISTRATION ACCEPT message. If "all PLMN registration area allocated" is indicated in the MICO indication IE, the AMF shall not assign and include the TAI list in the REGISTRATION ACCEPT message. If the REGISTRATION ACCEPT message included an MICO indication IE indicating "all PLMN registration area allocated", the UE shall treat all TAIs in the current PLMN as a registration area and delete its old TAI list. If "strictly periodic registration timer supported" is indicated in the MICO indication IE in the REGISTRATION REQUEST message, the AMF may indicate "strictly periodic registration timer supported" in the MICO indication IE in the REGISTRATION ACCEPT message.
The AMF shall include an active time value in the T3324 IE in the REGISTRATION ACCEPT message if the UE requested an active time value in the REGISTRATION REQUEST message and the AMF accepts the use of MICO mode and the use of active time.
If the AMF supports and accepts the use of MICO, and the UE included the Requested T3512 value IE in the REGISTRATION REQUEST message, then the AMF shall take into account the T3512 value requested when providing the T3512 value IE in the REGISTRATION ACCEPT message.
The AMF shall include the T3512 value IE in the REGISTRATION ACCEPT message only if the REGISTRATION REQUEST message was sent over the 3GPP access.
The AMF shall include the non-3GPP de-registration timer value IE in the REGISTRATION ACCEPT message only if the REGISTRATION REQUEST message was sent over the non-3GPP access.
If the UE requests "control plane CIoT 5GS optimization" in the 5GS update type IE, indicates support of control plane CIoT 5GS optimization in the 5GMM capability IE and the AMF decides to accept the requested CIoT 5GS optimization and the registration request, the AMF shall indicate "control plane CIoT 5GS optimization supported" in the 5GS network feature support IE of the REGISTRATION ACCEPT message.
The AMF may include the T3447 value IE set to the service gap time value in the REGISTRATION ACCEPT message if:
the UE has indicated support for service gap control in the REGISTRATION REQUEST message; and
a service gap time value is available in the 5GMM context.
If there is a running T3447 timer in the AMF and the Follow-on request indicator is set to "Follow-on request pending" in the REGISTRATION REQUEST message, the AMF shall ignore the flag and proceed as if the flag was not received except for the following cases:
the UE is configured for high priority access in the selected PLMN; or
the 5GS registration type IE in the REGISTRATION REQUEST message is set to "emergency registration".
If the UE has indicated support for the control plane CIoT 5GS optimizations, and the AMF decides to activate the congestion control for transport of user data via the control plane, then the AMF shall include the T3448 value IE in the REGISTRATION ACCEPT message.
If:
the UE in NB-N1 mode is using control plane CIoT 5GS optimization; and
the network is configured to provide the truncated 5G-S-TMSI configuration for control plane CIoT 5GS optimizations;
the AMF shall include the Truncated 5G-S-TMSI configuration IE in the REGISTRATION ACCEPT message and set the "Truncated AMF Set ID value" and the "Truncated AMF Pointer value" in the Truncated 5G-S-TMSI configuration IE based on network policies. The AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
If the UE has included the service-level device ID set to the CAA-level UAV ID in the Service-level-AA container IE of the REGISTRATION REQUEST message, and if:
the UE has a valid aerial UE subscription information;
the UUAA procedure is to be performed during the registration procedure according to operator policy;
there is no valid successful UUAA result for the UE in the UE 5GMM context; and
the REGISTRATION REQUEST message was not received over non-3GPP access,
then the AMF shall initiate the UUAA-MM procedure with the UAS-NF as specified in TS 23.256 and shall include a service-level-AA pending indication in the Service-level-AA container IE of the REGISTRATION ACCEPT message. The AMF shall store in the UE 5GMM context that a UUAA procedure is pending. The AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3. If the REGISTRATION REQUEST message was received over non-3GPP access, the AMF shall not initiate UUAA-MM procedure.
If the UE has included the service-level device ID set to the CAA-level UAV ID in the Service-level-AA container IE of the REGISTRATION REQUEST message, and if:
the UE has a valid aerial UE subscription information;
the UUAA procedure is to be performed during the registration procedure according to operator policy; and
there is a valid successful UUAA result for the UE in the UE 5GMM context,
then the AMF shall include a service-level-AA response in the Service-level-AA container IE of the REGISTRATION ACCEPT message and set the SLAR field in the service-level-AA response to "Service level authentication and authorization was successful".
If the AMF determines that the UUAA-MM procedure needs to be performed for a UE, the AMF has not received the service-level device ID set to the CAA-level UAV ID in the Service-level-AA container IE of the REGISTRATION REQUEST message from the UE and the AMF decides to accept the UE to be registered for other services than UAS services based on the user's subscription data and the operator policy, the AMF shall accept the initial registration request and shall mark in the UE's 5GMM context that the UE is not allowed to request UAS services.
If the UE supports MINT, the AMF may include the List of PLMNs to be used in disaster condition IE in the REGISTRATION ACCEPT message.
If the UE supports MINT, the AMF may include the Disaster roaming wait range IE in the REGISTRATION ACCEPT message.
If the UE supports MINT, the AMF may include the Disaster return wait range IE in the REGISTRATION ACCEPT message.
If the AMF received the list of TAIs from the satellite NG-RAN as described in TS 23.501, and determines that, by UE subscription and operator's preferences, any but not all TAIs in the received list of TAIs is forbidden for roaming or for regional provision of service, the AMF shall include the TAI(s) in:
the Forbidden TAI(s) for the list of "5GS forbidden tracking areas for roaming" IE; or
the Forbidden TAI(s) for the list of "5GS forbidden tracking areas for regional provision of service" IE; or
both;
in the REGISTRATION ACCEPT message.
If the UE has set the Reconnection to the network due to RAN timing synchronization status change (RANtiming) bit to "Reconnection to the network due to RAN timing synchronization status change supported" in the 5GMM capability IE of the REGISTRATION REQUEST message, the AMF may include the RAN timing synchronization IE with the RecReq bit set to "Reconnection requested" in the REGISTRATION ACCEPT message.
If the AMF receives the initial registration request along with the mobile IAB-indication over N2 reference point (see TS 38.413) from UE and the UE is authorized to operate as an MBSR based on the subscription information and local policy (see TS 23.501), the AMF shall include the Feature authorization indication IE in the REGISTRATION ACCEPT message and shall set the MBSRAI field to "authorized to operate as MBSR". If the AMF receives the initial registration request along with the mobile IAB-indication over N2 reference point (see TS 38.413) from UE and the UE is not authorized to operate as an MBSR based on the subscription information and local policy but can operate as a UE, the AMF shall include the Feature authorization indication IE in the REGISTRATION ACCEPT message and shall set the MBSRAI field to "not authorized to operate as MBSR but allowed to operate as a UE".
If the UE supports user plane positioning using LCS-UPP, SUPL, or both, the AMF shall set the LCS-UPP bit, the SUPL bit, or both in the 5GS network feature support IE of the REGISTRATION ACCEPT message as specified in TS 24.572.
Upon receipt of the REGISTRATION ACCEPT message, the UE shall reset the registration attempt counter, enter state 5GMM-REGISTERED and set the 5GS update status to 5U1 UPDATED.
If the UE receives the REGISTRATION ACCEPT message from a PLMN, then the UE shall reset the PLMN-specific attempt counter for that PLMN for the specific access type for which the message was received. The UE shall also reset the PLMN-specific N1 mode attempt counter for that PLMN for the specific access type for which the message was received. If the message was received via 3GPP access, the UE shall reset the counter for "SIM/USIM considered invalid for GPRS services" events and the counter for "SIM/USIM considered invalid for non-GPRS services" events, if any. If the message was received via non-3GPP access, the UE shall reset the counter for "USIM considered invalid for 5GS services over non-3GPP" events.
If the UE receives the REGISTRATION ACCEPT message from an SNPN, then the UE shall reset the SNPN-specific attempt counter for the current SNPN for the specific access type for which the message was received. If the message was received via 3GPP access, the UE shall reset the counter for "the entry for the current SNPN considered invalid for 3GPP access" events. If the message was received via non-3GPP access, the UE shall reset the counter for "the entry for the current SNPN considered invalid for non-3GPP access" events.
If the REGISTRATION ACCEPT message included a T3512 value IE, the UE shall use the value in the T3512 value IE as periodic registration update timer (T3512).
If the REGISTRATION ACCEPT message include a T3324 value IE, the UE shall use the value in the T3324 value IE as active timer (T3324).
If the REGISTRATION ACCEPT message included a non-3GPP de-registration timer value IE, the UE shall use the value in non-3GPP de-registration timer value IE as non-3GPP de-registration timer.
If the REGISTRATION ACCEPT message contains
the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed";
a Configured NSSAI IE with a new configured NSSAI for the current PLMN or SNPN and optionally the mapped S-NSSAI(s) for the configured NSSAI for the current PLMN or SNPN;
an NSSRG information IE with a new NSSRG information;
an Alternative NSSAI IE with a new alternative NSSAI;
an S-NSSAI location validity information in the Registration accept type 6 IE container IE with a new S-NSSAI location validity information;
an S-NSSAI time validity information IE with a new S-NSSAI time validity information; or
an On-demand NSSAI IE with a new on-demand NSSAI or an updated slice deregistration inactivity timer value,
the UE shall return a REGISTRATION COMPLETE message to the AMF to acknowledge the successful update of the network slicing information. If the UE has set the RCMAN bit to "Sending of REGISTRATION COMPLETE message for NSAG information supported" in the 5GMM capability IE of the REGISTRATION REQUEST message and if REGISTRATION ACCEPT message contains the NSAG information IE, the UE shall return REGISTRATION COMPLETE message to the AMF to acknowledge the reception of the NSAG information IE.
If the REGISTRATION ACCEPT message contains the CAG information list IE or the Extended CAG information list IE and the UE had set the CAG bit to "CAG supported" in the 5GMM capability IE of the REGISTRATION REQUEST message, the UE shall:
replace the "CAG information list" stored in the UE with the received CAG information list IE or the Extended CAG information list IE when received in the HPLMN or EHPLMN;
replace the serving VPLMN's entry of the "CAG information list" stored in the UE with the serving VPLMN's entry of the received CAG information list IE or the Extended CAG information list IE when the UE receives the CAG information list IE or the Extended CAG information list IE in a serving PLMN other than the HPLMN or EHPLMN; or
remove the serving VPLMN's entry of the "CAG information list" stored in the UE when the UE receives the CAG information list IE or the Extended CAG information list IE in a serving PLMN other than the HPLMN or EHPLMN and the CAG information list IE or the Extended CAG information list IE does not contain the serving VPLMN's entry.
The UE shall store the "CAG information list" received in the CAG information list IE or the Extended CAG information list IE as specified in Annex C.
If the received "CAG information list" includes an entry containing the identity of the registered PLMN, the UE shall operate as follows:
if the UE receives the REGISTRATION ACCEPT message via a CAG cell, none of the CAG-ID(s) supported by the current CAG cell is authorized based on the "Allowed CAG list" of the entry for the registered PLMN in the received "CAG information list", and:
the entry for the registered PLMN in the received "CAG information list" does not include an "indication that the UE is only allowed to access 5GS via CAG cells", then the UE shall enter the state 5GMM-REGISTERED.LIMITED-SERVICE and shall search for a suitable cell according to TS 38.304 or TS 36.304 with the updated "CAG information list"; or
the entry for the registered PLMN in the received "CAG information list" includes an "indication that the UE is only allowed to access 5GS via CAG cells" and:
if one or more CAG-ID(s) are authorized based on the "Allowed CAG list" of the entry for the registered PLMN in the received "CAG information list", the UE shall enter the state 5GMM-REGISTERED.LIMITED-SERVICE and shall search for a suitable cell according to TS 38.304 with the updated "CAG information list"; or
if no CAG-ID is authorized based on the "Allowed CAG list" of the entry for the registered PLMN in the received "CAG information list", the UE has not set the 5GS registration type IE in the REGISTRATION REQUEST message to "emergency registration", and the initial registration was not initiated to perform handover of an existing emergency PDU session from the non-current access to the current access, then the UE shall enter the state 5GMM-REGISTERED.PLMN-SEARCH and shall apply the PLMN selection process defined in TS 23.122 with the updated "CAG information list"; or
if the UE receives the REGISTRATION ACCEPT message via a non-CAG cell and the entry for the registered PLMN in the received "CAG information list" includes an "indication that the UE is only allowed to access 5GS via CAG cells" and:
if one or more CAG-ID(s) are authorized based on the "allowed CAG list" for the registered PLMN in the received "CAG information list", the UE shall enter the state 5GMM-REGISTERED.LIMITED-SERVICE and shall search for a suitable cell according to TS 38.304 with the updated "CAG information list"; or
if no CAG-ID is authorized based on the "Allowed CAG list" of the entry for the registered PLMN in the received "CAG information list", the UE has not set the 5GS registration type IE in the REGISTRATION REQUEST message to "emergency registration", and the initial registration was not initiated to perform handover of an existing emergency PDU session from the non-current access to the current access, then the UE shall enter the state 5GMM-REGISTERED.PLMN-SEARCH and shall apply the PLMN selection process defined in TS 23.122 with the updated "CAG information list".
If the received "CAG information list" does not include an entry containing the identity of the registered PLMN and the UE receives the REGISTRATION ACCEPT message via a CAG cell, the UE shall enter the state 5GMM-REGISTERED.LIMITED-SERVICE and shall search for a suitable cell according to TS 38.304 or TS 36.304 with the updated "CAG information list".
If the REGISTRATION ACCEPT message contains the Operator-defined access category definitions IE, the Extended emergency number list IE ,the CAG information list IE or the Extended CAG information list IE, the UE shall return a REGISTRATION COMPLETE message to the AMF to acknowledge reception of the operator-defined access category definitions, the extended local emergency numbers list or the "CAG information list".
If the UE has set the RCMAP bit to "Sending of REGISTRATION COMPLETE message for negotiated PEIPS parameters supported" in the 5GMM capability IE of the REGISTRATION REQUEST message and if REGISTRATION ACCEPT message contains the Negotiated PEIPS assistance information IE, the UE shall return REGISTRATION COMPLETE message to the AMF to acknowledge the reception of the Negotiated PEIPS assistance information IE.
If the REGISTRATION ACCEPT message contains the UE radio capability ID IE or the UE radio capability ID deletion indication IE, the UE shall return a REGISTRATION COMPLETE message to the AMF to acknowledge reception of the UE radio capability ID IE or the UE radio capability ID deletion indication IE.
Upon receiving a REGISTRATION COMPLETE message, the AMF shall stop timer T3550 and change to state 5GMM-REGISTERED. The 5G-GUTI, if sent in the REGISTRATION ACCEPT message, shall be considered as valid, the PEIPS assistance information, if sent in the REGISTRATION ACCEPT message, shall be considered as valid, and the UE radio capability ID, if sent in the REGISTRATION ACCEPT, shall be considered as valid.
If the 5GS update type IE was included in the REGISTRATION REQUEST message with the SMS requested bit set to "SMS over NAS supported", and SMSF selection is successful, then the AMF shall send the REGISTRATION ACCEPT message after the SMSF has confirmed that the activation of the SMS service was successful. When sending the REGISTRATION ACCEPT message, the AMF shall:
set the SMS allowed bit of the 5GS registration result IE to "SMS over NAS allowed" in the REGISTRATION ACCEPT message, if the UE has set the SMS requested bit of the 5GS update type IE to "SMS over NAS supported" in the REGISTRATION REQUEST message and the network allows the use of SMS over NAS for the UE; and
store the SMSF address and the value of the SMS allowed bit of the 5GS registration result IE in the UE 5GMM context and consider the UE available for SMS over NAS.
If:
the SMSF selection in the AMF is not successful;
the SMS activation via the SMSF is not successful;
the AMF does not allow the use of SMS over NAS;
the SMS requested bit of the 5GS update type IE was set to "SMS over NAS not supported" in the REGISTRATION REQUEST message; or
the 5GS update type IE was not included in the REGISTRATION REQUEST message;
then the AMF shall set the SMS allowed bit of the 5GS registration result IE to "SMS over NAS not allowed" in the REGISTRATION ACCEPT message.
When the UE receives the REGISTRATION ACCEPT message, if the UE is also registered over another access to the same PLMN, the UE considers the value indicated by the SMS allowed bit of the 5GS registration result IE as applicable for both accesses over which the UE is registered.
The AMF shall include the 5GS registration result IE in the REGISTRATION ACCEPT message. If the 5GS registration result value in the 5GS registration result IE indicates:
"3GPP access", the UE:
shall consider itself as being registered to 3GPP access; and
if in 5GMM-REGISTERED state over non-3GPP access and on the same PLMN or SNPN as 3GPP access, shall enter state 5GMM-DEREGISTERED.ATTEMPTING-REGISTRATION over non-3GPP access and set the 5GS update status to 5U2 NOT UPDATED over non-3GPP access; or
"Non-3GPP access", the UE:
shall consider itself as being registered to non-3GPP access; and
if in the 5GMM-REGISTERED state over 3GPP access and is on the same PLMN or SNPN as non-3GPP access, shall enter the state 5GMM-DEREGISTERED.ATTEMPTING-REGISTRATION over 3GPP access and set the 5GS update status to 5U2 NOT UPDATED over 3GPP access; or
"3GPP access and non-3GPP access", the UE shall consider itself as being registered to both 3GPP access and non-3GPP access.
In roaming scenarios, the AMF shall provide mapped S-NSSAI(s) for the configured NSSAI, the allowed NSSAI, the partially allowed NSSAI, the rejected NSSAI (if Extended rejected NSSAI IE is used) , the partially rejected NSSAI, the pending NSSAI or NSSRG information when included in the REGISTRATION ACCEPT message.
The AMF shall include the allowed NSSAI for the current PLMN or SNPN and shall include the mapped S-NSSAI(s) for the allowed NSSAI contained in the requested NSSAI from the UE if available, in the REGISTRATION ACCEPT message if the UE included the requested NSSAI in the REGISTRATION REQUEST message and the AMF allows one or more S-NSSAIs in the requested NSSAI. Additionally, if the AMF allows one or more subscribed S-NSSAIs for the UE, the AMF may include the allowed subscribed S-NSSAI(s) in the allowed NSSAI in the REGISTRATION ACCEPT message.
The AMF may also include rejected NSSAI in the REGISTRATION ACCEPT message if the initial registration request is not for onboarding services in SNPN. If the UE has set the ER-NSSAI bit to "Extended rejected NSSAI supported" in the 5GMM capability IE of the REGISTRATION REQUEST message, the rejected NSSAI shall be included in the Extended rejected NSSAI IE in the REGISTRATION ACCEPT message; otherwise the rejected NSSAI shall be included in the Rejected NSSAI IE in the REGISTRATION ACCEPT message. If the initial registration request is for onboarding services in SNPN, the AMF shall not include rejected NSSAI in the REGISTRATION ACCEPT message.
If the UE has indicated the support for partial network slice and the AMF determines one or more S-NSSAI(s) in the requested NSSAI are to be included in the partially rejected NSSAI as specified in subclause 4.6.2.11, the AMF shall include the Partially rejected NSSAI IE in the Registration accept type 6 IE container IE of the REGISTRATION ACCEPT message.
If the UE receives the Partially rejected NSSAI IE in the Registration accept type 6 IE container IE of the REGISTRATION ACCEPT message, the UE shall store the partially rejected NSSAI as specified in subclause 4.6.2.2.
If the UE has set the ER-NSSAI bit to "Extended rejected NSSAI supported" in the 5GMM capability IE of the REGISTRATION REQUEST message, the rejected NSSAI contains S-NSSAI(s) which was included in the requested NSSAI but rejected by the network associated with rejection cause(s); otherwise the rejected NSSAI contains S-NSSAI(s) which was included in the requested NSSAI but rejected by the network associated with rejection cause(s) with the following restrictions:
rejected NSSAI for the current PLMN or SNPN shall not include an S-NSSAI for the current PLMN or SNPN which is associated to multiple mapped S-NSSAIs and some of these but not all mapped S-NSSAIs are not allowed; and
rejected NSSAI for the current registration area shall not include an S-NSSAI for the current PLMN or SNPN which is associated to multiple mapped S-NSSAIs and some of these but not all mapped S-NSSAIs are not allowed.
If the UE indicated the support for network slice-specific authentication and authorization, and if the Requested NSSAI IE includes one or more S-NSSAIs subject to network slice-specific authentication and authorization, the AMF shall in the REGISTRATION ACCEPT message include:
a)
the allowed NSSAI containing the S-NSSAI(s) or the mapped S-NSSAI(s), if any:
which are not subject to network slice-specific authentication and authorization and are allowed by the AMF; or
for which the network slice-specific authentication and authorization has been successfully performed;
aa)
the partially allowed NSSAI containing the S-NSSAI(s) or the mapped S-NSSAI(s), if any:
which are not subject to network slice-specific authentication and authorization and are allowed by the AMF; or
for which the network slice-specific authentication and authorization has been successfully performed;
b)
optionally, the rejected NSSAI;
ba)
optionally, the partially rejected NSSAI;
c)
pending NSSAI containing one or more S-NSSAIs for which network slice-specific authentication and authorization (except for re-NSSAA) will be performed or is ongoing, and one or more S-NSSAIs from the pending NSSAI which the AMF provided to the UE during the previous registration procedure for which network slice-specific authentication and authorization will be performed or is ongoing, if any; and
d)
the "NSSAA to be performed" indicator in the 5GS registration result IE set to indicate that the network slice-specific authentication and authorization procedure will be performed by the network, if the allowed NSSAI is not included in the REGISTRATION ACCEPT message.
If the initial registration request is not for onboarding services in SNPN, the UE indicated the support for network slice-specific authentication and authorization, and:
the UE did not include the requested NSSAI in the REGISTRATION REQUEST message or none of the S-NSSAIs in the requested NSSAI in the REGISTRATION REQUEST message are allowed;
all default S-NSSAIs are subject to network slice-specific authentication and authorization; and
the network slice-specific authentication and authorization procedure has not been successfully performed for any of the default S-NSSAIs,
the AMF shall in the REGISTRATION ACCEPT message include:
pending NSSAI containing one or more default S-NSSAIs for which network slice-specific authentication and authorization will be performed or is ongoing and one or more S-NSSAIs from the pending NSSAI which the AMF provided to the UE during the previous registration procedure for which network slice-specific authentication and authorization will be performed or is ongoing (if any);
optionally, the rejected NSSAI; and
optionally, the partially rejected NSSAI.
If the initial registration request is not for onboarding services in SNPN, the UE indicated the support for network slice-specific authentication and authorization, and:
the UE did not include the requested NSSAI in the REGISTRATION REQUEST message or none of the S-NSSAIs in the requested NSSAI in the REGISTRATION REQUEST message are allowed; and
one or more default S-NSSAIs are not subject to network slice-specific authentication and authorization or the network slice-specific authentication and authorization procedure has been successfully performed for one or more default S-NSSAIs;
the AMF shall in the REGISTRATION ACCEPT message include:
pending NSSAI containing one or more default S-NSSAIs for which network slice-specific authentication and authorization will be performed or is ongoing (if any) and one or more S-NSSAIs from the pending NSSAI which the AMF provided to the UE during the previous registration procedure for which network slice-specific authentication and authorization will be performed or is ongoing (if any);
allowed NSSAI containing S-NSSAI(s) for the current PLMN each of which corresponds to a default S-NSSAI which are not subject to network slice-specific authentication and authorization or for which the network slice-specific authentication and authorization has been successfully performed;
allowed NSSAI containing one or more default S-NSSAIs, as the mapped S-NSSAI(s) for the allowed NSSAI in roaming scenarios, which are not subject to network slice-specific authentication and authorization or for which the network slice-specific authentication and authorization has been successfully performed; and
optionally, the rejected NSSAI.
If the UE did not include the requested NSSAI in the REGISTRATION REQUEST message or none of the S-NSSAIs in the requested NSSAI in the REGISTRATION REQUEST message are allowed, the allowed NSSAI shall not contain default S-NSSAI(s) that are subject to NSAC. If the subscription information includes the NSSRG information, the S-NSSAIs of the allowed NSSAI shall be associated with at least one common NSSRG value.
When the REGISTRATION ACCEPT message includes a pending NSSAI, the pending NSSAI shall contain all S-NSSAIs for which network slice-specific authentication and authorization (except for re-NSSAA) will be performed or is ongoing from the requested NSSAI of the REGISTRATION REQUEST message that was received over the 3GPP access, non-3GPP access, or both the 3GPP access and non-3GPP access.
If the UE supports extended rejected NSSAI and the AMF determines that maximum number of UEs reached for one or more S-NSSAI(s) in the requested NSSAI as specified in subclause 4.6.2.5, the AMF shall include the rejected NSSAI containing one or more S-NSSAIs with the rejection cause "S-NSSAI not available due to maximum number of UEs reached" in the Extended rejected NSSAI IE in the REGISTRATION ACCEPT message. In addition, the AMF may include a back-off timer value for each S-NSSAI with the rejection cause "S-NSSAI not available due to maximum number of UEs reached" included in the Extended rejected NSSAI IE of the REGISTRATION ACCEPT message. To avoid that large numbers of UEs simultaneously initiate deferred requests, the network should select the value for the backoff timer for each S-NSSAI for the informed UEs so that timeouts are not synchronised.
If the UE does not indicate support for extended rejected NSSAI and the maximum number of UEs has been reached, the AMF should include the rejected NSSAI containing one or more S-NSSAIs with the rejection cause "S-NSSAI not available in the current registration area" in the Rejected NSSAI IE and should not include these S-NSSAIs in the allowed NSSAI in the REGISTRATION ACCEPT message.
If the UE indicates support for network slice usage control and the AMF determines to provide on-demand NSSAI, the AMF shall include the On-demand NSSAI IE in the REGISTRATION ACCEPT message. In addition, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
If the AMF has a new configured NSSAI for the current PLMN or SNPN, the AMF shall include the configured NSSAI for the current PLMN or SNPN in the REGISTRATION ACCEPT message.
The AMF may include a new configured NSSAI for the current PLMN or SNPN in the REGISTRATION ACCEPT message if:
the REGISTRATION REQUEST message did not include the requested NSSAI and the initial registration request is not for onboarding services in SNPN;
the REGISTRATION REQUEST message included the requested NSSAI containing an S-NSSAI that is not valid in the serving PLMN or SNPN;
the REGISTRATION REQUEST message included the requested NSSAI containing S-NSSAI(s) with incorrect mapped S-NSSAI(s);
the REGISTRATION REQUEST message included the Network slicing indication IE with the Default configured NSSAI indication bit set to "Requested NSSAI created from default configured NSSAI";
the S-NSSAIs of the requested NSSAI in the REGISTRATION REQUEST message are not associated with any common NSSRG value, except for the case that the AMF, based on the indication received from the UDM as specified in TS 23.501, has provided all subscribed S-NSSAIs in the configured NSSAI to a UE who does not support NSSRG; or
the UE is in 5GMM-REGISTERED state over the other access and the S-NSSAIs of the requested NSSAI in the REGISTRATION REQUEST message over the current access and the allowed NSSAI over the other access are not associated with any common NSSRG value.
The AMF may include a new configured NSSAI for the current PLMN or SNPN in the REGISTRATION ACCEPT message if the REGISTRATION REQUEST message includes a requested NSSAI containing an S-NSSAI and the S-NSSAI time validity information, if available, indicates that the S-NSSAI is not available (see TS 23.501). In this case, if the TempNS bit of the 5GMM capability IE in the REGISTRATION REQUEST message is set to:
"S-NSSAI time validity information supported" and the S-NSSAI time validity information indicates that the S-NSSAI will:
become available again, then the AMF shall also send S-NSSAI time validity information; or
not become available again, then the AMF shall not include the S-NSSAI in the new configured NSSAI; or
"S-NSSAI time validity information not supported" and the AMF sends a new configured NSSAI, then the AMF shall not include the S-NSSAI in the new configured NSSAI.
If a new configured NSSAI for the current PLMN is included in the REGISTRATION ACCEPT message, the subscription information includes the NSSRG information, and the NSSRG bit in the 5GMM capability IE of the REGISTRATION REQUEST message is set to:
"NSSRG supported", then the AMF shall include the NSSRG information in the REGISTRATION ACCEPT message; or
"NSSRG not supported", then the configured NSSAI shall include one or more S-NSSAIs each of which is associated with all the NSSRG value(s) of the default S-NSSAI(s), or the configured NSSAI shall include, based on the indication received from the UDM as specified in TS 23.501, all subscribed S-NSSAIs even if these S-NSSAIs do not share any common NSSRG value.
If the AMF needs to update the NSSRG information and the UE has set the NSSRG bit to "NSSRG supported" in the 5GMM capability IE of the REGISTRATION REQUEST message, then the AMF shall include the new NSSRG information in the REGISTRATION ACCEPT message. In addition, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
If the UE supports S-NSSAI time validity information and the AMF needs to update the S-NSSAI time validity information, then the AMF shall include the S-NSSAI time validity information IE in the REGISTRATION ACCEPT message. In addition, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
If the UE supports S-NSSAI location validity information and the AMF needs to update the S-NSSAI location validity information, then the AMF shall include the new S-NSSAI location validity information in the Registration accept type 6 IE container IE of the REGISTRATION ACCEPT message. In addition, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
If the UE has set the NSAG bit to "NSAG supported" in the 5GMM capability IE of the REGISTRATION REQUEST message over 3GPP access, the AMF may include the NSAG information IE in the REGISTRATION ACCEPT message. Up to 4 NSAG entries are allowed to be associated with a TAI list in the NSAG information IE. If the UE has set the RCMAN bit to "Sending of REGISTRATION COMPLETE message for NSAG information supported" in the 5GMM capability IE of the REGISTRATION REQUEST message and if the NSAG information IE is included in the REGISTRATION ACCEPT message, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
If the UE receives the NSAG information IE in the REGISTRATION ACCEPT message, the UE shall store the NSAG information as specified in subclause 4.6.2.2.
If the UE supports network slice replacement and the AMF determines to provide the mapping information between the S-NSSAI to be replaced and the alternative S-NSSAI to the UE, then the AMF shall include the Alternative NSSAI IE, the Allowed NSSAI IE including the alternative S-NSSAI, if not included in the current allowed NSSAI, and the Configured NSSAI IE including the alternative S-NSSAI, if not included in the current configured NSSAI, in the REGISTRATION ACCEPT message. If the AMF determines that the replaced S-NSSAI is available, then the AMF shall provide the updated alternative NSSAI excluding the replaced S-NSSAI and the corresponding alternative S-NSSAI in the Alternative NSSAI IE in the REGISTRATION ACCEPT message. If the AMF determines that all the replaced S-NSSAI(s) are available, then the AMF shall provide the Alternative NSSAI IE with Length of Alternative NSSAI contents set to 0 in the REGISTRATION ACCEPT message. In addition, the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3. If the AMF determines that the replaced S-NSSAI is not supported due to the UE moving outside of NS-AoS of the S-NSSAI while the alternative S-NSSAI is available, then the AMF shall provide the updated allowed NSSAI and partially allowed NSSAI, if available, excluding the replaced S-NSSAI, if included, in the allowed NSSAI or partially allowed NSSAI in the REGISTRATION ACCEPT message.
If the UE receives the Alternative NSSAI IE in the REGISTRATION ACCEPT message, the UE shall store the alternative NSSAI as specified in subclause 4.6.2.2.
If the UE has indicated the support for partial network slice and the AMF determines one or more S-NSSAI(s) in the requested NSSAI are to be included in the partially allowed NSSAI as specified in subclause 4.6.2.11, the AMF shall include the Partially allowed NSSAI IE in the Registration accept type 6 IE container IE of the REGISTRATION ACCEPT message.
If the UE receives the Partially allowed NSSAI IE in the Registration accept type 6 IE container IE of the REGISTRATION ACCEPT message, the UE shall store the partially allowed NSSAI as specified in subclause 4.6.2.2.
If the UE requests ciphering keys for ciphered broadcast assistance data in the REGISTRATION REQUEST message and the AMF has valid ciphering key data applicable to the UE's subscription and current tracking area, then the AMF shall include the ciphering key data in the Ciphering key data IE of the REGISTRATION ACCEPT message.
The AMF shall include the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed" in the REGISTRATION ACCEPT message if the UDM has indicated that the subscription data for network slicing has changed. In this case the AMF shall start timer T3550 and enter state 5GMM-COMMON-PROCEDURE-INITIATED as described in subclause 5.1.3.2.3.3.
The UE that has indicated the support for network slice-specific authentication and authorization receiving the pending NSSAI in the REGISTRATION ACCEPT message shall store the S-NSSAI(s) in the pending NSSAI as specified in subclause 4.6.2.2. If the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, the UE shall store the received pending NSSAI for each of the equivalent PLMNs as specified in subclause 4.6.2.2. If the pending NSSAI is not included in the REGISTRATION ACCEPT message and the "NSSAA to be performed" indicator is not set to "Network slice-specific authentication and authorization is to be performed" in the 5GS registration result IE of the REGISTRATION ACCEPT message, then the UE shall delete the pending NSSAI for the current PLMN and its equivalent PLMN(s) or SNPN, if existing, as specified in subclause 4.6.2.2.
The UE receiving the rejected NSSAI in the REGISTRATION ACCEPT message takes the following actions based on the rejection cause in the rejected S-NSSAI(s):
"S-NSSAI not available in the current PLMN or SNPN"
The UE shall add the rejected S-NSSAI(s) in the rejected NSSAI for the current PLMN or SNPN as specified in subclause 4.6.2.2 and shall not attempt to use this S-NSSAI(s) in the current PLMN or SNPN over any access until switching off the UE, the UICC containing the USIM is removed, the entry of the "list of subscriber data" with the SNPN identity of the current SNPN is updated, or the rejected S-NSSAI(s) are removed as described in subclause 4.6.2.2.
"S-NSSAI not available in the current registration area"
The UE shall add the rejected S-NSSAI(s) in the rejected NSSAI for the current registration area as specified in subclause 4.6.2.2 and shall not attempt to use this S-NSSAI(s) in the current registration area over the current until switching off the UE, the UE moving out of the current registration area, the UICC containing the USIM is removed, the entry of the "list of subscriber data" with the SNPN identity of the current SNPN is updated, or the rejected S-NSSAI(s) are removed as described in subclause 4.6.2.2.
"S-NSSAI not available due to the failed or revoked network slice-specific authentication and authorization"
The UE shall store the rejected S-NSSAI(s) in the rejected NSSAI for the failed or revoked NSSAA as specified in subclause 4.6.2.2 and shall not attempt to use this S-NSSAI in the current PLMN or SNPN over any access until switching off the UE, the UICC containing the USIM is removed, the entry of the "list of subscriber data" with the SNPN identity of the current SNPN is updated, or the rejected S-NSSAI(s) are removed as described in subclause 4.6.1 and subclause 4.6.2.2.
"S-NSSAI not available due to maximum number of UEs reached"
Unless the back-off timer value received along with the S-NSSAI is zero, the UE shall add the rejected S-NSSAI(s) in the rejected NSSAI for the maximum number of UEs reached as specified in subclause 4.6.2.2 and shall not attempt to use this S-NSSAI in the current PLMN or SNPN over the current access until switching off the UE, the UICC containing the USIM is removed, the entry of the "list of subscriber data" with the SNPN identity of the current SNPN is updated, or the rejected S-NSSAI(s) are removed as described in subclauses 4.6.1 and 4.6.2.2.
If there is one or more S-NSSAIs in the rejected NSSAI with the rejection cause "S-NSSAI not available due to maximum number of UEs reached", then for each S-NSSAI, the UE shall behave as follows:
stop the timer T3526 associated with the S-NSSAI, if running;
start the timer T3526 with:
the back-off timer value received along with the S-NSSAI, if a back-off timer value is received along with the S-NSSAI that is neither zero nor deactivated; or
an implementation specific back-off timer value, if no back-off timer value is received along with the S-NSSAI; and
remove the S-NSSAI from the rejected NSSAI for the maximum number of UEs reached when the timer T3526 associated with the S-NSSAI expires.
If the UE sets the NSSAA bit in the 5GMM capability IE to "Network slice-specific authentication and authorization not supported", and:
if the Requested NSSAI IE only includes the S-NSSAI(s) subject to network slice-specific authentication and authorization and one or more default S-NSSAIs (containing one or more S-NSSAIs each of which may be associated with a new S-NSSAI) which are not subject to network slice-specific authentication and authorization are available, the AMF shall in the REGISTRATION ACCEPT message include:
the allowed NSSAI or the partially allowed NSSAI containing S-NSSAI(s) for the current PLMN or SNPN each of which corresponds to a default S-NSSAI which are not subject to network slice-specific authentication and authorization;
the allowed NSSAI or the partially allowed NSSAI containing the default S-NSSAIs, as the mapped S-NSSAI(s) for the allowed NSSAI in roaming scenarios, which are not subject to network slice-specific authentication and authorization; and
the rejected NSSAI containing the S-NSSAI(s) subject to network slice specific authentication and authorization with the rejection cause indicating "S-NSSAI not available in the current PLMN or SNPN", except if the UE has not set the ER-NSSAI bit to "Extended rejected NSSAI supported" in the 5GMM capability IE of the REGISTRATION REQUEST message and the S-NSSAI(s) is associated to multiple mapped S-NSSAIs and some of these but not all mapped S-NSSAIs are subject to NSSAA; or
if the Requested NSSAI IE includes one or more S-NSSAIs subject to network slice-specific authentication and authorization, the AMF shall in the REGISTRATION ACCEPT message include:
the allowed NSSAI or the partially allowed NSSAI containing the S-NSSAI(s) or the mapped S-NSSAI(s) which are not subject to network slice-specific authentication and authorization; and
the rejected NSSAI containing:
the S-NSSAI(s) subject to network slice specific authentication and authorization with the rejection cause indicating "S-NSSAI not available in the current PLMN or SNPN", except if the UE has not set the ER-NSSAI bit to "Extended rejected NSSAI supported" in the 5GMM capability IE of the REGISTRATION REQUEST message and the S-NSSAI is associated to multiple mapped S-NSSAIs and some of these but not all mapped S-NSSAIs are subject to NSSAA; and
the S-NSSAI(s) which was included in the requested NSSAI but rejected by the network associated with the rejection cause indicating "S-NSSAI not available in the current PLMN or SNPN" or the rejection cause indicating "S-NSSAI not available in the current registration area", if any.
If the UE does not indicate support for network slice-specific authentication and authorization, the initial registration request is not for onboarding services in SNPN, and if:
the UE did not include the requested NSSAI in the REGISTRATION REQUEST message; or
none of the S-NSSAIs in the requested NSSAI in the REGISTRATION REQUEST message are allowed;
and one or more default S-NSSAIs (containing one or more S-NSSAIs each of which may be associated with a new S-NSSAI) which are not subject to network slice-specific authentication and authorization are available, the AMF shall:
put the allowed S-NSSAI(s) for the current PLMN or SNPN each of which corresponds to a default S-NSSAI and not subject to network slice-specific authentication and authorization in the allowed NSSAI of the REGISTRATION ACCEPT message;
put the default S-NSSAIs and not subject to network slice-specific authentication and authorization, as the mapped S-NSSAI(s) for the allowed NSSAI in roaming scenarios, in the allowed NSSAI of the REGISTRATION ACCEPT message; and
determine a registration area such that all S-NSSAIs of the allowed NSSAI are available in the registration area.
If the REGISTRATION ACCEPT message contains the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed", the UE shall delete the network slicing information for each and every PLMN or SNPN except for the current PLMN or SNPN as specified in subclause 4.6.2.2 and remove all tracking areas from the list of "5GS forbidden tracking areas for roaming" which were added due to rejection of S-NSSAI due to "S-NSSAI not available in the current registration area".
If the REGISTRATION ACCEPT message contains the allowed NSSAI, then the UE shall store the included allowed NSSAI together with the PLMN identity of the registered PLMN or the SNPN identity of the registered SNPN and the registration area as specified in subclause 4.6.2.2. If the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, the UE shall store the received allowed NSSAI in each of allowed NSSAIs which are associated with each of the PLMNs.
If the REGISTRATION ACCEPT message contains a configured NSSAI IE with a new configured NSSAI for the current PLMN or SNPN and optionally the mapped S-NSSAI(s) for the configured NSSAI for the current PLMN or SNPN, the UE shall store the contents of the configured NSSAI IE as specified in subclause 4.6.2.2. In addition, if the REGISTRATION ACCEPT message contains:
an NSSRG information IE, the UE shall store the contents of the NSSRG information IE as specified in subclause 4.6.2.2. If the UE receives a new configured NSSAI in the REGISTRATION ACCEPT message and no NSSRG information IE, the UE shall delete any stored NSSRG information, if any, as specified in subclause 4.6.2.2;
an S-NSSAI location validity information in the Registration accept type 6 IE container IE, the UE shall store the contents of the S-NSSAI location validity information as specified in subclause 4.6.2.2. If the UE receives a Configured NSSAI IE in the REGISTRATION ACCEPT message and no S-NSSAI location validity information, the UE shall delete any stored S-NSSAI location validity information as specified in subclause 4.6.2.2;
an S-NSSAI time validity information IE, the UE shall store the contents of the S-NSSAI time validity information IE as specified in subclause 4.6.2.2. If the UE receives a Configured NSSAI IE in the REGISTRATION ACCEPT message and no S-NSSAI time validity information IE, the UE shall delete any stored S-NSSAI time validity information as specified in subclause 4.6.2.2; or
an On-demand NSSAI IE, the UE shall store the contents of the On-demand NSSAI IE as specified in subclause 4.6.2.2. If the UE receives a Configured NSSAI IE in the REGISTRATION ACCEPT message and no On-demand NSSAI IE, the UE shall delete any stored on-demand NSSAI as specified in subclause 4.6.2.2. The UE shall stop slice deregistration inactivity timer, if running for the S-NSSAI which is deleted from the on-demand NSSAI.
If the REGISTRATION ACCEPT message:
includes the 5GS registration result IE with the "NSSAA to be performed" indicator set to "Network slice-specific authentication and authorization is to be performed";
includes a pending NSSAI;
does not include an allowed NSSAI; and
does not include an partially allowed NSSAI,
the UE shall delete the stored allowed NSSAI, if any, as specified in subclause 4.6.2.2, and the UE:
shall not initiate a 5GSM procedure except for emergency services ; and
shall not initiate a service request procedure except for cases f), i), m) and o) in subclause 5.6.1.1;
shall not initiate an NAS transport procedure except for sending SMS, an LPP message, a UPP-CMI container, an SLPP message, a location service message, an SOR transparent container, a UE policy container, a UE parameters update transparent container or a CIoT user data container;
until the UE receives an allowed NSSAI, a partially allowed NSSAI, or both.
If the UE included S1 mode supported indication in the REGISTRATION REQUEST message, the AMF supporting interworking with EPS shall set the IWK N26 bit to either:
"interworking without N26 interface not supported" if the AMF supports N26 interface; or
"interworking without N26 interface supported" if the AMF does not support N26 interface
in the 5GS network feature support IE in the REGISTRATION ACCEPT message.
The UE supporting S1 mode shall operate in the mode for interworking with EPS as follows:
if the IWK N26 bit in the 5GS network feature support IE is set to "interworking without N26 interface not supported", the UE shall operate in single-registration mode;
if the IWK N26 bit in the 5GS network feature support IE is set to "interworking without N26 interface supported" and the UE supports dual-registration mode, the UE may operate in dual-registration mode; or
if the IWK N26 bit in the 5GS network feature support IE is set to "interworking without N26 interface supported" and the UE only supports single-registration mode, the UE shall operate in single-registration mode.
The UE shall store the received interworking without N26 interface indicator for interworking with EPS as specified in Annex C.1 and treat it as valid in the entire PLMN and its equivalent PLMN(s).
The network informs the UE about the support of specific features, such as IMS voice over PS session, location services (5G-LCS), emergency services, emergency services fallback, ATSSS and non-3GPP access path switching, in the 5GS network feature support information element. In a UE with IMS voice over PS session capability, the IMS voice over PS session indicator, the Emergency services support indicator, and the Emergency services fallback indicator shall be provided to the upper layers. The upper layers take the IMS voice over PS session indicator into account when selecting the access domain for voice sessions or calls. In a UE with LCS capability, location services indicator (5G-LCS) shall be provided to the upper layers. When initiating an emergency call, the upper layers also take the IMS voice over PS session indicator, the Emergency services support indicator, and the Emergency services fallback indicator into account for the access domain selection. In a UE with the capability for ATSSS, the network support for ATSSS shall be provided to the upper layers. If the UE receives the 5GS network feature support IE with the ATSSS support indicator set to "ATSSS not supported", the UE shall perform a local release of the MA PDU session, if any. In a UE that supports non-3GPP access path switching, the network support for non-3GPP access path switching shall be provided to the upper layers. If the UE receives the 5GS network feature support IE with the non-3GPP access path switching bit set to "non-3GPP access path switching not supported", the UE shall not perform the registration procedure for mobility registration update for non-3GPP access path switching.
The AMF shall set the EMF bit in the 5GS network feature support IE to:
"Emergency services fallback supported in NR connected to 5GCN and E-UTRA connected to 5GCN" if the network supports the emergency services fallback procedure when the UE is in an NR cell connected to 5GCN or an E-UTRA cell connected to 5GCN;
"Emergency services fallback supported in NR connected to 5GCN only" if the network supports the emergency services fallback procedure when the UE is in an NR cell connected to 5GCN and does not support the emergency services fallback procedure when the UE is in an E-UTRA cell connected to 5GCN;
"Emergency services fallback supported in E-UTRA connected to 5GCN only" if the network supports the emergency services fallback procedure when the UE is in an E-UTRA cell connected to 5GCN and does not support the emergency services fallback procedure when the UE is in an NR cell connected to 5GCN; or
"Emergency services fallback not supported" if network does not support the emergency services fallback procedure when the UE is in any cell connected to 5GCN.
Access identity 1 is only applicable while the UE is in N1 mode. Access identity 2 is only applicable while the UE is in N1 mode.
When the UE is registered to the same PLMN or SNPN over 3GPP and non-3GPP access, the UE and the AMF maintain one MPS indicator and one MCS indicator that are common to both 3GPP and non-3GPP access. When the UE is registered to different PLMNs or SNPNs over 3GPP access and non-3GPP access, the UE maintains two MPS indicators and two MCS indicators separately for different accesses i.e., an MPS indicator and an MCS indicator for the 3GPP access and another MPS indicator and an MCS indicator for the non-3GPP access. For both 3GPP and non-3GPP access, the access identity is determined according to subclause 4.5.2:
if the UE is not operating in SNPN access operation mode:
a)
the network informs the UE that the use of access identity 1 is valid in the RPLMN or equivalent PLMN by setting the MPS indicator bit of the 5GS network feature support IE to "Access identity 1 valid", in the REGISTRATION ACCEPT message. Based on operator policy, the AMF sets the MPS indicator bit in the REGISTRATION ACCEPT message based on the MPS priority information in the user's subscription context obtained from the UDM;
b)
upon receiving a REGISTRATION ACCEPT message with the MPS indicator bit set to "Access identity 1 valid":
via 3GPP access; or
via non-3GPP access if the UE is registered to the same PLMN over 3GPP access and non-3GPP access;
the UE shall act as a UE with access identity 1 configured for MPS, as described in subclause 4.5.2, in all NG-RAN of the registered PLMN and its equivalent PLMNs. The MPS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in all NG-RAN of the registered PLMN and its equivalent PLMNs until the UE receives a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message with the MPS indicator bit set to "Access identity 1 not valid":
via 3GPP access; or
via non-3GPP access if the UE is registered to the same PLMN over 3GPP access and non-3GPP access; or
until the UE selects a non-equivalent PLMN over 3GPP access;
b1)
upon receiving a REGISTRATION ACCEPT message with the MPS indicator bit set to "Access identity 1 valid":
via non-3GPP access; or
via 3GPP access if the UE is registered to the same PLMN over 3GPP access and non-3GPP access;
the UE shall act as a UE with access identity 1 configured for MPS, as described in subclause 4.5.2, in non-3GPP access of the registered PLMN and its equivalent PLMNs. The MPS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in non-3GPP access of the registered PLMN and its equivalent PLMNs until the UE receives a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message with the MPS indicator bit set to "Access identity 1 not valid":
via non-3GPP access; or
via 3GPP access if the UE is registered to the same PLMN over 3GPP access and non-3GPP access; or
until the UE selects a non-equivalent PLMN over non-3GPP access;
c)
the network informs the UE that the use of access identity 2 is valid in the RPLMN or equivalent PLMN by setting the MCS indicator bit of the 5GS network feature support IE to "Access identity 2 valid", in the REGISTRATION ACCEPT message. Based on operator policy, the AMF sets the MCS indicator bit in the REGISTRATION ACCEPT message based on the MCS priority information in the user's subscription context obtained from the UDM;
d)
upon receiving a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 valid":
via 3GPP access; or
via non-3GPP access if the UE is registered to the same PLMN over 3GPP access and non-3GPP access;
the UE shall act as a UE with access identity 2 configured for MCS, as described in subclause 4.5.2, in all NG-RAN of the registered PLMN and its equivalent PLMNs. The MCS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in all NG-RAN of the registered PLMN and its equivalent PLMNs until the UE receives a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message with the MCS indicator bit set to "Access identity 2 not valid":
via 3GPP access; or
via non-3GPP access if the UE is registered to the same PLMN over 3GPP access and non-3GPP access; or
until the UE selects a non-equivalent PLMN over 3GPP access; and
d1)
upon receiving a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 valid":
via non-3GPP access; or
via 3GPP access if the UE is registered to the same PLMN over 3GPP access and non-3GPP access;
the UE shall act as a UE with access identity 2 configured for MCS, as described in subclause 4.5.2, in non-3GPP access of the registered PLMN and its equivalent PLMNs. The MCS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in non-3GPP access of the registered PLMN and its equivalent PLMNs until the UE receives a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message with the MCS indicator bit set to "Access identity 2 not valid":
via non-3GPP access; or
via 3GPP access if the UE is registered to the same PLMN over 3GPP access and non-3GPP access; or
until the UE selects a non-equivalent PLMN over non-3GPP access; or
if the UE is operating in SNPN access operation mode:
a)
the network informs the UE that the use of access identity 1 is valid in the RSNPN or equivalent SNPN by setting the MPS indicator bit of the 5GS network feature support IE to "Access identity 1 valid", in the REGISTRATION ACCEPT message. Based on operator policy, the AMF sets the MPS indicator bit in the REGISTRATION ACCEPT message based on the MPS priority information in the user's subscription context obtained from the UDM;
b)
upon receiving a REGISTRATION ACCEPT message with the MPS indicator bit set to "Access identity 1 valid":
via 3GPP access; or
via non-3GPP access if the UE is registered to the same SNPN over 3GPP access and non-3GPP access;
the UE shall act as a UE with access identity 1 configured for MPS, as described in subclause 4.5.2A, in all NG-RAN of the registered SNPN and its equivalent SNPNs. The MPS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in all NG-RAN of the registered SNPN and its equivalent SNPNs until the UE receives a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message with the MPS indicator bit set to "Access identity 1 not valid":
via 3GPP access; or
via non-3GPP access if the UE is registered to the same SNPN over 3GPP access and non-3GPP access; or
until the UE selects a non-equivalent SNPN over 3GPP access;
b1)
upon receiving a REGISTRATION ACCEPT message with the MPS indicator bit set to "Access identity 1 valid":
via non-3GPP access; or
via 3GPP access if the UE is registered to the same SNPN over 3GPP access and non-3GPP access;
the UE shall act as a UE with access identity 1 configured for MPS, as described in subclause 4.5.2A, in non-3GPP access of the registered SNPN and its equivalent SNPNs. The MPS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in non-3GPP access of the registered SNPN and its equivalent SNPNs until the UE receives a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message with the MPS indicator bit set to "Access identity 1 not valid";
via non-3GPP access; or
via 3GPP access if the UE is registered to the same SNPN over 3GPP access and non-3GPP access; or
until the UE selects a non-equivalent SNPN over non-3GPP access;
c)
the network informs the UE that the use of access identity 2 is valid in the RSNPN or equivalent SNPN by setting the MCS indicator bit of the 5GS network feature support IE to "Access identity 2 valid", in the REGISTRATION ACCEPT message. Based on operator policy, the AMF sets the MCS indicator bit in the REGISTRATION ACCEPT message based on the MCS priority information in the user's subscription context obtained from the UDM;
d)
upon receiving a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 valid":
via 3GPP access; or
via non-3GPP access if the UE is registered to the same SNPN over 3GPP access and non-3GPP access;
the UE shall act as a UE with access identity 2 configured for MCS, as described in subclause 4.5.2A, in all NG-RAN of the registered SNPN and its equivalent SNPNs. The MCS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in all NG-RAN of the registered SNPN and its equivalent SNPNs until the UE receives a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message with the MCS indicator bit set to "Access identity 2 not valid":
via 3GPP access; or
via non-3GPP access if the UE is registered to the same SNPN over 3GPP access and non-3GPP access; or
until the UE selects a non-equivalent SNPN over 3GPP access; and
d1)
upon receiving a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 valid":
via non-3GPP access; or
via 3GPP access if the UE is registered to the same SNPN over 3GPP access and non-3GPP access;
the UE shall act as a UE with access identity 2 configured for MCS, as described in subclause 4.5.2A, in non-3GPP access of the registered SNPN and its equivalent SNPNs. The MCS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid in non-3GPP access of the registered SNPN and its equivalent SNPNs until the UE receives a REGISTRATION ACCEPT message or a CONFIGURATION UPDATE COMMAND message with the MCS indicator bit set to "Access identity 2 not valid":
via non-3GPP access; or
via 3GPP access if the UE is registered to the same SNPN over 3GPP access and non-3GPP access; or
until the UE selects a non-equivalent SNPN over non-3GPP access.
If the UE indicates support for restriction on use of enhanced coverage in the REGISTRATION REQUEST message and:
in WB-N1 mode, the AMF decides to restrict the use of CE mode B for the UE, then the AMF shall set the RestrictEC bit to "CE mode B is restricted";
in WB-N1 mode, the AMF decides to restrict the use of both CE mode A and CE mode B for the UE, then the AMF shall set the RestrictEC bit to "Both CE mode A and CE mode B are restricted"; or
in NB-N1 mode, the AMF decides to restrict the use of enhanced coverage for the UE, then the AMF shall set the RestrictEC bit to "Use of enhanced coverage is restricted",
in the 5GS network feature support IE in the REGISTRATION ACCEPT message.
If the UE indicates support of the N1 NAS signalling connection release in the REGISTRATION REQUEST message and the network decides to accept the N1 NAS signalling connection release, then the AMF shall set the N1 NAS signalling connection release bit to "N1 NAS signalling connection release supported" in the 5GS network feature support IE of the REGISTRATION ACCEPT message.
If the UE indicates support of the paging indication for voice services in the REGISTRATION REQUEST message and the network decides to accept the paging indication for voice services, then the AMF shall set the paging indication for voice services bit to "paging indication for voice services supported" in the 5GS network feature support IE of the REGISTRATION ACCEPT message. Upon receipt of REGISTRATION ACCEPT message with the paging indication for voice services bit set to "paging indication for voice services supported", the UE NAS layer informs the lower layers that paging indication for voice services is supported. Otherwise, the UE NAS layer informs the lower layers that paging indication for voice services is not supported.
If the UE indicates support of the reject paging request in the REGISTRATION REQUEST message and the network decides to accept the reject paging request, then the AMF shall set the reject paging request bit to "reject paging request supported" in the 5GS network feature support IE of the REGISTRATION ACCEPT message.
If the UE indicates support of the paging restriction in the REGISTRATION REQUEST message, and the AMF sets:
the reject paging request bit to "reject paging request supported";
the N1 NAS signalling connection release bit to "N1 NAS signalling connection release supported"; or
both of them;
in the 5GS network feature support IE of the REGISTRATION ACCEPT message, and the network decides to accept the paging restriction, then the AMF shall set the paging restriction bit to "paging restriction supported" in the 5GS network feature support IE of the REGISTRATION ACCEPT message.
If the UE indicates support of ranging and sidelink positioning in the REGISTRATION REQUEST message and the network supports and accepts the use of ranging and sidelink positioning, the AMF shall set the ranging and sidelink positioning support bit to "Ranging and sidelink positioning supported" in the 5GS network feature support IE of the REGISTRATION ACCEPT message.
If the UE has set the Follow-on request indicator to "Follow-on request pending" in the REGISTRATION REQUEST message, or the network has downlink signalling pending, the AMF shall not immediately release the NAS signalling connection after the completion of the registration procedure.
If the UE is authorized to use A2X communication over PC5 reference point based on:
at least one of the following bits in the 5GMM capability IE of the REGISTRATION REQUEST message set by the UE, or already stored in the 5GMM context in the AMF during the previous registration procedure as follows:
the A2XEPC5 bit to "A2X over E-UTRA-PC5 supported"; or
the A2XNPC5 bit to "A2X over NR-PC5 supported"; and
the user's subscription context obtained from the UDM as defined in TS 23.256;
the AMF should not immediately release the NAS signalling connection after the completion of the registration procedure.
If the UE is authorized to use V2X communication over PC5 reference point based on:
at least one of the following bits in the 5GMM capability IE of the REGISTRATION REQUEST message set by the UE, or already stored in the 5GMM context in the AMF during the previous registration procedure as follows:
the V2XCEPC5 bit to "V2X communication over E-UTRA-PC5 supported"; or
the V2XCNPC5 bit to "V2X communication over NR-PC5 supported"; and
the user's subscription context obtained from the UDM as defined in TS 23.287;
the AMF should not immediately release the NAS signalling connection after the completion of the registration procedure.
If the UE is authorized to use 5G ProSe services based on:
at least one of the following bits in the 5GMM capability IE of the REGISTRATION REQUEST message set by the UE, or already stored in the 5GMM context in the AMF during the previous registration procedure as follows:
the 5G ProSe direct discovery bit to "5G ProSe direct discovery supported"; or
the 5G ProSe direct communication bit to "5G ProSe direct communication supported"; and
the user's subscription context obtained from the UDM as defined in TS 23.304;
the AMF should not immediately release the NAS signalling connection after the completion of the registration procedure.
If the Requested DRX parameters IE was included in the REGISTRATION REQUEST message, the AMF shall include the Negotiated DRX parameters IE in the REGISTRATION ACCEPT message and replace any stored Negotiated DRX parameter and use it for the downlink transfer of signalling and user data. The AMF may set the Negotiated DRX parameters IE based on the received Requested DRX parameters IE and operator policy if available.
If the Requested NB-N1 mode DRX parameters IE was included in the REGISTRATION REQUEST message, the AMF shall include the Negotiated NB-N1 mode DRX parameters IE in the REGISTRATION ACCEPT message and replace any stored Negotiated NB-N1 mode DRX parameters and use it for the downlink transfer of signalling and user data in NB-N1 mode. The AMF may set the Negotiated NB-N1 mode DRX parameters IE based on the received Requested NB-N1 mode DRX parameters IE and operator policy if available.
The AMF shall include the Negotiated extended DRX parameters IE in the REGISTRATION ACCEPT message only if the Requested extended DRX parameters IE was included in the REGISTRATION REQUEST message, and the AMF supports and accepts the use of eDRX. The AMF may set the Negotiated extended DRX parameters IE based on the received Requested extended DRX parameters IE, operator policy, information from NG-RAN and the user's subscription context obtained from the UDM if available.
If:
the UE's USIM is configured with indication that the UE is to receive the SOR transparent container IE, the SOR transparent container IE included in the REGISTRATION ACCEPT message does not successfully pass the integrity check (see TS 33.501); and
if the UE attempts obtaining service on another PLMNs as specified in TS 23.122Annex C;
then the UE shall locally release the established N1 NAS signalling connection after sending a REGISTRATION COMPLETE message.
If:
the UE's USIM is configured with indication that the UE is to receive the SOR transparent container IE, the SOR transparent container IE is not included in the REGISTRATION ACCEPT message; and
the UE attempts obtaining service on another PLMNs as specified in TS 23.122Annex C;
then the UE shall locally release the established N1 NAS signalling connection.
If:
the UE operates in SNPN access operation mode;
the ME is configured to indicate that the UE shall expect to receive the steering of roaming information during initial registration procedure for the selected entry of the "list of subscriber data" or the selected PLMN subscription;
the SOR transparent container IE included in the REGISTRATION ACCEPT message does not successfully pass the integrity check (see TS 33.501); and
the UE attempts obtaining service on another SNPN as specified in TS 23.122Annex C;
then the UE shall locally release the established N1 NAS signalling connection after sending a REGISTRATION COMPLETE message.
If:
the UE operates in SNPN access operation mode;
the ME is configured to indicate that the UE shall expect to receive the steering of roaming information during initial registration procedure for the selected entry of the "list of subscriber data" or the selected PLMN subscription;
the SOR transparent container IE is not included in the REGISTRATION ACCEPT message; and
the UE attempts obtaining service on another SNPN as specified in TS 23.122Annex C;
then the UE shall locally release the established N1 NAS signalling connection.
If the REGISTRATION ACCEPT message includes the SOR transparent container IE and the SOR transparent container IE successfully passes the integrity check (see TS 33.501), the ME shall store the received SOR counter as specified in Annex C and proceed as follows:
the UE shall proceed with the behaviour as specified in TS 23.122Annex C; and
if the registration procedure is performed over 3GPP access and the UE attempts obtaining service on another PLMNs or SNPNs as specified in TS 23.122Annex C, then the UE may locally release the established N1 NAS signalling connection after sending a REGISTRATION COMPLETE message. Otherwise the UE shall send a REGISTRATION COMPLETE message and not release the current N1 NAS signalling connection locally. If an acknowledgement is requested in the SOR transparent container IE of the REGISTRATION ACCEPT message, the UE acknowledgement is included in the SOR transparent container IE of the REGISTRATION COMPLETE message. In the SOR transparent container IE carrying the acknowledgement, the UE shall set the ME support of SOR-CMCI indicator to "SOR-CMCI supported by the ME". Additionally, if the UE supports access to an SNPN using credentials from a credentials holder and the UE is not operating in SNPN access operation mode, the UE may set the ME support of SOR-SNPN-SI indicator to "SOR-SNPN-SI supported by the ME". Additionally, if the UE supports access to an SNPN providing access for localized services in SNPN, the UE shall set the ME support of SOR-SNPN-SI-LS indicator to "SOR-SNPN-SI-LS supported by the ME"
If the SOR transparent container IE successfully passes the integrity check (see TS 33.501) and:
the list type indicates:
"PLMN ID and access technology list", and the SOR transparent container IE indicates a list of preferred PLMN/access technology combinations is provided, then the ME shall replace the highest priority entries in the "Operator Controlled PLMN Selector with Access Technology" list stored in the ME and shall proceed with the behaviour as specified in TS 23.122Annex C; or
"secured packet", then the ME shall behave as if a SMS is received with protocol identifier set to SIM data download, data coding scheme set to class 2 message and SMS payload as secured packet contents of SOR transparent container IE. The SMS payload is forwarded to UICC as specified in TS 23.040 and the ME shall proceed with the behaviour as specified in TS 23.122Annex C; or
the list type indicates "PLMN ID and access technology list" and the SOR transparent container IE indicates "HPLMN indication that 'no change of the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE is needed and thus no list of preferred PLMN/access technology combinations is provided'", the UE operates in SNPN access operation mode and the SOR transparent container IE includes SOR-SNPN-SI, the ME shall replace SOR-SNPN-SI of the selected entry of the "list of subscriber data" or associated with the selected PLMN subscription, as specified in TS 23.122 with the received SOR-SNPN-SI. Additionally, if the SOR transparent container IE includes SOR-SNPN-SI-LS, the ME shall replace SOR-SNPN-SI-LS of the selected entry of the "list of subscriber data" or associated with the selected PLMN subscription, as specified in TS 23.122 with the received SOR-SNPN-SI-LS.
If the SOR-CMCI is present and the Store SOR-CMCI in ME indicator is set to "Store SOR-CMCI in ME" then the UE shall store or delete the SOR-CMCI in the non-volatile memory of the ME as described in Annex C.1.
The UE shall proceed with the behaviour as specified in TS 23.122Annex C.
If the SOR transparent container IE does not pass the integrity check successfully, then the UE shall discard the content of the SOR transparent container IE.
If required by operator policy, the AMF shall include the NSSAI inclusion mode IE in the REGISTRATION ACCEPT message (see Table 4.6.2.3.1 of subclause 4.6.2.3). Upon receipt of the REGISTRATION ACCEPT message:
if the message includes the NSSAI inclusion mode IE, the UE shall operate in the NSSAI inclusion mode indicated in the NSSAI inclusion mode IE over the current access within the current PLMN and its equivalent PLMN(s), if any, or the current SNPN ,in the current registration area; or
otherwise:
if the UE has NSSAI inclusion mode for the current PLMN or SNPN and access type stored in the UE, the UE shall operate in the stored NSSAI inclusion mode;
if the UE does not have NSSAI inclusion mode for the current PLMN or SNPN and the access type stored in the UE and if the UE is performing the registration procedure over:
3GPP access, the UE shall operate in NSSAI inclusion mode D in the current PLMN or SNPN and the current access type;
untrusted non-3GPP access, the UE shall operate in NSSAI inclusion mode B in the current PLMN and the current access type; or
trusted non-3GPP access, the UE shall operate in NSSAI inclusion mode D in the current PLMN and the current access type; or
if the 5G-RG does not have NSSAI inclusion mode for the current PLMN and wireline access stored in the 5G-RG, and the 5G-RG is performing the registration procedure over wireline access, the 5G-RG shall operate in NSSAI inclusion mode B in the current PLMN and the current access type.
The AMF may include operator-defined access category definitions in the REGISTRATION ACCEPT message.
If the UE receives Operator-defined access category definitions IE in the REGISTRATION ACCEPT message and the Operator-defined access category definitions IE contains one or more operator-defined access category definitions, the UE shall delete any operator-defined access category definitions stored for the RPLMN and shall store the received operator-defined access category definitions for the RPLMN. If the UE receives the Operator-defined access category definitions IE in the REGISTRATION ACCEPT message and the Operator-defined access category definitions IE contains no operator-defined access category definitions, the UE shall delete any operator-defined access category definitions stored for the RPLMN. If the REGISTRATION ACCEPT message does not contain the Operator-defined access category definitions IE, the UE shall not delete the operator-defined access category definitions stored for the RPLMN.
If the UE has indicated support for service gap control in the REGISTRATION REQUEST message and:
the REGISTRATION ACCEPT message contains the T3447 value IE, then the UE shall store the new T3447 value, erase any previous stored T3447 value if exists and use the new T3447 value with the timer T3447 next time it is started; or
the REGISTRATION ACCEPT message does not contain the T3447 value IE, then the UE shall erase any previous stored T3447 value if exists and stop the timer T3447 if running.
If the T3448 value IE is present in the received REGISTRATION ACCEPT message and the value indicates that this timer is neither zero nor deactivated, the UE shall:
stop timer T3448 if it is running; and
start timer T3448 with the value provided in the T3448 value IE.
If the UE is using 5GS services with control plane CIoT 5GS optimization, the T3448 value IE is present in the REGISTRATION ACCEPT message and the value indicates that this timer is either zero or deactivated, the UE shall ignore the T3448 value IE and proceed as if the T3448 value IE was not present.
If the REGISTRATION ACCEPT message contains the Truncated 5G-S-TMSI configuration IE, then the UE shall store the included truncated 5G-S-TMSI configuration and return a REGISTRATION COMPLETE message to the AMF to acknowledge reception of the truncated 5G-S-TMSI configuration.
If the UE is not in NB-N1 mode, the UE has set the RACS bit to "RACS supported" in the 5GMM Capability IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message includes:
a UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested", the UE shall delete any network-assigned UE radio capability IDs associated with the RPLMN or RSNPN and, if the UE supports access to an SNPN using credentials from a credentials holder, equivalent SNPNs or both, the selected entry of the "list of subscriber data" or the selected PLMN subscription stored at the UE, then the UE shall, after the completion of the ongoing registration procedure, initiate a registration procedure for mobility and periodic registration update as specified in subclause 5.5.1.3.2 over the existing N1 NAS signalling connection; or
a UE radio capability ID IE, the UE shall store the UE radio capability ID as specified in Annex C.
If the UE has included the service-level device ID set to the CAA-level UAV ID in the Service-level-AA container IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message contains the service-level-AA pending indication in the Service-level-AA container IE, the UE shall return a REGISTRATION COMPLETE message to the AMF to acknowledge reception of the service-level-AA pending indication, and the UE shall not attempt to perform another registration procedure for UAS services until the UUAA-MM procedure is completed, or to establish a PDU session for USS communication or a PDU session for C2 communication until the UUAA-MM procedure is completed successfully.
If the UE has included the service-level device ID set to the CAA-level UAV ID in the Service-level-AA container IE of the REGISTRATION REQUEST message and the REGISTRATION ACCEPT message does not contain the service-level-AA pending indication in the Service-level-AA container IE, the UE shall consider the UUAA-MM procedure is not triggered.
If the REGISTRATION REQUEST message includes the 5GS registration type IE set to "SNPN onboarding registration" or the network determines that the UE's subscription only allows for configuration of SNPN subscription parameters in PLMN via the user plane, the AMF may start an implementation specific timer for onboarding services when the network considers that the UE is in 5GMM-REGISTERED (i.e. the network receives the REGISTRATION COMPLETE message from UE).
If the UE receives the List of PLMNs to be used in disaster condition IE in the REGISTRATION ACCEPT message and the UE supports MINT, the UE shall delete the "list of PLMN(s) to be used in disaster condition" stored in the ME together with the PLMN ID of the RPLMN, if any, and may store the "list of PLMN(s) to be used in disaster condition" included in the List of PLMNs to be used in disaster condition IE in the ME together with the PLMN ID of the RPLMN.
If the UE receives the Disaster roaming wait range IE in the REGISTRATION ACCEPT message and the UE supports MINT, the UE shall delete the disaster roaming wait range stored in the ME, if any, and store the disaster roaming wait range included in the Disaster roaming wait range IE in the ME.
If the UE receives the Disaster return wait range IE in the REGISTRATION ACCEPT message and the UE supports MINT, the UE shall delete the disaster return wait range stored in the ME, if any, and store the disaster return wait range included in the Disaster return wait range IE in the ME.
If the 5GS registration type IE in the REGISTRATION REQUEST message is set to "disaster roaming initial registration" and:
the UE determined PLMN with disaster condition IE is included in the REGISTRATION REQUEST message, the AMF shall determine the PLMN with disaster condition in the UE determined PLMN with disaster condition IE;
the UE determined PLMN with disaster condition IE is not included in the REGISTRATION REQUEST message and the Additional GUTI IE is included in the REGISTRATION REQUEST message and contains 5G-GUTI of a PLMN of the country of the PLMN providing disaster roaming services, the AMF shall determine the PLMN with disaster condition in the PLMN identity of the 5G-GUTI;
the UE determined PLMN with disaster condition IE and the Additional GUTI IE are not included in the REGISTRATION REQUEST message and:
the 5GS mobile identity IE contains 5G-GUTI of a PLMN of the country of the PLMN providing disaster roaming services, the AMF shall determine the PLMN with disaster condition in the PLMN identity of the 5G-GUTI; or
the 5GS mobile identity IE contains SUCI of a PLMN of the country of the PLMN providing disaster roaming services, the AMF shall determine the PLMN with disaster condition in the PLMN identity of the SUCI; or
the UE determined PLMN with disaster condition IE is not included in the REGISTRATION REQUEST message, NG-RAN of the PLMN providing disaster roaming services broadcasts disaster roaming indication and:
the Additional GUTI IE is included in the REGISTRATION REQUEST message and contains 5G-GUTI of a PLMN of a country other than the country of the PLMN providing disaster roaming services; or
the Additional GUTI IE is not included and the 5GS mobile identity IE contains 5G-GUTI or SUCI of a PLMN of a country other than the country of the PLMN providing disaster roaming services;
the AMF shall determine the PLMN with disaster condition based on the disaster roaming agreement arrangement between mobile network operators.
If the AMF determines that a disaster condition applies to the PLMN with disaster condition, and the UE is allowed to be registered for disaster roaming services, the AMF shall set the Disaster roaming registration result value bit in the 5GS registration result IE to "no additional information" in the REGISTRATION ACCEPT message. If the AMF determines that the UE can be registered to the PLMN for normal service, the AMF shall set the Disaster roaming registration result value bit in the 5GS registration result IE to "request for registration for disaster roaming services accepted as registration not for disaster roaming services" in the REGISTRATION ACCEPT message.
If the UE indicates "disaster roaming initial registration" in the 5GS registration type IE in the REGISTRATION REQUEST message and the 5GS registration result IE value in the REGISTRATION ACCEPT message is set to:
"request for registration for disaster roaming service accepted as registration not for disaster roaming service", the UE shall consider itself registered for normal service. If the PLMN identity of the registered PLMN is a member of the forbidden PLMN list as specified in subclause 5.3.13A, any such PLMN identity shall be deleted from the corresponding list(s). If UE supports S1 mode, the UE shall initiate the registration procedure for mobility and periodic registration update and indicate that S1 mode is supported as described in subclause 5.5.1.3.2; or
"no additional information", the UE shall consider itself registered for disaster roaming services.
If the UE receives the forbidden TAI(s) for the list of "5GS forbidden tracking areas for roaming" IE in the REGISTRATION ACCEPT message, the UE shall store the TAI(s) belonging to the serving PLMN or equivalent PLMN(s) and ignore the TAI(s) which do not belong to the serving PLMN or equivalent PLMN(s) included in the IE, if not already stored, into the list of "5GS forbidden tracking areas for roaming".
If the UE receives the forbidden TAI(s) for the list of "5GS forbidden tracking areas for regional provision of service" IE in the REGISTRATION ACCEPT message, the UE shall store the TAI(s) belonging to the serving PLMN or equivalent PLMN(s) and ignore the TAI(s) which do not belong to the serving PLMN or equivalent PLMN(s) included in the IE, if not already stored, into the list of "5GS forbidden tracking areas for regional provision of service".
If the UE supporting the reconnection to the network due to RAN timing synchronization status change receives the RAN timing synchronization IE with the RecReq bit set to "Reconnection requested" in the REGISTRATION ACCEPT message, the UE shall operate as specified in subclauses 5.3.1.4, 5.5.1.3.2 and 5.6.1.1.
If the UE supports discontinuous coverage, the AMF may include the Discontinuous coverage maximum time offset IE in the REGISTRATION ACCEPT message.
If the UE receives, the Discontinuous coverage maximum time offset IE in the REGISTRATION ACCEPT message, the UE shall replace any previously received discontinuous coverage maximum time offset value on the same satellite NG-RAN RAT type and PLMN with the latest received timer value.
If the UE receives the Unavailability configuration IE in the REGISTRATION ACCEPT message, the UE shall consider that the corresponding unavailability type is "unavailability due to discontinuous coverage". A UE that does not implement this unavailability type may ignore the Unavailability configuration IE provided by the AMF. If the EUPR bit is set to "UE does not need to report end of unavailability period", the UE is not required to initiate the registration procedure for mobility registration update when the unavailability period duration has ended.
If the UE receives the Unavailability configuration IE with a value of the unavailability period duration in the REGISTRATION ACCEPT, then the UE may either:
delete a UE determined value and start using the received unavailability period duration value; or
use a UE determined value.
If the UE receives the Unavailability configuration IE with a value of the start of the unavailability period in the REGISTRATION ACCEPT message, then the UE may either:
delete a UE determined value and start using the received start of the unavailability period value; or
use a UE determined value.
If the UE operating as MBSR receives the MBSRAI field of the Feature authorization indication IE in the REGISTRATION ACCEPT message, the UE NAS layer informs the lower layers of the status of MBSR authorization as specified in subclause 5.35A.4 of TS 23.501.
If the UE indicates support of the RAT utilization control in the REGISTRATION REQUEST message and the network decides to apply the RAT utilization control, the AMF shall include the RAT utilization control IE in the REGISTRATION ACCEPT message. The AMF shall not indicate "NG-RAN is restricted" in the RAT utilization control IE. If the REGISTRATION ACCEPT message contains the RAT utilization control IE, the UE shall store the received RAT utilization control information and replace the previously stored one, if any, with the newly received RAT utilization control information. Otherwise, if the REGISTRATION ACCEPT message does not contain the RAT utilization control IE, the UE shall delete the stored RAT utilization control information if any and shall consider all RATs as not restricted.
