강좌 전체보기

.

3장에서는 블루투스 기술을 활용한 통신 및 서비스 구축 방법에 대해 다룹니다.

블루투스 통신 모듈을 직접 다루기 위해서는 블루투스 프로토콜 스펙에 대해 살펴볼 필요가 있습니다. 하지만 블루투스 프로토콜 스펙이 워낙 방대하기도 하고 어렵기도 하므로 아래의 내용을 전부 이해하고 넘어가기는 힘듭니다. 일단은 한번 훝어본다는 느낌으로 일독하시길 권장합니다.

[3-5 BLE 프로토콜 소개] 파트에서 BLE 스펙 중에서 실습해 필요한 부분은 따로 간추려서 쉽게 설명을 할 예정이므로 굳이 여기서 스펙의 세세한 부분을 이해하려 할 필요는 없습니다.

1. 블루투스(Bluetooth)

블루투스는 1994년 에릭슨이 최초 개발을 시작하고 2000년 대에 본격적으로 사용되기 시작한 근거리 무선통신 기술입니다. 무선랜과 같은 2.4GHz 주파수 대역을 사용하며, 주파수 대역을 여러개의 채널로 분할한 뒤 신호간 간섭을 피하기 위해 주파수 호핑 방식을 사용합니다.

  • 주파수 호핑(frequency hopping): 다수의 채널 사이를 특정 순서에 따라 이동하며 데이터를 분할 전송하는 방법. 혼잡이 심한 채널은 건너뛰고 다른 채널 사용함으로써 동일 주파수 대역폭을 사용하는 기기간 주파수 간섭에 대응 가능. 블루투스 클래식의 경우 초당 1600번 호핑. 마스터 기기가 생성하는 호핑 패턴에 슬레이브 기기가 동기화 함으로써 통신이 가능.

블루투스는 기기간 1:1 데이터 통신을 위해 사용되는 것이 일반적입니다. 하지만 경우에 따라 블루투스는 하나의 마스터 장치를 중심으로 여러대의(최대 7대) 슬레이브 장치가 연결되는 Piconet 을 구성할 수 있으며, 이를 확장한 Scatternet  구성이 스펙상으로는 가능합니다.

Bluetooth network

블루투스 통신 표준은 2016년 6월에 버전 5 가 발표되기까지 굵직한 변화들을 거쳐왔습니다. 이 중 우리가 주요하게 봐야 할 버전은 2.0 과 4.0 입니다. 아래는 블루투스 표준의 변화 과정과 주요한 특징입니다.

  • 블루투스 1.0 ~ 1.1 ~ 1.2
    • 1.1 버전은 2002년 IEEE 표준 승인
    • 전송속도 723kbit/s
  • 블루투스 2.0 + EDR (Enhanced Data Rate)
    • 2004년 10월 표준화
    • 데이터 전송 속도가 3.0Mbit/s 로 향상(실속도 2.1Mbit/s)
  • 블루투스 2.1 + EDR
    • 2007년 7월 채택
    • 1.2 버전과 호환
  • 블루투스 3.0 + HS (High Speed)
    • 2009년 4월 발표
    • 최대 24Mbps
  • 블루투스 4.0 + LE (Low Energy)
    • 2010년 6월 채택
    • Classic Bluetooth(2.x 호환) / Bluetooth high speed (3.x 호환) / Bluetooth Low Energy(BLE) 프로토콜을 모두 포함
    • BLE의 경우 저전력 구동, 1Mbps 속도
  • 블루투스 4.1
    • 2013년 12월
    • 공존성(coexistence) 향상, 더 나은 연결(better connections), 데이터 전송 개선(improved data transfer), 개발자에게 더 많은 유연성 제공(more flexibility to developers), IoT를 위한 IPV6 표준 추가
  • 블루투스 4.2
    • 2014년 12월. IoT 지원을 위한 특징들을 도입
    • IPv6, 6LoWPAN 을 이용한 인터넷 직접 접속
  • 블루투스 5
    • 2016년 6월
    • 사물인터넷에 초첨
    • 데이터 전송 속도와 신호 도달 범위의 trade off 가 가능

이 중 우리가 자주 접하고, 강좌에서 주요하게 다룰 버전은 2.0과 4.0 입니다.

구형 스마트 폰이라 하더라도 대부분 2.0 버전을 지원하는 블루투스 칩을 내장하고 있습니다. 그래서 블루투스 2.0 버전은 지원하는 단말의 스펙트럼이 넓고 상대적으로 빠르며, (개발자 입장에서는) 구현도 간단한 장점이 있습니다. 하지만 블루투스 연결이 성립된 이후에 소모전류가 상대적으로 높은 단점이 있습니다.

블루투스 4.0 버전에서 이러한 단점을 해결한 BLE(Bluetooth Low Energy) 스펙이 포함되었습니다. BLE는 모바일, 센서장치가 저전력으로 블루투스 통신 기능을 사용할 수 있도록 해주기 때문에 각종 웨어러블 장치 뿐 아니라 비컨 장치, 센서장치가 BLE 를 기반으로 동작합니다. 다만 전송 속도면에서는 블루투스 2.0 버전보다 느립니다. 블루투스 4.0 버전은 하위 버전의 블루투스 스펙들도 포함하고 있긴 하지만, 많은 경우 BLE 라는 단어가 블루투스 4.0 버전을 지칭하는 단어처럼 사용됩니다. 그리고 블루투스 2.x 버전은 클래식 블루투스(Classic Bluetooth) 라고 지칭합니다. 본 강좌에서도 블루투스를 크게 클래식 블루투스 – BLE 로 구분해서 언급합니다.

사실 사용자 입장에서는 클래식 블루투스와 BLE 는 큰 차이가 없습니다. 하지만 개발자 입장에서 클래식 블루투스와 BLE는 전혀 다른 프로토콜입니다. 어플리케이션을 제작하는 입장에서 클래식 블루투스는 주변의 장치를 스캔해서 원하는 장치를 찾기만 하면 연결과 통신이 간단하게 구현됩니다. 반면 BLE는 연결 후 데이터 송수신을 위해서는 BLE 프로토콜에 대한 상당한 이해가 필요합니다. 따라서 본격적으로 BLE 장치를 세팅하고 사용하기 전에 BLE 프로토콜을 살펴보도록 하겠습니다.

2. 블루투스 장치의 구분

블루투스 통신을 사용하는 장치들은 Bluetooth classic, Bluetooth Smart Ready, Bluetooth Smart 로 구분됩니다. 개념적인 구분이므로 한번 읽어만 보시면 됩니다.

  • Bluetooth classic
    • BLE 이전의 스펙을 사용하는 기기를 지칭합니다. 멀티미디어, 대용량 텍스트 등을 다루는 장치들입니다.
  • Bluetooth Smart Ready
    • Bluetooth classic와 BLE를 모두 지원하는 장치를 말합니다. (듀얼 모드) 핸드폰이나 PC, 태블릿 등이 해당되며 보통 Bluetooth Smart Ready 마크를 붙여 해당 기능을 가지고 있음을 표시합니다.
  • Bluetooth Smart
    • BLE 연결만 지원하는 장치를 말합니다. (싱글 모드) 저전력으로 구동되며 소량의 데이터를 생산하는 센서장치가 여기에 해당합니다.

3. 블루투스 프로토콜 스택

싱글 모드로 동작하는 블루투스 Smart 장치(센서장치)들은 아래와 같이 Application-Host-Controller 3개의 계층 구조를 이루며 동작합니다.

Bluetooth Protocol Stack

우리가 ESP32 같은 모듈을 이용해 블루투스 장치를 만든다면, 이 계층 구조중에서 Application 계층을 코드로 작성하는 것입니다. App 계층은 블루투스 장치의 전체적인 동작을 개발자가 원하는대로 제어하는 부분이므로 이 스펙 문서에서 언급할 내용은 거의 없습니다.

Host 계층은 개발자가 직접 구현하는 부분은 아닙니다. 이미 이 계층을 위한 코드들은 칩 개발사에서 제공합니다. 하지만 우리 입맛에 맞게 블루투스 기기의 동작 속성을 바꾸고, 블루투스 장치와 연결되는 PC – 스마트 폰에 올라가는 어플리케이션 작성을 위해 Host 계층이 동작하는 방식을 알아야합니다. Host 계층 중에서도 GAP과 GATT 이 중요합니다. (특히 GATT !!)

Controller 계층은 블루투스 기기의 물리적인 회로와 이를 제어하는 저레벨의 software를 지칭합니다. 이 중 Link Layer 의 내용이 중요합니다.

이제 이 계층들을 하나씩 살펴보도록 하겠습니다.

4. Physical Layer

Physical Layer(PHY) 는 아날로그 통신을 담당하는 회로와 디지털 데이터 – 아날로그 신호를 변환 (modulation and demodulation)하는 기능을 포함합니다.

BLE는 2.4 GHz ISM (Industrial, Scientific, and Medical) 주파수 대역을 사용하고, 2402MHz ~ 2480MHz 대역을 2MHz 단위로 분할해서 총 40 개의 채널을 사용합니다. 이 중 [37-38-39] 3개의 채널은 기기간 상호 인지를 위해 advertising 신호를 broadcast/scan 하고 연결을 시작하기 위한 Advertising 채널로 사용합니다. 클래식 블루투스는 1MHz 단위로 분할해서 총 79 개의 채널을 사용합니다.

BLE channels

Classic BT channels

5. Link Layer

Link Layer 는 PHY 레이어와 직접 상호작용하는 hardware와 software로 구성되어 있습니다.

  • Preamble, Access Address, and air protocol framing, CRC generation and verification, Data whitening, Random number generation, AES encryption 등 복잡하고 처리하는데 비용이 많이 드는 작업들이 hardware 레벨에서 처리됩니다.
  • Software 레벨에서는 블루투스 기기간 통신 및 연결 상태를 관리합니다.

블루투스로 연결되는 두 장치는 서로 다른 역할을 가지게 됩니다. USB 에서 Host(controller), Client 로 나누듯 블루투스도 Master, Slave 로 역할을 나누고 Master 가 더 많은 제어, 처리작업을 담당하도록 합니다. 이렇게 함으로써 Slave 역할을 하는 센서장치(peripheral)는 더 작은 리소스로 구동할 수 있습니다. 이를 위해 Link Layer 에서는 다음과 같은 역할(role)을 정의해 두었습니다.

  • Advertiser
    • advertising packet 을 전송하는 장치
  • Scanner
    • advertising packet 을 수신하는 장치
  • Master
    • 연결을 시작하고 관리하는 장치
  • Slave
    • 연결 요청을 수락하고, 마스터 장치가 보내준 timing(호핑 규칙)을 따르는 장치

Advertiser 와 Scanner 는 두 장치가 연결되기 전에 서로 담당해야 할 역할을 말합니다. Master 와 Slave 는 연결이 되고 난 이후 각자가 맡을 역할입니다.

Link Layer 에서는 BLE 장치가 서로를 발견하고 연결을 맺은 뒤, 데이터 통신을 하기까지 하위 레이어에서 일어나는 과정 전반을 다룹니다. 따라서 블루투스가 동작하는 (저레벨의) 구조를 익히고 싶다면 이 파트를 유심히 보시는 것이 좋습니다.

Advertising and Scanning

BLE 는 송출하는 packet의 형식(format)이 하나로 정해져 있습니다. 그리고 advertising, data 두 종류의 패킷을 사용합니다. 먼저 advertising packet 과 이를 송출, 수신하는 Advertiser, Scanner 에 대해 다뤄보겠습니다.

Advertising packet 은 BLE 장치들은 서로를 인식하는 과정에 사용됩니다.

  • Advertiser 장치가 목적지 없이 주변에 advertising packet을 송출하면, Scanner 장치는 이걸 수신해서 주변에 있는 advertiser 장치들을 인지합니다.
  • Advertising packet 은 header data(장치 정보)에 31 byte data payload (사용자 지정 데이터)를 합친겁니다. 헤더 데이터에는 6 byte MAC address (Bluetooth address) 도 포함하고 있습니다. 6 Byte MAC address (Media Access Control)는 블루투스 장치를 구분하는 고유한 주소값입니다.
  • Packet 을 송출하는 간격(advertising interval)은 20ms ~ 10.24s 사이에서 조절할 수 있습니다. 간격이 짧을수록 빠르게 인식되지만 소비 전류가 많아집니다.
  • Advertiser와 Scanner는 세 개의 advertising channel 을 임의로 호핑하면서 데이터를 송출-스캔하기 때문에, 한 채널에 둘이 오버랩 되는 경우에만 데이터가 전달됩니다. 이 물론 호핑하는 속도가 빠르기 때문에 시간이 걸리더라도 오버랩은 됩니다.

Advertising packet을 수신하는 Scanner 입장에서는 advertising packet 을 수신한 이후의 동작에 따라 두 가지로 분류할 수 있습니다.

  • Passive scanning
    • 단순히 advertising packet 을 수신만 합니다. 수신 여부를 advertiser 에게 전송하지 않습니다.
  • Active scanning
    • advertising packet 을 수신하면 Scan Request 라 불리는 packet 을 advertiser에게 전송합니다. Advertiser 가 Scan Request를 받으면 다시 Scan Response 라 불리는 packet 을 응답으로 보내줍니다. Advertising packet 의 31 byte 에 담지 못했던 정보가 있다면 Scan Response 에 31 byte 를 추가해서 보낼 수 있습니다. 일반적으로 블루투스 장치의 이름이 Scan Response 로 전달됩니다. 그래서 블루투스를 스캔하면 MAC 주소가 먼저 뜨고, 잠시 후에 이름으로 대체되는 것입니다.

아래는 advertising packet 과 scan response 로 전달받는 데이터의 실제 구조입니다. (참고 설명)

 

Advertiser 는 세 개의 상태값을 가질 수 있으며, 이 값이 Advertising packet 에 포함되어 전송됩니다.

  • Connectable / Non-connectable
    • Scanner 가 advertising packet 을 받은 이후 연결을 시도할 수 있는지를 나타냅니다. Non-connectable 이면 오직 advertising packet 만을 송출하는 장치라는 뜻입니다. (예 – 비컨 전용 기기)
  • Scannable / Non-scannable
    • Scanner 가 advertising packet 을 받은 이후 Scan request 를 보낼 수 있는지를 나타냅니다.
  • Directed / Undirected
    • Directed 상태값을 가진다면 advertising packet 에는 송출기기와 수신기기의 Bluetooth address 만 포함하고 그 밖의 사용자 데이터를 가지지 않습니다. 이 속성은 연결을 원하는 기기가 명확히 정해져 있다는 것을 의미합니다.

실제 상태값이 Advertising packet에 포함될 때는 아래처럼 조합되어 사용됩니다. 일반적으로 사용되는 ADV_IND 값은 해당 BLE 기기가 advertising 할 때 31 byte 의 사용자 데이터를 포함해서 전송하고, Scan resquest 에 응답을 하며, 연결 요청을 받아들인다는 의미입니다.

Advertising PDU Description Max adv data len Allow scan req Allow connect
ADV_IND Used to send connectable undirected advertisement 31 bytes Yes Yes
ADV_DIRECT_IND Used to send connectable directed advertisement N/A No Yes
ADV_SCAN_IND Used to send scannable undirected advertisement 31 bytes Yes No
ADV_NONCONN_IND Used to send non-connectable undirected advertisement 31 bytes No No
ADV_EXT_IND Used to indicate that an advertisement will be sent on a secondary advertisement channel. No adv data allowed. No No
AUX_ADV_IND Used to send connectable directed advertisement on a secondary advertisement channel. 254 bytes Yes Yes
AUX_SYNC_IND Used for periodic advertisements on secondary advertisement channels. 254 bytes No No
AUX_CHAIN_IND Used to chain advertisement packets, allowing the advertisement data to extend beyond one packet. 254 bytes N/A N/A

Connections

두 블루투스 장치가 연결을 맺으려면 Master 장치는 스캔을 하고 connection request packet 을 보내야 합니다. 여기에 Slave 장치가 응답하면 연결이 맺어집니다. Connection request packet 은 채널 호핑을 위한 정보를 담고 있습니다.

Link Layer 는 BLE 는 블루투스 기기가 미리 정해진 몇 개의 장치만 연결될 수 있도록 해주는 White list 기능을 제공합니다. 이 기능을 사용할 경우 미리 정해진 Bluetooth address 가 아니면 연결 요청을 무시합니다.

Connection 자체는 단순히 Slave 와 Master 장치가 정해진 시간 간격에 따라 (connection interval) 데이터를 주고 받는 것입니다. 따라서 connection 을 맺을 때 마스터는 연결 설정과 관계된 connection parameter들을 전달해서 공유해야 합니다. 다음 세 항목은 그 중 주요한 파라미터들 입니다.

  • Connection interval
    • 두 장치 사이의 데이터 통신(connection event)은 주기적으로 이루어집니다. 각 통신의 시작 시점 사이의 간격이 connection interval 입니다. (7.5 ms  ~ 4 s) 이 시간 간격은 배터리 소모와도 연관이 있습니다.
  • Slave latency
    • Slave 장치가 주기적으로 이루어지는 connection event 에 응답하지 않아도 연결해제 되지 않는 횟수입니다.
  • Connection supervision timeout
    • 지정된 시간동안 유효한 데이터 송수신이 없는 경우 연결이 해제된 것으로 간주됩니다.

연결 후 데이터를 실어나르는 data packet 은 사용자가 사용할 수 있는 27 byte의 공간(payload)을 제공합니다. 이 공간은 프로토콜이 사용되는 방식에 따라 변경될 수 있기 때문에 일반적으로는 20byte로 제한되어 사용됩니다.

이 밖에도 Link Layer 에서는 몇 가지 제어 기능을 추가로 담당하는데 그 중에서도 다음 두 가지 기능이 중요합니다.

  • Changing the connection parameters
    • 연결을 시작하기 위해 Master 장치가 연결 요청을 보낼 때 connection parameter 를 전달해서 공유한다고 했습니다. 하지만 처음에 설정된 이 파라미터들을 연결 된 상태에서 바꿔줘야 할 경우가 있습니다. 예를 들어 상당량의 데이터 전송을 위해 connection interval 을 짧게 바꾸는 대신 배터리 소모를 희생하는 상황이 이에 해당됩니다. Link Layer 는 Master/Slave 장치가 connection parameter 를 연결 도중에 변경할 수 있도록 처리해 줍니다.
  • Encryption
    • 암호화된 데이터 통신을 사용하는 경우 데이터 암복호화 작업을 담당합니다.

BLE 장치가 서로를 발견한 뒤(advertising/scanning) 연결을 맺고(connection) 데이터 통신을 하기까지 서로 주고 받는 무선 신호를 도식화 하면 아래와 같습니다.

6. Security Manager (SM)

SM은 두 장치가 암호화 된 보안 통신을 할 때 필요한 보안키를 생성-교환할 수 있도록 보안 알고리즘과 프로토콜을 제공합니다. SM은 BLE 장치가 담당할 두 가지 역할을 정의합니다.

  • Initiator
    • Link Layer 의 Master (GAP 에서의 Central)
  • Responder
    • Link Layer 의 Slave (GAP 에서의 Peripheral)

SM 은 다음의 세가지 procedure 를 제공합니다.

  • Pairing
    • 보안 링크를 구축하기 위해 temporary security encryption key 를 생성합니다. Encryption key는 연결이 지송되는 동안 유지되지만 저장되지 않기 때문에 다른 연결에 재사용될 수 없습니다.
  • Bonding
    • 일단 Pairing 과정이 끝나면 shared security key 를 저장해서 다음번 연결해도 재사용할 수 있는 보안 관계를 구축할 수 있습니다. 이 상태를 Bonding 또는 Pairing with Bonding 이라고 합니다.
  • Encryption Re-establishment
    • Bonding 과정이 끝나면 키가 양쪽 장치에 저장됩니다. Encryption re-establishment 는 저장된 키를 이용해서 다음번에 다시 연결될 때 Pairing-Bonding 없이 보안 연결을 재설정하는 방법을 제공합니다.

SM이 동작하는 구조는 위 이미지와 같습니다. Phase 1 에서 temporary key 생성을 위해 필요한 정보들을 교환합니다. Phase 2 에서는 Temporary encryption key(STK, Short Term Key) 를 양쪽 장치에 생성하고 연결을 암호화 하는데 사용합니다.  이후  Bonding을 실행한다면 Key distribution 과정을 통해 permanent key 를 받아 저장하고 다음번 접속 때 재사용합니다.

Pairing procedure는 temporary security encryption key(STK) 를 양쪽 장치에 생성하기 위해 Security Manager Protocol(SMP) packet 을 교환합니다. 이 과정이 끝나면 최종적으로 STK 를 이용한 암호화 통신이 가능합니다.

7. GAP (Generic Access Profile)

GAP는 Generic Access Profile의 약자로, 다양한 제조사에서 제작된 BLE 장치들이 서로 연동될 수 있도록 프레임워크를 제공합니다. Advertising/Scanning 단계부터 Connection이 완료되어 데이터 통신을 위한 준비가 끝날때까지 BLE 장치가 취해야 할 Action 과 State 들을 정의합니다.

GAP 에서는 BLE 장치가 서로 연동할 때 다음과 같은 5가지 관점으로 접근합니다. 그리고 BLE 장치가 연동할 때 각 관점에서 어떤 일들을 해야하는지 정의합니다.

  • Role
    • BLE 장치는 동작할 때 하나 이상의 역할을 합니다.
  • Mode
    • BLE 장치가 맡은 Role 을 수행하기 위하여 사용해야 할 상태(=Mode)를 정의합니다. Mode 는 Role 에 비해 자주 바뀔 수 있습니다.
  • Procedure
    • BLE 장치가 특정한 목적을 이루기 위해 수행해야 할 작업(Action)의 목록입니다. Procedure는 다른 BLE 장치의 Mode 와 긴밀하게 연관되어 있습니다.
  • Security
    • GAP 은 Security Manager 와 Security Manager Protocol 에  밀접하게 관련되어 있습니다. GAP 은 보안 레벨을 컨트롤하는 방법과 기타 보안 특성을 제시합니다.
  • Additional GAP Data Formats
    • Mode, procedure 와 관련된 data format 을 정의합니다.

GAP 프로토콜에서 다루는 내용 중 많은 부분이 Link Layer 에서 다룬 개념들과 중복됩니다. 그래서 GAP 에서 눈여겨 봐둘 만한 내용만 간추렸습니다.

Role

GAP은 특정 장치가 다른 장치들에게 어떻게 보여지도록 할 것인가와 어떻게 두 장치를 연결할 것인가를 결정합니다. 이때 각각의 장치는 GAP에서 정의한 하나 이상의 역할(role)을 맡게 됩니다.

  • Broadcaster
    • Link Layer 의 advertiser 역할에 상응합니다. 특정한 타켓 장치나 연결과는 상관없이, 데이터를 주기적으로 주변에 뿌립니다. 이때 advertising packet 에는 전송하고자 하는 데이터를 소량 담을 수 있기 때문에 신호를 수신하는 어떤 장치든 해당 데이터를 사용할 수 있습니다. iBeacon 스펙을 따르는 비컨 장치가 여기에 해당됩니다.
  • Observer
    • Link Layer 의 scanner 역할에 상응합니다. advertising packet 을 수집하고 여기에 담긴 데이터를 이용하는 장치입니다.
  • Central
    • Link Layer 에서 정의한 Master에 대응됩니다.  Central 장치는 다수의 장치들이 네트워크에 함께 연결될 수 있도록 구심점 역할을 하기 때문에 폰이나 태블릿과 같이 충분한 전원과 메모리 등의 리소스를 갖춘 장치입니다.
  • Peripheral
    • Link Layer 의 Slave에 대응됩니다. Peripheral 장치는 주로 작고, 저전력으로 동작하고, 제한된 리소스를 가진 장치들로 보다 리소스가 풍부한 Central 장치에 연결되어 동작하도록 설계된 장치입니다. Heart Rate Monitor(심박측정기), BLE 근접센서 태그와 같은 센서장치가 이 역할을 맡습니다. Peripheral 장치는 Central 장치가 자신을 찾아서 연결할 수 있도록 advertising packet 을 이용합니다.

Discovery

Peripheral 장치는 advertising packet 을 전송할 때 discoverability mode 를 설정할 수 있습니다.

  • Non-discoverable mode
    • 이 모드가 설정된 장치는 advertising packet 을 전송하기는 하지만 connection 을 원치 않으며, scanning  결과에 포함되기도 원치 않는 상태입니다.
  • Limited discoverable mode
    • 특정 시간 동안만 scanning 되고 connectable 하길 원할 때 사용합니다. Limited discovery procedure 를 수행하는 Central 장치는 이 모드를 사용한 장치만을 필터링합니다.
  • General discoverable mode
    • 제한없이 scanning 이 가능하고 connectable 한 모드입니다. 일반적으로 사용되는 모드입니다.

Peripheral 장치가 출시될 때 General discoverable mode 를 사용하더라도 특정 장치와 연결된 이후에는 Non-discoverable mode 로 동작하도록 만들 수 있습니다. 이 경우 이전에 연결된 장치만 다시 연결할 수 있도록 만들 수 있습니다.

Connection establishment procedures

Central 장치는 connection을 맺을 때 아래와 같은 procedure 중 하나를 선택할 수 있습니다.

  • Auto connection establishment
    • Central 장치는 자동 접속을 원하는 Peripheral 장치들을 white list 로 등록 관리합니다. 그리고 white list 에 등록된 장치 중 하나가 검색되면 바로 연결을 시도합니다. scanning 이후 조건이 맞으면 connection 시도까지 하나의 스텝으로 처리합니다.
  • General connection establishment procedure
    • 새롭게 발견된 장치와 연결할 때 사용하는 가장 일반적인 procedure 입니다. White list 없이 모든 장치를 검색하지만, 어플리케이션이 이 중 어떤 장치와 연결할지 선택해야만 다음 과정이 진행됩니다.
  • Selective connection establishment procedure
    • General connection establishment procedure 와 거의 동일한데, 스캐닝 한 advertising packet 들 중에서 white list에 등록된 결과만 필터링해서 알려줍니다. 이 중 하나를 선택하면 connection 을 시도합니다.
  • Direct connection establishment procedure
    • Bluetooth address 를 이용해 특정 기기에 바로 접속을 시도합니다. 타겟이 되는 장치가 유효할 때만 접속이 됩니다.

GAP Service

GAP 프로토콜은 두 장치가 연결되었을 때, 별다른 보안 없이도 Central 장치에게 반드시 다음의 항목들이 보여지고 억세스(read-only) 가능해질것을 강제합니다.

  • Device Name characteristic
  • Appearance characteristic
    • 접속한 기기가 어떤 종류인지를 설명 (폰, PC, 시계, 센서 등)
  • Peripheral Preferred Connection Parameters (PPCP) characteristic
    • 두 장치간 연결 설정을 바꿀 수 있도록 해주는 connection parameter update procedure 용 필드

8. GATT (Generic Attribute Profile)

일단 BLE 장치가 서로 연결되고 데이터 통신을 위한 준비가 모두 끝났다면 이제 서로가 할 수 있는 일들을 인지하고 상황에 맞게 데이터를 주고받아야 합니다. BLE 에서는 어떤 장치와 연결되더라도 일관된 방식으로 데이터를 주고 받을 수 있도록 데이터 형식(format)과 동작방식(procedure)을 추상화 했습니다.

BLE 표준은 시장에서 자주 사용될 수 있는 장치들과 그 속에 포함될 기능, 데이터 들을 미리 정의해 두었는데 이를 Profile 이라 부릅니다. 이런 Profile 들이 실제 BLE 장치속에서 구현될 때 갖춰야 할 데이터 형식, 데이터의 계층 구조, 동작방식이 GATT 을 기반으로 합니다.

Role

GATT 에서는 데이터 통신에 참여하는 BLE 장치를 다음과 같은 두 가지 역할로 구분합니다. 각 장치가 하나의 역할을 맡습니다. 아래 내용은 BLE 어플리케이션 작성을 위해 매우 중요한 부분입니다!

  • GATT client
    • GATT client 장치는 GATT server 장치로 request를 보내고 해당되는 response를 받습니다. 즉, 데이터가 무선으로 전달되기 위해서는 GATT client 가 먼저 요청을 보내야합니다.
    • 이런 시나리오로 동작하기 위해서는 GATT client 장치는 사전에 GATT server 가 제공하는 service 가 무엇인지, service 는 어떤 데이터들을 보내줄 수 있는지 알고 있어야합니다. 그래서 BLE 연결이 성공적으로 이루어지는 시점에 GATT client 는 먼저 Service Discovery 라는 동작을 합니다. GATT server 에 요청해서 제공할 수 있는 service 와 데이터가 무엇인지 목록을 받는 것입니다.
  • GATT server
    • 일반적으로 웹 서버는 클라이언트가 보내는 request 가 있을 때, 여기에 상응하는 데이터를 response로 보내줍니다. GATT server 도 마찬가지로 GATT client 가 보내는 request 가 있으면, 해당하는 동작을 한 후 response 를 보내줍니다.
    • 단, GATT server 는 일반적인 인식과는 달리 성능 좋은 PC나 모바일 폰 등이 담당하지는 않습니다. 보통은 저전력으로 동작하는 센서장치, GAP 에서 정의하는 peripheral 장치가 GATT server 역할을 맡는 경우가 많습니다. BLE 데이터 요청과 컨트롤을 GATT client 에서 담당하므로 더 많은 에너지를 소비하기 때문입니다.

주로 센서장치가 담당하는 GATT server 는 자신이 제공하는 서비스와 데이터를 아래와 같은 계층구조로 만들어서보관하고 있습니다. Service discovery 동작이 GATT client 가 이 계층 구조를 받아오는 작업입니다.

Profile

GATT server 역할을 하는 BLE 장치가 어떤 일을 하는 장치인지를 나타내는 개념적인 구분입니다. 블루투스 공식 홈페이지에서 GATT Specification 페이지를 보면 프로토콜에서 정의한 표준 profile 들이 있습니다. 혈압 profile, 심박 profile 등 다양한 profile 들이 있는데, ‘이런 기능을 하는 센서장치를 만들때는 이런 사항들을 지켜라’ 라는 가이드 정도로 보시면 됩니다. 표준 profile을 따르거나 혹은 custom profile 을 구현한 BLE 장치 자체가 profile 이라고 봐도 무방합니다. 실제 Service discovery 동작을 하더라도 Profile 정보는 오지 않습니다.

Service

만약 운동 보조용 BLE 센서장치를 만든다면 여기에는 다양한 센서가 탑재될 겁니다. 사람의 움직임을 측정하기 위한 목적으로 가속도-자이로-지자기 센서를 탑재하고, 신체 변화를 측정하기 위해서 심박-체온 센서를 사용한다고 가정해 보겠습니다. 그러면 아래와 같은 Profile 구조로 만들 수 있습니다.

  • [운동 보조 기구 profile]
    • [움직임 측정 Service]
      • 가속도 센서 값 characteristic
      • 자이로 센서 값 characteristic
      • 지자기 센서 값 characteristic
    • [신체 변화 감지 Service]
      • 심박 측정 값 characteristic
      • 체온 측정 값 characteristic

이처럼 Service 는 특정한 기능과 관련이 있는 데이터들의 집합입니다. Service 는 서로를 구분하기 위해 고유한 UUID 값을 가지는데, 블루투스 표준에 정의된 Service 인 경우 이미 정의된 16 bit UUID 값을 가집니다. 직접 만든 사용자 정의(user-defined) Service 는 128 bit UUID 를 사용합니다.

  • Heart Rate Service UUID 예 : 180D
  • user-defined Service 예 : 195AE58A-437A-489B-B0CD-B7C9C394BAE4

Service 는 Primary service, Secondary service 두 종류가 있습니다. Primary service 는 GATT 에서 정의한 일반적인 서비스이며, Secondary service 는 하나 이상의 Primary service 에 의해 참조되면서 부가적인 기능을 추가해 주는 역할을 합니다. Secondary service 는 거의 사용되지 않습니다.

Characteristic

Characteristic 은 실질적인 데이터를 담고 관리합니다. 센서장치가 Characteristic 에 설정된 값을 변경하면 GATT client 가 Read 요청을 보냈을 때 읽어가는 값도 변경됩니다. 혹은 GATT client 에서 Characteristic 에 값을 쓸 수도 있습니다. Characteristic 의 구조는 아래와 같습니다.

  • Characteristic definition
    • Characteristic declaration : Characteristic 을 설명하는 메타데이터. 3개의 attribute 값을 가짐
      • Characteristic properties : Characteristic 의 특성
      • Characteristic Value Handle : Characteristic 의 실질적인 데이터인 value 에 접근하기 위한 Handle 값을 저장합니다.
      • Characteristic UUID : 2 byte, 4 byte, 16 byte UUID 사용
    • Characteristic value : Characteristic 이 담는 데이터
    • Characteristic descriptor

Characteristic Properties 는 아래의 값들을 가질 수 있습니다.

  • Broadcast : 이 값을 설정하면 Characteristic value 값이 advertising packet에 Service Data AD Type 항목으로 포함되어 전송됩니다. 즉, BLE 연결 없이 advertising packet 만 scanning 해서 값을 받을 수 있습니다.
  • Read : GATT client는 value 값을 읽을 수 있습니다.
  • Write without response : GATT client는 value 에 값을 기록할 수 있습니다.
  • Write : Write Request/Response 작업이 순차적으로 일어납니다.
  • Notify : value 값에 변경되면 GATT client 에 알려주는 기능입니다.
  • Indicate : Notify 와 같은 동작을 하지만 notify 이후 GATT client 로 부터 confirmation 을 받습니다.
  • 이 외에도 Signed Write Command, Queued Write, Writable Auxiliaries 를 사용할 수 있습니다.

Characteristic 의 Properties 를 통해 GATT client 는 어떤 데이터를 읽고 쓸 수 있는지 알 수 있습니다. 이 중 특이한 것은 Notify 와 Indicate 입니다. 다른 동작들은 GATT client 가 server 에 요청을 보내고 그에 대한 응답을 받는데 반해, Notify-Indicate 는 GATT server 가 먼저 데이터 변경 알림을 보내기 때문입니다. 그래서 이 기능은 GATT client 가 사전에 이 기능을 사용하겠다고 통보해야 활성화 됩니다. 이때 Characteristic Descriptor 가 사용됩니다.

Descriptor 도 다양한 종류가 있습니다.

  • GATT-defined descriptors
    • Extended Properties Descriptor
    • Characteristic User Description Descriptor
    • Client Characteristic Configuration Descriptor (CCCD)
      • CCCD 가 가장 흔하게 사용되는 descriptor 입니다. 단순히 특정 기능을 on/off 시키는 스위치 역할을 합니다. Notify-Indication 기능을 여기서 on/off 할 수 있기 때문에 2 bit 필드를 가지고 있습니다.
    • 기타…
  • Profile or vendor-defined descriptors

가장 많이 사용되는 것은 CCCD 입니다. Notify-Indication 기능을 on/off 할 수 있는 descriptor 이기 때문입니다.

9. ATT (Attributes)

ATT 는 GATT 에서 정의한 Service, Characteristic 의 개념들을 데이터 형태로 저장하기 위한 스펙이라고 할 수 있습니다. ATT 는 Handle, Type, Permissions, Value – 4가지 항목으로 이루어져 있습니다. 실제 GATT client 에서 수행하는 Service discovery 작업이 일련의 ATT 리스트를 받아오는 작업입니다.

  • Handle
    • 16 bit ID 값입니다. 모든 ATT 항목들은 고정된 handle을 가지며 동작하는 동안 불변합니다.
    • GATT client 에서 특정 service, characteristic 에 접근할 때 handle을 사용합니다.
  • Type (UUID)
    • Handle이 BLE 장치가 ATT 항목들 구분을 위해 임의로 지정한 값이라면, UUID 는 service/characteristic 을 구분할 뿐 아니라 각각의 특징을 알려주는 ID 입니다.
    • 이 ID 는 블루투스 표준에서 정의한 값을 쓸 수도 있고, 임의로 정의해서 사용할 수도 있습니다.
    • UUID 는 2 byte, 4 byte, 16 byte 길이 중 하나를 사용합니다.
  • Permissions
    • 해당 ATT 항목의 접근 권한입니다. 일반적으로 PC에서 File 에 부여된 read/write 권한을 생각하면 됩니다.
    • None / Readable / Writable / Readable and writable
  • Value
    • 실제 데이터가 저장되는 필드입니다. 512byte 제한이 있습니다.

아래는 블루투스 프로토콜 문서에서 제공하는 심박센서 장치의 Service/Characteristic 구조를 바탕으로 ATT 형식으로 표현한 예 입니다.

실제 센서장치에는 이런 구조로 데이터가 저장되고, GATT client 에서 Service discovery 요청이 왔을 때 이 데이터를 보내줍니다. GATT client 에서 ATT 각 항목을 접근할 때는 handle을 사용합니다.

다음 파트에서는 BT/BLE 모듈을 이용한 통신 예제를 실습하겠습니다.

참고 :

주의!!! [사물 인터넷 네트워크와 서비스 구축 강좌] 시리즈 관련 문서들은 무단으로 내용의 일부 또는 전체를 게시하여서는 안됩니다. 계속 내용이 업데이트 되는 문서이며, 문서에 인용된 자료의 경우 원작자의 라이센스 문제가 있을 수 있습니다.

.

강좌 전체보기

.