韓 麗，楊 宏，卓 蘭，柏文彥

（1.中國電子技術(shù)標準化研究院，北京 100007；2.普奧云信息科技（北京）有限公司，北京 100012）

0 引 言

物聯(lián)網(wǎng)的概念雛形可以追溯至1999年的麻省理工學(xué)院，相關(guān)學(xué)者依托射頻識別技術(shù)提出萬物皆可通過網(wǎng)絡(luò)互聯(lián)的概念。2005年國際電信聯(lián)盟ITU在《ITU互聯(lián)網(wǎng)報告2005：物聯(lián)網(wǎng)》[1]對物聯(lián)網(wǎng)概念進行擴展，提出任何時刻、任何地點、任何物體之間的互聯(lián)，無所不在的網(wǎng)絡(luò)和無所不在的計算的發(fā)展愿景。隨著外部周期性驅(qū)動力持續(xù)作用，物聯(lián)網(wǎng)進入了基礎(chǔ)性、規(guī)?；袠I(yè)需求推動的新階段[2]。

通信技術(shù)是物聯(lián)網(wǎng)關(guān)鍵核心技術(shù)之一，尤其是協(xié)議，物聯(lián)網(wǎng)協(xié)議可分為網(wǎng)絡(luò)協(xié)議和通信協(xié)議兩類，網(wǎng)絡(luò)協(xié)議包括 Ethernet、WiFi、RFID、ZigBee、Bluetooth、NB-IoT、LoRa、3G/4G等，物聯(lián)網(wǎng)網(wǎng)絡(luò)應(yīng)用部署時需要根據(jù)實際需求選擇所需的網(wǎng)絡(luò)協(xié)議[3]。通信協(xié)議主要運行在TCP/IP之上，負責設(shè)備間的數(shù)據(jù)交換和通信，如CoAP[4]、MQTT[5]、XMPP[6-7]、AMQP[8]等，這些協(xié)議有各自的設(shè)計出發(fā)點，也有特定的應(yīng)用場景和適用范圍[9-10]。當前物聯(lián)網(wǎng)實際應(yīng)用中并不存在統(tǒng)一的應(yīng)用層協(xié)議，無論基于上述哪種協(xié)議，具體物聯(lián)網(wǎng)應(yīng)用均需再額外封裝開發(fā)交互消息。

本文基于物聯(lián)網(wǎng)現(xiàn)有協(xié)議應(yīng)用和發(fā)展現(xiàn)狀，提出一種可支持多種底層承載協(xié)議的物聯(lián)網(wǎng)應(yīng)用層接入?yún)f(xié)議AAP（Access Application Protocol, AAP），可統(tǒng)一物聯(lián)網(wǎng)終端設(shè)備或物聯(lián)網(wǎng)網(wǎng)關(guān)接入物聯(lián)網(wǎng)平臺的協(xié)議，簡化物聯(lián)網(wǎng)相關(guān)應(yīng)用的開發(fā)，有助于推動物聯(lián)網(wǎng)規(guī)模化應(yīng)用的部署。

1 相關(guān)工作

CoAP[4]協(xié)議旨在適用于資源受限的物聯(lián)網(wǎng)設(shè)備，基于UDP的輕量級協(xié)議，設(shè)計原則上參考了HTTP協(xié)議。但是由于很多物聯(lián)網(wǎng)設(shè)備隱藏在局域網(wǎng)內(nèi)部，CoAP設(shè)備作為服務(wù)器無法被外部設(shè)備尋址，當前僅適用于局域網(wǎng)內(nèi)部通信。

MQTT[5]作為一種基于客戶端-服務(wù)器的消息發(fā)布/訂閱傳輸協(xié)議，設(shè)計目的是為了存儲資源和解決網(wǎng)絡(luò)資源受限環(huán)境下的通信問題，比較適合物聯(lián)網(wǎng)通信。工業(yè)應(yīng)用場景中物聯(lián)網(wǎng)連接可以采用MQTT和OPC UA結(jié)合的方法[11]。有研究[12]表明，MQTT更適用于云平臺和智能家居場景中。

XMPP[6-7]作為一種基于標準通用標記語言子集XML的協(xié)議，通信業(yè)務(wù)流程比較適合物聯(lián)網(wǎng)系統(tǒng)，但協(xié)議的安全性以及計算資源消耗的問題尚未解決。

AMQP[8]作為提供統(tǒng)一消息服務(wù)的應(yīng)用層標準高級消息隊列協(xié)議，常應(yīng)用于金融系統(tǒng)之間的交易消息傳遞。

數(shù)據(jù)分發(fā)服務(wù)DDS[13]作為OMG定義的分布式實時通信中間件規(guī)范，采用發(fā)布/訂閱方式，其缺點是不適合資源受限的無線網(wǎng)絡(luò)環(huán)境。WebSocket協(xié)議作為實現(xiàn)服務(wù)器和瀏覽器之間全雙工通信的協(xié)議標準，可用于實時數(shù)據(jù)推送。WebSocket的目的是避免服務(wù)器頻繁雙向通信時打開多個HTTP連接，從而提高工作效率和資源利用率。WebSocket協(xié)議本身消息類型數(shù)量有限，所以在應(yīng)用于物聯(lián)網(wǎng)場景時，需要額外進行消息封裝。

2 AAP概述

2.1 適用場景

由于物聯(lián)網(wǎng)的應(yīng)用場景多樣化，又面臨著多種通信技術(shù)選擇，所以物聯(lián)網(wǎng)終端設(shè)備的網(wǎng)絡(luò)接入呈現(xiàn)出復(fù)雜的態(tài)勢。根據(jù)終端設(shè)備接入是否通過物聯(lián)網(wǎng)網(wǎng)關(guān)，可將其劃分為不經(jīng)過物聯(lián)網(wǎng)網(wǎng)關(guān)的直接接入和通過物聯(lián)網(wǎng)網(wǎng)關(guān)的間接接入兩類，適用場景的網(wǎng)絡(luò)拓撲示意圖如圖1所示。AAP運行的載體可以是直接接入物聯(lián)網(wǎng)平臺的物聯(lián)網(wǎng)終端、物聯(lián)網(wǎng)網(wǎng)關(guān)和物聯(lián)網(wǎng)平臺。在具體部署時，物聯(lián)網(wǎng)終端設(shè)備可根據(jù)其具體信息處理能力和所支持的通信手段靈活選擇接入物聯(lián)網(wǎng)平臺的具體實現(xiàn)方式。

圖1 AAP的適用場景

2.2 AAP協(xié)議棧

AAP屬于應(yīng)用層消息類協(xié)議，其協(xié)議棧如圖2所示，可支持適配以下三類底層協(xié)議：

（1）基于消息代理進行發(fā)布和訂閱的消息協(xié)議，如MQTT等；

（2）基于請求/響應(yīng)的點對點應(yīng)用層協(xié)議，如HTTP等；

（3）點對點的消息包傳送協(xié)議，如WebSocket等。

圖2 AAP協(xié)議棧

3 AAP設(shè)計與實現(xiàn)

3.1 AAP協(xié)議流程

AAP協(xié)議流程分為4個階段。

（1）連接建立階段：物聯(lián)網(wǎng)網(wǎng)關(guān)或物聯(lián)網(wǎng)終端與物聯(lián)網(wǎng)平臺建立連接；

（2）平臺注冊階段：物聯(lián)網(wǎng)網(wǎng)關(guān)或物聯(lián)網(wǎng)終端向物聯(lián)網(wǎng)平臺發(fā)起注冊請求，得到回復(fù)后，物聯(lián)網(wǎng)平臺顯示物聯(lián)網(wǎng)網(wǎng)關(guān)或物聯(lián)網(wǎng)終端在線；

（3）消息交互階段：物聯(lián)網(wǎng)網(wǎng)關(guān)或物聯(lián)網(wǎng)終端與物聯(lián)網(wǎng)平臺之間進行消息交互，比如物聯(lián)網(wǎng)平臺下發(fā)命令、物聯(lián)網(wǎng)網(wǎng)關(guān)或物聯(lián)網(wǎng)終端上報數(shù)據(jù)以及兩者之間發(fā)送連接并保持；

（4）連接斷開階段：物聯(lián)網(wǎng)網(wǎng)關(guān)或物聯(lián)網(wǎng)終端向物聯(lián)網(wǎng)平臺發(fā)送注銷請求，物聯(lián)網(wǎng)平臺不再保持物聯(lián)網(wǎng)網(wǎng)關(guān)或物聯(lián)網(wǎng)終端的狀態(tài)。

3.2 AAP消息

AAP消息格式由協(xié)議行、消息頭和消息體三部分構(gòu)成。協(xié)議行包括格式標志和協(xié)議版本號等，協(xié)議行的第1個字節(jié)是消息格式標志，表示消息頭和消息體的編碼格式，比如由“J”開頭代表JSON格式，由“B”開頭代表二進制格式；消息頭包括消息類型、時間戳、應(yīng)答標志、壓縮相關(guān)信息、認證和加密信息等；消息體的具體內(nèi)容由消息類型確定。

AAP用于物聯(lián)網(wǎng)終端或物聯(lián)網(wǎng)網(wǎng)關(guān)與物聯(lián)網(wǎng)平臺之間的連接，涉及的消息類型包括物聯(lián)網(wǎng)網(wǎng)關(guān)注冊請求消息/物聯(lián)網(wǎng)網(wǎng)關(guān)注冊應(yīng)答消息、物聯(lián)網(wǎng)終端注冊請求消息/物聯(lián)網(wǎng)終端注冊應(yīng)答消息、連接保持請求消息/連接保持應(yīng)答消息和注銷，消息接收端根據(jù)消息頭中的消息類型進行消息體的識別、解碼、認證和解密。

3.3 AAP消息交互模型

AAP消息交互模型分為通知模型、請求應(yīng)答模型、選擇性應(yīng)答模型和延遲應(yīng)答模型。

（1）通知模型中，發(fā)送端將消息發(fā)送至接收者，接收者無需應(yīng)答。

（2）請求應(yīng)答模型中，發(fā)送端將消息發(fā)送至接收者，接收者將應(yīng)答消息反饋至發(fā)送端。

（3）選擇性應(yīng)答模型中，發(fā)送端請求消息的應(yīng)答標志為0，在發(fā)送指定的請求條數(shù)或間隔指定時長后發(fā)送請求消息，其應(yīng)答標志為1，要求接收端發(fā)回應(yīng)答消息，以確認接收端已收到該請求之前的全部消息。

（4）延遲應(yīng)答模型中，發(fā)送端將請求消息發(fā)送至接收端，其應(yīng)答標志為1，接收端反饋應(yīng)答消息確認收到請求消息。接收端處理完請求消息后，向發(fā)送端發(fā)送請求消息，其應(yīng)答標志為1，將處理結(jié)果報告發(fā)送端，發(fā)送端發(fā)回應(yīng)答消息，表示收到處理結(jié)果。若接收端發(fā)送完處理結(jié)果后不能接收到應(yīng)答消息，可以選擇通過請求消息重傳處理結(jié)果。

3.4 AAP適配

AAP采用消息主題實現(xiàn)與底層協(xié)議的適配，消息主題包括消息主題標識、接入賬號、消息發(fā)送或接收設(shè)備標識。不同的底層協(xié)議傳輸模式對消息主題采用不同的處理方式，底層協(xié)議采用消息代理傳輸模式時，通過消息主題進行發(fā)送和訂閱；底層協(xié)議采用點對點傳輸模式時，消息主題封裝至底層協(xié)議的消息包中。

AAP具體實現(xiàn)時可適配底層協(xié)議。與MQTT適配時，AAP消息主題直接映射到MQTT的主題，AAP消息體封裝至MQTT消息體中，AAP的接入帳號和接入密碼對應(yīng)MQTT中消息代理的客戶端帳號和密碼。表1給出底層協(xié)議為MQTT時，MQTT的主題設(shè)計示例。

表1 MQTT消息主題設(shè)計示例

與HTTP適配時，HTTP的頭部是在AAP消息主題增加相應(yīng)的頭部字段，從而實現(xiàn)應(yīng)用平臺與物聯(lián)網(wǎng)網(wǎng)關(guān)或智能感知控制設(shè)備之間的多種交互模式。與WebSocket協(xié)議適配時，AAP的消息主題和消息體直接封裝到WebSocket消息中。

3.5 AAP實現(xiàn)示例

以底層協(xié)議為MQTT，物聯(lián)網(wǎng)終端在物聯(lián)網(wǎng)平臺上注冊為例，給出AAP協(xié)議消息的具體實現(xiàn)。消息交互模型為請求應(yīng)答模型，采用JSON格式。

AAP中注冊請求消息實現(xiàn)格式示例如圖3所示，AAP中注冊應(yīng)答消息實現(xiàn)格式示例如圖4所示。

圖3 AAP中注冊請求消息實現(xiàn)格式示例

圖4 AAP中注冊應(yīng)答消息實現(xiàn)格式示例

4 結(jié) 語

綜上所述，針對物聯(lián)網(wǎng)平臺、物聯(lián)網(wǎng)網(wǎng)關(guān)和物聯(lián)網(wǎng)終端所設(shè)計的物聯(lián)網(wǎng)應(yīng)用層協(xié)議AAP，可以承載多種底層協(xié)議，既可以靈活適配發(fā)布訂閱式消息協(xié)議，也可以運行于點對點的請求響應(yīng)式HTTP協(xié)議，及面向消息的點對點連接WebSocket協(xié)議之上。AAP解決了物聯(lián)網(wǎng)應(yīng)用層協(xié)議的不統(tǒng)一問題，簡化了具體物聯(lián)網(wǎng)應(yīng)用部署的開發(fā)流程，有力促進了物聯(lián)網(wǎng)應(yīng)用的規(guī)?；l(fā)展。