VoNR calls not completing properly

[Rashed97]

Hi,

First I wanted to thank you for the wonderful setup and guides. Using this, I've successfully set up a 5G SA network with a B210 radio. Using the experimental 5G IMS PyHSS branch, I've been able to get several Android UEs to register successfully with P-CSCF/S-CSCF. The UEs show a successful registration, and SMSoIP works fine. Calls however, do not complete; the devices never even get a dial tone. P-CSCF logs show that the N5 routes seem to be working fine, so I'm not really sure where to start with this.

A note on these UEs: when I start the B210 as an eNB instead of a gNB, they can register on the LTE network and VoLTE works fine. There appears to be an issue with video calling over IMS, but I have not looked at it enough to have any idea whether that's a UE issue or IMS issue.

Please let me know what logs you'd like me to provide and I can provide those in a follow up. I'm happy to help debug this however you'd like.

Thanks!

[herlesupreeth]

@Rashed97

I've successfully set up a 5G SA network with a B210 radio.

In general the VoNR is not working as expected mainly due to failure in setting up a dedicated bearer for the call. This is still largely work in progress. Will let you know once its ready to be tested again

A note on these UEs: when I start the B210 as an eNB instead of a gNB, they can register on the LTE network and VoLTE works fine. There appears to be an issue with video calling over IMS, but I have not looked at it enough to have any idea whether that's a UE issue or IMS issue.

Regarding issue with video calls, please attach a pcap taken for below scenario

1. Start pcap
2. Register two UEs
3. Attempt video call
4. Wait for it to fail
5. Stop pcap and attach here

[Rashed97]

@herlesupreeth Thanks for the clarification.

In general the VoNR is not working as expected mainly due to failure in setting up a dedicated bearer for the call. This is still largely work in progress. Will let you know once its ready to be tested again

Are there any workarounds for this right now, or is this pretty much entirely broken in srsRAN? I’ve seen some of the discussion threads around this, and it looks like it potentially works sometimes, or am I misunderstanding?

Regarding issue with video calls, please attach a pcap taken for below scenario

1. Start pcap
2. Register two UEs
3. Attempt video call
4. Wait for it to fail
5. Stop pcap and attach here

For this, should it just be a PCAP on the host machine with -i any ?

[herlesupreeth]

Are there any workarounds for this right now, or is this pretty much entirely broken in srsRAN? I’ve seen some of the discussion threads around this, and it looks like it potentially works sometimes, or am I misunderstanding?

So far we haven't had any luck making VoNR call work when tested between two devices (as per the main contributor it worked when calling a device from an application server). I dont think there is a workaround for it. I will try to see whether this issue can be fixed easily or not.

For this, should it just be a PCAP on the host machine with -i any ?

Yes, thats right

[Rashed97]

So far we haven't had any luck making VoNR call work when tested between two devices (as per the main contributor it worked when calling a device from an application server). I dont think there is a workaround for it. I will try to see whether this issue can be fixed easily or not.

OK, great thanks. Let me know if there's anything I can help with.

For this, should it just be a PCAP on the host machine with -i any ?

Yes, thats right

Great, appreciate it, thanks. I'll grab this at my first opportunity.

[NUCLEAR-WAR]

I'm also interested in the PCAPs so I can improve the logic more.
srsRAN just dropped a Fix in the Test branch of there Repo for the modify request, maybe give it a shot and provide the traces.

just tested the new fix in my setup, but as @herlesupreeth I do a different approach, to test MOC and MTC, as I'm still fighting with the IPhone as a second device without a success attaching it to network.

here is my test for an Orig Call with the new Fix :
gnb_DockerHost_newFix.zip

[Rashed97]

I'm also interested in the PCAPs so I can improve the logic more. srsRAN just dropped a Fix in the Test branch of there Repo for the modify request, maybe give it a shot and provide the traces.

Will do, may not get to it until tomorrow evening or Saturday (I’m currently on work travel) but will do as soon as I can get to my workstation.

just tested the new fix in my setup, but as @herlesupreeth I do a different approach, to test MOC and MTC, as I'm still fighting with the IPhone as a second device without a success attaching it to network.

I’ve found Android devices to be more flexible with this setup, and can provide more detailed logging. Do you have access to any rooted Android devices or ones running custom ROMs? If not, send me an email and I can arrange that if you’d like.

[NUCLEAR-WAR]

@Rashed97 its more like vendor issues, they look down the devices to be only usable with normal Operators, not with Lab/Private, even if they attach they don't activate voice just data ( e.g. IPhones), I tried to reach Samsung for example over some internal channel, but did get any answer, not sure what the sense and reason behind looking it.

Anyway, I just bought a Xiaomi Redmi Note 12 5G and it attached perfectly to the network with both Regs/QoS VoNR directly from the experimental Branch without any issue, what I noticed though that there is no N5 upon SIP UPDATE, but everything just worked fine.

here are pcaps from my Tests with and without Precondition :

e2e_with_and_withoutPrecond.zip

@herlesupreeth, can you give it a look if there is something to be improved ?

EDITE: just to add, this test done with two devices using the experimental 5G Branch and the new srsRAN Test Branch, I repeated it many time without any issues.

[herlesupreeth]

@NUCLEAR-WAR Awesome work, I checked the pcap with precondition and it seems to work well.

what I noticed though that there is no N5 upon SIP UPDATE, but everything just worked fine.

This could be because the packet filters/flow descriptions didnt change (because SDP ports didnt change)

So basically I should update the srsRAN dockerfile to use the latest commits right?

[Rashed97]

Thank you both. I just got home after a few weeks of travel so I can resume testing as well. I’ll build an srsRAN container with the test branch shortly.

@NUCLEAR-WAR have you seen the test2 branch as well? Looks like it might have additional fixes but I haven’t gotten a chance to look at it too deeply yet.

[NUCLEAR-WAR]

@herlesupreeth

This could be because the packet filters/flow descriptions didnt change (because SDP ports didnt change)

actually, Its because I did not add the in-Dialog UPDATE to the logic that should be easy to add, this will not affect the case where we use the docker setup directlly, but could affect advanced use cases where the update could be for Ringtone/announcements injection ( the cases mostly will be using external IMS or using an AS that do some early media ).
I think I would add some condition to prevent N5 Requests spamming to only trigger in case of SDP Media/Port/IP change, I will add it to the fine tuning To-Do list.

So basically I should update the srsRAN dockerfile to use the latest commits right?
Not sure if the test branch has been migrated to teh main/master branch, in any case you need to pay attention that the setting in the .yml files changed and the ones from the docker setup will not work (least this was my experience) here is mine :

gnb.yml :

cu_cp:
  amf:
    addr: AMF
    bind_addr: GNB_IP
    supported_tracking_areas:
      - tac: 1
        plmn_list:
          - plmn: "PLMN"
            tai_slice_support_list:
              - sst: 1

ru_sdr:
  device_driver: uhd                                            # The RF driver name.
  device_args: type=b200,num_recv_frames=64,num_send_frames=64  # Optionally pass arguments to the selected RF driver.
  clock: external                                               # Specify the clock source used by the RF.
  sync:                                                         # Specify the sync source used by the RF.
  srate: 23.04                                                  # RF sample rate might need to be adjusted according to selected bandwidth.
  otw_format: sc12
  tx_gain: 80                                                   # Transmit gain of the RF might need to adjusted to the given situation.
  rx_gain: 40                                                   # Receive gain of the RF might need to adjusted to the given situation.

cell_cfg:
  dl_arfcn: 632628                                                # ARFCN of the downlink carrier (center frequency).
  band: 78                                                        # The NR band.
  channel_bandwidth_MHz: 20                                       # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 30                                                  # Subcarrier spacing in kHz used for data.
  plmn: "PLMN"                                                    # PLMN broadcasted by the gNB.
  tac: 1                                                          # Tracking area code (needs to match the core configuration).
  pci: 1                                                          # Physical cell ID.

log:
  filename: gnb.log                                   # Path of the log file.
  all_level: info                                              # Logging level applied to all layers.

pcap:
  mac_enable: true                                               # Set to true to enable MAC-layer PCAPs.
  mac_filename: gnb_mac.pcap                          # Path where the MAC PCAP is stored.
  ngap_enable: true                                              # Set to true to enable NGAP PCAPs.
  ngap_filename: gnb_ngap.pcap                        # Path where the NGAP PCAP is stored.
  f1ap_enable: true                                              # Set to true to enable F1AP PCAPs.
  f1ap_filename: gnb_f1ap.pcap                        # Path where the F1AP PCAP is stored.
  e1ap_enable: true                                              # Set to true to enable E1AP PCAPs.
  e1ap_filename: gnb_e1ap.pcap                        # Path where the E1AP PCAP is stored.
  e2ap_enable: true                                              # Set to true to enable E2AP PCAPs.
  e2ap_filename: gnb_e2ap.pcap                        # Path where the E2AP PCAP is stored.

qos.yml :

# Quality of Service (QoS) example configurations for 5QI 1, 2, 5, 7 and 9
# Based on 5QI characteristics in TS 23.501 table 5.7.4-1 

# This is a supplementary configuration to modify the RLC and PDCP radio bearers on 
# a per 5QI basis.

qos:
  -
    five_qi: 1 # E.g. Conversational Voice
    rlc:
      mode: um-bidir
      um-bidir:
        tx:
          sn: 12
          queue-size: 16384
          queue-bytes: 6172672
        rx:
          sn: 12
          t-reassembly: 50
    pdcp:
      integrity_required: false
      tx:
        sn: 12
        discard_timer: -1
        status_report_required: false
      rx:
        sn: 12
        t_reordering: 80
        out_of_order_delivery: false
    f1u_du:
      backoff_timer: 10
    f1u_cu_up:
      backoff_timer: 10
    mac:
      lc_priority: 4
      lc_group_id: 1
      bucket_size_duration_ms: 5
      prioritized_bit_rate_kBps: 65537
  -
    five_qi: 2 # E.g. Conversational Video
    rlc:
      mode: um-bidir
      um-bidir:
        tx:
          sn: 12
          queue-size: 16384
          queue-bytes: 6172672
        rx:
          sn: 12
          t-reassembly: 50
    pdcp:
      integrity_required: false
      tx:
        sn: 12
        discard_timer: -1
        status_report_required: false
      rx:
        sn: 12
        t_reordering: 80
        out_of_order_delivery: false
    f1u_du:
      backoff_timer: 10
    f1u_cu_up:
      backoff_timer: 10
    mac:
      lc_priority: 4
      lc_group_id: 1
      bucket_size_duration_ms: 5
      prioritized_bit_rate_kBps: 65537
  -
    five_qi: 5 # E.g. IMS signaling
    rlc:
      mode: am
      am:
        tx:
          sn: 12
          t-poll-retransmit: 80
          max-retx-threshold: 4
          poll-pdu: 64
          poll-byte: 125
          queue-size: 16384
          queue-bytes: 6172672
        rx:
          sn: 12
          t-reassembly: 80
          t-status-prohibit: 10
    pdcp:
      integrity_required: false
      tx:
        sn: 12
        discard_timer: -1
        status_report_required: false
      rx:
        sn: 12
        t_reordering: 80
        out_of_order_delivery: false
    f1u_du:
      backoff_timer: 10
    f1u_cu_up:
      backoff_timer: 10
    mac:
      lc_priority: 5
      lc_group_id: 2
      bucket_size_duration_ms: 5
      prioritized_bit_rate_kBps: 65537
  -
    five_qi: 7 # E.g. Voice, Video (live streaming)
    rlc:
      mode: um-bidir
      um-bidir:
        tx:
          sn: 12
          queue-size: 16384
          queue-bytes: 6172672
        rx:
          sn: 12
          t-reassembly: 50
    pdcp:
      integrity_required: false
      tx:
        sn: 12
        discard_timer: -1
        status_report_required: false
      rx:
        sn: 12
        t_reordering: 80
        out_of_order_delivery: false
    f1u_du:
      backoff_timer: 10
    f1u_cu_up:
      backoff_timer: 10
    mac:
      lc_priority: 4
      lc_group_id: 1
      bucket_size_duration_ms: 5
      prioritized_bit_rate_kBps: 65537
  -
    five_qi: 9 # E.g. Buffered video streaming, TCP-based traffic
    rlc:
      mode: am
      am:
        tx:
          sn: 12
          t-poll-retransmit: 80
          max-retx-threshold: 4
          poll-pdu: 64
          poll-byte: 125
          queue-size: 16384
          queue-bytes: 6172672
        rx:
          sn: 12
          t-reassembly: 80
          t-status-prohibit: 10
    pdcp:
      integrity_required: false
      tx:
        sn: 12
        discard_timer: -1
        status_report_required: false
      rx:
        sn: 12
        t_reordering: 80
        out_of_order_delivery: false
    f1u_du:
      backoff_timer: 10
    f1u_cu_up:
      backoff_timer: 10
    mac:
      lc_priority: 5
      lc_group_id: 2
      bucket_size_duration_ms: 5
      prioritized_bit_rate_kBps: 65537

@Rashed97

I’ll build an srsRAN container with the test branch shortly.
If you are running gNB on separated host, I would recommend that you compile it and run it directly.

@NUCLEAR-WAR have you seen the test2 branch as well? Looks like it might have additional fixes but I haven’t gotten a chance to look at it too deeply yet.

No, this is new to me my test was with the "Test" branch, not sure what the the "Test 2" has for changes, did have a look in it.

[Rashed97]

I updated to the latest srsRAN test2 branch and used @NUCLEAR-WAR your qos.yml but still not seeing the calls complete. Here is the latest pcap collection.
pcaps-241104-065617.zip

Update: alto tested with the normal test branch. Same behaviour with the call just not getting a dial tone, but not hanging up either. Here are the pcaps for that as well:
pcaps-241104-071514.zip

[NUCLEAR-WAR]

@Rashed97
can you take the trace on the Docker Host where the Open5gs+IMS are running ? need to check the N5 Flow, if anything wrong in it.

[Rashed97]

@NUCLEAR-WAR by full trace, do you mean a pcap on all interfaces? If so, here you go 😄 :
full-241105-040331.zip

Edit: also here is the log from the attached docker containers for the network core and IMS: https://gist.github.com/Rashed97/194d8ed2db912d72806949356bfc90ab

Edit: I ran tcpdump on interface "any" and filtered out port 22 since I'm SSH'ed into the machine from my laptop, but everything else is in the pcap, so you'll see a bunch of irrelevant packets as well.

[NUCLEAR-WAR]

@Rashed97 I am still looking into the trace now but have some questions:

Is the device you are using a dual SIM device and both SIM Cards are in it ? if so, try to use separated devices.

does the PC running gNB has enough resources ? not having enough resources could lead to disconnecting the device from Network, can you describe your setup ?
Is there any reason why the device is losing connectivity to the network ? each user has multiple Contacts the INVITE is sent to all its contacts, although the current N5 logic does not support Forking, at the end only the working IP is getting an AppSession ID and also modified without any complain from PCF, so for me it looks like the issue on RAN, though i could be wrong .

Best Regards

[Rashed97]

@NUCLEAR-WAR see answers below:

Is the device you are using a dual SIM device and both SIM Cards are in it ? if so, try to use separated devices.

No, the SIM cards are inserted into 2 separate devices, but they’re the same model, running the same Android build.

does the PC running gNB has enough resources ? not having enough resources could lead to disconnecting the device from Network, can you describe your setup ? Is there any reason why the device is losing connectivity to the network ? each user has multiple Contacts the INVITE is sent to all its contacts, although the current N5 logic does not support Forking, at the end only the working IP is getting an AppSession ID and also modified without any complain from PCF, so for me it looks like the issue on RAN, though i could be wrong .

Yeah sure. I’m running the entire stack on a machine without Ubuntu 24.04 with an i9-9900K and 96GB RAM. The radio is a modified B210 from Aliexpress (they’re calling it a B220 since it has an upgraded FPGA), and I’m running it with QOS, MIMO, and QAM256. The radio is a bit far from the drives so I can move them closer but I don’t think it’s a signal issue.