SRSUE used for VoNR

[lucker7777]

Hello community!
First of all, let me thank you for your work on this fun project.

Now to the topic: I do not have a physical HW, but I want to set up VoNR call over IMS. I am using sa-vonr-deploy.yaml for Core, then srsgnb_zmq.yaml and srsue_5g_zmq.yaml. Based on this suggestion, I installed PJSUA SIP client on top of UE. From there, I am able to reach PCSCF and register SIP client.

But, all the traffic between SIP client and IMS goes through eth0 interface, not via tun_srsue tunnel - thus the traffic does not pass GNB. Sure, it works, but it does not simulate real 5G.

I am struggling to understand how are those tunnels between UE and UPF set up, what they represent and how should they be utilized. I know that in UE, I can have only one APN, so I switched it from "internet" APN to "IMS" APN. So, now I have "192.168.101.2" interface in UE (this is UE_IPV4_IMS subnet in .env ). But, IMS components have a different subnet (172.22.0.0), so I do not know why there is an UE_IPV4_IMS and what it should do, considering it is not connected to IMS in any way. When UE's SIP client is reaching PCSCF on 172.22.0.0 network, everything goes through eth0.

So, should I just change IMS's subnet to UE_IPV4_IMS subnet, or something else? Or maybe I am completely wrong about it :)

[herlesupreeth]

But, all the traffic between SIP client and IMS goes through eth0 interface, not via tun_srsue tunnel - thus the traffic does not pass GNB. Sure, it works, but it does not simulate real 5G.

Your application (in your case PJSUA SIP client) should bind to that tun_srsue interface in order to simulate somewhat a VoLTE/VoNR call. Although its not complete a VoLTE/VoNR call because the application is not asking the UE stack to request a dedicated bearer to have QoS for the call.

UE_IPV4_IMS subnet is the subnet from which open5gs assigns IP to the UEs when it requests a PDN session for "ims" APN/DNN

So any any IMS traffic (from IP 192.168.101.x) first reaches eNB/gNB and then eNB/gNB encapsulates that traffic and sends it in a GTP-U tunnel to SGW-U/UPF where it gets decapsulated. Now, all that remain is the original IMS traffic. This will be routed based on the destination IP (P-CSCF IP).

So, should I just change IMS's subnet to UE_IPV4_IMS subnet, or something else? Or maybe I am completely wrong about it :)

Since your application is not binding to tun_srsue interface in order to send traffic (i.e. for example when you do ping 8.8.8.8 -I tun_srsue it binds to that interface in order to send ping packets) it using eth0 interface. This traffic over eth0 interface is not using the 4G/5G link

[lucker7777]

Alright, so binding the application to tun_srsue could indeed be solution for correct routing. I will try that.

But, besides that, why is the UE_IPV4_IMS set up to 192.168.101.X network, if all other IMS components are in default network and nothing else seems to be connected to this subnet?
Can you maybe explain what is the purpose of those tun_srsue tunnels? What should they represent? I mean once dataplane is established, there is a GTP tunnel between GNB and UPF, so why is there additional tunnel from UE?

I am not very knowledgeable about 5G, so maybe I am missing something.

[herlesupreeth]

Can you maybe explain what is the purpose of those tun_srsue tunnels? What should they represent? I mean once dataplane is established, there is a GTP tunnel between GNB and UPF, so why is there additional tunnel from UE?

tun_srsue is just a TUN interface which could be used to push traffic towards the CN. Yes, there is GTP tunnel between gNB and UPF. The traffic flow is as follows

1. Traffic from UE with IP 192.168.101.X reaches gNB using the air interface (no GTP tunnel involved here)
2. Then gNB encapsulates (IP in IP) this traffic with GTP header to send to UPF
3. Once the traffic reaches UPF, the UPF removes the GTP header. Once GTP header is removed all that is left if the IP packet from UE which has source IP as 192.168.101.X and destination as P-CSCF IP i.e. 172.22.0.X (I am assuming here its the IMS registration scenario. For internet traffic destination IP can be anything e.g. DNS server at 8.8.8.8 or anything else)
4. From this point onwards it basic linux networking to route the packet from UPF to P-CSCF