1、課程 WH003402媒體網關IU接口信令分析與處理ISSUE 1.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重點

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

3、PP TS25.415 UTRAN 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連接，同時也對該信令系統內的通道、通路等資源進行必要的維護和管理。連接的建立和釋放是在業務用戶的請

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

5、.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的建立請求消息后，

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

7、L2通知業務用戶釋放呼叫資源，然后回送釋放證實。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表示“未知”。NSA

8、P：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中記錄了原因值

9、，有幾種協議標準的原因值是可以直接得出釋放原因的。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

10、訪問點，即位于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

11、不成功初始化過程: 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的初始化過程。典型的支持模式業務是語音業務和非透明數據業務，典型的

12、透明模式業務是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.AAL

13、2和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為

14、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，這樣在虛擬媒體網關

15、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消息，排除RN

16、C消息錯誤和配置錯誤；(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)

17、用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

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(結果個數 = 15)RFCI集