Construction of SMS PDU’s
LZT 123 7632 R1A
14
So we see that TP-MTI is set to 01 and we are sending an SMS from the
mobile to the Service Centre, and therefore it says that this is a PDU of
type SMS-SUBMIT (as if we needed telling).
TP-RD is 0, so we don’t want the Service Centre to reject any duplicates
that we may send.
TP-VPF is 10 and, therefore, our PDU will be using the relative Validity
Period field format.
TP-SRR is 0 therefore no Status Report is requested.
TP-UDHI is 0 and so there will be no user data header within our User
Data.
Finally there will be no Reply Path set since we set TP-RP to 0.
Could it be simpler?
4.3 Message reference field (TP-MR)
Now back to our example, and the next octet
07916407058099F911
00
0A8170607896200000A71554747A0E4ACF416
110945805B5CBF379F85C06
This is the Message reference field, TP-MR). This field is 1 octet in length,
and is just a hexadecimal representation of an integer reference number
given to the SMS-SUBMIT. The number can range from 0-255 in value.
The user can set it to any value, although usually it can be set to 00.
It could be used by the user to keep track of and, distinguish between
sent, delivered, and received SMS.
We see that in our example we have chosen to set this to 00.
4.4 Destination Address (tp-da)
The destination address is shown in our example below:
07916407058099F91100
0A817060789620
0000A71554747A0E4ACF416
110945805B5CBF379F85C06
This field represents the mobile number for whom which the SMS is
intended.
This looks familiar right? Well, it is almost identical to the address field
described earlier for the Service Centre. There is only one difference, and
that is in the first octet.
Remember in the Service Centre Address it was the number of octets to
follow in the address field? Now it
is the number of digits in the
destination mobile subscriber number.
