UMG8900产品黄埔培训系列教材-14 问题定位-3G类

UMG8900产品问题定位-3G类ISSUE1.0介绍UMG89003G组网时基本业务流程和常见问题处理前言参考资料Q.2630.1AAL2信令协议(功能集1)Q.2630.2AAL2信令协议(功能集2)3GPPTS25.415UTRANIuinterfaceuserplaneprotocols

3GPPTS29.415CoreNetworkNbInterfaceUserPlaneProtocols

学习完此课程，您将会：了解UMG8900处理3G业务的基本流程和原理了解UP协议功能和初始化流程能够处理UMG89003G业务常见问题目标第1章3G业务在UMG上的实现第2章UP协议介绍第3章常见问题处理内容介绍第1章3G业务在UMG上的实现1.1信号流和数据流1.2语音呼叫建立及释放过程1.3VP呼叫建立及释放过程内容介绍信号流和数据流－3G局内呼叫其中A4L是ATM的光接口板，用于接入ATM承载ASU是ATM的协议处理板，完成ATM相关协议（MTP3B，QAAL2等）处理。RNC为R4版本的局内呼叫，RNC侧打开TrFO功能时，UMG不插入TC编解码资源，呼叫模型如上图所示。如果RNC为R99版本或者RNC没有打开TrFO功能时，UMG将插入双TC，这样对TC资源是极大的浪费，这种情况的呼叫模型如下图，请尽量避免。信号流和数据流－3G出局呼叫区别局内呼叫之处在于，ASU完成ATM协议处理后经过TC的转换为PCM码流，可以在TDM承载上传输，然后经过TNU交换后走TDM接口板（如E32）连接至其他网络。如果3G始发至固网用户，为了抵消固网2/4线转换引发的回声，UMG还需要在插入EC，拓扑修改为此处的EC为EEC，用于消除固网侧引入的电学回声。移动用户产生的回声是声学回声，通常由移动终端或无线接入网进行回声抵消处理。信号流和数据流－3G出局呼叫IP承载对于3G出局呼叫，承载网为IP时，核心网即UMG内部的承载拓扑为如果RNC是R99版本、TrFO功能未打开、核心网与接入网采用的语音编解码（CODEC）不同、核心网与接入网的UP版本不一致等，UMG会在语音承载通道上插入双TC。承载拓扑变为：ASU完成ATM协议处理、并将AAL2承载的语音转变为IP承载的语音包后经过HRU路由转发走IP接口板（如G1O）发送至IP网络。Q.AAL2信令流程Q.AAL2信令系统的主要任务是在网关和RNC间建立和释放AAL2连接，同时也对UMG上的ATM承载资源等资源进行管理。在Iu接口，Q.AAL2的建立过程都是由RNC发起的，释放过程可以由双方发起。Q.AAL2协议实体之间的交互常见的消息有：ERQ、ECF、REL、RLC、RES、RSC、BLC、UBL。Q.AAL2承载建立在手机用户发起呼叫，RNC收到RAB指派请求之后，将向MGW发送Q.AAL2的建立请求（REQ)。MGW的Q.AAL2收到建立请求消息，首先进行AAL2资源的分配，如果分配成功，则发建立指示给业务用户模块进行呼叫处理资源（ATM端点控制块SAID）和呼叫控制(UP实例)资源的分配。如果在定时器超时前，Q.AAL2得到业务用户模块的建立响应，则向RNC发送建立证实消息（ECF），承载建立成功。Q.AAL2承载建立（续）MGW的Q.AAL2收到RNC的建立请求消息后，如果AAL2资源分配失败，Q.AAL2将直接向RNC发送释放证实消息（RLC），呼叫失败。常见的AAL2资源分配失败原因有：PATH对应的物理端口不可用、PATH对应的PVC剩余带宽资源不足、虚拟媒体网关可支持用户数不足等。MGW的Q.AAL2收到RNC的建立请求消息后，AAL2资源分配成功，发建立指示给业务用户。如果业务用户模块在资源处理过程中出现错误，则回送释放响应，Q.AAL2将向RNC发送释放证实消息，呼叫失败。业务用户常见失败包括：呼叫控制资源不足、会话控制资源超时、AAL2资源占用失败等。Q.AAL2承载建立（续）MGW的Q.AAL2收到RNC的建立请求消息后，AAL2资源分配成功，发建立指示给业务用户。如果业务用户在资源处理过程中出现延迟，在定时器超时前没有给出响应，Q.AAL2将向RNC发送释放证实消息，呼叫失败。业务用户超时的常见原因包括：语音处理资源不足、内部通信超时等。Q.AAL2承载释放手机用户挂机后，RNC将向MGW发送Q.AAL2的释放请求消息（REL)，MGW的QAAL2模块通知业务用户模块释放呼叫资源，然后回送释放证实。Q.AAL2消息跟踪ERQERQ消息：消息中需要重点关注的信息是：ceid，osaid，nsap，alc，sugr。这些信息会决定AAL2连接建立的成功与否，在失败时经常要分析它们是否正确填写。ERQ（续）ceid：呼叫使用的AAL2Path和Channel，每个Path最多可以使用248个channel。nsap：UMG8900上配置的本节点nsap地址。alc：描述AAL2链路的属性，最大比特率、平均比特率、最大包长度、平均包长度。比特率的单位是64bpsSUGR：ATM端点ID的后四个字节，1个字节的虚拟媒体网关号，一个字节的CMU板组号，两个字节的端点索引。OSAID：源信令关联标识，RNC上呼叫索引，不能为全0。DSAID：目的信令关联标识UMG对应ASU单板上的呼叫索引，全0表示“未知”。ECFECF消息表示建立承载成功，携带osaid。REL释放AAL2承载消息。在异常释放时，cause中记录了原因值，有几种协议标准的原因值是可以直接得出释放原因的。REL一般释放原因有：

41：临时错误，该ASU单板为给定的VMGW分配的资源不够

使用SETAAL2VMGW设置该ASU单板为指定VMGW分配的资源数

42：设备拥塞,ASU分配SAID失败

44：请求的Channel已经被占用

47：资源不可用,如ANI资源/Path未配置或path状态不可用RLC释放AAL2承载应答消息。在建立连接时，如果UMG8900对ERQ消息应答RLC，cause则中记录了原因值。RLC是Iu口Q.AAL2建立失败时最常查看的消息。Iu口的基本协议过程用户发起呼叫时，先进行Q.AAL2建立协商，成功后做UP初始化协商。用户挂机时，进行Q.AAL2的释放。UP有两种模式：支持模式和透明模式业务。透明模式下没有UP的初始化过程。典型的支持模式业务是语音业务和非透明数据业务，典型的透明模式业务是VP（VideoPhone）业务和透明数据业务。UP初始化请求消息消息中需要重点关注的是：modVer，RFCs，modeVerSupp。这些信息不兼容会造成初始化失败。modVer是当前使用的版本，modeVerSupp是支持的版本集合RFCS是AMR语音编码速率的集合UP初始化应答消息消息中需要重点关注的是：ackNack。该值在初始化成功时为ack，失败时为nack，包含ErrorCause

问题ATM局内呼叫可能会经过UMG8900那些单板？Q.AAL2信令是做什么用的？UP协商失败可能是什么原因？小结ATM呼叫数据流ATM承载建立和协商过程小结第2章UP协议介绍2.1UP协议总体介绍

2.2UP协议功能组成2.3 UP协议消息解读内容介绍UP协议总体介绍——IuUPIU接口在MGW组网中的位置:

IU接口为RNC和核心网的接口，一般是基于ATM承载

信令承载在AAL5上,

媒体承载在AAL2上UP协议总体介绍——NbUPNB接口在MGW组网中的位置:

Nb接口是MGW之间用于传输用户数据及用户面控制信令的接口。

基于ATM或IP承载。NBUP协议在NB接口的位置

NB接口用户面的控制方法和协议称为NBUP

NbUP协议处在核心网络层（CNL）和传输网络层（TNL）之间，为核心网络层提供数据传输服务。UP协议总体介绍——UP的操作模式透明模式

除了用户数据的传输，不需要IuUP协议的特别功能

支持模式(且是预定义长度支持模式)

需要一些过程控制功能及一些数据流特定功能，而其传输的用户数据大小可以预定义的方式进行变化UP协议的功能组成——功能模型介绍帧处理功能（FameHandle）UP帧（控制部分/检查部分/净荷）的封装/解析，帧号处理，保证控制头的语义正确，帧头CRC帧控制功能（ProcedureControl）初始化－－UP协议实体间进行版本信息、RFCI信息交换（重点掌握）速率控制－－控制对端可以发送数据帧的最大速率时间校准－－控制对端发送数据帧的时间（快或慢）错误事件处理－－UP发生错误时，通知相关功能模块非接入层数据流特定功能（NASDatastreamsspecificfunctions）数据帧序号连续性检查净荷CRC检查帧质量分类（基于RAB属性DeliveryoferroneousSDE、Radiaoframecalssification、净荷CRC结果，填写UP数据帧的FQC域）UP协议过程控制之一——初始化（1）目的：以RFCI和相关的RAB子流SDU大小，配置UP两个实体。其他附加参数也可以传送。通常由负责建立无线网络层用户面的实体（SRNC）控制。初始化过程优先级最高，当该过程被调用时，所有其他过程将被挂起，直到初始化过程完成。RFCI（RABsub-FlowCombinationIdentifier）：

SRNC对于每个RAB子流组合分配一个RFCI。该标识与RFC的对应关系在IuUP中将一直保持，可以认为每个RFCI代表一个编码速率。过程控制之一——初始化（2）RFCI说明示例：AMR编码的语音比特子流与RFCI集合RFCIFrameTypeIndexAMR

codecmodeTotalnumberofbitsClassAClassBClassC1004,759542530015,1510349540125,9011855630236,7013458760347,4014861870457,95159758405610,22046599406712,22448110360过程控制之一——初始化（3）初始化过程示意图UP协议过程控制之一——初始化（4）过程控制之二——速率控制（1）目的：向对等UP协议层说明在相反方向允许的速率。责任体：通常由在UTRAN完成速率控制的控制实体（SRNC）完成。在某些情况下，如：TrFO

和TFO，由IuUP另一端的远端伙伴进行控制。该过程可以UP初始化完成后的任何时间指示，除非UP实体出现错误。过程控制之二——速率控制（2）发送方：过程控制功能根据高层的请求，准备速率控制帧的有效载荷，其中包含了速率控制帧的反向允许速率。接收方：过程控制功能检查新的允许速率是否与在初始化中收到的RFCI集合一致，也核实仍然允许的非速率控制速率。过程控制之二——速率控制（3）成功速率过程示意图过程控制之二——速率控制（4）不成功速率过程示意图UP将重新触发速率控制过程。如果经过NRC次重复，错误情况依然存在，UP协议层（发送与接收）将采取适当的本地动作过程控制之三——时间校准（1）目的：通过控制对等IuUP协议实体的传输定时，使RNC中的缓冲时延最小。

IuUP时间校准过程由SRNC控制当用户数据传输不被其他控制过程挂起时，该过程可以在任何时间指示。过程控制之三——时间校准（2）发送方：当检测到IuUP数据报文在不适当的时间到达从而导致不必要的缓冲延时时，SRNC将调用时间校准过程。协议层向对等实体说明延迟或提前调整的量值，该量值以500us的单位表示。启动定时器，等待时间调整应答帧的接收。接收方：按照SRNC的指示调整传输定时。被接收IuUP协议层和高层正确处理，后者将发送时间校准应答帧。过程控制之三——时间校准（3）成功校准过程示意图过程控制之三——时间校准（4）不成功校准过程示意图TimeAlignmentnotsupported：不再校准超时：重发过程控制之四——错误事件触发条件：监测到的一个错误（接收错误帧或接收未知或不希望的数据）高层的请求收到UP的错误事件帧错误通过UP-StatusIndication或错误事件帧通知。包含信息：错误原因值错误距离，即错误发生的位置优先级：当用户数据传输不被其他控制过程挂起时，该过程可以在任何时间指示第3章UMG上3G业务常见问题处理3.13G用户呼叫不成功，QAAL2信令建立失败

3.23G用户呼叫不成功，IuUP初始化失败

内容介绍QAAL2信令建立失败——（1）【现象描述】手机用户做端局局内呼叫，被叫用户尚未接听就已失败。跟踪QAAL2接口消息，发现MGW收到ERQ后，直接回RLC。【处理过程】查看RLC中的cause，为temporaryfailure。导致这个错误码的可能性较多，不能直接得出结论，需要具体分析。QAAL2信令建立失败——（2）QAAL2信令建立失败——（3）打开ERQ消息，对其中的重点信息及可能的错误进行对比分析。检查ceid对应的PATH在UMG上是否配置，状态是否正常。检查nsap和UMG配置的邻接点ID是否相同。LSTQAAL2LOCNODE:;检查alc中的双向速率和包大小值是否填写正确，查询MGW上的PVC流量配置，剩余带宽是否足够，DSPAAL2PATH:;QAAL2信令建立失败——（4）sugr的值为0x00080011，解析出该长字的最高字节为0，对应MGW的虚拟媒体网关ID；解析出长字的次高字节为8，对应MGW的CMU板组号，这两个值都正确。但用LSTAAL2VMGW查询对应ASU板上的ATM资源数配置，0号虚拟媒体网关对应的资源数为0，这样在虚拟媒体网关0上是不能分配任何ATM资源的，也就是错误所在。+++HUAWEIU-SYSUMG89002004-08-0114:44:21O&M#20%%LSTAAL2VMGW:BN=0,VMGWID=0;%%RETCODE=0执行成功查询虚拟媒体网关信息--------------------板组号虚拟媒体网关号最大用户数000(结果个数=1)---ENDQAAL2信令建立失败同类问题定位指导通常先查看RLC的错误码，对原因单一的错误码，直接定位原因；对通用错误码，划出可能的错误范围；分析ERQ消息，排除RNC消息错误和配置错误；对比查询MGW的数据配置，定位解决配置上的错误。3G用户呼叫不成功，IuUP初始化失败

【现象描述】手机用户做端局局内呼叫，出现电话可以振铃但无法接续。检查QAAL2接口跟踪消息没有发现问题。跟踪IuUP接口，发现MGW收到初始化请求后，直接回NACK导致协商失败。或UP跟踪中只有发送的请求报文，没有应答报文。【处理过程】查看NACK消息的原因值，为“初始化失败”，可认定是RFCI协商失败。IuUP初始化失败分析RFCI是否合法第一个RFCI对应12.2kbps速率（81+103+60)*50=12200第二个RFCI对应4.75kbps速率（42+53)*50=4750查看编解码和打包时长是否和Server下发给UMG的一致。（G.711编解码根据包长度可以确定打包时长）打开初始化请求消息，检查参数是否正确3G用户呼叫不成功，IuUP初始化失败用LSTRFCI查看UP初始化报文中的RFCI在UMG上的配置，如果有RFCI号（RfcNo)为63，则说明UMG不支持该速率，会导致UP协商失败。+++HUAWEIUMG89002009-01-0401:15:23O&M#152%%LSTRFCI:CODECID=AMR;%%RETCODE=0accomplishedRFCIset--------

RfciNo.IptiCodecRfciLengthFrametypeFirstflagSubFlownumberSubFlow1SubFlow2SubFlow3

720AMR2447YES38110360020AMR950NO342530120AMR1031NO3