Wi-Fi RTT (IEEE 802.11mc)

Tính năng Wi-Fi Round Trip Time (RTT) trong Android 9 cho phép các thiết bị hỗ trợ đo khoảng cách đến các thiết bị hỗ trợ khác: cho dù chúng là Điểm truy cập (AP) hay Wi-Fi Aware ngang hàng (nếu Wi-Fi Aware được hỗ trợ trên thiết bị). Tính năng này, được xây dựng dựa trên giao thức IEEE 802.11mc, cho phép các ứng dụng sử dụng nhận thức và độ chính xác về vị trí nâng cao.

Ví dụ và nguồn

Để sử dụng tính năng này, hãy triển khai giao diện HAL của nhà cung cấp. Trong Android 14 trở lên, giao diện HAL của nhà cung cấp được xác định bằng AIDL. Trong Android 13 trở xuống, giao diện HAL của nhà cung cấp được xác định bằng HIDL. Trong Android 8.0, HIDL đã thay thế cấu trúc Lớp trừu tượng phần cứng (HAL) trước đây được sử dụng để hợp lý hóa việc triển khai bằng cách chỉ định các loại và lệnh gọi phương thức được thu thập vào các giao diện và gói.

Làm theo giao diện Wi-Fi để sử dụng tính năng Wi-Fi RTT. Tùy thuộc vào giao diện nào được triển khai, đây là:

  • AIDL: hardware/interfaces/wifi/aidl
  • HIDL: hardware/interfaces/wifi/1.0 trở lên.

Bạn có thể tham khảo Wi-Fi HAL cũ để xem nó tương quan như thế nào với giao diện AIDL và HIDL: hardware/libhardware_legacy/+/main/include/hardware_legacy/rtt.h .

Thực hiện

Để triển khai Wi-Fi RTT, bạn phải cung cấp cả hỗ trợ khung và HAL/chương trình cơ sở:

  • Khung:

    • Mã AOSP
    • Bật Wi-Fi RTT: yêu cầu cờ tính năng
  • Hỗ trợ HAL Wi-Fi RTT (IEEE 802.11mc) (ngụ ý hỗ trợ phần sụn)

Để triển khai tính năng này, hãy triển khai giao diện Wi-Fi AIDL hoặc HIDL và bật cờ tính năng:

  • Trong device.mk nằm trong device/<oem>/<device> , hãy sửa đổi biến môi trường PRODUCT_COPY_FILES để bao gồm hỗ trợ cho tính năng 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
    

Mặt khác, mọi thứ cần thiết cho tính năng này đều có trong AOSP.

ngẫu nhiên MAC

Để nâng cao quyền riêng tư, địa chỉ MAC được sử dụng trong các giao dịch Wi-Fi RTT phải được chọn ngẫu nhiên, tức là địa chỉ này không được khớp với địa chỉ MAC gốc của giao diện Wi-Fi. Tuy nhiên, như một ngoại lệ, khi một thiết bị được liên kết với một AP, thiết bị đó có thể sử dụng địa chỉ MAC mà nó được liên kết cho bất kỳ giao dịch RTT nào với AP đó hoặc với các AP khác.

Thẩm định

Các thử nghiệm Bộ kiểm tra khả năng tương thích Android (CTS) tồn tại cho tính năng này. CTS phát hiện khi tính năng này được bật và tự động bao gồm các bài kiểm tra liên quan. Tính năng này cũng có thể được kiểm tra bằng cách sử dụng Bộ kiểm tra nhà cung cấp (VTS)actions/sl4a , một bộ kiểm tra tiến hành kiểm tra tích hợp rộng rãi.

Kiểm tra đơn vị

Việc kiểm tra gói Wi-Fi RTT được thực hiện bằng cách sử dụng:

Kiểm tra dịch vụ:

atest com.android.server.wifi.rtt

Kiểm tra người quản lý:

atest android.net.wifi.rtt

Kiểm tra tích hợp (ACTS)

Bộ kiểm tra hành vi/sl4a, được mô tả trong /tools/test/connectivity/acts_tests/tests/google/wifi/rtt/README.md , cung cấp các bài kiểm tra chức năng, hiệu suất và mức độ căng thẳng.

CTS

Các thử nghiệm Bộ kiểm tra khả năng tương thích Android (CTS) tồn tại cho tính năng này. CTS phát hiện khi tính năng này được bật và tự động bao gồm các bài kiểm tra liên quan. Điểm truy cập hỗ trợ Wi-Fi RTT (IEEE 802.11mc) phải nằm trong phạm vi của thiết bị đang thử nghiệm.

Các thử nghiệm CTS có thể được kích hoạt bằng cách sử dụng:

atest WifiRttTest

Sự định cỡ

Để Wi-Fi RTT hoạt động tốt, phạm vi được trả về trong giao thức 802.11mc là chính xác lý tưởng trong Chỉ báo hiệu suất chính (KPI). Đối với lỗi CDF 90%, ở băng thông được liệt kê, KPI đề xuất cho ước tính phạm vi dự kiến ​​sẽ có dung sai sau:

  • 80 MHz: 2 mét
  • 40 MHz: 4 mét
  • 20 MHz: 8 mét

Để đảm bảo việc triển khai tính năng này hoạt động chính xác, việc kiểm tra hiệu chuẩn là cần thiết.

Điều này có thể đạt được bằng cách so sánh phạm vi thực tế mặt đất với phạm vi ước tính RTT ở khoảng cách ngày càng tăng. Để tuân thủ cơ bản, bạn nên xác thực giải pháp của mình dựa trên thiết bị đã được hiệu chuẩn RTT. Hiệu chuẩn phạm vi phải được kiểm tra trong các điều kiện sau:

  1. Một phòng thí nghiệm rộng mở hoặc một hành lang không có nhiều đồ vật bằng kim loại có thể dẫn đến tần suất xuất hiện đa đường cao bất thường.
  2. Ít nhất một đường/đường dẫn Line-Of-Sight (LOS) kéo dài 25m.
  3. Các điểm đánh dấu có khoảng cách 0,5 mét từ đầu này đến đầu kia của đường ray.
  4. Nơi để bảo đảm điểm truy cập có khả năng RTT ở một đầu của rãnh được gắn cách sàn 20 cm và giá đỡ di động dành cho điện thoại Android (hoặc thiết bị di động Android khác đang được thử nghiệm) có thể di chuyển dọc theo rãnh và căn chỉnh với Điểm đánh dấu 0,5m, cũng ở độ cao 20 cm so với sàn nhà. Lưu ý: Nhiệm vụ lặp đi lặp lại này có thể được thực hiện bởi một robot nhỏ nhưng con người cũng có thể thực hiện được.
  5. 50 kết quả khác nhau phải được ghi lại ở mỗi điểm đánh dấu, cùng với khoảng cách từ điểm truy cập. Các số liệu thống kê, chẳng hạn như giá trị trung bình và phương sai của phạm vi, phải được tính toán cho từng vị trí điểm đánh dấu.

Từ các kết quả ở bước 5, có thể vẽ biểu đồ về giá trị thực tế cơ bản (trục x) so với phạm vi ước tính (trục y) và đường hồi quy phù hợp nhất được ước tính. Hiệu chuẩn thiết bị lý tưởng sẽ tạo ra một đường có độ dốc 1,0, với độ lệch 0,0m trên trục y. Những sai lệch so với các giá trị này có thể được chấp nhận nếu chúng nằm trong KPI cho băng thông tương ứng. Nếu kết quả nằm ngoài KPI thì tính năng của thiết bị phải được hiệu chỉnh lại để mang lại kết quả nằm trong thông số KPI.