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

物聯網通訊協定、技術的戰火仍持續發燒。

高層次的標準（在此指應用層）即有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年先行。由此可知，通訊技術、協定的物聯網熱戰，恐怕短期內不易停火。