|
1 CMMB標準的緊急廣播協(xié)議介紹 1．1 CMMB標準介紹 CMMB(China Mobile Multimedia Broadcasting，中國移動(dòng)多媒體廣播)是國內自主研發(fā)的第一套面向手機、PDA、MP3、MP4、數碼相機、筆記本電腦多種移動(dòng)終端的系統，利用S波段衛星信號實(shí)現“天地”一體覆蓋和全國漫游，支持25套電視節目和30套廣播節目。2006年10月24日，國家廣電總局正式頒布了中國移動(dòng)多媒體廣播(俗稱(chēng)手機電視)行業(yè)標準《GY／T 220．1-2006移動(dòng)多媒體廣播第1部分：廣播信道的調制》，確定采用我國自主研發(fā)的移動(dòng)多媒體廣播傳輸技術(shù)標準STiMi(Satellite- Terrestrial Interactive Multi-service Infrastructure)。 移動(dòng)多媒體廣播系統架構的主要組成部分包括廣播前端、廣播電視節目和數據業(yè)務(wù)，通過(guò)節目集成平臺匯集在一起進(jìn)行廣播。它的傳輸系統主要包括衛星系統和地面轉換網(wǎng)：以衛星覆蓋為主，以地面增固網(wǎng)為輔，覆蓋全中國。 1．2 國外預警廣播系統介紹 美國早在1963年就開(kāi)始建設緊急廣播系統。最初的設計目的是，當國家處于緊急狀況時(shí)給總統提供一種能迅速通告全民的通信方式。后來(lái)在美國聯(lián)邦通信委員會(huì )、聯(lián)邦應急管理局和國家氣象服務(wù)三個(gè)部門(mén)的共同努力下，緊急廣播系統逐步完善，并更名為緊急警告系統。EAS除了能實(shí)現全國范圍的緊急警告外，當地發(fā)生緊急情況時(shí)也可以使用。 在尼泊爾，廣播網(wǎng)絡(luò )是唯一能夠到達邊遠地區的通信系統。所以尼泊爾廣播電臺(RNE)和尼泊爾電視臺(NTV)共同實(shí)現了使用廣播網(wǎng)絡(luò )通信的緊急預警廣播系統。 日本氣象廳使用了一套地震預警系統，該系統通過(guò)探測地震最初小范圍的震動(dòng)(地震縱波)，預測出地震的震中和強度，并向公眾發(fā)布警報。此系統能預報的信息包括主震和余震發(fā)生的時(shí)間以及震級。在此系統中就使用了廣播預警技術(shù)。該系統可以將警報廣播疊加到現有的電視臺和無(wú)線(xiàn)電廣播上。 1．3 我國緊急廣播的發(fā)展 目前，我國緊急預警廣播系統還處于起步階段。2007年11月14日，國家廣電總局頒發(fā)了《移動(dòng)多媒體廣播第4部分：緊急廣播》，并于2007年 11月20日開(kāi)始實(shí)施。這表明我國的緊急廣播已經(jīng)從無(wú)到有，并逐步走向正軌。該標準以國務(wù)院頒發(fā)的《國家突發(fā)公共事件總體應急預案》為指導，緊密結合 CMMB的技術(shù)體系，能夠在移動(dòng)多媒體中為用戶(hù)提供及時(shí)、迅捷的緊急廣播消息，成為我國公共突發(fā)事件應急預案的重要組成部分。 1．4 CMMB標準中緊急廣播協(xié)議的核心技術(shù) 《移動(dòng)多媒體廣播第4部分：緊急廣播》中規定的緊急廣播的發(fā)送和接收流程如圖1所示。當要發(fā)送緊急廣播消息時(shí)，服務(wù)器端先將消息拆分，并段封裝為緊急廣播數據段。再將緊急廣播數據段封裝為緊急廣播表，最后進(jìn)行復用和發(fā)送。在接收端，按相反的流程進(jìn)行解析。最終得到具體的緊急廣播消息內容，并且在終端將內容展現給用戶(hù)。本文中實(shí)現的客戶(hù)端的主要功能就是從接收到的復用幀中解析出具體的緊急廣播消息，并加以展現。 
本客戶(hù)端解析緊急廣播消息是根據《移動(dòng)多媒體廣播第4部分：緊急廣播》中規定的緊急廣播消息格式進(jìn)行解析的。緊急廣播表就是在0時(shí)隙 (MF_ID=0)中表標識為0x10的復用子幀，如圖2所示。
緊急廣播表中的協(xié)議版本號表示緊急廣播協(xié)議版本。協(xié)議最低版本號表示可以兼容的最低版本序號，取值不大于當前協(xié)議版本號。網(wǎng)絡(luò )級別表示緊急廣播消息所屬網(wǎng)絡(luò )的網(wǎng)絡(luò )級別。網(wǎng)絡(luò )號表示緊急廣播消息所屬網(wǎng)絡(luò )的網(wǎng)絡(luò )號。消息ID標示1個(gè)緊急廣播消息；允許同時(shí)廣播多個(gè)緊急廣播消息，通過(guò)網(wǎng)絡(luò )級別、網(wǎng)絡(luò )號和消息ID三者唯一確定1個(gè)緊急廣播消息。當前序號表示當前緊急廣播數據段的序號。最后段序號表示最后1個(gè)緊急廣播數據段的序號。數據長(cháng)度表示后續緊急廣播數據的長(cháng)度，單位為字節。緊急廣播數據承載著(zhù)拆分后的緊急廣播消息，接收終端按“當前段序號”和“最后段序號”字段指示的順序和數量，拼接具有相同網(wǎng)絡(luò )級別、網(wǎng)絡(luò )號和消息ID的所有緊急廣播數據即可得到緊急廣播消息。本字段的長(cháng)度N由簽名“數據長(cháng)度”字段指示。 2 EBP客戶(hù)端在終端上的設計實(shí)現 2．1 EBP客戶(hù)端的設計模型 本EBP(Emergeney Broadcasting Protocol，緊急廣播協(xié)議)客戶(hù)端從解析到展現一共分為以下4層，如圖3所示。
EBP解析層：主要負責從CMMB協(xié)議棧提供的位于0時(shí)隙(MF_ID=0)中表標識為0x10的復用子幀中解析出緊急廣播消息，并且抽象出相應的數據結構供上層使用。該層可編譯成庫，在移植時(shí)可以不作修改。 EBP本地管理層：主要負責已經(jīng)接收的緊急廣播消息本地相關(guān)的管理，如保存、獲取已接收的緊急廣播消息，刪除過(guò)期的緊急廣播消息等。該層在移植時(shí)需要做少量適配相應終端文件系統的工作。 接口抽象層：根據以上2層抽象出供用戶(hù)UI層使用的統一接口。用戶(hù)UI層使用的所有接口都通過(guò)該層提供，并保持不變，在一定程度上減少了用戶(hù)UI層的移植工作。用戶(hù)UI層：主要負責緊急廣播消息數據對用戶(hù)的展現。針對不同的終端，如支持CMMB技術(shù)的手機、游戲機、PDA、車(chē)載GPS、 MP4，其屏幕大小、分辨率、支持的UI系統等都可能存在差異，所以將本EBP客戶(hù)端移植到不同終端上時(shí)主要工作便是移植該層。抽象接口層、EBP本地管理層、EBP解析層構成了EBP客戶(hù)端的核心。 2．2 EBP客戶(hù)端的處理流程 (1)關(guān)鍵消息 ①需要CMMB協(xié)議棧通知的消息：MSG_EBP_COME。當CMMB協(xié)議棧發(fā)現有緊急廣播消息時(shí)，給EBP客戶(hù)端發(fā)送預先定義好的MSG_EBP_COME消息。 ②EBP客戶(hù)端核心給UI發(fā)送的消息：a．EBP_RECEIVE_OK，客戶(hù)端成功接收到新的緊急廣播消息，需要UI展現層做相應的展現；b．EBP_RECEIVE_TIMEOUT，客戶(hù)端接收緊急廣播消息超時(shí)失敗。 (2)關(guān)鍵數據結構 ①EBP_Index：緊急廣播索引，圖3所示的本地管理層通過(guò)該數據結構來(lái)管理本地保存的緊急廣播消息。 ②EBP_Table：緊急廣播表，對應圖2所示的表標識為0x10的控制信息表的格式，圖3的解析層中第1次初步解析出的數據用該結構保存。 ③EBP_MessageInfo：非觸發(fā)消息，圖3的解析層中解析出的非觸發(fā)消息用該結構保存。 ④EBP_TriggerInfo：觸發(fā)消息，圖3的解析層中解析出的觸發(fā)消息用該結構保存。 ⑤EBF_MsgInfo：緊急廣播消息，由于1個(gè)緊急廣播消息只可能是觸發(fā)或者非觸發(fā)中的1種，為了邏輯上和流程上便于處理，該結構聯(lián)合上述結構3、 4，統一為1個(gè)結構。 ⑥EBP：對本地管理層暴露的緊急廣播消息結構，對EBP_MsgInfo的封裝，加上一些上層需要用到的屬性域。 ⑦EBP_CURSOR：本地管理層定義的數據結構，供接口層使用，通過(guò)該結構訪(fǎng)問(wèn)響應的緊急廣播消息。 ⑧EBP_LangContent：存儲非觸發(fā)緊急廣播消息中的語(yǔ)種相關(guān)信息。 ⑨EBP_Ext：存儲非觸發(fā)緊急廣播消息中輔助信息的相關(guān)內容。 (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)； 功能：解析緊急廣播具體內容。 ④CMMB_EBP_CURSOR ebp_create_cursor(void_t)； 功能：創(chuàng )建游標。 ⑤CMMB_EBP_CURSOR ebp_get_nextcur(EBP_CURSOR cur)； 功能：獲取當前游標cur游標的下一個(gè)游標。 ⑥int8_t ebp_getebp(EBP_CURSOR cur，EBP_MESSAGE*msg)； 功能：獲取cur游標對應的緊急廣播消息具體內容填充在輸出參數msg中。 ⑦static int32_t ebp_checkout(void_t)； 功能：檢查索引并刪除過(guò)期EBP索引及相關(guān)文件。 ⑧int8_t ebp_cancel_receive(void_t)； 功能：取消緊急廣播消息接收。 ⑨int32_t ebp_set_curfreq_ebpupdate(uint32_t cur_freq)； 功能：設置頻點(diǎn)cur_freq的緊急廣播消息更新序號。 ⑩static int8_t ebp_read_sared_ebp(EBP*ebp，EBP_Index*index) 功能：讀取本地保存的緊急廣播。 ⑩int32_t ebp_suspend()； 功能：阻塞緊急廣播消息接收線(xiàn)程。 ⑩int32_t ebp_active(void_t*param)； 功能：激活緊急廣播消息接收線(xiàn)程。 (4)主要流程 本EBP客戶(hù)端主要流程分為以下幾步： ①本客戶(hù)端啟動(dòng)后，等待CMMB協(xié)議棧發(fā)送MSG_EBP_COME消息。收到該消息后，表明當前CMMB網(wǎng)絡(luò )中有緊急廣播消息。EBP客戶(hù)端使用ebp_receive_data(uint8_t*path)接口接收緊急廣播表。該接口同時(shí)設置標志位，在其進(jìn)行緊急廣播消息接收的過(guò)程中，暫不響應新的MSG_EBP_COME消息。 ②用ebp_table_decoder接口對緊急廣播表進(jìn)行解析，得到1組EBP_Table數據。 ③用ebp_message_decoder接口對EBP_Table數據進(jìn)行進(jìn)一步解析，得到1組EBP_MessageInfo或 EBP_TriggerInfo數據，并檢查刪除已經(jīng)接收過(guò)的消息，然后將新收到的緊急廣播消息封裝為EBP結構，并加入到已接收的EBP鏈上。 ④EBP客戶(hù)端核心層給用戶(hù)UI層發(fā)送EBP_RECEIVE_OK(如前三步失敗發(fā)送：EBP_RECEIVE_TIMEOUT)消息。 ⑤用戶(hù)UI層根據步驟4發(fā)送的消息來(lái)做相應的處理。a．如果是EBP_RECEIVE_OK消息，則使用關(guān)鍵接口中的4、5、6接口便可以獲取各個(gè)緊急廣播消息，并在界面上做響應展現。接口4內部會(huì )去判斷并刪除過(guò)期的緊急廣播消息。 當新接收的緊急廣播消息中有緊急程度為1級或者2級的緊急廣播時(shí)，直接彈出圖4所示的界面。新接收的緊急廣播消息緊急程度都是3級或者4級時(shí)，僅需要給用戶(hù)1個(gè)閃爍提示，由用戶(hù)選擇是否觀(guān)看緊急程度不太高的廣播消息。b．如果是EBP_RECEIVE_TIMEOUT消息，本客戶(hù)端采用的策略是首先調用ebp_cancel_receive接口，對此次接收失敗的環(huán)境進(jìn)行清理，然后過(guò)10分鐘再次進(jìn)入步驟②。
(5)減少客戶(hù)端移植工作量的探討 嵌入式軟件開(kāi)發(fā)與PC軟件開(kāi)發(fā)很大的區別是，嵌入式軟件設計中必須考慮目標機的差異性，如不同屏幕尺寸、不同分辨率、不同硬件接口、不同GUI系統，甚至不同操作系統。如果本EBP客戶(hù)端軟件的設計中沒(méi)有考慮便于移植的因素，那么適配這些適用于CMMB技術(shù)的手機、游戲機、PDA、車(chē)載GPS、 MP4，所需工作量將是非常大的。正是考慮到這個(gè)因素，所以本客戶(hù)端做了以下2方面工作來(lái)簡(jiǎn)化移植工作。 ①邏輯與GUI的解耦，也就是圖3所展現的核心層與UI層的分離。核心層的職責是管理緊急廣播消息的接收、解析、本地管理。UI層的職責是監聽(tīng)核心層發(fā)送的EBP_RECEIVE_OK消息，收到該消息就利用接口層提供的3個(gè)接口ebp_create_cursor、 ebp_get_nextcur、ebp_getebp，像使用迭代器那樣訪(fǎng)問(wèn)接收到的緊急廣播數據。這樣的好處之一是，在支持相同GUI系統的終端間移植該客戶(hù)端時(shí)，在用戶(hù)UI層不需要任何的移植工作。好處二是，該層使用EBP_CURSOR(當前版本定義是 typedefvoid_t*CMMB_EBP_CURSOR；)訪(fǎng)問(wèn)頂層數據，如果以后核心層使用的數據結構改變，如“typedef int CMMB_EBP_CURSOR；”，也就是說(shuō)存儲緊急廣播消息由鏈表改為數組，該層也不需要作任何改變。 ②核心層中的分層。核心層之所以分為3層的原因是，接口抽象層和EBP解析層在移植的過(guò)程中可以保持不變，而本地管理層在移植的過(guò)程中可能因為文件系統不同而必須修改具體操作。所以在核心層中將該層抽取出來(lái)，在移植客戶(hù)端核心層時(shí)只需要關(guān)注該層即可。將EBP解析層與接口層分離的目的是，給用戶(hù)UI 層僅暴露出接口層的接口以及數據結構，使其關(guān)心的內容局限于自己所需要的數據結構，不需要去關(guān)心不會(huì )直接使用且可能會(huì )因為架構上的調整而發(fā)生變化的問(wèn)題。這樣如果由第三方來(lái)實(shí)現用戶(hù)UI層，可以簡(jiǎn)化其開(kāi)發(fā)。 在最初的原型設計中，并沒(méi)有采取這種分層的結構，而是將邏輯與GUI混合在一起，在移植到不同的平臺時(shí)發(fā)現增加的工作量十分大且極易出錯。所以決定在移植前采取重構，重構后的結構就是本文所描述的設計架構，后來(lái)的移植工作量就很少，也很簡(jiǎn)單了。本次設計令筆者切身感受到這種邏輯與UI分離的思想帶來(lái)的好處。 2．3 運行效果截圖 本客戶(hù)端接收過(guò)程是后臺接收，運行效果如圖4所示，該圖是在支持CMMB的Windows Mobile5手機上運行，用SuperSnap工具截屏得到的。左邊的標簽表示接收緊急廣播消息的時(shí)間，通過(guò)標簽可以切換右側內容，觀(guān)看具體的緊急廣播消息。所使用的測試數據為中國數字電視論壇上的CMMBMFS測試樣本碼流。 結語(yǔ) 以上的設計和實(shí)現充分考慮了空間和效率這兩大要素，通過(guò)和市面上其他產(chǎn)品進(jìn)行比較，該系統能夠在存儲空間更小、處理速度更慢的移動(dòng)設備上流暢地運行，取得了令人滿(mǎn)意的效果。 本設計中的EBP客戶(hù)端程序能夠成功接收CMMB網(wǎng)絡(luò )中多個(gè)頻點(diǎn)發(fā)送的緊急廣播消息，并且客戶(hù)端具有一定的鍵壯性，可以通過(guò)較少的移植工作量使其工作在適用于CMMB技術(shù)的手機、游戲機、PDA、車(chē)載GPS、MP4，達到了預期目的。相信隨著(zhù)CMMB網(wǎng)絡(luò )的日漸成熟，CMMB標準的緊急廣播應用必然會(huì )在我國災害預警中起到重要作用。 參考文獻 1. 孔彬.亞太地區緊急廣播系統發(fā)展現狀調查.廣播與電視技術(shù),2008(5):55-59. 2. 解偉.移動(dòng)多媒體廣播-復用[DB/OL].(2007-11-19).http://124.42.5.8/biaozhun/index.asp. 3. 房磊.日本、尼泊爾緊急預警廣播系統探究[J].廣播與電視技術(shù),2008(7):62-66. 4. 秦勇.移動(dòng)多媒體廣播--緊急廣播[DB/OL].(2007-11-19).http://124.42.5.8/biaozhun /index.asp. 5. 陳德林.緊急廣播概況及我國開(kāi)展緊急廣播業(yè)務(wù)的相關(guān)建議[J].廣播與電視技術(shù),2008(1):61-64. 6. 楊慶華.移動(dòng)多媒體廣播--廣播信道的調制[DB/OL].(2007-11-19).http://124.42.5.8/biaozhun /index.asp. 作者：電子科技大學(xué) 左崗 羅蕾 來(lái)源：《單片機與嵌入式系統應用》 2009（10） |
