18、6LoWPAN应用协议解析

6LoWPAN应用协议解析

在无线嵌入式互联网的发展中，应用协议起着至关重要的作用。不同的应用协议适用于不同的场景，下面将详细介绍几种重要的应用协议及其在6LoWPAN中的应用情况。

1. Web服务协议

Web服务在互联网上取得了巨大的成功，特别是在企业的机器对机器互联网系统中。由于许多整合了LoWPAN设备信息的后端系统已经在使用现有的Web服务原则和协议，因此预计6LoWPAN将被集成到Web服务架构中。

1.1 Web服务内容结构

Web服务内容通常基于HTTP和TCP构建，其典型结构如下：
- SOAP模型 ：一个URL标识一个服务，例如 /sensorservice ，该服务可能支持多种方法（如 GetSensor ），对应的响应由WSDL文档描述。SOAP（ application/soap+xml ）是一种XML格式，由头部和主体组成，主体可携带任意数量的消息。
- REST设计 ：直接使用HTTP传输 text/xml 内容，不使用正式的消息序列，每个资源由一个URL标识，通过在该URL上使用不同的HTTP方法来访问资源。例如，发送一个HTTP GET请求到 /sensors/temp 可能会返回一个包含传感器温度的 text/xml 主体。

然而，对于6LoWPAN的使用，所有Web服务都存在一些基本问题：
- XML太大 ：在可用的有效负载空间中标记内容时，XML通常过大。
- HTTP头开销高 ：HTTP头开销大且难以解析。
- TCP有局限性 ：TCP自身存在一些限制。

例如，一个简化的HTTP头和 application/soap+xml 内容的示例如下：

POST /sensorservice HTTP/1.1
Host: sensor10.example.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="http://www.example.com/soap.wsdl">
<m:GetSensor>
<m:SensorID>0x1a</m:SensorID>
</m:GetSensor>
</soap:Body>
</soap:Envelope>

这个简单的示例长度为424字节，在6LoWPAN网络上传输可能需要多达六个片段。

1.2 集成6LoWPAN到Web服务架构的方法

有两种基本方法可以将6LoWPAN集成到Web服务架构中：
- 网关方法 ：在LoWPAN边缘（通常是本地服务器或边缘路由器）实现一个Web服务网关。在LoWPAN内部使用专有协议来请求数据、进行配置等。网关通过Web服务接口提供设备的内容和控制。这种方法的缺点是节点和网关之间需要专有或6LoWPAN特定的协议，并且网关依赖于应用协议的内容，这会导致可扩展性和可演进性问题。
- 压缩方法 ：将Web服务格式和协议压缩到适合在6LoWPAN上使用的大小。可以使用标准来实现，有端到端和代理两种形式。
- 端到端方法 ：压缩格式由两个应用端点支持。
- 代理方法 ：中间节点进行透明压缩，使互联网端点可以使用标准Web服务。

有几种技术可用于执行XML压缩：
- WAP Binary XML (WBXML) ：为手机浏览器开发。
- Binary XML (BXML) ：由开放地理空间联盟（OGC）设计，用于压缩大量地理空间数据，目前是草案提案。
- Fast Infoset (ISO/IEC 24824 - 1) ：类似于XML的zip压缩方案。
- Efficient XML Interchange (EXI) ：W3C正在完成标准化的高效XML交换格式，对XML进行紧凑的二进制编码。EXI标准是适合6LoWPAN使用的技术，因为它支持带外模式知识，并且表示足够紧凑。

此外，还需要仔细设计与6LoWPAN设备一起使用的命名空间和模式。标准模式（如OGC的SensorML）通常太大且复杂，即使进行压缩也不适合在6LoWPAN上高效使用。使用简单模式或专门为嵌入式设备设计的模式可以获得最有效的结果。

2. 传感器网络的MQ遥测传输（MQTT - S）

MQ遥测传输（MQTT）是一种轻量级的发布/订阅协议，设计用于企业应用在低带宽广域网（WAN）链路上（如ISDN或GSM）使用。它由IBM设计，在商业产品（如Websphere和Lotus）中广泛使用，在M2M应用中很受欢迎。

2.1 MQTT - S的特点

MQTT使用基于代理的发布/订阅架构，客户端根据匹配的主题名称向代理发布数据，订阅者根据主题名称从代理请求数据。然而，MQTT需要使用TCP，其格式在6LoWPAN网络上效率不高。为了使MQTT也能在传感器网络中使用，开发了MQTT - S。

MQTT - S是一种优化的协议，可以在ZigBee、UDP/6LoWPAN或任何提供双向数据报服务的简单网络上使用。它针对低带宽无线网络、小帧大小和简单设备进行了优化，仍然与MQTT兼容，可以使用所谓的MQTT - S网关无缝集成到MQTT代理中。

2.2 MQTT - S的架构和消息结构

MQTT - S架构由四个不同的元素组成：MQTT代理、MQTT - S网关、MQTT - S转发器和MQTT - S客户端。客户端通过网关使用MQTT - S协议连接到代理。网关可以位于LoWPAN边缘路由器上，也可以集成在代理本身中。

MQTT - S消息结构由长度字段、消息类型字段和可变长度的消息部分组成：

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Msg Type | Variable Message Part ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.3 MQTT - S的协议操作

• 网关发现 ：MQTT - S包括网关发现过程，网关发送周期性的 ADVERTISE 消息，客户端可以发送 SEARCHGW 消息，收到 SEARCHGW 消息后，会向客户端发送 GWINFO 消息，提供关于网关的基本信息。客户端也可以预先配置网关位置以避免发现开销。
• 连接管理 ：客户端使用 CONNECT 连接到网关，网关以 ACK 响应。 DISCONNECT 用于结束连接或指示睡眠周期。客户端可以连接到多个网关（从而连接到多个代理），网关可以进行负载均衡。网关可以在透明模式（为每个客户端维护与代理的连接）或聚合模式（将所有客户端的消息聚合到一个代理连接中）下工作，聚合模式可以显著提高可扩展性。
• 主题管理 ：MQTT - S使用两字节的主题ID和短主题名称来优化MQTT中通常使用的长主题名称字符串。客户端可以发送 REGISTER 消息来注册发布的主题，收到 REGACK 消息指示分配的主题ID。主题名称和ID也可以预先配置。客户端使用 PUBLISH 消息发布数据，包括主题ID和可能的QoS信息。
• 订阅管理 ：客户端通过发送 SUBSCRIBE 消息到网关来订阅感兴趣的主题，收到 SUBACK 消息指示分配的主题ID。 UNSUBSCRIBE 用于从网关删除订阅。

3. ZigBee紧凑应用协议（CAP）

ZigBee应用层（ZAL）和ZigBee集群库（ZCL）指定了一种应用协议，使ZigBee设备在应用层能够互操作。ZigBee联盟维护了一系列使用单个无线电（IEEE 802.15.4）的嵌入式设备自组网规范。ZigBee的典型应用包括家庭自动化、能源应用和类似的局域网无线控制应用。

3.1 CAP的提出

ZigBee应用协议解决方案在标准UDP/IP通信（特别是6LoWPAN）上使用也会有好处，因为ZigBee应用协议的设计要求与之相似。然而，ZAL最初只考虑了ZigBee网络层原语和IEEE 802.15.4。

为了在UDP/IP上使用ZigBee应用协议和配置文件，提出了紧凑应用协议（CAP）。CAP将ZAL映射到标准UDP/IP原语，使任何ZigBee配置文件都可以在6LoWPAN或标准IP栈上使用。

3.2 CAP协议栈

CAP协议栈如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    A(IP/6LoWPAN):::process --> B(UDP):::process
    B --> C(CAP):::process
    C --> D(Data protocol):::process
    C --> E(Management protocol):::process
    C --> F(Security protocol):::process
    D --> G(Home automation profile):::process
    D --> H(Smart energy profile):::process
    D --> I(Private profile):::process
    E --> G
    E --> H
    E --> I
    F --> G
    F --> H
    F --> I

3.3 CAP的主要修改和特点

• 地址修改 ：使用IP主机和IP地址代替IEEE 802.15.4主机和IEEE 802.15.4地址。ZigBee应用层消息使用CAP数据协议放在UDP数据报中，而不是ZigBee网络层帧。
• 端口监听 ：CAP监听一个知名的UDP端口以接收主动通知。
• 地址记录 ：ZAL通过64位或16位IEEE 802.15.4 MAC地址识别节点，在CAP中由CAP地址记录代替，该记录可以包含IPv4地址加UDP端口、IPv6地址加UDP端口或完全限定域名加UDP端口。
• 配置方式 ：CAP在引导时需要配置发现缓存、信任中心、绑定协调器和绑定缓存的IP地址和端口，可以手动配置、使用DHCP、特殊DNS条目或CAP服务器发现消息进行配置。
• 协议映射 ：CAP协议只是将ZigBee应用层APS帧放在UDP中，APS交付模式映射到IP单播和广播交付，组播简化为广播。CAP支持安全传输和使用APS确认，提供有限的应用协议可靠性。CAP数据协议包含在APS有效负载中，包含ZCL命令帧，支持所有ZCL命令类型，无需修改ZCL命令。CAP管理协议修改ZigBee设备配置文件命令帧，去除IEEE 802.15.4特定帧或在可能的情况下修改地址。ZigBee的安全和密钥管理功能由CAP安全协议实现。

CAP是ZigBee和无线嵌入式互联网融合的重要一步，但它只适用于物联网应用的一个子集（如家庭自动化）。它补充了企业遥测协议（如MQTT - S）和通用嵌入式Web服务。由于6LoWPAN的IP设计和套接字概念，所有这些协议都可以在UDP/6LoWPAN网络上一起使用。CAP需要标准化才能广泛使用，可能的标准化机构包括IETF和ZigBee联盟。即将推出的ZigBee/IP智能能源2.0配置文件将不基于CAP方法，而是选择开放的IETF、W3C和IEC标准用于应用协议和数据格式，以实现端到端的互联网使用。

4. 服务发现

在无线嵌入式互联网应用中，服务发现是一个重要问题，因为设备是自主的，还需要应用程序的自动配置。服务发现用于查找提供哪些服务、它们使用的应用协议设置以及它们所在的IP地址。以下是几种常见的服务发现协议及其在6LoWPAN中的适用性分析。

4.1 服务位置协议（SLP）

服务位置协议用于IP网络上的通用服务发现，但由于典型消息的大小，需要进行优化才能在6LoWPAN中有效使用。为此，有人提出了简单服务位置协议（SSLP），它为6LoWPAN网络中的服务发现提供了一种简单、轻量级的协议。

• SSLP与SLP的互联 ：通过位于边缘路由器上的SSLP转换代理，SSLP可以轻松地与运行在IP网络上的SLP互连，从而允许从LoWPAN外部发现6LoWPAN服务，反之亦然。
• SSLP的特点 ：SSLP支持SLP的大部分功能，包括可选的目录代理使用。其头格式由一个四字节的基本头和特定的消息字段组成，服务类型、范围和URL以字符串形式携带，使用时应尽量保持字符串简短。

4.2 通用即插即用（UPnP）

UPnP旨在使家庭设备能够自动识别和控制，它使用三种协议：简单服务发现协议（SSDP）用于发现设备、通用事件通知架构（GENA）用于事件通知以及SOAP用于控制设备。设备描述以XML格式存储，在使用SSDP进行初始发现后，使用HTTP检索。

• UPnP在6LoWPAN中的问题 ：由于UPnP依赖广播以及基于XML和HTTP的描述和协议，它不能直接应用于6LoWPAN设备。
• 可能的解决方案 ：SSDP与SSLP类似，可能直接适用于6LoWPAN。通过对UPnP描述和协议应用Web服务压缩和绑定，可能可以在6LoWPAN上使用UPnP或其一个子集，但这需要为6LoWPAN和类似网络指定一个特殊版本的UPnP。

4.3 设备Web服务配置文件（DPWS）

DPWS描述了一组基本功能，使基于Web服务的嵌入式IP设备能够进行发现、设备描述、消息传递和事件处理。其目标与UPnP相似，但采用纯Web服务方法。

• DPWS在6LoWPAN中的挑战 ：由于DPWS描述是XML格式，所有消息传递都基于XML/HTTP/TCP，因此需要进行Web服务压缩和绑定以及简化才能在6LoWPAN上使用。
• DPWS的优势 ：DPWS在企业和工业系统中越来越受欢迎，因为使用DPWS的设备可以自动集成到基于Web服务的后端系统中。

5. 简单网络管理协议（SNMP）

网络管理是任何网络部署的重要功能，即使对于自主无线嵌入式设备也需要一定程度的管理。SNMP是IP网络中网络基础设施和设备管理的标准，包括应用协议、数据库模式和数据对象，当前版本是SNMPv3。

5.1 SNMP的工作方式

SNMP通过将变量暴露给管理系统，管理系统可以使用GET或在某些情况下使用SET操作来配置或控制设备。这些变量以层次结构组织，称为管理信息库（MIBs）。

5.2 SNMP在6LoWPAN中的问题

• 轮询方法的局限性 ：SNMP使用的轮询方法（GET消息）是其最大的缺点。对于使用睡眠调度的电池供电LoWPAN节点，轮询方法不起作用，并且盲目轮询可能未更改的统计信息会产生不必要的开销。因此，需要为SNMP添加基于事件的方法才能适用于6LoWPAN管理。
• 优化需求 ：相关草案分析了SNMPv3在6LoWPAN中使用的适用性，发现需要进行优化以减少数据包大小和内存成本。具体优化点如下：
  • 有效负载大小 ：目前SNMPv3需要处理最大484字节的有效负载大小，这对于管理大型6LoWPAN来说开销太大。
  • 头大小 ：SNMPv3头的大小可变，需要针对6LoWPAN进行优化，只支持最小功能子集并限制头大小。
  • 编码规则 ：有效负载的二进制编码规则（BER）使用可变长度字段，对于6LoWPAN，可能需要固定长度字段或更紧凑的编码。

总结

不同的应用协议在6LoWPAN中有各自的特点和适用场景。Web服务协议功能强大，但需要解决XML过大、HTTP头开销高和TCP局限性等问题；MQTT - S针对低带宽无线网络进行了优化，适用于传感器网络的发布/订阅场景；CAP为ZigBee应用协议在UDP/IP上的使用提供了方案，有助于ZigBee和无线嵌入式互联网的融合；服务发现协议各有优劣，需要根据具体情况进行选择和优化；SNMP作为网络管理协议，需要进行优化才能更好地适用于6LoWPAN。在实际应用中，应根据具体需求和场景选择合适的协议，并对协议进行必要的优化和调整，以充分发挥6LoWPAN的优势，推动无线嵌入式互联网的发展。

协议名称	优点	缺点	适用场景
Web服务协议	功能丰富，与现有后端系统集成度高	XML大、HTTP头开销高、TCP有局限	企业机器对机器系统
MQTT - S	轻量级，适合低带宽网络	依赖网关	传感器网络发布/订阅
CAP	使ZigBee协议适用于IP网络	只适用于部分物联网应用	家庭自动化等
SSLP	简单轻量级，可与SLP互连	功能相对有限	6LoWPAN服务发现
UPnP	方便家庭设备自动识别控制	依赖广播和XML/HTTP	家庭网络
DPWS	纯Web服务方法，易集成后端系统	需压缩简化	企业和工业系统
SNMP	标准网络管理协议	轮询开销大，需优化	网络管理