(57)【特許請求の範囲】
【請求項１】
複数の異なるデータリンクを管理する少なくとも１つの送信機、または、それぞれが少なくとも１つのデータリンクを管理する複数の送信機であって、該１つまたは複数の送信機が、スライディングウィンドウメモリ要求を送信し、前記データリンクが、ＡＲＱプロトコルに従ってＰＤＵを転送し、かつ、１組の所定のＱｏＳ優先度に属する各ＱｏＳ優先度に関連付けられる、少なくとも１つの送信機または複数の送信機と、
複数の前記データリンクを収容し、ＡＲＱ肯定応答メッセージまたはＡＲＱ−ＡＣＫメッセージを前記送信機に送信することによって、送信された各ＰＤＵに応答する少なくとも１つの受信機と、
前記データリンク間で共有されるメモリであって、前記受信機に備えられて、少なくとも受信されたＰＤＵの応答が行われるまで、該受信されたＰＤＵを記憶する、メモリと、
送信機ＡＲＱインスタンスと、前記１つまたは複数の送信機から前記スライディングウィンドウメモリ要求を受信する受信機ＡＲＱインスタンスとを備え、所定の１組の動作制御モードから選択された動作制御モードに従って前記データリンクのそれぞれを制御するＡＲＱ管理エンティティと、
を備えるネットワークにおける動的ＡＲＱウィンドウ管理方法であって、
前記ＡＲＱ管理エンティティが、所与の動作制御モードを選択するステップと、
前記１つの送信機または前記複数の送信機のうちの少なくとも１つが、所与のデータリンクの１つまたは２つ以上のＰＤＵを前記受信機に送信するステップと、
前記受信機が、前記受信されたＰＤＵを前記共有メモリに記憶するステップと、
前記受信機ＡＲＱインスタンスが、前記選択された動作制御モードおよび／またはフロー制御データを含んだ特定の情報を含む前記対応するＡＲＱ−ＡＣＫメッセージを返信するステップと、
前記受信機ＡＲＱインスタンスが、応答されたＰＤＵを上位層に配信すると、該応答されたＰＤＵを前記共有メモリから除去するステップと、
前記ＡＲＱ−ＡＣＫメッセージを受信すると、前記送信機ＡＲＱインスタンスが、該ＡＲＱ−ＡＣＫメッセージに含まれる前記特定の情報に基づいて、前記データリンクでのＰＤＵの送信の継続または停止を行うステップと、
を含み、
前記動作制御モードを選択するステップは、前記共有メモリ内の利用可能なメモリ空間、前記関連付けられた各ＱｏＳ優先度、および前記受信機によって受信された前記送信機からの前記スライディングウィンドウメモリ要求を考慮しながら、ＰＤＵ送信中にデータリンクごとに動的に繰り返され、
前記１組の所定の動作制御モードは、少なくとも、メモリ空間が所与のデータリンクに対して前記共有メモリに予約されない第１の動作制御モードと、所与のメモリ空間が所与のデータリンクに対して前記共有メモリに排他的に予約される第２の動作制御モードとを含む、動的ＡＲＱウィンドウ管理方法。
【請求項２】
前記第２の動作制御モードは、スライディングウィンドウメカニズムに基づく、請求項１に記載の動的ＡＲＱウィンドウ管理方法。
【請求項３】
前記フロー制御データは、
前記共有メモリの前記利用可能なメモリ空間が運用管理で設定された第１のしきい値よりも大きい場合には、前記フロー制御データは、前記データリンクについてＰＤＵの送信を継続するように前記各送信機ＡＲＱインスタンスに広告するステップと、
前記共有メモリの前記利用可能なメモリ空間が運用管理で設定された第１のしきい値よりも大きくない場合には、前記フロー制御データは、前記データリンクについてＰＤＵの送信を停止するように前記各送信機ＡＲＱインスタンスに広告するステップと、
に基づいて提供される、
請求項１または２に記載の動的ＡＲＱウィンドウ管理方法。
【請求項４】
前記ＰＤＵの送信を停止するステップの後に、
前記共有メモリの前記利用可能なメモリ空間が運用管理で設定された第２のしきい値よりも大きい場合には、前記受信機ＡＲＱインスタンスが、最後に正しく受信されたＰＤＵに関する情報を含むメッセージを送信することによって、前記送信機ＡＲＱインスタンスにＰＤＵの送信を継続するように広告するステップと、
前記送信機ＡＲＱインスタンスが、前記情報に基づいてＰＤＵの送信を継続するステップと、
をさらに含む、請求項３に記載の動的ＡＲＱウィンドウ管理方法。
【請求項５】
前記ＡＲＱ管理エンティティは、
前記送信機ＡＲＱインスタンスが、所与のデータリンクについて前記共有メモリの要求したメモリ空間を含んだメモリ予約要求メッセージを送信するステップと、
前記受信機ＡＲＱインスタンスが、前記所与のデータリンクについて、前記共有メモリの予約したメモリ空間に関するメモリ情報を含んだ対応する応答メッセージを返信するステップと、に従ってメモリ予約が行われると、前記第１の動作制御モードから前記第２の動作制御モードへ前記動作制御モードを切り換え、
前記受信機ＡＲＱインスタンスは、前記要求したメモリ空間と、前記所与のデータリンクの前記各ＱｏＳ優先度と、前記共有メモリの前記利用可能なメモリ空間とに応じて、前記予約したメモリ空間を決定する、請求項１ないし４のいずれか１項に記載の動的ＡＲＱウィンドウ管理方法。
【請求項６】
前記共有メモリにメモリ空間が利用可能でない場合には、前記受信機ＡＲＱインスタンスは、前記メモリ予約要求を拒否する、対応する応答メッセージを返信し、該応答メッセージは、現在予約されているメモリ空間に関する情報を含む、請求項５に記載の動的ＡＲＱウィンドウ管理方法。
【請求項７】
前記送信機ＡＲＱインスタンスは、前記共有メモリの新たに要求したメモリ空間を画定するメモリ予約要求をさらに送信することによって、前記予約したメモリ空間のサイズを変更するように要求する、請求項５または６に記載の動的ＡＲＱウィンドウ管理方法。
【請求項８】
前記利用可能なメモリ空間がメモリ予約を達成するのに十分でない場合には、前記受信機ＡＲＱインスタンスは、前記所与のデータリンクのＱｏＳ優先度よりも低いＱｏＳ優先度に関連付けられた低いＱｏＳのデータリンクに予約された前記メモリ空間を寄せ集め、
該寄せ集めたメモリ空間が前記要求したメモリ空間よりも大きい場合には、前記受信機ＡＲＱインスタンスは、前記低いＱｏＳのデータリンクに予約されたメモリ空間を先取りすることによって、前記要求したメモリ空間を前記所与のデータリンクに対して予約し、前記低いＱｏＳのデータリンクに、前記第２の動作制御モードから前記第１の動作制御モードへ切り換わるように強制し、
前記寄せ集めたメモリ空間が前記要求したメモリ空間よりも大きくない場合には、前記受信機ＡＲＱインスタンスは、現在予約されているメモリ空間に関する情報を含む、前記メモリ予約を拒否する対応する応答メッセージを返信する、
請求項５ないし７のいずれか１項に記載の動的ＡＲＱウィンドウ管理方法。
【請求項９】
前記送信機ＡＲＱインスタンスは、
メモリ予約要求が送信された時にタイマを始動するステップと、
前記メモリ予約要求メッセージに対応する応答メッセージの受信時に前記タイマをリセットするステップと、
前記タイマの満了時に前記メモリ予約要求メッセージを再び送信するステップと、
をさらに実行する、請求項５ないし８のいずれか１項に記載の動的ＡＲＱウィンドウ管理方法。
【請求項１０】
前記ＡＲＱエンティティは、メモリ予約要求に対応する応答メッセージであって、サイズが０に等しい予約したメモリ空間を含む応答メッセージの、前記受信機ＡＲＱインスタンスについては送信時に、前記送信機ＡＲＱインスタンスについては受信時に、それぞれ、前記第２の動作制御モードから前記第１の動作制御モードへ前記動作制御モードを切り換え、または、前記第１の動作制御モードを含むＡＲＱ−ＡＣＫメッセージの受信時に前記第２の動作制御モードから前記第１の動作制御モードへ前記動作制御モードを切り換える、請求項５ないし９のいずれか１項に記載の動的ＡＲＱウィンドウ管理方法。
【請求項１１】
前記第１の動作制御モードは、比較的低いＱｏＳ優先度に関連付けられたデータリンクに対して選択され、前記第２の動作制御モードは、比較的高いＱｏＳ優先度に関連付けられたデータリンクに対して選択される、請求項１ないし１０のいずれか１項に記載の動的ＡＲＱウィンドウ管理方法。
【請求項１２】
前記共有メモリにメモリ空間がもはや利用可能でない場合には、前記受信機ＡＲＱインスタンスは、データリンクのＰＤＵを廃棄する、請求項１ないし１１のいずれか１項に記載の動的ＡＲＱウィンドウ管理方法。
【請求項１３】
請求項１ないし１２のいずれか１項に記載の方法を実行する手段を備える、データリンク伝送を制御するデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、包括的には、通信ネットワークに関し、詳細には、ＡＲＱプロトコルに基づくネットワークにおける動的ＡＲＱウィンドウの管理に関する。
【背景技術】
【０００２】
本明細書では、いくつかの局（ＳＴＡ）およびノードを備えた通信ネットワークについて考える。ＳＴＡで実行されるアプリケーションが生成したデータは、各データフローにおいて、データリンクを介して交換される。各データフローは、所与の送信機、所与の受信機、所与のアプリケーションに対応する。所与のデータリンクを介して１つまたは２つ以上のデータフローを転送することができる。データリンクは、送信機ＳＴＡから受信機ＳＴＡへ確立され、中間ノードを通ることもあるし、通らないこともある。ＩＳＯ（「国際標準化機構」）によるネットワークプロトコル階層モデルを参照すると、データリンクは、リンク層（ＬＬ）プロトコルによって規定され、ＬＬプロトコルは、媒体アクセス制御サブ層（ＭＡＣ）を含む。ＬＬレベルでは、データは、ＭＡＣサブ層によって物理媒体に挿入されたり、物理媒体から抽出されたりするＬＬプロトコルデータユニット（ＬＬ−ＰＤＵ）で転送される。以下では、送信機ＳＴＡおよび受信機ＳＴＡを、それぞれ送信機および受信機と呼ぶことにする。
【０００３】
エラーが発生しやすい物理媒体（例えば、無線、電力ライン等）の場合、ＬＬ層は、ＬＬ−ＰＤＵが受けた伝送エラーの回復を担当するエラー制御（ＥＣ）メカニズムを含む。ＥＣメカニズムは、通常、受信機によって検出されるような喪失または破損したＬＬ−ＰＤＵを再送することに基づいている。このような再送方式を管理するプロトコルは、自動再送要求（ＡＲＱ）プロトコルとしても知られている。一般に、ＡＲＱインスタンスは、受信機および送信機の双方で実行される。さらに、受信機のＡＲＱインスタンスが、送信されたＬＬ−ＰＤＵの受信ステータスを送信機のＡＲＱインスタンスに通知できるように、逆方向のデータリンクがプロビジョニングされる。このＡＲＱプロトコル情報は、ＡＲＱフィードバックメッセージまたはＡＲＱ肯定応答（ＡＲＱ−ＡＣＫ）メッセージとも呼ばれる特定のシグナリングＬＬ−ＰＤＵで転送される。このタイプのプロトコルでは、先に送信されたＬＬ−ＰＤＵに対するＡＲＱ−ＡＣＫメッセージが正しく受信されている場合に限り、送信機は、所与のデータリンクを介して受信機にデータを送信することができる。その結果、送信機がＡＲＱ−ＡＣＫメッセージを待っている時、ＡＲＱ−ＡＣＫメッセージが受信されるまで、データ送信は阻止される。このデータ送信の阻止は、データリンク、さらには送信効率に影響を与える。送信阻止を回避することによって送信効率を改善するために、スライディングウィンドウメカニズムが一般に導入される。スライディングウィンドウは、送信機がＡＲＱ−ＡＣＫメッセージを受信していなくても送信できるＬＬ−ＰＤＵの個数を表す。このようなスライディングウィンドウのサイズは、２つの境界によって画定される。これら２つの境界は、一般にウィンドウボトム（ＢｏＷ（Bottom of Window））およびウィンドウトップ（ＴｏＷ（Tow of Window））と呼ばれる。プロトコルに応じて、スライディングウィンドウのサイズは、例えば、ヨーロッパ電気通信標準協会（ＥＴＳＩ）によって定義されたＨｉｐｅｒＬＡＮ／２標準規格と同様に固定することもできるし、例えば、伝送制御プロトコル（ＴＣＰ）と同様に可変とすることもできる。スライディングウィンドウのサイズが固定される場合、そのサイズは、データリンクの確立時に選ばれる。スライディングウィンドウのサイズが可変とされる場合、そのサイズは、受信機が送信したＡＲＱ−ＡＣＫメッセージを通じて送信機に広告される。この後者の場合、ＡＲＱ−ＡＣＫの受信によって、スライディングウィンドウの境界が更新される。データ送信中、送信機は、これらの境界に基づいて、対応するデータリンクを介したデータフローを制御する。換言すると、送信機は、ＡＲＱ−ＡＣＫを受信せずに送信するＬＬ−ＰＤＵの個数を制御することによって、ＬＬ−ＰＤＵの送信の停止、再開、または継続を行う。その結果、スライディングウィンドウは、エラーが発生していない場合であっても、データリンクスループットに不利に影響する可能性のあるフロー制御効果を有する。
【０００４】
受信機が、どのＰＤＵが正しく受信されていないかを、送信機に送信したＡＲＱ−ＡＣＫメッセージで示すことができるように、ＡＲＱプロトコルは、送信機および受信機に共通のＰＤＵの識別情報であって、プロトコルシグナリングによって使用されるＰＤＵの識別情報に依拠している。このデータユニット識別情報は、通常、データユニットに特有の連続番号であり、考慮されている層によってのみハンドリングされる。
【０００５】
他方、ＳＴＡで実行されるアプリケーションは、さまざまなサービス品質（ＱｏＳ）要件を有することができる。例えば、これらのＱｏＳ要件は、ビットレート（もしくは帯域幅）制約条件または伝送遅延制約条件の点から表すことができる。これらの制約条件を満たすことは、データリンクが必要とされる帯域幅および／または伝送遅延を提供するならば可能である。特に、帯域幅のプロビジョニングは、資源予約プロシージャを通じて実行することができる。資源予約が成功すると、それによって、必要とされるビットレートでアプリケーションデータフローを転送することが保証される。以下のセクションでは、より良く理解するために、ビットレートＱｏＳ要件のみを考える。
【０００６】
類似のＱｏＳ要件を有するいくつかのアプリケーションデータフローを転送するのに単一のデータリンクを使用することができる。したがって、データリンクのビットレートは、異なるアプリケーションデータフローのアクティビティに応じて、時間で変化し得る。
【０００７】
このセクションでは、このようなＡＲＱプロトコルの基本原理および定義を示す。すでに説明したように、スライディングウィンドウは、２つの境界およびそのサイズによって画定される。２つの境界はＴｏＷおよびＢｏＷであり、サイズはウィンドウサイズ（ＷＳ（Window Size））である。以下では、これら境界およびサイズを同じ単位で表す。この単位は、ＬＬ−ＰＤＵが例えばＨｉｐｅｒＬＡＮ／２と同様に固定サイズである場合にはＬＬ−ＰＤＵ番号（数？）とすることもできるし、ＴＣＰと同様にバイト数とすることもできる。
【０００８】
また、この単位は、各ＬＬ−ＰＤＵを識別するのに使用される連続番号空間を画定するのにも使用される。連続番号の範囲は、ＬＬ−ＰＤＵの番号付けにおいてあいまいさが生じないように、かつ、各ＬＬ−ＰＤＵを一意に識別できるように決定される。この場合、ＢｏＷおよびＴｏＷは、それぞれスライディングの下端および上端に位置するＬＬ−ＰＤＵの連続番号である。より良く理解するために以下では、ＬＬ−ＰＤＵ連続番号および対応するＬＬ−ＰＤＵは等価であるとみなす。
【０００９】
ＢｏＷは、受信機が検出する最も小さな連続番号の喪失または破損したＬＬ−ＰＤＵを指し、ＴｏＷは、以下の方程式によってＢｏＷから求められる。
ＴｏＷ＝ＢｏＷ＋ＷＳ−１
【００１０】
送信機は、ＢｏＷとＴｏＷとを含めて両者の間に含まれるどのＬＬ−ＰＤＵも送信または再送することができる。
【００１１】
ＢｏＷは、受信機によって更新され、ＡＲＱ−ＡＣＫメッセージで送信機に広告される。スライディングウィンドウのサイズが可変である場合には、ＷＳも、一般に、ＡＲＱ−ＡＣＫメッセージで広告されるのに対し、このサイズが固定である場合には、ＷＳはデータリンク確立時に選択される。
【００１２】
一般に、データリンクのラウンドトリップ時間（ＲＴＴ）は、送信機によるＬＬ−ＰＤＵの放出と、対応するＡＲＱ−ＡＣＫメッセージ、すなわち、放出されたＬＬ−ＰＤＵをカバーするＡＲＱ−ＡＣＫメッセージの受信との間の経過時間として定義される。ＲＴＴは、物理媒体による伝送遅延、および、送信機および受信機における処理だけでなく、さまざまな中間ノードにおける処理をも含む。
【００１３】
このタイプのプロトコルは、伝送エラーが発生するデータリンクに正確に適合される。逆に、伝送エラーのないデータリンクは、このようなプロトコルによって影響を受けることがある。
【００１４】
実際に、伝送エラーが発生しない場合、Ｂｍａｘと呼ばれる最大データリンクスループット、対応するＲＴＴ、およびＷＳは、以下の方程式によって結合される。
Ｂｍａｘ＝ＷＳ／ＲＴＴ
【００１５】
この関係は、以下の簡単化の仮定から推論することができる。
【００１６】
送信されたすべてのＬＬ−ＰＤＵは同じサイズを有し、ＡＲＱ−ＡＣＫメッセージの送信レートは、受信機から送信機への逆方向のデータリンクにおいて制限を受けない。換言すると、逆方向のデータリンクはＡＲＱ−ＡＣＫにトランスペアレントである。
【００１７】
送信機がＬＬ−ＰＤＵを一定のスループットＢで放出すると仮定すると、ＬＬ−ＰＤＵ間のタイムギャップはＴと呼ぶことができる。受信機は、ＬＬ−ＰＤＵを受信するごとに１つのＡＲＱ−ＡＣＫを放出する。送信機がこれまでに送信した最初のＬＬ−ＰＤＵがＢｏＷとみなされる場合、このＬＬ−ＰＤＵに応答するＡＲＱ−ＡＣＫメッセージはＲＴＴ後に受信される。スライディングウィンドウによって、送信機は、最初のＡＲＱ−ＡＣＫが受信されるまで、所与の個数ｎの他のＬＬ−ＰＤＵをさらに送信することが可能になる。ｎは、ＷＳよりも小さな整数である。以下の方程式が推論される。
ｎ＝Ｂ×ＲＴＴ
【００１８】
ＡＲＱ−ＡＣＫメッセージを受信することによって、送信機には、ＬＬ−ＰＤＵをさらに１つ送信する機会が与えられる。換言すると、ＢｏＷが進み、その結果、スライディングウィンドウが進む。後続のＡＲＱ−ＡＣＫメッセージがＴおきに受信され、したがって、それにより、新たなＬＬ−ＰＤＵをＴおきに送信することが可能になり、その結果、送信機は、Ｂに等しいスループットでＬＬ−ＰＤＵを放出し続ける。
【００１９】
したがって、スループットＢを達成するために、以下の関係を検証するようにＷＳの最小値を選択しなければならない。
ＷＳｍｉｎ＝Ｂ×ＲＴＴ
【００２０】
図１は、送信機１１、受信機１２、および所与のデータリンク１３を示している。データリンク１３は、Ｂと呼ばれるビットレートでデータフローを転送する。対応する逆方向データリンク１４によって、受信機１２から送信機１１へのＡＲＱ−ＡＣＫメッセージの送信が可能になる。送信機側では、１６で参照される送信待ち状態のＬＬ−ＰＤＵのキューが、ＬＬ−ＰＤＵ＃１１からＬＬ−ＰＤＵ＃１４までのＬＬ−ＰＤＵを含む。先行するＬＬ−ＰＤＵ＃１からＬＬ−ＰＤＵ＃１０までのＬＬ−ＰＤＵはすでに送信されている。さらに、ＬＬ−ＰＤＵ＃１からＬＬ−ＰＤＵ＃７までのＬＬ−ＰＤＵは、受信機側に受信されていると仮定し、それらＬＬ−ＰＤＵは、受信機がそれらの対応するＡＲＱ−ＡＣＫメッセージを送信するまで、１５で参照されるメモリバッファに記憶されると仮定する。受信機は、ＬＬ−ＰＤＵおよびＡＲＱ−ＡＣＫメッセージの処理に或る時間を費やすので、図示の例では、ＬＬ−ＰＤＵ＃１からＬＬ−ＰＤＵ＃３までのＬＬ−ＰＤＵに対応するＡＲＱ−ＡＣＫメッセージのみが処理されて、逆方向データリンク１４を介して送信されているとみなしている。時刻ｔで放出されたＬＬ−ＰＤＵに対応するＡＲＱ−ＡＣＫメッセージは、送信機側に時刻ｔ＋ＲＴＴで受信される。その結果、メモリバッファ１５は、多くともＲＴＴの時間の間に受信される個数のＬＬ−ＰＤＵを記憶可能でなければならない。図１に示す例では、データフローが、ＲＴＴの時間の間、所与のビットレートＢで送信されると、受信機は７個のＬＬ−ＰＤＵを記憶する。
【００２１】
エラーが発生しやすい伝送の場合、ＲＴＴの大部分が、受信機でのＬＬ−ＰＤＵおよびＡＲＱ−ＡＣＫの処理に費やされる可能性がある。その結果、受信機には、その時間の間に送信されたＬＬ−ＰＤＵを記憶できるだけ十分なメモリが設けられる。確かに、ＬＬ−ＰＤＵが正しく受信されなかったことを示すＡＲＱ−ＡＣＫが受信されると、ＬＬ−ＰＤＵが再送される。再送されたＬＬ−ＰＤＵのステータスをその後のＡＲＱ−ＡＣＫメッセージを通じて得るための経過時間のために、見掛けのＲＴＴはより長くなる。この場合、ＡＲＱ−ＡＣＫメッセージを待っている間、送信機の送信を阻止しない方が好ましい。その結果、再送による待ち時間の間、できるだけ多くの補償を行うために、より大きなスライディングウィンドウを設けることが好ましい。このため、厳しいＱｏＳ制約条件を示すいくつかのデータリンクに対しては、これらのデータリンクがエラーを受ける時であっても、これらの制約条件を保証できるように、大きな空間のメモリ資源が予約されることになる。
【００２２】
上記説明に関して、ＡＲＱプロトコルがメモリ予約に基づく場合には、所与のスループットが保証され、ＡＲＱプロトコルが予約のないメモリ使用に基づく場合には、スループットが保証されない。
【００２３】
その結果、異なるＱｏＳを有し、かつ、異なるスライディングウィンドウサイズ要件を有する異なるデータリンクに対しては、特に、これらのスライディングウィンドウサイズの要求がとりわけ伝送エラーに応じて可変であることから、効率的な動的ＡＲＱウィンドウ管理を適用することは困難である。
【発明の開示】
【発明が解決しようとする課題】
【００２４】
所与のデータリンク用のスライディングウィンドウの実施に使用されるメモリバッファは、一般に、共有メモリ資源において、同じ受信機で終端するすべてのデータリンク間で取得される限られた資源である。いくつかのアプリケーションは、基礎を成すデータリンクが満たさなければならない特定のスループット要件を有する。したがって、スライディングウィンドウのメモリバッファを管理して、共通資源を共有するすべてのデータリンクをできるだけうまく収容することが望ましい。上記に鑑み、異なるＱｏＳ制約条件を有する多くのタイプのアプリケーションに適合可能な動的ＡＲＱウィンドウ管理が必要とされている。
【課題を解決するための手段】
【００２５】
従って、本発明は第１の態様において、
複数の異なるデータリンクを管理する少なくとも１つの送信機、または、それぞれが少なくとも１つのデータリンクを管理する複数の送信機であって、当該１つまたは複数の送信機が、スライディングウィンドウメモリ要求を送信し、データリンクが、ＡＲＱプロトコルに従ってＰＤＵを転送し、かつ、１組の所定のＱｏＳ優先度に属する各ＱｏＳ優先度に関連付けられる、少なくとも１つの送信機または複数の送信機と、
複数の上記データリンクを収容し、ＡＲＱ肯定応答メッセージまたはＡＲＱ−ＡＣＫメッセージを上記送信機に送信することによって、送信された各ＰＤＵに応答する少なくとも１つの受信機と、
上記データリンク間で共有されるメモリであって、上記受信機に備えられて、少なくとも受信されたＰＤＵの応答が行われるまで、当該受信されたＰＤＵを記憶する、メモリと、
送信機ＡＲＱインスタンスと、上記１つまたは複数の送信機から上記スライディングウィンドウメモリ要求を受信する受信機ＡＲＱインスタンスとを備え、所定の１組の動作制御モードから選択された動作制御モードに従って上記データリンクのそれぞれを制御するＡＲＱ管理エンティティと、
を備えるネットワークにおける動的ＡＲＱウィンドウ管理方法を提案し、本方法は、
上記ＡＲＱ管理エンティティが、所与の動作制御モードを選択するステップと、
上記１つの送信機または上記複数の送信機のうちの少なくとも１つが、所与のデータリンクの１つまたは２つ以上のＰＤＵを上記受信機に送信するステップと、
上記受信機が、上記受信されたＰＤＵを上記共有メモリに記憶するステップと、
上記受信機ＡＲＱインスタンスが、上記選択された動作制御モードおよび／またはフロー制御データを含んだ特定の情報を含む上記対応するＡＲＱ−ＡＣＫメッセージを返信するステップと、
上記受信機ＡＲＱインスタンスが、応答されたＰＤＵを上位層に配信すると、当該応答されたＰＤＵを上記共有メモリから除去するステップと、
上記ＡＲＱ−ＡＣＫメッセージを受信すると、上記送信機ＡＲＱインスタンスが、当該ＡＲＱ−ＡＣＫメッセージに含まれる上記特定の情報に基づいて、上記データリンクでのＰＤＵの送信の継続または停止を行うステップと、
を含み、
上記動作制御モードを選択するステップは、上記共有メモリ内の利用可能なメモリ空間、上記関連付けられた各ＱｏＳ優先度、および上記受信機によって受信された上記送信機からの上記スライディングウィンドウメモリ要求を考慮しながら、ＰＤＵ送信中にデータリンクごとに動的に繰り返される。
【００２６】
本発明の第２の態様は、データフロー伝送を制御するデバイスに関し、本デバイスは、第１の態様による方法を実行する手段を備える。
【００２７】
本発明のさらなる特徴および利点は、以下の説明からより一層明らかになるであろう。以下の説明は、単に例示として与えられるものであり、添付図面と共に読まれるべきである。
【発明を実施するための最良の形態】
【００２８】
本発明の一実施の形態は、所定の１組の動作制御モードを定義して、これら動作制御モードの１つをいくつかの特定の特性に従って適用するＡＲＱウィンドウ管理方法を提案する。これらの特性は、所与のアプリケーションのＱｏＳ制約条件とすることができる。
【００２９】
送信機および受信機は、１組のデータリンクによってリンクされる。各データリンクは、所与のレベルのＱｏＳに対応する伝送特性を有する。この所与のレベルのＱｏＳは、ＰＤＵが各データリンクを介して転送されて与えられたアプリケーションに提供されるものである。これらの伝送特性は、トラフィッククラスに対応することができる。ＩＥＥＥ８０２．１Ｄ標準規格は、本明細書の以下に示す分類を提案している。
【００３０】
【表１】
0004728013.tif 000002
【００３１】
本明細書の上記に示したトラフィッククラスは、ＱｏＳレベルと等価であり、例えば、ＱｏＳレベルを、本発明の一実施の形態によって管理されるデータフローに関連付けるのに使用することができる。
【００３２】
送信機から受信機へ送信された所与のアプリケーションに対応するデータフローは、所与のアプリケーションのトラフィック要件またはＱｏＳ制約条件に対応するクラスのデータリンクにマッピングされる。本発明の一実施の形態に従って提案されたメカニズムの一実施態様は、これよりも少ないトラフィッククラスに依拠することもできるし、これよりも多いトラフィッククラスに依拠することもできることに留意すべきである。これらのトラフィッククラスは、他のトラフィック特性またはパラメータを使用して定義することができる。クラスは次のように識別される。すなわち、Ｃ１，Ｃ２，…，Ｃｎで識別される。Ｃ１は、Ｃ２よりも優先度が低く、以下同様である。クラスＣｎに属するデータリンクｋはＤＬｋ（Ｃｎ）と呼ばれる。
【００３３】
データリンクは、ＡＲＱプロトコルにより信頼性のあるデータ転送を提供することが好ましい。ＡＲＱプロトコルは、当業者に周知のスライディングウィンドウメカニズムに基づくものとすることができる。
【００３４】
すでに上記で説明したように、ＡＲＱプロトコルは、受信機がＡＲＱプロトコルを管理できるようにするために、受信機側にバッファメモリを必要とする。受信機において各データリンクでこのようなＡＲＱプロトコルを実施するのに使用されるメモリは、すべてのデータリンク間で共有される。
【００３５】
本発明の一実施の形態による動的ＡＲＱウィンドウ管理は、ＡＲＱ管理エンティティと呼ばれるエンティティによって管理される。ＡＲＱエンティティは、受信機側の受信機ＡＲＱインスタンス（ＡＲＱ−ＲＸ）および送信機側の送信機ＡＲＱインスタンス（ＡＲＱ−ＴＸ）を備える。ＡＲＱ−ＲＸインスタンスは、データリンクのＡＲＱウィンドウを管理するデータリンクの宛先終端に位置する。単一のＡＲＱメモリバッファマネージャ（ＡＲＱ−ＭＢＭ）が、受信機側の利用可能なメモリバッファの管理を担当する。ＡＲＱ−ＭＢＭは、ＡＲＱ−ＲＸインスタンスによって起動される。ＡＲＱ−ＴＸインスタンスは、データリンクの送信元終端に位置し、トラフィック要件に基づいてスライディングウィンドウを管理するためにメモリ予約の要求をトリガする。
【００３６】
本発明の一実施の形態では、より良く理解するために、所定の１組の動作制御モードは２つの動作制御モードを備える。もちろん、本発明は、これよりも多くの動作制御モードに基づく実施の形態を包含する。
【００３７】
ＡＲＱエンティティは、データリンクごとに動作制御モードの１つを選択する。第１の選択は、データリンク確立時に行われる。このような選択は、所与のデータリンクのデータ送信中いつでも行えることが好ましい。第１の動作制御モードをバイナリフロー制御（ＢＦＣ）と呼ぶことにする。第２の動作制御モードをウィンドウフロー制御（ＷＦＣ）と呼ぶことにする。
【００３８】
ＡＲＱエンティティが、所与のデータリンクに対してＢＦＣモードを選択すると、ＡＲＱ−ＴＸインスタンスは、ＡＲＱ−ＡＣＫメッセージのフラグを使用してフロー制御されることが好ましい。このフロー制御フラグは、停止／再開（Stop/Resume）の略語であるＳ／Ｒと呼ばれる。実際には、このフロー制御フラグは、送信機が停止しなければならないこと、または、データ送信を継続（もしくは再開）できることを送信機に通知するフロー制御データを含む。ＢＦＣモードでは、受信機は、或るしきい値と利用可能なメモリ空間との比較に基づいてこのフラグを設定する。このしきい値は、運用管理で設定される。利用可能なメモリ空間がしきい値よりも大きい場合、ＡＲＱ−ＲＸインスタンスは、再開（Resume）の略語であるＲにフラグを設定し、次いで、送信機は、所与のデータリンクに対応する送信の継続を許可される。逆の場合、ＡＲＱ−ＲＸインスタンスは、停止（Stop）の略語であるＳにフラグを設定し、送信機は各データ送信を停止する。
【００３９】
ＡＲＱエンティティが、所与のデータリンクに対してＷＦＣモードを選択すると、ＡＲＱウィンドウサイズ（ＡＲＱ−ＷＳ）は、メモリ予約メカニズムに基づくウィンドウ予約メカニズムを通じて固定される。ＡＲＱ−ＷＳは、ＡＲＱ−ＴＸインスタンスおよびＡＲＱ−ＲＸインスタンスの双方によって使用されるパラメータである。ＢＦＣモードに導入されるフロー制御メカニズムは、送信機が、交渉されたＡＲＱ−ＷＳを一時的に超えることができるように、ＷＦＣモードで再現される。
【００４０】
メモリ予約メカニズムは、ＡＲＱプロトコルメッセージの組に追加される簡単な予約メッセージを通じて実施されることが好ましい。もちろん、本発明は、異なるプロトコルの実施態様を包含する。ウィンドウ予約（ＡＲＱ−ＷＲＳＶ（Window ReSerVation））メッセージおよびウィンドウ許可（ＡＲＱ−ＷＧＮＴ（Window GraNT））メッセージの２つのタイプのメッセージが定義される。それらメッセージは、データリンクの特定のシグナリングＬＬ−ＰＤＵで転送することもできるし、フィードバック要求（ＡＲＱ−ＲＦＢ（Requests for FeedBack））メッセージやＡＲＱ−ＡＣＫメッセージ等の既存のメッセージに組み込むこともできる。既存のメッセージに組み込む場合、ＡＲＱ−ＲＦＢメッセージおよびＡＲＱ−ＡＣＫメッセージに付加フィールドが設けられることが好ましい。ＡＲＱ−ＷＲＳＶメッセージは、要求ウィンドウサイズ（ＲｅｑＷＳ（Requested Window Size））フィールドと呼ばれる要求されたメモリ空間に関する情報を含む。ＡＲＱ−ＷＧＮＴメッセージは、予約されたメモリ空間に関する情報を含む。この予約されたメモリ空間は、受信機の共有メモリに現実に予約されるものであり、許可ウィンドウサイズ（ＧｎｔＷＳ（Granted Window Size））フィールドと呼ばれる。もちろん、予約されたメモリ空間は、要求されたメモリ空間と異なる可能性がある。
【００４１】
また、このようなプロトコルは、ＡＲＱ−ＡＣＫメッセージでピギーバックされるフロー制御フラグも使用することが好ましい。このフロー制御フラグがＲに設定されると、ＡＲＱ−ＡＣＫメッセージは、最後に正しく受信されたＬＬ−ＰＤＵ（ＬａｓｔＲＸ）の連続番号も含むことが好ましい。この情報は、ＡＲＱ−ＴＸがデータ送信を再開できるＬＬ−ＰＤＵを決定できるように設けられる。さらに、現在選択されている動作制御モード（ＢＦＣまたはＷＦＣ）は、ＡＲＱ−ＲＸインスタンスによって示され、好ましくは、既存のＡＲＱプロトコルメッセージを使用するために、モードフラグと呼ばれるフラグを通じて、各ＡＲＱ−ＡＣＫメッセージに含まれる。
【００４２】
ＡＲＱメモリバッファマネージャ（ＡＲＱ−ＭＢＭ（Memory Buffer Manager））は、所与の受信機で終端するデータリンクのすべてのＡＲＱ−ＲＸインスタンス間で受信機の共有メモリを共有することを担当する。このＡＲＱ−ＭＢＭは、ＡＲＱテーブルと呼ばれるテーブルを保持する。このテーブルの各エントリは、以下に示すように、１つのデータリンクのステータス情報を含む。このようなテーブルは、データリンクＩＤフィールド、クラスフィールド、モードフィールド、およびウィンドウサイズフィールドを含む。
【００４３】
【表２】
0004728013.tif 000003
【００４４】
データリンクＩＤは、データリンクｉ（ＤＬｉ）に付属した識別子である。
クラスは、ＤＬｉの優先度クラスである。
モードは、ＤＬｉの現在の動作モード（Ｍｏｄｅｉ）である。
ウィンドウサイズは、ＤＬｉの現在予約されているウィンドウサイズ（ＷＳｉ）である。
【００４５】
すべてのデータリンクに対応するメモリ予約要求に従ってメモリの共有を行うために、ＡＲＱ−ＭＢＭは、ＡＲＱ−ＷＲＳＶメッセージを通じてＡＲＱ−ＴＸインスタンスにより渡されたＲｅｑＷＳフィールドと、異なるテーブルエントリの内容とを入力として取り込む。
【００４６】
ＡＲＱ−ＭＢＭでは、メモリを共有する以下のアルゴリズムを実施することができる。
【００４７】
ＢＭＳｉｚｅ：全バッファメモリサイズ
ＢＭＲｓｖ：予約されたすべてのウィンドウによって占有されたバッファメモリ空間
ＢＭＲｓｖ（ＣＬｉ）：クラスｉのデータリンクの予約されたウィンドウによって占有されたバッファメモリの部分
ＤＬｉ：データリンクｉ
Ｍｏｄｅｉ：データリンクｉの現在のデータリンク動作モード
ＷＳｉ：データリンクｉの現在予約されているウィンドウサイズ（ＢＦＣモードの時、０に等しい）
ＲｅｑＷＳｉ：データリンクｉの要求されたウィンドウサイズ
ＧｎｔＷＳｉ：受信機によってデータリンクｉに許可されたウィンドウサイズ
【００４８】
ＡＲＱ−ＷＲＳＶメッセージをＤＬｉで受信すると、
【００４９】
【数１】
0004728013.tif 000004
【００５０】
if (ReqWSi ≦ WSi)
if (ReqWSi = 0)
Modei = BFC
endif
「予約は受け付けられた」
GntWSi = ReqWSi
WSi = GntWSi
else
if (ReqWSi < (BMSize  BMRsv))
if (WSi = 0)
Modei = WFC
endif
「予約は受け付けられた」
GntWSi = ReqWSi
WSi = GntWSi
else
【００５１】
【数２】
0004728013.tif 000005
【００５２】
if (WSi = 0)
Modei = WFC
endif
「予約は受け付けられた」
GntWSi = ReqWSi
WSi = GntWSi
【００５３】
【数３】
0004728013.tif 000006
【００５４】
等のクラスｊ＜ｉのすべてのＤＬｎに対してＢＦＣモードを強制する。すなわち、対応するデータリンクのテーブルにおいてモードフィールドをＢＦＣに設定する。
else
「予約は拒否された」
GntWSi = WSi
endif
endif
endif
【００５５】
ＡＲＱ−ＭＢＭは、以下の方程式に従って計算できる利用可能なバッファメモリ空間を常に監視する。
（ＢＭＳｉｚｅ−ＢＭＲｓｖ）
【００５６】
図２は、ＢＦＣモードとＷＦＣモードとの間の遷移を示す状態マシンを示している。これらの遷移は、（ＡＲＱ−ＲＸインスタンスについては）ＡＲＱ−ＷＧＮＴメッセージの送信時または（ＡＲＱ−ＴＸインスタンスについては）ＡＲＱ−ＡＣＫメッセージの受信時にトリガされる。実際には、ＡＲＱエンティティは、ＢＦＣ動作制御モードからＷＦＣ動作制御モードへの、２２で参照される遷移を管理する。この遷移は、受信機が、サイズが０に等しくないメモリ空間の要求を含んだＡＲＱ−ＷＲＳＶに応答して、メモリ予約が正しく行われたことを送信機に通知するＡＲＱ−ＷＧＮＴメッセージを返信する時の遷移である。ＡＲＱエンティティは、ＷＦＣ動作制御モードからＢＦＣ動作制御モードへの、２３で参照される遷移を管理する。この遷移は、サイズが０に等しいメモリ空間の要求を含んだＡＲＱ−ＷＲＳＶメッセージの受信時、または、受信機が、前に受け付けたメモリ予約をもはや保証できない時のいずれかの遷移である。その場合、遷移は、ＢＦＣに設定されたモードフィールドを有するＡＲＱ−ＡＣＫメッセージの放出／受信時にトリガされる。２４で参照される遷移は、送信機が現在のスライディングウィンドウよりも大きなスライディングウィンドウを必要とする場合を示している。この場合、ＡＲＱエンティティは、ＷＦＣ動作制御モードを維持し、予約されたメモリサイズのみが変更される。他方、２１で参照される遷移は、送信機が、サイズが０に等しくない所与のメモリ空間を予約するＡＲＱ−ＷＲＳＶメッセージを送信する場合であって、ＡＲＱ−ＲＸインスタンスがこのメモリ予約を受け付けることができない場合を示している。その結果、ＡＲＱエンティティはＢＦＣモードを維持する。
【００５７】
以下のセクションでは、本発明の一実施の形態に従ってＡＲＱ−ＲＸインスタンスにより受信機側で実行されるオペレーションを説明する。
【００５８】
所与のデータリンクについて考えると、その動作モードが何であっても、ＡＲＱ−ＲＸインスタンスは、ＬＬ−ＰＤＵを受信すると、共有メモリバッファの利用可能なメモリ空間をチェックする。この利用可能なメモリ空間は、以下の方程式に従って計算される。
ＢＭＳｉｚｅ−ＢＭＲｓｖ
【００５９】
利用可能なメモリ空間が所与の下限しきい値よりも小さい場合、ＡＲＱ−ＲＸインスタンスは、Ｓに設定されたフロー制御フラグを有するＡＲＱ−ＡＣＫメッセージを送信し、これによって、ＡＲＱ−ＴＸインスタンスは、対応するデータリンクのＰＤＵの送信を停止する。受信機のメモリバッファがない場合には、Ｓに設定されたフロー制御フラグを有するＡＲＱ−ＡＣＫメッセージをＡＲＱ−ＲＸインスタンスが送信した後に受信されたＬＬ−ＰＤＵは、廃棄することができる。
【００６０】
メモリバッファの利用可能なメモリ空間が、所与の上限しきい値よりも大きく、かつ、ＡＲＱ−ＴＸインスタンスが、対応するデータリンクでのＬＬ−ＰＤＵの送信を停止している場合、すなわち、Ｓに設定されたフロー制御フラグを有する最後のＡＲＱ−ＡＣＫが送信された後、ＡＲＱ−ＲＸインスタンスは、Ｒに設定されたフロー制御フラグを有し、有効なＬａｓｔＲＸフィールドを含んだＡＲＱ−ＡＣＫメッセージを送信し、最後に受信された有効なＰＤＵを送信機に示す。
【００６１】
ＡＲＱ−ＲＸがＡＲＱ−ＡＣＫメッセージを送信する他のあらゆる場合において、フロー制御フラグはＲに設定される。
【００６２】
いずれにしても、ＡＲＱ−ＲＸインスタンスは、現在のデータリンクの動作制御モードをＡＲＱ−ＡＣＫ中に位置するモードフラグを通じて示す。このモードフラグは、ＡＲＱテーブルにおけるデータリンクに関連付けられたエントリのモードフィールドから決定される。
【００６３】
ＢＦＣモードで動作するデータリンクについて考えると、ＡＲＱ−ＲＸインスタンスは、ＡＲＱ−ＷＲＳＶメッセージを受信すると、ＲｅｑＷＳフィールドに示された、要求されたウィンドウサイズでＡＲＱ−ＭＢＭを起動する。ＡＲＱ−ＭＢＭが「予約は受け付けられた」の表示を返すと、ＡＲＱ−ＲＸインスタンスは、ＲｅｑＷＳフィールドと同じ値を含んだＧｎｔＷＳフィールドを有するＡＲＱ−ＷＧＮＴメッセージを送信し、対応するデータリンクの動作制御モードは、ＢＦＣモードからＷＦＣモードへ切り換わる。ＡＲＱ−ＭＢＭが「予約は拒否された」の表示を返すと、ＡＲＱ−ＲＸインスタンスは、０に設定されたＧｎｔＷＳフィールドを有するＡＲＱ−ＷＧＮＴメッセージを送信し、データリンクはＢＦＣモードに留まる。
【００６４】
ＷＦＣモードで動作する所与のデータリンクについて考えると、ＡＲＱ−ＲＸインスタンスは、ＡＲＱ−ＷＲＳＶメッセージを受信すると、ＡＲＱ−ＭＢＭを起動することによって、ＲｅｑＷＳフィールドに示された新たに要求されたウィンドウサイズに利用可能なメモリバッファ空間を融通できるかどうかをチェックする。ＡＲＱ−ＭＢＭが「予約は受け付けられた」の表示を返すと、ＡＲＱ−ＲＸインスタンスは、ＲｅｑＷＳフィールドと同じ値を含んだＧｎｔＷＳフィールドを有するＡＲＱ−ＷＧＮＴメッセージを送信する。要求したウィンドウサイズの変更が拒否されると、ＡＲＱ−ＲＸインスタンスは、前に使用されていた値に設定されたＧｎｔＷＳフィールドを有するＡＲＱ−ＷＧＮＴメッセージを送信する。ＧｎｔＷＳフィールドが０に設定されると、ＡＲＱエンティティはＢＦＣモードに切り換わる。
【００６５】
以下のセクションでは、本発明の一実施の形態に従ってＡＲＱ−ＴＸインスタンスにより送信機側で実行されるオペレーションについて説明する。
【００６６】
動作モードが何であっても、ＡＲＱ−ＴＸインスタンスは、Ｓに設定されたフロー制御フラグを有するＡＲＱ−ＡＣＫメッセージを受信すると、所与のデータリンクでの新たなＬＬ−ＰＤＵの放出を停止するが、依然としてエラーのあったＬＬ−ＰＤＵを再送することはできる。
【００６７】
ＡＲＱ−ＴＸは、Ｒに設定されたフロー制御フラグを有するＡＲＱ−ＡＣＫメッセージを受信すると、所与のデータリンクでの新たなＬＬ−ＰＤＵの放出が前もって停止されていないならば、その放出を継続することができる。停止している時にこのメッセージが受信されると、ＡＲＱ−ＴＸインスタンスは、ＬａｓｔＲＸフィールドで示された連続番号から開始する新たなＬＬ−ＰＤＵの送信を再開する。
【００６８】
本発明の一実施の形態において、ＢＦＣモードで動作する所与のデータリンクを考えると、ＡＲＱ−ＴＸインスタンスは、要求されたウィンドウサイズをＲｅｑＷＳフィールドに含むＡＲＱ−ＷＲＳＶメッセージを送信することによって、ＢＦＣモードにある時はいつでもウィンドウメモリ予約プロシージャをトリガできることが好ましい。対応するＡＲＱ−ＷＧＮＴメッセージの受信を待っている間、タイマが始動される。ＡＲＱ−ＷＧＮＴメッセージが受信される前にタイマが満了すると、同じＡＲＱ−ＷＲＳＶメッセージを再送することができる。ＡＲＱ−ＴＸインスタンスは、ＡＲＱ−ＷＧＮＴメッセージを受信すると、このＡＲＱ−ＷＧＮＴメッセージのＧｎｔＷＳフィールドをチェックする。返されたウィンドウサイズが要求した値と等しい場合には、メモリ予約が成功している。返された値が要求した値と異なる場合、特に、返された値が０である場合には、予約は失敗しており、データリンクはＢＦＣモードに留まる。
【００６９】
ＷＦＣモードで動作する所与のデータリンクについて考えると、ウィンドウサイズは、各ＧｎｔＷＳフィールドに非ゼロの値を含む、最も近時に受信したＡＲＱ−ＷＧＮＴメッセージで返された値に固定される。
【００７０】
ウィンドウサイズは、ＢＦＣモードと同じプロシージャを使用することによって、ＡＲＱ−ＴＸインスタンスの要求に応じていつでも変更することができる。
【００７１】
ＡＲＱ−ＴＸインスタンスは、ＡＲＱ−ＷＧＮＴメッセージを受信すると、返されたＧｎｔＷＳフィールド値でウィンドウサイズを更新する。ＧｎｔＷＳフィールドが０に等しい場合、データリンクモードはＢＦＣモードに切り換わる。
【００７２】
ＢＦＣモードに設定された動作制御モードフラグを有するＡＲＱ−ＡＣＫメッセージを受信すると、データリンクモードはＢＦＣモードに切り換わる。
【００７３】
上述したように、Ｓに設定された制御フローフラグは、ＢＦＣモードと解釈される。この最後の特徴によって、メモリバッファ資源が受信機で利用可能である時に、ＡＲＱ−ＴＸインスタンスは、交渉したウィンドウサイズを超過することが可能になる。
【００７４】
図３は、本発明の一実施の形態における交換メッセージを介して所与のデータリンクで所与のデータリンクのＢＦＣモードとＷＦＣモードとの間を切り換わるいくつかの場合を示している。最初に、ＡＲＱエンティティは、ＢＦＣモード３１３を選択している。その結果、所与のデータリンクに対して、メモリ空間は受信機側に予約されない。送信機３０１は、メモリ空間を予約するためにＡＲＱ−ＷＲＳＶメッセージ３０３を受信機３０２に送信し、同時に、タイマ３１８を始動する。要求したメモリ空間のサイズは、ＡＲＱ−ＷＲＳＶメッセージのＲｅｑＷＳフィールドに設定される。受信機３０２は、ＡＲＱ−ＷＧＮＴメッセージ３０４を送信機３０１に返信する。送信機３０１は、タイマが満了する前に、このＡＲＱ−ＷＧＮＴメッセージ３０４を受信しない。送信機３０１は、同じＡＲＱ−ＷＲＳＶメッセージ３０５を再送する。利用可能なメモリ空間が、予約を要求したメモリ空間よりも大きい場合には、受信機３０２は、メモリ予約を受け付けたＡＲＱ−ＷＧＮＴメッセージ３０６を送信機に返信する。ＡＲＱエンティティは、所与のデータリンクについてＷＦＣモード３１４に切り換わる。予約された資源を解放するために、送信機３０１は、要求メモリサイズ０を含むＡＲＱ−ＷＲＳＶメッセージ３０７を送信する。受信機は、このメッセージ３０７を受信すると、対応するメモリ空間を解放し、ＡＲＱ−ＷＧＮＴメッセージ３０８を送信機３０１に返信する。ＡＲＱエンティティは、ＢＦＣモード３１５に切り換わる。その後、送信機３０１は、ＲｅｑＷＳフィールドにメモリ空間サイズを含むＡＲＱ−ＷＲＳＶメッセージ３０９を送信することによって、メモリ予約プロシージャを要求する。受信機は、要求されたメモリ空間サイズに等しい予約したメモリ空間サイズを含むＡＲＱ−ＷＧＮＴメッセージ３１０を返信することによって、この予約を受け付ける。ＡＲＱエンティティは、ＷＦＣモード３１６に切り換わる。その後、受信機は、所与のデータリンクに予約されたメモリ空間を先取りし、次いで、ＢＦＣに設定されたモードフラグを含むＡＲＱ−ＡＣＫメッセージ３１１を送信する。その結果、ＡＲＱエンティティは、ＢＦＣモード３１７に切り換わる。
【００７５】
本発明の一実施の形態は、さまざまなＱｏＳ制約条件を示す異なるアプリケーションデータフローが送信されるネットワークに有利に適用することができる。特に、特定のＱｏＳ要件を伴うことなく、大きな柔軟性がアプリケーションデータフローに提供される。実際には、このタイプのアプリケーションは、固定サイズの予約メモリを使用する必要なく、アプリケーションデータフローの瞬時スループットに応じてメモリ資源を有利に使用することができる。その結果、データリンク間でのメモリバッファの分配を動的に行うことができる。他方、厳しいＱｏＳ制約条件を有するアプリケーションデータフローには、予約プロシージャを使用することによって、資源が保証される。さらに、受信機に十分なメモリバッファが存在すると、あらゆるアプリケーションデータフローは、直ちに、下位層が提供する最大スループットに達することができる。その結果、メモリ資源が利用可能である限り、送信効率は、メモリ資源を使用する柔軟で効率的な動的メモリ管理によって改善され、これによって、メモリ資源の浪費が回避される。
【図面の簡単な説明】
【００７６】
【図１】従来技術による古典的なＡＲＱ方式を示す図である。
【図２】本発明の一実施の形態による２つの動作制御モード間の状態マシンを示す図である。
【図３】本発明の一実施の形態による送信機と受信機との間で交換されるメッセージを示す図である。
【符号の説明】
【００７７】
１１  送信機
１２  受信機
１３  データリンク
１４  逆方向データリンク
１５  メモリバッファ
【図１】
0004728013.tif 000007
【図２】
0004728013.tif 000008
【図３】
0004728013.tif 000009