CN105812079A

CN105812079A - 一种应急广播状态上报、接收方法及装置

Info

Publication number: CN105812079A
Application number: CN201610131328.6A
Authority: CN
Inventors: 焦朋伟; 樊永永; 宋承岩; 李晓伟; 边雁; 张天若
Original assignee: Sumavision Technologies Co Ltd
Current assignee: Sumavision Technologies Co Ltd
Priority date: 2016-03-08
Filing date: 2016-03-08
Publication date: 2016-07-27

Abstract

本发明公开了一种应急广播状态上报、接收方法及装置，包括：接收应急广播平台发送的指令，并转发至各应急广播设备，所述应急广播设备是所述应急广播平台下属的各应急广播设备；接收各应急广播设备上报的应急广播状态报告，并转发至应急广播平台；其中，在进行接收及转发时，是通过传输控制协议通道进行接收及转发的。采用本发明能够避免现有回传系统中各级应急广播平台独立申请固定IP地址的浪费问题，极大缩减应急广播成本。

Description

一种应急广播状态上报、接收方法及装置

技术领域

本发明涉及应急广播技术领域，特别涉及一种应急广播状态上报、接收方法及装置。

背景技术

应急广播系统通常是由应急广播平台(也即为应急广播网管)及其集中管理的下属应急广播设备组成，工作人员由平台发送信息给现场可发声音柱、收扩机等设备，从而通知现场群众灾害信息；与此同时，作为上游网管，平台也必须知道设备运行的实时状态，以及时纠正状态错误的设备，而该实时状态主要依赖设备的主动回传上报。

图1为现有回传方案示意图，如图所示，由于各类现实因素，如设备环境网络状态恶劣，应急广播方案限制，移动运营商对相对有限IP地址的保护等，现有设备状态回传方案大多基于平台服务器固定外网IP地址，设备插入SIM(SubscriberIdentityModule，用户识别模块)卡并使用其附带的GPRS(GeneralPacketRadioService，通用分组无线业务)网络进行指向性报告自身状态数据。例如图1中所示，归属平台A的设备向平台A使用外网IP地址回传实时状态，归属平台B的设备向平台B使用外网IP地址回传实时状态。

该方案也带来了一个现实问题，假如X市有10个县，每个县部署一套应急广播系统，则X市需要向移动运营商购买10个固定IP地址并按期交付费用，显然，现行的回传方案成本相当高昂。

另外，除设备上行回传状态的高昂成本之外，其平台下行指令的维护成本及复杂度也很高。即使暂不考虑固定IP地址成本，假设已经存在固定IP地址，设备上行数据有目的的发往该IP地址即可；但安装SIM卡的设备并不具备固定IP地址，如果平台需要通过GPRS发送指令给设备，需要设备通过GPRS不断发送包含自身标识及实时IP地址的报文给平台，平台方根据该报文解析结果存储该标识和动态IP地址的映射，找到相应设备进行指令的下发。每一套应急广播系统都需要存储辖下设备标识及其动态IP地址的映射信息，而这无疑增加应急广播系统服务器的通信及数据库负担。

最后，传统回传方案并不能应用在平台服务器是移动设备的情况，而在某些情况下，平台服务器并不具备拥有固定IP地址的条件。这时，传统固定IP地址回传方案则束手无策。

综上，由于现有设备状态回传方案都基于平台服务器固定外网IP地址，设备插入SIM卡并使用其附带的GPRS网络进行指向性报告自身状态数据。这样导致现有技术的不足在于：每一个应急广播平台都需要一个固定的外网IP地址为其服务，大大增加了整个应急广播系统的成本，并且适用的场合也非常局限。

发明内容

本发明提供了一种应急广播状态上报、接收方法及装置，用以解决在应急广播系统中，各级应急广播平台需要独立申请固定IP地址才能进行应急广播状态报告上报的问题。

本发明实施例中提供了一种应急广播状态上报方法，包括：

接收应急广播平台发送的指令，并转发至各应急广播设备，所述应急广播设备是所述应急广播平台下属的各应急广播设备；

接收各应急广播设备上报的应急广播状态报告，并转发至应急广播平台；

其中，在进行接收及转发时，是通过TCP通道进行接收及转发的。

本发明实施例中提供了一种应急广播状态上报方法，包括：

在应急广播设备上接收网络侧设备发送的指令，并执行该指令，所述指令是由应急广播平台经由网络侧设备发送的，所述应急广播设备是所述应急广播平台下属的应急广播设备；

向网络侧设备上报应急广播状态报告，所述应急广播状态报告将由网络侧设备发送至应急广播平台；

其中，在进行接收及上报时，是通过TCP通道进行接收及上报的。

本发明实施例中提供了一种接收应急广播状态的方法，包括：

向网络侧设备发送指令，并由应急广播设备执行，所述指令是由应急广播平台生成的，所述应急广播设备是所述应急广播平台下属的应急广播设备；

在应急广播平台上接收网络侧设备发送的应急广播状态报告，所述应急广播状态报告是由应急广播设备经由网络侧设备发送至应急广播平台的；

其中，在进行接收及发送时，是通过TCP通道进行接收及转发的。

本发明实施例中提供了一种应急广播状态上报装置，包括：

通道模块，用于建立TCP通道；

转发模块，用于接收应急广播平台发送的指令，并转发至各应急广播设备，所述应急广播设备是所述应急广播平台下属的各应急广播设备；接收各应急广播设备上报的应急广播状态报告，并转发至应急广播平台；其中，在进行接收及转发时，是通过TCP通道进行接收及转发的。

本发明实施例中提供了一种应急广播状态上报装置，包括：

指令接收模块，用于在应急广播设备上接收网络侧设备发送的指令，并执行该指令，所述指令是由应急广播平台经由网络侧设备发送的，所述应急广播设备是所述应急广播平台下属的应急广播设备；

报告发送模块，用于向网络侧设备上报应急广播状态报告，所述应急广播状态报告将由网络侧设备发送至应急广播平台；

本发明实施例中提供了一种接收应急广播状态的装置，包括：

指令发送模块，用于向网络侧设备发送指令，并由应急广播设备执行，所述指令是由应急广播平台生成的，所述应急广播设备是所述应急广播平台下属的应急广播设备；

报告接收模块，用于在应急广播平台上接收网络侧设备发送的应急广播状态报告，所述应急广播状态报告是由应急广播设备经由网络侧设备发送至应急广播平台的；

本发明有益效果如下：

在本发明实施例中，由于由网络侧设备来实现应急广播状态报告的上报回传，通过将应急广播设备和应急广播平台通信资源视为对等的两方，通过提供TCP连接来实现信息传输，而转发云只需解决应急广播设备和应急广播平台动态IP地址及应急广播设备和应急广播平台唯一标识的映射问题；因而能够避免现有回传系统中各级应急广播平台独立申请固定IP地址的浪费问题，极大缩减应急广播成本。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为现有回传方案示意图；

图2为本发明实施例中在网络侧设备上的应急广播状态上报方法实施流程示意图；

图3为本发明实施例中在应急广播设备上的应急广播状态上报方法实施流程示意图；

图4为本发明实施例中在应急广播平台接收应急广播状态的方法实施流程示意图；

图5为本发明实施例中应急广播状态上报、接收方案实施环境示意图；

图6为本发明实施例中上报应急广播状态报告流程示意图；

图7为本发明实施例中应急广播平台下发指令流程示意图；

图8为本发明实施例中应急广播状态上报装置1结构示意图；

图9为本发明实施例中应急广播状态上报装置2结构示意图；

图10为本发明实施例中接收应急广播状态的装置结构示意图。

具体实施方式

基于现有应急广播系统闭门造车的设备状态回传方案，并未考虑资源重复利用和整合的可能性，造成了包括经济及性能成本不必要的浪费，并且只能应用在平台具备固定IP地址条件的场景，本发明实施例中提供了一种应急广播状态上报、接收方案，下面结合附图对本发明的具体实施方式进行说明。

在说明过程中，将分别从网络侧设备、应急广播设备侧、应急广播平台侧的实施进行说明，其中网络侧设备将说明应急广播状态上报的过程，应急广播设备侧将应急广播状态上报转发的过程，应急广播平台侧将说明接收应急广播状态上报的过程，然后还将给出三者配合实施的实例以更好地理解本发明实施例中给出的方案的实施。这样的说明方式并不意味着三者必须配合实施、或者必须单独实施，实际上，当三者分开实施时，其也各自解决自身一侧的问题，而三者结合使用时，会获得更好的技术效果。

图2为在网络侧设备上的应急广播状态上报方法实施流程示意图，如图所示，可以包括：

步骤201、接收应急广播平台发送的指令，并转发至各应急广播设备，所述应急广播设备是所述应急广播平台下属的各应急广播设备；

步骤202、接收各应急广播设备上报的应急广播状态报告，并转发至应急广播平台；

实施中，在进行接收及转发时，是通过TCP(TransmissionControlProtocol，传输控制协议)通道进行接收及转发的。

需要说明的是，步骤201与202之间并无必然的时序关系，事实上，在实施中这个转发过程是彼此独立的。

图3为在应急广播设备上的应急广播状态上报方法实施流程示意图，如图所示，可以包括：

步骤301、在应急广播设备上接收网络侧设备发送的指令，并执行该指令，所述指令是由应急广播平台经由网络侧设备发送的，所述应急广播设备是所述应急广播平台下属的应急广播设备；

步骤302、向网络侧设备上报应急广播状态报告，所述应急广播状态报告将由网络侧设备发送至应急广播平台；

实施中，在进行接收及上报时，是通过TCP通道进行接收及上报的。

需要说明的是，步骤301与302之间并无必然的时序关系，事实上，在实施中这个转发过程是彼此独立的。

图4为在应急广播平台接收应急广播状态的方法实施流程示意图，如图所示，可以包括：

步骤401、向网络侧设备发送指令，并由应急广播设备执行，所述指令是由应急广播平台生成的，所述应急广播设备是所述应急广播平台下属的应急广播设备；

步骤402、在应急广播平台上接收网络侧设备发送的应急广播状态报告，所述应急广播状态报告是由应急广播设备经由网络侧设备发送至应急广播平台的；

实施中，在进行接收及发送时，是通过TCP通道进行接收及转发的。

需要说明的是，步骤401与402之间并无必然的时序关系，事实上，在实施中这个转发过程是彼此独立的。

下面对三者的结合实施进行具体说明。

图5为应急广播状态上报、接收方案实施环境示意图，图中包括平台A、平台B，其中省略号表示该环境中可以容纳更多类似的平台，每个平台中都包括有应急广播平台，以及该应急广播平台下属的应急广播设备。为便于更直观的理解，图中将网络侧设备命名为转发云，之所以这样命名是因为这些网络侧设备的主要功能是“转发”，同时，它们构成的设备功能体按现有习惯通常称为“云服务”，转发云以有线或者无线方式与各应急广播平台以及应急广播设备相连，并传输信息。

实施中，转发云具体可以是一个具有固定IP地址的远端服务器，具体实践中可以自行申请各云服务公司的产品或者自己建设，在该服务器上部署数据转发服务，作为TCP服务端监听各平台服务器及终端的TCP请求，并提供动态IP地址和应急广播设备、应急广播平台服务器标识的映射数据库存储功能，随着应急广播设备及应急广播平台服务器的IP地址动态更新该映射；应急广播设备主动TCP连接转发云并以固定时间间隔(具体可以设置为3分钟)发送心跳以保持TCP连接，并确保在自身IP地址变化时及时将自身信息上报转发云；应急广播平台服务器以和应急广播设备同样的方式在转发云端维持一个TCP连接并向其更新自身变化IP地址及标识。也即：

实施中，对于各应急广播设备和/或应急广播平台，还可以进一步包括：发送心跳报文维持连接。

对于网络侧设备，还可以进一步包括：通过各应急广播设备和/或应急广播平台发送的心跳报文维持连接。

对于转发云来讲，所有应急广播平台中的服务器和应急广播设备终端被抽象为统一的子元素，转发云的作用主要有两点：一是维护所有子元素的身份标识信息和动态IP地址信息的映射，二是将源元素发出的数据和/或指令准确无误的转发到目的元素。

下面对子元素在传输指令、应急广播状态报告时所使用的通信及转发协议的具体实施进行说明。

可以采用如下结构的注册消息报文协议：

表格1注册消息报文格式

可以采用如下结构的注册返回消息报文协议：

表格2注册返回消息报文格式

	消息长度	消息内容
			示例	4b	0x01
大小	4b	4b

可以采用如下结构的回传消息报文协议：

表格3消息报文格式

可以采用如下结构的心跳报文：

表格4心跳报文格式

	心跳长度	心跳内容
			示例	1B	0x00
大小	2B	1B

具体实施中，并不一定严格采用上述方式的报文格式，事实上，是要能实现三方各子元素通信目的的报文格式都可以，上述实例仅用于教导本领域技术人员具体如何实施本发明，但不意味仅能使用上述报文格式，实施过程中可以结合实践需要来确定相应的方式。下面依赖以上协议，说明转发流程的实施。

图6为上报应急广播状态报告流程示意图，先对图中的设备进行说明，在部署平台时，每个元素(即终端设备或者服务器)为TCP客户端，具体在图中唯一标识符为0013101389、0013101390的TCP客户端为应急广播设备，唯一标识符为001025、001026的TCP客户端为构成应急广播平台的服务器。本实例中，将说明应急广播设备0013101389向应急广播平台001025上报应急广播状态报告的实施。

如图6所示，上报应急广播状态报告时可以包括如下步骤：

步骤601、应急广播设备向转发云端发起TCP连接请求，TCP建立连接之后紧跟一条注册消息报文，具体可以采用如表格1的格式；

步骤602、转发云端建立连接之后，将第一条收到的报文当作注册报文格式解析，解析并注册成功之后向注册终端发送注册成功响应报文，具体可以采用如表格2的格式；

步骤603、应急广播设备收到注册成功响应后，开始发送应急广播状态报告数据报文，具体可以采用如表格3的格式；

进一步的，应急广播设备每隔一个间隔时间向云端发送心跳报文维持连接，如果发现连接中断，启动重新注册动作，直到收到注册成功响应；也即，具体实施中，对于各应急广播设备和/或应急广播平台，还可以进一步包括：

向网络侧设备发送心跳报文用以维持连接。

对于网络侧设备，还可以进一步包括：在应急广播设备和/或应急广播平台连接中断后启动的注册流程中恢复连接。

步骤604、转发云端将随后收到的报文都作为应急广播状态报告消息报文和心跳报文来解析；如果是应急广播状态报告则按取得的目的标识对应的TCP连接进行转发。

图7为应急广播平台下发指令流程示意图，先对图中的设备进行说明，在部署平台时，每个元素(即终端设备或者服务器)为TCP客户端，具体在图中唯一标识符为0013101389、0013101390的TCP客户端为应急广播设备，唯一标识符为001025、001026的TCP客户端为构成应急广播平台的服务器。本实例中，将说明应急广播平台001025向应急广播设备0013101389下发指令的实施，实施中，假设已按图6中的实施方式注册、建立，并已经按取得的目的标识对应了相应的TCP连接。

如图7所示，应急广播平台下发指令时可以包括如下步骤：

步骤701、应急广播平台发指令给转发云端；

步骤702、转发云端转发指令给相应标识的应急广播设备；

步骤703、应急广播设备响应应急广播状态报告给转发云端；

步骤704、转发云端转发应急广播状态报告给应急广播平台。

基于同一发明构思，本发明实施例中还提供了一种应急广播状态上报、接收装置，由于这些装置解决问题的原理与一种应急广播状态上报、接收方法相似，因此这些装置的实施可以参见方法的实施，重复之处不再赘述。

图8为应急广播状态上报装置1结构示意图，如图所示，包括：

通道模块801，用于建立TCP通道；

转发模块802，用于接收应急广播平台发送的指令，并转发至各应急广播设备，所述应急广播设备是所述应急广播平台下属的各应急广播设备；接收各应急广播设备上报的应急广播状态报告，并转发至应急广播平台；其中，在进行接收及转发时，是通过TCP通道进行接收及转发的。

实施中，通道模块还可以进一步用于通过各应急广播设备和/或应急广播平台发送的心跳报文维持连接。

实施中，通道模块还可以进一步用于在应急广播设备和/或应急广播平台连接中断后启动的注册流程中恢复连接。

图9为应急广播状态上报装置2结构示意图，如图所示，可以包括：

指令接收模块901，用于在应急广播设备上接收网络侧设备发送的指令，并执行该指令，所述指令是由应急广播平台经由网络侧设备发送的，所述应急广播设备是所述应急广播平台下属的应急广播设备；

报告发送模块902，用于向网络侧设备上报应急广播状态报告，所述应急广播状态报告将由网络侧设备发送至应急广播平台；

实施中，报告发送模块还可以进一步用于向网络侧设备发送心跳报文用以维持连接。

实施中，报告发送模块还可以进一步用于在连接中断后，启动注册流程用以恢复连接。

图10为接收应急广播状态的装置结构示意图，如图所示，包括：

指令发送模块1001，用于向网络侧设备发送指令，并由应急广播设备执行，所述指令是由应急广播平台生成的，所述应急广播设备是所述应急广播平台下属的应急广播设备；

报告接收模块1002，用于在应急广播平台上接收网络侧设备发送的应急广播状态报告，所述应急广播状态报告是由应急广播设备经由网络侧设备发送至应急广播平台的；

实施中，指令发送模块还可以进一步用于向网络侧设备发送心跳报文用以维持连接。

实施中，指令发送模块还可以进一步用于在连接中断后，启动注册流程用以恢复连接。

为了描述的方便，以上所述装置的各部分以功能分为各种模块或单元分别描述。当然，在实施本发明时可以把各模块或单元的功能在同一个或多个软件或硬件中实现。

综上所述，在本发明实施例中提供了应急广播状态上报、接收方案，具体的，利用转发云来实现应急广播状态报告的上报回传，通过将应急广播设备和应急广播平台通信资源视为对等的两方，通过提供TCP连接来实现信息传输，而转发云只需解决应急广播设备和应急广播平台动态IP地址及应急广播设备和应急广播平台唯一标识的映射问题；

进一步的，还提供了整个通信流程及协议的实施方式；

该方案除应急广播外还可以复制到具有GPRS上报或下载功能的各类监控管理系统，如智能抄表、终端GPRS升级等。

应用本发明实施例提供的技术方案，可以避免各级应急广播平台独立申请固定IP地址的浪费问题，极大缩减应急广播成本；减轻了应急广播平台服务器通信及数据库性能不必要的损耗问题，使得平台服务器专注完成自有业务；解决了平台服务不能为移动设备的问题，极大扩展了现有应急广播平台可以适用的场景。

本发明经过实验环境及若干现场环境测试调试，终端设备通过定期(3分钟)心跳可以很好的和转发云保持TCP连接状态，转发云快速解析报文头中的相关信息进行数据转发并更新数据库中该终端的IP地址及标识映射；应急广播平台服务器以同样的心跳方式和转发云保持TCP连接，需要给特定终端设备发送指令时，则指定相应终端标志id即可将指令准确实时的发送到相应终端设备；同时验证了平台服务器为移动设备时的回传场景；各模块及场景均出色的完成了应急广播平台下的回传任务，具有成本低，部署方便，时效性好诸多优点。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器和光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种应急广播状态上报方法，其特征在于，包括：

其中，在进行接收及转发时，是通过传输控制协议TCP通道进行接收及转发的。

2.如权利要求1所述的方法，其特征在于，进一步包括：

通过各应急广播设备和/或应急广播平台发送的心跳报文维持连接。

3.如权利要求1或2所述的方法，其特征在于，进一步包括：

在应急广播设备和/或应急广播平台连接中断后启动的注册流程中恢复连接。

4.一种应急广播状态上报方法，其特征在于，包括：

5.如权利要求4所述的方法，其特征在于，进一步包括：

向网络侧设备发送心跳报文用以维持连接。

6.如权利要求4或5所述的方法，其特征在于，进一步包括：

在连接中断后，启动注册流程用以恢复连接。

7.一种接收应急广播状态的方法，其特征在于，包括：

8.如权利要求7所述的方法，其特征在于，进一步包括：

向网络侧设备发送心跳报文用以维持连接。

9.如权利要求7或8所述的方法，其特征在于，进一步包括：

在连接中断后，启动注册流程用以恢复连接。

10.一种应急广播状态上报装置，其特征在于，包括：

通道模块，用于建立TCP通道；

11.如权利要求10所述的装置，其特征在于，通道模块进一步用于通过各应急广播设备和/或应急广播平台发送的心跳报文维持连接。

12.如权利要求10或11所述的装置，其特征在于，通道模块进一步用于在应急广播设备和/或应急广播平台连接中断后启动的注册流程中恢复连接。

13.一种应急广播状态上报装置，其特征在于，包括：

14.如权利要求13所述的装置，其特征在于，报告发送模块进一步用于向网络侧设备发送心跳报文用以维持连接。

15.如权利要求13或14所述的装置，其特征在于，报告发送模块进一步用于在连接中断后，启动注册流程用以恢复连接。

16.一种接收应急广播状态的装置，其特征在于，包括：

17.如权利要求16所述的装置，其特征在于，指令发送模块进一步用于向网络侧设备发送心跳报文用以维持连接。

18.如权利要求16或17所述的装置，其特征在于，指令发送模块进一步用于在连接中断后，启动注册流程用以恢复连接。