Kısa bir süre önce çeşitli kaynaklarda ve blogumda ZigBee'nin öldüğünden ve uçuş görevlisini gömme zamanının geldiğinden bahsetmiştim. IPv6 ve 6LowPan üzerinde çalışan Thread ile kötü bir oyuna iyi bir yüz kazandırmak için buna daha uygun olan Bluetooth (LE) yeterlidir. Ama bunu sana başka bir zaman anlatacağım. Bugün, komitenin çalışma grubunun 802.11ah'dan sonra nasıl iki kez düşünmeye karar verdiğini ve LRLP (Uzun Menzilli Düşük Güç) gibi bir şeyin tam teşekküllü bir versiyonunu 802.11 standartları havuzuna ekleme zamanının geldiğine karar verdiğini konuşacağız. LoRA'ya. Ancak geriye dönük uyumluluğun kutsal ineğini katletmeden bunun hayata geçirilmesinin imkansız olduğu ortaya çıktı. Sonuç olarak Uzun Menzil terk edildi ve yalnızca Düşük Güç kaldı ki bu da çok iyi. Sonuç, 802.11 + 802.15.4'ün veya kısaca Wi-Fi + ZigBee'nin bir karışımıydı. Yani yeni teknolojinin LoraWAN çözümlerine rakip olmadığını, tam tersine onları tamamlamak için yaratıldığını söyleyebiliriz.
O halde en önemli şeyle başlayalım - Artık 802.11ba'yı destekleyen cihazlarda iki radyo modülü bulunmalıdır. Görünüşe göre, Hedef Uyanma Süresi (TWT) teknolojisine sahip 802.11ah/ax'i inceleyen mühendisler bunun yeterli olmadığına ve güç tüketimini radikal bir şekilde azaltmaları gerektiğine karar verdiler. Standart neden iki farklı radyo türüne bölünmeyi öngörüyor: Birincil İletişim Radyosu (PCR) ve Uyandırma Radyosu (WUR). İlkinde her şey açıksa, bu ana radyodur, veri iletir ve alır, o zaman ikincisinde o kadar da değil. Aslında WUR çoğunlukla bir dinleme cihazıdır (RX) ve çalışması için çok az güç tüketecek şekilde tasarlanmıştır. Ana görevi AP'den bir uyandırma sinyali almak ve PCR'yi etkinleştirmektir. Yani bu yöntem, soğuk başlatma süresini önemli ölçüde azaltır ve cihazları belirli bir zamanda maksimum doğrulukla uyandırmanıza olanak tanır. Bu, örneğin on değil, yüz on cihazınız olduğunda ve her biriyle kısa bir süre içinde veri alışverişinde bulunmanız gerektiğinde çok kullanışlıdır. Ayrıca uyanmanın sıklığı ve periyodikliği mantığı AP tarafına taşınıyor. Örneğin, LoRAWAN, aktüatörlerin kendileri uyandığında ve yayında bir şey ilettiğinde ve geri kalan zamanda uyuduğunda PUSH yöntemini kullanıyorsa, bu durumda tam tersine, AP ne zaman ve hangi cihazın uyanması gerektiğine karar verir ve aktüatörlerin kendisi... her zaman uyumaz.
Şimdi çerçeve formatları ve uyumluluğuna geçelim. İlk denemede 802.11ah, 868/915 MHz bantları veya yalnızca SUB-1GHz için oluşturulmuşsa, 802.11ba zaten 2.4GHz ve 5GHz bantları için tasarlanmıştır. Önceki "yeni" standartlarda uyumluluk, eski cihazların anlayabileceği bir giriş bölümüyle sağlanıyordu. Yani, hesaplama her zaman eski cihazların çerçevenin tamamını tanımasının gerekmediği şeklinde olmuştur; bu çerçevenin ne zaman başlayacağını ve iletimin ne kadar süreceğini anlamaları yeterlidir. Giriş bölümünden aldıkları bilgi budur. Plan kanıtlanmış ve kanıtlanmış olduğundan 802.11ba da bir istisna değildi (şimdilik maliyet konusunu göz ardı edeceğiz).
Sonuç olarak 802.11ba çerçevesi şuna benzer:
HT olmayan bir giriş ve BPSK modülasyonlu kısa bir OFDM parçası, tüm 802.11a/g/n/ac/ax cihazlarının bu çerçevenin iletiminin başlangıcını duymasına ve müdahale etmemesine ve yayın dinleme moduna geçmesine olanak tanır. Giriş kısmından sonra, esasen L-STF/L-LTF'nin bir benzeri olan senkronizasyon alanı (SYNC) gelir. Frekansı ayarlamayı ve cihazın alıcısını senkronize etmeyi mümkün kılmaya yarar. Ve tam bu anda verici cihaz 4 MHz'lik başka bir kanal genişliğine geçiyor. Ne için? Her şey çok basit. Bu, gücün azaltılabilmesi ve karşılaştırılabilir bir sinyal-gürültü oranının (SINR) elde edilebilmesi için gereklidir. Veya gücü olduğu gibi bırakın ve iletim menzilinde önemli bir artış elde edin. Bunun çok zarif bir çözüm olduğunu söyleyebilirim, bu da güç kaynağı gereksinimlerini önemli ölçüde azaltmaya da olanak tanıyor. Örneğin popüler ESP8266'yı hatırlayalım. 54 Mbps bit hızı ve 16dBm güç kullanan iletim modunda, 196 mA tüketir; bu, CR2032 gibi bir şey için engelleyici derecede yüksektir. Kanal genişliğini beş kat azaltırsak ve verici gücünü beş kat azaltırsak, o zaman pratik olarak iletim menzilinde kaybolmayacağız, ancak mevcut tüketim, örneğin yaklaşık 50 mA'ya kadar azalacaktır. Bu, WUR çerçevesini ileten AP açısından kritik değildir, ancak yine de kötü değildir. Ancak STA için bu zaten mantıklıdır, çünkü daha düşük tüketim, CR2032 gibi bir şeyin veya düşük nominal deşarj akımlarına sahip uzun vadeli enerji depolama için tasarlanmış pillerin kullanılmasına olanak tanır. Elbette hiçbir şey bedava gelmiyor ve kanal genişliğini azaltmak, sırasıyla bir karenin iletim süresinin artmasıyla birlikte kanal hızının da azalmasına yol açacaktır.
Bu arada, kanal hızı hakkında. Mevcut haliyle standart iki seçenek sunmaktadır: 62.5 Kbps ve 250 Kbps. ZigBee'nin kokusunu hissediyor musun? 2Mhz yerine 4Mhz kanal genişliğine sahip olduğundan ve daha yüksek spektral yoğunluğa sahip farklı bir modülasyon tipine sahip olduğundan bu kolay değildir. Sonuç olarak, 802.11ba cihazlarının aralığının daha geniş olması gerekir; bu da iç mekan IoT senaryoları için çok faydalıdır.
Ama durun bir dakika... 4 MHz bandının sadece 20 MHz'ini kullanarak bölgedeki tüm istasyonları sessizliğe zorlamak... "BU BİR ZARARLIK!" - diyeceksin ve haklı olacaksın. Ama hayır, BU GERÇEK İSRAF!
Standart, 40 MHz ve 80 MHz alt kanallarını kullanma olanağı sağlar. Bu durumda her alt kanalın bit hızları farklı olabilir ve yayın zamanına uyum sağlamak için çerçevenin sonuna Dolgu eklenir. Yani, cihaz 80 MHz'in tamamında yayın süresini doldurabilir, ancak yalnızca 16 MHz'de kullanabilir. Bu gerçek israftır.
Bu arada etraftaki Wi-Fi cihazlarının orada ne yayınlandığını anlama şansı yok. Çünkü olağan OFDM, 802.11ba çerçevelerini kodlamak için KULLANILMAZ. Evet, aynen böyle, ittifak yıllardır kusursuz bir şekilde işleyen şeyi terk etti. Klasik OFDM yerine Çoklu Taşıyıcı (MC)-OOK modülasyonu kullanılmaktadır. 4MHz kanalı, her biri Manchester kodlamasını kullanan 16(?) alt taşıyıcıya bölünmüştür. Aynı zamanda, VERİ alanının kendisi de bit hızına bağlı olarak mantıksal olarak 4 μs veya 2 μs'lik bölümlere ayrılır ve bu tür bölümlerin her birinde düşük veya yüksek kodlama seviyesi bire karşılık gelebilir. Bu, uzun bir sıfır veya bir dizisinden kaçınmanın çözümüdür. Asgari ücrette çekişme.
MAC seviyesi de son derece basitleştirilmiştir. Yalnızca aşağıdaki alanları içerir:
- Çerçeve Kontrolü
Beacon, WuP, Discovery değerlerini veya satıcının tercih ettiği başka herhangi bir değeri alabilir.
Beacon zaman senkronizasyonu için kullanılır, WuP bir veya bir grup cihazı uyandırmak için tasarlanmıştır ve Discovery, STA'dan AP'ye ters yönde çalışır ve 802.11ba'yı destekleyen erişim noktalarını bulmak için tasarlanmıştır. Bu alan aynı zamanda çerçevenin 48 biti aşması durumunda uzunluğunu da içerir. - ID
Çerçevenin türüne bağlı olarak, bu çerçevenin hedeflendiği bir AP'yi, bir STA'yı veya bir grup STA'yı tanımlayabilir. (Evet, cihazları gruplar halinde uyandırabilirsiniz, buna grup yayını uyandırmaları denir ve oldukça hoştur).
- Tipe Bağlı (TD)
Oldukça esnek bir alan. Tam saatin, sürüm numarasıyla birlikte bir donanım yazılımı/yapılandırma güncellemesine ilişkin bir sinyalin veya STA'nın bilmesi gereken yararlı bir şeyin iletilebileceği yer burasıdır.
- Çerçeve Sağlama Toplamı Alanı (FCS)
Burada her şey basit. Bu bir sağlama toplamıdır
Ancak teknolojinin çalışması için sadece gerekli formatta bir çerçeve göndermek yeterli değildir. STA ve AP'nin aynı fikirde olması gerekiyor. STA, PCR'yi başlatmak için gereken süre de dahil olmak üzere parametrelerini rapor eder. Tüm anlaşmalar normal 802.11 çerçeveleri kullanılarak gerçekleşir; bunun ardından STA, PCR'yi devre dışı bırakabilir ve WUR etkinleştirme moduna girebilir. Ya da mümkünse biraz uyuyabiliriz. Çünkü eğer oradaysa, kullanmak daha iyidir.
Daha sonra, WUR Görev Döngüsü adı verilen değerli miliamper saatlerin biraz daha sıkıştırılması geliyor. Karmaşık bir şey yok, sadece STA ve AP, TWT'dekine benzer şekilde bir uyku programı üzerinde anlaşıyorlar. Bundan sonra STA çoğunlukla uyur ve ara sıra WUR'u açarak "Benim için yararlı bir şey geldi mi?" Ve yalnızca gerekirse trafik alışverişi için ana radyo modülünü uyandırır.
TWT ve U-APSD'ye kıyasla durumu kökten değiştiriyor, değil mi?
Ve şimdi hemen düşünmediğiniz önemli bir nüans. WUR'un ana modülle aynı frekansta çalışması gerekmez. Aksine farklı bir kanalda çalışması arzu edilir ve tavsiye edilir. Bu durumda 802.11ba işlevselliği hiçbir şekilde ağın çalışmasına müdahale etmez ve tam tersine yararlı bilgiler göndermek için kullanılabilir. Konum, Komşu Listesi ve diğer 802.11 standartları dahilinde çok daha fazlası, örneğin 802.11k/v. Peki Mesh ağları için ne gibi avantajlar açılıyor... Ancak bu ayrı bir makalenin konusu.
Bir belge olarak standardın kaderine gelince, o zaman . Yani bu yıl gerçek bir standart veya en azından ilk uygulamaları bekleyebiliriz. Ne kadar yaygınlaşacağını zaman gösterecek.
Böyle şeyler... (c) .
Önerilen Kaynaklar:
Kaynak: habr.com