過去SONY社長安藤國威應邀，來台灣年底資訊月進行演講時曾說到：SONY未來的數位產品都將支援IPv6，因為歐美已經把IPv4申請與使用了差不多，加上日本電子產品年產量這麼多，必然要使用IPv6才能與Internet接軌。

而今年，一位台北科技大學的教授在一個場合中說道：物聯網要發展必須等到IPv6夠成熟普及才有可能，否則任何環境位置、器物都要上網，IP數根本不夠。事實上即便在IPv4的有限IP下，只要讓閘道器獲得IP，不一定每個感測節點都要具有IP，且閘道器與節點間的溝通方式標準，應當也是可行，不一定非要到各節點IP。

圖一 : 現階段的物聯網，尚缺乏最佳的通訊方式，也缺乏一致的通訊方式。

不過，上述也點出了一點，那就是現階段的物聯網，尚缺乏最佳的通訊方式，也缺乏一致的通訊方式，因此已有許多資通訊大廠佈局於此。

例如Google購併的Nest Labs就提出Thread通訊協定，Nest Labs技術主管認為現有通訊協定對家用物聯網環境而言沒有一個是合適的，因而另行制訂Thread協定，該主管認為Wi-Fi會有路由器故障就完全停擺的問題，ZigBee的路由協定較無效率也較耗電，ZigBee PRO缺乏原生性的IP協定支援，Z-Wave一樣不支援IP且技術偏封閉，OpenWSN則在安全性上不足。

ARM購併Sensinode Oy

Google購併Nest Labs，知名的ARM則在2013年8月購併芬蘭的Sensinode Oy，為的也是佈局物聯網所需的通訊協定，購併Sensinode Oy後取得6LoWPAN（讓ZigBee網路與IPv6接軌的協定）、CoAP、OMA LW M2M、MQTT、TLS、DTLS等，其中MQTT、CoAP確實是因應物聯網而有的協定。

圖二 : ARM mbed支援多種IoT協定

在購併Sensinode之前，ARM本身就有一個穿戴式、物聯網的開放原始碼專案，稱為mbed，購併Sensinode後，ARM把這些通訊協定軟體進行分配，一部份撥給mbed OS，即物聯網無線感測器節點用的作業系統與相關軟體，另一部份撥給mbed Device Server，即物聯網閘道器所用的相關軟體。

類似的，Intel很早即購併Wind River（開發工具）、McAfee（資訊安全）等軟體業者，也是為了強化嵌入式應用市場，因此相關軟體也用於物聯網應用上，例如傳輸加密安全方面即倚賴McAfee。

值得注意的是，雖然業者發動購併或提出新通訊協定技術，是為了讓自身的本有業務，能更順利擴展延伸到物聯網市場，但畢竟購併與發展新技術也是要花費成本時間，單純從原有業務回收此一成本，可能有些難度。

因此，Nest Labs雖然表示Thread技術不收權利金，但依然與其他業者共同成立了Thread Group，負責對採行Thread技術的電子產進行測試驗證，而驗證自然需要收費，加入Thread Group的會員企業也要支付會費。

同樣的，ARM將Sensinode的軟體分別撥給mbed OS與mbed Device Server後，前者ARM採完全免費策略，但後者則需要收授權費。

Qualcomm購併CSR

當然，Bluetooth也開始朝物聯網應用方向努力，4.1版的Bluetooth也能夠用Mesh方式構成網路，因此協定部份必然也要新開發、新驗證，也因為Mesh技術的出現，使Qualcomm購併CSR（CSR的藍牙Mesh技術稱為CSRMesh），希望能掌握另一種切入物聯網市場的機會，且在此之前Microchip也想購併CSR。

協定不僅上述幾個，其他尚有XMPP、DDS、AMQP等，以上所談均是網路層面、偏底層的物聯網通訊協定，而之前OIC與AllSeen所角逐的，是應用程式層面、偏高層的物聯網通訊協定。

且眾人皆知OIC與AllSeen是重量級科技業者的集合，但高層次的物聯網通訊標準，也要把政府、國際機構的想法一併考慮，如歐洲ETSI提出自有的M2M標準，國際間也合作提出OneM2M標準等。

關於這些，國外甚至有文章直接以「IoT Protocol War」來形容，很明顯的，掌握物聯網的關鍵通訊協定，如同卡到交通幹道、黃金地段的重要位置，這也是各業者、機構均積極佈局、研擬、購併的原因，短期內恐難但到停戰止歇。

各方通訊標準皆為物聯網動起來

目前物聯網常用的一種無線通訊方式是Sub-1GHz，即是指低於1GHz頻段的通訊，如315MHz、433MHz、868MHz、915MHz等，此方面缺乏標準，各業者各行其是，但IEEE有意統一此一應用，提出IEEE 802.11ah，預計2016年3月完成制訂。

3GPP R12

IEEE 802.11標準某種程度上代表著Wi-Fi陣營，而3GPP陣營也不放過市場機會，在現行LTE Advanced的後續標準中增訂內容，提出機器型通訊（Machine-Type Communications, MTC），期望用LTE基地台來充當閘道器，接收大量的感測器節點的感測資訊，此已經列入3GPP R12之後的技術提案。

Bluetooth 4.1

再來是Bluetooth，4.0版的Bluetooth進入Bluetooth Smart、Bluetooth Low Energy（BLE）的新時代，4.0版增訂的兩項應用型態：防丟器與Beacon室內導覽，目前都在大幅成長中，但Bluetooth也在2013年12月提出4.1版，4.1版提出Mesh連接型態，不再受限於過去Scatternet的主僕角色明確的連接型態，很明顯是針對物聯網市場而來，因為物聯網的基礎是無線感測器網路（Wireless Sensor Network, WSN），此網路多使用Mesh連接型態，或稱Ad-hoc型態，即隨意連線的意思。

圖三

而近期Qualcomm購併CSR，CSR在過去古典藍牙（Bluetooth Classic）是最大市佔率的晶片業者，但近年來表現不盡理想，而之所以能被Qualcomm購併，主要在於CSR提出的新技術CSRmesh，有助於開拓物聯網市場。同樣的著眼，使Microchip試圖購併CSR，但最終因出價較低而被Qualcomm得手。

另外也不能忽視本來就是物聯網位置的ZigBee，其中數位家庭、家用物聯網被認為最重要，所以ZigBee的諸多應用型態，以家庭自動化最先完成定義，早於2007年就完成，稱為ZHA（ZigBee Home Automation）。

不過ZHA的推行進度仍不如理想，ZigBee聯盟中的GreenPeak公司於2013年1月提出Open Smart Home Framework（簡稱OSF），試圖只取廣大ZigBee的一部分來專精、加速發展，好讓家庭物聯網更快普及。

Tread

但是OSF也推行有限，因而2014年7月Google旗下的Nest Labs結合另6家業者共同提出Thread無線技術，Thread頗類似ZigBee IP技術，但後者主要在支援公用事業的節能管理，即ZSE 2.0（ZigBee Smart Energy），前者則鎖定家庭自動化。

圖四 : Nest Labs結合6家業者共同提出Thread無線技術

為何要再行提出Thread？Nest Labs方面認為，Wi-Fi因為集中由路由器掌控一切，一旦路由器故障，整個Wi-Fi網路就會停擺，等於單點故障影響一切，這個不能接受。而Z-Wave技術不支援原生IP協定，且它的閘道器過於複雜，且不是很開放性的標準。

另外ZigBee IP的路由協定不是很有效率，不能很省電，ZigBee PRO也一樣不是原生支援IP，或者OpenWSN雖表現理想，但較缺乏傳輸加密，以及缺乏新增節點時的安全驗證。總之，Nest Labs認為各種現行標準都有些不足，而Thread是更理想的選擇。

Thread技術預計2015年正式提出1.0版，而且記取過去Google發展標準的一些教訓，Thread提出後暫時沒有後續展望規劃（Roadmap），就只會有1.0版，至少持續整個2015年，以避免規格的紛亂（Fragment），Android即受此困擾過。

Thread技術目前免權利金，不過加入Thread Group的業者會員需要繳年費，Thread Group也將在2015年規格發佈後，提供Thread產品的測試認證。

結論

綜合上述，Wi-Fi Alliance的IEEE 802.11ah、3GPP的3GPP R12、Bluetooth SIG的4.1、ZigBee Alliance的ZHA或OSF、Google/Nest Labs的Thread等，都在角逐全面或家庭領域的物聯網市場，而這些都還是通訊底層的互通標準，如Allseen、OIC則是應用高層的互通標準，也是另一番角力。

不僅業者結盟投入，也不僅現有聯盟延伸投入，包含國區或全球管理機構也熱衷，如歐洲的電信標準組織ETSI（European Telecommunication Standards Institute）、美國的ATIS（The Alliance for Telecommunications Industry Solutions）、TIA（Telecommunications Industry Association），及世界電信組織ITU-T（International Telecommunications Union-Telecommunication Standardization Sector）等，也都在制訂M2M相關標準，看來物聯網仍需一大段時日才能走向共通。

圖五

物聯網通訊路線的不同主張

從2013年9月Intel宣布大力進軍穿戴式電子與物聯網，及張忠謀直言半導體業的未來為物聯網後，物聯網熱潮已延續一年多，但物聯網的通訊方式各家各有看法，且認為現有的通訊方式仍不足以實現理想的物聯網，因而紛紛訂立新標準、新協定。

圖六 : Intel力主的OIC是希望建立一個共通的標準，確保裝置與裝置間的連結性。

高層次的標準（在此指應用層）即有Qualcomm為主的AllSeen，以及Intel力主的OIC，但在此我們不談高層標準，而專注在底層基礎標準，此方面也已戰鬥了一年，至今未停歇。

2013年12月Bluetooth 4.1版推出後，Bluetooth也可以支援Mesh型網路，擺明進軍物聯網，且宣布支援IPv6、6LoWPAN，但具體的支援方式則未明確定義。而後2014年1月Google買下Nest Labs，而後Nest Labs提出Thread通訊協定，該協定與ZigBee相同，均使用IEEE 802.15.4基礎所發展成，亦即只要換掉現有ZigBee晶片的韌體，就能改行Thread協定，不需要為此設計或生產新晶片。

已有ZigBee為何還要推行Thread？Thread主要強調支持IPv6、6LoWPAN等協定，ZigBee雖也能支援IPv6、6LoWPAN，但僅限於ZigBee IP，ZigBee/ZigBee PRO與ZigBee RF4CE則否，但ZigBee IP目前僅限智慧電網、電動車充電使用，ZigBee聯盟現階段無意在物聯網領域全面採行。

為何ZigBee聯盟不願全面採行？原因在於成本與功耗，若每個感測器節點都能以IP協定通訊運作，節點的運算效能、硬體資源必須更高，連帶增加成本與用電，因此認為現階段只要閘道器支援IP協定即可，外界若希望得知每個節點的狀態，或操控節點運作，只要連線至閘道器，透過閘道器進行讀寫操控，也能達到相同效果。

Thread的另一個主張是避免單點故障，所以即便Thread主打數位家庭的物聯網應用，也要求要有2個閘道器，不可只裝設1個。所謂單點故障即是單一裝置故障時，導致整個系統停擺，例如家用的Wi-Fi路由器一旦壞去，家中所有Wi-Fi裝置都會無法使用。

也因為ZigBee聯盟尚未有IP全面普及化的打算，因此2014年10月的ZigBee 3.0標準出爐，僅是將原有ZigBee PRO上的6個應用型態整合成一體，進行歸納統整動作，而非加入新功效、新應用。

相對的，Thread與Bluetooth的支持者認為IP化是不可逆的趨勢，因此均力主感測節點能配發到IP，以IP協定進行通訊，所以2014年12月新制訂完成的Bluetooth 4.2，就提出IPSP的型態（Profile）標準，使IPv6/6LoWPAN的應用方式標準化，即呼應與延續之前發表的Bluetooth 4.1。

Bluetooth用4.1、4.2版因應物聯網，ZigBee用3.0版因應物聯網，而Thread也預計在2015年1月推出1.0版標準，且Thread方面已表示暫時不提出後續的標準展望路線圖（Roadmap），且保證整個2015年就只會有Thread 1.0版，不會有更新改版。

Thread方面此一主張與作法，推估是記取Google過往推行Android的教訓，過頻繁推出新版、且戰且走的標準訂立，使Android的版本過於零碎、紊亂，成了後續統合上的難題。

所以，Thread將集中火力推展1.0版，不傾向密集改版，而不提供後續展望，也讓業者不要再觀望，直接有決心從1.0版就投入，讓標準推行的氣勢更廣泛有效。

當然，Wi-Fi、LTE-Advanced也沒有坐視，LTE-Advanced的3GPP機構，近期提出3GPP R12版即已加入一些物聯網功效，但更完整的物聯網功效要到R13版才有，Wi-Fi倚賴的IEEE 802.11組織，也以IEEE 802.11ah為物聯網發展目標，但目前規劃至2016年3月標準才能出爐，但在此之前，仍不排除有人偷跑，先推出Pre版、Draft版的方案，過去的11n、11ac均勢如此，多比正式標準早1、2年先行。由此可知，通訊技術、協定的物聯網熱戰，恐怕短期內不易停火。