WHMTSMS.doc

Open informationReport8 (8)Uppgjord (ven faktaansvarig om annan) - Prepared (also subject responsible if other)Nr - No.ETC/YOF/NSG Chen YaoCBC/YOF/NSG-2006:Dokansv/Godk - Doc respons/ApprovedKontr - CheckedDatum - DateRevFileETC/YOF/ Zhang Wen 2006-04-03A关于串短信问题的故障处理报告1 概述武汉移动自从去年11月份以来，陆续接到用户投诉，反映出现串短信故障。经过武汉移动公司运维、客服部门与爱立信公司技术支援部门的长期配合调查，采取了多种预防及排障手段，到目前为止，该问题已经得到解决。本报告将回溯整个问题处理过程，并解答故障原因。2 故障现象据用户反映，串短信故障表现为：用户A发送短信给用户B，然而B在第一时间没有收到，其短信却被用户C收到了。经过查找MSC和短消息中心的话单后进一步发现，故障发生时，用户B和C都处于接收短消息状态，但是B的短信却被C收到，即用户C在当时收到两条短消息。参见下图：ABDC故障发生前SMSSMSABDC故障发生时SMSSMS尽管B用户没有当即收到短信，但从MSC和短消息中心的话单都显示B用户已经接收成功，并且，C用户也应该只收到一条短信。另外，话单还显示，用户B和C都处于同一BSC下。从客服收集的信息还了解到，用户B和C无统一的基站分布规律，而且用户手机终端类型也各不相同。3 故障调查串短信问题主要发生在MSC7、8、9的覆盖区域，因此，查障工作也主要集中在这些MSC，整个工作经历了三个阶段。3.1 第一阶段（2005年11月2006年春节前）按照用户反映的现象，移动公司运维部门做了大量模拟测试，但未能重现故障。爱立信技术人员对MSC做了部分调整工作，包括： 关闭TMSI，改为IMSI寻呼 关闭被叫短消息选择性鉴权，改为每次鉴权 修改SCCP和C7缓存区设置 关闭被叫短信智能缓存排队功能（MSCNF66MTQ） 手工释放MSC处理被叫短信功能块MSMT的吊死进程通过以上修改后，在春节前，投诉明显减少。爱立信技术部门建议做进一步观察。3.2 第二阶段（2006年春节后2006年3月8日）在春节后的一个多月，又陆续收到用户投诉（每天一起以上）。但由于该故障无法手工重现，给问题定位带来极大困难，所以爱立信技术部门建议收集问题高发MSC的所有时段A接口信令，以便在用户投诉后做信令回溯分析。同时，爱立信安排技术人员携带信令仪表到现场收集信令记录。3.3 第三阶段（2006年3月8日2006年3月13日）3月8日，MSC7再次出现串短信故障。用户投诉反映在当天中午12：17用户B 发送短信给用户C，但是户接收到。通过A接口信令回溯，找到了用户B和C当时的收短信记录。在13日将这两个用户的A接口信令、MSC话单、短信中心话单整理完毕。A接口信令记录表明，MSC在收到被叫用户的寻呼响应后（SCCP CR），正确完成了对B和C从鉴权、加密、到短信下发及接收确认的工作。但是，实际上，B没有收到，C却收到两条短消息。为明确串短信故障根源，首先需要做理论分析。下图为根据实际收集信令记录得出的A口和Abis接口的被叫短信接收流程。BTS/MSMSCPaging (SCCP_CL)Immediate assignmentPaging responseConnection Request(SCCP CO)Authentication and CipheringPaging (SCCP_CL)BSCCP DATA(DTAP)CP DATA(DTAP)CP ACK(DTAP)CP ACK(DTAP)CP DATA(DTAP)CP DATA(DTAP)CP ACK(DTAP)CP ACK(DTAP)Clear CommandClear CompleteConnection Confirmed(SCCP CO )1. 在MSC向BSC下发寻呼消息后，BSC将手机上报的寻呼响应消息通过面向连接的SCCP 消息打包在连接请求（Connection Request）中报告给MSC。此消息中包含关键字段LRN（本地参考号）。2. MSC收到连接请求（寻呼响应）消息后，根据前一CR消息的来自BSC的LRN，将其转换为DRN（目的地参考号）向BSC发送连接确认，并提供MSC的LRN。在MSC、BSC的两个LRN作为完成后续所有DTAP会话的唯一识别标志。3. MSC要求手机完成鉴权、加密、IMEI识别4. MSC下发CP-DATA消息，该消息包括SAPI（Service Access Point Identifier）3识别标志，代表短消息；以及短信内容，主叫号码等。5. BSC收到CPDATA后，建立SAPI3链路，这个链路连接SCCP会话（即DTAP消息）和用户做寻呼响应、鉴权、加密等操作使用的SDCCH信令信道。6. 接下来，MSC和用户手机按照标准被叫短信信令流程完成被叫短消息发送7. 释放信令信道结合以上过程和跟踪得到的A接口信令记录，不难看出： MSC对用户B和C的寻呼响应消息都作出正确处理并分配了的不同LRN。 MSC与手机之间完成被叫短消息发送是在正确的LRN/DRN组合上完成。 尽管C用户收到两条短信，而B用户没有收到，但是BSC将用户手机发送的CPACK消息分别打包在两个不同的SCCP会话报告给MSC，因此，MSC认为B用户正常接收了短消息，从而进一步向短消息中心回送短信发送成功消息。至此，基本可以确定由于无线侧原因造成了串短信故障。4 问题深入分析及解决4.1 问题分析根据前面分析，造成故障的可疑点包括： 基站问题 BSC SAPI3链路问题4.1.1 基站问题在检查BSC下所以小区参数后发现，各BSC都存在小区参数BSSWANTED设置与BSC系统参数BSSRLEASE不一致的问题。其中，参数BSSRELEASE代表所有小区CF功能所要求的基站软件版本；BSSWANTED是指BSC与基站做互动操作是使用的软件版本信息。武汉各BSC均设置BSSRELEASE R100，即R10；而BSSWANTED则有R81、R91、R100多个版本。这种版本差异已经在广东省被证明会造成用户被叫短消息接收失败。4.1.2 SAPI 3链路问题从C用户在同一时间接收到两条短消息的事实可以推论出，在发生故障时出现了两个不同的SCCP CO会话（来自MSC的B和C用户的CPDATA）使用了同一个SDCCH信道。因此，即BSC可能建立或使用了错误的SAPI 3链路连接。考虑到BSC在建立SAPI 3链路时需要连接用户做寻呼响应及鉴权加密等操作的SDCCH信道，而这样的链路连接又被怀疑存在问题，所以，可以通过参数调整，使得BSC在建立SAPI 3链路前重新分配一次SDCCH信道，防止错误发生。调整工作在MSC完成，具体参数为SMTASSIGN，调整后的信令流程如下：MSCPaging (SCCP_CL)Immediate assignmentPaging responseConnection Request(SCCP CO)Authentication and CipheringPaging (SCCP_CL)BSCCP DATA(DTAP)CP DATA(DTAP)CP ACK(DTAP)CP ACK(DTAP)CP DATA(DTAP)CP DATA(DTAP)CP ACK(DTAP)CP ACK(DTAP)Clear CommandClear CompleteConnection Confirmed(SCCP CO )Assignment requestAssignment completeBTS/MS参数SMTASSIGN的在MSC被定义为：在被叫短消息发送时，MSC在下发送CPDATA前，是否要求BSC重新分配SDCCH信道。0不发送，1发送。4.2 问题解决通过在3月1