Attribute and Data Hierarchy
특성 및 데이터 계층 구조
Although the Bluetooth specification defines attributes in the ATT section, that is as far as ATT goes when it comes to them.
Bluetooth 사양은 ATT 섹션의 특성을 정의하지만 ATT에 관한 한 이는 ATT에 관한 것입니다.
ATT operates in attribute terms and relies on all the concepts exposed in “Attributes” on page 53 to provide a series of precise protocol data units (PDUs, commonly known as packets) that permit a client to access the attributes on a server.
ATT는 속성 용어로 작동하며 53페이지의 "속성"에 노출된 모든 개념을 활용하여 클라이언트가 서버의 속성에 액세스할 수 있도록 하는 일련의 정확한 프로토콜 데이터 단위(PDU, 일반적으로 패킷이라고 함)를 제공합니다.
GATT goes further to establish a strict hierarchy to organize attributes in a reusable and practical manner, allowing the access and retrieval of information between client and server to follow a concise set of rules that together constitute the framework used by all GATT-based profiles.
GATT는 속성을 재사용 가능하고 실용적인 방식으로 구성하기 위한 엄격한 계층 구조를 확립하여 클라이언트와 서버 간의 정보 액세스 및 검색이 간결한 규칙 집합을 따를 수 있도록 합니다. 이러한 규칙은 모든 GATT 기반 프로필에서 사용되는 프레임워크를 구성합니다.
Figure 4-1 illustrates the data hierarchy introduced by GATT.
그림 4-1은 GATT가 도입한 데이터 계층 구조를 보여줍니다.
The attributes in a GATT server are grouped into services, each of which can contain zero or more characteristics.
GATT 서버의 속성은 서비스로 그룹화되며 각 서비스에는 0개 이상의 특성이 포함될 수 있습니다.
These characteristics, in turn, can include zero or more descriptors.
이러한 특성에는 0개 이상의 설명자가 포함될 수 있습니다.
This hierarchy is strictly enforced for any device claiming GATT compatibility (essentially, all BLE devices sold), which means that all attributes in a GATT server are included in one of these three categories, with no exceptions.
이 계층 구조는 GATT 호환성을 주장하는 모든 장치 (기본적으로 판매된 모든 BLE 장치)에 대해 엄격하게 적용됩니다. 즉, GATT 서버의 모든 속성은 예외 없이 이 세 가지 범주 중 하나에 포함됩니다.
No dangling attributes can live outside of this hierarchy, as exchanging data between BLE devices depends on it.
BLE 장치 간 데이터 교환이 이에 의존하므로 이 계층 외부에는 매달린 속성이 존재할 수 없습니다.
For most types of data in the GATT hierarchy, it is important to differentiate between their definition (the whole group of attributes that make it up) and the declaration.
GATT 계층 구조에 있는 대부분의 데이터 유형의 경우 정의 (구성하는 전체 속성 그룹)와 선언을 구별하는 것이 중요합니다.
The declaration is a single attribute that is always placed first (in increasing handle order) within the definition and that introduces most of the metadata about the data that follows.
선언은 정의 내에서 항상 첫 번째 (핸들 순서 증가)에 배치되고 뒤따르는 데이터에 대한 대부분의 메타데이터를 소개하는 단일 속성입니다.
All declarations have read-only permissions with no security required, because they cannot contain sensitive data.
모든 선언에는 민감한 데이터를 포함할 수 없으므로 보안이 필요하지 않은 읽기 전용 권한이 있습니다.
They are only structural attributes that allow the client to find out and discover the layout and nature of the attributes on the server.
이는 클라이언트가 서버에 있는 속성의 레이아웃과 특성을 찾아 발견할 수 있도록 하는 구조적 속성일 뿐입니다.
Attribute and Data Hierarchy services group conceptually related attributes in one common section of the attribute information set in the GATT server.
속성 및 데이터 계층 서비스는 GATT 서버에 설정된 속성 정보의 하나의 공통 섹션에 개념적으로 관련된 속성을 그룹화합니다.
The specification refers to all the attributes within a single service as the service definition.
사양에서는 단일 서비스 내의 모든 속성을 서비스 정의로 참조합니다.
Therefore, a GATT server’s attributes are in fact a succession of service definitions, each one starting with a single attribute that marks the beginning of a service (aptly named a service declaration.)
따라서 GATT 서버의 속성은 실제로 일련의 서비스 정의이며, 각 정의는 서비스의 시작을 표시하는 단일 속성 (서비스 선언이라는 이름이 적절함)으로 시작됩니다.
This attribute’s type and value format is strictly specified in GATT, as shown in Table 4-2.
이 속성의 유형과 값 형식은 표 4-2에 표시된 것처럼 GATT에 엄격하게 지정되어 있습니다.
In the declaration shown in Table 4-2, UUID primary service (0x2800) and UUID secondary service (0x2801) refer to standard, SIG-assigned UUIDs that are used as the exclusive type to introduce a service.
표 4-2의 선언에서 UUID 기본 서비스 (0x2800)와 UUID 보조 서비스 (0x2801)는 서비스 도입을 위해 전용 타입으로 사용되는 표준 SIG 할당 UUID를 의미합니다.
They are naturally 16-bit UUIDs (because they are fundamental ones defined by the specification).
이는 기본적으로 16비트 UUID입니다 (사양에서 정의한 기본 UUID이기 때문입니다).
The difference between primary and secondary services is important to note.
1차 서비스와 2차 서비스의 차이를 알아두는 것이 중요합니다.
A primary service is the standard type of GATT service that includes relevant, standard function‐ ality exposed by the GATT server.
기본 서비스는 GATT 서버에 의해 노출되는 관련 표준 기능을 포함하는 표준 유형의 GATT 서비스입니다.
A secondary service, on the other hand, is intended to be included only in other primary services and makes sense only as its modifier, having no real meaning on its own.
반면에 보조 서비스는 다른 기본 서비스에만 포함되도록 의도되었으며 수정자로서만 의미가 있으며 그 자체로는 실제 의미가 없습니다.
In practice, secondary services are rarely used.
실제로 보조 서비스는 거의 사용되지 않습니다.
The value of the service declaration attribute itself contains a UUID (as mentioned in “Value” on page 55, the value of an attribute can be any data type), this time corresponding to the UUID of the actual service that this declaration introduces.
서비스 선언 속성 자체의 값에는 UUID가 포함되어 있습니다 (55페이지의 "값"에서 언급했듯이 속성의 값은 모든 데이터 유형이 될 수 있음). 이번에는 이 선언이 도입하는 실제 서비스의 UUID에 해당합니다.
Although the service declaration must always be the first attribute of the service, many others can follow it before the next service declaration, usually in the form of characteristics and descriptors.
서비스 선언은 항상 서비스의 첫 번째 속성이어야 하지만, 다음 서비스 선언 앞에 다른 속성이 올 수도 있는데, 일반적으로 특성과 설명자의 형태로 나타납니다.
Conceptually, you could think of a GATT service as a class in any modern object oriented language, complete with instantiation, because a service can be instantiated multiple times within a single GATT server (however, this is not a common occurrence and most services would therefore be akin to singletons).
개념적으로, GATT 서비스는 인스턴스화가 포함된 최신 객체 지향 언어의 클래스로 생각할 수 있습니다. 서비스는 단일 GATT 서버 내에서 여러 번 인스턴스화될 수 있기 때문입니다 (그러나 이는 흔히 있는 일이 아니며 대부분의 서비스는 싱글톤과 유사합니다).
Inside a service definition (that is to say, inside a service), you can add one or more references to another services, using include definitions.
서비스 정의 내부 (즉, 서비스 내부)에서는 포함 정의를 사용하여 다른 서비스에 대한 하나 이상의 참조를 추가할 수 있습니다.
Include definitions consist of a single attribute (the include declaration) that contains all the details required for the client to reference the included service.
Include/포함 정의는 클라이언트가 포함된 서비스를 참조하는 데 필요한 모든 세부 정보를 포함하는 단일 속성 (포함 선언)으로 구성됩니다.
Included services can help avoid duplicating data in a GATT server.
포함된 서비스는 GATT 서버에서 데이터 중복을 방지하는 데 도움이 될 수 있습니다.
If a service will be referenced by other services, you can use this mechanism to save memory and simplify the layout of the GATT server.
서비스가 다른 서비스에서 참조되는 경우 이 메커니즘을 사용하여 메모리를 절약하고 GATT 서버의 레이아웃을 단순화할 수 있습니다.
In the previous analogy with classes and objects, you could see include definitions as pointers or references to an existing object instance.
클래스 및 객체에 대한 이전 비유에서는 기존 체 인스턴스에 대한 포인터 또는 참조로 포함 정의를 볼 수 있습니다.
Table 4-3 shows the include declaration attribute with all its fields.
표 4-3은 모든 필드와 함께 포함 선언 속성을 보여줍니다.
Again, the UUID include (0x2802) is a special SIG-assigned UUID used exclusively in include declarations, and the value field in this case contains both the start and end handles of the include service, as well as its UUID.
다시 말하지만, UUID include (0x2802)는 include 선언에만 사용되는 특수 SIG 할당 UUID이며 이 경우 값 필드에는 UUID뿐만 아니라 include 서비스의 시작 및 끝 핸들도 포함됩니다.
You can understand characteristics as containers for user data.
사용자 데이터의 컨테이너로서의 특성을 이해할 수 있습니다.
Containers always include at least two attributes: the characteristic declaration (which provides metadata about the actual user data) and the characteristic value (which is a full attribute that contains the user data in its value field).
컨테이너에는 항상 최소한 두 개의 속성이 포함됩니다. 특성 선언(실제 사용자 데이터에 대한 메타데이터를 제공함)과 특성 값(값 필드에 사용자 데이터가 포함된 전체 속성)입니다.
Additionally, the characteristic value can be followed by descriptors, which further expand on the metadata contained in the characteristic declaration.
또한 특성 값 뒤에는 특성 선언에 포함된 메타데이터를 더욱 확장하는 설명자가 올 수 있습니다.
The declaration, value, and any descriptors together form the characteristic definition, which is the bundle of attributes that make up a single characteristic.
선언, 값 및 모든 설명자가 함께 단일 특성을 구성하는 특성 묶음인 특성 정의를 형성합니다.
Table 4-4 shows the structure of the first two attributes of every single characteristic.
표 4-4는 모든 단일 특성의 처음 두 속성의 구조를 보여줍니다.
All GATT characteristics are always part of a service, and can therefore always be found enclosed in one.
모든 GATT 특성은 항상 서비스의 일부이므로 항상 서비스 하나로 묶일 수 있습니다.
Characteristic declaration attribute
특성 선언 속성
Once again, the characteristic declaration attribute’s type UUID (0x2803) is a standardized, unique UUID used exclusively to denote the beginning of characteristics.
다시 한 번 말씀드리지만, 특성 선언 속성의 유형 UUID(0x2803)는 특성의 시작을 나타내는 데만 사용되는 표준화된 고유 UUID입니다.
As with all other declarations (such as service and include), this attribute has read-only permissions, because clients are allowed only to retrieve its value but in no case modify it.
다른 모든 선언 (예: 서비스 및 포함)과 마찬가지로 이 속성에는 읽기 전용 권한이 있습니다. 클라이언트는 해당 값을 검색만 할 수 있고 어떠한 경우에도 수정할 수 없기 때문입니다.
Table 4-5 lists the different items concatenated within the characteristic declaration’s attribute value.
표 4-5에는 특성 선언의 속성 값 내에 연결된 다양한 항목이 나열되어 있습니다.
These three fields are contained in a characteristic declaration attribute value:
다음 세 필드는 특성 선언 속성 값에 포함되어 있습니다:
This 8-bit bitfield, along with the additional two bits in the extended properties descriptor (discussed in “Extended Properties Descriptor” on page 62), contains the operations and procedures that can be used with this characteristic.
이 8비트 비트 필드는 확장 속성 설명자의 추가 2비트 (62페이지의 "확장 속성 설명자"에서 설명)와 함께 이 특성과 함께 사용할 수 있는 작업 및 절차를 포함합니다.
Each of those 10 properties is encoded as a single bit on the bit field shown in Table 4-6.
이러한 10개 속성 각각은 표 4-6에 표시된 비트 필드의 단일 비트로 인코딩됩니다.
The client can read those properties to find out which operations it is allowed to perform on the characteristic.
클라이언트는 이러한 속성을 읽어서 특성에 대해 어떤 작업을 수행할 수 있는지 알아낼 수 있습니다.
This is particularly important for the Notify and Indicate properties, because these operations are initiated by the server (further detailed in “Server Initiated Updates” on page 72) but require the client to enable them first by using the descriptor described in “Client Characteristic Configuration Descriptor” on page 62.
이것은 Notify 및 Indicate 속성에 특히 중요합니다. 이러한 작업은 서버에서 시작되기 때문입니다 (72페이지의 "서버에서 시작한 업데이트"에서 자세히 설명). 그러나 클라이언트가 62페이지의 "클라이언트 특성 구성 설명자"에 설명된 설명자를 사용하여 먼저 이를 활성화해야 합니다.
Characteristic Value Handle
특성 값 핸들
These two bytes contain the attribute handle of the attribute that contains the actual value of the characteristic.
이 두 바이트에는 특성의 실제 값이 포함된 특성의 특성 핸들이 포함됩니다.
Although it’s often the case, you should never assume that this handle will be contiguous (i.e., 0xNNNN+1) to the one containing the declaration.
종종 있는 일이지만 이 핸들이 선언을 포함하는 핸들과 연속적 (예: 0xNNNN+1)일 것이라고 가정해서는 안 됩니다.
The UUID of the particular characteristic, this can be either a SIG-approved UUID (when making use of the dozens of characteristic types included in the standard profiles) or a 128-bit vendor specific UUID otherwise.
특정한 특성의 UUID는 SIG 승인 UUID (표준 프로필에 포함된 수십 가지 특성 유형을 사용하는 경우)이거나 그렇지 않은 경우 128비트 공급업체별 UUID일 수 있습니다.
Continuing with the class and object-orientation analogy, characteristics are like individual fields or properties in that class, and a profile is like an application that makes use of one or more classes for a specific need or purpose.
클래스 및 객체 지향 비유를 계속하면 특성은 해당 클래스의 개별 필드 또는 속성과 같으며 프로필은 특정 요구 사항이나 목적을 위해 하나 이상의 클래스를 사용하는 애플리케이션과 같습니다.
Finally, the characteristic value attribute contains the actual user data that the client can read from and write to for practical information exchanges.
마지막으로 특성 값 속성에는 클라이언트가 실제 정보 교환을 위해 읽고 쓸 수 있는 실제 사용자 데이터가 포함됩니다.
The type for this attribute is always the same UUID found in the characteristic’s declaration value field (as shown in “Characteristic declaration attribute” on page 59).
이 속성의 유형은 항상 특성의 선언 값 필드에서 발견되는 동일한 UUID입니다 (59페이지의 "특성 선언 속성" 참조).
So, characteristic value attributes no longer have types of services or characteristics, but rather concrete, specific UUIDs that can refer to a sensor’s reading or a keypress on a keyboard.
따라서 특성 값 속성에는 더 이상 서비스나 특성 유형이 없으며 센서 판독이나 키보드 키 누르기를 참조할 수 있는 구체적이고 특정 UUID가 있습니다.
The value of a characteristic value attribute can contain any type of data imaginable, from temperatures in celsius to key scan codes to display strings to speeds in miles per hour—anything that can be usefully transmitted over two BLE devices can fill in the contents of that value.
특성 값 속성의 값에는 섭씨 온도부터 주요 스캔 코드, 표시 문자열, 시간당 마일 단위의 속도까지 상상할 수 있는 모든 유형의 데이터가 포함될 수 있습니다. 두 개의 BLE 장치를 통해 유용하게 전송할 수 있는 모든 데이터는 해당 값의 내용을 입력합니다.
GATT characteristic descriptors (commonly called simply descriptors) are mostly used to provide the client with metadata (additional information about the characteristic and its value).
GATT 특성 설명자 (일반적으로 간단히 설명자라고 함)는 클라이언트에 메타데이터 (특성 및 해당 값에 대한 추가 정보)를 제공하는 데 주로 사용됩니다.
They are always placed within the characteristic definition and after the characteristic value attribute.
이는 항상 특성 정의 내 및 특성 값 속성 뒤에 배치됩니다.
Descriptors are always made of a single attribute, the characteristic descriptor declaration, whose UUID is always the descriptor type and whose value contains whatever is defined by that particular descriptor type.
설명자는 항상 단일 속성, 특성 설명자 선언으로 구성됩니다. 이 속성의 UUID는 항상 설명자 유형이고 해당 값에는 해당 특정 설명자 유형에 의해 정의된 모든 항목이 포함됩니다.
You can find two types of descriptors in the different GATT characteristics:
서로 다른 GATT 특성에서 두 가지 유형의 설명자를 찾을 수 있습니다:
GATT-defined descriptors
GATT 정의 설명자
These are the fundamental, widely used descriptor types that simply add meta information about the characteristic.
이는 단순히 특성에 대한 메타 정보를 추가하는 기본적이고 널리 사용되는 설명자 유형입니다.
The following sections describe the most common ones.
다음 섹션에서는 가장 일반적인 섹션을 설명합니다.
Profile or vendor-defined descriptors
프로필 또는 공급업체 정의 설명자
Regardless of whether a profile is specified and published by the SIG or by a particular vendor, these descriptors can contain all types of data, including additional information regarding the characteristic value, such as the encoding used to acquire the value from a sensor or any other particulars that complement the reading itself.
프로파일이 SIG 또는 특정 공급업체에서 지정 및 게시되었는지 여부에 관계없이 이러한 설명자는 센서에서 값을 수집하는 데 사용된 인코딩이나 판독 자체를 보완하는 기타 세부 정보와 같은 특성 값에 대한 추가 정보를 포함하여 모든 유형의 데이터를 포함할 수 있습니다.
The following sections describe some of the most commonly used descriptors defined by GATT.
다음 섹션에서는 GATT에서 정의한 가장 일반적으로 사용되는 설명어 중 일부를 설명합니다.
Extended Properties Descriptor
확장 속성 설명자
This descriptor, when present, simply contains the two additional property bits, covered in “Characteristic declaration attribute” on page 59 and listed in Table 4-6.
이 설명자는 존재하는 경우 59페이지의 "특성 선언 속성"에 포함되어 표 4-6에 나열된 두 개의 추가 속성 비트를 포함합니다.
Characteristic User Description Descriptor
특성 사용자 설명 설명자
As the name implies, this descriptor contains a user-readable description for the characteristic within which it is placed.
이름에서 알 수 있듯이, 이 설명자에는 해당 설명자가 배치된 특성에 대한 사용자가 읽을 수 있는 설명이 포함되어 있습니다.
This is a UTF-8 string that could read, for example, “Temperature in the living room.”
예를 들어 "거실의 온도"와 같이 읽을 수 있는 UTF-8 문자열입니다.
Client Characteristic Configuration Descriptor
클라이언트 특성 구성 설명명자
This descriptor type (often abbreviated CCCD) is without a doubt the most important and commonly used, and it is essential for the operation of most of the profiles and use cases.
이 설명자 유형 (종종 CCCD로 약칭)은 의심의 여지 없이 가장 중요하고 일반적으로 사용되며, 대부분의 프로파일과 사용 사례의 작동에 필수적입니다.
Its function is simple: it acts as a switch, enabling or disabling server-initiated updates (covered in more detail in “Server-Initiated Updates” on page 72), but only for the characteristic in which it finds itself enclosed.
그 기능은 간단합니다. 서버 시작 업데이트를 활성화하거나 비활성화하는 스위치 역할을 하지만 (자세한 내용은 72페이지의 "서버 시작 업데이트" 참조), 포함된 특성에 대해서만 적용됩니다.
Why Provide a Notification Switch?
알림 스위치를 제공하는 이유는 무엇입니까?
As discussed earlier, a client knows nothing in advance about a server’s attributes, so it will need to perform discovery to find out which services, characteristics, and descriptors are present on the server.
앞서 논의한 대로 클라이언트는 서버의 속성에 대해 미리 아무것도 모르기 때문에 서버에 어떤 서비스, 특성 및 설명자가 있는지 알아내기 위해 검색을 수행해야 합니다.
The server sends server-initiated updates (handle value notifications and handle value indications, introduced in “ATT operations” on page 26) asynchronously whenever a characteristic’s value changes, formatted in a packet that only contains an attribute handle and an array of bytes with the value.
서버는 특성 값이 변경될 때마다 비동기적으로 서버에서 시작하는 업데이트 (핸들 값 알림 및 핸들 값 표시, 26페이지의 "ATT 작업"에서 소개)를 전송하며, 속성 핸들과 값이 있는 바이트 배열만 포함하는 패킷으로 포맷합니다.
If the client has not yet discovered all characteristic and descriptor handles on the server, it might not yet be able to associate the data received in those notifications and indica‐ tions with a particular type, rendering those over-the-air transactions useless.
클라이언트가 아직 서버의 모든 특성 및 설명자 핸들을 발견하지 못했다면 해당 알림 및 표시에서 수신한 데이터를 특정 유형과 연관시키지 못할 수 있으며, 이로 인해 무선 거래가 쓸모없게 될 수 있습니다.
Furthermore, even when a client can identify all handles with their corresponding services and characteristics, there might be times (perhaps because the application is not visible, perhaps because the client uses only one of many services and characteristics in the server) when the client simply does not wish to receive updates.
게다가 클라이언트가 모든 핸들을 해당 서비스와 특성으로 식별할 수 있더라도 (예를 들어 애플리케이션이 보이지 않거나, 클라이언트가 서버에서 여러 서비스와 특성 중 하나만 사용하기 때문에) 클라이언트가 업데이트를 받고 싶지 않은 경우가 있을 수 있습니다.
That is where CCCDs come in, allowing for fine-grained enabling and disabling of notifications and indications for all characteristics that support them.
이것이 바로 CCCD가 등장하는 곳으로 이를 지원하는 모든 특성에 대한 알림 및 표시를 세밀하게 활성화 및 비활성화할 수 있습니다.
A CCCD’s value is nothing more than a two-bit bitfield, with one bit corresponding to notifications and the other to indications.
CCCD의 값은 2비트 비트필드에 불과하며, 한 비트는 알림에 해당하고 다른 비트는 표시에 해당합니다.
A client can set and clear those bits at any time, and the server will check them every time the characteristic that encloses them has changed value and might be susceptible to an update over the air.
클라이언트는 언제든지 해당 비트를 설정하고 지울 수 있으며, 서버는 해당 비트를 포함하는 특성의 값이 변경되어 무선 업데이트가 발생할 수 있을 때마다 이를 확인합니다.
Every time a client wants to enable notifications or indications for a particular characteristic that supports them, it simply uses a Write Request ATT packet to set the corresponding bit to 1.
클라이언트가 이를 지원하는 특정 특성에 대한 알림 또는 표시를 활성화하려고 할 때마다 단순히 쓰기 요청 ATT 패킷을 사용하여 해당 비트를 1로 설정합니다.
The server will then reply with a Write Response and start sending the appropriate packets whenever it wants to alert the client of a change in value.
그런 다음 서버는 쓰기 응답으로 응답하고 클라이언트에 값 변경을 경고할 때마다 적절한 패킷 전송을 시작합니다.
Additionally, CCCDs have two special properties that separate them from other attributes:
또한 CCCD에는 다른 속성과 구분되는 두 가지 특수 속성이 있습니다:
Their values are unique per connection.
해당 값은 연결마다 고유합니다.
In multi-connection scenarios, in which a central is connected to multiple peripherals and also acting as a GATT server, each peripheral will receive its own copy of the CCCD’s value when reading it with ATT.
중앙 장치가 여러 주변 장치에 연결되어 있고 GATT 서버 역할도 하는 다중 연결 시나리오에서 각 주변 장치는 ATT로 읽을 때 CCCD 값의 고유한 사본을 받습니다.
Their values are preserved across connections with bonded devices.
해당 값은 결합된 장치와의 연결 전반에 걸쳐 보존됩니다.
“Attribute Caching” on page 66 discusses attribute caching in more detail, but that concerns only attribute handles.
66페이지의 "속성 캐싱"에서는 속성 캐싱에 대해 자세히 설명하지만 이는 속성 핸들에만 적용됩니다.
Values are typically not stored per-device and the GATT server can reset them between connections.
값은 일반적으로 장치별로 저장되지 않으며 GATT 서버는 연결 간에 값을 재설정할 수 있습니다.
This is not the case with CCCDs among bonded devices: the last value written by a client to a CCCD on the server is guaranteed to be restored upon reconnection, regardless of the time elapsed between connections.
본딩된 장치 중 CCCD의 경우는 그렇지 않습니다. 클라이언트가 서버의 CCCD에 기록한 마지막 값은 연결 간 경과 시간에 관계없이 재접속 시 복원이 보장됩니다.
Many protocol stacks have special mechanisms to deal with CCCDs, both from a client’s and a server’s perspective, because they are so critical to correct operation and to guarantee timely data updates between peers.
많은 프로토콜 스택에는 클라이언트와 서버의 관점 모두에서 CCCD를 처리하는 특별한 메커니즘이 있습니다. 왜냐하면 CCCD는 작동을 수정하고 피어 간의 시기적절한 데이터 업데이트를 보장하는 데 매우 중요하기 때문입니다.
Characteristic presentation format descriptor
특성 표현 형식 설명자
When present, this descriptor type contains the actual format of the enclosing characteristic value in its seven-byte attribute value.
존재하는 경우 이 설명자 유형에는 7바이트 속성 값에 포함된 특성 값의 실제 형식이 포함됩니다.
The list of formats available include Booleans, strings, integers, floating-point, and even generic untyped buffers.
사용 가능한 형식 목록에는 부울, 문자열, 정수, 부동 소수점 및 일반 유형이 지정되지 않은 버퍼도 포함됩니다.
Example Service
예시 서비스
This section presents an example of a particular service found in many commercial products today.
이 섹션에서는 오늘날 많은 상용 제품에서 볼 수 있는 특정 서비스의 예를 제시합니다.
The Heart Rate Service (HRS) exposes the user’s heart rate to a monitoring device.
심박수 서비스 (Heart Rate Service (HRS))는 사용자의 심박수를 모니터링 장치에 노출합니다.
Figure 4-2 illustrates an instance of the HRS on a fictitious server.
그림 4-2는 가상 서버의 HRS 인스턴스를 보여줍니다.
This would not be the only service contained in the server, so you can see this as a partial slice of the complete set of attributes that a client could access.
이것은 서버에 포함된 유일한 서비스가 아니므로 클라이언트가 액세스할 수 있는 전체 속성 집합의 일부로 볼 수 있습니다.
Here is a handle-by-handle description of the HRS service illustrated in Figure 4-2:
다음은 그림 4-2에 예시된 HRS 서비스의 핸들별 설명입니다:
Handle 0x0021 : This attribute contains the service declaration (see “Services” on page 58) for the Heart Rate Service.
Handle 0x0021 : 이 속성에는 심박수 서비스에 대한 서비스 선언 (58페이지의 "서비스" 참조)이 포함되어 있습니다.
These are the service declaration attribute’s fields:
서비스 선언 속성의 필드는 다음과 같습니다:
The UUID is the standard 16-bit UUID for a primary service declaration, UUID primary service (0x2800).
UUID는 기본 서비스 선언인 UUID 기본 서비스 (0x2800)에 대한 표준 16비트 UUID입니다.
The value is the 16-bit UUID for the Heart Rate Service, assigned by the SIG (0x180D).
값은 SIG에서 할당한 심박수 서비스용 16비트 UUID (0x180D)입니다.
Handle 0x0024 : This attribute contains the characteristic declaration (see “Characteristic declaration attribute” on page 59) for the Heart Rate Measurement characteristic.
Handle 0x0024 : 이 속성에는 심박수 측정 특성에 대한 특성 선언 (59페이지의 "특성 선언 속성" 참조)이 포함되어 있습니다.
These are the characteristic declaration attribute’s fields:
다음은 특성 선언 속성의 필드들입니다:
The UUID is the standard 16-bit UUID for a characteristic declaration, UUID characteristic (0x2803).
UUID는 특성 선언, UUID 특성 (0x2803)에 대한 표준 16비트 UUID입니다.
Handle 0x0027 : This attribute contains the characteristic value (see “Characteristic value attribute” on page 61), in this case the heart rate measurement itself.
Handle 0x0027 : 이 속성에는 특성 값 (61페이지의 "특성 값 특성" 참조)이 포함되며, 이 경우 심박수 측정 자체가 포함됩니다.
These are the characteristic value attribute’s fields:
다음은 특성 값 속성의 필드입니다:
The same UUID present in the last two bytes of the characteristic definition’s attribute value.
특성 정의 속성 값의 마지막 2바이트에 동일한 UUID가 있습니다.
This attribute’s value is neither readable nor writable: a client can obtain its value only through notifications sent by the server.
이 속성의 값은 읽거나 쓸 수 없습니다. 클라이언트는 서버에서 보낸 알림을 통해서만 해당 값을 얻을 수 있습니다.
The actual heart rate measurement (fictitiously represented in beats per minute for clarity).
실제 심박수 측정값 (명확성을 위해 분당 심박수로 가상으로 표시됨).
Handle 0x0028 : This attribute contains a CCCD (a key descriptor described in “Client Characteristic Configuration Descriptor” on page 62).
Handle 0x0028 : 이 속성에는 CCCD (62페이지의 "클라이언트 특성 구성 설명자"에 설명된 키 설명자)가 포함되어 있습니다.
These are the CCCD attribute’s fields:
CCCD 속성의 필드는 다음과 같습니다:
The UUID for any CCCD is always the standard 16-bit UUIDCCCD (0x2902).
모든 CCCD의 UUID는 항상 표준 16비트 UUIDCCCD (0x2902)입니다.
A CCCD must always be readable and writable.
CCCD는 항상 읽고 쓸 수 있어야 합니다.
The security level required to execute these operations is defined by the profile or application.
이러한 작업을 실행하는 데 필요한 보안 수준은 프로필이나 애플리케이션에 의해 정의됩니다.
As already established, the CCCD’s value is a bit field, in this case 0x0001, denoting that notifications are enabled for this particular HRM characteristic.
이미 설정된 대로 CCCD의 값은 비트 필드 (이 경우 0x0001)로, 이 특정 HRM 특성에 대해 알림이 활성화되었음을 나타냅니다.
Handle 0x002A : This attribute contains another characteristic declaration (see “Characteristic declaration attribute” on page 59), this time for Body Sensor Location characteristic.
핸들 0x002A : 이 속성에는 또 다른 특성 선언이 포함되어 있습니다 (59페이지의 "특성 선언 특성" 참조). 이번에는 신체 센서 위치 특성에 대한 것입니다.
These are the characteristic declaration attribute’s fields:
다음은 특성 선언 속성의 필드입니다:
The UUID is the standard 16-bit UUID for a characteristic declaration, UUIDcharacteristic (0x2803).
UUID는 특성 선언을 위한 표준 16비트 UUID인 UUIDcharacteristic (0x2803)입니다.
The characteristic properties for this characteristic are read only, the characteristic value handle is 0x002C, and the characteristic value UUID is the UUID for the Body Sensor Location (0x2A38).
이 특성의 특성 속성은 읽기 전용이고 특성 값 핸들은 0x002C이며 특성 값 UUID는 Body Sensor Location (0x2A38)의 UUID입니다.
Handle 0x002C : This attribute contains the characteristic value (see “Characteristic value attribute” on page 61), in this case the body sensor location.
핸들 0x002C : 이 속성에는 특성 값 (61페이지의 "특성 값 특성" 참조) (이 경우 신체 센서 위치)이 포함됩니다.
These are the characteristic value attribute’s fields:
다음은 특성 값 속성의 필드입니다:
This attribute’s value is read only: a client can only check where the sensor is located, but not modify its location (that is up to the server).
이 속성의 값은 읽기 전용입니다. 클라이언트는 센서가 있는 위치를 확인할 수만 있고 위치를 수정할 수는 없습니다 (서버에 따라 다름).
The actual body sensor location (fictitiously represented as “finger” for clarity).
실제 신체 센서 위치입니다 (명확성을 위해 가상으로 "손가락"으로 표시됨).
Several tools exist to discover and display the different services on a server in a format similar to Figure 4-2, which can be useful during application development.
그림 4-2와 유사한 형식으로 서버의 다양한 서비스를 검색하고 표시하는 여러 도구가 있으며, 이는 애플리케이션 개발 중에 유용할 수 있습니다.
Chapter 6 has more information on these tools.
6장에는 이러한 도구에 대한 자세한 정보가 있습니다.