1 序論

1.1 範囲

一般的な属性プロファイル（GATT）は、属性プロトコルを用いたサービスのフレームワークを定義しています。このフレームワークは，サービスとその特性の手順とフォーマットを定義する。定義された手順には、特性の発見、読み込み、書き込み、通知、表示、および特性のブロードキャストの設定が含まれる。

1.2 PROFILE DEPENDENCY

図1.1は、プロファイルの構造と依存関係を示しています。あるプロファイルは、暗黙的または明示的にそのプロファイルを参照することで、そのプロファイルの一部を再利用している場合、別のプロファイルに依存しています。

1.3 コンフォーマンス

このプロファイルへの適合性が主張される場合，このプロファイルに対して必須であると示されたすべての能力は，指定された方法でサポートされなければならない（プロセス必須）。これは，サポートが指示されているすべてのオプション及び条件付き能力にも適用される。すべての必須能力、およびサポートが示されているオプション能力と条件付き能力は、Bluetooth資格プログラムの一部として検証の対象となる。

1.4 BLUETOOTH仕様リリースの互換性

この部分は、BR/EDR物理リンクでプロファイルを使用する場合は仕様のバージョン1.2以上、LE物理リンクでプロファイルを使用する場合はバージョン4.0以上で使用することができる。

1.5 コンベンション

このパートでは、プロシージャ、PDU、オペコード、関数名などのリテラル用語を使用する場合はイタリック体で表記する。また、構造体やパケットなどのフィールドの具体的な名称もイタリック体で表記する。(例：「Primary Service」)の使用は、UUIDを示す。属性プロトコルのエラーコード（[Vol.3] Part F, Table 3.3 参照）は，イタリック体に続いて数値のエラーコードを示す。

2 PROFILE概要

GATTプロファイルは、クライアントがサーバと通信できるように、アプリケーションまたは別のプロファイルで使用するように設計されています。サーバには多数の属性が含まれており，GATTプロファイルは，属性のブロードキャストの設定と同様に，これらの属性の発見，読み取り，書き込み，表示の取得のための属性プロトコルの使用方法を定義している。

2.1 プロトコルスタック

図 2.1 に、このプロファイルで使用されるピア・プロトコルを示す。

2.2 設定と役割

このプロファイルを実装するデバイスには、以下の役割が定義されています。 クライアント - サーバーに向けてコマンドと要求を開始し、サーバーから送信された応答、表示、および通知を受け取ることができるデバイスです。 Server-これは、クライアントからの受信コマンドと要求を受け入れ、クライアントに応答、表示、および通知を送信するデバイスです。 注：役割はデバイスに固定されていません。役割は、デバイスが定義されたプロシージャを開始したときに決定され、プロシージャが終了すると解放されます。 デバイスは同時に両方の役割を果たすことができます。 本プロファイルの役割を示す構成の例を図2.2に示します。 図2.2では、コンピュータが温度サービスクライアントであり、センサが温度サービスサーバである。コンピュータは、センサを構成したり、センサの値を読み取ったりするための手順を開始します。この例では、センサは、温度サービスの一部としてセンサ装置が露出する特性に関する情報を提供し、いくつかの特性の書き込みを許可してもよい。また、センサは適切な値を持つ読み取り要求に応答する。

2.3 ユーザ要求とシナリオ

このプロファイルでは、以下のシナリオが対象となります。

• 構成の交換
• デバイス上のサービスや特性の発見
• 特性値を読み取る
• 特性値の書き方
• 特性値の通知
• 特性値の表示

2.4 プロファイルの基礎

このプロファイルは、ATTベアラとして知られる属性プロトコルL2CAPチャネルを使用して、任意の物理リンク上で使用することができます。ここでは、クライアントとサーバ間の下層要件通信を簡単にまとめます。

• ATTベアラは、セクション6で定義されている「チャネル確立」を使用して確立されます。
• プロファイルの役割は、コントローラのマスター/スレーブの役割に縛られない。
• LE 物理リンクでは、認可、認証、暗号化などのセキュリティ機能の使用はオプションです。BR/EDR 物理リンクでは、暗号化は必須です。
• GATTプロファイル内のマルチオクテットフィールドは、Characteristic Valueフィールドを除いて、最下位オクテッ トが最初に送信される（リトルエンディアン）ものとする。特性を定義する仕様に別段の定義がない限り、特性値とその中のフィールドはリトルエンディアンでなければならない。

2.5 アトリビュートプロトコル

GATT プロファイルでは、第 4.2 節及び第 4.13 節で示された属性プロトコル（ATT）と必要な属性オペコードの実装が必要である。

2.5.1 概要

GATTプロファイルは、デバイス間でコマンド、要求、応答、指示、通知、確認の形でデータを伝送するために属性プロトコルを使用する。このデータは、AttributeプロトコルPDUに含まれている。 オペコードは、特定のコマンド、要求、応答、表示、通知、または確認のオペコードと認証のためのフラグを含む。属性パラメータは、特定のコマンドまたは要求、または応答、指示、または通知で返されるデータを含む。認証署名はオプションであり、[Vol.3]パートH、セクション2.4.5に記述されている。 属性プロトコルのコマンドやリクエストは、サーバ装置の属性に格納された値に基づいて動作する。アトリビュートは4つの部分から構成される。属性は、「属性ハンドル」、「属性タイプ」、「属性値」、「属性権限」の4つの部分から構成される。図 2.4 に属性の論理的表現を示す。所定の実装における実際の表現は、その実装に固有のものである。 属性ハンドルは、特定の属性に対応するインデックスである。Attribute Type」は、「Attribute Value」を記述する UUID である。属性値は、属性タイプによって記述され、属性ハンドルによってインデックス化されたデータである。属性は、属性ハンドルの値を増やすことで順序付けられる。属性ハンドルの値は 0x0001 から 0xFFFF の間の任意の値から始まる。属性ハンドルの値は多い順に並んでいますが、以下の属性ハンドルの値は1つ以上異なる場合があります。すなわち、連続した属性ハンドル間にギャップがある場合がある。この仕様では、2つの属性ハンドルが隣接していなければならない場合や、一方の属性ハンドルが他方の属性ハンドルにすぐに追従することを要求している場合には、このようなギャップは依然として許容されており、無視されるものとする。 Attribute Permissionsは，Attributeプロトコルを用いて読み書きすることができないAttributeの一部である。これは、サーバが与えられた属性に対して読み書きアクセスが許可されているかどうかを判断するために使用される。属性パーミッションは、GATTプロファイル、上位レイヤのプロファイル、または指定されていない場合は実装固有のもので確立される。

2.5.2 属性キャッシング

属性キャッシュとは、クライアントがサーバで使用している属性ハンドルなどの属性情報を一度発見し、再発見せずに再接続時に同じ属性情報を使用できるようにする最適化のことです。クライアントがアトリビュート情報をキャッシュしない場合、クライアントは再接続のたびにアトリビュート情報を再発見しなければなりません。キャッシングを行うことで時間を節約でき、クライアントとサーバ間でかなりの数のパケットを交換する必要がない。クライアントがキャッシュする属性情報は、全てのサーバ属性の属性ハンドルと GATT サービス特性値である。 サーバが使用する属性ハンドルは、時間の経過とともに変化してはならない。これは、一度クライアントによって属性ハンドルが発見されると、その属性の属性ハンドルは変更されてはならないことを意味する。 状況によっては、工場出荷時のリセットやファームウェアのアップグレード手順の実行などにより、サーバーがサービスに使用するアトリビュートハンドルを変更することがあるかもしれません。以下のことは、サーバ上のサービスを追加、変更、削除できる場合にのみサーバ上で必要とされる。サーバ上の GATT ベースのサービスがデバイスの使用可能な寿命の間に変更できない場合、Service Changed 特性はサーバ上に存在してはならず、クライアントは、そのサーバの最初のサービス検出後にサービス検出を実行する必要はない。 サーバが GATT ベースのサービスの変更をサポートしている場合のキャッシングをサポートするために、サーバ上でサービスが追加、削除、または変更されたときに、サーバからクライアントに指示が送信されます。クライアントは、サーバ上にデータベースハッシュ特性が存在する場合には、データベースハッシュ特性を読み取ることでサービスの変更を検出することもできます。 GATTベースのサービスは、サービス定義内でグループ化された関連属性に対する属性ハンドルのバインディングが変更された場合、変更されたとみなされます。 GATT サービス定義の特性値に変更があった場合、「Service Changed」特性値と「Client Supported Features」特性値そのもの以外の変更も変更とみなす。 サーバとの間に信頼された関係（すなわちボンド）を持つクライアントの場合、属性キャッシュは接続をまたいで有効である。サービス変更が発生したときに，信頼された関係を持ち，接続中ではないクライアントについては，サーバは，クライアントがサーバに再接続したときに，指示を送信しなければならない(セクション7.1参照)。サーバとの信頼された関係を持たず，データベースハッシュ特性の読み込みをサポートしないクライアントの場合，属性キャッシュは，接続中のみ有効である。データベースハッシュ特性の読み込みをサポートしている信頼された関係のないクライアントは、接続セットアップ時に属性キャッシュを検証してもよい。信頼された関係のないクライアントは，現在の接続中にのみサービス変更が発生した場合に表示を受ける。 注：キャッシュをサポートしている信頼された関係のないクライアントは、サービス発見を行うか、サーバがService Changed特性をサポートしている場合は、各接続でデータベースハッシュ特性を読み取ってサービス変更を検出しなければならない。 サーバは、クライアントの属性キャッシュで無効とみなされる影響を受ける属性ハンドルの範囲を含むハンドル値表示を送信しなければならない。開始属性ハンドルは、変更を含むサービス定義の開始属性ハンドルとし、終了属性ハンドルは、変更を含むサービス定義の最後の属性ハンドルとする。表示の値は、影響を受ける属性ハンドルの範囲を示すために連結された2つの16ビットの属性ハンドルで構成される。 注：サーバは、サーバ上の属性ハンドルの全セットを再発見することをクライアントに示すために、影響を受ける属性ハンドルの範囲を 0x0001～0xFFFF に設定してもよい。 データベース・ハッシュ特性がサーバ上に存在する場合、サービス変更が発生するたびに、サーバはデータベース・ハッシュ特性値を新しいデータベース・ハッシュで更新しなければならない(セクション7.3参照)。 データベースハッシュ特性値が最後に読み込まれた時から変更されている場合、クライアントはその属性キャッシュを無効とみなし、サービスディスカバリを行うか、アウトオブバンド機構を用いて変更されたデータベース定義を取得するまで、キャッシュされた情報を利用してはならない。 サーバとの間に信頼された関係(すなわち結合)を持つクライアントの場合、属性キャッシュは接続をまたいで有効である。信頼された関係を持ち，サービス変更が発生したときに接続中ではないクライアントについては，サーバは，クライアントがサーバに再接続したときに指示を送信しなければならない(セクション7.1参照)。サーバとの信頼された関係を持たず，データベースハッシュ特性の読み込みをサポートしないクライアントの場合，属性キャッシュは，接続中のみ有効である。データベースハッシュ特性の読み込みをサポートしている信頼された関係のないクライアントは、接続セットアップ時に属性キャッシュを検証してもよい。信頼された関係のないクライアントは，現在の接続中にのみサービス変更が発生した場合に表示を受ける。 注：キャッシュをサポートしている信頼された関係のないクライアントは、サービス発見を行うか、サーバがService Changed特性をサポートしている場合は、各接続でデータベースハッシュ特性を読み取ってサービス変更を検出しなければならない。 サーバは、クライアントの属性キャッシュで無効とみなされる影響を受ける属性ハンドルの範囲を含むハンドル値表示を送信しなければならない。開始属性ハンドルは、変更を含むサービス定義の開始属性ハンドルとし、終了属性ハンドルは、変更を含むサービス定義の最後の属性ハンドルとする。表示の値は、影響を受ける属性ハンドルの範囲を示すために連結された2つの16ビットの属性ハンドルで構成される。 注：サーバは、サーバ上の属性ハンドルの全セットを再発見することをクライアントに示すために、影響を受ける属性ハンドルの範囲を 0x0001～0xFFFF に設定してもよい。 データベース・ハッシュ特性がサーバ上に存在する場合、サービス変更が発生するたびに、サーバはデータベース・ハッシュ特性値を新しいデータベース・ハッシュで更新しなければならない(セクション7.3参照)。 データベースハッシュ特性値が最後に読み込まれた時から変更されている場合、クライアントはその属性キャッシュを無効とみなし、サービスディスカバリを行うか、アウトオブバンド機構を用いて変更されたデータベース定義を取得するまで、キャッシュされた情報を利用してはならない。 クライアントは、影響を受ける属性ハンドルの範囲を含むハンドル値表示を受信した場合、影響を受ける属性ハンドルの範囲にわたって属性キャッシュが無効であると考えなければならない。未解決の要求トランザクションは、属性ハンドルが影響を受ける属性ハンドルの範囲内に含まれている場合、無効であると考えなければならない。クライアントは、影響を受ける属性ハンドルの範囲内にある属性を持つサービスを使用する前に、サービス発見を実行しなければならない。あるいは、クライアントは、データベースハッシュ特性を読み取り、帯域外メカニズムを使用して変更されたデータベース定義を取得してもよい。クライアントがサービス発見中にハンドル値表示を受信した場合、クライアントがサービス発見の前にデータベースハッシュ特性を読んだ場合、クライアントは、現在のサービス発見を継続できるか、または新しいサービス発見が必要かを判断するために、データベースハッシュ特性を再度読んでもよい。 サーバがハンドル値確認を受信すると、サーバは、クライアントが更新された属性ハンドルを認識しているとみなすことができる。 クライアントは、影響を受けた属性ハンドル範囲をその属性キャッシュ内で無効とみなし、属性キャッシュを復元するための発見手順を実行する。サーバは、全ての保税対象機器のサービス変更情報を格納する。

2.5.2.1 ロバストキャッシング

ロバストキャッシングとは，サーバがクライアントがサービス変更を認識していないと判断した場合に，サーバがクライアントにエラー応答を送信する機能である。 データベースハッシュ特性とサービス変更特性の両方がサーバ上に存在する場合、サーバはロバストキャッシング機能をサポートしなければならない。 サーバの観点からは，接続された各クライアントは，データベース定義の変更について「変更を認識している」か「変更を認識していない」かのいずれかである。サーバに接続した後の信頼関係のないクライアントの初期状態は，変更を認識している状態である。信頼された関係を持つクライアントの初期状態は、前回の接続以降にデータベースが更新されていない限り、前回の接続から変更されていません。 サーバーがデータベース定義を更新するたびに、接続されているすべてのクライアントは変更不可となります。接続されているクライアントは、同じ接続中に最新のデータベース変更の後に以下のいずれかが発生した場合、変更を認識するようになります。

• クライアントが Service Changed という表示を受信して確認する(図2.5参照)。
• サーバはクライアントにエラーコードを「Database Out Of Sync」に設定した応答を送信し、その後、サーバはクライアントから別の ATT 要求を受信する（図 2.6 参照）。
• クライアントは Database Hash 特性を読み取り、サーバはクライアントから別の ATT 要求を受信する（図 2.6 参照）。 (Client Supported Features 特性の Robust Caching ビットを設定することで)ロバストキャッシングのサポートを示したクライアントが変更不可の場合、そのクライアントが ATT 要求を送信して属性ハンドルまたは属性ハンドルのリストで操作を要求すると、サーバは操作を実行せず、代わりに Database Out Of Sync に設定されたエラーコードを持つ応答を送信しなければならない。エラー応答は、クライアントが変更を認識しなくなってから一度だけ送られる。クライアントが切断しない限り、またはクライアントが変更を認識する前にデータベースが再び変更されない限り、その場合、エラー応答は再び送られなければならない。変更を認識していないクライアントが ATT コマンドを送信した場合、サーバはそれを無視するものとする。ハンドル値の表示を除いて、サーバは、そのようなクライアントが変更を認識するまで、そのようなクライアントに通知や表示を送信してはならない。クライアントが変更を認識している場合、サーバは通常の操作を行うものとする。 注：通知や表示がブロックされる確率を減らすために、サーバは、サービス変更後、できるだけ早くサービス変更表示を送信すべきである。 クライアントが「Database Out Of Sync」に設定されたエラーコードを持つエラー応答を受信した場合、クライアントはその属性キャッシュを無効とみなし、サービス発見を実行するか、帯域外メカニズムを使用して変更されたデータベース定義を取得するまで、キャッシュされた情報を利用してはならない。

2.5.3 属性のグループ化

汎用属性プロファイルは、3 つの属性タイプの属性のグループ化を定義します。"プライマリサービス"，"セカンダリサービス "及び "特性 "である。グループは宣言で始まり、サービスについては第 3.1 節、特性については第 3.3 節で定義された通りに終了する。グループ化属性の全てが ATT Read By Group Type Request で使用できるわけではない。グループ化タイプ「プライマリサービス」及び「セカンダリサービス」は、グループ化タイプ「Read By Group Type Request」で使用することができる。Characteristic」グループ化タイプは、ATT Read By Group Type Request において使用してはならない。

2.5.4 UUID

すべての 16 ビット UUID は、正確に 2 オクテットに含まれなければならない。すべての 128 ビット UUID は、正確に 16 オクテットに含まれなければならない。 UUID が ATT PDU に含まれる場合は、32 ビット UUID をすべて 128 ビット UUID に変換する。変換方法については、[Vol.3]パート B 2.5.1 節を参照のこと。

2.6 ガットプロファイル階層構造

2.6.1 概要

GATTプロファイルは、プロファイルデータを交換するための構造を規定している。この構造は、プロファイルで使用されるサービスや特性などの基本的な要素を定義しています。これらの要素はすべて属性（Attributes）に含まれている。属性プロトコルで使用される属性は、このプロファイルデータを運ぶコンテナである。 階層の最上位はプロファイルである。プロファイルは、ユースケースを満たすために必要な１つ以上のサービスで構成される。サービスは、他のサービスの特性または包含物で構成される。各特性は、値を含み、その値に関するオプション情報を含んでもよい。サービスと特性及び特性の構成要素（すなわち，値と記述子）は，プロファイルデータを含み，すべてサーバ上の属性に格納される。

2.6.2 サービス

サービスとは、特定の機能や特徴を達成するためのデータと関連する動作の集合体である。GATTでは、サービスはそのサービス定義によって定義される。サービス定義には，含まれるサービス，必須特性，オプション特性を含めることができる。 以前のクライアントとの下位互換性を維持するために、サービス定義の後のバージョンでは、新たに含まれるサービスやオプション特性のみを追加することができます。サービス定義の後のバージョンは、サービス定義の前のバージョンの動作を変更することが禁止されている。 サービスには、プライマリサービスとセカンダリサービスの2種類がある。プライマリサービスは、このデバイスの主に使用可能な機能を公開するサービスである。プライマリサービスは、別のサービスによって含まれることができます。プライマリサービスは、プライマリサービス発見手順を使用して発見することができます。二次サービスは、一次サービスまたは別の二次サービスまたは他の上位レイヤ仕様からのみ含まれることを意図したサービスである。セカンダリサービスは、それを含むエンティティのコンテキストでのみ関連する。 サービスがプライマリサービスであるかセカンダリサービスであるかの決定は、上位レイヤ仕様によって義務付けられることがある。 サービスは、特定のユースケースを満たすために、1つ以上の上位レイヤ仕様で使用されてもよい。 サービスの定義については、セクション 3.1 に記述する。

2.6.3 含まれるサービス

インクルードサービスとは、サーバ上に存在する別のサービス定義を、定義されているサービスに参照する方法です。他のサービスをインクルードするには、サービス定義の先頭にインクルード定義を使用します。サービス定義がインクルード定義を使用してサービスをインクルードする場合、インクルードされたサービス定義全体が新しいサービス定義の一部となります。これには、インクルードされたすべてのサービスとインクルードされたサービスの特性が含まれる。インクルードされたサービスは、依然として独立したサービスとして存在する。他のサービスによって包含されたサービスは、包含の行為によっても、包含されたサービスによっても変更されてはならない。サービス定義におけるインクルード定義の数や入れ子になったインクルードの深さに制限はない。 インクルード定義については、第3.2節に記述する。

2.6.4 特性

特性とは、サービスで使用される値であり、その値がどのようにアクセスされるかに関するプロパティや設定情報、値の表示方法や表現方法に関する情報と一緒に提供される。GATTでは、特性はその特性定義によって定義される。特性定義は、特性宣言、特性プロパティ、値を含み、その値を記述する記述子を含んでもよいし、特性に関連してサーバの設定を許可する記述子を含んでもよい。 特性定義は、セクション3.3に記述されている。

2.7 構成されたブロードキャスト

LE 物理リンクの場合、Configured Broadcast は、クライアントがサーバが Broadcast モード手順を実行しているときに、広告データの中でどの特性値をブロードキャストすべきかをサーバに指示するための方法である。BR/EDR 物理リンクでは、Configured Broadcast はサポートされていません。 Broadcastモード時にサーバがブロードキャストする特性値を設定するには、クライアントは、3.3.3.4節に記載されているブロードキャスト設定ビットを設定する。ブロードキャストの頻度はサービス動作定義の一部である。

3 サービスの相互運用性の要件

3.1 サービスの定義

サービス定義は，サービス宣言を含まなければならず，インクルード定義及び特性定義を含んでもよい。サービス定義は、次のサービス宣言の前、又は属性ハンドルの最大値に達した後に終了する。サービス定義は、属性ハンドルに基づく順にサーバ上に現れる。 サービス定義内に含まれる全てのインクルード定義及び特性定義は，サービスの一部とみなされる。すべてのインクルード定義は，サービス宣言の直後に続き，いかなる特性定義にも先行しなければならない。サービス定義は，0個以上のインクルード定義を持つことができる。すべての特性定義は，最後のインクルード定義の直後，又はインクルード定義がない場合には，サービス宣言の直後でなければならない。サービス定義は，0個以上の特性定義を持つことができる。インクルード定義又は特性定義に上限はない。 サービス宣言は、"プライマリサービス "又は "セカンダリサービス "のUUIDにAttribute Typeを設定したAttributeである。属性値は、サービスの 16 ビットの Bluetooth UUID または 128 ビットの UUID であり、サービス UUID として知られている。クライアントは、16 ビットと 128 ビットの両方の UUUID の使用をサポートしなければならない。クライアントは、不明なサービスUUIDを持つサービス定義を無視してもよい。未知のサービス UUID は、サポートされていないサービスの UUID である。属性権限は読み取り専用であり、認証や認可を必要としないものとする。 複数のサービスが存在する場合には、16ビットのBluetooth UUIDを使用するサービス宣言を持つサービス定義をまとめて(すなわち、順次リストアップして)グループ化し、128ビットのUUIDを使用するサービス宣言を持つサービス定義をまとめてグループ化しなければならない。 デバイスまたはそれ以上のレベルの仕様は、複数のサービス定義を持つことができ、同じサービスUUIDを持つ複数のサービス定義を持つことができる。 サーバー上のすべての属性は、サービス宣言を含むか、サービス定義内に存在しなければならない。 サーバに含まれるサービス定義は，任意の順序で現れることができる。クライアントは，サーバ上のサービス定義の順序を想定してはならない。

3.2 定義を含む

インクルード定義は，一つのインクルード宣言だけを含まなければならない。 インクルード宣言は、Attribute Typeを "Include "のUUIDに設定したAttributeである。属性値には、インクルードされたサービスの属性ハンドル、エンドグループハンドル、及びサービスUUIDを設定しなければならない。サービスUUIDは、UUIDが16ビットのBluetooth UUIDである場合にのみ存在しなければならない。 サーバーは、元のサービスを含む別のサービスへのインクルード定義を持つサービス定義を含んではならない。これは、インクルード定義が参照する各サービスに適用される。これを循環参照という。 クライアントが循環参照を検出した場合、または期待以上にネストされたインクルード宣言を検出した場合は、ATTベアラを終了させるべきである。

3.3 特徴的な定義

特性定義は，特性宣言，特性値宣言を含まなければならず，特性記述子宣言を含んでもよい。特性定義は，次の特性宣言又はサービス宣言の開始時，又は属性ハンドルの最大値の後に終了する。特性定義は、サービス定義内のサーバ上に、属性ハンドルに基づく順序で現れる。 上記の各宣言は、別個の属性に含まれる。必須の宣言は，特性宣言と特性値宣言の２つである。特性値宣言は，特性宣言の直後に存在しなければならない。任意の特性記述子宣言は，特性値宣言の後に置かれる。任意の特性記述子宣言の順序は，重要ではない。 特性定義は、複数の特性値を連結して、単一の集約された特性値にするために定義してもよい。これは、単一の集約された特性値の読み書きを通じて、複数の特性値の読み書きを最適化するために使用されることがあります。このタイプの特性定義は、通常の特性定義と同じである。特性宣言は、特性値に固有の特性UUIDを使用しなければならない。 集約された特性定義を含む。集約された特性定義は、集約された特性値の表示形式を記述する特性集約形式記述子を含んでもよい。

3.3.1 特性宣言

特性宣言は、「特性」のUUIDにAttribute Typeを設定し、特性プロパティ、特性値属性ハンドル、特性UUIDにAttribute Valueを設定した属性である。属性パーミッションは、読み取り可能なものでなければならず、認証や認可を必要としないものでなければならない。 特性宣言の属性値は，サーバが任意のクライアントと信頼関係を持っている間は，変更してはならない。

特性宣言の属性値は，読み取り専用である。

1 つのサービスは、同じ特性 UUID を持つ複数の特性定義を持つことができる。 サービス定義の中には，いくつかの特性が必須である場合があり，それらの特性は，インクルード宣言の後で，サービス定義の中の任意の特性の前に配置されなければならない。クライアントは，サービス定義内で，必須である特性の順序又は任意である特性の順序を想定してはならない。可能な限り，前に述べた要件の範囲内で，16ビットのBluetooth UUIDを使用する特性宣言を持つ特性定義は，まとめて（すなわち，順番に列挙して），128ビットのUUIDを使用する特性宣言を持つ特性定義は，まとめてグループ化することが望ましい。

3.3.1.1 特性特性

特性特性ビットフィールドは、特性値がどのように使用できるか、または特性記述子（3.3.3項参照）がどのようにアクセスできるかを決定する。表3.5で定義されているビットが設定されている場合，記述されている動作が許可される。複数の特性特性を設定することができる。 これらのビットは，セキュリティ要件に関係なく，上位層の仕様で定義されているように，この特性に対して許可された手順に従って設定しなければならない。

3.3.1.2 特性値属性ハンドル

特性値属性ハンドルは、特性値を含む属性の属性ハンドルである。

3.3.1.3 キャラクター UUID

Characteristic UUIDフィールドは、16ビットのBluetooth UUIDまたは128ビットのUUIDであり、キャラクタリスティック値のタイプを記述する。クライアントは、16ビット及び128ビットの両方の特性UUIDの使用をサポートしなければならない。クライアントは、未知の特性UUIDを持つ特性定義を無視してもよい。未知の特性 UUIDは、サポートされていない特性のUUIDである。

3.3.2 特性値宣言

特性値宣言は、特性の値を含む。これは，特性宣言の後の最初の属性である。すべての特性定義は、特性値宣言を持たなければならない。 特性値宣言は、特性宣言で使用される特性値の 16 ビット Bluetooth または 128 ビット UUID に Attribute Type を設定した属性である。属性値には、特性値が設定されている。属性の許可は、サービスによって指定されるか、特に指定がない場合は実装固有のものとすることができる。

3.3.3 特性記述子宣言

特性記述子は、特性値に関する関連情報を含むために使用される。GATTプロファイルは、上位レイヤプロファイルで使用できる特性記述子の標準セットを定義している。高次レイヤプロファイルは、プロファイル固有の追加の特性記述子を定義してもよい。各特性記述子は、特性記述子 UUID によって識別される。クライアントは，16 ビット及び 128 ビットの特性記述子 UUID の両方の使用をサポートしなければならない。クライアントは，未知の特性記述子UUIDを持つ特性記述子宣言を無視してもよい。未知の特性記述子 UUID は，サポートされていない特性記述子に対する UUUID である。 特性定義内に存在する場合，特性記述子は，特性値宣言に従わなければならない。特性記述子宣言は，特性定義内でどのような順序で現れてもよい。クライアントは，特性定義内で特性記述子宣言が特性値宣言に続いて現れる順序を想定してはならない。 特性記述子宣言の許可は，上位レイヤプロファイルによって定義されているか，又は実装固有のものである。クライアントは，すべての特性記述子宣言が読み取れると仮定してはならない。

3.3.3.1 特徴的な拡張特性

特性拡張特性宣言は，追加の特性特性を定義する記述子である。特性特性特性の拡張特性ビットが設定されている場合，この特性記述子は存在しなければならない。特性記述子は，特性定義内の特性値の後のどの位置にも存在することができる。特性定義内には，１つの特性拡張特性宣言のみが存在しなければならない。 特性記述子は，属性に含まれ，属性タイプは "特性拡張特性 "のUUIDに設定され，属性値は "特性拡張特性ビットフィールド "でなければならない。属性パーミッションは、認証及び認可を必要とせずに読み取れるものとする。 特性拡張特性ビットフィールドは，特性値がどのように使用できるか，又は特性記述子(3.3.3.3項参照)がどのようにアクセスできるかについての追加特性を記述する。表3.8に定義されているビットが設定されている場合，記述されている動作が許可される。複数の特性プロパティを設定することができる。

3.3.3.2 特性ユーザ記述

Characteristic User Description宣言は、オプションの特性記述子であり、可変サイズのUTF-8文字列を定義します。特性プロパティの書き込み可能補助ビットが設定されている場合、この特性記述子を書き込むことができます。特性記述子は、特性定義内の特性値の後の任意の位置に記述することができる。特性定義内には，1つの特性定義内に1つの特性ユーザ記述宣言のみが存在するものとする。 特性記述子は、属性に含まれ、属性タイプは、「特性ユーザ記述」のUUIDに設定し、属性値は、特性ユーザ記述のUTF-8文字列に設定しなければならない。属性権限は、プロファイルによって指定されるか、特に指定がない場合は、実装固有のものであってもよい。

3.3.3.3 クライアント特性設定

クライアント特性構成宣言は、特性が特定のクライアントによってどのように構成されるかを定義するオプションの特性記述子である。クライアント特性構成記述子の値は、保税されたデバイスの接続間で永続的でなければならない。クライアント特性設定記述子の値は、非結合デバイスとの各接続において、デフォルト値に設定されなければならない。特性記述子の値はビットフィールドであり、ビットが設定されている場合はその動作を有効とし、設定されていない場合は使用しない。クライアント特性設定記述子は、特性定義内の特性値の後の任意の位置に出現することができる。1 つの特性定義には、1 つのクライアント特性構成宣言だけが存在しなければならない。 クライアントは，クライアントのためにサーバ上でこの特性の構成を制御するために，この構成記述子を記述してもよい。各クライアントは，クライアント特性設定の独自のインスタンスを持つ。クライアント特性設定の読み取りは、そのクライアントの設定のみを示し、書き込みは、そのクライアントの設定にのみ影響を与えます。設定記述子の書き込みには、サーバによる認証と認可が必要な場合がある。クライアント特性構成宣言は，読み書き可能でなければならない。 特性記述子は、属性に含まれる。属性種別には、「クライアント特性設定」の UUUID を設定する。属性値には、特性記述子の値を設定する。属性の許可は、プロファイルによって指定されるか、又は、以下の場合には、実装固有のものであってもよい。 指定されていない場合は、次のビットが定義される。 次のクライアント特性設定ビットを定義する。 Client Characteristic Configuration 記述子のデフォルト値は 0x0000 である。 GATT サーバが同一デバイスからの複数の ATT ベアラをサポートしている場合、各 ATT ベアラは別個の GATT クライアントインスタンスを持つものとみなす。そのため、各 GATT クライアントは個別のクライアント特性設定を持つものとする。

3.3.3.4 サーバー特性設定

サーバー特性構成宣言は、特性がサーバーに対してどのように構成されるかを定義するオプションの特性記述子である。特性記述子の値は、ビットフィールドである。ビットが設定されている場合、そのアクションは有効にしなければならず、そうでない場合は使用されない。サーバー特性構成記述子は、特性定義内の特性値の後の任意の位置に出現することができる。1 つの特性定義には、1 つのサーバー特性構成宣言のみが存在しなければならない。サーバー特性構成宣言は、読み取り可能であり、書き込み可能でなければならない。 クライアントは，この構成記述子を記述して，すべてのクライアントに対してサーバ上のこの特性の構成を制御することができる。すべてのクライアントに対して，サーバー特性構成の単一のインスタンスが存在する。サーバー特性構成の読み取りはすべてのクライアントの構成を示し、書き込みはすべてのクライアントの構成に影響を与えます。構成記述子の書き込みには、サーバーによって認証と認可が必要な場合があります。 特性記述子は、属性に含まれる。Attribute Type には、「Server Characteristic Configuration」の UUID を設定しなければならない。属性値には、特性記述子の値を設定しなければならない。属性の権限は、プロファイルで指定するか、指定がない場合は実装固有のものとする。

以下のサーバー特性設定ビットを定義する。

3.3.3.5 特性提示形式

特性提示形式宣言は、特性値の形式を定義するオプションの特性記述子である。特性記述子は、特性定義内の特性値の後のどの位置にも存在することができる。特性定義内に２つ以上の特性提示フォーマット宣言が存在する場合、特性定義の一部として特性集約フォーマット宣言が存在しなければならない。 特性書式値は，書式，指数，単位，名前空間，記述の5つの部分から構成される。 特性記述子は，属性に含まれる。属性種別には、「特性提示形式」のUUIDを設定しなければならない。また、属性の種類は、「特性提示形式」のUUIDを設定する。

属性値は、特性記述子の値を設定する。属性値は、特性記述子の値に 許可は、読み取りのみとし、認証や認可を必要としないこととする。

Characteristic Presentation Format 記述子の属性値フィールドの定義は次のとおりである。

3.3.3.5.1 ビット順序

文字表示フォーマットのビット順は、リトルエンディアンとする。

3.3.3.5.2 フォーマット

フォーマットフィールドは、特性値に含まれる単一の値がどのようにフォーマットされるかを決定する。フォーマットがオクテットの整数でない場合、データは、値を含むことができる最小のオクテット数に格納されなければならない。データは，最後のオクテットの最上位ビットを除いて，各オクテットの全体を占めなければならない。 符号付き整数は 2 の補数表現を使用する。

IPv4 アドレスをエンコードする場合は、uint32 形式を使用する。IPv4 アドレスをエンコードする場合は uint32 形式、IPv6 アドレスをエンコードする場合は uint128 形式とする。Bluetooth BD_ADDR をエンコードする場合は、uint48 フォーマットを使用する。duint16 は、uint16 の 2 つの値を連結したものである。

3.3.3.5.3 指数

指数フィールドは、整数データ型で使用され、値がどのようにフォーマットされるかを決定します。指数フィールドは、表3.16のフォーマットフィールドで示されているように、整数フォーマットタイプでのみ使用されます。指数フィールドは、2の補数の符号付き整数です。

実際の値 = 特性値 * 10Exponent 上の式からわかるように、実際の値は、特性値と値１０の累乗指数の組み合わせである。これを定点数と呼ぶこともある。 例えば、指数が２で、特性値が２３であれば、実際の値は２３００となる。 例えば、指数が-3で特性値が3892の場合、実際の値は3.892となります。

3.3.3.5.4 単位

ユニットは、Assigned Numbers[1]で定義されているUUIDである。

3.3.3.5.5 名前空間

名前空間フィールドは、Assigned Numbers[1]で定義されているように、記述フィールドの列挙を定義する責任のある組織を識別するために使用される。

3.3.3.5.6 説明

説明」は、「名前空間」フィールドで識別される組織の「割り当て番号」[1]で定義された列挙値である。

3.3.3.6 特性集約フォーマット

Characteristic Aggregate Format 宣言は、集約されたキャラクタリスティック値のフォーマットを定義するオプションの特性記述子である。 特性記述子は、特性定義内の特性値の後のどの位置にも存在することができる。特性定義内には、1つの特性定義内に1つの特性集約フォーマット宣言のみが存在するものとする。 特性集合フォーマット値は、特性提示フォーマット宣言の属性ハンドルのリストで構成され、各属性ハンドルは、特性提示フォーマット宣言を指す。 属性権限は、読み取り専用であり、認証や認可を必要としない。 属性ハンドルのリストは、複数の16ビットの属性ハンドル値を1つの属性値に連結したものである。このリストには、特性提示フォーマット宣言のための少なくとも 2 つの属性ハンドルが含まれなければならない。特性値は、属性ハンドルが指す特性提示形式の宣言ごとに分解されなければならない。リスト内の属性ハンドルの順序は、重要である。 特性定義に複数の特性提示形式宣言が存在する場合，特性集約形式宣言も1つ存在しなければならない。特性集合形式宣言は、特性定義内の各特性提示形式宣言を属性ハンドルのリストに含めなければならない。他の特性定義からの特性提示形式宣言も使用することができる。 特性定義に存在する特性提示形式宣言がなくても，特性集約形式宣言が存在してもよい。特性集約形式宣言は、他の特性定義からの特性提示形式宣言を使用することができる。

3.4 ガットプロフィール属性タイプの概要

表 3.18 は，GATT プロファイルで定義された属性タイプをまとめたものである。

---

中略

7 定義済みジェネリック属性プロファイルサービス

この節で定義されているすべての特性は、第3.1節で定義されているように、サービスUUIDが「GATTサービス」に設定されているプライマリサービスに含まれていなければならない。GATTサービスの1つのインスタンスのみが，GATTサーバ上で公開されなければならない。 表 7.1 に、サーバに存在する可能性のある特性と、クライアントがサポートする可能性のある特性を示す。

7.1 サービスの変更

Service Changed」特性は、サービスが変更されたこと（すなわち、追加、削除、変更）を接続された機器に示すために使用される制御点属性（[Vol 3] Part F、3.2.6 節で定義）である。この特性は、サーバと信頼関係(すなわち結合)を持つクライアントがサーバに再接続した際に、GATTベースのサービスが変更された場合に、サーバとの間で信頼関係(すなわち結合)を持つクライアントに示すために使用されなければならない。2.5.2節を参照のこと。 この特性値は、クライアントがクライアント特性設定記述子を使用して表示するように設定しなければならない。クライアントがクライアント特性設定記述子での表示を有効にしていない場合は、 サービス変更後特性値の変更による表示は、失われたものとみなす。 変更されたサービス特性値は、サーバ上の GATT ベースのサービスへの追加、削除、または変更によって影響を受ける属性ハンドルの先頭と末尾を示す 2 つの 16 ビットの属性ハンドルを連結したものである。特性値の変更は、サービスの変更とはみなされない。GATT サービス定義の特性値のうち、変更されたサービスの特性値とクライアントがサポートする機能の特性値以外に変更があった場合、その範囲には GATT サービス定義の開始と終了の属性ハンドルも含まれなければならない。 GATT サービス定義内には、変更後のサービス特性のインスタンスは 1 つのみとする。変更されたサービス特性値は、信頼された関係を持つ各クライアントに対して存在しなければならない。 GATT ベースのサービスのリストとサービス定義がデバイスの寿命の間変更できない場合は、この特性は存在してはならず、そうでない場合は、この特性は存在しなければならない。 Service Changed特性がサーバ上に存在する場合、サーバ上での特性値表示のサポートは必須である。 クライアントは、サービス変更後の特性の特性値表示をサポートしなければならない。

7.2 クライアントがサポートする機能

クライアントがサポートする機能特性は、クライアントがサポートする機能をサーバーに通知するために、クライアントが使用する。この特性がサーバ上に存在する場合、クライアントは、クライアントがサポートする機能ビットフィールドを更新してもよい。クライアントによってクライアント特徴ビットが設定され、サーバーがその特徴をサポートしている場合、サーバーは、このクライアントと通信する際に、この特徴に関連するすべての要件を満たさなければならない。 クライアントがサポートする機能特性のフォーマットを表7.5に定義する。 クライアントがサポートする機能特性の値は、オクテットの配列であり、それぞれがビットフィールドである。これらのビットの割り当てを表 7.6 に示す。リストされていないすべてのビットは将来の使用のために予約されている。この配列は，末尾にゼロオクテットがあってはならない。 表 7.6 のオクテット番号が短すぎるために属性値に現れない場合、サーバは、そのオクテットがゼロの値で存在するかのように振る舞わなければならない。 クライアントサポート機能特性値のデフォルト値は、すべてのビットがゼロに設定されていなければならない。 GATT サービス定義内には、クライアントサポート機能特性のインスタンスは 1 つだけでなければならない。 クライアントサポート機能特性値は、接続しているクライアントごとに存在しなければならない。信頼された関係を持つクライアントの場合、特性値は、接続をまたいで永続的でなければならない。信頼関係のないクライアントの場合、特性値は接続ごとにデフォルト値に設定されなければならない。 サーバ上のクライアントサポート機能特性の属性ハンドルは、接続中又はサーバがクライアントと信頼関係を持っている場合には、変更してはならない。 クライアントは，設定したビットをクリアしてはならない。サーバは、このような要求に対して、エラーコードを「許可されていない値」に設定して応答しなければならない。

7.3 データベースハッシュ

データベースハッシュ特性は、GATT データベース内のサービス定義に適用されたハッシュ関数の結果を含む。クライアントは、サービスが追加されたか、削除されたか、または変更されたかどうかを判断するために、いつでもこの特性を読むことができる。ハッシュ関数への入力フィールド（7.3.1項に記載）のいずれかが変更された場合、サーバは新しいデータベースハッシュを計算し、特性値を更新しなければならない。 データベースハッシュ特性は，読み取り専用属性である。 特性値は 128 ビットの符号なし整数値である。データベースハッシュの計算は 7.3.1 節に規定する。 データベースハッシュ特性のインスタンスは GATT サービス定義内に 1 つだけ存在する。信頼関係が存在するか否かに関わらず、全てのクライアントで同じデータベースハッシュ値が使用される。 この特性の値を読み込むために、クライアントは常に GATT Read Using Characteristic UUID サブプロシージャを使用しなければならない。 サーバがデータベースへの変更後にハッシュを再計算している間にクライアントがこの特性の値を読み出す場合、サーバは新しいハッシュを返し、それが利用可能になるまで応答を遅らせるものとする。

7.3.1 データベースハッシュ計算

データベースハッシュは、RFC-4493[2]に従って算出する。このRFCでは、ブロック暗号関数としてAES-128を用いた暗号ベースのメッセージ認証コード(CMAC)を定義しており、AES-CMACとも呼ばれている。 AES-CMACへの入力は以下の通りである。

m はハッシュ化される可変長データである． k は 128 ビットの鍵であり、すべてゼロ（0x00000000_00000000_00000000_00000000）とする。

128ビットのデータベースハッシュは、以下のように生成される。 データベースハッシュ = AES-CMACk(m) ここで，m は以下のように計算される．

属性ハンドルの昇順に，最初のハンドルから順に，Attribute Handle，Attribute Type，Attribute Value を連結し，属性が以下のいずれかのタイプを持つ場合には，Attribute Handle，Attribute Type，Attribute Value を連結する．"プライマリサービス」、「セカンダリサービス」、「インクルードサービス」、「特性」、「特性拡張プロパティ」のいずれかを持つ属性の場合は、属性ハンドル、属性タイプ、属性値を連結する。属性が "特性ユーザ記述"、"クライアント特性設定"、"サーバ特性設定"、"特性フォーマット"、または "特性集計フォーマット "のいずれかのタイプを持っている場合は、属性ハンドルと属性タイプを連結し、それ以外のタイプを持っている場合は、その属性を無視する（そのような属性は連結の一部ではない）。 各属性ハンドルについて、フィールドは上記の順序で連結されなければならない。各フィールド又はサブフィールド値に使用されるバイト順序はリトルエンディアンでなければならない。フィールドがサブフィールドを含む場合、サブフィールドは、セクション3(サービス相互運用性要件)に示されている順序で連結されなければならない。例えば、{0x02, 0x0005, 0x2A00}の特性宣言値は、連結後に 02 05 00 00 2A として表現される。

上記の属性タイプの属性ハンドル、属性タイプ、属性値のフォーマットは、第 3 節（サービス相互運用性要件）で規定する。 m の長さが AES-CMAC のブロック長 128 ビットの倍数でない場合は、RFC-4493 節 2.4 に規定されているようにパディングを行う。

8 セキュリティに関する考察

8.1 認証要件

GATTプロファイルにおける認証は，各特性に独立して適用される。認証要件は，このプロファイル，関連する上位層の仕様で規定されているか，あるいは，特に指定されていない場合には実装固有のものである。 GATTプロファイルの手順は、特性が読み書きされる前に、クライアントが認証され、暗号化された接続を持つことを要求する可能性がある情報にアクセスするために使用される。 物理リンクが認証されていないか，又は暗号化されていないときにそのような要求が出された場合，サーバは，エラー応答を送らなければならない。この特性の読み取り又は書き込みを望むクライアントは，その後，物理リンクがGAP認証手順を用いて認証されるように要求することができ，これが完了したら，再度要求を送信する。 デバイスがサポートするサービス及び特性のリストは，プライベート情報又は機密情報とはみなされないので，サービス及び特性発見手順は常に許可されなければならない。これは，不十分な認証エラーコードが，情報検索要求に対するエラー応答で使用されてはならないことを意味する。 備考：特性は、どのデバイスでも読み取りを許可されてもよいが、書き込まれるのは認証されたデバイスのみである。実装は、これを考慮に入れなければならず、特性値を読み取ることができれば、特性値を書き込むこともできると仮定してはならない。同様に、ある特性が書き込める場合、その特性が読み込めるとは限らない。個々の特性は、それぞれ異なるセキュリティ特性を持つ可能性がある。 サービス定義内の１つの特性へのアクセスを許可するためにクライアントの十分な認証が確立されると，サーバは，より高いレベルの要件又は実装固有の要件に応じて，サービス定義内の他の特性へのアクセスを許可してもよい。 サーバは，十分な認証が行われると，サービス定義内のほとんどの特性へのアクセスを許可してもよいが，同じサービス定義内の他の特性へのアクセスを制限してもよい。これは、現在有効になっている認証要件よりも強い認証要件を必要とする特性があるために生じることがある。 サーバがあるサービス定義内の特性へのアクセスのためにクライアントを認証すると，サーバは，他のサービス定義内の特性へのアクセスを自動的に許可してもよい。

8.2 認証要件

GATTプロファイルにおける認可は，各特性に独立して適用される。承認要件は，このプロファイル，関連する上位層仕様で規定されていてもよいし，別段の規定がない場合は，実装固有のものである。 GATTプロファイルは，特性が読み書きされる前に認可を必要とする可能性のある情報にアクセスするために使用することができる。 そのような要求が，認可されていないサービス定義に含まれる特性に対して発行された場合，レスポンダは，エラーコードをInsufficient Authorizationに設定したエラー応答を送信しなければならない。 サーバが，一つのグループ又はサービス定義内の特性へのアクセスをクライアントに許可すると，サーバは，他のサービス定義内の特性へのアクセスを自動的に許可してもよい。