彩信的架构。彩信和其它WAP应用的架构差不多，都要经过WAP Gateway中转。要注意的是彩信并非直接投递给接收方，而是像邮件一样，先发送给一个中间服务器MMS Proxy-Relay。MMS Proxy-Relay暂时保存彩信，然后通过push协议给彩信接收方发送一个通知，彩信接收方收到通知后从MMS Proxy-Relay上获取彩信内容。MMS Client和WAP Gateway之间用WAP传输协议传输，而WAP Gateway和MMS Proxy-Relay之间走传统的TCP/IP协议。
彩信的交互过程。对彩信客户端实现者来说，我们主要关心：彩信发送方与MMS Proxy-Relay之间的交互和彩信接收方和MMS Proxy-Relay之间的交互，这包括下列几个过程。 l 发送过程。这是彩信发送方把彩信发送给MMS Proxy-Relay的过程，MMS Proxy-Relay在收到彩信后会给发送方一个确认消息。 l 通知过程。为了把彩信投递给接收方，MMS Proxy-Relay要通过PUSH协议给接收方发送一条彩信通知消息，这个消息通常是一条特殊短信，里面包含彩信的位置URL。
l 彩信接收。接收方收到彩信通知后，从中取出URL，然后通过标准的HTTP GET请求从MMS Proxy-Relay上获取彩信。
l 彩信回执。当MMS Proxy-Relay成功的通知彩信接收方后，它会给彩信发送方发送一个消息表明彩信投递成功。
l 彩信阅读回执。彩信阅读回执是一条新彩信，它的传递过程和普通彩信没有什么差别，只是不能再有阅读回执。
彩信的PDU。PDU即协议数据单元，对应前面每种消息的消息格式。彩信的PDU和HTTP协议极为类似，当然相对来说要简单多了。它定义了一些常用的消息域，有的消息域是公有的，每种消息都可以使用，有的消息域是专用的，只有特定的消息才能使用。除了常用的消息域外，也可以自定义消息域，自定义消息域以X-打头，但不能以X-Mms-打头。常用的消息域如：
l 发送请求。m-send-req(终端<发送方>->彩信中心) l 发送确认。m-send-conf(彩信中心->终端<发送方>) l 彩信通知。m-notification-ind(发送PUSH：彩信中心<通过PUSH协议>->终端<接收方><特殊短信，包含URL>) l 通知回应。m-notifyresp-ind(收到PUSH回应：终端<接收方>->彩信中心) l 获取彩信回应。m-retrieve-conf（彩信中心->终端<接收方>） l 接收确认。m-acknowledge-ind(终端<接收方>->彩信中心) l 彩信回执。m-delivery-ind(彩信中心->终端<发送方>)
获取彩信只是一个普通的HTTP GET请求，而没有专门的PDU。
彩信的PDU编码。彩信PDU在语义上与HTTP协议类似，但是其编码方式并不一样，为了充分利用带宽，彩信PDU采用二进制方式编码。其编码规则很简单，预定义的消息域的KEY都有唯一的单字节编码，如：
而消息域的Value部分，如果只有几个固定的可选值，这几个值也用单子节的编码，由于这些值只出现在特定的上下文中，所以无需要全局唯一。
一、
Ping成功率
在两次测试中，湖南EDGE网络ping成功率都不太理想，未达到100%成功。我们从测试结果中看，Ping失败并不集中在某一地市，而是有一半的地市均有Ping失败。
【例】：
从各Ping失败测试点的log来看，就信号覆盖来说多数还是比较理想的，总的来说失败当时无线环境属于比较良好状态，因此我们分析一方面是否为FTP服务器瞬时多用户的处理能力有所欠缺，另一方面是否跟网络配置有少许关联。在PCU及BTS支持的情况下，建议抽取个别Ping失败率比较高的站，开启分组上行指配下移功能，从而提升在PACCH上建立上行TBF的性能，以提高一定的Ping成绩。
二、
CQT FTP下载
本次测试中虽然CQT FTP下载速率较上一次测试有明显提高，但有还存在着一些比较典型的问题。下举例说明：
1、
FTP下载时RLC BLER偏高
【例】：
本次测试中有一部分测试点，从RXLEVEL和C/I等来看，无线环境比较理想，但RLC BLER比较高，导致应用层下载速率降低。
因为误码率高，导致顺序包抵达时间不同，延时太长，或者包丢失。
2、
FTP下载时出现TCP Previous segment lost.
【例】：
本次测试中，有部分测试点无线环境良好，但下载中途应用层出现断传现象。从WSP协议浏览器里发现，断传时协议层出现了TCP Previous segment lost，既而TCP duplicate ack
建议在GB口上抓包分析是否属于无线侧问题，再进一步分析产生丢包的原因。
MMS成功率
问题描述：某GPRS网络无法正常发送MMS
问题分析：成功的MMS发送流程包括两个阶段
1）连接建立阶段，MS和WAP GATEWAY建立联系；
2）数据传送阶段，MS和WAP GATEWAY交互发送相关的彩信信息，MMS正常发送Gi口正常信息如下图所示：
n
此问题发生在第一阶段。
在WAP GATEWAY回的消息“WSP REPLY”中消息指示“Sorry Gateway is busy”，无法处理MS的连接请求。在WAP GATEWAY忙的情况下，手机进行了多次的连接尝试。最后达到尝试次数的门限，本次MMS业务失败。
造成这种情况原因：WAP GATEWAY侧忙。
n
解决措施:
重点检查WAP GATEWAY，WAP GATEWAY的确存在处理能力有限的问题，对WAP GATEWAY进行升级，问题解决。
4、
GPRS attach 分析
Gprs附着成功率低
XX大酒店(当时的服务小区CELLID: 11460 Channel: 2 BSIC：17 REXlev:-68)
【分析建议】
通过回放可知道，附着由于超时，引起失败。规范中，当Attach尝试开始时，手机向网络发送Attach Request消息，并启动定时器T3310，如果此消息中不包含P-TMSI，则网络向手机发送Identity Request消息，要求手机发送IMSI，手机回应Identity Response（含IMSI）消息。然后手机正常接收到Attach Accept后，回应Attach Complete，T3310停止。若T3310超时，手机会向网络再次发送Attach Request消息，并重新启动T3310。
从第5次发Attach Request消息，发了好多个Immediate Assignment，由于局部资源比较紧张或者无线环境差（当时的误块率为100%）没有收到Attach Accept，最后由于超时从而导致附着失败.
5、
EGPRS典型案例1-由于FTP丢包导致下载速率低
问题描述
在CQT测试中，发现金阳光测试点的FTP速率下降严重,从以前的18k下降为9k左右，为此于6月6日下午对金阳光大酒店做进一步CQT FTP下载测试，并联系核心网工程师在Gb接口和Gn接口分别抓包。
通过CDS 分析,可以看到Seq = 103661丢包要求重发,整个下载过程中丢包重传较多6、
RAU更新失败后连续Ping失败并掉线
问题描述
在DT测试中，南三环省射击场附近的FTP测试时由LAC14139--LAC14093路由区更新成后后，Routing
area updata reject
造成的 FTP download fail ，如下图所示
问题一、测试时通过数据协议查看器，发现一般在WAP图铃下载失败或者耗时长的情况下都会出现下行丢包的问题，如下图，我们初步判断由于手机没有收到完整的下行数据包，因此没有回复WTP Ack而是回复了WTP Negative Ack，最终导致下行数据重传超时退出，下载失败。
1．图铃下载失败CDS数据协议查看器抓图
有时丢包会经过一次或者数次重发成功，图铃下载成功，但是经过数据重发，耗时较长，因此下载速率就会受到很大影响。重发成功后图铃下载成功的测试截图如下：
问题二、在1月5日以后的测试中又发现下载时数据协议查看器中会抓到一些关于DNS的信息，显示是standard query A zjzczs-sms-01.zc.zj.corp.chinamobile.com，我们不清楚核心网发送此DNS信息是什么意思；如下图：
三、省网管配合跟踪情况
1月3日省网管数据室协助在GB口挂表跟踪，跟踪到的图铃下载失败时的信息如下：
4．省公司GB口跟踪测试抓包截图
我们观察发现也是下行丢了WTP segmented resunlt(15)、(16)、(17)、(18)，此后下行一直没有能够正确重发，手机也是上行回应WTP Negative Ack，最后因为长时间没有收到完整的数据，导致图铃下载失败。
| 
发表于 2010-8-16 11:52:48
