2007/05/23

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版本

2007/05/20

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

2007/05/18

自問自答 - 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版本

2007/05/16

無責任雜記(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版本