Part E. General Terminology and Interpretation
vAtlanta r00
1. Language conventions
In the development of a specification, the Bluetooth SIG has established the following conventions for use of the terms “shall”, “shall not”, “should”, “should not”, “may”, “must”, and “can”. In this Bluetooth specification, the terms in Table 1.1 have the specific meanings given in that table, irrespective of other meanings that exist.
shall | —used to express what is required by the specification and is to be implemented exactly as written without deviation |
shall not | —used to express what is forbidden by the specification |
should | —used to express what is recommended by the specification without forbidding anything |
should not | —used to indicate that something is discouraged but not forbidden by the specification |
may | —used to indicate something that is permissible within the limits of the specification |
must | —used to indicate either: 1. an indisputable statement of fact that is always true regardless of the circumstances 2. an implication or natural consequence if a separately-stated requirement is followed |
can | —used to express a statement of possibility or capability |
1.1. [This section is no longer used]
1.2. [This section is no longer used]
1.3. [This section is no longer used]
1.4. [This section is no longer used]
1.5. [This section is no longer used]
1.6. [This section is no longer used]
1.7. Implementation Alternatives
When specification content indicates that there are multiple alternatives to satisfy specification requirements, if one alternative is explained or illustrated in an example it is not intended to limit other alternatives that the specification requirements permit.
1.8. Discrepancies
It is the goal of Bluetooth SIG that specifications are clear, unambiguous, and do not contain discrepancies. However, members can report any perceived discrepancy by filing an erratum and can request a test case waiver as appropriate.
1.9. Appropriate Language
Certain terms that were identified as inappropriate have been replaced. As a consequence, some other terms have also been changed to retain consistency and some HCI command and event names had consequential changes. For a list of the original terms and names and their replacements, see the Appropriate Language Mapping Tables, https://www.bluetooth.com/language-mapping/Appropriate-Language-Mapping-Table.
2. General interpretation rules
The following rules apply throughout the specification except where explicitly overridden.
2.1. Binary and hexadecimal values
Binary numbers are normally written with a “0b” prefix, so 0b1101 is the same as the decimal number 13.
In some places a sequence of bits is written in quotation marks thus: '1010'. Such sequences are not normally intended to be interpreted as numbers. The order that the bits are to be processed will always be specified.
Hexadecimal numbers are written with a "0x" prefix, so 0x42 is the same as the decimal number 66. The letters "a" to "f" are used to represent the digits 10 to 15, so 0x1A is the same as the decimal number 26. The case of letters in a hexadecimal number is not significant.
Underscore characters may be placed between the digits of binary or hexadecimal numbers to make them easier to interpret; these underscores shall not affect the value. For example, 0b0010_1011 and 0b00101011 both equal the decimal number 43.
All numbers not written in one of the above ways are decimal.
2.2. Bit numbers and bit fields
In some cases the specification needs to refer to some of the bits of an integer value. Bits are always numbered from 0 as the least significant bit, so bit 0 of 0b1011 equals 1 while bit 2 equals 0. A single bit will be notated with a subscript, as in CLK5.
Sometimes it is necessary to refer to a consecutive set of bits; for example, given a value CLK it may be necessary to refer to bits 2 to 4 of CLK (that is, the value equal to (CLK ÷ 4) mod 8. This will be notated either by a subscript with a dash or by brackets and a colon; the bit numbers will always be inclusive and the most significant bit number is given first. For example, bits 2 to 4 of CLK are written CLK4-2 or CLK[4:2].
2.3. Specification of bit values
Some values in the specification are divided into individual bits, each of which has a description. If explicit bit values are not given then this description represents the meaning when the bit equals 1 and the opposite applies when the value is 0. For example, a description of:
Bit 3: use 3-slot packets
means the same as:
Bit 3 = 1: use 3-slot packets;
Bit 3 = 0: do not use 3-slot packets.
2.4. Values with restricted purposes
Where a field in a packet, PDU, or other data structure, a parameter, or another variable object is described as being split into components (e.g., when each bit of a field has a separate meaning), the rules in this section apply to each component separately.
2.4.1. Reserved for future use
Where a field in a packet, PDU, or other data structure is described as "Reserved for future use" (irrespective of whether in upper or lower case), the device creating an instance of the structure to send to another device (including messages sent between a Host and a Controller over HCI) shall set it to zero. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.
Where a field, parameter, or other variable object can take a range of values and some values are described as "Reserved for future use", devices shall not set the object to any of those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or if it is specified to ignore unrecognized values.
Where a field, parameter, or other variable object only has meanings specified for some values, all other values are reserved for future use.
The abbreviation "RFU" is equivalent to "Reserved for future use".
2.4.2. Previously used
The term "Previously used" (irrespective of whether in upper or lower case) indicates that a field or value was used for a removed feature (see [Vol 1] Part C, Section 1). Devices that do not implement that feature shall treat the field or value as reserved for future use.
Note
Note: These fields and values will not be used for new features.
2.5. Use of invalid values in checksums and other calculations
Where a field or value is used as part of a checksum, CRC, cryptographic key, or other similar calculation, and the value sent to or received from the peer is not valid (for example, it is an RFU field that has not been set to 0 by the sender), the actual value sent or received shall be used in the calculation and it shall not be replaced by a different valid value.
2.6. Assigned number requirements
The Bluetooth SIG maintains a published set of assigned numbers on the Bluetooth SIG Assigned Numbers web page. These assigned numbers are grouped in various number spaces. Numbers assigned may overlap with other assigned numbers in different number spaces, but no number within a number space is ever reused. The various number spaces are defined in the specification that defines the usage of the assigned numbers.
All assigned numbers within a given number space shall only be designated by the Bluetooth SIG and shall only be used for their intended purposes when used within a field, parameter, or other variable object defined to take on a value within that number space. All values not explicitly assigned within a given number space are Reserved for future use and subject to the requirements in Section 2.4.
All 16-bit and 32-bit UUIDs as defined in [Vol 3] Part B, Section 2.5.1, are considered assigned numbers. All other UUID values may be used in any context where a UUID is permitted provided they are generated according to the recommendations in ITU-T Rec. X.667(10/2012), alternatively known as ISO/IEC 9834.8:2014.
2.7. Responding to invalid behavior
If a device receives a packet or PDU that it supports but is not permitted in its current state, or has contents not permitted by the specification, the sending device has exhibited invalid behavior. Unless the specification states a particular action to be taken, the receiving device should respond in one of the following ways:
Ignore the packet or PDU.
Attempt to recover the situation while both not violating the specification and being prepared for the sending device to be in a state where one or both devices cannot recover.
If the packet or PDU was received from the peer device in a connection, either immediately terminate that connection or consider the connection to be lost. This may be done at any appropriate layer; e.g., following invalid behavior on an L2CAP channel, a device could choose to terminate either the channel or the underlying ACL connection.
Methods for recovering from invalid behavior include, but are not limited to:
Sending a rejection response
If a packet or PDU is too long, ignoring the extra contents
If a value is out of range, using the nearest permitted value
If a field is missing, using any default value specified
Examples of packets or PDUs not permitted in the current state include:
A POLL packet sent by a Peripheral (see [Vol 2] Part B, Section 6.5.1.3)
An LMP_DETACH PDU received while the device is in Hold or Sniff mode (see [Vol 2] Part C, Section 4.1.2)
Any packet sent on the primary advertising physical channel using the LE 2M PHY or an ADV_IND PDU sent on the LE Coded PHY (see [Vol 6] Part B, Section 2.3)
Two consecutive LL_FEATURE_REQ PDUs sent by a Central with no LL_FEATURE_RSP sent by the Peripheral between them (see [Vol 6] Part B, Section 5.1.4.1)
A second LL_VERSION_IND PDU sent by the same device during the same connection (see [Vol 6] Part B, Section 5.1.5)
A second ATT request or indication before the device has sent a response or confirmation in reply to the first one
Examples of packets and PDUs with contents not permitted by the specification include:
A packet or PDU which is required to have a specific length but does not have that length
A PDU where the value of a specific parameter or field is out of range (also see Section 2.4)
An L2CAP C-frame sent over fixed channel CID 0x0005 that contains more than one command (see [Vol 3] Part A, Section 4) or has a length longer than that of the enclosed command packet
Note
Note: The appropriate response to invalid behavior will depend on the specific circumstances and the choice made can affect the user experience. For example, a POLL packet sent by a Peripheral could actually be a NULL packet with the TYPE field corrupted, so it would be reasonable to ignore the POLL packet rather than terminate the connection. On the other hand, invalid behavior during a security procedure can indicate an attack by a third party and immediate disconnection may be appropriate.
Note
Note: If the sending device supports different features or a different version of the specification, invalid behavior can occur because there are different requirements and one device has not checked for this possibility, such as by checking feature masks.
2.8. Ranges of values
Where a range is given (e.g. "the value is between 1 and 10", "in the range 7 to Nmax", or "Size: 1-31") then the range always includes both endpoints unless explicitly stated otherwise.
2.9. Type Names
The names defined in this section are used in the specification to indicate the type and representation of a value.
Values shall be stored in little-endian order. Except in arrays (see Section 2.9.2), a value of a given type shall be stored in the smallest number of octets that can contain the value; the value shall occupy the whole of each octet except the most significant bits of the last octet. All other bits in the last octet shall be reserved for future use. For example, if a value has a size of 22 bits, then it occupies 3 octets:
The 8 least significant bits (value7-0) are stored in the first octet.
The next 8 bits (value15-8) are stored in the middle octet.
The 6 most significant bits (value21-16) are stored in the 6 least significant bits of the last octet.
The 2 most significant bits of the last octet are reserved for future use.
Where a value appears in an SDP service record (see [Vol 3] Part B, Section 2.2), the octets representing the value shall be reversed in order to match the big-endian order used by SDP. The order of elements of an array shall be unchanged.
2.9.1. Basic types
The names uint#, where # is a decimal number other than zero, indicate an unsigned integer with the specified number of bits; therefore uint16 is an unsigned integer with 16 bits. The value shall be represented in binary, so uint16 has the range of values 0 to 65535.
The names sint#, where # is a decimal number other than 0 or 1, indicate a signed integer with the specified number of bits including sign; therefore sint12 is a signed integer with 12 bits. The value shall be represented in two’s-complement binary with the sign bit as the most significant bit, so sint12 has the range of values -2048 to +2047.
The name boolean indicates a single bit representing a truth value: a 0 bit represents false and a 1 bit represents true.
The names float#, where # is 16, 32, 64, 128, or 256, indicate a floating point number using the IEEE 754 interchange format with that number of bits.
The names medfloat16 and medfloat32 indicate the 16 and 32 bit floating point types defined in ISO/IEEE 11073-20601.
The names UUID16, UUID32, and UUID128 indicate the three lengths of UUID (see [Vol 3] Part B, Section 2.5.1). The name UUID indicates a UUID whose length is specified separately to the value.
2.9.2. Array types
Any basic type may be converted to an array type of a specific length. The name of the array type is formed from the name of the basic type by adding the length, in brackets, after the name. For example, sint12[3] indicates an array of 3 values, each of type sint12. Empty brackets indicate that the length of the array is specified elsewhere. The original type is called the base type of the array.
If the size of the base type is 1 bit, each group of 8 consecutive elements is packed into an octet starting at the least significant bit for the first value.
If the size of the base type is 2 bits, each group of 4 consecutive elements is packed into an octet using bits 1-0 for the first value, bits 3-2 for the second value, bits 5-4 for the third value, and bits 7-6 for the fourth value.
If the size of the base type is 3 bits, each consecutive pair of elements is packed into an octet using bits 2-0 for the first value and bits 5-3 for the second value; bits 6 and 7 of each octet are reserved for future use.
If the size of the base type is 4 bits, each consecutive pair of elements is packed into an octet using bits 3-0 for the first value and bits 7-4 for the second value.
If the number of elements is not a multiple of 8, 4, or 2 as appropriate, the bits of the last octet that are not occupied by values are reserved for future use.
If the size of the base type is 5 bits or more, each element of the array occupies separate octets.
For example, the type uint2[5] occupies two octets, with the first value occupying bits 1-0 of the first octet, the fourth value occupying bits 7-6 of the first octet, the last value occupying bits 1-0 of the second octet, and bits 7-2 of the second octet reserved for future use. The type sint12[3] occupies six octets in total, two for each element.
2.9.3. Variable length types
The name utf8s indicates a variable length array of octets holding a string encoded using UTF-8. A specific number of octets may be indicated by appending the number in braces to the type name, so utf8s{6} indicates an array of 6 octets. If the actual string is shorter than the size of the array, the first unused octet shall be zero. If the number in braces is followed by the letter “z”, the remaining octets shall also be zero. For example, the string “Café” is represented in the type utf8s{8z} by the octet sequence 0x43, 0x61, 0x66, 0xC3, 0xA9, 0x00, 0x00, 0x00. If a specific length is not indicated, the length is specified separately to the value.
The name utf16s indicates a variable length array of uint16 values holding a string encoded using UTF-16LE; the length is specified separately to the value.
The name struct indicates a variable length array of octets whose length and internal format are specified separately to the value.
2.10. Mathematical conventions
These conventions apply to how mathematical symbols are used in this specification, irrespective of how they are interpreted in any other context.
The operators +, −, ×, and ÷ have their usual meanings. Division is done using real numbers unless the result is being assigned to or used as an integer, in which case the quotient is rounded towards zero. The × operator is sometimes omitted if the meaning is clear. (This specification sometimes uses * instead of × for multiplication and / instead of ÷ for division. These uses are being phased out and can be treated as equivalent.)
The operator mod indicates the remainder from division; x mod y is the remainder when x is divided by y. It is only used with both operands being integers and y greater than zero. The division is rounded down so that the remainder is always non-negative; in other words, x mod y always equals .
The operators + and – have equal precedence. The operators ×, ÷, and mod have equal precedence, which is higher than that of + and −. Exponentiation has higher precedence than all of these operators. Expressions involving operators of equal precedence are evaluated from left to right. Precedence can be overridden using parentheses; unless clear from the context, brackets and braces are equivalent to parentheses and are used for clarity. Exponents and subscripts are evaluated separately as if they were in parentheses; for example, x2−y means x raised to the power 2 − y, not the square of x with y then subtracted.
Signed integers shall be represented as two’s complement.
Where a field, variable, parameter, or similar is specified as an integer with a specific number of bits B, then any requirement to store a value not representable in B bits shall be carried out by adding or subtracting 2B until the value is in range. In particular, adding 1 to an unsigned variable with value 2B − 1 results in setting it to zero.
The relational operators <, >, ≤, ≥, =, and ≠ have lower precedence than all arithmetic operators. Multiple relational operators are logically combined; e.g., x < y ≥ z means that x is required to be less than y and that y is required to be at least as great as z.
The bitwise operators NOT, AND, OR, and XOR are applied to each bit of their operands separately; for the last three, the operands will have the same number of bits.
The symbols in Table 2.1 have the meanings given in that table.
Symbol | Meaning |
|---|---|
the largest integer less than or equal to x | |
the smallest integer greater than or equal to x | |
the absolute value of x | |
the square root of x | |
min (x, y) | the minimum value of x and y; there can be more than two arguments |
max (x, y) | the maximum value of x and y; there can be more than two arguments |
any value v such that x − y ≤ v ≤ x + y; the precedence is the same as the + operator | |
logarithm base B of x | |
concatenation of bit sequences |
2.11. Requirement status symbols
In this document (such as in requirements tables), the following symbols are used:
“M” for mandatory to support or include.
“O” for optional to support or include. Where more than one item is optional, they are independent: each can be supported (or included) or not, irrespective of the choice made for any other item.
“C.#” for conditional support or inclusion (# represents any number or number followed by a letter); the condition will be defined nearby in terms of whether other items are supported or included.
“E” for excluded in this context; cannot be supported or included for this purpose, but the item can still be supported or included if allowed for some other purpose (e.g., a feature can be mandatory for one role and excluded for another; a device that supports both roles must support this feature).
“X” for reserved for future use; excluded in this context but might change status in a future version of this document.
2.12. Table structure
A blank cell in a table indicates that there is no useful information that can be placed in this cell. Examples of this are:
When there is no comment to make in a "comments" column
In a column specifying properties when the relevant item is reserved for future use (and therefore does not have any properties)
In a "units" column when the relevant item is unitless
Where an explicit absence is indicated, the cell will contain "none". Examples of this are:
In the "condition" column of the description of a finite state machine where a rule is unconditional
In the "action" column of the description of a finite state machine where a rule has no action
In a "restrictions" column where there are no applicable restrictions
In an interface description where there are no parameters of a specific type
3. Naming conventions
3.1. BR/EDR
This section is not currently used.
3.2. Bluetooth Low Energy
3.2.1. Link Layer PDUs
A consistent naming scheme is used for Link Layer PDUs to make their purpose and usage clearer.
The PDU name consists of up to five components. Each component is entirely uppercase. Those components that are present are separated by a single underscore (e.g., if only three of the five components are present, there are two underscores, not four). In order, these components are:
Where the PDU is used (optional)
When the PDU is used (mandatory)
What the PDU does (optional but usually present)
Version (optional)
How the PDU is used (mandatory)
The first component ("where") indicates which physical channel the PDU is used on. The values currently used are shown in Table 3.1.
Value | Meaning |
|---|---|
none | PDU is used on the primary advertising physical channel or any non-advertising physical channel |
AUX | PDU is used on the secondary advertising physical channel |
The second component ("when") indicates which kind of Link Layer procedure makes use of the PDU. The values currently used are shown in Table 3.2.
Value | Meaning | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
ADV | Normal Advertising | ||||||||||||||||||||||||||||||||||||||||||||||||
SYNC | Periodic Advertising | ||||||||||||||||||||||||||||||||||||||||||||||||
SCAN | Scanning | ||||||||||||||||||||||||||||||||||||||||||||||||
CONNECT | Connecting | ||||||||||||||||||||||||||||||||||||||||||||||||
CHAIN | Fragmented Data | ||||||||||||||||||||||||||||||||||||||||||||||||
LL | Control PDU on the Data logical transport | ||||||||||||||||||||||||||||||||||||||||||||||||
BIG | Control PDU in a Broadcast Isochronous Group on the isochronous logical transport | ||||||||||||||||||||||||||||||||||||||||||||||||
DATA | Reliable Data [Note 1] | ||||||||||||||||||||||||||||||||||||||||||||||||
CIS | Isochronous data PDU in a Connected Isochronous Stream | ||||||||||||||||||||||||||||||||||||||||||||||||
BIS | Isochronous data PDU in a Broadcast Isochronous Stream | ||||||||||||||||||||||||||||||||||||||||||||||||
[Note 1] This name is not currently used in the specification. | |||||||||||||||||||||||||||||||||||||||||||||||||
The third component ("what") distinguishes different PDUs that are found in the same context. While it is normally present, it is sometimes omitted where there is a "default" or "usual" case. This component may contain more than one word separated by underlines.
For example, the different cases for legacy advertising are shown in Table 3.3.
Value | Meaning |
|---|---|
none | Various |
DIRECT | Connectable directed |
NONCONN | Non-connectable and non-scannable undirected |
SCAN | Scannable undirected |
As another example, each Link Layer PDU has a value for this component based on the specific procedure it is used for.
The fourth component ("version") distinguishes between PDUs with the same purpose but different contents (usually because the original PDU was found to be insufficient to handle new features). The values currently used are shown in Table 3.4.
Value | Meaning |
|---|---|
none | Original version of the PDU |
EXT | Extended version of the PDU |
The fifth and final component ("how") indicates how the PDU fits into a procedure. The values currently used are shown in Table 3.5.
Value | Meaning |
|---|---|
IND | An indication that doesn’t expect a reply |
REQ | A request that expects a response |
RSP | A response to a request |
Some examples of this convention in use, showing how the PDU name breaks up into the five components, are given in Table 3.6. A blank cell indicates that the component is omitted.
PDU name | Components | ||||
|---|---|---|---|---|---|
where | when | what | version | how | |
ADV_IND | ADV | IND | |||
ADV_DIRECT_IND | ADV | DIRECT | IND | ||
ADV_EXT_IND | ADV | EXT | IND | ||
AUX_ADV_IND | AUX | ADV | IND | ||
AUX_CHAIN_IND | AUX | CHAIN | IND | ||
SCAN_REQ | SCAN | REQ | |||
AUX_SYNC_IND | AUX | SYNC | IND | ||
LL_PHY_UPDATE_IND | LL | PHY_UPDATE | IND | ||
LL_LENGTH_REQ | LL | LENGTH | REQ | ||
LL_LENGTH_RSP | LL | LENGTH | RSP | ||
LL_REJECT_IND | LL | REJECT | IND | ||
LL_REJECT_EXT_IND | LL | REJECT | EXT | IND | |
BIG_CHANNEL_MAP_IND | BIG | CHANNEL_MAP | IND | ||
Thus AUX_SYNC_IND is a PDU used for synchronous advertising on the secondary advertising physical channel that does not expect a response.