(57)【要約】  エラーを有する相互接続において、リアルタイムトラフィックのための保証型サービスを確実化するための方法が提供される。リアルタイムトラフィックは、第１および第２のトラフィッククラス（ＨＲＴ，ＳＲＴ）を備える。第１および／または第２のトラフィッククラス（ＨＲＴ，ＳＲＴ）のリアルタイムトラフィックは、送信器から受信器へ送信される。受信器によって、リアルタイムトラフィックの送信中にエラーが生じたかどうかが検出され、エラーは送信器に報告される。所定の期間内に、送信器が受信器からのエラー報告を受信した場合、第２のトラフィッククラス（ＳＲＴ）のリアルタイムトラフィックの少なくとも一部が、送信器によって再送信される。
2010529800.tif 000002
【特許請求の範囲】
【請求項１】
エラーを有する相互接続において、第１および第２のトラフィッククラスを備えるリアルタイムトラフィックのための保証型サービスを確実化するための方法であって、
前記第１および／または第２のトラフィッククラスのリアルタイムトラフィックを、送信器から受信器へ送信するステップと、
前記受信器により、前記リアルタイムトラフィックの送信中にエラーが生じたかどうかを検出し、エラーを前記送信器に報告するステップと、
所定の期間内に、前記送信器が前記受信器からのエラー報告を受信した場合、前記第２のトラフィッククラスのリアルタイムトラフィックの少なくとも一部を、前記送信器によって再送信するステップと、
を備えることを特徴とする方法。
【請求項２】
前記相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する複数の接続に基づく、ことを特徴とする請求項１に記載の方法。
【請求項３】
前記相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する複数の接続に基づき、かつ可変ビットレートを備え、前記方法は、
少なくとも１つの第１の帯域幅を、それぞれの第１の接続に関連付けるステップと、
追加の少なくとも１つの第２の帯域幅を、必要に応じて前記少なくとも１つの第１の帯域幅に関連付け、および／または、前記第１の接続が前記第２のトラフィッククラスのトラフィックを備える場合、前記少なくとも１つの第１の接続の少なくとも一部の再送信のための、少なくとも１つの第３の帯域幅を供給するとともに、第３のトラフィックのための帯域幅を供給するための、共通プール帯域幅ユニットを提供するステップと、を備える、ことを特徴とする請求項１または請求項２に記載の方法。
【請求項４】
前記トラフィックは、第１のトラフィッククラスとしてのハードリアルタイムトラフィック、第２のトラフィッククラスとしてのソフトリアルタイムトラフィック、制御トラフィック、および／またはベストエフォートトラフィックを備え、
前記ベストエフォートトラフィック、前記制御トラフィック、前記第１のトラフィッククラス、第２クラスのトラフィックの再送信、および第２クラスのトラフィックは、それぞれ、これらを高い順に関連付ける優先度を有する、ことを特徴とする請求項１、請求項２または請求項３に記載の方法。
【請求項５】
第１および第２のトラフィッククラスを備えるリアルタイムトラフィック通信のための、エラーが発生し得る相互接続と、
エラー報告が受信された場合に、前記第２のトラフィッククラスのリアルタイムトラフィックの少なくとも一部の再送信を開始するための再送信処理ユニットと、
前記第２のクラスのリアルタイムトラフィックの少なくとも一部の再送信の調停を行うためのリアルタイムトラフィックアービターと、
を備えることを特徴とする電子装置。
【請求項６】
前記リアルタイムトラフィックアービターは、追加の第２の帯域幅を、必要に応じて前記第１の帯域幅に関連付ける共通プール帯域幅カウンタを備えており、前記第１の接続が前記第２のトラフィッククラスのトラフィックを備える場合に前記第１の接続の少なくとも一部の再送信のための第３の帯域幅を供給し、第３のトラフィックのための帯域幅を供給する、ことを特徴とする請求項５に記載の電子装置。
【請求項７】
エラーを有する相互接続において、リアルタイムトラフィックのための保証型サービスを確実化するための方法であって、前記相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する複数の接続に基づくものである、方法において、
第１の帯域幅を、それぞれの第１の接続に関連付けるステップと、
追加の第２の帯域幅を、必要に応じて前記第１の帯域幅に関連付け、前記第１の接続の少なくとも一部の再送信のための第３の帯域幅を供給し、および／または第３のトラフィックのための帯域幅を供給するための、共通プール帯域幅ユニットを供給するステップと、を備えることを特徴とする方法。
【請求項８】
前記相互接続を介した通信は、可変ビットレートを備え、前記リアルタイムトラフィックは、第１および第２のトラフィッククラスを備え、
前記共通プール帯域幅ユニットは、前記第１の接続が前記第２のトラフィッククラスのトラフィックを備える場合、前記第１の接続の少なくとも一部の再送信のための第３の帯域幅を供給するように構成されている、ことを特徴とする請求項７に記載の方法。
【請求項９】
第１および第２のトラフィッククラスを備える、複数の接続に基づくリアルタイムトラフィック通信のための相互接続と、
前記接続を処理するための接続処理モジュールユニットと、
送信中にエラーが生じた場合に、前記第２のトラフィッククラスのリアルタイムトラフィックの少なくとも一部の再送信を開始するための再送信処理ユニットと、
前記第２のクラスのリアルタイムトラフィックの少なくとも一部の再送信の調停を行うためのリアルタイムトラフィックアービターと、を備えることを特徴とする電子装置。
【請求項１０】
前記リアルタイムトラフィックアービターは、追加の第２の帯域幅を、必要に応じて前記第１の帯域幅に関連付け、前記第１の接続が前記第２のトラフィッククラスのトラフィックを備える場合、前記第１の接続の少なくとも一部の再送信のための第３の帯域幅を供給し、第３のトラフィックのための帯域幅を供給するための、共通プール帯域幅ユニットを備える、ことを特徴とする請求項９に記載の電子装置。
【請求項１１】
前記第１および第２のトラフィッククラスのそれぞれのために、前記リアルタイムトラフィックアービターは、競合解決および許可配信ユニットを備え、前記ユニットを用いて、前記第１および第２のトラフィッククラスにそれぞれ属する接続からのリクエストの間の競合が解決され、競合の勝者への許可が配信される、ことを特徴とする請求項９または請求項１０に記載の電子装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子装置および保証型サービスを確実化する方法に関する。
【背景技術】
【０００２】
携帯電話または携帯情報端末（ＰＤＡ）などの現在の移動体システムは、新たな機能を実現し、既存の機能を改善するための要求が、増加する一方であり、このため、絶え間なく複雑さが増している。
【０００３】
スマートフォンおよびアプリケーションの豊富なネットワーク化された他の移動体装置のコストを削減し、機械的設計を簡素化するために、ＭＩＰＩは、高速直列ＰＨＹ層（ＤＰＨＹ）を定義している。ＭＩＰＩは、また、ＯＳＩプロトコルスタックに基づく階層化プロトコルスタック、すなわちＵｎｉｆｉｅｄ  Ｐｒｏｔｏｃｏｌ（ＵｎｉＰｒｏ）を、ＰＨＹ層の上に規定しており、これは、信頼性のある、ネットワーク化可能な、待ち時間を意識したデータ転送を、移動体装置の構成要素またはモジュール間で提供する。エラー検出およびフレーム再送信を用いて、ＵｎｉＰｒｏは、雑音の多い移動体環境により発生するエラーに対する信頼性を提供する。ＵｎｉＰｒｏのクライアントとして考えられる、ベースバンド通信に対するＲＦ、ビデオストリーミングなどのようなリアルタイムアプリケーションは、帯域幅保証および厳密な待ち時間／ジッタ制限を必要とする。再送信は、これらの保証を妨げる。
【０００４】
リアルタイムトラフィックは、論理的な正確性を伴って、期限の前に供給されなかった場合、その有効性を失うトラフィックである。リアルタイムトラフィックは、ハードリアルタイムまたはソフトリアルタイムに分類される。トラフィックは、ジッタについて厳しい制限を有する場合、ハードリアルタイムであり、一方、ソフトリアルタイムは、中程度の量のジッタを許容することができる。しかし、これらの両方が、帯域幅の保証を必要とする。ベースバンドデータ送信に対するＲＦは、ハードリアルタイムトラフィックの例であり、一方、圧縮ビデオ送信は、ソフトリアルタイムトラフィックのカテゴリーに属する。独立した保証を複数の接続のそれぞれに提供できるように、接続指向のデータ転送機構が用いられる。外部の機構が、セットアップされる接続の帯域幅、ジッタおよび待ち時間の要件を決定する。
【発明の概要】
【０００５】
したがって、本発明の目的は、ハードリアルタイムトラフィックとソフトリアルタイムトラフィックとを区別することができ、通信帯域幅に関する保証を提供することが可能な、電子装置および保証型サービスを確実化する方法を提供することである。
【０００６】
この目的は、請求項１および請求項７に記載の方法、ならびに請求項５および請求項９に記載の電子装置によって解決される。
【０００７】
したがって、エラーを有する相互接続において、リアルタイムトラフィックのための保証型サービスを確実化するための方法が提供される。リアルタイムトラフィックは、第１および第２のトラフィッククラスを備える。第１および／または第２のトラフィッククラスのリアルタイムトラフィックは、送信器から受信器へ送信される。受信器によって、リアルタイムトラフィックの送信中にエラーが生じたかどうかが検出され、エラーは送信器に報告される。所定の期間内に、送信器が受信器からのエラー報告を受信した場合、第２のトラフィッククラスのリアルタイムトラフィックの少なくとも一部が、送信器によって再送信される。
【０００８】
本発明の態様によると、相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する接続に基づき、相互接続は、直列の相互接続として実施される。
【０００９】
本発明のさらなる態様によると、相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する接続に基づき、かつ可変ビットレートを有する。第１の帯域幅が、それぞれの第１の接続に関連付けられる。追加の第２の帯域幅を、必要に応じて第１の帯域幅に関連付け、第１の接続が第２のトラフィッククラスのトラフィックを備える場合、第１の接続の少なくとも一部の再送信の前に、第３の帯域幅を供給し、第３の接続を有する帯域幅を供給するための、共通プール帯域幅ユニットが設けられる。
【００１０】
本発明のさらなる態様によると、トラフィックは、第１のトラフィッククラスとしてのハードリアルタイムトラフィック、第２のクラスとしてのソフトリアルタイムトラフィックおよび制御トラフィックを備える。制御トラフィック、第１のトラフィッククラス、第２のトラフィッククラスの再送信、および第２のトラフィッククラスは、高い順に関連付けられた優先度を有する。
【００１１】
本発明は、また、電子装置に関する。電子装置は、リアルタイムトラフィック通信のための相互接続を備える。リアルタイムトラフィックは、第１および第２のトラフィッククラスを備える。電子装置は、トラフィックの受信器が、送信中にエラーを報告した場合に、第２のトラフィッククラスのリアルタイムトラフィックの少なくとも一部の再送信を開始するための再送信処理ユニットを、さらに備える。電子装置は、第１および第２のトラフィッククラスについての調停に加えて、第２のクラスのリアルタイムトラフィックの少なくとも一部の再送信の調停を行うためのリアルタイムトラフィックアービターを、さらに備える。
【００１２】
本発明は、また、エラーを有する相互接続において、リアルタイムトラフィックのための保証型サービスを確実化する方法に関する。相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する接続に基づく。第１の帯域幅が、それぞれの第１の接続に関連付けられる。追加の第２の帯域幅を、必要に応じて第１の帯域幅に関連付け、第１の接続の少なくとも一部の再送信のための第３の帯域幅を供給し、および／または第３の接続のための帯域幅を供給するための、共通プール帯域幅ユニットが設けられる。
【００１３】
本発明の態様によると、相互接続を介した通信は、可変ビットレートを備え、リアルタイムトラフィックは、第１および第２のトラフィッククラスを備える。共通プール帯域幅ユニットは、第１の接続が第２のトラフィッククラスのトラフィックを備える場合、第１の接続の少なくとも一部の再送信のための第３の帯域幅を供給するように適合されている。
【００１４】
本発明は、また、接続に基づくリアルタイムトラフィック通信のための相互接続を備える電子装置に関する。リアルタイムトラフィックは、第１および第２のトラフィッククラスを備える。電子装置は、接続を処理するための接続処理モジュールユニットと、トラフィッククラスの受信器が、送信中にエラーを報告した場合、第２のトラフィッククラスのリアルタイムトラフィックの少なくとも一部の再送信を開始するための再送信処理ユニットと、をさらに備える。電子装置は、第１および第２のトラフィッククラスにおける調停を行うことに加えて、第２のクラスのリアルタイムトラフィックの少なくとも一部の再送信の調停を行うためのリアルタイムトラフィックアービターを、さらに備える。本発明の態様によると、リアルタイムトラフィックアービターは、追加の第２の帯域幅を、必要に応じて第１の帯域幅に関連付け、第１の接続が第２のトラフィッククラスのトラフィックを備える場合、第１の接続の少なくとも一部の再送信のための第３の帯域幅を供給し、第３の接続のための帯域幅を供給するための、共通プール帯域幅ユニットを備える。
【００１５】
本発明は、ハードおよびソフトリアルタイムトラフィックを区別し、リアルタイムトラフィックの両方のカテゴリに対して、帯域幅の保証とジッタおよび待ち時間についての厳しい制限とを提供する概念に関する。ハードリアルタイムトラフィックのために、ジッタについての厳しい低い制限を提供することができ、固定数の再送信を許可することによって、ソフトリアルタイムトラフィックの信頼性を向上することができる。
【００１６】
しかし、ハードリアルタイムの再送信は、顕著なジッタをもたらすので無益である。エラーが検出された場合でも、ハードリアルタイムトラフィックは、これらのエラーを有するアプリケーションに供給される。その理由は、ハードリアルタイムアプリケーションは、データのエラーを処理することができるが、データ送信における遅延は受け付けないからである。ソフトリアルタイムトラフィック向けに、データ転送の堅牢性は、固定数の再送信、例えばフレームシーケンス番号に基づく一度の再送信を通して改善することができる。遠隔ノードからのＵｎｉＰｒｏにおける既存のＮＡＣ制御フレームを修正して、最後に正しく受信されたソフトリアルタイムトラフィックのフレームシーケンス番号を保持させることによって、再送信方式を実施することができる。否定応答フレームＮＡＣを、ローカルノードまたは遠隔ノードから送信できることに留意すべきである。遠隔ノードＮＡＣを用いて、どのフレームを再送信すべきかが示される。ローカルノードは、遠隔ノードにＮＡＣを送信して、遠隔ノードによってローカルノードに送信されたいくつかのフレームが、誤って受信されたことを知らせることができる。
【００１７】
可変ビットレートリアルタイムトラフィック（ＶＢＲ−ｒｔ：Variable Bit Rate real-time traffic、例えば圧縮画像送信）の場合、最大レートの帯域幅を割り当てる代わりに、接続用の最小データレートの帯域幅が割り当てられる。変化を吸収するために、残りの帯域幅の割り当てを、「共通プール」に割り当てる。この帯域幅の共通プールは、制御トラフィック（最高の優先度、例えば（送信側）ＮＡＣ）、リプレイトラフィック、ＶＢＲ−ｒｔ（最低の優先度）またはＴｃ−０、Ｔｃ−１などの他のトラフィックによって共有される。共通プールのサイズは、ノードでのトラフィック特性に依存する。
【００１８】
リアルタイムトラフィック調停は、先取することが可能な可変サイズのＵｎｉＰｒｏフレームの細分性で動作する。よって、固定サイズのスロットの概念はない。各接続は、送信すべきフレームがあるとすぐに、アービターにリクエストを行う。また、再送信スキームの結果としてのリクエストもあり得る。全てのリクエストは、以下のトラフィックカテゴリのいずれか、すなわちハードリアルタイム（最高の優先度）または再送信すなわちソフトリアルタイム（最低の優先度）に該当する。競合がある場合は、最高の優先度のカテゴリが選択される。カテゴリ内でのタイ（tie）は、カテゴリ内部の優先機構を用いて解決することができ、ここで、ハードリアルタイムトラフィックＲＴおよびソフトリアルタイムトラフィックＲＴのみが、このようなタイを経験し得る。再送信カテゴリは、１つの接続として見ることができ、したがって、構成によりタイブレークする機構は必要とされない。カテゴリ内の優先度の割り当ては、帯域幅、トラフィックフローのジッタ要件に基づく接続セットアップで行われる。ひとたび、リアルタイムアービターが決定を行うと、アービターは許可を発行する。より低い優先度のカテゴリに発行された許可は、より高い優先度のカテゴリからのリクエストによって先取することができる。ひとたび先取が終わると、アービターは、先取された接続に戻る。先取は、トラフィックカテゴリ内では許されない。アービターは、現在許可されているフレームがフレーム終了インジケータを与えると、次のフレームの許可をスケジュールする。これは、スケジューリングに加えられた待ち時間のように見えるが、パイピングによって、およびＬ２（レベル２）トレイラー送信によっても、吸収することができる。
【００１９】
効率的なリンク帯域幅割り当てを、「共通プール」帯域幅の概念を通して、行うこともでき、これは、制御、再送信およびＶＢ−Ｒｔによって共有することができる。
【００２０】
さらに、本発明は、「グループ」データ送信をサポートする概念に関し、この概念は、電力消費を減少させる。さらに、肯定応答またはフロー制御は要求されず、このことは、一方向のデータフローの場合に、戻りのリンクが低電力モードに移行することを可能にし、リンク電力消費を２の因数で減少させる。
【００２１】
保証は、接続ごとのベースで個別に提供することができ、これは、リアルタイムおよびベストエフォートの適用の混合が共存し、個別に最適化されることを可能にする。本発明の原理は、ＵｎｉＰｒｏに適合することができる。
【００２２】
本発明のさらなる態様は、独立請求項において定義される。
【図面の簡単な説明】
【００２３】
【図１】図１は、第１の実施形態に係る電子装置の基本ブロック図を示している。
【図２】図２は、第１の実施形態に係る接続処理ブロックユニットの基本ブロック図を示している。
【図３】図３は、本発明に係る帯域幅カウントステートマシンのフローチャートを示している。
【図４】図４は、本発明に係るバッファに書き込みするためのステートマシンのフローチャートを示している。
【図５】図５は、本発明に係るリクエスト生成のステートマシンのフローチャートを示している。
【図６】図６は、本発明に係る許可処理ステートマシンのフローチャートを示している。
【図７】図７は、本発明に係る再送信のためのリクエスト生成のフローチャートを示している。
【図８】図８は、本発明に係る再送信処理のための許可処理ステートマシンのフローチャートを示している。
【図９】図９は、本発明に係る再送信バッファの上書き処理のフローチャートを示している。
【図１０】図１０は、本発明に係る調停ステートマシンのフローチャートを示している。
【図１１】図１１は、本発明に係るリクエスト競合解決および許可配信ステートマシンのフローチャートを示している。
【図１２】図１２は、共通カウンタ制御ステートマシンのフローチャートを示している。
【発明を実施するための形態】
【００２４】
本発明の実施形態および利点を、これより、図面を参照してより詳細に説明する。
【００２５】
図１は、本発明に係る電子装置のブロック図を示している。電子装置は、接続処理モジュールユニットＣＰＭと、接続処理モジュールユニットＣＰＭの出力に結合されたマルチプレクサＭ１と、Ｌ２フレーム処理ユニットＬ２ＦＰと、再送信処理ユニットＲＰＭと、第２のマルチプレクサＭ２と、リアルタイムトラフィックアービターＲＴＴＡと、Ｌ２静的優先度アービターＬ２ＳＰＡと、Ｌ２マルチプレクサＬ２Ｍと、を備える。接続処理モジュールユニットは、リクエスト生成および個別の接続への許可処理を行う。接続処理モジュールユニットＣＰＭは、ハードまたはソフトのリアルタイムトラフィックカテゴリのいずれかに属する、（同一の）サブモジュール、すなわち、接続処理ブロックユニットＣＰＢで構成されている。再送信トラフィックは、別の接続とみなされ、再送信処理ユニットＲＰＭによって処理される。再送信処理ユニットＲＰＭは、接続処理モジュールユニットＣＰＭサブモジュールと同様である。リアルタイムトラフィックアービターＲＴＴＡは、様々な接続からの要求を調停し、最高の優先度の接続に許可を与える。リアルタイムトラフィックアービターＲＴＴＡは、ハンドシェイク信号を介して接続処理モジュールユニットＣＰＭおよび再送信処理ユニットＲＰＭと相互作用し、決定を行う。Ｌ２フレーム処理モジュールＬ２ＦＰＭは、データフレームとしてＵｎｉＰｒｏネットワークにおいて搬送されるべきパケットに必要とされるフレームヘッダおよびトレイラー情報を加え、Ｌ２静的優先度アービターＬ２ＳＰＡは、制御、リアルタイムおよび他のトラフィッククラスフレーム間の調停を行う。
【００２６】
ハードリアルタイムリクエスト競合解決および許可配信ユニットＨＲＣＲは、全てのハードリアルタイムトラフィックＨＲＴ接続についての集合的リクエストを生成し、アービターＲＴＴＡは、このユニットに対して、集合的許可を示して返し、この許可は、配信することができる。ソフトリアルタイムリクエスト競合解決および許可配信ユニットＳＲＣＲは、全てのソフトリアルタイムトラフィックＳＲＴ接続についての集合的リクエストを生成し、アービターＲＴＴＡは、このユニットに対して、集合的許可を発行して返し、この許可は、次いで配信される。再送信処理ユニットＲＴＭのステートマシンＲＰＭＳは、アービターＲＴＴＡのステートマシンＲＴＴＡＳＭに対して再送信リクエストを発行し、このステートマシンは、再送信処理ユニットＲＰＭＳＭのステートマシンに対して、許可を発行して返す。
【００２７】
接続処理モジュールユニットＣＰＭは、接続処理ユニットＣＰＢと呼ばれる、各接続に対して１つずつの同一のブロックからなる。
【００２８】
図２は、図１の接続処理ブロックユニットのブロック図を示している。接続処理ブロックユニットＣＰＢは、帯域幅カウンタＢＷＣと、接続バッファＣＰＢＢと、接続処理ＣＰＢ状態ユニットと、を備える。ＣＰＢ状態ユニットは、さらに、書き込みユニットＷＳと、リクエスト生成ステートマシンＲＧＳと、許可処理ステートマシンＧＰＳとに分かれる。レジスタＭＢＷＲ，ＡＢＷＲは、特定の接続に割り当てられた最小および追加の帯域幅を保持する機能を果たし、バッファ内のパケットの終了アドレスは、小型のメモリ（書き込みユニット内に含まれる）に記憶される。これは、接続内で可変長パケットがサポートされる場合に要求される。最小帯域幅レジスタＭＢＲＷは、接続に対して保証される帯域幅を記憶する。追加帯域幅レジスタＡＢＷＲは、共通帯域幅プールから使用することができる、追加帯域幅を記憶する。全ての非可変ビットレートＶＢＲ−ｒｔトラフィックについて、追加帯域幅レジスタ内の値をゼロにすることができる。接続処理ブロックユニットＣＰＢは、これらのレジスタ内の値を、決定を行う際に使用する。
【００２９】
帯域幅カウンタＢＷＣには、最小帯域幅レジスタからの値が定期的（例えば１００ミリ秒ごと）にロードされる。
【００３０】
図３は、帯域幅カウンタステートマシンのフローチャートを示している。帯域幅カウンタＢＷＣで行われる帯域幅カウンタ方法またはステートマシンは、アイドル状態において（ステップＳ１）、デクリメントイネーブルｄｅｃ＿ｅｎ＿ＢＷまたは帯域幅アップデートＢＭ＿ｕｐｄａｔｅのいずれかが受信されるとトリガされる。まず、（定期的）ＢＷアップデートの真がある場合（ステップＳ２）、ＢＷカウンタに、最小帯域幅レジスタＭＢＷＲから値がロードされる（ステップＳ３）。ステートマシンは、アイドル状態（ステップＳ１）に戻るが、それは、同時のデクリメントイネーブルがあったとしても、それについては、すでに前のインターバルの帯域幅において計上されているからである。ＢＷアップデートチェックが偽である場合（ステップＳ２）、カウンタＢＷＣをデクリメントする（ステップＳ４）。追加の帯域幅が提供されている場合、カウンタＢＷＣの値は、追加の帯域幅レジスタＡＢＷＣの値まで、負となる可能性がある。帯域幅利用可能性のチェックは、許可処理ステートマシンによって行われる。
【００３１】
接続処理ユニット内の接続バッファＣＰＢＢは、接続のそれぞれに対して、論理的または物理的いずれかに分離されたものとすることができる。これらのバッファの主な機能は、同一のトラフィックカテゴリのトラフィックフロー間に競合がある場合、あるいはＬ１／Ｌ２再初期化またはより高い優先度のフレーム送信のために「一時停止」が生成された場合に、データを保持することである。
【００３２】
バッファへの書き込みまたは読み出しは、バイトの細分性で扱われるものとみなされる。あるいは、バッファは、ワード細分性で実施することもでき、次いで、全てのバッファ制御は、これに応じて変更されるべきである。
【００３３】
接続ステートマシンは、利用可能な帯域幅および送信すべきデータがある場合、リアルタイムトラフィックアービターＲＴＴＡに対するリクエストを生成する（リクエストステートマシン）。接続ステートマシンは、リアルタイムトラフィックアービターＲＴＴＡからの許可を処理する（許可処理ステートマシン）。接続ステートマシンは、リアルタイムトラフィックアービターＲＴＴＡからの許可に基づいて、接続バッファからのデータ送信を可能にする（許可処理ステートマシン）。接続ステートマシンは、バッファにスペースがある場合、接続バッファへの書き込みを可能にする（書き込みステートマシン）。接続ステートマシンは、送信イネーブルがあるたびに、ＢＷカウンタＢＷＣ（または追加のＢＷ向けの共通プールカウンタ）に対するデクリメントイネーブルを生成する（許可処理ステートマシン）。
【００３４】
接続処理ブロックユニットＣＰＢステートマシンは、３つのサブステートマシン、すなわちリクエスト生成ＲＧＳと、許可処理ＧＰＳと、書き込みステートマシンＷＳと、に分割される。リクエスト生成ステートマシンＲＧＳは、リアルタイムトラフィックアービターＲＴＴＡに対するリクエストを生成し、一方で、許可処理ステートマシンＧＰＳは、リアルタイムトラフィックアービターＲＴＴＡからの許可を処理する。リクエスト生成ステートマシンＲＧＳは、書き込みパケットポインタ（Ｗｒ＿ｐｋｔ）を通してバッファに書き込まれたパケットの数を追跡し、許可処理ステートマシンＧＰＳは、読み出しパケットポインタ（Ｒｄ＿ｐｋｔ）を通して読み出されたパケットを追跡する。これらのポインタは、パケット数を記憶する。個別の書き込みアドレスポインタ（Ｗｒ＿ａｄｄｒ）および読み出しアドレスポインタ（Ｒｄ＿ａｄｄｒ）を用いて、ＣＰＢバッファ内のバイトアドレスが指される。書き込みステートマシンは、ＵｎｉＰｒｏを用いたアプリケーションからのＣＰＢバッファへの書き込みを制御する。
【００３５】
図４は、本発明に係るバッファ書き込みステートマシンのフローチャートを示している。ここでは、接続処理ユニットにおいてバッファＣＰＢＢへの書き込みを制御するステートマシンが、示されている。ステートマシンは、書き込みがバッファにリクエストされるたびに、アイドル状態（Ｓ１０）から出る。まず、バッファ（ＣＰＢ＿ｂｕｆｆｅｒ＿ｆｕｌｌ）が満杯かどうかを調べるチェックが行われ（ステップＳ２０）、これが真である場合、接続は、バッファへの書き込みの一時停止を要請される（Ｓ３０）。ステートマシンは、この接続より前のリクエストに対して、許可が受信され、その結果、データがバッファから読み出されるまで待つ。バッファＣＰＢＢ内にデータを記憶するスペースがある場合、現在のパケットに書かれたバイトの数が、最大パケットサイズと等しいかどうか知るためのチェックが行われる（ステップＳ５０）。これに該当する場合、完全なパケットが再送信に利用可能である。書き込みバイトアドレスＷｒ＿ａｄｄｒを接続バッファＣＰＢＢと比べる間、係数演算を行うことにより、アドレスのラップアラウンドも計算に入れる。また、メッセージ終了（ＥｏＭ：End of Message）が生じる可能性もあり（ステップＳ６０）、これは、メッセージの最後のひとまとまりが、ＵｎｉＰｒｏで許容されるパケットの最大サイズよりも小さいことを意味し得る。また、ＵｎｉＰｒｏ内のメッセージが、最大パケットサイズよりも小さい場合、ＥｏＭが生成される。この条件は、最初の条件が真でない場合にチェックされる。これら２つの状態のうちのいずれかが真である場合、書き込みアドレスが、パケット終了アドレスとして、パケットサイズメモリに格納される。書き込みパケットポインタ（Ｗｒ＿ｐｋｔ）がインクリメントされて、次のパケットを指し、一方、バッファの書き込みアドレスポインタ（Ｗｒ＿ａｄｄｒ）がインクリメントされて、次の位置を指す（ステップＳ１００）。ステートマシンは、アイドル状態に戻り、新たな書き込みを待つ。
【００３６】
上述の実施は、パケットの送信に蓄積転送技術を用い、この技術では、パケットがまず完全に格納され、その後にのみ送信される。代わりに、いわゆるカットスルー実施においては、パケットの送信は、パケット内の最初のワードが受信されるとすぐに開始される。カットスルーは、パケット送信待ち時間が減少されるという利点を有する。
【００３７】
図５は、図１に係る接続処理ユニットにおける、本発明に係るリクエスト生成ステートマシンのフローチャートを示している。リクエスト生成ステートマシンは、可変ＣＰＢ＿ｂｕｆｆｅｒ＿ｅｍｐｔｙ（ステップＳ１１０）によって決定されるように、接続バッファにデータがあるたびにトリガされる。まず、書き込みおよび読み出しパケットポインタＷｒ＿ｐｋｔ＃，Ｒｄ＿ｐｋｔ＃を比較することにより、送信されるべき何らかのパケットがあるかどうかを調べるチェックが行われる（ステップＳ１２０）。リクエスト生成のケースがある場合、接続が、完全なフレームを送信するのに十分な帯域幅を有するかどうかを調べるチェックが行われる（ステップＳ１３０）。Ｌ２のヘッダおよびトレイラーのための帯域幅は、簡潔さのために省略されているが、帯域幅カウンタＢＷＣにおいて計上されている。帯域幅カウンタ値ＢＷ＿ｃｏｕｎｔｅｒ＿ｖａｌｕｅが、共通プールＡｄｄｉｔｉｏｎａｌ＿ＢＷから利用可能な帯域幅に加えられて、接続が利用可能な帯域幅が計算される。ここで、可能なＮＡＣ制御フレームの帯域幅が計上され、ＮＡＣ制御フレームは、この接続を先取することができ、共通プールからの帯域幅を共有する。利用可能な十分の帯域幅がある場合、リアルタイムトラフィックアービターＲＴＴＡに対するリクエスト信号が、アサートされる（ステップＳ１５０）。なければ、ステートマシンはアイドル状態に戻る。ひとたび、リクエスト信号がアサートされると、ステートマシンは、許可処理ステートマシンからパケット終了（End of Packet）信号を得るまで待機する。再び、それ以上のリクエストを行う必要があるかを調べるチェックが行われる。ある場合、ステップが反復される。ない場合、ステートマシンは、リクエスト信号を非アサートした後（Ｓ１４０）、アイドル状態に戻る（Ｓ１１０）。
【００３８】
図６は、図１の接続処理ユニットにおける許可処理ステートマシンのフローチャートを示している。接続処理ブロックユニットＣＰＢからのリクエスト後に、リアルタイムトラフィックアービターＲＴＴＡは、応答として最終的に許可を発行する。この許可は、ＣＰＢ許可処理ステートマシンをトリガする。いくつかの接続は、共通帯域幅プールから追加の帯域幅を借りることがあるため、接続が自身の帯域幅を使うのか、あるいは共通プールからの帯域幅を使うのかがチェックされる（ステップＳ２１０）。これは、帯域幅カウンタが負であるかをチェックすることによって行うことができ、負の帯域幅カウンタは、共通プールからの帯域幅を消費する必要があることを示す。リクエストを行う間、パケットの送信に利用可能な帯域幅があるかどうかが、既にチェックされている。帯域幅カウンタＢＷ＿ｃｏｕｎｔｅｒが負でない場合、帯域幅カウンタへのデクリメントイネーブルパルスが与えられ（Ｓ２５０）、一方でバイトが読み出される（Ｓ２６０）。次いで、このバイトが、読み出しパケットポインタによって指されたパケットの最後のバイトであったかを調べるチェックが行われる（ステップＳ２７０）。そうである場合、リアルタイムトラフィックアービターＲＴＴＡへのパケット終了（ＥｏＰ：End of Packet）パルスが生成される（ステップＳ２８０）。読み出しパケットポインタは、１だけインクリメントされ（Ｓ２９０）、ＣＰＢバッファへのリードアドレスポインタもインクリメントされる（Ｓ３００）。パケット終了に達していない場合、ＣＰＢバッファへの読み出しアドレスポインタのみが、インクリメントされる（ステップＳ３００）。
【００３９】
帯域幅カウンタが負である場合、いくつかの追加ステップが必要となる。まず（ステップＳ２２０）、リクエスト生成ステートマシンにて行われたものと同様の、完全なパケットのために十分な帯域幅が利用可能かどうかを調べるチェックが再び行われる。このチェックは、この接続が、リクエストを行う間に他の（より優先度の高い）接続と同時に、共通プールに残った帯域幅に入札する可能性があるため、必要とされる。より優先度の高い接続は、調停を勝ち取り、帯域幅を使い果たしているはずであり、送信のための十分な帯域幅を残さない。リアルタイムトラフィックアービターＲＴＴＡは、調停を行う間、帯域幅を調べない。代わりに、チェックは、接続処理モジュールユニットＣＰＭによって行われる。よって、共通プール帯域幅が消費され、パケット送信を進める前に、帯域幅チェックが再び行われる場合である（ステップＳ２２０）。利用可能な帯域幅がある場合、共通プールカウンタへのデクリメントイネーブルがパルスされ（Ｓ２４０）、ステートマシンは、負でない帯域幅カウンタのケースでのステップの実行に進む。十分な帯域幅が残っていない場合、読み出しパケットおよび読み出しアドレスポインタをインクリメントすることなく、ＥｏＰがシグナルされ、ステートマシンは、アイドル状態に戻る。このＥｏＰは、ＲＴＴＡをトリガして、他の接続からのリクエストの調停を助ける。
【００４０】
再送信処理ユニットＲＰＭは、ソフトリアルタイムトラフィックの再送信を制御する機能を果たす。再送信処理ユニットは、再送信ステートマシンＲＰＭＳと、再送信バッファＲＰＭＢとを備える。接続処理ブロックユニットＣＰＢと同様に、フレーム境界を記憶するメモリが提供され、このメモリを用いて、フレーム終了インジケータが生成される。ＣＰＢとは異なり、専用の帯域幅カウンタおよびいずれのレジスタも存在しない。このブロックの機能は、接続処理ブロックユニットＣＰＢと同様である。
【００４１】
再送信バッファＲＰＭＢは、Ｌ２フレーム処理ユニットＬ２ＦＰが、必要なＬ２ヘッダおよびトレイラーをＳＲＴパケットに加えた後に、データを受信する。再送信バッファは、全てのソフトリアルタイムフレームを、最初にこれらが送信されたのと同じ順番で記憶する。再送信バッファは、書き込みフレームポインタと、再送信フレームポインタとを有する。送信されるソフトリアルタイムカテゴリに属するどのフレームも、ＵｎｉＰｒｏにおけるTraffic Class-1およびTraffic Class-0で搬送されるものと同様のフレームシーケンス番号を有する。ポインタは、常にフレームシーケンス番号を指す。小型のメモリが設けられ、このメモリは、フレームシーケンス番号と、フレームのエンドバイトアドレスとを記憶する。これは、可変長フレームへの書き込みを可能にする。フレームの一部が上書きされた場合、ポインタは、次のフレームシーケンス番号までジャンプする。書き込みフレームポインタは、新たなフレームがリプレイバッファに書き込まれるたびに、フレームシーケンス番号によってインクリメントされ、これは、フレームの最初の送信と並行して生じる。書き込みフレームポインタがロールオーバーし、再送信フレームポインタに追いつくたびに、ポインタは、書き込みポインタを追跡する必要があり、そうでなければ、肯定応答されていないバッファにおける最も古いフレームを指していない可能性がある。よって、再送信フレームポインタは、書き込みフレームポインタがそれに追いつく場合（しばらくＮＡＣがなかった場合に生じやすい状況）か、ＮＡＣが受信される場合のどちらかで更新される。後述される再送信ステートマシンは、再送信バッファと再送信処理ブロックの機能について、より明らかにする。
【００４２】
再送信ステートマシンＲＰＭＳは、ＮＡＣフレームが受信され、再送信のケースがあるたびに、リアルタイムトラフィックアービターＲＴＴＡに対するリクエストを生成する。再送信ステートマシンは、リアルタイムトラフィックアービターＲＴＴＡからの許可を処理し、許可が利用可能になると、再送信バッファから読み出されたデータをイネーブルする。再送信ステートマシンは、ソフトリアルタイムトラフィックが最初に送信された際に、データフレームを格納し、データが送信されている際に、共通プールカウンタへのデクリメントインジケータを生成し、データが上書きされるたびに、バッファの再送信ポインタを調整する。
【００４３】
このステートマシンも、３つのサブステートマシンに分割される。一方のステートマシンは、ＲＴＴＡに対するリクエストを生成し、他方のステートマシンは、ＲＴＴＡからの許可を処理する。再送信フレームポインタは更新され、これは、バッファ内で上書きが起こるたびに、第３のステートマシンによって行われる。
【００４４】
図７は、図１に係る再送信処理ユニットにおけるリクエスト生成のフローチャートを示している。特に、再送信処理ユニットでのリクエスト生成のステートマシンが、表されている。ステートマシンのポインタは、フレームシーケンス番号を指し、書き込みフレームポインタ（ＲｅＴｘ＿Ｂｕｆ＿Ｗｒ＿ｆｒａｍｅ＃）が、最近送信されたソフトリアルタイムＳＲＴフレーム向けの値を保持し、再送信フレームポインタ（ＲｅＴｘ＿ｆｒａｍｅ＃）が、次に再送信する必要があるフレームのシーケンス番号を保持している。ＮＡＣフレームが受信されるたびに、このステートマシンがトリガされる。最初に、ＮＡＣフレームで搬送されるシーケンス番号がチェックされ（ステップＳ３２０）、フレームが最新かどうかが調べられる。このシーケンス番号が、再送信ポインタと書き込みポインタの間にはないか、またはこれらのポインタに等しい場合、これは、フレームが、使われなくなったシーケンス番号を含み、無視されることを意味する（Ｓ３４０）。そうでなければ、再送信ポインタは更新されて、ＮＡＣによって肯定応答された番号の後で次のシーケンス番号を指す（Ｓ３３０）。モジュロ演算が行われて、ポインタがラップアラウンドするケースを計算に入れ、これにより比較が正しい結果を生じるようにする（ステップＳ３２０において）。ひとたび、再送信ポインタが更新されると、書き込みフレームポインタが再送信フレームポインタより大きいかどうかを比較することによって（Ｓ３５０）、再送信のケースがあるかどうかがチェックされる。比較を行う間、ポインタのラップアラウンドに対処するよう注意する必要がある。再送信するフレームがない場合、ステートマシンは、リクエストを非アサートし（Ｓ３７０）、アイドル状態に戻る（ステップＳ３１０）。ある場合、再送信バッファの読み出しアドレスポインタ（Ｒｄ＿ａｄｄｒ＿ＲｅＴｘ＿Ｂｕｆ）は、肯定応答されたフレームがスキップされると更新される（Ｓ３６０）。次いで、再送信フレームポインタによって現在指されているフレームの送信に十分な帯域幅が、共通プールで利用可能であるかどうかがチェックされる（Ｓ３８０）。ＮＡＣフレームは、この再送信を先取できるため、帯域幅を計算する間、これについても計上する必要がある。帯域幅が利用可能である場合、ＲＴＴＡへの再送信リクエストがアサートされ（Ｓ３９０）、次いで、図８に示されるＲＰＭ許可処理ステートマシンからフレーム終了（ＥｏＦ：End of Frame）が受信されるまで待つ（Ｓ４００）。ひとたび、ＥｏＦが受信されると、再送信フレームポインタをインクリメントし（ステップＳ４１０）、テストを繰り返して（Ｓ３５０）リプレイされるべきフレームがそれ以上あるかどうかが決定される。フレームがある場合、上述のステップが再び繰り返される。再送信されるべきいずれかのフレームが、帯域幅を使い果たしている場合、再送信は中止され、再送信リクエストを非アサートした後、ステートマシンはアイドル状態に戻る（Ｓ３１０）。
【００４５】
図８は、図１に係る再送信処理ユニットにおける許可処理のフローチャートを示している。アービターＲＴＴＡから許可が受信されるたびに、ステートマシンがトリガされる（ステップＳ５００）。このフレームを再送信するために十分な帯域幅があるので、デクリメントイネーブルが、共通プールカウンタに与えられる（Ｓ５１０）。同時に、データがバッファから読み出される（ステップＳ５２０）。次いで、読み出されたバイトがフレームの最後のバイトだったかを調べるチェックが行われる（ステップＳ５３０）。そうであった場合、ステートマシンは、フレーム終了インジケータを、ＲＰＭリクエスト処理ステートマシンおよびアービターＲＴＴＡに対して生成する（ステップＳ５４０）。次いで、再送信バッファに対する読み出しアドレスポインタをインクリメントした後、アイドル状態に戻る（ステップＳ５５０）。フレームの最後のバイトのテストが失敗した場合、ステートマシンは、ＥｏＦパルス生成をスキップする。読み出しアドレスポインタのみが、次の場所を指すためにインクリメントされて、ステートマシンは、アイドル状態に戻る。
【００４６】
図９は、図１に係る再送信処理ユニットにおける再送信バッファ上書き処理方法のフローチャートを示している。このステートマシンにより提供される機能は、再送信バッファが満たされるのに十分長い期間、ＮＡＣフレームが得られない場合があり得るため、必要とされる。この場合、この方式は、エラーがなかったとみなし、バッファのデータの上書きに進む。ソフトリアルタイムトラフィックＳＲＴフレームおよび再送信されたフレームの送信は、相互に排他的である。このステートマシンは、再送信が行われている場合は機能しない。
【００４７】
ステートマシンは、アービターＲＴＴＡからのＳＲＴ許可があるたびに、アイドル状態から出る（ステップＳ６００）。いずれかのＳＲＴ接続によって、許可が受信されると、そのＣＰＢバッファからのデータ読み出しが開始される。バッファからのこのパケットは、Ｌ２ＦＰＭによるＬ２処理の後に、リンク上で送信され、また、ＲｅＴｘバッファに格納される。まず、再送信バッファ（ＲｅＴｘ＿ＢＵＦ＿Ｗｒ＿ｆｒａｍｅ＃）の書き込みフレームポインタが、次に再送信されるべきフレームを指しているかどうかを調べるテストが行われ、ｆｒａｍｅ＃ロールオーバーフラグが設定される（ステップＳ６１０）。ｆｒａｍｅ＃ロールオーバーフラグは、書き込みフレームポインタがラップアラウンドする場合にセットされ、再送信フレームポインタがラップアラウンドする場合にリセットされる。この条件が真である場合、部分的なフレームが再送信されないように、再送信フレーム番号ポインタ（ＲｅＴｘ＿ｆｒａｍｅ＃）がインクリメントされる（Ｓ６２０）。
【００４８】
テストが失敗した場合、ＣＰＢバッファから送られているフレームの最後のバイトかどうかのチェックが必要となる（Ｓ６３０）。この場合、現在格納されているフレームの終了アドレスが、フレーム番号アドレスメモリに格納される（ステップＳ６４０）。次いで、書き込みフレーム番号ポインタ（ＲｅＴx＿ＢＵＦ＿Ｗｒ＿ｆｒａｍｅ＃）がインクリメントされ（Ｓ６５０）、次いで、再送信バッファでのバイトの書き込みに進む（ステップＳ６６０）。最後に、再送信バッファ書き込みアドレスポインタが、インクリメントされ（ステップＳ６７０）、ステートマシンはアイドル状態に戻る。現在のバイトがフレームの終わりではない場合、書き込みフレーム番号ポインタを更新する必要がなく、また、フレームのエンドアドレスを格納するステップがスキップされる。
【００４９】
リアルタイムトラフィックアービターＲＴＴＡは、この方式全体の主ブロックであり、異なるトラフィックカテゴリからのリクエスト間の調停を行うステートマシンＲＴＴＡＳＭと、カテゴリおよび共通プールカウンタ内の接続のリクエスト競合解決および許可配信を行うユニットＳＲＣＲ，ＨＲＣＲと、を備える。このユニットは、また、定期的な帯域幅更新も制御する。
【００５０】
アービターＲＴＴＡステートマシンは、データの送信を望む様々なトラフィックカテゴリからのリクエスト間の調停を行い、それらの優先度に基づくトラフィックカテゴリへの許可を生成する。接続に対して許可が発行されるたびに、ステートマシンは、リアルタイムトラフィックの送信のための、Ｌ２静的優先度アービターへのリクエストを行い、より低い優先度のトラフィックカテゴリからのリクエストを先取して、より高い優先度のリクエストに対応し、同じ優先度レベルからの他のリクエストが処理される前に、先取された接続に対応する。
【００５１】
図１０は、図１のリアルタイムトラフィックアービターのステートマシンのフローチャートを示している。特定のカテゴリからのリクエスト信号は、このカテゴリに属する接続のいずれか１つがアサートされると、アサートされる。例えば、ＨＲＴ＿ｒｅｑは、ハードリアルタイムトラフィック接続の少なくとも１つがリクエストを有する場合にアクティブに設定され、そして、パケット終了が受信され、かつハードリアルタイムカテゴリからのさらなるリクエストがない場合に、非アクティブ化される。これは、他の２つのカテゴリでのケースである。アービターは、一時停止信号がアサートされているか、またはどのトラフィックカテゴリからもリクエストがない限り、アイドル状態に留まる（ステップＳ７００）。ひとたび、いずれかのトラフィックカテゴリでのリクエストを受け、かつ一時停止信号がない場合、アービターはアイドル状態から出る。まず、アービターは、ハードリアルタイムリクエストについてチェックするが（ステップＳ７１０）、それは、このリクエストが、一時停止の後の最高の優先度を有するからである。このリクエストが、アイドル状態から出た理由であると判明した場合、アービターは、ＨＲＴへの許可をアサートする（ステップＳ７５０）。アービターＲＴＴＡは、一時停止信号が到着するまで、またはパケット終了に達するまで、この状態を続ける（ステップＳ７６０）。許可がアクティブである間に一時停止が受信されると、アービターは許可を非アサートし、アイドル状態に移行する（ステップＳ７６０）。一時停止が非アサートされた後、ＨＲＴ＿ｒｅｑはまだアサートされているため、アービターはＨＲＴ許可発行状態に戻り、ＨＲＴトラフィックへの許可をアサートする。パケット終了に達すると、アービターは、アイドル状態に戻り、新たなリクエストを待つ。より高いカテゴリが許可される間、より低いトラフィックカテゴリーからのリクエストが到着すると、このリクエストは格納され、より高い優先度のリクエストが対応された後に取り上げられる。
【００５２】
アイドル状態から出た理由が、ＨＲＴリクエストでない場合（ステップＳ７１０）、アービターは、その理由が再送信リクエストであるかをチェックする（ステップＳ７２０）。これが真であると判明した場合、再送信トラフィックカテゴリに対して許可が与えられる（ステップＳ７７０）。ＨＲＴ許可状態と同様に、一時停止またはフレーム終了が発生すると、アービターはこの状態から出る（ステップＳ７８０）。ここで、追加の条件はＨＲＴリクエストであり、これは、再送信トラフィックより上の優先度を有する。
【００５３】
アイドル状態から出た理由が、ＨＲＴまたは再送信トラフィックのどちらでもない場合、その理由はソフトリアルタイムトラフィックＳＲＴリクエストであり、よって、このカテゴリに許可が与えられる（ステップＳ７３０）。アービターがこの状態を出るケースは、再送信許可状態を出るケースと同様である。再送信は、ＳＲＴトラフィックリクエストよりも高い優先度を有するが、ＳＲＴリクエストは、再送信リクエストによって先取することができず、現在のＳＲＴリクエストが終わるまで待つ必要がある。最後に、許可が接続に対して発行されるたびに、リアルタイムトラフィックフレーム送信リクエストが、Ｌ２静的優先度アービターに対して与えられる。
【００５４】
現在の調停方式では、ＨＲＴトラフィックを、制御フレームによって先取することが許されている（Ｌ２静的アービターブロックからの一時停止信号を使用）。しかし、ジッタ要件が非常に厳しい場合は、条件から一時停止信号を除いてＨＲＴ許可状態から出ることにより、この先取をなくすことができる。これは、Ｌ２静的優先度アービターにおける修正も要求する。
【００５５】
図１１は、図１のリクエスト競合解決および許可配信ユニットを示している。このユニットは、特にハードリアルタイムトラフィック用に使用されている。いくつかの接続は、ｒｅｑ＿ｃｏｎｎ＃１すなわち接続＃１からのリクエスト信号、接続＃ｎからのパケット終了インジケータＥｏＰ＿ｉｎｄ＿ｃｏｎｎ＃Ｎ、アービターステートマシンによりアサートされた許可信号ｇｒａｎｔ＿ＨＲＴ、および許可として接続＃ｎに与えられた、アービターステートマシンによりアサートされた許可信号ｇｒａｎｔ＿ｃｏｎｎ＃ｎ、のようなハードリアルタイムトラフィックカテゴリに属することができ、これらはアービターによって選択可能である。これらの信号は、ハードリアルタイムトラフィッのリクエストＨＲＴ＿ｒｅｑを出力するゲートＧにおいて組み合わせることができる。リクエストは、競合解決メモリＣＲＭにも入力され、このメモリは、選択信号を許可配信ユニットＧＤに対して出力し、このユニットは、許可信号ｇｒａｎｔ＿ＨＲＴも受信し、接続のそれぞれに許可を出力する。
【００５６】
個別のＨＲＴ接続からのリクエストは、到着するたびに「リクエスト中（request pending）」ラッチにラッチされる。接続のリクエストは、この特定の接続からパケット終了インジケータが受信されると消去される。パイプライン内に、この接続からの待機中のさらなるリクエストがある場合、この「リクエスト中」ラッチは、リセットされない。これらのラッチからの出力が、調停メモリＣＲＭに対してアドレスラインとして供給される。このアドレスによって指されるメモリ位置に、リンク帯域幅を勝ち取った接続番号が格納される。この接続番号を用いて、アービターＲＴＴＡステートマシンによってＨＲＴカテゴリに与えられた許可が逆多重化される。各接続のリクエスト信号をメモリ位置へのアドレスとして、異なる接続間の競合の勝者をメモリに記憶するこの方法は、接続が固定の優先度と関連しないという利点を有する。例えば、より新しい接続（ｃｏｎｎ＿３）を、既存の接続（ｃｏｎｎ＿１＆ｃｏｎｎ＿２）よりも高い優先度で依頼することができ、その接続番号は、新しい可能なメモリ位置（アドレス＝０ｂ１ＸＸ）に格納することができる。この接続がアクティブでなければ、この特定のメモリ位置は、有効とはならない（リクエスト信号＝’０’は、有効アドレスが０ｂ０ＸＸであることを示す）。この機能は、接続とその優先度が静的にマッピングされないため、従来技術より新規性がある。新たな接続が依頼（または廃止）された際にメモリを構成することによって、既存の接続よりも高い、または低い優先度を、新たな接続と関連付けることができる。この方法は、セットアップされる新たな接続に対して異なる優先度（より高い、低い、または対等の優先度）を割り当てる柔軟性を提供する。同様のサブモジュールが、ソフトリアルタイムトラフィックカテゴリーについても存在する。
【００５７】
アービターＲＴＴＡは、また、共通プールカウンタＣＰＣも含む。このカウンタは、定期的に更新され、最小の帯域幅よりも上の制御、再送信、またはＶＢＲ−ｒｔトラフィックが送信されるたびに、デクリメントされる。共通プールカウンタのデクリメントイネーブルは、これらの接続からの独立デクリメントイネーブルの論理和である。接続からのデクリメントイネーブルは、制御トラフィックおよびその他の接続から同時のイネーブルがあるケースに対処するために、ラッチされる。
【００５８】
図１２は、本発明に係る共通プールカウント方法のフローチャートを示している。ステートマシンは、デクリメントイネーブルｄｅｃ＿ｅｎ＿ＣＰ＿ｃｏｕｎｔｅｒまたは帯域幅更新信号ＢＷ＿ｕｐｄａｔｅのどちらかが受信されるとトリガされる（ステップＳ９００）。帯域幅更新信号は、ＣＰＢ内の帯域幅カウンタに与えられた信号と同じであり、カウンタに新しい帯域幅をロードするための定期的な指示である。初期チェックは、帯域幅更新信号が、ステートマシンをアイドル状態から出させたかを調べるためのものである。これが真であると判明した場合、共通プールカウンタに、共通プール帯域幅レジスタの値がロードされ、ステートマシンはアイドル状態に戻る（ステップＳ９２０）。同時のデクリメントイネーブルがあったとしても、このイネーブルは、前の期間の共通プール帯域幅に属している。その理由は、いずれかのトラフィックカテゴリによってリクエストが行われるたびに、フレーム全体を送信するのに十分な帯域幅を有するかをチェックするためである。ステートマシンをアイドル状態から出させたのが、帯域幅更新信号でなかった場合、それはデクリメントイネーブルでしかあり得ない。共通プールカウンタは、１だけデクリメントされて（ステップＳ９３０）バイトを計上し、ステートマシンはアイドル状態に戻る。
【００５９】
接続が、アービターＲＴＴＡにリクエストを行う前に、共通プールから利用可能な帯域幅を調べるので、共通プールカウンタステートマシンは、残っている帯域幅を探さない。
【００６０】
Ｌ２静的優先度アービターＬ２ＳＰＡは、リアルタイムが後に続き、ＵｎｉＰｒｏのトラフィッククラス１および０が後に続く、最高の優先度を有する制御フレームによる静的優先度を実施する。このアービターは、「一時停止」信号をアサートすることによって、より高い優先度のトラフィックを送信している際に、アービターＲＴＴＡと通信する。この信号は、ＰＨＹ再初期化を検知した場合にも、アサートされる。「一時停止」信号は、前の条件の両方が欠けている場合、非アサートされる。各トラフィッククラスモジュールおよび制御フレーム生成モジュールは、このブロックに対するリクエストを発行しなければならず、受信されたリクエストの優先度に基づいて、このブロックが「許可」を発行する。リアルタイムトラフィックは、全てのデータトラフィックの中で最高の優先度を有するので、Ｌ２アービターからのどの許可も探さない。制御トラフィックがあれば、一時停止を得、なければ、リンク帯域幅を勝ち取ることが想定されている。このブロックは、また、ＣＰＭまたはＲＰＭが、一時停止信号に反応する前に、これらによって既に送信されているデータを保持する小型のバッファを有する。このブロックは、また、ＵｎｉＰｒｏ規格に従う制御フレームからの先取の後に、フレームの継続を示す必要な符号も加える。
【００６１】
Ｌ２フレーム処理モジュール（Ｌ２ＦＰＭ）は、ＵｎｉＰｒｏ規格で述べられているフレームフォーマットに従って、データリンク層ヘッダおよびトレイラーを加える機能を実行する。全てのソフトリアルタイム接続トラフィックは、それらが送信される際に割り当てられるフレームシーケンス番号を得る。
【００６２】
上述の実施形態において、本発明の原理は、ＵｎｉＰｒｏプロトコルに基づき実施することができる。しかし、本発明の原理は、他のプロトコルに基づいて実施することもできることに留意すべきである。
【００６３】
本発明は、エラーを有する相互接続において、第１および第２のトラフィッククラス（ＨＲＴ，ＳＲＴ）を備えるリアルタイムトラフィックのための保証型サービスを確実化するための方法に関し、この方法は、第１および／または第２のトラフィッククラス（ＨＲＴ，ＳＲＴ）のリアルタイムトラフィックを、送信器から受信器へ送信するステップと、受信器によって、リアルタイムトラフィックの送信中にエラーが生じたかどうかを検出し、エラーを送信器に報告するステップと、所定の期間内に、送信器が受信器からのエラー報告を受信した場合、第２のトラフィッククラス（ＳＲＴ）のリアルタイムトラフィックの少なくとも一部を、送信器によって再送信するステップと、を備える。第２のトラフィッククラス、すなわちソフトリアルタイムトラフィックＳＲＴは、制限された数の再送信を許可し、この数は、任意として、多くとも１回の再送信とすることもできる。リアルタイムトラフィックは、ベストエフォートトラフィック（ＡＦＣ，Ｔｃ−１，Ｔｃ−０）と組み合わせることができる。
【００６４】
相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する接続に基づく。あるいは、相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する接続に基づき、かつ可変ビットレートを備え、方法は、少なくとも１つの第１の帯域幅を、それぞれの第１の接続に関連付けるステップと、追加の少なくとも１つの第２の帯域幅を、必要に応じて少なくとも１つの第１の帯域幅に関連付け、および／または、第１の接続が第２のトラフィッククラス（ＳＲＴ）のトラフィックを備える場合、少なくとも１つの第１の接続の少なくとも一部の再送信のための、少なくとも１つの第３の帯域幅を供給し、第３のトラフィック（ＮＡＣ，Ｔｃ−１，Ｔｃ−０）のための帯域幅を供給するための、共通プール帯域幅ユニットを設けるステップと、を備える。トラフィックは、第１のトラフィッククラス（ＨＲＴ）としてのハードリアルタイムトラフィック、第２のトラフィッククラス（ＳＲＴ）としてのソフトリアルタイムトラフィック、制御トラフィック（ＮＡＣ）、および／またはベストエフォートトラフィックを備えてもよい。ベストエフォートトラフィック、制御トラフィック、第１のトラフィッククラス（ＨＲＴ）、第２クラスのトラフィックの再送信、および第２クラスのトラフィック（ＳＲＴ）は、それぞれ高い順に関連付けられた優先度を有する。ベストエフォートトラフィックは、最低の優先度を有する。より高い優先度のトラフィックは、より低い優先度のトラフィックを先取することができる。先取の数は制限可能であり、例えば、先取の数は多くとも１である。先取の数は、トラフィッククラスごとに制限されており、例えば、トラフィッククラスごとに制限された先取の数は、多くとも１つである。
【００６５】
本発明は、また、電子装置に関し、この装置は、第１および第２のトラフィッククラス（ＨＲＴ，ＳＲＴ）を備えるリアルタイムトラフィック通信に用いられる、エラーを有する相互接続と、エラー報告が受信された場合に、第２のトラフィッククラス（ＳＲＴ）のリアルタイムトラフィックの少なくとも一部の再送信を開始するための再送信処理ユニット（ＲＰＭ）と、第２のクラス（ＳＲＴ）のリアルタイムトラフィックの少なくとも一部の再送信の調停を行うためのリアルタイムトラフィックアービター（ＲＴＴＡ）と、を備える。アービターは、また、第１および第２のトラフィッククラスＨＲＴおよびＳＲＴの間の調停を行うこともできる。ソフトリアルタイムトラフィックＳＲＴは、制限された数の再送信、例えば多くとも１回の再送信、を可能にする。
【００６６】
本発明は、また、電子装置に関し、この装置は、第１および第２のトラフィッククラス（ＨＲＴ，ＳＲＴ）を備える、接続に基づくリアルタイムトラフィック通信のための相互接続と、接続を処理するための接続処理モジュールユニット（ＣＰＭ）と、送信中にエラーが生じた場合に、第２のトラフィッククラス（ＳＲＴ）のリアルタイムトラフィックの少なくとも一部の再送信を開始するための再送信処理ユニット（ＲＰＭ）と、第２のクラス（ＳＲＴ）のリアルタイムトラフィックの少なくとも一部の再送信の調停を行うためのリアルタイムトラフィックアービター（ＲＴＴＡ）と、を備える。アービターは、また、第１および第２のトラフィッククラスＨＲＴおよびＳＲＴの間の調停をおこなうこともできる。ソフトリアルタイムトラフィックＳＲＴは、制限された数の再送信、例えば多くとも１回の再送信、を可能にする。第１（ＨＲＴ）および第２（ＳＲＴ）のトラフィッククラスのそれぞれのために、リアルタイムトラフィックアービター（ＲＴＴＡ）は、競合解決および許可配信ユニット（それぞれＨＲＣＲおよびＳＲＣＲ）を備え、このユニットを用いて、第１および第２のトラフィッククラスにそれぞれ属する接続からのリクエストの間の競合が解決され、競合の勝者への許可が配信される。ユニットは、トラフィッククラスに属する全ての接続からのリクエストを連結することによって生成されたインデックスのテーブルを用いて、トラフィッククラス内で調停を行う。ユニットは、テーブル内のインデックス付けされた位置にある予め設定された値を用いて、競合するリクエストの勝者を選択することができる。この値は、接続がセットアップされる際に設定される。ユニットは、さらに、未解決であった全ての競合するより低い優先度の接続が処理されるまでの期間にわたって、インデックス作成において勝利した接続からのさらなるリクエストを抑制することができる。
【００６７】
上述の実施形態は、本発明を限定ではなく例示していること、および当業者は、添付の特許請求の範囲から逸脱することなく、多くの代わりの実施形態を設計可能であることに留意すべきである。各請求項において、括弧内に置かれる参照符号はどれも、請求項を限定するものと解釈されるべきでない。“備える”という語は、請求項に記載のもの以外の要素またはステップの存在を除外しない。要素に先行する“１つの（”a” or “an”）”という語は、このような要素の複数の存在を除外しない。いくつかの手段を列挙する装置請求項において、これらの手段のいくつかを、同一のハードウェアのアイテムで具体化することもできる。特定の手段が、互いに異なる従属請求項において述べられているという単なる事実は、これらの手段の組合せを有利に使用することができないということを示すものではない。
【００６８】
さらに、特許請求の範囲におけるどの参照符号も、特許請求の範囲を限定するものと解釈されるべきではない。
【図１】
2010529800.tif 000003
【図２】
2010529800.tif 000004
【図３】
2010529800.tif 000005
【図４】
2010529800.tif 000006
【図５】
2010529800.tif 000007
【図６】
2010529800.tif 000008
【図７】
2010529800.tif 000009
【図８】
2010529800.tif 000010
【図９】
2010529800.tif 000011
【図１０】
2010529800.tif 000012
【図１１】
2010529800.tif 000013
【図１２】
2010529800.tif 000014
【手続補正書】
【提出日】平成22年2月17日(2010.2.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
エラーを有する相互接続において、第１および第２のトラフィッククラスを備えるリアルタイムトラフィックのための保証型サービスを確実化するための方法であって、
前記第１および／または第２のトラフィッククラスのリアルタイムトラフィックを、送信器から受信器へ送信するステップと、
前記受信器により、前記リアルタイムトラフィックの送信中にエラーが生じたかどうかを検出し、エラーを前記送信器に報告するとともに、再送信を待つことなく、エラーが生じたかどうかに拘わらず、前記第１のトラフィッククラスのリアルタイムトラフィックを転送するステップと、
所定の期間内に、前記送信器が前記受信器からのエラー報告を受信した場合、前記第２のトラフィッククラスのリアルタイムトラフィックの少なくとも一部を、前記送信器によって再送信するステップと、
を備えることを特徴とする方法。
【請求項２】
前記相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する複数の接続に基づく、ことを特徴とする請求項１に記載の方法。
【請求項３】
前記相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する複数の接続に基づき、かつ可変ビットレートを備え、前記方法は、
少なくとも１つの第１の帯域幅を、複数の前記接続のそれぞれに関連付けるステップと、
追加の少なくとも１つの第２の帯域幅を、必要に応じて前記少なくとも１つの第１の帯域幅に関連付け、および／または、複数の前記接続の少なくとも１つの接続が前記第２のトラフィッククラスのトラフィックを備える場合、前記少なくとも１つの前記接続の少なくとも一部の再送信のための、少なくとも１つの第３の帯域幅を供給するとともに、第３のトラフィックのための帯域幅を供給するための、共通プール帯域幅ユニットを提供するステップと、
を備えることを特徴とする請求項１または請求項２に記載の方法。
【請求項４】
前記トラフィックは、第１のトラフィッククラスとしてのハードリアルタイムトラフィック、第２のトラフィッククラスとしてのソフトリアルタイムトラフィック、制御トラフィック、および／または、ベストエフォートトラフィックを備え、
前記制御トラフィック、前記第１のトラフィッククラス、第２クラスのトラフィックの再送信、第２クラスのトラフィック、および、前記ベストエフォートトラフィックは、それぞれ、これらを高い順に関連付ける優先度を有する、ことを特徴とする請求項１、請求項２または請求項３に記載の方法。
【請求項５】
第１および第２のトラフィッククラスを備えるリアルタイムトラフィック通信のための、エラーが発生し得る相互接続であって、前記第１のトラフィッククラスのトラフィックについては、当該相互接続上の再送信を待つことなく、当該相互接続でエラーが生じたかどうかに拘わらず、当該相互接続からトラフィックが転送される、相互接続と、
エラー報告が受信された場合に、前記第２のトラフィッククラスのリアルタイムトラフィックの少なくとも一部の再送信を開始するための再送信処理ユニットと、
前記第２のクラスのリアルタイムトラフィックの少なくとも一部の再送信の調停を行うためのリアルタイムトラフィックアービターと、
を備えることを特徴とする電子装置。
【請求項６】
前記リアルタイムトラフィックアービターは、追加の第２の帯域幅を、必要に応じて前記第１の帯域幅に関連付ける共通プール帯域幅カウンタを備えており、前記トラフィックの少なくとも一部が前記第２のトラフィッククラスのトラフィックを備える場合に前記トラフィックの少なくとも一部の再送信のための第３の帯域幅を供給し、第３のトラフィックのための帯域幅を供給する、ことを特徴とする請求項５に記載の電子装置。
【請求項７】
エラーを有する相互接続において、リアルタイムトラフィックのための保証型サービスを確実化するための方法であって、前記相互接続を介した通信は、それぞれが少なくとも保証された通信帯域幅を有する複数の接続に基づくものである、方法において、
第１の帯域幅を、それぞれの第１の接続に関連付けるステップと、
追加の第２の帯域幅を、必要に応じて前記第１の帯域幅に関連付け、１または複数の前記接続の少なくとも一部の再送信のための第３の帯域幅を供給し、および／または、第３のトラフィックのための帯域幅を供給するための、共通プール帯域幅ユニットを供給するステップと、を備えることを特徴とする方法。
【請求項８】
前記相互接続を介した通信は、可変ビットレートを備え、前記リアルタイムトラフィックは、第１および第２のトラフィッククラスを備え、
前記共通プール帯域幅ユニットは、前記１または複数の接続が前記第２のトラフィッククラスのトラフィックを備える場合、前記１または複数の接続の少なくとも一部の再送信のための第３の帯域幅を供給するように構成されている、ことを特徴とする請求項７に記載の方法。
【請求項９】
前記リアルタイムトラフィックは、第１および第２のトラフィッククラスを備えており、前記共通プール帯域幅ユニットに利用可能な帯域幅がある場合にのみ、前記第２のトラフィッククラスのトラフィックが再送信される、ことを特徴とする請求項７に記載の方法。
【請求項１０】
第１および第２のトラフィッククラスを備える、複数の接続に基づくリアルタイムトラフィック通信のための相互接続と、
前記接続を処理するための接続処理モジュールユニットと、
送信中にエラーが生じた場合に、前記第２のトラフィッククラスのリアルタイムトラフィックの少なくとも一部の再送信を開始するための再送信処理ユニットと、
前記第２のクラスのリアルタイムトラフィックの少なくとも一部の再送信の調停を行うためのリアルタイムトラフィックアービターと、を備え、
前記リアルタイムトラフィックアービターは、追加の第２の帯域幅を、必要に応じて前記第１の帯域幅に関連付けて、１または複数の前記接続が前記第２のトラフィッククラスのトラフィックを備える場合に１または複数の前記接続の少なくとも一部の再送信のための第３の帯域幅を供給し、第３のトラフィックのための帯域幅を供給するための共通プール帯域幅ユニットを、備えることを特徴とする電子装置。
【請求項１１】
前記再送信処理ユニットは、十分な帯域幅が共通プールで利用可能な場合にのみ、再送信のリクエストを、前記リアルタイムトラフィックアービターに送信する、ことを特徴とする請求項１０に記載の電子装置。
【請求項１２】
前記第１および第２のトラフィッククラスのそれぞれのために、前記リアルタイムトラフィックアービターは、競合解決および許可配信ユニットを備え、前記ユニットを用いて、前記第１および第２のトラフィッククラスにそれぞれ属する接続からのリクエストの間の競合が解決され、競合の勝者への許可が配信される、ことを特徴とする請求項９または請求項１０に記載の電子装置。
【国際調査報告】
2010529800.tif 000015
2010529800.tif 000016
2010529800.tif 000017