JP2009060213A - 無線通信装置、無線通信システム、無線通信方法及びプログラム - Google Patents

Abstract

【課題】送信側で必要最小限のメディアを確保することで、ネットワーク内の端末に対して送信契機を均等に割り当てること。
【解決手段】無線通信ネットワークを介して接続された通信先端末との間で通信を行う帯域予約型の無線通信装置であって、通信先端末からの返信データを受信する際のトラフィック量を推定するＲＤトラフィック量算出部と、トラフィック量に基づいてメディアを予約するメディア予約部１００と、を備える。
【選択図】図６

Description

本発明は、無線通信装置、無線通信システム、無線通信方法及びプログラムに関する。

無線ＬＡＮ(WLAN; wireless local area network)のIEEE 802.11に代表されるＣＳＭＡ／ＣＳ(carrier sense multiple access with collision detection)方式では、メディア(Media; 無線伝送路)の空き状態検出、他端末とのメディア使用権競合、メディアの確保（予約）、データ送信、再送要求検出、の手順を繰り返すことにより、データの送受信が行われる。

図１５は、ＣＳＭＡ／ＣＳ方式でデータの送受信が行われる様子を示すタイミングチャートである。まず、送信側端末(STA-A)は、通信の準備ができたことを知らせる信号RTS(request to send)を送信し、受信側端末(STA-B)から送信の許可を表す信号CTS(clear to send)を受信する。これにより、メディアの確保が行われる。その後、STA-AからSTA-Bへデータ(Data to B)を送り、データが正しく受信されたことを通知するため、STA-BからSTA-AへＡＣＫ(acknowledge)を返信する。

その後、STA-Bがチャネルをセンシングし、RTSをSTA-Aへ送信し、CTSの返信を受けてメディアを確保する。そして、STA-BからSTA-Aへデータ(Data to A)を送信し、STA-AからＡＣＫの返信を受ける。

上記手法はデータ送受信の制御を簡素に行うことができる一方で、以下要因によりスループットが劣化するという問題がある。
・メディア空き状態検出、他端末とのメディア使用権均等化処理に要する時間のオーバーヘッドが大きい。このため、同一の端末に対して複数の端末から送信が行われ、仕組みの不完全性によるパケット衝突が発生する。
・メディア確保に必要なプロトコルのオーバーヘッドが大きい。
・送信機はメディアの伝送能力を認識することができないため、最適なデータパケット伝送レートを選択できない。

このような状況の中、IEEE 802.11nには、端末間の双方向データ通信を行う際のオーバーヘッド、パケット衝突確率を削減するリバース・ダイレクション・プロトコル(Reverse
Direction Protocol)が規定されている。

しかしながら、リバース・ダイレクション・プロトコルによる手法では、STA-Bが必要とするメディアのリソース(データの有無、データ量、送信可能レート)をSTA-Aは把握できないという問題がある。そして、メディアの確保時にどれだけメディアを確保すべきか判断することができないため、実際に使うメディア量よりも多くのリソースを一旦確保することが行われてしまう。そして、必要以上にメディアを予約した場合であっても、ペナルティが課されることもないため、メディアの予約自体が他端末の送信契機を減らす要因となる。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、送信側で必要最小限のメディアを確保することで、ネットワーク内の端末に対して送信契機を均等に割り当てることが可能な、新規かつ改良された無線通信装置、無線通信システム、無線通信方法及びプログラムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、無線通信ネットワークを介して接続された通信先端末との間で通信を行う帯域予約型の無線通信装置であって、前記通信先端末からの返信データを受信する際のトラフィック量を推定するトラフィック量推定部と、前記トラフィック量に基づいてメディアを予約するメディア予約部と、を備える無線通信装置が提供される。

上記構成によれば、通信先端末からの返信データを受信する際のトラフィック量が推定され、トラフィック量に基づいてメディアが予約される。従って、通信先端末からの返信データに応じた必要最小限のメディアを確保することができ、実際に必要なメディア量以上のメディアが確保されてしまうことを抑えることが可能となり、他端末の送信契機が低減してしまうことを確実に抑止できる。

また、前記通信先端末へ送信する送信データ量を算出する送信データ量算出部と、送信時の平均送信レートを算出する平均送信レート算出部と、前記トラフィック量、前記送信データ量、及び前記平均送信レートに基づいて、メディア予約時間を算出するメディア算出部と、を備え、前記メディア予約部は、前記メディア算出部で算出されたメディア予約時間に基づいてメディアを予約するものであってもよい。かかる構成によれば、返信データを受信する際のトラフィック量とともに、通信先端末へ送信する送信データ量、送信時の平均送信レートに基づいてメディア予約時間が算出され、メディア予約時間に基づいてメディアが予約される。従って、返信データを受信する際のトラフィック量とともに、データ送信時のメディアを考慮してメディアを予約することが可能となる。

また、前記通信先端末へのデータ送信に対して返信されたＡＣＫとともに前記通信先端末からの返信データを受信するものであってもよい。かかる構成によれば、IEEE 801.11nにおけるリバース・ダイレクション・プロトコルなどのＡＣＫとともに返信データを受信する装置において、返信データを受信する際のトラフィック量を推定することができる。

また、前記トラフィック量推定部は、前記通信先端末が送信する要求値に基づいて前記トラフィック量を推定するものであってもよい。かかる構成によれば、通信先端末が送信する要求値に基づいてメディアを予約することができる。

また、前記トラフィック量推定部は、ＭＡＣレイヤーよりも上位のアプリケーションから通知される情報に基づいて前記トラフィック量を推定するものであってもよい。かかる構成によれば、ＭＡＣレイヤーよりも上位のアプリケーションから通知される情報に基づいて、トラフィック量を精度良く推定することが可能となる。

また、前記上位のアプリケーションはＴＣＰレイヤーであり、前記トラフィック量推定部は、前記通信先端末のＴＣＰバッファの残量に基づいて前記トラフィック量を推定するものであってもよい。かかる構成によれば、通信先端末のＴＣＰバッファの残量が少ない場合は、通信先端末からデータが返信されてくることが予測できるため、ＴＣＰバッファの残量に基づいてトラフィック量を推定することが可能となる。

また、前記トラフィック量推定部は、前記通信先端末のＴＣＰバッファのウィンドウサイズと、前記通信先端末に対して送信済みであり且つＡＣＫが返信されていない送信データ量との差分から前記ＴＣＰバッファの残量を算出するものであってもよい。かかる構成によれば、通信先端末のＴＣＰバッファのウィンドウサイズと、通信先端末に対して送信済みであり且つＡＣＫが返信されていない送信データ量との差分からＴＣＰバッファの残量を算出することができるため、これに基づいてトラフィック量を推定することが可能となる。

また、前記トラフィック量推定部は、前記通信先端末に送信する送信データ量と、前記上位のアプリケーションで認識される通信アプリケーションのタイプとに応じて、前記トラフィック量を推定するものであってもよい。かかる構成によれば、通信先端末に送信する送信データ量と、上位のアプリケーションで認識される通信アプリケーションのタイプとに応じてトラフィック量を推定することが可能となる。

また、前記トラフィック量推定部は、前記通信先端末に送信する送信データ量に前記通信アプリケーションのタイプに応じて設定された係数を乗算して前記トラフィック量を算出するものであってもよい。かかる構成によれば、通信アプリケーションのタイプに応じて設定された係数に応じて、トラフィック量を算出することが可能となる。

また、前記メディア予約部は、メディアの使用を開始してからのメディア使用時間を管理するメディア使用時間管理部を含み、前記メディア使用時間管理部は、前記メディア使用時間と前記メディア予約時間とを加算して前記メディア使用時間を更新し、前記無線通信ネットワークの負荷状態に応じて、前記メディア予約時間の加算量を調整するものであってもよい。かかる構成によれば、メディア使用時間とメディア予約時間とが加算されてメディア使用時間が更新され、無線通信ネットワークの負荷状態に応じて、メディア予約時間の加算量が調整される。従って、無線通信ネットワークの負荷状態とメディア予約時間に応じてメディア使用時間を調整することができ、メディア確保時間が多い無線通信装置に対して送信契機を抑制することが可能となる。

また、前記メディア使用時間管理部は、前記無線通信ネットワークの負荷状態が大きい場合ほど、前記メディア予約時間の加算量を増加するものであってもよい。かかる構成によれば、メディア使用時間が大きくなった場合に送信抑制をかけるシステムにおいて、無線通信ネットワークの負荷状態が大きい場合ほど、メディア予約時間の加算量が増加されるため、過度にメディアを予約した無線通信装置に対して送信契機を抑制することが可能となる。

また、前記メディア使用時間管理部は、前記メディア予約時間から前記通信先端末が使用したメディア使用時間を差し引いた値を加算して前記メディア使用時間を更新するものであってもよい。かかる構成によれば、通信先端末が使用したメディア使用時間を差し引くことで、自装置のメディア使用時間を精度良く求めることが可能となる。

また、前記メディア使用時間が所定のしきい値を超えた場合に送信契機を抑制する送信契機抑制制御部を備えるものであってもよい。かかる構成によれば、メディア使用時間が所定のしきい値を超えた場合に送信契機を抑制されるため、ネットワーク内の装置に対して均等に送信契機を与えることが可能となる。

また、上記課題を解決するために、本発明の別の観点によれば、送信装置と受信装置とが無線通信ネットワークを介して接続された帯域予約型の無線通信システムであって、前記送信装置は、前記受信装置からの返信データを受信する際のトラフィック量を推定するトラフィック量推定部と、前記トラフィック量に基づいてメディアを予約するメディア予約部と、を備える無線通信システムが提供される。

上記構成によれば、送信装置と受信装置とが無線通信ネットワークを介して接続された帯域予約型の無線通信システムにおいて、送信装置では、通信先端末からの返信データを受信する際のトラフィック量が推定され、トラフィック量に基づいてメディアが予約される。従って、通信先端末からの返信データに応じた必要最小限のメディアを確保することができ、実際に必要なメディア量以上のメディアが確保されてしまうことを抑えることが可能となり、他端末の送信契機が低減してしまうことを確実に抑止できる。

また、上記課題を解決するために、本発明の別の観点によれば、無線通信ネットワークを介して接続された通信先端末との間で通信を行う帯域予約型の無線通信装置における無線通信方法であって、前記通信先端末からの返信データを受信する際のトラフィック量を推定するステップと、前記トラフィック量に基づいてメディアを予約するステップと、を備える無線通信方法が提供される。

上記構成によれば、無線通信ネットワークを介して接続された通信先端末との間で通信を行う帯域予約型の無線通信装置における無線通信方法において、通信先端末からの返信データを受信する際のトラフィック量が推定され、トラフィック量に基づいてメディアが予約される。従って、通信先端末からの返信データに応じた必要最小限のメディアを確保することができ、実際に必要なメディア量以上のメディアが確保されてしまうことを抑えることが可能となり、他端末の送信契機が低減してしまうことを確実に抑止できる。

また、上記課題を解決するために、本発明の別の観点によれば、無線通信ネットワークを介して接続された通信先端末との間で通信を行う帯域予約型の無線通信装置におけるプログラムであって、前記通信先端末からの返信データを受信する際のトラフィック量を推定する手段、前記トラフィック量に基づいてメディアを予約する手段、としてコンピュータを機能させるためのプログラムが提供される。

上記構成によれば、無線通信ネットワークを介して接続された通信先端末との間で通信を行う帯域予約型の無線通信装置におけるプログラムにおいて、通信先端末からの返信データを受信する際のトラフィック量が推定され、トラフィック量に基づいてメディアが予約される。従って、通信先端末からの返信データに応じた必要最小限のメディアを確保することができ、実際に必要なメディア量以上のメディアが確保されてしまうことを抑えることが可能となり、他端末の送信契機が低減してしまうことを確実に抑止できる。

本発明によれば、送信側で必要最小限のメディアを確保することで、ネットワーク内の端末に対して送信契機を均等に割り当てることが可能となる。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

［リバース・ダイレクション・プロトコル(Reverse Direction Protocol)］
先ず、本実施形態の前提として、IEEE 801.11nにおけるリバース・ダイレクション・プロトコルについて詳細に説明する。双方向のデータ転送を行う場合、図１５で説明した処理シーケンスを各々の端末が独立に実行する必要がある。これに対し、IEEE
802.11nで規定されるリバース・ダイレクション・プロトコルでは、上述したメディア確保に必要なプロトコルのオーバーヘッド、パケットの衝突の確率等を低減する目的で、送信側が相手に対してデータ送信を促す仕組みを提供している。

図１は、リバース・ダイレクション・プロトコルによるパケットデータの送受信を示す模式図である。先ず、イニシエータ(Initiator; STA-A)がレスポンダー(Responder; STA-B)へRTSを送信し、CTSを受信することでメディアを確保する。次に、STA-Aがデータパケット(Data to B)をSTA-Bに送信する。このとき、データパケットのヘッダーにはSTA-Bに送信を許可する旨を示すフラグが含まれている。STA-Bの送信を許可するためには、RTS/CTSの送受信の時点で確保したメディアが十分に残っている必要がある。

次に、STA-Bがデータパケットを受信し、ヘッダーに含まれる送信許可フラグを検出し、データパケットを受信したことに対するＡＣＫと、STA-Aへのデータパケット(Data to A)を送信する。なお、ここで送信されるデータパケットをＲＤデータ（リバースダイレクションデータ；RD Data）と称する場合がある。次に、STA-Aは、STA-Bからのデータパケットを受信したことに対するＡＣＫを送信する。次に、STA-Aは、確保したメディアをリリースするための報知パケット（エンドパケット(END)）を送信する。

リバース・ダイレクション・プロトコルでは、STA-AからSTA-Bへの送信データ(Data to B)の中に、STA-BからSTA-Aへのデータ送信を許可することを示すフラグ(RD)がヘッダー中に１ビット入っている。STA-Bは、STA-Aからの送信データ(Data to B)に送信を許可する旨を示すフラグが含まれている場合は、ＡＣＫとともに送信データ(Data to A)をSTA-Aへ送信する。図１５と比較すると、リバース・ダイレクション・プロトコルでは、STA-BからSTA-Aへ送信する際にRTS, CTSを送受信する必要がないため、オーバーヘッド、およびパケット衝突の確率を低減することが可能である。

図２は、リバース・ダイレクション・プロトコルによる処理を行う場合の処理ブロックを示す模式図である。図２に示す処理ブロックは、制御の順序を表す制御パスを示しており、主に端末のＭＡＣ(Media access control)で行われる制御を示している。また、図２に示す構成は、送信側端末であるイニシエータ(Initiator; STA-A)、および受信側端末であるレスポンダー(Responder; STA-B)に共通の構成である。図２に示すように、処理ブロックは、メディア予約部(media reservation)１００、送信データ処理部(Forward Direction Data)１０２、受信データ処理部(Reverse Direction Data)１０４、解除部(Exchange Termination)１０６、送信契機抑制制御部(Admission Control)１０８を有して構成されている。

メディア予約部１００は、RTS、CTSを送受信することでメディアを予約する処理を行う。送信データ処理部１０２は、STA-AからSTA-Bへ送るデータの送受信処理を行うブロックであり、STA-A側では、STA-AからSTA-Bへ送るデータの送信処理を行う。また、STA-B側では、STA-Aから受信したデータの受信処理を行う。

受信データ処理部１０４は、STA-BからSTA-Aへ送るデータの送受信処理を行うブロックであり、STA-A側では、STA-Bから受信したデータの受信処理を行う。また、STA-B側では、STA-BからSTA-Aへ送るデータの送信処理を行う。

解除部１０６は、データの送受信が終了した際にエンドパケット(END Packet)を送る処理を行うブロックである。また、送信契機抑制制御部１０８は、確保したメディア予約時間とメディアを使用した時間を比較して、メディアの使用の可否を判定するブロックである。

図３は、リバース・ダイレクション・プロトコルによる、イニシエータ(STA-A)の処理を示すフローチャートである。図３では、各ステップと図２の各ブロックによる処理とを対応付けて示している。

図３の処理では、先ず、ステップＳ１，Ｓ２において、図２のメディア予約部１００による処理が行われる。ステップＳ１では、STA-AからSTA-BへRTSを送信し、STA-AがSTA-BからCTSを受信することで、RTS/CTSの送受信によりメディアを確保する。次のステップＳ２では、RTS/CTSの送受信により確保したメディア予約時間を現在までのメディア使用時間(Used Time)に積算する処理が行われる。このとき、メディアの予約時間は、以降の処理を行うために十分な長さをとっておく必要がある。

次に、ステップＳ３〜Ｓ９において、図２の送信データ処理部１０２による処理が行われる。ここでは、STA-AからSTA-Bへデータパケット(Data to B)を送信する処理を行う。このとき、データパケット(Data to B)のヘッダーには、STA-Bに送信を許可するか否かを示すフラグ(RD)が含まれている。STA-Bの送信を許可するためには、RTS／CTSを送受信した時点（ステップＳ１）で確保したメディアが十分に残っている必要がある。

具体的には、ステップＳ３において、データパケットを送るためのメディア残量が残っているか否かを判定する。メディア残量がある場合はステップＳ４へ進み、メディア残量がない場合は処理を終了する(RETURN)。

ステップＳ４では、送信するデータパケットが最後のデータであるか否かを判定し、最後のデータでない場合は、ステップＳ５へ進み、データパケット(Data to B)をSTA-Bに送信する(Data TX; なお、“TX”は送信を表す。)。この際、データパケットが最後のデータではないため、続けてデータを送信する必要があり、レスポンダー(STA-B)に送信を許可することはできない。従って、フラグRDは０とされ(RD=0)、STA-Bからの送信は不許可とされる。次のステップＳ６では、STA-BからＡＣＫを受信する。その後、ステップＳ３に戻り、上記の処理を繰り返し行う。一方、ステップＳ４で送信するデータパケットが最後のデータの場合は、レスポンダー(STA-B)に送信を許可するため、ステップＳ７へ進む。ステップＳ７では、レスポンダー(STA-B)に送信を許可するにあたって、メディア残量があるか否かを判定する。

ステップＳ７でメディア残量がある場合は、ステップＳ８へ進み、STA-AからSTA-Bへ最後のデータパケットを送信する(Data TX)。この際、STA-Bに送信を許可するため、データパケットのヘッダー中のフラグRDは1に設定される(RD=1)。次のステップＳ９では、STA-BからＡＣＫを受信する(Rx Ack; なお、“RX”は受信を表す。)。ステップＳ７でメディア残量がない場合は、ステップＳ５へ進む。この場合、ステップＳ５で最後のデータを送信した後、ステップＳ３でメディア残量がないため、処理を終了する(RETURN)。

次に、ステップＳ１０〜Ｓ１２において、図２の受信データ処理部１０４による処理が行われる。ここでは、STA-Bから送られたデータパケット（ＲＤデータ）をSTA-Aが受信する処理を行う。ステップＳ１０では、STA-Bから送られたデータパケットを受信し(Data RX)、次のステップＳ１１では、STA-BへＡＣＫを送信する(ACK TX)。

次のステップＳ１２では、現時点のメディア使用時間(Used Time)からステップＳ１０，Ｓ１１でのＲＤデータの受信時間（ＲＤ時間）を減算する処理を行う(Used Time-=RD Time)。これは、ステップＳ１０におけるデータパケットの受信時間と、ステップＳ１１におけるＡＣＫの送信時間は、STA-Bのメディア使用時間であるためである。

次にステップＳ１３〜Ｓ１５では、図２の解除部１０６によりメディア予約を解除する処理が行われる。先ず、ステップＳ１３では、現時点でメディア予約時間の残量があるか否かを判定し、残量がある場合は、ステップＳ１４でエンドパケットを送信し(Tx END Packet)、残りのリソースを解除する。このエンドパケットの送信により、確保したメディアが解除される。一方、ステップＳ１３でメディア予約時間の残量がない場合は、エンドパケットを送ることなく処理を終了する(RETURN)。ステップＳ１５では、現時点のメディア使用時間からエンドパケットの送信によりキャンセルされた時間を減算する(Used Time-=canceled Time)。ステップＳ１５の後は、処理を終了する(RETURN)。

ステップＳ２でメディア使用時間にメディア予約時間を加算してメディア使用時間を更新した後、ステップＳ１２ではSTA-Bのメディア使用時間が減算され、ステップＳ１５ではキャンセルされた時間が減算されて開放したリソース分が戻される。この結果、イニシエータの処理では、ステップＳ２でメディア予約時間が加算される前のメディア使用時間に対して、ステップＳ３〜Ｓ９の処理時間が加算されて、メディア使用時間が更新される。

また、図３では、上記の処理とともに、送信契機抑制制御部１０８による処理を示している。先ずステップＳ１６では、現在のメディア使用時間が所定のしきい値Thよりも大きいか否かを判定し、メディア使用時間がしきい値Thよりも大きい場合は、ステップＳ１７で送信を抑制する制御を行う。これにより、メディアの使用量が多いステーションに対して、送信を抑制することができる。

また、送信契機抑制制御部１０８では、メディア使用時間をリセットする処理を行う。ここでは、ある観測時間を測定するためタイマーを動作させ、ステップＳ１８において、タイマーの値がリセットの契機となるオブザーブピリオド(observe_period)を超えているか否かを判定する。そして、タイマーの値がオブザーブピリオドを超えている場合は、ステップＳ１９へ進み、メディア使用時間をリセットする。一方、タイマーの値がオブザーブピリオド以下の場合は、ステップＳ１８で待機する。

ステップＳ１９の後はステップＳ２０へ進み、ステップＳ１７で設定した送信抑制を解除する。次のステップＳ２１では、タイマーの時間をリセットして、新たにタイマーを動作させる。

また、図４は、リバース・ダイレクション・プロトコルによる、レスポンダー(STA-B)の処理を示すフローチャートであって、各ステップと図２の各ブロックによる処理とを対応付けて示している。STA-Bの処理では、アイドル状態（ステップＳ３１）からの状態遷移を判定する（ステップＳ３２，Ｓ３３，Ｓ３４）。状態遷移の判定は、RTSを受信したか否か（ステップＳ３２）、データパケットを受信した否か（ステップＳ３３）、エンドパケットを受信したか否か（ステップＳ３４）、の判定により行われる。ステップＳ３２において、STA-AからRTSを受信したことが判定された場合は、ステップＳ３５でCTSを返信し、イニシエータのメディア予約部１００によりメディアの確保が行われる。

ステップＳ３５でメディアを確保した後は、ステップＳ３６へ進む。また、ステップＳ３３において、STA-Aからデータパケットを受信したことが判定された場合は、ステップＳ３６へ進む。

ステップＳ３６〜Ｓ３８では、図２の送信データ処理部１０２による処理が行われる。ここでは、先ず、ステップＳ３６において、STA-Aから送られたデータパケットを受信する処理を行う(Data RX)。次のステップＳ３７では、STA-AへＡＣＫを送信する処理を行う(TX ACK)。次のステップＳ３８では、STA-Aから送られたデータパケットのヘッダーに含まれるフラグRDの状態が１であるか否かを判定する。

ステップＳ３８において、フラグRDの状態が１の場合は、レスポンダーに送信が許可されているため、ステップＳ３９へ進む。ステップＳ３９〜Ｓ４３では、図２の受信データ処理部１０４による処理が行われる。ステップＳ３９では、メディア予約時間の残量があるか否かを判定し、メディア予約時間に残量がある場合は、次のステップＳ４０でデータパケットを送信する(Data TX)。次のステップＳ４１では、ステップＳ４０で送信したパケットデータに対するＡＣＫをSTA-Aから受信する。次のステップＳ４２では、ステップＳ３９〜Ｓ４１の処理でＲＤ時間だけメディアを使用したため、レスポンダーのメディア使用時間(Used Time)にＲＤ時間(RD Time)を加算し、メディア使用時間を更新する(Used Time+=RD Time)。次のステップＳ４３では、フラグRDの状態が１であるか否かを判定する。ステップＳ４３でフラグRDの状態が１の場合は、STA-Bによる送信が許可されているため、ステップＳ３９へ戻り、以降の処理を再度行う。

また、ステップＳ３４において、STA-Aからエンドパケットを受信したことが判定された場合は、ステップＳ４４へ進む。ステップＳ４４では、エンドパケットを受信する処理を行う(RX END Packet)。ステップＳ４４の処理は、図２の解除部１０６によって行われる。ステップＳ３８，Ｓ４３，Ｓ４４の後は、アイドル状態に戻る。

以上説明したようなリバース・ダイレクション・プロトコルでは、レスポンダーがデータを送信する際にRTS/CTSの送受信が行われないため、レスポンダー(STA-B)が必要とするメディアリソース(データの有無、データ量、送信可能レート)をイニシエータ(STA-A)側が把握できないという実装上の問題がある。このため、イニシエータ側でのメディア確保時に、どれだけメディアを確保すべきか判断することができない。そして、確保すべきメディア量が推定できないため、上述のように、実際に使用するメディア量よりも多くのリソースを一旦確保するという事態が生じてしまう。

また、イニシエータ(STA-A)が、レスポンダー(STA-B)に送信するデータレートを自由に設定できないという問題も生じる。メディアを確保するにあたり、イニシエータ(STA-A)は、自身が行うパケット送信に要する時間を推定する必要があり、全パケットを送信するためには、メディア確保(RTS/CTSの送受信)の時点で想定した送信レートを使って送信する必要がある。しかし、伝送路の変動で送信レートを下げる必要性が生じた場合や、伝送路の誤りにより再送の必要が生じた場合など、必要なメディア量が増大する要因を鑑みると、実際に使うメディア量よりも多くのメディアを確保する事態が生じてしまう。

このため、図３のステップＳ１（図４のステップＳ３５）のメディア確保の時点では、確保可能な最大時間、または予め定められた固定時間によりメディアの確保が最大限に行われる。そして、通信後にメディアが余った場合には、エンドパケットを送信して確保したメディアをリリースする手法が行われる。しかしながら、この手法では、必要以上にメディアが確保されるのみならず、エンドパケットを受信できない隠れ端末が発生する問題がある。ネットワーク内でエンドパケットを受信できた端末は、メディアが開放されたことを認識して新たにメディアの確保が可能となる。一方、エンドパケットが受信できなかった隠れ端末は、メディアの使用が終了したことを認識することができないため、メディア予約に参加することができず、メディア予約の公平性を確保することができない。このような、メディアリリース用パケットが受信できない隠れ端末が存在する場合を考慮すると、実際に使用するメディア量にできるだけ近似したメディアの確保をRTS/CTSの送受信の段階で行うことが望ましい。

また、WLANの仕様には、各端末が使用するメディア量を制御（Admission Control）するため、Used Media Timeという時間当たりのメディア使用量を制限する仕組みがある。これは、ある一定量以上のメディアを使用した端末の再度のメディアへのアクセスを抑制するものであり（図３のステップＳ１６〜Ｓ２１）、これによりBSS内端末のメディア利用の公平性を保つものである。この仕様では、実際に使用したメディア量のみの監視が定義されているが、上述のように予約メディアのリリースは完全なものではなく、また、過度なメディア予約はそれ自体が他端末の送信契機を減らす要因になる。このため、実際に使用したメディア使用時間の管理だけでは公平性を保つうえで不十分であり、予約したリソースと実際に使用したリソースに差が生じた場合に、ペナルティが与えられるようなプロトコルを設けることが望ましい。

［本発明の実施形態の説明］
図５は、本発明の一実施形態に係る無線通信ネットワークの構成を示す模式図である。無線通信ネットワークは、端末１０、端末１２、端末１４を備えている。ここで、それぞれの端末１０，１２，１４は、メディア予約(確保)、データ送信、データ受信を行う機能を有する。また、メディア予約した端末をイニシエータ(Initiator)、イニシエータの通信相手の端末をレスポンダー(Responder)と定義する。

図６は、本実施形態に係る無線通信装置（イニシエータ、レスポンダー）の処理ブロックを示す模式図である。本実施形態の無線通信装置は、上述したリバース・ダイレクション・プロトコルを前提として処理を行う。本実施形態の無線通信装置は、ＭＡＣレイヤー、およびＭＡＣレイヤーの上層のアプリケーションであるＴＣＰ／ＩＰレイヤーを備えている。図２に示す構成と同様に、図６では、主にＭＡＣで行われる制御の処理ブロックを模式的に示している。図６に示すように、イニシエータ、およびレスポンダーの処理ブロックは、メディア予約部(Media reservation)１００、送信データ処理部(Forward Direction Data)１０２、受信データ処理部(Reverse Direction Data)１０４、解除部(Exchange Termination)１０６、送信契機抑制制御部(Admission Control)１０８、レート制御部(Rate Control)１１０、バッファ管理部(Buffer statistics)１１２、ＲＤトラフィック量算出部(RD traffic estimate)１１４、メディア算出部(Media estimate)１１６、バッファ管理部(Buffer statistics)１１８を有して構成されている。

図６と図２を比較すると、図６に示す本実施形態の構成では、図２の構成に対して、レート制御部１１０、バッファ管理部１１２、ＲＤトラフィック量算出部１１４、メディア算出部１１６、バッファ管理部１１８の構成が付加されている。

本実施形態において、レート制御部１１０は、メディアを確保する際の送信レートを制御するブロックであり、送信の対象となる端末(レスポンダー)への送信レートの平均値（平均送信レート）を算出する。平均送信レートは、例えば比較的長期に渡って測定された送信レートの平均値を採用することができる。

バッファ管理部１１２はイニシエータ側のバッファを管理する機能ブロックであり、レスポンダーに送信するデータをどれだけ保有しているかを表す統計を管理する。バッファ管理部１１２は、レスポンダーへ送信するデータ量とパケット数（バッファ量）を出力する。また、バッファ管理部１１８はレスポンダー側のバッファを管理する機能ブロックであり、レスポンダーがイニシエータに対してデータを送信する際に、自身のデータ量とパケット数（バッファ量）を算出する機能を有する。バッファ管理部１１８で算出されたレスポンダーのバッファ量は、イニシエータに対して通知される。また、ＲＤトラフィック量算出部１１４は、リバースダイレクションデータ(RD Data)を受信する際のトラフィック量（ＲＤトラフィック量； RD Traffic）を出力する。

メディア算出部１１６は、レート制御部１１０から出力されるメディア予約用の送信レート情報と、バッファ管理部１１２から出力されるバッファ量と、ＲＤトラフィック量算出部１１４から出力されるＲＤトラフィック量を用いて、RTS/CTSの送受信時に確保する必要なメディア量を算出する。そして、決定されたメディア量でRTS/CTSシーケンスが実行される。

送信データ処理部１０２は、図２のシステムと同様に、イニシエータからレスポンダーへのデータ転送処理を行う。このときに使用する送信データレートまたは再送手法は特に限定されるものではなく、独立した別アルゴリズムにて導出される伝送路状態に適したレート、または再送手段を用いることが可能である。

受信データ処理部１０４は、図２のシステムと同様に、レスポンダーからイニシエータへ送信されるデータ（RD Data）の処理を行う。更に、リバースダイレクションを最も効率良く行うために、レスポンダーはイニシエータに対して送信可能なデータ量を通知する機能を有する。データ量の通知は、例えばIEEE 802.11のフレームフォーマットで運用する場合、マックヘッダーのリザーブビット(RESERVE BIT)を使うことにより実現できる。

また、解除部１０６は、図２のシステムと同様の処理を行う。本実施形態では、エンドパケットを使って予約していたメディアを開放した場合には、開放したリソース分をそのまま戻すのではなく、係数alphaで補正した分だけを戻す仕組みとする。この係数alpha (0<alpha<1.0)は、メディアの使用状況（メディアの占有度）、帯域使用状況により調整されるものとし、アクセスポイント(AP)などの中央管理機能がユーザ数、チャネル占有率などから係数alphaの値を制御し、ネットワーク内の各端末１０，１２，１４へ報知する。また、ネットワーク内の端末１０，１２，１４の１つの端末が、ユーザ数、チャネル占有率などから係数alphaの値を制御しても良い。図５では、端末１０がメディアの使用状況を把握し、係数alphaを制御するものとしている。係数alphaの制御において、メディアの使用状況、帯域使用状況が混雑しているほど係数alphaを0に近づける仕組みとする。

以上のように構成された本実施形態のシステムにおいて、ＲＤトラフィック量算出部１１４により、ＲＤトラフィック量を算出する処理が行われる。ＲＤトラフィック量は、メディアの重さを表す指標であり、レスポンダーからＲＤデータが送信される際のトラフィック量を示している。そして、ＲＤトラフィック量が大きいほど、レスポンダーに対して多くのメディアを与えるようにする。これにより、レスポンダーとの通信の際に、通信状況に応じてメディアの確保を最適に行うことが可能となる。ここで、ＲＤトラフィック量は、ＲＤデータ送信時の時間（ＲＤ時間）と、自端末の送信データ量に対する受信データ量の比率を表す値(fact)で表現することができる。

ＲＤトラフィック量算出部１１４によるＲＤトラフィック量を算出は、大きく分けて２通りの手法がある。第１の方法は、レスポンダーからの報告値（ＲＤ要求）に基づいてＲＤトラフィック量の出力値を決定する手法である。この場合、イニシエータは、後述する図１０のステップＳ９４において、リバースダイレクションデータから抽出されたＲＤ要求値に従いＲＤトラフィック量を出力する。

第２の方法は、アプリケーションの補助情報を使ってＲＤトラフィック量を算出する方法である。ここでは、アプリケーションのタイプ(Application Type)に基づいてＲＤトラフィック量を算出する方法と、ＴＣＰ／ＩＰプロトコル使用時にＲＤトラフィック量を導出する方法を想定する。

アプリケーションのタイプからＲＤトラフィック量を導出する方法では、アプリケーションのタイプに応じて、イニシエータから送るデータ量に対する、レスポンダーから送るデータ量を算出する。例えばテレビ電話、ＶｏＩＰなどのインターアクティブ・アプリケーション(Interactive Application)では、自端末の送信データ量と受信データ量がほぼ同等になる。一方、他のアプリケーション・タイプでは、自身の送信データ量に対して所定の係数倍をすることで、受信量を表すことができる。このため、ＲＤトラフィック量算出部１１４は、アプリケーションのタイプに応じて、自端末の送信データ量に対する受信データ量の比を出力する。アプリケーションのタイプは、ＭＡＣ層の上位レイヤーであるＴＣＰ／ＩＰレイヤーから取得することが可能である。

ＴＣＰ／ＩＰプロトコル使用時にトラフィック量を導出する方法では、送信データに対するＴＣＰ＿ＡＣＫを予測して割り当てる。ＴＣＰ＿ＡＣＫの予測は、ＴＣＰバッファ(TCP Buffer)の状態から推測することができ、相手端末のＴＣＰバッファの残り量に応じて、リソースを割り当てる量を可変とする。

具体的には、イニシエータ側でレスポンダーのＴＣＰバッファの残量を監視して、メディア予約、相手端末へのメディアの割り当てを行う。なお、ＴＣＰバッファの動作は、RFC(request for comments)793にて定義される。

図７は、イニシエータのＴＣＰバッファの状態を示す模式図である。図７において、Ａの領域のパケットデータは、レスポンダーへ送信済みであり、レスポンダーからＡＣＫが返信されたパケット領域を示している。Ｂの領域のパケットデータは、レスポンダーへ送信済みで相手からのＡＣＫがまだ返信されていないパケット領域を示している。Ｃの領域は、これから送信可能なパケット領域を示している。Ｄは、プロトコルにより送信不可能とされるパケット領域を示している。イニシエータ自身がパケット送信を行った場合、またはイニシエータがレスポンダーから新たなＡＣＫを受信した場合に、図７に示すＴＣＰバッファの状態の更新処理が行われる。

図７において、Ｂの領域とＣの領域を合わせた領域の容量は、ＴＣＰバッファのウィンドウサイズ(TCP Window Size)である。ここで、Ｃの領域のパケットデータは、これから送信可能なパケット領域であり、レスポンダーのバッファ残量として定義できる。具体的には、レスポンダーのバッファ残量は、ＴＣＰバッファのバッファサイズと、図７の送信済みパケットであるＢ領域との差とすることができ、下記（１）式にて表現することができる。

（１）式において、バッファサイズ(buffsize[i])は、送信相手であるレスポンダーから報告されるＴＣＰバッファのウィンドウサイズに相当し、レスポンダーからのＡＣＫ受信時に更新される。また、Σで表される項は、図７中のパケット＃ｎからパケット＃ｍまでのパケットサイズ(packet_size)の積算値であり、図７中の領域Ｂのパケットデータの容量を示している。

なお、変数ｉは、ＡＣＫが返信される度にバッファサイズが更新されるため、バッファサイズ(buffsize[i])、及びrsize[i]が時間に応じて変動することを示している。上式では、既に送信済みのパケットのサイズを積算した例を示したが、次に送る予定のパケットも含めて計算しても良い。

ここで、ＡＣＫのオーバーヘッドを減らすため、レスポンダー側ではバッファ残量が少なくなった場合にＡＣＫを送信する。従って、バッファ残量が少ない場合ほど、ＡＣＫとともにレスポンダーからデータパケットが送られてくる可能性が高いと判断できる。上式で算出されたrsize[i]は、レスポンダーのＴＣＰバッファ残量に相当するため、レスポンダーのＴＣＰバッファの残量が少なく、rsize[i]の値が小さいほど、ＡＣＫが送信されてくる確率が高くなり、ＲＤトラフィック量が多くなることが判る。このため、本実施形態では、rsize[i]の値が小さい場合ほど、ＲＤデータ送信時のメディアを多く確保して、リバースダイレクションのリソースを確保する処理を行う。

図８は、上式から算出されたrsize[i]の値に応じて、ＲＤトラフィック量算出部１１４の出力を更新する処理を示している。先ず、ステップＳ５１では、（１）式から算出されたrsize[i]が所定のしきい値(thresh)を超えているか否かが判定され、rsize[i]が所定のしきい値を超えている場合は、ステップＳ５２でメディア算出部１１６の出力が０に設定される(Normal Frame Exchange)。この場合、rsizeの値が比較的大きいため、しばらくの間はレスポンダーからＡＣＫが返信されてこないと判断でき、ＲＤトラフィック量が小さいと判断できる。従って、通常のフレーム(Normal
Frame)に設定が行われ、ＲＤ時間が０に設定される。

一方、ステップＳ５１でrsize[i]が所定のしきい値(thresh)以下の場合は、ステップＳ５３へ進み、ＲＤトラフィック量算出部１１４からのＲＤ時間の出力がｘ［ｍｓ］とされる。これにより、レスポンダーによるＲＤデータの返信に対してより多くのメディアが与えられる。

以上のように、図８の処理によれば、rsize[i]の値に応じてＲＤトラフィック量算出部１１４の出力が更新されるため、トラフィック量に応じてメディアを確保することが可能となる。

図９は、ＲＤトラフィック量算出部１１４によるＲＤトラフィック量の算出に際し、上述した第１及び第２の方法を含めた処理を示すフローチャートである。ここで、ステップＳ６１，Ｓ６２の処理は、上述した第１の方法により、レスポンダーからの報告値に基づいてＲＤトラフィック量の出力値を決定する処理である。また、ステップＳ６３〜Ｓ６８の処理は、上述した第２の方法により、アプリケーションのタイプに基づいてＲＤトラフィック量を算出する処理である。更に、ステップＳ６９〜Ｓ７２の処理は、ＴＣＰ／ＩＰプロトコル使用時にＲＤトラフィック量を導出する処理である。

先ず、ステップＳ６１では、ＲＤ要求があるか否かを判定する。ＲＤ要求がある場合は、ステップＳ６２へ進み、ＲＤ時間をＲＤ要求に応じたリクエスト時間(RD_req)に設定し、自端末の送信データ量に対する受信量の比率を表す値(fact)を１．０に設定する。

ステップＳ６１でＲＤ要求がない場合はステップＳ６３へ進み、アプリケーションのタイプがＴＶ／ＶｏＩＰであるか否かを判定し、ＴＶ／ＶｏＩＰの場合はステップＳ６４へ進む。ステップＳ６４では、ＲＤ時間を０に設定し、factを２に設定する。

ステップＳ６３でＴＶ／ＶｏＩＰでない場合はステップＳ６５へ進み、他のアプリケーションのタイプ（Ａｐｐ#１）であるか否かを判定し、Ａｐｐ#１の場合はステップＳ６６へ進む。ステップＳ６６では、ＲＤ時間の値を０に設定し、factをアプリケーションのタイプ（Ａｐｐ#１）に応じた値（＝１．５）に設定する。

ステップＳ６５で他のアプリケーションのタイプ（Ａｐｐ#１）でない場合は、ステップＳ６７へ進む。ステップＳ６７では、更に他のアプリケーションのタイプ（Ａｐｐ#２）であるか否かを判定し、Ａｐｐ#２の場合はステップＳ６８へ進む。ステップＳ６８では、ＲＤ時間を０に設定し、比率(fact)をアプリケーションのタイプ（Ａｐｐ#２）に応じた値（＝１．２５）に設定する。

同様にして各種条件についてＲＤ時間、factの値を設定した後、ステップＳ６９では、ＴＣＰ／ＩＰであるか否かを判定し、ＴＣＰ／ＩＰの場合はステップＳ７０へ進む。ステップＳ７０では、バッファの残量rsize[i]を算出し、ステップＳ７１へ進む。ステップＳ７１以降の処理は、図８で説明した処理と同様である。

ステップＳ７１では、バッファの残量rsize[i]が所定のしきい値(thresh)よりも大きいか否かを判定し、残量がしきい値よりも大きい場合は、ステップＳ７２へ進む。ステップＳ７２では、ＲＤ時間の値を０に設定し、factを１．０に設定する。一方、バッファの残量がしきい値以下の場合は、ステップＳ１３へ進み、ＲＤ時間をｘ［ｍｓ］に設定し、factを１．０に設定する。

以上のようにしてＲＤトラフィック量算出部１１４からＲＤ時間と値(fact)が出力されると、これに基づいてメディア算出部１１６により送信禁止期間(NAV)が設定され、メディア予約部１００によりメディアが予約される。このメディア予約の処理を含めた本実施形態のシステムによる処理を、図１０に基づいて説明する。図１０の処理はイニシエータによる処理を示しており、図３の一部の処理と同様に行われる。

図１０の処理では、ステップＳ８１〜Ｓ８３において、メディア算出部１１６により予約するメディア量の算出が行われる。この際、ＲＤトラフィック量算出部１１４により計算されたＲＤトラフィック量、バッファ管理部１１２で計算された送信データ量、レート制御部１１０により計算された平均送信レートが用いられる。

メディア算出部１１６によるメディア算出では、先ず、ステップＳ８１において、イニシエータによる送信時間Ｆｄの値を算出する。ここでは、送信時間Ｆｄが下式より算出される。
Ｆｄ＝送信データ量／平均送信レート＋レスポンス時間(Response)＋IFS

上式において、レスポンス時間は、送信時のレスポンスに要する時間である。また、IFSはパケットのフレーム間隔時間である。

次のステップＳ８２では、レスポンダーによる送信時間Ｒｄが下式より算出される。
Ｒｄ＝ＲＤ時間(Time)＋（fact-１．０）＊Ｆｄ

ここで、ＲＤ時間、factの値は、上述したように図８、図９の処理により設定される。
図９で説明したように、第１の方法の場合、ＲＤ時間はレスポンダーからの要求値(RD_req)に設定される。また、この場合、fact＝１であるため、送信時間Ｒｄを算出する上式の第２項は０となる。従って、送信時間Ｒｄは、レスポンダーからの要求値に設定される。

また、第２の方法によりアプリケーションのタイプに応じてＲＤ時間を決定した場合は、ＲＤ時間が０であるため、上式の第１項は０となる。また、この場合、比率(fact)が２、１．５、１．２５などの値に設定されるため、送信時間Ｒｄの値は上式の第２項によって決定される。例えば、アプリケーションのタイプがテレビ電話の場合、自端末の送信データ量と受信データ量がほぼ同等になるため、図９のステップＳ６４でfactが２に設定される。従って、上式の第２項により、イニシエータの送信時間Ｆｄとレスポンダーの送信時間Ｒｄが同一に設定される。

次のステップＳ８３では、送信禁止期間(Nav)が下式より算出される。
Nav＝Ｆｄ＋Ｒｄ

ステップＳ８４，Ｓ８５では、メディア予約部１００による処理が行われる。基本的な処理は、図３のステップＳ１，Ｓ２の処理と同様であるが、メディア予約時間はステップＳ３で算出された送信禁止期間(Nav)に設定される。これにより、ＲＤトラフィック量から想定されるメディアの使用量に応じてメディア予約時間を設定することができる。

次のステップＳ８６〜Ｓ９２では、送信データ処理部１０２による処理が行われる。ここでの処理は、基本的に図４のステップＳ３〜Ｓ９の処理と同様である。

次のステップＳ９３〜Ｓ９６では、受信データ処理部１０４による処理が行われる。ここで、ステップＳ９３、ステップＳ９５、ステップＳ９６の処理は、図３のステップＳ１０，Ｓ１１，Ｓ１２の処理と同様である。図１０の処理では、ステップＳ９４において、レスポンダーから受信したデータパケットの中から、ＲＤトラフィック量算出部１１４に対するＲＤ要求を抽出する処理が行われる。抽出されたＲＤ要求は、ＲＤトラフィック量算出部１１４へ送られる。

次に、ステップＳ９７〜Ｓ９９において、解除部１０６による処理が行われる。ここで、ステップＳ９７、ステップＳ９８の処理は、図３のステップＳ１３，Ｓ１４の処理と同様である。図１０の処理では、ステップＳ９９において、解除時間(Canceled Time)に係数alphaを乗算した値をメディア使用時間から減算する(Used Time-=alpha*Canceled Time)。
上述したように、係数alphaはアクセスポイント(AP)、またはネットワーク内の端末から報知され、メディアの使用状況、帯域使用状況が混雑しているほど係数alphaの値は0に近づく。従って、メディアの使用状況が混雑している場合ほど、メディア使用時間からの減算量が少なくなり、メディア使用時間がより大きな値に設定される。

図１０において、送信契機抑制制御部１０８によるステップＳ１０１〜Ｓ１０６の処理は、図３のステップＳ１６〜Ｓ２１の処理と同様である。ここで、ステップＳ９９の処理により、メディアの使用状況が混雑している場合にメディアをキャンセルした場合は、メディア使用時間がより大きな値に設定される。従って、この場合は、ステップＳ１０２における送信抑制にかかり易くなり、メディアの使用状況が混雑している場合にメディアをキャンセルした端末に対して、送信抑制によるペナルティを課すことができる。

図１１は、本実施形態によるレスポンダーの処理を示すフローチャートである。図１１において、ステップＳ１１１〜Ｓ１１９の処理は、図４のステップＳ３１〜Ｓ３９の処理と同様である。図１１の処理では、ステップＳ１１５のメディア確保において、上述したイニシエータ側の処理により、ＲＤトラフィック量を考慮して必要なメディア量が確保される。

図１１の処理では、ステップＳ１２６〜Ｓ１２８において、レスポンダー側のバッファ管理部１１８による処理が行われる。先ず、ステップＳ１２６ではバッファ量を算出し、ステップＳ１２７では平均送信レートを算出する。次のステップＳ１２７では、バッファ量と平均送信レートからレスポンダーからの送信時に必要なメディア時間（ＲＤ要求）を計算する。

そして、ステップＳ１２０では、ステップＳ１２７で計算したメディア時間に基づいて、イニシエータに対してメディアの要求を行うため、パケットデータ中にＲＤ要求を挿入する。次のステップＳ１２１では、ＲＤ要求が挿入されたパケットデータをイニシエータに送信すする。以降のステップＳ１２２〜Ｓ１２５の処理は、図４のステップＳ４１〜Ｓ４４の処理と同様である。

図１２は、IEEE 802.11のフレームフォーマットで運用する場合において、レスポンダーがイニシエータに送信可能なデータ量としてのＲＤ要求を通知する際に、マックヘッダーのリザーブビットを使用した実現方法を示す模式図である。図１２に示すように、レスポンダーから送信されるＡＣＫには、ヘッダーリザーブビットが含まれている。このため、ヘッダーリザーブビットによりイニシエータへ送信するデータの有無、およびデータ量をイニシエータに通知可能である。図１２において、レスポンダーから送信された２つのＡＣＫのうち、最初のＡＣＫにはデータが付加されていない。従って、このＡＣＫのヘッダーリザーブビットには、送信データがない旨の情報が含まれている。また、次に送信されたＡＣＫにはデータが付加されているため、このＡＣＫのヘッダーリザーブビットには、送信データがある旨の情報と、データ量の情報が含まれている。

図１３は、データフォーマットの一例を示す模式図である。具体的には、例えば、IEEE 802.11nのマックヘッダーに定義されるHT-Control Fieldを図１３のように定義することで、レスポンダー（またはイニシエータ）自身のバッファ量(=RD要求)を通知することができる。

図１４は、イニシエータ(STA-A)のＴＣＰ／ＩＰレイヤーとＭＡＣレイヤーとの間のデータの送受信、イニシエータのＭＡＣレイヤーとレスポンダー(STA-B)のＭＡＣレイヤーとの間のワイヤレスのデータ送受信、レスポンダーのＭＡＣレイヤーとＴＣＰ／ＩＰレイヤーとの間のデータの送受信を示す模式図である。

先ず、図１４のステップＳ１３１では、イニシエータのＴＣＰ／ＩＰレイヤーからＭＡＣレイヤーにデータが送信され、ステップＳ１３２では、イニシエータのＭＡＣレイヤーからレスポンダーのＭＡＣレイヤーへワイヤレスでデータが送信される。このとき、イニシエータのＴＣＰ／ＩＰレイヤーでは、バッファの残量が少なくなるまでは、データの中のフラグＲＤは０に設定されない。

レスポンダー側では、ステップＳ１３３において、イニシエータのＭＡＣレイヤーから受信したデータが、レスポンダーのＭＡＣレイヤーからＴＣＰ／ＩＰレイヤーへ送られる。ＴＣＰ／ＩＰレイヤーは、データを受信するとＭＡＣレイヤーへＴＣＰ＿ＡＣＫを送信する（ステップＳ１３４）。

レスポンダーのＭＡＣレイヤーは、イニシエータからのデータのフラグＲＤが１に設定される以前は、レスポンダーにＡＣＫを送ることができないため、レスポンダーのＴＣＰ／ＩＰレイヤーからＭＡＣレイヤーへ送られたＴＣＰ＿ＡＣＫは、レスポンダーのＭＡＣレイヤーに蓄積された状態となる。

イニシエータ側では、データ送信によりＴＣＰバッファの残量が少なくなった場合は、ステップＳ１３５において、レスポンダーへ送るデータ中のフラグＲＤを１に設定してレスポンダーへデータを送る。レスポンダーは、フラグＲＤ＝１のデータ送信を受けて、ステップＳ１３６において、ＭＡＣレイヤーに蓄積されたＴＣＰ＿ＡＣＫをイニシエータに送信する。

イニシエータのＭＡＣレイヤーがＴＣＰ＿ＡＣＫを受信した時点では、ＴＣＰ／ＩＰレイヤーがＴＣＰ＿ＡＣＫを認識していないため、ステップＳ１３７では、ＲＤ＝１の状態のままレスポンダーへのデータ送信が行われる。ＴＣＰ／ＩＰレイヤーがＴＣＰ＿ＡＣＫを認識すると、フラグＲＤが０に設定されて、ステップＳ１３１と同様にレスポンダーへのデータ送信が行われる（Ｓ１３８）。

なお、ステップＳ１３９で示すように、レスポンダーが受信したデータのフラグＲＤが０の場合であっても、コンディションによってはＴＣＰ＿ＡＣＫがイニシエータに返信される場合がある。

以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

リバース・ダイレクション・プロトコルによるパケットデータの送受信を示す模式図である。 リバース・ダイレクション・プロトコルによる処理を行う場合の処理ブロックを示す模式図である。 リバース・ダイレクション・プロトコルによる、イニシエータ(STA-A)の処理を示すフローチャートである。 リバース・ダイレクション・プロトコルによる、レスポンダー(STA-B)の処理を示すフローチャートである。 本発明の一実施形態に係る無線通信ネットワークの構成を示す模式図である。 本発明の一実施形態に係るイニシエータ、レスポンダーの処理ブロックを示す模式図である。 イニシエータのＴＣＰバッファの状態を示す模式図である。 rsize[i]の値に応じて、メディア算出部の出力を更新する処理を示すフローチャートである。 ＲＤトラフィック量算出部によるＲＤトラフィック量の算出に際し、１及び第２の方法を含めた処理を示すフローチャートである。 本発明の一実施形態によるイニシエータの処理を示すフローチャートである。 本発明の一実施形態によるレスポンダーの処理を示すフローチャートである。 IEEE802.11のフレームフォーマットで運用する場合において、レスポンダーがイニシエータに送信可能なデータ量としてのＲＤ要求を通知する際に、マックヘッダーのリザーブビットを使用した実現方法を示す模式図である。 データフォーマットの一例を示す模式図である。 イニシエータのＴＣＰ／ＩＰレイヤーとＭＡＣレイヤーとの間のデータの送受信、イニシエータとレスポンダーとの間のデータの送受信、レスポンダーのＭＡＣレイヤーとＴＣＰ／ＩＰレイヤーとの間のデータの送受信を示す模式図である。 ＣＳＭＡ／ＣＳ方式でデータの送受信が行われる様子を示すタイミングチャートである。

符号の説明

１００ メディア予約部
１０８ 送信契機抑制制御部
１１０ レート制御部
１１２ バッファ管理部
１１４ ＲＤトラフィック量算出部
１１６ メディア算出部

Claims (16)

1. 無線通信ネットワークを介して接続された通信先端末との間で通信を行う帯域予約型の無線通信装置であって、
   前記通信先端末からの返信データを受信する際のトラフィック量を推定するトラフィック量推定部と、
   前記トラフィック量に基づいてメディアを予約するメディア予約部と、
   を備えることを特徴とする、無線通信装置。
2. 前記通信先端末へ送信する送信データ量を算出する送信データ量算出部と、
   送信時の平均送信レートを算出する平均送信レート算出部と、
   前記トラフィック量、前記送信データ量、及び前記平均送信レートに基づいて、メディア予約時間を算出するメディア算出部と、を備え、
   前記メディア予約部は、前記メディア算出部で算出されたメディア予約時間に基づいてメディアを予約することを特徴とする、請求項１に記載の無線通信装置。
3. 前記通信先端末へのデータ送信に対して返信されたＡＣＫとともに前記通信先端末からの返信データを受信することを特徴とする、請求項１に記載の無線通信装置。
4. 前記トラフィック量推定部は、前記通信先端末が送信する要求値に基づいて前記トラフィック量を推定することを特徴とする、請求項１に記載の無線通信装置。
5. 前記トラフィック量推定部は、ＭＡＣレイヤーよりも上位のアプリケーションから通知される情報に基づいて前記トラフィック量を推定することを特徴とする、請求項１に記載の無線通信装置。
6. 前記上位のアプリケーションはＴＣＰレイヤーであり、前記トラフィック量推定部は、前記通信先端末のＴＣＰバッファの残量に基づいて前記トラフィック量を推定することを特徴とする、請求項５に記載の無線通信装置。
7. 前記トラフィック量推定部は、前記通信先端末のＴＣＰバッファのウィンドウサイズと、前記通信先端末に対して送信済みであり且つＡＣＫが返信されていない送信データ量との差分から前記ＴＣＰバッファの残量を算出することを特徴とする、請求項６に記載の無線通信装置。
8. 前記トラフィック量推定部は、前記通信先端末に送信する送信データ量と、前記上位のアプリケーションで認識される通信アプリケーションのタイプとに応じて、前記トラフィック量を推定することを特徴とする、請求項５に記載の無線通信装置。
9. 前記トラフィック量推定部は、前記通信先端末に送信する送信データ量に前記通信アプリケーションのタイプに応じて設定された係数を乗算して前記トラフィック量を算出することを特徴とする、請求項８に記載の無線通信装置。
10. 前記メディア予約部は、メディアの使用を開始してからのメディア使用時間を管理するメディア使用時間管理部を含み、
    前記メディア使用時間管理部は、
    前記メディア使用時間と前記メディア予約時間とを加算して前記メディア使用時間を更新し、
    前記無線通信ネットワークの負荷状態に応じて、前記メディア予約時間の加算量を調整することを特徴とする、請求項２に記載の無線通信装置。
11. 前記メディア使用時間管理部は、前記無線通信ネットワークの負荷状態が大きい場合ほど、前記メディア予約時間の加算量を増加することを特徴とする、請求項１０に記載の無線通信装置。
12. 前記メディア使用時間管理部は、
    前記メディア予約時間から前記通信先端末が使用したメディア使用時間を差し引いた値を加算して前記メディア使用時間を更新することを特徴とする、請求項１０に記載の無線通信装置。
13. 前記メディア使用時間が所定のしきい値を超えた場合に送信契機を抑制する送信契機抑制制御部を備えることを特徴とする、請求項１０に記載の無線通信装置。
14. 送信装置と受信装置とが無線通信ネットワークを介して接続された帯域予約型の無線通信システムであって、
    前記送信装置は、
    前記受信装置からの返信データを受信する際のトラフィック量を推定するトラフィック量推定部と、
    前記トラフィック量に基づいてメディアを予約するメディア予約部と、
    を備えることを特徴とする、無線通信システム。
15. 無線通信ネットワークを介して接続された通信先端末との間で通信を行う帯域予約型の無線通信装置における無線通信方法であって、
    前記通信先端末からの返信データを受信する際のトラフィック量を推定するステップと、
    前記トラフィック量に基づいてメディアを予約するステップと、
    を備えることを特徴とする、無線通信方法。
16. 無線通信ネットワークを介して接続された通信先端末との間で通信を行う帯域予約型の無線通信装置におけるプログラムであって、
    前記通信先端末からの返信データを受信する際のトラフィック量を推定する手段、
    前記トラフィック量に基づいてメディアを予約する手段、
    としてコンピュータを機能させるためのプログラム。

Images