Lines Matching +full:data +full:- +full:role
6 The Bluetooth Host implements all the higher-level protocols and
7 profiles, and most importantly, provides a high-level API for
17 Lowest down in the host stack sits a so-called HCI driver, which is
19 provides a basic API for delivering data from the controller to the
20 host, and vice-versa.
26 * Connection-oriented roles
32 * Connection-less roles
38 Each role comes with its own build-time configuration option:
41 connection-oriented roles central implicitly enables observer role, and
42 peripheral implicitly enables broadcaster role. Usually the first step
46 Peripheral role. This will be described in more detail in a later
49 Peripheral role
52 Most Zephyr-based BLE devices will most likely be peripheral-role
61 Central role
64 Central role may not be as common for Zephyr-based devices as peripheral
65 role, but it is still a plausible one and equally well supported in
67 role device will scan for available peripheral device and choose one to
78 There are some sample applications for the central role available in the
81 Observer role
84 An observer role device will use the :c:func:`bt_le_scan_start` API to
86 simply utilize the advertising data of found devices, combining it
89 Broadcaster role
92 A broadcaster role device will use the :c:func:`bt_le_adv_start` API to
93 advertise specific advertising data, but the type of advertising will be
94 non-connectable, i.e. other device will not be able to connect to it.
111 Man-In-The-Middle (MITM) attacks, it is recommended to use some
112 out-of-band channel during the pairing. If the devices have a sufficient
116 a set of optional callbacks that can be used during the pairing - if the
143 using separate mesh-specific APIs.
151 so-called Connection-oriented Channels (CoC) mode. More information on
155 -----------
160 .. list-table::
161 :header-rows: 1
163 * - Term
164 - Description
166 * - Upper layer
167 - Layer above L2CAP, it exchanges data in form of SDUs. It may be an
170 * - Lower layer
171 - Layer below L2CAP, it exchanges data in form of PDUs (or fragments). It is
174 * - Service Data Unit (SDU)
175 - Packet of data that L2CAP exchanges with the upper layer.
180 * - Protocol Data Unit (PDU)
181 - Packet of data containing L2CAP data. PDUs always start with Basic L2CAP
184 Types of PDUs for LE: :ref:`B-frames <bluetooth_l2cap_b_frame>` and
185 :ref:`K-frames <bluetooth_l2cap_k_frame>`.
187 Types of PDUs for BR/EDR: I-frames, S-frames, C-frames and G-frames.
189 * - Maximum Transmission Unit (MTU)
190 - Maximum size of an SDU that the upper layer is capable of accepting.
192 * - Maximum Payload Size (MPS)
193 - Maximum payload size that the L2CAP layer is capable of accepting.
195 In Basic L2CAP mode, the MTU size is equal to MPS. In credit-based
198 * - Basic L2CAP header
199 - Present at the beginning of each PDU. It contains two fields, the PDU
203 ---------
207 B-frame: Basic information frame
216 :alt: Representation of a B-frame PDU. The PDU is split into two rectangles,
223 K-frame: Credit-based frame
231 :alt: Representation of a starting K-frame PDU. The PDU is split into three
242 :alt: Representation of K-frames PDUs after the starting one. The PDU is split
249 ----------------
251 .. list-table::
252 :header-rows: 1
254 * - Kconfig symbol
255 - Description
257 * - :kconfig:option:`CONFIG_BT_BUF_ACL_RX_SIZE`
258 - Represents the MPS
260 * - :kconfig:option:`CONFIG_BT_L2CAP_TX_MTU`
261 - Represents the L2CAP MTU
263 * - :kconfig:option:`CONFIG_BT_L2CAP_DYNAMIC_CHANNEL`
264 - Enables LE Credit Based Flow Control and thus the stack may use
265 :ref:`K-frame <bluetooth_l2cap_k_frame>` PDUs
276 -----------
292 default, mesh requires both observer and broadcaster role to be enabled.
293 If the optional GATT Proxy feature is desired, then peripheral role
307 .. _bluetooth-persistent-storage:
317 .. code-block:: cfg