ESP32 BLE - cchamchi/ESP32 GitHub Wiki

BLE 블루투스 모듈을 이용해서 다양한 앱과 장치를 만들기 위해서는 먼저 BLE 의 구조와 컨셉, 스펙에 대해서 이해할 필요가 있습니다. 국내외의 자료 중 비교적 이해가 쉬운 자료들을 정리했습니다.

BLUETOOTH LOW ENERGY(BLE)

BLE는 종종 Bluetooth Smart 로도 불리며 classic bluetooth의 경량화 버전을 목표로 블루투스 4.0의 일부로 발표되었습니다. Classic bluetooth와 겹치는 부분이 존재하지만 BLE는 완전히 다른 표준으로 블루투스 표준화 그룹인 Bluetooth SIG에 의해서 개발되기 전까지 Nokia의 사내 프로젝트(Wibree)로 시작하였습니다.

BLE 지원 플랫폼

iOS5+ (iOS7+ preferred)
Android 4.3+ (numerous bug fixes in 4.4+)
Apple OS X 10.6+
Windows 8 (XP, Vista and 7 only support Bluetooth 2.1)
GNU/Linux Vanilla BlueZ 4.93+

GAP

GAP는 Generic Access Profile의 약자로 블루투스에서 게시(advertising)와 연결(connection)을 제어합니다. GAP은 특정 장치가 다른 장치들에게 어떻게 보여지도록 할 것인가와 어떻게 두 장치를 연결할 것인가를 결정합니다. GAP은 장치들이 맡을 수 있는 다양한 역할들에 대해 정의합니다. 그 중 가장 핵심이 되는 컨셉은 Central 장치와 Peripheral 장치입니다.

Peripheral 장치는 주로 작고, 저전력으로 동작하고, 제한된 리소스를 가진 장치들로 보다 리소스가 풍부한 Central 장치에 연결되어 동작하도록 설계된 장치입니다. Heart Rate Monitor(심박측정기), BLE 근접센서 태그 등이 해당됩니다. 이하 글에서는 이해의 편의를 위해 Peripheral 장치를 [센서 장치]로 표현합니다.

Central 장치는 폰이나 태블릿과 같이 충분한 전원과 메모리 등의 리소스를 갖춘 장치입니다. 이하 글에서는 이해의 편의를 위해 [폰] 등으로 표현합니다.

ADVERTISING AND SCAN RESPONSE DATA

GAP을 이용해서 게시(Advertising)를 할 때 Advertising Data Payload와 Scan Response Payload 를 포함할 수 있습니다. 두 가지는 서로 구분되며 31바이트까지 데이터를 포함할 수 있습니다. 하지만 Advertising Data Payload 가 필수인데 반해 Scan Response Payload는 선택적입니다. Advertising Data Payload 는 Central 장치가 인식할 수 있도록 peripheral 장치(센서장치)에서 계속 송출되는 데이터입니다. Scan Response Payload 는 central 장치(폰)에서 장치 이름과 같이 추가적인 정보를 요구하기 위해 정의된 것으로 선택적으로 구현됩니다.

ADVERTISING PROCESS

Advertising 과정이 어떻게 동작하는지는 아래 그림을 참고하세요.

먼저 센서장치는 특정한 게시 주기(advertising interval)를 가지고, 이 주기마다 advertising packet을 전송합니다. 주기가 길어질수록 전력소모를 줄여주지만 Central 장치에서의 반응이 느려집니다. 만약 수신 장치(central 장치)에서 Scan Response Data 에 관심이 있다면 추가로 요청을 보낼 수 있고 peripheral 이 여기에 데이터와 함께 응답할 것입니다.

BROADCASTING, BEACON

Peripheral 장치는 31바이트 정도의 작은 데이터를 실어서 게시(advertising)를 함으로써 낮은 비용으로 주변의 central 장치에 자신의 존재를 알릴 수 있습니다. BLE에서는 이것을 Broadcasting 이라고 부릅니다. 그리고 오로지 advertising 역할만을 하는 Peripheral 장치가 바로 비컨(Beacon) 입니다. 애플의 iBeacon은 advertising packet 의 custom payload 내용을 특정한 형식으로 작성하도록 정의하고 있습니다.

일단 Central, Peripheral 두 장치가 연결되면 advertising 은 종료되어 외부 장치에서 scan 되지 않습니다. 이제 GATT 서비스와 특성(characteristic)을 사용하여 양방향으로 통신하게 됩니다.

주요 용어와 컨셉

자세한 설명이 이어지기 전에 곧 언급될 주요 용어들과 컨셉을 소개합니다.

GATT (Generic Attribute Profile) : GATT는 두 BLE 장치간에 Service, Characteristic 을 이용해서 데이터를 주고 받는 방법을 정의한 것입니다.
Attribute Protocol (ATT) : GATT는 ATT의 최상위 구현체이며 GATT/ATT로 참조되기도 합니다. 각각의 속성(Attribute)은 UUID를 가지며 128비트로 구성됩니다. ATT에 의해 부여된 속성은 특성(characteristic)과 서비스(Service)를 결정합니다.
Characteristic : 하나의 특성(characteristic)은 하나의 값과 n개의 디스크립터를 포함합니다.
Descriptor : 디스크립터는 특성의 값을 기술합니다.
Service : 하나의 서비스는 특성들의 집합입니다. 예를 들어 "Heart Rate Monitor"라고 불리는 서비스를 가지고 있다면 그 서비스는 "heart rate measurement"같은 특성을 포함합니다.

GATT-based profile의 리스트와 서비스는 bluetooth.org 에서 확인할 수 있습니다.

역할에 따른 구분 (복습)

CENTRAL / PERIPHERAL BLE 로 연결되기 위한 서로의 역할을 구분한 것입니다. central 은 scan, 게시검색(looking for advertisement)을 담당합니다. 그리고 peripheral 은 게시(advertisement)를 만듭니다. 예를들어 폰과 센서장치가 있다면 폰이 주변의 센서장치를 스캔하는 역할을 할 것이므로 central 이 됩니다. 반대로 센서장치가 peripheral 이 됩니다. 중요한 점은 peripheral 은 오로지 하나의 central 장치에만 연결될 수 있습니다. peripheral 이 central 에 연결되면 게시(advertising)를 중단하기 때문입니다. 따라서 다른 central 장치는 peripheral의 연결이 해제될 때 까지 찾을 수 없습니다.

GATT SERVER(SLAVE) / GATT CLIENT(MASTER) BLE 장치가 연결된 이후 어떻게 서로 통신하는지에 대해 정의합니다. 일반적으로 peripheral 장치(센서장치)가 GATT server 역할을 하며 ATT lookup data, service, characteristic 에 대한 정의를 가지고 있습니다. GATT client(폰, 태블릿 등)에서는 GATT server 로 데이터 요청을 보냅니다. 모든 동작(transaction)은 GATT client 에서 시작되어 GATT server로 부터 응답을 받게 됩니다.

두 장치가 연결될 때 peripheral(센서장치) 은 연결간격(connection interval)을 전달합니다. Central(폰)은 이 시간만큼 간격을 두고 새로운 데이터가 있는지 재연결을 시도할 수 있습니다. 하지만 이것은 필수 사항은 아닙니다.

전체 구조

BLE에서 사용하는 GATT 기반 동작구조는 프로파일(Profile), 서비스(Service), 특성(Characteristic) 에 기초합니다. 아래 이미지와 같은 수직 구조를 이룹니다.

프로파일(PROFILE)

프로파일은 BLE peripheral(센서장치) 에 실제로 존재하는 것은 아닙니다. 이것은 Bluetooth SIG(블루투스 표준 개발그룹) 혹은 peripheral(센서장치) 디자이너에 의해서 만들어진, 미리 정의된 서비스의 묶음입니다.

Heart Rate Profile (HRP)을 예로 들어보겠습니다. 이 프로파일은 Heart Rate Service(필수)와 Device Information Service(선택)를 결합한 것입니다. 이 두 서비스를 묶어서 Heart Rate Profile 이라고 정의했으며 논리적인 구분이라고 보시면 됩니다.

서비스(SERVICE)

서비스는 데이터를 논리적인 단위로 나누는 역할을 하며 특성(characteristic)이라 불리는 데이터 단위를 하나 이상 포함하고 있습니다. 각 서비스는 UUID라 불리우는 16bit(for officially adopted BLE Services) 혹은 128bit(for custom services) 구분자를 가지고 있습니다. 표준 그룹에서 제정한 공식 서비스 리스트는 [링크]에서 확인할 수 있습니다.

이 중 Heart Rate Service 를 확인해보면 16-bit UUID - 0x180D 를 사용함을 알 수 있습니다. 그리고 이 서비스는 3개의 특성(Heart Rate Measurement, Body Sensor Location, Heart Rate Control Point) 을 가지고 있고 이 중 Heart Rate Measurement 만 필수임을 알 수 있습니다.

특성(CHARACTERISTIC)

GATT 기반 동작구조에서 가장 하위 단위는 특성입니다. 특성은 단 하나의 데이터만을 포함합니다. 가속도 센서처럼 X, Y, Z 축 값이 한 쌍을 이루는 경우 일련된 값의 나열(배열)도 하나의 데이터로 간주합니다.

서비스와 유사하게 특성도 16-bit 또는 128-bit UUID 를 가지고 있고 표준 특성 리스트를 제공합니다. 혹은 본인의 목적에 맞게 특성을 정의해도 됩니다.

예를들어 Heart Rate Measurement 특성은 Heart Rate Service 의 필수 특성으로 UUID - 0x2A37 을 사용합니다. 이 특성은 데이터의 첫 8bit 중 첫 1bit 가 Heart Rate Measurement(HRM) 데이터 타입을 표시합니다. 데이터 타입이 0일 경우 이어지는 HRM 데이터는 UINT8 타입이고 1일 경우는 UINT16 입니다. 이와같이 BLE에서 특성은 peripheral(센서장치)와 데이터를 주고 받는데 핵심 역할을 합니다. 특성은 또한 Central(폰) 장치에서 peripheral(센서장치)로 데이터를 전송할 때도 사용됩니다.

간략하게 실제 폰에서의 동작과정을 요약하면 Central(폰) 장치는 아래와 같은 순서를 거쳐 데이터를 받아 처리합니다.

먼저 폰은 주변의 BLE 장치를 스캔합니다. (GAP profile 이 정의하는 것이 이 과정. 주기적으로 advertising 이 되는 데이터가 어떻게 이루어져 있는지를 정의)
폰은 스캔 결과에서 원하는 peripheral(센서장치)가 보이면 연결 (두 장치가 연결되면 센서장치는 advertising을 종료, Central(폰)은 GATT client 역할을 하고 GATT server에 연결하는 것)
이제 이후부터는 안드로이드, iOS 프레임웍에서 GATT client를 운영하고 데이터 수신, 연결 상태의 변화 등 각종 이벤트가 발생 할 때 앱에 알려주게됩니다. (이 과정을 운용하기 위해 필요한 내용들이 GATT/ATT에 정의됨)
먼저 연결된 장치의 GATT 정보와 Service 정보를 수신 (Service UUID 정보로 확인) Characteristic 정보 수신 (UUID 값으로 실제 처리할 데이터를 추출)