0% found this document useful (0 votes)
9 views

Messaging

This document provides a tutorial on mobile messaging, focusing on sending and receiving SMS messages using AT commands. It covers the setup required for communication between a computer and a mobile phone, the structure of SMS messages in both text and PDU modes, and advanced topics such as Service Indication and WSP Push messages. The document also includes practical exercises for experimenting with various SMS parameters and configurations.

Uploaded by

李志强
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
9 views

Messaging

This document provides a tutorial on mobile messaging, focusing on sending and receiving SMS messages using AT commands. It covers the setup required for communication between a computer and a mobile phone, the structure of SMS messages in both text and PDU modes, and advanced topics such as Service Indication and WSP Push messages. The document also includes practical exercises for experimenting with various SMS parameters and configurations.

Uploaded by

李志强
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Mobile messaging

Johan Montelius

Introduction
In this session you will experiment with different messaging alternatives.
You will first send plan SMS messages using a laptop and a mobile phone
an then learn how to code a WAP Push message to send a MMS notification
and a Service Indication.
Through out this tutorial it’s good to have the SMS specification 23.040
at hand. You can find it at the 3GPP web site.

1 Getting started
You need a computer and a mobile phone and some means to connect the
phone to the computer. A cable is of course to prefer but IrDa or Bluetooth
also works. We will communicate with the modem of the phone using AT
commands so you also need a terminal program. On a Windows platform
you could use HyperTerm and and on a Linux platform you can use minicom.
The firs thing you need to do is to connect the mobile and the computer
and find out which com port the modem is assigned. Next open up the
terminal program and attach the terminal to the com port. If you succeed
you should be able to issue the following AT command (¡cr¿ is you typing
return):

AT+ CIMI<cr>

The result should be a fifteen digit number starting with 240.... (240 is
the number for Sweden). This is the IMSI number of the SIM card.

AT+ CSCA?<cr>

This is the number to the SMSC. You could change it to anything


you want but if you’re on the Telenor network it should probably read
”+46708000708”.
When sending SMS messages over AT you either work in text mode or
binary (PDU) mode. You can check which mode you’re in with the command
CMGF. A 0 is PDU mode and a 1 is text mode.

AT+ CMGF?<cr>

To change it to text mode CMGF=1 but if you’re using a SonyEricsson


phone it is very likely that it will only give you a error message. Since

1
submit header (1 byte)

message ref (1 byte)

destination address (2-12 byte)

protocol identifier (1 byte)

coding scheme (1 byte)

validity period (0, 1 or 7 byte)

user data length (1 byte)

user data (0-140 byte)

we will experiment with different SMS parameters that is ok, we will do


everything in PDU mode. If your phone supports text mode you could try
to send a message directly.

AT+ CMGS="+46703123456"<cr>
>This is the message<ctrl-Z>

Sending a SMS using PDU mode is a bit more complicated. Remember


the structure of a Submit PDU.
Let’s first send a regular SMS and then we will explore the different
parameters. A simple submit header is 01, this indicates a SMS submit
without a validity period set. The message reference can be left out so we
will use 00 for now.

01
00

If your phone number is 0732-041640 we have to code it as 6437021446F0,


remember why? The number is then written in international format using
E.164 numbering plan. This will be coded using one byte as 91. The highest
bit is always set and the lower four bits indicate the E.164 numbering plan.
Bits 7,6 and 5 (in our case 001) describe how the number is written down.
We will use international format but you can try 010 (that is A) to use a
number without the country code. The length of the number is 11 digits so
the complete coding of the destination will thus be as follows.

0B916437021446F0

2
Protocol identifier is set to 00 indicating a regular mobile to mobile
message. One can also play with protocol identifiers from 60 to 9F that are
used to replace previously delivered messages.

00

The coding scheme will in our first SMS be regular GSM 7-bit charac-
ters. So coding scheme is 00. We will use 8-bit data when we send more
complicated messages and then the coding scheme is 04.

00

Since we specified that there was no validity period we can omit this
byte. The length of the my secret message is thirty characters.

1E

The message it self is hard to decode since it is coded in GSM 7-bit


characters but written down using hex numbers. The message is coded as
follows. Note that the coding of our 30 characters only requires 26 8-bit
bytes.

61361B947FD7E52071785E0685E56590B8CC7EBBCF20FA1B549F03

A smaller messag that you can work with is “hello”. If we want to code
this we first write it down in 7-bit code with the least significat bit first.
The 7-bit code is ASCII for regular characters.

0001011 (h, 0x68)


1010011 (e, 0x65)
0011011 (l, 0x6C)
0011011 (l, 0x6C)
1111011 (o, 0x6F)

Now read the bits eight by eight.

0001011 1
010011 00
11011 001
1011 1111
011 .....

Patch the last octet with zeros and write down the corresponding hex
code. Remember that the least significat bit is the first bit.

3
0001011 1 0xE8
010011 00 0x32
11011 001 0x9B
1011 1111 0xFD
011 00000 0x06

Since “hello” has five characters the we would code the length field as
05 and the message as E8329BFD06. Simple, right?
Now send you first PDU SMS using the CMGS command. The command
takes one argument that is the number of bytes in the PDU. When we issue
the command we will have an input prompt in the terminal. We can now
write down the PDU as listed above but we have to start with 00 to indicate
that the terminal should use its default SMSC (this byte is not part of the
PDU and is thus not counted in the length of the PDU). End the sequence
with ctr-z.

AT+ CMGS=40<cr>
>0001000B9164..... <ctr-z>

If all works ok you should have a OK message with a message reference.


Now let’s tweak the parameters a bit.

1.1 message waiting


One thing we can play with is the coding scheme. This byte holds more
than just the character coding. If the high nible is 1100 we tell the terminal
to handle the message as a “Message waiting indication”. If the low nible is
coded as follows s0ii where the s bit is set or re-set and ii is either voice
00, fax 01, mail 10 or other 11 .
Try to set and re-set an icon (different on each terminal) that indicates
that we have a fax waiting. The body of the PDU can be empty (length
00).

1.2 ohh, no!


How often have you not sent a SMS and though “Ohh no, I should never
had sent that”. Well the designers of GSM knew this would happen so
they included a “Replace message” protocol type. The protocol identifier is
otherwise quite useless if you’re not in the business of sending telex messages.
If the high nible is set to 4 the low nible can specify a replace identifier from
one to seven. If we send one message with code 41 you can then send another
message with the same code and the new SMS will replace the old one.
Try to send a message and then change its meaning. Does it matter if
you have read the first message.

4
1.3 gone in 30 sec
Another parameter one can play with is the validity period. Turn a phone
off and then send it a message with very limited validity period (how do you
code 30 sec?). Then turn the phone back on and see if the SMSC is still
trying to deliver your message. You will probably have to use two phones
for this so collaborate in a small group.

2 Receiving a SMS
Receiving SMS can actually be quite tricky. One has to set it up properly
before we can even read stored messages on the terminal. There are different
memory areas and one can choose to work with, the SIM card denoted
"SM" and the mobile denoted "ME". There are also three different storage:
for reading and deleting, for writing and sending and for storing incoming
messages. Each storage can be allocated on either the SIM card or the
mobile. You can list the current setting with the CPMS command. You will
then also see how many messages you have in each storage.

AT+ CPMS?

The writing storage can be used to store SMS messages and and then
send them at a later point. This could be more convenient then issuing a
full CMSG command. We will now read messages so we must make sure that
the memory area for reading is the same as for storing incoming messages.
If incoming messages are stored in "ME" then we should also us this area for
reading.

AT+ CPMS="ME"

We can now list the content of this memory area with the CMGL command.
However, this command also takes a parameter: the status of the message.
Check in the AT command reference how to use the CMGL command.

AT+ CMGL=1

As you see we now have a message number attached to each message.


One can then read and handle a specific message.

AT+ CMGR=NN

The result is of course a SMS in its binary PDU format but this is of
course easy for you to decode. Look at a small message and try to identify the
elements. Remember that you’re now looking at a delivered SMS message,
not a submit message. All though similar in structure the decoding is not
the same. Can you see who it is from?

5
The next thing you could explore is how to automatically be notified of
incoming messages. If you build an application you do not want to poll the
terminal every 10’th second you would rather have a message being delivered
to you. First issue the CNMI command to find out how messages are handled
by default. Then change the setting so that arriving messages will give you
a message in the terminal window.
AT+ CNMI=2,1,0,0,0

3 More advanced stuff


You now have all the tools that you need to send SMS messages. You can
then proceed with one of three tasks: sending EMS messages, sending a
MMS notification or sending a Service Indication (SI). They all require you
to understand how User Data Headers are coded, the MMS and SI also
requires a lot of knowledge on how a WSP/WDP packet is coded.

3.1 Service Indication


This is the message we want to deliver. It’s a service indication message,
the message will be presented to the user and if the user choose to accept
the message the link to the server will be used. More information can be
found in WAP-167 Service Indication.
<?xml version="1.0"?>
<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN"
"http://www.wapforum.org/DTD/si.dtd">
<si>
<indication href="http://www.it.kth.se/courses/2g1722/push.wml" >
This is a test.
</indication>
</si>
In order to send this we need to code it in WBXML format. Note that
the specifics of how to code a service indication element is found in the end
of WAP-167.
Strings are coded in 8-bit octets, nothing funny here.

3.2 A WSP push


We now have to construct a WSP Push message.
Note that when you look for the token values in WAP-230 you will not
find ”0xAE” but rather ”0x2E”. When coding small integers the high bit is
set.
The WSP message is then put in a WDP packet that is directed to the
push destination port.

6
0x02 WBXML version 1.1
0x05 public identifier for SI 1.0
0x04 charset iso-8859-1
0x00 length of string
0x45 si with content
0xC6 indication with content and attributes
0x0D token for ”href=http://www.”
0x03 inline string follows
.... the string ”it.kth.se/courses/2g1722/push.wml
0x00 end of string
0x01 end of indication attributes
0x03 inline string follows
.... the string ”2G1722”
0x01 end of indication
0x01 end of si

0x01 push transaction id, could be anything


0x06 WSP type is Push
0x08 header length
0x01 content type length
0xAE content type: application/vn
0xAF header: x-wap-application-id
0x82 2 - the WML User Agent
0xB4 header:push-flag
0x85 101 - last-push, URI authenticated

7
0x0B User Data Header length (not including this byte)
0x05 identifer elements, port addressing
0x04 length of element
0x0B84 push dest port (2948)
0x23F0 push originator port (9200)
0x00 concatenated short message
0x03 length of element
0x01 ref number
0x01 max number of segments
0x01 current segmenet number

0x41 A SMS-SUBMIT message with a User Header


0x00 This is the message reference but here we let the phone set it.
0x0B Length of the address, change this if you change the receiver number
0x91 The address type used, in this case international starting with country code
.... this is the phone number, check the SMS tutorial.
0x00 Protocol
0x04 Data coding scheme, in this case 8-bit bytes.
0x.. This is the length of the User Data

3.3 The WDP


The WDP packet have different structure depending on which link layer we
are using. Since we are sending it over a SMS we will code it as a User Data
Header. Note that we have two elements one specifying the destination port
(2948) and a second indicating that the rest a concatented message.

3.4 The SMS


So we now have a WDP that includes a WSP consisting of a Service indi-
cation. This should now all be put in a SMS.
The whole WDP is now interpreted as a User Header Information. If
the terminal can not understand the header it will be ignored.

You might also like