WAP Push SMS Encoding (Complete Guide)

sms encoding

As I started to explain in the last post, a WAP push consists of an XML document sent to the device over SMS. This is true but somewhat simplified.
The truth is that we send:

  • an WBXML encoded XML
  • over WSP (Wireless Session Protocol)
  • over WDP (Wireless Datagram Protocol)
  • over SMS

This is called an unconfirmed push.

It is also possible to send a confirmed push. In a confirmed push, the recipient confirms the receipt of the push message. If the recipient fails to confirm the sender is supposed to retry sending it. This is necessary mainly when WDP is over a less reliable protocol than SMS (like UDP for instance). For unconfirmed push we have to add another layer:

  • an WBXML encoded XML
  • over WSP (Wireless Session Protocol)
  • over WTP (Wireless Transaction Protocol)
  • over WDP (Wireless Datagram Protocol)
  • over SMS

Since we’re focusing on SMS in this series and SMS messages are very reliable, I’ll ignore the confirmed push in this article.

WBXML

The WAP protocol (versions 1.3 and before) relied heavily on compressing data (such as WML and XML documents) to reduce the bandwidth used by WAP. WAP started to become deployed around 1998, at which time an Mb of bandwidth was still expensive.

Today many operators offer all-you-can-eat data plans, network speeds are much higher and network latency is much lower. So since WAP protocol version 2.0, WAP is much more like HTTP and doesn’t rely on the encodings as much.

In a WBXML encoding, predefined element names, attributes and even attribute values will be substituted by tokens. A token typically consists of 1 octet. The encoding also allows for efficient encoding of strings that occur more than once.

In the WBXML encoding of an XML document is a document type-specific encoding. The WBXML encoding for a document type is defined by

  • Which elements translate to hat tokens
  • Which attributes translate to what tokens
  • Which attribute values translate to what tokens

WSP

The Wireless Session Protocol is the WAP (1.3 and before) version of HTTP. WSP is a request/response protocol optimized for carrying HTTP requests and responses. As with WBXML the main feature of WSP is the compression of HTTP request/responses and HTTP headers.

This is relevant to us since what we’re going to send in the WAP push message includes the HTTP Content-Type and Content-Size headers. Additionally we can send some WAP specific headers, of which I’ll show one. Basic structure for WSP encoded content is:

  • Encoded headers Length
  • Encoded headers
  • Body Length
  • Body

The length fields are integers encoded in 1 or more octets.

WDP

The Wireless Datagram Protocol is the lowest layer of the WAP (1.3 and before) stack. It defines how packets are to be sent over a specific bearer. In any IP based network (GPRS, 3G, etc) WDP corresponds to UDP. We’re interested only in how to send packets over SMS, so we need to understand how to make a WDP packet out of an SMS.

There are 2 IEI used to make a WDP packet out of an SMS:

  • Source and destination ports. This is IEI 0×05. When multiple applications on the device interested in WDP packets, they use the destination port to figure out if a particular packet is for them.
  • The concatenation information. This IEI 0×00. This is exactly as described in the ‘Concatenating SMS messages’ article.

Having said all this let’s just dive in and look at the first example:

Service Load

Here we send an SMS message that corresponds to the Service Load document of the previous article:

AT+CMGS=59
0041000B915121551532F400042E0B05040B84C0020003F001010A060403B081EA02066A0085
09036D6F62696C65746964696E67732E636F6D2F0001

Here is a byte-for-byte explanation:

Size Value Description Section
1 octet 0×00 No SMSC supplied SMS
1 octet 0×41 SUBMIT-PDU + UDH present
1 octet 0×00 message reference
1 octet 0x0B Length of destination address in digits
1 octet 0×91 Destination is an international telephone number
6 octets 0x5121551532F4 Destination is ‘+15125551234’
1 octet 0×00 Protocol identifier
1 octet 0×04 Date coding scheme. This value stands for ‘8 bit data’.
1 octet 0x2E User Data Length. Size of payload is 46 octets.
1 octets 0x0B User data header length is 11 octets. UDH
1 octet 0×05 IEI 0×05 contains source and destination port.
1 octet 0×04 IEDL. Content is 4 octets.
2 octets 0x0B84 Destination port is 2948.
2 octets 0xC002 Source port is 49154.
1 octet 0×00 IEI 0×00 contains concatenation information
1 octet 0×03 EIDL. Content is 3 octets.
1 octet 0xF0 Reference number
1 octet 0×01 Total 1 parts
1 octet 0×01 This is the 1st (and only) part
1 octet 0x0A The WSP transaction ID WSP
1 octet 0×06 This is a push PDU
1 octet 0×04 Headers consist of 4 octets
1 octet 0×03 Content type consists of 3 octets
1 octet 0xB0 Content type 0×30: This stands for  application/vnd.wap.slc (a WBXML encoded SL document)
1 octet 0×81 Parameter name: 0×01 means ‘Charset
1 octet 0xEA Parameter value: 0x6A means ‘UTF-8
1 octet 0×02 WBXML Version 1.2 WBXML
1 octet 0×06 Document type
-//WAPFORUM//DTD SL 1.0//EN
1 octet 0x6A Encoding UTF-8
1 octet 0×00 String table length
1 octet 0×85 <sl> element, with attributes
1 octet 0×09 token for ‘href=http://’
1 octet 0×03 Inline string follows
18 octets 0x6D6F62696C657
0x46964696E6773
0x2E636F6D2F
“mobiletidings.com/”
1 octet 0×00 end of inline string
1 octet 0×01 end of <sl> attributes

In the next post, I’ll analyze the Service Indication variant.