BLE

본 포스트는 졸업 프로젝트 중간 보고서로 제출한 내용 중 일부를 가져온 것입니다.

 

 블루투스 4.0 스펙을 의미한다. Central 과 Peripheral 방식으로 장치 역할이 나뉘는데, 각자 규칙을 정하는 역할, 제시되는 설정에 따라 동작하는 역할로 보면 된다. 본 프로젝트는 BLE를 이용하므로 그 구조와 프로토콜에 대한 이해가 어느정도 필요하다. 다음은 BLE 의 프로토콜 스택 이미지이다.

 

 크게 Host 와 Controller로 나뉘어 있다. PHY는 하드웨어, LL은 BLE 연결을 직접적으로 관리하는 계층이다. 하드웨어 계층과 직접적으로 연결된 LL에서 연결 상태가 정의 되므로 BLE를 이용하는데 있어 중요한 계층이라고 할 수 있다. 그림은 다음과 같다.

 

 Central 장치가 scanning 을 해서 advertising 중인 peripheral을 발견하고, 연결 준비 상태인 initiating 로 들어가 페어링에 성공하면 connected 상태가 된다. 앱으로 블루투스 디바이스와 페어링을 할 때도 같은 과정을 거칠 것이기 때문에 꼭 알고 있어야 하는 부분이라고 생각한다.

 

 GAP 계층에서는 블루투스 연결에 대한 장치의 역할이 정의된다. Broadcaster, Observer, Central, 그리고 Peripheral 로 나뉘는데, 바빌 키 서비스에서 스마트폰이 수행해 줘야 하는 역할은 Central 이다. ATT는 GATT에서 정의된 Server 역할 장치와 Client 역할 장치의 데이터 교환 규칙이며, 말 그대로 서버는 데이터 보유, 클라이언트는 데이터 요청을 한다. 바빌 키 역시 스캔 후 페어링만 하고 끝낼 수 없으므로, BLE Protocol 에서의 데이터 구조 및 규칙에 대한 이해 역시 굉장히 중요하다. GATT에서 정의된 BLE 의 데이터 구조는 다음 그림을 참고하면 쉽게 이해 가능하다.

 

 즉, Service는 장치에서의 어떤 기능이 정의된 단위라고 볼 수 있고, Characteristic 은 그 Service를 구성하는 요소이다. 두 영역은 물리적으로 attribute라는 데이터 단위로 이루어져 있다. 다음 표를 보면 attribute의 구성요소를 한눈에 파악 가능하다.

 

 handle은 attribute의 주소 값, uuid는 고유 식별자, permission 은 표에 있는 예시처럼 접근 권한을 의미한다. 링크에 충분히 설명되어 있지만, 요약하자면 다음과 같다. 맨 위 행을 보면, 0X000C에 Service 선언 uuid가 심장박동측정 Service의 uuid 0X180D를 값으로 갖고 있다. 바로 아래 행에서는, Characteristic 선언 uuid가 0X00E에 있는 2A37이라는 Characteristic을 값으로 가지는데, 그 아래를 보면 0X00E에 있는 2A37이라는 uuid는 심장박동수 / 분 값을 가지는 Charateristic 이라는 것을 알 수 있다.

 

 본 프로젝트에서는 BLE API를 직접 만들 수는 없기 때문에 ble-plx라는 라이브러리를 가져다 쓰지만, 위와 같은 과정을 이해하고 있지 않으면 원하는 기능을 구현할 수 없다.

 

출처

 

BLE (2) - BLE 프로토콜 스택 - 임베디드 개발장이 ~ Danny’s Embedded Dev-log (enidanny.github.io)

BLE (2) - BLE 프로토콜 스택

BLE (3) - ATT/GATT 이해하기 - 임베디드 개발장이 ~ Danny’s Embedded Dev-log (enidanny.github.io)

BLE (3) - ATT/GATT 이해하기