Problem with gNB when modiyfing QoS over N5 -- PduSessionResourceModifyItems failed to setup

[NUCLEAR-WAR]

Issue Description

I am currently writing routing logic for N5 communication between Kamailio P-CSCSF and Open5GC see here, currently I'm encountering a Problem when I send a session modification for QoS, gNB answers with "PDU Session Resource Modification Routine" Invalid PduSessionResourceModification"

Setup Details

Open5gc_docker solution with Kamailio as IMS Core, QoS using N5 Interface RF is B210mini with GPSDO, OS is Ubuntu Server 22.04

Expected Behavior

PduSessionResourceModification should be successful

Actual Behaviour

PDU Session Resource Modification Routine" Invalid PduSessionResourceModification

Steps to reproduce the problem

start Open5GC + IMS configured with N5 configuration. Register the device and make a call On 183 and 200 the P-CSCF sends npcf-policyauthorization_update to the created session. gNB answers with : PDU Session Resource Modification Routine" Invalid PduSessionResourceModification

Additional Information

Using Open5gc with those PRs 348-349-350 from here.

logs and pcaps :

gNB IP is : 192.168.199.168 VoNR_QoS_N5_PDUSessionfailed.zip

gNB :

2024-08-09T23:13:35.010684 [GNB     ] [I] Built in Release mode using commit 4ac5300d4 on branch main)
2024-08-09T23:42:08.404826 [CU-CP   ] [W] QFI=2 already exists
2024-08-09T23:42:08.404827 [CU-CP   ] [W] ue=7: "PDU Session Resource Modification Routine" Invalid PduSessionResourceModification
2024-08-09T23:42:08.404827 [CU-CP   ] [W] ue=7: "PDU Session Resource Modification Routine" failed
2024-08-09T23:42:08.404831 [NGAP    ] [W] ue=7 ran_ue=7 amf_ue=27: Some or all PduSessionResourceModifyItems failed to setup
2024-08-09T23:42:28.033191 [NGAP    ] [W] ue=8 ran_ue=8 amf_ue=28: Some or all PduSessionResourceSetupItems failed to setup
2024-08-09T23:45:27.321000 [CU-CP   ] [W] QFI=2 already exists
2024-08-09T23:45:27.321001 [CU-CP   ] [W] ue=10: "PDU Session Resource Modification Routine" Invalid PduSessionResourceModification
2024-08-09T23:45:27.321002 [CU-CP   ] [W] ue=10: "PDU Session Resource Modification Routine" failed
2024-08-09T23:45:27.321005 [NGAP    ] [W] ue=10 ran_ue=10 amf_ue=30: Some or all PduSessionResourceModifyItems failed to setup

HTTP2 Request to PCF : Headers :

Stream: HEADERS, Stream ID: 1, Length 266, PATCH /npcf-policyauthorization/v1/app-sessions/33

    Header: :method: PATCH
    Header: :path: /npcf-policyauthorization/v1/app-sessions/33
    Header: :scheme: http
    Header: :authority: 172.22.0.27:7777
    Header: user-agent: PCSCF
    Header: accept: */*
    Header: content-type: application/merge-patch+json
    Header: 3gpp-sbi-discovery-target-nf-type: NRF
    Header: accept: application/json
    Header: accept: application/problem+json
    Header: 3gpp-sbi-max-rsp-time: 10000
    Header: 3gpp-sbi-discovery-service-names: npcf-policyauthorization
    Header: 3gpp-sbi-sender-timestamp: Fri, 09 Aug 2024 23:45:27 UTC
    Header: content-length: 732
    [Full request URI: http://172.22.0.27:7777/npcf-policyauthorization/v1/app-sessions/33]

JSON for PATCH request :

{
   "ascReqData":{
      "afAppId":"+g.3gpp.icsi-ref=\"urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel\"",
      "dnn":"ims",
      "medComponents":{
         "0":{
            "medCompN":1,
            "medType":"AUDIO",
            "codecs":[
               "downlink\nEVS/16000\n",
               "uplink\nEVS/16000\n"
            ],
            "medSubComps":{
               "0":{
                  "fNum":1,
                  "fDescs":[
                     "permit out 17 from 172.22.0.140 10050 to 192.168.105.24 50024",
                     "permit in 17 from 192.168.105.24 50024 to 172.22.0.140 10050"
                  ],
                  "fStatus":"ENABLED"
               },
               "1":{
                  "fNum":2,
                  "fDescs":[
                     "permit out 17 from 172.22.0.140 10051 to 192.168.105.24 50025",
                     "permit in 17 from 192.168.105.24 50025 to 172.22.0.140 10051"
                  ],
                  "fStatus":"ENABLED"
               }
            }
         }
      },
      "evSubsc":{
         "events":[
            {
               "event":"QOS_NOTIF",
               "notifMethod":"PERIODIC"
            },
            {
               "event":"ANI_REPORT",
               "notifMethod":"ONE_TIME"
            }
         ]
      },
      "notifUri":"http://172.22.0.21:8284"
   }
}

[NUCLEAR-WAR]

can anyone help with this issue ? the srsGNB is crushing and the version from the main branch is silently stopping to work and need a restart.

[andrepuschmann]

He, it's holiday time for most of the core development team so answers might take a bit longer than usual.

[andrepuschmann]

Hey - it seems you're trying to modify an existing QoS Flow which isn't supported right now. I was trying to see the original PDUSessionResouceSetupRequest but I couldn't spot it in the PCAP. Could you perhaps run the test again and enable NGAP pcaps on the gNB?

[NUCLEAR-WAR]

Hi @andrepuschmann,

here are all pcap and the log file that the gNodeB generated, I also ran a tcpdump on the host.

gnb_pcap_logs.zip

Best Regards

[andrepuschmann]

The only difference I can spot in the Modify request is that it doesn't contain the gBR-QosInformation:

The original setup:

And the modify:

I am not sure what is the intention of the core here - why remove the GBR for the flow? But ok - the right solution would be too modify the DRB on the DU as well and remove the GBR for the flow.

Could you try this trivial patch here and let me know if you can progress further?

diff --git a/lib/cu_cp/up_resource_manager/up_resource_manager_helpers.cpp b/lib/cu_cp/up_resource_manager/up_resource_manager_helpers.cpp
index a401b03a3b..d667c844b1 100644
--- a/lib/cu_cp/up_resource_manager/up_resource_manager_helpers.cpp
+++ b/lib/cu_cp/up_resource_manager/up_resource_manager_helpers.cpp
@@ -149,7 +149,7 @@ bool srsran::srs_cu_cp::is_valid(const cu_cp_pdu_session_resource_modify_request
       // Until then: Reject request if QoS flow to add already exists.
       if (context.qos_flow_map.find(qos_flow.qos_flow_id) != context.qos_flow_map.end()) {
         logger.warning("{} already exists", qos_flow.qos_flow_id);
-        return false;
+        // return false;
       }
     }

[NUCLEAR-WAR]

Hi @andrepuschmann,

during the INVITE I sent create AppSession for Audio QoS over N5 along with BW Info, after getting SDP Answer I did not send the BW Info on the modify as there is nothing changed, sometimes the media direction (ENABLED-UPLINK; ENABLED DOWNLINK ..etc), but I had it very simple, anyway I changed the logic to also send the BW in the N5 Modify request to the PCF but nothing changed, also tried the patch did not change anything.

Here is the traces for both Core and gNodeB to provide more view on what is happening between the P-CSCF and the PCF. Test2 : contains the trace without applying the PATCH but sending the BW Info on N5 modify request, also the core signaling included ´. With patch : this is from the test after modifying the code as requested.

gng_issue_test2.zip

Best Regards

[BurmazDaniel]

Hi @andrepuschmann

I am also intresed in a fix to this issue. The change in up_resource_manager_helpers.cpp dose not solve it.

[andrepuschmann]

Hey @NUCLEAR-WAR , @BurmazDaniel - I've had a look a the PCAPs and I am afraid there is no quick solution to it. The change I suggested isn't enough to fully support the modification of existing QoS flows. This feature will require a bit of development work. Please feel free to reach out to info@srs.io for commercial support.

[NUCLEAR-WAR]

Hi @andrepuschmann,

first many thanks for your reply! I went to srsRAN because its opensource, I have some commercial gNBs, but It would be very nice to have the first opensource gNB that fully support VoNR, I would try to help where I can to achieve this.

Best Regards

[BurmazDaniel]

I agree with @NUCLEAR-WAR. Having a fully functional gNB with VoNR would really amplify the idea of OpenRAN and open mobile private network.

[andrepuschmann]

We currently don't support modifying an existing QoS flow. But what we do support is adding/removing QoS flows to an existing PDU session. So you can add voice and even video flows during runtime.

What I would suggest you to try is to change the logic and don't add the QoS properties to the flow as a 2nd step but instead add them straight when you create the flow.

We've tested VoNR with another 5GC/IMS solution and this approach works well. Even voice and video calls work well.

[NUCLEAR-WAR]

Hi @andrepuschmann,

Many thanks again for your reply! This approach would severely limit the use cases and defeat the purpose of QoS Flow Management, it's also not 3GPP-compliant. I'm unsure how it would perform in real-world scenarios involving multiple early responses or forks. Additionally, some implementations determine flow direction based on factors like P-Early-Media or SDP a= attributes (e.g., ENABLED-UPLINK, ENABLED-DOWNLINK, or new media sources). Waiting to add the flow until it’s received would require creating sessions with every new offer/answer this will exhaust the resources, complicating the logic in Kamailio and potentially causing it to fail, plus some devices may not like that and will release the call because of "Bearer_loss".

It would be wonderful if we can get this feature working, and will support more use cases and more 5GCs.

Best Regards

[andrepuschmann]

It's a totally valid use-case/feature and we added the issue to our internal tracking system. Let's see how we can incorporate this into our commercial roadmap - we'll keep you posted.

Could you please elaborate on your comment "it's also not 3GPP-compliant"? Is there a TS that describes the exact order of events for setting up calls and how the QoS should be signaled for each step, etc.?

I am asking because the approach we're usually taking is to take the spec of course but then to analyze traces and see what is happening in the real-world with real systems to implement what is needed. And more important - design test cases for things that should not happen.

The TS's are full of things/messages/alternative that never actually happen and nobody implements them so we need to down-select the ones we deem useful to be as efficient as possible.

[NUCLEAR-WAR]

Hi @andrepuschmann,

Thank you for taking this point, I would be very happy to see SRS gNodeB the first open source solution to support QoS flow Control.

there are a few TSs that can be viewed regarding this mechanism for example : TS 23.502 TS 29.513 TS 29.514 TS 24.501 would worth to look at.

Most of the commercial 5GC/IMS Solution that I know, modifying the current opened session, I saw a widely used P-CSCF sends first create the session with the initial INVITE and later send a modify request after it gets the first answer, this is to make sure that the access has enough BW before allowing the call, then later modifying the IP Filter in the fDescs depending on the received Answer, there is also cases with Handover.

I would agree with you about the last Statement, but this not always the case, particularly in this one it related to the main mechanism of the flow control "Create/Modify/Terminate".

Again I would like to thank you for your Help, and looking forward to test when this will be implemented.

Have a nice day!

Best Regards

[Sticcolet]

We currently don't support modifying an existing QoS flow. But what we do support is adding/removing QoS flows to an existing PDU session. So you can add voice and even video flows during runtime.

What I would suggest you to try is to change the logic and don't add the QoS properties to the flow as a 2nd step but instead add them straight when you create the flow.

We've tested VoNR with another 5GC/IMS solution and this approach works well. Even voice and video calls work well.

Hello, I have also encountered the same problem. What is the IMS/VONR solution that you have tested and passed?

@NUCLEAR-WAR @andrepuschmann I tried to modify the logic. I noticed that there was actually no important modification information in the two modification requests, so I modified it to reply with a successful response directly without any action when the base station receives a duplicate QFI. However, it seems that the core network does not recognize such a response. Is this a feasible solution?

This is my log information, and I have kept error prompts for easy access to the logs. voNR.zip

[andrepuschmann]

There has been an update on the PDU session handling that is available in the test branch. Please feel free to try again and post logs/PCAPs in case its still failing.

[NUCLEAR-WAR]

fantastic! going to test it now

[NUCLEAR-WAR]

@andrepuschmann Just tested it and I don't see the issue anymore ;) also the device is not detaching anymore due to modify request.

Great job and many many thanks for the help.

I attached the logs and PCAPs in case someone want to give more deep look.

gnb_DockerHost_newFix.zip

Best Regards

[andrepuschmann]

@NUCLEAR-WAR Thanks for confirming the fix.