(57)【特許請求の範囲】
【請求項１】
データ・ネットワークにおいて、
帯域限定リンクを介して伝送されるデータ・パケットのヘッダの圧縮／解凍を行うヘッダ圧縮／解凍装置を具備する第１のノードと、
前記帯域限定リンクを介して伝送されるデータ・パケットのヘッダの圧縮／解凍を行うヘッダ圧縮／解凍装置を具備する第２のノードと、を具備し、
変化しないフィールドのコンテキスト状態を最初に確立し、さらに、前記第１のノードと前記第２のノードのうちの一方の圧縮装置と、前記第１のノードと前記第２のノードのうちの他方の解凍装置との間の変化するフィールドの１次差を確立し、次いで、任意のフィールドの２次差がノンゼロであるとき、新しい１次差と共にノンゼロの２次差を持つ特定パケットを、上記新しい１次差が受信された旨の肯定の確認が上記圧縮装置により受信されるまで、もしくは、所定期間の期限切れまで、上記新しい１次差を持つ当該後続パケットと共に伝送することにより、ヘッダの圧縮と再構成とを行うことを特徴とするデータ・ネットワーク。
【請求項２】
請求項１に記載のデータ・ネットワークにおいて、データ・パケットのラウンド・トリップ時間とパケット間分離時間との商として前記所定期間を設定することを特徴とするデータ・ネットワーク。
【請求項３】
請求項１に記載のデータ・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、ダイアルアップ・モデムのような低速回線に対応することを特徴とするデータ・ネットワーク。
【請求項４】
請求項１に記載のデータ・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、セルラ・リンクに対応することを特徴とするデータ・ネットワーク。
【請求項５】
請求項１に記載のデータ・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、インターネット・サービス・プロバイダ（ＩＳＰ）のＩＰベースのネットワークと、インターネットと、例えば公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）、及び、前記第１のノードと前記第２のノードとの間の通信を可能にするその他のアクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）などを含む様々な発信側ネットワークと着信側ネットワークと、に対応することを特徴とするデータ・ネットワーク。
【請求項６】
請求項１に記載のデータ・ネットワークにおいて、ノンゼロの２次差を持つ上記対応フィールドが上記１次差の通信時間中再び変化したとき、上記圧縮装置が、上記解凍装置へ伝送するために上記新しい１次差を上記元の１次差と組み合わせることを特徴とするデータ・ネットワーク。
【請求項７】
請求項１に記載のデータ・ネットワークにおいて、前記データ・パケットの各々が、タイム・スタンプとパケット・シーケンス番号とを有する少なくともヘッダ・フィールドを含むことを特徴とするデータ・ネットワーク。
【請求項８】
請求項７に記載のデータ・ネットワークにおいて、前記ヘッダ圧縮メカニズムを実行して、上記パケットの紛失やエラーの発生時に前記データ・パケットのヘッダを正しく再構成するようにすることを特徴とするデータ・ネットワーク。
【請求項９】
請求項７に記載のデータ・ネットワークにおいて、前記ヘッダが、上記インターネットでのリアルタイム通信のために、及び、ボイス・オーバーＩＰとテレビ会議などのようなアプリケーションのために用いられるＩＰ／ＵＤＰ／ＲＴＰヘッダであることを特徴とするデータ・ネットワーク。
【請求項１０】
請求項８に記載のデータ・ネットワークにおいて、上記コンテキスト状態が確立された後、上記対応する２次差がノンゼロでない限り、変化するフィールドの上記１次差の伝送を終了するために前記ヘッダ圧縮メカニズムを実行することを特徴とするデータ・ネットワーク。
【請求項１１】
パケット・ネットワークにおいて、
各パケットがヘッダ・フィールドを含む複数のパケットを供給する発信側端末と、
受信側端末と、
上記発信側端末と上記受信側端末との間で接続を行う帯域限定リンクと、を具備し、
上記発信側端末または上記受信側端末の少なくとも一方のネットワーク・インターフェース・コントローラが、ヘッダの圧縮と再構成を行うための、該コントローラにインストールされたヘッダ圧縮メカニズムを具備し、前記ヘッダ圧縮メカニズムは、変化しないフィールドのコンテキスト状態、並びに、変化するフィールドの１次差を確立し、次いで、任意のフィールドの２次差がノンゼロであるとき、新しい１次差と共にノンゼロの２次差を持つ特定パケットを、上記新しい１次差が受信された旨を示す肯定の確認が受信されるまで、もしくは、所定期間の期限切れまで、上記新しい１次差を持つ当該後続パケットと共に伝送することを特徴とするパケット・ネットワーク。
【請求項１２】
請求項１１に記載のパケット・ネットワークにおいて、データ・パケットのラウンド・トリップ時間とパケット間分離時間との商として前記所定期間を設定することを特徴とするパケット・ネットワーク。
【請求項１３】
請求項１１に記載のパケット・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、ダイアルアップ・モデムのような低速回線に対応することを特徴とするパケット・ネットワーク。
【請求項１４】
請求項１１に記載のパケット・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、セルラ・リンクに対応することを特徴とするパケット・ネットワーク。
【請求項１５】
請求項１１に記載のパケット・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、インターネット・サービス・プロバイダ（ＩＳＰ）のＩＰベースのネットワークと、インターネットと、例えば公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）、及び、前記第１のノードと前記第２のノードとの間の通信を可能にするその他のアクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）などを含む様々な発信側ネットワークと着信側ネットワークと、に対応することを特徴とするパケット・ネットワーク。
【請求項１６】
請求項１１に記載のパケット・ネットワークにおいて、ノンゼロの２次差を持つ上記対応フィールドが上記１次差の通信時間中再び変化したとき、上記圧縮装置が、上記解凍装置へ伝送するために上記新しい１次差を上記元の１次差と組み合わせることを特徴とするパケット・ネットワーク。
【請求項１７】
請求項１１に記載のパケット・ネットワークにおいて、前記ヘッダ・フィールドがタイム・スタンプとパケット・シーケンス番号とを含むことを特徴とするパケット・ネットワーク。
【請求項１８】
請求項１１に記載のパケット・ネットワークにおいて、上記パケットの紛失やエラーの発生時に前記パケットのヘッダを正しく再構成するために前記ヘッダ圧縮メカニズムを実行することを特徴とするパケット・ネットワーク。
【請求項１９】
請求項１１に記載のパケット・ネットワークにおいて、前記ヘッダが、上記インターネットでのリアルタイム通信のために、及び、ボイス・オーバーＩＰとテレビ会議などのようなアプリケーションのために用いられるＩＰ／ＵＤＰ／ＲＴＰヘッダであることを特徴とするパケット・ネットワーク。
【請求項２０】
請求項１１に記載のパケット・ネットワークにおいて、上記コンテキスト状態が確立された後、上記対応する２次差がノンゼロでない限り、変化するフィールドの上記１次差の伝送を終了するために前記ヘッダ圧縮メカニズムを実行することを特徴とするパケット・ネットワーク。
【請求項２１】
信頼できないネットワークが存在する場合に、圧縮装置と解凍装置との間でロバストなヘッダ圧縮を達成する方法において、
前記解凍装置が前記データ・パケットの変化しないフィールドのコンテキスト状態、並びに、変化するフィールドの１次差を確立するまで、帯域限定リンクを介して前記圧縮装置から前記解凍装置へデータ・パケットのヘッダを伝送するステップと、
前記圧縮装置と前記解凍装置との間に上記コンテキスト状態が確立されたとき、任意のフィールドの２次差がノンゼロであるかどうかを決定するステップと、
任意のフィールドの２次差がノンゼロであるとき、新しい１次差と共にノンゼロの２次差を持つ特定パケットを、上記新しい１次差が受信された旨を示す肯定の確認が受信されるまで、もしくは、所定期間の期限切れまで、上記新しい１次差を持つ当該後続パケットと共に伝送するステップと、を有することを特徴とする方法。
【請求項２２】
請求項２１に記載の方法において、データ・パケットのラウンド・トリップ時間とパケット間分離時間との積として前記所定期間を設定することを特徴とする方法。
【請求項２３】
請求項２１に記載の方法において、前記圧縮装置と前記解凍装置とを接続するために設けた前記帯域限定リンクが、ダイアルアップ・モデムのような低速回線に対応することを特徴とする方法。
【請求項２４】
請求項２１に記載の方法において、前記圧縮装置と前記解凍装置とを接続するために設けた前記帯域限定リンクが、セルラ・リンクに対応することを特徴とする方法。
【請求項２５】
請求項２１に記載の方法において、前記圧縮装置と前記解凍装置とを接続するために設けた前記帯域限定リンクが、インターネット・サービス・プロバイダ（ＩＳＰ）のＩＰベースのネットワークと、インターネットと、例えば公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）、及び、前記第１のノードと前記第２のノードとの間の通信を可能にするその他のアクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）などを含む様々な発信側ネットワークと着信側ネットワークと、に対応することを特徴とする方法。
【請求項２６】
請求項２１に記載の方法において、ノンゼロの２次差を持つ上記対応フィールドが上記１次差の通信時間中再び変化したとき、上記解凍装置へ伝送するために、上記新しい１次差を上記元の１次差と組み合わせることを特徴とする方法。
【請求項２７】
請求項２１に記載の方法において、前記データ・パケットの各々がタイム・スタンプとパケット・シーケンス番号と有するヘッダ・フィールドを含むことを特徴とする方法。
【請求項２８】
請求項２１に記載の方法において、前記ヘッダが、上記インターネットでのリアルタイム通信のために、及び、ボイス・オーバーＩＰとテレビ会議などのようなアプリケーションのために用いられるＩＰ／ＵＤＰ／ＲＴＰヘッダであることを特徴とする方法。
【請求項２９】
ホスト可読媒体であって、圧縮／解凍装置を含むホスト・システムにより命令が実行されるとき、
前記解凍装置が前記データ・パケットの変化しないフィールドのコンテキスト状態、並びに、変化するフィールドの１次差を確立するまで、帯域限定リンクを介して前記圧縮装置から前記解凍装置へデータ・パケットのヘッダを伝送するステップと、
前記圧縮装置と前記解凍装置との間に上記コンテキスト状態が確立されたとき、任意のフィールドの２次差がノンゼロであるかどうかを決定するステップと、
任意のフィールドの２次差がノンゼロであるとき、新しい１次差と共にノンゼロの２次差を持つ特定パケットを、上記新しい１次差が受信された旨を示す肯定の確認が受信されるまで、もしくは、所定期間の期限切れまで、上記新しい１次差を持つ当該後続パケットと共に伝送するステップとによって、遠隔システムの圧縮装置と解凍装置との間でロバストなヘッダ圧縮を上記ホスト・システムに行わせる命令を含むことを特徴とするホスト可読媒体。
【請求項３０】
請求項２８に記載のホスト可読媒体において、データ・パケットのラウンド・トリップ時間とパケット間分離時間との商として前記所定期間を設定することを特徴とするホスト可読媒体。
【請求項３１】
請求項２８に記載のホスト可読媒体において、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、低速回線かセルラ・リンクのいずれかに対応することを特徴とするホスト可読媒体。
【請求項３２】
請求項２８に記載のホスト可読媒体において、ノンゼロの２次差を持つ上記対応フィールドが上記１次差の通信時間中再び変化したとき、上記圧縮装置が、上記解凍装置へ伝送するために上記新しい１次差を上記元の１次差と組み合わせることを特徴とするホスト可読媒体。
【請求項３３】
請求項２８に記載のホスト可読媒体において、前記ヘッダ・フィールドが、タイム・スタンプとパケット・シーケンス番号とを含み、上記インターネットでのリアルタイム通信のために、及び、ボイス・オーバーＩＰとテレビ会議などのようなアプリケーションのために用いられるＩＰ／ＵＤＰ／ＲＴＰヘッダであることを特徴とするホスト可読媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ・ネットワークにおけるデータの圧縮と解凍に関し、具体的には、信頼できないネットワークが存在する場合にロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮を達成するシステム及び方法に関する。
【０００２】
【従来の技術】
最近、インターネットの利用が増加した結果、ネットワーク容量の不足が生じて、従来のアプリケーションのパフォーマンスに対して否定的影響を与えるようになっている。同時に、テレビ会議やボイス・オーバーＩＰ（ＶｏＩＰ）を含む双方向型オーディオ及び／又はビデオなどの、タイムリなデータ配信並びにはるかに改善されたサービス品質が要求される新しいアプリケーションが現れてきた。テレビ会議やボイス・オーバーＩＰ（ＶｏＩＰ）のような、様々なタイプのネットワーク用リアルタイム・アプリケーション間でのインターオペラビリティ（相互運用性）を得るためにリアルタイム転送プロトコル（ＲＴＰ）が利用されてきた。インターネット・プロトコル（ＩＰ）ベースのリアルタイム・マルチメディア用として、ユーザ・データグラム・プロトコル（ＵＤＰ／ＩＰ）の上位でＲＴＰを使用して、“ＲＴＰ：リアルタイム・アプリケーション用トランスポート・プロトコル”（Ｈｅｎｎｉｎｇ Ｓｃｈｕｌｚｒｉｎｎｅ， Ｓｔｅｐｈｅｎ Ｌ． Ｃａｓｎｅｒ， Ｒｏｎ Ｆｒｅｄｅｒｉｃｋ， ａｎｄ Ｖａｎ Ｊａｃｏｂｓｏｎ共著、インターネットの技術標準文書（ＲＦＣ）１８８９年、１９９６年１月）に記述されているような多重化及びチェックサム・サービスの利用が可能である。しかし、ダイアルアップ・モデムのような低速回線を介して伝送を行う場合、容認できる双方向型の応答と回線効率にとってＲＴＰヘッダが大きくなりすぎるかもしれないという懸念がある。例えば、インターネット・プロトコル・バージョン４（ＩＰｖ４）では、ＩＰ／ＵＤＰ／ＲＴＰを含むヘッダ・フィールドは、パケット当たり４０バイトを占めることができる。同様に、インターネット・プロトコル・バージョン６（ＩＰｖ６）では、このようなヘッダ・フィールドはパケット当たり６０バイトを占めることができる。音声ペイロードを（２０ｍｓのＧＳＭ符号化音声に対応する）３６バイトほどの小さなものとすることも可能な通話用音声のようなリアルタイム・アプリケーションでは、このヘッダ・オーバーヘッドはきわめて大きなものである。従って、リアルタイム・アプリケーションではこのようなヘッダ・オーバーヘッドを大幅に減らす必要がある。
【０００３】
現在、ヘッダ・オーバーヘッドを低減して、低速及び中速リンクでの帯域の効率的な利用を可能にするための、ＩＰ／ＵＤＰ／ＲＴＰデータグラムのヘッダ圧縮に利用可能なヘッダ圧縮手法はほとんどが存在しない。このようなヘッダ圧縮手法の最も最近の例が、“低速シリアルリンク用ＩＰ／ＵＤＰ／ＲＴＰヘッダの圧縮”（Ｓｔｅｐｈｅｎ Ｌ． Ｃａｓｎｅｒ及びＶａｎ Ｊａｃｏｂｓｏｎ、ＲＦＣ２５０８、１９９９年２月）に記載されている。ＩＰ／ＵＤＰ／ＲＴＰデータグラムのヘッダを圧縮して、２〜４バイトまでヘッダ・オーバーヘッドを低減する圧縮／解凍装置を備えたヘッダ圧縮メカニズムが提供されている。このヘッダ圧縮方式は、ＩＰヘッダのほとんどのフィールドが、接続寿命（すなわちセッションの長さ）の間パケット・ストリームの中で一定のままであるという観察に基づくものである。したがって、解凍装置で圧縮状態を保持することにより、また、（エラー検出及びパケット紛失検出用として使用するセッション・コンテキスト識別子と小さなシーケンス番号のような）最低量のヘッダ・オーバーヘッドを圧縮装置から解凍装置へ単にトランスポートすることにより、ヘッダ圧縮を達成することも可能である。ＲＦＣ２５０８によれば、解凍装置での圧縮状態は、すべてのパケットで変化するフィールド、及び、すべてのパケットで変化しないフィールドを含む未圧縮のヘッダ・フィールドに対応するようにしてもよい。（発信元と宛先のＩＰアドレス及びポート番号のような）変化しないフィールドの場合、解凍装置は、圧縮状態で保存されている対応フィールドを単に加算するだけでよい。しかし、変化するフィールドの場合、解凍装置は、圧縮パケット・ヘッダで送られる情報に依拠することができる。典型的には、圧縮パケット・ヘッダの中に内包される情報は、前回のパケット内のフィールドの値（すなわち変化するフィールドのノンゼロの２次差のみに関する変化の差）を含み、変化したフィールド自身を含むものではない。
【０００４】
一般的処理を行うために、変化しないフィールドのコンテキスト状態及び変化するフィールドの１次差が解凍装置により確立されるまで完全なＩＰ／ＵＤＰ／ＲＴＰヘッダを解凍装置へ伝送することにより圧縮装置は始動する。いったんコンテキスト状態が確立されると、２次差（デルタ）がノンゼロである限り、圧縮装置は差（特に、ＲＴＰタイム・スタンプやＲＴＰシーケンス番号などのようなＲＴＰヘッダ・フィールドに対応する差）を伝送する必要はなくなる。パケットからパケットへのＲＴＰヘッダの２次差（デルタ）がゼロである場合、解凍装置は、各圧縮パケットが受信されたとき、前回のパケットを表す保存されている未圧縮ヘッダに１次差を単純に加算することにより、情報ロスのないパケットの再構成（復元）が可能となる。通信の必要があるのはただ、圧縮装置と解凍装置との間のパケット紛失を検出するためのセッション・コンテキスト識別子（ＩＤ）と小さなシーケンス番号（ＲＴＰシーケンス番号とは関連しない）だけである。例えば、パケット＃１、＃２、＃３のＲＴＰタイム・スタンプが、２０から４０、６０へと変化する場合、２０と４０及び４０と６０との間の１次差は２０である。初期値２０が既知である場合、２次差がゼロであることが圧縮ヘッダ内の適切なフィールドによって示されていれば、解凍装置はパケット＃３の正しい増分値を単に加算するだけでよい。
【０００５】
一方、いくつかのフィールドのＲＴＰヘッダの２次差（デルタ）がゼロでない場合、コンパクトな符号化を用いてそれらのフィールドだけの新しい１次差を通信しなければならない。これらの新しい１次差の値は、解凍装置のセッション・コンテキスト内の未圧縮ヘッダ内の対応フィールドに加算され、次いで、セッション・コンテキストの中にはっきりと保存されて、２次差（デルタ）がゼロである各後続パケット内の対応フィールドに再び加算される。後続パケット内で１次差が変化する度にその差が伝送され、セッション・コンテキストの更新に利用される。
【０００６】
しかし、インターネット共同体に利用可能なインターネット用の規格プロトコルが含まれるＲＦＣ２５０８及びその他のＲＦＣ文書に記載されているようなヘッダ圧縮方式は、帯域が不足し、多くのリンク・エラーや長いリンク待ち時間が生じる（セルラ無線ネットワークのような）環境での処理には適していない。パケットの紛失に起因して、解凍装置が、ＲＴＰタイム・スタンプやＲＴＰシーケンス番号のような間違ったヘッダ情報を受信に成功した次のパケットに加算する可能性がある。同様に、圧縮パケット・ヘッダがエラーになった場合、ＲＴＰパケットの同様の間違った再構成が結果として生じる可能性がある。例えば、１フィールド（または複数のフィールド）の新しい１次差を含むパケットが（おそらくエラーに起因して）紛失したと考えられる場合、解凍装置が圧縮装置に通知するか、必要な１次差の再送に圧縮装置が成功するまで後続パケット用ヘッダの正しい再構成はできなくなる。この回復段階中、ヘッダの再構成を行うために伝送済みパケットと伝送中パケットの処理を行うことはできない。ボイス・オーバーＩＰ（ＶｏＩＰ）やテレビ会議のようなリアルタイム・アプリケーションの場合、プレイアウト・デッドライン（ｐｌａｙ−ｏｕｔ ｄｅａｄｌｉｎｅ）の期限切れに起因してこれらのパケットは破棄される可能性がある。例えば、（基地局のような）無線アクセス・ポイントから移動機への１方向遅延（または基地局から移動機へ、次いで基地局へもどる１２０ｍｓのラウンド・トリップ遅延）の６０ｍｓを持つセルラ・リンク、及び、トーク・スパート（ｔａｌｋｓｐｕｒｔ）中の２０ｍｓの音声パケット間でのパケット間（ｉｎｔｅｒ−ｐａｃｋｅｔ）分離について考えてみよう。トーク・スパートの開始時に、一番最初のパケットのＲＴＰタイム・スタンプは、無音間隔に起因してその２次差がノンゼロとなるように増分する。したがって、この一番最初のパケットで解凍装置へ新しい１次差を通信しなければならない。パケットがエラーに起因してなぜか紛失した場合、解凍装置が故障に関する情報を圧縮装置に与えるまで、次の３個のパケット（６０ｍｓ／２０ｍｓ）の再構成を行うことはできない。この故障時間中、（トーク・スパートが少なくとも６個のパケットで持続すると仮定した場合）別のさらに３個のパケットが圧縮装置により伝送されたであろう。解凍装置によって正しい１次差が受信されるまでこれら６個のパケットはすべて待機する必要があり、その結果、プレイアウト・デッドラインの期限切れのために破棄される可能性がある。
【０００７】
したがって、信頼できないネットワークが存在する際のロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式に対する要望が存在する。さらに、ヘッダ・パケットの紛失やエラーの発生時に正しく再構成を行うことが可能な方式が必要とされている。
【０００８】
【発明が解決しようとする課題】
したがって、本発明の様々な実施例は、パケットの紛失やエラーの発生時に、ＩＰ／ＵＤＰ／ＲＴＰヘッダの正しい再構成が可能なロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮メカニズムと手法を目的とするものである。このヘッダ圧縮メカニズムには、ＲＦＣ２５０８に類似して処理を行うように実現される圧縮／解凍装置であって、紛失が多く、エラーし易いネットワークで使用される場合、ロバスト性を処理できるように特別に設計された圧縮／解凍装置が含まれ、パケットの紛失やエラーの発生時にヘッダの正しい再構成が可能となる。
【０００９】
【課題を解決するための手段】
本発明の１つの態様によれば、上記ロバストなヘッダ圧縮方式の要件として、フィールドの２次差がノンゼロである場合、ノンゼロの２次差を持つ或る特定のＲＴＰパケットを新しい１次差と共に伝送することが求められるだけでなく、（ａ）ある時間が、チャンネル特性（リンク・ラウンド・トリップ時間ＲＴＰ／パケット間分離など）のような係数により予め定められているか、（ｂ）新しい１次差が正しく受信された旨の肯定の確認が圧縮装置により受信される限り、その新しい１次差と共に後続パケットを伝送することが求められる。その結果、後続パケットの“自制”が保証され、たとえ２次差をノンゼロとなるようにしたパケットが紛失しても、解凍装置は該後続のパケットのヘッダの正しい再構成を行うことが可能となる。
【００１０】
本発明の別の態様によれば、ロバストなヘッダ圧縮方式の要件として、対応するＲＴＰフィールドが１次差の通信時間中ノンゼロの２次差と共に再び変化した場合、これら２つの１次差を高い信頼性で通信する単純な手段としてこれら２つの１次差をまとめて後ろに付加することができるように“新しい”１次差は元の１次差と組み合わされる。しかし、本発明は効率を図る目的で１次差を組み合わせる別の手段を除外するものではない。
【００１１】
【発明の実施の形態】
単に例として添付されている図面を参照しながら以下のパラグラフで本発明についてさらに具体的に説明する。
【００１２】
本発明のさらに完全な理解、及び、本発明の付随する利点の多くは、添付図面と関連して考察し、以下の詳細な記述を参照して同発明をより良く理解したとき容易に明らかになる。上記添付図面では同じ参照記号により、同じまたは類似の構成要素が示されている。
【００１３】
本発明は、すべてのタイプのデータ・ネットワークとリアルタイム通信サービスと共に使用するために適用可能である。例えば、データ・ネットワークは、ボイス・オーバーＩＰ（ＶｏＩＰ）やテレビ会議（ビデオ・オーバーＩＰ）のようなリアルタイム・アプリケーション用として利用される、イーサネット・ローカル・エリア・ネットワーク（ＬＡＮ）、非同期転送モード（ＡＴＭ）、フレーム・リレー及びインターネットを含むパケット・ネットワークであってもよい。上記とは別に、このようなデータ・ネットワークは、旧来の電話サービス（ＰＯＴＳ）、公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）、移動通信ネットワーク、衛星ネットワーク、及び、地上デジタルＴＶや無線、セルラ、短距離用無線（ブルートゥース、ＲＦプロトコル、無線ＬＡＮ）ネットワークなどのネットワークを含む私設ネットワークまたは公衆ネットワークであってもよい。しかし、説明を単純にするために、本解説では、ボイス・オーバーＩＰ（ＶｏＩＰ）やテレビ会議（ビデオ・オーバーＩＰ）のようなリアルタイム・アプリケーションのための様々な構成から成る単純なデータ・ネットワークが主として中心となる。但し、本発明の範囲と実現はこのようなデータ・ネットワークに限定されるものではない。
【００１４】
図面、特に、図１の発信側端末２０と受信側端末３０からなる、本発明の実施例に従う単純なデータ・ネットワークに注意されたい。図１に図示のように、帯域限定リンク１０を利用して発信側端末２０を受信側端末３０と接続するようにすることも可能である。帯域限定リンク１０はダイアルアップ・モデムまたは高周波（ＲＦ）無線リンク（セルラ・リンク）などの低速回線を表すものであってもよい。上記とは別に、帯域限定リンク１０は、インターネット・サービス・プロバイダ（ＩＳＰ）のＩＰベースのネットワーク、インターネット、例えば、公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）及び発信側端末２０と受信側端末３０との間の通信を可能にするその他のアクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）などを含む様々な発信側ネットワーク及び着信側ネットワークを含むものであってもよい。帯域限定リンク１０がセルラ・リンクに対応する場合、発信側端末２０及び受信側端末３０は移動端末装置と基地局にそれぞれ対応するようにすることも可能であり、また、その逆も可能である。
【００１５】
発信側端末２０には、例えば、少なくともホスト２２とネットワーク・インターフェース・コントローラ（ＮＩＣ）２４とが含まれる。同様に、受信側端末３０には、例えば、少なくともホスト３２とネットワーク・インターフェース・コントローラ（ＮＩＣ）３４とが含まれる。複数のホストが発信側端末２０と受信側端末３０に含まれるようにしてもよい。各ホストは、帯域限定リンク１０を介して発信側端末２０から受信側端末３０へデータ・パケットを伝送するＩＰ電話やスタンド・アローン型ＰＣに対応するようにしもよい。
【００１６】
発信側端末２０では、ホスト２２は、ネットワーク・インターフェース・コントローラ（ＮＩＣ）２４へ転送するデータを生成する。発信側端末２０のＮＩＣ２４は、例えば、ユーザ・データグラム・プロトコル（ＵＤＰ／ＩＰ）の上位で用いられるリアルタイム転送プロトコル（ＲＴＰ）を利用してホスト２２からの着信データをデータ・パケットに変換し、帯域限定リンク１０を介してこれらのデータ・パケットを注入する。帯域限定リンク１０がＩＰベースのネットワークである場合、そのデータ・パケットのレートはＩＰベースのネットワーク１０を介して注入されて、外へ向かうデータ・フローパケットの制御と管理がＮＩＣ２４により行われ、ＩＰベースのネットワーク１０における輻輳状態の回避及びデータ・パケット帯域の使用の限定が図られる。ＩＰベースのネットワーク１０は着信データ・パケットを受け取り、次いで、ヘッダに含まれる情報に従って受信側端末３０へ同着信データ・パケットを転送する。受信側端末３０のＮＩＣ３４は、ＩＰベースのネットワーク１０からこれらのデータ・パケットを受け取り、同データ・パケットをデータに変換し、次いでホスト３２へ該データの転送を行う。
【００１７】
図２Ａ〜２Ｂは本発明の実施例に従う単純なデータ・ネットワークで利用する例示データ・パケットを示すものである。図２Ａに図示のように、例示データ・パケット１００は、データ・ペイロード１３０のセグメントと、データ・ペイロード１３０の前に付加される小さなヘッダ１２０とから構成される。パケット１００は、ボイス・オーバーＩＰ（ＶｏＩＰ）またはビデオ・オーバーＩＰのリアルタイム・トラフィックを表すものであってもよいが、これに限定されるものではない。例えば、ヘッダ・セグメント１２０には、ＩＰアドレス・フィールド（一般にネットワークＩＤとホストＩＤとから成る３２ビット・グローバル・インターネット・アドレス）と、ＩＰのどのバージョンがＩＰパケットの中に表されているか（例えばＩＰバージョン４及びＩＰバージョン６など）を指定するために使用されるバージョン・フィールドと、様々なサービス品質を提供するＩＰベースのネットワークでのＩＰパケットの処理方法を指定するために使用されるサービス・フィールドのタイプと、伝送エラーの検証に使用されるヘッダ・チェックサム・フィールドとが含まれる。フラグとフラグメント・オフセット・フィールド、合計長フィールド、ＩＤフィールド、ＴＴＬ（ｔｉｍｅ ｔｏ ｌｉｖｅ）フィールドと、プロトコル・フィールドなどのその他のＩＰフィールドをこのようなヘッダの中に含めてもよい。インターネット・プロトコル・バージョン４（ＩＰｖ４）では、ＩＰ／ＵＤＰ／ＲＴＰを含むヘッダ・フィールドはパケット当たり４０バイト、また、インターネット・プロトコル・バージョン６（ＩＰｖ６）の場合には、パケット当たり６０バイトを占めることが可能である。ヘッダ・オーバーヘッドは、データ・ペイロードに比べて一般に相当の大きさになり、特に、実際の音声ペイロードが３６バイト（２０ｍｓのＧＳＭ符号化音声に対応する）ほどの小さなものである場合もある通話用音声のような、ユーザ・データグラム・プロトコル（ＵＤＰ／ＩＰ）の上位で使用されるリアルタイム転送プロトコル（ＲＴＰ）が用いられるリアルタイム・アプリケーションの場合には、ヘッダ・オーバーヘッドは相当の大きさのものになる。
【００１８】
図２Ｂは、ＩＰヘッダ１２２と、ＵＤＰヘッダ１２４と、ＲＴＰヘッダ１２６、及び、例えば、図２Ａに図示の音声サンプルなどを含むデータ・ペイロード１３０の組合せを含む例示ヘッダ・セグメント１２０を示す。
【００１９】
図３は、本発明の実施例に従う、未圧縮フォーマットの例示ＲＴＰヘッダ１２６を示す。図３に図示のように、未圧縮のＲＴＰヘッダ１２６にはタイム・スタンプ（Ｔ）３１０と、シーケンス番号（ＳＮ）３１２と、その他のフィールド３１４とが含まれる。ＩＰネットワークのパケット交換型の性質（図１を参照）に起因して、ＲＴＰパケットが間違った順序で着信する場合がある。受信側端末３０でシーケンス番号３１２を使用して、ＲＴＰ音声サンプルを正しい順序に組み立てることも可能である。しかし、ＲＴＰパケット内のシーケンス番号は、フィールドのいずれの非線形変化（音声信号の無音間隔）も反映しない場合がある。したがって、タイム・スタンプ（Ｔ）３１０を設けて各パケットの相対的タイミングを示すようにしてもよい。
【００２０】
前述したように、各ＲＴＰパケット内のＩＰ／ＵＤＰ／ＲＴＰヘッダにより供給される４０〜６０バイトのヘッダ・オーバーヘッドが大きすぎる場合もある。特に、ＲＴＰタイム・スタンプがあまりに大きな負担となるためダイアルアップ・モデムや帯域限定リンクなどのような低速回線を介してＲＴＰパケットがトランスポートを行うことができなくなる場合もある。したがって、図１に図示のデータ・ネットワークの発信側端末２０のＮＩＣ２４の中には（またエンド・ツー・エンド・ベースの双方向通信用受信側端末２０のＮＩＣ３４の中にも）、一般に、発信側端末２０と受信側端末３０においてヘッダ圧縮を行うヘッダ圧縮メカニズム２６と３６が含まれる。上記メカニズムは、ダイアルアップ・モデムまたは帯域限定リンクなどのような低速回線を介する作動時に、容認できる双方向型の応答と回線効率のためにヘッダのオーバーヘッドの低減を図るものである。ヘッダ圧縮メカニズム２６と３６に、ＩＰ／ＵＤＰ／ＲＴＰデータグラムのヘッダを圧縮する圧縮／解凍装置を設けて、２〜４バイトまでヘッダ・オーバーヘッドを低減するようにしてもよい。ＣやＣ＋＋のような高水準プログラム言語と汎用コンピュータを用いて標準的プログラミング方法により構成されるハードウェア及び／又はソフトウェアによりヘッダ圧縮メカニズム２６と３６を実現して、ヘッダ圧縮を達成するようにしてもよい。ソフトウェア・モジュールによりヘッダ圧縮メカニズム２６と３６を実現する場合、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの半導体記憶装置、フラッシュメモリ・デバイス、磁気ディスク（固定ディスク、フロッピー・ディスク、リムーバブル）、テープなどのその他の磁気媒体及びＣＤ−ＲＯＭディスクなどのような光媒体を含む有形の媒体（但しこれらに限定されるものではない）上にこのようなソフトウェア・モジュールを設けることも可能である。ホストのネットワーク・インターフェース・カードと共にこのようなソフトウェア・モジュールをバンドルしてもよい。上記とは別に、ヘッダ圧縮メカニズム２６と３６は、ファームウェア・モジュールまたはホストに組み込みが可能な包括的なハードウェア／ソフトウェア・モジュールとして利用できるものであってもよい。さらに、ヘッダ圧縮メカニズム２６と３６とは、ＲＦＣ２５０８に類似の機能を行うために実現可能であるが、セルラ無線ネットワークのような多くのリンク・エラーや長いリンク待ち時間が生じることを特徴とする、紛失が多く、エラーし易いネットワーク環境で使用される場合、アドレスのロバスト性を処理できるように特別に設計されて、パケットの紛失やエラーの発生時にヘッダの正しい再構成が図られるようになっている。
【００２１】
図１に図示の発信側端末と受信側端末及びリンクの具体的な数と構成は、帯域が不足し、エラーが稀ではない場合もあるデータ・リンクを介してデータ・パケットのヘッダ圧縮と伝送を行うヘッダ圧縮方式が利用される例示データ・ネットワークとして単に示されているものにすぎない。すべてのタイプのデータ・ネットワークにおいてどのような数の端末装置、交換機、リンクから成る多種多様な実現例と構成例が可能である。
【００２２】
ヘッダ圧縮処理を行うために、ＲＦＣ２５０８に記載されている方法と同じ方法で、変化しないフィールドのコンテキスト状態並びに変化するフィールドの１次差が解凍装置３６により確立されるまで、受信側端末３０の解凍装置３６へ完全なＩＰ／ＵＤＰ／ＲＴＰヘッダを伝送することにより発信側端末２０の圧縮装置２６は始動する。すなわち、コンテキスト状態が確立されると、２次差（デルタ）がノンゼロでない場合、発信側端末２０の圧縮装置２６は、１次差（特に、例えば、ＲＴＰタイム・スタンプとＲＴＰシーケンス番号などのようなＲＴＰヘッダ・フィールドに対応する差）を伝送する必要はなくなる。パケットからパケットへのＲＴＰヘッダ（またはデータ・パケットのＩＰ／ＵＤＰヘッダ）の２次差（デルタ）がゼロである場合、各圧縮パケットが受信されたとき、受信側端末３０の解凍装置３６は、前回のパケットを表す保存された未圧縮ヘッダに１次差を単に加算するだけで、情報の紛失が皆無のパケットの再構成が可能となる。
【００２３】
いずれかのフィールドのＲＴＰヘッダの２次差（デルタ）がノンゼロである場合、発信側端末２０の圧縮装置２６は、ＲＦＣ２５０８に記載の方法で、対応フィールドの新しい１次差を伝送するように機能する。しかし、ＲＦＣ２５０８に加えて、（帯域が不足し、多くのリンク・エラーと長いリンク待ち時間が生じる可能性があるセルラ・ネットワークまたは無線ネットワークのような）紛失が多く、エラーし易い、信頼できないネットワークで使用する場合、ヘッダ圧縮メカニズム２６と３６がロバスト性を処理できるように特別に設計され、実現されて、パケットの紛失やエラーの発生時にヘッダの正しい再構成が行われる。
【００２４】
一般に、本発明のヘッダ圧縮方式の要件として、フィールドの２次差がノンゼロである場合、ノンゼロの２次差を持つ或る特定のＲＴＰパケットを発信側端末２０の圧縮装置２６から新しい１次差と共に伝送することが求められるだけでなく、（ａ）ある時間が、チャンネル特性（リンク・ラウンド・トリップ時間ＲＴＰ／パケット間分離など；ラウンド・トリップ時間ＲＴＴとは、データ・パケットまたはフレームが発信側端末２０から受信側端末３０までどれだけの長さを進むかを示す推定値である）のような係数によって予め定められているか、（ｂ）新しい１次差が正しく受信された旨の肯定の確認が発信側端末２０の圧縮装置２６により受信される限り、その新しい１次差と共に後続パケットの伝送も求められる。上記要件によって、後続パケットの“自制”が保証され、たとえ２次差をノンゼロとなるようにしたパケットが紛失しても、受信側端末３０の解凍装置３６による該後続パケットのヘッダの正しい再構成を行うことが可能となる。
【００２５】
本発明の別の態様によれば、対応するＲＴＰフィールドが１次差の通信時間中ノンゼロの２次差と共に再び変化した場合、これら２つの１次差を高い信頼性で通信する単純な手段としてこれら２つの１次差をまとめて後ろに付加することができるように“新しい”１次差は元の１次差と組み合わされる。しかし、本発明は効率を図る目的で１次差を組み合わせる別の手段を除外するものではない。
【００２６】
ここで図４Ａ〜４Ｂを参照しながら、変化するフィールドのための、発信側端末２０の圧縮装置２６及び受信側端末３０の解凍装置３６の機能、及び、パケットの紛失やエラーの発生時にヘッダを正しく再構成できる方法の諸例について以下本明細書で説明する。
【００２７】
単一の変化するフィールドの場合、ｘｎを発信側端末２０の圧縮装置２６が伝送しなければならないフィールドｇｎの１次差符号値（すなわち１次差の符号化された値）とする。なぜなら、該符号値は、パケットｐｎの中で通常の予想値とは異なる量だけ変化し、受信側端末３０の解凍装置３６による受信に成功しなかったからである。
【００２８】
Ｘｎ＝ｘ（ｎ−１）＊ｆ（ｎ−１，ｎ）＊Ｘｎかつｘ（ｎ＋１）＝Ｘｎ＊ｆ（ｎ，ｎ＋１）＊ｘ（ｎ＋１）と定義する。但し、ｆ（ｉ，ｊ）は、Ｘｎとｘ（ｎ＋１）とからＸｎ（共通入力）を計算し、所定のＸｎとＸｎ、ｘ（ｎ−１）の一意的計算を可能にするものである。さらに、ｆ（ｉ，ｊ）は、入力ｘｎまたはｘ（ｎ−１）のうちのいずれか一方がゼロの場合、Ｘｎ＝ノンゼロ入力を設定するようにするものである。
【００２９】
ｆ（ｉ，ｊ）の最も単純な形は、“アペンド（ａｐｐｅｎｄ）”関数であり、これは存在するフィールドに単に冗長性をつけ加えるだけの関数である。例えば、上記のＸｎはｘ（ｎ−１）とｘｎの双方から構成されるものであってもよい。さらに優れた関数を利用してもよい。しかし、関数の複雑さとＸｎを表すために必要とされるビットの減少との間でトレードオフが行われる。
【００３０】
発信側端末２０の圧縮装置２６は、たとえ対応フィールドｇ（ｎ＋１）が予想量とは異なる量しか変化しない場合であっても（この場合ｘ（ｎ＋１）はゼロになる）、パケットｐｎに対応するＸｎと、ｐ（ｎ＋１）に対応するｘ（ｎ＋１）の計算を行うことが可能である。発信側端末２０の圧縮装置２６は、ｘｎの代わりにｐｎでＸｎを伝送し、ｘ（ｎ＋１）の代わりにｐ（ｎ＋１）でＸ（ｎ＋１）を伝送する。
【００３１】
パケットｐｎが紛失し、ｐ（ｎ＋１）とｐ（ｎ＋２）とが受信された場合、ｘ（ｎ＋１）の計算が可能となり、Ｘ（ｎ＋１）が既知となるためＸｎの計算も可能となる。したがって、パケットｐｎの紛失がヘッダの正しい再構成に影響を与えることはない。その結果、単一パケットの紛失に対する保護を行うことが可能となる。
【００３２】
ｆ（ｉ，ｊ）が“アペンド”関数以外の場合、Ｘｎの計算をＸｎとｘ（ｎ−１）だけに限定する必要はない。ｘｎは上記すべてのｘｉの関数とすることができる。但し、対応する関数ｆ（ｉ，ｉ−ｊ）が存在する限り、任意のｉ−ｊの値についてｉ＝ｉ，ｉ−１，ｉ−２，．．．ｉ−ｊである。任意の２つのＸｉとＸ（ｉ＋１）から、共通入力ｘｉ、ｘ（ｉ−１）、ｘ（ｉ−２）、．．．、ｘ（ｉ−ｊ）をｘｉとｘ（ｉ＋１）から別個に計算することができる。このような場合、フィールドの変化が生じたとき、パケット紛失のバーストに対する保護を目的として、発信側端末２０の圧縮装置２６はｘ（ｉ−ｊ）までｘｉ値を計算しなければならない。
【００３３】
ｆ（ｉ，ｊ）が“アペンド”関数であるとき、本発明の１つの態様として記述される要件により、バースト・パケット紛失に対する保護が行われる。すなわち、フィールドの２次差がノンゼロである場合、ノンゼロの２次差を持つ或る特定のＲＴＰパケットを新しい１次差と共に伝送することが求められるだけでなく、（ａ）ある時間が、チャンネル特性（リンク・ラウンド・トリップ時間ＲＴＰ／パケット間分離など）のような係数によって予め定められているか、（ｂ）新しい１次差が正しく受信された旨の肯定の確認が圧縮装置により受信される限り、上記新しい１次差と共に後続パケットの伝送も求められる。
【００３４】
図４Ａ〜４Ｂに図示のように、変化するフィールドのための、発信側端末２０の圧縮装置２６及び受信側端末３０の解凍装置３６のについて以下説明する。図４Ａでは、本発明の実施例に従う、圧縮フォーマットでの例示ＲＴＰパケット１００の中に、コンテキスト識別子（ＩＤ）フィールド、タイム・スタンプ（Ｔ）フィールドが変化しているかどうかを示すフラグ“Ｔ”により示されるタイム・スタンプ（Ｔ）フィールド及びシーケンス番号（ＳＮ）を含むようにしてもよい。残りのフィールドは図を明瞭にするために示されていない。
【００３５】
Ｔは、ＲＴＰタイムスタンプ・フィールドが（ＲＦＣ２５０８に記載されているような）予想値とは異なる値だけ変化したかどうかを示すために使用するビットとする。
【００３６】
圧縮ヘッダにおいて、デルタ・タイムスタンプ（ＲＴＰタイム・スタンプの１次差の符号化された値）＝シーケンス番号ｓｎを持つパケットｐｎに対応するＸｎ、かつ、Ｔ＝１とする。受信側端末３０の解凍装置３６からパケットｐｎが紛失したと仮定する。この紛失は、シーケンス番号ｓ（ｎ＋１）を持つ次のパケットｐ（ｎ＋１）が着信したとき、受信側端末３０の解凍装置３６により検知可能である。
【００３７】
ｐ（ｎ＋１）でＴ＝０の場合、受信側端末３０の解凍装置３６は、上記方法論に従って発信側端末２０の圧縮装置２６が配置したであろうデルタ・タイムスタンプ・フィールドをまだ探索している（前回のパケットが紛失したため）。デルタ・タイムスタンプ・フィールドはＸｎを含むことになる。解凍装置３６はｘ（ｎ＋１）からＸｎを取得する。
【００３８】
次に、図４Ｂに図示のように、Ｔ＝１の場合、受信側端末３０の解凍装置３６はデルタ・タイムスタンプ・フィールドの探索を求められる。しかし、当該フィールドに含まれる値がｘ（ｎ＋１）になるため、“ｆ（ｉ，ｊ）”関数が“アペンド”関数でない関数の場合、受信側端末３０の解凍装置３６はデルタ・タイムスタンプ（Ｘｎ）の実際の値を計算することはできない。ｆ（ｉ，ｊ）が“アペンド”関数でない関数の場合、受信側端末３０の解凍装置３６は追加パケット・タイムの間待機を余儀なくされる。“ｆ（ｉ，ｊ）”関数が単に２つの１次差を連結するにすぎない“アペンド”関数である場合、待機は本質的なことではないという点に留意されたい。
【００３９】
ｆ（ｉ，ｊ）が“アペンド”関数でない関数の場合であって、かつ、後続パケットｐ（ｎ＋２）の着信が成功したと仮定すると、受信側端末３０の解凍装置３６は（ｘ（ｎ＋１）とｘ（ｎ＋２）内の）共通入力ｘ（ｎ＋１）を復号化することができる。ｘ（ｎ＋１）が既知であるため、受信側端末３０の解凍装置３６はデルタ・タイムスタンプＸｎ並びにｘ（ｎ＋２）の計算を行うことも可能となる。図４Ｂに図示のように、フィールド情報の再構成が成功するまで、受信側端末３０の解凍装置３６は追加パケットの着信を待機しなければならない。この待機時間は、同様に、バースティなパケットの紛失が生じる場合と同じで（かつ一定）ある。
【００４０】
図５Ａ〜５Ｄは、図４Ａ〜４Ｂに図示の発信側端末２０の圧縮装置２６、及び、受信側端末３０の解凍装置３６の機能に従うデータ・パケットの様々なパケット・ヘッダ・フォーマットを例示する図である。これらのパケット・ヘッダ・フォーマットはｆ（ｉ，ｊ）が“アペンド”関数であると仮定して示されるものである。特に、図５Ａは２次（ＳＯ）差がゼロの場合のデータ・パケットのヘッダ・フォーマットを例示する図である。データ・パケット１００のヘッダ・セグメント１２０（図２Ａを参照）には、（ＲＦＣ２５０８に記載のものと同じであり、セルラ方式ネットワークなどのような或る種のネットワークでは暗黙のうちに了解され、オプションとする場合もある）コンテキスト識別子（ＩＤ）フィールドと、４ビット・シーケンス番号フィールドとを含めてもよい。図５Ａに示されるヘッダ・フォーマットは、２次（ＳＯ）差がゼロのとき、ＲＦＣ２５０８に記載の方法で発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ通常伝送される。
【００４１】
図５Ｂは、パケット“ｎ”の２次（ＳＯ）差がノンゼロ（ＮＯＮＪＥＮＤ）である場合のデータ・パケットのヘッダ・フォーマットを例示する図である。図５Ｂに図示のように、データ・パケット１００のヘッダ・セグメント１２０は、４ビット・コンテキスト識別子（ＩＤ）フィールドと、パケット“ｎ”の４ビット・シーケンス番号（ｎ）フィールドと、（ＲＴＰ圧縮ヘッダ、フル・ヘッダなどの）パケットタイプを特定する３ビット・パケットタイプ・フィールドと、伝送中の１次（ＦＯ）差がノンゼロの２次（ＳＯ）差を持つパケットについての差であるか、あるいは、該パケットの後続パケットについての差であるかを示す１ビット再転送（ＲｅＴＸ＝０）ビットと、変化したフィールドを特定する、ＲＦＣ２５０８に記載のような４ビットの組合せ（ＭＳＴＩ：マーカービット、シーケンス番号、タイム・スタンプ、ＩＰ−ＩＤ）フィールドと、ノンゼロの２次（ＳＯ）差を持つＲＴＰフィールドの１次（ＦＯ）差を含む可変長フィールドと、を含むものであってもよい。例えば、タイム・スタンプ（Ｔ＝１）が図４Ａに図示されているように変化したとき、図５Ｂに図示のようなヘッダ・フォーマットは、発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ伝送される。
【００４２】
図５Ｃは、図５Ｂに図示の、（パケット“ｎ＋１”などの）パケット“ｎ”に後続するパケット内の一次（ＦＯ）差を反復する際のヘッダ・フォーマットを例示する。図５Ｃに図示のように、データ・パケット１００のヘッダ・セグメント１２０は、コンテキスト識別子（ＩＤ）フィールドと、パケット“ｎ＋１”のシーケンス番号（ｎ＋１）フィールドと、（ＲＴＰ圧縮ヘッダ、フル・ヘッダなどの）パケットタイプを特定するパケットタイプ・フィールドと、伝送中の１次（ＦＯ）差がノンゼロの２次（ＳＯ）差を持つパケットについての差であるか、あるいは、該パケットの後続パケットについての差であるかを示す再転送（ＲｅＴＸ＝１）ビットと、変化したフィールドを特定するＲＦＣ２５０８に記載のようなＭＳＴＩフィールドと、パケット“ｎ”のシーケンス番号（ｎ）フィールドと、パケット“ｎ”のＲＴＰフィールドの１次（ＦＯ）差を示す可変長フィールドと、を含むものであってもよい。例えば、タイム・スタンプ（Ｔ＝０）が図４Ａと４Ｂに図示されているように変化しなかったとき、図５Ｂに図示のようなヘッダ・フォーマットは、次のパケット（ｎ＋１）または（ｎ＋２）との関連で、発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ伝送される。
【００４３】
図５Ｄは、パケット“ｎ”の１次（ＦＯ）差の通信中、パケット“ｎ＋ｋ”（または図４Ｂを参照して説明したように“ｎ＋１”）の２次（ＳＯ）差がノンゼロである場合のヘッダ・フォーマットを例示する図である（図５Ｂと５Ｃの組合せなど）。図５Ｄに図示のように、データ・パケット１００のヘッダ・セグメント１２０は、コンテキスト識別子（ＩＤ）フィールドと、パケット“ｎ＋ｋ”のシーケンス番号（ｎ＋ｋ）フィールド（または図４Ｂを参照して説明したように、パケット“ｎ＋１”の“ｎ＋１”フィールド）と、（ＲＴＰ圧縮ヘッダ、フル・ヘッダなどの）パケットタイプを特定するパケットタイプ・フィールドと、伝送中の１次（ＦＯ）差がノンゼロの２次（ＳＯ）差を持つパケット“ｎ＋ｋ”（または図４Ｂを参照して説明したように、“ｎ＋１”）についての差であること、あるいは、該パケットの後続パケットについての差であることを示す再転送（ＲｅＴＸ＝０）ビットと、変化したフィールドを特定するＲＦＣ２５０８に記載のような、ビット組合せ（ＭＳＴＩ）フィールドと、パケット（ｎ＋ｋ）（または図４Ｂを参照して説明したようにパケット“ｎ＋１”）についての１次（ＦＯ）差を示すフィールドと、パケット“ｎ”のシーケンス番号（ｎ）フィールドと、パケット“ｎ”のタイプを特定する別のパケットタイプ・フィールドと、ノンゼロの２次（ＳＯ）差を持つパケット“ｎ”のフィールドであることを示す再転送（ＲｘＴｘ＝１）ビットと、変化したフィールドを特定する、ＲＦＣ２５０８に記載されているような別のビット組合せ（ＭＳＴＩ）フィールドと、パケット（ｎ）の１次（ＦＯ）差を示すフィールドと、を含むものであってもよい。例えば、図４Ｂに図示のように、タイム・スタンプ（Ｔ＝１）が変化したとき、図５Ｄに図示のようなヘッダ・フォーマットは、次のパケット（ｎ＋１）と関連して発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ伝送される。
【００４４】
前述したように、図１に図示の発信側端末２０と受信側端末３０は単に例示のデータ・ネットワークとして設けられるものである。すべてのタイプのデータ・ネットワークで任意の数の端末装置、交換機、リンクから成る多種多様な実現例及び構成例が可能である。例えば、ヘッダ圧縮用として設けられたヘッダ圧縮メカニズムを含む、発信側端末と受信側端末から成るこのようなデータ・ネットワークの１つの推奨利用実現例として、図６に図示のようなボイス・オーバーＩＰとテレビ会議のようなリアルタイム・アプリケーション用セルラ方式ネットワークを挙げることもできよう。帯域限定リンク１０は、セルラ通信を行うための、ＩＰネットワーク１２とアクセス・ネットワーク・インフラ・ストラクチャＡＮＩ１４とＡＮＩ１６との組合せとすることも可能である。発信側端末２０は、ＲＴＰ／ＵＤＰ／ＩＰを実行し、ＩＰネットワーク１２及びＡＮＩ１４と１６を介する伝送用のパケット化された音声サンプルをＲＴＰパケットで供給するホストＰＣまたは同種のものであってもよい。受信側端末３０は、ＡＮＩ１４を備えたセルラ通信用の移動端末装置であってもよい。各端末２０と３０はＲＴＰパケット用の発信側端末か受信側端末のいずれかとすることができる。
【００４５】
端末２０には、（例えばＩＰアドレス、ポート番号などを含む）この端末をＲＴＰパケット用の発信元または宛先のいずれかとして特定するＲＴＰエンドポイント２２を含むことも可能である。ＩＰネットワークが例として示されているが、代わりに別のタイプのパケット交換方式ネットワークや同種のネットワークの利用も可能である。また端末２０には、タイム・スタンプ生成用ローカル・タイマ２４も含まれる。
【００４６】
アクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）１４をＩＰネットワーク１２と接続してもよい。無線周波数（ＲＦ）リンク５０を介して移動端末装置３０をＡＮＩ１４と結合してもよい。ＲＦリンク５０には（端末３０からＡＮＩ１４への）上り回線５２と（ＡＮＩ１４から端末３０への）下り回線５４とが含まれる。ＡＮＩ１４は、ある領域で、１以上の無線（すなわち無線周波数）端末（端末３０を含む）をＩＰネットワーク１２とインターフェースすることも可能である。これには（ＩＰネットワーク１２から出力される）有線信号と、（端末３０へまたは端末３０から出力される）無線すなわちＲＦ信号との間の変換が含まれる。したがって、ＩＰネットワーク１２から受信したＲＴＰパケットをＲＦリンク５０を介して移動端末装置３０へ伝送することがＡＮＩ１４により可能になり、さらに、ＩＰネットワーク１２を介して移動端末装置３０から端末２０などのような別の端へＲＴＰパケットの伝送を行うことが可能となる。
【００４７】
本発明の実施例によれば、ＡＮＩ１４には、各々がタイマ４２を含む１以上のＡＮＩアダプタ（ＡＮＩ＿ＡＤ）４０を含むことが望ましい。ＲＦＣ２５０８に類似したヘッダ圧縮処理を行うための、本発明の実施例に従うロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式であるが、図１〜４を参照して説明したように、紛失の多い、エラーし易いネットワークで使用する際、パケットの紛失やエラーの発生時にロバスト性を処理するＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式を用いて各ＡＮＩ＿ＡＤ４０が構成され、実現されて、ヘッダの正しい再構成を行うことが可能となる。ＡＮＩ＿ＡＤ４０は（下り回線の伝送に先行して）ヘッダ圧縮を実行し、次いで（上り回線の伝送後）解凍を実行することが可能である。ＩＰネットワーク１２から受信したＲＴＰパケット用ヘッダ（またはタイム・スタンプのような１以上のヘッダ・フィールド）は、下り回線５４を介する移動端末装置３０への伝送に先行してＡＮＩ＿ＡＤ４０により圧縮され、移動端末装置３０から受信したパケット・ヘッダはＩＰネットワーク１２への伝送前にＡＮＩ＿ＡＤ４０により解凍される。したがって、各ＡＮＩ＿ＡＤ４０はヘッダ圧縮装置／解凍装置と考えることもできる。また各ＡＮＩ＿ＡＤ４０は、ＩＰネットワーク１２とつながる領域の範囲内の特定のエリアまたは異なるエリア内に位置する端末をインターフェースすることも可能である。
【００４８】
ＡＮＩ＿ＡＤ４０は、タイマ・ベースの解凍手法を実現するためのタイマ４２を含むことも可能である。また、ＩＰネットワーク１２とつながる追加領域に位置する別の端末をインターフェースするために追加のＡＮＩを設けることも可能である。
【００４９】
移動端末装置３０は、ＲＴＰパケットの発信元及び／又は宛先（受信装置）であるＲＴＰエンドポイント１３２を含むことも可能である。移動端末装置３０は、（上り回線５２で伝送されるパケットに対する）ヘッダ圧縮、及び、（下り回線５４を介して受信されるパケットに対する）解凍を実行するターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）３６を含むことも可能である。したがって、ターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）は、ＡＮＩ＿ＡＤと類似のヘッダ圧縮装置／解凍装置と考えることもできる。
【００５０】
また、ターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）３６にはカレント・ヘッダのＲＴＰタイム・スタンプの近似値（または推定値）を計算するタイマ３４も含まれる。次いで、ターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）３６は、ＲＴＰヘッダ内の追加情報を利用してタイム・スタンプの近似値の微調整または補正を行う。ローカル・タイマ及び圧縮されたタイム・スタンプを利用して、各ＲＴＰヘッダの正しいタイム・スタンプの再生が可能となる。各々がそれ自身のＲＴＰエンドポイント、ターミナル・アダプタ及びタイマを含む別の端末を設けることも可能である。
【００５１】
上述のように、本発明は、信頼できないネットワークが存在する場合にロバストなＩＰヘッダ圧縮を達成するためのロバストなヘッダ圧縮方式を好適に提供するものである。この提案された方式は、パケット紛失に対して必要な所望の保護に基づいて弾力的に適用することも可能である。奇数ビットの保護（但しこの場合ペイロードに対してヘッダへの保護）を行う、例えば音声符号化時などに利用される手法と類似の手法を用いることによりビット誤りに対する保護を行うことも可能である。
【００５２】
本発明の推奨実施例と考えられるものを例示し、説明したが、様々な変更及び修正を行うことも可能であること、及び、本発明の真の範囲から逸脱することなく本発明の要素の代わりの均等物を用いることも可能であることを当業者は理解するであろう。さらに、多くの修正を行って、本発明の中心となる範囲から逸脱することなく、特定の状況を本発明の教示に適合させることも可能である。したがって、本発明の実行のために熟慮されたベストモードとして開示した特定の実施例に限定されるものではなく、本発明は添付の請求項の範囲に属するすべての実施例を含むものであることが意図される。
【図面の簡単な説明】
【図１】本発明の実施例に従う、帯域限定リンクを介してヘッダ圧縮及びデータ通信を行うために設けられたヘッダ圧縮メカニズムを含む、発信側端末と受信側端末とからなる例示データ・ネットワークを示す。
【図２Ａ】本発明の実施例に従う、例示データ・ネットワークで使用する例示データ・パケットを示す。
【図２Ｂ】本発明の実施例に従う、例示データ・ネットワークで使用する例示データ・パケットを示す。
【図３】本発明の実施例に従う、未圧縮フォーマットでのデータ・パケットの例示ＲＴＰヘッダ・セグメントを示す。
【図４Ａ】本発明の実施例に従う、変化するフィールドのための、発信側端末の圧縮装置と受信側端末の解凍装置の機能を例示する。
【図４Ｂ】本発明の実施例に従う、変化するフィールドのための、発信側端末の圧縮装置と受信側端末の解凍装置の機能を例示する。
【図５Ａ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図５Ｂ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図５Ｃ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図５Ｄ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図６】本発明の実施例に従う、ヘッダ圧縮用、並びに、セルラ・リンクを介するデータ通信用として設けられたヘッダ圧縮メカニズムを含む、発信側端末と受信側端末とからなるＩＰベースのネットワークの１つの推奨利用実現例を例示する。
【符号の説明】
１０  帯域限定リンク（ＩＰ）
２０  発信側端末
２２  ホスト
２４  ＮＩＣ
２６  圧縮装置／解凍装置
３０  受信側端末
３２  ホスト
３４  ＮＩＣ
３６  圧縮装置／解凍装置
【図１】
0003559019.tif 000002
【図２Ａ】
0003559019.tif 000003
【図２Ｂ】
0003559019.tif 000004
【図３】
0003559019.tif 000005
【図４Ａ】
0003559019.tif 000006
【図４Ｂ】
0003559019.tif 000007
【図５Ａ】
0003559019.tif 000008
【図５Ｂ】
0003559019.tif 000009
【図５Ｃ】
0003559019.tif 000010
【図５Ｄ】
0003559019.tif 000011
【図６】
0003559019.tif 000012