VOLTE掉话分析-电子围栏系统导致掉话
一、问题背景
呼分公司在9月4日对呼和浩特市区二环内的主要路段进行了VOLTE业务拉网测试。统计分析指标时，按照区公司下发的VOLTE业务能力测试规范统计指标时，主被叫共发现5处掉话，问题点记录如下：
| 编号 |
MO/MT |
ID |
Offset |
Index |
Report Time |
MS Time |
Event |
Event Information |
| 1 |
MO |
33679 |
13733 |
8939015 |
22:53:36:366 |
22:53:24:210 |
VoLTECallDropped |
VoLTE Call Dropped |
| 2 |
MO |
41696 |
16937 |
10902249 |
23:46:06:089 |
23:45:53:976 |
VoLTECallDropped |
VoLTE Call Dropped |
| 3 |
MT |
21091 |
8087 |
5419709 |
16:47:44:192 |
16:47:50:670 |
VoLTECallDropped |
VoLTE Call Dropped |
| 4 |
MT |
33707 |
13744 |
8941116 |
22:53:47:087 |
22:53:53:635 |
VoLTECallDropped |
VoLTE Call Dropped |
此外按照规范要求，主叫主动挂机时，主叫未收到SIP_BYE-OK或被叫未发送SIP_BYE-OK，均计算一次掉话。按条件筛选出主叫有一次通话未收到SIP_BYE-OK消息，消息点记录如下：
| 编号 |
IndexID |
Time |
Channel |
Message |
Info |
| 5 |
12595192 |
2017-09-05 01:49:43:741 |
VoLTE |
IMS Message |
INVITE 180 Ringing |
二、理论介绍
Ú 掉话率定义：（主叫掉话次数+被叫掉话次数）/（成功建立呼叫次数×2）；
Ú 掉话：通话保持期间内，主被叫的空口RRC连接释放、EPS承载释放等均属于掉话；
Ú 呼叫建立成功：从主叫终端发起SIP INVITE消息到接收到网络侧下发的SIP 200 OK消息。
Ú 通话保持期间：主叫收到网络侧下发的SIP 200 OK消息到主叫收到网络侧下发的SIP BYE 200 OK消息；被叫下发SIP 200 OK消息到被叫下发SIP BYE 200 OK消息。
下图为正常呼叫流程图：
三、参数设置
本次测试参数设置如下：
| 项目 |
值 |
| 主叫 |
MS1 |
| 被叫 |
MS2 |
| 呼叫建立等待时延（s） |
15 |
| 呼叫保持时间（s） |
120 |
| 挂断发起方 |
MS1 |
| 呼叫间隔（s） |
10 |
四、问题分析
Ø 问题点1分析
按逻辑时间在MS1信令中查找该问题点，是一条RRC连接释放消息（图1）。
向上查找，在22:53:13:452时刻发现DEACTIVATEEPS REQ（EPS承载去激活请求）消息，并得到了网络的响应（DEACTIVATE EPS ACC）。继续向上查找，发现在22:53:13:392时刻MS1收到了BYE 500 Service Internal消息（图2）。
查看消息体（图3），该消息为网络下发给UE的（Network to UE）,告警正文中显示无法收到对端（MS2）的响应（No Response From Peer）。
进一步查看MS2信令（图4），与MS1上传的BYE 0Request相对应的为RRC Connection Setup Complete消息,同时发现MS2在该时间段内连续发送了3次TAU请求，在第一次TAU之前的22:52:49:657时刻还收到了RRC重建被拒绝的消息（RRC Connetion ReestablishmentReject）,前两次TAU请求（TAU REQ）后，均完成了RRC连接（RRCConnetion Setup Complete），但没有下一步流程，也无网络响应，TAU流程异常。
而第三次TAU流程正常（图5），并收到网络响应（TAU ACC）
查看当时MS2服务小区状态（图6），发现第一次发起TAU所接入的主服务小区站号显示为242_111，TAC码为23882，非电信4G站点。
查询采样点（图7），MS2在22:52:37:505就已经接入到242_111的站点，接入点位置在北垣街与兴安北路十字路口西侧，退出点位置在路口东侧。也就是说MS2在MS1发送BYE 0Request消息之前便接入到242_111站点。经调查，该接入站点为公安部门在路口设置的“电子围栏”，频段与L1800相同，本次问题原因为MS2接入到“电子围栏”，主叫在发起BYE 0 Request消息后未取得MS2的应答而导致的掉话。
Ø 问题点4分析
这里把问题点4放到该处分析其原因为，问题点4与问题点1是在同一通话过程中发生的掉话（图8），MS2的RRC连接释放是在第三次TAU成功之后，即退出“电子围栏”正常接入到电信站点后，故被系统统计为一次被叫掉话，原因同问题点1，这里不再做分析。
Ø 问题点2分析
信令中查询问题点（图9），发现在RRC连接释放消息之上连续出现了3条BYE 0 Request，均未得到网络回应。在23:45:36:592时刻可以看到VoLTE会话进程结束（VoLTE Session End）的消息，查看消息体，结束原因代码为2即RTP不活动定时器到时（EndCause=2（RTP Inactivity））,该定时器作用是当RTP包不能正常收发，持续10秒后，RTPInactivity定时器将作用使会话中断。正常挂断时,会话结束原因代码应为0（图10）,即主叫发起的会话终止（EndCause=0（MO Initiated））。
分析RTP包不能正常收发，有可能是无线环境差或BLER高而导致的，按采样点查询该时间段服务小区状态及BLER（图11），该时间段主服务小区RSRP在-75dBm左右，SINR在10左右，无线环境良好，但下行的BLER在问题点前后的时间段内异常高，时间从23:48:18持续到23:45:56，对应MS1信令，从23:45:05:453到23:45:36:225，之后恢复正常。该时间段内BLER最高时达到100%，而该时间段正好是在主被叫通话建立期间，从BLER异常开始23:45:05:453到会话进程结束23:45:24:454，持续时间19秒。
网管提取当时该站点BLER指标统计，由于网管提取最小粒度为15分钟，按15分钟粒度查询，服务小区在问题时间段内的BLER值在正常范围之内，查询结果见下表。
| 序号 |
开始时间 |
结束时间 |
小区名称 |
[FDD]小区上行BLER |
[FDD]小区下行BLER |
| 1 |
2017/9/4 23:15 |
2017/9/4 23:30 |
HHHT-玉泉-铸锻厂800M-ZFTB-921738-18 |
5.41% |
10.02% |
| 2 |
2017/9/4 23:30 |
2017/9/4 23:45 |
HHHT-玉泉-铸锻厂800M-ZFTB-921738-18 |
5.35% |
10.42% |
| 3 |
2017/9/4 23:45 |
2017/9/5 0:00 |
HHHT-玉泉-铸锻厂800M-ZFTB-921738-18 |
5.25% |
10.10% |
BLER统计的是物理层的丢包率，由于VOLTE语音是按照RTP/RTCP协议以数据包的形式来传输的，从VOLTE协议栈可以看出（图12），所以必然也需要在物理层共享信道上传输，物理层的丢包率高也必然会影响RTP包的正常收发，本次掉话原因，就是因为BLER异常而引起用户面RTP数据包不能正常收发，触发RTP Inactivity定时器，中断通话，从而引起掉话，而BLER异常发生在极短的时间内，引发原因已无从查找。
Ø 问题点3分析
问题点3与问题点1相同，MS2与MS1建立会话后，在乌兰察布东街与展览馆东路十字路口东侧500米左右位置（图13），时间16:47:43:752，又一次接入到小区ID为0_0，TAC为3694的电子围栏系统，主叫会话正常结束（VoLTE Session End消息体中的EndCause=0即表示主叫结束通话，并收到了网络回复的BYE 200 OK）。
之后MS2在电子围栏系统中发起RRC重建请求被拒（图14），之后又发起TAU请求，也被拒绝，随即MS2的RRC连接被释放了，从而引起掉话。
Ø 问题点5分析
按时间查找问题点（图15），该问题点被叫整个会话流程正常，主叫流程仅缺少网络端下发的BYE 200 OK消息，查看会话结束原因，原因值为0是由主叫正常挂断的，从INVITE 180 Ringing（01:49:43:741）到VoLTE Session End（01:51:45:707），通话保持时间正常（参数设置为120秒），但问题点所处位置的无线环境较差，服务小区RSRP为-101dBm，SINR为3.7，该处还存在导频污染和模三干扰，分析该次通话为正常通话，因无线环境差导致MS1未接收到网络下发的BYE 200 OK。
五、应用总结
VOLTE掉话的原因还有很多，本次测试遇到的掉话原因相对而言较为简单，本案例仅希望能为后续的VOLTE优化和故障处理提供一些思路，面对电信VOLTE功能开通带来的挑战，对未知的、新的网络问题还有待进一步的探索和研究。