在3GPP規格書中，定義了兩種的網路元件：HNB（即為Femtocell），HNB Gateway（即為Femto Gateway）與一個新的介面Iu-h。

HNB經由Iu-h介面將資料傳送到HNB Gateway，而HNB Gateway則利用現有的Iu-CS與Iu-PS介面與核心網路溝通（如圖二）。在這個架構下HNB可說是整合了原本UMTS Macro網路Node-B與RNC的功能（如圖二）。

圖三是HNB Uu介面的通訊協定堆疊架構圖，可分為RRM、RRC、RLC、MAC、FP、NBAP。RRM負責監控目前系統資源，並經由RRC Signaling對手機下命令作資源上的調整與配置。訊息會被RLC做封包切割，並經由MAC多工處理傳到底層。同時，RRM也會經由NBAP對HNB的組態做調整。底下各章節還會對各個協定層做詳細介紹。

《圖一 UMTS Macro網路架構圖》

《圖二 UMTS Femto網路架構圖》

《圖三 HNB Uu介面的通訊協定堆疊架構圖》

什麼是PRM？

RRM為Radio Resource Management的縮寫。RRM模組分成Code Management、Handover control、Admission Control、Load Control 的幾個功能模組。底下將分別介紹這些模組。

Admission Control

在新的手機發出RRC 連結要求、建立新的Radio Bearer或是Radio Bearer組態的重新設定時，Admission Control功能模組必須檢查目前系統狀態如各連結品質、訊號與雜訊比、發射功率，以及目前已存在的使用者數目。同時，它會去估算允許一個新的手機建立連接，對系統負載的影響。當估算結果發現新的手機進入系統時，會對原有的使用者產生極大的干擾時，這時新的手機就會被拒絕註冊。

評斷一個Admission Control演算法的好壞有很多因素，其中兩個重要的指標就是錯誤拒絕率與錯誤接受率。所謂的錯誤拒絕就是當系統有足夠的資源而Admission Control演算法卻拒絕一個連結的要求。錯誤接受則剛好是剛好相反，此情況發生於系統沒有足夠的資源，卻又接受一個新的手機加入要求。倘若這種情況發生時，會影響已存在連結的品質，並會減少HNB的訊號涵蓋區域。所以一個優異的演算法會具有低錯誤拒絕率以及低錯誤接受率。

Handover Control

Handover是讓手機具有移動性的基本功能。當手機從一個細胞（Cell）的訊號涵蓋區域移動至另外一個時，手機與一個新的細胞連結就會被建立，而與舊細胞連結就會被切斷。一般來說，電信營運商會有兩到三個FDD頻帶。此時不同的頻帶就可以用來做為壓縮模式（Compressed Mode）量測之用。

目前3G Macro 網路的Hard Handover流程可以分為底下幾個步驟。

首先，網路端會下量測命令給手機。手機接到命令後會去量測不同細胞的訊號品質並會回報給網路端。網路端收到手機的回報之後，Handover演算法會跟據一些參數如服務品質、系統負載等來決定是否要讓手機Handover到別的細胞上。但是，目前3G標準對於HNB Handover做法尚未有明確的解決方案。

Load Control

Load Control功能模組與Admission Control功能模組在功能上為互補關係。當Admission Control演算法估算不準確時，就有可能會發生超過負載的情況。此時Load Control模組就必須採取行動，及時把系統負載調整回正常範圍。Load Control演算法會隨時偵測目前系統負載狀態及發射功率。當異常狀況發生時，就會啟動降低負載的機制。

這個機制經由一些準則來判斷系統效能的優先次序。為了要提升某些效能這個機制無可必免地要犧牲某些效能來達到目地。舉例來說，提升使用者的傳輸速度可能會降低系統容量。在決定優先次序後，就會經由一些方法如調整TFCS參數、降低資料傳輸速率，以及使手機Handover到另外一個細胞等來進行負載控制。在經由調整以後，Load Control演算法會檢查是否有達到預設目標。若沒有，則會在經由其它方式來做進一步的調整。

Code Management

頻道碼與攪亂碼是被HNB所管理的。攪亂碼在上傳方向是用來分辨不同的手機。頻道碼在上傳方向是用來區分同一隻手機的不同頻道，而在下傳方向是用來區分同一個HNB中的不同手機。

這些碼的作用就像是手機或者是某個頻道的識別碼。因為碼的數目是有限的，所以Code Management演算法必須以有效率的方式來分配這些碼，並且以Code Handover方式來保證有足夠數量的碼可以使用，以防止新的呼叫因為沒有適合的碼可以使用而被拒絕的情況。

Power Control

UMTS標準在功率控制可以分為開迴路控制與閉迴路控制兩大類。開回路功率控制可用在隨機存取程序上（Random Access Procedure），而閉迴路控制又可以分成外部迴路功率控制與內部迴路功率控制兩種。

外部回路功率控制則是跟據資料的服務品質對接收端設定一個目標訊號干擾比。內部回路主要是利用領航訊號（Pilot Signal）來量測所接收到的訊號品質，並將其與目標訊號干擾比做比較，然後再利用TPC來降低或增加發送端的功率，最快速度可以達到1500Hz。如此高的速度就可用來補償通道衰減所造成的效應，讓接收功率維持在一個固定範圍。

在同一個細胞內，若手機的數目越多，則對彼此的干擾是越大的。此時，若把手機的發射功率提高，會使系統的容量降低並且縮短手機通話時間。相反地，假如使發射功率降低，則會在接收端產生過大的位元錯誤率。所以Power Control 演算法必須在系統容量、手機的通訊品質以及通話時間這幾個因子取得最佳平衡點。

RRC協定的功能

RRC全名為Radio Resource Control，在傳統3G系統中，RRC分別位於UE及UTRAN端，主要功能為管理與維護Uu interface上的資料封包收送與程序傳遞。利用點對點的RRC message，UTRAN端的RRC可告知UE端的RRC如何設定、改變或釋放L2(RLC、MAC)和L1(PHY)的協定個體，以達到建立、重設或取消資料傳輸通道的目的，來配合資料封包的傳遞。此外，RRC也利用Radio Bearer(RB3及RB4)提供上層(NAS)在UTRAN及UE之間程序傳遞的服務。

RRC協定主要分成以下幾個功能個體：

繞送功能個體（RFE）

將由上層（NAS）傳遞過來的資訊，轉送到RRC內部負責處理的功能個體，或是由收到的RRC message中，將所夾帶NAS訊息傳遞到上層。

廣播功能個體（BCFE）

在UTRAN端，此功能個體負責處理跟Broadcast相關的服務，如決定系統訊息（SIB）的參數、系統訊息的排程（MIB、SB）等等。在UE端，此功能個體會將所收到的SIB解開，並將其所攜帶的訊息視需求送至RRC其他功能個體或是NAS的功能個體。

傳呼與提示功能個體（PNFE）

在UTRAN端，透過由此功能個體，可傳送傳呼訊息給尚未建立RRC連線的UE或是處於URA-PCH或CELL-PCH狀態的UE，令其依傳呼內容進行必要的程序，如建立RRC連線或是接收更新的系統訊息（SIB）等等。

指定控制功能個體（DCFE)

此功能個體負責針對某一特定UE的所有資訊交換功能。

傳輸模式個體 (TME)

此功能個體負責處理來自不同RRC協定個體的資訊，決定他們需要使用哪一種RLC傳輸模式來做資料傳輸。

RRC協定的程序

在3GPP TS 25.331 RRC協定規格書中，共定義了多個RRC程序及數十道RRC message，以下將依功能將所有程序分成五大類：

RRC Connection Management Procedures

此類程序主要功能為建立或釋放RRC連線，並儘量維持RRC連線的完整性。此外還包含了諸如系統訊息的廣播、針對某特定UE發出傳呼訊息、NAS資訊的傳遞、資訊安全的相關設定及UE能力的取得及更新等功能也都歸屬在此類程序當中來進行。

Radio Bearer Control Procedures

此類程序主要功能為建立、再組態及釋放Radio Bearer。透過設定不同的傳輸格式、傳輸通道、實體通道及RB等等的參數來滿足不同的傳輸需求。

RRC Connection Mobility Procedures

由於UE的位置隨時會改變，因此在連線狀態下，為了確保連線不被中斷及保持良好的連線品質，諸如Cell Update、Active Update、Hard Handover、Inter-RAT Handover等等的程序被設計來滿足這樣的需求，除了上面舉出的幾個程序外，還有好幾個程序也被歸在此類功能範圍內。

Measurement Procedures

為維持良好的連線品質，UE必須做一些量測並回報給UTRAN端作為調整無線通道參數的依據，此類的程序包含了：Measurement Control、Measurement Report及Assistance Data Deliver。

Other Procedures

為了使無線資源運用更有效率，避免不同UE之間的相互干擾，RRC會執行Power Control程序。其他還有PRACH Selection、S-CCPCH Selection、PLMN Type Selection等等程序，分別支援不同的功能。

HNB的RRC和3G的RRC大同小異，除了Handover及PLMN認定方面因還沒有完全定案，故無法確定相關程序是否支援之外，其他屬於3G的RRC功能在HNB上大致上都有實現。當然，因為HNB的環境和Macro不盡相同，故在許多的做法上也會和Macro略有差異。

PDCP協定

在傳統3G系統中，為了提高封包交換的傳輸效率，故增加了PDCP層的通訊協定，其主要功能為將傳送的封包表頭（如RTP、UDP或IP等表頭）資料進行壓縮/解壓縮處理來降低傳輸的資料量，有效提昇傳輸速率。此外，PDCP也提供了無漏失的SRNS Relocation服務（需在RLC-AM模式及in-sequence傳送模式下才可執行），不過由於HNB關於Handover的一些細節目前仍未定案，因此HNB的PDCP目前僅支援封包表頭壓縮功能，SRNS Relocation的部份則需等待Handover的細節更近一步確認之後才能確定是否支援。

RLC協定

RLC的全名為Radio Link Control，在HNB中的RLC協定基本上和傳統3G的RLC協定並無差異，其主要工作是將由上層傳送過來的使用者資料(PDCP)或是控制信號(RRC)，或是由下層(MAC)傳送過來的資料，依據不同的傳輸品質需求，進行切割、傳送、重傳和重組處理之後，再分別送到指定的協定(RRC/PDCP/MAC)。除此之外，RLC也提供了諸如流量控制、封包次序重組、封包加解密、封包錯誤偵測等服務。

RLC提供以下三種封包處理方式，來滿足不同傳輸品質的需求。

Transparent Mode (TM)

在傳送端直接根據封包長度進行切割分封，不做其他處理。在接收端則是將接收到的正確封包直接往上層送，錯誤的則直接丟棄。此模式適用於對即時傳輸要求高的服務，如語音電話。

Unacknowledged Mode (UM)

傳送端除了基本的切割分封之外，還會在每個封包前面加上適當的表頭(header)，使得接收端得以進行封包次序的檢查與錯誤封包的丟棄。除此之外，也提供對傳送資料的加解密功能以確保其安全性。此模式適用於對即時傳輸及封包次序都有需求的服務，如視訊電話。

Acknowledged Mode (AM)

除了UM所提供的切割分封與表頭附加及加解密功能之外，接收端需要確認所有的封包都必須要正確的接收完成，並告知傳送端才算完成資料的遞送。若接收端發現封包遺失則必須通知傳送端做重傳的動作直到封包確定接收到為止。目的為確保資料正確的送達接收端。此模式適用於對資料正確性要求嚴苛的服務，如郵件、FTP等。

MAC協定

MAC的全名為Media Access Control，在HNB中的MAC協定和傳統3G的MAC協定並無差異。MAC的主要功能為提供傳輸資料在邏輯通道及傳輸通道之間的多工/解多工處理，在傳送端，MAC將自RLC邏輯通道傳送過來的封包加上一些表頭之後，再經由適當的傳輸通道轉送到FP。當處於接收端時則反之。下表列出MAC的基本功能與說明：

表一： MAC協定功能說明

FP協定

FP全名為Frame Protocol，原為傳統3G網路中在RNC與RNC（Iur）或Node B（Iub）之間資料傳輸的關鍵角色。FP將由MAC傳來的資料轉換成FP自有的格式，再轉送到Node B送至UE或是其他RNC。

在HNB中，由於RNC與Node B結合成一體，不需使用原本的AAL2及AAL5來傳輸資料，且HNB和HNB之間的溝通方式也沒有定案，因此目前在HNB中的FP不需要支援Iur介面或是與AAL2/AAL5之間的資料交換。另外，FP也支援Node Synchronization及Outer Loop Power Control等機制。

NBAP協定

NBAP全名為Node B Application Part，其所提供的服務如下所列：

Radio link控管

Radio link資源的建立、增加、調校、以及釋放。

基地台控管

Cell的相關參數設定以及對廣播信號(broadcast information)進行排程。

共用通道控管

對RACH和FACH的無線資源進行控管。

量測和監控

控制並且回報實體層量測訊息，例如功率的量測。

錯誤控管

回報實體層提供的相關錯誤訊息。

結語

電信業者利用HNB此項技術，不但可以降低現有戶外大型基地台的負荷、增加覆蓋率、使得系統業者可以提供更佳品質的室內行動資料服務，進而增加用戶對系統業者的滿意度。也因為如此，消費者可進一步地改變使用習慣，多加利用多媒體或加值服務，為大眾帶來更多生活上的便利。

但是，HNB仍然面對許多技術上的挑戰。首先，昂貴的價格會讓一般人對這項新科技望之怯步，如何將Uu界面的Protocol Stack功能在軟體與硬體上做適當地切割與整合，這將會對HNB製造成本以及系統效能有決定性的影響。其次，HNB存在頻率干擾問題。不僅HNB會對基地台產生訊號覆蓋上的死角，而HNB與HNB彼此之間也同樣會產生干擾。在讓頻率有效使用而且不會降低系統容量前提下，如何避免頻率干擾問題也是RRM模組設計上的一大挑戰。當這些技術難題被克服時，HNB這新技術才有機會大放異彩。

<本文作者林映辰、張毓仁 皆任職於資策會網路多媒體研究所>