JP4583691B2 - スケジューリングおよびヘッダ圧縮を利用しパケット遅延を軽減させるための方法と装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、パケットの情報を転送するための多重化通信システム、より特定すれば、多層化されたネットワークアーキテクチャにおけるパケットのスケジューリングおよびヘッダ圧縮に関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
現代の通信ネットワークが伝送する、リアルタイムの音声、動画、および関連データが関係しているパケットトラフィック量は増加している。例えば、インターネットにおいては、リアルタイムの音声および動画を含む多様なデータを送信するために、従来の通話接続と比べてより割安な代替手段を利用する、多くの新規なアプリーケーションが登場している。インターネット上でリアルタイムアプリケーションが流行している一因として、一般家庭で設置されるコンピュータが高性能化してきたこと、および、音声通話、音楽やビデオクリップの視聴などの様々なオンライン活動の中心としてインターネットが普及してきたことが挙げられる。高帯域幅の商業用接続におけるコンピュータ同士のインターネット接続と違い、典型的な家庭における帯域幅は、モデムスピード、ライン品質等によって課せられる接続性の条件によって制限されている。
【０００３】
帯域幅の制限という基本的な問題は、プロトコルヘッダが原因のパケットオーバーヘッドの結果、実際に転送される情報量が制限されることにより、更に大きな問題となる。基本的なインターネットプロトコルは、リアルタイム問題がほとんど考慮されていなかった時に、エンドツーエンドでパケットが正確に転送されるのを確実にすることを第一に開発されたものである。
【０００４】
Ｘ．２５等のプロトコルを含む３階層のインターフェースアーキテクチャは、例えば、下位層における転送制御のために開発され、一方、上位層のプロトコルは、より緻密な機能を制御するために開発された（“Ｏｐｅｎ Ｓｙｓｔｅｍ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＯＳＩ）−Ｎｅｗ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｓｔａｎｄａｒｄｓ Ａｒｃｈｉｔｅｃｔｕｒｅｓ ａｎｄ Ｐｒｏｔｏｃｏｌｓ ｆｏｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ”ＩＥＥＥ会報 特別版、編集Ｈ．Ｃ．ＦｏｌｔｓおよびＲ．ｄｅｓ Ｊａｒｄｉｎｓ，ｖｏｌ．７１，ｎｏ．１２，１９８３年１２月を参照）。設計思想によると、下位層の機能は、上位層の機能性に対して「透過的」であるように考慮されるため、下位層で達成され得ることのほとんどは、下位層のハードウェアとソフトウェアが当該透過性を保存する能力によってのみ制限される。最下位層、つまり物理層では、Ｘ．２１プロトコル等のプロトコルスペシフィケーションが装置間の物理的接続を管理する。次に、データリンク層は、例えば上位層からパケットを受信し、それを、物理層を通り転送するための例えばＨＤＬＣフレームに配置するためのプロトコルを特定する。データリンク層は、更に、物理層からフレーム化された情報を受信し、それをアンパックして、ネットワーク層まで転送することができる。ネットワーク層、またはパケット層では、エンドツーエンドでのパケット配送の成功が保証されていない場合や、順序どおりの配送が保証されていない場合、および、あて先アドレス等の情報を含むパケットまたは「データグラム」がひとつずつ配送される場合等のいくつかの想定に基づいて、複数の論理接続を確立し、パケットにアドレスを添付することができる。
【０００５】
本明細書では様々な下位層について記載されているが、上位層からのデータグラムは、ネットワーク層のプロセスまたはシステムへのインプットを形成し、それに引き続き、下位層へ、最終的には送信先へインプットが提供されるという点に留意しなければならない。ネットワーク層エンティティに入力される上位層のデータグラムは、例えば、伝送層プロセスまたはシステムから入力され得る。典型的で周知の伝送層プロトコルは、他にも周知で利用されている伝送層プロトコルはあるものの、伝送制御プロトコル（ＴＣＰ）である。特に、ユーザデータグラムプロトコル（ＵＤＰ）は、伝送層プロトコルとしてしばしば使用されている。ＵＤＰは、無線データグラムサービスを定義するプロトコルである。ＵＤＰを実行する伝送層プロセスまたはシステムは、あて先へのルーティング情報を含む内臓データパケットを形成することができる。
【０００６】
インターネット上でのネットワーク層通信のために定着したプロトコルは、インターネットプロトコル（ＩＰ）である。ＩＰスペシフィケーションには、ＩＰヘッダに関連したフィールドの算出が含まれており、当該フィールドは、関連パケットについての情報を含んでおり、当該パケットには、当該パケットがどのように配送されるべきかを特定するための情報が含まれている。ＩＰヘッダフィールドについては、以下で詳述する。ＩＰヘッダの内容をより完全に理解するには、“Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ”Ｅ．Ｊ．Ｐｏｓｔｅｌ，ＳＲＩ Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｍｅｎｌｏ Ｐａｒｋ，ＣＡ，１９８１年９月，ＲＦＣ７９１を参照。
【０００７】
データリンク層通信については、ポイントツーポイントプロトコル（ＰＰＰ）が独占的なプロトコルとなっている。ＰＰＰは３つの主要な構成、つまり、マルチプロトコルデータグラム（データグラムはネットワーク層（ＩＰ等）における伝送単位である）をカプセル化する手段と、データーリンク接続を確立、設定、およびテストするためのリンク制御プロトコル（ＬＣＰ）と、相違するネットワーク層のプロトコルを確立、設定するためのネットワーク制御プロトコル（ＮＣＰ）ファミリーとを有する。
【０００８】
ＰＰＰは、当該プロトコルに従ったリンクの両端である、２つのいわゆるピアの間でパケットを伝送するために設けられる。従って、カプセル化フォーマットのオプションについて合意し、パケットサイズへの多様な制限を処理し、設定誤りを検出し、リンクを終了するために、ＬＣＰを使用することができる。他の任意の機能は、リンク上のそのピアのアイデンティティの認証と、リンクがいつ正常に機能し、いつ不能であるかを決定することである。ＰＰＰリンクは、全二重同時ビッドレクショナルオペレーションを提供する。ＰＰＰの定義については、Ｎｅｔｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ＲＦＣ １６６１，“Ｔｈｅ Ｐｏｉｎｔ ｔｏ Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ”Ｗ．Ｓｉｍｐｓｏｎ編，１９９４年７月，に記載がある。
【０００９】
ＰＰＰを使用して確立されたリンク間の通信は、プロトコルと関連のあるデータグラムが一または複数のフレームにカプセル化され得るように達成される。上記に記載のフレームは、いくつかのデータ単位とともに、ヘッダおよび／またはトレーラをふくむことができる。しかしながら、パケット全体をフレームにマッピングするのが従来からの慣行である。しかし、フラグメント化・メソッドをフロー制御管理に使用できる、ネットワークが輻輳している状態では、従来のフレーミングは機能しない。そのような輻輳の原因は、何よりも、例えばマルチリンクサービスによって提供される広帯域接続の数の増加による、トラフィックの増加にある。基本レートでもあり一次群レートでもあるＩＳＤＮは、例えば、システム間の多重同時チャネルによるオンディマンド帯域幅を可能とするので、そのようなサービスに関係する問題に取り組まなくてはならない。待ち時間を生じさせる輻輳は、音声や動画のリアルタイムデータ、ＶｏＩＰ、テルネット等にとって特に問題となる。そのようなリアルタイムデータフォーマットには、パケット待ち時間、ジッタ、パケット再順序化、および関連問題に対する許容度が殆どまたは全くない。マルチリンク環境に関連する問題は、独特のリアルタイムパケットデータ条件を増加させるだけである。
【００１０】
マルチリンク環境での輻輳を緩和するために、リンクフラグメント化とインターリービング（ＬＦＩ）として既知の解決方法が、シスコシステムによる“ＣｉｓｃｏＩＯＳ^ＴＭＳｏｆｔｗａｒｅ Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ Ｓｏｌｕｔｉｏｎｓ”１９９９年４月８日，に提案されている。ＬＦＩでは、遅延とジッタは、大きなデータグラムの分割と、時間に敏感なパケットと得られたパケットフラグメントとのインターリービングとによって軽減される。ＬＦＩでは、連続遅延が主要な遅延要因である比較的低速度のリンクが想定されている。ＬＦＩは、単に、インターリービングを可能とするためにＰＰＰの設定を要求する。そうでない場合には、ＬＦＩは、ＰＰＰに対して透過的である。
【００１１】
同様の解決法がＣａｒｓｔｅｎ Ｂｏｒｍａｎによる、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ），ＩＮＴＥＲＮＥＴ−ＤＲＡＦＴ，“Ｍｕｌｔｉ−Ｃｌａｓｓ Ｅｘｔｅｎｓｉｏｎ ｔｏ Ｍｕｌｔｉ−Ｌｉｎｋ ＰＰＰ”，１９９９年６月，期限満了：１９９９年１２月，に提案されている。本書によって、例えば統合サービス通信リンクの標準アーキテクチャの一部であるフォーマットのリアルタイムカプセル化のための、フラグメント志向の解決方法を知ることができる。
【００１２】
従来のＬＦＩ、マルチリンクＰＰＰ、および関連するデータ転送に関する問題のいくつかは、具体例によって最もよく説明することができる。２８．８キロビット／秒のモデムリンク上での１．５キロバイトのパケットの転送によって、当該リンクは占有されるため、当該リンクは、４００ミリ秒以上の間、マルチリンク環境における他のリンクに関連するパケットのデータ転送のために利用することができなくなる。そのような遅延は、音声通話等のインタラクティブリアルタイムデータと関連した往復遅延を１秒近く起こす原因となり得る。所定のサイズより大きな様々なプライオリティ（優先度）を有するパケットのフラグメント化により、高プライオリティパケットまたはそのフラグメントをより低いプライオリティパケットのフラグメント間に送信することができる。既存のマルチリンクＰＰＰスペシフィケーションは既にシーケンス番号の提供によってフラグメント化を可能とし、ＰＰＰカプセル化フォーマットのビットを開始し終了する。しかし、既存のマルチリンクＰＰＰは、連続したパケット番号付けスキームが原因で、他のパケットを送信するために１パケットのフラグメントの送信転送を停止することができない。上記のＢｏｒｍａｎが提案した解決手段には、クラス番号を特定するためにマルチリンクＰＰＰプロトコルにある未使用のビットを使用し、多重の停止可能なクラスをネスティングすることが可能な同一リンク上で、多重マルチリンクプロトコルインスタンスを作動させることが含まれている。従って、特定のクラスに属するフラグメントをマルチリンクヘッダなしに送信することが可能となり、ヘッダビット数に応じて４乃至１２レベルの停止を達成することが可能となる。
【００１３】
考慮されるフラグメントのスケジューリング方法がいかなるものであれ、実行時には問題が生じる。特に、留意すべきは、下位３つのプロトコル層と、例えばＵＤＰ、ＩＰ、およびＰＰＰを含む関連プロトコルは、物理層と共に、典型的にはルータ等のハードウェアリソース上に存在するため、フラグメント化や他のスケジューリング方法によって得られる利益が致命的な制約を受ける場合があるという点である。特に、ルータは、例えば、一旦優先度などが設定されると、典型的には、出力パケットを一緒に同一の伝送キューへ配列させる場合。典型的な出力パケットキューの設定は、一般的には、ファーストインファーストアウト（ＦＩＦＯ）であるが、これは、キューの深さと関係のある固有の遅延レベルを有する。更に、高いトラフィクレベルを経験し、典型的な出力パケットキューを使用しているルータにおいては、ＬＦＩ、マルチリンクＰＰＰ等を使用している場合でさえ、輻輳が発生したときには、パケットを落とす可能性が高くなる。ＩＰスケジューリングが発生した後にダウンストリームキューからパケットが落とされた場合、シークエンスから受信したパケットに関連した問題が発生し得る。リンク設定に応じて、欠落したパケットを再伝送する要求が、例えば、リアルタイムデータの遅延と劣化を引き起こすことがある。
【００１４】
パケットドロップは、例えばヘッダ圧縮等の輻輳を減少させるための他の方法と共に使用された場合、特に問題となり得る。典型的なヘッダに含まれた情報の任意部分を圧縮または破棄することによって、ヘッダ圧縮方法は、データグラムまたはパケットの全体サイズを減少させる。このことは、、ヘッダがパケットオーバーヘッドのほぼ１００％を示すことがあるリアルタイムデータ転送アプリケーションのために典型的に使用される小さいパケットの場合、特に重要である。ヘッダ圧縮は様々な段階で実行されるが、パケットドロップの影響を含めて、パケット再伝送または再配列が起こらないであろうという、ヘッダ圧縮の使用の際に当該技術分野において必ず考慮されるべき想定が問題の原因となっている。この問題を処理するためのアプローチによると、ヘッダ圧縮技術を使用して当初軽減されたものとほぼ同等のヘッダオーバーヘッドが付加される。ヘッダ圧縮に関する概説については、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ），ＩＮＴＥＲＮＥＴ−ＤＲＡＦＴ，“Ｐｒｏｖｉｄｉｎｇ Ｉｎｔｅｒｇｒａｄｅｄ Ｓｅｒｖｅｓ Ｏｖｅｒ Ｌｏｗ−ｂｉｔｒａｔｅ Ｌｉｎｋｓ”，１９９９年６月，期限満了：１９９９年１２月，Ｃａｒｓｔｅｎ Ｂｏｒｍａｎ、および、Ｎｅｔｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ＲＦＣ １１４４，“Ｃｏｍｐｒｅｓｓｉｎｇ ＴＣＰ／ＩＰＨｅａｄｅｒｓ ｆｏｒ Ｌｏｗ−Ｓｐｅｅｄ Ｓｅｒｉａｌ Ｌｉｎｋｓ”，Ｖ．Ｊａｃｏｂｓｏｎ編，１９９０年２月を参照。
【００１５】
遅いリンクでは、既に記載したように、時間に敏感なパケットは、例えば長いベストエフォート（ＢＥ）データパケットの完成を待つ余裕がない。ＩＰフラグメント化を使用すれば、そのようなパケットの待ち時間が改善されるかもしれないが、各セグメントあたり約２０バイトのヘッダを付加しなければならない。更なる解決方法は、マルチリンクＰＰＰセグメントを使用することであり、これによると、各セグメントに２または４バイトのヘッダが付加される。そのようなヘッダは、スケジューリング情報をセグメントまたはフラグメントに伝達するように設計されている。ヘッダ圧縮は、しかしながら、ＩＰスケジューリングを困難にする。ヘッダ圧縮が使用された場合、ＩＰヘッダにおける識別フィールドを含む情報が、圧縮後、下位層に利用不可能となる。ＨＣパケットが落ちた場合、受信側で発生した欠落シーケンス番号は、リンク上で問題を発生させるだろう。というのは、上述したように、例えば、受信側は落ちたパケットの再伝送を要求するであろうが、担当階層はどのパケットが落ちたのかを認識できないであろうから、上位層から落ちたパケットを要求することができず、更なる遅延や品質の低下が引き起こされるためである。
【００１６】
従って、当然のことながら、当該技術分野においては、スケジューリングを処理し、ヘッダ圧縮が落下パケットに与えるスケジューリングへの悪影響を減少させるための方法と装置が期待されている。そのような方法および装置は、ＩＰ層の操作の妨害なしに動作し、ヘッダ圧縮を有する純粋なＩＰパケットへの一般的なＩＰスケジューリングを可能とする。
【００１７】
【課題を解決するための手段】
従って、本発明の目的は、スケジューリングとヘッダ圧縮を使用してパケット遅延を軽減させる方法と装置を提供することである。
【００１８】
本発明のさらなる目的は、多層プロトコルの実行内で様々な層にそのような方法と装置を提供することである。
【００１９】
従って、本発明の一面によると、上記および他の目的は、複数のパケットの転送で遅延を減少させるための方法と装置において達成される。パケットは、少なくとも１つの上位層、および１つの下位層を有する多層プロトコルに従って複数の分類を有することができる。パケットは、関連する分類に従ってスケジュールすることができる。スケジューリングの間に輻輳が発生した場合、スケジュール化できないパケットは破棄することができる。スケジューリングと破棄の後、幾つかのパケットヘッダは圧縮することができ、それに従って、シーケンス情報が保存することができる。
【００２０】
本発明の他の実施態様によると、パケットは、スケジューリング、破棄および圧縮の後、少なくとも２つの複数の分類に従って、第一および第二のキューに配列することができ、当該第一のキューは、当該第二のキューに対して優先度が高い。例えば、上記２つの可能な分類の１つには、キューイングにパケットがベストエフォートとして分類されているか否かを決定させること、および、そのように分類されている場合には、ベストエフォートパケットを例えば第二のキューにキューイングさせることを含むように、ベストエフォート分類が含まれている。
【００２１】
パケットと関連しているＩＰヘッダに見られ得る例えばＱｏＳレベルと関連しているかもしれない多くの分類が含まれてもよいということが理解されなければならない。分類は、複数の遅延要素とも関連があってもよく、好ましくは、複数のキューは、複数の分類に基づいて確立されてもよい。従って、各パケットｈ、関連した分類に基づく複数のキューの中の１つに並べられる。
【００２２】
本発明の更なる実施態様によると、複数の分類は、本書で既に記載したリンクフラグメント化とインターリービング（ＬＦＩ）に関連していてもよい。あるいは、複数の分類は、本書で上記に記載したマルチリンクＰＰＰと関連していてもよい。
【００２３】
更に留意すべきは、本発明によると、スケジューリングは、上位層または下位層で実行することができ、ここで、当該下位層は、上述したようにＰＰＰ層を含む。下位層は、更にＨＤＬＣ層を含み、そこでスケジューリングが実行される場合、ヘッダ圧縮に先立ち、各パケットにタグが作成される。タグはその後に付加され、伝送前に除去されることができる。第一および第二のキューからの各パケットは、１未満のキュー深さを有する出力パケットキューに並べられることができる。
【００２４】
本発明の目的と利点は、図面を参照しながら以下の詳細な記載を読むことによって理解されるであろう。
【００２５】
【発明の実施の形態】
従って、本発明により、ルータ、ライン・インターフェースカード等のネットワークにおける様々な階層において、ＩＰスケジューリングと共にヘッダ圧縮を使用することを可能にする方法および装置が提供される。
【００２６】
興味深いのは、本発明によると、本書で記載のように、本発明の特定の実施態様に従って、様々な段階でＩＰパケットのヘッダ圧縮を実行することができる点である。例示的な圧縮されたヘッダフォーマットが図１に示されており、これは、例えば、典型的なＴＣＰ／ＩＰヘッダにおいても可能なヘッダ圧縮動作である。上記で言及したように、ここでＴＣＰは、伝送層制御プロトコルを例示するために使用されているが、他の伝送層プロトコル、好ましくはＵＤＰを本発明に使用することもできる。図からわかるように、重要な情報は、圧縮されたパケットに伝わり、例えば、変更が期待されているフィールドのうちどれが実際に変更するかを示す変更マスク１９３などの処理を通じて解釈されてもよい。圧縮されたヘッダは典型的には接続中またはパケットセッションの間に変更が期待されるフィールドからなってもよいので、ビット１９３ａ−１９３ｇを、これらの変化を示すために使用してもよい。接続番号フィールド１９４は、例えば変更マスク１９３の前の値とその現在の値を比較するために示された特定の接続からの最後のパケットの保存コピーを受信側が見つけることを可能とする値を含んでもよい。ＴＣＰチェックサムフィールド１９５は、当該技術分野で既知の方法で計算された圧縮されたヘッダのためのチェックサムを含む。アージェントポインタ１９３ｈは、緊急データを指す値を含む。残りのフィールドは、関連フィールドのための値の変化を表示し、例えば、△ウィンドウフィールド１９３ｊは、ウィンドウフィールドの変化を示し、フィールドのサイズを２オクテットから１へ減少させた、より小さな値を使用して示されてもよい。同様に、△アクトフィールド１９３ｋは識別番号フィールドでの変化を示し、４オックテットではなく１オクテットを使用する。△シーケンスフィールド１９３１は、シーケンス番号フィールドでの変化を示し、ここでもまた使用するオクテットは４から１に減少している。△ＩＰＩＤフィールド１９３ｍは、関連ＩＰヘッダからのパケットＩＤフィールドでの変化を示し、２オクテットから１オクテットへサイズが減少した結果であってもよい。最後に、データフィールド１９６は、示されたように、圧縮されたヘッダフィールドの最後に続く。興味深いのは、例えばパケット間に変化が表れない場合、フィールド１９３ｈ−１９３ｍは省略されてもよく、データフィールド１９６がは、ＴＣＰチェックサムフィールド１９５のすぐ後に直接続いてもよいことである。また、興味深いのは、上記に記載のフィールドは、そこで実行されるヘッダ圧縮をともなう例示的なＩＰパケットと関連していてもよい点である。更に、圧縮されたフィールド数を減少すること、または、受信するＩＰパケットを圧縮し、および本発明の技術に従ってタグを単に含めることが可能である。
【００２７】
多層プロトコルの本質的性質を理解することにより、圧縮されたヘッダである可能性のある、多重データタイプ（リアルタイム、ベストエフォート等）を運ぶリンクにおける輻輳制御に関連する問題を理解することができる。これらの問題は、特にパケットがヘッダ圧縮に先立ちスケジュール化され、ヘッダ圧縮実行後、輻輳が原因で破棄された場合であって、ヘッダ圧縮が発生した階層の下の階層において、特に困難な問題である。輻輳の間、転送待ちのパケットは幾つかの既知の方法を使用してスケジュール、またはキューイングされなくてはならない。図２は、下位３層を有する典型的なネットワークサービススタックを使用した例示的なネットワークノード２００を図示する。例示的なデータパケット２１１、２１２、および２１３がネットワーク層２１０へ入る状態が図示されており、ここでプロセス２１５は、ここでＤ_１が最も時間に敏感でＤ_４が比較的時間に敏感ではないことを示すとした時、例えばパケット２１２についてはＤ_４というふうに表された時間についての敏感度に基づいて、到来した転送されるべきパケットを、リンクフラグメント化とインターリービング（ＬＦＩ）層２２０のキュー２２１、２２２、２２３、２２４内に配置決定することができる。ＬＦＩ層２２０がデータリンク層２３０の少なくとも一部を占有していることが分かる。キューＤ_１２２４のパケットが最初に送信され、その後、Ｄ_２２２３、Ｄ_３２２２、Ｄ_４２２１が送信される。パケット２１３で表示されたような長いパケットは、パケット２１３_ａ、２１３_ｂ、２１３_ｃとして表示された小さなパケットへフラグメント化されてもよい。長いパケットの優先度は一般的に低いので、パケット２１４_ａ、２１４_ｂ、２１４_ｃとして表示されている、多くの場合音声、またはビデオ等のリアルタイムデータに関連した優先度の高いパケットは、転送前にキュー２２４に蓄積される。パケットがキュー２２１−２２４に入る際、ＨＤＬＣ等の典型的なデータリンクプロセスなどのプロセス２３１によって物理層に転送され、ここで、これらパケットをＦＩＦＯ伝送キュー２３２で処理し、物理リンク２３３に出力することができる。
【００２８】
上記に記載のＬＦＩメソッドを使用していても、一度パケットがフラグメント化されると、それらは、一例が図３に図示されている従来の優先制御スキームに従ってキューイングされるか、または、適当なその導関数によってキューイングされる場合がある。例示的なネットワークノード３００が示されており、優先順位が低い方から高い方へ並んだキュー３１１−３１４に関する優先制御が、実行されている。パケット３１５、３１６および３１７は、例えば、各パケット３１５、３１６、３１７のそれぞれに典型的に関連したＩＰヘッダと共に含まれる、例えばＱｏＳ情報などの内容によって決定された、異なる優先度を有してネットワーク層２１０に到達する。例えば、優先度の高いパケット３１７は、プロセス３２０によって優先度の高いキュー３１４に配置される。到来した優先度が中程度のパケット３１５と低度のパケット３１６は、ネットワーク層２１０に到達した時にプロセス３２０によって、それぞれ優先度が中程度のキュー３１３と優先度が低度のキュー３１１へ配置される。優先制御は、データリンク層２３０に相当する層３１０、または、データリンク層２３０と整合するＰＰＰ層等の代替プロトコル層で実行される場合がある。出力パケット３１８ａ−３１８ｄが、図示したように、最も高い優先度を有する出力パケット３１８ａが最初に送信されるように、伝送キュー２３２でのキューイングのために、優先順位に従ってプロセス２３１に送信される。その後、出力パケット３１８ａ−３１８ｄは、ＨＤＬＣ等の典型的なデータリンクプロセスなどのプロセス２３１により物理層に転送され、ここで、これらパケットは、ＦＩＦＯ伝送キュー２３２において処理され、物理リンク２３３へ出力される。
【００２９】
図２および図３と関連して説明されたＬＦＩおよび優先制御によって、より効率的にパケットを処理することができる一方、留意しなくてはならないのは、処理が効率的にできるか否かは、例えば多くの場合、優先制御のためのＩＰヘッダに関連した正確なヘッダ情報に拠っており、フラグメント化されたパケットにとっては、配列情報が重要である。しかし、下位層ではその情報が利用可能でないかもしれないし、圧縮されたＩＰヘッダでは、そのような情報は、ＩＰパケットが復元されるまで利用不可能である。下位層でのフラグメント化には、ピアごとにフラグメントを追跡するためのヘッダ情報が更に必要である。階層化されたプロトコルでは多重層でフラグメント化を有することが可能である点に留意しなければならない。しかしながら、各層はフラグメント化を追跡しなければならず、あるタイプのデータは、パケットがシーケンスパケット等からフラグメント化される場合に発生する可能性が高い特定の異常を許容しない場合がある。従って、上記の「Ｍｕｌｔｉ−Ｃｌａｓｓ Ｅｘｔｅｎｓｉｏｎ ｔｏ Ｍｕｌｔｉ−Ｌｉｎｋ ＰＰＰ」では、優先制御するための多重クラスに対応したヘッダフォーマットが説明されている。図４Ａは、基本的なマルチリンクＰＰＰのためのパケットフォーマットを図示する。
【００３０】
アドレスフィールドＡ４１０は、パケットの宛先のアドレスを示す値を含んでもよい。制御フィールドＣ４１０は、既知の様々な制御機能と関連したビットの設定に関連する値を含んでもよい。パケット識別ＰＩＤフィールド４３０は、高および低オクテット４３１および４３２を含み、多量のフラグメントに対応することができる。フィールド４４０は、フラグメント化されたＰＰＰパケットの開始フラグメントを示すために設定された開始インディケータ・ビット４４０ａと、フラグメント化されたＰＰＰパケットの終端フラグメントを示すために設定された終端インディケータ・ビット４４０ｂとを含むビットを有する。他の全てのフラグメントでは、開始インディケータ・ビット４４０ａと終端インディケータ・ビット４４０ｂがゼロに設定されているはずである。更に、１つだけの「フラグメント」がパケットと関連している場合には、両ビットを１に設定することも可能である。ビット４４０ｃおよび４４０ｄは、最も基本的な実行では、単一クラスＰＰＰについてはゼロであってもよい、クラスレベルを示すために使用されてもよい。図４Ａ、４Ｂおよび４Ｃに図示されたマルチリンクＰＰＰフォーマットの間の主要な相違点は、フラグメントのためのより精密な分類に明らかに進歩的に対応している、各クラスフィールド４４０、４４１および４４２の設定である。従って、フィールド４４０、４４１、および４４２に含まれる分類値を使用して、優先制御と類似の制御をＰＰＰレベルで達成することができる。配列フィールド４５０は、フラグメント送信の度に増加する２４ビットの値（１２ビットも可能）である。フラググメントデータのセグメント４６０は、フラグメントデータの終端を示すＦＣＳセグメント４７０まで続いていてもよい。
【００３１】
従って、本発明の１つの実施態様によると、図５Ａに図示されたように、例えば、ＩＰ層５１０に向けられたデータグラムのＩＰヘッダに特定されていてもよい様々なＱｏＳレベルが、ＩＰ層５１０での「純粋な」 ＩＰスケジューリングを実行することによって処理される。キュー規律が、時間に敏感なパケットを扱うためにキュー５１２−５１４を使用して呼び出される場合があることが分かる。最も時間に敏感ではないＤ_Ｎ−１５１２は、最も遅延に対する許容度の高いパケットを配送できる。例えば、典型的なＩＰヘッダに関連したＤＳバイトまたはＴｏＳを検討することによって、そのような時間敏感性（タイム・センシティビティ）を決定できる。より低いＱｏＳ条件を有するパケットは、例えば、より優先度の低いキューへまわすことができる。対照的に、例えば音声データと関連しているリアルタイムパケットのように、より高いレベルのＱｏＳを有するパケットはより高いレベルの時間敏感性に関連しているので、より優先度の高いキューに配置される。非常に大きな時間敏感性を有するパケットは、非常に優先度の高いキューにスケジュールされ、最高の時間敏感性を有したパケットが高い時間敏感性のキューＤ_１５１４にスケジュールされる。通常は、非リアルタイムデータと関連したパケットである、ベストエフォートに設定されたＱｏＳを有するパケットは、ベストエフォート型キューＤ_Ｎ５１１に配置され、これらは、その名が示すとおり、例えば、送信するべきより高い優先度のパケットがない間に、可能であれば、送信される。時間に敏活な、およびベストエフォート型のキューイング・ストラテジーと一緒にインターリービングとフラグメント化を使用することができる点は興味深い。純粋なＩＰスケジューリングの実施態様でのプロセシングについては、以下で詳細に説明する。
【００３２】
本発明の別の実施態様においては、２段階のスケジューラから１段階のスケジューラへ減少させたことにより、図６に図示したように、ＰＰＰ層におけるスケジューリングを含むことが更に可能である。ＰＰＰ層６２０は、最も高い時間敏感性のキューＤ_１６２４から、より低い時間敏感性のキューＤ_Ｎ−１６２２までと、ベストエフォート型キュー_Ｎ６２１とからなる、様々な時間敏感性の程度を示す一連の優先キュー６２１−６２４を有することができる。
【００３３】
重要なことは、上記に記載された実施態様のいずれにおいても、出力プロセシングが、ＩＰ転送；パケット識別（ＤＳバイト・ルックアップ）；パケット破棄、レート制御、および優先制御を含むパケットスケジューリング；ヘッダ圧縮；ＰＰＰ／ＭＰ、イーサネット、ＡＴＭを含むリンクアダプテーション；およびリンクフレーミングを含んで実施されなくてはならない点である。ＩＰ転送と識別は、ヘッダ圧縮の前に実施されなくてはならない。更に重要なことは、上記に記載のように、ヘッダ圧縮シーケンスから落ちたパケットはアウトオブシーケンスに関連した問題の原因となるため、パケット破棄はヘッダ圧縮の前に実施されなくてはならないという点である。本発明に係るバックプレッシャー環境では、出力パケットキューを１未満の深さに設定し、時間に敏感なパケットは、出力パケットキューにおいてプロセスされる前に、せいぜい１ベストエフォートパケットを待つだけでよいことを確実にすることが重要である。パケットスケジューリングがパケット圧縮の後に行われた場合、ヘッダ圧縮機能は、「ローカル」タグをパケットの先頭に付加し、どのキューにパケットが付加されなくてはならないのかをリンク層に知らせなくてはならない。
【００３４】
図５Ａに図示された「純粋な」ＩＰスケジューリングの実施態様では、純粋なＩＰパケットがスケジュール化される（例えば、完全なＩＰヘッダおよびペイロード）。ＩＰ層５１０に関連したキューが満杯である場合、または、当該技術分野において既知で、実施されている通常の他の原則に基づいて、パケット破棄が起こる。
【００３５】
物理リンクに転送される前に、リンク層アダプテーションが出力パケットに実施される。ＩＰ層５１０でスケジューリングを実行する実施例に従って、ヘッダ圧縮とＰＰＰ／ＭＰ／ＨＤＬＣフレーミングをリンク層アダプテーションを完了させるために実行してもよい。上記の記載等に従って使用されるフラグメント化とインターリービング・スキーム等によって課されるかもしれないクラス数に関係なく、音声パケットのような時間に敏感なパケットについての遅延を短縮するために、例えば、キューＳＱ＿ＰＰＰ５２２およびＦＱ＿ＰＰＰ５２３の２つのキューを使用してＰＰＰ層５２０で簡単な優先制御規律を使用してもよい。セグメンテーションの程度が、ベストエフォートＱｏＳ以上である場合、または、上記に記載したようにマルチクラスのＰＰＰに関連して概要を述べた付加クラスを有する場合、それぞれの付加クラスがセグメント化されるための更なる待ち受け行列がＰＰＰ層５２０に付加されてもよい。従って、いつパケットを転送することが可能かに関する情報は、スケジューリング化プロセス、または本実施態様では、ＰＰＰ層５２０に知られていなければならない。
【００３６】
例えば、上記に記載のようにＤＳまたはＱｏＳを分析することによって、または、図４Ａ−４Ｃの記載を参照しながら概説したパケットに関するクラスを分析することによって分類され、ＩＰ層５１０からのＤ_１５１４からＤ_Ｎ−１５１２までのキューに関連した遅延レベルに分類されたパケットは、キューＦＱ＿ＰＰＰ５２３に配置、例えば大きなベストエフォートパケットに属する残りのセグメントより先に送信される。留意しなければならないのは、ヘッダ圧縮は、パケットがキューＦＱ＿ＰＰＰ５２３にスケジュール化される前に実行されるのが好ましい点である。ベストエフォートパケットとセグメント化されたパケットは、キューＳＱ＿ＰＰＰ５２２に入力されてもよい。パケットが大きすぎる場合、ＰＰＰ層５２０におけるＭＰプロセシングにより、キューイングの前にセグメンテーションを実行してもよい。
【００３７】
ＰＰＰ層５２０に付属するデータリンク層であってもよいＨＤＬＣ層５３０では、パケットを上記の記載に従って圧縮し、スケジュール化することができる。パケットのヘッダ圧縮後のプロセシングを更に容易にするため、例えばインターフェースカードに見られる出力バッファ５３１の深さは１パケット未満に設定される。これにより、輻輳によるパケット破棄の全てが、ＦＱ＿ＰＰＰ５２３とＳＱ＿ＰＰＰ５２２上で、つまり、ヘッダ圧縮のアップストリーム上で発生することを余儀なくさせられるという、「バックプレッシャー」が提供される。上記に記載したように、ヘッダ圧縮後に破棄されるパケットはアウトオブシーケンスに関連した問題の原因となる可能性があるので、そのような結果は望ましい。図５Ａで図示された実施態様の動作は、キューＦＱ＿ＰＰＰ５２３およびＳＱ＿ＰＰＰ５２２のための例示的なキュー規律に関連する以下の擬似コードにより最もよく理解される。ＩＰ層５１０とＰＰＰ層５２０の間のインターフェースに存在するスケジューラの例示的アウトプットループは、例えば以下に記載のケースが該当する場合に、パケットをキューＦＱ＿ＰＰＰ５２３およびＳＱ＿ＰＰＰ５２２にスケジュール化してもよい。
ケース１）キューＤ_１５１４にパケット、ＡＮＤ ＦＱ＿ＰＰＰ５２３に空きあり
ケース２）（ケース１はＦＡＬＳＥ）ＡＮＤ（キューＤ_２５１３にパケット）ＡＮＤ（ＦＱ＿ＰＰＰ５２３は空）
ケースＮ−１）（ケース１，２，…，Ｎ−２はＦＡＬＳＥ）ＡＮＤ（キューＤ_Ｎ−１５１２にパケット）ＡＮＤ（ＦＱ＿ＰＰＰ５２３は空）
ケースＮ）（１，…Ｎ−１はＦＡＬＳＥ）ＡＮＤ（キューＤ_Ｎ５１１にパケット）ＡＮＤ（ＳＱ＿ＰＰＰ５２２は空きあり）
更に留意すべきは、本発明の実施態様によると、キューＦＱ＿ＰＰＰ５２３のパケットは、好適には、常にキューＳＱ＿ＰＰＰ５２２のパケットの前に転送される。
【００３８】
図５Ｂに図示された例示的フローチャートは、例えば本発明に係るソフトウェアプロセスを通じてパケットがどのように進むかを最もよく示している。多層プロトコルを実行する送信元における上位層から、開始点５５０、例えばＩＰ層５１０で受信されたパケットは、ブロック５５１において、当該パケットに関連のある遅延要素に従ってキュー５１１−５１４にスケジュール化される。出力キュー５３１のための「バックプレッシャー」設計のため、決定ブロック５５２ａが実行されて、ＰＰＰ層５２０キューイングとヘッダ圧縮に先立ち、ブロック５５２ａにおいてパケットを破棄する。ＩＰ層５１０のキュー５１１−５１４が満杯になると、関連パケットは破棄され、再スケジューリングのための準備が上位層で行われる。そうでない場合は、キュー５１１−５１４からのパケットは、キューイングのために上記に概説したプロセスに従ってＰＰＰ層５２０で処理される。パケットの処理において、最も時間に敏感なパケットがＰＰＰ層５２０に最初に送信される。従って、例えば、キューＤ_１５１４が決定ブロック５５４において空でないと認定され、ＦＱ＿ＰＰＰキュー５２３が決定ブロック５５７において満杯ではないと認定された場合、Ｄ_１パケットを、決定ブロック５６０において空であるかそうでないかどちらに認定されたとしても、ＦＱ＿ＰＰＰキュー５２３に付加することができる。いずれにせよ、ヘッダ圧縮は、パケットがキューＦＱ＿ＰＰＰ５２３に付加される前にブロック５６２および５６４によって実行される。Ｄ_２パケットについては、キューＤ_２５１３にパケットが残り、ＦＱ＿ＰＰＰ５２３が決定ブロック５５７および５６０によって空であると認定される一方で、決定ブロック５５５は、Ｄ_２パケットがブロック５６２でヘッダ圧縮することができ、キューＦＱ＿ＰＰＰ５６３に付加することができることを示す。同様に、決定ブロック５５６、５５７および５６０の条件が満たされれば、Ｄ_Ｎ−１パケットは、ブロック５６２においてヘッダを圧縮された後にキューＦＱ＿ＰＰＰ５２３に付加されてもよい。留意しなければならないのは、時間に敏感なパケットが処理された後、例えばＤ_Ｎパケットによって表示されるベストエフォートパケットは、決定ブロック５５８および５５９を通過し、ブロック５６５でヘッダを圧縮された後、ブロック５６６においてＳＱ＿ＰＰＰ５２２に付加されてもよい点である。
【００３９】
更に留意すべきは、Ｙｅｓ条件に従って決定ブロック５５４、５５５、５５６および５５８を通過することによって、ループが形成される点である。そのようなループは、例えばソフトウェア実施態様において、以下のキューよりも優先度を有するキューＤ_１５１４によって各キューをクリアするために継続的なルーピングが実行され得ることを意味している。更に、より低い優先度を有するキューがクリアされる前に、より高い優先度を有するパケットが処理できる状態である場合、ルーピングは中断できる。
【００４０】
上記の詳細な説明に従ってスケジューリングを実行するのに加えて、本発明の実施態様は、更に、キューＦＱ＿ＰＰＰ５２３およびＳＱ＿ＰＰＰ５２２におけるキューイングの前に更なるステップを実行できる。例えば、パケットスケジュール化のためにあるキューが選択された後、例えば図１について記載した説明または同様の態様に従って、ヘッダ圧縮が実行できる。上述のカプセル化に関するコンセプトおよび層化構造に従って、例えば受信ノード上のＰＰＰ層５２０に対応するＰＰＰピア層への適切な配送、およびそれによる破棄を確実にするためにＰＰＰヘッダが付加されてもよい。上記したように、完全であるが長いベストエフォートデータパケットまたは、上位層でフラグメント化されたがＰＰＰ層５２０での効率的転送のためには依然として長すぎるパケットの何れかに更なるセグメンテーションを実行してもよい。そのようなフラグメント化は、例えばＭＰを使用して実行できる。
【００４１】
ＰＰＰ層５２０は、バッファ深さがパケット１個未満である場合などにインターフェースカードに具体化されるような、ＨＤＬＣ層５３０にパケットを転送することができる。理想的には、最も時間に敏感なパケット、例えばキューＤ_１５１４からのパケットについての最適な遅延特性は、出力バッファへの制限がゼロに設定された時点に到達される。しかし、そのような態様で深さを制限すると、連続的にパケットが送信されない結果となる。一方、出力バッファ５３１の深さ制限が１であると、ほぼ２つのベストエフォートパケットまたはパケットフラグメントの転送時間にほぼ相当する間、キューＤ_１５１４からのパケットを待つという最悪のケースの結果となる。
【００４２】
更に望ましくは、例示的な実施態様に従って、バッファ５３１が空あるいは新規のパケットを入れる準備ができている場合に、ＨＤＬＣ層５３０から妨害を発生することが望ましい。そのような妨害のためのタイミングは、好適には、最悪の場合のパケット待ち時間を約１パケット転送間隔にまで減少させる出力バッファ５３１へキューＦＱ＿ＰＰＰ５２３およびＳＱ＿ＰＰＰ５２２がパケットを送信するタイミングを正確に制御するために最適化される。そのようなタイミングは、例えばソフトウェアルーティンにおいて設定してもよいが、当該技術分野の既知の慣行に従ったハードウェア実行が好ましい。
【００４３】
上記に記載のように、ＨＣパケットの破棄は、受信側でシーケンス番号を見失う結果となり、その結果ヘッダ全体の再送が必要となる。音声等のリアルタイムデータストリームの遅延や中断の可能性を防止するため、破棄は、好適には、ヘッダ圧縮より先になされるべきである。図６に図示された本発明に係る他の実施態様では、スケジューリングがＰＰＰ層６２０で実行される。ＩＰ層６１０に到来するパケットは、優先または分類レベルに関して分析される。ＰＰＰ層６２０においてはスケジューリングに先行して特に優先度または分類に関連したキューの深さがチェックされる。パケットの優先度または分類に関連したキューが満杯の場合、パケットは、ＰＰＰ層６２０でスケジューリングプロセスにより破棄されるかもしれない。優先度または分類に関連するキューが満杯でない場合、ヘッダ圧縮が実行され、ＰＰＰヘッダが付加されて、必要であれば、上記のように、更にパケットキューイングの前に、ＭＰを使用してセグメンテーションが実行される。
【００４４】
本発明の更なる実施態様では、より優先度の高いパケットの最大待ち時間を減少させるため、図７Ａに図示したように、例えば、ＨＤＬＣ層７２０でＨＤＬＣスケジューリングを実行してもよい。先の実施態様のＰＰＰ層６２０およびＩＰ層５１０におけるのと同様に、ＨＤＬＣ層７２０は、最も時間敏感性の高いキューＤ_１７２４からより時間敏感性の低いキューＤ_Ｎ−１７２２までと、ベストエフォートキューＤ_Ｎ７２１まで、様々な程度の時間敏感性を表す一連の優先キュー７２１−７２４を有している。
【００４５】
先の実施態様におけるように、出力バッファ７３０は１パケットの深さにセットされる。キューイングおよびデキューイングについては、図６を参照して先に説明したようなＰＰＰ層６２０に関する場合と同様の方法を使用できる。本実施態様は、「純粋な」ＩＰスケジューラとは考えられず、２ステップのスケジューリングプロセスを１ステップに変更することにより複雑性を減少させることができる。ＭＰ後のスケジューリングによって、ＭＰ拡張が容易に付加される。
【００４６】
ＨＤＬＣ層７２０でのスケジューリングについては、完全なリンク使用を維持しながら出力バッファ７３０から妨害を発生させて、例えば音声パケット等の時間に敏感なパケットについてのパケット待ち時間を改善することは、スケジューリングが例えばインターフェースカード上で実行されるので、最適な解決方法ではない。ＨＤＬＣ層７２０での１バッファの代わりに、図６を参照しながら先に説明したＰＰＰ層６２０でのスケジューリングのために使用したものと同様のスケジューリングアルゴリズムを使用するバッファ７２１から７２４がある。従って、ＩＰ層６１０およびＰＰＰ層７１０においてバックプレッシャーおよびスケジューリングは必要でない。好適には、破棄を操作するために、ＨＤＬＣ層７２０におけるスケジューリング処理と破棄処理の間にシグナリングを実行してもよい。再度留意しなければならないのは、ヘッダ圧縮がＩＰパケットで実行された場合、例えばＤＳバイトに含まれる分類情報が圧縮後には利用不可能となることにより、問題が発生する点である。
【００４７】
従って、図７Ｂに図示された本実施態様では、ローカルバイトまたは「タグ」７５２は、パケット７５１の先頭に、好適には、ＨＤＬＣ層７２０におけるスケジューリングプロセスによって圧縮されたばかりのヘッダに付加されてもよい。タグ７５２は、ヘッダに含まれる情報にとって余分で、圧縮より先に作成された情報を含んでもよい。タグ７５２は、パケット７５１が転送のためにキューに送られる前に除去されてもよい。パケット破棄は、ヘッダ圧縮の前の時点でレート制御とは別に実行できる。レート制御は、ＨＤＬＣ層７２０でのスケジューリングプロセス内で実行できる。パケットを破棄するべきか否かの決定は、好適には、例えばＰＰＰ層７１０におけるバッファ６１１からＩＰパケットを受信した後に実行されるチェックに基づいて行うことができる。パケットが送られるキュー７２１−７２４のうちの対応する１つが満杯の場合、パケットは落とされるか、あるいは、ヘッダ圧縮へ進められる。
【００４８】
このように、本実施態様におけるそれぞれの層の機能を要約すると、ＩＰ層６１０は、ヘッダ圧縮の前にパケット破棄を実行できる。いずれのパケットもヘッダ圧縮に先行して作成された短い「タグ」を有することができ、当該タグは、ヘッダに先に含まれていた情報を含んでもよく、ヘッダが圧縮されたパケットに付加されてもよい。ＰＰＰ層７１０は、例えばＭＰを使用して、長いデータパケットにセグメンテーションを実行してもよい。ＨＤＬＣ層７２０は、例えばソフトウェアデバイスドライバに含まれたスケジューリングを実行してもよく、あるいは、ＨＤＬＣ層７２０は、タグ７５２を付加することができるハードウェアに具現化されてもよい。タグ７５２は、パケット７５１が転送される前に除去できる。
【００４９】
当業者は、本発明がその本質的な特長または精神から逸脱することなく他の特定の態様で実施可能であることを理解しているであろう。本明細書に開示された実施態様は、従って、全ての面で例示的なものであり、制限的なものではない。本発明の範囲は、上記の説明よりもむしろ、附属の特許請求の範囲によって示されており、それと同等の範囲および意味の範疇に入る一切の変更は本発明に含まれる点を指摘しておく。
【図面の簡単な説明】
【図１】 図１は、ＴＣＰ／ＩＰを使用した例示的な圧縮データグラムとフォーマットとを図示する。
【図２】 図２は、例示的なリンクフラグメント化とインターリービングを図示する。
【図３】 図３は、例示的な優先制御を図示する。
【図４】 図４Ａは、マルチリンクＰＰＰのための例示的なフラグメント化フォーマットを図示する。図４Ｂは、マルチリンクＰＰＰのためのショートシーケンス番号と多重クラスに対応する例示的なフラグメント化フォーマットを図示する。図４Ｃは、マルチリンクＰＰＰのためのロングシーケンス番号と多重クラスに対応する例示的なフラグメント化フォーマットを図示する。
【図５】 図５Ａは、本発明に係る例示的な純粋ＩＰスケジューリングを図示する。図５Ｂは、本発明に係る例示的な純粋ＩＰスケジューリングを示すフローチャートである。
【図６】 図６は、本発明に係る、ＰＰＰ層での例示的なＰＰＰスケジューリングを図示する。
【図７】 図７Ａは、本発明に係るＨＤＬＣ層での例示的なＩＰスケジューリングを図示する。図７Ｂは、本発明に係るＨＤＬＣ層での圧縮されたヘッダへに添付される例示的タグを図示する。

Claims (28)

1. 少なくとも１の上位層と少なくとも１の下位層を有する多層プロトコルに従った、通信リンクでの複数の分類を有する複数のパケットの転送における遅延を軽減させるための方法であって、当該方法は、
   複数のパケットのそれぞれを、それらに関連する複数の分類の１つに従ってスケジューリングし、
   スケジューリングできない複数のパケットのそれぞれを破棄し、
   スケジューリングと破棄の後、複数のパケットのうち少なくとも複数のヘッダのそれぞれを圧縮することを含む方法。
2. スケジューリング、破棄および圧縮の後、複数の分類の少なくとも２つに従って、複数のパケットを第一および第二のキューに送るステップを更に含み、ここで第一のキューが第二のキューよりも優先度が高い請求項１に記載の方法。
3. スケジューリングのステップは、
   複数の分類に基づいて複数のキューを確立するステップと、
   複数のパケットのそれぞれを、それらに関連する複数の分類の１つに従って複数のキューの１つに送るステップを更に含む請求項１に記載の方法。
4. 複数の分類がＱｏＳレベルと関連している請求項３に記載の方法。
5. 複数の分類が複数の遅延要素と関連しており、ここで、複数の遅延要素のそれぞれが複数のキューごとに異なる、請求項３に記載の方法。
6. 複数の分類が複数のドロップセンシティビティと関連しており、ここで、複数のドロップセンシティビティ要素のそれぞれが複数のキューごとに異なる、請求項３に記載の方法。
7. 複数の分類がＬＦＩと関連している請求項３に記載の方法。
8. 複数の分類がマルチリンクＰＰＰと関連している請求項３に記載の方法。
9. 少なくとも２の分類の１つがベストエフォートの分類を含み、キューイングのステップが更に、
   複数のパケットのそれぞれがベストエフォートパケットとして分類されるか否かを決定するステップと、
   決定されたベストエフォートパケットを第二のキューに送るステップを含む請求項２に記載の方法。
10. スケジューリングのステップが上位層でスケジューリングを実行するステップを更に含む請求項１に記載の方法。
11. スケジューリングのステップが下位層でスケジューリングを実行するステップを更に含む請求項１に記載の方法。
12. 下位層がＰＰＰ層を含む請求項１１に記載の方法。
13. 下位層がＨＤＬＣ層を含み、下位層においてスケジューリングを実行するステップは、
    圧縮のステップを実行する前に、複数のパケットのそれぞれに、少なくとも複数のヘッダからの情報を含むタグを作成するステップと、
    複数のパケットのそれぞれにタグを付加するステップと、
    複数のパケットのそれぞれを転送する前に、前記タグを除去するステップと、を更に含む請求項１１に記載の方法。
14. 第一および第二のキューに送られた複数のパケットのそれぞれを、キューの深さが１未満の出力キューに出力するステップを更に含む請求項１に記載の方法。
15. 複数の分類を有する複数のパケットの、通信リンクにおける遅延を軽減するための装置であって、当該複数のパケットは少なくとも１の上位層と少なくとも１の下位層を有する多層プロトコルに従って転送される装置であって、当該装置は、
    シリアルリンクと、
    当該シリアルリンクと連結されたインターフェース装置を含み、当該インターフェース装置は、多層プロトコルの実行のための装置であって、当該インターフェース装置は、プロセッサを有し、当該プロセッサは、
    複数のパケットのそれぞれをそれらに関連した複数の分類の１つに従ってスケジュール化し、
    スケジュール化できない複数のパケットのそれぞれを破棄し、および
    スケジューリングと破棄の後、複数のパケットのうち少なくとも複数のヘッダのそれぞれを圧縮するように設定されている装置。
16. 第一と第二のキューを更に含み、プロセッサは、スケジューリング、破棄および圧縮の後、複数の分類の少なくとも２つに従って、複数のパケットを第一および第二のキューに送るように設定されており、ここで第一のキューが第二のキューよりも優先度が高い、請求項１５に記載の装置。
17. スケジューリングの間、プロセッサは更に、
    複数の分類に基づいて複数のキューが確立され、
    複数のパケットのそれぞれが、それらに関連した複数の分類の１つに従って複数のキューの１つに送られるように設定されている請求項１５に記載の装置。
18. 複数の分類は異なるＱｏＳ値と関連している請求項１７に記載の装置。
19. 複数の分類が複数の遅延要素と関連しており、ここで、複数の遅延要素のそれぞれが複数のキューごとに異なる請求項１７に記載の装置。
20. 複数の分類が複数のドロップセンシティビティと関連しており、ここで、複数のドロップセンシティビティ要素のそれぞれが複数のキューごとに異なる請求項１７に記載の装置。
21. 複数の分類はＬＦＩに関連している請求項１７に記載の装置。
22. 複数の分類はマルチリンクＰＰＰと関連している請求項１７に記載の装置。
23. 少なくとも２つの分類の１つは、ベストエフォート分類を含み、プロセッサは、キューイングの間、更に、
    複数のパケットのそれぞれがベストエフォートパケットか否かを決定し、
    決定されたベストエフォートパケットを第二のキューに送るように設定されている請求項１６に記載の装置。
24. プロセッサは、更に、上位層で複数のパケットのそれぞれをスケジュール化するように設定されている請求項１５に記載の装置。
25. プロセッサは、更に、下位層で複数のパケットのそれぞれをスケジュール化するように設定されている請求項１５に記載の装置。
26. 下位層はＰＰＰ層を含む請求項２５に記載の装置。
27. 階層はＨＤＬＣ層を含み、プロセッサは、更に、
    圧縮のステップを実行する前に、複数のパケットのそれぞれに、少なくとも複数のヘッダからの情報を含むタグを作成し、
    、
    複数のパケットのそれぞれにタグを付加し、
    複数のパケットのそれぞれを転送する前に、前記タグを除去するように設定されている請求項２５に記載の装置。
28. キューの深さが１未満の出力キューを更に含み、ここでプロセッサは更に、第一および第二のキューに送られた複数のパケットのそれぞれを出力キューに出力するように設定されている、請求項１５に記載の装置。

Images