As explained in a prevous post in this series, a GSM modem can let you send SMS messages from a PC. There are two basic ways to do this: text mode and PDU mode.
You can play around with your GSM modem using a terminal program like HyperTerminal (which came with Windows XP, but is no longer there in Windows Vista). The commands I mention can just be entered in the terminal window when connected to the modem. You can try the following basic commands, any modem should support these:
||Returns general modem identification
||Dials the phone number you supplied (don’t enter the <> brackets)
||Hang-up the phone (useful after the previous command).
The following commands are specific for GSM modems. If you get an error response (e.g. ‘+ERR’), your modem probably isn’t a GSM modem or it doesn’t support the extensions specific for GSM modems. Read More…
PDU mode is a lot more interesting than text mode. There are all kinds of things that can be done with SMS messages, all leveraging special formatting that is only available if you use PDU mode:
The formatting of these PDU’s is a little more complicated and requires some bit manipulations that are hard to do by hand.
The GSM modem is put into PDU mode with the command ‘AT+CMGF=0’. Once in PDU mode a PDU can be sent using the ‘AT+CMGS’ command:
As discussed in an earlier post, you can connect to a GSM modem and use AT commands to send SMS messages. There are 2 possible methods: text mode and PDU mode.
It turns out that most devices support PDU mode, but only a few support text mode.
Here is an example AT command to submit a PDU:
As explained before the size (24) is the number of octets in the PDU. he PDU itself is passed as a hex representation of those octets (48 characters). Here is what the individual octets represent:
So far I’ve show how to send a text message in PDU mode. There is nothing special about this. There are a number of things you can do in PDU mode, that you can’t do in text mode.
A first example is a flash SMS message.
A flash SMS message is an SMS message that, instead of being stored in the SIM or memory of the receiving phone, pops-up on the receiving phone’s screen, without the user taking any action. When dismissed the message is usually gone.
Here is an example AT command to send a flash SMS message in PDU mode:
Here is what the individual octets represent:
EMS stands for Enhance Message Services. EMS messages are just SMS messages with a twist.
EMS messages make use of the User Data Header to add some meta data to the SMS message being sent. This meta data is separate from the actual text and devices that don’t understand some or any of the EMS features will easily skip over them and just render the text.
The uses of EMS are many:
As discussed in a previous post, many features of SMS messages become available if you can set the User Data Header (UDH) field.
When using a GSM modem in text mode you can’t sent a UDH, so you need to use PDU mode.
How do you add a UDH?
There are 2 things you need to do:
- Set the UDH bit in the first octet of the PDU. For an SMS-SUBMIT PDU (the only one we’ve been using so far) the value is normally 0×01. To indicate that a UDH is present we need to set bit 6 (0×40). So for an SMS-SUBMIT with UDH present we set the PDU type to 0×41.
- With the UDH bit set, this first octet of the payload (or User Data = UD) needs to indicate the length of the UDH in octets. This field is known as UDHL.
As you may understand, the data you can send via SMS is limited. It is limited because:
- A single message can only hold 160 GSM-7 encoded characters
- Even though messages can be combined in to bigger ones, the total size is still limited in several ways:
- A message can have at most 256 parts
- The receiving device as a (much lower) limit on how many parts it can reassemble into a bigger message
- And if the technical limits aren’t prohibitive, the cost might be
So how do you send more and richer information to a device? There are 2 possibilities:
Today I’ll focus on WAP push.
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.
As I have been writing about EMS and WAP Push, I am sure your ask yourself: “Does my phone support this?”. Again we dig into the WURFL database and we see that WAP Push is widely supported, but EMS a little less so.
This is understandable, because WAP Push is a protocol used in MMS (or picture messaging). Since most phones nowadays are camera phones and support picture messaging, they’re very likely to support WAP Push.
Here is a list of devices that support EMS and/or WAP Push, according to WURFL:
I still needed to show how you can send an Service Indication (SI) document like:
< ?xml version="1.0"?>
< !DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
si-expires="2009-03-04T16:25:00Z">Check out Mobile Tidings!</indication>
This document, a Service Indication, tells the WAP client to store the following:
- A link to http://mobiletidings.com/
- With text “Check out Mobile Tidings!“
- This typically shows up in a “WAP Push Inbox” or sometimes in the “SMS Inbox”
- The link will show when it was created
- It should automatically be removed after the expiry time mentioned
Well here is the AT command to send this particular SI document: