WH003402 媒體網(wǎng)關(guān)IU接口信令分析與處理 ISSUE1.0

1、課程 WH003402媒體網(wǎng)關(guān)IU接口信令分析與處理ISSUE 1.0目 錄課程說(shuō)明1課程介紹1課程目標(biāo)1相關(guān)資料1第1章 Iu接口MGW的典型協(xié)議過(guò)程21.1 概述21.2 Q.AAL2協(xié)議應(yīng)用21.2.1 正常建立過(guò)程31.2.2 建立失敗過(guò)程31.2.3 正常釋放過(guò)程41.2.4 正常呼叫和掛機(jī)過(guò)程的Q.AAL2跟蹤實(shí)例51.2.5 Q.AAL2重點(diǎn)消息舉例51.3 IuUP協(xié)議應(yīng)用71.3.2 Iu UP的主要功能81.3.3 語(yǔ)音呼叫的Iu UP跟蹤實(shí)例91.4 Iu口的基本協(xié)議過(guò)程91.4.1 語(yǔ)音呼叫建立及釋放過(guò)程101.4.2 VP呼叫建立及釋放過(guò)程101.4.3 IuUP重點(diǎn)

2、消息舉例10第2章 Iu接口故障案例分析132.1 概述132.2 典型案例132.2.1 3G用戶呼叫不成功，QAAL2信令建立失敗132.2.2 3G用戶呼叫不成功，Iu UP初始化失敗16課程說(shuō)明課程介紹本課程通過(guò)對(duì)UMG8900設(shè)備Iu接口的典型協(xié)議過(guò)程和實(shí)際故障案例進(jìn)行分析，使學(xué)員能夠深刻掌握Q.AAL2和IuUP協(xié)議，并能夠熟練處理日常維護(hù)中的相關(guān)故障。課程目標(biāo)完成本課程學(xué)習(xí)，學(xué)員能夠掌握： l Q.AAL2信令故障的處理方法l IuUP信令故障的處理方法相關(guān)資料(1) Q.2630.1 AAL2信令協(xié)議(功能集1)(2) Q.2630.2 AAL2信令協(xié)議(功能集2)(3) 3G

3、PP TS25.415 UTRAN Iu接口用戶面協(xié)議第1章 Iu接口MGW的典型協(xié)議過(guò)程1.1 概述在3GPP的R4典型組網(wǎng)中，MGW在Iu接口的最基本應(yīng)用是實(shí)現(xiàn)Iu口承載建立和用戶面協(xié)商的功能（如圖1-1），承載建立過(guò)程要通過(guò)Q.AAL2協(xié)議與RNC交互，用戶面的協(xié)商則通過(guò)Iu UP協(xié)議完成。這兩個(gè)協(xié)議與3G業(yè)務(wù)密切相關(guān)，是理解MGW移動(dòng)業(yè)務(wù)處理過(guò)程和定位Iu口問(wèn)題的重點(diǎn)。圖1-1 3GPP典型組網(wǎng)1.2 Q.AAL2協(xié)議應(yīng)用AAL2信令系統(tǒng)的主要任務(wù)是在兩AAL2信令節(jié)點(diǎn)間建立和釋放AAL2連接，同時(shí)也對(duì)該信令系統(tǒng)內(nèi)的通道、通路等資源進(jìn)行必要的維護(hù)和管理。連接的建立和釋放是在業(yè)務(wù)用戶的請(qǐng)

4、求下、通過(guò)AAL2信令網(wǎng)上各有關(guān)節(jié)點(diǎn)相互交流信令消息而完成的。維護(hù)管理功能則多是根據(jù)維護(hù)臺(tái)的指示而啟動(dòng)的，也有一些是因系統(tǒng)檢查出了錯(cuò)誤而主動(dòng)發(fā)起的維護(hù)操作。但無(wú)論是誰(shuí)發(fā)起的維護(hù)調(diào)用，均需與被管理對(duì)象(通道、通路)有關(guān)的兩相鄰節(jié)點(diǎn)互相配合才可完成。在Iu接口，Q.AAL2的建立過(guò)程都是由RNC發(fā)起的，釋放過(guò)程可以由雙方發(fā)起。Q.AAL2協(xié)議實(shí)體之間的交互是通過(guò)原語(yǔ)，常見(jiàn)的原語(yǔ)如：ERQ、ECF、REL、RLC、RES、RSC、BLC、UBL。下邊介紹一些基本的交互過(guò)程，也包括了實(shí)際業(yè)務(wù)中經(jīng)常出現(xiàn)的錯(cuò)誤情況。1.2.1 正常建立過(guò)程在手機(jī)用戶發(fā)起呼叫，RNC收到RAB指派請(qǐng)求之后，將向MGW發(fā)送Q

5、.AAL2的建立請(qǐng)求。MGW的Q.AAL2收到建立請(qǐng)求消息，首先進(jìn)行AAL2資源的分配，如果分配成功，則發(fā)建立指示給業(yè)務(wù)用戶，以便進(jìn)行呼叫處理資源和呼叫控制資源的分配。如果在定時(shí)器超時(shí)前，Q.AAL2得到業(yè)務(wù)用戶的建立響應(yīng)，則向RNC發(fā)送建立證實(shí)消息，承載建立成功。1.2.2 建立失敗過(guò)程MGW的Q.AAL2收到RNC的建立請(qǐng)求消息后，AAL2資源分配失敗，Q.AAL2將直接向RNC發(fā)送釋放證實(shí)消息，呼叫失敗。常見(jiàn)的AAL2資源分配失敗原因包括：PATH對(duì)應(yīng)的物理端口不可用、PATH對(duì)應(yīng)的PVC剩余帶寬資源不足、虛擬媒體網(wǎng)關(guān)可支持用戶數(shù)不足等。 MGW的Q.AAL2收到RNC的建立請(qǐng)求消息后，

6、AAL2資源分配成功，發(fā)建立指示給業(yè)務(wù)用戶。如果業(yè)務(wù)用戶在資源處理過(guò)程中出現(xiàn)錯(cuò)誤，則回送釋放響應(yīng)，Q.AAL2將向RNC發(fā)送釋放證實(shí)消息，呼叫失敗。業(yè)務(wù)用戶常見(jiàn)失敗包括：呼叫控制資源不足、會(huì)話控制資源超時(shí)、AAL2資源占用失敗。MGW的Q.AAL2收到RNC的建立請(qǐng)求消息后，AAL2資源分配成功，發(fā)建立指示給業(yè)務(wù)用戶。如果業(yè)務(wù)用戶在資源處理過(guò)程中出現(xiàn)延遲，在定時(shí)器超時(shí)前沒(méi)有給出響應(yīng)，Q.AAL2將向RNC發(fā)送釋放證實(shí)消息，呼叫失敗。業(yè)務(wù)用戶超時(shí)的常見(jiàn)原因包括：語(yǔ)音處理資源不足、內(nèi)部通信超時(shí)等。1.2.3 正常釋放過(guò)程手機(jī)用戶掛機(jī)后，RNC將向MGW發(fā)送Q.AAL2的釋放請(qǐng)求消息，MGW的QAA

7、L2通知業(yè)務(wù)用戶釋放呼叫資源，然后回送釋放證實(shí)。1.2.4 正常呼叫和掛機(jī)過(guò)程的Q.AAL2跟蹤實(shí)例1.2.5 Q.AAL2重點(diǎn)消息舉例1. ERQ消息消息中需要重點(diǎn)關(guān)注的信息是：ceid，osaid，nsap，alc，sugr。這些信息會(huì)決定AAL2連接建立的成功與否，在失敗時(shí)經(jīng)常要分析它們是否正確填寫。CEID：連接元素標(biāo)識(shí)，CEID中的path identifier是相連設(shè)備之間的唯一通道標(biāo)識(shí)，用于指定PVC，CEID中的channel identifier是通路標(biāo)識(shí)，用于指定PVC中的CID。OSAID：源信令關(guān)聯(lián)標(biāo)識(shí)，不能為全0。DSAID：目的信令關(guān)聯(lián)標(biāo)識(shí)，全0表示“未知”。NSA

8、P：ATM端點(diǎn)地址SUGR：業(yè)務(wù)用戶生成的參考，是一個(gè)長(zhǎng)字。在UMG中結(jié)構(gòu)解釋為1個(gè)字節(jié)的虛擬媒體網(wǎng)關(guān)號(hào)，一個(gè)字節(jié)的CMU板組號(hào)，兩個(gè)字節(jié)的端點(diǎn)索引。ALC：鏈路屬性。描述AAL2鏈路的屬性，CPS-SDU的最大比特率、CPS-SDU的平均比特率、CPS-SDU的最大長(zhǎng)度、CPS-SDU的平均長(zhǎng)度。比特率的單位是64bps，表示即將建立話路的帶寬，CPS-SDU長(zhǎng)度表示的是要支持ATM信元的大小。2. ECF消息消息中需要重點(diǎn)關(guān)注的信息是：osaid。ECF消息已經(jīng)表示建立成功，消息中的信息僅用于事后分析。REL消息消息中需要重點(diǎn)關(guān)注的信息是：cause。在異常釋放時(shí)，cause中記錄了原因值

9、，有幾種協(xié)議標(biāo)準(zhǔn)的原因值是可以直接得出釋放原因的。3. RLC消息消息中需要重點(diǎn)關(guān)注的信息是：cause。在釋放應(yīng)答中，cause沒(méi)有實(shí)際意義。但在建立連接時(shí)，對(duì)ERQ消息應(yīng)答RLC，cause則中記錄了原因值。RLC是Iu口Q.AAL2建立失敗時(shí)最常查看的消息。1.3 IuUP協(xié)議應(yīng)用Iu UP 協(xié)議位于Iu 接口的無(wú)線網(wǎng)絡(luò)層的用戶面：Iu UP 協(xié)議層。Iu UP 協(xié)議用于傳送與RAB 相關(guān)的用戶數(shù)據(jù)。一個(gè)Iu UP 協(xié)議實(shí)例（instance）同且只同一個(gè)RAB 相關(guān)。如果對(duì)于一給定UE，建立了幾個(gè)RAB，那么這些RAB 將使用相同數(shù)目的Iu UP 實(shí)例。Iu UP 協(xié)議實(shí)例存在于Iu

10、訪問(wèn)點(diǎn)，即位于CN 和UTRAN 中。當(dāng)RAB 需要在Iu UP 中傳輸用戶數(shù)據(jù)時(shí)，Iu UP 協(xié)議實(shí)例應(yīng)存在于每個(gè)Iu 接口訪問(wèn)點(diǎn)。這些Iu UP 實(shí)例應(yīng)同相關(guān)的RAB 一起建立、重定位及釋放 。圖1-2 UTRAN體系中的UP協(xié)議視圖1.3.2 Iu UP的主要功能Iu UP協(xié)議有透明和支持兩種模式，透明模式僅提供透明傳輸用戶數(shù)據(jù)，支持模式下則還需要支持以下功能：初始化；速率控制；時(shí)間對(duì)準(zhǔn)；錯(cuò)誤事件處理；幀質(zhì)量分類。其中初始化過(guò)程要在RAB指派時(shí)進(jìn)行，所以在語(yǔ)音呼叫中，會(huì)導(dǎo)致失敗的UP過(guò)程一般是初始化，而初始化消息在MGW上也是可以跟蹤到的。圖1-3 m個(gè)RFCI的成功初始化過(guò)程圖1-4

11、不成功初始化過(guò)程: 1) 否定應(yīng)答 或 2) 應(yīng)答超時(shí)初始化失敗的常見(jiàn)原因有：MGW配置的RFCI集合不能包含RNC的RFCI集合，MGW與RNC的UP版本不兼容，一次呼叫帶的RFCI數(shù)目超過(guò)10。初始化超時(shí)的常見(jiàn)原因有：Iu口的AAL2通道未正確建立，初始化報(bào)文CRC校驗(yàn)錯(cuò)。1.3.3 語(yǔ)音呼叫的Iu UP跟蹤實(shí)例1.4 Iu口的基本協(xié)議過(guò)程MGW在Iu接口的協(xié)議交互過(guò)程是：用戶發(fā)起呼叫時(shí)，先做Q.AAL2建立過(guò)程，成功后做UP初始化。用戶掛機(jī)時(shí)，做Q.AAL2的釋放過(guò)程。UP支持模式和透明模式業(yè)務(wù)的差別在于透明模式下沒(méi)有UP的初始化過(guò)程。典型的支持模式業(yè)務(wù)是語(yǔ)音業(yè)務(wù)和非透明數(shù)據(jù)業(yè)務(wù)，典型的

12、透明模式業(yè)務(wù)是VP（H324M）業(yè)務(wù)和透明數(shù)據(jù)業(yè)務(wù)。1.4.1 語(yǔ)音呼叫建立及釋放過(guò)程1.4.2 VP呼叫建立及釋放過(guò)程1.4.3 IuUP重點(diǎn)消息舉例1. 初始化請(qǐng)求消息消息中需要重點(diǎn)關(guān)注的是：modVer，RFCs，modeVerSupp。這些信息不兼容會(huì)造成初始化失敗。modVer是當(dāng)前使用的版本，modeVerSupp是支持的版本集合RFCS 是AMR 語(yǔ)音編碼速率的集合2. 初始化應(yīng)答消息消息中需要重點(diǎn)關(guān)注的是：ackNack。該值在初始化成功時(shí)為ack，失敗時(shí)為nack。第2章 Iu接口故障案例分析2.1 概述Iu接口的業(yè)務(wù)相關(guān)問(wèn)題通常表現(xiàn)為呼叫失敗。某些情況下，從跟蹤的Q.AAL

13、2和Iu UP接口消息能夠分析出失敗的可能原因，再結(jié)合Mc接口跟蹤、內(nèi)部接口跟蹤、查詢配置，則基本可以定位。2.2 典型案例2.2.1 3G用戶呼叫不成功，QAAL2信令建立失敗1. 現(xiàn)象描述手機(jī)用戶做端局局內(nèi)呼叫，被叫用戶尚未接聽(tīng)就已失敗。跟蹤QAAL2接口消息，發(fā)現(xiàn)MGW收到ERQ后，直接回RLC。2. 處理過(guò)程(1) 查看RLC中的cause，為temporary failure。導(dǎo)致這個(gè)錯(cuò)誤碼的可能性較多，不能直接得出結(jié)論，需要具體分析。(2) 打開(kāi)ERQ消息，對(duì)其中的重點(diǎn)信息及可能的錯(cuò)誤進(jìn)行對(duì)比分析。ceid中的path identifier為1，說(shuō)明RNC要求使用的PATH ID為

14、1。查詢MGW的配置，ID為1的PATH已經(jīng)配置并且可用，無(wú)誤；nsap值為09.08.09.08.09.08.09.08.09.08.09.08.09.08.09.08.09.08.09.07，查詢MGW上的鄰節(jié)點(diǎn)配置，地址相同，無(wú)誤；alc中的雙向速率和包大小值填寫正確，查詢MGW上的PVC流量配置，剩余帶寬足夠，無(wú)誤；sugr的值為0x80011，解析出該長(zhǎng)字的最高字節(jié)為0，對(duì)應(yīng)MGW的虛擬媒體網(wǎng)關(guān)ID；解析出長(zhǎng)字的次高字節(jié)為8，對(duì)應(yīng)MGW的CMU板組號(hào)，這兩個(gè)值都正確。但用LST AAL2VMGW查詢對(duì)應(yīng)ASU板上的ATM資源數(shù)配置，0號(hào)虛擬媒體網(wǎng)關(guān)對(duì)應(yīng)的資源數(shù)為0，這樣在虛擬媒體網(wǎng)關(guān)

15、0上是不能分配任何ATM資源的，也就是錯(cuò)誤所在。+ HUAWEI U-SYS UMG8900 2004-08-01 14:44:21O&M #20 %LST AAL2VMGW: BN=0, VMGWID=0;%RETCODE = 0 執(zhí)行成功查詢虛擬媒體網(wǎng)關(guān)信息-板組號(hào) 虛擬媒體網(wǎng)關(guān)號(hào) 最大用戶數(shù)0 0 0(結(jié)果個(gè)數(shù) = 1)- END(3) 更改配置，SET AAL2VMGW設(shè)置虛擬媒體網(wǎng)關(guān)0的用戶數(shù)為12000。再次呼叫，成功。3. 同類問(wèn)題定位指導(dǎo)(1) 通常先查看RLC的錯(cuò)誤碼，對(duì)原因單一的錯(cuò)誤碼，直接定位原因；對(duì)通用錯(cuò)誤碼，劃出可能的錯(cuò)誤范圍；(2) 分析ERQ消息，排除RN

16、C消息錯(cuò)誤和配置錯(cuò)誤；(3) 對(duì)比查詢MGW的數(shù)據(jù)配置，定位解決配置上的錯(cuò)誤。2.2.2 3G用戶呼叫不成功，Iu UP初始化失敗1. 現(xiàn)象描述手機(jī)用戶做端局局內(nèi)呼叫，被叫用戶尚未接聽(tīng)就已失敗。跟蹤QAAL2接口消息沒(méi)有問(wèn)題。跟蹤Iu UP接口，發(fā)現(xiàn)MGW收到初始化請(qǐng)求后，直接回NACK導(dǎo)致協(xié)商失敗。2. 處理過(guò)程(1) 查看NACK消息的原因值，為 “初始化失敗”，可認(rèn)定是RFCI協(xié)商失敗。(2) 打開(kāi)初始化請(qǐng)求消息的解析，分析攜帶的RFCI集合，可以看出帶有3個(gè)RFC，每個(gè)RFC的子流個(gè)數(shù)為3，按照子流長(zhǎng)度判斷，3個(gè)RFC應(yīng)該分別是12.2K、0速率和靜音幀，都是正確的AMR速率。(3)

17、用LST RFCI查看MGW的RFC配置，12.2K和靜音幀對(duì)應(yīng)的RFCI號(hào)分別為7和8，有效；但0速率對(duì)應(yīng)的RFCI號(hào)為63，即無(wú)效的RFCI，這樣RNC的0速率無(wú)法在MGW上匹配，導(dǎo)致初始化失敗。+ HUAWEI U-SYS UMG8900 2004-08-01 14:34:59O&M #14 %LST RFCI:;%RETCODE = 0 執(zhí)行成功RFCI集-Rfci號(hào) 發(fā)送間隔(ms) 編解碼 RFC長(zhǎng)度 幀類型 子流數(shù) 子流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

18、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(結(jié)果個(gè)數(shù) = 15)RFCI集