短消息CDR分析指导书 文档密级：
场景12：收到Deliver，回Ack，回Deliver，无错误码
全网绝大部分MT短消息都是成功的，即三条交互信令的次数都是相同的，且无错误码（最后一条Ack的错误码=255）。
场景13：收到Deliver，回Ack，回两条Deliver，无错误码
最后一条交互信令—-“BSC发送ADDS Deliver次数”—出现多条Adds_Deliver（上表中归纳为两条），这种情况一般为不规范的手机发送了多条Ack短消息，或者前空口向不好，导致Ack短消息重发，华为MSC会自动抛弃多出的Ack短消息不予处理。
短消息始发的分析与终接分析类似，不再详细描述。
5.5 时延分布
利用CDR时长相关的字段，对短消息始发和终接进行时延分布的分析。 有两种计算短消息时延的方法： 1， 2，
基于呼叫记录数，即业务信道占用次数。
基于短消息发送条数，即考虑建立一次业务信道，可能会发送多条短消息的因素。
分析主叫短消息发送时延计算的约束条件为：呼叫标志为0，呼叫状态为1，最终的业务选项为6的呼叫，直接使用呼叫持续时长进行计算总的短消息发送时延，使用（呼叫持续时长-指配时长-捕获Preamble时长-协商时长）可以计算出业务信道占用时长。使用第二种计算方法时，短消息条数使用“BSC发送ADDS_Deliver次数”进行计算。
被叫短消息发送时延计算约束条件：呼叫标志为1，呼叫状态为1，最终的业务选项为6的呼叫。直接使用呼叫持续时长进行计算总的短消息发送时延，使用（呼叫持续时长-寻呼时长-指配时长-捕获Preamble时长-协商时长）可以计算出业务信道占用时长。使用第二种计算方法进行计算时，短消息条数使用“BSC接收ADDS_Deliver次数”进行计算。
说明：
? 基于CDR计算出来的呼叫持续时长比实际的短消息发送时延要长一些，因为在发
送完最后一条Ack短消息后，还有一段释放空口的流程，有必要的话需要说明。 ? 被叫的呼叫持续时长是包含了寻呼时长的，这一点需要特别注意，否则计算被叫短
2013-3-31
华为机密，未经许可不得扩散
第21页, 共26页
短消息CDR分析指导书 文档密级：
消息时延时很可能会使用（寻呼时长+呼叫持续时长）进行计算，这样相当于把寻呼时长计算了两次，带来约2.3秒左右的误差。
? 使用该方法计算出的时延，只是B侧承载短消息发送的时延，并不是用户真正感
受到的短消息时延，比如短消息发送失败后短消息中心根据重发策略进行重发等场景，就是通过CDR计算时延无法评估的。
? 始发短消息连发由终端控制，终端的超长短消息发送策略（能力），决定了始发短
消息是否能通过建立一次业务信道发送多条短消息。终接短消息连发由MSC控制，MSC判断短消息发送缓冲区中是否有堆积的短信，决定是否采取连发。华为MSC从V1R6C02B059SP08开始支持该功能，由软参控制。
还有一点值得注意，由于部分终端（如酷派某款终端）对短消息的处理不规范，在发完短消息后不会主动发起释放，而是一直占用空口，这样就会导致主叫短消息在11秒左右的时间点的呼叫持续时长较多。下图为主被叫时延的对比情况。
主叫短信发送时延分布80000700006000050000400003000020000100000160000140000120000100000800006000040000200000被叫短信发送时延分布 5.6 失败原因组合分析
主要基于上面提到的释放原因值，Ack短消息错误码以及短消息交互信令的匹配程度，结合短消息发送和接收的信令流程，进行综合分析。
由于三类因素结合起来分析，可能的组合太多，下文将以案例的形式给出问题分析的思路。
案例1：MO短消息，BSC发送ADDS_Deliver次数为1，BSC接收ADDS_Deliver次数和BSC回复ADDS_Deliver Ack次数都为0，释放原因值为11F（MSC释放），最后一条Ack的错误码为0，呼叫持续时长基本都大于11秒。
结合文章开始时给出的信令流程图分析，BSC向MSC发送了Adds Deliver消息后就再也没有得到应答，手机一直等待前向发来的DBM，MSC发现业务信道空闲，定时器超时，
2013-3-31
华为机密，未经许可不得扩散
第22页, 共26页
短消息CDR分析指导书 文档密级：
发起释放。这类问题，由于BSC已经将Adds_Deliver发送给MSC，MSC应该再将MC的处理建议回送给BSC，没有收到消息，可能的几种情况为：1，A口链路不稳定，MSC处理问题，MSC与短消息中心之间的链路（包括STP）的问题，MC处理问题（包括短消息中心不识别上报上来的Adds_Deliver直接丢弃等），需要联合上层网元综合分析，如果是网内短消息，也可结合MT短消息CDR，和实际测试结果分析是否短消息实际已经发出。
案例2：MO短消息，BSC发送ADDS_Deliver次数为1，BSC接收ADDS_Deliver次数和BSC回复ADDS_Deliver Ack次数都为0，释放原因值为1000（手机释放），最后一条Ack的错误码为0，呼叫持续时长基本都小于2秒
与案例1类似，都是1-0-0的排列方式，但是呼叫释放时有手机发起的，且业务信道占用时长（呼叫持续时长减去呼建状态的三个时长）很短。这类不匹配，则很有可能是终端行为不规范造成的，终端发送了点对点短消息后立即拆线，BSC还没收到MSC会的Adds Deliver，呼叫就已经释放了。
案例3：MT短消息，BSC接收ADDS_Deliver次数和BSC回复ADDS_Deliver次数为1，BSC回复ADDS_Deliver Ack次数都为0，释放原因值为11F（MSC释放），最后一条Ack的错误码为0。
结合信令流程进行分析，可知BSC没有收到MS在收到点对点短消息后给系统回的层二Ack。造成这种现象的原因主要有以下两种：1，空口不稳定，前向发送的短消息MS没有收到，或者反向的层二Ack和Ack短消息（包括重发）都没有收到，一般来说会伴随呼叫持续时长超过11秒的现象。需要重点检查出现问题的接入小区的分布，找出Top Cell进行有针对性的优化。2，终端问题，收到短消息后不向系统侧回复任何消息，已知型号为LG W800。
案例4：MT短消息，BSC接收ADDS_Deliver次数、BSC回复ADDS_Deliver次数和BSC回复ADDS_Deliver Ack次数均为1，释放原因值为11F（MSC释放），最后一条Ack的错误码为35（目标手机内存满）。
这种失败在各个本地网短消息发送失败的情况中一般都会占到很大的比例，通常由由两类手机造成：1，低端手机，只有卡存短消息功能，或者机存短消息能力有限，导致存储空间满；2，一些高端手机在运行大型应用程序如某些游戏时，由于CPU处理不及时，导致短消息处理失败，都会返回35号错误码。
2013-3-31
华为机密，未经许可不得扩散
第23页, 共26页
短消息CDR分析指导书 文档密级：
5.7 实战举例
以下两个例子，充分体现了CDR字段中添加短消息可测手段的重要性。
1，电信领导投诉短消息接收异常，一次只收到了超长短消息的一半，另两次根本没有收到短消息。但是从CDR记录中分析，BSS侧的处理是完全正常的，说明是领导使用的手机处理上出现了问题。
短消息丢失问题CDR分析处理报告
2009-04-14
1. 问题现象
主叫号码：13301168120 – IMSI：460030900112862 – ESN：3571292516 被叫号码：18910111125 – IMSI：460036011023790 – ESN：2900509078 被叫号码接收短信异常情况如下：
2009/04/14 9点25分，收到一半短消息； 2009/04/14 10点59分，没有收到短消息； 2009/04/14 11点07分，没有收到短消息。 2. 问题分析
分析思路：通过分析CDR数据观察BSC侧短消息接收和发送状况。 a) BSC侧分析
通过ＢＳＣ侧的ＣＤＲ功能进行数据统计分析，如下图：
2013-3-31
华为机密，未经许可不得扩散 第24页, 共26页
短消息CDR分析指导书 文档密级：
9:25时：
主叫发短消息，ＣＤＲ中看发了２条ADDS Deliver消息，说明短消息被拆成两条 被叫接收两次短消息，ＣＤＲ中看该时间有两条记录，每条记录的ADDS Deliver 数是１，说明分两次收到；
从被叫的CDR属性“BSC接收ADDS_Deliver次数”、“BSC回复
Adds_Deliver_Ack次数”、“BSC发送ADDS_Deliver次数”都是1，说明空口跟终端的交互正常，当终端回复DBM消息后BSC才会向MSC发送ADDS_Deliver消息，所以从CDR跟踪消息看，终端已经正常接收到短消息。
同样的 10:59 和 11:07 的结果也是一样。 结论
所以从CDR的数据分析中空口短信的接收和发送是正常的。 优化建议
检查终端对收到的短消息的处理方式是否存在异常。
2013-3-31
华为机密，未经许可不得扩散 第25页, 共26页
短消息CDR分析指导书 文档密级：
6 附件
1，
CDR过滤工具单机版使用指导书
2，
Sql脚本示例（仅提供示例，各本地网应根据现场实际需要编写脚本）
2013-3-31
华为机密，未经许可不得扩散 第26页, 共26页
百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库短消息CDR分析处理指导书V1.1-20090512(5)在线全文阅读。
相关推荐：