鼎橋UTRAN與Nokia核心網(wǎng)聯(lián)調(diào)出現(xiàn)的問題及解決

1、 鼎橋RNC與諾基亞CN聯(lián)調(diào) 需要注意的兩個問題及解決方法 Feng xinjian 2008.10.22 內(nèi)容1、網(wǎng)絡(luò)拓撲及軟件版本2、RNC內(nèi)7號信令配置問題3、Iu接口Iu UP操作模式問題4、附錄 TFO和TRFO1、網(wǎng)絡(luò)拓撲及軟件版本TRNC810opc=7673NodeB510MGWspc=7667MSCServerspc=7666Iu CSIubMcSW：U4GU3100SW：MEGU2400SW：V03R01C00H02B070 注：核心網(wǎng)沒有和PSTN連接 2、RNC內(nèi)7號信令配置問題CREATE: N7DPC=DPX:1, NAME=MGW, SPC=7667, SLSMA

2、SK=B0011, STP=OFF, NEIGHBOR=YES, DPCT=IUCS;CREATE: MTP3BLKS=SIGLKSX:0, DPX=1, LNKSLSMASK=B0000, EMERGENCY=OFF;CREATE: MTP3BLINK=SIGLKSX:0/SIGSLC:0, SRN=1, SSN=0, SAALLNKN=1, PRIORITY=0, TCLEN=10, TC=170;CREATE: MTP3BROUTE=DPX:1/SIGLKSX:0, PRIORITY=0; 此種配置的中心思想就是把CN當作R99核心網(wǎng)對待(DPCT=IUCS)，R99核心網(wǎng)可以同時處理控

3、制面和傳輸網(wǎng)絡(luò)面。 這種配置在對端核心網(wǎng)為華為核心網(wǎng)時均可正常工作，在深圳移動項目和廈門移動項目均為此種配置。 但是在和Nokia核心網(wǎng)連接時卻無法正常工作，現(xiàn)象為UE開機無法注冊。下圖為跟蹤的Iu CS信令，根據(jù)信令可以看出，RNC發(fā)給核心網(wǎng)的信令只到了MGW(7667)，而并沒有轉(zhuǎn)發(fā)到MSCserver(7666)。RNC只配置一個到CN的信令點，Nokia核心網(wǎng)把MGW的信令轉(zhuǎn)接功能打開MGW 2、RNC內(nèi)7號信令配置問題RNC只配置一個到CN的信令點，Nokia核心網(wǎng)把MGW的信令轉(zhuǎn)接功能打開進一步跟蹤Iu接口SCCP信令，發(fā)現(xiàn)在UE請求建立SCCP連接(CR)時，核心網(wǎng)拒絕了此請求(

4、CREF)SCCP信令CREF消息 2、RNC內(nèi)7號信令配置問題RNC配置兩個信令點到CN，分別到MGW和MSCserver，其中MGW設(shè)為信令轉(zhuǎn)接點CREATE: N7DPC=DPX:1, NAME=MGW, SPC=7667, SLSMASK=B0011, STP=ON, NEIGHBOR=YES, DPCT=IUCS_ALCAP;CREATE: N7DPC=DPX:2, NAME=MSC SERVER, SPC=7666, SLSMASK=B1111, STP=OFF, NEIGHBOR=NO, DPCT=IUCS_RANAP;CREATE: MTP3BLKS=SIGLKSX:0, DP

5、X=1, LNKSLSMASK=B0000, EMERGENCY=OFF;CREATE: MTP3BLINK=SIGLKSX:0/SIGSLC:0, SRN=1, SSN=0, SAALLNKN=1, PRIORITY=0, TCLEN=10, TC=170;CREATE: MTP3BROUTE=DPX:1/SIGLKSX:0, PRIORITY=0;CREATE: MTP3BROUTE=DPX:2/SIGLKSX:0, PRIORITY=0;CREATE: AAL2ADJNODE=ANI:1, NAME=MGW, ANT=IU, DPX=1;CREATE: AAL2ROUTE=RTX:1,

6、NSAP=H3912345, ANI=1, OWNERSHIP=YES;CREATE: AAL2PATH=ANI:1/PATHID:1, PATHTYPE=NORMAL, ENDSRN=1, ENDSN=7, CARRYSR=WRSS, CARRYSN=2, CARRYPN=4, CARRYVPI=7, CARRYVCI=45, TXTRFX=102, RXTRFX=102, CONTROLSSN=0, OWNERSHIP=LOCAL;此種配置的中心思想就是把核心網(wǎng)當作R4核心網(wǎng)對待，指明MGW只負責傳輸網(wǎng)絡(luò)面(DPCT=IUCS_ALCAP)，而MSCserver則負責控制面(DPCT=IU

7、CS_RANAP)。另外增加了一個MTP3B的路由，此路由使用和MGW相同的信令鏈路，但是目的信令點時Server(7666). 2、RNC內(nèi)7號信令配置問題RNC配置兩個信令點到CN，分別到MGW和MSCserver，其中MGW設(shè)為信令轉(zhuǎn)接點配置更改后，Iu接口信令正確路由到了MSCserver，UE順利完成注冊，下面是對應(yīng)的Iu接口信令：RANAP信令從信令可以看出，UE和CN成功建立了Iu信令連接SCCP信令RNC發(fā)出CR消息給CN后，CN回復CC，說明SCCP連接成功建立MSC Server 2、RNC內(nèi)7號信令配置問題總結(jié)理論上講，當RNC和核心網(wǎng)都支持R99時，在RNC內(nèi)只配置一個

8、信令點就可以和核心網(wǎng)聯(lián)調(diào)成功，比如鼎橋RNC和華為核心網(wǎng)之間就可以采用這種配置方式。但是實際聯(lián)調(diào)過程中，如果這種配置方式不能正常工作，我們也可以采用R4的配置方式，也就是在RNC內(nèi)配置兩個信令點，分別到MGW和MSC Server。3、Iu接口Iu UP操作模式問題 在信令點的問題解決之后，出現(xiàn)了另外一個問題。UE雖然可以正常登記，位置更新，但是UE無法正常進行AMR12.2業(yè)務(wù)(由于CN和PSTN之間沒有連接，所以UE和UE之間互撥）。下圖是跟蹤的Iu口RANAP信令，根據(jù)信令流程可以看出，UE和核心網(wǎng)的Iu信令連接建立正常，但是在雙方協(xié)商RAB指派的參數(shù)之后，由于雙方?jīng)]有達成一致，由核心網(wǎng)

9、發(fā)起釋放了Iu信令連接。因而問題肯定出在Iu接口的用戶面。Iu信令連接建立呼叫處理RAB指派不成功3、Iu接口Iu UP操作模式問題進一步分析RAB ASSIGNMENT REQUEST消息中的參數(shù)，并與華為核心網(wǎng)相應(yīng)消息比較后發(fā)現(xiàn)：Nokia核心網(wǎng)Iu UP mode version是2而華為核心網(wǎng)Iu UP mode version是33、Iu接口Iu UP操作模式問題Nokia的NED文檔對Iu UP操作模式的解釋如下注意這一點3、Iu接口Iu UP操作模式問題Iu UP mode versionRAB分配消息中Iu UP mode version為2則說明了Nokia核心網(wǎng)遵照R4規(guī)范

10、，同時它也認為RNC也是遵照R4規(guī)范。TrFO(Trancoder Free Operation)是R4 網(wǎng)絡(luò)中的一種技術(shù)，當移動用戶之間通話時，用戶的AMR語言碼流在核心網(wǎng)內(nèi)不再進行二次編碼轉(zhuǎn)換，而是直接在兩個用戶之間傳送AMR碼流。根據(jù)Nokia核心網(wǎng)文檔的描述，在Support Mode下Iu UP的兩種操作模式的含義如下：Iu UP mode version 1： MGW和RNC都是遵照R99規(guī)范，當移動用戶之間呼叫建立后采用 TFO方式進行通話Iu UP mode version 2：MGW和RNC都是遵照R4規(guī)范，當移動用戶之間呼叫建立后采用 TrFO方式進行通話3、Iu接口Iu

11、UP操作模式問題RNC實際情況如何呢？是不是支持Iu UP mode version 2和TrFO呢？使用命令GET: RNCCORRMALGOSWITCH=RNCCORRMALGOSWITCH:0;發(fā)現(xiàn)CHSWITCH=CORRM_IUUP_VERSION2_SUPP-0也就是說RNC并不支持R4規(guī)范的Iu UP mode version 2和TrFO，而只支持R99規(guī)范的version 1和TFO。因此當核心網(wǎng)發(fā)起RAB建立請求時，由于核心網(wǎng)和RNC在用戶面對AMR碼流的處理方式不同，在核心網(wǎng)側(cè)采用TrFO而在RNC側(cè)采用TFO，造成了RAB建立失??！這就是UE和UE互撥無法建立通話的原因

12、。使用命令SET: RNCCORRMALGOSWITCH=RNCCORRMALGOSWITCH:0, CHSWITCH=CORRM_IUUP_VERSION2_SUPP-1;重新配置RNC支持UP mode version 2后，UE撥打AMR語音電話正常。華為核心網(wǎng)Iu UP mode version 3的含義是同時支持Mode version 1和2因此當RNC不支持Mode version 2時，華為核心網(wǎng)自動選擇了Mode version 1來適應(yīng)RNC4、TFO和TRFO 在R99網(wǎng)絡(luò)中，話音的AMR碼流從UTRAN，通過Iu口達到核心網(wǎng)時，核心網(wǎng)的編解碼轉(zhuǎn)換設(shè)備要將AMR碼流轉(zhuǎn)換為

13、G.711格式的編碼，封裝在PCM中進行傳輸，到達對端后，需要將G.711編碼再還原為AMR碼流。每一次的編解碼對語音質(zhì)量都是一次損傷，而且G.711編碼的傳輸速率遠比不上AMR編碼。 在R4網(wǎng)絡(luò)中，有兩種方式可以實現(xiàn)在局間直接傳送AMR編碼，而不是G.711編碼，這就是TrFO和TFO功能。 4、附錄 TFO和TRFO TrFO(Transcoder Free Operation)是一種帶外的Transcoder控制協(xié)議，是在R4中定義的新功能，網(wǎng)絡(luò)可以在呼叫建立前就對編解碼的類型和模式進行協(xié)商，如果兩端使用的編解碼一樣(例如都是AMR編碼)，則對于移動到移動的呼叫可以完全不經(jīng)過編解碼轉(zhuǎn)換。

14、TrFO可以提高話音質(zhì)量，并且在分組核心網(wǎng)中可以優(yōu)化網(wǎng)絡(luò)帶寬，因為話音是AMR速率而不是64kbit/s在核心網(wǎng)中傳輸；由于移動網(wǎng)內(nèi)的呼叫可以不使用編解碼器，還可以節(jié)省設(shè)備投資；另外，編解碼協(xié)商在承載建立之前完成，可以保證呼叫使用適當?shù)某休d資源。4、附錄 TFO和TRFO TFO(Tandem Free Operation)是一種帶內(nèi)的通信協(xié)議，是在2G網(wǎng)絡(luò)中已定義的方法。TFO在呼叫建立之后對使用的編解碼進行協(xié)商，發(fā)送方的解碼器和接收方的編碼器被旁路，直接將空中接口中使用的話音幀傳送給接收方。這樣可以改善話音質(zhì)量。TFO功能是在標準的64kbit/s鏈路的基礎(chǔ)上，提取一定數(shù)量的比特，組成子信道，用來傳輸TFO信令和話音幀。4、TFO和TRFO將兩種編解碼協(xié)商方式相比，相同點就是在局間都直接傳送A