Get in Toucharrow

CONTACT US

Untrusted Non-3GPP Access Network Interworking with 5G Core

The use of the non-3GPP Interworking Function (N3IWF) facilitates interworking between the 5G Core Network (5GCN) and untrusted non-3GPP networks. With support for both N2 and N3 interfaces towards the 5GCN, the N3IWF serves as a gateway for the 5GCN. Furthermore, with support for IPsec between the UE and the N3IWF, N3IWF offers a secure connection for the UE accessing the 5GCN over non-3GPP access networks. The architecture of an untrusted non-3GPP network interacting with the 5G core is described in the paper, along with the interfaces, protocols, and techniques that are employed, as well as QoS support.

This blog describes in detail the user plane (UP) functionalities such as QoS for untrusted non-3GPP access and in the N3IWF, and the control plane (CP) functionalities such as registration and PDU session establishment. The untrusted non-3GPP access network in this paper is taken into consideration because the current 3GPP specification only supports Wireless LAN (Wi-Fi) Access Network (WLAN) as the non-3GPP access network.

Need

Untrusted WLANs are those that are not under the mobile network operator’s control, such as public hotspots, private homes, business buildings, etc. Untrusted non-3GPP/WLAN networks can, however, complement 3GPP access networks by facilitating convergence to a single 5GCN that offers a variety of IP-based services to address the following needs:

  • By using more capacity and intelligent traffic offloading, you can prevent data congestion and lower backhaul expenses.
  • Improve coverage and connectivity both indoors and in areas with heavy traffic density.
  • With value-added services, creative mobility solutions, and mobile engagement, open up new business opportunities.
  • With more capacity and centralized management, lower operator capital and operating expenses.
  • Provide customers with improved services in an economical manner.

Evolution

Untrusted WLANs are those that are not under the mobile network operator’s control, such as public hotspots, private homes, business buildings, etc. Untrusted non-3GPP/WLAN networks can, however, complement 3GPP access networks by facilitating convergence to a single 5GCN that offers a variety of IP-based services to address the following needs:

  • By using more capacity and intelligent traffic offloading, you can prevent data congestion and lower backhaul expenses.
  • Improve coverage and connectivity both indoors and in areas with heavy traffic density.
  • With value-added services, creative mobility solutions, and mobile engagement, open up new business opportunities.
  • With more capacity and centralized management, lower operator capital and operating expenses.
  • Provide customers with improved services in an economical manner.

Evolution

The architecture evolution for untrusted WLAN interworking with 3GPP mobile networks is depicted in the below figure. WLANs that are not trusted can access the 3GPP network before 4G/5G by using a Packet Data Gateway (PDG) and a Wireless Access Gateway (WAG). A portion of the GGSN’s functionality that interacts with the Tunnel Termination Gateway (TTG) is included in the PDG. Through EAP-AKA/EAP-SIM authentication via WAG, the AAA server is used to authenticate the UEs over untrusted WLAN. Using the GTPC protocol, the CP signaling between TTG and GGSN creates PDP contexts for user sessions. An IPsec tunnel ends at the TTG for every UE session that is established, and a corresponding GTPU tunnel is established to the GGSN.


Architecture Evolution for Untrusted WLAN Interworking

Using EAP-AKA/EAP-AKA authentication with AAA server, the evolved packet data gateway (ePDG) allows access to the 4G network from an untrusted WLAN. The GTPC/PMIP protocol is used in the CP signaling between ePDG and PGW to establish bearers for user sessions. An IPsec tunnel ends at the ePDG for every UE session created over an untrusted WLAN, and a corresponding GTPU/GRE tunnel is established to the PGW. In addition, IPsec can be established between UE and ePDG for CP signaling, and a tunnel between UE and PGW for UP, using the Dual Stack MIPv6 protocol.

Architecture

The figure below depicts the network architecture integrating 5GCN with untrusted WLAN access. When a UE uses an untrusted WLAN to access the 5GCN, it must be able to support NAS signaling and use the N3IWF for initial registration and authentication. In contrast to previous untrusted WLAN architectures, 3GPP access registration and authentication methods are employed, with the UE being registered using the AMF and authenticated using the AUSF via EAP-AKA/5G-AKA.

An IPsec Security Association (SA) is established between the UE and N3IWF prior to the registration process’ conclusion in order to secure NAS mobility and session management messages. Using the NAS session management messages and the IPsec signaling SA, the UE will establish PDU sessions with the SMF through the AMF. The N3IWF will establish a GTPU tunnel with the UPF and IPsec Child SAs with the UE for different QoS flows corresponding to the PDU session during the establishment of a PDU session. The secure IPsec tunnel(s) between UE and N3IWF and the GTPU tunnel between N3IWF and UPF are used for the transfer of UL and DL data packets between the UE and data network. The ensuing sections go into further detail about the architecture.


Design for Untrusted WLAN Collaboration with 5GCN

Interfaces

The following interfaces are supported by the untrusted WLAN interacting with 5GCN:

  • NWu reference point for creating a secure tunnel or tunnels between the UE and N3IWF to enable the safe transfer of control-plane and user-plane traffic over untrusted non-3GPP access between the UE and the 5GCN.
  • Y1 reference point that connects the WLAN and the UE.
  • Y2 reference point for NWu traffic transport between the WLAN and the N3IWF.
  • N1 point of reference for the AMF and UE.
  • N2 point of reference for the AMF and N3IWF.
  • N3 point of reference for the UPF and N3IWF.

Protocols

The CP and UP protocol stacks used in UE, WLAN AP, N3IWF, AMF, and UPF to access the 5GCN from an untrusted WLAN are described in this section.

Protocol stacks for control planes

The protocols utilized in UE, WLAN, N3IWF, and AMF are provided by the CP protocol stacks for the following:

  • Initial Registration and Authentication.
  • NAS mobility and session management.
  • Establishing UP between N3IWF and UE.

Initial registration and authentication protocol stack

The figure below displays the CP protocol stack for first access to 5GCN. The UE must first choose and establish a WLAN connection over the Y1 interface using the WLAN protocol in order to register with the 5GCN. The UE must choose the N3IWF and use the IKEv2 protocol to start the IKEv2 SA establishment process with the N3IWF over the NWu interface after configuring the UE with a local IP address from the chosen WLAN.

Following the establishment of the IKEv2 SA, the UE and the N3IWF begin the EAP-5G process, which in turn triggers the registration and authentication process via the NAS protocol and the AMF over the N1 interface. Between the N3IWF and UE over the NWu interface, the NAS messages are transmitted via the EAP-5G/IKEv2 protocol; between the N3IWF and AMF over the N2 interface, the NGAP/SCTP protocol is used.

Control Plane prior to IPsec SA signaling

Protocol stack for NAS mobility and session management

The UE and the N3IWF establish a signalling IPsec SA at the conclusion of the registration process. Following this, the UE and the N3IWF establish a TCP connection for the transfer of NAS mobility and session management messages via the inner IP layer and the signalling IPsec SA. The original IP signaling packets and the port numbers used for their communications are protected and encrypted by the signaling SA using IPsec tunnel mode. Figure below displays the CP protocol stack subsequent to signaling IPsec SA.

Control Plane after Signalling IPsec SA

TCP or the inner IP layer have the ability to split up large NAS messages. The UE and N3IWF can communicate via UDP protocol to allow NAT traversal for IPsec and IKEv2 traffic.

Protocol stack for establishing user plane

As shown in the figure below, the N3IWF uses the IKEv2 protocol to start the IPsec Child SAs establishment process with the UE in order to tunnel the UP traffic during the session establishment procedure.

Plane of Control for Determining User Plane

User plane protocol stack

The protocols used in UE, WLAN, N3IWF, and UPF for transferring UP traffic between the UE and data network are included in the UP protocol stack depicted in Figure 6. To safeguard and encrypt the original IP user data packets and the port numbers used for their communication, the established Child SAs use IPsec tunnel mode.

User Plane Protocol Stack

N3IWF Functionalities

The CP and UP functionalities of N3IWF for connecting to the 5GCN from an untrusted WLAN are described in this section.

These CP functions are supported by the N3IWF:

  • Support for IKEv2/IPsec protocols to establish an IPsec tunnel with the UE over NWu.
  • Creation of a signaling IPsec SA to protect NAS messages.
  • IPsec SA establishment to protect PDU session traffic.
  • N2 interface termination towards AMF via NGAP and SCTP protocols.
  • Relaying control plane NAS (N1) signals uplink and downlink between the UE and AMF NAS messages in order to register, authenticate, and grant the UE access to the 5GCN NAS messages in order to create PDU sessions.
  • Managing N2 signals from SMF that AMF relays in relation to PDU sessions and AMF’s choice of QoS.
  • User-plane features

    The UP functionalities listed below are supported by the N3IWF:

    • N3 interface termination with the GTPU protocol directed at UPF.
    • Relaying user plane packets between the UE and UPF both uplink and downlink.
    • Packet encapsulation and decapsulation for GTPU tunneling, IPsec, and N3 user plane packet marking in the uplink.
    • Enforcing N3 packet marking-corresponding QoS.
    • Control Plane Procedures

      From the untrusted WLAN network, access to the 5GCN primarily entails the following steps:

      • Access network selection and discovery.
      • Registration, authorization and authentication.
      • PDU session establishment.
      • Access Network Discovery and Selection

        The UE must utilize the Access Network Discovery and Selection Policy (ANDSP) to identify the untrusted WLAN access network and choose N3IWF. Information about the configuration of non-3GPP access networks (N3AN) nodes and WLAN Selection Policies (WLANSP) make up the ANDSP. The UE is configured with a local IP address and connects to the WLAN using the WLANSP.

        To choose a N3IWF, the UE consults the N3AN node configuration data. A prioritized list of PLMNs, including HPLMN, and a PLMN that matches any PLMN the UE is connected to but not HPLMN make up the N3AN information. A FQDN parameter (Tracking/Location Area Identity or Operator Identifier) is used to find the address of N3IWF in the PLMN, and each PLMN has a preference parameter that indicates the preferred N3IWF in the PLMN. The FQDN or IP address of the N3IWF in all PLMNS can also be included in the UE’s N3IWF identifier configuration, which the UE will prefer when selecting the N3IWF regardless of the preference parameter.

        Registration, Authentication and Authorization

        As illustrated in Figure below, the UE continues with the registration, authentication, and authorization processes after selecting N3IWF in order to gain access to the 5GCN.

        Registration Procedure

        • In order to establish an IKE SA, UE starts the IKEv2 initial exchange with the chosen N3IWF. Using the established IKE SA, all ensuing IKE messages are encrypted and integrity-protected.
        • Without the AUTH payload indicating the use of EAP-5G, UE sends the IKE AUTH request. A Notify payload to indicate support for MOBIKE and a CERTREQ payload to request a N3IWF certificate may also be included in the IKE AUTH request.
        • The IKE AUTH response from N3IWF includes an EAP-Request/5G-Start packet telling the UE to begin sending NAS messages. If the CERTREQ payload has been received, the N3IWF certificate will be included in the IKE AUTH response.
        • In addition to the EAP-Response/5G-NAS with the NAS registration request and AN parameters (GUAMI, the chosen PLMN ID, the requested NSSAI, and the Establishment Cause), the UE sends the IKE AUTH request. UE and N3IWF encapsulate all subsequent NAS messages into EAP/5G-NAS packets.
        • Based on the received AN parameters and local policy, N3IWF chooses an AMF and, in a N2 Initial UE message, forwards the registration request from the UE to the chosen AMF. N3IWF transparently relays all NAS messages between UE and AMF.
        • AMF may ask the UE for the SUCI by sending a NAS Identity request, which the UE will respond to with a NAS Identity Response.
        • Using SUCI or SUPI, AMF chooses an AUSF to authenticate the UE. In order to obtain authentication data, the AUSF further chooses a Unified Data Management (UDM) and uses the UE to carry out the EAP-AKA’/5G-AKA authentication.
        • Following successful authentication, the EAP Success Security anchor key (SEAF key) is sent by the AUSF to the AMF, which uses it to obtain the N3IWF and NAS security keys.
        • To enable NAS security, AMF sends the UE the NAS Security Mode Command message, which contains the EAP-Success that was received from AUSF.
        • A message titled “NAS Security Mode Complete” is sent to the AMF by UE along with the N3IWF key, NAS security keys, and SEAF key.
        • In addition, AMF sends the N3IWF a message known as an NGAP Initial Context Setup Request, which includes the N3IWF key. This causes the N3IWF to send UE an EAP-Success message, concluding the EAP-5G session.
        • With the assignment of an inner IP address for the UE and a NAS IP address for the N3IWF, 1IPsec SA is formed between the UE and N3IWF using the shared N3IWF key in tunnel mode. The established Signalling IPsec SA encapsulates all NAS messages sent back and forth between UE and N3IWF.
        • By sending an NGAP Initial Context Setup Response, N3IWF alerts the AMF to the creation of the UE context.
        • The Allowed NSSAI for the UE’s access type is included in the NAS Registration Accept message that the AMF sends to the N3IWF, which then forwards it to the UE via the signaling IPsec SA.
        • Following registration, the UE must use the N1 reference point to support NAS signaling with 5GCN for mobility and session management functions. A UE connected to a 5GCN via an untrusted WLAN and 3GPP access must have multiple N1 instances. A UE that is concurrently connected to the same PLMN via a 3GPP access and an untrusted WLAN must register with a single AMF using a shared 5G-GUTI; however, the UDM is in charge of overseeing separate UE Registration processes for every access.

          A UE is registered with two distinct AMFs if it is served by two different PLMNs. A change in WLAN AP shall not require a UE registered with 5GCN over an untrusted WLAN to perform a registration procedure, i.e., does not support mobility registration update in non-3GPP access.

          Registration Management (RM) and connection management (CM)

          When a UE successfully registers with a 5GCN through an untrusted WLAN, both the UE and the AMF enter the RM-REGISTERED state for non-3GPP access. For non-3GPP access, a UE that has an active NWu connection that is, one that is signaling IPsec SA—transitions to the CM-CONNECTED state. To access the 5GCN, a UE does not create multiple NWu connections at once.

          When an explicit deregistration procedure, WLAN release procedure, or N3IWF release procedure occurs—which can be identified by IKEv2’s dead peer detection mechanism—the NWu connection is released. For non-3GPP access, the UE enters the CM-IDLE state and initiates the UE non-3GPP deregistration timer.

          For non-3GPP access, a UE that has an active N2 connection between N3IWF and the AMF changes to the CM-CONNECTED state in the AMF. Either an explicit deregistration process or the release of the NWu connection by N3IWF causes the N2 connection to be released. For non-3GPP access, the UE enters the CM-IDLE state in the AMF and initiates the network’s non-3GPP deregistration timer. All UE resources, including the non-3GPP Access Connection and related N3 resources, will be released by the N3IWF upon the AMF releasing the N2 interface.

          When a UE experiences non-3GPP access while in the CM-IDLE state, it initiates the service request procedure to ask for the restoration of the NAS signaling connection and the user plane for some or all of the PDU Sessions connected to the non-3GPP access. A user equipment (UE) in the CM-CONNECTED state over non-3GPP access initiates or initiates a service request procedure on behalf of the network to restore the user plane for the PDU Sessions related to non-3GPP access.

          When a UE/network non-3GPP deregistration timer in the UE/AMF expires, or when an explicit deregistration procedure is carried out, a UE in the RM-REGISTERED state in the UE/AMF transitions to RM-DEREGISTERED state. With an untrusted WLAN, periodic registration updates are not supported.

          The UE independently maintains two RM and two CM states corresponding to each access when it is connected over 3GPP access and an untrusted WLAN at the same time. Each access is managed by the corresponding AMF for two RM and CM states when the UE is registered to the same PLMN.

          PDU Session Establishment

          PDU session establishment for a UE utilizing the untrusted WLAN to access the 5GCN is depicted in figure below.

          Session Establishment Procedure

          • Using the NAS signaling IPsec SA, the UE sends a PDU Session Establishment request to the N3IWF, which then transparently forwards it to the AMF in a NAS UL message.
          • Procedures that resemble the PDU session establishment in a 3GPP access are carried out in the 5GCN.
          • To set up the WLAN resources for this PDU session, AMF sends a message to N3IWF called N2 PDU Session Resource Setup Request. The QoS profiles and related QFIs, PDU Session ID, UL GTPU Tunnel Information, and NAS PDU Session Establishment Accept are all included in the message.
          • Based on its own policies, configuration, and QoS profiles received, N3IWF decides how many IPsec Child SAs to create and the QoS profiles linked to each IPsec Child SA.
          • To create the first IPsec Child SA for the PDU session, N3IWF submits an IKE Create Child SA request. It contains, optionally, a DSCP value and a Default Child SA indication in addition to the QFIs, PDU Session ID, and UP IP address linked to the Child SA.
          • After accepting the IKE Create Child SA request, UE sends an IKE Create Child SA response.
          • N3IWF creates extra IPsec Child SAs as needed, assigning a UP IP address and tying each one to one or more QFIs.
          • Following the creation of each IP Child SA, the PDU Session Establishment Accept message is sent by the N3IWF to the UE through the signaling IPsec SA, allowing UL data to begin.Additionally, the N3IWF provides AMF with a N2 PDU Session Resource Setup Response that includes DL GTPU Tunnel information. This allows DL data to begin and further executes procedures akin to the PDU session establishment in a 3GPP.
          • Different SMFs may serve PDU sessions over 3GPP access than those serving PDU sessions over non-3GPP access.

            PDU session deactivation

            The corresponding NWu connection, which includes the IPsec Child SAs and N3 tunnel, is also deactivated when the UP connection of an active PDU session is terminated. When a UE is in the CM-CONNECTED state, multiple PDU sessions’ UP connections can be disconnected separately. When a PDU session is always on, the SMF shouldn’t cut off the UP connection because it’s not being used. The release of a N2 connection is not implied by the release of PDU Sessions over non-3GPP access.

            Using an untrusted WLAN does not support paging. Therefore, regardless of the UE state for 3GPP access, a network-triggered service request procedure may be carried out over 3GPP access when the AMF receives a message corresponding to a PDU session for a UE in CM-IDLE state for non-3GPP access. When paging over 3GPP access is not carried out, a UE in CM-IDLE state for 3GPP access and CM-CONNECTED state for Non-3GPP access in AMF may also carry out a network-triggered Service Request procedure over non-3GPP access.

            Multiple PDU Sessions over 3GPP and non-3GPP access

            A UE that registered concurrently over two untrusted WLANs and a 3GPP access may have multiple PDU sessions over both access points, with each PDU session active in just one of the access points. Depending on UE policies, the UE may move the PDU Sessions in the corresponding access to the target access when it transitions to CM-IDLE in either of the access. In order to establish a PDU session using the PDU session IDs of the PDU sessions that were moved, the UE may need to start a registration process in the target access for the handover. For such PDU Sessions, the N3 user plane connection is disabled by the core network, but the PDU Sessions are still maintained. The UE may start a Deregistration procedure in the access that doesn’t have any PDU Sessions based on the implementation.

            Multi-Access PDU Session

            Access Traffic Steering, Switching, and Splitting (ATSSS) is supported by 3GPP Release 16 and enables multi-access PDU sessions. These sessions have multiple packet flows, and each packet flow can choose between 3GPP access and an untrusted WLAN, or it can be split between the two. To do so, additional information is included in the PDU session establishment procedure, along with user plane establishment.

            User Plane

            The UE can send uplink and downlink traffic for the session with different QoS flows over the untrusted WLAN network using the established IPsec Child SAs and the associated GTPU tunnel between the N3IWF and UPF after the PDU session establishment is complete and user plane IPsec Child SAs are established between the UE and N3IWF.

            Uplink Traffic

            When the UE needs to send a UL PDU, it uses the QoS rules of the relevant PDU session to ascertain the QFI associated with the PDU. Then, it encapsulates the PDU inside a GRE packet and includes the QFI value in the GRE packet header. By encapsulating the GRE packet into an IPsec packet in tunnel mode with a source address of UE and a destination address of UP associated with the Child SA, the UE will forward the GRE packet to N3IWF via the IPsec Child SA linked to the QFI.

            Upon receiving the UL PDU, the N3IWF is required to decapsulate the IPsec header and GRE header in order to ascertain the GTPU tunnel ID that is associated with the PDU session. With the QFI value present in the GTPY packet header, the N3IWF will encapsulate the UL PDU inside a GTPU packet and forward it via N3 to the UPF.

            Downlink Traffic

            After decapsulating the GTPU header and using the QFI and the PDU session identity found there, the N3IWF can determine which IPsec Child SA to use to send the DL PDU over NWu to the UE when it receives a DL PDU via N3 from the UPF.

            The QFI value must be present in the GRE packet header for the N3IWF to encapsulate the DL PDU inside a GRE packet. In order for the UE to enable reflective QoS, the N3IWF may additionally include a Reflective QoS Indicator (RQI) in the GRE header. By encapsulating the GRE packet into an IP packet in tunnel mode with source address as the UP IP address associated with the Child SA and destination address as the address of the UE, the N3IWF will forward the GRE packet with DL PDU to the UE via the IPsec Child SA associated with the QFI.

            QoS

            The N3IWF supports QoS differentiation and mapping of QoS flows to non-3GPP access resources for a UE accessing the 5GCN via the untrusted WLAN. A QoS flow can be preconfigured or established through the UE requested PDU session establishment or modification procedure, which is managed by the SMF. Based on local policies, configuration, and QoS profiles received from the network, the N3IWF will decide how many user plane IPsec Child SAs to create and the QoS profiles linked to each Child SA. After that, the N3IWF will start the IPsec SA creation process with the UE in order to create Child SAs that are connected to the PDU session’s QoS flows. The figure below lists the QoS functionalities of the UE, N3IWF, and UPF.

            QoS for Untrusted WLAN Accessing 5GCN

            Through a N3IWF, untrusted non-3GPP access is offered, which essentially translates to WLAN interworking with 5GCN. On the other hand, the N3IWF functions as an access network that is comparable to the 3GPP access, in contrast to the previous architectures where the WLAN interworking network element (PDG/ePDG) was a component of the 3GPP core network. This enables common registration, authentication, and session handling procedures for both 3GPP and non-3GPP access. Untrusted WLANs do not support paging, mobility registration, or periodic registration. It is possible to create multiple PDU sessions over the untrusted WLAN and 3GPP access, and to switch between the PDU sessions. Additionally, with support for ATSSS, a multi-access PDU session can be established over untrusted WLAN and 3GPP access.