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

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

2、消息舉例10第2章 Iu接口故障案例分析132.1 概述132.2 典型案例132.2.1 3G用戶呼叫不成功，QAAL2信令建立失敗132.2.2 3G用戶呼叫不成功，Iu UP初始化失敗16課程說明課程介紹本課程通過對UMG8900設(shè)備Iu接口的典型協(xié)議過程和實際故障案例進行分析，使學員能夠深刻掌握Q.AAL2和IuUP協(xié)議，并能夠熟練處理日常維護中的相關(guān)故障。課程目標完成本課程學習，學員能夠掌握： 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é)議過程1.1 概述在3GPP的R4典型組網(wǎng)中，MGW在Iu接口的最基本應(yīng)用是實現(xiàn)Iu口承載建立和用戶面協(xié)商的功能（如圖1-1），承載建立過程要通過Q.AAL2協(xié)議與RNC交互，用戶面的協(xié)商則通過Iu UP協(xié)議完成。這兩個協(xié)議與3G業(yè)務(wù)密切相關(guān)，是理解MGW移動業(yè)務(wù)處理過程和定位Iu口問題的重點。圖1-1 3GPP典型組網(wǎng)1.2 Q.AAL2協(xié)議應(yīng)用AAL2信令系統(tǒng)的主要任務(wù)是在兩AAL2信令節(jié)點間建立和釋放AAL2連接，同時也對該信令系統(tǒng)內(nèi)的通道、通路等資源進行必要的維護和管理。連接的建立和釋放是在業(yè)務(wù)用戶的請

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

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

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

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

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

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

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

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

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

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

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

15、0上是不能分配任何ATM資源的，也就是錯誤所在。+ 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)信息-板組號 虛擬媒體網(wǎng)關(guān)號 最大用戶數(shù)0 0 0(結(jié)果個數(shù) = 1)- END(3) 更改配置，SET AAL2VMGW設(shè)置虛擬媒體網(wǎng)關(guān)0的用戶數(shù)為12000。再次呼叫，成功。3. 同類問題定位指導(1) 通常先查看RLC的錯誤碼，對原因單一的錯誤碼，直接定位原因；對通用錯誤碼，劃出可能的錯誤范圍；(2) 分析ERQ消息，排除RN

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

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