802.11ba (WUR) או איך לחצות נחש עם קיפוד

לפני זמן לא רב, במשאבים שונים אחרים ובבלוג שלי, דיברתי על העובדה ש-ZigBee מת והגיע הזמן לקבור את הדיילת. על מנת לשים פנים טובות למשחק רע עם Thread שעובד על גבי IPv6 ו-6LowPan, מספיק בלוטות' (LE) שמתאים יותר לכך. אבל אני אספר לך על זה בפעם אחרת. היום נדבר על איך קבוצת העבודה של הוועדה החליטה לחשוב פעמיים אחרי 802.11ah והחליטה שהגיע הזמן להוסיף גרסה מלאה של משהו כמו LRLP (Long-Range Low-Power) למאגר התקני 802.11, דומה ל-LoRA. אבל זה התברר כבלתי אפשרי ליישום מבלי לשחוט את הפרה הקדושה של תאימות לאחור. כתוצאה מכך, Long-Range ננטש ונשאר רק Low-Power, וזה גם טוב מאוד. התוצאה הייתה תערובת של 802.11 + 802.15.4, או פשוט Wi-Fi + ZigBee. כלומר, ניתן לומר שהטכנולוגיה החדשה אינה מתחרה לפתרונות LoraWAN, אלא להיפך, נוצרת כדי להשלים אותם.

אז בואו נתחיל עם הדבר החשוב ביותר - כעת מכשירים שתומכים ב-802.11ba צריכים להיות בעלי שני מודולי רדיו. ככל הנראה, לאחר שבדקו את 802.11ah/ax עם טכנולוגיית Target Wake Time (TWT), המהנדסים החליטו שזה לא מספיק והם צריכים להפחית באופן קיצוני את צריכת החשמל. מדוע התקן מספק חלוקה לשני סוגים שונים של רדיו - רדיו תקשורת ראשוני (PCR) ורדיו השכמה (WUR). אם עם הראשון הכל ברור, זה הרדיו הראשי, הוא משדר ומקבל נתונים, אז עם השני זה לא כל כך הרבה. למעשה, ה-WUR הוא בעיקרו מכשיר האזנה (RX) והוא נועד לצרוך מעט מאוד חשמל לתפעול. המשימה העיקרית שלו היא לקבל אות התעוררות מה-AP ולאפשר PCR. כלומר, שיטה זו מפחיתה משמעותית את זמן ההתנעה הקרה ומאפשרת להעיר מכשירים בזמן נתון בדיוק מירבי. זה מאוד שימושי כאשר יש לך, למשל, לא עשרה מכשירים, אלא מאה ועשרה ואתה צריך להחליף נתונים עם כל אחד מהם בפרק זמן קצר. בנוסף, ההיגיון של תדירות ומחזוריות ההתעוררות עובר לצד ה-AP. אם, נניח, LoRAWAN משתמש במתודולוגיית PUSH כאשר המפעילים עצמם מתעוררים ומשדרים משהו באוויר, וישנים בשאר הזמן, אז במקרה הזה, להיפך, ה-AP מחליט מתי ואיזה מכשיר צריך להתעורר, ו המפעילים עצמם... לא תמיד ישנים.

כעת נעבור לפורמטים ותאימות של מסגרת. אם 802.11ah, בתור הניסיון הראשון, נוצר עבור רצועות 868/915 מגה-הרץ או פשוט SUB-1GHz, אז 802.11ba כבר מיועד לרצועות 2.4GHz ו-5GHz. בתקנים "חדשים" קודמים, התאימות הושגה באמצעות הקדמה שהייתה מובנת למכשירים ישנים יותר. כלומר, החישוב תמיד היה שמכשירים ישנים יותר לא בהכרח צריכים להיות מסוגלים לזהות את כל המסגרת, מספיק שהם יבינו מתי המסגרת הזו תתחיל וכמה זמן תימשך השידור. את המידע הזה הם לוקחים מההקדמה. 802.11ba לא היה יוצא מן הכלל, מכיוון שהתוכנית מוכחת ומוכחת (נתעלם מבעיית העלויות לעת עתה).

כתוצאה מכך, מסגרת 802.11ba נראית בערך כך:

הקדמה שאינה HT ומקטע OFDM קצר עם אפנון BPSK מאפשרים לכל התקני 802.11a/g/n/ac/ax לשמוע את תחילת השידור של המסגרת הזו ולא להפריע, להיכנס למצב האזנה לשידור. אחרי ההקדמה מגיע שדה הסנכרון (SYNC), שהוא בעצם אנלוגי של L-STF/L-LTF. זה משמש כדי לאפשר לכוונן את התדר ולסנכרן את המקלט של המכשיר. וברגע זה מכשיר המשדר עובר לרוחב ערוץ אחר של 4 מגה-הרץ. בשביל מה? הכל מאוד פשוט. זה הכרחי כדי שניתן יהיה להפחית את ההספק ולהשיג יחס אות לרעש (SINR) דומה. או להשאיר את ההספק כפי שהוא ולהשיג גידול משמעותי בטווח השידור. הייתי אומר שזהו פתרון מאוד אלגנטי, שמאפשר גם להפחית משמעותית את הדרישות לספקי כוח. בואו נזכור, למשל, את ה-ESP8266 הפופולרי. במצב שידור תוך שימוש בקצב סיביות של 54 Mbps והספק של 16dBm, הוא צורך 196 mA, שזה גבוה באופן בלתי רגיל עבור משהו כמו CR2032. אם נצמצם את רוחב הערוץ פי חמישה ונפחית את הספק המשדר פי חמישה, אז למעשה לא נאבד בטווח השידור, אבל צריכת הזרם תופחת בפקטור של, למשל, לכ-50 mA. לא שזה קריטי מצד ה-AP שמשדר את המסגרת עבור WUR, אבל זה עדיין לא רע. אבל עבור STA זה כבר הגיוני, שכן צריכה נמוכה יותר מאפשרת שימוש במשהו כמו CR2032 או סוללות המיועדות לאחסון אנרגיה לטווח ארוך עם זרמי פריקה נמוכים. כמובן ששום דבר לא מגיע בחינם והקטנת רוחב הערוץ תוביל לירידה במהירות הערוץ עם עלייה בזמן השידור של פריים אחד, בהתאמה.

אגב, לגבי מהירות הערוץ. התקן במתכונתו הנוכחית מספק שתי אפשרויות: 62.5 Kbps ו-250 Kbps. האם אתה מרגיש את הריח של ZigBee? זה לא קל, מכיוון שיש לו רוחב ערוץ של 2Mhz במקום 4Mhz, אבל סוג אחר של אפנון עם צפיפות ספקטרלית גבוהה יותר. כתוצאה מכך, הטווח של מכשירי 802.11ba אמור להיות גדול יותר, וזה שימושי מאוד עבור תרחישי IoT פנימיים.

אם כי, חכו רגע... לאלץ את כל התחנות באזור לשתוק, תוך שימוש רק ב-4 מגה-הרץ של פס ה-20 מגה-הרץ... "זה בזבוז!" – תאמר ותצדק. אבל לא, זה הפסולת האמיתית!

התקן מספק את היכולת להשתמש בתת-ערוצי 40 מגה-הרץ ו-80 מגה-הרץ. במקרה זה, קצבי הסיביות של כל תת-ערוץ יכולים להיות שונים, ועל מנת להתאים את זמן השידור, נוסף Padding לסוף הפריים. כלומר, המכשיר יכול לתפוס זמן אוויר בכל ה-80 מגה-הרץ, אבל להשתמש בו רק ב-16 מגה-הרץ. זה בזבוז אמיתי.

אגב, למכשירי Wi-Fi שמסביב אין סיכוי להבין מה משודר שם. מכיוון שה-OFDM הרגיל אינו משמש לקידוד מסגרות 802.11ba. כן, בדיוק כך, הברית מפורסמת נטשה את מה שעבד ללא רבב במשך שנים רבות. במקום OFDM הקלאסי, נעשה שימוש באפנון Multi-Carrier (MC)-OOK. ערוץ 4MHz מחולק ל-16(?) תת-נשאים, שכל אחד מהם משתמש בקידוד מנצ'סטר. יחד עם זאת, גם שדה ה-DATA עצמו מחולק באופן הגיוני למקטעים של 4 μs או 2 μs בהתאם לקצב הסיביות, ובכל קטע כזה רמת קידוד נמוכה או גבוהה יכולה להתאים לאחד. זה הפתרון להימנע מרצף ארוך של אפסים או אחדים. טרחה בשכר מינימום.

רמת ה-MAC היא גם פשוטה ביותר. הוא מכיל רק את השדות הבאים:

• בקרת מסגרת

  יכול לקחת את הערכים Beacon, WuP, Discovery או כל ערך אחר לפי בחירת הספק.
  Beacon משמש לסנכרון זמן, WuP נועד להעיר מכשיר אחד או קבוצה של מכשירים, ו-Discovery פועל בכיוון ההפוך מ-STA ל-AP ונועד למצוא נקודות גישה התומכות ב-802.11ba. שדה זה מכיל גם את אורך המסגרת אם הוא עולה על 48 סיביות.

• ID

  בהתאם לסוג המסגרת, הוא יכול לזהות AP, או STA, או קבוצה של STA שאליהם מיועדת המסגרת הזו. (כן, אתה יכול להעיר מכשירים בקבוצות, זה נקרא groupcast wake-ups וזה די מגניב).

• תלוי סוג (TD)

  תחום די גמיש. בו ניתן להעביר את השעה המדויקת, אות על עדכון קושחה/קונפיגורציה עם מספר גרסה, או משהו שימושי שה-STA צריך לדעת עליו.

• שדה בדיקת מסגרת (FCS)
  הכל פשוט כאן. זהו סכום בדיקה

אבל כדי שהטכנולוגיה תעבוד, זה לא מספיק פשוט לשלוח מסגרת בפורמט הנדרש. ה-STA ו-AP חייבים להסכים. ה-STA מדווח על הפרמטרים שלו, כולל הזמן הנדרש לאתחול ה-PCR. כל המשא ומתן מתרחש באמצעות מסגרות 802.11 רגילות, ולאחר מכן ה-STA יכול להשבית את PCR ולהיכנס למצב הפעלת WUR. או אולי אפילו לישון קצת, אם אפשר. כי אם הוא קיים, אז עדיף להשתמש בו.
לאחר מכן מגיעה עוד קצת סחיטה של ​​שעות מיליאמפר יקרות המכונה WUR Duty Cycle. אין שום דבר מסובך, רק STA ו-AP, באנלוגיה לאיך שזה היה עבור TWT, מסכימים על לוח זמנים לשינה. אחרי זה, STA לרוב ישנה, ​​מדי פעם מפעילה את WUR כדי להאזין ל"האם הגיע לי משהו שימושי?" ורק אם יש צורך, הוא מעיר את מודול הרדיו הראשי לחילופי תעבורה.

משנה באופן קיצוני את המצב בהשוואה ל-TWT ו-U-APSD, לא?

ועכשיו ניואנס חשוב שאתה לא חושב עליו מיד. ה-WUR אינו חייב לפעול באותו תדר כמו המודול הראשי. להיפך, רצוי ומומלץ שזה יעבוד בערוץ אחר. במקרה זה, הפונקציונליות של 802.11ba אינה מפריעה בשום אופן לפעולת הרשת, ולהפך, ניתן להשתמש בה כדי לשלוח מידע שימושי. מיקום, רשימת שכנים ועוד הרבה בתקני 802.11 אחרים, למשל 802.11k/v. ואיזה יתרונות נפתחים לרשתות Mesh... אבל זה הנושא של מאמר נפרד.

באשר לגורל התקן עצמו כמסמך, אם כן כרגע טיוטה 6.0 מוכנה עם שיעור אישורים: 96%. כלומר, השנה אנחנו יכולים לצפות לתקן אמיתי או לפחות להטמעות ראשונות. רק הזמן יגיד כמה זה יהיה נרחב.

דברים כאלה... (ג) EvilWirelesMan.

קריאה מומלצת:

IEEE 802.11ba - Wi-Fi עם צריכת חשמל נמוכה במיוחד עבור האינטרנט המאסיבי של הדברים - אתגרים, בעיות פתוחות, הערכת ביצועים

IEEE 802.11ba: רדיו התעוררות בעוצמה נמוכה עבור IoT ירוק

רדיו השכמה תומך בתקן IEEE 802.11: מקרי שימוש ויישומים

מקור: www.habr.com