Bluetooth Core Specification

To perform initial setup of a LE Controller, the following sequence of actions may be required.

First, the Host would wait for the Controller to indicate the number of HCI Command packets the Host is currently allowed to send using a Command Complete event on a No OPeration command opcode. Then it would reset the Controller to a known state. Then it needs to read the local supported features to check that low energy is supported on this Controller. It would then set the event mask and LE event mask to enable the events that it needs the Controller to generate to the Host. Next, it will check the buffers that are available for data flow, using the Read Buffer Size and LE Read Buffer Size commands. Then it would read the locally supported LE features and select the features that it may use. Finally, it will read the public device address if the Controller has one (see Figure 2.1).

Figure 2.1: Initial setup

A device may use a random device address, but this address has to be configured before being used during advertising, scanning or initiating (see Figure 2.2).

Figure 2.2: Random device address

Before advertising, scanning or initiating can use a Filter Accept List, the Filter Accept List may be cleared and devices added in as required (see Figure 2.3).

Figure 2.3: Filter Accept List

Before advertising, scanning or initiating can use resolving lists, the resolving list may be cleared and devices added in as required (see Figure 2.4).

Figure 2.4: Resolving lists

Before creating a connection, the Host may specify its preferred values for the Controller’s maximum transmission packet size and maximum packet transmission time to be used for new connections. This may be done on either the Central or the Peripheral.

Figure 2.5: Default data length

The Periodic Advertiser List may be cleared and entries added as required, before it is made use of (see Figure 2.6).

Figure 2.6: Periodic Advertiser List

A device may enter the Advertising state by enabling advertising. It should also configure the advertising parameters before doing this (see Figure 3.1).

Figure 3.1: Undirected advertising

A device may use directed advertising to allow an initiator to connect to it. High duty cycle directed advertising is time limited in the Controller and therefore this may fail before a connection is created. This example only shows the failure case (see Figure 3.2).

Figure 3.2: High duty cycle directed advertising showing failure case

Low duty cycle directed advertising is not time-limited. This example shows the case where no connection is made. A device should also configure the advertising parameters before doing this (see Figure 3.3).

Figure 3.3: Low duty cycle directed advertising

A device may enter the Advertising state by enabling advertising a set. It should also configure the advertising set parameters before doing this (see Figure 3.4).

Figure 3.4: Advertising using ADV_EXT_IND

A device may enable scan request notifications in an advertising set (see Figure 3.5).

Figure 3.5: Scan request notifications

A device may enter the Advertising State by enabling advertising a set for a limited duration of time (see Figure 3.6).

Figure 3.6: Advertising duration ended

A device may enter the Advertising State by enabling periodic advertising in a set. It should also configure the advertising set parameters before doing this (see Figure 3.7).

Figure 3.7: Periodic advertising

A device may send periodic advertising packets containing a Constant Tone Extension (see Figure 3.8).

Figure 3.8: Connectionless CTE transmission

A device may enter the Advertising state by enabling PAwR in a set. The device should configure the advertising set parameters before doing this (see Figure 3.11).

Figure 3.11: Configuring PAwR

A Controller may request data to be sent in one or more subevents of a PAwR advertising set. The Host can send this data to the Controller ahead of when the subevents are scheduled.

Figure 3.12: Transmitting PAwR subevents

A device can send a response to a PAwR advertisement packet. The timing of the response is determined by the Host using information from the advertisement packet. The Host can send a response by indicating the response slot and data to be sent in that response slot.

Figure 3.13: Using a response slot in PAwR

A device may initiate a connection with a synchronized device by using the LE Extended Create Connection command which indicates the subevent and BD_ADDR of the peer device. This initiates a connection by sending an AUX_CONNECT_REQ PDU in that subevent.

Figure 3.14: Connecting from PAwR

A synchronized device can miss an AUX_CONNECT_REQ PDU sent by the periodic advertiser.

Figure 3.15: Synchronized device misses the AUX_CONNECT_REQ PDU

The periodic advertiser can miss an AUX_CONNECT_RSP PDU sent by a synchronized device.

Figure 3.16: Periodic advertiser misses the AUX_CONNECT_RSP PDU

A device can use passive scanning to find advertising devices in the area. This would receive advertising packets from peer devices and report these to the Host (see Figure 4.1).

Figure 4.1: Passive scanning

A device may use active scanning to obtain more information about devices that may be useful to populate a user interface. Active scanning involves more Link Layer advertising messages (see Figure 4.2).

Figure 4.2: Active scanning

If a device does not support Privacy in the Controller, it may choose to forward LE Directed Advertising Report events from devices supporting Privacy without requiring filtering through the Controller Resolving List.

Figure 4.3: Directed advertising with Privacy

A device may use active scanning to obtain more information about devices that may be useful to populate a user interface. Privacy may be used during active scanning to make it more difficult to track either device during active scanning (see Figure 4.4).

Figure 4.4: Active scanning with Privacy

A Controller will periodically update the resolvable private addresses used on both devices if the devices use active scanning and advertising with Privacy. A Host may at anytime retrieve the read from the Controller the current addresses being used (see Figure 4.5).

Figure 4.5: Retrieving local and remote resolvable address updates from the Controller

A device may use active scanning on the secondary advertising physical channel in order to obtain more information about devices that may be useful to populate a user interface (see Figure 4.6).

Figure 4.6: Extended active scanning on the secondary advertising physical channel

A device may scan for a limited duration of time (see Figure 4.7).

Figure 4.7: Scan timeout

A device may establish synchronization with a periodic advertiser and report periodic advertising packets to the Host (see Figure 4.8).

Figure 4.8: Periodic scanning

A device may cancel a pending request to establish synchronization with a periodic advertiser. This example shows an unsuccessful synchronization, followed by cancellation of the synchronization (see Figure 4.9).

Figure 4.9: Periodic scanning cancel

A device may lose synchronization with a periodic advertiser (see Figure 4.10).

Figure 4.10: Periodic scanning timeout

Once synchronized with a periodic advertiser, the Host can terminate the synchronization (see Figure 4.11).

Figure 4.11: Periodic scanning terminate

A device may receive periodic advertising packets containing a Constant Tone Extension and send IQ samples to the Host (see Figure 4.12).

Figure 4.12: Connectionless Constant Tone Extension reception

A device may enable or disable reports after establishing synchronization with a periodic advertising train.

Figure 4.13: Periodic scanning with separate enable

Device A reports to the Host when it starts or stops receiving advertisements from device B.

Figure 4.14: Monitoring advertisers

A device can initiate a connection to an advertiser. This example shows a successful initiation, resulting in both devices able to send application data (see Figure 5.1).

Figure 5.1: Initiating a connection

A device can cancel a pending connection creation. This example shows an unsuccessful initiation, followed by a cancellation of the initiation (see Figure 5.2).

Figure 5.2: Canceling an initiation

A device can initiate a connection to an advertiser. Privacy may be used during connection initiation to make it more difficult to track either device during connection setup. The example shows a successful initiation, resulting in both devices able to send application data (see Figure 5.3).

Figure 5.3: Initiating a connection using undirected advertising with Privacy

A device can initiate a connection to an advertiser who is using Directed Advertising. Privacy may be used during connection initiation to make it more difficult to track either device during connection setup as well as target a single initiator. The example shows a successful initiation, resulting in both devices able to send application data (see Figure 5.4).

Figure 5.4: Initiating a connection using directed advertising with Privacy

This example shows an initiation that fails to establish because Device B (the advertiser) fails to respond to the Data Physical Channel PDUs sent by Device A.

Figure 5.5: Initiating a connection that fails to establish

Device A is not required to send Data Channel PDUs in the 6 connection intervals before establishment fails. However, if it does not do so, Device B is unable to respond.

A device can initiate a connection to an advertiser on the secondary channel. This example shows a successful initiation, resulting in both devices able to send application data (see Figure 5.6).

Figure 5.6: Initiating a connection on the secondary advertising physical channel

Where a device supports the Channel Selection Algorithm #2 feature, it can initiate a connection which will use Channel Selection Algorithm #2 to an advertiser who has the ChSel field of the advertising physical channel PDU set to 1. The example shows a successful initiation, resulting in the connection using Channel Selection Algorithm #2.

Figure 5.7: Initiating a Channel Selection algorithm #2 connection

A device can initiate a connection to an advertiser using an Extended Advertising advertising set. This causes additional events to be generated (see Figure 5.8). The LE Channel Selection Algorithm event can be generated irrespective of which algorithm is used by the connection.

Figure 5.8: Initiating a connection using an advertising set

Once two devices are in a connection, either device can send data. This example shows both devices sending data, for example when the Attribute Protocol does a read request and a read response is returned (see Figure 6.1).

Figure 6.1: Sending data

The Central of the connection may request a connection update using a Link Layer control procedure (see Figure 6.2).

Figure 6.2: Connection update

The Controller of the Central may receive some channel classification data from the Host and then perform the Channel Update Link Layer Control procedure (see Figure 6.3).

Figure 6.3: Channel map update

Both the Central and Peripheral can discover the set of features available on the remote device. To just fetch page 0, the Feature Exchange Link Layer Control procedure is used (see Figure 6.4 and Figure 6.5). 

Figure 6.4: Central-initiated features exchange 

Figure 6.5: Peripheral-initiated features exchange 

To fetch the entire feature list, this procedure is combined with 10 uses of the Feature Page Exchange procedure (see Figure 6.6). 

Figure 6.6: Complete feature exchange 

If the peer only supports features in pages 0 to 2, then the Feature Page Exchange procedure need only be used twice (see Figure 6.7). 

Figure 6.7: Complete feature exchange where only pages 0 to 2 are used 

If the Peripheral does not support the Feature Page Exchange procedure, then the command has finished successfully as soon as it determines that it does not support the new procedure (see Figure 6.8).

Figure 6.8: Complete feature exchange where the Peripheral does not support the new procedure 

Either device may perform a Version Exchange procedure (see Figure 6.9 and Figure 6.10).

Figure 6.9: Version exchange from Central

Figure 6.10: Version exchange from Peripheral

If encryption has not been started on a connection, it may be started by the Central (see Figure 6.11).

Figure 6.11: Start encryption

If encryption has not been started on a connection, it may be started by the Central. Figure 6.12 shows the failure case of the Peripheral not having the Long Term Key for the Central.

Figure 6.12: Start encryption without Long Term Key

If encryption has not been started on a connection, it may be started by the Central. Figure 6.13 shows the failure case when the Peripheral has masked out the HCI_LE_­Long_­Term_­Key_­Request event.

Figure 6.13: Start encryption with Peripheral masking out event

If encryption has not been started on a connection, it may be started by the Central. Figure 6.14 shows the failure case of the Peripheral that does not support the encryption feature.

Figure 6.14: Start encryption failure when Peripheral does not support encryption

If encryption has already been started on a connection, it may be restarted by the Central. This may be required to use a stronger encryption as negotiated by the Security Manager Protocol (see Figure 6.15).

Figure 6.15: Restart encryption

Once a connection has no need to be kept active, the Host can disconnect it. This can be done by either device (see Figure 6.16 and Figure 6.17).

Figure 6.16: Disconnect from Central

Figure 6.17: Disconnect from Peripheral

The Central or the Peripheral of the connection may request change in connection parameters using a Link Layer control procedure (see Figure 6.18 to Figure 6.25).

Figure 6.18: Peripheral-initiated Connection Parameters Request procedure - Peripheral requests a change in anchor points, Central accepts

Figure 6.19: Peripheral-initiated Connection Parameters Request procedure – Peripheral requests a change in anchor points, Central rejects

Figure 6.20: Peripheral-initiated Connection Parameters Request procedure – Peripheral requests change in LE connection parameters, Central’s Host accepts

Figure 6.21: Peripheral-initiated Connection Parameters Request procedure – Peripheral requests change in LE connection parameters, Central’s Host rejects

Figure 6.22: Central-initiated Connection Parameters Request procedure – Central requests a change in anchor points, Peripheral accepts

Figure 6.23: Central-initiated Connection Parameters Request procedure – Central requests a change in anchor points, Peripheral rejects

Figure 6.24: Central-initiated Connection Parameters Request procedure – Central requests change in LE connection parameters, Peripheral’s Host accepts

Figure 6.25: Central-initiated Connection Parameters Request procedure – Central requests change in LE connection parameters, Peripheral’s Host rejects

A Host may use the HCI_Write_Authenticated_Payload_Timeout command to change the maximum interval between packets containing a valid MIC that the Link Layer will enforce when encryption is used.

Figure 6.26: Set LE authenticated payload timeout

Either Link Layer can authenticate the remote device using the LE Ping procedure even if the remote device does not support the LE Ping feature. This procedure can also be used for soliciting a packet from the remote device containing a valid MIC. LL A may be a Central or a Peripheral.

Figure 6.27: Successful LE Ping

When a packet with a valid MIC has not been received within the LE Authenticated Payload Timeout, the Host is notified that the timer has expired.

Figure 6.28: Unsuccessful LE Ping

The T_{LE_Authenticated_Payload} Timer gets reset when the Host sets the Authenticated Payload Timeout.

Figure 6.29: T_{LE_Authenticated_Payload} Timer reset

Once a connection has been created, the Host may suggest maximum transmission packet size and maximum packet transmission time to be used for the connection. This may be done on either the Central or the Peripheral.

Figure 6.30: Data length update

To change the parameters for LE HDT PHY, the [v2] or above versions of the HCI_LE_Set_Data_Length command, the HCI_LE_Data_Length_Change event, the LL_LENGTH_REQ PDU and the LL_LENGTH_RSP PDU are used.

The Central or Peripheral of the connection may request a change in the PHY using a Link Layer control procedure (see Figure 6.31 to Figure 6.39).

The sequence of events shown in Figure 6.33 and Figure 6.36 can only happen before feature exchange and can only happen once per connection, because a Link Layer must not use a procedure that it knows the peer does not support as required by [Vol 6] Part B, Section 4.6.

Figure 6.31: Central-initiated PHY Update procedure – Central requests a change of PHY, PHY changed in at least one direction

Figure 6.32: Central-initiated PHY Update procedure – PHY not changed (either because Peripheral doesn't specify PHYs that the Central prefers, or because the Central concludes that the current PHYs are still best)

Figure 6.33: Central-initiated PHY Update procedure – Central requests a change of PHY, Peripheral does not support the feature

Figure 6.34: Peripheral-initiated PHY Update procedure – Peripheral requests a change of PHY, PHY changed in at least one direction

Figure 6.35: Peripheral-initiated PHY Update procedure – PHY not changed (either because Peripheral doesn't specify PHYs that the Central prefers, or because the Central concludes that the current PHYs are still best)

Figure 6.36: Peripheral-initiated PHY Update procedure – Peripheral requests a change of PHY, Central does not support the feature

Figure 6.37: Autonomous Central-initiated PHY Update procedure – Central requests a change of PHY, Peripheral accepts, PHY changed in at least one direction

Figure 6.38: Autonomous Central-initiated PHY Update procedure – Central requests a change of PHY, PHY not changed (either because Peripheral doesn't specify PHYs that the Central prefers, or because the Central concludes that the current PHYs are still best)

Figure 6.39: Central and Peripheral crossover PHY Update procedure – Central and Peripheral request a change of PHY concurrently

Where a Peripheral supports the Minimum Number of Used Channels procedure, it can request that a certain minimum number of channels be used on the indicated PHY. The example shows a successful request, resulting in a channel map update with the requested minimum number of channels used for the connection.

Figure 6.40: Requesting minimum number of used channels

The Link Layers of both the Central and Peripheral may initiate the same LL procedure at the same time.

Figure 6.41: LL procedure collision

The Central or Peripheral of the connection may request the remote device to send an LL_CTE_RSP PDU with a Constant Tone Extension (see Figure 6.42 to Figure 6.44).

The sequence of events shown in figure 6.40 can only happen before feature exchange and can only happen once per connection, because a Link Layer must not use a procedure that it knows the peer does not support as required by [Vol 6] Part B, Section 4.6.

Figure 6.42: Central or Peripheral-initiated Constant Tone Extension Request procedure – remote device responds successfully

Figure 6.43: Central or Peripheral-initiated Constant Tone Extension Request procedure – remote device does not support the feature

Figure 6.44: Central or Peripheral-initiated Constant Tone Extension Request procedure – remote device rejects

A Central sets up a CIG with parameters for one or more CISes, then establishes a CIS with a Peripheral (see Figure 6.45).

Figure 6.45: Device A establishes a CIS with a Peripheral

A Central sets up CIG parameters and establishes a CIS with two Peripherals (see Figure 6.46).

Figure 6.46: Device A establishes CISes with two Peripherals

The Peripheral’s Host rejects the request to establish a CIS with the Central (see Figure 6.47).

Figure 6.47: The Host in Device B rejects a CIS from Device A

While setting up CISes with two Peripherals, the Host of one of the Peripherals rejects the request to establish a CIS with the Central (see Figure 6.48).

Figure 6.48: The Host in Device C rejects a CIS from Device A

The Link Layer of the Peripheral rejects the request to establish a CIS with a Central (see Figure 6.49).

Figure 6.49: The Link Layer in Device B rejects a CIS request from Device A

While setting up CISes with two Peripherals, the Link Layer of one of the Peripherals rejects the request to establish a CIS with the Central (see Figure 6.50).

Figure 6.50: The Link Layer in Device C rejects a CIS from Device A

The Link Layer of the Central rejects the request to create a CIS (see Figure 6.51).

Figure 6.51: Link Layer in Device A rejects a request to create a CIS

The Host of the Central terminates a Connected Isochronous Stream (see Figure 6.52). Either A or B can be the Central.

Figure 6.52: Device A terminates an established CIS

The Host of device A, which is the Central, terminates a Connected Isochronous Stream either before the Link Layer starts creating that CIS (see Figure 6.53) or during the creation process (see Figure 6.54).

Figure 6.53: Device A terminates a CIS before the Link Layer starts creating it

Figure 6.54: Device A terminates a CIS during the creation process

The disconnection of the ACL causes the disconnections of CISes (see Figure 6.55).

Figure 6.55: ACL connection Terminated

A Host of the Central terminates the CIS and removes the CIG from the Link Layer (see Figure 6.56).

Figure 6.56: Device A terminates a CIS and removes a CIG

The Host of the Central terminates both the CISes in the CIG and removes the CIG from the Controller (see Figure 6.57).

Figure 6.57: Device A terminates both CISes and removes the CIG

Either device can initiate a Sleep Clock Accuracy Update procedure to query the sleep clock accuracy of the peer device (see Figure 6.58).

Figure 6.58: Device A requests SCA from Device B

Either device can initiate a Power Control Request procedure to request the peer device to adjust its transmit power level (see Figure 6.59).

Figure 6.59: Power Control Request procedure to request remote transmit power update

Either device can use the Power Control Request procedure to query the Acceptable Power Reduction (APR) value from the peer device and adjust its transmit power based on the response (see Figure 6.60).

Figure 6.60: Power Control Request procedure to query Acceptable Power Reduction (APR) and transmitter Update

When the Host issues a command to enable reporting of remote power level changes, the Controller may initiate a Power Control Request procedure to request the remote device to start power level management (see [Vol 6] Part B, Section 4.5.15). When the remote Controller changes its transmit power level, it sends an indication to the peer device (see Figure 6.61). If reporting of remote transmit power level changes is enabled, the Controller sends an LE Transmit Power Reporting event to the Host.

Figure 6.61: LL Power Change Indication procedure when device adjusts TX power autonomously

When a Host issues a command to read the transmit power level of a remote device, the Controller can initiate an LL Power Control Request procedure to query the transmit power level of the remote device (see Figure 6.62).

Figure 6.62: HCI command to read remote transmit power level

Before a PHY Update procedure is performed, the Link Layer may request a preferred transmit power level for the new PHY to be used by the remote device (see Figure 6.63).

Figure 6.63: Autonomous Central-initiated PHY Update procedure with preferred transmit power level. PHY changed in both directions.

An implementation may choose to manage transmit power levels only on active PHYs and could reject a request for preferred transmit power level on the new PHY before a PHY Update procedure is performed (see Figure 6.64).

Figure 6.64: Autonomous Central-initiated PHY Update procedure with remote device maintaining only a single transmit power level. PHY changed in both directions.

When a PHY Update procedure is performed to switch to the LE Coded PHY, where the local and remote devices can use both S=8 and S=2 coding, the Controller treats them as separate PHYs for the purpose of Power Control (see Figure 6.65).

Figure 6.65: Autonomous Central-initiated PHY Update procedure to change to the LE Coded PHY (S=8 and S=2). PHY changed in both directions.

When an associated CIS is established on a PHY different from the one used by ACL, the Power Change Indication procedure may be used to indicate the transmit power level used on the new PHY. When the associated CIS is disconnected, the implementations may choose to stop managing the PHY used on the CIS (see Figure 6.66).

Figure 6.66: ACL with associated CIS established on a new PHY different from one on ACL

When a Host enables path loss monitoring, the Controller may initiate the Power Control Request procedure to query the remote transmit power level. As the remote device moves around, the Controller monitors the path loss on the connection and sends events to the Host as appropriate (see Figure 6.67).

Figure 6.67: Power Control Request procedure in context of path loss monitoring

Figure 6.68 shows an example of unidirectional music streaming from Host A to Host B. Host A does LC3 codec processing in the Host and sends data over HCI to the Controller, which transmits the PDUs over the air without further processing. Host B configures an output data path to the speaker(s) and enables LC3 codec processing in the Controller.

The notifications between the Hosts are specified by the relevant profile(s).

If the audio data is stereo, then how the data sent to the output data path is split into the separate audio signals is outside the scope of this specification.

Figure 6.68: Host A with codec in the Host streams music to Host B which has a codec in the Controller

Figure 6.69 shows an example of a bidirectional voice call between Host A and Host B. Device A contains proprietary audio interface hardware with an embedded LC3 codec. Hence the Host sets up the ISO data path with Coding_Format set to transparent mode. Device B supports LC3 codec processing in the Controller and hence Host B sets up the ISO data path with Coding_Format set to LC3 along with the codec configuration data defined by the relevant profile(s).

The notifications between the Hosts are specified by the relevant profile(s).

Figure 6.69: Host A with codec in the data path establishes a bi-directional voice call with Host B with codec in the Controller

The contents of this section are now in Section 8.5.

A Central A in a connection with a Peripheral B modifies the subrating of the connection. The first two PDUs are not received by device B (see Figure 6.70).

Figure 6.70: Central A modifies the connection subrating

Peripheral B requests a new subrating for its connection with device A and makes the change (see Figure 6.71).

Figure 6.71: Peripheral B requests a change to the connection subrate which is accepted

Peripheral B requests a new Subrating for its connection with device A but device A rejects the change (see Figure 6.72).

Figure 6.72: Peripheral B requests a change to the connection subrate which is rejected

The Central can enable reporting of channel classification information on the Peripheral.

Figure 6.73: Central requests the Peripheral to enable reporting of channel classification information

The reporting is enabled, the Peripheral can provide channel classification information to the Central.

Figure 6.74: Peripheral provides channel classification information to the Central

The example flow in Figure 6.75 shows the CS setup phase, in which CS capabilities are read and roles are enabled at both ends of a connection. An encrypted ACL connection is established before exchanging CS capabilities and security parameters.

A distance measurement application in a Host can issue HCI commands to start the setup phase with the Channel Sounding Capability Exchange procedure. The local and remote Host can then set the default settings for Channel Sounding. Based on the capability support for a non-zero Frequency Actuation Error, the application can issue appropriate commands to read or write the mode-0 Frequency Actuation Error table. The application can create CS configurations using the Channel Sounding Configuration procedure. The Controller in the Central role can then start the Channel Sounding Security Start procedure. After the Channel Sounding Security Start procedure completes, the application can consider the setup phase to be completed.

After the first time the setup phase is completed with a specific remote device, an application may cache the remote capabilities, remote FAE table, and CS configuration parameters used. During subsequent connections, the Host may avoid LL control procedure exchanges as described in Figure 6.75.

Figure 6.75: Channel Sounding example setup phase

As mentioned in [Vol 1] Part A, Section 3.3.2.5.3, an LE device may assume either the initiator or reflector role. In the example shown in Figure 6.76, an application running on a Central device in the initiator role starts a CS procedure.

Figure 6.76: Channel Sounding started by Central in initiator role

As mentioned in [Vol 1] Part A, Section 3.3.2.5.3, an LE device may assume either the initiator or reflector role. In the example shown in Figure 6.77, an application running on a Peripheral device in the reflector role starts a CS procedure.

Figure 6.77: Channel Sounding started by Peripheral in reflector role

In the example shown in Figure 6.78, an application running on a Central device in the initiator role starts a CS procedure. The Peripheral rejects the LL_CS_REQ because the requested parameters are not acceptable.

Figure 6.78: Channel Sounding started by Central, rejected by Peripheral

In the example shown in Figure 6.79, an application running on a Central device in the initiator role starts a CS procedure. To remove a CS configuration that is being used in an active CS procedure, the Host first terminates the active CS procedure and then issues a LE CS Remove Config command.

Figure 6.79: Channel Sounding configuration removal during an active CS procedure

Either the Host or the Controller of device A requests a change to the frame space values of the connection, specifying a change to T_IFS_CIS, T_MSS_CIS, or a PHY that is not the PHY used on the ACL.

Figure 6.80: Frame Space Update affecting CIS only

Either the Host or the Controller of device A requests a change to the frame space value of the connection, specifying a change to T_IFS_CIS and a change to either T_IFS_­ACL_­CP, T_IFS_­ACL_­PC, or T_MCES. Device B responds with only a change to a PHY that is not the PHY used on the ACL.

Figure 6.81: Frame Space Update procedure where the responding device does not update the frame space for the PHYs used for the connection

Either the Host or the Controller of device A requests a change to the frame space value of the connection. Device B responds that it can modify T_IFS_­ACL_­CP on the PHY used on the ACL.

Figure 6.82: Frame Space Update where the frame space for the connection is affected

Central A in a connection with Peripheral B modifies the connection rate (see Figure 6.83).

Figure 6.83: Central A modifies the connection rate

Central A in a connection with Peripheral B attempts to modify the connection rate. Peripheral B rejects the procedure due to invalid parameters, or the instant in the past (see Figure 6.84).

Figure 6.84: Central A attempts to modify the connection rate, Peripheral B rejects

Peripheral B requests a new rate for its connection with Central A. Central A accepts the request (see Figure 6.85).

Figure 6.85: Peripheral B requests a change to the connection rate, Central A accepts

Peripheral B requests a new rate for its connection with Central A. Central A rejects the change (see Figure 6.86).

Figure 6.86: Peripheral B requests a change to the connection rate, which is rejected by Central A

Host A configures the Controller to generate a report each time a session key is generated. These reports are not sent to Host B.

Figure 6.87: Host on Device A enables the Encryption Key Debug Report event

The Central or Peripheral of the connection may request a change from GFSK PHY to LE HDT PHY on an unencrypted ACL connection using the PHY Update procedure as shown in Figure 6.88. The [v2] or above version of the LL_PHY_UPDATE_IND PDU is used if this is the first switch from a GFSK PHY to the LE HDT PHY on this connection.

Figure 6.88: Switch to LE HDT PHY on an unencrypted ACL connection

The Central or Peripheral of the connection may request a change from GFSK PHY to LE HDT PHY on an encrypted ACL connection using the PHY Update procedure as shown in Figure 6.89.

Figure 6.89: Switch to LE HDT PHY on an encrypted ACL connection

The Central or Peripheral of the connection may request a change from an LE HDT PHY to a GFSK PHY using the PHY Update procedure on an unencrypted ACL connection as shown in Figure 6.90.

Figure 6.90: Switch from LE HDT PHY to GFSK PHY on an unencrypted ACL connection

The Central or Peripheral of the connection may request a change from an LE HDT PHY to a GFSK PHY using the PHY Update procedure on an encrypted ACL connection as shown in Figure 6.91.

Figure 6.91: Switch from LE HDT PHY to GFSK PHY on an encrypted ACL connection

In both the unencrypted and the encrypted case, the Central and Peripheral finalize the sending of any outstanding Data Physical Channel PDUs during the PHY update procedure, as described in [Vol 6] Part B, Section 5.1.10.

A Central sets up a CIG with parameters for one or more CISes, then establishes a CIS with a Peripheral on LE HDT PHY (see Figure 6.92).

Note: On LE HDT PHY, a CIS Null PDU is a short format packet or a packet with corresponding transmit length set to zero.

Figure 6.92: Established CIG over LE HDT PHY

If encryption has not been started on a connection, then a Central may start encryption with key schedule as described in [Vol 6] Part B, Section 5.1.3.1 (see Figure 6.93).Encryption Start procedures

Figure 6.93: Start encryption with key schedule

If encryption has not been started on a connection, then a Central may start opportunistic encryption as described in [Vol 6] Part B, Section 5.1.3.1 (see Figure 6.94).Encryption Start procedures

Figure 6.94: Start opportunistic encryption

If encryption has already been started on a connection, then the Central may restart encryption with key schedule (see Figure 6.95).

Figure 6.95: Restart encryption with key schedule

If encryption has already been started on a connection, then the Central may refresh encryption without pausing it (see Figure 6.96).

Figure 6.96: Refresh encryption with Key Schedule

A Central device sets up a CIG with parameters for one CIS. The Central adds CIG configuration definitions and then establishes a CIS with the Peripheral. When the Connected Isochronous Group Configuration Definition procedure is complete, an event is sent to the Central and Peripheral Hosts.

Figure 6.97: CIS parameter update setup

A Central device sets up a CIG with parameters for one CIS. The Central adds CIG configuration definitions and then establishes a CIS with the Peripheral. When channel conditions change, for example based on packet error rate (PER), the Central initiates a CIS parameter update.

Figure 6.98: Central initiated CIS parameter update with 1 CIS

A Central device sets up a CIG with parameters for two CISes. The Central adds CIG configuration definitions and then establishes a CIS with Peripherals A and B. The CIG is set up with CIS events of A and B scheduled either sequentially or interleaved. When channel conditions change, the Central initiates a coordinated CIS parameter update with Peripherals A and B as needed.

Figure 6.99: Central initiated CIS parameter update with 2 CISes in sequential arrangement

A Central device sets up a CIG with parameters for one CIS. The Central adds CIG configuration definitions with the Peripheral and then establishes a CIS with the Peripheral. Based on local information, the Peripheral sends a request to the Central for a CIS parameter update.

Figure 6.100: Peripheral initiated CIS parameter update

When the Peripheral sends a request for a CIS parameter update to a different configuration group, the Central’s Controller notifies the Host and the Host accepts the request from the Controller. The Central’s Controller completes the update.

Figure 6.101: Peripheral-initiated CIS parameter update with Config_Group_ID change

A Central device sets up a CIG with parameters for one CIS. Figure 6.102 shows an example of a Peripheral-initiated Connected Isochronous Stream Update procedure being rejected because the Central has local constraints that make it unable to satisfy the request.

Figure 6.102: Peripheral-initiated CIS parameter update rejected by Central

A Central’s Host sets up a CIG with parameters for one CIS and adds CIG configurations for all supported Max_SDU (i.e., bit rate options). CIG configurations 0 and 1 are placed in configuration group 0 and CIG configuration 2 is placed in configuration group 1. Figure 6.103 shows an example of a Central’s Controller initiating updates to change the bit rates as and when link conditions (e.g., packet error rate (PER)), change. The Controller initiates an autonomous update to CIG configuration 1, which is part of the same configuration group 0. For CIG configurations in a different configuration group, only the Host is allowed to initiate an update. The Host then initiates an update to CIG configuration 2 and provides an update offset. When bit rate is decreased, the Central’s Host switches to the new bit rate by the event specified by the Instant.

Figure 6.103: Bit Rate changes with CIS parameter updates

A Central device sets up a CIG with parameters for music streaming. The Central also sets up parameters for a voice connection with a different transport latency value. Figure 6.104 shows an example of a Host initiating an update from music to voice and back to music.

Figure 6.104: CIS parameter updates for a use case switch with transport latency change

The scanning device (A) transfers periodic advertising synchronization information to device C, which starts listening to the periodic advertising train but only sends reports to the Host when explicitly requested.

Figure 7.1: Periodic Advertising Sync Transfer by scanner, reports initially disabled

The scanning device (A) transfers periodic advertising synchronization information to device C, which starts listening to the periodic advertising train and immediately sends reports to the Host.

Figure 7.2: Periodic Advertising Sync Transfer by scanner, reports initially enabled

The advertiser (B) directly transfers periodic advertising synchronization information about its periodic advertising to device C. In this example reports to Host C are disabled.

Figure 7.3: Periodic Advertising Sync Transfer by advertiser, reports initially disabled

A device enters the Synchronization state, receives the synchronization information from the periodic advertising train that is associated with the BIG, and synchronizes to a BIS (see Figure 8.1).

Figure 8.1: Device B synchronizes with a BIG

A device terminates synchronization with a BIG (see Figure 8.2).

Figure 8.2: Synchronization with a BIG is terminated

A device receives a channel map update for a BIG (see Figure 8.3).

Figure 8.3: Device A sends a channel map update for a BIG

A device loses synchronization with a BIG (see Figure 8.4).

Figure 8.4: Device B loses synchronization with a BIG

Figure 8.5 shows an example of an isochronous broadcast stream from the Broadcaster A. Host A sets up the ISO data path with codec processing in the Controller to create the PDUs transmitted over the BIS. Device B becomes a Synchronized Receiver for the BIS and sets up the ISO data path to do codec processing in the Controller on the received data PDUs.

Figure 8.5: Isochronous broadcasting between devices which both have a codec in the Controller