Wi-Fi RTT (IEEE 802.11mc، IEEE 802.11az)

ویژگی Wi-Fi Round Trip Time (RTT) در اندروید ۹ به دستگاه‌های پشتیبانی‌کننده این امکان را می‌دهد که فاصله تا سایر دستگاه‌های پشتیبانی‌کننده را اندازه‌گیری کنند: چه نقاط دسترسی (AP) باشند و چه دستگاه‌های همتای Wi-Fi Aware (در صورت پشتیبانی Wi-Fi Aware در دستگاه). این ویژگی که بر اساس پروتکل IEEE 802.11mc و IEEE 802.11az (که از اندروید ۱۵ موجود است) ساخته شده است، به برنامه‌ها امکان می‌دهد از دقت و آگاهی مکانی پیشرفته‌تری استفاده کنند.

مثال‌ها و منابع

برای استفاده از این ویژگی، رابط Vendor HAL را پیاده‌سازی کنید. در اندروید ۱۴ و بالاتر، رابط Vendor HAL با استفاده از AIDL تعریف می‌شود. در اندروید ۱۳ و پایین‌تر، رابط Vendor HAL با استفاده از HIDL تعریف می‌شود. در اندروید ۸.۰، HIDL جایگزین ساختار قبلی Hardware Abstraction Layer (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 پشتیبانی کنید:

  • چارچوب:

    • کد AOSP
    • فعال کردن Wi-Fi RTT: به یک feature flag نیاز دارد
  • پشتیبانی از Wi-Fi RTT (IEEE 802.11mc یا IEEE 802.11az) و HAL (که به معنای پشتیبانی از میان‌افزار است)

برای پیاده‌سازی این ویژگی، رابط 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 مطابقت داشته باشد. با این حال، به عنوان یک استثنا، هنگامی که یک دستگاه با یک AP مرتبط است، می‌تواند از آدرس MAC که برای هرگونه تراکنش RTT با آن AP یا سایر APها به آن متصل است، استفاده کند.

اعتبارسنجی

مجموعه تست سازگاری اندروید (CTS) برای این ویژگی وجود دارد. CTS زمان فعال شدن این ویژگی را تشخیص می‌دهد و به طور خودکار تست‌های مرتبط را در آن لحاظ می‌کند. این ویژگی را می‌توان با استفاده از مجموعه تست فروشنده (VTS) نیز آزمایش کرد.

تست‌های واحد

تست‌های بسته Wi-Fi RTT با استفاده از موارد زیر انجام می‌شوند:

آزمایش‌های سرویس:

atest com.android.server.wifi.rtt

آزمون‌های مدیریتی:

atest android.net.wifi.rtt

سی تی اس

مجموعه تست سازگاری اندروید (CTS) برای این ویژگی وجود دارد. CTS زمان فعال شدن این ویژگی را تشخیص می‌دهد و به طور خودکار تست‌های مرتبط را شامل می‌کند. یک نقطه دسترسی که از Wi-Fi RTT (IEEE 802.11mc) پشتیبانی می‌کند، باید در محدوده دستگاه تحت آزمایش باشد.

آزمایش‌های CTS را می‌توان با استفاده از موارد زیر انجام داد:

atest WifiRttTest

کالیبراسیون

برای اینکه Wi-Fi RTT عملکرد خوبی داشته باشد، محدوده‌های بازگشتی در پروتکل‌های 802.11mc یا 802.11az باید در محدوده شاخص‌های کلیدی عملکرد (KPI) که در این بخش توضیح داده شده است، دقیق باشند.

برای پروتکل 11mc، در پهنای باندهای ذکر شده (80 مگاهرتز، 40 مگاهرتز، 20 مگاهرتز) و اندازه برست 8، انتظار می‌رود KPI برای تخمین برد، دقت زیر را در 90 درصد خطا به دست آورد.

  • ۸۰ مگاهرتز: ۲ متر
  • ۴۰ مگاهرتز: ۴ متر
  • ۲۰ مگاهرتز: ۸ متر

برای پروتکل 11az، پیکربندی آنتن MIMO و تکرار میدان آموزشی طولانی (LTF) بر دقت تأثیر می‌گذارند. با یک تلفن همراه معمولی (با استفاده از 2 آنتن) و یک نقطه دسترسی (4 آنتن)، سیستم دارای پیکربندی 2x4 MIMO است. برای چنین پیکربندی با استفاده از ضریب تکرار LTF برابر با دو و در پهنای باندهای ذکر شده (160 مگاهرتز، 80 مگاهرتز، 40 مگاهرتز، 20 مگاهرتز)، انتظار می‌رود KPI برای تخمین برد، دقت زیر را در 90 درصد خطا به دست آورد.

  • ۱۶۰ مگاهرتز: ۰.۵ متر
  • ۸۰ مگاهرتز: ۱ متر
  • ۴۰ مگاهرتز: ۲ متر
  • ۲۰ مگاهرتز: ۴ متر

برای تأیید صحت عملکرد پیاده‌سازی این ویژگی، آزمایش کالیبراسیون ضروری است.

این امر را می‌توان با مقایسه یک محدوده واقعیت زمینی در برابر محدوده تخمینی RTT در فواصل فزاینده به دست آورد. برای انطباق اولیه، توصیه می‌کنیم که راه‌حل خود را در برابر دستگاهی که به عنوان کالیبره شده RTT شناخته می‌شود، اعتبارسنجی کنید. توصیه می‌کنیم کالیبراسیون محدوده را تحت شرایط زیر آزمایش کنید:

  1. یک آزمایشگاه بزرگ و روباز، یا راهرویی که اشیاء فلزی زیادی ندارد که ممکن است منجر به وقوع غیرمعمول و زیاد چندمسیری شود.
  2. حداقل یک مسیر یا خط دید مستقیم (LOS) به طول ۲۵ متر.
  3. نشانگرهایی با فواصل ۰.۵ متر از یک سر مسیر تا سر دیگر.
  4. مکانی برای محکم کردن یک نقطه دسترسی با قابلیت RTT در یک انتهای مسیر که 20 سانتی‌متر بالاتر از کف نصب شده است، و یک پایه متحرک برای یک تلفن اندروید (یا سایر دستگاه‌های همراه اندروید تحت آزمایش) که می‌تواند در امتداد مسیر حرکت کند و با نشانگرهای 0.5 متری، آن هم در 20 سانتی‌متر بالاتر از کف، هم‌تراز شود.

  5. توصیه می‌کنیم ۵۰ نتیجه‌ی اندازه‌گیری را در هر نشانگر، به همراه فاصله از نقطه‌ی دسترسی ثبت کنید. آماره‌هایی مانند میانگین و واریانس محدوده، باید برای هر موقعیت نشانگر محاسبه شوند.

از نتایج مرحله ۵، می‌توان نموداری برای حقیقت زمینی (محور x) در برابر محدوده تخمینی (محور y) و بهترین خط رگرسیون برازش تخمینی رسم کرد. کالیبراسیون ایده‌آل دستگاه منجر به خطی با شیب ۱.۰ و انحراف ۰.۰ متر روی محور y خواهد شد. انحراف از این مقادیر در صورتی قابل قبول است که در محدوده KPI برای پهنای باند مربوطه باشند. اگر نتایج خارج از KPI باشند، توصیه می‌کنیم که ویژگی دستگاه را دوباره کالیبره کنید تا نتایج در محدوده مشخصات KPI قرار گیرند.