移动(cmpp协议)发送即显短信的设置

Wayne posted @ Thu, 03 Mar 2011 21:00:05 +0000 in Experience , 21913 readers

即显短信,也就是直接在手机屏幕上显示出来,不用自己点进去查看,同时看完之后直接就没了,不会留下短信记录的那种短信。在中国移动采用的SP与ISMG之间的CMPP协议中,发送消息使用的是CMPP_SUBMIT消息,该消息的消息体如下:

 

字段名

字节数

属性

描述

Msg_Id

8

Unsigned Integer

信息标识,由SP侧短信网关本身产生,本处填空。

Pk_total

1

Unsigned Integer

相同Msg_Id的信息总条数,从1开始

Pk_number

1

Unsigned Integer

相同Msg_Id的信息序号,从1开始

Registered_Delivery

1

Unsigned Integer

是否要求返回状态确认报告:

0:不需要

1:需要

2:产生SMC话单

 (该类型短信仅供网关计费使用,不发送给目的终端)

Msg_level

1

Unsigned Integer

信息级别

Service_Id

10

Octet String

业务类型,是数字、字母和符号的组合。

Fee_UserType

1

Unsigned Integer

计费用户类型字段

0:对目的终端MSISDN计费;

1:对源终端MSISDN计费;

2:对SP计费;

3:表示本字段无效,对谁计费参见Fee_terminal_Id字段。

Fee_terminal_Id

21

Unsigned Integer

被计费用户的号码(如本字节填空,则表示本字段无效,对谁计费参见Fee_UserType字段,本字段与Fee_UserType字段互斥)

TP_pId

1

Unsigned Integer

GSM协议类型。详细是解释请参考GSM03.40中的9.2.3.9

TP_udhi

1

Unsigned Integer

GSM协议类型。详细是解释请参考GSM03.40中的9.2.3.23,仅使用1位,右对齐

Msg_Fmt

1

Unsigned Integer

信息格式

  0:ASCII串

  3:短信写卡操作

  4:二进制信息

  8:UCS2编码

15:含GB汉字  。。。。。。

Msg_src

6

Octet String

信息内容来源(SP_Id)

FeeType

2

Octet String

资费类别

01:对“计费用户号码”免费

02:对“计费用户号码”按条计信息费

03:对“计费用户号码”按包月收取信息费

04:对“计费用户号码”的信息费封顶

05:对“计费用户号码”的收费是由SP实现

FeeCode

6

Octet String

资费代码(以分为单位)

ValId_Time

17

Octet String

存活有效期,格式遵循SMPP3.3协议

At_Time

17

Octet String

定时发送时间,格式遵循SMPP3.3协议

Src_Id

21

Octet String

源号码

SP的服务代码或前缀为服务代码的长号码, 网关将该号码完整的填到SMPP协议Submit_SM消息相应的source_addr字段,该号码最终在用户手机上显示为短消息的主叫号码

DestUsr_tl

1

Unsigned Integer

接收信息的用户数量(小于100个用户)

Dest_terminal_Id

21*DestUsr_tl

Octet String

接收短信的MSISDN号码

Msg_Length

1

Unsigned Integer

信息长度(Msg_Fmt值为0时:<160个字节;其它<=140个字节)

Msg_Content

Msg_length

Octet String

信息内容

Reserve

8

Octet String

保留

 

表面上看,没有任何关于发送的短信是普通的还是即显的东西。不过根据这份文档可以发现,实际上里面还有不少文章。进入文档的TP-DCS段,可以看到当整个字段处于00xx状态时,在bit1和bit0两位上,若两个值都为0,则短信成为class0短信,是一种alert,也就是即显短信。那么,这个TP-DCS相对应CMPP_SUBMIT,是属于哪一块呢?

 

Coding Group Bits 7..4 Use of bits 3..0
00xx General Data Coding indication
Bits 5..0 indicate the following:
Bit 5  
0 Text is uncompressed
1 Text is compressed

Bit 4  
0 Bits 1 and 0 are reserved and have no message class meaning
1 Bits 1 and 0 have a message class meaning

Bit 3 Bit 2 Alphabet being used
0 0 Default alphabet
0 1 8 bit data
1 0 UCS2 (16bit)
1 1 Reserved

Bit 1 Bit 0 Message class Description
0 0 Class 0 Immediate display (alert)
0 1 Class 1 ME specific
1 0 Class 2 SIM specific
1 1 Class 3 TE specific

NOTE: The special case of bits 7..0 being 0000 0000 indicates the Default Alphabet as in Phase 2

0100..1011 Reserved coding groups
1100 Message Waiting Indication Group: Discard Message

Bits 3..0 are coded exactly the same as Group 1101, however with bits 7..4 set to 1100 the mobile may discard the contents of the message, and only present the indication to the user.

1101 Message Waiting Indication Group: Store Message

This Group allows an indication to be provided to the user about status of types of message waiting on systems connected to the GSM PLMN. The mobile may present this indication as an icon on the screen, or other MMI indication. The mobile may take note of the Origination Address for message in this group and group 1100. For each indication supported, the mobile may provide storage for the Origination Address which is to control the mobile indication. 
Text included in the user data is coded in the Default Alphabet. 
Ehere a message is received with bits 7..4 set to 1101, the mobile shall store the text of the SMS message in addition to setting the indication.

Bit 3 Description
0 Set Indication Inactive
1 Set Indication Active

 

Bit 2 is reserved, and set to 0

Bit 1 Bit 0 Indication Type
0 0 Voicemail Message Waiting
0 1 Fax Message Waiting
1 0 Electronic Mail Message Waiting
1 1 Other Message Waiting*

 

* Mobile manufacturers may implement the "Other Message Waiting" indication as an additional indication without specifying the meaning. The meaning of this indication is intended to be standardized in the future, so Operators should not make use of this indication until the standard for this indication is finalized.

1110 Message Waiting Indication Group: Store Message

The coding of bits 3..0 and functionality of this feature are the same as for the Message Waiting Indication Group above, (bits 7..4 set to 1101) with the exception that the text included in the user data is coded in the uncompressed UCS2 alphabet.

1111 Data coding/message class

Bit 3 is reserved, set to 0.

Bit 2 Message coding
0 Default alphabet
1 8-bit data

Bit 1 Bit 0 Message Class Description
0 0 Class 0 Immediate display (alert)
0 1 Class 1 ME specific
1 0 Class 2 SIM specific
1 1 Class 3 TE specific

 

 

稍微往上看看,在bit3与bit2的位置,指定了短信的字符编码。那么联系一下,在CMPP_SUBMIT中关于字符编码的是什么?对,就是Msg_Fmt字段。这个字段总共是1个字节长,也就是8位。列举协议所示的几种情况:

0:ASCII串--- 0000 0000

3:短信写卡操作--- 0000 0011

4:二进制信息 --- 0000 0100

8: UCSII编码 --- 0000 1000

15:含GB汉字 --- 0000 1111

 

将其与TP-DCS表格进行对照,可以发现至少UCSII编码与表格是完全一致的。而它的bit4位置是0,所以没有激活class属性,因而bit0与bit1上的值没有实际作用。倘若要实现发送即显短信的效果,那么应当将bit4置1,成为0001 1000,也就是0x18,或者说24.

 

将Msg_Fmt字段设成24之后进行测试,结果让人满意。如果要以GB编码进行传送,那么推论下,Msg_Fmt的值当为31.

另外一个问题就是,协议上所说的“短信写卡操作”是什么东西? 若根据这个TP-DCS来看,它的bit4是0,那么结果跟 ASCII串是一样的,在bit0和bit1上的两个1并没有任何作用。可是不论电信的SMGP协议还是移动的CMPP协议,在这个地方都明确写明值为3(十进制)时是“短信写卡操作”。 “短信写卡”又是什么呢?是写入SIM卡吗?  SIM卡的话,我再测试即显短信时无意中已经做过一次了,我把0x18误当18,赋值给了Msg_Fmt, 结果就是短信直接存入了SIM卡中。而18的二进制是 0000 1010,对照TP-DCS表,正好是 SIM specific, 可见表格是对的。难道协议错了?


Login *


loading captcha image...
(type the code from the image)
or Ctrl+Enter