Hardware Reference
In-Depth Information
Conversely, Table 3-2 shows the modes that the peer needs be in to perform each of the
listed GAP procedures.
Table 3-2. Procedures and their required modes
Procedure
Applicable Role(s)
Applicable Peer Mode(s)
Observation
Observer
Broadcast
Limited discovery
Central
Limited discoverable
General discovery
Central
Limited and General discoverable
Name discovery
Peripheral, central
N/A
Any connection establishment
Central
Any connectable
Connection parameter update
Peripheral, central
N/A
Terminate connection
Peripheral, central
N/A
Chapter 1 and Chapter 2 introduced the basic concepts of over-the-air data exchange
in BLE, but it is worth reviewing them briefly here. Advertising packets are blindly sent
unidirectionally at fixed intervals, and they constitute the basis of both broadcasting
(and observing) and discovery. A device scanning for advertising packets might receive
one if it happens to scan while an advertising packet is being transmitted, and it might
simply receive the data contained in it or continue by initiating a connection. Connec‐
tions , on the other hand, require two peers that synchronously perform data exchanges
at regular intervals and provide guarantees on data transmission and throughput.
Broadcast and Observation
The broadcast mode and the observation procedure defined in GAP establish the frame‐
work through which devices can send data unidirectionally, as a broadcaster to one or
more actively listening peer devices (the observers ). It is important to note that the
broadcaster has no way of knowing whether the data actually reaches any observers at
all, so this combination of mode and procedure remains faithful to its nomenclature: a
broadcaster broadcasts data without any confirmation or acknowledgement, and an
observer listens (temporarily or indefinitely) for potential broadcasters without any
guarantee of ever actually receiving any data.
The advertising packets sent by the broadcaster contain actual valid user data, along
with a few items of metadata (such as Bluetooth device address) inserted by the Link
Layer. As described in “Advertising and Scanning” on page 19 , each advertising packet
contains up to 31 bytes of data (the actual available user data length will be lower due
to headers and format overheads), but that can be doubled by using the scan request/
scan response transaction just after the successful reception of an advertising packet on
the part of the observer, yielding up to 62 bytes of data per advertising event. Since a
scan response packet is sent only upon request from the observer, the most critical and
important data should always be placed in the advertising packet itself, not in the scan
 
Search WWH ::




Custom Search