國 立 交 通 大 學
資訊學院
資訊學程
碩 士 論 文
RUA通訊協定之設計與實作
Design and implementation of RUA
protocol
研 究 生：楊適聰
指導教授：林一平 博士
顏在賢 博士
RUA通訊協定之設計與實作
Design and implementation of RUA protocol
研 究 生：楊適聰
Student：Shin-Tsung Yang
指導教授：林一平 博士
Advisor：Dr. Yi-Bing Lin
顏在賢 博士
Dr. Chai-Hien Gan
國 立 交 通 大 學
資訊學院
資訊學程
碩 士 論 文
A Thesis
Submitted to College of Computer Science National Chiao Tung University
in partial Fulfillment of the Requirements for the Degree of
Master of Science in
Computer Science April 2011
Hsinchu, Taiwan, Republic of China
RUA通訊協定之設計與實作
研究生：楊適聰
指導教授：林一平 博士
顏在賢 博士
國 立 交 通 大 學
資 訊 學 院
資 訊 學 程 碩 士 班
摘要
Femtocell 被視為延伸行動通訊網路覆蓋範圍、提昇系統容量的方法。3GPP 制定整合家用無線基地台 (Home Node B) 與戶外無線基地台 (Node B) 的 Femtocell 網路架構。本論文敘述 Femtocell 網路架構和相關的 Iuh 介面通訊協 定 (如：RANAP, SCTP 等)。在 Femtocell 網路架構中，RANAP User Adpatation (RUA) 提供一個負擔較小的機制來傳輸家用無線基地台與家用無線基地台閘道(HNB-Gateway) 之間的控制功能與 RANAP 訊息。我們並說明 RUA 如何與其他通訊 協定互動。本研究介紹在 Femtocell/HNB 專案中採用訊息佇列設計與實作的 RUA 通訊協定。我們設計的 RUA 經由訊息佇列與一致性的基本流程模型 (unified primitive flow model) 可以在不同的系統與平台上運作。
Design and implementation of RUA protocol
Student：Shin-Tsung Yang
Advisor：Dr. Yi-Bing Lin
Dr. Chai-Hien Gan
Degree Program of Computer Science
National Chiao Tung University
Abstract
Femtocell is proposed extend the mobile network coverage in
environments such as deep building and to enhance the system capacity. 3GPP has proposed Femtocell Network Architecture (FNA) to integrate Home Node B (HNB) and Node B. In this paper, we describe 3GPP FNA and related Iuh interface protocols (e.g., RANAP, SCTP, etc.). Specifically, we will focus on RANAP User Adaptation (RUA) in FNA, which is a lightweight mechanism to transport RANAP messages and control functions between HNBs and HNB-Gateways. We also illustrate how RUA interworks with other FNA protocols. This study describes our design and implement of RUA protocol in a Femtocell/HNB project through Message Queuing (MQ) method. Based on our design, the RUA protocol can work on different operating systems and platforms by the MQ method and the unified primitives.
Acknowledgements
誌
謝
首先誠摯地感謝指導教授林一平博士與顏在賢博士，若沒
有老師的專業建議與細心指導，並無法完成此篇碩士論文。
在林一平博士嚴格的指導中，我學習到了研究的方法，並從
中獲得極大的助益。在顏在賢博士的指導中，讓我獲得論文
研究方向與許多專業知識。另外感謝陳元凱博士、鄭枸澺博
士擔任我的口試委員，並在口試中給與指正與建議，使得論
文能更加完整。
其次，要感謝實驗室的所有同伴們，謝謝你們的陪伴，讓
我的研究生活更加的充實。
最後我也要感謝我的家人與我的朋友們在我研究生活中
給予的鼓勵及支持。
目錄
摘要...iii Abstract ... iv Acknowledgements... v 一. 簡介 ... 1 1.1. Femtocell 網路架構 ... 1 1.2. Femtocell 網路通訊協定堆疊 ... 2 1.3. RUA 通訊協定... 3 1.4. 章節提要... 5 二. RUA 通訊協定軟體之設計 ... 6 2.1. 基本程序 (Elementary Procedures) 與訊息類型 ... 6 2.1.1. 連線建立 (Connect) 程序與訊息類型... 6 2.1.2. 直接傳輸 (Direct Transfer) 程序與訊息類型 ... 6 2.1.3. 連線關閉 (Disconnect) 程序與訊息類型 ... 7 2.1.4. 無連線傳輸 (Connectionless Transfer) 程序與訊息類型 ... 7 2.1.5. 錯誤指示 (Error Indication) 程序與訊息類型 ... 8 2.2. RUA 通訊協定之功能 (Functionality)... 8 2.2.1. RUA-SAP 的基本訊息 (Primitives) ... 10 1. RUA REQ ... 10 2. RUA IND ... 11 2.2.2. SCTP-SAP 的基本訊息 (Primitives)... 12 三. RUA 通訊協定軟體之實作 ... 13 3.1. HNB 軟體系統架構 ... 13 3.2. 訊息佇列應用程式與流程... 13 3.3. RUA 通訊協定功能模組與流程 ... 15四. RUA 與 SCCP/M3UA 基本訊息 (primitives) 差異 ... 19
4.1. 連線建立基本訊息差異比較... 20 4.2. 直接傳輸基本訊息差異比較... 23 4.3. 連線關閉基本訊息差異比較... 24 4.4. 無連線傳輸基本訊息差異比較 ... 25 4.5. 資料傳輸基本訊息差異比較... 26 五. 效能評估 ... 29 5.1. 基本訊息承載不同 RANAP 訊息類型之效能評估 ... 30 5.2. 基本訊息承載不同大小訊息之效能評估... 32 5.3. 基本訊息在不同傳送頻率下之效能評估... 34 5.3.1. 處理延遲時間之評估... 34 5.3.2. 訊息佇列 (Queue) 之評估 ... 36
六. 結論 ... 39 參考文獻 ... 40
圖目錄
圖 1.1 FEMTOCELL 通訊網路架構 ... 1 圖 1.2 FEMTOCELL 網路通訊協定堆疊圖 ... 3 圖 1.3 IU 介面通訊協定堆疊與 IUH 介面通訊協定堆疊 ... 4 圖 2.1 建立連線程序 ... 6 圖 2.2 直接傳輸程序 ... 7 圖 2.3 關閉連線程序 ... 7 圖 2.4 無連線傳輸程序 ... 8 圖 2.5 錯誤指示程序 ... 8 圖 2.6 HNB 端 RUA 通訊協定架構 ... 9 圖 2.7 基本流程模型 ... 10 圖 3.1 HNB 系統架構圖 ... 13 圖 3.2 CSPL 訊息佇列應用程式流程... 15圖 3.3 RUA REQ 基本訊息模型處理流程與 RUA 功能模組 ... 16
圖 3.4 SCTP IND 基本訊息模型處理流程與 RUA 功能模組 ... 18
圖 4.1 RUA 與 SCCP/M3UA 基本訊息模型對照關係圖 ... 19
圖 5.1 訊息處理延遲時間關係圖 ... 29
圖 5.2 RUA 與 SCCP/M3UA 不同傳送頻率所需處理延遲時間比較 ... 35
表目錄
表 2.1 RUA 基本程序與訊息類型對照表 ... 6 表 4.1 RUA 與 SCCP/M3UA 基本訊息對照表 ... 20 表 4.2 RUA 與 SCCP/M3UA 連線建立基本訊息內容對照表 ... 21 表 4.3 RUA 與 SCCP/M3UA 直接傳輸基本訊息內容對照表 ... 23 表 4.4 RUA 與 SCCP/M3UA 連線關閉基本訊息內容對照表 ... 24 表 4.5 RUA 與 SCCP/M3UA 無連線傳輸基本訊息內容對照表 ... 26表 4.6 RUA 與 SCCP/M3UA 的 SCTP REQ/IND 資料傳輸基本訊息內容對照表 ... 27
表 5.1 測量延遲時間所承載的 RANAP 訊息類型... 30
表 5.2 REQ 基本訊息模型處理不同 RANAP 訊息之平均處理延遲時間比較 ... 31
表 5.3 IND 基本訊息模型處理不同 RANAP 訊息之平均處理延遲時間比較 ... 32
表 5.4 REQ 基本訊息模型處理不同大小訊息之平均處理延遲時間比較 ... 33
一. 簡介
隨時隨地皆可進行高品質高效率的語音與數據通訊是行動通訊服務發展趨 勢。根據ABI Research研究，70%的行動通訊行為發生在室內 [1]，然而戶外無 線基地台 (Node B) 對室內覆蓋率卻往往不盡人意。若以更密集架設戶外無線基 地台或提高基地台功率來改善覆蓋範圍，容易產生訊號干擾，降低通訊品質，且 網路設備佈建成本較高。另一個較可行的方案是採用家用無線基地台 (Home Node B - HNB) 放置於室內，補強現有無線基地台不足的部份。Femtocell網路可以提 供高品質的語音訊號以及高速的數據服務，大小如同WiFi基地台一般，建置成本 低，可代替固接式電話，又具有行動接取的特性，讓使用者使用單一終端設備即 可進行語音和數據通訊，且傳輸功率低，涵蓋範圍小，不易造成訊號干擾，有利 提高無線頻帶使用效率。因此不僅可吸引使用者經由行動網路取得網路服務，提 升平均使用者貢獻度 (Average Revenue Per User - RPU)，也促進固接式網路 與行動通訊網路整合 (Fixed-Mobile Convergence - FMC) 發展 [2][3][4][5]。1.1. Femtocell 網路架構
Femtocell 通訊網路架構如圖 1.1 所示，HNB (圖 1.1 (1)) 設置於使用者 家中，經由 IP 網路 (圖 1.1 (2)) 連接行動通訊網路 (圖 1.1 (3))。使用者不 需更換終端設備就可以獲得高效能的行動語音與數據接取服務。 圖 1.1 Femtocell 通訊網路架構 Femtocell網路將HNB佈建於使用者家中，用來補強無線基地台 [6] 室內訊 號涵蓋率不足的問題 [7]。雖然微波功率較弱、涵蓋的服務範圍也較小，卻可在有限範圍內提供更高傳輸速率的高品質行動通訊服務。3GPP亦制定整合HNB與 Node B的Femtocell網路架構 [8]。在Femtocell網路架構中，HNB同時具有Node B 與部份RNC的能力 [9]。行動通訊核心網路 (以下簡稱核心網路; 圖 1.1 (7)) 與 HNB之間則引進家用無線基地台閘道 (HNB-GW；圖 1.1 (4)) 來負責網路安全、 通信協定轉換、HNB的管理與連接控制等功能。3GPP並新制定Iuh介面 (圖 1.1 (5))，支援HNB與HNB-GW之間的連結與管控。此外HNB-GW以既有Iu介面 (圖 1.1 (6)) [10] 與核心網路連結，直接接受與回報核心網路的控管訊息，提高 Femtocell網路維運的效率。至於使用者終端設備 (UE) 與HNB間則以既有Uu介面 (圖 1.1 (8)) 連結，免除更新UE的需求。
1.2. Femtocell 網路通訊協定堆疊
Femtocell 網路的通訊協定堆疊就如圖 1.2 所示。方案中的 Uu 介面 (圖 1.2 (1)) [11] 與 Iu 介面 (圖 1.2 (3)) [12] 承襲 UMTS [13] 的定義，因此不多加 贅述。HNB 與 HNB-GW 之間新制定的 Iuh 介面 (圖 1.2 (2))，包含以下的通訊協 定： Radio Access Network Application Part (RANAP；圖 1.2 (a)) [14]，其 主要功能包括解析每個 UE 送來的移動管理資訊並提供專屬服務、轉送帶有 UE 通訊內容的訊息、請求與管理各種無線通訊資源以及執行 UE 切換服務網 路 (Serving Radio Network Subsystem) 時的重新定位。在 Iuh 介面中用 來傳輸 HNB 與 HNB-GW 間的控制訊息。
RANAP User Adaption (RUA；圖 1.2 (b)) [15]，其主要功能為提供系統一 個負擔較輕的方法，讓系統可以在 Iuh 介面使用 SCTP 傳送 RANAP 訊息與相 關錯誤資訊處理。必需經由 RUA，UE 才能使用核心網路所提供的通訊連線與 數據服務，在 Iuh 介面中扮演著極其關鍵的角色，因此本論文將在下一節 (詳 見一.1.3) 對其做更深入的描述。
Stream Control Transmission Protocol (SCTP；圖 1.2 (c)) [16]，其主 要功能為提供 Iuh 介面上層通訊協定一個穩定可靠的傳輸。IETF 根據信令傳 輸特點所制定的 SCTP 協定，具有流量控制與重送機制，並支援多重串流與 多點對多點的傳輸，亦能減少因服務拒絕攻擊 (denial of service attack) 所造成資源耗竭。
HNB 搜尋適合的 HNB-GW、註冊 HNB 資訊到核心網路、提供 UE 註冊以及回傳 本身的錯誤資訊給 HNB-GW。HNB-GW 與核心網路經由 HNBAP 所提供的資訊與 服務可以進行相關認證，執行網路接取管理。
Internet Protocol (IP；圖 1.2 (e)) [18]，其主要功能為提供網際網路 資料封包傳送的基本服務，包括封包格式及定址。根據封包表頭 (header) 中的目的地址，決定傳送路徑，將數據資料繞送 (routing) 到目的地址。
圖 1.2 Femtocell 網路通訊協定堆疊圖
1.3. RUA 通訊協定
Iuh 介面 (圖 1.3 (b)) 在制定時思考的重點，包括建置成本、運作效能、 網路安全等。既有 Iu 介面 (圖 1.3 (a)) 中的 Signaling Connection Control Part (SCCP; (圖 1.3 (2)) [19]與 MTP3 User Adaptation Layer (M3UA; (圖 1.3 (3)) [20]，會傳輸與處理許多非 HNB 與 HNB-GW 所必需的 SS7 信令 (如: 通用標 碼轉換) [21]，造成網路與系統資源的浪費 [22]，且用來映射 (mapping) SCTP (圖 1.3 (4))連線與繞送通訊訊息的點碼 (Point Code) 長度僅 14 位元，亦不 足應付 HNB 大量佈署的需求 [23]。為此，3GPP 制定 RUA 通訊協定 (圖 1.3 (1))， 提供一個對系統負擔較輕的機制，傳送與管理 HNB 與 HNB-GW 間的 RANAP (圖 1.3 (5))訊息，亦改用 UE 內容定義 (Context Identifiers) 繞送通訊訊息，其長度 為 24 位元，因此能解決點碼不足的問題。RUA 的制定適度簡化既有 Iu 介面的通 訊協定堆疊，降低系統開發成本，也減少通訊協定的負擔 (overhead) 提高 Femtocell 的運作效率 [24]。此外，3GPP 亦制定 HNBAP (圖 1.3 (6)) 來達成 Iuh 介面中認證 HNB 與 UE 的需求，因非本論文重點，故不多加撰述。
圖 1.3 Iu 介面通訊協定堆疊與 Iuh 介面通訊協定堆疊 RUA 的功能包含以下幾點： 提供系統可以在 Iuh 介面 (HNB 與 HNB-GW 間) 使用 SCTP 傳送 RANAP 訊息 的方法。 支援特定 UE 邏輯上連接的鏈結與定義，例如：HNB-GW 在 UE 註冊期間，對 每一個 UE 給予一個唯一的 UE 內容定義，經由 UE 內容定義，可以定義決 定不同的 RANAP 訊息屬於那些特定 UE 所使用。 支援在核心網路網域裡的核心網路節點間，建立訊息連接的繞送方法。 提供特定 UE 建立連線的原因說明，例如：建立緊急通訊．．等。 提供從 HNB 到核心網路間，一個不需要對己經封裝好的 RANAP 訊息進行解 碼就可以傳送 RANAP 訊息的方法。 提供錯誤回報處理機制。 為達成上述功能，3GPP 制定 5 個 RUA 基本程序，包括： 連線建立 (Connect) 程序：增加必要連接傳輸資訊，讓 HNB-GW 在處理 RANAP 訊息傳送不需檢查內容與建立新的訊息傳送連結，即可直接對應 Iu 介面中的特定 UE 連線。
直接傳送 (Direct Transfer) 程序：傳送 Iuh 介面中特定 UE 的 RANAP 訊 息。
連接關閉 (Disconnect) 程序：關閉在 Iuh 介面中的特定 UE 連線。 無連線傳輸 (Connectionless Transfer) 程序：傳送非特定 UE 的 RANAP
訊息。
錯誤指示 (Error Indication) 程序：接收訊息發生錯誤時的回傳處理。 由於 RUA 在 Iuh 介面中負責通訊建立與傳輸等功能，能否順利運作對系統具 有舉足輕重的影響，所以後續本論文將根據 RUA 的功能，設計基本流程模型訊息
並實作該通訊協定。
1.4. 章節提要
本論文共分六個章節，描述如何設計與實作 Iuh 介面中的 RUA 通訊協定。第 一章為 RUA 通訊協定簡介，包含 Femtocell 通訊網路架構與通訊協定堆疊。第二 章介紹 RUA 的基本程序與功能，包含服務接取點 (Service Access Point - SAP) 與基本流程模型。第三章介紹本論文實作的 RUA 軟體架構，包含系統架構與功能 模組。第四章為 RUA 與 SCCP/M3UA 的基本訊息模型差異比較。第五章則針對 RUA 進行效能評估。第六章為結論。
二. RUA 通訊協定軟體之設計
本章描述 RUA 通訊協定的基本程序與訊息類型，並依據 RUA 通訊協定功能， 設計我們實作 HNB 或 HNB-GW 時所需使用的基本流程模型與基本訊息。2.1. 基本程序 (Elementary Procedures) 與訊息類型
承第一章第 3 節所述，RUA 共有 5 個基本程序。而各程序分別使用不同的訊 息類型來傳輸資訊，表 2.1 列出了各基本程序與其所使用的訊息類型。本節後續 小節將詳細說明各程序的使用時機。 表 2.1 RUA 基本程序與訊息類型對照表 基本程序 訊息類型 連線建立 (Connect) CONNECT直接傳輸 (Direct Transfer) DIRECT TRANSFER 連線關閉 (Disconnect) DISCONNECT
無連線傳輸 (Connectionless Transfer) CONNECTIONLESS TRANSFER 錯誤指示 (Error Indication) ERROR INDICATION
2.1.1. 連線建立 (Connect) 程序與訊息類型
當 UE 要在 HNB 與 HNB-GW 間建立新連線時，須使用連線建立程序 (圖 2.1) 來 建立連線。本程序承載從 HNB 傳送給 HNB-GW 的 RANAP INITIAL UE MESSAGE，並 交換連線建立所需的資訊，由於僅可由 HNB 發起建立連線，所以本程序僅可由 HNB 傳送到 HNB-GW。本程序使用 CONNECT 訊息來傳輸資料。 圖 2.1 建立連線程序
2.1.2. 直接傳輸 (Direct Transfer) 程序與訊息類型
若 UE 己具備與核心網路的連線，則與該 UE 相關的所有資料傳輸，均會使用 直接傳輸程序 (圖 2.2)。由於資料傳輸可經由 HNB 或 HNB-GW 發起，所以本程序可由 HNB 傳送給 HNB-GW (圖 2.2 (a))，亦可由 HNB-GW 傳送給 HNB (圖 2.2 (b))。 本程序使用 DIRECT TRANSFER 訊息來傳輸資料。 圖 2.2 直接傳輸程序
2.1.3. 連線關閉 (Disconnect) 程序與訊息類型
HNB 與 HNB-GW 間經由連線建立程序所建立的 UE 連線，可經由連線關閉（圖 2.3）程序來終止。HNB 或 HNB-GW 均可依照系統運作情形，終止目前 UE 使用中的 連線，所以本程序可由 HNB 端發起傳送給 HNB-GW (圖 2.3 (a))，亦可由 HNB-GW 端發起傳送給 HNB (圖 2.3 (b))。本程序使用 DISCONNECT 訊息來傳輸資料。 圖 2.3 關閉連線程序2.1.4. 無連線傳輸 (Connectionless Transfer) 程序與訊
息類型
當 HNB 與 HNB-GW 間所需傳訊的資料非屬於特定 UE 連線時，則需使用無連線 傳輸程序(圖 2.4)。此程序主要用於傳輸廣播 (Broadcast) 與尋呼 (Paging) 等非屬特定連線的訊息。無連線傳輸可經由 HNB 或 HNB-GW 發起，所以本程序可 由 HNB 傳送給 HNB-GW (圖 2.4 (a))，亦可由 HNB-GW 傳送給 HNB (圖 2.4 (b))。本程序使用 CONNECTIONLESS TRANSFER 訊息來傳輸資料。 圖 2.4 無連線傳輸程序
2.1.5. 錯誤指示 (Error Indication) 程序與訊息類型
HNB 與 HNB-GW 若發生系統錯誤時，須經由錯誤指示程序 (圖 2.5) 通知對 方，避免因不知對方發生錯誤仍不斷嘗試，而造成的網路癱瘓或資源浪費等問 題。由於 HNB 與 HNB-GW 均可能發生錯誤，所以本程序為雙向傳輸，可由 HNB 端 發起傳送給 HNB-GW (圖 2.5 (a))，亦可由 HNB-GW 端發起傳送給 HNB (圖 2.5 (b))。本程序使用 ERROR INDICATION 訊息來傳輸資料。 圖 2.5 錯誤指示程序2.2. RUA 通訊協定之功能 (Functionality)
本節描述 RUA 通訊協定的功能並進行解析。承第一章第 4 節所述，RUA 的功 能分為二大類，分別為： (1) 經由 SCTP 進行傳送與接收 RANAP 訊息，完成通訊 相關資訊的傳遞。 (2) 系統錯誤資訊回報與處理。由其功能可知，HNB 的 RUA 與 其他通訊協定間的服務接取點共有二個，分別是 RUA-SAP (圖 2.6 (1)) 與 SCTP-SAP (圖 2.6 (2))。RUA-SAP 負責處理 RUA (圖 2.6 (b)) 與 RANAP (圖 2.6(a)) 之間的基本訊息，SCTP-SAP 負責處理 RUA 與 SCTP (圖 2.6 (c)) 之間的基 本訊息。 圖 2.6 HNB 端 RUA 通訊協定架構 RUA 的基本流程模型 [25]，如同圖 2.7 所示。在我們設計的模型中包含了 二種角色，分別為：HNB 端 (圖 2.7 (a))與 HNB-GW 端 (圖 2.7 (b))，但是不論 RUA 身處於何種角色之中，其功能僅有部份差異，這方面會在基本流程模型中的 基本訊息說明相關差異。因此，我們的設計除特定訊息外，均可在二種角色中使 用。基本流程模型中所使用的基本訊息共包含四種型式的設計，分別為：RUA Request (RUA REQ；圖 2.7 (1))、RUA Indicator (RUA IND；圖 2.7 (2))、SCTP Request (SCTP REQ；圖 2.7 (3))、SCTP Indicator (SCTP IND；圖 2.7 (4))， 其中 RUA-SAP 使用 RUA REQ 與 RUA IND 基本訊息模型來傳遞資料，SCTP-SAP 使用 SCTP REQ 與 SCTP IND 基本訊息模型來傳遞資料。經由以上四種基本訊息模型的 設計，RUA 的接口即具備統一格式，我們可以單獨開發 RUA 軟體模組。
圖 2.7 基本流程模型
2.2.1. RUA-SAP 的基本訊息 (Primitives)
RUA-SAP 是 RUA 與 RANAP 之間的服務接取點，用來傳輸 RUA 與 RANAP 之間的 訊息。其中 RUA REQ 是 RANAP 想要經由 RUA 傳送特定訊息時，所使用的基本訊息 模型，而 RUA IND 則是 RUA 要傳送給 RANAP 時所使用的基本訊息模型。
1.
RUA REQ
RUA REQ 為 RUA 承接 RANAP 資料的基本訊息模型，並依據本章第 1 節所描述 的基本程序與訊息類型，本模型應包含以下的基本訊息： RUA-CONNECT-REQ：此訊息使用於連線建立基本程序，用來傳送 RANAP 通訊 初始化訊息。當特定的 UE 想要建立通訊時，須使用此訊息來傳送第一個 RANAP 訊息，其內容須包含 UE 內容定義與 HNB ID。RUA 可經由本訊息提供系統建 立 UE 連線資訊的資料，讓系統進行後續的連線管理。由於 UE 連線資訊的建 立僅可由 HNB 傳送給 HNB-GW 所以本訊息僅在 HNB 端使用。 RUA-DIRECT-TRANSFER-REQ：此訊息使用於直接傳輸基本程序，是用來承載 特定 UE 在通訊建立或進行中所使用的其他訊息，如：通話協議資訊、系統 加解密資訊等，其內容須包含 UE 內容定義與 HNB ID。RUA 可經由本訊息提 供的資訊找出特定 UE 所使用的連線。本訊息為雙向傳輸，HNB 端或 HNB-GW 端均可以發送本訊息，也都有本訊息相對應的處理流程。 RUA-DISCONNECT-REQ：此訊息使用於連線關閉基本程序，是用來傳送 RANAP 通訊結束訊息，傳送特定 UE 的最後訊息，其內容須包含 UE 內容定義與 HNB ID。RUA 可經由本訊息提供足夠的資訊，讓系統結束對特定 UE 的連線資料維
護。由於終止通話可以由 UE 或是核心系統發起，所以本訊息為雙向傳輸， HNB 端或 HNB-GW 端都有本訊息相對應的處理流程。 RUA-CONNECTIONLESS-TRANSFER-REQ： 此訊息使用於無連線傳輸基本程序， 是用來傳送非特定 UE 的通訊訊息，例如核心系統呼叫 (Paging) UE，或是 多媒體廣播多播服務 (MBMS) 的註冊訊息等。本訊息亦為雙向傳輸，HNB 端 或 HNB-GW 端都可以傳送本訊息。 RUA-ERROR-INDICATION-REQ：此訊息使用於錯誤指示基本程序，是用來承載 系統運作時發生錯誤的相關資訊，其內容應包括 HNB ID 與相關錯誤資料。 透過此訊息的傳輸，不管 HNB 端或是 HNB-GW 端都可以明確判斷錯誤發生的 情況與原因，透過這些資訊所指明的狀況，盡快做適當處理，讓系統恢復正 常運作。
2.
RUA IND
RUA IND 為 RUA 傳送資料給 RANAP 的基本訊息模型，並依據本章第 1 節所描 述的基本程序與訊息類型，本模型應包含以下的基本訊息： RUA-CONNECT-IND：此訊息使用於連線建立基本程序，是用來傳送通訊初始 化訊息，僅在 HNB-GW 端使用。當特定的 UE 想要建立通訊時，經由 RUA 傳送 給 RANAP 的第一個訊息，其內容包含 UE 內容定義與 HNB ID。RUA 可經由本 訊息提供系統足夠資訊建立 UE 連線資訊的資料，進行後續的連線管理。由 於 UE 連線資訊的建立僅可由 HNB 傳送給 HNB-GW 所以本訊息僅在 HNB-GW 端 使用。 RUA-DIRECT-TRANSFER-IND：本訊息使用於直接傳輸基本程序，與 RUA-DIRECT-TRANSFER-REQ 承載的資訊相同，但使用時機不同，當 RUA 收到 特定 UE 的通訊訊息後應使用本訊息傳遞給 RANAP，其內容須包含 UE 內容定 義與 HNB ID。本訊息為雙向傳輸，HNB 端或 HNB-GW 端都有本訊息相對應的 處理流程。 RUA-DISCONNECT-IND：此訊息使用於連線關閉基本程序，是 RUA 用來傳送特 定 UE 的最後訊息，通知 RANAP 通訊結束，其內容須包含 UE 內容定義與 HNB ID。系統可經由本訊息所提供的 UE 內容定義，結束對特定 UE 連線資料的維 護。由於終止通話可以由 UE 或是核心系統發起，所以本訊息為雙向傳輸， HNB 端或 HNB-GW 端均會產生本訊息。 RUA-CONNECTIONLESS-TRANSFER-IND：此訊息使用於無連線傳輸基本程序，
是用來傳送非特定 UE 的通訊訊息，例如核心系統呼叫 (paging) UE，或是 多媒體廣播多播服務 (MBMS) 的註冊訊息等。本訊息亦為雙向傳輸，HNB 端 或 HNB-GW 端都可以傳送本訊息。 RUA-ERROR-IND：此訊息使用於錯誤指示基本程序，用來傳送 RUA 的錯誤訊 息或對口端點回報的錯誤訊息，其內容應包括 HNB ID 與相關錯誤資料。系 統可經由本訊息的傳送對產生錯誤的部份做相關維護處理，並透過這些資訊 所指明的狀況，盡快做適當的處理，讓系統恢復正常運作。本訊息為雙向傳 輸，HNB 端或 HNB-GW 端都會產生本訊息。
2.2.2. SCTP-SAP 的基本訊息 (Primitives)
SCTP-SAP 是 RUA 與 SCTP 之間的服務接取點，用來傳輸 SCTP 與 RUA 之間的訊 息。其中 SCTP REQ 是 RUA 想要經由 SCTP 傳送訊息時，所使用的基本訊息模型， 而 SCTP IND 則是 SCTP 傳送訊息給 RUA 時所使用的基本訊息模型。
SCTP REQ 為 RUA 將編碼好的資料傳送給 SCTP 時所使用的基本訊息模型，包 含 SCTP-RUA- REQ 基本訊息。SCTP-RUA- REQ 基本訊息是用來傳送各種處理完成 的 RUA REQ 的基本訊息，應包含 SCTP 的連接訊息與要傳送的訊息，由於 SCTP 僅 負責建立與結束連線，並不負責維護 UE 內容定義與連線資訊的對應關係，所以 RUA 必需使用 HNB ID 查詢系統所維護的連線資料後，提供相關連線資料給 SCTP。 本訊息為雙向傳輸，HNB 端或 HNB-GW 端都會建立與使用本訊息，並都有相對應的 處理。 SCTP INQ 為 SCTP 接收對口端點傳送過來的編碼資料或資訊傳送給 RUA 所使 用的基本訊息模型，包含以下 2 種基本訊息：
SCTP-RUA-IND：此訊息傳送各種內含 RUA IND 基本訊息的資料，包含 SCTP 連線資訊與收到的訊息內容，RUA 收到本訊息後，進行解碼並利用 SCTP 所提 供連線資訊查詢相對應的 HNB ID，讓 RUA 提供足夠的資訊給 RANAP 處理相關 訊息。本訊息為雙向傳輸，HNB 端或 HNB-GW 端都會建立與使用本訊息。 SCTP-RUA-ERROR-IND：此訊息用來告知 SCTP 連線錯誤，訊息內包含連線傳
輸資訊。經由本訊息，RUA 可以提供系統目前的連線資訊，讓系統可以維護 與該連線相關的 UE 內容定義與或 HNB ID 資訊。本訊息為雙向傳輸，HNB 端 或 HNB-GW 端都會建立與使用本訊息。
三. RUA 通訊協定軟體之實作
本章描述我們實作的 HNB 端 RUA 通訊協定軟體。除了介紹我們開發的軟體系 統架構、使用的訊息佇列和訊息佇列運作流程外，最後並會說明我們實作的 RUA 中包含那些功能模組與功能模組的運作流程。3.1. HNB 軟體系統架構
HNB 的運作，需要無線通訊協定存取模組 (圖 3.1 (1))、RANAP 通訊協定模 組 (圖 3.1 (2))、RUA 通訊協定模組 (圖 3.1 (3))、HNBAP 通訊協定模組 (圖 3.1 (4))、SCTP 通訊協定模組 (圖 3.1 (5)) 和控制系統運作的控制器模組 (圖 3.1 (6))，才能完成整個系統的運作。在作業系統方面，考量到將來執行系統的嵌入 式系統 (Embedded System) 平台，我們採用 Linux 作為我們開發時的作業系統， 減少後續移植系統的困難度。在系統運作方面，考量各通訊協定模組化與系統整 合的需求，我們使用訊息佇列 (Message Queue；圖 3.1 (7)) [26] 的方式來開 發 HNB 軟體。所有的模組將要傳送給其他模組的流程模型訊息，先傳送到訊息佇 列中，然後訊息佇列依照排程與優先順序，逐一進行分發處理，依序通知各模組 完成工作。採用此方式，當某一模組發生錯誤時，可以判別發生錯誤的模組，對 該模組進行修正，減少系統整合的困難度。 圖 3.1 HNB 系統架構圖3.2. 訊息佇列應用程式與流程
訊息佇列是目前一般作業系統 (如：windows, linux) 都有提供的功能。考 量 HUGHES 公司在電信軟體方面具有一定的市佔率，我們採用該公司的 CommonStack Porting Library (CSPL；圖 3.2 (7)) 來作為我們訊息佇列的運作平台。 CSPL 使用 C 語言，並定義數個巨集 (macros) 與函數 (functions)，也規範傳送 訊息時所使用的資料格式，只要符合其格式，不論是否使用 CSPL 所提供的巨集 與函數，都可經由 CSPL 傳送流程模型的基本訊息。為了縮短開發時程，我們開 發的程式與 CSPL 一起編譯。CSPL 的訊息佇列應用程式流程 (圖 3.2) 如下： 步驟 1： 開始執行系統，登錄所有要經由 CSPL 訊息佇列傳送訊息的模組。 步驟 2-3： 進入無限迴圈等待外部應用程式的訊息觸發系統執行。 步驟 4： 接收由外部應用程式送來的訊息，存放訊息到 CSPL 優先佇列中。 步驟 5-7： 檢查目前 CSPL 優先佇列中是否有任何待傳送的訊息，若有需要傳送 的訊息，則取出排序優先的訊息，若無則回到步驟 2-3 無限迴圈。 步驟 8： 分配訊息至對應的模組執行。 步驟 9： 執行模組內的訊息處理程序。 步驟 10： 執行結束，判斷是否有訊息要傳送至其他模組。 步驟 11： 判斷訊息種類，傳送給內部模組的訊息則執行步驟 13，傳送給外部 應用程式的訊息則執行步驟 14。 步驟 12： 回到步驟 5-7，檢查是否還有訊息需要傳送。 步驟 13： 存放訊息到 CSPL 優先佇列中。 步驟 14： 傳送訊息到外部應用程式。 步驟 15-16： 到步驟 5-7，檢查是否還有訊息需要傳送。
圖 3.2 CSPL 訊息佇列應用程式流程
3.3. RUA 通訊協定功能模組與流程
為減少系統負擔，提高系統整體運作效率，RUA 除提供必要的連線資訊、UE 內容定義外，不應有過多的運算處理，我們設計與實作的功能模組也依循此一原 則。承第三章第 1 節所述，RUA (圖 3.3 (Ⅱ)) 是經由訊息佇列來觸發相關執行 程序，考量到將來移植到不同作業系統的彈性，我們將訊息處理的功能模組化。 在我們實作的系統中，與 RUA 互相傳送基本訊息的模組為 RANAP (圖 3.3 (Ⅰ)) 和 SCTP (圖 3.3 (Ⅲ))，依據不同的基本流程模型與基本訊息，RUA 進行不同的處 理流程。各流程內的執行步驟分別說明如下： (1) RUA 接收 RANAP 的訊息處理流程 (圖 3.3) 步驟如下： 步驟 1 ： 接收經由訊息佇列傳送的 RUA REQ 基本訊息模型並由接收 RANAP 訊息模組 (圖 3.3 (A)) 取出訊息資料。 步驟 2 ： 取出訊息資料後執行參數資料驗證模組 (圖 3.3 (B)) 進行驗 證。 步驟 3.a： 驗證通過，執行 SCTP 連線查詢模組 (圖 3.3 (C))，查詢該筆 訊息資料所用的 SCTP 連線資訊。步驟 4.a： 查詢 SCTP 的連線資訊成功，執行進行編碼處理模組 (圖 3.3 (D))，模組中會使用 OSS ASN.1 [27][28][29] 來對要傳送的 RUA 訊息內容做 ANS.1 PER [30] 格式的編碼。
步驟 4.b： 查詢 SCTP 連線資訊失敗，執行 RANAP 訊息錯誤處理模組 (圖 3.3 (F))。
步驟 5.a： ANS.1 PER 格式編碼成功，執行 SCTP 訊息傳送模組 (圖 3.3 (E))。
步驟 5.b： ANS.1 PER 格式編碼失敗，執行 RANAP 訊息錯誤處理模組 (圖 3.3 (F))。 步驟 6 ： 轉換訊息資料成為 SCTP REQ 基本訊息模型的資料結構，並填入 SCTP 模組的相關資訊，傳送給訊息佇列。 步驟 7 ： 判斷錯誤資訊，並將相關錯誤資訊填入錯誤訊息的資料結構傳 送給 RANAP 訊息傳送模組 (圖 3.3 (G))。 步驟 8 ： 轉換訊息資料成為 RUA IND 基本訊息模型的資料結構，並填入 RANAP 模組的相關資訊，傳送給訊息佇列。
圖 3.3 RUA REQ 基本訊息模型處理流程與 RUA 功能模組 (2) RUA 接收 SCTP 的訊息處理流程訊息處理流程 (圖 3.4) 步驟如下：
步驟 1 ： 接收經由訊息佇列傳送的 SCTP IND 基本訊息模型並由接收 SCTP 訊息資料模組 (圖 3.4 (A)) 取出訊息資料。
證。 步驟 3.a： 驗證通過，執行 HNB 序號查詢模組 (圖 3.4 (C))，查詢該筆訊 息資料所用的 HNB 序號資訊。 步驟 3.b： 驗證未通過，執行 SCTP 訊息錯誤處理模組 (圖 3.4 (F))。 步驟 3.c： 驗證通過，並判別該筆訊息資料為 SCTP 連線失敗指示，則執行 傳送錯誤回報模組 (圖 3.4 (H))。 步驟 4.a： 查詢 HNB 序號資訊成功，執行進行解碼處理模組 (圖 3.4 (D))，模組中會使用 OSS ASN.1 來對 RUA 訊息內容進行 ANS.1 PER 格式的解碼。
步驟 4.b： 查詢 HNB 序號資訊失敗，執行 SCTP 訊息錯誤處理模組 (圖 3.4 (F))。
步驟 5.a： ANS.1 PER 格式編碼成功，執行 RANAP 訊息傳送模組 (圖 3.4 (E))。 步驟 5.b： ANS.1 PER 格式編碼失敗，執行 SCTP 訊息錯誤處理模組 (圖 3.4 (F))。 步驟 6 ： 轉換訊息資料成為 RUA IND 基本訊息模型的資料結構，並填入 RANAP 模組的相關資訊，傳送給訊息佇列。 步驟 7 ： 判斷錯誤資訊，並將相關錯誤資訊填入錯誤訊息的資料結構傳 送給 SCTP 訊息傳送模組 (圖 3.4 (G))。 步驟 8 ： 轉換訊息資料成為 SCTP REQ 基本訊息模型的資料結構，並填入 SCTP 模組的相關資訊，傳送給訊息佇列。 步驟 9 ： 解讀連線失敗指示並填入錯誤訊息的資料傳送給 RANAP 訊息傳 送模組 (圖 3.4 (E))。
圖 3.4 SCTP IND 基本訊息模型處理流程與 RUA 功能模組
如前文所述，基於我們設計的基本流程模型與訊息處理功能模組，RUA 可以 輕易地移植到不同的系統。當改變 RUA 使用的系統時，我們只需修改與訊息佇列 相關的 SCTP 與 RANAP 訊息的傳送功能模組 (圖 3.4 (E) 與 (G)) 與接收功能模 組 (圖 3.3 (A) 與圖 3.4 (A)) 即可。
四. RUA 與 SCCP/M3UA 基本訊息 (primitives) 差異
本章描述我們實作的 RUA 和工研院的 SCCP/M3UA 在處理不同程序的差異。圖 4.1 為 RUA 與 SCCP/M3UA 在處理訊息時所使用的基本訊息模型。RUA 與 RANAP 介 接的基本訊息模型為 RUA REQ/IND (圖 4.1 (1) 與 (2))，與 SCTP 介接的基本模 型為 SCTP REQ/IND (圖 4.1 (3) 與 (4))。SCCP/M3UA 與 RANAP 介接的基本訊息 模型為 SCCP REQ/IND (圖 4.1 (5) 與 (6))，與 SCTP 介接的基本模型為 SCTP REQ/IND (圖 4.1 (7) 與 (8))。
圖 4.1 RUA 與 SCCP/M3UA 基本訊息模型對照關係圖
依照不同的訊息模型 (圖 4.1) 與訊息類型 (表 2.1)，我們將 RUA 與 SCCP/M3UA 所使用的基本訊息對照列出如表 4.1 所示。
表 4.1 RUA 與 SCCP/M3UA 基本訊息對照表
訊息模型 訊息類型
RUA REQ/IND (RUA) SCCP REQ/IND (SCCP/M3UA)
RUA-CONNECT-REQ SCCP-CONNECT-REQ 連線建立 RUA-CONNECT-IND SCCP-CONNECT-IND RUA-DIRECT-TRANSFER-REQ SCCP-DATA-REQ 直接傳輸 RUA-DIRECT-TRANSFER-IND SCCP-DATA-IND RUA-DISCONNECT-REQ SCCP-DISCONNECT-REQ 關閉連線 RUA-DISCONNECT-IND SCCP-DISCONNECT-IND RUA-CONNECTIONLESS-TRANSFER-REQ SCCP-UNITDATA-REQ 無連線傳輸 RUA-CONNECTIONLESS-TRANSFER-IND SCCP-UNITDATA-IND 訊息模型 訊息類型
SCTP REQ/IND (RUA) SCTP REQ/IND (SCCP/M3UA)
SCTP-RUA-REQ SCTP-M3UA-REQ 資料傳輸 SCTP-RUA-IND SCTP-M3UA-IND 本研究僅考量一般正常系統運作，錯誤處理基本訊息不列入比較。本章後續 小節將比對各訊息內容的差異。
4.1. 連線建立基本訊息差異比較
本節比對 RUA 與 SCCP/M3UA 中用來進行連線建立的基本訊息參數差異。表 4.2 中 RUA REQ 模型的基本訊息為 RUA-CONNECT-REQ，RUA IND 模型的基本訊息為 RUA-CONNECT-IND；SCCP/M3UA 的 SCCP REQ 模型的基本訊息為 SCCP-CONNECT-REQ， SCCP IND 模型的基本訊息為 SCCP-CONNECT-IND。表 4.2 RUA 與 SCCP/M3UA 連線建立基本訊息內容對照表 RUA SCCP/M3UA RUA REQ RUA IND SCCP REQ SCCP IND 通訊協定 參數名稱 參數大小 參數大小 參數大小 參數大小 Message Type 1 1 -- --HNB Id 256 256 -- --CN Domain Id 1 1 -- --Context Id 3 3 --
--Intra Domain NAS Node Selector 28 28 -- --Establishment Cause 2 2 -- --Presence Bitmask -- -- 2 2 Mandatory Parameters -- -- 1 1 Optional Parameters -- -- 1 1 Protocol Class -- -- 1 1 Logical User Id -- -- 2 --Connection Id -- -- -- 4 Called Party Address -- -- 8 8 Correlation Id -- -- 2 3 Calling Party Address -- -- -- 9 RANAP Message 512 512 513 513
Importance -- -- 2 2
單位:位元組
表內各參數分別說明如下：
Message Type：RUA 以此參數分辨 RUA 訊息類型。SCCP 則以 Protocol Class 參數來分辨訊息類型。
HNB Id：RUA 以此參數識別各 HNB，並依此決定傳送 UE 訊息時所使用的 SCTP 連線。SCCP 則使用 Connection Id 來決定所需使用的連線。
CN Domain Id：RUA 以此參數分辨被叫端 (Called) 的 UE 連線是採用線路交 換 (Circuit Switching) 或分封交換 (Packet Switching)。SCCP 則使用 Called Party Address 來分辨。
Context Id：RUA 以此參數作為 UE 的身份識別碼。SCCP 在主叫端 (Calling) 時仍尚未具備連線資訊，故無對應參數；若為被叫端時則以 Called Party Address 來識別 UE。
如：SGSN) 繞送訊息所需資訊。SCCP 則使用 Called Party Address 內的點 碼資訊來繞送訊息。
Establishment Cause：RUA 以此參數說明連線建立原因 (例如：緊急電話)， 系統並以此參數決定繞送訊息的優先順序。SCCP/M3UA 則以 Importance 參數 決定繞送訊息的順序。
Presence Bitmask：SCCP/M3UA 以此參數決定該訊息中包含那些參數。RUA 則因全部參數都必需提供，故無此需求。
Mandatory Parameters：SCCP 以此參數決定該訊息內的有多少個必要參數。 SCCP-CONNECT-REQ 與 SCCP-CONNECT-IND 中，此參數值分別為 4 與 3。RUA 則 因全部參數都必需提供，故無此需求。
Optional Parameters：SCCP 以此參數決定該訊息內包含多少個選擇性參數。 SCCP-CONNECT-REQ 與 SCCP-CONNECT-IND 中，此參數值分別為 2 與 4。RUA 則 因全部參數都必需提供，故無此需求。
Protocol Class：SCCP 以此參數識別訊息種類，並定義系統發生錯誤的處理 機制，其功能與 RUA 的 Message Type 參數相同。
Logical User Id：SCCP 以此參數識別該 SCCP-CONNECT-REQ 訊息為 RANAP 模 組或是系統控制模組所產生。RUA 因訊息來源僅為 RANAP 模組故無此參數。 Connection Id：SCCP-CONNECT-IND 以此參數告知 RANAP 模組，該訊息傳輸
所用的 SCTP 連線，其功能與 RUA 的 HNB Id 參數相同。
Called Party Address：SCCP 以此參數識別被叫端資訊，並決定傳送連線對 象，其內容包含點碼 (Point Code)、全域碼 (Global Title) 與子系統號 碼 (Subsystem Number) 等。RUA 則不分主叫端與被叫端均以 Context Id 來 識別 UE。
Correlation Id：此參數為 M3UA 的路由連線相關資訊其大小為 2 位元組。 因在 SCCP-CONNECT-IND 中並非必要資訊，故需增加 1 位元組的參數種類， 讓系統可對該參數進行解讀。RUA 則以 Context Id 參數取代此部份功能。 Calling Party Address：SCCP 以此參數識別呼叫端資訊，使其在回傳訊息
能傳送到正確節點。其大小原只需 8 位元組，因在 SCCP-CONNECT-IND 中為 可選擇資訊，故需增加 1 位元組的參數種類，讓系統可對該參數進行解讀。 RUA 則以 Context Id 識別回傳訊息所需連線。
RANAP Message：RUA 或 SCCP/M3UA 所承載的 RANAP 訊息內容，在
組的參數種類，辨別參數內容。
Importance：SCCP 以此參數定義訊息決定繞送訊息的優先順序，其功能與 RUA 的 Establishment Cause 參數相同。
4.2. 直接傳輸基本訊息差異比較
本節比對 RUA 與 SCCP/M3UA 中，已具備連線狀態下用來直接傳輸資料的基本 訊息參數差異。表 4.3 中 RUA REQ 模型的基本訊息為 RUA-DIRECT-TRANSFER-REQ， RUA IND 模型的基本訊息為 RUA-DIRECT-TRANSFER-IND；SCCP/M3UA 的 SCCP REQ 模型的基本訊息為 SCCP-DATA-REQ，SCCP IND 模型的基本訊息為 SCCP-DATA-IND。
表 4.3 RUA 與 SCCP/M3UA 直接傳輸基本訊息內容對照表 RUA SCCP/M3UA RUA REQ RUA IND SCCP REQ SCCP IND 通訊協定 參數名稱 參數大小 參數大小 參數大小 參數大小 Message Type 1 1 -- --HNB Id 256 256 -- --CN Domain Id 1 1 -- --Context Id 3 3 -- --Presence Bitmask -- -- 2 2 Mandatory Parameters -- -- 1 1 Optional Parameters -- -- 1 1 Connection Id -- -- 4 4 RANAP Message 512 512 512 512 Importance -- -- 2 2 單位:位元組 表內各參數僅就與第四章第 1 節有差異部份進行說明，功能重複或無差異部份則 省略不再敍述： Mandatory Parameters：SCCP 以此參數決定該訊息內的有多少個必要參數。 SCCP-DATA-REQ 與 SCCP-DATA-IND 中，此參數值均為 2。 Optional Parameters：SCCP 以此參數決定該訊息內包含多少個選擇性參數。 SCCP-DATA-REQ 與 SCCP-DATA-IND 中，此參數值均為 1。
RANAP Message：RUA 或 SCCP/M3UA 所承載的 RANAP 訊息內容，在直接傳輸訊 息內容中，均為必要資訊。
4.3. 連線關閉基本訊息差異比較
本節比對 RUA 與 SCCP/M3UA 中，進行連線關閉的基本訊息參數差異。表 4.4 中 RUA REQ 模型的基本訊息為 RUA-DISCONNECT-REQ，RUA IND 模型的基本訊息為 RUA-DIRECT-TRANSFER-IND； SCCP REQ 模型的基本訊息為
SCCP-DISCONNECT-REQ，SCCP IND 模型的基本訊息為 SCCP-DISCONNECT-IND。 表 4.4 RUA 與 SCCP/M3UA 連線關閉基本訊息內容對照表
RUA SCCP/M3UA RUA REQ RUA IND SCCP REQ SCCP IND 通訊協定 參數名稱 參數大小 參數大小 參數大小 參數大小 Message Type 1 1 -- --HNB Id 256 256 -- --CN Domain Id 1 1 -- --Context Id 3 3 -- --Presence Bitmask -- -- 2 2 Mandatory Parameters -- -- 1 1 Optional Parameters -- -- 1 1 Release cause 2 2 1 1 Originator -- -- -- 1 Connection Id -- -- 4 4 Responding Address -- -- 9 9 Correlation Id -- -- 3 3 RANAP Message 512 512 513 513 Importance -- -- 2 2 Logical User Id -- -- 3 --單位:位元組 表內各參數僅就與第四章第 1 節有差異部份進行說明，功能重複或無差異部份則 省略不再敍述： Mandatory Parameters：SCCP 以此參數決定該訊息內的有多少個必要參數。 SCCP-DISCONNECT-REQ 與 SCCP-DISCONNECT-IND 中，此參數值分別為 2 與 3。 Optional Parameters：SCCP 以此參數決定該訊息內包含多少個選擇性參數。 SCCP-DISCONNECT-REQ 與 SCCP-DISCONNECT-IND 中，此參數值分別為 5 與 4。 Release cause：RUA 與 SCCP/M3UA 均以此參數說明連線關閉原因。RUA 將系
Originator：SCCP 以此參數定義發起關閉連線的元件為網路服務使用者、網 路服務提供者或其他未定義之元件。RUA 則因關閉連線後，兩端均需自行清 除連線相關資訊，不再進行資訊傳遞，故不需識別發起元件。 Responding Address：SCCP/M3UA 以此參數告知系統回應連線關閉的位址資 訊。SCCP-DISCONNECT-REQ 與 SCCP-DISCONNECT-IND 中，此參數為可選擇資 訊，故需增加 1 位元組做為參數類型與內容的辨別使用。RUA 的兩端均需自 行清除連線相關資訊，不再進行資訊傳遞，故不需此參數。
Correlation Id：此參數為 M3UA 的路由連線相關資訊其大小為 2 位元組。 SCCP-DISCONNECT-REQ 與 SCCP-DISCONNECT-IND 中，此參數為可選擇資訊， 故需增加 1 位元組做為參數類型與內容的辨別使用。RUA 則 Context Id 參數 取代此部份功能。
Logical User Id：SCCP 以此參數識別該 SCCP-DISCONNECT-REQ 訊息為 RANAP 模組或是系統控制模組所產生。此參數為可選擇資訊，故需增加 1 位元組做 為參數類型與內容的辨別使用。RUA 因訊息來源僅為 RANAP 模組故無此參數。
4.4. 無連線傳輸基本訊息差異比較
本節比對 RUA 與 SCCP/M3UA 中，進行連線關閉的基本訊息參數差異。表 4.5 中 RUA REQ 模型的基本訊息為 RUA-CONNECTIONLESS-TRANSFER-REQ，RUA IND 模 型的基本訊息為 RUA-CONNECTIONLESS-TRANSFER-IND；SCCP REQ 模型的基本訊息 為 SCCP-UNITDATA-REQ，SCCP IND 模型的基本訊息為 SCCP-UNITDATA-IND。
表 4.5 RUA 與 SCCP/M3UA 無連線傳輸基本訊息內容對照表 RUA SCCP/M3UA RUA REQ RUA IND SCCP REQ SCCP IND 通訊協定 參數名稱 參數大小 參數大小 參數大小 參數大小 Message Type 1 1 -- --HNB Id 256 256 -- --Presence Bitmask -- -- 2 2 Mandatory Parameters -- -- 1 1 Optional Parameters -- -- 1 1 Called Party Address -- -- 8 8 Calling Party Address -- -- 8 8 RANAP Message 512 512 512 512 Sequence Control -- -- 2 2 Return Option -- -- 2 2 Importance -- -- 2 2 單位:位元組 表內各參數僅就與第四章第 1 節有差異部份進行說明，功能重複或無差異部份則 省略不再敍述： Mandatory Parameters：SCCP 以此參數決定該訊息內的有多少個必要參數。 SCCP-UNITDATA-REQ 與 SCCP-UNITDATA-IND 中，此參數值均為 3。 Optional Parameters：SCCP 以此參數決定該訊息內包含多少個選擇性參數。 SCCP-UNITDATA-REQ 與 SCCP-UNITDATA-IND 中，此參數值均為 3。
Sequence Control：SCCP 以此參數做為訊息同步控制。RUA 並不做同步控制， 故無此參數。 Return Option：SCCP 以此參數定義所傳資訊是否應回傳，亦或直接丟棄。 並定義回傳資訊所使用的位元排序模式 (有效位元在最前或最後)。RUA 並不 回傳資訊，故無此參數。
4.5. 資料傳輸基本訊息差異比較
本節比對 RUA 與 SCCP/M3UA 中，與 SCTP 傳送與接收訊息所使用的基本訊息 參數差異。表 4.6 中 RUA 的 SCTP REQ 模型，其對應的基本訊息為 SCTP-RUA-REQ， SCTP IND 模型所對應的基本訊息為 SCTP-RUA-IND; SCCP/M3UA 的 SCTP REQ 模型， 其對應基本訊息為 SCTP-M3UA-REQ，SCTP IND 模型對應基本訊息則為表 4.6 RUA 與 SCCP/M3UA 的 SCTP REQ/IND 資料傳輸基本訊息內容對照表 RUA SCCP/M3UA SCTP REQ SCTP IND SCTP REQ SCTP IND 通訊協定 參數名稱 參數大小 參數大小 參數大小 參數大小 Payload Protocol Id 4 -- 4 4 User Data 512 512 8[註 1] 1[註 2] Confirm Type 4 -- -- --Confirm Data 512 -- -- --Association Id 4 4 4 4 Stream Id 2 2 2 2 Message Type -- 1 -- --Context -- -- 4 --Destination Address -- -- 10 --IO Vector Length -- -- 4 --Life Time -- -- 4 --Order Flag -- -- 1 --Bundle Flag -- -- 1 --Error Code -- -- 4 4 Data Len -- -- -- 4 SCTP Block -- -- -- 1 單位:位元組 [註 1]User Data 為採 iovec 結構的指標故標示 8 位元組，其內容資料長度可變。 [註 2]User Data 為 1 位元組指標，其內容資料長度記錄在 Data Len 參數。 表內各參數分別說明如下：
Payload Protocol Id：SCTP 層需要此參數定義所承載的通訊協定類型。該 參數值 RUA 為 19，M3UA 為 3。另外，由於 Iuh 介面中 HNBAP 與 RUA 共用 SCTP 連結 (Association)，SCTP 須分辦該訊息傳送對象為 RUA 或 HNBAP，當 RUA 收到 SCTP-RUA-IND 訊息時，已確該訊息為 RUA 所有，故省略本參數。 User Data：RUA 與 SCCP/M3UA 均使用此參數傳送訊息內容。SCTP-M3UA-REQ
中此參數採 iovec 結構的指標故標示 8 位元組，其內容資料長度可變。 SCTP-M3UA-IND 中此參數為 1 位元組指標，其內容資料長度記錄於 Data Len 參數。
Confirm Type：RUA 使用此參數辨識其 SCTP-RUA-REQ 傳送內容的操作類型。 SCCP/M3UA 則並不辨識回傳內容的操作類型，故無此參數。
Confirm Data：RUA 使用此參數承載 SCTP 傳送後須回報的資料。SCCP/M3UA 則並不做資訊回報，故無此參數。
Association Id：SCTP 連結識別碼。 Stream Id：SCTP 串流識別碼。
Message Type：RUA 使用此參數辨識 SCTP-RUA-IND 所承載的內容為回報資訊 或 SCTP 的傳送資訊。SCCP/M3UA 則並不做資訊回報，故無此參數。
Context：SCCP/M3UA 用此參數對 SCTP 連結進行細部操作，如建立連線、設 定參數與停止服務等。RUA 則因系統中 SCTP 連結的所有操作均由 HNBAP 處 理，故無此參數。
Destination Address：SCCP/M3UA 用此參數指定 SCTP-RUA-REQ 的傳送對象。 RUA 則因系統中 SCTP 連結的所有操作均由 HNBAP 處理，故無此參數。 IO Vector Length、Life Time、Order Flag、Bundle Flag：為 SCTP 細部
運作參數。SCCP/M3UA 用此參數指定 SCTP-M3UA-REQ 傳送時所需的操作資訊。 RUA 則因系統中 SCTP 連結的所有操作均由 HNBAP 處理，故無相關參數。 Error Code：SCCP/M3UA 用此參數報告錯誤代碼，RUA 則以 Confirm Type 編
碼與 Confirm Data 內容辨識錯誤。
Data Len：SCCP/M3UA 中 SCTP-M3UA-IND 用此參數告知系統 User Data 內容 的長度。RUA 則因 User Data 為固定長度故無需此參數。
SCTP Block：SCCP/M3UA 中 SCTP-M3UA-IND 用此參數告知系統目前 SCTP 是否 阻塞。RUA 則以 Message Type 做為系統連線狀況資訊。
五. 效能評估
本章為系統運作之效能評估。經由大量訊息的傳送與接收，測量 RUA 與 SCCP/M3UA 在訊息處理上的效能差異。我們進行實驗模擬所使用的硬體環境為具 備 2048 KB 快取 (cache) Intel(R) Xeon(TM) 3.20GHz 中央處理器 (CPU)，並搭 配 2GB (512MB * 4) 的記憶體。
訊息處理延遲時間關係如圖 5.1 所示，其中的 RUA REQ/IND (圖 5.1 (1) 與 (4))與 SCCP REQ/IND (圖 5.1 (5) 與 (8)) 負責處理與 RANAP 間的相關訊息。 RUA 的 SCTP REQ/IND (圖 5.1 (2) 與 (3)) 與 SCCP/M3UA 的 SCTP REQ/IND (圖 5.1 (6) 與 (7)) 負責處理與 SCTP 間的相關訊息。 2 , i
t
2 , rt
1 , it
1 , rt
圖 5.1 訊息處理延遲時間關係圖 根據不同訊息的來源，可將訊息處理區分為 REQ 基本訊息模型的處理與 IND 基本訊息模型的處理。依據不同的處理，我們定義出不同的訊息處理延遲時間 (Processing Delay)，分別說明如下： t ：RUA 由收到 RUA REQ 訊息 (圖 5.1 (1)) 至送出 SCTP REQ 訊息 (圖 5.1r,1
(2))間的延遲時間。
tr,2：SCCP/M3UA 由收到 SCCP REQ 訊息 (圖 5.1 (5)) 至送出 SCTP REQ 訊息 (圖 5.1 (6)) 間的延遲時間。
t ：RUA 由收到 SCTP IND 訊息 (圖 5.1 (3)) 至送出 RUA IND 訊息 (圖 5.1i,1
(4)) 間的延遲時間。
t ：SCCP/M3UA 由收到 SCTP IND 訊息 (圖 5.1 (7)) 至送出 SCCP IND 訊息i,2
(圖 5.1 (8)) 間的延遲時間。
後傳送給 SCTP 的間隔時間）。t 與i,1 t 則為 IND 基本訊息模型的處理延遲時間 (收i,2 到 SCTP 訊息，處理後傳送給 RANAP 的間隔時間）。 系統運作之效能評估方式共有以下 3 種： (1) 使用相同傳送頻率，傳送不 同類型的 RANAP 訊息、 (2) 使用相同傳送頻率，傳送相同類型但不同大小的 RANAP 訊息與 (3) 使用不同傳送頻率，傳送相同類型且相同大小的 RANAP 訊息。本章 後續將分別測量三種方式的t /r,1 tr,2與t /i,1 ti,2，並且說明各測量數據的意義。
5.1. 基本訊息承載不同 RANAP 訊息類型之效能評估
為驗證 RUA 是否比 SCCP/M3UA 具有更好的效能，來傳送與管理 HNB 與 HNB-GW 間的訊息，我們使用相同的硬體環境與軟體架構，處理不同類型的 RANAP 訊息， 並且測量其所需的處理延遲時間進行比較。同時，為確保實驗結果的穩定性，每 種類型的 RANAP 訊息處理模擬實驗，均處理 1 萬筆 RANAP 訊息，並將每 1 筆訊息 所需的間隔時間加總後平均，再進行比較。 我們以每秒 1 筆的頻率傳送模擬訊息，並使用表 4.1 的連線建立基本訊息、 直接傳輸基本訊息、連線關閉基本訊息與無連線傳輸基本訊息，量測各種訊息所 需的處理延遲時間，做為不同訊息的效能評量數據。表 5.1 為量測 4 種基本訊息 所使用的 RANAP 訊息。 表 5.1 測量延遲時間所承載的 RANAP 訊息類型 基本訊息類型 連線建立 直接傳輸 關閉連線 無連線傳輸 RANAP 訊息 INITIAL_ UE_MESSAGE SECURITY_ MODE_COMMAND IU_RELEASE_ REQUEST PAGING 承 載 訊 息 訊息大小 (位元組) 97 41 14 22 根據上述量測方式，我們先進行 REQ 基本訊息模型的效能評估。表 5.2 列出 1 r, t /tr,2處理 4 種 RANAP 訊息所需的平均處理延遲時間。依據實驗結果可知，處理 REQ 基本訊息模型時，RUA 對 SCCP/M3UA 的改善率介於 41.94%～62.52%之間。表 5.2 REQ 基本訊息模型處理不同 RANAP 訊息之平均處理延遲時間比較 RANAP 訊息 訊息類型 INITIAL_ UE_MESSAGE SECURITY_ MODE_COMMAND IU_RELEASE_ REQUEST PAGING 1 r, t 43.3852 33.6360 36.6011 27.4256 2 r, t 74.7218 72.8554 72.5446 73.1732 改善率 41.94% 53.83% 49.55% 62.52% 單位:微秒 RUA 在 PAGING 訊息的處理上，改善率達到 62%，是所有訊息中最好的。不論 RUA 或 SCCP/M3UA 對於 INITIAL_UE_MESSAGE 訊息的處理，皆需較長的處理延遲時 間。除了因為該訊息長度為 94 位元組，較其他類型的訊息大之外，RUA 處理 INITIAL_UE_MESSAGE 訊息時，需要攜帶較多參數，進行連線建立資源的對應 (mapping)，導致系統所需的記憶體空間比其他訊息多。而且因為資料較多，進 行 ASN.1 編碼運算就會花費較多的時間，所以其平均處理延遲時間在各種訊息中 最長。SCCP/M3UA 在處理 INITIAL_UE_MESSAGE 訊息上，雖然在系統初始時即預先 配置 (allocation) 處理該訊息所需的資源，希望藉由此種方式加快訊息的處 理，但受限於訊息長度，其處理延遲時間依舊最長。綜合來說，雖然 RUA 在處理 INITIAL_UE_MESSAGE 訊息時，相對於其他訊息的處理，需要較多時間，但是比起 SCCP/M3UA 所需的處理延遲時間，仍然是大幅改善。我們也注意到 RUA 與 SCCP/M3UA 平均處理延遲時間最短的訊息並不相同，分別為 PAGING 訊息跟 IU_RELEASE_REQUEST 訊息。這是因為在 PAGING 訊息的處理上，RUA 所使用的無 連線傳輸基本訊息，僅需分辨傳送訊息所需的連線，參數較少，所以編碼運算與 資源需求相對較少，自然其所需的平均處理延遲時間最短。而 SCCP/M3UA 則因系 統處理並無預先載入與連線無關的資源，所以需對 PAGING 訊息額外進行資源配 置，造成平均處理延遲時間略多於 SECURITY_MODE_COMMAND 與
IU_RELEASE_REQUEST 訊息。在 SECURITY_MODE_COMMAND 訊息處理上，RUA 並沒有 對相關連線資源做資源配置釋放 (free)，所以平均處理延遲時間反而較 IU_RELEASE_REQUEST 訊息略為減少。SCCP/M3UA 在這 2 種訊息的處理，只有修改 連線狀態記錄，並沒有做資源釋放動作，所以平均處理延遲時間反而因為 IU_RELEASE_REQUEST 訊息較小，所以表現優於 SECURITY_MODE_COMMAND 訊息。 評估 REQ 基本訊息模型後，我們再對進行 INQ 基本訊息模型的進行效能評 估，並觀察實驗結果。表 5.3 為 IND 基本訊息模型對不同 RANAP 訊息的平均處理 延遲時間。t /i,1 t 對 4 種 RANAP 訊息所需的平均處理延遲時間分別介於 23.8025i,2 ～33.9775/66.3629～70.9730 間。改善率則介於 52.13%～66.34%之間。
表 5.3 IND 基本訊息模型處理不同 RANAP 訊息之平均處理延遲時間比較 RANAP 訊息 訊息類型 INITIAL_ UE_MESSAGE SECURITY_ MODE_COMMAND IU_RELEASE_ REQUEST PAGING 1 i, t 33.9775 26.6860 31.0778 23.8025 2 i, t 70.9730 66.3629 66.9710 70.7246 改善率 52.13% 59.79% 53.60% 66.34% 單位:微秒
RUA 在 IND 基本訊息模型的處理上仍然比 SCCP/M3UA 的表現為佳，而且比起 REQ 基本訊息模型的處理，其 4 種訊息的平均改善率由 51.96%提昇至 57.96%。不 論 RUA 或 SCCP/M3UA 對於 IND 基本訊息模型的平均處理延遲時間均小於 REQ 基本 訊息模型的平均處理延遲時間。這是因為當 RUA 收到所需處理的 IND 基本訊息模 型時，會直接對目前訊息存放的記憶體空間，進行 ASN.1 解碼運算，並且不需保 留確認資料傳送的相關資料，記憶體空間存取與配置所需要的次數和時間均比處 理 REQ 基本訊息模型少，所以相較於 REQ 基本訊息模型的會有較短的平均處理延 遲時間。而 SCCP/M3UA 則是因為處理 IND 基本訊息時，僅直接對訊息的標頭 (Header) 進行辨識，操作該訊息使用中的記憶體空間來取得相關資訊，不再重 複配置記憶體，所以也較 REQ 處理為佳。我們亦可發現 SCCP/M3UA 在 IU_RELEASE_REQUEST 訊息的處理比 SECURITY_MODE_COMMAND 訊息還要花費較多時 間，與處理 REQ 基本訊息模型時並不相同。此部份是因為 SCCP/M3UA 會對該訊息 的連線登錄狀態相關資源做釋放動作，故需較多處理時間。由實驗數據可知，若 能減少記憶體配置操作，RUA 所能得到的效益將大於 SCCP/M3UA 所能得到的效益。
5.2. 基本訊息承載不同大小訊息之效能評估
承第五章第 1 節，不同的 RUA 基本訊息在處理 RANAP 訊息時比 SCCP/M3UA 提高 41%～66%的效能。本節我們則評估，若是使用相同的基本訊息，傳送與 接收不同大小 RANAP 訊息，其效能表現是否會隨著資料大小不同而有所變化。 1 r, t /t 與i,1 tr,2/t 均使用第四章表 4.1 的直接傳輸基本訊息處理 50 位元組、i,2 100 位元組、150 位元組、200 位元組與 250 位元組，5 種不同大小位元組的 RANAP SECURITY_MODE_COMMAND 訊息。並且為了確保實驗結果的穩定性，每種大小均處 理 1 萬筆訊息，再將所有數據進行算數平均。 表 5.4 為 REQ 基本訊息模型對不同大小 RANAP 訊息的平均處理延遲時間。由 實驗結果可知，t /r,1 tr,2所需的平均處理延遲時間分別為 32.3856～ 34.9507/70.2078～71.7306。改善率則介於 51.28%～53.98% 之間。
表 5.4 REQ 基本訊息模型處理不同大小訊息之平均處理延遲時間比較 訊息大小(位元組) 50 100 150 200 250 1 r, t 32.3856 32.4644 34.5393 34.6353 34.9507 2 r, t 70.2078 70.5458 70.6014 71.1060 71.7306 改善率 53.87% 53.98% 51.08% 51.29% 51.28% 單位:微秒 根據實驗數據的結果，我們觀察到，隨著訊息大小的增加，處理時間亦相對 增加，符合原先預期。同時，我們也發現到 RUA 在處理傳送 150 位元組以上的 REQ 基本訊息模型時，需要額外增加一些處理時間，但是在 SCCP/M3UA 並沒有發現這 樣的情形。這是因為 RUA 所使用的 OSS ASN.1 在進行編碼運算時，會預先配置記 憶體空間儲存已完成編碼的字元組，但是當需要儲存的字元組超過原先預設的空 間時，即需擴充原先的記憶體配置空間，以確保編碼資訊可以完整儲存，故會額 外增加一些時間。而 SCCP/M3UA 在處理直接傳輸的 REQ 基本訊息模型時，並不需 對訊息做編碼動作，僅對該訊息加上所需標頭 (Header)，故無處理時間額外增 加的現象。 表 5.5 為 IND 基本訊息模型對不同大小 RANAP 訊息的平均處理延遲時間。由 實驗數據可知，RUA 比起 SCCP/M3UA，其改善率約為 59%。且各訊息的平均處理延 遲時間隨著訊息大小而增加，與 REQ 基本訊息模型的處理相同。 表 5.5 IND 基本訊息模型處理不同大小訊息之平均處理延遲時間比較 訊息大小(位元組) 50 100 150 200 250 1 i, t 26.2248 26.3286 26.6542 26.7090 26.8645 2 i, t 65.3393 65.5058 65.7725 65.8609 65.9131 改善率 59.86% 59.81% 59.48% 59.45% 59.24% 單位:微秒 我們也發現不論任何大小的處理均較 REQ 基本訊息處理來的少，表現亦與上 一節承載不同 RANAP 訊息類型的狀況相符合。RUA 對 IND 基本訊息的處理是將該 訊息進行解碼運算，且解碼運算是直接針對資料既存的記憶體空間進行。解碼後 的結果，會存放於系統預先配置好記憶體空間區塊。而且 OSS ANS.1 原先預設的 解碼儲存空間，就可以完整容納我們測試訊息的大小，所以並不會進行記憶體擴 充配置。因此對照 REQ 訊息的處理，就沒有因訊息較大而需額外增加處理時間的 現象。SCCP/M3UA 在處理 IND 訊息時，如同前一節所述，並無解碼動作，僅會對 該訊息標頭進行解讀，並直接存取相關的訊息內容，所以表現亦無太大差異。 雖然隨著訊息大小的增加，RUA 的改善率略有降低，但仍遠優於 SCCP/M3UA。 且不論 RUA 或 SCCP/M3UA，針對同類型的 RANAP 訊息處理，所需的平均處理延遲
時間，相較於處理不同類型的 RANAP 訊息，呈現的變化較小。由上一節與本節的 實驗數據結果，我們可以知道，不同的基本訊息類型比同樣訊息類型但不同大 小，對系統處理效能的影響較為明顯。整體而言，RUA 在處理不同大小訊息的表 現與承載不同類型 RANAP 訊息時，均較 SCCP/M3UA 提升不少效率。
5.3. 基本訊息在不同傳送頻率下之效能評估
依據前面二小節的測量數據結果，我們可知，不論是不同類型或是相同 類型但不同大小的 RANAP 訊息，RUA 的處理效能皆優於 SCCP/M3UA 許多。接續 前面的實驗，本節改採用不同傳輸頻率傳送相同訊息，進行效能評估，驗證 RUA 是否具備優秀的處理效能。5.3.1. 處理延遲時間之評估
因為連線建立、直接傳輸、連線關閉等訊息，須照建立通話步驟依序執行， 並無法依不同傳送頻率進行單獨處理，否則會造成系統錯誤。為避免因訊息重複 執行而造成的通話狀態錯誤，影響實驗結果，所以我們以不具狀態的無連線傳輸 訊息 (表 4.1) 進行效能評估。本模擬實驗使用 22 位元組的 RANAP PAGING 訊息， 並依不同的頻率傳送給 RUA 與 SCCP/M3UA，測量其t /r,1 t 與i,1 tr,2/t 延遲時間的數i,2 據。雖然我們已避免因通話狀態而造成的系統錯誤，但是電腦的運算能力有其上 限，並非各種傳送頻率的 1 萬筆訊息測量程序都能正確執行完成，所以我們只將 正確處理的部份，進行算數平均。 圖 5.2 (a)為 REQ 基本訊息模型在不同傳輸頻率下的平均處理延遲時間。t /r,1 2 r, t 在每秒 1、10、100、1000、10000 與 100000 筆時，所需的平均處理延遲時間 分別為 27.43/73.17、17.54/62.26、17.11/62.14、14.71/213.71、18.43/1727.27 與 18.28/7122.63。改善率分別為 62.52%、71.83%、72.47%、93.12%、98.93%與 99.74%。 圖 5.2 (b)為 IND 基本訊息模型在不同傳輸頻率下的平均處理延遲時間。t /i,1 2 i, t 在每秒 1、10、100、1000、10000 與 100000 筆時，所需的平均處理延遲時間 分別為 23.80/70.72、20.50/407.93、18.15/593.33、17.97/26068.21、 18.13/26288.40 與 18.06/26184.91。改善率分別為 66.34%、94.97%、96.94%、 99.93%、99.93%與 99.93%。圖 5.2 RUA 與 SCCP/M3UA 不同傳送頻率所需處理延遲時間比較
由實驗數據可知，RUA 在 REQ 基本訊息模型的處理，以平均每秒 1000 筆時所 需的平均處理延遲時間最短。SCCP/M3UA 則以每秒 100 筆所需的平均處理延遲時 間最短。會有此現象是因為記憶體快取與系統運算能力的限制。RUA 的運作若是
每秒傳送筆數小於 1000 筆時，系統會受到記憶體快取 (cache) 已被其他資料取 代，需重新載入運算資料，使得處理時間變慢。但若是每秒傳送筆數大於 1000 筆時，則會超過系統處理資料能力的上限，造成處理時間的延長。SCCP/M3UA 在 處理 REQ 基本訊息模型時，除了承接 RANAP 訊息的 SCCP 層需經由訊息佇列傳送 外，連 SCCP 與 M3UA 間的訊息亦需經由訊息佇列傳送。在單一處理緒 (single thread) 循序處理的情況下，系統會優先處理已進入佇列排序的 RANAP 訊息，而 SCCP 處理完成並傳送至訊息佇列的訊息，則會等待排序在前面的訊息處理完成後 才傳送到 M3UA 進行處理，造成處理時間的延遲。若是訊息傳送頻率大於每秒 1000 筆時，SCCP/M3UA 便會發生異常，無法再處理任何訊息。對於無法正常完成測量 程序的部份，我們僅以系統發生錯誤前的數據進行加總再除以所完成的筆數。 RUA 在 IND 基本訊息模型的處理，為每秒 1000 筆時所需的平均處理延遲時間 最短。其原因與 REQ 基本訊息模型的處理相同，故不再撰述。而 SCCP/M3UA 的表 現也與 REQ 基本訊息模型相同。當傳送頻率大於每秒 1000 筆時，SCCP/M3UA 即發 生異常，無法處理訊息，所以相關實驗數據，亦只取系統發生錯誤前的統計資料 進行算數平均。 經由本實驗的結果可以驗證出，RUA 在大量資料的處理能力上，是 SCCP/M3UA 所不及的。而且當系統所需處理的資料量越大，RUA 取代 SCCP/M3UA 所得到的效 益越明顯。Iuh 介面制定 RUA 以簡化既有 Iu 介面通訊協定堆疊是非常正確的決定。
5.3.2. 訊息佇列 (Queue) 之評估
由上一小節的實驗，我們得知傳送頻率越高時，用 RUA 取代 SCCP/M3UA 來簡化通訊協定的所能獲得的處理時間效益越明顯，符合當初制定 RUA 通訊 協定的初衷。本節，我們使用與上一小節相同的傳送資料 (請參考 5.3.1.小 節)，改以訊息佇列的大小來驗證 RUA 與 SCCP/M3UA 在運作效能上的差異。在 測量並紀錄佇列大小數據的同時，我們也觀察中央處理器的使用率做為效能 評估的依據，評估推測我們開發的 RUA 所能負荷的運作上限值。為取得更精 準的數據，RANAP PAGING 訊息傳送頻率的處理延遲則比上一小節更密集。我 們以開始測量一分鐘後的訊息佇列大小，做為效能評量的數據。由於系統運 作效能有其上限，並非所有傳送頻率均可以順利運作完成，無法完成測量的 部份則紀錄為無限大。因本實驗僅紀錄訊息佇列大小，所以並無扣除訊息錯 誤處理部份，且該部份亦不影響實驗數據。 系統效能數據的評估時間處理延遲，從每隔 3000 微秒傳送 1 筆 (每秒333 筆)，依序遞減 100 微秒，到無限循環迴圈。圖 5.3 (a) 為 RUA 與 SCCP/M3UA 在不同傳送頻率下處理 RUA REQ 與 SCCP REQ 時所需的佇列大小。由實驗數據 可知，處理 REQ 基本訊息模型時，當傳送隔間時間小於每 1000 微秒一筆時 (每 秒 1000 筆)，RUA 的訊息佇列大小便開始急速增加。而且中央處理器的使用率 亦由 50%以下升高到 80%以上。傳送隔間時間為 100 微秒時 (每秒 10000 筆)， 系統便因為等待處理的資料堆積過多而產生系統異常，無法完成測量程序。 至於 SCCP/M3UA 則在傳送處理延遲小於 1900 微秒 (每秒 526 筆) 時，系統就 無法完成測量程序。由上述可知，SCCP/M3UA 所能負荷的處理能力上限，明顯 不如 RUA。 圖 5.3 RUA 與 SCCP/M3UA 不同傳送頻率所需佇列大小比較
圖 5.3 (b) 為 RUA 與 SCCP/M3UA 在不同傳送頻率下處理 SCTP IND 基本訊息 模型所需的佇列大小。由實驗數據可知，RUA 與 SCCP/M3UA 在處理 IND 基本訊息 模型時，即使處理延遲時間為 100 微秒時 (每秒 10000 筆)，佇列大小仍無明顯 變化，系統維持運作。不過，當訊息模擬器的訊息傳送以無限迴圈傳送時，系統 即會發生錯誤而無法量測。 比較 RANAP 基本訊息處理的效能評估數據（圖 5.3 (a)）與 SCTP 基本訊息 處理的效能評估數據（圖 5.3 (b)），我們可以發現無論是 RUA 或 SCCP/M3UA，在 處理 RANAP 訊息時，所能負荷的傳送頻率均較處理 SCTP 訊息低。而且 RUA 所能 處理的傳送頻率高出 SCCP/M3UA 許多。這是因為不論是 RUA REQ 或是 SCCP REQ
基本訊息模型的處理原本就需要較多的系統資源，且處理時間亦較久 (由第五章 第 1 節與第 2 節的評估結果可知)，所以當傳送頻率高於一定程度時，系統便無 法即時處理訊息佇列內的訊息，並且快速累積訊息，造成系統錯誤。而 SCTP IND 基本訊息模型的處理，原本所需的處理時間與記憶體配置運作就比較少，即便每 秒傳送 10000 筆時，我們的系統仍可維持正常運作。 經由上一節與本節的測量數據，我們可以推測 RUA 與 SCCP/M3UA 系統運 作上限分別為每秒 1000 筆與每秒 100 筆。為印證該推測是否正確，我們分別 以上述傳送頻率各自持續運作 24 小時以上，並觀察其變化與系統運作情形。 經過 24 小時運作的驗證，RUA 與 SCCP/M3UA 均正常運作無誤。所以我們可以 確認在我們的硬體設備規格下，RUA 能負荷的頻率上限為每秒 1000 筆訊息， SCCP/M3UA 則為每秒 100 筆訊息。
六. 結論
本論文設計與實作 RUA 通訊協定軟體。我們制定 RUA 通訊協定的基本流程模 型，並且使用訊息佇列做為 RUA 與其他通訊協定之間的資訊傳遞方式。文中也介 紹我們所使用的 CSPL 與其訊息佇列運作流程，並且設計與實作出符合 3GPP 規範 的 RUA 通訊協定軟體。最後並進行效能評估，驗證 RUA 是否比 SCCP/M3UA 更適合 使用於 Iuh 介面，雖然目前僅以 HNB 系統架構實作 RUA 軟體，但是我們設計的基 本流程模型中包含 HNB-GW 端 RUA 的功能，所以亦可在 HNB-GW 系統運行。並且經 由不同類型的效能評估，可以驗證我們設計的 RUA 通訊協定，確實較 SCCP/M3UA 大幅提昇約 50%的效能。 我們實作的 RUA 通訊協定優點歸納如下： 1. 透過基本流程模型的制定，RANAP 與 SCTP 可以使用一致性的接口與 RUA 進行整合。 2. 移植到不同系統平台時，RUA 只需做部份變更即可與其他模組互動。 3. 具有統一的訊息格式，可輕易與其他廠商的 HNB 或 HNB-GW 系統軟體進行 整合。 經由我們 RUA 通訊協定的實作，可以對國際社會傳達我們在 Femtocell 通訊 系統的研發能力上，已具備一定的實力與其他廠商競爭。並讓有意開發 Femtocell 產品的相關廠商，可以多一個選擇，增加其產品在開發上的彈性與價格的競爭力。
參考文獻
[1] ABI research, “Femtocell market challenges and opportunities”, Apr. 2007.
[2] P. Marshall, “Rationalizing Fixed-Mobile Convergence”, Yankee Group Research, Inc., 2006.
[3] D.H. Yang, S. Kim, C. Nam, and J.S. Moon, “Fixed and mobile service convergence and reconfiguration of telecommunications value chains”, IEEE Wireless Communications, Vol. 11, Issue 5, pp. 42-47, 2004.
[4] S.T. Yang, C.H. Gan, Y.B. Lin, “Design and Implementation of RUA Protocol”, ICL Technical Journal, Vol. 130, pp.28-37, Dec. 2009. [5] S.T. Yang, C.H. Gan, “The Design and Implementation of the RUA
Protocol in the Home Node B”, IEEE Vehicular Technology Conference (VTC 2010-Spring), pp.1-4. 2010.
[6] 3GPP, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN overall description (Release 8), 3GPP TS 25.401 V8.2.0 (2008-12), 2008.
[7] V. Chandrasekhar, J. G. Andrews, and A. Gatherer, “Femtocell networks: a survey”, IEEE Communications Magazine, vol. 46, pp. 59-67, Sep. 2008
[8] 3GPP, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN architecture for 3G Home Node B (HNB); Stage 2 (Release 8), 2009.
