CMMB標準緊急廣播業(yè)務的研究與應用

　　1 CMMB標準的緊急廣播協(xié)議介紹

　　1．1 CMMB標準介紹

　　CMMB(China Mobile Multimedia BroADCasting，中國移動多媒體廣播)是國內自主研發(fā)的第一套面向手機、PDA、MP3、MP4、數(shù)碼相機、筆記本電腦多種移動終端的系統(tǒng)，利用S波段衛(wèi)星信號實現(xiàn)“天地”一體覆蓋和全國漫游，支持25套電視節(jié)目和30套廣播節(jié)目。2006年10月24日，國家廣電總局正式頒布了中國移動多媒體廣播(俗稱手機電視)行業(yè)標準《GY／T 220．1-2006移動多媒體廣播第1部分：廣播信道的調制》，確定采用我國自主研發(fā)的移動多媒體廣播傳輸技術標準STiMi(Satellite- Terrestrial Interactive Multi-service Infrastructure)。

　　移動多媒體廣播系統(tǒng)架構的主要組成部分包括廣播前端、廣播電視節(jié)目和數(shù)據(jù)業(yè)務，通過節(jié)目集成平臺匯集在一起進行廣播。它的傳輸系統(tǒng)主要包括衛(wèi)星系統(tǒng)和地面轉換網：以衛(wèi)星覆蓋為主，以地面增固網為輔，覆蓋全中國。

　　1．2 國外預警廣播系統(tǒng)介紹

　　美國早在1963年就開始建設緊急廣播系統(tǒng)。最初的設計目的是，當國家處于緊急狀況時給總統(tǒng)提供一種能迅速通告全民的通信方式。后來在美國聯(lián)邦通信委員會、聯(lián)邦應急管理局和國家氣象服務三個部門的共同努力下，緊急廣播系統(tǒng)逐步完善，并更名為緊急警告系統(tǒng)。EAS除了能實現(xiàn)全國范圍的緊急警告外，當?shù)匕l(fā)生緊急情況時也可以使用。

　　在尼泊爾，廣播網絡是唯一能夠到達邊遠地區(qū)的通信系統(tǒng)。所以尼泊爾廣播電臺(RNE)和尼泊爾電視臺(NTV)共同實現(xiàn)了使用廣播網絡通信的緊急預警廣播系統(tǒng)。

　　日本氣象廳使用了一套地震預警系統(tǒng)，該系統(tǒng)通過探測地震最初小范圍的震動(地震縱波)，預測出地震的震中和強度，并向公眾發(fā)布警報。此系統(tǒng)能預報的信息包括主震和余震發(fā)生的時間以及震級。在此系統(tǒng)中就使用了廣播預警技術。該系統(tǒng)可以將警報廣播疊加到現(xiàn)有的電視臺和無線電廣播上。

　　1．3 我國緊急廣播的發(fā)展

　　目前，我國緊急預警廣播系統(tǒng)還處于起步階段。2007年11月14日，國家廣電總局頒發(fā)了《移動多媒體廣播第4部分：緊急廣播》，并于2007年11月 20日開始實施。這表明我國的緊急廣播已經從無到有，并逐步走向正軌。該標準以國務院頒發(fā)的《國家突發(fā)公共事件總體應急預案》為指導，緊密結合CMMB的技術體系，能夠在移動多媒體中為用戶提供及時、迅捷的緊急廣播消息，成為我國公共突發(fā)事件應急預案的重要組成部分。

　　1．4 CMMB標準中緊急廣播協(xié)議的核心技術

　　《移動多媒體廣播第4部分：緊急廣播》中規(guī)定的緊急廣播的發(fā)送和接收流程如圖1所示。當要發(fā)送緊急廣播消息時，服務器端先將消息拆分，并段封裝為緊急廣播數(shù)據(jù)段。再將緊急廣播數(shù)據(jù)段封裝為緊急廣播表，最后進行復用和發(fā)送。在接收端，按相反的流程進行解析。最終得到具體的緊急廣播消息內容，并且在終端將內容展現(xiàn)給用戶。本文中實現(xiàn)的客戶端的主要功能就是從接收到的復用幀中解析出具體的緊急廣播消息，并加以展現(xiàn)。

　　本客戶端解析緊急廣播消息是根據(jù)《移動多媒體廣播第4部分：緊急廣播》中規(guī)定的緊急廣播消息格式進行解析的。緊急廣播表就是在0時隙(MF_ID=0)中表標識為0x10的復用子幀，如圖2所示。

　　緊急廣播表中的協(xié)議版本號表示緊急廣播協(xié)議版本。協(xié)議最低版本號表示可以兼容的最低版本序號，取值不大于當前協(xié)議版本號。網絡級別表示緊急廣播消息所屬網絡的網絡級別。網絡號表示緊急廣播消息所屬網絡的網絡號。消息ID標示1個緊急廣播消息；允許同時廣播多個緊急廣播消息，通過網絡級別、網絡號和消息ID 三者唯一確定1個緊急廣播消息。當前序號表示當前緊急廣播數(shù)據(jù)段的序號。最后段序號表示最后1個緊急廣播數(shù)據(jù)段的序號。數(shù)據(jù)長度表示后續(xù)緊急廣播數(shù)據(jù)的長度，單位為字節(jié)。緊急廣播數(shù)據(jù)承載著拆分后的緊急廣播消息，接收終端按“當前段序號”和“最后段序號”字段指示的順序和數(shù)量，拼接具有相同網絡級別、網絡號和消息ID的所有緊急廣播數(shù)據(jù)即可得到緊急廣播消息。本字段的長度N由簽名“數(shù)據(jù)長度”字段指示。

　　2 EBP客戶端在終端上的設計實現(xiàn)

　　2．1 EBP客戶端的設計模型

　　本EBP(Emergeney Broadcasting Protocol，緊急廣播協(xié)議)客戶端從解析到展現(xiàn)一共分為以下4層，如圖3所示。

EBP解析層：主要負責從CMMB協(xié)議棧提供的位于0時隙(MF_ID=0)中表標識為0x10的復用子幀中解析出緊急廣播消息，并且抽象出相應的數(shù)據(jù)結構供上層使用。該層可編譯成庫，在移植時可以不作修改。

　　EBP本地管理層：主要負責已經接收的緊急廣播消息本地相關的管理，如保存、獲取已接收的緊急廣播消息，刪除過期的緊急廣播消息等。該層在移植時需要做少量適配相應終端文件系統(tǒng)的工作。

　　接口抽象層：根據(jù)以上2層抽象出供用戶UI層使用的統(tǒng)一接口。用戶UI層使用的所有接口都通過該層提供，并保持不變，在一定程度上減少了用戶UI層的移植工作。用戶UI層：主要負責緊急廣播消息數(shù)據(jù)對用戶的展現(xiàn)。針對不同的終端，如支持CMMB技術的手機、游戲機、PDA、車載GPS、MP4，其屏幕大小、分辨率、支持的UI系統(tǒng)等都可能存在差異，所以將本EBP客戶端移植到不同終端上時主要工作便是移植該層。抽象接口層、EBP本地管理層、EBP解析層構成了EBP客戶端的核心。

　　2．2 EBP客戶端的處理流程

　　(1)關鍵消息

　?、傩枰狢MMB協(xié)議棧通知的消息：MSG_EBP_COME。當CMMB協(xié)議棧發(fā)現(xiàn)有緊急廣播消息時，給EBP客戶端發(fā)送預先定義好的MSG_EBP_COME消息。

　　②EBP客戶端核心給UI發(fā)送的消息：a．EBP_RECEIVE_OK，客戶端成功接收到新的緊急廣播消息，需要UI展現(xiàn)層做相應的展現(xiàn)；b．EBP_RECEIVE_TIMEOUT，客戶端接收緊急廣播消息超時失敗。

　　(2)關鍵數(shù)據(jù)結構

　　①EBP_Index：緊急廣播索引，圖3所示的本地管理層通過該數(shù)據(jù)結構來管理本地保存的緊急廣播消息。

　　②EBP_Table：緊急廣播表，對應圖2所示的表標識為0x10的控制信息表的格式，圖3的解析層中第1次初步解析出的數(shù)據(jù)用該結構保存。

　　③EBP_MessageInfo：非觸發(fā)消息，圖3的解析層中解析出的非觸發(fā)消息用該結構保存。

　?、蹺BP_TriggerInfo：觸發(fā)消息，圖3的解析層中解析出的觸發(fā)消息用該結構保存。

　?、軪BF_MsgInfo：緊急廣播消息，由于1個緊急廣播消息只可能是觸發(fā)或者非觸發(fā)中的1種，為了邏輯上和流程上便于處理，該結構聯(lián)合上述結構3、4，統(tǒng)一為1個結構。

　　⑥EBP：對本地管理層暴露的緊急廣播消息結構，對EBP_MsgInfo的封裝，加上一些上層需要用到的屬性域。

　　⑦EBP_CURSOR：本地管理層定義的數(shù)據(jù)結構，供接口層使用，通過該結構訪問響應的緊急廣播消息。

　　⑧EBP_LangContent：存儲非觸發(fā)緊急廣播消息中的語種相關信息。

　?、酔BP_Ext：存儲非觸發(fā)緊急廣播消息中輔助信息的相關內容。

　　(3)關鍵接口

　?、賗nt32_t ebp_receive_data(uint8_t*path)；功能：接收緊急廣播表。

　?、趕tatic int32_t ebp_table_decoder(uint8_t*bur，int32_t len)；
功能：解析緊急廣播表。

　?、踫tatic int32_t ebp_message_decoder(uint8_t* *buf_adr，uint32_t len)；
功能：解析緊急廣播具體內容。

　?、蹸MMB_EBP_CURSOR ebp_create_cursor(void_t)；
功能：創(chuàng)建游標。

　?、軨MMB_EBP_CURSOR ebp_get_nextcur(EBP_CURSOR cur)；
功能：獲取當前游標cur游標的下一個游標。

　　⑥int8_t ebp_getebp(EBP_CURSOR cur，EBP_MESSAGE*msg)；
功能：獲取cur游標對應的緊急廣播消息具體內容填充在輸出參數(shù)msg中。

　?、遱tatic int32_t ebp_checkout(void_t)；
功能：檢查索引并刪除過期EBP索引及相關文件。

　?、鄆nt8_t ebp_cancel_receive(void_t)；
功能：取消緊急廣播消息接收。

　?、醝nt32_t ebp_set_cuRFreq_ebpupdate(uint32_t cur_freq)；
功能：設置頻點cur_freq的緊急廣播消息更新序號。

　　⑩static int8_t ebp_read_sared_ebp(EBP*ebp，EBP_Index*index)
功能：讀取本地保存的緊急廣播。

　?、鈏nt32_t ebp_suspend()；
功能：阻塞緊急廣播消息接收線程。

　?、鈏nt32_t ebp_active(void_t*param)；
功能：激活緊急廣播消息接收線程。

　　(4)主要流程

　　本EBP客戶端主要流程分為以下幾步：

①本客戶端啟動后，等待CMMB協(xié)議棧發(fā)送MSG_EBP_COME消息。收到該消息后，表明當前CMMB網絡中有緊急廣播消息。EBP客戶端使用 ebp_receive_data(uint8_t*path)接口接收緊急廣播表。該接口同時設置標志位，在其進行緊急廣播消息接收的過程中，暫不響應新的MSG_EBP_COME消息。

　　②用ebp_table_decoder接口對緊急廣播表進行解析，得到1組EBP_Table數(shù)據(jù)。

　?、塾胑bp_message_decoder接口對EBP_Table數(shù)據(jù)進行進一步解析，得到1組EBP_MessageInfo或 EBP_TriggerInfo數(shù)據(jù)，并檢查刪除已經接收過的消息，然后將新收到的緊急廣播消息封裝為EBP結構，并加入到已接收的EBP鏈上。

　?、蹺BP客戶端核心層給用戶UI層發(fā)送EBP_RECEIVE_OK(如前三步失敗發(fā)送：EBP_RECEIVE_TIMEOUT)消息。

　?、萦脩鬠I層根據(jù)步驟4發(fā)送的消息來做相應的處理。a．如果是EBP_RECEIVE_OK消息，則使用關鍵接口中的4、5、6接口便可以獲取各個緊急廣播消息，并在界面上做響應展現(xiàn)。接口4內部會去判斷并刪除過期的緊急廣播消息。

　　當新接收的緊急廣播消息中有緊急程度為1級或者2級的緊急廣播時，直接彈出圖4所示的界面。新接收的緊急廣播消息緊急程度都是3級或者4級時，僅需要給用戶1個閃爍提示，由用戶選擇是否觀看緊急程度不太高的廣播消息。b．如果是EBP_RECEIVE_TIMEOUT消息，本客戶端采用的策略是首先調用 ebp_cancel_receive接口，對此次接收失敗的環(huán)境進行清理，然后過10分鐘再次進入步驟②。

　　(5)減少客戶端移植工作量的探討

　　嵌入式軟件開發(fā)與PC軟件開發(fā)很大的區(qū)別是，嵌入式軟件設計中必須考慮目標機的差異性，如不同屏幕尺寸、不同分辨率、不同硬件接口、不同GUI系統(tǒng)，甚至不同操作系統(tǒng)。如果本EBP客戶端軟件的設計中沒有考慮便于移植的因素，那么適配這些適用于CMMB技術的手機、游戲機、PDA、車載GPS、MP4，所需工作量將是非常大的。正是考慮到這個因素，所以本客戶端做了以下2方面工作來簡化移植工作。

　?、龠壿嬇cGUI的解耦，也就是圖3所展現(xiàn)的核心層與UI層的分離。核心層的職責是管理緊急廣播消息的接收、解析、本地管理。UI層的職責是監(jiān)聽核心層發(fā)送的EBP_RECEIVE_OK消息，收到該消息就利用接口層提供的3個接口ebp_create_cursor、ebp_get_nextcur、 ebp_getebp，像使用迭代器那樣訪問接收到的緊急廣播數(shù)據(jù)。這樣的好處之一是，在支持相同GUI系統(tǒng)的終端間移植該客戶端時，在用戶UI層不需要任何的移植工作。好處二是，該層使用EBP_CURSOR(當前版本定義是typedefvoid_t*CMMB_EBP_CURSOR；)訪問頂層數(shù)據(jù)，如果以后核心層使用的數(shù)據(jù)結構改變，如“typedef int CMMB_EBP_CURSOR；”，也就是說存儲緊急廣播消息由鏈表改為數(shù)組，該層也不需要作任何改變。

　?、诤诵膶又械姆謱印：诵膶又苑譃?層的原因是，接口抽象層和EBP解析層在移植的過程中可以保持不變，而本地管理層在移植的過程中可能因為文件系統(tǒng)不同而必須修改具體操作。所以在核心層中將該層抽取出來，在移植客戶端核心層時只需要關注該層即可。將EBP解析層與接口層分離的目的是，給用戶UI層僅暴露出接口層的接口以及數(shù)據(jù)結構，使其關心的內容局限于自己所需要的數(shù)據(jù)結構，不需要去關心不會直接使用且可能會因為架構上的調整而發(fā)生變化的問題。這樣如果由第三方來實現(xiàn)用戶UI層，可以簡化其開發(fā)。

　　在最初的原型設計中，并沒有采取這種分層的結構，而是將邏輯與GUI混合在一起，在移植到不同的平臺時發(fā)現(xiàn)增加的工作量十分大且極易出錯。所以決定在移植前采取重構，重構后的結構就是本文所描述的設計架構，后來的移植工作量就很少，也很簡單了。本次設計令筆者切身感受到這種邏輯與UI分離的思想帶來的好處。

　　2．3 運行效果截圖

　　本客戶端接收過程是后臺接收，運行效果如圖4所示，該圖是在支持CMMB的Windows Mobile5手機上運行，用SuperSnap工具截屏得到的。左邊的標簽表示接收緊急廣播消息的時間，通過標簽可以切換右側內容，觀看具體的緊急廣播消息。所使用的測試數(shù)據(jù)為中國數(shù)字電視論壇上的CMMBMFS測試樣本碼流。

　　結 語

　　以上的設計和實現(xiàn)充分考慮了空間和效率這兩大要素，通過和市面上其他產品進行比較，該系統(tǒng)能夠在存儲空間更小、處理速度更慢的移動設備上流暢地運行，取得了令人滿意的效果。

　　本設計中的EBP客戶端程序能夠成功接收CMMB網絡中多個頻點發(fā)送的緊急廣播消息，并且客戶端具有一定的鍵壯性，可以通過較少的移植工作量使其工作在適用于CMMB技術的手機、游戲機、PDA、車載GPS、MP4，達到了預期目的。相信隨著CMMB網絡的日漸成熟，CMMB標準的緊急廣播應用必然會在我國災害預警中起到重要作用。