Hardware Reference
In-Depth Information
In the ANCS context, the iOS device always acts as a GATT server,
and the device that displays the notifications acts as a GATT client.
For efficiency, describing how the ANCS works requires some termi‐
nology. For the purposes of this discussion, we will refer to the iOS
device that sends the ANCS notifications as the
notification provider
(NP) and the accessory waiting to receive notifications (e.g., the BLE-
enabled watch) as the
notification consumer
(NC).
Notifications displayed on the iOS device are also known as
iOS no‐
tifications
, whereas notifications sent via BLE GATT characteristic are
known as
GATT notifications
.
Using ANCS does not require programming an app on the iPhone. Instead, the acces‐
sory advertises its request to receive notifications via an advertising packet, which in‐
cludes the service UUID of the ANCS (
7905F431-B5CE-4E99-A40F-4B1E122D00D0
).
Figure 9-6
shows the structure of the packet.
Figure 9-6. The advertising packet format used by the NC
When the NP iOS device scans an advertising packet with the ANCS UUID from the
NC, it connects to the NC accessory device. Now, a curious role reversal takes place (at
least in the way we might normally think of the data flow between the central and
peripheral). The NC (peripheral) becomes a GATT client, subscribing to services on
the NP (ANCS services) and receiving notifications and data from the NP (central) iOS
device. This is completely normal, because, as mentioned in
“Roles” on page 51
, the
GAP and GATT roles are independent from each other.
