仕様管理プロセスドキュメント（SMPD）

このドキュメントは、タイトルや内容にかかわらず、Bluetooth SIG Inc. (以下「Bluetooth SIG」) およびそのメンバーが Bluetooth 特許/著作権ライセンス契約および Bluetooth 商標ライセンス契約に基づいて付与するライセンスの対象となる Bluetooth 仕様ではありません。

この文書は「現状のまま」提供され、BLUETOOTH SIG、そのメンバー、およびその関連会社は、商品性、所有権、非侵害、特定目的への適合性、この文書の内容に誤りがないことに対する保証を含め、明示または黙示を問わず、いかなる表明または保証も行いません。

法律で禁じられていない限り、BLUETOOTH SIG、そのメンバー、およびその関連会社は、本書の使用および本書に含まれるあらゆる情報に起因または関連するすべての責任（収益、利益、データまたはプログラムの損失、事業中断、または特別、間接、結果的、偶発的または懲罰的損害を含む）を、原因の如何を問わず、また責任の理論にかかわらず、また BLUETOOTH SIG、そのメンバー、またはその関連会社がそのような損害の可能性について知らされていた場合であっても、一切の責任を負いません。

このドキュメントは Bluetooth SIG の所有物です。このドキュメントには Bluetooth SIG およびそのメンバーの知的財産である主題が含まれているか、または取り上げられている場合があります。このドキュメントの提供は、Bluetooth SIG またはそのメンバーの知的財産に対するライセンスを付与するものではありません。

この文書は予告なく変更されることがあります。

1. はじめに

仕様管理プロセス文書（SMPD）は、仕様の作成者と再設計者が行うプロセスを記述します。view開発者が新しい仕様を開発し、既存の仕様を強化する（つまり、採用された仕様の機能の追加や削除、特定の機能の変更）、採用された仕様の維持、採用された仕様の寿命の管理を行うために従わなければならない手順について説明します。さらに、このドキュメントでは、新しい仕様の作成、再作成、既存の仕様の拡張（つまり、採用された仕様の機能の追加や削除、特定の機能の変更）、採用された仕様の維持、採用された仕様の寿命の管理のプロセスについて説明します。viewホワイトペーパーの作成、承認を行います。

新しい仕様を開発することと既存の仕様を強化することの間には、タスクの範囲に固有の違いがあるため、仕様開発プロセスに違いがあります。このドキュメントでは、これらの違いについて詳しく説明されています。

仕様開発プロセスには以下が含まれます。

機能要件を定義するための要件フェーズ（セクション3で説明）

開発フェーズ（セクション4で説明）では、view 仕様
相互運用性プロトタイプ（IOP）テストによって仕様を検証する検証フェーズ（セクション5で説明）

採用/承認フェーズ（セクション6で説明）では、Bluetooth SIG理事会（BoD）に仕様を提示して採用/承認を求めます。

仕様エラッタプロセス文書（EPD）[3]は、仕様エラッタプロセス文書の提案と再提案のプロセスについて説明しています。view仕様の正誤表を作成し、採用された仕様に対する正誤表修正（定款[2]で定義）として承認する。特に明記されていない限り、このSMPDにおける正誤表への言及はすべて仕様の正誤表を意味する。

1.1 優先順位

Bluetooth SIG, Inc. の定款（定款）および会員契約 [2] は、これらの文書と SMPD の矛盾する内容に優先します。この文書の内容にかかわらず、取締役会は、たとえそれらの行動や決定がこの文書の内容に従わない、または矛盾する場合でも、行動を起こし決定を下す最終的な裁量権と権限を保持し、この文書のいかなる内容も取締役会の独立した権限と裁量を制限または制約するものではありません。

SMPD のテキストと図の間に矛盾がある場合は、テキストが優先されます。

1.2 参照されたグループと委員会

この文書では、研究グループ (SG)、専門家グループ (EG)、ワーキンググループ (WG) などのグループが参照されています。WG には、WG に報告するサブグループが存在する場合もあります。同様に、この文書では、Bluetooth アーキテクチャ委員会などの委員会が参照されています。view 委員会（BARB）、Bluetoothテストと相互運用性（BTI）、およびBluetooth認定再view 理事会 (BQRB)。このドキュメントでは、Bluetooth SIG 技術スタッフ (BSTS) および理事会についても言及しています。

1.3 委員会についてviewおよび承認

委員会はview は再view 委員会のメンバー（通常は3人）が、指定された期間（通常は2～3週間）内にフィードバックを提供するために実施されますが、view 時間は、資料の長さや複雑さ、委員会内の他の優先事項によって変わる可能性があります。view そして、再調査を実施する委員会view それぞれが再契約の期間について合意するviewグループと委員会のメンバーは、Bluetooth SIGツールを使用して、再開始と終了を通知および記録します。view. グループは、通常、委員会からのフィードバックを受け取った時点で処理します。委員会がview 時間が切れると、グループは委員会のフィードバックへの対応を完了し、遅れて到着したフィードバックも考慮する必要があります。view 資料はその後委員会の承認を受ける必要がある可能性があることを念頭に置いてフィードバックしてください。

委員会の承認は、ワーキンググループプロセス文書[4]に従って委員会メンバーの投票によって得られます。

1.4 会員への通知と資料の閲覧可能性

この文書に従ってメンバーに提供されるすべての通知は、定期的な技術更新など、電子メールで提供される場合があります。すべてのメンバーに提供される通知は、すべてのアクティブメンバー (メンバーシップが一時停止、終了、または取り消されていないメンバー) に送信されます。通知が電子メールで送信される場合、メンバー企業のメンバーシップアカウントに登録し、電子メール通知の受信をオプトアウトしていない各個人の最新の電子メールアドレス (Bluetooth SIG のその時点の最新記録に反映されているもの) に送信されます。この文書のいかなる内容も、定款または Bluetooth SIG とメンバー間のその他の契約に基づく通知の提供に関する Bluetooth SIG の義務または要件を変更するものではありません。

この文書が webすべてのメンバーがアクセスできるサイト。これは、アクティブなBluetooth SIGアカウントを持つ個人がアクセスできることを意味します。アクティブなアカウントを持っていないメンバーは、Bluetooth SIGを通じてアカウントを作成できます。 webサイト。

1.5 テンプレート

この SMPD で参照される各ドキュメントタイプ (仕様、ホワイトペーパー、テストドキュメントなど) について、Bluetooth SIG はテンプレートを提供しています。このテンプレートは、この SMPD に従って作成される各ドキュメントの基礎として使用する必要があります。正しいテンプレートを使用しないと、ドキュメントが承認されない場合があります。テンプレートは Bluetooth SIG で入手できます。 webサイト[8]。

1.6 仕様の種類

Bluetooth SIG仕様にはいくつかの種類があります。階層的に、すべての仕様はBluetoothコア仕様に依存しています。従来のプロ仕様などの仕様は、files; 従来のプロトコル; GATTベースのプロトコルfile、GATTベースのサービス、GATTベースのプロトコルはすべてコア仕様内の機能に依存しています。メッシュモデル仕様などの他の仕様は、メッシュプロ仕様に依存しています。file コア仕様に依存する仕様。

コア仕様補足（CSS）仕様は、データ型、データ形式、および共通プロパティを定義します。file コア仕様およびその他の仕様で使用されるサービスエラーコードであり、それ自体では動作を定義しません。

GATT仕様補足（GSS）仕様は、Proで使用される特性と記述子のフォーマットを定義します。fileおよびサービスであり、それ自体はいかなる動作も定義しません。
メッシュデバイスプロパティ（MDP）仕様は、メッシュプロで使用されるメッシュプロパティを定義します。file およびメッシュモデルの仕様であり、それ自体は動作を定義しません。

2。オーバーview

このセクションでは、view プロセスの一部であり、すべての詳細を網羅するものではありません。

図 2.1 は、仕様管理プロセスを構成する XNUMX つの主要フェーズを示しています。

最初の 3 つのフェーズは、仕様開発プロセス中に発生し、要件フェーズ (セクション 4)、開発フェーズ (セクション 5)、検証フェーズ (セクション 6)、および採用/承認フェーズ (セクション 7) で構成されます。その後に、採用後の 8 つのフェーズ、仕様保守フェーズ (セクション XNUMX) と仕様終了フェーズ (セクション XNUMX) が続きます。

図 2.2 は、仕様開発プロセス内の XNUMX つのフェーズの詳細を示しています。灰色のボックスは、各フェーズの主な成果物を示しています。オレンジ色のボックスは、プロセスのマイルストーンをまとめたものです。

要件フェーズ (セクション 3 で説明) では、新しい作業を開始するための提案 (新規作業提案 (NWP)) によって、新しい作業が進行した場合に有効になるユーザーシナリオが定義され、仕様開発プロセスが開始されます。NWP が承認されると、割り当てられたグループが機能要件ドキュメント (FRD) を作成します。FRD が承認され、グループに割り当てられると、開発フェーズが開始されます。

開発フェーズ（セクション4で説明）では、仕様開発は一連のステップを経て進行します。tages (0.5/DIPD から 0.9/CR) が最終的に仕様の完全な草案にまとめられます。0.9/CR 仕様はすべてのメンバーに公開され、その後、仕様の承認を検討する理事会に提出されます。承認されると、検証フェーズが開始されます。

仕様策定の検証フェーズ（セクション5で説明）では、理事会が承認した0.9/CR仕様が、すべてのメンバーに公開され、view 検証し、メンバーの再view が開始されます。検証は、メンバーが構築したプロトタイプ間の相互運用性 (IOP) テストによって行われます。IOP テストが完了し (仕様で必要な場合)、BARB が IOP テストレポートを承認すると、採用/承認フェーズが開始されます。

採用/承認フェーズ（セクション 6 で説明）では、仕様と関連テストドキュメントが完成し、BARB、BQRB、および BTI の承認が得られ、最終的な仕様パッケージが理事会に提出され、理事会で仕様の採用（最終承認）が検討されます。

仕様は、以前のフェーズまたはtage 大幅な変更があった場合。場合によっては、セクション 4.4 で説明されているように、フェーズの一部を免除することも可能です。

仕様メンテナンスフェーズ (セクション 7 で説明) は、仕様が理事会によって採用された後に開始されます。このフェーズでは、採用された仕様で見つかった潜在的なエラーが報告および評価され、(必要な場合は) 仕様に対してエラッタ修正が行われます。仕様メンテナンスフェーズは、仕様が非推奨または撤回されるまで継続されます (次の段落の仕様サポート終了フェーズを参照)。

仕様のサポート終了フェーズ (セクション 8 で説明) では、採用された仕様を非推奨にしたり撤回したりするプロセスについて説明します。

3. 要件フェーズ

要件フェーズは、NWP (3.1 つ以上のユーザーシナリオで作業を開始する意思を表明) から、または希望する新規作業がすでに WG 憲章でカバーされていると判断された後に開始されます。WG が、すでに WG 憲章の範囲内にあると思われる新規作業を開始する場合、WG はセクション 3.2 で定義されたプロセスに従って、FRD の開発に直接進む必要があります。その他のすべての作業項目については、WG はセクション 3.1 で定義されたプロセスに従う必要があります。FRD は、開発フェーズで仕様を作成するために使用される機能要件の範囲を定義します。要件フェーズは、図 XNUMX に示されています。

3.1 WG憲章でカバーされる新しい作業

WG が新しい作業を開始することを希望し、追加したい機能がすでに WG 憲章の範囲内であると合理的に判断できる場合、WG は BARB に直ちに通知すれば FRD の作業を開始できます。WG は BARB への通知に、提案された新しい作業の説明と、新しい作業を開始する権限を与える文言が強調表示された WG 憲章のコピーを含めます。

BARB が WG の分析を拒否した場合、WG は FRD の作業を中止し、セクション 3.2 で概説されている NWP プロセスを進める必要があります。BARB が WG の分析を承認した場合、WG は直ちに BSTS に通知し (specification.manager@bluetooth.com への電子メール経由)、BSTS は次の BoD 議題に項目を追加します。

WG は、BSTS への通知に、BARB に提供したのと同じ情報を含めます。BoD が WG の分析を拒否した場合、WG は FRD の作業を中止し、セクション 3.2 で概説されている NWP プロセスを進めなければなりません。BoD が WG の分析を承認した場合、WG はセクション 3.3 で概説されているように FRD の作業を続行できます。

3.2 新規作業提案（NWP）

どのメンバー、WG、SG、EGもNWPを作成して提出することができます（Bluetooth SIG経由）。 webサイト[10]）。NWPには、[8]で提供されている公式テンプレートを使用して、少なくとも以下の情報を含める必要があります。

ユーザーシナリオ
FRDの開発に対するメンバーのコミットメントと、その分野（例：貢献者、著者、レビューviewえーと、プロトタイピング
FRD活動のリーダーシップの提案
FRD作業のグループ割り当て案
主著者のメールアドレス

注記： NWPプロセスに関するガイダンスはBluetooth SIGで入手可能です。 webサイト[10]。

BSTS は、NWP の開発中に次のタスクを実行します。

著者に受領確認（通常は受領後 7 暦日以内）を提供し、次の手順の概要を説明します。
必要に応じて、著者と協力して NWP が明確かつ完全なものになるようにします。このためには、NWP を複数回繰り返す必要がある場合があります。
NWPに採用されたBluetooth仕様の誤りに関する記述が含まれている場合は、作成者と協力して file エラッタシステムへのエントリ。
NWP がすでに進行中または完了している作業と重複している可能性があることが判明した場合は、他の作業の著者に通知して評価してもらいます。
NWPをNWPに投稿する webすべてのメンバーがアクセスできるサイト。

NWPが再利用可能であることを全メンバーに通知するview FRD の開発にさらなる加盟国の関与が必要かどうか。

メンバーは著者に連絡して、NWP に関する質問をしたり、フィードバックを提供したりできます。

NWP が理事会承認の候補となるには、少なくとも 3.3 社の会員企業が FRD の完成に参加することを約束する必要があり、また少なくとも XNUMX 社の会員企業が準会員またはプロモーター会員である必要があります。NWP が理事会で承認されると、理事会は NWP を既存の全会員 WG サブグループまたは SG に割り当てて、FRD の作業を行います (セクション XNUMX で説明)。適切な WG サブグループまたは SG が存在しない場合は、作成できます。

十分なメンバーのコミットメントがある NWP の場合、BSTS は次の追加タスクを実行します。

NWP が理事会によって承認される予定の少なくとも 13 日前に、BARB と、NWP の割り当てが推奨されるグループに、保留中の NWP 承認について通知します。これは、提案されたグループ、NWP が既存の作業で既にカバーされているかどうかなどの領域でフィードバックを得る機会を提供するために行われます。
完成したNWPを理事会に提出します。

NWP がグループに所属していないメンバーによって提出された場合は、メンバーの 1 人が NWP を理事会に提出するように手配します。

NWP がグループによって提出される場合は、グループ議長が NWP を理事会に提出するように手配します。
BARB 議長と、NWP の割り当てが推奨されるグループの議長を理事会会議に招待します。
NWP が理事会によって承認され、割り当てられた場合は、割り当てられたグループ、作成者、NWP で対応する FRD の開発に取り組んでいると特定されたメンバー、および NWP がグループによって提案された場合は、そのグループに結果と次のステップを通知します。

NWPが理事会で承認されたら、NWPのステータスを更新します。 webサイト。

いかなるNWPも取締役会の裁量で拒否される可能性がある。例えば、amp例えば、リソースの制限により、作業がすでに完全に完了している場合、作業がBluetooth SIGの管理文書（アプリケーションプログラミングインターフェース（API）など）[2]の範囲外である場合、または提案された作業が filed は正誤表として提出されます。NWP が拒否された場合、BSTS は作成者、NWP で対応する FRD の開発に取り組んでいると特定されたメンバー、および NWP がグループによって提案されている場合はそのグループに通知します。通知には拒否の理由が含まれます。作成者、コミットしたメンバー、またはグループは、拒否に対する異議申し立てを行うために、理事会の議題に時間を割くよう要求できます。

メンバーまたはグループが採用された仕様から機能を削除することを提案する場合、グループまたはメンバーは NWP を準備する必要があります。NWP には、テストケースへの影響の分析など、削除が下位互換性と相互運用性に与える影響の分析を含める必要があります。

NWP は、CSS、GSS、または MDP 仕様の拡張には必要ありません。通常、CSS、GSS、または MDP 仕様の更新は、独自の NWP を持つ他の仕様の更新によって発生します。

3.3 機能要件ドキュメント（FRD）

FRDはユーザーシナリオを実現するための機能要件を定義します。FRDには、[8]で提供されている公式テンプレートを使用して、少なくとも以下の情報が含まれている必要があります。

ユーザーシナリオ
ユーザーシナリオに基づく機能要件
結果として得られる仕様を開発するためのメンバーのコミットメント
想定される役割に対するメンバーによるオプションのプロトタイプサポート
結果として得られる仕様を開発するための推奨WG

FRD開発

FRD は、BSTS の編集サポートを受けて、割り当てられた全メンバー WG サブグループまたは SG メンバーによって作成されます。FRD 開発への参加に関心のあるメンバーは誰でもグループに参加できます。

FRD は、少なくとも 2 社 (3 社が推奨されます) のアソシエイトレベルまたはプロモーターレベルのメンバー企業が、最終的な仕様の開発に参加することを表明する必要があります。FRD を提出する WG または SG は、FRD で特定された対象業界セグメントを代表するグループメンバー企業から幅広いサポートを得るよう努める必要があります。

FRDで提案される新機能は、可能な限り多くのトランスポートと既存のデバイスでサポート可能である必要があります。これには、たとえば、ample、GATTベースのプロをサポートfileおよびサービスは、基本レート/拡張データレート（BR/EDR）トランスポートとBluetooth Low Energy（LE）トランスポートの両方でサポートされます。新しい機能にトランスポートに対する十分なメンバーサポートがない場合、たとえばampトランスポートの使用を定義するメンバーのコミットメントが不足しているか、1 つ以上のロールに対して IOP テストプラットフォームの数が不足している可能性があるため、そのトランスポートのサポートは FRD から除外される可能性があります。

他に正当な理由がない限り、新しい機能、プロfileおよびサービスは、セクション 3.3.2 で説明されている下位互換性の要件に準拠している必要があります。

WGまたはSGはFRDをBARBに提出して再審査を受けなければならない。view および承認。BARB は、エンジニアリングの判断に基づいて FRD を承認または拒否する必要があります。BARB によって承認された場合、FRD はすべてのメンバーに提供され、BSTS からその利用可能性に関する通知が発行されます。

FRD は、CSS、GSS、または MDP 仕様の拡張には必要ありません。通常、CSS、GSS、または MDP 仕様の更新は、独自の FRD を持つ他の仕様の更新によって発生します。

下位互換性の要件

BR/EDR の下位互換性

BR/EDR 操作の場合、下位互換性の要件は、Bluetooth コア仕様 v1.1 以降の BR/EDR 部分との相互運用性として定義されます。

Bluetooth Low Energyの下位互換性

LE 操作の場合、下位互換性の要件は、Bluetooth コア仕様 v4.0 以降の LE 部分との相互運用性として定義されます。

コア仕様以外の仕様に対する下位互換性

Bluetoothコア仕様以外の仕様の場合、特定のバージョンの下位互換性は、同じメジャーバージョン番号を持つすべての以前のバージョンと維持される必要があります。例：ampたとえば、バージョン 1.3 はバージョン 1.2、1.1、および 1.0 と互換性がある必要がありますが、バージョン 2.0 はバージョン 1.0、1.1、1.2、および 1.3 と互換性がない可能性があります。コア仕様のメジャーバージョン番号が増加しても、以前のバージョンとの下位互換性がなくなるわけではないことに注意してください。

下位互換性要件の免除

WGまたはSGは、正当な理由があれば、特定の機能を後方互換性の要件から除外することを提案することができる。例えば、ampたとえば、機能の市場採用率が低い場合や、相互運用性の問題により、機能を変更するよりも機能を削除または置き換えた方がよい場合などです。 WG または SG は、FRD に下位互換性の免除を含める必要があります。これは、FRD の承認時に BARB によって承認されます。 BARB によって承認された免除は、0.9/CR S で BoD に承認のために提示されます。tage.

3.4 ワーキンググループ憲章

BARB が既存の WG に割り当てることが提案されている FRD を承認する場合、その WG は、新しい機能を範囲に追加するために、憲章の更新案を準備する必要があります (WG 憲章の更新は不要であるという WG の分析を BoD が以前に承認していた場合を除く)。ただし、BARB が新しい WG に割り当てることが提案されている FRD を承認する場合、BARB と、FRD で概説されている機能の開発に関心のあるメンバーは、憲章の範囲に新しい機能を含めた新しい WG の憲章の草案を準備する必要があります。

新しいまたは更新されたWG憲章が準備されたら、再審査のためにBARBに提出する必要があります。view 承認。BARB が憲章を承認すると、新しい WG 憲章または更新された WG 憲章の草案が理事会に提出され、承認されます。

理事会が憲章を承認すると、理事会によって仕様開発作業が割り当てられた WG は、FRD に必要な更新や説明が必要な場合に備えて、FRD を作成したグループと緊密に連携する必要があります。開発フェーズ中に FRD の更新が必要な場合は、セクション 3.3 およびこのセクションに概説されているプロセスに従う必要があります。ただし、仕様開発は FRD および WG 憲章の更新と並行して行われる場合があります。

3.5 要件フェーズ終了要件

FRD に必要な範囲を含む WG 憲章が理事会によって確認または承認され、次の要件が満たされると、要件フェーズが完了し、開発フェーズが開始されます。

NWP は取締役会によって承認されているか、または取締役会が NWP は不要であると同意しています。
FRD および対応する WG 憲章は BARB によって承認されています。

4. 開発フェーズ

開発フェーズでは、割り当てられた WG が新しい仕様を作成したり、既存の仕様を拡張したりします。FRD は、新しい Bluetooth 仕様または拡張 Bluetooth 仕様の要件を定義します。FRD の要件に合理的に関連しない機能は、仕様に含められません。目標は、開発フェーズの終了時に、検証フェーズ (セクション 0.9 で説明) の準備が整った 5/CR 仕様を作成することです。
開発フェーズでは、仕様（または仕様拡張）は3つの段階を経て進みます。tages。

新しい仕様では、3つのtagesは次のとおりです:

0.5年tage
0.7年tage
0.9年tage

仕様強化のために、3つのstagesは次のとおりです:

改善提案書（DIPD）Stage
最終改善提案書（FIPD）Stage
変更リクエスト (CR) Stage

各stag詳細は、以下のサブセクションで説明します。図4.1は、WGが各段階で準備するさまざまな文書を示しています。tage.

図4.1：以上view 仕様のtag開発フェーズ中に発生する問題

仕様開発プロセス全体を通じて BARB の役割は、WG にアドバイスと技術支援を提供することです。WG は、仕様開発と仕様で使用されるアーキテクチャコンセプトに関する技術アドバイスをいつでも BARB に要求できます。WG は、より複雑なアーキテクチャ上の考慮事項がある機能については、特に BARB から早期にフィードバックを求めることが推奨されます。

4.1 0.5/DIPD Stage

0.5/DIPD Sの間tage、WGは[8]で提供されている公式テンプレートを使用して以下を開発します。

新しい仕様の場合、0.5 仕様のドラフトには、少なくとも以下の情報が含まれている必要があります。

FRDに記載されている要件を満たすアーキテクチャ
プロトコルの場合、サービスアクセスポイントが定義される
サービス、公開されたデータ、動作について
プロ向けfileプロトコルが識別され、機能が指定された

2. 仕様の拡張の場合、DIPD の草案には、少なくとも以下の情報が含まれている必要があります。

背景： 作業範囲、作業の指針となる目的、そしてこの特定の提案が作業範囲にどのように適合するか

以上view 提案の: DIPD によって提供される拡張機能 (柔軟性の向上、パフォーマンスの向上など) の概要。新しい機能が現在の仕様バージョンにどのように適合するかについての明確な説明が含まれます。WG が複数の提案を評価した場合は、BARB が適切な提案の選択に十分なデューデリジェンスが行われたかどうかを判断できるように、これらの提案を含める必要があります。
要件の範囲: 提案で示された機能要件の範囲の概要。関連するFRDで示された適切なシステム要件と使用シナリオを参照します。
問題の定義: 提案によって解決される問題の説明

選択基準: 選択プロセスの指針となった関連する評価指標からの選択/パフォーマンス基準に関する声明
選択の正当性: 提案間の選択を正当化し、トレードオフを明らかにする評価指標の検討
説明： 機能と拡張プロトコルの説明。このセクションは、関連するサブセクションを追加することで、さまざまなニーズに適応できます。

3. テスト戦略: Bluetooth 認定プログラムの一部としてテストされる（またはテストされない）ことが提案されている機能と、その機能がテストされる方法（下位テスターまたは上位テスターへの期待、テストが適合性テストまたは相互運用性テスト、あるいはその両方の組み合わせとして分類されるかどうかなど）の説明。これは、別の文書または 0.5/DIPD 仕様内の別のセクションにある場合があります。テスト戦略で使用される規則は、テスト戦略および用語集に記載されています。view 文書（TSTO）[5]。

この文書の主な対象者はtagWGメンバーとBARBは、view アーキテクチャの提案と要件の範囲、そしてBTIはviewテスト戦略です。ほとんどの場合、このドキュメントはtag最終仕様に盛り込む予定のテキストを含めることを意図したものではありません。

BSTSは再view すべての文書をBluetoothドラフトガイドライン[1]と整合させ、WGが取り組むべき問題を特定する必要がある。BARBはview 0.5/DIPD仕様。仕様強化のために、BARBはview DIPDのセクション3.3.2に記載されている下位互換性要件に準拠していることを確認する必要があります。BTIはview テスト戦略。

BARBは、エンジニアリングの判断に基づいて0.5/DIPD仕様を承認するか拒否するかを決定する必要があります。BARBによって承認された場合、0.5/DIPD仕様はBluetooth SIGで利用可能になります。 webこのサイトは、すべてのアソシエイトおよびプロモーターメンバーに公開され、その利用可能性に関する通知はBSTSから発行されます。0.5/DIPD Stage、テスト戦略の承認は必要ありません。
0.5/DIPD StagCSS、GSS、またはMDP仕様の拡張にはeは必要ありません。

0.5/DIPD Stag退出要件

0.5/DIPD Stageは完全であり、0.7/FIPD Stage は、次の終了要件が満たされたときに開始されます。

BSTSは再view0.5/DIPD 仕様とテスト戦略を実行します。

BARB は 0.5/DIPD 仕様を承認しました。
BTIは再view テスト戦略の。
BSTS は、承認された 0.5/DIPD 仕様をすべての準会員およびプロモーター会員に公開しました。

4.2 0.7/FIPD Stage

0.7/FIPD Sの間tage、WGは[8]で提供されている公式テンプレートを使用して以下を開発します。

新しい仕様の場合、0.7 仕様のドラフトには、少なくとも以下の情報が含まれている必要があります。

BARB承認の0.5以降に行われたすべての変更の説明。新規または修正された提案、選択基準、選択の正当性など。変更は、0.5 Sで要求されているのと同じレベルの詳細で説明する必要があります。tage.
FRD からのすべての機能要件に対応しました。

2. 仕様の拡張については、FIPD の草案。これには少なくとも以下の情報が含まれている必要があります。

BARB承認のDIPD以降に行われたすべての変更の説明。新規または修正された提案、選択基準、選択の正当性など。変更は、DIPD Sで要求されるのと同じレベルの詳細で説明する必要があります。tage.

必要に応じて、DIPD に関してセクション 4.1 で説明した領域をさらに開発しました。
改善の完全な説明。
更新されたアーキテクチャの説明。
FRD からのすべての機能要件に対応しました。

3. 0.7/FIPD テスト文書には、少なくとも以下の情報が含まれている必要があります。

TSTO [5]に記載されているテスト目的のリストで構成されるテストスイート。

TSTO [5]に記載されている実装適合性ステートメント（ICS）。

仕様の拡張のために、テストスイートと ICS は、個別のドキュメントとして、または FIPD の追加セクションとして提供される場合があります。

この会議で作成された文書の主な対象者はtagWGメンバーとBARBは、view 最終仕様書に盛り込む予定のテキストを含む、機能または改良点の完全な説明。BTIは、view テスト文書の。

BSTSは再view 0.7/FIPD仕様およびテスト文書の新規または変更された部分を、Bluetooth SIGによって確立された言語規則を含むBluetoothドラフトガイドラインと整合させる。BARBは、view 0.7/FIPD 仕様。

BSTSは、TSTO [0.7]に従って5/FIPDテスト文書を作成するWGを支援します。

BTIは再view 0.7/FIPDテスト文書。WGは、BTIに0.7/FIPD仕様を参考資料として提供する必要がある。view0.7/FIPDテスト文書をBTIが再作成しますview BTI仕様書に従ってview プロセスチェックリスト[6]

BARBが再view 0.7/FIPD仕様のBTIは再view 0.7/FIPDテスト文書のBSTSは、viewed 0.7/FIPD 仕様は、すべてのアソシエイトメンバーとプロモーターメンバーが利用できます。

0.7/FIPD StagCSS、GSS、または MDP 仕様の拡張には e は必要ありません。

0.7/FIPD Stag退出要件

0.7/FIPD Stageは完全であり、0.9/CR Stage は、次の終了要件が満たされたときに開始されます。

BSTSは再view0.7/FIPD 仕様とテスト文書に準拠します。
BARBは再view0.7/FIPD 仕様に準拠しています。
BTIは再view0.7/FIPD テストスイート (テスト目的) と 0.7/FIPD ICS を実行します。
BSTSは再viewed 0.7/FIPD 仕様は、すべてのアソシエイトメンバーとプロモーターメンバーが利用できます。

4.3 0.9/CRStage

CR には 2 つの種類があります。統合 CR は、採用された仕様全体の変更を追跡したドキュメントで、以前のバージョン以降のすべての変更を示します。また、簡略化された CR は、CR のベースとなる仕様バージョンの影響を受けるセクションのみを変更するための手順を示すドキュメントです。

0.9/CR Sの間tage、WGは[8]で提供されている公式テンプレートを使用して以下を開発します。

新しい仕様の場合、0.9 仕様の完全な内容のドラフトには、少なくとも次の情報が含まれている必要があります。

BARB-re以降に行われたすべての変更の説明view0.7仕様（または0.5仕様以降で0.7仕様の作成が免除されていた場合）以降、新規または
変更された提案、選択基準、および選択の正当性。変更は、0.5 Sで要求されるのと同じレベルの詳細で記述する必要があります。tageと0.7Stage.

2. 仕様強化の場合:

統合 CR には、少なくとも以下の情報が含まれている必要があります。

BARB-re以降に行われたすべての変更の説明viewFIPD（またはFIPDが免除されている場合はDIPD以降）で変更された提案、選択基準、選択の正当性など、変更内容はDIPD Sで要求されているのと同じレベルの詳細で記述する必要があります。tageおよびFIPD Stage.
変更追跡を使用して、以前に採用された仕様に提案されたすべての変更。
変更追跡を使用して表示される、以前に採用された仕様バージョンにまだ組み込まれておらず、仕様の拡張に関連するテキストに影響を与える、または IOP テストに影響を与える、承認されたすべての技術エラッタ (各エラッタはエラッタ番号で参照されます)。

3. または、少なくとも以下の情報を含む簡略化された CR:

BARB-re以降に行われたすべての変更の説明viewFIPD（またはFIPDが免除されている場合はDIPD以降）で変更された提案、選択基準、選択の正当性など、変更内容はDIPD Sで要求されているのと同じレベルの詳細で記述する必要があります。tageおよびFIPD Stage.
CR が変更を提案する仕様の各影響を受けるセクションおよび段落に対して提案されたすべての変更。
マークアップを使用して表示される、承認されたすべての技術エラッタ (各エラッタはエラッタ番号で参照されます) で、以前に採用された仕様バージョンにまだ組み込まれておらず、仕様の拡張に関連するテキストに影響を与えるか、または IOP テストに影響を与えるもの。

4. CSS CR（仕様で新しいエントリが必要な場合）。仕様の短縮 CR に埋め込むことができます。
5. GSS CR（仕様で新しいエントリが必要な場合）。仕様の簡略化された CR に埋め込むことができます。
6. MDP CR（仕様で新しいエントリが必要な場合）。仕様の短縮 CR に埋め込むことができます。
7. 0.9/CRテスト文書には、[8]で提供されている公式テンプレートを使用して、少なくとも以下の情報が含まれている必要があります。

0.9/CRテストスイートには、TSTO [5]で説明されているように、コンテンツが完全なテストケースと関連するテストケースマッピングテーブル（TCMT）が含まれています。
TSTO [0.9]に記載されている5/CR ICS。
テストを構成する際に、テスト対象の実装 (IUT) に特定のパラメータが必要な場合は、0.9/CR のテスト用実装追加情報 (IXIT) を使用します。

0.9/CR テストケース参照リスト (TCRL) (コア仕様の更新の場合はオプション)。

8. 0.9/CR テストスイート内でどの仕様要件がテストされているか、またはテストされていないかを示すテストカバレッジ分析 (仕様の拡張の場合、テストカバレッジ分析には、新しく追加された機能と影響を受ける機能のみを含める必要があり、元の仕様の影響を受けない領域を含める必要はありません)。
9. IOP テスト計画。

仕様拡張の場合、テストスイート、ICS、および IXIT は、個別のドキュメントとして、または短縮 CR の追加セクションとして提供される場合があります。

ほとんどの場合、統合CRまたは短縮CRは、以前に採用された仕様のバージョンに基づいて作成する必要がありますが、最新の中間ドラフトに基づいて作成することもできます。最新の中間ドラフト仕様のバージョン番号は、固定されており、時間の経過とともに変更されないドキュメントのバージョンに関連付けられたバージョン番号である必要があります。それ以外の場合は、追加の識別情報（ドキュメントの日付や URL 特定の「ベースライン」バージョンを識別するために、CR の最終バージョン（永続的な場所に保存されるもの）を指定する必要があります。中間ドラフトを使用する場合、CR が変更する特定のセクション内の CR に直接関係しない変更はすべて含める必要がありますが、マークアップを使用して表示する必要はありません。中間ドラフトの関連部分が後で更新された場合、CR を更新して中間ドラフトの更新を反映する必要があります。

理想的には、短縮された CR 資料は、検証フェーズの前に、それぞれ完全な仕様のドラフトと完全なテストドキュメントに統合されますが、検証フェーズの開始時に統合することもできます。仕様 (コア仕様など) に対して複数の機能が開発されている場合は、IOP テストが完了した後に、それらの機能を 1 つのドラフトに統合することが望ましい場合があります。

BSTSは再view 0.9/CR仕様とテスト文書をBluetoothドラフトガイドラインと整合させる。その後、BARBはview 0.9/CR仕様書とそれに続くIOPテスト計画書（セクション4.3.1で説明）が提出される。0.9/CR仕様書がWGからBARBに提出されると、viewBSTSは、すべての会員がアクセスできるようにします。view すべてのメンバーにその利用可能性を通知します。仕様開発プロセスのこの時点以降、BSTS は BARB に提出された仕様のドラフトをすべてのメンバーが利用できるようにし、すべてのメンバーに定期的に通知を送信します。

仕様の強化については、WG は、推奨の技術的な理由を含め、仕様の以前のバージョンを廃止または撤回する必要があるかどうかを理事会に推奨します。

BARBは再view 0.9/CR仕様がFRDで規定された要件に準拠しているかどうか、潜在的なセキュリティ問題、規制上の問題、Bluetoothアーキテクチャとの適合性、および仕様拡張の場合はセクション3.3.2で説明されている下位互換性要件に準拠しているかどうかのWGの分析。BARBが潜在的なセキュリティ問題を特定した場合、BARBはBSTSに通知して再検討を求める。view セキュリティ専門家グループとの調整。BARBが規制上の影響を特定した場合、BARBはBSTSに通知して、view 規制委員会および Bluetooth SIG の法律顧問と調整します。BARB は、エンジニアリング上の判断とこの段落で説明されている要因を考慮して、0.9/CR 仕様を承認または拒否する必要があります。

BTIは再view テストカバレッジ分析を考慮した 0.9/CR テストドキュメント。BTI は 0.9/CR テストドキュメントを承認または拒否する必要があります。

BARBが0.9/CR仕様を承認した後、WGはIOPテスト計画をBARBに提出し、再検証を行う。view.

BARB 承認の 0.9/CR 仕様が理事会に提出され、IOP テストの開始と 0.9/CR 仕様の全メンバーへの公開が承認されます。

潜在的な法的問題を強調するために、WGは仕様を要求する場合があります。view Bluetooth SIGの法律顧問（法律関係）によるview）の義務的な法的再view 採用/承認フェーズで行われます。ただし、仕様の拡張については、法的再view 統合 CR (短縮 CR ではなく) で実行する必要があります。また、リソースが利用できるように、できるだけ早めにスケジュールを設定する必要があります。

IOPテスト計画

WGは、IOPテストイベントの検証フェーズで使用するために、以下に定義されるすべての要件を満たす書面によるIOPテスト計画を作成します。WGは、IOPテスト計画を再検証するためにBARBに提出する必要があります。view IOP テストイベントが始まる前に。単純な仕様拡張 (特にテストスイートのテストケースの変更や追加を必要としないもの) の場合、IOP テストは必要ない可能性があり、WG はセクション 4.4 で定義されているプロセスを使用して、IOP テストの免除を BARB に要求できます。

IOP テスト計画には次の内容が含まれている必要があります。

すべての新しい必須、オプション、条件付き機能を検証するためのテストケース
各オペコードごとに少なくとも1つのテストケース
各パラメータごとに少なくとも1つのテストケース
各パケットタイプごとに少なくとも1つのテストケース
セクション 3.3.2 に記載されている要件がすべての拡張機能に対して満たされるように、仕様を拡張するための下位互換性テストケース (セクション 4.3.1.1 も参照)。

IUT が定義された範囲外の値にさらされたり、無効または予期しないと見なされる動作の側面にさらされたりするテストケース (無効な動作のテストケース)。無効な動作の開始者は、PTS などのテスターやその他のテストツールであることが想定されることに注意してください。
セクション 4.3.1.2 で説明されているように、IOP テストイベントで使用される一時的に割り当てられた番号 (今後の IOP テストイベントでの重複を避けるために BSTS と調整して選択されます)。
セクション4.3.1.3で説明されているカバレッジ要件を考慮して、各テストケースに合格する必要がある独立した実装の必要な数を特定する。

WG がテストスイートから除外すべきと考えるテストケースの特定と、その除外の正当性。これには通常、次のものが含まれます。• 将来対応型テストケース (たとえば、追加特性、拡張特性、将来使用のために予約されている (RFU) ビットまたはフィールドの使用など、将来追加される可能性があるものに対応できるようにするための共通テスト)
• 他のテストのサブセットであるテストケース
• 他のいくつかの仕様で実行されるテストと実質的に同一の汎用テストケース（例：共通のエラーコードのトリガー）
• 別のトランスポートで実行されるテストケースと同じテスト目的のテストケース（例：LEテストケースに類似したBR/EDRテストケース）
• 実装の堅牢性またはストレステスト

IOP テストプランには、一般的なユーザーシナリオに類似する、より複雑なシーケンスを連結するエンドツーエンドのテストケースなど、IOP テストに固有のテストも含まれる場合があります。

IOP テスト計画の BARB 承認は必須ではありませんが (IOP テスト計画は各 IOP テストイベントで変更および改善され続けるという前提で)、IOP テストレポートの BARB 承認は必須です (セクション 5.1.1 を参照)。IOP テスト計画がセクション 4.3.1 で定義されているすべての要件を満たしていない場合、WG は IOP テストイベントの開始前に、既知の差異の概要と各差異の根拠を BARB に提示する必要があります。

IOP テスト計画とテストケースは、主に関連する仕様のテストドキュメント内のコンテンツに基づく必要があります。

IOP テストイベントを効率的に行うには、WG は IOP テストプランと関連するすべてのテストケースを完了し、理想的には最初の IOP テストイベントの少なくとも 1 か月前に実装者が利用できるようにしておく必要があります。

下位互換性テストの計画
仕様の拡張については、IOP の下位互換性テストでは、Bluetooth 製品によく見られる仕様と機能の寿命が非常に長い可能性があるため (例: 車両)、すべてのアクティブバージョンと非推奨バージョンの仕様に対する検証を考慮する必要があります。WG は、テストするバージョンと実行するテストを含め、必要な下位互換性テストの適切なレベル (ある場合) を分析し、この分析を BARB に提供する必要があります。BARB は、view 分析を行い、WG が IOP テスト計画に組み込む変更 (ある場合) を推奨します。

下位互換性テストに参加するメンバーは、以前の仕様バージョンで認定されたレガシーデバイスを持参することをお勧めします。WG は、下位互換性の失敗を IOP テストレポートに報告する必要があります。メンバー企業は、IOP テストイベントの場所以外の独自のラボで下位互換性テストを実行し、仕様に関連する問題を WG に報告することもお勧めします。

IOP テストで使用される一時的な割り当て番号
IOP テストイベントで使用される割り当て番号の一時的な割り当てを調整するために、BSTS および BARB に相談し、他の仕様との重複や衝突が発生しないようにする必要があります。これらの一時的な値は IOP テストプランに含める必要があり、採用された仕様で使用するために割り当てられることはありません。

16 つ以上の新しい 0 ビット UUID 値が提案されている IOP テストの場合、7x00F0 から 7xXNUMXFFF の範囲内の値が IOP テスト用に予約されます。

0 つ以上の新しい固定プロトコルサービスマルチプレクサ (PSM) 値が提案されている IOP テストでは、コア仕様で指定されている有効範囲の終わり (0000x0 から 007xXNUMXF) から始まる値が使用されます。

カバレッジ要件
WG は、必要な数の独立した実装 (次のセクションで説明) が各テストケースに合格したことの証明を BARB に提供する必要があります。必要な数の独立した実装に対する例外を求める WG の要求は、BARB に提出される IOP テストプランに記載する必要があります。

検証に関連するすべての部分が独立して開発されている限り、つまり異なるチーム (必ずしも異なる会社のチームである必要はありません) によって開発されている限り、実装は互いに独立していると見なされます。BSTS は、実装の詳細の匿名性と機密性を維持するために、プロトタイプが互いに独立しているかどうかの評価を支援する場合があります。

PTS を含むテストツールは独立した実装とは見なされないことに注意してください。

コア仕様 IOP カバレッジ要件
コア仕様機能は通常、1 つ以上のロールを定義します。各ロールは、1 つ以上の他のロール、または場合によってはそれ自体と相互運用するように設計されています。

相互運用するように設計されたロールの各ペアについて、各ロールの少なくとも 3 つの独立した実装が、補完的なロールの 3 つの独立した実装と相互運用できることを実証する必要があります。

同じロールの別のデバイスと相互運用できる各ロールについて、そのロールの少なくとも 3 つの独立した実装が、そのロールで相互に対話できることを実証する必要があります。

サービス仕様 IOP カバレッジ要件
少なくとも 3 つの独立したサービス実装は、少なくとも 1 つのクライアント実装 (PTS の場合もあります) と相互運用できることを実証する必要があります。

プロfile プロトコル仕様IOPカバレッジ要件
プロfile プロトコル仕様では通常、1 つ以上のロールが定義され、各ロールは 1 つ以上の他のロールと相互運用するように、または場合によってはそれ自体と相互運用するように設計されています。

相互に相互運用するように設計されたロールの各ペアについて、各ロールの少なくとも 2 つの独立した実装が、補完的なロールの 2 つの独立した実装と相互運用できることを実証する必要があります。

同じロールの別のデバイスと相互運用できる各ロールについて、そのロールの少なくとも 3 つの独立した実装が、そのロールで相互に対話することを実証する必要があります。

モデル仕様 IOP カバレッジ要件
少なくとも 3 つの独立したサーバーモデルまたは制御モデルの実装は、少なくとも 1 つのクライアント実装 (PTS の場合もあります) と相互運用できることを実証する必要があり、少なくとも 1 つのクライアントモデル実装は、少なくとも 1 つのサーバーモデル実装および PTS と相互運用できることを実証する必要があります。

仕様のバージョン番号

0.9/CR Sの間tage. WG は、採用されたときに仕様に適用されるバージョン番号に関して理事会に提出する推奨事項を準備する必要があります。

仕様のバージョンは、新機能や更新された機能を含むフルリリースバージョンと、技術的および編集上の正誤表を統合するが新機能や更新された機能は含まないメンテナンスリリースバージョン (「ドット Z バージョン」とも呼ばれる) の 2.1 種類に分けられます。フルリリースバージョンは 5.0 や 2.1.2 などの XY 形式の 0 部構成の番号を持ち、メンテナンスリリースバージョンは XNUMX などの XYZ 形式の XNUMX 部構成の番号を持ちます。Z の値は XNUMX にできません。

2 つのバージョンのうち、一方は「上位バージョン」、もう一方は「下位バージョン」と呼ばれます。これは、次の規則に従って決定されます。

X コンポーネントが異なる場合は、X 値が大きい方が「上位バージョン」になります。
X コンポーネントは同じだが、Y コンポーネントが異なる場合は、Y 値が大きい方が「上位バージョン」になります。
XY コンポーネントは同じだが、Z コンポーネントが異なる場合は、Z 値が大きい方が「上位バージョン」になります。この目的では、0 つの部分から成る数値 XY は、XNUMX つの部分から成る数値 XYXNUMX として扱われます。

例えばampたとえば、バージョン番号は、最低バージョンから最高バージョンの順に、1.4、2.0、2.0.3、2.1、2.1.1、2.1.2、2.2 となります。CSS の場合、各更新でバージョン番号の X コンポーネントのみが増加します。

取締役会の承認の前提条件
仕様開発フェーズの終了時に、0.9/CR 仕様が理事会に承認のために提出される前に、次の要件を満たす必要があります。

WG はテスト範囲分析を完了しました。
BSTSは再view0.9/CR 仕様とテストドキュメントを確認します。
BARB は 0.9/CR 仕様を承認しました。
BARB は、仕様の省略 CR に埋め込むことができる CSS CR (仕様で新しいエントリが必要な場合) を承認しました。
BARB は GSS CR と MDP CR を承認しました (仕様で新しいエントリが必要な場合)。
BTIは、0.9/CRテストスイート、ICS、TCRL、およびIXIT（テストスイートのテストを実行するためにIXITが必要であることを条件とする）を承認しました。TCRLは現時点ではオプションです。tagコア仕様の更新については、e を参照してください。
WGはIOPテスト計画をBARBに提出し、view （BARB によってテストが免除されていない場合）。

取締役会に提出される文書には、BARB 承認の 0.9/CR 仕様と、次の内容を含む取締役会へのプレゼンテーションが含まれている必要があります。

IOPテストまたはセクション4.3.1で定義された要件のいずれかを免除する既知の要求
仕様がサポートするトランスポートのリスト (例: BR/EDR、LE など)
仕様の拡張については、WGによって要求されている後方互換性要件（セクション3.3.2で説明）からの免除
仕様の拡張の場合、採用された仕様に適用するバージョン番号に関するWGからの推奨
仕様の強化については、採用された仕様の以前のバージョンに対する WG のサポート終了の推奨事項 (以前のバージョンの仕様の廃止または撤回が推奨される、または推奨されない技術的な理由、および推奨の正当性を含む)
BARBまたはBTIメンバーからの未解決の重大な懸念（例えば、承認中に反対票を投じた理由、再審査の結果生じた懸念など）view テスト文書の不備、または 0.9/CR 仕様が FRD または憲章の範囲外であるという懸念)
プロの準備状況file BSTSが用意した、導入に関連するチューニングスイート（PTS）またはその他の必要なツール

理事会は、BTIが0.9/CRテスト文書を承認する前、およびWGがIOPテスト計画がセクション2で定義された要件を満たしていることを確認する前に、定款[0.9]で要求されているようにIOPテストの4.3.1/CR仕様を承認することを選択できます。理事会は、BTIによる0.9/CRテスト文書の承認を、IOPテストの0.9/CR仕様の承認の条件とすることもできます。

0.9/CRStag退出要件
0.9/CR Stage が完了し、BoD が IOP テストの開始を承認すると検証フェーズが始まります。

4.4 仕様開発プロセスの免除

WG は、次のプロセスステップの 1 つ以上を免除するよう要求できます。

0.5/DIPD Stage
0.7/FIPD Stage
検証フェーズにおけるIOPテスト

免除を申請するには、WGはBluetooth SIG [8]が提供するプロセス免除テンプレートを使用し、免除申請を各委員会（BARBまたはBTI）に提出する必要があります。view または、ドラフト仕様書または関連するテスト文書を承認するtagWG が免除を提案し、各委員会が免除要求を承認する必要があります。

免除申請には以下の内容を含める必要があります。

の識別tagWGが免除したい事項
sの正当性tage(s)は免除されるべきである
再審査が必要な各委員会（BTIおよび/またはBARB）の識別view 免除申請を承認する

免除を検討する委員会は、免除要求を決定する前に、WG の代表者に SMPD プロセス免除を正当化するプレゼンテーションを行うことを要求する場合があります。

免除が複数の手順の免除を要求し、免除の一部が拒否され、一部が承認された場合、委員会の回答には、免除要求のどの手順が承認され、どの手順が拒否されたかを示す必要があります。免除要求が拒否された場合、拒否通知には拒否の理由を含める必要があります。

5. 検証フェーズ

検証フェーズでは、ワーキンググループは0.9/CR仕様のIOPテストを実施し、BARB再検証用のIOPテストレポートを提供することを目的とする。view 承認。可能な限り、仕様強化のIOPテストは統合されたドラフト仕様に対して実施されるべきである。さらに、メンバーReview細則[2]で定められているように、このフェーズで開始されます。

仕様 (または拡張機能) で IOP テストが不要な場合は、セクション 4.4 で説明されているプロセスを使用して、検証フェーズ内の IOP テストを省略できます。

IOPテスト（1回以上のイベント）の過程を通じて、WGはBluetooth SIGの問題追跡システムを使用して問題を追跡し、ドラフト仕様、テスト文書、およびIOPテスト計画の更新を繰り返す必要があります。IOPテストが終了したら、WGはドラフト仕様とテスト文書の更新を完了してすべての問題に対処し、IOPテストレポートを準備してBARBに提出して再検証する必要があります。view 承認です。これは図5.1に示されています。

検証フェーズでは、いくつかのアクティビティが開始される可能性があります。これらのアクティビティは並行して実行される場合があり、次のようなアクティビティが含まれます。

理事会承認の0.9/CR仕様は、BSTSによりメンバー再審査の開始通知とともに全メンバーに公開されます。view 定款で定められた期間。
必要な更新はすべて CSS に組み込まれます (仕様の短縮 CR に埋め込まれる場合があります)。
特性または記述子の定義は、IOP テスト用の PTS だけでなく GSS 仕様にも組み込まれています。
メッシュプロパティの定義は、IOP テスト用の PTS だけでなく MDP 仕様にも組み込まれています。
BSTS は、IOP テストの準備として IOP プラットフォーム登録および結果入力ツールを有効にします。
必要に応じてIOP検査を実施します（セクション5.1を参照）。
Review IOP テストの結果として提出されたものも含め、コメントと問題が処理され、変更がドラフト仕様に組み込まれます。

5.1 IOP検査

IOPテストの主な目的は、例えば次のような方法で仕様を検証することです。ampテキスト内の正確性と曖昧さをチェックし、view基本的な設計エラーや漏れがないか確認し、仕様開発プロセスの早い段階で開発された既存の要件に対する検証を提供します。IOP テストによりドラフト仕様が変更される可能性があり、必要なすべてのテストを完了するには複数の IOP テストイベントが必要になる場合があります。

WG外のメンバーにIOPテストに参加する機会を与えることは、独立した view 仕様の詳細な調査と、ドラフトを作成した WG のメンバーには明らかでない可能性のある、仕様の曖昧な部分を明らかにすることができます。各 IOP テストイベントの前に、BSTS はイベントの詳細、最新のドラフト仕様、テストスイート、および IOP テストプランを公開し、各イベントの 1 か月前までにすべてのメンバーに通知します。IOP テストイベントで使用される更新されたドラフト仕様、テストスイート、および IOP テストプランは、各イベントの少なくとも 1 週間前には公開される必要があります。

IOP テスト中、プラットフォームのペアの組み合わせでテストの実行が試みられ、IOP テスト参加者は各テストの合格/不合格の結果とコメントを記録します。これらの結果の匿名化された要約 (「プラットフォーム A」、「プラットフォーム B」など) とコメントは、IOP テストイベント中に収集され、IOP テストイベント中およびイベント後に WG メンバーに提供されます。IOP テスト中に発生したコメントや障害をより深く理解するために追加情報が必要な場合、BSTS は仲介役として機能し、提出メンバーからさらに情報を収集することがあります。

可能であれば、PTS を更新して、ホストコントローラインターフェイス (HCI) より上のすべてのレイヤーのプラットフォームで IOP テストをサポートし、それらのレイヤーの IOP テストイベントに参加できるようにする必要があります。IOP テストイベントには、他のテストツールも参加できます。PTS または他のテストツール (ある場合) を使用したテスト結果の概要は、IOP テストレポートに含める必要があります。

IOP テストは、プロトタイプ実装を提供したいすべてのメンバーに公開されますが、Bluetooth SIG は、Bluetooth SIG との契約 (参加契約および機密保持契約を含む) の承諾を参加の条件とする場合があります。WG は、IOP テスト中に発見された問題の処理と解決、および影響を受けるドキュメントの更新を担当します。WG が承認した変更は、各 IOP テストイベントで使用するために、ドラフト仕様とテストドキュメントの更新として組み込む必要があります。

検証フェーズの前に、WG は WG メンバーのみが参加できるイベントで予備的な IOP テストを実行する場合があります。ただし、非公式テストの結果は IOP テスト結果に含まれない場合があります。

IOP テストを開始する目的で IOP の日付と場所の発表を含む最初の IOP テストイベントまでのすべての手順が実行されたが、テストイベントの開始前に BoD の承認が得られなかったという状況が発生する場合があります。この場合、収集された結果が BoD によって承認されている同じ仕様とテストスイートに基づいている限り、BoD は IOP テストの開始を承認する前に収集されたテスト結果を含めることを承認できます。

CSS、GSS、または MDP 仕様の拡張には IOP テストは必要ありません。

IOPテストレポート
IOPテストが完了したら、WGは必要な数の独立プラットフォームが必要なテストに合格したことを示す目的で、IOPテストレポートをBARBに提出する必要があります。BARBは、view IOP テストレポートを承認または拒否し、追加の IOP テストが必要な場合は、投票ドラフト仕様パッケージを理事会に提出する前に WG に通知します。BSTS と WG は、レポートを BARB に提出する前に、IOP テストレポートにメンバーを特定する情報が含まれていないことを確認する必要があります。

IOP テストレポートには次の内容が含まれている必要があります。

検証フェーズ中に発生したすべての IOP テストイベントのリスト (日付と場所を含む)。
PTS が使用されたかどうかを含む、各 IOP イベントに参加したメンバー企業と独立プラットフォームの数。
各イベントで使用される仕様、テストスイート、および IOP テストプランのバージョンのリスト。
すべてのテストケースが最低限の合格基準を満たしているかどうかを示すエグゼクティブサマリー。
セクション 4.3.1 で定義された IOP テスト計画要件からの差異の概要と、各差異の根拠。
テストスイート内のテストケースの PTS カバレッジの概要。
IOP テストプランのすべてのテストケース (下位互換性テストを含む)、テスト合格数、テスト不合格数、テストケースごとに最小基準が満たされたかどうか、および要件が満たされなかった理由の説明のリスト。
各イベントでの問題、コメント、質問の要約（ fileIOP テスト中に仕様に違反したかどうか、また、仕様とテストドキュメントに与える影響について説明します。

5.2 検証フェーズ終了要件

BARB が IOP テストレポートを承認し (BARB によってテストが免除されない限り)、次の要件がすべて満たされると、検証フェーズが完了し、承認/採用フェーズが開始されます。

BSTSは、承認された0.9 / CR仕様をメンバー再のためにすべてのメンバーに公開しました。view 定款の規定に従い、その利用可能性を全会員に通知しました。
IOP テスト中に特定され、テストに影響を与えるすべての問題が組み込まれ、テストされました。
WG は IOP テストを完了しました (BARB によってテストが免除されない限り)。

6. 採用/承認フェーズ

採用/承認フェーズでは、仕様と関連テスト文書が完成し、BARB、BQRB、BTIの承認が得られ、採用予定日の通知が、採用のために理事会に提出された仕様草案の最終版（投票草案）とともに発行され、最終的な仕様パッケージが理事会に提出されます。メンバーの再検討の最小期間が経過した後、view 細則[2]で要求される要件が満たされると、理事会は採択日に仕様の採択を検討します。採択後、仕様は公開され、認定システムが有効になります。採択/承認フェーズを図6.1に示します。

6.1 投票草案

投票ドラフトは、更新内容 (検証フェーズで提供) を必要な仕様文書に組み込み、新しい仕様の最終ドラフトを準備することによって作成されます。仕様の拡張については、BSTS は、検証フェーズの前にまだ完了していない場合、4.3.2 つ以上の CR を以前に採用された仕様の上位バージョン (セクション XNUMX を参照) に統合することによって統合仕様を作成します。

このフェーズで仕様に変更が加えられ、WG、BARB、または BTI が変更には追加の IOP テストが必要であると判断した場合、仕様は検証フェーズの IOP テスト部分に戻り、WG が追加のテストを実行します。採用/承認フェーズでは、採用日までに次の文書が完成し、理事会に提供されます。

投票草案
関連する仕様（または拡張機能）タイプに必要なすべてのサポート仕様（CSS、GSS、MDPなど）（以前に採用されていない場合）
仕様の強化については、投票草案で提案された変更を示す、採用された仕様バージョンの変更追跡バージョン
満たされていない下位互換性要件（セクション3.3.2で説明）と例外の正当性に関するWGからの説明
満たされていないIOPテスト計画要件（セクション4.3.1で説明）に関するWGからの説明と、逸脱の正当性、およびIOPテストレポート（Bluetooth SIGのリンクを提供することで提供される場合があります） web地点）
採用された仕様の以前のバージョンを廃止または撤回するためのWGからの勧告と、その理由、0.9/CR S以降の変更点を強調したもの。tag終末期の推奨事項
WG が作成した、0.9/CR 仕様以降の機能または機能の変更の概要 (ある場合)
BARB が作成した、WG によって作成された仕様が理事会によって承認された憲章 (ある場合) の範囲を超えているという BARB メンバーから提起された懸念の要約
法務問題から未解決の法的問題のリストview （もしあれば）
BTI 承認のテストスイートと、WG 承認の投票ドラフト仕様のテスト範囲の概要。テスト範囲のない新機能の追加または変更があった場合は、省略の理由を文書で示す必要があります。
BTI 承認の ICS および IXIT (仕様で必要な場合)
TCRLはBTIとBQRBの両方によって承認されました
BSTS が BTI と共同で作成した、ツールの準備状況 (例: PTS およびその他のテストツール、Bluetooth Launch Studio) に関するレポート。これには、TCRL 内のテストケースがテストツールでサポートされていないかどうかも含まれます。
WGが作成した、割り当てられたすべての必要な番号の概要
BSTSとWGが作成した採用チェックリスト。このセクションのすべての成果物が完了したことを示しています。
取締役会が要求するその他のすべての情報

採用/承認フェーズでは、WG は Bluetooth SIG の問題追跡システムを使用して、ドラフト仕様とテストドキュメントに対する問題とコメントをキャプチャし、投票ドラフト仕様の最終決定に反映させる必要があります。仕様の拡張では、関連する承認済みのエラッタ (つまり、まだ統合されていない承認済みのエラッタ) をすべて組み込む必要があり、追跡された変更を使用して識別する必要があります。

WGは、法的審査のためにBSTSに最終仕様案を提出する必要がある。view新しい仕様については、法的再view 仕様全体が含まれます。仕様の拡張については、view 仕様の変更部分に主に焦点を当てます。法的再検討の目的は、view WGが検討し解決すべき法的リスクを特定することが主な目的です。法的フィードバックは重大度に基づいて分類されます。オプションの法的フィードバックがある場合は、view 0.9/CR Sで実施されましたtage、法的審査のために提出されたバージョンview 当該バージョン（WGまたはBSTSによって生成されたもの）以降に行われたすべての変更を、追跡された変更として表示する必要があります。法的再検証が完了すると、viewWGとBSTSは、ドラフト仕様に組み込むフィードバックについて合意する。法務担当者から未解決の法的コメントがある場合は、view 仕様草案に関して、WG 議長は理事会の議題に時間を設け、解決策について合意するよう要請することができます。

法的再検討と並行してviewWGは、仕様草案をBARBに提出して、viewBARBへの最初の提出時に、BSTSは、仕様草案が再検討のためにBARBに提出されたことをすべてのメンバーに通知します。view また、会員向けサービスも提供されている。viewワーキンググループがBARBの再再仕様案の更新を提出した場合viewBSTS は定期的にすべての会員に追加の通知を送信します。

BARBの再完了後viewWG と BARB は、ドラフト仕様に組み込むフィードバックについて合意します。

法的にview 実質的な変更、追加の再view BARBによる承認が必要な場合があります。同様に、BARBがview 実質的な変更が生じた場合、BSTSは追加の法的再view これらの変更の完了が必要です。法的再view BARBの再viewBARB は投票草案を承認または拒否する必要があります。

テストドキュメントを更新する必要がある場合、BSTS は WG によるテストドキュメントの更新を支援します。BTI はテストドキュメントを承認または拒否する必要があります。BTI によって承認された場合、BTI は TCRL の最終決定を支援し、このドキュメントを関連する ICS、IXIT、およびテストスイートとともに BQRB に渡します。BSTS は、BoD が投票草案の採用に投票する予定の BoD 会議の日付 (採用日) を推定し、TCRL で使用するために BTI に提供します。仕様の BARB 承認、すべてのテストドキュメント (テストスイート、TCRL、ICS、および IXIT を含む) の BTI 承認、および TCRL の BQRB 承認は、採用日までに行う必要があります。

BSTSは、投票ドラフトの最終決定と利用可能日、および採択日を全会員に通知します。採択日は、会員が理事会承認の60/CR仕様を通知されてから0.9日後以降に設定されます。ただし、会員が再投票を要求した場合は除きます。view 理事会が定款に従って期間を短縮し、定款に従って採択日の通知が会員に提供されてから少なくとも14日後。複数のCRが投票草案に統合されている場合、会員再投票の開始は定款に従って行われます。view 理事会が承認した最新の CR がメンバーに通知された日付です。

採用日がメンバーに通知された後、投票草案の誤字に対する理事会承認の修正が許可されます。仕様採用のタイムラインは図 6.2 に示されています。

6.2 割り当てられた番号

Bluetooth SIGは、Bluetooth SIG Assigned Numbersで公開されている割り当て番号のセットを管理しています。 webサイト[7]。割り当てられた番号は、さまざまな番号スペース（重複のない関連する番号セット）にグループ化されます。割り当てられた番号は、異なる番号スペースの他の割り当てられた番号と重複する場合がありますが、番号スペース内の番号を再利用することは許可されていません。さまざまな番号スペースは、割り当てられた番号の使用方法を定義する仕様で定義されます。

BARBがIOPテストレポートを承認した後、WGは最終仕様で要求される番号スペース内で新しい番号を割り当てるようBARBに要求を提出します。BARBはview BSTSは、要求に応じて、割り当てられた番号を決定するためにBSTSと協力します。BARBの承認後、BSTSは割り当てられた番号の公開をBluetooth SIG Assigned Numbersで公開する予定です。 web仕様の採用後7週間以内にサイト[XNUMX]に提出してください。

Bluetooth SIG Assigned Numbersに割り当てられた番号が公開されると、 webサイト内または採用された仕様内で変更が発生した場合、割り当てられた番号は不変（値も意味も変わらない）となることが意図されています。何らかの理由で使用できなくなった場合、その番号は予約値となり、再利用は許可されません。

6.3 採用/承認フェーズ終了要件

承認/採用フェーズは、取締役会が仕様を採用し、採用後の次の活動が完了した時点で完了します。

BSTSは、Bluetooth SIGで最終的に割り当てられた番号を公開しました。 webサイト。
BSTSは、採用された仕様をBluetooth SIGで公開しました。 webサイト
BSTSは、関連仕様に必要なすべてのサポートドキュメント（CSS、GSS、MDPなど）をBluetooth SIGで公開しています。 webサイト。
BSTSは、Bluetooth SIGのすべてのメンバーが関連するテスト文書を利用できるようにしました。 webサイト。
仕様の強化については、BSTSは、新しく採用されたバージョンで行われたすべての変更を反映させた、以前に採用された仕様バージョンの有益な変更追跡バージョンを作成し、Bluetooth SIGのすべてのメンバーに公開しました。 webサイト。
BSTS は資格制度を導入しました。
BSTS は、採用された仕様とすべてのサポート文書が利用可能になったことをすべてのメンバーに通知しました。

Bluetooth SIG は、仕様の採用後 1 週間以内にこれらの採用後の活動を完了する予定です。

7. 仕様維持フェーズ

仕様保守フェーズは、採用/承認フェーズが完了した後に開始されます。仕様または関連するテストドキュメントに問題 (言葉の曖昧さや技術的なエラーなど) が見つかった場合は、Bluetooth SIG Errata ツールを使用してエラッタ提案を作成し、それらを文書化する必要があります。仕様エラッタ提案は、EPD [3] に従って処理、分類、承認されます。テストスイートエラッタは、TSTO [5] に従って処理および分類されます。SMPD と EPD または TSTO の間に矛盾がある場合は、SMPD が優先されます。

仕様の正誤表は、最終的に採用された Bluetooth 仕様の技術的または編集上の誤りを修正する場合にのみ使用できます。機能の追加、変更、および削除は、このドキュメントで前述した仕様拡張プロセスによってのみ行うことができます。

7.1 迅速な訂正プロセス

EPD [3] で定義されたプロセスに従ってエラッタが承認された場合、WG、BARB、または BSTS は、緊急性が高いため早急に修正するよう勧告することがあります。この場合、BSTS は WG または BARB とともに、理事会に勧告を提出します。理事会は勧告を受け入れるか拒否するかを決定します。勧告が受け入れられた場合、BSTS は承認されたエラッタを直ちにエラッタテンプレート [8] に組み込み、担当 WG と協力して、WG に再提出するための緊急エラッタ修正を完了します。view と承認。

オーバーview 迅速な訂正プロセスの流れを図7.1に示します。

以下の文書は採択日までに完成し、取締役会に提出する必要があります。

BARB 承認の緊急正誤表修正案。
満たされていない下位互換性要件 (セクション 3.3.2 で説明) と免除の正当性に関する WG からの説明。
法務問題から未解決の法的問題のリストview (もしあれば)
BTI 承認のテストスイート、ICS、および IXIT (エラッタで必要な場合)。
BTI および BQRB 承認の TCRL (エラッタで必要な場合)。
BSTS が BTI と共同で作成した、ツールの準備状況 (PTS およびその他のテストツール、Bluetooth Launch Studio など) に関するレポート。これには、TCRL 内のテストケースがテストツールでサポートされていないかどうか、および説明 (エラッタで必要な場合) が含まれます。
BSTS と WG によって完了した採用チェックリスト。このセクションの成果物がすべて完了していることを示しています。
取締役会が要求するその他すべての情報。

BSTSは担当WGと協力して緊急エラッタ修正案を最終決定し、担当WGに再提出するためのバージョンを作成します。view と承認。

WGは、法的対応のためにBSTSに緊急エラッタ修正を提出する必要がある。view法的再審査が完了するとviewWGとBSTSは、緊急エラッタ修正に組み込むフィードバックについて合意します。法務担当者から未解決の法的コメントがある場合は、view 迅速な正誤表修正については、WG 議長は、解決策に関する理事会の意見を求めるために理事会の議題に時間を割くよう要請することができます。

法的再検討と並行してviewWGは、BARBに緊急エラッタ修正を提出し、再提出しなければならない。view緊急エラッタ修正がBARBに提出されると、BSTSはそれをすべての会員が再アクセスできるようにします。view 全てのメンバーにその利用可能性を通知してください。BARBの再viewWG と BARB は、迅速なエラッタ修正に組み込むフィードバックについて合意します。

法的にview 実質的な変更、追加の再view BARBによる承認が必要な場合があります。同様に、BARBがview 実質的な変更が生じた場合、BSTSは追加の法的再view これらの変更の完了が必要です。法的再view BARBの再viewBARB は、迅速なエラッタ修正を承認または拒否する必要があります。

テストドキュメントを更新する必要がある場合、BSTS は WG によるテストドキュメントの更新を支援します。BTI がテストドキュメントを承認すると、BTI は TCRL の最終決定を支援し、必要に応じて関連する ICS、IXIT、およびテストスイートとともにドキュメントを BQRB に渡します。BSTS は採用日を推定し、TCRL で使用するために BTI に提供します。迅速なエラッタ修正の BARB 承認、すべてのテストドキュメント (該当する場合はテストスイート、TCRL、ICS、および IXIT を含む) の BTI 承認、および TCRL の BQRB 承認は、採用日までに行う必要があります。

BSTS は、緊急エラッタ修正の最終決定と利用可能性、および提案された採択日を全会員に通知します。採択日は定款 [2] に従って設定され、全会員に通知されます。採択日は、会員への通知が提供されてから少なくとも 14 日後とします。提案された採択日の通知が会員に提供された後、理事会は、提案された採択日の追加通知を提供せずに、必要な 14 日間待つことなく、緊急エラッタ修正の誤植の修正を承認できます。

Bluetooth SIG は、採択された Expedited Errata Correction を一般公開し、採択後 1 週間以内に公開する予定です。その公開に関する通知は、BSTS からすべてのメンバーに発行されます。

迅速なエラッタ修正プロセスは、取締役会が迅速なエラッタ修正を採用し、採用後の以下の活動が完了した時点で完了します。

BSTSは、採用された迅速エラッタ修正と関連するテスト文書（エラッタで必要な場合）をBluetooth SIGで公開しました。 webサイト。
BSTS は、資格システムを有効にしました (エラッタで必要な場合)。
BSTS は、採用された迅速な正誤表修正が利用可能になったことをすべてのメンバーに通知しました。

これらの活動が完了すると、エラッタ修正は、計画されている仕様拡張の一部として、またはセクション 7.2 で説明されているように、今後のメンテナンスリリースで、影響を受ける仕様に統合される予定です。

7.2 メンテナンスリリースプロセス（.Z仕様）

BSTS は、ほぼ毎年、テクニカル/高またはテクニカル/クリティカルに分類され、アクティブな仕様 (つまり、廃止または撤回されていない採用された仕様) のテキストにまだ組み込まれていない承認済みのエラッタ (エラッタ修正と呼ばれる) があるかどうかを判断します。エラッタ分類の定義については、付録 A を参照してください。仕様所有者 (仕様の保守を認可された WG、または仕様の保守を認可された WG がない場合は BARB) は、承認済みのエラッタを組み込むためのアクティブな仕様の以前のメンテナンスリリースを要求することもできます。BSTS の決定または仕様所有者の要求に基づいて、メンテナンスリリースプロセスが開始されます。

オーバーview メンテナンスリリースプロセスの詳細は、「エラー! 参照ソースが見つかりません」に示されています。

メンテナンスリリースプロセスの開始時に、BSTS は仕様所有者、BARB、および BTI と共同で、エラッタ修正を公開仕様バージョンに組み込むための計画を作成し、理事会に提出します。提案された計画では、エラッタ修正が仕様のメンテナンスリリース (つまり、.Z バージョン) に組み込まれるか、すでに進行中の仕様拡張 (つまり、XY バージョン) に組み込まれるかを示す必要があります。提案された計画では、採用された仕様のバージョン間で新しい必須機能が追加されたかどうか、次の仕様拡張の採用が予定されている推定時間、およびその他の要因を考慮する必要があります。

理事会による計画の承認後、BSTS は仕様所有者とともに、すべての技術/中、技術/高、技術/重大なエラッタ修正を「メンテナンスリリースドラフト」と呼ばれるドラフト仕様に組み込みます。編集または技術/低レベルのエラッタ修正については、エラッタ修正が仕様の複数のバージョンに適用される場合は、理事会が別途指示しない限り、BSTS はそれらのエラッタを、そのバージョンの次回更新時に最新の上位仕様バージョンにのみ組み込みます。メンテナンスリリースドラフトには、エラッタ修正を組み込む以外の変更を含めることはできません。各メンテナンスリリースドラフトでは、変更追跡を使用して組み込まれたすべてのエラッタ修正を特定し、公開された仕様の以前に採用されたバージョンへの提案された変更を示す必要があります。

メンテナンスリリースドラフト内の各エラッタ修正の提案された組み込みのタイミングは、テストスイートへの影響によって異なります。テストスイートに影響を与えないすべてのエラッタ修正はすぐに組み込まれる可能性がありますが、テストスイートに影響を与えるエラッタ修正は、タイミングが TCRL の更新と一致するように処理されます。

BTI と BSTS は、テストスイートに影響するエラッタ修正をメンテナンスリリースドラフトに含める期限を設定します。この期限は通常、次の主要な TCRL リリースの予定承認日の 3 ～ 6 か月前です。期限を過ぎたテストスイートに影響するエラッタ修正は、次の年次 TCRL リリースの一部として処理されます。したがって、より早いリリースが要求されない限り、テクニカル/高またはテクニカル/クリティカルエラッタ修正が仕様更新に含まれるまでの最大時間は、約 15 ～ 18 か月です。

仕様所有者は、法的要求のために最終版として承認したメンテナンスリリースドラフトを提出する必要がある。view法的再view 仕様の変更部分に主に焦点を当てます。法的再検討が完了すると、view仕様所有者とBSTSは、メンテナンスリリースドラフトに組み込むフィードバックについて合意します。法務担当者からの未解決の法的コメントがある場合は、view メンテナンスリリースドラフトでは、仕様所有者は、解決策について取締役会の意見を求めるために、取締役会の議題に時間を割くよう要求できます。

法的再検討と並行してview仕様所有者は、メンテナンスリリースドラフトをBARBに提出して、viewメンテナンスリリースドラフトがBARBに提出されると、BSTSはそれをすべてのメンバーが再アクセスできるようにします。view 全てのメンバーにその利用可能性を通知してください。BARBの再view仕様所有者と BARB は、ドラフト仕様に組み込むフィードバックについて合意します。

法的にview 実質的な変更、追加の再view BARBによる承認が必要な場合があります。同様に、BARBがview 実質的な変更が生じた場合、BSTSは追加の法的再view これらの変更の完了が必要です。法的再view BARBの再viewBARB はメンテナンスリリースドラフトを承認または拒否する必要があります。BARB によって承認された場合、これは投票ドラフトになります。

テストドキュメントに影響するエラッタ修正については、対応するテストエラッタが次の TCRL リリースに間に合うように処理される場合、BSTS は仕様所有者および BTI と協力してテストドキュメントを更新します。BTI がテストドキュメントを承認すると、BSTS は採用日を推定し、TCRL で使用するために BTI に提案された採用日を提供します。BTI は、該当する場合は関連する ICS、IXIT、およびテストスイートとともに TCRL を BQRB に提供します。仕様の BARB 承認、すべてのテストドキュメント (該当する場合はテストスイート、TCRL、ICS、および IXIT を含む) の BTI 承認、および TCRL の BQRB 承認は、採用日までに行う必要があります。

BSTS は、投票草案の最終決定と利用可能日、および提案された採択日を全会員に通知します。採択日は定款に従って設定され、全会員に通知されます。採択日は、会員に通知が提供されてから少なくとも 14 日後とします。提案された採択日の通知が会員に提供された後、理事会は、提案された採択日の追加通知を提供せず、必要な 14 日間待つことなく、投票草案の誤字の修正を承認できます。

以下の文書は採択日までに完成し、取締役会に提出する必要があります。

投票草案
投票ドラフトの変更追跡バージョン。同じ XY 値を持つ、採用された仕様バージョンに対するすべての変更が表示されます (例: 投票ドラフトがバージョン 1.4.2 として提案されている場合、変更は仕様のバージョン 1.4.1 に対して追跡されます)。
採用された仕様の以前のバージョンを廃止または撤回することに関する仕様所有者からの推奨とその理由
法務問題から未解決の法的問題のリストview （もしあれば）
BTI 承認のテストスイート、ICS、および IXIT (メンテナンスリリースで必要な場合)
BTI および BQRB 承認の TCRL (メンテナンスリリースで必要な場合)
BSTS が BTI と共同で作成した、ツールの準備状況 (例: PTS およびその他のテストツール、Bluetooth Launch Studio) に関するレポート。これには、テストツールでサポートされていない TCRL のテストケースと説明 (メンテナンスリリースで必要な場合) が含まれます。
BSTS と仕様所有者によって完了した採用チェックリスト。このセクションの成果物がすべて完了していることを示します。
取締役会が要求するその他のすべての情報

理事会が投票草案を採択し、次の採択後の活動が完了すると、メンテナンスリリースプロセスが完了します。

BSTSは、採用された仕様と関連するテスト文書（メンテナンスリリースで必要な場合）をBluetooth SIGで公開しています。 webサイト。
BSTSは、Bluetooth SIGのすべてのメンバーが利用できる、新しく採用されたバージョンに組み込まれたすべての変更を含む、以前に採用された仕様バージョンの有益な変更追跡バージョンを作成しました。 webサイト。
BSTS は資格制度を導入しました。
BSTS は、採用された仕様とサポート文書が利用可能になったことをすべてのメンバーに通知しました。

Bluetooth SIG は、仕様の採用後 1 週間以内にこれらの採用後の活動を完了する予定です。

これらのアクティビティが完了すると、仕様は、セクション 8 で定義されているように、廃止または撤回されるまで、仕様メンテナンスフェーズのままになります。

8. 仕様の終了段階

仕様は、新しいバージョンに置き換えられた場合、技術的に不十分であると判断された場合、またはその他の理由により、非推奨または撤回される場合があります。非推奨および撤回された仕様はアーカイブされ、更新されなくなります。非推奨および撤回された仕様は、Bluetooth 認定プログラムでは異なる方法で扱われます。

どのメンバー、グループ、委員会も、仕様を廃止または撤回する勧告を関連するタイムラインとともにBSTSに提出することができます（電子メールで

BSTSは、仕様および関連するタイムラインの廃止または撤回を推奨することもあります。BSTSは、推奨をBARBおよび仕様の保守を担当するグループまたは委員会に再委託します。view およびフィードバック。

BARB と担当グループまたは委員会は、仕様を廃止または撤回するための推奨事項を評価し、次の (網羅的ではない) 基準を考慮します。

以前のバージョンの仕様には、廃止された機能や使用すべきでない機能はありますか?
後のバージョンでは新しい必須機能が追加されましたか?
以前のバージョンには操作や相互運用性を損なう欠陥がありましたが、後のバージョンでは修正され、既存のユーザーシナリオを進めるために必要になっていますか?
新しいユーザーシナリオを進めるために必要な、以降のバージョンでの追加機能はありますか?
後のバージョンでは使いやすさと相互運用性が向上していますか?
後のバージョンではセキュリティが改善されていますか?

BARB および担当グループまたは委員会は、代替の推奨事項を提案する場合があります。

BARB または仕様の維持を担当するグループまたは委員会からのフィードバックを受け取った後、BSTS は推奨事項とフィードバックを理事会に提出して検討します。理事会は、影響を受ける仕様の維持を担当するグループまたは委員会を招集して、推奨事項について話し合うことができます。理事会は推奨事項とフィードバックを検討し、提案に同意するか、提案を修正する場合があります。理事会は、BSTS に、仕様を廃止または撤回する提案と関連するタイムラインを 30 日間の再検討のためにすべてのメンバーに通知するよう要求します。view 最終決定を下す前に、すべてのメンバーが追加のフィードバックを提供できる期間。

理事会はメンバーから受け取ったフィードバックを検討します。理事会が仕様の廃止または撤回を承認すると、BSTS はすべてのメンバーにその決定と関連するタイムラインを通知します。

8.1 廃止

仕様が廃止されると、次のことが起こります。

仕様は今後更新されません。
担当WGは、view 非推奨の仕様に対して書かれたすべての未解決のエラッタが、他の仕様に適用されるかどうかを判断します。エラッタはエラッタシステムで拒否され、適用可能な仕様に対して書き直される場合があります。
WG または BSTS は、他の仕様内の非推奨の仕様への必要な参照を更新するためにエラッタを作成します。
BTI は、仕様の廃止を示すために、該当するテストドキュメントを更新します。
BSTSはBluetooth SIGを更新します web使用する代替仕様に関するガイダンスのあるサイト。
非推奨の仕様に対して新しいエラータを送信できなくなります。
この仕様は将来の仕様では参照されません。
BSTS は、メンバーが履歴目的でアクセスできるように、非推奨としてマークされた仕様のバージョンをアーカイブします。

8.2 撤退

仕様が撤回されると、廃止に適用される手順に加えて、次の処理が行われます。

BTI は、仕様の撤回を示すために該当するテスト文書を更新します。
BSTSはBluetooth SIGを更新します web使用する代替仕様に関するガイダンスのあるサイト。
BSTS は、メンバーが履歴目的でアクセスできるように、撤回済みとしてマークされた仕様のバージョンをアーカイブします。

理事会は、最初に仕様を非推奨にすることなく、直ちに仕様を撤回することを選択できます。

9. ホワイトペーパープロセス

ホワイトペーパーは情報提供のみを目的として作成されます。次のホワイトペーパープロセスは、すべての Bluetooth WG、EG、SG、および委員会に適用されます。このセクションは、Bluetooth SIG 内でのみ使用される情報ドキュメントには適用されません。

このプロセスは以下の図9.1に示されています。

グループまたは委員会は、Bluetooth SIG によって公開する予定のホワイトペーパーの作業を開始する前に、ホワイトペーパーの提案内容を明確に定義する提案憲章の更新とホワイトペーパー提案のプレゼンテーションの両方を準備します。

ホワイトペーパーの提案プレゼンテーションには、少なくとも次の内容が含まれている必要があります。

ホワイトペーパーの必要性
白書の提案内容の概要
コンテンツを仕様の一部として含めることが推奨されない理由の説明
対象読者
メンテナンス計画（このホワイトペーパーの次回リリースまでに必要となる推定時間）
ホワイトペーパーの以前のバージョンをどのように処理するかについての推奨事項（アーカイブなど）

憲章の更新とホワイトペーパーの提案プレゼンテーションは、BARBの再提出のために提出する必要があります。view. 再view BARB による憲章更新の承認後、BSTS は、補足ホワイトペーパー提案プレゼンテーションとともに、憲章更新を理事会に提出し、承認を得ます。

理事会が憲章の更新を承認した場合、グループまたは委員会はホワイトペーパーの作成を進めることができます。

グループまたは委員会がホワイトペーパーの開発を完了すると、BSTSは編集レビューを実施します。view Bluetooth ドラフトガイドラインとの一貫性を保つため。

BSTSのコメントが解決された後、グループは法的対応のためにBSTSにホワイトペーパーを提出する必要がある。view法的再審査が完了するとviewグループとBSTSは、ホワイトペーパーに組み込むフィードバックについて合意します。法務担当者から未解決の法的コメントがある場合は、view ホワイトペーパーでは、グループ議長は取締役会の議題に時間を割いて、決議に関する取締役会の意見を求めることができます。

法的再検討と並行してviewグループは、再審査のためにホワイトペーパーをBARBに提出しなければならない。view. 彼らの再viewBARBは、ホワイトペーパーの一部をホワイトペーパーから削除し、セクション3のプロセスに従って仕様に組み込むかどうかを推奨する場合があります。BARBは、ホワイトペーパーを再検討するために他のグループまたは委員会に提出することを決定する場合もあります。viewBARBの再完了後viewグループと BARB は、ホワイトペーパーに組み込むフィードバックについて合意します。

法的にview 実質的な変更、追加の再view BARBによる承認が必要な場合があります。同様に、BARBがview 実質的な変更が生じた場合、BSTSは追加の法的再view これらの変更の完了が必要です。法的再view BARBの再viewBARB はホワイトペーパーを承認または拒否する必要があります。

BARB がホワイトペーパーを承認した後、BARB 承認済みのホワイトペーパーは、作成グループまたは委員会によって理事会に承認のために提出されます。

取締役会がホワイトペーパーを承認し、次の承認後のアクティビティが完了した時点で、ホワイトペーパープロセスは完了します。

BSTSは承認されたホワイトペーパーをBluetooth SIGで公開しました。 webサイト。
BSTS は承認されたホワイトペーパーをすべてのメンバーに通知します。
ホワイトペーパーが既存のホワイトペーパーの拡張である場合、BSTS はメンバーが履歴目的でアクセスできるようにホワイトペーパーのバージョンをアーカイブします。

Bluetooth SIG は、ホワイトペーパーの承認後 1 週間以内に承認後の活動を完了する予定です。

10. 参考文献

参照されているBluetoothドキュメントはBluetoothから入手できます。 webサイト http://www.bluetooth.com.

Bluetoothドラフトガイドライン（ワーキンググループのテンプレートとドキュメントのページで入手可能） https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Bluetooth SIG, Inc.の定款（管理文書ページに掲載） https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Bluetooth仕様のErrata Process文書（ワーキンググループのテンプレートと文書のページで入手可能） https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
ワーキンググループプロセス文書（ワーキンググループテンプレートと文書のページで入手可能） https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
テスト戦略と用語view 文書（資格試験要件ページで入手可能、 https://www.bluetooth.com/specifications/qualification-test-requirements)
BTI仕様についてview プロセスチェックリスト（ワーキンググループのテンプレートとドキュメントのページで入手可能） https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Bluetooth SIG 割り当て番号 (https://www.bluetooth.com/specifications/assigned-numbers)
ワーキンググループのテンプレートとドキュメント（ワーキンググループのテンプレートとドキュメントのページで入手可能） https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
GATT仕様補足（GSS）（GATT仕様ページから入手可能、 https://www.bluetooth.com/specifications/gatt)
新しい仕様のアイデアを提出する https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. 頭字語と略語

表A: 頭字語と略語

付録A – 正誤表の重大度分類

この付録では、仕様のエラッタに対する重大度分類ガイドラインをまとめています。この表は EPD の将来の改訂版に追加され、その後このセクションは削除されます。

このマニュアルの詳細を読む & PDF をダウンロード:

仕様管理プロセス文書（SMPD） – 最適化されたPDF
仕様管理プロセス文書（SMPD） – オリジナルPDF

マニュアルについてご質問がありますか? コメント欄に投稿してください。

参考文献

ユーザーマニュアル