CN113015113A - 基于北斗卫星的海洋物联网通用网关数据转发方法 - Google Patents

Abstract

本发明公开了基于北斗卫星的海洋物联网通用网关数据转发方法，本方案以北斗卫星通信为中心，以异构网络数据转发协议的研究为核心，并且涉及北斗卫星短报文协议、以太网和GPRS协议以及ZigBee网络协议三种网络协议，需要通过研究三种不同网络之间构建和解析数据结构协议，从而重新进行数据组包和拆包，同时还需进行异构网络之间的网络地址判断，本发明的方案可以按多种工作模式采集海洋数据，并进行数据拆包、北斗协议封装、北斗短报文传输；同时研制的主站端接收设备可以完成北斗短报文接收、数据解析、组包和补包操作，实现异构网络之间不受地址位置限制的数据互传和通信功能。

Description

基于北斗卫星的海洋物联网通用网关数据转发方法

技术领域

本发明涉及基于北斗卫星的海洋物联网通用网关数据转发方法，属于通信技术领域。

背景技术

我国国土辽阔，地形包括平原、山区、湖泊、沙漠以及海域等，虽然我国通信建设位列与世界前茅，建设面积也基本覆盖了2/3的国土面积，但是对于偏远山区、临海、大型湖泊以及沙漠地区，无线通信网却无能为力。另外我国是受自然灾害较为严重的国家，有些多灾平原地区即使拥有通信网，但是当灾难发生的时候，通信网就会遭受破坏甚至瘫痪，比如2008年汶川大地震。如何有效、准确、高效的进行通信成为了这些地区以及这些情况下紧要的问题。

北斗导航系统是我国自主研发的卫星导航系统，具有精确定位、短报文通信、精密授时三大功能。该系统由北斗导航定位卫星、地面控制中心和各类用户终端三个部分组成，可为全球范围内的各类用户提供全天候、全天时的高精度、高可靠的定位、导航、短报文以及授时服务。

北斗短报文通信时北斗导航系统特有的一个功能，其不受地形条件和环境气候等影响，可以解决偏远地区数据实时通信问题，特别适用于常规通信手段存在盲区多、基建投入大的场合使用，例如，海上数据采集和救援通信等。但是由于北斗卫星的主要任务是定位导航，对于通信任务的信道资源很少，导致民用北斗短报文在通信过程中受限于单次报文长度和通信频度问题，这使得通信效率明显降低，比如在汇报灾情和紧急救援的时候，每一秒都很重要，每一个细节都很重，很显然对于单天线北斗短报文通信是无法解决这类问题。

目前北斗短报文通信被应用于各个领域，并且结合现有网络组成异构网络，文献在无公网覆盖的偏远地区，居民用电信息的自动化采集是一个历史性难题。随着网络多元化的发展，不同网络直接连接和数据转换也越来越频繁，因此异构网络直接的协议转换和实现发放成为物联网通信领域的研究热点，由于海上资源开发需要前期进行大量长期的海上研究和探测，这就需要可靠高效实时的通信以及数据转发服务。然而海洋通信相比于陆地没有可靠的移动网基站，所以需要进行海上数据采集业务只能先采集保存数据，再到陆地进行处理的离线数据传输方法，此方法通信效率较低。如果通过海事卫星进行数据转发，则价格过于昂贵和频道资源的浪费，不适用于实时频繁的大数据传输和通信。北斗短报文可以实时的进行数据传输和通信，而且不受地理位置限制，但是北斗短报文无法于其他网络进行互传数据和通信，由此极大的影响了与陆地通信网之间进行数据共享，从而降低了通信数据处理效率。

发明内容

因此本发明开发出一套以北斗卫星为中心的海洋物联网通用网关数据转发方法，实现异构网络之间不受地址位置限制的数据互传和通信功能。

本发明以北斗卫星通信为中心，以异构网络数据转发协议的研究为核心，并且涉及北斗卫星短报文协议、以太网和GPRS协议以及ZigBee网络协议三种网络协议，需要通过研究三种不同网络之间构建和解析数据结构协议，从而重新进行数据组包和拆包，同时还需进行异构网络之间的网络地址判断等研究。

一、协议架构

关于网关系统总体架构如图1所示，以北斗卫星为中心，通过北斗天线进行发送端和接收端的信息交互，北斗天线连接至网关，通过网关进行异构网络的消息数据处理，主要分为四个不同网络之间根据不同协议把数据进行解析再封装的过程。

首先把数据输入端进行弱耦合设计，用户输入数据进行不同协议分类处理，主要分为以太网协议、GPRS协议和Zigebe无线网协议。数据通过不同网络协议封装之后传输到北斗短报文处理模块，1)首先判断第一次封装数据的协议类型；2)对第一次封装后对数据运用本异构网络网关协议数据转发设计方法进行基于北斗短报文协议到二次封装；3)最后把二次封装后的数据通过北斗天线发送到北斗卫星。在接收方的北斗天线从北斗卫星中接收到数据，然后根据北斗协议进行解包处理，取出数据之后判断封装协议类型，并进行对应协议解析，具体如下：

(1)北斗卫星网络和以太网网络协议

北斗卫星网络和以太网协议转发采用json格式，其是一种轻量级的数据交换协议，通过收发双方自定数据字段进行编码和解码操作。字段定义如下表1所示：

表1字段定义说明表

序号	字段名称	说明
			1	opcode	0：发送消息；1：发送心跳包；
2	msg	消息内容
			3	peerBeidouId	接收方北斗天线ID
4	peerAddrType	0：无下接设备；1：以太网；2：GPRS；3：ZigBee
			5	peerAddr	下接设备网络地址

说明：北斗卫星直接交互按照北斗协议原始数据进行编码和解码，不做协议规定。

(2)北斗卫星网络和GPRS网络协议

北斗卫星网络和GPRS网络协议直接分为发送和接收两个部分，首先接收端只需判断peerAddrType字段类型即可，当时为2时，既GPRS网络时候，解码数据包直接转发至对应手机号码。在发送端进行发送数据协议设计，如下表2所示。

表2发送数据协议字段表

对端北斗ID

对端地址类型

对端设备地址

短信内容

在编辑短信时，四个字段之间需要有“#”符号进行隔开，当接收方接收发到消息后按照协议定义进行字段位数据解码。

(3)北斗卫星网络和ZigBee网络协议

北斗卫星网络和ZigBee网络协议之间数据收发研究同样分为协调器数据收发和终端数据收发，其中协调器只需要进行判断peerAddrType字段类型即可，当为数字3时，既ZigBee网络时候进行数据解码操作。终端设备是于PC端上位机相连，并且包含多个终端设备，因此需要进行ZigBee端数据协议设计，当协调器和终端上电以后既开始握手建立连接，在建立连接后终端首先发送自己的网络地址给协调器，当协调器接收到终端短地址之后进行绑定建表，在转发数据时候通过广播方式把需要发送到的终端地址放在包头与数据一起发送，终端接收到之后首先解码终端短地址，并与自己本地短地址进行比对，比对结果如果一致则进行数据位解码。

另外，无论是协调器还是终端在数据发送时，在数据位末尾加上“\r\n”字符进行数据包是否接受完整判断。

二、GPRS网络PDU模式短信收发研究

本方案对于GPRS网络进行了PDU模式短信收发协议设计，从而满足其数据结构在发送和接收过程兼容北斗卫星短报文数据结构。本发明的GPRS网络采用短信文本方式与北斗短报文协议格式进行转化，其中短信发送采用PDU模式。

ZigBee网络寻址路由组网过程如下：

(1)协调器和终端上电以后，终端开始寻址同一个PANID下的可用地址并发起请求操作，当协调器接到同一个网络下的终端连接请求指令后，开始下发终端地址。

(2)当终端收到协调器发来的连接响应指令后建立连接，同时对恢复任务ID给协调器。

(3)协调器收到终端发来的建立任务指令后存储其终端任务ID，并与终端地址进行绑定。

(4)当用户从终端发送消息给协调器后，协调器接收消息的同时解析出终端地址，并根据终端地址搜索相应的任务ID，因此可以查到协调器下接所有终端地址，实现寻址路由功能。其中在组网过程中本方案的基础组网方式选择的是单播组网。

为了防止Zigbee模块启动后会往上位机发一个字节的数值0x00，本方案约定了上位机串口接收协议，如下表3所示。

表3串口发送协议字段

所占字节	1	4	N	2
					字段	>	srcAddr	msg	\r\n

其中符号“>”表示包头，占1字节；srcAddr:表示包的源地址，占4字节，msg：表示消息目前最大长度为76字节，\r\n：表示包结束，占2字节。

另外为了防止终端及协调器在接收消息内容过程中分段解析问题，本方案约定了一个包结束符号“\r\n”，具体协议如下表4所示。

表4串口接收协议字段

所占字节	0/2	n	1
				字段	dstAddr	msg	\r\n

其中dstAddr为目标zigbee网络短地址，如果要发给zigbee终端设备需要该字段，此时占2字节，大端方式；如果是发给协调器，则不需要该字段，此时为0字节。

有益效果

本发明方案研发的基于北斗卫星的海洋物联网通用网关系统，可以按多种工作模式采集海洋数据，并进行数据拆包、北斗协议封装、北斗短报文传输；同时研制的主站端接收设备可以完成北斗短报文接收、数据解析、组包和补包操作，实现异构网络之间不受地址位置限制的数据互传和通信功能。

附图说明

图1为本发明整体方案的示意图；

图2为本发明的系统硬件示意图；

图3为本发明的传送方法示意图；

图4为本发明的协议架构示意图。

具体实施方式

以下结合附图进一步说明本发明的技术方案。参见图1至图4，为本发明方案的示意图。

以北斗卫星为中心，通过北斗天线进行发送端和接收端的信息交互，北斗天线连接至网关，通过网关进行异构网络的消息数据处理，主要分为四个不同网络之间根据不同协议把数据进行解析再封装的过程。首先把数据输入端进行弱耦合设计，用户输入数据进行不同协议分类处理，主要分为以太网协议、GPRS协议和Zigebe无线网协议。数据通过不同网络协议封装之后传输到北斗短报文处理模块，首先判断第一次封装数据的协议类型，然后对第一次封装后的数据包运用本异构网络网关协议数据转发设计方法进行基于北斗短报文协议到二次封装。最后把二次封装后的数据包通过北斗天线发送到北斗卫星。在接收方的北斗天线从北斗卫星中接收到数据包，然后根据北斗协议进行解包处理，取出数据之后首先判断封装协议类型，然后进行对应协议解析。

假如要发送下面的短信：

(1)接收号码：+8613501337830

(2)短信内容：工作愉快！

(3)短信中心号码：+8613800250500

(4)中国移动短信号码为：+8613800XYZ500

其中XYZ为您号码归属地区号去除0的部分，不足三位末尾补0，比如：南京区号025，XYZ对应为250；深圳区号0755，XYZ对应为755。这里网上也存在另一种说法，即对于中国移动的短信服务中心号是+861380xxxx500，其中xxxx是你所在的长途电话区号，不足4位就补0，比如北京是010，补0后是0100，就应该+8613800100500。无论哪一种说法都需要注意一下几点：

(1)发送的指令用0x0D结尾，注意不是通常认为的0x0D,0x0A。

特别是在发送PDU短信的AT+CMGS＝25命令时，一定只能以0x0D结尾。

(2)在发送短信内容时，以0x1A(代表ctrl+Z的虚拟键值)结尾。

(3)用AT+CMEE＝1命令，可以在短信返回ERROR时带上原因，这样方便调试。

短信接收

对于短信接收部分同样以接收13752141860号码发送来的“你好”，以及信息中心号码为：+8613800220500为例，手机接收到字符串为：

+CMT:,24

0891683108200205F0240D91683157121468F0000860800331220000044F60597D。

其中+CMT表示新短信指示代码格式为收到短消息立即显示；若+CMTI则指示收到短消息存储到存储器里；这里是否直接显示需要通过CNMI进行设置；

数字24表示PDU数据中短信中心号码后面的字符串长度/2，即240D91683157121468F0000860800331220000044F60597D的长度除以2；

下面分析一下接收到的PDU数据：

(1)08//信息中心号码的长度,将91+683108200205F0的长度除2,格式化成2位的16进制字符串所得；

(2)91//短信中心号码类型；

(3)683108200205F0//短信中心号码，转换方法前面有提到；

(4)24//TPDU头字节，接收到iphone的短信，该值为04；

(5)0D//发送源号码长度，8613752141860的长度格式化为2位16进制所得；

(6)91//发送源号码类型；

(7)683157121468F0//发送源号码；

(8)00//协议标识TP—PID；

(9)08//数据编码方案，08：中文编码，00为英文或数字,Bit No.7与Bit No.6；

(10)608003312200//日期时间，奇偶互换：06-08-30 13:22:00,有论坛上写接收到的是026080……就是前面有’02’,表示2006-08…但是我用不同的手机发送短信过来接收到的都是06,无法取得2006,不知道是发送方手机设置的问题还是哪里的问题,还在研究中.；

(11)00//时区；

(12)04//用户数据长度TP-UD(TP-User-Data-Length)，4F60597D的长度除2格式化为2位16进制数所得；

(13)4F60597D//”你好”的UNICODE码,同样提供一个DELPHI下的解码函数：0891683108200205F0240D91683157121468F00008

60800331220000044F60597D；

上面例子中接收到的是中文短信“你好”，那么当接收到的短信是纯中文或者数字的时候又如何解码呢？例如接收到13752141860发送的英文短信“hello”，手机接收到的字符串为：

+CMT:,24

0891683108200205F0240D91683157121468F00000608003416270000461F1980C。

前面编码的意义和中文信息相同，这里不再重复，只从红色的00说起：

先前提到了这两位表示数据编码方案，08为中文编码，00为英文或数字，当手机发送普通的ASCII字符即使用7-bit编码方式，说明我们接收到的短信是英文或者数字格式的，而不是中文UNICODE码；

04仍然是用户数据(61F1980C)长度除2格式化为2位10进制数所得，61F1980C就是发送方发送过来的短信息，根据前面的00我们知道这是一段7-bit码，而不再是UNICODE码，7-bit的解码过程很复杂，大体过程是：

将源数据每7个字节分为一组，解码成8个字符。基本自然是：将第n个字节左移n位，再加上前一字节的剩余数据，即第(n-1)个字节右移(8-n)位的数值，屏幕最高位，即得到一目标字符数据，n＝0…6。第7个字节右移1位就得到解码后的第8个字符数据。

Claims (3)

1.基于北斗卫星的海洋物联网通用网关数据转发方法，其特征在于，以北斗卫星为中心，通过北斗天线进行发送端和接收端的信息交互，北斗天线连接至网关，通过网关进行异构网络的消息数据处理，四个不同网络之间根据不同协议将数据进行解析再封装，过程如下：

1)、将数据输入端进行弱耦合设计，用户输入数据进行不同协议分类处理，分为以太网协议、GPRS协议和Zigebe无线网协议，数据通过不同网络协议封装之后传输到北斗短报文处理模块：

1-1)判断第一次封装数据的协议类型；

1-2)对第一次封装后对数据运用本异构网络网关协议数据转发设计方法进行基于北斗短报文协议到二次封装；

1-3)将二次封装后的数据通过北斗天线发送到北斗卫星，在接收方的北斗天线从北斗卫星中接收到数据，然后根据北斗协议进行解包处理，取出数据之后判断封装协议类型，并进行对应协议解析；

2)、对于GPRS网络进行了PDU模式短信收发协议设计，从而满足其数据结构在发送和接收过程兼容北斗卫星短报文数据结构，GPRS网络采用短信文本方式与北斗短报文协议格式进行转化，其中短信发送采用PDU模式。

2.如权利要求1所述的方法，其特征在于，在过程1)的步骤1-3)中，二次封装后，通过北斗天线发送到北斗卫星，在接收方的北斗天线从北斗卫星中接收到数据，然后根据北斗协议进行解包处理，取出数据之后判断封装协议类型，并进行对应协议解析，具体如下：

1-3-1)北斗卫星网络和以太网网络协议

北斗卫星网络和以太网协议转发采用json格式，其是一种轻量级的数据交换协议，通过收发双方自定数据字段进行编码和解码操作，字段定义如下表1所示：

表1 字段定义说明表

北斗卫星直接交互按照北斗协议原始数据进行编码和解码，不做协议规定；

1-3-2)北斗卫星网络和GPRS网络协议

北斗卫星网络和GPRS网络协议直接分为发送和接收两个部分，首先接收端只需判断peerAddrType字段类型即可，当时为2时，既GPRS网络时候，解码数据包直接转发至对应手机号码，在发送端进行发送数据协议设计，如下表2所示：

表2 发送数据协议字段表

对端北斗ID 对端地址类型 对端设备地址 短信内容

在编辑短信时，四个字段之间需要有“#”符号进行隔开，当接收方接收发到消息后按照协议定义进行字段位数据解码；

1-3-3)北斗卫星网络和ZigBee网络协议

北斗卫星网络和ZigBee网络协议之间数据收发同样分为协调器数据收发和终端数据收发，其中协调器只需要进行判断peerAddrType字段类型即可，当为数字3时，既ZigBee网络时候进行数据解码操作；终端设备是于PC端上位机相连，并且包含多个终端设备，因此需要进行ZigBee端数据协议设计，当协调器和终端上电以后既开始握手建立连接，在建立连接后终端首先发送自己的网络地址给协调器，当协调器接收到终端短地址之后进行绑定建表，在转发数据时候通过广播方式把需要发送到的终端地址放在包头与数据一起发送，终端接收到之后首先解码终端短地址，并与自己本地短地址进行比对，比对结果如果一致则进行数据位解码；

另外，无论是协调器还是终端在数据发送时，在数据位末尾加上“\r\n”字符进行数据包是否接受完整判断。

3.如权利要求1所述的方法，其特征在于，在过程2)中，ZigBee网络寻址路由组网过程如下：

(2-1)协调器和终端上电以后，终端开始寻址同一个PANID下的可用地址并发起请求操作，当协调器接到同一个网络下的终端连接请求指令后，开始下发终端地址；

(2-2)当终端收到协调器发来的连接响应指令后建立连接，同时对恢复任务ID给协调器；

(2-3)协调器收到终端发来的建立任务指令后存储其终端任务ID，并与终端地址进行绑定。

(2-4)当用户从终端发送消息给协调器后，协调器接收消息的同时解析出终端地址，并根据终端地址搜索相应的任务ID，因此查到协调器下接所有终端地址，实现寻址路由功能，其中在组网过程中的基础组网方式选择的是单播组网；

为了防止Zigbee模块启动后会往上位机发一个字节的数值0x00，约定了上位机串口接收协议，如下表3所示：

表3 串口发送协议字段

所占字节 1 4 N 2 字段 > srcAddr msg \r\n

其中符号“>”表示包头，占1字节；srcAddr:表示包的源地址，占4字节，msg：表示消息目前最大长度为76字节，\r\n：表示包结束，占2字节；

为了防止终端及协调器在接收消息内容过程中分段解析问题，约定一个包结束符号“\r\n”，具体协议如下表4所示：

表4 串口接收协议字段

所占字节 0/2 n 1 字段 dstAddr msg \r\n

其中dstAddr为目标zigbee网络短地址，如果要发给zigbee终端设备需要该字段，此时占2字节，大端方式；如果是发给协调器，则不需要该字段，此时为0字节。

Images