WCDMA网络中引入TrFO技术的相关问题探讨

陈婉珺 赫 罡

【摘要】文章分析了TrFO对呼叫建立流程、参数设置的要求，以及TrFO编码协商失败时网络的处理方式，提出了在WCDMA网络中引入TrFO技术的具体实施建议。

【关键词】WCDMA TrFO Codec编码协商BICC

1引言

移动通信系统中，对语音信号进行多次编码转换，会降低语音质量。为了减少网络传输过程中语音编码转换的次数，UMTS在R4阶段引入了TrFO(Transcoder Free Operation)功能。使得呼叫双方在采用相同语音编解码的情况下，在网络中实现压缩语音的透传，从而提高语音质量。

而实际应用中发现，TrFO常常因呼叫流程、设备参数配置等原因。导致无法正常建立；且在TrFO协商失败时，各厂家的处理方式也不一致。

本文深入探讨TrFO技术在WCDMA网络中应用时，对呼叫流程、网络设备配置的特殊要求；并且对TrFO无法正常建立时。各厂家设备处理方式进行对比分析，从而给出在WCDMA网络中引入TrFO技术的具体实施建议。

2TrFO基本原理

TrFO采用带外编码控制(OoBTC，out of Band Transcoder Control)功能实现。UE之间TrFO连接的基本结构如图1所示。

移动至移动用户TrFO呼叫建立过程分为3个阶段：编解码协商阶段、网络侧承载建立阶段、RAB指配阶段。其中编码协商如图2所示。

发送端MSC Server发出的IAM消息中包含一个所支持的Codec list(该列表是O-MSCS查询到的发送端O-UE、O-RNC和O-MGW所支持的Codec的交集)；IAM消息途经的中间MSCS节点查看该列表，从中删除与其相关的MGW所不支持的Codec；接收端MSCS收到该列表后，从中删除接收端T-UE、T-RNC和T-MGW所不支持的Codec，从剩余的Codec list中选择一个：Selected Codec=v，通过APM消息告知发送端O-MSCS。

3TrFO对呼叫建立流程的要求

3.1TrFO呼叫流程问题分析

(1)early RAB Assignment流程

在呼叫建立过程中，为节省接续时间，可以采用earlyRAB Assignment的方式。即在寻呼被叫之前。也就是在APM消息返回之前，进行主叫侧RAB指配过程。early RABAssignment信令流程如图3所示：

RAB Assignment消息会根据会话所用的编码决定消息中的SDU参数。而此时，TrFO的编码协商流程尚未完成，主叫侧未收到APM消息，即并不知道SeIected Codec是什么。因此，主叫侧RAB Assignment消息中编码的选择只能根据主叫侧O UE、O-RNC和O-MGW所支持的Codec的交集进行选择，从中选择优先级高的Codec，并根据选择的Codec完成Iu口用户面的初始化。在接下来的Codec协商过程中。若O－UE、O-RNC和O-MGW所支持的Codec的交集包含多个Codec。那么主被叫双方协商后。可能会因为被叫侧原因(或中间传输结点原因)，使得双方最终选择的Select Codec与之前主叫侧RAB Assignment消息中包含的Codec不一致，从而导致TrFO协商失败。

若在收到APM消息之后。即完成编码协商过程之后再进行RAB Assignment过程，则可以根据编码协商的结果，按照双方选定的Codec确定SDU参数，从而避免上述问题，保证TrFO的实现。

(2)BlCC承载建立过程

网络侧承载建立是要建立O－MGW与T-MGW之间的承载，通过BICC承载建立过程实现，如图4所示。在MGW向MSCS发送的IPBCP请求；自息中需要指明为建立此次会话所需的会话属性和媒体属性等信息，其中媒体属性必须明确指出所采用的语音编码格式。因此，当Codec Iist中包含多个编码时，为了保证TrFO的实现，网络侧承载建立过程也必须在Codec协商过程之后完成。

BICC承载存在三种建立方式：前向快速、前向延迟、后向延迟。

◆对于前向快速方式，在IAM消息中包含了lPBCP的请求信息，也就是说在发端的MSC Server发送IAM之前，MGW就开始了IPBCP承载建立过程，Codec协商过程无法在网络侧承载建立过程之前完成，此时可能出现IPBCP请求消息中先选的Codec与编码协商后选择的Codec不一致的情况。

◆对于后向延迟方式，在IAM消息之后的后向APM消息中携带被叫侧MGW发起的IPBCP请求，之后主叫侧MGW收到该请求消息。做如下处理：①向被叫侧MGW发送Nb uP初始化消息；②以隧道方式向被叫MGW发送IPBCPAccept消息。因这两个消息发送渠道不同，可能导致IPBCPAccept消息晚于Nb UP初始化消息到达被叫MGW，使得初始化失败。

◆对于前向延迟方式，在第二个APM消息(前向APM消息)中携带IPBCP请求信息，此时编码协商过程已经完成，即主叫侧MGW可以在编码协商完成之后再发起IPBCP的请求信息。此时所选的编码已经确定，且该种方式是主叫侧MGW先发送IPBCP—Request，被叫侧MGW回复IPBCP_Accept，之后主叫侧MGW才发起Nb UP初始化消息，不会导致初始化失败。

3.2TrFo呼叫流程建议

综上所述。TrFO的实现对于单编码协商过程没有过多要求，而对于多编码协商过程，编码协商阶段必须在网络侧承载建立阶段和RAB指配阶段之前完成；对于RAB指配流程。不应当激活earIy RAB Assignment流程；对于网络侧承载建立阶段。推荐使用BICC的前向延迟承载方式。

4TrFO对参数设置的要求

4.1TrFO涉及的编码类型及主要参数

目前常用的语音编码主要有三种。应用于传统PSTN的PCM c脉冲编码调制)编码(即ITU-T G.711)、应用于GSM和UMTS的AMR(自适应多速率)编码以及应用于VolP的G，7XX系列编码。AMR编码又分为FR AMR、HR AMR、UMTS AMR、UMTS AMR2和OHR AMR五种编码类型。3GPP TS 26.103规定，对于UMTS／GSM双模终端，使用UMTS AMR2作为默认语音编码，实际运营中支持的UMTSAMR2也将是终端产品的主流；因此。在TrFO的实际应用中，一般使用UMTS AMR2类型的编码。

每种编码类型中，又可以进一步定义详细的模式。AMR2类型的编码中，定义了8种速率模式：12.2kbps，10.2kbps，7.95kbps，7.4kbps，6.7kbps。5.9kbps，

5.15kbps，4.75kbps。每一个Codec都会使用其中的一种或几种速率模式。对于AMR2类型编码，有以下几个主要概念：

◆Active Codec Set，ACS：指示当前编码中，哪些模式处于可以使用状态。ACS共8个bil，若某一模式对应的bit为1，则表示该模式包含在ACS中；若为O，则表示不包含在ACS中。

◆Supported Codec Set。SCS：指示当前编码中，哪些模式是网络支持的(从能力上来说)。SCS也是8个bit，若某一模式对应的bit为1，则表示该模式包含在SCS中；若为0，则表示不包含在SCS中。SCS至少应当包含ACS中所有的模式。

◆Maximal number Of codec modes in the ACS，MACS：用于Supported Codec List和Available Codec List中，用来限制Selected Codec中可以包含的最大模式数。

◆Optimisation Mode for ACS，OM：指发送端(主叫端)是否允许接收端(被叫端)修改ACS中的内容。当OM=0(not supported)时，被叫端如果能够支持ACS中所有的模式，则响应支持该编解码；如果ACS中有任一模式不支持，被叫端都响应不支持该编解码。当OM=1(supported)时，被叫如果不支持ACS中的某一种(或某几种)模式，仍可以响应支持该编解码，但是指明只支持ACS中的某一种(或某几种)模式。

当UMTS AMR2用于带外编码协商时，每个Codec中，最少包含1种、最多包含4种速率模式。ACS中包含的速率模式不同，即可以组成不同的Codec，同时选择OM=0或1，就有不同的配置组合。3GPP一共为UMTS AMR2类型的编码推荐了16种不同的配置组合，如ACS=(5.9，4.75)，OM=0，即为一种配置组合。

在TrFO的编码协商过程中，通过控制面消息确定通话所使用的Codec，通过用户面消息对选定的Codec中的各个速率模式进行初始化，最终用户面数据流会优先使用Codec中最高速率模式进行通信。

4.2TrFO参数设置建议

多种配置组合增加了TrFO编码协商的灵活性，同时也增加了协商过程的复杂性。对网络设备提出了很高的要求，即要求所有参与的设备(手机终端、无线节点、MGW节点等)都支持这些配置组合，否则可能导致呼叫失败。而实际上很多网络设备和终端并不支持较低的速率，在这种情况下，要求OM=1，进一步增加配置的灵活性是没有意义的。因此。应当根据实际情况尽量简化编码的配置组合，目前3GPP推荐的速率模式为12.2kbps、7.4kbps、5.9kbps和4.75kbps四种，且不推荐使用OM=1的设置。实际应用中，应当从协商流程的简化、安全、稳定的角度考虑，尽量减少对配置组合的要求。

5TrFO编码协商失败场景分析与建议

实际应用中，实现TrFO需要在MSCS上配置MGW和RNC支持的Codec list，配置方式主要可以分为两种：

(1)不区分Nb口和Iu口配置，在MSCS上配置本端RNC和MGW支持的Codec list的交集。

(2)MSCS上区分Nb口和1u口的配置，Nb口配置的Codec list即为MGW支持的Codec list，Iu口配置的Codeclist即为RNC支持的Codec list。

因为配置方式不同。当TrFO编码协商失败时，网络设备的处理方式也不相同。

作为局问呼叫主叫MSCS时，这两种配置方式没什么区别，在IAM消息中发送的Codec list均为RNC、MGW以及终端支持的Codec list的交集。

作为被叫MSCS时，若采用方式(1)，如图5所示。被叫MSCS检查IAM消息中的SCL和本端配置，包括被叫终端支持的Codec情况，如果没有兼容的Codec，即回复G.711。查询双方TrFO状态均为关闭，主被叫MGW中均插入TC。

若采用方式(2)，如图6所示，被叫MSCS检查IAM消息中的SCL和本端配置，如果SCL和Nb口配置的Codec list不存在交集，即回复主叫侧G.711；如果SCL和Nb口配置存在交集，和Iu口配置没有交集，那么被叫MSCS会选择SCL和Nb口配置的交集中优先级最高的Codec作为SelectedCodec，主叫侧根据返回的SeIected Codec进行RABAssignment和用户面初始化。查询主叫侧TrFO状态为开启状态，MGW中未插入TC。而被叫侧TrFO状态为关闭状态，在MGW中插入TC，将核心网的编码转化为Iu口支持的编码在lu口进行传输。

这种方式，在本端不可能开启TrFO的情况下，优先选择对方支持的最高优先级的编码，尽量保证对方TrFO开启。使得TrFO得以分段实现，对整个通话过程没有负面影响，保证通话的语音质量。因此实际部署时，可以结合具体网络情况及设备功能进行选择。

6结束语

综上所述。在WCDMA中引2kTrFO技术有以下几点建议：

(1)为了保证TrFO能够正常建立，要求网络侧承载建立阶段、RAB指配阶段必须在编码协商阶段完成之后进行。因此，引入TrFO技术时，不能选用early RAB Assignment流程，同时，BICC的lP承载建立方式应当选用前向延迟方式。

(2)多编码、多速率配置增加了编码协商的灵活性，但同时会使设备操作变得复杂。考虑到设备支持程度以及简化协商流程的要求，因厂家普遍对12.2k的TrFO支持较好，且WCDMA网络建设初期网络负荷较低，使用12.2k可以满足要求，因此建议网络建设初期仅要求支持12.2k的单编码单速率的TrFO；随着WCDMA网络负荷的不断增加，采用低速率的编码能够降低无线小区负荷，因此网络建设后期可考虑引入多速率的TrFO。

(3)对于TrFO编码协商失败场景，目前存在的两种处理方式都可以保证通话正常建立，因此都可以接受。

随着网络的演进，下一代网络，必然是多协议多终端互联互通的异构网，而不同终端间频繁的编码转换，必然导致通信质量降低。在WCDMA系统中引入TrFO和软交换技术，对移动运营商提高业务服务质量和降低运营成本具有重要意义。