Truminds 5G Core Technology Solution (TruCore) now has TNGF (in addition to N3IWF)

In this blog, I am going to tell you about how we went about implementing TNGF (Trusted Non 3GPP Gateway Function) in Truminds 5G Core, popularly known as Trucore.

Here is 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 set up a call. The Control Plane then programs the UPF to prepare for end-to-end data transfer. And then when the call is set up, 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 in our homes the signal is quite weak, and we struggle to make good voice calls. But we almost always have access to a good Wi-Fi 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 Wi-Fi strength is good, can we somehow make use of the Wi-Fi 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 couple of a special network functions in the 5G core network called the N3IWF and the TNGF. 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, the UE can connect to N3IWF or TNGF over the internet access using the Wi-Fi 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/TNGF 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/TNGF instead of the gNB and also receive the uplink data from the N3IWF/TNGF instead of the gNB. Effectively the data transfer path is from UE to N3IWF/TNGF to UPF to Internet and all the way back. In the case of TNGF the operator might have his own network from the wireless access point (AP) towards the TNGF since it is a trusted network.

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!

So, what’s the difference between N3IWF and TNGF – this is a natural question. The answer lies in the ‘trust’ level of access. In case of N3IWF, the 5G core network operator has zero trust in the Wi-Fi network using which the UE is trying to come in. Thus, IPSec tunnel is first established using IKEv2 protocol and all signaling, and data happens either in the IKEv2 or the IPSec tunnels. However, in case of TNGF, the 5G core network operator ‘trusts’ the Wi-Fi network using which the UE is coming in. Presumably the same operator has deployed this Wi-Fi network for better coverage. So in this case, we don’t really need IPSec based encryption for data between UE and TNGF because the trust is already there. However, to keep the architecture similar between N3IWF and TNGF, the IKEv2 and IPSec are still used between the UE and the TNGF, but to save on compute resources, the so-called NULL encryption is used. So, the entire transport infra remains very similar but with the usage of the NULL encryption over IPSec. This also explains why the TNGF is called TNGF – Trusted Non 3GPP Access Gateway Function.

So, this means that if you understand N3IWF, then you already understand most of the details of TNGF because they are very similar.

I refer you to read the article which I wrote on N3IWF sometime ago, here’s the link –

https://www.dhirubhai.net/pulse/truminds-5g-core-now-supports-n3iwf-truminds-software-systems%3FtrackingId=JfnnoJKiPaJ%252FgK9HAmg35g%253D%253D/?trackingId=JfnnoJKiPaJ%2FgK9HAmg35g%3D%3D

But there is a subtle difference between the TNGF and N3IWF which deserves our attention.

In N3IWF, the UE authentication happens within the IKE_AUTH messages using EAP protocol. This is because there is zero trust with the Wi-Fi network so the IKEv2 is the first level of interaction between the UE and the N3IWF. The following picture captures this (source: 3GPP TS 24.502)

On the other hand, in the case of TNGF, the UE is authenticated using the link layer protocol of Wi-Fi first. The UE still employs EAP, but these EAP messages are exchanged between the UE and TNGF even before the IKEv2 protocol is used. Remember that there is a Wi-Fi Access Point (AP) between the UE and the TNGF. Let’s henceforth call this AP TNAP (Trusted Non 3GPP AP). The combination of TNAP and TNGF is called the TNAN (Trusted Non 3GPP Access Network) Let’s look at the following picture for the TNGF for EAP interactions (before the IKEv2 is used) – source: 3GPP TS 24.502

So, as we can see from the above picture, the UE talks EAP to the TNAP over the Wi-Fi link layer. However, the EAP must be transported all the way to TNGF. 3GPP leaves this transport as outside its scope. However, AAA (over Diameter) is becoming a popular choice for this. Truminds has also chosen this option. For this TNGF uses the open-source free diameter (https://www.freediameter.net/) in its TNGF product. Once the UE is authenticated with EAP, then the IKEv2 dialog begins as is shown in the picture above. For a minor detail, once the UE is authenticated, a so called TNAP key is generated by TNGF and provided to the TNAP using which the messages are encrypted/authenticated between the UE and the TNAP. There is also the question of who allocates the initial IP to the UE when the UE connects first to the wireless network. This can be done either via the TNAP or by the TNGF (eg. via cooperation with a DHCP server) – 3GPP leaves this to implementation.

And as I mentioned before, once the UE authentication is achieved the operations in TNGF are very similar to the N3IWF including IKEv2 and IPSec signaling and data except that NULL encryption is used in case of TNGF over the IPSec tunnels.

One good thing that Truminds has done is that the code base for N3IWF and TNGF is the same. The executable produced is the same for both. At runtime, the user can choose via a configuration whether the executable must run as N3IWF or as TNGF. This is expected to be useful because it is likely that the same operator would need both the modes presumably because part of the network is deployed as trusted Wi-Fi network and naturally the operator wants to support the untrusted access as well.

If you need a demo of this product from Truminds, please do get in touch with: [email protected] or reach out to us via the Contact page of Truminds website.

Reference documents –

RFC 7296 – IKEv2

RFC 2890 – GRE

RFC 3748 – EAP

RFC 4303 – ESP

RFC 2410 - The NULL Encryption Algorithm and Its Use With IPsec

3GPP TS 23.501 – 5G System Architecture

3GPP TS 23.502 – 5G System Aspects

3GPP TS 24.502 – Non 3GPP Access

Articulated by Prashant Upadhyaya, VP Technology at Truminds.....