התכונה Wi-Fi Round Trip Time (RTT) ב-Android 9 מאפשרת למכשירים תומכים למדוד את המרחק למכשירים תומכים אחרים: בין אם מדובר בנקודות גישה (AP) או במכשירים עמיתים ב-Wi-Fi Aware (אם Wi-Fi Aware נתמך במכשיר). התכונה הזו, שמבוססת על פרוטוקול IEEE 802.11mc ו-IEEE 802.11az (זמינה מ-Android 15), מאפשרת לאפליקציות להשתמש במיקום משופר ובמודעות משופרת למיקום.
דוגמאות ומקור
כדי להשתמש בתכונה הזו, צריך להטמיע את ממשק Vendor HAL. ב-Android 14 ואילך, ממשק Vendor 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-release/include/hardware_legacy/rtt.h.
הטמעה
כדי להטמיע Wi-Fi RTT, צריך לספק תמיכה גם במסגרת וגם ב-HAL/firmware:
Framework:
- קוד AOSP
- הפעלת Wi-Fi RTT: נדרש דגל תכונה
תמיכה ב-HAL של Wi-Fi RTT (IEEE 802.11mc או IEEE 802.11az) (שמשמעותה תמיכה בקושחה)
כדי להטמיע את התכונה הזו, מטמיעים את ממשק ה-AIDL או ה-HIDL של Wi-Fi, ומפעילים את דגל התכונה:
ב-
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.rttCTS
קיימות בדיקות של חבילת הבדיקות לתאימות (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. צריך לבדוק את כיול הטווח בתנאים הבאים:
- מעבדה גדולה ופתוחה, או מסדרון שאין בו הרבה חפצי מתכת שעלולים לגרום להתרחשות גבוהה במיוחד של נתיבים מרובים.
- לפחות מסלול או נתיב בקו ראייה (LOS) באורך של 25 מ'.
- סימון של מרווחים של 0.5 מטר מקצה אחד של המסלול לקצה השני.
מקום להצבת נקודת גישה עם תמיכה ב-RTT בקצה אחד של המסלול, בגובה 20 ס"מ מעל הרצפה, ותושבת ניידת לטלפון Android (או למכשיר נייד אחר עם Android שנבדק) שאפשר להזיז לאורך המסלול וליישר עם סימוני 0.5 מ', גם בגובה 20 ס"מ מעל הרצפה.
צריך לתעד 50 תוצאות של מדידת מרחק בכל סמן, יחד עם המרחק מנקודת הגישה. צריך לחשב נתונים סטטיסטיים, כמו ממוצע וסטיית תקן של טווח, לכל מיקום של סמן.
מהתוצאות בשלב 5, אפשר ליצור תרשים של נתוני האמת (ציר x) לעומת הטווח המשוער (ציר y) ולהעריך את קו הרגרסיה המתאים ביותר. כיול אידיאלי של המכשיר יניב קו עם שיפוע של 1.0, עם היסט של 0.0 מ' בציר ה-y. אפשר לחרוג מהערכים האלה אם החריגה היא במסגרת ה-KPI של רוחב הפס המתאים. אם התוצאות חורגות מהיעד של ה-KPI, צריך לבצע כיול מחדש של תכונת המכשיר כדי שהתוצאות יהיו במסגרת המפרט של ה-KPI.