JP2008541600A - データを送信するためのシステム及び方法 - Google Patents

Abstract

データを更なるデバイス（Ｄ２）に対して送信するためのデバイス（Ｄ１）は、第１のクラスのデータ（ＧＴ）をデータ単位の保証されたストリームとして送信するとともに、第２のクラスのデータ単位（ＢＥ）をベストエフォート方式で送信するように構成されている。デバイス（Ｄ１）は、第１のクラスのデータ（ＧＴ）の次のバーストの開始までの残りの時間間隔（ｔ１＿ｓｔａｒｔ）から第２のクラスのデータのバーストを送信するための所要時間（ｔ２＿ｂｕｒｓｔ）を差し引いた時間が所定の時間（Ｔｐ）よりも少ない時間点（ｔ２＿ｓｔａｒｔ）において、第２のクラス（ＢＥ）に属するデータ単位のバーストの送信を開始する。

Description

本発明は、データを送信するためのデバイス及び方法に関する。

例えば携帯電話等のシステムを、モジュール形態で構成するという明確な傾向が存在する。この場合、様々なモジュールがユニバーサルインタフェースを介して互いに結合される。モジュールは、バス又はネットワーク等の接続部を介して互いにデータをやり取りすることがある。接続部の利用可能な帯域幅は、様々な要求間で分配されなければならない。接続部の割り当ては、各時間点ごとに独立に行われてもよく、又は、ＴＤＭＡシステムの場合のようにタイムスロットの状態でクラスタ化されてもよい。最も重要なクラスのデータトラフィックは、保証スループット（ＧＴ）トラフィック及びベストエフォート（ＢＥ）トラフィックである。ＧＴトラフィックは、予めスケジュールされたデータ量が明確な時間インスタンスでやり取りされることを意味している。等時性データトラフィックはその特定のケースであり、この場合、データは規則的な時間間隔で送信される。ＢＥトラフィッククラスは、これを保証しないが、最良の可能なデータ転送速度を与える。結局、第１のクラスのデータは、保証スループットデータ即ちＧＴデータとしても示される。第２のクラスのデータは、ベストエフォートデータ即ちＢＥデータとしても示される。特に携帯電話等のモバイル機器では、電力消費量を低減することが重要である。これを達成するための重要な方法は、トラフィックが存在しないときにデータ接続部をパワーダウンすることである。この特徴はＰＣＩ Ｅｘｐｒｅｓｓにおいて知られている。データリンクがアイドル状態であることが検出される場合、データリンクは約２０バスサイクル（８ｎｓ）でパワーダウンされる。その後、データリンクは、５０バスサイクル（２０ｎｓ）に亘ってパワーダウンモードに留まらなければならない。しかしながら、データ送信のための頻繁な要求がある場合には、アイドル時間は非常に短くなり、パワーダウンすることはできない。

本発明の目的は、データ送信間に残存するアイドル時間がより連続して分配されるシステムを提供することである。

本発明の更なる目的は、データ送信間に残存するアイドル時間のより連続的な分配を行う方法を提供することである。

本発明によれば、ＢＥトラフィックがＧＴトラフィックと整列させられる。ＧＴトラフィックは、保証されたデータフローを達成するために所定の間隔でスケジュールされなければならない。ＢＥデータトラフィックは、現在行き渡っている状況に応じて動的にスケジュールされるものとするとよい。既にスケジュールされたＧＴトラフィックバーストと整列させてＢＥデータトラフィックをスケジュールすることにより、データ送信間に残存する時間の寸断が制限され続けることが達成される。本発明の特に驚くべき態様は、ＢＥデータの送信が受信デバイスによって受け入れることができ且つＧＴデータトラフィックがスケジュールされない間、ＢＥデータの送信が延期されることである。この延期によって電力消費量を低減させることができるという事実にも拘わらず、単位時間当たりに送信される平均データ量を同一に保つことができる。

即ち、ＢＥトラフィックの要求は、ＧＴ送信が終了される直後まで又はＧＴトラフィックが開始する前の時間点に延期される。その場合、ＢＥ送信は、好ましくはＧＴトラフィックが開始する直前に終了されなければならず、又は、それが不可能な場合には、ＧＴ送信が終了される直後に既に開始されたＢＥトラフィックを継続しなければならない。いずれにせよ、ＧＴトラフィック間隔同士の間のアイドル間隔が複数の更に短いアイドル間隔へ寸断されることを回避しなければならない。他の実施の形態において、ＢＥデータの送信の開始は、いくらかの時間がＢＥデータ送信終了後に次のＧＴデータ送信の開始まで利用可能なままとなるような時間点においてスケジュールされる。このようにすれば、スケジュールされたＢＥデータ送信の終了前に新たな受け入れ可能なＢＥデータが利用可能になることを考慮に入れることができる。次のＧＴ送信前にＢＥ送信を実行することによってかなりの残存時間を使用し過ぎてしまいパワーダウンを行うことができない場合には、次のＧＴ送信後までＢＥ送信が部分的に延期されてもよい。例えば、ＢＥ送信が更なるＢＥ送信と整列させられてもよく、その場合、更なるＢＥ送信は、その後の次のＧＴ送信と整列させられる。

ＢＥトラフィックは、フロー制御ファシリティを用いて調整されることが好ましい。フロー制御クレジットにより、データを受信する第２のデバイスは、オーバーフローが起こる前にそれがいくつのデータ単位を受け入れることができるのかを示す。その目的のために、第２のデバイスは、それが新たなデータ単位のために利用できる余地を有するたびに、フロー制御クレジットを第１のデバイスに対して送る。あるいは、第１のデバイスは、新たなデータ単位のために利用できる余地の量を示す値を含む、第１のデバイスとのレジスタ（ｒｅｇｉｓｔｅｒ）をポーリング（ｐｏｌｌ）してもよい。

図面を参照して、本発明のこれらの態様及び他の態様について更に詳しく説明する。

図１は、本発明が適用可能な典型的なシステムを示す。システムは、複数のモジュールを備えている。モジュールアーキテクチャにより、迅速な設計と、容易なアップグレード及び再設計とが可能になる。システムは、様々なモデム、ここではＷＬＡＮモデム及びセルラーモデムを備えている第１のモジュールＭ１を含む。また、第１のモジュールＭ１は、ＷＬＡＮモデムへの第１のポートＰ１１及びセルラーモデムへの第２のポートＰ１２の他に第３のポートＰ１３及び第４のポートＰ１４を有する第１のルータＲ１も含む。第１のルータの第３のポートＰ１３は、別個のモジュールとして設けられる第２のルータＲ２の第１のポートＰ２１に結合されている。また、第２のルータＲ２は、記憶モジュールＭ２に結合された第２のポートＰ２２と、音声モジュールＭ３に結合された第３のポートＰ２３とを更に有する。

第１のルータＲ１の第４のポートＰ１４は、アプリケーションモジュールＭ４におけるアプリケーションエンジンと一体の第３のルータＲ３の第２のポートＰ３２に対して結合されている。第３のルータは第１、第３、第４のポートを更に有する。第１のポートＰ３１はカメラモジュールＭ５に結合され、また、第４のポートは、特定のアプリケーションのためのコア処理を行うアプリケーションエンジンに結合されている。アプリケーションエンジンは汎用プロセッサ又は専用ハードウェアであってもよい。第３のルータの第３のポートＰ３３は、第４のルータＲ４の第１のポートＰ１４に結合されている。

第４のルータＲ４は、第３のポートＰ４３を介してディスプレイエンジンに結合されている。第４のルータ及びディスプレイエンジンは、モジュールＭ６に組み込まれている。第４のルータＲ４は、３ＤエンジンＭ７に結合された第２のポートＰ４２を更に有する。

ルータ間のデータ交換、及び、ルータとルータのポートに結合されたデバイスとの間のデータ交換は、ＰＣＩ−Ｅｘｐｒｅｓｓのようなプロトコルを介して行われる。このプロトコルについては、インテルプレス（Ｉｎｔｅｌ Ｐｒｅｓｓ）からの「Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ ＰＣＩ Ｅｘｐｒｅｓｓ」に詳しく記載されている。

図２は、図１に示されるシステムの二つのデバイスＤ１，Ｄ２、例えば二つのルータ、又は、一つのルータとメモリ等の一つの機能ユニットとを概略的に示す。デバイスＤ１，Ｄ２は、送信部Ｔｘと受信部Ｒｘとを備えている。デバイスＤ１の出力ポートＰ１ｏは、デバイスＤ２の入力ポートＰ１ｉに結合されている。デバイスＤ２の出力ポートＰ２ｏは、デバイスＤ１の入力ポートＰ１ｉに結合されている。図示の実施の形態において、デバイスＤ１は、その出力ポートＰ１ｏとデバイスＤ２の入力ポートＰ２ｉとの間でリンクを介してデータを送信する。デバイスＤ２は、その出力ポートＰ２ｏとデバイスＤ１の入力ポートＰ１ｉとの間のリンクを介して、それがＤ１から受け入れることができるデータの量を示す。同様に、デバイスＤ２は、データをデバイスＤ１に対して送信するためのファシリティを有していてもよく、また、デバイスＤ１は、それがデバイスＤ２から受け入れることができるデータの量を示すためのファシリティを有していてもよい。送信データは、第１のクラスのデータ、即ち、保証されたスループットをもって送信されるＧＴデータを含む。このデータは、例えば、ストリーミング音声データやストリーミングビデオデータ等の等時性データである。また、送信データは、第２のクラスのデータ、即ち、ベストエフォート方式で送信されるＢＥデータ、例えばバックグラウンドで実行中のプロセス間でやり取りされるデータを更に含む。両方のデータを送信するために、また、受け入れられ得るデータ量を示すために、均一な送信機構が使用されてもよい。

図２では、デバイスＤ１の方がいくらか詳しく示されている。デバイスＤ２は、同じアーキテクチャを有していてもよい。図示のように、デバイスＤ１の受信部は、Ｄ２によって受け入れることができるＢＥデータの量を検出するための検出ユニットＦＣＤを有する。これはＧＴデータにおいては不必要である。なぜなら、このデータの送信は、予めスケジュールされているからである。

デバイスＤ１は、様々なデータソースのためのバッファＧＴ１，ＧＴ２，．．．，ＧＴｎ，ＢＥを伴うバッファユニットＢＵを有する。スケジューラＳＣは、バッファＢＥ内で利用可能なＢＥデータの量及びデバイスＤ２によって受け入れられ得るＢＥデータの量ＮＣのみならずバッファＧＴ１，ＧＴ２，．．．，ＧＴｎに格納されたＧＴデータに関する所定のスケジュールを考慮に入れて、いつ何時にどのデータが送信されるのかを決定する。データ量の情報は、フロー制御ユニットＦＣＵから検索される。このユニットＦＣＵにおける情報は、例えばフロー制御単位の形態で、スケジューラがＢＥデータを送信した場合にはスケジューラにより信号ＮＣ−をもって更新され、また、検出ユニットＦＣＤがＢＥの受け入れに関する情報をデバイスＤ２から受けた場合には検出ユニットＦＣＤにより信号ＮＣ＋をもって更新される。

図３Ａは、非アクティブ中に電力消費量を低減することができるリンクによる消費電力を概略的に示す。例えば、ＰＣＩ−Ｅｘｐｒｅｓｓがこの特徴をもたらす。しかし、特にモバイル機器のためにこれまで開発された通信規格もこの特徴を見越している。送信デバイスは、それ自体、いつ、どの期間に亘ってそれが動作しないのかを示してもよいが、そうでなければ、リンクが非アクティブであり低電力リンクモードを取ることを通信ファシリティが検出してもよい。ＰＣＩ Ｅｘｐｒｅｓｓ仕様は、二つの低電力リンク状態と、アクティブ状態電力管理（ＡＳＰＭ）プロトコルとを形成する。ＰＣＩ Ｅｘｐｒｅｓｓリンクがアイドル状態になると、リンクは、二つの低電力状態のうちの一つへと移行することができる。これらの状態は、リンクがアイドル状態のときに電力を節約するが、データが送信されるべき必要があるときには、送信器及び受信器を再同調させるために回復時間を必要とする。回復時間（又は待ち時間）が長ければ長いほど、電力使用が低くなる。最もよくある実施は、回復時間が最も短い低電力状態である。ＰＣＩ−Ｅｘｐｒｅｓｓにより、例えば送信器は、四つの記号ＣＯＭ Ｉｄｌｅ Ｉｄｌｅ Ｉｄｌｅを含むＥｌｅｃｔｒｉｃａｌ Ｉｄｌｅの順序付けられた組を送信することができる。これらの記号は、ＰＣＩ−Ｅｘｐｒｅｓｓによって使用される８／１０ビットコーディングに関連する特定の記号である。

図３Ａに示されるように、斜線部分として示される第１の時間間隔中にデータ送信が行われる。この時間間隔中にリンクの電力が十分に増大させられる。リンクがアクティブでないことを検出してリンクを低電力状態へ切り換えるためには、いくらかの時間Ｔ１を要する。リンクの非アクティブが検出されると、そのリンクに関してパワーダウン手順が開始される。この手順には、ＰＣＩ−Ｅｘｐｒｅｓｓにおいて、０．４ｎｓのサイクル４個分を要する。ＰＣＩ−Ｅｘｐｒｅｓｓにおいて、フルパワーダウンモードを達成するには、０．４ｎｓのサイクル約２０個分の時間間隔Ｔ２を要する。フルパワーダウンモードが達成されると、このモードは、最低で０．４ｎｓのサイクル５０個分の時間間隔Ｔ３に亘って維持されなければならない。リンクを再びアクティブにするには、先と同様、２０サイクル分の更なる時間間隔Ｔ４を要する。４／２０／５０／２０サイクルのこれらの数量は、リンクのいわゆるスリープモードに固有のものである。デバイスのパワーダウンがリンクのパワーダウンモードも伴う場合には、これらの時間がかなり異なると考えられる。例えば、リンクに結合されたデバイスのパワーアップ中、リンクを介して送信される拡張同期信号を用いて受信器側でＰＬＬをトレーニングするためには時間が必要である。しかしながら、様々なデータストリームのためのサービス保証の品質を危うくすることなく、リンクに結合されたデバイスのパワーダウンのために時間が利用できる場合には、電力消費量を更に減少させるためにこれが好ましい。

他のプロトコルは、一般に、パワーアップ及びパワーダウンのために異なる時間を必要とする。しかしながら、いずれにしても、真の節電をもたらすためには、少なくとも最小時間間隔に亘ってパワーダウン状態が維持されなければならない。

図３Ｂ及び図３Ｃを参照すると、ここで、時間間隔ｔ０−ｔ１及びｔ４−ｔ５においてＧＴデータの送信がスケジュールされ且つ時間点ｔ１と時間点ｔ４との間でＢＥデータの送信のために時間を利用できると仮定する。

図３Ｂは、ＧＴデータの最初の送信が終了するよりも遅い時間間隔ｔ２−ｔ１においてＢＥデータの送信が開始し、ＧＴデータの次の送信が始まる前の時間間隔ｔ４−ｔ３においてＢＥデータの送信が終了する状況を概略的に示す。

データ送信間の全体の残存アイドル時間は、（ｔ４−ｔ１）−（ｔ３−ｔ２）である。しかしながら、この残存アイドル時間の一部の間に亘ってのみ、リンクをパワーダウンすることができる。特に、リンクがパワーダウンされている総時間は、以下の通りである。
Ｔｐｄ＝（ｔ４−ｔ１）−（ｔ３−ｔ２）−２^＊（Ｔ１＋Ｔ２＋Ｔ４）

図３Ｃは、ＢＥデータの送信の開始が時間点ｔ２ｐまで延期される状況を示す。特に、この時間点ｔ２ｐは、ＢＥデータの送信がその後のＧＴデータの送信の開始時にちょうど完了されるようにスケジュールされる。しかしながら、他の方法としては、ＢＥデータの現在の送信中に更なるＢＥデータが送信のために利用可能になることを考慮に入れて、時間点ｔ２ｐが少し早くスケジュールされてもよく、又は、少し遅くスケジュールされてもよい。後者の場合、残りのＢＥデータは、ＧＴデータの送信が終了された直後に送信され得る。いずれにしても、ＢＥデータの送信は、ＧＴデータの次のバーストの開始までの残りの時間間隔（ｔ１＿ｓｔａｒｔ）からＢＥデータのバーストを送信するための所要時間（ｔ２＿ｂｕｒｓｔ）を差し引いた時間が所定の時間Ｔｐよりも短くなる時間点（ｔ２＿ｓｔａｒｔ）後に開始する。

図３Ｃに示される状況においても、先と同様に、全体の残存アイドル時間は（ｔ４−ｔ１）−（ｔ３−ｔ２）である。しかしながら、この場合、残存アイドル時間のかなり長い部分に亘ってリンクをパワーダウンすることができる。パワーダウンは、Ｔｐｄ＝（ｔ４−ｔ１）−（ｔ３−ｔ２）−（Ｔ１＋Ｔ２＋Ｔ４）中に可能である。なぜなら、この場合、ＧＴ送信間において１回だけ、パワーダウンを検出し、パワーダウンを初期化し、リンクを再びアクティブにする必要があるからである。全体のエネルギ消費量が低減されるという事実にも拘わらず、送信データの全体の量は、同じままである。

図３Ｄは、その後に第１のＧＴ送信ＧＴ１、第１のＢＥ送信ＢＥ１、第２のＧＴ送信ＧＴ２、第２のＢＥ送信ＢＥ２及び第３のＧＴ送信ＧＴ３が行われる状況を示す。図示の状況において、時間間隔Ｔ１，Ｔ２及びＴ３はそれぞれ、リンクのパワーダウンのための最小所要時間間隔Ｔｍｉｎよりも短い。同様に、時間間隔Ｔ２＋Ｔ３は、第２のＢＥ送信が第３のＧＴ送信と整列させられる場合には、パワーダウンするには短か過ぎる。

図３Ｅは、第１のＢＥ送信ＢＥ１の終了が次のＧＴ送信ＧＴ２の後まで延期される本発明の実施の一形態の動作方法を示す。特に、第１のＢＥ送信の終了は、次のＢＥ送信ＢＥ２の開始まで遅延させられる。この次のＢＥ送信ＢＥ２は、その後の次のＧＴ送信ＧＴ３と整列させられる。図示の例において、第１のＢＥ送信は、第１の部分送信ＢＥ１Ａと第２の部分送信ＢＥ１Ｂとに分離される。ここで、第１のＧＴ送信と第２のＧＴ送信との間の全体の残存アイドル時間は、Ｔ４＝Ｔ１＋Ｔ２＋Ｔ３であり、これは最小所要時間間隔Ｔｍｉｎよりも長い。

図４は、本発明に係る方法を概略的に示す。

ステップ１における初期化の後、新たなＢＥデータが送信のために利用できるまで、又は、受信デバイスが例えばフロー制御クレジットによって新たなデータ単位を受け入れることができることを示すまで、待機ステップ２が繰り返される。

これらの条件のうちの一つが適用可能になると、ステップ３が実行される。

ステップ３では、送信のために利用できるデータが存在するかどうか、また、受信デバイスが現時点でデータを受け入れることができるかどうかが検証される。これがそのようなケースである場合には、方法がステップ４へと移行し、そのようなケースでない場合には、ステップ２が繰り返される。

ステップ４では、現在ＧＴデータ送信が行われているかどうかが検証される。これがそのようなケースでない場合には、方法がステップ５へ移行する。ＧＴデータ送信が継続中である場合には、ステップ１３が実行される。

ステップ５では、次のスケジュールされたＧＴデータ送信までの残りの時間間隔ｔ１＿ｓｔａｒｔが決定される。

ステップ５の後のステップ６では、決定の瞬間の時間をｔ＝０として規定するどの時間点ｔ２＿ｓｔａｒｔにおいて受信デバイスにより受け入れることができる利用可能なＢＥデータの送信が送られるべきかが決定される。この時間点ｔ２＿ｓｔａｒｔは、以下を満たさなければならない。
ｔ２＿ｓｔａｒｔ＋ｔ２＿ｂｕｒｓｔ≧ｔ１＿ｓｔａｒｔ−Ｔｐ

ここで、ｔ２＿ｂｕｒｓｔは、利用可能で且つ受け入れることができるＢＥデータを送信するために必要な時間量である。ｔ１＿ｓｔａｒｔは、次のＧＴデータ送信がスケジュールされる時間点である。

Ｔｐは、所定の時間量である。Ｔｐ＝０の場合、ＢＥデータのバーストは、次のＧＴ送信が開始されると正に同時に完了される。

このようにして、残存アイドル時間、即ち、ＢＥデータの送信のために使用されない前のＧＴデータ送信と来るべきＧＴデータ送信との間の時間がＢＥデータ送信前の時間間隔とＢＥデータ送信後の時間間隔とに寸断されることが防止される。これは、残存アイドル時間が送信チャンネルのパワーダウンを可能にするのに十分長くなる可能性を高める。

ステップ７では、時間点ｔ２＿ｓｔａｒｔが現在の時間点ｔと比較される。

ｔ≧ｔ２＿ｓｔａｒｔである場合には、方法がステップ８へ移行し、そうでない場合には、ステップ７が繰り返される。

ステップ８では、最大時間ｔ１＿ｓｔａｒｔ−ｔ２＿ｓｔａｒｔに亘ってＢＥデータが送信される。

ステップ９では、時間点ｔ１＿ｓｔａｒｔにおいて、ＢＥデータの送信が完了され、又は、ＧＴデータのスケジュールされた送信を可能にするためにＢＥデータの送信が中断される。送信のために利用できる利用可能ＢＥデータの管理及びデータ受け入れ可能性状態、例えばフロー制御クレジットカウントの管理が更新される。更新は、ＧＴデータ送信中に行われることが好ましい。

ステップ１０では、ＧＴデータ送信の最後に、更なるＢＥデータが送信可能な状態にあるかどうかが検証される。これがそのような場合には、ステップ１１において、データの量が「少ない」か又は「多い」かどうかが検証される。量は、アイドル時間を依然として持続している間に当該量を二つのＧＴデータ送信間で送ることができる場合には少ないとみなされ、そうでない場合には多いとみなされる。データ量が多い場合には、方法がステップ８へ移行する。データ量が少ない場合には、方法がステップ１２へ移行する。ステップ１２では、ＢＥデータが送信される。この送信が終了されると、方法がステップ２へ移行する。

ステップ１３では、継続中のＧＴデータ送信がどの時間点ｔ１＿ｅｎｄにおいて終了されるのかが決定される。この時間点は、ＢＥデータの送信のための開始時間ｔ２＿ｓｔａｒｔでもある。ステップ１３の後にステップ７が続く。

図５の状態図を参照して、本発明について更に説明する。

状態図から分かるように、システムは、以下の三つの主な状態を取ることができる。
Ｉ：ＧＴデータ送信
Ｂ：ＢＥデータ送信
ＩＡ：非アクティブ：データを送信しない

第３の状態ＩＡは、以下の四つのサブ状態を有する。
ＳＮＤ：低電力又はスリープモードであり、受け入れることができるＢＥデータを送信のために利用できない。
ＳＷＤ：低電力又はスリープモードであり、受け入れることができるＢＥデータを送信のために利用できる。
ＷＮＤ：通常のパワーモードであり、受け入れることができるＢＥデータを送信のために利用できない。
ＷＷＤ：通常のパワーモードであり、受け入れることができるＢＥデータを送信のために利用できる。

以下の状態移行が起こり得る。
１．ＧＴ送信が完了した後、受け入れることができるＢＥデータをその瞬間に利用できない場合には、システムが低電力モードＳＮＤに入る。
２．モードＳＮＤにおいてＢＥデータが利用可能になり且つ次のＧＴ送信までＢＥデータの送信を維持するのにデータ量が不十分である場合には、システムが低電力モードＳＷＤに入る。
３．低電力モードＳＷＤにおいて次のＧＴデータ送信までの残り時間においてＢＥデータ送信を維持できる時間点に達する場合、システムは、それが利用可能なＢＥデータを送信する状態Ｂへと移行する。
４．この移行は、ＧＴデータ送信に関してスケジュールされた時間点に達する場合に行われる。
５．ＧＴデータ送信の直後にＢＥデータが利用可能な場合、システムは、このＢＥデータを直ちに送信し始める。
６．ＢＥ送信が完了し且つ次のスケジュールされたＧＴデータ送信まで依然としてパワーダウンのための十分な残存時間が存在する場合には、システムが移行部６を介して状態ＳＮＤに入る。
７．この状態は、それが次のスケジュールされたＧＴデータ送信のための時間である場合に移行部７を介して終了する。
８．あるいは、システムがＢＥデータ送信を完了し且つ残存アイドル時間がパワーダウンのために不十分である場合、システムは、通常パワー待機状態ＷＮＤを一時的に取る。
９．待機状態ＷＮＤの間に、新たなＢＥデータが利用可能になる場合がある。次のＧＴデータ送信までデータ送信を維持するのにＢＥデータの量が不十分である場合には、システムが状態ＷＷＤで更に待機する。この場合、依然としてアイドル時間は低電力状態に入るにはあまりにも少ないが、連続的なアイドル時間は、他の目的のため、例えばリンク制御情報を送信するために役立つ場合がある。他の実施の形態では、状態ＷＷＤが省かれる場合がある。
１０．モードＷＷＤにおいて、次のＧＴデータ送信までの残り時間においてＢＥデータ送信を維持できる時間点に達した場合、システムは、それが利用可能なＢＥデータを送信する状態Ｂへと移行する。
１１．待機状態ＷＮＤから状態Ｉへの移行は、次のＧＴデータ送信が開始する時間点で起こる。
１２．パワーダウン状態ＳＮＤの間に、次のＧＴデータ送信までデータ送信を維持するために十分な量の受け入れ可能なＢＥデータが利用可能になる場合には、モードＢへの移行が行われる。
１３．同様に、システムがモードＷＮＤにあり且つ十分な量のＢＥデータが利用可能になったときには、ＢＥデータを送信するために状態Ｂへの移行が行われる。

図６は、前述した本発明の原理を実施する図２のデバイスＤ１を更に詳しく示す。デバイスＤ１は、データを第２のデバイスＤ２へ送信するための出力ポートＰ１ｏを備えている。選択ファシリティＳＥＬは、出力ポートＰ１ｏに対するＧＴデータ又はＢＥデータのアクセスを選択的に可能にする。選択デバイスＳＥＬは、制御ファシリティによって制御される。図示の実施の形態において、制御ファシリティは、クロック信号Ｃｌの受信時にバイナリルックアップテーブルＴＢ２を周期的にアドレス指定するカウンタＡＣＮＴを備えている。ルックアップテーブルＴＢ２のアドレス指定された場所の値は、選択要素ＳＥＬによってなされるべき選択を示す。あるいは、制御ファシリティがステートマシン（状態機械）であってもよい。選択デバイスＳＥＬは、例えばこの実施の形態に示されるようにマルチプレクサであるが、そうではなく、そのうちの少なくとも一つが高オーム状態である一対の第１及び第２の３状態ゲートを備えていてもよい。デバイスは、ＢＥデータを一時的に記憶するための少なくともバッファファシリティＤＢを更に備えている。デバイスは、ＧＴデータを一時的に記憶するための更なるバッファファシリティを備えていてもよいが、デバイスのための送信スケジュールが他のデバイスと正確に同期され、それにより、受信されたＧＴデータがその次の送信先へ直ちに送信されるときには、この更なるバッファファシリティは絶対に必要なものではない。

デバイスは、次の非同期データ送信がスケジュールされる時間点と現在の時間点との間の第１の時間間隔ｔ１＿ｓｔａｒｔの継続時間を計算するとともに利用可能で且つ第２のデバイスが受け入れ可能な状態にある所定量のＢＥデータを送信するために必要な第２の時間間隔ｔ２＿ｂｕｒｓｔを計算するためのファシリティを更に備えていてもよい。図示の実施の形態において、第１の時間間隔を計算するためのファシリティは、ルックアップテーブルＴＢ１と、ルックアップテーブルをアドレス指定するためのカウンタＡＣＮＴとを備えている。クロック信号Ｃｌの受信の際に、カウンタは、ルックアップテーブルＴＢ１を周期的にアドレス指定する。ルックアップテーブルの各記憶場所は、次のＧＴデータ送信までの時間間隔の継続時間の表示を含む。そうでなければ、ルックアップテーブルＴＢ１の記憶場所は、次のＧＴデータ送信が行われる時間点のための表示を含んでいてもよい。この場合、テーブルＴＢ１内に記憶された値から現在の時間点を差し引くことにより第１の時間間隔が得られる。コントローラ、例えばコントローラＤＦＣＴがこの減算を実行してもよい。

コントローラは、バッファＤＢ内で利用でき且つ第２のデバイスＤ２が受け入れ可能な状態にあるＢＥデータの量から第２の時間間隔ｔ２＿ｂｕｒｓｔの継続時間を更に計算する。一般に、第２の時間間隔の継続時間は、この量に比例するとみなされる。この継続時間は、専用のハードウェアによって、又は、一般的な計算ファシリティによって計算され得る。

デバイスＤ１のコントローラＤＦＣＴは、第１の時間間隔と第２の時間間隔との間の差が所定の値Ｔｐよりも小さい状態を検出し且つこの状態が満たされる場合にＢＥデータの送信を可能にするためのファシリティを更に備えている。

コントローラは、リンクの予期されるアクティビティを示す出力信号を供給してもよい。例えば、コントローラは、それが所定数のクロックサイクル内でデータの次のバーストの送信を開始することを示すために、例えば受信デバイスに対して起動信号を供給してもよい。受信デバイスは、この信号を使用してそれ自体を起動させることができ、先と同様にデータのバーストが実際に開始する時に完全に使用できる。所定の時間間隔ごとに起動信号を前もって発する代わりに、コントローラは、データの次のバーストが送信されるまでのクロックサイクルの数に関する情報を定期的に又は連続的に供給してもよい。また、デバイスＤ１は、十分に長い時間に亘ってリンクのアクティビティが低下することが予期される場合、そのファシリティの特定の組、例えば出力バッファをパワーダウンしてもよい。

コントローラＤＦＣＴの一例が、図７に更に詳しく示されている。

図示のコントローラは、バッファファシリティＤＢを制御するための第１のカウンタＣＮＴＲ１及び第２のカウンタＣＮＴＲ２を内部に備えている。書き込みカウンタは、新たなＢＥデータを一時的に記憶できるバッファ内の記憶場所ＷＰを示し、また、読み取りカウンタは、ＢＥデータを読み出すことができるバッファ内の記憶場所ＲＰを示す。他の実施の形態では、シフトレジスタが使用されてもよく、又は、データの順序が無視されてもよい場合には、一つのスタックの状態でデータが記憶されてもよい。図示の実施の形態では、カウンタＤ＋が新たなＢＥデータの到達を示す信号を受信するたびに、書き込みポインタＷＰが周期的にインクリメントされる。減算器ＳＵＢは、書き込みポインタＷＰ及び読み取りポインタＲＰの値から、利用可能なＢＥデータの量Ｎｂｅを計算する。フロー制御ユニットＦＣＵは、デバイスＤ２から受け取られた多くのクレジットＮＣ＋及び送信デバイスＤ１によって費やされた多くのクレジットＮＣ−を監視することにより、データのどの量ＮＣを受信デバイスＤ２が受け入れ可能な状態にあるのかを計算する。各クレジットは、例えばバイトごとに、ワードごとに、又は、ワードのパケットごとにデバイスＤ２が新たなデータ単位を受け入れてもよいことを示す。ユニットＭＩＮは、その後に送信できるデータの量を計算する。この量は、利用できるデータの量Ｎｂｅ及び受け入れることができるデータの量ＮＣの最小値である。ユニットＭＩＮは、この送信のために必要な時間間隔を示す出力値ｔ２＿ｂｕｒｓｔを供給する。更なる減算器ＳＵＢ２は、この値ｔ２＿ｂｕｒｓｔを、次のスケジュールされたＧＴ送信まで残る時間間隔ｔ１＿ｓｔａｒｔの値から差し引くとともに、差Δｔを示す値をゲートＧＡＴＥに対して供給する。ゲートＧＡＴＥは、この値Δｔを所定の値Ｔｐと比較する。条件Δｔ＜Ｔｐが成り立つと直ちに、ゲートは、データバッファＤＢの読み取りポインタＲＰを制御する第２のカウンタＣＮＴＲ２に対してクロック信号を送信する。それに応じて、データバッファＤＢがそのＢＥデータを解放する。

Ｔｐが値０を取ることができ、その場合、第２のデバイスＤ２のために受け入れることができるＢＥデータ量の送信の完了は、次のＧＴデータ送信の開始と一致する。新たなＢＥデータが利用可能になること、又は、ＢＥデータの現在の送信中に第２のデバイスＤ２が更なるＢＥデータを受け入れてもよいことを考慮に入れるため、値Ｔｐ＞０が選択されてもよい。Ｔｐのマイナス値は一般に有利ではない。なぜなら、その場合、ＢＥデータの送信が必要以上の長い時間に亘って延期されるからである。

尚、本発明の保護範囲は、本明細書で説明した実施の形態には限定されない。システムの一部は、ハードウェア、ソフトウェア、又は、これらの組み合わせとして実施されてもよい。本発明の保護範囲は、特許請求の範囲内の参照符号によっても限定されない。用語「備える、含む（ｃｏｍｐｒｉｓｉｎｇ）」は、請求項に記載されている要素以外の要素を排除しない。要素に先行する用語「一つの（ａ（ｎ））」は、複数のそれらの要素を排除しない。本発明の一部を形成する手段は、専用のハードウェアの形態で又はプログラムされた汎用プロセッサの形態で実施されてもよい。本発明は、それぞれの新規な特徴又は特徴の組み合わせに存在する。

本発明を適用することが可能な典型的なデータ処理システムを示す。 データ処理システムのデバイスを更に詳しく示す。 データ処理システムにおけるリンクのアクティビティの様々な段階中のデータ送信に関与する電力消費量を概略的に示す。 ＢＥデータトラフィックをスケジュールする従来のモードにおける電力消費量を示す。 ＢＥデータトラフィックをスケジュールする本発明に係るモードにおける電力消費量を示す。 ＢＥデータトラフィックをスケジュールする本発明に係る更なるモードにおける電力消費量を示す。 ＢＥデータトラフィックをスケジュールする本発明に係る更なるモードにおける電力消費量を示す。 本発明に係る方法を示すフローチャートである。 本発明に係るデバイスの可能な状態及びそれらの状態間の移行を伴う状態図を示す。 本発明に係るデバイスを概略的に示す。 図６のデバイスの一態様を更に詳しく示す。

Claims (7)

1. データを更なるデバイス（Ｄ２）に対して送信するためのデバイス（Ｄ１）であって、第１のクラスのデータ（ＧＴ）をデータ単位の保証されたストリームとして所定の時間インスタンスにおいて送信するとともに、第２のクラスのデータ（ＢＥ）をベストエフォート方式で送信するように構成されているデバイス（Ｄ１）において、前記第１のクラスのデータ（ＧＴ）の次のバーストの開始までの残りの時間間隔（ｔ１＿ｓｔａｒｔ）から前記第２のクラスのデータ（ＢＥ）のバーストを送信するために必要な時間（ｔ２＿ｂｕｒｓｔ）を差し引いた時間が所定の時間（Ｔｐ）よりも少ない時間点（ｔ２＿ｓｔａｒｔ）において、前記第２のクラス（ＢＥ）に属するデータ単位のバーストの送信を開始することを特徴とするデバイス（Ｄ１）。
2. ａ．データを前記第２のデバイス（Ｄ２）に対して送信するための出力ポート（Ｄ１Ｐ）と、
   ｂ．少なくとも前記第１のクラスのデータ（ＧＴ）又は前記第２のクラスのデータ（ＢＥ）のうちの一方からの前記出力ポート（Ｄ１Ｐ）へのアクセスを選択的に可能にするための選択ファシリティ（ＳＥＬ）と、
   ｃ．前記第２のクラスのデータ（ＢＥ）を一時的に記憶するための少なくともバッファファシリティ（ＤＢ）と、
   ｄ．次の非同期データ送信がスケジュールされる時間点と現在の時間点との間の第１の時間間隔（ｔ１＿ｓｔａｒｔ）を計算するとともに、利用可能で且つ前記第２のデバイスが受け入れ可能な状態にある所定量のベストエフォートデータ（ＢＥ）を送信するために必要な第２の時間間隔（ｔ２＿ｂｕｒｓｔ）を計算するためのファシリティ（ＡＣＮＴ，ＴＢ１）と、
   ｅ．前記第１の時間間隔（ｔ１＿ｓｔａｒｔ）と前記第２の時間間隔（ｔ２＿ｂｕｒｓｔ）との間の時間間隔差が所定の値（Ｔｐ）以下となる状態を検出するとともに、この状態が満たされる場合に前記第２のクラスのデータ（ＢＥ）の送信を可能にするための送信制御ファシリティ（ＤＦＣＴ，ＡＣＮＴ，ＴＢ２）と、
   を備えていることを特徴とする請求項１に記載のデバイス（Ｄ１）。
3. 前記送信制御ファシリティ（ＤＦＣＴ）は、前記第２のクラスのデータ（ＢＥ）のバーストの送信の開始の時間点（ｔ２＿ｓｔａｒｔ）をスケジュールするとともに、その時間点までカウントダウンすることによりこの開始を起こすことを特徴とする請求項２に記載のデバイス。
4. 前記送信制御ファシリティは、前記時間間隔差を定期的に再計算するとともに、前記状態が満たされる場合に前記第２のクラスのデータのバーストの送信の開始を起こすことを特徴とする請求項２に記載のデバイス。
5. データ処理システムのためのルータであって、請求項１乃至４のいずれか一項に記載のデバイスを備えていることを特徴とするルータ。
6. データ処理システムのための機能ユニットであって、請求項１乃至４のいずれか一項に記載のデバイスを備えていることを特徴とする機能ユニット。
7. データを送信するための方法であって、第１のクラスのデータ（ＧＴ）がデータ単位の保証スループットストリームとして所定の時間インスタンスにおいて送信されるとともに、第２のクラスのデータ（ＢＥ）がベストエフォート方式で送信される方法において、前記第１のクラスのデータの次のバーストの開始までの残りの時間間隔（ｔ１＿ｓｔａｒｔ）から前記第２のクラスのデータのバーストを送信するために必要な時間（ｔ２＿ｂｕｒｓｔ）を差し引いた時間が所定の時間（Ｔｐ）よりも少ない時間点（ｔ２＿ｓｔａｒｔ）において前記第２のクラスに属するデータの送信が開始されることを特徴とする方法。

Images