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

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

3GPPTS29.415CoreNetworkNbInterfaceUserPlaneProtocols

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

41：臨時(shí)錯(cuò)誤，該ASU單板為給定的VMGW分配的資源不夠

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

42：設(shè)備擁塞,ASU分配SAID失敗

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

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

問(wèn)題ATM局內(nèi)呼叫可能會(huì)經(jīng)過(guò)UMG8900那些單板？Q.AAL2信令是做什么用的？UP協(xié)商失敗可能是什么原因？小結(jié)ATM呼叫數(shù)據(jù)流ATM承載建立和協(xié)商過(guò)程小結(jié)第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)絡(luò)層（CNL）和傳輸網(wǎng)絡(luò)層（TNL）之間，為核心網(wǎng)絡(luò)層提供數(shù)據(jù)傳輸服務(wù)。UP協(xié)議總體介紹——UP的操作模式透明模式

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

支持模式(且是預(yù)定義長(zhǎng)度支持模式)

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

SRNC對(duì)于每個(gè)RAB子流組合分配一個(gè)RFCI。該標(biāo)識(shí)與RFC的對(duì)應(yīng)關(guān)系在IuUP中將一直保持，可以認(rèn)為每個(gè)RFCI代表一個(gè)編碼速率。過(guò)程控制之一——初始化（2）RFCI說(shuō)明示例：AMR編碼的語(yǔ)音比特子流與RFCI集合RFCIFrameTypeIndexAMR

codecmodeTotalnumberofbitsClassAClassBClassC1004,759542530015,1510349540125,9011855630236,7013458760347,4014861870457,95159758405610,22046599406712,22448110360過(guò)程控制之一——初始化（3）初始化過(guò)程示意圖UP協(xié)議過(guò)程控制之一——初始化（4）過(guò)程控制之二——速率控制（1）目的：向?qū)Φ萓P協(xié)議層說(shuō)明在相反方向允許的速率。責(zé)任體：通常由在UTRAN完成速率控制的控制實(shí)體（SRNC）完成。在某些情況下，如：TrFO

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

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

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

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

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

RfciNo.IptiCodecRfciLengthFrametypeFirstflagSubFlownumberSubFlow1SubFlow2SubFlow3

720AMR2447YES38110360020AMR950NO342530120AMR1031NO3