Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.501  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.3…   5.9…   5.10…   6…   6.1.3…   6.1.4…   6.2…   6.2.2…   6.3…   6.4…   6.5…   6.6…   6.7…   6.8…   6.9…   6.10…   6.11   6.12…   6.13   6.14…   6.15…   6.16…   7…   7A…   7A.2.3…   7B…   8…   9…   10…   11…   12…   13…   13.2.2…   13.2.4…   13.3…   13.4…   14…   15…   16…   A…   B…   C…   D…   E…   F…   G…   I…   I.9…   J…   K…   M…   N…   O…   P…   R   S…   T…   U…   V…   W…   X…   Y…   Z… 
S  Support for Non-seamless WLAN offload (NSWO) in 5GS  S.1 Introduction  S.2 General  S.3 Authentication procedure  S.3.1 5G NSWO co-existence with EPS NSWO  S.3.2 5G NSWO procedures  S.4 Roaming 
...

 

S (Normative)  Support for Non-seamless WLAN offload (NSWO) in 5GS |R17|  p. 282

S.1  Introduction  p. 282

Non-seamless WLAN offload (NSWO) is an optional capability of a UE supporting WLAN radio access. A UE supporting non-seamless WLAN offload may, while connected to WLAN access, route specific IP flows via the WLAN access without traversing the 3GPP core network.
The present Annex specifies the support for authentication for NSWO in 5GS (5G NSWO).

S.2  General  p. 282

5G NSWO shall use EAP-AKA', as specified in RFC 5448, for authentication. The EAP-AKA' implementations shall comply with the EAP-AKA' profile specified in Annex F of the present document.
A new network function, called NSWOF, is introduced to support authentication for NSWO in 5GS. The NSWOF interfaces to the WLAN access network using SWa interface and interfaces to the AUSF using Service Based Interface (SBI).
Up

S.3  Authentication procedure  p. 282

S.3.1  5G NSWO co-existence with EPS NSWO  p. 282

An HPLMN that supports 5G NWSO and wants the UE to use 5G NSWO shall configure the UE to use 5G NSWO. This configuration shall be either on the USIM or ME, with configuration on the USIM taking precedence over the ME.
A UE that supports 5G NSWO and is configured to use 5G NSWO shall always use 5G NSWO as described in clause S.3.2 (i.e., it shall not use EPS NSWO defined in TS 23.402). Otherwise, the UE may use EPS NSWO (e.g., UE does not support 5G NSWO or not configured to use 5G NSWO).
The network may support both 5G NSWO and EPS NSWO. In such a case, the routing of the AAA messages is determined by the network based on the realm part of the UE Identity (e.g., realm contains epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org (EPS NSWO) or 5gc-nswo.mnc<MNC>.mcc<MCC>.3gppnetwork.org (5G NSWO)). Which entities in the network perform this routing decision is dependent on the network configuration.
Up

S.3.2  5G NSWO procedures  p. 283

Reproduction of 3GPP TS 33.501, Fig. S.3-1: Authentication procedure for NSWO in 5GS
Figure S.3-1: Authentication procedure for NSWO in 5GS
Up
Step 1.
The UE establishes a WLAN connection between the UE and the WLAN Access Network (AN), using procedures specified in IEEE 802.11 [80].
Step 2.
The WLAN AN sends an EAP Identity/Request to the UE.
Step 3.
The UE sends an EAP Response/Identity message. If the UE determines to use the NSWO service, the UE shall use the SUCI in NAI format (as specified in clause 28.7.12 and clause 28.7.9.2 of TS 23.003) as its identity irrespective of whether SUPI Type configured on the USIM is IMSI or NAI. If the SUPI Type configured on the USIM is IMSI, the UE shall construct the SUCI in NAI format with username containing the encrypted MSIN and the realm part containing the MCC/MNC.
Step 4.
The EAP Response/Identity message shall be routed over the SWa interface towards the NSWOF based on the realm part of the SUCI.
Step 5.
The NSWOF shall send the message Nausf_UEAuthentication_Authenticate Request with SUCI, Access Network Identity and NSWO indicator towards the AUSF. NSWO_indicator is used to indicate to the AUSF that the authentication request is for Non-seamless WLAN offload purposes. The NSWOF shall set the Access Network Identity to "5G:NSWO".
Step 6.
Based on the NSWO_indicator, the AUSF (acting as the EAP authentication server) shall send a Nudm_UEAuthentication_Get Request to the UDM, including SUCI and the Access Network Identity and NSWO indicator.
Step 7.
Upon reception of the Nudm_UEAuthentication_Get Request, the UDM shall invoke SIDF. SIDF shall de-conceal SUCI to gain SUPI before UDM can process the request. Based on the NSWO indicator, the UDM/ARPF shall select the EAP-AKA' authentication method and generate an authentication vector using the Access Network Identity as the KDF input parameter. The UDM shall include the EAP-AKA' authentication vector (RAND, AUTN, XRES, CK' and IK') and may include SUPI to AUSF in a Nudm_UEAuthentication_Get Response message.
Step 8.
The AUSF shall store XRES for future verification. The AUSF shall send the EAP-Request/AKA'-Challenge message to the NSWOF in a Nausf_UEAuthentication_Authenticate Response message.
Step 9.
The NSWOF shall send the EAP-Request/AKA'-Challenge message to the WLAN AN over the SWa interface.
Step 10.
The WLAN AN forwards the EAP-Request/AKA'-Challenge message to the UE.
Step 11.
At receipt of the RAND and AUTN in the EAP-Request/AKA'-Challenge message, the ME shall obtain the Access Network Identity from the EAP signalling and the USIM in the UE shall verify the freshness of the AV' by checking whether AUTN can be accepted as described in TS 33.102. If so, the USIM computes a response RES. The USIM shall return RES, CK, IK to the ME. The ME shall derive CK' and IK' using the Access Network Identity as the KDF input parameter. If the verification of the AUTN fails on the USIM, then the USIM and ME shall proceed as described in sub-clause 6.1.3.3. The UE may derive MSK from CK' and IK' as per Annex F and as described in RFC 5448. When the UE is performing NSWO authentication, the KAUSF shall not be generated by the UE.
Step 12.
The UE shall send the EAP-Response/AKA'-Challenge message to the WLAN AN.
Step 13.
The WLAN AN forwards the EAP-Response/AKA'-Challenge message over the SWa interface to the NSWOF.
Step 14.
The NSWOF shall send the Nausf_UEAuthentication_Authenticate Request with EAP-Response/AKA'-Challenge message to AUSF.
Step 15.
The AUSF shall verify if the received response RES matches the stored and expected response XRES. If the AUSF has successfully verified, it continues as follows to step 16, otherwise it returns an error to the NSWOF. The AUSF shall derive the required MSK key from CK' and IK' as per Annex F and as described in RFC 5448, based on the NSWO indicator received in step 5. The AUSF shall not generate the KAUSF.
Step 16.
The AUSF shall send Nausf_UEAuthentication_Authenticate Response message with EAP-Success and MSK key to NSWOF. The AUSF may optionally provide the SUPI to NSWOF. The AUSF/UDM shall not perform the linking increased home control to subsequent procedures (as stated in present document clause 6.1.4).
Step 17.
The NSWOF shall send the EAP-success and MSK to WLAN AN over the SWa interface. The EAP-Success message is forwarded from WLAN AN to the UE.
Step 18.
Upon receiving the EAP-Success message, the UE derives the MSK as specified in step 11, if it has not derived the MSK earlier. The UE uses the first 256-bit of MSK as PMK to perform 4-way handshake to establish a secure connection with the WLAN AN.
Up

S.4  Roaming  p. 284

The HPLMN may have a roaming agreement with a VPLMN for NSWO roaming. A roaming UE configured by the HPLMN to use 5G NSWO may try to register onto a WLAN AN that may advertise the HPLMN or a VPLMN (with which the HPLMN has a roaming agreement for NSWO roaming). The roaming architecture options are described in clause 4.2.15 in TS 23.501.

Up   Top   ToC