经典案例VoLTE掉话探究.docx
《经典案例VoLTE掉话探究.docx》由会员分享，可在线阅读，更多相关《经典案例VoLTE掉话探究.docx（23页珍藏版）》请在冰豆网上搜索。
经典案例VoLTE掉话探究
VoLTE掉话探究
VoLTE掉话探究
1VoLTE关键知识点1
1.1VOLTE概述和基本特征1
1.2终端开机的IMS注册过程3
1.1.1IMS注册流程图5
1.3VoLTE呼叫VoLTE的信令呼叫流程6
1.3.1呼叫流程图7
1.3.2连接态与idle态起呼信令7
1.3.3主叫流程图8
1.3.4被叫流程图9
1.3.5SIP会话流程11
2VoLTE路测与分析12
2.1VoLTE主要指标12
2.2分析方法及问题分类13
2.3信令流程解析14
3各类问题优化分析16
3.1掉话问题分析思路16
3.2未接通问题分析思路17
4案例分析18
案例一：
模三干扰导致掉话问题18
案例二：
BYE与切换冲突导致掉话19
案例三：
bSRVCC失败导致未接通20
案例四：
终端未收到专载建立请求导致未接通20
【案例摘要】
在VOLTE使用中网络保持性能是业务质量重要方面，主要体现在VOLTE掉话指标。
【关键词】
VOLTE、呼叫、接通
1VoLTE关键知识点
1.1VOLTE概述和基本特征
VOLTE是什么？
最直接简单的理解就是VOIP，因为LTE没有电路域，需要基于分组域提供IP语音业务，即VoLTE（VoiceoverLTE）。
网络结构：
CSCF（CallSessionControlFunction）：
多媒体呼叫会话过程中的信令控制
MGCF（MediaGatewayControlFunction）：
执行IMS与CS域的互通；不同域间协议转换
MGW（MediaGateway）：
连接不同域的用户面；不同网络之间的编解码转换
特征1：
VoLTE由IMS提供呼叫控制和业务逻辑。
VoLTE的信令和媒体经EPC路由至IMS网络，由IMS提供会话控制和业务逻辑。
特征2：
VoLTE由EPC提供高质量的分组域承载。
在VoLTE中EPC作为IMS的接入网，通过全球统一的专用APN（‘IMS’APN）及独立承载为用户提供区别于普通数据业务的QoS保障。
特征3：
连续覆盖前VoLTE可通过eSRVCC保障呼叫连续性。
VoLTE终端在通话过程中漫游至无LTE覆盖的区域时，通过eSRVCC将当前呼叫切换至2G/3G电路域，此时2G/3G网络作为IMS的接入网。
1.2终端开机的IMS注册过程
为什么要注册：
-用户使用IMPU（IPMultimediaPublicIdentity）通信
-建立用户当前的IP与其IMPU的对应关系
-掌握用户当前的位置信息及业务能力
-注册过程的鉴权与认证保证了网络的安全性
用户开机以后，首先完成EPC附着过程，建立QCI=9默认承载，附着完成以后，发起IMS注册过程和鉴权。
在IMS注册流程中，先建立QCI=5的SIP信令承载。
然后进行SIP的注册过程，当完成注册过程以后，就可以进行VoLTE呼叫了。
SIP信令的注册过程如下图所示。
1.1.1IMS注册流程图
SIP注册过程：
IMS注册流程：
说明
1
IMS_SIP_REGISTER->Request
上
用户首次试呼时，终端向代理服务器发送REGISTER注册请求
2
IMS_SIP_REGISTER->Unauthorized
下
401Unauthorized（无权）响应，表明IMS端要求对用户进行认证
3
IMS_SIP_REGISTER->Request
上
SIPPhone重新向IMS发起注册请求，携带 Authorization字段，包括认证方式DIGEST、SIPPhone的用户标识（此时为电话号码）、IMS的域名、NONCE、URI和RESPONSE（SIPPhone收到401Unauthorized响应后根据服务器端返回的信息和用户配置等信息采用特定的算法生成加密的RESPONSE）字段
4
IMS_SIP_REGISTER->OK
下
IMS收到SIPPhone的注册请求，首先检查NONCE的正确性，如果和在401Unauthorized响应中产生的NONCE相同，则通过。
否则，直接返回失败。
然后，IMS会根据NONCE、用户名、密码（服务器端可以根据本地用户信息获取用户的密码）、URI等采用和终端相同的算法生成RESPONSE，并且对此RESPONSE和请求消息中的RESPONSE进行比较，如果二者一致则用户认证成功，否则认证失败。
此时，IMS返回200OK响应消息，表明终端认证成功。
5
IMS_SIP_SUBSCRIBE
上
用户订阅注册事件包
6
IMS_SIP_SUBSCRIBE200
下
服务器应答订阅成功。
7
IMS_SIP_NOTIFY
下
IMS服务器发送notify消息，由于订阅的用户已经注册，所以IMS服务器回应Notify消息中，状态为active，同时携带XML信息。
8
IMS_SIP_NOTIFY200
上
终端发送Notify200表示接收成功
1）用户首次试呼时，终端向代理服务器发送REGISTER注册请求
2）IMS认证/计费中心获知用户信息不在数据库中，向终端回401Unauthorized质询信息，其中包含安全认证所需的令牌
3）终端将用户标识和密码根据安全认证令牌加密后，再次用REGISTER消息报告给IMS服务器
4）IMS服务器将REGISTER消息中的用户信息解密，认证合法后，将该用户信息登记到数据库中，并向终端返回响应消息200OK。
5）用户订阅注册事件包，
6）服务器应答订阅成功。
7）IMS服务器发送notify消息，由于订阅的用户已经注册，所以IMS服务器回应Notify消息中，状态为active，同时携带XML信息。
8）终端发送Notify200表示接收成功。
1.3VoLTE呼叫VoLTE的信令呼叫流程
1.3.1呼叫流程图
1.3.2连接态与idle态起呼信令
Idle态起呼连接态起呼
1.3.3主叫流程图
1.3.4被叫流程图
对关键流程的解释如下表所示：
1）主叫发INVITE消息，触发主叫RRC建立过程，INVITE消息中包含被叫方的号码，主叫方支持的媒体类型和编码等。
2）主叫建立SRB2信令无线承载，QCI9默认承载和QCI5SIP信令无线承载。
例如在本例中，信令无线承载SRB-ID=2;QCI=9的默认承载的eps-BearerID=5,DRB-ID=3;QCI=5的SIP信令承载的eps-BearerID=6,DRB-ID=4
3）核心网侧收到主叫的INVITE消息以后，给主叫发送INVITE的应答消息，INVITE100.表示正在处理中。
4）核心网向处于空闲态的被叫发INVITE消息，由于被叫处于空闲态，所以核心网侧触发寻呼消息，寻呼处于空闲态的被叫用户
5）被叫建立SRB2信令无线承载，QCI9默认承载和QCI5SIP信令无线承载
6）核心网在QCI5RB承载上，给被叫用户发送INVITE消息
7）被叫对INVITE消息的响应
8）被叫方通知主叫方，自己所支持的媒体类型和编码。
9）主叫建立QCI1的数据无线承载，用于承载语音数据，使用UM方式。
例如本例中，eps-BearerID=7，DRB-ID=5。
关键参数包括头压缩参数，TTIBundling，SPS。
DRX参数也会按照语音业务的要求进行重新配置。
10）被叫建立QCI1的数据无线承载。
例如本例中QCI1承载的eps-BearerID=7，DRB-ID=5。
11）核心网通知主叫终端的SM层，建立qci=1的承载,例如：
eps-BearerID=7
12）主叫收到被叫的INVITE183消息
13）核心网通知被叫终端的SM层，建立qci=1的承载
14）主叫收到INVITE183消息以后，发送确认消息PRACK，启动资源预留过程，
15）被叫收到主叫的PRACK以后，返回PRACK200响应，启动资源预留过程，
16）主叫收到被叫的PRACK200以后，发送UPDATE消息，标明资源预留成功。
17）被叫收到主叫的UPDATE消息后，得知主叫UE的资源预留成功。
被叫发送UPDATE200，标明被叫资源预留成功，
18）被叫发送INVITE180，被叫振铃，主叫放回铃音
19）被叫摘机，被叫向主叫发送INVITE200.
20）主叫给IMS服务器发ACK，证实已经收到IMS对于INVITE请求的最终响应。
核心网IMS服务器发ACK消息给被叫，证实对于INVITE请求的最终响应。
21）主叫挂机，发BYE,请求结束本次会话。
IMS服务器给被叫发送BYE,请求结束本次会话。
22）被叫挂机，回BYE200消息，核心网IMS服务器给主叫发BYE200，标明会话结束。
23）通过RRCConntctionReconfiguration消息和去激活EPS专用承载消息，主叫删除QCI=1的数据无线承载。
24）被叫删除QCI=1的数据无线承载。
1.3.5SIP会话流程
下图是主叫A呼叫被叫B的SIP信令流程。
在INVITE消息前，终端已完成了MME附着和IMS注册，已经重配完成QCI=9和QCI=5，在随后的SIP信令交互中主被叫需要完成媒体协商、QCI=1专用承载建立、资源预留、通话建立和直到通话结束等流程。
1.主叫发起VoLTE语音呼叫，向IMS发起INVITE请求。
2.IMS向主叫响应100Trying，说明收到了INVITE请求。
3.从IMSHSS网元获得主叫签约和鉴权数据并触发AS业务逻辑控制后，确认用户认证通过，IMS向被叫转发INVITE请求。
4.被叫向IMS响应100Trying，说明正在处理INVITE消息。
5.被叫向IMS发送183SessionProgress消息，告知对端会话建立过程已经启动，开始资源预留的过程。
（此时被叫QCI1建立专用承载）。
6.待主叫QCI=1专用承载建立后，IMS向主叫转发183SessionProgress消息。
7.主叫发送PRACK请求消息并通过IMS转发给被叫，通知被叫已经收到其发送的183响应消息。
8.被叫收到PRACK请求消息后，发送200（OK）响应消息并通过IMS转发给主叫。
9.主叫发送Updata消息并通过IMS转发给被叫，表明主叫资源预留完成。
10.步骤10，被叫收到来自IMS转发的Updata消息后，通过IMS回应对端主叫200OK消息并表明被叫资源也预留完成。
11.步骤11，被叫振铃，通过IMS向主叫发送180Ringing振铃信息。
12.步骤12，被叫通过IMS向主叫发送200OK消息，表明主叫最初的INVITE请求已经处理成功。
13.步骤13，主叫通过IMS向被叫发送ACK确认消息，通知被叫，主叫已知道被叫处理INVITE请求成功，开始通话过程。
14.步骤14，主叫挂机并通过IMS向被叫发起通话结束BYE信息。
15.步骤15，被叫通过IMS向主叫发送200OK确认消息，整个通话结束。
2VoLTE路测与分析
2.1VoLTE主要指标
2.2分析方法及问题分类
VOLTE异常归属判定依据
VOLTE异常事件分析技术要求
2.3信令流程解析
3各类问题优化分析
3.1掉话问题分析思路
A、无线原因：
1）终端异常进入空闲模式或者无线链路失败、RRC重建失败，需要查看当时的SINR和RSRP，确认是否由于越区覆盖、邻区漏配、PCI模3干扰、弱覆盖、基站故障等无线问题导致。
2）eSRVCC切换失败需要对GSM邻区频点和BSIC码数据进行核查。
3）版本缺陷，如：
异频重定向和TM3/8转换为已知基站问题，已升级基站版本解决。
B、EPC原因：
如果保持期间发生专用承载丢失、核心网下发DetachRequest，跟踪MME、S/PGW、PCRF信令查找问题原因。
C、终端问题：
对比相同芯片的不同终端、异芯片终端，如果某款终端掉话率高，则疑似终端问题，需要对终端进行排查。
D、端到端原因：
RRC连接异常释放，则需要在eNB、EPC、IMS上同步抓取信令和数据包，检查消息在哪些网元之间丢失，针对相关网元进行问题排查。
3.2未接通问题分析思路
呼叫建立流程涉及终端、eNB、EPC、IMS等网元，所有网元的问题都可能导致未接通。
A、无线原因排查：
1）主叫/被叫多次发送信令或者异常进入空闲模式，查看当时的SINR和RSRP，确认是否由于越区覆盖、邻区漏配、PCI模3干扰、弱覆盖等无线问题导致。
2）主叫寻呼期间，被叫发起RAU/LAU/TAU，需要分析之前终端如何从4G重选或切换到
GSM/TD。
3）RRC连接异常释放，需要进行eNB信令跟踪，查看无线原因。
4）RAB建立问题，需要结合基站侧信令分，包括：
基站是否收到专载建立请求，基站收到
专载建立请求下发给终端但终端未收到专载建立请求，原因可能是下行链路太差导致终端无法收到；核心网未下发专载建立请求，联系核心网排查未下发专载建立请求原因。
B、终端问题排查：
1）对比相同芯片的不同终端、异芯片终端，如果某款终端接通成功率低，则疑似终端问题，需要对终端进行排查。
C、端到端原因排查：
1）主被叫发生SIP消息发送失败、SIP消息发送多次问题，则需要在eNB、EPC、IMS上同步抓取数据包，检查消息在哪些网元之间丢失，针对相关网元进行问题排查。
2）如果主叫收到480消息（当前不可用）、603（谢绝邀请），一般为被叫未收到寻呼问题，
需要在终端、eNB、EPC、PCRF、SBC上跟踪寻呼消息触发及发送情况。
3）如果主叫收到486消息（被叫忙），一般为被叫终端发送，需要跟踪终端、EPC、HSS
上信令，确认被叫忙原因。
4）如果主叫或被叫发送580消息（资源准备失败），一般为专用承载未建立或承载丢失，
需要在EPC、PCRF、SBC上跟踪信令，排查承载问题。
4案例分析
案例一：
模三干扰导致掉话问题
问题描述：
11:
32:
12.814，主叫切换到197小区后，SINR突然变得很差，11:
32:
13.126，引起Radiolinkfailure；之后RRC重建到212小区，SINR恢复正常；之后正常切换到415小区，发生TAU，之后RRCrelease，重建到210小区，继续TAU，然后导致掉话。
问题分析：
切换到197小区之后，电平良好，但SINR特别低，怀疑为mode3干扰导致，查看周围小区，发现50小区与197小区电平相近，mode3相同（见图1）；查工参，发现事发路段为197与50重叠覆盖区域（见图2），确认事件原因为mode3干扰；
解决方案：
进行PCI优化
案例二：
BYE与切换冲突导致掉话
问题描述：
通话正常结束，在主叫上发BYE消息，收到IMS回复的BYE200之后，或者在被叫收到BYE消息，回复BYE200之后，发生小区切换，之后再无收到EPS专载释放请求，被软件统计为掉话。
问题分析：
此问题需要核心网侧做出修改，在去激活与切换冲突的时候，当切换完成后，应该按照协议再发起一次释放过程。
图1：
有冲突的流程图2：
正常BYE流程
解决方案：
此问题属于核心网问题，应该核心网解决，但是由于此问题不影响用户感知，统计前台测试指标时可以剔除。
案例三：
bSRVCC失败导致未接通
问题描述：
终端在180Ring之前，无线环境满足B2门限，上报B2报告并触发eSRVCC过程，到2G后又很快释放。
发生在终端呼叫过程中，且发生于振铃前的eSRVCC过程被称为bSRVCC。
问题分析：
11:
27:
36.024，主叫在上发PRACK之后，发起eSRVCC过程，到2G侧后，核心网发送Progress消息给终端，终端上发releasecomplete消息，消息携带原因值：
Invalidtransactionidentifiervalue。
解决方案：
目前终端与核心网都不支持bSRVCC，规范也没有出来。
目前只能尽量优化无线环境、核查是否有邻区漏配，避免出现bSRVCC。
案例四：
终端未收到专载建立请求导致未接通
【问题描述】
主叫或被叫在呼叫过程中，未收到系统下发的专载建立请求导致未接通。
【问题分析】
上次正常通话结束后，本次通话主叫发送trying100消息后，核心网下发专业承载请求后主叫开始建立和激活专载流程。
被叫在上报183后，正常流程应该是由核心网下发专业承载建立请求后被叫开始建立专载过程，但实际上被叫一直未收到核心网下发的QCI1建立请求，主叫在上报PRACK后收到网络下发的481Calllegtransactiondoesnotexist消息，随后主叫上报cancel消息取消本次通话。
【问题定位】
终端未收到专载建立请求原因可能有：
1、无线环境太差，基站转发了核心网下发的专载建立请求但终端未收到；2、核心网未下发专载建立请求。
【解决措施】
需结合基站测CTS信令查看核心网是否下发专载建立请求消息，如下发了专载建立请求但终端未收到需要检查下行链路是否太差导致，需要优化下行覆盖。
核心网问题导致核心网未下发专载建立请求，需要核心网侧查找未下发专载建立请求原因。
升级会员 