TQOS定时器在Session Progress触发后的应用

优化VoLTE成功率，需要把RF原因导致的QCI5 SIP包收发超时或丢包问题与端到端流程造成的异常分类，以展开RF优化，或定界到问题产生网元解决相关问题，如图8-3所示。

图8-3 VoLTE呼叫失败处理流程

分析VoLTE接通率，在通过测试软件记录空口LOG的同时，需要进行eNodeb、MME、P/SGW、PCRF、IMS多点信令跟踪，端到端进行问题分析。

1.终端侧问题分析

通过测试Log记录空口数据，重点查看测试软件记录的SIP信令、RRC信令、NAS信令及表征空口质量的RSRP、SINR、BLER等指标。分析思路如下：

1）查看主叫终端是否存在TCALL定时器超时的问题。

终端TCALL定时器：当主叫终端发出Invite消息后，TCALL定时器开始记时，当主叫收到IMS下发的100 TRYING消息后，定时器停止。若该定时器超时，则主叫终端发CAN-CEL消息，转CSFB。

在测试软件SIP信令窗口看到主叫发Invite后，一直没有收到下行的100 TRYING消息，10s后启动转CSFB，就会出现上述问题，如图8-4所示。

接下来的分析思路如下：

①首先查看主叫终端发Invite消息后，RRC是否未能正常建立或RRC建立后异常释放。

RRC未能正常建立，看是否存在RPRP过低、上行存在干扰、PRACH功控参数设置不合理等问题。

RRC建立后异常中断，看是否RSRP过低或SINR过低导致上行或下行失步，导致RRC异常释放。如果空口质量无问题，则需要查看eNodeb的虚用户跟踪，来判断RRC异常释放的原因。

②若RRC建立成功且未正常释放，则需要查看P-CSCF侧信令，看主叫终端发送的Invite消息P-CSCF是否收到，P-CSCF是否发100 TRYING，定界问题所在。

图8-4 TCALL定时器超时转CSFB流程

2）查看主被叫终端是否存在TQOS定时器超时的问题。

TQOS定时器在主叫收到183 Session Progress或被叫发送183 Session Progress后记时，当主叫或被叫QCI1承载成功建立后停止记时。若该定时器超时，则主叫终端发CANCEL消息，转CSFB（见图8-5）；被叫终端发580 Precondition Failure消息，终止呼叫（见图8-6）。

图8-5 主叫VoLTE终端TQOS定时器超时异常流程

接下来的分析思路如下：

①首先查看是否存在RRC异常释放。若存在RRC异常释放，需要查看是否存在RSRP和SINR值偏低的空口质量问题，必要时结合虚用户跟踪判断RRC异常释放的原因。

②RRC已建立，但终端未收到QCI1承载建立请求。

图8-6 被叫终端TQOS定时器超时异常流程

●从虚用户跟踪或MME侧跟踪上，可以看到MME根本没有向终端发QCI1承载建立请求。

●RRC已建立，但QCI1承载建立失败。需要查看eNodeb虚用户跟踪和MME侧单用户跟踪来判断QCI1承载建立失败的原因。

3）查看终端在QCI1正常建立后，是否存在RRC异常释放，导致SIP信令中断，IMS相关流程定时器超时导致呼叫建立失败。

需要查看是否存在RSRP和SINR值偏低的空口质量问题，导致RRC异常释放，必要时结合虚用户跟踪判断RRC异常释放的原因。这里要明确是RRC异常释放导致SIP信令中断还是SIP信令中断，不活动定时器超时导致RRC释放。对于RRC异常释放导致SIP信令中断场景，避免RRC异常释放在前，IMS发的错误码在后（或者终端中断时间过长根本收不到IMS发的错误码）。而SIP信令中断，不活动定时器超时导致RRC释放，则必是终端或IMS发CANCEL或错误码在前，不活动定时器超时后，RRC才释放。

4）终端QCI1建立后又被EPC释放。

终端QCI1建立后又被释放可能是由本侧的呼叫异常导致的，也可能是对端的呼叫异常导致的。通过查看测试软件或P-CSCF跟踪的SIP信令，如果是本端先发CANCEL、580Precondition Failure，或先收到IMS发的错误码，则认为呼叫建立失败是本端引起的，否则呼叫建立失败可能是由对端引起的。

图8-7所示为P-CSCF信令跟踪结果，呼叫流程中最先出现的500错误消息中的CALL ID是被叫的，可以判断呼叫建立失败是被叫侧SIP流程出现异常。

5）被叫不响应寻呼。

下面的案例为典型被叫不响应寻呼导致主叫出现的未接通。16：14：26，主叫终端（17820500390）发Invite，但实际上被叫终端从16：14：12～16：14：15（17820500390）3min内没有建立RRC连接。16：14：28.156，IMS将Invite转给被叫后，无法得到被叫回应。半分钟后，16：14：58.237，IMS向主叫发499 BAD REQUEST消息，呼叫建立失败，如图8-8所示。

图8-7 500错误消息跟踪

图8-8 被叫不响应寻呼失败现象

这个场景产生的根本原因是IMS将Invite转给被叫后，无法得到被叫回应，IMS超时释放呼叫。正常场景主叫侧应放音，但目前放音流程尚未做好，IMS超时通过发送499错误码释放呼叫。

6）终端问题或异常操作导致未接通。

①主叫终端异常终止呼叫。如图8-9所示，终端在发送Invite消息后马上发CANCEL，并且连续多次，明显是终端异常导致。

图8-9 主叫终端异常终止信令流程

注意，该问题要和主叫TQOS定时器超时现象区分开。主叫TQOS定时器超时一定是183 Session Progress后，QCI承载未建立，主叫发CANCEL消息转CSFB。

②呼叫未建立前，被叫终端终止呼叫。如图8-10所示，MS2是主叫，MS1是被叫。被叫在未摘机前就主动挂机，上报603 Decline消息。

图8-10 被叫终端终止呼叫信令流程

③主叫拨打被叫，被叫正在响应其他呼叫。如图8-11所示，MS2是主叫，MS1是被叫。07：58：11.092，MS1呼叫MS2，但实际上MS2正在拨打另外一个电话。MS2收到IMS发送的Invite消息，发486 Busy Here消息。

图8-11 被叫正在响应其他呼叫信令流程

2.eNodeb侧问题分析

IMS信令流程对eNodeb是透传的，一般通过eNodeb侧的虚用户跟踪来判断RRC和QCI1承载、QCI5承载未建立或建立失败的原因。

虚用户跟踪信令可用业务数据回顾工具、OMSATR或FMA来打开。由于前台测试时间和eNodeb系统时间可能不一致，因此首先需要做信令时间点对齐工作。

通过RRC Connection Setup Complte的NAS消息来做路测软件上信令和eNodeb上虚用户跟踪的信令对齐。

eNodeb虚用户跟踪RRC Connection Setup Complte信令，如图8-12所示。

路测数据L3上RRC Connection Setup Complte信令，如图8-13。

可以看到虚用户跟踪和路测层3上RRC Connection Setup Complte信令的NAS消息码流都是C7055290，这样就可以做到虚用户跟踪和路测数据的信令时间对齐。

1）判断终端发的RRC信令，eNodeb有无正常接收。

图8-12 RRC Connection Setup Complte后台信令解析

图8-13 RRC Connection Setup Complte测试信令解析

2）通过虚用户跟踪判断RRC释放原因。

在eNodeb发RRC Connection Release消息前，会向MME发送UE Context REL_REQ消息，其中带有RRC释放的原因，如图8-14所示。RRC释放的原因为User INActvity（UE不活动定时器超时）。

3）通过虚用户跟踪查看QCI1、QCI5承载是否正常建立。

如果在QCI1承载建立时，eNodeb已经收到MME发送的ERAB SETUP REQUEST，但终端侧没有收到激活专用EPS承载上下文请求消息，则说明QCI1承载未建立，可能为空口原因。如果eNodeb根本就没有收到MME发送的ERAB SETUP REQUEST，则说明QCI1未建立和MME未发承载建立请求相关，和空口关系不大。

图8-15所示为起呼RRC建立后MME没有发QCI1承载请求。

图8-14 RRC释放原因信令解析

(www.xing528.com)

图8-15 不下发QCI1承载请求消息信令

图8-16所示为MME发送QCI1承载请求的信令，消息内容中可以看到ERAB ID为7，QCI为QCI1。

3.MME侧问题分析

MME侧信令跟踪重点关注以下两个流程：

1）HSS和被叫方MME的IDR/IDA（流程14、流程15）是否正常。HSS应向被叫方MME发送Insert Subscriber Data Request（IDR）消息，MME应回Insert Subscriber Data Answer消息。

图8-16 QCI1承载请求消息解析

2）QCI1/QCI5承载建立是否正常，其中包括MME和P/SGW、eNodeB和终端的交互。P/SGW向MME发送Create Bearer Request消息，MME向P/SGW回Create Bearer Response消息。

IDR/IDA所携带消息关键信源如图8-17所示。图8-18所示为Create Bearer Request信令详细内容，LABEL-QCI信元显示是请求哪种QCI的承载。

图8-17 IDR/IDA所携带消息关键信源

MME向eNodeb发送E-RAB Setup Request消息，eNodeB向MME回E-RAB Setup Re-sponse消息。

图8-18 Create Bearer Request信令解析

MME向UE发送Activate Dedicated EPS Bearer Context Request消息，UE向MME回Acti-vate Dedicated EPS Bearer Context Accept消息。

图8-19所示为一个通话正常的流程，HSS首先和被叫方MME进行IDR/IDA流程，然后P/SGW向MME发送Create Bearer Request消息，启动QCI1承载建立流程。

图8-19 通话正常流程

图8-20所示为一个通话异常的场景，MME和HSS进行IDR/IDA流程（流程14、15）交互后，P/SGW未向MME发送Create Bearer Request消息，导致QCI1承载未建立。

图8-20 通话异常信令流程

4.P/SGW侧问题分析

P/SGW信令跟踪应重点关注以下流程是否异常：

1）与PCRF的RAR/RAA流程（流程24、25）是否正常。该流程异常会导致QCI1承载无法建立。

PCRF根据认证/授权请求消息AAR中携带的媒体类型和媒体描述信息做策略决策，提供授权的QoS，并通过重新认证/授权请求消息RAR将QoS（QCI/ARP/GBR/MBR）和PCC规则发送至P-GW；P-GW_B收到重新认证/授权请求消息RAR，上报重新认证/授权应答消息RAA响应给PCRF_B。

RAR消息的关键信元如图8-21所示。

图8-21 RAR消息关键信元

2）和MME交互的CB Request和CB Response流程是否存在异常（流程27、30）。

在P/SGW与PCRF完成RAR/RAA流程（流程24、25）交互后，P/SGW向MME发送Create Bearer Request消息要求建立QCI1承载，MME向P/SGW回Create Bearer Response消息，表示QCI1承载已完成。

5.PCRF侧问题分析

PCRF网元信令交互重点关注以下两点：

1）和PGW网元的RAR/RAA流程（流程24、25）是否正常。PCRF根据认证/授权请求消息AAR中携带的媒体类型和媒体描述信息做策略决策，提供授权的QoS，并通过重新认证/授权请求消息RAR将QoS（QCI/ARP/GBR/MBR）和PCC规则发送至P-GW_B；P-GW_B收到重新认证/授权请求消息RAR，上报重新认证/授权应答消息RAA响应给PCRF_B。RAR/RAA流程流程异常，会导致QCI1承载无法正常建立。

2）和P-CSCF的AAR/AAA流程（流程23、26）是否正常。P-CSCF收到被叫侧返回的183（SDP）后，下发认证/授权请求消息AAR给PCRF_B开始建立专有承载。AAR包括用户的信令地址、媒体带宽等信息；PCRF根据P-GW返回的重新认证/授权应答消息RAA，向P-CSCF发送认证/授权应答消息AAA响应授权请求结果。

6.P-CSCF（SBC）网元侧问题分析

获取到P-CSCF网元信令后，首先要进行信令过滤。在P-CSCF信令回顾工具里面，点“过滤”菜单，在弹出的对话框中单击“新建”或“修改”按钮，设置过滤条件，如图8-22所示。

过滤条件设置方式如图8-22所示，即在消息接口类型中选择字符串包含SIP和DIAM的消息。将P-CSCF侧SIP信令和终端信令做对比时，需要做信令时间点对齐。方法很简单，SIP信令中都有CALL ID信元，对于主叫侧或被叫侧来说，每次呼叫的CALL ID都是基本唯一的，相同CALL ID的SIP信令属于同一次呼叫，可通过CALL ID来实现信令时间对齐。

拿到P-CSCF侧单用户信令，主要从以下两方面进行分析：

图8-22 P-CSCF信令过滤方法

1）查看P-CSCF与PCRF的AAR/AAA流程是否异常。

P-CSCF与PCRF的AAR/AAA流程用于QCI1承载的建立或修改。P-CSCF将用户的信令地址、媒体带宽等信息通过认证/授权请求消息AAR发送给PCRF，通知PCRF建立专有承载。从AAR消息中的内容可以看到终端的IP地址，可以据此判断该AAR消息是用于主叫的QCI1承载建立或修改，还是被叫侧的，如图8-23所示。

图8-23 AAR消息解析

PCRF_B向P-CSCF_B发送认证/授权应答消息AAA响应。从消息内容中可以看到流程是否成功，如图8-24所示。

2）P-CSCF侧信令和路测软件SIP信令做对比，判断SIP流程异常的原因。

①观察终端发送的SIP信令，P-CSCF是否正常收到，或P-CSCF发出的信令，终端有无正常收到，通话SIP信令流程在哪一步存在信令缺失或异常。

②查看IMS是否发送错误码，导致了呼叫建立失败，根据错误码来判断呼叫建立失败的原因。

一些常见错误码列举如下。

●Request Terminated：IMS在发现异常（出现CANCEL消息或其他错误码）后用487Request Terminated终止呼叫。

●481Call/Transaction Does Not Exist：IMS收到UE发送消息后，发现呼叫已不存在，发

图8-24 AAA响应消息解析

此错误码

●480Temporarily Unavailable：IMS长期得不到UE响应，相关定时器超时发此错误码。

●486 BUSY HERE：成功联系到被叫方的终端系统，但是被叫方当前在这个终端系统上不能接听这个电话（如正在进行其他呼叫业务），发此错误码。

●500 Server Internal Error：服务器遇到了未知的情况，并且不能继续处理请求，一般为IMS内部问题或和其他网元交互异常。

●503 Service Unavailable：服务不可用，一般为IMS内部问题或和其他网元交互异常。

●603Decline：寻呼到被叫后，被叫在摘机前终止此次呼叫，一般发此错误码。

IMS侧错误码示列如图8-25所示。状态码解释见表8-2。

图8-25 IMS侧错误码示例

表8-2 状态码解释

（续）

（续）