Advertising Data trong BLE: khái niệm, cấu trúc và các loại dữ liệu
Advertising Data là dữ liệu có cấu trúc mà thiết bị BLE truyền trong các gói quảng cáo để xác định danh tính và dịch vụ của nó. Bluetooth Core Specification 5.4 (2023) định nghĩa định dạng AD Structure: mỗi phần tử chứa độ dài (1 byte), loại (1 byte) và giá trị (tối đa 29 byte). Đặc tả mô tả hơn 30 loại AD — từ Flags và Local Name đến Service UUID và Manufacturer Specific Data. Việc đóng gói advertising data đúng cách rất quan trọng cho khả năng tương thích của thiết bị với iOS, Android và các nền tảng khác, đồng thời quyết định tốc độ phát hiện và hiệu quả năng lượng quảng cáo.
Những điểm chính
- AD Structure là định dạng dữ liệu trong gói quảng cáo BLE: độ dài (1 byte), loại (1 byte), giá trị (tối đa 29 byte).
- Gói quảng cáo bị giới hạn ở 31 byte, scan response cung cấp thêm 31 byte cho dữ liệu bổ sung.
- Flags (0x01) là loại AD bắt buộc xác định các chế độ LE Limited Discoverable và BR/EDR Not Supported.
- Service UUID được truyền ở dạng rút gọn (2 byte) hoặc đầy đủ (16 byte).
- Manufacturer Specific Data (0xFF) là loại linh hoạt cho bất kỳ dữ liệu tùy chỉnh nào của nhà sản xuất.
Advertising Data là gì?
Advertising Data là một tập hợp các trường có cấu trúc mà thiết bị BLE truyền trong các gói quảng cáo để xác định danh tính và mô tả khả năng của nó. Central, quét sóng, đọc dữ liệu này và quyết định: kết nối với thiết bị, bỏ qua nó hoặc yêu cầu thông tin bổ sung qua Scan Response.
Dữ liệu được tổ chức theo nguyên tắc TLV (Type-Length-Value): mỗi phần tử AD gồm ba trường. Length (1 byte) là độ dài của Value + Type (tức là tổng độ dài phần tử trừ 1 byte cho Length). Type (1 byte) là định danh loại dữ liệu từ Bluetooth Assigned Numbers. Value (N byte) là nội dung tùy theo loại.
Một gói quảng cáo tiêu chuẩn có thể chứa tối đa 31 byte dữ liệu AD. Nếu không đủ, Scan Response (thêm 31 byte) hoặc Extended Advertising (BLE 5.0, tối đa 251 byte) được sử dụng. Các byte đầu tiên của gói quảng cáo được dành cho tiêu đề PDU và địa chỉ thiết bị — tải trọng AD bắt đầu tại một offset.
Định dạng AD Structure
Mỗi phần tử AD trong gói quảng cáo bắt đầu bằng trường Length (1 byte). Giá trị Length cho biết số byte theo sau Length — tức là Type + Value. Ví dụ, một phần tử có Length=3 có nghĩa là sau Length có 1 byte Type và 2 byte Value. Gói tin kết thúc khi tổng độ dài của tất cả các phần tử đạt đến kích thước dữ liệu quảng cáo.
| Trường | Kích thước | Mô tả |
|---|---|---|
| Length | 1 byte | Độ dài của Type + Value (không bao gồm Length) |
| Type (AD Type) | 1 byte | Định danh loại dữ liệu từ Bluetooth SIG |
| Value | 0–29 byte | Dữ liệu của loại đã chỉ định |
Trình phân tích Central đọc chuỗi các phần tử AD bắt đầu từ byte đầu tiên sau tiêu đề. Nếu Length=0, phần tử bị bỏ qua và trình phân tích chuyển sang byte tiếp theo. Các loại AD trùng lặp (nhiều phần tử có cùng Type trong một gói) được phép, nhưng Central có thể chỉ xử lý phần tử đầu tiên hoặc cuối cùng tùy theo cách triển khai ngăn xếp.
Một quy tắc quan trọng: tổng của tất cả Length(+1) trong gói không được vượt quá kích thước dữ liệu quảng cáo (31 byte cho advertising PDU). Nếu dữ liệu không vừa, cần đặt ưu tiên — loại AD nào quan trọng cho việc phát hiện ban đầu và loại nào có thể chuyển sang Scan Response.
Flags (0x01): Loại AD bắt buộc
Flags (AD Type 0x01) là một phần tử bắt buộc trong gói quảng cáo của mọi thiết bị BLE. Nó chiếm 3 byte: Length (0x02), Type (0x01), Value (1 byte cờ bit). Các cờ xác định chế độ phát hiện và khả năng của thiết bị. Core Specification khuyến nghị bao gồm Flags trong mọi gói quảng cáo.
Các cờ chính: LE Limited Discoverable Mode (bit 0) — thiết bị có thể phát hiện trong thời gian giới hạn, LE General Discoverable Mode (bit 1) — thiết bị luôn có thể phát hiện, BR/EDR Not Supported (bit 2) — thiết bị chỉ hỗ trợ LE, Simultaneous LE and BR/EDR (bit 3) — hỗ trợ cả hai chế độ. Đối với thiết bị BLE thuần túy, tổ hợp LE General Discoverable + BR/EDR Not Supported là bắt buộc.
Giá trị Flags không chính xác là một trong những nguyên nhân phổ biến khiến thiết bị không được phát hiện trên iOS hoặc Android. Ví dụ, nếu cờ BR/EDR Not Supported không được đặt, iOS có thể cố gắng kết nối qua Bluetooth cổ điển thay vì BLE. Kiểm tra giá trị Flags khi gỡ lỗi gói quảng cáo bằng trình phân tích Bluetooth (nRF Connect, Wireshark).
Local Name: Tên thiết bị
Local Name (AD Type 0x08 hoặc 0x09) là tên hiển thị của thiết bị BLE. Type 0x08 (Shortened Local Name) là tên rút gọn, được sử dụng khi tên đầy đủ không vừa trong gói quảng cáo. Type 0x09 (Complete Local Name) là tên đầy đủ của thiết bị. Độ dài tên tối đa là 248 byte, nhưng trong gói quảng cáo tiêu chuẩn, không quá 28 byte có sẵn.
Nếu tên thiết bị vượt quá không gian có sẵn trong gói quảng cáo, khuyến nghị: đặt tên rút gọn trong advertising PDU (loại 0x08) và tên đầy đủ trong Scan Response (loại 0x09). iOS hiển thị tên từ gói quảng cáo khi quét, trong khi tên đầy đủ có sẵn sau khi kết nối hoặc Scan Response.
Khi chọn tên thiết bị, hãy lưu ý: tên quá dài chiếm không gian có thể được sử dụng cho Service UUID hoặc dữ liệu quan trọng khác. Độ dài tên khuyến nghị là 8–16 ký tự. Tránh các ký tự không chuẩn và khoảng trắng — một số ngăn xếp BLE có thể xử lý chúng không chính xác.
Service UUID: Nhận dạng dịch vụ
Service UUID (AD Type 0x02–0x07) là một trong những loại AD quan trọng nhất, cho phép Central xác định các dịch vụ mà thiết bị cung cấp mà không cần kết nối với nó. Bluetooth SIG định nghĩa một số định dạng truyền UUID tùy theo kích thước: 0x02 (Incomplete 16-bit), 0x03 (Complete 16-bit), 0x04 (Incomplete 32-bit), 0x05 (Complete 32-bit), 0x06 (Incomplete 128-bit), 0x07 (Complete 128-bit).
UUID 16-bit (2 byte) cho các dịch vụ Bluetooth SIG tiêu chuẩn, ví dụ 0x180F (Battery Service), 0x180A (Device Information). UUID 128-bit (16 byte) cho các dịch vụ tùy chỉnh do nhà phát triển định nghĩa. UUID 16-bit chỉ chiếm 4 byte trong AD (Length + Type + 2 byte UUID), trong khi UUID 128-bit chiếm 18 byte. Nếu cần truyền nhiều UUID tùy chỉnh trong một gói, chúng có thể không vừa trong 31 byte.
Khuyến nghị sử dụng loại Incomplete (0x02/0x04/0x06) nếu không phải tất cả UUID của thiết bị được truyền, chỉ những UUID quan trọng nhất cho việc lọc. Danh sách đầy đủ UUID được truyền qua Scan Response hoặc GATT Discovery sau khi kết nối. Điều này tiết kiệm không gian trong gói quảng cáo cho các loại AD khác.
Manufacturer Specific Data
Manufacturer Specific Data (AD Type 0xFF) là loại AD linh hoạt nhất, được thiết kế để truyền dữ liệu tùy chỉnh của nhà sản xuất. 2 byte đầu tiên của Value là Company Identifier Code do Bluetooth SIG chỉ định (ví dụ: 0x004C cho Apple, 0x0075 cho Samsung). Các byte còn lại là dữ liệu tùy ý ở định dạng do nhà sản xuất xác định.
Apple sử dụng Manufacturer Data cho iBeacon: Company ID (0x004C), loại Beacon (0x0215), UUID (16 byte), Major (2 byte), Minor (2 byte), TX Power (1 byte). Google sử dụng định dạng tương tự cho Eddystone. Các nhà sản xuất thiết bị IoT thường đặt chỉ số cảm biến hoặc trạng thái thiết bị trong Manufacturer Data.
js
// Parse Manufacturer Specific Data on Central
function parseManufacturerData(data) {
const view = new DataView(data.buffer);
// Company Identifier Code (first 2 bytes)
const companyId = view.getUint16(0, true);
// Check for Apple iBeacon
if (companyId === 0x004C) {
return parseIBeacon(view);
}
return null;
}Khi sử dụng Manufacturer Data, điều quan trọng là phải tuân thủ giới hạn kích thước: 31 byte cho toàn bộ gói quảng cáo trừ đi các loại AD bắt buộc. Đối với Apple iBeacon, toàn bộ gói chiếm 30 byte, chỉ để lại không gian cho Flags (3 byte). Đối với Eddystone — tối đa 31 byte. Các định dạng tùy chỉnh nhỏ gọn có thể bao gồm nhiệt độ, độ ẩm hoặc áp suất trong 4–8 byte.
Chiến lược đóng gói dữ liệu
Việc đóng gói advertising data đúng cách là nghệ thuật đặt thông tin hữu ích tối đa trong không gian giới hạn 31 byte. Chiến lược phụ thuộc vào mục đích của thiết bị: beacon cần một định danh, cảm biến IoT cần chỉ số, tracker thể dục cần tên và UUID dịch vụ. Nguyên tắc chung: Central cần đưa ra quyết định càng nhanh, dữ liệu trong advertising PDU càng phải quan trọng.
Chiến lược khuyến nghị: advertising PDU (31 byte đầu) — Flags (3 byte) + một Service UUID 16-bit (4 byte) + tên rút gọn (tối đa 12 ký tự = 14 byte) + Manufacturer Data (tối đa 10 byte). Scan Response (31 byte tiếp theo) — tên đầy đủ (phần còn lại) + Service UUID bổ sung + TX Power Level (3 byte). Sự phân bố này cho phép Central lọc nhanh các thiết bị theo UUID.
| Ưu tiên | Loại AD | Kích thước | Đặt trong |
|---|---|---|---|
| 1 (bắt buộc) | Flags (0x01) | 3 byte | Advertising PDU |
| 2 (lọc) | Service UUID (0x02–0x03) | 4+ byte | Advertising PDU |
| 3 (nhận dạng) | Local Name (0x08–0x09) | 2+ byte | Advertising PDU (rút gọn) |
| 4 (bổ sung) | TX Power Level (0x0A) | 3 byte | Scan Response |
| 5 (tùy chỉnh) | Manufacturer Data (0xFF) | 4+ byte | Advertising PDU / Scan Response |
| 6 (dữ liệu đầy đủ) | UUID còn lại | Theo kích thước | Scan Response |
Gỡ lỗi advertising data là một bước bắt buộc trong phát triển thiết bị BLE. Sử dụng nRF Connect (Nordic Semiconductor) hoặc Wireshark với trình phân tích Bluetooth để xem dữ liệu thô của gói tin. Kiểm tra rằng tất cả các loại AD có Length chính xác, tổng độ dài không vượt quá 31 byte và Flags được đặt đúng cho trường hợp sử dụng của bạn.
Câu hỏi thường gặp
Điều gì xảy ra nếu tổng các phần tử AD vượt quá 31 byte?
Ngăn xếp Bluetooth Controller sẽ loại bỏ dữ liệu vượt quá giới hạn hoặc không gửi gói tin. Kiểm tra tổng độ dài của các phần tử AD khi lắp ráp gói quảng cáo. Nếu dữ liệu không vừa, hãy chuyển một phần sang Scan Response hoặc sử dụng Extended Advertising (BLE 5.0) với giới hạn 251 byte.
Có thể truyền chỉ số cảm biến trong gói quảng cáo không?
Có, thông qua Manufacturer Specific Data (0xFF). Đóng gói chỉ số vào 4–8 byte: ví dụ, nhiệt độ (2 byte ở định dạng fixed-point), độ ẩm (2 byte), điện áp pin (2 byte). Cách tiếp cận này cho phép Central đọc dữ liệu mà không cần kết nối, tiết kiệm năng lượng.
Tôi nên sử dụng loại AD nào cho các dịch vụ tùy chỉnh?
Đối với dịch vụ tùy chỉnh, sử dụng UUID 128-bit (AD Type 0x06–0x07). Nếu UUID không vừa trong advertising PDU (16 byte cho mỗi UUID), hãy chuyển nó sang Scan Response hoặc sử dụng định dạng rút gọn Incomplete (0x06) để chỉ định một hoặc hai UUID đầu tiên.
Sự khác biệt giữa loại Complete và Incomplete của Service UUID là gì?
Complete — tất cả UUID dịch vụ của thiết bị được liệt kê trong gói. Incomplete — chỉ một phần UUID (thường là quan trọng nhất). Central không thể dựa vào Incomplete như một danh sách đầy đủ, nhưng sử dụng nó để lọc nhanh. Danh sách đầy đủ có sẵn sau GATT Discovery.
Tại sao iOS không thấy thiết bị BLE của tôi?
Một nguyên nhân phổ biến là Flags (0x01) không chính xác. Đảm bảo rằng bit BR/EDR Not Supported được đặt. Nguyên nhân thứ hai là thiếu Service UUID trong gói quảng cáo (iOS lọc theo UUID). Nguyên nhân thứ ba là thiết bị quảng cáo quá hiếm (iOS mong đợi khoảng thời gian không quá 1000 ms).
Tổng kết
- Advertising Data là dữ liệu có cấu trúc ở định dạng AD Structure (Length-Type-Value), được truyền trong các gói quảng cáo BLE.
- Một gói quảng cáo tiêu chuẩn chứa tối đa 31 byte dữ liệu, Scan Response cung cấp thêm 31 byte cho thông tin bổ sung.
- Flags (0x01) là loại AD bắt buộc xác định chế độ phát hiện. BR/EDR Not Supported là bắt buộc cho thiết bị BLE.
- Service UUID được truyền ở định dạng 16-bit (2 byte) hoặc 128-bit (16 byte), Complete hoặc Incomplete tùy theo không gian có sẵn.
- Manufacturer Specific Data (0xFF) là loại linh hoạt cho dữ liệu tùy chỉnh, được sử dụng trong beacon iBeacon, Eddystone và thiết bị IoT.
- Chiến lược đóng gói: các loại AD bắt buộc (Flags, Service UUID, tên rút gọn) trong advertising PDU, các loại bổ sung trong Scan Response.
- Gỡ lỗi advertising data bằng nRF Connect hoặc Wireshark — một bước phát triển bắt buộc để xác minh cấu trúc AD chính xác.
Chúng tôi sẽ phát triển ứng dụng di động chìa khóa trao tay
IT Sectr tạo các ứng dụng iOS và Android cho các công ty khởi nghiệp và doanh nghiệp từ năm 2017. Chúng tôi sẽ tư vấn và đề xuất giải pháp tốt nhất cho bạn.
Đọc thêm