BLE의 Advertising Data: 개념, 구조 및 데이터 유형
Advertising Data는 BLE 장치가 자신과 서비스를 식별하기 위해 광고 패킷으로 전송하는 구조화된 데이터입니다. Bluetooth Core Specification 5.4(2023)는 AD Structure 형식을 정의합니다. 각 요소는 길이(1바이트), 유형(1바이트), 값(최대 29바이트)을 포함합니다. 사양은 Flags와 Local Name부터 Service UUID와 Manufacturer Specific Data까지 30개 이상의 AD 유형을 설명합니다. advertising data의 올바른 패킹은 iOS, Android 및 기타 플랫폼과의 장치 호환성에 중요하며, 검색 속도와 광고 에너지 효율성도 결정합니다.
핵심 요점
- AD Structure는 BLE 광고 패킷의 데이터 형식입니다: 길이(1바이트), 유형(1바이트), 값(최대 29바이트).
- 광고 패킷은 31바이트로 제한되며, 스캔 응답은 추가 데이터를 위해 31바이트를 더 제공합니다.
- Flags(0x01)는 LE Limited Discoverable 및 BR/EDR Not Supported 모드를 정의하는 필수 AD 유형입니다.
- Service UUID는 축약형(2바이트) 또는 전체형(16바이트)으로 전송됩니다.
- Manufacturer Specific Data(0xFF)는 제조업체의 사용자 정의 데이터를 위한 유연한 유형입니다.
Advertising Data란?
Advertising Data는 BLE 장치가 자신을 식별하고 기능을 설명하기 위해 광고 패킷으로 전송하는 구조화된 필드 집합입니다. Central은 전파를 스캔하여 이 데이터를 읽고 장치에 연결할지, 무시할지, Scan Response를 통해 추가 정보를 요청할지 결정합니다.
데이터는 TLV(Type-Length-Value) 원칙에 따라 구성됩니다. 각 AD 요소는 세 개의 필드로 구성됩니다. Length(1바이트)는 Value + Type의 길이입니다(즉, 요소 총 길이에서 Length의 1바이트를 뺀 값). Type(1바이트)은 Bluetooth Assigned Numbers의 데이터 유형 식별자입니다. Value(N바이트)는 유형에 따른 내용입니다.
표준 광고 패킷에는 최대 31바이트의 AD 데이터가 포함될 수 있습니다. 이것으로 충분하지 않은 경우 Scan Response(추가 31바이트) 또는 Extended Advertising(BLE 5.0, 최대 251바이트)이 사용됩니다. 광고 패킷의 첫 번째 바이트는 PDU 헤더와 장치 주소용으로 예약되어 있으며, AD 페이로드는 오프셋에서 시작됩니다.
AD Structure 형식
각 AD 요소는 광고 패킷에서 Length 필드(1바이트)로 시작합니다. Length 값은 Length 뒤에 오는 바이트 수, 즉 Type + Value를 나타냅니다. 예를 들어 Length=3인 요소는 Length 뒤에 1바이트의 Type과 2바이트의 Value가 있음을 의미합니다. 모든 요소 길이의 합이 광고 데이터 크기에 도달하면 패킷이 종료됩니다.
| 필드 | 크기 | 설명 |
|---|---|---|
| Length | 1바이트 | Type + Value의 길이(Length 제외) |
| Type(AD Type) | 1바이트 | Bluetooth SIG의 데이터 유형 식별자 |
| Value | 0–29바이트 | 지정된 유형의 데이터 |
Central 파서는 헤더 후 첫 번째 바이트부터 AD 요소 시퀀스를 읽습니다. Length=0이면 요소가 무시되고 파서는 다음 바이트로 이동합니다. 중복 AD 유형(하나의 패킷에 동일한 Type을 가진 여러 요소)은 허용되지만, Central은 스택 구현에 따라 첫 번째 또는 마지막 요소만 처리할 수 있습니다.
중요한 규칙: 패킷의 모든 Length(+1)의 합계는 광고 데이터 크기(advertising PDU의 경우 31바이트)를 초과해서는 안 됩니다. 데이터가 맞지 않는 경우 우선순위를 설정해야 합니다. 어떤 AD 유형이 초기 검색에 중요하고 어떤 유형을 Scan Response로 이동할 수 있는지 결정해야 합니다.
Flags(0x01): 필수 AD 유형
Flags(AD Type 0x01)는 모든 BLE 장치의 광고 패킷에서 필수 요소입니다. 3바이트를 차지합니다: Length(0x02), Type(0x01), Value(1바이트 비트 플래그). 플래그는 검색 모드와 장치 기능을 정의합니다. Core Specification은 모든 광고 패킷에 Flags를 포함할 것을 권장합니다.
주요 플래그: LE Limited Discoverable Mode(비트 0) — 장치가 제한된 시간 동안 검색 가능, LE General Discoverable Mode(비트 1) — 장치가 항상 검색 가능, BR/EDR Not Supported(비트 2) — 장치가 LE만 지원, Simultaneous LE and BR/EDR(비트 3) — 두 모드 모두 지원. 순수 BLE 장치의 경우 LE General Discoverable + BR/EDR Not Supported 조합이 필수입니다.
잘못된 Flags 값은 iOS 또는 Android에서 장치가 감지되지 않는 일반적인 원인 중 하나입니다. 예를 들어 BR/EDR Not Supported 플래그가 설정되지 않은 경우 iOS는 BLE 대신 클래식 Bluetooth를 통해 연결을 시도할 수 있습니다. Bluetooth 분석기(nRF Connect, Wireshark)로 광고 패킷을 디버깅할 때 Flags 값을 확인하세요.
Local Name: 장치 이름
Local Name(AD Type 0x08 또는 0x09)는 BLE 장치의 표시 이름입니다. Type 0x08(Shortened Local Name)은 축약된 이름으로, 전체 이름이 광고 패킷에 맞지 않을 때 사용됩니다. Type 0x09(Complete Local Name)는 장치의 전체 이름입니다. 최대 이름 길이는 248바이트이지만, 표준 광고 패킷에서는 28바이트 이상 사용할 수 없습니다.
장치 이름이 광고 패킷의 사용 가능한 공간을 초과하는 경우 축약된 이름을 advertising PDU(유형 0x08)에, 전체 이름을 Scan Response(유형 0x09)에 배치하는 것이 좋습니다. iOS는 스캔 중에 광고 패킷의 이름을 표시하고, 전체 이름은 연결 또는 Scan Response 후에 사용할 수 있습니다.
장치 이름을 선택할 때 너무 긴 이름은 Service UUID나 다른 중요한 데이터에 사용할 수 있는 공간을 차지한다는 점을 명심하세요. 권장 이름 길이는 8–16자입니다. 비표준 문자와 공백은 피하세요. 일부 BLE 스택에서 올바르게 처리하지 못할 수 있습니다.
Service UUID: 서비스 식별
Service UUID(AD Type 0x02–0x07)는 가장 중요한 AD 유형 중 하나로, Central이 장치에 연결하지 않고도 장치가 제공하는 서비스를 확인할 수 있게 합니다. Bluetooth SIG는 크기에 따라 여러 UUID 전송 형식을 정의합니다: 0x02(Incomplete 16-bit), 0x03(Complete 16-bit), 0x04(Incomplete 32-bit), 0x05(Complete 32-bit), 0x06(Incomplete 128-bit), 0x07(Complete 128-bit).
16비트 UUID(2바이트)는 표준 Bluetooth SIG 서비스용입니다(예: 0x180F Battery Service, 0x180A Device Information). 128비트 UUID(16바이트)는 개발자가 정의하는 사용자 정의 서비스용입니다. 16비트 UUID는 AD에서 4바이트(Length + Type + 2바이트 UUID)만 차지하는 반면, 128비트 UUID는 18바이트를 차지합니다. 하나의 패킷에서 여러 사용자 정의 UUID를 전송해야 하는 경우 31바이트에 맞지 않을 수 있습니다.
장치의 모든 UUID를 전송하는 것이 아니라 필터링에 가장 중요한 UUID만 전송하는 경우 Incomplete(0x02/0x04/0x06) 유형을 사용하는 것이 좋습니다. UUID의 전체 목록은 연결 후 Scan Response 또는 GATT Discovery를 통해 전송됩니다. 이렇게 하면 다른 AD 유형을 위한 광고 패킷 공간이 절약됩니다.
Manufacturer Specific Data
Manufacturer Specific Data(AD Type 0xFF)는 가장 유연한 AD 유형으로, 제조업체의 사용자 정의 데이터를 전송하도록 설계되었습니다. Value의 처음 2바이트는 Bluetooth SIG에서 할당한 Company Identifier Code입니다(예: Apple의 경우 0x004C, Samsung의 경우 0x0075). 나머지 바이트는 제조업체가 정의한 형식의 임의 데이터입니다.
Apple은 iBeacon용으로 Manufacturer Data를 사용합니다: Company ID(0x004C), Beacon 유형(0x0215), UUID(16바이트), Major(2바이트), Minor(2바이트), TX Power(1바이트). Google은 Eddystone용으로 유사한 형식을 사용합니다. IoT 장치 제조업체는 종종 센서 판독값이나 장치 상태를 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;
}Manufacturer Data를 사용할 때는 크기 제한을 준수하는 것이 중요합니다: 필수 AD 유형을 제외한 전체 광고 패킷에 31바이트입니다. Apple iBeacon의 경우 전체 패킷이 30바이트를 차지하여 Flags(3바이트)만을 위한 공간만 남깁니다. Eddystone의 경우 최대 31바이트입니다. 컴팩트한 사용자 정의 형식은 4–8바이트에 온도, 습도 또는 압력을 포함할 수 있습니다.
데이터 패킹 전략
advertising data의 올바른 패킹은 31바이트의 제한된 공간에 최대 유용한 정보를 배치하는 기술입니다. 전략은 장치의 목적에 따라 다릅니다: 비콘에는 식별자가 필요하고, IoT 센서에는 판독값이 필요하며, 피트니스 트래커에는 이름과 서비스 UUID가 필요합니다. 일반적인 원칙: Central이 더 빠르게 결정을 내려야 할수록 advertising PDU의 데이터가 더 중요해야 합니다.
권장 전략: advertising PDU(처음 31바이트) — Flags(3바이트) + 하나의 16비트 Service UUID(4바이트) + 축약된 이름(최대 12자 = 14바이트) + Manufacturer Data(최대 10바이트). Scan Response(다음 31바이트) — 전체 이름(나머지) + 추가 Service UUID + TX Power Level(3바이트). 이 분배를 통해 Central은 UUID로 장치를 신속하게 필터링할 수 있습니다.
| 우선순위 | AD 유형 | 크기 | 배치 위치 |
|---|---|---|---|
| 1(필수) | Flags(0x01) | 3바이트 | Advertising PDU |
| 2(필터링) | Service UUID(0x02–0x03) | 4+바이트 | Advertising PDU |
| 3(식별) | Local Name(0x08–0x09) | 2+바이트 | Advertising PDU(축약) |
| 4(추가) | TX Power Level(0x0A) | 3바이트 | Scan Response |
| 5(사용자 정의) | Manufacturer Data(0xFF) | 4+바이트 | Advertising PDU / Scan Response |
| 6(전체 데이터) | 나머지 UUID | 크기에 따라 | Scan Response |
advertising data 디버깅은 BLE 장치 개발의 필수 단계입니다. 패킷의 원시 데이터를 보려면 nRF Connect(Nordic Semiconductor) 또는 Bluetooth 분석기와 함께 Wireshark를 사용하세요. 모든 AD 유형의 Length가 올바른지, 길이의 합계가 31바이트를 초과하지 않는지, 사용 사례에 맞게 Flags가 올바르게 설정되었는지 확인하세요.
자주 묻는 질문
AD 요소의 합계가 31바이트를 초과하면 어떻게 되나요?
Bluetooth Controller 스택은 제한을 초과하는 데이터를 폐기하거나 패킷을 보내지 않습니다. 광고 패킷을 조립할 때 AD 요소의 전체 길이를 확인하세요. 데이터가 맞지 않는 경우 일부를 Scan Response로 이동하거나 251바이트 제한의 Extended Advertising(BLE 5.0)을 사용하세요.
센서 판독값을 광고 패킷으로 전송할 수 있나요?
네, Manufacturer Specific Data(0xFF)를 통해 가능합니다. 판독값을 4–8바이트로 패킹하세요: 예를 들어 온도(고정 소수점 형식으로 2바이트), 습도(2바이트), 배터리 전압(2바이트). 이 접근 방식을 사용하면 Central이 연결 없이 데이터를 읽을 수 있어 에너지를 절약할 수 있습니다.
사용자 정의 서비스에는 어떤 AD 유형을 사용해야 하나요?
사용자 정의 서비스의 경우 128비트 UUID(AD Type 0x06–0x07)를 사용하세요. UUID가 advertising PDU(UUID당 16바이트)에 맞지 않는 경우 Scan Response로 이동하거나 처음 하나 또는 두 개의 UUID만 지정하기 위해 Incomplete 축약 형식(0x06)을 사용하세요.
Complete와 Incomplete Service UUID 유형의 차이점은 무엇인가요?
Complete — 패킷에 장치의 모든 서비스 UUID가 나열됩니다. Incomplete — UUID의 일부만(일반적으로 가장 중요한 것). Central은 Incomplete를 전체 목록으로 신뢰할 수 없지만 빠른 필터링에 사용합니다. 전체 목록은 GATT Discovery 후에 사용할 수 있습니다.
iOS에서 내 BLE 장치가 보이지 않는 이유는 무엇인가요?
일반적인 원인은 잘못된 Flags(0x01)입니다. BR/EDR Not Supported 비트가 설정되어 있는지 확인하세요. 두 번째 원인은 광고 패킷에 Service UUID가 없는 것입니다(iOS는 UUID로 필터링합니다). 세 번째 원인은 장치가 너무 드물게 광고하는 것입니다(iOS는 1000ms 이하의 간격을 기대합니다).
요약
- Advertising Data는 BLE 광고 패킷으로 전송되는 AD Structure 형식(Length-Type-Value)의 구조화된 데이터입니다.
- 표준 광고 패킷에는 최대 31바이트의 데이터가 포함되며, Scan Response는 추가 정보를 위해 31바이트를 더 제공합니다.
- Flags(0x01)는 검색 모드를 정의하는 필수 AD 유형입니다. BLE 장치의 경우 BR/EDR Not Supported가 필수입니다.
- Service UUID는 16비트(2바이트) 또는 128비트(16바이트) 형식으로, 사용 가능한 공간에 따라 Complete 또는 Incomplete로 전송됩니다.
- Manufacturer Specific Data(0xFF)는 사용자 정의 데이터를 위한 유연한 유형으로, iBeacon, Eddystone 비콘 및 IoT 장치에서 사용됩니다.
- 패킹 전략: 필수 AD 유형(Flags, Service UUID, 축약된 이름)은 advertising PDU에, 추가 유형은 Scan Response에 배치합니다.
- nRF Connect 또는 Wireshark를 사용한 advertising data 디버깅은 올바른 AD 구조를 확인하기 위한 필수 개발 단계입니다.
턴키 방식의 모바일 애플리케이션을 개발해 드립니다
IT Sectr는 2017년부터 스타트업과 기업을 위한 iOS 및 Android 애플리케이션을 만듭니다. 저희가 상담해 드리고 최적의 솔루션을 제안하겠습니다.
더 읽어보기