התכונה זמן הנסיעה הלוך ושוב (RTT) ב-Wi-Fi ב-Android 9 מאפשרת למכשירים נתמכים למדוד את המרחק למכשירים נתמכים אחרים: נקודות גישה (AP) או מכשירי Wi-Fi Aware (אם יש תמיכה ב-Wi-Fi Aware במכשיר). התכונה הזו, שמבוססת על פרוטוקול IEEE 802.11mc ו-IEEE 802.11az (זמין מ-Android 15), מאפשרת לאפליקציות להשתמש בשיפור הדיוק והמוּדעוּת של המיקום.
דוגמאות ומקור
כדי להשתמש בתכונה הזו, צריך להטמיע את ממשק ה-HAL של הספק. ב-Android מגרסה 14 ואילך, ממשק HAL של הספק מוגדר באמצעות AIDL. ב-Android מגרסה 13 ומטה, ממשק ה-HAL של הספק מוגדר באמצעות HIDL. ב-Android 8.0, HIDL החליף את המבנה הקודם של שכבת החומרה לניתוח (HAL), ששימש לייעול הטמעות על ידי ציון סוגים קריאות ל-method שנאספו בממשקים ובחבילות.
פועלים לפי ממשק ה-Wi-Fi כדי להשתמש בתכונת ה-RTT ב-Wi-Fi. בהתאם לממשק שמוטמע, זהו:
- AIDL:
hardware/interfaces/wifi/aidl
- HIDL:
hardware/interfaces/wifi/1.0
ואילך.
אפשר לעיין ב-HAL הקודם של Wi-Fi כדי לראות איך הוא קשור לממשקי AIDL ו-HIDL: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h.
הטמעה
כדי להטמיע את Wi-Fi RTT, צריך לספק תמיכה גם במסגרת וגם ב-HAL או בקושחה:
מסגרת:
- קוד AOSP
- הפעלת RTT ב-Wi-Fi: נדרש דגל תכונה
תמיכה ב-HAL של Wi-Fi RTT (IEEE 802.11mc או IEEE 802.11az) (המשמעות היא תמיכה בקושחת קושחה)
כדי להטמיע את התכונה הזו, צריך להטמיע את ממשק ה-Wi-Fi AIDL או HIDL ולהפעיל את דגל התכונה:
בקובץ
device.mk
שנמצא ב-device/<oem>/<device>
, משנים את משתנה הסביבהPRODUCT_COPY_FILES
כך שיכלול תמיכה בתכונה RTT של Wi-Fi: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 שמשמשת במהלך עסקאות RTT ב-Wi-Fi צריכה להיות רנדומלית, כלומר היא לא יכולה להתאים לכתובת ה-MAC המקורית של ממשק ה-Wi-Fi. עם זאת, כחריגה, כשמכשיר משויך לנקודת AP, הוא עשוי להשתמש בכתובת ה-MAC שאיתה הוא משויך בכל עסקאות RTT עם נקודת ה-AP הזו או עם נקודות AP אחרות.
אימות
יש בדיקות של חבילה לבדיקות תאימות (CTS) של Android עבור התכונה הזו. CTS מזהה מתי התכונה מופעלת וכולל באופן אוטומטי את הבדיקות המשויכות. אפשר לבדוק את התכונה הזו גם באמצעות חבילת בדיקות הספק (VTS).
בדיקות יחידה
בדיקות החבילות של RTT ב-Wi-Fi מתבצעות באמצעות:
בדיקות שירות:
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 אנטנות), למערכת יש תצורת MIMO של 2x4. בהגדרה כזו, עם מקדם חזרה של LTF בשניים וברוחב הפס שצוין (160 MHz, 80 MHz, 40 MHz, 20 MHz), מדד ה-KPI של אומדן הטווח צפוי להשיג את הדיוק הבא ב-90% מהשגיאות.
- 160 MHz: 0.5 מטרים
- 80 MHz: מטר אחד
- 40 MHz: 2 מטרים
- 20 MHz: 4 מטרים
כדי לוודא שההטמעה של התכונה פועלת כמו שצריך, צריך לבצע בדיקת כיול.
כדי לעשות זאת, משווים בין טווח של נתוני שטח אמיתיים לבין הטווח המשוער של זמן האחזור (RTT) במרחקים הולכים וגדלים. לצורך תאימות בסיסית, צריך לאמת את הפתרון מול מכשיר שידוע כיול RTT. צריך לבדוק את כיול הטווח בתנאים הבאים:
- מעבדה גדולה ופתוחה או מסדרון בלי הרבה חפצים ממתכת, שיכולים לגרום למספר גבוה במיוחד של מקרים של נתיב מרובים.
- לפחות מסלול או נתיב באורך 25 מטר.
- סמנים במרווחים של 0.5 מטר מקצה המסלול לקצה השני.
מקום להצמדת נקודת גישה עם תמיכה ב-RTT בקצה אחד של המסלול, בגובה 20 ס"מ מעל הרצפה, ותושבת ניידת לטלפון Android (או למכשיר נייד אחר של Android שנמצא בבדיקה) שניתן להזיז לאורך המסלול וליישר עם הסמנים של 0.5 מ', גם בגובה 20 ס"מ מעל הרצפה.
צריך לתעד 50 תוצאות מדידת מרחק בכל סממן, יחד עם המרחק מנקודת הגישה. צריך לחשב נתונים סטטיסטיים, כמו ממוצע וריאציה של טווח, לכל מיקום של סמן.
מהתוצאות בשלב 5, אפשר לצייר תרשים של נתוני האמת (ציר ה-x) לעומת טווח משוער (ציר ה-y) וקו רגרסיה משוער של ההתאמה הטובה ביותר. כיוון מושלם של המכשיר יביא לקו עם שיפוע של 1.0, עם סטייה של 0.0m בציר ה-y. סטיות מהערכים האלו מותרות אם הם נמצאים ב-KPI של רוחב הפס התואם. אם התוצאות לא עומדות במדדי ה-KPI, צריך לבצע כיול מחדש של תכונת המכשיר כדי שהתוצאות יעמדו במפרט של מדדי ה-KPI.