Long and short letter realization series of mobile CMPP2.0

1) Background
At present, our text message is basically more than 140 bytes (or even less) on the Shard (mobile ordinary text messages more than 140 bytes or even send, Unicom is OK), and then a few sent to the customer, but also can not guarantee the order, the user experience is not good,
Operation this side complained that the streamlining and streamlining or more than the number of words, so long and short letter support becomes necessary things.

2) Principle

2.1) Long text Message protocol and general text message protocol slightly different

2.1.1) Tp_udhi=1
Prefix the Udhi header with 6 bytes or 7 bytes in a msg_content

2.1.2) A 6-byte Tp_udhi protocol header
XX MM NN
Byte 1:05, indicating the length of the remaining protocol header
Byte 2:00, this value is specified in the GSM 03.40 specification 9.2.3.24.1, indicating that the length of the subsequent long text message is 1 (the XX value in the format).
Byte 3:03, this value indicates the length of the remaining SMS ID
Byte 4:xx, the only sign of the text, in fact, the SME (cell phone or SP) after the message has been merged and re-recorded, so this flag is not very important.
Byte 5:mm, the number of this batch of text messages. If a long text message totals 5, the value here is 5.
Byte 6:nn, the number of this batch of text messages. If the current text message is the first value in this text message is 1, the second value is 2.
Example: 05 00 03 39 02 01

2.1.3) A 7-byte Tp_udhi protocol header
Geneva xx xx MM NN
Byte 1:06, indicating the length of the remaining protocol header
Byte 2:08, this value is specified in the GSM 03.40 specification 9.2.3.24.1, indicating that the length of the subsequent long text message is 2 (the XX value in the format).
Byte 3:04, this value indicates the length of the remaining SMS ID
byte 4-5: xx xx, the only sign of this text message, in fact, the SME (mobile phone or SP) after the message merge, re-record, so this flag is not very important.
Byte 6:mm, the number of this batch of text messages. If a long text message totals 5, the value here is 5.
Byte 7:nn, the number of this batch of text messages. If the current text message is the first value in this text message is 1, the second value is 2.
Example: 06 08 04 00 39 02 01

2.2) Implementation method
Our SMS gateway is still to divide the text message by 140 bytes, only the byte of the text message and the previous slightly different (see 2.1 instructions), SMS Center by the split SMS sent to the mobile phone terminal,
Mobile phone terminal According to the Udhi protocol head and then put these several text messages into a full text message displayed on the phone screen

3) Action

3.0) A brief downlink process
Our Gateway Program (SP) <-------CMPP2.0 protocol-----> Internet SMS Gateway (ISMG) <-----SMPP protocol---------> Short Message Center (SMC) <-----Wireless protocol---- > Mobile Phone Terminal

3.1) First stage
Conditions: (6-byte protocol header, Tp_udhi=1, Pk_total pk_number are 1 or 0 or Tp_udhi header, Msg_fmt is GBK)
Terminal cannot receive, get error code from SMS Center ma:0054, meaning SMS Center does not return industry gateway response message

Conditions: (7-byte protocol header, Tp_udhi=1, Pk_total pk_number are 1 or 0 or Tp_udhi header, Msg_fmt is GBK)
Terminal cannot receive, get error code from SMS Center mb:1057, meaning SMS Center return Industry Gateway Error Response message

Specific error reasons, how to correct, I asked the mobile technician, no results

3.2) Phase II
Whim, change the msg_fmt to UCS2, which is set to 8 instead of 15, the situation has changed
Conditions: (6-byte protocol header, Tp_udhi=1, Pk_total pk_number are 1 or 0 or Tp_udhi header, Msg_fmt is UCS2)
Can receive a
Another industry gateway has a problem, the return error code is 8, indicating that the traffic is too large

Conditions: (7-byte protocol header, Tp_udhi=1, Pk_total pk_number are 1 or 0 or Tp_udhi header, Msg_fmt is UCS2)
Can receive a
Another industry gateway has a problem, the return error code is 8, indicating that the traffic is too large

Later found that this error is self-inflicted, I set up the MSG fmt, but the msg_content in the byte is still the original GBK

3.3) Phase III
After correcting the above error, it's OK.
At this point the situation is:
(7 bytes, tp_udhi=1, Pk_total Pk_number and Udhi head consistent, msg FMT for UCS2)

3.4) Give an example
I'm going to send AAABBBCCC, I split it into 3: AAA, BBB, CCC
3 lines are as follows
Aaa:
pk_total:03
Pk_number:01
Tp_udhi:01
msg_fmt:08
msg_content:06 08 04 00 39 03 01 00 41 00 41 00 41

Bbb:
pk_total:03
Pk_number:02
Tp_udhi:01
msg_fmt:08
msg_content:06 08 04 00 39 03 02 00 42 00 42 00 42

Ccc:
pk_total:03
pk_number:03
Tp_udhi:01
msg_fmt:08
msg_content:06 08 04 00 39 03 03 00 43 00 43 00 43

Note that the Tp_udhi in the protocol header of XX xx here for 00 39 is randomly generated by me.


4) conclusion must be set Tp_udhi 1 must be added before MSG_CONTETNT Tp_udhi protocol header, protocol header I currently use 7 bytes, I think 6 bytes should also be possible, you can try to pk_total,pk_number whether it must be set and TP_ Udhi protocol head in the MM NN consistent, I am at present is consistent, but I feel inconsistent can also, just like ordinary text message in this field is 1, you can try to msg_fmt must not choose 15 that is GBK, I currently choose 8 (UCS2), the other line no, you can try Feel that 7 bytes is still good, especially with two bytes xx xx to mark a batch of text messages, if the two bytes randomly generated (if not randomly generated, the implementation cost is much larger), which makes in the case of large concurrency, The likelihood of a conflict (in which two batches of text messages received by a mobile phone at some point will cause problems with a mobile phone merge) is much less likely. It is best to have a simulation gateway test, although simulation only simulates the industry gateway, but at least to avoid my second phase of the stupid error, it is better to have a tcpdump tool to detect the correct bytes sent.