UMG8900產(chǎn)品黃埔培訓系列教材-14 問題定位-3G類

UMG8900產(chǎn)品問題定位-3G類ISSUE1.0介紹UMG89003G組網(wǎng)時基本業(yè)務流程和常見問題處理前言參考資料Q.2630.1AAL2信令協(xié)議(功能集1)Q.2630.2AAL2信令協(xié)議(功能集2)3GPPTS25.415UTRANIuinterfaceuserplaneprotocols

3GPPTS29.415CoreNetworkNbInterfaceUserPlaneProtocols

學習完此課程，您將會：了解UMG8900處理3G業(yè)務的基本流程和原理了解UP協(xié)議功能和初始化流程能夠處理UMG89003G業(yè)務常見問題目標第1章3G業(yè)務在UMG上的實現(xiàn)第2章UP協(xié)議介紹第3章常見問題處理內(nèi)容介紹第1章3G業(yè)務在UMG上的實現(xiàn)1.1信號流和數(shù)據(jù)流1.2語音呼叫建立及釋放過程1.3VP呼叫建立及釋放過程內(nèi)容介紹信號流和數(shù)據(jù)流－3G局內(nèi)呼叫其中A4L是ATM的光接口板，用于接入ATM承載ASU是ATM的協(xié)議處理板，完成ATM相關協(xié)議（MTP3B，QAAL2等）處理。RNC為R4版本的局內(nèi)呼叫，RNC側(cè)打開TrFO功能時，UMG不插入TC編解碼資源，呼叫模型如上圖所示。如果RNC為R99版本或者RNC沒有打開TrFO功能時，UMG將插入雙TC，這樣對TC資源是極大的浪費，這種情況的呼叫模型如下圖，請盡量避免。信號流和數(shù)據(jù)流－3G出局呼叫區(qū)別局內(nèi)呼叫之處在于，ASU完成ATM協(xié)議處理后經(jīng)過TC的轉(zhuǎn)換為PCM碼流，可以在TDM承載上傳輸，然后經(jīng)過TNU交換后走TDM接口板（如E32）連接至其他網(wǎng)絡。如果3G始發(fā)至固網(wǎng)用戶，為了抵消固網(wǎng)2/4線轉(zhuǎn)換引發(fā)的回聲，UMG還需要在插入EC，拓撲修改為此處的EC為EEC，用于消除固網(wǎng)側(cè)引入的電學回聲。移動用戶產(chǎn)生的回聲是聲學回聲，通常由移動終端或無線接入網(wǎng)進行回聲抵消處理。信號流和數(shù)據(jù)流－3G出局呼叫IP承載對于3G出局呼叫，承載網(wǎng)為IP時，核心網(wǎng)即UMG內(nèi)部的承載拓撲為如果RNC是R99版本、TrFO功能未打開、核心網(wǎng)與接入網(wǎng)采用的語音編解碼（CODEC）不同、核心網(wǎng)與接入網(wǎng)的UP版本不一致等，UMG會在語音承載通道上插入雙TC。承載拓撲變?yōu)椋篈SU完成ATM協(xié)議處理、并將AAL2承載的語音轉(zhuǎn)變?yōu)镮P承載的語音包后經(jīng)過HRU路由轉(zhuǎn)發(fā)走IP接口板（如G1O）發(fā)送至IP網(wǎng)絡。Q.AAL2信令流程Q.AAL2信令系統(tǒng)的主要任務是在網(wǎng)關和RNC間建立和釋放AAL2連接，同時也對UMG上的ATM承載資源等資源進行管理。在Iu接口，Q.AAL2的建立過程都是由RNC發(fā)起的，釋放過程可以由雙方發(fā)起。Q.AAL2協(xié)議實體之間的交互常見的消息有：ERQ、ECF、REL、RLC、RES、RSC、BLC、UBL。Q.AAL2承載建立在手機用戶發(fā)起呼叫，RNC收到RAB指派請求之后，將向MGW發(fā)送Q.AAL2的建立請求（REQ)。MGW的Q.AAL2收到建立請求消息，首先進行AAL2資源的分配，如果分配成功，則發(fā)建立指示給業(yè)務用戶模塊進行呼叫處理資源（ATM端點控制塊SAID）和呼叫控制(UP實例)資源的分配。如果在定時器超時前，Q.AAL2得到業(yè)務用戶模塊的建立響應，則向RNC發(fā)送建立證實消息（ECF），承載建立成功。Q.AAL2承載建立（續(xù)）MGW的Q.AAL2收到RNC的建立請求消息后，如果AAL2資源分配失敗，Q.AAL2將直接向RNC發(fā)送釋放證實消息（RLC），呼叫失敗。常見的AAL2資源分配失敗原因有：PATH對應的物理端口不可用、PATH對應的PVC剩余帶寬資源不足、虛擬媒體網(wǎng)關可支持用戶數(shù)不足等。MGW的Q.AAL2收到RNC的建立請求消息后，AAL2資源分配成功，發(fā)建立指示給業(yè)務用戶。如果業(yè)務用戶模塊在資源處理過程中出現(xiàn)錯誤，則回送釋放響應，Q.AAL2將向RNC發(fā)送釋放證實消息，呼叫失敗。業(yè)務用戶常見失敗包括：呼叫控制資源不足、會話控制資源超時、AAL2資源占用失敗等。Q.AAL2承載建立（續(xù)）MGW的Q.AAL2收到RNC的建立請求消息后，AAL2資源分配成功，發(fā)建立指示給業(yè)務用戶。如果業(yè)務用戶在資源處理過程中出現(xiàn)延遲，在定時器超時前沒有給出響應，Q.AAL2將向RNC發(fā)送釋放證實消息，呼叫失敗。業(yè)務用戶超時的常見原因包括：語音處理資源不足、內(nèi)部通信超時等。Q.AAL2承載釋放手機用戶掛機后，RNC將向MGW發(fā)送Q.AAL2的釋放請求消息（REL)，MGW的QAAL2模塊通知業(yè)務用戶模塊釋放呼叫資源，然后回送釋放證實。Q.AAL2消息跟蹤ERQERQ消息：消息中需要重點關注的信息是：ceid，osaid，nsap，alc，sugr。這些信息會決定AAL2連接建立的成功與否，在失敗時經(jīng)常要分析它們是否正確填寫。ERQ（續(xù)）ceid：呼叫使用的AAL2Path和Channel，每個Path最多可以使用248個channel。nsap：UMG8900上配置的本節(jié)點nsap地址。alc：描述AAL2鏈路的屬性，最大比特率、平均比特率、最大包長度、平均包長度。比特率的單位是64bpsSUGR：ATM端點ID的后四個字節(jié)，1個字節(jié)的虛擬媒體網(wǎng)關號，一個字節(jié)的CMU板組號，兩個字節(jié)的端點索引。OSAID：源信令關聯(lián)標識，RNC上呼叫索引，不能為全0。DSAID：目的信令關聯(lián)標識UMG對應ASU單板上的呼叫索引，全0表示“未知”。ECFECF消息表示建立承載成功，攜帶osaid。REL釋放AAL2承載消息。在異常釋放時，cause中記錄了原因值，有幾種協(xié)議標準的原因值是可以直接得出釋放原因的。REL一般釋放原因有：

41：臨時錯誤，該ASU單板為給定的VMGW分配的資源不夠

使用SETAAL2VMGW設置該ASU單板為指定VMGW分配的資源數(shù)

42：設備擁塞,ASU分配SAID失敗

44：請求的Channel已經(jīng)被占用

47：資源不可用,如ANI資源/Path未配置或path狀態(tài)不可用RLC釋放AAL2承載應答消息。在建立連接時，如果UMG8900對ERQ消息應答RLC，cause則中記錄了原因值。RLC是Iu口Q.AAL2建立失敗時最常查看的消息。Iu口的基本協(xié)議過程用戶發(fā)起呼叫時，先進行Q.AAL2建立協(xié)商，成功后做UP初始化協(xié)商。用戶掛機時，進行Q.AAL2的釋放。UP有兩種模式：支持模式和透明模式業(yè)務。透明模式下沒有UP的初始化過程。典型的支持模式業(yè)務是語音業(yè)務和非透明數(shù)據(jù)業(yè)務，典型的透明模式業(yè)務是VP（VideoPhone）業(yè)務和透明數(shù)據(jù)業(yè)務。UP初始化請求消息消息中需要重點關注的是：modVer，RFCs，modeVerSupp。這些信息不兼容會造成初始化失敗。modVer是當前使用的版本，modeVerSupp是支持的版本集合RFCS是AMR語音編碼速率的集合UP初始化應答消息消息中需要重點關注的是：ackNack。該值在初始化成功時為ack，失敗時為nack，包含ErrorCause

問題ATM局內(nèi)呼叫可能會經(jīng)過UMG8900那些單板？Q.AAL2信令是做什么用的？UP協(xié)商失敗可能是什么原因？小結ATM呼叫數(shù)據(jù)流ATM承載建立和協(xié)商過程小結第2章UP協(xié)議介紹2.1UP協(xié)議總體介紹

2.2UP協(xié)議功能組成2.3 UP協(xié)議消息解讀內(nèi)容介紹UP協(xié)議總體介紹——IuUPIU接口在MGW組網(wǎng)中的位置:

IU接口為RNC和核心網(wǎng)的接口，一般是基于ATM承載

信令承載在AAL5上,

媒體承載在AAL2上UP協(xié)議總體介紹——NbUPNB接口在MGW組網(wǎng)中的位置:

Nb接口是MGW之間用于傳輸用戶數(shù)據(jù)及用戶面控制信令的接口。

基于ATM或IP承載。NBUP協(xié)議在NB接口的位置

NB接口用戶面的控制方法和協(xié)議稱為NBUP

NbUP協(xié)議處在核心網(wǎng)絡層（CNL）和傳輸網(wǎng)絡層（TNL）之間，為核心網(wǎng)絡層提供數(shù)據(jù)傳輸服務。UP協(xié)議總體介紹——UP的操作模式透明模式

除了用戶數(shù)據(jù)的傳輸，不需要IuUP協(xié)議的特別功能

支持模式(且是預定義長度支持模式)

需要一些過程控制功能及一些數(shù)據(jù)流特定功能，而其傳輸?shù)挠脩魯?shù)據(jù)大小可以預定義的方式進行變化UP協(xié)議的功能組成——功能模型介紹幀處理功能（FameHandle）UP幀（控制部分/檢查部分/凈荷）的封裝/解析，幀號處理，保證控制頭的語義正確，幀頭CRC幀控制功能（ProcedureControl）初始化－－UP協(xié)議實體間進行版本信息、RFCI信息交換（重點掌握）速率控制－－控制對端可以發(fā)送數(shù)據(jù)幀的最大速率時間校準－－控制對端發(fā)送數(shù)據(jù)幀的時間（快或慢）錯誤事件處理－－UP發(fā)生錯誤時，通知相關功能模塊非接入層數(shù)據(jù)流特定功能（NASDatastreamsspecificfunctions）數(shù)據(jù)幀序號連續(xù)性檢查凈荷CRC檢查幀質(zhì)量分類（基于RAB屬性DeliveryoferroneousSDE、Radiaoframecalssification、凈荷CRC結果，填寫UP數(shù)據(jù)幀的FQC域）UP協(xié)議過程控制之一——初始化（1）目的：以RFCI和相關的RAB子流SDU大小，配置UP兩個實體。其他附加參數(shù)也可以傳送。通常由負責建立無線網(wǎng)絡層用戶面的實體（SRNC）控制。初始化過程優(yōu)先級最高，當該過程被調(diào)用時，所有其他過程將被掛起，直到初始化過程完成。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協(xié)議過程控制之一——初始化（4）過程控制之二——速率控制（1）目的：向?qū)Φ萓P協(xié)議層說明在相反方向允許的速率。責任體：通常由在UTRAN完成速率控制的控制實體（SRNC）完成。在某些情況下，如：TrFO

和TFO，由IuUP另一端的遠端伙伴進行控制。該過程可以UP初始化完成后的任何時間指示，除非UP實體出現(xiàn)錯誤。過程控制之二——速率控制（2）發(fā)送方：過程控制功能根據(jù)高層的請求，準備速率控制幀的有效載荷，其中包含了速率控制幀的反向允許速率。接收方：過程控制功能檢查新的允許速率是否與在初始化中收到的RFCI集合一致，也核實仍然允許的非速率控制速率。過程控制之二——速率控制（3）成功速率過程示意圖過程控制之二——速率控制（4）不成功速率過程示意圖UP將重新觸發(fā)速率控制過程。如果經(jīng)過NRC次重復，錯誤情況依然存在，UP協(xié)議層（發(fā)送與接收）將采取適當?shù)谋镜貏幼鬟^程控制之三——時間校準（1）目的：通過控制對等IuUP協(xié)議實體的傳輸定時，使RNC中的緩沖時延最小。

IuUP時間校準過程由SRNC控制當用戶數(shù)據(jù)傳輸不被其他控制過程掛起時，該過程可以在任何時間指示。過程控制之三——時間校準（2）發(fā)送方：當檢測到IuUP數(shù)據(jù)報文在不適當?shù)臅r間到達從而導致不必要的緩沖延時時，SRNC將調(diào)用時間校準過程。協(xié)議層向?qū)Φ葘嶓w說明延遲或提前調(diào)整的量值，該量值以500us的單位表示。啟動定時器，等待時間調(diào)整應答幀的接收。接收方：按照SRNC的指示調(diào)整傳輸定時。被接收IuUP協(xié)議層和高層正確處理，后者將發(fā)送時間校準應答幀。過程控制之三——時間校準（3）成功校準過程示意圖過程控制之三——時間校準（4）不成功校準過程示意圖TimeAlignmentnotsupported：不再校準超時：重發(fā)過程控制之四——錯誤事件觸發(fā)條件：監(jiān)測到的一個錯誤（接收錯誤幀或接收未知或不希望的數(shù)據(jù)）高層的請求收到UP的錯誤事件幀錯誤通過UP-StatusIndication或錯誤事件幀通知。包含信息：錯誤原因值錯誤距離，即錯誤發(fā)生的位置優(yōu)先級：當用戶數(shù)據(jù)傳輸不被其他控制過程掛起時，該過程可以在任何時間指示第3章UMG上3G業(yè)務常見問題處理3.13G用戶呼叫不成功，QAAL2信令建立失敗

3.23G用戶呼叫不成功，IuUP初始化失敗

內(nèi)容介紹QAAL2信令建立失敗——（1）【現(xiàn)象描述】手機用戶做端局局內(nèi)呼叫，被叫用戶尚未接聽就已失敗。跟蹤QAAL2接口消息，發(fā)現(xiàn)MGW收到ERQ后，直接回RLC。【處理過程】查看RLC中的cause，為temporaryfailure。導致這個錯誤碼的可能性較多，不能直接得出結論，需要具體分析。QAAL2信令建立失敗——（2）QAAL2信令建立失敗——（3）打開ERQ消息，對其中的重點信息及可能的錯誤進行對比分析。檢查ceid對應的PATH在UMG上是否配置，狀態(tài)是否正常。檢查nsap和UMG配置的鄰接點ID是否相同。LSTQAAL2LOCNODE:;檢查alc中的雙向速率和包大小值是否填寫正確，查詢MGW上的PVC流量配置，剩余帶寬是否足夠，DSPAAL2PATH:;QAAL2信令建立失敗——（4）sugr的值為0x00080011，解析出該長字的最高字節(jié)為0，對應MGW的虛擬媒體網(wǎng)關ID；解析出長字的次高字節(jié)為8，對應MGW的CMU板組號，這兩個值都正確。但用LSTAAL2VMGW查詢對應ASU板上的ATM資源數(shù)配置，0號虛擬媒體網(wǎng)關對應的資源數(shù)為0，這樣在虛擬媒體網(wǎng)關0上是不能分配任何ATM資源的，也就是錯誤所在。+++HUAWEIU-SYSUMG89002004-08-0114:44:21O&M#20%%LSTAAL2VMGW:BN=0,VMGWID=0;%%RETCODE=0執(zhí)行成功查詢虛擬媒體網(wǎng)關信息--------------------板組號虛擬媒體網(wǎng)關號最大用戶數(shù)000(結果個數(shù)=1)---ENDQAAL2信令建立失敗同類問題定位指導通常先查看RLC的錯誤碼，對原因單一的錯誤碼，直接定位原因；對通用錯誤碼，劃出可能的錯誤范圍；分析ERQ消息，排除RNC消息錯誤和配置錯誤；對比查詢MGW的數(shù)據(jù)配置，定位解決配置上的錯誤。3G用戶呼叫不成功，IuUP初始化失敗

【現(xiàn)象描述】手機用戶做端局局內(nèi)呼叫，出現(xiàn)電話可以振鈴但無法接續(xù)。檢查QAAL2接口跟蹤消息沒有發(fā)現(xiàn)問題。跟蹤IuUP接口，發(fā)現(xiàn)MGW收到初始化請求后，直接回NACK導致協(xié)商失敗。或UP跟蹤中只有發(fā)送的請求報文，沒有應答報文?！咎幚磉^程】查看NACK消息的原因值，為“初始化失敗”，可認定是RFCI協(xié)商失敗。IuUP初始化失敗分析RFCI是否合法第一個RFCI對應12.2kbps速率（81+103+60)*50=12200第二個RFCI對應4.75kbps速率（42+53)*50=4750查看編解碼和打包時長是否和Server下發(fā)給UMG的一致。（G.711編解碼根據(jù)包長度可以確定打包時長）打開初始化請求消息，檢查參數(shù)是否正確3G用戶呼叫不成功，IuUP初始化失敗用LSTRFCI查看UP初始化報文中的RFCI在UMG上的配置，如果有RFCI號（RfcNo)為63，則說明UMG不支持該速率，會導致UP協(xié)商失敗。+++HUAWEIUMG89002009-01-0401:15:23O&M#152%%LSTRFCI:CODECID=AMR;%%RETCODE=0accomplishedRFCIset--------

RfciNo.IptiCodecRfciLengthFrametypeFirstflagSubFlownumberSubFlow1SubFlow2SubFlow3

720AMR2447YES38110360020AMR950NO342530120AMR1031NO3