Content for  TS 24.501  Word version:  19.0.0

If the registration update request has been accepted by the network, the AMF shall send a REGISTRATION ACCEPT message to the UE. If timer T3513 is running in the AMF, the AMF shall stop timer T3513 if a paging request was sent with the access type indicating non-3GPP and the REGISTRATION REQUEST message includes the Allowed PDU session status IE. If timer T3565 is running in the AMF, the AMF shall stop timer T3565 when a REGISTRATION REQUEST message is received. 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 5G-GUTI reallocation shall be part of the registration procedure for mobility registration update. The 5G-GUTI reallocation should be part of the registration procedure for periodic registration update. During the registration procedure for mobility registration update, 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. 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 or 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 RCMP 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 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 may include a new TAI list for the UE in the REGISTRATION ACCEPT message. The new TAI list shall not contain 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 there is no TAI list received, the UE shall consider the old TAI list as valid. If the registration area contains TAIs belonging to different PLMNs, which are equivalent PLMNs, and

1. the UE already has stored allowed NSSAI for the current registration area, the UE shall store the allowed NSSAI for the current registration area in each of the allowed NSSAIs which are associated with each of the PLMNs in the registration area;
2. the UE already has stored rejected NSSAI for the current registration area, the UE shall store the rejected NSSAI for the current registration area in each of the rejected NSSAIs which are associated with each of the PLMNs in the registration area;
3. the UE already has stored rejected NSSAI for the failed or revoked NSSAA, the UE shall store the rejected NSSAI for the failed or revoked NSSAA in each of the rejected NSSAIs which are associated with each of the PLMNs in the registration area;
4. the UE already has stored rejected NSSAI for the maximum number of UEs reached, the UE shall store the rejected NSSAI for the maximum number of UEs reached in each of the rejected NSSAIs which are associated with each of the PLMNs in the registration area;
5. the UE already has stored pending NSSAI, the UE shall store the pending NSSAI in each of the pending NSSAIs which are associated with each of the PLMNs in the registration area; and
6. the UE already has stored partially rejected NSSAI, the UE shall store the partially rejected NSSAI in each of the partially rejected NSSAIs which are associated with each of the PLMNs in the registration area.

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 there is no emergency PDU session established, 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. If the UE is not registered for emergency services and there is an emergency PDU session established, the UE shall remove from the list of equivalent PLMNs any PLMN code present in the forbidden PLMN list as specified in subclause 5.3.13A, when the emergency PDU session is released. 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 UE is registered 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 there is no emergency PDU session established and the UE is not registered 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).

If the UE is not registered for emergency services and there is an emergency PDU session established, the UE shall remove from the list of equivalent SNPNs any SNPN identity present in the "permanently forbidden SNPNs" list or the "temporarily forbidden SNPNs" list, when the emergency PDU session is released. 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 UE is not registered for emergency 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). The AMF may include new service area restrictions in the Service area list IE in the REGISTRATION ACCEPT message. The UE, upon receiving a REGISTRATION ACCEPT message with new service area restrictions shall act as described in subclause 5.3.5. 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. 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 includes 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 and may include the T3512 value IE in the REGISTRATION ACCEPT message. If the timer value received in T3512 IE is different from the already stored value of the timer T3512 and the timer T3512 is running, the UE shall restart T3512 with the new value received in the T3512 value IE. 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 UE does not include MICO indication IE in the REGISTRATION REQUEST message, then the AMF shall disable MICO mode if it was already enabled. 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 may include the T3512 value IE in the REGISTRATION ACCEPT message only if the REGISTRATION REQUEST message was sent over the 3GPP access. The AMF may include the non-3GPP de-registration timer value IE in the REGISTRATION ACCEPT message only if the REGISTRATION REQUEST message was sent for the non-3GPP access. 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. If the UE receives the 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 MUSIM UE does not include the Paging restriction IE in the REGISTRATION REQUEST message, the AMF shall delete any stored paging restriction for the UE and stop restricting paging. If the MUSIM UE requests the release of the NAS signalling connection, by setting Request type to "NAS signalling connection release" in the UE request type IE included in the REGISTRATION REQUEST message, and the AMF supports the N1 NAS signalling connection release, the AMF shall initiate the release of the NAS signalling connection after the completion of the registration procedure for mobility and periodic registration update. If the UE requests restriction of paging by including the Paging restriction IE and the AMF supports the paging restriction, the AMF:

• if accepts the paging restriction, shall include the 5GS additional request result IE in the REGISTRATION ACCEPT message and set the Paging restriction decision to "paging restriction is accepted". The AMF shall store the paging restriction of the UE and enforce these restrictions in the paging procedure as described in subclause 5.6.2; or
• if rejects the paging restriction, shall include the 5GS additional request result IE in the REGISTRATION ACCEPT message and set the Paging restriction decision to "paging restriction is rejected", and shall discard the received paging restriction. The AMF shall delete any stored paging restriction for the UE and stop restricting paging.

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. 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 AMF decides to deactivate the congestion control for transport of user data via the control plane, then the AMF shall delete the stored control plane data back-off time for the UE and the AMF shall not include timer 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. For inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode, if the UE has included a ngKSI indicating a current 5G NAS security context in the REGISTRATION REQUEST message by which the REGISTRATION REQUEST message is integrity protected, the AMF shall take one of the following actions:

1. if the AMF retrieves the current 5G NAS security context as indicated by the ngKSI and 5G-GUTI sent by the UE, the AMF shall integrity check the REGISTRATION REQUEST message using the current 5G NAS security context and integrity protect the REGISTRATION ACCEPT message using the current 5G NAS security context;
2. if the AMF cannot retrieve the current 5G NAS security context as indicated by the ngKSI and 5G-GUTI sent by the UE, the AMF shall treat the REGISTRATION REQUEST message fails the integrity check and take actions as specified in subclause 4.4.4.3; or
3. if the UE has not included an Additional GUTI IE, the AMF may treat the REGISTRATION REQUEST message as in the previous item, i.e. as if it cannot retrieve the current 5G NAS security context.

For inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode, the AMF shall integrity check REGISTRATION REQUEST message using the current K'AMF as derived when triggering the handover to N1 mode (see subclause 4.4.2.2). The AMF shall verify the received UE security capabilities in the REGISTRATION REQUEST message. The AMF shall then take one of the following actions:

1. if the REGISTRATION REQUEST does not contain a valid KSIAMF in the Non-current native NAS key set identifier IE, the AMF shall remove the non-current native 5G NAS security context, if any, for any 5G-GUTI for this UE. The AMF shall then integrity protect and cipher the REGISTRATION ACCEPT message using the security context based on K'AMF and take the mapped 5G NAS security context into use; or
2. if the REGISTRATION REQUEST contains a valid KSIAMF in the Non-current native NAS key set identifier IE and:
   1. the AMF decides to take the native 5G NAS security context into use, the AMF shall initiate a security mode control procedure to take the corresponding native 5G NAS security context into use and then integrity protect and cipher the REGISTRATION ACCEPT message using the corresponding native 5G NAS security context; and
   2. otherwise, the AMF shall then integrity protect and cipher the REGISTRATION ACCEPT message using the security context based on K'AMF and take the mapped 5G NAS security context into use.

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; and
• the UUAA procedure is to be performed during the registration procedure according to operator policy; and
• there is no valid successful UUAA result for the UE in the UE 5GMM context,

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 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 registration update 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:

a) the Forbidden TAI(s) for the list of "5GS forbidden tracking areas for roaming" IE; or
b) the Forbidden TAI(s) for the list of "5GS forbidden tracking areas for regional provision of service" IE; or
1. 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 mobility and periodic registration request along with along with the mobile IAB-indication over N2 reference point (see TS 38.413) from an 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 mobility and periodic registration request along with along with the mobile IAB-indication over N2 reference point (see TS 38.413) from a UE and the UE is not authorized 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 and service request 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", 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 T3512 value IE as periodic registration update timer (T3512). If the T3512 value IE is not included, the UE shall use the value currently stored, e.g. from a prior REGISTRATION ACCEPT message. If the REGISTRATION ACCEPT message include a T3324 value IE, the UE shall use the value in the T3324 value IE as active time timer (T3324). If the REGISTRATION ACCEPT message does not include a T3324 value IE, UE shall not start the timer T3324 until a new value is received from the network. 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 non-3GPP de-registration timer value IE is not included, the UE shall use the value currently stored, e.g. from a prior REGISTRATION ACCEPT message. If non-3GPP de-registration timer value IE is not included and there is no stored non-3GPP de-registration timer value in the UE, the UE shall use the default value of the non-3GPP de-registration timer. If the REGISTRATION ACCEPT message contains a 5G-GUTI, the UE shall return a REGISTRATION COMPLETE message to the AMF to acknowledge the received 5G-GUTI, stop timer T3519 if running, and delete any stored SUCI. The UE shall provide the 5G-GUTI to the lower layer of 3GPP access if the REGISTRATION ACCEPT message is sent over the non-3GPP access, and the UE is in 5GMM-REGISTERED in both 3GPP access and non-3GPP access in the same PLMN. If the REGISTRATION ACCEPT message contains

1. the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed";
2. 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;
3. an NSSRG information IE with a new NSSRG information;
4. an Alternative NSSAI IE with a new alternative NSSAI;
5. an S-NSSAI location validity information in the Registration accept type 6 IE container IE with a new S-NSSAI location validity information;
6. an S-NSSAI time validity information IE with a new S-NSSAI time validity information; or
7. 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:

1. 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;
2. 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
3. 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.

1. 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:
   1. 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
   2. 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:
      1. 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
      2. 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" and:
         1. the UE does not have an emergency PDU session, 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
         2. the UE has an emergency PDU session, then the UE shall perform a local release of all PDU sessions associated with 3GPP access except for the emergency PDU session and enter the state 5GMM-REGISTERED.LIMITED-SERVICE; or
2. 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:
   1. 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
   2. 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" and:
      1. the UE does not have an emergency PDU session, 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
      2. the UE has an emergency PDU session, then the UE shall perform a local release of all PDU sessions associated with 3GPP access except for the emergency PDU session and enter the state 5GMM-REGISTERED.LIMITED-SERVICE.

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 or 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 assistance information 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 a REGISTRATION COMPLETE message to the AMF to acknowledge 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. 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:

1. stop timer T3448 if it is running; and
2. 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 UE in 5GMM-IDLE mode initiated the registration procedure for mobility and periodic registration update and the REGISTRATION ACCEPT message does not include the T3448 value IE and if timer T3448 is running, then the UE shall stop timer T3448. 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 message, 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:

1. the SMSF address is stored in the UE 5GMM context and:
   1. the UE is considered available for SMS over NAS; or
   2. the UE is considered not available for SMS over NAS and the SMSF has confirmed that the activation of the SMS service is successful; or
2. the SMSF address is not stored in the UE 5GMM context, the SMSF selection is successful and the SMSF has confirmed that the activation of the SMS service is successful;

then the AMF shall set the SMS allowed bit of the 5GS registration result IE in the REGISTRATION ACCEPT message as specified in subclause 5.5.1.2.4. If the UE 5GMM context does not contain an SMSF address or the UE is not considered available for SMS over NAS, then the AMF shall:

1. store the SMSF address in the UE 5GMM context if not stored already; and
2. store 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 SMSF selection in the AMF or SMS activation via the SMSF is not successful, or the AMF does not allow the use of SMS over NAS, 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. If the 5GS update type IE was included in the REGISTRATION REQUEST message with the SMS requested bit set to "SMS over NAS not supported" or the 5GS update type IE was not included in the REGISTRATION REQUEST message, then the AMF shall:

1. mark the 5GMM context to indicate that the UE is not available for SMS over NAS; and
2. 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. If the 5GS update type IE was included in the REGISTRATION REQUEST message with the NG-RAN-RCU bit set to "UE radio capability update needed", the AMF shall delete the stored UE radio capability information or the UE radio capability ID, if any. 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:

1. "3GPP access", the UE:
   1. shall consider itself as being registered to 3GPP access; and
   2. 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
2. "Non-3GPP access", the UE:
   1. shall consider itself as being registered to non-3GPP access; and
   2. 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
3. "3GPP access and non-3GPP access", the UE shall consider itself as being registered to both 3GPP access and non-3GPP access.

If the UE is not currently registered for emergency services and the emergency registered bit of the 5GS registration result IE in the REGISTRATION ACCEPT message is set to "Registered for emergency services", the UE shall consider itself registered for emergency services and shall locally release all non-emergency PDU sessions, if any. 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, in roaming scenarios, and shall include the mapped S-NSSAI(s) for the allowed NSSAI contained in the requested NSSAI (i.e. Requested NSSAI IE or Requested mapped NSSAI IE) from the UE, 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 for the current PLMN or SNPN in the Requested NSSAI IE or one or more mapped S-NSSAIs in the Requested NSSAI IE or Requested mapped NSSAI IE. 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 S-NSSAI associated with each of the active PDN connections for which interworking to 5GS is supported, shall be included in the allowed NSSAI if the UE included the UE status IE with the EMM registration status set to "UE is in EMM-REGISTERED state" in the REGISTRATION REQUEST message and the AMF supports N26 interface. The AMF may also include rejected NSSAI in the REGISTRATION ACCEPT message if the UE is not registered 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 UE is registered 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:

1. 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
2. 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 (i.e. the Requested NSSAI IE or the Requested mapped 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: If the UE is not registered for onboarding services in SNPN, the UE indicated the support for network slice-specific authentication and authorization, and:

1. 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;
2. all default S-NSSAIs are subject to network slice-specific authentication and authorization; and
3. 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:

1. the "NSSAA to be performed" indicator in the 5GS registration result IE to indicate that the network slice-specific authentication and authorization procedure will be performed by the network; and
2. 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); and
3. optionally, the rejected NSSAI.

If the UE is not registered for onboarding services in SNPN, the UE indicated the support for network slice-specific authentication and authorization, and:

1. 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
2. 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:

1. 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);
2. 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 or for which the network slice-specific authentication and authorization has been successfully performed;
3. 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
4. optionally, the rejected NSSAI; and
5. optionally, the partially 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. If the network has pending NSSAI, the S-NSSAIs in the pending NSSAI and allowed NSSAI shall be associated with at least one common NSSRG value. When the REGISTRATION ACCEPT 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 all S-NSSAIs 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 the 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 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:

1. "S-NSSAI time validity information supported" and the S-NSSAI time validity information indicates that the S-NSSAI will:
   1. become available again, then the AMF shall also send S-NSSAI time validity information; or
   2. not become available again, then the AMF shall not include the S-NSSAI in the new configured NSSAI; or
2. "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 or SNPN is included and the UE is roaming, the AMF shall also include the mapped S-NSSAI(s) for the configured NSSAI for the current PLMN or SNPN in the REGISTRATION ACCEPT message. 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. If a new configured NSSAI for the current PLMN or SNPN is included, the subscription information includes the NSSRG information, and the NSSRG bit in the 5GMM capability IE of the REGISTRATION REQUEST message is set to:

1. "NSSRG supported", then the AMF shall include the NSSRG information in the REGISTRATION ACCEPT message; or
2. "NSSRG not supported", then the configured NSSAI shall include 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 S-NSSAI location validity information IE 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. 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. If the S-NSSAI(s) associated with the existing PDU session(s) of the UE is not included in the requested NSSAI (i.e. Requested NSSAI IE or Requested mapped NSSAI IE) of the REGISTRATION REQUEST message, the AMF shall perform a local release of the PDU session(s) associated with the S-NSSAI(s) except for a PDU session associated with DNN and S-NSSAI in the AMF onboarding configuration data and shall request the SMF to perform a local release of those PDU session(s). 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): 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:

1. stop the timer T3526 associated with the S-NSSAI, if running;
2. start the timer T3526 with:
   1. 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
   2. an implementation specific back-off timer value, if no back-off timer value is received along with the S-NSSAI; and
3. 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:

1. 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:
   1. 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;
   2. 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
   3. 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
2. 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:
   1. 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
   2. the rejected NSSAI containing:
      1. 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; and
      2. 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.

For a REGISTRATION REQUEST message with a 5GS registration type IE indicating "mobility registration updating", if the UE does not indicate support for network slice-specific authentication and authorization, the UE is not registered for onboarding services in SNPN, and:

1. the UE is not in NB-N1 mode; and
2. if:
   1. the UE did not include the requested NSSAI in the REGISTRATION REQUEST message; or
   2. none of the S-NSSAIs in the requested NSSAI in the REGISTRATION REQUEST message are allowed;

and one or more default S-NSSAIs which are not subject to network slice-specific authentication and authorization are available, the AMF shall:

1. 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;
2. 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
3. determine a registration area such that all S-NSSAIs of the allowed NSSAI are available in the registration area.

During a registration procedure for mobility and periodic registration update for which the 5GS registration type IE indicates:

1. "periodic registration updating"; or
2. "mobility registration updating" and the UE is in NB-N1 mode;

and the UE is not registered for onboarding services in SNPN, the AMF:

1. may provide a new allowed NSSAI, a new partially allowed NSSAI, or both to the UE;
2. shall provide a pending NSSAI to the UE if the UE has indicated the support for network slice-specific authentication and authorization and there are S-NSSAIs for which network slice-specific authentication and authorization (except for re-NSSAA) will be performed or is ongoing for the current PLMN or SNPN; or
3. may provide both a new allowed NSSAI and a pending NSSAI to the UE;

in the REGISTRATION ACCEPT message. Additionally, if a pending NSSAI is provided without an allowed NSSAI and no S-NSSAI is currently allowed for the UE, the REGISTRATION ACCEPT message shall include the 5GS registration result IE with the "NSSAA to be performed" indicator set to "Network slice-specific authentication and authorization is to be performed". 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. For each of the PDU session(s) active in the UE:

1. if the allowed NSSAI contains an HPLMN S-NSSAI (e.g., mapped S-NSSAI, in roaming scenarios) matching to the HPLMN S-NSSAI of the PDU session, the UE shall locally update the S-NSSAI associated with the PDU session to the corresponding S-NSSAI received in the allowed NSSAI;
2. if the allowed NSSAI does not contain an HPLMN S-NSSAI (e.g., mapped S-NSSAI, in roaming scenarios) matching to the HPLMN S-NSSAI of the PDU session, the UE may perform a local release of the PDU session except for an emergency PDU session, if any, and except for a PDU session established when the UE is registered for onboarding services in SNPN, if any; and
3. if the partially allowed NSSAI contains an S-NSSAI associated with a PDU session, and the UE is in the TA where the S-NSSAI is not supported:
   1. the UE may initiate:
      1. the PDU session release procedure; or
      2. the PDU session modification procedure to set the 3GPP PS data off status to "deactivated" as specified in TS 24.008; and
   2. the SMF may initiate the PDU session release procedure.

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:

1. 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 Configured NSSAI IE 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;
2. an S-NSSAI location validity information IE 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 IE, the UE shall delete any stored S-NSSAI location validity information as specified in subclause 4.6.2.2;
3. 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
4. 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 any slice deregistration inactivity timer associated with an S-NSSAI which is deleted from the on-demand NSSAI.

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. 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. 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 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 REGISTRATION ACCEPT message:

1. 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";
2. includes a pending NSSAI;
3. does not include an allowed NSSAI; and
4. does not include a partially allowed NSSAI;

the UE:

1. shall not perform the registration procedure for mobility and periodic registration update with the Uplink data status IE except for emergency services;
2. shall not initiate a service request procedure except for emergency services, for emergency services fallback procedure, for responding to paging or notification over non-3GPP access, for cases f), i), m) and o) in subclause 5.6.1.1;
3. shall not initiate a 5GSM procedure except for emergency services, indicating a change of 3GPP PS data off UE status, or to request the release of a PDU session; and
4. shall not initiate the NAS transport procedure except for sending a CIoT user data container, SMS, an LPP message, a UPP-CMI container, an SLPP message, a location services message, an SOR transparent container, a UE policy container or a UE parameters update transparent container;

until the UE receives an allowed NSSAI, a partially allowed NSSAI, or both. During a registration procedure for mobility and periodic registration update for which the 5GS registration type IE indicates:

1. "mobility registration updating" and the UE is in NB-N1 mode; or
2. "periodic registration updating";

if the REGISTRATION ACCEPT message includes the 5GS registration result IE with the "NSSAA to be performed" indicator not set to "Network slice-specific authentication and authorization is to be performed" and the message does not contain an allowed NSSAI and no new allowed NSSAI, the UE shall consider the previously received allowed NSSAI as valid. During a registration procedure for mobility and periodic registration update for which the 5GS registration type IE indicates:

1. "mobility registration updating"; or
2. "periodic registration updating";

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" and the message contains a pending NSSAI, the UE shall delete any stored allowed NSSAI as specified in subclause 4.6.2.2. If the Uplink data status IE is included in the REGISTRATION REQUEST message:

1. if the AMF determines that the UE is in non-allowed area or is not in allowed area, and the PDU session(s) indicated by the Uplink data status IE is non-emergency PDU session(s) or the UE is not configured for high priority access in selected PLMN or SNPN, the AMF shall include the PDU session reactivation result IE in the REGISTRATION ACCEPT message indicating that user-plane resources for the corresponding PDU session(s) cannot be re-established, and shall include the PDU session reactivation result error cause IE with the 5GMM cause set to #28 "Restricted service area";
2. otherwise, the AMF shall:
   1. indicate the SMF to re-establish the user-plane resources for the corresponding PDU session;
   2. include PDU session reactivation result IE in the REGISTRATION ACCEPT message to indicate the user-plane resources re-establishment result of the PDU sessions for which the UE requested to re-establish the user-plane resources; and
   3. determine the UE presence in LADN service area (see subclause 6.2.6) and forward the UE presence in LADN service area towards the SMF, if the corresponding PDU session is a PDU session for LADN.

If the Uplink data status IE is not included in the REGISTRATION REQUEST message and the REGISTRATION REQUEST message is sent for the trigger d) in subclause 5.5.1.3.2, the AMF may indicate the SMF to re-establish the user-plane resources for the PDU sessions. If the registration procedure for mobility registration update is triggered for non-3GPP access path switching from the old non-3GPP access to the new non-3GPP access and there are:

1. one or more single access PDU sessions whose user plane resources are associated to the old non-3GPP access but whose PDU session ID(s) are not indicated in the Uplink data status IE in the REGISTRATION REQUEST message; or
2. one or more MA PDU sessions whose PDU session ID(s) are not indicated in the Uplink data status IE in the REGISTRATION REQUEST message;

the AMF shall not release those PDU session(s) and shall release the user plane resources of the old non-3GPP access of those PDU session(s), so that the UE or the network can re-establish user-plane resources on the new non-3GPP access by triggering a service request procedure. If a PDU session status IE is included in the REGISTRATION REQUEST message:

1. for single access PDU sessions, the AMF shall:
   1. perform a local release of all those PDU sessions which are not in 5GSM state PDU SESSION INACTIVE on the AMF side associated with the access type the REGISTRATION REQUEST message is sent over, but are indicated by the UE as being in 5GSM state PDU SESSION INACTIVE. If any of those PDU sessions is associated with one or more MBS multicast sessions, the SMF shall consider the UE as removed from the associated multicast MBS sessions; and
   2. include a PDU session status IE in the REGISTRATION ACCEPT message to indicate which PDU sessions associated with the access type the REGISTRATION ACCEPT message is sent over are not in 5GSM state PDU SESSION INACTIVE in the AMF; and
2. for MA PDU sessions:
   1. for all those PDU sessions which are not in 5GSM state PDU SESSION INACTIVE and have user plane resources being established or established on the access the REGISTRATION REQUEST message is sent over on the AMF side, but are indicated by the UE as no user plane resources are being established or established:
      1. for PDU sessions having user plane resources being established or established only on the access the REGISTRATION REQUEST message is sent over, the AMF shall perform a local release of all those PDU sessions. If the MA PDU session is associated with one or more multicast MBS sessions, the SMF shall consider the UE as removed from the associated multicast MBS sessions; and
      2. for PDU sessions having user plane resources being established or established on both accesses, the AMF shall perform a local release on the user plane resources associated with the access type the REGISTRATION REQUEST message is sent over. If the REGISTRATION REQUEST message is sent over 3GPP access and the MA PDU session is associated with one or more multicast MBS sessions, the SMF shall consider the UE as removed from the associated multicast MBS sessions; and
   2. the AMF shall include a PDU session status IE in the REGISTRATION ACCEPT message to indicate which MA PDU sessions having the corresponding user plane resources are being established or established on the AMF side on the access the REGISTRATION ACCEPT message is sent over.

If the Allowed PDU session status IE is included in the REGISTRATION REQUEST message, the AMF shall:

1. for a 5GSM message from each SMF that has indicated pending downlink signalling only, forward the received 5GSM message via 3GPP access to the UE after the REGISTRATION ACCEPT message is sent;
2. for each SMF that has indicated pending downlink data only:
   1. notify the SMF that reactivation of the user-plane resources for the corresponding PDU session(s) associated with non-3GPP access cannot be performed if the corresponding PDU session ID(s) are not indicated in the Allowed PDU session status IE; and
   2. notify the SMF that reactivation of the user-plane resources for the corresponding PDU session(s) associated with non-3GPP access can be performed if the corresponding PDU session ID(s) are indicated in the Allowed PDU session status IE.
3. for each SMF that have indicated pending downlink signalling and data:
   1. notify the SMF that reactivation of the user-plane resources for the corresponding PDU session(s) associated with non-3GPP access cannot be performed if the corresponding PDU session ID(s) are not indicated in the Allowed PDU session status IE;
   2. notify the SMF that reactivation of the user-plane resources for the corresponding PDU session(s) associated with non-3GPP access can be performed if the corresponding PDU session ID(s) are indicated in the Allowed PDU session status IE; and
   3. discard the received 5GSM message for PDU session(s) associated with non-3GPP access; and
4. include the PDU session reactivation result IE in the REGISTRATION ACCEPT message to indicate the successfully re-established user-plane resources for the corresponding PDU sessions, if any.

If the PDU session reactivation result IE is included in the REGISTRATION ACCEPT message indicating that the user-plane resources have been successfully reactivated for a PDU session that was indicated by the UE in the Allowed PDU session status IE as allowed to be re-established over 3GPP access, the UE considers the corresponding PDU session to be associated with the 3GPP access. If the user-plane resources of a PDU session have been successfully reactivated over the 3GPP access, the AMF and SMF update the associated access type of the corresponding PDU session. If the PDU session reactivation result IE is included in the REGISTRATION ACCEPT message indicating that the user-plane resources cannot be established for a PDU session that was indicated by the UE in the Allowed PDU session status IE as allowed to be re-established over 3GPP access, the UE considers the corresponding PDU session to be associated with the non-3GPP access. If an EPS bearer context status IE is included in the REGISTRATION REQUEST message, the AMF handles the received EPS bearer context status IE as specified in TS 23.502. If the EPS bearer context status information is generated for the UE during the inter-system change from S1 mode to N1 mode as specified in TS 23.502 and the AMF supports N26 interface, the AMF shall include an EPS bearer context status IE in the REGISTRATION ACCEPT message to indicate the UE which mapped EPS bearer contexts are active in the network. If the user-plane resources cannot be established for a PDU session, the AMF shall include the PDU session reactivation result IE in the REGISTRATION ACCEPT message indicating that user-plane resources for the corresponding PDU session cannot be re-established, and:

1. if the user-plane resources cannot be established because the SMF indicated to the AMF that the UE is located out of the LADN service area (see TS 29.502), the AMF shall include the PDU session reactivation result error cause IE with the 5GMM cause set to #43 "LADN not available";
2. if the user-plane resources cannot be established because the SMF indicated to the AMF that only prioritized services are allowed (see TS 29.502), the AMF shall include the PDU session reactivation result error cause IE with the 5GMM cause set to #28 "restricted service area";
3. if the user-plane resources cannot be established because the SMF indicated to the AMF that the resource is not available in the UPF (see TS 29.502), the AMF shall include the PDU session reactivation result error cause IE with the 5GMM cause set to #92 "insufficient user-plane resources for the PDU session";
4. if the user-plane resources cannot be established because the SMF indicated to the AMF that the S-NSSAI associated with the PDU session is unavailable due to NSAC (see TS 29.502), the AMF shall include the PDU session reactivation result error cause IE with the 5GMM cause set to #69 "insufficient resources for specific slice";
5. if the user-plane resources cannot be established because the AMF determines that the UE is outside the NS-AoS of an S-NSSAI, the AMF may include the PDU session reactivation result error cause IE with the 5GMM cause set to #69 "insufficient resources for specific slice" to indicate the cause of failure to re-establish the user-plane resources; or
6. otherwise, the AMF may include the PDU session reactivation result error cause IE to indicate the cause of failure to re-establish the user-plane resources.

If the AMF needs to initiate PDU session status synchronization the AMF shall include a PDU session status IE in the REGISTRATION ACCEPT message to indicate the UE:

• which single access PDU sessions associated with the access the REGISTRATION ACCEPT message is sent over are not in 5GSM state PDU SESSION INACTIVE in the AMF; and
• which MA PDU sessions are not in 5GSM state PDU SESSION INACTIVE and having user plane resources established in the AMF on the access the REGISTRATION ACCEPT message is sent over.

The AMF may include the LADN information IE in the REGISTRATION ACCEPT message as described in subclause 5.5.1.2.4. The UE, upon receiving the REGISTRATION ACCEPT message with the LADN information IE, shall delete its old LADN information (if any) and store the received new LADN information. 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, the AMF may include the Extended LADN information IE in the Registration accept type 6 IE container IE in the REGISTRATION ACCEPT message as described in subclause 5.5.1.2.4. The UE, upon receiving the REGISTRATION ACCEPT message with the Registration accept type 6 IE container IE which includes the Extended LADN information IE, shall delete its old extended LADN information (if any) and store the received new extended LADN information. 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. If the AMF does not include:

• the LADN information IE; or
• the Extended LADN information IE in the Registration accept type 6 IE container IE,

in the REGISTRATION ACCEPT message during registration procedure for mobility and periodic registration update, the UE shall delete its old LADN information or old extended LADN information respectively. If the PDU session status IE is included in the REGISTRATION ACCEPT message:

1. for single access PDU sessions, the UE shall perform a local release of all those PDU sessions associated with the access type the REGISTRATION ACCEPT message is sent over which are not in 5GSM state PDU SESSION INACTIVE or PDU SESSION ACTIVE PENDING on the UE side, but are indicated by the AMF as being in 5GSM state PDU SESSION INACTIVE. If a locally released PDU session is associated with one or more multicast MBS sessions, the UE shall locally leave the associated multicast MBS sessions; and
2. for MA PDU sessions, for all those PDU sessions which are not in 5GSM state PDU SESSION INACTIVE and have the corresponding user plane resources being established or established in the UE on the access the REGISTRATION ACCEPT message is sent over, but are indicated by the AMF as no user plane resources are being established or established:
   1. for MA PDU sessions having the corresponding user plane resources being established or established only on the access the REGISTRATION ACCEPT message is sent over, the UE shall perform a local release of those MA PDU sessions. If a locally released MA PDU session is associated with one or more multicast MBS sessions, the UE shall locally leave the associated multicast MBS sessions; and
   2. for MA PDU sessions having user plane resources being established or established on both accesses, the UE shall perform a local release on the user plane resources on the access the REGISTRATION ACCEPT message is sent over. If the user plane resources over 3GPP access are released and the MA PDU session is associated with one or more multicast MBS sessions, the UE shall locally leave the associated multicast MBS sessions.

If:

1. the UE included a PDU session status IE in the REGISTRATION REQUEST message;
2. the UE is operating in the single-registration mode;
3. the UE is performing inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode; and
4. the UE has received the IWK N26 bit set to "interworking without N26 interface supported";

the UE shall ignore the PDU session status IE if received in the REGISTRATION ACCEPT message. If the EPS bearer context status IE is included in the REGISTRATION ACCEPT message, the UE shall locally delete all those QoS flow descriptions and all associated QoS rules, if any, which are associated with inactive EPS bearer contexts as indicated by the AMF in the EPS bearer context status IE. 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:

1. "interworking without N26 interface not supported" if the AMF supports N26 interface; or
2. "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 inter-system interworking with EPS as follows:

1. 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;
2. 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
3. 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 inter-system change 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, Emergency services support indicator and 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. When initiating an emergency call, the upper layers take the IMS voice over PS session indicator, Emergency services support indicator and Emergency services fallback indicator into account for the access domain selection. When the UE determines via the IMS voice over PS session indicator that the network does not support IMS voice over PS sessions in N1 mode, then the UE shall not perform a local release of any persistent PDU session if the AMF does not indicate that the PDU session is in 5GSM state PDU SESSION INACTIVE via the PDU session status IE. When the UE determines via the Emergency services support indicator that the network does not support emergency services in N1 mode, then the UE shall not perform a local release of any emergency PDU session if user-plane resources associated with that emergency PDU session are established if the AMF does not indicate that the PDU session is in 5GSM state PDU SESSION INACTIVE via the PDU session status IE. In a UE with LCS capability, location services indicators (5G-LCS) shall be provided to the upper layers. 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. If a locally released MA PDU session is associated with one or more multicast MBS sessions, the UE shall locally leave the associated multicast MBS sessions. 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:

1. "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;
2. "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;
3. "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
4. "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.

If the UE indicates support for restriction on use of enhanced coverage in the REGISTRATION REQUEST message and:

1. 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";
2. 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
3. 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. 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)

  during ongoing active PDU sessions that were set up relying on the MPS indicator bit being set to "Access identity 1 valid", if the network indicates in a registration update that the MPS indicator bit is reset to "Access identity 1 not valid", then the UE shall no longer act as a UE with access identity 1 configured for MPS as described in subclause 4.5.2 unless the USIM contains a valid configuration for access identity 1 in RPLMN or equivalent PLMN. In the UE, the ongoing active PDU sessions are not affected by the change of the MPS indicator bit;

  d)

  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;

  e)

  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;

  e1)

  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; and

  f)

  during ongoing active PDU sessions that were set up relying on the MCS indicator bit being set to "Access identity 2 valid", if the network indicates in a registration update that the MCS indicator bit is reset to "Access identity 2 not valid", then the UE shall no longer act as a UE with access identity 2 configured for MCS as described in subclause 4.5.2 unless the USIM contains a valid configuration for access identity 2 in RPLMN or equivalent PLMN. In the UE, the ongoing active PDU sessions are not affected by the change of the MCS indicator bit; 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)

  during ongoing active PDU sessions that were set up relying on the MPS indicator bit being set to "Access identity 1 valid", if the network indicates in a registration update that the MPS indicator bit is reset to "Access identity 1 not valid", then the UE shall no longer act as a UE with access identity 1 configured for MPS as described in subclause 4.5.2A unless the unified access control configuration in the "list of subscriber data" stored in the ME (see TS 23.122) indicates the UE is configured for access identity 1 in the RSNPN or equivalent SNPN. In the UE, the ongoing active PDU sessions are not affected by the change of the MPS indicator bit;

  d)

  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;

  e)

  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;

  e1)

  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; and

  f)

  during ongoing active PDU sessions that were set up relying on the MCS indicator bit being set to "Access identity 2 valid", if the network indicates in a registration update that the MCS indicator bit is reset to "Access identity 2 not valid", then the UE shall no longer act as a UE with access identity 2 configured for MCS as described in subclause 4.5.2A unless the unified access control configuration in the "list of subscriber data" stored in the ME (see TS 23.122) indicates the UE is configured for access identity 2 in the RSNPN or equivalent SNPN. In the UE, the ongoing active PDU sessions are not affected by the change of the MCS indicator bit.

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 V2X communication over PC5 reference point based on:

1. 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:
   1. the V2XCEPC5 bit to "V2X communication over E-UTRA-PC5 supported"; or
   2. the V2XCNPC5 bit to "V2X communication over NR-PC5 supported"; and
2. 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 A2X communication over PC5 reference point based on:

1. 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:
   1. the A2XEPC5 bit to "A2X over E-UTRA-PC5 supported"; or
   2. the A2XNPC5 bit to "A2X over NR-PC5 supported"; and
2. 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 5G ProSe services based on:

1. 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:
   1. the 5G ProSe direct discovery bit to "5G ProSe direct discovery supported"; or
   2. the 5G ProSe direct communication bit to "5G ProSe direct communication supported"; and
2. 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 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 included the Non-3GPP path switching information IE in the REGISTRATION REQUEST message with the NSONR bit set to "non-3GPP path switching while using old non-3GPP resources requested" and the AMF supports non-3GPP path switching while using old non-3GPP resources, the AMF shall not release the user plane resources of the old non-3GPP access of the MA PDU session(s) and whose PDU session ID(s) are included in the Uplink data status IE of the REGISTRATION REQUEST message until the user plane resources of the new non-3GPP access are established. Otherwise, the AMF shall release the user plane resources of the old non-3GPP access before proceeding with the registration procedure. If the UE has triggered the registration procedure for mobility registration update for non-3GPP access path switching from the old non-3GPP access to the new non-3GPP access and the UE receives the REGISTRATION ACCEPT message over the new non-3GPP access, the UE shall consider itself as de-registered for 5GS services over the old non-3GPP access. 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 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 shall include the Negotiated NB-N1 mode DRX parameters IE in the REGISTRATION ACCEPT message. 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 network cannot derive the UE's identity from the 5G-GUTI because of e.g. no matching identity/context in the network, failure to validate the UE's identity due to integrity check failure of the received message, the AMF may operate as described in subclause 5.5.1.2.4 and include a PDU session status IE indicating all PDU sessions are in 5GSM state PDU SESSION INACTIVE in the AMF. If the UE included in the REGISTRATION REQUEST message the UE status IE with the EMM registration status set to "UE is in EMM-REGISTERED state" and the AMF does not support N26 interface, the AMF shall operate as described in subclause 5.5.1.2.4. If the UE has indicated support for service gap control in the REGISTRATION REQUEST message, a service gap time value is available in the 5GMM context, the AMF may include the T3447 value IE set to the service gap time value in the REGISTRATION ACCEPT message. 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. 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 does not have an active emergency PDU session, 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 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 sets 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. If the UE sets the Unavailability type to "unavailability due to UE reasons" in the Unavailability information IE in the REGISTRATION REQUEST message, then the AMF shall: If the UE sets the Unavailability type to "unavailability due to discontinuous coverage" in the Unavailability information IE and the UE provides the Unavailability information IE in the REGISTRATION REQUEST message then: The AMF may determine the periodic registration update timer value based on the stored value of the received unavailability period duration if any, the received Start of unavailability period if any, the network determined unavailability period duration if any and the network determined Start of unavailability period if any. If the UE does not provide the Unavailability information IE in the REGISTRATION REQUEST message, the AMF shall delete any stored value of the Unavailability information IE if exists. If the UE receives the Unavailability configuration IE with a value of the unavailability period duration in the REGISTRATION ACCEPT message, then the UE may either:

1. delete a UE determined value and start using the received value; or
2. 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:

1. delete a UE determined value and start using the received value; or
2. use a UE determined value.

If due to regional subscription restrictions or access restrictions the UE is not allowed to access the TA or due to CAG restrictions the UE is not allowed to access the cell, but the UE has an emergency PDU session established, the AMF may accept the REGISTRATION REQUEST message and indicate to the SMF to perform a local release of all non-emergency PDU sessions (associated with 3GPP access if it is due to CAG restrictions) and informs the UE via the PDU session status IE in the REGISTRATION ACCEPT message. The AMF shall not indicate to the SMF to release the emergency PDU session. If the AMF indicated to the SMF to perform a local release of all non-emergency PDU sessions (associated with 3GPP access if it is due to CAG restrictions), the network shall behave as if the UE is registered for emergency services and shall set the emergency registered bit of the 5GS registration result IE to "Registered for emergency services" in the REGISTRATION ACCEPT message. If the REGISTRATION ACCEPT message includes the PDU session reactivation result error cause IE with the 5GMM cause set to #28 "Restricted service area", the UE shall enter the state 5GMM-REGISTERED.NON-ALLOWED-SERVICE and behave as specified in subclause 5.3.5. If the REGISTRATION ACCEPT message includes the SOR transparent container IE and:

1. the SOR transparent container IE does not successfully pass the integrity check (see TS 33.501); and
2. if the UE attempts obtaining service on another PLMNs or SNPNs as specified in TS 23.122 Annex C;

then the UE shall release locally the established NAS signalling connection after sending a REGISTRATION COMPLETE message. 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:

1. the UE shall proceed with the behaviour as specified in TS 23.122 Annex C; and
2. 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.122 Annex C then the UE may release locally the established 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:

1. the SOR transparent container IE indicates a list of preferred PLMN/access technology combinations is provided and the list type indicates "PLMN ID and access technology list", 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.122 Annex C.
   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;
2. the list type indicates "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; or
3. 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;

and the UE shall proceed with the behaviour as specified in TS 23.122 Annex 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:

1. 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
2. otherwise:
   1. 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;
   2. 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:
      1. 3GPP access, the UE shall operate in NSSAI inclusion mode D in the current PLMN and the current access type;
      2. untrusted non-3GPP access, the UE shall operate in NSSAI inclusion mode C in the current PLMN and the current access type; or
      3. trusted non-3GPP access, the UE shall operate in NSSAI inclusion mode D in the current PLMN and the current access type; or
      4. 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 there is a running T3447 timer in the AMF and the Uplink data status IE is included or the Follow-on request indicator is set to "Follow-on request pending" in the REGISTRATION REQUEST message, the AMF shall ignore the Uplink data status IE or that the Follow-on request indicator is set to "Follow-on request pending" and proceed as if the Uplink data status IE was not received or the Follow-on request indicator was not set to "Follow-on request pending" except for the following case:

• the PDU session indicated by the Uplink data status IE is emergency PDU session;
• the UE is configured for high priority access in selected PLMN;
• the REGISTRATION REQUEST message is as a paging response; or
• the UE is establishing an emergency PDU session or performing emergency services fallback.

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

1. 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 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
2. a UE radio capability ID IE, the UE shall store the UE radio capability ID as specified in Annex C.

If the registration procedure for mobility and periodic registration update was initiated and there is a request from the upper layers to perform "emergency services fallback" pending, the UE shall restart the service request procedure after the successful completion of the mobility and periodic registration update. When AMF re-allocation occurs in the registration procedure for mobility and periodic registration update, if the new AMF receives in the 5GMM context of the UE the indication that the UE is registered for onboarding services in SNPN, the new AMF may start an implementation specific timer for onboarding services when the registration procedure for mobility and periodic registration update is successfully completed. 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 UE is registered for onboarding services in SNPN 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, if not running already, 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 stored included in the Disaster return wait range IE in the ME. If the 5GS registration type IE is set to "disaster roaming mobility registration updating" and:

1. 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;
2. 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, the AMF shall determine the PLMN with disaster condition in the PLMN identity of the 5G-GUTI;
3. the UE determined PLMN with disaster condition IE and the Additional GUTI IE are not included in the REGISTRATION REQUEST message and:
   1. the 5GS mobile identity IE contains 5G-GUTI of a PLMN of the country of the PLMN providing disaster roaming, the AMF shall determine the PLMN with disaster condition in the PLMN identity of the 5G-GUTI; or
   2. the 5GS mobile identity IE contains SUCI of a PLMN of the country of the PLMN providing disaster roaming, the AMF shall determine the PLMN with disaster condition in the PLMN identity of the SUCI; or
4. the UE determined PLMN with disaster condition IE is not included in the REGISTRATION REQUEST message, NG-RAN of the PLMN providing disaster roaming 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; 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;
   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 service accepted as registration not for disaster roaming service" in the REGISTRATION ACCEPT message. If the UE indicates "disaster roaming mobility registration updating" 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.

If the UE receives the Forbidden TAI(s) for the list of "5GS forbidden tracking areas for roaming" IE in the REGISTRATION ACCEPT message and the TAI(s) included in the IE is not part of the list of "5GS forbidden tracking areas for roaming", 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 into the list of "5GS forbidden tracking areas for roaming" and remove the TAI(s) from the stored TAI list if present. 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 and the TAI(s) included in the IE is not part of the list of "5GS forbidden tracking areas for regional provision of service", 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 into the list of "5GS forbidden tracking areas for regional provision of service" and remove the TAI(s) from the stored TAI list if present. If the ESI bit of the 5GMM capability IE of the REGISTRATION REQUEST message is set to "equivalent SNPNs supported", and the serving SNPN changes, the AMF shall indicate the NID of the serving SNPN in the REGISTRATION ACCEPT message. The UE shall determine the SNPN identity of the RSNPN from the NID received in the REGISTRATION ACCEPT message and the MCC and the MNC of the new 5G-GUTI. 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 maximum time offset value on the same satellite NG-RAN RAT type and PLMN with the latest received timer value. If the AMF includes Unavailability configuration IE in the REGISTRATION ACCEPT message and sets the EUPR bit 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 does not receive the Unavailability configuration IE or the EUPR bit is set to "UE needs to report end of unavailability period", the UE should trigger registration procedure for mobility registration update when the unavailability period duration has ended. If the UE has stored a discontinuous coverage maximum time offset timer value, upon returning to satellite coverage after being out of satellite coverage due to discontinuous coverage, the UE starts a timer with a random value up to the discontinuous coverage maximum time offset value and the UE should trigger the registration procedure for mobility registration update at the expiry of this timer. 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.