CTimes - :物聯網,IPv6,IPv4,輕量化,雲端,MQTT,Google,谷歌,IBM

電子工程、半導體、資通訊產業為了儘快讓物聯網時代到來，已對現有多種主流技術作了許多調整設定，筆者觀察檢視了這些改變後，大體可以用「減肥、輕量化Light Weight」等字詞來形容。

例如ZigBee打從2004年就開始發展，但原有傳輸設計一次最多只能傳遞128Bytes的封包資料，如此無法支援IPv6協定，而IPv6幾乎是物聯網的必備，因為IPv4幾乎用盡，要讓東西（Thing）可以上網，肯定要更多的IP。

針對此，業界提出6LoWPAN（IPv6 over Low power Wireless Personal Area Networks），將原有的IPv6協定進行減肥，把一些比較細膩的表達資訊捨棄，把一些重複表達的資訊捨棄，終於能擠入128Bytes的現有傳輸模式中，進行傳遞。

在6LoWPAN之後有人提出uIP的微型化IP協定（主要為Cisco與Atmel所提），以及lwIP的輕量化IP協定，同樣是著眼於嵌入式系統需求，而後因物聯網觀念興起而更被看重，如近期知名的ESP8266晶片即宣布支援lwIP。

類似的，LTE過往總追求高資料傳輸率，不斷推出更快速的終端裝置類別（Category），從Category 1一路到Category 15，但為了因應物聯網，開始訂立退化性標準的Category 0，速率從10.3Mbps～3,916.6Mbps降至1Mbps，後續更將降至200kbps。

協定方面還有更多的輕量化工作，例如業界提出CoAP（Constrained Application Protocol）協定，也是一種輕量化的作法，其傳輸上採行UDP（User Datagram Protocol）協定，而非TCP（Transmission Control Protocol）協定，此也有助於減少資料傳輸量，雖然這些輕量化也帶來一些犧牲，例如UDP協定不似TCP具備連線狀態，但對於不是很嚴謹的應用，這些犧牲尚能接受。

往CoAP的更上層，是應用資料的傳遞，此方面一樣有輕量化的工程，過往是以XML（eXtensible Markup Language）格式來傳遞各種不同欄位、屬性的資料，但XML格式使封包量大增，1MB原生實質資料，改以XML格式表達後，可能增至4～10MB資料量。

因此，業界提出JSON（JavaScript Object Notation）格式，以便在某些應用場合取代XML，有效減少傳輸量，目前許多新的物聯網技術也積極支援JSON格式，如Google提出的Weave協定也支援JSON格式，MediaTek的雲端物聯網服務MCS（MediaTek Cloud Services）也支援JSON。

另外，為了管理物聯網的裝置，OMA（Open Mobile Alliance）提出其M2M的裝置管理協定，稱為OMA Lightweight M2M，從協定名稱也已看到「Lightweight，輕量」字樣，簡稱LWM2M。

再者，由IBM內部研究提出的MQTT（MQ Telemetry Transport）協定，也因為輕量特性而在近年來受到重視，很多雲端大廠多開始支援MQTT，例如Facebook的傳訊功能Facebook Messenger即採行MQTT，或2015年10月Amazon的AWS （Amazon Web Services）也支援MQTT。

由此可知，物聯網協定不單只有產業聯盟的相互較勁，如AllSeen、OIC、Apple HomeKit、ECHONET Lite（由名稱也可看出已進行輕量化）、Google Weave等的叫戰之外，還需要對現行協定進行簡化，而越是輕量則越有潛在普及機會，因為再初階入門規格的硬體也能採行。

幸運的是，這些輕量化的標準，是針對各環節進行輕量化，相互之間的衝突性不高，或即便是屬於同一類型、同一取向的協定，至目前為止也沒有高度的敵對競爭態勢。

即便克服了運算負荷、傳輸負荷問題，挑戰也還沒結束，現行傳輸站能否負荷，也是個問題，所謂傳輸站包含LTE基地台、家用Wi-Fi路由器等，Google為此提出高價、高規格的OnHub路由器，宣稱同時間可服務128個裝置的連線。

而LTE後續的5G，也明訂每平方公尺的覆蓋範圍內都能支援服務，也就是每平方公里要能支援100萬個裝置節點連線傳輸，這將成為下一個重要挑戰。