(57)【要約】【課題】アドホックネットワークに適した無線リソースの割り当てが無い。【解決手段】無線通信装置として、（ａ）トラフィック別にデータ到着レートを求める到着レート演算部と、（ｂ）求められたデータ到着レートに基づいて、各トラフィックに対応する無線リソースの割り当て量を自律的に制御する無線リソース制御部とを有するものを提案する。これにより、各トラフィックに必要な無線リソースを自律的に確保できる。結果として、遅延とジッターの影響を極力無くすことができる。【選択図】図３
2006020069.tif 000002
【特許請求の範囲】
【請求項１】
トラフィック別のデータ到着レートに基づいて、各トラフィックに対応する無線リソースの割り当て量を自律的に制御する
ことを特徴とする無線通信方法。
【請求項２】
請求項１に記載の無線通信方法において、
前記トラフィックのデータ到着レートは、サービスクラス別に求める
ことを特徴とする無線通信方法。
【請求項３】
請求項１に記載の無線通信方法において、
前記制御では、トラフィック別のデータ到着レートに基づいて割り当て量の基準値を決定し、トラフィック別の残存パケット長と残存無線リソース量を用いて基準値を修正する
ことを特徴とする無線通信方法。
【請求項４】
請求項３に記載の無線通信方法において、
前記修正は、トラフィック別の残存パケット長に応じた割り当て量の増加と、残存無線リソース量に応じた割り当て量の削減とにより行う
ことを特徴とする無線通信方法。
【請求項５】
トラフィック別にデータ到着レートを求める到着レート演算部と、
求められたデータ到着レートに基づいて、各トラフィックに対応する無線リソースの割り当て量を自律的に制御する無線リソース制御部と
を有することを特徴とする無線通信装置。
【請求項６】
請求項５に記載の無線通信装置において、
前記トラフィックのデータ到着レートは、サービスクラス別に求める
ことを特徴とする無線通信装置。
【請求項７】
請求項５に記載の無線通信装置において、
前記制御では、トラフィック別のデータ到着レートに基づいて割り当て量の基準値を決定し、トラフィック別の残存パケット長と残存無線リソース量を用いて基準値を修正する
ことを特徴とする無線通信装置。
【請求項８】
請求項７に記載の無線通信装置において、
前記修正は、トラフィック別の残存パケット長に応じた割り当て量の増加と、残存無線リソース量に応じた割り当て量の削減とにより行う
ことを特徴とする無線通信装置。
【請求項９】
無線通信装置に搭載されるコンピュータに、
トラフィック別のデータ到着レートに基づいて、各トラフィックに対応する無線リソースの割り当て量を自律的に制御する処理を実行させる
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
１つの発明は、無線ネットワークを構成する無線通信装置に関する。無線通信装置は、半導体チップ、処理ボード、通信カード、アダプタその他の回路デバイスとして実現される他、当該回路デバイスを搭載又は装着可能な電子機器としても実現される。
また、この発明は、無線通信方法としても実現される。また、この発明は、無線通信方法を実現するプログラムとしても実現される。
【背景技術】
【０００２】
今日、無線ネットワークの普及が急速に進んでいる。これに伴い、動画データや音声データの送信機会が増えている。このため、これらデータの性質に応じたＱｏＳ（Quality of Service）制御技術の確立が求められている。なお、既存のＱｏＳ制御技術の大半は、通信経路に沿って無線リソースを事前に確保する方式を採用する。
ところが、無線ネットワークの場合、フェージングや隠れ端末などの影響により、通信状態が絶えず変化する。このため、単位時間あたりに伝送可能なデータ量や通信経路が頻繁に変化する。このように不安定な無線環境下では、有線ネットワークで用いるような資源予約型のＱｏＳ制御技術はうまく機能しない。
現在、かかる無線ネットワークに適したＱｏＳ制御技術の一つに、ＩＥＥＥ802.11e がある。ＩＥＥＥ802.11e は、２つのＱｏＳ制御技術を採用する。一つは、ＥＤＣＡ（Enhanced
Distributed Channel Access ）であり、一つはＨＣＣＡ（HCF Controlled Channel Access）である。
このＩＥＥＥ802.11e は、「どのように無線リソースを要求するか」という手法については規定するが、「どのくらいの無線リソースを割り当てるか」という手法については規定していない。
このため、具体的なＱｏＳ制御技術については、従来より様々な提案が行われている。例えば、特許文献１がある。特許文献１には、各端末に対する通信回線の割り当て順序を決定し、その順序に従って通信回線（無線リソース）の割り当てを決定する手法が開示されている。
【特許文献１】特開２００２−１１２３２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかし、特許文献１は、アクセスポイントその他の特定装置が、“通信回線”を集中管理する手法を採用する。このため、集中管理方式を採用しない無線ネットワークには適応することができない。また、集中管理方式の場合、管理できる“通信回線”は、アクセスポイントと通信可能な範囲に限られる。
【課題を解決するための手段】
【０００４】
本発明者は以上の事実認識に基づき、以下の通信方法を提案する。
すなわち、トラフィック別のデータ到着レートに基づいて、各トラフィックに対応する無線リソースの割り当て量を自律的に制御する無線通信方法を提案する。これにより、各トラフィックに必要な無線リソースを自律的に確保できる。結果として、遅延とジッターの影響を極力無くすことができる。
ここでの「トラフィック」には、最終的な宛先が同じ場合のみならず、同じ中継先をもつトラフィックを一体として扱う場合も含めることができる。
なお、トラフィック別のデータ到着レートは、サービスクラス別に求めることが望ましい。サービスクラス別に無線リソースの割り当て量を制御することにより、クラス別のアクセス制御を実現できる。
また、制御では、トラフィック別のデータ到着レートに基づいて割り当て量の基準値を決定し、トラフィック別の残存パケット長と残存無線リソース量を用いて基準値を修正することが望ましい。
ここで、トラフィック別の残存パケット長は割り当て量の増加に用い、残存無線リソース量は割り当て量の削減に用いるのが望ましい。
【発明の効果】
【０００５】
発明に係る通信手法の採用により、各トラフィックに必要な無線リソースの確保を、各無線通信装置において自律的に実現できる。
【発明を実施するための最良の形態】
【０００６】
以下、発明に係る通信手法を採用する通信装置の実施形態例を説明する。
なお、本明細書で特に図示又は記載されない部分には、当該技術分野の周知又は公知技術を適用する。
また以下に説明する実施形態は、発明の一つの実施形態であって、これらに限定されるものではない。
【０００７】
（１）通信方式の概要
以下、アドホックネットワークについて説明する。アドホックネットワークは、アクセスポイントを必要としない無線通信装置（以下、「ノード」という。）のみで構成される無線ネットワークをいう。
アドホックネットワークのＭＡＣ（Media Access Control）層には、２種類のビーコンが規定されている。通常のビーコン（以下、「正規ビーコン」という。）と、追加のビーコン（以下、「補助ビーコン」という。）との２つである。
ビーコンは、無線デバイスのアベイラビリティと存在を通知するパケットである。
正規ビーコンは、アドホックネットワークを構成する各ノードが１つ送信するビーコンをいう。
一方、補助ビーコンは、周囲のノードよりも優先的にデータを送信できる権利を取得したノードが、正規ビーコンとは別に送信するビーコンをいう。
図１（Ａ）に、ノードＡ、Ｂ、Ｃに対応する正規ビーコン１の配置例を示す。また、図１（Ｂ）に、ノードＡが補助ビーコン３を１つ追加的に送信する場合の配置例を示す。
補助ビーコンの送信タイミングは、他のビーコンの送信期間と衝突しないように各ノードが自律的に調停する。なお、データは、各ビーコンの送信から一定期間内に任意のタイミングで送信される。
補助ビーコン３を取得したノードは、補助ビーコンの送信から一定時間、他のノードに優先してデータを送信できる。この期間３Ａを、ＴＧＰ（Transmission Guarantee Period）区間と呼ぶ。なお、このＴＧＰ区間は、ＴＰＰ（Transmission Prioritized Period）区間とも呼ばれる。
他方、ＴＧＰ区間以外の期間３Ｂは、ＦＡＰ（Fairness Access
Period ）区間と呼ぶ。ＦＡＰ区間では、各ノードがＣＳＭＡ（正確にはＰＳＭＡ）を用いて公平に送信機会を競う。
【０００８】
本実施形態では、補助ビーコンの送信によって得られるＴＧＰ区間を利用して優先度の高いデータを送信する。
なお、ＱｏＳ制御をユーザ又はアプリケーションに提供するには、補助ビーコンをいくつ割り当てるかを決める機構や、ＴＧＰ区間にどのような順番でパケットを送出するかを決定する機構などが必要となる。
以下、これら機構の実施例を説明する。もっとも、実施例では、狭義のＱｏＳ（帯域予約などを伴う絶対的な優先制御）は提供しない。すなわち、伝送帯域、遅延、ジッター（遅延揺らぎ）などは保証しない。
代わりに、以下の実施例は、ＣｏＳ（Class of Service ）と呼ばれる相対的な優先制御を提供する。これは優先クラスに分類されたトラフィックに対し、非優先クラスよりも相対的に高品質なサービスを提供するものである。
以下の実施例では、２種類のクラスを用意する場合について説明する。２種類のクラスは、優先クラス（ＴＧＰクラス）と、非優先クラス（ＦＡＰクラス）の２つである。
優先クラスとは、ＴＧＰ区間を用いて優先的に送信されるクラスをいう。
一方、非優先クラスとは、ＦＧＰ区間を用いて送信機会が公平に与えられるクラスをいう。非優先クラスは、優先度が指定されていない場合に用いられる。
これら２種類のクラスを用い、サービス品質の保証はしないが、なるべく低遅延で低ジッターのデータ伝送が可能な伝送帯域を確保する手法を提案する。また、ＣｏＳ制御を自律分散的に実現する手法を提案する。
【０００９】
（２）ノード構成
図２に、アドホックネットワークを構成する各ノードの構成例を示す。ノード１１は、ルーティング部１３、クラス分け部１５、出力待ちキュー１７、パケットスケジューラ１９、ＱｏＳ管理部２１、トークン生成部２３、補助ビーコン管理部２５を主要モジュールとして有する。
ルーティング部１３は、パケットのルーティングを実行するデバイスである。ルーティング経路は３つである。
１つは、上位層（アプリケーション）１１Ａから入力されたパケットを隣接ノードに出力する経路である。１つは、隣接ノードから受信したパケットを上位層（アプリケーション）１１Ａに出力する経路である。１つは、隣接ノードから受信したパケットを他の隣接ノードに転送する経路である。なお、隣接ノードとは、ビーコンが届く範囲のノードをいう。
いずれの場合も、ルーティング部１３に届く以前にパケットが所属するクラス（ＦＡＰクラスかＴＧＰクラス）が指定されている。
ルーティング部１３は、転送先となる隣接ノード（ホップ先）が決まると、パケットをクラス分け部１５に出力する。
クラス分け部１５は、パケットを対応する出力待ちキュー１７に振り分けるデバイスである。この他、クラス分け部１５は、ＴＧＰクラスのトラフィックについて転送先別（ホップ先別）にデータ到着レート等の計測にも使用される。計測された各種統計値は、ＱｏＳ管理部２１の参照対象となる。
【００１０】
出力待ちキュー１７は、転送先別(ホップ先別)及びクラス別に用意したキューの集合である。図２の場合、ＴＧＰクラス用及びＦＡＰクラス用のそれぞれについて、各Ｎ個のキューが転送先別に用意されている。
なお、用意したＮ個のキューに対して隣接ノードの数が少ない場合、一部のキューは使用されない。
パケットスケジューラ１９は、各キューからパケットを取り出して送信するデバイスである。具体的には、物理層に出力される。
パケットスケジューラ１９は、送出レートを平滑化するため、トークンバケット法を採用する。すなわち、パケットスケジューラ１９は、一定速度で生成されるトークンをトークンバケットに溜めておき、溜まっているトークンの量だけパケットを送信する手法を採用する。
なお、パケットスケジューラ１９は、パケットの送信後、送信した分だけトークンバケット内のトークンを減らす。
ＱｏＳ管理部２１は、クラス分け部１５で計測されたトラフィック到着レートその他の値を用いて、取得する補助ビーコン数を決定し、補助ビーコン管理部２５に通知するデバイスである。
また、ＱｏＳ管理部２１は、ＴＧＰクラスの各キューに対応するトークンレートを決定し、トークン生成部２３に通知する。ここで、トークンレートとは、トークンバケットに溜めるトークンの生成スピードをいう。
トークン生成部２３は、各キュー別に指定されたトークンレートでトークンを生成するデバイスである。生成されたトークンは、各キューに対応して用意されたトークンバケットに溜められる。
補助ビーコン管理部２５は、ＱｏＳ管理部２１の決定した数の補助ビーコンを確保するデバイスである。補助ビーコンが不足する場合、補助ビーコン管理部２５は、可能な限り必要な数の補助ビーコンの取得を試みる。ただし、補助ビーコン管理部２５は、不足が生じても特に例外処理などは行わない。
以上、ＱｏＳ管理部２１、トークン生成部２３、補助ビーコン管理部２５の３つが、無線リソース制御部としての機能を提供する。すなわち、データ到着レートに基づいて、各トラフィックの伝送に必要なだけの補助ビーコンを自律的に獲得する機能を提供する。
【００１１】
（３）各部の処理内容
続いて、各モジュールで実行される具体的な処理内容を詳述する。ただし、ルーティング部１３の処理内容は既存の技術であるので説明を省略する。
（ａ）クラス分け部の処理
ルーティング処理の終わったパケットは、クラス分け部１５に渡される。クラス分け部１５は、ヘッダ情報に含まれる優先度（クラス）と、転送先となる隣接ノードのアドレスに基づいて、隣接ノード数×２個だけ用意されたキューにパケットを振り分ける。図２の場合、隣接ノード数はＮ（Ｎは自然数）である。
クラス分け部１５には、ＭＡＣ層で保持できる最大パケット数を超えるパケットが流入する場合、そのパケットを廃棄する機構が設けられている。この方式を、Tail Drop 方式という。
なお、ＭＡＣ層が確保するバッファの大半が一方のクラスのトラフィックで占有されると、他方のクラスのトラフィックがほとんど流れないという問題が発生する。
クラス分け部１５には、この問題を避けるための機能も設けられている。すなわち、クラス分け部１５には、両クラスのパケットを振り分ける(Enqueueする)際に、クラス別の最大パケット数を超えないか否かをチェックする機能が設けられている。
クラス別の最大パケット数を超える場合、クラス分け部１５は、パケットを廃棄する。なお、クラス別の最大パケット数は、ＱｏＳ管理部２１から与えられる。
【００１２】
図３に、この処理機能を実現する処理手順例を示す。
まず、クラス分け部１５は、入力パケットが、優先パケットか非優先パケットかを判断する（プロセスＰ１）。すなわち、クラス分け部１５は、入力パケットがＴＧＰクラスのパケット（ＴＧＰパケット）かＦＡＰクラスのパケット（ＦＡＰパケット）かを判断する。
まず、プロセスＰ１で否定結果が得られた場合を説明する。
ＦＡＰパケットであった場合、クラス分け部１５は、出力待ちキュー１７に入っている総てのパケット数と閾値ＬｉｍＢＵＦとを比較する（プロセスＰ２）。ここで、閾値ＬｉｍＢＵＦは、各ノードが保持可能なパケットバッファ数の限界値（定数）である。
総パケット数が閾値ＬｉｍＢＵＦ以上のとき、クラス分け部１５は、入力パケットを廃棄する（プロセスＰ３）。
廃棄後、クラス分け部１５はプロセスＰ１に戻り、次の入力パケットについて前述した判断を開始する。
一方、総パケット数が閾値ＬｉｍＢＵＦ未満のとき、クラス分け部１５は、ＦＡＰパケットの総数が閾値ＬｉｍＦＡＰと比較する（プロセスＰ４）。ここで、閾値ＬｉｍＦＡＰは、ＦＡＰパケットの上限数（変数）である。閾値ＬｉｍＦＡＰは、ＱｏＳ管理部２１から与えられる。
ＦＡＰパケットの総数が閾値ＬｉｍＦＡＰ以上のとき、クラス分け部１５は、入力パケットを廃棄する（プロセスＰ３）。
一方、ＦＡＰパケットの総数が閾値ＬｉｍＦＡＰ未満のとき、クラス分け部１５は、入力パケットを対応するキューの最後に追加する（プロセスＰ５）。
【００１３】
次に、プロセスＰ１で肯定結果が得られた場合を説明する。
ＴＧＰパケットであった場合も、クラス分け部１５は、出力待ちキュー１７に入っている総てのパケット数と閾値ＬｉｍＢＵＦとを比較する（プロセスＰ６）。総パケット数が閾値ＬｉｍＢＵＦ以上のとき、クラス分け部１５は、入力パケットを廃棄する（プロセスＰ７）。廃棄後、次の入力パケットについて前述した判断を開始する。
一方、総パケット数が閾値ＬｉｍＢＵＦ未満のとき、クラス分け部１５は、ＴＧＰパケットの総数が閾値ＬｉｍＴＧＰと比較する（プロセスＰ８）。ここで、閾値ＬｉｍＴＧＰは、ＴＧＰパケットの上限数（定数）である。閾値ＬｉｍＴＧＰは、ＱｏＳ管理部２１から与えられる。
ＴＧＰパケットの総数が閾値ＬｉｍＴＧＰ以上のとき、クラス分け部１５は、入力パケットを廃棄する（プロセスＰ７）。
一方、ＴＧＰパケットの総数が閾値ＬｉｍＴＧＰ未満のとき、クラス分け部１５は、入力パケットを対応するキューの最後に追加する（プロセスＰ９）。この後、クラス分け部１５は、最大蓄積パケット数Ｎ＿ＰＲＩを更新すると共に（プロセスＰ１０）、データ到着レートを更新する（プロセスＰ１１）。
ここで、最大蓄積パケット数Ｎ＿ＰＲＩとは、一定期間内におけるキュー内のＴＧＰパケットの最大値をいう。この例の場合、一定期間を１スーパーフレームとする。
また、データ到着レートとは、ある一定期間内に到着したＴＧＰパケットの合計バイト数をいう。この例の場合、一定期間を１スーパーフレームとする。
なお、最大蓄積パケット数Ｎ＿ＰＲＩ及びデータ到着レートは、ＴＧＰクラスのキューに書き込まれたＴＧＰパケットについて求める。
【００１４】
（ｂ）ＱｏＳ管理部の処理
ＱｏＳ管理部２１では、補助ビーコン数ＢＮ、トークン生成レートＴＲ、クラス別の最大パケット数ＬｉｍＦＡＰ、ＬｉｍＴＧＰが計算される。計算に必要な情報は、データ到着レート、最大蓄積パケット数Ｎ＿ＰＲＩ、その時点での実効転送速度の３つである。
これらの情報は、クラス分け部１５から定期的に取り込まれる。この実施例の場合、これらの情報は、１スーパーフレーム毎に取得される。
なお、生成された補助ビーコン数ＢＮは、補助ビーコン管理部２５で使用される。また、生成されたトークン生成レートＴＲは、トークン生成部２３で使用される。また、最大パケット数ＬｉｍＦＡＰ、ＬｉｍＴＧＰは、クラス分け部１５で使用される。
次に、これら各値の計算例を示す。
まず、最大パケット数ＬｉｍＦＡＰ、ＬｉｍＴＧＰの計算例を示す。
ＬｉｍＦＡＰ＝ＬｉｍＢＵＦ−Ｎ＿ＰＲＩ−Ｎ＿ＳＵＲＰＬＵＳ
ＬｉｍＴＧＰ＝ＬｉｍＢＵＦ−Ｎ＿ＭＩＮ
ここで、ＬｉｍＦＡＰは、取り込み可能なＦＡＰパケットの最大パケット数である。
ＬｉｍＢＵＦは、各ノードが保持できる最大パケット数である。
Ｎ＿ＰＲＩは、ＴＧＰパケットの最大蓄積パケット数である。Ｎ＿ＰＲＩは、初期化時（起動時）に定数として与えられ、その値が保持される。
Ｎ＿ＳＵＲＰＬＵＳは、ＴＧＰパケットの増加を吸収するためのパケットバッファ数である。
ＬｉｍＴＧＰは、取り込み可能なＴＧＰパケットの最大パケット数である。
Ｎ＿ＭＩＮは、ＦＡＰパケット用に最低限確保すべきパケットバッファ数である。
なお、この例の場合、平滑処理後の最大蓄積パケット数Ｎ＿ＰＲＩを計算に使用する。
【００１５】
次に、補助ビーコン数ＢＮとトークン生成レートＴＲの計算例を示す。
基本的には、これらの値は、トラフィックのデータ到着レートＡＲに比例し、実効転送速度に反比例するように算出する。
ただし、この実施例では、パケットやトークンの滞留が発生しないように、出力待ちキュー１７に残存するバイト数（残パケット長）やトークンバケットに残っているトークン量も計算に用いる。トークンの残量は、残存無線リソースを与える値として用いられる。
すなわち、残パケット長に応じて補助ビーコン数とトークンレートを大きくする修正を加える。また、残存するトークン量（残トークン量）に応じてトークンレートを小さくする修正を加える。
なお、残パケット長やトークン量をそのまま用いると、修正量が大きくなりすぎる場合がある。このため、実施例では、残パケット長とトークン量をそれぞれ４分の１に演算したものを修正に使用する。
従って、実施例におけるトークンレートＴＲの計算式は次式となる。
ＴＲ＝ＡＲ＋（残パケット長−残トークン量）/４
また、実施例における補助ビーコン数ＢＮの計算式は次式となる。本実施例では、補助ビーコン数ＢＮの計算時に、残パケット数を２分の１に修正したものを使用する。
ＢＮ＝（ＡＲ＋残パケット長/２）÷（補助ビーコン１つ当たりの転送可能バイト数）
【００１６】
図４に、この処理機能を実現する処理手順例を示す。
まず、ＱｏＳ管理部２１が、クラス分け部１５からトラフィックのデータ到着レートＡＲを取得する（プロセスＰ２１）。
この実施例の場合、ＱｏＳ管理部２１は、取得したデータ到着レートＡＲを平滑化する。ＱｏＳ管理部２１は、平滑化したデータ到着レートＡＲを取り込み、トークンレートＴＲの仮の値に設定する（プロセスＰ２２）。
次に、ＱｏＳ管理部２１は、優先トラフィック用の出力待ちキューにパケットが残存しているか否かを判定する（プロセスＰ２３）。
パケットが残存していた場合、ＱｏＳ管理部２１は、残パケット長の４分の１をトークンレートＴＲに加算する（プロセスＰ２４）。この加算処理により、修正前に比べてトークンレートＴＲの値が大きくなる。トークンレートＴＲが大きくなることで、ＴＧＰパケットの送信が促進される。
この加算処理が終了すると又はパケットが無かった場合、ＱｏＳ管理部２１は、トークンバケットにトークンが残存しているか否かを判定する（プロセスＰ２５）。
トークンが残存していなかった場合、ＱｏＳ管理部２１は、残トークン量の４分の１をトークンレートＴＲから減算する（プロセスＰ２６）。この減算処理により、修正前に比べてトークンレートＴＲの値が小さくなる。トークンレートＴＲが小さくなることで、トークンの過剰蓄積が抑制される。
この減算処理が終了すると又はトークンが無かった場合、ＱｏＳ管理部２１は、決定したトークンレートＴＲをトークン生成部２３に通知する（プロセスＰ２７）。
【００１７】
続いて、ＱｏＳ管理部２１は、現在の通信速度（実効転送速度）を取得し、補助ビーコン１つ当たりの転送可能バイト数ＴＢを計算する（プロセスＰ２８）。
次に、ＱｏＳ管理部２１は、データ到着レートＡＲをトークンレートＴＲで割り、必要な補助ビーコン数ＢＮを求める（プロセスＰ２９）。
かかる後、ＱｏＳ管理部２１は、優先トラフィック用の出力待ちキュー１７にパケットが残存しているか否かを判定する（プロセスＰ３０）。
パケットが残存していた場合、ＱｏＳ管理部２１は、残パケット長の２分の１を補助ビーコン１つ当たりの転送可能バイト数ＴＢで割り、その送信に必要な補助ビーコン数を求める。ＱｏＳ管理部２１は、算出された補助ビーコン数をプロセスＰ２９で算出された補助ビーコン数ＢＭに加算する（プロセスＰ３１）。
この加算処理が終了すると又はパケットが無かった場合、ＱｏＳ管理部２１は、補助ビーコン数ＢＭをビーコン管理部２５に通知する（プロセスＰ２７）。
【００１８】
（ｃ）トークン生成部とパケットスケジューラの処理
トークン生成部２３では、ＱｏＳ管理部２１が決定したトークンレートＴＲに従ってトークンが生成され、対応するトークンバケットに追加される。実施例の場合、トークン生成部２３は、生成したトークンをスーパーフレームの先頭毎に加算する。
パケットスケジューラ１９は、ＴＧＰトラフィック用キューとＦＡＰトラフィック用キューのそれぞれから、パケットを取り出して送信する。
パケットスケジューラ１９は、ＴＧＰ区間の間、全ての転送先に対する出力機会が平等になるようにＴＧＰトラフィック用キューを選択する。すなわち、パケットスケジューラ１９はラウンドロビン法に従い、ＴＧＰトラフィック用のＮ個の出力待ちキューを巡回的に選択する。
同時に、パケットスケジューラ１９は、トークンバケットを用いてＴＧＰパケットの送出量を制限し、トラフィックを平滑化する。なお、ＴＧＰパケットの送信時、パケットスケジューラ１９は、送信分のパケット長をトークンバケットからトークンを削減する。
一方、パケットスケジューラ１９は、ＦＡＰ区間の間、ラウンドロビン法に従い、全ての転送先に対する出力機会が平等になるようにＦＡＰトラフィック用キューを選択する。すなわち、パケットスケジューラ１９はラウンドロビン法に従い、ＦＡＰトラフィック用のＮ個の出力待ちキューを巡回的に選択する。ただし、パケットスケジューラ１９は、トークンバケットなどを用いた送出レートの制限は行なわない。
【００１９】
図５及び図６に、この処理機能を実現する処理手順例を示す。
まず、パケットスケジューラ１９は、現時点がＴＧＰ区間に属するか否かを判断する（プロセスＰ４１）。
ここでは、否定結果が得られた場合について説明する。
ＦＡＰ区間であった場合、パケットスケジューラ１９は、最後に参照したＦＡＰトラフィック用キューの次のキューを参照する（プロセスＰ４２）。そして、パケットスケジューラ１９は、参照したキューにパケットがあるか否かを判断する（プロセスＰ４３）。
ここで、パケットが無かった場合、パケットスケジューラ１９は、プロセスＰ４１に戻る。一方、パケットが存在した場合、パケットスケジューラ１９は、キューの先頭に位置するパケットを取り出す（プロセスＰ４４）。
続いて、パケットスケジューラ１９は、現在のＦＡＰ区間で更にパケットの送信が可能な否かを判断する（プロセスＰ４５）。
送信可能であった場合、パケットスケジューラ１９は、参照したキューに別のパケットがあるか否かを判断する（プロセスＰ４６）。ここで、肯定結果が得られた場合、パケットスケジューラ１９はプロセスＰ４４に戻り、次の先頭パケットを読み出す。
これに対し、プロセスＰ４５で送信できないと判断された場合又はプロセスＰ４６でパケットが存在しないと判断された場合、パケットスケジューラ１９は、それまでの処理で取り出してあったパケット群を現在のＦＡＰ区間にまとめて送信する。この後、パケットスケジューラ１９は、プロセスＰ４１に戻って前述した判断を繰り返す。
【００２０】
次に、プロセスＰ４１で肯定結果が得られた場合について説明する。
ＴＧＰ区間であった場合、パケットスケジューラ１９は、最後に参照したＴＧＰトラフィック用キューの次のキューを参照する（プロセスＰ４８）。そして、パケットスケジューラ１９は、参照したキューにパケットがあるか否かを判断する（プロセスＰ４９）。
ここで、パケットが無かった場合、パケットスケジューラ１９は、プロセスＰ４１に戻る。一方、パケットが存在した場合、パケットスケジューラ１９は、キューの先頭に位置するパケットの長さがトークン量より大きいか否かを判断する（プロセスＰ５０）。
パケット長がトークン量より大きい場合、パケットスケジューラ１９は、先頭パケットは取り出さず、以前に取り出してあったパケット群をまとめて送信する（プロセスＰ５４）。なお、１つもパケットを取り出していない場合は、何も送信しない。
これに対し、パケット長とトークン量が同じである場合又は小さかった場合、パケットスケジューラ１９は、先頭パケットを取り出し、その分をトークン量から減算する（プロセスＰ５１）。
続いて、パケットスケジューラ１９は、現在のＴＧＰ区間で他のパケットを送信可能であるか否かを判断する（プロセスＰ５２）。
ここで、肯定結果が得られた場合、パケットスケジューラ１９は、参照したキューに別のパケットがあるか否かを判断する（プロセスＰ５３）。ここでも肯定結果が得られた場合、パケットスケジューラ１９はプロセスＰ５０に戻り、次の先頭パケットの長さとトークン量を比較する。
これに対して、プロセスＰ５２で送信できないと判断された場合又はプロセスＰ５３でパケットが存在しないと判断された場合、パケットスケジューラ１９は、参照したキューから取り出してあったパケット群を現在のＴＧＰ区間にまとめて送信する。この後、パケットスケジューラ１９は、プロセスＰ４１に戻って前述した判断を繰り返す。
パケットスケジューラ１９では、かかる処理が繰り返し実行される。
【００２１】
（ｄ）実験結果
本発明者は、前述したノードについて伝送実験を行った。以下、２つの実験例について実験結果を説明する。
（ｄ−１）実験例１
図７に、ネットワークトポロジーの一例を示す。このネットワークでは、各ノードが自分以外の全ノードのビーコンを受信できるものとする。
図中、丸印は各ノードを示す。また、丸印内の数字は各ノードを識別する番号である。ここで、隣接するノード間の距離は５〔ｍ〕とする。
実験は、このネットワーク上に、優先度を異にする次の２つのトラフィックを流すことで行った。
（ｉ）ＦＡＰトラフィック
ノード“１”→“２”→“３”→“５”で与えられる経路上に、２０〔Mbps〕のＣＢＲ（Constant Bit Rate ）トラフィックを、０．５秒目から９．５秒目までの９秒間流す。
（ii）ＴＧＰトラフィック
ノード“０”→“２”→“３”→“４”で与えられる経路上に、２０〔Mbps〕のＣＢＲ（Constant Bit Rate ）トラフィックを、４．５秒目から９．５秒目までの５秒間流す。
【００２２】
この際のスループットを図８に、遅延量を図９に、補助ビーコン数を図１０に示す。
図８に示すように、ＴＧＰトラフィックのスループットは、ほぼ期待値と一致することが確認された。すなわち、スループットは、ほぼ２０〔Mbps〕であり、ＦＡＰトラフィックよりも優先的に送信されていることが確認された。
一方、ＦＡＰトラフィックのスループットは、ＴＧＰトラフィックの送信開始に伴って低下し、ほぼ１０〔Mbps〕に低下することが確認された。
また、図９に示すように、ＴＧＰトラフィックの遅延量は、時間の経過に伴って低下し、ほぼ３〜４０〔msec〕で安定した。一方、ＦＡＰトラフィックの遅延量は、ＴＧＰトラフィックの送信開始に伴って増加し、ほぼ８〜９０〔msec〕で安定した。
また、図１０に示すように、ＴＧＰトラフィックが流れるノード“０”、“２”、“３”の補助ビーコン数はいずれも安定している。また、各ノードの補助ビーコン数の合計も安定的に推移することが確認できた。
【００２３】
（ｄ−２）実験例２
図１１に、ネットワークトポロジーの他例を示す。ただし、このネットワークでは、各ノードが隣接ノードのビーコンのみを受信可能とし、隣接しないノードのビーコンは受信できないものとする。
図１２に、この関係を示す。なお、隣接ノード間の距離は最短でも８〔ｍ〕とする。
実験は、このネットワーク上に、優先度を異にする次の２つのトラフィックを流すことで行った。
（ｉ）ＦＡＰトラフィック
ノード“１”→“２”→“３”→“５”で与えられる経路上に、１５〔Mbps〕のＣＢＲ（Constant Bit Rate ）トラフィックを、０．５秒目から９．５秒目までの９秒間流す。
（ii）ＴＧＰトラフィック
ノード“０”→“２”→“３”→“４”で与えられる経路上に、１５〔Mbps〕のＣＢＲ（Constant Bit Rate ）トラフィックを、４．５秒目から９．５秒目までの５秒間流す。
【００２４】
この際のスループットを図１３に、遅延量を図１４に、補助ビーコン数を図１５に示す。
図１３に示すように、ＴＧＰトラフィックのスループットは、ほぼ期待値と一致することが確認された。すなわち、スループットは、ほぼ１５〔Mbps〕であり、ＦＡＰトラフィックよりも優先的に送信されていることが確認された。
一方、ＦＡＰトラフィックのスループットは、ＴＧＰトラフィックの送信開始に伴って低下し、ほぼ６〔Mbps〕に低下することが確認された。
また、図１４に示すように、ＴＧＰトラフィックの遅延量は、時間の経過に伴って低下した。一方、ＦＡＰトラフィックの遅延量は、ＴＧＰトラフィックの送信開始に伴って増加した。
また、図１５に示すように、ＴＧＰトラフィックが流れるノード“０”、“２”、“３”の補助ビーコン数はいずれも安定している。また、各ノードの補助ビーコン数の合計もやや変動が増えるものの、比較的安定して推移することが確認できた。
【００２５】
（４）実施形態の効果
以上説明した制御機能の採用により、各トラフィックに必要な伝送帯域を、各ノードで自律分散的に確保できる。この結果、アプリケーションに応じた優先度によるデータ伝送を実用的な品質で実現できる。
（５）他の実施形態
（ａ）前述の実施形態では、非優先クラスに割り当て可能な最大パケット数ＬｉｍＦＡＰを、ＬｉｍＢＵＦ−Ｎ＿ＰＲＩ−Ｎ＿ＳＵＲＰＬＵＳと定義した。
この場合、ＴＧＰパケットの最大パケット数Ｎ＿ＰＲＩが大きくなるに伴って、ＬｉｍＦＡＰの値は小さくなる。
その一方で、ＬｉｍＦＡＰの値が小さくなりすぎると、非優先クラスをほとんど伝送できなくなる。従って、ＬｉｍＦＡＰが事前に設定した基準値を下回る場合には、少なくともＬｉｍＦＡＰの値を基準値まで引き上げることが望ましい。
例えば、ＴＧＰパケットの増加を吸収するためのパケットバッファ数Ｎ＿ＳＵＲＰＬＵＳを強制的に小さくすれば良い。また、ＴＧＰパケットの最大パケット数Ｎ＿ＰＲＩを強制的に小さくすれば良い。
（ｂ）前述の実施形態では、トラフィックの途絶後も補助ビーコンの確保をしばらく継続する方式を採用する。
しかし、継続時間が長すぎると無駄に無線リソースが消費されることの弊害が大きくなる。従って、トラフィック無しが一定期間続いたら、そのデータ到着レートを強制的にゼロに設定する機能を搭載することが望ましい。例えば、無入力期間が１０スーパーフレームに亘って継続したら強制的にデータ到着レートを強制的にゼロに設定する方式を採用することが望ましい。
このように、データ到着レートをゼロに変更することにより、無線リソースを早期に解放できる。
【００２６】
（ｃ）前述の実施形態では、通信機能をハードウェア的に実現する場合について説明した。もっとも、同じ機能をファームウェア又はソフトウェアとして実現することもできる。これらのプログラムは、光学式記憶媒体（光ディスク、フォログラム媒体その他）、磁気記録媒体（ハードディスクその他）、半導体メモリに格納される。
（ｄ）前述した無線通信装置には、商品形態に応じて様々な装置が含まれる。例えば、携帯情報端末（携帯型のコンピュータ、携帯電話機、携帯型ゲーム機、電子書籍等）、無線ＬＡＮ装置（無線ルーター、子機、アクセスポイント）、時計、ゲーム機器、コンピュータ、ビデオカメラ、デジタルカメラ、スキャナ、印刷装置、画像再生装置（例えば、光ディスク装置、ホームサーバー）、モニタ、テレビジョン受像器、発明に係る機能を搭載した処理ボードや処理カードが含まれる。
なお、いずれの場合にも、筐体と、アンテナ、送受信回路を共通構成とし、商品形態に応じた周辺装置が組み合わされて構成される。例えば、携帯情報端末であれば、前述の構成に加え、操作入力部、表示部その他のユーザーインターフェースを有する。また例えば、ビデオカメラやデジタルカメラであれば、前述の構成に加え、カメラユニットや撮像された映像データを記憶媒体に保存するための書き込み回路を有する。
（ｅ）前述の実施例には、発明の趣旨の範囲内で様々な変形例が考えられる。また、本明細書の記載に基づいて創作される各種の変形例及び応用例も考えられる。
【図面の簡単な説明】
【００２７】
【図１】正規ビーコンと補助ビーコンの配置例を示す図である。
【図２】無線通信装置の内部構成例を示す図である。
【図３】クラス分け部の処理手順例を示す図である。
【図４】ＱｏＳ管理部の処理手順例を示す図である。
【図５】パケットスケジューラの処理手順例を示す図である。
【図６】パケットスケジューラの処理手順例を示す図である。
【図７】アドホックネットワークのトポロジー例を示す図である。
【図８】図７に示すネットワークについて測定したスループットを示す図である。
【図９】図７に示すネットワークについて測定した遅延量を示す図である。
【図１０】図７に示すネットワークについて測定した補助ビーコン数を示す図である。
【図１１】アドホックネットワークのトポロジー例を示す図である。
【図１２】ビーコンの受信状態を示す図である。
【図１３】図１１に示すネットワークについて測定したスループットを示す図である。
【図１４】図１１に示すネットワークについて測定した遅延量を示す図である。
【図１５】図１１に示すネットワークについて測定した補助ビーコン数を示す図である。
【符号の説明】
【００２８】
１１        ノード
１３        ルーティング部
１５        クラス分け部
１７        出力待ちキュー
１９        パケットスケジューラ
２１        ＱｏＳ管理部
２３        トークン生成部
２５        補助ビーコン管理部
【図１】
2006020069.tif 000003
【図２】
2006020069.tif 000004
【図３】
2006020069.tif 000005
【図４】
2006020069.tif 000006
【図５】
2006020069.tif 000007
【図６】
2006020069.tif 000008
【図７】
2006020069.tif 000009
【図８】
2006020069.tif 000010
【図９】
2006020069.tif 000011
【図１０】
2006020069.tif 000012
【図１１】
2006020069.tif 000013
【図１２】
2006020069.tif 000014
【図１３】
2006020069.tif 000015
【図１４】
2006020069.tif 000016
【図１５】
2006020069.tif 000017