34G互操作过程中脱网RAU重建fail问题

内部公开▲

34G互操作过程中脱网重建RAU FAIL问题

经验总结

作者：

本文中的所有信息均为本公司内部信息，不得向外传播

内部公开▲

案例简介

【摘要】 端到端信令分析是分析网络问题的最直接方法 【关键词】 MME、终端加密

本案例通过端到端的信令流程分析，根据3Gpp协议，分析终端在处理上存在问题，提交终端修改后正常。

本文中的所有信息均为本公司内部信息，不得向外传播

内部公开▲

1.1 现象描述

TDS/TDL互操作，终端在TDL侧业务连接态情况下脱网重建后，在TDS侧进行RAU流程失败。

1.2 现象分析

脱网重建前，终端尝试TAU请求，因信号原因无法接入导致失败；

脱网重建后，终端发起RAU请求，但因此时可能因为终端状态机异常，导致终端发起RAU时的状态为注册，SGSN回复SMC流程的时候，没有回复；

RNC等待5秒后释放，回复SGSN无线侧校验失败； SGSN收到后回复MME ACK信息为SYSTEM FAIL。 终端信令流程如下：

如图，每次终端在LTE网络脱网重建时，因终端发现自身信号丢失，都会发起TAU请求，但是由于信号条件差，无法正常入网。

SGSN侧信令流程如下：

本文中的所有信息均为本公司内部信息，不得向外传播 1

内部公开▲

可以从截图看出，SGSN给MME发送SGSN CONTEXT REQUEST请求后，MME也回复了SGSN CONTEXT RESPONSE消息，但因没有收到终端侧的完保性性校验信令，SGSN等待超时后，回复MME侧SGSN CONTEXT ACK（SYSTEM FAIL）

MME侧信令流程如下：

本文中的所有信息均为本公司内部信息，不得向外传播 2

内部公开▲

标准信令流程：

红色圈为问题点，终端没有响应SMC PRROCEDURE。

本文中的所有信息均为本公司内部信息，不得向外传播 3

内部公开▲

S-GW MS eNodeB new SGSN old MME P-GW HSS 0. UE changes to UTRAN or GERAN 1. Routeing Area Update Request 2. SGSN Context Request 2. SGSN Context Response 3. Security Functions 4. SGSN Context Acknowledge old SGSN 6. Update PDP Context Request 6. Update PDP Context Response 7. Update Location 8. Cancel Location 8. Cancel Location Ack 9. Insert Subscriber Data 9. Insert Subscriber Data Ack 10. Update Location Ack C2 11. Routeing Area Update Accept C3 12. Routeing Area Update Complete 13. Delete Session Request 13. Delete Session Response 13. S1-AP: S1 Release

经过终端的log分析，没有进行SMC响应的原因是由于完保没有通过，从UE看，完保检查错误，网络使用的IK与UE使用的IK不一致。（这个问题应该由NAS来分析下为什么UE到TD后IK和之前不一致）

本文中的所有信息均为本公司内部信息，不得向外传播 4

内部公开▲

1.3 解决方法及验证

分析 NAS层处理，NAS层网元涉及终端、SGSN以及MME，也就终端、SGSN、MME都需要分析为啥终端侧的IK和网络侧的IK不一致。

而从这两个问题的现象来看，有一个相同的特征：就是终端在RAU FAIL前，都有一次RAU没有走完或者TAU请求没有发出去.

根据协议描述，IK、CK与NAS COUNT有关系，终端与MME都会维护UPLINK NAS COUNT已经DOWNLINK NAS COUNT，每次进行安全校验，NAS COUNT都会更新，怀疑发生问题的时候，终端的UPLINK NAS COUNT变化了，而核心网侧因为收不到消息，UPLINK NAS COUNT没有变化，因为IK就不一样。

按照协议描述，

The NAS sequence number part of the NAS COUNT shall be exchanged between the UE and the MME as part of the NAS signalling. After each new or retransmitted outbound security protected NAS message, the sender shall increase the NAS COUNT number by one. Specifically, on the sender side, the NAS sequence number shall be increased by one, and if the result is zero (due to wrap around), the NAS overflow counter shall also be incremented by one (see subclause 4.4.3.5). The receiving side shall estimate the NAS COUNT used by the sending side. Specifically, if the estimated NAS sequence number wraps around, the NAS overflow counter shall be incremented by one.

终端侧修改NAS COUNT后问题解决

1.4 经验总结

LTE网络在运行过程中，会出现比较异常的问题，问题分析进行端到端的信令分析，通过协议对比查找问题根源，LTE终端前期的还不是很稳定，可能存在各种各样的问题，在后期优化过程中需要注意。

本文中的所有信息均为本公司内部信息，不得向外传播 5

本文来源：https://www.bwwdw.com/article/77yv.html