Truminds 5G core now supports N3IWF

In this blog, we will go about how we went on implementing N3IWF (Non 3GPP Interworking Function) in Truminds 5G Core Network Solution, known as Trucore.

Here’s a bird’s eye view of the 5G network. I always imagine in my head that the mobile is towards the far left, UPF (User Plane Function)/Control Plane is in the middle and the Internet is on the right side. Something like this –

The UE is our mobile phone

The RAN (Radio Access Network) comprises of an antenna system also known as the gNB. It is the gNB which provides the air interface signal to our mobile. If the signal strength is good, then we are all happy.

The Control Plane is really the brains of the network and comprises of a series of NF’s (Network Functions) like the AMF, SMF, AUSF, UDM and a few others. Each has a specific responsibility. The main idea is that the UE, via the gNB, initially contacts the Control Plane using signaling to setup a call. The Control Plane then programs the UPF to prepare for end-to-end data transfer. And then when the call is setup, the Control Plane gets out of the way of main data which travels from mobile to gNB to UPF to the Internet and all the way back to the mobile.

Now imagine that your mobile is at a location, say at the basement of a building, where there is no signal available from the gNB. We have all been there, haven’t we! Sometimes even at our homes the signal is quite weak, and we struggle to make good voice calls. But we almost always have access to a good Wifi signal at our homes. So, in short, if we are in a location where the 5G cellular signal is weak or not available at all but the Wifi strength is good, can we somehow make use of the Wifi to make calls as usual as we would have, and here is the key, as if the 5G cellular signal were to be available?

The answer to the above question is a yes thanks to a special network function in the 5G core network called the N3IWF. A picture is worth a thousand words, so let’s take a quick peek below at what we are talking about.

As you can see in the above picture, UE can connect to N3IWF over the internet access using the Wifi presumably because the UE does not have a good cellular signal. The UE can then follow the same signaling that it would have with the Control Plane via RAN, but in this case via the N3IWF instead. Once the call setup is complete, the Control Plane programs the UPF as usual, except that the UPF will send the downlink data to the N3IWF instead of the gNB and also receive the uplink data from the N3IWF instead of the gNB. Effectively the data transfer path is from UE to N3IWF to UPF to Internet and all the way back. This also explains why it is called the N3IWF. The UE is accessing the 5G core network without the traditional 3GPP Radio Access Network (hence non 3GPP), instead it is using the internet, and the N3IWF is acting like an interworking function to hookup the mobile to the 5G core.

The best part is all of the above happens transparently for the UE user, so effectively the user enjoys all the experience of 5G even if the 5G cellular signal is not present which is wonderful, isn’t it!

All of the above is great, but there would certainly be some security concerns because the UE sending data over the internet to the N3IWF. This inherently seems less secure than sending data over the air interface towards the gNB. To address these security concerns, 3GPP decided that the UE would form an IPSec tunnel first towards the N3IWF. Then all the signaling data and the end-to-end traffic would be sent and received by the UE inside this IPSec tunnel. Thus, any eavesdropper on the Internet who observes the packet on the Wifi network and at any path between the UE and the N3IWF would just see some garbled data. The N3IWF of course terminates the IPSec tunnel and takes the packets coming from the UE inside this tunnel and send them to either the Control Plane or the UPF and all the way back too.

Now let’s see some of the protocols involved.

First of all, to negotiate the keys for the IPSec tunnel, a protocol called IKEv2 is used. Essentially the UE and N3IWF talk the IKEv2 protocol to each other to setup the IPSec keys securely.

Next comes the signaling for the call setup where the UE talks to the Control Plane. Part of this signaling happens inside the IKEv2 protocol. However, once the IKEv2 signaling leads to the formation of the first IPSec tunnel (also called a Child Security Association), this first child tunnel is used specifically for all the subsequent signaling between the UE and the Control Plane. This means that all the signaling packets from UE will travel inside this first tunnel negotiated between UE and N3IWF with the IKEv2 protocol. But which protocol is used to send the inner IP packets inside the IPSec tunnel for this signaling? This is TCP. So essentially there is a TCP connection which is formed between the UE and the N3IWF and these TCP packets are exchanged wrapped in IPSec over the first tunnel that is formed.

And finally comes the end-to-end traffic which the UE needs to exchange with the internet. For that one or more separate tunnels are negotiated between the UE and the N3IWF again using the IKEv2 protocol. The end-to-end UE traffic is sent in these tunnels which are separate from the tunnel used for signaling data. But which protocol is used to send the inner packets inside these tunnels ? This is GRE. So essentially there is a GRE connection which is formed between the UE and N3IWF and UE packets are wrapped as GRE packets and then sent over the IPSec tunnels which were negotiated.

It should be noted that the N3IWF terminates the IPSec, TCP and GRE protocols and sends the signaling data to Control Plane just as gNB would have sent in the normal case. Eg. if gNB sends signaling data over SCTP to AMF, so does N3IWF. Just as gNB sends end to end user data over GTP-u to UPF, so does N3IWF. Likewise in the reverse direction, N3IWF receives the signaling and user data and ensures that it sends the data towards mobile in the right format – TCP or GRE -- and on the right IPSec tunnel.

All of the above is nicely captured in a couple of pictures taken from 3GPP TS 23.501 for signaling and data transfer respectively between UE and the 5G core

As you can see, N3IWF is a complex switching entity which must deal with the complexity at the following levels --

N3IWF needs a solid implementation of the IKEv2 protocol which is a reasonably complex protocol.

N3IWF needs to have a solid implementation of the user space TCP stack (we will come in just a bit regarding the reason for user space implementation)

N3IWF needs to also use GTP-u, GRE and SCTP

N3IWF comes in the Datapath of the traffic of all the mobiles going to internet and vice versa so it should typically use technologies like DPDK for high-speed packet transfer. Since DPDK works in user space and the signaling data (TCP/IPSec) also comes over the same interface from the mobile, thus the TCP implementation should also be in user space to handle millions of such TCP connections from the several mobiles.

And that is where Truminds engineers and their work came together to a crowning glory. Truminds has its own IKEv2 stack along with own implementation of IPSec algo’s so there was no dependency on any open-source toolkit. Having control of the source code meant that it could be changed as per the requirements of the N3IWF.

Truminds also has its own implementation of TCP/MPTCP user space stack which could be leveraged for N3IWF at scale.

GRE is relatively straight forward and based on Truminds experience with UPF the GTP-u was no challenge, neither was SCTP since Truminds already has its own Control Plane comprising of AMF amongst other network functions which already uses SCTP.

Truminds also built its own UE simulator to test the N3IWF which is quite a challenge because most of the protocols mentioned above are utilized at the UE too.

So it was a lot of fun implementing all of the above. If you want a demo or want a jump start on implementing your own N3IWF, please do get in touch with –Truminds at info@truminds.com or visit our website (www.truminds.com) and register for the demo.

 Reference documents –

RFC 7296 – IKEv2

RFC 2890 – GRE

RFC 3748 – EAP

RFC 4303 – ESP

3GPP TS 23.501 – 5G System Architecture

3GPP TS 23.502 – 5G System Aspects

3GPP TS 24.502 – Non 3GPP Access

Ethereum: 0xfcE2493F55c23c2f15791bf66dd9498Ed302548A

Bitcoin: 14FPc8Kq4tqbjHm6H2ygJYYEZTgk1Z6ruf

Tron: TMd9ryE8V9CXgbDNFbq2NmsRxNSqy7FYP1

Unstoppable Domain: praupadhyaya.crypto

Blog by Prashant Upadhyaya, VP - Technology at Truminds Software Systems