JP4365358B2 - サービング無線ネットワークコントローラによるノードｂの消去制御を可能にするためのシステム - Google Patents

Description

本発明は、無線通信の分野に関する。より詳細には、本発明は、サービング無線ネットワークコントローラによりノードＢでの消去の制御を可能にするためのシステムおよび方法に関する。

３Ｇ（第３世代）ＵＴＲＡＮ（Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）は、いくつかのＲＮＣ（ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌｌｅｒ、無線ネットワークコントローラ）を備え、そのそれぞれが１つまたは複数のノードＢに結合されている。各ノードＢは、１つまたは複数のセルにサービスを提供する１つまたは複数の基地局を備える。ノードＢは、１つまたは複数のＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ、ユーザ機器）と通信する。

ＦＤＤ（周波数分割複信）とＴＤＤ（時分割複信）モードをどちらも含む３Ｇシステムは、通常、ＵＥへのデータ送信を配布（すなわち、バッファおよびスケジュール）するのにそのＲＮＣを使用する。しかし、３Ｇセルラシステムの高速チャネルでは、データはノードＢによって配布される。この高速チャネルの１つは、例えばＨＳ−ＤＳＣＨ（Ｈｉｇｈ Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）である。データがノードＢによって配布されるので、ＵＥへの送信前にデータをノードＢにバッファする必要がある。

ノードＢ中にバッファされたデータがもはや有用ではない場合、またそこにデータがあるとシステムの効率的な動作が妨げられ得る場合など多くのシナリオが存在する。例えば、最初のシナリオは、モバイルＵＥがあるセルから他に移動した場合である。その場合、ＵＥが他のノードＢによってもサービスを受けるＨＳ−ＤＳＣＨセル変更になるか、または同じノードＢ中でセル同士の間で切り換えることになる。「旧データ」（すなわち、ＨＳ−ＤＳＣＨのセル変更前に、ＵＥへの送信用にノードＢ内にバッファされたデータ）は、ＨＳ−ＤＳＣＨのセル変更後はもはや有用ではなくなる。ノードＢがそのデータをバッファし送信し続けた場合、それはバッファ資源と無線リンク資源をどちらも浪費することになる。バッファ資源と無線リンク資源をどちらも節約することになるので、この旧データをバッファから削除しデータ送信を中止することが望ましい。

第２のシナリオは、ＲＬＣ（ｒａｄｉｏ ｌｉｎｋ ｃｏｎｔｒｏｌ、無線リンクコントロール）レイヤに関する。ＲＬＣレイヤは、ＳＲＮＣ（ｓｅｒｖｉｎｇ ｒａｄｉｏ ｎｅｔｗｏｒｋ ｃｏｎｔｒｏｌｌｅｒ、サービング無線ネットワークコントローラ）とＵＥの両方におけるピアエンティティである。ＲＬＣピアツーピアプロトコルが正常に動作せず、ＲＬＣがそれ自体をリセットする場合がある。ＲＬＣの故障理由は様々であり、このような理由は本発明の範囲外である。しかし、ＲＬＣがそれ自体をリセットした後は送信を再同期させ再開するので、前にノードＢ中にバッファしたデータがもはや有用ではなくなる。このバッファされているデータは、伝送遅延、および無線資源の不必要な使用を生ずるだけである。このデータが伝送された場合、それはＲＬＣのピアエンティティによって廃棄されることになる。

第３のシナリオは、肯定応答モード（ＡＭ）でＲＬＣによりデータを順番に送達することに関する。肯定応答モードのＲＬＣへの要件は、ＰＤＵ（ｐｒｏｔｏｃｏｌ ｄａｔａ ｕｎｉｔ）が順番に送達されるのを確認することである。ＲＬＣは、各ＰＤＵに関連付けられたシーケンス番号（ＳＮ）を用いて、上位レイヤにＰＤＵが順番に送達されるのを確認する。順番通りではない送達があった場合（すなわち、ＰＤＵが消失した場合）、ＵＥ中のＲＬＣがノードＢ中のピアエンティティに状況レポート（Ｓｔａｔｕｓ Ｒｅｐｏｒｔ）ＰＤＵを送り、消失したＰＤＵの再送信を要求する。状況レポートＰＤＵを受信すると、ＲＮＣ中のピアエンティティがその消失したＰＤＵの複製を再送信する。

いくつかの理由のため、可能な限り速やかにその再送信されたＰＤＵが受信側のＲＬＣ（すなわち、ＵＥ）に到着することが非常に望ましい。まず、順番に送達されることが要件であるため、消失したＰＤＵにより後続するＰＤＵが上位レイヤに転送されることが妨げられる。次に、ＵＥのバッファが、実効データレートをなお維持しながら再送信の待ち時間を収容するほどの十分な大きさである必要がある。待ち時間が長くなればなる程、正しい順序のＰＤＵを上位レイヤに転送することができるまで、ＵＥが、維持されているＰＤＵと連続データ受信をどちらもバッファできるようにＵＥのバッファサイズを大きくする必要がある。バッファサイズを大きくするとＵＥのハードウェアコストが高くなる。これは非常に望ましくない。

図１は、ＲＮＣ、ノードＢ、ＵＥ、およびそれらの関連するバッファを含む従来技術のシステムである。この従来技術のシステムでは、ＳＮ＝３のＰＤＵがＵＥで正常に受信されていない。したがって、ＵＥ中のＲＬＣがＲＮＣ中のそのピアＲＬＣレイヤに再送信を要求する。一方、ＳＮ＝６〜９のＰＤＵは、ノードＢ中にバッファされ、ＳＮ＝４、５のＰＤＵはＵＥ中にバッファされる。図１は、いくつかのＰＤＵだけがバッファされているのを示しているが、実際は、（１００またはそれ以上などの）もっと多くのＰＤＵおよび他のＲＬＣエンティティからのＰＤＵがバッファされ得ることに留意されたい。

図２で示すように、ＳＮ＝３のＰＤＵの再送信は、ノードＢのバッファ中の待ち行列の最後で待っている必要があり、ＳＮ＝６〜９のＰＤＵが送信された後に初めて送信されることになる。ＵＥ中のＰＤＵは、すべてのＰＤＵが順番に受信されるまで、上位レイヤに転送することができない。この場合、すべてのＰＤＵが正常に送信されたと仮定しても、ＳＮ＝３のＰＤＵにより、後続のＰＤＵ（すなわち、ＳＮ＝４〜９）を上位レイヤに転送することが引き止められる。この例は１０個のＰＤＵを示しているだけであるが、通常の動作では何百ものＰＤＵが、データＰＤＵの再送信の前にスケジューリングされるおそれがあり、それが送信待ち時間およびデータのバッファリングの問題をさらに悪化させることに留意されたい。

上記のシナリオは、多くの例のうちのほんの数例であるが、ノードＢ中のデータを消去することにより、無線通信システムがさらに効率よく動作できるようになるはずである。

ノードＢ中にバッファされているもはや有用ではないデータの消去をＲＮＣが制御できるシステムおよび方法を有することが望ましい。多くの環境下で、このバッファされたデータを消去することにより、システムはさらに効率よく動作可能になるはずである。

本発明は、ＲＮＣがノードＢ中にバッファされたデータの消去の制御を可能にするシステムおよび方法を含む。消去コマンドが、特定のＵＥに関連するノードＢのバッファされたデータを削除する。ＲＮＣは、ＲＮＣ中で認識された特定のデータ消去トリガイベントに基づいて、特定のＵＥ用のすべてのデータ、すなわち１つまたはいくつかのユーザ優先順位送信待ち行列中のデータ、あるいはノードＢ中の１つまたは複数の論理チャネル中のデータの消去を決定する。次いで、ＲＮＣは、ノードＢに送信データを消去する必要があることを知らせる。その消去コマンドは、ＲＮＣから開始された既存の（従来技術の）手順を受信したことに応じてノードＢがデータを消去するための構成を含み、またはノードＢが具体的にデータ消去を要求するまったく新しい手順を含み、またはノードＢの消去要件を示すビットまたは情報要素として、既存の手順内もしくは送信データフレーム内に存在することもできる。

図を参照して本発明の好ましい実施形態を説明する。図中同じ番号は、全体を通して同じ要素を表す。

図３Ａを参照すると、本発明による、ノードＢ内の消去機能をＲＮＣが制御する方法１０が示されている。ＲＮＣは、特定のＵＥに関連する消去「トリガ」イベントが生ずるのを待つ（ステップ１２）。このトリガイベントは、例えば、サービングＨＳ−ＤＳＣＨセル変更（ｓｅｒｖｉｎｇ ＨＳ−ＤＳＣＨ ｃｅｌｌ ｃｈａｎｇｅ）、ＲＬＣリセット、あるいは一定のＰＤＵの再送信を必要とするＵＥからのＲＬＣ状況レポートの生成を含む。これらはトリガイベントのうちの３例であるが、もしノードＢの消去がシステムオペレーションに利益をもたらすならば、どんな機能であってもノードＢを消去するためのトリガイベントとして使用可能であることを当業者なら明確に理解するであろう。したがって、以下で説明する本発明の方法およびシステムを、この３つの列挙したトリガイベントだけに限定すべきではない。

消去トリガイベントに応じて、ＵＥに関連するすべてのデータ、すなわち、ＵＥの特定のデータフローに関連するデータ、またはＵＥの１つまたは複数の論理チャネルに関連するデータをノードＢ中で消去するように要求することができる。

例えば、サービングＨＳ−ＤＳＣＨセル変更の場合、サービングＨＳ−ＤＳＣＨセル変更後は、ソースノードＢ内にバッファされたＵＥ用のすべてのデータがもはや有用ではなくなる。ＲＮＣは、無線資源が不必要なデータ送信に浪費されることがないように、ソースノードＢを消去してＵＥに関連するすべてのバッファのデータを解放する。

ＲＬＣリセットまたはＲＬＣ再送信の場合は、ＲＮＣは、送信優先順位待ち行列により、あるいはそのＲＬＣインスタンスと関連する論理チャネルにより、その特定のＵＥ用にノードＢ中にバッファされたデータを選択的に消去する。その消去機能によって、ＲＬＣ再送信の場合、ＲＬＣ再送信待ち時間を低減し、ＲＬＣリセットの場合は無線資源の浪費を回避するようになる。

さらに図３Ａを参照すると、ＲＮＣはトリガイベントを受信したかどうか判定する（ステップ１４）。受信していない場合、ＲＮＣはステップ１２に戻り、トリガイベントが生ずるのを続けて待つ。トリガイベントが検出された場合、ＲＮＣは、ＵＥに関連する所望のデータをノードＢが消去すべきであることを示す消去メッセージをノードＢに送信する（ステップ１６）。これは、１つまたは複数のデータフローに関連する１つまたは複数のバッファ中のデータであり得る。このメッセージを受信すると（ステップ１８）、ノードＢは所望のバッファを消去する（ステップ２０）。

本発明の方法１０によれば、ノードＢ内のデータを消去することにより、もはや有用ではないデータを削除し、ノードＢ中のデータバッファリングリソースとこのデータの送信のために不必要に割り振られた無線資源をどちらも解放することを理解されたい。

ステップ１６から分るように、消去メッセージは以下の任意の１つまたは複数の代替形態を含むこともまた、当業者により理解されるであろう。消去メッセージの第１の代替形態では、消去メッセージは、ＲＮＣとノードＢの間で送信される既存のＵＴＲＡＮ手順内に存在し、それにより、ノードＢがメッセージを受信することによって消去が開始されるようにノードＢが構成される。この代替形態では、データ消去が既存の手順中で明示され、追加のシグナリングを必要とせず単にメッセージを受信するだけで、そのメッセージがまったく別の機能に関連するものである場合であっても、データを消去する。その明示的な関連は、フレームプロトコルのデータフレームにより発生し得るか、ＲＬＣのＰＤＵ中で搬送され得るか、あるいはＮＢＡＰ（Ｎｏｄｅ Ｂ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）もしくはＲＮＳＡＰ（Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｓｕｂｓｙｓｔｅｍ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）の従来技術のメッセージもしくは手順の情報要素として搬送され得る。

消去メッセージの第２の代替形態では、消去メッセージが、具体的にノードＢが所望のバッファの消去を開始するように指示する、ＲＮＣとノードＢの間で送信されるまったく新しい、または独特のＵＴＲＡＮ手順を含むことができる。これは、消去機能にまったく専用の別個のメッセージを含む。この代替形態では、例えば、フレームプロトコルにおける新しい制御フレームがこの消去機能専用であり、あるいは新しいＮＢＡＰ手順またはＲＮＳＡＰの手順がこの消去機能専用である。

消去メッセージの第３の代替形態では、消去メッセージが既存のＵＴＲＡＮ手順の一部を含むことができる。この実施形態では、ＲＮＣとノードＢの間で送信される既存のＵＴＲＡＮ手順におけるメッセージの一部であるビットまたは情報要素が消去機能専用である。ノードＢは、この情報を既存の手順によって受信し、そのビットまたは情報要素を読み取って消去を行うべきかどうかを判定する。

最後に、消去メッセージの第４の代替形態は、ノードＢが、従来技術のメッセージまたは新しいメッセージであり得るメッセージをＲＮＣから受信すると、データを消去するようにあらかじめ構成されている。この代替形態では、例えばＨＳ−ＤＳＣＨチャネルの解放（すなわち、無線リンクの解放）を示すメッセージを受信するとデータを消去するようにあらかじめ構成することができる。ＨＳ−ＤＳＣＨチャネルに関連しノードＢ中にバッファされたデータがＨＳ−ＤＳＣＨチャネルの解放後はもはや有用ではなくなるので、消去機能が有利である。

特定のシナリオに応じて、適正なシステム動作を行うために、ノードＢにおける消去機能を実行した後に他の機能が続くことができることが当業者により理解されるであろう。この発明は、ノードＢ中のＲＮＣによって制御される消去機能が様々なシナリオのための他の機能と協調するのを妨げるものではない。

ノードＢはさらに、図３Ｂで示すように消去機能の肯定応答を行うことができる。ステップ１１２〜１２０は、図３Ａの方法１０に関して図示し説明したステップ１２〜２０と同じである。したがって、この諸ステップをさらには説明しない。しかし、本発明の方法１００のこの代替形態によれば、所望のバッファを消去した後（ステップ１２０）ノードＢは、データが消去されたという肯定応答をＲＮＣに送る（ステップ１２２）。次いで、ＲＮＣは、その肯定応答を受信し処理する（ステップ１２４）。

この肯定応答の形式およびそれに応答してＲＮＣが行う動作の形式は、様々なシナリオに適した様々なシステム構成に基づいて異なることがあり得る。一例として、消去機能がＲＬＣのＰＤＵ再送信のために設計されているＨＳＤＰＡでは、消去機能を完了した後ノードＢからＲＮＣへの肯定応答はＲＮＣがＰＤＵ送信を再開することにより実施することができる。この場合、その肯定応答は、前に説明したのと同様な方法で行われる。

肯定応答メッセージの第１の代替形態では、肯定応答メッセージは、フレームプロトコルデータフレームのヘッダ中などノードＡからＲＮＣへの既存のメッセージ内に、あるいはＮＢＡＰまたはＲＮＳＡＰの従来技術のメッセージ中における１つもしくは数ビットまたは情報の要素として存在する。

肯定応答メッセージの第２の代替形態では、その肯定応答メッセージがまったく新しい、または独特のメッセージを含むことができる。それは、消去肯定応答機能に専用のフレームプロトコル中の新しい制御フレームなど、消去機能の肯定応答にまったく専用の別個のメッセージ、あるいは消去肯定応答機能に専用のＮＢＡＰまたはＲＮＳＡＰの新しいメッセージを含む。

最後に、肯定応答メッセージの第３の代替形態では、ノードＢからＲＮＣへの既存のメッセージが、そのメッセージ中に肯定応答用に特に予約されたフィールドがない場合であっても、消去機能の肯定応答を示すようにあらかじめ構成されている。特定のシナリオに応じて、適正なシステムオペレーションを達成できる他の方法を消去機能の肯定応答に使用できることが当業者により理解されるであろう。

肯定応答の形式にかかわらず、肯定応答はいくつかの機能を含むことができることに留意されたい。まず、肯定応答は、ノードＢによる、消去機能完了の肯定応答を含むことができる。あるいは、肯定応答は、ＲＮＣの動作を支援するためのノードＢ中のＰＤＵ送信状況を提供することができる。ノードＢは、ＰＤＵのＳＮに気付かないので、ノードＢは送信されたＰＤＵのＳＮをＲＮＣに直接送り返すことはできない。ノードＢは、例えばノードＢ中でＰＤＵの状況を識別するビットマップによってＰＤＵ送信状況をＲＮＣに知らせることができる。その状況は、消去され送信を待っているＰＤＵまたはＰＤＵの数を示すことができる。

図４を参照すると、本発明の方法５０の一例が示されている。このシナリオでは、ＵＥは１つまたは複数のＰＤＵが消失したことを示す状況ＰＤＵを送信する。ステップ５２で、ＵＥが、ＰＤＵの状況を示すＲＬＣ状況レポートをＲＮＣに送信する。この例では、その状況レポートは１つまたは複数のＰＤＵが消失していることを示すものと仮定している。状況レポートを処理した後、ＲＮＣは、再送信すべきＰＤＵに関連するバッファからバッファされているＰＤＵを消去するためのメッセージをノードＢに送る（ステップ５４）。

その消去メッセージは、再送信されるＰＤＵと共にデータフレーム中で、または再送信されるＰＤＵより高い優先順位で送られる制御フレーム中でフレームプロトコルによって運ばれる。あるいは、ＮＢＡＰまたはＲＮＳＡＰ上のメッセージを用いることによっても、ノードＢに知らせることができる。ノードＢは、所望のバッファからＰＤＵを消去し（ステップ５６）、その消去およびＰＤＵ状況をＲＮＣに肯定応答する（ステップ５８）。次いで、ＲＮＣは消失したＰＤＵおよび後続のＰＤＵを再送信する（ステップ６０）。ノードＢはこれらのＰＤＵをＵＥに送る（ステップ６２）。あるいは、消去メッセージは、消失したＰＤＵと共にフレームプロトコル中に含めることも、またはＮＢＡＰもしくはＲＮＳＡＰ中で、またはＮＢＡＰもしくはＲＮＳＡＰ上の別個のメッセージとして送信することもできる。

ＲＬＣ再送信の場合にノードＢ消去機能を実施する利点は、送信待ち時間の低減であるが、それは以下の例で説明する。図５を参照すると、本発明による消去機能を用いて、ノードＢは、ＳＮ＝６〜９のＰＤＵが削除されるようにバッファを消去する。この消去機能が完了するのに続いて、ノードＢがＲＮＣに消去機能の肯定応答を行い、次いで、ＲＮＣはＳＮ＝３からＲＬＣ送信を再開する（すなわち、ＵＥ中で消失したＰＤＵ）。次いで、ノードＢは、ＳＮ＝３のＰＤＵを受信する。その前には他のＰＤＵがまったくないので、再送信されたＳＮ＝３のＰＤＵは図２で示されたシナリオのときよりはるかに速く送信される。この例では、ＳＮ＝６〜９のＰＤＵは、ノードＢが消去された後に再度送信側のＲＬＣによって再送信される。

ＲＮＣは、消失したＰＤＵを送信後できる限り速やかに正常なＰＤＵシーケンスの再スタートを開始し、あるいは消去の肯定応答を行いかつ消去されたＰＤＵの情報を与えるＰＤＵ消去状況がノードＢから送られるまで待つこともできる。

第１の代替形態では、消去機能の肯定応答が行われない、または肯定応答機能が行われたとしても、ノードＢの消去機能の肯定応答の受信を待たないで消失したＰＤＵの再送信をＲＮＣが開始する。ノードＢは、消去機能を受け取る前にバッファされたＰＤＵを消去するだけであり、ＲＮＣから消去コマンドを受信した後、最近受信したＰＤＵをＵＥに送信することになる。

第２の代替形態では，ＲＮＣはノードＢから消去の肯定応答が送られるまで待つ。肯定応答がまた、ノードＢ中のデータブロック送信の状況を含む場合、ＲＮＣはその情報を用いてＰＤＵ送信をどこから再スタートすべきか決定することもできる。

図６を参照すると、本発明による代替の方法７０が示されている。この方法７０は、ノードＢがＲＮＣに送信する、ＰＤＵ状況および消去情報の肯定応答がない以外は図４で示された方法５０とほぼ同じである。

本発明について好ましい実施形態によって説明したが、添付の特許請求の範囲に略述されている本発明の範囲に含まれる他の変形形態は当業者であれば明らかであろう。

従来技術のＲＬＣ再送信を示す図である。 従来技術の消去しないＲＬＣ再送信を示す図である。 本発明の消去メッセージを生成する方法を示す図である。 肯定応答を含めた、本発明による消去メッセージを生成する代替の方法を示す図である。 本発明による、ＰＤＵ消去状況を受信するまでＲＮＣが再送信を待つノードＢの消去方法の一例を示す図である。 消去を含めた、本発明によるＲＬＣ再送信を示す図である。 本発明による、ＰＤＵ消去状況を受信するまでＲＮＣが再送信を待たないノードＢの消去方法の一例を示す図である。

Claims (15)

1. パケットデータユニット（ＰＤＵ）の送信を効率的に管理するための無線通信システムであって、
   ユーザ機器（ＵＥ）に関連するＰＤＵに関して消去トリガイベントを検出し、消去メッセージをノードＢに送信して前記ノードＢのバッファから前記ＵＥに関連する前記ＰＤＵの少なくとも一部の消去を要求するように構成されたＲＮＣと、
   ユーザ機器（ＵＥ）への送信を待機しているＰＤＵを記憶するバッファを含み、前記消去メッセージの受信に基づき前記バッファから前記要求されたＰＤＵを削除するように構成されたノードＢと
   を備えることを特徴とする無線通信システム。
2. 前記消去トリガイベントは、前記ＵＥのＨＳ−ＤＳＣＨ（Ｈｉｇｈ Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）のセル変更であることを特徴とする請求項１に記載のシステム。
3. 前記消去トリガイベントは、無線リンクコントロールのリセットであることを特徴とする請求項１に記載のシステム。
4. 前記ＵＥおよび前記ノードＢは、肯定応答モード（ＡＭ）で通信するように構成され、前記消去トリガイベントは、前記ＵＥから前記ノードＢへ送信されたＲＬＣ状況レポートのメッセージであることを特徴とする請求項１に記載のシステム。
5. 前記ノードＢは、前記ノードＢのバッファから前記ＵＥに関連する前記ＰＤＵの全てを削除するように構成されたことを特徴とする請求項１に記載のシステム。
6. 前記消去メッセージは、前記ＲＮＣから前記ノードＢへ送信されたデータフレームに含まれていることを特徴とする請求項１に記載のシステム。
7. 前記消去メッセージは、前記ＲＮＣから前記ノードＢへ送信された前記データフレームに含まれた情報要素であることを特徴とする請求項６に記載のシステム。
8. 前記消去メッセージは、前記ＲＮＣから前記ノードＢへ送信された前記データフレームに含まれたビットであることを特徴とする請求項６に記載のシステム。
9. 前記消去メッセージは、ＨＳ−ＤＳＣＨベアラの解放を指示することを特徴とする請求項７に記載のシステム。
10. 前記ノードＢは、前記ノードＢのバッファから前記要求されたＰＤＵを削除すると、前記ＲＮＣにバッファ消去の肯定応答を送信するようにさらに構成されたことを特徴とする請求項９に記載のシステム。
11. 前記バッファ消去の肯定応答は、前記ノードＢにおけるＰＤＵ送信状況を含むことを特徴とする請求項９に記載のシステム。
12. 前記ＲＮＣは、前記バッファ消去の肯定応答を受信すると、前記ノードＢに対するＰＤＵの送信を再開するようにさらに構成されたことを特徴とする請求項９に記載のシステム。
13. 前記バッファ消去の肯定応答は、データフレームのヘッダに含まれていることを特徴とする請求項９に記載のシステム。
14. 前記バッファ消去の肯定応答は、前記データフレームのヘッダの情報要素に含まれていることを特徴とする請求項１３に記載のシステム。
15. 前記バッファ消去の肯定応答は、前記データフレームのヘッダの少なくとも１ビットであることを特徴とする請求項１３に記載のシステム。

Images