JP3559019B2 - 信頼できないネットワークが存在する場合にロバストなｉｐ／ｕｄｐ／ｒｔｐヘッダ圧縮を達成するシステム及び方法 - Google Patents
信頼できないネットワークが存在する場合にロバストなｉｐ／ｕｄｐ／ｒｔｐヘッダ圧縮を達成するシステム及び方法 Download PDFInfo
- Publication number
- JP3559019B2 JP3559019B2 JP2001550961A JP2001550961A JP3559019B2 JP 3559019 B2 JP3559019 B2 JP 3559019B2 JP 2001550961 A JP2001550961 A JP 2001550961A JP 2001550961 A JP2001550961 A JP 2001550961A JP 3559019 B2 JP3559019 B2 JP 3559019B2
- Authority
- JP
- Japan
- Prior art keywords
- packet
- header
- network
- difference
- field
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、データ・ネットワークにおけるデータの圧縮と解凍に関し、具体的には、信頼できないネットワークが存在する場合にロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮を達成するシステム及び方法に関する。
【０００２】
【従来の技術】
最近、インターネットの利用が増加した結果、ネットワーク容量の不足が生じて、従来のアプリケーションのパフォーマンスに対して否定的影響を与えるようになっている。同時に、テレビ会議やボイス・オーバーＩＰ（ＶｏＩＰ）を含む双方向型オーディオ及び／又はビデオなどの、タイムリなデータ配信並びにはるかに改善されたサービス品質が要求される新しいアプリケーションが現れてきた。テレビ会議やボイス・オーバーＩＰ（ＶｏＩＰ）のような、様々なタイプのネットワーク用リアルタイム・アプリケーション間でのインターオペラビリティ（相互運用性）を得るためにリアルタイム転送プロトコル（ＲＴＰ）が利用されてきた。インターネット・プロトコル（ＩＰ）ベースのリアルタイム・マルチメディア用として、ユーザ・データグラム・プロトコル（ＵＤＰ／ＩＰ）の上位でＲＴＰを使用して、“ＲＴＰ：リアルタイム・アプリケーション用トランスポート・プロトコル”（Ｈｅｎｎｉｎｇ Ｓｃｈｕｌｚｒｉｎｎｅ， Ｓｔｅｐｈｅｎ Ｌ． Ｃａｓｎｅｒ， Ｒｏｎ Ｆｒｅｄｅｒｉｃｋ， ａｎｄ Ｖａｎ Ｊａｃｏｂｓｏｎ共著、インターネットの技術標準文書（ＲＦＣ）１８８９年、１９９６年１月）に記述されているような多重化及びチェックサム・サービスの利用が可能である。しかし、ダイアルアップ・モデムのような低速回線を介して伝送を行う場合、容認できる双方向型の応答と回線効率にとってＲＴＰヘッダが大きくなりすぎるかもしれないという懸念がある。例えば、インターネット・プロトコル・バージョン４（ＩＰｖ４）では、ＩＰ／ＵＤＰ／ＲＴＰを含むヘッダ・フィールドは、パケット当たり４０バイトを占めることができる。同様に、インターネット・プロトコル・バージョン６（ＩＰｖ６）では、このようなヘッダ・フィールドはパケット当たり６０バイトを占めることができる。音声ペイロードを（２０ｍｓのＧＳＭ符号化音声に対応する）３６バイトほどの小さなものとすることも可能な通話用音声のようなリアルタイム・アプリケーションでは、このヘッダ・オーバーヘッドはきわめて大きなものである。従って、リアルタイム・アプリケーションではこのようなヘッダ・オーバーヘッドを大幅に減らす必要がある。
【０００３】
現在、ヘッダ・オーバーヘッドを低減して、低速及び中速リンクでの帯域の効率的な利用を可能にするための、ＩＰ／ＵＤＰ／ＲＴＰデータグラムのヘッダ圧縮に利用可能なヘッダ圧縮手法はほとんどが存在しない。このようなヘッダ圧縮手法の最も最近の例が、“低速シリアルリンク用ＩＰ／ＵＤＰ／ＲＴＰヘッダの圧縮”（Ｓｔｅｐｈｅｎ Ｌ． Ｃａｓｎｅｒ及びＶａｎ Ｊａｃｏｂｓｏｎ、ＲＦＣ２５０８、１９９９年２月）に記載されている。ＩＰ／ＵＤＰ／ＲＴＰデータグラムのヘッダを圧縮して、２〜４バイトまでヘッダ・オーバーヘッドを低減する圧縮／解凍装置を備えたヘッダ圧縮メカニズムが提供されている。このヘッダ圧縮方式は、ＩＰヘッダのほとんどのフィールドが、接続寿命（すなわちセッションの長さ）の間パケット・ストリームの中で一定のままであるという観察に基づくものである。したがって、解凍装置で圧縮状態を保持することにより、また、（エラー検出及びパケット紛失検出用として使用するセッション・コンテキスト識別子と小さなシーケンス番号のような）最低量のヘッダ・オーバーヘッドを圧縮装置から解凍装置へ単にトランスポートすることにより、ヘッダ圧縮を達成することも可能である。ＲＦＣ２５０８によれば、解凍装置での圧縮状態は、すべてのパケットで変化するフィールド、及び、すべてのパケットで変化しないフィールドを含む未圧縮のヘッダ・フィールドに対応するようにしてもよい。（発信元と宛先のＩＰアドレス及びポート番号のような）変化しないフィールドの場合、解凍装置は、圧縮状態で保存されている対応フィールドを単に加算するだけでよい。しかし、変化するフィールドの場合、解凍装置は、圧縮パケット・ヘッダで送られる情報に依拠することができる。典型的には、圧縮パケット・ヘッダの中に内包される情報は、前回のパケット内のフィールドの値（すなわち変化するフィールドのノンゼロの２次差のみに関する変化の差）を含み、変化したフィールド自身を含むものではない。
【０００４】
一般的処理を行うために、変化しないフィールドのコンテキスト状態及び変化するフィールドの１次差が解凍装置により確立されるまで完全なＩＰ／ＵＤＰ／ＲＴＰヘッダを解凍装置へ伝送することにより圧縮装置は始動する。いったんコンテキスト状態が確立されると、２次差（デルタ）がノンゼロである限り、圧縮装置は差（特に、ＲＴＰタイム・スタンプやＲＴＰシーケンス番号などのようなＲＴＰヘッダ・フィールドに対応する差）を伝送する必要はなくなる。パケットからパケットへのＲＴＰヘッダの２次差（デルタ）がゼロである場合、解凍装置は、各圧縮パケットが受信されたとき、前回のパケットを表す保存されている未圧縮ヘッダに１次差を単純に加算することにより、情報ロスのないパケットの再構成（復元）が可能となる。通信の必要があるのはただ、圧縮装置と解凍装置との間のパケット紛失を検出するためのセッション・コンテキスト識別子（ＩＤ）と小さなシーケンス番号（ＲＴＰシーケンス番号とは関連しない）だけである。例えば、パケット＃１、＃２、＃３のＲＴＰタイム・スタンプが、２０から４０、６０へと変化する場合、２０と４０及び４０と６０との間の１次差は２０である。初期値２０が既知である場合、２次差がゼロであることが圧縮ヘッダ内の適切なフィールドによって示されていれば、解凍装置はパケット＃３の正しい増分値を単に加算するだけでよい。
【０００５】
一方、いくつかのフィールドのＲＴＰヘッダの２次差（デルタ）がゼロでない場合、コンパクトな符号化を用いてそれらのフィールドだけの新しい１次差を通信しなければならない。これらの新しい１次差の値は、解凍装置のセッション・コンテキスト内の未圧縮ヘッダ内の対応フィールドに加算され、次いで、セッション・コンテキストの中にはっきりと保存されて、２次差（デルタ）がゼロである各後続パケット内の対応フィールドに再び加算される。後続パケット内で１次差が変化する度にその差が伝送され、セッション・コンテキストの更新に利用される。
【０００６】
しかし、インターネット共同体に利用可能なインターネット用の規格プロトコルが含まれるＲＦＣ２５０８及びその他のＲＦＣ文書に記載されているようなヘッダ圧縮方式は、帯域が不足し、多くのリンク・エラーや長いリンク待ち時間が生じる（セルラ無線ネットワークのような）環境での処理には適していない。パケットの紛失に起因して、解凍装置が、ＲＴＰタイム・スタンプやＲＴＰシーケンス番号のような間違ったヘッダ情報を受信に成功した次のパケットに加算する可能性がある。同様に、圧縮パケット・ヘッダがエラーになった場合、ＲＴＰパケットの同様の間違った再構成が結果として生じる可能性がある。例えば、１フィールド（または複数のフィールド）の新しい１次差を含むパケットが（おそらくエラーに起因して）紛失したと考えられる場合、解凍装置が圧縮装置に通知するか、必要な１次差の再送に圧縮装置が成功するまで後続パケット用ヘッダの正しい再構成はできなくなる。この回復段階中、ヘッダの再構成を行うために伝送済みパケットと伝送中パケットの処理を行うことはできない。ボイス・オーバーＩＰ（ＶｏＩＰ）やテレビ会議のようなリアルタイム・アプリケーションの場合、プレイアウト・デッドライン（ｐｌａｙ−ｏｕｔ ｄｅａｄｌｉｎｅ）の期限切れに起因してこれらのパケットは破棄される可能性がある。例えば、（基地局のような）無線アクセス・ポイントから移動機への１方向遅延（または基地局から移動機へ、次いで基地局へもどる１２０ｍｓのラウンド・トリップ遅延）の６０ｍｓを持つセルラ・リンク、及び、トーク・スパート（ｔａｌｋｓｐｕｒｔ）中の２０ｍｓの音声パケット間でのパケット間（ｉｎｔｅｒ−ｐａｃｋｅｔ）分離について考えてみよう。トーク・スパートの開始時に、一番最初のパケットのＲＴＰタイム・スタンプは、無音間隔に起因してその２次差がノンゼロとなるように増分する。したがって、この一番最初のパケットで解凍装置へ新しい１次差を通信しなければならない。パケットがエラーに起因してなぜか紛失した場合、解凍装置が故障に関する情報を圧縮装置に与えるまで、次の３個のパケット（６０ｍｓ／２０ｍｓ）の再構成を行うことはできない。この故障時間中、（トーク・スパートが少なくとも６個のパケットで持続すると仮定した場合）別のさらに３個のパケットが圧縮装置により伝送されたであろう。解凍装置によって正しい１次差が受信されるまでこれら６個のパケットはすべて待機する必要があり、その結果、プレイアウト・デッドラインの期限切れのために破棄される可能性がある。
【０００７】
したがって、信頼できないネットワークが存在する際のロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式に対する要望が存在する。さらに、ヘッダ・パケットの紛失やエラーの発生時に正しく再構成を行うことが可能な方式が必要とされている。
【０００８】
【発明が解決しようとする課題】
したがって、本発明の様々な実施例は、パケットの紛失やエラーの発生時に、ＩＰ／ＵＤＰ／ＲＴＰヘッダの正しい再構成が可能なロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮メカニズムと手法を目的とするものである。このヘッダ圧縮メカニズムには、ＲＦＣ２５０８に類似して処理を行うように実現される圧縮／解凍装置であって、紛失が多く、エラーし易いネットワークで使用される場合、ロバスト性を処理できるように特別に設計された圧縮／解凍装置が含まれ、パケットの紛失やエラーの発生時にヘッダの正しい再構成が可能となる。
【０００９】
【課題を解決するための手段】
本発明の１つの態様によれば、上記ロバストなヘッダ圧縮方式の要件として、フィールドの２次差がノンゼロである場合、ノンゼロの２次差を持つ或る特定のＲＴＰパケットを新しい１次差と共に伝送することが求められるだけでなく、（ａ）ある時間が、チャンネル特性（リンク・ラウンド・トリップ時間ＲＴＰ／パケット間分離など）のような係数により予め定められているか、（ｂ）新しい１次差が正しく受信された旨の肯定の確認が圧縮装置により受信される限り、その新しい１次差と共に後続パケットを伝送することが求められる。その結果、後続パケットの“自制”が保証され、たとえ２次差をノンゼロとなるようにしたパケットが紛失しても、解凍装置は該後続のパケットのヘッダの正しい再構成を行うことが可能となる。
【００１０】
本発明の別の態様によれば、ロバストなヘッダ圧縮方式の要件として、対応するＲＴＰフィールドが１次差の通信時間中ノンゼロの２次差と共に再び変化した場合、これら２つの１次差を高い信頼性で通信する単純な手段としてこれら２つの１次差をまとめて後ろに付加することができるように“新しい”１次差は元の１次差と組み合わされる。しかし、本発明は効率を図る目的で１次差を組み合わせる別の手段を除外するものではない。
【００１１】
【発明の実施の形態】
単に例として添付されている図面を参照しながら以下のパラグラフで本発明についてさらに具体的に説明する。
【００１２】
本発明のさらに完全な理解、及び、本発明の付随する利点の多くは、添付図面と関連して考察し、以下の詳細な記述を参照して同発明をより良く理解したとき容易に明らかになる。上記添付図面では同じ参照記号により、同じまたは類似の構成要素が示されている。
【００１３】
本発明は、すべてのタイプのデータ・ネットワークとリアルタイム通信サービスと共に使用するために適用可能である。例えば、データ・ネットワークは、ボイス・オーバーＩＰ（ＶｏＩＰ）やテレビ会議（ビデオ・オーバーＩＰ）のようなリアルタイム・アプリケーション用として利用される、イーサネット・ローカル・エリア・ネットワーク（ＬＡＮ）、非同期転送モード（ＡＴＭ）、フレーム・リレー及びインターネットを含むパケット・ネットワークであってもよい。上記とは別に、このようなデータ・ネットワークは、旧来の電話サービス（ＰＯＴＳ）、公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）、移動通信ネットワーク、衛星ネットワーク、及び、地上デジタルＴＶや無線、セルラ、短距離用無線（ブルートゥース、ＲＦプロトコル、無線ＬＡＮ）ネットワークなどのネットワークを含む私設ネットワークまたは公衆ネットワークであってもよい。しかし、説明を単純にするために、本解説では、ボイス・オーバーＩＰ（ＶｏＩＰ）やテレビ会議（ビデオ・オーバーＩＰ）のようなリアルタイム・アプリケーションのための様々な構成から成る単純なデータ・ネットワークが主として中心となる。但し、本発明の範囲と実現はこのようなデータ・ネットワークに限定されるものではない。
【００１４】
図面、特に、図１の発信側端末２０と受信側端末３０からなる、本発明の実施例に従う単純なデータ・ネットワークに注意されたい。図１に図示のように、帯域限定リンク１０を利用して発信側端末２０を受信側端末３０と接続するようにすることも可能である。帯域限定リンク１０はダイアルアップ・モデムまたは高周波（ＲＦ）無線リンク（セルラ・リンク）などの低速回線を表すものであってもよい。上記とは別に、帯域限定リンク１０は、インターネット・サービス・プロバイダ（ＩＳＰ）のＩＰベースのネットワーク、インターネット、例えば、公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）及び発信側端末２０と受信側端末３０との間の通信を可能にするその他のアクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）などを含む様々な発信側ネットワーク及び着信側ネットワークを含むものであってもよい。帯域限定リンク１０がセルラ・リンクに対応する場合、発信側端末２０及び受信側端末３０は移動端末装置と基地局にそれぞれ対応するようにすることも可能であり、また、その逆も可能である。
【００１５】
発信側端末２０には、例えば、少なくともホスト２２とネットワーク・インターフェース・コントローラ（ＮＩＣ）２４とが含まれる。同様に、受信側端末３０には、例えば、少なくともホスト３２とネットワーク・インターフェース・コントローラ（ＮＩＣ）３４とが含まれる。複数のホストが発信側端末２０と受信側端末３０に含まれるようにしてもよい。各ホストは、帯域限定リンク１０を介して発信側端末２０から受信側端末３０へデータ・パケットを伝送するＩＰ電話やスタンド・アローン型ＰＣに対応するようにしもよい。
【００１６】
発信側端末２０では、ホスト２２は、ネットワーク・インターフェース・コントローラ（ＮＩＣ）２４へ転送するデータを生成する。発信側端末２０のＮＩＣ２４は、例えば、ユーザ・データグラム・プロトコル（ＵＤＰ／ＩＰ）の上位で用いられるリアルタイム転送プロトコル（ＲＴＰ）を利用してホスト２２からの着信データをデータ・パケットに変換し、帯域限定リンク１０を介してこれらのデータ・パケットを注入する。帯域限定リンク１０がＩＰベースのネットワークである場合、そのデータ・パケットのレートはＩＰベースのネットワーク１０を介して注入されて、外へ向かうデータ・フローパケットの制御と管理がＮＩＣ２４により行われ、ＩＰベースのネットワーク１０における輻輳状態の回避及びデータ・パケット帯域の使用の限定が図られる。ＩＰベースのネットワーク１０は着信データ・パケットを受け取り、次いで、ヘッダに含まれる情報に従って受信側端末３０へ同着信データ・パケットを転送する。受信側端末３０のＮＩＣ３４は、ＩＰベースのネットワーク１０からこれらのデータ・パケットを受け取り、同データ・パケットをデータに変換し、次いでホスト３２へ該データの転送を行う。
【００１７】
図２Ａ〜２Ｂは本発明の実施例に従う単純なデータ・ネットワークで利用する例示データ・パケットを示すものである。図２Ａに図示のように、例示データ・パケット１００は、データ・ペイロード１３０のセグメントと、データ・ペイロード１３０の前に付加される小さなヘッダ１２０とから構成される。パケット１００は、ボイス・オーバーＩＰ（ＶｏＩＰ）またはビデオ・オーバーＩＰのリアルタイム・トラフィックを表すものであってもよいが、これに限定されるものではない。例えば、ヘッダ・セグメント１２０には、ＩＰアドレス・フィールド（一般にネットワークＩＤとホストＩＤとから成る３２ビット・グローバル・インターネット・アドレス）と、ＩＰのどのバージョンがＩＰパケットの中に表されているか（例えばＩＰバージョン４及びＩＰバージョン６など）を指定するために使用されるバージョン・フィールドと、様々なサービス品質を提供するＩＰベースのネットワークでのＩＰパケットの処理方法を指定するために使用されるサービス・フィールドのタイプと、伝送エラーの検証に使用されるヘッダ・チェックサム・フィールドとが含まれる。フラグとフラグメント・オフセット・フィールド、合計長フィールド、ＩＤフィールド、ＴＴＬ（ｔｉｍｅ ｔｏ ｌｉｖｅ）フィールドと、プロトコル・フィールドなどのその他のＩＰフィールドをこのようなヘッダの中に含めてもよい。インターネット・プロトコル・バージョン４（ＩＰｖ４）では、ＩＰ／ＵＤＰ／ＲＴＰを含むヘッダ・フィールドはパケット当たり４０バイト、また、インターネット・プロトコル・バージョン６（ＩＰｖ６）の場合には、パケット当たり６０バイトを占めることが可能である。ヘッダ・オーバーヘッドは、データ・ペイロードに比べて一般に相当の大きさになり、特に、実際の音声ペイロードが３６バイト（２０ｍｓのＧＳＭ符号化音声に対応する）ほどの小さなものである場合もある通話用音声のような、ユーザ・データグラム・プロトコル（ＵＤＰ／ＩＰ）の上位で使用されるリアルタイム転送プロトコル（ＲＴＰ）が用いられるリアルタイム・アプリケーションの場合には、ヘッダ・オーバーヘッドは相当の大きさのものになる。
【００１８】
図２Ｂは、ＩＰヘッダ１２２と、ＵＤＰヘッダ１２４と、ＲＴＰヘッダ１２６、及び、例えば、図２Ａに図示の音声サンプルなどを含むデータ・ペイロード１３０の組合せを含む例示ヘッダ・セグメント１２０を示す。
【００１９】
図３は、本発明の実施例に従う、未圧縮フォーマットの例示ＲＴＰヘッダ１２６を示す。図３に図示のように、未圧縮のＲＴＰヘッダ１２６にはタイム・スタンプ（Ｔ）３１０と、シーケンス番号（ＳＮ）３１２と、その他のフィールド３１４とが含まれる。ＩＰネットワークのパケット交換型の性質（図１を参照）に起因して、ＲＴＰパケットが間違った順序で着信する場合がある。受信側端末３０でシーケンス番号３１２を使用して、ＲＴＰ音声サンプルを正しい順序に組み立てることも可能である。しかし、ＲＴＰパケット内のシーケンス番号は、フィールドのいずれの非線形変化（音声信号の無音間隔）も反映しない場合がある。したがって、タイム・スタンプ（Ｔ）３１０を設けて各パケットの相対的タイミングを示すようにしてもよい。
【００２０】
前述したように、各ＲＴＰパケット内のＩＰ／ＵＤＰ／ＲＴＰヘッダにより供給される４０〜６０バイトのヘッダ・オーバーヘッドが大きすぎる場合もある。特に、ＲＴＰタイム・スタンプがあまりに大きな負担となるためダイアルアップ・モデムや帯域限定リンクなどのような低速回線を介してＲＴＰパケットがトランスポートを行うことができなくなる場合もある。したがって、図１に図示のデータ・ネットワークの発信側端末２０のＮＩＣ２４の中には（またエンド・ツー・エンド・ベースの双方向通信用受信側端末２０のＮＩＣ３４の中にも）、一般に、発信側端末２０と受信側端末３０においてヘッダ圧縮を行うヘッダ圧縮メカニズム２６と３６が含まれる。上記メカニズムは、ダイアルアップ・モデムまたは帯域限定リンクなどのような低速回線を介する作動時に、容認できる双方向型の応答と回線効率のためにヘッダのオーバーヘッドの低減を図るものである。ヘッダ圧縮メカニズム２６と３６に、ＩＰ／ＵＤＰ／ＲＴＰデータグラムのヘッダを圧縮する圧縮／解凍装置を設けて、２〜４バイトまでヘッダ・オーバーヘッドを低減するようにしてもよい。ＣやＣ＋＋のような高水準プログラム言語と汎用コンピュータを用いて標準的プログラミング方法により構成されるハードウェア及び／又はソフトウェアによりヘッダ圧縮メカニズム２６と３６を実現して、ヘッダ圧縮を達成するようにしてもよい。ソフトウェア・モジュールによりヘッダ圧縮メカニズム２６と３６を実現する場合、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの半導体記憶装置、フラッシュメモリ・デバイス、磁気ディスク（固定ディスク、フロッピー・ディスク、リムーバブル）、テープなどのその他の磁気媒体及びＣＤ−ＲＯＭディスクなどのような光媒体を含む有形の媒体（但しこれらに限定されるものではない）上にこのようなソフトウェア・モジュールを設けることも可能である。ホストのネットワーク・インターフェース・カードと共にこのようなソフトウェア・モジュールをバンドルしてもよい。上記とは別に、ヘッダ圧縮メカニズム２６と３６は、ファームウェア・モジュールまたはホストに組み込みが可能な包括的なハードウェア／ソフトウェア・モジュールとして利用できるものであってもよい。さらに、ヘッダ圧縮メカニズム２６と３６とは、ＲＦＣ２５０８に類似の機能を行うために実現可能であるが、セルラ無線ネットワークのような多くのリンク・エラーや長いリンク待ち時間が生じることを特徴とする、紛失が多く、エラーし易いネットワーク環境で使用される場合、アドレスのロバスト性を処理できるように特別に設計されて、パケットの紛失やエラーの発生時にヘッダの正しい再構成が図られるようになっている。
【００２１】
図１に図示の発信側端末と受信側端末及びリンクの具体的な数と構成は、帯域が不足し、エラーが稀ではない場合もあるデータ・リンクを介してデータ・パケットのヘッダ圧縮と伝送を行うヘッダ圧縮方式が利用される例示データ・ネットワークとして単に示されているものにすぎない。すべてのタイプのデータ・ネットワークにおいてどのような数の端末装置、交換機、リンクから成る多種多様な実現例と構成例が可能である。
【００２２】
ヘッダ圧縮処理を行うために、ＲＦＣ２５０８に記載されている方法と同じ方法で、変化しないフィールドのコンテキスト状態並びに変化するフィールドの１次差が解凍装置３６により確立されるまで、受信側端末３０の解凍装置３６へ完全なＩＰ／ＵＤＰ／ＲＴＰヘッダを伝送することにより発信側端末２０の圧縮装置２６は始動する。すなわち、コンテキスト状態が確立されると、２次差（デルタ）がノンゼロでない場合、発信側端末２０の圧縮装置２６は、１次差（特に、例えば、ＲＴＰタイム・スタンプとＲＴＰシーケンス番号などのようなＲＴＰヘッダ・フィールドに対応する差）を伝送する必要はなくなる。パケットからパケットへのＲＴＰヘッダ（またはデータ・パケットのＩＰ／ＵＤＰヘッダ）の２次差（デルタ）がゼロである場合、各圧縮パケットが受信されたとき、受信側端末３０の解凍装置３６は、前回のパケットを表す保存された未圧縮ヘッダに１次差を単に加算するだけで、情報の紛失が皆無のパケットの再構成が可能となる。
【００２３】
いずれかのフィールドのＲＴＰヘッダの２次差（デルタ）がノンゼロである場合、発信側端末２０の圧縮装置２６は、ＲＦＣ２５０８に記載の方法で、対応フィールドの新しい１次差を伝送するように機能する。しかし、ＲＦＣ２５０８に加えて、（帯域が不足し、多くのリンク・エラーと長いリンク待ち時間が生じる可能性があるセルラ・ネットワークまたは無線ネットワークのような）紛失が多く、エラーし易い、信頼できないネットワークで使用する場合、ヘッダ圧縮メカニズム２６と３６がロバスト性を処理できるように特別に設計され、実現されて、パケットの紛失やエラーの発生時にヘッダの正しい再構成が行われる。
【００２４】
一般に、本発明のヘッダ圧縮方式の要件として、フィールドの２次差がノンゼロである場合、ノンゼロの２次差を持つ或る特定のＲＴＰパケットを発信側端末２０の圧縮装置２６から新しい１次差と共に伝送することが求められるだけでなく、（ａ）ある時間が、チャンネル特性（リンク・ラウンド・トリップ時間ＲＴＰ／パケット間分離など；ラウンド・トリップ時間ＲＴＴとは、データ・パケットまたはフレームが発信側端末２０から受信側端末３０までどれだけの長さを進むかを示す推定値である）のような係数によって予め定められているか、（ｂ）新しい１次差が正しく受信された旨の肯定の確認が発信側端末２０の圧縮装置２６により受信される限り、その新しい１次差と共に後続パケットの伝送も求められる。上記要件によって、後続パケットの“自制”が保証され、たとえ２次差をノンゼロとなるようにしたパケットが紛失しても、受信側端末３０の解凍装置３６による該後続パケットのヘッダの正しい再構成を行うことが可能となる。
【００２５】
本発明の別の態様によれば、対応するＲＴＰフィールドが１次差の通信時間中ノンゼロの２次差と共に再び変化した場合、これら２つの１次差を高い信頼性で通信する単純な手段としてこれら２つの１次差をまとめて後ろに付加することができるように“新しい”１次差は元の１次差と組み合わされる。しかし、本発明は効率を図る目的で１次差を組み合わせる別の手段を除外するものではない。
【００２６】
ここで図４Ａ〜４Ｂを参照しながら、変化するフィールドのための、発信側端末２０の圧縮装置２６及び受信側端末３０の解凍装置３６の機能、及び、パケットの紛失やエラーの発生時にヘッダを正しく再構成できる方法の諸例について以下本明細書で説明する。
【００２７】
単一の変化するフィールドの場合、ｘｎを発信側端末２０の圧縮装置２６が伝送しなければならないフィールドｇｎの１次差符号値（すなわち１次差の符号化された値）とする。なぜなら、該符号値は、パケットｐｎの中で通常の予想値とは異なる量だけ変化し、受信側端末３０の解凍装置３６による受信に成功しなかったからである。
【００２８】
Ｘｎ＝ｘ（ｎ−１）＊ｆ（ｎ−１，ｎ）＊Ｘｎかつｘ（ｎ＋１）＝Ｘｎ＊ｆ（ｎ，ｎ＋１）＊ｘ（ｎ＋１）と定義する。但し、ｆ（ｉ，ｊ）は、Ｘｎとｘ（ｎ＋１）とからＸｎ（共通入力）を計算し、所定のＸｎとＸｎ、ｘ（ｎ−１）の一意的計算を可能にするものである。さらに、ｆ（ｉ，ｊ）は、入力ｘｎまたはｘ（ｎ−１）のうちのいずれか一方がゼロの場合、Ｘｎ＝ノンゼロ入力を設定するようにするものである。
【００２９】
ｆ（ｉ，ｊ）の最も単純な形は、“アペンド（ａｐｐｅｎｄ）”関数であり、これは存在するフィールドに単に冗長性をつけ加えるだけの関数である。例えば、上記のＸｎはｘ（ｎ−１）とｘｎの双方から構成されるものであってもよい。さらに優れた関数を利用してもよい。しかし、関数の複雑さとＸｎを表すために必要とされるビットの減少との間でトレードオフが行われる。
【００３０】
発信側端末２０の圧縮装置２６は、たとえ対応フィールドｇ（ｎ＋１）が予想量とは異なる量しか変化しない場合であっても（この場合ｘ（ｎ＋１）はゼロになる）、パケットｐｎに対応するＸｎと、ｐ（ｎ＋１）に対応するｘ（ｎ＋１）の計算を行うことが可能である。発信側端末２０の圧縮装置２６は、ｘｎの代わりにｐｎでＸｎを伝送し、ｘ（ｎ＋１）の代わりにｐ（ｎ＋１）でＸ（ｎ＋１）を伝送する。
【００３１】
パケットｐｎが紛失し、ｐ（ｎ＋１）とｐ（ｎ＋２）とが受信された場合、ｘ（ｎ＋１）の計算が可能となり、Ｘ（ｎ＋１）が既知となるためＸｎの計算も可能となる。したがって、パケットｐｎの紛失がヘッダの正しい再構成に影響を与えることはない。その結果、単一パケットの紛失に対する保護を行うことが可能となる。
【００３２】
ｆ（ｉ，ｊ）が“アペンド”関数以外の場合、Ｘｎの計算をＸｎとｘ（ｎ−１）だけに限定する必要はない。ｘｎは上記すべてのｘｉの関数とすることができる。但し、対応する関数ｆ（ｉ，ｉ−ｊ）が存在する限り、任意のｉ−ｊの値についてｉ＝ｉ，ｉ−１，ｉ−２，．．．ｉ−ｊである。任意の２つのＸｉとＸ（ｉ＋１）から、共通入力ｘｉ、ｘ（ｉ−１）、ｘ（ｉ−２）、．．．、ｘ（ｉ−ｊ）をｘｉとｘ（ｉ＋１）から別個に計算することができる。このような場合、フィールドの変化が生じたとき、パケット紛失のバーストに対する保護を目的として、発信側端末２０の圧縮装置２６はｘ（ｉ−ｊ）までｘｉ値を計算しなければならない。
【００３３】
ｆ（ｉ，ｊ）が“アペンド”関数であるとき、本発明の１つの態様として記述される要件により、バースト・パケット紛失に対する保護が行われる。すなわち、フィールドの２次差がノンゼロである場合、ノンゼロの２次差を持つ或る特定のＲＴＰパケットを新しい１次差と共に伝送することが求められるだけでなく、（ａ）ある時間が、チャンネル特性（リンク・ラウンド・トリップ時間ＲＴＰ／パケット間分離など）のような係数によって予め定められているか、（ｂ）新しい１次差が正しく受信された旨の肯定の確認が圧縮装置により受信される限り、上記新しい１次差と共に後続パケットの伝送も求められる。
【００３４】
図４Ａ〜４Ｂに図示のように、変化するフィールドのための、発信側端末２０の圧縮装置２６及び受信側端末３０の解凍装置３６のについて以下説明する。図４Ａでは、本発明の実施例に従う、圧縮フォーマットでの例示ＲＴＰパケット１００の中に、コンテキスト識別子（ＩＤ）フィールド、タイム・スタンプ（Ｔ）フィールドが変化しているかどうかを示すフラグ“Ｔ”により示されるタイム・スタンプ（Ｔ）フィールド及びシーケンス番号（ＳＮ）を含むようにしてもよい。残りのフィールドは図を明瞭にするために示されていない。
【００３５】
Ｔは、ＲＴＰタイムスタンプ・フィールドが（ＲＦＣ２５０８に記載されているような）予想値とは異なる値だけ変化したかどうかを示すために使用するビットとする。
【００３６】
圧縮ヘッダにおいて、デルタ・タイムスタンプ（ＲＴＰタイム・スタンプの１次差の符号化された値）＝シーケンス番号ｓｎを持つパケットｐｎに対応するＸｎ、かつ、Ｔ＝１とする。受信側端末３０の解凍装置３６からパケットｐｎが紛失したと仮定する。この紛失は、シーケンス番号ｓ（ｎ＋１）を持つ次のパケットｐ（ｎ＋１）が着信したとき、受信側端末３０の解凍装置３６により検知可能である。
【００３７】
ｐ（ｎ＋１）でＴ＝０の場合、受信側端末３０の解凍装置３６は、上記方法論に従って発信側端末２０の圧縮装置２６が配置したであろうデルタ・タイムスタンプ・フィールドをまだ探索している（前回のパケットが紛失したため）。デルタ・タイムスタンプ・フィールドはＸｎを含むことになる。解凍装置３６はｘ（ｎ＋１）からＸｎを取得する。
【００３８】
次に、図４Ｂに図示のように、Ｔ＝１の場合、受信側端末３０の解凍装置３６はデルタ・タイムスタンプ・フィールドの探索を求められる。しかし、当該フィールドに含まれる値がｘ（ｎ＋１）になるため、“ｆ（ｉ，ｊ）”関数が“アペンド”関数でない関数の場合、受信側端末３０の解凍装置３６はデルタ・タイムスタンプ（Ｘｎ）の実際の値を計算することはできない。ｆ（ｉ，ｊ）が“アペンド”関数でない関数の場合、受信側端末３０の解凍装置３６は追加パケット・タイムの間待機を余儀なくされる。“ｆ（ｉ，ｊ）”関数が単に２つの１次差を連結するにすぎない“アペンド”関数である場合、待機は本質的なことではないという点に留意されたい。
【００３９】
ｆ（ｉ，ｊ）が“アペンド”関数でない関数の場合であって、かつ、後続パケットｐ（ｎ＋２）の着信が成功したと仮定すると、受信側端末３０の解凍装置３６は（ｘ（ｎ＋１）とｘ（ｎ＋２）内の）共通入力ｘ（ｎ＋１）を復号化することができる。ｘ（ｎ＋１）が既知であるため、受信側端末３０の解凍装置３６はデルタ・タイムスタンプＸｎ並びにｘ（ｎ＋２）の計算を行うことも可能となる。図４Ｂに図示のように、フィールド情報の再構成が成功するまで、受信側端末３０の解凍装置３６は追加パケットの着信を待機しなければならない。この待機時間は、同様に、バースティなパケットの紛失が生じる場合と同じで（かつ一定）ある。
【００４０】
図５Ａ〜５Ｄは、図４Ａ〜４Ｂに図示の発信側端末２０の圧縮装置２６、及び、受信側端末３０の解凍装置３６の機能に従うデータ・パケットの様々なパケット・ヘッダ・フォーマットを例示する図である。これらのパケット・ヘッダ・フォーマットはｆ（ｉ，ｊ）が“アペンド”関数であると仮定して示されるものである。特に、図５Ａは２次（ＳＯ）差がゼロの場合のデータ・パケットのヘッダ・フォーマットを例示する図である。データ・パケット１００のヘッダ・セグメント１２０（図２Ａを参照）には、（ＲＦＣ２５０８に記載のものと同じであり、セルラ方式ネットワークなどのような或る種のネットワークでは暗黙のうちに了解され、オプションとする場合もある）コンテキスト識別子（ＩＤ）フィールドと、４ビット・シーケンス番号フィールドとを含めてもよい。図５Ａに示されるヘッダ・フォーマットは、２次（ＳＯ）差がゼロのとき、ＲＦＣ２５０８に記載の方法で発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ通常伝送される。
【００４１】
図５Ｂは、パケット“ｎ”の２次（ＳＯ）差がノンゼロ（ＮＯＮＪＥＮＤ）である場合のデータ・パケットのヘッダ・フォーマットを例示する図である。図５Ｂに図示のように、データ・パケット１００のヘッダ・セグメント１２０は、４ビット・コンテキスト識別子（ＩＤ）フィールドと、パケット“ｎ”の４ビット・シーケンス番号（ｎ）フィールドと、（ＲＴＰ圧縮ヘッダ、フル・ヘッダなどの）パケットタイプを特定する３ビット・パケットタイプ・フィールドと、伝送中の１次（ＦＯ）差がノンゼロの２次（ＳＯ）差を持つパケットについての差であるか、あるいは、該パケットの後続パケットについての差であるかを示す１ビット再転送（ＲｅＴＸ＝０）ビットと、変化したフィールドを特定する、ＲＦＣ２５０８に記載のような４ビットの組合せ（ＭＳＴＩ：マーカービット、シーケンス番号、タイム・スタンプ、ＩＰ−ＩＤ）フィールドと、ノンゼロの２次（ＳＯ）差を持つＲＴＰフィールドの１次（ＦＯ）差を含む可変長フィールドと、を含むものであってもよい。例えば、タイム・スタンプ（Ｔ＝１）が図４Ａに図示されているように変化したとき、図５Ｂに図示のようなヘッダ・フォーマットは、発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ伝送される。
【００４２】
図５Ｃは、図５Ｂに図示の、（パケット“ｎ＋１”などの）パケット“ｎ”に後続するパケット内の一次（ＦＯ）差を反復する際のヘッダ・フォーマットを例示する。図５Ｃに図示のように、データ・パケット１００のヘッダ・セグメント１２０は、コンテキスト識別子（ＩＤ）フィールドと、パケット“ｎ＋１”のシーケンス番号（ｎ＋１）フィールドと、（ＲＴＰ圧縮ヘッダ、フル・ヘッダなどの）パケットタイプを特定するパケットタイプ・フィールドと、伝送中の１次（ＦＯ）差がノンゼロの２次（ＳＯ）差を持つパケットについての差であるか、あるいは、該パケットの後続パケットについての差であるかを示す再転送（ＲｅＴＸ＝１）ビットと、変化したフィールドを特定するＲＦＣ２５０８に記載のようなＭＳＴＩフィールドと、パケット“ｎ”のシーケンス番号（ｎ）フィールドと、パケット“ｎ”のＲＴＰフィールドの１次（ＦＯ）差を示す可変長フィールドと、を含むものであってもよい。例えば、タイム・スタンプ（Ｔ＝０）が図４Ａと４Ｂに図示されているように変化しなかったとき、図５Ｂに図示のようなヘッダ・フォーマットは、次のパケット（ｎ＋１）または（ｎ＋２）との関連で、発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ伝送される。
【００４３】
図５Ｄは、パケット“ｎ”の１次（ＦＯ）差の通信中、パケット“ｎ＋ｋ”（または図４Ｂを参照して説明したように“ｎ＋１”）の２次（ＳＯ）差がノンゼロである場合のヘッダ・フォーマットを例示する図である（図５Ｂと５Ｃの組合せなど）。図５Ｄに図示のように、データ・パケット１００のヘッダ・セグメント１２０は、コンテキスト識別子（ＩＤ）フィールドと、パケット“ｎ＋ｋ”のシーケンス番号（ｎ＋ｋ）フィールド（または図４Ｂを参照して説明したように、パケット“ｎ＋１”の“ｎ＋１”フィールド）と、（ＲＴＰ圧縮ヘッダ、フル・ヘッダなどの）パケットタイプを特定するパケットタイプ・フィールドと、伝送中の１次（ＦＯ）差がノンゼロの２次（ＳＯ）差を持つパケット“ｎ＋ｋ”（または図４Ｂを参照して説明したように、“ｎ＋１”）についての差であること、あるいは、該パケットの後続パケットについての差であることを示す再転送（ＲｅＴＸ＝０）ビットと、変化したフィールドを特定するＲＦＣ２５０８に記載のような、ビット組合せ（ＭＳＴＩ）フィールドと、パケット（ｎ＋ｋ）（または図４Ｂを参照して説明したようにパケット“ｎ＋１”）についての１次（ＦＯ）差を示すフィールドと、パケット“ｎ”のシーケンス番号（ｎ）フィールドと、パケット“ｎ”のタイプを特定する別のパケットタイプ・フィールドと、ノンゼロの２次（ＳＯ）差を持つパケット“ｎ”のフィールドであることを示す再転送（ＲｘＴｘ＝１）ビットと、変化したフィールドを特定する、ＲＦＣ２５０８に記載されているような別のビット組合せ（ＭＳＴＩ）フィールドと、パケット（ｎ）の１次（ＦＯ）差を示すフィールドと、を含むものであってもよい。例えば、図４Ｂに図示のように、タイム・スタンプ（Ｔ＝１）が変化したとき、図５Ｄに図示のようなヘッダ・フォーマットは、次のパケット（ｎ＋１）と関連して発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ伝送される。
【００４４】
前述したように、図１に図示の発信側端末２０と受信側端末３０は単に例示のデータ・ネットワークとして設けられるものである。すべてのタイプのデータ・ネットワークで任意の数の端末装置、交換機、リンクから成る多種多様な実現例及び構成例が可能である。例えば、ヘッダ圧縮用として設けられたヘッダ圧縮メカニズムを含む、発信側端末と受信側端末から成るこのようなデータ・ネットワークの１つの推奨利用実現例として、図６に図示のようなボイス・オーバーＩＰとテレビ会議のようなリアルタイム・アプリケーション用セルラ方式ネットワークを挙げることもできよう。帯域限定リンク１０は、セルラ通信を行うための、ＩＰネットワーク１２とアクセス・ネットワーク・インフラ・ストラクチャＡＮＩ１４とＡＮＩ１６との組合せとすることも可能である。発信側端末２０は、ＲＴＰ／ＵＤＰ／ＩＰを実行し、ＩＰネットワーク１２及びＡＮＩ１４と１６を介する伝送用のパケット化された音声サンプルをＲＴＰパケットで供給するホストＰＣまたは同種のものであってもよい。受信側端末３０は、ＡＮＩ１４を備えたセルラ通信用の移動端末装置であってもよい。各端末２０と３０はＲＴＰパケット用の発信側端末か受信側端末のいずれかとすることができる。
【００４５】
端末２０には、（例えばＩＰアドレス、ポート番号などを含む）この端末をＲＴＰパケット用の発信元または宛先のいずれかとして特定するＲＴＰエンドポイント２２を含むことも可能である。ＩＰネットワークが例として示されているが、代わりに別のタイプのパケット交換方式ネットワークや同種のネットワークの利用も可能である。また端末２０には、タイム・スタンプ生成用ローカル・タイマ２４も含まれる。
【００４６】
アクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）１４をＩＰネットワーク１２と接続してもよい。無線周波数（ＲＦ）リンク５０を介して移動端末装置３０をＡＮＩ１４と結合してもよい。ＲＦリンク５０には（端末３０からＡＮＩ１４への）上り回線５２と（ＡＮＩ１４から端末３０への）下り回線５４とが含まれる。ＡＮＩ１４は、ある領域で、１以上の無線（すなわち無線周波数）端末（端末３０を含む）をＩＰネットワーク１２とインターフェースすることも可能である。これには（ＩＰネットワーク１２から出力される）有線信号と、（端末３０へまたは端末３０から出力される）無線すなわちＲＦ信号との間の変換が含まれる。したがって、ＩＰネットワーク１２から受信したＲＴＰパケットをＲＦリンク５０を介して移動端末装置３０へ伝送することがＡＮＩ１４により可能になり、さらに、ＩＰネットワーク１２を介して移動端末装置３０から端末２０などのような別の端へＲＴＰパケットの伝送を行うことが可能となる。
【００４７】
本発明の実施例によれば、ＡＮＩ１４には、各々がタイマ４２を含む１以上のＡＮＩアダプタ（ＡＮＩ＿ＡＤ）４０を含むことが望ましい。ＲＦＣ２５０８に類似したヘッダ圧縮処理を行うための、本発明の実施例に従うロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式であるが、図１〜４を参照して説明したように、紛失の多い、エラーし易いネットワークで使用する際、パケットの紛失やエラーの発生時にロバスト性を処理するＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式を用いて各ＡＮＩ＿ＡＤ４０が構成され、実現されて、ヘッダの正しい再構成を行うことが可能となる。ＡＮＩ＿ＡＤ４０は（下り回線の伝送に先行して）ヘッダ圧縮を実行し、次いで（上り回線の伝送後）解凍を実行することが可能である。ＩＰネットワーク１２から受信したＲＴＰパケット用ヘッダ（またはタイム・スタンプのような１以上のヘッダ・フィールド）は、下り回線５４を介する移動端末装置３０への伝送に先行してＡＮＩ＿ＡＤ４０により圧縮され、移動端末装置３０から受信したパケット・ヘッダはＩＰネットワーク１２への伝送前にＡＮＩ＿ＡＤ４０により解凍される。したがって、各ＡＮＩ＿ＡＤ４０はヘッダ圧縮装置／解凍装置と考えることもできる。また各ＡＮＩ＿ＡＤ４０は、ＩＰネットワーク１２とつながる領域の範囲内の特定のエリアまたは異なるエリア内に位置する端末をインターフェースすることも可能である。
【００４８】
ＡＮＩ＿ＡＤ４０は、タイマ・ベースの解凍手法を実現するためのタイマ４２を含むことも可能である。また、ＩＰネットワーク１２とつながる追加領域に位置する別の端末をインターフェースするために追加のＡＮＩを設けることも可能である。
【００４９】
移動端末装置３０は、ＲＴＰパケットの発信元及び／又は宛先（受信装置）であるＲＴＰエンドポイント１３２を含むことも可能である。移動端末装置３０は、（上り回線５２で伝送されるパケットに対する）ヘッダ圧縮、及び、（下り回線５４を介して受信されるパケットに対する）解凍を実行するターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）３６を含むことも可能である。したがって、ターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）は、ＡＮＩ＿ＡＤと類似のヘッダ圧縮装置／解凍装置と考えることもできる。
【００５０】
また、ターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）３６にはカレント・ヘッダのＲＴＰタイム・スタンプの近似値（または推定値）を計算するタイマ３４も含まれる。次いで、ターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）３６は、ＲＴＰヘッダ内の追加情報を利用してタイム・スタンプの近似値の微調整または補正を行う。ローカル・タイマ及び圧縮されたタイム・スタンプを利用して、各ＲＴＰヘッダの正しいタイム・スタンプの再生が可能となる。各々がそれ自身のＲＴＰエンドポイント、ターミナル・アダプタ及びタイマを含む別の端末を設けることも可能である。
【００５１】
上述のように、本発明は、信頼できないネットワークが存在する場合にロバストなＩＰヘッダ圧縮を達成するためのロバストなヘッダ圧縮方式を好適に提供するものである。この提案された方式は、パケット紛失に対して必要な所望の保護に基づいて弾力的に適用することも可能である。奇数ビットの保護（但しこの場合ペイロードに対してヘッダへの保護）を行う、例えば音声符号化時などに利用される手法と類似の手法を用いることによりビット誤りに対する保護を行うことも可能である。
【００５２】
本発明の推奨実施例と考えられるものを例示し、説明したが、様々な変更及び修正を行うことも可能であること、及び、本発明の真の範囲から逸脱することなく本発明の要素の代わりの均等物を用いることも可能であることを当業者は理解するであろう。さらに、多くの修正を行って、本発明の中心となる範囲から逸脱することなく、特定の状況を本発明の教示に適合させることも可能である。したがって、本発明の実行のために熟慮されたベストモードとして開示した特定の実施例に限定されるものではなく、本発明は添付の請求項の範囲に属するすべての実施例を含むものであることが意図される。
【図面の簡単な説明】
【図１】本発明の実施例に従う、帯域限定リンクを介してヘッダ圧縮及びデータ通信を行うために設けられたヘッダ圧縮メカニズムを含む、発信側端末と受信側端末とからなる例示データ・ネットワークを示す。
【図２Ａ】本発明の実施例に従う、例示データ・ネットワークで使用する例示データ・パケットを示す。
【図２Ｂ】本発明の実施例に従う、例示データ・ネットワークで使用する例示データ・パケットを示す。
【図３】本発明の実施例に従う、未圧縮フォーマットでのデータ・パケットの例示ＲＴＰヘッダ・セグメントを示す。
【図４Ａ】本発明の実施例に従う、変化するフィールドのための、発信側端末の圧縮装置と受信側端末の解凍装置の機能を例示する。
【図４Ｂ】本発明の実施例に従う、変化するフィールドのための、発信側端末の圧縮装置と受信側端末の解凍装置の機能を例示する。
【図５Ａ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図５Ｂ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図５Ｃ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図５Ｄ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図６】本発明の実施例に従う、ヘッダ圧縮用、並びに、セルラ・リンクを介するデータ通信用として設けられたヘッダ圧縮メカニズムを含む、発信側端末と受信側端末とからなるＩＰベースのネットワークの１つの推奨利用実現例を例示する。
【符号の説明】
１０ 帯域限定リンク（ＩＰ）
２０ 発信側端末
２２ ホスト
２４ ＮＩＣ
２６ 圧縮装置／解凍装置
３０ 受信側端末
３２ ホスト
３４ ＮＩＣ
３６ 圧縮装置／解凍装置
【発明の属する技術分野】
本発明は、データ・ネットワークにおけるデータの圧縮と解凍に関し、具体的には、信頼できないネットワークが存在する場合にロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮を達成するシステム及び方法に関する。
【０００２】
【従来の技術】
最近、インターネットの利用が増加した結果、ネットワーク容量の不足が生じて、従来のアプリケーションのパフォーマンスに対して否定的影響を与えるようになっている。同時に、テレビ会議やボイス・オーバーＩＰ（ＶｏＩＰ）を含む双方向型オーディオ及び／又はビデオなどの、タイムリなデータ配信並びにはるかに改善されたサービス品質が要求される新しいアプリケーションが現れてきた。テレビ会議やボイス・オーバーＩＰ（ＶｏＩＰ）のような、様々なタイプのネットワーク用リアルタイム・アプリケーション間でのインターオペラビリティ（相互運用性）を得るためにリアルタイム転送プロトコル（ＲＴＰ）が利用されてきた。インターネット・プロトコル（ＩＰ）ベースのリアルタイム・マルチメディア用として、ユーザ・データグラム・プロトコル（ＵＤＰ／ＩＰ）の上位でＲＴＰを使用して、“ＲＴＰ：リアルタイム・アプリケーション用トランスポート・プロトコル”（Ｈｅｎｎｉｎｇ Ｓｃｈｕｌｚｒｉｎｎｅ， Ｓｔｅｐｈｅｎ Ｌ． Ｃａｓｎｅｒ， Ｒｏｎ Ｆｒｅｄｅｒｉｃｋ， ａｎｄ Ｖａｎ Ｊａｃｏｂｓｏｎ共著、インターネットの技術標準文書（ＲＦＣ）１８８９年、１９９６年１月）に記述されているような多重化及びチェックサム・サービスの利用が可能である。しかし、ダイアルアップ・モデムのような低速回線を介して伝送を行う場合、容認できる双方向型の応答と回線効率にとってＲＴＰヘッダが大きくなりすぎるかもしれないという懸念がある。例えば、インターネット・プロトコル・バージョン４（ＩＰｖ４）では、ＩＰ／ＵＤＰ／ＲＴＰを含むヘッダ・フィールドは、パケット当たり４０バイトを占めることができる。同様に、インターネット・プロトコル・バージョン６（ＩＰｖ６）では、このようなヘッダ・フィールドはパケット当たり６０バイトを占めることができる。音声ペイロードを（２０ｍｓのＧＳＭ符号化音声に対応する）３６バイトほどの小さなものとすることも可能な通話用音声のようなリアルタイム・アプリケーションでは、このヘッダ・オーバーヘッドはきわめて大きなものである。従って、リアルタイム・アプリケーションではこのようなヘッダ・オーバーヘッドを大幅に減らす必要がある。
【０００３】
現在、ヘッダ・オーバーヘッドを低減して、低速及び中速リンクでの帯域の効率的な利用を可能にするための、ＩＰ／ＵＤＰ／ＲＴＰデータグラムのヘッダ圧縮に利用可能なヘッダ圧縮手法はほとんどが存在しない。このようなヘッダ圧縮手法の最も最近の例が、“低速シリアルリンク用ＩＰ／ＵＤＰ／ＲＴＰヘッダの圧縮”（Ｓｔｅｐｈｅｎ Ｌ． Ｃａｓｎｅｒ及びＶａｎ Ｊａｃｏｂｓｏｎ、ＲＦＣ２５０８、１９９９年２月）に記載されている。ＩＰ／ＵＤＰ／ＲＴＰデータグラムのヘッダを圧縮して、２〜４バイトまでヘッダ・オーバーヘッドを低減する圧縮／解凍装置を備えたヘッダ圧縮メカニズムが提供されている。このヘッダ圧縮方式は、ＩＰヘッダのほとんどのフィールドが、接続寿命（すなわちセッションの長さ）の間パケット・ストリームの中で一定のままであるという観察に基づくものである。したがって、解凍装置で圧縮状態を保持することにより、また、（エラー検出及びパケット紛失検出用として使用するセッション・コンテキスト識別子と小さなシーケンス番号のような）最低量のヘッダ・オーバーヘッドを圧縮装置から解凍装置へ単にトランスポートすることにより、ヘッダ圧縮を達成することも可能である。ＲＦＣ２５０８によれば、解凍装置での圧縮状態は、すべてのパケットで変化するフィールド、及び、すべてのパケットで変化しないフィールドを含む未圧縮のヘッダ・フィールドに対応するようにしてもよい。（発信元と宛先のＩＰアドレス及びポート番号のような）変化しないフィールドの場合、解凍装置は、圧縮状態で保存されている対応フィールドを単に加算するだけでよい。しかし、変化するフィールドの場合、解凍装置は、圧縮パケット・ヘッダで送られる情報に依拠することができる。典型的には、圧縮パケット・ヘッダの中に内包される情報は、前回のパケット内のフィールドの値（すなわち変化するフィールドのノンゼロの２次差のみに関する変化の差）を含み、変化したフィールド自身を含むものではない。
【０００４】
一般的処理を行うために、変化しないフィールドのコンテキスト状態及び変化するフィールドの１次差が解凍装置により確立されるまで完全なＩＰ／ＵＤＰ／ＲＴＰヘッダを解凍装置へ伝送することにより圧縮装置は始動する。いったんコンテキスト状態が確立されると、２次差（デルタ）がノンゼロである限り、圧縮装置は差（特に、ＲＴＰタイム・スタンプやＲＴＰシーケンス番号などのようなＲＴＰヘッダ・フィールドに対応する差）を伝送する必要はなくなる。パケットからパケットへのＲＴＰヘッダの２次差（デルタ）がゼロである場合、解凍装置は、各圧縮パケットが受信されたとき、前回のパケットを表す保存されている未圧縮ヘッダに１次差を単純に加算することにより、情報ロスのないパケットの再構成（復元）が可能となる。通信の必要があるのはただ、圧縮装置と解凍装置との間のパケット紛失を検出するためのセッション・コンテキスト識別子（ＩＤ）と小さなシーケンス番号（ＲＴＰシーケンス番号とは関連しない）だけである。例えば、パケット＃１、＃２、＃３のＲＴＰタイム・スタンプが、２０から４０、６０へと変化する場合、２０と４０及び４０と６０との間の１次差は２０である。初期値２０が既知である場合、２次差がゼロであることが圧縮ヘッダ内の適切なフィールドによって示されていれば、解凍装置はパケット＃３の正しい増分値を単に加算するだけでよい。
【０００５】
一方、いくつかのフィールドのＲＴＰヘッダの２次差（デルタ）がゼロでない場合、コンパクトな符号化を用いてそれらのフィールドだけの新しい１次差を通信しなければならない。これらの新しい１次差の値は、解凍装置のセッション・コンテキスト内の未圧縮ヘッダ内の対応フィールドに加算され、次いで、セッション・コンテキストの中にはっきりと保存されて、２次差（デルタ）がゼロである各後続パケット内の対応フィールドに再び加算される。後続パケット内で１次差が変化する度にその差が伝送され、セッション・コンテキストの更新に利用される。
【０００６】
しかし、インターネット共同体に利用可能なインターネット用の規格プロトコルが含まれるＲＦＣ２５０８及びその他のＲＦＣ文書に記載されているようなヘッダ圧縮方式は、帯域が不足し、多くのリンク・エラーや長いリンク待ち時間が生じる（セルラ無線ネットワークのような）環境での処理には適していない。パケットの紛失に起因して、解凍装置が、ＲＴＰタイム・スタンプやＲＴＰシーケンス番号のような間違ったヘッダ情報を受信に成功した次のパケットに加算する可能性がある。同様に、圧縮パケット・ヘッダがエラーになった場合、ＲＴＰパケットの同様の間違った再構成が結果として生じる可能性がある。例えば、１フィールド（または複数のフィールド）の新しい１次差を含むパケットが（おそらくエラーに起因して）紛失したと考えられる場合、解凍装置が圧縮装置に通知するか、必要な１次差の再送に圧縮装置が成功するまで後続パケット用ヘッダの正しい再構成はできなくなる。この回復段階中、ヘッダの再構成を行うために伝送済みパケットと伝送中パケットの処理を行うことはできない。ボイス・オーバーＩＰ（ＶｏＩＰ）やテレビ会議のようなリアルタイム・アプリケーションの場合、プレイアウト・デッドライン（ｐｌａｙ−ｏｕｔ ｄｅａｄｌｉｎｅ）の期限切れに起因してこれらのパケットは破棄される可能性がある。例えば、（基地局のような）無線アクセス・ポイントから移動機への１方向遅延（または基地局から移動機へ、次いで基地局へもどる１２０ｍｓのラウンド・トリップ遅延）の６０ｍｓを持つセルラ・リンク、及び、トーク・スパート（ｔａｌｋｓｐｕｒｔ）中の２０ｍｓの音声パケット間でのパケット間（ｉｎｔｅｒ−ｐａｃｋｅｔ）分離について考えてみよう。トーク・スパートの開始時に、一番最初のパケットのＲＴＰタイム・スタンプは、無音間隔に起因してその２次差がノンゼロとなるように増分する。したがって、この一番最初のパケットで解凍装置へ新しい１次差を通信しなければならない。パケットがエラーに起因してなぜか紛失した場合、解凍装置が故障に関する情報を圧縮装置に与えるまで、次の３個のパケット（６０ｍｓ／２０ｍｓ）の再構成を行うことはできない。この故障時間中、（トーク・スパートが少なくとも６個のパケットで持続すると仮定した場合）別のさらに３個のパケットが圧縮装置により伝送されたであろう。解凍装置によって正しい１次差が受信されるまでこれら６個のパケットはすべて待機する必要があり、その結果、プレイアウト・デッドラインの期限切れのために破棄される可能性がある。
【０００７】
したがって、信頼できないネットワークが存在する際のロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式に対する要望が存在する。さらに、ヘッダ・パケットの紛失やエラーの発生時に正しく再構成を行うことが可能な方式が必要とされている。
【０００８】
【発明が解決しようとする課題】
したがって、本発明の様々な実施例は、パケットの紛失やエラーの発生時に、ＩＰ／ＵＤＰ／ＲＴＰヘッダの正しい再構成が可能なロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮メカニズムと手法を目的とするものである。このヘッダ圧縮メカニズムには、ＲＦＣ２５０８に類似して処理を行うように実現される圧縮／解凍装置であって、紛失が多く、エラーし易いネットワークで使用される場合、ロバスト性を処理できるように特別に設計された圧縮／解凍装置が含まれ、パケットの紛失やエラーの発生時にヘッダの正しい再構成が可能となる。
【０００９】
【課題を解決するための手段】
本発明の１つの態様によれば、上記ロバストなヘッダ圧縮方式の要件として、フィールドの２次差がノンゼロである場合、ノンゼロの２次差を持つ或る特定のＲＴＰパケットを新しい１次差と共に伝送することが求められるだけでなく、（ａ）ある時間が、チャンネル特性（リンク・ラウンド・トリップ時間ＲＴＰ／パケット間分離など）のような係数により予め定められているか、（ｂ）新しい１次差が正しく受信された旨の肯定の確認が圧縮装置により受信される限り、その新しい１次差と共に後続パケットを伝送することが求められる。その結果、後続パケットの“自制”が保証され、たとえ２次差をノンゼロとなるようにしたパケットが紛失しても、解凍装置は該後続のパケットのヘッダの正しい再構成を行うことが可能となる。
【００１０】
本発明の別の態様によれば、ロバストなヘッダ圧縮方式の要件として、対応するＲＴＰフィールドが１次差の通信時間中ノンゼロの２次差と共に再び変化した場合、これら２つの１次差を高い信頼性で通信する単純な手段としてこれら２つの１次差をまとめて後ろに付加することができるように“新しい”１次差は元の１次差と組み合わされる。しかし、本発明は効率を図る目的で１次差を組み合わせる別の手段を除外するものではない。
【００１１】
【発明の実施の形態】
単に例として添付されている図面を参照しながら以下のパラグラフで本発明についてさらに具体的に説明する。
【００１２】
本発明のさらに完全な理解、及び、本発明の付随する利点の多くは、添付図面と関連して考察し、以下の詳細な記述を参照して同発明をより良く理解したとき容易に明らかになる。上記添付図面では同じ参照記号により、同じまたは類似の構成要素が示されている。
【００１３】
本発明は、すべてのタイプのデータ・ネットワークとリアルタイム通信サービスと共に使用するために適用可能である。例えば、データ・ネットワークは、ボイス・オーバーＩＰ（ＶｏＩＰ）やテレビ会議（ビデオ・オーバーＩＰ）のようなリアルタイム・アプリケーション用として利用される、イーサネット・ローカル・エリア・ネットワーク（ＬＡＮ）、非同期転送モード（ＡＴＭ）、フレーム・リレー及びインターネットを含むパケット・ネットワークであってもよい。上記とは別に、このようなデータ・ネットワークは、旧来の電話サービス（ＰＯＴＳ）、公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）、移動通信ネットワーク、衛星ネットワーク、及び、地上デジタルＴＶや無線、セルラ、短距離用無線（ブルートゥース、ＲＦプロトコル、無線ＬＡＮ）ネットワークなどのネットワークを含む私設ネットワークまたは公衆ネットワークであってもよい。しかし、説明を単純にするために、本解説では、ボイス・オーバーＩＰ（ＶｏＩＰ）やテレビ会議（ビデオ・オーバーＩＰ）のようなリアルタイム・アプリケーションのための様々な構成から成る単純なデータ・ネットワークが主として中心となる。但し、本発明の範囲と実現はこのようなデータ・ネットワークに限定されるものではない。
【００１４】
図面、特に、図１の発信側端末２０と受信側端末３０からなる、本発明の実施例に従う単純なデータ・ネットワークに注意されたい。図１に図示のように、帯域限定リンク１０を利用して発信側端末２０を受信側端末３０と接続するようにすることも可能である。帯域限定リンク１０はダイアルアップ・モデムまたは高周波（ＲＦ）無線リンク（セルラ・リンク）などの低速回線を表すものであってもよい。上記とは別に、帯域限定リンク１０は、インターネット・サービス・プロバイダ（ＩＳＰ）のＩＰベースのネットワーク、インターネット、例えば、公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）及び発信側端末２０と受信側端末３０との間の通信を可能にするその他のアクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）などを含む様々な発信側ネットワーク及び着信側ネットワークを含むものであってもよい。帯域限定リンク１０がセルラ・リンクに対応する場合、発信側端末２０及び受信側端末３０は移動端末装置と基地局にそれぞれ対応するようにすることも可能であり、また、その逆も可能である。
【００１５】
発信側端末２０には、例えば、少なくともホスト２２とネットワーク・インターフェース・コントローラ（ＮＩＣ）２４とが含まれる。同様に、受信側端末３０には、例えば、少なくともホスト３２とネットワーク・インターフェース・コントローラ（ＮＩＣ）３４とが含まれる。複数のホストが発信側端末２０と受信側端末３０に含まれるようにしてもよい。各ホストは、帯域限定リンク１０を介して発信側端末２０から受信側端末３０へデータ・パケットを伝送するＩＰ電話やスタンド・アローン型ＰＣに対応するようにしもよい。
【００１６】
発信側端末２０では、ホスト２２は、ネットワーク・インターフェース・コントローラ（ＮＩＣ）２４へ転送するデータを生成する。発信側端末２０のＮＩＣ２４は、例えば、ユーザ・データグラム・プロトコル（ＵＤＰ／ＩＰ）の上位で用いられるリアルタイム転送プロトコル（ＲＴＰ）を利用してホスト２２からの着信データをデータ・パケットに変換し、帯域限定リンク１０を介してこれらのデータ・パケットを注入する。帯域限定リンク１０がＩＰベースのネットワークである場合、そのデータ・パケットのレートはＩＰベースのネットワーク１０を介して注入されて、外へ向かうデータ・フローパケットの制御と管理がＮＩＣ２４により行われ、ＩＰベースのネットワーク１０における輻輳状態の回避及びデータ・パケット帯域の使用の限定が図られる。ＩＰベースのネットワーク１０は着信データ・パケットを受け取り、次いで、ヘッダに含まれる情報に従って受信側端末３０へ同着信データ・パケットを転送する。受信側端末３０のＮＩＣ３４は、ＩＰベースのネットワーク１０からこれらのデータ・パケットを受け取り、同データ・パケットをデータに変換し、次いでホスト３２へ該データの転送を行う。
【００１７】
図２Ａ〜２Ｂは本発明の実施例に従う単純なデータ・ネットワークで利用する例示データ・パケットを示すものである。図２Ａに図示のように、例示データ・パケット１００は、データ・ペイロード１３０のセグメントと、データ・ペイロード１３０の前に付加される小さなヘッダ１２０とから構成される。パケット１００は、ボイス・オーバーＩＰ（ＶｏＩＰ）またはビデオ・オーバーＩＰのリアルタイム・トラフィックを表すものであってもよいが、これに限定されるものではない。例えば、ヘッダ・セグメント１２０には、ＩＰアドレス・フィールド（一般にネットワークＩＤとホストＩＤとから成る３２ビット・グローバル・インターネット・アドレス）と、ＩＰのどのバージョンがＩＰパケットの中に表されているか（例えばＩＰバージョン４及びＩＰバージョン６など）を指定するために使用されるバージョン・フィールドと、様々なサービス品質を提供するＩＰベースのネットワークでのＩＰパケットの処理方法を指定するために使用されるサービス・フィールドのタイプと、伝送エラーの検証に使用されるヘッダ・チェックサム・フィールドとが含まれる。フラグとフラグメント・オフセット・フィールド、合計長フィールド、ＩＤフィールド、ＴＴＬ（ｔｉｍｅ ｔｏ ｌｉｖｅ）フィールドと、プロトコル・フィールドなどのその他のＩＰフィールドをこのようなヘッダの中に含めてもよい。インターネット・プロトコル・バージョン４（ＩＰｖ４）では、ＩＰ／ＵＤＰ／ＲＴＰを含むヘッダ・フィールドはパケット当たり４０バイト、また、インターネット・プロトコル・バージョン６（ＩＰｖ６）の場合には、パケット当たり６０バイトを占めることが可能である。ヘッダ・オーバーヘッドは、データ・ペイロードに比べて一般に相当の大きさになり、特に、実際の音声ペイロードが３６バイト（２０ｍｓのＧＳＭ符号化音声に対応する）ほどの小さなものである場合もある通話用音声のような、ユーザ・データグラム・プロトコル（ＵＤＰ／ＩＰ）の上位で使用されるリアルタイム転送プロトコル（ＲＴＰ）が用いられるリアルタイム・アプリケーションの場合には、ヘッダ・オーバーヘッドは相当の大きさのものになる。
【００１８】
図２Ｂは、ＩＰヘッダ１２２と、ＵＤＰヘッダ１２４と、ＲＴＰヘッダ１２６、及び、例えば、図２Ａに図示の音声サンプルなどを含むデータ・ペイロード１３０の組合せを含む例示ヘッダ・セグメント１２０を示す。
【００１９】
図３は、本発明の実施例に従う、未圧縮フォーマットの例示ＲＴＰヘッダ１２６を示す。図３に図示のように、未圧縮のＲＴＰヘッダ１２６にはタイム・スタンプ（Ｔ）３１０と、シーケンス番号（ＳＮ）３１２と、その他のフィールド３１４とが含まれる。ＩＰネットワークのパケット交換型の性質（図１を参照）に起因して、ＲＴＰパケットが間違った順序で着信する場合がある。受信側端末３０でシーケンス番号３１２を使用して、ＲＴＰ音声サンプルを正しい順序に組み立てることも可能である。しかし、ＲＴＰパケット内のシーケンス番号は、フィールドのいずれの非線形変化（音声信号の無音間隔）も反映しない場合がある。したがって、タイム・スタンプ（Ｔ）３１０を設けて各パケットの相対的タイミングを示すようにしてもよい。
【００２０】
前述したように、各ＲＴＰパケット内のＩＰ／ＵＤＰ／ＲＴＰヘッダにより供給される４０〜６０バイトのヘッダ・オーバーヘッドが大きすぎる場合もある。特に、ＲＴＰタイム・スタンプがあまりに大きな負担となるためダイアルアップ・モデムや帯域限定リンクなどのような低速回線を介してＲＴＰパケットがトランスポートを行うことができなくなる場合もある。したがって、図１に図示のデータ・ネットワークの発信側端末２０のＮＩＣ２４の中には（またエンド・ツー・エンド・ベースの双方向通信用受信側端末２０のＮＩＣ３４の中にも）、一般に、発信側端末２０と受信側端末３０においてヘッダ圧縮を行うヘッダ圧縮メカニズム２６と３６が含まれる。上記メカニズムは、ダイアルアップ・モデムまたは帯域限定リンクなどのような低速回線を介する作動時に、容認できる双方向型の応答と回線効率のためにヘッダのオーバーヘッドの低減を図るものである。ヘッダ圧縮メカニズム２６と３６に、ＩＰ／ＵＤＰ／ＲＴＰデータグラムのヘッダを圧縮する圧縮／解凍装置を設けて、２〜４バイトまでヘッダ・オーバーヘッドを低減するようにしてもよい。ＣやＣ＋＋のような高水準プログラム言語と汎用コンピュータを用いて標準的プログラミング方法により構成されるハードウェア及び／又はソフトウェアによりヘッダ圧縮メカニズム２６と３６を実現して、ヘッダ圧縮を達成するようにしてもよい。ソフトウェア・モジュールによりヘッダ圧縮メカニズム２６と３６を実現する場合、ＥＰＲＯＭ、ＥＥＰＲＯＭなどの半導体記憶装置、フラッシュメモリ・デバイス、磁気ディスク（固定ディスク、フロッピー・ディスク、リムーバブル）、テープなどのその他の磁気媒体及びＣＤ−ＲＯＭディスクなどのような光媒体を含む有形の媒体（但しこれらに限定されるものではない）上にこのようなソフトウェア・モジュールを設けることも可能である。ホストのネットワーク・インターフェース・カードと共にこのようなソフトウェア・モジュールをバンドルしてもよい。上記とは別に、ヘッダ圧縮メカニズム２６と３６は、ファームウェア・モジュールまたはホストに組み込みが可能な包括的なハードウェア／ソフトウェア・モジュールとして利用できるものであってもよい。さらに、ヘッダ圧縮メカニズム２６と３６とは、ＲＦＣ２５０８に類似の機能を行うために実現可能であるが、セルラ無線ネットワークのような多くのリンク・エラーや長いリンク待ち時間が生じることを特徴とする、紛失が多く、エラーし易いネットワーク環境で使用される場合、アドレスのロバスト性を処理できるように特別に設計されて、パケットの紛失やエラーの発生時にヘッダの正しい再構成が図られるようになっている。
【００２１】
図１に図示の発信側端末と受信側端末及びリンクの具体的な数と構成は、帯域が不足し、エラーが稀ではない場合もあるデータ・リンクを介してデータ・パケットのヘッダ圧縮と伝送を行うヘッダ圧縮方式が利用される例示データ・ネットワークとして単に示されているものにすぎない。すべてのタイプのデータ・ネットワークにおいてどのような数の端末装置、交換機、リンクから成る多種多様な実現例と構成例が可能である。
【００２２】
ヘッダ圧縮処理を行うために、ＲＦＣ２５０８に記載されている方法と同じ方法で、変化しないフィールドのコンテキスト状態並びに変化するフィールドの１次差が解凍装置３６により確立されるまで、受信側端末３０の解凍装置３６へ完全なＩＰ／ＵＤＰ／ＲＴＰヘッダを伝送することにより発信側端末２０の圧縮装置２６は始動する。すなわち、コンテキスト状態が確立されると、２次差（デルタ）がノンゼロでない場合、発信側端末２０の圧縮装置２６は、１次差（特に、例えば、ＲＴＰタイム・スタンプとＲＴＰシーケンス番号などのようなＲＴＰヘッダ・フィールドに対応する差）を伝送する必要はなくなる。パケットからパケットへのＲＴＰヘッダ（またはデータ・パケットのＩＰ／ＵＤＰヘッダ）の２次差（デルタ）がゼロである場合、各圧縮パケットが受信されたとき、受信側端末３０の解凍装置３６は、前回のパケットを表す保存された未圧縮ヘッダに１次差を単に加算するだけで、情報の紛失が皆無のパケットの再構成が可能となる。
【００２３】
いずれかのフィールドのＲＴＰヘッダの２次差（デルタ）がノンゼロである場合、発信側端末２０の圧縮装置２６は、ＲＦＣ２５０８に記載の方法で、対応フィールドの新しい１次差を伝送するように機能する。しかし、ＲＦＣ２５０８に加えて、（帯域が不足し、多くのリンク・エラーと長いリンク待ち時間が生じる可能性があるセルラ・ネットワークまたは無線ネットワークのような）紛失が多く、エラーし易い、信頼できないネットワークで使用する場合、ヘッダ圧縮メカニズム２６と３６がロバスト性を処理できるように特別に設計され、実現されて、パケットの紛失やエラーの発生時にヘッダの正しい再構成が行われる。
【００２４】
一般に、本発明のヘッダ圧縮方式の要件として、フィールドの２次差がノンゼロである場合、ノンゼロの２次差を持つ或る特定のＲＴＰパケットを発信側端末２０の圧縮装置２６から新しい１次差と共に伝送することが求められるだけでなく、（ａ）ある時間が、チャンネル特性（リンク・ラウンド・トリップ時間ＲＴＰ／パケット間分離など；ラウンド・トリップ時間ＲＴＴとは、データ・パケットまたはフレームが発信側端末２０から受信側端末３０までどれだけの長さを進むかを示す推定値である）のような係数によって予め定められているか、（ｂ）新しい１次差が正しく受信された旨の肯定の確認が発信側端末２０の圧縮装置２６により受信される限り、その新しい１次差と共に後続パケットの伝送も求められる。上記要件によって、後続パケットの“自制”が保証され、たとえ２次差をノンゼロとなるようにしたパケットが紛失しても、受信側端末３０の解凍装置３６による該後続パケットのヘッダの正しい再構成を行うことが可能となる。
【００２５】
本発明の別の態様によれば、対応するＲＴＰフィールドが１次差の通信時間中ノンゼロの２次差と共に再び変化した場合、これら２つの１次差を高い信頼性で通信する単純な手段としてこれら２つの１次差をまとめて後ろに付加することができるように“新しい”１次差は元の１次差と組み合わされる。しかし、本発明は効率を図る目的で１次差を組み合わせる別の手段を除外するものではない。
【００２６】
ここで図４Ａ〜４Ｂを参照しながら、変化するフィールドのための、発信側端末２０の圧縮装置２６及び受信側端末３０の解凍装置３６の機能、及び、パケットの紛失やエラーの発生時にヘッダを正しく再構成できる方法の諸例について以下本明細書で説明する。
【００２７】
単一の変化するフィールドの場合、ｘｎを発信側端末２０の圧縮装置２６が伝送しなければならないフィールドｇｎの１次差符号値（すなわち１次差の符号化された値）とする。なぜなら、該符号値は、パケットｐｎの中で通常の予想値とは異なる量だけ変化し、受信側端末３０の解凍装置３６による受信に成功しなかったからである。
【００２８】
Ｘｎ＝ｘ（ｎ−１）＊ｆ（ｎ−１，ｎ）＊Ｘｎかつｘ（ｎ＋１）＝Ｘｎ＊ｆ（ｎ，ｎ＋１）＊ｘ（ｎ＋１）と定義する。但し、ｆ（ｉ，ｊ）は、Ｘｎとｘ（ｎ＋１）とからＸｎ（共通入力）を計算し、所定のＸｎとＸｎ、ｘ（ｎ−１）の一意的計算を可能にするものである。さらに、ｆ（ｉ，ｊ）は、入力ｘｎまたはｘ（ｎ−１）のうちのいずれか一方がゼロの場合、Ｘｎ＝ノンゼロ入力を設定するようにするものである。
【００２９】
ｆ（ｉ，ｊ）の最も単純な形は、“アペンド（ａｐｐｅｎｄ）”関数であり、これは存在するフィールドに単に冗長性をつけ加えるだけの関数である。例えば、上記のＸｎはｘ（ｎ−１）とｘｎの双方から構成されるものであってもよい。さらに優れた関数を利用してもよい。しかし、関数の複雑さとＸｎを表すために必要とされるビットの減少との間でトレードオフが行われる。
【００３０】
発信側端末２０の圧縮装置２６は、たとえ対応フィールドｇ（ｎ＋１）が予想量とは異なる量しか変化しない場合であっても（この場合ｘ（ｎ＋１）はゼロになる）、パケットｐｎに対応するＸｎと、ｐ（ｎ＋１）に対応するｘ（ｎ＋１）の計算を行うことが可能である。発信側端末２０の圧縮装置２６は、ｘｎの代わりにｐｎでＸｎを伝送し、ｘ（ｎ＋１）の代わりにｐ（ｎ＋１）でＸ（ｎ＋１）を伝送する。
【００３１】
パケットｐｎが紛失し、ｐ（ｎ＋１）とｐ（ｎ＋２）とが受信された場合、ｘ（ｎ＋１）の計算が可能となり、Ｘ（ｎ＋１）が既知となるためＸｎの計算も可能となる。したがって、パケットｐｎの紛失がヘッダの正しい再構成に影響を与えることはない。その結果、単一パケットの紛失に対する保護を行うことが可能となる。
【００３２】
ｆ（ｉ，ｊ）が“アペンド”関数以外の場合、Ｘｎの計算をＸｎとｘ（ｎ−１）だけに限定する必要はない。ｘｎは上記すべてのｘｉの関数とすることができる。但し、対応する関数ｆ（ｉ，ｉ−ｊ）が存在する限り、任意のｉ−ｊの値についてｉ＝ｉ，ｉ−１，ｉ−２，．．．ｉ−ｊである。任意の２つのＸｉとＸ（ｉ＋１）から、共通入力ｘｉ、ｘ（ｉ−１）、ｘ（ｉ−２）、．．．、ｘ（ｉ−ｊ）をｘｉとｘ（ｉ＋１）から別個に計算することができる。このような場合、フィールドの変化が生じたとき、パケット紛失のバーストに対する保護を目的として、発信側端末２０の圧縮装置２６はｘ（ｉ−ｊ）までｘｉ値を計算しなければならない。
【００３３】
ｆ（ｉ，ｊ）が“アペンド”関数であるとき、本発明の１つの態様として記述される要件により、バースト・パケット紛失に対する保護が行われる。すなわち、フィールドの２次差がノンゼロである場合、ノンゼロの２次差を持つ或る特定のＲＴＰパケットを新しい１次差と共に伝送することが求められるだけでなく、（ａ）ある時間が、チャンネル特性（リンク・ラウンド・トリップ時間ＲＴＰ／パケット間分離など）のような係数によって予め定められているか、（ｂ）新しい１次差が正しく受信された旨の肯定の確認が圧縮装置により受信される限り、上記新しい１次差と共に後続パケットの伝送も求められる。
【００３４】
図４Ａ〜４Ｂに図示のように、変化するフィールドのための、発信側端末２０の圧縮装置２６及び受信側端末３０の解凍装置３６のについて以下説明する。図４Ａでは、本発明の実施例に従う、圧縮フォーマットでの例示ＲＴＰパケット１００の中に、コンテキスト識別子（ＩＤ）フィールド、タイム・スタンプ（Ｔ）フィールドが変化しているかどうかを示すフラグ“Ｔ”により示されるタイム・スタンプ（Ｔ）フィールド及びシーケンス番号（ＳＮ）を含むようにしてもよい。残りのフィールドは図を明瞭にするために示されていない。
【００３５】
Ｔは、ＲＴＰタイムスタンプ・フィールドが（ＲＦＣ２５０８に記載されているような）予想値とは異なる値だけ変化したかどうかを示すために使用するビットとする。
【００３６】
圧縮ヘッダにおいて、デルタ・タイムスタンプ（ＲＴＰタイム・スタンプの１次差の符号化された値）＝シーケンス番号ｓｎを持つパケットｐｎに対応するＸｎ、かつ、Ｔ＝１とする。受信側端末３０の解凍装置３６からパケットｐｎが紛失したと仮定する。この紛失は、シーケンス番号ｓ（ｎ＋１）を持つ次のパケットｐ（ｎ＋１）が着信したとき、受信側端末３０の解凍装置３６により検知可能である。
【００３７】
ｐ（ｎ＋１）でＴ＝０の場合、受信側端末３０の解凍装置３６は、上記方法論に従って発信側端末２０の圧縮装置２６が配置したであろうデルタ・タイムスタンプ・フィールドをまだ探索している（前回のパケットが紛失したため）。デルタ・タイムスタンプ・フィールドはＸｎを含むことになる。解凍装置３６はｘ（ｎ＋１）からＸｎを取得する。
【００３８】
次に、図４Ｂに図示のように、Ｔ＝１の場合、受信側端末３０の解凍装置３６はデルタ・タイムスタンプ・フィールドの探索を求められる。しかし、当該フィールドに含まれる値がｘ（ｎ＋１）になるため、“ｆ（ｉ，ｊ）”関数が“アペンド”関数でない関数の場合、受信側端末３０の解凍装置３６はデルタ・タイムスタンプ（Ｘｎ）の実際の値を計算することはできない。ｆ（ｉ，ｊ）が“アペンド”関数でない関数の場合、受信側端末３０の解凍装置３６は追加パケット・タイムの間待機を余儀なくされる。“ｆ（ｉ，ｊ）”関数が単に２つの１次差を連結するにすぎない“アペンド”関数である場合、待機は本質的なことではないという点に留意されたい。
【００３９】
ｆ（ｉ，ｊ）が“アペンド”関数でない関数の場合であって、かつ、後続パケットｐ（ｎ＋２）の着信が成功したと仮定すると、受信側端末３０の解凍装置３６は（ｘ（ｎ＋１）とｘ（ｎ＋２）内の）共通入力ｘ（ｎ＋１）を復号化することができる。ｘ（ｎ＋１）が既知であるため、受信側端末３０の解凍装置３６はデルタ・タイムスタンプＸｎ並びにｘ（ｎ＋２）の計算を行うことも可能となる。図４Ｂに図示のように、フィールド情報の再構成が成功するまで、受信側端末３０の解凍装置３６は追加パケットの着信を待機しなければならない。この待機時間は、同様に、バースティなパケットの紛失が生じる場合と同じで（かつ一定）ある。
【００４０】
図５Ａ〜５Ｄは、図４Ａ〜４Ｂに図示の発信側端末２０の圧縮装置２６、及び、受信側端末３０の解凍装置３６の機能に従うデータ・パケットの様々なパケット・ヘッダ・フォーマットを例示する図である。これらのパケット・ヘッダ・フォーマットはｆ（ｉ，ｊ）が“アペンド”関数であると仮定して示されるものである。特に、図５Ａは２次（ＳＯ）差がゼロの場合のデータ・パケットのヘッダ・フォーマットを例示する図である。データ・パケット１００のヘッダ・セグメント１２０（図２Ａを参照）には、（ＲＦＣ２５０８に記載のものと同じであり、セルラ方式ネットワークなどのような或る種のネットワークでは暗黙のうちに了解され、オプションとする場合もある）コンテキスト識別子（ＩＤ）フィールドと、４ビット・シーケンス番号フィールドとを含めてもよい。図５Ａに示されるヘッダ・フォーマットは、２次（ＳＯ）差がゼロのとき、ＲＦＣ２５０８に記載の方法で発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ通常伝送される。
【００４１】
図５Ｂは、パケット“ｎ”の２次（ＳＯ）差がノンゼロ（ＮＯＮＪＥＮＤ）である場合のデータ・パケットのヘッダ・フォーマットを例示する図である。図５Ｂに図示のように、データ・パケット１００のヘッダ・セグメント１２０は、４ビット・コンテキスト識別子（ＩＤ）フィールドと、パケット“ｎ”の４ビット・シーケンス番号（ｎ）フィールドと、（ＲＴＰ圧縮ヘッダ、フル・ヘッダなどの）パケットタイプを特定する３ビット・パケットタイプ・フィールドと、伝送中の１次（ＦＯ）差がノンゼロの２次（ＳＯ）差を持つパケットについての差であるか、あるいは、該パケットの後続パケットについての差であるかを示す１ビット再転送（ＲｅＴＸ＝０）ビットと、変化したフィールドを特定する、ＲＦＣ２５０８に記載のような４ビットの組合せ（ＭＳＴＩ：マーカービット、シーケンス番号、タイム・スタンプ、ＩＰ−ＩＤ）フィールドと、ノンゼロの２次（ＳＯ）差を持つＲＴＰフィールドの１次（ＦＯ）差を含む可変長フィールドと、を含むものであってもよい。例えば、タイム・スタンプ（Ｔ＝１）が図４Ａに図示されているように変化したとき、図５Ｂに図示のようなヘッダ・フォーマットは、発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ伝送される。
【００４２】
図５Ｃは、図５Ｂに図示の、（パケット“ｎ＋１”などの）パケット“ｎ”に後続するパケット内の一次（ＦＯ）差を反復する際のヘッダ・フォーマットを例示する。図５Ｃに図示のように、データ・パケット１００のヘッダ・セグメント１２０は、コンテキスト識別子（ＩＤ）フィールドと、パケット“ｎ＋１”のシーケンス番号（ｎ＋１）フィールドと、（ＲＴＰ圧縮ヘッダ、フル・ヘッダなどの）パケットタイプを特定するパケットタイプ・フィールドと、伝送中の１次（ＦＯ）差がノンゼロの２次（ＳＯ）差を持つパケットについての差であるか、あるいは、該パケットの後続パケットについての差であるかを示す再転送（ＲｅＴＸ＝１）ビットと、変化したフィールドを特定するＲＦＣ２５０８に記載のようなＭＳＴＩフィールドと、パケット“ｎ”のシーケンス番号（ｎ）フィールドと、パケット“ｎ”のＲＴＰフィールドの１次（ＦＯ）差を示す可変長フィールドと、を含むものであってもよい。例えば、タイム・スタンプ（Ｔ＝０）が図４Ａと４Ｂに図示されているように変化しなかったとき、図５Ｂに図示のようなヘッダ・フォーマットは、次のパケット（ｎ＋１）または（ｎ＋２）との関連で、発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ伝送される。
【００４３】
図５Ｄは、パケット“ｎ”の１次（ＦＯ）差の通信中、パケット“ｎ＋ｋ”（または図４Ｂを参照して説明したように“ｎ＋１”）の２次（ＳＯ）差がノンゼロである場合のヘッダ・フォーマットを例示する図である（図５Ｂと５Ｃの組合せなど）。図５Ｄに図示のように、データ・パケット１００のヘッダ・セグメント１２０は、コンテキスト識別子（ＩＤ）フィールドと、パケット“ｎ＋ｋ”のシーケンス番号（ｎ＋ｋ）フィールド（または図４Ｂを参照して説明したように、パケット“ｎ＋１”の“ｎ＋１”フィールド）と、（ＲＴＰ圧縮ヘッダ、フル・ヘッダなどの）パケットタイプを特定するパケットタイプ・フィールドと、伝送中の１次（ＦＯ）差がノンゼロの２次（ＳＯ）差を持つパケット“ｎ＋ｋ”（または図４Ｂを参照して説明したように、“ｎ＋１”）についての差であること、あるいは、該パケットの後続パケットについての差であることを示す再転送（ＲｅＴＸ＝０）ビットと、変化したフィールドを特定するＲＦＣ２５０８に記載のような、ビット組合せ（ＭＳＴＩ）フィールドと、パケット（ｎ＋ｋ）（または図４Ｂを参照して説明したようにパケット“ｎ＋１”）についての１次（ＦＯ）差を示すフィールドと、パケット“ｎ”のシーケンス番号（ｎ）フィールドと、パケット“ｎ”のタイプを特定する別のパケットタイプ・フィールドと、ノンゼロの２次（ＳＯ）差を持つパケット“ｎ”のフィールドであることを示す再転送（ＲｘＴｘ＝１）ビットと、変化したフィールドを特定する、ＲＦＣ２５０８に記載されているような別のビット組合せ（ＭＳＴＩ）フィールドと、パケット（ｎ）の１次（ＦＯ）差を示すフィールドと、を含むものであってもよい。例えば、図４Ｂに図示のように、タイム・スタンプ（Ｔ＝１）が変化したとき、図５Ｄに図示のようなヘッダ・フォーマットは、次のパケット（ｎ＋１）と関連して発信側端末２０の圧縮装置２６から受信側端末３０の解凍装置３６へ伝送される。
【００４４】
前述したように、図１に図示の発信側端末２０と受信側端末３０は単に例示のデータ・ネットワークとして設けられるものである。すべてのタイプのデータ・ネットワークで任意の数の端末装置、交換機、リンクから成る多種多様な実現例及び構成例が可能である。例えば、ヘッダ圧縮用として設けられたヘッダ圧縮メカニズムを含む、発信側端末と受信側端末から成るこのようなデータ・ネットワークの１つの推奨利用実現例として、図６に図示のようなボイス・オーバーＩＰとテレビ会議のようなリアルタイム・アプリケーション用セルラ方式ネットワークを挙げることもできよう。帯域限定リンク１０は、セルラ通信を行うための、ＩＰネットワーク１２とアクセス・ネットワーク・インフラ・ストラクチャＡＮＩ１４とＡＮＩ１６との組合せとすることも可能である。発信側端末２０は、ＲＴＰ／ＵＤＰ／ＩＰを実行し、ＩＰネットワーク１２及びＡＮＩ１４と１６を介する伝送用のパケット化された音声サンプルをＲＴＰパケットで供給するホストＰＣまたは同種のものであってもよい。受信側端末３０は、ＡＮＩ１４を備えたセルラ通信用の移動端末装置であってもよい。各端末２０と３０はＲＴＰパケット用の発信側端末か受信側端末のいずれかとすることができる。
【００４５】
端末２０には、（例えばＩＰアドレス、ポート番号などを含む）この端末をＲＴＰパケット用の発信元または宛先のいずれかとして特定するＲＴＰエンドポイント２２を含むことも可能である。ＩＰネットワークが例として示されているが、代わりに別のタイプのパケット交換方式ネットワークや同種のネットワークの利用も可能である。また端末２０には、タイム・スタンプ生成用ローカル・タイマ２４も含まれる。
【００４６】
アクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）１４をＩＰネットワーク１２と接続してもよい。無線周波数（ＲＦ）リンク５０を介して移動端末装置３０をＡＮＩ１４と結合してもよい。ＲＦリンク５０には（端末３０からＡＮＩ１４への）上り回線５２と（ＡＮＩ１４から端末３０への）下り回線５４とが含まれる。ＡＮＩ１４は、ある領域で、１以上の無線（すなわち無線周波数）端末（端末３０を含む）をＩＰネットワーク１２とインターフェースすることも可能である。これには（ＩＰネットワーク１２から出力される）有線信号と、（端末３０へまたは端末３０から出力される）無線すなわちＲＦ信号との間の変換が含まれる。したがって、ＩＰネットワーク１２から受信したＲＴＰパケットをＲＦリンク５０を介して移動端末装置３０へ伝送することがＡＮＩ１４により可能になり、さらに、ＩＰネットワーク１２を介して移動端末装置３０から端末２０などのような別の端へＲＴＰパケットの伝送を行うことが可能となる。
【００４７】
本発明の実施例によれば、ＡＮＩ１４には、各々がタイマ４２を含む１以上のＡＮＩアダプタ（ＡＮＩ＿ＡＤ）４０を含むことが望ましい。ＲＦＣ２５０８に類似したヘッダ圧縮処理を行うための、本発明の実施例に従うロバストなＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式であるが、図１〜４を参照して説明したように、紛失の多い、エラーし易いネットワークで使用する際、パケットの紛失やエラーの発生時にロバスト性を処理するＩＰ／ＵＤＰ／ＲＴＰヘッダ圧縮方式を用いて各ＡＮＩ＿ＡＤ４０が構成され、実現されて、ヘッダの正しい再構成を行うことが可能となる。ＡＮＩ＿ＡＤ４０は（下り回線の伝送に先行して）ヘッダ圧縮を実行し、次いで（上り回線の伝送後）解凍を実行することが可能である。ＩＰネットワーク１２から受信したＲＴＰパケット用ヘッダ（またはタイム・スタンプのような１以上のヘッダ・フィールド）は、下り回線５４を介する移動端末装置３０への伝送に先行してＡＮＩ＿ＡＤ４０により圧縮され、移動端末装置３０から受信したパケット・ヘッダはＩＰネットワーク１２への伝送前にＡＮＩ＿ＡＤ４０により解凍される。したがって、各ＡＮＩ＿ＡＤ４０はヘッダ圧縮装置／解凍装置と考えることもできる。また各ＡＮＩ＿ＡＤ４０は、ＩＰネットワーク１２とつながる領域の範囲内の特定のエリアまたは異なるエリア内に位置する端末をインターフェースすることも可能である。
【００４８】
ＡＮＩ＿ＡＤ４０は、タイマ・ベースの解凍手法を実現するためのタイマ４２を含むことも可能である。また、ＩＰネットワーク１２とつながる追加領域に位置する別の端末をインターフェースするために追加のＡＮＩを設けることも可能である。
【００４９】
移動端末装置３０は、ＲＴＰパケットの発信元及び／又は宛先（受信装置）であるＲＴＰエンドポイント１３２を含むことも可能である。移動端末装置３０は、（上り回線５２で伝送されるパケットに対する）ヘッダ圧縮、及び、（下り回線５４を介して受信されるパケットに対する）解凍を実行するターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）３６を含むことも可能である。したがって、ターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）は、ＡＮＩ＿ＡＤと類似のヘッダ圧縮装置／解凍装置と考えることもできる。
【００５０】
また、ターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）３６にはカレント・ヘッダのＲＴＰタイム・スタンプの近似値（または推定値）を計算するタイマ３４も含まれる。次いで、ターミナル・アダプタ（ｔｅｒｍ＿ＡＤ）３６は、ＲＴＰヘッダ内の追加情報を利用してタイム・スタンプの近似値の微調整または補正を行う。ローカル・タイマ及び圧縮されたタイム・スタンプを利用して、各ＲＴＰヘッダの正しいタイム・スタンプの再生が可能となる。各々がそれ自身のＲＴＰエンドポイント、ターミナル・アダプタ及びタイマを含む別の端末を設けることも可能である。
【００５１】
上述のように、本発明は、信頼できないネットワークが存在する場合にロバストなＩＰヘッダ圧縮を達成するためのロバストなヘッダ圧縮方式を好適に提供するものである。この提案された方式は、パケット紛失に対して必要な所望の保護に基づいて弾力的に適用することも可能である。奇数ビットの保護（但しこの場合ペイロードに対してヘッダへの保護）を行う、例えば音声符号化時などに利用される手法と類似の手法を用いることによりビット誤りに対する保護を行うことも可能である。
【００５２】
本発明の推奨実施例と考えられるものを例示し、説明したが、様々な変更及び修正を行うことも可能であること、及び、本発明の真の範囲から逸脱することなく本発明の要素の代わりの均等物を用いることも可能であることを当業者は理解するであろう。さらに、多くの修正を行って、本発明の中心となる範囲から逸脱することなく、特定の状況を本発明の教示に適合させることも可能である。したがって、本発明の実行のために熟慮されたベストモードとして開示した特定の実施例に限定されるものではなく、本発明は添付の請求項の範囲に属するすべての実施例を含むものであることが意図される。
【図面の簡単な説明】
【図１】本発明の実施例に従う、帯域限定リンクを介してヘッダ圧縮及びデータ通信を行うために設けられたヘッダ圧縮メカニズムを含む、発信側端末と受信側端末とからなる例示データ・ネットワークを示す。
【図２Ａ】本発明の実施例に従う、例示データ・ネットワークで使用する例示データ・パケットを示す。
【図２Ｂ】本発明の実施例に従う、例示データ・ネットワークで使用する例示データ・パケットを示す。
【図３】本発明の実施例に従う、未圧縮フォーマットでのデータ・パケットの例示ＲＴＰヘッダ・セグメントを示す。
【図４Ａ】本発明の実施例に従う、変化するフィールドのための、発信側端末の圧縮装置と受信側端末の解凍装置の機能を例示する。
【図４Ｂ】本発明の実施例に従う、変化するフィールドのための、発信側端末の圧縮装置と受信側端末の解凍装置の機能を例示する。
【図５Ａ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図５Ｂ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図５Ｃ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図５Ｄ】本発明の実施例に従う、データ・パケットの様々なパケット・ヘッダ・フォーマットを例示する。
【図６】本発明の実施例に従う、ヘッダ圧縮用、並びに、セルラ・リンクを介するデータ通信用として設けられたヘッダ圧縮メカニズムを含む、発信側端末と受信側端末とからなるＩＰベースのネットワークの１つの推奨利用実現例を例示する。
【符号の説明】
１０ 帯域限定リンク（ＩＰ）
２０ 発信側端末
２２ ホスト
２４ ＮＩＣ
２６ 圧縮装置／解凍装置
３０ 受信側端末
３２ ホスト
３４ ＮＩＣ
３６ 圧縮装置／解凍装置
Claims (33)
- データ・ネットワークにおいて、
帯域限定リンクを介して伝送されるデータ・パケットのヘッダの圧縮／解凍を行うヘッダ圧縮／解凍装置を具備する第１のノードと、
前記帯域限定リンクを介して伝送されるデータ・パケットのヘッダの圧縮／解凍を行うヘッダ圧縮／解凍装置を具備する第２のノードと、を具備し、
変化しないフィールドのコンテキスト状態を最初に確立し、さらに、前記第１のノードと前記第２のノードのうちの一方の圧縮装置と、前記第１のノードと前記第２のノードのうちの他方の解凍装置との間の変化するフィールドの１次差を確立し、次いで、任意のフィールドの２次差がノンゼロであるとき、新しい１次差と共にノンゼロの２次差を持つ特定パケットを、上記新しい１次差が受信された旨の肯定の確認が上記圧縮装置により受信されるまで、もしくは、所定期間の期限切れまで、上記新しい１次差を持つ当該後続パケットと共に伝送することにより、ヘッダの圧縮と再構成とを行うことを特徴とするデータ・ネットワーク。 - 請求項１に記載のデータ・ネットワークにおいて、データ・パケットのラウンド・トリップ時間とパケット間分離時間との商として前記所定期間を設定することを特徴とするデータ・ネットワーク。
- 請求項１に記載のデータ・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、ダイアルアップ・モデムのような低速回線に対応することを特徴とするデータ・ネットワーク。
- 請求項１に記載のデータ・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、セルラ・リンクに対応することを特徴とするデータ・ネットワーク。
- 請求項１に記載のデータ・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、インターネット・サービス・プロバイダ（ＩＳＰ）のＩＰベースのネットワークと、インターネットと、例えば公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）、及び、前記第１のノードと前記第２のノードとの間の通信を可能にするその他のアクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）などを含む様々な発信側ネットワークと着信側ネットワークと、に対応することを特徴とするデータ・ネットワーク。
- 請求項１に記載のデータ・ネットワークにおいて、ノンゼロの２次差を持つ上記対応フィールドが上記１次差の通信時間中再び変化したとき、上記圧縮装置が、上記解凍装置へ伝送するために上記新しい１次差を上記元の１次差と組み合わせることを特徴とするデータ・ネットワーク。
- 請求項１に記載のデータ・ネットワークにおいて、前記データ・パケットの各々が、タイム・スタンプとパケット・シーケンス番号とを有する少なくともヘッダ・フィールドを含むことを特徴とするデータ・ネットワーク。
- 請求項７に記載のデータ・ネットワークにおいて、前記ヘッダ圧縮メカニズムを実行して、上記パケットの紛失やエラーの発生時に前記データ・パケットのヘッダを正しく再構成するようにすることを特徴とするデータ・ネットワーク。
- 請求項７に記載のデータ・ネットワークにおいて、前記ヘッダが、上記インターネットでのリアルタイム通信のために、及び、ボイス・オーバーＩＰとテレビ会議などのようなアプリケーションのために用いられるＩＰ／ＵＤＰ／ＲＴＰヘッダであることを特徴とするデータ・ネットワーク。
- 請求項８に記載のデータ・ネットワークにおいて、上記コンテキスト状態が確立された後、上記対応する２次差がノンゼロでない限り、変化するフィールドの上記１次差の伝送を終了するために前記ヘッダ圧縮メカニズムを実行することを特徴とするデータ・ネットワーク。
- パケット・ネットワークにおいて、
各パケットがヘッダ・フィールドを含む複数のパケットを供給する発信側端末と、
受信側端末と、
上記発信側端末と上記受信側端末との間で接続を行う帯域限定リンクと、を具備し、
上記発信側端末または上記受信側端末の少なくとも一方のネットワーク・インターフェース・コントローラが、ヘッダの圧縮と再構成を行うための、該コントローラにインストールされたヘッダ圧縮メカニズムを具備し、前記ヘッダ圧縮メカニズムは、変化しないフィールドのコンテキスト状態、並びに、変化するフィールドの１次差を確立し、次いで、任意のフィールドの２次差がノンゼロであるとき、新しい１次差と共にノンゼロの２次差を持つ特定パケットを、上記新しい１次差が受信された旨を示す肯定の確認が受信されるまで、もしくは、所定期間の期限切れまで、上記新しい１次差を持つ当該後続パケットと共に伝送することを特徴とするパケット・ネットワーク。 - 請求項１１に記載のパケット・ネットワークにおいて、データ・パケットのラウンド・トリップ時間とパケット間分離時間との商として前記所定期間を設定することを特徴とするパケット・ネットワーク。
- 請求項１１に記載のパケット・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、ダイアルアップ・モデムのような低速回線に対応することを特徴とするパケット・ネットワーク。
- 請求項１１に記載のパケット・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、セルラ・リンクに対応することを特徴とするパケット・ネットワーク。
- 請求項１１に記載のパケット・ネットワークにおいて、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、インターネット・サービス・プロバイダ（ＩＳＰ）のＩＰベースのネットワークと、インターネットと、例えば公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）、及び、前記第１のノードと前記第２のノードとの間の通信を可能にするその他のアクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）などを含む様々な発信側ネットワークと着信側ネットワークと、に対応することを特徴とするパケット・ネットワーク。
- 請求項１１に記載のパケット・ネットワークにおいて、ノンゼロの２次差を持つ上記対応フィールドが上記１次差の通信時間中再び変化したとき、上記圧縮装置が、上記解凍装置へ伝送するために上記新しい１次差を上記元の１次差と組み合わせることを特徴とするパケット・ネットワーク。
- 請求項１１に記載のパケット・ネットワークにおいて、前記ヘッダ・フィールドがタイム・スタンプとパケット・シーケンス番号とを含むことを特徴とするパケット・ネットワーク。
- 請求項１１に記載のパケット・ネットワークにおいて、上記パケットの紛失やエラーの発生時に前記パケットのヘッダを正しく再構成するために前記ヘッダ圧縮メカニズムを実行することを特徴とするパケット・ネットワーク。
- 請求項１１に記載のパケット・ネットワークにおいて、前記ヘッダが、上記インターネットでのリアルタイム通信のために、及び、ボイス・オーバーＩＰとテレビ会議などのようなアプリケーションのために用いられるＩＰ／ＵＤＰ／ＲＴＰヘッダであることを特徴とするパケット・ネットワーク。
- 請求項１１に記載のパケット・ネットワークにおいて、上記コンテキスト状態が確立された後、上記対応する２次差がノンゼロでない限り、変化するフィールドの上記１次差の伝送を終了するために前記ヘッダ圧縮メカニズムを実行することを特徴とするパケット・ネットワーク。
- 信頼できないネットワークが存在する場合に、圧縮装置と解凍装置との間でロバストなヘッダ圧縮を達成する方法において、
前記解凍装置が前記データ・パケットの変化しないフィールドのコンテキスト状態、並びに、変化するフィールドの１次差を確立するまで、帯域限定リンクを介して前記圧縮装置から前記解凍装置へデータ・パケットのヘッダを伝送するステップと、
前記圧縮装置と前記解凍装置との間に上記コンテキスト状態が確立されたとき、任意のフィールドの２次差がノンゼロであるかどうかを決定するステップと、
任意のフィールドの２次差がノンゼロであるとき、新しい１次差と共にノンゼロの２次差を持つ特定パケットを、上記新しい１次差が受信された旨を示す肯定の確認が受信されるまで、もしくは、所定期間の期限切れまで、上記新しい１次差を持つ当該後続パケットと共に伝送するステップと、を有することを特徴とする方法。 - 請求項２１に記載の方法において、データ・パケットのラウンド・トリップ時間とパケット間分離時間との積として前記所定期間を設定することを特徴とする方法。
- 請求項２１に記載の方法において、前記圧縮装置と前記解凍装置とを接続するために設けた前記帯域限定リンクが、ダイアルアップ・モデムのような低速回線に対応することを特徴とする方法。
- 請求項２１に記載の方法において、前記圧縮装置と前記解凍装置とを接続するために設けた前記帯域限定リンクが、セルラ・リンクに対応することを特徴とする方法。
- 請求項２１に記載の方法において、前記圧縮装置と前記解凍装置とを接続するために設けた前記帯域限定リンクが、インターネット・サービス・プロバイダ（ＩＳＰ）のＩＰベースのネットワークと、インターネットと、例えば公衆電話交換網（ＰＳＴＮ）、総合デジタル通信網（ＩＳＤＮ）、及び、前記第１のノードと前記第２のノードとの間の通信を可能にするその他のアクセス・ネットワーク・インフラ・ストラクチャ（ＡＮＩ）などを含む様々な発信側ネットワークと着信側ネットワークと、に対応することを特徴とする方法。
- 請求項２１に記載の方法において、ノンゼロの２次差を持つ上記対応フィールドが上記１次差の通信時間中再び変化したとき、上記解凍装置へ伝送するために、上記新しい１次差を上記元の１次差と組み合わせることを特徴とする方法。
- 請求項２１に記載の方法において、前記データ・パケットの各々がタイム・スタンプとパケット・シーケンス番号と有するヘッダ・フィールドを含むことを特徴とする方法。
- 請求項２１に記載の方法において、前記ヘッダが、上記インターネットでのリアルタイム通信のために、及び、ボイス・オーバーＩＰとテレビ会議などのようなアプリケーションのために用いられるＩＰ／ＵＤＰ／ＲＴＰヘッダであることを特徴とする方法。
- ホスト可読媒体であって、圧縮／解凍装置を含むホスト・システムにより命令が実行されるとき、
前記解凍装置が前記データ・パケットの変化しないフィールドのコンテキスト状態、並びに、変化するフィールドの１次差を確立するまで、帯域限定リンクを介して前記圧縮装置から前記解凍装置へデータ・パケットのヘッダを伝送するステップと、
前記圧縮装置と前記解凍装置との間に上記コンテキスト状態が確立されたとき、任意のフィールドの２次差がノンゼロであるかどうかを決定するステップと、
任意のフィールドの２次差がノンゼロであるとき、新しい１次差と共にノンゼロの２次差を持つ特定パケットを、上記新しい１次差が受信された旨を示す肯定の確認が受信されるまで、もしくは、所定期間の期限切れまで、上記新しい１次差を持つ当該後続パケットと共に伝送するステップとによって、遠隔システムの圧縮装置と解凍装置との間でロバストなヘッダ圧縮を上記ホスト・システムに行わせる命令を含むことを特徴とするホスト可読媒体。 - 請求項２８に記載のホスト可読媒体において、データ・パケットのラウンド・トリップ時間とパケット間分離時間との商として前記所定期間を設定することを特徴とするホスト可読媒体。
- 請求項２８に記載のホスト可読媒体において、前記第１のノードを前記第２のノードと接続するために設けた前記帯域限定リンクが、低速回線かセルラ・リンクのいずれかに対応することを特徴とするホスト可読媒体。
- 請求項２８に記載のホスト可読媒体において、ノンゼロの２次差を持つ上記対応フィールドが上記１次差の通信時間中再び変化したとき、上記圧縮装置が、上記解凍装置へ伝送するために上記新しい１次差を上記元の１次差と組み合わせることを特徴とするホスト可読媒体。
- 請求項２８に記載のホスト可読媒体において、前記ヘッダ・フィールドが、タイム・スタンプとパケット・シーケンス番号とを含み、上記インターネットでのリアルタイム通信のために、及び、ボイス・オーバーＩＰとテレビ会議などのようなアプリケーションのために用いられるＩＰ／ＵＤＰ／ＲＴＰヘッダであることを特徴とするホスト可読媒体。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/476,205 | 1999-12-30 | ||
| US09/476,205 US6608841B1 (en) | 1999-12-30 | 1999-12-30 | System and method for achieving robust IP/UDP/RTP header compression in the presence of unreliable networks |
| PCT/US2000/035088 WO2001050705A2 (en) | 1999-12-30 | 2000-12-22 | System and method for robust ip/udp/rtp header compression in unreliable networks |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003519965A JP2003519965A (ja) | 2003-06-24 |
| JP3559019B2 true JP3559019B2 (ja) | 2004-08-25 |
Family
ID=23890932
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001550961A Expired - Fee Related JP3559019B2 (ja) | 1999-12-30 | 2000-12-22 | 信頼できないネットワークが存在する場合にロバストなｉｐ／ｕｄｐ／ｒｔｐヘッダ圧縮を達成するシステム及び方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US6608841B1 (ja) |
| EP (1) | EP1243118B1 (ja) |
| JP (1) | JP3559019B2 (ja) |
| AU (1) | AU2912201A (ja) |
| CA (1) | CA2397687C (ja) |
| DE (1) | DE60022391T2 (ja) |
| WO (1) | WO2001050705A2 (ja) |
Families Citing this family (156)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6804211B1 (en) * | 1999-08-03 | 2004-10-12 | Wi-Lan Inc. | Frame structure for an adaptive modulation wireless communication system |
| EP1411700B8 (en) | 1999-08-06 | 2006-08-30 | Matsushita Electric Industrial Co., Ltd. | Data transmission method, data transmission apparatus, and data reception apparatus |
| US7058728B1 (en) * | 1999-10-29 | 2006-06-06 | Nokia Corporation | Method and apparatus for initiating compression of headers of packets and refreshing the context related to the packets |
| JP3423930B2 (ja) * | 1999-12-27 | 2003-07-07 | 富士通株式会社 | バンプ形成方法、電子部品、および半田ペースト |
| US6839339B1 (en) * | 2000-02-02 | 2005-01-04 | Lucent Technologies Inc. | Header compression for general packet radio service tunneling protocol (GTP)-encapsulated packets |
| EP1146713B1 (en) * | 2000-03-03 | 2005-04-27 | NTT DoCoMo, Inc. | Method and apparatus for packet transmission with header compression |
| US6999429B1 (en) * | 2000-03-03 | 2006-02-14 | Telefonaktiebolaget Lm Ericsson | Access technology integrated header compression |
| US6970476B1 (en) * | 2000-03-07 | 2005-11-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Efficient header compression context update in packet communications |
| US20020001315A1 (en) * | 2000-03-21 | 2002-01-03 | Tran Hung V. | Method and apparatus for compressing IP/UDP/RTP headers in a lossy environment |
| US7539130B2 (en) * | 2000-03-28 | 2009-05-26 | Nokia Corporation | Method and system for transmitting and receiving packets |
| US20020031103A1 (en) * | 2000-05-02 | 2002-03-14 | Globalstar L.P. | User terminal employing quality of service path determination and bandwidth saving mode for a satellite ISP system using non-geosynchronous orbit satellites |
| US20010053134A1 (en) * | 2000-06-16 | 2001-12-20 | Fillebrown Lisa A. | Router for a personal wireless network |
| US8386557B2 (en) * | 2000-06-16 | 2013-02-26 | Enfora, Inc. | Method for supporting a personal wireless network |
| US20010054060A1 (en) * | 2000-06-16 | 2001-12-20 | Fillebrown Lisa A. | Personal wireless network |
| FR2810484B1 (fr) * | 2000-06-19 | 2002-09-06 | Cit Alcatel | Procede de gestion et agencement de conference pour systeme de communication comportant des terminaux d'usager communiquant sous protocole ip |
| US7136577B1 (en) * | 2000-06-29 | 2006-11-14 | Tandberg Telecom As | RTP-formated media clips |
| CN100471195C (zh) * | 2000-07-25 | 2009-03-18 | 诺基亚西门子通信有限责任两合公司 | 用于网络协议的报头压缩及解压方法和适于该方法的装置 |
| US20020018471A1 (en) * | 2000-08-09 | 2002-02-14 | Lucid V.O.N. Ltd. | Method and system for voice-over-IP communication |
| US7002993B1 (en) * | 2000-08-18 | 2006-02-21 | Juniper Networks, Inc. | Method and apparatus providing media aggregation in a packet-switched network |
| US7586899B1 (en) | 2000-08-18 | 2009-09-08 | Juniper Networks, Inc. | Methods and apparatus providing an overlay network for voice over internet protocol applications |
| US7209473B1 (en) | 2000-08-18 | 2007-04-24 | Juniper Networks, Inc. | Method and apparatus for monitoring and processing voice over internet protocol packets |
| JP3889919B2 (ja) * | 2000-08-31 | 2007-03-07 | 株式会社日立製作所 | 情報配信方法、情報受信方法、情報配信システム、情報配信装置、受信端末及び記憶媒体 |
| EP1187416B1 (en) * | 2000-09-07 | 2005-03-23 | Matsushita Electric Industrial Co., Ltd. | Method and apparatus for transmitting data packets |
| EP1187417B1 (en) * | 2000-09-07 | 2005-05-11 | Matsushita Electric Industrial Co., Ltd. | Method and apparatus for transmitting data packets |
| JP3323483B2 (ja) * | 2000-09-12 | 2002-09-09 | 松下電器産業株式会社 | パケット送信装置およびパケット伝送方法 |
| US6845105B1 (en) * | 2000-09-28 | 2005-01-18 | Telefonaktiebolaget Lm Ericsson | Method and apparatus for maintaining sequence numbering in header compressed packets |
| GB2367459A (en) | 2000-09-28 | 2002-04-03 | Roke Manor Research | Method of compressing data packets |
| US6967964B1 (en) * | 2000-10-03 | 2005-11-22 | Telefonaktiebolaget Lm Ericsson (Publ) | Context identification using header compression key at link layer |
| US7451235B2 (en) * | 2000-10-11 | 2008-11-11 | Broadcom Corporation | Dynamic delta encoding for cable modem header suppression |
| US7756032B2 (en) | 2000-10-17 | 2010-07-13 | Avaya Inc. | Method and apparatus for communicating data within measurement traffic |
| US7720959B2 (en) | 2000-10-17 | 2010-05-18 | Avaya Inc. | Method and apparatus for characterizing the quality of a network path |
| AU2002213287A1 (en) | 2000-10-17 | 2002-04-29 | Routescience Technologies Inc | Method and apparatus for performance and cost optimization in an internetwork |
| US7349994B2 (en) | 2000-10-17 | 2008-03-25 | Avaya Technology Corp. | Method and apparatus for coordinating routing parameters via a back-channel communication medium |
| US7406539B2 (en) * | 2000-10-17 | 2008-07-29 | Avaya Technology Corp. | Method and apparatus for performance and cost optimization in an internetwork |
| US7080161B2 (en) | 2000-10-17 | 2006-07-18 | Avaya Technology Corp. | Routing information exchange |
| US8023421B2 (en) | 2002-07-25 | 2011-09-20 | Avaya Inc. | Method and apparatus for the assessment and optimization of network traffic |
| US7363367B2 (en) | 2000-10-17 | 2008-04-22 | Avaya Technology Corp. | Systems and methods for robust, real-time measurement of network performance |
| US7289433B1 (en) * | 2000-10-24 | 2007-10-30 | Nortel Networks Limited | Method and system for providing robust connections in networking applications |
| US7069495B2 (en) * | 2000-10-30 | 2006-06-27 | Telefonaktiebolaget Lm Ericsson (Publ) | Bit error resilience for an internet protocol stack |
| CA2825592C (en) | 2000-11-15 | 2016-04-19 | An Chen | Improved frame structure for communication system using adaptive modulation |
| US7046672B2 (en) * | 2000-11-16 | 2006-05-16 | Microsoft Corporation | Robust, inferentially synchronized transmission of compressed transport-layer-protocol headers |
| US8009667B1 (en) * | 2001-01-16 | 2011-08-30 | Wi—LAN, Inc. | Packing source data packets into transporting packets with fragmentation |
| EP1233595A1 (de) * | 2001-02-15 | 2002-08-21 | Siemens Aktiengesellschaft | Bearbeitung einer IP-Adresse auf Systemebene |
| US8121296B2 (en) | 2001-03-28 | 2012-02-21 | Qualcomm Incorporated | Method and apparatus for security in a data processing system |
| US7693508B2 (en) * | 2001-03-28 | 2010-04-06 | Qualcomm Incorporated | Method and apparatus for broadcast signaling in a wireless communication system |
| US9100457B2 (en) | 2001-03-28 | 2015-08-04 | Qualcomm Incorporated | Method and apparatus for transmission framing in a wireless communication system |
| US8077679B2 (en) | 2001-03-28 | 2011-12-13 | Qualcomm Incorporated | Method and apparatus for providing protocol options in a wireless communication system |
| US7031666B2 (en) * | 2001-03-28 | 2006-04-18 | Qualcomm Incorporated. | Method and apparatus for header compression in a wireless communication system |
| SE0101295D0 (sv) | 2001-04-10 | 2001-04-10 | Ericsson Telefon Ab L M | A method and network for delivering streaming data |
| US20020191691A1 (en) * | 2001-05-10 | 2002-12-19 | Holborow Clive Eric | Payload header suppression including removal of fields that vary in known patterns |
| JP3600189B2 (ja) * | 2001-06-19 | 2004-12-08 | 松下電器産業株式会社 | パケット送受信装置及びパケット伝送方法 |
| US7170896B2 (en) * | 2001-06-20 | 2007-01-30 | Motorola, Inc. | Communication infrastructure and method to preserve communication link bandwidth in a packet communication session |
| US20030028611A1 (en) * | 2001-07-23 | 2003-02-06 | Kenny John G. | Multi-task, multi-location networking system |
| US7362707B2 (en) * | 2001-07-23 | 2008-04-22 | Acme Packet, Inc. | System and method for determining flow quality statistics for real-time transport protocol data flows |
| CN1225883C (zh) * | 2001-07-27 | 2005-11-02 | 华为技术有限公司 | 一种节约带宽的语音传送方法 |
| US8837471B2 (en) * | 2001-08-01 | 2014-09-16 | Certicom Corp. | Disabling header compression over point-to-point protocol (PPP) |
| US7010613B2 (en) * | 2001-09-07 | 2006-03-07 | Intel Corporation | Methods and apparatus for reducing frame overhead on local area networks |
| US6954460B2 (en) | 2001-10-05 | 2005-10-11 | Ericsson Inc. | Method and apparatus for compressing packet headers |
| US7352868B2 (en) | 2001-10-09 | 2008-04-01 | Philip Hawkes | Method and apparatus for security in a data processing system |
| US7649829B2 (en) | 2001-10-12 | 2010-01-19 | Qualcomm Incorporated | Method and system for reduction of decoding complexity in a communication system |
| JP2005509381A (ja) * | 2001-11-06 | 2005-04-07 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | ヘッダ圧縮を行う無線通信装置 |
| US7088739B2 (en) * | 2001-11-09 | 2006-08-08 | Ericsson Inc. | Method and apparatus for creating a packet using a digital signal processor |
| EP1968277B1 (en) * | 2001-11-24 | 2011-03-16 | LG Electronics, Inc. | Method for transmitting packet data in compressed form in a communication system |
| FI113324B (fi) * | 2001-12-21 | 2004-03-31 | Nokia Corp | Parannettu laitejärjestely, päätelaite ja menetelmä audiosignaalin siirrossa pakettikytkentäisessä tiedonsiirtoverkossa |
| JP2003338830A (ja) * | 2002-03-12 | 2003-11-28 | Matsushita Electric Ind Co Ltd | メディア送信方法、メディア受信方法、メディア送信装置及びメディア受信装置 |
| US7106733B2 (en) * | 2002-03-20 | 2006-09-12 | Intel Corporation | Method and apparatus for network header compression |
| GB2386805B (en) * | 2002-03-22 | 2004-05-26 | Roke Manor Research | Apparatus and method for compression of a signalling portion of a communications packet |
| US8619592B2 (en) * | 2002-06-12 | 2013-12-31 | Telefonaktiebolaget L M Ericsson (Publ) | Method and apparatus for increased internet protocol (IP) headers compression performance by reporting cause of missing packets |
| KR100497357B1 (ko) * | 2002-06-26 | 2005-06-23 | 삼성전자주식회사 | 인터넷 프로토콜 기반 네트워크 환경에 있어서 헤더 압축및 패킷 다중화 장치와 그 방법 |
| US7920590B2 (en) * | 2002-07-12 | 2011-04-05 | Spyder Navigations L.L.C. | Wireless communications system having built-in packet data compression and support for enabling non-standard features between network elements |
| JP4317403B2 (ja) * | 2002-08-09 | 2009-08-19 | パナソニック株式会社 | ヘッダ圧縮装置及びヘッダ圧縮方法 |
| KR100889864B1 (ko) * | 2002-08-14 | 2009-03-24 | 엘지전자 주식회사 | 멀티미디어 데이터의 압축 전송 방법 및 시스템 |
| KR100884956B1 (ko) | 2002-08-14 | 2009-02-23 | 엘지전자 주식회사 | 비대칭 양방향 패킷데이터 송수신 방법 및 시스템 |
| JP3792631B2 (ja) | 2002-09-30 | 2006-07-05 | Ｎｅｃインフロンティア株式会社 | パケット伝送方法及び装置、それを用いた基地局装置、無線ｌａｎ端末装置、無線ｌａｎシステム |
| TWI250724B (en) * | 2002-10-11 | 2006-03-01 | Ericsson Telefon Ab L M | Method and communication system for packeting messaging, and header compressor unit |
| US7599655B2 (en) | 2003-01-02 | 2009-10-06 | Qualcomm Incorporated | Method and apparatus for broadcast services in a communication system |
| US20040136476A1 (en) * | 2003-01-10 | 2004-07-15 | Rosen Eric C. | Method and apparatus for compressing header information for short data burst messaging |
| US7333479B2 (en) * | 2003-06-30 | 2008-02-19 | Nokia Corporation | RFID system with packetized data storage in a mobile environment: methods, systems and program products |
| US8098818B2 (en) | 2003-07-07 | 2012-01-17 | Qualcomm Incorporated | Secure registration for a multicast-broadcast-multimedia system (MBMS) |
| US7065087B2 (en) * | 2003-07-08 | 2006-06-20 | Cisco Technology, Inc. | Performing compression of user datagram protocol packets |
| CN1802567B (zh) * | 2003-07-08 | 2012-04-25 | 思科技术公司 | 用于对用户数据报协议分组执行压缩的方法和系统 |
| US7317724B2 (en) * | 2003-07-08 | 2008-01-08 | Cisco Technology, Inc. | Performing compression of user datagram protocol packets |
| US8718279B2 (en) | 2003-07-08 | 2014-05-06 | Qualcomm Incorporated | Apparatus and method for a secure broadcast system |
| KR100594115B1 (ko) * | 2003-07-30 | 2006-06-28 | 삼성전자주식회사 | 패킷 데이터 서비스의 채널 타입 변경에 따른 헤더 압축 컨텍스트 설정 장치 및 방법 |
| US8724803B2 (en) | 2003-09-02 | 2014-05-13 | Qualcomm Incorporated | Method and apparatus for providing authenticated challenges for broadcast-multicast communications in a communication system |
| US8767704B2 (en) * | 2003-10-17 | 2014-07-01 | Nokia Solutions And Networks Oy | Compressing header data |
| US7839852B2 (en) * | 2003-10-30 | 2010-11-23 | Utstarcom (China) Co. Ltd. | Apparatus and method for radio transmission of real-time IP packets using header compression technique |
| US7129853B2 (en) * | 2003-11-18 | 2006-10-31 | Kyocera Wireless Corp. | System and method for remote control of a wireless handset |
| US20050144311A1 (en) * | 2003-12-09 | 2005-06-30 | International Business Machines Corporation | Communications network for transmitting packets of data via a plurality of sequential routers from a transmitting station to a receiving station with packet header coding for maximizing transmission efficiency |
| US7430617B2 (en) * | 2003-12-19 | 2008-09-30 | Nokia Corporation | Method and system for header compression |
| US8327026B1 (en) * | 2004-07-01 | 2012-12-04 | Hewlett-Packard Development Company, L.P. | Method and system for selecting a data compression technique for data transfer through a data network |
| CN100428733C (zh) * | 2004-08-11 | 2008-10-22 | 华为技术有限公司 | 移动通信网络中ip报头压缩的错误恢复方法及装置 |
| CN100407692C (zh) * | 2004-08-11 | 2008-07-30 | 华为技术有限公司 | 一种实现ip头压缩的系统及方法 |
| US7411975B1 (en) | 2004-08-26 | 2008-08-12 | Juniper Networks, Inc. | Multimedia over internet protocol border controller for network-based virtual private networks |
| JP4661373B2 (ja) * | 2004-10-15 | 2011-03-30 | Ｋｄｄｉ株式会社 | 特定メディアデータの破棄を制御する送信装置及び送信プログラム |
| US7680105B2 (en) * | 2004-12-03 | 2010-03-16 | Cisco Technology, Inc. | Voice over internet protocol (VOIP) subcell multiplexing |
| US20060262788A1 (en) * | 2005-05-23 | 2006-11-23 | Broadcom Corporation | Dynamic payload header suppression extensions for IPV6 |
| US8804765B2 (en) * | 2005-06-21 | 2014-08-12 | Optis Wireless Technology, Llc | Dynamic robust header compression |
| US7620870B2 (en) * | 2005-11-22 | 2009-11-17 | Cisco Technology, Inc. | Data compression method and system |
| US7965771B2 (en) | 2006-02-27 | 2011-06-21 | Cisco Technology, Inc. | Method and apparatus for immediate display of multicast IPTV over a bandwidth constrained network |
| US7876695B2 (en) * | 2006-03-07 | 2011-01-25 | Telefonaktiebolaget Lm Ericsson (Publ) | Communication station and method providing flexible compression of data packets |
| US8218654B2 (en) * | 2006-03-08 | 2012-07-10 | Cisco Technology, Inc. | Method for reducing channel change startup delays for multicast digital video streams |
| US9198084B2 (en) | 2006-05-26 | 2015-11-24 | Qualcomm Incorporated | Wireless architecture for a traditional wire-based protocol |
| US8031701B2 (en) | 2006-09-11 | 2011-10-04 | Cisco Technology, Inc. | Retransmission-based stream repair and stream join |
| US20080101421A1 (en) * | 2006-10-30 | 2008-05-01 | Stephen Gordon | Fast audio and angle switching via multiple demux buffers |
| US7937531B2 (en) * | 2007-02-01 | 2011-05-03 | Cisco Technology, Inc. | Regularly occurring write back scheme for cache soft error reduction |
| US8769591B2 (en) | 2007-02-12 | 2014-07-01 | Cisco Technology, Inc. | Fast channel change on a bandwidth constrained network |
| US7940644B2 (en) * | 2007-03-14 | 2011-05-10 | Cisco Technology, Inc. | Unified transmission scheme for media stream redundancy |
| US20080253369A1 (en) * | 2007-04-16 | 2008-10-16 | Cisco Technology, Inc. | Monitoring and correcting upstream packet loss |
| US8356331B2 (en) * | 2007-05-08 | 2013-01-15 | Qualcomm Incorporated | Packet structure for a mobile display digital interface |
| US8711851B1 (en) * | 2007-07-19 | 2014-04-29 | American Megatrends, Inc. | Multi-protocol data transfers |
| US20090080422A1 (en) * | 2007-09-21 | 2009-03-26 | Posdata Co., Ltd. | Header-compression packet processing method, mobile station, base station, and control station in wireless communication system |
| US8001278B2 (en) * | 2007-09-28 | 2011-08-16 | Intel Corporation | Network packet payload compression |
| US8787153B2 (en) | 2008-02-10 | 2014-07-22 | Cisco Technology, Inc. | Forward error correction based data recovery with path diversity |
| US9600261B2 (en) * | 2008-03-25 | 2017-03-21 | Qualcomm Incorporated | Apparatus and methods for widget update scheduling |
| US9110685B2 (en) * | 2008-03-25 | 2015-08-18 | Qualcomm, Incorporated | Apparatus and methods for managing widgets in a wireless communication environment |
| US9069575B2 (en) * | 2008-03-25 | 2015-06-30 | Qualcomm Incorporated | Apparatus and methods for widget-related memory management |
| US9269059B2 (en) * | 2008-03-25 | 2016-02-23 | Qualcomm Incorporated | Apparatus and methods for transport optimization for widget content delivery |
| US9747141B2 (en) | 2008-03-25 | 2017-08-29 | Qualcomm Incorporated | Apparatus and methods for widget intercommunication in a wireless communication environment |
| US8811294B2 (en) | 2008-04-04 | 2014-08-19 | Qualcomm Incorporated | Apparatus and methods for establishing client-host associations within a wireless network |
| CA2722857A1 (en) * | 2008-04-28 | 2010-07-22 | Xg Technology, Inc. | Header compression mechanism for transmitting rtp packets over wireless links |
| US8902805B2 (en) * | 2008-10-24 | 2014-12-02 | Qualcomm Incorporated | Cell relay packet routing |
| US9398089B2 (en) * | 2008-12-11 | 2016-07-19 | Qualcomm Incorporated | Dynamic resource sharing among multiple wireless devices |
| US20100205321A1 (en) * | 2009-02-12 | 2010-08-12 | Qualcomm Incorporated | Negotiable and adaptable periodic link status monitoring |
| US9264248B2 (en) * | 2009-07-02 | 2016-02-16 | Qualcomm Incorporated | System and method for avoiding and resolving conflicts in a wireless mobile display digital interface multicast environment |
| US8140709B2 (en) * | 2009-08-07 | 2012-03-20 | Alcatel Lucent | Two stage internet protocol header compression |
| CN102056235B (zh) | 2009-11-09 | 2017-04-26 | 华为技术有限公司 | 一种数据传输方法、设备和系统 |
| US9582238B2 (en) | 2009-12-14 | 2017-02-28 | Qualcomm Incorporated | Decomposed multi-stream (DMS) techniques for video display systems |
| US9168946B2 (en) * | 2010-03-19 | 2015-10-27 | Javad Gnss, Inc. | Method for generating offset paths for ground vehicles |
| US9065876B2 (en) | 2011-01-21 | 2015-06-23 | Qualcomm Incorporated | User input back channel from a wireless sink device to a wireless source device for multi-touch gesture wireless displays |
| US8964783B2 (en) | 2011-01-21 | 2015-02-24 | Qualcomm Incorporated | User input back channel for wireless displays |
| US20130013318A1 (en) * | 2011-01-21 | 2013-01-10 | Qualcomm Incorporated | User input back channel for wireless displays |
| US9413803B2 (en) | 2011-01-21 | 2016-08-09 | Qualcomm Incorporated | User input back channel for wireless displays |
| US10135900B2 (en) | 2011-01-21 | 2018-11-20 | Qualcomm Incorporated | User input back channel for wireless displays |
| US9787725B2 (en) | 2011-01-21 | 2017-10-10 | Qualcomm Incorporated | User input back channel for wireless displays |
| US8674957B2 (en) | 2011-02-04 | 2014-03-18 | Qualcomm Incorporated | User input device for wireless back channel |
| US9503771B2 (en) | 2011-02-04 | 2016-11-22 | Qualcomm Incorporated | Low latency wireless display for graphics |
| US10108386B2 (en) | 2011-02-04 | 2018-10-23 | Qualcomm Incorporated | Content provisioning for wireless back channel |
| JP2013085224A (ja) | 2011-07-29 | 2013-05-09 | D & M Holdings Inc | コンテンツデータ伝送システム及びコンテンツデータ伝送方法 |
| JP2013031087A (ja) * | 2011-07-29 | 2013-02-07 | D & M Holdings Inc | コンテンツデータ伝送システム及びコンテンツデータ伝送方法 |
| US20140022969A1 (en) * | 2012-07-17 | 2014-01-23 | Cubic Corporation | Application and method of inter-frame gap reduction in low-power time-synchronized networks |
| US8804766B2 (en) * | 2011-11-18 | 2014-08-12 | Dialogic Networks (Israel) Ltd. | Method and apparatus for compressing communication packets |
| US9525998B2 (en) | 2012-01-06 | 2016-12-20 | Qualcomm Incorporated | Wireless display with multiscreen service |
| US9620955B2 (en) | 2013-03-15 | 2017-04-11 | Schweitzer Engineering Laboratories, Inc. | Systems and methods for communicating data state change information between devices in an electrical power system |
| US9270109B2 (en) | 2013-03-15 | 2016-02-23 | Schweitzer Engineering Laboratories, Inc. | Exchange of messages between devices in an electrical power system |
| US9065763B2 (en) | 2013-03-15 | 2015-06-23 | Schweitzer Engineering Laboratories, Inc. | Transmission of data over a low-bandwidth communication channel |
| FR3006534B1 (fr) * | 2013-05-31 | 2015-05-22 | Thales Sa | Procedes de transmission et de reception de donnees entre un terminal et une passerelle, en particulier via une liaison satellite |
| US9374443B2 (en) * | 2013-07-11 | 2016-06-21 | Qualcomm Incorporated | Method and apparatus for efficient packet compression |
| KR101754285B1 (ko) * | 2013-08-19 | 2017-07-06 | 엘지전자 주식회사 | 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법 |
| US9674803B2 (en) | 2013-09-23 | 2017-06-06 | Qualcomm Incorporated | Out-of synchronization detection and correction during compression |
| US20160378630A1 (en) * | 2015-06-25 | 2016-12-29 | Dell Products L.P. | Port monitoring system |
| US9924000B2 (en) | 2016-03-14 | 2018-03-20 | Sprint Communications Company L.P. | Communication packet header data compression |
| EP3264779B1 (en) * | 2016-06-30 | 2022-04-13 | Apple Inc. | Apparatus adapted for maintaining receiving data quality and method for receiving data |
| WO2019175378A1 (en) * | 2018-03-16 | 2019-09-19 | Acklio | Method and apparatus processing of message data |
| US10819727B2 (en) | 2018-10-15 | 2020-10-27 | Schweitzer Engineering Laboratories, Inc. | Detecting and deterring network attacks |
| JP2020205531A (ja) * | 2019-06-17 | 2020-12-24 | 富士通株式会社 | ネットワーク監視装置、伝送装置、及びネットワーク監視方法 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5148272A (en) * | 1991-02-27 | 1992-09-15 | Rca Thomson Licensing Corporation | Apparatus for recombining prioritized video data |
| US5246779A (en) * | 1992-08-10 | 1993-09-21 | Quantum Chemical Corporation | Microfine propylene polymer powders and process for their preparation |
| US5742773A (en) * | 1996-04-18 | 1998-04-21 | Microsoft Corporation | Method and system for audio compression negotiation for multiple channels |
| US5987022A (en) * | 1996-12-27 | 1999-11-16 | Motorola, Inc. | Method for transmitting multiple-protocol packetized data |
| US6032197A (en) * | 1997-09-25 | 2000-02-29 | Microsoft Corporation | Data packet header compression for unidirectional transmission |
| US6125348A (en) * | 1998-03-12 | 2000-09-26 | Liquid Audio Inc. | Lossless data compression with low complexity |
| US6519223B1 (en) * | 1999-04-06 | 2003-02-11 | Telefonaktiebolaget L M Ericsson (Publ) | System and method for implementing a semi reliable retransmission protocol |
| US6198735B1 (en) * | 1999-05-20 | 2001-03-06 | Motorola, Inc. | Method for retransmitting a data packet in a packet network |
| US6300887B1 (en) * | 1999-11-09 | 2001-10-09 | Nokia Networks Oy | Efficient handoff procedure for header compression |
-
1999
- 1999-12-30 US US09/476,205 patent/US6608841B1/en not_active Expired - Lifetime
-
2000
- 2000-12-22 WO PCT/US2000/035088 patent/WO2001050705A2/en active IP Right Grant
- 2000-12-22 CA CA002397687A patent/CA2397687C/en not_active Expired - Fee Related
- 2000-12-22 EP EP00993761A patent/EP1243118B1/en not_active Expired - Lifetime
- 2000-12-22 JP JP2001550961A patent/JP3559019B2/ja not_active Expired - Fee Related
- 2000-12-22 AU AU29122/01A patent/AU2912201A/en not_active Abandoned
- 2000-12-22 DE DE60022391T patent/DE60022391T2/de not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| WO2001050705A2 (en) | 2001-07-12 |
| AU2912201A (en) | 2001-07-16 |
| EP1243118B1 (en) | 2005-08-31 |
| DE60022391T2 (de) | 2006-05-18 |
| JP2003519965A (ja) | 2003-06-24 |
| US6608841B1 (en) | 2003-08-19 |
| EP1243118A2 (en) | 2002-09-25 |
| CA2397687A1 (en) | 2001-07-12 |
| CA2397687C (en) | 2006-08-01 |
| DE60022391D1 (de) | 2005-10-06 |
| WO2001050705A3 (en) | 2002-01-03 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3559019B2 (ja) | 信頼できないネットワークが存在する場合にロバストなｉｐ／ｕｄｐ／ｒｔｐヘッダ圧縮を達成するシステム及び方法 | |
| KR100663586B1 (ko) | 헤더 압축에 의한 패킷 데이터의 송신 방법 및 장치 | |
| JP3694241B2 (ja) | インターネットプロトコルを使用する遠隔通信のための方法および装置 | |
| JP4582565B2 (ja) | パケット通信におけるロバストヘッダ圧縮 | |
| JP5084842B2 (ja) | 無線通信ネットワークにおける改良されたヘッダ圧縮 | |
| EP1045562A2 (en) | A Light-weight Internet Protocol Encapsulation (LIPE) scheme for multimedia traffic transport | |
| US20090268667A1 (en) | Header compression mechanism for transmitting RTP packets over wireless links | |
| EP1122925A1 (en) | Header compression for general packet radio service tunneling protocol (GTP) | |
| CA2387382C (en) | Sparse feedback in high delay-low bandwidth wireless systems | |
| KR20020079796A (ko) | 무선 네트워크 시스템 및 방법 | |
| JP2002026963A (ja) | パケット伝送方法、中継装置およびデータ端末 | |
| US20020191691A1 (en) | Payload header suppression including removal of fields that vary in known patterns | |
| WO2002028107A2 (en) | Enhanced header compression profile | |
| WO2000060795A1 (en) | Method and devices for digital data transfer | |
| US9148257B2 (en) | Method and apparatus for reducing delays in a packets switched network | |
| US7337384B2 (en) | Error detection scheme with partial checksum coverage | |
| KR100689473B1 (ko) | 통신시스템에서 프로토콜 헤더 압축장치 및 방법 | |
| US20040034826A1 (en) | Transport protocol checksum recalculation | |
| CN100428733C (zh) | 移动通信网络中ip报头压缩的错误恢复方法及装置 | |
| Madsen et al. | IP header compression for media streaming in wireless networks | |
| KR20120032129A (ko) | 무선링크에 최적화된 헤더압축장치 및 그 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040419 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040519 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090528 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100528 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110528 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110528 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120528 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130528 Year of fee payment: 9 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130528 Year of fee payment: 9 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |