반응형
ble 를 공부하기 위해 기초 개념을 llm을 통해 알아봄
📌 BLE 통신 구조 핵심 개념
1. Central ↔ Peripheral
- Central: 데이터를 요청하는 주체 (예: 스마트폰).
- Peripheral: 데이터를 제공하는 장치 (예: 심박계, 체중계, IoT 디바이스).
- BLE 통신은 일반적으로 Central이 Peripheral에 연결해서 데이터를 읽거나 쓴다.
2. GATT (Generic Attribute Profile)
- BLE 데이터 전송의 기본 구조.
- GATT는 Central이 Peripheral로부터 데이터를 읽거나 쓰는 방식을 정의함.
GATT는 서비스 (Service) 와 특성 (Characteristic)의 집합
▶ Service
- 관련된 데이터를 그룹화한 것.
예: "Heart Rate Service", "Battery Service" - 고유한 UUID(범용 고유 식별자)를 가짐.
▶ Characteristic
- 실제 데이터를 담는 요소.
예: 심박수 값, 배터리 잔량 등 - 각 특성도 UUID를 가짐.
- Properties: 읽기(Read), 쓰기(Write), 알림(Notify) 등의 권한이 있음.
▶ Descriptor
- Characteristic에 부가 정보를 부여함. 예: 알림 설정 정보, 포맷 정보 등
💡 예시
심박수 센서 예:
- Service (UUID: 180D): Heart Rate Service
- Characteristic (UUID: 2A37): Heart Rate Measurement (Notify)
- Characteristic (UUID: 2A38): Body Sensor Location (Read)
🧠 알아야 할 기타 개념
3. UUID
- 모든 Service와 Characteristic은 UUID로 식별됨.
- 표준(16비트)과 커스텀(128비트) UUID가 있음.
4. Advertising
- Peripheral이 자신을 Central에게 알리기 위해 주기적으로 브로드캐스팅하는 데이터.
- 광고 패킷에는 장치 이름, 서비스 UUID 등이 포함될 수 있음.
5. MTU (Maximum Transmission Unit)
- BLE 한 번에 전송 가능한 최대 바이트 수.
- 기본은 23바이트, negotiated를 통해 확장 가능.
6. Notify vs Indicate
- Notify: 데이터가 바뀌면 Central에 자동으로 보내줌. 응답 없음 (빠름).
- Indicate: Notify처럼 자동 전송되지만 응답(ACK)을 기다림 (신뢰성 높음).
✅ BLE 통신 흐름 정리
- Central이 Peripheral을 스캔하여 장치를 찾음.
- Peripheral이 광고(Advertising)를 통해 존재를 알림.
- Central이 연결(connect) 시도.
- GATT 서비스 목록을 디스커버리함.
- 원하는 Characteristic에 대해 읽기/쓰기/구독 수행.
UUID에 대한 자세한 설명
🔐 UUID (Universally Unique Identifier)
▶ BLE에서 UUID의 역할
- Service, Characteristic, Descriptor 등 모든 요소를 구분하는 ID.
- Bluetooth SIG(표준 기관)에서 정한 공식 UUID도 있고, 개발자가 자유롭게 정의하는 커스텀 UUID도 있어.
✅ 표준 16비트 UUID (Assigned Numbers)
🔹 정의
- Bluetooth SIG가 지정한 공식 서비스/특성용 UUID.
- 16진수 4자리 (예: 0x180D → Heart Rate Service)
- 실제 사용 시에는 128비트로 확장되어 사용됨.
(하지만 중앙 부분만 다르고 나머지는 고정된 형식이야.)
text
CopyEdit
0000XXXX-0000-1000-8000-00805F9B34FB ↑ 여기에 16비트 UUID가 들어감
예시
의미16비트 UUID128비트 확장형 UUID
| Heart Rate Service | 0x180D | 0000180D-0000-1000-8000-00805F9B34FB |
| Battery Level | 0x2A19 | 00002A19-0000-1000-8000-00805F9B34FB |
👉 표준 UUID는 공식 문서 Bluetooth GATT Specifications에서 모두 확인 가능.
✅ 커스텀 128비트 UUID
🔹 정의
- 자신만의 BLE 서비스나 특성을 만들 때 사용.
- 128비트 전체를 직접 정의.
- 충돌 방지를 위해 랜덤하게 생성하거나, 회사에서 관리하는 UUID 범위를 사용함.
text
CopyEdit
예: f000aa01-0451-4000-b000-000000000000
🔸 특징
- 표준 장치가 아닌 경우에는 거의 무조건 커스텀 UUID 사용.
- 클라이언트(Central)는 이 UUID를 알고 있어야 접근 가능함.
📦 비교 요약
항목표준 16비트 UUID커스텀 128비트 UUID
| 크기 | 16비트 | 128비트 |
| 형식 | 0x180D | f000aa01-0451-4000-... |
| 용도 | 표준 서비스/특성용 | 커스텀 기능용 |
| 정의 기관 | Bluetooth SIG | 개발자 or 회사 |
| 사용 편의성 | Central에서 쉽게 탐색 | 클라이언트가 UUID 알아야 함 |
🛠 실전 팁
- 개발 중에 커스텀 서비스를 만들 경우:
- UUID 생성기(ex. uuidgenerator.net)로 만들고 사용.
- 표준 서비스와의 호환이 목적이라면 표준 UUID 사용이 좋음.
- 앱에서 BLE 장치를 스캔하고 접근할 때, UUID 필터를 통해 원하는 장치만 찾을 수도 있어.
ble 규격을 정한다는게 결국 uuid를 정한다는거네
정확해! 🎯
BLE에서 "규격을 정한다"는 건 실질적으로는 어떤 서비스를 만들고, 그 안에 어떤 데이터를 어떤 형식으로 담을지 정의하는 것인데 — 그걸 UUID로 표현하는 거야.
📐 BLE 규격 = GATT 프로파일 설계 = UUID 구조 설계
BLE 규격을 만든다는 건 대체로 이런 걸 정하는 거야:
1. 서비스(Service) 정의
- 이 서비스는 어떤 기능을 담당하는가?
- 예: 심박수 측정, 체온 측정, 펌웨어 업데이트 등
2. 특성(Characteristic) 정의
- 어떤 데이터들을 제공할 것인가?
- 예: 심박수 값, 배터리 잔량, 센서 온도 등
- 각각의 데이터는 Characteristic으로 표현되고, 각자 UUID를 가짐
3. 데이터 구조 정의
- 이 특성에 담기는 데이터는 몇 바이트인가?
- 어떤 형식으로 해석해야 하나? (예: int, float, bitmask, enum…)
예: 직접 만든 커스텀 규격 (예: 온습도 센서)
항목설명
| Service UUID | 12345678-1234-5678-1234-56789abcdef0 |
| → Characteristic 1 | 온도 측정값 (UUID: 12345678-1234-5678-1234-56789abcdef1) |
| → Characteristic 2 | 습도 측정값 (UUID: 12345678-1234-5678-1234-56789abcdef2) |
| 데이터 포맷 | 온도: 2바이트 int (0.01°C 단위) 습도: 1바이트 퍼센트 |
이런 식으로 UUID + 데이터 형식을 정의하는 게 BLE 규격을 만든다는 의미야.
🧩 표준 규격과 커스텀 규격 차이
항목표준 규격 (SIG)커스텀 규격 (자체 설계)
| UUID 사용 | 16비트 표준 UUID | 128비트 커스텀 UUID |
| 사용 목적 | 공용 장치 호환 | 특정 앱/하드웨어 간 통신 |
| 장점 | 범용성, 재사용 쉬움 | 유연성, 자유도 높음 |
| 예시 | Heart Rate, Battery | 맞춤형 센서, 디바이스 제어 등 |
반응형
댓글