Skip to Content

Bluetooth/BLE Notes

Posted on

BLE

Application Layers                                                             
┌────────────────────────────────────────────────┐                              
│   Profiles, Services                           │                              
└────────────────────────────────────────────────┘                              
                                                                                
Host Layers                                                                     
┌─┬──────────────────────────────────┬───────────────────────────────────┐      
│ │                                  │                                   │      
│ │ Generic Attribute Profile (GATT) │ Generic Access Profile (GAP)      │      
│ ├──────────────────────────────────┼────────────────────────────────┐  │      
│ │ Attribute Protocol (ATT)         │ Security Manager Protocol (SMP)│  │      
│ │   MTU Payload Bytes:             │                                │  │      
│ │   L2CAP_MTU - 4 (header) = 19    │                                │  │      
│ └──────────────────────────────────┴────────────────────────────────┴──┤      
│   Logical Link Control and Adaptation Protocol (L2CAP)                 │      
│     Default MTU: 23 bytes, up to 251; Header uses 4 bytes              │      
└────────────────────────────────────────────────────────────────────────┘      
                                                                                
Controller Layers                                                               
┌─────────────────────────────────────────────────────────────────────┐         
│   Host Controller Interface (HCI - Data/Control)                    │         
├─────────────────────────────────────────────────────────────────────┤         
│  Isochronous Adaptation Layer                                       │         
│  Link Layer - 27 bytes, up to 251 bytes (Bluetooth 5)               │         
│  Physical Layer - Depending on PHY (1Mbps/2MBps) or coding scheme   │         
└─────────────────────────────────────────────────────────────────────┘

Application Layers

  • Defines the use case and functionality. Specifies how to interpret data coming from specific GATT Services
  • Unit and format of the data is calculated and normalized here

Host Layers

  • L2CAP provides multiple “logical channels” defined by the Channel ID (CID)
  • This is NOT the same as the 40 radio channels at the physical layer
    • The CID namespace is defined in the Bluetooth spec, Volume 3, Part A, Table 2.3
    • Usually, CID 0x0004 Attribute Protocol (ATT) is used for the actual data because that goes up to GATT and then the Attributes themselves
    • Dynamic CIDs are used for custom applications
    • Generic Access Profile (GAP) defines how devices discover, connect, and secure communication with each other. GAP uses L2CAP’s signaling capabilities to manage connection parameters and updates. Similar to a Control Plane.
  • If ATT_MTU is larger than physical packet size (Link Layer), it will be fragmented automatically. L2CAP is responsible for dividing up and re-assembling the packets, such that from ATT’s perspective it just gets one payload blob.
  • GATT Services, Characteristics and Descriptors have their own UUIDs for identification
    • You can design your own GATT Services and Characteristics; or use existing well-known ones.

Physical Layers

  • Physical Layer has Protocol Data Unit (PDU) of 27 bytes (up to 251 bytes in Bluetooth 5.0)

More Details

Bluetooth 4.0 was the original “LE”, which was relatively simple. In 4.1, ECDH was added.

BLE is very different from Bluetooth Classic – think of it as Wifi Alliance took Z-Wave and called it “Wifi 4.0”. L2CAP is the only shared foundational layer between BLE and Bluetooth Classic.

Bluetooth 5.0 added extended advertizing. The advertising channels were getting busy, so this is a way to make a short packet with a “pointer” to a timeslot where more information about that device can be read if desired.

“Just works” pairing – the first exchange is MITM-able.

Numeric comparison method is both parties do ECDH, compute a 6-digit number derived from the shared secret key, then display to the user. This relies on the user to perform check OOB.

Bluetooth Classic

TBD – too complicated