关于物联网:车联网中-MQTT-心跳保活与远程唤醒设计

随着车联网的疾速倒退，其利用场景也越来越丰盛。除了在车辆行驶中进行相干数据传输上报，在车辆熄火状态下也可实现近程控车（近程启动、开启空调与开后备箱等）、OTA 降级等场景需要。为了给车主提供低时延、高成功率的应用体验，须要通过车联网平台与车机的心跳保活机制，放弃长连贯状态，并在车辆熄火的状况下疾速近程唤醒车机，实现近程控车。

本篇文章将介绍车联网平台中 MQTT 的心跳保活和近程唤醒设计。

MQTT 车联网通信音讯保活

构建大型车联网平台时，为了实现车机与平台的高效实时通信，咱们通常采纳长连贯形式通信（如 MQTT、HTTP、私有化 TCP 长连贯等），本文次要围绕 MQTT 协定长连贯通信与近程车控唤醒场景进行具体介绍。

业务场景

MQTT 自身也是采纳 TCP 长连贯的形式进行通信保活，TCP 长连贯是指通过传输层三层握手建设的连贯并长期保持，这样在应用层做消息传递申请的时候免去了 DNS 解析、连贯倡议等工夫，大大放慢了申请的速率，有利于音讯的实时性。但同时咱们须要端对端连贯的保护和连贯的保活。

MQTT 是规范的 RFC 协定，相比公有协定更加规范。同时 MQTT 协定面向物联网场景设计，具备如下性能劣势：

• 欠缺的心跳机制
• 反对遗嘱音讯
• QoS 品质等级 + 离线音讯
• 基于订阅公布的异步机制
• 低功耗，能够实现长连贯低功耗保活和近程疾速唤醒
• 采纳 Topic 主题、反对平安扩大

应用 MQTT 协定建设车机与 TSP 等平台的长连贯通信，能够无效解决对象唯一性与实时性等问题。其所具备的欠缺性能个性反对，实用于疾速构建车联网业务，因而广泛应用于车联网 TSP 平台车控数据上报、近程控车、路线救济、高精地图、ADAS 和 C-V2X 等场景。

MQTT 音讯心跳保活

MQTT Keep Alive 心跳机制

MQTT 协定设计了一套 Keep Alive 心跳机制。车机在与 Broker 建设连贯的时候，咱们能够传递一个 Keep Alive 参数，它的单位为秒。MQTT 协定中约定：在 1.5 倍 Keep Alive 的工夫距离内，如果 Broker 没有收到来自车机端的任何数据包，那么 Broker 认为它和车机端之间的连贯曾经断开；同样地，如果车机端没有收到来自 Broker 的任何数据包，那么车机端认为它和 Broker 之间的连贯曾经断开。

MQTT 还有一对 PINGREQ/PINGRESP 数据包，当 Broker 和车机端之间没有任何数据包传输的时候，能够通过 PINGREQ/PINGRESP 来满足 Keep Alive 心跳通信和连贯状态检测。

• PINGREQ

  PINGREQ 数据包没有可变头（Variable header）和音讯体（Payload），当 Client（车机端）在一个 Keep Alive 工夫距离内没有向 Broker 发送任何数据包，比方 Publish 和 Subscribe 的时候，它应该向 Broker 发送 PINGREQ 数据包。

• PINGRESP

  PINGRESP 数据包没有可变头（Variable header）和音讯体（Payload），当 Broker 收到来自 Client 的 PINGREQ 数据包，它应该回复 Client 一个 PINGRESP 数据包。

对于 MQTT Keep Alive 机制，咱们还须要留神以下几点：

• 如果在一个 Keep Alive 工夫距离内，车机端和 Broker 有过数据包传输，比方 Publish，车机端就没有必要再应用 PINGREQ 了，在网络资源比拟缓和的状况下这点很重要；
• Keep Alive 值是由 Client 指定的，不同的 Client 能够指定不同的值，咱们能够依据车机硬件和业务个性应用不同的 Keep Alive 值；
• Keep Alive 的最大值为 18 小时 12 分 15 秒（65535 秒），默认个别为 60s，咱们能够依据车机的性能抉择 10s、30s、60s 等值；
• Keep Alive 如果设为 0，则代表不应用 Keep Alive 机制。

MQTT 心跳保活车联网场景设计

通信保活

例如，假如咱们抉择了 30s 作为 Keep Alive 的心跳周期，咱们在车机端建设与 Broker 连贯的时候发送 Keep Alive 值为 30s。

• Broker 判断车机离线：

  在 1.5 倍 Keep Alive 的工夫距离即 45s 内，如果 Broker 没有收到来自车机端的任何数据包（包含 PINGREQ），那么 Broker 认为它和车机端之间的连贯曾经断开，这个时候 Broker 就会把车机端状态离线，如果客户端有遗嘱音讯，Broker 就向某个主题 Publish 这个遗嘱音讯。

• 车机判断与 Broker 断开连接：

  同理，在 Keep Alive 周期内，如果车机端没有收到来自 Broker 的任何数据包（包含 PINGRESP），那么车机端认为它和 Broker 之间的连贯曾经断开，这个时候车机端能够设置重连机制，从新连贯上 Broker。

当车辆熄火后，在肯定周期内为了实现疾速的近程控车响应，车机端的 T-Box 会主动进入低功耗的休眠模式，这时 T-Box 主控模块敞开，只保留通信模块工作（低功耗模式，个别在微安级），采纳定时唤醒的形式给 Broker 发送心跳报文以放弃长连贯 Socket 通道。

近程唤醒

之前为了实现车辆离线状态下近程控车场景，平台通常采纳短信或电话振铃的形式对车机端 T-Box 进行近程唤醒。这种传统形式存在以下弊病：

1. 时延大且成功率不高：通过短信形式往往会有运营商短信延时，T-Box 唤醒后往往须要肯定的工夫启动，这个时候近程控车的音讯有可能因为 T-box 未启动实现导致执行失败。
2. 经营老本较高：如果业务场景 1sms/ 车 / 天，100 万车机的零碎短信产生的费用老本将会很高。

所以当初主机厂大多联合越来越成熟的 T-Box 终端采纳 4G/5G 网络通信（MQTT 音讯）唤醒形式，通过低功耗的保活音讯实现车机长连贯（有些主机厂局部车型还采纳双连贯），当平台有车控音讯下发时，车机端 T-Box 收到音讯后迅速唤醒对应的 ECU 执行对应的车控指令，无效缩短了近程控车的音讯时延，晋升车主的应用感知，同时大大降低主机厂的经营老本。

基于 EMQX 的心跳保活零碎架构

零碎架构

咱们已在本系列之前的文章中介绍了如何基于 EMQX 构建千万级的车联网平台架构。EMQX 反对 MQTT 3.1、3.1.1、5.0 全协定栈，基于 EMQX 构建的音讯 Broker 集群能够完满实现 Keep Alive 心跳、遗嘱音讯、保留音讯等 MQTT 协定个性，撑持车联网平台的长连贯保活和近程唤醒场景。

EMQX 能力扩大

除了根本的心跳保活和近程唤醒场景反对外，依据车联网场景下的理论业务需要，EMQX 还减少了如下扩大性能，帮忙车联网用户构建更加适应各类场景的平台利用。

• 减少心跳超时确认机制

  思考到车联网场景车辆常常处于公开车库、隧道等网络不稳固的环境中，EMQX 减少了心跳超时确认机制，（可配置启用）在规范的 1.5 倍的 Keep Alive 周期之上再减少 1 倍的心跳工夫，即在 2.5 个 Keep Alive 周期没收到心跳报文才会认为车机端因网络中断断开连接，能够优化在弱网场景客户端频繁高低线的问题。

• 心跳周期 Keep Alive 值反对 API 近程设置

  例如在某出名主机厂的车联网场景中，为了更好地管制电瓶馈电状况，当车主在熄火后，平台能够通过 EMQX 的离线音讯性能感知车辆离线，这时 T-Box 主动进入休眠模式，并且 Keep Alive 工夫距离从 30s 主动设置为 300s。但因为 Broker 与车机建设连贯时 Keep Alive 设置的是 30s，所以须要平台告诉 Broker 同步将 Keep Alive 值批改为 300s。

EMQX 通过定制化能力扩大形式，提供标准化的 REST API 原子能力，TSP 在获取车机熄火的事件后第一工夫调用 EMQX 提供的原子能力，将 Broker 与该车机的 Keep Alive 心跳周期设置为 300s，确保车机端 T-Box 进行低功耗休眠场景仍然可能实现长连贯保活。

结语

基于 MQTT 协定欠缺的长连贯保活通信机制和 EMQX 弱小的产品能力，车联网平台开发者能够疾速构建高可用、低时延的车联网利用平台。随着 T-Box 的不断完善，通过双 APN 通信链路、提前唤醒（车主 APP 进入控车模式时提前唤醒 T-Box）或基于车机控车行为大数据分析更高效的馈电管制等形式，车企能够为宽广车主提供更加优质的车联网业务体验。

版权申明：本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/mqtt-keep-alive-design-in-the-internet-of-vehicles