Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.502  Word version:   16.4.0

Top   Up   Prev   Next
1…   4.2.2.2.2   4.2.2.2.3…   4.2.3…   4.2.3.3   4.2.4…   4.2.6   4.2.7…   4.2.9…   4.3…   4.3.2.2…   4.3.2.2.2   4.3.2.2.3…   4.3.3   4.3.4   4.3.5…   4.3.5.2…   4.3.5.4…   4.3.5.6…   4.3.6…   4.4…   4.5…   4.9…   4.9.1.3…   4.9.2…   4.11…   4.11.1.2.2…   4.11.1.3…   4.11.1.4…   4.11.1.5…   4.11.2   4.11.3…   4.12…   4.12.6…   4.12a   4.12b   4.13…   4.13.4…   4.13.6…   4.14…   4.15…   4.15.4…   4.16…   4.16.4…   4.16.8…   4.17…   4.17.9…   4.18…   4.19…   4.23…   4.23.7…   4.23.9…   4.23.11…   4.24   4.25   4.26…   5…   5.2.3…   5.2.5…   5.2.6…   5.2.7…   5.2.8…   5.2.9…   5.2.12…   A…   E…   F…

 

4.12a  Procedures for Trusted non-3GPP access [R16]Word-p. 255
4.12a.1  General
Clause 4.12a defines the procedures to support trusted non-3GPP access by describing the differences compared to the defined procedures in other clauses.
4.12a.2  Registration via Trusted non-3GPP Access
4.12a.2.1  General
Clause 4.12a.2 specifies how a UE can register to 5GC via a trusted non-3GPP access network. The utilized procedure is very similar with the 5GC registration procedure over untrusted non-3GPP access in clause 4.12.2.2 and it is based on the Registration procedure specified in clause 4.2.2.2.2. It uses the same vendor-specific EAP method (called "EAP-5G") as the one specified in clause 4.12.2.1. In this case, the "EAP-5G" method is used between the UE and the TNGF and is utilized for encapsulating NAS messages.
In Registration and subsequent Registration procedures via trusted non-3GPP access, the NAS messages are always exchanged between the UE and the AMF. When possible, the UE can be authenticated by reusing the existing UE security context in AMF.
Up
4.12a.2.2  Registration procedure for trusted non-3GPP access
The UE connects to a trusted non-3GPP access network (TNAN) and it also registers to 5GC over via this TNAN, by using the EAP-based procedure shown in the figure 4.12a.2.2. This procedure is very similar with the 5GC registration procedure over untrusted non-3GPP access in clause 4.12.2.2. The link between the UE and the TNAN can be any data link (L2) that supports EAP encapsulation, e.g. PPP, PANA, Ethernet, IEEE 802.3, IEEE 802.11, etc. The interface between the TNAP and TNGF is an AAA interface.
Up
Step 0.
The UE selects a PLMN and a TNAN for connecting to this PLMN by using the Trusted Non-3GPP Access Network selection procedure specified in TS 23.501, clause 6.3.12. During this procedure, the UE discovers the PLMNs with which the TNAN supports trusted connectivity (e.g. "5G connectivity").
Step 1.
A layer-2 connection is established between the UE and the TNAP. In the case of IEEE 802.11 [48], this step corresponds to an 802.11 Association. In the case of PPP, this step corresponds to a PPP LCP negotiation. In other types of non-3GPP access (e.g. Ethernet), this step may not be required.
Step 2-3.
An EAP procedure is initiated. EAP messages are encapsulated into layer-2 packets, e.g. into IEEE 802.3/802.1x packets, into IEEE 802.11/802.1x packets, into PPP packets, etc. The NAI provided by the UE indicates that the UE requests "5G connectivity" to a specific PLMN, e.g. NAI = "<any_username>@nai.5gc. mnc<MNC>.mcc<MCC>.3gppnetwork.org". This NAI triggers the TNAP to send an AAA request to a TNGF, which operates as an AAA proxy. Between the TNAP and TNGF the EAP packets are encapsulated into AAA messages. The AAA request also include the TNAP identifier, which can be treated as the User Location Information.
Step 4-10.
An EAP-5G procedure is executed as the one specified in clause 4.12.2.2 for the untrusted non-3GPP access with the following modifications:
  • A TNGF key (instead of an N3IWF key) is created in the UE and in the AMF after the successful authentication. The TNGF key is transferred from the AMF to TNGF in step 10a (within the N2 Initial Context Setup Request). The TNGF derives a TNAP key, which is provided to the TNAP. The TNAP key depends on the non-3GPP access technology (e.g. it is a Pairwise Master Key in the case of IEEE 802.11 [48]). How these security keys are created, it is specified in TS 33.501.
  • In step 5 the UE shall include the Requested NSSAI in the AN parameters only if allowed, according to the conditions defined in TS 23.501, clause 5.15.9, for the trusted non-3GPP access.
  • In step 9b the UE receives the "TNGF Contact Info" which includes the IP address of TNGF.
Step 11.
The TNAP key is used to establish layer-2 security between the UE and TNAP. In the case of IEEE 802.11 [48], a 4-way handshake is executed, which establishes a security context between the WLAN AP and the UE that is used to protect unicast and multicast traffic over the air.
Step 12.
The UE receives IP configuration from the TNAN, e.g. with DHCP.
Step 13.
At this point, the UE has successfully connected to the TNAN and has obtained IP configuration. The UE sets up a secure NWt connection with the TNGF as follows:
The UE initiates an IKE_INIT exchange using the IP address of TNGF received during the EAP-5G signalling, in step 9b. Subsequently, the UE initiates an IKE_AUTH exchange and provides its identity. The identity provided by the UE in the IKEv2 signalling should enable the TNGF to locate the TNGF key that was created before for this UE, during the authentication in step 8. The TNGF key is used for mutual authentication. NULL encryption is negotiated between the UE and the TNGF, as specified in RFC 2410 [49].
In step 13c, the TNGF provides to UE (a) an "inner" IP address, (b) a NAS_IP_ADDRESS and a TCP port number and (c) a DSCP value. After this step, an IPsec SA is established between the UE and TNGF. This is referred to as the "signalling IPsec SA" and operates in Tunnel mode. Operation in Tunnel mode enables the use of MOBIKE [40] for re-establishing the IPsec SAs when the IP address of the UE changes during mobility events. All IP packets exchanged between the UE and TNGF via the "signalling IPsec SA" shall be marked with the above DSCP value. The UE and the TNAP may map the DSCP value to a QoS level (e.g. to an EDCA Access Class [48]) supported by the underlying non-3GPP access network. The mapping of a DSCP value to a QoS level of the non-3GPP access network is outside the scope of 3GPP.
Right after the establishment of the "signalling IPsec SA", the UE shall setup a TCP connection with the TNGF by using the NAS_IP_ADDRESS and the TCP port number received in step 13c. The UE shall send NAS messages within TCP/IP packets with source address the "inner" IP address of the UE and destination address the NAS_IP_ADDRESS. The TNGF shall send NAS messages within TCP/IP packets with source address the NAS_IP_ADDRESS and destination address the "inner" IP address of the UE.
This concludes the setup of the NWt connection between the UE and the TNGF. All subsequent NAS messages between UE and TNGF-CP are carried over this NWt connection (i.e. encapsulated in TCP/IP/ESP).
Step 14.
After the NWt connection is successfully established, the TNGF responds to AMF with an N2 Initial Context Setup Response message.
Step 15.
Finally, the NAS Registration Accept message is sent by the AMF and is forwarded to UE via the established NWt connection. Now the UE can use the TNAN (a) to transfer non-seamless offload traffic and (b) to establish one or more PDU Sessions.
Up
4.12a.3  Deregistration procedure for Trusted non-3GPP accessWord-p. 258
The Deregistration procedure via trusted non-3GPP access shall be supported as specified in clause 4.12.3 for the untrusted non-3GPP access with the following modifications:
  • The untrusted non-3GPP access is substituted by a trusted non-3GPP access point (TNAP).
  • The N3IWF is substituted by the TNGF.
  • If the UE has reserved QoS resources over non-3GPP access by using the Additional QoS Information (specified in clause 4.12a.5), then the UE shall release these resources.
Up
4.12a.4  N2 procedures via Trusted non-3GPP Access
4.12a.4.1  Service Request procedures via Trusted non-3GPP Access
The Service Request procedure via trusted non-3GPP access shall be supported as specified in clause 4.12.4.1 for the untrusted non-3GPP access with the following modifications:
  • The untrusted non-3GPP access is substituted by a trusted non-3GPP access.
  • The N3IWF is substituted by the TNGF.
  • The user plane between the UE and TNGF is established with IKEv2 signalling, as specified in clause 4.12a.5 (i.e. by using an IKEv2 Create_Child_SA exchange). The IKEv2 Create Child SA Request shall include the Additional QoS Information to reserve non-3GPP specific QoS resources as defined in clause 4.12a.5.
Up
4.12a.4.2  Procedure for the UE context release in the TNGF
This procedure for releasing the N2 signalling connection and the N3 user plane connection for a UE connected to 5GC via trusted non-3GPP access, shall be the same as the procedure specified in clause 4.12.4.2 for the untrusted non-3GPP access with the following modifications:
  • The untrusted non-3GPP access is substituted by a trusted non-3GPP access point (TNAP).
  • The N3IWF is substituted by the TNGF.
  • If the UE has reserved any non-3GPP specific QoS resources, the UE releases these resources when the IKEv2 Child SA is released.
Up
4.12a.4.3  CN-initiated selective deactivation of UP connection of an existing PDU Session associated with Trusted non-3GPP Access
The procedure described in clause 4.3.7 (CN-initiated selective deactivation of UP connection of an existing PDU Session) is used for CN-initiated selective deactivation of UP connection for an established PDU Session associated with trusted non-3GPP Access for a UE in CM-CONNECTED state, with the following exceptions:
  • The NG-RAN corresponds to a TNAN including a TNGF.
  • The user plane between the UE and TNGF, i.e. Child SA(s) for the PDU Session, is released not with RRC signalling but with IKEv2 signalling, as specified in clause 4.12a.7.
  • If the UE has reserved any non-3GPP specific QoS resources, the UE releases these resources when the IKEv2 Child SA is released.
Up
4.12a.5  UE Requested PDU Session Establishment via Trusted non-3GPP AccessWord-p. 259
After the UE registers to 5GC via trusted non-3GPP access, the UE may request a PDU Session establishment by using the same procedure as the one specified in clause 4.12.5 for untrusted non-3GPP access, with the following modifications:
  • The N3IWF in Figure 4.12.5-1 should be substituted with a TNGF and the Untrusted non-3GPP access should be substituted with a Trusted non-3GPP Access Point (TNAP).
  • The TNGF may send a TNGF Identities parameter to AMF inside an N2 Uplink NAS Transport message. The TNGF Identities parameter contains a list of identifiers (i.e. FQDNs or IP addresses) of N3 terminations supported by the TNGF. If received by the AMF, it shall forward it to the SMF, which may use it as input to UPF selection.
  • The IKEv2 Create Child SA Request message that is sent by the TNGF to UE (in steps 4a and 4c), in order to establish a child SA for one or more QoS flows, shall also include Additional QoS Information. The Additional QoS Information shall contain:
    1. If the IPsec child SA carries a GBR flow: QoS Characteristics and GBR QoS Flow Information:
      • The QoS Characteristics are associated with the 5QI of the GBR flow and are defined in TS 23.501, clause 5.7.3. The TNGF either receives the QoS Characteristics via the N2 interface (in the case of a dynamically assigned 5QI), or is pre-configured with the QoS Characteristics (in the case of a standardized 5QI).
      • The GBR QoS Flow Information (defined in TS 38.413) is part of the QoS Profile received via the N2 interface and contains: MFBR, GFBR, optionally a Notification Control, and optionally Maximum Packet Loss Rate. The Notification Control is not used by the UE.
    2. If the IPsec child SA carries a non-GBR flow: QoS Characteristics:
      • The QoS Characteristics are defined in bullet a) above.
      • The TNGF may aggregate multiple GBR flows or multiple non-GBR flows into the same IPsec child SA. In this case, the TNGF derives, in an implementation specific way, the QoS Characteristics of the aggregated flow by considering the QoS Characteristics of the individual flows. Similarly, the TNGF derives, in an implementation specific way, the GBR QoS Flow Information of an aggregated GBR flow by considering the GBR QoS Flow Information of the individual GBR flows.
    NOTE:
    The above behaviour of the TNGF does not create any impact on the N2 interface.
  • After receiving an IKEv2 Create Child SA Request message, the UE shall use the Additional QoS Information contained in this message to determine what QoS resources to reserve over the non-3GPP access, including e.g. guaranteed bit rates and delay bounds for UL/DL communication. How the UE determines what QoS resources to reserve over the non-3GPP access and how these QoS resources are reserved, is outside the scope of 3GPP specifications.
  • If the UE fails to reserve QoS resources over non-3GPP access for the QoS flows associated with the child SA (e.g. because the non-3GPP access network rejects the allocation of the requested bit rates), the UE shall reject the IKEv2 Child SA Request.
Up
4.12a.6  UE or network Requested PDU Session Modification via Trusted non-3GPP access
The UE or network requested PDU Session Modification procedure via trusted non-3GPP access is the same procedure as the one specified in clause 4.12.6 for untrusted non-3GPP access, with the following modifications:
  • The N3IWF in Figure 4.12.6-1 should be substituted with a TNGF and the Untrusted non-3GPP access should be substituted with a Trusted non-3GPP Access Point (TNAP).
  • The IKEv2 Create Child SA Request sent by the TNGF in step 4a, in order to create new QoS flow(s) for the PDU Session, shall include the Additional QoS Information defined in clause 4.12a.5. If the UE decides to reserve QoS resources over non-3GPP access for the QoS flows associated with the Child SA but fails to reserve these resources, the UE shall reject the IKEv2 Child SA Request.
  • The IKEv2 Informational Request sent by the TNGF in step 4b shall include the Additional QoS Information defined in clause 4.12a.5, when the IKEv2 Informational Request is sent to modify one or more existing QoS flows. If the UE decides to reserve QoS resources over non-3GPP access for the QoS flows associated with the Child SA but fails to reserve these resources, the UE shall indicate the failure in the IKEv2 Informational Response. The TNGF includes the list of QoS flows which are failed to setup in step 5.
  • The IKEv2 Informational Request sent by the TNGF in step 4c to release an existing IKEv2 Child SA shall trigger the UE to release the resources reserved over non-3GPP access for this IKEv2 Child SA.
  • If, after the PDU Session establishment, the UE determines that the QoS resources reserved over non-3GPP access for the QoS flows associated with a Child SA are released, then the UE shall initiate an INFORMATIONAL exchange, as specified in RFC 7296 [3], to delete the Child SA. After the Child SA is deleted, the TNGF initiates PDU Session Modification procedure as described in step 1e, in clause 4.3.3.2, including the list of QoS flows, which are released.
Up
4.12a.7  UE or network Requested PDU Session Release via Trusted non-3GPP accessWord-p. 260
The UE or the network can release a PDU Session via a trusted non-3GPP access network as specified in clause 4.12.7 for the untrusted non-3GPP access with the following modifications:
  • The untrusted non-3GPP access is substituted by a trusted non-3GPP access point (TNAP).
  • The N3IWF is substituted by the TNGF.
  • If the UE reserved any non-3GPP specific QoS resources, the UE releases these resources when the IKEv2 Child SA is released.
4.12a.8  Mobility from a non-geographically selected AMF to a geographically selected AMF
The procedure specified in clause 4.12.8 for untrusted non-3GPP access applies also to the trusted non-3GPP access with the following modifications:
  • The untrusted non-3GPP access is substituted by a trusted non-3GPP access point (TNAP).
  • The N3IWF is substituted by the TNGF.
  • The PDU Session is activated in step 2 as specified in clause 4.12a.5.
4.12a.9  Support of EAP Re-Authentication
The EAP Re-authentication Protocol (ERP) may be used, as specified in RFC 6696 [59], in order enable the UE move from a source TNAP to a target TNAP within the area of the same TNGF without a need to perform a full authentication.
To support EAP Re-authentication, the 5GC registration procedure specified in Figure 4.12a.2.2-1 shall be able to support the ERP implicit bootstrapping specified in RFC 6696 [59]. In particular, to support EAP Re-authentication, the 5GC registration procedure specified in Figure 4.12a.2.2-1 shall be extended as follows:
  • The TNGF shall implement the functionality as a local EAP Re-authentication (ER) server.
  • In step 6b, the N2 message sent from TNGF to AMF containing a NAS Registration Request shall also contain an ERP Request, which indicates that an EAP re-authentication root key (rRK) is needed. If necessary, the ERP Request may also contain a domain name, in which case, a domain-specific rook key (DSRK) is requested (see RFC 6696 [59]). In step 8a, the ERP Request is sent to the AUSF.
  • After the successful authentication in step 8b, the AUSF creates an EAP re-authentication root key (rRK) from the Extended Master Session Key (EMSK) by applying the procedures in RFC 5295 [60]. If a domain name was received in step 8a, then a DSRK is created instead.
  • In step 8c, the AUSF sends an ERP Response, which contains the created EAP re-authentication root key (e.g. rRK or DSRK) along with other information, such as the root key lifetime and an EMSKname, as specified in RFC 6696 [59]. The ERP Response is forwarded to TNGF in step 9a.
  • The TNGF applies the received EAP re-authentication root key to derive other EAP re-authentication keys, such as a re-authentication integrity key (rIK). These keys are stored in the TNGF and are used later when an EAP re-authentication procedure is initiated.
NOTE:
It is expected that SA WG3 will confirm the above steps and will define how the re-authentication root key (rRK) is created.
After the 5GC registration with ERP implicit bootstrapping is completed, the EAP re-authentication can be applied during a mobility event as shown in the figure below.
Up
  • When the UE moves to a target TNAP, which belongs to the same ERP domain as the domain of the source TNAP, an EAP re-authentication procedure is initiated as specified in RFC 6696 [59]. In step 1, the UE informs the target TNAP that it supports ERP.
  • The UE derives the same EAP re-authentication keys (e.g. in step 3) as those derived by TNGF during the 5GC registration procedure.
  • The EAP-Initiate/Re-auth in step 4 and the EAP-Finish/Re-auth in step 5 are both integrity protected using the re-authentication integrity keys created independently in the UE and in the TNGF. If these integrity keys are the same, the EAP re-authentication procedure is successful and the re-authentication MSK (rMSK) key is used to establish a security context between the UE and the target TNAP.
  • The above figure assumes that the IP address allocated to UE does not change during the mobility event. Therefore, after steps 1-6, the UE can use the same IP address to resume communication with the TNGF over the existing NWt connection.
  • The UE may reserve non-3GPP specific QoS resources based on the Additional QoS Information received during the QoS Flow establishment or modification. If the UE decides to reserve QoS resources over non-3GPP access for the QoS flows associated with the Child SA but fails to reserve these resources, the UE shall release the associated IKEv2 Child SA. In this case, the TNGF initiates the PDU Session Modification procedure as described in step 1e, in clause 4.3.3.2.
Up

Up   Top   ToC