Specification Management Process Document (SMPD)

Specification Management Process Document (SMPD)

Bluetooth® Process Document

• Revision: V27
• Revision Date: 2019-05-17
•  Feedback Email: BARB-feedback@bluetooth.org

Abstract:
This document defines the development processes for creating and enhancing Bluetooth specifications and white papers.

Revision History

Contributors to most recent version

This document, regardless of its title or content, is not a Bluetooth Specification subject to the licenses granted by the Bluetooth SIG Inc. (“Bluetooth SIG”) and its members under the Bluetooth Patent/Copyright License Agreement and Bluetooth Trademark License Agreement.

THIS DOCUMENT 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 WARRANTY OF MERCHANTABILITY, TITLE, NON- INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, THAT THE CONTENT OF THIS DOCUMENT IS FREE OF ERRORS.

TO THE EXTENT NOT PROHIBITED BY LAW, BLUETOOTH SIG, ITS MEMBERS, AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS DOCUMENT AND ANY INFORMATION CONTAINED IN THIS DOCUMENT, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS, OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

This document is proprietary to Bluetooth SIG. This document may contain or cover subject matter that is intellectual property of Bluetooth SIG and its members. The furnishing of this document does not grant any license to any intellectual property of Bluetooth SIG or its members.

This document is subject to change without notice.

Copyright © 2004–2019 by Bluetooth SIG, Inc. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.

1. Introduction

The Specification Management Process Document (SMPD) describes the processes that specification authors and reviewers must follow to develop new specifications and to enhance existing specifications (i.e., to add or remove functionality or to change specific functionality in an adopted specification), to maintain adopted specifications, and to manage the end-of- life of adopted specifications. In addition, this document describes the process for creating, reviewing, and approving white papers.

There are differences in the specification development process between developing new specifications and enhancing existing specifications due to the inherent differences in the scope of those tasks; those differences are highlighted in this document.

The specification development process includes:

• A Requirements Phase (described in Section 3) to define functional requirements
• A Development Phase (described in Section 4) to develop and review specifications
• A Validation Phase (described in Section 5) to validate the specifications by means of Interoperable Prototype (IOP) testing
• An Adoption/Approval Phase (described in Section 6) to present the specifications to the Bluetooth SIG Board of Directors (BoD) for adoption/approval

The Specification Errata Process document (EPD) [3] describes the process for proposing and reviewing specification errata, and approving them as Errata Corrections (as defined in the Bylaws [2]) to adopted specifications. Unless otherwise noted, all references to errata in this SMPD mean specification errata.

1.1 Precedence

The Bylaws of Bluetooth SIG, Inc. (Bylaws) and membership agreements [2] take precedence over any conflicting content in those documents and the SMPD. Notwithstanding anything in this document, the BoD retains ultimate discretion and authority to take action and make decisions even if those actions and decisions do not follow, or conflict with, anything in this document, and nothing in this document limits or restricts the BoD’s independent authority and discretion.

If there are any conflicts between the text in the SMPD and the figures, the text takes precedence.

1.2 Referenced groups and committees

The following types of groups are referenced in this document: Study Groups (SG), Expert Groups (EG), and Working Groups (WG). A WG may also have a subgroup that reports to the WG. Similarly, the following types of committees are referenced in this document: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI), and Bluetooth Qualification Review Board (BQRB). This document also refers to Bluetooth SIG Technical Staff (BSTS), and the BoD.

1.3 Committee reviews and approvals

A committee review is a review that is conducted by members of a committee (typically 3 members) to provide feedback within a specified time (typically 2-3 weeks), however the review time may vary depending on the length and complexity of the material and other priorities within the committee. The group requesting the review and the committee conducting the review each agree upon the duration of the review. The group and committee members use the Bluetooth SIG tools to notify and record the start and end of the review. The group will generally process committee feedback when it is received. When the committee review time expires, the group completes addressing the committee feedback, and should also consider any late-arriving review feedback keeping in mind that the material may be subject to subsequent approval by the committee.

A committee approval is obtained by a vote of the committee members in compliance with the Working Group Process Document [4].

1.4 Notices to members and accessibility of materials

All notices provided to members pursuant to this document may be provided by email, such as a periodic technical update. Notifications that are to be provided to all members will be sent to all active members (i.e., where membership has not been suspended, terminated, or withdrawn). When notifications are emailed they will be sent to the last-known email address (as reflected in Bluetooth SIG’s then-current records) of each individual who has registered under the member company’s membership account and who has not opted-out of receiving email notifications. Nothing in this document alters Bluetooth SIG obligations or requirements with respect to provision of notice under the Bylaws or any other agreement between Bluetooth SIG and any member.

Wherever this document refers to a website that is accessible to all members, this refers to accessibility to individuals who have an active Bluetooth SIG account. Members who do not have an active account may create an account via the Bluetooth SIG website.

1.5 Templates

For each document type (e.g., specifications, white papers, test documents) referred to in this SMPD, Bluetooth SIG provides a template. The template must be used as a basis for each document produced in accordance with this SMPD. Failure to use the correct template may result in the document not being approved. Templates are available on the Bluetooth SIG website [8].

1.6 Specification Types

There are several types of Bluetooth SIG specifications. Hierarchically, all specifications depend on the Bluetooth Core Specification. Specifications such as traditional profiles; traditional protocols; and GATT-based profiles, GATT- based services, and GATT-based protocols all depend on the features within the Core Specification. Other specifications, such as Mesh Model specifications, depend on the Mesh Profile specification which in turn depends on the Core Specification.

The Core Specification Supplement (CSS) specification defines data types, data formats, and common profile and service error codes that are used by the Core Specification and other specifications and does not itself define any behaviors.

The GATT Specification Supplement (GSS) specification defines characteristic and descriptor formats that are used by Profiles and Services and does not itself define any behaviors.
The Mesh Device Properties (MDP) specification defines mesh properties used by the Mesh Profile and Mesh Model specifications and does not itself define any behaviors.

2. Overview

This section provides an overview of the processes and is not intended to include all details.

Figure 2.1 shows the six major phases that make up the Specification Management Process.

The first four phases occur during the specification development process and consist of the Requirements Phase (Section 3), the Development Phase (Section 4), the Validation Phase (Section 5), and the Adoption/Approval Phase (Section 6). This is followed by two post-adoption phases: the Specification Maintenance Phase (Section 7) and the Specification End-of-Life Phase (Section 8).

Figure 2.2 illustrates details of the four phases within the specification development process. The gray boxes indicate the major deliverables for each phase. The orange boxes summarize the process milestones.

In the Requirements Phase (described in Section 3), a proposal to start new work (a New Work Proposal (NWP)) initiates the specification development process by defining the user scenarios to be enabled if the new work proceeds. If the NWP is approved, an assigned group creates a Functional Requirements Document (FRD). Once the FRD is approved and assigned to a group, the Development Phase begins.

During the Development Phase (described in Section 4), specification development progresses through a sequence of stages (0.5/DIPD to 0.9/CR) culminating in a complete draft of the specification. The 0.9/CR specification is made available to all members, then submitted to the BoD who considers the specification for approval. Once approved, the Validation Phase begins.

During the Validation Phase of specification development (described in Section 5), the BoD-approved 0.9/CR specification is made available to all members to review and validate, and Member Review is started. Validation is accomplished via interoperability (IOP) testing between prototypes that are built by members. Once IOP testing is completed (if required for the specification) and BARB approves the IOP test report, then the Adoption/Approval Phase begins.

During the Adoption/Approval Phase (described in Section 6), the specification and related test documents are finalized; BARB, BQRB, and BTI approvals are received; and the final specification package is submitted to the BoD who considers the specification for adoption (i.e., final approval).

A specification may need to return to a previous phase or stage if significant changes are made. In some cases, it may also be possible to waive part of a phase as described in Section 4.4.

The Specification Maintenance Phase (described in Section 7) begins after a specification is adopted by the BoD. During this phase potential errors found in an adopted specification are reported and evaluated, and (if needed) Errata Corrections are made to the specification. The Specification Maintenance Phase continues until the specification is deprecated or withdrawn (see Specification End-of-Life Phase in the following paragraph).

The Specification End-of-Life Phase (described in Section 8) describes the process for deprecating and withdrawing adopted specifications.

3. Requirements Phase

The Requirements Phase begins either with an NWP (which states the desire to initiate work on one or more user scenarios) or after a determination that the desired new work is already covered by their WG charter. If a WG wants to begin new work that it believes is already within the scope of its WG charter, the WG must follow the process defined in Section 3.1 to proceed directly to developing an FRD. For all other work items, the WG must follow the process defined in Section 3.2. The FRD defines the scope of the functional requirements that are used to build specifications in the Development Phase. The Requirements phase is illustrated in Figure 3.1.

3.1 New work covered by a WG charter

When a WG wants to begin new work and reasonably believes that the functionality it wants to add is already within the scope of its WG charter, the WG may begin work on the FRD, provided that they immediately notify BARB. The WG will include in its notification to BARB a description of the proposed new work and a copy of the WG charter with language highlighted that authorizes them to begin the new work.

If BARB rejects the WG’s analysis, the WG must stop work on the FRD and proceed with the NWP process outlined in Section 3.2. If BARB approves the WG’s analysis, the WG will immediately notify BSTS (via email to specification.manager@bluetooth.com) and BSTS will add the item to the next BoD agenda.

The WG will include in its notification to BSTS the same information it provided to BARB. If the BoD rejects the WG’s analysis, the WG must stop work on the FRD and proceed with the NWP process outlined in Section 3.2. If the BoD approves the WG’s analysis, the WG may continue to work on the FRD as outlined in Section 3.3.

3.2 New Work Proposal (NWP)

Any member, WG, SG, or EG may create and submit an NWP (via the Bluetooth SIG website [10]). An NWP must include, at a minimum, information on the following using the official template provided in [8]:

• User scenarios
• Member commitment to develop the FRD and in what area(s) (e.g., Contributor, Author, Reviewer, Prototyping)
• Proposed leadership of the FRD work
• Proposed group assignment for the FRD work
• Email address of primary author(s)

Note: Guidance on the NWP process is available on the Bluetooth SIG website [10].

BSTS will perform the following tasks during the development of the NWP:

• Provide the author(s) an acknowledgement of receipt (typically within seven calendar days of receipt) and outline the next steps.
• If necessary, work with the author(s) so that the NWP is clear and complete. This may require several iterations of the NWP.
• If the NWP contains statements about errors in adopted Bluetooth specifications, work with the author(s) to file entries into the errata system.
• If it is noticed that the NWP is potentially duplicating work that is already in progress or has already been completed, notify the author(s) of the other work for their evaluation.
• Post the NWP to the NWP website accessible to all members.
• Notify all members that the NWP is available for review and whether additional member commitment to develop the FRD is needed.

Members may contact the author(s) to ask questions or to provide feedback regarding the NWP.

At least three member companies must commit to participate in the completion of the resulting FRD for the NWP to become a candidate for BoD approval, and at least one member company must be an Associate or Promoter member. Upon BoD approval of the NWP, the BoD will assign the NWP to an existing all-member WG subgroup or SG to work on the FRD (described in Section 3.3). If an appropriate WG subgroup or SG does not exist, one may be created.

For NWPs that have sufficient member commitment, BSTS will perform the following additional tasks:

• At least 13 days before the NWP is proposed to be approved by the BoD, notify BARB, and the group to which the NWP is recommended for assignment, of the pending NWP approval. This is done to provide an opportunity for feedback in areas such as the proposed group, whether the NWP is already covered by existing work, etc.
• Submit the completed NWP to the BoD.

1. If the NWP is submitted by members who are not associated with a group, arrange for one of the members to present the NWP to the BoD.
2. If the NWP is submitted by a group, arrange for the group chair to present the NWP to the BoD.
3. Invite the BARB chair and the chairs of the group, to which the NWP is recommended for assignment, to the BoD meeting.
4. If the NWP is approved and assigned by the BoD, notify the group it was assigned to; the author(s); the members identified in the NWP as committing to develop corresponding FRD; and if the NWP is proposed by a group, the group of the outcome and the next steps.

After an NWP is approved by the BoD, update the status on the NWP website.

Any NWP may be rejected by the BoD at its discretion, for example, due to resource limitations, if the work is already fully completed, the work is out of scope of the governing documents of Bluetooth SIG (e.g., the Application Programming Interface (API)) [2], or if the work proposed should be filed as an erratum. If the NWP is rejected, BSTS will notify the author(s), the members identified in the NWP as committing to develop the corresponding FRD, and, if the NWP is proposed by a group, the group. The notification will include any reasons for the rejection. The author(s), committed members, or group may request time on the BoD agenda to appeal the rejection.

If a member or group wants to propose removing a feature from an adopted specification, the group or member must prepare an NWP. The NWP must include an analysis of the impact that the removal will have on backward compatibility and interoperability, including an analysis of the impact on test cases.

NWPs are not required for enhancements to the CSS, GSS, or MDP specifications: typically, updates to the CSS, GSS, or MDP specifications result from updates to other specifications that have their own NWPs.

3.3 Functional Requirements Document (FRD)

FRDs define the functional requirements to enable user scenarios. An FRD must include, at a minimum, information on the following using the official template provided in [8]:

• User scenarios
• Functional requirements based on the user scenarios
• Member commitment to develop the resulting specification(s)
• Optional prototype support by members for the anticipated roles
• Recommended WG to develop the resulting specification(s)

FRD development

FRDs are created by the assigned all-member WG subgroup or SG members with editorial support from BSTS. Any member interested in participating in the FRD development may join the group.

FRDs must indicate a commitment from at least two (though three is encouraged) Associate- or Promoter-level member companies to participate in the development of the resulting specification. WGs or SGs that submit an FRD should attempt to achieve broad support from group member companies that represent the intended target industry segment identified in the FRD.

New functionality that is proposed in an FRD should be supportable on as many transports and existing devices as possible. This includes, for example, supporting GATT-based profiles and services on both the Basic Rate/Extended Data Rate (BR/EDR) transport and the Bluetooth Low Energy (LE) transport. If new functionality lacks sufficient member support for a transport, for example due to a lack of member commitment to defining the use of the transport or a potentially insufficient number of IOP test platforms for one or more roles, support on that transport may be excluded from the FRD.

Unless otherwise justified, new functionality, profiles, and services must be compliant with the backward compatibility requirements described in Section 3.3.2.

The WG or SG must submit the FRD to BARB for review and approval. BARB must either approve or reject the FRD based on its engineering judgment. If approved by BARB, the FRD will be made available to all members and notification of its availability will be issued by BSTS.

FRDs are not required for enhancements to the CSS, GSS, or MDP specifications: typically, updates to the CSS, GSS, or MDP specifications result from updates to other specifications that have their own FRDs.

Backward compatibility requirements

Backward compatibility for BR/EDR

For BR/EDR operation, the backward compatibility requirement is defined as interoperation with the BR/EDR portion of the Bluetooth Core Specification v1.1 and later.

Backward compatibility for Bluetooth Low Energy

For LE operation, the backward compatibility requirement is defined as interoperation with the LE portion of the Bluetooth Core Specification v4.0 and later.

Backward compatibility for specifications other than the Core Specification

For specifications other than the Bluetooth Core Specification, backward compatibility of a given version must be maintained with all earlier versions that have the same major version number. For example, version 1.3 must be compatible with versions 1.2, 1.1, and 1.0, but version 2.0 might not be compatible with versions 1.0, 1.1, 1.2, and 1.3. Note that an increment to the major version number of the Core Specification does not imply a lack of backward compatibility with previous versions.

Exemption from the backward compatibility requirements

The WG or SG may propose to exempt specific functionality from the backward compatibility requirement if justification is provided. For example, if the functionality is shown to have low market adoption rates or, because of interoperability issues, it is better to remove or replace functionality than to modify functionality. The WG or SG must include any backward compatibility exemptions in the FRD, which are approved by BARB upon approval of the FRD. Any BARB-approved exemptions will be presented to the BoD for approval at the 0.9/CR Stage.

3.4 Working Group charter

When BARB approves an FRD that is proposed to be assigned to an existing WG, that WG must prepare a draft update to its charter to add the new functionality to the scope (unless the BoD had previously approved the WG’s analysis that a WG charter update is not required). However, when BARB approves an FRD that is proposed to be assigned to a new WG, BARB and members who are interested in developing the functionality outlined in the FRD must prepare a draft charter for a new WG with the new functionality included in the charter scope.

Once the new or updated WG charter is prepared, it must be submitted to BARB for review and approval. Once BARB approves the charter, the draft of the new or updated WG charter will be submitted to the BoD for approval.

Once the BoD approves the charter, the WG to which the specification development work was assigned by the BoD must work closely with the group who prepared the FRD in case any necessary updates or clarifications to that FRD are required. If an FRD update is needed during the Development Phase, the processes outlined in Section 3.3 and this section must be followed; however, specification development may occur in parallel with the FRD and WG charter updates.

3.5 Requirements Phase exit requirements

The Requirements Phase is complete and the Development Phase begins when a WG charter with necessary scope for the FRD is either confirmed or approved by the BoD and the following requirements have been met:

• The NWP has either been approved by the BoD, or the BoD has agreed that an NWP is unnecessary.
• The FRD and corresponding WG charter has been approved by BARB.

4. Development Phase

During the Development Phase, the assigned WG(s) create the new specification and/or enhance an existing specification. The FRD defines the requirements of the new or enhanced Bluetooth specification. No functionality is allowed in the specification that is not reasonably related to requirements in the FRD. The objective is to create a 0.9/CR specification that is ready for the Validation Phase (described in Section 5) at the conclusion of the Development Phase.
During the Development Phase, a specification (or specification enhancement) advances through three stages.

For a new specification, the three stages are:

• 0.5 Stage
• 0.7 Stage
• 0.9 Stage

For a specification enhancement, the three stages are:

• Draft Improvement Proposal Document (DIPD) Stage
• Final Improvement Proposal Document (FIPD) Stage
• Change Request (CR) Stage

Each stage is described further in the subsections that follow. Figure 4.1 below illustrates the various documents that the WG will prepare at each stage.

Figure 4.1: Overview of the specification stages that occur during the Development Phase

The role of BARB throughout the specification development process is to provide WGs with advice and technical assistance. WGs may, at any time, make requests to BARB for technical advice regarding specification development and architectural concepts to be used in a specification. WGs are particularly encouraged to solicit early feedback from BARB for features that have more complex architectural considerations.

4.1 0.5/DIPD Stage

During the 0.5/DIPD Stage, the WG will develop the following using the official templates provided in [8]:

1. For a new specification, a draft of the 0.5 specification, which must include, at a minimum, information on the following:

• Architecture to cover the requirements as stated in the FRD
• For protocols, service access points defined
• For services, exposed data and behavior
• For profiles, protocols identified and functionality specified

2. For a specification enhancement, a draft of the DIPD, which must include, at a minimum, information on the following:

• Background: The scope of work, the objectives guiding the work, and how this specific proposal fits into the scope
• Overview of proposal: A summary of the extended functionality (added flexibility, improved performance, etc.) provided by the DIPD including a clear description regarding how the new functionality fits into the current specification version. If the WG has evaluated multiple proposals, these proposals should be included to allow BARB the opportunity to determine if sufficient due diligence was made in the selection of the preferred proposal.
• Coverage of requirements: A summary of the coverage of functional requirements given by the proposal, with reference to the appropriate system requirements and usage scenarios given in the associated FRD
• Problem definition: A statement of problems solved by the proposal(s)
• Selection criteria: A statement regarding the selection/performance criteria from associated evaluation metrics that have guided the selection process
• Justification of choice: An examination of the evaluation metrics that justify the choice between proposals and reveal trade-offs
• Description: A description of the functionality and extended protocols. This section can adapt to different needs by adding relevant sub-sections.

3. Test Strategy: A description of functionality proposed to be tested (or not tested) as part of the Bluetooth Qualification Program and how the functionality it is proposed to be tested (e.g., expectations on the Lower Tester(s) or the Upper Tester(s), and if the tests will be attributed as conformance or interoperability tests or a combination of both). This may be in a separate document or a separate section within the 0.5/DIPD specification. The conventions to be used in a Test Strategy are described in the Test Strategy and Terminology Overview document (TSTO) [5].

The primary audience of the documents at this stage is the WG members and BARB who review the architectural proposals and requirement coverage, and BTI who reviews the Test Strategy. In most cases, the documents at this stage are not intended to contain text that is planned for inclusion in the final specification.

BSTS must review all documents for consistency with the Bluetooth Drafting Guidelines [1] and identify issues for the WG to address. BARB must review the 0.5/DIPD specification. For a specification enhancement, BARB must also review the DIPD for compliance with the backward compatibility requirements described in Section 3.3.2. BTI must review the Test Strategy.

BARB must either approve or reject the 0.5/DIPD specification based on its engineering judgment. If approved by BARB, the 0.5/DIPD specification will be made available on the Bluetooth SIG website to all Associate and Promoter members and notification of its availability will be issued by BSTS. At the 0.5/DIPD Stage, approval of the Test Strategy is not required.
The 0.5/DIPD Stage is not required for enhancements to the CSS, GSS, or MDP specifications

0.5/DIPD Stage exit requirements

The 0.5/DIPD Stage is complete and the 0.7/FIPD Stage begins when the following exit requirements are met:

• BSTS has completed reviewing the 0.5/DIPD specification and Test Strategy.
• BARB has approved the 0.5/DIPD specification.
• BTI has completed its review of the Test Strategy.
• BSTS has made the approved 0.5/DIPD specification available to all Associate and Promoter members.

4.2 0.7/FIPD Stage

During the 0.7/FIPD Stage, the WG will develop the following using the official templates provided in [8]:

1. For a new specification, a draft of the 0.7 specification, which must include, at a minimum, information on the following:

• A description of all changes that were made since the BARB-approved 0.5, including new or modified proposals, selection criteria, and justification of choice. Changes must be described at the same level of detail as required in the 0.5 Stage.
• All functional requirements from the FRD addressed.

2. For a specification enhancement, a draft of the FIPD, which must include, at a minimum, information on the following:

• A description of all changes that were made since the BARB-approved DIPD, including new or modified proposals, selection criteria, and justification of choice. Changes must be described at the same level of detail as required in the DIPD Stage.
• As necessary, further developed areas that were described in Section 4.1 regarding the DIPD.
• A completed description of the improvement.
• An updated architectural description.
• All functional requirements from the FRD addressed.

3. 0.7/FIPD test documents, which must include, at a minimum, information on the following:

• A Test Suite, consisting of a list of Test Purposes as described in the TSTO [5].
• An Implementation Conformance Statement (ICS), as described in the TSTO [5].

For specification enhancements, the Test Suite and ICS may be supplied either as separate documents or as additional sections in the FIPD.

The primary audience of the documents produced at this stage is the WG members and BARB who review the complete description of the feature or improvement including some text planned for inclusion in the final specification. BTI is the audience for review of the test documents.

BSTS will review the new or changed parts of the 0.7/FIPD specification and test documents for consistency with the Bluetooth Drafting Guidelines, including language conventions established by Bluetooth SIG. BARB will review the 0.7/FIPD specification.

BSTS will assist the WG in preparing the 0.7/FIPD test documents in accordance with the TSTO [5].

BTI must review the 0.7/FIPD test documents. The WG must provide the 0.7/FIPD specification to BTI as a reference when reviewing the 0.7/FIPD test documents, which BTI will review in accordance with the BTI Specification Review Process Checklist [6].

After BARB has completed its review of the 0.7/FIPD specification and BTI has completed its review of the 0.7/FIPD test documents, BSTS will make the reviewed 0.7/FIPD specification available to all Associate and Promoter members.

The 0.7/FIPD Stage is not required for enhancements to CSS, GSS, or MDP specifications.

0.7/FIPD Stage exit requirements

The 0.7/FIPD Stage is complete and the 0.9/CR Stage begins when the following exit requirements are met:

• BSTS has completed reviewing the 0.7/FIPD specification and test documents.
• BARB has completed reviewing the 0.7/FIPD specification.
• BTI has completed reviewing the 0.7/FIPD Test Suite (Test Purposes) and 0.7/FIPD ICS.
• BSTS has made the reviewed 0.7/FIPD specification available to all Associate and Promoter members.

4.3 0.9/CR Stage

There are two types of CRs: An Integrated CR, which is a change-tracked document of an entire adopted specification showing all changes since the previous version, and an Abbreviated CR, which is a document that provides instructions for modifying only the affected sections of the specification version on which the CR is based.

During the 0.9/CR Stage, the WG will develop the following using the official templates provided in [8]:

1. For a new specification, a content-complete draft of the 0.9 specification, which must include, at a minimum, information on the following:

• A description of all changes that were made since the BARB-reviewed 0.7 specification (or since the 0.5 specification if producing the 0.7 specification had been waived), including new or
• modified proposals, selection criteria, and justification of choice. Changes must be described at the same level of detail as required in the 0.5 Stage and 0.7 Stage.

2. For a specification enhancement:

• Either an Integrated CR, which must include, at a minimum, information on the following:
• A description of all changes that were made since the BARB-reviewed FIPD (or since the DIPD if the FIPD has been waived) including new or modified proposals, selection criteria, and justification of choice. Changes must be described at the same level of detail as required in the DIPD Stage and FIPD Stage.
• All changes proposed to the previously-adopted specification using change-tracking.
• All approved technical errata (with each erratum referenced with an erratum number), shown using change-tracking, that have yet to be incorporated into the previously-adopted specification version, and that impact text that is associated with the specification enhancement; or that otherwise impact IOP testing.

3. Or an Abbreviated CR, which must include, at a minimum, information on the following:

• A description of all changes that were made since the BARB-reviewed FIPD (or since the DIPD if the FIPD has been waived) including new or modified proposals, selection criteria, and justification of choice. Changes must be described at the same level of detail as required in the DIPD Stage and FIPD Stage.
• All changes proposed to each affected section and paragraph of the specification that the CR proposes to change.
• All approved technical errata (with each erratum referenced with an erratum number), shown using markup, that have yet to be incorporated into the previously-adopted specification version, and that impact text that is associated with the specification enhancement; or that otherwise impact IOP testing.

4. A CSS CR (if new entries are required by the specification), which may be embedded in an Abbreviated CR of the specification.
5. A GSS CR (if new entries are required by the specification), which may be embedded in an Abbreviated CR of the specification.
6. An MDP CR (if new entries are required by the specification), which may be embedded in an Abbreviated CR of the specification.
7. 0.9/CR test documents, which must include, at a minimum, information on the following using the official template provided in [8]:

• The 0.9/CR Test Suite, which includes content-complete test cases and the associated Test Case Mapping Table (TCMT), as described in the TSTO [5].
• The 0.9/CR ICS, as described in the TSTO [5].
• If configuring the tests requires specific parameters for the Implementation Under Test (IUT), the 0.9/CR Implementation eXtra Information for Testing (IXIT).
• The 0.9/CR Test Case Reference List (TCRL) (optional for Core Specification updates).

8. A test coverage analysis indicating which specification requirements are either tested or not tested within the 0.9/CR Test Suite (for specification enhancements, the test coverage analysis only needs to include newly added and impacted functionality, and not the un-impacted areas of the original specification).
9. An IOP test plan.

For specification enhancements, the Test Suite, ICS, and IXIT may be supplied either as separate documents or as additional sections in the Abbreviated CR.

In most cases, an Integrated or Abbreviated CR should be based on the previously-adopted version of the specification, but it may also be based on the latest intermediate draft. The latest intermediate draft specification version number must be the version number associated with a version of the document that is frozen and that will not change over time. Otherwise, additional identifying information (such as the document date and a URL to a permanent location) must be provided to identify the specific “baseline” version. If an intermediate draft is used, any changes not directly related to the CR within a given section that the CR is modifying must be included, but are not required to be shown using markup. If the relevant portions of the intermediate draft are later updated, the CR must be updated to reflect the updates to the intermediate draft.

Ideally, Abbreviated CR material is integrated into a draft of the complete specification and the complete test documents respectively, before the Validation Phase, but they may also be integrated at the start of the Validation Phase. If multiple features are being developed for a specification (e.g., the Core Specification), it may be desirable to integrate the features into a single draft after IOP testing is complete.

BSTS will review the 0.9/CR specification and test documents for consistency with the Bluetooth Drafting Guidelines. Then BARB will review the 0.9/CR specification followed later by the IOP test plan (as described in Section 4.3.1). Once the 0.9/CR specification is submitted by the WG to BARB for review, BSTS will make it accessible for all members to review and notify all members of its availability. From this point forward in the specification development process, BSTS will make drafts of the specification submitted to BARB available to all members with periodic notices sent to all members.

For a specification enhancement, the WG will recommend to the BoD whether or not previous versions of the specification should be deprecated or withdrawn, including the technical reasons for the recommendation(s).

BARB will review the WG’s analysis of the 0.9/CR specification’s compliance with the requirements given in the FRD, any potential security issues, any regulatory issues, conformity with the Bluetooth architecture, and, for a specification enhancement, compliance with the backward compatibility requirements described in Section 3.3.2. If BARB identifies any potential security issues, BARB will notify BSTS for review and coordination with the Security Expert Group; and if BARB identifies any regulatory implications, BARB will notify BSTS to review and coordinate with the Regulatory Committee and Bluetooth SIG’s legal counsel. BARB must either approve or reject the 0.9/CR specification based on its engineering judgment and consideration of the factors described in this paragraph.

BTI will review the 0.9/CR test documents taking the test coverage analysis into account. BTI must either approve or reject the 0.9/CR test documents.

After BARB approves the 0.9/CR specification, the WG submits the IOP test plan to BARB for review.

The BARB-approved 0.9/CR specification is presented to the BoD to approve the start of IOP testing and the publication of the 0.9/CR specification to all members.

To highlight potential legal issues, WGs may request a specification review by Bluetooth SIG’s legal counsel (legal review) before the mandatory legal review takes place during the Adoption/Approval Phase. However, for specification enhancements, the legal review should be done on an Integrated CR (as opposed to an Abbreviated CR) and this should be prescheduled as far in advance as possible so that resources are available.

IOP test plan

The WG will develop a written IOP test plan that must satisfy all the requirements defined below for use during the Validation Phase at the IOP test events. WGs must submit the IOP test plan to BARB for review before the IOP test event(s) begin. For simple specification enhancements (especially those that do not require modifying or adding any test cases in the Test Suite), IOP testing may not be needed, and the WG may submit a request to BARB for a waiver from IOP testing by using the process defined in Section 4.4.

The IOP test plan must include:

1. Test cases to verify all new mandatory, optional, and conditional features
2. At least one test case for each op code
3. At least one test case for each parameter
4. At least one test case for each packet type
5. Backward compatibility test cases for specification enhancements so that requirements listed in Section 3.3.2 are met for all enhanced functionality (also see Section 4.3.1.1).
6. Test cases where the IUT is exposed to values outside of defined ranges or to behavioral aspects considered invalid or unexpected (Invalid Behavior test cases). Note that it is expected that a tester such as PTS or other test tool will be the initiator of any invalid behavior.
7. Any temporary assigned numbers (selected in coordination with BSTS to avoid overlap at upcoming IOP test events) to be used at the IOP test event, as described in Section 4.3.1.2.
8. Identification of the required number of independent implementations that must pass each test case, taking into account the coverage requirements described in Section 4.3.1.3
9. Identification of any test cases in the Test Suite that the WG believes should be excluded and the justification for their exclusion. These typically include:                                             • Future Proofing test cases (e.g., common tests so that possible future additions can be accommodated, such as additional characteristics, extending characteristics, or the use of Reserved for Future Use (RFU) bits or fields)
   • Test cases which are a subset of other included tests
   • Generic test cases that are virtually identical to tests that run for several other specifications (e.g., triggering common error codes)
   • Test cases with the same test purpose as test cases that run over another transport (e.g., a BR/EDR test case that is similar to an LE test case)
   • Robustness or stress testing of the implementation

The IOP test plan may also include tests that are unique to IOP testing such as end-to-end test cases that string together more complex sequences that may resemble a typical user scenario.

Although BARB approval of the IOP test plan is not required (on the understanding that the IOP test plan will continue to be modified and improved with each IOP test event), BARB approval of the IOP test report is required (see Section 5.1.1). If an IOP test plan does not satisfy all the requirements defined in Section 4.3.1, the WG should present a summary of any known variances and the rationale for each variance to BARB before the IOP test event(s) begin.

The IOP test plan and test cases should be primarily based on the content within the associated specification’s test documents.

To make the IOP test events efficient, the WG should have the IOP test plan and all associated test cases completed and available to implementers ideally at least one month before the first IOP test event.

Planning for backward compatibility testing
For specification enhancements, IOP testing of backward compatibility must consider verification against all active and deprecated versions of the specification because those specifications and functionality commonly found in Bluetooth products may have a very long life span (e.g., vehicles). The WG must analyze the appropriate level of backward compatibility testing needed (if any) including which versions to test and the tests to perform, and provide this analysis to BARB. BARB must review the analysis and recommend changes (if any) for the WG to incorporate into the IOP test plan.

Members participating in backward compatibility testing are encouraged to bring legacy devices that have been qualified against previous specification version(s). The WG must report any backward compatibility failures in the IOP test report. Member companies are also encouraged to perform backward compatibility testing in their own labs outside of the location of the IOP test event and to report any specification-related issues to the WG.

Temporary Assigned Numbers used in IOP testing
BSTS and BARB must be consulted to coordinate temporary assignment of assigned numbers that will be used at the IOP test event so that there are no overlaps or clashes with other specifications. These temporary values must be included in the IOP test plan and will not be assigned for use by any adopted specifications.

For IOP testing where one or more new 16-bit UUID values are being proposed, the values within the range of 0x7F00 to 0x7FFF are reserved for IOP testing.

For IOP testing where one or more new Fixed Protocol Service Multiplexer (PSM) values are being proposed, values starting from the end of the valid range from 0x0000 to 0x007F, as specified in the Core Specification, will be used.

Coverage requirements
The WG must provide proof to BARB that the required number (as described in the sections that follow) of independent implementations have passed each test case. Any WG request for exceptions to the required number of independent implementations must be indicated in the IOP test plan that is submitted to BARB.

Implementations are considered to be independent of each other as long as all parts that are relevant to the validation have been developed independently, i.e., by different teams (which do not necessarily come from different companies). BSTS may assist in assessing whether the prototypes can be considered independent of each other in order to preserve anonymity and confidentiality of implementation details.

Note that test tools, including PTS, are not considered to be independent implementations.

Core Specification IOP coverage requirements
A Core Specification feature typically defines one or more roles where each role is designed to interoperate with one or more other roles or possibly with itself.

For each pair of roles that are designed to interoperate with each other, at least three independent implementations of each role must be demonstrated to interoperate with three independent implementations of the complementary role.

For each role that can interoperate with another device in the same role, at least three independent implementations of that role must demonstrate that they can interact with one another in that role.

Service specification IOP coverage requirements
At least three independent service implementations must demonstrate that they interoperate with at least one client implementation, which may be PTS.

Profile and protocol specification IOP coverage requirements
Profile and protocol specifications typically define one or more roles where each role is designed to interoperate with one or more other roles, or possibly with itself.

For each pair of roles that are designed to interoperate with each other, at least two independent implementations of each role must demonstrate that they interoperate with two independent implementations of the complementary role.

For each role that can interoperate with another device in the same role, at least three independent implementations of that role must demonstrate that they interact with one another in that role.

Model specification IOP coverage requirements
At least three independent server model or control model implementations must demonstrate that they interoperate with at least one client implementation (which may be PTS), and at least one client model implementation must demonstrate that it interoperates with at least one server model implementation and PTS.

Specification version numbering

During the 0.9/CR Stage, the WG must prepare a recommendation to present to the BoD regarding the version number to be applied to the specification when adopted.

Versions of the specifications fall into two types: full release versions, which include new or updated features, and maintenance release versions (also known as “dot-Z versions”), which integrate technical and editorial errata, but do not include new or updated features. Full release versions have two- part numbers in the form of X.Y, such as 2.1 or 5.0, while maintenance release versions have three-part numbers in the form of X.Y.Z, such as 2.1.2. The value of Z cannot be 0.

For any two versions, one is referred to as the “higher version” and the other is the “lower version”. This is determined according to the following rules:

• If the X components differ, the one with the higher X value is the “higher version”.
• If the X components are the same, but the Y components differ, the one with the higher Y value is the “higher version”.
• If the X.Y components are the same, but the Z components differ, the one with the higher Z value is the “higher version”. A two-part number X.Y is, for this purpose, treated as a three-part number X.Y.0.

For example, the following version numbers would be in order from lowest version to highest version: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. For CSS, each update increments only the X component of the version number.

BoD approval prerequisites
At the end of the Specification Development phase the following requirements must be met before a 0.9/CR specification is submitted to the BoD for approval:

• The WG has completed the test coverage analysis.
• BSTS has completed reviewing the 0.9/CR specification and test documents.
• BARB has approved the 0.9/CR specification.
• BARB has approved the CSS CR (if new entries are required by the specification) which may be embedded in an Abbreviated CR of the specification.
• BARB has approved the GSS CR and MDP CR (if new entries are required by the specification).
• BTI has approved the 0.9/CR Test Suite, ICS, and TCRL, together with an IXIT (provided that the IXIT is needed to perform the tests in the Test Suite). The TCRL is optional at this stage for updates to the Core Specification.
• The WG has submitted the IOP test plan to BARB for review (if testing is not waived by BARB).

The documents presented to the BoD must include the BARB-approved 0.9/CR specification, and a presentation to the BoD which must include:

• Any known requests to waive IOP testing or any of the requirements defined in Section 4.3.1
• A list of transports that the specification supports (e.g., BR/EDR, LE. etc.)
• For a specification enhancement, any exemptions from the backward compatibility requirements (described in Section 3.3.2) that are being requested by the WG
• For a specification enhancement, a recommendation from the WG for the version number to apply to the adopted specification
• For a specification enhancement, the WG’s end-of-life recommendation for the previous version(s) of the adopted specification, including any technical reasons why the deprecation or withdrawal of any previous version of the specification is or is not recommended, and the justification for the recommendation
• Any unresolved serious concerns from BARB or BTI members (e.g., reasons for any No votes during approvals, concerns resulting from review of test documents, or concerns that the 0.9/CR specification is outside of the scope of the FRD or charter)
• The preparation status of the Profile Tuning Suite (PTS) or other necessary tools associated with adoption that are prepared by BSTS

The BoD may choose to approve the 0.9/CR specification for IOP testing as required by the Bylaws [2], before BTI approves the 0.9/CR test documents and before the WG confirms that the IOP test plan meets the requirements defined in Section 4.3.1. The BoD may also condition its approval of the 0.9/CR specification for IOP testing upon BTI’s approval of the 0.9/CR test documents.

0.9/CR Stage exit requirements
The 0.9/CR Stage is complete and the Validation Phase begins when the BoD approves the start of IOP testing.

4.4 Specification Development Process Waivers

A WG may request to waive one or more of the following process steps:

• The 0.5/DIPD Stage
• The 0.7/FIPD Stage
• IOP testing within the Validation Phase

To request a waiver, the WG must use the process waiver template provided by Bluetooth SIG [8] and submit a waiver request to each committee (i.e., BARB or BTI) that is required to review or approve the draft specification or associated test documents at the stage that the WG proposes to waive, and each of those committees must approve the waiver request.

A waiver request must include the following:

• An identification of the stage(s) that the WG wants to waive
• A justification why the stage(s) should be waived
• An identification of each committee (i.e., BTI and/or BARB) that is required to review and approve the waiver request

The committee considering the waiver may require that a representative of the WG make a presentation to justify the SMPD process waiver before deciding on the waiver request.

If a waiver requests to waive multiple steps and part of the waiver is rejected and part is approved, the committee’s response must indicate which steps in the waiver request were approved and which were rejected. If a waiver request is rejected, the rejection notification must include the reasons for rejection.

5. Validation Phase

During the Validation Phase, the WG will perform IOP testing on the 0.9/CR specification with the objective of delivering an IOP test report for BARB review and approval. Whenever possible, IOP testing of specification enhancements should be conducted against the integrated draft specification. In addition, the Member Review, as required by the Bylaws [2], starts during this phase.

If the specification (or enhancement) does not require IOP testing, then IOP testing within the Validation Phase may be waived using the process described in Section 4.4.

Throughout the course of IOP testing (which may be one or more events), the WG should track issues using Bluetooth SIG’s issue tracking system and iterate to incorporate updates to the draft specification, test documents, and IOP test plan. Once IOP testing concludes, the WG must complete updates to the draft specification and test documents to address all issues, and prepare and submit an IOP test report to BARB for review and approval. This is illustrated in Figure 5.1.

During the Validation Phase there are several activities that may begin. These activities may occur in parallel and include the following:

• The BoD-approved 0.9/CR specification is made available to all members by BSTS with notification of the start of the Member Review period required by the Bylaws.
• Any required updates are incorporated into CSS (which may be embedded in an Abbreviated CR of the specification).
• Characteristic or descriptor definitions are incorporated into the GSS specification as well as PTS for IOP testing.
• Mesh property definitions are incorporated into the MDP specification as well as PTS for IOP testing.
• BSTS enables IOP platform registration and results entry tool in preparation for IOP testing.
• IOP testing, if required (see Section 5.1).
• Review comments and issues, including those submitted as a result of IOP testing, are processed and changes are incorporated into the draft specification.

5.1 IOP testing

The primary objective of IOP testing is to validate the specification by, for example, checking for accuracy and ambiguity within the text, reviewing for any fundamental design errors and omissions, and providing validation against previously established requirements developed earlier in the specification development process. IOP testing may result in changes to the draft specification and multiple IOP test events may be necessary to complete all required testing.

It is important to give members outside the WG the opportunity to participate in IOP testing because they provide an independent view of the specification and can uncover areas of ambiguity in the specification that may not be evident to the members of the WG who developed the draft. Before each IOP test event, BSTS will make the event details, the latest draft specification, the Test Suite, and IOP test plan available and will notify all members ideally one month before each event. The updated draft specification, Test Suite, and IOP test plan used at an IOP test event should be available at least one week before each event.

During IOP testing, pairwise combinations of platforms will attempt to execute the tests and IOP testing participants will record the pass/fail results of each test and comments. An anonymized summary of these results (referring to e.g., “Platform A”, “Platform B”, etc.) and any comments, will be gathered during the IOP test events and made available to the members of the WG during and after the IOP test event. In case additional information is needed to gain a better understanding of any comments or failures that occurred during IOP testing, BSTS may act as an intermediary to gather further information from the submitting member.

If possible, PTS should be updated to support IOP testing with platforms at all layers above the Host Controller Interface (HCI), and be present at IOP test events for those layers. Other testing tools may also be present at IOP test events. A summary of the results of testing with PTS or other test tools (if any) should be included in the IOP test report.

IOP testing will be open to all members who want to provide a prototype implementation, however, Bluetooth SIG may condition participation on acceptance of agreements with Bluetooth SIG (including participation and confidentiality agreements). The WG is responsible for processing and resolving issues discovered during IOP testing, and updating the affected documents; WG-approved changes must be incorporated as updates to the draft specification and test documents for use at each IOP test event.

Before the Validation Phase, WGs may perform preliminary IOP testing at events that are only open to members of the WG, however the results of informal testing may not be included in the IOP test results.

It may happen that all steps leading up to the first IOP test event are followed, including an announced IOP date and location with the intention to start IOP testing, but BoD approval had not been secured before the start of the test event. In this case, the BoD may authorize the inclusion of test results that were collected before the BoD’s approval to start IOP testing, provided that the results collected were based on the same specification and Test Suite being approved by the BoD.

IOP testing is not required for enhancements to CSS, GSS, or MDP specifications.

IOP test report
After IOP testing is complete, the WG must submit the IOP test report to BARB with the objective of demonstrating that the required number of independent platforms have passed the required tests. BARB must review and approve or reject the IOP test report and will notify the WG if additional IOP testing is needed before submitting the Voting Draft specification package to the BoD. BSTS and the WG must ensure that no member-identifying information appears in the IOP test report before submitting the report to BARB.

The IOP test report must include:

• A list of all IOP test events that occurred during the Validation Phase including their dates and locations.
• The number of member companies and independent platforms that participated at each IOP event including whether PTS was used.
• A list of the specification, Test Suite, and IOP test plan versions used at each event.
• An executive summary stating whether or not all test cases met the minimum pass criteria.
• A summary of any variances from the IOP test plan requirements defined in Section 4.3.1 and the rationale for each variance.
• A summary of PTS coverage for test cases in the Test Suite.
• A list of all test cases (including backward compatibility tests) from the IOP test plan, the number of test passes, the number of test failures, and whether the minimum criteria was met per test case including an explanation as to why any requirements were not met.
• A summary of issues, comments, and questions at each event (including those filed against the specification during IOP testing) and the impact to the specification and test documents.

5.2 Validation Phase exit requirements

The Validation Phase is complete and the Approval/Adoption Phase begins when BARB has approved the IOP test report (unless testing was waived by BARB) and all of the following requirements have been met:

• BSTS has made the approved 0.9/CR specification available to all members for Member Review as required by the Bylaws and notified all members of its availability.
• All issues that were identified during IOP testing, and that have a test impact, have been incorporated and tested.
• WG has completed IOP testing (unless testing was waived by BARB).

6. Adoption/Approval Phase

During the Adoption/Approval Phase, the specification and related test documents are finalized, BARB, BQRB, and BTI approval is received, notice of the proposed Adoption Date is issued along with the final version of the draft specification submitted to the BoD for adoption (Voting Draft), and the final specification package is submitted to the BoD. After the minimum duration of Member Review required by the Bylaws [2]) has been satisfied, the BoD will consider the specification for adoption on the Adoption Date. After adoption, the specification is published and the qualification system is enabled. The Adoption/Approval Phase is illustrated in Figure 6.1.

6.1 Voting Draft

The Voting Draft is created by incorporating updates (provided in the Validation Phase) into the required specification documents, and preparing a final draft of the new specification. For specification enhancements, BSTS will create the integrated specification by integrating one or more CR(s) into the previously-adopted higher version of the specification (see Section 4.3.2) if not already completed before the Validation Phase.

If changes are made to the specification during this phase and the WG, BARB, or BTI determines that any change requires additional IOP testing, the specification will return to the IOP testing portion of the Validation Phase for the WG to perform the additional tests. During the Adoption/Approval Phase, the following documents will be completed and made available to the BoD prior to the Adoption Date:

• The Voting Draft
• All supporting specifications (i.e., CSS, GSS, MDP) as required for the relevant specification (or enhancement) type, if not previously adopted
• For specification enhancements, a change-tracked version of the adopted specification version showing the changes proposed in the Voting Draft
• A description from the WG of any backward compatibility requirements (as described in Section 3.3.2) that have not been met and the justification for any exemptions
• A description from the WG of any IOP test plan requirements (as described in Section 4.3.1) that have not been met and the justification for any deviations along with the IOP test report (which may be provided by providing a link to a copy on the Bluetooth SIG website)
• A recommendation from the WG for the deprecation or withdrawal of any previous version(s) of the adopted specification along with a justification, highlighting changes since the 0.9/CR Stage end-of-life recommendation
• A summary, prepared by the WG, of changes to features or functionality since the 0.9/CR specification (if any)
• A summary, prepared by BARB, of concerns raised by BARB members that the specification produced by the WG is beyond the scope of the charter approved by the BoD (if any)
• A list of remaining unresolved legal issues from legal review (if any)
• The BTI-approved Test Suite, together with the WG-approved summary of the test coverage of the Voting Draft specification. In case of newly-added or modified functionality without test coverage, a written justification for the omission is required
• The BTI-approved ICS and IXIT (if required by the specification)
• The TCRL approved by both BTI and BQRB
• A report prepared by BSTS together with BTI regarding the status of tool readiness (e.g., PTS and other test tools, Bluetooth Launch Studio) including if any test cases in the TCRL are not supported by test tools
• A summary, prepared by the WG, of all necessary assigned numbers
• An adoption checklist prepared by BSTS and the WG showing that all the deliverables in this section have all been completed
• All other information requested by the BoD

During the Adoption/Approval Phase, the WG should use Bluetooth SIG’s issue tracking system to capture issues and comments against the draft specification and test documents so that they are accounted for in the finalization of the Voting Draft specification. For a specification enhancement, all relevant approved errata (i.e. those approved errata not yet integrated) must be incorporated, and must be identified using tracked changes.

The WG must submit the final draft specification to BSTS for legal review. For new specifications, the legal review will include the entire specification. For specification enhancements, the review will focus primarily on the changed parts of the specification. The purpose of legal review is primarily to identify legal risks that the WG should consider and seek to resolve. The legal feedback will be categorized based on severity. If an optional legal review was performed at the 0.9/CR Stage, the version that is submitted for legal review must show, as tracked changes, all changes that were made since that version (generated either by the WG or BSTS). Upon completion of legal review, the WG and BSTS will agree on the feedback to be incorporated into the draft specification. If there are any unresolved legal comments from legal review on the draft specification, the WG Chair may request time on the BoD agenda to agree on resolution.

In parallel with legal review, the WG must submit the draft specification to BARB for review. Upon the initial submission to BARB, BSTS will notify all members that the draft specification has been submitted to BARB for review and that it is also available for Member Review. If the WG submits updates to the draft specification for BARB re-review, BSTS will send additional notices to all members on a periodic basis.

Upon completion of BARB review, the WG and BARB will agree on the feedback to be incorporated into the draft specification.

If the legal review results in any substantive changes, additional review by BARB may be required. Similarly, if the BARB review results in any substantive changes, BSTS will determine if an additional legal review of those changes is required. Upon completion of legal review and BARB review, BARB must either approve or reject the Voting Draft.

If any test documents require updating, BSTS will assist the WG in updating the test documents. BTI must either approve or reject the test documents. If approved by BTI, BTI will assist in finalizing the TCRL and deliver this document to BQRB along with the associated ICS, IXIT, and Test Suite. BSTS will estimate the date of the BoD meeting when the BoD intends to vote on adoption of the Voting Draft (Adoption Date) and provide it BTI for use in the TCRL. BARB approval of the specification, BTI approval of all test documents (including the Test Suite, TCRL, ICS, and IXIT), and BQRB approval of the TCRL must occur on or before the Adoption Date.

BSTS will inform all members of the finalization and availability of the Voting Draft and the Adoption Date. The Adoption Date will be set no earlier than 60 days after members were notified of the BoD-approved 0.9/CR specification, unless the Member Review period is shortened by the BoD in accordance with the Bylaws, and at least 14 days after notice of the Adoption Date is provided to members in accordance with the Bylaws. For cases where multiple CRs have been integrated into a Voting Draft, the start of Member Review is the date on which members were notified of the most recent BoD- approved CR.

After notice of the Adoption Date is provided to members, BoD-approved corrections to typographical errors in the Voting Draft are permitted. The Specification Adoption timeline is illustrated in Figure 6.2.

6.2 Assigned numbers

Bluetooth SIG maintains a publicly available set of assigned numbers on the Bluetooth SIG Assigned Numbers website [7]. These assigned numbers are grouped in various number spaces (a related set of numbers with no duplicates). Numbers assigned may overlap with other assigned numbers in different number spaces, but no number within a number space is permitted to be reused. The various number spaces are defined in the specification that defines the usage of the assigned numbers.

After BARB approves the IOP test report, the WG will submit a request to BARB for the assignment of new numbers within the number space(s) required by the final specification. BARB will review the request and work with BSTS to determine the assigned numbers. Upon BARB approval, BSTS will schedule the publication of the assigned numbers to be made publicly available on the Bluetooth SIG Assigned Numbers website [7] within one week of the adoption of the specification.

Once the publication of assigned numbers on the Bluetooth SIG Assigned Numbers website or within an adopted specification occurs, the assigned numbers are intended to be immutable (to not change in either value or meaning). If they become unusable for some reason, they become reserved values and are not permitted to be reused.

6.3 Adoption/Approval Phase exit requirements

The Approval/Adoption Phase is complete when the BoD has adopted the specification and the following post-adoption activities have been completed:

• BSTS has made the final assigned numbers publicly available on the Bluetooth SIG website.
• BSTS has made the adopted specification publicly available on the Bluetooth SIG website
• BSTS has made all supporting documents (e.g., CSS, GSS, MDP) required for the relevant specification publicly available on the Bluetooth SIG website.
• BSTS has made the associated test documents available to all members on the Bluetooth SIG website.
• For specification enhancements, BSTS has made an informative change-tracked version of the previously-adopted specification version with all changes made by the newly-adopted version and made it available to all members on the Bluetooth SIG website.
• BSTS has enabled the qualification system.
• BSTS has notified all members the availability of the adopted specification and all supporting documents.

The Bluetooth SIG plans to complete these post-adoption activities within one week after adoption of the specification.

7. Specification Maintenance Phase

The Specification Maintenance Phase begins after the Adoption/Approval Phase is complete. If problems are found (e.g., wording ambiguities or technical errors) with the specification or associated test documents, they must be documented by creating errata proposals using the Bluetooth SIG Errata tool. Specification erratum proposals will be processed, categorized, and approved according to the EPD [3]. Test Suite erratum are processed and categorized according to the TSTO [5]. If there are any conflicts between the SMPD and either the EPD or TSTO, the SMPD takes precedence.

Specification erratum must only be used to correct technical or editorial errors in final adopted Bluetooth specifications. Addition of, changes to, and removal of functionality can only be made by means of the specification enhancement process defined earlier in this document.

7.1 Expedited erratum process

When an erratum is approved following the process defined in the EPD [3], the WG, BARB, or BSTS may recommend that it be considered urgent and should be expedited. When this occurs, BSTS along with the WG or BARB will present the recommendation to the BoD. The BoD will decide whether to accept or reject the recommendation. If the recommendation is accepted, BSTS will immediately incorporate the approved erratum into the erratum template [8] and work with the responsible WG to finalize an Expedited Errata Correction to be submitted to the WG for review and approval.

An overview of the expedited erratum process is illustrated in Figure 7.1.

The following documents must be completed and made available to the BoD prior to the Adoption Date:

• The BARB-approved draft Expedited Errata Correction.
• A description from the WG of any backward compatibility requirements (as described in Section 3.3.2) that have not been met and the justification for any exemptions.
• A list of remaining unresolved legal issues from legal review (if any).
• The BTI-approved Test Suite, ICS, and IXIT (if required by the erratum).
• The BTI- and BQRB-approved TCRL (if required by the erratum).
• A report completed by BSTS together with BTI regarding the status of tool readiness (e.g., PTS and other test tools, Bluetooth Launch Studio) including if any test cases in the TCRL are not supported by test tools and an explanation (if required by the erratum).
• An adoption checklist completed by BSTS and the WG showing that the deliverables in this section have all been completed.
• All other information requested by the BoD.

BSTS will work with the responsible WG to finalize the draft Expedited Errata Correction and create a version to submit to the responsible WG for review and approval.

The WG must submit the Expedited Errata Correction to BSTS for legal review. Upon completion of legal review, the WG and BSTS will agree on the feedback to be incorporated into the Expedited Errata Correction. If there are any unresolved legal comments from legal review on the Expedited Errata Correction, the WG Chair may request time on the BoD agenda to seek BoD input on resolution.

In parallel with legal review, the WG must submit the Expedited Errata Correction to BARB for review. Once the Expedited Errata Correction is submitted to BARB, BSTS will make it accessible for all members to review and notify all members of its availability. Upon completion of BARB review, the WG and BARB will agree on the feedback to be incorporated into the Expedited Errata Correction.

If the legal review results in any substantive changes, additional review by BARB may be required. Similarly, if the BARB review results in any substantive changes, BSTS will determine if an additional legal review of those changes is required. Upon completion of legal review and BARB review, BARB must either approve or reject the Expedited Errata Correction.

If any test documents require updating, BSTS will assist the WG in updating the test documents. Upon BTI approval of the test documents, BTI will assist in finalizing the TCRL and deliver the document to BQRB along with the associated ICS, IXIT, and Test Suite as applicable. BSTS will estimate the Adoption Date and provide it to BTI for use in the TCRL. BARB approval of the Expedited Errata Correction, BTI approval of all test documents (including the Test Suite, TCRL, ICS, and IXIT as applicable), and BQRB approval of the TCRL must occur on or before the Adoption Date.

BSTS will inform all members of the finalization and availability of the Expedited Errata Correction and the proposed Adoption Date. The Adoption Date will be set and notified to all members in accordance with the Bylaws [2] and the Adoption Date shall be at least 14 days after the notice is provided to members. After notice of the proposed Adoption Date is provided to members, the BoD may approve corrections of typographical errors in the Expedited Errata Correction without providing an additional notice of the proposed Adoption Date and waiting the required 14 days.

Bluetooth SIG will make the adopted Expedited Errata Correction publicly available and plans to do so within one week after adoption. Notification of its availability will be issued by BSTS to all members.

The expedited erratum process is complete when the BoD has adopted the Expedited Errata Correction and the following post-adoption activities have been completed:

• BSTS has made the adopted Expedited Errata Correction and associated test documents (if required by the erratum) publicly available on the Bluetooth SIG website.
• BSTS has enabled the qualification system (if required by the erratum).
• BSTS has notified all members of the availability of the adopted Expedited Errata Correction.

At the completion of these activities, the Errata Correction will be scheduled for integration into affected specifications either as part of a planned specification enhancement or in an upcoming maintenance release as described in Section 7.2.

7.2 Maintenance release process (.Z specifications)

On an approximately annual basis, BSTS will determine whether there are any approved errata (referred to as Errata Corrections) that are classified as Technical/High or Technical/Critical and that have yet to be incorporated into the text of any active specification (i.e., an adopted specification that has not been deprecated or withdrawn). See Appendix A for errata classification definitions. A Specification Owner (either the WG chartered to maintain the specification, or BARB if no WG is chartered to maintain the specification) may also request an earlier maintenance release of an active specification in which to incorporate any approved errata. Upon either BSTS determination, or the request of the Specification Owner, the maintenance release process will begin.

An overview of the maintenance release process is illustrated in Error! Reference source not found.

At the start of the maintenance release process, BSTS together with the Specification Owner, BARB, and BTI will develop and present a plan to the BoD for incorporating the Errata Corrections into the published specification version. The proposed plan must indicate whether Errata Corrections will be incorporated into a maintenance release of the specification (i.e., a .Z version) or a specification enhancement that is already in progress (i.e., an X.Y version). The proposed plan should take into account whether any new mandatory features have been added between versions of adopted specifications, the estimated time when the next specification enhancement is planned for adoption, and other factors.

Upon approval of a plan by the BoD, BSTS together with the Specification Owner will proceed to incorporate all Technical/Medium, Technical/High, and Technical/Critical Errata Corrections into a draft specification referred to as a “Maintenance Release Draft”. For Editorial or Technical/Low Errata Corrections, if the Errata Correction applies to more than one version of the specification, BSTS will, unless the BoD indicates otherwise, integrate those errata into only the most recent higher specification version at the next update of that version. No changes may be included in a Maintenance Release Draft other than incorporating Errata Corrections. Each Maintenance Release Draft must identify all incorporated Errata Corrections using change-tracking to show the proposed changes to the previously-adopted version of the published specification.

The timing of the proposed incorporation for each Errata Correction in a Maintenance Release Draft will depend upon the Test Suite impact: all Errata Corrections that do not have Test Suite impact may be incorporated right away, but Errata Corrections that impact on the Test Suite will be processed so that the timing coincides with an update to the TCRL.

BTI and BSTS will establish a deadline for inclusion of Errata Corrections with Test Suite impact in a Maintenance Release Draft. This deadline is typically 3 to 6 months before the planned approval date of the next major TCRL release. Errata Corrections with Test Suite impact that miss the deadline for inclusion will be processed as part of the next annual TCRL release. Therefore, unless an earlier release is requested, the maximum time for Technical/High or Technical/Critical Errata Corrections to be included in a specification update is approximately 15 to 18 months.

The Specification Owner must submit the Maintenance Release Draft that it has approved as final for legal review. The legal review will focus primarily on the changed parts of the specification. Upon completion of legal review, the Specification Owner and BSTS will agree on the feedback to be incorporated into the Maintenance Release Draft. If there are any unresolved legal comments from legal review on the Maintenance Release Draft, the Specification Owner may request time on the BoD agenda to seek BoD input on resolution.

In parallel with legal review, the Specification owner must submit the Maintenance Release Draft to BARB for review. Once the Maintenance Release Draft is submitted to BARB, BSTS will make it accessible for all members to review and notify all members of its availability. Upon completion of BARB review, the Specification Owner and BARB will agree on the feedback to be incorporated into the draft specification.

If the legal review results in any substantive changes, additional review by BARB may be required. Similarly, if the BARB review results in any substantive changes, BSTS will determine if an additional legal review of those changes is required. Upon completion of legal review and BARB review, BARB must either approve or reject the Maintenance Release Draft. If approved by BARB, this becomes the Voting Draft.

For Errata Corrections that impact test documents, and where the corresponding test errata will be processed in time for the upcoming TCRL release, BSTS will work with the Specification Owner and BTI to update the test documents. Upon BTI approval of the test documents, BSTS will estimate the Adoption Date and provide the proposed Adoption Date to BTI for use in the TCRL. BTI will deliver the TCRL to BQRB along with the associated ICS, IXIT, and Test Suite as applicable. BARB approval of the specification, BTI approval of all test documents (including the Test Suite, TCRL, ICS, and IXIT as applicable), and BQRB approval of the TCRL must occur on or before the Adoption Date.

BSTS will inform all members of the finalization and availability of the Voting Draft and the proposed Adoption Date. The Adoption Date will be set and notified to all members in accordance with the Bylaws and the Adoption Date shall be at least 14 days after notice of the notice is provided to members. After notice of the proposed Adoption Date is provided to members, the BoD may approve corrections of typographical errors in the Voting Draft without providing an additional notice of a proposed Adoption Date and waiting the required 14 days.

The following documents must be completed and made available to the BoD prior to the Adoption Date:

• The Voting Draft
• A change-tracked version of the Voting Draft showing all changes to the adopted version of the specification that has the same X.Y value (e.g., if the Voting Draft is proposed as version 1.4.2, the changes will be tracked against the 1.4.1 version of the specification)
• A recommendation from the Specification Owner for the deprecation or withdrawal of any previous version(s) of the adopted specification along with a justification
• A list of remaining unresolved legal issues from legal review (if any)
• The BTI-approved Test Suite, ICS, and IXIT (if required by the maintenance release)
• The BTI- and BQRB-approved TCRL (if required by the maintenance release)
• A report completed by BSTS together with BTI regarding the status of tool readiness (e.g., PTS and other test tools, Bluetooth Launch Studio) including any test cases in the TCRL that are not supported by test tools, and explanation (if required by the maintenance release)
• An adoption checklist completed by BSTS and the Specification Owner showing that the deliverables in this section have all been completed
• All other information requested by the BoD

The maintenance release process is complete when the BoD has adopted the Voting Draft and the following post-adoption activities have been completed:

• BSTS has made the adopted specification and associated test documents (if required by the maintenance release) publicly available on the Bluetooth SIG website.
• BSTS has made an informative change-tracked version of the previously-adopted specification version with all changes incorporated in the newly adopted version available to all members on the Bluetooth SIG website.
• BSTS has enabled the qualification system.
• BSTS has notified all members of the availability of the adopted specification and supporting documents.

The Bluetooth SIG plans to complete these post-adoption activities within one week after adoption of the specification.

At the completion of these activities, the specification remains in the Specification Maintenance phase until the specification is deprecated or withdrawn, as defined in Section 8.

8. Specification End-of-Life Phase

Specifications may be deprecated or withdrawn when they are superseded by newer versions, determined to be technically insufficient, or for other reasons. Deprecated and withdrawn specifications are archived and no longer updated. Deprecated and withdrawn specifications are treated differently in the Bluetooth Qualification Program.

Any member, group, or committee may submit recommendations to deprecate or withdraw a specification along with an associated timeline to BSTS (via email to

specification.manager@bluetooth.com) at any time. BSTS may also recommend deprecation or withdrawal of a specification and associated timeline. BSTS will refer the recommendation to BARB and the group or committee responsible for maintaining the specification for review and feedback.

BARB and the group or committee responsible will evaluate recommendations to deprecate or withdraw a specification and consider the following (non- exhaustive) criteria:

• Is there functionality in a previous version of the specification that is obsolete or should not be used?
• Has new mandatory functionality been added to later versions?
• Are there deficiencies in earlier versions that impair operation or interoperability that have been corrected in later versions and are needed to advance existing user scenarios?
• Is there additional functionality in later versions needed to advance new user scenarios?
• Is there improved usability and interoperability in later versions?
• Are there security improvements in later versions?

BARB and the group or committee responsible may propose an alternative recommendation.

After receiving feedback from BARB or the group or committee responsible for maintaining the specification, BSTS will submit the recommendation(s) and feedback to the BoD for consideration. The BoD may invite the group or committee that is responsible for maintaining the affected specifications to meet and discuss the recommendations. The BoD will consider recommendations and feedback and may agree with or modify the proposal. The BoD will request that BSTS notify all members of the proposals to deprecate or withdraw specification(s) and associated timeline(s) for a 30-day review period to allow all members to provide additional feedback prior to making its final decision.

The BoD will consider the feedback received from members. Once the BoD approves the deprecation or withdrawal of a specification, BSTS will notify all members of the decision and associated timeline.

8.1 Deprecation

Once a specification is deprecated, the following will occur:

• The specification will no longer be updated.
• The responsible WG will review all outstanding errata written against the deprecated specification to determine if they apply to other specifications. Errata may be rejected in the errata system and rewritten against the applicable specification(s).
• The WG or BSTS will create errata to update any necessary references to deprecated specifications in other specifications.
• BTI will update the applicable test documents to indicate the deprecation of the specification.
• BSTS will update the Bluetooth SIG website with guidance regarding alternative specification(s) to use.
• New errata can no longer be submitted against a deprecated specification.
• The specification will not be referenced in any future specifications.
• BSTS will archive a version of the specification marked as deprecated for members to access for historical purposes.

8.2 Withdrawal

Once a specification is withdrawn, in addition to the steps that apply for deprecation, the following will occur:

• BTI will update the applicable test documents to indicate the withdrawal of the specification.
• BSTS will update the Bluetooth SIG website with guidance regarding alternative specification(s) to use.
• BSTS will archive a version of the specification marked as withdrawn for members to access for historical purposes.

The BoD may choose to withdraw a specification immediately without first deprecating the specification.

9. White paper process

White papers are created for informational purposes only. The following white paper process applies to all Bluetooth WGs, EGs, SGs, and committees. This section does not apply to informational documents for use only within the Bluetooth SIG.

This process is illustrated in Figure 9.1 below.

Before any group or committee begins work on a white paper they intend to be published by Bluetooth SIG, the group or committee will prepare both a proposed charter update clearly defining the proposed contents of the white paper and a white paper proposal presentation.

The white paper proposal presentation must include at minimum:

• The need for the white paper
• A summary of the proposed contents of the white paper
• An explanation for why the content is not recommended to be included as part of a specification
• The intended audience
• Any maintenance plans (i.e., the estimated time before the next release of this white paper may be necessary)
• Recommendations for how to handle previous versions of the white paper, if any (e.g., archiving)

The charter update and white paper proposal presentation must be submitted for BARB review. Upon review and approval of the charter update by BARB, BSTS will submit the charter update to the BoD for approval along with the supporting white paper proposal presentation.

If the BoD approves the charter update, the group or committee may proceed with developing the white paper.

When the group or committee has completed the development of the white paper, BSTS will perform an editorial review for consistency with the Bluetooth Drafting Guidelines.

After resolution of BSTS comments, the group must submit the white paper to BSTS for legal review. Upon completion of legal review, the group and BSTS will agree on the feedback to be incorporated into the white paper. If there are any unresolved legal comments from legal review on the white paper, the group chair may request time on the BoD agenda to seek BoD input on resolution.

In parallel with legal review, the group must submit the white paper to BARB for review. As part of their review, BARB may recommend whether any part of the white paper should be removed from the white paper and incorporated into a specification following the process in Section 3. BARB may also decide to submit the white paper to other groups or committees for review. Upon completion of BARB review, the group and BARB will agree on the feedback to be incorporated into the white paper.

If the legal review results in any substantive changes, additional review by BARB may be required. Similarly, if the BARB review results in any substantive changes, BSTS will determine if an additional legal review of those changes is required. Upon completion of legal review and BARB review, BARB must either approve or reject white paper.

After BARB approves the white paper, the BARB-approved white paper will be presented by the authoring group or committee to the BoD for approval.

The white paper process is complete when the BoD has approved the white paper and the following post-approval activities have been completed:

• BSTS has made the approved white paper publicly available on the Bluetooth SIG website.
• BSTS notifies all members of the approved white paper.
• If the white paper is an enhancement of an existing white paper, BSTS will archive a version of the white paper for members to access for historical purposes.

The Bluetooth SIG plans to complete the post-approval activities within one week after approval of the white paper.

10. References

Referenced Bluetooth documents are available from the Bluetooth website http://www.bluetooth.com.

1. Bluetooth Drafting Guidelines (available on the Working Group Templates & Documents page, at https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
2. Bylaws of the Bluetooth SIG, Inc. (available on the Governing Documents page, at https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
3. Bluetooth Specification Errata Process document (available on the Working Group Templates & Documents page, at https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
4. Working Group Process Document (available on the Working Group Templates & Documents page, at https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
5. Test Strategy and Terminology Overview document (available on the Qualification Test Requirements page, at https://www.bluetooth.com/specifications/qualification-test-requirements)
6. BTI Specification Review Process Checklist (available on the Working Group Templates & Documents page, at https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
7. Bluetooth SIG Assigned Numbers (https://www.bluetooth.com/specifications/assigned-numbers)
8. Working Group Templates and Documents (available on the Working Group Templates & Documents page, at https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
9. GATT Specification Supplement (GSS) (available on the GATT Specifications page, at https://www.bluetooth.com/specifications/gatt)
10. Submit an Idea for a new Specification https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Acronyms and abbreviations

Table A: Acronyms and abbreviations

Appendix A – Erratum severity classification

This appendix summarizes severity classification guidelines for a specification erratum. This table will be added to a future revision of the EPD, and then this section will be deleted.

Read More About This Manual & Download PDF:

Specification Management Process Document (SMPD) – Optimized PDF
Specification Management Process Document (SMPD) – Original PDF

Questions about your Manual? Post in the comments!

Read User Manual Online (PDF format)

Download This Manual (PDF format)

Download this manual  >>