移动公司短信系统参数配置原则

短信系统参数配置原则

（初稿）

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

2003年六月

前言

受集团公司委托（移网通[2002]528号《关于委托编写短信系统参数配置原则的通知》），四川移动通信有限责任公司负责制定短信系统参数配置原则。为此公司上下十分重视，立即成立了以网络部副主任刘耕为组长的参数编制小组，对短信系统相关的参数进行了大量的测试和分析，为提高短信各设备间的兼容性和下发成功率以及解决短信中心、短信网关的参数设置不规范，导致省际、省内各级短信设备配合不一致，影响短信业务成功下发的问题，提出了参数配置建议。由于时间和水平有限，《原则》当中难免有考虑不周之处，敬请指正。

目录

第一部分情况简介3

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

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

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

三、短信系统重发参数11

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

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

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

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

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

一、与短信中心接口24

二、与SP接口26

三、与SCP的接口27

四、与其他ISMG的接口28

第一部分情况简介

（一）编写小组成员

组长：刘耕

副组长：杨书其白庆王耀阳

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

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

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

点对点短信中心：华为（软件版本 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提交成功率、效益（成功下发的点对点短信条数/手机向短信中心提交的点对点短信条数 X 100%）以及内存占用率进行统计和分析。由于各短信设备制造商均未建议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表上

非首次发送成功的平均延时。

测试结果：

9000

9500

10000

10500

11000

11500

12000

延时统计(秒)

建议参数配置：系统默认最长重发时间间隔。（华为为10小时）理由：根据规范，短信中心在首次下发收到用户关机/出服或内存满的状态报告之后，将通知被叫用户归属HLR对该用户数据置消息等待位HNRF或MCEF，同时用户所在的VLR也将对该用户的拜访数据置消息等待位。如果用户在原VLR或新VLR开机/上网或清理内存，VLR或位置更新的信令均将通知HLR向SMSC发alert sc消息，从而保证用户能在第一时间接收到短信。也就是说正常情况下，短信中心对这些错误代码的重发是完全没必要的，过于密集的重发设置只会加重短信中心系统负荷以及HLR的信令负荷。

2）用户忙：用户由于拨出/接入电话、发送/接收短消息、位置更新等行为占用SDCCH信道而导致短信中心收到用户忙的错误代码。从全天统计来可看，数量极少，考虑到部分机型开机后一段时间才能接收短信（MOTOROLA 老款6188、6288），因此此项参数的建议设置为5分钟周期性重发。

3）终端设备不支持：建议直接删除不进行重发。

4）被叫无短信功能：建议直接删除不进行重发。

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

1）HLR/MSC无应答：通常两种情况下会出现：

i)MSC对来自SMSC的forward sm信令的ack 应答消息由于各种

网络原因（例如SDCCH掉话等）未能返回到SMSC。此类情况出现

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

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

ii)信令转接局STP上MSISDN以及MSCID的GT数据做错或漏做，或HLR/MSC上短信中心号码的GT数据做错或漏做，造成短信中心无法收到send routing info寻址消息或forward sm下发消息的返回信令。若出现这种情况，无论怎样重发均是不会成功的。只能通过保证GSM网络的相关GT数据的正确来避免此类情况的出现。

建议参数配置：直接删除不进行重发。

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

2）其余网络原因的重发设置：主要有两类。

HLR/MSC拒绝：HLR/MSC对来自SMSC的send routing info或forward sm信令直接回送ABORT消息。该错误代码的数量比例较高，在4月份对取消网络原因的重发后统计，府青短信中心平均每天收到的这种错误代码数量在3万条以上，是影响短信接通率指标的主要原因之一。我们曾在交换侧对此错误代码进行了长期的跟踪和观测发现，该错误代码的出现完全随机，错误代码的数量只和下发业务量成正比，且和HLR/MSC的CP负荷、信令链路负荷、应答等待参数设置等均无关，通常第2次发送即能成功。（关

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

HLR/MSC系统错误：HLR/MSC对来自SMSC的send routing info 或forward sm信令回送system failure。该错误代码的数量比例较高，在4月份对取消网络原因的重发后统计，府青短信中心平均每天收到的这种错误代码数量在1万条以上，是影响短信接通率指标的主要原因之一。在交换侧对此错误代码进行跟踪和观测发现，造成MSC侧回送system failure的原因之一是由于无线SDCCH掉话导致了MSC对手机的鉴权失败。（详细分析见后）通常第2次发送即能成功。（关于制定重发前后错误代码数量的对比详见《影响短信质量各类原因及优化技术方案》）

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

测试结果：

0.97

0.975

0.98

0.985

0.99

0.995

1

（图一）

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

失败次数

（图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日两天由于这两类错误代码而最终下发失败的数量进行

了统计：

0200

400

600

800

1000

1200

16日最终下发失败条数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 系统错误占下发量的比例。

测试结果：

00.001

0.002

0.003

0.004

失败比例

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

参数配置建议：调整MSC 本地用户发起/接收短信两类事件的鉴权频率为15次。

理由：

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

SIM卡是非法的，它在开机后的鉴权必定无法成功，更不可能完成位置更新。各MSC对短信鉴权参数的设置是在开局之初制定的，我们认为在短信业务蓬勃发展的今天，这种过于密集的鉴权机制已不再适用：

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

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

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

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

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

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