Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

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à Access Point (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 độ chính xác và nhận biết vị trí nâng cao.

Ví dụ và nguồn

Để sử dụng tính năng này, hãy triển khai Ngôn ngữ thiết kế giao diện phần cứng Wi-Fi (HIDL) được cung cấp trong Dự án nguồn mở Android (AOSP). 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 HIDL Wi-Fi để sử dụng tính năng Wi-Fi RTT: 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 HIDL mới: phần cứng / libhardware_legacy / + / master / 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ợ Wi-Fi RTT (IEEE 802.11mc) HAL (ngụ ý hỗ trợ phần sụn)

Để triển khai tính năng này, hãy triển khai Wi-Fi 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
    

Nếu không, mọi thứ cần thiết cho tính năng này đều được đưa vào AOSP.

Ngẫu nhiên hóa MAC

Để tăng cường quyền riêng tư, địa chỉ MAC được sử dụng trong các giao dịch Wi-Fi RTT phải được ngẫu nhiên hóa, 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, là một ngoại lệ, khi một thiết bị được liên kết với một AP, nó có thể sử dụng địa chỉ MAC được liên kết với nó 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 bài kiểm tra 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 kích hoạ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 thử nghiệm bằng Bộ thử nghiệm của nhà cung cấp (VTS)hành động / sl4a , một bộ thử nghiệm tiến hành thử nghiệm tích hợp rộng rãi.

Bài kiểm tra đơn vị

Các bài 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ộ thử nghiệm 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à căng thẳng.

CTS

Các bài kiểm tra 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 kích hoạ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 kiểm tra của thiết bị.

Các bài kiểm tra 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à lý tưởng chính xác trong Chỉ báo hiệu suất chính (KPI). Đối với lỗi CDF 90%, ở các băng thông được liệt kê, KPI được đề xuất cho một ước tính phạm vi dự kiến ​​sẽ có các dung sai sau:

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

Để đảm bảo việc triển khai tính năng 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 sự thật trên mặt đất với phạm vi ước tính RTT ở khoảng cách tăng dần. Để đạt được sự phù hợp cơ bản, bạn nên xác nhận giải pháp của mình dựa trên một thiết bị được biết là đã được hiệu chuẩn RTT. Hiệu chuẩn dải phải được kiểm tra trong các điều kiện sau:

  1. Một phòng thí nghiệm mở lớn hoặc một hành lang không có nhiều đồ vật bằng kim loại có thể dẫn đến khả năng xuất hiện nhiều đường bất thường.
  2. Ít nhất một đường / lối đi Line-Of-Sight (LOS) kéo dài 25m.
  3. Các điểm đánh dấu khoảng tăng 0,5 mét từ đầu này đến đầu kia của bản nhạc.
  4. Một nơi để cố định điểm truy cập có khả năng RTT ở một đầu của đường ray được gắn cách mặt sàn 20cm và một giá đỡ có thể di chuyển 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 đường ray và được căn chỉnh với Các điểm đánh dấu 0,5m, cũng ở độ cao 20cm so với mặt sàn. 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 người điều khiển cũng không sao.
  5. 50 kết quả khác nhau phải được ghi lại tại mỗi điểm đánh dấu, cùng với khoảng cách từ điểm truy cập. Các thống kê, chẳng hạn như giá trị trung bình của phạm vi và phương sai, phải được tính toán cho mỗi vị trí điểm đánh dấu.

Từ kết quả ở bước 5, một biểu đồ có thể được vẽ cho sự thật cơ bản (trục x) so với phạm vi ước tính (trục y) và ước tính một đường hồi quy phù hợp nhất. Hiệu chuẩn thiết bị lý tưởng sẽ dẫn đến một đường có độ dốc 1,0, với độ lệch 0,0m trên trục y. Độ lệch từ các giá trị này có thể chấp nhận được 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, tính năng của thiết bị nên được hiệu chỉnh lại để mang lại kết quả trong thông số KPI.