VoLTE简介 下载本文

VoLTE介绍

一、 概述

由于在LTE网络中不存在交换域,全部业务都由分组域提供。目前,其语音解决方法,也就存在着双待机、CSFB和VoLTE等三种主流方案。其中,双待机和CSFB均为依托原有的2/3G网络来提供语音服务,VoLTE则使用IMS域,在LTE网络上通过VoIP方式直接提供语音服务。

双待机方案:双待机终端可以同时待机在LTE网络和3G/2G网络中,而且可以同时从LTE和3G/2G网络接收和发送信号,其语音解决方案的实质是使用传统3G/2G电路域网络,与LTE网络无关,LTE与3G/2G模式之间没有任何互操作,终端不需要实现异系统测量,技术实现简单。

CSFB方案:CSFB方案的主要思想是在用户需要进行语音业务的时候,从LTE网络回落到3G/2G的电路域重新接入,并按照电路域的业务流程发起或接听语音业务。终端空闲态下驻留在LTE网络上发起/收到呼叫时,回落到2G/3G网络,待呼叫结束后,再返回到LTE网络。

VoLTE(Voice over LTE):以LTE网络作为接入,提供了基于IMS域的语音视频业务。IMS由于支持多种接入方式和丰富的多媒体业务,成为全IP时代的核心网标准架构。与多模双待机方案和CSFB方案不同,VoLTE不在需要2/3G电路域网络的支持,3GPP和GSMA等标准化组织已将VoLTE确定为移动语音业

务演进的标准架构和目标方案。

VoLTE提供了架构在LTE网络上全IP条件下的“端到端”语音方案。VoLTE的语音作为IP数据传输,无需2G/3G网络,实现了数据与语音业务在同一网络下的统一。相对于现有的2G/3G网络,VoLTE通过引入高清编解码和QoS等技术,可拥有比2G/3G语音和OTT语音更好的用户体验。同时,当终端离开LTE覆盖区域时,VoLTE能够使用SRVCC技术将LTE上的语音呼叫切换到2G/3G网络上,保证呼叫的连续性。 1.1. 特性

VoLTE使用IMS的多媒体语音业务,与传统2/3G语音和OTT语音业务相比具有以下特点:

1、 低时延、高清音视频等业务体验:由于LTE网络“永远在线”的特点,寻呼

时长减少,使得VoLTE端到端呼叫时延较2/3G显著缩短,VoLTE端到端时延理论值仅为0.5~2s,其中语音呼叫带宽提高近1倍,话音质量更清晰。 2、 多域配合的网络架构:VoLTE由EPS提供数据承载、PCC提供QoS保障、IMS提

供呼叫控制和业务逻辑、eSRVCC技术提供至CS的切换,并采用统一融合的数据库“三合一”HSS,是一张需多域网元相互配合的网络。

3、 基于SIP协议,核心控制全IP化:VoLTE是一张全IP的网络,采用互联网应用

层SIP协议进行呼叫控制和业务触发。相对于传统的电信协议,SIP采用文本编码、定义宽松、规则简单、易于扩展,但也有协议内容冗余、兼容性问题突出等互联网协议传统缺陷。

4、 用户归属网络提供业务:区别于CS域采用拜访地网络提供业务,VoLTE由归

属地网络提供业务,以实现无论用户漫游在何地,均可保证一致的业务体验。各省可以面向本省用户提供个性化VoLTE多媒体业务。

5、 全面使用IPv6: 2/3G环境下,由于网络地址有限,当用户使用数据业务完

成以后,网络侧会将IP地址收回。在LTE环境下,用户永远在线,网络侧将不再回收IP地址。考虑IMS永远在线的特性对IP地址的巨大需求,3GPP组织则明确将IPv6确定为IMS的强制支持的协议版本。

6、 终端更复杂、更智能:VoLTE终端除继承LTE终端“多模多频”的能力外,还

集成了IMS协议栈、具备eSRVCC能力、支持多种音视频编解码方式等。不同

于2/3G“网络智能化,终端傻瓜化”的特点, VoLTE终端更复杂、更智能,成为影响时延、互通、业务的关键因素,需进行专门的维护和管理,也对未来网络优化带来很大的挑战。

1.2. 与传统的双待和CSFB对比

由于VoLTE有很强的技术优势,其在接通时延,语音和业务提供上相比传统业务有很大改进,但其网络改造大,优化覆盖难,终端支持较慢等不利因素也较为明显。下表为几种语音解决方案的简单对比

种类 实现方案 优点 缺点 同时待机在LTE网? 双待机,数据和语音可以并行 络和3G/2G网络里,? 网络无需改造,LTE与3G/2G模式多模双待 而且可以同时从LTE发送信号 之间没有任何互操作, 术实现简单 和3G/2G网络接收和? 终端不需要实现异系统测量,技? 无标准化,终端自行实现, ? 同时使用两套收发机,对终端待机有一定影响 在用户需要进行语音业务的时候,从LTE网络回落到CSFB ? 现网需要改造,优化难度大 ? 不引入IMS,重用现有的CS网络 3G/2G的电路域重? 呼叫接续时间增加 ? 终端产业链较成熟,3GPP标准化 新接入,并按照电? 语音通话期间,不能体路域的业务流程发起或接听语音业务 验LTE高速数据业务 LTE网络作为接? 多业务,低时延,高清语音 SRVCC 入,提供了基于IMS? 频谱利用率高,网络成本低 的音视频业务 ? 一套收发机,3GPP标准化 ? 核心网改造巨大,需新建众多网元, ? 对LTE覆盖要求高, ? 优化难度大 二、 系统构架与原理

2.1. 系统构架

从整体上看,VOLTE网络分为终端、接入网、承载网、核心网、业务平台。

业务平台彩铃业务平台彩印业务平台定位业务平台UtIP短信网关(IP-SM-GW)VoLTE AS/MRFCAPCAP智能网SCP业务配置代理网关核心网PCCIMS域ShSLh/SLgCx/Sh/Zh/S6a/SLhIBCF用户数据ZhJ三合一HSSC/D2G/3G电路域PCRFRx/Gx信令网MxISCSLsCxI/S/E-CSCF/BGCF/TRF/LRF/EATFDNS/ENUMMGCF/IM-MGWNc/NbMwMg/MjDRARxP-CSCF/ATCF/ATMw/I2GW/AGWGMSCNcS1-MMESGiSAE GW/GGSN/PCEF分组域Nanocell网关Gr/S6aS11/Gn/GpS6a/SLgMME/SGSNS1-UGxeMSCSv/SGs承载网承载网S1-U接入网NanocellLTE接入eNodeBS1-MMEGmUuGbBTS/BSCA2G接入终端 UEUmUt 其中,相对于传统的LTE无线网络,核心网改动较大,主要分为分组域(接入核心网)、策略控制单元(PCC)、信令网(DRA)、 IMS域、CS域、用户域 ,其中,信令网和IMS域为VoLTE专门使用。核心网中的MME,SGW,PGW在前文已经介绍,在这里将不在累述。 2.2. 设备用途

其各个设备的主要功能如下:

? 策略控制单元(PCC): Policy and Charging Control 策略与计费控

制: 提供策略控制、计费控制功能、业务数据流的事件报告等功能。 ? PCEF(Policy and Charging Enforcement Function 策略和计费执行功能):主要包含业务数据流的检测、策略执行和基于流的计费功能

? PCRF(Policy and Charging Rule Function策略和计费规则功能):包含策略控制决策和基于流计费控制的功能,PCRF接受来自PCEF、SPR和AF的输入,向PCEF提供关于业务数据流检测、门控、基于QoS和基于流计费的网络控制功能,并结结合PCRF的自定义信息做出PCC决策。

? 信令网(DRA):DRA(Diameter Routing Agent 路由代理):下一代信令

网,可以真正实现未来核心网逐步的扩展,简化网络,实现快速部署、高效维护及增强网络安全。用处:解决移动用户漫游到其他网络时,用户的鉴权、认证、位置登记、计费策略等信息在漫游网络与归属网络之间的传递。在一些业务应用场景中,保证对于同一个用户,AF和PCEF能够寻址到同一个PCRF,通过部署Diameter 代理来实现IP地址和IMSI的动态绑定以完成寻址。

IMS域在逻辑上主要分为三部分,为呼叫会话控制功能,多媒体资源功能和网关,下面分别进行介绍

? IMS域-SBC

? SBC(Session Border Control 会话边界控制器):其位于IMS网络的边界,起着将终端用户接入到IMS核心网的重要作用。它的主要功能包括接入许可控制,网络拓扑隐藏,NAT以及NAT穿越,QoS及带宽策略,和网络安全机制等。VoLTE SBC包含P-CSCF/AGW、ATCF/ATGW功能模块。

? P-CSCF(Proxy Call Session Control Function 代理会话控制功能):是IMS中用户的第一个联系点(在信令平面),从SIP的角度来看,它是一个出站/入站的SIP代理服务器,所有的SIP信令,无论是来自用户设备UE,还是发送给UE的,都必须经过P-CSCF。UE使用本地CSCF发现机制可以获得P-CSCF的地址。P-CSCF负责验证请求,将它转发给指定的目标,并且处理和转发响应。提供注册鉴权、信令保护、信令压缩、媒体授权、QoS控制、信令路由、紧急呼叫、漫游计费等功能。为支持号码补全以及紧急呼叫,P-CSCF需能识别紧急呼叫,获取用户位置信息,并在SIP信令中添加相应信息,且能将位置信息映射为区号。

? ATCF(Acess Transfer Control Functionality,接入转移控制功能 ,用于控制面)/ATGW(Access Transfer Gateway,接入转移网关,用于媒体面),该网元为eSRVCC新增网元,是VoLTE用户在当前所在网络的信令面和媒体面的锚定点,在发生eSRVCC时将VoLTE用户接入侧的媒体面从LTE切换到电路域,以减少切换时长。

? IMS域-CSCF:,

? S-CSCF(Serving Call Session Control Function 服务会话控制功能): 是IMS的核心所在,它位于归属网络,负责对UE的注册鉴权和会话控制,执行针对主叫端及被叫端CM-IMS用户的基本会话路由功能,并根据用户签约的IMS业务触发规则,在条件满足时进行到AS的业务触发。但当UE处于会话中时,S-CSCF处理网络中的会话状态。在同一个运营商的网络中,可以有多个S-CSCF。 ? I-CSCF(Interrogating Call Session Control Function 协商会话控制功能):运营商网络内部的接触点,所有与这个网络运营商的用户连接都要经过这个实体,CM-IMS域的边界点,其主要功能包括指派S-CSCF、PSI路由功能、Transit功能等。I-CSCF不要求做拓扑隐藏。在一个网络中可以有多个I-CSCF。

? E-CSCF:从P-CSCF接受紧急会话建立请求,并完成用户接入位置信息查询和紧急呼叫路由等功能。

? BGCF:IMS到CS的呼叫路由,BGCF收到来自S-CSCF的呼叫请求后根据本地配置选择合适的MGCF进行转发。

? LRF:E-CSCF提供路由信息(紧急呼叫中心的SIP URI和TEL URI)和其它根据管制要求、紧急呼叫应提供的参数(比如用户位置信息TAI)。当LRF与E-CSCF合设时,用户位置信息和路由信息需配置在E-CSCF中。

? EATF:作为紧急呼叫的锚定点,提供紧急呼叫的SRVCC,保证紧急呼叫的语音连续性。

? IMS域-MGW/MGCF

? MGCF(Multimedia Gateway Control Function 多媒体网关控制功能):在ISDN部分(ISUP)和IMS呼机控制协议之间执行协议转换,用于IMS域与CS域的互通,负责完成控制面信令的互通(PSTN/CS域侧ISUP/BICC协议与CM-IMS侧SIP协议的交互和互通),并控制IM-MGW完成用户面媒体面的互通、号码规整、号码分析和路由、放音、放音抑制、视频回落等功能。

? IM-MGW(IP Multimedia Gateway IP多媒体网关):负责IMS与PSTN/CS域之间的媒体流互通,提供CS CN网络和IMS之间的用户

面链路,支持PSTN/电路域TDM承载和IMS用户IP承载的转换。主要功能是承载和媒体处理。在IMS终端不支持CS端编码时IM-MGW完成编解码的转换工作。MGCF的控制下完成VoLTE用户面IP承载与CS域承载之间的转换,提供编解码转换、承载资源管理和放音功能。 ? HSS:VoLTE中的HSS是HLR/AuC、IMS-HSS、EPS-HSS三合一融合设备,统一存储VoLTE用户在2/3/4G及IMS的用户数据,处理2/3/4G及IMS网络中呼叫控制网元对用户的数据访问,还通过开通接口接收并响应BOSS业务开通指令。在移动网络中,一般从HLR升级而来。 ? eMSC: 针对SRVCC的增强MSC,支持普通呼叫的eSRVCC、aSRVCC和mid-call SRVCC以及紧急呼叫的SRVCC,一般在一个MSC POOL中会升级1-2个MSC用作eMSC。 下表为VoLTE各个网络接口表: 功能域 接口名称 S1-MME S1-U S11 分组域 SGi SLg SLs Sv Rx PCC Gx Gm Mw Mx Mg IMS域 Mj Mw/I2 ISC 信令 信令 信令 信令 信令 信令 信令 信令 PCRF-SAE GW Diameter 接口类型 信令 数据 信令 数据 信令 信令 信令 信令 连接网元 MME-eNodeB SAE GW-eNodeB MME-SAE GW SAE GW-VoLTE SBC MME-LSP(GMLC) MME-LSP(eSMLC) MME-eMSC PCRF-VoLTE SBC 承载协议 GTP-C GTP-U GTP-C 应用层协议 Diameter SCTP GTP Diameter VoLTE UE-VoLTE SBC SIP VoLTE SBC-xCSCF xCSCF-IBCF SIP SIP I-CSCF/S-CSCF-MGCF SIP BGCF-MGCF xCSCF-eMSC xCSCF-IMS AS VoLTE UE/VoLTE AS-业务配置代理网关 三合一HSS-xCSCF 三合一HSS-IMS AS 三合一HSS-业务配SIP SIP SIP Ut 信令 XCAP Cx 用户数据 Sh Zh 信令 信令 信令 Diameter Diameter Diameter 置代理网关 SLh S6a C/D 信令 信令 信令 三合一HSS-LSP 三合一HSS-MME 三合一Diameter Diameter MAP HSS-eMSC/GMSC 三合一HSS——IP-SM-GW MSC-MSC IMS SSF/MSC-智能网SCP SGSN-三合一HSS J Nc 2G/3G电路域 CAP Gr 信令 信令 信令 信令 MAP BICC Camel MAP 2.3. 协议栈

和传统的LTE数据业务相似,VoLTE的协议栈也分为信令面和用户面。要实现语音或视频业务需要UE同时建立三个数据承载外,还需要UE建立RRC链接信令承载:SRB0,SRB1和SRB2。其协议栈总体结构如下:

业务 承载 SRB0 QCI / / / 8,9 5 1 / / / 8,9 5 1 2 用途 RRC连接建立过程,不加密和完整性保护 RRC重配消息,有加密和完整性保护 承载NAS信令, 有加密和完整性保护 一般数据业务 SIP信令 语音包 RRC连接建立过程,不加密和完整性保护 RRC重配消息,有加密和完整性保护 承载NAS信令, 有加密和完整性保护 一般数据业务 SIP信令 语音包 视频包 VoLTE的语音电话 SRB1 SRB2 AM-DRB AM-DRB UM-DRB SRB0 VoLTE的视频电话 SRB1 SRB2 AM-DRB AM-DRB UM-DRB UM-DRB 其中SRB0,SRB1,SRB2,AM-DRB(QCI=8,9)为一般LTE数据业务需建立的承载,UM-DRB(QCI=2)为VoLTE视频业务专用承载.UM-DRB(QCI=1)为VoLTE语音专业承载,AM-DRB(QCI=5)为IMS信令专用承载。 2.4. VoLTE的控制面协议栈

VoLTE的控制面协议分为用于承载控制的LTE协议和用于业务控制的SIP协议,前者发生在PS域上,后者发生在IMS域上。由于用于承载的LTE协议栈和传统业务没有区别,故不再累述。下面主要介绍,用户业务控制的IMS域协议栈。

1. SIP(Session Initiation Protocol,会话初始协议):是一个基于文本的应用层控制协议,用于创建、修改和释放一个或多个参与者的会话。

2. SDP: ( Session Description Protocol 会话描述协议):为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述。

3. SIP/SDP是用来传输SIP/IMS信令的,需要在承载中建立优先级最高QCI=5(QCI并非是数字小来决定其优先级),无线侧用户名RLC采用AM模式,保障其正确性;

4. SIP/SDP流建立在UDP/IP之上,用于终端之间应用控制。SIP流用于发起一个Session,并负责传输SDP包;而SDP包中描述了一个Session包含哪些媒体数据,邀请人;

2.5. VoLTE的用户面协议栈

和信令面协议类似,VoLTE的用户面协议也可以区分为承载层和业务层,其和QQ微信等OTT厂家的VoIP协议类似。

1. RTP(Realtime Transport Protocol实时传输协议):被定义为在一对一或一对多的传输情况下工作,其目的是提供时间信息和实现流同步。RTP本身只保证实时数据的传输,并不能为按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些服务。

2. RTCP(Realtime Transport Control Protocol实时传输控制协议):负责管理传输质量,在当前应用进程之间交换控制信息,提供流量控制和拥塞控制服务。RTP和RTCP配合使用,能以有效的反馈和最小的开销使传输效率最佳化,故特别适合传送网上的实时数据。 3. RTP/RTCP用来传输用户媒体信息的,需要在承载中建立优先级最高QCI=1/2(其语音业务建立QCI=1,视频业务建立QCI=2),根据其低延迟要求,无线侧用户的RLC数据包采用UM模式,保障其实时性,其正确性通过HARQ来实现;

4. RTP/RTCP流建立在UDP/IP之上,当被邀请人通过各自终端设备接到邀请通知以后,就可以使用RTSP来控制特定的媒体通信。比如RTCP 控制视频/音频的播放,使用RTP协议来进行实时的数据传输,在传输过程中,RTCP负责QoS。

三、 与现有语音解决方案对比

在这里,分别用VoLTE与传统的GSM语音,OTT的VoIP语音进行对比。

3.1. VoLTE窄带与宽带语音质量对比

在3GPP LTE中,VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码,两种编码速率具有不同的话音质量,所以又分别称为VoLTE高清语音(或VoLTE 23.85kbps)和VoLTE标清语音(或VoLTE 12.2kbps)。

AMR-NB和AMR-WB这2种编码具有如下特点:

? 每20ms产生一个语音包,包括了RTP/UDP/RLC-Security压缩头,每160ms生成一个SID语音静默包,帧长20ms;

? 共有8个编码速率,分别为:4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps; ? 采样率为8kHz。 AMR-WB编码特点为:

? 语音包和静默包产生与AMR-NB类似,20ms产生一个语音包,160ms产生一个静默包;

? 共有8个码率,分别为:6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps; ? 采样率为16kHz。

可见两者显著的主要差异是采样速率不一样,窄带一个语音帧是160个点,宽带一个语音帧采样320个点。AMR NB的语音带宽范围:300-3400Hz,8KHz采样。AMR WB的语音带宽范围: 50-7000Hz,16KHz采样。用户可主观感受到话音比以前更加自然、舒适和易于分辨。

为了降低复杂度,AMR WB将位算法集中到更重要的频率区。低频带使用ACELP算法进行编码,添加几个特征来达到一个高的主观质量。线性预测(LP)

算法是在每隔20ms 的帧要进行一次线性预测算法,每5ms搜索一次自适应码本,这个过程是在12.8Kbs 速率下进行。高频带是在解码器端使用低带和随机激励的参数重建的, 目的是调整与在声音基础上的低频有关的高频带. 高频带的声频通过使用由低带LP 过滤器产生的LP 滤波器进行重建。

AMR WB与AMR NB的MUSHRA评分(multi-stimulustest with hidden reference and anchor,ITU-R recommendation BS.1534.)参考见下图。

利用传统的MOS值进行AMR-NB和AMR-WB进行对比测试,结果如下图:

5.004.504.003.503.002.502.001.501.000.500.004.324.184.164.144.284.14.254.084.054.224.053.93.853.73.63.53.6AMR-WBAMR-NB23.85, 12.223.05, 10.219.85, 7.9518.25, 7.415.85, 6.714.25, 5.912.65, 5.158.85, 4.756.6 由以上分析可见AMR-WB比AMR-NB有更高的话音质量。

3.2. VoLTE与GSM语音质量比较

现场使用POLQA SWB作为评分标准,评估GSM,VoLTE(23.85kbps)和VoLTE(12.65kbps)三种通话的语音质量。相比传统的PESQ标准,POLQA标准对宽带

适应能力更好,PESQ无法使用8Khz以上采样频率,其主要区别如下:

VoLTE MOS相比GSM有较大改善,MOS评分参见下表。

语音拨打类型 2G打2G MOS(POLQA SWB) 2.64 VoLTE(23.85kbps) 3.98 VoLTE(12.65kbps) 3.84 2G使用窄带语音AMR-NB 12.2k和EFR编码方式,使用POLQA SWB评分时会比传统PESQ评分会低,具体映射关系如下:

表从上可以看出:AMR(12.2k)/EFR POLQA评分先比PESQ评分低0.5分左右。

按照上表,将2G打2G MOS(POLQA SWB)折算为PESQ MOS分应为2.64+0.5=3.14分。分析2G MOS分值,大量2分MOS分值对应的语音编码方式为EFR,AMR 12.2k编码MOS分一般在3分左右。

POLQA SWB评分按照64Kbps采样率进行语音质量评分,评分标准比传统PESQ高。同样的2G语音POLQA评分先比PESQ评分低0.5分左右。

3.3. VoLTE与OTT语音质量比较

在这里,选择有代表性的腾讯公司的微信电话本的VoIP电话进行对比,其具有低接通时延、无通信费用(仅有流量费用)和高清晰音质等特点。

VoLTE试点区域内共有4G基站400个,主覆盖区域为D频段,覆盖良好。使用设备为ASCOM公司的TEMS16.1.3,测试手机为HTC M8t。

3.3.1. 音质对比分析

从现有的PDCP层速率和MoS进行推测,OTT语音采用的编码为skype的SILK Codec。SILK Codec是一个语音和音频编解码算法, 对于音频带宽、网络带宽和算法复杂度都具有很好的弹性,支持4种采样率:8KHz、12KHz、16KHz、24KHz;三种复杂度:低、中、高。编码码率在 6~40kbps(不同采样率具有不同的码率范围)以及还支持VAD、DTX、FEC等模块,已经在QQ,AIM,GOOGLE TALk上使用,性能在高掉包环境下优于AMR-WB。

为适应其编码方式,这里采用的打分标准使用基于48K采样的POLQA。OTT语音在好点(-88.33dbm,12.67)下,其MoS可以达到3.78,在坏点为1.93。在坏点的条件下,其时延,抖动,丢包都在急剧上涨,用户感知急剧降低。而VoLTE具备QoS保障,其MOS比较稳定,无明显波动,祥见下表。

类型 微信电话本 VoLTE SINR -0.09 0.02 物理层速PDCP速率率(下行) (下行) 50.48 15.61 36.23 10.44 传输模式 MCS 2.00 2.15 6.31 4.95 每TTI RB数 11.94 8.78 总调度RB数 910.89 227.22 TB size 668.44 590.79 为进一步对OTT语音的语音MOS值进行分析,找出其能力拐点,优化人员

对其RSRP的从-125dbm到-110dbm,SINR从-4到10的范围进行测试,详见下图。

语音 VoLTE 23.85 AMR封装负荷 RTP UDP IP 477+21 96 64 40 PDCP头 RLC头 MAC头 Total 8 8 16 16 1010 570 320 8 8 VoLTE 23.85(RoHC) 477+21

微信和VoLTE的RSRP走势对比543210-125-124-123-122-121-120-119-118-117-116-115-114-113-112-111微信-MOSVoLTE-MOS1.88 2.15 1.79 1.78 1.78 1.78 1.98 1.90 1.74 1.74 1.71 1.88 1.57 1.51 2.62.92.92.92.933.33.33.43.43.53.63.63.73.7433.22 210 从RSRP走势中可以看出:在RSRP>-110dBm,SINR >10的在LTE轻载网络环境下,MOS可以保持在3.5以上。当RSRP>-111dBm的时候,语音质量会出现大幅提升,MoS会大于3.22,已经超过了GSM的MoS,其音质和VoLTE AMR-WB在感知上差异不大。

微信和VoLTE的SINR走势对比43210-5-4-3-2-101234VoLTE56789101.83 1.82 1.91 1.76 1.84 1.87 2.01 2.30 2.85 2.55 2.59 2.53 3.53.63.63.63.63.73.73.73.83.83.83.83.83.83.83.83.80 3.50 3.70 3.19 微信-MOS 从SINR走势中可以看出,其在3的时候,其质量会出现大幅提升,MoS会到2.85以上,已经其超过GSM的EFR的MoS,当SINR提升到9的时候,其值已经和VoLTE差距不大。

下图4个波形分为标准语料,GSM波形,VoLTE波形和微信波形。微信语音压缩方法与2G/4G不一样,OTT语音对标准语料毛刺部分压缩比较干净,将标准语音样本中的背景噪声被简单给过滤掉了,故MOS峰值较低。在同样的MOS

分下,用户可能会觉得OTT语音更加干脆清澈。

3.3.2. 容量对比分析

OTT语音采用SLIK编码,具备VAD、DTX、FEC能力,具备不连续发射,静默期检查,前向纠错能力。微信电话本传输效率要低于VoLTE。下表为微信电话本和VoLTE在好点时候的资源占用情况。

下行 类型 SINR 物理层速率(kbps) PDCP速率平均MCS (kbps) RB数 (bite) TB size上行 物理层速率(kbps) PDCP速率MCS (kbps) RB数 (bite) TBsize微信电18.26 58.14 40.27 19.77 3.28 1268.24 52.76 40.33 22.45 2.5 1285.14 话本 VoLTE 20.02 18.2 11.13 15.26 2.8 819.47 21.82 11.21 22.01 1.68 1086.69 微信电话本和VoLTE高清语音的网络好点资源占用对比

OTT语音每TTI调度RB数和VoLTE(23.85k)基本近似,微信没有语音静默包,每TTI调度次数明显高于VoLTE,微信语音总调度RB数明显高于VoLTE。

OTT语音和VoLTE高清语音的网络差点资源占用对比(下行)

类型 微信电话本 VoLTE SINR -0.09 0.02 物理层速PDCP速率率(下行) (下行) 50.48 15.61 36.23 10.44 传输模式 MCS 2.00 2.15 6.31 4.95 每TTI RB数 11.94 8.78 总调度RB数 910.89 227.22 TB size 668.44 590.79 OTT语音走默认承载,没有RoHC功能,语音包大于VoLTE,与不打开RoHC的 VoLTE语音包相似)。RoHC功能开启对VoLTE语音包压缩参见下表。

语音 VoLTE 23.85 AMR封装负荷 RTP UDP IP 477+21 96 40 64 PDCP头 RLC头 MAC头 Total 8 8 16 16 1010 570 320 8 8 VoLTE 23.85(RoHC) 477+21 微信电话本语音包大小与SINR关系2000 1500 1000 500 0 -6-303691215包大小(byte)1,2801,08088068048028080微信电话本语音包大小与RSRP关系-128-123-118-113-107-102包大小(bite) OTT语音没有语音静默包,不具备头压缩功能,导致PDCP速率(40k左右)高于VoLTE(10k左右)。按好点的包大小计算,OTT语音每分钟消耗流量为(40.27+40.33)*60/8=600kbyte,其通话一个小时占用流量为35Mbytes。

在差点时,微信语音掉包和时延会恶化,资源占用会加大。从现网测试情况看:在-110dbm,SINR=0的情况下,会占用12个RB,资源占用增加了三倍,VoLTE占用9个RB。在资源紧张时,VoLTE有QoS保障机制,语音各项指标会远好于OTT语音。

从无线环境和OTT语音包大小进行走势对比,可以清楚的发现:当其无线环境好的时候,其语音包较大,语音采样编码方式越高,语音越清晰,用户感知越好。当无线环境恶化时,语音采样编码方式变差,用户感知不好。 四、 信令流程

VoLTE的信令流程非常复杂,其主要可以分PS域(承载建立过程)和IMS域(业务建立过程)。

PS域,承载建立过程,主要是指语音承载的建立,其涉及网元主要是传统的LTE的PS域,为RRC,ERAB和NAS层信令,除去QCI和PCC有所不同以外,和传统上网业务区别不大。

IMS域,负责业务建立,释放过程,该过程为在承载建立以后的业务建立,主要涉及IMS域,相当于IMS的IP电话流程。

-84-90下面,将分信令流程几个阶段进行分别介绍。

4.1.

SIP协议介绍

在VOLTE中引入了IMS,对VOLTE进行业务控制,MME只是做为业务的承载体,IMS对业务的控制全部通过SIP消息完成,在学习VoLTE的过程中必须学习SIP消息。

SIP:Session Initiation Protocol -会话发起协议,是IETF制定的多媒体通信协议,它是一个基于文本的应用层控制协议,独立于底层协议,用于建立、修改和终止IP网上的双方或多方的多媒体会话。SIP是端到端的协议,采用请求/响应机制,可以用UDP,TCP等传送。

SIP消息是文本格式的,分为请求和响应两类:

? 请求消息:用于客户端为了激活按特定操作而发给服务器的SIP 消息,一般为上行消息。

? 响应消息:用于对请求消息进行响应,指示呼叫的成功或失败状态,一般为下行消息。

SIP消息格式由一个起始行,若干个头子段以及可选的消息体组成。请求和响应的起始行不同,请求的起始行为请求行(Request-Line),响应的起始行为状态行(Status-Line)。 4.1.1. SIP请求消息

VOLTE常用的请求消息包括下列几种

SIP方法 INVITE ACK BYE OPTIONS CANCEL REGISTER PRACK SUBSCRIBE NOTIFY UPDATE PUBLISH INFO REFER MESSAGE 描述 表示一个客户端发起或被邀请参加电话会议 确认客户已经收到一个INVITE请求的最终响应 终止一个呼叫,可以由主叫或被叫方发起 查询服务器的能力 取消所有正在处理中的请求 向标题字段中的SIP服务器发起地址列表注册 临时确认 向服务器订阅某个事件通知 向订阅都发送一个新的事件 在没有修改对话状态的情况下修改会话 发布一个事件到服务器 会话过程中发送一个会话消息,但不修改会话状态 请求收件人发出SIP请求 使用SIP传输即时消息

上图典型的请求消息,invite消息,即为呼叫发起。

请求消息的起始行为请求行(Request-Line)。请求消息头至少包括From、To、

CSeq、Call-ID、Max-Forwards、Via六个头字段,它们是构建SIP消息基本单元

请求行的格式如下所示,由方法名,请求URL和协议版本组成,各部分之间均用一个空格字符进行分隔。请求行必须用回车换行(CRLF)字符终结。

Request-Line = Method SP Request-URI SP SIP-Version CRLF Method:方法表示该请求消息的目的。常用的方法有INVITE,ACK,BYE,CANCEL,REGISTER,PRACK。INVITE,ACK用于建立会话,BYE用于释放会话,CANCEL用于取消还未建立的会话,REGISTER用于向软交换注册SIP用户的IP地址,PRACK用于确认收到了INVITE的临时响应。

Request-URI:请求发送到的目的URI。

SIP-Version:用于定义协议当前的版本号,目前的协议版本号为SIP/2.0。

4.1.2. SIP响应消息

响应消息包含数字响应代码,SIP响应代码集部分基于HTTP响应代码。

响应消息的起始行为状态行(Status-Line),状态行由协议版本,状态码和与状态码相关的文本描述组成,各个部分之间用一个空格字符分隔。状态行的格式如下所示:

Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF Status-Code:状态码是一个3位的十进制整数,取值范围为100---699,用于表示请求消息的响应结果。状态码的第1位数字表示响应类型,后两位数字表示具体的响应。100---199是临时响应,200---699是最终响应。通常情况下,一个请求只能收到一个响应,即为最终响应,而INVITE请求可以收到多个临时响应和一个最终响应 响应码反馈如下

? 1XX:临时响应,请求消息正在被处理。

? 2XX:成功响应,请求已被成功接收,完全理解并接受。 ? 3XX:重定向响应,请求需要重新发送到其他的目的地址。 ? 4XX:客户机错误,请求包含语法错误或服务器无法完成该请求。 ? 5XX:服务器错误,服务器无法完成合法请求。 ? 6XX:全局故障,任何服务器无法完成该请求。

常用的响应码如下: 响应码 100 180 181 182 183 200 400 401 403 404 407 480 内容 Trying Ringing Call Queued Session Progress OK Bad Request Unauthorized Forbidden Not Found Proxy Authentication Required Temporarily Unavailable Is Being Forwarded 含义 表明下一跳服务器已经收到INVITE请求。客户端收到该响应停止重发INVITE请求。 被叫振铃。 呼叫被前转 呼叫等待 表示呼叫正在处理,通常用来传递呼叫处理的信息 请求成功 请求消息有语法错误 表示请求消息需要用户鉴权 表示请求被禁止,用户没有权限。 表示找不到被叫 表示请求消息需要用户鉴权 表示被叫临时不可用 486 487 500 503 Busy Here Server Internal Error Service Unavailable 表示被叫忙 表示服务器端内部错误 表示服务器过载或正在维护导致暂时不能处理该请求 Request Terminated 表示请求被CANCEL或BYE终止 4.1.3. SIP信令的消息头

头字段格式:头字段由字段名和字段值组成,字段名和字段值之间用冒号分隔。 常用头字段:

? To:表示请求消息的目的接收者,SIP URI或TEL URI格式。在请求消息中,

除了REGISTER请求外,通常To和Request-Line相同。 ? From:表示请求消息的发起方,SIP URI或TEL URI格式。

? Call-ID:用来消息分组的标识,在一个会话中,一个用户发送的所有请求

和响应消息都必须有相同的Call-ID。

? Contact:消息发送方的联系地址,SIP URI格式。

? CSeq:消息的顺序编号。这在一次对话或一个Call-ID中是惟一的。这用于

区别新的消息和“重试消息”。当一条初始消息没有及时OK时,重试就会进行,并会定时发送。

? Content-Type:消息内payload的MIME类型。

? Content-Length:payload的大小,以字节为单位。信封和payload之间由一

空行隔开。

4.1.4. SIP信令的消息体

消息体的类型由Content-Type头字段定义,最常用的是application/sdp,也就是会话描述协议(Session Description Protocol)。消息体的长度由Content-Length头字段定义。

下表为常见SDP协议中的字段含义。其中a=,b=会同时存在多个。*为非必选参数,可根据需要在IMS域中选择开启,从现网来看,i,c,a,b存在。VoLTE专属,表明其在VoLTE网络中存在,在一般的IMS域的固话呼叫中,会没有。

类别 字段 v = o = s = i = u = e = 会话描述 p = c = b = z = k = a = 时间描述 t = r = m = i = c = b = k = a = VoLTE专属 中文含义 协议版本 所有者/创建者和会话标识符 *会话名称 * 会话信息 * URI 描述 * Email 地址 * 电话号码 * 连接信息 ― 如果包含在所有媒体中,则不需要该字段 * 带宽信息 * 时间区域调整 * 加密密钥 * 0 个或多个会话属性行 会话活动时间 * 0或多次重复次数 媒体名称和传输地址 * 媒体标题 * 连接信息 — 如果包含在会话层则该字段可选 * 带宽信息 * 加密密钥 * 0 个或多个会话属性行 媒体描述 P-Access-Network-Info 无线承载信息 Security-Verify 安全信息 Proxy-Require Require P-Preferred-Identity P-Preferred-Service P-Early-Media Allow Route 代理请求 代理请求 主叫信息 首选服务器 提早呼叫信息 允许的事件 路由

4.2.

EPC附着与IMS注册

要进行VoLTE通话就必须首先在IMS域上进行注册,其发挥的作用和GSM通话中要先在MSC上注册是相似的。终端首先会进行EPC网络的附着,之后进行IMS域的注册和鉴权。一般来说,和普通数据业务不同,IMS业务会使用不同APN,IMS会使用独立APN来进行专用承载的建立。

? 开机附着与数据默认承载建立:VoLTE终端开机后发起LTE附着过程后,将根据签约首先建立数据默认承载(APN=CMNET,QCI=9) ? IMS默认承载建立:VoLTE终端LTE附着完成后,根据网络能力发起IMS连接建立请求,为VoLTE信令建立IMS默认承载( APN=IMS,QCI=5 ),SAE-GW根据SBC动态选择策略向UE返回SBC/P-CSCF地址(即IMS域入口地址)

? IMS注册过程:IMS默认承载建立后,VoLTE终端通过P-CSCF向IMS核心网发起注册与鉴权过程,以实现IMS域对后续呼叫控制和业务能力的支持;S-CSCF发起第三方注册,向VolTE AS更新STN-SR,之后VOlTE AS通过HSS向MME下发STN-SR,实现后续SRVCC操作相关信息的传递。

基本流程:

1. 用户开机进行EPC附着

2. 使用IMS APN建立PDN连接,并为用户建立QCI=5的默认承载 3. 终端通过上述默认承载发起IMS注册请求并完成IMS核心网注册 4. S-CSCF发起第三方注册,向VolTE AS更新STN-SR,之后VOlTE AS 通

过HSS向MME下发STN-SR

UE1.Attach RequesteNBMMES/PGWPCRFHSSSBC/ATCFI-CSCFS-CSCFTAS2.Attach Request3.Identity Request4.Identity Response5.Authentication/Security6.Authentication/Security7.Update Location Request(Homogeneous Support of IMS Voice over PS Sessions)8.Update Location Answer9.Create Session Request(APN=CMNET)10.CCR11.CCA(QCI=9)12.Create Session Response(QCI=9)13.Initial Context Setup Request/Attach Accept14.RRC Connection Reconfiguration/Attach Accept15.RRC Connection Reconfigurationn Complete16.Initial Context Setup Response17.Direct Transfer/Attach Complete18.Attach Complete19.Modify Bearer Request21. UE decide to create IMS PDN connection20.Modify Bearer Response22. PDN Connectivity Request(APN=IMS, PCO:P-CSCF addr )23.Create Session Request(APN=IMS, PCO: P-CSCF addr request)24.CCR25.CCA(QCI=5)26.Create Session Response(QCI=5, PCO:P-CSCF addr)27.Initial Context Setup Request/PDN Connectivity Accept(PCO: P-CSCF addr)28.RRC Connection Reconfiguration/PDN Connectivity Accept(PCO:P-CSCF addr)29.RRC Connection Reconfigurationn Complete30.Initial Context Setup Response31.Direct Transfer32.PDN Connectivity Complete33.Modify Bearer Request34.Modify Bearer Response35.REGISTER (IMPI=IMSI@ims.mnc000.mcc460.3gppnetwork.org, IMPU=sip:IMSI@ims.mnc000.mcc460.3gppnetwork.org)36.REGISTER37.UAR38.UAA(S-CSCF cap set)39.REGISTER40.MAR41.MAA(RAND,IK CK,XRES,AUTN)42.401(RAND,IK CK,XRES,AUTN)43.401(RAND,IK CK,XRES,AUTN)44.401(RAND,AUTN)45.REGISTER (RES)46.REGISTER (RES,STN-SR)47.UAR48.UAA(Stored S-CSCF)49.REGISTER (RES,STN-SR)50.SAR51.SAA(user profile)52.REGISTER(original REGISGTER message)53.200 OK54.200 OK55.200 OK56.200 OK57. UDR58.UDA(SRVCC capability)59.MESSAGE (ATU-STI,C-MSISDN)60.MESSAGE (ATU-STI,C-MSISDN)61.200 OK[to MESSAGE]62.200 OK[to MESSAGE]63.PUR(STN-SR)64.PUA65.IDR(STN-SR)66.IDA

? 1~2 UE发起EPC附着请求。 ? 3~6 EPC网络对用户进行认证鉴权。

? 7~8 认证通过后,MME向HSS进行用户的EPC位置更新,并告知HSS IMS Voice homogeneous support。

? 9 MME根据用户签约发起默认PDN连接建立(默认APN为CMNET APN) ? 10~11

SAE GW向PCRF获取默认规则,PCRF返回QCI=9。

? 12~20 完成默认承载建立后续流程。

? 21 UE在发起IMS注册前需要建立IMS PDN连接。

? 22 UE发起新的PDN连接建立请求,其中携带APN为IMS,PCO获取P-CSCF地址。

? 23 MME向SAE GW发起PDN连接建立请求,其中携带APN为IMS,PCO获取P-CSCF地址。

? 24~25 SAE GW向PCRF获取默认规则,PCRF返回QCI=5. ? 26 SAE GW返回PDN连接建立响应,其中包含P-CSCF地址 ? 27~34

完成IMS PDN连接建立后续流程

? 35 UE通过IMS PDN默认承载发起IMS 注册请求,其中包含通过IMSI导出的IMPU/IMPI

? 36 SBC中的ATCF功能决定锚定后续呼叫,分配一个STN-SR指向自己,并将STN-SR携带在注册请求中发送到S-CSCF,注册请求经SBC转发至I-CSCF; ? 37~38

I-CSCF向HSS发起查询,HSS返回S-CSCF的能力集

? 39 I-CSCF根据HSS返回的能力集选择S-CSCF并向其转发注册请求 ? 40~41 ? 42~44 ? 45~49 ? 50~51 ? 52~53

S-CSCF向HSS查询用户的鉴权信息 S-CSCF向UE返回401响应,发起鉴权挑战 UE计算鉴权结果后再次发起注册请求

UE鉴权通过,S-CSCF向HSS获取用户签约信息

S-CSCF向AS发起第三方注册,并在其中携带UE发起的核心网

注册请求消息,并携带SBC分配的STN-SR ? 54~56 ? 57~58 ? 59~62

S-CSCF向UE返回注册成功响应

SCC AS从HSS中读取用户数据,判断终端是否支持SRVCC AS根据三方注册消息中的ATCF management URI向其发送

MESSAGE请求,包含ATU-STI和C-MSISDN ? 63~64

SCC AS需要比较本地配置的STN-SR和三方注册请求中携带

的STN-SR是否一致,如果不一致,则更新HSS中存储的STN-SR ? 65~66

HSS向MME推送STN-SR

无线侧信令

? Activate Default EPS Bearer Context Request:该信令是用于建立QCI=5的默认承载,所有SIP信令都通过QCI=5的承载传输,该信令的内容已在该信令前的RRC重配置中附带下来

? REGISTER(1ST Sip Register Request)& REGISTER 401(Unauthorized):是用于网络注册,建立关联,这是用户的第一个REGISTER REQUST信令,所以鉴权方面部分内容为空,需要网络回应后才能补齐,REGISTER 401信令是用于向终端回送401Unauthorized 质询信息,其中包含安全认证所需的令牌,令牌对应用户第一个REGISTER REQUST信令中鉴权摘要为空的部分,并指明算法

? REGISTER(2nd Sip Register Request)®ISTER 200:第二条Register信令是终端将用户标识和密码根据安全认证令牌加密后回送给服务器,REGISTER 200信令是用是确认注册流程完成,并生成SIP-URI和TEL URI

? SUBSCRIBE&NOTIFY:用来请求对方节点的当前状态以及后续状态变化的请求方法,从网络订阅消息,NOTIFY是用于向服务器请求返回当前状态消

息。网络通过NOTIFY向UE发送订阅的内容,UE通过NOTIFY 200确认已收到

4.3.

VoLTE呼叫流程

VoLTE的呼叫信令,是VoLTE信令中非常重要,也是很复杂的部分,其涉及流程长,牵涉网元多,认证和鉴权也比较繁琐。为便于理解,本文先给出简单的业务执行流程,再给出网元信令节点流程。其中,网元信令节点流程分为PS呼叫流程和SIP信令流程。

4.1.5.

VoLTE呼叫流程-业务性能流程

1. 主叫发起呼叫,信令路由至被叫域

2. 被叫侧触发VoLTE AS进行被叫域选择,根据HSS返回的信息决定在IMS

进行呼叫

3. 信令路由至被叫终端

4. 被叫接听后返回200 OK响应,被叫SBC根据INVITE和200 OK中的SDP

信息向PCRF申请资源,PCRF通知EPC预留资源 5. 资源预留成功后,被叫SBC向主叫转发200 OK响应

6. 主叫SBC收到200 OK响应后根据INVITE和200 OK中的SDP信息向PCRF

申请资源,PCRF通知EPC预留资源

7. 资源预留成功后,主叫SBC向主叫终端转发200 OK响应 8. 媒体链接建立

Attach--路测软件界面

PDN链接--路测软件界面

IMS注册-路测软件界面

4.1.6. VoLTE呼叫流程-网元信令流程

为给出整个业务流程,本文假设主被叫用户均进入IDLE模式,未进行MME和IMS注册。

具体流程如下。

1. 用户A和B在注册成功后,无业务触发,MME发起上下文释放,将A和B

均置为IDLE模式。

2. UE A呼叫UE B,此时A发现其为IDLE模式,则需要先建立信令连接。

首先缓存需要发送的数据,向eNodeB发起RRC Connection Request,携带初始UE ID和S-TMSI(第一次是随机值,此时TMSI值应为有效)。 3. eNodeB向UE回复RRC Connection Setup,其中携带无线资源专用配置

信。

4. UE向eNodeB回复RRConnection Setup Complete,确认RRC建立成功完

成。其中携带选择的PLMN ID,注册的MME信息(plmn-id、mmegi、mmec),NAS消息(Service Request)。

5. eNodeB发送Initial UE Message到MME,其中携带eNodeB UE S1AP Id,

TAI,E-UTRAN -CGI,RRCEstablishment Cause, NASPDU为Service Request。

6. MME侧用户面承载建立成功后向eNodeB返回Initial Context Setup

Request,携带MME UE S1AP Id ,ERAB相关信息(QOS, GTP-TEID ,ERAB Id,IP),UE安全能力和安全密钥,如果存在UE无线能力,也需要带回。如果没有UE无线能力,则eNodeB需要向UE所要UE无线能力参数。

7. 无线承载的建立,对上下文进行处理,eNodeB向UE发送RRCConnection

Reconfiguration消息,其中包含测量配置,移动性配置,无线资源配置(RBs,MAC主要配置,物理信道配置),NAS信息和安全配置等信息。 8. eNodeB收到UE的RRC Connection Reconfiguration Complete消息,确

认无线资源配置完成。

9. eNodeB向MME发送Initial Context Setup Response消息,将eNodeB

侧承载的IP和GTP-TEID带给MME。在重配完成后,实际上已经可以发送上行数据了。此时,完成建立EPS数据业务连接(QCI8/9承载),即完成在EPC侧的注册;以及IMS的注册(QCI5承载) 。

10. 用户A发送上行数据,呼叫用户B,首先向AS服务器发送INVITE请求,

LTE系统中会以数据的方式进行传输,用户A发送上行数据到AS服务器,其中携带SIP信令INVITE请求。

11. AS服务器发送100 Trying的确认消息给用户A,确认收到INVITE消息.。 12. 同时转发INVITE到用户B,发送下行数据首先经过PDN网关到SGW网关。 13. SGW发现UE B为IDLE模式,发送下行数据到的通知到MME, 同时缓存

数据。

14. MME对UE B发起寻呼流程。

15. 同上述步骤1-9 : 步骤14-21,UE B也会完成在MME以及IMS的注册。 16. SGW将缓存的数据发往UE B,其中SIP信令为A呼叫B的INVITE消息。

UE发送上行数据到AS,携带回复的100 Trying消息。后续信令和数据的传输见A呼叫B(SIP呼叫业务流程)。

4.1.7. VoLTE呼叫流程-SIP信令

下面的信令流程为SIP信令,该信令产生在用户面上,通过接入网直接透传到IMS域,是作为用户业务数据进行传输。

1. 用户A,摘机对用户B发起呼叫,用户A首先向AS服务器发起INVITE请

求。

2. AS服务器回复100 Trying给用户A说明收到INVITE请求。

3. AS服务器通过认证,确认用户认证已通过后,向被叫终端B转送INVITE

请求。

4. 用户B向AS服务器送呼叫处理中的应答消息,100 Trying 。

5. 用户B向AS服务器送183 Session Progress消息,提示建立对话的进度

信息。(此时被叫QCI1专用承载建立)

6. AS服务器向主叫终端A转送183 Session Progress消息,终端A了解到

整个Session的建立进度消息。

7. 终端A向AS服务器回复临时应答消息PRACK,表示收到183 Session

Progress消息,此时主叫QCI1专用承载建立。

8. AS服务器向被叫终端B转送临时应答消息PRACK ,终端B了解到终端A

收到183 Session Progress消息。

9. 被叫终端B向AS服务器发送200 OK消息,表示183 Session Progress

请求已经处理成功。

10. AS服务器向主叫终端A转送200 OK消息。

11. 主叫终端A向AS服务器发送UPDATE消息,意在与被叫终端B协商相关SDP

信息。

12. AS服务器向被叫终端B转送UPDATE消息。

13. 被叫终端B向AS服务器发送200 OK消息,表示UPDATE请求已经处理成功。

14. AS服务器向主叫用户A转送200 OK消息,通知用户A UPDATE请求已经处

理成功。

15. 被叫用户B振铃,用户振铃后,向AS服务器发送180 Ringing 振铃信息。 16. AS服务器向主叫终端A转送180 Ringing 振铃信息。

17. 被叫终端B向AS服务器发送200 OK消息,表明主叫最初的INVITE请求已

经处理成功。

18. AS服务器向主叫终端A转送200 OK消息,通知主叫终端A,被叫终端B

已经对INVITE请求处理成功。

19. 主叫终端A向AS服务器发送ACK消息,意在通知被叫终端B,主叫侧已经

了解被叫侧处理INVITE请求成功。 20. AS服务器向被叫终端B转送ACK信息。

21. 用户A主动挂机,A向AS服务器发起通话结束BYTE信息。 22. AS服务器向被叫终端B转送BYTE信息。

23. 被叫终端B向AS服务器发送200 OK消息,表示对BYTE信息处理成功。 24. AS服务器向用户A转送200 OK信息。整个通话结束。 25. 被叫用户B主动挂机流程同步骤21—24。

无线侧信令过程

? INVITE:发起会话邀请,在VOLTE中就是用于起呼,INVITE消息中主要包含了

主叫信息、被叫号码和主叫支持的格式 ? RRCConnectionReconfiguration:

“RRCConnectionReconfiguration”消息中一起下发,所以“RRCConnectionReconfiguration”中解码出来的“Activate Dedicated EPS Bearer Context Request”消息内容,与后续的“Activate Dedicated EPS Bearer Context Request”消息内容一致

? UPDATE & UPDATE 200: 用于在呼叫过程中进行媒体格式的二次协商,UPDATE

200消息是对UPDATE消息的确认,UPDATE 200消息中协商结果为双方通话使用的通话格式,通常选取主被叫双方中格式中较低的一种,主被叫双方根据协商结果,通过“Modify EPS Bearer Context Request”消息对EPS承载进行相应的修改,其中携带了主要建议的语音编码格式

如通过WireShark抓包,其信令流程如下:

核心网侧的IP包过程

4.4. VoLTE异系统切换流程-SRVCC\\eSRVCC流程

SRVCC(Single Radio Voice Call Continuity),中文称为单一无线语音呼叫连续性,其作用是:当用户在移出LTE网络覆盖范围时,将正在进行的语音业务由LTE的PS域切换到2G/3G电路域,从而保证语音呼叫的连续性。用户在GSM网络中语音通话结束,以后将返回LTE网络,依赖于FR功能,其实现和CSFB类似。由于同系统的VoLTE切换,仅涉及承载切换,和传统的LTE同系统切换相同,不再累述。

4.4.1. SRVCC的业务流程

上图为一个简单的SRVCC业务流程,具体步骤如下: 1. SRVCC终端发起向另一IMS终端的语音呼叫 2. 呼叫成功,媒体连接建立,双方进行通话

3. 用户离开LTE覆盖,发生SRVCC切换,SAE网络通知SRVCC MSC准备切换,

MSC完成预留资源

4. 通知终端切换到2G/TD,切换过程中语音发生中断,中断时间T1约为200ms 5. SRVCC MSC发起远端媒体更新,通知远端IMS终端通过SRVCC MSC接收和发

送语音

6. 远端IMS终端将媒体连接切换至SRVCC MSC

7. 从SRVCC终端切换到2G/TD到远端IMS终端切换媒体连接完成,这段时间语

音将发生中断,中断时间T2约为800ms左右(如果远端终端处于漫游中,这段时间还会更长)

简单来说,当UE移动到LTE覆盖边缘,MME根据enodeB上报信息检测到终端接收信号减弱,LTE覆盖不能满足其需求,低于其判决门限时,需要切换到GSM/TDS网络以保证通话连续性。这时,MME会通知关联的eMSC发起切换流程,该流程通过IMS核心网控制进行信令的处理和媒体的切换。此时的信令是从CS域接入到MSC Server,再从MSC Server到拜访地的ATCF,然后连接到S-CSCF和SCC AS,再通过SCC AS同远端用户建立连接;此时的媒体连接是UE到CS-MGW(Media GateWay,媒体网关),然后由CS-MGW锚定到拜访地的ATGW,再从ATGW连接到远端的媒体网关。

从理论上来说,SRVCC在承载层面的切换(从LTE切换到GSM/TDS)是能满足R8版本3GPP TS25.913 8.4章节规定的实时业务小于300ms的中断时延要求,但它的会话转换(业务切换)过程却无法在300ms内完成,由此导致整个语音中断时间无法满足300ms的要求。而从实际测试上看,用该方案,最短语音中断时长为0.8s,而一般测试均在1s以上,用户感知较差。 4.4.2. eSRVCC的业务流程

在这种情况下,3GPP R10协议提出了eSRVCC方案。eSRVCC,增强型SRVCC,是在SRVCC基础上,在IMS 系 统 中 新 增 了 一 对 功 能 实 体 ,分别作为 VoIP 呼叫在控制平面和用户平面的锚定点,让媒体切换点改为更靠近本端的设备。

具体方案就是增加ATCF/ATGW功能实体作为媒体锚定点,无论是切换前还是切换后的会话消息都要经过ATCF(Acess Transfer Control Functionality,接入转移控制功能 ,用于控制面)/ATGW(Access Transfer Gateway,接入转移网关,用

于媒体面)转发。后续在发生eSRVCC切换时,只需要创建UE与ATGW之间的承载通道,对端设备与ATGW之间的媒体流还是通过原承载通道传输。这样其创建新承载通道的消息交互路径明显短于SRVCC方案,减少了切换时长。

4.4.3. eSRVCC种类

根据切换发生在不同信令阶段,SRVCC也分为不同种类,B为被叫用户: ? SRVCC/eSRVCC:一般通话情况下的切换,发生在ACKtoB和BYE of B之

间的切换;

? aSRVCC:在振铃阶段发生的切换,发生在180 Ringing和信令ACKtoB之间

的切换

? bSRVCC:发生在183 Session Progress和信令Ringing之间的切换,由于该时

间很短,该切换一般不予开启;

? rSRVCC:eSRVCC切换到GSM后,LTE信号变强,UE从GSM网络回切会

LTE的切换,但考虑到现阶段GSM覆盖要强于LTE覆盖,也为了防止来回切换的乒乓效应,该切换一般不予开启。

? vSRVCC:视频业务的切换,现GSM网络不支持视频业务,故无此切换; ? Mid-call SRVCC:呼转的切换; 4.4.4. eSRVCC的信令流程

由于SRVCC种类较多,本文仅介绍使用最多eSRVCC,即在通话状态下的eSRVCC过程。其他类型的信令与该类型相似,不再累述。

UE-AE-UTRANGSM BSSMME目标MSCeMSC/MGWSAE GWP-CSCFI-CSCFSCC ASUE B1. 终端A和B之间已建立会话,呼叫信令锚定在ATCF上,媒体面锚定在ATGW1. 测量报告2. eNB发起eSRVCC切换3. Handover Required4. 媒体面拆分5. PS to CS request6. HO prep7. HO request8. HO resp9. 电路资源预留10. PS to CS resp12. Handover11. Handover Command19. SIP INVITE (STN-SR, C-MSISDN)20. SIP INVITE (ATU-STI, C-MSISDN)13. UE切换到GSM21. SIP INVITE (ATU-STI, C-MSISDN)23. SIP 200 OK14. HO Complete22. ATCF控制ATGW进行媒体改向15. HO Complete25. SIP 200 OK26. SIP ACK24. SIP 200 OK27. SIP ACK16. PS to CS HO Complete17. 释放QCI=1的承载18. 释放无线资源30. SIP BYE33. TMSI reallocation34. location updateHSS31. SIP 200 OK32. SIP 200 OK28. SIP ACK29. SIP BYE ? 步骤0:终端A和终端B之间已经建立起VoLTE会话,终端A为SRVCC终端,呼叫信令锚定在ATCF上,媒体面锚定在ATGW上;

? 步骤1:终端A根据eNB指示,对相邻小区进行测量,并上报测量结果; ? 步骤2:eNB决定发起eSRVCC切换,并选定目标小区;

? 步骤3:eNB向MME发送HANDOVER REQUIRED消息,消息中携带目标小区ID,并通过SRVCC HO Indication指示该切换为SRVCC切换; ? 步骤4:MME根据SRVCC HO Indication判断本次切换为SRVCC切换,将切换会话中的语音媒体流(QCI=1)分离出来进行后续切换;

? 步骤5:MME选择一个eMSC并发送SRVCC PS to CS Request请求,通知eMSC发起电路域侧资源预留,主要参数包含IMSI、C-MSISDN、STN-SR、Target Cell ID和Source to Target Transparent Container。

? 步骤6-9:eMSC发起电路域侧的资源预留流程包括空口资源及核心网链路资源;

? 步骤10:eMSC返回SRVCC PS to CS Response,通知MME资源预留结果,并携带Target to Source Transparent Container参数;

? 步骤11:如果电路域侧资源预留已完成,MME向eNB发送HANDOVER COMMAND消息,携带Target to Source Transparent Container参数; ? 步骤12:eNB根据Target to Source Transparent Container参数通知终端从LTE切换到GSM的目标小区; ? 步骤13:终端空口切换到GSM;

? 步骤14-16:在终端空口切换到GSM后,BSS向目标MSC发送HO Complete消息,经过eMSC后通知MME切换完成;

? 步骤17:MME发起承载释放流程,删除SAE GW上的所有GBR承载,并挂起默认承载;

? 步骤18:MME发起无线侧承载释放流程,释放S1接口及无线资源; ? 步骤19:eMSC在发出SRVCC PS to CS Response消息触发接入侧切换流程的同时,也向P-CSCF发送SIP INVITE消息,触发会话层面的切换流程,消息中携带从MME获得的STN-SR和C-MSISDN,同时携带MSC侧的SDP; ? 步骤20-21:P-CSCF根据MSC侧的SDP,通过ATCF和ATGW交互完成媒体面的改向,将媒体连接指向eMSC/MGW;同时构造一个新的INVITE消息,将Request-URI设置为之前从注册消息中收到的ATU-STI,指向SCC AS; ? 步骤22:P-CSCF通过ATCF控制ATGW完成媒体面改向; ? 步骤23-28:200 OK响应及ACK;

? 步骤29:SCC AS在收到INVITE消息后,得知发生了SRVCC切换,通过C-MSISDN将新的信令连接与远端信令连接进行关联,并通过BYE消息释放原有信令连接;

? 步骤30:P-CSCF收到BYE消息后,删除本地信令连接;

? 步骤31-32:释放完成,切换完成后,媒体面通过ATGW和eMSC/MGW实现转接;

? 步骤33-34:eMSC发起TMSI重新分配,并代替用户进行电路域位置更新。

下面为eSRVCC的大概步骤:

SRVCC处理过程中,对于UE已建立的非语音业务,根据网络、UE的能力、业务的类型,触发PS HO、去激活Deactivated(GBR业务)或者挂起Suspended(NGBR业务)等业务处理流程。从现网流程来看,其处理逻辑和CSFB相似,一般为Suspended(挂起)操作。若UE在CS 域结束语音业务后,返回到LTE网络,UE通过TAU过程指示MME,MME检测UE存在挂起的业务,则可以恢复UE已挂起的业务。

4.4.5. eSRVCC的无线侧信令流程

在无线测试的层面上,其具体的信令步骤为: 1. 下发针对服务小区频点的A2事件测控 2. UE上报下发的GSM邻区的B2事件测控 3. UE上报后选点目标小区 4. enodeB向MME发起eSRVCC切换请求,并等待目标网络完成资源预留 5. enodeB收到MME切换响应 6. enodeB向UE下发切换命令 7. 切换完成,释放本地资源。 其无线侧信令如下。如网络不支持B2切换,其起测门限和切换门限不能分开设置,那信令将从步骤4开始。考虑到,由于门限分开设置,在网络优化上有更大便利性,可以有效克服LTE信号陡降引起的话音无法及时切换造成的掉话,现集团已经要求各个厂家必须支持B2切换,故本解析按正常的B2切换为蓝本进行介绍。 eSRVCC切换无线侧信令 步骤 接口 信令 网络 信道 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Uu Uu Uu Uu Gs A Uu Uu measurementReport RRCConnectionReconfigration LTE UL-DCCH LTE DL-DCCH RRCConnectionReconfigrationComplete LTE UL-DCCH measurementReport Handover Requried Handover request Handover Command mobilityFromEUTRACommand LTE LTE GSM LTE UL-DCCH Gs A DL LTE DL-DCCH LTE S1-C LTE S1-C GSM DL RR GSM UL RR GSM DL RR GSM UL RR GSM DL MM GSM UL MM GSM UL CC S1-C UE Context Release Request S1-C UE Context Release Command Uu Uu Uu Uu Uu Uu Uu Physical Information Handover Complete Physical Information GPRS Suspension Request Identity Request Identity Response Disconnect 现对该无线侧信令进行解析 1. MeasurementReport中上报RSRP,启动A2事件,开启异系统测量,测量标示为测量标识:measId = 2 2. RRCConnectionReconfigration:在 Measurement Control信息中下发B2事件,下发GSM的小区频点和接入门限; 3. RRCConnectionReconfigrationComplete:完成RRC重配置; 4. MeasurementReport:上报测量到的GSM小区的信号强度,符合条件的GSM小区的网络色码与基站色码; 5. Handover Requried:eNodeB向GSM系统发起基于SRVCC的切换请求,包含目标小区的CGI,CI和频点;该请求通过MME由Gs接口发给对应的eMSC。 6. Handover Request:MME通知enodeB,GSM侧的资源准备已经完成,可以启动切换流程; 7. Handover Command:,由MME通过S1口通知基站触发由E-UTRAN到GSM的切换。下发小区BSIC,频点,信道类型,跳频等信息; 8. mobilityFromEUTRACommand:网络通知UE断开LTE链接,UE删除LTE链接。 9. UE Context Release Request:LTE侧切换完成,enodeB向MME请求释放UE的相关资源

10. UE Context Release Command:MME响应基站释放UE资源的请求。

11.Physical Information:UE在GSM上向GSM小区发的物理信息,GMS同步

切换时使用,现网中未使用,现该信令为空,部分测试设备不会显示;

12.Handover Complete:UE在GSM上向GSM小区发的切换完成信息,用于GSM侧的切换完成(LTE侧切换已经在步骤9以前已经完成,网络在步骤7已经通知UE);

13.Physical Information:UE在GSM上向GSM小区发的物理信息,GMS同步切换时使用,现网中未使用;

14.GPRS Suspension Request:在GPRS业务上挂起原有的LTE业务; 15.Identity Request:身份验证申请,现网基本未开启,信令为空; 16.Identity Response:身份验证响应,现网基本未开启,信令为空;

4.5. VoLTE挂机流程

? 当VoLTE呼叫挂机的时候,会先释放IMS的业务,再释放无线侧的承载; ? 当无线侧有多个承载的时候,即有其他业务并存,网络将只释放专用承载,保留默认承载;

? 如果终端此时没有数据业务,10s后网络侧将会进行RRC release

测试软件信令路程

在测试软件上,其信令主要表现为BYE和BYE200反馈,以及专有承载的释放。

五、 无线侧功能介绍

VoLTE的无线侧功能分为基本功能和增强型功能:

? 基本功能:QCI=1/2的承载,RLC层的Um模式,无线承载组合,IMS紧

急呼叫

? 增强型功能:IP包头压缩,SPS(半持续调度),TTI Bunding

在前面介绍中,已经对基本功能进行了介绍,在这里,不再累述,主要介绍其重点VoLTE专用的增强功能。 5.1. IP包头压缩(RoHC)

VoIP业务是基于IP网络传输的语音业务,包头开销占整个数据包的比例较大,为了节省传输资源,业界提出了一种IP包头压缩方法——RoHC,该功能可大大降低包头开销。

其基本原理为:仅在初次传输时发送数据包头的静态信息(如IP地址等),后续不再重复发送。通过一定信息可推知数据流中其他信息时,可仅发送必须的信息,其他信息可由上下文推算(如SN号和IP-ID号都是以1为单位递增,可通过上下文推算)。IP包头压缩可大大降低头开销,提高VoLTE语音用户容量,提高数据业务吞吐量,增强边缘覆盖。

从现场测试效果来看,典型VoLTE数据包净荷为32字节,IP头开销甚至超过净荷本身,当为IPv6时,其包头大小为60 byte,头开销可达188%,为IPv4时,包头大小为40 byte,头开销也有125%。经过RoHC压缩后,包头开销从40~60bytes降为4~6 bytes, 开销占比降为12.5%~18.8%,从而对VoLTE业务信道覆盖和容量有显著增益。

头压缩主要对包头进行压缩,以节省传输效率。在试点测试中RoHC头压缩可到60%左右压缩效率。试点验证建议开启RoHC压缩。

RoHC的模式可以如下几种:

? U模式(unidirectional,单向模式),报文只能从压缩方到解压方单向发送,不强制要求有反馈通道,因此这种模式的可靠性低于优化模式和可靠模式,但反馈占用的开销也最低

? O模式(Bidirectional,双向模式),解压方可以向压缩方发送反馈信息,指示异常或上下文同步成功,此模式的可靠性比单向模式要高;需要的反馈信息量也不如可靠模式模式大

? R模式( Bidirectional Reliable,双向可靠模式),压缩方和解压方上下文的可靠性也最高,但由于反馈频繁,链路开销也最大

压缩器总是启动在U模式,根据反馈信息实现三种模式的迁移

? 当Feedback信道可获得时,压缩器可以从U模式到O模式转换 ? 当至少一个报文被正确解压缩,即Context的静态信息建立后,才能允许从O模式到R模式的转换

华为设备的参数开启如下:

? RoHCSwitch:RoHC开关,建议ON,该参数表示eNodeB是否启用RoHC功能,当开关打开时,启用RoHC头压缩功能减小报文头部在空口的传输开销,提高VoIP业务容量,改善VoIP业务覆盖。

? HighestMode:RoHC最高模式,建议:O_MODE(优化模式)。该参数表示RoHC的运行模式,

? Profiles:压缩协议类型,建议值:开启1-4的压缩协议。该参数表示eNodeB支持的压缩协议类型,在RoHC的框架下,针对不同的协议,有多种不同的头部压缩算法,Profiles就定义了特定报文流的头部压缩协议(比如RTP/UDP/IP、TCP/IP),这些协议从属于共同的RoHC框架。不同Profile通过唯一的标识号进行区分。对不支持格式的报文头,统一采用Profile0x0000处理。不压缩,增加Profile0x0000 RoHC头。增加了空口传输开销,降低RoHC的整体增益。

5.2. SPS半持续调度

在VoLTE标清(RoHC)的场景下,VoLTE容量同时受限于PDSCH和PDCCH。半持续调度(SPS)是LTE中为了节省PDCCH数量而提出的一种新的调度方法,最初主要是针对VoIP业务。其可大大降低控制信令开销,使信令开销资源最低可仅为业务的1.3%。

VoIP的新传包由于其达到间隔是20ms,所以可以由一条信令分配频域资源,以后每隔20ms就“自动”用分配的频域资源传输新来的包;重传包由于其不可预测性,所以动态的调度每一次重传,因而叫“半”持续调度

TDD特性(上行双周期配置):由于其HARQ RTT与FDD有所差异,会导致重传包和新传包传输冲突,为解决这个TDD独有的问题,支持双周期的半持续性调度,即2DL:2UL时为19ms和21ms;3DL:1UL时为25ms和15ms

由于VoIP的语音包间隔周期为严格的20ms/个,在PDCCH资源受限情况下,SPS调度可以减少控制信道的资源开销。但在现网3:1时隙配比下,因SPS采用保守调度算法(MSC不得高于15),可能导致系统容量受限于PUSCH而有所下降,同时C-DRX配置为40ms(终端每2个VoLTE语音包得到一次调度),此时VoLTE语音受限因素并不是PDCCH,故在现网中很少采用。

华为SPS开关在小区级算法开关中(CELLALGOSWITCH)中的上行调度算法开关和下行调度算法开关中,当前版本默认SPS开关关闭。

? CELLALGOSWITCH:小区级算法开关,该开关用来决定VoIP业务通话期是否

采用半静态调度,如果开关打开,采用半静态调度;如果开关关闭,采用动态调度。

? 上行SPS周期分别在上行调度算法参数(CELLULSCHALGO)中的上行半静态

调度周期(UlSpsInterval)中配置,目前可配置20ms/40ms/自适应。 ? 下行SPS周期分别在下行调度算法参数(CELLDLSCHALGO)中的下行半静态

调度周期(DlSpsInterval)中配置,目前可配置20ms/40ms/自适应。

5.3. TTI bundling

在小区边缘存在瞬时传输速率较高、上行功率受限等情况,会导致上行覆盖受限,在一个TTI内终端可能无法满足数据发送的误块率(BLER)要求。TTI bundling可以提升上行覆盖性能,但增加了传输时延。

TTI bundling示意图

属于同一个TTI bundle的每一次传输(每个TTI)都由同一个HARQ process来处理,其多个子帧使用同一个PDCCH(DCI format 0)来指示分配的上行资源。

UE只有对应TTI bundle的最后一个TTI,会收到一个HARQ ACK/NACK反馈,也就是说,TTI bundle内的所有TTI传输作为一个整体,统一反馈HARQ ACK/NACK。TTI bundle的重传依然是一个TTI bundle。

如果UE配置了TTI bundling,则分配给该UE的上行资源不能多于3个PRB,同时其modulation order必须配置成2,如下图:

时隙绑定示意图

TTI bundling使用4个连续TTI传输同一个数据包的四个不同版本,增大了传输成功率,从而提高数据解调成功率,对上行覆盖范围有一定的改善。

不考虑重传,单从1个TTI和4个TTI传输角度,HARQ进程为4,上行覆盖增益大约4dB(链路级仿真得出)。如考虑重传,TDD上行覆盖增益仅为2dB,性能增益有限,但控制信令会节省开销。

由OMC配置是否开启。当测量SINR小于一定的值时,启动TTI Boundling功能,小区边缘需要启动TTI Boundling。在模式3下,TTI Boundling的增益约为3~4dB;考虑重传情况下,TDD增益仅为2dB。

但在TD-LTE系统中,由于上下行时隙不连续,而语音包又有20ms的周期限制,因此仅在2DL:2UL配置时才可使用TTI bundling,3DL:1UL无法使用。同时在标准中,VoLTE业务不能同时采用SPS调度和上行TTI bundling(MCS标注位受限),但可仅针对边缘用户使用TTI bundling,故在一般中,该功能一般不予开启。 六、 参数基本设置

6.1. VoLTE功能开启参数配置

华为eNodeB版本BTS3900 V100R009C00SPC135版本全面支持VoLTE功能,包括SPS、头压缩、eSRVCC等特性。若有新版本建议升级最新版本。

根据试点测试,VoLTE商用基本功能默认配置如下:

eNodeB版本 VoIP功能开关 头压缩 eSRVCC 半静态调度SPS 打开 打开 关闭 BTS3900 V100R009C00SPC135 打开 说明:eSRVCC需要根据现网邻区灵活配置。

6.2. 基本业务参数

华为eRAN7.0SPC135版本VoLTE能力开关默认打开。不同QCI(QCI1~QCI9)等级参数通过RLC PDCP参数组ID对应的参数进行关联, RLC PDCP参数组ID最多配置40个(0-39),关联的参数有RLC模式(UM/AM)、PDCP丢包定时器。

QCI等级RLC PDCP参数组ID RLC模式(1-9) (UM/AM) PDCP丢包定时器 DiscardTimer_50(50毫秒), DiscardTimer_100(100毫秒), QCI1~QCI9 0~39 UM/AM DiscardTimer_150(150毫秒), DiscardTimer_300(300毫秒), DiscardTimer_500(500毫秒), DiscardTimer_750(750毫秒), DiscardTimer_1500(1500毫秒), DiscardTimer_Infinity(无限