Bluetooth low energy(ble) wireless technology

7,215 views

Published on

Published in: Technology, Business
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,215
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
243
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • BT 100m ,BLE 50m,
  • 可以看到 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 
  • Bluetooth low energy(ble) wireless technology

    1. 1. Author:steven Introduction Bluetooth low energy(BLE) wireless technology 07/04/131
    2. 2. Outline About Bluetooth Bluetooth low energy(BLE) wireless technology Feature Stack Profile Nordic BLE feature Example Nordic BLE framework(con,..) 07/04/132
    3. 3. About Bluetooth(BT) 2.0: EDR (Not Mandatory) 2.1: SSP (Mandatory) 3.0: High Speed (Not Mandatory) 4.0: Low Energy (Mandatory)  07/04/133
    4. 4. About Bluetooth Fig 1.History of Bluetooth 07/04/134
    5. 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
    6. 6. Feature Classic BT(Bluetooth) v.s BLE(bluetooth low energy) 1.藍牙 4.0  不傳聲音,  不傳檔案,  只傳資料,  小量的資料,  距離短  最短可在 3 毫秒內完成連線設定並開始傳輸資料  支援星形拓撲的一對多連線 1. BT 和 BLE, 不是用來取代 BT 。而是將 BT(BLE) 擴展 它的應用範圍。 07/04/136
    7. 7. Feature BT v.s BLE 07/04/137
    8. 8. Feature BT v.s BLE 07/04/138
    9. 9. Feature 專有名詞 : 藍牙規範( Bluetooth profile ) 藍牙技術聯盟定義了許多 Profile 。 Profile 目的是要確保 Bluetooth 設備間的互通性( interoperability )。但 Bluetooth 產 品無須實現所有的 Bluetooth 規範 Profile 。 SIG 所通過的 Profile ,分成兩類;健康醫療體適能及通知類。 有關健康的 Profile 有心跳計、體溫計及血壓計。通知類有電 話通知、近距離通知及時間等。 及新增 HID 的 Profile(keyboard and mouse) 。 07/04/139
    10. 10. Feature 專有名詞 : Bluetooth smart (single mode) Bluetooth smart ready(dual mode) BLE smart : 只能各 BT 4.0(smart and smart ready) 相容 BLE smart ready : 可向下相容於之前的 BT(2 and 3) 07/04/1310
    11. 11. 專有名詞 (ATT , GATT, UUID and CCCD ) 07/04/1311
    12. 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. 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. 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
    15. 15. 專有名詞 (ATT , GATT, UUID and CCCD ) GATT: Generic Attribute Profile . GATT services 07/04/1315
    16. 16. 專有名詞 (ATT , GATT, UUID and CCCD ) GATT: Generic Attribute Profile 07/04/1316
    17. 17. 專有名詞 (ATT , GATT, UUID and CCCD ) GATT service characteristics 07/04/1317
    18. 18. 專有名詞 (ATT , GATT, UUID and CCCD ) Characteristic descriptors 07/04/1318
    19. 19. 專有名詞 (ATT , GATT, UUID and CCCD ) Client Characteristic Configuration descriptor 07/04/1319
    20. 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. 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. 22. Nordic BLE profile The source code and project file can be found in the <InstallFolder>Nordicnrf51822Boardnrf6310ble <installFolder> @C:KeilARMDevice 07/04/1322
    23. 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
    24. 24. 07/04/1324
    25. 25. 07/04/1325
    26. 26. reference Bluetooth: ATT and GATT http://epx.com.br/artigos/bluetooth_gatt.php Bluetooth v4.0 真的是超省電的,只要傳統的 1/10 http://wjungle.blogspot.tw/2011/12/bluetooth-v40.html Bluetooth Smart (Low Energy) Technology file:///C:/Users/steven/AppData/Roaming/Mozilla/Firefox /Profiles/v0pqr6dp.default/ScrapBook/data/2013062811571 5/index.html 07/04/1326

    ×