Bug #6358


SMS from 4G fails - RP-DATA (MO) without DST or TPDU ?!?

Added by keith 15 days ago. Updated 14 days ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


WE currently cannot send SMS from a UE on 4G RAN

RP-DATA (MO) without DST or TPDU ?!?

20240213001943906 DLSMS DEBUG trans(SMS IMSI-334070000000968:MSISDN-68070122968:TMSI-0x1DCB852B:EUTRAN-SGs:CM_SERVICE_REQ callref-0x4000000c tid-8) RX_RP-DATA: src_len=0, dst_len=0 ud_len=15 (gsm_04_11.c:768)
20240213001943906 DLSMS ERROR trans(SMS IMSI-334070000000968:MSISDN-68070122968:TMSI-0x1DCB852B:EUTRAN-SGs:CM_SERVICE_REQ callref-0x4000000c tid-8) RP-DATA (MO) without DST or TPDU ?!? (gsm_04_11.c:775)
20240213001943906 DLSMS NOTICE trans(SMS IMSI-334070000000968:MSISDN-68070122968:TMSI-0x1DCB852B:EUTRAN-SGs:CM_SERVICE_REQ callref-0x4000000c tid-8) TX: SMS RP ERROR, cause 96 (Invalid Mandatory Information) (gsm_04_11.c:714)

Maybe this is due to a change in latest open5gs?


SGsAP.pcapng SGsAP.pcapng 8.86 KB keith, 02/13/2024 12:34 AM

Related issues

Related to OsmoMSC - Bug #6207: "MO SMS without prior CM Service Request" for every SMS in 4GFeedbackdexter10/05/2023

Actions #1

Updated by keith 15 days ago

  • Related to Bug #6207: "MO SMS without prior CM Service Request" for every SMS in 4G added
Actions #2

Updated by keith 15 days ago

So, as can be seen in the pcap, the RP-DATA in this NAS message container from open5gs does not have any RP-Destination Address field. (length is 0)
So we fail here:

    if (!dst_len || !dst || !rpud_len || !rp_ud) {
        LOG_TRANS(trans, LOGL_ERROR,
            "RP-DATA (MO) without DST or TPDU ?!?\n");
        gsm411_send_rp_error(trans, rph->msg_ref,
        return -EIO;

Question: Is this an error on the part of open5gs, or is this RP-DATA spec-legal and we should parse the RP-User Data (TPDU) for the destination address?

NAS message container
    Element ID: 0x16
    Length: 23
        Protocol Discriminator: SMS messages (9)
            .... 1001 = Protocol discriminator: SMS messages (0x9)
            0... .... = TI flag: allocated by sender
            .101 .... = TIO: 5
        DTAP Short Message Service Message Type: CP-DATA (0x01)
        CP-User Data
            Length: 20
            RPDU (not displayed)
    GSM A-I/F RP - RP-DATA (MS to Network)
        Message Type RP-DATA (MS to Network)
        RP-Message Reference
            RP-Message Reference: 0xba (186)
        RP-Originator Address
            Length: 0
        RP-Destination Address
            Length: 0
        RP-User Data
            Length: 15
            TPDU (not displayed)
        0... .... = TP-RP: TP Reply Path parameter is not set in this SMS SUBMIT/DELIVER
        .0.. .... = TP-UDHI: The TP UD field contains only the short message
        ..0. .... = TP-SRR: A status report is not requested
        ...0 0... = TP-VPF: TP-VP field not present (0)
        .... .1.. = TP-RD: Instruct SC to reject duplicates
        .... ..01 = TP-MTI: SMS-SUBMIT (1)
        TP-MR: 186
        TP-Destination-Address - (68070144444)
            Length: 11 address digits
            1... .... = Extension: No extension
            .000 .... = Type of number: Unknown (0)
            .... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1)
            TP-DA Digits: 68070144444
        TP-PID: 0
            00.. .... = Defines formatting for subsequent bits: 0x0
            ..0. .... = Telematic interworking: no telematic interworking, but SME-to-SME protocol
            ...0 0000 = The SM-AL protocol being used between the SME and the MS: 0
        TP-DCS: 0
            00.. .... = Coding Group Bits: General Data Coding indication (0)
            Special case, GSM 7 bit default alphabet
        TP-User-Data-Length: (2) depends on Data-Coding-Scheme
            SMS text: Ok

Actions #3

Updated by keith 14 days ago

Looking at three phones, and capturing this time the S1AP between the radio and open5gs, (open5gs at a glance and a guess, is simply forwarding the NAS msg container verbatim)

The HTC is indeed sending

RP-Destination Address
    Length: 0

The other two phones, a samsung and a xiaomi send:

RP-Destination Address - (7)
    Length: 2
    1... .... = Extension: No Extension
    .001 .... = Type of number: International Number (0x1)
    .... 0001 = Numbering plan identification: ISDN/Telephony Numbering (ITU-T Rec. E.164 / ITU-T Rec. E.163) (0x1)
    Called Party BCD Number: 7

So it looks like we need osmo-msc to accept zero length RP-Destination Address?

Actions #5

Updated by laforge 14 days ago

Hi Keith,

On Tue, Feb 13, 2024 at 06:25:33PM +0000, keith wrote:

Looking at three phone, and capturing this time, the S1AP between the radio and open5gs, the htc is indeed sending [...]

Are you sure you're using the same SIM card between those attempts? Maybe the EF.SMSP contains different conten between your different phones? Didn't the RP-layer normally contain the GlobalTitle of the SMSC? Or am I mixing things here (sorry, just recalling off my head).

Actions #6

Updated by keith 14 days ago

  • Status changed from New to Closed
  • Priority changed from High to Normal

After reading some TS 100 942 (04.11), TS 23.272 and TS 23.040:

I see, RP-DA is the SMSC number. Somebody (!) programmed a SIM card without any SMSC number. :-(

I guess it's all good.

Actions #7

Updated by fixeria 14 days ago

keith wrote in #note-3:

The HTC is indeed sending [...]

keith are you sure you have the SMSC address configured on that HTC phone?
I think we have already seen such behavior in the absence of SMSC address. Some phones require the user to set it before sending SMS, some do not and send with empty RP-Destination Address.

Actions #8

Updated by keith 14 days ago

Thanks laforge and fixeria, Yes I realised what was going on after checking that the spec indeed requires a min length of 2 for the RP-DA and that there are no variations allowed for SMS over SGs, and also observing that the htc phone with this SIM also sends RP-DA of zero length on 2G.

Funny, this post from 2010, (back in the openBTS at the Burning Man days) came into my head, so I'll just leave this link here as it took a while to find it:

It's not the same issue as no SMSC configured, but maybe somebody is looking up SMSC problems sometime in the future..


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)