PS域2╱3G双向切换失败的解决案例.doc

PS域2/3G双向切换失败的解决案例报告日期：2008.12.18 报告人： 马于飞 唐少强一测试现象在T网开始数据业务（用迅雷下载数据），达到门限后从T网切到G网，数据业务中断（下载无流量）；同样，在G网开始数据业务，达到门限后从G网切到T网，数据业务中断。二原因分析1. TD-SCDMA到GSM的切换 以下是在Outum上抓到的UU口信令流程，如下图所示：TD-SCDMA到GSM的UU口信令将重要事件提炼出来，实际上总体的过程如下图所示：1. UE首先上报测量报告，向网络报告测量情况，由系统决定是否需要进行系统间切换。2. UE收到系统发的Cell Change Order From UTRAN命令，要求UE进行系统间切换，从TD-SCDMA网络切到GSM的网络。3. UE向新系统（MSC）请求位置区更新，并告诉系统自己所在的旧的位置以及自己的能力和标识。4. G网对UE进行一致性检测以及认证。5. G网给UE分配一个新的TMSI号。6. G网告诉UE位置区更新成功，并告诉其新的位置区号。7. UE向系统（新SGSN）请求路由区更新，并告诉系统自己所在的旧的路由区以及自己的标识。8. 8s左右系统没有反应，UE再发一次路由区更新请求。9. 5s左右系统向UE回复路由区更新失败消息，失败的原因为“MS identity cannot be derived by the network 网络不能得到UE的身份”。10. UE马上向系统发送Attach请求，此时UE已经中断了业务，要重新与网络建立GPRS附着。2. GSM到TD-SCDMA的切换 以下是在Outum上抓到的UU口信令流程，如下图所示：GSM到TD-SCDMA的UU口信令将重要事件提炼上来，实际上总体的过程如下图所示：这一流程与之前描述的从TD-SCDMA到GSM的信令流程类似，但最后显示“路由区更新成功。其实，最后成功的这次路由更新并不是由于跨系统切换而引起的，只是TD网络内部的更新而已，而实际上第一条的路由区更新请求才是由跨系统切换所引起的，从信令上来看它是失败了。这个从对两条路由区更新请求的解码中可以看出，按照TD厂家设计，由跨系统切换所引起的路由区更新请求中会携带TD网络的版本号，否则没有，如下图所示：第一条的路由区更新第二条的路由区更新3. 路由区更新失败的原因分析 由上可见，UE在PS域的切换中数据业务的中断，是由于路由区更新失败而造成的，那么路由器更新失败的原因又是什么呢？下面以从T网到G网为例来进一步的分析，首先看看在3GPP规范中PS域3G向2G切换的正常流程，如下图所示：上图是3GPP协议中3G到2G的路由更新流程图，具体解释如下：1. MS（MS处于Idle状态）或UTRAN（MS处于Cell-DCH状态或者Cell-FACH状态）决定发起分组域的系统间切换。2. MS向新2-SGSN发起路由区更新请求（包括旧的RAI、旧的P-TMSI签名、MS的网络能力等信息），BSS在将消息送到SGSN之前将收到消息中加入新小区的CGI（包括LAC和RAC）。3. 新2-SGSN向老3-SGSN发送SGSN Context Request消息获取MS的MM和PDP上下文。老3-SGSN对MS的P-TMSI签名进行验证，如果SGSN不认识该MS，则会回应一个适当的错误原因。4. 如果切换之前MS处在CONNECTED状态（即正在进行数据业务时），老3-SGSN向SRNS发送SRNS Context Request消息，SRNS收到此消息后停止向MS发送数据PDU，并将数据进行缓存，同时向老3-SGSN返回SRNS Context Response。5. 老3-SGSN向新2-SGSN发送SGSN Context Response，其中包含MS的MM和PDP上下文。6. 若在第3步中老3-SGSN通过P-TMSI检验出MS无效，则在这步执行安全流程，通过HLR来检验MS是否有效；若第3步已经检验出MS有效，那么这一步不被执行。7. 新2-SGSN向老3-SGSN发送SGSN Context Acknowledge消息，通知老3-SGSN现在2-SGSN可以接受激活的PDP contexts的相关数据PDU。8. 如果手机处于CONNECTED状态，则老3-SGSN向SRNS发送数据转发命令（Data Forward Command）。SRNS在收到该命令后启动数据转发定时器，SRNS发送已缓存的数据PDU到老3-SGSN。9. 老3-SGSN将GTP PDU按隧道方式传送给新2-SGSN，GTP头中的序列号不改变。10. 新2-SGSN向GGSN发送Update PDP Context Request。GGSN更新PDP context后返回应答Update PDP Context Response。11. 新2-SGSN发送Update GPRS Location消息通知HLR修改MS所在的SGSN号和地址信息。12. HLR发送Cancel Location通知老3-SGSN删除该MS的MM和PDP Context信息。删除后，老3-SGSN以Cancel Location Ack消息应答。13. 如果MS处于CONNECTED时，老3-SGSN将向SRNC发出Iu Release Command消息，在第8步的数据转发定时器超时后SRNS通过Iu Release Complete消息回应。14. HLR发送Insert Subscriber Data消息给新2-SGSN，2-SGSN将用户签约数据插入MM上下文和PDP上下文并且回应Insert Subscriber Data Ack消息。15. HLR确认修改完成，发送Update GPRS Location ACK消息到新2-SGSN。16-18&21. 如果路由更新请求的类型是RA/LA时才被执行。一般RA与LA是分开独立进行的。19. 新2-SGSN验证MS在新路由区的合法性，如果所有检查成功，新2-SGSN给用户组建MM和PDP上下文，并向MS回应一个Routing Area Update Accept消息（包括给MS分配的新P-TMSI签名）。20. MS通过发送Routing Area Update Complete消息确认新分配的P-TMSI，并将在路由区更新发起之前所有成功发送给MS的PDU数发给新2-SGSN，从而告诉新2-SGSN要向MS Forward哪些PDU数据。22. 新2-SGSN和BSS执行BSS Packet Flow Context procedure。以上就是3GPP协议中3G到2G路由更新的详细流程，可见路由区更新失败的原因有可能是以上前19步中的任一一步出现问题，下面将一步一步的进行分析：1. 首先在2-SGSN终端上没有看到“路由器更新请求”的消息，但从UU口来看，手机确实是发送了路由器更新请求。实际上2-SGSN的终端只能记录一些简单的信令，并没有信令跟踪仪的功能。所以，这个现象并不能完全说明2-SGSN没收到“路由器更新请求”的消息。2. 假设上一步2-SGSN有收到“路由器更新请求”的消息，那么看看接下来新2-SGSN 是否有向老3-SGSN发送SGSN Context Request消息，并且老3-SGSN是否有收到。结果发现在新2-SGSN终端上没有发送此条消息的记录，同上一步原因，这个现象并无太大参考性。然而同时，在老3-SGSN的终端上也没有收到此条消息的记录，由于老3-SGSN的终端能够显示详细的信令，所以这个现象就基本可以将问题定位在2-SGSN/3-SGSN间SGSN Context Request消息的传递上了。另外，从路由区更新失败的原因 “MS identity cannot be derived by the network”来看，最有可能的也是新2-SGSN 没有从老3-SGSN上拿到 “SGSN Context”。进一步想，有以下3种可能： 新2-SGSN根本就没有向老3-SGSN发SGSN Context Request消息。 新2-SGSN向老3-SGSN发了SGSN Context Request消息，但由于2-SGSN/3-SGSN间的连路不通，消息无法到达老3-SGSN。 新2-SGSN向老3-SGSN发了SGSN Context Request消息，老3-SGSN也收到了此消息，但由于两个系统间的格式不一样，导致老3-SGSN解不出此消息。对于上面的第三种可能，从之前的分析基本可以排除（因为在3-SGSN终端上没看见接收了“SGSN Context Request”的记录）；对于上面第一种可能，由于需要另外在Gb口挂表查看，暂时挂起，假设2-SGSN已经