关于超长短信技术的研究探索.pdfVIP

TCP/IP 通信协议的无顺序性，导致这些分拆短信到达手机终端时可能没有按照原来发送的 逻辑顺序，或者更严重的情况出现其中的一些短信不能及时下发成功，使得接收方对于信息 的理解不全面或者有偏差[1]。 从北京地区移动网络的短信网络结构来看，短信中心Cluster A、B 共8 台服务器负荷 分担应用下发(AO--MT)的短信；由于短信中心具有的Fast Forward 功能，以及各短信中心 处理内容不同，容易造成短信“后发先至”现象，和短信同时到达造成手机忙而延迟接收的 现象发生。 二、解决问题的思路 为解决通过短信网关下发长短信时，出现接收无序以及丢失等问题，我们只需要在应用 系统中调用长短信库函数API，即可实现长短信的收发。该长短信库函数API通过研究手机点 对点发送长短信的实施方式，借鉴该方式并结合GSM中关于短信的协议，摸索出符合协议要 求合理的用户数据报头（UD HEADER）用于控制短信的合并，包括： 1、分析下发内容是否超过70个，如果超过70个，对短信内容进行分拆，建议每条短信按67 个汉字进行分拆，编码方式设置DCS为8 （UCS2编码方式）,并且设置每条短信的UDHI为1； 2、构造UD的报头部分：前三个字节为05 00 03，第四个为分拆个数； 3、将reference number参数设置为全局变量，每次在发送一条长短信时该加1，以防止如果 同时发送多条长短信给同一个客户端时，在合并短信时将不同的短信合并在一起。该值 取值范围为0－255，建议每次该值加1，达到255时，从0重新开始[1][2]。 CMPP 协议中已经规范了关于长短信收发技术的标准，长短信库函数API 是这种技 术的标准化成果。其实，在手机桌面助理中已经应用了长短信发送技术，只是没 有形成标准化的API。以银行账单信息发布系统为例，用户的账单信息很难控制在70 个 汉字之内，如果该系统不支持长短信发送功能，账单短信发送到短信网关时，短信网关会自 动按70 个汉字/条进行拆分，被拆分后的每一条短信到达手机终端时可能没有按照原来发送 的逻辑顺序，甚至会出现一些短信不能及时下发成功，这会给用户对账单信息的理解带来障 碍。如果该系统调用了长短信API，被拆分后的短信到达用户手机终端（支持长短信功能） 时会合并为一条短信显示，相信应用这种模式可以大大提高用户的满意度。 基于短信的应用系统通过调用长短信库函数API[2][3]，可以规避现有各类基于普通短 信的增值业务由于短信长度限制而存在的缺陷。业务实现组网结构图如图1 所示： 超长短 应用系统 短信网关 短信中心 信API 图1.超长短信收发系统结构图 由于超长短信是基于现有的短信协议实现的，所以不需要对现有的短信中心和短信网关升 级，对系统组网结构和实施方案没有影响。 三、前期业务测试和试用推广情况 1、为了了解超长短信的接收合并功能，2006 年9 月份，我们分不同组别共测试了91 款终 端，涵盖16 个品牌，统计如表2 所示。 测试1 测试2 测试3 发送长度 400 汉字 198--5053 汉字 多组 终端数量 25 18 48 涵盖品牌 13 11 12 表2 超长短信测试总体情况统计表 整体结果表明，98%以上的手机终端可以支持对超长短信的接收及合并，有不少终端能单条 接收几千汉字以上的短信。现网和实验室测试的结果如图2 所示，大部分手机可以支持超长 短信的接收及合并功能。 不支持接收长 短信(%) 最多合并长度 6% 5000汉字以上 支持接收但不