ESR10 v1.0

Errata Service
Release ESR10
Specification of the Bluetooth® System
Applies to:
v4.2
v4.1
v4.0
v3.0
v2.1
CSA3
CSA4
CSSv6
Profiles
Indicates:
Test Specification Impact
Publication Date: 06 December 2016

Errata Service Release to the Bluetooth Specification: ESR10 page 2
Revision History
Revision Date Comments
r01 18 May 2016 Initial Draft

r02 24 Jun 2016 Incorporated BARB comments
r03 12 Jul 2016 Added E7354, 7355, and 7372. Minor editorial fixes.
r04 14 Oct 2016 Added test spec impact table. Minor editorial fixes.
r05 17 Oct 2016 Removed TSE 7583, 7685, and 7557 from test impact table
r06 20 Oct 2016 Removed E6547
r07 10 Nov 2016 E7355: removed 4.1 and 4.0 from previous affected versions
r07 22 Nov 2016 Approved by BARB
v1.0 06 Dec 2016 Updated copyright. Adopted by the Bluetooth SIG BoD
Web Site
This Errata Service Release can also be found on the official Bluetooth web site:
https://www.bluetooth.com/specification/adopted-specifications
06 December 2016
Bluetooth SIG Proprietary
Use of this specification is your acknowledgement that you agree to and will comply with the
following notices and disclaimers. You are advised to seek appropriate legal, engineering, and
other professional advice regarding the use, interpretation, and effect of this specification.
Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership
and other related agreements between Bluetooth SIG and its members, including those agree-
ments posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this spec-
ification by a member that is not in compliance with the applicable membership and other
related agreements is prohibited and, among other things, may result in (i) termination of the
applicable agreements and (ii) liability for infringement of the intellectual property rights of Blue-
tooth SIG and its members.
Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is
an infringement of the intellectual property rights of Bluetooth SIG and its members. The fur-
nishing of this specification does not grant any license to any intellectual property of Bluetooth
SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG,
ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES
AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRAN-
TIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICU-
LAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF
ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation
as to third parties that may claim rights in or to any specifications or any intellectual property
that may be required to implement any specifications and it disclaims any obligation or duty to
do so.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS
MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR
RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN
THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS,
OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCI-
DENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE
THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILI-
ATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.
If this specification is a prototyping specification, it is solely for the purpose of developing and
using prototypes to verify the prototyping specifications at Bluetooth SIG sponsored IOP
events. Prototyping Specifications cannot be used to develop products for sale or distribution
and prototypes cannot be qualified for distribution.
Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combi-
nation, operation, use, implementation, and distribution may be subject to regulatory controls
under the laws and regulations of numerous countries that regulate products that use wireless
non-licensed spectrum. Examples include airline regulations, telecommunications regulations,
technology transfer controls and health and safety regulations. You are solely responsible for
complying with all applicable laws and regulations and for obtaining any and all required autho-
rizations, permits, or licenses in connection with your use of this specification and develop-
ment, manufacture, and distribution of Bluetooth Products. Nothing in this specification
provides any information or assistance in connection with complying with applicable laws or
regulations or obtaining required authorizations, permits, or licenses.
Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is
not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any
specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or
modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in
accordance with its membership and operating agreements.
Copyright © 1999 - 2016. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc.
All copyrights in the Bluetooth Specifications themselves are owned by Apple, Inc, Ericsson
AB, Lenovo (Singapore) Pte. Ltd., Intel Corporation, Microsoft Corporation, Nokia Corporation
and Toshiba Corporation. Other third-party brands and names are the property of their respec-
tive owners.
06 December 2016
NOTATIONS USED IN THIS DOCUMENT
Indication of inserted and deleted text:

• Text insertions are shown by green underlined text.
• Text deletions are shown by red strikethrough text.
• Unchanged text is black.
Indication when text is affected by more than one erratum:

When more than one erratum applies to a section, the secondary erratum is
shown as a link: “[E1234]”.
(The blue number is a link pointing to the erratum in question.)
Note that this document shows excerpts from the specification as they appear
in the final amended specification.
06 December 2016
TABLE OF CONTENTS
Notations used in this document ................................................................. 4
Part I
CORE SPECIFICATION ERRATA
Core Errata Index Tables
By Number: ........................................................................................... 9
By Core Specification Volume and Part: ............................................. 18
1 Core Specification Supplement [CSS] Errata.................................. 28
2 Global Changes - Affecting Several Parts ....................................... 30
3 [Vol 0] Part B: Compliance requirements ........................................ 32
4 [Vol 1] Part A: Architecture ............................................................... 35
5 [Vol 1] Part Bb: Acronyms................................................................. 44
6 [Vol 1] Part E: IEEE LANGUAGE....................................................... 45
7 [Vol 2] Part A: Radio Specification ................................................... 48
8 [Vol 2] Part B: Baseband Specification............................................ 53
9 [Vol 2] Part C: Link Manager Protocol ............................................. 66
10 [Vol 2] Part D: Error Codes ............................................................... 71
11 [Vol 2] Part E: Host Controller Interface .......................................... 73
12 [Vol 2] Part F: Message Sequence Charts ..................................... 125
13 [Vol 2] Part H: Security Specification............................................. 131
14 [Vol 3] Part A: L2CAP ...................................................................... 136
15 [Vol 3] Part B: Service Discovery Protocol.................................... 142
16 [Vol 3] Part C: Generic Access Profile (GAP)................................ 143
17 [Vol 3] Part D: Test Support ............................................................ 166
18 [Vol 3] Part F: Attribute Protocol (ATT) .......................................... 168
19 [Vol 3] Part G: Generic Attribute Profile (GATT)............................ 171
20 [Vol 3] Part H: Security Manager .................................................... 178
21 [Vol 4] Part B: USB Transport Layer .............................................. 187
22 [Vol 5] Part A: 802.11 Protocol Adaptation Layer.......................... 188
23 [Vol 6] Part A: Physical Layer Specification .................................. 190
24 [Vol 6] Part B: Link Layer Specification......................................... 192
25 [Vol 6] Part C: Sample Data............................................................. 217
26 [Vol 6] Part D: Message Sequence Charts..................................... 218
06 December 2016
27 [Vol 6] Part F: Direct Test Mode...................................................... 223

28 [Vol 7] Part A: MWS Coexistence Logical Signaling .................... 227
29 [Vol 7] Part B: Wireless Coexistence Interface 1 (WCI-1) Transport
Specification .................................................................................... 228
30 [Vol 7] Part C: Wireless Coexistence Interface 2 (WCI-2) Transport
Specification .................................................................................... 229
Part II
GATT-BASED PROFILES & SERVICES ERRATA
Profile Errata Index Tables
By Number: ....................................................................................... 231
By Profile Name: ............................................................................... 231
1 Automation IO Service (AIOS) ........................................................ 233
2 Continuous Glucose Monitoring Profile (CGMP).......................... 234
3 Continuous Glucose Monitoring SystemService (CGMS) ........... 235
4 Current Time Service (CTS) ............................................................ 236
5 Device Information Service (DIS) ................................................... 237
6 Environmental Sensing Service (ESS)........................................... 238
7 Find Me Profile (FMP) ...................................................................... 239
8 Glucose Profile (GLP)...................................................................... 240
9 Immediate Alert Service (IAS)......................................................... 241
10 Internet Protocol Support Profile (IPSP)........................................ 242
11 Object Transfer Service (OTS) ........................................................ 243
Part III
TRADITIONAL PROFILES ERRATA
Profile Errata Index Tables
By Number: ....................................................................................... 245
By Profile Name: ............................................................................... 247
1 AUDIO/VIDEO REMOTE CONTROL PROFILE (AVRCP)................ 249
2 Basic Printing Profile (BPP)............................................................ 253
3 Calendar, Tasks and Notes Profile (CTN) ...................................... 254
4 Dial-up networkING PROFILE (DUN).............................................. 257
5 Generic Object Exchange Profile (GOEP) ..................................... 259
6 Health Device Profile (HDP) ............................................................ 260
7 Hands-Free Profile (HFP) ................................................................ 262
8 Human Interface DesignDevice Profile (HID) ................................ 266
06 December 2016
9 IrDA Interoperability (IRDA) ............................................................ 273

10 Message Access Profile (MAP)....................................................... 274
11 Phone Book Access Profile (PBAP)............................................... 278
Part IV
TEST SPECIFICATION IMPACT
Index Tables
By Number: ....................................................................................... 283
By Core Specification Volume and Part: ........................................... 283
1 TSE Mapping Table .......................................................................... 284
06 December 2016
Errata Service Release ESR10
Part I
PART I: CORE SPECIFICATION

ERRATA

Errata Service Release to the Bluetooth Specification: ESR10 [Part I] page 9
Core Specification Errata
CORE ERRATA INDEX TABLES
By Number:
Erratum Volume/Part Versions affected
E3548 Vol 3, Part A 4.2 4.1 4.0 3.0
E4165 Vol 4, Part B 4.2 4.1 4.0 3.0 2.1
E4243 Vol 3, Part F 4.2 4.1 4.0
E4348 Vol 3, Part C 4.2 4.1 4.0 3.0 2.1
E4654 Vol 3, Part G 4.2
E4761 Vol 2, Part E 4.0 3.0 2.1
E4777 Vol 3, Part C 4.2 4.1 4.0 3.0 2.1
E4783 Vol 2, Part C 4.2 4.1 4.0 3.0
E4796 Vol 3, Part H 4.2 4.1 4.0
E4872 Vol 3, Part C 4.0
E4919 Vol 3, Part C 4.2 4.1 4.0
E4999 Vol 2, Part E 4.2 4.1 4.0 CSA3
E5002 Vol 7, Part A 4.2 4.1 CSA3
E5003 Vol 2, Part E 4.2 4.1 CSA3
E5089 Vol 2, Part F 4.2 4.1 4.0 3.0 2.1
E5107 Vol 3, Part F 4.2 4.1 4.0
E5110 Vol 3, Part C 4.2 4.1 4.0
E5242 Vol 3, Part G 4.2 4.1 4.0
E5359 Vol 3, Part G 4.2 4.1 4.0
E5383 Vol 3, Part G 4.2 4.1 4.0
E5399 Vol 3, Part C 4.2 4.1
E5407 Vol 3, Part C 4.2 4.1 4.0
E5418 Vol 3, Part C 4.2 4.1
E5433 Vol 3, Part C 4.2
06 December 2016
E5435 Vol 3, Part C 4.2 4.1 4.0 3.0 2.1
E5610 Vol 3, Part F 4.2 4.1 4.0 3.0 2.1
E5708 Vol 3, Part C 4.2 4.1
E5717 Vol 3, Part G 4.2 4.1
E5718 Vol 3, Part G 4.2 4.1 4.0
E5719 Vol 3, Part G 4.2 4.1 4.0
E5778 Vol 3, Part C 4.2 4.1 4.0
E5791 Vol 2, Part H 4.2 4.1 4.0 3.0 2.1
E5792 Vol 2, Part H 4.2 4.1 4.0 3.0 2.1
E5809 Vol 6, Part C 4.2 4.1 4.0
E5882 Vol 2, Part H 4.2 4.1
E5919 Vol 3, Part F 4.2 4.1 4.0
E6007 Vol 2, Part E 4.2 4.1 4.0
E6098 Vol 3, Part F 4.2 4.1 4.0
E6182 Vol 2, Part E 4.2
E6182 Vol 6, Part B 4.2
E6199 Vol 2, Part A 4.2 4.1 4.0 3.0 2.1
E6214 Vol 3, Part C 4.2
E6218 Vol 2, Part F 4.2 4.1 4.0 3.0 2.1
E6219 Vol 3, Part H 4.2 4.1 4.0
E6228 Vol 6, Part A 4.2 4.1 4.0
E6247 Vol 2, Part E 4.2
E6264 Vol 4, Part A 4.2 4.1 4.0 3.0 2.1
E6352 Vol 1, Part A 4.2 4.1 4.0
E6352 Vol 2, Part E 4.2 4.1 4.0
E6352 Vol 3, Part C 4.2 4.1 4.0
E6352 Vol 6, Part B 4.2 4.1 4.0
06 December 2016
E6356 Vol 1, Part A 4.2 4.1
E6356 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6356 Vol 3, Part C 4.2 4.1 4.0
E6356 Vol 6, Part B 4.2
E6360 Vol 0, Part B 4.2 4.1 4.0
E6399 Vol 2, Part E 4.2
E6401 Vol 3, Part C 4.2
E6417 Vol 3, Part A 4.2 4.1 4.0 3.0 2.1
E6421 Vol 1, Part A 4.2 4.1 4.0 3.0 2.1 CSA4
E6421 Vol 1, Part E 4.2 4.1 4.0 3.0 2.1 CSA4
E6421 Vol 2, Part D 4.2 4.1 4.0 3.0 2.1 CSA4
E6421 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1 CSA4
E6421 Vol 3, Part B 4.2 4.1 4.0 3.0 2.1 CSA4
E6421 Vol 3, Part C 4.2 4.1 4.0 3.0 2.1 CSA4
E6421 Vol 3, Part D 4.2 4.1 4.0 3.0 2.1 CSA4
E6421 Vol 3, Part H 4.2 4.1 4.0 3.0 2.1 CSA4
E6421 Vol 5, Part A 4.2 4.1 4.0 3.0 2.1 CSA4
E6421 Vol 6, Part B 4.2 4.1 4.0 3.0 2.1 CSA4
E6422 Vol 1, Part E 4.2 4.1 4.0 3.0 2.1
E6428 Vol 2, Part F 4.2 4.1 4.0 3.0 2.1
E6436 Vol 3, Part H 4.2 4.1 4.0
E6439 Vol 3, Part C 4.2
E6443 Vol 2, Part B 4.2
E6443 Vol 6, Part B 4.2
E6446 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6447 Vol 2, Part C 4.2 4.1 4.0 3.0 2.1
E6451 Vol 2, Part E 4.2 4.1 4.0 3.0
06 December 2016
E6452 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6455 Vol 6, Part B 4.2 4.1
E6465 Vol 1, Part A 4.2 4.1 4.0 3.0 CSA4
E6469 Vol 6, Part B 4.2
E6471 Vol 6, Part B 4.2
E6480 Vol 2, Part B 4.2
E6480 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6480 Vol 2, Part H 4.2
E6480 Vol 3, Part A 4.2
E6480 Vol 6, Part F 4.2 4.1
E6493 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6502 Vol 3, Part C 4.2 4.1 4.0
E6505 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6508 Vol 2, Part E 4.2
E6510 Vol 3, Part C 4.2 4.1
E6517 Vol 6, Part B 4.2 4.1 4.0
E6518 Vol 6, Part B 4.2 4.1
E6523 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6524 Vol 1, Part A 4.2
E6525 Vol 3, Part D 4.2 4.1 4.0
E6528 CSSv6
E6529 Vol 1, Part A 4.2 4.1 4.0
E6531 Vol 2, Part B 4.2 4.1
E6531 Vol 2, Part C 4.2 4.1
E6531 Vol 2, Part E 4.2 4.1
E6531 Vol 2, Part F 4.2 4.1
E6531 Vol 6, Part B 4.2 4.1
06 December 2016
E6532 Vol 2, Part E 4.2 4.1
E6534 Vol 2, Part E 4.2 4.1 CSA4
E6536 Vol 2, Part E 4.2 4.1 CSA4
E6537 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1 CSA4
E6541 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6553 Vol 2, Part E 4.2
E6553 Vol 6, Part B 4.2
E6556 Vol 2, Part E 4.2 4.1 4.0 CSA4
E6558 Vol 1, Part A 4.2 4.1 4.0 3.0 2.1
E6559 Vol 2, Part E 4.2 4.1 4.0
E6563 Vol 2, Part E 4.2 4.1 4.0
E6563 Vol 6, Part D 4.2 4.1 4.0
E6566 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6567 Vol 3, Part A 4.2 4.1 4.0
E6568 Vol 2, Part E 4.2 4.1 4.0
E6570 Global 4.2 4.1 4.0 3.0 2.1
E6574 Vol 3, Part C 4.2
E6575 Vol 3, Part C 4.2 4.1 4.0
E6575 Vol 3, Part F 4.2 4.1 4.0
E6575 Vol 3, Part G 4.2 4.1 4.0
E6576 Vol 2, Part E 4.2 4.1 4.0
E6577 Vol 6, Part B 4.2
E6582 Vol 3, Part G 4.2 4.1
E6586 Vol 6, Part B 4.2 4.1 4.0
E6599 Vol 3, Part C 4.2
E6603 Vol 1, Part A 4.2 4.1
E6604 Vol 1, Part A 4.2 4.1 4.0 3.0 2.1
06 December 2016
E6606 Vol 2, Part C 4.2 4.1 4.0 3.0 2.1
E6610 CSSv6
E6618 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1 CSA4
E6619 Vol 6, Part F 4.2 4.1
E6629 Vol 2, Part E 4.2
E6646 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6647 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6664 Vol 6, Part B 4.2
E6668 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1 CSA4
E6672 Global 4.2 4.1 4.0
E6689 Vol 2, Part E 4.2
E6694 Vol 1, Part E 4.2 4.1 4.0 3.0 2.1
E6695 CSSv6
E6697 Vol 6, Part B 4.2 4.1 4.0
E6702 Vol 3, Part A 4.2 4.1
E6709 Vol 2, Part E 4.2
E6710 Vol 6, Part B 4.2 4.1 4.0
E6714 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6716 Vol 2, Part E 4.2 4.1
E6717 Vol 0, Part B 4.2 4.1 4.0
E6717 Vol 1, Part B 4.2 4.1 4.0
E6721 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6722 Vol 2, Part E 4.2 4.1 CSA4
E6729 Vol 3, Part H 4.2
E6732 Vol 3, Part C 4.2 4.1 4.0
E6733 Vol 6, Part B 4.2 4.1 4.0
E6734 Vol 6, Part B 4.2 4.1 4.0
06 December 2016
E6735 Vol 2, Part C 4.2 4.1 4.0 3.0 2.1
E6745 Vol 3, Part C 4.2 4.1
E6749 Vol 2, Part B 4.2 4.1 CSA4
E6749 Vol 2, Part E 4.2 4.1 CSA4
E6751 Global 4.2 4.1 4.0 3.0 2.1 CSA4
E6752 Vol 2, Part E 4.2 4.1 4.0
E6764 Vol 3, Part C 4.2 4.1 4.0
E6766 Vol 1, Part A 4.2
E6767 Vol 2, Part E 4.2
E6773 Vol 2, Part C 4.2 4.1 4.0 3.0 2.1
E6776 Vol 2, Part C 4.2 4.1 4.0 3.0 2.1
E6793 Vol 6, Part F 4.2 4.1 4.0
E6796 Vol 3, Part H 4.2
E6797 Vol 2, Part E 4.2 4.1 4.0
E6807 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6821 Vol 6, Part B 4.2 4.1
E6824 Vol 3, Part H 4.2
E6847 Vol 6, Part B 4.2 4.1 4.0
E6847 Vol 6, Part D 4.2 4.1 4.0
E6852 Vol 2, Part C 4.2 4.1 4.0 3.0 2.1
E6855 Global 4.2 4.1 4.0 3.0 2.1
E6855 Global 4.2 4.1 4.0
E6856 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6857 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6882 Vol 2, Part E 4.2 4.1 4.0
E6886 Vol 2, Part E 4.2 4.1 CSA4
E6897 Vol 3, Part C 4.2
06 December 2016
E6898 Vol 3, Part A 4.2 4.1 4.0 3.0
E6902 Vol 2, Part H 4.2 4.1
E6906 Vol 2, Part H 4.2 4.1
E6907 Vol 2, Part H 4.2 4.1
E6910 Vol 2, Part E 4.2 4.1 4.0 3.0
E6913 Vol 6, Part B 4.2 4.1 4.0
E6914 Vol 2, Part E 4.2 4.1 4.0
E6915 Vol 7, Part B 4.2 4.1
E6915 Vol 7, Part C 4.2 4.1
E6918 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6922 Vol 1, Part A 4.2 4.1 4.0 3.0
E6927 Vol 2, Part E 4.2 4.1
E6939 Vol 2, Part E 4.2 4.1 4.0
E6939 Vol 3, Part A 4.2 4.1 4.0
E6939 Vol 6, Part B 4.2 4.1 4.0
E6946 Vol 3, Part H 4.2 4.1 4.0
E6947 Vol 6, Part B 4.2
E6953 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6962 Vol 6, Part B 4.2 4.1 4.0
E6963 Vol 6, Part B 4.2 4.1 4.0
E6964 Vol 2, Part B 4.2 4.1 4.0 3.0 2.1
E6984 Vol 6, Part B 4.2
E6986 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6997 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E6998 Vol 2, Part E 4.2 4.1 4.0
E7003 Vol 6, Part B 4.2
E7005 Vol 6, Part F 4.2 4.1
06 December 2016
E7008 CSSv6
E7017 Vol 2, Part E 4.2
E7019 CSSv6
E7021 Vol 2, Part E 4.2 4.1 4.0
E7024 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E7025 Vol 6, Part B 4.2
E7028 Vol 3, Part G 4.2 4.1 4.0
E7029 Vol 6, Part F 4.2 4.1
E7030 Vol 1, Part A 4.2 4.1 4.0
E7031 Vol 1, Part A 4.2 4.1 4.0
E7032 Vol 3, Part C 4.2 4.1 4.0
E7033 Vol 3, Part C 4.2 4.1 4.0
E7034 Vol 6, Part B 4.2 4.1 4.0
E7036 Vol 5, Part A 4.2 4.1 4.0 3.0
E7045 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E7065 Vol 3, Part G 4.2 4.1 4.0
E7066 Vol 3, Part G 4.2 4.1 4.0
E7067 Vol 2, Part E 4.2 4.1 4.0 3.0
E7068 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1
E7069 Vol 2, Part E 4.2 4.1 4.0 3.0 2.1 CSA4
E7072 Vol 3, Part G 4.2 4.1 4.0
E7075 Vol 3, Part D 4.2 4.1 4.0 3.0 2.1
E7076 Global 4.2 4.1 4.0
E7077 Vol 2, Part E 4.2
E7080 Vol 6, Part B 4.2 4.1
E7081 Vol 6, Part B 4.2 4.1
E7106 Vol 6, Part B 4.2 4.1
06 December 2016
E7301 Vol 1, Part A 4.2
E7301 Vol 3, Part H 4.2 4.1 4.0
E7354 Vol 3, Part C 4.2 4.1
E7355 Vol 3, Part C 4.2
E7372 Vol 2, Part E 4.2
E7461 Vol 3, Part H 4.2
E7521 Vol 1, Part E 4.2 4.1 4.0 3.0 2.1
By Core Specification Volume and Part:
Volume/Part Section Erratum Versions affected
1 E7019
1.1.1 E6695
CSSv6
1.3.1 E6610
Part A
1.5.1 E6528
1.9.1 E7008
Various E6570 4.2 4.1 4.0 3.0 2.1
Various E6672 4.2 4.1 4.0

Global
Various E6751 4.2 4.1 4.0 3.0 2.1 CSA4
Several Parts
Various E6855 4.2 4.1 4.0 3.0 2.1
Various E6855 4.2 4.1 4.0
Vol 0, Part B 3.1 E6717 4.2 4.1 4.0

Compliance
Requirements 4.5 E6360 4.2 4.1 4.0
1.4 E6352 4.2 4.1 4.0
1.4 E6603 4.2 4.1

Vol 1, Part A
Architecture
2 E6421 4.2 4.1 4.0 3.0 2.1 CSA4
3.1.3.2 E6558 4.2 4.1 4.0 3.0 2.1
06 December 2016
3.2 E6465 4.2 4.1 4.0 3.0 CSA4
3.2 E6922 4.2 4.1 4.0 3.0
3.3 E6604 4.2 4.1 4.0 3.0 2.1
3.5.4.6 E6529 4.2 4.1 4.0
3.5 E7030 4.2 4.1 4.0

Vol 1, Part A
Architecture
3.5 E7031 4.2 4.1 4.0
5.3 E6524 4.2
5.4.5 E6356 4.2 4.1
5.4.5 E6766 4.2
5.1 E7301 4.2
Vol 1, Part B
1 E6717 4.2 4.1 4.0
Acronyms
1.5 E6421 4.2 4.1 4.0 3.0 2.1 CSA4
1.1 E7521 4.2 4.1 4.0 3.0 2.1

Vol 1, Part E
IEEE Language
2 E6422 4.2 4.1 4.0 3.0 2.1
2.5 E6694 4.2 4.1 4.0 3.0 2.1
Vol 2, Part A
1 E6199 4.2 4.1 4.0 3.0 2.1
Radio Specification
1.1 E6537 4.2 4.1 4.0 3.0 2.1 CSA4
1.2 E6443 4.2
2 E6668 4.2 4.1 4.0 3.0 2.1 CSA4
2.2.4 E6480 4.2

Vol 2, Part B
2.5.4 E6964 4.2 4.1 4.0 3.0 2.1
Baseband
2.7.3 E6749 4.2 4.1 CSA4
3.2 E6531 4.2 4.1
7.2 E6714 4.2 4.1 4.0 3.0 2.1
7.6.1 E6953 4.2 4.1 4.0 3.0 2.1
06 December 2016
8.2 E6721 4.2 4.1 4.0 3.0 2.1
8.3.1 E6480 4.2 4.1 4.0 3.0 2.1
8.6.5 E6446 4.2 4.1 4.0 3.0 2.1
8.6.3 E6505 4.2 4.1 4.0 3.0 2.1

Vol 2, Part B
Baseband
8.6.3 E6523 4.2 4.1 4.0 3.0 2.1
8.6.4 E6618 4.2 4.1 4.0 3.0 2.1 CSA4
8.6.5 E6646 4.2 4.1 4.0 3.0 2.1
8.6.5 E6647 4.2 4.1 4.0 3.0 2.1
2.5 E6852 4.2 4.1 4.0 3.0 2.1
4.1.3.1.2 E4783 4.2 4.1 4.0 3.0
4.1.14 E6531 4.2 4.1
Vol 2, Part C 4.2.4 E6735 4.2 4.1 4.0 3.0 2.1

Link Manager
Protocol (LMP) 4.4.1 E6447 4.2 4.1 4.0 3.0 2.1
4.4.1 E6776 4.2 4.1 4.0 3.0 2.1
4.5.3.1 E6606 4.2 4.1 4.0 3.0 2.1
5.1 E6773 4.2 4.1 4.0 3.0 2.1
Vol 2, Part D
2.1 E6421 4.2 4.1 4.0 3.0 2.1 CSA4
Error Codes
7.3.23 E4761 4.0 3.0 2.1
7.3.85 E4999 4.2 4.1 4.0 CSA3
7.5.11 E5003 4.2 4.1 CSA3
3.3 E6007 4.2 4.1 4.0

Vol 2, Part E
Host Controller 7.8.10 E6182 4.2
Interface
7.7.65.11 E6247 4.2
3.5 E6352 4.2 4.1 4.0
3.14 E6356 4.2 4.1 4.0 3.0 2.1
7.8.9 E6399 4.2
06 December 2016
4.5 E6421 4.2 4.1 4.0 3.0 2.1 CSA4
7.3.74 E6451 4.2 4.1 4.0 3.0
4.1.1 E6452 4.2 4.1 4.0 3.0 2.1
6.1 E6493 4.2 4.1 4.0 3.0 2.1
3.19 E6508 4.2
3.16 E6531 4.2 4.1
7.3.93 E6532 4.2 4.1
6.37 E6534 4.2 4.1 CSA4
7.1.52 E6536 4.2 4.1 CSA4
4.3 E6541 4.2 4.1 4.0 3.0 2.1
7.7.65.7 E6553 4.2
4.5 E6556 4.2 4.1 4.0
Vol 2, Part E 7.8.14 E6559 4.2 4.1 4.0

Host Controller
Interface 7.7.65.1 E6563 4.2 4.1 4.0
7.1.6 E6566 4.2 4.1 4.0 3.0 2.1
7.8.8 E6568 4.2 4.1 4.0
7.1.41 E6576 4.2 4.1 4.0
7.7.65.11 E6629 4.2
7.8.34 E6689 4.2
7.7.65.11 E6709 4.2
3.19 E6716 4.2 4.1
7.5.12 E6722 4.2 4.1 CSA4
6.37 E6749 4.2 4.1 CSA4
7.4.5 E6752 4.2 4.1 4.0
5 E6767 4.2
3.5 E6797 4.2 4.1 4.0
06 December 2016
3 E6807 4.2 4.1 4.0 3.0 2.1
5.4.2 E6856 4.2 4.1 4.0 3.0 2.1
5.4.3 E6857 4.2 4.1 4.0 3.0 2.1
4.4.1 E6882 4.2 4.1 4.0
7.7.66 E6886 4.2 4.1 CSA4
3.14 E6910 4.2 4.1 4.0 3.0
7.8.11 E6914 4.2 4.1 4.0
7.3.47 E6918 4.2 4.1 4.0 3.0 2.1
7.1.47 E6927 4.2 4.1
7.8.12 E6939 4.2 4.1 4.0
Vol 2, Part E 6.10 E6986 4.2 4.1 4.0 3.0 2.1

Host Controller
Interface 7.7.16 E6997 4.2 4.1 4.0 3.0 2.1
3.19 E6998 4.2 4.1 4.0
7.8.33 E7017 4.2
3.5 E7021 4.2 4.1 4.0
4.4 E7024 4.2 4.1 4.0 3.0 2.1
A.2 E7045 4.2 4.1 4.0 3.0 2.1
7.1.40 E7067 4.2 4.1 4.0 3.0
7 E7068 4.2 4.1 4.0 3.0 2.1
7 E7069 4.2 4.1 4.0 3.0 2.1 CSA4
7.8.5 E7077 4.2
7.8.12 E7372 4.2
4.7 E5089 4.2 4.1 4.0 3.0 2.1
Vol 2, Part F 4.7 E6218 4.2 4.1 4.0 3.0 2.1

Message Sequence
Charts 8.1 E6428 4.2 4.1 4.0 3.0 2.1
9 E6531 4.2 4.1
06 December 2016
7.7.1 E5791 4.2 4.1 4.0 3.0 2.1
7.2.2 E5792 4.2 4.1 4.0 3.0 2.1
7.7.4 E5882 4.2 4.1

Vol 2, Part H
Security 3.1 E6480 4.2
Specification
9 E6902 4.2 4.1
9.2 E6906 4.2 4.1
9.2 E6907 4.2 4.1
8.6.5.2 E3548 4.2 4.1 4.0 3.0
4.3 E6417 4.2 4.1 4.0 3.0 2.1
5.3 E6480 4.2

Vol 3, Part A
4.20 E6567 4.2 4.1 4.0
L2CAP
4.24 E6702 4.2 4.1
7.2.1 E6898 4.2 4.1 4.0 3.0
4.20 E6939 4.2 4.1 4.0
Vol 3, Part B
Service Discovery 2.4.1 E6421 4.2 4.1 4.0 3.0 2.1 CSA4
Protocol
5.2.2.6 E4348 4.2 4.1 4.0 3.0 2.1
4.3.1.1 E4777 4.2 4.1 4.0 3.0 2.1
11.1.8 E4872 4.0
10.3.1 E4919 4.2 4.1 4.0
Vol 3, Part C 10.4.1 E5110 4.2 4.1 4.0

Generic Access
Profile (GAP) 13.2 E5399 4.2 4.1
9.4.4.2 E5407 4.2 4.1 4.0
10.7.2 E5418 4.2 4.1
9.3.1 E5433 4.2
12 E5435 4.2 4.1 4.0 3.0 2.1
06 December 2016
5.2.2 E5708 4.2 4.1
9.2.3.2 E5778 4.2 4.1 4.0
9.3.7.2 E6214 4.2
9.3.6.2 E6352 4.2 4.1 4.0
10.7 E6356 4.2 4.1 4.0
12 E6401 4.2
10.4.2 E6421 4.2 4.1 4.0 3.0 2.1 CSA4
10.2.1 E6439 4.2
5.2.2.3 E6502 4.2 4.1 4.0
3.2.5.1 E6510 4.2 4.1

Vol 3, Part C
Generic Access 12.4 E6574 4.2
Profile (GAP)
1.2.4 E6575 4.2 4.1 4.0
10.7 E6599 4.2
9.2.2.2 E6732 4.2 4.1 4.0
12 E6745 4.2 4.1
9.3.9.2 E6764 4.2 4.1 4.0
10.3.1 E6897 4.2
16 E7032 4.2 4.1 4.0
2.2.2.3 E7033 4.2 4.1 4.0
12 E7355 4.2
12.5 E7354 4.2 4.1
1.2.1 E6421 4.2 4.1 4.0 3.0 2.1 CSA4

Vol 3, Part D
1.1.3 E6525 4.2 4.1 4.0
Test Support
1.1.2.2 E7075 4.2 4.1 4.0 3.0 2.1
3.4.5.4 E4243 4.2 4.1 4.0

Vol 3, Part F
Attribute Protocol 3.4.4.10 E5107 4.2 4.1 4.0
(ATT)
3.4.6.3 E5610 4.2 4.1 4.0 3.0 2.1
06 December 2016
3.2.5 E5919 4.2 4.1 4.0

Vol 3, Part F
Attribute Protocol 3.4.1.1 E6098 4.2 4.1 4.0
(ATT)
1.3 E6575 4.2 4.1 4.0
3.3.3.5.2 E4654 4.2
3.3.1.1 E5242 4.2 4.1 4.0
7.1 E5359 4.2 4.1 4.0
2.5.1 E5383 4.2 4.1 4.0
4.8.3 E5717 4.2 4.1
4.8.2 E5718 4.2 4.1 4.0

Vol 3, Part G
Generic Attribute 4.8.1 E5719 4.2 4.1 4.0
Profile (GATT)
1.5 E6575 4.2 4.1 4.0
4.4.2 E6582 4.2 4.1
4.10.1 E7028 4.2 4.1 4.0
3.3.3.3 E7065 4.2 4.1 4.0
3.3.3.4 E7066 4.2 4.1 4.0
3.3 E7072 4.2 4.1 4.0
3.4 E4796 4.2 4.1 4.0
3.4 E6219 4.2 4.1 4.0
B.2.2 E6421 4.2 4.1 4.0 3.0 2.1 CSA4
3.6.1 E6436 4.2 4.1 4.0
3.6.1 E6729 4.2

Vol 3, Part H
Security Manager
2.3.5.6.4 E6796 4.2
3.5.5 E6824 4.2
3.5.1 E7461 4.2
B.2.2 E6946 4.2 4.1 4.0
2.2 E7301 4.2 4.1 4.0
06 December 2016
Vol 4, Part A
UART Transport 2 E6264 4.2 4.1 4.0 3.0 2.1
Layer
Vol 4, Part B
4 E4165 4.2 4.1 4.0 3.0 2.1
USB Transport Layer
2.14.7 E6421 4.2 4.1 4.0 3.0 2.1 CSA4

Vol 5, Part A
802.11 PAL
3.5.5 E7036 4.2 4.1 4.0 3.0
Vol 6, Part A
Physical Layer 1 E6228 4.2 4.1 4.0
Specification
1.3 E6182 4.2
4.4.3 E6352 4.2 4.1 4.0
4.7 E6356 4.2
4.5.1 E6421 4.2 4.1 4.0 3.0 2.1 CSA4
1.3.1 E6443 4.2
5.3 E6455 4.2 4.1
6.2.1 E6469 4.2
6.3 E6471 4.2
3.2 E6517 4.2 4.1 4.0

Vol 6, Part B
5.1.8 E6518 4.2 4.1
Link Layer
5.4 E6531 4.2 4.1
4.5.10 E6553 4.2
5.1.9 E6577 4.2
4.4.2.3 E6586 4.2 4.1 4.0
5.1.9 E6664 4.2
4.6 E6697 4.2 4.1 4.0
1.1.1 E6710 4.2 4.1 4.0
4.5.3 E6733 4.2 4.1 4.0
4.5.1 E6734 4.2 4.1 4.0
06 December 2016
2.4.2.17 E6821 4.2 4.1
4.4.2.3 E6847 4.2 4.1 4.0
4.4.3 E6913 4.2 4.1 4.0
4.5.1 E6939 4.2 4.1 4.0
4.5.10 E6947 4.2
5.1.1 E6962 4.2 4.1 4.0
4.4.3.2 E6963 4.2 4.1 4.0

Vol 6, Part B
Link Layer
6.2.1 E6984 4.2
7.1 E7003 4.2
4.3.3 E7025 4.2
5.5 E7034 4.2 4.1 4.0
2.3 E7080 4.2 4.1
5.3 E7081 4.2 4.1
5.3 E7106 4.2 4.1
Vol 6, Part C
1.2 E5809 4.2 4.1 4.0
Sample Data
Vol 6, Part D 5.5 E6563 4.2 4.1 4.0

Message Sequence
Charts 5.3 E6847 4.2 4.1 4.0
4.1.5 E6480 4.2 4.1
4.1.6 E6619 4.2 4.1

Vol 6, Part F
3.2 E6793 4.2 4.1 4.0
Direct Test Mode
4.1.5 E7005 4.2 4.1
4.1.6 E7029 4.2 4.1
Vol 7, Part A
MWS Coexistence 2.1.5 E5002 4.2 4.1 CSA3
Logical Signaling
Vol 7, Part B
1 E6915 4.2 4.1
WCI-1
06 December 2016
Vol 7, Part C
1 E6915 4.2 4.1
WCI-2
06 December 2016
1 CORE SPECIFICATION SUPPLEMENT [CSS] ERRATA
1.1 E7019 – Wording and consistency in data types desc
Erratum Added to: Section(s) affected:
E7019 CSSv6 Part A 1 Data Types Definitions and Formats
EDITOR’S NOTE: Add text to the first paragraph as shown below.
This part defines the basic data types used for Extended Inquiry Response
(EIR), Advertising Data (AD), Scan Response Data, and OOB data blocks. All
data types defined here may be used for EIR or AD data types unless stated
otherwise. All data types may be used multiple times in the same packet unless
otherwise stated. Additional data types may be defined in profile specifications.
[End of changes for E7019]
1.2 E6695 – Missing hyphens
E6695 CSSv6 Part A 1.1.1 Description [1.1 Service UUID]
EDITOR’S NOTE: Add missing hyphens in the last two paragraphs.

[...] If a device has no Service UUIDs of a certain size, 16-, 32-, or 128-bit, the
corresponding [...]
16-bit and 32-bit UUIDs shall [...] may assign 16-bit and 32-bit UUIDs [...]
1.3 E6610 – Problem in interpreting advertisements without

FLAGS AD type
E6610 CSSv6 Part A 1.3.1 Description [1.3 Flags]
EDITOR’S NOTE: After the first paragraph, add the following note.
Core Specification Supplement [CSS] Errata 06 December 2016

Note: If the Flags AD type is not present in a non-connectable advertisement,

the Flags should be considered as unknown and no assumptions should be
made by the scanner.
1.4 E6528 – Advertised Tx power
E6528 CSSv6 Part A 1.5.1 Description [1.5 TX Power Level]
EDITOR’S NOTE: Add a sentence in the first paragraph.

The TX Power Level data type indicates the transmitted power level of the
packet containing the data type. The TX Power Level should be the radiated
power level. The TX Power Level data type may be used to calculate path loss
on a received packet using the following equation:
1.5 E7008 – Wrong section index
E7008 CSSv6 Part A 1.9.1 Description
EDITOR’S NOTE: Change 12.5 to 12.3

The Slave Connection Interval Range data type contains the Peripheral’s pre-
ferred connection interval range, for all logical connections. See Vol 3, Part C,
Section 12.53.
Core Specification Supplement [CSS] Errata 06 December 2016

2 GLOBAL CHANGES - AFFECTING SEVERAL PARTS
2.1 E6570 – Inconsistent spelling of the word: signalling
Erratum Apply to version(s) Part(s) in Core Specification Reference
E6570 4.2 4.1 4.0 3.0 2.1 Global Several Parts
Core Section(s) affected: Various
EDITOR’S NOTE: Change all instances of “signaling” to “signalling”
2.2 E6672 – Rename certain PDUs
E6672 4.2 4.1 4.0 Global Several Parts
EDITOR’S NOTE: Rename PDUs in body text, tables, and figures
Original PDU New PDU
LL_CONNECTION_UPDATE_REQ LL_CONNECTION_UPDATE_IND
LL_CHANNEL_MAP_REQ LL_CHANNEL_MAP_IND
LL_REJECT_IND_EXT LL_REJECT_EXT_IND
CONNECT_REQ CONNECT_IND
2.3 E6751 – SI rules relating to seconds
E6751 4.2 4.1 4.0 3.0 2.1, Global Several Parts

CSA4
Global Changes - Affecting Several Parts 06 December 2016

EDITOR’S NOTE: Change SI rules as shown below
Original Change to
µsec µs
msec ms
sec s
secs seconds
Also in Volume 2 Part E Sections 6 and 7
Original Change to
second s
seconds s
2.4 E6855 – Spelling of acknowledgement
E6855 4.2 4.1 4.0 3.0 2.1 Global Several Parts
EDITOR’S NOTE: Change all instances of “acknowledgement to

“acknowledgment”
2.5 E7076 – Consistency of capitalization of White List
E6855 4.2 4.1 4.0 Global Several Parts
EDITOR’S NOTE: Change all instances of "white list", "White list", or "white
List" to "White List"
Global Changes - Affecting Several Parts 06 December 2016

3 [Vol 0] Part B: COMPLIANCE REQUIREMENTS
3.1 E6717 – Meaning of excluded, E, and X
E6717 4.2 4.1 4.0 Vol 0, Part B Compliance Requirements
Vol 1, Part B Acronyms Section 5.1
Core Section(s) affected: 3.1 Types of Bluetooth Products
3.1.1 Bluetooth End Product
3.1.2.1 Bluetooth Host Subsystem Product
3.1.2.2 Bluetooth Controller Subsystem Product
EDITOR’S NOTE: Revise text as shown below
Section 3.1
Using the abbreviations in Table 3.1 the following tables define Bluetooth
product types in terms of Core Configurations. For the respective Core
Configuration, the letter “M” indicates that it is mandatory to claim support, “O”
indicates that it is optional to claim support, “P” indicates that it is optionally
permitted to claim only partial support of the Core Configuration, “I” indicates
that the Core Configuration is inherently included in the combined Core
Configuration, “EX” indicates that support for the Core Configuration shall not
be claimed.
Section 3.1.1
BR and LE
BR CC EDR CC HS CC Combined CC LE CC HCI CC
BR End Product M P P EX EX O
EDR End Product M M P EX EX O
HS End Product M M M EX EX O
LE End Product EX EX EX EX M O
[Vol 0] Part B: Compliance requirements 06 December 2016

Section 3.1.2.1
BR and LE
BR CC HS CC Combined CC LE CC
Host Parts Host Parts Host Parts Host Parts HCI CC
BR/EDR Host
M P EX EX M
Subsystem Product
HS Host
M M EX EX M
Subsystem Product
LE Host
EX EX EX M M
Subsystem Product
Section 3.1.2.2
BR and LE
BR CC EDR CC HS CC Combined CC LE CC
Controller Controller Controller Controller Controller HCI
Parts Parts Parts Parts Parts CC
BR Controller
Subsystem M P P EX EX M
Product
EDR Control-
ler Subsys- M M P EX EX M
tem Product
HS Controller
Subsystem M M M EX EX M
Product
HS only Con-
troller Subsys- EX EX M EX EX M
tem Product
LE Controller
Subsystem EX EX EX EX M M
Product
3.2 E6360 – Are ATT and GATT requirements from the BR CC

not required to be met?
E6360 4.2 4.1 4.0 Vol 0, Part B Compliance Requirements
Basic Rate and Low Energy Combined Core

Core Section(s) affected: 4.5 Configuration

EDITOR’S NOTE: Edit Table 4.8 as shown below
Layer Required Features
ATT ([Vol 3] Part F) All ATT requirements in the LE CC. If ATT is supported on BR,
all ATT requirements in the BR CC.
GATT ([Vol 3] Part G) All GATT requirements in the LE CC. If GATT is supported on
BR, all GATT requirements in the BR CC.

4 [Vol 1] Part A: ARCHITECTURE
4.1 E6421 – Problems with [use of “may not” phrase]
E6421 4.2 4.1 4.0 3.0 2.1, Vol 1, Part A Architecture

CSA4
Vol 1, Part E IEEE Language Section 6.2
Vol 2, Part B Baseband Section 8.4
Vol 2, Part D Error Codes Section 10.1
Vol 2, Part E Host Controller Interface Section 11.4
Vol 2, Part H Security Specification Section 13.1
Vol 3, Part A L2CAP Section 14.6
Vol 3, Part B Service Discovery Proto- Section 15.1

col
Vol 3, Part C Generic Access Profile Section 16.19

(GAP)
Vol 3, Part D Test Support Section 17.3
Vol 3, Part H Security Manager Section 20.9
Vol 5, Part A 802.11 PAL Section 22.1
Vol 6, Part B Link Layer Section 24.15
Core Section(s) affected: 2 Core System Architecture
3.1 Core Traffic Bearers
4.2.1.5 Sniff Mode
EDITOR’S NOTE: Revise instances of “may not” as shown below
Section 2
Although these assumptions may not beare not always required for embedded
Bluetooth implementations that combine all layers in a single system, the
general architectural and QoS models are defined with these assumptions in
mind, in effect a lowest common denominator.
Section 3.1
Figure 3.2 shows a number of application traffic types. These are used to
classify the types of data that may be submitted to the Bluetooth core system.
The original data traffic type may not be the same ascan be different from the
[Vol 1] Part A: Architecture 06 December 2016

type that is submitted to the Bluetooth core system if an intervening process

modifies it. [...]
Section 4.2.1.5
[...]A master device should aim to schedule broadcasts to coincide with periods
of physical link presence within the piconet physical channel, but this may not
always beis not always possible or practical. [...]
4.2 E6352 – Definition of [Advertising Packet]
E6352 4.2 4.1 4.0 Vol 1, Part A Architecture
Vol 3, Part C Generic Access Profile (GAP) Section 16.11
Core Section(s) affected: 1.4 Nomenclature
3.3.2.2.2 Characteristics
EDITOR’S NOTE: Section 1.4: Insert row with new term and definition.
Section 3.3.2.2.2: Insert/delete text in first paragraph.
Section 1.4
Advertising Packet A packet containing an advertising PDU. See Vol 6 Part

B Section 2.3.1.
Section 3.3.2.2.2
[...] All advertising packets on the advertising PHY channels use a fixed Access
Address.
4.3 E6603 – Need a definition of physical transport
E6603 4.2 4.1 Vol 1, Part A Architecture
Core Section(s) affected: 1.4 Nomenclature

EDITOR’S NOTE: Insert a new row in Table 1.1
Physical Link A Baseband or Link Layer level connection between

two devices.
Physical Transport PHY packet transmission and/or reception on an RF

channel using one or more modulation schemes.
Piconet A collection of devices occupying a shared physical

channel where one of the devices is the Piconet Master
and the remaining devices are connected to it.
4.4 E6558 – Removing packets from the transmit queue
E6558 4.2 4.1 4.0 3.0 2.1 Vol 1, Part A Architecture
Core Section(s) affected: 3.1.3.2 LE reliability
EDITOR’S NOTE: Delete the following paragraph
In summary, if a link or channel is characterized as reliable this means that the

receiver is capable of detecting errors in received packets and requesting re-
transmission until the errors are removed.
The transmitter may remove packets from the transmit queue such that the
receiver does not receive all the packets in the sequence. If this happens
detection of the missing packets is delegated to the L2CAP layer.
On an unreliable link the receiver is capable of detecting errors in received

packets but cannot request retransmission. The packets passed on by the
receiver may be without error, but there is no guarantee that all packets in
Version 3.0
Section is 3.1.3.1
Version 2.1
Section is 3.1.3

4.5 E6465 – Jumping past the logical transport
E6465 4.2 4.1 4.0 3.0 CSA4 Vol 1, Part A Architecture
Core Section(s) affected: 3.2 Transport Architecture Entities
EDITOR’S NOTE: Move the connection between Control (PAL) AMP-C and
AMP Physical Link to be between Control (PAL) AMP-C and AMP ACL in
Figure 3.3.
Channels
L2CAP
Unicast Broadcast
User
User
(L2CAP)
Logical
Control User Control User Profile User Control Control User Control User
Links
(L2CAP)
AMP-U
(PAL) (L2CAP)
AMP-U (LMP) (L2CAP) Stream Broadcast (L2CAP) (LMP) (LL) (L2CAP) (LL) (LL)
AMP-C AMP-U ACL-C ACL-U Data (PBD) PSB-U PSB-C LE-C LE-U ADVB-C ADVB-U
Transports
Logical
AMP BR/EDR LE
ASB SCO eSCO CSB PSB ADVB
ACL ACL ACL
BR/EDR BR/EDR BR/EDR LE LE

Physical
AMP
Links
Active Connectionless Parked Active Advertising

Physical
Physical Slave Broadcast Physical Physical Physical
Link
Link Physical Link Link Link Link
BR/EDR BR/EDR BR/EDR BR/EDR

Channels
BR/EDR LE LE
Physical
AMP Basic Adapted Page Inquiry Synchronization Piconet Advertising

Physical Piconet Piconet Scan Scan
Physical Physical Physical Physical Scan Physical Physical Physical
Channel
Channel Channel Channel Channel Channel Channel Channel
Transports
Physical
BR/EDR Physical Transport LE Physical Transport
4.6 E6922 – Remove stacked boxes in figure 3.3
E6922 4.2 4.1 4.0 3.0 Vol 1, Part A Architecture Section 4.5
Core Section(s) affected: 3.2 Transport Architecture Entities
EDITOR’S NOTE: Remove stacked boxes from Figure 3.3. See Section 4.5

4.7 E6604 – Channels can have multiple frequencies
E6604 4.2 4.1 4.0 3.0 2.1 Vol 1, Part A Architecture
Core Section(s) affected: 3.3 Physical Channels
EDITOR’S NOTE: Revise text in first paragraph
A number of types of physical channel are defined. All Bluetooth physical

channels are characterized by a PHY frequencya set of PHY frequencies
combined with temporal parameters and restricted by spatial considerations.
For the basic [...]
4.8 E7030 – ADVB logical transport is mis-described
Core Section(s) affected: 3.5 Logical Links and Logical Transports
EDITOR’S NOTE: Revise Table 3.2 as shown below
Links
Logical transport supported Supported by Bearer Overview
LE Advertising Control (LL) LE advertising LE LE advertising phys-

Broadcast ADVB-C, User physical link, LE ical link, LE piconet
(ADVB) (LL) ADVB-U piconet physical physical chan-
channel nel.Unreliable, uni-
directional broadcast
to all devices in a
given area or
directed to one
recipient. Used to
carry data and Link
Layer signalling
between uncon-
nected devices.

4.9 E7031 – LE ACL logical transport is mis-described
Core Section(s) affected: 3.5 Logical Links and Logical Transports
Links
Logical transport supported Supported by Bearer Overview
LE asynchronous Control (LL) LE active physi- LE Reliable or time-

connection (LE LE-C, User cal link, LE bounded, bi-direc-
ACL (L2CAP) LE-U piconet physical tional, point-to-point.
channel
4.10 E6529 – Revisit erratum 6362
Core Section(s) affected: 3.5.4.6 LE Asynchronous Connection (LE ACL)
EDITOR’S NOTE: Change 2-bit to 1-bit
The LE asynchronous connection (LE ACL) logical transport is used to carry LL

and L2CAP control signaling and best effort asynchronous user data. The LE
ACL logical transport uses a 21-bit NESN/SN scheme to provide simple
channel reliability.
4.11 E7301 – Cross Transport Key Derivation hash inputs
E7301 4.2 Vol 1, Part A Architecture
Core Section(s) affected: 5.1 Security Architecture

EDITOR’S NOTE: Revise figure 5.2 as shown below

LE Secure BR/EDR Secure
LE Legacy Pairing
Connections Pairing Connections Pairing
TK Mrand Srand DHKey N1 N2 BD_ADDRm BD_ADDRs
BR/EDR Secure
Connections
s1(AES-128) f5(AES-CMAC-128)
LE STK LE LTK BR/EDR Link Key

- legacy
“tmp1” SALT “tmp2” SALT
LE key
distribution: h6(AES-CMAC-128) h7(AES-CMAC-128) h6(AES-CMAC-128) h7(AES-CMAC-128)
LTK, EDIV, RAND, ILK ILTK

IRK, CSRK
“lebr” “brle”
LTK from
LE Legacy
Pairing h6(AES-CMAC-128) h6(AES-CMAC-128)
BR/EDR
Link Key LTK
BR/EDR Link Key
LE key distribution IRK, CSRK
Stored
Long Term Key
4.12 E6524 – Mandating the use of Security Mode 4 Level 0
Core Section(s) affected: 5.3 Secure Connections Only Mode
EDITOR’S NOTE: Revise the 4th paragraph as shown below
If a BR/EDR/LE device is configured in Secure Connections Only Mode, then

aboth the BR/EDR and the LE transports will only be used whenin Secure
Connections is supported by both devicesOnly Mode.

4.13 E6766 – Missing alternative?
Core Section(s) affected: 5.4.5 Privacy Feature
EDITOR’S NOTE: Delete “or” from last sentence of fifth paragraph.
[...]If the Controller cannot resolve the peer’s device identity address in an
advertisement or, it may pass the event to the Host for resolution in the Host.
4.14 E6356 – Defining scanner’s device address in “Scanner

filter policy”
E6356 4.2 4.1 Vol 1, Part A Architecture
Core Section(s) affected: 5.4.5 Privacy Feature
Section 5.4.5
Bluetooth LE supports a feature that reduces the ability to track a LE device

over a period of time by changing the Bluetooth device address on a frequent
basis. The privacy feature is not used in the GAP discovery mode and
procedures but it is used, when supported, during connection mode and
connection procedures.
[...] There are two modes of privacy: device privacy mode and network privacy
mode. A device in device privacy mode is only concerned about the privacy of
the device and will accept advertising packets from peer devices that contain
their identity address as well as ones that contain a private address, even if
the peer device has distributed its IRK in the past. In network privacy mode, a
device will only accept advertising packets from peer devices that contain

private addresses. By default, network privacy mode is used when private

addresses are resolved and generated by the Controller.

5 [VOL 1] PART B: ACRONYMS
5.1 E6717 – Meaning of excluded, E, and X
E6717 4.2 4.1 4.0 Vol 1, Part B Acronyms
Vol 0, Part B Compliance Requirements Section 3.1
Core Section(s) affected: 1 List of Acronyms and Abbreviations
Section 1
Acronym or
Writing out in full Comments
abbreviation
E Excluded Do not use or claim support in this

context.
[Vol 1] Part B: Acronyms 06 December 2016

6 [Vol 1] Part E: IEEE LANGUAGE
6.1 E7521 – Adjust 4 instances of “PICS”
E7521 4.2 4.1 4.0 3.0 2.1 Vol 1, Part E IEEE Language
Core Section(s) affected: 1.1 Shall
1.4 Should
1.5 May
EDITOR’S NOTE: Change “PICS” to “ICS” as shown below:
Section 1.1
There is a strong implication that the presence of the word shall indicates a
testable requirement. All testable requirements shall be reflected in the
Protocolappropriate Implementation Conformance Statement (PICS). In turn,
all PICS indicators should be reflected in the Test Cases (TCs) either directly or
indirectly.
Section 1.4
In the Bluetooth Specification the term designates an optional attribute that

may require an entry in the PICS.
Section 1.5
The use of may implies an optional condition in the PICS and therefore may
need to be reflected in the corresponding test cases.
E6421 4.2 4.1 4.0 3.0 2.1, Vol 1, Part E IEEE Language
CSA4
Vol 2, Part B Piconet Clocks Section 8.4
[Vol 1] Part E: IEEE LANGUAGE 06 December 2016

Vol 3, Part B Service Discovery Protocol Section 15.1

(GAP)
Vol 1, Part A Architecture Section 4.1
Core Section(s) affected: 1.5 May
EDITOR’S NOTE: Revise instance of “may not” as shown below
The use of may implies an optional condition in the PICS and therefore may
need to be reflected in the corresponding test cases.
This specification does not use the phrase may not except in the form may or
may not.
6.3 E6422 – Add general interpretation rules
Core Section(s) affected: 2 General Interpretation Rules
2.1 Binary and Hexadecimal Values
2.2 Bit Numbers and Bit Fields
2.3 Specification of Bit Values
EDITOR’S NOTE: Add content to new section
2 General Interpretation Rules
The following rules apply throughout this specification except where explicitly
overridden.

2.1 Binary and Hexadecimal Values
Binary numbers are normally written with a "b" suffix, so 1101b 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, 0010_1011b and 00101011b 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
1011b 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) modulo 8, or in C notation "(CLK >> 2) % 8" or "(CLK
>> 2) & 7"). 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 this 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.
6.4 E6694 – No language to forbid use of reserved UUIDs
Core Section(s) affected: 2.5 Assigned Number Requirements
EDITOR’S NOTE: Add new section in Volume 1, Part E to address this erratum
filed against Volume 3, Part B, Section 2.5.1
2.5. ASSIGNED NUMBER REQUIREMENTS
All numbers indicated in the specification as 'Assigned Numbers' shall only be

designated by the Bluetooth SIG and used for their intended purposes. All
other use of assigned numbers not specifically assigned by the Bluetooth SIG
is prohibited. 16-bit and 32-bit UUIDs are considered assigned numbers.

7 [VOL 2] PART A: RADIO SPECIFICATION
7.1 E6199 – Assessment of the RF part vs current regulatory

references and practises
E6199 4.2 4.1 4.0 3.0 2.1 Vol 2, Part A Radio Specification Section 23.1
Core Section(s) affected: 1 Scope
3 Transmitter Characteristics
Out-of-Band and Intermodulation

4.2.5 Characteristics
A.1.2 Nominal power source
A.1.2.1 Mains voltage
Lead-acid battery power sources used in

A.1.2.2 vehicles
A.1.2.3 Other power sources
A.2.1 Extreme temperatures
A.2.2 Extreme power source voltages
A.2.2.1 Mains voltage
Lead-acid battery power source used on

A.2.2.2 vehicles
A.2.2.3 Power sources using other types of batteries
A.2.2.4 Other power sources
B Test Conditions for RF Parameters
EDITOR’S NOTE: Revise text as shown below. In v2.1, section 3 is different.

Affects E6228.
Section 1
Europe:
Approval Standards: European Telecommunications Standards Institute, ETSI
Documents: EN 300 328, ETS 300-826EN 300 440, EN 301 489-17
Approval Authority: National Type Approval Authorities
[Vol 2] Part A: Radio Specification 06 December 2016

Section 3
If transmitting antennas of directional gain greater than 0 dBi are used, the
power level delivered to the antenna shall be compensated to comply with the
applicable paragraphs in relevant regulatory standards: EN 300 328, EN 301
489-17 and FCC part 15.
Bluetooth devices are classified into three power classes based on the
modulation mode with the highest output power. That modulation mode shall
meet the specification requirements for the power class. The other modulation
modes do not need to meet the power class requirements of the applicable
device power class, but the maximum output power used for the other
modulation modes shall not exceed the maximum power of the modulation
mode used for classification.Bluetooth devices are classified into three power
classes based on their highest output power capabilities.
Section 4.2.5
Note: The Basic Rate out-of-band blocking and intermodulation requirements

ensure adequate Enhanced Data Rate performance, and therefore there are
no specific requirements for Enhanced Data Rate.
Section A.1.2
The normal test voltage for the equipment shall be the nominal voltage for
which the equipment was designed.
Section A.1.2.1
The nominal test voltage for equipment to be connected to the mains shall be
the nominal mains voltage. The nominal voltage shall be the declared voltage
or any of the declared voltages for which the equipment was designed. The
frequency of the test power source corresponding to the AC mains shall be
within 2% of the nominal frequency.
Section A.1.2.2
When radio equipment is intended for operation from the alternator-fed lead-
acid battery power sources which are standard in vehicles, then the nominal
test voltage shall be 1.1 times the nominal voltage of the battery (6V, 12V, etc.).
Section A.1.2.3
For operation from other power sources or types of battery (primary or

secondary), the nominal test voltage shall be as declared by the equipment
manufacturer. This shall be recorded in the test report.

Section A.2.1
Where tests at extreme temperatures are required, measurements shall be

made over the extremes of the operating temperature range as declared by the
manufacturer.
The extreme temperature range shall be the largest temperature range given
by the combination of:
• The minimum temperature range 0 °C to +35 °C
• The product operating temperature range declared by the manufacturer.
This extreme temperature range and the declared operating temperature range
shall be recorded in the test report.
Section A.2.2
Tests at extreme power source voltages specified below are not required when
the equipment under test is designed for operation as part of and powered by
another system or piece of equipment. Where this is the case, the limit values
of the host system or host equipment shall apply. The appropriate limit values
shall be declared by the manufacturer and recorded in the test report.
Section A.2.2.1
The extreme test voltage for equipment to be connected to an AC mains

source shall be the nominal mains voltage ±10%.
Section A.2.2.2
When radio equipment is intended for operation from the alternator-fed lead-
acid battery power sources which are standard in vehicles, then extreme test
voltage shall be 1.3 and 0.9 times the nominal voltage of the battery (6V, 12V
etc.).
Section A.2.2.3
The lower extreme test voltage for equipment with power sources using the
following types of battery, shall be
a) for Leclanché, alkaline, or lithium type battery: 0.85 times the
nominal voltage of the battery
a) for mercury or nickel-cadmium types of battery: 0.9 times the
nominal voltage of the battery.
In both cases, the upper extreme test voltage shall be 1.15 times the nominal
voltage of the battery.

Section A.2.2.4
For equipment using other power sources, or capable of being operated from a
variety of power sources (primary or secondary), the extreme test voltages
shall be those declared by the manufacturer. These shall be recorded in the
test report.
Section B
Test Conditions for RF Parameters[This section is no longer used]
The Basic Rate radio parameters shall be tested in the following conditions:
Parameter Temperature Power source
Output Power ETC ETC
Power control NTC NTC
Modulation index ETC ETC
Initial Carrier Frequency accuracy ETC ETC
Carrier Frequency drift ETC ETC
Conducted in-band spurious emissions ETC ETC
Radiated in-band emissions NTC NTC
Sensitivity ETC ETC
Interference Performance NTC NTC
Intermodulation Characteristics NTC NTC
Out-of-band blocking NTC NTC
Maximum Usable Level NTC NTC
Receiver Signal Strength Indicator NTC NTC
ETC = Extreme Test Conditions

NTC = Nominal Test Conditions
The Enhanced Data Rate radio parameters shall be tested in the following
conditions:
Modulation accuracy ETC ETC
Carrier frequency stability ETC ETC
In-band spurious emissions ETC ETC
Relative transmit power ETC ETC
Sensitivity ETC ETC
BER floor sensitivity NTC NTC

Interference Performance NTC NTC
Maximum usable level NTC NTC
ETC = Extreme Test Conditions

NTC = Nominal Test Conditions

8 [Vol 2] Part B: BASEBAND SPECIFICATION
8.1 E6537 – Clock specification requires a particular

implementation
E6537 4.2 4.1 4.0 3.0 2.1, Vol 2, Part B Baseband

CSA4
Core Section(s) affected: 1.1 Bluetooth Clock
EDITOR’S NOTE: Revise 2nd paragraph after Figure 1.4
CLKR is the reference clock driven by the free running system clock. CLKN
may be offset from the reference clock by a timing offset. In STANDBY and in
Park, Hold, Sniff, and Connectionless Slave Broadcast modes the reference
clock may be driven by a low power oscillator (LPO) withshall have a worst
case accuracy (of +/-250ppm). Otherwise, the reference clock shall be driven
by the reference crystal oscillator withIn all other circumstances it shall have a
worst case accuracy of +/-20ppm; this accuracy shall also be used by the
piconet master device. The master shall use the higher resolution oscillator
while performing Piconet Clock Adjustment (see Section 8.6.10).
8.2 E6443 – IEEE terminology change
E6443 4.2 Vol 2, Part B Baseband
Core Section(s) affected: 1.2 Bluetooth Device Addressing
EDITOR’S NOTE: Revise text and illustration in section 1.2 as follows:

Each Bluetooth device shall be allocated a unique 48-bit Bluetooth device
address (BD_ADDR). This address shall be obtained from the IEEE
Registration Authority. The address shall be a 48-bit extended unique identifier
(EUI-48) created in accordance with section 9.2 ("48-bit universal LAN MAC
addresses") 8.2 ("Universal addresses") of the IEEE 802-20012014 standard
(http://standards.ieee.org/findstds/standard/802-20012014.html). and using a
valid Organizationally Unique Identifier (OUI)
Creation of a valid EUI-48 requires one of the following MAC Address Block
types to be obtained from the IEEE Registration Authority:
[Vol 2] Part B: Baseband Specification 06 December 2016

• MAC Address Block Large (MA-L)

• MAC Address Block Medium (MA-M)
• MAC Address Block Small (MA-S)
(sSee http://standards.ieee.org/regauth/oui/forms/http://standards.ieee.org/
develop/regauth/index.html for information on obtaining one of these MAC
Address Blocks. See also the "Guidelines for 48-bit Global Identifier (EUI-48)"
(https://standards.ieee.org/develop/regauth/tut/eui48.pdf) for a tutorial on
creation of EUI-48 addresses.and sections 9 and 9.1 of the IEEE 802-2001
specification). The LAP and UAP form the significant part of the BD_ADDR.
Figure 1.5 illustrates how the LAP, UAP, and NAP map to the EUI-48.
The bit pattern in Figure 1.5 is an example BD_ADDR.
LSB MSB
EUI-48
LAP UAP NAP
0000 0001 0000 0000 0000 0000 0001 0010 0111 1011 0011 0101
Figure 8.1: Format of BD_ADDR
The BD_ADDR may take any values except those that would have any of the 64
reserved LAP values for general and dedicated inquiries (see Section 1.2.1).
8.3 E6668 – Consistency

CSA4
Core Section(s) affected: 2 Physical Channels
EDITOR’S NOTE:
Version 4.2
Change “Five” to “Several”.
Versions 4.1, 4.0, 3.0. 2.1, CSA4

Change “Two” to “Several”.
FiveSeveral Bluetooth physical channels are defined. Each is optimized and

used for a different purpose. Two of these physical channels (the basic piconet

channel and adapted piconet channel) are used for communication between
connected devices and are associated with a specific piconet.[...]

CSA4

(GAP)
Core Section(s) affected: 2.2.4 Piconet Clocks
Piconet physical channel re-synchroniza-

2.2.5.2 tion
6.5.1.2 NULL Packet
Connectionless Slave Broadcast Receive

8.10.2 Operation
Section 2.2.4
[...]In some cases, it may not beis not possible to determine how much of an
observed offset is caused by external frame timing alignment
(time_base_offset) and how much is caused by the offset between master and
slave (slave_offset).
Section 2.2.5.2
[...]The master may notfail to transmit to the slave due to the master device

being busy with other tasks such as maintaining connections to other devices
in Sniff, Hold, or Park modes, due to SCO, eSCO, or Connectionless Slave
Broadcast activity, due to the master being involved in a scatternet, or due to
interference.
Section 6.5.1.2
The NULL packet may be used to return link information to the source
regarding the success of the previous transmission (ARQN), or the status of
the RX buffer (FLOW). The NULL packet maydoes not have to berequire
acknowledgedacknowledgment.
Section 8.10.2
The BR/EDR Controller may transfer Connectionless Slave Broadcast data to
the Host through HCI events. Because HCI events are limited to 255 bytes a
received packet may or may not fit into a single HCI event.[...]
8.5 E6964 – Figure 2.11: Timing of inquiry response packets

on successful inquiry in second half slot
E6964 4.2 4.1 4.0 3.0 2.1 Vol 2, Part B Baseband
Core Section(s) affected: 2.5.4 Inquiry Response Timing
EDITOR’S NOTE: Revise images as shown below
Figure 2.10
master-to-slave slot slave-to-master slot master-to-slave slot slave-to-master slot master-to-slave slot
hop f(k) hop f(k+1) hop f ’(k) hop f ’(k)
hop f’(k) hop f’ (k)
68 μs
Master ID
hop f ’(k) hop f ’(k)

hop f’(k) hop f’ (k)
hop f(k) Extended Inquiry
Slave FHS
Response Packet
625 μs 1250 μs

Figure 2.11
master-to-slave slot
master-to-slave slot master-to-slave slot slave-to-master slot master-to-slave slot
slave-to-master slot
hop f(k) hop f(k+1) hop f ’(k) hop f ’(k+1) hop f ’(k+1)
hop f’(k) hop f’(k+1) hop f’(k+1)
68 μs
Master ID
hop f ’(k+1) hop f ’(k+1)

hop f’(k+1) hop f’(k+1)
hop f(k+1) Extended Inquiry
Slave FHS
Response Packet
625 μs 1250 μs
8.6 E6749 – Time Default value for synchronization_trainTO
E6749 4.2 4.1 CSA4 Vol 2, Part B Baseband
Core Section(s) affected: 2.7.3 Synchronization Scan Procedure Timing
B.1.8 synchronization_trainTO
B.1.9 synchronization_scanTO
EDITOR’S NOTE: Edit text as shown below. Only section 2.7.3 is in previous
version.
Section 2.7.3
[...] During each scan window, the device listens for the duration of
TSync_Scan_Window (see [Vol 2] Part E, Section 7.1.52). The RF Channel for
each scan window shall be selected as specified in Section 2.7.1. Each scan
window should be continuous and not interrupted by other activities. The
interval between the start of consecutive scan windows shall be equal to≤
TSync_Scan_Interval (see [Vol 2] Part E, Section 7.1.52). The values for
TSync_Scan_Window and TSync_Scan_Interval shall be chosen as follows:
• During Connectionless Slave Broadcast, refer to [Vol 2] Part E, Section
7.1.52.

• During Coarse Clock Adjustment Recovery Mode, the values chosen are
implementation specific.
≤ TSync_Scan_Interval ≤ TSync_Scan_Interval
TSync_Scan_Window TSync_Scan_Window TSync_Scan_Window
f1 f2 f3
scan scan scan
Figure 2.22: Synchronization scan timing
Section B.1.8
[...] At the baseband level a default value equivalent to 120 seconds should be
used for Connectionless Slave Broadcast and a default value equivalent to 20
seconds should be used for Coarse Clock Adjustment Recovery Mode. The
Host maycan change the value of synchronization_trainTO that is used during
Connectionless Slave Broadcast.
Section B.1.9
At the baseband level a default value equivalent to 5.12 seconds should be

used for Connectionless Slave Broadcast and a default value equivalent to 20
seconds should be used during Coarse Clock Adjustment Recovery Mode. The
Host maycan change the value of synchronization_scanTO that is used during
Connectionless Slave Broadcast.
8.7 E6714 – Missing subscripts (editorial)
Core Section(s) affected: 7.2 Data Whitening
EDITOR’S NOTE: Change following characters to subscript
Before each transmission, the shift register shall be initialized with a portion of
the master Bluetooth clock, CLK6-1, extended with an MSB of value one. This
initialization shall be carried out with CLK1 written to position 0, CLK2 written to
position 1, etc. Exceptions are the FHS packet sent during inquiry response or
page response, and the extended inquiry response packet sent during inquiry
response, where initialization of the whitening register shall be carried out

differently. Instead of the master clock, the X-input used in the inquiry or page
response (depending on current state) routine shall be used, see Table 2.2.
The 5-bit value shall be extended with two MSBs of value 1. During register
initialization, the LSB of X (i.e., X0) shall be written to position 0, X1 shall be
written to position 1, etc.
8.8 E6953 – Need to specify whether it is mandatory for slave

to transmit in reserved slots
Core Section(s) affected: 7.6.1 Unnumbered ARQ
8.6.3 eSCO
EDITOR’S NOTE: Edit text as shown below.
7.6.1 – Add the following ‘Note’ just before Figure 7.12.

Note: In Figure 7.12, TX refers to the next transmission that the device makes
and does not imply that it must transmit in the next slot. NO TX indicates that
the device must not transmit in the next slot.
8.6.3 – Revise the last paragraph in this section.
In the reserved slots both master and slave shall only listen and transmit at
their allocated slots at the first transmission time of each eSCO window.
Intermittent lapses due to, for instance, time-critical signaling during connection
establishment are allowed. Both master and slave may refrain from sending
data and may use instead POLL and NULL packets respectively. When the
master transmits a POLL packet instead of an eSCO 3-slot packet the slave
shall transmit starting in the same slot as if the master transmitted an eSCO 3-
slot packet. If the slave does not receive anything in the reserved master-to-
slave transmission slot it shall transmit , or the slave does not receive anything
in the reserved master-to-slave transmission slot, it shall start any transmission
in the same slot as if the master had transmitted the negotiated packet type.
For example, if the master had negotiated an EV5 packet the slave would
transmit three slots later. If the master does not receive a slave transmission in
response to an eSCO packet it causes an implicit NAK of the packet in
question. The listening requirements for the slave during the retransmission
window are the same as for an active ACL logical transport.


implementation redux
Core Section(s) affected: 8.2 Standby State
EDITOR’S NOTE: Revise first paragraph
The STANDBY state is the default state in the device. In this state, the device
may be in a low-power mode. Only the native clock is running at the accuracy
of the LPO (or better)with a worst case accuracy of +/-250 ppm.
8.10 E6480 – Inconsistent names for time values
Core Section(s) affected: 8.3.1 Page Scan Substate
EDITOR’S NOTE: Add underscores and delete spaces in time values in 5th
and 6th paragraphs and in Table 6.1.
[...]The scan window shall be increased to minimize the setup delay. If one
SCO logical transport is present using HV3 packets and TSCO=6 slots or one
eSCO logical transport is present using EV3 packets and TeSCO=6 slots, a total
scan window Tw_ page_ scan of at least 36 slots (22.5ms) is recommended; if
two SCO links are present using HV3 packets and TSCO=6 slots or two eSCO
links are present using EV3 packets and TeSCO=6 slots, a total scan window of
at least 54 slots (33.75ms) is recommended.
The scan interval Tpage_ scan is defined as the interval between the beginnings
of two consecutive page scans. A distinction is made between the case where
the scan interval is equal to the scan window Tw _page_ scan (continuous scan),
the scan interval is maximal 1.28s, or the scan interval is maximal 2.56s. These
three cases shall determine the behavior of the paging device; that is, whether
the paging device shall use R0, R1 or R2, see also Section 8.3.2. Table 8.1
illustrates the relationship between Tpage_ scan and modes R0, R1 and R2.
Although scanning in the R0 mode is continuous, the scanning may be

interrupted for example by reserved synchronous slots. The scan interval

information is included in the SR field in the FHS packet.
SR mode Tpage_ scan
R0 ≤ 1.28s and = Tw_ page_ scan
R1 ≤ 1.28s
R2 ≤ 2.56s
Reserved -
Table 8.1: Relationship between scan interval, and paging modes R0, R1, and R2
8.11 E6505 – The master's eSCO retransmission rule is not

clear
Core Section(s) affected: 8.6.3 eSCO
EDITOR’S NOTE:
Version 4.2
Delete last sentence in 5th paragraph and add to new paragraph.
Versions 4.1, 4.0, 3.0. 2.1

Delete sentence within paragraph 5, add to new paragraph as shown and
make remainder of original paragraph a new paragraph.
[...]The master may transmit on any non-eSCO LT_ADDR in any master-to-

slave transmission slot inside the eSCO retransmission window.The master
shall only transmit on an eSCO LT_ADDR in the retransmission window if there
are enough slots left for both the master and slave packets to complete in the
retransmission window.
The master shall only transmit on an eSCO LT_ADDR in the retransmission

window if there are enough slots left for both the master and slave packets to
complete in the retransmission window. If the master is transmitting a NULL
packet (with ARQN=ACK), then this requires one slot, otherwise it requires
enough slots for the master’s negotiated eSCO packet type plus:
• if the master’s packet has ARQN=NAK, then enough slots for the slave’s
negotiated eSCO packet type;

• if the master’s packet has ARQN=ACK, then one slot.
[End of changes for E6505
8.12 E6523 – eSCO rules do not take account of EDR
Core Section(s) affected: 8.6.3 eSCO
EDITOR’S NOTE: Revise the last paragraph of the section
[...]When the master transmits a POLL packet instead of an EV4 or EV5eSCO

3-slot packet the slave shall transmit starting in the same slot as if the master
transmitted an EV4 or EV5eSCO 3-slot packet. If the slave[...]
8.13 E6618 – Can a broadcast L2CAP packet be fragmented?

CSA4
Core Section(s) affected: 8.6.4 Broadcast Scheme
EDITOR’S NOTE: Revise and reorder the first three paragraphs. Change bars
reflect E6277 that was in ESR09.
The master of the piconet can broadcast messages to all slaves on the ASB
and PSB logical transports. An ASB or PSB broadcast packet shall have an
LT_ADDR set to all zero. If aEach new broadcast message carries ASB-U
data, it may be (which may be carried by a number of packetsfragmented in the
same way as ACL packets.) Therefore it shall start with a packet carrying the
start of L2CAP message indication (LLID=10b) and may be followed by
packets carrying the continuation of L2CAP message indication (LLID=01b). If
a new broadcast message carries ASB-C data, it shall not be fragmented and
shall consist of a single packet carrying or the LMP message indication
(LLID=11b). In either case, the master may carry out a number of
retransmissions of each of these packets to increase the probability for error-
free delivery; see also Section 7.6.5.
The Broadcast LT_ADDR shall use a ptt=0.

A broadcast packet shall never be acknowledged at the baseband layer. In an

error-prone environment, the master may carry out a number of
retransmissions to increase the probability for error-free delivery, see also
Section 7.6.5.
The Broadcast LT_ADDR shall use a ptt=0.
8.14 E6647 – Statement in first bullet is not always strictly

true
Core Section(s) affected: 8.6.5 Role Switch
EDITOR’S NOTE: Revise text in first bullet.
There are several occasions when a role switch is used:.

• aA role switch is necessary in order to make a paging device a slave when
joining an existing piconet by paging, since by definition, the paging device
is initially master of a "small" piconet only involving the pager (master) and
the paged (slave) device.
8.15 E6646 – Punctuation and capitalization issues in

bulleted list at start of section
EDITOR’S NOTE: Revise text in second bullet.

• aA role switch is necessary in order for a slave in an existing piconet to set
up a new piconet with itself as master [...]

8.16 E6446 – What are steps 1 and 3? What is step 2?
EDITOR’S NOTE: Revise text in 5th paragraph.
In step 1To begin the role switch, the slave A and master B shall perform a
TDD switch using the former hopping scheme (still using the Bluetooth device
address and clock of device B), so there is no piconet switch yet. The slot
offset information sent by slave A shall not be used yet; it is used when both
devices have switched to the new piconet and device B is positioning its
correlation window.but shall be used in step 3. Device A now becomes the
master, device B the slave. The LT_ADDR formerly used by device A in its
slave role, shall now be used by slave B.
8.17 E6531 – extended_pageTO should be italicized for

consistency
E6531 4.2 4.1 Vol 2, Part B Baseband
Vol 2, Part C Link Manager Protocol (LMP) Section 9.3
Vol 2, Part F Message Sequence Charts Section 12.4
Vol 6, Part B Link Layer Specification Section 24.28
Link Supervision for Connectionless Slave

Core Section(s) affected: 3.2 Broadcast Physical Links
8.3.2 Page substate
8.6.10.3 Clock Dragging
B.1.2 pageTO
EDITOR’S NOTE: Italicize text as shown below:
Section 3.2
For each slave, the timeout period, CSB_supervisionTO, shall be provided by
the Host.

Section 8.3.2
Train B shall be repeated for Npage times. If no response is obtained, knudge
may be updated in the case where slots to receive are periodically not
available and train A shall be tried again Npage times. Alternate use of train A
and train B and updates of knudge shall be continued until a response is
received or the timeout pageTO is exceeded. When extended_pageTO is
greater than zero, the timeout may be extended to (pageTO +
extended_page_TO). If a response is returned by the slave, the master device
enters the master response substate.
Section 8.6.10.3
Each single adjustment shall be performed by a directed packet from the
master to each slave and a response (e.g. baseband
acknowledgementacknowledgment) from each slave. If a slave does not
respond, the master shall suspend its updating of time_base_offset (but should
continue to poll that slave) at least until each slave has either responded or has
failed to respond for at least CLK_adj_drag_TO. In case several slaves fail to
respond, the master should ensure that each of the failing slaves gets at least
one CLK_adj_drag_TO to respond (these may be concurrent for multiple
slaves). The master need not allow more than one suspension of
CLK_adj_drag_TO for any given slave during a link supervision timeout for that
slave.
If a master is performing Clock Dragging when it initiates a Coarse Clock

Adjustment, a new Clock Dragging, or a sequence containing an instant or
timing control flags, or receives a request from a slave to initiate such a
sequence, it shall abort the current Clock Dragging before processing the new
request or carrying out the sequence. If the master has suspended clock
dragging during CLK_adj_drag_TO, it shall reject new requests until the
timeout is cancelled due to slave response or the timeout period expires.
Section B.1.2
The pageTO defines the number of slots the page substate can last before a
response is received when the extended_pageTO is zero. The timer value may
be changed by the host. HCI provides a command to change the timer value.

9 [Vol 2] Part C: LINK MANAGER PROTOCOL
9.1 E6852 – Bad reference
E6852 4.2 4.1 4.0 3.0 2.1 Vol 2, Part C Link Manager Protocol (LMP)
Core Section(s) affected: 2.5 Error Handling
EDITOR’S NOTE: Revise Section reference
If the maximum response time, see Section 2.4.1, is exceeded or if a link loss
is detected (see [Vol 2] Part B, Section 3.1), the party that waits for the
response shall conclude that the procedure has terminated unsuccessfully.
9.2 E4783 – What should be put in a LMP_power_control_res

PDU if the level doesn't change?
E4783 4.2 4.1 4.0 3.0 Vol 2, Part C Link Manager Protocol (LMP)
Responding to Enhanced Power Control

Core Section(s) affected: 4.1.3.1.2 Requests
When a device receives an LMP_power_control_req PDU with the

power_control_adjust parameter set to "increment one step," at least one
modulation shall be increased one step unless all supported modulations are at
the maximum level. Modulations that would violate the relative power level
between modulations (see [Vol 2] Part A, Section 3) shall also increment one
step.all supported modulations that are not at the maximum level shall be
increased one step.
When a device receives an LMP_power_control_req PDU with the

power_control_adjust parameter set to "decrement one step", at least one
modulation shall be decreased one step unless all supported modulations are
at the minimum level. Modulations that would violate the relative power level
between modulations (see [Vol 2] Part A, Section 3) shall also decrement one
step. all supported modulations that are not at the minimum level shall be
decreased one step.
[Vol 2] Part C: Link Manager Protocol 06 December 2016

Implementations shall not violate the relative power level between modulations
(see [Vol 2] Part A, Section 3).

consistency
E6531 4.2 4.1 Vol 2, Part C Link Manager Protocol (LMP)
Core Section(s) affected: 4.1.14 Piconet Clock Adjustment
5.2 Parameter Definitions

Section 4.1.14
The master’s LM shall not initiate another sequence containing an instant or
timing control flags before an outstanding clock adjustment instant has been
reached, while waiting for CLK_adj_drag_TO to expire (see [Vol 2] Part B,
Section Appendix B), or while in Coarse Clock Adjustment Recovery Mode
(see [Vol 2] Part B, Section 8.6.10.2); however the latter may be terminated by
the master in order to initiate the request. If a request to initiate such a
sequence is received before an outstanding clock adjustment instant is
reached or CLK_adj_drag_TO has been cancelled or has expired, the request
shall be rejected with the error code Different Transaction Collision (0x2A).
Section 5.2
Length
(bytes)
Mandatory
Name Type Unit Detailed
range
Only even values less than

or equal to (supervisionTO * 0x0014 to
hold time 2 u_int16 slots
0x8000
0.999) are valid1
Only even values less than

or equal to (supervisionTO * 0x0006 to
Tsniff 2 u_int16 slots
0x0540
0.999) are valid1

9.4 E6735 – may or shall not (redux)?
Core Section(s) affected: 4.2.4 Change Current Link Key Type
EDITOR’S NOTE: Revise text first paragraph
[...] The current link key mayshall not be changed before the connection
establishment procedure has completed. This feature is only supported if
broadcast encryption is supported as indicated by the LMP features mask.
9.5 E6447 – Bad grammar
Core Section(s) affected: 4.4.1 Slot Offset
EDITOR’S NOTE: Revise text first paragraph
[...]The slot offset shall be the time in microseconds betweenfrom the start of a
master transmission in the current piconet to the start of the next following
master transmission in the piconet where the BD_ADDR device (normally the
slave) is master at the time that the request is interpreted by the BD_ADDR
device.
9.6 E6776 – Incorrect table label
Core Section(s) affected: 4.4.1 Slot Offset
4.4.2 Role Switch
EDITOR’S NOTE: Revise Table captions for 4.30 and 4.31
Tables 4.29 and 4.30 in version 4.2

Tables 4.27 and 4.28 in version 4.1
Tables 4.24 and 4.25 in versions 4.0, 3.0, and 2.1
M/O PDU Contents
O(3) LMP_slot_offset slot offset

BD_ADDR
Table 4.30: Role SwitchSlot Offset PDU
M/O PDU Contents
O(5) LMP_switch_req switch instant
O(5) LMP_slot_offset slot offset

BD_ADDR
Table 4.31: Role Switch PDUs
9.7 E6606 – Remove teleology
Core Section(s) affected: 4.5.3.1 Master or Slave requests Sniff Mode
EDITOR’S NOTE: Revise last paragraph in section
If the slave receives an LMP_sniff_req PDU it must decideshall determine

whether to accept the request. If the slave does not wish to enter sniff mode
then it replies with an LMP_not_accepted PDU. If it is happy toThe slave may
reply with an LMP_not_accepted PDU to reject the request or, if it can enter
sniff mode but requires a different set of parameters it shall respond with an
LMP_sniff_req PDU containing the new parameters.[...]

9.8 E6773 – LMP_switch_req (and maybe LMP_slot_offset)

incorrectly shown as allowed in DV packets
Core Section(s) affected: 5.1 AMP User Asynchronous/Isochronous
EDITOR’S NOTE: Revise Packet type for LMP_switch_req in Table 5.1.
Position
Length op Packet Possible in
LMP PDU (bytes) code type direction Contents payload
LMP_switch_req 5 19 DM1/DV m ↔ s switch instant 2-5
Table 5.1: Coding of the different LM PDUs

10 [Vol 2] Part D: ERROR CODES
E6421 4.2 4.1 4.0 3.0 2.1, Vol 2, Part D Error Codes
CSA4

(GAP)
Core Section(s) affected: 2.1 Unknown HCI Command (0X01)
Section 2.1
The OpCode given might not correspond to any of the OpCodes specified in
this document, or any vendor-specific OpCodes, or the command may not
have not been implemented.
[Vol 2] Part D: Error Codes 06 December 2016

11 [VOL 2] PART E: HOST CONTROLLER INTERFACE
11.1 E6910 – Set Event Filter Command on AMP
E6910 4.2 4.1 4.0 3.0 Vol 2, Part E Host Controller Interface
Core Section(s) affected: 3.14 Host Flow Control
EDITOR’S NOTE: Revise text in Table 3.15 as shown below:
Supported
Name Vers. Summary description Controllers
Set Event Filter Command 1.1 The Set Event Filter command is BR/EDR,
used by the Host to specify different AMP
event filters. The Host may issue this
command multiple times to request
various conditions for the same type
of event filter and for different types of
event filters.

consistency
E6531 4.2 4.1 Vol 2, Part E Host Controller Interface
Core Section(s) affected: 3.16 Authentication and Encryption
6.37 Synchronization Train Timeout
Read Authenticated Payload Timeout

7.3.93 Command
Write Authenticated Payload Timeout

7.3.94 Command
7.7.75 Authenticated Payload Timeout Expired Event
[Vol 2] Part E: Host Controller Interface 06 December 2016

Section 3.16
Table 3.17
Supported
Authenticated Payload 4.1 This event is used to indicate that BR/EDR, LE

Timeout Expired Event a packet containing a valid MIC on
the Handle was not received within
the authenticatedPayloadTO.
Section 6.37
The synchronization_trainTO configuration parameter is used by the controller
to terminate the Synchronization Train after it has been started via the
HCI_Start_Synchronization_Train command.
Section 7.3.93
This command reads the Authenticated_Payload_Timeout
(authenticatedPayloadTO, see [Vol 2] Part B, Section Appendix B for BR/EDR
connections and [Vol 6] Part B, Section 5.4 for the LE connections) parameter
in the BR/EDRPrimary Controller on the specified Connection_Handle.
Section 7.3.94
This command writes the Authenticated_Payload_Timeout
(authenticatedPayloadTO, see [Vol 2] Part B, Section Appendix B and [Vol 6]
Part B, Section 5.4 for the LE connection) parameter in the Primary Controller
for the specified Connection_Handle.
Section 7.7.75
The Authenticated Payload Timeout Expired event is used to indicate that a
packet containing a valid MIC on the Connection_Handle was not received
within the authenticatedPayloadTO (see [Vol 2] Part B, Section Appendix B for
the BR/EDR and [Vol 6] Part B, Section 5.4 for the LE connection). Note: A
Host may choose to disconnect the link when this occurs.
11.3 E6998 – The C3 condition is wrong
E6998 4.2 4.1 4.0 Vol 2, Part E Host Controller Interface
Core Section(s) affected: 3.19 LE Controller Requirements

EDITOR’S NOTE: Edit table as shown below
Name LE Feature Requirements
LE Set Scan Response Data Command C3
LE Set Scan Response Data Command C15
C3: Mandatory if Controller supports transmitting and receiving

packetsConnection State, otherwise optionalexcluded.
C15: Mandatory if Controller supports transmitting scannable advertisements,

otherwise excluded.
E6421 4.2 4.1 4.0 3.0 2.1, Vol 2, Part E Host Controller Interface
CSA4

(GAP)
Core Section(s) affected: 4.5 Command Error Handling
A.10.1 Deprecated Parameters
Section 4.5
If an error occurs for a command for which a Command Complete event is

returned, the Return Parameters field may notonly contain all some of the
return parameters specified for the command.[...]
Section A.10.1
4. Note: in the Connection Complete event the Encryption_Mode parameter
will show whether encryption was successfully turned on. If tThe remote device
maydoes not support encryption or may havehas set Encryption_Mode to 0x01
when the local device has not, so the encryption mode returned in the
Connection Complete event may or may not equal the encryption mode set in
the Write_Encryption_Mode command.
11.5 E6807 – What does it mean to support a command?
E6807 4.2 4.1 4.0 3.0 2.1 Vol 2, Part E Host Controller Interface
Core Section(s) affected: 3 Overview of Commands and Events
EDITOR’S NOTE: Add text to last paragraph
[...]The Supported Controllers column denotes the Controller types that can
support the command: All, BR/EDR, LE, or AMP, or a comma-separated list of
Controller types (e.g. “BR/EDR, LE”). Not all Controllers of the names type(s)
will necessarily support the command.
11.6 E6007 – Clarification regarding supported commands

for LE only controller
Core Section(s) affected: 3.3 Controller Flow Control (Table 3.4)
4.1.1 Packet-based Data Flow Control
EDITOR’S NOTE: Revise text in sections as follows:

Section 3.3, Table 3.4

Change “Supported Controller” column for Read Buffer Size Command.
Supported
Read Buffer Size 1.1 The Read_Buffer_Size com- AllBR/EDR, AMP

Command mand returns the size of the HCI
buffers. These buffers are used
by the Controller to buffer data
that is to be transmitted.
Table 3.4: Controller flow control
Section 4.1.1, first paragraph

[...] A Primary Controller that supports BR/EDR and LE may return zero for the
total number of HCI ACL Packets used to transmit ACL data for an LE
transport. In this case the Host shall then send all BR/EDR and LE data using
the HCI ACL Data Packets into the buffers identified using the Read Buffer
Size command.
11.7 E6797 – Typo
Core Section(s) affected: 3.5 Controller Configuration
EDITOR’S NOTE: Fix typo in Table 3.6
Supported
LE Set Advertising Param- 4.0 The LE Set Advertising Parame- LE

eters Command ters Ccommand will set the
parameters used for advertising.
11.8 E7021 – LE Set Advertise Enable Command needs to be

renamed for consistency

3.18 Alphabetical List of Commands and Events
3.19 LE Controller Requirements
6.27 Supported Commands
7.8.9 LE Set Advertising Enable Command
EDITOR’S NOTE: Change all instances of “LE Set Advertise Enable

Command” to “LE Set Advertising Enable Command” as shown below
Section 3.5
Supported
LE Set Advertisinge 4.0 The LE Set Advertisinge Enable LE

Enable Command Command will enable or disable
advertising.
Table 11.1: Controller configuration
Section 3.18
Commands/Events Group
LE Set Advertisinge Enable Command Controller Configuration
Table 11.2: Alphabetical list of commands and events
Section 3.19
LE Set Advertisinge Enable Command C1
Table 11.3: Bluetooth Controller supporting LE requirements
Section 6.27
Octet Bit Command Supported
26 1 LE Set Advertisinge Enable

Section 7.8.9
LE Set Advertisinge Enable Command1
Command OCF Command parameters Return Parameters
HCI_LE_Set_ 0x000A Advertising_Enable Status

Advertisinge_En-
able
The LE_Set_Advertisinge_Enable command is used to request the Controller

to start or stop advertising.
The Controller shall continue advertising until the Host issues an

LE_Set_Advertisinge_Enable command with Advertising_Enable set to 0x00
(Advertising is disabled) or until a connection is created or until the Advertising
is timed out due to high duty cycle Directed Advertising.
Status: Size: 1 Octet

Value Parameter Description
0x00 LE_Set_Advertisinge_Enable command succeeded.
0x01 – 0xFF LE_Set_Advertisinge_Enable command failed. See [Vol 2] Part D,

Error Codes for a list of error codes and descriptions.
When the LE_Set_Advertisinge_Enable command has completed, a

Command Complete event shall be generated.
1. This command was formerly called “LE Set Advertise Enable”.
7.8.10 LE Set Scan Parameters Command
EDITOR’S NOTE: Section 3.5: Add text to LE Set Random Address Command
Summary description. Section 7.8.10: Change “advertisement packets” to
“advertising packets.”

Section 3.5
LE Set Random Address 4.0 The LE Set Random Address LE

Command Command will set the Random
Device Address that may be
used in an advsertising packeta
packet sent on an advertising
PHY channel.
Section 7.8.10
All changes below apply to v4.2. Changes in rows 0x00 and 0x01 also
apply to v4.1 and v4.0.
Scanning_Filter_Policy: Size: 1 Octet

0x00 Accept all

• advertisingement packets except directed advertising packets not
addressed to this device (default).
0x01 Accept only

• advertisingement packets from devices where the advertiser’s
address is in the White List.
• Directed advertising packets which are not addressed for this device
shall be ignored.
0x02 Accept all

• undirected advertisingement packets, and
• directed advertising packets where the initiator address is a
resolvable private address, and
• directed advertising packets addressed to this device.
0x03 Accept all

• advertisingement packets from devices where the
advertiser’s address is in the White List, and
11.10 E6356 – Defining scanner’s device address in “Scanner

filter policy”

Core Section(s) affected: 3.14 Host Flow Control
3.19 LE Controller Requirements
6.27 Supported Commands
7.8.38 LE Add Device to Resolving List Command
7.8.78 LE Set Privacy Mode Command
EDITOR’S NOTE: Revise tables and text as shown below
Section 3.14
Supported
LE Set Privacy Mode 4.2 The LE Set Privacy Mode command LE

is used to allow the Host to specify
the privacy mode for an entry on the
resolving list.
Section 3.19.
LE Read Local Resolvable Address Command C10
LE Set Privacy Mode C10
Section 6.27
Octet Bit Command Supported
39 0 Reserved for future use
1 Reserved for future use
2 ReservedLE Set Privacy Mode
Editor’s note: only applies to v4.2, 4.1, and 4.0.
Section 7.8.38
This command can be used at any time when address translation is disabled in
the Controller.

The added device shall be set to Network Privacy mode.
Editor’s note: only applies to v4.2.
Add new section at the end of the “LE Controller Commands”. In

Shanghai r07b it is section 7.8.77. In v4.2 it will be section 7.8.47. In v4.1 it
will be section 7.8.33.
Issue 7566 comment ID 25075: add new paragraph (Events generated

unless masked away) at the end of section 7.8.77.
7.8.77 LE Set Privacy Mode Command
Return
Command OCF Command Parameters Parameter
HCI_LE_Set_Privacy_Mode 0x004E Peer_Identity_Address_- Status

Type,
Peer_Identity_Address,
Privacy_Mode
Description:
The HCI_LE_Set_Privacy_Mode command is used to allow the Host to specify

the privacy mode to be used for a given entry on the resolving list. The effect of
this setting is specified in [Vol 6] Part B, Section 4.7.
When an entry on the resolving list is removed, the mode associated with that
entry shall also be removed.
This command cannot be used when address translation is enabled in the

Controller and:
• Advertising is enabled
• Scanning is enabled
• Create connection command is outstanding
This command can be used at any time when address translation is disabled in
the Controller.
If the device has not been added to the resolving list, the command shall be
rejected using the error code Unknown Connection Identifier (0x02).
Command Parameters:
Peer_Identity_Address_Type: Size: 1 Octet

0x00 Public Identity Address
0x01 Random (static) Identity Address

All other values Reserved for future use
Peer Identity_Address: Size: 6 Octets

0xXXXXXXXXXX Public Identity Address, or Random (static) Identity Address of the

XX advertiser
Privacy_Mode: Size: 1 Octet

0x00 Use Network Privacy Mode for this peer device (default)
0x01 Use Device Privacy Mode for this peer device
All other values Reserved for future use
Return Parameters:
Status: Size: 1 Octet

0x00 HCI_LE_Set_Privacy_Mode command succeeded
0x01 - 0xFF HCI_LE_Set_Privacy_Mode command failed. See [Vol 2] Part D, Error

Codes for a list of error codes and descriptions.
Event(s) Generated (unless masked away):
When the HCI_LE_Set_Privacy_Mode command has completed, a Command

Complete event shall be generated.
11.11 E6508 – HCI command name mismatch
E6508 4.2 Vol 2, Part E Host Controller Interface
Core Section(s) affected: 3.19 LE Controller Requirements (Table 3.20)
EDITOR’S NOTE: Change “LE Set Random Private Address Timeout

Command” to “LE Set Resolvable Private Address Timeout Command” in
Table 3.20. See Section 11.12.

11.12 E6716 – Wrong condition
Core Section(s) affected: 3.19 LE Controller Requirements (Table 3.20)
EDITOR’S NOTE: Change C7 Command to C13. Add C13 to Conditionals..
Set Event Mask Page 2 Command C713
LE Set Randomesolvable Private Address Timeout Command C9
Table 3:20: Bluetooth Controller supporting LE requirements
C13:Mandatory if LE Feature (LE Ping) is supported, otherwise optional.
Version 4.1
C8:Mandatory if LE Feature (LE Ping) is supported, otherwise optional.
11.13 E6452 – Bad descriptions of connection handles
Core Section(s) affected: 4.1.1 Packet-based Data Flow Control
4.3 Disconnection Behavior
5.3 Handles
5.3.1 Primary Controller Handles
5.3.1.1 Broadcast Connection_Handles
5.3.2 AMP Controller Handles
7.1.6 Disconnect Command
7.1.14 Change Connection Packet Type Command
7.1.15 Authentication Requested Command
7.1.16 Set Connection Encryption Command

7.1.17 Change Connection Link Key Command
Read Remote Supported Features

7.1.21 Command
7.1.22 Read Remote Extended Features Command
7.1.23 Read Remote Version Information Command
7.1.24 Read Clock Offset Command
7.1.25 Read LMP Handle Command
7.1.26 Setup Synchronous Connection Command
Enhanced Setup Synchronous Connection

7.1.45 Command
7.2.1 Hold Mode Command
7.2.2 Sniff Mode Command
7.2.3 Exit Sniff Mode Command
7.2.6 QoS Setup Command
7.2.7 Role Discovery Command
7.2.9 Read Link Policy Settings Command
7.2.10 Write Link Policy Settings Command
7.2.13 Flow Specification Command
7.2.14 Sniff Subrating Command
7.3.4 Flush Command
7.3.29 Read Automatic Flush Timeout Command
7.3.30 Write Automatic Flush Timeout Command
7.3.35 Read Transmit Power Level Command
Write Synchronous Flow Control Enable

7.3.37 Command
Set Controller To Host Flow Control Com-

7.3.38 mand
7.3.39 Host Buffer Size Command

Host Number Of Completed Packets

7.3.40 Command
7.3.41 Read Link Supervision Timeout Command
7.3.42 Write Link Supervision Timeout Command
7.3.57 Refresh Encryption Key Command
7.3.66 Enhanced Flush Command
Read Enhanced Transmit Power Level

7.3.74 Command

7.3.93 Command
Write Authenticated Payload Timeout

7.3.94 Command
7.4.5 Read Buffer Size Command
7.5.2 Reset Failed Contact Counter Command
7.5.4 Read RSSI Command
7.5.5 Read AFH Channel Map Command
7.5.6 Read Clock Command
7.5.7 Read Encryption Key Size Command
7.5.12 Set Triggered Clock Capture Command
Write Secure Connections Test Mode

7.6.8 Command
7.7.3 Connection Complete Event
7.7.8 Encryption Change Event
Change Connection Link Key Complete

7.7.9 Event
7.7.10 Master Link Key Complete Event
Read Remote Supported Features

7.7.11 Complete Event
Read Remote Version Information Complete

7.7.12 Event
7.7.13 QoS Setup Complete Event

7.7.19 Number Of Completed Packets Event
7.7.28 Read Clock Offset Complete Event
7.7.32 Flow Specification Complete Event
Read Remote Extended Features Complete

7.7.34 Event
7.7.35 Synchronous Connection Complete Event
7.7.36 Synchronous Connection Changed Event
7.7.39 Encryption Key Refresh Complete Event
7.7.46 Link Supervision Timeout Changed Event
7.7.65 LE Meta Event
7.7.65.3 LE Connection Update Complete Event
LE Read Remote Used Features Complete

7.7.65.4 Event
7.7.65.5 LE Long Term Key Request Event
LE Remote Connection Parameter Request

7.7.65.6 Event
7.7.65.7 LE Data Length Change Event
7.7.65.10 LE Enhanced Connection Complete Event
7.7.66 Triggered Clock Capture Event
Authenticated Payload Timeout Expired

7.7.75 Event
7.7.76 SAM Status Change Event
7.8.2 LE Read Buffer Size Command
7.8.18 LE Connection Update Command
7.8.20 LE Read Channel Map Command
7.8.21 LE Read Remote Used Features Command
7.8.24 LE Start Encryption Command
7.8.25 LE Long Term Key Request Reply Command

LE Long Term Key Request Negative Reply

7.8.26 Command

7.8.31 Reply Command

7.8.32 Negative Reply Command
7.8.33 LE Set Data Length Command
A.5 Add SCP Connection Command
EDITOR’S NOTE: Revise text and change all occurrences of “Connection

Handle” (irrespective of case) within HCI to “Connection_Handle” (with that
capitalization and underscore). A trailing “s” shall be retained. In tables, delete
text before and after “Connection_Handle”. See examples below:
Connection_Handle: Size: 2 Octets (12 Bits meaningful)

0xXXXX Connection_Handle for the connection being disconnected.

Range: 0x0000-0x0EFF (0x0F00 - 0x0FFF Reserved for future use)
Section 4.1.1
The Host chooses the Connection_ Handles for the following HCI Data Packets
based on the information returned in this event, and/or the LE Read Buffer Size
commands.
Section 4.3
When the Host receives a Disconnection Complete, Disconnection Physical
Link Complete or Disconnection Logical Link Complete event, the Host shall
assume that all unacknowledged HCI Data Packets that have been sent to the
Controller for the returned Handle have been flushed, and that the
corresponding data buffers have been freed. A Primary Controller does not
have to notify the Host about this in a Number Of Completed Packets event,
nor does the AMP Controller have to notify the Host about this in a Number Of
Completed Data Blocks event, before the disconnection event (and must not
do so afterwards because the Connection_Handle is no longer valid).
Section 5.3
Three types of handles are used to identify logical channels between the Host
and a Controller: Connection HandleConnection_Handles, Logical Link
Handles, and Physical Link Handles.
Section 7.1.15
Note: The Connection_Handle command parameter is used to identify the
other BR/EDR Controller, which forms the connection. The Connection_Handle

should be a Connection_Handle for an ACL connection. The authentication will

apply to all Connection_Handles with the same remote BR/EDR Controller.
Section 7.1.16
The Set_Connection_Encryption command is used to enable and disable the
link level encryption. Note: the Connection_Handle command parameter is
used to identify the other BR/EDR Controller which forms the connection. The
Connection_Handle should be a Connection_Handle for an ACL connection.
The encryption setting will apply to all Connection_Handles with the same
remote BR/EDR Controller. While the encryption is being changed, all ACL
traffic must be turned off for all Connection_Handles associated with the
remote device.
Section 7.3.57
This command is used by the Host to cause the BR/EDR Controller to refresh
the encryption key on an ACL connection identified by a Connection_Handle
by pausing and resuming encryption.
Section 7.5.6
Connection_Handle: Size: 2 Octets (12 Bits meaningful)
0xXXXX The Connection_Handle for the connection for which the master clock has
been read. If the Which_Clock parameter was 0, then the Connec-
tion_Handle shall be set to 0 and ignored upon receipt.
Range: 0x0000-0x0EFF (0x0F00 – 0x0FFF Reserved for future use)
Section 7.7.8
The Encryption Change event is used to indicate that the change of the
encryption mode has been completed. The Connection_Handle will be a
Connection_Handle for an ACL connection and is used to identify the remote
device. The Encryption_Enabled event parameter specifies the new
Encryption_Enabled parameter for the Connection_Handle specified by the
Connection_Handle event parameter. This event will occur on both devices to
notify the Hosts when Encryption has changed for the specified
Connection_Handleall connections between the two devices. Note: This event
shall not be generated if encryption is paused or resumed; during a role switch,
for example.
Section 7.7.9
The Change Connection Link Key Complete event is used to indicate that the
change in the Link Key for the Connection_Handle specified by the
Connection_Handle event parameterall connections to a given remote BR/
EDR Controller has been completed.
The Connection_Handle will be a Connection_Handle for an ACL connection to

the remote Controller. The Change Connection Link Key Complete event is
sent only to the Host which issued the Change_Connection_Link_Key
command.

Section 7.7.10
The Master Link Key Complete event is used to indicate that the Link Key
managed by the master of the piconet has been changed. The
Connection_Handle will be a Connection_Handle for an ACL connection within
that piconet. The link key used for the connection will be the temporary link key
of the master device or the semi-permanent link key indicated by the Key_Flag.
The Key_Flag event parameter is used to indicate which Link Key (temporary
link key of the Master, or the semi-permanent link keys) is now being used in
the piconet.
Section 7.7.76
The SAM Status Change event indicates that the Controller has changed the
SAM status for the connection identified by the Connection_Handle; i.e., a new
SAM slot map has been enabled or the existing one disabled. Note: A change
from one SAM slot map to another only generates one event, not two.
11.14 E6541 – Number of Completed Packets after

disconnection
Core Section(s) affected: 4.3 Disconnection Behavior
7.719 Number of Completed Packets Event
EDITOR’S NOTE: Insert text to Section 4.3. Insert/delete text to 7.7.19.
Section 4.3
[...] A Primary Controller does not have to notify the Host about this in a
Number Of Completed Packets event, nor does the AMP Controller have to
notify the Host about this in a Number Of Completed Data Blocks event, before
the disconnection event (and must not do so afterwards because the
connection handle is no longer valid).
Section 7.7.19
[...] The Number Of Completed Packets event must not be sentshall not specify
a given connection handle before the corresponding Connection Complete
event for the corresponding connection or after an event indicating
disconnection of the corresponding connection.

11.15 E7024 – There is no NOP command
Core Section(s) affected: 4.4 Command Flow Control
5.4.1 HCI Command Packet
7.7.14 Command Complete Event
7.7.15 Command Status Event
Section 4.4
To indicate to the Host that the Controller is ready to receive HCI command
packets, the Controller may generate a Command Complete or Command
Status event with the Command Opcode set to 0x0000, and the Num HCI
Command Packets event parameter is set to 1 or more. Command Opcode
0x0000 is a NOP (No OPeration),special value indicating that this event is not
associated with a command sent by the Host. The Controller can send a
Command Complete or Command Status event with Command Opcode
0x0000 at any time and can be used to change the number of outstanding HCI
command packets that the Host can send before waiting. The Controller may
generate a Command Complete or Command Status event with the Num HCI
Command Packets event parameter set to zero to inform the Host that it must
stop sending commands.
Section 5.4.1
Note: The OGF composed of all ‘zeros’ and an OCF or all ‘zeros’ is the NOP
command. This command Opcode may be used in Command Flow Control.
(See Section 4.4.)
Section 7.7.14
[...] To indicate to the Host that the Controller is ready to receive HCI command
packets, the Controller generates a Command Complete event with the
Command_Opcode set to 0x0000, and the Num_HCI_Command_Packets
event parameter is set to 1 or more. Command_Opcode, 0x0000 is a NOP (No
OPeration),special value indicating that this event is not associated with a
command sent by the Host. The Controller can send a Command Complete
event with Command Opcode 0x0000 at any time and can be used to change
the number of outstanding HCI command packets that the Host can send
before waiting. See each command for the parameters that are returned by this
event.

Command_Opcode: Size: 2 Octets

0x0000 No associated command
0xXXXX (non-zero) Opcode of the command which caused this event
Section 7.7.15
[...] To indicate to the Host that the Controller is ready to receive HCI command
packets, the Controller generates a Command Status event with Status 0x00
and Command_Opcode 0x0000, and the Num_HCI_Command_Packets event
parameter is set to 1 or more. Command_Opcode, 0x0000 is a NOP (No
OPeration)special value indicating that this event is not associated with a
command sent by the Host. The Controller can send a Command Status event
with Command Opcode 0x0000 at any time and can be used to change the
number of outstanding HCI command packets that the Host can send before
waiting.
Command_Opcode: Size: 2 Octets

0x0000 No associated command
0xXXXX (non-zero) Opcode of the command which caused this event and is pending
completion.
11.16 E6882 – Fragmentation of data packets in 27 octets

after LE Data Length Change Event
Core Section(s) affected: 4.4.1 Packet-based Data Flow Control
5.4.2 HCI ACL Data Packets
EDITOR’S NOTE: Revise text as shown
Section 4.1.1
HCI ACL Data Packets on an LE-U logical link shall be 27 octets or larger. A
Host shall not fragment HCI ACL Data Packetsan L2CAP message on an LE-U
logical link that areis 27 octets or less in length.

Section 5.4.2 (v4.2 only)

[...] The format of the HCI ACL Data Packet is shown in Figure 5.2. The
definition for each of the fields in the data packets is explained below.
Hosts and Controllers shall be able to accept HCI ACL Data Packets with up to
27 bytes of data excluding the HCI ACL Data Packet header on
Connection_Handles associated with an LE-U logical link.The HCI ACL Data
Packet header is the first 4 octets of the packet.
Section 7.8.2
HC_LE_Data_Packet_Length: Size: 2 Octets
0x0000 No dedicated LE Buffer – use Read_Buffer_Size command.
0x0001 – 0x001A Reserved
0x00011B – 0xFFFF Maximum length (in octets) of the data portion of each HCI ACL
Data Packet that the Controller is able to accept.
11.17 E6556 – LE Enhanced Connection Complete event is

not always mentioned
Core Section(s) affected: 4.5 Command Error Handling
5.3.1 Primary Controller Handles
7.7.65.1 LE Connection Complete Event
7.8.9 LE Set Advertise Enable Command
7.8.13 LE Create Connection Cancel Command
EDITOR’S NOTE: Revise text as shown below for each section:
Section 4.5
The above also applies to commands that have associated command specific
completion events with a status parameter in their completion event, with
fourfive exceptions. The first two exceptions are the Connection Complete and
the Synchronous Connection Complete events. On failure, for these two events
only, the second parameter, Connection_Handle, is not valid and the third
parameter, BD_ADDR, is valid for identification purposes. The third exception
isnext two exceptions are the LE Connection Complete and LE Enhanced

Connection Complete events. On failure, the Status parameter is valid, all other
parameters are not valid. The fourthfinal exception is the Logical Link
completion event. [...]
Section 5.3.1
[...] Connection Handles are assigned by the Primary Controller when a new
logical link is created, using the Connection Complete, Synchronous
Connection Complete, or LE Connection Complete, or LE Enhanced
Connection Complete events. Broadcast Connection Handles are handled
differently, and are described in Section 5.3.1.1.
Section 7.7.65.1
The Master_Clock_Accuracy parameter is only valid for a slave. On a master,
this parameter shall be set to 0x00.
Note: This event is not sent if the LE Enhanced Connection Complete event
(see Section 7.7.65.10) is unmasked.
Section 7.8.9
If the Advertising_Type parameter is 0x01 (ADV_DIRECT_IND, high duty
cycle) and the directed advertising fails to create a connection, an LE
Connection Complete or LE Enhanced Connection Complete event shall be
generated with the Status code set to Directed Advertising Timeout (0x3C).
If the Advertising_Type parameter is 0x00 (ADV_IND), 0x01

(ADV_DIRECT_IND, high duty cycle), or 0x04 (ADV_DIRECT_IND, low duty
cycle) and a connection is created, an LE Connection Complete or LE
Enhanced Connection Complete event shall be generated.
Section 7.8.13
[...] This command shall only be issued after the LE_Create_Connection
command has been issued, a Command Status event has been received for
the LE Create Connection command and before the LE Connection Complete
or LE Enhanced Connection Complete event.
If the cancellation was successful then, after the Command Complete event for
the LE_Create_Connection_Cancel command:
• if the LE Enhanced Connection Complete event is unmasked, then that
event shall be sent.
• otherwise the LE Connection Complete or LE Enhanced Connection
Complete event shall be sent.

11.18 E6767 – Incorrect figure numbering
Core Section(s) affected: 5 HCI Data Formats
7 HCI Commands And Events
EDITOR’S NOTE: Update template to correct Figure numbering
Section 5.4.2
[...] The format of the HCI ACL Data Packet is shown in Figure 5.12. The
definition for each of the fields in the data packets is explained below.[...]
Figure 5.12: HCI ACL Data Packet
Section 5.4.3
[...]The format of the synchronous Data Packet is shown in Figure 5.13. The
definition for each of the fields in the data packets is explained below.[...]
Figure 5.13: HCI Synchronous Data Packet
Section 5.4.4
[...]The format of the HCI Event Packet is shown in Figure 5.14, and the
definition of each field is explained below.[...]
Figure 5.14: HCI Event Packet
Section 7.6.8
See Figure 7.13, where the rightmost device has the eSCO_Loopback_Mode
parameter set to enabled and the leftmost device is in a normal mode of
operation.[...]
Figure 7.13: Secure Connections eSCO Loopback
Figure 7.24: Secure Connections eSCO loopback immediate
Figure 7.35: Secure Connections eSCO loopback delayed
Figure 7.46: Secure Connections eSCO loopback delayed with retransmissions
11.19 E6856 – Use standard convention
Core Section(s) affected: 5.4.2 HCI ACL Data Packets

EDITOR’S NOTE: Add “b” suffix to values as shown below
Packet_Boundary_Flag: Size: 2 Bits

Parameter ASB-U
Value ACL-U AMP-U LE-U
Description PSB-U
00b First non-auto- Host to Not Allowed Not Allowed

matically-flush- Controller allowed allowed
able packet of
Higher Layer Controller Not Not Not Not
Message (start of to Host allowed allowed allowed allowed
a non-automati- (except
cally-flushable during
L2CAP PDU) from loopback)
Host to Controller.
01b Continuing frag- Host to Allowed Allowed Not Allowed

ment of Higher Controller allowed
Layer Message
Controller Allowed Allowed Not Allowed
to Host allowed
10b First automati- Host to Allowed Allowed Not Not

cally flushable Controller allowed Allowed
packet of Higher
Layer Message Controller Allowed Allowed Not Allowed
(start of an auto- to Host allowed
matically-flush-
able L2CAP
PDU).
11b A complete Host to Not Not Allowed Not

L2CAP PDU. Controller allowed Allowed Allowed
Automatically
flushable. Controller Not Not Allowed Not
to Host allowed Allowed Allowed
The start of a non-flushable packet of a Higher Layer Message (start of a non-

automatically-flushable L2CAP PDU) with the PBF of 00b shall be transmitted
with an LLID of 10b. All continuing fragment packets of a Higher Layer
Message shall be transmitted with an LLID of 01b.
Broadcast_Flag (in packet from Host to Controller): Size: 2 Bits

00b No broadcast. Only point-to-point (this is the only valid option for AMPs).
01b Active Slave Broadcast: packet is sent to all active slaves (i.e. packet is
usually not sent during park beacon slots), and it may be received by
slaves in sniff mode or park state.
10b Parked Slave Broadcast: packet is sent to all slaves and all slaves in park
state (i.e. packet is sent during park beacon slots if there are parked
slaves), and it may be received by slaves in sniff mode.

11b Reserved for future use.
Broadcast_Flag (in packet from Controller to Host): Size: 2 Bits

00b Point-to-point
01b BBR/EDR Packet received as a slave not in park state (either Active Slave
Broadcast or Parked Slave Broadcast)
10b BR/EDR Packet received as a slave in park state (Parked Slave Broad-
cast)
11b Reserved for future use.
11.20 E6857 – Use standard convention
Core Section(s) affected: 5.4.3 HCI Synchronous Data Packets
EDITOR’S NOTE: Add suffix “b”
The Host shall set the Packet_Status_Flag bits to 00b.
If the Erroneous_Data_Reporting parameter was set to disabled when the

synchronous connection was created, the Controller shall set the
Packet_Status_Flag bits to 00b and whether or not data is provided for cases
when a valid (e)SCO packet was not received is unspecified.

Packet_Status_Flag (in packets sent by the Controller) Size: 2 Bits

00b Correctly received data. The payload data belongs to received eSCO or
SCO packets that the baseband marked as “good data”.
01b Possibly invalid data. At least one eSCO packet has been marked by the
baseband as “data with possible errors” and all others have been marked
as “good data” in the eSCO interval(s) corresponding to the HCI Synchro-
nous Data Packet.
10b No data received. All data from the baseband received during the (e)SCO
interval(s) corresponding to the HCI Synchronous Data Packet have been
marked as "lost data" by the baseband. The Payload data octets shall be
set to 0.
11b Data partially lost. Not all, but at least one (e)SCO packet has been
marked as “lost data” by the baseband in the (e)SCO intervals corre-
sponding to the HCI Synchronous Data Packet. The payload data octets
corresponding to the missing (e)SCO packets shall be set to 0.
11.21 E6493 – Mysterious text in table
Core Section(s) affected: 6.1 Scan Enable
EDITOR’S NOTE: Delete text in last row of table
0x00 No Scans enabled.
0x01 Inquiry Scan enabled.

Page Scan always disabled.
0x02 Inquiry Scan disabled.

Page Scan enabled.
0x03 Inquiry Scan enabled.

Page Scan enabled.
0x04-0xFF Reserved [0x04 limited page scan removed]

11.22 E6986 – Minor inconsistency in handling deprecated

text
Core Section(s) affected: 6.10
A.10.3 Page Scan Period Mode
EDITOR’S NOTE: Move text from section 6.10 to a new section A.10.3 as
shown below
Section 6.10
6.10 Page Scan Period Mode (Deprecated)This section no longer used
Every time an inquiry response message is sent, the BR/EDR Controller will
start a timer (T_mandatory_pscan), the value of which is dependent on the
Page_Scan_Period_Mode. As long as this timer has not expired, the BR/EDR
Controller will use the mandatory page scan mode for all following page scans.
Note: The timer T_mandatory_pscan will be reset at each new inquiry

response. For details see [Vol 2] Part B, Baseband Specification.
0x00 P0
0x01 P1
0x02 P2
0x03-0xFF Reserved
Section A.10.3
A.10.3 Page Scan Period Mode
Every time an inquiry response message is sent, the BR/EDR Controller will
start a timer (T_mandatory_pscan), the value of which is dependent on the
Page_Scan_Period_Mode. As long as this timer has not expired, the BR/EDR
Controller will use the mandatory page scan mode for all following page scans.

Note: The timer T_mandatory_pscan will be reset at each new inquiry

response. For details see [Vol 2] Part B, Baseband Specification.
0x00 P0
0x01 P1
0x02 P2
0x03-0xFF Reserved
11.23 E6749 – Time Default value for

synchronization_trainTO
E6749 4.2 4.1 CSA4 Vol 2, Part E Host Controller Interface
Core Section(s) affected: 6.37 Synchronization Train Timeout
EDITOR’S NOTE: Change “Time Default: 120 msec” to “Time Default: 120 s”
as shown below
synchronization_trainTO: Size: 4 Octets

N = 0xXXXXXXXX Range: 0x00000002 to 0x07FFFFFE; only even values are valid

Default: 0x0002EE00
Mandatory Range: 0x00000002 to 0x07FFFFFE
Time = N * 0.625 msecms
Time Range: 1.25 msecms to 23.3 hours
Time Default: 120 msecs
11.24 E6918 – Consistency of bold v roman
Core Section(s) affected: 7.3.47 Read Inquiry Scan Type Command

7.3.48 Write Inquiry Scan Type Command
7.3.56 Write Extended Inquiry Response Command
7.3.59 Write Simple Pairing Mode Command
Write Default Erroneous Data Reporting

7.3.65 Command
7.3.77 Short Range Mode Command
7.3.96 Read Extended Page Timeout Command
7.3.98 Read Extended Inquiry Length Command
7.6.1 Read Loopback Mode Command
7.6.2 Write Loopback Mode Command
7.6.4 Write Simple Pairing Debug Mode Command
7.8.5 LE Set Advertising Parameters Command
7.8.7 LE Set Advertising Data Command
7.8.8 LE Set Scan Response Data Command
7.8.10 LE Set Scan Parameters Command
EDITOR’S NOTE: Change font weight of “default” from bold to roman/unbold

from Command Parameters tables in the sections listed above.
11.25 E6752 – Wrong minimum for

HC_LE_Data_Packet_Length
Core Section(s) affected: 7.4.5 Read Buffer Size Command
EDITOR’S NOTE: Remove text from sections as shown below

Section 7.4.5 (4th paragraph under Description)

[...]The HC_Synchronous_Data_Packet_Length return parameter is used to
determine the maximum size of HCI synchronous Data Packets. Both the Host
and the Controller must support command and event packets, where the data
portion (excluding header) contained in the packets is 255 octets in size. The
HC_Total_Num_ACL_Data_Packets return parameter contains the total
number of HCI ACL Data Packets that can be stored in the data buffers of the
Controller. [...]
Section 7.8.2 (4th paragraph under Description)

[...] contained in ACL Data Packets, which are transferred from the Host to the
Controller to be broken up into packets by the Link Layer. Both the Host and
the Controller shall support command and event packets, where the data
portion (excluding header) contained in the packets is 255 octets in size. The
HC_Total_Num_LE_ACL_Data_Packets return parameter contains [...]
11.26 E6534 – Typo in command name
Core Section(s) affected: 6.37 Synchronization Train Timeout
EDITOR’S NOTE: Fix typo
The synchronization_trainTO configuration parameter is used by the controller

to terminate the Synchronization Train after it has been started via the
HCI_Start_Synchronization_Train command.
11.27 E7068 – Consistent style for error codes
Core Section(s) affected: 7 HCI Commands and Events

EDITOR’S NOTE: When a specific error code appears in a command or event

description the name should be in italics and the numeric code should be
given. [12 instances were updated in current version]
11.28 E7069 – Consistent wording for dealing with errors
E7069 4.2 4.1 4.0 3.0 2.1, Vol 2, Part E Host Controller Interface
CSA4
Core Section(s) affected: 7 HCI Commands and Events
EDITOR’S NOTE: In the following 14 commands the wording dealing with error
codes has been aligned to what is used in the rest of Section 7. That is, a
wording along the lines of:
"If [some problem occurs], the Controller shall return the error code Encryption
Mode Not Acceptable (0x25)"
Section 7.1.26 Setup Synchronous Connection Command

If the ACL link has encryption enabled using AES-CCM and the Controller can-
not establish an eSCO transport (e.g. the Host parameters restricting the
packet types to only SCO packet types), the Controller shall return the Eerror
code 0x0E (Connection Rejected Due to Security Reasons (0x0E) shall be
returned and a SCO transport will not be established.
Section 7.1.27 Accept Synchronous Connection Request Command

Same change as 7.1.26 above.
Section 7.1.36 IO Capability Request Negative Reply Command

The Eerror code 0x37 (Simple Pairing not Supported by Host (0x37) shall not
be used in the Reason parameter.
Section 7.3.42 Write Link Supervision Timeout Command

This command writes the value for the Link_Supervision_Timeout parameter
for a BR/EDR or AMP Controller. For BR/EDR Controllers,If the Host issues
this command shall only be issued on the master for the givenwith a Connec-
tion_Handle[E6452]. If this command is issued on a which identifies a BR/EDR
connection where the Controller is the slave, the command shall be rejected by
the BR/EDR cController withshall return the error code Command Disallowed
(0x0C). The command may be issued to any AMP Controller without restriction
to role.
Section 7.1.45 Enhanced Setup Synchronous Connection Command

Section 7.1.46 Enhanced Accept Synchronous Connection Request

Command
Section 7.3.92 Write Secure Connections Host Support Command

If the Host has not written Tthis parameter shall be written before initiating page
scan or paging procedures, otherwise this command shall be rejected withthe
Controller shall return the error code Command Disallowed (0x0C).
Section 7.3.93 Read Authenticated Payload Timeout Command

When the Connection_Handle identifies a BR/EDR synchronous connection,
this command shall be rejected withthe Controller shall return the error code
Command Disallowed (0x0C).[E6532]
Section 7.8.12 LE Create Connection Command

If Tthe Host shall not issues this command when another LE_Create_Connec-
tion is pending in the Controller;, if this does occur the Controller shall return
the error code Command Disallowed error code(0x0C).
Section 7.8.16 LE Add Device To White List Command

When a cController cannot add a device to the list because there is no space
available, it shouldshall respond withreturn the error code 0x07 (Memory
Capacity Exceeded (0x07).[E6559]
Section 7.8.38 LE Add Device to Resolving List Command

When a Controller cannot add a device to the list because there is no space
available, it shall respond withreturn the error code 0x07 (Memory Capacity
Exceeded (0x07).[E6559]
Section 7.8.39 LE Remove Device From Resolving List Command

When a Controller cannot remove a device from the resolving list because it is
not found, it shall respond with the error code 0x02 (Unknown Connection
Identifier (0x02).
Section 7.8.42 LE Read Peer Resolvable Address Command

When a Controller cannot find a Resolvable Private Address associated with
the Peer Identity Address, it shall respond with the error code 0x02 (Unknown
Connection Identifier (0x02).
Section 7.8.43 LE Read Local Resolvable Address Command


11.29 E7067 – Wrong error name and style of error codes
Core Section(s) affected: 7.1.40 Create Logical Link Command
EDITOR’S NOTE: Revise the third paragraph as shown below
The AMP Controller may refuse to create the logical link if it has insufficient
resources. If the AMP Controller is already in the process of creating one or
more logical links, it may reject a Create Logical Link command with the error
code "Busy"Controller Busy (0x3A) (see [Vol 2] Part D, Section 2.55. [...]
11.30 E6536 – Minimum parameter values incorrect
Core Section(s) affected: 7.1.52 Receive Synchronization Train Command
EDITOR’S NOTE: Change Parameter Descriptions
synchronization_scanTO: Size: 2 Octets

N = 0xXXXX Duration in slots to search for the synchronization train

Range: 0x0022-0xFFFE; only even values are validShall be greater
than or equal to Sync_Scan_Window; only even values are valid
Sync_Scan_Interval: Size: 2 Octets

N = 0xXXXX Duration in slots between the start of consecutive scan windows

Range: 0x0002-0xFFFE; only even values are validShall be greater
than or equal to Sync_Scan_Window+0x0002; only even values
are valid

11.31 E6566 – Wrong command name
Core Section(s) affected: 7.1.6 Disconnect Command
EDITOR’S NOTE: Correct command name under Description
The Disconnection command is used to terminate an existing connection. The

Connection_Handle command parameter indicates which connection is to be
disconnected. The Reason command parameter indicates the reason for
ending the connection.[...]
11.32 E6576 – Unmatched parenthesis
Core Section(s) affected: 7.1.41 Accept Logical Link Command
EDITOR’S NOTE: Delete extra closing parenthesis
Tx_Flow_Spec: Size: 16 Octets

Parameter Description
Extended Flow Specification value defining transmitted traffic (see [Vol 3] Part A, Section
5.6)).
11.33 E6927 – Use simpler descriptions of bit-fields
Core Section(s) affected: 7.1.47 Truncated Page Command

EDITOR’S NOTE: Revise the parameter Clock_Offset table as shown below
Bits 14-0 Bits 16-2 of CLKNslave-CLK
Bit 15 0 = Clock_Offset is invalid

1 = Clock _ Offset is valid
11.34 E4761 – Inconsistent use of Authentication Enable

parameter
Core Section(s) affected: 7.3.23 Read Authentication Enable Command
EDITOR’S NOTE: Change cross-reference from 10.10.1 to 6.16
This command reads the value for the Authentication_Enable configuration

parameter. See Section 6.16 Authentication Enable10.10.1 on page 869.
11.35 E6451 – Spelling error in name
Read Enhanced Transmit Power Level Com-

Core Section(s) affected: 7.3.74 mand
EDITOR’S NOTE: Correct Command name
Command Return
Command OCF Parameters Parameters
HCI_Read_ 0x0068 Connection_Handle, Status,

Enhanced_ Type Connection_Handle,
Transmit_Power_ Transmit_Power_Level_GFSK,
Level Transmit_Power_Level_DQPSK,
Transmit_Power_Level_8DPSK

11.36 E4999 – Restrictions on type 4 pattern intervals
E4999 4.2 4.1 4.0 CSA3 Vol 2, Part E Host Controller Interface
Set MWS_PATTERN Configuration Com-

Core Section(s) affected: 7.3.85 mand
EDITOR’S NOTE: Add a new paragraph after the third paragraph.
If any interval with type 4 either has a MWS_PATTERN_IntervalDuration

greater than the length of a frame or the sum of the
MWS_PATTERN_IntervalDuration parameters for the previous intervals is not
a multiple of the length of the frame, the Controller shall return the error code
Invalid HCI Command Parameters (0x12).
11.37 E6532 – Reference to BR/EDR controller should be

changed to Primary Controller

Core Section(s) affected: 7.3.93 Command
EDITOR’S NOTE: Revise text and add new paragraph to Description
This command reads the Authenticated_Payload_Timeout

(authenticatedPayloadTO, see [Vol 2] Part B, Section Appendix B for BR/EDR
connections and [Vol 6] Part B, Section 5.4 for the LE connections) parameter
in the BR/EDRPrimary Controller on the specified Connection_Handle.
When the Connection_Handle identifies a BR/EDR synchronous connection,

this command shall be rejected with the error code Command Disallowed
(0x0C).

11.38 E5003 – How are To_MWS and From_MWS baud rates

related
Get MWS Transport Layer Configuration

EDITOR’S NOTE: Add a new paragraph at the end of the Description as shown
below
The From_MWS_Baud_Rate parameters indicate the supported baud rates in

the direction from MWS to Bluetooth for each transport.
If one direction has more supported rates than the other direction, the
Controller shall - in the direction with less supported rates - fill with sufficient
zeros to produce the same number of values. The rates for the two directions
are not necessarily paired.

implementation redux
Core Section(s) affected: 7.5.12 Set Triggered Clock Capture Command
EDITOR’S NOTE: Replace text in fourth paragraph.
The LPO_Allowed parameter informs the BR/EDR Controller whether the low
power oscillator is allowed to be used,it may use a lower accuracy clock or not.
11.40 E6997 – Which controller types does Hardware Error

Event apply to?
Core Section(s) affected: 7.7.16 Hardware Error Event

The Hardware Error event is used to indicate some type of hardware failure for
the BR/EDR Controller. This event is used to notify the Host that a hardware
failure has occurred in the Controller.
11.41 E6563 – Which event does the Controller send when

connection establishment fails?
Vol 6, Part D Message Sequence Charts Section 26.2
Core Section(s) affected: 7.7.65.1 LE Connection Complete Event
7.7.65.10 LE Enhanced Connection Complete Event
EDITOR’S NOTE: Revise text under the Description for 7.7.65.1 and 7.7.65.10
and under Event(s) Generated for 7.8.9
Section 7.7.65.1 (apply to v4.2, v4.1, and v4.0)

[...] If the connection establishmentcreation fails this event shall be provided to
the Host that had issued the LE_Create_Connection command.
This event indicates to the Host which issued a LE_Create_Connection

command and received a Command Status event if the connection
establishmentcreation failed or was successful.
Section 7.7.65.10 (apply to v4.2 only)

[...] If the connection establishmentcreation fails, this event shall be provided to
the Host that had issued the LE_Create_Connection command.
If this event is unmasked and LE Connection Complete event is unmasked,

only the LE Enhanced Connection Complete event is sent when a new
connection has been completedcreated.
This event indicates to the Host that issued a LE_Create_Connection

command and received a Command Status event if the connection
establishmentcreation failed or was successful.
Section 7.8.9 (apply to v4.2 only)

If the Advertising_Type parameter is 0x00 (ADV_IND), 0x01
(ADV_DIRECT_IND, high duty cycle), or 0x04 (ADV_DIRECT_IND, low duty

cycle) and a connection is establishedcreated, an LE Connection Complete

event shall be generated.
11.42 E6553 – Confusion of packet and PDU
Core Section(s) affected: 7.7.65.7 LE Data Length Change Event

7.8.33 Negative Reply Command
LE Read Maximum Data

7.8.46 Length Command
EDITOR’S NOTE: Change instances of “Data Channel PDU” to “packet” and

“Data Channel PDUs” to “packets”
Section 7.7.65.7
The LE Data Length Change event notifies the Host of a change to either the
maximum Payload length or the maximum transmission time of Data Channel
PDUspackets in either direction. The values reported are the maximum that will
actually be used on the connection following the change
MaxTxOctets: Size: 2 Octets

0xXXXX The maximum number of payload octets in a Link Layer Data Channel
PDUpacket that the local Controller will send on this connection (con-
nEffectiveMaxTxOctets defined in [Vol 6] Part B, Section 4.5.10).
Range 0x001B-0x00FB (0x0000 - 0x001A and 0x00FC - 0xFFFF
Reserved for future use)
MaxTxTime: Size: 2 Octets

0xXXXX The maximum time that the local Controller will take to send a Link
Layer Data Channel PDUpacket on this connection (connEffectiveMax-
TxTime defined in [Vol 6] Part B, Section 4.5.10).
Range 0x0148-0x0848 (0x0000 - 0x0127 and 0x0849 - 0xFFFF

MaxRxOctets: Size: 2 Octets

0xXXXX The maximum number of payload octets in a Link Layer Data Channel
PDUpacket that the local controller expects to receive on this connec-
tion (connEffectiveMaxRxOctets defined in [Vol 6] Part B, Section
4.5.10).
MaxRxTime: Size: 2 Octets
0xXXXX The maximum time that the local Controller expects to take to receive a
Link Layer Data Channel PDUpacket on this connection (connEffec-
tiveMaxRxTime defined in [Vol 6] Part B, Section 4.5.10).
Section 7.8.33
TxOctets: Size: 2 Octets
0xXXXX Preferred maximum number of payload octets that the local Control-
ler should include in a single Link Layer Data Packet PDUpacket on
this connection.
TxTime: Size: 2 Octets
0xXXXX Preferred maximum number of microseconds that the local Controller

should use to transmit a single Link Layer Data Packet PDUpacket
on this connection
Section 7.8.46
supportedMaxTxOctets: Size: 2 Octet
0xXXXX Maximum number of payload octets that the local Controller supports
for transmission of a single Link Layer packet on a data connection.

supportedMaxTxTime: Size: 2 Octet

0xXXXX Maximum time, in microseconds, that the local Controller supports for
transmission of a single Link Layer packet on a data connection.
supportedMaxRxOctets: Size: 2 Octet

0xXXXX Maximum number of payload octets that the local Controller supports
for reception of a single Link Layer packet on a data connection.
supportedMaxRxTime: Size: 2 Octet

0xXXXX Maximum time, in microseconds, that the local Controller supports for
reception of a single Link Layer packet on a data connection.
11.43 E6247 – Unclear when to use LE Direct Advertising

Report Event or LE Advertising Report Event
Core Section(s) affected: 7.7.65.11 LE Direct Advertising Report Event
EDITOR’S NOTE: Replace “in” with “of.” Add “which the Controller is unable to
resolve.”
See Section 11.44

11.44 E6709 – Editorial
EDITOR’S NOTE: Correct spelling error and change “is” to “specify.”
The LE Direct Advertising Report event indicates that directed advertisements

have been received where the advertiser is using a resolvable private address
for the InitA field inof the ADV_DIRECT_IND PDU which the Controller is
unable to resolve and the Scanning_Filter_Policy is equal to 0x02 or 0x03, see
Section 7.8.10. Direct_Address_Type and Direct_Address isspecify the
address the directed advertisements are being directed to. Address_Type and
Address isspecify the address of the advertiser sending the directed
advertisements. [...]
11.45 E6629 – LE Direct Advertising Report Event - Order of

parameters
EDITOR’S NOTE: Move parameter tables to match order in the top event table
Event_Type[i]: Size: 1 Octet

0x01 Connectable directed advertising (ADV_DIRECT_IND)
0x00 and 0x02 – Reserved for future use

0xFF
Address_Type[i]: Size: 1 Octet

0x00 Public Device Address (default)
0x01 Random Device Address
0x02 Public Identity Address (Corresponds to Resolved Private Address )

0x03 Random (static) Identity Address (Corresponds to Resolved Private

Address)
0x04 – 0xFF Reserved for future use
Address[i]: Size: 6 Octets

0xXXXXXXXXXX Public Device Address, Random Device Address, Public Identity

XX Address or Random (static) Identity Address of the advertising device.
Direct_Address_Type[i]: Size: 1 Octet

0x01 Random Device Address (default)
0x00 and 0x02 – Reserved for future use

0xFF
Direct_Address[i]: Size: 6 Octets

0xXXXXXXXXXX Random Device Address

XX
Address_Type[i]: Size: 1 Octet

0x00 Public Device Address (default)
0x02 Public Identity Address (Corresponds to Resolved Private Address )
0x03 Random (static) Identity Address (Corresponds to Resolved Private

Address)
Address[i]: Size: 6 Octets

0xXXXXXXXXXX Public Device Address, Random Device Address, Public Identity

XX Address or Random (static) Identity Address of the advertising device.

11.46 E6886 – No explanation of triggered clock capture
Core Section(s) affected: 7.7.66 Triggered Clock Capture Event
EDITOR’S NOTE: Add note after Description
The Slot_Offset parameter indicates the number of microseconds (from 0 to

1249) from the instant at which the selected clock took the value Clock until the
triggering event.
Note: What constitutes a triggering event is defined by the Controller

implementation. For example, it could be an interrupt signal received by the
Controller hardware.
11.47 E6182 – Invalid behavior with resolving address list not

clear in Core or Test Spec
Core Section(s) affected: 7.8.10 LE Set Scan Parameters Command
EDITOR’S NOTE: Edit the Description column in the table below as follows:
0x00: Remove bullet and merge text into a single sentence.
0x01: Remove bullets and merge text into a single paragraph.
0x02 and 0x03: Changes as shown in the table.

Scanning_Filter_Policy: Size: 1 Octet

0x00 Accept all advertising packets except directed advertising packets not
addressed to this device (default).
0x01 Accept only advertising packets from devices where the advertiser’s
address is in the White List. Directed advertising packets which are not
addressed forto this device shall be ignored.
0x02 Accept all advertising packets except directed advertising packets

where the initiator's identity address does not address this device.
Note: Directed advertising packets where the initiator's address is a
resolvable private address that cannot be resolved are also accepted.
• undirected advertising packets, and
0x03 Accept all advertising packets except:

• advertising packets where the advertiser's identity address is not in
the White List; and
• directed advertising packets where the initiator's identity address
does not address this device
Note: Directed advertising packets where the initiator's address is a
resolvable private address that cannot be resolved are also accepted.
• advertising packets from devices where the advertiser’s address is
in the White list, and
0x04 – 0xFF Reserved for future use.
[End of changes for Erratum E6182]
11.48 E6914 – LE Set Scan Enable Command -

Filter_Duplicates
Core Section(s) affected: 7.8.11 LE Set Scan Enable Command
EDITOR’S NOTE: Add text as shown below. The text in versions 4.1 and 4.0
are slightly different.
The Filter_Duplicates parameter controls whether the Link Layer should filter
out duplicate advertising reports (Filtering_Enabled) to the Host, or if the Link

Layer should generate advertising reports for each packet received

(Filtering_Disabled). See [Vol 6] Part B, Section 4.4.3.5.
Version 4.1
The Filter_Duplicates parameter controls whether the Link Layer shall filter
duplicate advertising reports to the Host, or if the Link Layer should generate
advertising reports for each packet received. See [Vol 6] Part B, Section
4.4.3.5.
Version 4.0
The Filter_Duplicates parameter controls whether the Link Layer shall filter
duplicate advertising reports to the Host, or if it shall generate advertising
reports for each packet received. See [Vol 6] Part B, Section 4.4.3.5.
11.49 E7372 – Changes to Peer_Address_Type values 0x02

and 0x03
Core Section(s) affected: 7.8.12 LE Create Connection Command
EDITOR’S NOTE: Add text as shown below:
Description:
The Initiator_Filter_Policy is used to determine whether the White List is used.

If the White List is not used, the Peer_Address_Type and the Peer_Address
parameters specify the address type and address of the advertising device to
connect to.
Peer_Address_Type parameter indicates the type of address used in the

connectable advertisement sent by the peer. The Host shall not set
Peer_Address_Type to either 0x02 or 0x03 if both the Host and the Controller
support the LE Set Privacy Mode command. If a Controller that supports the LE
Set Privacy Mode command receives the LE Create Connection command with
Peer_Address_Type set to either 0x02 or 0x03, it may use either device
privacy mode or network privacy mode for that peer device.
Peer_Address parameter indicates the Peer’s Public Device Address, Random

(static) Device Address, Non-Resolvable Private Address or Resolvable
Private Address depending on the Peer_Address_Type parameter.

Command Parameters:
Peer_Address_Type: Size: 1 Octet

0x00 Public Device Address
0x02 Public Identity Address (Corresponds to peer’s Resolvable Private

Address). This value shall only be used by the Host if either the Host
or the Controller does not support the LE Set Privacy Mode com-
mand.
0x03 Random (static) Identity Address (Corresponds to peer’s Resolvable

Private Address). This value shall only be used by a Host if either the
Host or the Controller does not support the LE Set Privacy Mode
command.
11.50 E6939 – Connection interval is not defined
Core Section(s) affected: 7.8.12 LE Create Connection Command
7.8.18 LE Connection Update Command
EDITOR’S NOTE: Change “connection event interval” to “connection interval”

as shown below
Section 7.8.12
Conn_Interval_Min: Size: 2 Octets

N = 0xXXXX Minimum value for the connection event interval. This shall be less
than or equal to Conn_Interval_Max.
Range: 0x0006 to 0x0C80
Time Range: 7.5 msecms to 4 secondss.

Conn_Interval_Max: Size: 2 Octets

N = 0xXXXX Maximum value for the connection event interval. This shall be
greater than or equal to Conn_Interval_Min.]
Section 7.8.18
Conn_Interval_Min: Size: 2 Octets

N = 0xXXXX Minimum value for the connection event interval. This shall be
less than or equal to Conn_Interval_Max.
Conn_Interval_Max: Size: 2 Octets

N = 0xXXXX Maximum value for the connection event interval. This shall
be greater than or equal to Conn_Interval_Min.
11.51 E6559 – Is this command a promise or a hint?
Core Section(s) affected: 7.8.14 LE Read White List Size Command
7.8.16 LE Add Device To White List Command
LE Add Device to Resolving

7.8.38 List Command
LE Read Resolving List Size

7.8.41 Command

EDITOR’S NOTE: Section 7.8.14: Inserted note to end of description. Section

7.8.16: Inserted text to end of description. Section 7.8.38: Revise text in last
paragraph of description. Section 7.8.41: Inserted note to end of description.
All changes below apply to v4.2. Changes in Sections 7.8.14 and 7.8.16
also apply to v4.1 and v4.0.
Section 7.8.14
The LE_Read_White_List_Size command is used to read the total number of

White List entries that can be stored in the Controller. Note: the number of
entries that can be stored is not fixed and the Controller can change it at any
time (e.g. because the memory used to store the list can also be used for other
purposes).
Section 7.8.16
[...] When a controller cannot add a device to the list because there is no space
available, it should respond with error code 0x07 (Memory Capacity
Exceeded).
Section 7.8.38
[...] When a Controller cannot add a device to the resolving list because the list
is fullthere is no space available, it shall respond with error code 0x07 (Memory
Capacity Exceeded).
Section 7.8.41
The LE_Read_Resolving_List_Size command is used to read the total number

of address translation entries in the resolving list that can be stored in the
Controller. Note: the number of entries that can be stored is not fixed and the
Controller can change it at any time (e.g. because the memory used to store
the list can also be used for other purposes).
11.52 E7017 – No mention of the Data Length Change Event
Core Section(s) affected: 7.8.33 LE Set Data Length Command
EDITOR’S NOTE: Add text as shown below

If the command causes the maximum transmission packet size or maximum

packet transmission time to change, an LE Data Length Change Event shall be
generated.
11.53 E6689 – Reduce confusion
LE Read Suggested Default Data Length

LE Write Suggested Default Data Length

7.8.35
Command
EDITOR’S NOTE: Revise text for the Description, SuggestedMax TXOctets,

and SuggestedMax TxTime
Section 7.8.34
The LE_Read_Suggested_Default_Data_Length command allows the Host to
read the Host's suggested values (SuggestedMaxTxOctets and
SuggestedMaxTxTime) for the Controller's maximum transmitted number of
payload octets and maximum packet transmission time to be used for new
connections (connInitialMaxTxOctets and connInitialMaxTxTime - see ([Vol 6]
Part B, Section 4.5.10).
SuggestedMaxTxOctets: Size: 2 Octets

0xXXXX The Host's suggested value for the Controller's maximum transmitted
number of payload octets to be used for new connections- connInitial-
MaxTxOctets.
Default: 0x001B
SuggestedMaxTxTime: Size: 2 Octets

0xXXXX The Host's suggested value for the Controller's maximum packet
transmission time to be used for new connections - connInitialMaxTx-
Time.
Default: 0x0148

Section 7.8.35
The LE_Write_Suggested_Default_Data_Length command allows the Host to
specify its suggested values for the Controller's maximum transmission
number of payload octets and maximum packet transmission time to be used
for new connections. The Controller may use smaller or larger values for
connInitialMaxTxOctets and connInitialMaxTxTime based on local
information.(connInitialMaxTxOctets and connInitialMaxTxTime - see [Vol 6]
Part B, Section 4.5.10). The Controller may use smaller or larger values based
on local information.
SuggestedMaxTxOctets: Size: 2 Octets

0xXXXX The Host's suggested value for the Controller's maximum transmitted
number of payload octets to be used for new connections - connIni-
tialMaxTxOctets.
SuggestedMaxTxTime: Size: 2 Octets

0xXXXX The Host's suggested value for the Controller's maximum packet
transmission time to be used for new connections -
connInitialMaxTxTime.
11.54 E6568 – Typo
Core Section(s) affected: 7.8.8 LE Set Scan Response Data Command
EDITOR’S NOTE: Fix typo
When the LE_Set_Scan_Response_Data command has completed, a

Command Complete event shall be generated.

11.55 E6399 – LE Enhanced Connection Complete event
Core Section(s) affected: 7.8.9 LE Set Advertise Enable Command
EDITOR’S NOTE: Revise text in Note at end of section
Note: There is a possible race condition if the Advertising_Enable parameter is

set to 0x00 (Disable) and the Advertising_Type parameter is 0x00, 0x01, or
0x04. The advertisements might not be stopped before a connection is
created, and therefore both the Command Complete event and either an LE
Connection Complete event or an LE Enhanced Connection Complete event
could be generated. This can also occur when high duty cycle directed
advertising is timed out and this command disables advertising.
11.56 E7045 – Missing OGFs
Core Section(s) affected: A.2 Write Page Scan Mode Command
A.3 Read Page Scan Period Mode Command
A.4 Write Page Scan Period Mode Command
A.8 Read Encryption Mode Command
A.9 Write Encryption Mode Command
EDITOR’S NOTE: Revise text in Appendix A as shown below
Section A.2 – Delete first line:
OGF: 0x03 (Controller and baseband commands)
Return
Command OGF OCF Command Parameters Parameters
HCI_Write_Page_Scan_Mode 0x03 0x003E Page_Scan_Mode Status

Section A.3, A.4, A.8 and A.9 – Add OGF column (0x03) as in this example:
Command
Command OGF OCF Parameters Return Parameters
HCI_Read_Page_Scan_ 0x03 0x003B Status,

Period_Mode Page_Scan_Period_Mode
11.57 E7077 – Trivial editorial
Core Section(s) affected: 7.8.5 LE Set Advertising Parameters Command
EDITOR’S NOTE: In the block for the Advertising_Filter_Policy parameter, row

0x02 has two full stops at the end of the description. Remove one.

12 [Vol 2] Part F: MESSAGE SEQUENCE CHARTS
12.1 E5089 – Missing mutual authentication in master link

key
E5089 4.2 4.1 4.0 3.0 2.1 Vol 2, Part F Message Sequence Charts
Core Section(s) affected: 4.7 Master Link Key
EDITOR’S NOTE: Add authentication to MSC

LM-A LM-B
Host A Host B
Master Slave
Step 1: Host requests switch from Semi-permanent Link Key to Master Link Key
HCI_Master_Link_Key
(master_link_key)
HCI_Command_Status
LMP_temp_rand
LMP_temp_key
LMP_au_rand
LMP_sres
LMP_au_rand
LMP_sres
If (encryption is enabled)
then restart encryption
LMP_encryption_mode_req
(off)
LMP_accepted
LMP_stop_encryption_req
LMP_accepted
LMP_encryption_mode_req
(on)
LMP_accepted
LMP_encryption_key_size_req
LMP_accepted
LMP_start_encryption_req
LMP_accepted
HCI_Master_Link_Key_Complete HCI_Master_Link_Key_Complete
[Vol 2] Part F: Message Sequence Charts 06 December 2016

12.2 E6218 – MLK MSC Shows Stop/Start rather than Pause/

Resume
Core Section(s) affected: 4.7 Master Link Key
EDITOR’S NOTE: Add text to first paragraph.
4.7 Master Link Key
Step 1: The host changes to a Master Link Key from a Semi-permanent Link
Key using the HCI_Master_Link_Key command when at least one device does
not support Encryption Pause Resume. (See Figure 4.34.)
12.3 E6428 – Only one host is involved, plus editorial issues
Core Section(s) affected: 8.1 Local Loopback Mode
EDITOR’S NOTE: Specify the host in Figures 8.1, 8.2, 8.3, and 8.4
Host A LM-A >> BB-A LM-B >> BB-B Host B
Step 1: Host A enters Local Loopback Mode
HCI_Write_Loopback_Mode
(local)
HCI_Connection_Complete
(ACL)
(SCO or eSCO)
(SCO or eSCO)
(SCO or eSCO)

Figure 8.1: Entering local loopback mode
Step 2a: Host A sends data to Controller while in Local Loopback Mode
ACL Data Packet
ACL Data Packet
ACL Data Packet
ACL Data Packet
Figure 8.2: Looping back data in local loopback mode
Step 2b: Host A sends HCI Commands to Controller while in Local Loopback Mode
HCI Command Packet
HCI_Loopback_Command
HCI Command Packet
HCI_Loopback_Command
Figure 8.3: Looping back commands in local loopback mode

Step 3: Host A Exits Local Loopback Mode
HCI_Write_Loopback_Mode
(no loopback)
HCI_Disconnection_Complete
(ACL)
(SCO or eSCO)
(SCO or eSCO)
(SCO or eSCO)
HCI_Command_Complete
Figure 8.4: Exiting local loopback mode

consistency
E6531 4.2 4.1 Vol 2, Part F Message Sequence Charts
Core Section(s) affected: 9 Connectionless Slave Broadcast Services

Section 9
Figure 9.1
Host A Controller A Controller B Host B
Step 1: Device B Pages Device A Using Truncated Paging
HCI_Write_Scan_Enable
HCI_Truncated_Page
HCI_Command_Status
Page
Page
Page Response
HCI_Truncated_Page_Complete
Ppageresp_TO
HCI_Slave_Page_Response_Timeout

Figure 9.3
Host A Controller A Controller B Host B
Step 3: Device A Starts the Synchronization Train
HCI_Write_Synchronization_Train_Parameters
HCI_Start_Synchronization_Train
HCI_Command_Status
Synchronization Train Packet
HCI_Receive_Synchronization_Train
HCI_Command_Status
HCI_Synchronization_Train_Received
synchronization_train_TO
HCI_Synchronization_Train_Complete

13 [Vol 2] Part H: SECURITY SPECIFICATION
E6480 4.2 4.1 4.0 3.0 2.1, Vol 2, Part H Security Specification
CSA4

(GAP)
Core Section(s) affected: 3.1 Key Types
[...] For the longer lengths, the devices exchanging PIN codes may not use
mechanical (i.e. human) interaction, but rather may use software at the
application layermay use software at the application layer rather than
mechanical (i.e. human) interaction. For example, this can be a Diffie-Hellman
key agreement, where the exchanged key is passed on to the Kinit generation
process in both devices, just as in the case of a shorter PIN code.
13.2 E5792 – Indicate when pairing begins
E5792 4.2 4.1 4.0 3.0 2.1 Vol 2, Part H Security Specification
[Vol 2] Part H: Security Specification 06 December 2016

Core Section(s) affected: 7.2.2 Authentication Stage 1: Out of Band Protocol
EDITOR’S NOTE: Edit Figure 7.5 as shown below
Initiating Non-initiating
Device A Device B
Authentication Stage
Out -Of-Band
2a. Set ra=rand, rb=0 2b. Set rb=rand, ra=0
3b. Compute commitment 3b. Compute commitment

Ca=f1(Pkax,Pkax,ra,0) and send 4a. Cb=f1(PKbx,PKbx,rb,0) and send 4b.
4a. A, ra, Ca OOB

Communication
OR AND
A = Bluetooth address of
4b. B, rb, Cb B = Bluetooth address of
LMP Pairing begins
5a. If 4b received reset rb to the 5b. If 4a received reset ra to the

received value, and if received value, and if
Cbf1(PKbx,PKbx,rb,0) abort. &DI3.D[3.D[UDDERUW
If 4b received and Device B’s IO If 4a received and Device A’s IO
capability does not indicate OOB capability does not indicate OOB
authentication data present set set authentication data present set
ra=0. rb=0.
6a. Select random Na 6b. Select random Nb
7. Na
8. Nb
13.3 E5791 – R or r
E5791 4.2 4.1 4.0 3.0 2.1 Vol 2, Part H Security Specification
Core Section(s) affected: 7.7.1 The Simple Pairing Commitment Function f1

EDITOR’S NOTE: Update Table 7.2 and add a paragraph at the end of the
section
Numeric Comparison Out-Of-Band Passkey Entry
Ca = f1(PKax, PKbx, Na, 0) Ca = f1(PKax, PKax, Rra, 0) Cai = f1(PKax, PKbx, Nai, rai)
Cb = f1(PKbx, PKax, Nb, 0) Cb = f1(PKbx, PKbx, Rrb, 0) Cbi = f1(PKbx, PKax, Nbi, rbi)
Table 7.2: Inputs to f1 for the different protocols
where PKax denotes the x-coordinate of the public key PKa of A. Similarly,
PKbx denotes the x-coordinate of the public key PKb of B. Nai is the nonce
value of ith round. For each round Nai value is a new 128 bit number. Similarly,
rai is one bit value of the passkey expanded to 8 bits (either 0x80 or 0x81).
Na and Nb are nonces from Devices A and B. ra and rb are random values
generated by devices A and B.
13.4 E5882 – DHKey can be calculated using either P192 or

P256
E5882 4.2 4.1 Vol 2, Part H Security Specification
Core Section(s) affected: 7.7.4 The Simple Pairing Check Function f3
EDITOR’S NOTE: Revise text in paragraph after Table 7.3
DHKey denotes the shared secret Diffie-Hellman Key computed as P192(SKa,

PKb) or P256(SKa, PKb) by A and as P192(SKb, PKa) or P256(SKb, PKb) by
B. IOcapA denotes the IO capability data of A and IOcapB denotes the IO
capability data of B. In Passkey Entry, the data ra and rb are 6-digit passkey
values which are expressed as a 128-bit integer. For instance, if the 6-digit
value of ra is 131313
13.5 E6902 – BR/EDR SC not compliant to RFC 3610
Core Section(s) affected: 9 AES-CCM Encryption for BR/EDR

The Baseband provides security using Counter with Cipher Block Chaining-
Message Authentication Code (CCM) as defined in IETF RFC 3610 (http://
www.ietf.org/rfc/rfc3610.txt) with a modification to the B1 counter mode block
format that omits the length of the additional authenticated data. The
description of the algorithm can also be found in the NIST Special Publication
800-38C (http://csrc.nist.gov/publications/PubsSPs.html).
Core Section(s) affected: 9.2 Counter Mode Blocks
EDITOR’S NOTE: Revise text
For calculating the MIC, the payload is broken into two or more counter mode
blocks. The CCM specification refers to these blocks ast blocks B0 – Bn. [...]
13.7 E6907 – Meaning of payload
Core Section(s) affected: 9.2 Counter Mode Blocks
9.3 Encryption Blocks
EDITOR’S NOTE: Change “payload” to “payload body” as shown below
Section 9.2
For calculating the MIC, the payload is broken into two or more counter mode
blocks. The CCM specification refers to these blocks ast blocks B0 – Bn. B0
applies to the nonce, B1 applies to the associated data {that is packet header

and payload header} and additional B blocks are generated as needed for
authentication of the payload body.
Offset Size
(octets) Field (octets) Value Description
14 Length[MSO] 1 variable The most significant octet of the length of

the payload body.
15 Length[LSO] 1 variable The least significant octet of the length of

the payload body.
Section 9.3
The CCM algorithm uses the AxAi blocks to generate a keystream that is used
to encrypt the MIC and payload body. Block A0A0 is always used to encrypt
and decrypt the MIC, when present. Block A1A1 is always used to encrypt and
decrypt the first 16 octets of the Ppayload body. Subsequent blocks are always
used to encrypt and decrypt the rest of the Ppayload body as needed.

14 [Vol 3] Part A: L2CAP
14.1 E3548 – Clarification on - Recv REJ (F=0) in RECV State

Machine
E3548 4.2 4.1 4.0 3.0 Vol 3, Part A L2CAP
Core Section(s) affected: 8.6.5.2 States
8.6.5.6 Actions
EDITOR’S NOTE: Revise sections as shown below.
Section 8.6.5.2
WAIT_F—Local busy has been cleared or the Retransmission timer has
expired and an S-frame with P=1 has been sent. The local L2CAP entity is
waiting for a frame with F=1. New I-frames cannot be sent while in the WAIT_F
state [...]
Section 8.6.5.6 – This change is also valid for v2.1+CSA1

Send-Pending-I-frames (F=x)—If PbitOustanding equals FALSE then send all
pending I-frames that can be sent without exceeding [...]
14.2 E6567 – Wrong reference
E6567 4.2 4.1 4.0 Vol 3, Part A L2CAP
Connection Parameter Update Request

Core Section(s) affected: 4.20 (code 0X12)
EDITOR’S NOTE: Correct cross-reference in 3rd paragraph
[...]this notification will be in the form of an LE Connection Update Complete

event (see [Vol 2] Part E, Section 7.7.65.31). If the LE master Controller rejects
the updated connection parameters no indication from the LE slave Controller
will be sent to the LE slave Host.
[Vol 3] Part A: L2CAP 06 December 2016

E6939 4.2 4.1 4.0 Vol 3, Part A L2CAP
Connection Parameter Update Request

Core Section(s) affected: 4.20 (code 0X12)

as shown below
Section 4.20
The data fields are:

• Interval Min (2 octets)
Defines minimum value for the connection event interval in the following manner:
connIntervalMin = Interval Min * 1.25 ms. Interval Min range: 6 to 3200 frames
where 1 frame is 1.25 ms and equivalent to 2 BR/EDR slots. Values outside the
range are reserved. Interval Min shall be less than or equal to Interval Max.
• Interval Max (2 octets)
Defines maximum value for the connection event interval in the following manner:
connIntervalMax = Interval Max * 1.25 ms. Interval Max range: 6 to 3200 frames.
Values outside the range are reserved. Interval Max shall be equal to or greater
than the Interval Min.
14.4 E6702 – typo in first paragraph of L2CAP 4.24
E6702 4.2 4.1 Vol 3, Part A L2CAP
Core Section(s) affected: 4.24 LE Flow Control Credit (Code 0x16)
EDITOR’S NOTE: Correct typo in first paragraph
A device shall send a LE Flow Control Credit packet when it is capable of

receiveing additional LE-frames (for example after it has processed one or
more LE-frames).

14.5 E6417 – Usage of error handling for (0x0006 & 0x0007)

to be made explicit
E6417 4.2 4.1 4.0 3.0 2.1 Vol 3, Part A L2CAP
Core Section(s) affected: 4.3 Connection Response (code 0x03)
EDITOR’S NOTE: In the third bullet, change the text in the last sentence.
• Result (2 octets)
[...] sending the response. Table 4.6 defines values for this field. The
DCID and SCID fields shall be ignored when the result field indicates the
connection was refused.If the result field does not indicate the connection
was successful, the DCID and SCID fields may be invalid and shall be
ignored.

E6480 4.2 4.1 4.0 3.0 2.1, Vol 3, Part A L2CAP

CSA4

(GAP)
Core Section(s) affected: 5.3 Quality of Service (QOS) Option
5.6 Extended Flow Specification Option
6 State Machine
7.3.3 Segmentation and fragmentation
8.6.5.3 Variables and Timers
Appendix A Configuration MSCs
Section 5.3
[...]The Quality of Service guarantees are only provided for conformant traffic.
For non-conformant traffic there may not be insufficient resources such as
bandwidth and buffer space.[...]
Section 5.6
[...][Note that access latency is based on the time base of the Controller, which
may or may not be synchronous to the time base being used by the host or the
application.

Section 6
This section is informative. The state machine maydoes not necessarily
represent all possible scenarios.
Section 7.3.3
[...]Note that while SDUs and L2CAP PDUs are transported in peer-to-peer
fashion, the fragment size used by the Fragmentation and Recombination
routines is implementation specific and may not be the samedifferent in the
sender and the receiver.[...]
Section 8.6.5.3
PendingFrames—holds the number of pending I-frames. I-frames passed to
L2CAP from the upper layer may not be unable to be sent immediately
because the remote L2CAP entity's TxWindow is full, is in a busy condition or
the local L2CAP is in the incorrect state.[...]
Appendix A
The second problem is an attempt to configure a channel with an invalid CID.
For example device B may not have noan open connection on that CID
(0x01234567 in this example case).
14.7 E6898 – Changes to figure 7.2

E6898 4.2 4.1 4.0 3.0 Vol 3, Part A L2CAP
Core Section(s) affected: 7.2.1 Fragmentation of L2CAP PDUs
7.2.2 Recombination of L2CAP PDUs
7.3.3 Segmentation and fragmentation
EDITOR’S NOTE: Edit Figure 7.2 as shown below and move it from section
7.2.2 to the end of section 7.2.1. The bottom half of this figure is the same as in
Figure 7.4, so the same change is valid for Figure 7.4 in section 7.3.3.

Section 7.2.1
Service Data Unit
Encapsulate SDU
into L2CAP
L2CAP Length CID L2CAP Payload
B-frame
Connection Handle Flags=Start Length HCI data payload
Connection Handle Flags=Continue Length HCI data payload

Segment L2CAP packet
HCI into the payload of
many HCI data packets.
Host Connection Handle Flags=Continue Length HCI data payload

Software
Transfer packets to HCI 1 HCI 2 HCI n

HCI-USB USB driver Start Continue Continue
USB Send USB

packets over bus USB 1 USB 2 USB 3 USB 4 USB 5 USB p
Driver
USB Hardware bus
USB Receive USB

Driver packets. USB 1 USB 2 USB 3 USB 4 USB 5 USB p
Embedded
Software Re-assemble &
HCI-USB buffer packets HCI 1 HCI 2 HCI n
Link M anager Assemble 1,3 & 5 Air 1 Air 2 Air 3 Air q

slot packet types as Start Continue Continue Continue
Link Controller appropriate
Radio modulation and transmission
Section 7.3.3
USB Hardware bus
USB Receive USB

Driver packets. USB 1 USB 2 USB 3 USB 4 USB 5 USB p
Embedded
Software Re-assemble &
HCI-USB buffer packets HCI 1 HCI 2 HCI n
Link M anager Assemble 1,3 & 5 Air 1 Air 2 Air 3 Air q

slot packet types as Start Continue Continue Continue
Link Controller appropriate
Radio modulation and transmission

15 [Vol 3] Part B: SERVICE DISCOVERY PROTOCOL
E6421 4.2 4.1 4.0 3.0 2.1, Vol 3, Part B Service Discovery Protocol
CSA4

(GAP)
Core Section(s) affected: 2.4.1 A Printer Service Class Example
Note that this example is only illustrative. This mayis not benecessarily a
practical printer class hierarchy.
[Vol 3] Part B: Service Discovery Protocol 06 December 2016

16 [Vol 3] Part C: GENERIC ACCESS PROFILE (GAP)
16.1 E6575 – Misuse of conventions
E6575 4.2 4.1 4.0 Vol 3, Part C Generic Access Profile (GAP)
Vol 3, Part F Attribute Protocol (ATT) Section 18.1
Vol 3, Part G Generic Attribute Profile (GATT) Section 19.1
Core Section(s) affected: 1.2.4 Notation for UUIDs [new]
EDITOR’S NOTE: Add a new subsection as shown below
1.2.4 Notation for UUIDs

The use of « » (e.g. «Device Name») indicates a Bluetooth SIG-defined UUID.
16.2 E7033 – LE physical link is ambiguous
Core Section(s) affected: 2.2.2.3 Peripheral Role
2.2.2.4 Central Role
Section 2.2.2.3
Any device that accepts the establishment of an LE active physical link using
any of the connection establishment procedures as defined in Section 9 is
referred to as being in the Peripheral role. A device operating in the Peripheral
role will be in the Slave role in the Link Layer Connection State as described in
[Vol 6] Part B, Section 4.5. A device operating in the Peripheral role is referred
to as a Peripheral. A Peripheral shall have both a transmitter and a receiver.
Section 2.2.2.4
A device that supports the Central role initiates the establishment of an LE

active physical connectionlink. A device operating in the Central role will be in
the Master role in the Link Layer Connection State as described in [Vol 6] Part
[Vol 3] Part C: Generic Access Profile (GAP) 06 December 2016

B, Section 4.5. A device operating in the Central role is referred to as a Central.

A Central shall have both a transmitter and a receiver.
16.3 E6510 – Incorrect description of Appearance

characteristic
E6510 4.2 4.1 Vol 3, Part C Generic Access Profile (GAP)
Core Section(s) affected: 3.2.5.1 Definition
3.2.5.2 Usage at user interface level
3.2.5.3 Representation
Section 3.2.5.1
The Appearance characteristic contains a UUID 16-bit number that can be

mapped to an icon or string that describes the physical representation of the
device during the device discovery procedure (See Section 12.2). It is a
characteristic of the GAP service located on the device’s GATT server. See
Section 12.2.
Section 3.2.5.2
The Appearance characteristic valueUUID should be mapped to an icon or

string or something similar that conveys to the user a visual description of the
device. This allows the user to determine which device is being discovered
purely by visual appearance. If a string is displayed, this string should be
translated into the language selected by the user for the device.
Section 3.2.5.3
The Appearance characteristic value shall be set to one of the is a UUID16-bit

numbers assigned by the Bluetooth SIG and defined in [Core Specification
Supplement], Part A, Section 1.12. The UI-level representation of the
Appearance characteristic value is implementation specific.

16.4 E4777 – Negative replies not mentioned
E4777 4.2 4.1 4.0 3.0 2.1 Vol 3, Part C Generic Access Profile (GAP)
Core Section(s) affected: 4.3.1.1 Definition
4.3.2.1 Definition
EDITOR’S NOTE: Remove sentences as shown below
Section 4.3.1.1
A device in non-bondable mode shall respond to a received LMP_in_rand with

LMP_not_accepted with the reason pairing not allowed. An HCI-compliant host
stack shall respond to an HCI_PIN_Code_Request event with the
HCI_PIN_Code_Request_Negative_Reply command.
When both devices support Secure Simple Pairing and the local device isare in
non-bondable mode, the local host shall respond to an IO capability request
withwhere the Authentication_Requirements parameter requestings dedicated
bonding or general bonding with a negative response. An HCI-compliant host
stack shall respond to an HCI_IO_Capabilities_Request event with an
HCI_IO_Capabilities_Request_Negative_Reply command.
Section 4.3.2.1
When a Bluetooth device is in bondable mode, and Secure Simple Pairing is

not supported by either the local or remote device, the local device shall
respond to a received LMP_in_rand with LMP_accepted (or with LMP_in_rand
if it has a fixed PIN). An HCI-compliant host stack shall respond to an
HCI_PIN_Code_Request event with the HCI_PIN_Code_Request_Reply
command.
When both devices support Secure Simple Pairing, the local host shall respond
to a user confirmation request with a positive response. An HCI-compliant host
stack shall respond to an HCI_User_Confirmation_Request event with an
HCI_User_Confirmation_Request_Reply command or an
HCI_User_Passkey_Request event with an
HCI_User_Passkey_Request_Reply command.

16.5 E5708 – Authenticated Pairing is also a requirement for

Secure Connections Only Mode
Security Mode 4 (service level enforced

Core Section(s) affected: 5.2.2 security)
EDITOR’S NOTE: Revise text in 8th paragraph
[...]available on the BR/EDR physical transport require Security Mode 4, Level 4.

The device shall reject both new outgoing and incoming service level
connections when the physical transport does not support Secure Connections
and theservice requires Security Mode 4, Level 4 and either the physical
transport does not support Secure Connections or unauthenticated pairing is
being requested.
A device operating with a physical transport operating [...]
16.6 E6502 – Wrong table reference
Core Section(s) affected: 5.2.2.3 Simple Pairing after Authentication Failure
EDITOR’S NOTE: Update cross-reference
[...] When the link key is stored, subsequent connections to the same device
will use authentication but this may fail if the remote device has deleted the link
key. Table 5.21 defines what shall be done depending on the type of the link
key and whether bonding was performed or not.

16.7 E4348 – Table item with NoInputNoOutput
IO and OOB Capability Mapping to Authenti-

Core Section(s) affected: 5.2.2.6 cation Stage 1 Method
EDITOR’S NOTE: Add text to Table 5.7 (Table 5.6 in previous versions):

Device A (Initiator)
Display Only DisplayYesNo KeyboardOnly NoInputNoOutput
Numeric Numeric Passkey Entry: Numeric
Comparison Comparison Responder Comparison
with auto- with auto- Display, with automatic
matic confir- matic confir- Initiator Input. confirmation on
DisplayOnly mation on mation on both devices.
both devices. device B only.
Un- Un- Authenticated Unauthenticated
authenticated authenticated
Numeric Numeric Passkey Entry: Numeric
Comparison Comparison: Responder Comparison
with auto- Both Display, Display, with automatic
matic confir- Both Confirm. Initiator Input. confirmation on
mation on device A only and
device A only. Yes/No confirma-
DisplayYes tion whether to
No pair on device B.
Device B does not
show the confir-
Device B (Responder)
mation value.
Un- Authenticated Authenticated Unauthenticated
authenticated
Passkey Passkey Passkey Entry: Numeric
Entry: Initia- Entry: Initiator Initiator and Comparison
Keyboard tor Display, Display, Responder with automatic
Only Responder Responder Input. confirmation on
Input. Input. both devices.
Authenticated Authenticated Authenticated Unauthenticated
Numeric Numeric Numeric Numeric
Comparison Comparison Comparison Comparison
with auto- with auto- with automatic with automatic
matic confir- matic confir- confirmation on confirmation on
mation on mation on both devices. both devices.
both devices. device B only
and Yes/No
NoInputNo confirmation
Output on whether to
pair on device
A. Device A
does not show
the confirma-
tion value.
Un- Un- Un- Unauthenticated
authenticated authenticated authenticated
Table 5.7: IO Capability Mapping to Authentication Stage 1

16.8 E6732 – Why is it not permitted to send connectable

undirected advertising events in the non-
discoverable mode?
Core Section(s) affected: 9.2.2.2 Conditions
EDITOR’S NOTE: Revise first two paragraphs
Version 4.2 and 4.1

A device in the non-discoverable mode may send advertising events. AIf the
device in the non-discoverable mode that sends advertising events, it shall not
set the ‘LE General Discoverable Mode’ flag or ‘LE Limited Discoverable Mode’
flag in the Flags AD type (see [Core Specification Supplement], Part A, Section
1.3). A Peripheral device in the non-connectable mode may send non-
connectable undirected advertising events or scannable undirected advertising
events or may not send advertising packets.
If the Peripheral device in the non-discoverable mode sends non-connectable

advertising events or scannable undirected advertising events, then it is
recommended that the Host configures the Controller as follows:
Version 4.0
A device in the non-discoverable mode may send advertising events. AIf the
device in the non-discoverable mode that sends advertising events, it shall not
set the ‘LE General Discoverable Mode’ flag or ‘LE Limited Discoverable Mode’
flag in the Flags AD type. A Peripheral device in the non-connectable mode
may send non-connectable undirected advertising events or scannable
undirected advertising events or may not send advertising packets.
16.9 E5778 – Central role not allowed for Limited/General

Discoverable Modes
9.2.4.2 Conditions
9.2.5.2 Conditions

9.2.6.2 Conditions
9.3.1 Requirements
9.3.3.2 Conditions
9.3.4.2 Conditions
9.3.5.2 Conditions
9.3.6.2 Conditions
9.3.7.2 Conditions
9.3.8.2 Conditions
9.3.9.2 Conditions
EDITOR’S NOTE: Revise text as shown below:
Section 9.2.3.2
While a device is in the Peripheral role the device may support the limited
discoverable mode. While a device is only in the Broadcaster, Observer or
Central role the device shall not support the limited discoverable mode.
Section 9.3.1
Table 9.3: Connection modes and procedures requirements1

1. Note: Requirements listed in the table above refer to the specific role a device is
operating in. Devices supporting multiple roles are required to support the specified
modes and procedures for a given role while operating in that role.
16.10 E5433 – In Table 9.3, C1 condition should be removed
E5433 4.2 Vol 3, Part C Generic Access Profile (GAP)
Core Section(s) affected: 9.3.1 Requirements

EDITOR’S NOTE: Revise text in Table 9.3 as shown below:
Connection Modes and

Procedures Ref. Peripheral Central Broadcaster Observer
General connection estab- 9.3.6 E C1O E E

lishment procedure
Selective connection estab- 9.3.7 E O E E

lishment procedure
Direct connection establish- 9.3.8 E M E E

ment procedure
Connection parameter 9.3.9 O M E E

update procedure
Terminate connection proce- 9.3.10 M M E E

dure
C1: Mandatory if privacy feature is supported, else optional
EDITOR’S NOTE: Revise text in second box of figure

General connection
establishment procedure
Host sets scanner filter policy to one

of the 'accept all'
advertisementadvertising packets options
Host sets scan parameters and starts

scanning
Host compares received

advertisers address with the list of
devices it wants to connect to
Connect to
peripheral
device?
Yes
Stop scanning
Initiate connection using the

directed connection establishment
procedure
No
Connection successful
End of procedure
Figure 9.4: Flow chart for a device performing the general connection establishment procedure

16.12 E6214 – Statement mismatch between procedure

descriptiion and figure
EDITOR’S NOTE: Change text in second box as shown in Figure 9.5

Selective connection
establishment procedure
Host writes list of device addressesidentities

to the controller whitelist to selectively
connect to
Host sets scanner filter policy to:

the 'accept only' option
Host sets scan parameters
Start scanning
Host compares received

advertiser’s address with the list of
devices it wants to connect to
Connect to
peripheral no
device?
yes
Stop scanning
Initiate connection using the directed

connection establishment procedure
with the connection configuration
parameters for the peripheral
End of procedure

16.13 E6764 – Wrong reference to another chapter (probably

a typo)
EDITOR’S NOTE: Correct first hyperlink in fourth paragraph.
If either the Central or the Peripheral does not support the Connection
Parameters Request Link Layer Control procedure, then the Peripheral
initiating the connection parameter update procedure shall use the L2CAP
Connection Parameter Update Request command defined in [Vol 3] Part A,
Section 4.20 with the required connection parameters.[...]
Version 4.0
Change is in third paragraph.
16.14 E5407 – 4.1: Conflict on IRK requirements: mandatory

or not?
10.8 Random Device Address
EDITOR’S NOTE: Revise text in following two sections as shown:
Section 9.4.4.2 (v4.2, v4.1, v4.0)

If a device supports the generation of resolvable private addresses as defined
in Section 10.8.2.2, the Host should send its IRK to the peer device and
request the IRK of the peer device during the pairing procedure and generates
a resolvable private address for its local address, it shall send Identity
Information with SMP, including a valid IRK. If a device does not generate a
resolvable private address for its own address and the Host sends Identity
Information with SMP, the Host shall send an all-zero IRK. The Host can abort
the pairing procedure if the authentication requirements are not sufficient to
distribute the IRK.
Section 10.8 (v4.2, v4.1)

A bonded device shall process a resolvable private address as defined in

Section 10.8.2.3 or by establishing a connection and then performing the

authentication procedure as defined in Section 10.3. A device that uses
resolvable generates a resolvable private address privatefor its local address
shall always request to distribute its IRK value as defined in [Vol 3] Part H,
Section 3.6.4 if both sides are bondable, unless keys have been pre-
distributed. If the request to distribute the IRK fails then the peer device may
authenticate re-connections using the authentication procedure as defined in
Section 10.3 or terminate the current connection.
16.15 E6439 – Need to explicitly mention 128 bit encryption

key size requirement for LE SC Only case
Core Section(s) affected: 10.2.1 LE Security Mode 1
4. Authenticated LE Secure Connections pairing with encryption using a 128-

bit strength encryption key.
16.16 E6897 – LE Secure Connections authenticated vs

unauthenticated pairing
Core Section(s) affected: 10.3.1 Responding to a Service Request
If LE Secure Connections authenticated pairing is required but LE legacy

pairing has occurred and the link is currently encrypted, the service request
shall be rejected with the error code “Insufficient Authentication”.

16.17 E4919 – Unauthenticated/Authenticated Encryption

capabilities can also be determined by STK
Core Section(s) affected: 10.3.1 Responding to a Service Request
When a local device receives a service request from a remote device, it shall
respond with an error code if the service request is denied. The error code is
dependent on whether the current connection is encrypted or not and on the
type of pairing that was performed to create the LTK or STK to be used.
If neither an LTK nor an STK is not available, the service request shall be
rejected with the error code “Insufficient Authentication”.
If an LTK or an STK is available and encryption is required (LE security mode

1) but encryption is not enabled, the service request shall be rejected with the
error code “Insufficient Encryption”. If the encryption is enabled with insufficient
key size then the service request shall be rejected with the error code
“Insufficient Encryption Key Size.”
Local Device Pairing Status
Link Local Device’s Unauthenticated Authenticated Authenticated

Encryp- Access LTK or LTK or LTK with
tion Requirement No LTK Unauthenticate Authenticate Secure
State for Service No STK d STK d STK Connections
None N/A Request Request Request

Encrypted
(Not possible succeeds succeeds succeeds

to be
encrypted
without LTK)
16.18 E5110 – Data signing: generation of CSRK
Core Section(s) affected: 10.4.1 Connection Data Signing Procedure

A device shall generate a new Connection Signature Resolving Key CSRK for
each set of peer device(s) to which it sends signed data in a connections.
CSRK is defined in [Vol 3] Part H, Section 2.4.2.2.
E6421 4.2 4.1 4.0 3.0 2.1, Vol 3, Part C Generic Access Profile
CSA4 (GAP)
Core Section(s) affected: 10.4.2 Authenticate Signed Data Procedure
Privacy Feature in a Peripheral with Host-

10.7.1.2 based privacy
Privacy Feature in a Central with Host-

10.7.2.2 based privacy
10.7.3 Privacy Feature in a Broadcaster
10.7.4 Privacy Feature in an Observer
Section 10.4.2
Note that since the server does not respond to a Signed Write Command, the
higher layer application may or may not be notified of the ignored request.[...]

[...]Note that since the server does not respond to a Signed Write Command,
the higher layer application may or may not be notified of the ignored
request.[...]
Section 10.7.1.2
The Host shall generate a new resolvable private address or non-resolvable
private address when the timer TGAP(private_addr_int) expires.
Note: TGAP(private_addr_int) timer may or may not be run if a Peripheral is not

advertising.
Section 10.7.2.2
Note: TGAP(private_addr_int) timer may or may not be run if a Central is not
scanning or connected.
Section 10.7.3
Note: TGAP(private_addr_int) timer may or may not be run if a Broadcaster is
not advertising.
Section 10.7.4
Note: TGAP(private_addr_int) timer may or may not be run if an Observer is not
scanning.
16.20 E6599 – Host based privacy and controller based

privacy mutually exclusive?
Core Section(s) affected: 10.7 Privacy Feature
EDITOR’S NOTE: Add text as second paragraph following Table 10.3 as

shown below
A device may support either Host-based privacy or both Host-based and

Controller-based privacy. When a device supports Controller-based privacy,
some of the privacy functionality is configured to be performed by the
Controller by the Host.

16.21 E6356 – Defining scanner’s device address in

“Scanner filter policy”
Core Section(s) affected: 10.7 Privacy Feature
10.7.1.1 Privacy Feature in a Peripheral

with Controller-based privacy
10.7.2.1 Privacy Feature in a Central with Controller-

based privacy
12.5 Resolvable Private Address Only
Section 10.7
Two modes of privacy exist:

• Device Privacy Mode: When a device is in device privacy mode, it is only
concerned about its own privacy. It should accept advertising packets from
peer devices that contain their identity addresses as well as their private
address, even if the peer device has distributed its IRK. A device shall only
use this mode when the Resolvable Private Address Only characteristic is
not present in the GAP service of the peer device.
• Network Privacy Mode. When a device is in network privacy mode, it shall
not accept advertising packets containing the identity address of peer
devices that have distributed their IRK.
A device may use different modes for different peers.
[...]
• If the Host wants to be in device privacy mode, it shall so instruct the
Controller for each peer in the resolving list.

Section 10.7.1.1
By default, network privacy mode is used when private addresses are resolved
and generated by the Controller.
Section 10.7.2.1
By default, network privacy mode is used when private addresses are resolved
and generated by the Controller.
Section 10.8
After a device has distributed its IRK, it should use resolvable private
addresses when establishing a connection with a peer device to which the IRK
has been distributed.
Section 12.5
12.5 Resolvable Private Address Only
The device shall check if the peer will only use Resolvable Private Addresses
(RPAs) after bonding by reading the Resolvable Private Address Only
characteristic.
The Resolvable Private Address Only characteristic defines whether the device
will only use Resolvable Private Addresses (RPAs) as local addresses. See
Table 12.8.
Attribute Handle Attribute Type Attribute Value Attribute Permissions
0xMMMM 0x2AC9 - UUID of « Resolvable Private Readable without

Resolvable Private Address Only authentication or autho-
Address Only » rization.
Not writable.
Table 12.8: Resolvable Private Address Only Characteristic
The Resolvable Private Address Only characteristic value shall be 1 octet in

length:
0 = only Resolvable Private Addresses will be used as local addresses after
bonding
1 – 255 = Reserved

A device shall have only one instance of the Resolvable Private Address Only
characteristic. If the Resolvable Private Address Only characteristic is not
present, then it cannot be assumed that only Resolvable Private Addresses will
be used over the air.
16.22 E5418 – If the request to distribute the IRK fails...
Core Section(s) affected: 10.7.2 Privacy Feature in a Central
EDITOR’S NOTE: Remove text as shown below
Section 10.7.2
If, a privacy-enabled Central, that has a stored bond, receives a resolvable
private address, the Host may resolve the resolvable private address by
performing the "resolvable private address resolution procedure" as defined in
Section 10.8.2.3. If the resolution is successful, the Host may accept this and
future connection attempts from this device; otherwise, the Host will ignore the
remote device.
Section 10.8
A bonded device shall process a resolvable private address as defined in
Section 10.8.2.3 or by establishing a connection and then performing the
authentication procedure as defined in Section 10.3. A device that uses
generates a resolvable private address for its local address shall always
request to distribute its IRK value as defined in [Vol 3] Part H, Section 3.6.4 if
both sides are bondable, unless keys have been pre-distributed. If the request
to distribute the IRK fails then the peer device may authenticate re-connections
using the authentication procedure as defined in Section 10.3 or terminate the
current connection.
16.23 E4872 – Slave Connection Interval Range parameters
Core Section(s) affected: 11.1.8 Slave Connection Interval Range

The Slave Connection Interval Range AD type contains the Peripheral’s

preferred connection interval range, for all logical connections. See [Vol. 3] Part
C, Section 12.3.
16.24 E5435 – UUID mnemonic shoud be «Generic Access

Profile» instead of «GAP Service»
GAP Service and Characteristics for GATT

Core Section(s) affected: 12 Server
EDITOR’S NOTE: No change to the Core specification. Should this section be

included in the ESR at all?
16.25 E6401 – Central Address Resolution Char in LE

Peripheral

EDITOR’S NOTE: Change conditional and add description
Characteristics Ref. BR/EDR LE LE LE LE

GAP Role Broadcaster Observer Peripheral Central
Central Address 12.4 O E E C23 C2

Resolution
C1: Mandatory for BR/EDR/LE type devices, else optional

C2: Mandatory if Link Layer Privacy is supported, otherwise excluded
C3: Optional if Link Layer Privacy is supported, otherwise excluded
Table 12.2: Requirements related to GAP Service characteristics

16.26 E7355 – Add Resolvable Private Address Only to Table

12.2

EDITOR’S NOTE: Add a new row for Resolvable Private Address Only to table
12.2. In v4.0 it’s table 12.1.
BR/EDR LE LE LE LE
Characteristics Ref. GAP Role Broadcaster Observer Peripheral Central
Resolvable Pri-
12.5 O E E C3 C3
vate Address Only
16.27 E6745 – Unclear specification regarding circumstances

when Generic Access and Generic Attribute
services are mandatory

15.2 GATT Profile Requirements
15.3 SDP Requirements
Section 12
The GATT server shall contain the GAP service as defined in the GAP Service
Requirements in Table 12.1for devices supporting the Central and Peripheral
GAP roles and BR/EDR GAP role for BR/EDR/LE type devices. The GATT
Server may contain the GAP service for BR/EDR type devices supporting the
BR/EDR GAP role. A device shall have only one instance of the GAP service in
the GATT server. The GAP service is a GATT based service with the service
UUID as «GAP Service» defined in the Bluetooth Assigned Numbers
document.

Section 15.2
A BR/EDR or BR/EDR/LE device that supports the GATT profile on the BR/
EDR physical transport shall implement the GATT server. A BR/EDR/LE or LE-
only device that supports the LE Central and/or Peripheral roles shall
implement the GATT serverThe requirements for supporting a GATT Client or
GATT Server are specified in Table 15.1.
Section 15.3
BR/EDR and BR/EDR/LE devices shall implement either an SDP server or an

SDP client. A BR/EDR or BR/EDR/LE device that supports a GATT server shall
implement an SDP server. BR/EDR and BR/EDR/LE devices may implement
both an SDP server and an SDP client. There shall be no more than one active
SDP server per device. SDP client and server are excluded for the LE-only
device typeThe requirements for supporting an SDP Client or SDP Server are
specified in Table 15.2. There shall be no more than one active SDP server per
device.
16.28 E6574 – Typo
Core Section(s) affected: 12.4 Central Address Resolution
EDITOR’S NOTE: Fix brackets
Attribute Handle Attribute Type Attribute Value Attribute Permissions
0xMMMM 0x2AA6 - UUID of Central Address Readable without

«<<Central Address Resolution Support authentication or autho-
Resolution>>» rization.
Not writable.
Table 12.7: Central Address Resolution Characteristic
16.29 E7354 – Allocate value 0x2AC9 to Resolvable Private

Address Only

Core Section(s) affected: 12.5 Resolvable Private Address Only
EDITOR’S NOTE: Replace TBD in the 2nd column with 0x2AC9. See E6356.
16.30 E5399 – GAP 13.2 in Budapest has conflicting

requirements
Core Section(s) affected: 13.2 Bonding for BR/EDR/LE Device Type
EDITOR’S NOTE: Change “M” to “O” as shown below in Table 13.2
Bonding Requirement Ref. Peripheral Central
Bonding 6.5 / 9.4.4 OM OM
16.31 E7032 – Definitions are BR/EDR-specific
Core Section(s) affected: 16 Definitions
In the following, terms written with capital letters refer to states.
Most definitions in this section are BR/EDR specific.

17 [Vol 3] Part D: TEST SUPPORT
17.1 E7075 – Editorial consistency
E7075 4.2 4.1 4.0 3.0 2.1 Vol 3, Part D Test Support
Core Section(s) affected: 1.1.2.2 Pseudorandom Sequence
EDITOR’S NOTE: In the first paragraph, change PRBS-9 to PRBS9.
The same pseudorandom sequence of bits shall be used for each transmission
(i.e. the packet is repeated). A PRBS-9PRBS9 Ssequence is used, see [2] and
[3].
17.2 E6525 – The future is here
E6525 4.2 4.1 4.0 Vol 3, Part D Test Support
Core Section(s) affected: 1.1.3 LoopBack Test
EDITOR’S NOTE: Revise text in footnote for Packet Class after Figure 1.9
Packet Class1
1. This is included because, in the future, the packet type numbering may not remainis
unambiguous.
E6421 4.2 4.1 4.0 3.0 2.1, Vol 3, Part D Test Support
CSA4
[Vol 3] Part D: Test Support 06 December 2016


(GAP)
Core Section(s) affected: 1.2.1 Methodology Overview
The "Optional Control" interface shown in Figure 1.10 is a vendor specific

interface that allows local control of the AMP Test Manager when a BR/EDR
link may not beis not available.
[Vol 3] Part D: Test Support 06 December 2016

18 [Vol 3] Part F: ATTRIBUTE PROTOCOL (ATT)
E6575 4.2 4.1 4.0 Vol 3, Part F Attribute Protocol (ATT)
Vol 3, Part G Generic Attribute Profile (GATT) Section 19.1
Core Section(s) affected: 1.3 Conventions [new]
EDITOR’S NOTE: Add a new subsection as shown below
1.3 CONVENTIONS
In this specification PDU names appear in italics. Error codes defined in Table
3.3 (see Section 3.4.1.1) appear in « » (e.g. «Attribute Not Found»). Other
names such as parameters appear in Roman text.
18.2 E4243 – Clarification of signed write command data
Core Section(s) affected: 3.4.5.4 Signed Write Command
EDITOR’S NOTE: Add text to the forth paragraph
The attribute signature shall be calculated as defined in Section 3.3.1.

For example, if the variable length message m to be signed is ‘D212001337’,
SignCounter is 0x00000001 and key is
0x611B64EBFBCD1FD372EC9196DF425E50, then message to be signed (M)
by the CMAC function is the octet sequence ‘D21200133701000000’.
The padding(M) is 0x0000000137130012D280000000000000, resultant
CMAC is 0xF20F903C931E87F159B64F012574B4D0 and Authentication
Signature is the octet sequence ‘01000000F1871E933C900FF2’.
The final signed message is ‘D21200133701000000F1871E933C900FF2’.
[Vol 3] Part F: Attribute Protocol (ATT) 06 December 2016

18.3 E5919 – Clearly state separate authentication and

encryption for read and write
Core Section(s) affected: 3.2.5 Attribute Permissions
EDITOR’S NOTE: Add paragraph after bulleted list
The following authorization permissions are possible:

• Authorization Required
• No Authorization Required
Encryption, authentication, and authorization permissions can have different

possibilities; for example, a specific attribute could require a particular kind of
authentication or a certain minimum encryption key length. An attribute can
have several combinations of permissions that apply; for example, a specific
attribute could allow any of the following:
• Read if encrypted (authentication not required)
• Write if authenticated and encrypted
• Read or write if authenticated and authorized (irrespective of encryption)
18.4 E6098 – Attribute Not Long description error
Core Section(s) affected: 3.4.1.1 Error Response
EDITOR’S NOTE: Delete text in description for “Attribute Not Long”
Name Error Code Description
Attribute Not Long 0x0B The attribute cannot be reador written

using the Read Blob Request.

18.5 E5107 – Discrepency in Attribute Data List Size in Table

3.24
Core Section(s) affected: 3.4.4.10 Read by Group Type Response
EDITOR’S NOTE: Change size (octets) for Attribute Data List in Table 3.24
Parameter Size (octets) Description
Attribute Opcode 1 0x11 = Read By Group Type

Response
Length 1 The size of each Attribute Data
Attribute Data List 24 to (ATT_MTU- 2) A list of Attribute Data
Table 3.24: Format of Read By Group Type Response
18.6 E5610 – Provide error code for Execute Write response

when there is no Prepare write request
E5610 4.2 4.1 4.0 3.0 2.1 Vol 3, Part F Attribute Protocol (ATT)
Core Section(s) affected: 3.4.6.3 Execute Write Request
EDITOR’S NOTE: Add new paragraph after third paragraph
When the flags parameter is set to 0x00 all pending prepare write values shall
be discarded for this client. The queue shall then be cleared, and an Execute
Write Response shall be sent.
If there are no pending prepared write values, then no values are written, and
an Execute Write Response shall be sent.

19 [Vol 3] Part G: GENERIC ATTRIBUTE PROFILE (GATT)
E6575 4.2 4.1 4.0 Vol 3, Part G Generic Attribute Profile (GATT)
Vol 3, Part F Attribute Protocol (ATT) Section 18.1
Core Section(s) affected: 1.5 Conventions
4.6.1 Discover all Characteristics of a Service
Section 1.5
In this specification the use of literal terms such as procedure, PDUs, opcodes
or function names appear in italics. Specific names of fields in structures, pack-
ets, etc. also appear in italics. The use of « » (e.g. «Primary Service») indicates
a Bluetooth SIG-defined UUID or an Attribute Protocol error code (see [Vol 3]
Part F, Table 3.3).
Section 4.6.1 – after Figure 4.5, add the following paragraph:

Note: In this example «UUID1» and «UUID2» are 16 bits (2 octets).
If they were 128 bits (16 octets) then the Read By Type Response data would
instead be:
0x15, 0x0203, 0x02, 0x0204, «UUID1», 0x0210, 0x02, 0x0212, «UUID2»
19.2 E5383 – Need clarification, if unused attribute handles in

between characteristic declaration and
Characteristic value declaration are allowed
Core Section(s) affected: 2.5.1 Overview
EDITOR’S NOTE: Add text to the end of the second to last paragraph
[...] Although the Attribute Handle values are in increasing order, following
Attribute Handle values may differ by more than one. That is to say there may
[Vol 3] Part G: Generic Attribute Profile (GATT) 06 December 2016

be gaps between successive Attribute Handles. When this specification

requires two attribute handles to be adjacent or for one to immediately follow
one the other, such gaps are still permitted and shall be ignored.
19.3 E7072 – Possible typo
Core Section(s) affected: 3.3 Characteristic Definition
EDITOR’S NOTE: In first paragraph, second sentence replase “or” with “of”,
A characteristic definition ends at the start orof the next characteristic

declaration or service declaration or after the maximum Attribute Handle.
19.4 E5242 – Characteristic properties usage needs

clarification
Core Section(s) affected: 3.3.1.1 Characteristic Properties
EDITOR’S NOTE: Revise text in second paragraph as shown below
These bits shall be set according to the procedures allowed for this
characteristic, supportsas defined by higher layer specifications, without regard
to security requirements.

19.5 E7065 – Reserved for future use mask appears to be

incorrect
Core Section(s) affected: 3.3.3.3 Client Characteristic Configuration
EDITOR’S NOTE: Correct the figures in the tables below:
Attribute
Handle Attribute Type Attribute Value Attribute Permissions
0xNNNN 029020x2902 – UUID Characteristic Readable with no authentica-

for «Client Character- Configuration Bits tion or authorization. [...]
istic Configuration»
Table 3.10: Client Characteristic Configuration declaration
Configuration Value Description
Reserved for 0xFFF4 Reserved for future use.

Future Use FFFC
Table 3.11: Client Characteristic Configuration bit field definition
19.6 E7066 – Reserved for future use mask appears to be

incorrect
Core Section(s) affected: 3.3.3.4 Server Characteristic Configuration
EDITOR’S NOTE: Correct the figure in the table below:
Configuration Value Description
Reserved for 0xFFF2 Reserved for future use.

Future Use FFFE
Table 3.13: Server Characteristic Configuration bit field definition

19.7 E4654 – Octet alignment in Aggregate Characteristics
E4654 4.2 Vol 3, Part G Generic Attribute Profile (GATT)
Core Section(s) affected: 3.3.3.5.2 Format
EDITOR’S NOTE: Revise text in 1st paragraph
The format field determines how a single value contained in the Characteristic
Value is formatted. If a format is not a whole number of octets, then the data
shall be contained within the least significant bits of the value, and all other bits
shall be set to zero on transmission and ignored upon receipt. If the
Characteristic Value is less than an octet, it occupies an entire octet.If a format
is not a whole number of octets, then the data shall be stored in the smallest
number of octets that can contain the value. The data 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 set to zero on transmission and ignored upon receipt.
19.8 E6582 – Wrong procedure name used
E6582 4.2 4.1 Vol 3, Part G Generic Attribute Profile (GATT)
Core Section(s) affected: 4.4.2 Discover Primary Service by Service UUID
This sub-procedure is complete when the Error Response is received and the
Error Code is set to «Attribute Not Found» or when the End Group Handle in
the Read by Type GroupFind By Type Value Response is 0xFFFF.

19.9 E5719 – Issue on knowing the size of Long

Characteristic value for using Read Blob
Request
Core Section(s) affected: 4.8.1 Read Characteristic Value
EDITOR’S NOTE: Change the second paragraph to read as follows:
The Read Response only contains athe complete Characteristic Value if that is
less than or equal to (ATT_MTU – 1) octets in length. If the Characteristic Value
is greater than (ATT_MTU – 1) octets in length, the Read Response only
contains the first portion of the Characteristic Value and the Read Long
Characteristic Value procedure may be used if the rest of the Characteristic
Value is required.
19.10 E5718 – Issues on 4.8.2 Read Using Characteristic

UUID
Core Section(s) affected: 4.8.2 Read Using Characteristic UUID
Read By Type Response returns a list of Attribute Handle and Attribute Value
pairs corresponding to the characteristics contained in the handle range
provided.Read By Type Response returns a list of Attribute Handle and
Attribute Value pairs corresponding to the first characteristics contained in the
handle range that will fit into the Read By Type Response PDU. This procedure
does not return the complete list of all characteristics with the given
characteristic UUID within the range of values. If such an operation is required,
then the Discover All Characteristics by UUID sub procedure shall be used.

19.11 E5717 – Errata on Figure 4.10: Read Long

Characteristic Values example
E5717 4.2 4.1 Vol 3, Part G Generic Attribute Profile (GATT)
Core Section(s) affected: 4.8.3 Read Long Characteristic Values
EDITOR’S NOTE: Change 2nd and 3rd “Read Response” to “Read Blob
Response” in Figure 4.10
&OLHQW 6HUYHU
5HDG5HTXHVW[
5HDG5HVSRQVH$9HU\/RQJ'HYLFH1DP
5HDG%ORE5HTXHVW[[
5HDG%ORE5HVSRQVHH8VLQJ$/RQJ$WWULEX
5HDG%ORE5HTXHVW[[&
5HDG%ORE5HVSRQVHWH
19.12 E7028 – Missing the last word
Core Section(s) affected: 4.10.1 Notifications
4.11.1 Indications
EDITOR’S NOTE: Change “Attribute Handle” to italics and revise text as shown
below. In v4.0, the image didn’t have a typo.

Section 4.10.1
[...] The Attribute Protocol Handle Value Notification is used to perform this
sub-procedure. The Attribute Handle parameter shall be set to the
Characteristic Value Handle being notified, and the Attribute Value parameter
shall be set to the Characteristic Value.
Section 4.11.1
[...] The Attribute Protocol Handle Value Indication is used to perform this sub-
procedure. The Attribute Handle parameter shall be set to the Characteristic
Value Handle being indicated, and the Attribute Value parameter shall be set to
the cCharacteristic Value. Once the Handle Value Indication is received by the
client, the client shall respond with a Handle Value Confirmation.
&OLHQW 6HUYHU
+DQGOH9DOXH,QGLFLDWLRQ[[
+DQGOH9DOXH&RQILUPDWLRQ
19.13 E5359 – Need clarification which portion of the service

are protected
Core Section(s) affected: 7.1 Service Changed
The Service Changed Characteristic Value is two 16-bit Attribute Handles

concatenated together indicating the beginning and ending Attribute Handles
affected by an addition, removal, or modification to a GATT-based service on

the server. A change to a characteristic value is not considered a modification

of the service.

20 [Vol 3] Part H: SECURITY MANAGER
20.1 E7301 – Cross Transport Key Derivation hash inputs
E7301 4.2 4.1 4.0 Vol 3, Part H Security Manager
Core Section(s) affected: 2.2 Cryptographic Toolbox
2.2.11 Link Key Conversion Function h7
2.4.2.4 Derivation of BR/EDR Link Key from LE LTK
2.4.2.5 Derivation of LE LTK from BR/EDR Link Key
3.5.1 Pairing Request
3.5.2 Pairing Response
D.8 h7 LE SC Link Key Conversion Function
D.9 LTK to Link Key Conversion Using CT2=1
D.11 Link Key to LTK Conversion Using CT2=1
D.12 Link Key to LTK Conversion Using CT2=0
EDITOR’S NOTE: Revise text as shown below. All section except 3.5.1 apply
only to v4.2.
Section 2.2
• h6 is used to generate the LE LTK from a BR/EDR link key derived from
Secure Connections and is used to generate the BR/EDR link key from an
LE LTK derived from Secure Connections.
• h7 is used to generate intermediate keys while generating the LE LTK from a
BR/EDR link key derived from Secure Connections and the BR/EDR link key
from an LE LTK derived from Secure Connections.
The building block for the cryptographic functions ah, c1 and s1 is the security
function e.
The building block for the cryptographic functions f4, f5, f6, g2, h6 and h67 is
the security function AES-CMAC.
[Vol 3] Part H: Security Manager 06 December 2016

Inside the f4, f5, f6, g2, h6 and h67 functions when a multi-octet integer
parameter is used as input to AES-CMAC the most significant octet of the
integer shall be the first octet of the stream and the least significant octet of the
integer shall be the last octet of the stream. The output of AES-CMAC inside
these functions is a multi-octet integer where the first octet is MSB and the last
octet is LSB of this integer.
Section 2.2.11
2.2.11 Link Key Conversion Function h7
The function h7 is used to convert keys of a given size from one key type to
another key type with equivalent strength.
The definition of the h7 function makes use of the hashing function AES-
CMACW with 128-bit key W.
The inputs to function h7 are:

W is 128 bits
SALT is 128 bits
W is used as input m to the hashing function AES-CMAC and SALT is used as

the key k (2.4.5).
The output of h7 is as follows:
h7(W, SALT) = AES-CMACSALT(W)
Section 2.4.2.4
The LTK from the LE physical transport can be converted to the BR/EDR link
key for the BR/EDR transport as follows, using intermediate link key (ILK) as
an intermediate value:
If at least one device sets CT2 = 0 then
1. ILK = h6(LTK, “tmp1”)

2. BR/EDR link key = h6(ILK, “lebr”)
If both devices set CT2 = 1 then
1. ILK = h7(LTK, SALT)

2. BR/EDR link key = h6(ILK, “lebr”)

The string “lebr” is mapped into keyID using extended ASCII as follows:
keyID[0] = 0111 0010
keyID[1] = 0110 0010
keyID[2] = 0110 0101
keyID[3] = 0110 1100
keyID = 0x6c656272
The string “tmp1” is mapped into keyID using extended ASCII as follows:
keyID[0] = 0011 0001
keyID[1] = 0111 0000
keyID[2] = 0110 1101
keyID[3] = 0111 0100
keyID = 0x746D7031
SALT is defined as follows:

SALT = 0x00000000000000000000000000000000746D7031
Note: If the LTK has an encryption key size that is less than 16 octets (128
bits), the BR/EDR link key is derived before the LTK gets masked.
Section 2.4.2.5
The BR/EDR Link Key from the BR/EDR physical transport can be converted to
the LTK for the LE transport as follows, using intermediate long term key (ILTK)
as an intermediate value:
If at least one device sets CT2 = 0 then
1. ILTK = h6(Link Key, “tmp2”)

2. LTK = h6(ILTK, “brle”)
If both devices set CT2 = 1 then
1. ILTK = h7(Link Key, SALT)

2. LTK = h6(ILTK, “brle”)
The string “brle” is mapped into keyID using extended ASCII as follows:
keyID[0] = 0110 0101
keyID[1] = 0110 1100
keyID[2] = 0111 0010
keyID[3] = 0110 0010
keyID = 0x62726c65

The string “tmp2” is mapped into keyID using extended ASCII as follows:
keyID[0] = 0011 0010
keyID[1] = 0111 0000
keyID[2] = 0110 1101
keyID[3] = 0111 0100
keyID = 0x746D7032
The SALT is defined as follows:

SALT = 0x00000000000000000000000000000000746D7032
Section 3.5.1
Editor’s note: see E7461.

LSB MSB
Bonding_Flags MITM SC Keypress CT2 Reserved

(2 bits) (1 bit) (1 bit) (1 bit) (1 bit) (2 bits)
Figure 3.3: Authentication Requirements Flag
The keypress field is a 1-bit flag that is used only in the Passkey Entry protocol
and is ignored in other protocols. When both sides set that field to one,
Keypress notifications shall be generated and sent using SMP Pairing
Keypress Notification PDUs.
The CT2 field is a 1-bit flag that shall be set to 1 upon transmission to indicate
support for the h7 function. See sections 2.4.2.4 and 2.4.2.5. The CT2 field
shall ignored upon reception when at least one device sets SC to 0.
The reserved 32-bit field shall be set to zero and ignored upon reception.
Editor’s note: Figure 3.3 in v4.1 and earlier does not have sections SC (1 bit) or
Keypress (1 bit).
Section 3.5.2
Editor’s note: see E7461.
support for the h7 function. See sections 2.4.2.4 and 2.4.2.5. The CT2 field
shall ignored upon reception when at least one device sets SC to 0.
The reserved 32-bit field shall be set to zero and ignored upon reception.

Section D.8
D.8 h7 LE SC Link Key Conversion Function
Key ec0234a3 57c8ad05 341010a6 0a397d9b

Salt 00000000 00000000 00000000 746D7031
AES_CMAC fb173597 c6a3c0ec d2998c2a 75a57011
Section D.9
LTK 368df9bc e3264b58 bd066c33 334fbf64

Link Key 287ad379 dca40253 0a39f1f4 3047b835
Section D.10
LTK 368df9bc e3264b58 bd066c33 334fbf64

Link Key bc1ca4ef 633fc1bd 0d8230af ee388fb0
Section D.11
D.11 LINK KEY to LTK Conversion Using CT2=1
Link Key 05040302 01000908 07060504 03020100

LTK e85e09eb 5eccb3e2 69418a13 3211bc79
Section D.12
D.12 LINK KEY to LTK Conversion Using CT2=0
Link Key 05040302 01000908 07060504 03020100

LTK a813fb72 f1a3dfa1 8a2c9a43 f10d0a30
20.2 E6796 – A and B BD_ADDR
E6796 4.2 Vol 3, Part H Security Manager
Core Section(s) affected: 2.3.5.6.4 Authentication Stage 1 – Out of Band

2.3.5.6.5 Authentication Stage 2 and Long Term Key

Calculation
EDITOR’S NOTE: In Figures 2.5 and 2.6 replace "BD_ADDR" with "Device
Address” (twice in each figure).
20.3 E6219 – What happens when a Master ignores the Slave

Security Request?
Core Section(s) affected: 3.4 SMP Timeout
EDITOR’S NOTE: Revise first paragraph
To protect the Security Manager protocol from stalling, a Security Manager

Timer is used. Upon transmission of the PairingSecurity Request command or
reception of the PairingSecurity Request command, the Security Manager
Timer shall be reset and restarted. Upon transmission of the Pairing Request
command or reception of the Pairing Request command, the Security Manager
Timer shall be reset and started.
20.4 E4796 – SM procedure is not defined
Core Section(s) affected: 3.4 SMP Timeout
When aSMP Pairing process completes, the Security Manager Timer shall be
stopped.
If the Security Manager Timer reaches 30 seconds, the procedure shall be

considered to have failed, and the local higher layer shall be notified. No further
SMP commands shall be sent over the L2CAP Security Manager Channel. A

new SM procedurePairing process shall only be performed when a new

physical link has been established.
20.5 E7461 – Problem with CT2 bit in Auth Req when running
over BR/EDR
Core Section(s) affected: 3.5.1 Pairing Request
3.5.2 Pairing Response
EDITOR’S NOTE: Delete and add text as shown below. See also E7301.
Section 3.5.1
support for the h7 function. See sections 2.4.2.4 and 2.4.2.5.
[...]
If Secure Connections pairing has been initiated over BR/EDR, the IO

Capability, OOB data flag and Auth Req following fields of the SM Pairing
Request PDU shall be set to zero on transmission, and ignored on reception:.
• the IO Capability field,
• the OOB data flag field, and
• all bits in the Auth Req field except the CT2 bit.
Section 3.5.2
support for the h7 function. See Sections 2.4.2.4 and 2.4.2.5.
[...]

If Secure Connections pairing has been initiated over BR/EDR, the IO

Capability, OOB data flag and Auth_Reqfollowing fields of the SM Pairing
Response PDU shall be set to zero on transmission, and ignored on reception:.
• the IO Capability field,
• the OOB data flag field, and
• all bits in the Auth Req field except the CT2 bit.
20.6 E6824 – Typo on error code description
Core Section(s) affected: 3.5.5 Pairing Failed
EDITOR’S NOTE: Revise description in Table 3.7
Value Name Description
0x0D BR/EDR pairing in progress Indicates that the pairing over the
LE transport failed due to a Pairing Request
sent over the BR/EDR transport in process-
gress.
Table 3.7: Pairing Failed Reason Codes
20.7 E6436 – Sign to SignKey
Core Section(s) affected: 3.6.1 Key Distribution and Generation
EDITOR’S NOTE: Update Figure 3.11 and revise 3rd bullet after figure
LSB MSB
EncKey IdKey SignKey LinkKey Reserved

(1 bit) (1 bit) (1 bit) (1 bit) (4 bits)
Figure 3.11: LE Key Distribution Format

• SignKey is a 1-bit field that is set to one to indicate that the device shall
distribute CSRK using the Signing Information command.

If EncKey, IdKey, and SignKey are set to zero in the Initiator Key Distribution /
Generation and Responder Key Distribution / Generation fields, then no keys
shall be distributed or generated and the link will be encrypted using the
generated STK when using LE legacy pairing and LTK when using LE Secure
Connections pairing.
Versions 4.1 and 4.0

Figure number is 3.8
20.8 E6729 – Possible confusion on how to set the EncKey

bit
Core Section(s) affected: 3.6.1 Key Distribution and Generation
EDITOR’S NOTE: Revise 2nd paragraph of 1st bullet after Figure 3.11
When the SC bit is set to 1 by both devices and ifIn LE Secure Connections
pairing, when SMP is running on the LE transport, then the EncKey field is
ignored. EDIV and Rand shall be set to zero and shall not be distributed.
E6421 4.2 4.1 4.0 3.0 2.1, Vol 3, Part H Security Manager
CSA4


(GAP)
Core Section(s) affected: B.2.2 Generating Keys from ER
This method provides an LTK and CSRK with limited amount of entropy
because LTK and CSRK are directly related to EDIV and may not be asless
secure asthan other generation methods.
20.10 E6946 – Applicability of key generation formulas from

section B.2
Core Section(s) affected: B.2.2 Generating Keys from ER
B.2.3 Generating Keys from IR
Section B.2.2
Note: The generation of LTK using ER is only applicable when doing LE

Legacy Pairing. The generation of CSRK using ER is applicable both when
doing LE Legacy Pairing and LE Secure Connections Pairing.
Section B.2.3
Note: The generation of DHK using IR is only applicable when doing LE

Legacy Pairing. The generation of IRK using IR is applicable both when doing
LE Legacy Pairing and LE Secure Connections Pairing.

21 [Vol 4] Part B: USB TRANSPORT LAYER
21.1 E6264 – Missing link
E6264 4.2 4.1 4.0 3.0 2.1 Vol 4, Part A UART Transport Layer
Core Section(s) affected: 2 AMP User Asynchronous/Isochronous
EDITOR’S NOTE: Fix hyperlink
[...] HCI Synchronous Data Packet (see [Vol 2] Part E, Host Controller Interface
Functional Specification“Host Controller Interface Functional Specification” in
Volume 2, Part E). HCI Command Packets can only be sent to the Bluetooth
Host Controller, HCI Event Packets can only be sent from the Bluetooth [...][
21.2 E4165 – DFU v1.1 now available
E4165 4.2 4.1 4.0 3.0 2.1 Vol 4, Part B USB Transport Layer
Core Section(s) affected: 4 Device Firmware Upgrade
EDITOR’S NOTE: Revise text
Firmware upgrade capability is not a required feature. But iIf implemented, the
firmware upgrade shallshould be compliant with the “Universal Serial Bus
Device Class Specification for Device Firmware Upgrade” (version 1.01 dated
May 13, 1999or later) available on the USB Forum web site at
http://www.usb.org.
[Vol 4] Part B: USB Transport Layer 06 December 2016

22 [VOL 5] PART A: 802.11 PROTOCOL ADAPTATION

LAYER
E6421 4.2 4.1 4.0 3.0 2.1, Vol 5, Part A 802.11 PAL
CSA4

(GAP)
Core Section(s) affected: 2.14.7 Preferred Channel List v2
3.2.1 Overview
5.2.1 Interference from Collocated Radios
Section 2.14.7
If a PCLv2 TLV is not included in the AMP Get AMP Assoc Request message
from a responder, then the initiating PAL shall not assume that the responder
may not havehas the ability to interpret PCLv2 TLVs.[...]
Section 3.2.1
The initiating PAL may not be able to select a suitable channelThere may be no
suitable channel that the initiating PAL can select or the responding PAL may
reject the selected channel. If the selection process cannot identify a channel,
then the physical link establishment shall be aborted.
[Vol 5] Part A: 802.11 Protocol Adaptation Layer 06 December 2016

Section 5.2.1
Interference can also arise between the 802.11 AMP radio and collocated
licensed band radios (LBRs) operating in adjacent bands to the ISM spectrum.
Due to 802.11 AMP transmissions, the collocated LBR may not be unable to
receive transmissions from its peer LBR.[...]
22.2 E7036 – Provide more specificity on OUI to be used in

SNAP header on AMP PAL
E7036 4.2 4.1 4.0 3.0 Vol 5, Part A 802.11 PAL
Core Section(s) affected: 3.5.5 Transporting Security Handshake Messages
EDITOR’S NOTE: Add reference to Table 5.1 in the second paragraph.
The SNAP header composed of the OUI of the Bluetooth SIG as shown in
Table 5.1 and the protocol identifier given in Table 5.2 shall be used to
distinguish AMP 4-way handshake messages from external security traffic.
[Vol 5] Part A: 802.11 Protocol Adaptation Layer 06 December 2016

23 [VOL 6] PART A: PHYSICAL LAYER SPECIFICATION
23.1 E6228 – Assessment of the PHY part vs current

regulatory references and practises
E6228 4.2 4.1 4.0 Vol 6, Part A Physical Layer Specification Section 7.1
Core Section(s) affected: 1 Scope
A.1.1 Normal Temperature and Air Humidity
A.2 Extreme Operating Conditions (EOC)
A.2.1 Extreme Temperature And Air Humidity
A.2.2 Extreme Supply Voltage
B Operating Conditions
EDITOR’S NOTE: Revise text as shown below. Affected by E6199.
Section 1
The radio parameters shall be measured according to the methods described

in the LE RF PHY Test Specification.
Europe:
Approval Standards: European Telecommunications Standards Institute, ETSI
Documents: EN 300 328, EN 300 440, EN 301 489-17EN 301 489, ETS 300-
826
Section A.1.1
The normal operating temperature shall be declared by the product

manufacturer. The nominal test temperature shall be within ±10°C of the
normal operating temperature. The nominal operating temperature ±10°C shall
not exceed the extreme limits stated in Section A.2.1.
Operating air humidity range shall be declared by the product manufacturer.

The air humidity level for the nominal test condition tests shall be within the
declared NOC range.
Section A.2
Extreme Operating Conditions (EOC)
[Vol 6] Part A: Physical Layer Specification 06 December 2016

Section A.2.1
The extreme temperature limits are defined as the minimum and maximum
temperatures of the operating temperature range declared by the product
manufacturer.
For the extreme test condition, the air humidity shall be at a level within the
operating air humidity range declared by the product manufacturer (see
Section A.1.1).
Section A.2.2
The extreme supply voltages are dependent on the characteristics of the

product’s power supply.
If the product is designed to be operated as a part of another system or a

portion of a product, the extreme voltage limits for this product or system shall
be used.
The applicable upper and lower extreme supply voltages shall be declared by
the product manufacturer.
Section B
The LE radio parameters shall be compliant in the following conditions.
Parameter Temperature Power supply
Output power EOC EOC
In-band emissions EOC EOC
Modulation characteristics NOC NOC
Carrier frequency offset and drift EOC EOC
Receiver sensitivity EOC EOC
C/I and selectivity performance NOC NOC
Blocking performance NOC NOC
Intermodulation performance NOC NOC
Maximum input signal level NOC NOC
EOC = Extreme Operating Conditions

NOC = Normal Operating Conditions
Note: Validation of the LE receiver parameters is performed using the Direct

Test Mode (see [Vol 6] Part F).
[Vol 6] Part A: Physical Layer Specification 06 December 2016

24 [Vol 6] Part B: LINK LAYER SPECIFICATION
24.1 E6710 – Title "State and Role Combination Restrictions"

may be revised
E6710 4.2 4.1 4.0 Vol 6, Part B Link Layer
Core Section(s) affected: 1.1.1 State and Role Combination Restrictions
EDITOR’S NOTE: Revise section heading
1.1.1 Permitted State and Role Combination Restrictions
24.2 E6182 – Invalid behavior with resolving address list not

clear in Core or Test Spec
E6182 4.2 Vol 6, Part B Link Layer
Core Section(s) affected: 1.3 Device Address
EDITOR’S NOTE: Revise the third paragraph as follows:
Section 1.3
A device's Identity Address is a Public Device Address or Random Static

Device Address that it uses in packets it transmits. If a device is using
Resolvable Private Addresses, it shall also have an Identity Address that is
either a Public Device Address or Random Static Device Address type.
24.3 E6443 – IEEE terminology change
[Vol 6] Part B: Link Layer Specification 06 December 2016

Core Section(s) affected: 1.3.1 Public Device Address
EDITOR’S NOTE: Revise text and illustration in section 1.3.1 as follows:
The public device address shall be created in accordance with [Vol 2] Part B,
Section 1.2, with the exception that the restriction on LAP values does not
apply unless the public device address will also be used as a BD_ADDR for a
BR/EDR Controller.section 9.2 ("48-bit universal LAN MAC addresses") of the
IEEE 802-2001 standard
(http://standards.ieee.org/findstds/standard/802-2001.html) and using a valid
Organizationally Unique Identifier (OUI) obtained from the IEEE Registration
Authority (see http://standards.ieee.org/regauth/oui/forms/ and sections 9 and
9.1 of the IEEE 802-2001 specification).
The public device address is divided into the following two fields:
• company_assigned field is contained in the 24 least significant bits
• company_id field is contained in the 24 most significant bits
LSB MSB
company_assigned company_id
(24 bits) (24 bits)
Figure 1.2: Format of public device address
24.4 E7080 – Meaning of Advertising Data
E7080 4.2 4.1 Vol 6, Part B Link Layer
Core Section(s) affected: 2.3 Advertising Channel PDU
EDITOR’S NOTE: Revise text in section 2.3 as follows:
Within advertising channel PDUs, Aadvertising Ddata or scan response data

from the Host may be included in the Payload in some PDU Types. The format
of this data is defined in [Vol 3] Part C, Section 11.

24.5 E6821 – Erratum 5707 introduces <= of

LL_CONNECTION_PARAM_REQ has not been
replicated to LL_CONNECTION_PARAM_RSP
Core Section(s) affected: 2.4.2.17 LL_CONNECTION_PARAM_RSP
EDITOR’S NOTE: Replace all contents of 2.4.2.17 with the following text:
The format of the LL_CONNECTION_PARAM_RSP PDU is identical to the

format of the LL_CONNECTION_PARAM_REQ PDU (see Section 2.4.2.16).
24.6 E6517 – PDU does not contain a PDU field
Core Section(s) affected: 3.2 Data Whitening
EDITOR’S NOTE: Revise text in first paragraph
Data whitening is used to avoid long sequences of zeros or ones, e.g.

0000000b or 1111111b, in the data bit stream. Whitening shall be applied on the
PDU and CRC fields of all Link Layer PDUspackets and is performed after the
CRC in the transmitter. De-whitening is performed before the CRC in the
receiver (see Figure 3.1).
24.7 E7025 – Inconsistent capitalization
Core Section(s) affected: 4.3.3 Scanner Filter Policy
EDITOR’S NOTE: Change capitalized D to lowercase as shown below

• The Link Layer shall process advertising packets only from devices in the
White List. A connectable dDirected advertising packet not containing the
scanner’s device address shall be ignored.
• The Link Layer shall process all advertising packets (i.e., the White List is
not used). A connectable dDirected advertising packet not containing the
scanner’s device address shall be ignored. This is the default on reset.
• The Link Layer shall process advertising packets only from devices in the
White List. A connectable dDirected advertising packet shall not be ignored
if the InitA is the scanner's device address or a resolvable private address.
• The Link Layer shall process all advertising packets (i.e., the White List is
not used). A connectable dDirected advertising packet shall not be ignored if
the InitA is the scanner's device address or a resolvable private address.
24.8 E6586 – Wording clean-up
Core Section(s) affected: 4.4.2.3 Connectable Undirected Event Type
4.4.2.5 Scannable Undirected Event Type
Non-connectable Undirected
4.4.2.6 Event Type
EDITOR’S NOTE: Revise text in the first paragraph of all three sections:
Section 4.4.2.3
When the connectable undirected advertising event type is used, advertising
indications (ADV_IND PDUs) are sent by the Link Layer.
Section 4.4.2.5
When the scannable undirected advertising event type is used, scannable
advertising indications (ADV_SCAN_IND PDUs) packets are sent by the Link
Layer.
Section 4.4.2.6
When the non-connectable undirected event type is used, non-connectable
advertising indications (ADV_NONCONN_IND PDUs) packets are sent by the
Link Layer.

24.9 E6847 – Erratum 6672: few remains of CONNECT_REQ
E6847 4.2 4.1 4.0 Vol 6, Part B Link Layer Section 26.1
4.4.2.4.1 Low Duty Cycle Directed Advertising
EDITOR’S NOTE: Change CONNECT_REQ to CONNECT_IND in Figures 4.6

and 4.8
ADV_IND ADV_IND CONNECT
_REQIND
PV T_IFS
Adv_idx = 37 Adv_idx = 38
Advertising Advertising
event event
started closed
Figure 4.6: Connectable undirected advertising event during which a CONNECT_REQIND

PDU is received
ADV_DIRECT ADV_DIRECT CONNECT_

_IND _IND REQIND
≤ 10 ms T_IFS
Adv_idx = 37 Adv_idx = 38
Advertising Advertising
Event Event
started closed
Figure 4.8: Low duty cycle connectable directed advertising event during which a
CONNECT_REQIND PDU is received
See also E6672

Core Section(s) affected: 4.4.3 Scanning State
EDITOR’S NOTE: Insert text to sixth paragraph.
[...] The scanner filter policy shall apply when receiving an advertising PDU or
scanning PDU when scanning.
24.11 E6913 – Duplicate ADVs
Core Section(s) affected: 4.4.3 Scanning State
EDITOR’S NOTE: Replace text as shown below
[...] The advertising report shall contain at least the advertiser's device address
and advertising data or scan response data if present. Duplicate advertising
reports are not required to be sent to the Host.The Host may request that
duplicate advertising reports are filtered. A duplicate advertising report is an
advertising report for the same device address while the Link Layer stays in the
Scanning State. The advertising data may change; advertising data or scan
response data is not considered significant when determining duplicate
advertising reports.
24.12 E6963 – Scan Backoff Algorithm should be an example
Core Section(s) affected: 4.4.3.2 Active Scanning
EDITOR’S NOTE: Edit section 4.4.3.2 beginning with the 4th paragraph.

The scanner shall run a backoff procedure to minimize collisions of

SCAN_REQ PDUs from multiple scanners. An example of such a procedure is
given in the following paragraphs.
The backoff procedure uses two parameters, backoffCount and upperLimit to

restrict the number of SCAN_REQ PDUs sent when collisions occur on
SCAN_RSP PDUs. Upon entering the Scanning State, the upperLimit shall be
set to one and the backoffCount shall beare set to one.
On every received ADV_IND PDU or ADV_SCAN_IND PDU that is allowed by

the scanner filter policy and a SCAN_REQ PDU is to be sent the backoffCount
shall beis decremented by one until it reaches the value of zero. The
SCAN_REQ PDU shallis only be sent when backoffCount becomes zero.
After sending a SCAN_REQ PDU the Link Layer shall listens for a SCAN_RSP
PDU from that advertiser. If the SCAN_RSP PDU was not received from that
advertiser, it is considered a failure otherwise it is considered a success. On
every two consecutive failures, the upperLimit shall beis doubled until it
reaches the value of 256. On every two consecutive successes, the upperLimit
shall beis halved until it reaches the value of one. After success or failure of
receiving the SCAN_RSP PDU, the Link Layer shall sets backoffCount to a
new pseudo-random integer between one and upperLimit inclusive.
If a device uses a different backoff algorithm it shall share the medium

responsibly.
24.13 E6734 – Spellling mistake
Core Section(s) affected: 4.5.1 Connection Events
The connInterval shall be a multiple of 1.25 ms in the range of 7.5 ms to 4.0 s.

The connInterval is set by the Initiator’s Link Layer in the CONNNECT_REQ
PDU from the range given by the Host.


as shown below
Section 4.5.1
The timing of connection events is determined by two parameters: connection

event interval (connInterval), and slave latency (connSlaveLatency).
E6421 4.2 4.1 4.0 3.0 2.1, Vol 6, Part B Link Layer
CSA4

(GAP)

4.5.9.1 Flow Control
5.1.4 Feature Exchange Procedure
Responding to
LL_CONNECTION_PARAM_REQ and
5.1.7.2 LL_CONNECTION_PARAM_RSP PDUs
Section 4.5.1
The slave shall increment connEventCounter for all connection events, even if
it mayis not be listening to the master due to slave latency in those events.
Section 4.5.9.1
A Link Layer may notfail to update nextExpectedSeqNum for reasons,
including, but not limited to, lack of receive buffer space. This will cause the
peer to resend the Data Channel PDU at a later time, thus enabling flow
control.
Section 5.1.4
[...] Cached information for a device from a previous connection mayis not
beauthoritative and, therefore, an implementation must be able to accept the
LL_UNKNOWN_RSP PDU if use of a feature is attempted that is not currently
supported or used by the peer.
Section 5.1.7.2
If the received LL_CONNECTION_PARAM_REQ PDU requests a change to
one or more of connInterval, connSlaveLatency, and connSupervisionTimeout
and if the values selected by the Link Layer are, respectively, within the range
of the connInterval, the value of connSlaveLatency and the value of
connSupervisionTimeout provided by the local Host, then the Link Layer may
choose to not indicate this request to its Host and proceed as if the Host has
accepted the remote device’s request.[...]
24.16 E6733 – Packet timing wording is technically wrong
Core Section(s) affected: 4.5.3 Connection Event Transmit Window
EDITOR’S NOTE: Revise 2nd and 4th paragraphs

The CONNECT_REQ PDU includes three parameters used to determine the

transmit window. The transmit window starts at transmitWindowOffset + 1.25
ms after the end of the packet containing the CONNECT_REQ PDU, and the
transmitWindowSize parameter shall define the size of the transmit window.
The connInterval is used in the calculation of the maximum offset and size of
the transmit window. The transmitWindowOffset and transmitWindowSize
parameters are determined by the Link Layer.
The transmitWindowOffset shall be a multiple of 1.25 ms in the range of 0 ms

to connInterval. The transmitWindowSize shall be a multiple of 1.25 ms in the
range of 1.25 ms to the lesser of 10 ms and (connInterval - 1.25 ms).
Therefore the start of the first packet will be no earlier than 1.25 ms +
transmitWindowOffset and no later than 1.25 ms + transmitWindowOffset +
transmitWindowSize after the end of the packet containing the
CONNECT_REQ PDU transmitted in the advertising channel.
Core Section(s) affected: 4.5.10 Data PDU Length Management
The Controller may change the values of connMaxTxOctets,

connMaxRxOctets, connMaxTxTime, and connMaxRxTime at any time after
entering the Connection State. Whenever it does so, it shall communicate
these values to the peer device using the Data Length Update Procedure.
If the Controller decreases the value of connMaxRxOctets or connMaxRxTime,

it shall not apply the new values until a Data Length Update Procedure
(Section 5.1.9) that sends the new value has completed.
24.18 E6553 – Confusion of packet and PDU

Core Section(s) affected: 4.5.10 Data PDU Length Management
EDITOR’S NOTE: Revise text in paragraph as shown
The controller shall not transmit Data Channel PDUspackets as part of a

connection that have a maximum Payload Length greater than
connEffectiveMaxTxOctets or that take more than connEffectiveMaxTxTime
microseconds to transmit.
24.19 E6697 – Features should always be valid between Host

and Controller
Core Section(s) affected: 4.6 Feature Support
EDITOR’S NOTE: Revise text in last paragraph
The bit positions for each Link Layer Feature shall be as shown in Table 4.4.
This table also shows if these bits are valid for the intended destinationbetween
Controllers. If a bit is shown as not valid, using ‘N’, then this bit shall be ignored
upon receipt by the peer Controller.
24.20 E6356 – Defining scanner’s device address in

“Scanner filter policy”
Core Section(s) affected: 4.7 Resolving List
6.2.1 Connectable Undirected Event Type

6.2.2 Connectable Directed Even Type
6.2.3 Non-connectable Undirected and Scannable

Undirected Event Types
6.3 Privacy in the Scanning State
6.4 Privacy in the Initiating State
6.5 Privacy of the Device
Section 4.7
The White List and filter policies set by the Host are applied to the associated
Identity Address once the Resolvable Private Address has been resolved.
If the Host, when populating the resolving list, sets a peer IRK to all zeros, then
the peer address used within an Advertisementadvertising channel PDU shall
use the peer’s Identity Address, which is provided by the Host.
The Host specifies the privacy mode to be used with each peer identitys on the
resolving list. If it specifies that device privacy mode is to be used, then the
Controller shall accept both the peer's device identity address and a resolvable
private address generated by the peer device using its distributed IRK.
Otherwise, network privacy mode is used: the Controller shall only accept
resolvable private addresses generated by the peer device using its distributed
IRK. If the Host has added the peer device to the resolving list with an all-zero
peer IRK, the Controller shall only accept the peer's identity address, as
defined in Section 6.5.
If the Host, when populating the resolving list, sets a local IRK to all zeros, then
any local address used within an Advertisementadvertising channel PDU shall
use the local Identity Address, which is provided by the Host.
Section 6.2.1
When an advertiser receives a connection request that contains a device

identity address for the initiator's address field (InitA field), and if that device is
in the Resolving List with a non-zero peer IRK for which the Host has specified
device privacy mode, then the advertising filter policy where the White List is
enabled (see Section 4.3.2) shall determine if the advertiser establishes a
connection.
An advertiser that receives a scan request that contains a resolvable private

address for the scanner’s device address, (ScanA field) shall resolve the
private address (see Section 1.3.2.3). The advertising filter policy where white

listWhite List is enabled (see Section 4.3.2) and the successful resolution of the
scanner’s address shall determine if the advertiser processes the scan
request.
When an advertiser receives a scan request that contains a device identity

address for the scanner's device address (ScanA field), and if that device is in
the Resolving List with a non-zero peer IRK for which the Host has specified
enabled (see Section 4.3.2) shall determine if the advertiser processes the
scan request.
Section 6.2.2
When an advertiser receives a connection request that contains a resolvable

private address for the initiator’s address (InitA field); the Link Layer shall
resolve the private address (see Section 1.3.2.3). The advertising filter policy
(see Section 4.3.2) and the successful resolution of the initiator’s address shall
determine if the advertiser establishes a connection.
When an advertiser receives a connection request that contains a device

identity address for the initiator's address field (InitA field), and if that device is
in the Resolving List with a non-zero peer IRK for which the Host has specified
enabled (see Section 4.3.2) shall determine if the advertiser establishes a
connection.
Section 6.2.3

private address (see Section 1.3.2.3). The advertising filter policy where white
scanner's address shall determine if the advertiser processes the scan
request.
When an advertiser receives a scan request that contains a device identity

address for the scanner's device address (ScanA field), and if that device is in
enabled (see Section 4.3.2) shall determine if the advertiser processes the
scan request.
Section 6.3
A scanner that receives an advertising event that contains a resolvable private

address for the advertiser’s device address, (AdvA field) shall resolve the
private address (see Section 1.3.2.3). The scanner’s filter policy where white
advertiser’s address shall determine if the scanner responds with a scan
request.

When a scanner receives an advertising packet that contains a device identity

address for the advertiser's device address (AdvA field), and if that device is in
device privacy mode, then the scanner's filter policy where the White List is
enabled (see Section 4.3.3) shall determine if the scanner responds with a
scan request.
Section 6.4
An initiator that receives a directed connectable advertising event that contains

a resolvable private address for the initiator’s address, (InitA field) shall resolve
the private address using the Local IRK values (see Section 1.3.2.3). An
initiator that has been instructed by the Host to use Resolvable Private
Addresses shall not respond to directed connectable advertising events that
contain Public or Static addresses for the initiator address, (InitA field).
When an initiator receives a connectable advertising event that contains a

device identity address for the advertiser's device address (AdvA field), and if
that device is in the Resolving List with a non-zero peer IRK for which the Host
has specified device privacy mode, then the initiator's filter policy where the
White List is enabled (see Section 4.3.4) shall determine if the initiator
establishes a connection.
The Link Layer shall use resolvable private addresses for the initiator’s device
address (InitA field) when initiating connection establishment with an
associated device that exists in the Resolving List. The initiator’s device
address (InitA field) in the connect request PDU is generated using the
Resolving List Local IRK and the Resolvable Private Address Generation
Procedure (see Section 1.3.2.2). The Link Layer should not set the InitA field to
the same value of the InitA field in the received ADV_DIRECT_IND PDU.
Section 6.5
Section 6.5 Device Privacy of the Device
A private device shall not use its Identity Address in any packet type used on
the advertising channelsadvertising PDU. The Host may command the
Controller to advertise, scan, or initiate a connection using a Resolvable
Private Address when the resolving list is enabled. If the local or peer IRK in
the resolving list associated with the peer Identity Address is all zeros, the
Controller will use the Identity Address. If the peer IRK in the resolving list
associated with the peer Identity Address is all zeros, the Controller will in
some instances use or accept the Identity Address (see Table 6.1). If the Host
has instructed the Controller to use device privacy mode with a peer Identity
Address, the Controller will accept the peer’s Identity Address. This implies that
the device's network privacy is violated. To maintain a device’s network privacy,

the Host should only populate entries in the Controller’s resolving list with non-
zero IRKs and not instruct the Controller to use device privacy mode.
Resolving Address in
list Advertisement
Loca Send / Accept

Peer
l AdvA InitA CONNECT_REQ
IRK
IRK or SCAN_REQ
Normal Privacy RPA RPA

Set Set Y
resolved resolved
Advertiser uses initiator’s iden-

RPA
tity address instead of a private Set Set Identity N
resolved
address
Initiator uses
RPA
advertiser’s identity address Set Set Identity N
resolved
instead of a private address
Device not in privacy mode and RPA

Zero Set Identity Y
peer hasn’t distributed IRK resolved
Device not in privacy mode and RPA

Set Zero Identity Y
peer doesn’t accept IRK resolved
Address spoofing:
Peer uses address previously
Set / Set / RPA RPA
sent over air. AdvA and N
Zero Zero resolved resolved
InitA are resolved using differ-
ent entries in the resolving list.
Table 24.1: Controller Decision Table for Privacy and Non-Privacy Mode
Note: Device privacy is violated when the Controller sends/accepts a

CONNECT_REQ or SCAN_REQ if the resolving list is populated with all zero
IRKs.
Core Section(s) affected: 5.1.1 Connection Update Procedure
EDITOR’S NOTE: Add “the” to the sentence as shown below

The Instant field of theSection 5.5 shall apply to the

LL_CONNECTION_UPDATE_REQIND PDU.
24.22 E6518 – Grammar and redundant text
Core Section(s) affected: 5.1.8 LE Ping Procedure
EDITOR’S NOTE: Delete the last sentence of the second paragraph
Either the master or the slave Link Layer may initiate this procedure at any time
after entering the Connection State by sending an LL_PING_REQ PDU. The
responding Link Layer responds with the LL_PING_RSP PDU. The initiating
Link Layer may be a master or slave.
24.23 E6577 – Collision in Data length update procedure may

need real time pdu processing
Core Section(s) affected: 5.1.9 Data Length Update Procedure
EDITOR’S NOTE: Add note after paragraph beginning with "If the Link Layer
receives an LL_LENGTH_REQ, or an LL_LENGTH_RSP..."
Note: Because Link Layer PDUs are not required to be processed in real time,
it is possible for the local Controller to have queued but not yet transmitted an
LL_LENGTH_REQ PDU when it receives an LL_LENGTH_REQ PDU from the
peer device. In this situation each device responds as normal; the resulting
collision is harmless.

24.24 E6664 – No need to ban useless runs of the procedure
Core Section(s) affected: 5.1.9 Data Length Update Procedure
EDITOR’S NOTE: Delete the last sentence of the fifth paragraph
If the Link Layer of the master or slave sends the LL_LENGTH_REQ PDU to a
device that does not understand that PDU, then the device should expect an
LL_UNKNOWN_RSP PDU in response. If the Link Layer receives an
LL_UNKNOWN_RSP PDU with the UnknownType field set to
LL_LENGTH_REQ, then it shall not transmit another LL_LENGTH_REQ PDU
to the peer device.
24.25 E6455 – Link Layer Procedure Collisions that involve

connEventCount not clear for Master when
Slave procedure in progress
E6455 4.2 4.1 Vol 6, Part B Link Layer Section 24.26
Core Section(s) affected: 5.3 Procedure Collisions
EDITOR’S NOTE: Replace text as shown below. Affected by E7081.
Since LL Control PDUs are not interpreted in real time, collisions can occur
where both the Link Layer of the master and the Link Layer of the slave either
initiate the sameincompatible procedures out of a limited set of LL Control
Procedures or initiate procedures that update Link Layer parameters at a given
connEventCount. Two procedures are incompatible if they are the same
procedure or if they both involve an instant. In this situation, the following rules
in this section shall be followed:
A device shall not initiate a procedure after responding to a PDU that had
initiated an incompatible procedure until that procedure is complete.
If device initiates a procedure A and, while that procedure is not complete,

receives a PDU from its peer that initiates an incompatible procedure B, then:
• If the peer has already sent at least one PDU as part of procedure A, the
device should immediately exit the Connection State and transition to the
Standby State.[E7081]

• Otherwise, if the device is the master, it shall reject the PDU received from
the slave by issuing an LL_REJECT_EXT_IND (if supported by both
devices) or LL_REJECT_IND (otherwise) PDU. It shall then proceed with
procedure A.
• Otherwise (the device is the slave) it shall proceed to handle the master-
initiated procedure B and take no further action in the slave-initiated
procedure A except processing the rejection from the master.[E7106]
The Host shall be notified that the link has been disconnected with, or the
rejection PDU shall use (as appropriate):
• Error Code 0x23 (LMP Error Transaction Collision / LL Procedure Collision)
if procedures A and B are the same procedure;
• Error Code 0x23 (LMP Error Transaction Collision / LL Procedure Collision)
if procedure A is the Connection Update Procedure and procedure B is the
Connection Parameters Update Procedure;
• Error Code 0x2A (Different Transaction Collision) otherwise.
• If the slave initiates the Connection Parameters Request Procedure (Section
5.1.7) at the same time the master is in the process of initiating or has
already initiated a Connection Parameters Request Procedure or a
Connection Update Procedure (Section 5.1.1), then the master shall reject
the LL_CONNECTION_PARAM_REQ PDU received from the slave by
issuing an LL_REJECT_IND_EXT PDU with Error Code 0x23 (LMP Error
Transaction Collision) and proceed with the master initiated procedure. The
slave shall proceed to handle the master initiated procedure and consider
the slave initiated procedure as complete.
• If the slave initiates the Connection Parameters Request Procedure (Section
5.1.7) at the same time the master is in the process of initiating or has
already initiated a Channel Map Update Procedure, then the master shall
reject the LL_CONNECTION_PARAM_REQ PDU received from the slave
by issuing an LL_REJECT_IND_EXT PDU with Error Code 0x2A (Different
Transaction Collision) and proceed with the master initiated procedure. The
slave shall proceed to handle the master initiated procedure and consider
the slave initiated procedure as complete.
24.26 E7081 – Requirements added by erratum 6455
E7081 4.2 4.1 Vol 6, Part B Link Layer Section 24.25

EDITOR’S NOTE: This erratum changes text added in E6455.
24.27 E7106 – Same procedure collisions should be allowed

sometimes
EDITOR’S NOTE: This erratum changes text added in E6455.

The penultimate sentence in the first paragraph was changed as shown below:
Two procedures are incompatible if they are the same procedure or if they both
involve an instant.
The third bullet was changed as shown below.

• Otherwise (the device is the slave) it shall proceed to handle the master-
initiated procedure B and shall consider take no further action in the slave-
initiated procedure A as complete except processing the rejection from the
master.

consistency
Core Section(s) affected: 5.4 LE Authenticated Payload Timeout
Section 5.4
LE Authenticated Payload Timeout (authenticatedPayloadTO) is a parameter

that defines the maximum amount of time in milliseconds allowed between

receiving packets containing a valid MIC. The Host can change the value of
authenticatedPayloadTO using the
HCI_Write_Authenticated_Payload_Timeout Command ([Vol 2] Part E, Section
7.3.94). The default value for authenticatedPayloadTO is 30 seconds.
24.29 E7034 – Connection Update Procedure
Core Section(s) affected: 5.5 Procedures With Instants
EDITOR’S NOTE: Add text to the second paragraph as shown below1:
The Instant field shall be used to indicate the connEventCount when the
relevant change shall be applied; this is known as the instant for the procedure.
The master should allow a minimum of 6 connection events that the slave will
be listening for before the instant occurs, considering that the slave may only
be listening once every connSlaveLatency events.
24.30 E6469 – Advertiser is not required to check AdvA
4.4.2.4 Connectable Directed Event Type
4.4.2.5 Scannable Undirected Event Type1
4.4.2.6 Non-connectable Undirected Event Type
4.4.3 Scanning State
4.4.4 Initiating State
6.2.1 ADV_IND
1. Note: E6119 (ESR09) moved this text from section 5.1.1 to the new section 5.5.

6.2.2 ADV_DIRECT_IND
6.2.3 ADV_NONCONN_IND and ADV_SCAN_IND
EDITOR’S NOTE: Revise headings and add new paragraphs as shown below.
Section 4.4.2.3
If Link Layer Privacy has been enabled then the requirements in Section 6.2.1
shall also be followed.
Section 4.4.2.4
Section 4.4.2.5
Section 4.4.2.6
Section 4.4.3
If Link Layer Privacy has been enabled then the requirements in Section 6.3
Section 4.4.4
If Link Layer Privacy has been enabled then the requirements in Section 6.4
Section 6.2.1
6.2.1 Connectable Undirected Event TypeADV_IND
The requirements in Section 4.4.2.3 shall also be followed in the Advertising

State and when using connectable undirected events.
Section 6.2.2

6.2.2 Connectable Directed Event TypeADV_DIRECT_IND

State and when using connectable directed events.
Section 6.2.3
6.2.3 Non-connectable Undirected and Scannable Undirected Event

TypesADV_NONCONN_IND and ADV_SCAN_IND

State and when using non-connectable undirected events. The requirements in
Section 4.4.2.5 shall also be followed in the Advertising State and when using
scannable undirected events.
Section 6.3
The requirements in Section 4.4.3.1 shall also be followed in the Scanning

State and when doing passive scanning. The requirements in Section 4.4.3.2
shall also be followed in the Scanning State and when doing active scanning.
Section 6.4
The requirements in Section 4.4.4 shall also be followed in the Initiating State.
24.31 E6984 – How Does Adv Respond to RPA in Connect

Req When There's No IRK and No WL
Core Section(s) affected: 6.2.1 ADV_IND
6.2.2 ADV_DIRECT_IND
6.2.3 ADV_NONCONN_IND and ADV_SCAN_IND
EDITOR’S NOTE: Delete the indicated part from the last sentence in the
paragraphs shown below.
Section 6.2.1

where White List is enabled (see Section 4.3.2) and the successful resolution
of the initiator’s address shall determine if the advertiser establishes a
connection.

private address (see Section 1.3.2.3). The advertising filter policy where White
List is enabled (see Section 4.3.2) and the successful resolution of the
scanner’s address shall determine if the advertiser processes the scan
request.
Section 6.2.2
(see Section 4.3.2) and the successful resolution of the initiator’s address shall
determine if the advertiser establishes a connection.
Section 6.2.3
private address (see Section 1.3.2.3). The advertising filter policy where White
scanner's address shall determine if the advertiser processes the scan
request.
Section 6.3
A scanner that receives an advertising event that contains a resolvable private
address for the advertiser’s device address, (AdvA field) shall resolve the
private address (see Section 1.3.2.3). The scanner’s filter policy where White
advertiser’s address shall determine if the scanner responds with a scan
request.
Section 6.4
An initiator that receives a connectable advertising event that contains a
resolvable private address for the advertiser’s address, (AdvA field) shall
resolve the private address using the Peer IRK values (see Section 1.3.2.3).
The initiator’s filter policy (see Section 4.3.4) and the successful resolution of
the advertiser’s address shall determine if the initiator establishes a
connection.

24.32 E6471 – AdvaA not well defined in SCAN_RSP pdu,

when privacy 1.2 enabled
Core Section(s) affected: 6.3 Privacy in the Scanning State
The Link Layer may use resolvable private addresses or non-resolvable private
addresses for the scanner’s device address, (ScanA field) when entering the
Scanning State.
The scanning event PDU’s ScanA field is generated using the Resolving List’s
Local IRK value and the Resolvable Private Address Generation Procedure
(see Section 1.3.2.2), or the address is provided by the Host.
The advertiser’s device address, (AdvA field) in the SCAN_REQscan request

event PDU shall be the same as the advertiser’s device address, (AdvA field)
received in the advertising event PDU to which the scanner is responding.
24.33 E7003 – LE connection
Core Section(s) affected: 4.5 Connection State
When two devices are in a connection, the two devices act in different roles. A
Link Layer in the Master Role is called a master. A Link Layer in the Slave Role
is called a slave. The master controls the timing of a connection event. A
connection event is a point of synchronization between the master and the
slave. There shall be only one connection, whether or not established, between
two LE device addresses. An initiator shall not send a connection request to an
advertiser it is already connected to.

25 [Vol 6] Part C: SAMPLE DATA
25.1 E5809 – Wrong byte ordering in AES-CCM BR/EDR

Sample data
E5809 4.2 4.1 4.0 Vol 6, Part C Sample Data
Core Section(s) affected: 1.2 Derivation of the MIC and Encrypted Data
EDITOR’S NOTE: Edit text as shown below
All B/X/A/S values below follow the notation of AES-CCM: MLSbyte to

LMSbyte & msbit to lsbit.
[Vol 6] Part C: Sample Data 06 December 2016

26 [Vol 6] Part D: MESSAGE SEQUENCE CHARTS
26.1 E6847 – Erratum 6672: few remains of CONNECT_REQ
E6847 4.2 4.1 4.0 Vol 6, Part D Message Sequence Charts Section 24.9
Initiating a Connection using Undirected

Core Section(s) affected: 5.3 Advertising with Privacy
Initiating a Connection using Directed Adver-

5.4 tising with Privacy
Initiating a Connection That Fails To Estab-

5.5 lish
EDITOR’S NOTE: Change CONNECT_REQ to CONNECT_IND in Figures 5.3,

5.4, and 5.5.
[Vol 6] Part D: Message Sequence Charts 06 December 2016

+RVW$ //$ //% +RVW%
6WHS6HWXS'HYLFH$WR,QLWLDWHDFRQQHFWLRQXVLQJ53$V
6HWXS'HYLFH%WRVHQGDGYHUWVXVLQJ53$V
LE Set Event Mask LE Set Event Mask
Command Complete Command Complete
LE Add Device to Resolving List LE Add Device to Resolving List
LE Set Address Resolution Enable LE Set Address Resolution Enable
LE Create Connection LE Set Advertising Parameters
Command Status Command Complete
LE Set Advertising Enable
Command Complete
ADV_IND
5HVROYH$GY$53$
8VH$GY$53$
*HQHUDWH,QLW$53$
CONNECT_REQIND
LE Enhanced Connection Complete
9HULI\$GY$53$
5HVROYH,QLW$53$
Data Channel PDU
Data Channel PDU
Data Channel PDU
Data Channel PDU
Figure 5.3: Initiating a connection using Undirected Advertising with Privacy

+RVW$ //$ //% +RVW%
6WHS6HWXS'HYLFH$WR,QLWLDWHDFRQQHFWLRQXVLQJ53$V
6HWXS'HYLFH%WRVHQGDGYHUWVXVLQJ53$V
LE Set Event Mask LE Set Event Mask
LE Add Device to Resolving List LE Add Device to Resolving List
LE Set Address Resolution Enable LE Set Address Resolution Enable
LE Create Connection LE Set Advertising Parameters
Command Status Command Complete
LE Set Advertising Enable
Command Complete
ADV_DIRECT_IND
5HVROYH$GY$53$
5HVROYH,QLW$53$
8VH$GY$53$
*HQHUDWH,QLW$53$
CONNECT_REQIND
9HULI\$GY$53$
5HVROYH,QLW$53$
Data Channel PDU
Data Channel PDU
Data Channel PDU
Data Channel PDU
Figure 5.4: Initiating a connection using Directed Advertising with Privacy

+RVW$ //$ //% +RVW%
6WHS'HYLFH%LVVHQGLQJ$GYHUWV'HYLFH$LQLWLDWHVFRQQHFWLRQWR'HYLFH%
LE Create Connection
Command Status
Advert
CONNECT_REQIND
LE Connection Complete
Data Channel PDU
FRQQHFWLRQLQWHUYDOVZLWKQRSDFNHWVIURP'HYLFH%
LE Disconnection Complete
Figure 5.5: Initiating a Connection that fails to establish
26.2 E6563 – Which event does the Controller send when

connection establishment fails?
E6563 4.2 4.1 4.0 Vol 6, Part D Message Sequence Charts
Core Section(s) affected: 5.5 Initiating a Connection That Fails To Establish
EDITOR’S NOTE: Add Section 5.5
5.5 Initiating a Connection That Fails To Establish
This example shows an initiation that fails to establish because Device B (the
advertiser) fails to respond to the Data Channel PDUs sent by Device A.

+RVW$ //$ //% +RVW%
6WHS'HYLFH%LVVHQGLQJ$GYHUWV'HYLFH$LQLWLDWHVFRQQHFWLRQWR'HYLFH%
LE Create Connection
Command Status
Advert
CONNECT_REQ
LE Connection Complete
Data Channel PDU
FRQQHFWLRQLQWHUYDOVZLWKQRSDFNHWVIURP'HYLFH%
LE Disconnection Complete
Figure 5.5: Initiating a Connection that fails to establish
Device A may or may not send data channel PDUs in the 6 connection
intervals before establishment fails. If it does not do so, Device B is unable to
respond.

27 [Vol 6] Part F: DIRECT TEST MODE
27.1 E6793 – Assorted inconsistencies of terminology
E6793 4.2 4.1 4.0 Vol 6, Part F Direct Test Mode
Core Section(s) affected: 3.2 UART Functional Description
3.4 Events
3.4.2 LE_Packet_Report_Event
EDITOR’S NOTE: Revise text to be consistent
Section 3.2 (2nd paragraph)

The Upper Tester sends test commands to the DUT. The DUT shall respond
with a test status event or the packet reporting event.
Section 3.4
There are two types of events sent by the DUT:
1. LE_Test_Status_Event
2. LE_Test_Packet_Report_Event
EThe event packet format is as shown in Figure 3.3. This packet format is used
for both Test Command Status Events and Packet Report Events.
EV (Event): Size: 1 Bit

0 LE_Test_Status_Event
1 LE_Packet_Reporting_Event
Section 3.4.2
The LE_Packet_Report_Event packet format is as shown in Figure 3.5. The
Packet Count parameter indicates the number of received LE Test Packets.
The Packet Count in the Packet Report ending a transmitter test shall be 0.
[Vol 6] Part F: Direct Test Mode 06 December 2016

27.2 E6798 – PRBS15 initialization unclear
E6480 4.2 4.1 Vol 6, Part F Direct Test Mode
Core Section(s) affected: 4.1.5 LE Test Packet Payload Description
EDITOR’S NOTE: Revise paragraph for PRBS15 and add figure
PRBS15:
A 15-bit pseudorandom binary sequence that is used for the interfering signal
and can optionally be used for wanted signal payload content. The PRBS15
sequence repeats itself after the (215 -1 = 32767) bit. The PRBS15 polynomi-
alsequence may be arbitrarily chosen where this is not explicitly specified in the
textgenerated in a fifteen stage shift register whose 14th and 15th stage out-
puts are added in a modulo-two addition stage (See Figure 4.6) and the result
is fed back to the input of the first stage. The sequence begins with the first
ONE of 15 consecutive ONEs (i.e. the shift register is initialized with fifteen
ONEs). The interfering signal is to be continuously modulated with PRBS15
data (i.e. no packet structures or pauses in the signal).
This PRBS15 definition is consistent with ITU T-REC-01 150-199605-I.
SERIES O: SPECIFICATIONS OF MEASURING EQUIPMENT - Equipment for
the measurement of digital and analogue/digital parameters.
+
Figure 4.6: Linear feedback shift register for generation of the PRBS15 sequence
27.3 E7005 – Clarify PRBS9 payload in DTM
Core Section(s) affected: 4.1.5 LE Test Packet Payload Description
EDITOR’S NOTE: Add the following sentence after Figure 4.5 and Figure 4.6:
The same pseudorandom sequence of bits shall be used for each transmission
(i.e. the packet is repeated).

27.4 E6619 – Inconsistencies in terminology and out...
Core Section(s) affected: 4.1.6 LE Test Packet Interval
EDITOR’S NOTE: Revise text in 2nd paragraph and update Figure 4.5
Version 4.2
While in LE direct RX mode, the nominal packet interval of the LE test packets
transmitted from the tester is(i.e. the time from the start of an LE test packet to
the start of the next LE test packet) depends on the LE Test Packet length as
defined in Table 4.2, depending on the LE Test Packet length (i.e. the time from
the start of a LE test packet to the start of the next LE test packet). The tester
packet interval may be extended up to a maximum of 12.5ms upon change of
the dirty transmitter parameter settings and during verification of the EUT PER
reporting functionality.
Version 4.1
transmitted from the tester is 625µs (Ii.e. the time from the start of an LE test
packet to the start of the next LE test packet) depends on the LE Test Packet
length as defined in Table 4.2. The tester packet interval may be extended up
to a maximum of 12.5ms upon change of the dirty transmitter parameter
settings and during verification of the EUT PER reporting functionality.
Figure changes for both Versions 4.2 and 4.1:

See Table 4.2 625μs
(87WUDQVPLWWHVWHUUHFHLYH
From EUT
V3DFNHWLQWHUYDOPV
From Tester
t
7HVWHUWUDQVPLW(87UHFHLYH

27.5 E7029 – Clarification of text
Core Section(s) affected: 4.1.6 LE Test Packet Interval
transmitted from the tester is defined in Table 4.2, depending on the LE Test
Packet length (i.e. the time from the start of a LE test packet to the start of the
next LE test packet). The tester packet interval may be extended up to a
maximum of 12.5ms upon change of the dirty transmitter parameter settings
and during verification of the EUT PER reporting functionality.

28 [Vol 7] Part A: MWS COEXISTENCE LOGICAL

SIGNALING
28.1 E5002 – How do MWS_PATTERN changes relate to MWS

frames?
E5002 4.2 4.1 CSA3 Vol 7, Part A MWS Coexistence Logical Signaling
Core Section(s) affected: 2.1.5 MWS_PATTERN
EDITOR’S NOTE: Edit section 2.1.5 as shown below.
The MWS_PATTERN signal is sent by the MWS device to inform the Bluetooth
Controller which MWS_PATTERN is in use.
MWS_PATTERN changes take effect at the start of the next MWS Frame as
defined by the FRAME_SYNC signal plus the MWS_Frame_Sync_Offset.
Up to three different MWS_PATTERNs can be selected: 0, 1, and 2. The MWS

device may indicate that the MWS_PATTERN has not changed by setting it to
3. The definitions of the patterns isare communicated to the Bluetooth
Controller using the HCI_Set_MWS_PATTERN_Configuration command. If the
pattern is not currently configured, the behaviour is equivalent to setting a
pattern that allows unrestricted activity by the Bluetooth Controller.
The MWS_PATTERN will be retransmitted by the MWS device every pattern

interval.
At the start of each MWS Frame, as defined by the FRAME_SYNC signal plus
the MWS_Frame_Sync_Offset, the most recent MWS_PATTERN value takes
effect as follows.
• If it is 3, the current pattern continues in use.
• If it is the index of the current pattern, then that pattern is restarted.
• Otherwise the indicated pattern is started.
[Vol 7] Part A: MWS Coexistence Logical Signaling 06 December 2016

29 [Vol 7] Part B: WIRELESS COEXISTENCE

INTERFACE 1 (WCI-1) TRANSPORT SPECIFICATION
29.1 E6915 – Transport Layer of WCI-1 and WCI-2 are similar
E6915 4.2 4.1 Vol 7, Part B WCI-1
Vol 7, Part C WCI-2 Section 30.1
Core Section(s) affected: 1 Introduction
[...] Note: the physical layers for WCI-1 and WCI-2 (See [Vol 7] Part C) differ
but the transport layers are identical.
[Vol 7] Part B: Wireless Coexistence Interface 1 (WCI-1) Transport Specification 06 December 2016
30 [Vol 7] Part C: WIRELESS COEXISTENCE

INTERFACE 2 (WCI-2) TRANSPORT SPECIFICATION
30.1 E6915 – Transport Layer of WCI-1 and WCI-2 are similar
E6915 4.2 4.1 Vol 7, Part C WCI-2
Vol 7, Part B WCI-1 Section 29.1
Core Section(s) affected: 1 Introduction
[...] Note: the physical layers for WCI-2 and WCI-1 (see volume 7 part B) differ
but the transport layers are identical.
[Vol 7] Part C: Wireless Coexistence Interface 2 (WCI-2) Transport Specification 06 December 2016
Part II
PART II: GATT-BASED PROFILES &

SERVICES ERRATA

Errata Service Release to the Bluetooth Specification: ESR10 [Part II] page 234
GATT-based Profiles & Services Errata
PROFILE ERRATA INDEX TABLES
By Number:
Versions
Erratum Profile Section affected
E6147 Immediate Alert Service (IAS) 4.1 1.0
E6148 Find Me Profile (FMP) 4.3 1.0
E6237 Device Information Service (DIS) 3.9 1.1
E6377 Current Time Service (CTS) 3.2.1 1.1
E6639 Glucose Profile (GLP) 6.1 1.0
Continuous Glucose Monitoring Profile

E6640 6.1 1.0.1
(CGMP)
E6712 Automation IO Service (AIOS) 3.2.2 1.0
E6822 Internet Protocol Support Profile (IPSP) 9 1.0
E6842 Environmental Sensing Service (ESS) 3.1.2.2 1.0
E6851 Object Transfer Service (OTS) 1.11 1.0
Continuous Glucose Monitoring Service

E6904 3.2.1.3 1.0
(CGMS)
By Profile Name:
Versions
Profile Section Erratum affected
Automation IO Service (AIOS) 3.2.2 E6712 1.0
Continuous Glucose Monitoring Profile

6.1 E6640 1.0.1
(CGMP)
Continuous Glucose Monitoring Service

3.2.1.3 E6904 1.0
(CGMS)
Current Time Service (CTS) 3.2.1 E6377 1.1
Device Information Service (DIS) 3.9 E6237 1.1
Environmental Sensing Service (ESS) 3.1.2.2 E6842 1.0
Find Me Profile (FMP) 4.3 E6148 1.0
06 December 2016
Versions
Glucose Profile (GLP) 6.1 E6639 1.0
Immediate Alert Service (IAS) 4.1 E6147 1.0
Internet Protocol Support Profile (IPSP) 9 E6822 1.0
Object Transfer Service (OTS) 1.11 E6851 1.0
06 December 2016
1 AUTOMATION IO SERVICE (AIOS)
1.1 E6712 – Format and Value of Analog Characteristic
Erratum Adopted version Profile Reference
E6712 1.0 Automation IO Service (AIOS)
Section(s) affected: 3.2.2 Characteristic Descriptors

The Characteristic Presentation Format descriptor format field, exponent, unit, and descriptor
fields can be used to specify the format of the Analog characteristic. The allowed values for the
format field are uint8, uint12, uint16, sint8, sint12, sint16, and SFLOAT, and duint16 (see [1]).
Automation IO Service (AIOS) 06 December 2016

2 CONTINUOUS GLUCOSE MONITORING PROFILE

(CGMP)
2.1 E6640 – CGM Sensor shall use Slave Security Request
E6640 1.0.1 Continuous Glucose Monitoring Profile (CGMP)
Section(s) affected: 6.1 Security Considerations
EDITOR’S NOTE: Delete text as shown below

The CGM Sensor shall use the SM Slave Security Request procedure to inform the Collector of
its security requirements.
Continuous Glucose Monitoring Profile (CGMP) 06 December 2016

3 CONTINUOUS GLUCOSE MONITORING SERVICE

(CGMS)
3.1 E6904 – CGMS Feature Characteristic has a mandatory

CRC field
E6904 1.0 Continuous Glucose Monitoring Service (CGMS)
Section(s) affected: 3.2.1.3 E2E-CRC Field

3.2.1.3 E2E-CRC Field
If the device supports E2E-safety (E2E-CRC Supported bit is set in CGM Features), the CGM Feature
shall be protected by a CRC calculated over all data, see Section 3.11 for details.
This field is mandatory in this characteristic. If the device doesn’t support E2E-safety, the value of the
field shall be set to 0xFFFF.
If E2E-safety is supported and an error occurs, the error codes as defined in Section 1.8 shall be used.
Continuous Glucose Monitoring Service (CGMS) 06 December 2016

4 CURRENT TIME SERVICE (CTS)
4.1 E6377 – Need to clarify that disconnecting the link

causes the alerting to end
E6377 1.1 Current Time Service (CTS)
Section(s) affected: 3.2.1 Characteristic Behavior - Notification
3.1.2 Characteristic Behavior – Notification

This characteristic can be configured for notification using the GATT Write
Characteristic Descriptors sub-procedure on the Client Characteristic Configuration
descriptor. When configured for notification, this characteristic can be notified while in a
connection.
When the local time in the server is adjusted and the device has a connection to a
client device, theA server device shall notify this characteristic to the client device
depending on the value of Client Characteristic Configuration descriptor when the time
of the server device is adjusted. The events that can cause the local time in the server
device to change are user interaction (setting time via UI), time zone change, DST
offset change, or reference time change. These events are not exclusive.
Current Time Service (CTS) 06 December 2016

5 DEVICE INFORMATION SERVICE (DIS)
5.1 E6237 – The PnP_ID characteristic incorrectly claims to

be unique for each device
E6237 1.1 Device Information Service (DIS)
Section(s) affected: 3.9 PnP ID
3.9 PnP ID
The PnP_ID characteristic is a set of values that shall beis used to create a device ID
value that is unique for this device. Included in the characteristic are a Vendor ID source
field, a Vendor ID field, a Product ID field, and a Product Version field. These values are
used to identify all devices of a given type/model/version using numbers. Included in the
characteristic are a Vendor ID source field, a Vendor ID field, a Product ID field, and a
Product Version field.
Device Information Service (DIS) 06 December 2016

6 ENVIRONMENTAL SENSING SERVICE (ESS)
6.1 E6842 – Units field part of the Operand?
E6842 1.0 Environmental Sensing Service (ESS)
Section(s) affected: 3.1.2.2 ES Trigger Setting Descriptor

The conditions that can be set are enumerated in Table 3.11. For example, for Condition 0x01 (use a
fixed time interval between transmissions), the Operand is a UINT24 number, representing the requested
time interval value in units of seconds.
Environmental Sensing Service (ESS) 06 December 2016

7 FIND ME PROFILE (FMP)
7.1 E6148 – Need to clarify that disconnecting the link

causes the alerting to end
E6148 1.0 Find Me Profile (FMP)
Section(s) affected: 4.3 Alerting Peer Device

4.3 Alerting Peer Device
When the Find Me Locator device wishes to cause an alert on the Find Me Target
device, it shall write the specific Alert Level in the Alert Level characteristic. If a link
does not exist then the Find Me Locator device shall connect to the Find Me Target
device as defined in Section 5. After terminating the alert, by writing the value “No Alert”
to the Alert Level characteristic, Tthe Find Me Locator device should disconnect the link
after alerting the device to save battery power.
Find Me Profile (FMP) 06 December 2016

8 GLUCOSE PROFILE (GLP)
8.1 E6639 – Slave device should not send Security Request
E6639 1.0 Glucose Profile (GLP)
Section(s) affected: 6.1 Glucose Sensor Security Considerations
EDITOR’S NOTE: Delete text as shown below

6.1 Glucose Sensor Security Considerations
All supported characteristics specified by the Glucose Service shall be set to Security
Mode 1 and either Security Level 2 or 3.
The Glucose Sensor shall bond with the Collector.
The Glucose Sensor shall use the SM Slave Security Request procedure to inform the
Collector of its security requirements.
Glucose Profile (GLP) 06 December 2016

9 IMMEDIATE ALERT SERVICE (IAS)
9.1 E6147 – Non IEEE language in the requirement for ending

the alarm
E6147 1.0 Immediate Alert Service (IAS)
Section(s) affected: 4.1 Writing Alert Level Behavior

This alert shall continues until one of following conditions occurs:
x An implementation specific timeout.
x User interaction on this device.
x A new alert level is written.
x The physical link is disconnected.
Immediate Alert Service (IAS) 06 December 2016

10 INTERNET PROTOCOL SUPPORT PROFILE (IPSP)
10.1 E6822 – Reference RFC 7668
E6822 1.0 Internet Protocol Support Profile (IPSP)
Section(s) affected: 9 References

[3] IETF RFC 7668, IPv6 over BLUETOOTH(R) Low EnergyTransmission of IPv6 packets over
Bluetooth Low Energy (informative)
https://tools.ietf.org/rfc/rfc7668.txt https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/
Internet Protocol Support Profile (IPSP) 06 December 2016

11 OBJECT TRANSFER SERVICE (OTS)
11.1 E6851 – Clarify bit order in relation to octet order
E6851 1.0 Object Transfer Service (OTS)
Section(s) affected: 1.11 Byte Transmission Order

1.11 Byte Transmission Order
All characteristics used with this service shall be transmitted with the least significant octet first (i.e., little
endian). The least significant octet is identified in this specification as well as in the characteristic
definitions in [3].
The least significant bit (LSB) of each characteristic value corresponds to bit 0.
Within a field, the least significant octet (LSO) of the field value corresponds to the octet containing the
lowest numbered bit.
Object Transfer Service (OTS) 06 December 2016

Part III
PART III: TRADITIONAL PROFILES

ERRATA

Errata Service Release to the Bluetooth Specification: ESR10 [Part III] page 248
Traditional Profiles Errata
PROFILE ERRATA INDEX TABLES
By Number:
Versions
E340 IrDA Interoperability (IrDA) 3 1.1
E909 Basic Printing Profile (BPP) 11.9.1 1.0
E2644 Human Interface Device Profile (HID) 6.5.1.4 1.0
E3525 Health Device Profile (HDP) 5.2.9.1.1 1.1
E3669 Human Interface Device Profile (HID) 7.10 1.0
E4231 Generic Object Exchange Profile (GOEP) 5.4.2 1.1
E4790 Human Interface Device Profile Service (HIDS) 2.2 1.0
E4792 Human Interface Device Profile Service (HIDS) 2.5.3.2 1.0
E4804 Human Interface Device Profile Service (HIDS) 2.6.3.1 1.0
E4805 Human Interface Device Profile Service (HIDS) 2.7 1.0
E4806 Human Interface Device Profile Service (HIDS) 2.9.3 1.0
E4807 Human Interface Device Profile Service (HIDS) 2.11.2 1.0
E5128 Dial-Up Networking Profile (DUN) 5 1.2
E6820 Phone Book Access Profile (PBAP) 9 1.2.1
E6013 Audio/Video Remote Control Profile (AVRCP) 4.5 1.6.1
E6209 Audio/Video Remote Control Profile (AVRCP) 8 1.6.1
E6273 Audio/Video Remote Control Profile (AVRCP) 6.7.1 1.6.1
E6297 Health Device Profile (HDP) 2.1 1.1
E6418 Message Access Profile (MAP) 5.8.2 1.0
E6473 Hands-Free Profile (HFP) 4.3 1.7
E6492 Phone Book Access Profile (PBAP) 6.2.1 1.2.1
E6494 Hands-Free Profile (HFP) 4.34.1 1.7
E6503 Phone Book Access Profile (PBAP) 5.1.4.3 1.2.1
06 December 2016
Versions
E6800 Human Interface Device Profile (HID) 5.1.13 1.1
E6809 Calendar, Tasks and Notes Profile (CTN) 2.1 1.0
E6819 Phone Book Access Profile (PBAP) 6.4 1.2.1
E6877 Phone Book Access Profile (PBAP) 6.4 1.2.1
E6932 Message Access Profile (MAP) 5.1 1.2.2
E6933 Message Access Profile (MAP) 5.8 1.2.2
E6937 Message Access Profile (MAP) 0 1.2.2
E6942 Message Access Profile (MAP) 6.3.1 1.2.2
E6945 Calendar, Tasks and Notes Profile (CTN) 3.3.3 1.0
E6957 Calendar, Tasks and Notes Profile (CTN) 4.4 1.0
E6958 Calendar, Tasks and Notes Profile (CTN) 5.5.4 1.0
E7059 Human Interface Device Profile (HID) C.1 1.1
By Profile Name:
Versions
4.5 E6013 1.6.1
8 E6209 1.6.1
Audio/Video Remote Control Profile (AVRCP) 6.7.1 E6273 1.6.1
6.4.1 E6557 1.6.1
4.1.8 E6784 1.6.1
06 December 2016
Versions
Basic Printing Profile (BPP) 11.9.1 E909 1.0
2.1 E6809 1.0
3.3.3 E6945 1.0

Calendar, Tasks and Notes Profile (CTN)
4.4 E6957 1.0
5.5.4 E6958 1.0
Dial-Up Networking Profile (DUN) 5 E5128 1.2
Generic Object Exchange Profile (GOEP) 5.4.2 E4231 1.1
5.2.9.1.1 E3525 1.1

Health Device Profile (HDP)
2.1 E6297 1.1
4.3 E6473 1.7
4.34.1 E6494 1.7

Hands-Free Profile (HFP)
4.11.3 E6544 1.7
4.10.2 E6628 1.7
6.5.1.4 E2644 1.0
7.10 E3669 1.0

Human Interface Device Profile (HID)
5.1.13 E6800 1.1
C.1 E7059 1.1
2.2 E4790 1.0
2.5.3.2 E4792 1.0
2.6.3.1 E4804 1.0

Human Interface Device Profile Service (HIDS)
2.7 E4805 1.0
2.9.3 E4806 1.0
2.11.2 E4807 1.0
IrDA Interoperability (IRDA) 3 E340 1.1
06 December 2016
Versions
5.8.2 E6418 1.0
5.8.2 E6768 1.1
5.8.2 E6769 1.2
Message Access Profile (MAP) 5.1 E6932 1.2.2
5.8 E6933 1.2.2
0 E6937 1.2.2
6.3.1 E6942 1.2.2
9 E6820 1.2.1
5.1.4.3 E6503 1.2.1
Phone Book Access Profile (PBAP) 6.4 E6819 1.2.1
6.4 E6877 1.2.1
6.2.1 E6492 1.2.1
06 December 2016
1 AUDIO/VIDEO REMOTE CONTROL PROFILE

(AVRCP)
1.1 E6784 – Description for the image handle need to be

reviewed
E6784 1.6.1 Audio/Video Remote Control Profile (AVRCP)
Section(s) affected: 4.1.8 OBEX Connection Release

4.1.8 OBEX Connection Release
AVRCP does not place a restriction on when the OBEX L2CAP channel is closed.
However, when the OBEX level connection is closed, the BIP imaging handles retrieved
during that OBEX connection will no longer be valid.
It is strongly recommended that the underlying L2CAP channel is not disconnected
when the reason the CT disconnects OBEX is solely to release the image handles.
Keeping the underlying L2CAP channel in place during the OBEX disconnect/connect
cycle will reduce the latency and the overhead involved in the UIDs changed procedure.
Note the BIP image handle may be reused by the TG in subsequent OBEX connections,
but the CT should not assume it will be the case. The CT shall reacquire the image
handle for any new OBEX connection.
1.2 E6013 – Implementation of Errata 5376 not fully correct
Section(s) affected: 4.5 AVRCP specific commands
Audio/Video Remote Control Profile (AVRCP) 06 December 2016

EDITOR’S NOTE: In Table 4.5, change C17 to C14 as shown below

0x40 RequestContinuingResponse AV/C CONTROL TMTC 6.8.1
C17
C14 4
7 [E5
[E5 376
376 ][E6
] 013
]
0x41 AbortContinuingResponse AV/C CONTROL TMTC 6.8.2
C17
C14 4
7 [E5
[E5 376
376 ][E6
] 013
]
1.3 E6557 – The range of CapabilityCount parameter is

incorrect
Section(s) affected: 6.4.1 GetCapabilities
EDITOR’S NOTE: Change 2 to 0 as shown below

GetCapabilities Response format for EVENTS_SUPPORTED:
Parameters Size (octets) Description Allowed Values
CapabilityID 1 Specific capability requested EVENTS_SUPPORTED
CapabilityCount (n) 1 Specifies the number of events 02-255

supported
Capability 2…n List of EventIDs see Table 6.9Table 6.9
Table 6.8: GetCapabilities Response for EVENTS_SUPPORTED

1.4 E6273 – Statements present for play position value when

retrieved using different mechanisms for no
track selected case are contradictory
Section(s) affected: 6.7.1 GetPlayStatus
EDITOR’S NOTE: Add text below Table 6.29 as shown below

Note: If no track is currently selected, the TG should return 0x00000000 for both
SongLength and SongPosition.
1.5 E6209 – Alignment issue in SDP table for Protocol

descriptor list for
Section(s) affected: 8 Service Discovery Interoperability

Requirements

EDITOR’S NOTE: In Table 8.2, format the rows to alternate as white and grey,
edit text, and align text as shown below
Item Definition Type Value AttrID Status Default
Protocol #0 UUID L2CAP M

Parameter #0 for PSM Uint 16 PSM=AVCTP M
Protocol #0
Protocol #1 UUID AVCTP M
Parameter #0 for Version Uint 16 0x0104*1 M
Protocol #1
Additional Protocol C1
Descriptor List
Protocol Descriptor C1
List #0
Protocol #0 UUID L2CAP C1
Parameter #0 for PSM Uint 16 PSM= C1
AVCTP_Browsing
Protocol #0
Protocol #1 UUID AVCTP C1
Parameter #0 for Version Uint 16 0x0104*1 C1
Protocol #1
Protocol Descriptor C2
List #1
Protocol #0 UUID L2CAP C2
Parameter #0 for PSM Uint 16 Dynamically C2
Protocol #0 assigned L2CAP
PSM on which the
Cover Art service is
available
Protocol #1 UUID OBEX C2
Bluetooth Profile M
Descriptor List
Profile #0 UUID A/V Remote M
Control
Parameter #0 for Version Uint 16 0x0106*2 M
Profile #0

2 BASIC PRINTING PROFILE (BPP)
2.1 E909 – SOAPACTION HTTP header missing in Get Printer

Attribute Response
E909 1.0 Basic Printing Profile (BPP)
Section(s) affected: 11.9.1 SOAP Stream Requirements
EDITOR’S NOTE: Revise the table as shown below
HTTP Header Requirement Description
CONTENT-LENGTH Required Contains the length of the SOAP body, in bytes.
CONTENT-TYPE Required Contains ‘text/xml; charset=”utf-8”’.
SOAPACTION Required for Contains the service type, hash-mark, and name of
requests only action to be invoked; all enclosed in double quotes as
shown in the examples associated with each SOAP
encoded operation.
CONTENT-LANGUAGE Optional Contains user’s preferred language (per RFC 1766

[38]), which the printer may use in some manner in
communications with the user.
Table 45: HTTP Headers in SOAP Messages
Basic Printing Profile (BPP) 06 December 2016

3 CALENDAR, TASKS AND NOTES PROFILE (CTN)
3.1 E6809 – Typo in label of CTN Server in Figure 2.1. Should

be CSE.
E6809 1.0 Calendar, Tasks and Notes Profile (CTN)
Section(s) affected: 2.1 Protocol Stack
EDITOR’S NOTE: Replace CCS with CSE in the figure as shown below
Figure 2.1: Protocol model for transport of CTN data objects
3.2 E6945 – Invalid reference in CTN-Event-Report(cal_type

Attribute)
Section(s) affected: 3.3.3 CTN-Event-Report Object (x-bt/CTN-Even-

tReport)
Calendar, Tasks and Notes Profile (CTN) 06 December 2016

EDITOR’S NOTE: Revise the text as shown below

x "handle" is the related bCalendar object handle in hexadecimal representation (see
Section 3.2.3)
x "cal_type" is the type of the bCalendar object (see “cal_type” attribute in CTN-listing
object, Section 3.3.2)
x "summary " is the summary or subject of the bCalendar object (see “summary” attribute
in CTN-listing object, Section 3.3.2)
3.3 E6957 – Typo in Figure 4.3. Written PAS client instead of

CAS Client
Section(s) affected: 4.4 CTN Browsing Feature
EDITOR’S NOTE: Change PAS to CAS as shown below

CCE device CSE device
CNS PCAS CAS CNS

Server Client Server Client
Ongoing CTN Access Service connection
GetCTNListing_Req(...) retrieve list of CTN

entries from folder of
GetCTNListing_Resp(...)
interest
3.4 E6958 – Unclear description about application

parameters
Section(s) affected: 5.5.4 Application Parameters


For bCalendar entries whose confirmpStatus (see section 3.3.2) has been changed the
CSE device shall send a confirmation to the originator of the entry. The implementation
of this confirmation is out-of-scope for CTN. If the confirmation transmission is not
possible for any reason the CSE shall send a "SendingFailure" notification event to the
CCE.

4 DIAL-UP NETWORKING PROFILE (DUN)
4.1 E5128 – Interoperability requirements table are

unreferenced and confusing
E5128 1.2 Dial-Up Networking Profile (DUN)
Section(s) affected: 5 Serial Port Profile Interoperability Require-

ments
EDITOR’S NOTE: Delete Table 5.1.
6'3,QWHURSHUDELOLW\5HTXLUHPHQWV
,WHP 'HILQLWLRQ 7\SH 9DOXH 6WDWXV 'HIDXOW

6HUYLFH&ODVV,'/LVW 0
6HUYLFH&ODVV 88,' 'LDO8S 0

1HWZRUNLQJ
6HUYLFH&ODVV 88,' *HQHULF 2

1HWZRUNLQJ
3URWRFRO'HVFULSWRU/LVW 0
3URWRFRO 88,' /&$3 0
3URWRFRO 88,' 5)&200 0
3DUDPHWHUIRU3URWRFRO 6HUYHU 8,QW 0

&KDQQHO
6HUYLFH1DPH 'LVSOD\DEOH 6WULQJ 6HUYLFH 2 µ'LDO8S

7H[WQDPH SURYLGHU QHWZRUNLQJ¶
GHILQHG
(VFDSH6HTXHQFH 6WULQJ 1RQ 2 )DOVH

ORFDOL]DEOH
%OXHWRRWK3URILOH 0
'HVFULSWRU/LVW
3URILOH 88,' 'LDO8S 0

1HWZRUNLQJ
3DUDPHWHUIRU3URILOH 9HUVLRQ 8,QW [ 0
Table 5.1: Interoperability Requirements
Dial-up networking Profile (DUN) 06 December 2016

7DEOH7DEOHOLVWVDOOHQWULHVLQWKH6'3GDWDEDVHRIWKH*:GHILQHGE\WKLV
SURILOH7KHµ6WDWXV¶FROXPQLQGLFDWHVZKHWKHUWKHSUHVHQFHRIWKLVILHOGLVPDQGDWRU\RU
RSWLRQDO
7KHFRGHVDVVLJQHGWRWKHPQHPRQLFVXVHGLQWKHµ9DOXH¶FROXPQDQGWKHFRGHV
DVVLJQHGWRWKHDWWULEXWHLGHQWLILHUVFDQEHIRXQGLQWKH%OXHWRRWK$VVLJQHG1XPEHUV
VHFWLRQ
,WHP 'HILQLWLRQ 7\SH 9DOXH 6WDWXV 'HIDXOW

6HUYLFH&ODVV,'/LVW
6HUYLFH&ODVV 88,' 'LDO8S 0
1HWZRUNLQJ
6HUYLFH&ODVV 88,' *HQHULF 2
1HWZRUNLQJ
3URWRFRO'HVFULSWRU/LVW 0
3URWRFRO 88,' /&$3 0
3URWRFRO 88,' 5)&200 0
3DUDPHWHUIRU3URWRFRO 6HUYHU 8,QW 0
&KDQQHO
6HUYLFH1DPH 'LVSOD\DEOH 6WULQJ 6HUYLFH 2 µ'LDO8S
7H[WQDPH SURYLGHU QHWZRUNLQJ¶
GHILQHG
$XGLR)HHGEDFN6XSSRUW %RROHDQ 7UXH)DOVH 2 )DOVH
%OXHWRRWK3URILOH 0
'HVFULSWRU/LVW
3URILOH 88,' 'LDO8S 0
1HWZRUNLQJ
3DUDPHWHUIRU3URILOH 9HUVLRQ 8,QW [ 0
Table 5.12: Service Database Entries
Dial-up networking Profile (DUN) 06 December 2016

5 GENERIC OBJECT EXCHANGE PROFILE (GOEP)
5.1 E4231 – "subject blank"
E4231 1.1 Generic Object Exchange Profile (GOEP)
Section(s) affected: 5.4.2 OBEX Session with Authentication
EDITOR’S NOTE: Revise Table 5.6 as shown below. This was trivially
accepted since GOEP 2.0 already fixed this.
Field/
Name Value Status Explanation
Header
Field Response code for CON- Varies M 0x&1 for Unauthorized,

NECT request because OBEX authentication
is used.
Field Connect Response Packet Varies M
Length -
Field OBEX Version Number Varies M

-
Field Flags Varies M
-
Field Max OBEX Packet Length Varies M
-
Header Authenticate Challenge Varies M
&DUULHVWKHGLJHVWFKDOOHQJHVWULQJ
Table 5.6: Fields and Headers in First CONNECT Response when Authenticating
The second CONNECT request has the following fields and headers in this
order:
Generic Object Exchange Profile (GOEP) 06 December 2016

6 HEALTH DEVICE PROFILE (HDP)
6.1 E6297 – Incorrect Word - Figure 2.1
E6297 1.1 Health Device Profile (HDP)
Section(s) affected: 2.1 Protocol Stack
EDITOR’S NOTE: In Figure 2.1 on the right side, change “IEEE...Protocol

(Agent)” to “IEEE...Protocol (Manager)” as shown below
2.1 Protocol Stack
Figure 2.1 shows the protocols and entities used in this profile.
Application (Source) Application (Sink)
Device Data Specialization Device Data Specialization

IEEE 11073 Data Exchange IEEE 11073 Data Exchange
Protocol (Agent) Protocol (ManagerAgent)
MCAP SDP SDP MCAP
L2CAP L2CAP
Source Side Sink Side
Figure 2.1: Protocol Model
6.2 E3525 – Echo Test Function requirements for Sources

and Sinks need to be clarified
E3525 1.1 Health Device Profile (HDP)
Section(s) affected: 5.2.9.1.1 Echo Test Function (MDEP ID 0x00)
Health Device Profile (HDP) 06 December 2016


5.2.9.1.1 Echo Test Function (MDEP ID 0x00)
MDEP ID 0x00 is reserved for debugging and interoperability testing, and is
implemented as an Echo Test Function. The general use of this function is that it allows
the Initiator to send any L2CAP data packet it wants, and the Acceptor repeats it back.
x A Source can either initiate or accept the creation of Control and Data Channels or
support both. The support of the Echo Test Function is based on the supported
feature of the Source.
x Sinks shall be able to initiate or accept the Echo Test Function.
x Acceptance of the Echo Test Function shall be supported by all Sources and Sinks.
The Echo Test Function Procedure is defined as follows:
Health Device Profile (HDP) 06 December 2016

7 HANDS-FREE PROFILE (HFP)
7.1 E6473 – Typo Errors in HFP1.7 Specification
E6473 1.7 Hands-Free Profile (HFP)
Section(s) affected: 4.3 Service Level Connection Release
4.12 Audio Connection Release
4.13.1 Answer Incoming Call from the HF - In-Band

Ringing
4.13.4 Change the In-Band Ring Tone Setting
4.17 Audio Connection Transfer towards the AG
4.18 Place a Call with the Phone Number Supplied

by the HF
4.19 Memory Dialing from the HF
4.20 Last Number Re-Dial from the HF
4.21 Call Waiting Notification Activation
4.22 Three-Way Call Handling
4.23 Calling Line Identification (CLI) Notification
4.24 The HF Requests Turning off the AG's EC and

NR
4.25 Voice Recognition Activation
4.26 Attach a Phone Number to a Voice Tag
4.28.1 Audio Volume Control
4.28.2 Volume Level Synchronization
EDITOR’S NOTE: Change “Apreconditions a precondition” to “As a

precondition” as shown below
Section 4.3
Aspreconditions a precondition for this procedure, an ongoing Service Level Connection
between the AG and the HF shall exist.
Section 4.12
Aspreconditions a precondition for this procedure, an ongoing Audio Connection between the
AG and the HF shall exist.
Hands-Free Profile (HFP) 06 December 2016

Section 4.13.1
This case is described in Figure 4.24 below and implies, aspreconditions a precondition, that an
ongoing Service Level Connection between the AG and the HF shall exist. If this connection
does not exist, the AG shall autonomously establish the Service Level Connection using the
proper procedure as described in Section 4.2.
Section 4.13.4
between the AG and the HF shall exist. If this connection does not exist, the AG shall
autonomously establish the Service Level Connection using the proper procedure as described
in Section 4.2.
Section 4.17
Aspreconditions a precondition for this procedure, an ongoing call process shall exist in the AG.
The audio paths of the ongoing call shall be available in the HF via an Audio Connection
established between the AG and the HF.
Section 4.18
between the AG and the HF shall exist. If this connection does not exist, the HF shall
in Section 4.2.
Section 4.19
in Section 4.2.
Section 4.20
in Section 4.2.
Section 4.21
in Section 4.2.
Section 4.22
between the AG and the HF shall exist. If this connection does not exist, the initiator of the
procedure shall autonomously establish the Service Level Connection using the proper
procedure as described in Section 4.2.

Section 4.23
in Section 4.2.
Section 4.24
in Section 4.2.
Section 4.25
Aspreconditions a precondition for these procedures, an ongoing Service Level Connection
between the AG and the HF shall exist. If this connection does not exist, the initiator of the
procedure shall autonomously establish the Service Level Connection using the proper
procedure as described in Section 4.2.
Section 4.26
in Section 4.2.
Section 4.28.1
between the AG and the HF shall exist. If this connection does not exist, the AG shall
in Section 4.2.
Section 4.28.2
in Section 4.2.
7.2 E6628 – Typo in Section Header
Section(s) affected: 4.10.2 Transfer of Callheld Status

EDITOR’S NOTE: Revise heading as shown below
4.10.2 Transfer of Callsetupheld Status

Upon the change in AG's callsetup status, the AG shall execute this procedure to advise the HF
of the current callsetup status changes. The values for the callsetup indicator are:
7.3 E6544 – Codec Negotiation for
Section(s) affected: 4.11.3 Codec Connection Setup
EDITOR’S NOTE: Remove text as shown below

After the Synchronous Connection has been established, the Codec Connection is established.
The selection of codec with the +BCS command is in effect for this connection as well as
subsequent Codec Connections. The Codec selection procedure needs to be redone only if a
different codec is to be used for a new Synchronous Connection.
7.4 E6494 – Bluetooth Retrieve Supported Features reserved

bits defined differently in table and in text below
it.
Section(s) affected: 4.34.1 Bluetooth Defined AT Capabilities

12-31 Reserved for future definition
The reserved bits (112-31) shall be initialized to Zero.

AT+NREC (Noise Reduction and Echo Canceling)
Syntax: AT+NREC=<nrec>

8 HUMAN INTERFACE DEVICE PROFILE (HID)
8.1 E6800 – HID Host may support Inquiry scan
E6800 1.1 Human Interface Device Profile (HID)
Section(s) affected: 5.1.13 Link Control Compatibility Requirements
EDITOR’S NOTE: Replace X with O in Table 5.2 as shown below
Capability Support in Bluetooth HID Host Support in Bluetooth HID device

Inquiry M O
Inquiry scan OX M
Paging M C2
Extended Inquiry Response O O
Page scan Type R0 C1 C3
Type R1 C1 C3
Type R2 C1 C3
Table 5.2: Link Control Compatibility
8.2 E2644 – Incorrect statements regarding Sniff Mode
Section(s) affected: 6.5.1.4 Use of SNIFF Mode
Human Interface Device Profile (HID) 06 December 2016


Note: Due to the Bluetooth clock accuracy specifications (+/- 20 ppm), a worst-case
clock accuracy situation could potentially require a maximum beacon interval of less
than 250 ms in order for devices in Park, Sniff, or Hold modes to stay synchronized. The
best link manager implementations will widen the receive window as the beacon interval
is increased, but at the expense of additional power consumption. If loss of
synchronization occurs, link loss will occur and the link must be re-established by the
normal paging and connection establishment procedures.
Note: In Sniff Mode, the Bluetooth Core Specification allows use of a low power oscillator
for which clock drift may be as high as +/-250ppm and the jitter may be as high as
+/10ȝs. In the worst case, this can result in a +/-500ppm clock skew between two devices
during Sniff Mode and +/-20ȝs jitter. The Bluetooth Core Specification only requires that
the receive window be a minimum of 20ȝs in duration (+/10ȝs), but does allow it to be
widened to compensate for drift and jitter. Since the jitter may be as high as +/-20ȝs in
Sniff Mode, which results in a relative uncertainty of 40ȝs that is already larger than the
minimum receive window, it is necessary for implementations to widen the receive
window to ensure that synchronization is maintained in Sniff Mode in conditions where
the worst case drift and jitter may be encountered, regardless of the Sniff interval that
may be in use.
8.3 E3669 – Inconsistency on HID Device Release Number

attribute between Table 18, 19 and Table 21
Section(s) affected: 7.10 HID Service Class Definitions
7.11.15 SDP Entry for HID Service
7.14 Example SDP Transactions
Section 7.10
HIDProfileVersion
HIDDeviceReleaseNumber (not recommended for new designs; see Section 7.11.1)
HIDParserVersion
HIDDeviceSubclass
HIDCountryCode
HIDVirtualCable
HIDReconnectInitiate
HIDSDPDisable
HIDBatteryPower
HIDRemoteWake
HIDSupervisionTimeout
HIDNormallyConnectable
HIDBootDevice

1
Attribute ID Type & Size Required Section
HIDBatteryPower 0x0209 Bool8 O 7.11.9
HIDBootDevice 0x020E Bool8 M 7.11.11
HIDCountryCode 0x0203 uint8 M 7.11.3
HIDDescriptorList 0x0206 Sequence M 7.11.6
HIDDeviceReleaseNumber 0x0200 uint16 O2 7.11.1
HIDDeviceSubclass 0x0202 uint8 M 7.11.2
HIDLANGIDBaseList 0x0207 Sequence M 7.11.7
HIDNormallyConnectable 0x020D Bool 8 O 7.11.13
HIDParserVersion 0x020B Uint16 M 7.11.14
HIDProfileVersion 0x0201 uint16 M 0
HIDReconnectInitiate 0x0205 Bool8 M 7.11.5
HIDRemoteWake 0x020A Bool8 O 7.11.10
HIDSDPDisable 0x0208 Bool8 O 7.11.8
HIDSupervisionTimeout 0x020C Uint16 O 7.11.12
HIDVirtualCable 0x0204 Bool8 M 7.11.4
1
Notation: uint = Unsigned Integer, 8 = 8-bit, 16 = 16-bit, Bool = Boolean, Array = array
of specified data type.
2 HIDDeviceReleaseNumber is not recommended for new designs; see Section
7.11.1.
Table 18: SDP Attribute Summary (Alphabetical Order)
1
Attribute ID Type & Size Required Section
HIDDeviceReleaseNumber 0x0200 uint16 O2 7.11.1
HIDParserVersion 0x0201 uint16 M 0
HIDDeviceSubclass 0x0202 uint8 M 7.11.2
HIDCountryCode 0x0203 uint8 M 7.11.3
HIDVirtualCable 0x0204 Bool 8 M 7.11.4
HIDReconnectInitiate 0x0205 Bool 8 M 7.11.5
HIDDescriptorList 0x0206 Sequence M 7.11.6
HIDLANGIDBaseList 0x0207 Sequence M 7.11.7
HIDSDPDisable 0x0208 Bool 8 O 7.11.8
HIDBatteryPower 0x0209 Bool 8 O 7.11.9
HIDRemoteWake 0x020A Bool 8 O 7.11.10
HIDProfileVersion 0x020B Uint16 M 7.11.14
HIDSupervisionTimeout 0x020C Uint16 O 7.11.12
HIDNormallyConnectable 0x020D Bool 8 O 7.11.13
HIDBootDevice 0x020E Bool 8 M 7.11.11
0x020F – Reserved HID
0x03FF Attributes
0x0400 – Available for
0xFFFF HID Language
Strings
1
Notation: uint = Unsigned Integer, 8 = 8-bit, 16 = 16-bit, Bool = Boolean.
2 HIDDeviceReleaseNumber is not recommended for new designs; see Section 7.11.1.
Table 19: SDP Attribute Summary (Numeric Order)

Section 7.11.15
7.11.15 SDP Entry for HID Service
6 7
Item Definition Type Value Status Attribute
ID
Profile 0 UUID HID M
Parameter for Profile 0 Version uint16 0x0100, Note 4 M
LanguageBase Data Define Primary M 0x0006
AttributeIDList Element/ (and alternate)
Sequence language
HIDDeviceRelease 7.11.1 uint16 0x0100, Note 4 M 0x0200
Number
HIDParserVersion 0 uint16 0x0111, Note 5 M 0x0201
HIDDeviceSubclass 7.11.2 uint8 See Bluetooth M 0x0202
Defined
Numbers
Document [8]
Table 21: SDP Entry for HID Service
Section 7.14
Attribute ID Attribute Value Description

ProviderName 0x25 0x0B text string, 11 bytes
0x0100 + 0x0002 “XYZ Company”
HIDDeviceReleaseNumber 0x09 0x0100 Uint16, Version of HID Device. See
0x0200 Section 7.11.1.
HIDParserVersion 0x09 0x0111 Uint16, Version of core USB HID
0x0201 Specification [4] to which the device was
designed. See Section 0.
Note: HIDDeviceReleaseNumber is not recommended for new designs; see Section
7.11.1.
Table 22: Example Service Record for HID Mouse
8.4 E7059 – [Typo] Type in
Section(s) affected: C.1 Bluetooth HID Pairing Examples

x Discovery: User places the Bluetooth HID Host in a mode in which it discovers and
reports new Bluetooth HID devices. This could be invoked by resetting the Bluetooth
HID Host. Alternatively, vendor-supplied software supplied in the box may initiate
this mode, or the Bluetooth HID Host may simply perform a periodic device
discovery by default. The Bluetooth HID Hostf may also have a button which can be
used to cause it to initiate an Inquiry,

8.5 E4790 – Boot Mouse Input Report characteristic

properties incorrect
E4790 1.0 Human Interface Device Profile Service (HIDS)
Section(s) affected: 2.2 Characteristic Overview
Characteristic Requirement Mandatory Optional Security

Name Properties Properties Permissions
Protocol Mode C.4 Read / None
WriteWithoutResponse
Report O
Report: Input C.1 Read/Notify Write None
Report Type
Report: Output C.1 Read/Write/Write None
Report Type Without Response
Report: Feature C.1 Read/Write None
Report Type
Report Map M Read None
Boot Keyboard C.2 Read/Notify Write None
Input Report
Boot Keyboard C.2 Read/Write/Write None
Output Report Without Response
Boot Mouse Input C.3 Read/NotifyWrite Write None
Report
HID Information M Read None
HID Control Point M WriteWithoutResponse None
C.1: Mandatory to support at least one Report Type if the Report characteristic is supported
C.2: Mandatory for HID Devices operating as keyboards, else excluded.
C.3: Mandatory for HID Devices operating as mice, else excluded.
C.4: Mandatory for HID Devices supporting Boot Protocol Mode, otherwise optional.
Table 2.1: HID Service Characteristics
8.6 E4792 – Typo
Section(s) affected: 2.5.3.2 Report Reference Characteristic Descriptor

EDITOR’S NOTE: Change 0x040xFF to 0x04-0xFF as shown below

Name Size Value
Report ID 1 octet 0x00 – 0xFF

Report Type 1 octet 0x00: Reserved. Shall not be used
0x01: Input Report
0x02: Output Report
0x03: Feature Report
0x04 – 0xFF: Reserved for Future Use.
Table 2.7: Report Reference attributes value
8.7 E4804 – Descriptor lost, not a characteristic
Section(s) affected: 2.6.3.1 External Report Reference Characteristic

Descriptor
Field Size Value
Characteristic 2 octets Characteristic UUID for externally referenced characteristic

UUID
Table 2.9: External Report Reference characteristic descriptor attribute value
8.8 E4805 – Characteristic name should be unified.
Section(s) affected: 2.7 Boot Keyboard Input Report Characteristic

The Input Boot Keyboard Input Report characteristic is used to transfer fixed format and
length Input Report data between a HID Host operating in Boot Protocol Mode and a
HID Service corresponding to a boot keyboard.

8.9 E4806 – C&P Typo
Section(s) affected: 2.9.3 Boot Keyboard Input Report Characteristic

Descriptors
EDITOR’S NOTE: Revise the heading as shown below
2.9.3 Boot MouseKeyboard Input Report Characteristic Descriptors
8.10 E4807 – C&P Typo
Section(s) affected: 2.11.2 HID Control Point Characteristic Value
EDITOR’S NOTE: Edit text as shown below
Value Command Description
0x00 Suspend Informs HID Device that HID Host is entering the Suspend State as
defined in (§7.4.2, Bluetooth HID Profile Specification [5])
0x01 Exit Suspend Informs HID Device that HID Host is exiting the Suspend State as defined
in (§7.4.2, Bluetooth HID Profile Specification [5])
0x02 – N/A Reserved for Future Use.
0xFF
Table 2.17: HID Control PointInformation characteristic value field

9 IRDA INTEROPERABILITY (IRDA)
9.1 E340 – E2080 Type of server in "servers running

simultaneously" (imported)
E340 1.1 IrDA Interoperability (IrDA)
Section(s) affected: 3 OBEX over RFCOMM

1. The device supporting OBEX must be able to function as either a client,
a server, or both
2. All servers (for example FTP, OPP, SYNC) running simultaneously on a device must
use separate RFCOMM server channels
3. Applications (service/server) using OBEX must be able to register the proper
information into the service discovery database. This information for different
application profiles is specified in the profile specifications.
IrDA Interoperability (IrDA) 06 December 2016

10 MESSAGE ACCESS PROFILE (MAP)
10.1 E6937 – Wrong Version Indicated
E6937 1.2.2 Message Access Profile (MAP)
Section(s) affected: 0 Title page header
EDITOR’S NOTE: Change 1.2.1 to 1.2.2 as shown below

Date / Year-Month- Approved Revision Document No
Day
BLUETOOTH DOC
2013-07-16 Adopted dV1.2.21 MAP_SPEC
Prepared E-mail address N.B.
Tel & Car Working Group [email protected]
10.2 E6932 – Typo in condition for SendEvent response SRM

header
Section(s) affected: 5.1 SendEvent Function

C1: The Single Response Mode header is mandatory (M) if:
- GOEP 2.0 or later is used AND
- an SRM header has been received in the previous PUTGET request AND
- the response code is success (0x90 or 0xA0).
10.3 E6933 – Typo in condition for PushMessage response

SRM header
Section(s) affected: 5.8 PushMessage Function
Message Access Profile (MAP) 06 December 2016


C1: The Single Response Mode header is mandatory (M) if:
- GOEP 2.0 or later is used AND
- an SRM header has been received in the previous PUTGET request AND
- the response code is success (0x90 or 0xA0)
else it is excluded (X).
10.4 E6418 – Clarify that PushMessage allows to push

messages to any folder
E6418 1.0 Message Access Profile (MAP)
Section(s) affected: 5.8.2 Name
5.8.2 Name
In a request:
This property shall be used to indicate the folder to which the Message object is to be
pushed. The property shall be empty in case the desired listing is that of the current
folder or shall be the name of a child folder; this may be any folder from the <x-
obex/folder-listing> object. Thus, the value shall not include any path information.



5.8.2 Name
In a request:

5.8.2 Name
In a request:
10.7 E6942 – Typo in table6.5 StartOffset should be

ListStartOffset
Section(s) affected: 6.3.1 Application Parameters Heading

EDITOR’S NOTE: Revise text in Table 6.5 as shown below

6.3.1 Application Parameters Header
The tag IDs used in the Application Parameters header are listed in Table 6.5Table 6.5.
Value Tag ID Length Possible Values
MaxListCount 0x01 2 bytes 0x0000 to 0xFFFF
ListStartOffset 0x02 2 byte 0x0000 to 0xFFFF

11 PHONE BOOK ACCESS PROFILE (PBAP)
11.1 E6503 – The MaxListCount description is not consistent

through the spec
E6503 1.2.1 Phone Book Access Profile (PBAP)
Section(s) affected: 5.1.4.3 MaxListCount
5.3.4.4 MaxListCount

This header is used to indicate the maximum number of entries of the <x-bt/phonebook>
object that the PCE can handle. This header shall always contain a value between 0 and 65535.
The value 65535 means that the number of entries is not restricted. The maximum number of
entries shall be 65,535 if this header is not specified.
This header shall be used to indicate the maximum number of entries of the <x-bt/vcard-
listing> listing object. The value 65535 means that the number of entries is not restricted. The
maximum number of entries shall be 65,535 if this header is not specified.
11.2 E6492 – Inconsistent naming of Folder Version Counters
Section(s) affected: 6.2.1 Application Parameters Header
Phone Book Access Profile (PBAP) 06 December 2016


Value Tag ID Length Possible Values
Order 0x01 1 byte 0x00 = indexed
0x01 = alphanumeric
0x02 = phonetic
SearchValue 0x02 variable Text
SearchProperty 0x03 1 byte 0x00= Name
0x01= Number
0x02= Sound
MaxListCount 0x04 2 bytes 0x0000 to 0xFFFF
ListStartOffset 0x05 2 bytes 0x0000 to 0xFFFF
PropertySelector 0x06 8 bytes 64 bits mask
Format 0x07 1 byte 0x00 = 2.1
0x01 = 3.0
PhonebookSize 0x08 2 bytes 0x0000 to 0xFFFF
NewMissedCalls 0x09 1 byte 0x00 to 0xFF
PrimaryFolderVersionCounter 0x0A 16 bytes 0 to (2128 – 1)
SecondaryFolderVersionCounter 0x0B 16 bytes 0 to (2128 – 1)
11.3 E6877 – Reference to Bluetooth Generic Access Profile

incorrect
Section(s) affected: 6.4 Establishing an OBEX Session
6.4 Establishing an OBEX Session

See Section 5.4 in the Bluetooth Generic Object ExchangeAccess Profile specification for a
description of OBEX connection establishment without authentication.

11.4 E6819 – Incorrect value listed for the OBEX Version

Number in the OBEX Connect Request/
Response tables
Section(s) affected: 6.4 Establishing an OBEX Session
EDITOR’S NOTE: Change 0x14 to “Varies” as shown below
Field/Header Name Value Status

Field Opcode 0x80 M
Field Packet Length Varies M
Field OBEX Version Number Varies0x14 M
Field Flags 0x00 M
Field Maximum Packet Length Varies M
Header Target 796135f0-f0c5-11d8-0966- M
0800200c9a66
Header Authentication Challenge C1
Header Authentication Response C2
Header Application Parameters M
PbapSupportedFeatures Varies C3
C1: Optional if previous packet from remote contained an Authentication Challenge, else excluded.
C2: Mandatory if previous packet from remote contained an Authentication Challenge, else excluded.
C3: Mandatory if the PSE advertises a PbapSupportedFeatures attribute in its SDP record, else excluded.
Backwards compatibility: If the PbapSupportedFeatures parameter is not present 0x00000003 shall be assumed
for a remote PCE.
The OBEX connect response is formatted as follows:
Field/Header Name Value Status

Field Response Code 0xA0 or Error Code M
Field Packet Length Varies M
Field OBEX Version Number Varies0x14 M
Field Flags 0x00 M
Field Maximum Packet Length Varies M
Header Who 796135f0-f0c5-11d8-0966- M
0800200c9a66
Header Connection ID M
Header Authentication Challenge C1
Header Authentication Response C2
C1: Optional if previous packet from remote contained an Authentication Challenge, else excluded.
C2: Mandatory if previous packet from remote contained an Authentication Challenge, else excluded.

11.5 E6820 – Incorrect IrOBEX version listed in [9] in the

References
Section(s) affected: 9 References
EDITOR’S NOTE: Replace text as shown below

[9] IrOBEX specification, version 1.2, April, 1999IrDA Object Exchange Protocol OBEX™ with
Published Errata, Version 1.5, August 2009, iAnywhere Solutions, Inc., Extended Systems,
and Microsoft Corporation

Part IV
PART IV: TEST SPECIFICATION

IMPACT

Errata Service Release to the Bluetooth Specification: ESR10 [Part IV] page 286
INDEX TABLES
By Number:
E4654 Vol 3, Part G 4.2
E5407 Vol 3, Part C 4.2 4.1 4.0
E5433 Vol 3, Part C 4.2
E5610 Vol 3, Part F 4.2 4.1 4.0 3.0 2.1
E6199 Vol 2, Part A 4.2 4.1 4.0 3.0 2.1
E6352 Vol 6, Part B 4.2 4.1 4.0
E6356 Vol 2, Part E 4.2 4.1
E6356 Vol 6, Part B 4.2
E6436 Vol 3, Part H 4.2 4.1 4.0
E6471 Vol 6, Part B 4.2
E6492 PBAP 1.2.1
E6536 Vol 2, Part E 4.2 4.1
E6672 Global 4.2 4.1 4.0
E6910 Vol 2, Part E 4.2 4.1 4.0 3.0
E6963 Vol 6, Part B 4.2 4.1 4.0
E7017 Vol 2, Part E 4.2
E7021 Vol 2, Part E 4.2 4.1 4.0
E7075 Vol 3, Part D 4.2 4.1 4.0 3.0 2.1
E7301 Vol 3, Part H 4.2 4.1 4.0
06 December 2016
By Core Specification Volume and Part:

Volume/Part Erratum Versions affected
Global
E6672 4.2 4.1 4.0
Several Parts
Vol 2, Part A
E6199 4.2 4.1 4.0 3.0 2.1
Radio Specification
E6356 4.2 4.1
E6536 4.2 4.1

Vol 2, Part E
E6910 4.2 4.1 4.0 3.0
Host Controller Interface
E7017 4.2
E7021 4.2 4.1 4.0
Vol 3, Part C E5407 4.2 4.1 4.0

Generic Access Profile
(GAP) E5433 4.2
Vol 3, Part D
E7075 4.2 4.1 4.0 3.0 2.1
Test Support
Vol 3, Part F
E5610 4.2 4.1 4.0 3.0 2.1
Attribute Protocol (ATT)
Vol 3, Part G
Generic Attribute Profile E4654 4.2
(GATT)
E6436 4.2 4.1 4.0

Vol 3, Part H
Security Manager
E7301 4.2 4.1 4.0
E6352 4.2 4.1 4.0
E6356 4.2
Vol 6, Part B
Link Layer
E6471 4.2
E6963 4.2 4.1 4.0
PBAP v1.2.1 E6492 1.2.1
06 December 2016
1 TSE MAPPING TABLE
Test
Test Spec. Spec. Spec.
Spec. Errata Type Related
Errata Ref. Version Location
Impact
E4654 TSE 7558 Core Core 4.2 GATT Yes
E5407 TSE 7570 Core Core 4.2, GAP Yes

Core 4.1,
Core 4.0
E5433 TSE 7058 Core Core 4.2 GAP Yes
E5610 TSE 7573 Core Core 4.2, ATT Yes

Core 4.1,
Core 4.0,
Core 3.0,
Core 2.1
E6199 TSE 7569 Core Core 4.2, Radio Yes

Core 4.1, Specification
Core 4.0,
Core 3.0,
Core 2.1
E6352 TSE 7582 Core Core 4.2, Link Layer Yes

Core 4.1,
Core 4.0
E6356 TSE 7537 Core Core 4.2, HCI Yes

Core 4.1
E6356 TSE 7833 Core Core 4.2 Link Layer Yes
E6436 TSE 7568 Core Core 4.2, Security Yes

Core 4.1, Manager
Core 4.0
E6471 TSE 7812 Core Core 4.2 Link Layer Yes
E6492 TSE 7559 Traditional PBAP Sections 5.1, Yes

Profile v1.2.1 5.1.4.9, and 5.3

Core 4.1

Core 4.1,
Core 4.0

Core 4.1,
Core 4.0,
Core 3.0
TSE Mapping Table 06 December 2016

Test
Test Spec. Spec. Spec.
Spec. Errata Type Related
Errata Ref. Version Location
Impact

Core 4.1,
Core 4.0
E7017 TSE 7574 Core Core 4.2 HCI Yes

Core 4.1,
Core 4.0
E7075 TSE 7556 Core Core 4.2, Test Support Yes

Core 4.1,
Core 4.0,
Core 3.0,
Core 2.1
E7301 TSE 7576 Core Core 4.2, Security Yes

Core 4.1, Manager
Core 4.0
TSE Mapping Table 06 December 2016

unthinkably connected

ESR10 v1.0

Uploaded by

Copyright:

Available Formats

ESR10 v1.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ESR10 v1.0

Uploaded by

Copyright:

Available Formats

Errata Service

Specification of the Bluetooth® System

Publication Date: 06 December 2016

r01 18 May 2016 Initial Draft

NOTATIONS USED IN THIS DOCUMENT

Indication of inserted and deleted text:

Indication when text is affected by more than one erratum:

Notations used in this document ................................................................. 4

27 [Vol 6] Part F: Direct Test Mode...................................................... 223

9 IrDA Interoperability (IRDA) ............................................................ 273

PART I: CORE SPECIFICATION

Bluetooth SIG Proprietary

Core Specification Errata

CORE ERRATA INDEX TABLES

Erratum Volume/Part Versions affected

E3548 Vol 3, Part A 4.2 4.1 4.0 3.0

E4165 Vol 4, Part B 4.2 4.1 4.0 3.0 2.1

E4243 Vol 3, Part F 4.2 4.1 4.0

E4348 Vol 3, Part C 4.2 4.1 4.0 3.0 2.1

E4654 Vol 3, Part G 4.2

E4761 Vol 2, Part E 4.0 3.0 2.1

E4777 Vol 3, Part C 4.2 4.1 4.0 3.0 2.1

E4783 Vol 2, Part C 4.2 4.1 4.0 3.0

E4796 Vol 3, Part H 4.2 4.1 4.0

E4872 Vol 3, Part C 4.0

E4919 Vol 3, Part C 4.2 4.1 4.0

E4999 Vol 2, Part E 4.2 4.1 4.0 CSA3

E5002 Vol 7, Part A 4.2 4.1 CSA3

E5003 Vol 2, Part E 4.2 4.1 CSA3

E5089 Vol 2, Part F 4.2 4.1 4.0 3.0 2.1

E5107 Vol 3, Part F 4.2 4.1 4.0

E5110 Vol 3, Part C 4.2 4.1 4.0

E5242 Vol 3, Part G 4.2 4.1 4.0

E5359 Vol 3, Part G 4.2 4.1 4.0

E5383 Vol 3, Part G 4.2 4.1 4.0

E5399 Vol 3, Part C 4.2 4.1

E5407 Vol 3, Part C 4.2 4.1 4.0

E5418 Vol 3, Part C 4.2 4.1

E5433 Vol 3, Part C 4.2

Core Specification Errata

Erratum Volume/Part Versions affected

E5435 Vol 3, Part C 4.2 4.1 4.0 3.0 2.1

E5610 Vol 3, Part F 4.2 4.1 4.0 3.0 2.1

E5708 Vol 3, Part C 4.2 4.1

E5717 Vol 3, Part G 4.2 4.1

E5718 Vol 3, Part G 4.2 4.1 4.0

E5719 Vol 3, Part G 4.2 4.1 4.0

E5778 Vol 3, Part C 4.2 4.1 4.0

E5791 Vol 2, Part H 4.2 4.1 4.0 3.0 2.1

E5792 Vol 2, Part H 4.2 4.1 4.0 3.0 2.1

E5809 Vol 6, Part C 4.2 4.1 4.0

E5882 Vol 2, Part H 4.2 4.1

E5919 Vol 3, Part F 4.2 4.1 4.0

E6007 Vol 2, Part E 4.2 4.1 4.0

E6098 Vol 3, Part F 4.2 4.1 4.0

E6182 Vol 2, Part E 4.2

E6182 Vol 6, Part B 4.2

E6199 Vol 2, Part A 4.2 4.1 4.0 3.0 2.1

E6214 Vol 3, Part C 4.2