华为媒体网关IU接口信令分析与处理.doc

课程 WH003402媒体网关IU接口信令分析与处理ISSUE 1.0WH003402 媒体网关IU接口信令分析与处理 ISSUE1.0目 录目 录课程说明1课程介绍1课程目标1相关资料1第1章 Iu接口MGW的典型协议过程21.1 概述21.2 Q.AAL2协议应用21.2.1 正常建立过程31.2.2 建立失败过程31.2.3 正常释放过程41.2.4 正常呼叫和挂机过程的Q.AAL2跟踪实例51.2.5 Q.AAL2重点消息举例51.3 IuUP协议应用71.3.2 Iu UP的主要功能81.3.3 语音呼叫的Iu UP跟踪实例91.4 Iu口的基本协议过程91.4.1 语音呼叫建立及释放过程101.4.2 VP呼叫建立及释放过程101.4.3 IuUP重点消息举例10第2章 Iu接口故障案例分析132.1 概述132.2 典型案例132.2.1 3G用户呼叫不成功，QAAL2信令建立失败132.2.2 3G用户呼叫不成功，Iu UP初始化失败1619华为技术有限公司 版权所有, 未经许可不得扩散WH003402 媒体网关IU接口信令分析与处理 ISSUE1.0课程说明课程说明课程介绍本课程通过对UMG8900设备Iu接口的典型协议过程和实际故障案例进行分析，使学员能够深刻掌握Q.AAL2和IuUP协议，并能够熟练处理日常维护中的相关故障。课程目标完成本课程学习，学员能够掌握： l Q.AAL2信令故障的处理方法l IuUP信令故障的处理方法相关资料(1) Q.2630.1 AAL2信令协议(功能集1)(2) Q.2630.2 AAL2信令协议(功能集2)(3) 3GPP TS25.415 UTRAN Iu接口用户面协议WH003402 媒体网关IU接口信令分析与处理 ISSUE1.0第2章 Iu接口故障案例分析第1章 Iu接口MGW的典型协议过程1.1 概述在3GPP的R4典型组网中，MGW在Iu接口的最基本应用是实现Iu口承载建立和用户面协商的功能（如图1-1），承载建立过程要通过Q.AAL2协议与RNC交互，用户面的协商则通过Iu UP协议完成。这两个协议与3G业务密切相关，是理解MGW移动业务处理过程和定位Iu口问题的重点。图1-1 3GPP典型组网1.2 Q.AAL2协议应用AAL2信令系统的主要任务是在两AAL2信令节点间建立和释放AAL2连接，同时也对该信令系统内的通道、通路等资源进行必要的维护和管理。连接的建立和释放是在业务用户的请求下、通过AAL2信令网上各有关节点相互交流信令消息而完成的。维护管理功能则多是根据维护台的指示而启动的，也有一些是因系统检查出了错误而主动发起的维护操作。但无论是谁发起的维护调用，均需与被管理对象(通道、通路)有关的两相邻节点互相配合才可完成。在Iu接口，Q.AAL2的建立过程都是由RNC发起的，释放过程可以由双方发起。Q.AAL2协议实体之间的交互是通过原语，常见的原语如：ERQ、ECF、REL、RLC、RES、RSC、BLC、UBL。下边介绍一些基本的交互过程，也包括了实际业务中经常出现的错误情况。1.2.1 正常建立过程在手机用户发起呼叫，RNC收到RAB指派请求之后，将向MGW发送Q.AAL2的建立请求。MGW的Q.AAL2收到建立请求消息，首先进行AAL2资源的分配，如果分配成功，则发建立指示给业务用户，以便进行呼叫处理资源和呼叫控制资源的分配。如果在定时器超时前，Q.AAL2得到业务用户的建立响应，则向RNC发送建立证实消息，承载建立成功。1.2.2 建立失败过程MGW的Q.AAL2收到RNC的建立请求消息后，AAL2资源分配失败，Q.AAL2将直接向RNC发送释放证实消息，呼叫失败。常见的AAL2资源分配失败原因包括：PATH对应的物理端口不可用、PATH对应的PVC剩余带宽资源不足、虚拟媒体网关可支持用户数不足等。 MGW的Q.AAL2收到RNC的建立请求消息后，AAL2资源分配成功，发建立指示给业务用户。如果业务用户在资源处理过程中出现错误，则回送释放响应，Q.AAL2将向RNC发送释放证实消息，呼叫失败。业务用户常见失败包括：呼叫控制资源不足、会话控制资源超时、AAL2资源占用失败。MGW的Q.AAL2收到RNC的建立请求消息后，AAL2资源分配成功，发建立指示给业务用户。如果业务用户在资源处理过程中出现延迟，在定时器超时前没有给出响应，Q.AAL2将向RNC发送释放证实消息，呼叫失败。业务用户超时的常见原因包括：语音处理资源不足、内部通信超时等。1.2.3 正常释放过程手机用户挂机后，RNC将向MGW发送Q.AAL2的释放请求消息，MGW的QAAL2通知业务用户释放呼叫资源，然后回送释放证实。1.2.4 正常呼叫和挂机过程的Q.AAL2跟踪实例1.2.5 Q.AAL2重点消息举例1. ERQ消息消息中需要重点关注的信息是：ceid，osaid，nsap，alc，sugr。这些信息会决定AAL2连接建立的成功与否，在失败时经常要分析它们是否正确填写。CEID：连接元素标识，CEID中的path identifier是相连设备之间的唯一通道标识，用于指定PVC，CEID中的channel identifier是通路标识，用于指定PVC中的CID。OSAID：源信令关联标识，不能为全0。DSAID：目的信令关联标识，全0表示“未知”。NSAP：ATM端点地址SUGR：业务用户生成的参考，是一个长字。在UMG中结构解释为1个字节的虚拟媒体网关号，一个字节的CMU板组号，两个字节的端点索引。ALC：链路属性。描述AAL2链路的属性，CPS-SDU的最大比特率、CPS-SDU的平均比特率、CPS-SDU的最大长度、CPS-SDU的平均长度。比特率的单位是64bps，表示即将建立话路的带宽，CPS-SDU长度表示的是要支持ATM信元的大小。2. ECF消息消息中需要重点关注的信息是：osaid。ECF消息已经表示建立成功，消息中的信息仅用于事后分析。REL消息消息中需要重点关注的信息是：cause。在异常释放时，cause中记录了原因值，有几种协议标准的原因值是可以直接得出释放原因的。3. RLC消息消息中需要重点关注的信息是：cause。在释放应答中，cause没有实际意义。但在建立连接时，对ERQ消息应答RLC，cause则中记录了原因值。RLC是Iu口Q.AAL2建立失败时最常查看的消息。1.3 IuUP协议应用Iu UP 协议位于Iu 接口的无线网络层的用户面：Iu UP 协议层。Iu UP 协议用于传送与RAB 相关的用户数据。一个Iu UP 协议实例（instance）同且只同一个RAB 相关。如果对于一给定UE，建立了几个RAB，那么这些RAB 将使用相同数目的Iu UP 实例。Iu UP 协议实例存在于Iu 访问点，即位于CN 和UTRAN 中。当RAB 需要在Iu UP 中传输用户数据时，Iu UP 协议实例应存在于每个Iu 接口访问点。这些Iu UP 实例应同相关的RAB 一起建立、重定位及释放 。图1-2 UTRAN体系中的UP协议视图1.3.2 Iu UP的主要功能Iu UP协议有透明和支持两种模式，透明模式仅提供透明传输用户数据，支持模式下则还需要支持以下功能：初始化；速率控制；时间对准；错误事件处理；帧质量分类。其中初始化过程要在RAB指派时进行，所以在语音呼叫中，会导致失败的UP过程一般是初始化，而初始化消息在MGW上也是可以跟踪到的。图1-3 m个RFCI的成功初始化过程图1-4 不成功初始化过程: 1) 否定应答 或 2) 应答超时初始化失败的常见原因有：MGW配置的RFCI集合不能包含RNC的RFCI集合，MGW与RNC的UP版本不兼容，一次呼叫带的RFCI数目超过10。初始化超时的常见原因有：Iu口的AAL2通道未正确建立，初始化报文CRC校验错。1.3.3 语音呼叫的Iu UP跟踪实例1.4 Iu口的基本协议过程MGW在Iu接口的协议交互过程是：用户发起呼叫时，先做Q.AAL2建立过程，成功后做UP初始化。用户挂机时，做Q.AAL2的释放过程。UP支持模式和透明模式业务的差别在于透明模式下没有UP的初始化过程。典型的支持模式业务是语音业务和非透明数据业务，典型的透明模式业务是VP（H324M）业务和透明数据业务。1.4.1 语音呼叫建立及释放过程1.4.2 VP呼叫建立及释放过程1.4.3 IuUP重点消息举例1. 初始化请求消息消息中需要重点关注的是：modVer，RFCs，modeVerSupp。这些信息不兼容会造成初始化失败。modVer是当前使用的版本，modeVerSupp是支持的版本集合RFCS 是AMR 语音编码速率的集合2. 初始化应答消息消息中需要重点关注的是：ackNack。该值在初始化成功时为ack，失败时为nack。第2章 Iu接口故障案例分析2.1 概述Iu接口的业务相关问题通常表现为呼叫失败。某些情况下，从跟踪的Q.AAL2和Iu UP接口消息能够分析出失败的可能原因，再结合Mc接口跟踪、内部接口跟踪、查询配置，则基本可以定位。2.2 典型案例2.2.1 3G用户呼叫不成功，QAAL2信令建立失败1. 现象描述手机用户做端局局内呼叫，被叫用户尚未接听就已失败。跟踪QAAL2接口消息，发现MGW收到ERQ后，直接回RLC。2. 处理过程(1) 查看RLC中的cause，为temporary failure。导致这个错误码的可能性较多，不能直接得出结论，需要具体分析。(2) 打开ERQ消息，对其中的重点信息及可能的错误进行对比分析。ceid中的path identifier为1，说明RNC要求使用的PATH ID为1。查询MGW的配置，ID为1的PATH已经配置并且可用，无误；nsap值为09.08.09.08.09.08.09.08.09.08.09.08.09.08.09.08.09.08.09.07，查询MGW上的邻节点配置，地址相同，无误；alc中的双向速率和包大小值填写正确，查询MGW上的PVC流量配置，剩余带宽足够，无误；sugr的值为0x80011，解析出该长字的最高字节为0，对应MGW的虚拟媒体网关ID；解析出长字的次高字节为8，对应MGW的CMU板组号，这两个值都正确。但用LST AAL2VMGW查询对应ASU板上的ATM资源数配置，0号虚拟媒体网关对应的资源数为0，这样在虚拟媒体网关0上是不能分配任何ATM资源的，也就是错误所在。+ HUAWEI U-SYS UMG8900 2004-08-01 14:44:21O&M #20 %LST AAL2VMGW: BN=0, VMGWID=0;%RETCODE = 0 执行成功查询虚拟媒体网关信息-板组号 虚拟媒体网关号 最大用户数0 0 0(结果个数 = 1)- END(3) 更改配置，SET AAL2VMGW设置虚拟媒体网关0的用户数为12000。再次呼叫，成功。3. 同类问题定位指导(1) 通常先查看RLC的错误码，对原因单一的错误码，直接定位原因；对通用错误码，划出可能的错误范围；(2) 分析ERQ消息，排除RNC消息错误和配置错误；(3) 对比查询MGW的数据配置，定位解决配置上的错误。2.2.2 3G用户呼叫不成功，Iu UP初始化失败1. 现象描述手机用户做端局局内呼叫，被叫用户尚未接听就已失败。跟踪QAAL2接口消息没有问题。跟踪Iu UP接口，发现MGW收到初始化请求后，直接回NACK导致协商失败。2. 处理过程(1) 查看NACK消息的原因值，为 “初始化失败”，可认定是RFCI协商失败。(2) 打开初始化请求消息的解析，分析携带的RFCI集合，可以看出带有3个RFC，每个RFC的子流个数为3，按照子流长度判断，3个RFC应该分别是12.2K、0速率和静音帧，都是正确的AMR速率。(3) 用LST RFCI查看MGW的RFC配置，12.2K和静音帧对应的RFCI号分别为7和8，有效；但0速率对应的RFCI号为63，即无效的RFCI，这样RNC的0速率无法在MGW上匹配，导致初始化失败。+ HUAWEI U-SYS UMG8900 2004-08-01 14:34:59O&M #14 %LST RFCI:;%RETCODE = 0 执行成功RFCI集-Rfci号 发送间隔(ms) 编解码 RFC长度 帧类型 子流数 子流1 子流2 子流3 子流4 子流5 子流67 20 0 244 7 3 81 103 60 0 0 00 20 0 95 0 2 42 53 0 0 0 01 20 0 103 1 2 49 54 0 0 0 02 20 0 118 2 2 55 63 0 0 0 03 20 0 134 3 2 58 76 0 0 0 04 20 0 148 4 2 61 87 0 0 0 05 20 0 159 5 2 75 84 0 0 0 06 20 0 204 6 3 65 99 40 0 0 08 20 0 39 8 3 39 0 0 0 0 063 20 0 0 15 3 0 0 0 0 0 016 5 0 320 16 1 320 0 0 0 0 017 10 0 640 17 1 640 0 0 0 0 018 20 0 576 18 1 576 0 0 0 0 019 20 0 672 19 1 672 0 0 0 0 020 40 0 576 20 1 576 0 0 0 0 0(结果个数 = 1