Wi-Fi RTT (IEEE 802.11mc)

ویژگی Wi-Fi Round Trip Time (RTT) در Android 9 به دستگاه‌های پشتیبانی کننده امکان می‌دهد فاصله را با سایر دستگاه‌های پشتیبانی کننده اندازه‌گیری کنند: خواه نقاط دسترسی (APs) یا Wi-Fi Aware همتایان (اگر Wi-Fi Aware در دستگاه پشتیبانی می‌شود. دستگاه). این ویژگی که بر اساس پروتکل IEEE 802.11mc ساخته شده است، برنامه‌ها را قادر می‌سازد تا از دقت و آگاهی موقعیت مکانی پیشرفته استفاده کنند.

مثال ها و منبع

برای استفاده از این ویژگی، زبان طراحی رابط سخت افزاری Wi-Fi (HIDL) ارائه شده در پروژه متن باز اندروید (AOSP) را پیاده سازی کنید. در Android 8.0، HIDL جایگزین ساختار قبلی Hardware Abstraction Layer (HAL) می‌شود که برای ساده‌سازی پیاده‌سازی‌ها با تعیین انواع و فراخوان‌های روش جمع‌آوری‌شده در رابط‌ها و بسته‌ها استفاده می‌شد.

Wi-Fi HIDL را دنبال کنید تا از ویژگی Wi-Fi RTT استفاده کنید: hardware/interfaces/wifi/1.0 یا جدیدتر.

می‌توانید به Wi-Fi HAL قدیمی مراجعه کنید تا ببینید چگونه با رابط HIDL جدید مرتبط است: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h .

پیاده سازی

برای پیاده سازی Wi-Fi RTT، باید هم از چارچوب و هم پشتیبانی HAL/firmware ارائه دهید:

  • چارچوب:

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

برای پیاده سازی این ویژگی، Wi-Fi HIDL را پیاده سازی کنید و پرچم ویژگی را فعال کنید:

  • در 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ها استفاده کند.

اعتبار سنجی

تست‌های مجموعه تست سازگاری Android (CTS) برای این ویژگی وجود دارد. CTS تشخیص می دهد که این ویژگی چه زمانی فعال است و به طور خودکار آزمایش های مرتبط را شامل می شود. این ویژگی همچنین می‌تواند با استفاده از Vendor Test Suite (VTS) و acts/sl4a ، مجموعه‌ای آزمایشی که آزمایش‌های ادغام گسترده را انجام می‌دهد، آزمایش شود.

تست های واحد

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

تست های خدمات:

atest com.android.server.wifi.rtt

تست های مدیر:

atest android.net.wifi.rtt

تست های یکپارچه سازی (ACTS).

مجموعه آزمایشی acts/sl4a که در /tools/test/connectivity/acts_tests/tests/google/wifi/rtt/README.md توضیح داده شده است، تست های عملکردی، عملکردی و استرس را ارائه می دهد.

سی تی اس

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

تست های CTS را می توان با استفاده از موارد زیر آغاز کرد:

atest WifiRttTest

تنظیم

برای اینکه Wi-Fi RTT به خوبی کار کند، محدوده های بازگردانده شده در پروتکل 802.11mc به طور ایده آل در شاخص عملکرد کلیدی (KPI) دقیق هستند. برای خطای CDF 90 درصد، در پهنای باند فهرست شده، انتظار می رود KPI توصیه شده برای تخمین محدوده دارای تلورانس های زیر باشد:

  • 80 مگاهرتز: 2 متر
  • 40 مگاهرتز: 4 متر
  • 20 مگاهرتز: 8 متر

برای اطمینان از اینکه اجرای این ویژگی به درستی کار می کند، آزمایش کالیبراسیون ضروری است.

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

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

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

،

ویژگی Wi-Fi Round Trip Time (RTT) در Android 9 به دستگاه‌های پشتیبانی کننده امکان می‌دهد فاصله را با سایر دستگاه‌های پشتیبانی کننده اندازه‌گیری کنند: خواه نقاط دسترسی (APs) یا Wi-Fi Aware همتایان (اگر Wi-Fi Aware در دستگاه پشتیبانی می‌شود. دستگاه). این ویژگی که بر اساس پروتکل IEEE 802.11mc ساخته شده است، برنامه‌ها را قادر می‌سازد تا از دقت و آگاهی موقعیت مکانی پیشرفته استفاده کنند.

مثال ها و منبع

برای استفاده از این ویژگی، زبان طراحی رابط سخت افزاری Wi-Fi (HIDL) ارائه شده در پروژه متن باز اندروید (AOSP) را پیاده سازی کنید. در Android 8.0، HIDL جایگزین ساختار قبلی Hardware Abstraction Layer (HAL) می‌شود که برای ساده‌سازی پیاده‌سازی‌ها با تعیین انواع و فراخوان‌های روش جمع‌آوری‌شده در رابط‌ها و بسته‌ها استفاده می‌شد.

Wi-Fi HIDL را دنبال کنید تا از ویژگی Wi-Fi RTT استفاده کنید: hardware/interfaces/wifi/1.0 یا جدیدتر.

می‌توانید به Wi-Fi HAL قدیمی مراجعه کنید تا ببینید چگونه با رابط HIDL جدید مرتبط است: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h .

پیاده سازی

برای پیاده سازی Wi-Fi RTT، باید هم از چارچوب و هم پشتیبانی HAL/firmware ارائه دهید:

  • چارچوب:

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

برای پیاده سازی این ویژگی، Wi-Fi HIDL را پیاده سازی کنید و پرچم ویژگی را فعال کنید:

  • در 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ها استفاده کند.

اعتبار سنجی

تست‌های مجموعه تست سازگاری Android (CTS) برای این ویژگی وجود دارد. CTS تشخیص می دهد که این ویژگی چه زمانی فعال است و به طور خودکار آزمایش های مرتبط را شامل می شود. این ویژگی همچنین می‌تواند با استفاده از Vendor Test Suite (VTS) و acts/sl4a ، مجموعه‌ای آزمایشی که آزمایش‌های ادغام گسترده را انجام می‌دهد، آزمایش شود.

تست های واحد

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

تست های خدمات:

atest com.android.server.wifi.rtt

تست های مدیر:

atest android.net.wifi.rtt

تست های یکپارچه سازی (ACTS).

مجموعه آزمایشی acts/sl4a که در /tools/test/connectivity/acts_tests/tests/google/wifi/rtt/README.md توضیح داده شده است، تست های عملکردی، عملکردی و استرس را ارائه می دهد.

سی تی اس

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

تست های CTS را می توان با استفاده از موارد زیر آغاز کرد:

atest WifiRttTest

تنظیم

برای اینکه Wi-Fi RTT به خوبی کار کند، محدوده های بازگردانده شده در پروتکل 802.11mc به طور ایده آل در شاخص عملکرد کلیدی (KPI) دقیق هستند. برای خطای CDF 90 درصد، در پهنای باند فهرست شده، انتظار می رود KPI توصیه شده برای تخمین محدوده دارای تلورانس های زیر باشد:

  • 80 مگاهرتز: 2 متر
  • 40 مگاهرتز: 4 متر
  • 20 مگاهرتز: 8 متر

برای اطمینان از اینکه اجرای این ویژگی به درستی کار می کند، آزمایش کالیبراسیون ضروری است.

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

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

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