IoT的快速發展迫使人們重新思考傳統Wi-Fi,Wi-Fi HaLow與傳統Wi-Fi有何不同?
TECHSUGARTECHSUGAR 發表於 2021年6月22日 15:00 2021-06-22
Wi-Fi就像是我們互聯世界的氧氣,是當今最普遍的無線網路協議,承載了超過一半的網際網路流量。「Wi-Fi 是一個通用術語,指的是經過二十多年發展而成的802.11協議家族。Wi-Fi聯盟是推動Wi-Fi應用和發展的組織,該組織用數字命名法,簡化了常用的幾代Wi-Fi名稱,例如,Wi-Fi 4 = 802.11n、Wi-Fi 5 = 802.11ac 、Wi-Fi 6 = 802.11ax。您正在家裡或工作場所使用的,很有可能就是這些類型的Wi-Fi。
儘管Wi-Fi 4/5/6無處不在,但物聯網(IoT)的快速發展,迫使人們重新思考傳統Wi-Fi,揭示技術差距,重新定義802.11協議在現今超低功耗物聯網設備的無線連接世界中應該發揮的作用。物聯網和機器對機器(M2M)應用,對遠端連接和低功耗的更高要求,促使人們需要另一種為物聯網而最佳化的Wi-Fi。
Wi-Fi HaLow(發音為HEY-low)協議,透過提供超低功耗的無線解決方案,填補了這一空白,與傳統Wi-Fi相比,該方案可以在更遠的距離和更低的功耗下,連接更多的物聯網設備。該協議於2016年得到了IEEE 802.11ah任務組的批准,被Wi-Fi聯盟稱為Wi-Fi HaLow。
Wi-Fi HaLow本質上是一款低功耗、遠距離、多用途的Wi-Fi版本,在免許可的1 GHz頻譜下運行。Wi-Fi HaLow標準結合了能效、遠端連接、低延遲、高解析度影片品質數據速率、安全功能和本地IP支持,是無線連接、電池供電的物聯網設備的理想協議選擇。讓我們仔細看看Wi-Fi HaLow和傳統Wi-Fi之間的一些主要分別,以及為什麼802.11ah協議非常適合物聯網應用的連接要求。
一種省電的協議
Wi-Fi HaLow為耗電的物聯網設備,提供了卓越的能效。IEEE 802.11ah規定的各種複雜的休眠模式,使HaLow設備能夠長時間處於極低功率狀態, 節省電池能量:
TWT(Target wake time):這允許工作站(STA)和存取點(AP)預先安排一個時間,喚醒休眠的節點以存取訊號。
RAW(Restricted access window):存取點可以授予工作站子集傳輸其資料的權限,而其他工作站則被迫休眠、緩衝非緊急數據或兩者兼而有之。
BSS(Basic Service Set )空閒期:這將工作站的「允許空閒期」延長至五年。
TIM(Traffic Indication Mapping ): 更有效地分組編碼TIM,節省信標(Beacon)的傳輸時間。
短MAC標頭:將低標頭傳輸虛耗、傳輸時間和功耗,並釋放無線電波頻段。
空值PHY協議數據單元(NPD):這將類似MAC的ACKs/NACKs嵌入PHY層,以減少時間和功耗。
短信標:短(有限)信標頻繁發送以同步工作站,而完整信標的發送頻率較低。
BSS著色機制:顏色分配表示特定接入點的BSS組,而站點可以忽略其他顏色。
雙向TXOP(BDT:Bi-directional TXOP):當喚醒工作站,發現存在用於傳輸的上行和下行訊框(Frame)時,會減少介質的存取次數。BDT使用實體層協議資料單元(PPDU)的訊號(SIG)字段中的響應指示,以增加對第三方工作站傳輸的TXOP持續時間保護。
該協議的高效休眠和電源管理模式,支援物聯網設備使用電池運行多年,以及多種靈活的電源和電池大小選擇,從採用鈕扣電池的短距離物聯網設備,到傳輸超過一公里的更高功率、採用更大電池的應用。與2.4 GHz和5 GHz頻段的Wi-Fi協議相比,該協議採用的sub-GHz窄頻訊號,傳輸距離更遠,能耗更低,讓每單位能耗可傳輸更多數據。
因此,Wi-Fi HaLow晶片所需的功率僅為傳統Wi-Fi晶片的一小部分。雖然傳統Wi-Fi的數據速率較高,讓使用者能夠在2.4 GHz、5 GHz和6 GHz頻段,使用寬頻頻道快速傳輸高解析影片和下載大量檔案,但這些Wi-Fi連接的有效距離很短,電池消耗很快,需要頻繁充電或更換電池,或者最好有一個主電源連接。基於這些原因,Wi-Fi HaLow是電源受限的物聯網設備的更好選擇,這些設備需要達到更遠的距離,並能用電池運行數年,同時仍然提供較高的數據吞吐量。
Wi-Fi HaLow的sub-1 GHz協議優化了滲透率、覆蓋範圍、功率和容量。
覆蓋範圍更廣
802.11標準涵蓋的頻率範圍非常廣泛,從sub-GHz到毫米波(mmWave)。Wi-Fi HaLow是第一個在免許可的sub-GHz頻段運行的Wi-Fi標準。Wi-Fi HaLow提供的數據速率,從幾百kb/s到幾十Mb/s不等,傳輸距離從幾十公尺到一公里以上。
與傳統Wi-Fi使用的最窄的20MHz頻道相比,Wi-Fi HaLow的sub-1 GHz訊號使用更窄的頻道,從1MHz到更窄。由於頻道中的熱雜訊較低,這種20倍的頻寬系數轉化為13 dB的link budget改進。與傳統的2.4 GHz Wi-Fi相比,750 MHz – 950 MHz之間的RF頻率,需要額外增加8dB-9 dB的link budget,進而節省自由空間傳輸損耗。此外,Wi-Fi HaLow協議增加了一個範圍最佳化的調變和編碼方案(MCS10),可提供額外的3dBlink budget改進。
總之,與傳統的2.4GHz IEEE 802.11n(Wi-Fi 4)相比,Wi-Fi HaLow提供了高達24dB的link budget改進。與頻率更高、頻寬更寬的802.11ac(Wi-Fi 5)和802.11ax(Wi-Fi 6/6E)協議相比,Wi-Fi HaLowlink budget優勢進一步增強,其使用頻寬更寬的5GHz和6GHz頻譜。這就解釋了為什麼Wi-Fi HaLow訊號的傳輸距離,是傳統Wi-Fi的十倍,而不需要網路擴展器。例如,電池供電的攝影鏡頭可以放置在家裡或車庫外牆更方便的地方。照明系統可以從單個AP控制,而不管燈具是在室內還是室外的花園裡。
為終端使用者提供無線物聯網解決方案,覆蓋數百公尺的距離,而無需額外的擴展器或昂貴的手機行動網路,是802.11ah協議的一個關鍵競爭優勢。Wi-Fi-HaLow的遠端覆蓋優勢,擴展了智慧型家居和智慧型城市網路的範圍,讓使用者能夠控制1公里以外的物聯網設備,遠遠超出了傳統Wi-Fi協議的覆蓋範圍。
訊號穿透力更強
一般來說:頻率越低,覆蓋範圍越遠,穿透障礙物的能力越強。Sub-GHz 的Wi-Fi HaLow訊號可以比傳統Wi-Fi更容易穿過牆壁和其他障礙物。與2.4GHz和5GHz頻段的Wi-Fi協議相比,住宅和商業建築的建築材料和布局的變化,對sub-GHz HaLow訊號的影響較小。Wi-Fi HaLow可以穿透牆壁和建築物,這有助於減少客戶投訴和產品退貨,這些問題有時會困擾使用傳統Wi-Fi的產品。
Wi-Fi HaLow使用正交分頻多工(OFDM)調變,來校正反射和多徑環境。無論設備製造商的產品是在室內還是室外,或者是在地下室還是閣樓,Wi-Fi HaLow都可以確保設備與接入點之間有穩健的連接。這種靈活性消除了提供專有集線器或橋接設備以補償不同家庭架構的額外成本和複雜性。
高度可擴展的解決方案
單個Wi-Fi HaLow接入點可以處理多達8191個設備,是傳統Wi-Fi接入點的4倍多。在可預見的未來,這足夠連接每個LED燈泡、電燈開關、智慧型門鎖、電動窗簾、恆溫器、煙霧探測器、太陽能電池板、監控攝影鏡頭或任何可想像的智慧型家居設備。典型的家庭Wi-Fi路由器,通常支援幾十種設備。當頻寬服務提供商在家居中進行部署時,單個Wi-Fi HaLow接入點可以成為一個可擴展的平台,用於提供額外的安全和公用事業管理設備和服務。
多種訊號傳遞選項,減少了管理和控制大量HaLow設備所需的開銷。這樣可以最大限度地減少訊號衝突,並為有源設備釋放無線電波,以便以最快的調變和編碼方案(MCS)速率傳輸更多數據。與傳統Wi-Fi一樣,HaLow可以根據訊號完整性和與接入點的距離,自動調整頻寬。預定義的MCS級別支持單流、單天線產品的頻寬從150 Kbps到40 Mbps,使用的頻寬從1 MHz到8 MHz,80 Mbps的能力也可通過使用可選的16 MHz寬頻道來實現。
Wi-Fi HaLow的星形網路拓撲結構、卓越的穿透力、廣闊的覆蓋面積和巨大的容量,將無線連接從難以部署和頻寬受限的網狀網路中解放出來,簡化了網路安裝,並將總體持有成本降至最低。
具有抗噪性的免許可頻譜
與採用2.4GHz、5GHz和6GHz頻段的傳統Wi-Fi一樣,Wi-Fi HaLow使終端使用者能夠擁有自己的設備並使用免許可的sub-GHz無線電頻譜,範圍從750MHz到950MHz。Wi-Fi HaLow的可用頻率範圍、最大傳輸功率和占空比,在世界各地有所不同。(例如,美洲可用的HaLow頻譜是902 MHz至928 MHz,而在歐洲是863 MHz至868 MHz)。
Wi-Fi HaLow在工業、科學和醫療(ISM)頻段內運行,可以使用多種頻段:1MHz、2MHz、4MHz、8MHz和16MHz。頻寬越窄,訊號傳輸的距離就越遠。使用OFDM,以跨多個子頻道的數據包形式傳輸數據,這可以提高在具有挑戰性的RF環境中的性能,特別是當有來自其他無線電設備的強干擾時。前向錯誤更正(FEC)編碼也為恢復數據包提供了額外的保護,確保穩健的連接。
安全性和互通性
與其他IEEE 802.11 Wi-Fi版本一樣,Wi-Fi HaLow是一種固有的安全無線協議,支援最新的Wi-Fi認證要求(WPA3)和空中傳輸(OTA)AES加密,其數據速率可以實現安全的OTA韌體升級。
就像其他類型的Wi-Fi一樣,HaLow是一個全球公認的標準(IEEE 802.11ah),定義了連接設備如何進行安全認證和通訊。採用Wi-Fi HaLow的設備供應商,可以保證其產品和網路,將按照Wi-Fi聯盟的開髮指導來實現互通性。由於Wi-Fi HaLow是IEEE 802.11標準的一部分,Wi-Fi HaLow網路也可以與Wi-Fi 4、Wi-Fi 5和Wi-Fi 6網路共存,而不影響其RF性能。
本地IP支援
所有物聯網路都需要網路協議(IP)支持,以實現雲端連接。由於Wi-Fi HaLow是802.11 Wi-Fi標準,因此它提供本地TCP/IP支持。這種內建的IP功能,意味著物聯網連接不需要專有閘道器或橋接器。所有連接到具有Wi-Fi HaLow功能的路由器的客戶端設備,可以使用IPv4/IPv6傳輸協議,直接連結網際網路,以獲得基於雲端的服務和物聯網數據的管理。
HaLow效應:延伸範圍,拓展物聯網的可能性
傳統Wi-Fi的網路擁塞、範圍限制和較高的功耗,以及可連接到單個AP的設備數量有限,在當今物聯網設備的世界中已不再可行。這些限制阻礙了各行業出現的以物聯網為中心的新商業模式,這些模式需要更遠的距離、更大的容量、更靈活的電池和電源選項,同時最大限度地降低部署成本。
作為一種遠端協議,Wi-Fi HaLow支持那些2.4GHz和5GHz Wi-Fi無法達到的室內外物聯網應用,例如遠端監控鏡頭、門禁網路甚至無人機。其他潛在的使用案例包括大型公共場所,如體育場館、購物中心和會議中心,在這些場所,單個Wi-Fi HaLow接入點可以替代大量的接入點,無需複雜的網狀網路,簡化了安裝,降低了總持有成本。
工業物聯網、過程控制感測器、大樓自動化、倉庫和零售店等眾多應用,也將受益於這種遠端、低功耗協議,讓無數設備能夠在日益自動化的世界中保持連接。事實上,Wi-Fi-HaLow在傳統的802.11協議中因其覆蓋範圍、能效、容量和多功能性而脫穎而出。
附圖:▲Wi-Fi 4/5/6與Wi-Fi HaLow的比較
▲ 傳統的Wi-Fi 4/5/6協議,使用更高的頻率和更寬的頻寬來最大化吞吐量。
▲ 比較802.11n/ac(左)和802.11ah(右)的吞吐量與範圍。(資料來源:Sensors期刊(Basel )。2016年11月,IEEE 802.11ah:一種應對物聯網挑戰的技術,作者:Victor Baños-Gonzalez, M. Shahwaiz Afaqui, Elena Lopez-Aguilera, and Eduard Garcia-Villegas)
資料來源:https://www.techbang.com/posts/87835-wifi-halow-iot?fbclid=IwAR1P3nR4iV8V3ZhhOO4zX7GZ_9Tz4v5MBzLlCX3aXYbnOCVqPYi58LPFrmQ
ipv4轉ipv6 在 矽谷牛的耕田筆記 Facebook 的精選貼文
本篇文章帶來的是 Kubernetes 1.20 的一些整理,到底 Kubernetes 1.20 有什麼改變以及要如何升級舊有的 Kubernetes 到 1.20
官方宣稱該版本有 42 個改進,其中 11 個改進是該內容正式畢業進入 stable 版本, 15 個轉移到 beta 版本而剩下 16 個則是進入 alpha。
1. Volume Snapshot Operations (Stable)
針對容器快照的相關操作正式進入穩定版,要注意的是這個功能必須要使用的 Storage 服務有支援,同時請記得,針對任何的儲存設備,可以使用 CSI 來安裝就使用 CSI。
盡量不要繼續使用 in-tree 的方式去銜接這些設備了,因為所有的維護與修改都轉移到 CSI driver 上
2. Kubectl Debug (Beta)
Kubectl alpha 之前的子指令 debug 已經正式轉移到 beta 版本,未來可以直接使用 kubectl debug 的指令來幫忙一些資源的驗證與處理。
譬如
a. 創建一個 pod 部署到指定的節點上並存取節點上的檔案系統來提供對節點的除錯功能
b. 針對運行 crash 的 pod 除錯
3. Dual IP Stack IPv4/IPv6 (Alpha)
IPv4/IPv6 功能重新實作,未來將可以對單一 Serivce 同時指派 ipv4 + ipv6 的地址,同時也可以針對現存單一 ipv4 的 service 進行轉換
4. Graceful node shutdown (Alpha)
過往刪除 Pod 時都會有所謂的 pod lifecycle 等階段來處理一切狀態,但是當節點被關機時,節點上方運行的 Pod 並不會遵循 Pod lifecycle 來處理。
這個新的功能將會讓 Kubelet 去感知到節點正在關閉,並且能夠針對正在運行的Pod去提供 graceful shutdown 的過程
更多的討論可以參考下列文章或是直接看官方全文,滿多功能都慢慢改變
另外要注意的是,每次改版都要注意 API 是否有改變名稱,非常推薦使用如 kube-no-trouble 這類型的工具去檢查當前部署資源的 APIVersion 是否有即將要被捨棄的,避免 k8s 更新後應用程式都無法部署上去的情況發生
https://faun.pub/whats-new-in-kubernetes-version-1-20-and-how-to-upgrade-to-1-20-x-5ea72f904e7d
ipv4轉ipv6 在 矽谷牛的耕田筆記 Facebook 的精選貼文
這是一篇幻想文,幻想如果你可以重新設計 Kubernetes,你會希望有什麼樣的改動。也因為是幻想文,所以以下所提的東西不一定真的可以實作,也沒有考慮實作上可能會有什麼困難。原文非常的長,所以這邊就稍微列出一些內容
# 前提
作者(David Anderson, MetalLB 的主要貢獻者)認為 Kubernetes 真的很複雜,從 MetalLB 的開發經驗來看,幾乎無法開發出一個永遠不會壞且與 k8s 整合的軟體。
k8s 發展快速,一些不相容的修改也很難除錯,往往導致這些整合應用程式一起壞掉。
此外,作者使用 GKE 的經驗讓他覺得就算是這些k8s專家,也很難大規模環境中平安順利的使用 k8s.
作者認為 k8s 就像是管理平台內的 c++,功能非常強大,什麼都可以做,但是它會一直傷害你,直到你奉獻餘生該領域內。
作者期盼有一天,可以出現一個像是 go 語言的管理平台,簡單,優雅,容易學習
接下來就來看一下如果時光倒流,作者會希望 k8s 有哪些功能
# Mutable Pod
不像其他的資源一樣, Pod 這個資源基本上是不能修改的,有任何的更動都需要先刪除,後重新部署這樣兩步走來處理。
作者希望可以有一種 Pod 是可以支援即時修改的。
舉例來說,我透過 kubectl edit 修改了 Pod Image,然後只要透過 SIGTERM 送給 Runc 底層容器,然後當該 Container 被重啟,就會使用新的設定。這一切的發生都在同一個 Pod 的資源內,而不是重新產生一個新的 Pod
# Version control all the things
當 Pod 可以修正後,下一個作者想要的功能就是基於 Pod 本身的 Rollback。這意味希望叢集內可以有這些資訊可以去紀錄每次的變化
為了實現這個功能,可能每個節點上面也要去紀錄過往的所有 image 版本資訊,並且加上 GC 等概念來清除過期或是太舊的內容
# Replace Deployment with PinnedDeployment
相對於 Deployment, PinnedDeployment 最大的改動就是一個 Deployment 內可以同時維護兩個版本的 Pod。
舉例來說,我今天要將 Nginx 從 1.16 升級到 1.17,我可以透過 PinnedDeployment 去部署 Nginx,其中 1.16 佔了 60% ,而新版本 1.17 佔了 40%。
當一切轉移都沒有問題後,可以逐漸地將新版本的比例遷移到 100% 來達成真正的移轉。
原生的 Deployment 要達到這個功能就要創建兩個 Deployment 的物件來達到這個需求。
# IPv6 only, mostly
作者期望能的話,想要把 k8s networking 內的東西全部移除,什麼 overlay network, serivce, CNI, kube-proxy 通通移除掉。
k8s 全面配置 IPv6,而且也只有 IPv6,通常來說你的 LAN 都會有 /64 這麼多的地址可以分配 IPv6,這個數量多到你根本不可能用完 (2^64)。
也因為都有 public IPv6 的緣故,所有的存取都採用 Routing 的方式,封裝之類的玩法也不需要了。
文章內還提了很多東西,譬如說如果今天真的需要導入 IPv4 於這個純 IPv6 的系統上,可以怎麼做,如何設計 NAT64 等,算是非常有趣的想法
# Security is yes
作者認為安全性方面要最大強化,預設情況下要開啟 AppArmor, seccomp profile 等控管機制,同時也要全面禁止用 Root 來運行容器, 基本上就是用非常嚴格的方式來設定安全性方面的規則。
目前 Kubernetes 內的資源, Pod Security Policy 非常類似作者想要完成的東西,通過這種機制確保所有部署的 Pod 都會符合這些條件。唯一美中不足的是 Pod Security Policy 也不是預設就有的規則。
# gVisor? Firecracker?
從安全性考量出發,是否預設改使用 gVisor 或是 Firecracker 這類型的 OCI Runtime 而非 Runc,同時搭配上述的各種安全性條件來打造非常嚴苛的運行環境
# VMs as primitives
是否可以讓 kubernetes 同時管理 container 以及 virtual machine,也許就會像是將 kubevirt 變成一個內建的功能,讓 kubernetes 更加靈活的使用
除了上面之外,文章內還有許多其他的想法,但是內容都滿長的,如果有興趣的可以點選下列連結參考看看
https://blog.dave.tf/post/new-kubernetes/
ipv4轉ipv6 在 全球43 億個#IPv4 地址耗盡,轉至#IPV6 為所趨... - Facebook 的推薦與評價
全球43 億個#IPv4 地址耗盡,轉至#IPV6 為所趨https://news.xfastest.com/others/72928/43e-ipv4-addr/?fbclid= ... ... <看更多>
ipv4轉ipv6 在 无需公网IPV4地址,手机通过公网IPV6,远程访问软路由Openwrt 的推薦與評價
无需公网 IPV4 地址,手机通过公网 IPV6 ,远程访问软路由Openwrt格式:https://[ IPV6 地址]:端口号. ... <看更多>
ipv4轉ipv6 在 ipv6轉ipv4 - Mobile01 的推薦與評價
小弟在外住宿用的是4G sim卡上網,利用4G dongle E8372在接到asus的分享器最近才發現遠傳有支援ipv6,所以想申請來透過duckdns轉址但不知道這樣可不可行有查到一篇文章 ... ... <看更多>