应急状况下北斗短报文通信功能的应用

2018-10-18，

计算机测量与控制 2018年10期

，

(陆军勤务学院军事物流系，重庆 401311)

0 引言

我国幅员辽阔，地震、洪水、泥石流等大型自然灾害时有发生，造成的人员伤亡和经济损失都十分巨大[1-4]。灾害发生地区容易产生通信设备瘫痪问题，导致链路中断、通信不畅，加之偏远地区本身所存在的通信盲区，无法将灾区信息及时传递出去，对于救援工作的开展带来很大的不便[5]。为了尽快投入救援工作，最大程度的保护人民群众的生命财产安全，构建应急通信链路进行信息的传递是十分必要的。

常规的通信技术由于通信原理的限制，在应急情况下无法很好的完成通信任务[6]。例如采用以太网进行远程数据传输，虽然可以确保数据传输的实时性，但基站等通信设备易遭到破坏[7-8]；基于手机无线自组织网构建小范围应急通信系统，虽然可以实现语音和文本的一对一或一对多通信，但无法保证传输链路的通畅性以及数据传输的可靠性[9-10]；使用ZigBee网络和GPRS传输数据，虽然可以提高数据传输的可靠性，但ZigBee网络无法进行移动终端组网，且传输的距离较近，GPRS存在着丢包现象和转接时延的问题[11-14]。

相比而言，卫星通信技术可以不受自然灾害的影响，不存在通信盲区，稳定性较高；并且误码率低，北斗系统的误码率最大为105，传输可靠[15-16]。因此，研究应急情况下北斗短报文通信功能的应用，构建通信系统，实现一对一或一对多的通信，对于灾区信息的及时发送具有现实意义。

1 信息预处理

应急情况下，首先应当保证信息发送的时效性，在此基础上，考虑到北斗短报文通信功能所具有的容量和频度的限制，为了充分利用传输空间，尽可能多地将有用信息正确发送出去，需要对信息进行前期处理。为了便于说明，本文将一条信息称为一个数据单元(Data Unit)，用符号DU进行表示。

处理1：根据数据单元所含内容重要程度的差异，将其分为紧急数据单元和普通数据单元两类，用符号UDU和ODU进行表示。UDU的内容较为重要，时效性要求比较高，需尽快让接收方知晓；ODU内的内容相对来说对于发送时间没有严格要求，因此，发送端应优先对UDU进行处理。

为了处理方便，在发送端缓冲区内，划定队列Queue1和队列Queue2。如图1所示，Queue1是由UDU组成的队列，具有优先处理权；Queue2是由ODU组成的队列，优先级较低。在发送信息时，指针首先指向队列Queue1，当遍历Queue1内数据单元后，再将指针指向队列Queue2，从而保证数据单元按重要程度进行发送。

图1 发送端缓冲区内队列划分

处理2：根据北斗短报文通信功能容量的限制，将需要发送的数据单元按照所含数据量的多少进行划分。理论上北斗短报文通信功能的传输能力可达1680bit/次，但由于生产厂商、应用对象等因素的不同，各北斗设备的实际传输容量存在着差异。

如图2所示：假定某北斗设备的传输容量为Nbit,设定限值区间为(N/2，N)。DU内所含数据量用M表示，当MN时，划分为长数据单元(LDU)。在处理过程中，对于SDU需要进行数据整合，对于LDU则需要进行数据切分。

图2 根据DU大小进行划分

2 通信协议设计

为了满足应急情况下应用的实际需求，本文提出了相应的机制，需要对北斗短报文通信协议进行一定的改进。在北斗原有协议的基础上，添加必要的传输约定关键字，以便于后续对数据的处理。协议改进部分的具体格式如表1所示。

表1 通信协议改进部分的格式

1)起始位。占用一个字节，以符号“*”表示。当读取到起始位标识时，表明一条信息的开始。起始位对于SDU整合处理后的信息读取具有重要作用。

2)标志位。用于传输机制的控制，可分为四个部分：反馈标识、数据类型标识、数据序列号、长数据单元标识。

(1)反馈标识。占用1个比特，用于表示DU是否为反馈数据单元。设定若反馈标识为0，则DU不是反馈信息；若反馈标识为1，则DU为反馈信息。反馈标识用于确保传输可靠，对发送的信息进行回复。

(2)数据类型标识。占用1个比特，用于表示DU所含信息的紧急程度。设定若数据类型标识为0，则为UDU；若数据类型标识为1，则为ODU。数据类型标识，对于应急条件下优先发送紧急信息的处理具有重要作用。

(3)数据序列号。占用5个比特，对需要发送的DU进行编号，并且根据划分出的队列Queue1和队列Queue2分别进行编号。这样能够使得处理过程中能够简单快捷的找到所需的数据单元，对重传处理具有重要作用。

(4)长数据单元标识。占用1个比特，用于表示DU是否为LDU。设定若长数据单元标识为0，则不是LDU；若长数据单元标识为1，则是LDU。长数据单元标识对于LDU的切分以及接收后的重组处理具有重要作用。

3)长度位。占用1个字节，用来标识DU的净长度(不包含添加的传输约束关键字)。长度位是SDU整合处理以及LDU切分处理的依据。

4)终止位。占用一个字节，以符号“#”表示。当读取到终止位标识时，表明一条信息读取完毕。

3 发送端信息处理

3.1 UDU的处理

对于成为“信息孤岛”的应急状况而言，在有限的时间和容量条件下，紧急情况中发送的多为SDU和MDU，对于LDU的使用较少，这样可以尽可能多的将信息发送出去，对救援工作的指挥部署和具体方案的实施提供可靠的保障。因此，本文仅对SDU进行处理，处理步骤如下：

步骤一：顺势检验队列Queue1中是否还有其它UDU。若有的话，进一步判断其是否也为SDU；若没有的话，就直接发送该UDU；

步骤二：若其后一个UDU也为SDU，则判断两者能否整合成一个UDU；若其后不是SDU，则直接发送第一个UDU；

步骤三：若两者能够整合，则整合成一个UDU，进而判断整合后的UDU是否仍旧是SDU；若不能整合，则直接发送第一个UDU；

步骤四：若整合后的UDU仍旧是SDU，则重复步骤一至三，直至整合后的UDU不是SDU为止，将整合后的UDU进行发送。

UDU的处理过程如图3所示。

图3 UDU的处理

对于UDU而言，为了不影响信息传输的时效性，处理过程应当在极短的时间内完成。为防止SDU过多，整合过程持续循环，数据长时间滞留的情况发生，在整合处理中需设定一个计时器。计时器的时间设置为北斗设备发送两次报文的时间间隔，从而强制终止整合操作，将数据信息发送出去。

值得注意的是，SDU整合过程中，对于每个DU添加的关键字仍然需要保留，这样接收端在接收到数据包后，按照协议制定的规则进行解析就能够还原出每条信息，避免造成信息的混淆。但处理后的DU相比于长度位所标定的DU的净长度有所增加，所以整合时应当考虑传输约定关键字的因素，每合并一个SDU其真实数据量为标志位标定的数据量加上关键字的长度。

3.2 ODU的处理

相较于UDU仅对SDU进行整合处理的情况，在ODU中，由于时效性的要求降低，信息滞留的时间相对较长，因此数据处理的可操作性增加，不单只是SDU间可以进行整合，也可考虑和MDU，甚至于LDU切分后的数据单元进行整合。

一些ODU虽然达到了MDU的限值，但是数据量不是特别的大，如果将其按照一个数据包进行发送，则会造成传输空间的浪费。为了尽可能充分的利用传输空间，需设定一个更加精确的限值如(5N/6,N),当数据量不满足限值时，虽然是MDU，但仍需进行整合处理。

如图4所示，在发送端缓冲区中建立一个临时队列Queue3，专门用来存放队列Queue2中的SDU。通过这一处理过程，可以将SDU挑拣出来，这样在整合处理的过程中，就能有针对性的进行操作，使整合处理高效快捷。

图4 建立临时队列Queue3

对于ODU的处理过程如下：

当队列Queue2中为SDU时，将其提取出来按序放入临时队列Queue3中。同时检查Queue3的长度是否达到精确限值(5N/6,N)，若达到限值，则将Queue3中的SDU整合成一个数据包进行发送；若没有达到限值，则暂时搁置。

当队列Queue2中为MDU或者LDU切分后的数据单元时，步骤如下：

步骤一：让其按照Queue3的排列顺序从前至后进行尝试，看能否和其中的某个SDU进行整合；

步骤二：如果能够整合，则将两者进行合并，成为一个ODU，并判断整合后的ODU是否满足精确限值(5N/6，N)；如果不能够整合，则直接发送该MDU或者LDU切分后的数据单元；

步骤三：若整合后的ODU不满足精确限值，则重复步骤一和二；若满足精确限值，则发送整合后的ODU。

虽然ODU对于时效性的要求没有那么严格，但是也不应一直滞留，因此在队列Queue3中应该添加一个机制，当某个SDU滞留的时间达到一定值时，强制性进行发送。因此考虑对SDU添加计时器，从其进入队列Queue3开始计时，当滞留时间达到30分钟时，不再考虑数据的整合，直接进行发送。

ODU具体的处理过程如图5所示。

图5 ODU的处理

3.3 LDU的切分处理

对于LDU而言，保证接收端数据的完整性是重要条件。因此，对于LDU的切分，要考虑切分出来数据块的大小和顺序性。为了处理简单，以ODU处理中设定的精确限值作为切分的依据。这样切分出来的前几个数据块都可直接发送，不必再考虑和SDU的整合问题。对于切分出来的最后一个数据块，应当按照ODU处理中提到的处理方法进行处理。

为了方便传输，需要对切分出来的数据块进行处理，使其符合制定的传输协议规则。为了便于数据块的重组，在标志位中增加一个数据块序列号，约占用3个比特位，其传输协议格式如表2所示。

LDU切分后，第一个数据块保留有起始位和标志位，最后一个数据块保留有长度位和终止位。为了整合处理方便，现将其舍弃，重新添加关键字信息。由同一个LDU切

表2 LDU切分后的传输协议格式 bit

分出来的数据块，其起始位和标志位相同，使用LDU本身的起始位和标志位信息，仅根据实际改变数据块序列号，这样保证了切分出来的数据块符合整个传输协议所制定的规则。在数据接收端进行LDU数据块的重组时，就能够根据相同的数据序列号对其进行合并，并通过数据块序列号进行合并顺序的确定，确保数据重组的完整性。

4 接收端信息处理

4.1 差错检测

在北斗短报文通信的传输过程中存在着丢包的问题，据相关研究表明，北斗短报文通信单数据包的传输成功率约为95.5%；并且对于一个数据包来说存在着一定的传输出错率，随着包内数据量的增加传输出错的可能性也会增加。因此，接收端在收到数据包时，首先需要进行差错检测。

针对丢包问题的检测，通过数据包编号来进行。设定数据包编号标志位，编号取1～1 000，当发送端发送数据包时，按照从小到大的顺序对其自动进行编号。当数据包发生丢失时，可通过其相邻的数据包编号将其查找出来。假设46号数据包发生丢包问题，接收端在接收到45号包后，下一个接收到的数据包编号将为47，这样就能够检测出46号包丢失。

针对传输数据出错的检测，通过长度位关键字来进行。接收端收到数据包后，对其进行解析，通过计算DU的长度和长度位进行比较，如果结果一致，则表明DU传输正确，若不一致，则检测出传输错误。

这种方法仅为一种简单快速的检验，并不能精确的将所有错误检测出来，但是相比于其他差错检测方法而言，具有所需添加的冗余信息少，检测时间短的优势，在应急情况下具有一定的应用价值。

4.2 反馈机制

北斗短报文通信从本质上来说属于不可靠通信，再加上丢包和传输数据出错等因素，发送端不能明确的得知报文是否发送成功。在应急情况下，信息的交互显得至关重要，为了让通信双方能够知晓信息发送结果，充分利用其双向通信的性质，采用最原始的逐条反馈机制，对接收到的每一个数据包都发送一个反馈数据包。

接收端接收到数据包后，首先对其进行差错检测，然后根据检测结果，向发送端发送反馈信息，告知发送端数据包是否发送成功，数据传输是否完整，以便发送端采取相应的措施。反馈信息作为一个UDU存在，在接收端按照UDU发送方法进行操作。

当发生数据包丢失时，反馈信息中只需说明数据包编号即可；当发生数据单元传输出错时，需要发送数据类型标识以及数据序列号，并且若为LDU出错，还需要发送长数据单元标识以及数据块序列号。这样发送端在接收到反馈信息时，就能确定发送出错的原因，并定位到出错位置。

4.3 数据重传处理

4.3.1 丢包问题的处理

通信系统中解决数据丢包的问题，主要采用自动重传请求技术和前向纠错技术两种[17]。自动重传请求技术根据反馈数据包的内容，对丢失的数据包进行重新发送；前向纠错技术通过增加冗余数据来实现数据的恢复。

前向纠错技术虽然具有时延低和恢复丢包效率高的优点，但是其操作过程更加复杂，并且需要加入冗余数据包，这对于传输信道极其珍贵的应急情况而言，并不适用。相比较而言，重传技术简单而且不会带来过多的额外信息传输，因此本文采用重传技术处理丢包问题。

当通过反馈信息得知数据包丢失时，接收端根据数据类型决定是否进行重发。对于紧急数据类型的数据包，信息重要程度较高，应立即进行重发；对于普通数据类型的数据包，则可以根据信息的内容有选择的进行重发，那些可有可无的信息将不再进行重发，以节约传输信道空间。

4.3.2 传输数据出错处理

发送端在读取到反馈信息时，根据出现错误的数据单元类型采取相应的处理。当UDU出现错误时，将其进行按照紧急数据类型的处理方式进行重新发送；当ODU出现错误时，由发送者决定是否进行重传。

这种处理方法对于SDU出错的情况有很好的效果，不必将由该SDU整合而成的数据包进行全部的重传，节约了传输信道空间，同时避免了重复性传输信息，在应急情况下具有较高的实用性。

5 实验结果与分析

本文采用Matlab软件对所提出的传输机制进行模拟仿真，主要对数据类型分类以及DU的处理方法进行了验证。如图6所示，引入元胞数组的概念，将每一行看作是一个DU,某一时刻发送端所有需要发送的DU看作是一个元胞数组。第一列模拟DU的大小，第二列用“急”和“普”来标识UDU和ODU，第三列用数字来表示数据单元形成的先后顺序。为提高仿真效率，本实验中设置N=30。

为了模拟现实情况中所需处理的DU的任意性，在形成第一列的元胞数据时，首先通过‘A=randint(1,i)’产生由0和1两个数组成的1*i维矩阵；然后通过循环产生30个长度不固定的1*i维矩阵，分别组成UDU和ODU两个元胞数组,并在第二列进行标识；最后通过‘r= 1 + 30*rand([1 10])’，产生10个(1，30)范围内均匀分布的随机数，通过‘r1=fix(r)’对随机数取整，并按照产生的随机数从两个胞元数组中分别抽取相应的10行组成图6所示元胞数组，在第三列进行编号。运用对UDU和ODU的处理方法，对元胞数组进行编程处理，得到的处理结果如图7所示。