GPRS信令盲點-RR

[前言]
不知何故，對於GPRS的信令(即通信協定)，筆者目前所能找到的教學資料，無論是知名原文著作如[5]、大學教材如[8]、[9]，還是網路上的教學資源如[7]，大都沿襲自3GPP TS03.60[1]的同一套講法：將RR視而不見，這令筆者隱隱覺得不妥，便開始深入3GPP/GSM 的規格圖書館中博灠文件，幸運地在某些文件中找到解答，在此發表心得，以供參考。

圖一以簡化的方式畫出GSM與GPRS的網路元件與界面名稱。此圖下端可以看出GPRS比GSM多增加的兩個網路元件：SGSN與GGSN，由於Gb界面的信令複雜度大於Gn界面(Gn的堆疊只有IP/GTP/UDP/IP/Ethernet)，可以了解到SGSN在GPRS網路所扮演的吃重角色，也因為與移動相關的信令(如GMM)從MS經由各BTS-BSC只到SGSN為止，所以大部分的3GPP技術規格都只談論MS到SGSN的過程，這種觀點是可以理解的。

GPRS還新增一個重要的Gs界面，位於VLR與SGSN之間(實體界面看起來介於MSC與SGSN之間，但邏輯上其實是介於VLR與SGSN兩者，請讀者注意)，讓Class A的手機在使用數據服務的時候，不會錯過GSM的服務。
圖二是張經典的作圖，將MS, BSS(BSS是BTS與BSC的合稱，這樣合稱會錯過其間的Abis界面沒有畫出，請讀者留心)到SGSN的每個網路元件的內部信令堆疊圖。此圖出自3GPP的規格書，此規格書清楚地說明這是GPRS的信令平面(Signalling Plane)，之後幾乎所有的經典著作與通信教材也都遵守此圖來傳述GPRS，非常忠於原著。但筆者以第一線機房工程師的工作需求設想，這張圖其實不夠充分，因為所謂GPRS信令平面，應該是將GPRS各種功能與服務需要涉及到的所有信令都包含在內才算充分，筆者不知當年(1998年)的會員是否曾經有人針對這點提出異議，究竟經過如何的爭辯攻防，事到如今，我們看到的還是這樣一張資訊不夠充分的圖，科技發展的歷程實在很值得細細玩味。

無論如何，這張圖至少標示著一個正確的資訊，就是所有的GMM/SM訊息，都是承載在LLC/RLC/MAC/RF上面，經由RF到達BSS，然後LLC被送到SGSN，LLC上層的GMM/SM才被SGSN讀取/對話，以這個觀點而言，這張圖的資訊的確是足夠用的。以下繼續說明筆者認為資訊不足之處。
圖三是在3GPP TS43.051規格中發現的圖，以另一種觀點來詮釋GPRS控制信令平面(Control Plane)(Control Plane是Signalling Plane的另一個說法)，筆者在此終於獲得印證與更多的啟發。

首先，請讀者先不必在意手機Iu mode加上RRC與RLC的建議，(老實說，筆者覺得在GPRS中加入RRC的功能真是瘋狂的建議)，除此之外，讀者仔細看看此圖可以發現，如同RRC在Uu具有的重要地位，RR也對於控制RLC/MAC與LAPDm有著重要地位，只是目前所有RR的訊息都通過LAPDm，在GSM既有的logical channel上傳送，所以無法在GPRS的logical channel上發現RR的蹤跡。

此圖很清楚可以發現GMM/SM有一條線向下關連著RR/LAPDm/PHY的控制路徑，這證明RR在GPRS的控制信令平面具有不容忽視的重要性。
讓我們繼續深入RR的架構。很驚訝地發現RLC/MAC在GPRS的實現方式其實是納入RR的堆疊中，請看圖四，此圖出自3GPP TS44.060，可以在RR的sublayer中清楚發現RLC/MAC的堆疊，所以GPRS的RLC/MAC不像UMTS的RLC/MAC一樣，是與RRC分離的獨立堆疊，倒像是違章建築一樣蓋在RR之中，這是非常有趣的發現，這種結構暗示了GSM/GPRS結構上的不優雅，因為RR屬於OSI model L3，而RLC/MAC屬於L2，現在RR中建構RLC/MAC會造成OSI model的分層不夠清楚。

此圖最右邊GMM由上而下，經由LLC經過GRR-SAP到RLC/MLC，最後到達PDCH，目前所知所有的GMM訊息都經由PDCH這條physical channel收送。

另一條路徑從GMM經由GMMRR-SAP到RR management，命令GPRS RR(GRR)控制RLC/MAC或是送出不同的GRR訊息協助完成GMM的工作，只是目前所有的GRR訊息都經由GSM的logical channel收送，所以無法在PDCH上發現RR的訊息，因此常常被視為傳統GSM的訊息，筆者認為這是不正確的觀念，RR當中的確有純粹屬於GSM功能的訊息，但也隨著GPRS的引入而加入許多純粹GPRS功能的訊息，當我們談論GPRS的控制信令時，只要是與GPRS相關的程序與服務有關的信令，都該被一併考慮，才能完整描述整個GPRS過程。

最左邊從MM下到RR-SAP的那條控制線，才是傳統GSM的信令路徑，表示MM只會出現在GSM的logical channel上，在這條路徑上所發現的RR訊息才是純粹GSM的信令。
分析至此，筆者將以上的看法綜合整理後，重新繪製GPRS的信令平面如圖五。改變的部份不多，只是在MS與BSS加入GRR與用來傳輸GRR的LAPDm/PHY而已，其餘部分維持不變，此圖重點在於強調原本RR在GPRS信令過程於Um界面所扮演的重要性，至於BSC上行的Gb界面則與圖二完全一致。

對工程師而言，無論是設計GPRS MS或是RF網路優化，筆者建議RR堆疊的角色不可忽視，在Abis監看GMM/SM的同時也要從LAPD監看RR的訊息才能完全掌握GPRS的所有動作是否完成。

說明：由於保密性的設計，Um無法監看，所有Um的信令必須由Abis間接取得，而Um界面上的無線LAPDm堆疊到了Abis變成了有線的LAPD堆疊，因此RR變成要在LAPD上監看。
圖六是使用Protocol Analyser(協定分析儀)作GPRS call trace時的信令監控界面圖。藍色的線表示Protocol Analyser的probe，標準監控界面包含Abis, Gb, Gn與Gs此四個界面，在Abis界面以往只監看PCU以上的堆疊，例如GMM，筆者在此認為不夠，建議還需要同時監看LAPD以上的GRR信令，才可以獲得完整的資訊來進行網路的除錯與優化。

[結論]
RR是GPRS信令的盲點，長期以來被文獻教材視而不見，或是當成GSM的信令，筆者認為不適當，因此試圖在此文中以3GPP規格書的其它例子說明RR在GPRS網路中的重要性。

參考文獻：
[1] ETSI TS 101 344 V7.9.0 (2002-09) Technical Specification Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS) Service description; Stage 2 (3GPP TS 03.60 version 7.9.0 Release 1998)

[2] ETSI TS 143 051 V5.6.0 (2002-04) Technical Specification Digital cellular telecommunications system (Phase 2+); GSM/EDGE Radio Access Network (GERAN) overall description; Stage 2 (3GPP TS 43.051 version 5.6.0 Release 5)

[3] ETSI TS 144 060 V4.1.0 (2001-04) Technical Specification Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control/ Medium Access Control (RLC/MAC) protocol (3GPP TS 44.060 version 4.1.0 Release 4)

[4] Jörg Erbespächer, Hans Jörg Vogel, Christian Bettstetter, GSM: Switching services and protocols, Wiley 2001

[5] Yi-Bing Lin and Imrich Chlamtac. Wireless and Mobile Network Architectures. John Wiley, 2001

[6] ETSI TS 101 350 V8.9.0 (2001-11) Technical Specification Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Overall description of the GPRS radio interface; Stage 2 (3GPP 03.64 version 8.9.0 Release 1999)

[7] Christian Bettstetter, Hans-Jörg Vögel, and Jörg Eberspächer/ GSM Phase 2+ General Packet Radio Service GPRS: Architecture, Protocols, and Air Interface/ Technische Universität München (TUM) : http://www.comsoc.org/livepubs/surveys/public/3q99issue/bettstetter.html

[8] 台大資訊工程學系/林風教授的教學資料：2006 Fall 個人通訊服務(Personal Communication Service)

[9] 元智大學電機系/賴薇如教授的教學資料：Chapter 7 GPRS 系統簡介 (96 1 17)

[10] 3GPP TS 24.007 V4.4.0 (2005-01) Technical Specification 3GPP; Technical Specification Group Core Network; Mobile radio interface signalling layer 3; General aspects (Release 4)

070528r1版本

GPRS學習雜記

1. GPRS不只提供GSM系統移動數據服務(Mobile Data Service)，也提供給IS-136系統(D-AMPS)。

2. GPRS與GSM收費方式的差異：
- GSM的CS-data以每分鐘計費，無論用戶是否真正傳送資料，都要收費
- GPRS的PS-data以實際傳送的資料量來計費，只有用戶真正傳送資料的時候，才要收費。

3. GPRS的數據服務，包含WAP, SMS, MMS, email與web access.

4. GPRS的標準由Release 97開始。原本在ETSI制定，後來交由3GPP維護。

070520r1

自問自答 - 2007Q2

[-] 在3GPP的LCS中的LMU Type A到底是一個由operator安裝在某些特殊地點的無線裝置，還是某種會與UE/MS合併的功能呢？(070323提出)

[-] 在3GPP的IMS領域一直出現的IP Multimedia Network(IMN)，到底與Internet的差別何在呢？(070223提出)
--> 目前自己的答案是，IP Multimedia Network是個以IP為主的全方位網路，相對於以數據為主，缺乏QoS保證的Internet與以SIP為主的IMS而言，IMN是個還在成長中的概念，也許會成為未來4G的核心網路。吉康Ed的答案是，FMC是個很大的架構，IMS僅是其中的一個子系統，故稱為Sub-system，我覺得還蠻有道理的(20070511)。

Tektronix的William說IMS犧牲自己，在NGN中扮演一個sub-system，也是很有趣的說法(2007年4月)。

[-] 畫完Uu界面之後，回頭整理Um界面，卻發現無論網路上、教科書籍中的GSM堆疊，由上而下分別是CM/MM/RR/LAPDm/PHY，而且僅有這一種標準答案，突然間我發現不懂GSM的架構了，首先是GSM的MAC難道與GPRS的不同嗎？第二個問題是，GSM為何沒有user plane的堆疊呢？那上網的資料要如何收送呢？(例如以GSM收email該如何運作呢？透過何種堆疊？)(070514提出)
NetHawk/Yehim的答覆如下：- GSM的Um確定沒有RLC/MAC，僅有LAPDm- GSM的user plane有兩種，一是純語音服務，其堆疊是codec/PHY，其二是CS-data，其堆疊應該是RLP/V.110/PHY。在此感謝Yehim的友情支援。(20070514)

[-] MAC到底是什麼？似乎很值得好好玩味一下，心中有些不解之謎，先寫在此處待日後回覆。首先，ISDN是有線的點對點、點對多點技術，但是數位有線技術ISDN沒有MAC，ISDN的堆疊是NWK(Q.931)/DLC(Q.921)/PHY(I.430)，相對地，同樣數位有線技術IEEE 802.3(Ethernet)的堆疊卻有MAC，加上IP為IP/(LLC/MAC)/PHY；以數位無線技術來說，DECT有MAC，其堆疊是NWK/(DLC/MAC)/PHY，而GSM(比DECT晚發展)的堆疊卻沒有MAC，堆疊是CM/MM/RR/LAPDm/PHY，GSM直到GPRS才加上MAC變成CM/GMM/(LLC/RLC/MAC)/PHY。至於UMTS的MAC, WLAN與WiMAX的MAC都扮演非常重要的角色，
整理如下：
ISDN: DLC (無MAC)
802.3: MAC
802.11:MAC
802.16d/e: MAC

DECT: MAC

GSM: LAPDm (無MAC)
GPRS: MAC
UMTS: MAC

IS-95(cdmaOne): MAC
cdma2000: MAC

我不禁想問，在何種情況下，MAC是必須的，能帶來獨一無二的好處？那當時GSM為何沒有使用呢？Ethernet又為何使用？如果Ethernet沒有使用MAC，會造成怎樣的改變呢？
--> 今天想到一個答案，在還未證明之前，先記在這裡備忘：
我覺得關鍵是CS-data或是PS-data，凡是提供PS-data服務的技術，無論有線或無線，都需要MAC，反之，只以CS-data為主的服務之技術，就不需要MAC，所以我的整理如下：
ISDN: DLC (無MAC) -> CS-data
802.3: MAC -> IP-data
802.11:MAC -> IP-data
802.16d/e: MAC -> IP-data

DECT: MAC -> CS-data and PS-data (當初MAC為DPRS作準備，可惜未成功)

GSM: LAPDm (無MAC) -> CS-data
GPRS: MAC -> IP-data
UMTS: MAC -> CS-data and PS-data

IS-95(cdmaOne): MAC -> CS-data and PS-data
cdma2000: MAC -> CS-data and PS-data
(20070518)

[-] R99可提供最多384kbps的數據服務，雖然是長久以來的已知，今天突然想問，對於R99可是僅有CS-domain的網路而言，其數據服務的最大值是多少？(亦即沒有PDCP)(070515提問)



070518r4版本

無責任雜記(002)

[前言]
此部份紀錄還有待仔細驗證，目前只是自己的聽聞筆記，請勿引用。

[主題]
行動網路全網監控的困難度

日前剛聽說Tektronix的NSA Analyzer全網監控的架構目前還無法應付2個以上的RNC，感到非常驚訝，因為NSA Analyzer是我心目中剛投票給100分的儀器呢。姑且不論此說法是否為真，倒是覺得可以當作一個題目好好研究一下，因為如果Tektronix做不到，筆者不認為其他儀器可以輕鬆達成，包在裡面的石頭是一樣硬的。

其實仔細分析，可以略知這個工程的困難度的確非常高。

分析如下：一個RNC可以管理多達200個以上的NodeB，一個NodeB代表一個Iub界面，所以要完全監控一個RNC，必須同時監看與此RNC相連的所有Iub，這是RNC的前半段，後半段加上所有Iu界面。Iu界面又分成IuCS與IuPS，一般operator為了避免loading過大，會在Iu界面施行load sharing的措施，亦即將兩條STM-1當作一條Iu界面來用(無論IuCS或IuPS都有)，這樣就多出4個STM-1的port。

所以光是一個RNC的完全監控，保守估計，就包含了150個Iub的STM-1(在此假設是中等規模的UTRAN，只接了150個NodeB，而且Iub不考慮IMA架構，都是單純的STM-1)與至少四條STM-1給Iu界面使用，還有一些E1界面或Ethernet界面給HSS以及Gn, Gi等其它完整call trace的必需界面。光這些實體界面多達幾百個port還不夠驚人，這些界面平常即使沒有user traffic也不會是靜止的，其中維護用的control signal就以非常驚人的速率累積到監控系統中的硬碟。

然而就像保全的錄影一樣，由於你不知道何時會發生狀況，只好將每個角落的錄影畫面乖乖地保存起來，等幾天以後再消除，這些線路中出現的所有信令，在沒有事先妥善的理論模型保證之下，一般operator不敢漏失任何資料，都以完全紀錄的方式保存，包含每個ATM cell，每個E1的frame，每個IP的packet，都詳實記錄在raw data中。

接下來問題才大條呢，首先是保存的資料要以Tektronix自己特有的資料格式還是operator定義好的資料庫格式呢？如果以Tekrtonix自己特殊的資料格式保存，好處是raw data的檔案可以保持在最小，相同硬碟空間因此可以大量儲存資料，但是相對地，如果想看某個時刻所發生的事件詳情，必須將這些raw data以檔案名稱找出來(因為time stamp是raw data的一部分，無法從檔案外觀閱讀)，用專用軟體"倒"(playback)回去重新看一次，在倒資料的同時，利用NSA Analyzer的集成功能，重新統計分析那段時間在各界面(所有包住RNC的界面)所有信令，進而分析出事件的發生原因。

其中這個"倒"資料的過程就有很大的學問，舉例來說，假設要看某事件發生前後共3天的資料，在回顧的時候，必須將這三天的raw data整個"倒"出來，這種資料量是非常大的，光是"倒"資料就要花上數小時，要等全部"倒"到記憶體中，對這三天的統計分析與搜尋的功能才能發揮即時作用，而我懷疑目前的電腦能有如此大的記憶體來暫存如此龐大的資料量，所以很可能是倒一段資料 -> 分析一段 -> 清除記憶，再倒下一段 -> 分析下一段 -> 再清除記憶 ... 直到所有raw data都跑完為止，這種作法在實際找出網路問題之前，需要額外花費多少時間實在難以預估。

接下來談另一種方式。這種方式是raw data被固定時間儲存成大小有限的檔案，例如每10分鐘儲存一筆，然後程式自動將此raw data"倒"進NSA Analyser中，(別忘了這時前線還在繼續打仗，線上的每筆資訊依然繼續被記錄在新的raw data中)，倒入NSA Analyser的raw data，依照operator事先定義的格式，將其中重要的KPI(Key Performance Indicator)取出轉換成資料庫的資料，經過分析過濾後這筆raw data其實已經算被"看過了"，operator可以選擇繼續保存或是乾脆刪除。

這樣處理的優點是可以直接在資料庫平台上做網路效能的統計分析，不再受限於raw data的特殊格式，operator可以聘用程式高手，配合幾種移動網路效能分析理論模型，在這些從網路界面所撈出來的協定資料上大玩統計分析遊戲，雖然要等raw data被儲存以後才開始分析，不算真正的real-time，可是僅僅10分鐘或甚至是1小時的延後分析，對網路整體效能的評比絲毫沒有影響。

第二種方式看起來很優雅，但是缺點仍然有，首先是raw data經過解碼，轉換成人類可以閱讀的ASCII訊息以後，檔案大小會暴增，會有比原本raw data更佔記憶容量的轉換後檔案，塞滿資料庫。唯一節省資料庫空間的作法是先決定那些資料是垃圾，那些資料是珍珠，垃圾不留就可以大幅節省資料庫的容量，這部份有賴移動網路效能分析理論模型的建立與驗證，筆者憂心，模型恐怕永遠跟不上新應用的出現，因為每種新應用多少會改變使用者的習慣，甚至修改到PDU(Protocol Data Unit)的大小，好不容易建立的模型可能又需要修改才能有用。

第二種方式還有很大的挑戰，如前所描述，程式需要同時做好幾件事：
1. STM-1/E1/Ethernet線上資料的定期儲存(不解碼、不分析，只紀錄最底層的所有資料)
2. 將儲存的raw data資料集中送回資料庫
3. 在資料庫端將raw data以特殊程式解碼、過濾、儲存成新的資料庫格式檔案。
這些事情恐怕不容易被區區一部電腦或是架構簡單的程式所掌握。(筆者要再次提醒：本文中154條STM-1，兩條E1與兩個Ethernet的監控也僅是針對一個RNC監控的基本需求而已，如果operator有8個RNC，該如何監控呢？，如果MSC界面也需要監控，那還需要額外的STM-1 port與Ethernet，甚至Giga-Ethernet的配備，又該如何監控呢？複雜度實在很大。)

[結論]
筆者不知道目前Tektronix使用第一種或是第二種方式，也聽說NetHawk在停止probe計畫多年後，最近又開始全網監控的研發，可是無論那家公司的那種產品，相信都脫離不了本文描述的架構，也都面臨相同的困難：監控界面的多樣化與大數量，raw data的處理，以及raw data分析後的統計分析。

這已經不是使用一部電腦、幾張卡片同時在2個Iub，2個Iu界面來demo針對幾十個用戶的call trac就可以交差了事的小工程，當然，筆者承認能做到這點已經很不簡單，可是比起全網監控，還只是一本書的序言而已！

祝福全網監控的技術早日成熟。

070517r2版本