某通讯短信系统参数配置原则.docx

某通讯短信系统参数配置原则.docx

《某通讯短信系统参数配置原则.docx》由会员分享，可在线阅读，更多相关《某通讯短信系统参数配置原则.docx（19页珍藏版）》请在冰豆网上搜索。

某通讯短信系统参数配置原则

短信系统参数配置原则

（初稿）

四川移动通信责任有限公司

2003年六月

前言

受集团公司委托（移网通[2002]528号《关于委托编写短信系统参数配置原则的通知》），四川移动通信有限责任公司负责制定短信系统参数配置原则。

为此公司上下十分重视，立即成立了以网络部副主任刘耕为组长的参数编制小组，对短信系统相关的参数进行了大量的测试和分析，为提高短信各设备间的兼容性和下发成功率以及解决短信中心、短信网关的参数设置不规范，导致省际、省内各级短信设备配合不一致，影响短信业务成功下发的问题，提出了参数配置建议。

由于时间和水平有限，《原则》当中难免有考虑不周之处，敬请指正。

第一部分情况简介

（一）编写小组成员

组长：

刘耕

副组长：

杨书其白庆王耀阳

组员：

刘晟、林勇、林静、曾智、侯漫秋、涂越秋

厂家：

张美军（华为）钟智（康维）李邦建（亚信）

（二）本省短信及相关网络设备情况

点对点短信中心：

华为（软件版本v280r001.5d611），容量300万BHSM

梦网短信中心：

康维（软件版本2.5.27），容量300万BHSM

短信网关：

亚信（软件版本2.5.1）,容量288万BHSM

SCP：

东信北邮（4.04）

MSC：

西门子（sr9.0）

HLR:

西门子（sr9.0）

第二部分短信中心参数配置原则

一、短信中心单个用户最大短信缓存条数（被叫）：

参数释义：

短信中心对于单个被叫号码的最大短信保存数量。

不同地区、不同短信中心此项参数的设置并不一致。

为了证实此项参数的不同配置对收入以及对系统资源的影响，我们在成都万年短信中心（华为）上进行了测试：

测试环境：

万年短信中心（华为），承载四川全省除成都以外的点对点短信业务以及梦网点播等上行短信业务。

1、处理能力：

300万BHSM

2、日短信提交量（MO提交量）：

约为300万左右。

3、内存占用情况：

通常情况下5万条以内，内存容量为70万条。

测试方法：

分别将短信中心的单个被叫最大短信缓存条数设置为20条、15条、10条，然后对修改前后的MO提交成功率、效益（成功下发的点对点短信条数/手机向短信中心提交的点对点短信条数X100%）以及内存占用率进行统计和分析。

由于各短信设备制造商均未建议10条以下的设置，为避免影响公司收入，因此我们未对低于10条的短信存储数进行测试。

测试结果：

（如图）

效益=下发成功的点对点短信条数/手机向短信中心提交的点对点短信条数

配置原则建议：

15条。

理由：

1、由上图可见，单个用户待发缓存从20条调整到15条，对MO提交成功率影响不大，效益降低不明显，内存占用却下降了很多。

但从15条调整到10条，效益却有明显的下降。

2、对于一些业务种类较多（例如含短信群发业务、梦网业务）的短信中心，为保证系统安全，我们更是建议采取15条的被叫缓存设置。

因为承载广告群发业务以及梦网业务的短信中心，内存空间或者数据库空间占用率通常较高（成都康维短信中心，数据库空间150万，承载广告群发业务以及梦网络下行等业务，根据统计，广告群发的关机率约为20%，梦网下发的关机率约为10%，数据库空间经常超过100万），因此若被叫缓存数设置过高，不仅经济效益不明显，反而容易导致数据库被占满，给网络的安全带来隐患。

二、短信中心单条短信最大保存期限

参数释义：

未下发成功的短信在短信中心内存或数据库的保存期限。

不同地区、不同短信中心此项参数的设置并不一致，有的设置为24小时，有的设置为48小时。

为了证实此项参数的不同配置对收入以及对系统资源的影响，我们在成都万年短信中心（华为）上进行了测试：

测试环境：

万年短信中心（华为），承载四川全省除成都以外的点对点短信业务以及梦网点播等上行短信业务。

1、处理能力：

300万BHSM

2、日短信提交量（MO提交量）：

约为300万左右。

3、内存占用情况：

通常情况下5万条以内，内存容量为70万条。

测试方法：

考虑到一些厂家的短信中心此项参数的设置只能以天为单位，分别将短信中心的单条短信最大保存时限设置为24小时和48小时，然后对修改前后效益以及内存占用率进行统计分析。

测试结果：

（如图）

效益=下发成功的点对点短信条数/手机向短信中心提交的点对点短信条数

配置原则建议：

24小时。

理由：

1、测试所在的短信中心业务较为单一，只有点对点业务，从上图的比较可以看出，单条短信最大保存时限由24小时调整到48小时，内存占用明显上升，经济效益却明显的下降这说明正常的在网用户，短信中心的待发短信保存时限很少会超过24小时，而对那些长时间关机的用户，短信中心保存时限设置再高，这部分短信最终也会由于超期而被系统删除。

因此对于点对点业务而言，此项参数的合理配置建议为24小时。

2、对于一些业务种类较多（例如含短信群发业务、梦网业务）的短信中心，为保证系统安全，我们更是建议采取24小时的单条短信保存时限设置。

因为承载广告群发业务以及梦网业务的短信中心，内存空间或者数据库空间占用率通常较高（成都康维短信中心，数据库空间150万，承载广告群发业务以及梦网络下行等业务，根据统计，广告群发的关机率约为20%，梦网下发的关机率约为10%，数据库空间经常超过100万），因此若被叫缓存数设置过高，不仅无明显的经济效益，反而容易导致数据库被占满，给网络的安全带来隐患。

三、短信系统重发参数

参数释义：

短信中心对于一些由于各种原因首次下发失败的短信执行即定的发送机制进行重发。

现网重发机制主要有两类：

一、定时重发（华为）：

根据不同的错误代码按原定的重发时间间隔进行周期性的重发。

二、智能重发（康维）：

根据不同的错误代码按原定的重发机制进行由密到疏的重发。

现网重发机制主要包括用户原因的重发和网络原因的重发：

一、用户原因：

1、用户关机。

2、PAGING无应答

3、手机内存满。

4、用户忙：

5、终端设备不支持。

6、被叫用户无短信功能

二、网络原因：

1、HLR/MSC拒绝

2、HLR/MSC无应答：

3、HLR/MSC系统错误：

目前不同短信中心设备对不同错误代码的重发机制差异很大，例如，华为短信中心将用户关机和PAGING无应答作为一种错误代码来制定重发机制，而康维则是分开制定的；华为短信短信中心可将各类网络原因分开制定重发机制，而康维短信中心则是将网络原因作为一种错误代码而制定重发机制的。

为了使重发机制的测试结果具有可推广性，我们选择在成都府青短信中心（华为）上进行测试。

测试环境：

府青短信中心（华为），承载成都点对点短信业务以及成都用户梦网点播等上行短信业务。

1、处理能力：

300万BHSM

2、日短信提交量（MO提交量）：

约为340万左右。

3、内存占用情况：

通常情况下5万条左右，内存容量为70万条。

测试内容：

1、用户原因的重发机制：

1）缺席用户/内存满：

由于系统对用户忙以及终端设备不支持的重发数量较少，因此本次测试，主要针对缺席用户（关机/出服）以及内存满这两类错误代码的重发时间的不同设置进行测试。

测试方法：

关闭除缺席用户和内存满之外的所有重发，分别将这两种错误代码的重发间隔设置为10小时和10分钟，统计A表上非首次发送成功的平均延时。

测试结果：

建议参数配置：

系统默认最长重发时间间隔。

（华为为10小时）

理由：

根据规范，短信中心在首次下发收到用户关机/出服或内存满的状态报告之后，将通知被叫用户归属HLR对该用户数据置消息等待位HNRF或MCEF，同时用户所在的VLR也将对该用户的拜访数据置消息等待位。

如果用户在原VLR或新VLR开机/上网或清理内存，VLR或位置更新的信令均将通知HLR向SMSC发alertsc消息，从而保证用户能在第一时间接收到短信。

也就是说正常情况下，短信中心对这些错误代码的重发是完全没必要的，过于密集的重发设置只会加重短信中心系统负荷以及HLR的信令负荷。

2）用户忙：

用户由于拨出/接入电话、发送/接收短消息、位置更新等行为占用SDCCH信道而导致短信中心收到用户忙的错误代码。

从全天统计来可看，数量极少，考虑到部分机型开机后一段时间才能接收短信（MOTOROLA老款6188、6288），因此此项参数的建议设置为5分钟周期性重发。

3）终端设备不支持：

建议直接删除不进行重发。

4）被叫无短信功能：

建议直接删除不进行重发。

2、网络原因的重发机制。

1）HLR/MSC无应答：

通常两种情况下会出现：

i）MSC对来自SMSC的forwardsm信令的ack应答消息由于各种网络原因（例如SDCCH掉话等）未能返回到SMSC。

此类情况出现概率极小，一旦这种情况，往往被叫用户实际已接收到了短信。

若短信中心对此错误进行重发，将造成被叫用户重复接收。

ii）信令转接局STP上MSISDN以及MSCID的GT数据做错或漏做，或HLR/MSC上短信中心号码的GT数据做错或漏做，造成短信中心无法收到sendroutinginfo寻址消息或forwardsm下发消息的返回信令。

若出现这种情况，无论怎样重发均是不会成功的。

只能通过保证GSM网络的相关GT数据的正确来避免此类情况的出现。

建议参数配置：

直接删除不进行重发。

理由：

设置重发不但容易导致被叫用户重复接收，另一方面，在出现传输阻断、STP以及本地重要MSC/HLR退服等意外的情况下，短信中心内存空间将会很快被占满从而导致业务中断。

2）其余网络原因的重发设置：

主要有两类。

HLR/MSC拒绝：

HLR/MSC对来自SMSC的sendroutinginfo或forwardsm信令直接回送ABORT消息。

该错误代码的数量比例较高，在4月份对取消网络原因的重发后统计，府青短信中心平均每天收到的这种错误代码数量在3万条以上，是影响短信接通率指标的主要原因之一。

我们曾在交换侧对此错误代码进行了长期的跟踪和观测发现，该错误代码的出现完全随机，错误代码的数量只和下发业务量成正比，且和HLR/MSC的CP负荷、信令链路负荷、应答等待参数设置等均无关，通常第2次发送即能成功。

（关于制定重发前后错误代码数量的对比详见《影响短信质量各类原因及优化方案》）

HLR/MSC系统错误：

HLR/MSC对来自SMSC的sendroutinginfo或forwardsm信令回送systemfailure。

该错误代码的数量比例较高，在4月份对取消网络原因的重发后统计，府青短信中心平均每天收到的这种错误代码数量在1万条以上，是影响短信接通率指标的主要原因之一。

在交换侧对此错误代码进行跟踪和观测发现，造成MSC侧回送systemfailure的原因之一是由于无线SDCCH掉话导致了MSC对手机的鉴权失败。

（详细分析见后）通常第2次发送即能成功。

（关于制定重发前后错误代码数量的对比详见《影响短信质量各类原因及优化方案》）

测试方法：

将以上两类错误代码的重发时间间隔分别设置为5分钟、10分钟和不重发进行测试，对比修改前后指标情况以及网络错误代码的重发情况。

测试结果：

（图一）

由图可见，过密的重发机制对接通率的影响是明显的。

（图2）

上图中，6月16日（周一）网络错误代码的重发机制为5分钟重发，6月17日（周二）网络错误代码重发机制为10分钟重发，23日和24日（周一、周二）网络错误代码的重发机制为不重发。

由于这几天同为周一和周二，提交量等话务模型相近（均为340万左右），因而具有可比性。

由图可见，取消重发后的23日和24日，短信中心全天由于收到HLR/MSC拒绝以及HLR/MSC系统错误这两种错误代码而首次下发失败的条数既是全天下发失败的次数，约31200条左右。

当将这两种错误代码的重发机制设定为5分钟和10分钟，全天下发失败的次数分别为首次下发失败次数的1.58倍和1.32倍。

这说明首次下发失败的短信之中，其中绝大部分第1次重发即能成功，另外少部分无论怎样重发也不能成功。

我们对数据库中6月16日以及6月17日两天由于这两类错误代码而最终下发失败的数量进行了统计：

（图3）

由上图可见，每天最终下发不成功的短信条数约为1200条左右，正是这极少部分（不足网络原因首次下发失败总数的4%）的短信被系统反复重发，导致了网络原因下发失败次数的增多。

建议参数配置：

10分种

理由：

1、从以上统计结果可以看出，HLR/MSC拒绝以及HLR/MSC系统错误这两种错误代码其中大部分通常在短信中心第1次重发即能成功，但也不能排除有少量错误无论发送多少次均不能成功的可能。

2、由MT成功率指标的计算公式

MT成功率=短信中心下发成功的短信条数/（短信中心下发的短信条数含重发-用户原因造成的发送失败次数含重发）*100%

可见网络错误代码的周期性重发时间间隔若设置过密，将有可能造成“短信中心下发的短信条数含重发”此项参数指变高，从而导致接通率指标的下降。

从图一可见，网络错误的重发由5分钟改到10分钟，指标有明显的提高。

3、由于HLR/MSC拒绝以及HLR/MSC系统错误这两种错误代码出现几率较高，因此重发时间间隔设置过厂，被叫用户将明显感觉到接收短信延时。

因此兼顾用户和指标两方面因素此项参数的建议配置为10分钟。

推广：

综合指标效益、用户感受、网络安全等方面因素，智能化的重发机制更有利于精品网络的建设。

根据以上周期性重发机制的设置原则，对于有智能重发功能的系统，我们建议：

缺席用户/内存满：

建议在消息有效期内尽可能的减少重发次数。

用户忙：

建议首次发送时间间隔为5分钟。

终端设备不支持：

建议直接删除不进行重发。

被叫无短信功能：

建议直接删除不进行重发。

HLR/MSC无应答：

建议直接删除不进行重发。

HLR/MSC拒绝&HLR/MSC系统错误：

建议首次重发时间间隔尽可能短（5分钟），之后的重发时间间隔尽可能长（1小时以上）。

另外，对各类网络错误代码未加以区分的短信中心，例如康维，我们建议网络原因错误代码的重发机制设定为首次发送时间间隔为5分钟，第2次发送时间间隔为30分钟，之后删除。

四、MSC短消息事件鉴权参数

在对各类网络原因影响短消息下发的分析中，我们发现导致MSC回送系统错误的一类原因是用户鉴权无响应，并且在系统错误呼损里占到60%以上比例。

典型信令流程如下：

从信令上看，表现为MSC收到寻呼响应后，下发鉴权请求，但由于鉴权无响应（无线SDCCH掉话）而导致发生系统错误。

对现网MSC上的相关短信参数进行分析，我们发现所有MSC上两类短信事件（本地用户发起/接收短消息）的鉴权参数均设置为每次鉴权。

为了证明过于频繁的鉴权机制对短信发送的影响，我们选在了在成都府青短信中心以及成都G3进行测试。

测试环境：

府青短信中心（华为），承载成都点对点短信业务以及成都用户梦网点播等上行短信业务。

1、处理能力：

300万BHSM

2、日短信提交量（MO提交量）：

约为340万左右。

3、内存占用情况：

通常情况下5万条左右，内存容量为70万条。

测试方法：

关闭短信中心网络错误代码的重发，调整MSC3上两类短信事件的鉴权机制为15次事件鉴一次权，统计调整前后MSC系统错误占下发量的比例。

测试结果：

从上图可见，两类鉴权参数调整之后，由于MSC系统错误导致的发送失败占发往MSC3全部短信数量的比例约为调整前的61.5%左右。

参数配置建议：

调整MSC本地用户发起/接收短信两类事件的鉴权频率为15次。

理由：

进行鉴权的意义仅在于确定SIM卡的合法性，防止非法SIM卡。

但若SIM卡是非法的，它在开机后的鉴权必定无法成功，更不可能完成位置更新。

各MSC对短信鉴权参数的设置是在开局之初制定的，我们认为在短信业务蓬勃发展的今天，这种过于密集的鉴权机制已不再适用：

1）由于无线SDCCH的掉话，可能导致用户提交短信时MSC对主叫手机的鉴权失败，在短信中心的统计上虽不会影响MO成功率，但对用户实际感受造成了影响。

2）由于无线SDCCH的掉话，短信在下发中由于MSC对被叫手机的鉴权失败而产生系统错误，短信中心运行重发机制，将导致被叫用户接收信息延时。

3）目前各MSC上本地用户做主叫/被叫两类电话事件的鉴权频率均为15次，既然目前很多用户短信业务量远比语音业务量多，因此这两类短信事件的鉴权频率为1次的设置显然是不合理的。

4）调整两类短信事件的鉴权频率，主要目的是避免不必要的鉴权造成的呼损，因此这项参数的调整，对于无线环境良好的地区，意义不大，但对于一些无线覆盖不好，SDCCH掉话严重的地区，其网络质量的改善是肯定的。

五、短信中心接口部分相关参数：

以下参数为短信中心的和其他网元接口部分的参数设置。

从现网情况来看，网络运行情况良好，若对在网系统这部分参数进行修改可能会引发严重的网络故障，因此我们未对其进行调整测试。

现将其列出，谨供参考：

短消息MAPSERVER取路由超时时间为40秒；

短消息MAPSERVER下发GSM网络消息超时时间为60秒；

短消息MAPSERVER等待状态报告超时时间为40秒；

短消息MAPSERVER等待后续MT消息超时时间为25秒；

短消息中心等待SCP应答时间为12秒

短消息中心等待短信网关时间为120秒

短消息中心（华为）接收来自同一SP（根据服务代码判断）的消息队列长度建议根据各SP业务量具体制定。

第三部分短信网关参数配置原则

以下参数配置数据流向均为MT，即短信ISMG（ISMG）->短信中心（SMSC）。

一、与短信中心接口

1.ISMG与SMSC重连时间间隔：

ISMG与SMSC连接中断后ISMG重新发起连接请求的间隔时间。

该值过短会造成SMSC拒绝连接；也不宜过长，否则会造成连接中断时间增加，造成SMA话单数量增加，建议值为10s（需要与SMSC上等待enquire_link超时时间一致）。

2.ISMG等待SMSC回复smpp_submit_resp时间：

ISMG向SMSC提交smpp_submit消息后等待SMSC回复response的时间。

如果太短，ISMG在等待时间内没有收到response,就会重新发送。

出现这种情况，SP一次提交可能造成用户重复接收2次以上,但是计费话单只能匹配一次成功。

这样会造成ISMG与SMSC的负载进一步加重。

所以这里必须根据SMSC的回复response时间值，进行严格评估，而且要根据ISMG的处理能力来配置。

如果太长，会造成ISMG临时消息在内存的积压，会严重增加ISMG负载。

所以这个值的设置还要看双方的处理能力，目前四川ISMG等待SMSC的response时间是120秒，运行情况良好。

3.smpp_submit有效期设置（valid_time）：

消息在SMSC的存活期。

这个值格式在SMPP协议中有说明，但是最大值和最小值没有没有明确地说明。

这个有效期是消息在SMSC的存活期，即消息在没有正常下发的情况下，在SMSC存储的时间。

这个值CMPP没有明确的规定，由SP在向ISMG提交cmpp_submit时自行设置，如果SP没有设置，ISMG就会添加一个缺省的有效期。

SMSC对这个值的检查也是千差万别。

有的检查是否为空，有的不检查。

有的短信中心如果设置有效期小于1个小时，短信中心根本就不给返回状态报告，所以有必要对这个值进行规定。

有效期越长，状态报告中EXPIRED错误越少，从而最大限度减少下发消息时由于用户关机原因造成下发失败，有效提高下发成功率。

但会导致SMSC存储队列加大，加重SMSC的存储负载。

目前四川ISMG设置为16个小时，根据下面对不同有效期的测试结果统计，建议值为24小时。

短信中心返回状态报告统计

统计时间

消息有效期（小时）

状态报告发送成功数

状态报告发送失败数

状态报告发送成功率

EXPIRED

占状态报告总数比例

6-1114:

00－6-1214:

00

12

2324494

1271384

64.64%

618532

17.20%

6-1322:

00－6-1422:

00

16

2621377

1320307

66.50%

506780

12.86%

6-1514:

00－6-1614:

00

20

2471927

1276150

65.95%

436022

11.63%

6-1800:

00－6-1900:

00

24

2616815

1119656

70.03%

106670

2.85%

4.ISMG下发等待提交队列：

ISMG向SMSC提交MT消息时的临时缓存消息队列。

正常情况下，ISMG向SMSC提交MT消息不会形成积压，根据最新的CMPP协议规范（补充版），ISMG到短信中心MT连接出现异常时，短信下发不终止，而是直接生成SMA话单，并且该值如果配置过大将过多占用ISMG的I/O资源，降低系统性能，需要兼顾接通率和系统性能，目前四川ISMG设为2048条，运行情况良好。

二、与SP接口

1.接收SP提交消息队列：

ISMG临时缓存SP提交消息队列。

该队列大小设置与ISMG其他外围接口有关，如安全检查、SCP、SMSC等，正常情况下不会形成大量积压，如果配置过大将过多占用ISMG的I/O资源，降低系统性能，目前四川ISMG设为4096条。

2.SP等待ISMG回复cmpp_connect_resp时间：

SP向ISMG发送cmpp_connect消息后等待ISMG回复response的时间。

该值如果太小将导致SP频繁向ISMG发起连接，将造成ISMG系统资源的浪费，建议至少为30秒。

3.SP等待ISMG回复cmpp_submit_resp时间：

SP向ISMG发送一条cmpp_submit消息后等待ISMG回复response的时间。

该值不能设置太小，ISMG在正常情况下会很快给SP返回response，但是ISMG要到016做安全过滤，神州行用户还要到SCP进行实时扣费，所以ISMG的部分短信的回复可能会变慢，再加上大部分SP通过Internet接入ISMG，网络条件有的时候会变得不太稳定，如果设置过小，极易导致SP向ISMG重复提交短信，造成用户重复接收，ISMG也无法区分是否为超时重发从而重复计费。

建议设置为60秒。

三、与SCP的接口

该部分ISMG侧参数配置与SCP本身性能、处理速度等关系较大，配置时需要考虑SCP本身性能因素。

4.ISMG发送请求到SCP后等待回复结果的时间：

ISMG向SCP发送神州行扣费请求后等待SCP回复鉴权扣费结果的时间。

该值太小易导致神州行扣费超时，太大将导致ISMG等待扣费队列溢出，正常扣费请求无法进入队列，也会造成神州行扣费失败。

目前四川ISMG设为20秒，运行情况良好。

5.ISMG等待扣费队列：

ISMG上允许的最多同时等待SCP应答的请求数目。

该值太小易造成队列频繁溢出，太大将增加ISMG和SCP双方的负荷，会影响神州行扣费成功率。

目前四川ISMG设为100条，运行情况良好。

需要注意的是，总的扣费队列大小还跟ISMG上层调用SCP接口的模块数有如下关系：

ISMG等待扣费队列总长＝单个ISMG等待扣费队列长度×ISMG上层调用SCP接口的模块总数。

四、与其他ISMG的接口

6.等待其他ISMG回复cmpp_fwd_resp的时间：

本省ISMG向其他ISMG提交cmpp_fwd消息后等待对方回复response的时间。

该值如果太小将