Wi-Fi RTT‏ (IEEE 802.11mc, ‏ IEEE 802.11az)

התכונה Wi-Fi Round Trip Time (RTT) ב-Android 9 מאפשרת למכשירים תומכים למדוד את המרחק למכשירים תומכים אחרים: בין אם מדובר בנקודות גישה (AP) או במכשירים עמיתים ב-Wi-Fi Aware (אם Wi-Fi Aware נתמך במכשיר). התכונה הזו, שמבוססת על פרוטוקול IEEE 802.11mc ו-IEEE 802.11az (זמינה מ-Android 15), מאפשרת לאפליקציות להשתמש במיקום משופר ובזיהוי מיקום.

דוגמאות ומקור

כדי להשתמש בתכונה הזו, צריך להטמיע את ממשק ה-HAL של הספק. ב-Android מגרסה 14 ואילך, ממשק ה-HAL של הספק מוגדר באמצעות AIDL. ב-Android מגרסה 13 ומטה, ממשק Vendor HAL מוגדר באמצעות HIDL. ב-Android 8.0, ‏ HIDL החליפה את המבנה הקודם של שכבת הפשטת החומרה (HAL) ששימש לייעול ההטמעות על ידי ציון סוגים וקריאות לשיטות שנאספו בממשקים ובחבילות.

כדי להשתמש בתכונה Wi-Fi RTT, פועלים לפי ההוראות בממשק ה-Wi-Fi. בהתאם לממשק שהוטמע, זהו:

  • ‫AIDL: hardware/interfaces/wifi/aidl
  • ‫HIDL: hardware/interfaces/wifi/1.0 ואילך.

אפשר לעיין ב-Wi-Fi HAL מדור קודם כדי לראות איך הוא קשור לממשקי AIDL ו-HIDL: hardware/libhardware_legacy/+/android16-qpr2-release/include/hardware_legacy/rtt.h.

הטמעה

כדי להטמיע Wi-Fi RTT, צריך לספק תמיכה גם ב-framework וגם ב-HAL/firmware:

  • Framework:

    • קוד AOSP
    • הפעלת Wi-Fi RTT: נדרש feature flag
  • תמיכה ב-HAL של Wi-Fi RTT‏ (IEEE 802.11mc או IEEE 802.11az) (שמשמעותה תמיכה בקושחה)

כדי להטמיע את התכונה הזו, צריך להטמיע את ממשק ה-Wi-Fi AIDL או HIDL ולהפעיל את ה-feature flag:

  • ב-device.mk שנמצא ב-device/<oem>/<device>, משנים את משתנה הסביבה PRODUCT_COPY_FILES כך שיכלול תמיכה בתכונת Wi-Fi RTT:

    PRODUCT_COPY_FILES += frameworks/native/data/etc/android.hardware.wifi.rtt.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.wifi.rtt.xml
    

אחרת, כל מה שנדרש לתכונה הזו כלול ב-AOSP.

רנדומיזציה של כתובות MAC

כדי לשפר את הפרטיות, כתובת ה-MAC שמשמשת במהלך עסקאות Wi-Fi RTT צריכה להיות אקראית, כלומר, היא לא יכולה להיות זהה לכתובת ה-MAC המובנית של ממשק ה-Wi-Fi. עם זאת, כחריג, כשמכשיר משויך לנקודת גישה, הוא יכול להשתמש בכתובת ה-MAC שאליה הוא משויך לכל עסקאות ה-RTT עם נקודת הגישה הזו או עם נקודות גישה אחרות.

אימות

קיימות בדיקות של חבילת הבדיקות לתאימות (CTS) של Android לתכונה הזו. מערכת CTS מזהה מתי התכונה מופעלת וכוללת באופן אוטומטי את הבדיקות שקשורות אליה. אפשר גם לבדוק את התכונה הזו באמצעות חבילת בדיקות הספקים (VTS).

בדיקות יחידה

בדיקות החבילות של Wi-Fi RTT מבוצעות באמצעות:

בדיקות שירות:

atest com.android.server.wifi.rtt

בדיקות בחשבון ניהול:

atest android.net.wifi.rtt

CTS

קיימות בדיקות של חבילת הבדיקות לתאימות (CTS) של Android לתכונה הזו. מערכת CTS מזהה מתי התכונה מופעלת וכוללת באופן אוטומטי את הבדיקות שקשורות אליה. נקודת גישה שתומכת ב-Wi-Fi RTT ‏ (IEEE 802.11mc) צריכה להיות בטווח של המכשיר שנבדק.

אפשר להפעיל את בדיקות ה-CTS באמצעות:

atest WifiRttTest

כיול

כדי ש-Wi-Fi RTT יפעל בצורה טובה, הטווחים שמוחזרים בפרוטוקולים 802.11mc או 802.11az צריכים להיות מדויקים במסגרת מדדי הביצועים המרכזיים (KPI) שמתוארים בקטע הזה.

בפרוטוקול 11mc, ברוחבי הפס שמופיעים ברשימה (80 MHz, ‏ 40 MHz,‏ 20 MHz) ובגודל פרץ של 8, מדד ה-KPI להערכת טווח צפוי להשיג את רמת הדיוק הבאה באחוזון ה-90 של השגיאה.

  • 80 MHz: 2 מטרים
  • 40 MHz: 4 מטרים
  • 20 MHz: 8 מטרים

בפרוטוקול 11az, התצורה של אנטנת ה-MIMO והחזרה של שדה ההדרכה הארוך (LTF) משפיעות על הדיוק. בטלפון נייד רגיל (עם 2 אנטנות) ובנקודת גישה (עם 4 אנטנות), המערכת מוגדרת כ-2x4 MIMO. במקרה של הגדרה כזו עם מקדם חזרה של LTF של שניים ורוחבי הפס שמופיעים ברשימה (‎160 MHz, ‏ ‎80 MHz, ‏ ‎40 MHz,‏ ‎20 MHz), צפוי שה-KPI להערכת טווח ישיג את רמת הדיוק הבאה באחוזון ה-90 של השגיאה.

  • 160 MHz: 0.5 מטרים
  • 80 MHz: מטר אחד
  • 40 MHz: 2 מטרים
  • 20 MHz: 4 מטרים

כדי לוודא שההטמעה של התכונה פועלת בצורה תקינה, צריך לבצע בדיקת כיול.

כדי לעשות את זה, משווים בין טווח של נתוני אמת לבין טווח משוער של זמן הלוך ושוב במרחקים הולכים וגדלים. כדי לוודא שהפתרון שלכם עומד בדרישות הבסיסיות, מומלץ לבדוק אותו במכשיר שידוע שהוא מכויל ל-RTT. מומלץ לבדוק את כיול הטווח בתנאים הבאים:

  1. מעבדה גדולה ופתוחה, או מסדרון שאין בו הרבה חפצי מתכת שעלולים לגרום להתרחשות גבוהה במיוחד של נתיבים מרובים.
  2. לפחות מסלול או נתיב בקו ראייה (LOS) באורך של 25 מ'.
  3. סימון של מרווחים של 0.5 מטר מקצה אחד של המסלול לקצה השני.
  4. מקום להצבת נקודת גישה עם תמיכה ב-RTT בקצה אחד של המסלול, בגובה 20 ס"מ מעל הרצפה, ותושבת ניידת לטלפון Android (או למכשיר נייד אחר עם Android שנבדק) שאפשר להזיז לאורך המסלול וליישר עם סימני 0.5 מ', גם בגובה 20 ס"מ מעל הרצפה.

  5. מומלץ לתעד 50 תוצאות של טווח בכל סמן, יחד עם המרחק מנקודת הגישה. צריך לחשב נתונים סטטיסטיים, כמו ממוצע הטווח ושונות, לכל מיקום של סמן.

מהתוצאות בשלב 5, אפשר ליצור תרשים של נתוני האמת (ציר x) לעומת הטווח המשוער (ציר y) ולהעריך את קו הרגרסיה המתאים ביותר. כיול אידיאלי של המכשיר יניב קו עם שיפוע של 1.0, עם היסט של 0.0 מ' בציר ה-y. אפשר לחרוג מהערכים האלה אם החריגה היא במסגרת ה-KPI של רוחב הפס המתאים. אם התוצאות חורגות מהמדד, מומלץ לכייל מחדש את תכונת המכשיר כדי שהתוצאות יהיו במסגרת המפרט של המדד.