Content for  TS 23.501  Word version:  19.1.0

This functionality is used by the network to identify traffic to/from UEs accessing over NR RedCap or NR eRedCap, e.g. for charging differentiation. An NR RedCap UE or NR eRedCap UE using NR shall provide an NR RedCap indication or respectively an NR eRedCap indication to the NG-RAN during RRC Connection Establishment procedure as defined in TS 38.300. When the UE has provided an NR RedCap indication indicating support of NR RedCap to the NG-RAN during RRC Connection Establishment, the NG-RAN shall provide an NR RedCap Indication to the AMF in the Initial UE Message (see clause 4.2.2.2.1 of TS 23.502 and TS 38.413). When the UE has provided an NR eRedCap indication indicating support of NR eRedCap to the NG-RAN during RRC Connection Establishment, the NG-RAN shall provide an NR eRedCap Indication to the AMF in the Initial UE Message (see clause 4.2.2.2.1 of TS 23.502 and TS 38.413). When the AMF receives an NR RedCap Indication or NR eRedCap Indication from NG-RAN in an Initial UE Message, the AMF shall store the NR RedCap Indication or NR RedCap Indication in the UE context, consider that the RAT type is NR RedCap or NR eRedCap and signal it accordingly to the SMSF during registration procedure for SMS over NAS, to the SMF during PDU Session Establishment or PDU Session Modification procedure. The PCF can also receive the NR RedCap or NR eRedCap RAT type when applicable from the AMF using the PCRT on Access Type change specified in clause 6.1.2.5 of TS 23.503 during AM Policy Association Establishment or AM Policy Association Modification procedure, and from the SMF using the PCRT on Access Type change specified in clause 6.1.3.5 of TS 23.503 during SM Policy Association Establishment or SM Policy Association Modification procedure. During handover from E-UTRA to NR, the target NG-RAN (i.e. gNB) provides the NR RedCap indication or NR eRedCap indication to AMF in NGAP Path Switch Request message during Xn handover, or NGAP Handover Request Acknowledge message during N2 handover (including intra 5GS N2 handover and EPS to 5GS handover) based on the UE capability information provided by the source RAN to the target RAN as specified in TS 38.300. The NFs interacting with CHF shall include the NR RedCap or NR eRedCap as RAT type. Upon AMF change, the source AMF shall provide the "NR RedCap Indication" or "NR eRedCap Indication" to the target AMF. If a UE supports either NR RedCap or NR eRedCap as specified in TS 38.306 and the UE NG-RAN Radio Capability information changes following the procedure in clause 5.4.4.1, when the UE performs RRC Connection Establishment procedure, the UE shall report the NR RedCap indication or NR eRedCap indication that applies to the new Radio Capability.

Non-seamless WLAN offload is an optional capability of a UE supporting WLAN radio access. The architecture to support authentication for Non-seamless WLAN offload in 5GS is defined in clause 4.2.15. A UE supporting Non-seamless WLAN offload may, while connected to WLAN access, route specific data flows via the WLAN access without traversing the 5GC. These UE data flows are identified using URSP configuration for Non-Seamless Offload, or UE Local Configurations as defined in TS 23.503. For these data flows, the UE uses the local IP address allocated by the WLAN access network and no IP address preservation is provided between WLAN and NG-RAN. For performing the Non-seamless WLAN offload, the UE needs to acquire a local IP address from the WLAN access network and it is not required to connect to an N3IWF, ePDG or TNGF. If the WLAN access network is configured to require the 5GS based access authentication of the UE for connecting to the WLAN, the UE performs the authentication procedure for Non-seamless WLAN offload in 5GS defined in clause 4.2.15 and in Annex S of TS 33.501. After successful authentication, the UE is not considered to be entered in 5GS Registered state. The UE can send and receive traffic not traversing the 5GC and which is not under the control of the 5GC. A non-3GPP access network may be connected via SWa' to multiple PLMNs for 5G NSWO. In a roaming scenario the HPLMN may be reached by the UE via a WLAN access connected to more than one VPLMN. Therefore, a UE when roaming shall be able to indicate a specific selected VPLMN using decorated NAI for 5G NSWO, as specified in clauses 28.7.9.1 and 28.7.9.2 of TS 23.003, through which the NSWO request should be sent towards the HPLMN. A non-3GPP access network may be connected to multiple SNPNs different from the Credentials Holder for 5G NSWO. When using the credentials owned by CH, the UE shall be able to indicate a specific selected SNPN (e.g. using decorated NAI for 5G NSWO) through which the NSWO request should be sent towards the CH in the following scenarios:

• The CH hosts AUSF/UDM and the CH is reached by the UE via a WLAN access connected to a SNPN different from the CH as defined in Figure 4.2.15-3a.
• The CH hosts AAA server and the CH is reached by the UE via a WLAN access connected to the AAA proxy in specific SNPN as defined in Figure 4.2.15-3b.

A UE connected to a WLAN access network using 5GS credentials (as shown in Figure 4.2.15-1), may also be connected to the 5GC, for example to establish a PDU session. For example, the UE may connect to the 5GC either via another access type (such as NG-RAN), or via the same WLAN access network by performing the 5GS registration via Untrusted non-3GPP access procedure (using N3IWF) or interworking between ePDG connected to EPC and 5GS (using ePDG) defined in TS 23.502. When a UE is connected to a WLAN access network (e.g. using 5GS credentials) and using an Untrusted non-3GPP access, the UE can perform Non-Seamless Offload of some or all data traffic to this WLAN access network sending the traffic outside the IPSec tunnel encapsulation as defined in URSP rules with Non-Seamless Offload indication. A UE may use the Registration procedure for Trusted non-3GPP access defined in clause 4.12a.2.2 of TS 23.502 and then determine to send some traffic (to be subject to Non-seamless WLAN offload) outside of the IPSec tunnel established with the TNGF. When the UE decides to use 5G NSWO to connect to the WLAN access network using its 5GS credentials but without registration to 5GS, the NAI format for 5G NSWO is used whose realm is different than the realm defined for usage of Trusted non-3GPP access to the 5GC (defined in clauses 28.7.6 and 28.7.7 of TS 23.003). The NAI format for 5G NSWO is defined in TS 23.003.