中国移动A接口IP化技术规范V1

QB-A-004-2009中国移动通信企业标准QB-A-004-2009中国移动A接口IP化技术规范China Mobile A interface over IP Technical Specification版本号：1.0.02009-4-1实施2009-4-1发布中国移动通信集团公司 发布目录前 言III1.范围42.规范性引用文件43.术语、定义和缩略语74. 要求75. 网络架构和应用场景85.1网络架构85.2 应用场景106. 用户面116.1用户面工作原理116.1.1AoIP传输网络的用户面116.1.2 AoIP传输网络的控制面116.1.3对Nb和Nc接口的潜在影响126.2载荷格式126.2.1 语音RTP profile126.2.1.1 AoIP接口的G.711编码语音RTP profile126.2.1.2 AoIP接口的压缩语音RTP Profile126.2.2 数据和传真呼叫RTP Profile126.2.2.1BSS具有速率适配的数据和传真呼叫RTP Profile126.3传输层136.3.1 链路层和物理层136.3.2 UDP和IP136.3.3 RTP136.3.4 RTCP136.3.5 IP复用146.4切换过程 （用户面）146.4.1 一般切换过程146.4.2 至兼容目标小区的BSC内部切换146.4.3 至不兼容目标小区的BSC内部切换146.4.4 BSC之间的切换146.5时间和相位校准157. 控制面157.1控制面工作原理157.1.1传输层信息交换157.1.2 AoIP的呼叫ID177.1.3 编解码信息交换177.1.3.1 呼叫建立过程中编解码信息的交换187.1.3.2 切换期间编解码信息交换197.1.4 BSS或CN中的TC资源的位置207.1.5 RTP参数交换207.2信令消息207.2.1BSSMAP207.2.3DTAP207.2.4GCP（H.248 协议）207.3过程207.3.1呼叫建立时的编解码协商207.3.2切换期间的码型协商227.3.2.1至兼容目标小区的BSC内部切换227.3.2.2至不兼容目标小区的BSC内部切换227.3.2.3BSC间的切换238.编制历史24前 言本标准依据ITU-T和3GPP制定的相关标准，结合有关国内标准和中国移动其他企业标准，基于中国移动当前GSM网络情况和实际需求而拟定，充分考虑了网络的平滑演进能力，为中国移动BSS IP化的技术试验、网络建设和运行维护提供技术依据。本标准主要包括以下几方面内容：网络架构、用户面、控制面等各方面的要求。本标准是网络IP化系列标准之一，该系列标准的结构、名称或预计的名称如下：序号标准编号标准名称1QB-A-004-2009中国移动A接口IP化技术规范V1.0.02QB-A-005-2009中国移动Abis接口IP化技术规范V1.0.03中国移动Gb口IP化技术规范V1.0.0本标准由中移技200993号印发。本标准由中国移动通信研究院提出，集团公司技术部归口。本标准起草单位：中国移动通信研究院 本标准主要起草人：王帅宇、段晓东、杨光、魏冰、黄宇红 241.范围本标准规定了规定了A接口用户平面IP化在组网架构、用户面、信令面等方面的要求，为中国移动引入提供技术依据，供中国移动内部和厂商共同使用；适用于A接口IP化的技术试验、网络建设和运行维护。2.规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。序号标准编号标准名称发布单位1TR 21.905Vocabulary for 3GPP Specifications3GPP2TS 23.205Bearer-independent circuit-switched core network3GPP3TS 25.415UTRAN Iu Interface User Plane Protocols3GPP4TS 48.006Signaling Transport Mechanism Specification for the Base Station System - Mobile-services Switching Centre (BSS - MSC) Interface3GPP5TS 23.002Network architecture (Release 8)3GPP6TS 48.008Mobile Switching Centre - Base Station System (MSC-BSS) interface Layer 3 specification3GPP7TS 48.060In-band control for remote transcoders and rate adaptors for full rate traffic channels3GPP8TS 48.061In-band control for remote transcoders and rate adaptors for half rate traffic channels3GPP9TS 26.103Speech Codec list for GSM and UMTS3GPP10TS 29.802(G)MSC-S - (G)MSC-S Nc Interface based on the SIP-I protocol3GPP11TS 23.153Out of band transcoder control; Stage 23GPP12TS 23.231SIP-I based circuit-switched core network; Stage 23GPP13TS 29.414Core network Nb data transport and transport signalling3GPP14TS 25.415UTRAN Iu interface user plane protocols3GPP15TS 29.415Core Network Nb Interface User Plane Protocols3GPP16TS 28.062Inband Tandem Free Operation (TFO) of speech codecs; Service description; Stage 33GPP17TS 26.093Mandatory speech codec speech processing functions Adaptive Multi-Rate (AMR) speech codec; Source controlled rate operation3GPP18RFC 4040RTP Payload Format for a 64 kbit/s Transparent CallIETF19RFC 3551RTP Profile for Audio and Video Conferences with Minimal ControlIETF20RFC 768User Datagram ProtocolIETF21RFC 791Internet ProtocolIETF22RFC 792Internet Control Message ProtocolIETF23RFC 2460Internet Protocol, Version 6 (IPv6) SpecificationIETF24RFC 4443Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) SpecificationIETF25RFC 4867RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio CodecsIETF26TS 29.232Media Gateway Controller (MGC) - Media Gateway (MGW) interface; Stage 3IETF27TS 29.332Media Gateway Control Function (MGCF) - IM Media Gateway (IM-MGW); Mn interfaceIETF28TS 48.103Base Station System - Media GateWay (BSS-MGW) interface; User plane transport mechanismIETF29TS 23.009Handover proceduresIETF30TS 24.008Mobile radio interface Layer 3 specification; Core network protocols; Stage 33GPP31RFC 3555MIME Type Registration of RTP Payload FormatsIETF32RFC 3556Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) BandwidthIETF33RFC 4566SDP: Session Description ProtocolIETF3.术语、定义和缩略语下列术语、定义和缩略语适用于本标准：词语解释Codec Type指下列任意现有的编解码类型。例如：GSM_FR, GSM_HR, GSM_EFR, FR_AMR, HR_AMR,FR_AMR-WB, see 26.103.Codec Configuration主要用于AMR和AMR-WB时，用于在呼叫期间指定设定的模式。例如：NB-Set1 = (12.2) 7.4 5.9 4.75WB-Set0 = 12.65 8.85 6.60Compatible Codec Configurations不需要进行代码转换的编解码配置，尽管编解码类型和配置可能不同。例如： FR_AMR(set 1) to HR_AMR (set 1), 等等FR_AMR 12.2 7.4 5.9 4.75 to HR_AMR 7.4 - 5.9 - 4.75A-Interface TypeA-接口具有不同的类型。例如：AoTDM 或 AoIP (目标)AoIPA over IP，使用IP链路作为A-接口用户面的承载AoTDMA over TDM，使用TDM链路作为A-接口用户面的承载Call Identifier一个MSC内唯一的Call-ID号码GCPGateway Control Protocol（网关控制协议） (H.248)MS-SCLMobile Station Supported Codec List （移动台-支持的编解码列表）RanCRadio Access Network Codec Type（无线接入网编解码类型）（用于GSM无线接口）SCLSupported Codec List（支持的编解码列表）(在OoBTC中)SCSelected Codec （选中的编解码）(在OoBTC中)SCVLSpeech Coder Version List（语音编码器版本列表）4. 要求1) BSC-MGW 接口(用户面)的传输协议必须基于IP。2) 对传统设备和所有GERAN MS/UE必须没有影响。3) 必须支持使用TDM接口的传统BSC。4) 必须支持TrFO。5) 任何建议的解决方案不能妨碍使用GERAN Rel-8支持的任何现有语音编解码（其中包括GSM EFR、GSM FR、GSM HR、AMR-WB、AMR-FR和AMR-HR）。6) 能够重新使用2G/3G MGW/MSC硬件。7) 在BSC-MGW接口上必须支持所有为GSM定义的基本电信业务、承载业务，VGCS和补充业务。8) 必须对GERAN 无线接口（Um接口）没有影响。9) 必须对BTS硬件和软件没有影响。但有一个例外是，在BSC (FFS)移除TC的情况下，可能对BTS的软件有影响。10) 必须支持A-flex。11) AoIP不需要TFO功能。12) 支持用户面的复用功能。13) 支持GSM/AMR Codec适配功能，例如，在BSC或无线环境过负荷的情况下。GSM/AMR Codec适配延迟必须与现有的A-接口解决方案具有相同的顺序。14) 端到端语音时延不能增加。IP传输网络的拥塞可能会引入附加的时延，但端到端的语音延时不能超过ITU建议G.114的要求。15) 确保BSC-MGW接口的可靠性（参见下面的e)条款）。16) 能够自动配置IP地址和传输层端口（例如，RTCP, UDP端口数量）。是否能够进行人工配置是FFS。17) 切换期间的语音中断次数必须与现有的TDM实现方式具有相同的状态。18) 在MS至MS的呼叫中，动态AMR Codec变更和TrFO的互动不应该降低语音的总体质量。19) 必须满足在规范45.010第5章规定的BTS同步要求。实现这一要求的方法与特定的实施方式是相关的。20) 能够从现有的A-接口平滑过渡到新的基于IP的A-接口5. 网络架构和应用场景5.1网络架构如图5.1.1所示，现有的A-接口在原有使用TDM信令传输的基础上增加了的基于IP的信令(SIGTRAN)。但对于用户面来说，只定义了TDM传输，并且代码转换功能均位于BSS设备中。为TDM A-接口定义的编解码只有PCM (G.711)。另外，利用TFO可以通过TRAU和MGW之间的PCM链路传送压缩的语音。注：TRAU模块包含编解码转换器（以下简称TC），它位于BSS设备之中。图 5.1.1: 现有基于TDM的A-接口（TC在BSS）基于IP的传输协议能够提供成本低廉的中间网络，这些网络的CAPEX和OPEX均能够大幅降低。AoIP还能够简化MSC池（MSCs in a pool）的实施。此外，UTRAN网络和进一步演进的RAN能够与GERAN一起使用共有的IP回程链路（IP backhaul）。为了能够在用户面实现VoIP，必须要求相应的解决方案既简单又灵活以便满足目前网络的各种不同网络实施要求。例如，该解决方案必须支持TC位于MGW的网络实现情形(参见图 5.1.2)，并且还必须确保能够从现有的GSM网络平滑过渡到基于IP的A-接口(例如，图5.1.3的TC仍然位于BSS之中)。图 5.1.2:压缩语音over IP的网络结构，其中BSS不含TC图 5.1.3: G.711 over IP的网络结构5.2 应用场景A接口IP化方案应支持以下场景，如表1所示：实施方案范例TC位置AoTDMAoIPBSS 版本CN 版本现网场景所有Codec类型均在BSS中是，只有G.711否传统版本传统版本AoIP场景1根据Codec类型选择是，只有G.711是，G.711和3GPP Codec升级版本升级版本AoIP场景2所有Codec类型均在CN中否是， 只有3GPP Codec没有TC的版本 新的版本AoIP场景1适用于现有基于TDM的BSC向支持AoIP网络的过渡阶段。为了确保平滑过渡，在过渡阶段，基于TDM和基于IP的方案均需支持作为一种影响最小的过渡方案，对于所有新的呼叫，其在交换点之后的建立过程，必须基于IP传输，而现有呼叫仍基于TDM传输，直至其释放或切换至IP传输。作为上述这种影响最小的过渡方案的一种变化方案，在交换点之后，所有的话务负荷应该根据运营商预先设置的百分比（例如，90的所有新呼叫在TDM上建立，10的新呼叫在IP上建立）分配至TDM和IP传输。对于特定的呼叫，A-接口类型（TDM或IP）应该由分配过程（Assignment procedure）来确定。分配请求（Assigment Request）和切换请求（Handover Request）不使用双重占用方式。为了避免在过渡期间在核心网中使用不必要的代码转换器，处于过渡状态的BSC必须同时支持基于IP的PCM传输和基于IP的压缩语音。对于基于AoIP的新部署的BSC（适用于AoIP场景2），只需支持基于IP的压缩语音。MGW必须支持IP和TDM两种连接，以便能够与新部署的BSC（即只能支持IP连接）、传统BSC（即只能支持TDM连接）以及升级之后的BSC（即同时支持IP和TDM连接）相连。6. 用户面6.1用户面工作原理6.1.1AoIP传输网络的用户面 语音和CS数据或传真的有效负荷均封装在RTP包中并且由UDP/IP协议栈传送。物理层和相应的IP协议链路层的特定传送路由不受限制。例如，如果采用以太网，则链路层使用MAC协议；而如果采用POS 或 IPoE1，则链路层使用PPP协议。A-接口用户面传输工作原理如图 6.1.1.1所示。L1+L2IPUDPRTPPayloadL1+L2IPUDPRTPPayloadBSCMGW图 6.1.1.1：用户面传输：AoIP协议栈6.1.2 AoIP传输网络的控制面核心网和BSS之间的IP地址和UDP端口号码的交换通过GCP和BSSAP进行。对于语音呼叫来说，BSS和MSC-Server通过BSSAP协商为无线接口确定编解码类型和编解码配置、为A-接口用户面（TDM或IP）确定A-接口类型以及确定TC资源位置（位于BSS或CN中）。对于数据和传真呼叫，BSS和MSC-Server通过协商进行RTP打包、为A-接口用户面（TDM或IP）确定A-接口类型，由BSS确定速率适配位置。6.1.3对Nb和Nc接口的潜在影响关于对Nb和Nc接口的影响，请参考TS 26.102，TS 26.103和TS 23.153。6.2载荷格式6.2.1 语音RTP profile6.2.1.1 AoIP接口的G.711编码语音RTP profile当AoIP接口使用PCM (G.711)编码语音时，则必须使用RFC 3551 19。当使用PCM编码语音时，帧长为20 ms。冗余机制不适用。6.2.1.2 AoIP接口的压缩语音RTP Profile目前GSM使用的编解码类型和可用RTP profile如下所示：GSM_FR: RFC 3551 19。GSM_HR: 由GP-081377给出定义。（需要IETF进一步批准）。GSM_EFR: RFC 3551 19。AMR: RFC 4867 25。它包括FR_AMR和HR_AMR。AMR-WB: RFC 4867 25。它包括FR_AMR-WB。当使用压缩语音时，帧长为20 ms。冗余机制不适用。AoIP使用固定的、预先定义的载荷类型号码，参见TS 48.103.6.2.2 数据和传真呼叫RTP Profile6.2.2.1BSS具有速率适配的数据和传真呼叫RTP Profile数据和传真呼叫保持了在原GSM无线接入网和核心网之间的分离。在上行链路方向，BTS从无线接口提取CS数据和传真业务的有效负荷，然后，通过4个72比特的V.110帧将其进行速率适配至16 kbps，并且每隔20ms在上行链路发送出去。一条16kbps Abis/Ater链路的上行链路数据流能够提供净比特速率为300 bps至14.4 kbps的数据业务。BTS的TRAU（或相同功能模块）从TRAU帧中提取数据，然后，将其进行速率适配至64 kbps。等于和低于9.6Kbps的数据以80buts的V110帧传送，14.4kbps的数据以A-TRAU帧传送。当使用高速电路交换数据（High Speech Circuit Switched Data（HSCSD）功能时，BSS可以将多至4个信道复用至一个64kbps数据流中。因此，一个A-接口的上行链路数据流可以提供高达4*14.4kbps = 57.6kbps的净比特速率。AoIP的传输使用基于IP的64 kbps信道。RFC 4040定义的RTP框架正是用于此目的。创建该RFC的目的是提供透明传输64 kbps的基于IP的信道。A-接口的数据速率不仅较高而且恒定。打包时间固定为20ms。关于冗余机制，请参考GP-081401的相关定义。AoIP的CS数据传输的冗余方式必须协商确定。至少必须支持Level 1冗余方式。同样，业务的处理在相反方向进行，即从IWF至MGW、然后至BSS、再至BTS、最后至下行链路无线接口。6.3传输层参阅 TS 48.103 “BSC-MGW interface, User Plane Transport Mechanism”。6.3.1 链路层和物理层链路层和物理层均不需要进行标准化。参阅TS 48.103。6.3.2 UDP和IP 参阅TS 48.103。IPv.4 (RFC 791 21和RFC 792 22) 为必选。 IPv.6 (RFC 2460 23 and RFC 4443 24) 为可选。 这样，即使不支持IPv.6也不会耽搁AoIP的引入。关于UDP的定义，参阅RFC 768 20。6.3.3 RTP参阅TS 48.103。每个用户面连接能够由MGW的一个IP地址和一个UDP端口号码以及BSS的的另一个IP地址和一个UDP端口号码识别。这些地址是在用户面建立以及一些切换之前通过GCP和BSSAP进行交换的。被交换的UDP端口号码是与RTP数据流对应的UDP端口号码。这些UDP端口号码均为偶数。6.3.4 RTCP参阅TS 48.103。RTCP是RTP规范的控制协议。RTCP协议包是在与RTP包相同的用户面传输层交换的。与RTP数据流对应的UDP端口号码为偶数。而相应的奇数UDP端口号码 (RTP+1) 用于对应的RTCP协议。在6.3.5节提及的可选IP复用使用RTCP协议。AoIP没有使用RTCP的其它功能。6.3.5 IP复用参阅TS 48.103。为了降低A-接口的带宽需求， RTP/UDP/IP 包复用 (简称为 “IP 复用”)是AoIP的一个可选功能，正如在3GPP TS 29.414为Nb接口定义的那样。IP复用要求在BSS和MGW之间利用RTCP进行协商。该功能为可选。 6.4切换过程 （用户面）6.4.1 一般切换过程对于所有支持A-接口压缩语音的解决方案，呼叫建立的分配过程（包括增强码型协商）力求利用最合适的编解码以获得端到端最佳的语音质量。在理想情形下，在使用AoIP的未来结构中，如果呼叫在PSTN侧终结，或编解码协商在端到端的TrFO中没有成功，BSS不做编解码转换，只有MGW进行编解码转换。在呼叫建立之后，由于各种原因，BSS可能会改变小区和/或编解码类型和/或编解码配置。另外，A-接口类型（AoIP或AoTDM）也可能改变。这些改变可能会对用户面产生影响。6.4.2 至兼容目标小区的BSC内部切换在编解码类型、编解码配置和未更改的A-接口类型（BSS内部实施）的BSC内部切换过程中，IP-address-plus-UDP-port不发生变化。MGW只是在上行的RTP流中检测到一些无规律的数据。6.4.3 至不兼容目标小区的BSC内部切换在BSC内部切换和小区内部切换过程中，如果BSC不能或不想保留兼容的编解码类型或编解码配置，或如果A-接口类型需要改变（AoIP至AoTDM或反方向接口），或者BSC需要改变IP地址或者UDP端口，则MGW应该添加一个至目标小区的新的终结点（new termination），并且以BSC之间切换的方式处理该切换（参阅下面6.4.4节 BSC之间切换）。由MSC通过GCP控制MGW的方式与BSC之间切换相同（添加新的终结点（ADD new termination），减去原有的终结点（SUBtract old termination）。注：对于这一类（相对频繁的）BSS内部切换，在BSS和MSC之间引入了新的控制面过程以最大程度地降低BSC、MSC和MGW的负荷。参阅第7章（“要求的内部切换”和内部切换命令“）。6.4.4 BSC之间的切换在BSC之间切换过程中，MGW将在瞬间存在至无线接口的两个终结点，其中一个是至原有的服务BSC，另一个是至新的目标BSC。两个MGW终结点的编解码类型、编解码配置和A-接口类型可能是兼容的或不同的。因此，由MGW来决定是否插入必要的代码转换器设备，以及执行相应的切换处理。相应的处理细节不需要标准化。由MSC通过GCP控制MGW的方式与BSC内部切换相同（添加新的终结点（ADD new termination），修改终结点（MODify terminations），减去原有的终结点（SUBtract old termination）。6.5时间和相位校准AoIP不需要考虑时间和相位的校准。7. 控制面7.1控制面工作原理引入IP作为A-接口用户面的传输层需要BSSMAP和GCP信令的支持。因此，在后面的章节中特挑选下列内容进行讨论：1.传输层信息交换，即BSS和MGW之间的IP地址和UDP端口号码的交换2.AoIP的呼叫ID3.编解码信息的交换 即BSS能力（BSS Capability）和MSC Preference4.TC的位置（在BSS还是在CN）5.RTP参数交换7.1.1传输层信息交换CN和BSS之间的A-接口用户面对于每一个呼叫都是动态建立的。传输层信息必须在MGW和MSC-Server（后面简称MSC）之间通过H.248交换，而在MSC和BSS之间通过BSSMAP交换。传输层必须包含一下信息：- IP地址（IP-Address）- UDP端口号码（UDP-Port-Number）MGW和MSC之间以及MSC和BSC之间的交换过程的概念框图如图 7.1.1.1所示。BSCMGWMSCH.248BSSMAPH.248 procedures:Reserve RTP Connection Point /Configure RTP Connection PointAssignment Request / Assignment Complete: Exchange of transport layer informationA-Interface user plane图 7.1.1.1:传输层信息交换的概念框图在MSC收到Complete Layer 3消息并且决定为呼叫使用/提供AoIP之后，使用以下信令序列：§ MSC给MGW发送一条添加请求消息（ADD.REQuest）要求MGW预留本地IP地址和UDP端口。MGW预留A-接口IP终结点并且在添加响应（ADD.RESpond）消息中向MSC给出本地IP地址和UDP端口号码。这是通过利用现有的H.248过程“预留RTP连接点（Reserve RTP Connection Point）”完成的。§ MSC利用一条增强的BSSMAP分配请求（BSSMAP Assignment Request）消息，在新的“AoIP传输层地址（AoIP Transport Layer Address）(MGW)”IE中将MGW IP地址和UDP端口信息转发给BSS。然后，BSS执行信道分配任务。作为分配过程的一部分，BSS中的本地连接端点的传输层信息将被放入另一个“AoIP传输层地址（AoIP Transport Layer Address）(BSS)”IE中，该信息将通过BSSMAP分配完成（BSSMAP Assignment Complete）消息发回至MSC。§ MSC利用现有过程“配置RTP链接点（Configure RTP Connection Point）”，把在“AoIP传输层地址（AoIP Transport Layer Address）(BSS)”IE中接收到的BSS IP地址和UDP端口号码传送给MGW。图 7.1.1.2给出了在MGW和BSS之间交换传输层信息的一种可能的信令序列。Complete Layer 3BSSAdd.ReqAdd.Reply(T$, Reference point: A(oIP), local IP address=?, port =?)MSCMGW(T1, IP address, port)Assignment Request(AoIP Transport Layer Address(MGW) IE Assignment CompleteAoIP Transport Layer Address (BSS) IE Mod.ReqMod.Reply(T1, remote IP address, port)(T1)H.248 ProcedureReserve RTP Connection Point + Change Through-connectionH.248 ProcedureConfigure RTP Resources +Change Through-connectionUser plane is available for traffic图 7.1.1.2: 通过新的IE “AoIP传输层地址”交换传输层信息“AoIP传输层地址”IE能够为连接端点的传输层信息提供IPv4/IPv6地址和UDP端口号码，参阅章节7.2.1.12。7.1.2 AoIP的呼叫ID在传统结构中，MSC或BSC会获取一个CIC（Circuit Identity Code）。如果MSC获取了该CIC，则MSC在BSSMAP分配请求（BSSMAP Assignment Request）消息中将其发送给BSS。该CIC能够识别在传输层中使用的物理连接。该ID也用作呼叫ID代码（Call Identifier Code）。在AoIP标准中，使用一种新的IE“呼叫ID（Call Identifier）”来唯一地识别MSC和BSC之间的IP呼叫。在BSC和MSC之间的SCCP连接中断并且一侧需要通过复位资源（RESET RESOURCE）消息通知另一侧的情形下（此时，呼叫不得不释放），该IE“呼叫ID（Call Identifier）”非常有用。呼叫ID在A-flex (MSC池)解决方案中尤其重要，在这一解决方案中，如果发生故障，则可能需要清除大量呼叫。“呼叫ID”是一个独立于IP承载（IP- bearer-independent）的号码（32比特），其由MSC确定，然后通过Assignment Request 和 Handover Request消息发送至BSS。BSSMAP信令（RESET RESOURCE/RESET RESOURCE ACKNOWLEDGE）可以用于释放吊死的IP呼叫（参阅章节7.3.4）。7.1.3 编解码信息交换当使用的承载是TDM时，A-接口用户面使用的编解码类型为G.711。如果使用IP替代传输，则建议采用新的编解码类型，因为G.711不是最有效的基于IP的编解码方式。当使用的承载是IP时，用于空中接口的3GPP编解码类型能够继续用于A-接口的用户面，而且质量没有任何损失。至少在要求TrFO操作时需要采用这种方式。另外，这样也能够支持将TC资源从BSS转移至核心网。7.1.3.1 呼叫建立过程中编解码信息的交换编解码信息必须在MGW和MSC之间通过H.248交换，而在MSC和BSS的用户面对等节点之间通过BSSMAP交换。当MSC在MGW中为AoIP连接端点预留IP终结点时，MSC同时也为MGW提供编解码信息。这种机制即预留RTP链接点 (Reserve RTP Connection Point 过程)。在3GPP TS 29.232中定义的H.248接口提供编解码信息。在终结点预留阶段传递给MGW的编解码信息给出了“MSC首选编解码类型和配置”，这是由MSC在与远端MSC进行编解码协商之后确定的。在MSC预留IP终结点之后，它将构建编解码列表（Codec List (MSC Preferred)）并且向BSS发起编解码协商。然后，MSC在BSSMAP Assignment Request消息中向BSS发送编解码信息（即Codec List (MSC Preferred)）。Codec List (MSC Preferred)不仅包含MSC首选的编解码类型，还包含其它可选的编解码类型。目前为AoTDM定义的信息单元（Information Element）需要改变，因为，在使用AMR和AMR-WB 编解码类型的情况下，除了发送编解码类型，还应该发送编解码配置信息。因此，定义了一个新的信息单元（称为Codec List (MSC Preferred)）以将编解码信息传送至BSS。Codec List (MSC Preferred)是为信道分配而提供给BSS的所有编解码的优先列表。而MSC首选编解码类型是Codec List (MSC Preferred)中排在第一位的类型。它能够以最佳方式与核心网选中的编解码（Selected Codec（SC）匹配。Codec List (MSC Preferred)中的信息需要与Channel Type IE中的信息一致。此外，Codec List (MSC Preferred)还包含TC资源位置和A-接口类型信息。BSS原则上能够从接收到的Codec List (MSC Preferred)中自由选择任何编解码类型。虽然不能强制BSS选择MSC首选的编解码类型，但应该尽可能这样做。由于BSS内部算法可能会导致从Codec List (MSC Preferred)中选择另外的编解码类型的罕见情形，因此BSS将在BSSMAP Assignment Complete消息中提供关于最终选中的编解码（一种新的IE “Speech Codec (chosen)"）信息。MSC在MODify消息中向MGW发送Speech Codec (chosen)。为了减少BSS必须选择一个不同于MSC优先选择的编解码类型这样的情形发生的次数，BSS应该为每个呼叫通知MSC关于支持不同3GPP编解码类型资源的可用情况。这些信息必须在MSC开始端到端编解码协商之前提供。新的信息单元“编解码列表（BSS支持）”必须由BSC附加在BSSMAP Complete Layer 3 Information消息的后面。如果MSC检测到编解码列表（BSS支持）与一个语音呼叫相关，则它将利用该信息进行端到端的编解码协商以及为RAN接口进行编解码的预选。如果MSC收到关于任何其它商务的信息（例如，MSC收到一个数据呼叫的编解码列表（BSS支持），则该编解码列表（BSS支持）Complete Layer 3Add.ReqAdd.Reply(T$, IP address=?, port =?, pCodec*, )MSCMGW(T1, IP address, port)Assignment Request(AoIP Transport Layer Address IE(Codec List (MSC Preferred)-)Assignment Complete(AoIP Transport Layer Address IE, Mod.ReqMod.Reply(T1)H.248 ProcedureReserve RTP Connection Point + Change Through-connectionH.248 ProcedureConfigure RTP Resources +Change Through-connectionUser plane is available for trafficCodec List (BSS Supported)DTAP, SETUP (MS-SCL)MSS determines the “MSS Preferred Codec Type and Configuration”.BSC(T1, remote IP address, port, (codec*, )MSS performs the (OoBTC) codec negotiation with terminating side.(Speech Codec (Chosen)pCodec* = MSC首选的编解码类型Codec* = Speech Codec (chosen)图 7.1.3.1.1: 基于每个呼叫的编解码信息交换注 1：BSS在Codec List (BSS Supported)总是缺省包含编解码类型GSM-FR，但只有在很少的情况下才会使用它，例如，MS不支持任何其它编解码类型。注 2：关于IE“Codec List (MSC preferred)”和“Codec List (BSS Supported)”的详细信息，请查阅3GPP TS48.008。7.1.3.2 切换期间编解码信息交换 相关的详细信息，请参考章节7.3.2 切换过程（handover procedure）。7.1.4 BSS或CN中的TC资源的位置新的IE Codec List (BSS Supported)和Codec List (MSC Preferred)为协商和选择TC资源的位置提供了非常灵活的方式，如果需要，其位置既可以位于BSS，也可以位于CN。通过在Codec List (BSS Supported)中灵活地设置不同的比特，BSC能够针对每种编解码类型向MSC指示BSS是否具有TC资源。MSC通过在Codec List (MSC Preferred)中设置相应的比特指示其是需要BSS支持至PCM的代码转换，还是不需要BSS执行任何代码转换。这样，传统BSS的现有TC资源在升级至AoIP之后能够有效地重新利用。BSS中针对特定编解码类型的现有TC池能够在MGW中进行扩容以满足话务负荷增长需求。7.1.5 RTP参数交换标准化的IETF 3GPP编解码的RTP Profile具有相当的灵活性。例如：载荷类型（Payload Type）、冗余方案（Redundancy）和打包时间（Packetization Time）等。RTP参数是预先定义并且是固定不变的。参阅TS 26.102、TS 26.103和TS 48.103。RTP参数无需进行交换。数据冗余方案基于GP-081401。7.2信令消息7.2.1BSSMAP 关于相关详细信息，请参考3GPP TS 48.008。7.2.3DTAP不允许对DTAP进行修改以保持与现有移动终端的兼容性。7.2.4GCP（H.248 协议）请参考3GPP TS 29.232。7.3过程注：本章节遵循3GPP TS 48.008的最新版本。下面内容是对过程的概述。如果与TS 48.008存在差异，则以TS 48.008为准。7.3.1呼叫建立时的编解码协商 为了获得最佳服务质量，对于每一个呼叫都需要进行最优的端到端码型协商，在协商中充分考虑MS、BSS和CN及其远端等的编解码能力。图 7.3.1.1给出了一个MS至MS的呼叫范例，在呼叫建立时进行了端到端的编解码协商。在封装了来自MS1的DTAP CM SERVICE REQUEST消息的第一条Complete Layer 3消息中，BSC1向MSC1发送其实际的Codec List (BSS Supported) 1（简称：BSC-SCL1）。BSC1应该就其所知在该点及时地为这一特定呼叫预测在这一特定小区可以使用哪一种编解码类型、配置和A-接口类型。BSC1在该Codec List (BSS Supported) 1中不应该包含目前不支持的编解码类型。MSC1在DTAP SETUP中收到MS1的编解码能力（MS-SCL1），DTAP SETUP还包含其它与呼叫建立相关的详细信息。在收到SETUP之后，MSC1将根据MS-SCL1、Codec List (BSS Supported) 1以及CN能力确定SCL。然后，MSC1通过OoBTC向对端发起编解码协商，其中包含上述SCL。MSC 1Complete Layer 3: BSC-SCL1OoBTC: SCLComplete Layer 3: BSC-SCL2OoBTC: SCAssignment Request: MSC-PCL2: pRanC2, IP(MGW2) User Plane established end-to-end with cRanC1 via AoIP - SC via NboIP - cRanC2 via AoIPDTAP: MS-SCL1DTAP: MS-SCL2Assignment Complete: Speech Codec (Chosen)=cRanC2, IP(BSS2) MSC 1BSC 1BSC 2Assignment Complete: Speech Codec (Chosen)=cRanC1, IP(BSS1) Assignment Request: MSC-PCL1: pRanC1, IP(MGW1) 图 7.3.1.1: 范例：呼叫建立时的端到端码型协商（MS至MS呼叫）如果 cRanC1 = SC = cRanC2，则该呼叫端到端都无需TC在收到受话方的呼叫尝试之后，MSC2发起对受话用户的寻呼过程。BSC2向MSC2发送其实际的Codec List (BSS Supported) 2（简称：BSC-SCL2），该列表包含于第一条封装了来自MS2的PAGING RESPONSE消息的Complete Layer 3消息。MS2在DTAP CALL CONFIRMED消息中向MSC2发送其MS-SCL2的编解码能力。在收到CALL CONFIRMED之后，MSC2为该呼叫选择一对编解码，其中一个用于CN（称为“SC”），另一个用于受话方的RAN（称为"pRanC2"，首选的RAN编解码）。在上述选择操作中， MSC2考虑了MS-SCL2、Codec List (BSS Supported) 2、CN能力以及来自MSC1的SCL。在最优情况下，SC和pRanC2是相同的或至少是兼容的。MSC2还考虑了A-接口类型和TC位置。当然，MSC2还预先确定编解码的配置。之后，MSC2向MSC1回送SC。现在，MSC1综合考虑SC、编解码列表（MSC首选）1、编解码列表（BSS支持）1以及CN能力，为发起侧选择首选的RAN编解码（pRanC1）。在最优情况下，SC和pRanC1是相同的或至少是兼容的。MSC1还考虑了A-接口类型和TC位置。当然，MSC1还预先确定编解码的配置。现在，MSC1和MSC2分别开始为BSC1和BSC2分别发送可用的编解码信息。Codec List (MSC Preferred) 1包含pRanC1作为发起侧的首选编解码类型。请注意Codec List (MSC Preferred) 能够包含比BSS在Codec List (BSS Supported)中提供的更多的编解码类型，但不可能多于MS在MS-SCL中支持的编解码类型。BSS可以在后续的切换过程中使用这些附加的编解码类型。Codec List (MSC Preferred) 2包含pRanC2作为受话方的首选编解码类型。MSC1/MSC2在Assignment Request消息中向BSC1/BSC2发送Codec Li