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