VOLTE呼叫建立过程中的UPDATE含义及过程分析
VOLTE指标及信令流程
六忙时平 均
Enb
0.5%
E-RAB掉线率(QCI=5)
E-RAB(QCI=5)掉线率反映了系统 的业务通讯保持能力，也反映了系 统的稳定性和可靠性。
∑( 分QCI的eNB请求释放的E-RAB数 -分QCI的正常 的eNB请求释放的E-RAB数 +分QCI的切出失败的ERAB数 )/∑分QCI的E-RAB建立成功数， 其中∑代表将 本地网范围内的各个小区的统计结果累加, QCI=5。
（MO发送的RTP数据包数量-MT接收的RTP数据包数 量）/MO发送的RTP数据包数量*100%
六忙时平 均
Enb
小区下行PDCP SDU平均时延 小区用户面下行平均时延
六忙时平 均
Enb
99% 1% 0.1s
目录
VoLTE主要指标介绍 VoLTE集团用例测试指标 VoLTE信令流程
6
7.1基本呼叫体验测试-好点
话音质量
抖动（Jitter）（话音）
RTP丢包率（PLR）（话音）
RTP丢包率（PLR）（视频）
指标描述
公式定义
建议值
终端侧发起第一条随机接入消息到收到网 络侧下发SIP 180 ring消息之间的时间差
--
被叫上发INVITE 183到收到UPDATE（ QCI1专用承载建立）
--
被叫上发INVITE 183到收到UPDATE（ QCI1&QCI2专用承载建立）
六忙时平 均
Enb
0.5%
保持性 E-RAB掉线率(QCI=2)
E-RAB(QCI=2)掉线率反映了系统 的业务通讯保持能力，也反映了系 统的稳定性和可靠性。
∑( 分QCI的eNB请求释放的E-RAB数 -分QCI的正常 的eNB请求释放的E-RAB数 +分QCI的切出失败的ERAB数 )/∑分QCI的E-RAB建立成功数， 其中∑代表将 本地网范围内的各个小区的统计结果累加, QCI=2。
VoLTE基础信令流程与详细解析
VOLTE信令流程VOLTE是基于SIP协议的语音通话，所有与IMS交互的信令全部为SIP信令，在理解VOLTE信令方面必须对SIP信令进行了解，EPC只是做为业务承载体。
由于SIP信令是以加密方式传输，SIP信令只有在CN侧和终端侧才能解码，基站CDL无法记录SIP信令，同时CDL 无法解码较多NAS层直传消息，所以本文中的信令说明部分不结合CDL信令进行说明1.注册流程及重要信令详解SIP 提供了发现机制，如果用户要发起和另一个用户的会话，SIP 必须发现可到达目的用户的当前主机，注册将记录地址URI 和一个或者多个联系地址相关联，这样才能进行呼叫等业务。
严格意义上说，SUBSCRIBE和NOTIFY过程不属于注册过程，但由于该过程在注册完成后紧跟着出现，所以本文将该过程放在注册流程中进行说明。
用户的注销过程与注册过程相似，主要就是注销请求中,expire值为0，所以本文中不再进行单独说明，注销过程无SUBSCRIBE信令，是因为UE注册时已有SUBSCRIBE。
信令说明如下：1.UE进行Attach，建立QCI=9的默认承载，并使用IMS APN建立PDN连接；2.建立立QCI=5的默认承载，用于传送SIP信令；3.UE通过QCI=5的默认承载向IMS发起注册请求；4.P-CSCF通过HSS获知用户信息不在数据库中，便向终端代理回送401 Unauthorized 质询信息，其中包含安全认证所需的令牌；5.终端将用户标识和密码根据安全认证令牌加密后，再次用REGISTER消息报告给P-CSCF服务器；6.P-CSCF将REGISTER 消息中的用户信息解密，验证其合法后，IMS核心网将该用户信息登记到数据库中，并向终端返回成功响应消息200 OK；7.用户向IMS订阅注册事件包8.服务器应答订阅成功9.IMS服务器发送notify消息，由于订阅的用户已经注册，所以IMS服务器回应Notify消息中，状态为active，同时携带XML信息10.终端发送Notify 200表示接收成功注册过程测试信令载图如下：注销过程测试信令截图如下：1)Activate Default EPS Bearer Context Request（QCI=5）该信令是用于建立QCI=5的默认承载，所有SIP信令都通过QCI=5的承载传输，该信令的内容已在该信令前的RRC重配置中附带下来。
VOLTE测试问题点汇总
1、VOL TE测试信令流程与标准不符1.1起呼过程中主被叫在183 消息之前已完成QCI1专载建立,共有以下4种情况：被叫2种：a).被叫在收到INVITE Request之前已完成完成QCI1专载建立;b).被叫在收到INVITE的同时收到QCI=1的承载建立请求；主叫2种：c). 主叫在收到IMS的100 Trying之前就已经建立QCI=1的承载；d). 主叫在收到Trying 100后，183前已完成QCI1专载建立信令截图如下：a).被叫收到INVITE消息前就开始建立QCI1的专用承载;B).被叫在收到INVITE的同时收到QCI=1的承载建立请求；c).主叫在收到IMS的100 Trying之前就已经建立QCI=1的承载；d). 主叫在收到Trying 100后，183前已完成QCI1专载建立，被叫在INVITE Request前已完成完成QCI1专载建立。
1.2被叫侧在回复BYE-200之前，主叫就已经收到IMS下发的BYE-200消息IMS核心网反馈，SBC策略要是收到任一方BYE Reques 直接通知MME释放EPS，无需等待主被叫回复BYE 200 OK。
1.3主叫发起BYE Request挂机，但被叫先收到专载释放，且释放完成后才收到IMS下发的BYE Request，导致平台统计为掉话。
DRB-3为QCI1专载1.4主叫收到Trying 100后网络侧下发去激活QCI1专载，但主叫上次通过结束后已释放完成。
2、三次Modify EPS bearer2.1 主被叫在起呼过程中多次修改EPS Bearer测试发现起呼过程中多次修改EPS Bearer: GBrForDwLink、GBrForUpLink、MbForDwLink、MbrForUpLink 相关速率修改为49、50、96等。
QCI=1的专用承载的EPSID=8(GBR上行50、下行49，第一次MODIFY：修改GBR上下行49，第二次MODIFY：与第一次一样，第三次MODIFY与第二次一样；这种多次修改GBR保障速率主要目的是什么？帮忙看看核心网是否能答复异常呢？)value message name : Activate dedicated EPS bearer context requestvalue Activate dedicated EPS bearer context request ::=|----Esm Header|----Protocol discriminator : 2 (ESM messages)|----EpsBearerId : 0x08|----ProcedureTxnId : 0|----MsgType : 0xc5|----LinkedEpsBearerId : 0x05|----SdfQos|----GbrForDwLink : 49|----GbrForUpLink : 50|----MbrForDwLink : 49|----MbrForUpLink : 50|----GbrForDwLink_Extend : 0|----GbrForUpLink_Extend : 0|----MbrForDwLink_Extend : 0|----MbrForUpLink_Extend : 0|----Qci : 1第一次：value message name : Modify EPS bearer context requestvalue Modify EPS bearer context request ::=|----Esm Header|----Protocol discriminator : 2 (ESM messages)|----EpsBearerId : 0x08|----ProcedureTxnId : 0|----MsgType : 0xc9|----SdfQos|----GbrForDwLink : 49|----GbrForUpLink : 49|----MbrForDwLink : 49|----MbrForUpLink : 49|----GbrForDwLink_Extend : 0|----GbrForUpLink_Extend : 0|----MbrForDwLink_Extend : 0|----MbrForUpLink_Extend : 0|----Qci : 1第二次：value message name : Modify EPS bearer context requestvalue Modify EPS bearer context request ::=|----Esm Header|----Protocol discriminator : 2 (ESM messages)|----EpsBearerId : 0x08|----ProcedureTxnId : 0|----MsgType : 0xc9|----SdfQos|----GbrForDwLink : 49|----GbrForUpLink : 50|----MbrForDwLink : 49|----MbrForUpLink : 50|----GbrForDwLink_Extend : 0|----GbrForUpLink_Extend : 0|----MbrForDwLink_Extend : 0|----MbrForUpLink_Extend : 0|----Qci : 1第三次：value message name : Modify EPS bearer context requestvalue Modify EPS bearer context request ::=|----Esm Header|----Protocol discriminator : 2 (ESM messages)|----EpsBearerId : 0x08|----ProcedureTxnId : 0|----MsgType : 0xc9|----SdfQos|----GbrForDwLink : 49|----GbrForUpLink : 49|----MbrForDwLink : 49|----MbrForUpLink : 49|----GbrForDwLink_Extend : 0|----GbrForUpLink_Extend : 0|----MbrForDwLink_Extend : 0|----MbrForUpLink_Extend : 0|----Qci : 1下图GBrForDwLink、、MbForDwLink、相关速率有修改为49、96。
案例-Volte业务呼叫建立时延的优化分析
中国电信衡水分公司Volte业务中对呼叫建立时延的优化分析目录一、概述 (3)二、呼建时延分析 (4)2.1 Volte业务的呼叫建立流程 (4)2.2 影响呼叫建立时延的因素 (5)2.3 无线侧对呼叫建立时延的影响 (6)2.4 实践验证 (8)三、总结 (12)一、概述LTE时代，多元化的业务对“覆盖”、“速率”和“时延”提出了更高的要求，比如语音、web、视频等。
而语音业务特别是高清语音（VOLTE）的诉求逐渐增加，高清语音的优良感知提出新的挑战。
衡水LTE本地网络目前为800M、1800M、2100M共三个频段组网，对于不同业务承载采用的业务分层，即QCI（1、2、5）以800M网络优先承载，QCI（6、7）为1800M 网络优先承载。
本文通过对Volte语音业务下的呼叫流程解析以及Volte承载在不同频段下的起呼流程对比，从无线优化的角度来验证业务分层对呼叫建立时延的影响。
二、呼建时延分析2.1 Volte业务的呼叫建立流程volte信令流程图根据简化信令流程图所示，主叫发送Invite消息到主叫收到180振铃消息的时间差，即主叫发起第1条信令到主叫收到第11条信令的时间差即为呼叫建立时延。
正常情况下，UE由空闲态发起的VoLTE高清语音通话接入时延大致在3秒左右。
Volte网元流程图根据网元流程图，整个呼叫建立流程涉及到EPC(S/P-GW)、IMS(SBC/P-CSCF、I/S-CSCF)两个核心实体。
2.2 影响呼叫建立时延的因素主被叫UE在LTE网络下的Volte语音呼叫时延由终端、无线、EPC及IMS网络时延组成。
从主叫终端发送第一个会话消息（INVITE）到接受到网络侧发送的振铃消息（180），影响呼叫建立时长的因素主要有三个：IMS消息处理部分耗时，IMS消息处理主要包括消息在网元间的传输时延以及业务流程耗时，包括主叫业务、被叫业务、锚定、域选等关键流程。
呼叫过程中的空口耗时+EPC消息来回耗时，消息在网络侧和终端之间的耗时。
经典案例-VoLTE网络呼叫建立时延问题优化实践总结
VOLTE网络呼叫建立时延问题优化实践总结一、问题描述VOLTE技术的应用使4G网络除了能提供高速率的数据业务，同时还能提供高质量的音视频通话，不同于目前2G、3G网络下语音业务，带给4G用户最直接的感受就是接通等待时间更短，音视频通话效果更佳。
呼市电信VOLTE业务于2017年9月份已全部开通，但目前还未正式投入商用，此次优化重点找出VOLTE网络薄弱环节重点提升，夯实网络基础，确保VOLTE网络顺利试商用。
二、问题定位过程描述前期集团要求VOLTE网络全网摸底测试发现，呼叫建立时延较差在4S左右，未达到3S之内标准。
本次优化考虑到市内路况拥堵因素对测试结果的影响，故试验区域选择丰州路与昭君路区间南二环及其南侧区域主要道路为测试路线，规划路线总长约48km，途径站点74个，共273个小区。
具体规划路线如下图所示：对规划路线进行了首轮摸底测试，测试参数设置如下：主叫侧参数配置被叫侧参数配置测试指标统计如下：经分析电子围栏干扰发生一次掉话外，发现呼叫建立时延指标未达到标准值，本次重点提升呼叫建立时延指标。
全程呼叫成功率（%）测试里程(km)平均RSRP(dBm)平均SINR(dB)掉话次数（次）掉话率（%）呼叫建立时延（s）平均MOS值MOS>3.5比例（%）100.00% 47 -83.98 12.27 1 2.63% 3.49 4.11 97.73%三、优化过程（方法）描述➢过程1优化方案目前现网控制面user-inactivity定时器设置为10s，即VOLTE 呼叫结束10s内如无数据业务所有承载将全部被释放掉；而本次测试设置呼叫间隔为15s，故每次呼叫均在QCI=9和QCI=5的承载被释放后发起，此时主被叫均需重新建立QCI=9和QCI=5的承载，即每次呼叫主被叫均要发起随机接入过程，由空闲态转为连接态，如果让主被叫在呼叫过程中一直保持在连接态，则会省掉RRC连接建立过程，缩短呼叫时延。
VOLTE呼叫建立过程中的UPDATE含义及过程分析
呼叫建立过程中的UPDATE含义及过程分析UPDATE过程的意义在呼叫建立过程中主叫会有一个或者多个UPDATE过程，主要是用来进行资源预留及媒体更新，比如主叫有高清语音提示或者被叫有彩铃等业务时，在呼叫建立过程中将会进行多个UPDATE过程进行媒体更新体验新业务，具体情况下面详细分析。
主被叫均无其他高清语音提示或彩铃等业务主被叫均无高清语音提示、彩铃等业务时，主被叫在呼叫建立过程中均只有一次UPDATE过程，用来保障资源预留成功主被叫编码格式协商一致，其信令流程如下：炎强信令包：主叫有高清语音提示业务被叫无彩铃业务在主叫有高清语音提示音被叫无彩铃的呼叫建立过程中，主叫一般会有3次UPDATE 过程：第一次为资源预留与被叫编码格式协商；第二次为被叫180消息发送过来后先被TAS 拦截后由TAS触发UPDATE过程通过多个网元下发给主叫UE进行媒体更改，主叫出现高清语音提示音，在此次UPDATE完成后才将INVITE 180消息透传给主叫UE；第三次还是TAS 给主叫下发UPDATE过程，目的是将媒体格式更新为与被叫一致的格式，为主叫接收INVITE 200消息做好准备。
（主叫无高清语音提示被叫有彩铃的过程与此一样）第三次UPDATE过程有2种触发情景：情景1为主叫在听到高清语音提示音的过程中间被叫接通并上报INVITE200消息，此INVITE200消息在TAS处触发第三次UPDATE过程，并在第三次UPDATE完成后才由SBC将INVITE200消息下发给UE；情景2为主叫播放完高清语音提示音后，TAS自主下发UPDATE过程，现网的高清语音提示音时长大概为14秒左右，也就是说被叫一直没有接通的情况下，主叫在收到INVITE180消息大概14秒后会收到网络下发的UPDATE请求。
炎强信令包：主叫有高清语音提示、被叫有彩铃业务对于主叫有高清语音提示、被叫有彩铃业务的终端，在进行通话过程中将有4次UPDATE 过程：第一次为资源预留与被叫编码格式协商；第二次、第三次为被叫180消息发送过来后先被TAS拦截后由TAS触发UPDATE过程通过多个网元下发给主叫UE进行媒体更改，目的是让主叫接收到高清语音提示音及彩铃声音，在第二次、第三次UPDATE完成后才将INVITE 180消息透传给主叫UE；第四次还是TAS给主叫下发UPDATE过程，目的是将媒体格式更新为与被叫一致的格式，为主叫接收INVITE 200消息做好准备。
VoLTE端到端业务质量分析要点
VoLTE端到端质量分析SIP-503错误码原因分析研究目录1.SIP-503消息错误码分析背景 (2)2.SIP-503失败原因分类 (2)3.SIP-503流程分析 (4)3.1.无线链路失败导致掉话 (4)3.2.VoLTE走盲重定向导致掉话 (5)3.3.X2切换失败导致的掉话 (5)3.4.Sip信令丢失导致未接通ue-not-available-for-ps-service (6)3.5.2G侧资源异常导致未接通 (8)3.6.基站弱场起呼功能导致 (8)3.7.BSRVCC切换失败 (9)3.8.VoLTE参数配置问题 (10)3.9.VoLTE流程冲突问题（1） (11)3.10.VoLTE流程冲突问题（2） (12)3.11.VoLTE流程冲突问题（3） (13)3.12.VoLTE流程冲突问题（4） (13)3.13.VoLTE流程冲突问题（5） (14)4.SIP-503失败案例总结 (15)4.1.邻区配置问题导致SIP-503失败原因：tx2relocoverall-expiry (15)4.2.干扰问题导致SIP-503失败原因：tx2relocoverall-expiry (16)4.3.传输问题导致SIP-503 S1切换导致VoLTE掉话 (19)4.4.站内切换与modify并发SIP-503导致视频失败 (23)4.5.站内切换并发导致未接通 (24)5.SIP-503失败原因处理流程总结 (26)1.SIP-503消息错误码分析背景2016年中国移动集团开展VoLTE百日会战工作期间，我司在VoLTE质量提升过程中结合炎强平台从TOP小区、DT/CQT遍历拉网测试信令分析中总结经验，旨在帮助各办事处尽快解决信令分析中遇到的问题。
随着VoLTE优化工作的开展，我们发现有些SIP-503错误码与无线测关联较大，如外部邻区、帧头偏移未对齐导致的干扰，传输时延、切换并发等问题都会导致SIP消息报错，而这些SIP消息报错的时间点之前eNB就发起了异常的信令释放。
volte SIP协议主要消息
第一章SIP协议主要消息1.1 SIP消息分类SIP协议是以层协议的形式组成的，就是说它的行为是以一套相对独立的处理阶段来描述的，每个阶段之间的关系不是很密切。
SIP协议将Server和User Agent之间的通讯的消息分为两类：请求消息和响应消息。
请求消息：客户端为了激活特定操作而发给服务器的SIP消息，包括INVITE、ACK、BYE、CANCEL、OPTION和UPDATE消息。
SIP请求的6种方法：1、邀请（INVITE）——邀请用户加入呼叫2、确认（ACK）——确认客户机已经接收到对INVITE的最终响应3、可选项（OPTIONS）——请求关于服务器能力的信息4、再见（BYE）——终止呼叫上的两个用户之间的呼叫5、取消（CANCEL）6、注册（REGISTER）——提供地址解析的映射，让服务器知道其它用户的位置响应消息：服务器向客户反馈对应请求的处理结果的SIP消息，包括1xx、2xx、3xx、4xx、5xx、6xx响应1.2 SIP消息结构请求消息和响应消息都包括SIP消息头字段和SIP消息体字段；SIP消息头主要用来指明本消息是有由谁发起和由谁接受，经过多少跳转等基本信息；SIP消息体主要用来描述本次会话具体实现方式；1.3 消息格式1.3.1 请求消息格式SIP请求消息的格式，由SIP消息头和一组参数行组成，如图1-1所示。
通过换行符区分命令行和每一条参数行。
图1-1 SIP 请求消息结构注意：参数行的顺序不是固定的。
对应的参数解释见错误！未找到引用源。
消息体定义：Call-ID ：头字段是用来将消息分组的唯一性标识From ：头字段是指示请求发起方的逻辑标识，它可能是用户的注册地址。
From 头字段包含一个URI 和一个可选的显示名称CSeq ：头字段用于标识事务并对事务进行排序。
它由一个请求方法和一个序列号组成，请求方法必须与对应的请求消息类型一致Max-Fowords ：头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
呼叫建立过程中的UPDATE含义及过程分析UPDATE过程的意义
在呼叫建立过程中主叫会有一个或者多个UPDATE过程，主要是用来进行资源预留及媒体更新，比如主叫有高清语音提示或者被叫有彩铃等业务时，在呼叫建立过程中将会进行多个UPDATE过程进行媒体更新体验新业务，具体情况下面详细分析。
主被叫均无其他高清语音提示或彩铃等业务
主被叫均无高清语音提示、彩铃等业务时，主被叫在呼叫建立过程中均只有一次UPDATE过程，用来保障资源预留成功主被叫编码格式协商一致，其信令流程如下：
炎强信令包：
主叫有高清语音提示业务被叫无彩铃业务
在主叫有高清语音提示音被叫无彩铃的呼叫建立过程中，主叫一般会有3次UPDATE 过程：第一次为资源预留与被叫编码格式协商；第二次为被叫180消息发送过来后先被TAS 拦截后由TAS触发UPDATE过程通过多个网元下发给主叫UE进行媒体更改，主叫出现高清语音提示音，在此次UPDATE完成后才将INVITE 180消息透传给主叫UE；第三次还是TAS 给主叫下发UPDATE过程，目的是将媒体格式更新为与被叫一致的格式，为主叫接收INVITE 200消息做好准备。
（主叫无高清语音提示被叫有彩铃的过程与此一样）
第三次UPDATE过程有2种触发情景：情景1为主叫在听到高清语音提示音的过程中间
被叫接通并上报INVITE200消息，此INVITE200消息在TAS处触发第三次UPDATE过程，并在第三次UPDATE完成后才由SBC将INVITE200消息下发给UE；情景2为主叫播放完高清语音提示音后，TAS自主下发UPDATE过程，现网的高清语音提示音时长大概为14秒左右，也就是说被叫一直没有接通的情况下，主叫在收到INVITE180消息大概14秒后会收到网络下发的UPDATE请求。
炎强信令包：
主叫有高清语音提示、被叫有彩铃业务
对于主叫有高清语音提示、被叫有彩铃业务的终端，在进行通话过程中将有4次UPDATE 过程：第一次为资源预留与被叫编码格式协商；第二次、第三次为被叫180消息发送过来后先被TAS拦截后由TAS触发UPDATE过程通过多个网元下发给主叫UE进行媒体更改，目的是让主叫接收到高清语音提示音及彩铃声音，在第二次、第三次UPDATE完成后才将INVITE 180消息透传给主叫UE；第四次还是TAS给主叫下发UPDATE过程，目的是将媒体格式更新为与被叫一致的格式，为主叫接收INVITE 200消息做好准备。
炎强信令包：
UPDATE未正常完成导致的未接通
目前核心网的流程是在彩铃、高清语音提示的UPDATE流程完成后才能将INVITE180消息透传到主叫UE，特别是主被叫均有媒体业务时UPDATE过程更为繁琐，任何一次UPDATE 过程未完成都有可能造成未接通事件，大大增加了事件概率；后期核心网有可能对此机制进行调整，媒体更新过程可能会有所变化，实际分析时建议以实际网络为准。
上图为无线环境差造成由TAS下发的2次高清语音提示音媒体更新流程UPDATE过程均未顺利完成，导致INVITE180消息无法透传到主叫UE，从而造成主叫未接通，而此时被叫已经上报INVITE 200接通本次通话，被叫端将出现接通无声音单通问题
炎强信令包：。