On Nov 24, 7:16 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> et...@hotmail.com wrote:
> > thank u John very much for ur patience and help , now I 'am
> > facing another problem regarding connecting long SMS parts all
> > to gather for example I have a long SMS coming into 3 parts I
> > can know which part is 1st , 2nd and 3rd part but the problem
> > is if I got many long SMSs coming from the same sender ID and
> > same SMSC this may make all SMSs parts to be confused do u
> > have any solution for this problem
>
> The most important pieces of information for grouping are the
> message number and the OA (sender, "originator address").
>
> A concatenated SMS-submit (MO, "mobile originate") message has
> two message numbers, which are totally independent of one
> another.
>
> One sits between the PDU-type octet and the DA (destination
> address). This is the one which you normally set to zero in
> your SMS-submit PDU, and which the phone/modem allocates
> dynamically as it sends the message. The value used is
> returned in the "+CMGS: " result code. It does not exist in
> the SMS-deliver PDU, so you can't use it to identify received
> messages. In any case, each part of a concatenated message
> would have a different message number in this position.
>
> The second message reference number is put into the UDH (user
> data header). This one remains unchanged from SMS-submit PDU
> through to SMS-deliver (received) PDU, and will be the same for
> all parts of the one long message.
>
> In an earlier post, I decoded the three message parts of a
> concatenated message for you. This is the UDH decode from one
> of those messages:
>
> 6A UDL: 106 decimal
> 05 UDHL: the next 5 octets are UDH (header)
> 00 concatenated message using 8-bit numbering
> 03 information element length (3 octets follow)
> 3E concatenated message number 3E hex (62 decimal)
> 03 there are 3 parts to this message
> 03 this is part 3
>
> The message number I'm talking about is 3E hex (62 decimal) in
> this example. All three parts had this message number, and
> this identifies which message the three parts belong to, when
> viewed in conjunction with the OA.
>
> This number for this OA will eventually roll over (at 255) and
> earlier numbers will be reused for later messages. If you keep
> messages long enough for this to be a problem, I suggest you
> use the SMSC timestamp to untangle the parts.
>
> If you had six messages from the same sender all with UDH
> message number 62 decimal, and two messages were part 1, two
> were part 2, and two were part 3, then the SMSC timestamps
> should allow you to group them correctly. Three timestamps
> would be very close together (within a few seconds) and the
> other three would also be very close to each other but very
> different from the other three.
>
> The decoding of the SMSC timestamp is given in GSM 03.40, clause
> 9.2.3.11. The Siemens PDU guide athttp://www.jazi.staff.ugm.ac.id/Mobile%20and%20Wireless%20Documents/s...
> also gives some basic information on decoding this and other
> PDU header data elements.
>
> I hope that's clear and answers your question. Otherwise,
> please let me know.
>
> John


Hi Joh,

The information you provided in your earlier posts helped me a lot.
However, I still have some question wrt long/concatenated sms.

When I encode a message of length 153 chareecters in 7 bit format and
append(prefixed the header to the mesage as 05 00 01 03 01) the header
to it, some how the message is not getting displayed properly in the
handset. The example message i used is "hellohellohello......" up to
153 characters.

Can you explain me how I should encode the message part. I looked in
to the Mobile originated message and the same is encoded as
differently. I find difference only in the used data that is encoded
in to the deliver sm pdu.

Appreciate your suggestions.

Regards,
Aakash

aakash78_m@yahoo.co.in wrote:

> The information you provided in your earlier posts helped me a
> lot. However, I still have some question wrt long/concatenated
> sms.
>
> When I encode a message of length 153 chareecters in 7 bit
> format and append(prefixed the header to the mesage as 05 00
> 01 03 01) the header to it, some how the message is not
> getting displayed properly in the handset. The example message
> i used is "hellohellohello......" up to 153 characters.
>
> Can you explain me how I should encode the message part. I
> looked in to the Mobile originated message and the same is
> encoded as differently. I find difference only in the used
> data that is encoded in to the deliver sm pdu.
>
> Appreciate your suggestions.

Hi Aakash,

One requirement when encoding an SMS in the default 7-bit
alphabet, and which has a UDH, is to pad the UDH out to the
next septet boundary.

I don't know if this is one of the problems you're having. If
it's not, perhaps you could post your UD encoding so that we
can see where the problem is.

Why do we need to pad the UDH to the next septet boundary?
Basically it's because older phones were not able to join the
parts of concatenated messages they received. Therefore the
best they could do is to display the various message parts as
individual independent messages, and hope that all made sense
to the person reading them. Therefore they display the UDH
without decoding or removing it, as 7 garbage characters before
the actual text. If the UDH was not padded to a septet
boundary, then the text itself would also be garbage (because
it would not be correctly aligned with the beginning of the UD
itself).

You mention a UDH of 0500010301. That's one octet too short.
The leading "05" says that there are five more octets of UDH,
and the remaining "00010301" is only four octets.

Let's assume you want to send part 1 of a 3-part concatenated
SMS, and that the message reference number is 1. That UDH would
be

050003010301

as follows:

05 UDHL: the next 5 octets are UDH (header)
00 concatenated message using 8-bit numbering
03 information element length (3 octets follow)
01 concatenated message number 1
03 there are 3 parts to this message
01 this is part 3

Let's now take your message text "hellohellohello......"
litterally and encode it.

If the UD contained no UDH, then this would encode as:

E8329BFD4697D9EC37BACC66BF5D2E97CBE502

But we must pad to the next septet boundary. Because the UDH
takes up 6 octets (48 bits), we've got to pad out to 49 bits (7
septets = 49 bits = the next septet boundary).

I do this by prefixing the message text with 7 "@" characters,
and then overlaying the UDH on top. I use "@" because it's
"0000000" binary in the 7-bit default alphabet, giving me all
the binary zero padding I could possibly need.

"@@@@@@@hellohellohello......" encodes as:


000000000000D06536FB8D2EB3D96F7499CD7EBB5C2E97CB05

Overwriting the first 6 octets with the real UDH gives

050003010301D06536FB8D2EB3D96F7499CD7EBB5C2E97CB05

And that's our UD field, with the actual text displayed
correctly by new and old phones alike.

John

On Dec 20, 1:07 am, John Henderson <jhenRemoveT...@talk21.com> wrote:
> aakash7...@yahoo.co.in wrote:
> > The information you provided in your earlier posts helped me a
> > lot. However, I still have some question wrt long/concatenated
> > sms.
>
> > When I encode a message of length 153 chareecters in 7 bit
> > format and append(prefixed the header to the mesage as 05 00
> > 01 03 01) the header to it, some how the message is not
> > getting displayed properly in the handset. The example message
> > i used is "hellohellohello......" up to 153 characters.
>
> > Can you explain me how I should encode the message part. I
> > looked in to the Mobile originated message and the same is
> > encoded as differently. I find difference only in the used
> > data that is encoded in to the deliver sm pdu.
>
> > Appreciate your suggestions.
>
> Hi Aakash,
>
> One requirement when encoding an SMS in the default 7-bit
> alphabet, and which has a UDH, is to pad the UDH out to the
> next septet boundary.
>
> I don't know if this is one of the problems you're having. If
> it's not, perhaps you could post your UD encoding so that we
> can see where the problem is.
>
> Why do we need to pad the UDH to the next septet boundary?
> Basically it's because older phones were not able to join the
> parts of concatenated messages they received. Therefore the
> best they could do is to display the various message parts as
> individual independent messages, and hope that all made sense
> to the person reading them. Therefore they display the UDH
> without decoding or removing it, as 7 garbage characters before
> the actual text. If the UDH was not padded to a septet
> boundary, then the text itself would also be garbage (because
> it would not be correctly aligned with the beginning of the UD
> itself).
>
> You mention a UDH of 0500010301. That's one octet too short.
> The leading "05" says that there are five more octets of UDH,
> and the remaining "00010301" is only four octets.
>
> Let's assume you want to send part 1 of a 3-part concatenated
> SMS, and that the message reference number is 1. That UDH would
> be
>
> 050003010301
>
> as follows:
>
> 05 UDHL: the next 5 octets are UDH (header)
> 00 concatenated message using 8-bit numbering
> 03 information element length (3 octets follow)
> 01 concatenated message number 1
> 03 there are 3 parts to this message
> 01 this is part 3
>
> Let's now take your message text "hellohellohello......"
> litterally and encode it.
>
> If the UD contained no UDH, then this would encode as:
>
> E8329BFD4697D9EC37BACC66BF5D2E97CBE502
>
> But we must pad to the next septet boundary. Because the UDH
> takes up 6 octets (48 bits), we've got to pad out to 49 bits (7
> septets = 49 bits = the next septet boundary).
>
> I do this by prefixing the message text with 7 "@" characters,
> and then overlaying the UDH on top. I use "@" because it's
> "0000000" binary in the 7-bit default alphabet, giving me all
> the binary zero padding I could possibly need.
>
> "@@@@@@@hellohellohello......" encodes as:
>
> 000000000000D06536FB8D2EB3D96F7499CD7EBB5C2E97CB05
>
> Overwriting the first 6 octets with the real UDH gives
>
> 050003010301D06536FB8D2EB3D96F7499CD7EBB5C2E97CB05
>
> And that's our UD field, with the actual text displayed
> correctly by new and old phones alike.
>
> John- Hide quoted text -
>
> - Show quoted text -

Hi John,

The explanation is very clear.

Yes, the header I quoted in my earlier post was wrong.

Thanks a lot for your quick help John!!!

Regards-
Aakash