基于ASR1601的物联网4G模块数据透传软件设计

2021-11-08郑文波

广东通信技术 2021年10期

［郑文波］

1 应用背景

4G cat1 IoT模块广泛应用在物联网行业，如远程抄表、远程监控、公网无线对讲机等等。

在实际的应用中多采用MCU+IoT模块的方式来实现数据传输，MCU 通过与其连接的传感器实现数据的采集，然后通过AT 命令控制IoT模块实现数据端到端或端到云的数据传输。

IoT模块一般都有完整的AT 命令集。MCU 可以通过命令集中的数据传输子集，实现数据的传输，包括数据的接收和发送。由于数据传输子集中的AT 命令多数是异步执行的，这就带来两个问题。问题一是MCU 侧的控制部分软件编码复杂，尤其是对很多应用中MCU 是功能简单的单片机，程序是单任务的。问题二是无论数据的发送和接收，都是通过AT 命令一条一条的执行，两个AT 命令之间必须有一定的时间间隔，这样数据的传输的整体效率就不高。

为了克服MCU 数据传输部分的编程复杂和数据传输的整体效率不高这两个缺点，同时又要保证IoT模块的通用性。在保留原有的AT 命令集不变的情况下，增加了数据透传功能。数据透传功能可以有效的克服前面提到的两个缺点，因此，受到无线数据传输行业应用开发者的普遍欢迎。

2 功能设计

2.1 配置功能

IoT模块开机后默认是AT 命令模式，在这个模式下MCU 可以通过AT 命令和IoT模块交互。

通过专用的数据透传AT 命令AT+VTRANS，MCU可以命令IoT模块进入数据透传模式。在数据透传模式下，模块将暂时不能接收AT 命令，直到模块退出数据透传模式。

2.2 数据缓冲

数据传输分为上行（如图1 所示）和下行（如图2 所示），上行指MCU 发送数据给IoT模块，通过IoT模块发送到网络，下行指IoT模块从网络侧接收数据，然后通过AT uart 口发送给MCU。buffer A 中的数据发送完后，buffer A 和buffer B 可以快速切换，接着把buffer B 中的数据发送到网络侧，同时，如果MCU 有数据发送给IoT 时，就可以缓存到buffer A 中。下行数据传输类似。

图1 上行数据流

图2 下行数据流

如果某些应用场合，MCU 和IoT 之间数据传输的数据特点是：小包、频繁。那么可以进一步优化buffer的设计，增加buffer的数量，这些buffer 按顺序轮换，同时提高了MCU 与IoT模块之间数据传输和IoT模块与网络侧之间数据传输的效率，进而提高了整体的上行数据传输效率。如此设计buffer，下行数据传输也一样可以提高效率。

2.3 数据流控

在数据传输时，某些情况下会出现吞吐率A 和吞吐率B 严重不匹配的情况，比如上行当AT uart 吞吐率持续大于IoT模块发送到网络的吞吐率时，即使有buffer 缓存数据，buffer 也存在溢出的风险，数据一旦有溢出，那么就意味着数据中传输的过程中发生了部分丢失，即数据传输变得不可靠，这在实际应用中是不可接受的。

为了避免由于数据buffer 溢出而导致的数据丢失，必须进行数据流控。当数据buffer 中的数据量达到流控阀值上限时，启动流控，通知数据发送方暂停数据的发送，直到buffer 中的数据量下降到流控阀值下限。

MCU 和IoT模块之间通过AT uart 传输数据的速率，我们这里姑且称为吞吐率A，与IoT模块和网络之间的数据传输速率，我们姑且称为吞吐率B。理想的结果是吞吐率A 和吞吐率B 在任何情况下都是匹配的。上行发送数据时，MCU 通过AT uart 丢给IoT模块的数据，IoT模块马上通过网络发送出去。下行接收网络侧的数据是，IoT模块接收到数据，马上通过AT uart 丢给MCU。

实际的情况是吞吐率A 和吞吐率B 经常不匹配，导致数据传输时出现丢失数据的现场。我们采用增加数据buffer的方式来解决这个问题，即通过适当的数据缓存，来达到减少数据丢失的概率，增加上行和下行数据传输的效率。

为了进一步提高数据传输的效率，减少因为数据buffer 被占用，而导致数据传输效率受影响的情况发生，我们采用了乒乓buffer 来缓存数据。上行传输数据时，即使buffer A 中的数据正在上传到网络侧，那么buffer B还可以用于接收缓存MCU 发送给IoT模块的数据。当

2.4 维护长连接

在数据透传建立的过程中，可能会由于基站、终端受到干扰等原因，导致数据连接建立的过程中，出现异常。在数据建立连接后，在数据传输过程中或者在等待数据传输时，连接也可能出现异常，导致SOCKET 关闭，数据连接断开。

当出现连接异常时，要根据异常的不同情况，采取不同的处理方法，去尝试恢复连接，目的是维持持续的数据连接。

2.5 心跳功能

IP 资源是有限的，运营商为了基于有限的IP 资源，为尽可能多的无线数据终端提供数据服务，会定时清理长时间处于无数据收发状态（称为idle 状态）的终端。

当数据终端处于idle 状态持续时间超过运营商设定的时间（电信数据服务器的这个时间参数设置为6 分钟），运营商的数据服务器就会强制释放连接，并收回终端占用的IP。

有些应用中需要持续的数据连接，那么就要通过发送心跳包的方法，避免终端处于idle 状态持续时间超过运营商允许的最长时间。

3 流程设计

3.1 建立连接与数据透传功能

建立数据连接的过程分为两步，如图3 所示，第一步是PPP 拨号，第二步是创建SOCKET。

图3 SOCKET 创建流程

本文所述的IOT模块PPP拨号对应的AT命令格式为：

参数说明：

示例：AT+CGDATA=”PPP”,1

PPP 拨号成功后，接着需要为数据连接创建SOCKET。SOCKET 用于描述IP 地址和端口，是一个通信链的句柄，可以用来实现不同虚拟机或不同计算机之间的通信。

创建SOCKET 前，需要选择协议的类型。本文所述的IoT模块支持TCP/IP UDP 两种协议。MCU 可以在发给IoT模块建立数据透传的AT 命令中通过参数设置在两种协议中选择其一。

在IoT模块和数据接收端之间，建立一个用于数据传输的SOCKET，并且维持该SOCKET 持续有效。在端到端或端到云之间建立一个数据传输的数据通道。数据通道一旦成功创建，MCU 就可以直接把数据发送给IoT模块，而不需要每次发送数据前都要发送一堆的AT 命令来判断网络状态和创建数据连接。这样就实现了数据的透传功能。

3.2 异常情况的处理

3.2.1 建立过程中的异常

（1）无网络服务

建立数据透传之前，先查询一下终端有没有注册到网络，如果已经注册到网络，就继续查询一下是否有基站的网络服务，如果没有注册到网络或者没有网络服务，就上报错误信息给MCU。MCU 可以一段时间后再重新尝试连接。

（2）PPP 拨号失败

出现PPP 拨号失败时，如果重新尝试数次后还是不成功，可能的原因有：运营商网络原因，终端的SIM 卡欠费等。尝试次数达到了设定的最大次数，就放弃PPP 拨号，同时通过AT uart 口上报给MCU。

（3）SOCKET 无法打开

PPP 拨号成功后，终端会或获得有效的IP 地址。接着就可以尝试打开SOCKET。如果打开失败，可以再尝试几次。如果尝试几次后还是无法成功打开SOCKET，就要关闭PPP，重新打开PPP，然后再尝试去打开SOCKET。如果这样的操作循环尝试数次后还是无法打开SOCKET，就通过AT uart 口上报给MCU。这种情况最可能的原因是目标服务器有异常。

3.2.2 长连接状态下的异常

（1）SOCKET 异常关闭

导致SOCKET 异常关闭的常见原因有：目标服务器主动关闭、目标服务器异常、运营商网络异常、由于信号不好等原因导致的终端接收灵敏度大幅下降等。

SOCKET 异常关闭后，可以重新尝试打开SOCKET。如果尝试次数达到最大限制次数，还是无法成功打开SOCKET，就关闭PPP，然后重新尝试打开PPP 连接和SOCKET。如果尝试次数达到最大限制次数，还是无法打开SOCKET，就放弃建立连接，把错误信息通过AT uart口上报给MCU。

（2）SOCKET 和PPP 同时断开

如果SOCKET 和PPP 同时断开，就按照打开PPP，打开SOCKET的顺序重新建立连接，前面有阐述，就不再重复。

（3）SOCKET 未断开，数据始终发送不成功

如果连续发生数次数据发送失败时，就说明当前的连接出现了问题，这时候就要尝试断开当前的连接，然后重新建立数据透传。为了避免建立的过程中MCU 继续发送数据给IoT模块，进而导致因buffer 溢出而丢失数据，IoT模块发现有数据连续发送失败时，要把错误信息通过AT uart 口上报给MCU，然后再开始尝试重新建立连接。建立连接成功后，通过AT uart 口上报给MCU，MCU 就可以继续发送数据给IoT模块。