(57)【要約】      （修正有）【課題】  リアルタイム制御プロトコル（ＲＴＣＰ）トラフィックに関する帯域幅効率を最適化し、ＲＴＣＰレポート／フィードバックの間隔を短くする。【解決手段】  リアルタイムトランスポートプロトコル（ＲＴＰ）およびリアルタイム制御プロトコル（ＲＴＣＰ）を用いるメディアデータ送信における制御トラフィックを圧縮する方法に関し、上記方法は、特に、利用可能なセッション帯域幅の割り当て部分内でのインターネットプロトコル（ＩＰ）ネットワークのリアルタイムまたは準リアルタイムマルチメディア配信に用いられる。最初にコンテキストパラメータを送信することによって制御トラフィックフローのコンテキストを初期化するステップ、および必要に応じて、圧縮された制御パケットを用いてセッション中に前記コンテキストをアップデートするステップを含む方法を提供する。【選択図】  なし【特許請求の範囲】
【請求項１】
リアルタイムトランスポートプロトコル（ＲＴＰ）およびリアルタイム制御プロトコル（ＲＴＣＰ）を用いるメディアデータ送信における制御トラフィックを圧縮する方法であって、特に、利用可能なセッション帯域幅の割り当て部分内でのインターネットプロトコル（ＩＰ）ネットワークのリアルタイムまたは準リアルタイムマルチメディア配信に用いられ、該方法は、
最初にコンテキストパラメータを送信することによって制御トラフィックフローのコンテキストを初期化するステップと、
必要に応じて、圧縮された制御パケットを用いてセッション中に前記コンテキストをアップデートするステップと、
を包含する、方法。
【請求項２】
前記コンテキストパラメータは静的コンテキストパラメータおよび動的コンテキストパラメータに分類される、請求項１に記載の方法。
【請求項３】
既知のコンテキストパラメータを除外するステップをさらに包含する、請求項１または２に記載の方法。
【請求項４】
前記静的コンテキストパラメータは、少なくとも１つの初期化パケットで送信される、請求項１〜３のうちの１つに記載の方法。
【請求項５】
前記動的コンテキストパラメータは、初期化パケット、リフレッシュパケットまたは圧縮された制御パケットで送信される、請求項１〜４のうちの１つに記載の方法。
【請求項６】
前記動的コンテキストパラメータは、さらにソース記述（ＳＤＥＳ）パケットおよびバイパケット（ＢＹＥ  ｐａｃｋｅｔｓ）で送信される、請求項５に記載の方法。
【請求項７】
コンプレッサとデコンプレッサとの間の圧縮された制御データの送信に用いられ、
前記初期化するステップの前に、前記初期化パケット、前記リフレッシュパケット、前記圧縮された制御パケット、ならびにコンプレッサおよびデコンプレッサコンテキストパラメータのパケットフォーマットを定義するステップをさらに包含する、請求項５または６に記載の方法。
【請求項８】
必要に応じて、前記デコンプレッサで同期していないコンテキストを修復および回復するステップをさらに包含する、請求項７に記載の方法。
【請求項９】
前記初期化するステップは、前記動的コンテキストパラメータの初期設定値を参照値として送信する、請求項２〜８のうちの１つに記載の方法。
【請求項１０】
送信前の前記静的コンテキストパラメータから少なくとも１つの初期化パケットを形成するステップをさらに包含する、請求項２〜９のうちの１つに記載の方法。
【請求項１１】
送信前の前記動的コンテキストパラメータからリフレッシュパケットおよび圧縮された制御パケットを形成するステップをさらに包含する、請求項２〜１０のうちの１つに記載の方法。
【請求項１２】
前記リフレッシュパケットおよび圧縮された制御パケットを形成するステップは、ソース記述パケットおよびバイパケットをさらに形成する、請求項１１に記載の方法。
【請求項１３】
前記動的コンテキストパラメータを、随時変化するコンテキストパラメータ、ランダムキャラクタのコンテキストパラメータ、カウンタコンテキストパラメータ、頻繁に変化するコンテキストパラメータ、および定期的に一定の変化量だけ変化するコンテキストパラメータに分類するステップをさらに包含する、請求項２〜１２のうちの１つに記載の方法。
【請求項１４】
最下位ビット（ＬＳＢ）エンコーディングを用いて、前記カウンタコンテキストパラメータ、前記頻繁に変化するコンテキストパラメータ、および前記定期的に一定の変化量だけ変化するコンテキストパラメータを符号化するステップをさらに包含する、請求項１３に記載の方法。
【請求項１５】
前記リフレッシュパケットおよび圧縮された制御パケットを形成するステップは、符号化されていない随時変化するコンテキストパラメータおよびランダムキャラクタのコンテキストパラメータを形成されたパケットに組み込み、符号化されたカウンタコンテキストパラメータ、頻繁に変化するコンテキストパラメータおよび定期的に一定の変化量だけ変化するコンテキストパラメータをパケットに組み込む、請求項１２〜１４のうちの１つに記載の方法。
【請求項１６】
前記既知のコンテキストパラメータは制御プロトコルバージョンを含む、請求項３〜１４のうちの１つに記載の方法。
【請求項１７】
前記静的コンテキストパラメータは、
送信者レポートパケットが該送信者レポートパケットの末尾にコンテキストパラメータの一部ではない付加的なパディングフィールドを含むか否かを示すパディングフラグと、
パケット送信者またはメディアデータ送信のソースを特定する少なくとも１つの同期ソース（ＳＳＲＣ）識別子と、
データパケットに内容を追加する少なくとも１つのソースを特定する少なくとも１つの貢献ソース（ＣＳＲＣ）と、
を含む、請求項２〜１６のうちの１つに記載の方法。
【請求項１８】
前記随時変化するコンテキストパラメータはパケットの複数のフィールドを含み、
該複数のフィールドは、
前記パケット内のレポートブロックの数を示す受信レポート数（ＲＣ）フィールドと、
ソース記述（ＳＤＥＳ）パケット内の同期ソース（ＳＳＲＣ）もしくは貢献ソース（ＣＳＲＣ）の数を示すか、またはバイパケット内の同期ソース（ＳＳＲＣ）もしくは貢献ソース（ＣＳＲＣ）の数を特定するソース数（ＳＣ）フィールドと、
パケットタイプを特定するペイロードタイプ（ＰＴ）フィールドと、
パケットソースの属性を記述する情報を含むソース記述（ＳＤＥＳ）アイテムと、
一組のアプリケーション定義（ＡＰＰ）パケットが１つの固有名称で定義されることを可能にするアプリケーション定義（ＡＰＰ）パケット内のサブタイプフィールドと、
を含む、請求項１３〜１７のうちの１つに記載の方法。
【請求項１９】
前記ソース記述（ＳＤＥＳ）アイテムは、
ソースのユーザ名およびドメイン名を記述する標準エンドポイント識別子（ＣＮＡＭＥ）アイテムと、
ソースの一般名称を記述するユーザ名（ＮＡＭＥ）アイテムと、
ソースの電子メールアドレスを記述する電子メールアドレス（ＥＭＡＩＬ）アイテムと、
ソースの電話番号を記述する電話番号（ＰＨＯＮＥ）アイテムと、
ソースの地理的な位置を記述する地理的ユーザ位置（ＬＯＣ）アイテムと、
メディアデータを作成するソースアプリケーションの名称を記述するアプリケーションまたはツール名称（ＴＯＯＬ）アイテムと、
ソースの状態を記述する一時的なメッセージのための通知または状態（ＮＯＴＥ）アイテムと、
実験的拡張またはアプリケーション固有の拡張を定義するプライベート拡張（ＰＲＩＶ）アイテムと、
を含む、請求項１８に記載の方法。
【請求項２０】
前記ランダムキャラクタのコンテキストパラメータは、
受信が予想されるパケットの数に対する喪失したパケットの数を示す喪失分フィールドと、
喪失したパケットのビットマスクを含むフィールド（ＢＬＰ）と、
を含む、請求項１３〜１９のうちの１つに記載の方法。
【請求項２１】
前記頻繁に変化するコンテキストパラメータは、
最後の送信者レポートを受信してからの遅延を示すリアルタイムトランスポートプロトコル（ＲＴＰ）タイムスタンプフィールドと、
前記最後の送信者レポートのタイムスタンプフィールドと、
リアルタイムプロトコル（ＲＴＰ）データパケット到着間隔時間の統計的変動の推定を示す到着間隔ジッタフィールドと、
パケットの長さを示す長さフィールドと、
を含む、請求項１３〜２０のうちの１つに記載の方法。
【請求項２２】
前記カウンタコンテキストパラメータは、
リアルタイムプロトコル（ＲＴＰ）シーケンス番号と、
受信したパケットの拡張された最大シーケンス番号を示すフィールドと、
セッションの開始から送信者のパケット数を含むパケットの生成までのタイムフレームにおいて該送信者が送信したリアルタイムプロトコル（ＲＴＰ）パケットの総数を示すパケット送信者パケット数と、
前記セッションの開始から前記送信者のオクテット数を含むパケットの生成までのタイムフレームにおいて該送信者によって前記リアルタイムプロトコル（ＲＴＰ）パケットで送信されたペイロードオクテットの総数を示すパケット送信者オクテット数と、
送信中に喪失したパケットの累積数を示すフィールドと、
を含む、請求項１３〜２１のうちの１つに記載の方法。
【請求項２３】
前記圧縮された制御パケットは、送信者レポートパケット、受信者レポートパケット、およびアプリケーション定義（ＡＰＰ）パケットであり得る、請求項１１〜２２のうちの１つに記載の方法。
【請求項２４】
前記初期化パケットを形成するステップは、初期化パケットを形成し、
前記初期化パケットは、
パケットの解凍に用いられるヘッダデコンプレッサの状態を特定するコンテキスト識別子と、
パケット受信者がパケットタイプを特定することを可能にするパケット識別子と、
パケット送信者のプロファイル情報を含むプロファイル情報と、
アップデートするパケットのデータ完全性を検査する巡回冗長検査（ＣＲＣ）フィールドと、
静的コンテキストパラメータを含む静的情報チェーンと、
動的コンテキストパラメータを含む動的情報チェーンと、
を含む、請求項１０または１１に記載の方法。
【請求項２５】
前記リフレッシュパケットおよび圧縮された制御パケットを形成するステップは、リフレッシュパケットを形成し、
前記リフレッシュパケットは、
パケットの解凍に用いられるヘッダデコンプレッサの状態を特定するコンテキスト識別子と、
パケット受信者がパケットタイプを特定することを可能にするパケット識別子と、
パケット送信者のプロファイル情報を含むプロファイル情報と、
アップデートするパケットのデータ完全性を検査する巡回冗長検査（ＣＲＣ）フィールドと、
動的コンテキストパラメータを含む動的情報チェーンと、
を含む、請求項１１に記載の方法。
【請求項２６】
前記リフレッシュパケットおよび圧縮された制御パケットを形成するステップは、送信者レポートパケットヘッダおよび少なくとも１つのレポートブロックを含む送信者レポートパケットを形成する、請求項１１に記載の方法。
【請求項２７】
前記送信者レポートパケットヘッダは、
送信者レポートパケットのタイプを特定するパケット識別子と、
前記送信者レポートパケットに含まれるレポートブロックの数を示す受信レポート数フィールドと、
前記レポートブロックを生成するセッション参加者がアクティブであるか否かを示すアクティブ送信者フラグと、
前記送信者レポートパケットのデータ完全性を検査する巡回冗長検査（ＣＲＣ）フィールドと、
前記送信者レポートパケットが該送信者レポートパケットの末尾にコンテキストパラメータの一部ではない付加的なパディングフィールドを含むか否かを示すパディングフラグと、
最下位ビット（ＬＳＢ）エンコーディングにより符号化されたリアルタイムプロトコル（ＲＴＰ）タイムスタンプと、
前記送信者レポートパケットが拡張フィールドをさらに含むことを示す拡張フラグと、
セッションの開始から前記送信者レポートパケットの生成までのタイムフレームにおいて送信者が送信したリアルタイムプロトコル（ＲＴＰ）パケットの総数を示す、最下位ビット（ＬＳＢ）エンコーディングにより符号化された送信者パケット数フィールドと、
前記セッションの開始から前記送信者レポートパケットの生成までのタイムフレームにおいて前記送信者によってリアルタイムプロトコル（ＲＴＰ）パケットで送信されたペイロードオクテットの総数を示す、最下位ビット（ＬＳＢ）エンコーディングにより符号化された送信者オクテット数フィールドと、
最下位ビットエンコーディングにより符号化されたフォーマットの送信者レポートの長さを示す長さフィールドと、
を含む、請求項２６に記載の方法。
【請求項２８】
前記リフレッシュパケットおよび圧縮された制御パケットを形成するステップは、受信者レポートパケットヘッダおよび少なくとも１つのレポートブロックを含む圧縮された受信者レポートパケットを形成する、請求項１１〜２７のうちの１つに記載の方法。
【請求項２９】
前記受信者レポートパケットヘッダは、
前記圧縮された受信者レポートパケットのタイプを特定するパケット識別子と、
前記受信者レポートパケットに含まれたレポートブロックの数を示す受信レポート数フィールドと、
前記レポートブロックを生成するセッション参加者がアクティブであるか否かを示すアクティブ送信者フラグと、
前記受信者レポートパケットのデータ完全性を検査する巡回冗長検査（ＣＲＣ）フィールドと、
圧縮されたリアルタイム制御プロトコル（ＲＴＣＰ）受信者レポートパケットが、該圧縮されたリアルタイム制御プロトコル（ＲＴＣＰ）受信者レポートパケットの末尾にコンテキストパラメータの一部ではない付加的なパディングフィールドを含むか否かを示すパディングフラグと、
最下位ビットエンコーディングにより符号化されたフォーマットの送信者レポートの長さを示す長さフィールドと、
を含む、請求項２７に記載の方法。
【請求項３０】
前記レポートブロックは、
受信が予想されるパケットの数に対する喪失したパケット数を示す喪失分フィールドと、
送信中に喪失したパケットの累積数を示す最下位ビット（ＬＳＢ）エンコーディングにより符号化された累積ロスフィールドと
受信されたパケットの拡張された最大シーケンス番号のシーケンス番号周期（ｓｅｑｕｅｎｃｅ  ｎｕｍｂｅｒ  ｃｙｃｌｅ）を示す最下位ビット（ＬＳＢ）エンコーディングにより符号化されたシーケンス番号周期フィールドと、
パケットの送信者によって受信された最大シーケンス番号を示す最下位ビット（ＬＳＢ）エンコーディングにより符号化された最大シーケンス番号と、
リアルタイムプロトコル（ＲＴＰ）データパケット到着間隔時間の統計的変動の推定を示す最下位ビット（ＬＳＢ）エンコーディングにより符号化された到着間隔ジッタフィールドと、
最下位ビット（ＬＳＢ）エンコーディングにより符号化されたリアルタイムプロトコル（ＲＴＰ）タイムスタンプと、
最後に受信された送信者レポートからの遅延を示す最下位ビット（ＬＳＢ）エンコーディングにより符号化された最終送信者レポート遅延フィールドと、
を含む、請求項２６〜２９のうちの１つに記載の方法。
【請求項３１】
前記送信者レポートパケットおよび受信者レポートパケットは、プロファイル固有の拡張のためのフィールドをさらに含む、請求項２８〜３０のうちの１つに記載の方法。
【請求項３２】
前記リフレッシュパケットおよび圧縮された制御パケットを形成するステップは、アプリケーション定義（ＡＰＰ）パケットを形成し、
前記アプリケーション定義（ＡＰＰ）パケットは、
前記アプリケーション定義（ＡＰＰ）パケットのタイプを特定するパケット識別子と、
前記アプリケーション定義（ＡＰＰ）パケットに含まれるフィードバックタイプを示すフィードバックタイプフィールドと、
前記アプリケーション定義（ＡＰＰ）パケットの長さを示す最下位ビット（ＬＳＢ）エンコーディングにより符号化されたフィードバック長フィールドと、
喪失したパケットを示すビットマスク（ＢＬＰ）フィールドと、
を含む、請求項１１〜３１のうちの１つに記載の方法。
【請求項３３】
コンピュータ上で実行したときに、請求項１〜３２のうちの１つにおける全てのステップを実行するプログラムコード手段を含むコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディアデータの送信セッションにおけるＲＴＣＰトラフィックの圧縮方法に関する。詳細には、本方法は、メディアデータ配信のためのリアルタイムプロトコル（ＲＴＰ）およびメディア配信を制御するためのリアルタイム制御プロトコル（ＲＴＣＰ）を用いたインターネットプロトコル（ＩＰ）ネットワークにおけるリアルタイムまたは準リアルタイムデータパケット送信で用いられるように企図されている。これらのプロトコル（ＲＴＰおよびＲＴＣＰ）の各々には、ＲＦＣ１８８９に示す規格に従って、利用可能なセッション帯域幅の一部が割り当てられる。
【背景技術】
【０００２】
ＲＦＣ１８８９で定義されるようなリアルタイムトランスポートプロトコル（ＲＴＰ）は、マルチキャストまたはユニキャストネットワークサービスを介してリアルタイムデータを送信する用途に適したエンドツーエンドネットワークトランスポート機能を提供する事実上の標準である。リアルタイム制御プロトコル（ＲＴＣＰ）で強化されことにより、大規模マルチキャストネットワークに適応可能な様式でデータ配信のサービス品質（ＱｏＳ）を監視することが可能となり、最低限の制御および識別機能を提供する。ＲＴＰは、資源予約に対応しておらず、リアルタイムサービスのサービス品質（ＱｏＳ）を保証しない。
【０００３】
ＲＴＰは、二つの規則を用いて制御トラフィックを規制する。第一に、セッション帯域幅の５％がＲＴＣＰトラフィックに割り当てられることが推奨されており、セッションの全参加者によって共有される。第二に、フィードバック送信のための最小レポート間隔は５秒である。セッションにおける全受信者は、この５％を自身の割り当て分と共に用いてレポート間隔を算出する。ＲＴＣＰレポート間隔Ｔは、あるソースからの二つのＲＴＣＰデータパケットに関して、満たされるべき時間間隔を定義する。この間隔は、平均ＲＴＣＰパケットサイズに大きく依存する。
【０００４】
これらの規則によって、ＲＴＣＰは安定し、大規模マルチキャストグループに使用可能となるが、ユニキャストまたは小規模マルチキャストシナリオにとっては最適ではない。後者に関しては、ユーザごとのフィードバックがより多いことが有益であり、実現可能性が最も高い。この問題はすでに認識されており、ＩＥＴＦのオーディオビデオトランスポートワーキンググループ（Ａｕｄｉｏ  Ｖｉｄｅｏ  Ｔｒａｎｓｐｏｒｔ  Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ）が新たなＲＴＰプロファイルであるＲＴＰ−ＡＶＰＦの標準化を進めている。この新たなプロファイルでは、推奨される５秒の最小フィードバック間隔は適用されない。従って、受信者は、その時点のセッションパラメータに応じて、パケットロスに対するフィードバックとしていくつかの早期ＲＴＣＰパケットを送出できる。
【０００５】
ＩＰベースのリアルタイムマルチメディアアプリケーションは、リアルタイムデータフローにおける個々のパケットのペイロードサイズが通常は小さいため、第３層、第４層、および上位層に大きなヘッダオーバーヘッドを生じさせる。無線リンクの帯域幅が制限されているため、ヘッダ圧縮はモバイルインターネットに欠くことができない必要条件であり、すなわち、ＩＰベースの移動端末装置は常にＩＰベースのインフラストラクチャと通信しなければならない。ＲＨＣ３０９５で定義されるロバストヘッダ圧縮（ＲＯＨＣ）は、ＩＥＴＦによって標準化された最新のヘッダ圧縮方式であり、異なるリンク状態に基づいて、圧縮効率対リンクエラーに対するロバスト性を微調整することを可能にする複雑なフレームワークを提供する。プロトコルは、最初または最後のホップの無線リンクの両側のエンドポイントの状態を維持すること、パケットヘッダの冗長性を除去すること、および効率的に情報を符号化することによって機能する。送信側（またはエンドポイント）のコンプレッサおよび受信側のデコンプレッサの状態を「コンテキスト」とも呼ぶ。コンテキストは、静的フィールドならびに圧縮および解凍のための可能な参照値等、パケットストリーム内の先行するヘッダからの関連情報を含む。パケットストリームを記述する付加情報もコンテキストの一部であり得、例えば、ＩＰ識別子フィールドがどのように変化するかに関する情報、およびパケット間でシーケンス番号またはタイムスタンプがどのように増加するかに関する情報等がある。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ＲＦＣ３０９５には、圧縮なし、ＲＴＰ／ＵＤＰ／ＩＰ、ＵＤＰ／ＩＰ、およびＥＳＰに関する４つのプロファイル、ならびにＩＰのみに関する1つのドラフトプロファイルが存在するが、圧縮を用いたＲＴＣＰパケットおよびヘッダの取扱い方法に関する規格はない。
【０００７】
ＲＴＰ／ＲＴＣＰを用いたキーアプリケーションの１つとして、モバイルインターネットを介したビデオストリーミングが勢いを増しつつある。しかしながら、無線リンクにおける振舞いにロスが大きく、往復遅延時間が長いために、この種のアプリケーションの導入は極めて困難である。１つの理由として、ＭＰＥＧ−４のようなフレーム間ビデオ圧縮アルゴリズムは、フレーム間の時間的相関を利用することにより圧縮率を大幅に向上させるが、参照フレームのエラーが全ての独立した異なるフレームに伝播するため、周知のエラー伝播作用の影響を受けやすいことが挙げられる。
【０００８】
本発明の目的は、ＲＴＣＰトラフィックに関する帯域幅効率を最適化し、ＲＴＣＰレポート／フィードバックの間隔を短縮することである。セッションの全参加者間の双方向オペレーションでは、ＲＴＣＰのために共有されるセッション帯域幅の割り当て分は限られている。スペクトル効率は、散在しており、費用がかかる無線リンクには非常に重要である。従って、この限られた帯域幅を効率よく使用するためには、アプリケーションが無線リンクを介してＲＴＰを導入する必要がある。本発明による方法は、上述の使用に関して、利用可能なＲＴＣＰ帯域幅割り当て分を超過することなく、ＲＴＣＰトラフィックの帯域幅効率を最大限に利用することを目的とする。ＲＴＣＰレポート間隔は、同一のセッションにおける同一の受信者からの連続する二つのレポートの間の期間である。これは、２種類の待ち時間の影響を受ける。１つはＲＴＣＰレポートの待ち時間であり、これは、パケットロスが受信者側で検出されてからレポートまたはフィードバックが送信されるまでの期間であり、もう１つはリンクの往復遅延時間（ＲＴＴ）による待ち時間である。後者は回避し難いが、レポートの待ち時間は最適化に利用され得る。レポート間隔Ｔとして定義される待ち時間の計算式は、
Ｔ＝ａｖｇ＿ｒｔｃｐ＿ｓｉｚｅ＊ｎ／ｒｔｃｐ＿ｂｗ
で表され得る。
【０００９】
ＲＴＰ／ＲＴＣＰがユニキャストおよび小規模マルチキャストセッションで用いられる典型的なシナリオについては、参加者数ｎは比較的固定されている。参加者数を減らすことによって待ち時間を短縮することは望ましくない。これは、ＲＴＣＰ帯域幅割り当て分ｒｔｃｐ＿ｂｗおよび平均ＲＴＣＰパケットサイズａｖｇ＿ｒｔｃｐ＿ｓｉｚｅに実験的なスペースを残すだけである。前述したように、ＲＴＣＰ帯域幅割り当て分を増大させることによりレポート間隔を短縮するアプローチをとるが、ＲＴＣＰ帯域幅割り当て分を最大で利用可能なセッション帯域幅全体の５％とする規則を変更することとなる。また、このアプローチでは、互換性の問題が生じ得る。
【００１０】
以上の考察を鑑みて、ＲＴＣＰプロトコルのレポート間隔を短縮する手段として改善が唯一可能であるのは、平均ＲＴＣＰパケットサイズａｖｇ＿ｒｔｃｐ＿ｓｉｚｅを縮小することである。ＲＴＣＰレポート間隔Ｔは、平均ＲＴＣＰパケットサイズに正比例するため、ＲＴＣＰパケットを圧縮することによって、元のＲＴＣＰパケットの１０％までパケットサイズを縮小することができる。これによって、制御プロトコルパケットの平均的パケットサイズがより小さくなるため、レポート間隔Ｔが大きく短縮される。
【００１１】
上記に基づいて、本発明は、ＲＴＰメディアデータ送信セッションを制御するＲＴＣＰトラフィックの圧縮方法を提供する。本明細書中に記載の圧縮原理は、基本的に、有線／固定ネットワークまたは無線／モバイルネットワークのいずれにおいても、リアルタイムおよび準リアルタイムメディア配信のためにＲＴＰを用いるあらゆるリンクに適用され得る。
【課題を解決するための手段】
【００１２】
本発明によるデータ送信におけるエンドポイントは、コンプレッサおよびデコンプレッサの内容（状態）を維持する。コンテキストで維持される構造体により、デコンプレッサで同期していないコンテキストの修復および復旧が可能である。さらに、パケットフォーマット、ならびにコンプレッサおよびデコンプレッサのコンテキストを動的に定義することが可能である。
【００１３】
本圧縮方法は、最初にコンテキストパラメータを受信エンドポイントに送信することによって、制御トラフィックフローのコンテキストを初期化する。コンテキストは、必要に応じて、より小さなサイズのパケット（圧縮された制御パケット）を用いてセッション中にアップデートされる。後の方のパケットは、部分的なコンテキストのアップデートを行う場合に用いられる。また、初期化パケットを用いて定期的にコンテキストをアップデートすることも可能である。コンテキストパラメータは、静的パラメータおよび動的パラメータに分類され得る。静的コンテキストパラメータは、既知のパラメータまたはセッション中に変化しないパラメータのいずれかである。動的コンテキストパラメータは、セッション中に変化するパラメータであり、新たに定義されたパケットまたは圧縮された制御パケットで受信側に送信される。
【００１４】
実現可能な異なるコンテキストパラメータ（標準ＲＴＣＰデータパケットの全てのフィールドも含む）が既知であり、それらは、静的コンテキストパラメータおよび動的コンテキストパラメータに有利に分類され得る。ヘッダおよびデータの圧縮は、この分類に基づいて行われ得る。
【００１５】
既知のコンテキストパラメータは、トラフィックオーバーヘッドをさらに低減するために除外することができ、送信する必要はないが、本明細書中に記載の圧縮および解凍手法を用いて圧縮することも可能である。
【００１６】
セッションを初期化するために、これらのコンテキストパラメータを含む少なくとも１つの初期化パケットが受信ノードに送信される。パケットに含まれたパラメータは静的情報を含み、その情報は一度送信されるだけでよい。従って、送信される総トラフィック量は大幅に低減され得る。動的コンテキストパラメータは、例えば、制御プロトコルに固有のパケット（圧縮された制御パケット）で送信される。リフレッシュパケットにより、パケットソースが受信ノードのコンテキスト情報をアップデートすることが可能になる。制御パケットは、主に、標準ＲＴＣＰプロトコルにより既知のパケットに相当する。
【００１７】
対照的に、圧縮された制御パケットのパケット構造体は、パケットコンテンツのサイズ（ビット単位）が大幅に縮小され、初期化パケットおよびリフレッシュパケット等の新たなパケットが導入され得るように変更される。よって、制御プロトコルの制御パケットの総平均パケットサイズは、標準ＲＴＣＰプロトコルと比較して大幅に縮小され得る。
【００１８】
ＲＴＣＰソース記述パケットおよびＲＴＣＰバイパケット（ＲＴＣＰ  ｂｙｅ  ｐａｃｋｅｔｓ）の内容は、セッション中には頻繁に変わらないか、または変更があまり生じないため、制御プロトコルの対応するソース記述パケットおよびバイパケットは、開示する方法では圧縮されないが、これらのパケットは、本明細書中に記載の圧縮および解凍手法を用いて圧縮することができる。どちらのパケットも対応するＲＴＣＰパケットと同様のフォーマットを有する。
【００１９】
コンテキストパラメータを分類した後、少なくとも１つの初期化パケットが静的コンテキストパラメータ、および必要に応じて、送信前の動的コンテキストパラメータの初期設定値から形成される。リフレッシュパケットは、送信前の動的コンテキストパラメータから形成される。
【００２０】
最大限まで圧縮するために、動的コンテキストパラメータは、さらに、随時変化するコンテキストパラメータ、ランダムキャラクタのコンテキストパラメータ、カウンタコンテキストパラメータ（ｃｏｕｎｔｅｒ−ｌｉｋｅ  ｃｏｎｔｅｘｔ  ｐａｒａｍｅｔｅｒｓ）、頻繁に変化するコンテキストパラメータ、および定期的に一定の変化量だけ変化するコンテキストパラメータに分類される。動的コンテキストパラメータは、その分類に応じて、制御データパケットに組み込まれる前に符号化により圧縮されサイズが縮小され得る。特に、カウンタコンテキストパラメータ、頻繁に変化するコンテキストパラメータ、および定期的に一定の変化量だけ変化するコンテキストパラメータは、最下位ビット（ＬＳＢ）エンコーディング（ｌｅａｓｔ―ｂｉｔ  （ＬＳＢ）  ｅｎｃｏｄｉｎｇ）を用いて符号化され得る。
【００２１】
最下位ビット（ＬＳＢ）エンコーディングを用いる場合、元のフィールド値の代わりに、符号化されたフィールド値のＫ個の最下位ビットが用いられる（ここで、Ｋは正の整数）。Ｋビットを受信した後、圧縮されたデータパケットを解凍するパケット受信側のデコンプレッサは、以前に受信した値を参照値として用いて元の値を導き出す。
【発明を実施するための最良の形態】
【００２２】
レポート間隔Ｔを短縮するために、制御プロトコルのデータパケットの平均パケットサイズが縮小される。ＲＦＣ１８８９で定義される標準ＲＴＣＰプロトコルは、リアルタイムまたは準リアルタイム環境でメディアデータ送信ストリームを制御するために以下のパケットを用いる：メディアデータ送信セッションにおけるアクティブな送信者である参加者とスタティック（ｓｔａｔｉｃ’ｓ）を送受信するための送信者レポート、アクティブな送信者ではない参加者からスタティックを受信するための受信者レポート、送信元を記述するためのソース記述アイテム、参加者の参加終了を示すバイパケット、およびアプリケーション固有のデータを送信するためのアプリケーション定義（ＡＰＰ）パケット。
【００２３】
上述したデータパケットのサイズを縮小するために、パケット構造体内のフィールドが最初に解析される。一般に、ＲＴＣＰパケット内の全てのフィールドは、パケットストリーム（セッション）の継続時間を通じて一定であることが予想されるフィールドである静的コンテキストパラメータ、および制限された値の集合もしくは範囲内でなんらかの変化、例えば、ランダムな変化が予想されるか、またはそれ以外の変化が予想されるフィールドである動的コンテキストパラメータに分類され得る。
【００２４】
動的コンテキストパラメータ（動的ＲＴＣＰパケットフィールド）は、さらに、以下のように分類され得る：随時変化するコンテキストパラメータ、ランダムキャラクタのコンテキストパラメータ、カウンタコンテキストパラメータ、頻繁に変化するコンテキストパラメータ、および定期的に一定の変化量だけ変化するコンテキストパラメータ。
【００２５】
随時変化するコンテキストパラメータは、随時変化するが、制限された数のパケットの後に元の値に戻るフィールドである。標準ＲＴＣＰパケット内のコンテキストパラメータおよびフィールドに関して、これらの値またはフィールドは、パケット内のレポートブロックの数を示す受信レポート数（ＲＣ）、ソース記述パケット内の同期ソースもしくは貢献ソースの数を示すか、またはバイパケット内の同期ソースもしくは貢献ソースの数を特定するソース数（ＳＣ）フィールド、個々のパケットタイプを特定するペイロードタイプ（ＰＴ）フィールド、パケットソース属性を記述する情報を含むソース記述（ＳＤＥＳ）アイテム、ならびにアプリケーション定義（ＡＰＰ）パケットの集合を１つの固有名称で定義することを可能にするアプリケーション定義（ＡＰＰ）パケット内のサブタイプフィールドである。
【００２６】
随時変化するコンテキストパラメータは、初期化のために最初に送信され得るが、それらのフィールドが変化する場合には、そのフィールドを送信またはアップデートする方法が存在する。それゆえ、圧縮されたデータパケットを伴う提案された制御プロトコルは、アップデートの用途でコンテキストパラメータを送信するために用いられるリフレッシュパケットを取り入れている。パケットの使用法および構造は以下でさらに説明する。
【００２７】
頻繁に変化するコンテキストパラメータは、通常、一定であるか、または他のフィールドから推定できる値を有するパラメータを含み、その振る舞いは頻繁に変わる。それゆえ、頻繁に変化するコンテキストパラメータを受信者または送信者側でアップデートするための効率的な方法が必要である。上述したリフレッシュパケットがこのような場合に用いられ得るか、または新たに定義された制御パケット内にある場合、個々のフィールドが送信される。
【００２８】
頻繁にアップロードされるべきフィールドは、ＲＴＰタイムスタンプ、最後に受信された送信者レポートからの遅延（最後の送信者レポートからの遅延）を示すフィールド、最後の送信者レポートのタイムスタンプ、ＲＴＰデータパケットの到着間隔時間の統計的変動の推定を示す到着間隔ジッタフィールド、およびＲＴＣＰパケットの長さフィールドを含む。
【００２９】
動的コンテキストパラメータのさらなるカテゴリには、ランダムキャラクタのパケットがある。これらのパラメータの例としては、Ｊ．Ｏｔｔらの「ＲＴＣＰに基づくフィードバック（ＲＴＰ／ＡＶＰＦ）のための拡張されたＲＴＰプロファイル」、インターネットドラフト、２００２年１０月、に示されるようなＲＴＣＰ  ＡＰＰパケットのビットマップマスク（ＢＬＰ）内のＲＴＣＰ割り当て分のロスが挙げられる。これらのフィールドは完全にランダムであるため、全ての圧縮されたパケットヘッダにそのままの状態で含まれる。
【００３０】
動的コンテキストパラメータのさらに別のカテゴリには、カウンタコンテキストパラメータがある。このパラメータは、すべてのＲＴＣＰパケットの異なるカウンタ値間に一定の変化量を伴うカウンタのように動作するフィールドである。このフィールドの送信エンコーディングに関する唯一の要件は、送信者側のコンプレッサと受信者側のデコンプレッサとの間でのパケットロスが許容範囲内でなければならないことである。このようなフィールドがいくつか存在していれば、全てのフィールドが相互に通信することができる。このようなパラメータは、頻繁に変化するコンテキストパラメータの値を解釈するためにも用いられ得る。
【００３１】
このようなフィールドの例としては、ＲＴＰシーケンス番号、拡張された最大受信シーケンス番号フィールド、セッションの開始から送信者のパケット数を含むパケットの生成までのタイムフレームにおいて送信者が送信したＲＴＰパケットの総数を示す送信者パケット数、セッションの開始から送信者のオクテット数を含むパケットの生成までのタイムフレームにおいて送信者によってＲＴＰパケットで送信されたペイロードオクテットの総数を示すパケット送信者オクテット数、および送信中に喪失したパケットの累積数を示す喪失したパケットの累積数が挙げられる。
【００３２】
動的コンテキストパラメータの最後のカテゴリには、定期的に一定の変化量だけ変化するコンテキストパラメータが含まれる。このフィールドは、通常、後続のパケットにおいて一定の変化量だけ増加する。従って、このフィールドはパケット間で相互に相関関係を有する。このコンテキストでは、初期化パケットを用いてフィールドの値を初期設定し（ｉｎｉｔｉａｔｅ）、次いで、その値の増分を送信することによりフィールドをアップデートすることが望ましい。
【００３３】
定期的に一定の変化量だけ変化するコンテキストパラメータの例としては、ＲＴＰタイムスタンプが挙げられる。
【００３４】
さらに、静的コンテキストパラメータおよび動的コンテキストパラメータ以外に、第３のカテゴリを決定することができる。いわゆる標準ＲＴＣＰパケット内の周知または既知のフィールドは、初期化中に送信されるか、または除外され得る。既知のコンテキストパラメータの例としては、ＲＴＣＰバージョンフィールドが挙げられる。
【００３５】
上述のコンテキストパラメータの分類は、例えば、パケットおよびヘッダ圧縮に用いられるテーブルを参照することによって行われ得る。この提案された新たなＲＴＣＰ圧縮方法では、コンテキストパラメータを動的に分類することも可能である。
【００３６】
コンテキストパラメータを分類した後、動的コンテキストパラメータの一部が符号化され、そのサイズが縮小される。特に、カウンタコンテキストパラメータ、頻繁に変化するコンテキストパラメータ、および定期的に一定の変化量だけ変化するコンテキストパラメータは、元のフィールドサイズ（ビット単位）が実質的に縮小され得るように最下位ビット（ＬＳＢ）エンコーディングによって符号化される。
【００３７】
コンテキストパラメータを分類した後、制御プロトコルのパケットが形成される。セッションを初期化するために、初期化パケットが形成されて送信される。初期化パケットのパケットフォーマットを図１に示す。このパケットは、「静的チェーン（ｓｔａｔｉｃ  ｃｈａｉｎ）」フィールド内に、パディングフラグ、送信者およびソースの同期ソース、ならびに貢献ソースフィールド等の静的コンテキストパラメータを含む。よって、「静的チェーン」フィールドは、パケットの「動的チェーン」と同様に可変長である。さらに、初期化パケット内には、ソース数および受信レポート数、ペイロードタイプ識別、１つ以上のＳＤＥＳアイテム、ならびにアプリケーション定義（ＡＰＰ）パケット用のサブタイプフィールドが組み込まれる。
【００３８】
随時変化するコンテキストパラメータもまた、その初期値を用いて、形成された初期化パケットに組み込まれ得る。この随時変化するコンテキストパラメータの初期設定の値は、初期化パケットの「動的チェーン」フィールドに位置する。
【００３９】
初期化された随時変化するコンテキストパラメータは、後続のリフレッシュパケットによってアップデートされ得る。
【００４０】
詳細には、圧縮された初期化パケットは、パケット受信側で用いられる、初期化パケットの先頭を解凍するデコンプレッサの状態を特定するコンテキストＩＤ（ＣＩＤ、「Ａｄｄ−ＣＩＤオクテット」）、パケット受信者によるパケットタイプの特定を可能にするパケット識別子（「１１１１１１０Ｄ」）、送信者のプロファイルに関するプロファイル情報（「プロファイル」）、初期化パケットのデータ完全性を検査するための巡回冗長検査フィールド（「ＣＲＣ」）、静的コンテキストパラメータを含む静的情報チェーン（「静的チェーン」）、そして、最後に、一度初期化される必要がある動的コンテキストパラメータを含む動的情報チェーン（「動的チェーン」）を含む。動的情報チェーンは、ソース数、受信レポート数、ＲＴＣＰペイロードタイプ、ＳＤＥＳアイテム、およびアプリーケーション定義（ＡＰＰ）パケット用のサブタイプフィールド等の前述した随時変化するコンテキストパラメータに対応する。
【００４１】
図２は、リフレッシュパケットのパケットフォーマットを示す。初期化パケットに関して最後に述べたフィールドは動的であり、それらのフィールドをアップデートするために新たなリフレッシュパケットが導入される。詳細には、リフレッシュパケットは、パケット受信側でリフレッシュパケットを解凍するために用いられるヘッダデコンプレッサの状態を特定するコンテキストＩＤ（ＣＩＤ、「Ａｄｄ−ＣＩＤオクテット」）、パケット識別子（「１１１１１０００」）、パケット送信者のプロファイル情報（「プロファイル」）、リフレッシュパケットのデータ完全性を検査するための巡回冗長検査（「ＣＲＣ」）フィールド、そして、最後に、アップデートされる必要がある動的コンテキストパラメータを含む動的情報チェーン（「動的チェーン」）を含む。
【００４２】
また、長いコンテキスト識別子（ＣＩＤ）が用いられる場合、初期化パケットおよびリフレッシュパケットは、パケット識別子の後に最大で２バイトをさらに含み得る。
【００４３】
送信者レポートパケットおよび受信者レポートパケットの圧縮版を図３および図４に示し、新たな圧縮されたアプリケーション定義（ＡＰＰ）パケットを図５に示す。
【００４４】
ソース記述パケットおよびバイパケットは、ＲＦＣ１８８９で提案された標準パケットフォーマットに対応する。これは、これらのパケットは、セッション中に発生することが非常にまれであり、圧縮したとしてもＲＴＣＰパケットの平均パケットサイズを大幅に縮小することがないためである。
【００４５】
図３に示す送信者レポートパケットは、パケットヘッダ、および少なくとも１つのレポートブロックを含む。１つまたは複数のレポートブロックの後つ続いて、プロファイル固有の拡張が含まれ得る。プロファイル固有の拡張では、前述のカテゴリのうちの１つに該当する全てのフィールドも、最下位ビットエンコーディングを用いて圧縮され得る。よって、拡張フィールドのサイズも縮小され、結果として、平均パケットサイズが小さくなり得る。
【００４６】
図中の「ＬＳＢ」という略語は「最下位ビット」を表わし、個々のフィールドが最下位ビットエンコーディングにより符号化されていることを示す。
【００４７】
送信者レポートパケットのヘッダは、送信者レポートパケットのタイプを特定するパケット識別子（「１１１」）を含む。さらに、受信レポート数フィールド（ＲＣ）は、圧縮された送信者レポートパケットに含まれるレポートブロックの数を示す。アクティブ送信者フラグ（「Ｓ」）は、レポートブロックを形成する参加者がアクティブな送信者であるか否かを示す。巡回冗長検査（「ＣＲＣ」）フィールドは、圧縮された送信者レポートパケットのデータ完全性を検査するために用いられる。パディングフラグまたはビット（「Ｐ」）は、送信者レポートパケットがそのパケットの末尾に付加的なパディングフィールドを含むか否かを示す。この付加的なパディングフィールドは、実際のコンテキストパラメータの一部ではない。
【００４８】
ヘッダは、最下位ビット（ＬＳＢ）エンコーディングにより符号化されたＲＴＰタイムスタンプ（「ＬＳＢスケールＲＴＰタイムスタンプ（ＬＳＢ  Ｓｃａｌｅｄ  ＲＴＰ  Ｔｉｍｅｓｔａｍｐ）」）をさらに含む。拡張フラグ（「Ｘ」）は、パケットがそのパケットの末尾の特別な拡張フィールドにプロファイル固有の拡張を含むか否かを示す。
【００４９】
送信者レポートパケットサイズをさらに縮小するために、送信者パケット数フィールドも最下位ビット（ＬＳＢ）エンコーディングにより符号化される。送信者レポートパケットのヘッダ内の送信者パケット数フィールド（「ＬＳＢ送信者パケット数」）は、メディアデータ送信セッションの開始から個々の送信者レポートパケットの生成までのタイムフレームにおいて送信者が送信したＲＴＰパケットの総数を示す。
【００５０】
さらに、送信者レポートパケットのヘッダは、セッションの開始から送信者レポートパケットの生成までのタイムフレームにおいて送信者によってＲＴＰデータパケットで送信されたペイロードオクテットの総数を示す送信者オクテット数のフィールドを含む。また、このフィールドも最下位ビット（ＬＳＢ）エンコーディングにより符号化され、パケットヘッダのサイズが縮小される。図中では、このフィールドは二つの部分（「ＬＳＢ送信者オクテット数パート１」および「ＬＳＢ  ＳＯＣ  Ｐ２」）に分割されており、パケットの５番目のバイト、およびパケットの６番目のバイトの最初の５つのビットが、送信者のオクテット数を含む。
【００５１】
パケットヘッダは、送信者レポートの長さを示すフィールド（「ＬＳＢ  Ｌｅｎ  ＳＲ」）をさらに含む。このフィールドもまた、最下位ビット（ＬＳＢ）エンコーディングにより符号化される。ヘッダの末尾は、パケットの６番目のバイトの後の「＋＝＋＝＋＝」の線で示される。
【００５２】
送信者レポートパケット内の少なくとも１つのレポートブロックは、以下に示すフィールドを含む。
【００５３】
喪失分フィールド（「喪失分（ｆｒａｃｔｉｏｎ  ｌｏｓｔ）」）は、受信が認められたパケット数に対する喪失したパケットの数を示す。累積ロスフィールド（「累積ロス（ｃｕｍｍｕ．  ｌｏｓｓ）」）は、送信中に喪失したパケットの累積数を示す。サイズを縮小するために、累積ロスフィールドは、レポートブロックの残りのフィールドとして最下位ビット（ＬＳＢ）エンコーディングにより符号化される。シーケンス番号周期フィールド（「ＬＳＢ  ＳＮ  周期（ＬＳＢ  ＳＮ  Ｃｙｃｌｅ）」）は、受信されたパケットの拡張された最大シーケンス番号のシーケンス番号周期を示す。最大シーケンス番号フィールド（「ＬＳＢ  最大  ＳＮ（ＬＳＢ  Ｈｉｇｈｅｓｔ  ＳＮ）」）は、送信者レポートパケットの送信者によって受信された最大のシーケンス番号を示す。到着間隔ジッタフィールド（「到着間隔ジッタ（ｉｎｔｅｒａ．  ｊｉｔｔｅｒ）」）は、ＲＴＰデータパケット到着間隔時間の統計的変動の推定値を含む。さらに、レポートブロックには、最後の送信者レポートが送信されてからの時間を示すＲＴＰタイムスタンプフィールド（「ＬＳＢ  ＴＳ  最後  ＳＲ（ＬＳＢ  ＴＳ  ｌａｓｔ  ＳＲ）」）が含まれる。最後の圧縮されたＲＴＣＰ送信者レポートからの遅延を示すフィールド（「ＬＳＢ  ＤＬＳ」）も含まれる。
【００５４】
喪失分フィールドを除く、レポートブロック内の全てのフィールドは、最下位ビット（ＬＳＢ）エンコーディングを用いて符号化される。
【００５５】
単一のレポートブロックは４バイト長（図に示すバイト７〜１０）である。図に示すように、複数のレポートブロックが単一の送信者レポートに含まれ得る。
【００５６】
送信者レポートパケットに加え、ＲＴＣＰ受信者レポートパケットの圧縮版が以下のように提案される。図４に示す受信者レポートパケットは、ヘッダ（バイト１から３）、および前述したレポートブロックと同様の少なくとも１つのレポートブロックを含む。圧縮された受信者レポートパケットは、圧縮された送信者レポートパケットと同様に、パケットヘッダにおいて拡張フラグ（「Ｘ」）で示されるプロファイル固有の拡張をその末尾に含み得る。
【００５７】
受信者レポートパケットのヘッダは、受信側が受信者レポートの圧縮版を認識し得るように受信者レポートパケットのタイプを特定するパケット識別子（「１１１」）を含む。受信数フィールド（「ＲＣ」）は、受信者レポートパケットに含まれるレポートブロックの数を示す。送信者レポートパケットと同様に、受信者レポートパケットは、個々のパケットヘッダに続いていくつかのレポートブロックを含み得る。
【００５８】
アクティブ送信者表示フラグ（「Ｓ」）は、個々のレポートブロックを生成したセッション参加者の状態を示す。さらに、データ完全性を確認するための巡回冗長検査フィールドが含まれる。パディングフラグ（「Ｐ」）は、受信者レポートパケットが受信者レポートパケットの末尾に付加的なパディングフィールドを含んでいるか否かを示す。この付加的なパディングフィールドは、実際のコンテキストパラメータの一部ではない。最後に、長さフィールド（「ＬＳＢ  長さ  ＲＲ（ＬＳＢ  Ｌｅｎｇｔｈ  ＲＲ）」）が、受信者レポートパケットのヘッダに含まれており、これは最下位ビット（ＬＳＢ）エンコーディングにより符号化されたフォーマットで圧縮されたＲＴＣＰ受信者レポートの長さを示す。
【００５９】
最後に、アプリケーション定義（ＡＰＰ）パケットフォーマットを図５に示す。ここで提案された圧縮されたアプリケーション定義（ＡＰＰ）パケットフォーマットは、Ｏｔｔらによって提案されたような強化されたＲＴＣＰフィードバックが用いられる場合にのみ適用される。それゆえ、パケットの仕様は、その名が示すように、一般的なアプローチによるものではなくアプリケーション固有のものである。
【００６０】
圧縮されたアプリケーション定義（ＡＰＰ）パケットフォーマットは、圧縮されたアプリケーション定義（ＡＰＰ）パケットのタイプを特定するパケット識別子（「１１１」）を含む。フィードバックタイプフィールド（「ＦＭＴ」）は、このパケットに与えられたフィードバックのタイプを示す。さらに、パケットの長さは、フィードバック長フィールド（「ＬＳＢ  フィードバック長（ＬＳＢ  Ｆｅｅｄｂａｃｋ  Ｌｅｎｇｔｈ）」）に示される。このフィールドは最下位ビット（ＬＳＢ）エンコーディングにより符号化される。ビットマスクフィールド（「ＢＬＰ」）は、最後のパケットを示す。ＢＬＰフィールド（ビットマスクフィールド）の最初のビットにより、パケット識別子によって示されるＲＴＰパケットの直後のＲＴＰパケットに対するロスのレポートが可能になる。フィードバックタイプフィールド（ＦＭＴ）が汎用的な応答を示す場合、ＢＬＰフィールドの最初のビット（いわゆるＲビット）は１である。この場合、ＢＬＰフィールドは、圧縮されたアプリケーション定義（ＡＰＰ）パケットによって認識される付加的なパケットの数を特定するために用いられる。一方、Ｒ＝０の場合、ＢＬＰフィールドは、喪失したパケットを示すビットマスクを保持する。
【００６１】
要約すると、上記で提案された圧縮された制御パケット、および新しく導入された２つのパケットフォーマット（初期化パケットおよびリフレッシュパケット）は、制御プロトコルパケットの全体的な平均パケットサイズを縮小することにより、レポート間隔Ｔを短縮することを目的とする。
【００６２】
データ量は、随時変化するコンテキストパラメータを初期化する際に初期化パケットで静的コンテキストパラメータを「予め」送出することによって縮小される。随時変化するコンテキストパラメータが変化する際、随時変化するコンテキストパラメータをアップデートするためにリフレッシュパケットが用いられる。制御パケットフィールドの大半は、そのサイズがさらに縮小されるように符号化される。
【００６３】
よって、標準ＲＴＣＰプロトコルと比較して、圧縮された制御データパケットの平均サイズを縮小することができる。それゆえ、上記で提案されたパケットフォーマットを用ることによって、制御トラフィックのために割り当てられた帯域幅を拡張することなくレポート間隔Ｔを大幅に短縮することができる。結果として、より短い時間間隔でフィードバックが可能となり、それによって、メディアデータ送信セッションの参加者は、標準ＲＴＰ／ＲＴＣＰプロトコルの組み合わせを用いたセッションにおいてよりも早く、変化する送信環境に適応し得る。それゆえ、ＭＰＥＧ−４により符号化されたビデオデータ等の送信（またはブロードキャスト）されたアプリケーションデータの全体的な質は大幅に改善され得る。
【００６４】
上記で提案されたヘッダおよびデータ圧縮の手法は、ＲＴＣＰヘッダおよびデータ部分のみを対象としており、下位層のＵＤＰ／ＩＰヘッダを対象としていない。従って、ＰＲＦ３０９５で提案されたようなヘッダ圧縮方式が、一般に、最後または最初のホップにおけるポイントツーポイントリンクに適用されるのに対して、本明細書中において説明したアプローチは、エンドツーエンドに適用され得る。あるパケットに達するまでに介在するホップでは、圧縮された制御パケットを考慮する必要がなく、それらのホップは、レイヤ３ＩＰパケットデータまたはレイヤ４トランスポート層パケットデータとして見なされる。中間ホストに対しては付加的なオーバーヘッドは生じない。しかしながら、最初または最後のホップにおける無線リンクで下位層のヘッダに対してロバストヘッダ圧縮を併用する場合、より大きな帯域幅が節約され得る。
【図面の簡単な説明】
【００６５】
【図１】本発明による圧縮方法においてセッションを初期化するために用いる初期化パケットのパケットフォーマットを示す。
【図２】本発明による圧縮方法において動的コンテキストパラメータをアップデートするために用いるリフレッシュパケットのパケットフォーマットを示す。
【図３】本発明による圧縮方法において用いられる送信者レポートパケットのパケットフォーマットを示す。
【図４】本発明による圧縮方法において用いられる受信者レポートパケットのパケットフォーマットを示す。
【図５】本発明による圧縮方法において用いられるアプリケーション定義パケットのパケットフォーマットを示す。
【図１】
2004208292.tif 000002
【図２】
2004208292.tif 000003
【図３】
2004208292.tif 000004
【図４】
2004208292.tif 000005
【図５】
2004208292.tif 000006