[nRF52BLE][3]Components for Data Transfer

3) Components for Data Transfer

Attribute Protocol (ATT) 에 대하여

이전에 간략히 보았던 것처럼 프로토콜을 완성시키기 위하여 몇 가지 Layer가 쌓여 있다. 어플리케이션은 GATT를 이용해 생성할 수 있고 GATT 는 ATT 의 상위에 위치한다.

 

ATT는 Client ←→ Server 관계에 기반을 둔다. 서버는 센서의 값과 같은 정보를 갖고 있고, 이 정보는 table에 정리되어 있다. 이를 Attribute Table 이라 한다. Table의 각 Attribute는 여러 속성(Property)으로 연관되어 있다.

 

예를 들어 설명하겠습니다. 아래에는 1개의 Table이 있는데, 각 Row는 각 Attribute 를 뜻한다. 각 Attribute는 handle, type, set of permissions 그리고 value 를 가지고 있다.

 

Attribute Handle

클라이언트가 Read / Write request 시 Attribute 를 가리킬 수 있게끔 서버에서의 Attribute의 고유 값을 가진다.

Attribute Types (UUIDs)

Attribute의 종류를 나타낼 때 UUID로 표현한다 .

Attribute Permissions :

디바이스가 특정 Attribute와 어떻게 통신할 것인지를 정의한다. Attribute 가 read 만 가능한지, read/write 둘 다 가능한지 등등 ..

Attribute Values :

어떤 값이든 가지고 있을 수 있다. 예를 들어,

• heart rate value measured per minute
• Service Declaration value → UUID value : 어떤 서비스인지를 알림 [Row 0]
• Characteristic Declaration value → Characteristic Value Declaration (Properties, Handle Type) [Row 4]
• Heart Rate Measurement Characteristic Value → 센서에서 나온 값

 

Generic Attribute Profile (GATT) 에 대하여

Attribute를 모아 가장 논리적인 순서와 계층으로 분류한다. 다르게 말해, BLE를 이용하여 데이터를 꾸리고 보내는 방식을 효율적으로 결정하는 구조이다. 이 구조에서 사용하는 하위 구조로는 Service 와 Characteristic이 있다.

 

Service

하나의 기능을 만들기 위한 데이터와 행동 규칙들의 집합. 1개의 Service는 단일, 또는 다중 Characteristics을 포함할 수 있다. e.g.,Heart Rate Service. Heart Rate Service 와 같은 서비스들이 지켜야 할 표준을 만들어 펌웨어 및 앱의 호환을 돕기 위해 Bluetooth Special Interest Group (Bluetooth SIG) 가 이와 같이 설계하였다고 한다. 원한다면 Custom Bluetooth Service Definition을 직접 만들수도 있음.

---

Service Declaration Attribute

type: 0x2800 = Standard UUID For Service Declarations

 

Handle은 Attribute가 Table에 얼마나 있는지에 따라 달라진다. authentication/authorization 필요 없이 Permission은 항상 Read Only.

 

Value: Heart Rate Service를 지칭하는 UUID

---

Characteristics

실제로 보내고자(받고자) 하는 정보(값).

---

Characteristic Declaration Attribute

type: 0x2803 = Standard UUID For Characteristic Declarations

Handle: Read Only without authentification / authorization.

Value: 다음 세 가지를 포함한다:

• Handle : Attribute Table의 Characteristic Value Declaration(CVD)을 가리킴.
• UUID : CVD에서 어떤 값을 기대할 수 있는지를 알림.
• Properties : Ch. Value 와 어떻게 상호작용할 수 있는지를 나타냄.

아래는 Property Bit Field를 보여준다.

 

이미 Read/Write는 Permission에서 설정하였지만 Property 를 통해 다시 한 번 알려야 하는 이유는 Characteristic Value를 통해 클라이언트에 가이드라인을 주기 위함이다. Bluetooth Core Specification에서 명령하는 부분이기 때문에 어쩔 수 없이 따라야 한다.

---

Descriptor Declaration

Table에서 CVD 이후의 순서는 다음 중 하나가 될 수 있는데,

 

a. 다른 Characteristic Declaration (하나의 서비스 안에 다수의 Characteristic 포함 가능)

b. 다른 Service Declaration (하나의 Table 안에 다수의 Service 포함 가능)

c. Descriptor Declaration ( Characteristic에 대한 추가적인 Attribute)

 

대표적으로는 Client Characteristic Configuration Descriptor (CCCD)가 있다.

 

센서의 데이터를 얻는다면 데이터를 '푸시' 할 필요가 있을것이다. 그럼 이것이 Bluetooth에서 어떻게 이루어지는지 알 필요가 있다. Bluetooth Core Specification(BCS) 에 의하면 데이터를 푸시하는 방법에는 두 가지가 있다고 한다.

 

i) Indication - 업데이트된 정보를 송신한 이후 매번 다른 기기가 acknowledgement 하는 과정을 거쳐야 함.

ii) Notification - 반대편의 기기가 acknowledgement를 하건 말건 신경쓰지 않고 데이터를 송신.

 

Notification 기능을 활용하기 위해서는 attribute table에 Descriptor를 추가해야 하는데 이것이 CCCD이다. BCS에 의하면 CCCD는 클라이언트가 nRF Device (development kit)의 Notification 또는 Indication을 활성화시키거나 비활성화 시킬 수 있게끔 한다고 한다.

---

 

이전 포스팅에서 보았던 것처럼 Heirarchy 를 정리해보면

 

 

이렇게 보여질 수 있다. 이 방식은 유연성, 효율성, 플랫폼 간 호환성, 적용의 수월함 때문에 활용되고 있다. Heart Rate Service 를 가지는Device를 찾게 된다면 적어도 Heart Rate Measurement Characteristic 은 있어야 함을 기대할 수 있다.

 

UUID (Universally Unique ID): Service, Characteristic, Descriptor를 구분짓는 고유한 숫자. Hex 값으로 주로 나타낸다. 이전 포스팅에서 말씀드렸듯, 16bit 과 128bit UUID 가 존재한다.

 

Vendor-specific UUID로 알려져있는 128bit UUID는 직접 Service 와 Characteristics를 만들어야 할 때 사용함. Base UUID는 다음과 같이 생겼다.

 

4A98xxxx-1CC4-E7C1-C757-F1267DD021E8

 

x는 16 bit predefined UUID처럼 미리 만들어 대입한다. 메모리에서 Base UUID를 저장하고, 평소처럼 16 bit ID 만을 사용하면 된다. Base UUID는 nRFGo 프로그램을 사용하여 만들 수 있다.