trfo不同速率和承载建立方式说明.doc

TrFO不同速率和承载建立方式说明 拟 制 邵强 审 核 会 签 深圳市中兴通讯股份有限公司 内部公开编写目的本文对CS子系统中TRFO功能基本概念及用户面数据流加以简要描述，使读者对TRFO功能建立整体性概念。参考协议3GPP TS 24.0083GPP TR 25.953 V4.0.0: Transcoder free operation3GPP TS 23.153 V4.4.0:Out of band transcoder control3GPP TS 25.415 V4.2.0:UTRAN Iu interface user plane protocolsTrFO与TFOTrFO(Transcoder Free Operation)呼叫是一种呼叫建立过程中通过带外（呼叫控制信令）对语音编解码方式进行协商，如果整个呼叫链协商结果使用相同的语音编解码方式，那么在用户面就不需要插入Transcoder的一种呼叫模型。TrFO呼叫因为不需要插入语音编解码器，所以可以提高话音质量，节约编解码器资源；并且在分组核心网中可以节约网络带宽，因为话音是AMR速率而不是64kbit/s在核心网中传输；另外，编解码协商在承载建立之前完成，可以保证呼叫使用适当的承载资源。TFO(Tandem Free Operation)是一种带内的编解码协商协议，是在2G网络中已定义的方法。TFO在呼叫建立之后在两个语音编解码器之间对编解码进行协商，协商成功后发送方的解码器和接收方的编码器被旁路，直接将空中接口中使用的话音帧传送给接收方。同样因为用户面码流不再需要通过语音编解码器的压缩解压缩处理，这样可以同样改善话音质量。TFO功能是在标准的64kbit/s链路的基础上，提取一定数量的比特，组成子信道，用来传输TFO信令和话音帧。将两种编解码协商方式相比，相同点就是在局间都直接传送AMR编码，能够提高语音质量；但对TrFO方式，因为局间只传AMR码流，可以节省带宽，而TFO的AMR码流是嵌在G.711码流中的，局间传的还是G.711码流，因此并不能够节省带宽，传送速率也没有改善；TrFO能够真正免除编解码器，而TFO要求系统中仍然有编解码器，用于AMR-G.711的编码；TrFO因为是带外协商编解码，操作简单，TFO是带内协商方式，相对复杂。TrFO机制描述以R4中UMTS 到UMTS TRFO连接加以例举：OoBTC（Out of Band Transcoder Control） 对于建立TRFO是必不可少的，用来建立带外呼叫时协商编解码器类型及模式。图中所示过程发生在呼叫建立阶段TrFO的前提是RNC和MGW都支持UP mode2，否则只能支持非TrFO。对于非TrFO模式，MSC Server和MS采用隐含方式选择Codec模式。l 3G-3G 要求RNC，MGW版本支持UpVer=2l 3GBICCBICC3G要求局间中间节点都支持编解码协商，RNC，MGW支持UpVer=2 配置时应注意：对于支持R4的终端来说，对于MO呼叫，MS在Setup消息中携带SCL参数，对于MT呼叫，MS在CallConfirmed消息中携带SCL参数。对于R99终端和GSM终端，MS并没有告诉Network 自己支持的SCL参数，这时需要网络自己来构建SCL。缺省Codec类型终端类型确省Codec类型备注R99 UMTS onlyUMTS_AMRsupporting GSM and UMTSUMTS_AMR_2注 ：对于UMTS_Only终端，如果没有从UE收到SCL参数，则MSC将假定UE支持UMTS_AMR。对于“双系统”（同时支持GSM和UMTS）终端，如果没有从UE收到SCL参数，则MSC将假定UE支持UMTS_AMR_2。如果UE在BC的3a.etc中携带了一个及以上的GSM speech version参数，则标识这个UE是“双系统”终端（参见24008 协议）。UMTS_AMR_2是UMTS_AMR的超集，上行同FR_AMR，下行同UMTS_AMR。这样就允许UMTS终端同GSM终端通过TFO进行互通。UMTS_AMR_2同UMTS_AMR可以在TFO和TrFO下进行互通，完全相互兼容。如果UE同时支持UMTS_AMR和UMTS_AMR_2，则MSC在OoBTC协商时，应该只携带UMTS_AMR_2。当MSC收到的SCL中包括UMTS_AMR_2，而自己只支持UMTS_AMR，则返回UMTS_AMR。当MSC收到的SCL中包括UMTS_AMR，而自己支持UMTS_AMR_2，则返回UMTS_AMR。Codec模式选择对于CN发端节点，在同一个终端CN节点进行语音业务协商时，应该指定Codec的最大模式数目。当终端CN节点收到编解码列表信息后，同自己支持的编解码列表进行比较，得到交集。这个交集，是实际的激活的Codec，称为SC。当一个或多个TrFO链已经建立并初始化后，如果一个CN节点（例如在CH补充业务和CF补充业务时）发起一个后续的Codec协商，应该对已经选择的Codec类型，包括对应的ACS，给予最高的优先级。这样减少对已经建立的TrFO链进行承载修改和UP重新初始化的可能。当MSC请求进行RAB指配时，RNC在初始化时，应该接受全部的RFCI，或者不接受。MSC应该总是假定“DTX”功能是必选的，应该在协商的Codec类型上增加“SID”SDU。当MSC已经选择了公共的ACS后，就可以采用这个ACS来构建RAB指配参数了，GBR对应最低的码速率，MBR对应最高的码速率。对于MCC可以进行RAB指配的条件1. 已经选定了Codec，这样可以由Codec确定RFCI参数。2. 已经选定了MGW（获取终端ID），这样可以得到TransportAddr和BindID两个参数。用户数据流Iu口对于同一MGW内部的TrFO呼叫，其用户数据流向如下图所示。通过接口板接入的Iu口用户数据，经过AAL2适配（对于ATM承载）或RTP/RTCP处理（对于IP承载）后，根据转发表送到某个IuUP实例作上行处理，然后送到对端用户对应的IuUP实例作下行处理，最后接口板处理并送到Iu口上。整个流程无需经过AMR编解码和TDM交换。 图1同一MGW内部的TrFO呼叫Nb口对于不同MGW之间的TrFO呼叫，其用户数据流向如下图所示。在一个MGW上，通过接口板接入的Iu口用户数据，经过AAL2适配（对于ATM承载）或RTP/RTCP处理（对于IP承载）后，根据转发表送到某个IuUP实例作上行处理，然后送到Nb接口对应的NbUP实例作下行处理，最后Nb接口板处理并送到Nb口上。在另一个MGW上，通过Nb口接入的用户数据在接口