一种用于北斗大容量通信的丢包重传机制的实现

杨 双

(深圳市远东华强导航定位有限公司，河北 石家庄050081)

0 引言

随着北斗卫星导航系统的不断发展和完善，北斗三号[1]报文通信系统解决了北斗一号和北斗二号报文通信功能存在的局限性，北斗三号的短报文能力，与北斗二号相比有了进一步的提升，每次可达1 000个汉字，还可以传输图像、语音等内容，并支持每次560 bit(40个汉字)的全球通信能力[2]。

原来北斗二号通信服务容量最多只有128 字节，这对于传输图片、语音等大容量数据几乎不可能。自北斗三号卫星导航系统建设以来，北斗短报文通信服务能力有了显著的提升。而且各行各业对使用北斗传输图片、语音等大容量数据的需求越来越多，例如在发生森林灾害时，将森林失火照片传递到指挥管理中心，以便指挥中心根据灾情制定合理的救援方案；在智慧旅游行业，驴友们在移动信号差的沙漠、山谷等地，相互之间可以使用北斗短报文通信传递经历的风景；在石油勘探行业，利用北斗短报文通信可以将油井的状态数据传递给监控平台，以供生产监控平台进行监控和分析，避免油井爆炸等灾害的发生。

本文在探究传统丢包重传机制基础上，提出了一种用于北斗大容量通信的丢包重传机制，该机制利用北斗收发终端阵列部署提高北斗短报文通信的时效性，运用丢包重传机制使得数据传输更可靠，提高了北斗短报文通信成功率，满足各行各业使用北斗传输语音、图片等大容量数据的迫切要求，提高北斗应用的广泛性。

1 北斗短报文通信

北斗短报文通信[3]作为北斗三号最具特色的服务,可以直接通过卫星转发实现点对点、点对多点、兼收下属信息等服务，具有全天候、跨地域、收发业务简单等特点。短报文通信服务包括区域短报文通信和全球短报文通信两种。区域短报文通信利用3颗GEO卫星实现，具备报文通信及位置报告、应急搜救功能，报文最长长度为1 000个汉字。全球短报文通信利用14颗MEO卫星实现覆盖全球的报文通信服务，报文长度最长40个汉字[4]。

基于北斗短报文的通信服务已在船舶运输、公路交通、铁路运输、海上作业、渔业作业、森林火灾预防以及环境管理监测等领域得到了广泛的应用，覆盖部队、公安及海关等其他有特殊指挥调度要求的单位，产生显著的经济效应和社会效应。以森林防火、救灾减灾为例，北斗短报文应急通信技术服务的应用，不仅可以准确及时上报和共享灾情信息，还显著提高了救灾减灾的决策部署能力和反应能力[5]。

随着北斗三号系统的建设，北斗短报文通信相比于北斗二号，在通信容量上提升了近10倍，既能传输文字，还可传输语音和图片，尤其是在抗震救灾等恶劣环境中，可以通过语音快速将现场情况上报，还可以通过图片展示灾区的破坏程度。若要提高通信质量，就需要解决北斗大容量通信中丢包问题。针对此问题，本文提出了一种用于北斗大容量通信的丢包重传机制的实现，可实现北斗在图片、语音等大容量通信中的广泛应用。

2 丢包重传

基于北斗的短报文通信服务向用户提供了短报文通信功能，每条短报文所能发送的字节数有限，因此，一条长报文数据需要拆分成多条短报文数据后才能由北斗发送终端逐条发送给北斗接收终端。北斗接收终端只有收全所有短报文数据后，才能重组还原出原始的长报文数据。北斗短报文通信属于无线通信，无线通信信道容易受到外部环境干扰，使终端之间的数据传输不可避免地存在数据报文丢失或误码的情况。

传统的处理方法是：① 发送端配备一台指挥机，接收端配备下属用户，所有发送都由指挥机进行，丢包后重传也由单一指挥机来处理，效率较低，而且在进行丢包重传时，发送端不能执行其他的发送任务。② 接收端接收数据后，按照北斗短报文格式解析出电文内容，并按照包头标识的子包序号组装成长报文数据，组包成功后向发送端发送信息内容为0的响应包，表示数据包完成接收无子包丢失；若组包不成功，存在数据子包缺失，根据解析过程中包头标识信息定位丢失子包序号，并向发送端发送重传的包序号，同时在预计时间内没能接收到全部子包，则重复补包操作，最多重复3次；若仍不成功，则放弃本次数据包补发，转而执行其他数据传输流程[6-7]。

这种传统的丢包重传机制，能够在一定程度上提高通信链路的可靠性。但是对于包数较多，大容量数据传输的情况下，通信效率无法得到保证，而且是在单一发送终端实现，通过单一发送终端按照服务频度发送数据包，如果发生丢包重传，则单一发送终端丢包重传。采取这种方式，发送数据包较费时，而且成功率较低，用户的体验效果较差。有的方案采用了多个终端阵列，但是对于终端阵列使用分配以及丢包重传也是采取机械式的方式，没有合理利用通信链路资源。

下面对两种方式传输大容量数据所需时间进行比较：

根据不同的IC卡，北斗三号全球短报文通信频度预估主要分为1 s、5 s、30 s和60 s,由于全球用户容量较小，1 s的卡几乎不发放，5 s的卡只限特定用户申请和发放，大部分普通用户只能申请30 s和60 s的卡。

按能申请到的最高频度5 s的卡来计算，如果发送一张1 MB的图片，共需要耗时：(1×1 024×1 024×8/14 000)×5=2 995 s=0.8 h，考虑到14 000 bit不可能全部用于传输有效数据，估计传输时间在1 h左右。

同样的数据容量如果用30 s的频度进行传输，传输耗时则为6 h。

如果采用终端阵列的方案将极大地提高通信带宽，如果采用32阵列，则传输1 MB的数据量，5 s卡耗时约0.025 h(1.5 min),30 s卡耗时约0.188 h(11.28 min)。

通过表1可以看出，本文介绍的一种实现北斗大容量数据传输，在一定程度上解决了丢包影响，而且通信效率和通信容量得到大幅度提升，广泛应用于各行各业。

表1 数据传输量统计表

3 平台软件及北斗终端开发设计

3.1 北斗终端分配原理

发送端发送分包，根据分包总个数选择终端阵列中的终端。假设终端阵列为N个，共M个任务，第1个任务需要发送X1个数据包，第2个任务需要发送X2个数据包，第M个任务需要发送Xm个数据包。则发送端对于北斗终端的分配如下：

(1) 如果X1>N，即第一个任务发送包个数大于终端阵列，则按照以下分配发送终端：

北斗终端1传输第1包，第N+1,第2N+1,…,第X1-N包；

北斗终端2传输第2包，第N+2,第2N+2,…,第X1+1-N包；

以此类推，北斗终端N传输第N包，第2N包，第3N包,…,第X1包(3N

第一个任务完成后，再执行第二个任务。

(2) 如果X1+X2+…+Xp≤N(其中P

北斗终端1传输[任务1]第1包;

北斗终端2传输[任务1]第2包;

以此类推，北斗终端X传输[任务1]第X1包。

北斗终端X+1，传输[任务2]第1包;

北斗终端X+2，传输[任务2]第2包;

以此类推，北斗终端N，传输[任务P]第Xp包。

如果是丢包重传数据包[5]，则与上述北斗终端分配原理相同。

3.2 数据分包

北斗导航系统在通信时每次传输数量必须限制在14 000 bit以内，因此在进行大容量数据传输时，需要对其进行分包传输。具体是把大数据包拆分为系统所允许传输数据量n个字节的小数据包，然后每个小的数据包加上相对应的包头，包头中含有数据的序列信息，将分包依次发送出去。接收端在接收到各个数据包后，对其进行对比验证，确认所有数据包是否完全接收，完全接收的数据包合并分割前的数据，未完全接收的启动丢包重传机制[6]。

北斗三号短报文区域通信能力可达每次14 000 bit(1 000个汉字)，既能传输文字，也可以传输图片，并支持560 bit/次(40个汉字)的全球通信能力[7]。

以一张245 kB的图片，频度为5 s，通过区域短报文通信来计算：

245 kB=245×1 024 B=245×1 024×8=2 007 040 bit；

通信次数：M(总包数)=2 007 040/14 000≈144次(144个分包)；

144×5=720 s=12 min。

为了缩短发送所需的时间，采用北斗终端通信阵列，即：

令k=mod(M/N)，mod为取余数，0≤k

数据分包如图 1所示。

图1 数据分包示意图Fig.1 Schematic diagram of data subcontracting

3.3 数据重组

接收方接收到包后，根据帧唯一标识、总包数、包序号还原发送的数据内容，数据重组如图 2所示。

图2 数据重组示意图Fig.2 Data reorganization diagram

3.4 传输流程

整个数据发送过程包括数据压缩[8]、数据分包、数据发送和丢包重传[9]流程。有3种情况：

(1) 整个过程未丢包

接收端接收到最后一包数据，判断未丢包，通过接收终端阵列告知发送端信息接收完全。处理流程如图3所示。

图3 处理流程图Fig.3 Processing flow chart

(2) 接收端丢失最后一包数据的情况下

发送端向接收端发送查询指令，询问接收端是否接收完全，接收端根据接收到的包信息，解析出包序号、总包数等信息，将未接收到的包序号组帧，通过接收终端阵列告知发送端，发送端根据终端繁忙情况，选择终端阵列进行数据重发。数据发送处理流程如图4所示。

图4 数据发送处理流程(发送端主动发起询问)Fig.4 Data transmission processing flow (the sender actively initiates an inquiry)

(3) 接收端接收到最后一包数据，但是中间包有丢失的情况下

接收端接收到最后一包数据，将未接收到的包序号组帧，通过接收终端阵列告知发送端，发送端根据终端繁忙情况，选择终端进行数据重发。数据发送处理流程如图5所示。

图5 数据发送处理流程(接收端主动反馈接收信息)Fig.5 Data transmission processing flow (receiving end actively feedbacks received information)

重传包流程如图6所示。

图6 重传包处理流程Fig.6 Retransmission packet processing flow

由于发送端和接收端采用的是终端阵列，对于接收端反馈的丢包重传指令，整个阵列终端全部发送此丢包重传指令，发送端接收到一条即可以处理，相比于单一设备，使用终端通信阵列，通信成功率会大大提高。

3.5 数据丢包重传实现

假设发送端终端个数为4，接收端终端个数为4。

发送端到接收端发送流程为：发送端将大容量信息先进行压缩，压缩后的数据进行数据分包；分包后，平台处理软件通过发送终端阵列发送数据；北斗终端通过帧中的终端编号，判断是否通过自己转发，如果是，则继续转发，如果不是则丢掉。

接收端接收数据处理流程：当发送端发送完成后，向接收端发送查询是否丢包指令，如果发送端连续发送3遍接收端都没有反馈，则发送端不再等待，开始执行下一个任务。如果接收端接收到发送端发送的查询丢包指令，则根据每包的“包序号”识别丢失的包，如果未丢包，则通过4个用户机通知发送端“数据接收完毕”；如果接收不全，则通过北斗信息将“丢失的包序号”通知发送端，发送端接收解析后，将这些包重发，如果丢包重传指令发送3遍，发送端都未返回丢包数据，则不再等待，关闭此任务，开始执行新的任务。

图7为整个链路丢包工作流程图。

图7 丢包重传系统工作流程图Fig.7 Work flow chart of lost packet retransmission system

以上介绍的是发送查询指令查询接收端是否接收完全，接收端应答此消息。还有一种情况是，接收端已经接收到最后一包数据，接收端主动判断是否已经接收完全，并发送反馈指令，告知发送端“我已接收完毕”或“我有第X包未接收到”，发送端如果接收到接收完毕通知，则关闭此任务，如果接收到丢包重传指令，则开启丢包重传流程。实验结果如表2所示。

表2 通信实验记录

从表2可以看出，“北斗”卫星系统进行数据通信时数据丢包还是很严重的。数据丢包与通信终端性能以及外界干扰都有关系，但是采用了本文提出的终端收发阵列以及丢包重传原理后，只有1次补发失败，原因是当时信号终端受到强烈干扰，载噪比很低，其他情况丢包重传都成功了，最差的一次通信成功率达到了98.2%。

4 运行效果

发送端终端个数为4，接收端终端个数为4，终端采用频度为5 s的卡进行图片发送测试。

图片大小为：30.94 kB，压缩后大小为：13.923 kB，单包传输1.5 kB，分为10包，第1～9包为1.5 kB，最后一包为0.423 kB。

4个发送终端依次发送第1～10包数据，发送完成后，发送查询指令，接收端接收到查询指令后，申请重传第1、第4包数据;发送端分配两个终端重发第1、第4包，接收端接收完全后，向发送端发送接收完全通知，发送端接收后，结束此任务。

图8为发送端客户端软件，选择一张图片进行传输，图9是接收端软件，通信记录中实时显示发送和接收的内容。由图9可以看出，通过北斗发送大容量通信，发送一张30.94 kB的图片用时仅为13 s，丢包重传成功率达到100%。而且通过压缩还原接收到的图片，图片质量满足一般用户要求，达到了预想效果。

图8 发送端运行效果图Fig.8 Rendering of the sender′s operation

图9 接收端运行效果图Fig.9 Receiving end running effect diagram

5 结束语

针对北斗三号卫星导航系统需要发送语音、图片等大容量信息，提出了平台及终端架构、终端分配、数据包重传机制等，极大地扩展了北斗卫星导航系统的应用。相比于简单的依靠单一终端重传包的方式，本文方法应用更灵活，经试验验证通信成功率达到98.2%，通信速率可以提高到秒级。但是在环境受到严重干扰时，北斗短报文通信会出现丢包、误码的情况，影响了通信的成功率和用户的体验效果。如果需要解决此问题，就需要解决北斗短报文通信的传输等待时间、传输速率、丢包及误码率等问题。随着研究技术的不断进步，北斗大容量信息传输将在各个领域得到广泛应用[10]。