1、PS域2/3G雙向切換失敗的解決案例報告日期：報告人：蘇燕 馬于飛 孔令興一測試現象在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命令，要求U

2、E進行系統間切換，從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 網絡不能得到

3、UE的身份”。10. UE馬上向系統發送Attach請求，此時UE已經中斷了業務，要重新與網絡建立GPRS附著。2. GSM到TD-SCDMA的切換 以下是在Outum上抓到的UU口信令流程，如下圖所示：GSM到TD-SCDMA的UU口信令將重要事件提煉上來，實際上總體的過程如下圖所示：這一流程與之前描述的從TD-SCDMA到GSM的信令流程類似，但最后顯示“路由區更新成功。其實，最后成功的這次路由更新并不是由于跨系統切換而引起的，只是TD網絡內部的更新而已，而實際上第一條的路由區更新請求才是由跨系統切換所引起的，從信令上來看它是失敗了。這個從對兩條路由區更新請求的解碼中可以看出，按照TD廠家

4、設計，由跨系統切換所引起的路由區更新請求中會攜帶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發起路

5、由區更新請求（包括舊的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-

6、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發送數據轉

7、發命令（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-

8、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 Locat

9、ion 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

10、數據。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 是

11、否有向老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上拿到

12、“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 Con