《移動(dòng)通信無(wú)線網(wǎng)絡(luò)優(yōu)化技術(shù)》課件第3章

第3章RAN高層信令過(guò)程3.1概述3.2隨機(jī)接入和RRC連接建立3.3移動(dòng)性管理3.4CS域的業(yè)務(wù)3.5PS域業(yè)務(wù)3.6切換

3.1概

述

通用移動(dòng)通信系統(tǒng)(UniversalMobileTelecommunicationSystem，UMTS)由CN、UTRAN和UE三部分組成，結(jié)構(gòu)如圖3-1所示。CN和UTRAN之間的接口稱為Iu接口，UTRAN和UE之間的接口稱為Uu接口。圖3-1UMTS三大組成部分

UMTS的邏輯結(jié)構(gòu)與第二代移動(dòng)通信系統(tǒng)基本相同，分成兩大功能子網(wǎng)：核心網(wǎng)(CoreNetwork，CN)和無(wú)線接入網(wǎng)(RadioAccessNetwork，RAN)。核心網(wǎng)(CN)處理UMTS系統(tǒng)內(nèi)部的話音呼叫、數(shù)據(jù)連接和交換，進(jìn)行與外部其他網(wǎng)絡(luò)的連接和路由選擇，無(wú)線接入網(wǎng)(RAN)完成所有與無(wú)線有關(guān)的功能。

UMTS網(wǎng)絡(luò)單元構(gòu)成示意圖如圖3-2所示。核心網(wǎng)和無(wú)線接入網(wǎng)與用戶終端設(shè)備(UserEquipment，UE)一起構(gòu)成了完整的UMTS系統(tǒng)，UMTS陸地?zé)o線接入網(wǎng)(UMTSTerrestrialRadioAccessNetwork，UTRAN)執(zhí)行RAN的功能。UTRAN的外部接口有Iu接口和Uu接口，與核心網(wǎng)(CN)之間的接口為稱為Iu接口(分為電路域的Iu-CS，分組域的Iu-PS)，與終端(UE)之間的接口稱為Uu接口。UTRAN的內(nèi)部接口有Iub接口(NodeB與RNC之間的接口)和Iur接口(RNC與RNC之間的接口)。

圖3-2UMTS網(wǎng)絡(luò)單元構(gòu)成示意圖

3.1.1接口協(xié)議和功能

1．Uu接口協(xié)議和功能

第三代移動(dòng)通信的主流標(biāo)準(zhǔn)有TD-SCDMA、WCDMA和CDMA2000，三者的主要區(qū)別體現(xiàn)在空中接口的無(wú)線傳輸技術(shù)上。不同的Uu接口協(xié)議使用各自的無(wú)線傳輸技術(shù)(RTT)。

Uu接口協(xié)議分為用戶平面和控制平面兩大平面，用戶平面?zhèn)鬏斢脩魯?shù)據(jù)，控制平面?zhèn)鬏斚嚓P(guān)信令，以建立、重新配置和釋放各種3G移動(dòng)通信無(wú)線承載業(yè)務(wù)。Uu接口協(xié)議結(jié)構(gòu)圖如圖3-3所示。圖3-3Uu接口協(xié)議結(jié)構(gòu)圖

在Uu接口上，協(xié)議棧按其功能和任務(wù)，被分為物理層(L1)、數(shù)據(jù)鏈路層(L2)和網(wǎng)絡(luò)層(L3)等3層。

L2分為控制平面(C-平面)和用戶平面(U-平面)。在控制平面中包括媒體接入控制(MAC)和無(wú)線鏈路控制(RLC)兩個(gè)子層；在用戶平面除MAC和RLC外，還有分組數(shù)據(jù)會(huì)聚協(xié)議(PDCP)和廣播、多播控制協(xié)議(BMC)。

L3也分為控制平面(C-平面)和用戶平面(U-平面)。在C-平面上，L3的最底層為無(wú)線資源控制(RRC)，它屬于接入層(AS)，終止于RAN。移動(dòng)性管理(MM)和連接管理(CM)等屬于非接入層(NAS)，其中CM層還可以按其任務(wù)進(jìn)一步劃分為呼叫控制(CC)、補(bǔ)充業(yè)務(wù)(SS)、短消息業(yè)務(wù)(SMS)等功能實(shí)體。接入層通過(guò)業(yè)務(wù)接入點(diǎn)(SAP)承載上層的業(yè)務(wù)，非接入層信令屬于核心網(wǎng)功能。

在Uu接口協(xié)議圖中，用圓圈來(lái)標(biāo)注的是層(或子層)之間的業(yè)務(wù)接入點(diǎn)(SAP)。在物理層和MAC子層之間的SAP提供傳輸信道，在RLC子層和MAC子層之間的SAP提供邏輯信道，RLC子層提供3類SAP，對(duì)應(yīng)于RLC的3種操作模式，即非確認(rèn)模式(UM)、確認(rèn)模式(AM)和透明模式(TM)。在C-平面中，接入層和非接入層之間的SAP定義了通用控制(GC)、通知(Nt)和專用控制(DC)等3類業(yè)務(wù)接入點(diǎn)。

無(wú)線資源控制層(RRC)處理用戶終端(UE)和無(wú)線接入網(wǎng)(RAN)之間在第三層控制面的信令以及和更高層(非接入層)之間的關(guān)系。RRC在Uu接口中具有重要的作用，一方面，在UE側(cè)高層(非接入層)通過(guò)業(yè)務(wù)接入點(diǎn)和RRC交互信息，在RAN側(cè)通過(guò)RANAP協(xié)議和業(yè)務(wù)接入點(diǎn)與核心網(wǎng)交互信息，所以高層指令都被封裝成RRC消息；另一方面，RRC層和低層(L1，L2)所有協(xié)議實(shí)體間存在控制接口，RRC通過(guò)這些接口和相應(yīng)原語(yǔ)對(duì)低層進(jìn)行配置和傳輸一些控制命令，同時(shí)低層通過(guò)這些接口報(bào)告相應(yīng)的測(cè)量報(bào)告和狀態(tài)，供RRC決策采用。

2．Iu-CS接口協(xié)議和功能

圖3-4說(shuō)明了Iu-CS的總體協(xié)議結(jié)構(gòu)，為了能更清楚地說(shuō)明傳輸層技術(shù)在3GPP中的演進(jìn)情況，這里使用Release5的協(xié)議結(jié)構(gòu)——把傳輸網(wǎng)絡(luò)的IP化引了進(jìn)來(lái)。

圖3-4中傳輸網(wǎng)絡(luò)層用戶平面和控制平面引入了IP傳輸?shù)臋C(jī)制，相應(yīng)配合的傳輸層協(xié)議也隨之引入?？梢钥闯?，傳輸網(wǎng)絡(luò)的IP化是將來(lái)的必然趨勢(shì)。在現(xiàn)在的Release99的網(wǎng)絡(luò)中，底層的傳輸是ATM(異步傳輸模式)。

圖3-4Iu接口協(xié)議結(jié)構(gòu)CS域

Iu-CS的控制面協(xié)議棧包括RANAP，它構(gòu)筑在寬帶七號(hào)信令或IP信令之上。從3GPPRelease5版本開(kāi)始，傳輸網(wǎng)絡(luò)層提供了兩個(gè)選項(xiàng)：ATM和IP。

1)

ATM方式

Iu-CS控制面的傳輸網(wǎng)絡(luò)層用戶面各個(gè)協(xié)議層依次為信令連接控制部分(SCCP)，消息傳遞部分(MTP3b)，信令A(yù)TM適配層。信令A(yù)TM適配層又可進(jìn)一步分為SSCF、SSCOP以及AAL5等幾層。其中SSCF除將SCCP映射到SSCOP外，還提供SAAL連接管理、鏈路狀態(tài)以及遠(yuǎn)端處理器狀態(tài)監(jiān)視等功能；SSCOP負(fù)責(zé)建立和釋放連接，保證信令消息的可靠傳輸；AAL5則將上層協(xié)議適配到底層ATM信元。

Iu-CS的傳輸網(wǎng)絡(luò)控制面協(xié)議棧包括AAL2連接建立的信令協(xié)議Q.2630.2和Q.2150.1，它們也承載在寬帶七號(hào)信令之上。Iu-CS用戶面協(xié)議棧包括Iu用戶面協(xié)議IuUP和AAL2。

2)?IP方式

Iu-CS的傳輸網(wǎng)絡(luò)用戶面各個(gè)協(xié)議層次依次為信令連接控制部分(SCCP)，消息傳遞部分第三級(jí)用戶適配層(M3UA，M3UA提供了SCCP到SCTP的適配功能)，流控制傳輸協(xié)議(SCTP，SCTP是IETF制定的用于在IP網(wǎng)上傳遞各種信令的協(xié)議棧)，網(wǎng)際互聯(lián)協(xié)議(IP)和數(shù)據(jù)鏈路層協(xié)議。

Iu-CS的傳輸網(wǎng)絡(luò)控制面協(xié)議棧有兩種選項(xiàng)，即基于ALCAP和非ALCAP。非ALCAP不包括傳輸網(wǎng)絡(luò)控制面，建立用戶鏈路所需要的IP地址和UDP端口號(hào)等信息包含在RANAP的RAB指派消息中。

Iu-CS用戶面協(xié)議棧各個(gè)層次依次為Iu用戶面協(xié)議(IuUP)，實(shí)時(shí)傳送協(xié)議(RTP)/實(shí)時(shí)傳送控制協(xié)議(RTCP)，用戶數(shù)據(jù)報(bào)協(xié)議(UDP)，網(wǎng)際互聯(lián)協(xié)議(IP)和數(shù)據(jù)鏈路層協(xié)議。

3．Iu-PS接口協(xié)議和功能

圖3-5說(shuō)明了Iu-PS的總體協(xié)議結(jié)構(gòu)，同樣在這里也引入了IP傳輸機(jī)制。

同Iu-CS結(jié)構(gòu)一樣，在Release99中，用戶平面和控制平面采用共同的ATM傳輸，而物理層也是特定應(yīng)用于Iu-PS域的。

圖3-5Iu接口協(xié)議結(jié)構(gòu)PS域

1)

ATM方式

Iu-PS用戶面協(xié)議棧包括一個(gè)透明的Iu用戶面協(xié)議(IuUP)以及GTP-U加上IPOA。GTP-U提供了在IP地址上復(fù)用多個(gè)用戶的隧道功能。

對(duì)于Iu-PS來(lái)說(shuō)，它不包括傳輸網(wǎng)絡(luò)控制面，建立GTP隧道所需的IP地址等信息包含在RANAP的RAB指派消息中。

2)?IP方式

Iu-PS接口提供了底層傳輸為ATM的選項(xiàng)。

Iu-PS用戶面協(xié)議棧包括一個(gè)透明的Iu用戶面協(xié)議(IuUP)以及GTP-U。GTP-U提供了在IP地址上復(fù)用多個(gè)用戶的隧道功能。

對(duì)于Iu-PS來(lái)說(shuō)，它不包括傳輸網(wǎng)絡(luò)控制面，建立GTP隧道所需的IP地址等信息包含在RANAP的RAB指派消息中。

4．Iub接口協(xié)議和功能

Iub接口是RNC和NodeB之間的接口，用來(lái)傳輸RNC和NodeB之間的信令及無(wú)線接口的數(shù)據(jù)。它的協(xié)議棧是典型的三平面表示法：無(wú)線網(wǎng)絡(luò)層、傳輸網(wǎng)絡(luò)層和物理層。

無(wú)線網(wǎng)絡(luò)層由控制平面的NBAP和用戶平面的FP(幀協(xié)議)組成；傳輸網(wǎng)絡(luò)層采用ATM傳輸，在Release5以后的版本中都引入了IP傳輸機(jī)制；物理層可以使用E1、T1、STM-1等多種標(biāo)準(zhǔn)接口，目前常用的是E1和STM-1。圖3-6為該接口的協(xié)議結(jié)構(gòu)。

圖3-6Iub接口協(xié)議結(jié)構(gòu)

Iub接口主要完成以下功能：

—管理Iub接口的傳輸資源；

—NodeB邏輯O&M操作；

—傳輸O&M信令；

—系統(tǒng)信息管理；

—專用信道控制；

—公共信道控制；

—定時(shí)和同步管理。

由于RNC和NodeB之間具有較短的傳輸距離和相對(duì)密切的對(duì)應(yīng)關(guān)系，沒(méi)有必要采用七號(hào)信令傳輸網(wǎng)絡(luò)，所以無(wú)線網(wǎng)絡(luò)層和傳輸網(wǎng)絡(luò)層控制平面中作為信令承載的SS7協(xié)議棧被更簡(jiǎn)單的SAAL-UNI所代替；另外應(yīng)該注意的是，這里也沒(méi)有引入IP/SCTP。

在無(wú)線網(wǎng)絡(luò)層中，控制平面NBAP功能是通過(guò)具體的基本過(guò)程(EP)實(shí)現(xiàn)的，基本過(guò)程分為兩種類型：Class1和Class2。其中，Class1是指攜帶響應(yīng)消息的過(guò)程，響應(yīng)消息既包含成功的消息，也包含失敗的消息；Class2指攜帶那些無(wú)需響應(yīng)消息的過(guò)程。NBAP基本過(guò)程分為公共過(guò)程和專用過(guò)程，分別對(duì)應(yīng)公共鏈路和專用鏈路的信令過(guò)程。

在無(wú)線網(wǎng)絡(luò)層中，用戶平面FP是用來(lái)傳輸通過(guò)Iub接口上的公共傳輸信道和專用傳輸信道數(shù)據(jù)流的協(xié)議。其主要功能是把無(wú)線接口的幀轉(zhuǎn)化成Iub接口的數(shù)據(jù)幀，同時(shí)產(chǎn)生一些控制幀進(jìn)行相應(yīng)的控制。IubFP的各種幀結(jié)構(gòu)種類很多，主要分為數(shù)據(jù)幀和控制幀兩部分。

3.1.2內(nèi)部協(xié)議轉(zhuǎn)換

協(xié)議的解析是對(duì)等層的概念，即相應(yīng)層的協(xié)議由其對(duì)等層進(jìn)行解析，非對(duì)等層只能進(jìn)行協(xié)議轉(zhuǎn)發(fā)。理解協(xié)議轉(zhuǎn)換關(guān)系有助于理解信令在不同網(wǎng)元即內(nèi)部轉(zhuǎn)換關(guān)系和傳遞過(guò)程。

1．NodeB協(xié)議轉(zhuǎn)換

NodeB協(xié)議轉(zhuǎn)換如圖3-7所示，UERRC層協(xié)議只能對(duì)其對(duì)等層RNCRRC進(jìn)行解析，協(xié)議在Iub接口走的是FP協(xié)議，即用戶平面，故在NodeB內(nèi)部需進(jìn)行協(xié)議轉(zhuǎn)換。

圖3-7NodeB協(xié)議轉(zhuǎn)換圖

2．Uu接口到Iu接口控制平面協(xié)議

Uu接口到Iu接口控制平面協(xié)議示意圖如圖3-8所示。

圖3-8Uu接口到Iu接口控制平面協(xié)議示意圖

3．Uu接口到Iu接口用戶平面協(xié)議

Uu接口到Iu接口用戶平面協(xié)議示意圖如圖3-9所示。圖3-9Uu接口到Iu接口用戶平面協(xié)議示意圖

3.1.3信令過(guò)程總覽

TD-SCDMA系統(tǒng)從業(yè)務(wù)基站啟動(dòng)到用戶業(yè)務(wù)發(fā)起到完成的整個(gè)信令過(guò)程總流程如

圖3-10所示。

圖3-10TD-SCDMA業(yè)務(wù)總流程

3.2隨機(jī)接入和RRC連接建立

3.2.1物理層隨機(jī)接入過(guò)程

任何時(shí)候高層請(qǐng)求在RACH上發(fā)送一條消息時(shí)就會(huì)調(diào)用下面描述的物理隨機(jī)接入過(guò)程。

UE和基站之間的物理層隨機(jī)接入過(guò)程是開(kāi)環(huán)功控和開(kāi)環(huán)同步的過(guò)程，通過(guò)隨機(jī)接入過(guò)程可以調(diào)整終端的發(fā)送功率以及調(diào)整發(fā)送的上行時(shí)延，為后面的RRC連接建立過(guò)程做準(zhǔn)備。

TD-SCDMA系統(tǒng)是一個(gè)同步系統(tǒng)，對(duì)上行和下行同步有比較嚴(yán)格的要求。在空閑模式下，UE和NodeB之間僅建立了下行同步。換句話說(shuō)，此時(shí)UE端并不知道距NodeB的距離，也不能準(zhǔn)確地知道發(fā)送“RRC連接請(qǐng)求”消息時(shí)所需的發(fā)射功率和定時(shí)提前量。如前所述，PRACH位于常規(guī)時(shí)隙內(nèi)，若UE直接在PRACH上發(fā)送連接請(qǐng)求，那么，這個(gè)非同步的信號(hào)將對(duì)同時(shí)隙和相鄰時(shí)隙的其他用戶造成極強(qiáng)的干擾。因而，在TD-SCDMA系統(tǒng)中，專門定義了兩個(gè)時(shí)隙—GP和UpPTS，用于上行同步和初始功率調(diào)整。隨機(jī)接入過(guò)程始于UE在UpPCH上發(fā)送上行同步(SYNCUL)碼。

1．隨機(jī)接入準(zhǔn)備

UE在隨機(jī)接入之前必須保持下行同步并且讀取系統(tǒng)信息。隨機(jī)接入過(guò)程流程如圖3-11所示。

(1)UE通過(guò)當(dāng)前小區(qū)使用的SYNC_DL碼得到與之對(duì)應(yīng)的分配給UpPCH的8個(gè)SYNC_UL碼，隨機(jī)選取一個(gè)用于隨機(jī)接入。

(2)隨機(jī)接入過(guò)程中使用的PRACH、FPACH和S-CCPCH的資源信息在BCH中廣播。

圖3-11隨機(jī)接入過(guò)程

2．隨機(jī)接入沖突

隨機(jī)接入沖突包含兩步，一步是UE的物理層發(fā)送上行同步碼的過(guò)程，另一步是基站檢測(cè)到后，在FPACH信道回復(fù)PhysicalInformation消息的過(guò)程。

(1)

UE首先在UpPTS時(shí)隙發(fā)送此消息。SYNCUL偽序列碼從本小區(qū)8個(gè)允許的ID中隨機(jī)選取一個(gè)，以免不同用戶沖突；考慮無(wú)線路徑的延時(shí)，UE比標(biāo)準(zhǔn)時(shí)刻提前一定時(shí)間發(fā)送；SYNC_UL的發(fā)送功率由UE根據(jù)開(kāi)環(huán)功率來(lái)計(jì)算。

(2)

NodeB在FPACH信道上回復(fù)PhysicalInformation消息。NodeB檢測(cè)到SYNC_UL以后，WT(RNC的配置參數(shù)里配置)子幀以內(nèi)向用戶回復(fù)FPACH。FPACH中包含收到的SYNC_UL的ID以示區(qū)分回復(fù)給不同的用戶。對(duì)于相同ID不同幀發(fā)送的用戶，基站在不同的幀回復(fù)給用戶，在FPACH中以相對(duì)幀號(hào)區(qū)分。如果發(fā)生了碰撞(基站同一時(shí)間收到兩個(gè)相同的SYNC_UL)，基站就不會(huì)給UE回復(fù)響應(yīng)。

在FPACH中還包含對(duì)UE的開(kāi)環(huán)功率控制信息，以便于UE計(jì)算通路的延時(shí)和路徑損耗，使PRACH的發(fā)送可以按準(zhǔn)確的時(shí)間并以期望的接收功率到達(dá)NodeB。

3.2.2RRC連接建立

1．RRC連接建立過(guò)程

RRC連接過(guò)程是為了在UE和UTRAN之間建立一個(gè)RRC連接，該連接是申請(qǐng)傳遞信令通道的過(guò)程。RRC連接建立是根據(jù)UE的非接入層請(qǐng)求進(jìn)行初始化。在網(wǎng)絡(luò)需要與UE建立聯(lián)系時(shí)，需要事先通過(guò)尋呼通知UE，然后再建立RRC連接。

RRC可以建立在公共信道上和專用信道上。RRC連接建立在公共信道還是建立在專用信道，從信令流程看主要體現(xiàn)在是否需要準(zhǔn)備基站側(cè)的資源，就Uu接口的信令來(lái)說(shuō)，二者的流程是一致的，只是RRCConnectionSetup消息中攜帶的信息不同。

1)?RRC連接建立在公傳信道上

當(dāng)RRC連接建立在公共信道上時(shí)，因?yàn)橛玫氖且呀?jīng)建立好的小區(qū)公共資源，所以無(wú)需建立無(wú)線鏈路和用戶面的數(shù)據(jù)傳輸承載。RRC連接建立在公傳信道上的信令流程如圖3-12所示，其主要過(guò)程如下。

(1)

UE通過(guò)CCCH邏輯信道(傳輸信道是RACH)透過(guò)NodeB向RNC發(fā)送RRCConnectionRequest消息。該消息的主要參數(shù)有：

①

InitialUEIdentity：初始的UE標(biāo)識(shí)，如IMSI、TMSI等參數(shù)，用來(lái)讓網(wǎng)絡(luò)識(shí)別發(fā)送該建立請(qǐng)求消息的UE。

②

Establishmentcause：建立原因，有多種類型，但UE每次只能選擇其一。

③測(cè)量IE：在RACH上報(bào)的UE測(cè)量得到的PCCPCH值，參考點(diǎn)是UE的天線。

圖3-12RRC連接建立在公傳信道上

(2)

RNC接受UE的申請(qǐng)，通過(guò)傳輸信道FACH向UE回復(fù)RRCConnectionSetup信息。其中主要參數(shù)有：

①

InitialUEIdentity：與對(duì)應(yīng)的RRCConnectionRequest消息中的一致。

②

RNTI：分為C-RNTI(CellRadioNetworkTemporaryIdentity)和U-RNTI(UTRANRadioNetworkTemporaryIdentity)。U-RNTI用于分配給已經(jīng)建立RRC連接的UE，在一個(gè)UTRAN區(qū)中標(biāo)示一個(gè)UE；C-RNTI用來(lái)在一個(gè)cell中標(biāo)示UE。

③

RRCStateIndicator：用于指示此用戶的RRC是建立在何種狀態(tài)下，即此UE采用何種信道來(lái)傳輸RRC信令。

④

RBInformationElements：此元素組用以指示RRC信令的RB配置信息。主要有rb-id，rlc-info，rb-Mappinginfo等。

⑤

TrCHInformationElements：其中又分別包含Uplinktransportchannels和Downlinktransportchannels。在這一元素組中包含了上、下行公共信道和所分配的專用信道的信息。

⑥

PhyCHinformationelements：此元素組中包含了上、下行物理信道的配置信息，主要有上、下行分配的載頻、時(shí)隙、碼道、擴(kuò)頻因子、調(diào)制方式、midamble分配方式、功率信息等。

(3)

UE通過(guò)傳輸信道是RACH向RNC回復(fù)RRCConnectionSetupComplete信息。在此消息中主要包含UE向網(wǎng)絡(luò)側(cè)上報(bào)UE的能力，同時(shí)向網(wǎng)絡(luò)匯報(bào)當(dāng)前安全模式的相關(guān)參數(shù)信息。主要參數(shù)有：

①

StartList：元素組中所含的start-value值用于安全模式過(guò)程，告知RNC采用的Start值，此值分CS域和PS域。

②

UEradioaccesscapability：此元素組包含UE向網(wǎng)絡(luò)側(cè)上報(bào)的能力，主要有PDCPcapability、RLCcapability、Transportchannelcapability、RFcapabilityTDD、Physicalchannelcapability、UEmulti-mode/multi-RATcapability、Securitycapability、UEpositioningcapability、Measurementcapability。

2)?RRC連接建立在專用信道上

下面介紹RRC建立在專用信道上的過(guò)程，如圖3-13所示。其主要過(guò)程有6個(gè)。

圖3-13RRC連接建立在專用信道

(1)

UE在上行CCCH上發(fā)送一個(gè)RRCConnectionRequest消息，請(qǐng)求建立一條RRC連接。所用的傳輸信道是RACH，信息中包含的主要參數(shù)有：

①

InitialUEIdentity：初始的UE標(biāo)識(shí)，如IMSI、TMSI等參數(shù)，用來(lái)讓網(wǎng)絡(luò)識(shí)別發(fā)送該建立請(qǐng)求消息的UE。

②

Establishmentcause：建立原因，有多種類型，但UE每次只能選擇其一。

③測(cè)量IE：給出在Uu接口上的測(cè)量結(jié)果。

RNC根據(jù)RRC連接建立請(qǐng)求的原因及系統(tǒng)的資源狀態(tài)決定UE建立在專用信道并分配RNTI和L1、L2資源。(一般情況下在發(fā)起電路型業(yè)務(wù)或Speech業(yè)務(wù)以及QoS較高的分組業(yè)務(wù)時(shí)，盡可能地將RRC連接建立在DCH上。)

(2)

RNC準(zhǔn)備建立RRC連接，分配建立RRC連接所需要的資源，并發(fā)送一條RadioLinkSetupRequest消息給NodeB。在該消息中包含有建立無(wú)線鏈路所必需的參數(shù)：Cellid、TransportFormatSet、TransportFormatCombinationSet、Frequency、TimeSlots、信道碼、Powercontrolinformation。

(3)

NodeB配置物理信道，在新的物理信道上準(zhǔn)備接收UE消息，并給RNC發(fā)送一條RadioLinkSetupResponse響應(yīng)消息。

(4)

RNC通過(guò)ALCAP協(xié)議，建立Iub數(shù)據(jù)傳輸承載。Iub數(shù)據(jù)傳輸承載通過(guò)AAL2的綁定標(biāo)識(shí)與DCH綁定在一起。建立Iub數(shù)據(jù)傳輸承載需要NodeB確認(rèn)。

(5)通過(guò)DownlinkSynchronisation和UplinkSynchronisation控制幀，NodeB與RNC為Iub數(shù)據(jù)傳輸承載建立同步。

(6)

NodeB已獲得上行同步(通過(guò)接收UE發(fā)的Specialburst)，用該消息通知RNC。

2．RRC連接建立失敗過(guò)程

RRC連接建立失敗的原因有以下幾種：

(1)接納控制原因。網(wǎng)絡(luò)根據(jù)接納控制和本地資源配置結(jié)果決定拒絕建立RRC連接，并在下行CCCH上發(fā)送一條RRCConnectionReject消息。當(dāng)發(fā)送該消息后，網(wǎng)絡(luò)可以刪除與該UE有關(guān)的上下文。UE根據(jù)RRCConnectionReject消息(或包含協(xié)議錯(cuò)誤的RRCConnectionReject消息)，或者等待適當(dāng)時(shí)間重發(fā)RRCConnectionRequest消息，或者向其他UTRA載頻或其他系統(tǒng)(如GSM)發(fā)送RRC連接建立請(qǐng)求消息，或者因?yàn)槌^(guò)最大重發(fā)次數(shù)而進(jìn)入idle模式。

(2)無(wú)線鏈路建立失敗。網(wǎng)絡(luò)因?yàn)闊o(wú)線鏈路建立失敗而決定拒絕建立RRC連接，并在下行CCCH上發(fā)送一條RRCConnectionReject消息。

上述兩個(gè)原因的信令過(guò)程如圖3-14所示。

圖3-14RRC建立失敗(1)

(3)

UE不支持指配的配置/配置無(wú)效/建立失敗。

如果UE進(jìn)行小區(qū)重選，或定時(shí)器超時(shí)，或物理信道配置失敗，或UE不支持RRCConnectionSetup消息提供的配置，或RRCConnectionSetup消息提供的配置無(wú)效，或RRCConnectionSetup消息包含協(xié)議錯(cuò)誤，UE可以再次發(fā)送RRCConnectionRequest消息發(fā)起RRC連接建立過(guò)程，或進(jìn)入idle模式，如圖3-15所示。

圖3-15RRC建立失敗(2)

3．RRC連接的釋放

建立在公共信道的RRC連接釋放有兩個(gè)過(guò)程，如圖3-16所示。

(1)

RNC初始化釋放專用信道，此時(shí)，RNC通過(guò)DCCH向UE發(fā)送RRCConnectionRelease命令，此命令中給出了網(wǎng)絡(luò)側(cè)發(fā)起釋放的原因。

(2)

UE向RNC發(fā)送RRCConnectionReleaseComplete信息，其中包含數(shù)據(jù)量報(bào)告。RNC確認(rèn)釋放。

圖3-16RRC連接(建立在公共信道)的釋放

建立在專用信道的RRC釋放流程與建立在公共信道上的RRC連接釋放流程的不同之處在于多了RL刪除過(guò)程和IubALCAP承載釋放過(guò)程，如圖3-17所示。

圖3-17RRC連接(建立在專用信道)釋放

3.3移

動(dòng)

性

管

理

用戶的移動(dòng)性和對(duì)移動(dòng)性的自動(dòng)管理是移動(dòng)通信網(wǎng)絡(luò)的基礎(chǔ)，因此移動(dòng)性管理(MM)是移動(dòng)通信網(wǎng)絡(luò)中必不可少的邏輯功能。移動(dòng)性管理是實(shí)現(xiàn)網(wǎng)絡(luò)內(nèi)和網(wǎng)絡(luò)間無(wú)縫漫游的關(guān)鍵。在TD-SCDMA移動(dòng)通信系統(tǒng)中，移動(dòng)性管理包括位置區(qū)更新、路由區(qū)更新、小區(qū)更新和URA更新。

3.3.1位置區(qū)更新

1．位置區(qū)更新的三種方式

位置區(qū)更新屬于電路域的移動(dòng)性管理。位置更新過(guò)程是由HLR、MSC/VLR等實(shí)體之間邏輯配合完成。HLR記錄移動(dòng)用戶當(dāng)前位置信息和所有用戶數(shù)據(jù)；VLR記錄漫游到由該VLR控制位置區(qū)的移動(dòng)用戶的相關(guān)用戶數(shù)據(jù)；MSC處理移動(dòng)用戶的位置登記進(jìn)程，與移動(dòng)用戶對(duì)話并與HLR、VLR交互信息。

位置區(qū)更新包括正常位置區(qū)更新、周期性位置區(qū)更新和IMSI附著。這三類更新的觸發(fā)條件是不同的。IMSI附著過(guò)程一般發(fā)生在開(kāi)機(jī)或重新返回信號(hào)覆蓋區(qū)域或SIM卡被重新插入，同時(shí)需要滿足以下條件：

(1)在RRC接收到的NAS系統(tǒng)消息中，ATT標(biāo)志指示需要IMSI附著過(guò)程。

(2)更新?tīng)顟B(tài)是UPDATED。

(3)駐留的LAI與USIM中保存的LAI相同。

在其他所有需要做位置更新的情況下，除了因?yàn)橹芷谖恢酶露〞r(shí)器T3212超時(shí)，同時(shí)MM更新?tīng)顟B(tài)為“UPDATED”時(shí)進(jìn)行周期性位置更新外，其他都是進(jìn)行正常位置更新。

2．正常位置區(qū)更新

正常位置區(qū)更新用于UE更新當(dāng)前注冊(cè)的位置區(qū)。當(dāng)UE進(jìn)入一個(gè)新位置區(qū)，SIM卡中存儲(chǔ)的位置區(qū)標(biāo)識(shí)與UE所駐留小區(qū)的位置區(qū)(LAC)標(biāo)識(shí)不一致；或者網(wǎng)絡(luò)在MM連接建立響應(yīng)中指示UE在VLR中不可知，此時(shí)UE會(huì)發(fā)起一個(gè)位置登記過(guò)程。

圖3-18是正常位置區(qū)更新的流程圖(RRC釋放沒(méi)畫(huà)出來(lái))。

位置區(qū)更新過(guò)程是純信令過(guò)程，在空閑狀態(tài)時(shí)需要建立RRC連接，為位置更新信令傳遞提供通道。圖3-18正常位置區(qū)更新流程

3．周期性位置區(qū)更新

通過(guò)周期性位置登記(位置區(qū)更新)，PLMN可以保持追蹤UE當(dāng)前的狀態(tài)，特別是保持長(zhǎng)時(shí)間可以由PLMN運(yùn)營(yíng)商根據(jù)具體話務(wù)和用戶習(xí)慣來(lái)設(shè)定調(diào)整。

周期性位置區(qū)更新過(guò)程的啟動(dòng)由UE端的定時(shí)器T3212控制。UE是否需要使用周期性位置區(qū)更新以及T3212的長(zhǎng)度等信息都在系統(tǒng)信息中廣播。T3212超時(shí)MM層將觸發(fā)周期性位置區(qū)更新過(guò)程。同時(shí)為了下一次的啟動(dòng)，定時(shí)器將被重新初始化。若定時(shí)器超時(shí)，UE端的MM不處在空閑模式下，位置區(qū)更新過(guò)程將被延遲，直到MM進(jìn)入空閑模式。

圖3-19是周期性位置更新示意圖。

周期性位置區(qū)更新的過(guò)程與正常位置區(qū)更新的過(guò)程基本一樣，只是在位置區(qū)更新請(qǐng)求消息中注明具體的更新類型為周期性位置區(qū)更新過(guò)程。這里不再贅述。

圖3-19周期性位置更新示意圖

4．位置區(qū)更新拒絕流程

位置區(qū)更新被CN拒絕的流程如圖3-20所示。CN在LAUPREJ消息中說(shuō)明了位置區(qū)拒絕更新的原因。位置區(qū)拒絕更新包括Iu連接的釋放和RRC連接釋放。

圖3-20位置區(qū)更新拒絕流程

5．IMSI附著

IMSI附著過(guò)程和正常位置區(qū)更新過(guò)程的區(qū)別在于，UE開(kāi)機(jī)且LAC沒(méi)改變時(shí)，MM觸發(fā)的位置區(qū)更新類型“IMSIattach”。

6．IMSI去附著

IMSI分離過(guò)程即移動(dòng)用戶關(guān)機(jī)，MS發(fā)起DETACH的流程，MSC/VLR置用戶狀態(tài)為IMSI分離，該流程一般不通知HLR。若該MS被撥打，MSCserver會(huì)將用戶關(guān)機(jī)情況直接通知主叫方。

當(dāng)UE關(guān)機(jī)時(shí)，向網(wǎng)絡(luò)發(fā)出關(guān)機(jī)信號(hào)，MSCserver/VLR記錄用戶已經(jīng)關(guān)機(jī)。有些移動(dòng)終端在通話期間直接關(guān)電源時(shí)，也可以發(fā)起DETACH流程。IMSI去附著的流程如圖3-21所示。

圖3-21IMSI去附著

3.3.2路由區(qū)更新

路由區(qū)更新由UE發(fā)起，但只在PMM沒(méi)有信令連接時(shí)才能進(jìn)行。在路由區(qū)更新的過(guò)程中，UE端和網(wǎng)絡(luò)端的數(shù)據(jù)傳輸都將繼續(xù)進(jìn)行。路由區(qū)更新包括正常路由區(qū)更新和周期性路由區(qū)更新。

1．一般路由區(qū)更新

一般路由區(qū)更新由路由區(qū)改變引起，且新路由區(qū)對(duì)應(yīng)的網(wǎng)絡(luò)模式為Ⅱ。一般路由區(qū)更新過(guò)程如圖3-22所示。

一般路由區(qū)更新的具體過(guò)程如下：

(1)如果沒(méi)有RRC連接，先建立RRC連接。

(2)用戶發(fā)送路由區(qū)更新請(qǐng)求消息(帶有P-TMSI、老的RAI、跟隨請(qǐng)求、路由更新類型等參數(shù))給新的SGSN。如果用戶有上傳的信令或數(shù)據(jù)，跟隨請(qǐng)求應(yīng)該被置上。RNC將消息轉(zhuǎn)發(fā)給SGSN前，要加上用戶所在位置所屬的路由區(qū)標(biāo)識(shí)(包括路由區(qū)編碼RAC和位置區(qū)編碼LAC)。

(3)鑒權(quán)和安全模式控制過(guò)程是核心網(wǎng)可選的信令流程。如果鑒權(quán)部分失敗，則路由區(qū)更新被拒絕。

(4)新SGSN回應(yīng)用戶路由更新接受消息(帶有P-TMSI、VLRTMSI、P-TMSI簽名)。

(5)如果RAUP接受消息中帶有P-TMSI/TMSI或N-PDU號(hào)，則UE以附著完成消息給SGSN確認(rèn)新分配的P-TMSI等。

圖3-22一般路由區(qū)更新過(guò)程

2.周期性路由區(qū)更新

周期性路由區(qū)更新的過(guò)程與正常路由區(qū)更新的過(guò)程基本一樣，只是在路由區(qū)更新請(qǐng)求消息中注明具體的更新類型為周期性路由區(qū)更新過(guò)程。

周期性路由區(qū)更新由周期性路由區(qū)更新定時(shí)器超時(shí)引起，目的是為了告知網(wǎng)絡(luò)UE仍在網(wǎng)上，周期性路由區(qū)更新由CN的T3312定時(shí)器超時(shí)觸發(fā)，T3312的長(zhǎng)度由SGSN在AttachAccept或RAUPAccept消息中指定。周期性路由區(qū)更新流程如圖3-23所示。

圖3-23周期性路由區(qū)更新流程

3．路由區(qū)更新拒絕

鑒權(quán)等過(guò)程失敗，會(huì)導(dǎo)致路由區(qū)更新失敗，失敗的原因?qū)⒃贑N所發(fā)的路由區(qū)更新拒絕消息中注明。

3.3.3URA更新

URA(UTRANRegistrationArea)是UTRAN內(nèi)部區(qū)域的劃分，適用于UE處于RRC連接狀態(tài)的情形，而且只能在UTRAN端使用(比如由UTRAN發(fā)起的尋呼)。一個(gè)URA包含了一個(gè)或多個(gè)Cell，具體由運(yùn)營(yíng)商決定。

定義URA主要是為了更加有效地使用無(wú)線資源，這方面有兩點(diǎn)原因：

一是從網(wǎng)絡(luò)側(cè)考慮。通過(guò)定義URA，可以使部分移動(dòng)性管理功能由UTRAN來(lái)協(xié)作完成，這樣通過(guò)UTRAN的配合就能更加有效地尋呼到某個(gè)用戶。

二是從UE側(cè)考慮。我們知道UE的RRC連接有三個(gè)狀態(tài)(CELL，URA，IDLE)。如果UE上有業(yè)務(wù)，那么此時(shí)UE應(yīng)處于CELL_DCH狀態(tài)或者CELL_FACH狀態(tài)；如果UE上沒(méi)有業(yè)務(wù)進(jìn)行，但UE上將要有業(yè)務(wù)發(fā)生的可能性比較大，那么UE可以長(zhǎng)時(shí)間處在CELL_PCH或者URA_PCH狀態(tài)；如果UE上目前沒(méi)有業(yè)務(wù)正在進(jìn)行，而且UE將要發(fā)生業(yè)務(wù)的可能性非常小，那么UE應(yīng)處在IDLE狀態(tài)。

之所以要區(qū)別CELL和URA兩個(gè)不同的連接狀態(tài)，是從節(jié)省無(wú)線資源的角度考慮的。如果UE處在CELL_PCH狀態(tài)，但其頻繁在小區(qū)中切換，那么UE要頻繁進(jìn)行小區(qū)更新，這樣是很消耗UE的資源的；而如果引入了URA_PCH狀態(tài)，這樣小區(qū)間的更新將被URA更新取代，UE可以在URAID發(fā)生變化的時(shí)候(跨越多個(gè)cell)再進(jìn)行URA更新，而不必頻繁地進(jìn)行小區(qū)更新。

1．正常URA更新

正常URA更新有兩種原因：URA標(biāo)識(shí)改變或重新進(jìn)入服務(wù)區(qū)。

URA更新過(guò)程由UE發(fā)起，若UE在URA_PCH狀態(tài)下，檢測(cè)到當(dāng)前保存在“URA_IDENTITY”中的URA不包括在系統(tǒng)消息2的URA標(biāo)識(shí)碼列表中，或系統(tǒng)消息2的URA標(biāo)識(shí)碼列表為空，或沒(méi)有收到系統(tǒng)消息2，則UE啟動(dòng)URA更新過(guò)程，設(shè)置原因值為“changeofURA”或“URAreselection”。

URA更新過(guò)程的主要功能包括：

(1)向UTRAN通知。UE在URA_PCH狀態(tài)下重新進(jìn)入服務(wù)區(qū)域，URA重選引起的URA更新。

(2)周期性URA更新可作為URA_PCH狀態(tài)下的UE監(jiān)管機(jī)制。

(3)不屬于當(dāng)前URA的小區(qū)，指派給在URA_PCH狀態(tài)下的UE，UE重新得到一個(gè)新的URA標(biāo)識(shí)。

URA更新發(fā)生在URA_PCH狀態(tài)下，此時(shí)存在RRC連接，因此不需要建立RRC連接。

正常URA更新的流程圖如圖3-24所示。如果URA更新消息中不包含“CNinformationelements”、“Cipheringmodeinfo”、“Integrityprotectionmodeinfo”、“NewC-RNTI”和“NewU-RNT”中的任何一個(gè)，UE將不回“UTRANMOBILITYINFORMATIONCONFIRM”消息。否則，UE將回應(yīng)“UTRANMOBILITYINFORMATIONCONFIRM”消息。

圖3-24正常URA更新流程圖

2．周期性URA更新

周期性URA更新過(guò)程用于UE定期與網(wǎng)絡(luò)聯(lián)絡(luò)，可作為URA_PCH狀態(tài)下的UE監(jiān)管機(jī)制。若UE在URA_PCH狀態(tài)下，RNC側(cè)指定的定時(shí)器T305超時(shí)，且UE尚在配置了周期性更新的小區(qū)的覆蓋范圍內(nèi)，則啟動(dòng)URA更新流程，設(shè)置原因值為“periodicURAupdate”。UE是否需要使用周期性URA

更新以及T305的長(zhǎng)度等信息都在系統(tǒng)消息的SIB1中指定。

周期性URA更新流程如圖3-25所示。周期性URA更新的過(guò)程與普通URA更新的過(guò)程基本一樣，只是在URA更新請(qǐng)求消息中注明具體的更新類型為周期性URA更新過(guò)程。

圖3-25周期性URA更新流程

3．URA更新失敗

當(dāng)URA更新失敗時(shí)，UTRAN直接返回RRC連接釋放，啟動(dòng)一個(gè)RRC連接釋放的過(guò)程。URA更新失敗流程如圖3-26所示。

圖3-26URA更新失敗流程

3.3.4小區(qū)更新

1．小區(qū)更新功能和原因

小區(qū)更新過(guò)程的主要功能如下：

(1)通知UTRAN，處于CELL_PCH或CELL_FACH狀態(tài)的UE重新進(jìn)入了服務(wù)區(qū)；

(2)通知UTRAN，UE的AMRLC實(shí)體發(fā)生了不可恢復(fù)的RLC錯(cuò)誤；

(3)周期性小區(qū)更新可作為CELL_PCH或CELL_FACH狀態(tài)下的UE監(jiān)管機(jī)制；

(4)通知UTRAN，處于CELL_PCH或CELL_FACH狀態(tài)下的UE發(fā)生小區(qū)重選后所在的小區(qū)；

(5)用于處于CELL_DCH狀態(tài)下的UE發(fā)生無(wú)線鏈路故障時(shí)的處理；

(6)用于UE發(fā)送UECAPABILITYINFORMATION消息失敗時(shí)的處理；

(7)通知UTRAN，處于CELL_PCH狀態(tài)下的UE收到尋呼或需要發(fā)送上行數(shù)據(jù)，需要將其狀態(tài)轉(zhuǎn)移到CELL_FACH狀態(tài)；

(8)小區(qū)更新過(guò)程由UE發(fā)起，在UE滿足下面某一種條件時(shí)，可發(fā)起小區(qū)更新過(guò)程。如果某幾種小區(qū)更新觸發(fā)條件同時(shí)發(fā)生，則按照下述次序，優(yōu)先以前面的原因進(jìn)行小區(qū)

更新。

小區(qū)更新(CELLUPDATE)的原因有7種，主要是終端在CELL_DCH/CELL_FACH/CELL_PCH等狀態(tài)下，發(fā)生失步，無(wú)線鏈路失敗時(shí)進(jìn)行的一種恢復(fù)鏈路的情況。或者PCH狀態(tài)下，有上行數(shù)據(jù)傳輸?shù)刃枰⑿帕钸B接是發(fā)送。

(1)上行數(shù)據(jù)傳送。若UE在URA_PCH或CELL_PCH狀態(tài)下，RB1或RB1以上的其它RB上有上行RLC數(shù)據(jù)塊或控制塊需要發(fā)送，則UE啟動(dòng)小區(qū)更新流程，設(shè)置原因值為“uplinkdatatransmission”。

(2)尋呼響應(yīng)。若UE在URA_PCH或CELL_PCH狀態(tài)下，收到針對(duì)該UE的PAGINGTYPE1消息，其中的“UsedPAGINGidentity”為UTRANidentity，不包含可選項(xiàng)“CNoriginatedpagetoconnectedmodeUE”，且觸發(fā)條件1不滿足，則UE啟動(dòng)小區(qū)更新流程，設(shè)置原因值為“PAGINGresponse”。

(3)

Radiolinkfailure。若UE在CELL_DCH狀態(tài)下T313超時(shí)(物理層失步)，且觸發(fā)條件1、2不滿足，則UE在釋放專用物理信道資源后，啟動(dòng)小區(qū)更新流程，設(shè)置原因值為“Radiolinkfailure”。若UE發(fā)送CAPABILITYINFORMATION消息時(shí)，連續(xù)N304發(fā)送失敗(T304超時(shí)且V304>N304)，且觸發(fā)條件1、2不滿足，則UE啟動(dòng)小區(qū)更新流程，設(shè)置原因值為“Radiolinkfailure”。

(4)重進(jìn)入服務(wù)區(qū)。若UE在CELL_FACH或CELL_PCH狀態(tài)下，進(jìn)入無(wú)覆蓋區(qū)后，又在T307或T317超時(shí)之前重新進(jìn)入網(wǎng)絡(luò)覆蓋區(qū)，且觸發(fā)條件1、2、3不滿足，則UE啟動(dòng)小區(qū)更新流程，設(shè)置原因值為“re-enteringservicearea”。

(5)

RLC層不可恢復(fù)的錯(cuò)誤。若UE檢測(cè)到其中的AMRLC實(shí)體發(fā)生了不可恢復(fù)的RLC錯(cuò)誤，且觸發(fā)條件1、2、3、4不滿足，則啟動(dòng)小區(qū)更新流程，設(shè)置原因值為“RLCunrecoverableerror”。

(6)小區(qū)重選。若UE在CELL_FACH或CELL_PCH狀態(tài)下進(jìn)行小區(qū)重選，且觸發(fā)條件1、2、3、4、5不滿足，則啟動(dòng)小區(qū)更新流程，設(shè)置原因值為“Cellreselection”。若UE在CELL_FACH狀態(tài)下，C_RNTI為空，且觸發(fā)條件1、2、3、4、5不滿足，則啟動(dòng)小區(qū)更新流程，設(shè)置原因值為“Cellreselection”。

(7)周期性小區(qū)更新。若UE在CELL_FACH或CELL_PCH狀態(tài)下T305超時(shí)，UE尚在配置了周期性更新的小區(qū)的覆蓋范圍內(nèi)，且觸發(fā)條件1、2、3、4、5、6不滿足，則啟動(dòng)小區(qū)更新流程，設(shè)置原因值為“periodicalcellupdate”。

2．一般小區(qū)更新

小區(qū)更新發(fā)生在CELL_PCH、CELL_FACH、URA_PCH或者是CELL_DCH狀態(tài)下，此時(shí)存在RRC連接，因此不需要建立RRC連接。

UE向RNC所發(fā)的“CellUpdate”請(qǐng)求中包含了“Cellupdatecause”、U-RNTI、Integritycheckinfo、StartList等信息元素。RNC收到UE的“CellUpdate”后，向UE回復(fù)“CellUpdateConfirm”消息。網(wǎng)絡(luò)為了使UE能夠收到CellUpdateConfirm/URAUpdateConfirm消息，可以向UE發(fā)送幾條RRCSN相同的CellUpdateConfirm/URAUpdateConfirm，UE收到后將丟棄后面接收到的重復(fù)消息。此消息中可以攜帶“RBinformationelements”、“Transportchannelinformationelements”、“Physicalchannelinformationelements”、“CNinformationelements”、“Cipheringmodeinfo”、“Integrityprotectionmodeinfo”、“NewC-RNTI”和“NewU-RNT”等信息。根據(jù)此信息中所含信息元素的不同，小區(qū)更新的信令過(guò)程分以下幾種

情況：

(1)如果消息中不包含“RBinformationelements”、“Transportchannelinformationelements”、“Physicalchannelinformationelements”、“CNinformationelements”、“Cipheringmodeinfo”、“Integrityprotectionmodeinfo”、“NewC-RNTI”和“NewU-RNT”中的任何一個(gè)，則UE將不回應(yīng)消息，如圖3-27所示。

圖3-27一般小區(qū)更新過(guò)程(1)

(2)如果消息中包含“CNinformationelements”、

“Cipheringmodeinfo”、“Integrityprotectionmodeinfo”、“NewC-RNTI”或“NewU-RNT”且不包含“RBinformationelements”、“Transportchannelinformationelements”和“Physicalchannelinformationelements”，UE將回應(yīng)“UTRANMobilityInformationConfirm”消息，如圖3-28所示。

圖3-28一般小區(qū)更新過(guò)程(2)

(3)如果消息中包含“Physicalchannelinformationelements”且不包含“RBinformationelements”和“Transportchannelinformationelements”，UE將回應(yīng)“PhysicalChannelReconfigurationComplete”消息，如圖3-29所示。

圖3-29一般小區(qū)更新過(guò)程(3)

(4)如果消息中包含“Transportchannelinformationelements”且不包含“RBinformationelements”，UE將回應(yīng)“TransportChannelReconfigurationComplete”消息，如圖3-30所示。

圖3-30一般小區(qū)更新過(guò)程(4)

(5)如果CellUpdateConfirm消息中包含“RBinformationtoreleaselist”，UE將回應(yīng)“RadioBearerReleaseComplete”消息，如圖3-31所示。

圖3-31一般小區(qū)更新過(guò)程(5)

(6)如果消息中包含“RBinformationtoreconfigurelist”或“RBinformationtobeaffectedlist”且不包含“RBinformationtoreleaselist”，UE將回應(yīng)“RadioBearerReconfigurationComplete”消息，如圖3-32所示。

圖3-32一般小區(qū)更新過(guò)程(6)

(7)在UE進(jìn)行小區(qū)更新過(guò)程中，若出現(xiàn)另外一種不同于當(dāng)前小區(qū)更新原因的小區(qū)更新觸發(fā)條件，此時(shí)UE啟動(dòng)一次新的小區(qū)更新過(guò)程，放棄前一次的小區(qū)更新過(guò)程，如圖3-33所示。

(8)如果UE接收到RRCConnectionRelease消息，則UE按照RRC連接釋放過(guò)程處理。

圖3-33一般小區(qū)更新過(guò)程(7)

3．周期性小區(qū)更新

周期性小區(qū)更新過(guò)程用于UE定期與網(wǎng)絡(luò)聯(lián)絡(luò)。當(dāng)UE處于CELL_FACH或CELL_PCH狀態(tài)，RNC側(cè)指定的定時(shí)器T305超時(shí)，且UE尚在配置了周期性更新的小區(qū)的覆蓋范圍內(nèi)，同時(shí)不滿足其他觸發(fā)小區(qū)更新的條件時(shí)，將會(huì)觸發(fā)周期性的小區(qū)更新過(guò)程。UE是否需要使用周期性小區(qū)更新以及T305的長(zhǎng)度等信息都在系統(tǒng)消息的SIB1中指定。

周期性小區(qū)更新的過(guò)程與基本小區(qū)更新的過(guò)程基本一樣，只是在小區(qū)更新請(qǐng)求消息中注明具體的更新類型為周期性小區(qū)更新過(guò)程，如圖3-34所示。

圖3-34周期性小區(qū)更新

4．小區(qū)更新失敗

當(dāng)小區(qū)更新失敗時(shí)，UTRAN直接返回RRC連接釋放，啟動(dòng)一個(gè)RRC連接釋放的過(guò)程，如圖3-35所示。

此處為什么連續(xù)發(fā)3個(gè)RRCConnectionRelease?因?yàn)閁E收到釋放消息后不會(huì)回發(fā)確認(rèn)消息，為保證能收到，故下發(fā)了3次，此處下發(fā)次數(shù)可以在網(wǎng)絡(luò)側(cè)設(shè)定。

圖3-34小區(qū)更新失敗過(guò)程

3.4CS域的業(yè)務(wù)

CS域業(yè)務(wù)是電路交換業(yè)務(wù)，CS域業(yè)務(wù)主要包括一些語(yǔ)音業(yè)務(wù)，即普通語(yǔ)音(AMR)和視頻電話(CS64)，但是也包括一些電路型數(shù)據(jù)業(yè)務(wù)，最為常見(jiàn)和經(jīng)典的就是傳真。PS分組交換業(yè)務(wù)，就是常見(jiàn)的數(shù)據(jù)業(yè)務(wù)，也包括流媒體業(yè)務(wù)、VOIP等。

3.4.1MOC過(guò)程

MOC就是MobileOriginatedCall，也就是移動(dòng)電話作為主叫撥打網(wǎng)絡(luò)中其他終端的過(guò)程。

1．呼叫總體流程

CS域呼叫總體流程如圖3-36所示。

這里要說(shuō)明的是，該總體描述僅表示在IDLE時(shí)行為，如在連接模式，RRC連接建立之前的過(guò)程不需要。

圖3-36CS域呼叫總體流程圖

2．MOC子過(guò)程

對(duì)一個(gè)MOC過(guò)程來(lái)說(shuō)，可以分為隨機(jī)接入和RRC連接建立過(guò)程、初始直傳/上下行直傳、安全模式控制、呼叫建立過(guò)程、RAB建立過(guò)程和振鈴/接聽(tīng)過(guò)程六個(gè)子過(guò)程。這六個(gè)子過(guò)程關(guān)系如圖3-37所示。

圖3-37MOC的六個(gè)子過(guò)程

MOC主要過(guò)程介紹如下：

1)隨機(jī)接入和RRC連接建立過(guò)程

隨機(jī)接入和RRC連接建立過(guò)程的信令流程圖見(jiàn)圖3-11和圖3-13。

(1)

UE在取得下行同步后，當(dāng)用戶撥號(hào)時(shí)，向NodeB發(fā)送SYNC_UL，接收到NodeB回應(yīng)的FPACH信息后，在RACH信道上向RNC發(fā)送RRCConnectionRequest消息，發(fā)起RRC連接建立過(guò)程。上述過(guò)程中，一系列原語(yǔ)從MMI→CC→MM→RRC，原語(yǔ)中包含消息CMSERVICEREQUEST。

參數(shù)：CM業(yè)務(wù)類型，Cipheringkeysequencenumber，MobileIdentity(IMSI、IMEI、TMSI等)。

(2)

RNC準(zhǔn)備建立RRC連接，分配建立RRC連接所需要的資源，并發(fā)送一條RadioLinkSetupRequest消息給NodeB。

主要參數(shù)：cellid，TransportFormatSet，TransportFormatCombinationSet，frequency，TimeSlots，信道碼，Powercontrolinformation。

(3)

NodeB配置物理信道，在新的物理信道上準(zhǔn)備接收UE消息，并給RNC發(fā)送一條RadioLinkSetupResponse響應(yīng)消息。

主要參數(shù)：Signallinglinktermination，Transportlayeraddressinginformation(AAL2address，AAL2BindingIdentity)fortheIubDataTransportBearer。

(4)

RNC通過(guò)ALCAP協(xié)議，建立Iub數(shù)據(jù)傳輸承載。Iub數(shù)據(jù)傳輸承載通過(guò)AAL2的綁定標(biāo)識(shí)與DCH綁定在一起。建立Iub數(shù)據(jù)傳輸承載需要NodeB確認(rèn)。

(5)

(6)通過(guò)DownlinkSynchronisation和UplinkSynchronisation，控制幀，NodeB與RNC為Iub數(shù)據(jù)傳輸承載建立同步，此后NodeB開(kāi)始DL發(fā)送。

(7)

RNC在FACH信道上發(fā)送RRCConnectionSetup消息給UE。

主要參數(shù)：InitialUEIdentity，RNTI，CapabilityUpdateRequirement，TransportFormatSet，TransportFormatCombinationSet，F(xiàn)requency，TimeSlots，信道碼，Powercontrolinformation。

(8)

UE在DCCH上發(fā)送RRCConnectionSetupComplete

消息給RNC，RRC連接建立完成。

主要參數(shù)：Integrityinformation，cipheringinformation。

2)建立初始直傳/上下行直傳

圖3-38是初始直傳/上下行直傳信令流程。

NAS信令建立流程是在UE與UTRAN之間的RRC連接建立成功之后，UE通過(guò)RNC建立與CN的信令連接，用于UE與CN交互NAS信息，如鑒權(quán)、業(yè)務(wù)請(qǐng)求、連接建立等。

UE與CN的交互信令，對(duì)于RNC而言，都是直傳消息。RNC在收到第一條直傳消息，即初始直傳消息(InitialDirectTransfer)時(shí)，將建立與CN之間的信令連接，該連接建立在SCCP之上。

圖3-38初始直傳/上下行直傳信令流程

初始直傳/上下行直傳的具體信令過(guò)程為：

(1)

UE在DCCH上給RNC發(fā)送一條InitialDirectTransfer(CMServiceRequest)消息，該消息包括了UE請(qǐng)求的業(yè)務(wù)類型等信息。

主要參數(shù)：CMservicetype：此IE給出了UE請(qǐng)求的業(yè)務(wù)類型。目前主要有：Mobileoriginatingcallestablishment，Emergencycallestablishment，Shortmessageservice，Supplementaryserviceactivation，Voicegroupcallestablishment，Voicebroadcastcallestablishment；此處的消息類型是Mobileoriginatingcallestablishment。

LocationServicesMobileidentity：此IE給出了UE發(fā)起業(yè)務(wù)請(qǐng)求的身份，此處可以是TMSI或IMSI。

(2)

RNC發(fā)起初始到CN的信令連接，并發(fā)送一條InitialUEMessage消息給CN，通知CN關(guān)于UE請(qǐng)求的業(yè)務(wù)等內(nèi)容。

主要參數(shù)：NASPDU(couldforaGSMbasedCNbee.g.CMServiceRequest，LocationUpdateRequestetc.)，CNdomainindicator(indicatingtheCNdomaintowardswhichthismessageissent)。

通過(guò)初始直接傳輸過(guò)程后，可使用該信令連接傳輸U(kuò)E和CN之間的NAS消息。

(3)

CN發(fā)送RANAP消息DirectTransfer(AuthenticationRequest)到RNC，要求對(duì)UE進(jìn)行鑒權(quán)(可選)。

主要參數(shù)：

①

ParameterRAND，即鑒權(quán)隨機(jī)數(shù)。UE通過(guò)此隨機(jī)數(shù)來(lái)計(jì)算RES值，以及生成完整性保護(hù)和加密中所使用的IK、CK。

②

ParameterAUTN。此值中包含了CN側(cè)的MAC值，UE可以通過(guò)此值對(duì)CN進(jìn)

行鑒權(quán)。

(4)

RNC發(fā)送RRCDownlinkDirectTransfer(AuthenticationRequest)消息給UE。

主要參數(shù)：NASMessage，NAS消息由UTRAN透明地傳輸?shù)経E。

(5)

UE發(fā)送RRCUplinkDirectTransferMessage(AuthenticationResponse)消息給RNC，告知網(wǎng)絡(luò)側(cè)UE已經(jīng)按照鑒權(quán)要求完成了鑒權(quán)。

主要參數(shù)：RES，即UE根據(jù)接收的RAND和AUTN計(jì)算得到的響應(yīng)值，CN可以通過(guò)此值對(duì)UE進(jìn)行鑒權(quán)。

(6)

RNC發(fā)送RANAP消息DirectTransfer給CN，將UE的NAS消息轉(zhuǎn)發(fā)給CN。

主要參數(shù)：NASPDU，NAS消息被透明的傳輸?shù)経TRAN。

3)安全模式控制

安全模式控制是由網(wǎng)絡(luò)側(cè)用來(lái)向無(wú)線接入網(wǎng)側(cè)發(fā)送加密信息。在此過(guò)程中，核心網(wǎng)的網(wǎng)絡(luò)側(cè)將與無(wú)線接入網(wǎng)協(xié)商對(duì)用戶終端進(jìn)行加密的算法，使得用戶在后續(xù)的業(yè)務(wù)傳遞過(guò)程中使用加密算法；并且在終端用戶發(fā)生切換后，盡可能地使用此加密算法—即用于加密的有關(guān)參數(shù)會(huì)送到切換的RNC。

安全模式控制的信令流程圖如圖3-39所示。具體信令過(guò)程為：

圖3-39安全模式控制信令流程

(1)

CN發(fā)送RANAP消息SecurityModeCommand給RNC，要求終端進(jìn)行安全模式控制。

(2)

RNC在下行DCCH上發(fā)送RRCSecurityModeCommand給UE，開(kāi)始/重啟加密過(guò)程。

(3)

UE成功應(yīng)用新的加密方式后，在上行DCCH上發(fā)送RRCSecurityModeComplete給RNC。

(4)

RNC發(fā)送RANAP消息SecurityModeComplete給CN，雙方完成安全模式控制。

4)呼叫建立過(guò)程

當(dāng)UE發(fā)起一個(gè)呼叫的時(shí)候，UE的應(yīng)用層MMI(Man-MachineInterface，人-機(jī)界面)將首先發(fā)起一個(gè)呼叫建立的請(qǐng)求。如果UE發(fā)起一個(gè)普通呼叫，CC實(shí)體將首先向網(wǎng)絡(luò)發(fā)送一條SETUP消息，此消息主要包含TI(TransactionIdentifier)、承載能力(bearercapability)、被叫用戶號(hào)碼(calledpartyBCDnumber)、被叫用戶子地址(calledpartysubaddress)、SI(StreamIdentifier，流量標(biāo)識(shí)，只有當(dāng)UE支持多個(gè)呼叫時(shí)才存在)以及一些和普通呼叫相關(guān)的參數(shù)；如果UE發(fā)起一個(gè)緊急呼叫，CC實(shí)體將首先向網(wǎng)絡(luò)發(fā)送一條EMERGENCYSETUP消息，此消息主要包含TI、承載能力以及一些和緊急呼叫相關(guān)的參數(shù)。呼叫建立過(guò)程如圖3-40所示。

圖3-40呼叫建立過(guò)程

消息發(fā)出后，CC實(shí)體將等待網(wǎng)絡(luò)處理后的返回消息，此時(shí)可對(duì)應(yīng)3種情況：

(注：這里只考慮正常的呼叫建立過(guò)程，還有一些如定時(shí)器溢出，低層出錯(cuò)等異常情況這里不予描述。后面所述的其他進(jìn)程也與之相同。)

(1)網(wǎng)絡(luò)依次返回CallProceeding、Alerting和Connect消息。

(2)網(wǎng)絡(luò)依次返回Alerting和Connect消息。

(3)網(wǎng)絡(luò)直接返回Connect消息。

其中，CallProceeding消息表示網(wǎng)絡(luò)已經(jīng)收到了UE發(fā)出的建立呼叫所需的全部信息，并且正在處理這些信息；Alerting消息表示被叫方已經(jīng)開(kāi)始振鈴；Connect消息表示被叫方已經(jīng)接受呼叫，即用戶已經(jīng)摘機(jī)。

上述三種情況每次呼叫只能出現(xiàn)一種。對(duì)于其中任何一種情況，UE都將向網(wǎng)絡(luò)返回一條Connectacknowledge消息，當(dāng)網(wǎng)絡(luò)收到此確認(rèn)消息以后，就意味著整個(gè)MOC建立已經(jīng)完成，呼叫雙方可以進(jìn)行通信，CC實(shí)體進(jìn)入激活(active)狀態(tài)。

CN發(fā)送CommonID這條消息是CN通知RNCUE的IMSI號(hào)。用于識(shí)別UTRAN和CN公共的UE。RNC用它找到同一UE存在的其他信令連接(如RRC或IU信令連接)。

5)

RAB建立過(guò)程

RAB是指用戶平面的承載，用于UE和CN之間傳送語(yǔ)音、數(shù)據(jù)及多媒體業(yè)務(wù)。UE首先要完成RRC連接建立，然后才能建立RAB。

RAB既可以建立在公共信道上，也可以建立在專用信道(DCH)上。RAB建立在何種信道上與RRC建立在何種信道上的對(duì)應(yīng)關(guān)系如圖3-41所示。

圖3-41RAB與RRC建立的信道關(guān)系

下面以RRC和RAB均建立在DCH上為例介紹RAB建立的過(guò)程，如圖3-42所示。

圖3-42RRC_DCH時(shí)RAB建立在DCH的過(guò)程

(1)

CN向RNC發(fā)送RANAP消息RadioAccessBearerAssignmentRequest，發(fā)起RAB建立過(guò)程。

主要參數(shù)：RadioAccessBearerID，TrafficClass，RAB-AsymmetryIndicator，MaxBitRate，GuaranteedBitRate，SourceStatisticsDEscriptor。

(2)

RNC通過(guò)ALCAP協(xié)議建立Iu數(shù)據(jù)傳輸承載，并利用AAL2綁定標(biāo)識(shí)將Iu數(shù)據(jù)傳輸承載和無(wú)線接入承載綁定在一起。

(3)

RNC要求其NodeB準(zhǔn)備建立DCH來(lái)承載RAB(RadioLinkReconfigurationPrepare)。

主要參數(shù)：TransportFormatSet，TransportFormatCombinationSet，Powercontrolinformation，TimeSlots，信道碼。

(4)

NodeB配置資源并通知RNC準(zhǔn)備完畢(RadioLinkReconfigurationReady)。

主要參數(shù)：Transportlayeraddressinginformation(AAL2address，AAL2BindingID)forIubDataTransportBearer。

(5)

RNC通過(guò)ALCAP協(xié)議建立Iub數(shù)據(jù)傳輸承載，并利用AAL2綁定標(biāo)識(shí)將Iub數(shù)據(jù)傳輸承載綁定到DCH。

(6)

NodeB和RNC通過(guò)DownlinkSynchronisation和UplinkSynchronistionDCH-FP