××通讯- 短信系统参数配置原则(初稿）
短信系统参数配置原则 （初稿） 四川移动通信责任有限公司 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条的短信存储数进行测试。 测试结果：（如图） [pic] [pic] 效益=下发成功的点对点短信条数/手机向短信中心提交的点对点短信条数 [pic] 配置原则建议：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小时，然后对修改前后效益以及内存占用 率进行统计分析。 测试结果：（如图） [pic][pic]效益=下发成功的点对点短信条数/手机向短信中心提交的点对点短信条数 配置原则建议：24小时。 理由： 1. 测试所在的短信中心业务较为单一，只有点对点业务，从上图的比较可以看出，单条短 信最大保存时限由24小时调整到48小时，内存占用明显上升，经济效益却明显的下降 这说明正常的在网用户，短信中心的待发短信保存时限很少会超过24小时，而对那些 长时间关机的用户，短信中心保存时限设置再高，这部分短信最终也会由于超期而被 系统删除。因此对于点对点业务而言，此项参数的合理配置建议为24小时。 2. 对于一些业务种类较多（例如含短信群发业务、梦网业务）的短信中心，为保证系统安 全，我们更是建议采取24小时的单条短信保存时限设置。因为承载广告群发业务以及 梦网业务的短信中心，内存空间或者数据库空间占用率通常较高（成都康维短信中心 ，数据库空间150万，承载广告群发业务以及梦网络下行等业务，根据统计，广告群发 的关机率约为20%，梦网下发的关机率约为10%，数据库空间经常超过100万），因此若 被叫缓存数设置过高，不仅无明显的经济效益，反而容易导致数据库被占满，给网络 的安全带来隐患。 [pic][pic] 三、短信系统重发参数 参数释义：短信中心对于一些由于各种原因首次下发失败的短信执行即定的发送机制进 行重发。现网重发机制主要有两类： 1. 定时重发（华为）：根据不同的错误代码按原定的重发时间间隔进行周期性的重发。 2. 智能重发（康维）：根据不同的错误代码按原定的重发机制进行由密到疏的重发。 现网重发机制主要包括用户原因的重发和网络原因的重发： 1. 用户原因： 1. 用户关机。 2. PAGING无应答 3. 手机内存满。 4. 用户忙： 5. 终端设备不支持。 6. 被叫用户无短信功能 2. 网络原因： 1. HLR/MSC拒绝 2. HLR/MSC无应答： 3、HLR/MSC系统错误： 目前不同短信中心设备对不同错误代码的重发机制差异很大，例如，华为短信中心将 用户关机和PAGING无应答作为一种错误代码来制定重发机制，而康维则是分开制定的； 华为短信短信中心可将各类网络原因分开制定重发机制，而康维短信中心则是将网络原 因作为一种错误代码而制定重发机制的。为了使重发机制的测试结果具有可推广性，我 们选择在成都府青短信中心（华为）上进行测试。 测试环境：府青短信中心（华为），承载成都点对点短信业务以及成都用户梦网点播等 上行短信业务。 1. 处理能力：300万BHSM 2. 日短信提交量（MO提交量）：约为340万左右。 3. 内存占用情况：通常情况下5万条左右，内存容量为70万条。 测试内容： 1、用户原因的重发机制： 1. 缺席用户/内存满：由于系统对用户忙以及终端设备不支持的重发数量较少，因此本次 测试，主要针对缺席用户（关机/出服）以及内存满这两类错误代码的重发时间的不同 设置进行测试。 测试方法：关闭除缺席用户和内存满之外的所有重发，分别将这两种错误代码的重发 间隔设置为10小时和10分钟，统计A表上非首次发送成功的平均延时。 测试结果： [pic][pic] 建议参数配置：系统默认最长重发时间间隔。（华为为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次发送即能成功。（关于制定重发前后错误代码数量的对比详见《影响短 信质量各类原因及优化方案》） [pic] 测试方法：将以上两类错误代码的重发时间间隔分别设置为5分钟、10分钟和不重发进 行测试，对比修改前后指标情况以及网络错误代码的重发情况。 测试结果： [pic] （图一） 由图可见，过密的重发机制对接通率的影响是明显的。 [pic] [pic] （图2） 上图中，6月16日（周一）网络错误代码的重发机制为5分钟重发，6月17日（周二）网 络错误代码重发机制为10分钟重发，23日和24日（周一、周二）网络错误代码的重发 机制为不重发。由于这几天同为周一和周二，提交量等话务模型相近（均为340万左右 ），因而具有可比性。 由图可见，取消重发后的23日和24日，短信中心全天由于收到HLR/MSC拒绝以及HLR/M SC系统错误这两种错误代码而首次下发失败的条数既是全天下发失败的次数，约312 00条左右。当将这两种错误代码的重发机制设定为5分钟和10分钟，全天下发失败的 次数分别为首次下发失败次数的1.58倍和1.32倍。这说明首次下发失败的短信之中， 其中绝大部分第1次重发即能成功，另外少部分无论怎样重发也不能成功。我们对数 据库中6月16日以及6月17日两天由于这两类错误代码而最终下发失败的数量进行了统 计： [pic] （图3） [pic] 由上图可见，每天最终下发不成功的短信条数约为1200条左右，正是这极少部分（不 足网络原因首次下发失败总数的...
××通讯- 短信系统参数配置原则(初稿）