[下载]信令分析PS域2/3G双向切换失败的解释详细

teleinfor

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已经向3-SGSN发了SGSN Context Request消息；对于第二种可能，我们需要检查2-SGSN/3-SGSN间的配置，结果发现果然2-SGSN/3-SGSN间的防火墙的配置有问题。