It's been years since I last looked at this.  I promised myself
that I'd code up a concatenated SMS facility, but I never had
the need to, and so I never got around to it.

But I've just done a quick refresher course by looking at GSM
03.40.  You'll need a copy of this (or some other explanation
of it).  You should be able to find and download it from

       http://www.3gpp.org/

What follows is based on my memory and the quick revisit of GSM
03.40.

You'll need to send the large SMS as multiple individual
messages.  You embed cross-referencing information in them, and
that gets understood at the receiving end, where it's
reassembled.

Each individual part of the longer message can contain a maximum
of 153 7-bit characters.

Firstly, you need to turn the UDHI bit on within the PDU-type
octet.  In your example, you use  PDU-type octet of 31 hex.
The equivalent octet for each part of a multi-part message is
71 hex.  Note however that you've got the "Status Report
Request" bit turned on.  You have the option of having that on
or off for each individual part (at your discretion).  To save
cost, you might want to turn this off on some or all parts,
making the PDU-type octet 51 hex.

All other message components must then remain the same for each
individual part, except for UDL and UD itself.

The UD field now gets messy because it must now contain a header
(UDH).  You must know how many parts your message will be
broken up into, and you must number them, beginning at 1.

You must also give the whole message itself a number, so that
the individual parts can be reconstituted into the correct
message when received.  Modulo 256 numbering is specified for
this in GSM 03.40 (0, 1, 2, ... 254, 255, 0, 1, and so on
indefinitely).

The first 6 octets of the UD field are the UDH.  Assuming we're
dealing with part one of a 7-part message, it will look like
this:

06      UDHL (length)
00      concatenated message using 8-bit numbering (max 255 parts)
03      information element length (3 octets follow)
B6      I'm pretending the parts are of message number B6 hex
07      the receiver is to expect 7 parts
01      this is the first part

The final obstacle for you is to start your actual PDU-encoded
text on the next septet boundary.  So unless I'm mistaken, the
left-most bit of the 7th octet will be a fill bit (0), and your
PDU encoded text gets packed in normally after that.

Possibly the best way of understanding how it's done is to send
a multi-part message to your device from a handset, and read
off and analyze the received PDUs.  Being a store-and-forward
system, you can of course address such a message to yourself.

John