基于VOLTE的网络语音切换问题

林立引

基于VOLTE的网络语音切换问题

林立引

在VOLTE网络建设初期，VOLTE无线覆盖不足，发生eSRVCC切换次数较高，语音切换问题较多，严重影响着VOLTE业务的正常开展。本文根据实际运营中遇到的VOLTE语音切换问题，在深入分析问题原因的基础上，提出了相应的解决方案，并取得了良好的效果。

VoLTE（Voice over LTE）是一种基于全IP数据传输技术，可实现数据与语音业务同时在同一网络下承载1，换言之，VOLTE网络下不仅仅提供高速率的数据业务，同时还提供高质量的音视频通话，是提升网络业务能力、应对互联网竞争的重要手段，是移动核心网演进的目标架构。在VOLTE建网初期，支持VOLTE功能的无线基站覆盖不足、不连续，为了保证用户感知，保证语音呼叫连续性，中国移动部署eSRVCC （Enhanced Single Radio Voice Call Continuity，增强的单一无线语音呼叫连续性）切换技术， 在VOLTE业务部署初期，eSRVCC语音切换成功率较低，仍有较多技术问题亟需解决。

VOLTE语音切换解决方案

SRVCC（Single Radio Voice Call Continuity）是3GPP提出的一种VoLTE语音业务连续性方案2，主要是为了解决当单射频UE 在LTE/Pre－LTE 网络和2G/3G CS 网络之间移动时，如何保证语音呼叫连续性的问题，即保证单射频UE 在IMS 控制的VoIP 语音和CS 域语音之间的平滑切换3。在用户从4G网络向2G/3G网络漫游时由用户终端通过Sv接口触发PS到CS的语音业务切换4。 本端用户呼叫时发生移动，允许本端终端的IP地址重新分配。MSC会代替终端发起SRVCC切换请求，同时，本端手机与MSC之间的CS域连接也会建立，并与SCC－AS（TAS）之间建立一个新的本端呼叫路径，提供一个新的本端媒体地址给SCC－AS，SCC－AS会通过媒体切换过程让通话两端的媒体层连接重新建立。切换后，SIP层信令连接和RTP层媒体连接会在原通话两端重建，如图1所示。

中国移动VOLTE语音切换方案

为了提升用户感知，中国移动采用eSRVCC语音切换方案，作为SRVCC的增强版本5，eSRVCC在SRVCC网络架构的基础上增加了接入侧的信令（ATCF）和媒体锚定点（ATGW），媒体的锚定由ATGW完成，信令的锚定由ATCF和SCC－AS共同完成，这个改变可以减少远端更新（Remote Update）的信令传输时间，从而减少切换时延，如图2所示。

在eSRVCC方案中，在信令面，用户通过ATCF进行信令面的锚定，与2/3G的MSC server建立信令连接；而在媒体面，则通过ATGW进行媒体锚定，并分配CS域的媒体资源，信令流程如图3所示。

（1）本端用户发生LTE覆盖向2/3覆盖的移动时，IP地址重新分配。

（2）MSC server向ATCF发起切换请求（携带STN－SR和C－MSISDN）。

（3）ATCF信令锚定后通过ATGW媒体锚定分配媒体资源。

（4）ATCF向I/S－CSCF、SCC AS请求建立新的呼叫路径（携带ATU－STI和C－MSISDN），并提供新的本端地址。

（5）SIP层信令连接和RIP层媒体连接重建，新的呼叫会话建立。

图1 SRVCC工作原理图

图2 eSRVCC工作原理图

通过分析VOLTE语音呼叫切换流程，可以将可能导致VOLTE语音切换成功率下降的要素分为以下几个方面：用户IP地址解析失败、信令消息解析失败、信令消息的接收与发送失败、锚定失败、切换时延过长导致失败和网元接口不匹配导致失败。

VOLTE网络中语音切换存在的问题及解决方案

会话描述协议（SDP）媒体描述配置不当

根据中国移动VOLTE语音切换流程，呼叫的锚定由ATCF与SCC－AS共同完成，ATCF使用Megaco协议调用ATGW完成媒体资源的重新分配后（使用原主叫的context－ID，目的是建立原呼叫与切换呼叫的媒体通道），ATCF发送invite（被叫是ATU－STI，主叫是用户PUI）给SCC－AS（启用与切换Invite请求不同的新Call－leg）。切换后原信令leg被ATCF或SCC－AS释放。而跟踪切换信令发现，ATCF并没有调用ATGW，向SCC－AS发出的Invite请求仍然使用eMSC切换Invite请求的Call－ID，没有启用新的Call－leg，媒体面地址也只是透传了eMSC的媒体面地址。上述流程可以看出，ATCF并没有起到锚定作用。信令包截图如图4所示。

通过更广泛的信令包检查发现，由于主叫用户在注册入网时所分配的媒体参数的不同，ATCF在向ATGW申请媒体资源时所发送的INVITE切换请求的媒体编码存在差异，原呼叫回应消息（183）与切换请求INVITE必须携带相同的媒体组合才能成功触发媒体资源的建立。原呼叫回应消息（183）携带的媒体编码为AMR 8000和telephone－event 8000，而部分切换请求INVITE存在telephone－event 8000编码缺失的情况，这就导致了媒体参数在此处的不匹配，进而引起切换的失败。

ATCF中的接入域（access realm）参数设置不当

VOLTE语音切换前后的媒体面均由ATCF调用ATGW分配。SAE－GW分配给主被叫的均为IPv6地址。ATCF调用ATGW使用realm的Megaco协议分配媒体资源实现互通，realm分为access realm（与用户分配的IP地址互联（IPv6）），以及core realm（内部互联，实现主被叫媒体面互通（IPv4））。由于目前移动网络中的UE使用的是双栈协议的模式，因此在用户在注册到网络时，会被随机分配两个格式（Ipv4、Ipv6）的IP地址之一。当通过ATCF进行了信令面的锚定后，就开始通过ATGW建立媒体面的连接，并由eMSS分配媒体GSM的媒体资源。而eMSS和对端用户使用的是Ipv4协议，这就可能导致了如果主叫端被分配的IP地址为Ipv6格式，那么与远端的媒体连接就可能无法成功建立，导致切换失败。媒体连接建立交互图如图5所示。

通过抓取信令包来具体分析，以看出媒体面建立的工作原理。

图3 VOLTE语音切换流程图

图4 锚定失败信令包截图

图5 媒体连接建立示意图

图6 被叫送达失败信令包截图

（1）ATGW为属于同一组realm内的媒体实现连接，然后再与主被叫或切换呼叫的媒体地址连接，实现媒体互通。

（2）初始呼叫access realm（2）分配IPv6地址与主被叫地址互联，core realm（101）分配IPv4地址互联。

（3）被叫切换后，仍然使用access realm（2）实现对外连接，而被叫地址换成了eMSS的IPv4地址。

首先从切换后的两组realm分析，access realm（2）在切换前的呼叫中保存主被叫的IPv6地址，切换后全部替换成了IPv4地址，此时主叫的IPv6地址对应关系也未能保存，查看rtp媒体流也可以发现切换后主叫媒体为单向流，而且未能送达被叫，信令截图如图6所示。

解决对策一：修改编码，使SBC/TAS为INVITE添加telephone－event/8000编码使之与被叫的183回复消息相匹配。

为解决SDP媒体参数问题，制定图7所示的对策实施流程图。

图7 对策实施一流程图

图8 ATCF锚定失败信令包截图

图9 原呼叫信令包截图

实施步骤一：锁定锚定失败的环节

通过对ATCF网元内部消息的跟踪发现如下抓包记录（见图8）：

从信令抓包中能够看出，ATCF能够匹配原呼叫的信息，在试图进行eSRVCC切换时报如下错误：

[SDP codec check][RETURN] DTR/eSRVCC is NOT possible.Enum returned value：CmpEqual_mismath

ATCF报错后无法启用锚定功能，只作为代理中转了呼叫。

实施步骤二：分析具体原因

进一步跟踪信令发现，ATCF未实现锚定功能是由于SDP codec检查不通过。查看原呼叫的信令，被叫回复的183消息携带协商后的媒体携带AMR/8000与telephone－event/8000编码，183消息到达主叫的ATCF后，ATCF使用这两种编码请求ATGW修改媒体面地址和编码（见图9）。

参考RFC2833与RFC2198的描述，ATCF仅仅采用单个RTP静荷向ATGW请求分配媒体面地址。系统参数如下：

RFC2833：

MIME Registration

audio/AMR

图10 SBC现有媒体编码

图11 添加TELEPHONE－8000媒体编码

图12 发起锚定成功信令包截图

MIME media type name： audio

MIME subtype name： AMR

Required parameters： none.RFC2198：

m=audio 12345 RTP/AVP 121 0 5

a=rtpmap：121 AMR/8000/1

a=fmtp：121 0/5

实施步骤三：修改配置，解决问题

进入SBC的系统MM脚本可以看到目前系统中现有的媒体编码（见图10）：

从中发现，系统中并未开启telephoneevent 8000的添加功能。接着进入参数配置页面对telephone－event 8000编码进行添加，结果如图11。

实施效果

编码添加之后，再次对切换时的信令进行跟踪，发现INVITE消息已经成功添加了telephone－event 8000编码，ATCF正常向发起了ATGW媒体锚定请求，信令截图如图12。

图13 对策二实施流程图

图14 核心侧realm配置图

图15 修改接入侧realm配置图

图16 切换成功信令包截图

解决对策二：将接入侧的realm调整为与核心侧realm相同的配置

为解决接入域（access realm）参数问题，制定图13所示的对策实施流程图。

实施步骤一：锁定连接建立失败的环节

通过跟踪信令流程锁定了问题发生的节点：主叫方在进行切换时需要通过ATCF向eMSS申请媒体资源，在媒体资源分配后，则开始通过eMSS建立主被叫之间的媒体通道，而问题就发生在主叫与eMSS之间的媒体建立。

实施步骤二：确认核心侧的realm配置

为了使接入侧的realm配置与核心测相同，从而成功建立主被叫之间的媒体连接，首先需要明确核心侧的realm配置。通过跟踪过往语音切换流程，可以确认当前现网环境下的GSM核心侧realm配置为realm 101，信令包如图14所示。

实施步骤三：对接入侧realm采用realm 101配置方式

要与原有呼叫媒体建立关联，在ATCF的ACCESS NETWORK表中关于eMSS行使用的接入侧realm（realm2）置为与原来呼叫核心侧realm（realm101）相同。修改后信令包结果如图15。

实施步骤三：效果检查

采取设置后，接着对语音切换信令流程进行跟踪，发现ATCF会使用eMSS发出的切换请求里面的媒体地址与端口替换掉切换方原来呼叫存在于核心侧realm中的媒体地址与端口，并且与被叫方access realm建立关联，切换成功，主被叫双方能正常通话，媒体流交互正常，对策实施成功。信令包如图16所示。

通过以上两项对策后，VOLTE语音切换成功率达到了93.62%，提升10.7%，取得不错的效果。

结束语

语音切换是VOLTE网络中的一项基本业务场景，本文分析了语音切换问题在现网中具有一定的典型性，随着VOLTE技术的不断成熟，基于VOLTE网络中的语音切换的各项技术也将不断规范和进一步完善。

林立引

中国移动通信集团福建公司福州分公司

林立引，中级工程师，2006年北京邮电大学计算机科学与技术专业本科专业毕业，现任职于中国移动集团福建公司福州分公司，主要从事软交换、VOLTE等移动核心网的维护管理工作。

10.3969/j.issn.1001-8972.2016.09.016