陈宇 王月珍
1 引言
OTT语音通信在移动互联网时代得到了极大的关注与应用,这给运营商传统语音业务也带来了相应的冲击。随着移动通信网络所能提供的数据传输速率的提升及业务时延的缩小,这种冲击也将变得越来越大。LTE技术能提供超过100M的下行速率,同时大幅降低端到端时延,用户面单向时延将控制在5ms以内。如何在4G时代继续确保语音业务的主导地位,成为电信运营商需要重点关注的问题。在此背景下,本文对VoLTE技术展开分析,分别介绍了实现VoLTE技术的网络架构、VoLTE业务的关键流程和QoS保障机制,重点分析VoLTE技术如何在资源共享的全IP网络上,实现可靠性和语音质量不低于传统电路域的语音业务,最终确保与OTT语音竞争的优势地位。
2 VoLTE网络架构
VoLTE业务实现方案是以LTE作为接入和承载网络,以IMS(IP Multimedia System)作为语音和多媒体等业务的控制网络,并通过PCC架构和EPS协同提供QoS保障机制,满足端到端语音业务需求。
VoLTE网络架构由E-UTRAN、EPC和IMS控制域组成,如图1所示。其中E-UTRAN主要包括eNodeB,eNodeB是3GPP用于替代UMTS Node B和RNC联合功能的LTE无线接入设备。
EPC主要包括MME、S-GW和P-GW等。其中MME是EPC的控制面实体;S-GW是本地的移动性锚点;P-GW是连接外部分组数据网络的锚点,并拥有PCEF及IP地址分配等功能;PCRF是完成策略控制的功能实体;HSS用于存放用户签约数据。
IMS包括的主要网元有CSCF和MMTel AS等。其中P/I/S-CSCF为呼叫会话控制功能实体,主要完成呼叫会话过程中信令转发、路由及具体控制功能;MMTel AS提供多媒体通信及补充业务。由于本文主要针对VoLTE纯网络形态进行探讨,所以不涉及与其它网络的互通网元及结构分析。
3 VoLTE业务流程
VoLTE语音会话的建立需要UE、E-UTRAN、EPC、IMS完成一系列的信令交互和资源准备。VoLTE业务流程可以划分为EPC附着、IMS注册、VoLTE会话建立、VoLTE媒体流通信、VoLTE会话释放五个阶段,如图2所示。
LTE用户在EPS网络中注册,至少需要建立一个PDN连接。对于VoLTE用户,针对IMS APN的PDN连接将一直保持。用于IMS信令传输的默认承载将在EPC附着过程中创建,而用于媒体传输的专用承载将于VoLTE会话建立过程创建。下面对主要的流程分别进行介绍。
3.1 EPC附着
UE进行VoLTE业务前,需要先对EPC网络进行附着,如图3所示。
(1)UE开机后,与eNodeB建立RRC连接。
(2)UE进行EPS注册,同时通知HSS对用户信息进行更新,HSS将用户的默认PDN及用于SIP信令承载的QoS信息发回MME(假如默认PDN不是IMS PDN,IMS注册前还需先建立IMS PDN)。
(3)建立EPS默认承载。P-GW先通过IP-CAN会话建立过程向PCRF获取默认PCC规则,然后将用户IP地址、EPS默认承载QoS等用户信息经由S-GW返回给MME。
(4)P-GW将P-CSCF地址发给MME,MME对新的用户信息进行确认更新,并将EPS默认承载QoS、用户IP地址、P-CSCF地址等通过eNodeB下发给UE。
(5)UE经由eNodeB向MME发送附着完成消息,建立无线承载。
3.2 IMS注册
用户完成EPS附着,需要在IMS网络完成注册,注册流程如图4所示。
(1)UE首先向网络为其分配的S-CSCF发送注册请求。
(2)S-CSCF从HSS获取用户鉴权数据。
(3)S-CSCF将用户鉴权数据封装进401响应回送给UE。
(4)P-CSCF和UE根据401响应中的鉴权参数建立IPsec安全关联。
(5—7)S-CSCF收到UE第二次发送的注册请求后,对UE进行鉴权。若鉴权通过,则从HSS下载用户配置,并向UE返回200OK指示鉴权完成。
(8)注册成功后,S-CSCF通知用户签约的MMTel AS完成第三方注册。
(9、10)UE和P-CSCF分别向S-CSCF订阅用户注册状态信息。
3.3 VoLTE会话建立
在VoLTE通话前,需要进行媒体协商及资源预留等会话建立操作,如图5所示。
(1)UE1将封装有媒体类型及编解码方案的SDP请求通过INVITE消息发给UE2。
(2)UE2将自己支持的方案类型通过183响应返回给UE1。
(3、4)UE1向UE2发送携带有选定媒体类型及编解码方案的PRACK请求,并开始专用承载建立。
(5、6)UE2接收到PRACK请求后回复200OK用于确认,并开始专用承载建立。
(7)UE1收到200OK确认并完成专用承载建立后,向UE2发送UPDATE消息进行媒体更新。
(8、9)UE2接收到UPDATE消息,向UE1返回200OK表示接受请求。当UE2完成专用承载建立后,开始振铃并向UE1返回180振铃响应。
(10)UE2摘机,向UE1返回200OK响应。
(11)UE1收到200OK响应后,向UE2发送ACK确认消息。至此,会话建立完成。
VoLTE会话建立完成后,UE1和UE2之间正式开始VoLTE媒体流的通信。
3.4 VoLTE会话释放endprint
在语音会话结束后,终端可发起相应的会话释放,具体流程如图6所示。
(1)UE2挂机将向UE1发起BYE请求。
(2、3)当BYE请求经由UE2及UE1各自归属网络P-CSCF时,P-CSCF将经由PCRF通知P-GW执行专用承载拆除工作。
(4—6)UE1及UE2完成专用承载拆除,同时UE1将向UE2返回200OK响应。
除了终端发起的VoLTE会话释放场景,当某一端用户专用承载丢失,P-GW也会触发PCRF向归属网络P-CSCF发送会话释放消息,并由P-CSCF向对端网络发起BYE请求,接下来的会话释放流程与终端发起情况类似,此处不再赘述。
4 VoLTE的QoS保障机制与OTT语音的比较
结合前文针对VoLTE网络架构和业务流程的分析,下面对VoLTE语音通信的QoS保障机制及相对于OTT语音的优势进行进一步阐述。
4.1 VoLTE的QoS保障机制
VoLTE的QoS保障通过EPS域和IMS域共同完成,以下进行具体分析。
(1)EPS域的QoS保障
EPS采用端到端、层次化网络架构,并以承载的形式进行数据传输。如图7所示,LTE系统将端到端的业务划分为EPS承载和外部承载,而EPS承载又进一步分为无线承载、S1承载和S5/S8承载。
LTE没有沿用3G制式的QoS协商及专用信道机制,在空口只保留共享信道以利于采用更灵活的资源调度进行QoS保障。LTE采用承载级QoS保障,传输流模板(TFT)及其中的分组过滤器将上层业务数据流(SDF)进行相应的EPS承载映射,最终实现用户数据的区分QoS保障。EPS承载分为GBR承载和Non-GBR承载,GBR承载是指网络对承载速率进行严格保障的承载,而Non-GBR承载的速率将得不到保障。QCI作为重要的QoS参数,是接入点对承载级数据分组进行分类的重要依据。3GPP根据数据分组资源类型、时延、误码率、业务的不同将QCI分成9个等级(见表1)。VoLTE采用QCI=1的专用承载作为语音承载,QCI=5的默认承载作为IMS信令承载,从而保障语音数据分组的优先资源调度和传送。
(2)IMS域的QoS保障
在EPC附着和IMS会话建立过程中,连接EPS域和IMS域的PCC架构将参与VoLTE的QoS保障。EPC附着时,P-GW通过IP-CAN会话建立向PCRF获取缺省PCC规则,PCRF则向SPR获取用户信息并将其转换成相应的策略发往P-GW以建立默认承载;IMS会话建立时,P-CSCF将语音会话信息发往PCRF,PCRF进行QoS授权,授权通过后PCRF将QoS信息发往P-GW,P-GW根据接收到的QoS信息建立语音业务专用承载。这样,通过PCC架构,可以为VoLTE业务设置高优先级的QoS规则,从而保障语音通信的质量。
4.2 与基于LTE的OTT语音对比
OTT语音是上层应用业务,在LTE网络中底层承载将其认定为普通数据传输,于是OTT语音将与其它普通数据分组使用相同的Internet PDN连接的Non-GBR默认承载(QCI=8/9)。这将导致OTT语音与其它业务抢占公共带宽资源,引起OTT语音出现误码、丢包、时延大等一系列服务质量问题。因此,基于LTE的OTT语音业务无法得到有效的QoS保障。而对于VoLTE,前面提到其采用高QoS等级的语音及信令承载,且建立独立于普通数据业务的PDN连接,能在EPS域和IMS域获得良好的QoS保障。
同时,VoLTE对空口也作了进一步的优化。首先,RLC层采用UM模式,通过取消RLC重传机制来减少业务时延。其次,针对上行功率受限场景采用TTI Bunding技术,通过在同个HARQ进程连续发送相同RLC层分片4个不同冗余版本,以此来降低小区覆盖边缘VoLTE语音数据的误码率和时延。OTT语音采用普通数据处理机制,无法使用以上的优化特性。另外,由于通过软件方式完成会话建立及语音数据处理,OTT语音业务时延也相应增加。
从端到端来看,VoLTE业务走的是电信运营商具有高可靠性及安全性的内部网络。通过IMS域、EPS域及PCC架构的联合保障,语音业务端到端时延、误码率等服务质量都获得严格保证,这些都是OTT语音业务无法做到的。OTT分组数据需要通过Internet寻路至对端网络,而Internet一般采用无QoS保障的Best-Effort数据传输方式,这将导致OTT语音质量的进一步下降。
除了QoS无法得到可靠保障外,OTT语音在手机资源消耗、终端信道资源占用、异系统切换、异OTT应用兼容性等方面也得不到良好表现。对于这些问题,VoLTE采用底层数据处理、非连续性接收(DRX)、鲁棒性头压缩(RoHC)、半静态调度(SPS)、单载波语音呼叫连续性(SRVCC)等技术及本身拥有的特性,都能较好解决。在提高用户体验上,VoLTE可以采用高清语音、富通信套件(RCS)、增强富通信套件(RCSe)等丰富的业务形态来提高差异化优势。
5 结束语
VoLTE是电信运营商充分利用LTE网络在语音业务上演进的必然结果,它不单拥有传统的电信级QoS保障机制及业务特性,而且拥有新兴的如高清语音、RCS/RCSe的业务形态,在良好的服务质量和绝佳的用户体验上更能迎接OTT通信软件的挑战。当然,不论是从产业链及投入成本的角度,还是从网络演进策略的角度,要实现VoLTE还有很多问题需要考虑。但是,作为能充分利用先进网络技术并围绕提高用户感知体验,同时考虑运营商自身特点的VoLTE技术,相信在不远的将来必能得到广泛应用。
参考文献:
[1] GSMA IR 92.V7.0. IMS Profile for Voice and SMS[S]. 2013.
[2] GSMA IR 94.V6.0. IMS Profile for Video Service[S]. 2013.
[3] 3GPP TS 23.203. Policy and Charging Control Architecture[S]. 2013.
[4] 3GPP TS 23.207. End-to-end Quality of Service(QoS) Concept and Architecture[S]. 2012.
[5] 3GPP TS 23.228. IP Multimedia Subsystem(IMS) Stage2[S]. 2013.
[6] 3GPP TS 36.321. Medium Access Control(MAC) protocol specification[S]. 2013.endprint
在语音会话结束后,终端可发起相应的会话释放,具体流程如图6所示。
(1)UE2挂机将向UE1发起BYE请求。
(2、3)当BYE请求经由UE2及UE1各自归属网络P-CSCF时,P-CSCF将经由PCRF通知P-GW执行专用承载拆除工作。
(4—6)UE1及UE2完成专用承载拆除,同时UE1将向UE2返回200OK响应。
除了终端发起的VoLTE会话释放场景,当某一端用户专用承载丢失,P-GW也会触发PCRF向归属网络P-CSCF发送会话释放消息,并由P-CSCF向对端网络发起BYE请求,接下来的会话释放流程与终端发起情况类似,此处不再赘述。
4 VoLTE的QoS保障机制与OTT语音的比较
结合前文针对VoLTE网络架构和业务流程的分析,下面对VoLTE语音通信的QoS保障机制及相对于OTT语音的优势进行进一步阐述。
4.1 VoLTE的QoS保障机制
VoLTE的QoS保障通过EPS域和IMS域共同完成,以下进行具体分析。
(1)EPS域的QoS保障
EPS采用端到端、层次化网络架构,并以承载的形式进行数据传输。如图7所示,LTE系统将端到端的业务划分为EPS承载和外部承载,而EPS承载又进一步分为无线承载、S1承载和S5/S8承载。
LTE没有沿用3G制式的QoS协商及专用信道机制,在空口只保留共享信道以利于采用更灵活的资源调度进行QoS保障。LTE采用承载级QoS保障,传输流模板(TFT)及其中的分组过滤器将上层业务数据流(SDF)进行相应的EPS承载映射,最终实现用户数据的区分QoS保障。EPS承载分为GBR承载和Non-GBR承载,GBR承载是指网络对承载速率进行严格保障的承载,而Non-GBR承载的速率将得不到保障。QCI作为重要的QoS参数,是接入点对承载级数据分组进行分类的重要依据。3GPP根据数据分组资源类型、时延、误码率、业务的不同将QCI分成9个等级(见表1)。VoLTE采用QCI=1的专用承载作为语音承载,QCI=5的默认承载作为IMS信令承载,从而保障语音数据分组的优先资源调度和传送。
(2)IMS域的QoS保障
在EPC附着和IMS会话建立过程中,连接EPS域和IMS域的PCC架构将参与VoLTE的QoS保障。EPC附着时,P-GW通过IP-CAN会话建立向PCRF获取缺省PCC规则,PCRF则向SPR获取用户信息并将其转换成相应的策略发往P-GW以建立默认承载;IMS会话建立时,P-CSCF将语音会话信息发往PCRF,PCRF进行QoS授权,授权通过后PCRF将QoS信息发往P-GW,P-GW根据接收到的QoS信息建立语音业务专用承载。这样,通过PCC架构,可以为VoLTE业务设置高优先级的QoS规则,从而保障语音通信的质量。
4.2 与基于LTE的OTT语音对比
OTT语音是上层应用业务,在LTE网络中底层承载将其认定为普通数据传输,于是OTT语音将与其它普通数据分组使用相同的Internet PDN连接的Non-GBR默认承载(QCI=8/9)。这将导致OTT语音与其它业务抢占公共带宽资源,引起OTT语音出现误码、丢包、时延大等一系列服务质量问题。因此,基于LTE的OTT语音业务无法得到有效的QoS保障。而对于VoLTE,前面提到其采用高QoS等级的语音及信令承载,且建立独立于普通数据业务的PDN连接,能在EPS域和IMS域获得良好的QoS保障。
同时,VoLTE对空口也作了进一步的优化。首先,RLC层采用UM模式,通过取消RLC重传机制来减少业务时延。其次,针对上行功率受限场景采用TTI Bunding技术,通过在同个HARQ进程连续发送相同RLC层分片4个不同冗余版本,以此来降低小区覆盖边缘VoLTE语音数据的误码率和时延。OTT语音采用普通数据处理机制,无法使用以上的优化特性。另外,由于通过软件方式完成会话建立及语音数据处理,OTT语音业务时延也相应增加。
从端到端来看,VoLTE业务走的是电信运营商具有高可靠性及安全性的内部网络。通过IMS域、EPS域及PCC架构的联合保障,语音业务端到端时延、误码率等服务质量都获得严格保证,这些都是OTT语音业务无法做到的。OTT分组数据需要通过Internet寻路至对端网络,而Internet一般采用无QoS保障的Best-Effort数据传输方式,这将导致OTT语音质量的进一步下降。
除了QoS无法得到可靠保障外,OTT语音在手机资源消耗、终端信道资源占用、异系统切换、异OTT应用兼容性等方面也得不到良好表现。对于这些问题,VoLTE采用底层数据处理、非连续性接收(DRX)、鲁棒性头压缩(RoHC)、半静态调度(SPS)、单载波语音呼叫连续性(SRVCC)等技术及本身拥有的特性,都能较好解决。在提高用户体验上,VoLTE可以采用高清语音、富通信套件(RCS)、增强富通信套件(RCSe)等丰富的业务形态来提高差异化优势。
5 结束语
VoLTE是电信运营商充分利用LTE网络在语音业务上演进的必然结果,它不单拥有传统的电信级QoS保障机制及业务特性,而且拥有新兴的如高清语音、RCS/RCSe的业务形态,在良好的服务质量和绝佳的用户体验上更能迎接OTT通信软件的挑战。当然,不论是从产业链及投入成本的角度,还是从网络演进策略的角度,要实现VoLTE还有很多问题需要考虑。但是,作为能充分利用先进网络技术并围绕提高用户感知体验,同时考虑运营商自身特点的VoLTE技术,相信在不远的将来必能得到广泛应用。
参考文献:
[1] GSMA IR 92.V7.0. IMS Profile for Voice and SMS[S]. 2013.
[2] GSMA IR 94.V6.0. IMS Profile for Video Service[S]. 2013.
[3] 3GPP TS 23.203. Policy and Charging Control Architecture[S]. 2013.
[4] 3GPP TS 23.207. End-to-end Quality of Service(QoS) Concept and Architecture[S]. 2012.
[5] 3GPP TS 23.228. IP Multimedia Subsystem(IMS) Stage2[S]. 2013.
[6] 3GPP TS 36.321. Medium Access Control(MAC) protocol specification[S]. 2013.endprint
在语音会话结束后,终端可发起相应的会话释放,具体流程如图6所示。
(1)UE2挂机将向UE1发起BYE请求。
(2、3)当BYE请求经由UE2及UE1各自归属网络P-CSCF时,P-CSCF将经由PCRF通知P-GW执行专用承载拆除工作。
(4—6)UE1及UE2完成专用承载拆除,同时UE1将向UE2返回200OK响应。
除了终端发起的VoLTE会话释放场景,当某一端用户专用承载丢失,P-GW也会触发PCRF向归属网络P-CSCF发送会话释放消息,并由P-CSCF向对端网络发起BYE请求,接下来的会话释放流程与终端发起情况类似,此处不再赘述。
4 VoLTE的QoS保障机制与OTT语音的比较
结合前文针对VoLTE网络架构和业务流程的分析,下面对VoLTE语音通信的QoS保障机制及相对于OTT语音的优势进行进一步阐述。
4.1 VoLTE的QoS保障机制
VoLTE的QoS保障通过EPS域和IMS域共同完成,以下进行具体分析。
(1)EPS域的QoS保障
EPS采用端到端、层次化网络架构,并以承载的形式进行数据传输。如图7所示,LTE系统将端到端的业务划分为EPS承载和外部承载,而EPS承载又进一步分为无线承载、S1承载和S5/S8承载。
LTE没有沿用3G制式的QoS协商及专用信道机制,在空口只保留共享信道以利于采用更灵活的资源调度进行QoS保障。LTE采用承载级QoS保障,传输流模板(TFT)及其中的分组过滤器将上层业务数据流(SDF)进行相应的EPS承载映射,最终实现用户数据的区分QoS保障。EPS承载分为GBR承载和Non-GBR承载,GBR承载是指网络对承载速率进行严格保障的承载,而Non-GBR承载的速率将得不到保障。QCI作为重要的QoS参数,是接入点对承载级数据分组进行分类的重要依据。3GPP根据数据分组资源类型、时延、误码率、业务的不同将QCI分成9个等级(见表1)。VoLTE采用QCI=1的专用承载作为语音承载,QCI=5的默认承载作为IMS信令承载,从而保障语音数据分组的优先资源调度和传送。
(2)IMS域的QoS保障
在EPC附着和IMS会话建立过程中,连接EPS域和IMS域的PCC架构将参与VoLTE的QoS保障。EPC附着时,P-GW通过IP-CAN会话建立向PCRF获取缺省PCC规则,PCRF则向SPR获取用户信息并将其转换成相应的策略发往P-GW以建立默认承载;IMS会话建立时,P-CSCF将语音会话信息发往PCRF,PCRF进行QoS授权,授权通过后PCRF将QoS信息发往P-GW,P-GW根据接收到的QoS信息建立语音业务专用承载。这样,通过PCC架构,可以为VoLTE业务设置高优先级的QoS规则,从而保障语音通信的质量。
4.2 与基于LTE的OTT语音对比
OTT语音是上层应用业务,在LTE网络中底层承载将其认定为普通数据传输,于是OTT语音将与其它普通数据分组使用相同的Internet PDN连接的Non-GBR默认承载(QCI=8/9)。这将导致OTT语音与其它业务抢占公共带宽资源,引起OTT语音出现误码、丢包、时延大等一系列服务质量问题。因此,基于LTE的OTT语音业务无法得到有效的QoS保障。而对于VoLTE,前面提到其采用高QoS等级的语音及信令承载,且建立独立于普通数据业务的PDN连接,能在EPS域和IMS域获得良好的QoS保障。
同时,VoLTE对空口也作了进一步的优化。首先,RLC层采用UM模式,通过取消RLC重传机制来减少业务时延。其次,针对上行功率受限场景采用TTI Bunding技术,通过在同个HARQ进程连续发送相同RLC层分片4个不同冗余版本,以此来降低小区覆盖边缘VoLTE语音数据的误码率和时延。OTT语音采用普通数据处理机制,无法使用以上的优化特性。另外,由于通过软件方式完成会话建立及语音数据处理,OTT语音业务时延也相应增加。
从端到端来看,VoLTE业务走的是电信运营商具有高可靠性及安全性的内部网络。通过IMS域、EPS域及PCC架构的联合保障,语音业务端到端时延、误码率等服务质量都获得严格保证,这些都是OTT语音业务无法做到的。OTT分组数据需要通过Internet寻路至对端网络,而Internet一般采用无QoS保障的Best-Effort数据传输方式,这将导致OTT语音质量的进一步下降。
除了QoS无法得到可靠保障外,OTT语音在手机资源消耗、终端信道资源占用、异系统切换、异OTT应用兼容性等方面也得不到良好表现。对于这些问题,VoLTE采用底层数据处理、非连续性接收(DRX)、鲁棒性头压缩(RoHC)、半静态调度(SPS)、单载波语音呼叫连续性(SRVCC)等技术及本身拥有的特性,都能较好解决。在提高用户体验上,VoLTE可以采用高清语音、富通信套件(RCS)、增强富通信套件(RCSe)等丰富的业务形态来提高差异化优势。
5 结束语
VoLTE是电信运营商充分利用LTE网络在语音业务上演进的必然结果,它不单拥有传统的电信级QoS保障机制及业务特性,而且拥有新兴的如高清语音、RCS/RCSe的业务形态,在良好的服务质量和绝佳的用户体验上更能迎接OTT通信软件的挑战。当然,不论是从产业链及投入成本的角度,还是从网络演进策略的角度,要实现VoLTE还有很多问题需要考虑。但是,作为能充分利用先进网络技术并围绕提高用户感知体验,同时考虑运营商自身特点的VoLTE技术,相信在不远的将来必能得到广泛应用。
参考文献:
[1] GSMA IR 92.V7.0. IMS Profile for Voice and SMS[S]. 2013.
[2] GSMA IR 94.V6.0. IMS Profile for Video Service[S]. 2013.
[3] 3GPP TS 23.203. Policy and Charging Control Architecture[S]. 2013.
[4] 3GPP TS 23.207. End-to-end Quality of Service(QoS) Concept and Architecture[S]. 2012.
[5] 3GPP TS 23.228. IP Multimedia Subsystem(IMS) Stage2[S]. 2013.
[6] 3GPP TS 36.321. Medium Access Control(MAC) protocol specification[S]. 2013.endprint