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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　⑨EBP_Ext：存儲(chǔ)非觸發(fā)緊急廣播消息中輔助信息的相關(guān)內(nèi)容。

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

　　①int32_t ebp_receive_data(uint8_t*path)；功能：接收緊急廣播表。

　　②static int32_t ebp_table_decoder(uint8_t*bur，int32_t len)；
功能：解析緊急廣播表。

　　③static int32_t ebp_message_decoder(uint8_t* *buf_adr，uint32_t len)；
功能：解析緊急廣播具體內(nèi)容。

　　④CMMB_EBP_CURSOR ebp_create_cursor(void_t)；
功能：創(chuàng)建游標(biāo)。

　　⑤CMMB_EBP_CURSOR ebp_get_nextcur(EBP_CURSOR cur)；
功能：獲取當(dāng)前游標(biāo)cur游標(biāo)的下一個(gè)游標(biāo)。

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

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

　　⑧int8_t ebp_cancel_receive(void_t)；
功能：取消緊急廣播消息接收。

　　⑨int32_t ebp_set_cuRFreq_ebpupdate(uint32_t cur_freq)；
功能：設(shè)置頻點(diǎn)cur_freq的緊急廣播消息更新序號(hào)。

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

　　⑩int32_t ebp_suspend()；
功能：阻塞緊急廣播消息接收線程。

　　⑩int32_t ebp_active(void_t*param)；
功能：激活緊急廣播消息接收線程。

　　(4)主要流程

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

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

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

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

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

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

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

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

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

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

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

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

　　2．3 運(yùn)行效果截圖

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

　　結(jié) 語

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

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