JP2012518954A - サービス品質を伴うマネージド共有ネットワーク内でのフレキシブルな予約要求及びスケジューリング機構 - Google Patents

Abstract

マネージドネットワーク中のネットワーク通信をスケジュールするシステム及び方法は、通信ウィンドウ中の通信スロットの予約を要求するネットワークノードの各々から各自のフローに関するサブミッションをネットワークコーディネータにて受信する。サブミッションは、レイテンシ耐性や最大集約量などのスケジューリング情報を含む。ネットワークコーディネータは、通信ウィンドウ中の利用可能な帯域幅を検査し、第１のフローのスケジューリング情報及び帯域幅の可用性に基づいて、第１の要求ノードからの第１のフローに利用可能な帯域幅を割り振るとともに、第２のフローのスケジューリング情報及び帯域幅の可用性に基づいて、第２の要求ノードからの第２のフローへの帯域幅の割振りを後のウィンドウまで延期し、それにより複数の通信ウィンドウにわたって複数の要求ノード間でピークデマンドを再割り振りする。

Description

関連出願の相互参照

本出願は２００９年２月２０日出願の米国特許仮出願第６１／１５４，３３５号の利益を請求しており、この出願はその全体が参照によって本明細書に組み込まれている。

ここに開示する方法及び装置は、概してネットワーク通信に関するものであり、特に、いくつかの態様は、帯域幅の利用を改善するためのスケジューリング機構に関する。

関連技術の詳細

ホームネットワークは、加入者サービスを家中に届けるように構成された数種類のデバイスを含みうる。これらの加入者サービスは、例えば音声及び映像のストリーミングなどのように、マルチメディアコンテンツを家中に配置されたデバイスに届けることを含んでいる。利用可能な加入者サービス数が増えたこと及びこれらが更に普及したことに伴い、各ホームネットワーク内に接続されているデバイス数も同様に増えた。サービス数及びデバイス数が増えることにより、ネットワークノード間の通信を調整する複雑さが増している。

図１Ａのネットワークは、家庭内に実装される同軸ケーブルマルチメディア協会（ＭｏＣＡ）ネットワークの一つの例である。有線通信媒体１００が示されている。有線通信媒体は、同軸ケーブルシステム、電力線システム、光ファイバケーブルシステム、イーサネットケーブルシステム、又は他の同様な通信媒体であってもよい。あるいは、通信媒体は無線送信システムであってもよい。図１Ａの実施形態において、通信媒体１００は予め住居１０１内に配置された同軸ケーブルである。

図１Ａのネットワークは、ある通信プロトコルに従う通信において、複数のネットワークノード１０２、１０３、１０４、１０５、１０６を備える。例えば、その通信プロトコルは、周知の同軸ケーブルマルチメディア協会（ＭｏＣＡ）規格などのネットワーク規格に準拠してもよい。図１Ａの例において、この通信プロトコルは、パケットベースの通信システムを特定する。

いくつかの例では、ネットワーク上の活動はネットワークコーディネータ（ＮＣ）によって制御される。そのようなネットワークでは、ＮＣは、共有通信媒体へのアクセスを管理して、ネットワーク上の送信の「サービス品質（ｑｕａｌｉｔｙ−ｏｆ−ｓｅｒｖｉｃｅ）」を管理する。そのような例の一つでは、複数のノードのうちの一つが、通信プロトコルによって決定される処理に基づいてＮＣの機能を果たすように選択される。例えば、ＭｏＣＡネットワークでは、通信媒体を介して通信する第１のノードが、他のノードがＮＣの機能を既に果たしているか否かを判断するためにサーチを行う。第１のノードであるので、別のノードはネットワーク上にまだ存在しない。従って、その第１のノードがＮＣになる。第２のノードが同様のサーチをするときは、第２のノードによって検出されるビーコンを第１のノードが送出する。ＭｏＣＡプロトコルのアドミッション手順に従って、それらのノード間でアドミッション処理が行われる。アドミッション処理の結果は、第１のノードによって作成されたネットワークへの第２のノードのアドミッションとなる。任意の他の新しいノードがネットワークへのアドミッションを要求するときも、ＮＣはアドミッション手順を実行する。一つ以上のノードがネットワークに加わった後は、プロトコルを使用し、良く定義された一組の判断基準を用いることによって、それらのノードから新しいＮＣとなる一つのノードを選択する。

ＮＣを使用するネットワークでは、ＮＣは、媒体アクセスプラン（ＭＡＰ：Ｍｅｄｉａ Ａｃｃｅｓｓ Ｐｌａｎ）を用いて、複数のネットワークノード間のネットワーク通信をスケジュールする。ＭＡＰはパケットとして送信される。そのようなＭＡＰパケットは、定期的に送信される。ＭＡＰは媒体１００上の全てのトラフィックをスケジュールする。それは、ノードが送信を行うことのできる時間をスケジュールすることを含む。データパケットについての送信時間は、ネットワークのノードによる予約要求に応じて、ＮＣによってスケジュールされる。また、ＮＣは、パケットの制御及び管理を自ら（事前の予約要求なしで）スケジュールしてもよい。

図１Ａを再び参照すると、ノード１０２は、ネットワーク通信モジュール（例えば、ＭｏＣＡノード）として働き、複数のコンピュータ１０９のうちの一つに接続されている。そのようなノードは、複数のコンピュータ１０９が、媒体１００で使用される通信プロトコルに従って、通信媒体１００と通信することを可能にする。テレビが一つ以上の他のネットワークノードからストリームされた媒体を受信して表示できるようにするために、テレビ１１１に関連したモジュールとしてノード１０６が示されている。この他に、ノードは、スピーカ若しくは他の音楽デバイス又はビデオデバイス１０３に付随する（すなわち、接続される又は組み込まれる）ものであってもよい。また、ノードは、例えばインターネットアクセス、デジタルビデオ録画機能、媒体（メディア）ストリーミング機能、又はネットワーク管理サービスを住居１０１に提供するために、インターネットサービスプロバイダ又はケーブルサービスプロバイダ１１２とインターフェースするように構成されたモジュールに付随するものであってもよい。

一例としてＭｏＣＡを再度参照すると、ＭｏＣＡネットワークは、集中型ＮＣを利用して、ノード間のネットワーク通信をセットアップする。データパケットの単一方向トラフィックストリームの各々は、「フローＩＤ」によって識別される。本開示の目的上、「フロー」は、送信ノードと少なくとも一つの受信ノードとの間で送信されるパケットのストリームとして編成された情報伝達手段である。通常、一つのフローは、送信ノードから受信ノードまで伝達される一組の関連情報を含む。その情報は、テレビ又は他の映像モニタ上に表示される映画の全内容を表すデータのデジタルストリームであってもよい。映画をストリーミングするために用いられるデータのストリーム全体が、一つのフローに関連付けられてもよい。こうして、映画の内容を受信ノード１０６にストリーミングするために、固有のフローＩＤがそのフローに割り当てられ、送信ノード１０２から受信ノード１０６に送信されるのに必要なパケットの全て（すなわち、そのフローのパケットの全て）にその固有フローＩＤが関連付けられる。

送信ノード１０２は、そのノード１０２がネットワークの他のノードと通信するために必要な数のフローをセットアップしてもよい。例えば、ドキュメントがパーソナルコンピュータ１０９からパーソナルコンピュータ１１０へ送られることを可能にするために、第２のフローが、ノード１０２と別のノード１０５との間で同時にセットアップされてもよい。

いくつかのホームネットワークは、ネットワーク上で行われる通信に対して適切な優先度（プライオリティ）が確実に設定されるように、サービス品質（ＱｏＳ：ｑｕａｌｉｔｙ ｏｆ ｓｅｒｖｉｃｅ）パラメータを指定する。ＱｏＳパラメータを使用することで、望ましくない割込み又は遅延なしに、十分なリソースをユーザコンテンツの通信に確実に割り振ることもできる。例えば、ビデオゲームをプレイしているユーザの供するコマンドがゲーム機に通信されてモニタ又はテレビに高速で表示されたときにのみ、ユーザは望ましい体験をすることになる。そのようなゲーミングコマンドの実行において遅延が生じると、体験の質が著しく損なわれる可能性がある。従って、ＱｏＳパラメータ及びプロトコルの使用は、ユーザが満足のいく体験をすることを保証し、その一方で、コンテンツがレイテンシ（すなわち、遅延）に対する高い耐性を有する場合に、リソースが情報の通信に必要以上に速く無駄に消費されないことを保証するのに役立つ。

ホームネットワークでは、ＱｏＳは、パラメータ化ＱｏＳ（Ｐａｒａｍｅｔｅｒｉｚｅｄ ＱｏＳ：ＰＱｏＳ）及び優先度付きＱｏＳ（Ｐｒｉｏｒｉｔｉｚｅｄ ＱｏＳ）の二つの主要グループに分類することができる。パラメータ化ＱｏＳは、「トラフィック仕様」（ＴＳＰＥＣ：Ｔｒａｆｆｉｃ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）によって規定される定量化された品質基準を各フローに提供する。パラメータ化ＱｏＳフローのＴＳＰＥＣは、フローの制約及びパラメータを規定する。ＰＱｏＳフローのＴＳＰＥＣは、通常、ピークレート、最大パケットサイズなどの情報を含む。例えば、ＰＱｏＳが実施されるＭｏＣＡネットワークでは、ピークレートパラメータは、（ＭＡＰサイクルのような）非常に短い時間間隔で送信する必要のあるデータの（バイト単位での）最大量を示す。パラメータ化ＱｏＳフローの各々は、そのフローが任意のデータパケット送信を開始することが可能になる前に、まずフォーマルＰＱｏＳフローアドミッション処理を経なければならない。ＰＱｏＳフローアドミッション処理は、ＱｏＳ（ＴＳＰＥＣに付随するパラメータを満たしうること）を保証するために、適切なノードレベルリソース（バッファなど）及びネットワークレベルリソース（ネットワーク送信時間やネットワーク送信の適時性など）をそのフローに関与する全てのノードが予約することを可能にする。ＰＱｏＳフローが「アドミット」されると、送信ノードから一つ以上の受信ノードまで全てのフローを適時に送信するために必要なリソースが保証される。ＰＱｏＳフローアドミッション処理の後にＰＱｏＳフローが拒否されると、ＰＱｏＳフローを開始することはできない。一方、優先度付きＱｏＳに関しては、アドミッション処理はない。優先度付きＱｏＳフローの各々は、フローを送るノードによって優先度を割り当てられる。優先度の割当ては、フローをある優先度グループに単に配置する。最も高い優先度を有するグループ内のそれらのフローは、比較的低い優先度を有するグループ内のフローの前に送信することができる。しかしながら、ＰＱｏＳフローとは異なり、優先度付きＱｏＳフローは、フローのパケットが確実に送信されるために必要なリソースを得ることを保証されていない。

ＮＣが特定の量のネットワーク帯域幅を予約するため、また、関連するノードが十分なノードレベルリソースを予約して、ＰＱｏＳフローによって要求されるリソースを実際のデータパケット送信フェーズ（段階）中に必要になったときに確実に利用できるようにするためには、ＰＱｏＳフローのみがＰＱｏＳフローアドミッション処理を経なければならない。ＰＱｏＳフローのデータフェーズは、そのフローの個々のデータパケット又はデータパケットのグループのために送信ノードが実際に予約要求を行うフェーズである。また、データフェーズ中に、予約要求は、この要求に関するネットワーク帯域幅の可用性（利用可能性）に応じて、ＮＣによって「承認」（すなわち、スケジュール）又は破棄される。次いで、ＮＣは、ＭＡＰを送信して、要求ノードを含むネットワークの全てのノードにスケジュールを示す。次いで、各要求ノードは、ＭＡＰによって示されたスケジュールに従ってパケットを送信する。ＭＡＰ及び予約要求に関する更なる詳細は、以下で述べる。

ＰＱｏＳフローのデータフェーズは、ＰＱｏＳフローアドミッションフェーズが成功した後にのみ、開始することができる。他の（すなわち、優先度付き）ＱｏＳフローに対してリソースは保証されないので、ノードは、常に、拒否されたＰＱｏＳフローを優先度付きＱｏＳフローに格下げし、優先度付きＱｏＳレベルでそのフローの送信を開始することができる。

全てのＰＱｏＳフロー間で更なる区別を作り出すために、ＰＱｏＳフローの中で各フローに優先度を割り当ててもよい（優先度付きＱｏＳフローと同様）。しかしながら、仮に比較的低い優先度が割り当てられたとしても、ＰＱｏＳフローのために予約された帯域幅が他のＰＱｏＳフローによって完全に使用されていなかった場合、ＰＱｏＳフローは、常に、優先度付きＱｏＳフローなどの非ＰＱｏＳフローの前に送信される。ＰＱｏＳフローのために予約された帯域幅が、送信すべきＰＱｏＳパケットの全てを送信するためには不十分である場合、より高い優先度を有するＰＱｏＳフローに付随するパケットが、まず送信される。

ＭＡＰサイクルは約１ミリ秒の長さである。ＭＡＰサイクルは複数のタイムスロットに分割される。各ＭＡＰサイクルの間、ＮＣは、次のＭＡＰサイクルの各タイムスロットの間にどのノードが送信を行うか（次のＭＡＰサイクルにおけるどのスロットが次のＭＡＰパケットを含有するかを含む）を示すＭＡＰパケットを送信する。

図１Ｂは、ＭＡＰ２０１、２０２とＭＡＰサイクル２０３、２０５との間のタイミング関係を示すタイミング図である。ＭＡＰサイクル２０５は、先に送られたＭＡＰ２０１の制御下におけるチャネル上の通信動作（アクティビティ）として定義される。従って、各ＭＡＰ２０１は、次のＭＡＰサイクル２０５のための全ての通信動作をスケジュールする。そのような「次のＭＡＰサイクル」２０５の一つのみが図ｘに示されているが、ＭＡＰサイクル２０５に続くＭＡＰサイクルのための全ての通信を、ＭＡＰサイクル２０２がスケジュールすることが分かる（図示しない）。次のＭＡＰ２０２は、先のＭＡＰ２０１のスケジューリング制御の下で、次のＭＡＰサイクル２０５中に送られることに留意されたい。従って、次のＭＡＰサイクル２０５内に送られる各パケットについて、ＭＡＰ２０１は、次の情報、すなわち、ｉ）パケット開始時間、ｉｉ）パケット持続時間、ｉｉｉ）ソースノード、及びｉｖ）（一つ以上の）宛先ノードを決定する。同様に、ＭＡＰ２０２は、後続のＭＡＰサイクルに関するこれらの情報を決定する（図示しない）。パケット開始時間と、その開始時間に送信されるパケットに関するパケット持続時間と、そのパケットに関するソースノード及び（一つ以上の）宛先ノードとの組み合わせは、本明細書において「送信スロット割当て」と呼ばれる。本明細書で説明されるように、パケット長は、パケット中のバイトの数であり、パケット持続時間は、そのバイト数を送信するために要する時間の総計であることに留意されたい。

ＭＡＰ２０１、２０２がスケジューリングを受け持つ特定の種類のパケットは、予約要求（ＲＲ：Ｒｅｓｅｒｖａｔｉｏｎ Ｒｅｑｕｅｓｔ）２０７、２０９、２１１である。そのような６個のＲＲが図ｘの第１のＭＡＰサイクル２０３内に示されており、これらは最初のＲＲ２０７で始まり、最後のＲＲ２０９で終わる。一つのＲＲ２１１が第２のＭＡＰサイクル２０５内に示されている。各ＲＲ２０７、２０９は一つのノードから送られる。各ＲＲ２０７、２０９は、一つ以上の予約要求要素（ＲＲＥ：Ｒｅｓｅｒｖａｔｉｏｎ Ｒｅｑｕｅｓｔ Ｅｌｅｍｅｎｔ）を含有することができる。各ＲＲＥは、一つ以上のイーサネットパケットを含有する一つのＭｏＣＡパケットを送信するためにＲＲ２０７、２０９を送るノードからの要望に関する情報を伝達する。一つのＭｏＣＡパケットは、集約（アグリゲーション）と呼ばれる処理を通じて、二つ以上のイーサネットパケットを含有することができる。

このことから、ＲＲ２０７、２０９、２１１は、対応するクライアントノードが送りたいパケットを有していることを示し、したがって、それらのクライアントノードがそれらのパケットを送信できるときにＮＣが一つ以上の時間間隔を後続のＭＡＰサイクル中にスケジュールすることを要求するために、クライアントノード（すなわち送信ノード）によって送られることが分かる。従って、一つのフローの次のパケット又は次の一組のパケットの送信準備ができている場合、そのクライアントノードは、まず、クライアントノードがＲＲ２０７、２０９、２１１を送ることのできる時間をＮＣが割り振るのを待たなければならない。クライアントノードがＲＲ２０７、２０９、２１１を送ることのできる時間をＮＣが割り振ったら、クライアントノードは、その割り振られた時間に（すなわち、パケット開始時間に、ＭＡＰ２０１、２０２によって示されるパケット長にわたって）、ＲＲ２０７、２０９、２１１をＮＣに伝達する。図１Ｂは、これらのＲＲ２０７、２０９が時間順に送信される事例を示していることに留意されたい。しかしながら、いくつかのシステム（図示しない）では、直交周波数分割多元接続（ＯＦＤＭＡ：Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）方式を使用することができる。そのようなＯＦＤＭＡ方式において、各ＲＲは副搬送波の別個のグループで変調され、全てのＲＲは異なる要求ノードによって同時に送信される。

ＲＲ２０７、２０９は、クライアントノードが、それが送ることを望むデータパケットを有することをＮＣに伝達できるようにする。さらに、ＲＲ２０７、２０９は、それらのデータパケットについて、関連付けられた一つ以上の宛先ノード、パケット長（ここからパケット持続時間を決定できる）、パケット優先度、フローＩＤなどを示す。ＮＣは、これらの情報を用いて、そのクライアントノードが送ることを望むそれらのデータパケットを送信可能な「送信スロット」をスケジュールする。次いで、ＮＣは、次のＭＡＰサイクル２０５のための送信スロット割当てを有するＭＡＰ２０１を生成及び送信することによって、そのスケジュールを伝達する。非ＰＱｏＳ（すなわち優先度付きＱｏＳ）ＲＲＥは、一つの非ＰＱｏＳフローに対して一つであり、一方、ＰＱｏＳ（すなわちパラメータ化ＱｏＳ）ＲＲＥは、一つのＰＱｏＳフローに対して一つである。次のＭＡＰサイクル２０５中にＮＣがスケジューリングを行えないＲＲＥは破棄されるので、そのようなＲＲＥは、それらを生成したノードによって再送されなければならない。

アドミットされた全ＰＱｏＳフローが必要とされるリソースの全てを有することをＮＣが保証するために、ＮＣは、どれほどのレイテンシ制限内で、どのくらいの帯域幅を各ＰＱｏＳフローが必要とするかを決定しなければならない。

ネットワークをサポートするＰＱｏＳでは、いかなるＰＱｏＳフローも、ＰＱｏＳフローに割り当てられた優先度にかかわらず、比較的短い所定の時間（通常は数ミリ秒）内に送られることが保証されることを理解されたい。ＮＣは、そのフローのＴＳＰＥＣに規定されたパラメータセットを評価することによって、どのくらいの量の帯域幅が必要とされているかを決定する。上記のように、ＴＳＰＥＣは、通常、最大パケットサイズ、ピークレートなどを含む。通常、ネットワークをサポートするパラメータ化ＱｏＳは、ＰＱｏＳフローをサポートするための総ネットワーク容量を所与の割合まで使用する。例えば、一つのＮＣは、ＰＱｏＳフローへの割当てのために、送信スロットの８０％を各ＭＡＰサイクル内で予約することができる。新しいＰＱｏＳフローのために必要な帯域幅の量と、既存のＰＱｏＳフローのために予約された量とを決定することによって、ＮＣは、新しいＰＱｏＳフローをアドミットするために十分な容量を有するか否かを判断することができる。一つの新しいＰＱｏＳフローがアドミットされると、ＮＣは、その新しいＰＱｏＳフローのために十分な可用帯域幅が確実に存在するようにする。

通常、これらのＰＱｏＳフローは独立しているので、それらのピークトラフィック期間は、同時又はほぼ同時に生じることもあれば、生じないこともある。ＰＱｏＳフロー制約を確実にサポートできるように、ＮＣは、ノードが行いうる任意の要求において定められたピークレートを扱うために十分な帯域幅を予約する。したがって、最悪の事態のピークＰＱｏＳフロー期間をサポートするように所与の量のＭｏＣＡ帯域幅が予約される場合、確保されたＭｏＣＡ帯域幅の量は、通常、実際にＰＱｏＳトラフィックのために使用される平均帯域幅よりも著しく大きい。つまり、フローが時間的に不均一に分散した独立の事象であり、実際、しばしば極めてバースト的となりうることを考慮に入れながら最悪のケースのピークレートシナリオに対処するために、ＮＣは、実際に用いられるＰＱｏＳ帯域幅の平均総量を大きく超える、ＰＱｏＳ優先度のネットワーク帯域幅を予約しなければならない。これにより、ネットワークにおけるＰＱｏＳ帯域幅の所与の総量に対して、ネットワークでアドミットされうるＰＱｏＳフローの数及びそれらの総帯域幅が制限される。したがって、ＮＣ及び送信ノードがＰＱｏＳ帯域幅をより効果的に予約及び割り振ることを可能にする方法及び装置が要望されている。

更に、ＰＱｏＳフロー及び優先度付きＱｏＳフローの双方について、各フローがそのパケット集約（アグリゲーション）を最大限に高めることができれば、全体のネットワーク効率が増す。したがって、送信スロットのスケジューリングにおいて、より優れた集約効率を提供する方法及び装置が要望されている。

また更に、ＭｏＣＡ１．１業界標準によれば、予約要求は、データパケットが要求ノードのデータバッファ内にすでにあり、かつ、送信準備ができているときに生成される。データパケットが送信ノードのバッファ内にあるときまで予約要求はされないので、パケットが緊急（ｉｍｍｉｎｅｎｔ）であることをノードが知っているときに得られる効率は失われる。したがって、ＮＣが帯域幅をより効果的に予約することを可能にして、ホーム通信ネットワークのノードが送信ノードのバッファ内に存在するパケットより前に予約要求を行えるようにする方法及び装置が要望されている。

概要

本開示の方法及び装置の一実施形態では、ＰＱｏＳフローアドミッション処理は、ＰＱｏＳフローのために予約された帯域幅をより好適に利用する手法でネットワークコーディネータ（ＮＣ）がＰＱｏＳフローをアドミットできるように、従来のアドミッション処理で提供されるものを超える追加情報を含む「送信仕様」（ＴＳＰＥＣ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）を提供することを含む。特に、一実施形態において、ＰＱｏＳフローアドミッション処理は、「短期平均レート（ＳＴＡＲ：Ｓｈｏｒｔ Ｔｅｒｍ Ａｖｅｒａｇｅ Ｒａｔｅ）として定義される新しいパラメータの指示を含む。一実施形態において、ＳＴＡＲは、フローのコスト関数（Ｃｏｓｔ Ｆｕｎｃｔｉｏｎ）と呼ばれる値に等しい。他の実施形態では、フローのコスト関数を決定するために、ＳＴＡＲがレイテンシ耐性とともに用いられる。更に、ＰＱｏＳフローアドミッション処理の間、ＮＣは、ＰＱｏＳフローのためにネットワーク内で予約された帯域幅の量を考慮する。ＮＣは、フローのＳＴＡＲと、以前にアドミットされた他のＰＱｏＳフローに既に割り振られた量とを考慮し、残存する利用可能なＰＱｏＳ帯域幅に基づいて、ＰＱｏＳフローをアドミットする。

更に、本開示の方法及び装置は、要求ノードの各自のフローのパケットを送信できる期間である、通信ウィンドウ（例えばＭｏＣＡ ＭＡＰサイクル）中の一つ以上の通信スロットの予約要求を作成する処理を提供する。本開示の方法及び装置に係るそのような予約要求の一つは、スケジューリング情報を含んでおり、「便宜的予約要求」（ＯＲＲ：Ｏｐｐｏｒｔｕｎｉｓｔｉｃ Ｒｅｓｅｒｖａｔｉｏｎ Ｒｅｑｕｅｓｔ）と呼ばれる。そのようなスケジューリング情報は、少なくとも以下のうちの一つを含む。すなわち、（１）要求されているフローのレイテンシ耐性、及び（２）要求ネットワークノードがその最大集約量に達したか否か、の少なくとも一つである。スケジューリング情報を用いることで、ＮＣは、遅延に耐えることのできるＰＱｏＳフローのパケットに対してＰＱｏＳ帯域幅の割振りを延期することができる。フローのスケジューリング情報及びＰＱｏＳ帯域幅の可用性に基づいてＰＱｏＳ帯域幅の割振りを後のウィンドウまでずらすことにより、ＮＣが、複数の通信ウィンドウにわたって、複数の要求ノード間でデマンドを再割り振りすることが可能になる。

一実施形態において、全ての予約要求要素（ＲＲＥ）は、以下の「ＱｏＳ優先度レベル」（１）ＰＱｏＳ ＲＲ、（２）ＰＱｏＳ ＯＲＲ、（３）優先度高ＲＲ、（４）優先度中ＲＲ、（５）優先度低ＲＲ、（６）優先度バックグラウンドＲＲ、（７）優先度高ＯＲＲ、（８）優先度中ＯＲＲ、（９）優先度低ＯＲＲ、（１０）優先度バックグラウンドＯＲＲ、に分類される。この序列に加えて、最大集約量に達したパケットのための送信スロットを要求している、同じＱｏＳ優先度レベル内のＲＲＥは、より上の序列に移動する。

本開示の方法及び装置の一実施形態によれば、ノードは、ＯＲＲ要素か従来の（伝統的な）ＲＲＥのいずれかを用いることを選択することができる。そのような実施形態の一つにおいて、ＯＲＲ要素は、ＯＲＲ要素内のフラグによって識別される。そのフラグがセットされない場合、要求は従来のＲＲＥである。従来のＰＱｏＳ ＲＲＥはレイテンシ耐性パラメータを有さないので、パケットを即座に送信しなければならないことが想定される。従って、従来のＰＱｏＳ ＲＲＥは、最も高い優先度を与えられる。同様に、従来の優先度付きＲＲＥは、優先度付きＯＲＲ要素よりも高い優先度を与えられる。

一実施形態において、ＮＣは、最も高い優先度のＲＲＥから最も低い優先度のＲＲＥまで、優先度の順に、各ＲＲＥに関するスケジューリング情報を評価する。通常、この評価は、これらのＲＲＥを、同じ種類で同じパラメータを有する他のＲＲＥと共に一つのグループにグループ化することによって行われる。例えば、一つのＭＡＰサイクルに等しい値の生存時間（ｔｉｍｅ ｔｏ ｌｉｖｅ）を有するパケットであって最大集約量に達したパケットのための全てのＰＱｏＳ ＲＲＥは、一緒にグループ化され、一つの送信スロットが最初に割り当てられる。一つのＭＡＰサイクルに等しい生存時間値を有するパケットであって最大集約量に達していないパケットのための全てのＲＲＥは、一緒にグループ化され、次の一組の送信スロットが割り当てられる。このグループ化及び割当ては、次のＭＡＰサイクルのための送信スロットが全て割り当てられるまで続く。特定の序列についての更なる情報は、以下で述べる。

種々の実施形態において、レイテンシ耐性情報は、フローが任意のレイテンシに耐えることができるか否かに関する２進表現とすることが可能である。この他に、そのレイテンシ耐性情報は、フローが耐えることのできるレイテンシの量に関する情報とすることが可能である。レイテンシ耐性の値は、ＭＡＰサイクルの数で、又はミリ秒を単位として、又はＮＣがＲＲＥに適切に優先順位を付けられるようにする任意の他の形式で提供することができる。

本開示の方法及び装置の他の特徴及び態様は、本開示の方法及び装置の実施形態に係る特徴を例として示す添付の図面と併せて、以下の詳細な説明から明らかとなる。本概要は、特許請求された発明の範囲を限定するものではなく、特許請求された発明の範囲は、本明細書に添付された特許請求の範囲のみによって規定される。

本開示の方法及び装置は、以下の図面を参照して詳細に説明される。図面は、図示の目的のためにのみ提供されている。従って、これらの図面は、読者が開示された方法及び装置を容易に理解するために提供されており、特許請求された発明の広がり、範囲、又は適用可能性を限定するものとして考慮されないものとする。図示の明確さ及び容易さのため、これらの図面が必ずしも一定の縮尺で作製されないことに留意すべきである。

図面は、特許請求された発明を開示された厳密な形状に包括する又は限定するものではない。開示された方法及び装置は、変形及び変更を伴って実施可能であることが理解されるべきであり、特許請求された発明は特許請求の範囲及びこれらと同等のものによってのみ限定されるべきである。

図１Ａは、本開示の方法及び装置のいくつかの実施形態を実施可能な一つの環境の例を示す図である。

図１Ｂは、ＭＡＰとＭＡＰサイクルとのタイミング関係を示すタイミング図である。

図２は、本明細書に記載されたシステム及び方法の一実施形態に係るネットワークリソースをスケジュールする処理例を示す図である。

図３は、本明細書に記載されたシステム及び方法の一実施形態に係る便宜的予約要求を用いて予約を行う複数のノード間でネットワークリソースを割り振る処理例を示す図である。

図４は、本明細書に記載されたシステム及び方法の一実施形態に係る予約要求タイプを決定する処理例を示す図である。

図５は、本開示の方法及び装置の実施形態の様々な特徴を実施する際に使用することの可能な例示の計算モジュールを示す図である。

詳細な説明

本開示の方法及び装置の様々な実施形態によれば、ネットワーク上のノード（ネットワークデバイスとも呼ばれる）及びネットワークコーディネータ（ＮＣ）は、ＰＱｏＳフローのためのＰＱｏＳフローアドミッション処理に入る。これは、ＮＣと、フローのパケットを受信又は送信することになるノードの各々とによって、リソースを割り振る（すなわち、そのＰＱｏＳフローのアドミッションを得る）ためである。ＮＣは、「トラフィック仕様」（ＴＳｐｅｃ：Ｔｒａｆｆｉｃ Ｓｐｅｃｉｆｉｃａｔｉｏｎ）に規定されたパラメータに基づいて、ＰＱｏＳフローをアドミットするか否かを決定する。このＴＳｐｅｃは、本明細書において短期平均レート（Ｓｈｏｒｔ Ｔｅｒｍ Ａｖｅｒａｇｅ Ｒａｔｅ：ＳＴＡＲ）と呼ばれるパラメータを含み、また、レイテンシ耐性パラメータを含んでいる。Ｔｓｐｅｃは、フロー内で伝送される情報が送信され他端で受信されるために何が必要かを、満足なユーザ体験を提供するように示す。本開示の目的上、「フロー」は、送信ノード及び少なくとも一つの受信ノード間における情報パケットの伝達手段である。

本開示の方法及び装置の一実施形態において、ＮＣは、ＰＱｏＳフローのために所定量の帯域幅を予約する。フローの全てのパケットをネットワークによって確実にサポートできるように十分な帯域幅がある場合（すなわち、新しいＰＱｏＳフローのアドミッションが、ＰＱｏＳフローのために予約された帯域幅に過度の要求をしない場合）、ＮＣは、要求されたＰＱｏＳフローをアドミット（許可）する。

一つのＰＱｏＳフローがアドミットされると、そのフローを生み出したノードがＮＣに「予約要求要素」（ＲＲＥ）をサブミット（提出）する。それらのＲＲＥは、ＮＣによって生成された媒体アクセスプラン（ＭＡＰ）において割り振られたスケジュール済み送信スロット中に、ＮＣに送信される。それらのＲＲＥは、単一の「予約要求」ＲＲにグループ化される。同じような状況にある他の各ノードも、複数のＲＲＥを有するＲＲを送ることになる。ＮＣは、帯域幅割振り（すなわち、送信スロット割当てを割り振ること）を行う際、各ＲＲＥに含まれるパラメータを検査する。一実施形態では、ＲＲＥのパラメータによって、予約されたＰＱｏＳ帯域幅をより良く利用してネットワーク効率／容量を最大にするようにＮＣが送信スロット割当てを割り振ることが可能になる。

一実施形態では、全てのＲＲＥは、下記の「ＱｏＳ優先度レベル」、すなわち、（１）ＰＱｏＳ ＲＲ、（２）ＰＱｏＳ ＯＲＲ、（３）優先度高ＲＲ、（４）優先度中ＲＲ、（５）優先度低ＲＲ、（６）優先度バックグラウンドＲＲ、（７）優先度高ＯＲＲ、（８）優先度中ＯＲＲ、（９）優先度低ＯＲＲ、及び（１０）優先度バックグラウンドＯＲＲ、に分類される。この序列に加えて、最大集約量に達したパケット用の送信スロットを要求しているＲＲＥは、同じＱｏＳ優先度レベル内で序列を上げる。

ＰＱｏＳ ＲＲは、レイテンシ耐性（例えば、ＴＴＬ）パラメータを考慮されていないＲＲＥである。ＰＱｏＳ ＲＲは、ＲＲＥがＰＱｏＳ ＲＲであることを示すフラグセットを有する。

ＰＱｏＳ ＯＲＲは、ＰＱｏＳフローアドミッション処理の間にネットワークレベルリソース及びノードレベルリソースを予約することにより、ユーザの体験する品質に悪影響を与えずにパケットが届けられることをネットワークが保証するＲＲＥである。このため、レイテンシ耐性及び／又は最大集約量が、ＲＲＥが送信スロットを要求しているパケットに対して指定される。

優先度ＲＲは、ユーザの体験する品質に悪影響を与えずにパケットが届けられることをネットワークノードが保証しないＲＲＥである。これは、アドミッション処理を通じたリソース予約が元から存在しないからである。しかしながら、これらのＲＲＥは、他の優先度ＲＲに関する優先度を示すパラメータを有する。一実施形態では、示すことの可能な四つの優先度レベル、すなわち（１）高、（２）中、（３）低、及び（４）バックグラウンドがあることに留意されたい。必要な場合には、他の数の優先度レベルを用いてもよい。

優先度ＯＲＲは、ユーザの体験する品質に悪影響を与えずにパケットが届けられることをネットワークノードが保証しないＲＲＥである。それにもかかわらず、ＲＥＥが送信スロットを要求しているパケットについて、最大集約量（及び、利用可能な場合には、オプションのレイテンシ耐性）が指定される。これは、その要求の関連する優先度をＮＣが設定することを補助するためである。

一実施形態において、ＰＱｏＳ ＯＲＲは、フローのＴＳｐｅｃによって許容されるレイテンシの指示を含む。レイテンシを指示する手法の一例は、「生存時間（ｔｉｍｅ−ｔｏ−ｌｉｖｅ）」（ＴＴＬ）パラメータである。また、他の実施形態では、ＰＱｏＳ ＯＲＲ及び優先度ＯＲＲは、ノードがその最大集約量に達しているか否かに関する指示を含む。最大集約量は、関連するパケットが、単一のＭｏＣＡパケットヘッダを有する送信のために一緒に集約できる数の情報ユニットを蓄積したか否かを示す。

従って、これらの実施形態では、帯域幅割振りを行う際に用いることの可能な追加情報をＮＣは有する。例えば、ＮＣはレイテンシパラメータを調べることができ、ノードによって送信スロットが要求されているパケットがより長いレイテンシに耐えられる場合、そのＲＲＥに関連付けられたパケットの送信を後まで遅延させるか否かを、ＮＣは決定することができる。ここに開示する方法及び装置は、ＭｏＣＡネットワークの例を用いて開示されていることに留意されたい。しかしながら、ＭｏＣＡネットワークは、単に、その方法及び装置を包含するネットワークの種類の一例にすぎないことが、当業者には理解されるであろう。

更なる例として、情報が例えばＭＡＰサイクル等の通信ウィンドウで通信される、例えばＭｏＣＡ等のネットワークにおいて、比較的高いレイテンシ耐性を有する第１のアドミットされたフローによって、大量の帯域幅が必要とされる（すなわち、送信される準備のできたフローに関連する比較的多数のＰＱｏＳパケットが存在する）ことを想定する。更に、第２のアドミットされたフローのいくつかのパケットも送信準備ができており、それゆえノードが大量の帯域幅を要求しているが、そのレイテンシ耐性は低いことを想定する。この場合、ＮＣは、次のＭＡＰサイクルにおける送信スロットの割当てを遅延させることによって第１のフローの比較的高いレイテンシ耐性を利用し、現在の帯域幅を第２のフローに割り振ることを決定できる。

更に、本開示の方法及び装置の一実施形態では、従来のＲＲＥとは対照的に、ＯＲＲ要素が、予約要求がされる時間には要求ノードのデータバッファ内に存在しないかもしれないデータの送信を予約することができる。しかしながら、ＯＲＲがＮＣに提供された後、次の媒体アクセスプラン（ＭＡＰ）サイクルにおいて承認された送信間隔の前に、そのデータはノードのデータバッファ内に置かれる。更に、従来の予約要求と同様に、そのノードのデータバッファ内に既に存在するデータについて、ＯＲＲ要素は送信スロットを要求することができる。しかしながら、従来の予約要求に関連するパケットとは異なり、必要に応じて、従来の予約要求について許容される時間よりも長い時間にわたって、そのデータをデータバッファ内に保持することが可能である。換言すれば、現在のネットワーク利用が多い場合、レイテンシ耐性を考慮することによって、ＯＲＲに応じた送信スロットの割当てを遅延させることができる。

本開示の方法及び装置の一実施形態において、送信スロットの割当てを遅延させることは、ＮＣがＲＲＥに応答しないことを意味する。要求を発するノードが、次のＭＡＰを受信し、その要求に対応する割当てを見つけない場合、そのノードは、そのパケットのための新しいＲＲＥを生成できる。ある特定の場合において、そのパケットがほぼレイテンシ耐性だけ遅延させられた場合、そのノードは、その新しいＲＲＥを従来のＰＱｏＳ ＲＲＥとして生成できる。そのようにすることで、送信スロットの割当てが行われる際、最も高い優先度がそのパケットに確実に与えられることになる。しかしながら、多くの場合は、そのパケットを送信しなければならなくなる前に、そのノードが新しいＰＱｏＳ ＯＲＲを生成できるように十分な時間が残るだろう。新しいＲＲＥでは、いくらかの時間が既に経過したことを示すようにレイテンシ耐性が更新される。

送信スロットをＰＱｏＳ ＯＲＲに割り当てないことをＮＣが選択できるようにすることで、全てのＰＱｏＳフローの総計によって必要とされる帯域幅のピークを減らすことにより、予約されたＰＱｏＳ帯域幅を管理することが可能になる。そのようにすることは、ＰＱｏＳについて予約された帯域幅が、より多くのＰＱｏＳフローをサポートできることを意味する（すなわち、より多くのＰＱｏＳフローをアドミットできる）。フローのこの協調は、パケットのピーク数を同時に送信することをＮＣに要請するかもしれない多数のフローを、ＮＣがより効果的に管理することを可能にする。

一実施形態において、ＮＣスケジューラは、ＰＱｏＳフローをアドミットするか否かを決定するために、ＰＱｏＳフローの帯域幅コスト関数を用いる。いくつかの実施形態において、フローのコスト関数は、そのフローに関する最悪の場合のＳＴＡＲである。そのような実施形態の一つにおいて、ＳＴＡＲは、レイテンシ耐性にわたって平均化された、送信すべきバイト数（又は同等の割当て送信スロット）である。レイテンシ耐性は、ユーザの体験する品質に悪影響を与えずに、フローのパケットを遅延させることのできる時間の総計である。それゆえ、ＮＣは、フローに関する最悪の事態のＳＴＡＲと等しい量の帯域幅を予約する。所与のＰＱｏＳフローについて、ＳＴＡＲを測定するために用いられるウィンドウ長は、通常、ピークレートのそれよりも著しく長いので、ＳＴＡＲは、通常、ピークレートよりも著しく小さいことに留意されたい。送信ノード及び受信ノードにおけるバッファオーバフローを避けるために、各ノードにおけるバッファサイズは適切な大きさになっている。この他に、ＳＴＡＲは、レイテンシ耐性にわたって計算する必要はなく、代わりに、所定の持続時間のウィンドウ内におけるバイトの量として計算することができる。その場合、コスト関数は、そのフローのＳＴＡＲ及びレイテンシ耐性の双方を用いて計算されることになる。

従来のＲＲＥ及びＯＲＲ要素の双方は、ＰＱｏＳフロー及び非ＰＱｏＳフローの双方について識別することができる。一実施形態において、送信ノードは、少なくとも一つのパケットの送信準備が完了すると、レイテンシ制限又は最大集約効率（最大ＭｏＣＡパケットサイズ、又は例えばイーサネットパケットなどのサブパケットの最大数）に達していない限り、ＰＱｏＳ ＯＲＲを作る。最大集約効率又はレイテンシ耐性制限に達している場合、本開示の方法及び装置の一実施形態に従って、従来の（伝統的な）予約要求が用いられる。従来のＰＱｏＳ予約要求は、常に、ＰＱｏＳ ＯＲＲがＮＣによって承認される前に承認される。従来のＰＱｏＳ予約要求は、優先度が割り当てられている場合、それらの優先度の順に承認される。ＰＱｏＳフローについて予約された十分な量の帯域幅が利用可能であると想定すると、ＰＱｏＳ ＯＲＲは、優先度付き予約要求の前に、優先度の順に承認される。予約されたＰＱｏＳ帯域幅が十分に残っていない場合、従来の優先度付きＱｏＳ予約要求が、優先度の順に承認される。次に、不十分な予約ＰＱｏＳ帯域幅しかなかった残りのＰＱｏＳ ＯＲＲが承認される。最後に、優先度付きＯＲＲが優先度の順に承認される。

一つのＰＱｏＳフローについて必要なバッファサイズは、ピークレート、ＳＴＡＲ、予約要求−送信レイテンシ、及び最大ＭｏＣＡパケットサイズによって決定され、一方、ＮＣスケジューラ用のＰＱｏＳフローのコスト関数は、ＳＴＡＲ及びそのフローのレイテンシ耐性によって決定されることに留意されたい。

通常のＰＱｏＳフローのピークレート（通常、一つのＭｏＣＡサイクルよりも小さいウィンドウサイズで測定される）は、ＳＴＡＲ（レイテンシ耐性のサイズであるウィンドウで測定される場合、通常、数ミリ秒から数十ミリ秒までにわたる）よりも著しく大きい。更に、ＮＣは、フローのコスト関数計算においてＳＴＡＲを使用する。従って、ＰＱｏＳフローに割り振られた帯域幅の量（例えば、８０％）は、例えばＭｏＣＡ１．１などによって規定された従来のシステムを用いて以前に可能であったものよりも多くのＰＱｏＳフローに、本明細書に記載されたシステム及び方法を用いて適応することができる。

図２は、本明細書に記載されたシステム及び方法の一実施形態に係るネットワークリソースのスケジューリングのための処理例を示す図である。ここで図２を参照すると、ステップ２０４では、ネットワーク内においてフローの送信を要望するノードが、ネットワークコントローラに要求（一つ又は複数の予約要求要素を含有する）を送り、一つ又は複数の送信用ネットワークパケット（一つ又は複数のフローに属する）を有することを示す。その要求の予約要求要素の各々は、ＱｏＳ優先度レベル（優先度レベルの降順に、ＰＱｏＳ ＲＲ、ＰＱｏＳ ＯＲＲ、優先度高ＲＲ、優先度中ＲＲ、優先度低ＲＲ、優先度バックグラウンドＲＲ、優先度高ＯＲＲ、優先度中ＯＲＲ、優先度低ＯＲＲ、優先度バックグラウンドＯＲＲ）の情報を含む。更に、いくつかの実施形態において、その要求は、例えば、レイテンシに対するフローの耐性や、ノードが自らの最大集約効率に達しているか否かなどの追加情報を、パラメータとして直接的に、又は適切な優先度レベル（すなわち、ＰＱｏＳ ＲＲ対ＰＱｏＳ ＯＲＲ、及び優先度Ｎ ＲＲ対優先度Ｎ ＯＲＲ。ここで、ＰＱｏＳ ＲＲ及びＰＱｏＳ ＯＲＲは、共にＰＱｏＳに関するものであるが、ＰＱｏＳ ＯＲＲは、フローレイテンシが制限に達していないこと、及び最大パケット集約に達していないことを意味しており、それゆえ、ＰＱｏＳ ＯＲＲは、（１）全てのＰＱｏＳ ＲＲがスケジュールされた後にＰＱｏＳ帯域幅が残っている場合にのみ、又は（２）全ての優先度ＲＲがスケジュールされた後に優先度付き帯域幅が残っている場合にのみ、スケジュールされる）として間接的に含むことができる。ネットワーク工程の間、多数のノードが、このような予約要求をネットワークコントローラに送って、次の通信ウィンドウ又は複数の通信ウィンドウのための帯域幅予約を要求してもよい。

工程２０１では、ネットワークコントローラが、予約を要求する一つ以上のノードから、これらの要求を受信する。工程２１４では、ネットワークコントローラが要求を評価し、利用可能な帯域幅を全ての要求ノードの一つ以上のデータフロー間で割り振る。ＰＱｏＳフロー内では、ＰＱｏＳ ＲＲがＰＱｏＳ ＯＲＲの前にまずスケジュールされる。なぜなら、ＰＱｏＳ ＲＲは、対応するフローについて最大パケット集約に達したか、あるいはレイテンシ制限に達したことを示すからである。自らのレイテンシ制限に達したＰＱｏＳフローは、これらのパケットが失効する（ｓｔａｌｅとなる）ことを避けるために、最初にスケジュールされなければならない。自らの最大集約効率に達したＰＱｏＳフローは、本来的に、最大集約効率に達していないフローよりも効率的であり、従って、レイテンシ制限に達せず、最大集約にも達していないフローの前に、そのフローに帯域幅を割り振ることができる（ＰＱｏＳ ＯＲＲによって示される通り）。

同様に、複数のノードによって要求されたフローについて、ＰＱｏＳ ＯＲＲにおけるパラメータＴＴＬの使用によって、又はＰＱｏＳ ＲＲ対ＰＱｏＳ ＯＲＲ）の使用によって、ネットワークコントローラはレイテンシ制約を比較することができる。一実施形態では、レイテンシに対する耐性が最も低いフローに最初に帯域幅が割り付けられてもよく、残りの帯域幅があれば、その帯域幅は、一つ以上の残存するフローに、、そのレイテンシ耐性に基づいて、更に割り付けられる。例えば、所与のフローが非常に低いレイテンシ耐性を有する場合、利用可能な通信スロットは、レイテンシに対していくらか高い耐性を有する他のフローに割り付けられる前に、そのフローに割り付けられる。

工程２１８では、ネットワークコントローラは、上記の評価に基づいて、ノードのデータフローに帯域幅を割り付け、それに応じて、それらの通信をスケジュールする。工程２２２では、ネットワークはノードにそれらの予約を通知する。工程２２５では、ノードは、それらの予約に対する承認を受信し、それに応じて、スケジュールされた時間にパケットを送信する。

上述のように、フレキシブル（柔軟）な予約要求又は便宜的（日和見的）な予約要求は、ネットワーク割振りを行うときにネットワークコントローラがより多くの情報に基づいて決定を下すことを可能にする、図２を参照して上述した追加情報を含むように生成することができる。特に、図２を参照して上述した一例では、フレキシブル予約要求において、いくつかの追加の種類の情報が提供される。すなわち、フィールドＦＲＡＭＥ_ＳＵＢＴＹＰＥは、この予約要求要素が便宜的予約要求要素（ＯＲＲ）か否かを示しており、フィールドＰＡＲＡＭＥＴＥＲＳは、最大パケット集約に達しているか否か、及び、この予約要求要素におけるＰＱｏＳパケットの生存時間（ＴＴＬ）値を示しており、フィールドＰＲＩＯＲＩＴＹ_ＤＦＩＤは、予約要求要素の優先度レベル（ＰＱｏＳ、優先度高、優先度中、優先度低、及び優先度バックグラウンド）を示している。表１は、本明細書に記載されたシステム及び方法の一実施形態に係るフレキシブル予約要求（便宜的予約要求を含む）の一例を示す図である。

図３は、本明細書に記載されたシステム及び方法の一実施形態に従って、フレキシブル予約要求を用いて複数のＰＱｏＳフローのための予約を行う複数のノード間でネットワークリソースを割り振る処理例を示す図である。ここで図３を参照すると、工程３０４では、ネットワークコントローラが一つ以上の帯域幅予約要求を受信する。この例では、ネットワークコントローラが複数のＰＱｏＳフローのための一つ以上のフレキシブル予約要求を一つ以上の送信ノードから受信することが想定されている。工程３０６では、ネットワークコントローラが、スケジュールされようとしているウィンドウ又は期間についてのＰＱｏＳ帯域幅の可用性を検査する。

工程３０８では、ネットワークコントローラは、全てのＰＱｏＳ ＲＲに割り振りが行われるか、ＰＱｏＳ帯域幅が完全に割り振られるまでのいずれか早い方までに、まずＰＱｏＳ ＲＲについて帯域幅を割り振る。工程３１０では、ＰＱｏＳ帯域幅が残存しているか否かをネットワークコントローラが検査する。もし残存していたら、ネットワークコントローラは、工程３１２において、全てのＰＱｏＳ ＯＲＲを、それらのレイテンシ及びそれらの最大集約状況に従ってランク付けする。工程３１４では、所与のＰＱｏＳ ＯＲＲについて、ネットワークコントローラは、レイテンシパラメータ（一実施形態では生存時間パラメータ）を検査して、ノードによってスケジュールされようとしているフローが任意のレイテンシに耐えることができるか否かを判断する。一実施形態では、レイテンシパラメータは、実質的に、フローがレイテンシに耐えることができるか否かの２進表現である。他の実施形態では、レイテンシパラメータは、フローが耐えることのできるレイテンシ又は遅延の量を示すことができる。図３に示される単純な例は、前者に関して記載されており、レイテンシパラメータは、２進又はイエス／ノーのインジケータである。

工程３１４では、フローが任意のレイテンシに耐えることができない場合、工程３１２によって示されているように、予約がそのノードに与えられる。一方で、工程３１６に示されているように、そのフローが最大集約に達しているが、レイテンシに耐えることができる場合、そのフローは、工程３２１によって示されるようにスケジュールされる。そのフローがレイテンシに耐えることができ、最大集約にも達しておらず、なおかつ、未処理のフローが更に存在する場合、第１のフローへのリソースの割振りの前に、それらのフローのレイテンシ及びそれらの最大集約状況が検査される。これは、工程３１８及び３１２によって示されている。一実施形態では、リソースがそのゼロレイテンシフローに割り振られるように、レイテンシ耐性を有さないフローに遭遇するまで、この反復処理が続く。ＰＱｏＳフローのレイテンシを検査することのできる順序は、例えば、デバイスクラス又はタイプ、サービス品質の制約などの多様な基準に従うことができる。より高い粒度を用いてレイテンシが定義される一実施形態では、複数のフローは、それらの関連するレイテンシ耐性に従って、ランク付けすることができる。

未決の要求を有するＰＱｏＳフローが更に存在する場合、全てのノードに帯域幅が割り振られるまで、又はそのフローにサービスする十分な可用性がもはやなくなるまで、これらのノードの各々について処理を繰り返すことができる。工程３２５では、一つ又は複数の要求ノードに割振りが伝達される。

予約要求が行われるときに複数の送信ノードが最大パケットサイズ又はそれ以上を蓄積している場合、ネットワークコントローラは、各ノードのレイテンシ制約を依然として満たす間は、全てのノードの全てのデータをスケジュールするために利用可能な十分な帯域幅を持っていなくてもよい。従って、一実施形態では、送信ノードは、送るべきデータを送信ノードが有しているが、そのデータのレイテンシ制限には達しておらず、最大集約効率にも達していない場合に、便宜的予約要求を作成するように構成されている。利用可能なネットワーク帯域幅が存在する場合、便宜的予約要求はネットワークコントローラによって承認される。これは、利用可能なネットワーク帯域幅が存在する場合、便宜的予約要求を用いてＰＱｏＳフローパケットが送信され、送信ノードにおけるパケット蓄積が低減されることを意味する。送るべきデータを送信ノードが有し、かつ、そのデータのレイテンシ制限に達しているか、又は、最大集約効率に達している場合、送信ノードはＲＲを作成する。レイテンシ制限の前に予約要求及び対応する承認を済ませることで、バッファサイズ制約が減少する。

図４は、本明細書に記載されたシステム及び方法の一実施形態に係る予約要求タイプを決定するための処理例を示す図である。この例は、例えば、パラメータ化サービス品質（ＰＱｏＳ）フローを利用するＭｏＣＡ仕様によって規定されるようなネットワークタイプを想定する。ここで図４を参照すると、工程３７７では、要求ノードが自らのフローを評価する。

一実施形態によれば、送信ノードがＰＱｏＳフロー内で情報を送信することを望むと、そのノードは、ネットワークコントローラに対するＰＱｏＳ優先度レベルの予約要求を作成する。この予約要求は、ＰＱｏＳ ＲＲ又はＰＱｏＳ ＯＲＲであってもよい。ＰＱｏＳ ＯＲＲ３８６によれば、ノードが（最大ＭｏＣＡパケットサイズ及びイーサネットパケットの最大数の点で）最大集約効率に達しておらず、フローのレイテンシパラメータに違反する前にノードがある程度の時間だけ待機する余裕があることをノードが示せるようになる。これは、工程３８０、３８２、３８４、及び３６８によって示されている。一実施形態では、そのノードがレイテンシパラメータに違反せずに待機できる時間の量が、ＰＱｏＳ ＯＲＲ３８６に提供された変数「ＴＴＬ」によって定められている。ＴＴＬは、２進数とすることができ、あるいは、より高いレベルの解像度や粒度を有することができる。一実施形態では、ＴＴＬ値は、ミリ秒単位での時間量を示す。

ＰＱｏＳフローに対して十分な数のフリー送信スロットが存在する場合、ネットワークコントローラはノードのＰＱｏＳ ＯＲＲ３８６を承認する。一実施形態では、ネットワークコントローラが、異なるＴＴＬ値を有する複数のＰＱｏＳ ＯＲＲ３８６を受信する場合、ネットワークコントローラは、他のノードをスケジュールする前に、最小のＴＴＬを有するＰＱｏＳ ＯＲＲ３８６をまずスケジュールする。残りのノードも同様に、最小ＴＴＬ値から最大ＴＴＬ値に基づくこの順序でスケジュールすることができる。一実施形態において、ＴＴＬは、１から（レイテンシ−１）ミリ秒の範囲を有する。簡単のため、ＴＴＬを省略して（又は予約値１にセットして）、このＰＱｏＳ ＯＲＲ３８６に関連付けられたパケットを、レイテンシ制約に違反することなく、不定の時間だけ遅延できることを示してもよい。

他の実施形態では、ＰＱｏＳフローにおいて送るべきデータを有する送信ノードが、上記したＰＱｏＳ ＯＲＲ３８６要求に加えて、又はこの要求に代えて、ＰＱｏＳ ＲＲ３８８を用いて、送るべきＰＱｏＳフローデータを有することをネットワークコントローラに示すことができる。工程３８２においてそのノードが最大集約効率（すなわち、最大ＭｏＣＡパケットサイズ又は最大パケット数）に達しているので、又は、そのノードがフローのレイテンシ制約に違反せずに待機する余裕がない（工程３８４）ので、そのノードは、ＰＱｏＳ ＯＲＲ３８６ではなくＰＱｏＳ ＲＲ３８８を用いる。各ＭｏＣＡサイクルでは、一実施形態におけるネットワークコントローラは、ＰＱｏＳ ＯＲＲ３８６及び非ＰＱｏＳ予約要求（すなわち、優先度ＯＲＲ３９６及び優先度ＲＲ３９８）を含む全ての他の予約要求の前に、全てのＰＱｏＳ ＲＲ３８８を最初にスケジュールする。

本開示の方法及び装置の一実施形態によれば、一つの特定種類の予約要求は、優先度付きフローのために送信ノードによって用いられる優先度ＯＲＲ３９６である（工程３８０）。優先度ＯＲＲ３９６は、送信ノードが送るべき優先度付きデータを有するが、最大集約効率には達しておらず（工程３９２）、レイテンシ制約（もしあれば）に違反する前にある程度の時間だけ待機できることをネットワークコントローラに示すために用いられる。利用可能な送信スロットがあれば、ネットワークコントローラはその要求要素を承認する。

本開示の方法及び装置の他の実施形態によれば、優先度ＲＲ３９８は、ＰＱｏＳフローではないフローのために送信ノードによって用いられる他の要求である（工程３８０）。優先度ＲＲ３９８は、送るべき優先度付きデータを送信ノードが有していることと、送信ノードが最大集約効率に達していること（工程３９２）、又はそのノードが待機する余裕がないこと（工程３９４）（例えば、そのノードが緊急メッセージを有すること）とをネットワークコントローラに示すために、送信ノードによって用いられる。一実施形態において、ネットワークコントローラは、同じＱｏＳ優先度レベルの優先度ＯＲＲ３９６が承認される前に、優先度ＲＲ３９８を承認する。

これらの様々な要求は、スケジューリングの目的で優先順位を付けることができ、一実施形態では、ネットワークコントローラは、表２に降順に記載された優先度に従って、予約要求要素をスケジュールする。非ＰＱｏＳフロー（すなわち、優先度付きＱｏＳフロー）に関するこの例では、四つのレベルの優先度が示されている。

一実施形態では、ネットワークコントローラが二つ以上のＰＱｏＳ ＲＲ３８８を受信すると、ネットワークコントローラは、ラウンドロビン選択処理を用いてＰＱｏＳ ＲＲ３８８の要求を承認する。全てのＰＱｏＳ ＲＲ３８８が承認された後にＰＱｏＳ帯域幅が残り、かつ、二つ以上のＰＱｏＳ ＯＲＲ３８６がネットワークコントローラによって受信される場合は、ネットワークコントローラは、最小のＴＴＬ値を有するＰＱｏＳ ＯＲＲ３８６に対する要求を最初に承認する。二つ以上のＰＱｏＳ ＯＲＲ３８６が同じＴＴＬ値を有する場合、一実施形態では、同じＴＴＬ値を有するそれらのＰＱｏＳ ＯＲＲ３８６の中からどのＰＱｏＳ ＯＲＲ３８６に対してネットワークコントローラが次の要求を承認するかを決定するために、ラウンドロビン選択処理が用いられる。

一実施形態では、全ての送信ノード及びネットワークコントローラが、以下に規定されるルールによって、トラフィックの全てのクラスについてのＱｏＳと、ネットワーク帯域幅効率の最大化の双方を達成するように調整を行う。

送信ノード：要求要素順序ルール

各送信ノードは、全てのイーサネットパケットのために予約要素（ＲＥ）を作成し、ＭＡＰサイクル毎に、そのＲＥを自らの予約要求メッセージ（複数でもよい）に含めてネットワークコントローラ（ＮＣ）に送る。
優先順位のレベルは、
ＰＱｏＳ
高優先度
中優先度
低優先度
バックグラウンド優先度
と規定される。

以下のルールの全てが、任意の所与のＭＡＰサイクルのための予約要求の構築に適用される。
１．各フロー（同じＭｏＣＡ宛先及び同じ優先順位レベル）について、イーサネットパケットが送信（入口）ノードのイーサネットコンバージェンス層（ＥＣＬ）に順次に到着する。入口ノードは、そのフローについての一つ以上の隣接する順次パケットを集約し、その集約パケットのためにＲＥを作成する。フローのためにＲＥを作成するとき、入口ノードは、そのＲＥの中に、以下のものを含めてもよい。
ａ．同じフローのために再送されるべき任意のイーサネットパケット（複数でもよい）。再送されたイーサネットパケットは、その再送されたパケットの到着時間とは無関係に、任意の集約パケット内の任意の場所に含まれてもよい。
ｂ．当該入口ノードのＥＣＬにまだ到着していないイーサネットパケットであって低レイテンシＰＱｏＳフローに属するパケットのための送信時間要求。
２．入口ノードは、その入口ノードが送ることを望む制御パケット及び／又は制御プローブのためのＲＥを作成する。
３．入口ノードによって作成された全てのＲＥは、ＲＲ ＲＥタイプかＯＲＲ ＲＥタイプのいずれかでなければならない。
４．ＲＥは、以下のルールに従って予約要求（複数でもよい）に含まれるべきである。
ａ．ＲＥは、制御ＲＥが最初に送られる以下のリストで指定される順序に配列され、送られるべきである。
１．制御ＲＥ（プローブ要求を含む）
２．ＰＱｏＳ ＲＲ要素
３．ＰＱｏＳ ＯＲＲ要素
４．優先度付きＲＲ要素
ａ．高優先度
ｂ．中優先度
ｃ．低優先度
ｄ．バックグラウンド優先度
５．優先度付きＯＲＲ要素
ａ．高優先度
ｂ．中優先度
ｃ．低優先度
ｄ．バックグラウンド優先度
ｂ．同じフローのためのＲＥは、先にＥＣＬに到着したイーサネットパケットのためのＲＥが、後に到着したイーサネットパケットのためのＲＥより前に送られるような順序で送らなければならない。再送されるイーサネットパケットは、このルールから除外される。再送されたイーサネットパケットは、同じフローのための任意のＲＥで送ってもよい。
ｃ．同じイーサネットパケットを含む二つのＲＥを送ってはならない。

ネットワークコントローラ（ＮＣ）スケジューリングルール

ＮＣスケジューリングルールは、二つの部分を含む。包含（Ｉｎｃｌｕｓｉｏｎ）ルールは、どの要求要素をＭＡＰサイクル内でスケジュールすべきかをＮＣが選択する方法を記述し、また、承認順序ルールは、それらの選択された要求要素がＭＡＰサイクル内で承認される順序を記述する。

包含ルール

ＮＣは、要求を発する全てのノードからＲＲ要素及びＯＲＲ要素を受け取ると、ＭＡＰサイクル内でスケジュールされるデータ要求要素を、以下の包含順序レベルに従って選択する。
１．ＰＱｏＳ ＲＲ要素
２．承認された総ＰＱｏＳ帯域幅が、次のＭＡＰサイクルの所定量の利用可能なデータ帯域幅より少ない限り、ＰＱｏＳ ＯＲＲ要素は、この包含順序レベルで選択される。ＭＡＰサイクルの利用可能なデータ帯域幅は、各データＭＰＤＵ送信のプリアンブル及びＩＦＧを含むデータＭＰＤＵ送信のために利用可能なＭＡＰサイクル内の持続時間の合計と定義される（すなわち、制御パケット及び制御プローブについての合計時間ではない）。
３．優先度付きＲＲ要素、
ａ．高優先度
ｂ．中優先度
ｃ．低優先度
ｄ．バックグラウンド優先度
４．ＰＱｏＳ ＯＲＲ要素（すなわち、レベル２での選択の後に残る、選択されなかった任意の要素）、
５．優先度付きＯＲＲ要素：
ａ．高優先度
ｂ．中優先度
ｃ．低優先度
ｄ．バックグラウンド優先度

ＭＡＰサイクル内でスケジュールすべき要求要素を選択するとき、ＮＣは、次に低い包含順序レベルから任意の要求要素を選択することを進める前に、全ての要求ノードからの、所与の包含順序レベルにある全ての要求要素を使い果たさなければならない。任意の所与の包含順序レベル内において、ＮＣは、任意の所与の送信ノードからの要求要素を、それらの要求要素がそれぞれの予約要求内に配置された順序と同じ順序で選択しなければならない。同じ包含順序レベルの要求要素からのＮＣによる選択だが、異なるソースノードからの選択は、通常、ラウンドロビンである。

承認順序ルール

所与の優先順位レベルの全ての要求要素について、ＮＣのＭＡＰメッセージは、それらの要求要素が各送信ノードからの予約要求内に配置されていた順序と同じ順序で、各送信ノードに対してＤＡＵを承認しなければならない。

ＮＣは、レイテンシの少ないＰＱｏＳフローに関する承認を、ＭＡＰサイクルの早いうちにスケジュールすべきである。

媒体アクセス制御（ＭＡＣ）層の効率を高めるために、パケット集約が用いられる。ＭｏＣＡ１．１として知られている業界標準において、便宜的パケット集約が用いられる。すなわち、ＭｏＣＡネットワーク内で予約要求をする機会が送信ノードに与えられると、送信ノードは、送信に利用可能なパケット数（すなわち、その送信バッファ内のパケット数）を検査し、送信の前にできる限り多くのパケットを集約する（組み合わせる）。集約されたパケットは、「集約ＩＤ」に関連付けられる。この集約ＩＤは、通常、宛先ノードと、集約されているパケットの優先度との組み合わせである。集約は、パケットの時間分布に応じて程度の差こそあれ、効率良く行われる。

デジタルビデオレコーダ（ＤＶＲ）からセットトップボックス（ＳＴＢ）に向かう４Ｍｂ／秒の、１．５ｋＢのパケットサイズを有するＳＤフローでは、平均すると、３ミリ秒毎に１．５ｋＢのパケットが一つあるだけである。２０Ｍｂ／秒の高品位（ＨＤ）フローでは、平均すると、１ミリ秒当たり２．５ｋＢのデータがあり、又は等価的に、３ミリ秒毎に１．５ｋＢのパケットが５個ある。パケット集約を長い時間間隔にわたって行う場合、どのようにより効果的に行うことができるかを、この例は示す。長い時間間隔は、トラフィックについてのより長いレイテンシを意味する。非ＰＱｏＳトラフィックについて、多くの場合、トラフィックレイテンシ制約は定義されない。ＰＱｏＳフローについて、通常、明確に定義されたレイテンシ制約が存在する。また、時間間隔がより長いと、ＰＱｏＳフローのピークレートが減るので、より多くのフローをＰＱｏＳ帯域幅に対してアドミットすることができる（これは、総ネットワーク帯域幅の８０％までである。）。したがって、レイテンシパラメータを含めることで、レイヤ２によるパケット集約効率の最大化を補助することができる。

通常、異なるアプリケーションは、異なるレイテンシ制約及び異なる帯域幅保証を有する。レイテンシに敏感なアプリケーションの多くは、狭い帯域幅しか必要としないのに対し、広い帯域幅を必要とする多くのアプリケーションは、レイテンシに対してあまり敏感ではない。例えば、インタラクティブゲーム及びボイスオーバーインターネットプロトコル（ＶｏＩＰ）は、ＤＶＲからのビデオ再生データのストリームよりもレイテンシに対して敏感である。このレイテンシ／帯域幅の配分は、本開示のネットワークにおいて、より効果的なパケット集約を可能にする。なぜなら、パケットは、通常、狭い帯域幅と少ないレイテンシを必要とするアプリケーションほどレイテンシ制約が厳しくない広帯域幅のアプリケーションに対して、より大きく集約されやすいからである。

ＭｏＣＡアプリケーションにおける一実施形態では、ＰＱｏＳフローのアドミッション時間において、パラメータＬａｔｅｎｃｙ（レイテンシ）及びパラメータＳＴＡｖｅｒａｇｅＲａｔｅ（短期平均レート）がトラフィック仕様（ＴＳＰｅｃ）（ソースによって提供される）に含まれており、適切なバッファスペースを予約するため及びノードが効果的なパケット集約を行えるようにするために、関連するノードによって用いられる。Ｌａｔｅｎｃｙパラメータは、ＭｏＣＡ入口ノード／ブリッジからＭｏＣＡ出口ノード／ブリッジまでに必要とされるレイテンシの上限を示す。

ＭｏＣＡ入口ノードは、それがネットワークコントローラに緊急の（すなわち、レギュラーの）予約要求をする前に、最大集約効率に達するまで（最大ＭｏＣＡパケットサイズに達するか、最大パケット数に達するかのいずれか早い方まで）、又は、レイテンシ制限に達するまで、より多くのパケットを蓄積し続ける。これにより、最大集約効率を達成できる機会が入口ノードに与えられる。最大集約効率に達していない場合、かつ、レイテンシ制限に達していない場合、入口ノードは便宜的予約要求を作成することができる。その結果、ネットワークが混雑していない場合に、これらの要求がネットワークコントローラによって承認されることになる。

本明細書で用いられるように、モジュールという用語は、本開示の方法及び装置の一つ以上の実施形態に従って実行されうる機能の所与の構成単位を表してもよい。本明細書で用いられるように、モジュールは、ハードウェア、ソフトウェア、又はこれらの組み合わせの任意の形態を利用して実装されてもよい。例えば、一つ以上のプロセッサ、コントローラ、ＡＳＩＣ、ＰＬＡ、ＰＡＬ、ＣＰＬＤ、ＦＰＧＡ、論理部品、ソフトウェアルーチン又は他の機構が、モジュールを構成するように実装されてもよい。実装において、本明細書に記載された様々なモジュールが別々のモジュールとして実装されてもよく、あるいは、記載された機能及び特徴を一つ以上のモジュール間で部分的又は全体的に共有することができる。すなわち、この説明を読めば当業者にとって明らかとなるように、本明細書に記載された様々な特徴及び機能は、任意の所与の用途において実装されてもよく、また、様々な組み合わせ及び順列で、一つ以上の別個又は共有のモジュールに実装することができる。様々な特徴又は機能要素が別個のモジュールとして個別に説明又は特許請求されていたとしても、これらの特徴及び機能が一つ以上の共通のソフトウェア及びハードウェア要素間で共有でき、かつ、その説明が、その特徴又は機能を実装するために別個のハードウェア又はソフトウェア要素を使用することを要求又は示唆するものでないことは、当業者には理解できるだろう。

本開示の方法及び装置の構成要素又はモジュールがソフトウェアを用いて全体的又は部分的に実装される場合、一実施形態では、これらのソフトウェア要素は、それに関して記載される機能を実行することが可能な計算モジュール又は処理モジュールで動作するように実装することができる。そのような計算モジュールの一例を図５に示す。この例示の計算モジュール４００について様々な実施形態を説明する。この説明を読めば、他の計算モジュール又はアーキテクチャを用いて本開示の方法及び装置を実施する方法が当業者にとって明らかとなる。

ここで図５を参照すると、計算モジュール４００は、例えば、デスクトップ、ラップトップ及びノートブックコンピュータ、携帯型コンピュータデバイス（ＰＤＡ、スマートフォン、携帯電話、パームトップ機など）、メインフレーム、スーパーコンピュータ、ワークステーション若しくはサーバ、又は所与の用途や環境に望ましい又は適切であるかもしれない任意の他の種類の特殊用途若しくは汎用コンピュータデバイスおいて見出される計算能力又は処理能力を表していてもよい。計算モジュール４００はまた、所与のデバイス内に組み込まれるか他の方法で所与のデバイスが利用可能な計算能力を表していてもよい。例えば、計算モジュール４００は、電子デバイス、例えば、デジタルカメラ、ナビゲーションシステム、携帯電話、携帯型コンピュータデバイス、モデム、ルータ、無線アクセスポイント（ＷＡＰ）、端末、及び何らかの形態の処理能力を含みうる他の電子デバイスなどに見出されてもよい。

計算モジュール４００は、例えば、一つ以上のプロセッサ、コントローラ、制御モジュール、又は他の処理装置、例えばプロセッサ４０４を含んでいてもよい。プロセッサ４０４は、例えばマイクロプロセッサ、コントローラ又は他の制御ロジックなどの汎用又は特殊用途処理エンジンを用いて実装されていてもよい。図示された例では、プロセッサ４０４がバス４０２に接続されているが、任意の通信媒体を用いて、計算モジュール４００の他の構成要素との相互作用を容易にし、あるいは外部と通信することができる。

また、計算モジュール４００は、一つ以上のメモリモジュールを含んでいてもよく、このメモリモジュールを本明細書では単にメインメモリ４０８と称する。例えば、好ましくはランダムアクセスメモリ（ＲＡＭ）又は他のダイナミックメモリが、プロセッサ４０４によって実行される情報及び命令を記憶するために使用されてもよい。メインメモリ４０８は、プロセッサ４０４によって実行されるべき命令の実行中に、変数又は他の中間情報を一時的に記憶するために使用されてもよい。同様に、計算モジュール４００は、プロセッサ４０４用に静的な情報及び命令を記憶するためにバス４０２に結合されたリードオンリーメモリ（「ＲＯＭ」）又は他の静的記憶デバイスを含んでいてもよい。

また、計算モジュール４００は、一つ以上の様々な形式の情報記憶機構４１０を含んでいてもよい。この情報記憶機構は、例えば媒体ドライブ４１２及び記憶装置インターフェース４２０を含んでいてもよい。媒体ドライブ４１２は、固定の又はリムーバブルの記憶媒体４１４をサポートするためのドライブ又は他の機構を含んでもよい。例えば、ハードディスクドライブ、フロッピーディスクドライブ、磁気テープドライブ、光学ディスクドライブ、ＣＤ若しくはＤＶＤドライブ（ＲあるいはＲＷ）、又は他のリムーバブル若しくは固定媒体ドライブが設けられていてもよい。従って、記憶媒体４１４は、例えば、媒体ドライブ４１２で読み取られ、書き込まれ又はアクセスされるハードディスク、フロッピーディスク、磁気テープ、カートリッジ、光学ディスク、ＣＤ若しくはＤＶＤ、又は他の固定媒体若しくはリムーバブル媒体を含んでもよい。これらの例が示すように、記憶媒体４１４は、コンピュータソフトウェア又はデータが記憶されたコンピュータ使用可能記憶媒体を含むことができる。

他の実施形態において、情報記憶機構４１０は、コンピュータプログラム又は他の命令若しくはデータを計算モジュール４００にロードできるようにするための他の同様な手段を含んでいてもよい。そのような手段は、例えば、固定又はリムーバブルの記憶ユニット４２２と、インターフェース４２０を含んでいてもよい。そのような記憶ユニット４２２及びインターフェース４２０の例は、プログラムカートリッジ及びカートリッジインターフェース、リムーバブルメモリ（例えば、フラッシュメモリ又は他のリムーバブルメモリモジュール）及びメモリスロット、ＰＣＭＣＩＡスロット及びカード、並びに他の固定又はリムーバブル記憶ユニット４２２、及びソフトウェアやデータを記憶ユニット４２２から計算モジュール４００に転送できるようにするインターフェース４２０を含んでいてもよい。

また、計算モジュール４００は通信インターフェース４２４を含んでいてもよい。通信インターフェース４２４は、計算モジュール４００と外部デバイスとの間でソフトウェア及びデータを伝送できるようにするために使用されてもよい。通信インターフェース４２４の例は、モデム又はソフトモデム、ネットワークインターフェース（例えば、イーサネット、ネットワークインターフェースカード、ＷｉＭｅｄｉａ、ＩＥＥＥ８０２．ＸＸ又は他のインターフェース）、通信ポート（例えば、ＵＳＢポート、ＩＲポート、ＲＳ２３２ポートＢｌｕｅｔｏｏｔｈ（登録商標）インターフェース、又は他のポート）、又は他の通信インターフェースを含んでもよい。通信インターフェース４２４を介して伝送されるソフトウェア及びデータは、典型的には信号によって運ばれてもよい。この信号は、電子信号、電磁気信号（光信号を含む）、又は所与の通信インターフェース４２４によって変換可能な他の信号とすることができる。これらの信号はチャネル４２８を介して通信インターフェース４２４に提供されてもよい。このチャネル４２８は、信号を運んでもよく、また、有線又は無線通信媒体を用いて実施されてもよい。チャネルのいくつかの例は、同軸ケーブルを介するＭｏＣＡチャネル、電話線、セルラーリンク、ＲＦリンク、光リンク、ネットワークインターフェース、ローカル又はワイドエリアネットワーク、及び他の有線又は無線通信チャネルを含んでもよい。

本明細書では、用語「コンピュータプログラム媒体」及び「コンピュータ使用可能媒体」は、例えばメモリ４０８、記憶装置４２０、及び媒体４１４などの物理記憶媒体を一般的に表すために使用されている。これら及び他の種々の形態のコンピュータプログラム記憶媒体又はコンピュータ使用可能記憶媒体が、一つ以上の命令の一つ以上のシーケンスを記憶し、実行用の処理装置へ提供することに関与していてもよい。媒体に組み込まれたそれらの命令は、一般に「コンピュータプログラムコード」又は「コンピュータプログラム製品」（コンピュータプログラム又は他のグループの形式にグループ化されるかもしれない）と呼ばれる。これらの命令は、実行されると、本明細書で述べた本開示の方法及び装置の特徴又は機能を計算モジュール４００が実現できるようにしてもよい。本開示の方法及び装置の様々な実施形態を上述したが、これらは例示として提示したものに過ぎず、限定として提示したものではないことを理解されたい。同様に、様々な図は、本開示の方法及び装置のための例示のアーキテクチャ構成又は他の構成を示している可能性がある。ここで、この例示は、本開示の方法及び装置に含まれうる特徴及び機能を理解する際の助けとなる。特許請求された発明は、図示された例示のアーキテクチャ又は構成に限定されるものではなく、望ましい特徴は、様々な代替アーキテクチャ及び構成を用いて実施することができる。実際、本開示の方法及び装置の望ましい特徴を実施するために代替の機能的、論理的又は物理的な分割及び構成をどのように実施できるかは、当業者にとって明らかであろう。また、本明細書に記載された以外の多数の要素モジュール名を様々な要素に適用できる。更に、フロー図、動作の説明及び方法の請求項に関しては、本願に示されるブロックの順序は、文脈が別段の指示をしない限り、様々な実施形態が同じ順序で記載された機能を実行するように実施されることを強制しない。

本開示の方法及び装置を様々な典型的な実施形態及び実施例に関して説明しているが、個々の実施形態の一つ以上で説明された様々な特徴、態様及び機能は、これらの適用可能性がそれらが説明された特定の実施形態に限定されず、代わりに、本開示の方法及び装置の他の実施形態の一つ以上に、そのような実施形態が説明されたか否か及び説明された実施形態の一部としてそのような特徴が提示されているか否かにかかわらず、単独で、又は様々な組み合わせで適用することができるものと理解されるべきである。よって、特許請求された発明の広がり及び範囲は、単に説明のみのための例として提示された上述のいかなる実施形態によっても限定されるべきではない。

本明細書で使用された用語及び語句、並びにこれらの変形は、特に他のように述べられていない限り、限定的なものではなく、制限のないものとして解釈されるべきである。上記の例として、用語「含む」は、「限定なしに含む」などを意味するものとして解釈されるべきである。用語「例」は、議論中の事項の典型的な例を提供するために使用され、その事項の網羅的又は限定的なリストを提供するために使用されるわけではない。用語「一つ」（「ａ」又は「ａｎ」）は、「少なくとも一つ」、「一つ以上」などを意味するものとして解釈されるべきである。「従来の」、「伝統的な」、「通常の」、「標準の」、「既知の」及び同様の意味の用語といった形容詞は、所与の期間に対して説明される事項又は所与の時点で利用可能な事項に限定されるものとして解釈されるべきではなく、代わりに、現在又は将来のいずれかの時点で利用可能又は知られている可能性のある、従来の、伝統的な、通常の、又は標準の技術を包含するように解釈されるべきである。同様に、本明細書が、当業者にとって明白又は既知であろう技術を参照するとき、そのような技術は、現在又は将来のいずれかの時点で当業者にとって明白又は既知である技術を包含する。

一部の例における「一つ以上の」、「少なくとも」、「ただし〜に限定されない」、又は他の同様の語句のような拡張語及び拡張句の存在は、このような拡張句が存在しない例において、より狭義の例が意図又は要求されることを意味するように解釈されるべきではない。用語「モジュール」の使用は、モジュールの一部として説明又は請求項に記載された構成要素又は機能が、全て共通のパッケージ内に配置されることを意味するわけではない。実際、モジュールの種々の構成要素のうちのいずれか又は全部は、それが制御ロジックであれ他の構成要素であれ、単一のパッケージに組み込み、あるいは別個に維持することができ、更に、複数のグループやパッケージで流通し、あるいは複数の場所で流通してもよい。

更に、ここに記載された様々な実施形態は、例示のブロック図、フローチャート、及び他の図面を用いて説明されている。本明細書を読めば当業者には明らかになるように、図示された実施形態及びそれらの様々な代案は、図示された例に限定されることなく実施することができる。例えば、ブロック図及びそれらに付随する説明は、特定のアーキテクチャ又は構成を義務づけるものとして解釈されるべきではない。

Claims (22)

1. ネットワークコーディネータ及び複数の関連するネットワークノードを有するマネージドネットワークにおいてネットワーク通信をスケジュールする方法であって、
   ａ）パラメータ化サービス品質（ＰＱｏＳ）要求に対して所定量の帯域幅を割り振る工程と、
   ｂ）前記複数の関連するネットワークノードのうち通信ウィンドウ中の送信スロットの割当てを要求する少なくとも一つのノードから、複数のＰＱｏＳ要求を前記ネットワークコーディネータにおいて受信する工程であって、前記複数のＰＱｏＳ要求の少なくとも一部が、送信スロットを割り当てなければならなくなる前に耐えることのできる遅延の量を示すレイテンシ耐性パラメータを含んでいる、工程と、
   ｃ）受信した前記ＰＱｏＳ要求の全てに対して送信スロットを割り当てることができるほど十分な帯域幅がＰＱｏＳ要求のために予約されている場合は、各要求に応じて送信スロットを割り当て、そうでない場合は、レイテンシパラメータを含んでいない前記ＰＱｏＳ要求に最初にスロットが割り当てられる序列に従ってスロットを割り当てる工程と
   を含む方法。
2. レイテンシパラメータを含んでいない前記ＰＱｏＳ要求の全てに対してスロットが割り当てられる場合、より長いレイテンシ耐性を有する前記ＰＱｏＳ要求の前に、より短いレイテンシ耐性を有する前記ＰＱｏＳ要求に対して送信スロットが割り当てられる、請求項１に記載の方法。
3. レイテンシ耐性パラメータを含む前記要求の少なくとも一つは、最大集約量に達したときを示す最大集約量パラメータも含んでおり、
   前記最大集約量に達した前記要求に対して送信スロットを割り当てる請求項１に記載の方法。
4. 通信ネットワーク内でフローをアドミットするか否かを決定する方法であって、
   ａ）ＰＱｏＳフローのために予約されるべき所定の帯域幅を設定する工程と、
   ｂ）ＰＱｏＳフローアドミッション処理を実行して、新しいＰＱｏＳフローをアドミットするか否かを決定する工程と、
   ｃ）前記所定の帯域幅のうち、現在アドミットされているＰＱｏＳフローに既に割り当てられた量を決定する工程と、
   ｃ）前記新しいＰＱｏＳフローによって必要とされる帯域幅の量が、予約された帯域幅の量から前記既に割り当てられた量を引いた量以下であるか否かを、短期平均レート（ＳＴＡＲ）を用いて判断する工程と
   を含む方法。
5. 前記ＳＴＡＲが、前記新しいＰＱｏＳフローのレイテンシ耐性に等しい時間にわたって前記新しいＰＱｏＳフロー用のデータを送信するために必要な帯域幅の最大量である、請求項４に記載の方法。
6. 前記新しいＰＱｏＳフローの前記レイテンシ耐性が、前記新しいＰＱｏＳフローを送信するノードによってＮＣに伝達される送信仕様（ＴＳＰＥＣ）に規定された情報から導出される、請求項５に記載の方法。
7. 前記ＳＴＡＲが、前記新しいＰＱｏＳフローのためのピークレートを決定するために用いられる期間よりも実質的に長い、請求項４に記載の方法。
8. 前記ピークレートが、同軸ケーブルマルチメディア協会ネットワークの任意の一つのＭＡＰサイクル中に前記新しいＰＱｏＳフロー用のデータを送信するために必要な帯域幅の最大量である、請求項７に記載の方法。
9. 前記ＳＴＡＲが、送信仕様（ＴＳＰＥＣ）に規定された情報に基づいて決定される、請求項４に記載の方法。
10. 前記ＴＳＰＥＣに規定された前記情報が、前記新しいＰＱｏＳフローのレイテンシ耐性を少なくとも含む、請求項９に記載の方法。
11. 前記新しいＰＱｏＳフローによって必要とされる帯域幅の量が、予約された帯域幅の量から前記既に割り当てられた量を引いた量以下であるか否かを判断する前記工程が、ＴＳＰＥＣによって規定された情報から導出されるパラメータを用いて行われる、請求項４に記載の方法。
12. 通信ネットワーク上の複数の要求ノードを備えるシステムであって、
    前記要求ノードの各々は、第１のプロセッサと、第１のコンピュータ読み取り可能媒体に組み込まれた第１のコンピュータ実行可能プログラムコードとを含み、前記第１のコンピュータ実行可能プログラムコードは、前記ネットワーク上のネットワークコーディネータへのサブミッションを生成して、通信帯域幅の予約を要求するように構成されており、
    前記通信ネットワーク上の前記ネットワークコーディネータを更に備え、
    前記ネットワークコーディネータは、第２のプロセッサと、第２のコンピュータ読み取り可能媒体に組み込まれた第２のコンピュータ実行可能プログラムコードとを含み、前記第２のコンピュータ実行可能プログラムコードは、前記ネットワークコントロールノードに、
    ａ）通信ウィンドウ中の一つ以上の通信スロットの予約を各自のフローのために要求する複数の要求ネットワークノードの各々からのサブミッションを、前記ネットワークコーディネータにおいて受信する工程であって、前記サブミッションは、その対応する前記要求ネットワークノードの前記フローのレイテンシ耐性、及び、該要求ネットワークノードがその最大集約量に達したか否か、の少なくとも一つを含むスケジューリング情報を含む、工程と、
    ｂ）前記ネットワークコーディネータが、前記通信ウィンドウ内の利用可能な帯域幅を検査する工程と、
    ｃ）前記ネットワークコーディネータが、第１の要求ノードからの第１のフローのスケジューリング情報及び前記帯域幅の可用性に基づいて、前記利用可能な帯域幅を前記第１のフローに割り振るとともに、第２の要求ノードからの第２のフローのスケジューリング情報及び前記帯域幅の可用性に基づいて、前記第２のフローへの帯域幅の割振りを後のウィンドウまで延期し、それによって、複数の通信ウィンドウにわたって、前記複数の要求ノード間でピークデマンドを再割り振りする割振り工程と、
    ｄ）前記ネットワークコーディネータが、前記複数の要求ネットワークノードに予約情報を伝達する工程と、
    を実行させるように構成されている、システム。
13. 前記割振り工程は、前記第１のネットワークコーディネータが、前記第１の要求ノードがその最大集約量に達したか否かを判断し、前記最大集約量に達した場合に、利用可能な通信スロットを前記第１のフローのために割り当てる工程を含む、請求項１２に記載のシステム。
14. 前記割振り工程は、前記ネットワークコーディネータが、前記フローのいずれかがレイテンシに耐えることができるか否かを判断し、レイテンシに耐えることができる場合に、レイテンシに耐えることができるフローのための通信スロットの割振りを後の通信ウィンドウまで延期する工程を含む、請求項１２に記載のシステム。
15. 前記割振り工程は、前記ネットワークコーディネータが、所与の要求ノードに関する前記スケジューリング情報を評価し、前記所与の要求ノードがその最大集約効率に達したか、又はレイテンシ耐性を有さない場合に、前記所与の要求ノードに前記利用可能な通信スロットを割り振る工程を含む、請求項１２に記載のシステム。
16. 前記割振り工程は、前記所与の要求ノードがその最大集約効率に達しておらず、かつレイテンシ耐性を有する場合に、前記所与の要求ノードへの前記利用可能な通信スロットの割振りを延期する工程を更に含む、請求項１２に記載のシステム。
17. 前記所与の要求ノードへの割振りが延期される場合、前記割振り工程は、
    次の要求ノードの前記スケジューリング情報を調査する工程と、
    前記次の要求ノードがその最大集約効率に達したか、又はレイテンシ耐性を有さない場合に、前記次の要求ノードに前記利用可能な通信スロットを割り振る工程と、
    前記次の要求ノードがその最大集約効率に達しておらず、かつレイテンシ耐性を有する場合に、前記利用可能な通信スロットを割り振り、次いで、他の要求ノードに関する前記スケジューリング情報を調査し、又は他の要求ノードが無い場合には、前記所与の要求ノードに前記利用可能な通信スロットを割り振る工程と
    を更に含む、請求項１６に記載のシステム。
18. 前記ネットワークコントロールノードによって行われる前記工程は、前記要求ノードの各々に関する前記スケジューリング情報を、優先度の最も高い要求ノードから優先度の最も低い要求ノードまで優先度の順に評価する工程を更に含む、請求項１２に記載のシステム。
19. 前記レイテンシ耐性情報は、フローが任意のレイテンシに耐えられるか否かに関する２進表現を含む、請求項１２に記載のシステム。
20. 前記レイテンシ耐性情報は、フローが耐えられるレイテンシの量に関する情報を含む、請求項１２に記載のシステム。
21. 前記ネットワークコントロールノードによって行われる前記工程は、前記複数の要求ノードの各々が従来の予約要求又は便宜的予約要求を作成しているか否かを判断する工程を更に含む、請求項１２に記載のシステム。
22. 前記ネットワークコントロールノードによって行われる前記工程は、従来の予約要求を作成する要求ノードに前記利用可能な通信スロットを、他の要求ノードの各々のフロースケジューリング情報及び前記帯域幅の可用性に基づいて該他の要求ノードに残りの利用可能な通信スロットを割り振る前に、割り振る工程を更に含む、請求項１２に記載のシステム。