5. Feature
Ultra-low peak, average and idle mode power consumption
Ability to run for years on standard coin-cell batteries
Low cost
Multi-vendor interoperability
Enhanced range
07/04/135
12. 專有名詞 (ATT , GATT, UUID and CCCD )
ATT (Attribute Protocol) and GATT (Generic Attribute
Profile)
every LE profile is expected to use them. But they can also be used over
"vanilla" Bluetooth (BR/EDR).
ATT is a wire application protocol, while GATT dictates how ATT is
employed in service composition. Every Low Energy profile must be
based on GATT. So, ultimately, every LE service uses ATT as the
application protocol.
07/04/1312
13. 專有名詞 (ATT , GATT, UUID and CCCD )
ATT: Attribute Protocol
a 16-bit handle;
an UUID which defines the attribute type;
a value of a certaing length.
07/04/1313
14. 專有名詞 (ATT , GATT, UUID and CCCD )
GATT: Generic Attribute Profile
GATT is a base profile for all top-level LE profiles. It defines
how a bunch of ATT attributes are grouped together into
meaningful services.
07/04/1314
20. Nordic BLE profile
GATT-Based Specifications
1. alert notification profile/service
2. Current Time Service
3. Device Information Service
4. Find Me Profile
5. Health Thermometer Profile/Service
6. Heart Rate Profile/Service
7. Immediate Alert Service
07/04/1320
21. Nordic BLE profile
GATT-Based Specifications
Link Loss Service
Next DST Change Service
Phone Alert Status Profile/Service
Proximity Profile
Reference time Update Service
Time Profile
Tx Power Service
07/04/1321
22. Nordic BLE profile
The source code and project file can be found in the
<InstallFolder>Nordicnrf51822Boardnrf6310ble
<installFolder> @C:KeilARMDevice
07/04/1322
23. Nordic BLE profile
Test Step :
1. you can test the Profile example project By iOS system or
Master Control Panel
2. The every Profile project Testing Step at Nordic document
07/04/1323
可以看到 Bluetooth 的基礎架構仍然是維持上下兩大塊， Host 及 controller ，中間是兩方面溝通的 HCI(Host Controller Interface) 。以 controller 而言，原本到 3.0 是分為兩個 controller ； BR/EDR controller 及 AMP controller ，現在將 BR/EDR 擴充，變為 BR/EDR/LE controller ，可以看到與原本的 controller 有一些的不同，就是在於 Link Layer 。而 PHY(RF) 及 HCI 也都有為了 low energy( 以下簡稱 LE) 做了補充加強。而 Host ，則是除了 L2CAP 及 GAP 是擴充原本加入支援 LE 的功能，其他的 ATT protocol 及 GATT profile 都是為了 LE 而新增的階層。
以上圖說明，傳統的藍牙有 13 種的 protocol ，而 BLE 則簡化為一個，稱作 Attribute protocol(ATT) ，就很像傳統藍牙用來傳資料的 protocol ， RFCOMM ；基於 ATT 上面稱作 Generic Attribute profile ， BLE 各種制定的 Profile 就是基於 GATT 的 傳統的 BT 為了要支援許許多多的 profile ，制定了好幾種的 protocol ，所以所傳送的 packet 也有好幾種 ; BLE 的設計就簡單多了，只有一種， ATT ，只有一種 packet structure ，一個 packet formats ，當中參數不同來決定是 Advertising 還是 Data packets
健康類的比較好理解，而心跳算是應用面較廣的，例如有些較高檔的腳踏車碼表，就會附心跳計，讓運動員可以隨時偵測。體溫計可以利用在父母定時監控小 孩生病發燒的體溫，利用手機即可得知；或是婦女早上量測基礎體溫，預測哪一天是較易受孕的。血壓計則是可將計錄記在手機中做健康的管理。其他正在制定中的 還有血糖計及計步器。 通知類的有 Proximity Profile ，近距離感測，可利用手機與 NB 配對，當你在咖啡店時要上廁所時，帶著手機當遠離 NB 時，電腦會自動鎖住，依據手機與 NB 之間的訊號強弱，靠近 NB 時會自動解鎖，這樣就不用手動鎖電腦浪費時間啦。
dual mode 的意思就是傳統 BT 及現在的 BLE 通吃啦
a 16-bit handle ; an UUID which defines the attribute type ; a value of a certaing length . ATT itself does not define any UUID. This is left to GATT and higher-level profiles. it uses the ATT wire protocol to read and write values on server attributes. ATT wire protocol has some nice features, like searching attributes by UUID, getting all attributes given a handle range and so on, so the client does not need to know handle numbers beforehand, nor the higher-level profiles have to hardcode them. But handle numbers are expected to be stable for each given device Most of the ATT protocol is pure client-server: client takes the initiative, server answers. But ATT has notification and indication capabilities, in which the server takes the initiative of notifying a client that an attribute value has changed, saving the client from having to poll the attribute. The wire protocol never sends value length; it is always implied from PDU size, and client is expected to "know" the exact value layout for the UUID types it understands. Not sending value length explicitly saves bytes, which is particularly important in Low Energy, since MTU (maximum transmission unit) in LE is just 23 bytes. The small LE MTU is a problem for large attribute values. For those, ATT has "read long" and "write long" operations, which transfer big attributes in chunks. ATT adapts to link MTU; it does not limit packet size to lowest-common denominator. For example, a 40-byte attribute demands using the "read long" operation over LE, but can be read atomically over BR/EDR transport since the minimum MTU for the latter is 48 bytes.
a 16-bit handle ; an UUID which defines the attribute type ; a value of a certaing length . ATT itself does not define any UUID. This is left to GATT and higher-level profiles. it uses the ATT wire protocol to read and write values on server attributes. ATT wire protocol has some nice features, like searching attributes by UUID, getting all attributes given a handle range and so on, so the client does not need to know handle numbers beforehand, nor the higher-level profiles have to hardcode them. But handle numbers are expected to be stable for each given device Most of the ATT protocol is pure client-server: client takes the initiative, server answers. But ATT has notification and indication capabilities, in which the server takes the initiative of notifying a client that an attribute value has changed, saving the client from having to poll the attribute. The wire protocol never sends value length; it is always implied from PDU size, and client is expected to "know" the exact value layout for the UUID types it understands. Not sending value length explicitly saves bytes, which is particularly important in Low Energy, since MTU (maximum transmission unit) in LE is just 23 bytes. The small LE MTU is a problem for large attribute values. For those, ATT has "read long" and "write long" operations, which transfer big attributes in chunks. ATT adapts to link MTU; it does not limit packet size to lowest-common denominator. For example, a 40-byte attribute demands using the "read long" operation over LE, but can be read atomically over BR/EDR transport since the minimum MTU for the latter is 48 bytes.
The handle is just a number that uniquely identifies an attribute (since there may be many attributes with the same UUID within a device). ATT itself does not define any UUID. This is left to GATT and higher-level profiles. it uses the ATT wire protocol to read and write values on server attributes. ATT wire protocol has some nice features, like searching attributes by UUID, getting all attributes given a handle range and so on, so the client does not need to know handle numbers beforehand, nor the higher-level profiles have to hardcode them. But handle numbers are expected to be stable for each given device Most of the ATT protocol is pure client-server: client takes the initiative, server answers. But ATT has notification and indication capabilities, in which the server takes the initiative of notifying a client that an attribute value has changed, saving the client from having to poll the attribute. The wire protocol never sends value length; it is always implied from PDU size, and client is expected to "know" the exact value layout for the UUID types it understands. Not sending value length explicitly saves bytes, which is particularly important in Low Energy, since MTU (maximum transmission unit) in LE is just 23 bytes. The small LE MTU is a problem for large attribute values. For those, ATT has "read long" and "write long" operations, which transfer big attributes in chunks. ATT adapts to link MTU; it does not limit packet size to lowest-common denominator. For example, a 40-byte attribute demands using the "read long" operation over LE, but can be read atomically over BR/EDR transport since the minimum MTU for the latter is 48 bytes.
The cornerstone of a GATT service is the attribute with UUID equal to 0x2800. All attributes following this belong to that service, until another attribute 0x2800 is found. Each attribute does not "know" by itself to which service it belongs. GATT needs to figure it out based on handle ranges, and ranges are discovered solely on basis of UUID 0x2800 "cornerstones". This sounds a bit confusing at first; two UUIDs to define a single service? It is a result of layered GATT/ATT approach. The UUID 0x2800, which is well-known by GATT, is used to search for service boundaries. Once they are found, the attributes are read and the second UUID (stored as value) specifies the service. So a client may find all GATT services without knowing the specifics of e.g. a thermometer service. The UUID 0x2800 defines primary services. There are secondary services, too (UUID 0x2801), which are meant to be included by primary services Ok, how do I know if a given service is a thermometer, of keyfob, or GPS? By reading its value. The service attribute value contains an UUID, the service UUID. So, each service definition attribute has actually two UUIDs in its body: 0x2800 or 0x2801 as attribute UUID, and another one stored in value, which specifies the service.
. So, each service definition attribute has actually two UUIDs in its body: 0x2800 or 0x2801 as attribute UUID, and another one stored in value, which specifies the service.
Each GATT service has a number of characteristics . The characteristics store useful values for the services, as well as their permissions. For example, a thermometer would likely have a "temperature" characteristic, which is read-only, and possibly a date/time for timestamping, which is read/write. First off, there may be several characteristics per service, and each handle ranges for each characteristic are discovered by GATT the same way it does for services: by finding the "cornerstone" attributes. The main characteristic attribute has UUID = 0x2803. As happens with services, this attribute has "double UUIDs": the generic one (0x2803) which allows for easy discovering, and the specific one (in example: 0x2A2B for temperature) which tells exactly which information the characteristic contains. Each characteristic has at least two attributes: the main attribute (0x2803) and a value attribute that actually contains the value. The main attribute "knows" the value attribute's handle and UUID. This allows for a certain degree of cross-checking. The actual value format is entirely defined by its UUID. So, if the client knows how to interpret the value UUID 0x2A08, it is capable of reading date and time from any service that contains such a characteristic. In the other hand, if the client does not know how to interpret a certain value UUID, it may safely ignore it.
Apart from value, we can hang more attributes in every characteristic, if we need them. In GATT lingo, those extra attributes are called descriptors . GATT "knows" that handle 0x0104 is a descriptor that belongs to characteristic 0x0101 because a) it is not the value attribute, since the value attribute is known to be 0x0102; and b) it falls into the range 0x0103..0x010F, which falls between one characteristic and the next. The descriptor value is interpreted accordingly to attribute UIID. In the example, descriptor's UUID was 0x2A1F. A client may safely ignore a descriptor whose UUID is unknown. This allows for easy extension of a service, without breaking old clients. Each service may define its own descriptors, but GATT defines a set of standard descriptors that cover most cases, for example: Numeric format and presentation; Human-readable description; Valid range; Extended properties;
This descriptor, whose UUID is 0x2902, has a read/write 16-bit value, which is meant to be a bitmap. It is not some kind of client-side descriptor. It is server-side as any other attribute. But the server is required to store and present a separate instance of the value for each bonded client , and each client can only see its own copy. Hence the name. First two bits of CCC are already taken by GATT specification. They configure characteristic notification and indication. The other bits might be used for other functions, but they are currently reserved. Remember that ATT has notification capabilities, so the client does not need to poll for updates? By setting CCC, the client tells to server that it wants to be notified when the characteristic changes. It makes all sense for e.g. a thermometer. Let's see the thermometer service layout with CCC included: As usual, GATT knows that CCC belongs to temperature chraracteristic because the handle falls into the range (0x0102..0x010F). And it knows it is CCC because of the distinctive UUID (0x2902).
ANP Alert Notification Profile 1.0 ANS Alert Notification Service 1.0 CTS Current Time Service 1.0 DIS Device Information Service 1.0 FMP Find Me Profile 1.0 HTP Health Thermometer Profile 1.0 HTS Health Thermometer Service 1.0 HRP Heart Rate Profile 1.0 HRS Heart Rate Service 1.0 IAS Immediate Alert Service 1.0 LLS Link Loss Service 1.0 NDCS Next DST Change Service 1.0 PASP Phone Alert Status Profile 1.0 PASS Phone Alert Status Service 1.0 PXP Proximity Profile 1.0 RTUS Reference Time Update Service 1.0 TIP Time Profile 1.0 TPS Tx Power Service 1.0
ANP Alert Notification Profile 1.0 ANS Alert Notification Service 1.0 CTS Current Time Service 1.0 DIS Device Information Service 1.0 FMP Find Me Profile 1.0 HTP Health Thermometer Profile 1.0 HTS Health Thermometer Service 1.0 HRP Heart Rate Profile 1.0 HRS Heart Rate Service 1.0 IAS Immediate Alert Service 1.0 LLS Link Loss Service 1.0 NDCS Next DST Change Service 1.0 PASP Phone Alert Status Profile 1.0 PASS Phone Alert Status Service 1.0 PXP Proximity Profile 1.0 RTUS Reference Time Update Service 1.0 TIP Time Profile 1.0 TPS Tx Power Service 1.0
