현미경으로 본 BLE(ATTы GATTы…)

현미경으로 본 BLE(ATTы GATTы…)

1부, 개요

블루투스 4.0의 첫 번째 사양이 발표된 지 벌써 꽤 오랜 시간이 흘렀습니다. 그리고 BLE 주제는 매우 흥미롭지만 복잡성으로 인해 여전히 많은 개발자를 방해하고 있습니다. 이전 글에서는 가장 낮은 레벨인 Link Layer와 Physical Layer를 주로 살펴보았습니다. 이를 통해 우리는 속성 프로토콜(ATT) 및 일반 속성 프로필(GATT)과 같은 복잡하고 혼란스러운 개념에 의존할 필요를 피할 수 있었습니다. 그러나 갈 곳이 없으며, 이를 이해하지 못하면 호환 장치를 개발할 수 없습니다. 오늘 저는 이 지식을 여러분과 공유하고 싶습니다. 내 기사에서 나는 의지 할 것입니다 교과서 북유럽 웹사이트의 초보자용. 그럼 시작해 보겠습니다.

왜 모든 것이 그렇게 어렵습니까?

제 생각에는 스마트폰을 통해 장치를 관리하는 것이 매우 유망하고 오래 지속되는 주제라는 것이 즉시 분명해졌습니다. 따라서 그들은 즉시 최대한으로 구조화하기로 결정했습니다. 따라서 다양한 장치 제조업체가 자체 프로토콜을 제시하지 않아 호환되지 않습니다. 따라서 어려움이 있습니다. 이미 첫 번째 단계에서 그들은 가능한 모든 것을 BLE 프로토콜에 집어넣으려고 노력했습니다. 그리고 그것이 나중에 유용할지 여부는 중요하지 않습니다. 또한 향후 장치 목록을 확장할 수 있는 가능성도 제공했습니다.

BLE 프로토콜 다이어그램이 그려진 그림을 살펴보겠습니다. 여러 레이어로 구성됩니다. 가장 낮은 PHY(물리 계층)는 장치의 무선 채널을 담당합니다. 링크 계층(LL)은 전송된 메시지의 전체 바이트 시퀀스를 포함합니다. 이전 기사에서 우리는 이것을 정확히 연구했습니다. 호스트 컨트롤러 인터페이스(HCI)는 컨트롤러와 호스트가 서로 다른 칩에 구현되는 경우 BLE 레이어 또는 칩 간의 교환 프로토콜입니다. L2CAP(Logical Link Control and Adaptation Protocol)는 패킷 형성, 프레이밍, 오류 제어 및 패킷 조립을 담당합니다. SMP(Security Manager Protocol)는 패킷 암호화를 담당합니다. 일반 액세스 프로필(GAP)은 "누가 누구인지"를 결정하기 위해 장치 간의 초기 데이터 교환을 담당합니다. 여기에는 스캐닝 및 광고도 포함됩니다. 이 기사에서는 프로토콜의 나머지 두 부분인 GATT와 ATT에 중점을 둘 것입니다. GATT는 ATT의 상부구조이므로 서로 밀접하게 얽혀 있습니다.

이야기를 단순화하기 위해 비유를 들어보겠습니다. 어디선가 들은 이야기인데 응원하고 싶습니다. BLE 장치를 여러 선반이 있는 책장으로 생각하세요. 각 선반은 별도의 테마입니다. 예를 들어, SF, 수학, 백과사전이 담긴 선반이 있습니다. 각 선반에는 특정 주제의 책이 있습니다. 그리고 일부 책에는 메모가 적힌 종이 책갈피도 있습니다. 또한, 우리는 모든 책이 담긴 작은 종이 카탈로그를 보유하고 있습니다. 기억하신다면 학교 도서관은 종이 카드가 들어 있는 좁은 상자입니다. 이 비유에서 캐비닛은 우리 장치의 프로필입니다. 선반은 서비스이고, 책은 특성이며, 카탈로그는 속성 테이블입니다. 책의 북마크는 설명자이며 나중에 더 자세히 설명하겠습니다.

장치를 개발해 본 사람이라면 많은 프로젝트에 유사한 코드 조각이 있다는 것을 알고 있을 것입니다. 사실 많은 장치가 비슷한 기능을 가지고 있습니다. 예를 들어, 장치가 배터리로 구동되는 경우 충전 및 레벨 모니터링 문제는 동일합니다. 센서도 마찬가지다. 실제로 프로그래밍에 대한 객체 지향 접근 방식은 "속성과 동작을 자체 포함된 공용체로 결합한 후 재사용할 수 있는 객체를 생성하는 기능을 제공합니다.". 제 생각에는 BLE도 비슷한 접근 방식을 시도한 것 같습니다. 프로필은 Bluetooth SIG(Special Interest Group)에서 개발되었습니다. 동일한 프로필을 가진 여러 제조업체의 장치는 서로 어려움 없이 작동해야 합니다. 프로필은 서비스와 설명자로 보완된 특성 서비스로 구성됩니다. 일반적으로 다음과 같습니다.

예를 들어 심박수 모니터(피트니스 팔찌)의 프로필 다이어그램을 생각해 보세요. 두 가지 서비스와 여러 특성으로 구성됩니다. 여기에서 프로필 계층 구조가 즉시 명확해집니다. 체크포인트 특성은 총 칼로리 소비량을 XNUMX으로 재설정합니다.

1. 심박수 서비스에는 세 가지 특성(0x180D)이 포함됩니다.
    a) 필수 심박수 특성(0x2A37)
    b) 옵션 바디 센서 위치 특성 (0x2A38)
    c) 심박수 조절점(0x2A39)의 조건적 특성
2. 배터리 유지관리 서비스(0x180F):
    a) 필수 배터리 충전량 특성(0x2A19)

UUID

프로필 요소(서비스, 특성 및 설명자)에 고유하게 액세스하려면 어떻게든 모든 요소에 번호를 매겨야 합니다. 이를 위해 UUID(Universally Unique ID) 또는 Universally Unique Identifier와 같은 개념이 도입되었습니다. UUID는 각 줄의 괄호 안에 표시됩니다. 그리고 여기에는 한 가지 특이한 점이 있습니다. UUID의 경우 길이가 16비트와 128비트인 코드를 사용하기로 결정했습니다. 왜요? BLE 프로토콜에서는 모든 것이 에너지 보존에 관한 것입니다. 따라서 16비트 크기는 상당히 합리적입니다. 가까운 장래에 65개 이상이 생성될 가능성은 거의 없습니다. 독특한 서비스와 특징. 현재로서는 그들이 계산할 수 있는 모든 것이 이미 계산되어 있습니다(이 말이 어디서 왔는지 기억하세요 - "그는 당신도 계산했습니다" :-)) 번호가 매겨진 요소 프로필, 서비스, 특성 и 설명자 링크를 볼 수 있습니다.

하지만 인터넷상의 4바이트 IP 주소에 관한 이야기는 다들 기억하실 것 같습니다. 처음에는 충분하다고 생각했지만 지금은 여전히 ​​6바이트 주소로 전환할 수 없습니다. 이러한 실수를 반복하지 않고 DIYer의 장난스러운 손길을 자유롭게 하기 위해 SIG는 즉시 128비트 UUID를 도입하기로 결정했습니다. 이것은 개인적으로 라디오 채널에서 모든 종류의 Kulibins에게 제공되었던 무면허 433MHz 대역을 생각나게 합니다. 우리의 경우 서비스 및 특성에 대한 128비트 식별자가 생성되었습니다. 이는 서비스와 장치에 대해 거의 모든 128비트 값을 사용할 수 있음을 의미합니다. 마찬가지로, 동일한 UUID가 나올 확률은 XNUMX이 되는 경향이 있습니다.

실제로 짧은 16비트 UUID는 128비트 값으로 확장됩니다. 사양에서 이 확장은 Bluetooth Base UUID라고 하며 값은 00000000-0000-1000-8000-00805F9B34FB입니다. 예를 들어, 16비트 속성 UUID의 값이 0x1234인 경우 해당 128비트 UUID의 값은 00001234-0000-1000-8000-00805F9B34FB입니다. 그리고 해당 공식도 제공됩니다.

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

이 마법의 숫자가 어디서 왔는지 모르겠습니다. 독자 중 아는 사람이 있으면 댓글에 적어주세요. (Sinopteek라는 닉네임을 가진 사용자가 이미 이 작업을 수행했습니다. 댓글을 참조하세요.) 128비트 UUID를 만들려면 원칙적으로 특수한 UUID를 사용할 수 있습니다. 발전기에 의한누가 당신을 위해 그것을 할 것입니다.

아티 가티...

실제로 재미가 시작됩니다. ATT는 클라이언트-서버 관계를 기반으로 한다는 점을 상기시켜 드리겠습니다. 이제 우리는 서버 장치를 살펴보겠습니다. 여기에는 센서 값, 전등 스위치 상태, 위치 데이터 등과 같은 정보가 포함됩니다. 이제 모든 "퍼레이드 참가자"의 번호가 매겨졌으므로 어떻게든 그들을 장치의 메모리에 저장해야 합니다. 이를 위해 속성 테이블이라는 테이블에 넣습니다. 이것을 잘 기억하세요. 이것이 바로 BLE의 핵심입니다. 이것이 우리가 더 고려할 것입니다. 이제 각 줄을 속성이라고 부르겠습니다. 이 테이블은 스택 깊숙한 곳에 위치하며 일반적으로 직접 액세스할 수 없습니다. 우리는 그것을 초기화하고 접근하지만, 내부에서 일어나는 일은 일곱 개의 봉인 뒤에 숨겨져 있습니다.

사양의 그림을 살펴보겠지만, 그 전에 용어, 즉 설명자에서 자주 혼동되는 부분에 대해 즉시 주목하고 싶습니다. 설명자의 역할은 특성 설명을 보완하는 것입니다. 기능을 확장해야 할 경우 설명자가 사용됩니다. 또한 속성이기도 하며 서비스 및 특성과 마찬가지로 속성 테이블에 위치합니다. 기사의 두 번째 부분에서 자세히 살펴보겠습니다. 그러나 때로는 설명자가 속성 테이블의 행 번호를 참조하는 경우도 있습니다. 이 점을 명심해야 합니다. 혼란을 피하기 위해 이러한 목적으로 "속성 포인터"라는 용어를 사용합니다.


따라서 속성은 다음과 같은 속성이 연관된 개별 값입니다.
1. 속성 핸들은 속성에 해당하는 테이블 인덱스입니다.
2. 속성 유형은 해당 유형을 설명하는 UUID입니다.
3. 속성 값은 속성 포인터에 의해 색인화된 데이터입니다.
4. 속성 권한은 속성 프로토콜을 사용하여 읽거나 쓸 수 없는 속성, 즉 권한의 일부입니다.

이 모든 것을 어떻게 이해합니까? 속성 포인터는 상대적으로 우리 테이블의 번호입니다.
이를 통해 클라이언트는 읽기 또는 쓰기 요청에서 속성을 참조할 수 있습니다. 0x0001부터 0xFFFF까지 행(속성) 번호를 매길 수 있습니다. 책장과 관련하여 이것은 종이 카탈로그의 카드 번호입니다. 마찬가지로 도서관 목록과 마찬가지로 카드는 숫자가 많은 순서대로 배열됩니다. 각 후속 라인의 번호는 이전 라인보다 커야 합니다. 도서관과 마찬가지로 일부 카드가 분실되는 경우가 있기 때문에 우리의 경우 줄 번호에 공백이 있을 수 있습니다. 이는 허용됩니다. 가장 중요한 것은 점진적으로 진행된다는 것입니다.

속성 유형은 속성이 나타내는 내용을 결정합니다. C언어와 비유하자면,
부울, 숫자 변수 및 문자열이 있는 곳에 있으므로 여기에 있습니다. 우리가 인식하는 속성 유형으로
우리가 다루고 있는 것이 무엇인지, 이 속성을 어떻게 계속해서 활용할 수 있는지. 아래에서는 몇 가지 특정 유형의 속성을 살펴보겠습니다. 예를 들어 "서비스 선언"(0x2800), "특성 선언"(0x2803), "설명자 선언"(0x2902)입니다.

속성의 값은 실제 의미입니다. 동어반복을 용서하세요. 속성 유형이 문자열인 경우 속성 값은 예를 들어 "Hello World !!!"라는 슬로건일 수 있습니다. 속성 유형이 "서비스 선언"인 경우 해당 값은 서비스 자체입니다. 때로는 다른 속성과 해당 속성을 찾을 수 있는 위치에 대한 정보이기도 합니다.

속성 권한을 통해 서버는 읽기 또는 쓰기 액세스가 허용되는지 여부를 이해할 수 있습니다.
이러한 권한은 속성 값에만 적용되며 포인터, 유형 또는 권한 필드 자체에는 적용되지 않습니다. 저것들. 속성 기록이 허용되면 예를 들어 "Hello World !!!" 줄을 변경할 수 있습니다. "좋은 아침"이라는 줄에. 그러나 새로운 라인을 작성하는 것을 금지하거나 속성 유형을 변경하고 해당 라인을 “서비스 선언”으로 지정할 수는 없습니다. 클라이언트가 서버에 접속하면 클라이언트는 해당 속성을 요청합니다. 이를 통해 클라이언트는 서버가 무엇을 제공할 수 있는지 알 수 있습니다. 값을 읽고 쓸 필요는 없지만.

어떻게 보이는지

GATT의 개념은 속성 테이블의 속성을 매우 구체적이고 논리적인 순서로 그룹화하는 것입니다. 아래에서 심박수 프로필을 자세히 살펴보겠습니다. 이 테이블의 가장 왼쪽 열은 선택 사항입니다. 이는 단순히 이 행(속성)이 무엇인지 설명합니다. 다른 모든 열은 이미 우리에게 친숙합니다.

각 그룹의 상단에는 항상 서비스 선언 속성이 있습니다. 해당 유형은 항상 0x2800이며 포인터는 테이블에 이미 존재하는 속성 수에 따라 달라집니다. 해당 권한은 인증이나 승인 없이 항상 읽기 전용입니다. 이 개념에 대해서는 나중에 조금 이야기하겠습니다. 값은 서비스가 무엇인지 식별하는 또 다른 UUID입니다. 표에서 값은 0x180D로 Bluetooth SIG에서 심박수 서비스로 정의한 값입니다.

서비스 발표에 이어 특성 발표가 이어집니다. 서비스 선언과 형식이 유사합니다. UUID는 항상 0x2803이고 권한은 인증이나 권한 부여 없이 항상 읽기 전용입니다. 일부 데이터가 포함된 속성 값 필드를 살펴보겠습니다. 여기에는 항상 포인터, UUID 및 속성 집합이 포함됩니다. 이 세 가지 요소는 특성 값의 후속 선언을 설명합니다. 포인터는 자연스럽게 속성 테이블에서 특성 값 선언의 위치를 ​​나타냅니다. UUID는 우리가 기대할 수 있는 정보나 가치의 유형을 설명합니다. 예를 들어 온도 값, 전등 스위치 상태 또는 기타 임의 값이 있습니다. 마지막으로 특성 값이 상호 작용할 수 있는 방법을 설명하는 속성입니다.

여기서 또 다른 함정이 우리를 기다리고 있습니다. 이는 속성 권한 및 특성 속성과 연결됩니다. 사양의 비트 필드 속성에 대한 그림을 살펴보겠습니다.

보시다시피 여기에는 읽기 및 쓰기 기능을 제공하는 필드도 있습니다. 속성 및 속성에 대한 읽기/쓰기 권한이 있는 이유가 궁금할 수 있습니다.
특성값에 대한 읽기/쓰기? 항상 동일해야 하지 않나요? 사실 특성 값의 속성은 실제로 GATT 및 애플리케이션 계층에서 사용되는 클라이언트에 대한 권장 사항일 뿐입니다. 이는 클라이언트가 특성 선언 속성에서 무엇을 기대할 수 있는지에 대한 단순한 힌트입니다. 이에 대해 좀 더 자세히 살펴보겠습니다. 속성에는 어떤 유형의 권한이 있습니까?

1. 접근 권한:
     - 독서
     - 기록
     - 읽고 쓰기
2. 인증 권한:
     - 인증 필요
     - 인증이 필요하지 않습니다
3. 승인 권한:
     — 승인이 필요합니다
     - 승인이 필요하지 않습니다

속성 확인과 특성 속성의 주요 차이점은 전자는 서버에 적용되고 후자는 클라이언트에 적용된다는 것입니다. 서버는 특성 값을 읽는 것이 허용될 수 있지만 인증이나 권한 부여가 필요할 수 있습니다. 따라서 클라이언트가 특성의 속성을 요청하면 읽기가 허용된다는 메시지를 받게 됩니다. 하지만 읽으려고 하면 오류가 발생합니다. 따라서 속성보다 권한의 우선 순위에 대해 안전하게 이야기할 수 있습니다. 클라이언트 측에서는 속성에 어떤 권한이 있는지 알 수 없습니다.

설명자

우리 테이블로 돌아가자. 특성 값을 선언한 후 다음과 같은 속성 선언이 가능합니다.
1. 새로운 특성 선언(서비스는 많은 특성을 가질 수 있음)
2. 신규 서비스 선언(표에 다수가 있을 수 있음)
3. 핸들 선언

심박수 측정 특성의 경우, 본 표에서는 특성값 선언과 함께 디스크립터 선언을 동반합니다. 설명자는 특성에 대한 추가 정보가 포함된 속성입니다. 설명자에는 여러 유형이 있습니다. 이 기사의 두 번째 부분에서 이에 대해 자세히 설명하겠습니다. 지금은 CCCD(클라이언트 특성 구성 설명자)만 다루겠습니다. UUID는 0x2902입니다. 이 설명자를 사용하여 클라이언트는 서버에서 표시 또는 알림을 활성화할 수 있습니다. 그들 사이의 차이는 작지만 여전히 존재합니다. 통지에는 클라이언트의 수신 확인이 필요하지 않습니다. 표시에는 이것이 필요하지만 GATT 수준에서 발생하지만 적용 수준에는 도달하지 않습니다. 왜 그렇습니까? 아아, 나는 이것을 모른다. 북유럽 전문가들은 알림 사용을 권장한다고 말씀드리고 싶습니다. 또한 두 경우 모두 패키지 무결성 검사(CRC 사용)가 발생합니다.

결론

글을 마치며 이렇게 말하고 싶습니다. 마지막 표는 약간 혼란스럽습니다. 하지만, 에서 제공되기 때문에 선택했습니다. 기사, 내가 의존하는 것입니다. 내 기사의 두 번째 부분에서는 BlueTooth 4.0 사양에 대해 더 자세히 살펴보겠습니다. 더 정확한 다이어그램과 그림이 우리를 기다리고 있습니다. 세 번째 부분에서는 가젯 중 하나에서 Wireshark 프로그램을 사용하여 얻은 로그를 분석하고 우리가 연구 중인 모든 이론을 "실시간"으로 확인하고 싶습니다.

그룹사 직원 "카이사르 위성"
페체르스키크 블라디미르

출처 : habr.com