AGW does not reply to NGReset from RAN

[jao-tm]

• Version: 1.9.0-1713528042-5d58c69e
• Affected Component: AGW
• Affected Subcomponent: AMF
• Deployment Environment: bare-metal

Describe the Issue

RAN (Ericsson gNB) sends NGReset, but does not receive any answer from AGW. mme.log shows 'Failed to decode PDU' and 'Failed to decode new buffer' when NGReset is received. See from packet number 300 in pcap and mme.log at same time interval, from line 634 and 'Failed to decode PDU' in line 694.

eth1-debug-0805-1.zip

0805-1_mme.log

Expected behavior

AGW should reply to NGReset

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here (e.g. logs).

[jao-tm]

This issue was reported two years ago, but apparently no fix: #11428 . @mickymkumar, @panyogesh you were assigned this. Do you have any information regarding this topic?

[mickymkumar]

We are looking into it.

[jao-tm]

What is the best way to find out why PDU decode fails? I'm using test_ngap_flows.cpp to test the PDU decode, but I cannot find any more detailed logs than this:

Expected equality of these values:
  ngap_amf_decode_pdu(&pdu, ng_reset_msg)
    Which is: -1
  RETURNok
    Which is: 0

[jao-tm]

Wireshark decodes the NGReset packet like this:

NG Application Protocol (NGReset)
    NGAP-PDU: initiatingMessage (0)
        initiatingMessage
            procedureCode: id-NGReset (20)
            criticality: reject (0)
            value
                NGReset
                    protocolIEs: 2 items
                        Item 0: id-Cause
                            ProtocolIE-Field
                                id: id-Cause (15)
                                criticality: ignore (1)
                                value
                                    Cause: misc (4)
                                        misc: unspecified (5)
                        Item 1: id-ResetType
                            ProtocolIE-Field
                                id: id-ResetType (88)
                                criticality: reject (0)
                                value
                                    ResetType: partOfNG-Interface (1)
                                        partOfNG-Interface: 1 item
                                            Item 0
                                                UE-associatedLogicalNG-connectionItem
                                                    rAN-UE-NGAP-ID: 16863625

However, it seems that AGW fails after the value field. I run the TEST_F(NgapFlowTest, TestNgapReset) in test_ngap_flows.cpp, using real values for initial_ue_message_hexbuf and ng_reset_hexbuf, i.e:

 unsigned char ng_reset_hexbuf[] = {0x00, 0x14, 0x00, 0x13, 0x00, 0x00,
                                    0x02, 0x00, 0x0f, 0x40, 0x01, 0x8a,
                                    0x00, 0x58, 0x00, 0x07, 0x40, 0x01,
                                    0x2c, 0x01, 0x01, 0x51, 0x89}

I then run ngap_amf_decode_pdu(&pdu, ng_reset_msg), and print PDU values using xer_fprint(stdout, &asn_DEF_Ngap_NGAP_PDU, &pdu):

<NGAP-PDU><NGAP-PDU>
    <initiatingMessage>
        <procedureCode>20</procedureCode>
        <criticality><reject/></criticality>
        <value>

The PDU decode seems to stop after the value field. If I use the default value for ng_reset_hexbuf, which is in the test by default, it decodes the PDU:

unsigned char ng_reset_hexbuf[] = {0x00, 0x14, 0x00, 0x0e, 0x00, 0x00,
                                     0x02, 0x00, 0x0f, 0x40, 0x02, 0x00,
                                     0x00, 0x00, 0x58, 0x00, 0x01, 0x00};
<NGAP-PDU>
    <initiatingMessage>
        <procedureCode>20</procedureCode>
        <criticality><reject/></criticality>
        <value>
            <NGReset>
                <protocolIEs>
                    <NGResetIEs>
                        <id>15</id>
                        <criticality><ignore/></criticality>
                        <value>
                            <Cause>
                                <radioNetwork><unspecified/></radioNetwork>
                            </Cause>
                        </value>
                    </NGResetIEs>
                    <NGResetIEs>
                        <id>88</id>
                        <criticality><reject/></criticality>
                        <value>
                            <ResetType>
                                <nG-Interface><reset-all/></nG-Interface>
                            </ResetType>
                        </value>
                    </NGResetIEs>
                </protocolIEs>
            </NGReset>
        </value>
    </initiatingMessage>
</NGAP-PDU>

[mickymkumar]

This issue was reported two years ago, but apparently no fix: #11428 . @mickymkumar, @panyogesh you were assigned this. Do you have any information regarding this topic?

We are updating our ASN feature. Once it is pushed I will inform you and it will resolve this issue as well

[mickymkumar]

What is the best way to find out why PDU decode fails?

Share your logs and I can help you around PDU decode fails

[jao-tm]

This issue was reported two years ago, but apparently no fix: #11428 . @mickymkumar, @panyogesh you were assigned this. Do you have any information regarding this topic?

We are updating our ASN feature. Once it is pushed I will inform you and it will resolve this issue as well

What is the timeline for the ASN update? I've tried the branch asn_upgrade, but it does not seem to solve the problem.

What is the best way to find out why PDU decode fails?

Share your logs and I can help you around PDU decode fails

Any specific logs? mme.log and pcap is already provided in post

[mickymkumar]

There is no timeline. The code has not been pushed in the repo.

And, can you share the actual file for mme, syslog, pcap?

[jao-tm]

Sure, here are the log files. Is there a way to print the ASN packets?

NG Reset.zip

[jao-tm]

Were able to decode PDU, but now a new error occurs:

000401 Thu May 16 15:19:08 2024 7F66A97FA700 INFO  NGAP   tasks/ngap/ngap_amf.c           :0090    Received msg from :[TASK_SCTP] id:[113] name:[SCTP_DATA_IND]
000402 Thu May 16 15:19:08 2024 7F66A97FA700 INFO  NGAP   tasks/ngap/ngap_amf_handlers.c  :2280    No UEs connected, still proceeding with GNB Initiated Reset. gNB Id = 103
000403 Thu May 16 15:19:08 2024 7F66A97FA700 INFO  NGAP   tasks/ngap/ngap_client_servicer.:0063    Sending msg to :[TASK_AMF_APP] id: [92]-[NGAP_GNB_INITIATED_RESET_REQ]
000404 Thu May 16 15:19:08 2024 7F66CF7FE700 INFO  AMF-AP tasks/amf/amf_app_main.cpp      :0066    Received msg from :[TASK_NGAP] id:[92] name:[NGAP_GNB_INITIATED_RESET_REQ]
000405 Thu May 16 15:19:08 2024 7F66CF7FE700 INFO  AMF-AP tasks/amf/amf_app_handler.cpp   :2024     gNB Reset request received. gNB id = 103, reset_type  1

000406 Thu May 16 15:19:08 2024 7F66CF7FE700 ERROR AMF-AP tasks/amf/amf_app_handler.cpp   :2028    Invalid UE list received in gNB Reset Request

debug.zip

[mickymkumar]

Sure, here are the log files. Is there a way to print the ASN packets?

NG Reset.zip

I don't think so. but I check if there a way to flitter ASN

[mickymkumar]

tentative date is May 29 for update code change. But need to discuss to tsc team for update and changes as well.

[jao-tm]

The AGW still doesnt ack the ng-reset message. The mme.log error is from amf_app_handler.cpp. It seems that the gnb_reset_req message for some reason is decoded wrongly. Which debugging options do we have? The pcap file contains RAN_UE_NGAP_ID, so the "invalid ue list" error should not occur.

Is partial reset implemented? Issue 11800 closed without any fix (as far as I can see), which makes me wondes if M5G_RESET_PARTIAL is implemented. It exist multiple places, i.e. ngap_message_types.h, but in ngap_amf_handlers.c the switch only consist M5G_RESET_ALL.

Has anyone else tested with M5G_RESET_PARTIAL in NGReset message?

[mickymkumar]

I don't think the code has been pushed yet. let me check if anyone M5G_RESET_PARTIAL in NGReset message.