I think you should read the spec :) >From the spec sheet (http://www.3gpp.org/ftp/Specs/archive/23_series/ 23.040/23040-601.zip)
<<< 9.2.3.24.8 Concatenated short messages, 16-bit reference number This facility is an enhanced variant of the Concatenated Short Message facility (see clause 9.2.3.24.1). The enhancement is a 16-bit reference number, instead of the short 8-bit reference number. The larger reference number reduces the probability that two different concatenated messages are mistakenly sent with identical reference numbers to a receiver. Except for the size of the reference number this facility is identical to the Concatenated Short Message facility (see clause 9.2.3.24.1). In the case of uncompressed 8 bit data, the maximum length of the short message within the TP UD field is 133 (140 - 7) octets. In the case of uncompressed GSM 7 bit default alphabet data, the maximum length of the short message within the TP UD field is 151 (160 - 9) characters. In the case of 16 bit uncompressed USC2 data, the maximum length of the short message within the TP UD field is 66 ((140 - 7)/2) characters. A UCS2 character must not be split in the middle; if the length of the User Data Header is odd, the maximum length of the whole TP-UD field is 139 octets. >>> The 3GPP 23.040 series is a very informative spec sheet if you want to dig deeper. On Nov 12, 8:13 pm, nchin <[EMAIL PROTECTED]> wrote: > Sorry for the trouble, I am actually quite confused, hope you guys > could help me: > > So far this is what I understood > 1) 7-bits encoding gives 160 chars per sms > 2) 8-bits encoding gives 140 chars per sms > 3) Unicode encoding gives 70 chars per sms > > Can someone tell me, how to calculate the number of multi-parts sms > for the three scenario above, please? Since I cannot simple divide > into 160, 140 or 70 for all three scenario respectively because of the > overhead. > > Thanasis, you mentioned in your earlier reply that it is about 4 to 6 > char, so what should I use to calculate? Kindly accept my apologies if > my question sounds dumb. I really need to be precise to get the exact > number of multi-part. > > TIA > > On Nov 11, 7:28 pm, Thanasis <[EMAIL PROTECTED]> wrote: > > > > > Unicode/UCS2 is two-bytes per char! > > Unicode max message length is 70 chars - you should take this into account > > in your calculations. > > > 2008/11/11 Aryo Sanjaya <[EMAIL PROTECTED]> > > > > On Mon, Nov 10, 2008 at 12:35 AM, nchin <[EMAIL PROTECTED]> wrote: > > > >> Aryo, thank you for your assistance. > > > >> Correct me if I am wrong, based on your formula, if the encoding is > > >> Unicode/UCS2, then the formula should be:- > > >> if length(string) <= 140 the > > >> sms_count = 1 > > >> else > > >> sms_count = floor( length(string) / (140-7) ) + 1 > > >> endif > > > >> Am I right? I will be grateful if you could help clarify. > > > > Sorry for the late response. > > > > I have no idea how concatenated SMS is implemented on Unicode. Sorry. > > > > But I think the formula will be different, not just subtract it with 7 > > > chars. > > > > As Thanasis said, PDU will get 4-6 bytes per part as an information. Since > > > Unicode has different character wide (8 bits instead of 7), so I think it > > > will not take 7 chars as on 7-bits SMS. Maybe fewer. > > > > It's only my opinion, without any references :) > > > > -- > > > Best Regards, > > > > Aryo Sanjaya- Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SMSLib Users Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SMSLib?hl=en -~----------~----~----~----~------~----~------~--~---
