彩信(MMS)端到端优化方案.doc

彩信端到端优化方案
目 录
1 概述 2
2 端到端分析的主要分析方向 2
2.1 业务性能分析 2
2.1.1 业务概述 2
2.1.2 彩信失败原因分类 4
2.1.3 分析方法 5
2.1.4 实际分析案例 举例 6
彩信中心回复状态异常――130 Service Denined 6
某些终端无法识别特定的MMS_TID ― 132 Unrecognised 8
2.2 用户业务感受 9
2.2.1 彩信端到端时长分析方法 10
2.2.2 用户投诉问题的处理 11
2.3 彩信业务流量分析 12

1 概述
随着彩信业务的迅猛增长，由此产生的一些问题也日益值得我们关注。对于致力打造精品网的今天，彩信的分析和优化是一个必需的课题。
同时，彩信的分析也是一个难点。因为它不仅涉及的网元多，而且涵盖的信令协议多，包括IP、UDP、TCP、HTTP、WTP、WSP、MMSE等。从核心网到无线网，以往对彩信的分析往往集中于对特定问题的分析。这种分析方法在越来越重视端到端业务运行以及客户感受的今天已不能完全满足客户的需要；我们需要利用以往的技术积累，结合多种技术手段，从一个完整的业务流程的角度对彩信进行分析，这样虽然较为困难，但却是彩信分析和优化的根本方法。

2 端到端分析的主要分析方向
作为一个完整的业务流程，我们需要对以往的分析方法进行整合。关注彩信业务的各个方面，主要包括业务性能、用户使用业务感受、业务流量分析等。

2.1 业务性能分析
业务性能主要指业务运营的效率，如MMS-MT/MO成功率，分析网络和用户原因造成的各种业务失败等等。
2.1.1 业务概述
现网中彩信业务有基于WAP1.0和WAP2.0两种形式，两者实现大致相同。以WAP1.0协议栈为例，彩信业务流程如下：
1， MO过程
Step 1
Step 2
Step 3
Step 4

2， MT过程
Step 3
Step 4
Step 2
Step 1

说明：
步骤1，步骤4 分别是 RADIUS start 和stop过程，包含在PDP激活和去激活的过程中。
步骤2，WSP层的建立连接过程，对于建立在WAP2.0协议栈上的彩信业务，对应的是TCP三次握手的过程。
步骤3，MMS层数据包的发送、接收；对于接收流程来说，还包括彩信接收后的回执。
2.1.2 彩信失败原因分类
从图示的彩信规范流程来看，彩信可能发生的呼损环节很多，主要集中在终端与彩信中心的数据包交互过程阶段。
由于“网络原因”导致的彩信业务失败
· 无线原因导致传输中断；
· GPRS承载网SGSN，GGSN在数据包传递中漏包；
· 查询E-DNS超时无响应；
· WAP网关超时无响应；
· 彩信中心超时无响应；
· 短信中心下发PUSH消息失败。

由于“终端原因”导致的彩信业务失败
· SDU存储容量太小，无法接收数据；
· 终端协议栈出错；
· 软件bug，比如某些类型的终端对特定的MMS ID不兼容；
· 终端异常导致底层链接（WSP 、TCP）中断；
· 非彩信终端接收彩信。

由于“用户原因”导致的彩信业务失败
发生呼损的主要表现为用户原因，例如“用设置错误，向联通手机发彩信”等内存满”；终端原因，如“SDU存储容量太小，软件bug”等；和网络原因，可能由无线网络产生，也有可能由核心网侧产生。
“用户原因导致彩信业务失败”则包括：
· 用户设置错误的彩信中心地址；
· 向联通手机、固定电话发送彩信；
· 发送过大的彩信；
· 过期接收彩信；
· 用户主动断开链接。

2.1.3 分析方法
作为端到端的业务性能分析，我们不仅把注意力集中于彩信中心，还需要集中于业务链上所有的节点，包含无线、核心网、WAP网关、短信中心等等。因此需要无线、核心网、短信中心、客服等方面的力量支持。
面对MMSC侧，我们主要对MM1,MM4口以及和SMSC的接口进行跟踪
· MM1接口，跟踪终端和彩信中心间的交互过程；
· MM4接口, 跟踪本地和异地MMSC间的彩信转发过程，
· MMSC与SMSC接口，PUSH消息的下发成功率。

对在业务链上其它节点：
· 通过Gn，Gi口的信令联合分析来跟踪WAP网关、核心网在业务承载方面的表现，以及在这一部分所造成呼损；
· 无线侧，通过专用的测试工具和拨打测试等方法对具体的端到端KPI做测试，考察无线环境对业务的影响。
· 在客服等方面的配合下，进行具体问题定位和优化。
· 探索一些新的技术尝试，如业务流程方式的变化给指标带来的影响。

2.1.4 实际分析案例 举例
彩信中心回复状态异常――130 Service Denined
在配合GPRS 第三方测试中发现彩信发送失败的现象，手机收到的m-send-conf消息中的回复状态显示为Service Denined。R接口的消息流程如下：

R接口MMS消息流程
为确定网络下发Service denied消息的源头，我们进一步分析Gi口的信令流程发现彩信中心MMSC发送给WAP网关的（HTTP）m-send-conf消息，其回复状态就是Service Denied，这说明，彩信发送失败是由于彩信中心拒绝了该彩信业务。根据我们以往的项目经验，彩信中心发送Serviced Denied原因是由于发送彩信的被叫号码错误——被叫为联通号段、固话或者其它非法号码。但在这个具体个案中被叫号码是正确的，并且由于问题是出现在CDS测试过程中，排除了终端异常的原因，我们判断造成业务失败的原因是彩信中心异常。
为了进一步探索问题的原因，我们记录了某一小时内出现回复状态是Service Denied的彩信发送失败流程， 发现： 1）时段中有64.15 % 比例被拒绝的Service Denied，其被叫号码是正常的。2）这些出现异常的Service Denied都来自于华为某彩信中心侧（ip 218.205.233.97）。因此我们分析后将问题定位为该彩信中心的运行异常。

11/1/2006(10:32~11:32）
11/2/2006(22:08~23:08)
Message
Counter
Rate
Counter
Rate
MMS m-send-req
9621
100%
9521
100%
Serviced Denied
475
4.94%
1523
16.00%
Message
Counter
Rate
Counter
Rate
Serviced Denied
475
100%
1523
100%
Service Denied (被叫号码正确)
115
24.21%
977
64.15%
Service Denied (被叫号码错误)
360
75.79%
546
35.85%
观测时段内状态值Service Denied的彩信发送发送拒绝和数据统计

某些终端无法识别特定的MMS_TID ― 132 Unrecognised
在彩信的MT过程中，彩信中心应该先通过短信中心向终端用户Push接收彩信的消息，其中含有提供彩信的MMS-ID 和MMS-Transaction-ID字段。但对于MMS-Transaction-ID字段的编码规范并没有特别的规定。于是我们实际中通过信令分析发现有某些类型的终端不支持MMS-Transaction-ID为“0”或”dN6SS6VcNPSbA”的编码，造成对彩信无法提取的现象，影响了业务的发展。比如下面的一个实例：
终端之后回复为132 Unrecognised 。
移动终端无法识别值为0的MMS-TID！

进一步地，我们将这些有异常的终端型号进行了排查、甄别，发现这些问题终端占市场上占的份额5％左右。确认后我们将名单提交给客户，建议督促终端厂家更新软件版本或着在彩信中心屏蔽“0”，”dN6SS6VcNPSbA”等容易引起问题的ID号。

问题终端型号集中在WAPPER MAUI，MMS User Agent，LENOVO-Vxxx/WAP2.0，CECT T868等

2.2 用户业务感受
在端到端分析中，我们除了关注网络业务成功率之外，还需要关注用户在使用该业务过程中的实际感受；对彩信业务，我们主要关注的方向如下：
· 彩信端到端时长分析；
· 彩信业务失败以及在业务不成功情况下的重发机制分析；
· 客户无法发送、收到彩信、重复收到同一彩信等具体的个案问题；

2.2.1 彩信端到端时长分析方法
端到端时长分析，仍以在多接口的信令分析为依据；详尽分析MMS-MO/MT过程中每一环节信令交互过程间的时延。比如对MO主要过程如下：
E-DNS
WAP GW
GGSN
MS
MMSC
1.
2.
3.
4.
5.
6.
7.

1) PDP 上下文激活
2) MS 和 WAP GW间建立连接
3) MS 数据上传
4) WAP GW根据MSISDN查找终端归属地的MMSC
5) WAP GW 和 MMSC 建立连接
6) WAP GW 向MMSC 发送数据
7) WAP GW 向终端发送确认，彩信发送完毕。
根据我们的经验，彩信时延主要包含在以下几个阶段：（按造成时延的大小排列）
· 终端向网关发送数据
· 网关向E－DNS 查询用户信息
· 网元间（终端和网关，网关和彩信中心）建立连接，以及建立PDP激活等为实际彩信数据包发送做准备的阶段
· 网关向彩信中心发送数据
我们需要分阶段得出每段延时，并对比消息流程考察数据包在网络中每个网元节点上（无线、核心网，WAP网关）的时间损耗。同时我们还要关注到：彩信业务的时延在很大程度上是依赖于彩信本身的长度大小的，因此我们在考察时延的同时还要考察彩信的长度。

Average Send-Conf-Delay
22.865 (s)

2.2.2 用户投诉问题的处理
针对用户投诉的无法收到彩信、重复收到同一彩信问题。我们可以采用拨测结合信令分析的方式加以解决，无法收到彩信可以参考前面的彩信性能分析了解失败原因；重复彩信通常可能由以下原因造成：
· 无线问题导致WAP网关未正确收到应答；
· WAP网关未正确转发应答到MMSC；
· 某些终端异常——在接收彩信数据完毕后，不能正确发送回执。

2.3 彩信业务流量分析
随着彩信业务的迅猛发展，已经在众多数据增值业务中起到越来越重要的地位。根据长期监测的经验，尤其在热点时段和地区（节假日，重大活动日）；彩信的业务量的突增往往对系统运行的稳定性带来相当大的影响。因此对彩信流量，时间/位置分布进行分析，对重大节日、活动、突发事件所带来的业务量波动进行提前预测并采取措施是十分必要的。
对彩信业务流量分析主要工作方向和思路有以下方面：
· 彩信业务量时间/位置分布；
通过统计数据对彩信业务流量在全天时段内的波动以及从本地网关分发各地彩信中心的分布进行统计，归纳现网话务模型；
· 节假日 彩信/寻呼量预测；
通过国庆，圣诞，元旦网络监测，我们发现在晚忙时高峰时段往往会突增大量的群发和重复发送的彩信。业务无响应比例过高，重复尝试的比例过高，会导致很快达到系统设备的容量瓶颈，系统负荷的增加同时导致业务成功率不断下降。对于该问题，我们已经先后在WAP 网关上进行了话务统计和信令方面的分析。针对设备负荷我们亦进行了讨论。
以往我们都会对即将到来的话务高峰进行预测，并对需要扩容的硬件制定方案；考虑到运营成本与可行性，我们不可能单纯依靠扩容来解决问题。我们希望在现有条件下利用一定的技术手段来预防问题的发生，或尽可能减少对网络的影响。
· 省内/省外业务比例分布；依据信令，我们可以归纳出省内外各地区出、入本地网的业务量，为以后的网络规划提供依据。
· 长、短彩信比例分布；通过信令分析的手段，我们能精确地统计出用户所发送彩信的长度分布，掌握用户行为，帮助我们根据话务模型提前做好相适应的设备参数设置。

12