CMMB標(biāo)準緊急廣播業(yè)務(wù)的研究與應(yīng)用

CMMB標(biāo)準緊急廣播業(yè)務(wù)的研究與應(yīng)用

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

　　1．1 CMMB標(biāo)準介紹

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

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

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

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

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

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

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

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

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

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

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

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

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

　　2．1 EBP客戶端的設(shè)計模型

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

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

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

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

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

　　(1)關(guān)鍵消息

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

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

　　(2)關(guān)鍵數(shù)據(jù)結(jié)構(gòu)

　?、貳BP_Index：緊急廣播索引，圖3所示的本地管理層通過該數(shù)據(jù)結(jié)構(gòu)來管理本地保存的緊急廣播消息。

　?、贓BP_Table：緊急廣播表，對應(yīng)圖2所示的表標(biāo)識為0x10的控制信息表的格式，圖3的解析層中第1次初步解析出的數(shù)據(jù)用該結(jié)構(gòu)保存。

　?、跡BP_MessageInfo：非觸發(fā)消息，圖3的解析層中解析出的非觸發(fā)消息用該結(jié)構(gòu)保存。

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

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

　?、轊BP：對本地管理層暴露的緊急廣播消息結(jié)構(gòu)，對EBP_MsgInfo的封裝，加上一些上層需要用到的屬性域。

　?、逧BP_CURSOR：本地管理層定義的數(shù)據(jù)結(jié)構(gòu)，供接口層使用，通過該結(jié)構(gòu)訪問響應(yīng)的緊急廣播消息。

　?、郋BP_LangContent：存儲非觸發(fā)緊急廣播消息中的語種相關(guān)信息。

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

　　(3)關(guān)鍵接口

　?、賗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)；
功能：解析緊急廣播具體內(nèi)容。

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

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

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

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

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

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

　?、鈙tatic 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消息。收到該消息后，表明當(dāng)前CMMB網(wǎng)絡(luò)中有緊急廣播消息。EBP客戶端使用 ebp_receive_data(uint8_t*path)接口接收緊急廣播表。該接口同時設(shè)置標(biāo)志位，在其進行緊急廣播消息接收的過程中，暫不響應(yīng)新的MSG_EBP_COME消息。

　?、谟胑bp_table_decoder接口對緊急廣播表進行解析，得到1組EBP_Table數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

　　2．3 運行效果截圖

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

　　結(jié) 語

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

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