第4章 論理フレーム構造

4.1 フレームの構成

Logical_Frame（論理フレーム）は DTP のアプリケーション層フレーム構造であり、2つの部分で構成されます：

┌─────────────────────────────────────────┐
│              Logical_Frame               │
├─────────────────────────────────────────┤
│  Header（フレームヘッダー）                │
│  ┌─────────────────────────────────────┐│
│  │ protocolVersion   プロトコルバージョン ││
│  │ frameType         フレームタイプ識別   ││
│  │ fragmentId        Fragment 一意識別子 ││
│  │ agreementId       Agreement ID（圧縮可）││
│  │ originTimestamp   オリジナルタイムスタンプ││
│  │ dagDependencies   DAG 依存リスト      ││
│  │ encryptionMetadata 暗号化メタデータ   ││
│  │ sequenceNumber    シーケンス番号      ││
│  └─────────────────────────────────────┘│
├─────────────────────────────────────────┤
│  Payload（ペイロード）                    │
│  ┌─────────────────────────────────────┐│
│  │ 暗号化された実際のデータ内容            ││
│  └─────────────────────────────────────┘│
└─────────────────────────────────────────┘

主要な設計上の決定：

• フレームヘッダー内の暗号化メタデータ自体は暗号化されない。受信側が復号方法を判断できるようにするため
• Logical_Frame は端末→Fay と Fay→端末の両方向で同一のフレーム構造定義を使用
• 物理伝送でフラグメンテーションが必要な場合、分割処理は下位の Transport_Adapter に委譲し、Logical_Frame は完全性を維持

4.2 フレームタイプ

DTP は4種類のフレームタイプを定義します：

フレームタイプ	識別子	用途
データフレーム	data	実際の Fragment データを搬送
リクエストフレーム	request	データリクエストの発行またはアグリーメントの調整
レスポンスフレーム	response	データリクエストへの応答、承認・拒否・ネゴシエーション結果を含む
コントロールフレーム	control	エラー通知、アグリーメント終了などの制御情報を伝達

4.3 フレームヘッダーフィールド詳細

プロトコルバージョン（protocolVersion）

{ major: number, minor: number }

現在のフレームが使用するプロトコルバージョンを示します。受信側はこれに基づいて互換性を判断します。

フレームタイプ識別（frameType）

フレームのタイプを示し、ペイロードの解析方法を決定します。

Fragment 一意識別子（fragmentId）

グローバルに一意な UUID v4 識別子で、DAG 内での参照と追跡に使用されます。

Agreement ID（agreementId）

その Fragment が所属するアグリーメントを示します。圧縮伝送をサポート：連続する Fragment が同一アグリーメントに属する場合、そのバッチの最初の Fragment のヘッダーにのみ完全な Agreement_ID を含め、後続の Fragment では省略可能（null に設定）です。

受信側のルール：

• Agreement_ID を含まない Fragment を受信した場合、現在のコンテキストで最後に宣言された Agreement_ID に関連付ける
• 未知の Agreement_ID を参照する Fragment を受信した場合、その Fragment を破棄し「アグリーメント不存在」エラー通知を送信

オリジナルタイムスタンプ（originTimestamp）

データがソース側で実際に生成された時刻で、UTC タイムゾーンとミリ秒精度を使用します。伝送タイムスタンプとは分離して保存され、伝送遅延の影響を受けません。

例：ユーザーが地下鉄内でオフラインのまま30分間の心拍データを記録し、駅を出た後に一括アップロードした場合——各レコードが保持するのは実際の測定時刻のタイムスタンプであり、アップロード時刻ではありません。

DAG 依存リスト（dagDependencies）

他の Fragment との依存関係を宣言し、各依存には以下が含まれます：

• 対象 Fragment_ID
• 関係タイプ（derived_from / annotates / supersedes）

ゼロ個以上の依存関係の宣言をサポートします。

暗号化メタデータ（encryptionMetadata）

{ algorithm: string, keyVersion: number }

• algorithm：暗号化アルゴリズム識別子（例："AES-256-GCM"）
• keyVersion：鍵バージョン番号

暗号化メタデータ自体は暗号化されず、受信側が復号パラメータを確認できるようにします。

シーケンス番号（sequenceNumber）

伝送シーケンス番号で、単一セッション内で単調増加し、再開メカニズムに使用されます。各伝送方向で独立したシーケンス番号空間を維持します。

4.4 シリアライズとデシリアライズ

DTP_Engine は Logical_Frame オブジェクトをバイナリ形式にシリアライズして伝送し、受信側はバイナリデータを Logical_Frame オブジェクトにデシリアライズします。

コア保証——ラウンドトリップ一貫性：任意の有効な Logical_Frame オブジェクトに対して、シリアライズ後にデシリアライズすると、元のオブジェクトと等価な Logical_Frame が生成されます。

DTP_Engine はフォーマット出力機能（Pretty Printer）も提供し、Logical_Frame オブジェクトを人間が読めるテキスト形式に変換して、デバッグやログ記録を容易にします。

4.5 コンテキストメタデータ

各 Fragment は構造化されたコンテキストメタデータ（ContextMetadata）を携帯し、以下を含みます：

• データタイプ識別（dataType）：データのタイプを記述
• データソース（source）：ハードウェアソースとソフトウェアソースを区別
• カスタムフィールド（customFields）：拡張可能なキーバリューペア構造

ハードウェアソース

データがハードウェアセンサーに由来する場合、メタデータには以下が含まれます：

• センサータイプ（sensorType）
• センサー精度（precision）
• サンプリングレート（samplingRate、単位 Hz）

ソフトウェアソース

データがソフトウェア共有に由来する場合、メタデータには以下が含まれます：

• ソースアプリケーション識別子（appIdentifier）
• 共有方法の説明（sharingMethod）