Aptilo Networks
  • SOLUTIONS
    • Carrier Wi-Fi
      • Carrier Wi-Fi details
      • Operator Managed Guest Wi-Fi
      • Virtual Service Provider
      • Wi-Fi Monetization
      • Hotspot 2.0
    • Guest Wi-Fi
      • Enterprise Guest Wi-Fi
      • Hospitality Wi-Fi
      • Healthcare Wi-Fi
      • Airport Wi-Fi
      • Retail Wi-Fi
    • Mobile Data Offloading
      • Offloading Details
      • Authentication
      • Policy & Charging
      • 3GPP Wi-Fi Access
    • Wi-Fi Calling
      • What is Wi-Fi Calling?
      • Wi-Fi Calling Details
      • VoWiFi / VoLTE entitlement
    • IoT Connectivity
  • CLOUD
    • Cellular IoT Connectivity
      • IoT Security
    • Zero-touch Wi-Fi IoT
    • Aptilo Guest Wi-Fi Cloud (eng)
      • Consent & Personal Data
      • Wi-Fi Marketing
      • WiFi4EU
    • Aptilo Guest Wi-Fi Cloud (sv)
      • Samtycke & Personuppgifter
      • Wi-Fi Marknadsföring
      • WiFi4EU
  • PRODUCTS
    • Aptilo SMP
      • Scalability and Availability
      • System reporting
      • Aptilo ServiceGlue
    • Aptilo SMP Wi-Fi
      • Wi-Fi AAA
      • Wi-Fi Policy
      • Subscriber Management
      • Consent & Personal Data
      • Captive Portal
      • Wi-Fi Analytics
      • Wi-Fi Marketing
      • Prepaid and Charging
    • Aptilo SMP IoT
    • Aptilo SMP Applications
      • Aptilo SMP Venue Wi-Fi Mgr
      • Aptilo SMP SIM Authentication
      • Aptilo SMP Wi-Fi Calling
      • Aptilo SMP 3GPP AAA+
    • Aptilo Access Controller
  • SERVICES
    • Aptilo Managed Service
    • Aptilo Support
  • PARTNERS
  • COMPANY
    • About Us
    • Management
    • Awards
    • Careers
    • Resources
    • Privacy Policy
  • NEWS
    • Aptilo Blog
    • Press Releases
    • Aptilo in the News
    • Subscribe to News
    • Events
  • CONTACT US
  • Search
  • Menu Menu
5G Core Datacenter

Wi-Fi and Cellular Convergence – What’s New in 5G

May 6, 2022/in Carrier Wi-Fi /by Johan Terve

This is an excerpt from our white paper Wi-Fi in the 5G Era – Strategy Guide for Operators. The full white paper is available here if you like what you read. Don’t hesitate to contact us if you have any questions.

Download White Paper

Business and technical consolidation trends all point in the same direction: Mobile and fixed networks are coming together – for the benefit of everyone in the industry and consumers.

5G introduces new network architectural concepts for Wi-Fi integration with the mobile core (non-3GPP access). In our previous blog post, we explored the opportunities for mobile operators today and the basic concepts of trusted and untrusted Wi-Fi access. This post will dive into what is new within 5G, introduced in 3GPP releases 15 and 16. After this blog post, we will cover the new Access Traffic Steering, Switching & Splitting (ATSSS) function, the ‘Holy Grail’ of mobile data offloading. Spoiler alert; ATSSS complexity and reliance on device support mean it will likely take years to come to market.

TRUSTED AND UNTRUSTED WI-FI NETWORK INTEGRATION TO 5G CORE

Standardization and network technology history tell us that not all functions in a standard will be deployed in real networks. They will not be implemented by vendors and service providers unless there are sound commercial reasons.

The 3G and 4G versions of Wi-Fi data plane integration are excellent examples. Most mobile operators have focused on local break-out of Wi-Fi traffic from their secure Wi-Fi networks (802.1x).

With no operational rationale or commercial reasons to backhaul Wi-Fi traffic to the Mobile Core, operators have opted to use secure SIM-based authentication, sometimes combined with policy control from the Mobile Core. There is no reason to exert extra load on the Mobile Core when operators can apply all required policies for Wi-Fi locally.

Device manufacturers also control much of what is possible and implemented. It took almost ten years for device manufacturers to decide to implement the IPsec client needed for untrusted Wi-Fi access. In their view, it simply took that long for a good commercial reason to materialize. This reason came with Wi-Fi Calling, which was in their own and their customers’ best interest.

So, are operators likely to implement the 5G 3GPP standards for Wi-Fi access? We believe so, and there are a few reasons for that. But such implementations will take time. First – as already discussed in this paper – operators more than ever need to embrace Wi-Fi in the 5G era. Secondly, a new breed of carrier-grade Wi-Fi (Wi-Fi 6) is here. Thirdly, the new Access Traffic Steering, Switching & Splitting (ATSSS) 3GPPP standard will finally give operators a good reason to backhaul traffic to the Mobile Core. We will dive deeper into ATSSS in our next blog post.

It can be overwhelming and confusing with all these acronyms that come with new 3GPP releases. So for the benefit of those of you familiar with the acronyms for 3G and 4G, please refer to this ‘translation table. Note that these are just ‘functions’ and may be delivered as one combined solution, deployed as containerized functions, or the same virtual or physical gateway node.”

3GPP Acronyms 3G,4G,5G

Network Diagram for trusted and untrusted Wi-Fi access to 5G core

The simplified diagram shows Wi-Fi service integration with the new service-based 5G Core (5GC) introduced in 3GPP release 15 (untrusted) and 16 (trusted).

The first thing to observe is that this architecture is Radio network (RAN) agnostic since both the Cellular and Wi-Fi access use the same interfaces (N1-N3).

N1 Control Plane Interface

The N1 is a control plane interface between the device (UE) and the Access and Mobility Function (AMF). It is primarily used to transfer information about the connection, mobility, and session from the UE to the AMF.

This interface is used both for Cellular and Wi-Fi (for 5G Capable Devices), and it is physically transported the same way to the AMF as shown by the N2 interface.

N2 Control Plane Interface

The N2 is the control plane interface between the access network and the 5G Core. It is primarily used for connection management, UE context and Protocol Data Unit (PDU) session management, and UE mobility management.

N3 Data Plane Interface

The N3 is the data plane interface between the access network and the User Plane Function (UPF) in the 5G Core. The UPF is the packet gateway transporting data to the internet.

How It Is All Connected

For Cellular networks, the N2 and N3 interfaces connect the base station (gNB) with the AMF and UPF. For Wi-Fi, they use the non-3GPP interworking and gateway functions (N3IWF, TNGF, TWIF) to connect with the AMF and UPF.

5G introduces a new principle for non-3GPP access: Simultaneous connections via cellular and Wi-Fi are now possible by using multiple non-access stratum (NAS) connections over the N1 interface. This is a prerequisite for the new ATSSS standard and the same authentication procedures, EAP-AKA’ and 5G-AKA, are used for both Cellular and Wi-Fi.

New EAP Protocol and Unusual Use of IPsec

A new protocol, EAP-5G, has been introduced to support NAS messages over Wi-Fi networks. The IKEv2 and EAP-5G protocols are used to establish an IPsec tunnel for signaling during the registration procedure between the device and the interworking and gateway functions. The EAP-5G protocol is then used to encapsulate NAS messages over the IKEv2 protocol.

Another interesting new principle is the use of IPsec also for trusted Wi-Fi networks. Why would you want to use an IPsec connection – albeit with null encryption to avoid double encryption – in a secure Wi-Fi network? It turns out that implementations in devices and gateways with dual support for both trusted and untrusted access will probably be easier to implement in this case. Add to this the benefits of a fixed anchor point in the Mobile Core to facilitate mobility and ATSSS.

Let’s now examine the new functions for non-3GPP access. Again, please note that these functions are not the same as physical gateways. In practice, these functions could all reside in the same gateway. One vendor could also provide the control plane (N1-N2), while another supplies the data plane (N3).

Non-3GPP Interworking Function (N3IWF)

The Non-3GPP Interworking Function (N3IWF) is the IPsec tunnel terminating node for 5G, similar to the ePDG for integration with the 4G Core. It is located in the Mobile Core and communicates with the Access and Mobility Function (AMF) control plane over the N1 and N2 interface. For the data plane, it communicates with the User Plane Function (UPF) over the N3 interface.

Trusted Non-3GPP Gateway Function (TNGF)

The trusted non-3GPP Gateway Function (TNGF) is for 5G the equivalent to the Wireless Access Gateway (WAG) used for trusted access to the 4G Core. The TNGF is located in a trusted environment, often the Wi-Fi network, and communicates with the Access and Mobility Function (AMF) control plane over the N1 and N2 interface. For the data plane, it communicates with the User Plane Function (UPF) over the N3 interface. As discussed, the device and the TGNF are connected using an IPsec tunnel with null encryption.

Trusted WLAN Interworking Function (TWIF)

The trusted WLAN Interworking Function (TWIF) is a new 5G function for interoperability with legacy devices. This is to resolve the contingency that some devices may support 5G SIM authentication but do not support 5G NAS signaling over trusted Wi-Fi access. These devices lack the support for the EAP-5G and IKEv2 protocols. 3GPP refers to such devices as non-5G-Capable over WLAN (N5CW). The TWIF contains the NAS protocol stack and exchanges NAS messages with the AMF on behalf of these types of devices.

The TWIF is located in a trusted environment, often the Wi-Fi Network, and communicates with the Access and Mobility Function (AMF) control plane over the N1 and N2 interface. For the data plane, it communicates with the User Plane Function (UPF) over the N3 interface. Just as in the case of TNGF, the device connects with the TWIF using an IPsec tunnel with NULL encryption.

 

Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
  • Share by Mail
To all posts
© 2001-2022 I Aptilo Networks
  • LinkedIn
  • Facebook
  • Twitter
Layers in a Hyperscale IoT Connectivity SolutionLayers in a Hyperscale IoT solution IoT auto-configuration key to scale IoT Every IoT Customization Mustn’t Be a Project Scroll to top

We use cookies to improve and personalize your browsing experience. This site may also include cookies from third parties. By using this site, you consent to the use of cookies.

OKLearn more

Cookie and Privacy Settings



How we use cookies

We may request cookies to be set on your device. We use cookies to let us know when you visit our websites, how you interact with us, to enrich your user experience, and to customize your relationship with our website.

Click on the different category headings to find out more. You can also change some of your preferences. Note that blocking some types of cookies may impact your experience on our websites and the services we are able to offer.

Essential Website Cookies

These cookies are strictly necessary to provide you with services available through our website and to use some of its features.

Because these cookies are strictly necessary to deliver the website, refusing them will have impact how our site functions. You always can block or delete cookies by changing your browser settings and force blocking all cookies on this website. But this will always prompt you to accept/refuse cookies when revisiting our site.

We fully respect if you want to refuse cookies but to avoid asking you again and again kindly allow us to store a cookie for that. You are free to opt out any time or opt in for other cookies to get a better experience. If you refuse cookies we will remove all set cookies in our domain.

We provide you with a list of stored cookies on your computer in our domain so you can check what we stored. Due to security reasons we are not able to show or modify cookies from other domains. You can check these in your browser security settings.

Other external services

We also use different external services like Google Webfonts, Google Maps, and external Video providers. Since these providers may collect personal data like your IP address we allow you to block them here. Please be aware that this might heavily reduce the functionality and appearance of our site. Changes will take effect once you reload the page.

Google Webfont Settings:

Google Map Settings:

Google reCaptcha Settings:

Vimeo and Youtube video embeds:

Privacy Policy

You can read about our cookies and privacy settings in detail on our Privacy Policy Page.

Privacy Policy
Accept settingsHide notification only