(57)【要約】【課題】隠れ端末リストの作成・更新を必要とせず、ＲＴＳ／ＣＴＳプロトコル要否切り替え判定を効果的に行う。【解決手段】本発明の通信方法によれば、各端末は隠れ端末が存在するか否かを効果的に判定し、隠れ端末が存在する可能性がないと判定した場合にのみ衝突非抑制モードに移り、衝突抑制動作の不要な実行を避けることができ、衝突抑制効果を維持したまま伝送効率を改善できる。それに伴い、必要最小限に衝突抑制動作を行うため端末の消費電力の改善も期待できる。また、本発明は隠れ端末リストの作成・更新を必要としないため、データ伝送を一時中断する必要がなく、伝送スループットが一時的に急激に劣化することがない。このため、本発明は伝送ストリームの中断を許さない映像・音声のＡＶストリーム伝送を行う端末に非常に効果的である。【選択図】図２
2007174292.tif 000002
【特許請求の範囲】
【請求項１】
複数の無線局間または前記無線局と基地局との間でユーザ情報もしくは制御情報を含んだパケットを伝送する無線通信システムにおいて、前記パケットの衝突を抑制するために特定のパケット交換手順を実行する衝突抑制モードと、前記特定のパケット交換手順を実行しない衝突非抑制モードとの２つの動作モードを切り替えて通信を行う通信方法であって、
前記衝突非抑制モードで通信を行っている場合に、
前記衝突非抑制モードから前記衝突抑制モードに切り替えるかどうかの判定に用いる切り替え判定基準を取得するステップと、
前記切り替え判定基準に基づいて、前記衝突非抑制モードから前記衝突抑制モードに切り替えるかどうかを判定するステップと、
前記衝突非抑制モードから前記衝突抑制モードへの動作モードの切り替えを実行するステップとを含む通信方法。
【請求項２】
前記切り替え判定基準は、
前記パケットの受信信号の強度を示すパラメータと、
パケット誤り率を示すパラメータと、
パケット再送率を示すパラメータと、
前記パケットのパリティ検査の結果とのうちの少なくとも一つを含む、請求項１に記載の通信方法。
【請求項３】
複数の無線局間または前記無線局と基地局との間でユーザ情報もしくは制御情報を含んだパケットを伝送する無線通信システムにおいて、前記パケットの衝突を抑制するために特定のパケット交換手順を実行する衝突抑制モードと、前記特定のパケット交換手順を実行しない衝突非抑制モードとの２つの動作モードを切り替えて通信を行う通信方法であって、
前記衝突抑制モードで通信を行っている場合に、
前記衝突抑制モードから前記衝突非抑制モードに切り替えるかどうかの判定に用いる終了判定基準を取得するステップと、
前記終了判定基準に基づいて、前記衝突抑制モードから前記衝突非抑制モードに切り替えるかどうかを判定するステップと、
前記衝突抑制モードから前記衝突非抑制モードへの動作モードの切り替えを実行するステップとを含む通信方法。
【請求項４】
前記終了判定基準は、
パケット誤り率を示すパラメータと、
パケット再送率を示すパラメータと、
前記衝突抑制モードで動作する経過時間とのうち少なくとも一つを含む、請求項３に記載の通信方法。
【請求項５】
前記特定のパケット交換手順は、通信開始時に送信リクエストパケット（以下、ＲＴＳと称する）及び伝送路開放要求パケット（以下、ＣＴＳと称する）の送受信を含む、請求項１に記載の通信方法。
【請求項６】
前記特定のパケット交換手順は、通信開始時に送信リクエストパケット（以下、ＲＴＳと称する）及び伝送路開放要求パケット（以下、ＣＴＳと称する）の送受信を含む、請求項３に記載の通信方法。
【請求項７】
前記動作モードの切り替えを実行するステップは、
前記ユーザ情報を含むパケットに対して前記動作モード切り替えの指示情報を含む応答パケットを返信するステップと、
前記動作モード切り替えの指示情報を含むＣＴＳを送信するステップと、
前記ユーザ情報を含むパケットに対してＮＡＣＫと呼ばれる否定的な応答パケットを返信するステップとのうちいずれか一つを含む、請求項１に記載の通信方法。
【請求項８】
前記動作モードの切り替えを実行するステップは、
前記ユーザ情報を含むパケットに対して前記動作モード切り替えの指示情報を含む応答パケットを返信するステップと、
前記動作モード切り替えの指示情報を含むＣＴＳを送信するステップと、
前記ユーザ情報を含むパケットに対してＮＡＣＫと呼ばれる否定的な応答パケットを返信するステップとのうちいずれか一つを含む、請求項３に記載の通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信ネットワークにおける隠れ端末による影響を抑制するＲＴＳ／ＣＴＳプロトコルに関する。
【背景技術】
【０００２】
ＲＴＳ／ＣＴＳプロトコル（以下、“ＲＴＳ／ＣＴＳ”）は、キャリアセンス技術を用いた分散アクセス制御無線通信システムにおける隠れ端末による信号の衝突、いわゆる“コリジョン（ｃｏｌｌｉｓｉｏｎ）”を抑制するために一般的によく用いられるプロトコルである。
【０００３】
ＩＥＥＥ８０２.１１ａ／ｂ／ｇ／ｅなどに代表される様々な無線通信規格では、隠れ端末が存在する環境におけるシステム性能の劣化を緩和するためにＲＴＳ／ＣＴＳが採用されている。
【０００４】
しかし、各データフレームの送信の前にＲＴＳフレームおよびＣＴＳフレームの交換を行うことによって伝送効率が悪くなる。ＲＴＳ／ＣＴＳプロトコルを実行する場合、データフレームの長さによっては伝送効率が数パーセント〜数十パーセント劣化する。例えば、ＩＥＥＥ８０２．１１規格では、伝送レート３６Ｍｂｐｓで長さ１５００バイトのデータを送信する場合、ＲＴＳ／ＣＴＳを実行すると、伝送効率が約２０％低下する（下記計算例を参照）。
【０００５】
計算例：
データ伝送レート３６Ｍｂｐｓ、データフレーム１５００ｂｙｔｅ→（１）データフレーム伝送時間＝３６４＋規定フレームギャップ１６ｕｓ＝３８０ｕｓ
制御フレーム伝送レート１２Ｍｂｐｓ、ＲＴＳフレーム２０ｂｙｔｅ／ＣＴＳフレーム１４ｂｙｔｅ→ＲＴＳ３６ｕｓ／ＣＴＳ３２ｕｓ→（２）ＲＴＳ／ＣＴＳ伝送時間＝３６ｕｓ＋３２ｕｓ＋２×規定フレームギャップ１６ｕｓ＝１００ｕｓ
伝送効率＝（１）／（（１）＋（２））＝３８０／(３８０＋１００)×１００＝７９％
また、データフレームの長さが非常に短いＶｏＩＰ伝送のような場合では、伝送効率が５０％まで低下することが考えられる。
【０００６】
ＩＥＥＥ８０２．１１規格では、このようなＲＴＳ／ＣＴＳプロトコルによる伝送効率の低下を抑えるために、ｄｏｔ１１ＲＴＳＴｈｒｅｓｈｏｌｄという制御パラメータが設けられている。例えば、ｄｏｔ１１ＲＴＳＴｈｒｅｓｈｏｌｄ＝１５００ｂｙｔｅと設定された端末の場合、その端末は長さが１５００バイト以上のデータフレームを送信する時にのみＲＴＳ／ＣＴＳプロトコルを実行する。これにより、伝送効率の低下を２０％程度以下になるように抑えることができる（上記計算例と同一条件で計算した場合）。
【０００７】
しかし、このようなデータフレーム長によるＲＴＳ／ＣＴＳプロトコルの要否判定は、隠れ端末問題を本質的に考慮してないため、隠れ端末が存在しない環境でもＲＴＳ／ＣＴＳプロトコルを実行して、伝送効率を低下させてしまう可能性が十分にあると考えられる。
【０００８】
この課題に対して、特許文献１ではＲＴＳ／ＣＴＳプロトコルの無駄な実行を確実に避けるために、隠れ端末端末リストを作成する方法および隠れ端末リストに基づいたＲＴＳ／ＣＴＳプロトコル要否判定を提案している。特許文献１では、各端末はそれぞれ隠れ端末リストを作成し、そのリストに隠れ端末が一つも存在しない場合は、ＲＴＳ／ＣＴＳプロトコルを実行しない。
【０００９】
上記の隠れ端末リストを完成するために、各端末は近辺に存在する全ての端末が自分にとって隠れ端末であるかどうかを認識する必要がある。特許文献１では、隠れ端末の認識をＲＴＳフレーム／ＣＴＳフレームの受信状況に基づいて行なっている。ある端末のアドレスを含むＲＴＳフレーム／ＣＴＳフレームを両方とも受信できれば、該当端末は自分にとって隠れ端末ではないと認識する。ＲＴＳフレーム／ＣＴＳフレームのどちらか一方しか届かない場合は、届いたＲＴＳフレームまたはＣＴＳフレームに含まれる宛先アドレスの端末が自分にとって隠れ端末であると認識する（詳細は特許文献１を参照）。
【００１０】
このような認識方法で隠れ端末リストを完成するためには、システム内すべての端末がＲＴＳ／ＣＴＳを少なくても一週実行しなければならないため、端末台数が多いシステムほど隠れ端末リストの完成までに時間がかかる。また、新しい端末の新規参入や伝播路特性の変動に応じて周期的に隠れ端末リストを更新しなければ、正確なＲＴＳ／ＣＴＳプロトコルの要否判定を維持できない。このため、端末の出入りが激しいホットスポットのようなシステムに適用した場合、頻繁に隠れ端末リストを更新すると、リスト更新中データ伝送を休止する必要があるため伝送スループットが一時的に急激に劣化すると考えられる。
【特許文献１】特開２００２−２１７９１３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上記のように、本発明が解決しようとする課題は、「隠れ端末リストの作成・更新を必要とせず、ＲＴＳ／ＣＴＳプロトコル要否切り替え判定を効果的に行う」ことである。本発明では、前記課題を解決するためにＲＴＳ／ＣＴＳプロトコルの動的な要否切り替え判定方法を提案する。
【課題を解決するための手段】
【００１２】
上記課題を解決するための第１の発明は、複数の無線局間または前記無線局と基地局との間でユーザ情報もしくは制御情報を含んだパケットを伝送する無線通信システムにおいて、前記パケットの衝突を抑制するために特定のパケット交換手順を実行する衝突抑制モードと、前記特定のパケット交換手順を実行しない衝突非抑制モードとの２つの動作モードを切り替えて通信を行う通信方法であって、前記衝突非抑制モードで通信を行っている場合に、前記衝突非抑制モードから前記衝突抑制モードに切り替えるかどうかの判定に用いる切り替え判定基準を取得するステップと、前記切り替え判定基準に基づいて、前記衝突非抑制モードから前記衝突抑制モードに切り替えるかどうかを判定するステップと、前記衝突非抑制モードから前記衝突抑制モードへの動作モードの切り替えを実行するステップとを含む。
【００１３】
上記課題を解決するための第２の発明は、複数の無線局間または前記無線局と基地局との間でユーザ情報もしくは制御情報を含んだパケットを伝送する無線通信システムにおいて、前記パケットの衝突を抑制するために特定のパケット交換手順を実行する衝突抑制モードと、前記特定のパケット交換手順を実行しない衝突非抑制モードとの２つの動作モードを切り替えて通信を行う通信方法であって、前記衝突抑制モードで通信を行っている場合に、前記衝突抑制モードから前記衝突非抑制モードに切り替えるかどうかの判定に用いる終了判定基準を取得するステップと、前記終了判定基準に基づいて、前記衝突抑制モードから前記衝突非抑制モードに切り替えるかどうかを判定するステップと、前記衝突抑制モードから前記衝突非抑制モードへの動作モードの切り替えを実行するステップとを含む。
【発明の効果】
【００１４】
本発明の通信方法によれば、各端末は隠れ端末が存在するか否かを効果的に判定し、隠れ端末が存在する可能性がないと判定した場合にのみ衝突非抑制モードに移るため、隠れ端末が存在しない場合の不要な伝送効率の低下を避けることができ、衝突抑制効果を維持したまま伝送効率を改善できる。それに伴い、必要最小限に衝突抑制を行うため端末の消費電力の改善も期待できる。
【００１５】
また、本発明は、隠れ端末リストの作成・更新を必要としないため、データ伝送を一時中断する必要がなく、伝送スループットが一時的に劣化することがない。このため、本発明は、伝送ストリームの中断を許さない映像・音声のＡＶストリーム伝送を行う端末に非常に効果的である。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施の形態について図面を参照しながら説明する。説明の都合上、本発明を徹底的に理解いただくために特定の数、時間、構造およびその他のパラメータを提示する。以下の段階で本発明を実地する方法の例を挙げる。しかし、これほど詳細を指定せずとも本発明が実施可能であることは当業者には明らかであろう。また、当業者とって、実際の実装では、新たな情報が加えられる場合もあり、かつ実際に使用される状況に依存してある種のパーツや過程が省略される場合もあることは明白である。
【００１７】
本発明は、効果的にＲＴＳ／ＣＴＳプロトコル要否切り替え判定を行う判定アルゴリズムに用いられる“隠れ端末が存在する可能性がある条件”に着目する。例えば、近辺に隠れ端末が存在する場合、隠れ端末と同じ時間帯にデータパケットを送信すると、データパケットが衝突し、データパケットの受信電力が強くても衝突による干渉を受けたことによって送信したパケットが正しく復調できない確率が高くなる。この現象に基づく、“隠れ端末が存在する可能性がある条件”は、パケット受信電力が強いのにも係わらずパケット受信失敗確率が高いという条件である。ここでは、ＲＴＳ／ＣＴＳプロトコル要否切り替え判定の際に、パケット受信電力およびパケット誤り率を判定条件として用いる方法を提案する。また、パケット誤り率は、パケット再送率と同程度なのでパケット誤り率の代わりにパケット再送率を用いても支障はない。また、パケット受信電力およびパケット誤り率は実際のシステムではトラヒック、電波状況、端末の配置など様々な状況によって刻々と変化するため、この二つのパラメータを用いた提案の要否切り替え判定方法は、刻々と変化するシステム状況に対応可能なＲＴＳ／ＣＴＳプロトコル動的要否切り替え判定方法となる。
【００１８】
図１に、本発明のＲＴＳ／ＣＴＳプロトコル要否切り替え判定方法の基本構成を示す。本発明は主にＲＴＳ／ＣＴＳ実行モード（１０２）とＲＴＳ／ＣＴＳ非実行モード（１０１）を切り替える「切り替え判定」ステップ（１０３）および「戻る判定」ステップ（１０４）から構成される。「切り替え判定」ステップ（１０３）はＲＴＳ／ＣＴＳ非実行モード（１０１）で動作する時にＲＴＳ／ＣＴＳ実行モード（１０２）に切り替えるべきかどうかを判定する。一方、「戻る判定」ステップ（１０４）はＲＴＳ／ＣＴＳ実行モード（１０２）で動作する時にＲＴＳ／ＣＴＳ非実行モード（１０１）に戻るべきかどうかを判定する。「切り替え判定」ステップ（１０３）および「戻る判定」ステップ（１０４）はパケットの受信側における受信電力の強さ（以下ＲＳＳＩ：Ｒｅｃｅｉｖｅｄ  Ｓｉｇｎａｌ  Ｓｔｒｅｎｇｔｈ  Ｉｎｔｅｎｓｉｔｙ）や受信側におけるパケット誤り率や受信パケットＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）ビット検査結果などを判定条件として用いて、判定結果を決定する。つまり、判定結果はＲＳＳＩやパケット再送率やＣＲＣ検査結果に左右されるのである。ＲＳＳＩおよびパケット再送率は時間経過と共に変化するため、本発明を適用した端末は周期的または非周期的にこの二つのパラメータを測定または取得する必要がある（１０５）。ちなみに、上記ＲＳＳＩの代わりに信号電力対雑音電力の比（以下  ＳＮＲ：Ｓｉｇｎａｌ  Ｔｏ  Ｎｏｉｓｅ  Ｒａｔｉｏ）、キャリア電力対雑音電力の比（以下  ＣＮＲ：Ｃａｒｒｉｅｒ  ｔｏ  Ｎｏｉｓｅ  Ｒａｔｉｏ）など受信信号の強度を表すものを用いても良い。また、パケット誤り率の代わりに送信側におけるパケット再送率や受信側におけるビット誤り率などを用いても良い。
【００１９】
図１に示したＲＴＳ／ＣＴＳプロトコル要否切り替え判定は通常データストリームを受信する受信側で行われる。これはなぜかというと、ＲＳＳＩと受信パケット誤り率と受信パケットのＣＲＣビット検査結果は受信端末側で求めることが出来るものである。しかし、ＲＴＳ／ＣＴＳプロトコル要否切り替え判定をデータストリーム送信側で行うことも可能だが、この場合、受信パケット誤り率の代わりにパケット再送率を代用し、送信側で通常求められないＲＳＳＩ情報を受信側に何らかの手段で提供してもらうかまたは受信側の過去のフレーム(ＡＣＫなど)を受け取った時のＲＳＳＩに基づいて受信側のＲＳＳＩを推定する必要がある。受信側で上記判定方法を行う場合、“受信側主導ＲＴＳ／ＣＴＳ要否切り替え判定”と呼ぶ。一方、送信側で判定を行う場合、“送信側主導ＲＴＳ／ＣＴＳ要否切り替え判定”と呼ぶ。
【００２０】
次に、本発明の骨子である「切り替え判定」（１０３）の詳細について説明する。
【００２１】
図２〜５に、４通りのＲＴＳ／ＣＴＳ要否切り替え判定手順のフローチャートを示す。
【００２２】
図２に、ＲＳＳＩおよびパケット誤り率によるＲＴＳ／ＣＴＳ要否切り替え判定手順のフローチャートを示す。ＲＳＳＩおよびパケット誤り率を用いて判定を行う場合、切り替え判定ステップ（２２３）はＲＳＳＩ判定ステップ（２２１）とパケット誤り率判定ステップ（２２２）から構成される。ＲＳＳＩ判定ステップ（２２１）ではまずＲＴＳ／ＣＴＳ非実行モードで動作中にＲＳＳＩをある閾値と比較する（２０２）。ＲＳＳＩが閾値より下回った場合、ＲＳＳＩが弱いと見なされるため（２０４）、判定は「何もしない」という結果になる(２０５)。ＲＳＳＩが閾値より上回った場合、ＲＳＳＩが強いと見なされるためさらにパケット誤り率の判定を行う（２０６）。パケット誤り率判定ステップ（２２２）ではまずパケット誤り率をある閾値と比較する（２０６）。パケット誤り率が閾値より上回った場合、パケット誤り率が低いと見なされるため（２０８）、判定は「何もしない」という結果になる（２０９）。パケット誤り率が閾値より上回った場合、パケット誤り率が高いと見なされる（２０７）。この場合、ＲＳＳＩが強いのにも係わらずパケット誤り率が高いという条件になっているため「隠れ端末が存在する可能性が高い」と解釈され（２１０）、ＲＴＳ／ＣＴＳ非実行モードからＲＴＳ／ＣＴＳ実行モードに移行する。ＲＴＳ／ＣＴＳ実行モードに移行後、送信端末はデータフレームを送信する前に必ずＲＴＳ／ＣＴＳのフレーム交換を実行することになる。ＲＴＳ／ＣＴＳ実行モードで動作中に「戻る判定ステップ」が実行される。戻る判定ステップ（２１２）では条件が満たされれば、ＲＴＳ／ＣＴＳ実行モードからＲＴＳ／ＣＴＳ非実行モードに戻ることになるが、条件が満たされなければ、ＲＴＳ／ＣＴＳ実行モードにおける動作を維持する。「戻る判定ステップ」の詳細については下記図６、７で説明する。
【００２３】
この図２のＲＴＳ／ＣＴＳ要否切り替え判定は通常受信側主導で行うものだが、送信側主導でも行うことも可能である。しかし、受信パケット誤り率の代わりにパケット再送率を代用し、ＲＳＳＩ情報を受信側に何らかの手段で提供してもらうかまたは受信側の過去のフレーム(ＡＣＫなど)を受け取った時のＲＳＳＩに基づいて受信側のＲＳＳＩを推定する必要がある。
【００２４】
図３に、ＲＳＳＩおよび受信パケットＣＲＣビット検査結果によるＲＴＳ／ＣＴＳ要否切り替え判定手順のフローチャートを示す。ＲＳＳＩおよび受信パケットＣＲＣビット検査結果を用いて判定を行う場合、切り替え判定ステップ（３２３）はＲＳＳＩ判定ステップ（３２１）とデータ部ＣＲＣ判定ステップ（３２２）から構成される。ＲＳＳＩ判定ステップ（３２１）ではまずＲＴＳ／ＣＴＳ非実行モードで動作中にＲＳＳＩをある閾値と比較する（３０２）。ＲＳＳＩが閾値より下回った場合、ＲＳＳＩが弱いと見なされるため（３０４）、判定は「何もしない」という結果になる(３０５)。ＲＳＳＩが閾値より上回った場合、ＲＳＳＩが強いと見なされるためさらにデータ部ＣＲＣの判定を行う（３０６）。データ部ＣＲＣ判定ステップ（３２２）ではまずデータ部ＣＲＣビットの検査を行う（３０６）。ＣＲＣビット検査結果が成功の場合、パケットが受かるため（３０８）、判定は「何もしない」という結果になる（３０９）。ＣＲＣビット検査結果が失敗の場合、干渉が強いと予想される（３０７）。この場合、「隠れ端末が存在する可能性が高い」と解釈され（３１０）、ＲＴＳ／ＣＴＳ非実行モードからＲＴＳ／ＣＴＳ実行モードに移行する。ＲＴＳ／ＣＴＳ実行モードに移行後、送信端末はデータフレームを送信する前に必ずＲＴＳ／ＣＴＳのフレーム交換を実行することになる。ＲＴＳ／ＣＴＳ実行モードで動作中に「戻る判定ステップ」が実行される。戻る判定ステップ（３１２）では条件が満たされれば、ＲＴＳ／ＣＴＳ実行モードからＲＴＳ／ＣＴＳ非実行モードに戻ることになるが、条件が満たされなければ、ＲＴＳ／ＣＴＳ実行モードにおける動作を維持する。「戻る判定ステップ」の詳細については下記図６、７で説明する。
【００２５】
この図３のＲＴＳ／ＣＴＳ要否切り替え判定はＣＲＣ検査結果を必要とするため基本的に受信側主導でのみ行うことができる。また、ＣＲＣビット検査に用いられるデータＣＲＣ部は図８のＩＥＥＥ８０２．１１  ＭＡＣプロトコルデータフレームフォーマット内の７０４のようなものである。
【００２６】
図４に、受信パケットＣＲＣビット検査結果によるＲＴＳ／ＣＴＳ要否切り替え判定手順のフローチャートを示す。受信パケットＣＲＣビット検査結果のみを用いて判定を行う場合、切り替え判定ステップ（４２３）はヘッダ部ＣＲＣ判定ステップ（４２１）とデータ部ＣＲＣ判定ステップ（４２２）から構成される。ヘッダ部判定ステップ（４２１）ではまずＲＴＳ／ＣＴＳ非実行モードで動作中にヘッダ部ＣＲＣビット検査を行う（４０２）。ヘッダ部ＣＲＣ検査結果が失敗の場合、受信パケットが当然誤ったパケットと見なされるため（４０４）、判定は「何もしない」という結果になる(４０５)。ヘッダ部ＣＲＣ検査結果が成功の場合、さらにデータ部ＣＲＣの判定を行う（４０６）。データ部ＣＲＣ判定ステップ（４２２）ではまずデータ部ＣＲＣビットの検査を行う（４０６）。ＣＲＣビット検査結果が成功の場合、パケットが受かるため（４０８）、判定は「何もしない」という結果になる（４０９）。ＣＲＣビット検査結果が失敗の場合、干渉が強いと予想される（４０７）。この場合、「隠れ端末が存在する可能性がある」と解釈され（４１０）、ＲＴＳ／ＣＴＳ非実行モードからＲＴＳ／ＣＴＳ実行モードに移行する。ＲＴＳ／ＣＴＳ実行モードに移行後、送信端末はデータフレームを送信する前に必ずＲＴＳ／ＣＴＳのフレーム交換を実行することになる。ＲＴＳ／ＣＴＳ実行モードで動作中に「戻る判定ステップ」が実行される。戻る判定ステップ（４１２）では条件が満たされれば、ＲＴＳ／ＣＴＳ実行モードからＲＴＳ／ＣＴＳ非実行モードに戻ることになるが、条件が満たされなければ、ＲＴＳ／ＣＴＳ実行モードにおける動作を維持する。「戻る判定ステップ」の詳細については下記図６、７で説明する。
【００２７】
この図４のＲＴＳ／ＣＴＳ要否切り替え判定はＣＲＣ検査結果を必要とするため基本的に受信側主導でのみ行うことができる。また、ＣＲＣビット検査に用いられるデータＣＲＣ部は図８のＩＥＥＥ８０２.１１  ＭＡＣプロトコルデータフレームフォーマット内の７０４のようなものである。ヘッダＣＲＣ部は図８の７１５のようなものである。なお、ヘッダＣＲＣ部はＭＡＣ層のヘッダのＣＲＣと限定せず、物理層のヘッダのＣＲＣなどでも良い。
【００２８】
また、４１０で「隠れ端末が存在する可能性が高い」の代わりに「隠れ端末が存在する可能性がある」という表現を使った理由はヘッダ部ＣＲＣ検査結果が成功であってもデータ部ＣＲＣ検査が失敗になることが、隠れ端末からの干渉を受けたかどうかにも係わらず通常よく起きることである。このため、図４の判定手順による判定精度は図２、３の場合と比べて比較的劣ると考えられる。しかし、ヘッダＣＲＣ判定ステップとデータＣＲＣ判定ステップの順序を逆にすれば判定精度を高めることができる。
【００２９】
図５に、図４のＣＲＣ判定ステップとデータＣＲＣ判定ステップの順序を逆にした場合の受信パケットＣＲＣビット検査結果によるＲＴＳ／ＣＴＳ要否切り替え判定手順のフローチャートを示す。この場合、「データＣＲＣ検査結果が成功」且つ「ヘッダＣＲＣ検査結果が失敗」という条件を満たす時のみＲＴＳ／ＣＴＳ実行モードに切り替える結果になる。実際、受信パケットが干渉を受けない限り上記の条件が非常に発生しにくいため、この条件を用いれば隠れ端末が存在する状況をより正確に割り出すことができると考えられる。しかし、通常のパケット受信処理ではデータＣＲＣ検査の前に行われるヘッダＣＲＣ検査の結果が失敗になると基本的にそのパケットが即座に廃棄されるが、図５のＲＴＳ／ＣＴＳ要否切り替え判定手順を用いた場合ヘッダ部のＣＲＣ検査の結果が失敗であってもデータ部のＣＲＣ検査を行う必要がある。
【００３０】
次に、図１における「戻る判定」（１０４）の詳細について説明する。
【００３１】
図６、７に２通りのＲＴＳ／ＣＴＳ非実行モードへの戻る判定を示す。「戻る判定」（１０４）に用いられる判定条件は時間経過あるいはパケット誤り率の回復があります。
【００３２】
図６に、一定時間経過によるＲＴＳ／ＣＴＳ非実行モードへの戻る判定手順のフローチャートを示す。この場合、ＲＴＳ／ＣＴＳ実行モードの経過時間がある一定時間を越えると自動的にＲＴＳ／ＣＴＳ非実行モードに戻ることが決定される（５０３）。ＲＴＳ／ＣＴＳ実行モードの経過時間がある一定時間を越えなければＲＴＳ／ＣＴＳ実行モードでの動作が続けられる（５０４）。
【００３３】
図７に、パケット誤り率によるＲＴＳ／ＣＴＳ非実行モードへの戻る判定手順のフローチャートを示す。この場合、パケット誤り率がある閾値を下回ると自動的にＲＴＳ／ＣＴＳ非実行モードに戻ることが決定される（６０３）。パケット誤り率が閾値を下回るように回復するまでＲＴＳ／ＣＴＳ実行モードでの動作が続けられる（６０４）。送信側主導の場合、パケット誤り率の代わりにパケット再送率を用いても支障はない。
【００３４】
次に、「ＲＴＳ／ＣＴＳ実行モードに切り替える」ステップ（２１１、３１１、４１１、４６１）および「ＲＴＳ／ＣＴＳ非実行モードに戻る」ステップ（２０１、３０１、４０１、４５１）における動作について説明する。
【００３５】
送信側主導で本発明を実施する場合、送信側の端末は自分自身で判定結果を下し、ＲＴＳ／ＣＴＳ実行モードとＲＴＳ／ＣＴＳ非実行モードを自分自身で切り替えることが出来るため、「ＲＴＳ／ＣＴＳ実行モードに切り替える」ステップ（２１１）および「ＲＴＳ／ＣＴＳ非実行モードに戻る」ステップ（２０１）における動作は受信側の端末に協力してもらう必要がない。また、送信側の端末は受信側に届いたパケットＣＲＣ検査結果を入手する手段は一般的に設けられていないため、“送信側主導ＲＴＳ／ＣＴＳ要否切り替え判定”方法は基本的に図２に示した判定手順を用いる。この場合、送信側の端末は受信パケット誤り率の代わりにパケット再送率を代用し、ＲＳＳＩ情報を受信側に何らかの手段で提供してもらうかまたは受信側の過去のフレーム(ＡＣＫなど)を受け取った時のＲＳＳＩに基づいて受信側のＲＳＳＩを推定する必要がある。
【００３６】
図１３に、送信側主導ＲＴＳ／ＣＴＳ要否切り替え判定方法におけるフレームシーケンスの一例を示す。システム内でＳＴＡ１〜ＳＴＡ４  ４台の端末が存在するとし、各端末の配置は図１１に示される。ＳＴＡ１（１００１）とＳＴＡ３（１００３）はデータストリームの送信側とし、ＳＴＡ２（１００２）とＳＴＡ４（１００４）はデータストリームの受信側とする。ＳＴＡ２（１００２）はＳＴＡ１（１００１）から送信されたデータフレームを受信し、ＳＴＡ４（１００４）はＳＴＡ３（１００３）から送信されたデータフレームを受信する。ＳＴＡ１〜ＳＴＡ４は最初ＲＴＳ／ＣＴＳ非実行モードで動作しているものとする。図１１からわかるように、ＳＴＡ１（１００１）とＳＴＡ３（１００３）はお互い電波到達範囲外に存在する且つ両端末の受信端末は近くに存在するため、隠れ端末の関係である。このため、ＳＴＡ１（１００１）とＳＴＡ３（１００３）が同時にデータフレーム（１２０１、１２０２）を送信し、頻繁に衝突を起こすことになる。衝突が起きるたびにデータフレームが再送されるため、ある程度時間が経過するとＳＴＡ１（１００１）およびＳＴＡ３（１００３）におけるパケット再送率が閾値を上回ってしまう。図１３では、ＳＴＡ１（１００１）は先にパケット再送率が閾値を上回ってしまうため、「切り替え判定ステップ」（２２３）によってＳＴＡ３（１００３）より先にＲＴＳ／ＣＴＳ実行モードに切り替える（１２１１）。その後、ＳＴＡ１（１００１）はデータフレームを送信する前に必ずＳＴＡ２（１００２）とＲＴＳ／ＣＴＳフレームの交換を行うことになる。ＳＴＡ３（１００３）はまだＲＴＳ／ＣＴＳ非実行モードで動作中のため、ＳＴＡ３から送信されたデータフレーム（１２０５）がＳＴＡ１から送信されたＲＴＳフレーム（１２０４）と衝突することも考えられる。次第に、ＳＴＡ３（１００３）はパケット再送率が閾値を上回るため、ＲＴＳ／ＣＴＳ実行モードに切り替える（１２１２）。この時点から、ＳＴＡ１とＳＴＡ３両方の端末がＲＴＳ／ＣＴＳ実行モードで動作するようになったため、ＲＴＳ／ＣＴＳ効果により衝突確率が減少し始める。その後、ある程度時間が経過するとＳＴＡ１とＳＴＡ３のパケット再送率が閾値を下回るため、ＳＴＡ１とＳＴＡ３は「戻る判定ステップ」（図７）によって自動的に「ＲＴＳ／ＣＴＳ非実行モード」に戻ることになる。
【００３７】
「戻る判定ステップ」は図７のパケット誤り率の回復による戻る判定の代わりに図６の時間経過による戻る判定を用いても良い。
【００３８】
一方、受信側主導で本発明を実施する場合、受信側の端末は自分自身で判定結果を下すが、ＲＴＳ／ＣＴＳ実行モードとＲＴＳ／ＣＴＳ非実行モードの切り替えは送信側の端末しか出来ないため、「ＲＴＳ／ＣＴＳ実行モードに切り替える」ステップ（２１１）および「ＲＴＳ／ＣＴＳ非実行モードに戻る」ステップ（２０１）における動作は送信側の端末に協力してもらう必要がある。この場合、受信側の端末は判定結果を含むある特定フレームを送信側の端末に送信する必要がある。判定結果を含む特定フレームは図９と図１０のような拡張ＡＣＫフレームと拡張ＣＴＳフレームなどが考えられる。拡張ＡＣＫフレーム（８０１）および拡張ＣＴＳフレーム（９０１）に含まれる「ＲＴＳ／ＣＴＳ要否切り替え判定結果」（８０３、９０３）というフィールドは「Ｈｉｄｄｅｎ  Ｔｅｒｍｉｎａｌ  Ｐｏｓｓｉｂｉｌｉｔｙ（８０４、９０４）」(以下ＨＴＰ)または「ＲＴＳ／ＣＴＳ  Ｍｏｄｅ（８０５、９０５）」（以下ＲＣＭ）という情報が表示される。ＲＣＭ（８０５、９０５）は送信側の端末に強制的にＲＴＳ／ＣＴＳモードを切り替えさせる意味合いであるが、ＨＴＰ（８０４、９０４）はあくまでも送信端末に「隠れ端末の存在可能性」があるかどうかという意味合いだけである。このため、ＲＴＳ／ＣＴＳモードの切り替えの権限を受信側の端末に持たせる場合「ＲＣＭ」を用いるが、ＲＴＳ／ＣＴＳモードの切り替えの権限を送信側の端末に持たせる場合「ＨＴＰ」を用いることになる。
【００３９】
図１３に、拡張ＡＣＫをトリガーとして用いた場合における受信側主導要ＲＴＳ／ＣＴＳ否切り替え判定方法におけるフレームシーケンスの一例を示す。システム内にはＳＴＡ１〜ＳＴＡ４の４台の端末が存在するとし、各端末の配置は図１１に示される。ＳＴＡ１（１００１）とＳＴＡ３（１００３）はデータストリームの送信側とし、ＳＴＡ２（１００２）とＳＴＡ４（１００４）はデータストリームの受信側とする。ＳＴＡ２（１００２）はＳＴＡ１（１００１）から送信されたデータフレームを受信し、ＳＴＡ４（１００４）はＳＴＡ３（１００３）から送信されたデータフレームを受信する。ＳＴＡ１〜ＳＴＡ４は最初ＲＴＳ／ＣＴＳ非実行モードで動作しているものとする。図１１からわかるように、ＳＴＡ１（１００１）とＳＴＡ３（１００３）はお互い電波到達範囲外に存在する且つ両端末の受信端末は近くに存在するため、隠れ端末の関係である。このため、ＳＴＡ１（１００１）とＳＴＡ３（１００３）が同時にデータフレームを送信し、頻繁に衝突を起こすことになる。図１４ではまずＳＴＡ２は「切り替え判定ステップ」（２２３、３２３、４２３、４７３）によってＲＴＳ／ＣＴＳ実行モードに切り替えるという判定結果を下す。ＳＴＡ２は判定結果をＳＴＡ１伝えるために、ＨＴＰビットまたはＲＣＭビット＝０１を含む拡張ＡＣＫフレーム（１３０１）をＳＴＡ１からのデータフレームのレスポンスとして返信する。上記拡張ＡＣＫフレーム（１３０１）を受信したＳＴＡ１はＲＴＳ／ＣＴＳモードを非実行モードから実行モードに切り替える（１３１１）。その後、ＳＴＡ２と同様にＳＴＡ４は「切り替え判定ステップ」（２２３、３２３、４２３、４７３）によってＲＴＳ／ＣＴＳ実行モードに切り替えるという判定結果を下す。ＳＴＡ４は判定結果をＳＴＡ３伝えるために、ＨＴＰビットまたはＲＣＭビット＝０１を含む拡張ＡＣＫフレーム（１３０２）をＳＴＡ３からのデータフレームのレスポンスとして返信する。上記拡張ＡＣＫフレーム（１３０２）を受信したＳＴＡ３はＲＴＳ／ＣＴＳモードを非実行モードから実行モードに切り替える（１３１２）。その後、ＳＴＡ１およびＳＴＡ３はデータフレームを送信する前に必ず受信側の端末（ＳＴＡ２、ＳＴＡ４）とＲＴＳ／ＣＴＳフレームの交換を行うことになる。図１４ではそのあと、ある程度時間が経過するとＳＴＡ２におけるパケット誤り率が閾値を下回るため、ＳＴＡ２は「戻る判定ステップ」（図７）によって自動的に「ＲＴＳ／ＣＴＳ非実行モード」に戻るという判定結果を下す。ＳＴＡ２は判定結果をＳＴＡ１伝えるために、ＨＴＰビットまたはＲＣＭビット＝００を含む拡張ＡＣＫフレーム（１３０３）をＳＴＡ１からのデータフレームのレスポンスとして返信する。上記拡張ＡＣＫフレーム（１３０３）を受信したＳＴＡ１はＲＴＳ／ＣＴＳモードを実行モードから非実行モードに切り替える（１３１３）。その後、ＳＴＡ１はデータフレーム送信の前にＳＴＡ２とＲＴＳ／ＣＴＳフレームの交換を行わないようになる。
【００４０】
「戻る判定ステップ」は図７のパケット誤り率の回復による戻る判定の代わりに図６の時間経過による戻る判定を用いても良い。なお、図１３では判定結果を送信側に伝える時のみ拡張ＡＣＫフレーム（８０１）が使われているが、実際では判定結果を送信側に伝える時以外でも拡張ＡＣＫフレーム（８０１）を使用することも考えられる。つまり、受信データフレームに対する返信はすべて図９のような拡張ＡＣＫフレーム（８０１）用いることになる。
【００４１】
なお、従来システムの端末との互換性を保つために拡張ＡＣＫの代わりに「ＮＡＣＫ」と呼ばれる否定的な応答パケットをトリガーとして用いても良い。
【００４２】
図１５に、拡張ＣＴＳをトリガーとして用いた場合における受信側主導要ＲＴＳ／ＣＴＳ否切り替え判定方法におけるフレームシーケンスの一例を示す。システム内でＳＴＡ１〜ＳＴＡ４  ４台の端末が存在するとし、各端末の配置は図１１に示される。ＳＴＡ１（１００１）とＳＴＡ３（１００３）はデータストリームの送信側とし、ＳＴＡ２（１００２）とＳＴＡ４（１００４）はデータストリームの受信側とする。ＳＴＡ２（１００２）はＳＴＡ１（１００１）から送信されたデータフレームを受信し、ＳＴＡ４（１００４）はＳＴＡ３（１００３）から送信されたデータフレームを受信する。ＳＴＡ１〜ＳＴＡ４は最初ＲＴＳ／ＣＴＳ非実行モードで動作しているものとする。図１１からわかるように、ＳＴＡ１（１００１）とＳＴＡ３（１００３）はお互い電波到達範囲外に存在する且つ両端末の受信端末は近くに存在するため、隠れ端末の関係である。このため、ＳＴＡ１（１００１）とＳＴＡ３（１００３）が同時にデータフレームを送信し、頻繁に衝突を起こすことになる。図１５ではまずＳＴＡ２は「切り替え判定ステップ」（２２３、３２３、４２３、４７３）によってＲＴＳ／ＣＴＳ実行モードに切り替えるという判定結果を下す。ＳＴＡ２は判定結果をＳＴＡ１伝えるために、ＨＴＰビットまたはＲＣＭビット＝０１を含む拡張ＣＴＳフレーム（１４０１）をＳＴＡ１に送信する。上記拡張ＡＣＫフレーム（１４０１）を受信したＳＴＡ１はＲＴＳ／ＣＴＳモードを非実行モードから実行モードに切り替える（１４１１）。その後、ＳＴＡ２と同様にＳＴＡ４は「切り替え判定ステップ」（２２３、３２３、４２３、４７３）によってＲＴＳ／ＣＴＳ実行モードに切り替えるという判定結果を下す。ＳＴＡ４は判定結果をＳＴＡ３伝えるために、ＨＴＰビットまたはＲＣＭビット＝０１を含む拡張ＣＴＳフレーム（１４０２）をＳＴＡ３に送信する。上記拡張ＣＴＳフレーム（１４０２）を受信したＳＴＡ３はＲＴＳ／ＣＴＳモードを非実行モードから実行モードに切り替える（１４１２）。その後、ＳＴＡ１およびＳＴＡ３はデータフレームを送信する前に必ず受信側の端末（ＳＴＡ２、ＳＴＡ４）とＲＴＳ／ＣＴＳフレームの交換を行うことになる。図１５ではそのあと、ある程度時間が経過するとＳＴＡ２におけるパケット誤り率が閾値を下回るため、ＳＴＡ２は「戻る判定ステップ」（図７）によって自動的に「ＲＴＳ／ＣＴＳ非実行モード」に戻るという判定結果を下す。ＳＴＡ２は判定結果をＳＴＡ１伝えるために、ＨＴＰビットまたはＲＣＭビット＝００を含む拡張ＡＣＫフレーム（１４０３）をＳＴＡ１からのＲＴＳフレームのレスポンスとして返信する。上記拡張ＡＣＫフレーム（１４０３）を受信したＳＴＡ１はＲＴＳ／ＣＴＳモードを実行モードから非実行モードに切り替える（１４１３）。その後、ＳＴＡ１はデータフレーム送信の前にＳＴＡ２とＲＴＳ／ＣＴＳフレームの交換を行わないようになる。ちなみに、「戻る判定」の結果を伝える時、ＳＴＡ４のようにＲＴＳフレーム受信後でなくてもＨＴＰビットまたはＲＣＭビット＝００を含む拡張ＡＣＫフレーム（１４０４）をデータストリームの送信側の端末に送信して良い。
【００４３】
「戻る判定ステップ」は図７のパケット誤り率の回復による戻る判定の代わりに図６の時間経過による戻る判定を用いても良い。なお、図１５では判定結果を送信側に伝える時のみ拡張ＣＴＳフレーム（９０１）が使われているが、実際では判定結果を送信側に伝える時以外でも拡張ＣＴＳフレーム（９０１）を使用することも考えられる。つまり、どんな時でも図１０のような拡張ＣＴＳフレーム（９０１）用いることになる。
【００４４】
次に、新規端末の参入によってスループットはどのように変化するかということについて図１１、１２、１６を用いて説明する。
【００４５】
図１１に、新規参入前のシステム内の端末の配置の一例を示す。
【００４６】
図１２に、新規端末ＳＴＡ７およびＳＴＡ８が参入したあとのシステム内の端末の配置の一例を示す。
【００４７】
図１６に、新規端末ＳＴＡ７およびＳＴＡ８の参入によるスループット変化の一例を示す。
【００４８】
図１１では、システム内でＳＴＡ１〜ＳＴＡ４  ４台の端末が存在する。ＳＴＡ１（１００１）とＳＴＡ３（１００３）はデータストリームの送信側とし、ＳＴＡ２（１００２）とＳＴＡ４（１００４）はデータストリームの受信側とする。ＳＴＡ２（１００２）はＳＴＡ１（１００１）から送信されたデータフレームを受信し、ＳＴＡ４（１００４）はＳＴＡ３（１００３）から送信されたデータフレームを受信する。図１１からわかるように、ＳＴＡ１（１００１）とＳＴＡ３（１００３）はお互い電波到達範囲外に存在する且つ両端末の受信端末は近くに存在するため、隠れ端末の関係である。図１３、１４、１５でも説明したようにＳＴＡ１（１００１）およびＳＴＡ３（１００３）は本発明のＲＴＳ／ＣＴＳ要否切り替え判定方法によってＲＴＳ／ＣＴＳ実行モードで動作している。図１１におけるシステムの有効帯域は合計３０Ｍｂｐｓとするため、各ストリームにおけるスループットは最大約１０Ｍｂｐｓになる。しかし、ＳＴＡ１→ＳＴＡ２のストリーム（１５１１）およびＳＴＡ３→ＳＴＡ４のストリーム（１５１２）はＲＴＳ／ＣＴＳフレーム交換によるオーバヘッドロス約２０％を被るため実質のデータスループットは約８Ｍｂｐｓとなる。ちなみに、上記および下記の説明で使われる数値はＩＥＥＥ８０２．１１規格準拠システムにおいて伝送レート３６Ｍｂｐｓで長さ１５００バイトのデータストリームをＲＴＳ／ＣＴＳ実行モードで送信する場合の大まかな計算結果である。結果的に、図１１における定常状態のスループットは図１６の１５１０のようになる。
【００４９】
その後、ＳＴＡ７およびＳＴＡ８が参入すると、端末の配置は図１２のようになる。図１２におけるシステムの有効帯域は合計３０Ｍｂｐｓとするため、４つのストリームが均等に帯域を獲得できるとすれば各ストリームにおけるスループットは最大約３０Ｍｂｐｓ／４＝７．５Ｍｂｐｓになる。図１２からわかるように、ＳＴＡ５（１００５）とＳＴＡ７（１００７）はお互い電波到達範囲外に存在する且つ両端末の受信端末は近くに存在するため、隠れ端末の関係である。そのため、ＲＴＳ／ＣＴＳ非実行モードで動作している時はＳＴＡ５（１００５）とＳＴＡ７（１００７）が同時にデータフレームを送信し、頻繁に衝突を起こすことになる。ＳＴＡ５→ＳＴＡ６のストリーム（１５２３）およびＳＴＡ７→ＳＴＡ８のストリーム（１５２４）は衝突によってスループットが４Ｍｂｐｓまで低下することも考えられる。結果的に、ＳＴＡ７およびＳＴＡ８が新規参入した時の各ストリームのスループットは図１６の１５２０のようになる。
【００５０】
その後、ＳＴＡ５とＳＴＡ６は本発明のＲＴＳ／ＣＴＳ要否切り替え判定方法によってＲＴＳ／ＣＴＳ実行モードで動作し始めるため衝突が多少減少し、ＳＴＡ５→ＳＴＡ６のストリーム（１５３３）およびＳＴＡ７→ＳＴＡ８のストリーム（１５３４）は４Ｍｂｐｓから５Ｍｂｐｓまで改善される。結果的に、各ストリームのスループットは図１６の１５３０のようになる。
【００５１】
その後、ＳＴＡ７とＳＴＡ８もＲＴＳ／ＣＴＳ実行モードで動作し始めるため衝突がさらに減少し、ＳＴＡ５→ＳＴＡ６のストリーム（１５４３）およびＳＴＡ７→ＳＴＡ８のストリーム（１５４４）は５Ｍｂｐｓから６Ｍｂｐｓまで改善される。結果的に、各ストリームのスループットは図１６の１５４０のようになる。
【００５２】
図１６におけるスループット変化の一例からわかるように、新規参入端末が既存端末と隠れ端末の関係にある場合、本発明のＲＴＳ／ＣＴＳ要否切り替え判定方法を用いてＲＴＳ／ＣＴＳモードを切り替えることにより徐々に衝突によるスループットの低下を軽減できる。また、本発明は隠れ端末リストの作成・更新を必要としないため、リストの作成・更新のためにデータ伝送を一時中断する必要がなく、伝送スループットが一時的に急激に劣化することがない。
【００５３】
しかし、新規参入端末が既存端末と隠れ端末の関係にある場合、図１６の１５３０のような段階で隠れ端末リストの更新を必要とするためすべてのストリーム伝送を一時中断する必要がある。そのため、各ストリームのスループットが一時的に急激に低下する。
【００５４】
本発明は、隠れ端末リスト作成・更新を行わないため伝送ストリームの中断を許さない映像・音声のＡＶストリーム伝送を行う端末に非常に効果的である。
【産業上の利用可能性】
【００５５】
本発明は、無線ネットワークにおけるテレビ信号やＶｏＩＰ信号の安定的な伝送を実現することに有用である。
【図面の簡単な説明】
【００５６】
【図１】本発明のＲＴＳ／ＣＴＳプロトコル要否切り替え判定方法の基本構成を示す図
【図２】ＲＳＳＩおよびパケット誤り率によるＲＴＳ／ＣＴＳ要否切り替え判定手順を示すフローチャート
【図３】ＲＳＳＩおよびＣＲＣ検査によるＲＴＳ／ＣＴＳ要否切り替え判定手順を示すフローチャート
【図４】ＣＲＣ検査によるＲＴＳ／ＣＴＳ要否切り替え判定手順を示すフローチャート
【図５】ＣＲＣ検査によるＲＴＳ／ＣＴＳ要否切り替え判定手順を示すフローチャート
【図６】一定時間経過によるＲＴＳ／ＣＴＳ非実行モードへの戻る判定手順を示すフローチャート
【図７】パケット誤り率の回復よるＲＴＳ／ＣＴＳ非実行モードへの戻る判定手順を示すフローチャート
【図８】ＣＲＣ検査によるＲＴＳ／ＣＴＳ要否切り替え判定の場合のデータフレームフォーマットを示す図
【図９】拡張ＡＣＫフレームのフォーマットを示す図
【図１０】拡張ＣＴＳフレームのフォーマットを示す図
【図１１】実施の形態の利用シナリオ（１）を示す図
【図１２】実施例の利用シナリオ（２）を示す図
【図１３】送信側主導ＲＴＳ／ＣＴＳ要否切り替え判定方法におけるフレームシーケンスの一例を示す図
【図１４】受信側主導要ＲＴＳ／ＣＴＳ否切り替え判定方法におけるフレームシーケンスの一例を示す図（拡張ＡＣＫをトリガーとして用いた場合）
【図１５】受信側主導ＲＴＳ／ＣＴＳ否切り替え判定方法におけるフレームシーケンスの一例を示す図（拡張ＣＴＳをトリガーとして用いた場合）
【図１６】新規端末の参入によるスループット変化の一例を示す図
【図１】
2007174292.tif 000003
【図２】
2007174292.tif 000004
【図３】
2007174292.tif 000005
【図４】
2007174292.tif 000006
【図５】
2007174292.tif 000007
【図６】
2007174292.tif 000008
【図７】
2007174292.tif 000009
【図８】
2007174292.tif 000010
【図９】
2007174292.tif 000011
【図１０】
2007174292.tif 000012
【図１１】
2007174292.tif 000013
【図１２】
2007174292.tif 000014
【図１３】
2007174292.tif 000015
【図１４】
2007174292.tif 000016
【図１５】
2007174292.tif 000017
【図１６】
2007174292.tif 000018