UMTS無(wú)線接入網(wǎng)中的IP傳輸

摘要 本文簡(jiǎn)要介紹了IP傳輸在3GPP的研究成果，在Iu/Iur/Iub上的實(shí)現(xiàn)優(yōu)先級(jí)與策略，并討論了Iub用戶面協(xié)議棧、IP Qos、IP傳輸引入的新協(xié)議和對(duì)無(wú)線網(wǎng)絡(luò)層的影響等關(guān)鍵技術(shù)點(diǎn)，最后展望了未來(lái)通信網(wǎng)絡(luò)向全I(xiàn)P融合的趨勢(shì)。

1 引言

　　基于IP的Internet業(yè)務(wù)的爆炸式增長(zhǎng)，給傳統(tǒng)網(wǎng)絡(luò)帶來(lái)了前所未有的變革，使其在業(yè)務(wù)發(fā)展、流量模式、運(yùn)營(yíng)方面發(fā)生了巨大變化。IP技術(shù)在Internet上的成功，使其在移動(dòng)網(wǎng)絡(luò)的業(yè)務(wù)和承載方面也必將得到全面應(yīng)用，未來(lái)的移動(dòng)通信從網(wǎng)絡(luò)到終端均將使用基于IP的協(xié)議通信，包括結(jié)構(gòu)IP化、承載與業(yè)務(wù)IP化的全過(guò)程。IP技術(shù)在移動(dòng)網(wǎng)絡(luò)的應(yīng)用，首先將改變承載網(wǎng)絡(luò)的方式。從系統(tǒng)可擴(kuò)展性、節(jié)約網(wǎng)絡(luò)建設(shè)成本等方面考慮，以IP為核心的傳輸承載將逐漸從核心網(wǎng)向無(wú)線接入網(wǎng)滲透，并將最終成為無(wú)線接入網(wǎng)傳輸承載層的主流協(xié)議。目前IP技術(shù)已經(jīng)在軟交換核心網(wǎng)中廣泛應(yīng)用。

　　3GPP建議在R5階段引入無(wú)線接入網(wǎng)的IP承載，從而實(shí)現(xiàn)核心網(wǎng)和無(wú)線接入網(wǎng)全網(wǎng)向IP傳輸演進(jìn)，因此接入網(wǎng)的IP傳輸已經(jīng)成為業(yè)界關(guān)注的熱點(diǎn)。將IP傳輸技術(shù)引入3G無(wú)線接入網(wǎng)絡(luò)，不僅可以大幅度提高網(wǎng)絡(luò)數(shù)據(jù)承載能力，更可以緩解3G運(yùn)營(yíng)商當(dāng)前面臨的巨大傳輸壓力，特別是HSPA等無(wú)線寬帶技術(shù)的商用對(duì)接入網(wǎng)傳輸帶來(lái)的挑戰(zhàn)。

2 IP傳輸?shù)难芯砍晒?/p>

　　3GPP定義的UTRAN網(wǎng)絡(luò)結(jié)構(gòu)主要接口是Iub，Iur和Iu（包括Iucs和Iups），這些接口上的協(xié)議棧分為無(wú)線網(wǎng)絡(luò)層和傳輸網(wǎng)絡(luò)層。UTRAN的傳輸網(wǎng)絡(luò)實(shí)際上指在Iub/Iu/Iur上位于無(wú)線網(wǎng)絡(luò)層下的傳輸資源，分別是數(shù)據(jù)承載（Data Bearer）和信令承載(Signalling Bearer)。3GPP在早期制訂R99/R4 UTRAN 規(guī)范的時(shí)候，推薦了ATM技術(shù)，其面向連接的特性可以很好地保證業(yè)務(wù)質(zhì)量，并可發(fā)揮ATM的統(tǒng)計(jì)復(fù)用、QOS保證等優(yōu)勢(shì)，當(dāng)時(shí)IP傳輸技術(shù)被認(rèn)為還沒(méi)有成熟, 這樣常用的傳輸配置是：在最后一公里的Iub接口上是ATM over E1，在Iu/Iur上是ATM over STM1。 R4中的Iups上的IP不屬于真正的IP傳輸承載，它僅是IP over ATM，這時(shí)真正的傳輸承載是ATM。原理上講，IP必須滿足UMTS對(duì)QoS、傳輸效率和移動(dòng)性的要求，在這一點(diǎn)上，與對(duì)ATM的要求是相同的。對(duì)ATM 與IP傳輸技術(shù)的比較研究[1]發(fā)現(xiàn)，IP也能提供好的延遲性能，在點(diǎn)到點(diǎn)鏈路上小于5ms,能滿足UMTS對(duì)實(shí)時(shí)的要求，在高的數(shù)據(jù)業(yè)務(wù)負(fù)荷時(shí)有更高的鏈路利用率，并且有更好的開(kāi)放性，更低的成本，更能滿足用戶的通信需求[2]。所以3GPP在R5的UTRAN規(guī)范里正式推薦IP傳輸選項(xiàng)。3GPP R5 TR 25.933(540)是目前最新的標(biāo)準(zhǔn)，在R6及以后沒(méi)有更新。這個(gè)TR 對(duì)在UMTS無(wú)線接入網(wǎng)里的IP傳輸作了全面的介紹。根據(jù)3GPP的WI(工作項(xiàng)目)--- “IP Transport in UTRAN” 的最終輸出報(bào)告---RP-020135, 包括25.933, 共有18個(gè)3GPP規(guī)范描述了IP傳輸，主要涉及到Iub/Iur/Iu接口。

　　概括講，3GPP就IP傳輸標(biāo)準(zhǔn)達(dá)成如下共識(shí)：

　　1/ 新的采用IP傳輸選項(xiàng)的無(wú)線接入網(wǎng)絡(luò)的節(jié)點(diǎn)（RNC和Node B），必須與老的采用R99/R44規(guī)范或仍然采用ATM傳輸選項(xiàng)的R5及以后的規(guī)范的節(jié)點(diǎn)能夠互聯(lián)互通。在R5及以后的無(wú)線接入網(wǎng)中，只采用ATM傳輸選項(xiàng)、只采用IP傳輸選項(xiàng)、和既采用IP傳輸選項(xiàng)又采用ATM傳輸選項(xiàng)的三種節(jié)點(diǎn)設(shè)備能共存�；ヂ�(lián)互通的方式有三種：雙協(xié)議棧（Dual-stack），節(jié)點(diǎn)內(nèi)的傳輸網(wǎng)絡(luò)層邏輯交互功能（logical TNL Interworking function inside node ），單獨(dú)的傳輸網(wǎng)絡(luò)層交互單元（A TNL Interworking Unit）。

　　2/ IP傳輸?shù)囊�入�?duì)無(wú)線網(wǎng)絡(luò)層的影響必須盡量小；必須盡量使用已有的標(biāo)準(zhǔn)協(xié)議，如RFC規(guī)范等。

　　3/ UMTS無(wú)線接入網(wǎng)的IP傳輸網(wǎng)是個(gè)封閉的私有IP網(wǎng)，內(nèi)部安全性風(fēng)險(xiǎn)較低。

　　4/ 對(duì)于IP層下的L1和L2協(xié)議，3GPP沒(méi)有任何限定，決定權(quán)留給移動(dòng)運(yùn)營(yíng)商。

　　5/ IP Qos策略必須支持區(qū)分服務(wù)(DiffServ)，但沒(méi)有完全排除其他方式。

　　6/ 通過(guò)IP層下的復(fù)用技術(shù)（multiplexing）提高采用IP傳輸時(shí)的傳輸網(wǎng)絡(luò)帶寬利用率，使其與采用ATM傳輸時(shí)基本相當(dāng)。

　　7/ 在Iub/Iur/Iu上，ALCAP 將消失，AAL2/ATM 將被RTP（僅在Iucs上有效）/UDP/IP取代，SAAL/AAL5/ATM將被SCTP/IP取代，MTP3b將被M3UA取代。

　　8/ 當(dāng)使用IP傳輸時(shí)，層1將不再提供同步時(shí)鐘參考，這時(shí)其他時(shí)鐘同步方式需被考慮，如NTP等。

　　9/ IP傳輸必須支持IP V6，可以支持IP V4，最好是雙IP協(xié)議棧，但不排除單棧實(shí)現(xiàn)（V4 or V6）

3 IP傳輸在UTRAN接口上的優(yōu)先級(jí)及實(shí)現(xiàn)策略

　　對(duì)于傳統(tǒng)的移動(dòng)運(yùn)營(yíng)商，如果已經(jīng)擁有ATM傳輸網(wǎng)絡(luò)，或者已經(jīng)布署了R4/R99 UMTS網(wǎng)絡(luò)，他們對(duì)IP傳輸?shù)男枨髢A向于逐步演進(jìn)，主要?jiǎng)恿��?lái)自于較高速率的數(shù)據(jù)業(yè)務(wù)（如HSDPA/HSUPA）對(duì)傳輸帶寬的需求增加和降低成本的考慮。當(dāng)他們布署新的R5 UMTS或者升級(jí)現(xiàn)有的R4/R99網(wǎng)絡(luò)到R5時(shí)，他們將混合使用ATM和IP傳輸資源，當(dāng)新的Node B或RNC所在的地理位置有現(xiàn)成的ATM傳輸資源能滿足需要時(shí)，將首先考慮重用ATM，當(dāng)無(wú)ATM傳輸資源可用時(shí)，他們將可能采用IP傳輸，這樣在R5及以后的UTRAN網(wǎng)絡(luò)中，ATM傳輸與IP傳輸將在一定時(shí)間段內(nèi)共存。

　　從節(jié)約成本的角度出發(fā)，Iub上的傳輸資源占有了整個(gè)UTRAN傳輸資源的約70%，另外，核心網(wǎng)的IP化推動(dòng)了Iups上的IP傳輸進(jìn)程，所以Iub與Iups的IP傳輸將有更高優(yōu)先級(jí)，其次是Iur，最低優(yōu)先級(jí)的是Iucs，即：Iups+Iub ?Iur ?Iucs。但對(duì)于新興的移動(dòng)運(yùn)營(yíng)商，為了提高競(jìng)爭(zhēng)力和降低成本，他們采用新技術(shù)的態(tài)度將更為積極，在建一張新的R5 UMTS網(wǎng)絡(luò)時(shí)，他們可能更傾向于在UTRAN全網(wǎng)里全部實(shí)現(xiàn)IP傳輸，即包括Iub/Iu/Iur都需要支持IP傳輸。

　　為了保證UTRAN網(wǎng)絡(luò)從ATM傳輸平滑升級(jí)到IP傳輸，Iub/Iur上應(yīng)該支持雙棧，即同一個(gè)RNC的不同Iub/Iur上可以 同時(shí)支持不同的傳輸選項(xiàng)；但在Iucs和Iups上，RNC通常只連接到一個(gè)核心網(wǎng)節(jié)點(diǎn)，連接到多個(gè)核心網(wǎng)節(jié)點(diǎn)的情形只有兩種：NGN 和Iu-flex，對(duì)于NGN, 在Iucs上，一個(gè)RNC可能連接一個(gè)MGC（控制面）和多個(gè)MGW（用戶面），對(duì)于Iu-flex，一個(gè)RNC確實(shí)連接到多個(gè)核心網(wǎng)節(jié)點(diǎn)，但即使這兩種情況下，一個(gè)RNC連接的核心網(wǎng)節(jié)點(diǎn)仍然較少，為簡(jiǎn)單起見(jiàn)，我們可以假設(shè)RNC在Iucs和Iups上可以只支持單棧，即要么是ATM，要么是IP。

　　當(dāng)在IP上傳輸小的分組數(shù)據(jù)時(shí)，典型的如 AMR語(yǔ)音，IP頭開(kāi)銷(xiāo)將降低傳輸效率。對(duì)于Iub的用戶面，因?yàn)閹�寬有限和�?shù)據(jù)量較大，我們必須考慮傳輸效率問(wèn)題；但對(duì)于Iub的控制面，因?yàn)閿?shù)據(jù)量較小，對(duì)IP頭開(kāi)銷(xiāo)引起的傳輸效率降低可不予考慮，對(duì)Iu和Iur，因?yàn)閭鬏攷�寬不是�?wèn)題，對(duì)傳輸效率也不予考慮。 3GPP對(duì)Iub/Iu/Iur上的協(xié)議棧只規(guī)定了IP 層之上的協(xié)議，對(duì)于層2和層1，沒(méi)有任何限制，我們的建議是優(yōu)先使用Ethernet，RNC和Node B都應(yīng)該提供Ethernet接口，L1支持電纜或光纖�？傊�，Iub的用戶面和Iu/Iur/Iub上的L2/L1是我們實(shí)現(xiàn)IP傳輸時(shí)需要重點(diǎn)考慮的。對(duì)于不同的用戶業(yè)務(wù)需求，將分別采用不同的傳輸策略，如對(duì)于話音業(yè)務(wù)為主的基站，1-2 個(gè)E1能滿足帶寬需求，這時(shí)，ATM over E1是較優(yōu)的選擇，對(duì)IP沒(méi)有太大需求，對(duì)于數(shù)據(jù)業(yè)務(wù)較多，帶寬需求較大的基站，考慮E1較高的租金成本，可以用IP over Ethernet 方案。

4 IP傳輸?shù)年P(guān)鍵技術(shù)

　　4.1 Iub用戶面協(xié)議棧

　　在最后一公里上，盡管RNC和Node B都能提供以太接口，但可能需要使用微波或xDSL傳輸媒介，可獲得的帶寬將低于10M，如只有2M－ 8M，這樣Iub上端到端的帶寬將由最后一公里上的微波或xDSL傳輸媒介能提供的帶寬決定， 傳輸帶寬的瓶頸將在使用最為廣泛的最后一公里的Iub上出現(xiàn)。為保持簡(jiǎn)潔性，我們不推薦使用IP over ATM和在E1上使用IP傳輸。對(duì)于IP傳輸，通常傳輸效率越高，傳輸延遲越大，傳輸延遲越小，傳輸效率越低。所以，采用IP傳輸時(shí)，針對(duì)Iub用戶面，必須考慮傳輸效率和傳輸延遲，使之在有限的帶寬資源下達(dá)到一個(gè)好的平衡。對(duì)于Iub上用戶面協(xié)議棧常有三種實(shí)現(xiàn)策略：使用標(biāo)準(zhǔn)協(xié)議的前兩種和使用私有協(xié)議的第三種。

圖1 使用標(biāo)準(zhǔn)協(xié)議的Iub用戶面協(xié)議棧1

　　這里HC意味頭壓縮，為了節(jié)約UDP/IP/L2TP的頭開(kāi)銷(xiāo)，PPPmux為了共用IP頭，提高鏈路利用率。L2TP 版本3可以直接基于IP，省略下面的UDP。此時(shí)如果8個(gè)AMR FP復(fù)用在一個(gè)IP分組內(nèi)，總的頭開(kāi)銷(xiāo)為47.95%，優(yōu)于使用AAL2/ATM時(shí)的55.28%。對(duì)于數(shù)據(jù)業(yè)務(wù)，該協(xié)議棧比AAL2/ATM更有優(yōu)勢(shì)。此方案的優(yōu)勢(shì)是傳輸效率較高，特別對(duì)于AMR業(yè)務(wù)；直接使用RFC標(biāo)準(zhǔn)協(xié)議，便于實(shí)現(xiàn)運(yùn)營(yíng)商主導(dǎo)下的開(kāi)放的Iub。但缺點(diǎn)是實(shí)現(xiàn)復(fù)雜

圖2 使用標(biāo)準(zhǔn)協(xié)議的Iub用戶面協(xié)議棧2

　　此方案的優(yōu)勢(shì)是實(shí)現(xiàn)簡(jiǎn)單，便于實(shí)現(xiàn)運(yùn)營(yíng)商主導(dǎo)下的開(kāi)放的Iub，對(duì)于高速數(shù)據(jù)業(yè)務(wù)，因?yàn)镮P分組較大，IP頭開(kāi)銷(xiāo)相對(duì)較小，傳輸效率較高，缺點(diǎn)是對(duì)于AMR業(yè)務(wù)傳輸效率很低。

圖3 使用私有協(xié)議的Iub用戶面協(xié)議棧3

　　此方案將多個(gè)用戶的FP復(fù)用到一個(gè)FPMux，每個(gè)IP分組能包含多個(gè)用戶的FP，如果8個(gè)AMR FP復(fù)用在一個(gè)IP分組內(nèi)總的頭開(kāi)銷(xiāo)為63.11%， 略大于使用AAL2/ATM時(shí)的55.28%。但對(duì)于數(shù)據(jù)業(yè)務(wù)， 該協(xié)議棧比AAL2/ATM有優(yōu)勢(shì)。此時(shí)用戶面的傳輸承載標(biāo)識(shí)是包含在每個(gè)FP中的內(nèi)部UDP端口，外部UDP僅用來(lái)做檢驗(yàn)和計(jì)算，詳細(xì)幀格式如下：

圖4 使用私有協(xié)議的Iub用戶面幀格式

　　此方案優(yōu)勢(shì)是傳輸效率較高，相比第一種方案實(shí)現(xiàn)簡(jiǎn)單，但缺點(diǎn)是使用私有的FPMux協(xié)議，不利于Iub的開(kāi)放性。

　　4.2 IP QoS

　　在IP層，區(qū)分服務(wù)(DiffServ)必須被支持，在IP頭里的DSCP碼代表不同的優(yōu)先級(jí)，DSCP和UTRAN里業(yè)務(wù)類(lèi)型間的映射關(guān)系應(yīng)該由移動(dòng)運(yùn)營(yíng)商通過(guò)操作維護(hù)參數(shù)配置。

圖5 DSCP域在IP頭里

　　在對(duì)IP Qos需求最為迫切的最后一公里的Iub上，下列類(lèi)型的業(yè)務(wù)要區(qū)別對(duì)待：

　　1/ Node B synchronization 消息有最小的延遲

　　2/ NBAP信令有小的延遲

　　3/ O&M沒(méi)有延遲要求

　　對(duì)于用戶面四類(lèi)業(yè)務(wù)：

　�。�1） 會(huì)話類(lèi)（Conversational）對(duì)傳輸延遲，傳輸抖動(dòng)有高的要求。

　�。�2） 流類(lèi)（Stream）對(duì)傳輸抖動(dòng)有高的要求，對(duì)傳輸延遲有適中的要求。

　�。�3） 交互類(lèi)（Interactive）和背景類(lèi)（Background）對(duì)傳輸延遲和抖動(dòng)都無(wú)特殊要求。

　　區(qū)分服務(wù)允許定義6 比特的DSCP， 但僅8個(gè)Qos類(lèi)型可以被定義，每個(gè)類(lèi)型對(duì)應(yīng)一個(gè)PHB (Per Hop Behavior)， 在這8個(gè)類(lèi)型中，2 個(gè)被保留為網(wǎng)絡(luò)控制和網(wǎng)間控制，但剩下的6個(gè)QoS里，常常只有4個(gè)被IP骨干傳輸網(wǎng)使用，一個(gè)映射例子如下：

　　" 類(lèi)型 5 (DSCP=EF) : 會(huì)話類(lèi)（Conversational）

　　" 類(lèi)型 3 (DSCP=AF3): 節(jié)點(diǎn)同步（Node B synchronization）與信令 (NBAP and RRC)

　　" 類(lèi)型 1 (DSCP=AF1): 流和交互類(lèi)（Streaming and Interactive）

　　" 類(lèi)型 0 (DSCP=BE) : 背景類(lèi)（Background）和操作維護(hù)消息

　　如果在L2使用以太網(wǎng)，L2的優(yōu)先級(jí)通過(guò)802.1P 和802.1Q被支持，幀格式如下：

圖6：支持L2優(yōu)先級(jí)的以太幀格式

　　另外，需要配置詳細(xì)的QoS參數(shù)。IP Qos的實(shí)現(xiàn)一般通過(guò)購(gòu)買(mǎi)商用軟件組件，運(yùn)行于網(wǎng)絡(luò)處理器上。

　　4.3 IP傳輸引入的新協(xié)議

　　在Iub，Iur和Iu的控制面上，SCTP是新引入的基于IP的傳輸層協(xié)議，在Iur和Iu的控制面上，M3UA代換MTP3B, 在Iub，Iur和Iu的用戶面上，UDP是新引入的傳輸層協(xié)議，在Iucs用戶面，RTP是新引入的實(shí)時(shí)協(xié)議。這里UDP最簡(jiǎn)單，M3UA作為MTP3 用戶層的適配層，用來(lái)在IP上傳輸七號(hào)信令，有較好的適配上層協(xié)議的靈活性。

　　SCTP 是建立在無(wú)連接分組網(wǎng) (例如IP)之上的一種可靠傳輸協(xié)議，相比TCP，3GPP選擇SCTP主要基于以下考慮：

　　1 SCTP是由IETF根據(jù)信令傳輸?shù)奶攸c(diǎn)制訂的。比如，TCP 是基于字節(jié)的傳輸層協(xié)議，SCTP 是基于消息的傳輸層協(xié)議。SCTP 的這一特點(diǎn)使上層用戶協(xié)議便于進(jìn)行數(shù)據(jù)解析，使用SCTP 時(shí)，用戶層在向SCTP 層發(fā)送數(shù)據(jù)或從SCTP層接收數(shù)據(jù)時(shí)不用對(duì)數(shù)據(jù)進(jìn)行額外的分割。

　　2 SCTP 提供更好的安全機(jī)制。Cookie 機(jī)制被引入到SCTP 中來(lái)用于抵御“服務(wù)拒絕攻擊”(denial of service attack)。在預(yù)防意圖使SCTP 服務(wù)器端資源耗竭的“盲攻擊”方面特別有效。SCTP 使用簽名鑒權(quán)機(jī)制，不和客戶機(jī)端交換任何密鑰。

　　3 性能上，能保證信令傳輸?shù)撵`活性，可靠性，并且盡可能高效的利用資源，減少不必要的開(kāi)銷(xiāo)。比如，SCTP 支持在一個(gè)Association 中的多Stream 機(jī)制，每個(gè)Stream 都可被認(rèn)為是保證數(shù)據(jù)順序傳輸?shù)囊粋�(gè)單向邏輯信道，而且SCTP 協(xié)議的設(shè)計(jì)使各個(gè)不同的Stream 傳輸時(shí)能相互獨(dú)立，不會(huì)因?yàn)槟硹lStream 的阻塞，導(dǎo)致其他Stream 的數(shù)據(jù)傳輸受阻。

　　缺點(diǎn)是實(shí)現(xiàn)較復(fù)雜，成熟性沒(méi)有TCP高。

　　根據(jù)RFC 1889，RTP 設(shè)計(jì)成用于滿足多方多媒體會(huì)議的需要。在Iu-CS用戶面，采用基于RTP/UDP/IP數(shù)據(jù)傳輸協(xié)議棧的具體原因如下：

　　（1）通過(guò)進(jìn)行測(cè)量和提供發(fā)送方和接收方之間的通訊，能夠?qū)φZ(yǔ)音質(zhì)量進(jìn)行監(jiān)測(cè)。RTP和RTCP提供了保證順序完整性/重新排序的途徑以及對(duì)VoIP網(wǎng)絡(luò)進(jìn)行QoS監(jiān)測(cè)的途徑。

　�。�2）RTP 是標(biāo)準(zhǔn)的IETF 方案

　　目前，RTP/UDP/IP 是唯一的IETF 實(shí)時(shí)傳輸整合方案�；�于該方案做出決定就是遵循在RAN3 做出的遵循標(biāo)準(zhǔn)IETF 方案的設(shè)計(jì)思想。

　�。�3）RTP 已經(jīng)進(jìn)行了優(yōu)化，能夠與UDP/IP 進(jìn)行結(jié)合。

　　比如，RTP 允許與已有的機(jī)制進(jìn)行組合壓縮，從而得到只有2 字節(jié)的壓縮長(zhǎng)度；但是，GTP 不能與UDP/IP 共用該壓縮上下文，因此GTP 需要14(12+2，完整的GTP 頭長(zhǎng)度為12 字節(jié))字節(jié)的開(kāi)銷(xiāo)�？梢�(jiàn)，RTP 對(duì)效率的提高是非常明顯的（比如對(duì)于語(yǔ)音流）。

　　4.4 IP傳輸對(duì)無(wú)線網(wǎng)絡(luò)層的影響

　　3GPP在Iub，Iur和Iu接口上協(xié)議架構(gòu)的一個(gè)重要思想是使無(wú)線網(wǎng)絡(luò)層與傳輸網(wǎng)絡(luò)層相分離，這樣當(dāng)改變傳輸網(wǎng)絡(luò)層時(shí)，理論上對(duì)無(wú)線網(wǎng)絡(luò)層影響幾乎沒(méi)有影響。事實(shí)上，當(dāng)傳輸網(wǎng)絡(luò)層從ATM傳輸改變?yōu)镮P傳輸時(shí)，因?yàn)閭鬏斁W(wǎng)絡(luò)控制面上的ALCAP被移出,無(wú)線網(wǎng)絡(luò)層控制面上的NBAP，RNSAP和RANAP需要增加建立或釋放IP傳輸承載的功能，無(wú)線網(wǎng)絡(luò)層用戶面將使用UDP socket代替AAL2。

　　在Iub接口上建立用戶面?zhèn)鬏敵休d的信令過(guò)程如圖7。RNC在無(wú)線鏈路建立（RADIO LINK SETUP），無(wú)線鏈路增加（RADIO LINK Addition） 和無(wú)線鏈路重配置準(zhǔn)備（ RADIO LINK RECONFIGURATION PREPARE）過(guò)程中建立Iub用戶面上的傳輸承載。RNC通過(guò)無(wú)線鏈接建立請(qǐng)求消息告訴NodeB自己的IP地址（包含在Transport Layer Address元素里）和UDP端口號(hào)（包含在Binding ID元素里），NodeB在無(wú)線鏈接建立證實(shí)消息通知RNC自己的IP地址和UDP端口號(hào)。Iur上過(guò)程與Iub完全類(lèi)似。在Iucs和Iups上，核心網(wǎng)在RAB安排請(qǐng)求（RANAP RAB ASSIGNMENT REQUEST）消息里把自己的IP地址（包含在Transport Layer Address元素里）和UDP端口號(hào)（包含在Binding ID元素里）通知RNC，然后RNC在 RAB安排反應(yīng)（RANAP RAB ASSIGNMENT RESPONSE）消息里通知核心網(wǎng)自己的IP地址和UDP端口。

圖7 Iub上的用戶面?zhèn)鬏敵休d建立過(guò)程

5 結(jié)束語(yǔ)

　　本文討論了UMTS無(wú)線接入網(wǎng)絡(luò)的IP傳輸承載技術(shù)。 隨著HSDPA/HSUPA的商用和數(shù)據(jù)業(yè)務(wù)的增長(zhǎng)，對(duì)IP傳輸?shù)男枨髮⒏�加�?qiáng)烈。UMTS的下一步LTE（長(zhǎng)期演進(jìn)），即E3G標(biāo)準(zhǔn)將基于IP傳輸。

　　參考文獻(xiàn)

　　[ 1 ] GET/Institut National des T´el´ecommunication, Transport in UMTS Radio Access Network : IP versus AAL2/ATM. paper in http://www-rst.int-evry.fr/~samhat/paperwcnc.pdf

　　[ 2 ] 楊景，黃曉慶，《多媒體、集群化:下一代業(yè)務(wù)的發(fā)展趨勢(shì)》，現(xiàn)代電信科技，3G市場(chǎng)觀察專(zhuān)刊，Sept, 2003

　　[ 3 ] 3GPP 25.933 version540 IP transport in UTRAN

　　[ 4 ] RFC 791 Internet Protocol

　　[ 5 ] RFC 2475: An Architecture for Differentiated Services (DiffServ)

　　[ 6 ] RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

　　[ 7 ] RFC 2661 Layer Two Tunneling Protocol (L2TP)

　　[ 8 ] RFC 1661 The Point-to-Point Protocol (PPP)

　　[ 9 ] RFC 3153 PPP Multiplexing

　　[ 10 ] RFC 2960 Stream Control Transmission Protocol (SCTP)

　　[ 11 ] IP UTRAN研究，編寫(xiě)人：常疆，劉俊強(qiáng)，姜波。青島朗訊科技通訊設(shè)備有限公司，信息產(chǎn)業(yè)部電信研究院

　　[ 12 ] RFC 1889 A Transport Protocol for Real-Time Applications (RTP)

作者：孔令山　林凌峰　王春波 來(lái)源：泰爾網(wǎng)