Bluetooth Core Specification

The following terms are used in the ISOAL:

An unframed PDU is an ISO Data PDU; it shall contain payload from the SDU without additional headers in the payload. An unframed PDU shall only contain payload from a single SDU.

There are two types of unframed PDUs. An unframed PDU containing an end fragment or a complete SDU, and an unframed PDU containing a start or a continuation fragment. Unframed PDUs are identified by the LLID field as described below:

LLID in the header of the ISO Data PDU shall be set to 0b00 in the following conditions:

LLID in the header of the ISO Data PDU shall be set to 0b01 in the following conditions:

In the receiving device the payload from a PDU with LLID = 0b00 shall append the payload from PDUs with LLID = 0b01 to derive the length of the payload of the SDU. The SDU can contain some invalid or missing data due to missing or invalid PDUs. All SDUs shall be sent to the upper layer including the indication of validity of data. A report shall be sent to the upper layer if the SDU is completely missing.

Each fragment shall be sent in a new unframed PDU. Multiple fragments shall not be sent in a single PDU.

BN, Max_PDU and ISO_Interval parameters of the Connected or Broadcast Isochronous Stream shall be set such that the bandwidth of the data transmitted by the Link Layer shall be greater than or equal to the bandwidth of data from the upper layer.

The following two additional parameters are defined for unframed PDUs. USPI is the number of SDUs scheduled per ISO_Interval and equals ISO_Interval ÷ SDU_Interval. UPPS is the maximum number of fragments that an SDU is divided into and therefore the number of PDUs allocated to transmit each SDU. Both these parameters are integers.

UPPS shall be at least $⌈\text{Max\_SDU ÷ Max\_PDU}⌉$. BN shall equal UPPS × USPI.

Each SDU shall generate UPPS fragments. All these fragments shall be sent to the Link Layer before any fragments of the next SDU. If an SDU generates less than UPPS fragments, empty payloads shall be used to make up the number. Empty payloads shall be PDUs with LLID 0b01 with zero length payload, e.g., when UPPS=4 and only 3 PDUs are generated from the SDU, an additional padding PDU needs to be added.

When an SDU contains zero length data, the corresponding PDU(s) shall be of zero length and the LLID field shall be set to 0b00.

A framed PDU is an ISO Data PDU where the payload field is made up of segments or is empty. Each segment is encapsulated by a Segmentation Header and, for each first segment of a new SDU, a Time_Offset field is included to allow for reconstruction of the original SDU timing.

Framed PDUs shall be used when the requirements for using unframed PDUs are not met. Framed PDUs support the aggregation of data from multiple SDUs into a single PDU. The maximum allowed drift (MaxDrift) on the average timing of SDU delivery shall not exceed 100 ppm from the configured value of SDU_Interval.

There are two modes for use with framed¹ PDUs: Segmentable mode and Unsegmented mode. Segmentable mode shall be supported; Unsegmented mode may be supported.

In the Segmentable mode, the Controller may segment an SDU over multiple PDUs and a PDU may contain segments from more than one SDU. In the Unsegmented mode, each SDU shall be contained in a single segment in a single PDU; a PDU may contain more than one SDU.

Both modes use the same Segmentation Header format.

In Segmentable mode, the BN, Max_PDU and ISO_Interval parameters of the Connected or Broadcast Isochronous Stream shall be set such that the bandwidth of the data transmitted by the Link Layer shall be greater than or equal to the bandwidth of data from the upper layer plus the amount of space needed for the headers (including an allowance for MaxDrift). This requirement is met if:

BN × (Max_PDU − 2) ≥ $⌈\text{F}⌉$ × 5 + $⌈\text{F × Max\_SDU}⌉$

where F = (1 + MaxDrift) × ISO_Interval ÷ SDU_Interval

The requirement can be met without the inequality being satisfied.

In Unsegmented Mode, the Max_PDU parameter shall be set to $⌈(\mathrm{ISO\_Interval}÷\mathrm{SDU\_Interval}\times (1+\mathrm{MaxDrift})÷\mathrm{BN})⌉\times \left(\text{5 + Max\_SDU}\right)$. For example, 40-octet SDUs generated at 10 ms intervals (with the worst-case drift of 100 ppm) will require a Max_PDU of 45 octets when sent at 7.5 ms ISO_Interval (since there is at most one SDU per PDU, BN will equal 1).

Figure 2.2 shows how multiple segments from multiple SDUs may fit in multiple ISO Data PDUs. Each row in the figure shows the payload field of one PDU. The number and length of segments in the payload shall be limited such that the length of the ISO Data PDU does not exceed the Max_PDU set for the Connected or Broadcast Isochronous Stream.

Figure 2.2: Examples of ISO data PDU payload fields with one or more segments

The format of a Segmentation Header is shown in Figure 2.3.

Figure 2.3: Segmentation header format

The fields in the Header is shown in Table 2.2.

Each framed PDU starts with a Segmentation Header that contains a SC, CMPLT and a Length field. Depending on the SC field, an additional Time_Offset parameter is included between the Segmentation Header and the start of SDU data to indicate the relative timing difference between the SDU and CIG reference point or BIG anchor point timing.

A framed PDU with non-zero length shall contain one or more segments. A framed PDU with zero length can be used as a padding PDU; such a PDU does not have a Segmentation Header. Padding is required when the data does not add up to the configured number of PDUs that are specified by the BN parameter per BIS or CIS event.

The Segmentation Header includes the SC and the CMPLT fields with the following requirements:

The Segmentation Header shall contain a Length field. The Length field indicates the number of octets of the SDU data segment following the Segmentation Header including the length of Time_Offset when present (see Section 3).

Data from a single SDU shall not be split over multiple segments in a single PDU. Additional Segmentation Headers and data from other SDUs may be added depending on available remaining octets in that PDU. When an SDU has zero length, the SDU shall be included with a Segmentation Header with SC set to 0, CMPLT set to 1, and the length field set to the length of the Time_Offset. Such an empty SDU shall contain a correct Time_Offset, to allow the higher layer of the device that receives the empty SDU to maintain synchronization.

Because an isochronous transport is not a reliable transport, Segmentation Headers shall integrally be contained in a single PDU. When insufficient octets remain in a framed isochronous PDU to contain the Segmentation Header and the Time_Offset field, no new Segmentation Header can be added, as shown in Table 2.3. When only 5 octets remain, a new Segmentation Header, including the start of the next SDU, may be included but is not recommended.

A start of a new SDU with SC = 0 shall only be used when the previous frame has completed. A continuation of an SDU with SC = 1 shall only be used if the previous transmitted Segmentation Header had the completion flag set to 0.

When one or more ISO Data PDUs are not received, the receiving device may discard all SDUs affected by the missing PDUs. Any partially received SDU may also be discarded. A report shall be sent to the upper layer for each discarded SDU.

At the transmitter, the Time_Offset is measured from the reference time of the SDU at the source to the CIG Reference point or BIG anchor point of the corresponding CIG or BIG event of the isochronous payload containing the first Segmentation Header of that SDU. This computation excludes any potential retransmissions or missed subevents, resulting in the time of transmission under perfect link conditions. The Time_Offset shall be a positive value.

The reference time of the SDU is determined based on the local timing in the Controller based on either a time stamp of that SDU (e.g., provided via the Time_Stamp parameter in the HCI ISO Data packet) or another mechanism used by the implementation tracking the SDU timing to the transport timing.

Figure 3.1: SDU synchronization reference using the Time_Offset parameter

For details on the computation of the SDU synchronization reference and transport latency for all options of framed and unframed PDU in CIS and BIS, see Section 3.2.

At the receiver, the CIS reference anchor point is computed excluding any retransmissions or missed subevents, resulting in the time of transmission under perfect link conditions. Similar calculations can be performed for BIG.

Any potential delays in effective transmission shall be excluded in the calculation of Time_Offset.

When BN is greater than 1, all PDUs belonging to the same CIS or BIG event use the same reference anchor point.

For example, in a CIS with BN=2 and FT = 10, payload number 720 can have its first transmission potentially in CIS event 360 and its last potential transmission in CIS event 369. Even when the transfer effectively takes place in CIS event 365, the CIS reference anchor point for this payload is the anchor point of CIS event 360.

The Controller transmitting an SDU may use any of the following methods to determine the value of the SDU reference time, indicated in Figure 3.1, to define the Time_Offset for that SDU:

This section describes the method of managing the SDU synchronization reference in framed and unframed PDUs.

3.2.2. SDU synchronization reference using unframed PDUs

Using unframed PDUs does not introduce additional delay when the SDU interval equals the isochronous interval. When the Isochronous interval is larger than the SDU interval, multiple SDUs are received per BIS or CIS event which increases the delay. This additional delay shall be included when computing the SDU_Synchronization_Reference.

The transport latency is the duration between the CIG reference point (or BIG anchor point for BIG) of the first possible CIG event (or BIG event) containing the payload to the CIG synchronization point (or BIG synchronization point) of the last possible CIG event (or BIG event) containing the payload, plus the additional delay when grouping multiple SDUs in a single ISO_Interval (as shown in Figure 3.2 for CIG). Transport latency is measured from the reference time of the SDU to its SDU_Synchronization_Reference and does not include any implementation specific processing times or internal transport delays (e.g., delays over the HCI transport or PDU processing times).

The Transport_Latency for a CIG is the actual latency of transmitting payloads of all CISes in the CIG, and is calculated as:

Transport_Latency_C_To_P = CIG_Sync_Delay + (FT_C_To_P – 1) × ISO_Interval + (USPI_C_To_P – 1) × SDU_Interval_C_To_P Transport_Latency_P_To_C = CIG_Sync_Delay + (FT_P_To_C – 1) × ISO_Interval + (USPI_P_To_C – 1) × SDU_Interval_P_To_C

where USPI_C_To_P and USPI_P_To_C are the values of USPI for the two directions.

These calculations can be simplified as follows:

Transport_Latency_C_To_P = CIG_Sync_Delay + FT_C_To_P × ISO_Interval – SDU_Interval_C_To_P Transport_Latency_P_To_C = CIG_Sync_Delay + FT_P_To_C × ISO_Interval – SDU_Interval_P_To_C

The Transport_Latency for a BIG is the actual latency of transmitting payloads of all BISes in the BIG, and is calculated as:

Transport_Latency = BIG_Sync_Delay + PTO × (NSE ÷ BN – IRC) × ISO_Interval + (USPI – 1) × SDU_Interval

This calculation can be simplified as follows:

Transport_Latency = BIG_Sync_Delay + (PTO × (NSE ÷ BN – IRC) + 1) × ISO_Interval – SDU_Interval

For example, when the SDU interval is 10 ms and the Isochronous interval is 20 ms an additional 10 ms is added due to combination of 2 SDUs in one BIS or CIS event.

Figure 3.2: SDU synchronization reference using the unframed PDUs

Each SDU is given a synchronization reference point based on the reference anchor point.

The CIS reference anchor point is computed excluding any retransmissions or missed subevents and shall be set to the start of the CIS event in which the first PDU containing the SDU could have been transferred.

The BIG reference anchor point is the anchor point of the BIG event that the PDU is associated with (see [Vol 6] Part B, Section 4.4.6.6).

For the Central to Peripheral direction or from the Isochronous Broadcaster to Synchronized Receiver direction, the SDU synchronization point represents the absolute time where the data from a CIG or BIG should be available, and can be used to synchronize between multiple devices.

For SDUs sent from the Central to the Peripheral in CIS using unframed PDUs the SDU_Synchronization_Reference for the first SDU received in a burst of PDUs shall be calculated as follows:

SDU_Synchronization_Reference = CIS reference anchor point + CIS_Sync_Delay + (FT_C_To_P – 1) × ISO_Interval

For the Peripheral to Central direction, the SDU synchronization point represents the absolute reference time of the origin of an SDU and can be used to synchronize data coming from multiple sources. This point is at the start of the CIG reference point.

For SDUs sent from the Peripheral to the Central in CIS using unframed PDUs, the SDU_Synchronization_Reference for the first SDU received in a burst of PDUs shall be calculated as follows:

SDU_Synchronization_Reference = CIS reference anchor point + CIS_Sync_Delay – CIG_Sync_Delay + SDU_Interval – ISO_Interval

For SDUs received in BIS using unframed PDUs, the SDU_Synchronization_Reference shall be calculated as follows:

SDU_Synchronization_Reference = BIG reference anchor point + BIG_Sync_Delay

All PDUs belonging to a burst as defined by the configuration of BN have the same reference anchor point. When multiple SDUs have the same reference anchor point, the first SDU uses the reference anchor point timing. Each subsequent SDU increases the SDU_Synchronization_Reference timing by one SDU interval.

When the Time_Stamp field is included in an HCI ISO Data packet from the Controller to the Host, the value of Time_Stamp is set to the synchronization reference for the SDU, as defined in Section 3.2, and is based on the CIS or BIG reference anchor point of the Controller’s clock. The Controller should include a Time_Stamp.

The Host may determine the CIG reference point or BIG anchor point for the last transmitted SDU from the TX_Time_Stamp and Time_Offset return parameters of the HCI_LE_Read_ISO_TX_Sync command, as shown in Figure 3.1. It may then use this information when providing the Time_Stamp in future HCI ISO Data packets. For each HCI ISO Data packet where the Host can provide a valid Time_Stamp value, it should include a Time_Stamp in those HCI ISO Data packets that it sends.

When an HCI ISO Data packet sent by the Host does not contain a Time_Stamp or the Time_Stamp value is not based on the Controller's clock, the Controller should determine the CIS or BIS event to be used to transmit the SDU contained in that packet based on the time of arrival of that packet.

In each direction, in a given packet, the Time_Stamp provided (if any) shall be one that applies to the SDU corresponding to the Packet_Sequence_Number.

When using the Time_Stamp or another suitable method for synchronization, both the higher layer and Controller should implement a mechanism to compensate potential clock drift and jitter. These mechanisms should include long term drift compensation and tolerances on the synchronization method used.

The Controller or the higher layer sending or receiving an SDU may use any of the following methods to transfer the synchronization reference of the SDU to the higher layer: