Click [Internet of things thinking] at the top and click focus to view the wonderful sharing of Internet of things for the first time!

0. Preface

The attribute protocol (ATT) has two roles, Client and Server. The att protocol is a pure C/S architecture, that is, the Server stores attributes, the Client stores nothing, the Client actively initiates a request to read and write the attributes of the Server, and the Server responds passively. However, the Server also has the ability to notify. When the properties of the Server change, the Server can notify the Client, which avoids the Client's constant Poll.

1. Attribute classification

The attribute types of BLE are limited and can be divided into four categories. Primary Service Secondary Service Include (including service items) Characteristic

2. Relationship between Profile, service and feature

It can be seen that a Profile contains at least one service, and the service contains at least one feature declaration and feature value.

3. Attribute format

Attribute handle: attribute handle, 16 bit length; Attribute type: attribute type, 2 bytes or 16 bytes long, represented by UUID; Attribute value: the real value of the data; Attribute permissions: permission attribute.

4. Attribute permissions

At present, there are mainly the following four types: Access Permission: read-only, write only, read-write; The server uses access rights to determine whether the client can read and / or write attribute values; Encryption Permission: encrypted or unencrypted; Authentication Permission: authentication required or not required; The server uses authentication permissions to determine whether an authenticated physical link is required when a client attempts to access a property. Before sending a notification or instruction to the client, the server also uses the Authentication Permission to determine whether an authenticated physical link is required; Authorization Permission: authorization required or not required; The Authorization Permission determines whether the client needs to be authorized before accessing the attribute value.

Note: the permission of a certain attribute can be a combination of access permission, encryption permission, authentication permission and authorization permission.

The definitions of permissions in CH57X protocol stack are as follows:

// GATT Attribute Access Permissions Bit Fields
#define GATT_PERMIT_READ                 0x01 //!< Attribute is Readable
#define GATT_PERMIT_WRITE                0x02 //!< Attribute is Writable
#define GATT_PERMIT_AUTHEN_READ          0x04 //!< Read requires Authentication
#define GATT_PERMIT_AUTHEN_WRITE         0x08 //!< Write requires Authentication
#define GATT_PERMIT_AUTHOR_READ          0x10 //!< Read requires Authorization
#define GATT_PERMIT_AUTHOR_WRITE         0x20 //!< Write requires Authorization
#define GATT_PERMIT_ENCRYPT_READ         0x40 //!< Read requires Encryption
#define GATT_PERMIT_ENCRYPT_WRITE        0x80 //!< Write requires Encryption

5. Attribute declaration

be careful: The two required declarations are characteristic declaration and characteristic value declaration; The characteristic value declaration shall exist immediately after the characteristic declaration; A feature declaration is the beginning of a feature.

5.1 service statement

It can be seen that services are divided into primary services and secondary services, with UUID s of 0x2800 and 0x2801 respectively; Permissions are read-only.

5.2 inclusion statement

It can be seen that the UUID containing the declaration is 0x2802; Permissions are read-only.

5.3. Characteristic statement

It can be seen that the UUID of the feature declaration is 0x2803; Permissions are read-only.

5.3.1 value field of feature declaration

5.3.2 nature of the value of the characteristic declaration

Note: feature property and attribute permission are two concepts.

The properties of the value of the feature declaration in the CH57X protocol stack are defined as follows:

// GATT Characteristic Properties Bit Fields
#define GATT_PROP_BCAST                  0x01 //!< Permits broadcasts of the Characteristic Value
#define GATT_PROP_READ                   0x02 //!< Permits reads of the Characteristic Value
#define GATT_PROP_WRITE_NO_RSP           0x04 //!< Permits writes of the Characteristic Value without response
#define GATT_PROP_WRITE                  0x08 //!< Permits writes of the Characteristic Value with response
#define GATT_PROP_NOTIFY                 0x10 //!< Permits notifications of a Characteristic Value without acknowledgment
#define GATT_PROP_INDICATE               0x20 //!< Permits indications of a Characteristic Value with acknowledgment
#define GATT_PROP_AUTHEN                 0x40 //!< Permits signed writes to the Characteristic Value
#define GATT_PROP_EXTENDED               0x80 //!< Additional characteristic properties are defined in the Characteristic Extended Properties Descriptor

5.4. Eigenvalue statement

5.5. Feature description statement

5.5.1. Extended feature declaration

5.5.2 characteristic user description statement

UUID is 0x2901.

5.5.3 client feature configuration statement

UUID is 0x2902; Permissions are readable (no authentication, no authorization), writable (no authentication, no authorization) or specified by the upper layer.

5.5.4 server feature configuration statement

5.5.5 feature format declaration

5.5.6. Feature aggregation format declaration

6. Attribute definition

Attributes in CH57X are defined as follows:

typedef struct attAttribute_t
{
  gattAttrType_t type; //!< Attribute type (2 or 16 octet UUIDs)
  uint8 permissions;   //!< Attribute permissions
  uint16 handle;       //!< Attribute handle - assigned internally by attribute server
  uint8* pValue;       //!< Attribute value - encoding of the octet array is defined in 
                       //!< the applicable profile. The maximum length of an attribute 
                       //!< value shall be 512 octets.
} gattAttribute_t;

As you can see, it is consistent with the attribute format in 3.