(57)【要約】      （修正有）【課題】パケット交換ネットワークにおけるトラフィックシェーピングの装置及び方法で、異なるパケット遅延制約を有する複数のトラフィッククラスを扱う。【解決手段】パケット送信機をスリープモードに入るように制御するステップと、特定のトラフィッククラスに属するパケットを受信し、当該受信されたパケットの到着時刻を特定し、当該パケットを待ち行列に追加する受信するステップと、受信されたパケットの送信時刻を、パケットが属するトラフィッククラスのパケット遅延制約を考慮した最大時間として計算するステップと、送信タイマーを計算された送信時刻と到着時刻との差の値に設定するステップと、送信タイマーが満了するまで、又は待ち行列内のパケットの数が所与の閾値に達するまで、上記の各ステップを繰り返すステップと、パケット送信機をスリープモードから抜け出すように制御するステップと、待ち行列内のパケットを送信するステップを含む。【選択図】図４
2013176041.tif 000002
【特許請求の範囲】
【請求項１】
複数のトラフィッククラスを含むパケット交換ネットワークにおけるトラフィックシェーピングの方法であって、各トラフィッククラスは関連するパケット遅延制約を有し、
該方法は、
パケット送信機をスリープモードに入るように制御するステップと、
着信接続から特定のトラフィッククラスに属するパケットを受信するステップであって、該受信されたパケットの到着時刻を特定し、該パケットを待ち行列に追加する、受信するステップと、
前記受信されたパケットの送信時刻を計算するステップであって、該送信時刻は、前記パケットが属する前記トラフィッククラスの前記パケット遅延制約を考慮するために、前記パケットが送信されなければならない最大時間を表す、計算するステップと、
送信タイマーが以前に設定されていない場合、又は送信タイマーの現在値と前記到着時刻との和が前記計算された送信時刻よりも大きい場合には、該送信タイマーを前記計算された送信時刻と前記到着時刻との差の値に設定するステップと、
前記送信タイマーが満了するまで、又は前記待ち行列内のパケットの数が所与の閾値に達するまで、前記受信するステップ、前記計算するステップ及び前記設定するステップを繰り返すステップと、
前記パケット送信機を前記スリープモードから抜け出すように制御するステップと、
前記待ち行列内のパケットを送信するステップと
を含む、複数のトラフィッククラスを含むパケット交換ネットワークにおけるトラフィックシェーピングの方法。
【請求項２】
前記待ち行列内のパケットを送信する前記ステップは、
前記待ち行列内のパケットの数を求めるステップと、
上記ステップにおいて求められた数のパケットを送信するステップと、
前記待ち行列内の残りのパケットのうち、最も小さい送信時刻値を有する前記待ち行列内のパケットの送信時刻を求めるステップと、
前記送信タイマーを上記ステップにおいて求められた前記送信時刻に設定するステップと、
前記待ち行列内のパケットを送信するステップと
を更に含む、請求項１に記載の方法。
【請求項３】
前記送信時刻は、前記到着時刻と、前記パケットが属する前記トラフィッククラスに関連する最大遅延との和に等しい、請求項１又は２に記載の方法。
【請求項４】
前記送信時刻は、前記到着時刻と、前記パケットが属する前記トラフィッククラスに関連する最大遅延及び所定の最大遅延値のうちの小さい方との和に等しい、請求項１又は２に記載の方法。
【請求項５】
前記所定の最大遅延値は、前記着信接続のビットレートに基づいて絶えず更新される、請求項４に記載の方法。
【請求項６】
前記送信時刻は、前記待ち行列内のパケットを送信するために前記送信機によって必要とされる時間を含む、請求項１〜５のいずれか一項に記載の方法。
【請求項７】
前記待ち行列内のパケットを送信する前記ステップの後に、
スリープウェイトタイマーを始動するステップと、
前記スリープタイマーの満了前に任意のパケットが受信される場合、前記待ち行列内のパケットを送信する前記ステップに戻るステップと
を更に含む、請求項１〜６のいずれか一項に記載の方法。
【請求項８】
データ処理デバイスのためのコンピュータプログラム製品であって、該コンピュータプログラム製品は１組の命令を含み、該１組の命令は、前記データ処理デバイスにロードされると、前記デバイスに請求項１〜８のいずれか一項に記載のステップを実行させる、データ処理デバイスのためのコンピュータプログラム製品。
【請求項９】
複数のトラフィッククラスを含むパケット交換ネットワークにおけるトラフィックシェーピングのための装置であって、各トラフィッククラスは関連するパケット遅延制約を有し、
該装置は、
スリープモードに入るようにパケット送信機を制御するように構成されるコントローラと、
着信接続からそれぞれが特定のトラフィッククラスに属する１つ又は複数のパケットを受信し、該１つ又は複数の受信されたパケットのそれぞれの到着時刻を特定し、該１つ又は複数の受信されたパケットをそれぞれ待ち行列に追加するように構成される受信機とを備え、
前記コントローラは、
前記受信されたパケットの送信時刻を計算し、該送信時刻は、前記パケットが属する前記トラフィッククラスの前記パケット遅延制約を考慮するために、前記パケットが送信されなければならない最大時間を表し、
送信タイマーが以前に設定されていない場合、又は送信タイマーの現在値と前記到着時刻との和が前記計算された送信時刻よりも大きい場合には、該送信タイマーを前記計算された送信時刻と前記到着時刻との差の値に設定し、
前記送信タイマーの満了時、又は前記待ち行列内のパケットの数が所与の閾値に達したときに、前記スリープモードから抜け出すように前記パケット送信機を制御し、
前記待ち行列内のパケットを送信するように前記パケット送信機を制御する、ように更に構成される、複数のトラフィッククラスを含むパケット交換ネットワークにおけるトラフィックシェーピングのための装置。
【請求項１０】
前記コントローラは、
前記待ち行列内のパケットの数を求め、
前記求められた数のパケットを送信するように前記パケット送信機を制御し、
前記待ち行列内の残りのパケットのうち、最も小さい送信時刻値を有する前記待ち行列内のパケットの送信時刻を求め、
前記送信タイマーを前記求められた送信時刻に設定し、
前記待ち行列内のパケットを送信するように前記パケット送信機を制御するように更に構成される、請求項９に記載の装置。
【請求項１１】
前記送信時刻は、前記到着時刻と、前記パケットが属する前記トラフィッククラスに関連する最大遅延との和に等しい、請求項９又は１０に記載の装置。
【請求項１２】
前記送信時刻は、前記到着時刻と、前記パケットが属する前記トラフィッククラスに関連する最大遅延及び所定の最大遅延値のうちの小さい方との和に等しい、請求項９又は１０に記載の装置。
【請求項１３】
前記コントローラは、前記着信接続のビットレートに基づいて前記最大遅延値を絶えず更新するように構成される、請求項１２に記載の装置。
【請求項１４】
前記送信時刻は、前記待ち行列内のパケットを送信するために前記送信機によって必要とされる時間を含む、請求項９〜１３のいずれか一項に記載の装置。
【請求項１５】
前記送信機が前記待ち行列内のパケットを送信した後にスリープウェイトタイマーを始動し、該スリープウェイトタイマーの満了前に任意の更なるパケットが受信される場合には、前記待ち行列内のパケットを送信するように前記送信機を制御するように構成されるスリープウェイト手段を更に備える、請求項９〜１４のいずれか一項に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ通信の分野に関し、より詳細には、受動光ネットワークにおけるトラフィックシェーピングに関する。
【背景技術】
【０００２】
通常、既知の伝送ネットワークは伝送レートを最大化することを目的として設計され、この目的は、エネルギー消費に関連する設計上の検討事項を犠牲にして達成される場合がある。これら電力に関連する非効率性は、貴重なエネルギーを著しく無駄にすることになる可能性がある。特に、その大多数が現在少なくとも１台のコンピュータと、多くの場合に、ディジタルメディア受信機、タブレットコンピュータ、スマートフォン等のますます多くのネットワーク化されたデータ通信デバイスとを備えるエンドユーザ構内においてその可能性がある。
【０００３】
そのような環境において、イーサネット（登録商標）は依然として１つのユビキタス伝送技術である。しかしながら、現在のところ、イーサネット（登録商標）標準規格では、一般的には交換されるデータ量はリンク容量に比べて非常に小さいにもかかわらず、送信機と受信機の両方は交換されるデータ量にかかわらずリンク上で絶えず動作する必要がある。同時に、ローカルアクセスネットワークにおいて、ディジタル加入者線（ｘＤＳＬ）ネットワークのコストに相当するコストでギガビット／秒の速度をサポートする光技術が拡大していることが大きな要因となって、今日、エンドユーザが通信するために提供されるダウンリンクスループットとアップリンクスループットは、前例がない程の割合で増加しつつある。
【０００４】
この一例として、イーサネット（登録商標）受動光ネットワーク（ＥＰＯＮ）アーキテクチャを用いてサービスプロバイダ中央局を企業及び住宅加入者に接続する「ファーストマイル」では、現在、光ファイバをデプロイすることができる。これに関連して、エンドユーザの構内において、よりエネルギー効率の良いネットワーク装置の必要性が高まってきた結果として、これらの検討事項に取り組み、工業標準規格に組み込む努力がなされている。
【０００５】
２０１０年９月３０日に承認されたＩＥＥＥ標準規格８０２．３ａｚ−２０１０は、イーサネット（登録商標）の省電力動作、いわゆるＥＥＥを可能にするために、幾つかの既存の物理層への変更を規定する。実際、１００メガビット／秒、１ギガビット／秒、及び１０ギガビット／秒のデータリンクでは、物理層送信機チップを常にオンにしておくために比較的大量のエネルギーが用いられる。この問題に対処するために、ＥＥＥは低電力アイドル（ＬＰＩ）モードを導入しており、このモードでは、データが存在しない場合の送信を短い周期的なリフレッシュ間隔に制限し、送信機と受信機の間の整合性を保持する。ＬＰＩモードを用いることによって、送信機がＬＰＩモードにおいてオンになる割合が多い場合に、多大な省エネルギーを達成することができる。
【０００６】
概略的に言うと、ＥＥＥ標準規格は、送信すべきデータがないときは送信を停止し、新たなパケットが到着すると迅速に送信を再開する仕組みを規定する。これは、送信すべきデータがないときに連続的なＩＤＬＥ信号を送信する代わりに、上記のＬＰＩモードを導入することによって行われる。ＬＰＩは、信号が送信されない長い期間と、受信機状態をリフレッシュするためにデータが送信される短い期間を規定する。
【０００７】
ＬＰＩ指示信号（すなわち、「スリープ」信号）を周期的に送信することによって、システム内の送信機チップ（これ以降、ＰＨＹチップ、又はＰＨＹと呼ばれる）を単純にオフにすることができる。送信すべきデータがあるとき、データが送信されることになる前にＩＤＬＥ信号を送信して送信システムをウェイクさせる。このシナリオでは、送信経路がスリープモードにあるときでも受信機回路はアクティブのままであるので、データリンクは期間全体を通して動作中であるとみなされる。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ＥＥＥシステムを使用することに関連する省電力はデバイスによって異なるが、デバイスがスリープモードにあるときのエネルギー消費は、アクティブモードのエネルギー消費の１０％程度まで低くすることができる。しかしながら、スリープモードとアクティブモードの間の移行中には、送受信機内の数多くの素子がアクティブでなければならないので著しくエネルギーを消費する。通常、移行期間中の消費電力は、アクティブモード値の５０％〜１００％の範囲に及ぶ可能性がある。
【課題を解決するための手段】
【０００９】
従来技術に関する問題点を解決するために、本発明は、複数のトラフィッククラスを含むパケット交換ネットワークにおけるトラフィックシェーピングの方法を提供する。各トラフィッククラスは関連するパケット遅延制約を有する。この方法は、
パケット送信機をスリープモードに入るように制御するステップと、
着信接続から特定のトラフィッククラスに属するパケットを受信するステップであって、当該受信されたパケットの到着時刻を特定し、当該パケットを待ち行列に追加する、受信するステップと、
受信されたパケットの送信時刻を計算するステップであって、当該送信時刻は、パケットが属するトラフィッククラスのパケット遅延制約を考慮するために、パケットが送信されなければならない最大時間を表す、計算するステップと、
送信タイマーが以前に設定されていない場合、又は送信タイマーの現在値と到着時刻との和が計算された送信時刻よりも大きい場合には、送信タイマーを計算された送信時刻と到着時刻との差の値に設定するステップと、
送信タイマーが満了するまで、又は待ち行列内のパケットの数が所与の閾値に達するまで、上記受信するステップ、上記計算するステップ及び上記設定するステップを繰り返すステップと、
パケット送信機をスリープモードから抜け出すように制御するステップと、
待ち行列内のパケットを送信するステップとを含む。
【００１０】
好ましくは、待ち行列内のパケットを送信する上記ステップは、
待ち行列内のパケットの数を求めるステップと、
上記ステップにおいて求められた数のパケットを送信するステップと、
待ち行列内の残りのパケットのうち、最も小さい送信時刻値を有する待ち行列内のパケットの送信時刻を求めるステップと、
送信タイマーを上記ステップにおいて求められた送信時刻に設定するステップと、
待ち行列内のパケットを送信するステップとを更に含む。
【００１１】
送信時刻は、到着時刻と、パケットが属するトラフィッククラスに関連する最大遅延との和に等しくすることができる。
【００１２】
好ましくは、送信時刻は、到着時刻と、パケットが属するトラフィッククラスに関連する最大遅延及び所定の最大遅延値のうちの小さい方との和に等しい。
【００１３】
好ましくは、所定の最大遅延値は、着信接続のビットレートに基づいて絶えず更新される。
【００１４】
好ましくは、送信時刻は、待ち行列内のパケットを送信するために送信機によって必要とされる時間を含む。
【００１５】
好ましくは、待ち行列内のパケットを送信する上記ステップの後に、
スリープウェイトタイマーを始動するステップと、
スリープタイマーの満了前に任意のパケットが受信される場合、待ち行列内のパケットを送信する上記ステップに戻るステップとを更に含む。
【００１６】
本発明は、データ処理デバイスのためのコンピュータプログラム製品を更に提供する。このコンピュータプログラム製品は１組の命令を含み、当該１組の命令は、データ処理デバイスにロードされると、デバイスに上記の方法のステップを実行させる。
【００１７】
本発明は、複数のトラフィッククラスを含むパケット交換ネットワークにおけるトラフィックシェーピングのための装置を更に提供する。各トラフィッククラスは関連するパケット遅延制約を有する。この装置は、
スリープモードに入るようにパケット送信機を制御するように構成されるコントローラと、
着信接続からそれぞれが特定のトラフィッククラスに属する１つ又は複数のパケットを受信し、当該１つ又は複数の受信されたパケットのそれぞれの到着時刻を特定し、当該１つ又は複数の受信されたパケットをそれぞれ待ち行列に追加するように構成される受信機とを備え、
コントローラは、
受信されたパケットの送信時刻を計算し、当該送信時刻は、パケットが属するトラフィッククラスのパケット遅延制約を考慮するために、パケットが送信されなければならない最大時間を表し、
送信タイマーが以前に設定されていない場合、又は送信タイマーの現在値と到着時刻との和が計算された送信時刻よりも大きい場合には、送信タイマーを計算された送信時刻と到着時刻との差の値に設定し、
送信タイマーの満了時、又は待ち行列内のパケットの数が所与の閾値に達したときに、スリープモードから抜け出すようにパケット送信機を制御し、
待ち行列内のパケットを送信するようにパケット送信機を制御する、ように更に構成される。
【００１８】
好ましくは、コントローラは、
待ち行列内のパケットの数を求め、
求められた数のパケットを送信するようにパケット送信機を制御し、
待ち行列内の残りのパケットのうち、最も小さい送信時刻値を有する待ち行列内のパケットの送信時刻を求め、
送信タイマーを求められた送信時刻に設定し、
待ち行列内のパケットを送信するようにパケット送信機を制御するように更に構成される。
【００１９】
送信時刻は、到着時刻と、パケットが属するトラフィッククラスに関連する最大遅延との和に等しくすることができる。
【００２０】
好ましくは、送信時刻は、到着時刻と、パケットが属するトラフィッククラスに関連する最大遅延及び所定の最大遅延値のうちの小さい方との和に等しい。
【００２１】
好ましくは、コントローラは、着信接続のビットレートに基づいて最大遅延値を絶えず更新するように構成される。
【００２２】
好ましくは、送信時刻は、待ち行列内のパケットを送信するために送信機によって必要とされる時間を含む。
【００２３】
好ましくは、この装置は、送信機が待ち行列内のパケットを送信した後にスリープウェイトタイマーを始動し、当該スリープウェイトタイマーの満了前に任意の更なるパケットが受信される場合には、待ち行列内のパケットを送信するように送信機を制御するように構成されるスリープウェイト手段を更に備える。
【発明の効果】
【００２４】
本発明は、従来技術より優れた幾つかの利点を提供する。例えば、本発明は、サービス品質（ＱｏＳ）トラフィックシェーピングポリシーを用いてベースラインＥＥＥ性能を改善するので、上位層プロトコルに影響を及ぼしてユーザによって実行されるプロセス／アプリケーションに悪影響を及ぼすデータ伝送遅延を回避するために、種々のサービスクラスに固有のアプリケーション制約を考慮に入れる。本発明は、現在のトラフィックレベルに応じてスリープ周期の持続時間を適応させるので、急激かつ著しく大きなトラフィック変動に効率的に適応することができる。
【００２５】
さらに、本発明は、ＰＯＮやＷｉ−Ｆｉシステムにおいて用いられるような他のレイヤー２のプロトコルのための省電力も改善することができる。また、本発明は、メモリをほとんど必要としない（すなわち、単一のＦＩＦＯ）という点で容易に実装することができる。
【００２６】
本発明の更なる利益及び利点は、添付の図面とともに以下の詳細な説明を検討するときに明らかになるであろう。
【図面の簡単な説明】
【００２７】
【図１】従来技術によるＥＥＥ低電力アイドル（ＬＰＩ）システムの動作を示す図である。
【図２】本発明を用いることができる例示的なデータ通信ネットワークの図である。
【図３】本発明の一実施形態によるシステムの機能ブロック図である。
【図４】本発明の一実施形態による方法のフローチャートである。
【図５】本発明の一実施形態によるシステムの動作を示す図である。
【図６】本発明の一実施形態によるシステムの動作を示す状態図である。
【図７】本発明の一実施形態によるシステムの動作を示す状態図である。
【図８ａ】本発明の一実施形態によるシステムの動作を示す図である。
【図８ｂ】本発明の一実施形態によるシステムの動作を示す図である。
【図９】最適な消費電力Ｐｏｐに対する消費電力とＴ０の関係のグラフである。
【図１０】本発明の２つの実施形態によるデバイスのためのトラフィック負荷とＴ０値の関係のグラフである。
【発明を実施するための形態】
【００２８】
図１は、従来技術によるＥＥＥ  ＬＰＩ送信機の動作を示す図である。ＥＥＥ準拠ＰＨＹ動作は、以下のように説明することができる。パケットが送信されているとき、デバイスはアクティブモードにあり、送信するための更なるパケットを入手できないとき、リンクは通常、低電力（又はスリープ）モードに入ることになる。図１に示されるように、スリープモードに移行するにはＴｓマイクロ秒を要する。
【００２９】
スリープモードでは、ＰＨＹは短いインターバルＴｒの間にリフレッシュ信号を送信するのみであり、長いインターバルＴｑの間には送信を行わない。送信するためのパケットが到着すると、所定の期間にわたって送信機にウェイク信号を送信することによって、リンクが再び起動される。ウェイク信号を受信すると、ＰＨＹデバイスは通常動作状態（すなわち、アクティブモード）に入る。スリープモードからウェイクモードへの移行には、Ｔｗマイクロ秒を要する。リンクがアクティブになった後、１つ又は複数のパケットを送信することができる。
【００３０】
図１から見て取れるように、ＥＥＥは、ＰＨＹによって送信される１つ又は複数のバックツーバックパケットのバースト毎にオーバーヘッドを付加する。このオーバーヘッドは、アイドルからリンクをウェイクさせるのに要する時間（Ｔｗ）とリンクをスリープモードに戻すのに要する時間（Ｔｓ）とを含む。
【００３１】
最も有利な条件（すなわち、システムがドーマント状態にあるとき）では、非ＥＥＥ準拠ＰＨＹは、ＥＥＥ準拠ＰＨＹよりも最大で１０倍の電力を消費する可能性がある。しかしながら、最も有利でない条件（すなわち、システムが決してスリープモードに入らないとき）では、非ＥＥＥ準拠ＰＨＹは、ＥＥＥ準拠ＰＨＹと同じ量の電力を消費することになる。通常のシステムは常にドーマント状態であるとは限らず、また絶えず送信しているとも限らないので、ドーマント状態に費やされる時間とアクティブ状態に費やされる時間とを比較することによって、上記の比率が重み付けされなければならないことは理解されよう。
【００３２】
さらに、ＥＥＥ準拠ＰＨＹの性能は、イーサネット（登録商標）フレームの持続時間に対してスリープ移行（Ｔｓ）及びウェイク移行（Ｔｗ）の値が大きくなると、レイテンシによって影響を及ぼされる。例えば、１Ｇｂ／ｓでは、最小オーバーヘッドは１９８．５μｓ（Ｔｓ（ｍｉｎ）＝１８２μｓ、Ｔｗ＝１６．５μｓ→Ｔｓ＋Ｔｗ＝１９８．５μｓ）であり、一方、イーサネット（登録商標）フレーム持続時間、いわゆるＴフレームは、１５１４バイトからなる一般的な長さのフレームの場合に、１２μｓに等しいにすぎない。
【００３３】
さらにまた上記のように、ＥＥＥは、ＴｓとＴｗの間に何も送信できないという点で、オーバーヘッドを付加する。このオーバーヘッドは、必然的に消費電力に影響を及ぼす。これは、スリープ期間とウェイク期間の間の消費電力が最大である（すなわち、アクティブモードが要求される）ためである。さらに、フレーム間の時間インターバルが所与の閾値（すなわち、最小Ｔｓ）よりも短い場合には、スリープモードに全く入ることができない。
【００３４】
したがって、ＥＥＥ準拠ＰＨＹは、中程度のビットレートで通信する際、及び／又は短いパケットを扱っている際に、省電力性能の低下を示す。
【００３５】
後に示される限定されない例示的な実施形態において説明されるように、本発明は、サービス品質（ＱｏＳ）に基づくトラフィックシェーピングポリシーを提案し、ベースラインＥＥＥ性能を改善することによって、上記の問題に対処する。
【００３６】
図２は、本発明を用いることができる例示的なデータ通信ネットワークを示している。図２に示される住居環境トポロジーは、高速イーサネット（登録商標）リンクを介してイーサネット（登録商標）受動光ネットワーク（ＥＰＯＮ）光回線終端装置（ＯＮＵ）に接続されるホームゲートウエイ（ＨＧＷ）を備える構内の場合における、装置の点から見て代表的なネットワーキング要件を表している。
【００３７】
このトポロジーでは、メインユーザは複数の電話、スマートフォン、ビデオデバイス、ラップトップ、ＰＣ、タブレットコンピュータ等を所有している。これらの各デバイスは、それぞれ特定の用途を対象にするか、又は種々の異なる用途に対して用いることができる。これらの用途は、ディジタルテレビサービス（例えば、ブロードキャストＴＶ又はビデオオンデマンド）、ウェブアプリケーション（例えば、エンターテイメント、ゲーム、音楽、ビデオ、及びビジネスサービス）、電話通信（ＶｏＩＰ）、ビデオ監視又はウェブカメラ、テレコミューティング等を含む。
【００３８】
図２のネットワーク例では、ホームゲートウエイ（ＨＧＷ）とＯＮＵは、１００ＢＡＳＥ−ＴＸ、１０００ＢＡＳＥ−Ｔ、又は１０ＧＢＡＳＥ−ＴのＰＨＹ層を介してイーサネット（登録商標）８０２．３リンクによってリンクされる２つの別々のデバイスであり、省電力イーサネット（登録商標）（ＥＥＥ）をサポートする。当業者には理解されるように、本発明は種々の特徴を有する他のネットワークアーキテクチャと共に用いることもできる。
【００３９】
本発明は、図２のトポロジーにおいて示されるように、ＥＰＯＮ  ＯＮＵとホームゲートウエイ（ＨＧＷ）の間のインターフェースにおける２つの境界に有利に適用される。
【００４０】
本発明は、ＦＩＦＯバッファのサイズ、閾値等のパラメータを調整することによって、ＯＮＵインターフェースと光回線終端装置（ＯＬＴ）の間で用いることもできる。
【００４１】
図３は、本発明の一実施形態によるシステム３００の機能ブロック図である。図３のシステム３００は、図２のＥＰＯＮ  ＯＮＵにおける受信機３０１とＰＨＹ３０２送信機の間に実装される。
【００４２】
システム３００は、ＰＨＹ３０２及びＦＩＦＯバッファ３０３の動作を制御するためのコントローラ３０４を備えている。また、このシステムは、タイマー３０５及びメモリ３０６を備えており、ＰＨＹ３０２及びＦＩＦＯバッファ３０３を制御する際に、コントローラ３０４によって用いられる。動作時において、受信機３０１は、ＨＧＷに送信されることになるイーサネット（登録商標）パケットを受信する。受信が行われると、それらのパケットは受信された順序でＦＩＦＯバッファ３０３に入れられる。図３では、例えば、パケットＰ１が最初に受信され、Ｐ２が二番目に受信され、以下同様である。コントローラ３０４は、本発明の方法に従ってパケットが光リンク３０７を介して送信されるように、メモリ３０６及びタイマー３０５を用いて、本発明の方法に従ってＦＩＦＯバッファ３０３及びＰＨＹ３０２の動作を制御する。
【００４３】
本明細書において、パラメータＫはＦＩＦＯバッファ３０３のサイズに対応し、全ての関連するアプリケーションの一時的なトラフィックに対してＦＩＦＯバッファ３０３が最大限対応可能な遅延を吸収できるように有利に選択される。遅延は最大のＴｃｌａｓｓ値に対応し、Ｔｃｌａｓｓはミリ秒単位で表される。また、このパラメータの選択は、リンクの容量にも依存する。リンク容量がメガビット／秒単位で表されると仮定すると、Ｋは以下のように計算することができる。
【数１】
2013176041.tif 000003
【００４４】
例えば、１Ｇｂ／ｓのＰＯＮリンクで５０ｍｓに固定された最大Ｔｃｌａｓｓの場合、６．４ＭｂｙｔｅのＦＩＦＯバッファサイズＫが妥当であろう。
【００４５】
図４〜図８を参照しながら、本発明の実施形態の動作を以下に説明する。この実施形態において、本発明はＷｉ−Ｆｉ標準規格（すなわち、ＩＥＥＥ８０２．１１ｘ）において規定される４つのトラフィッククラス、すなわち、バックグラウンドトラフィック（ＢＫ）、ベストエフォート（ＢＥ）、ビデオ（ＶＩ）、及びボイス（ＶＯ）を用いる。トラフィックを分類する他の方式（例えば、ＩＥＥＥ８０２．１ｑ標準規格において規定される８つのトラフィッククラス）とともに本発明を用いることもできることは、当業者には明らかであろう。
【００４６】
本発明によれば、本発明において用いられるトラフィッククラスごとに、幾つかのＱｏＳパラメータが規定され、詳細には最大許容遅延が規定される。したがって、本発明に従って動作するシステムは、必要に応じて、及び／又はオペレータによって望まれる、多くのトラフィッククラスをサポートすることができる。例えば、伝送制御プロトコル（ＴＣＰ）トラフィック（ＢＥトラフィック又はＢＫトラフィック）について考える場合、ＴＣＰを介して通信する幾つかのアプリケーションは、或る形式の下位分類を正当化する特徴及び要件を有する場合がある。したがって、ＢＥトラフィッククラスは、例えば「インタラクティブＢＥ」クラス及び「非インタラクティブＢＥ」クラスに更に細分することができる。本発明は、任意のクラス構成を用いて動作することができ、用いられるトラフィッククラスのパラメータのいかなる変更にも適合することができる。
【００４７】
以下において、Ｔ０はタイマーとして定義され、その満了が送信（Ｔｘ）状態への移行をトリガーすることになる。Ｔ０は、任意の着信パケットの送信をトリガーする前にシステムが満たすことになる待ち時間に対応する。Ｔ０が満了する前は、システムのＰＨＹをスリープモードのままにすることができる。Ｔ０タイマーは、全てのタイプの全てのデータパケットが格納される唯一の先入れ先出し（ＦＩＦＯ）バッファ３０３に結合される。以下の説明において、Ｔ０はミリ秒単位で表され、ＦＩＦＯバッファ３０３内の最も古いパケットに関して設定される。
【００４８】
本実施形態では、本発明のトラフィックシェーピングをネットワーク化されたユーザから知覚できないようにするために、Ｔ０の値は所与のトラフィッククラスのためのリンク上のラウンドトリップタイム（ＲＲＴ）の半分を決して超えてはならない。用いられる種々のトラフィックカテゴリのためのＲＲＴ値が１０ｍｓから６０ｍｓまでに及び、平均ＲＲＴが約３０ｍｓであると仮定すると、妥当な値の一例は１０ｍｓ〜４０ｍｓである。本発明を用いてＴ０を自動的に計算することができる方法に関する技術的な詳細について、以下に説明する。
【００４９】
ｍａｘＴ０は、所与の時点におけるＴ０タイマーに関する最適値として定義され、ＱｏＳトラフィック制約を考慮して、超えてはならない値である。ｍａｘＴ０値は、理想的な電力値に関してオペレータがサポートすることに特に異存がない最大消費電力閾値値に依存する。以下に説明されるように、ｍａｘＴ０は、Ｔｃｌａｓｓ値を大きくしても遅延が著しく増加する割には省電力が僅かしか向上しない状況において、システムによって導入される最大遅延を制限し、それにより不必要な遅延を避けるために、本発明の一実施形態において有利に用いられる。ｍａｘＴ０は、以下に説明されるように、着信トラフィックレートの関数でもあり、本明細書では同じくミリ秒単位で表される。
【００５０】
本明細書において、ｎ０は、以下に説明されるように、システムがスリープモードにあり、Ｔ０が満了したとき又はＴｈに達したときのＦＩＦＯバッファ３０３内のパケットの数として定義される。
【００５１】
本明細書において、Ｔ１は、ＦＩＦＯバッファ３０３内に含まれるデータを送信した後に、ＰＨＹがスリープモード（すなわち、ＬＰＩモード）に戻る前の短いガード時間インターバルに関連するタイマー値として定義される。通常、このタイマーの値はＬＰＩオーバーヘッドの近似値に設定され、ウェイクモードからスリープモードに移行する移行時間と、スリープモードからウェイクモードに移行する移行時間との和として計算される。本発明の一実施形態では、この値は、少なくとも１つのリフレッシュサイクルに関連する最小値も含み、それゆえ、以下の式が成り立つ。
【数２】
2013176041.tif 000004
【００５２】
本明細書において、Ｔｃｌａｓｓは、所与のトラフィッククラスに関連する最大遅延として定義される。各トラフィッククラスは、自らのＴｃｌａｓｓ値に関連付けられる。この値は通常、予め規定された一定値であり、オペレータによって規定及び／又は更新することができる。本明細書ではミリ秒単位で表される。例示として、図４〜図８に従って記述されるシステムの場合のＴｃｌａｓｓ値は、ＴＢＫ＝１００ｍｓ、ＴＢＥ＝５０ｍｓ、ＴＶＩ＝３０ｍｓ、ＴＶＯ＝１０ｍｓである。
【００５３】
本明細書において、Ｔｈは、ＦＩＦＯバッファ３０３内のパケットの最大閾値として定義される。この閾値を超える場合、Ｔ０タイマーが満了したか否かにかかわらずデータの送信を開始するために、システムはアクティブモードへの復帰をトリガーする。好ましい実施形態では、ＴｈはＦＩＦＯバッファ３０３の容量のパーセンテージとして表され、ＦＩＦＯバッファ３０３の最大容量に近い値（例えば、９５％）に設定される。本明細書において、Ｂ（ｔ）は、時刻ｔにおけるＦＩＦＯバッファ３０３内のバイト数として定義される。
【００５４】
本明細書において、Ｐｏｐは、ミリワット単位で表される最適な消費電力として定義され、以下の式を用いて計算することができる。
【数３】
2013176041.tif 000005
ただし、α＝入力ビットレート／出力ビットレートであり、ＰＡはアクティブモードにおいて消費される電力（ミリワット単位）であり、ＰＬＰＩはＬＰＩモードにおいて消費される電力である。
【００５５】
上記のように、パケットが関連付けられるのがどのトラフィッククラスであるかにかかわらず、ＦＩＦＯバッファ３０３によって全てのパケットが受信されるため、本発明は１つのＦＩＦＯバッファ３０３しか必要としない。
【００５６】
有利には、Ｔ０は、瞬時の入力トラフィック量を考慮しながら、消費電力を最小化するように選択される。Ｐｏｐと比べて許容できる付加電力レベルを選択した後、その時点における推定入力トラフィック量に従って、ｍａｘＴ０で表される最適なＴ０の値を設定することができる。エンドユーザのＱｏＳ遅延制約を考慮するために、Ｔ０はＴｃｌａｓｓを決して超えてはならない。
【００５７】
図４は、スリープ状態中におけるシステム３００の動作を示すフローチャートであり、詳細には、本発明の一実施形態によるＴ０タイマーの作動と持続を記述する。上記のように、Ｔ０は、満了したときにＰＨＹのアクティブ（又は送信）モードへの復帰をトリガーすることになるタイマー値である。したがって、システムは、スリープモードにおいて図４のプロセスを実行する。
【００５８】
スリープモードにおいて、システムによってパケットが受信されると、ステップＳ４００において、それらのパケットはＦＩＦＯバッファ３０３に追加される。その後、プロセスはステップＳ４０１に進み、ステップＳ４０１において、そのパケットに対する最大許容パケット送信時刻ｔｔｘが計算される。これは以下の式を用いて行われる。
【数４】
2013176041.tif 000006
ただし、ｔｒｘはパケットが受信された時刻である。代替的には、最大許容パケット送信時刻ｔｔｘは、バッファを空にするために必要な時間、すなわちＦＩＦＯバッファ３０３のビット数Ｂ（ｔ）を送信ビットレートＴｘＲａｔｅで割った値を考慮に入れることによって計算することができる。そのような場合、上記の式は以下のようになる。
【数５】
2013176041.tif 000007
【００５９】
現在説明中の実施形態では、ＦＩＦＯバッファ３０３を空にするのに必要な時間は、この式中の他の値に比べて無視できるので、先の式が用いられる。種々の伝送レートとトラフィッククラスを有する他の実施形態では、この第２の式を用いることもできる。
【００６０】
さらに、現在説明中の実施形態では、遅延させても消費電力に関して著しい改善を提供できない状況においては、ｍａｘＴ０値を用いてそのような不必要な遅延を制限する。しかしながら、本発明の他の実施形態では、ｍａｘＴ０値を完全に省くこともできることが理解されよう。
【００６１】
したがって、本発明の少なくとも１つの実施形態では、上記の式は単に以下のようにすることができる。
【数６】
2013176041.tif 000008
【００６２】
最大許容パケット送信時刻ｔｔｘは、そのパケットが送信前にＦＩＦＯバッファ３０３内に留まることが許される最大許容時間を表している。
【００６３】
ステップＳ４０１においてｔｔｘが計算されると、ステップＳ４０２において、Ｔ０タイマーが作動したか否か、すなわち、タイマー３０５内でＴ０タイマーが設定されたか否かに関する判断が行われる。Ｔ０がまだ設定されていない場合（受信されたパケットがＦＩＦＯバッファ３０３内の最初のパケットであることを示している）、ステップＳ４０４においてＴ０がｔｔｘに設定され、プロセスはステップＳ４００において再び開始する。最初のＴ０が設定されると、タイマーＴ０が満了するまで図４を参照しながら説明されるサイクルが継続されることが理解されよう。
【００６４】
ステップＳ４０２において、Ｔ０が設定されていると判断される場合（受信されたパケットがＦＩＦＯバッファ３０３内の最初のパケットであることを示している）、ステップＳ４０３において、現在の値Ｔ０（すなわち、タイマーＴ０内の残り時間）とｔｒｘとの和が、計算されたばかりのｔｔｘよりも大きいか否かに関する判断が行われる。大きい場合には、ステップＳ４０４において、Ｔ０はｔｔｘ−ｔｒｘに設定され、プロセスはステップＳ４００から再び開始する。しかしながら、現在の値Ｔ０とｔｒｘとの和が、計算されたばかりのｔｔｘ以下である場合には、プロセスはＴ０の現在の値を変更することなくステップＳ４００に戻る。
【００６５】
プロセスの結果に重大な影響を及ぼすことなく、ステップＳ４０２とＳ４０３の順序を入れ替えることができることは、当業者には容易に明らかであろう。
【００６６】
上記の方法を用いて、Ｔ０タイマーが系統的に調整され、ＦＩＦＯバッファ３０３に受信されたパケットを送信する際の遅延が最大化される（結果として、省エネルギー動作が向上する）。また、それと同時に、当該遅延がＦＩＦＯバッファ３０３内の最も厳しいトラフィッククラス要件を有するパケットが知覚可能な遅延を生じることなく送達されることを保証するために許される遅延を決して超えないことを確実にする。
【００６７】
図４のプロセスの一例が図５に示されている。この図において、ベストエフォート（ＢＥ）トラフィッククラスに属する第１のパケットＰ１が時刻ｔ０において受信される。ＴＢＥは５０ｍｓに等しく、ｔ０は０に等しいので、ステップＳ４０１において、ｔｔｘは５０ｍｓであると計算される。その際、タイマーＴ０はまだ作動していない（すなわち、カウントダウンを開始していない）ので、初めてＴ０が作動することになり（図示せず）、プロセスはステップＳ４０４に進み、ステップＳ４０４においてタイマーＴ０が５０ｍｓに設定され、その後、ステップＳ４００に戻る。
【００６８】
時刻ｔ１においてパケットＰ２が受信されると、プロセスが繰り返される。対応するｔｔｘが計算され、その値がｔ１＋ＴＶＯ、すなわちｔ１＋１０ｍｓに等しいことが明らかになる。ボイストラフィックに関連するクラスは、ベストエフォートトラフィックに関連するクラスよりも厳しいタイミング要件を有することは理解されよう。
【００６９】
新たなｔｔｘ（パケットＰ２に関連する）が計算されると、ステップＳ４０２において、タイマーＴ０が作動しており、最初のパケットＰ１の到着によって設定されたと判断される。それゆえ、プロセスはステップＳ４０３に進み、ステップＳ４０３において、タイマーＴ０の残り時間と第２のパケットの受信時刻ｔ１との和が、第２のパケットの受信時刻ｔ１と第２のパケットのＴｃｌａｓｓ（すなわち、ＴＶＯ）との和よりも大きいと判断される。換言すると、システムは、Ｓ４０３において、タイマーＴ０の残り時間がＴＶＯ（すなわち、パケットＰ２がそれより前に送信されなければならない最大許容遅延）よりも大きいと判断する。それゆえ、パケットＰ２のＱｏＳを確保するために、ステップＳ４０４において、パケット送信が時刻ｔ２’において開始されるようにタイマーＴ０の値を短い値に調整し直す必要がある。これは、パケットＰ２が知覚し得る遅延を生じることなく（すなわち、ＶＯトラフィッククラスタイミング要件の限度内で）送信されることを確実にする。
【００７０】
図６及び図７の状態図を参照しながら、システム３００の動作を以下に説明する。
【００７１】
図６を参照すると、初期状態６００において、初期データが送信されなければならない場合には、システムは送信状態６０１に入り、ＦＩＦＯバッファ３０３に格納されている全てのパケットを送信するのに必要な期間、この状態にとどまる。送信状態においてＦＩＦＯバッファ３０３が空になったとき、又は初期状態６００においてデータが存在しないとき、システムは図７に示されるようなスリープ状態に入る。
【００７２】
スリープ状態７００では、上述した図４のプロセスが関与する。タイマーＴ０の満了時、又はＦＩＦＯバッファ３０３内に保持されているパケット数が閾値Ｔｈに達した場合、タイマーＴ０は停止され（すなわち、解除され）、システムは送信状態７０１に入る。送信状態７０１において、送信を待っている全てのパケットが放出され、リンクを介して送信される。送信状態７０１に入ると、パラメータｎ０がＦＩＦＯバッファ３０３内に存在するパケットの数に設定される。
【００７３】
ｎ０個のパケットが送信されるまで、システムは送信状態７０１に留まる。ｎ０個のパケットが送信され、かつＦＩＦＯバッファ３０３内に依然としてパケットが存在する場合、タイマーＴ０が再作動され、時間的な制約が最も大きいパケット（すなわち、受信時に最も小さいｔｔｘ計算値を有するパケット）の放出時間に設定される。送信状態７０１中にＦＩＦＯバッファ３０３にパケットが受信されることによって生じるこの状態において、システムは、ＦＩＦＯバッファ内に残る最後のパケットが送信されるまで送信状態７０１に留まる。これは、システムがウェイクして送信状態７０１にある間、システムが最大のトラフィック量を送達することを確実にする。
【００７４】
本発明の幾つかの実施形態では、ＦＩＦＯバッファ３０３内にそれ以上送信されるべきパケットが存在しないとき、システムはスリープ＿ウェイト状態７０２に入り、タイマーＴ１を始動する。スリープ＿ウェイト状態７０２の目的は、送信状態７０１からスリープ状態７００に移行する前に、僅かな遅延を導入することである。この遅延は、本明細書においてはタイマーＴ１によって表され、アクティブモードからスリープモードに過度に頻繁に変化することに関連するオーバーヘッド（すなわち、ＬＰＩオーバーヘッド）を有利に制限する。スリープ＿ウェイト状態７０２において、タイマーＴ１が満了する前にＦＩＦＯバッファ３０３に新たなパケットが受信された場合、システムはＴ１を停止して送信状態７０１に戻り、その状態において新たなパケットは直ちに送信される。一方、Ｔ１タイマーの満了前にＦＩＦＯバッファ３０３に新たなパケットが受信されない場合、システムはスリープ状態７００に切り替わる。
【００７５】
図８は、本発明の一実施形態によるシステムの動作のタイミング図を示している。図８ａは、着信トラフィックのタイミング図を表している。この例では、システムに入力されるトラフィックは５００Ｍｂ／ｓで一定である。図８ｂは、本発明に従って処理された後の発信トラフィックのタイミング図を表している。この例では、発信トラフィックの出力速度は１Ｇｂ／ｓである。それゆえ、この例のシステムの負荷は５０％（すなわち、５００Ｍ／１Ｇ）である。
【００７６】
時刻ｔ０から、システムがスリープ状態７００から送信状態７０１に移行して送信を開始する時刻ｔａまで、ＦＩＦＯバッファ３０３は５００Ｍｂ／ｓのレートで満たされていく。スリープ状態７００から送信状態７０１へ移行する間に、システムはタイマーＴ０を停止し、ＦＩＦＯバッファ３０３内のパケットの数ｎ０を求める。
【００７７】
送信状態７０１において、システムはパケットを送信し始める。時刻ｔｂにおいてｎ０個のパケットの送信が完了すると、システムはタイマーＴ０を再始動し、ＦＩＦＯバッファ３０３が空になるまで送信を続ける。この時点において、ＦＩＦＯバッファ３０３内に残されている時間的な制約が最も大きいパケット（すなわち、受信時に最も小さいｔｔｘ計算値を有するパケット）の放出時間を用いてＴ０の値が計算される。
【００７８】
時刻ｔｃにおいてＦＩＦＯバッファが空になり、システムは送信状態７０１からスリープ＿ウェイト状態７０２に移行し、タイマーＴ１が始動される。この例では、タイマーＴ１の持続時間の値は、受信トラフィックの最小パケット間時間よりも短い。したがって、このシステムはタイマーＴ１の満了後に、スリープ＿ウェイト状態７０２からスリープ状態７００に移行する。仮にタイマーＴ１の値が受信トラフィックの最小パケット間時間よりも長い値に設定されると、タイマーＴ１の満了前にＦＩＦＯバッファ３０３がパケットによって満たされることになり、システムは代わりに送信状態７０１に戻ることになる。
【００７９】
図８の例では、Ｔ１が満了すると、時刻ｔｃにおいてシステムはスリープ状態７００に戻る。スリープ状態７００では、タイマーＴ０は図４のプロセスに従って（必要に応じて）更新される。更新されない場合には、タイマーＴ０はｎ０個のパケットを送信した後に設定された値からカウントダウンし続けることになる（図８ｂに示される）。ｔｄにおいてタイマーＴ０が満了し、その時点でタイマーＴ０は停止され、システムは再度送信状態７０１に移行する前に、ＦＩＦＯバッファ３０３内に存在するパケットの数ｎ０を求める。ｎ０個のパケットを（時刻ｔｅにおいて）送信した後、システムはタイマーＴ０を再始動し、ＦＩＦＯバッファ３０３が空になるまでパケットを送信し続ける。時刻ｔｆにおいてＦＩＦＯバッファは空になり、システムはスリープ＿ウェイト７０２に移行する。スリープ状態７００において、システムは時刻ｔｇにおけるＴ０の満了まで図４のプロセスに従ってタイマーＴ０を更新し、そこからシステムは再び送信を開始する。
【００８０】
上記のように、ｍａｘＴ０は、所与の時刻におけるＴ０タイマーに関する最適値として定義され、ＱｏＳトラフィック制約を考慮して超えてはならない値である。ｍａｘＴ０値は、理想的な電力値に関連してオペレータがサポートすることに特に異存がない最大消費電力閾値に依存する。Ｔｃｌａｓｓ値を大きくしても遅延が著しく増加する割には省電力を僅かしか向上させることができない状況において、システムによって導入される最大遅延を制限するために、ｍａｘＴ０が本発明の特定の実施形態において有利に用いられる。
【００８１】
この例が図９に示されており、この図は相対消費電力とＴ０の関係のグラフを示している。本明細書において、相対消費電力は、最適な消費電力Ｐｏｐに対する実際の消費電力として定義される。図９の３つの曲線は、種々のトラフィック負荷（すなわち、入力／出力ビットレート比）において動作するシステムを表している。
【００８２】
図９から明らかであるように、Ｔ０の値を大きくする効果は１０ｍｓ以降では著しく減少し、１５ｍｓ以降では概ね無視できるようになる。したがって、特定のトラフィッククラスが非常に大きなＴｃｌａｓｓを有することがある場合には、ｍａｘＴ０値を使用することによって、不必要に長い（すなわち、結果として相対的な消費電力が大きく減少しない）遅延を有利に避けることができる。上記のように、妥当なｍａｘＴ０値を設定すると共に、ｍａｘＴ０値とＴｃｌａｓｓ値の小さい方の値を用いてＴ０を更新することによって（図４のプロセスを参照しながら説明されたように）、本発明は、ＱｏＳトラフィック制約が考慮されることを確実にすることができ、ユーザに知覚されない程度ではあるが消費電力の著しい改善を提供できない可能性のある遅延を回避することができる。
【００８３】
図１０は、本発明の一実施形態によるデバイスのためのトラフィック負荷とＴ０値の関係のグラフを示している。本発明の性能解析は、所与の負荷（すなわち、着信／発信ビットレート比）について、Ｐｏｐに対する消費電力が所与の閾値よりも小さくなるように最小Ｔ０値を計算できることを示している。第１の曲線（破線）は、最適な消費電力Ｐｏｐよりも５％高い範囲内で動作するように構成されたシステムを表している。第２の曲線（実線）は、最適な消費電力Ｐｏｐよりも２％高い範囲内で動作するように構成されたシステムを表している。したがって、本発明によるシェーピング機構の全体的な性能は、Ｔ０の値とトラフィック負荷に依存することを示すことができる。
【００８４】
上記のように、本発明によれば、ｍａｘＴ０という値を用いることができる。また、上記のように、ｍａｘＴ０値はシステムの入力ビットレートの推定値を用いて求められ、これはトラフィック負荷の推定に寄与することになる。そして、トラフィック負荷の推定値を用いて、所与の相対消費電力閾値について、図１０に示される関係を用いて妥当なｍａｘＴ０を求めることができる。例えば、動作中の所与の時点において、入力ビットレートが出力ビットレート値の２０％であると推定され、システムが最適な消費電力Ｐｏｐの５％以内で動作すべきであると判断された場合、図１０から１８ｍｓのｍａｘＴ０値が適切であることがわかる。したがって、システムの入力ビットレートを絶えず推定することによって、消費電力が管理者によって設定された相対閾値を超えないように、Ｔ０タイマー値を変更することができる。
【００８５】
当業者によって理解されるように、入力ビットレートの推定は多数の既知の方法によって実行することができる。この推定値を与える１つの有利な方法は、タイマーＴ０が満了する度にＦＩＦＯバッファ３０３内のパケットの数ｎ０を現在のＴ０タイマーの値で割ることによって実行することができる。
【００８６】
本発明の方法とは異なり、従来技術の方法では、ＦＩＦＯバッファ３０３に第１のパケットが受信されるのを（すなわち、スリープモードにおいて現在のデータバーストを全て送達するまで）待ってＴ０を再始動することを教示している。しかしながら、この方法では、システムが大きなスループット変動を受けたときに、レイテンシとジッタを制御するこができない。
【００８７】
例えば、現在のｍａｘＴ０計算において未だ考慮されていない突然のトラフィック増加が到着する場合には、ＦＩＦＯバッファ３０３内にパケットが予期せずに累積される可能性があり、これが更なる遅延とジッタを引き起こすことになる。
【００８８】
逆に、現在のｍａｘＴ０推定値が狭い時間値を有する非常に高いトラフィック負荷に適しており、トラフィックスループットが突然降下する場合には、ＦＩＦＯバッファ３０３内に含まれるパケットが短い送信インターバルで放出される期間中に、より多くのエネルギーが消費されることになるが、それでも、スループットが降下しているために、同じパケットを送信するのに著しく長い遅延を伴う可能性があり、それゆえ消費電力が少なくなる可能性がある。本発明の１つの利点は、ｎ０個のパケットが送信された後にＴ０が設定されるので、システムはＴ０の起動を予測することができ、これにより、システムは現在の入力ビットレートの不正確な推定値を用いて、ｍａｘＴ０を近似することから起こり得る誤差を免れることができる。
【００８９】
送信サイクルの最後においてＴ０タイマーが始動するシステムでは、発信スループットの制限を回避するか（特に、例えば、提供された全ての帯域幅を使用する可能性のある、ＴＣＰアプリケーションのようなバースト性トラフィックの場合）、又は遅延若しくはジッタの導入を回避するために、ｍａｘＴ０を非常に精度良く計算して実際のトラフィック条件に近づけなければならない。トラフィックは本来バースト性であるので、高性能システムは、負荷の変動に迅速に適応するか、負荷の変動を吸収することができなければならない。
【００９０】
また、上記の種々の方法のステップをプログラムされたコンピュータによって実行できることは、当業者には理解されよう。したがって、上記の実施形態が、上記の方法のステップのうちの幾つか又は全てを実行する機械実行可能又はコンピュータ実行可能命令を含む記憶デバイスを対象にすることを理解されたい。これらの実施形態は、上記の方法のステップを実行するようにプログラムされたコンピュータを対象にすることも意図している。
【００９１】
図面に示されている要素の機能は、専用のハードウェア及び／又はソフトウェアのいずれかを用いて提供することができる。表現「処理すること」、「処理手段」、「処理するモジュール」は、限定はしないが、ディジタルシグナルプロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するためのリードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）及び不揮発性記憶装置のいずれかを含むことができる。
【図１】
2013176041.tif 000009
【図２】
2013176041.tif 000010
【図３】
2013176041.tif 000011
【図４】
2013176041.tif 000012
【図５】
2013176041.tif 000013
【図６】
2013176041.tif 000014
【図７】
2013176041.tif 000015
【図８ａ】
2013176041.tif 000016
【図８ｂ】
2013176041.tif 000017
【図９】
2013176041.tif 000018
【図１０】
2013176041.tif 000019
【外国語明細書】
Title of invention;
2013176041.tif 000020
2013176041.tif 000021
2013176041.tif 000022
2013176041.tif 000023
2013176041.tif 000024
2013176041.tif 000025
2013176041.tif 000026
2013176041.tif 000027
2013176041.tif 000028
2013176041.tif 000029
2013176041.tif 000030
2013176041.tif 000031
2013176041.tif 000032
2013176041.tif 000033
2013176041.tif 000034
2013176041.tif 000035
2013176041.tif 000036
2013176041.tif 000037
2013176041.tif 000038
2013176041.tif 000039
2013176041.tif 000040
2013176041.tif 000041
2013176041.tif 000042
2013176041.tif 000043
2013176041.tif 000044
2013176041.tif 000045
2013176041.tif 000046
2013176041.tif 000047
2013176041.tif 000048
2013176041.tif 000049
2013176041.tif 000050
2013176041.tif 000051