SMS technology has been specified by the ETSI in GSM 03.40 and 03.38 documents (3GPP TS 23.040 and 3GPP TS 23.038 respectively). These documents only describe how to use SMS over mobile networks (nothing for IP networks).
In real world there are two way to receive SMS messages over mobile networks: Binary (PDU) and Text mode.
In this post I will explain how to use SMS technology over IP within the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and SIP Events as defined in 3GPP TS 24.229.
Note: In the coming chapters, « SMS over IMS Network » and « SMS over IP Network » have the same meaning.
Text mode
The message payload is transfered « as is ». This mode is out of scope.
Binary mode
Also know as PDU (Protocol Data Unit) mode, it is use to encode the payload of the SMS sent over IMS networks. In this case the payload only contains a sequence of hexa-decimal octets or decimal semi-octets strings. The overall PDU string contains some useful information (SMSC address, Service center time stamp, sender number, message reference ...) plus the actual message.
The message length can be up to 160 characters where each character represent 7bits [160/7bits], [140/8bits] or [70/16bits]. By default, each character represent 7bits encoded as per GSM 03.38.
For IMS Networks, SMS message shall be encapsulated in RPDUs (Relay Protocol Data Unit) data string as defined in 3GPP TS 24.011, subclause 7.3. The RPDU data is transfered from SM entity to SM entity using SIP MESSAGE requests. These SIP requests shall use the MIME type "application/vnd.3gpp.sms" for this purpose.
GSM 7 bit Default Alphabet
Each character represent 7bits. For more information see 3GPP TS 23.038 or ETSI GSM 03.38.
3GPP IMS Registration
On sending a REGISTER request, the IMS Client shall indicate its capability to receive traditional short messages over IMS network by including a "+g.3gpp.smsip" parameter into the Contact header according to RFC 3840.
Figure 2: SIP/IMS registration request
Mobile-Originated SMS (MO-SMS)
The IMS Client sender shall build and populate RP-DATA message (RPDU encapsulating TPDU data string), containing all the information that a mobile station submitting an SMS message according to 3GPP TS 24.011 would place, for successful delivery. The sender shall parse and interpret RP- DATA, RP-ACK and RP-ERROR messages, containing all the information that a mobile station receiving an SM according to 3GPP TS 24.011 would see, in a SM submission or status report.
Figure 3: Signaling flows demonstrating successful UE originated SM submit procedure over IP as per 3GPP TS 24.341
** [1,2,4] RP-DATA (SMS-SUBMIT)
Below is represented the first request (RP-DATA(SMS-SUBMIT)) sent from the IMS Client to the P-CSCF.
Figure 4: RP-DATA(SMS-SUBMIT) from Mercuro to the P-CSCF
The SIP MESSAGE (Figure 4) request sent from the IMS client to the P-SCSF carry the RP-DATA (Mobile station to IMS Network) message encoded as per 3GPP TS 24.011 chapter 7.3.1.2.
Figure 5: RP-DATA (Mobile Station to Network) as per 3GPP TS 24.011 subclause 7.3.1.2
The SIP MESSAGE content (Figure 4) can be dissected as following:
RP-MESSAGE: 000000069133010000F019069133010000F011000A9133163254760000AA05F330BB4E07
RPDU:000000069133010000F019
TPDU (SMS-SUBMIT):069133010000F011000A9133163254760000AA05F330BB4E07
RPDU:000000069133010000F019
The RP-MESSAGE can be dissected as follow (Figure 6):
Figure 6: RP-DATA (Mobile Station to Network) content dissection
** [9,10,11] RP-ACK(SMS-SUBMIT-REPORT)
The SIP MESSAGE payload includes the RP-ACK message. Its RP-User-Data information element includes a TPDU of type SMS-SUBMIT-REPORT.
Figure 7: RP-ACK as per 3GPP TS 24.011 subclause 7.3.3
For more information, see 3GPP TS 24.011 subclause 7.3.3 for RPDU (RP-ACK) data and 3GPP TS 23.040 subclause 9.2.2.2a for TPDU (SMS-SUBMIT-REPORT) encoding. If error occurs when decoding the message, RP-ERROR (3GPP TS 24.011 subclause 7.3.4) message is sent instead of RP-ACK.
Mobile-Terminated SMS (MT-SMS)
Figure 8: UE originated SM deliver procedure over IP signaling as per 3GPP TS 24.341
** [2,3,4] RP-DATA(SMS-DELIVER)
This request sent from the IP-SM-GW includes a vnd.3gpp.sms payload that includes the short message and routing information for the S-CSCF to forward the short message.
The payload includes the RP-DATA message. Its RP-User-Data information element includes a TPDU of type SMS-DELIVER.
Figure 9: RP-DATA (Network to Mobile Station ) as per 3GPP TS 24.011 subclause 7.3.1.1
The payload includes the RP-DATA message. Its RP-User-Data information element includes a TPDU of type SMS-DELIVER.
Figure 9: RP-DATA (Network to Mobile Station ) as per 3GPP TS 24.011 subclause 7.3.1.1RP-MESSAGE: 0100069133010000F0001E069133010000F0040A91331632547600000000000000000005F330BB4E07
For more information, see 3GPP TS 24.011 subclause 7.3.1.1 for RPDU (RP-DATA) data and 3GPP TS 23.040 subclause 9.2.2.1 for TPDU (SMS-DELIVER) encoding.
** [8,9,11] RP-ACK(SMS-DELIVER-REPORT)
RP-MESSAGE:020109069133163254760080
** [8,9,11] RP-ACK(SMS-DELIVER-REPORT)
This request includes a vnd.3gpp.sms payload that includes the SMS-DELIVER-REPORT and routing information for the IP-SM-GW to forward the delivery report.
The payload includes an RP-ACK message. Its RP-User-Data information element includes a TPDU of type SMS-DELIVER-REPORT.
The payload includes an RP-ACK message. Its RP-User-Data information element includes a TPDU of type SMS-DELIVER-REPORT.
RP-MESSAGE:020109069133163254760080
For more information, see 3GPP TS 24.011 subclause 7.3.3 for RPDU (RP-ACK) data and 3GPP TS 23.040 subclause 9.2.2.1a for TPDU (SMS-DELIVER-REPORT) encoding.
If error occurs when decoding the message, RP-ERROR (3GPP TS 24.011 subclause 7.3.4) message is sent instead of RP-ACK.
If error occurs when decoding the message, RP-ERROR (3GPP TS 24.011 subclause 7.3.4) message is sent instead of RP-ACK.
References:
- 3GPP TS 23.038 - Alphabets and language-specific information
- 3GPP TS 23.040 - Technical realization of Short Message Service (SMS)
- 3GPP TS 24.011 - Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface.
- 3GPP TS 24.341 - Support of SMS over IP networks; Stage 3
- 3GPP TS 24.451 - Support of SMS and MMS over NGN IMS subsystem; Stage 3 [Endorsement of 3GPP TS 24.341 Release 7]
20 commentaires:
This is a great post! very helpful.
I have some questions about the pdu format, though.
1) 3GPP TS 24.011 mentions one octet ahead each information element as information element identifier(IEI) to identify what element it is, e.g. the IEI for RP-User Data is 0x41. but the spec doesn't mention IEI values for RP-Originator Address etc..which really confuses me and here I don't see IEI in your examples too. So, IEI is not required?
2) I can't find anywhere in the 3gpp TS 23.040 describes SMSC information added before TPDU. but I do see many examples including yours have smsc information element added. do you have any reference?
3) in your figure 6, the length octet for RP-UD is 0x32, which appears to have counted the semi-octets, instead of octets? do you have any reference?
Thank you for your post!
Who knows where to download XRumer 5.0 Palladium?
Help, please. All recommend this program to effectively advertise on the Internet, this is the best program!
Hi Zhi,
Thanks for your comment.
I have updated the post (RP-UDL was incorrect).
Thanks.
This is really great post and helping me out on decoding the data.
Question: I see RP-DU Length in your sample is 19hex which is 25 decimal and my parser works fine because number of character in the message is 50(25*2) after the length.
But when I send SMS using Mercuro client, it adds twice the length.
e.g If you look at this link which has a message generated by Mercuro client,
http://feedback.mercuro.net/feedbacks/379961-send-sms-being-sent-to-sip-33100000000-example-com
The RP-Message is:
000000079133010000000F34079133010000000F11000B9133060000000F0000AA04F4F29C0E
Here RP_DU length is 34Hex which is 52 decimal but number of characters after that index is 52 characters instead of (52*2)=104.
So my question is should the length be 1A which is 26dec and number of characters are 26*2=52.
Hope you understand my question.
Hi,
@Neuro Yogi
As I specified in the previous post this was an issue.
The bug has been resolved by Mercuro team and should be part of the latest release (after release 1610).
Please update your Mercuro version and enjoy.
Thanks.
Thanks for your quick response. My client version is 1610 so I will get the latest one.
Regarding PSI for SMSC, does it have to be a number? Because mercuro client doesn't allow sip URI or wild card as per the spec.
Only tel URIs or sip URIs with a tel. number(e.g. sip:+44123456@example.com) as userinfo are allowed.
Thanks for your quick response. I copied the below sip message from Table B 5.1 3gpp 24341-900 (SMS over IP)
MESSAGE sip:sc.home1.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp; branch=z9hG4bKnashds7
Max-Forwards: 70
Route: ,
P-Preferred-Identity: "John Doe"
From: ; tag=171828
To:
Call-ID: cb03a0s09a2sdfglkj490333
Cseq: 666 MESSAGE
Content-Type: applicatioContent-Length: (…)
Here request URI for MESSAGE is sip:sc.home1.net but Mercuro client would not allow to send message. It always requires phonenumer in tel or sip uri.
Also in 3gpp 24341-900 5.3.1.2 a:) The Request URI, which shall contain the PSI of the SC of the SM-over-Sender.
NOTE 1: The PSI of the SC can be SIP URI or tel URI based on operator policy.
Hi,
@Neuro Yogi
To support sip URIs without tel. numbers as userinfo you shall be able to map sip addresses to phone numbers (see e.164 for more info.).
Mercuro do not support this feature.
Perhaps will be added in the coming releases.
Thanks
Very nice post.
One thing is unclear for me - how is RP-ACK linked to originating RP-DATA at a SIP level? Do they use the same Call-Id, or they're completely independent at SIP level?
If they're independent, how out-of-order messages should be handled?
@Alexander Chemeris
You don't need to link them at Sip level. In all case you can't as SIP MESSAGE is dialog-less. Off course the RP-ACK message MUST have the same MR (message reference) value as the RP-DATA.
For information, we have open source IMS/RCS clients supporting this feature.
For Windows: http://code.google.com/p/boghe/
For Android: http://code.google.com/p/imsdroid/
Nice post.
Just one side note - The service center number may not be available in the PDU. In Boghe, I believe the service center number is required (and configurable).
Some IMS clients (if configured with an implicit service center) may set the service center number to 00.
Regards
Aayush
Mamadou, it seems all images disappeared from this post. I refer to your write-up heavily in OpenBTS SMS discussions, so I would very much appreciate if you fix them :)
Hi.
Came across your post when trying to understand SMS over SIP. Great post. One question: If the message is sent to the SM-IP-GW, why should the UE care about limitation of SMS message length? Why shouldn't the SM-IP-GW cut the content of the SIP message body into a series of legal SMS messages? Or more precise, what reference did you find saying it is the responsibility of the UE, and not the GW?
Thanks!
Great Stuff! Thanks for sharing. I would like to follow your blog for latest updates.
Hi Mamadou,
Thanks for a very useful post.
I read in one comment about IEI value, example 41 for user-data.
I want to know if IEI value is mandatory? It is present in RP-User data as per TS 24.011 but I don't see it your example.
Hi ,
I have files that encoded ASN BER encoding, this files include Mobile Cominication Systems Short messages,
I read 3gpp TS 23.040 , but ı am so confused, How can ı parse this files and get human readable short messages.
thank you for the helpful post!
Blogs are so informative where we get lots of information on any topic. Nice job keep it up! Your post is really good providing good information. New Launch Info!
Enregistrer un commentaire