電子工程、半導體、資通訊產業為了盡快讓物聯網時代到來，已對現有多種主流技術作了許多調整設定，筆者觀察檢視了這些改變后，大體可以用“減肥、輕量化Light Weight”等字詞來形容。
在6LoWPAN之后有人提出uIP的微型化IP協定，以及lwIP的輕量化IP協定，同樣是著眼于嵌入式系統需求...
例如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萬個裝置節點連線傳輸，這將成為下一個重要挑戰。
京公網安備 11010502049343號