Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 24.501  Word version:  17.5.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.4…   4.4.3…   4.5…   4.5.3…   4.6…   4.7…   4.9…   4.15…   5…   5.2…   5.3…   5.3.2…   5.3.7…   5.3.19…   5.4…   5.4.1.3…   5.4.2…   5.4.4…   5.4.5…   5.4.6…   5.5…   5.5.1.2.4   5.5.1.2.5…   5.5.1.3…   5.5.1.3.4   5.5.1.3.5…   5.5.2…   5.6…   5.6.2…   6…   6.1.4…   6.2…   6.3…   6.3.2…   6.3.3…   6.4…   6.4.1.4…   6.4.2…   6.5…   7…   8…   8.2.9…   8.3…   9…   9.11.2…   9.11.2.10…   9.11.3…   9.11.3.4…   9.11.3.8…   9.11.3.14…   9.11.3.18C…   9.11.3.29…   9.11.3.33…   9.11.3.39…   9.11.3.45…   9.11.3.50…   9.11.3.53A…   9.11.3.68…   9.11.3.75…   9.11.4…   9.11.4.10…   9.11.4.13…   9.11.4.16…   9.11.4.30…   9.12   10…   A…   B…   C…   D…   D.6…   D.6.3…

 

5.5.1.3.4  Mobility and periodic registration update accepted by the networkWord‑p. 322
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 in the REGISTRATION ACCEPT message.
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 or the 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 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.
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.
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 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.
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 indicates support of the reject paging request in the REGISTRATION REQUEST message and the network decides to accept the reject paging request, then the AMF shall set the reject paging request bit to "reject paging request supported" in the 5GS network feature support IE of the REGISTRATION ACCEPT message.
If the UE indicates support of the paging restriction in the REGISTRATION REQUEST message, and the AMF sets:
  • the reject paging request bit to "reject paging request supported";
  • the N1 NAS signalling connection release bit to "N1 NAS signalling connection release supported"; or
  • both of them;
in the 5GS network feature support IE of the REGISTRATION ACCEPT message, and the network decides to accept the paging restriction, then the AMF shall set the paging restriction bit to "paging restriction supported" in the 5GS network feature support IE of the REGISTRATION ACCEPT message.
If the UE supporting MUSIM does not include the Paging restriction IE in the REGISTRATION REQUEST message, the AMF shall delete any stored paging restrictions for the UE and stop restricting paging.
If the UE supporting MUSIM 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 restrictions of the UE and enforce these restrictions in the paging procedure as described in clause 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 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 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.
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 the Network slicing indication IE with the Network slicing subscription change indication set to "Network slicing subscription changed", or contains a configured NSSAI IE with a new configured NSSAI for the current PLMN and optionally the mapped S-NSSAI(s) for the configured NSSAI for the current PLMN, the UE shall return a REGISTRATION COMPLETE message to the AMF to acknowledge the successful update of the network slicing information.
If the REGISTRATION ACCEPT message contains the 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 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 when the UE receives the 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 in a serving PLMN other than the HPLMN or EHPLMN and the 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 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, the entry for the registered PLMN in the received "CAG information list" does not include any of the CAG-ID(s) supported by the current CAG cell, 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 the entry for the registered PLMN in the received "CAG information list" includes one or more CAG-IDs, 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 the entry for the registered PLMN in the received "CAG information list" does not include any CAG-ID 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 the "allowed CAG list" for the registered PLMN in the received "CAG information list" includes one or more CAG-IDs, 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 the entry for the registered PLMN in the received "CAG information list" does not include any CAG-ID 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 or the Extended emergency number list IE or the 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 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, 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 IE value indicates:
  1. "3GPP access", the UE:
    • shall consider itself as being registered to 3GPP access only; and
    • if in 5GMM-REGISTERED state over non-3GPP access and on the same PLMN 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;
  2. "Non-3GPP access", the UE:
    • shall consider itself as being registered to non-3GPP access only; and
    • if in the 5GMM-REGISTERED state over 3GPP access and is on the same PLMN 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 5GS registration result IE value 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.
The AMF shall include the allowed NSSAI for the current PLMN 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 if available, in the REGISTRATION ACCEPT message if the UE included the requested NSSAI in the REGISTRATION REQUEST message and the AMF allows one or more S-NSSAIs for the current PLMN in the Requested NSSAI IE or one or more mapped S-NSSAIs in the Requested NSSAI IE or Requested mapped NSSAI IE. 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 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:
  1. the allowed NSSAI containing the S-NSSAI(s) or the mapped S-NSSAI(s), if any:
    1. which are not subject to network slice-specific authentication and authorization and are allowed by the AMF; or
    2. for which the network slice-specific authentication and authorization has been successfully performed;
  2. optionally, the rejected NSSAI;
  3. pending NSSAI containing one or more S-NSSAIs for which network slice-specific authentication and authorization (except for re-NSSAA) will be performed or is ongoing, and one or more S-NSSAIs from the pending NSSAI which the AMF provided to the UE during the previous registration procedure for which network slice-specific authentication and authorization will be performed or is ongoing, if any; and
  4. the "NSSAA to be performed" indicator in the 5GS registration result IE set to indicate that the network slice-specific authentication and authorization procedure will be performed by the network, if the allowed NSSAI is not included in the REGISTRATION ACCEPT message.
If the 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 subscribed S-NSSAIs marked as default 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 subscribed S-NSSAIs marked as default,
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 subscribed S-NSSAIs marked as default 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 subscribed S-NSSAIs marked as default 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 subscribed S-NSSAIs marked as default;
the AMF shall in the REGISTRATION ACCEPT message include:
  1. pending NSSAI containing one or more subscribed S-NSSAIs marked as default 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 each of which corresponds to a subscribed S-NSSAI marked as default 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 subscribed S-NSSAIs marked as default, 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.
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 subscribed S-NSSAI(s) marked as default subject to NSAC.
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.
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.
The AMF may include a new configured NSSAI for the current PLMN in the REGISTRATION ACCEPT message if:
a)
the REGISTRATION REQUEST message did not include a requested NSSAI and the UE is not registered for onboarding services in SNPN;
b)
the REGISTRATION REQUEST message included a requested NSSAI containing an S-NSSAI that is not valid in the serving PLMN;
c)
the REGISTRATION REQUEST message included a requested NSSAI containing an S-NSSAI with incorrect d) the REGISTRATION REQUEST message included the Network slicing indication IE with the Default configured NSSAI indication bit set to "Requested NSSAI created from default configured NSSAI";
e)
the REGISTRATION REQUEST message included the requested mapped NSSAI; or
f)
any two S-NSSAIs of the requested NSSAI in the REGISTRATION REQUEST message are not associated with any common NSSRG value.
If a new configured NSSAI for the current PLMN is included, the AMF shall also include the mapped S-NSSAI(s) for the configured NSSAI for the current PLMN if available 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 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 subscribed S-NSSAI(s) marked as default.
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 or SNPN and its equivalent PLMN(s), if existing, as specified in subclause 4.6.2.2.
The UE receiving the rejected NSSAI in the REGISTRATION ACCEPT message takes the following actions based on the rejection cause in the rejected S-NSSAI(s):
"S-NSSAI not available in the current PLMN or SNPN"
The UE shall add the rejected S-NSSAI(s) in the rejected NSSAI for the current PLMN as specified in subclause 4.6.2.2 and shall not attempt to use this S-NSSAI(s) in the current PLMN until switching off the UE, the UICC containing the USIM is removed, the entry of the "list of subscriber data" with the SNPN identity of the current SNPN is updated, or the rejected S-NSSAI(s) are removed or deleted as described in subclause 4.6.2.2.
"S-NSSAI not available in the current registration area"
The UE shall add the rejected S-NSSAI(s) in the rejected NSSAI for the current registration area as specified in subclause 4.6.2.2 and shall not attempt to use this S-NSSAI(s) in the current registration area until switching off the UE, the UE moving out of the current registration area, the UICC containing the USIM is removed, the entry of the "list of subscriber data" with the SNPN identity of the current SNPN is updated, or the rejected S-NSSAI(s) are removed or deleted as described in subclause 4.6.2.2.
"S-NSSAI not available due to the failed or revoked network slice-specific authentication and authorization"
The UE shall store the rejected S-NSSAI(s) in the rejected NSSAI for the failed or revoked NSSAA as specified in subclause 4.6.2.2 and shall not attempt to use this S-NSSAI in the current PLMN over any access until switching off the UE, the UICC containing the USIM is removed, the entry of the "list of subscriber data" with the SNPN identity of the current SNPN is updated, or the rejected S-NSSAI(s) are removed or deleted as described in subclause 4.6.1 and 4.6.2.2.
"S-NSSAI not available due to maximum number of UEs reached"
Unless the back-off timer value received along with the S-NSSAI is zero, the UE shall add the rejected S-NSSAI(s) in the rejected NSSAI for the maximum number of UEs reached as specified in subclause 4.6.2.2 and shall not attempt to use this S-NSSAI in the current PLMN over the current access until switching off the UE, the UICC containing the USIM is removed, the entry of the "list of subscriber data" with the SNPN identity of the current SNPN is updated, or the rejected S-NSSAI(s) are removed as described in subclause 4.6.2.2.
If there is one or more S-NSSAIs in the rejected NSSAI with the rejection cause "S-NSSAI not available due to maximum number of UEs reached", then for each S-NSSAI, the UE shall behave as follows:
  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 subscribed S-NSSAIs (containing one or more S-NSSAIs each of which may be associated with a new S-NSSAI) marked as default 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 containing S-NSSAI(s) for the current PLMN each of which corresponds to a subscribed S-NSSAI marked as default which are not subject to network slice-specific authentication and authorization;
    2. the allowed NSSAI containing the subscribed S-NSSAIs marked as default, 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 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 subscribed S-NSSAIs marked as default 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 each of which corresponds to a subscribed S-NSSAI marked as default and not subject to network slice-specific authentication and authorization in the allowed NSSAI of the REGISTRATION ACCEPT message;
  2. put the subscribed S-NSSAIs marked as default 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 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 except for the current PLMN as specified in subclause 4.6.2.2.
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 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.
With respect to each of the PDU session(s) active in the UE, if the allowed NSSAI contains neither:
  1. an S-NSSAI matching to the S-NSSAI of the PDU session; nor
  2. a mapped S-NSSAI matching to the mapped S-NSSAI of the PDU session;
the UE shall perform a local release of all such PDU sessions 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.
For each of the PDU session(s) active in the UE, if the allowed NSSAI contains a mapped S-NSSAI matching to the mapped 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.
If the REGISTRATION ACCEPT message contains a configured NSSAI IE with a new configured NSSAI for the current PLMN and optionally the mapped S-NSSAI(s) for the configured NSSAI for the current PLMN, the UE shall store the contents of the configured NSSAI IE as specified in subclause 4.6.2.2. In addition, if the REGISTRATION ACCEPT message contains an NSSRG information IE, the UE shall store the contents of the NSSRG information IE as specified in subclause 4.6.2.2.
If the 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; and
  3. does not include an allowed NSSAI;
the UE:
  1. shall not perform the registration procedure for mobility and 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 responding to paging or notification over non-3GPP access, for cases f), i) 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 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.
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, 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 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 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; 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 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 established:
      1. for PDU sessions having user plane resources established only on the access the REGISTRATION REQUEST message is sent over, the AMF shall perform a local release of all those PDU sessions; and
      2. for PDU sessions having user plane resources 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; and
    2. the AMF shall include a PDU session status IE in the REGISTRATION ACCEPT message to indicate which MA PDU sessions having user plane resources 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 requested by the UE in the Allowed PDU session status IE, 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 requested by the UE in the Allowed PDU session status IE, 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"; or
  4. 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 AMF does not include the LADN information IE in the REGISTRATION ACCEPT message during registration procedure for mobility and registration update, the UE shall delete its old LADN information.
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; and
  2. for MA PDU sessions, for all those PDU sessions which are not in 5GSM state PDU SESSION INACTIVE or PDU SESSION ACTIVE PENDING and have user plane resources 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 established:
    1. for MA PDU sessions having user plane resources established only on the access the REGISTRATION ACCEPT message is sent over, the UE shall perform a local release of those MA PDU sessions; and
    2. for MA PDU sessions having user plane resources 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:
  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 inter-system change 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 treat the received interworking without N26 interface indicator for inter-system change with EPS 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 and ATSSS, 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. 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.
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 is not operating in SNPN access operation mode:
  1. 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;
  2. upon receiving a REGISTRATION ACCEPT message with the MPS indicator bit set to "Access identity 1 valid", 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 until the UE receives a REGISTRATION ACCEPT message with the MPS indicator bit set to "Access identity 1 not valid" or until the UE selects a non-equivalent PLMN. Access identity 1 is only applicable while the UE is in N1 mode;
  3. 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;
  4. 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;
  5. upon receiving a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 valid", 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 until the UE receives a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 not valid" or until the UE selects a non-equivalent PLMN. Access identity 2 is only applicable while the UE is in N1 mode; and
  6. 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.
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.
If the UE is operating in SNPN access operation mode:
  1. the network informs the UE that the use of access identity 1 is valid in the RSNPN 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;
  2. upon receiving a REGISTRATION ACCEPT message with the MPS indicator bit set to "Access identity 1 valid", 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. The MPS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid until the UE receives a REGISTRATION ACCEPT message with the MPS indicator bit set to "Access identity 1 not valid" or until the UE selects another SNPN. Access identity 1 is only applicable while the UE is in N1 mode;
  3. 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. In the UE, the ongoing active PDU sessions are not affected by the change of the MPS indicator bit;
  4. the network informs the UE that the use of access identity 2 is valid in the RSNPN 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;
  5. upon receiving a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 valid", 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. The MCS indicator bit in the 5GS network feature support IE provided in the REGISTRATION ACCEPT message is valid until the UE receives a REGISTRATION ACCEPT message with the MCS indicator bit set to "Access identity 2 not valid" or until the UE selects another SNPN. Access identity 2 is only applicable while the UE is in N1 mode; and
  6. 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. 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 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 ProSe direct discovery bit to " ProSe direct discovery supported"; or
    2. the ProSe direct communication bit to "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 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. The AMF may set the Negotiated DRX parameters IE based on the received Requested DRX parameters IE and operator policy if available.
If the Requested NB-N1 mode DRX parameters IE was included in the REGISTRATION REQUEST message, the AMF shall include the Negotiated NB-N1 mode DRX parameters IE in the REGISTRATION ACCEPT message. 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, and the user's subscription context obtained from the UDM if available.
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 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.
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 5GS registration result IE value 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".
If the SOR transparent container IE successfully passes the integrity check (see TS 33.501) , and:
  1. the Payload 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 Payload 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.
    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 or SNPN and its equivalent PLMN(s), if any, 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(s) indicated by the Uplink data status IE is emergency PDU session(s);
  • 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, 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 in SNPN 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 IE, 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 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 PLMN with disaster condition IE is included in the REGISTRATION REQUEST message, the AMF shall determine the PLMN with disaster condition in the PLMN with disaster condition IE;
  2. the 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, the AMF shall determine the PLMN with disaster condition in the PLMN identity of the 5G-GUTI; or
  3. the 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, 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, the AMF shall determine the PLMN with disaster condition in the PLMN identity of the SUCI.
Up

Up   Top   ToC