CMMB标准紧急广播服务的研究与应用

1 CMMB标准的紧急广播协议介绍

1．1 CMMB标准介绍

CMMB(China Mobile Multimedia Broadcasting，中国移动多媒体广播)是国内自主研发的第一套面向手机、PDA、MP3、MP4、数码相机、笔记本电脑多种移动终端的系统，利用S波段卫星信号实现“天地”一体覆盖和全国漫游，支持25套电视节目和30套广播节目。2006年10月24日，国家广电总局正式颁布了中国移动多媒体广播(俗称手机电视)行业标准《GY／T 220．1-2006移动多媒体广播第1部分：广播信道的调制》，确定采用我国自主研发的移动多媒体广播传输技术标准STiMi(Satellite- Terrestrial Interactive Multi-service Infrastructure)。

移动多媒体广播系统架构的主要组成部分包括广播前端、广播电视节目和数据业务，通过节目集成平台汇集在一起进行广播。它的传输系统主要包括卫星系统和地面转换网：以卫星覆盖为主，以地面增固网为辅，覆盖全中国。

1．2 国外预警广播系统介绍

美国早在1963年就开始建设紧急广播系统。最初的设计目的是，当国家处于紧急状况时给总统提供一种能迅速通告全民的通信方式。后来在美国联邦通信委员会、联邦应急管理局和国家气象服务三个部门的共同努力下，紧急广播系统逐步完善，并更名为紧急警告系统。EAS除了能实现全国范围的紧急警告外，当地发生紧急情况时也可以使用。

在尼泊尔，广播网络是唯一能够到达边远地区的通信系统。所以尼泊尔广播电台(RNE)和尼泊尔电视台(NTV)共同实现了使用广播网络通信的紧急预警广播系统。

日本气象厅使用了一套地震预警系统，该系统通过探测地震最初小范围的震动(地震纵波)，预测出地震的震中和强度，并向公众发布警报。此系统能预报的信息包括主震和余震发生的时间以及震级。在此系统中就使用了广播预警技术。该系统可以将警报广播叠加到现有的电视台和无线电广播上。

1．3 我国紧急广播的发展

目前，我国紧急预警广播系统还处于起步阶段。2007年11月14日，国家广电总局颁发了《移动多媒体广播第4部分：紧急广播》，并于2007年 11月20日开始实施。这表明我国的紧急广播已经从无到有，并逐步走向正轨。该标准以国务院颁发的《国家突发公共事件总体应急预案》为指导，紧密结合 CMMB的技术体系，能够在移动多媒体中为用户提供及时、迅捷的紧急广播消息，成为我国公共突发事件应急预案的重要组成部分。

1．4 CMMB标准中紧急广播协议的核心技术

《移动多媒体广播第4部分：紧急广播》中规定的紧急广播的发送和接收流程如图1所示。当要发送紧急广播消息时，服务器端先将消息拆分，并段封装为紧急广播数据段。再将紧急广播数据段封装为紧急广播表，最后进行复用和发送。在接收端，按相反的流程进行解析。最终得到具体的紧急广播消息内容，并且在终端将内容展现给用户。本文中实现的客户端的主要功能就是从接收到的复用帧中解析出具体的紧急广播消息，并加以展现。



本客户端解析紧急广播消息是根据《移动多媒体广播第4部分：紧急广播》中规定的紧急广播消息格式进行解析的。紧急广播表就是在0时隙 (MF_ID=0)中表标识为0x10的复用子帧，如图2所示。



紧急广播表中的协议版本号表示紧急广播协议版本。协议最低版本号表示可以兼容的最低版本序号，取值不大于当前协议版本号。网络级别表示紧急广播消息所属网络的网络级别。网络号表示紧急广播消息所属网络的网络号。消息ID标示1个紧急广播消息；允许同时广播多个紧急广播消息，通过网络级别、网络号和消息ID三者唯一确定1个紧急广播消息。当前序号表示当前紧急广播数据段的序号。最后段序号表示最后1个紧急广播数据段的序号。数据长度表示后续紧急广播数据的长度，单位为字节。紧急广播数据承载着拆分后的紧急广播消息，接收终端按“当前段序号”和“最后段序号”字段指示的顺序和数量，拼接具有相同网络级别、网络号和消息ID的所有紧急广播数据即可得到紧急广播消息。本字段的长度N由签名“数据长度”字段指示。

2 EBP客户端在终端上的设计实现

2．1 EBP客户端的设计模型

本EBP(Emergeney Broadcasting Protocol，紧急广播协议)客户端从解析到展现一共分为以下4层，如图3所示。



EBP解析层：主要负责从CMMB协议栈提供的位于0时隙(MF_ID=0)中表标识为0x10的复用子帧中解析出紧急广播消息，并且抽象出相应的数据结构供上层使用。该层可编译成库，在移植时可以不作修改。

EBP本地管理层：主要负责已经接收的紧急广播消息本地相关的管理，如保存、获取已接收的紧急广播消息，删除过期的紧急广播消息等。该层在移植时需要做少量适配相应终端文件系统的工作。

接口抽象层：根据以上2层抽象出供用户UI层使用的统一接口。用户UI层使用的所有接口都通过该层提供，并保持不变，在一定程度上减少了用户UI层的移植工作。用户UI层：主要负责紧急广播消息数据对用户的展现。针对不同的终端，如支持CMMB技术的手机、游戏机、PDA、车载GPS、 MP4，其屏幕大小、分辨率、支持的UI系统等都可能存在差异，所以将本EBP客户端移植到不同终端上时主要工作便是移植该层。抽象接口层、EBP本地管理层、EBP解析层构成了EBP客户端的核心。

2．2 EBP客户端的处理流程

(1)关键消息

①需要CMMB协议栈通知的消息：MSG_EBP_COME。当CMMB协议栈发现有紧急广播消息时，给EBP客户端发送预先定义好的MSG_EBP_COME消息。

②EBP客户端核心给UI发送的消息：a．EBP_RECEIVE_OK，客户端成功接收到新的紧急广播消息，需要UI展现层做相应的展现；b．EBP_RECEIVE_TIMEOUT，客户端接收紧急广播消息超时失败。

(2)关键数据结构

①EBP_Index：紧急广播索引，图3所示的本地管理层通过该数据结构来管理本地保存的紧急广播消息。

②EBP_Table：紧急广播表，对应图2所示的表标识为0x10的控制信息表的格式，图3的解析层中第1次初步解析出的数据用该结构保存。

③EBP_MessageInfo：非触发消息，图3的解析层中解析出的非触发消息用该结构保存。

④EBP_TriggerInfo：触发消息，图3的解析层中解析出的触发消息用该结构保存。

⑤EBF_MsgInfo：紧急广播消息，由于1个紧急广播消息只可能是触发或者非触发中的1种，为了逻辑上和流程上便于处理，该结构联合上述结构3、 4，统一为1个结构。

⑥EBP：对本地管理层暴露的紧急广播消息结构，对EBP_MsgInfo的封装，加上一些上层需要用到的属性域。

⑦EBP_CURSOR：本地管理层定义的数据结构，供接口层使用，通过该结构访问响应的紧急广播消息。

⑧EBP_LangContent：存储非触发紧急广播消息中的语种相关信息。

⑨EBP_Ext：存储非触发紧急广播消息中辅助信息的相关内容。

(3)关键接口

①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)；
功能：创建游标。

⑤CMMB_EBP_CURSOR ebp_get_nextcur(EBP_CURSOR cur)；
功能：获取当前游标cur游标的下一个游标。

⑥int8_t ebp_getebp(EBP_CURSOR cur，EBP_MESSAGE*msg)；
功能：获取cur游标对应的紧急广播消息具体内容填充在输出参数msg中。

⑦static int32_t ebp_checkout(void_t)；
功能：检查索引并删除过期EBP索引及相关文件。

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

⑨int32_t ebp_set_curfreq_ebpupdate(uint32_t cur_freq)；
功能：设置频点cur_freq的紧急广播消息更新序号。

⑩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客户端主要流程分为以下几步：

①本客户端启动后，等待CMMB协议栈发送MSG_EBP_COME消息。收到该消息后，表明当前CMMB网络中有紧急广播消息。EBP客户端使用ebp_receive_data(uint8_t*path)接口接收紧急广播表。该接口同时设置标志位，在其进行紧急广播消息接收的过程中，暂不响应新的MSG_EBP_COME消息。

②用ebp_table_decoder接口对紧急广播表进行解析，得到1组EBP_Table数据。

③用ebp_message_decoder接口对EBP_Table数据进行进一步解析，得到1组EBP_MessageInfo或 EBP_TriggerInfo数据，并检查删除已经接收过的消息，然后将新收到的紧急广播消息封装为EBP结构，并加入到已接收的EBP链上。

④EBP客户端核心层给用户UI层发送EBP_RECEIVE_OK(如前三步失败发送：EBP_RECEIVE_TIMEOUT)消息。

⑤用户UI层根据步骤4发送的消息来做相应的处理。a．如果是EBP_RECEIVE_OK消息，则使用关键接口中的4、5、6接口便可以获取各个紧急广播消息，并在界面上做响应展现。接口4内部会去判断并删除过期的紧急广播消息。

当新接收的紧急广播消息中有紧急程度为1级或者2级的紧急广播时，直接弹出图4所示的界面。新接收的紧急广播消息紧急程度都是3级或者4级时，仅需要给用户1个闪烁提示，由用户选择是否观看紧急程度不太高的广播消息。b．如果是EBP_RECEIVE_TIMEOUT消息，本客户端采用的策略是首先调用ebp_cancel_receive接口，对此次接收失败的环境进行清理，然后过10分钟再次进入步骤②。



(5)减少客户端移植工作量的探讨

嵌入式软件开发与PC软件开发很大的区别是，嵌入式软件设计中必须考虑目标机的差异性，如不同屏幕尺寸、不同分辨率、不同硬件接口、不同GUI系统，甚至不同操作系统。如果本EBP客户端软件的设计中没有考虑便于移植的因素，那么适配这些适用于CMMB技术的手机、游戏机、PDA、车载GPS、 MP4，所需工作量将是非常大的。正是考虑到这个因素，所以本客户端做了以下2方面工作来简化移植工作。

①逻辑与GUI的解耦，也就是图3所展现的核心层与UI层的分离。核心层的职责是管理紧急广播消息的接收、解析、本地管理。UI层的职责是监听核心层发送的EBP_RECEIVE_OK消息，收到该消息就利用接口层提供的3个接口ebp_create_cursor、 ebp_get_nextcur、ebp_getebp，像使用迭代器那样访问接收到的紧急广播数据。这样的好处之一是，在支持相同GUI系统的终端间移植该客户端时，在用户UI层不需要任何的移植工作。好处二是，该层使用EBP_CURSOR(当前版本定义是 typedefvoid_t*CMMB_EBP_CURSOR；)访问顶层数据，如果以后核心层使用的数据结构改变，如“typedef int CMMB_EBP_CURSOR；”，也就是说存储紧急广播消息由链表改为数组，该层也不需要作任何改变。

②核心层中的分层。核心层之所以分为3层的原因是，接口抽象层和EBP解析层在移植的过程中可以保持不变，而本地管理层在移植的过程中可能因为文件系统不同而必须修改具体操作。所以在核心层中将该层抽取出来，在移植客户端核心层时只需要关注该层即可。将EBP解析层与接口层分离的目的是，给用户UI 层仅暴露出接口层的接口以及数据结构，使其关心的内容局限于自己所需要的数据结构，不需要去关心不会直接使用且可能会因为架构上的调整而发生变化的问题。这样如果由第三方来实现用户UI层，可以简化其开发。

在最初的原型设计中，并没有采取这种分层的结构，而是将逻辑与GUI混合在一起，在移植到不同的平台时发现增加的工作量十分大且极易出错。所以决定在移植前采取重构，重构后的结构就是本文所描述的设计架构，后来的移植工作量就很少，也很简单了。本次设计令笔者切身感受到这种逻辑与UI分离的思想带来的好处。

2．3 运行效果截图

本客户端接收过程是后台接收，运行效果如图4所示，该图是在支持CMMB的Windows Mobile5手机上运行，用SuperSnap工具截屏得到的。左边的标签表示接收紧急广播消息的时间，通过标签可以切换右侧内容，观看具体的紧急广播消息。所使用的测试数据为中国数字电视论坛上的CMMBMFS测试样本码流。