JP4523596B2 - ネットワークのためのパケットのフレームへのカプセル化 - Google Patents

Description

発明の詳細な説明

［発明の技術分野］
本発明は、データ通信の技術分野に関し、より詳細には、ネットワークのためのパケットのフレームへのカプセル化に関する。
［発明の背景］
ネットワークプロトコルによると、所与のレイヤにおけるパケットは、パケットを１つノードからネットワークの他のノードに送信するため、それより下位のレイヤにおいてフレームにカプセル化されるかもしれない。各イーサネット（登録商標）フレーム内に各インターネットプロトコル（ＩＰ）パケットをカプセル化するための技術が知られている。また、ネットワークを介しリアルタイムトラフィックの送信をサポートするための技術も知られている。例えば、ある既知の技術は、ＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）を利用して、リアルタイムトラフィックのＱｏＳ（Ｑｕａｌｉｔｙ−ｏｆ−Ｓｅｒｖｉｃｅ）を保証するものであるかもしれない。しかしながら典型的には、既知の技術は、パケットをフレームに効果的かつ効率的にカプセル化することはできない。例えば、既知の技術は、サイズの小さなパケットに対して大きなオーバヘッドを被るかもしれない。また、既知の技術は、コンテンションベースのイーサネット（登録商標）ネットワークにおけるリアルタイムトラフィックの連続的な一様なＱｏＳを保証することができないかもしれない。
［発明の概要］
本発明によると、パケットをフレームにカプセル化するための従来技術に関する短所及び問題点が軽減又は解消されるかもしれない。

本発明の一実施例によると、パケットをフレームにカプセル化することは、ネットワークのいくつかのステーションのあるステーションにおいてパケットを受信することからなる。各パケットは、これらのステーションの少なくとも１つのリアルタイムトラフィックに対応するデッドラインを反映する遅延要求に関連付けされる。パケットは、ステーションのキューに送られる。ネットワークの利用可能なチャネルが検出される。キューの１以上のパケットが、遅延要求に従ってフレームにカプセル化される準備ができているか判断される。１以上のパケットは、利用可能なチャネルを用いて送信のためフレームにカプセル化される。

本発明の実施例は、１以上の技術的効果を提供するかもしれない。一実施例の技術的効果は、ネットワークのキューにおいてフレームにカプセル化されるパケットの個数は、当該キューのデータ量、パケットの遅延要求及びネットワーク状態に従って適応的に調整されるということであるかもしれない。適応的なカプセル化は、カプセル化に伴う帯域幅オーバヘッドを最小限にする。適応的カプセル化は、可変的ネットワークロードの存在により常時リアルタイムトラフィックに対する一様な遅延を保証する。一実施例の他の技術的効果は、適応的カプセル化が送信試行回数を減少させ、スループットパフォーマンスを向上させるということであるかもしれない。

本発明の実施例は、上記技術的効果のすべて又は一部を有するかもしれないし、あるいはその何れも有しないかもしれない。１以上の他の技術的効果は、ここに含まれる請求項、説明及び図面から当業者には容易に明らかとなるであろう。
［発明の詳細な説明］
本発明の実施例及びその効果は、図１〜７を参照することにより最も良く理解される。各図面の同様及び対応する部分について、同様の番号が利用される。

図１は、パケットをフレームにカプセル化するためのシステム１０の一実施例を示すブロック図である。一般に、システム１０は、ネットワーク動作及びパケットの遅延要求に応じて、フレームにカプセル化されるパケット数を管理する。より大きなペイロードは、典型的には、より高い帯域幅効率をもたらすが、またより大きな送信遅延を招くこととなり、パケット遅延要求を満足しなくなるかもしれない。従って、システム１０は、パケット遅延要求の制約の下、帯域幅効率を最大にしようとする。

図示された実施例によると、システム１０は、リンク２２に接続された１以上のステーション２０を有する。ステーション２０は、ネットワークの他のノードに送信されるパケットを上位のインターネットプロトコルレイヤから受信するイーサネット（登録商標）ステーションから構成されるかもしれない。ステーション２０は、パケット遅延要求の制約の下、カプセル化オーバヘッドを最小限にするため、パケットをフレームに適応的にカプセル化する。ステーション２０は、ネットワークからフレームを受信し、フレームをネットワークに送信する入力２４を有する、リンク２２は、システム１０にパケットを伝送するのに利用可能な１以上のチャネルを提供する。リンク２２のチャネルは、対応する動作状態を有するかもしれない。例えば、チャネルは、アイドル、利用可能、ビジー、又は衝突の状態にあるかもしれない。リンク２２は、例えば、イーサネット（登録商標）プロトコルと互換性を有するケーブルから構成されてもよい。

実施例の説明に供するため、テーブル１は、本明細書において用いられる記号をまとまたものである。

システム１０は、ステーションなどのノードを有し、ネットワークノードが互いに通信することを可能にする通信ネットワークにおいてパケットを通信するのに利用可能である。例えば、システム１０は、半二重又は全二重イーサネット（登録商標）ネットワークについて利用されてもよい。通信ネットワークはまた、ＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）、パブリック又はプライベートデータネットワーク、インターネット、ローカル、リージョナル又はグローバル通信ネットワーク、企業イントラネット、他の適切な通信リンク、又は上記の任意の組み合わせのすべて又は一部から構成されてもよい。

システム１０は、適切なパケットを適切なフレームにカプセル化する。パケットは、送信用の特定の方法により構成されたデータ群から構成され、フレームは、送信用の特定の方法により構成された１以上のパケットのペイロードから構成されるかもしれない。一実施例によると、パケットは、インターネットプロトコルパケットのすべて又は一部から構成され、フレームは、ＩＥＥＥ８０２．３規格と実質的に互換性を有するイーサネット（登録商標）メディアアクセスコントロール（ＭＡＣ）フレームから構成されてもよい。

システム１０は、リアルタイム（ＲＴ）と非リアルタイム（ＮＲＴ）の両方のトラフィックをサポートするものであってもよい。リアルタイムパケットは、音声又は映像情報などを搬送する遅延の影響を受けやすいパケットフローから構成され、遅延要求を有するものであってもよい。遅延要求は、パケットが受信機に送信される必要がある時間に従って計算されるデッドラインを有するかもしれない。一実施例によると、遅延要求は、式（１）に従って確率的に表現されてもよい。

ただし、Ｄは任意のパケットのランダムな遅延であり、ｄ_ｉはｉ番目のリアルタイムフローのパケットに係るデッドラインであり、ε_ｉは小さな正数である。ペア（ｄ_ｉ，ε_ｉ）は、ｉ番目のリアルタイムフローの遅延要求を表す。

式（１）の遅延要求の確率的保証は、式（２）により表現されるかもしれない。

ただし、Ｍ^（ｉ） _ｔｏｔは、送信元ステーションにおいて破棄された、又はこれまで送信成功したｉ番目のフローからの一意的パケットの合計であり、Ｍ^（ｉ） _ｖｉｏは、デッドライン違反により破棄されたパケット数である。式（２）は、任意のパケットの確率的遅延保証を１００ε_ｉ未満のパーセントのパケット損失レートにおけるパケットの１００（１−ε_ｉ）パーセントの決定的保証にマッピングする。

一実施例によると、Ｍ^（ｉ） _ｔｏｔとＭ^（ｉ） _ｖｉｏの値は、パケットの代わりにバイト表示されてもよい。一実施例によると、Ｍ^（ｉ） _ｔｏｔとＭ^（ｉ） _ｖｉｏの値を追跡するため、カウンタが利用されてもよい。これらのカウンタは、例えば、システム１０が電力アップされるとき、キューが特定時間以上エンプティとされるときなどセッションが終了されるとき、又は他の適切なイベントなどの任意の適切なイベントによりリセットされるかもしれない。

遅延要求を満足するため、システム１０は、ネットワークを介し伝送されるパケットにより受ける遅延を考慮する。遅延の決定は、到着時間の計算を伴う。到着時間ｔ_ａｒｒ（ｉ，ｊ）は、ｉ番目のキューのｊ番目のパケットの到着時間を表す（ｉ＝１，２，．．．，Ｆ_ｒｔ，ｊ＝１，２，．．．，Ｑ_ｉ）。ただし、すべてのｉとｊについて、ｔ_ａｒｒ（ｉ，ｊ）＜ｔ_ａｒｒ（ｉ，ｊ＋１）である。サイズｓ_ｐ（ｉ，ｊ）は、パケットのサイズを表す。同一パケットの複数の部分は、同じ到着時間を有する個別のパケットとして扱われるかもしれない。一実施例によると、キューｉにおけるパケットの再順序付けは許されない。

任意の適切な処理がｍ次のパケットの到着時間を予測するのに利用されてもよい。一実施例によると、自己回帰（ＡＲ）予測子は時間可変的計数により利用されるかもしれない。自己回帰プロセスのオーダｐ_１とｐ_２は、それぞれパケット間時間とパケットサイズを特徴付ける（ｐ_１＝１及びｐ_２＝１）。パラメータｐ_１及びｐ_２は、予測子のメモリを反映する（過去のデータに応じた時間）。各パラメータの値は、実験データシーケンスのシンプルな自己回帰及び部分自己回帰の統計解析を用いて決定されるかもしれない。

所与のキューにおける次のパケット間時間が予測されるかもしれない。変数ｙ_ｎ（ｎ＝１，２，．．．）は、キューへの入力におけるパケット間時間のシーケンスを表す。当該シーケンスのＡＲ（ｐ_１）の特徴付けは、式（３）により与えられる。

ただし、

は白色ノイズであり（ｎ＝１，２，．．．）、

は時間可変的係数である。これら係数の値は、加重再帰的最小自乗推定法などを利用して各パケット到着に続いて更新される。

の係数は、ｙ_ｎ−１の利用性に従ってＡＲ係数の更新された値を表す。上記値及びｙ_ｎ−１，．．．，ｙ_ｎ−ｐ１の値が与えられると、ｙ_ｎの予測値

が式（４）により与えられるかもしれない。

時間ｔ_ｌａｓｔは直近のパケットの到着時間を表し、

は次のパケットの予測される到着時間を表し、

は次のパケットの予測されるサイズを表す。

の値は、ｔ_ｌａｓｔと予測される到着間の時間の和によって与えられる。

は、パケットがキューに到着するたびに計算される。

フレームサイズｓ_ｆ（ｉ，ｋ）は、ｉ番目のキューから最初のｋ個のパケットを有するペイロードを有するイーサネット（登録商標）フレームのサイズを表す。ただし、ｋ≦Ｑ_ｉである。

である場合、サイズｓ_ｆ（ｉ，ｋ）が式（５）により記述されるかもしれない。

ただし、ｓ_{ｏｖｅｒｈｅａｄ}はフレーム処理オーバヘッドであり、ｓ_ｍｉｎは許容される最小のフレームペイロードであり、ｓ_ｍａｘは許容される最大のフレームペイロードであり、これらのすべてがバイト単位で測定される。例えば、１０Ｍｂｐｓイーサネット（登録商標）の場合、ｓ_{ｏｖｅｒｈｅａｄ}＝２６、ｓ_ｍｉｎ＝４６、ｓ_ｍａｘ＝１５００となる。

定数Ｒ_ｌｉｎｋはビット／秒単位でのリンク容量を表し、時間ｔはリンクを介したワーストケースラウンドトリップ時間を表す。時間Ｔ_ｉ（ｋ）は、ｉ番目のキューからｋ個のパケットを有するフレームの送信時間を表す。衝突がない場合、送信時間Ｔ_ｉ（ｋ）は式（６）により表されるかもしれない。

ただし、Ｉはフレーム間ギャップである。２つのステーションの間の実際のラウンドトリップ時間がｔ未満であるかもしれないため、Ｔ_ｉ（０）＝０である。

ｊ番目のパケットの合計の遅延ｄ_ｉ（ｊ，ｋ）は、式（７）により表されるかもしれない。

ただし、ｔ_{ｃｕｒｒｅｎｔ}は現在の時間を表す。すべてのｉ、ｊ及びｋに対して、遅延ｄ_ｉ（ｊ，ｋ）＞ｄ_ｉ（ｊ＋１，ｋ）である。すなわち、複数のパケットを有するキューについて、期限切れとなる最初のデッドラインは、ＨＯＬ（Ｈｅａｄ−Ｏｆ−Ｌｉｎｅ）パケットのものである。送信先の誤り検出は、何れかのパケットが上位レイヤに送信可能となる前にフレーム全体に対して実行されるため、フレームのパケットは同じ送信時間Ｔ_ｉ（ｋ）を有する。

フレームが送信先に送信されると、当該フレームはアクノリッジされる必要がある。ＩＥＥＥ８０２．３規格は、衝突が検出可能であり、衝突は否定的アクノリッジメントと黙示的にみなすことが可能あるため、送信されたフレームを良好にアクノリッジする必要はない。しかしながら、これはノイズエラーに対するプロテクトではない。一実施例によると、アクノリッジメントフレームが利用されてもよい。受信機によりＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）コードが正しいと検証されると、受信機は、送信元ステーションにアクノリッジメントフレームを送信する。アクノリッジメントフレームは、他の任意のフレームと同様にチャネルについて競合するか、あるいは、チャネルはデータフレームの受信に続くアクノリッジメントフレームの送信のため短期に確保されるかもしれない。

ステーション２０は、計算されたカプセル化効率に従って適応的カプセル化を実行するかもしれない。一実施例によると、ｘバイトのペイロードを有するフレームのカプセル化効率η（ｘ）＝ｘ／（合計フレームサイズ）として表されるかもしれない。一実施例によると、１０Ｍｂ／秒のイーサネット（登録商標）ネットワークについて、許容される最小のフレームサイズは、２６バイトのフレーム処理オーバヘッドを含む７２バイトである。従って、４６≦ｘ≦１５００の場合、パディングバイトは必要とされない。従って、カプセル化効率η（ｘ）は、η（ｘ）＝ｘ／（ｘ＋２６）となる。

他方、０≦ｘ≦４６の場合、フレームサイズが７２バイトとなることを保証するため、パディングが必要とされる。この場合、η（ｘ）＝ｘ／７２となる。従って、カプセル化効率η（ｘ）は、式（８）により表されてもよい。

ＣＳＭＡ／ＣＤプロトコルが適切に動作するため、フレームの送信時間は、イーサネット（登録商標）を開始ワーストケースラウンドトリップ時間（ＲＴＴ）未満とすることはできず、これにより、ステーションはそれのフレーム送信のエンドまでに衝突を検出ことができる。２つのステーション間の最大ワイヤ距離が同じである場合、ワーストケースＲＴＴもまた固定されるかもしれない。従って、イーサネット（登録商標）の送信スピードが増加する場合、許容される最小フレームサイズは、衝突が検出可能となることを保証するため増大される必要がある。例えば、そのレンジを固定し続けながら、１０Ｍｂｐｓイーサネット（登録商標）の送信速度を１０倍に増大することは、１０のオーダによる最小フレームサイズの増大が必要となる。

しかしながら、これは、小さなフレームの場合には非効率な帯域幅利用性を招くかもしれない。あるいは、２つのステーション間の許容される最大ケーブル距離の減少、又は相互接続ステーションのハブに依存することを含む。例えば、１００Ｍｂｐｓイーサネット（登録商標）は、６４バイトの最小フレームサイズを維持するが、１００メータの最大となるステーションハブ間の距離によるハブに依存する。

半二重ギガビットイーサネット（登録商標）は、キャリア拡張を利用し、これにより、相対的に小さなフレームの送信が、フルフレームを送信するのに必要な時間に等しい最小のチャネルビジー時間を保証するキャリア信号の送信に続く。従って、カプセル化効率η_ＧＩＧＡ（ｘ）は、式（９）により表されるかもしれない。

ただし、ｓ_{ｍｉｎＧｂ}は、ギガビットイーサネット（登録商標）の許容される最小のフレームペイロードである。

本発明の範囲から逸脱することなく、変更、追加又は省略がシステム１０に可能である。例えば、システム１０は、より多く、より少なく、又は他のモジュールを有するかもしれない。さらに、システム１０の動作は、より多く、より少なく、又は他のモジュールにより実行されてもよい。さらに、ソフトウェア、ハードウェア、他のロジック、又は上記の任意の適切な組み合わせを有する任意の適切なロジックを利用して、各機能が実行されてもよい。本明細書において利用されるように、「各」とは、集合の各メンバー又は集合の部分集合の各メンバーを表す。

図２は、図１のシステム１０のステーション２０の一実施例のブロック図である。ステーション２０は、図２に示されるように、１以上のリアルタイムキュー３０ａ、１以上の非リアルタイムキュー３０ｂ、プロセッサ２４及び接続されるスケジューラ３４を有するかもしれない。図示された実施例により、ステーション２０は、Ｆ_ＲＴ個のリアルタイムキュー３０ａと、Ｆ_ＮＲＴ個の非リアルタイムキュー３０ｂを有する。リアルタイムキュー３０ａは、リアルタイムパケットフローを受信し、非リアルタイムキュー３０ｂは、非リアルタイムパケットフローを受信する。一実施例によると、異なるリアルタイムフローは異なる遅延要求を有し、同一のリアルタイムフローに属するパケットは、同一の遅延要求を有するかもしれない。

キュー３０ａ及び３０ｂは、パケットを受信、格納及び送信するよう動作可能な任意の適切なバッファから構成されるかもしれない。各キュー３０ａ及び３０ｂは、キュー３０ａ及び３０ｂの動作を管理する制御ロジック３２ａ及び３２ｂを有し、入力を受付け、所定のルールに従って入力を処理し、出力を生成するよう動作可能な任意の適切な装置を有するようにしてもよい。制御ロジック３２ａ及び３２ｂは、例えば、次のパケットの待機が遅延要求の違反を招くか計算し、あるいは適切なサイズのフレームを構成するためカプセル化されるパケットの個数を決定するものであってもよい。

制御ロジック３２ａ及び３２ｂは、現在のラインパケットヘッドから開始し、フレームにカプセル化されるべきｋ^＊ _ｉ個のパケットを維持するかもしれない。ｋ^＊ _ｉ個のパケットは、新たなパケットの到着、フレームの送信成功、パケット遅延要求の期限切れ、他のイベント、又は上記の他の任意の組み合わせなどのイベントに応答して、更新されてもよい。キューｉが送信するのに選択される場合、キューｉは、更新されたｋ^＊ _ｉの値を用いてフレームにカプセル化されるべきパケットを決定するか、あるいは、次のラウンドまで送信を中止する。

フレームペイロードタイマーＦＰＴは、直近に計算されたｋ^＊ _ｉの値に関連付けされてもよい。ｋ^＊ _ｉの新たな値が計算されるときは常に、タイマーが式（１０）に従って設定されてもよい。

タイマーは、ｋ^＊ _ｉ個のパケットのフレームの第１パケット、すなわち、ＨＯＬパケットのデッドラインの期限切れまでに許容可能な計算時間からの追加的なキュー遅延に従って設定される。新たに計算されたｋ^＊ _ｉの値が、ｄ_ｉ（１，ｋ^＊ _ｉ）＝ｄ_ｉを満たすため、Δ^（ｉ） _{ｔｉｍｅｒ}≧０となる。

フレームペイロードタイマーＦＰＴは、ｉ番目のキューがフレームを送信する前に期限切れとなるかもしれない。これは、例えば、チャネルが延長された期間においてビジーである場合、又は、ステーション２０がバックオフ期間にある場合に起こりうる。フレームペイロードタイマーＦＰＴが期限切れとなる場合、ｋ^＊ _ｉの新たな値を求める必要がある。ｋ^＊ _ｉの値は、ｄ_ｉ（１，ｋ^＊ _ｉ）＝ｄ_ｉとなるまで減少される。ｋ^＊ _ｉを減少する過程において、ｋ^＊ _ｉ＝０に到達する場合、ＨＯＬパケットのデッドラインを満たすことは不可能となる。すなわち、ｄ_ｉ（１，１）＞ｄ_ｉとなる。この場合、ステーション２０は、ＨＯＬパケットを破棄し、Ｍ^（ｉ） _ｖｉｏをインクリメントし、ｉ番目のキューを進め、ｋ^＊ _ｉ及びΔ^（ｉ） _{ｔｉｍｅｒ}の値を再計算する。

ＨＯＬパケットを破棄するため、タイマーは、破棄時間Ｔ^（ｉ） _{ｄｉｓｃａｒｄ}を追跡する。パケットがＨＯＬ位置に進むと、タイマーの値は、式（１１）に従って設定されるかもしれない。

破棄時間Ｔ_（ｉ）（１）は、ＨＯＬパケットを送信するのに必要な許容される最小時間である。式（１１）によるタイムアウト値は、ＨＯＬパケットが時間内に送信可能とならないことが予想されるまで、さらに許容可能な追加的なキュー処理時間である。タイムアウト値の設定時において、破棄時間Ｔ^（ｉ） _{ｄｉｓｃａｒｄ}＜０である場合、ＨＯＬパケットは破棄され、キューは進められる。

タイムアウト値を計算する処理は、ｔ_ａｒｒ（ｉ，ｊ）の値とｔ_ａｒｒ（ｉ，ｊ＋１）の値をすべてのｊについて設定し、更新されたｔの値を利用することによって、新たなＨＯＬパケットに対して繰り返される。ＨＯＬパケットによりＴ^（ｉ） _{ｄｉｓｃａｒｄ}＝０となると、パケットの破棄は中止される。

スケジューラ３４は、ステーション２０のキュー３０ａ及び３０ｂにおいてサービス順を決定するのに利用可能である。スケジューラ３４は、任意の適切な処理に従ってキュー３０ａ及び３０ｂを選択するかもしれない。一例として、スケジューラ３４は、キュー３０ａ及び３０ｂが順序付けされるラウンドロビン（ｒｏｕｎｄ−ｒｏｂｉｎ）スケジューリング処理に従ってキュー３０ａ及び３０ｂを選択するかもしれない。他の例として、スケジュール３４は、変更されたラウンドロビンスケジューリング処理に従ってキュー３０ａ及び３０ｂを選択するかもしれない。スケジューラ３４は、フレームの送信が成功した送信元の最後のキュー３０ａ及び３０ｂを追跡する。チャネルが利用可能となると、スケジューラ３４は、フレームを送信すべき次の確保されているキュー３０ａ及び３０ｂを選択する。スケジューラ３４は、リアルタイムキュー３０ａ又は非リアルタイムキュー３０ｂに等しい優先度を与えるか、あるいは、リアルタイムキュー３０ａ又は非リアルタイムキュー３０ｂを優先するかもしれない。

チャネルに衝突がある場合、スケジューラ３４は、ＩＥＥＥ８０２．３規格に規定されるようなバックオフ処理を利用するようにしてもよい。バックオフ期間後、スケジューラ３４は、チャネルがアイドルであるか判断する。チャネルがアイドルである場合、スケジューラ３４は、フレーム間ギャップを待機し、その後、衝突するフレームを送信したキュー３０及び３０ｂからのフレームを送信する。

本発明の範囲から逸脱することなく、ステーション２０への変更、追加又は省略が可能である。例えば、ステーション２０は、より多く、より少なく又は他のモジュールを有するかもしれない。さらに、ステーション２０の動作は、より多く、より少なく又は他のモジュールにより実行されてもよい。例えば、プロセッサ２４とスケジューラ３４の動作は、１つのモジュールにより実行されてもよく、あるいは、スケジューラ３４の動作は複数のモジュールにより実行されてもよい。さらに、各機能は、ソフトウェア、ハードウェア、他のロジック、又は上記の任意の適切な組み合わせからなる任意の適切なロジックを用いて実行されてもよい。

図３は、パケットをフレームにカプセル化する方法の一実施例を示すフローチャートである。本方法は、ステーション２０が利用可能なチャネルを検出するステップ１００から開始される。ステップ１０４において、ステーション２０は、キュー３０ａ及び３０ｂが衝突するフレームを送信したか判断する。キュー３０ａ及び３０ｂが衝突するフレームを送信した場合、本方法は、スケジューラ３４が衝突したフレームを送信したキュー３０ａ及び３０ｂを選択するステップ１０８に移行する。

何れのキューも衝突するフレームを送信していない場合、本方法は、スケジューラ３４が次のキュー３０ａ及び３０ｂを選択するステップ１１２に移行する。次に、キュー３０ａ及び３０ｂを選択するのに利用可能な任意の適切な選択処理に従って、次のキュー３０ａ及び３０ｂが選択されてもよい。例えば、次のキュー３０ａ及び３０ｂは、ラウンドロビン処理に従ってフラグが真であると設定される次のキュー３０ａ及び３０Ｂ又は次の確保されているキュー３０ａ及び３０ｂから選択されてもよい。キュー３０ａ及び３０ｂを選択した後、本方法はステップ１１６に移行する。

ステップ１１６において、スケジューラ３４は、キュー３０ａ及び３０ｂから送信される準備ができたフレームが存在するか示す選択されたキュー３０ａ及び３０ｂのフラグをチェックする。このフラグは、キューにおけるパケットの受信、キュー３０ａ及び３０ｂからのフレームの送信成功、他の適切なイベント、又は上記の任意の組み合わせなどの任意の適切なイベントに応答して設定される。

このフラグは、真が送信準備のできたフレームが存在することを示し、偽が送信準備のできたフレームが存在しないことを示すステップ１２０において、真又は偽に設定される。フラグが真に設定されている場合、本方法は、フレームが送信されるステップ１２４に移行する。フレーム送信後、本方法は終了する。フラグが偽に設定されている場合、本方法は、キュー３０ａ及び３０ｂがスキップされるステップ１２８に移行する。キューのスキップ後、本方法は終了する。

本発明の範囲から逸脱することなく、本方法に対する変更、追加又は省略が可能である。さらに、本発明の範囲から逸脱することなく、各ステップは任意の適切な順序により実行されてもよい。

図４は、パケットの受信に応答して、非リアルタイムキューｉにおいてフラグを更新する方法の一実施例を示すフローチャートである。本方法は、制御ロジック３２ａが、キューｉにおけるパケット数Ｑ_ｉ、フレームにカプセル化可能なパケット数ｋ^＊ _ｉ、及びフレームにカプセル化可能なパケットのサイズＢ^＊ _ｉを初期化する。パケットのサイズＢ^＊ _ｉは、フレームに潜在的にカプセル化可能なｋ^＊ _ｉ個のパケットの合計パケットサイズに対応する。ステップ１５４において、フラグが偽に設定される。最大サイズｓ_ｍａｘより小さい現在パケットサイズｓ_{ｃｕｒｒｅｎｔ}を有するパケットが、ステップ１５８において受信される。最大サイズｓ_ｍａｘは、許容される最大フレームペイロードである。ステップ１６２において、キューｉのパケット数Ｑ_ｉの値が更新される。

ステップ１６６において、フラグは真又は偽に設定される。フラグが真に設定されている場合、フレームのパケット数ｋ^＊ _ｉ及びフレームのパケットのサイズは、キューｉがフレームのペイロードを充填するのに十分なサイズのパケットを有するため、更新される必要はない。従って、ステップ１６６においてフラグが真に設定されている場合、本方法はステップ１９０に移行する。

ステップ１６６においてフラグが偽に設定されている場合、本方法はステップ１７０に移行する。ステップ１７０において、制御ロジック３２ａは、パケットのサイズＢ^＊ _ｉと現在のパケットのサイズｓ_{ｃｕｒｒｅｎｔ}の和が最大サイズｓ_ｍａｘより小さいか、等しいか、又は大きいか判断する。当該和が最大サイズｓ_ｍａｘより小さい場合、本方法は、パケットのサイズＢ^＊ _ｉとパケット数ｋ^＊ _ｉが更新されるステップ１７４に移行する。これらの値を更新した後、本方法はステップ１９０に移行する。

当該和が最大サイズｓ_ｍａｘに等しい場合、本方法は、パケットサイズＢ^＊ _ｉとパケット数ｋ^＊ _ｉが更新されるステップ１７８に移行する。ステップ１８２において、フラグが真に設定される。フラグの設定後、本方法はステップ１９０に移行する。当該和が最大サイズｓ_ｍａｘより大きい場合、本方法は、フラグが真に設定されるステップ１８６に移行する。フラグの設定後、本方法はステップ１９０に移行する。

スケジューラ３４は、ステップ１９０において、次のパケットが存在するか判断する。次のパケットが存在する場合、本方法は、次のパケットが受信されるステップ１５８に戻る。ステップ１９０において次のパケットが存在しない場合、本方法は終了する。

本発明の範囲から逸脱することなく、本方法に変更、追加又は省略が可能である。さらに、本発明の範囲から逸脱することなく、各ステップは、任意の適切な順序により実行されてもよい。

図５は、フレームの送信成功に応答して、非リアルタイムキューｉのフラグを更新する方法の一実施例を示すフローチャートである。本方法は、スケジューラ３４によりフレームがキューｉから送信することに成功したと判断されるステップ２００から開始される。キューｉのパケット数Ｑ_ｉが、ステップ２０４において確定される。パケット数Ｑ_ｉは、ステップ２０８において、ゼロ以上であってもよい。パケット数Ｑ_ｉがステップ２０８においてゼロである場合、本方法は、フレームにカプセル化されるパケット数ｋ^＊ _ｉ及びパケットサイズＢ^＊ _ｉが初期化されるステップ２１２に移行する。ステップ２１６において、フラグが偽に設定される。フラグ設定後、本方法は終了する。

ステップ２０８において、パケット数Ｑ_ｉがゼロに等しい場合、本方法はステップ２２０に移行する。プロセッサ２４は、対応するサイズＢ^＊ _ｉが最大値ｓ_ｍａｘ以下となるキューｉにおけるパケットの合計数Ｑ_ｉ以下のパケット数ｋ^＊ _ｉの最大値を決定する。ステップ２２４において、サイズＢ^＊ _ｉが最大サイズｓ_ｍａｘに等しい場合、本方法は、フラグが真に設定されるステップ２３０に移行する。フラグを真に設定した後、本方法は終了する。サイズＢ^＊ _ｉが最大サイズｓ_ｍａｘ未満である場合、本方法は、フラグが偽に設定されるステップ２３４に移行する、フラグを偽に設定した後、本方法は終了する。

本発明の範囲から逸脱することなく、本方法に変更、追加又は省略が可能である。さらに、本発明の範囲から逸脱することなく、各ステップは任意の適切な順序により実行されてもよい。

図６は、リアルタイムキュー３０ａのフラグを設定する方法の一実施例を示すフローチャートである。本方法は、フレームにカプセル化されるパケット数ｋ^＊ _ｉ及びフレームペイロードタイマーＦＰＴが、キューｉに対して更新されるステップ２５０から開始される。フレームペイロードタイマーＦＰＴが、キューｉにおけるパケットの遅延要求を説明するため、パケットがキューｉに滞留する時間を追跡するのに利用可能である。

ステップ２５４において、キューｉのパケット数Ｑ_ｉが確定される。ステップ２５８において、パケット数Ｑ_ｉがゼロである場合、本方法は、フラグが偽に設定されるステップ２６２に移行する。フラグの設定後、本方法は終了する。ステップ２５８において、キューｉのパケット数Ｑ_ｉがカプセル化されるパケット数ｋ^＊ _ｉより多い場合、本方法はステップ２６６に移行する。ステップ２６６において、フラグが真に設定される。フラグの設定後、本方法は終了する。

キューｉのパケット数Ｑ_ｉがフレームにカプセル化されるパケット数ｋ^＊ _ｉに等しい場合、本方法はステップ２７０に移行する。この場合、利用可能なパケットは、フレームが即座に送信される場合には、パケットデッドラインに違反することなく、１つのフレームに収容することが可能である。しかしながら、キューｉに新たなパケットが到着するまで、カプセル化が延期される場合、ｋ^＊ _ｉ以上のパケットを有するフレームが、パケットデッドラインに違反することなく形成及び送信することが可能となる。

プロセッサ２４は、ステップ２７０において、次のパケットの次のサイズ

を予測する。プロセッサ２４は、ステップ２７２において、カプセル化されるパケットと次のパケットのサイズの和が大きすぎる、すなわち、最大サイズｓ_ｍａｘより大きいか判断する。当該和が大きすぎる場合、すなわち、

となる場合、本方法は、フラグが真に設定されるステップ２７４に移行する。フラグの設定後、本方法は終了する。

当該和が大きすぎない場合、すなわち、

となる場合、本方法は、次のフレームの送信時間が予測されるステップ２７６に移行する。一実施例によると、この送信時間は、以下のように予測されるかもしれない。到着する次のパケットに加えて現在のｋ^＊ _ｉ個のパケットを含むペイロードを有するフレームの予測されたサイズ

は、式（１２）により記述されるかもしれない。

以降のフレームの予測される送信時間は、式（１３）により与えられるかもしれない。

ステップ２８０〜２８４において、３つの条件が確定される。ステップ２８０において、次のパケットの待機が、ＨＯＬパケットのデッドラインの期限切れを招く否か確定される。デッドライン期限切れは、ＨＯＬパケットに関するデッドラインの期限切れを表す。この条件は、式（１４）を用いて確定されてもよい。

ただし、式（１３）の和は、フラグが真に現在設定されているキュー３０ａ−ｂｊ上でなされる。

の項は、他のキューからのフレームの送信により生ずる追加的な遅延の予測である。当該項は、実際の遅延に関する上限でも下限でもない。なぜなら、一部のキューはそのｋ^＊ _ｊの値を以降において増減し、他のキューは次のラウンドまで送信を中止することを決定するかもしれないからである。キューｉに到着する次のパケットは、実際には１つのスケジューリングラウンドより遅く到着するかもしれず、すなわち、

であり、キューｉに判定処理を繰り返させる。次のパケットの予想される到着時間が、離れすぎており、デッドライン違反を生じさせる可能性がある場合、すなわち、

となる場合、キューｉは不要な待機を回避しようとし、フレームのカプセル化及び送信に移行する。

ステップ２８２において、待機が過剰なパケット損失レートを発生させるか確定される。過剰なパケット損失レートは、閾値を満たさないパケット損失レートを表すかもしれない。この条件は、式（１５）により確定されてもよい。

ステップ２８４において、待機することにより大きな効率改善がないか確定される。効率改善は、上述のような効率の向上を表すかもしれない。この条件は、式（１６）により確定されるかもしれない。

ただし、？_ｔｈは、調整可能な効率性閾値である。

次のパケットの到着時間及びサイズが正確に予測され、以降のキューにおけるフレームカプセル化が現在のパケット数ｋ^＊ _ｊから予想されるように実行されたとしても、ＨＯＬパケットのデッドラインを満たすことができることを保証するものではない。デッドラインは、ステーション２０により予想不可能な衝突及びバックオフ遅延により違反されるかもしれない。従って、フレームカプセル化及び送信の遅延が、デッドライン違反を導くと予想される場合、ステーション２０は、パケット違反を許容する余裕がない場合、フレームカプセル化を保留すべきでなく、カプセル化を保留するから生ずる予想される帯域幅ゲインのロスは十分である。

ステップ２８６において、２つ未満の条件が満足される場合、本方法は、フラグが偽に設定されるステップ２８８に移行する。フラグを偽に設定した後、本方法は終了する。ステップ２８６において、少なくとも２つの条件が満足される場合、本方法は、フラグが真に設定されるステップ２９０に移行する。フラグを真に設定した後、本方法は終了する。

フラグを設定するための他の適切な処理が利用されてもよい。例えば、次のパケットの到着時におけるチャネル状態の予測に基づく処理が、利用されてもよい。例えば、ステーション２０は、チャネルがアイドルであった時間の一部を追跡するかもしれない。当該部分は、トラフィックのダイナミックを説明するため、移動ウィンドウを介し計算されるかもしれない。カプセル化されるパケット数ｋ^＊ _ｉがキューｉにおけるパケット数Ｑ_ｉに等しい場合、カプセル化をすべきか否かの決定は、ステップ２８０〜２８４と共に、アイドル時間の一部において確定される条件に依存してなされる。例えば、何れの条件も満足されず、アイドルチャネルの確率が５０％などの特定のパーセントより低い場合、ステーション２０は、次のパケットが到着すると、チャネルが利用可能になる可能性が高くなることを期待して待機することを決定するかもしれない。

本発明の範囲から逸脱することなく、本方法に変更、追加又は省略が可能である。さらに、本発明の範囲から逸脱することなく、各ステップは任意の適切な順序により実行されてもよい。

図７は、リアルタイムキューｉにおいてフレームにカプセル化されるパケット数ｋ^＊ _ｉを更新する方法の一実施例を示すフローチャートである。本方法は、更新イベントが検出されるステップ３００から開始される。更新イベントは、例えば、キューｉからのフレームの送信成功、キューｉにおける新たなパケットの受信、キューｉのＦＰＴが期限切れとなったことの判定、又は他の適切なイベントからなるかもしれない。

制御ロジック３２は、ステップ３０４において、パケット数ｋ^＊ _ｉに対する更新処理を実行するか否か判断する。例えば、次のパケットを受信する場合、２つの可能性がある。前のパケット数ｋ^＊ _ｉの値が、キューｉのパケット数Ｑ_ｉより小さい場合、ｋ^＊ _ｉの値は、フレームがキューｉにすでにパケットを収容することができないため、更新される必要はない。パケット数ｋ^＊ _ｉがＱ_ｉに等しい場合、フレームが新たなパケットを収容することができるか判断するため、更新処理が実行されてもよい。

更新処理が実行されるべきでない場合、本方法は、ｋ^＊ _ｉが更新されないステップ３０６に移行する。更新されない後、本方法は終了する。ステップ３０４において、更新処理が実行されるべきである場合、本方法は、更新処理を開始するためステップ３０８に移行する。ステップ３１２において、パケット数Ｑ_ｉ未満のパケット数ｋ^＊ _ｉの値が選択される。ステップ３１６において、選択されたｋ^＊ _ｉの値が、

を満たすか確定することによって決定される満足いくサイズのフレームを生じさせるか制御ロジック３２ａは判断する。

選択されたｋ^＊ _ｉの値が、ステップ３１６において満足いくサイズを生成しない場合、本方法は、パケット数ｋ^＊ _ｉが更新されないステップ３０６に移行する。当該値を更新しない後、本方法は終了する。選択されたｋ^＊ _ｉの値が満足いくサイズを生成する場合、本方法は、フレームの次のパケットがデッドライン違反を導きながら、制御ロジック３２ａが選択されたｋ^＊ _ｉの値がＨＯＬパケットの時間通りの送信を保証するか判断するステップ３２０に移行する。この条件は、以下の関係式

を用いて確定されてもよい。

選択されたｋ^＊ _ｉの値が時間通りの送信を保証することができない場合、本方法は、パケット数ｋ^＊ _ｉが更新されないステップ３０６に移行する。当該値を更新しない後、本方法は終了する。選択された値が時間通りの送信を保証することが可能な場合、本方法は、パケット数ｋ^＊ _ｉが更新されるステップ３２４に移行する。当該値を更新しない後、本方法は終了する。

本発明の範囲から逸脱することなく、本方法に変更、追加又は省略が可能である。さらに、本発明の範囲から逸脱することなく、各ステップは任意の適切な順序により実行されてもよい。

本発明の実施例は、１以上の技術的効果を提供するかもしれない。一実施例の技術的効果は、ネットワークのキューのフレームにカプセル化されるパケット数が、ネットワーク状態及びキューのパケットデッドラインの変化に応じて適応的に調整されるということである。適応的カプセル化は、カプセル化により生ずる帯域幅オーバヘッドを最小化するかもしれない。一実施例の他の技術的効果は、適応的カプセル化がより少ない送信試行回数を提供し、これにより、スループットパフォーマンスを向上させるということであるかもしれない。

本発明の実施例及びその効果が詳細に説明されたが、添付した請求項により規定されるような本発明の趣旨及び範囲から逸脱することなく、様々な変更、追加及び省略が当業者により可能である。

図１は、パケットをフレームにカプセル化するためのネットワーキングシステムの一実施例を示すブロック図である。 図２は、図１のシステムのステーションの一実施例のブロック図である。 図３は、パケットをフレームにカプセル化するための方法の一実施例を示すフローチャートである。 図４は、パケットの受信に応答して、非リアルタイムキューのフラグを更新する方法の一実施例を示すフローチャートである。 図５は、フレームの送信成功に応答して、非リアルタイムキューのフラグを更新する方法の一実施例を示すフローチャートである。 図６は、リアルタイムキューのフラグを設定する方法の一実施例を示すフローチャートである。 図７は、リアルタイムキューのフレームにカプセル化されるパケット数を更新する方法の一実施例を示すフローチャートである。

Claims (26)

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. 複数のパケットをフレームにカプセル化する方法であって、
    ネットワークの複数のステーションのあるステーションにおいて、各パケットが前記複数のステーションの少なくとも一部に対応するデッドラインを反映する遅延要求に関連付けされる複数のパケットを受信するステップと、
    前記複数のパケットを前記ステーションの複数のキューに導くステップと、
    前記ネットワークの利用可能なチャネルを検出するステップと、
    前記キューが衝突に関する衝突フレームを送信したと判断し、前記判断に応答して前記キューを選択し、選択処理に従って前記複数のキューの前記キューを選択することによって、前記複数のキューの前記キューを選択するステップと、
    潜在的にカプセル化されるある合計パケットサイズを有する１以上の潜在的パケットを有する前記キューにおいて、現在のパケットサイズを有する現在のパケットを受信し、前記現在のパケットサイズと前記合計パケットサイズの和が、前記フレームのペイロードに応じた最大サイズより大きいと判断し、前記和が前記最大パケットサイズより大きい場合、前記キューが前記１以上のパケットを前記フレームにカプセル化する準備ができたと判断し、
    前記フレームのペイロードに対応する残りの合計パケットサイズを有し、潜在的にカプセル化される１以上の残りの潜在的パケットを有する前記キューが、前フレームを送信したことを確定し、前記残りの合計パケットサイズが、最大パケットサイズより大きいか判断し、前記残りの合計パケットサイズが前記最大パケットサイズより大きい場合、前記キューが前記１以上のパケットを前記フレームにカプセル化する準備ができたと判断し、
    前記キューの第１の次のパケットの第１の次のサイズを予測し、前記第１の次のパケットの待機は、デッドラインの期限切れに関連すると決定し、前記キューは、前記決定に従って前記１以上のパケットを前記フレームにカプセル化する準備ができたと判断し、
    前記キューの第２の次のパケットの第２の次のサイズを予測し、前記第２の次のパケットの待機が閾値を満足しないパケット損失レートに関連すると決定し、前記キューは、前記決定に従って前記１以上のパケットを前記フレームにカプセル化する準備ができたと判断し、
    前記キューの第３の次のパケットの第３の次のサイズを予測し、前記第３の次のパケットの待機が効率性向上に関連しないと決定し、前記キューは、前記決定に従って前記１以上のパケットを前記フレームにカプセル化する準備ができたと判断することによって、
    前記複数のキューの前記キューの１以上のパケットが、該１以上のパケットに関連付けされる遅延要求に従ってフレームにカプセル化される準備ができたか判断するステップと、
    前記利用可能なチャネルを利用して、送信のため前記１以上のパケットを前記フレームにカプセル化するステップと、
    から構成され、
    前記１以上のパケットに関連付けされる遅延要求は、前記１以上のパケットが送信される必要がある時間に従って計算されるデッドラインを含むことを特徴とする方法。

Images