[Noise Detector] nRF51 (2) : Noise Detector Service 구성

BLE(Bluetooth Low Energy) 프로토콜 중 서비스에 대해 간단히 설명하겠습니다. BLE 프로토콜에 대해 하나도 모르면 이해할 수 없지만, 이전 포스트에서 추천한 서적을 읽고, BLE 프로토콜을 이해하기 위해 노력했다면 약간 정리된 듯한 느낌을 받을 수 있을지도.. 모르겠습니다. BLE를 시작하는 개발자들이 BLE 프로토콜에 대한 약간의 느낌이라도 얻을 수 있으면 좋겠네요.

 

BLE 프로토콜에서 서비스는 자바에서 추상 클래스, 특성(Characteristic)은 서비스의 서브 클래스와 비슷한 개념입니다. 그리고 각 특성의 디스크립터와 값 속성은 서브 클래스의 필드와 비슷한 개념입니다. 이것들은 BLE 스택에서 GATT 프로파일(Generic Attribute Profile) 위에 위치하기 때문에 GATT 프로파일에 종속적인 것 처럼 보이지만, GATT 프로파일과 마찬가지로 속성 프로토콜(ATT Protocol)의 속성 테이블에 위치되며, GATT 프로파일에 의해 관리될 뿐입니다. 어떻게 보면 종속적이라고 볼 수 도 있네요.

 

이것은 비유일 뿐, 서비스는 특정 언어에 종속되지 않으며, 블루투스 SIG에서 서비스를 만드는 코드나 알고리즘을 제공하는 것도 아닙니다. 단지 서비스와 특성에 대한 설명서(스팩)만 제공될 뿐입니다. 그리고 이 스팩에 맞춰 서버와 클라이언트를 구성하는 것 입니다. 

블루투스 SIG는 블루투스 장비들이 많이 사용하는 기능들에 대해서 미리 서비스 스팩으로 만들어서 제공하고 있으며, 해당 서비스를 구현할 때는 호환성을 위해 이 스팩에 맞춰 구현해야 합니다.

프로파일은 서비스의 집합일 뿐입니다.

 

서버는 서비스를 초기화, 관리를 담당하고, 클라이언트는 서버에 있는 서비스를 이용하는 역할을 담당합니다. 

 

제가 만든 Noise Detector Service(소음 탐지 서비스)의 서버 C언어로 작성되었으며, 이식성을 위해서 디바이스 종속적인 부분(실제 동작을 조작하는 것)은 서비스를 초기화할 때 등록한 콜백 함수를 통해 수행됩니다. 콜백 함수는 개발자가 직접 구현해야하지만, 이 콜백 함수가 받을 수 있는 Event를 해더 파일에 따로 정의해 두었기 때문에, 이 Event에 맞는 동작만 구현하면 됩니다. 따라서 제가 만든 서비스 파일은 노르딕 MCU 뿐만 아니라 TI, Dialog BLE MCU에서도 사용될 수 있으...면 좋겠지만 소프트디바이스에 종속적이라 노르딕 MCU에서만 가능합니다. 물론 BLE 스택 사용 방법만 수정하면 다른 회사의 MCU에 충분히 이식 가능하다고 봅니다. 그래도 이정도면 BLE 설계자들이 목표로 했던 모듈화를 통한 이식과 재개발의 용의성을 반정도는 만족하는 것 같네요. . 참고로 당연하지만 클라이언트는 안드로이드의 Noise Detector 어플리케이션에서 자바로 구현되었습니다. 

 

어차피 테스트이고 매우 간단한 서비스이기 때문에 전 따로 스팩을 문서로 작성하지 않고, 블록 다이어그램정도만 그리고 해당 커스텀 서비스(Custom Service)를 구현했습니다.

Noise Detector Service는 Detected Value Characteristic과 Noise Detector Controlpoint Characteristic 두개의 특성을 포함합니다. UUID라고 불리는 서비스와 특성의 식별자는 다음과 같습니다. UUID 생성기를 사용하여 랜덤이로 생성한 것입니다. 배열로 표현할 때는 오른쪽 끝부터 0번 인덱스입니다. 블루투스 SIG 기본 프로파일은 0000XXXX-0000-1000-8000-00805f9b34fb를 BASE UUID로 하여 12, 13 인덱스만 다른 형태입니다. 제가 만든 Noise Detector Service는 이것들과 구분하기 위해 BASE UUID를 f673XXXX-0994-4967-bdf9-5e7702990a50로 하였고, 코드에서 기본 UUID와 커스텀 UUID가 소프트디바이스 스텍에 어떻게 저장되는지 확인할 수 있습니다.

Noise Detector Service

f6738d00-0994-4967-bdf9-5e7702990a50

Detected Value Characteristic

f6738d01-0994-4967-bdf9-5e7702990a50

Noise Detector Controlpoint Characteristic

f6738d02-0994-4967-bdf9-5e7702990a50

 

Detected Value Characteristic는 탐지된 소음값을 저장합니다.

CCCD 쓰기는 암호화된 연결이 요구됩니다. 값 속성은 최대 20바이트 길이만 가질 수 있고, 읽기/쓰기가 불가능하며, Notification만 될 수 있습니다. nRF51용 소프트디바이스는 블루투스 4.2가 완벽히 구현되지 않았기 때문에 메타 데이터를 제외하면 최대 20바이트까지만 전송될 수 있으며, "패킷 길이 교환" 절차가 제공되지 않습니다. nRF52는 "패킷 길이 교환" 절차가 제공되며 패킷당 200바이트 이상의 데이터를 전송할 수 있다고 알고 있습니다.

 

Noise Detector Controlpoint Characteristic은 소음을 탐지하는 장치에 대한 피어(클라이언트)의 명령과 (서버의)결과에 대한 정보를 저장합니다.

CCCD는 연결 암호화가 요구되지 않지만, 값 속성 쓰기에 대해 암호화된 연결이 요구되며, 값 속성은 쓸 수만 있고 읽을 수는 없습니다. 또한 쓰기 요청은 즉시 수행되지 않고 어플리케이션의 인증이 필요합니다.

값 속성은 2바이트로 구성되며 클라이언트가 2바이트 배열에서 결과값이 저장되는 1번 인덱스를 비우고(0x0:Reserved) 0번 인덱스만 원하는 명령어를 채워 값 속성에 쓰면, 서버는 쓰여진 명령어를 수행하고, nRF51은 수행 결과를 1번 인덱스에 입력하여 이전에 피어에 입력된 0번 인덱스 데이터와 함께 클라이언트에 Indication합니다. 

 

명령과 결과는 다음과 같은 값을 가져야 합니다.

명령 코드

결과 코드

 

서비스가 동작하는 과정은 다음 포스트에서 메세지 시퀀스를 사용하여 설명하겠습니다.