(57)【要約】【課題】ＣＳＭＡを用いた自立分散型ＱｏＳ制御方式における衝突の増加によるＱｏＳ保証の性能低下及びポーリング方式を用いた中央集中型ＱｏＳ制御方式における集中制御を緩和する。【解決手段】本願発明は、近隣端末を把握しあう段階で、交換トークンリング登録フレームに各端末が自分の要求ＱｏＳ条件に関する情報を付加することにより、各端末は近隣端末を認識できると共にそれらの端末のそれぞれの要求ＱｏＳ条件をも認識できるようになる。これにより、トークンを受け渡す段階で近隣端末リストの中からどの端末を優先的に選択すればいいか判定できる。各端末は、近隣端末ＱｏＳ認識区間の登録フレームの交換によって得られた近隣端末の要求ＱｏＳ条件をもとに近隣端末のＱｏＳ指数を計算し、トークン受け渡し順番を決定する。【選択図】図６
2007013825.tif 000002
【特許請求の範囲】
【請求項１】
競合を基礎とする媒体アクセス区間において、競合で媒体アクセス権を獲得した端末はそれぞれ近隣端末に要求サービス品質に関する情報を含む特定フレームを送信するステップと、
前記特定フレームを受信した前記近隣端末は前記要求サービス品質に関する情報を記録するステップと、
登録した近隣端末の前記要求サービス品質に関する情報をもとにトークン受け渡し順番を決定するステップと、
前記競合を基礎とする媒体アクセス区間が終了したあとに続くトークンパッシングを基礎とする媒体アクセス区間において、前記トークン受け渡し順番がもっとも高い近隣端末にトークンフレームを送信するステップと、
前記トークンフレームを受信した端末は前記トークンフレーム内の情報に従い、チャネルを占有する権利を獲得し、データを送信するステップと、
前記トークンフレームを受信した端末はデータ送信を完了したあと、近隣端末の情報をもとに作成したトークン受け渡し順番がもっとも高い近隣端末にトークンを送信するステップと
を含む、近隣端末の要求サービス品質を考慮したトークンパッシング方式によってリアルタイムデータのサービス品質を優先的に保証するＱｏＳ制御方法。
【請求項２】
所定の特定端末が、前記競合を基礎とする媒体アクセス区間の長さとトークンパッシングを基礎とする媒体アクセス区間長さとを示す情報を含むフレームを周期的に隣接端末に報知するステップをさらに含む、請求項１に記載のＱｏＳ制御方法。
【請求項３】
前記特定フレームに含まれる前記要求サービス品質は、要求データレートと、要求チャネル占有時間と、許容遅延時間とを含む、請求項１に記載のＱｏＳ制御方法。
【請求項４】
前記トークン受け渡し順番を決定するために、隣接端末の前記要求サービス品質に関する情報をもとに、サービス品質指数を計算するステップをさらに含む、請求項１に記載の方法。
【請求項５】
前記サービス品質指数は前記要求データレートまたは前記要求チャネル占有時間のいずれかを用いて、計算されるものとする請求項４に記載のＱｏＳ制御方法。
【請求項６】
前記サービス品質指数は前記要求チャネル占有時および前記許容遅延時間を用いて、計算されるものとする請求項４に記載のＱｏＳ制御方法。
【請求項７】
前記トークンフレームは、指定チャネル占有時間と、送信完了端末アドレスのリストと、トークンフレーム受信要求がある端末アドレスのリストとを含む、請求項１に記載のＱｏＳ制御方法。
【請求項８】
前記トークンフレームを受信した端末は前記トークンフレーム内の情報に従い、チャネルを占有する権利を獲得し、データを送信するステップは、前記トークンフレームを受信した端末は請求項７に規定する前記指定チャネル占有時間の分で、チャネルを占有し、データ送信を行うステップを含む、請求項１に記載のＱｏＳ制御方法。
【請求項９】
前記トークンフレームを受信した端末はデータ送信を完了したあと、近隣端末の情報をもとに作成したトークン受け渡し順番がもっとも高い近隣端末にトークンを送信するステップは、前記トークンフレームを受信した端末はデータ送信を完了したあと、自分のアドレスを追加した前記送信完了端末アドレスのリストを、次に受け渡すトークンフレームに含むステップをさらに含む、請求項１に記載のＱｏＳ制御方法。
【請求項１０】
前記トークンフレームを受信した端末はデータ送信を完了したあと、近隣端末の情報をもとに作成したトークン受け渡し順番がもっとも高い近隣端末にトークンを送信するステップは、前記トークンフレームを受信した端末はデータ送信を完了したあと、次にトークンフレームを受け渡す宛先端末のアドレスおよび前記送信完了端末アドレスのリストに含まれるアドレスと該当しないアドレスが前記トークン受け渡し順番のリストに存在する場合、自分のアドレスを追加した前記「トークンフレーム受信要求がある端末アドレスのリストを、次に受け渡すトークンフレームに含むステップをさらに含む、請求項１に記載のＱｏＳ制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＱｏＳ保証を必要とするトラヒックを、誤りの発生する無線伝送媒体を通して伝送する無線通信システムのＱｏＳ制御方法に関する。
【背景技術】
【０００２】
従来、ＩＥＥＥ８０２．１１ｅ規格に準ずる無線ＬＡＮシステムでは、伝送データのＱｏＳ保証のために下記２つのＱｏＳ制御方式が提案されている。
【０００３】
一つはデータの優先度によって、「キャリアセンス時間の長さ」や「バックオフ時間の長さ」などを調整し、優先度が高いトラヒックほどチャネル占有の頻度および長さを高くする優先制御を用いたＣＳＭＡ／ＣＡ方式である。これはＩＥＥＥ８０２．１１ｅ規格では「ＥＤＣＡ（Ｅｎｈａｎｃｅｄ  Ｄｉｆｆｅｒｅｎｔｉａｌ  Ｃｏ−ｏｒｄｉｎａｔｉｏｎ  Ａｃｃｅｓｓ）」と呼ばれる方式である（例えば、非特許文献１参照。）。ＥＤＣＡはＣＳＭＡ／ＣＡに基づく方式のため、制御局を設ける必要がない自立分散型ＱｏＳ制御方式である。しかし、ＥＤＣＡは未だに一つ大きな課題を抱えている。それは衝突の増加による性能低下である。ＥＤＣＡは合計端末台数が少ない環境では衝突確率が低いため通常どおりのＱｏＳ保証性能を発揮するが、ある程度合計端末台数が増えると衝突確率が無視できない程度まで増加するため、バックオフ時間および頻度が増加することにより、システム最大スループットが大きく劣化し、ＱｏＳ条件を満たされない端末が増加する。また、ＣＳＭＡのキャリアセンスを行っているにも関わらず、伝播路状況によってお互いに電波が聞こえない端末同士が同一タイミングでチャネルをアクセスすることによる衝突もＱｏＳ保証の性能低下に繋がると考えられる。
【０００４】
一方、もう一つは、制御局が要求データレートなどのＱｏＳ条件を満足するようにポールフレームを送信することによって帯域を効率よく端末に割り当てるＱｏＳを考慮したポーリング方式である。これはＩＥＥＥ８０２．１１ｅ規格では「ＨＣＣＡ（Ｈｙｂｒｉｄ  Ｃｏ−ｏｒｄｉｎａｔｉｏｎ  Ｆｕｎｃｔｉｏｎ  Ｃｏｎｔｒｏｌｌｅｄ  Ｃｈａｎｎｅｌ  Ａｃｃｅｓｓ）」と呼ばれる方式である（例えば、特許文献１、非特許文献１参照。）。ＨＣＣＡは制御局がすべての端末のチャネル占有時間やアクセスタイミングを管理・制御するため、中央集中型ＱｏＳ制御方式である。ＨＣＣＡは端末がキャリアセンスを行う必要がないため、ＥＤＣＡのような衝突増加によるＱｏＳ保証の性能低下が発生しないが、システム内のすべてのトラヒックのＱｏＳを管理・制御を行う制御局を導入する必要がある。また、様々なＱｏＳ条件を要求する複数のトラヒックの管理・制御を効率よく行える知能的な集中制御は複雑であり、開発コストおよび時間がかかると予想される。
【０００５】
本発明は前記ＥＤＣＡおよびＨＣＣＡの両方式の課題を解決できる無線通信システムにおけるＱｏＳ制御方法に関する。
【０００６】
本発明は前記課題を両方とも解決できる可能性があるトークンパッシング方式に着目した。トークンパッシング方式は本来端末の配置（以下では「トポロジー」と呼ぶ）が固定である有線通信分野において提案されたアクセス方式の一つである。トークンパッシング方式に着目した理由は下記のように挙げられる。
【０００７】
ＣＳＭＡ方式のような競合を行う必要がないため衝突が起きない。
【０００８】
集中制御が必ず必要ではない（例えば、特許文献２参照。）。
【０００９】
トークンパッシング方式は本来トポロジーが固定である有線通信のために提案されたアクセス方式であるが、無線通信システムにトークンパッシング方式を用いた提案もある（例えば、特許文献３、非特許文献２参照）。しかし、特許文献３や非特許文献２に記載の技術を含め、無線トークンパッシング方式に関する先行例はトラヒックのＱｏＳ条件や優先順位を考慮されておらず、ＱｏＳ制御を施されていない。
【特許文献１】特開２００４−２６６７９５号公報
【特許文献２】特開平７−２２６７５６号公報
【特許文献３】特開２００４−３１２６６５号公報
【非特許文献１】ＩＥＥＥ８０２．１１ｅ  Ｄｒａｆｔ  Ｖ４．０
【非特許文献２】ＵＣ  Ｂｅｒｋｅｌｅｙ  ＷＯＷ  ｇｒｏｕｐ著、「Ｗｉｒｅｌｅｓｓ  Ｔｏｋｅｎ  Ｒｉｎｇ  Ｐｒｏｔｏｃｏｌ」、［ｏｎｌｉｎｅ］、２００３年３月掲載
【発明の開示】
【発明が解決しようとする課題】
【００１０】
背景技術で述べたように、本発明が解決しようとする課題は「ＣＳＭＡを用いた自立分散型ＱｏＳ制御方式における衝突の増加によるＱｏＳ保証の性能低下」および「ポーリング方式を用いた中央集中型ＱｏＳ制御方式における集中制御の複雑さ」である。本願発明は前記二つの課題を解決するために無線トークンパッシング方式におけるＱｏＳ制御方法を提供する。
【課題を解決するための手段】
【００１１】
トークンパッシング方式の無線伝送路へ適用した場合、データを伝送する前に、トークンを受け渡せる宛て先の端末を把握するために、各端末はそれぞれ自分の近辺に存在する近隣端末のリストを作成する段階が必ず必要である。近隣端末リストの作成方法は、ＷＴＲＰなどの規定のプロトコルに従い、端末間で情報を交換することによって近隣端末のリストを作成する。本発明は、この段階で、交換情報に各端末が自分の要求ＱｏＳ条件に関する情報を付加することにより、各端末は近隣端末を認識できると共にそれらの端末のそれぞれの要求ＱｏＳ条件をも認識できるようになる。これにより、トークンを受け渡す段階で近隣端末リストの中から、どの端末を優先的に選択すればいいかを効率よく判定できる。各端末は自分の送信を完了した後、隣接端末リストの中から要求ＱｏＳ条件が厳しい順で端末を選び、その端末にトークンを受け渡すため、結果的にトラヒックはＱｏＳ条件の厳しい順で伝送されることになる。前記要求ＱｏＳ条件は要求データレート、要求チャネル占有時間、許容遅延時間などが挙げられる。
【発明の効果】
【００１２】
本願発明のＱｏＳ制御方法によれば、ＱｏＳ保証を必要とするＡＶ（Ａｕｄｉｏ  Ｖｉｓｕａｌ）トラヒックに対して、端末台数の増加による性能低下のない安定的なＱｏＳ保証を提供することが出来る。また、本発明は分散型ＱｏＳ制御により、すべてのトラヒックのＱｏＳ条件を管理する集中制御を行わないため、容易に実現できる。
【発明を実施するための最良の形態】
【００１３】
以下、本発明の実施の形態について図面を参照しながら説明する。説明の都合上、本発明を徹底的に理解いただくために特定の数、時間、構造およびその他のパラメータを提示する。以下の段階で本発明を実地する方法の例を挙げる。しかし、これほど詳細を指定せずとも本発明が実施可能であることは当業者には明らかであろう。また、当業者とって、実際の実装では、新たな情報が加えられる場合もあり、かつ実際に使用される状況に依存してある種のパーツや過程が省略される場合もあることは明白である。
【００１４】
図１に、本発明の実施の形態に係る「無線トークンパッシング方式におけるＱｏＳ制御方法」の基本フレームシーケンスを示す。基本フレームシーケンスは図１のように各周期、「ＣＳＭＡ／ＣＡ方式による近隣端末ＱｏＳ認識区間（１０２）」と「ＱｏＳを考慮したトークンパッシング方式によるデータ伝送区間（１０３）」によって構成される。周期の長さはＴｂｅａｃｏｎ−ｐｅｒｉｏｄ（１０１）とする。さらに、近隣端末ＱｏＳ認識区間は「自己ＱｏＳ情報報知区間（１０４）」と「承認区間（１０５）」によって構成される。トークンリングマスターとなる端末は各周期の先頭でビーコンフレーム（１０６）を放送する。ビーコンフレームの中に、前記各区間の長さを示す情報（１０８〜１１１）が含まれるため、トークンリングマスター以外の端末がトークンリングマスターの端末と同期を取ることが出来る。中央制御局が存在するインフラストラクチャーモードで動作する場合は、基本的には中央制御局がトークンリングマスターの役割を担う。一方、中央制御局が存在しないアドホックモードで動作する場合は、初めてアドホック通信を開始する端末がトークンリングマスターの役割を担うことになる。また、この場合、通信チャネルの電波の到達範囲が限られているために、トークンリングマスターから放送されるビーコンフレームを聞こえず、同期を取ることが出来ない端末が現れることが考えられる。このような同期問題を軽減するために、ビーコンフレームを放送する時のみ、トークンリングマスターは中央周波数が通信チャネルより比較的低い別のチャネルを用いることが一つの対策として考えられる。同期問題の対策については本発明の範囲外のため詳細を省略する。
【００１５】
図３に、自己ＱｏＳ情報報知を報知したい端末の動作のフローチャートを示す。各端末は自己ＱｏＳ情報報知区間中、ＣＳＭＡ／ＣＡ方式によって競合し、自力でチャネルアクセス権を獲得する。この区間のアクセス方式はＣＳＭＡ／ＣＡ方式の代わりに、トラヒックの優先順位によって「キャセンス時間」や「バックオフ時間」を制御するＥＤＣＡを用いると、ＡＶトラヒックを送信したい端末は優先的にチャネルアクセス権を獲得できる確率が高くなる。図３で示す手順によってチャネルアクセス権を獲得した端末は自分のＱｏＳ情報を近隣の端末に知らせるために、「要求チャネル占有時間（１２１２）」や「許容遅延（１２１３）」などの要求ＱｏＳ条件（１２１０）を含む図１５のトークンリング参加登録フレーム（１２０１）を送信する。自己ＱｏＳ情報報知区間が終了したあと、トークンリング参加登録フレーム（１２０１）を送信出来なかった端末は次の周期まで待ってから再度挑戦することになる（３０９）。
【００１６】
図２に、自己ＱｏＳ情報報知区間の動作例を示す。この動作例では、ネットワーク内に端末Ａ、端末Ｂ、端末Ｃ、端末Ｄ、合計４台の端末が存在するとする。端末ＡはＶｏＩＰ（Ｖｏｉｃｅ  ｏｖｅｒ  ＩＰ  ｐｒｏｔｏｃｏｌ）トラヒックを、端末Ｂと端末ＤはＳＤＴＶ（Ｓｔａｎｄａｒｄ  Ｄｅｆｉｎｉｔｉｏｎ  Ｔｅｌｅｖｉｓｉｏｎ）トラヒックを、端末ＣはＷｅｂトラヒックを、送信したい端末とする。また、トークンリングマスターは端末Ａとする。前記４つの端末は自己ＱｏＳ情報報知区間中、近隣端末に自己ＱｏＳ情報を含むトークンリング参加登録フレームを送信するが、電波の到達範囲が限られているためすべての端末に自分のトークンリング参加登録フレームが届くわけではない。しかし、図２のように、トークンリング参加登録フレーム（１２０１）（以下では、登録フレームと呼ぶ。）を交換し合うことによって、各端末は自分の電波到達範囲内に存在する他の端末のアドレスを認識できると共にその端末のそれぞれの要求ＱｏＳも認識出来る。下記に図２の説明を述べる。
【００１７】
ステップ１（２０１）：端末Ａは「要求チャネル占有時間＝０．５ｍｓ」を含む登録フレーム（１２０１）を送信する。端末Ｃが端末Ａの電波到達範囲外に存在するため、端末Ａの登録フレームは端末Ｂおよび端末Ｄにしか届かない。端末Ｂと端末Ｄは近隣に端末Ａが存在すると認識し、自分の近隣端末リストに端末Ａのアドレスを追加・記録する。さらに、端末Ｂと端末Ｄは端末Ａが「要求チャネル占有時間＝０．５ｍｓ」というＱｏＳ条件を要求していると認識し、自分の近隣端末のＱｏＳ情報リストに端末Ａの「要求チャネル占有時間＝０．５ｍｓ」を追加・記録する。
【００１８】
ステップ２（２０２）：端末Ｄは「要求チャネル占有時間＝３．０ｍｓ」を含む登録フレーム（１２０１）を送信する。端末Ｂと端末Ｃが端末Ｄの電波到達範囲外に存在するため、端末Ｄの登録フレームは端末Ａにしか届かない。端末Ａは近隣に端末Ｄが存在すると認識し、自分の近隣端末リストに端末Ａのアドレスを追加・記録する。さらに、端末Ａは端末Ｄが「要求チャネル占有時間＝３．０ｍｓ」というＱｏＳ条件を要求していると認識し、自分の近隣端末のＱｏＳ情報リストに端末Ｄの「要求チャネル占有時間＝３．０ｍｓ」を追加・記録する。
【００１９】
ステップ３（２０３）：端末Ｂは「要求チャネル占有時間＝２．５ｍｓ」を含む登録フレーム（１２０１）を送信する。端末Ｄが端末Ｂの電波到達範囲外に存在するため、端末Ｂの登録フレームは端末Ａと端末Ｃにしか届かない。端末Ａと端末Ｃは近隣に端末Ｂが存在すると認識し、自分の近隣端末リストに端末Ｂのアドレスを追加・記録する。さらに、端末Ａと端末Ｃは端末Ｂが「要求チャネル占有時間＝２．５ｍｓ」というＱｏＳ条件を要求していると認識し、自分の近隣端末のＱｏＳ情報リストに端末Ｂの「要求チャネル占有時間＝２．５ｍｓ」を追加・記録する。
【００２０】
ステップ４（２０４）：端末Ｃは「要求チャネル占有時間＝０．１ｍｓ」を含む登録フレーム（１２０１）を送信する。端末Ａと端末Ｄが端末Ｃの電波到達範囲外に存在するため、端末Ｃの登録フレームは端末Ｂにしか届かない。端末Ｂは近隣に端末Ｃが存在すると認識し、自分の近隣端末リストに端末Ｃのアドレスを追加・記録する。さらに、端末Ｂは端末Ｃが「要求チャネル占有時間＝０．１ｍｓ」というＱｏＳ条件を要求していると認識し、自分の近隣端末のＱｏＳ情報リストに端末Ｃの「要求チャネル占有時間＝３．０ｍｓ」を追加・記録する。
【００２１】
本発明のシステムにおける端末は図２のような動作によって、近隣端末のアドレスおよび要求ＱｏＳ条件を認識し合うことが出来る。
【００２２】
ちなみに、前記「要求チャネル占有時間」の値は基本的に「要求データレート」および「Ｔｂｅａｃｏｎ−ｐｅｒｉｏｄ（１０１）」に基づいて計算されたものである。
【００２３】
例えば、ＳＤＴＶ＝６ＭｂｐｓおよびＴｂｅａｃｏｎ−ｐｅｒｉｏｄ＝１０ｍｓの場合、
１データパケット内のデータビット数＝１１２００ビットとする
１データパケットを送信するのに必要な送信時間＝４００ｕｓとする
１周期で送らなければならないデータビット数＝１０ｍｓ×６Ｍｂｐｓ＝６００００ビット
１周期で送らなければならないデータパケット数＝６００００／１１２００≒６パケット
１周期で要求される送信時間＝６×４００ｕｓ＝２．４ｍｓ
「要求チャネル占有時間」＝２．４ｍｓ
また、伝播路特性の変動によるパケット誤り率１０％を見込んだ場合、要求データレートに１０％を上乗せした値を用いて上記と同じ計算を行う。
【００２４】
自己ＱｏＳ情報報知区間が完了したあと、承認情報報知区間が開始される。承認情報報知区間は、送信した参加登録フレームが他の端末に届いたかどうかを確認するために設けられたが、必ず必要なわけではないため、自己ＱｏＳ情報報知区間が完了したあとに即座データ伝送区間が開始されるシーケンスでも可能である。
【００２５】
図５に、承認情報を報知する端末の動作のフローチャートを示す。各端末は承認情報報知区間中、ＣＳＭＡ／ＣＡ方式によって競合し、自力でチャネルアクセス権を獲得する。この区間のアクセス方式はＣＳＭＡ／ＣＡ方式の代わりに、トラヒックの優先順位によって「キャセンス時間」や「バックオフ時間」を制御するＥＤＣＡを用いると、ＡＶトラヒックを送信したい端末は優先的にチャネルアクセス権を獲得できる確率が高くなる。図５で示す手順によってチャネルアクセス権を獲得した端末はどの端末から「参加登録フレーム（１２０１）」を受信したかを近隣の端末に知らせるために、自分が受信したすべての「参加登録フレーム（１２０１）のＳｏｕｒｃｅ  Ａｄｄｒｅｓｓ  （１２０２）」が表示されている「Ｃｏｎｆｉｒｍａｔｉｏｎ  Ａｄｄｒｅｓｓ  Ｌｉｓｔ（１３０３）」を含む図１６の承認フレーム（１３０１）を送信する。承認情報報知区間が終了したあと、承認フレームを送信出来なかった端末は次の周期まで待ってから再度挑戦することになる（３０９）。
【００２６】
図４に、承認情報報知区間の動作例を示す。この図の動作例、図２の動作例の続きである。前記４つの端末は承認情報報知区間中、近隣端末に「Ｃｏｎｆｉｒｍａｔｉｏｎ  Ａｄｄｒｅｓｓ  Ｌｉｓｔ（１３０３）」を含む承認フレームを送信するが、電波の到達範囲が限られているためすべての端末に自分の承認が届くわけではない。下記に図４の説明を述べる。
【００２７】
ステップ１（４０１）：端末Ａは「Ｃｏｎｆｉｒｍａｔｉｏｎ  Ａｄｄｒｅｓｓ  Ｌｉｓｔ＝Ｄ、Ｂ」を含む承認フレーム（１３０１）を送信する。端末Ｃが端末Ａの電波到達範囲外に存在するため、端末Ａの承認フレームは端末Ｂおよび端末Ｄにしか届かない。端末Ｂと端末Ｄは自分の登録フレームが端末Ａに受信されたことを確認できる。
【００２８】
ステップ２（４０２）：端末Ｄは「Ｃｏｎｆｉｒｍａｔｉｏｎ  Ａｄｄｒｅｓｓ  Ｌｉｓｔ＝Ａ」を含む承認フレーム（１３０１）を送信する。端末Ｂと端末Ｃが端末Ｄの電波到達範囲外に存在するため、端末Ｄの承認フレームは端末Ａにしか届かない。端末Ａは自分の登録フレームが端末Ｄに受信されたことを確認できる。
【００２９】
ステップ３（４０３）：端末Ｂは「Ｃｏｎｆｉｒｍａｔｉｏｎ  Ａｄｄｒｅｓｓ  Ｌｉｓｔ＝Ａ、Ｃ」を含む承認フレーム（１３０１）を送信する。端末Ｄが端末Ｂの電波到達範囲外に存在するため、端末Ｂの承認フレームは端末Ａおよび端末Ｃにしか届かない。端末Ａと端末Ｃは自分の登録フレームが端末Ｃに受信されたことを確認できる。
【００３０】
ステップ４（４０４）：端末Ｃは「Ｃｏｎｆｉｒｍａｔｉｏｎ  Ａｄｄｒｅｓｓ  Ｌｉｓｔ＝Ｂ」を含む承認フレーム（１３０１）を送信する。端末Ａと端末Ｄが端末Ｃの電波到達範囲外に存在するため、端末Ｃの承認フレームは端末Ｂにしか届かない。端末Ｂは自分の登録フレームが端末Ｃに受信されたことを確認できる。
【００３１】
「近隣端末ＱｏＳ認識区間（１０２）」が終了したあと、各端末は「近隣端末ＱｏＳ認識区間（１０２）」中で得られた近隣端末のＱｏＳ情報をもとにトークン受け渡し順番を決定する。
【００３２】
図１３に、要求チャネル占有時間のみ考慮した場合の近隣端末ＱｏＳ情報によるトークン受け渡し順番の決定方法を示す。各端末は、近隣端末ＱｏＳ認識区間（１０２）の登録フレームの交換によって得られた近隣端末の要求ＱｏＳ条件をもとに近隣端末の「ＱｏＳ指数（ＱｏＳ  Ｉｎｄｅｘ）」を計算し、トークン受け渡し順番（Ｔｏｋｅｎ  ｐａｓｓｉｎｇ  ｏｒｄｅｒ）を決定する。基本的にはＱｏＳ指数が高い近隣端末ほどトークン受け渡し順番が高い。要求ＱｏＳ条件として要求チャネル占有時間のみ用いた場合の図１３では、ＱｏＳ指数の値は単純に要求チャネル占有時間である。つまり、要求チャネル占有時間のみ考慮した場合、「ＱｏＳ指数＝要求チャネル占有時間」である。例えば、図１３では端末Ａは登録フレームの交換によって得られた近隣端末ＤおよびＢの要求チャネル占有時間（１１０１）をもとにＱｏＳ指数（１１０５）を計算する。この場合、近隣端末Ｄの要求チャネル占有時間＝３ｍｓ、近隣端末Ｂの要求チャネル占有時間＝２．５ｍｓ、のため、近隣端末ＤのＱｏＳ指数は３、近隣端末ＢのＱｏＳ指数は２．５となる。従って、端末Ａのトークン受け渡し順番（１１０９）は１位が近隣端末Ｄ、２位が近隣端末Ｂとなる。つまり、端末Ａの電波到達範囲内に近隣端末ＤとＢが存在するが、端末Ａは初めてトークンフレームを受信した時優先的にＱｏＳ指数が一番高い近隣端末Ｄにトークンを受け渡さなければならない。トークンを近隣端末Ｄに受け渡したあと、端末Ａが再びトークンを受信したとき、端末Ａはトークン受け渡し順番２位の近隣端末Ｂにトークンを受け渡す。
【００３３】
端末Ａ以外の端末もデータ伝送区間開始までに上記と同様な手続きによって近隣端末のＱｏＳ指数を計算し、トークン受け渡し順番を決定しておく。
【００３４】
許容遅延の条件が非常に厳しいＶｏＩＰなどのような音声トラヒックのＱｏＳを保証する場合、ＱｏＳ指数を計算するとき、要求チャネル占有時間に加え、許容遅延時間を用いる必要がある。
【００３５】
図１４に、要求チャネル占有時間および許容遅延時間を考慮した場合の近隣端末ＱｏＳ情報によるトークン受け渡し順番の決定方法を示す。例えば、図１４では端末Ｂは登録フレームの交換によって得られた近隣端末ＡとＣの要求チャネル占有時間（１１２２）および許容遅延時間（１１２６）をもとにＱｏＳ指数（１１３０）を計算する。ここで、近隣端末ＡとＣに注目する。近隣端末ＡはＶｏＩＰ送信端末で、要求チャネル占有時間が０．１ｍｓと非常に短いが、許容遅延時間が２０ｍｓと非常に厳しい条件を要求する。一方、近隣端末ＣはＷｅｂトラヒック送信端末で、許容遅延時間を特に要求しないものの、要求チャネル占有時間が０．５ｍｓで近隣端末Ａの５倍である。このような場合、要求チャネル占有時間のみ考慮すると、近隣端末ＣのＱｏＳ指数が近隣端末ＡのＱｏＳ指数を上回り、Ｗｅｂトラヒックを送信する近隣端末Ｃのトークン受け渡し順番がＶｏＩＰトラヒックを送信する近隣端末Ａより高くなってしまうのである。このような問題を避けるために、要求チャネル占有時間および許容遅延時間を考慮する必要がある。この場合、「ＱｏＳ指数＝要求チャネル占有時間÷（許容遅延／Ｔｂｅａｃｏｎ−ｐｅｒｉｏｄ）２」とする。このＱｏＳ指数計算式により、近隣端末ＡのＱｏＳ指数は０．１÷（２０／１０）２＝０．０２５であり、近隣端末ＣのＱｏＳ指数は０．５÷（１００００／１０）２＝５×１０−７である（１１３０）。この結果に従い、端末Ｂのトークン受け渡し順番（１１０９）は１位が近隣端末Ａ、２位が近隣端末Ｃとなる。つまり、端末Ｂの電波到達範囲内に近隣端末ＡとＣが存在するが、端末Ｂは初めてトークンフレームを受信した時優先的にＱｏＳ指数が一番高い近隣端末Ａにトークンを受け渡さなければならない。トークンを近隣端末Ａに受け渡したあと、端末Ｂが再びトークンを受信したとき、端末Ｂはトークン受け渡し順番２位の近隣端末Ｃにトークンを受け渡す。
【００３６】
近隣端末ＱｏＳ認識区間が終了したあと、ＱｏＳを考慮したトークンパッシング方式によるデータ伝送区間が開始される。
【００３７】
図６に、データ伝送区間の動作例を示す。図６では、各端末は図１３で決定したトークン受け渡し順番（１１０９〜１１１２）および近隣端末の要求チャネル占有時間（１１０１〜１１０４）に従い、動作する。まず、データ伝送区間の先頭で、トークンリングマスターである端末Ａは図７のトークンフレームフォーマット（７０１）によって作成されたトークンフレーム（６０１）を送信する。前記トークンフレーム（６０１）の表示情報は図１１の１０１０で示す。端末Ａは自分が決定したトークン受け渡し順番（１１０９）により優先的に近隣端末Ｄにトークンを受け渡さなければならないため、Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ＝Ｄをトークンに表示する。また、近隣端末Ｄの要求チャネル占有時間＝３ｍｓ（１１０１）により、Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝３ｍｓをトークンに表示する。さらに、トークン受け渡し順番リスト（１１０９）により近隣端末Ｄ以外に他の端末（この場合は端末Ｂ）が載っているため、自分のアドレスを追加したＭｏｒｅ  Ｔｏｋｅｎ  Ａｄｄｒｅｓｓ  Ｌｉｓｔをトークンに表示する。
【００３８】
上記の表示情報によって作成されたトークン（６０１、１１０１）を受信した端末は図８のフローチャートに従い、動作する。図６ではトークン６０１は端末Ｄ宛に送信されたため、端末Ｄはトークン６０１を受け取り、トークン内の表示情報（１１０１）に従い、３ｍｓ分データを送信する。その後、端末Ｄは図８のフローチャートの８１３のプロセス（８０５〜８１１）に従い、送信トークンの表示情報を決定する。その後、端末Ｄは決定した表示情報を含むトークンフレーム（６０３、１０２０）を送信する。
【００３９】
トークン（６０３、１０２０）を受け取った端末Ａは自分の送信を完了したあと、８１３のプロセス（８０５〜８１１）に従い、送信トークンの表示情報を決定する。この時、端末ＡはＤｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ＝Ｂ以外にトークンを受け渡してない宛先がないと判定したためＭｏｒｅ  Ｔｏｋｅｎ  Ａｄｄｒｅｓｓ  Ｌｉｓｔから自分のアドレスを削除する（８０７、８０９）。その後、端末Ａは決定した表示情報を含むトークンフレーム（６０５、１０３０）を送信する。
【００４０】
トークン（６０５、１０３０）を受け取った端末Ｂは自分の送信を完了したあと、８１３のプロセス（８０５〜８１１）に従い、送信トークンの表示情報を決定する。この時、端末Ｂは自分のアドレスをＡｌｌｏｃａｔｅｄ  Ａｄｄｒｅｓｓ  Ｌｉｓｔに追加するため、結果的に端末Ｂから送信されるトークンにＡｌｌｏｃａｔｅｄ  Ａｄｄｒｅｓｓ  Ｌｉｓｔ＝Ｄ、Ａ、Ｂ（１０４２）が含まれる。端末Ｂは決定した表示情報を含むトークンフレーム（６０７、１０４０）を送信する。
【００４１】
トークン（６０７、１０４０）を受け取った端末Ｃは自分の送信を完了したあと、８１３のプロセス（８０５〜８１１）に従い、送信トークンの表示情報を決定する。この時、端末Ｃは自分トークン受け渡し順番リストに載っているすべてのアドレスは  Ａｌｌｏｃａｔｅｄ  Ａｄｄｒｅｓｓ  Ｌｉｓｔに含まれていると認識したため、８０５以降のプロセスを行わず、図９のフローチャットで示されるプロセスを実行する。そのため、端末Ｃは「Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ＝ＱｏＳ指数が一番高い近隣端末のアドレス＝端末Ｂ」と決定し（９０２）、Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０を含むトークン（６０９、１０５０）を端末Ｂ宛に送信する（９０４）。
【００４２】
トークン（６０９、１０５０）を受け取った端末Ｂは図１０のフローチャートで示されるプロセスを実行する。
【００４３】
端末Ｂは自分がリングマスターではないと判断したため、「Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ＝ＱｏＳ指数が一番高い近隣端末のアドレス＝端末Ａ」と決定し（９１３）、Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０を含むトークン（６１０、１０６０）を端末Ａ宛に送信する（９１５）。
【００４４】
トークン（６１０、１０６０）を受け取った端末Ａは図１０のフローチャートで示されるプロセスを実行する。端末Ａは自分がリングマスターであると判断したため（９１２）、「Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０」のトークンを受け取った回数を所定回数と比較する（９１６）。実施の形態の動作例では所定回数＝２とするため、初めて「Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０」のトークンを受け取ったリングマスターである端末Ａは「Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ＝ＱｏＳ指数が一番高い近隣端末のアドレス＝端末Ｄ」と決定し（９１３）、Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０を含むトークン（６１１、１０７０）を端末Ｄ宛に送信する（９１５）。
【００４５】
トークン（６１１、１０７０）を受け取った端末Ｄは図１０のフローチャートで示されるプロセスを実行する。端末Ｂは自分がリングマスターではないと判断したため、「Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ＝ＱｏＳ  指数が一番高い近隣端末のアドレス＝端末Ａ」と決定し（９１３）、Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０を含むトークン（６１２、１０７０）を端末Ａ宛に送信する（９１５）。
【００４６】
トークン（６１２、１０７０）を受け取った端末Ａは図１０のフローチャートで示されるプロセスを実行する。端末Ａは自分がリングマスターであると判断したため（９１２）、「Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０」のトークンを受け取った回数を所定回数と比較する（９１６）。実施の形態の動作例では所定回数＝２とするため、２回目で「Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０」のトークンを受け取ったリングマスターである端末Ａはトークンを送信しないことを決定し（９１７）、データ伝送区間が終了するまで待機する（９１８）。
【００４７】
前記「Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０」のトークンを受け取った所定回数は任意に設定可能な値であるが、設定所定回数が多いほど、トークン待ち中の端末がまだあるにも関わらずトークン受け渡しを中断してしまうイベントが発生する確率が低くなる。
【００４８】
また、トークン待ち中の端末がまだあるにも関わらずデータ伝送区間が終了する場合、合計トラヒック量が有効な帯域を越えたことを意味するため、トークンを受け取る機会を得られなかったＱｏＳ指数が低いその端末らは帯域に余裕があるときまで待つことになる。
【００４９】
データ伝送区間が終了した後、次の周期の近隣端末ＱｏＳ情報認識区間が開始される。トークンリングマスターとなる端末は近隣端末ＱｏＳ情報認識区間の先頭でビーコンフレーム（１０６）を周期的に放送するため、トークンリングに参加してない端末またはリング参加登録に失敗した端末は近隣端末ＱｏＳ情報認識区間中で、トークンリングに参加できるまで何回も挑戦することが出来る。また、一度トークンリングに参加登録が成功した端末はトークンリング参加登録フレームを送信する必要がないが、要求ＱｏＳ条件に変化があった場合のみ新しい要求ＱｏＳ条件を含むトークンリング参加登録フレームを送信し、近隣端末に自分の新しい要求ＱｏＳ条件を知らせることにより、近隣端末に登録されている自分のＱｏＳ条件やトークン受け渡し順番を更新してもらうことが出来る。
【産業上の利用可能性】
【００５０】
本発明は無線ネットワークにおけるテレビ信号やＶｏＩＰ信号の安定的な伝送を実現することに有用である。
【図面の簡単な説明】
【００５１】
【図１】本発明の実施の形態に係る「無線トークンパッシング方式におけるＱｏＳ制御方法」の基本フレームシーケンスを示す図
【図２】自己ＱｏＳ情報報知区間の動作例を示す図
【図３】自己ＱｏＳ情報を報知したい端末の動作を示すフローチャート
【図４】承認報知区間の動作例を示す図
【図５】承認情報を報知する端末の動作を示すフローチャート
【図６】データ伝送区間の動作例を示す図
【図７】トークンフレームのフォーマットを示す図
【図８】データ伝送区間中のトークンを受信した端末の動作を示すフローチャート（通常動作）
【図９】トークン受け渡しリストに載っているすべてのアドレスはＡｌｌｏｃａｔｅｄ  Ａｄｄｒｅｓｓ  Ｌｉｓｔに含まれている場合の動作を示すフローチャート
【図１０】Ａｌｌｏｃａｔｅｄ  Ｔｉｍｅ＝０のトークンを受信した場合の動作を示すフローチャート
【図１１】トークン受け渡しの動作とトークン内の表示情報の関係を示す図（前半）
【図１２】トークン受け渡しの動作とトークン内の表示情報の関係を示す図（後半）
【図１３】近隣端末ＱｏＳ情報によるトークンパッシング順番の決定方法（要求チャネル占有時間のみ考慮した場合）を示す図
【図１４】近隣端末ＱｏＳ情報によるトークンパッシング順番の決定方法（要求チャネル占有時間および許容遅延を考慮した場合）を示す図
【図１５】トークンリング参加登録フレームのフォーマットを示す図
【図１６】承認フレームのフォーマットを示す図
【図１】
2007013825.tif 000003
【図２】
2007013825.tif 000004
【図３】
2007013825.tif 000005
【図４】
2007013825.tif 000006
【図５】
2007013825.tif 000007
【図６】
2007013825.tif 000008
【図７】
2007013825.tif 000009
【図８】
2007013825.tif 000010
【図９】
2007013825.tif 000011
【図１０】
2007013825.tif 000012
【図１１】
2007013825.tif 000013
【図１２】
2007013825.tif 000014
【図１３】
2007013825.tif 000015
【図１４】
2007013825.tif 000016
【図１５】
2007013825.tif 000017
【図１６】
2007013825.tif 000018