VoLTE接通时延长端到端分析

1： 问题分析

1. 1  问题信令分析

在某次空闲态拉网中，呼叫建立时延达到10.961s，如下图：

图1 主叫起呼

图2 主叫完成呼叫

根据上述信令流程可以看到，主叫从发出INVITE 到收到INVITE183需要9.818s，因此断定本次呼叫建立时延长是因为寻呼时延长，因此逐段排查被叫的INVIE接收过程。

主叫P-SBC信令跟踪如下：

图3 主叫P-SBC信令

UE在9:59:58.294产生INVITE消息，SBC在9:59:59:879收到INVITE消息，考虑到UE是在空闲态起呼，该时延属于正常范围。在主叫P-SBC完成与S-CSCF交互之后，于10:00:00:051向被叫P-SBC发送INVITE消息，之后由于直到10:09:059收到被叫100 trying，产生5次INVITE重发。从主叫P-SBC可以看出，本次时延主要是被叫侧发100 trying时延长导致。

被叫侧的P-SBC信令如下： 

图4 被叫P-SBC信令

从被叫的P-SBC看到，被叫P-SBC于10:00:00.353收到主叫的INVITE消息，且在10:00:00.353向PGW发送INVITE数据包，但是直到10:00:09:069收到UE的100 trying，时延也在正常范围，于是开始排查被叫MME和UE的交互环节。

被叫MME log如下：

图5 被叫MME信令

从被叫的MME log 可以看出，MME与10：00:00收到PGW下发的downlinkdatanotification消息（网元时间不同步，导致MME时收到数据通知时间在P-SBC下发之前），并于10:00:00按照TAC下发paging消息,如下图所示：

图6 被叫MME paging

M-TMSI转换成二机制后为11100010000010001100011011011110。从MME log可以看到，MME于10:00:08才收到UE的Service Request消息，因此推断本次呼叫时延长的问题是无线侧存在寻呼丢失的问题。

被叫UE在问题点附近的信令如下图：

图7 被叫UE问题时刻信令

从上述信令可以看到9：59：36:263回到空闲态开始，UE读取了5次SIB1，第1次收到完整SIB之后才读取paging消息，第2次、第4次读取了完整的系统消息，未能收到paging，第3次、第5次只是读取SIB1，但是能收到paging，五次SIB1的解析如下：

图8 被叫UE问题时刻第1次SIB1

图9 被叫UE问题时刻第2次SIB1

图10 被叫UE问题时刻第3次SIB1

图11 被叫UE问题时刻第4次SIB1

图12 被叫UE问题时刻第5次SIB1

从四次SIB1消息来看，UE经历了4次重选，所驻留的小区为426642-2、426642-3、426642-1、426642-5、426585-3，，除最后426585-3外，其他4个小区都存在SINR较差的问题。因此怀疑寻呼丢失的一个原因是UE所处的无线环境较差。

此外，两次SIB2的寻呼配置参数都是如下配置：

图12 被叫UE问题时刻第1次SIB1

从PCCH的参数配置来看，128个RF即1.28s里，终端有一次PO，但重选到426642-3、426642-5两个小区时Systeminfovaluetag发生了变化，终端都需要去读取完整的SIB，此时从log上看终端都是只有读取SIB消息而无paging消息。另外，426642-2也是读取完所有的SIB消息后才开始读取paging消息，而在426642-1、426585-3只需读取SBI1时，则可以正常接收paging消息。根据上述现象，怀疑HTC m8t终端在检测到Systeminfovaluetag发生变化需要读取完所有SIB之后才能读寻呼消息，导致错过一个周期里面的PO。

通过以上分析，可以确定本次呼叫时延长是因为在无线侧存在寻呼丢失的问题，但是需要确认SINR差还是终端问题造成的寻呼丢失。

1.2  问题确认

为了确定是SINR差还是终端接收寻呼截止问题导致寻呼丢失，通过修改双载波室分的重选参数构建一个SINR好但是频繁重选的场景，而且为了确定非测试软件问题，测试改成CDS+HTC m8进行（问题信令是鼎立+HTC m8），同时安排mate7+probe进行对比测试。

CDS+HTC测试结果如下：

主叫信令：

图13  主叫UE验证信令（HTC m8）

图14  被叫UE验证信令（HTC m8）

从验证结果看，即使HTC终端在SINR很好的条件下，主叫时延也会达到7.427s，主叫从发出INVITE到收到183需要6.187s。对于被叫如果Systeminformationvaluelag发生变化，被叫也会要读取系统消息完成后才会去接收寻呼消息导。另外，由于无线环境较好，UE只需0.258s就读完所有系统消息，因此本次寻呼响应时间相对原问题有所缩短。

华为mate7+probe测试结果如下：

图15 主叫UE验证信令（mate7）

图16 被叫UE验证信令重选前（mate7）

图17 被叫UE验证信令重选后（mate7）

从mate7的验证结果来看，主叫的呼叫时延是3.331s，被叫侧重选完后读取SIB1，即使systeminfomationvaluelag发生变化，也无需读取系统消息也能马上读取paging消息。

根据对比测试来看，问题的呼叫建立时延长主要是由于HTC在systeminfomationvaluelag发生变化时，需要读取完SIB1的系统消息列表里的所有SIB才能读取paging消息引起寻呼丢失。此外，问题点所处的无线环境较差，UE需要较长的时间解读所有系统消息加剧该问题。

2：结论

根据3GPP的36.331的5.2.1.3节的如下描述：

When the network changes (some of the) system information, it first notifies the UEs about this change, i.e. this may be done throughout a modification period. In the next modification period, the network transmits the updated systeminformation. These general principles are illustrated in figure 5.2.1.3-1, in which different colours indicate different system information. Upon receiving a change notification, the UE acquires the new system information immediately from the start of the next modification period. The UE applies the previously acquired system information until the UE acquires the new system information.

从上述描述可知，当UE知道系统消息有变化时，直到接收完下一个系统消息，否则UE继续沿用旧的系统消息的参数。 根据上述描述，当UE侦测到System infomation value lag有变化时，应该用旧的系统消息继续接收寻呼消息，而不是等所有系统消息接收完再接收寻呼消息。从这点上看，mate7符合36.331的要求，而HTC m8t不符合36.331协议的要求。

3. 后记

对笔者而言，该案例值得一提的地方能把寻呼丢失和手机读取系统消息的机制联系起来，而不是简单的归结于无线环境不好，并且之后能构建合适的验证环境正确其准确性。无线优化人员若要具备端到端分析能力，必须熟练掌握36304、36331、36413、36423、Gm口信令和流程并能应用到实际工作