VOLTE呼叫时延的优化研究.docx
《VOLTE呼叫时延的优化研究.docx》由会员分享，可在线阅读，更多相关《VOLTE呼叫时延的优化研究.docx（19页珍藏版）》请在冰豆网上搜索。
VOLTE呼叫时延的优化研究
VoLTE呼叫时延的优化研究
第一章项目创新背景3
第二章项目创新总体思路4
第三章项目创新方案和实施过程5
第四章项目创新成效6
第一章项目创新背景
VoLTE即VoiceoverLTE，是基于IMS的语音业务。
它是一种IP数据传输技术，无需2G/3G网，全部业务承载于4G网络上，可实现数据与语音业务在同一网络下的统一。
VoLTE技术带给4G用户最直接的感受就是接通等待时间更短，以及更高质量、更自然的语音视频通话效果。
VoLTE与2G、3G语音通话有着本质的不同。
VoLTE是架构在4G网络上全IP条件下的端到端语音方案。
VoLTE相较2G、3G语音通话，语音质量能提高40%左右，因为它采用高分辨率编解码技术。
VoLTE为用户带来更低的接入时延（拨号后的等待时间），比3G降50%，大概在2秒左右，而2G时代在6-7秒。
VOLTE呼叫建立时延是影响VOLTE网络质量和用户感知的关键因素，本文基于现网进行研究与实践，端到端分析影响VOLTE呼叫时延的因素，探索时延优化思路和方法，为VOLTE呼叫时延优化提供参考。
第二章项目创新总体思路
一、VoLTE呼叫原理及呼叫时长定义
VOLTE使用SIP（sessioninitiationprotocol）会话发起协议实现语音会话信令流程，SIP信令包括invite、100trying、183sessionprogress、prack/prack200OK、update/update200OK、180ringing、invite200OK等信令消息。
（一）、呼叫时长定义
呼叫建立时延=呼叫接通与呼叫试呼之间的时间差，即主叫发送INVITE消息到主叫收到180振铃消息的时间差。
如下图信令流程图中主叫发起第1条信令到主叫收到第11条信令的时间差。
在正常情况下,空闲态发起的VOLTE语音呼叫接入时延大致在3秒左右，下图是一次典型的VOLTE语音业务主被叫间各信令之间的时延分段统计，可作为时延参考。
由以上时延分段统计图可知：
1、无线接入阶段由RRC连接建立（SRB1）、SIP信令承载建立（QCI5，与SRB2/QCI9同时建立）、VOLTE语音业务承载建立（QCI1）三部构成。
前两步是呼叫建立流程中后续SIP信令交互的前提，时延大约100ms。
第三步与SIP流程并行，不影响接入时延。
2、QCI5的SIP信令承载建立后，终端通过NAS消息将INVITE请求发往IMS域。
首条SIP消息，需要经过I-CSCF路由处理，加上空口的寻呼时延，至被叫接收到VOLTE呼叫的寻呼请求时延大致在1s。
3、被叫终端接收INVITE消息到回复SESSION_PROGRESS（183），大约在50ms。
4、被叫SIP接入时延同样在100ms左右，建立QCI5的SIP信令承载后回复SESSION_PROGRESS（183），同样需要经过I-CSCF路由处理，时延在500ms左右。
至此主被叫已完成IP地址交换。
5、完成IP地址交换后，后续SIP传输时延都缩短为250ms左右，但180RINGING依旧需经过I-CSCF路由，故传送时延在500ms左右。
综上，主叫发送INVITE消息到主叫收到180RINGING消息的时间差大约在3s左右。
（二）、信令与承载流程
LTE呼叫LTE语音信令、承载流程图：
主叫信令面流程：
主叫用户发起呼叫请求后，首先MMTelAS进行主叫业务处理后，主叫侧S-CSCF根据被叫号码格式向ENUM/DNS请求被叫的入局I-CSCF的地址。
被叫信令面流程：
SCCAS向融合HLR/HSS请求被叫网络信息，融合HLR/HSS向MME请求本地保存的用户最新的位置更新信息，将得到的域选网络信息发送给SCCAS，SCCAS得到被叫的最近一次驻留的网络后，指示S-CSCF通过P-CSCF将呼叫路由到被叫用户。
被叫承载面建立流程：
被叫用户收到呼叫请求后，向被叫P-CSCF回复183/180响应消息，P-CSCF向PCRF发起承载建立请求，PCRF向P-GW提供授权的QoS策略，P-GW根据授权的QoS策略建立被叫UE的专有承载。
主叫承载面建立流程：
主叫P-CSCF收到被叫用户回复的响应消息后向PCRF发起承载建立请求，PCRF向P-GW提供授权的QoS策略，P-GW根据授权的QoS策略建立主叫UE的专有承载。
挂机释放流程：
被叫用户接收到主叫用户的挂机请求后，通过PCRF进行被叫承载释放操作，释放完成后，将响应消息发送给主叫侧，当主叫侧P-CSCF收到响应消息，通过PCRF进行主叫承载释放操作。
（三）、实测信令流程
主叫UE呼叫建立信令流程截图：
VOLTE视频呼叫前台信令：
1、主叫UE与eNB完成RRC连接建立，初始上下文建立，eNB下发RRC重配消息，此重配中带有QCI9和QCI5承载的重配置信息，完成QCI8/9和QCI5承载重配。
2、QCI5信令承载完成后，主叫UE与IMS进行SIP会话流程交互，主叫UE发SIP信令INVITE消息到IMS，IMS转发INVITE消息首先经过PDN网关到SGW网关，SGW发现被叫UE为IDLE状态，发送下行数据到达通知给MME，MME对被叫发起paging。
3、主叫UE发起QCI1专用承载建立，用以承载语音数据包，主叫UE发起QCI2专用承载建立，用以承载视频数据包。
4、被叫手机收到Paging后，完成RRC连接建立，初始上下文建立，eNB下发RRC重配消息，携带有QCI9和QCI5承载重配置信息，完成QCI8/9和QCI5承载重配。
被叫UE发起QCI1/QCI2专用承载建立，用以承载语音/视频数据包。
5、当主叫手机收到被叫反馈的INVITE200OK，向被叫发ACK响应，待被叫手机收到ACK后，VOLTE通话开始。
主叫UE呼叫释放信令流程截图：
6、主叫手机发起挂机，将发送BYE消息给被叫，主叫收到后被叫手机回复的200OK（BYE）消息，VOLTE视频通话结束，随后主被叫释放QCI1/QCI2专用承载，释放RRC空口连接。
第三章项目创新方案和实施过程
根据实测log分析，我们可以将VOLTE呼叫时长，分为无线RRC连接建立阶段（针对处于RRC空闲状态用户），SIP信令空口交互阶段，SIP信令网络侧交互阶段这3大阶段。
（一）RRC连接建立阶段时延
随机接入分为基于竞争的随机接入和基于非竞争的随机接入两个流程，其区别为针对两种流程其选择随机接入前缀的方式。
前者为UE从基于竞争的随机接入前缀中依照一定算法随机选择一个随机接入前缀；后者是基站通过RRC重配消息给UE指配非冲突的随机接入前缀资源。
初始接入采用基于竞争的随机接入，切换多数采用非竞争的随机接入。
基于竞争的随机接入：
1、MSG1：
UE在PRACH上发送随机接入前缀；
2、MSG2：
ENB的MAC层产生随机接入响应，并在PDSCH上发送；
3、MSG3：
UE的RRC层产生RRCConnectionRequest并映射到PUSCH上发送；
4、MSG4：
RRCConnectionSetup由ENB的RRC层产生，并映射到PDSCH上发送。
至此，基于竞争的随机接入冲突解决完成，UE的RRC层生成RRCConnectionSetupComplete并发往ENB。
绝大部分情况下，RRC连接建立时延都在100ms左右完成，VOLTE呼叫和普通数据业务的RRC连接建立无区别；如果RRC连接建立时延明显过长，可参照RRC连接建立成率优化相关专题进行优化处理，重点核查覆盖、参数设置、干扰等原因。
（二）被叫paging阶段时延
1、寻呼机制
为了实现UE省电，LTE引入了DTX/DRX的设计。
这里的DTX主要指eNB不连续发送，DRX主要指UE不连续接收。
根据UE所处的RRC状态不同，又可以分为RRC_IDLE状态的寻呼DRX和RRC_Connected状态下的DRX。
这两种DRX的主要特点如下表：
内容
RRC空闲态寻呼DRX
RRC连接态DRX
控制网元
MME：
发起寻呼
eNB：
传输寻呼
eNB
适用范围
在一个跟踪区域（TA）内
在一个小区内
指示使用的UE
标识
长标识（如NAS分配的S-TMSI或IMSI）
短标识（如eNB分配的C-RNTI16bits）
寻呼DRX是指处在RRC空闲状态的UE不连续地监测寻呼信道（PCH）。
它的主要要求是要能实现低功耗、低延迟和低网络负荷。
UE使用P-RNTI周期监听PDCCH来了解PDSCH上是否有寻呼。
如果有，则解码PDSCH上承载的PCH的寻呼消息，从解码后的寻呼信息中查看是否有针对该UE的寻呼记录。
每个寻呼消息中包含一个寻呼记录列表（PagingRecordList），该列表包含所有此次被寻呼的UE记录，每条寻呼记录含有用于寻呼的UE标识P-RNTI。
系统可以使用IMSI或者S-TMSI两种标识进行寻呼。
如果使用S-TMSI进行寻呼，每个寻呼记录长度约为5字节。
如果使用IMSI寻呼，每个寻呼记录长度约为8字节。
一次寻呼消息最多可以包含16条UE记录，也就是说每次最多16个UE可以被同时寻呼。
2、核心侧寻呼策略优化
MME支持将VOLTEDDN触发寻呼和分组数据智能寻呼方式区分开，VOLTE要求首次寻呼不采用eNB列表范围寻呼，防止首次eNB寻呼失败再二次发起TALIST范围寻呼，造成VoLTE呼叫接续时间长。
MME根据SGW/PGW的DDN消息中EBI执行对应的寻呼策略进行寻呼，从而缩短VoLTE业务寻呼的时间，加快VoLTE呼叫接续过程。
（1）MME打开支持EBI和PSI功能
SETSOFTWAREPARAMETER:
PARAID=262465,PARAVALUE=1;
SETSOFTWAREPARAMETER:
PARAID=262478,PARAVALUE=1;////以前改过，默认应该为1，现在为0
（2）如果TALIST配置大于2，则修改TALIST只分配2个TA。
如果小于或者等于2，不需要修改。
SETTALISTASSIGNPOLICY:
MAXTANUM=2;
（3）配置VOLTE的寻呼策略，GUTI在TALIST中寻呼3次，寻呼间隔为3秒。
总的寻呼时长为9秒。
这个总寻呼时长建议等于IMS的CSRETRY定时器时长。
ADDMMEPSPAGINGPOLICY:
ID=51,PAGEPOLICY="GUTITALIST"-30-"PRIO_255"&"GUTITALIST"-30-"PRIO_255"&"GUTITALIST"-30-"PRIO_255";
（4）配置VOLTEAPN=IMS,QCI=5的寻呼策略因子
ADDMMEPAGINGPOLICYFACTOR:
QCI=5,APNNI="ims",PGPOLICY="PS"-51;
ADDMMEPAGINGPOLICYFACTOR:
QCI=1,APNNI="ims",PGPOLICY="PS"-51;
ADDMMEPAGINGPOLICYFACTOR:
QCI=2,APNNI="ims",PGPOLICY="PS"-51;
VOLTE的DDN触发寻呼索引到51的寻呼模板，在当前TA中寻呼。
普通数据寻呼匹配MME全局寻呼策略。
普通数据业务的寻呼策略：
寻呼类型
寻呼次序
寻呼方式
寻呼时长（100ms）
寻呼优先级
携带寻呼无线能力
携带寻呼推荐小区信息
携带寻呼覆盖增强级别
自定义寻呼
1
最近活动eNB列表寻呼
40
N/A
不携带
不携带
不携带
自定义寻呼
2
最近一次活动TA寻呼
40
N/A
不携带
不携带
不携带
自定义寻呼
3
GUTI在TALIST范围寻呼
80
N/A
不携带
不携带
不携带
自定义寻呼
4
IMSI在TALIST范围寻呼
80
N/A
不携带
不携带
不携带
3、无线侧寻呼参数优化
无线影响寻呼时延相关的参数主要包括：
监听寻呼周期、寻呼重复次数、寻呼时机因子和DRX功能参数等。
对于空闲态终端，缩短UE监听寻呼周期，可以缩短寻呼时延；一般建议从128帧调整为32帧，缩短寻呼周期。
参数名称
参数短名
参数描述
UE监听寻呼场合的DRX循环周期
defaultPagingCycle
当处于idle状态的UE，如果DRX被使用，则UE只需要每隔DRXcycle个周期在一个pagingoccasion时刻仅监听一个P-RNTI。
该参数指示了该DRX周期。
在LTE小区用户数较大时，可以适当调整此参数，增大寻呼容量。
参数名称
参数短名
参数描述
寻呼时机因子
nB
增加寻呼容量，避免寻呼量大时等待时间长。
在LTE信号弱覆盖的郊区或农村地区，针对下行覆盖边缘PDSCH信号偏差，导致寻呼接收不到，无线侧启用寻呼重发1次，改善寻呼响应率。
注意：
增加寻呼重复次数，要避免在高用户和高负荷小区下导致寻呼丢弃或寻呼拥塞。
参数名称
参数短名
参数描述
寻呼重复次数
pagingRepeatTime
配置寻呼可重复的次数。
对于QCI1/QCI2的VOLTE业务，关闭GBR业务DRX使能开关，终端始终处于激活态，可减少VOLTE信令交互时延。
如果关闭GBR业务DRX开关，也需要同时关闭NGBR业务DRX开关。
存在多个DRX配置时，采用高优先级业务DRX配置。
参数名称
参数短名
参数描述
GBR业务DRX使能开关
switchForGbrDrx
控制GBR业务的不连续接收的开关，如果该开关关闭，则当UE有GBR业务时不启用DRX，否则可以启用DRX。
非GBR业务DRX使能开关
switchForNGbrDrx
控制NGBR业务的不连续接收的开关，如果该开关关闭，则当UE有NGBR业务时不启用DRX，否则可以启用DRX。
（三）IMS呼叫信令时延优化
1、IMS时延优化方法
（1）VOLTEAS重选域定时器优化
此定时器超时，VOLTEAS没有收到VOLTE被叫侧的响应，会重选CS网络，获得被叫的漫游号码TLDN后，向CS网络发起寻呼。
重选定时器可配置，需参考MME的寻呼时长，目前MME寻呼策略为3*3S，IMS设置为3*3+1S。
（2）SBC不等待RAR信息转发送183
被叫向主叫侧发送183时不等待位置信息RAR流程,改由200OK来携带位置信息。
目前SBC已经配置为不等待RAR，正常情况下可优化时延20ms左右。
ZTEB200#conft
ZTEB200（config）#sbc
ZTEB200（config-sbc）#signal-portal
ZTEB200（config-sbc-sp）#rx-profile1
ZTEB200（config-sbc-sp-rxp）#accinfo-queryrarnot-wait
ZTEB200#wr
（3）根据183媒体信息修改AAR流程
主叫SBC收到被叫侧的183后，与INVITE中的SDP媒体信息进行比对,如无变化，则不发AAR修改承载。
预计可减少160ms。
ZXSS10B200（config-sbc-sp-rxp）#trigger-mode
singlemo-init-optimizedadvanced
其中mo-init-optimized表示183不触发，advanced表示UPDATE和200UPDATE不触发与RX接口的UPDATEAAR消息发送优化同时使用。
2、EPC时延优化方法
SGW开启数据缓存功能：
当被叫Idle状态，由于SGW不缓存消息，当被叫寻呼成功时也无法发送SIP请求，SGW需要等待IMS重发请求（间隔500ms/1s/2s），然后将请求投递给eNodeB，这样时延就会加大。
S-GW开启数据缓存功能，减少用户呼叫建立时延。
另外可以在SBC和PCRF上把消息进行合并，减少消息交互次数。
xGW（config-xgw-sgw）#dl-buffer-num5ARPenableEBIenablePSIenable
3、无线侧其他时延优化方法
（1）LTE覆盖质量提升
在LTE弱覆盖或SINR差区域起呼，容易出现RRC连接建立时延长或者发生RRC重建立，影响呼叫时延。
邻区间优化不合理，很容易在起呼过程中发生连续多次切换，导致呼叫时延过长，甚至呼叫失败。
（2）控制面user_inactivity定时器
DT测试过程中，呼叫间隔一般在15s或20s，而控制面uesr_inactivity定时器当前集团建议为10s，此时在起呼时，UE基本都处于空闲态。
那么必然导致呼叫时延增长，呼叫时延增加主被叫RRC建立时长200ms左右，以及等待寻呼时间600ms左右。
（无线寻呼周期128帧）
第四章项目创新成效
案例1：
随机接入困难导致呼叫时延超长
【问题现象】：
本次呼叫建立时延为13970ms，时延超长。
【问题原因】：
经分析，VOLTE起呼时，RSRP在-130dBm上下，实际可能已经脱网。
后在其他小区发起RRC重建立流程，但是重建立失败。
最终经过TAU流程，在其他小区接入成功，呼叫继续。
此过程就占用11s左右。
从截图可以看到，此时SINR=-7.2，passloss=150dB,UE接收到RSSI=-91.75毫瓦分贝。
起呼时段为切换带，并且覆盖太差导致本次呼叫时延超长。
【解决方案】：
实际上在本次呼叫之前的一次呼叫，由于无线环境差，呼叫建立失败。
因此需要对此路段进行RF优化，考虑新新增规划站点，增加该区域覆盖。
案例2：
重复寻呼导致时延偏长
【问题现象】：
本次呼叫建立时延为5310ms，时延偏长。
【问题分析】：
根据终端侧信令，主叫侧发送invite消息后，在4s多后收到183消息；被叫侧在4s后才收到寻呼消息。
查看核心侧EPC信令，本次呼叫发生了2次寻呼，寻呼间隔3s，因此导致本次呼叫建立时延偏长。
根据核心侧寻呼时刻关联无线侧寻呼时刻，第一次寻呼时刻在09:
50:
37.570，第二次寻呼时刻在09:
50:
40.450，此时终端从PCI=202小区重选到了PCI=255小区。
在第一次寻呼时SINR较差，在-11左右，而第二次寻呼时SINR为3.2。
第一次寻呼占用PCI255信号，RSRP-115dBm，SINR-11.4,属于典型的弱覆盖场景，可能是导致第一次寻呼失败的原因。
第二次寻呼同样占用PCI255，RSRP-101dBm，SINR3.2信号转好
主叫信令：
被叫信令：
EPC侧的二次寻呼信令：
【解决方案】：
针对本次时延长场景，可以从两个方面优化。
一是增强覆盖，提高SINR;二是优化重选门限，降低重选门限，避免重选时SINR较差。
1、从测试数据上可以看出，由PCI202重选到PCI255上时，PCI255信号较差，由此说明PCI202此时信号更差，属于弱覆盖区域，因此可以在PCI202和PCI205扇区交叠处新增规划站点。
2、降低重选门限，snonintrasearch门限由原来的-108dBm调整为-104dBm，使得信号更快的重选到好的小区上，避免在差的小区上多次寻呼。
升级会员 