Section: 5.5.1.3.2 Mobility and periodic registration update initiation
Content: The UE in state 5GMM-REGISTERED shall initiate the registration procedure for mobility and periodic registration update by sending a REGISTRATION REQUEST message to the AMF, a) when the UE detects that the current TAI is not in the list of tracking areas that the UE previously registered in the AMF; b) when the periodic registration updating timer T3512 expires in 5GMM-IDLE mode and the UE is not registered for emergency services (see subclause 5.3.7); c) when the UE receives a CONFIGURATION UPDATE COMMAND message indicating "registration requested" in the Registration requested bit of the Configuration update indication IE as specified in subclauses 5.4.4.3; d) when the UE in state 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE either receives a paging or the UE receives a NOTIFICATION message with access type indicating 3GPP access over the non-3GPP access for PDU sessions associated with 3GPP access; NOTE 1: As an implementation option, MUSIM UE is allowed to not respond to paging based on the information available in the paging message, e.g. voice service indication. e) upon inter-system change from S1 mode to N1 mode and if the UE previously had initiated an attach procedure or a tracking area updating procedure when in S1 mode; f) when the UE receives an indication of "RRC Connection failure" from the lower layers and does not have signalling pending (i.e. when the lower layer requests NAS signalling connection recovery) except for the case specified in subclause 5.3.1.4; g) when the UE changes the 5GMM capability or the S1 UE network capability or both; h) when the UE's usage setting changes; i) when the UE needs to change the slice(s) it is currently registered to; j) when the UE changes the UE specific DRX parameters; k) when the UE in state 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE receives a request from the upper layers to establish an emergency PDU session or perform emergency services fallback; l) when the UE needs to register for SMS over NAS, indicate a change in the requirements to use SMS over NAS, or de-register from SMS over NAS; m) when the UE needs to indicate PDU session status to the network after performing a local release of PDU session(s) as specified in subclauses 6.4.1.5 and 6.4.3.5; n) when the UE in 5GMM-IDLE mode changes the radio capability for NG-RAN or E-UTRAN; o) when the UE receives a fallback indication from the lower layers and does not have signalling pending, see subclauses 5.3.1.4 and 5.3.1.2); p) void; q) when the UE needs to request new LADN information; r) when the UE needs to request the use of MICO mode or needs to stop the use of MICO mode or to request the use of new T3324 value or new T3512 value; s) when the UE in 5GMM-CONNECTED mode with RRC inactive indication enters a cell in the current registration area belonging to an equivalent PLMN of the registered PLMN and not belonging to the registered PLMN; t) when the UE receives over 3GPP access a SERVICE REJECT message or a DL NAS TRANSPORT message, with the 5GMM cause value set to #28 "Restricted service area"; u) when the UE needs to request the use of eDRX, when a change in the eDRX usage conditions at the UE requires different extended DRX parameters, or needs to stop the use of eDRX; NOTE 2: A change in the eDRX usage conditions at the UE can include e.g. a change in the UE configuration, a change in requirements from upper layers or the battery running low at the UE. v) when the UE supporting 5G-SRVCC from NG-RAN to UTRAN changes the mobile station classmark 2 or the supported codecs; w) when the UE in state 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE decides to request new network slices after being rejected due to no allowed network slices requested, or request S-NSSAI(s) which have been removed from the rejected NSSAI for the maximum number of UEs reached; x) when the UE is not in NB-N1 mode and the UE has received a UE radio capability ID deletion indication IE set to "Network-assigned UE radio capability IDs deletion requested”; y) when the UE receives a REGISTRATION REJECT message with 5GMM cause values #3, #6 or #7 without integrity protection over another access; z) when the UE needs to request new ciphering keys for ciphered broadcast assistance data; za) when due to manual CAG selection the UE has selected a CAG-ID which is not a CAG-ID authorized based on the "allowed CAG list" for the selected PLMN or a CAG-ID in a PLMN for which the entry in the "CAG information list" does not exist or when the UE has selected, without selecting a CAG-ID, a PLMN for which the entry in the "CAG information list" includes an "indication that the UE is only allowed to access 5GS via CAG cells"; zb) when the UE needs to start, stop or change the conditions for using the WUS assistance information or PEIPS assistance information; zc) when the UE changes the UE specific DRX parameters in NB-N1 mode; zd) when the UE in 5GMM-CONNECTED mode with RRC inactive indication enters a new cell with different RAT in current TAI list or not in current TAI list; ze) when the UE enters state 5GMM-REGISTERED.NORMAL-SERVICE or 5GMM-REGISTERED.NON-ALLOWED-SERVICE (as described in subclause 5.3.5.2) over 3GPP access after the UE has sent a NOTIFICATION RESPONSE message over non-3GPP access in response to reception of a NOTIFICATION message over non-3GPP access as specified in subclause 5.6.3.1; zf) when the UE supporting UAS services is not registered for UAS services and needs to register to the 5GS for UAS services; zg) when the UE supporting MINT needs to perform the registration procedure for mobility and periodic registration update to register to the PLMN offering disaster roaming; zh) when the MUSIM UE supporting the paging timing collision control needs to request a new 5G-GUTI assignment and the UE is not registered for emergency services; NOTE 3: Based on implementation, the MUSIM UE can request a new 5G-GUTI assignment (e.g. when the lower layers request to modify the timing of the paging occasions). zi) when the network supports the paging restriction and the MUSIM UE in state 5GMM-REGISTERED.NON-ALLOWED-SERVICE needs to requests the network to remove the paging restriction; zj) when the UE changes the 5GS Preferred CIoT network behaviour or the EPS Preferred CIoT network behaviour; zk) when the UE that has entered 5GMM-REGISTERED.NO-CELL-AVAILABLE and it has one or more S-NSSAI(s) in pending NSSAI, finds a suitable cell according to 3GPP TS 38.304[ NR; User Equipment (UE) procedures in Idle mode and in RRC Inactive state ]  [28]; zl) when the UE is registered for disaster roaming services and receives a request from the upper layers to establish an emergency PDU session or perform emergency services fallback; zm1) when the UE needs to provide the unavailability information; zm2) void; NOTE 3A: How UE determines that it is about to lose satellite coverage is an implementation option. zn) when the UE needs to come out of unavailability period and resume normal services; zo) when the UE in state 5GMM-REGISTERED.ATTEMPTING-REGISTRATION-UPDATE, the UE supports the reconnection to the network due to RAN timing synchronization status change has been requested to reconnect to the network upon receiving an indication of a change in the RAN timing synchronization status (see subclauses 5.4.4.2, 5.5.1.2.4, and 5.5.1.3.4), and the UE receives an indication of a change in the RAN timing synchronization status; or zp) when the UE that supports non-3GPP access path switching needs to trigger non-3GPP access path switching from the old non-3GPP access to the new non-3GPP access that is in the same PLMN. NOTE 4: Non-3GPP access path switching from a non-3GPP access to a wireline access, or from a wireline access to a non-3GPP access, is not specified in this release of the specification. zq) if the UE moves from a tracking area for which the TAI is configured for partially rejected NSSAI to another tracking area within the registration area with aTAI for which the S-NSSAI(s) is supported and the UE still needs to request that S-NSSAI(s). NOTE 4A: The UEs that do not initiate the registration procedure for mobility and periodic registration update in the case above will not receive service for the S-NSSAI(s) that are configured to support the S-NSSAI(s) in the tracking areas supporting the S-NSSAI(s). Operators are recomended to consider the impact of such a configuration, of having partially rejected NSSAI applicable in some tracking areas within a registration area, as it requires the UE to perform mobility and periodic registration update procedure upon mobility within the same registration area. If case b) is the only reason for initiating the registration procedure for mobility and periodic registration update, the UE shall indicate "periodic registration updating" in the 5GS registration type IE; otherwise, if the UE initiates the registration procedure for mobility and periodic registration update due to case Zg), the UE shall indicate "disaster roaming mobility registration updating" in the 5GS registration type IE; otherwise the UE shall indicate "mobility registration updating". If case zl) is the reason for initiating the registration procedure for mobility and periodic registration update and if the UE supports S1 mode and the UE has not disabled its E-UTRA capability, the UE shall: - set the S1 mode bit to "S1 mode supported" in the 5GMM capability IE of the REGISTRATION REQUEST message; and - include the S1 UE network capability IE in the REGISTRATION REQUEST message; If the UE which is not registered for disaster roaming services indicates "mobility registration updating" in the 5GS registration type IE and the UE supports S1 mode and the UE has not disabled its E-UTRA capability, the UE shall: - set the S1 mode bit to "S1 mode supported" in the 5GMM capability IE of the REGISTRATION REQUEST message; - include the S1 UE network capability IE in the REGISTRATION REQUEST message additionally, if the UE supports EPS-UPIP, the UE shall set the EPS-UPIP bit to "EPS-UPIP supported" in the S1 UE network capability IE in the REGISTRATION REQUEST message; and - if the UE supports sending an ATTACH REQUEST message containing a PDN CONNECTIVITY REQUEST message with request type set to "handover" to transfer a PDU session from N1 mode to S1 mode, set the HO attach bit to "attach request message containing PDN connectivity request with request type set to handover to transfer PDU session from N1 mode to S1 mode supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the LTE positioning protocol (LPP) in N1 mode as specified in 3GPP TS 37.355[ LTE Positioning Protocol (LPP) ]  [26], the UE shall set the LPP bit to "LPP in N1 mode supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the Location Services (LCS) notification mechanisms in N1 mode as specified in 3GPP TS 23.273[ 5G System (5GS) Location Services (LCS); Stage 2 ]  [6B], the UE shall set the 5G-LCS bit to "LCS notification mechanisms supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the user plane positioning using LCS-UPP as specified in 3GPP TS 23.273[ 5G System (5GS) Location Services (LCS); Stage 2 ]  [6B], the UE shall set the LCS-UPP bit to "LCS-UPP user plane positioning supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the user plane positioning using SUPL as specified in 3GPP TS 38.305[ NG Radio Access Network (NG-RAN); Stage 2 functional specification of User Equipment (UE) positioning in NG-RAN ]  [67] and 3GPP TS 23.271[ Functional stage 2 description of Location Services (LCS) ]  [68], the UE shall set the SUPL bit to "SUPL user plane positioning supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For all cases except case b), when the UE is not in NB-N1 mode and the UE supports RACS, the UE shall set the RACS bit to "RACS supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports 5G-SRVCC from NG-RAN to UTRAN as specified in 3GPP TS 23.216[ Single Radio Voice Call Continuity (SRVCC); Stage 2 ]  [6A], the UE shall set: - the 5G-SRVCC from NG-RAN to UTRAN capability bit to "5G-SRVCC from NG-RAN to UTRAN supported" in the 5GMM capability IE of the REGISTRATION REQUEST message for all cases except case b; and - include the Mobile station classmark 2 IE and the Supported codecs IE in the REGISTRATION REQUEST message for all cases except case b. If the UE supports the restriction on use of enhanced coverage, the UE shall set the RestrictEC bit to "Restriction on use of enhanced coverage supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports network slice-specific authentication and authorization, the UE shall set the NSSAA bit to "network slice-specific authentication and authorization supported" in the 5GMM capability IE of the REGISTRATION REQUEST message for all cases except case b. If the UE supports CAG feature, the UE shall set the CAG bit to "CAG Supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports extended CAG information list, the UE shall set the Ex-CAG bit to "Extended CAG information list supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports enhanced CAG information, the UE shall set the ECI bit to "enhanced CAG information supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports sending of REGISTRATION COMPLETE message for acknowledging the reception of Negotiated PEIPS assistance inforation IE, the UE shall set the RCMAP bit to "Sending of REGISTRATION COMPLETE message for negotiated PEIPS assistance information supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE operating in the single-registration mode performs inter-system change from S1 mode to N1 mode and: a) has one or more stored UE policy sections identified by a UPSI with the PLMN ID part indicating the HPLMN or the selected PLMN, the UE shall set the Payload container type IE to "UE policy container" and include the UE STATE INDICATION message (see annex D) in the Payload container IE of the REGISTRATION REQUEST message; or b) does not have any stored UE policy section identified by a UPSI with the PLMN ID part indicating the HPLMN or the selected PLMN, and the UE needs to send a UE policy container to the network, the UE shall set the Payload container type IE to "UE policy container" and include the UE STATE INDICATION message (see annex D) in the Payload container IE of the REGISTRATION REQUEST message. NOTE 5: In this version of the protocol, the UE can only include the Payload container IE in the REGISTRATION REQUEST message to carry a payload of type "UE policy container". The UE in state 5GMM-REGISTERED shall initiate the registration procedure for mobility and periodic registration update by sending a REGISTRATION REQUEST message to the AMF when the UE needs to request the use of SMS over NAS transport or the current requirements to use SMS over NAS transport change in the UE. The UE shall set the SMS requested bit of the 5GS update type IE in the REGISTRATION REQUEST message as specified in subclause 5.5.1.2.2. When initiating a registration procedure for mobility and periodic registration update and the UE needs to send the 5GS update type IE for a reason different than indicating a change in requirement to use SMS over NAS, the UE shall set the SMS requested bit of the 5GS update type IE in the REGISTRATION REQUEST message to the same value as indicated by the UE in the last REGISTRATION REQUEST message. If the UE no longer requires the use of SMS over NAS, then the UE shall include the 5GS update type IE in the REGISTRATION REQUEST message with the SMS requested bit set to "SMS over NAS not supported". After sending the REGISTRATION REQUEST message to the AMF the UE shall start timer T3510. If timer T3502 is currently running, the UE shall stop timer T3502. If timer T3511 is currently running, the UE shall stop timer T3511. If the last visited registered TAI is available, the UE shall include the last visited registered TAI in the REGISTRATION REQUEST message. The UE shall handle the 5GS mobile identity IE in the REGISTRATION REQUEST message as follows: a) if the UE is operating in the single-registration mode, performs inter-system change from S1 mode to N1 mode, and the UE holds a valid native 4G-GUTI, the UE shall create a 5G-GUTI mapped from the valid native 4G-GUTI as specified in 3GPP TS 23.003[ Numbering, addressing and identification ]  [4] and indicate the mapped 5G-GUTI in the 5GS mobile identity IE. Additionally, if the UE holds a valid 5G-GUTI, the UE shall include the 5G-GUTI in the Additional GUTI IE in the REGISTRATION REQUEST message in the following order: 1) a valid 5G-GUTI that was previously assigned by the same PLMN with which the UE is performing the registration, if available; 2) a valid 5G-GUTI that was previously assigned by an equivalent PLMN, if available; and 3) a valid 5G-GUTI that was previously assigned by any other PLMN, if available; and NOTE 6: The 5G-GUTI included in the Additional GUTI IE is a native 5G-GUTI. b) for all other cases, if the UE holds a valid 5G-GUTI, the UE shall indicate the 5G-GUTI in the 5GS mobile identity IE. If the UE is registering with an SNPN and the valid 5G-GUTI was previously assigned by another SNPN, the UE shall additionally include the NID of the other SNPN in the NID IE. If the UE does not operate in SNPN access operation mode, holds two valid native 5G-GUTIs assigned by PLMNs and: 1) one of the valid native 5G-GUTI was assigned by the PLMN with which the UE is performing the registration, then the UE shall indicate the valid native 5G-GUTI assigned by the PLMN with which the UE is performing the registration. In addition, the UE shall include the other valid native 5G-GUTI in the Additional GUTI IE; or 2) none of the valid native 5G-GUTI was assigned by the PLMN with which the UE is performing the registration, then the UE shall indicate the valid native 5G-GUTI assigned over the same access via which the UE is performing the registration. If the UE supports MICO mode and requests the use of MICO mode, then the UE shall include the MICO indication IE in the REGISTRATION REQUEST message. If the UE requests to use an active time value, it shall include the active time value in the T3324 IE in the REGISTRATION REQUEST message. If the UE includes the T3324 IE, it may also request a particular T3512 value by including the Requested T3512 IE in the REGISTRATION REQUEST message. Additionally, if the UE supports strictly periodic registration timer, the UE shall set the Strictly Periodic Registration Timer Indication bit of the MICO indication IE in the REGISTRATION REQUEST message to "strictly periodic registration timer supported". If the UE needs to stop the use of MICO mode, then the UE shall not include the MICO indication IE in the REGISTRATION REQUEST message. If the UE needs to use or change the UE specific DRX parameters, the UE shall include the Requested DRX parameters IE in the REGISTRATION REQUEST message for all cases except case b). If the UE is in NB-N1 mode and if the UE needs to use or change the UE specific DRX parameters for NB-N1 mode, the UE shall include the Requested NB-N1 mode DRX parameters IE in the REGISTRATION REQUEST message for all cases except case b). If the UE supports eDRX and requests the use of eDRX, the UE shall include the Requested extended DRX parameters IE in the REGISTRATION REQUEST message. If the UE needs to request LADN information for specific LADN DNN(s) or indicates a request for LADN information as specified in 3GPP TS 23.501[ System architecture for the 5G System (5GS) ]  [8], the UE shall include the LADN indication IE in the REGISTRATION REQUEST message and: - request specific LADN DNNs by including a LADN DNN value in the LADN indication IE for each LADN DNN for which the UE requests LADN information; or - to indicate a request for LADN information by not including any LADN DNN value in the LADN indication IE. If the UE is initiating the registration procedure for mobility and periodic registration update, the UE may include the Uplink data status IE to indicate which PDU session(s) is: - not associated with control plane only indication; - associated with the access type the REGISTRATION REQUEST message is sent over; and - have pending user data to be sent over user plane or are associated with active multicast MBS session(s). If the UE has one or more active always-on PDU sessions associated with the access type over which the REGISTRATION REQUEST message is sent and the user-plane resources for these PDU sessions are not established, and for cases triggering the REGISTRATION REQUEST message except b), the UE shall include the Uplink data status IE and indicate that the UE has pending user data to be sent for those PDU sessions. If the UE is located outside the LADN service area and inside the registration area assigned by the network, the UE shall not include the PDU session for LADN in the Uplink data status IE. If the UE is in a non-allowed area or is not in an allowed area as specified in subclause 5.3.5, and the UE is in the registration area assigned by the network, the UE shall not include the Uplink data status IE except for emergency services or for high priority access. If the MUSIM UE requests the network to release the NAS signalling connection, the UE shall not include the Uplink data status IE in the REGISTRATION REQUEST message. If the UE has one or more active PDU sessions which are not accepted by the network as always-on PDU sessions and no uplink user data pending to be sent for those PDU sessions, the UE shall not include those PDU sessions in the Uplink data status IE in the REGISTRATION REQUEST message. When the registration procedure for mobility and periodic registration update is initiated in 5GMM-IDLE mode, the UE may include a PDU session status IE in the REGISTRATION REQUEST message, indicating: - which single access PDU sessions associated with the access type the REGISTRATION REQUEST message is sent over are not inactive in the UE; and - which MA PDU sessions are not inactive and having the corresponding user plane resources being established or established in the UE on the access the REGISTRATION REQUEST message is sent over. If the UE received a paging message with the access type indicating non-3GPP access, the UE shall include the Allowed PDU session status IE in the REGISTRATION REQUEST message. If the UE has PDU session(s) associated with non-3GPP access for which the associated S-NSSAI(s) are included in the allowed NSSAI for 3GPP access or the S-NSSAI associated with the PDU session is included in the partially allowed NSSAI for 3GPP access and the TAI where the UE is currently camped is in list of TAs for which the S-NSSAI is allowed, the UE shall indicate the PDU session(s) for which the UE allows to re-establish the user-plane resources over 3GPP access in the Allowed PDU session status IE. Otherwise, the UE shall not indicate any PDU session(s) in the Allowed PDU session status IE. If the UE is in a non-allowed area or the UE is not in an allowed area, the UE shall set the Allowed PDU session status IE as specified in subclause 5.3.5.2. When the Allowed PDU session status IE is included in the REGISTRATION REQUEST message, the UE shall indicate that a PDU session is not allowed to be transferred to the 3GPP access if the 3GPP PS data off UE status is "activated" for the corresponding PDU session and the UE is not using the PDU session to send uplink IP packets for any of the 3GPP PS data off exempt services (see subclause 6.2.10). If the UE operating in the single-registration mode performs inter-system change from S1 mode to N1 mode, the UE: a) shall include the UE status IE with the EMM registration status set to "UE is in EMM-REGISTERED state" in the REGISTRATION REQUEST message; NOTE 7: Inclusion of the UE status IE with this setting corresponds to the indication that the UE is "moving from EPC" as specified in 3GPP TS 23.502[ Procedures for the 5G System (5GS) ]  [9], subclause 4.11.1.3.3 and 4.11.2.3. NOTE 8: The value of the 5GMM registration status included by the UE in the UE status IE is not used by the AMF. b) may include the PDU session status IE in the REGISTRATION REQUEST message indicating the status of the PDU session(s) mapped during the inter-system change from S1 mode to N1 mode from the PDN connection(s) for which the EPS indicated that interworking to 5GS is supported, if any (see subclause 6.1.4.1); c) shall include a TRACKING AREA UPDATE REQUEST message as specified in 3GPP TS 24.301[ Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 ]  [15] in the EPS NAS message container IE in the REGISTRATION REQUEST message if the registration procedure is initiated in 5GMM-IDLE mode and the UE has received an "interworking without N26 interface not supported" indication from the network; c1) may include a TRACKING AREA UPDATE REQUEST message as specified in 3GPP TS 24.301[ Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 ]  [15] in the EPS NAS message container IE in the REGISTRATION REQUEST message if the registration procedure is initiated in 5GMM-IDLE mode and the UE has received an "interworking without N26 interface supported" indication from the network; and d) shall include an EPS bearer context status IE in the REGISTRATION REQUEST message indicating which EPS bearer contexts are active in the UE, if the UE has locally deactivated EPS bearer context(s) for which interworking to 5GS is supported while the UE was in S1 mode without notifying the network. For a REGISTRATION REQUEST message with a 5GS registration type IE indicating "mobility registration updating", if the UE: a) is in NB-N1 mode and: 1) the UE needs to change the slice(s) it is currently registered to within the same registration area; or 2) the UE has entered a new registration area; or b) is not in NB-N1 mode and is not registered for onboarding services in SNPN; the UE shall include the Requested NSSAI IE containing the S-NSSAI(s) corresponding to the network slices to which the UE intends to register and associated mapped S-NSSAI(s), if available, in the REGISTRATION REQUEST message as described in this subclause. When the UE is entering a visited PLMN and intends to register to the slices for which the UE has only HPLMN S-NSSAI(s) available, the UE shall include these HPLMN S-NSSAI(s) in the Requested mapped NSSAI IE This is also applicable when the UE is entering an EHPLMN whose PLMN code is not derived from the IMSI. NOTE 9: The REGISTRATION REQUEST message can include both the Requested NSSAI IE and the Requested mapped NSSAI IE as described below. If the UE is registered for onboarding services in SNPN, the UE shall not include the Requested NSSAI IE in the REGISTRATION REQUEST message. If the UE has allowed NSSAI or configured NSSAI or both for the current PLMN, the Requested NSSAI IE shall include either: a) the configured NSSAI for the current PLMN or SNPN, or a subset thereof as described below; b) the allowed NSSAI for the current PLMN or SNPN, or a subset thereof as described below; or c) the allowed NSSAI for the current PLMN or SNPN, or a subset thereof as described below, plus the configured NSSAI for the current PLMN or SNPN, or a subset thereof as described below; In addition, the Requested NSSAI IE shall include S-NSSAI(s) applicable in the current PLMN or SNPN, and if available the associated mapped S-NSSAI(s) for: a) each PDN connection that is established in S1 mode when the UE is operating in the single-registration mode and the UE is performing an inter-system change from S1 mode to N1 mode; or b) each active PDU session. If the UE does not have S-NSSAI(s) applicable in the current PLMN or SNPN, then the Requested mapped NSSAI IE shall include HPLMN S-NSSAI(s) (e.g. mapped S-NSSAI(s), if available) for: a) each PDN connection established in S1 mode when the UE is operating in the single-registration mode and the UE is performing an inter-system change from S1 mode to N1 mode to a visited PLMN; or b) each active PDU session when the UE is performing mobility from N1 mode to N1 mode to a visited PLMN. NOTE 10: The Requested NSSAI IE is used instead of Requested mapped NSSAI IE in REGISTRATION REQUEST message when the UE enters HPLMN and the EHPLMN list is not present or is empty; or when the UE enters a PLMN whose PLMN code is derived from the IMSI and the EHPLMN list is not empty. The Requested mapped NSSAI IE is used when the UE enters an EHPLMN whose PLMN code is not derived from the IMSI. For a REGISTRATION REQUEST message with a 5GS registration type IE indicating "mobility registration updating", if the UE is in NB-N1 mode and the procedure is initiated for all cases except case a), c), e), i), s), t), w), and x), the REGISTRATION REQUEST message shall not include the Requested NSSAI IE. If the UE has: - no allowed NSSAI for the current PLMN or SNPN; - no configured NSSAI for the current PLMN or SNPN; - neither active PDU session(s) nor PDN connection(s) to transfer associated with an S-NSSAI applicable in the current PLMN or SNPN; and - neither active PDU session(s) nor PDN connection(s) to transfer associated with mapped S-NSSAI(s); and has a default configured NSSAI, then the UE shall: a) include the S-NSSAI(s) in the Requested NSSAI IE of the REGISTRATION REQUEST message using the default configured NSSAI; and b) include the Network slicing indication IE with the Default configured NSSAI indication bit set to "Requested NSSAI created from default configured NSSAI" in the REGISTRATION REQUEST message. If the UE has: - no allowed NSSAI for the current PLMN or SNPN; - no configured NSSAI for the current PLMN or SNPN; - neither active PDU session(s) nor PDN connection(s) to transfer associated with an S-NSSAI applicable in the current PLMN or SNPN - neither active PDU session(s) nor PDN connection(s) to transfer associated with mapped S-NSSAI(s); and - no default configured NSSAI, the UE shall include neither Requested NSSAI IE nor Requested mapped NSSAI IE in the REGISTRATION REQUEST message. If all the S-NSSAI(s) corresponding to the slice(s) to which the UE intends to register are included in the pending NSSAI, the UE shall not include a requested NSSAI in the REGISTRATION REQUEST message. When the UE storing a pending NSSAI intends to register to additional S-NSSAI(s) over the same access type, the UE shall send the requested NSSAI containing the additional S-NSSAI(s) that the UE intends to register to in the REGISTRATION REQUEST message. The requested NSSAI shall not include any S-NSSAI from the pending NSSAI. The subset of configured NSSAI provided in the requested NSSAI consists of one or more S-NSSAIs in the configured NSSAI applicable to the current PLMN or SNPN, where any included S-NSSAI is neither in the rejected NSSAI nor associated to an S-NSSAI in the rejected NSSAI. If the UE is inside the NS-AoS of an S-NSSAI in the rejected NSSAI with a rejection cause value set to "S-NSSAI not available in the current registration area", the S-NSSAI may be included in the requested NSSAI. For case zq, the subset of configured NSSAI provided in the requested NSSAI consists of one or more S-NSSAIs in the configured NSSAI applicable to the current PLMN or SNPN, where any included S-NSSAI is in the partially rejected NSSAI and the current TAI is in the list of TAs for which the S-NSSAI is not rejected. If the UE is inside the NS-AoS of an S-NSSAI in the partially rejected NSSAI and the current TAI is in the list of TAs for which the S-NSSAI is rejected, the S-NSSAI may be included in the requested NSSAI. In addition, if the NSSRG information is available, the subset of configured NSSAI provided in the requested NSSAI shall be associated with at least one common NSSRG value. The UE may also include in the requested NSSAI included in the Requested NSSAI IE or the Requested mapped NSSAI IE or both, the S-NSSAI(s) which were added to configured NSSAI in S1 mode and for which the associated NSSRG information is not available. If the UE is in 5GMM-REGISTERED state over the other access and has already an allowed NSSAI for the other access in the same PLMN or in different PLMNs, all the S-NSSAI(s) in the requested NSSAI included in the Requested NSSAI IE or the Requested mapped NSSAI IE or both for the current access shall share at least an NSSRG value common to all the S-NSSAI(s) of the allowed NSSAI for the other access. If the UE is simultaneously performing the registration procedure on the other access in different PLMNs, the UE shall include S-NSSAIs that share at least a common NSSRG value across all access types. The S-NSSAIs in the pending NSSAI and requested NSSAI shall be associated with at least one common NSSRG value. NOTE 11: If the UE has stored mapped S-NSSAI(s) for the rejected NSSAI, and one or more S-NSSAIs in the stored mapped S-NSSAI(s) for the configured NSSAI are not included in the stored mapped S-NSSAI(s) for the rejected NSSAI, then a S-NSSAI in the configured NSSAI associated to one or more of these mapped S-NSSAI(s) for the configured NSSAI are available to be included in the requested NSSAI together with their mapped S-NSSAI. NOTE 12: If one or more mapped S-NSSAIs in the stored mapped S-NSSAI(s) for the configured NSSAI are not included in the stored rejected NSSAI for the failed or revoked NSSAA, a S-NSSAI in the configured NSSAI associated to one or more of these mapped S-NSSAI(s) for the configured NSSAI are available to be included in the registration request together with their mapped S-NSSAI. NOTE 13: There is no need to consider the case that the UE is simultaneously performing the registration procedure on the other access in the same PLMN, due to that the UE is not allowed to initiate the registration procedure over one access when the registration over the other access to the same PLMN is going on. If: a) the UE is registered to current PLMN over the other access and has NSSRG information available; b) the UE is attempting mobility registration to the same current PLMN from other PLMN in the current access; and c) the UE has PDU session(s) or PDN connection(s) associated with NSSAI not sharing part of NSSRG available of the current PLMN; then the UE locally releases these PDU session(s) or PDN connection(s), as the NSSAI for these PDU session(s) or PDN connection(s) will not be included in the requested or the requested mapped NSSAI in the current PLMN due to its lack of association to the common NSSRG of the current PLMN. The subset of allowed NSSAI provided in the requested NSSAI consists of one or more S-NSSAIs in the allowed NSSAI for this PLMN. If the UE supports the S-NSSAI time validity information, S-NSSAI time validity information is available for an S-NSSAI, and the S-NSSAI time validity information indicates that the S-NSSAI is not available, the UE shall not include the S-NSSAI in the Requested NSSAI IE of the REGISTRATION REQUEST message. If the UE has S-NSSAI time validity information over the other access in the same PLMN and the S-NSSAI time validity information indicates that the S-NSSAI is not available, the UE shall not include the S-NSSAI in the Requested NSSAI IE of the REGISTRATION REQUEST message for the current access type. NOTE 14: How the UE selects the subset of configured NSSAI or allowed NSSAI to be provided in the requested NSSAI is implementation specific. The UE can take preferences indicated by the upper layers (e.g. policies like URSP, applications) and UE local configuration into account. NOTE 15: The number of S-NSSAI(s) included in the requested NSSAI cannot exceed eight. If the UE supports NSAG, the UE shall set the NSAG bit to "NSAG supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports sending of REGISTRATION COMPLETE message for acknowledging the reception of NSAG information IE in the REGISTRATION ACCEPT message, the UE shall set the RCMAN bit to "Sending of REGISTRATION COMPLETE message for NSAG information supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the unavailability period, the UE shall set the UN-PER bit to "unavailability period supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports network slice replacement, the UE shall set the NSR bit to "network slice replacement supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For case zm1), if the network indicated support for the unavailability period in the last registration procedure and the UE is able to store its 5GMM and 5GSM contexts, the UE shall include the Unavailability information IE, set the Follow-on request indicator to "No follow-on request pending" in the REGISTRATION REQUEST message. In addition, the UE shall not include the Uplink data status IE or the Allowed PDU session status IE in the REGISTRATION REQUEST message even if the UE has one or more active always-on PDU sessions associated with the 3GPP access. If the UE includes the Unavailability information IE to indicate the type of the unavailability period and the UE will be unavailable due to NR satellite access discontinuous coverage, the UE shall set the Unavailability type bit to "unavailability due to discontinuous coverage" in the Unavailability information IE. For case zm1, the UE should initiate the registration procedure for mobility and periodic registration update only if the UE can determine, based on its implementation, that there is enough time to complete the procedure before the start of the unavailability period. NOTE 15A: If the UE is unable to store its 5GMM and 5GSM contexts, the UE triggers the de-registration procedure. Ability to store the 5GMM information for UEs not operating in SNPN access operation mode as described in Annex C.1 does not imply the ability to store the 5GMM and 5GSM contexts. NOTE 15B: If the UE is able to store its 5GMM and 5GSM contexts, the UE can store the 5GMM and 5GSM contexts even if the registration procedure for mobility and periodic registration update is not completed successfully. The UE shall set the Follow-on request indicator to "Follow-on request pending", if the UE: a) initiates the registration procedure for mobility and periodic registration update upon request of the upper layers to establish an emergency PDU session; b) initiates the registration procedure for mobility and periodic registration update upon receiving a request from the upper layers to perform emergency services fallback; or c) needs to prolong the established NAS signalling connection after the completion of the registration procedure for mobility and periodic registration update (e.g. due to uplink signalling pending but no user data pending). NOTE 16: The UE does not have to set the Follow-on request indicator to 1 even if the UE has to request resources for V2X communication over PC5 reference point, 5G ProSe direct discovery over PC5, 5G ProSe direct communication over PC5 or ranging and sidelink positioning over PC5 or A2X communication over PC5 reference point. For case n), the UE shall include the 5GS update type IE in the REGISTRATION REQUEST message with the NG-RAN-RCU bit set to "UE radio capability update needed". Additionally, if the UE is not in NB-N1 mode, the UE supports RACS and the UE has an applicable UE radio capability ID for the new UE radio configuration in the serving PLMN or SNPN, the UE shall include the applicable UE radio capability ID in the UE radio capability ID of the REGISTRATION REQUEST message. NOTE 16A: For cases n, if the UE supports RACS irrespective whether the UE has an applicable UE radio capability ID for the new UE radio configuration in the selected PLMN the 5GS update type IE in the REGISTRATION REQUEST message with the NG-RAN-RCU bit is set to "UE radio capability update needed". If the UE is in the 5GMM-CONNECTED mode and the UE changes the radio capability for NG-RAN or E-UTRAN, the UE may locally release the established N1 NAS signalling connection and enter the 5GMM-IDLE mode. Then, the UE shall initiate the registration procedure for mobility and periodic registration update including the 5GS update type IE in the REGISTRATION REQUEST message with the NG-RAN-RCU bit set to " UE radio capability update needed". For case o), the UE shall include the Uplink data status IE in the REGISTRATION REQUEST message indicating the PDU session(s) without active user-plane resources for which the UE has pending user data to be sent, if any, and the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any. If the UE has joined one or more multicast MBS session and was in 5GMM-CONNECTED mode with RRC inactive indication before receiving the fallback indication from the lower layers, the UE shall include the Uplink data status IE in the REGISTRATION REQUEST message indicating the PDU session(s) that are associated to the one or more multicast MBS session. If the UE is in a non-allowed area or if the UE is not in allowed area, the UE shall not include the Uplink data status IE in REGISTRATION REQUEST message, except if the PDU session for which user-plane resources were active prior to receiving the fallback indication is an emergency PDU session, or if the UE is configured for high priority access in the selected PLMN or SNPN as specified in subclause 5.3.5. For case f), the UE shall include the Uplink data status IE in the REGISTRATION REQUEST message indicating the PDU session(s) for which the UE has uplink user data pending and the PDU session(s) for which user-plane resources were active prior to receiving "RRC Connection failure" indication from the lower layers, if any. If the UE has joined one or more multicast MBS session and was in 5GMM-CONNECTED mode with RRC inactive indication before receiving the indication of "RRC Connection failure" from the lower layers or before receiving the indication that the resumption of the RRC connection has failed from the lower layers, the UE shall include the Uplink data status IE in the REGISTRATION REQUEST message indicating the PDU session(s) that are associated to the one or more multicast MBS session. If the UE is in non-allowed area or not in allowed area, the UE shall not include the Uplink data status IE in REGISTRATION REQUEST message, except that the PDU session for which user-plane resources were active prior to receiving the "RRC Connection failure"indication is emergency PDU session, or that the UE is configured for high priority access in selected PLMN or SNPN, as specified in subclause 5.3.5. If the UE supports service gap control, then the UE shall set the SGC bit to "service gap control supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For case a), x) or if the UE operating in the single-registration mode performs inter-system change from S1 mode to N1 mode, the UE shall: a) if the UE has an applicable network-assigned UE radio capability ID for the current UE radio configuration in the selected PLMN or SNPN, include the applicable network-assigned UE radio capability ID in the UE radio capability ID IE of the REGISTRATION REQUEST message; and b) if the UE: 1) does not have an applicable network-assigned UE radio capability ID for the current UE radio configuration in the selected PLMN or SNPN; and 2) has an applicable manufacturer-assigned UE radio capability ID for the current UE radio configuration, include the applicable manufacturer-assigned UE radio capability ID in the UE radio capability ID IE of the REGISTRATION REQUEST message. For all cases except cases b) and z), if the UE supports ciphered broadcast assistance data and the UE needs to obtain new ciphering keys, the UE shall include the Additional information requested IE with the CipherKey bit set to "ciphering keys for ciphered broadcast assistance data requested" in the REGISTRATION REQUEST message. For case z), the UE shall include the Additional information requested IE with the CipherKey bit set to "ciphering keys for ciphered broadcast assistance data requested" in the REGISTRATION REQUEST message. For case a), if the UE supports ciphered broadcast assistance data and the UE detects that one or more ciphering keys stored at the UE is not applicable in the current TAI, the UE should include the Additional information requested IE with the CipherKey bit set to "ciphering keys for ciphered broadcast assistance data requested" in the REGISTRATION REQUEST message. For case b), if the UE supports ciphered broadcast assistance data and the remaining validity time for one or more ciphering keys stored at the UE is less than timer T3512, the UE should include the Additional information requested IE with the CipherKey bit set to "ciphering keys for ciphered broadcast assistance data requested" in the REGISTRATION REQUEST message. The UE shall set the WUSA bit to "WUS assistance information reception supported" in the 5GMM capability IE if the UE supports WUS assistance information. The UE may include its UE paging probability information in the Requested WUS assistance information IE if the UE has set the WUSA bit to "WUS assistance information reception supported" in the 5GMM capability IE and does not have an active emergency PDU session. The UE shall set the NR-PSSI bit to "NR paging subgrouping supported" in the 5GMM capability IE if the UE supports PEIPS assistance information, is not registered for emergency services and does not have an active emergency PDU session. The UE may include its UE paging probability information in the Requested PEIPS assistance information IE if the UE has set the NR-PSSI bit to "NR paging subgrouping supported" in the 5GMM capability IE. If the network supports the N1 NAS signalling connection release, and the MUSIM UE requests the network to release the NAS signalling connection, the UE shall set Request type to "NAS signalling connection release" in the UE request type IE, set the Follow-on request indicator to "No follow-on request pending" and, if the network supports the paging restriction, may set the paging restriction preference in the Paging restriction IE in the REGISTRATION REQUEST message. In addition, the UE shall not include the Uplink data status IE or the Allowed PDU session status IE in the REGISTRATION REQUEST message even if the UE has one or more active always-on PDU sessions associated with the 3GPP access. NOTE 17: If the network has already indicated support for N1 NAS signalling connection release in the current stored registration area and the UE doesn't have an emergency PDU session established, the MUSIM UE is allowed to request the network to release the NAS signalling connection during registration procedure for mobility and periodic registration update that is due to mobility outside the registration area even before detecting whether the network supports the N1 NAS signalling connection release in the current TAI. NOTE 18: If the network has already indicated support for paging restriction in the current stored registration area and the UE doesn't have an emergency PDU session established, the MUSIM UE is allowed to include paging restriction together with the request to the network to release the NAS signalling connection during registration procedure for mobility and periodic registration update that is due to mobility outside the registration area even before detecting whether the network supports the paging restriction in the current TAI. For case zi), the UE shall not include the Paging restriction IE in the REGISTRATION REQUEST message. If the UE is in 5GMM-IDLE mode and the network supports the N1 NAS signalling connection release, the UE may include the UE request type IE and set Request type to "NAS signalling connection release" to remove the paging restriction and request the release of the NAS signalling connection at the same time. In addition, the UE shall not include the Uplink data status IE in the REGISTRATION REQUEST message. If the UE does not have a valid 5G NAS security context and the UE is sending the REGISTRATION REQUEST message after an inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode, the UE shall send the REGISTRATION REQUEST message without including the NAS message container IE. The UE shall include the entire REGISTRATION REQUEST message (i.e. containing cleartext IEs and non-cleartext IEs, if any) in the NAS message container IE that is sent as part of the SECURITY MODE COMPLETE message as described in subclauses 4.4.6 and 5.4.2.3. If the UE indicates "mobility registration updating" in the 5GS registration type IE and supports V2X as specified in 3GPP TS 24.587[ Vehicle-to-Everything (V2X) services in 5G System (5GS); Stage 3 ]  [19B], the UE shall set the V2X bit to "V2X supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE indicates "mobility registration updating" in the 5GS registration type IE and supports V2X communication over E-UTRA-PC5 as specified in 3GPP TS 24.587[ Vehicle-to-Everything (V2X) services in 5G System (5GS); Stage 3 ]  [19B], the UE shall set the V2XCEPC5 bit to "V2X communication over E-UTRA-PC5 supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE indicates "mobility registration updating" in the 5GS registration type IE and supports V2X communication over NR-PC5 as specified in 3GPP TS 24.587[ Vehicle-to-Everything (V2X) services in 5G System (5GS); Stage 3 ]  [19B], the UE shall set the V2XCNPC5 bit to "V2X communication over NR-PC5 supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. The UE shall send the REGISTRATION REQUEST message including the NAS message container IE as described in subclause 4.4.6: a) when the UE is sending the message from 5GMM-IDLE mode, the UE has a valid 5G NAS security context, and needs to send non-cleartext IEs; or b) when the UE is sending the message after an inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode and the UE has a valid 5G NAS security context and needs to send non-cleartext IEs. The UE with a valid 5G NAS security context shall send the REGISTRATION REQUEST message without including the NAS message container IE when the UE does not need to send non-cleartext IEs and the UE is sending the message: a) from 5GMM-IDLE mode; or b) after an inter-system change from S1 mode to N1 mode in 5GMM-IDLE mode. If the UE is sending the REGISTRATION REQUEST message after an inter-system change from S1 mode to N1 mode in 5GMM-CONNECTED mode and the UE needs to send non-cleartext IEs, the UE shall cipher the NAS message container IE using the mapped 5G NAS security context and send the REGISTRATION REQUEST message including the NAS message container IE as described in subclause 4.4.6. If the UE does not need to send non-cleartext IEs, the UE shall send the REGISTRATION REQUEST message without including the NAS message container IE. If the REGISTRATION REQUEST message includes a NAS message container IE, the AMF shall process the REGISTRATION REQUEST message that is obtained from the NAS message container IE as described in subclause 4.4.6. If the UE is in NB-N1 mode, then the UE shall set the Control plane CIoT 5GS optimization bit to "Control plane CIoT 5GS optimization supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For all cases except case b, if the UE is capable of NB-S1 mode, then the UE shall set the Control plane CIoT EPS optimization bit to "Control plane CIoT EPS optimization supported" in the S1 UE network capability IE of the REGISTRATION REQUEST message. If the registration procedure for mobility and periodic registration update is initiated and there is request from the upper layers to perform "emergency services fallback" pending, the UE shall send a REGISTRATION REQUEST message without an Uplink data status IE. If the UE supports N3 data transfer and multiple user-plane resources in NB-N1 mode (see 3GPP TS 36.306[ Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio access capabilities ]  [25D], 3GPP TS 36.331[ Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification ]  [25A]), then the UE shall set the Multiple user-plane resources support bit to "Multiple user-plane resources supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. The UE shall set the ER-NSSAI bit to "Extended rejected NSSAI supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the NSSRG, then the UE shall set the NSSRG bit to "NSSRG supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For case zf), the UE shall include the service-level device ID in the Service-level-AA container IE of the REGISTRATION REQUEST message and set the value to the CAA-level UAV ID. The UE shall include the service-level-AA server address in the Service-level-AA container IE of the REGISTRATION REQUEST message and set the value to the USS address, if it is provided by the upper layers. The UE shall include the service-level-AA payload in the Service-level-AA container IE of the REGISTRATION REQUEST message and shall set the service-level-AA payload type, if the service-level-AA payload is provided by upper layers. NOTE 18: The service-level-AA payload can be of type "C2 authorization payload". The C2 authorization payload can include one or both of an indication of the request for direct C2 communication and pairing information for direct C2 communication. If the UE supports 5G ProSe direct discovery as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-dd bit to "5G ProSe direct discovery supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports 5G ProSe direct communication as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-dc bit to "5G ProSe discovery communication supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports acting as 5G ProSe layer-2 UE-to-network relay UE as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-l2relay bit to "Acting as a 5G ProSe layer-2 UE-to-network relay UE supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports acting as 5G ProSe layer-3 UE-to-network relay UE as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-l3relay bit to "Acting as a 5G ProSe layer-3 UE-to-network relay UE supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports acting as 5G ProSe layer-2 UE-to-network remote UE as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-l2rmt bit to "Acting as a 5G ProSe layer-2 UE-to-network remote UE supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports acting as 5G ProSe layer-3 UE-to-network remote UE as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-l3rmt bit to "Acting as a 5G ProSe layer-3 UE-to-network remote UE supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports acting as 5G ProSe layer-2 UE-to-UE relay UE as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-l2U2U relay bit to "Acting as a 5G ProSe layer-2 UE-to-UE relay UE supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports acting as 5G ProSe layer-3 UE-to-UE relay UE as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-l3U2U relay bit to "Acting as a 5G ProSe layer-3 UE-to-UE relay UE supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports acting as 5G ProSe layer-2 end UE as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-l2end bit to "Acting as a 5G ProSe layer-2 end UE supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports acting as 5G ProSe layer-3 end UE as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E], the UE shall set the 5G ProSe-l3end bit to "Acting as a 5G ProSe layer-3 end UE supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For all cases except case b, if the MUSIM UE supports the N1 NAS signalling connection release, then the UE shall set the N1 NAS signalling connection release bit to "N1 NAS signalling connection release supported" in the 5GMM capability IE of the REGISTRATION REQUEST message otherwise the UE shall not set the N1 NAS signalling connection release bit to "N1 NAS signalling connection release supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For all cases except case b, if the MUSIM UE supports the paging indication for voice services, then the UE shall set the paging indication for voice services bit to "paging indication for voice services supported" in the 5GMM capability IE of the REGISTRATION REQUEST message otherwise the UE shall not set the paging indication for voice services bit to "paging indication for voice services supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For all cases except case b, if the MUSIM UE supports the reject paging request, then the UE shall set the reject paging request bit to "reject paging request supported" in the 5GMM capability IE of the REGISTRATION REQUEST message otherwise the UE shall not set the reject paging request bit to "reject paging request supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For all cases except case b, if the MUSIM UE 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; and supports the paging restriction, then the UE shall set the paging restriction bit to "paging restriction supported" in the 5GMM capability IE of the REGISTRATION REQUEST message otherwise the UE shall not set the paging restriction bit to "paging restriction supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports MINT, the UE shall set the MINT bit to "MINT supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports slice-based N3IWF selection, the UE shall set the SBNS bit to "Slice-based N3IWF selection supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports slice-based TNGF selection, the UE shall set the SBTS bit to "Slice-based TNGF selection supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports UAS services, the UE shall set the UAS bit to "UAS services supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports A2X over E-UTRA-PC5 as specified in 3GPP TS 24.577[ Aircraft-to-Everything (A2X) services in 5G System (5GS) protocol aspects; Stage 3 ]  [60], the UE shall set the A2XEPC5 bit to "A2X over E-UTRA-PC5 supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports A2X over NR-PC5 as specified in 3GPP TS 24.577[ Aircraft-to-Everything (A2X) services in 5G System (5GS) protocol aspects; Stage 3 ]  [60], the UE shall set the A2XNPC5 bit to "A2X over NR-PC5 supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports A2X over Uu as specified in 3GPP TS 24.577[ Aircraft-to-Everything (A2X) services in 5G System (5GS) protocol aspects; Stage 3 ]  [60], the UE shall set the A2X-Uu bit to "A2X over Uu supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports SL positioning server UE as specified in 3GPP TS 23.586[ Architectural Enhancements to support Ranging based services and Sidelink Positioning ]  [63] over PC5, the UE shall set the SLPSPC5 bit to "SL positioning server UE over PC5 supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. For case zg), if the UE has determined the MS determined PLMN with disaster condition as specified in 3GPP TS 23.122[ Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode ]  [5], and: a) the MS determined PLMN with disaster condition is the HPLMN and: 1) the Additional GUTI IE is included in the REGISTRATION REQUEST message and does not contain a valid 5G-GUTI that was previously assigned by the HPLMN; or 2) the Additional GUTI IE is not included in the REGISTRATION REQUEST message and the 5GS mobile identity IE contains neither the SUCI nor a valid 5G-GUTI that was previously assigned by the HPLMN; or b) the MS determined PLMN with disaster condition is not the HPLMN and: 1) the Additional GUTI IE is included in the REGISTRATION REQUEST message and does not contain a valid 5G-GUTI that was previously assigned by the MS determined PLMN with disaster condition; or 2) the Additional GUTI IE is not included in the REGISTRATION REQUEST message and the 5GS mobile identity IE does not contain a valid 5G-GUTI that was previously assigned by the MS determined PLMN with disaster condition; the UE shall include in the REGISTRATION REQUEST message the MS determined PLMN with disaster condition IE indicating the MS determined PLMN with disaster condition. NOTE 19: If the UE initiates the registration procedure for disaster roaming services, and the MS determined PLMN with disaster condition cannot be determined when an NG-RAN cell of the PLMN broadcasts the disaster related indication as specified in 3GPP TS 23.122[ Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode ]  [5], the UE does not include in the REGISTRATION REQUEST message the MS determined PLMN with disaster condition IE but includes the Additional GUTI IE or the 5GS mobile identity IE or both as specified in subclauses 5.5.1.2.2. For case zh) the UE shall indicate "mobility registration updating" in the 5GS registration type IE of the REGISTRATION REQUEST message. For case zp), the UE shall send the REGISTRATION REQUEST message over the new non-3GPP access. The UE shall include the Uplink data status IE in the REGISTRATION REQUEST message indicating the MA PDU session ID(s) or the single access PDU session ID(s) whose user plan resources are to be switched from the old non-3GPP access to the new non-3GPP access or to be established over the new non-3GPP access, if any. If the UE requests the network to keep using the user plane resources of the old non-3GPP access during path switching to the new non-3GPP access, the UE shall include the Non-3GPP path switching information IE in the REGISTRATION REQUEST message and set the NSONR bit to "non-3GPP path switching while using old non-3GPP resources requested". If the UE supports event notification, the UE shall set the EventNotification bit to "Event notification supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports access to an SNPN using credentials from a credentials holder and the UE is in its HPLMN or EHPLMN or a subscribed SNPN, the UE shall set the SSNPNSI bit to "SOR-SNPN-SI supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports equivalent SNPNs, the UE shall set the ESI bit to "equivalent SNPNs supported" in the 5GMM capability IE of the REGISTRATION REQUEST message.If the UE supports LADN per DNN and S-NSSAI, the UE shall set the LADN-DS bit to "LADN per DNN and S-NSSAI supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the reconnection to the network due to RAN timing synchronization status change, the UE shall set the Reconnection to the network due to RAN timing synchronization status change (RANtiming) bit to "Reconnection to the network due to RAN timing synchronization status change supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports MPS indicator update via the UE configuration update procedure, the UE shall set the MPSIU bit to "MPS indicator update supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports MCS indicator update via the UE configuration update procedure, the UE shall set the MCSIU bit to "MCS indicator update supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports ranging and sidelink positioning over PC5 as specified in 3GPP TS 24.514[ Ranging based services and sidelink positioning in 5G system(5GS); Stage 3 ]  [62] and supports: a) V2X communication over PC5 as specified in 3GPP TS 24.587[ Vehicle-to-Everything (V2X) services in 5G System (5GS); Stage 3 ]  [19B]; b) 5G ProSe direct discovery and 5G ProSe direct communication as specified in 3GPP TS 24.554[ Proximity-services (ProSe) in 5G System (5GS) protocol aspects; Stage 3 ]  [19E]; or c) both a) and b), the UE shall set the RSPPC5 bit to "Ranging and sidelink positioning over PC5 supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the partial network slice, the UE shall set the PNS bit to "Partial network slice supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports network slice usage control, the UE shall set the NSUC bit to "Network slice usage control supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the S-NSSAI time validity information, the UE shall set the TempNS bit to "S-NSSAI time validity information supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. If the UE supports the S-NSSAI location validity information, the UE shall set the SLVI bit to "S-NSSAI location validity information supported" in the 5GMM capability IE of the REGISTRATION REQUEST message. Figure 5.5.1.3.2.1: Registration procedure for mobility and periodic registration update