(57)【要約】【課題】送信側と受信側の間の「距離減衰」および「シャドーイング」の変化に応じて媒体確保のスケジュールを適応的に調整し、ポーリングサービスによるストリーム伝送に対してより安定的なＱｏＳ保証を提供すること。【解決手段】伝送距離の増加やシャドーイングの増加によって平均パケット誤り率が大きく増加する場合、伝送ストリームのＱｏＳを維持するために２つの方法が考えられる。１つは誤るデータパケットの増加に応じて再送に必要な余分帯域を増やす方法である。もう一つは伝送データの情報伝送レートを下げてパケット誤り率を改善させる方法である。本発明はこの二つの方法を適切に選択しつつ、チャネルのエラー状態およびデータのトラヒック要求仕様に応じて帯域確保を効率よく調整するアルゴリズムおよびプロセスを提案し、様々なリアルタイムデータストリーム伝送に対して、より安定的なＱｏＳ保証を提供することが出来る。【選択図】図３
2006080847.tif 000002
【特許請求の範囲】
【請求項１】
制御局がトラヒック要求仕様を受け付けるステップと、
前記トラヒック要求仕様に基づいて媒体確保スケジュールを生成するステップと、
前記媒体確保スケジュールに応じてポーリングを行うステップと、
媒体の誤り状態を把握するステップと、
前記媒体の誤り状態によって前記媒体確保スケジュールを調整する必要があるかどうかを判定するステップと
媒体の誤り状態の変化に応じて動的に前記媒体確保スケジュールを調整するステップと、
前記媒体の誤り状態の変化に応じて動的に前記媒体確保スケジュールを調整するステップによって更新された媒体確保スケジュールを該当端末に通知するステップとを含むことを特徴とする媒体確保を調整する方法。
【請求項２】
前記媒体の誤り状態を把握するステップは、パケット誤り率とパケットのリトライ回数とリトライ回数が所定値以上多いパケットの割合とを含むパラメータを測定するステップを含むことを特徴とする請求項１記載の媒体確保を調整する方法。
【請求項３】
前記媒体確保スケジュールを調整するステップは、割り当てる帯域の調整又は情報伝送レートの変更のうちいずれか一方を選択するステップを含むことを特徴とする請求項１記載の媒体確保を調整する方法。
【請求項４】
前記媒体確保スケジュールを調整する必要があるかどうかを判定するステップにおいて、パケット誤り率とパケットのリトライ回数とリトライ回数が所定値以上多いパケットの割合とを含むパラメータを測定するステップを含むことを特徴とする請求項１記載の媒体確保を調整する方法。
【請求項５】
前記媒体確保スケジュールを調整するステップにおいて、前記割り当てる帯域の調整又は前記情報伝送レートの変更のうちいずれかを選択するために、リトライ回数が所定値以上多いパケットの割合を用いるステップを含む請求項３記載の媒体確保を調整する方法。
【請求項６】
端末がストリームの送信側であって、前記端末は前記媒体確保スケジュールを調整する必要があるかどうかを判定し、前記割り当てる帯域の調整により媒体確保スケジュールを調整する必要があると判定した場合、制御局に新たな希望のトラヒック要求仕様を通知するステップを含む請求項３記載の媒体確保を調整する方法。
【請求項７】
端末がストリームの送信側であって、前記端末は前記媒体確保スケジュールを調整する必要があるかどうかを判定し、前記情報伝送レートの変更により媒体確保スケジュールを調整する必要があると判定した場合、前記端末が制御局に希望の情報伝送レートでトラヒック要求仕様を送信し、通知するステップを含む請求項３記載の媒体確保を調整する方法。
【請求項８】
制御局がストリームの送信側であって、前記制御局は前記媒体確保スケジュールを調整する必要があるかどうかを判定し、前記割り当てる帯域の調整により媒体確保スケジュールを調整する必要があると判定した場合、制御局が新たな希望のトラヒック要求仕様を受信する必要がなく、制御局自身が新たな希望のトラヒック要求仕様を決定し、前記新たな希望のトラヒック要求仕様におうじて媒体確保スケジュールを調整するステップを含む請求項３記載の媒体確保を調整する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インタラクティブ・アプリケーション、コミュニケーティブ・アプリケーション、およびゲーム用のリアルタイムのオーディオービジュアルデータ等の時間にセンシティブなデータを、誤りの発生する伝送媒体を通して供給することに関する。アプリケーションのサービス品質（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ：ＱｏＳ）を満足するために、データトラヒックを調整する必要があると共に、帯域確保（ｂａｎｄｗｉｄｔｈ  ｄｅｄｉｃａｔｉｏｎ）のスケジューリングを実行する必要がある。
【背景技術】
【０００２】
従来、ＩＥＥＥ８０２．１１ｅ規格に準する無線ＬＡＮシステムでは、伝送データのＱｏＳ条件（要求データレート、許容遅延時間など）が含まれる「トラヒック要求仕様」（Ｔｒａｆｆｉｃ  ｒｅｑｕｉｒｅｍｅｎｔ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ）を確実に満足するために、制御局ＡＰはトラヒック要求仕様に基づいて計算された「媒体確保の周期（ポーリング周期：Ｐｏｌｌｉｎｇ  ｉｎｔｅｒｖａｌ）」や「一回の媒体確保に割り当てなければならない媒体占有持続時間」などのスケジュール情報に従いポーリングを行う（例えば、特許文献１参照）。トラヒック要求仕様に基づいたスケジュール情報の計算は基本的にマルチパスフェージングなどの伝播路特性の時間的変動によって誤るデータパケットの再送に必要な余分帯域を考慮して実行されるため、帯域不足問題が起きることなくデータのＱｏＳ保証が可能である。
【特許文献１】特開２００３−２０９５５４号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、前記従来の無線ＬＡＮシステムでは、実際の環境で端末の置き場所を変更したり、在室する人の人数や配置が変ったりすることなどによって送信側と受信側の間の「距離減衰」および「シャドーイング」の影響が大きく変化することがあるため初期のスケジュールによるポーリングサービスはいつまでもデータのＱｏＳが保証できるわけではないという課題を有していた。
【０００４】
本発明は前記従来の課題を解決するもので、前記トラヒック要求仕様に加えて、媒体の「トラヒック状態」および「伝搬路特性の変化によるエラー状態」を観測した結果を考慮し、それに応じて効率よく帯域確保を調整する媒体確保調整のプロセスおよびアルゴリズムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
伝送距離の増加やシャドーイングの増加によって平均パケット誤り率が大きく増加する場合、伝送ストリームのＱｏＳを維持するために２つの方法が考えられる。１つは誤るデータパケットの増加に応じて再送に必要な余分帯域を増やす方法である。もう一つは伝送データの情報伝送レート（ＴＸＲ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｒａｔｅ）を下げてパケット誤り率を改善させる方法である。再送に必要な帯域（再送帯域）を増やす方法はパケット誤りが下がらないため同一パケットが再送される回数（リトライ回数）の増加を防げない。リトライ回数が多くなればパケットの伝送遅延時間が許容遅延時間を越えてしまう確率も高くなるため、この再送帯域を増やす方法は許容遅延時間の条件が厳しいＶｏＩＰやビデオデータなどのＱｏＳ条件を満足できないことがある。一方、情報伝送レートＴＸＲを下げる方法はパケット誤り率と共にリトライ回数を改善できるが、ＴＸＲの減少に応じて「一回の媒体確保に割り当てなければならない媒体占有持続時間」（Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌ）を増やさなければならないため、チャネル利用効率と共に利用可能な合計帯域が減少してしまう。本発明はこの二つの方法を適切に選択しつつ、チャネルのエラー状態およびデータのトラヒック要求仕様に応じて帯域確保を効率よく調整するアルゴリズムおよびプロセスを提案する。
【発明の効果】
【０００６】
本発明の媒体確保調整のプロセスおよびアルゴリズムによれば、インタラクティブ・アプリケーション、コミュニケーティブ・アプリケーション、およびゲーム用のリアルタイムのオーディオービジュアルデータ等の様々なデータストリーム伝送に対して、チャネルの誤り特性の変化に応じた帯域確保を行うことが出来、より安定的なＱｏＳ保証を提供することが出来る。
【発明を実施するための最良の形態】
【０００７】
以下、本発明の実施の形態について図面を参照しながら説明する。説明の都合上、本発明を徹底的に理解いただくために特定の数、時間、構造およびその他のパラメータを提示する。以下の段階で本発明を実地する方法の例を挙げる。しかし、これほど詳細を指定せずとも本発明が実施可能であることは当業者には明らかであろう。また、当業者とって、実際の実装では、新たな情報が加えられる場合もあり、かつ実際に使用される状況に依存してある種のパーツや過程が省略される場合もあることは明白である。
【０００８】
図１は、本発明の背景となるストリームセットアップの手順を示す図である。ＩＥＥＥ８０２．１１ｅ規格に準する無線ＬＡＮシステムではポーリングサービスによるＱｏＳ保証が必要なデータの伝送は伝送を開始する前に、伝送の方向（アップリンク・ダウンリンク・ダイレクトリンク）を問わず端末ＳＴＡが必ずストリームセットアップを行う必要がある。ここで、ストリームセットアップの手順について説明する。
【０００９】
まず、端末は送信または受信したいデータのトラヒック要求仕様を含むトラヒック要求登録フレームを制御局ＡＰに送信する。トラヒック要求仕様は一般のパラメータ化された形式で、ストリームの最高の知識を備えたエンティティによって特定される。トラヒック要求仕様の例は、構造体の形式として以下に示される。
【００１０】
トラヒック要求仕様（Ｔｒａｆｆｉｃ  ｒｅｑｕｉｒｅｍｅｎｔ  ｓｐｅｃｉｆｉｃａｔｉｏｎ）｛
Ｍｅａｎ  Ｄａｔａ  Ｒａｔｅ
Ｎｏｍｉｎａｌ  Ｄａｔａ  ｓｉｚｅ
Ｄｅｌａｙ  ｂｏｕｎｄ
Ｍａｘｉｍｕｍ  Ｐｏｌｌｉｎｇ  Ｉｎｔｅｒｖａｌ
Ｍｉｎｉｍｕｍ  Ｐｏｌｌｉｎｇ  Ｉｎｔｅｒｖａｌ
Ｍｉｎｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｒａｔｅ
Ｅｘｔｒａ  Ｂａｎｄｗｉｄｔｈ  Ｒａｔｉｏ
｝
上記構造体の要素は、ストリームの特性に応じて拡張してもよく、また省略しても良いことは当業者にとって明らかなことである。平均データレート（Ｍｅａｎ  Ｄａｔａ  Ｒａｔｅ）はトラヒックストリームのデータ提供要求を満足するために必要とされる帯域であり、トラヒック要求仕様を規定するレイヤーとの関連で測定される。データサイズ（Ｎｏｍｉｎａｌ  Ｄａｔａ  Ｓｉｚｅ）は、データ提供に用いられる媒体によって強いられるオーバヘッドを算出するために用いられる、ＭＡＣ層への基本データ入力ユニットを示すためのものである。遅延限界または許容遅延時間（Ｄｅｌａｙ  Ｂｏｕｎｄ）はトラヒックストリームの遅延許容値を特定するためのものである。最大／最小ポーリング周期（Ｍａｘｉｍｕｍ／Ｍｉｎｉｍｕｍ  Ｐｏｌｌｉｎｇ  Ｉｎｔｅｒｖａｌ）は媒体確保間隔の最大値／最小値である。ストリームのポーリング周期の値はこの最大値と最小値の間に存在しなければならない。最低情報伝送レート（Ｍｉｎｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  ｒａｔｅ：ＴＸＲ）は媒体を経由してトラヒックストリームを伝送するために用いることができる最低レートを特定するためのものである。余分帯域率（Ｅｘｔｒａ  Ｂａｎｄｗｉｄｔｈ  Ｒａｔｉｏ）は誤りのパケットを再送するために必要とされる帯域を特定するためのものであり、（平均データレート＋再送帯域）／平均データレートの計算結果で表示する。例えば、伝送ストリームがＳＤＴＶの場合、平均データレート＝６Ｍｂｐｓで、１０％のパケット誤りによる再送を行うと仮定すると、余分帯域率＝（６Ｍｂｐｓ＋６Ｍｂｐｓの１０％）／６Ｍｐｓ＝１．１である。
【００１１】
制御局ＡＰは前記のトラヒック要求仕様を受け付けた（１０２）後にデータストリームの情報伝送レートＴＸＲを決める（１０３）。ＩＥＥＥ８０２．１１ａ／ｅ規格では選択可能な情報伝送レートは表１のとおりである。情報伝送レートは基本的に前記の最低情報伝送レートより高ければどのレートでも選択可能だが、帯域利用効率のために、前記トラヒック要求登録フレームの伝送に利用される情報伝送レートが用いられる。
【００１２】
【表１】
2006080847.tif 000003
【００１３】
制御局ＡＰがＴＸＲを決めた後に「ポーリング周期（Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ）」や「各ポーリング周期に割り当てられる媒体占有持続時間（Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌｏｒＤ）」など様々なスケジュールパラメータを前記トラヒック要求仕様によって計算する（１０４）。計算に関する詳細は［１］に明記してあるためここでは省略する。その次、制御局ＡＰはスケジュールパラメータに基づいてポーリングスケジュールを生成する（１０５）。図２にポーリングスケジュールの例およびスケジュールパラメータの関係を示す。
【００１４】
そのあと、生成された前記ポーリングスケジュールを既存ストリームのポーリングスケジュールと摺り合わせるためにスケジューリングを行う（１０６）。
【００１５】
スケジューリングが成功した場合、制御局ＡＰはスケジュールを更新し、ストリームセットアップが成功したこととスケジュール情報を含めるトラヒック要求仕様登録の応答フレームを前記端末ＳＴＡに送信し、通知する（１１０）。その後、前記ＳＴＡはポーリングサービスによるストリーム伝送を行う（１１１）。
【００１６】
スケジューリングが失敗した場合、制御局ＡＰはスケジュールを更新せず、ストリームセットアップが失敗したことを含めるトラヒック要求仕様登録の応答フレームを前記端末ＳＴＡに送信し、通知する（１０８）。
【００１７】
ＩＥＥＥ８０２．１１ｅ規格に準する無線ＬＡＮシステムでは、伝送データのＱｏＳ条件（要求データレート、許容遅延時間など）が含まれる前記トラヒック要求仕様を確実に満足するために、制御局ＡＰはトラヒック要求仕様に基づいて計算された「Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ」や「Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌ」などのスケジュール情報に従いポーリングを行う［１］。トラヒック要求仕様に基づいたスケジュール情報の計算は基本的にマルチパスフェージングなどの伝播路特性の時間的変動によって誤るデータパケットの再送に必要な余分帯域を考慮して実行されるため、帯域不足問題が起きることなくデータのＱｏＳ保証が可能である。しかし、実際には端末の置き場所を変更したり、在室する人の人数や配置が変ったりすることなどによって送信側と受信側の間の「距離減衰」および「シャドーイング」の影響が大きく変化することがあるため初期のスケジュールによるポーリングサービスはいつまでもデータのＱｏＳが保証できるわけではない。
【００１８】
伝送距離の増加やシャドーイングの増加によって平均パケット誤り率が大きく増加する場合、伝送ストリームのＱｏＳを維持するために２つの方法が考えられる。１つは誤るデータパケットの増加に応じて再送に必要な余分帯域を増やす方法である。もう一つは伝送データの情報伝送レートＴＸＲを下げてパケット誤り率を改善させる方法である。再送に必要な帯域（再送帯域）を増やす方法はパケット誤りが下がらないため同一パケットが再送される回数（リトライ回数）の増加を防げない。リトライ回数が多くなればパケットの伝送遅延時間が許容遅延時間を越えてしまう確率も高くなるため、この再送帯域を増やす方法は許容遅延時間の条件が厳しいＶｏＩＰやビデオデータなどのＱｏＳ条件を満足できないことがある。一方、情報伝送レートＴＸＲを下げる方法はパケット誤り率と共にリトライ回数を改善できるが、ＴＸＲの減少に応じて「一回の媒体確保に割り当てなければならない媒体占有持続時間」（Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌ）を増やさなければならないため、チャネル利用効率と共に利用可能な合計帯域が減少してしまう。チャネルのエラー状態が変化した場合、誤りパケットの増加を適切に対処するために前記の２つ方法でどの方法を用いるべきかは重要である。本発明は、エラー状態およびトラヒック要求仕様に応じて前記誤りパケットの増加の対処法を選択しつつ帯域確保を周期的に調整する制御を行う。
【００１９】
図３は、本発明の実施形態に係る「送信側がエラー状態の変化に応じて対処法を判定するアルゴリズム」を示す図である。送信側が前記ストリームセットアップ過程を完了すると下記の５つの制御パラメータを決定する（２０２）。
１．ＰＥＲｔｈ（Ｔｈｒｅｓｈｏｌｄ  ｖａｌｕｅ  ｏｆ  Ｐａｃｋｅｔ  Ｅｒｒｏｒ  Ｒａｔｅ）
パケット誤り率のし閾値
２．△ＰＥＲｔｈ，（Ａｌｌｏｗａｂｌｅ  ｄｉｆｆｅｒｅｎｃｅ  ｃｏｍｐａｒｅｄ  ｔｏ  Ｔｈｒｅｓｈｏｌｄ  ｖａｌｕｅ  ｏｆ  Ｐａｃｋｅｔ  Ｅｒｒｏｒ  Ｒａｔｅ）
パケット誤り率のし閾値との差の許容値
３．△ＰＥＲ（Ａｌｌｏｗａｂｌｅ  ｄｉｆｆｅｒｅｎｃｅ  ｃｏｍｐａｒｅｄ  ｔｏ  ｔｈｅ  ｌａｓｔ  ｅｓｔｉｍａｔｅｄ  Ｐａｃｋｅｔ  Ｅｒｒｏｒ  Ｒａｔｅ）
前回の推定パケット誤り率との差の許容値
４．Ｒｅｔｒｙｔｈ（Ｔｈｒｅｓｈｏｌｄ  ｖａｌｕｅ  ｏｆ  Ｒｅｔｒｙ  ｔｉｍｅｓ）
リトライ回数のし閾値
５．ＨＲＰＲｔｈ（Ｔｈｒｅｓｈｏｌｄ  ｖａｌｕｅ  ｏｆ  Ｈｉｇｈ  Ｒｅｔｒｙ  Ｐａｃｋｅｔ  Ｒａｔｉｏ）
ハイリトライパケットの割合の閾値
注意：ハイリトライパケットは「リトライ回数がＲｅｔｒｙｔｈより多いリトライ中のパケット」である。
【００２０】
Ｒｅｔｒｙｔｈの値は基本的にトラヒック要求仕様のパラメータである「遅延限界」やスケジュールパラメータである「Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ」に基づいて決定される。
【００２１】
例えば、Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ＝１０ｍｓと制御局ＡＰに指定される時、ポーリング周期１０ｍｓごとに誤りパケットを１回しか再送できない条件がある場合、１回のリトライのために平均１０ｍｓがかかるとなるため、遅延限界＝１００ｍｓであればパケットが破棄されるまでに最大（１００／１０）−１＝９回の再送が可能である。この場合、Ｒｅｔｒｙｔｈを９より少ない値に設定するべきである。Ｒｅｔｒｙｔｈ値が低いほどハイリトライパケットと認定されるパケット数が多くなる。
【００２２】
送信側が周期的に「推定パケット誤り率ＰＥＲ」および「推定ハイリトライパケット率ＨＲＰＲ」を更新し、前記５つの制御パラメータと比較して図３のアルゴリズムによって下記事項を判定する（２０３）。
【００２３】
−帯域確保を調整する必要があるかどうか？
−必要であれば、パケット誤り率が増加または減少？
−「再送帯域の調整」が良いのかまたは「情報伝送レートＴＸＲの変更」が良いのか？
「推定パケット誤り率ＰＥＲ」および「推定ハイリトライパケット率ＨＲＰＲ」は基本的に受信側ではなく送信側で推定されるため図３におけるプロセスはすべて送信側で行われるとする。ＰＥＲおよびＨＲＰＲは下記のように定義される。
【００２４】
ＰＥＲ＝一定時間Ｔｅｓｔ内で誤ったパケット数／一定時間Ｔｅｓｔ内で送信された総パケット数
ＨＲＰＲ＝リトライ回数がＲｅｔｒｙｔｈ以上多いリトライ中のパケット数／リトライ中の総パケット数
ＰＥＲおよびＨＲＰＲの推定に用いられる一定時間Ｔｅｓｔはマルチパスフェージングによる誤りを平均化するためにある程度長く設定しなければならない。
【００２５】
図３のＰＥＲおよびＨＲＰＲの更新（２０３）が完了したあとの手順は下記のようになっている。
【００２６】
｜ＰＥＲ−ＰＥＲｔｈ｜≧ΔＰＥＲｔｈ式で推定パケット誤り率ＰＥＲとＰＥＲｔｈの差は△ＰＥＲｔｈより大きいかどうかを確認する（２０４）。
【００２７】
その差が△ＰＥＲｔｈより大きければ帯域確保を調整する必要があると判定し２のステップに移行する。
【００２８】
その差が△ＰＥＲｔｈより小さければ帯域確保を調整する必要がないと判定し、次回の更新時まで待つために７のステップに移行する。
【００２９】
｜今回のＰＥＲ−前回のＰＥＲ｜≧ΔＰＥＲ式で今回更新されたＰＥＲと前回のＰＥＲの差は△ＰＥＲより大きいかどうかを確認する（２０５）。
【００３０】
その差が△ＰＥＲより大きければ、ＰＥＲが安定してないと認識するため、帯域確保を調整する必要があると判定し３のステップに移行する。
【００３１】
その差が△ＰＥＲより小さければ、ＰＥＲが安定していると認識するため、帯域確保を調整する必要がないと判定し次回の更新時まで待つために７のステップに移行する。
【００３２】
ＰＥＲ≧ＰＥＲｔｈという式で今回更新されたＰＥＲがＰＥＲｔｈより大きいどうかを確認する（２０６）。
【００３３】
ＰＥＲがＰＥＲｔｈより大きければ、パケット誤り率が増加したと判定し、対処法を選択するため４のステップに移行する。
【００３４】
ＰＥＲがＰＥＲｔｈより少なければ、パケット誤り率が減少したと判定し、対処法を選択するため５のステップに移行する。
【００３５】
ＨＲＰＲ≧ＨＲＰＲｔｈという式で今回更新されたＨＲＰＲがＨＲＰＲｔｈより大きいかどうかを確認する（２２２）。
【００３６】
ＨＲＰＲがＨＲＰＲｔｈより大きければ、ハイリトライパケットの割合が高いと認識する。この場合パケット誤り率を下げないと破棄されるパケットが生じる確率が高いのでそれを事前に防ぐために情報伝送レートＴＸＲを下げるべきである（２２３）。情報伝送レートＴＸＲを下げるに伴い６のステップに移行する。
【００３７】
ＨＲＰＲがＨＲＰＲｔｈより小さければ、ハイリトライパケットの割合がまだ低いと認識する。この場合、破棄されるパケットが生じる確率が低いが、パケット誤り率が増加した分再送帯域を増やさなければならないため各ポーリング周期における伝送可能なパケット数を増やすべきと判定し、Ａｄｄ＿Ｐａｃｋｅｔ＝１とする（２２３）。各ポーリング周期における伝送可能なパケット数を増やすに伴い６のステップに移行する。
【００３８】
ＨＲＰＲ＜ＨＲＰＲｔｈという式で今回更新されたＨＲＰＲがＨＲＰＲｔｈより小さいかどうかを確認する（２１２）。
【００３９】
ＨＲＰＲがＨＲＰＲｔｈより小さければ、ハイリトライパケットの割合がまだ低いと認識する。この場合パケット誤り率も下がり、ハイリトライパケットの割合も低いので情報伝送レートＴＸＲを上げて帯域を節約するべきである（２２３）。情報伝送レートＴＸＲを上げるに伴い６のステップに移行する。
【００４０】
ＨＲＰＲがＨＲＰＲｔｈより大きければ、ハイリトライパケットの割合が高いと認識する。この場合、パケット誤り率が減少した分ハイリトライパケットの割合も後々に減少する傾向にあるため、帯域確保を調整する必要がないと判定し次回の更新時まで待つために７のステップに移行する。
【００４１】
図４および３ｂにおける媒体占有持続時間を調整する過程に移行する（２０７）。媒体占有持続時間の調整が完了すると７のステップに移行する。
【００４２】
今回ＰＥＲ、ＨＲＰＲ更新した時点から更新周期Ｔが経過するまで待つ（２０８）。更新周期Ｔが経過したら２０３のＰＥＲ、ＨＲＰＲ更新のステップに移行する。更新が完了したあと再び１のステップに移行する。
【００４３】
ＰＥＲ、ＨＲＰＲの更新周期Ｔはマルチパスフェージングによる誤りを平均化するためにある程度長く設定しなければならない。また、更新周期Ｔが短すぎると帯域確保の調整を行う頻度が高くなるため制御局ＡＰ側でも端末ＳＴＡ側でも本発明のプロセスによる負担が必要以上に多くなる。５ＧＨｚ帯のＩＥＥＥ８０２．１１ａ／ｅシステムでは、伝送距離およびシャドーイングの変化による影響のみに応じて制御することが望ましいため、ＰＥＲ、ＨＲＰＲの更新周期Ｔは基本的に数百ｍｓ〜数十ｓの間で設定される。
【００４４】
上記６のステップである「媒体占有持続時間を調整する過程」は送信側が制御局ＡＰか端末ＳＴＡかによってプロセスが若干異なるため図４および図５を用いて説明する。
【００４５】
図４に、送信側が制御局ＡＰの場合の「媒体占有持続時間を調整する過程」を示す。送信側は制御局ＡＰのため、図４におけるプロセスはすべて制御局ＡＰが行う。まず、制御局ＡＰはＡｄｄ＿Ｐａｃｋｅｔ＝１かどうかを確認する（３０１）。Ａｄｄ＿Ｐａｃｋｅｔ＝０であればＡからスタートする。Ａｄｄ＿Ｐａｃｋｅｔ＝１であればＢからスタートする。
【００４６】
情報伝送レートＴＸＲを変更する場合
３１１→Ｎ＝Ｒｏｕｎｄｕｐ（Ｒ＊Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ／Ｓ）でポーリング１回あたりの伝送可能なパケット数Ｎを計算する。ここで、Ｒは平均データレートで、Ｓはデータサイズである。ＲとＳはデータ要求仕様から参照できる。Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌはスケジュールパラメータのため既知である。
【００４７】
３１２→新たなＴＸＲで「Ｎデータパケット＋ＡＣＫ（承認）を得るために必要とされる持続時間とからなるバーストを伝送するために必要とされる媒体占有持続時間」Ｄを図６のように試算する。新たなＴＸＲは２１３または２２３で決定された新たな情報伝送レートＴＸＲである。
【００４８】
図６の場合はＩＥＥＥ８０２．１１ｅ規格で定められたＢｌｏｃｋ  ＡＣＫ伝送方式での伝送を想定した場合の計算例である。
【００４９】
３１３→ポーリング一回あたりの新たな媒体占有持続時間ＮＥＷ＿Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌはＮＥＷ＿Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌ＝Ｄとする。
【００５０】
３１４→既存ストリームを考慮してスケジューリングを行う。
【００５１】
３１５→スケジューリングが成功したかどうかを確認する。図８に、媒体占有持続時間調整後スケジューリングが成功した一例を示す。図９に、媒体占有持続時間調整後スケジューリングが失敗した一例を示す。
【００５２】
３１６→スケジュールが成功した場合、制御局ＡＰが、更新された新たなスケジュール情報を含めるフレームを端末ＳＴＡに送信し、通知する（図９に参照）。３１４のスケジューリングプロセスによって他のストリームのスケジュールも更新された場合、スケジュールが更新されたすべての端末ＳＴＡに対して制御局ＡＰが、更新されたスケジュール情報を含めるフレームを図９のように送信しなければならない。その後、通知した新たなスケジュール情報どおり端末ＳＴＡにポーリングサービスによるデータ伝送を継続する。
【００５３】
３１７→スケジュールが失敗した場合、制御局ＡＰがスケジュールを更新せず元のスケジュール情報に基づいてポーリングサービスによるデータ伝送を継続する。
【００５４】
再送帯域を増やす場合
３２１→Ｎ＝Ｒｏｕｎｄｕｐ（Ｒ＊Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ／Ｓ）でポーリング１回あたりの伝送可能なパケット数Ｎを計算する。ここで、Ｒは平均データレートで、Ｓはデータサイズである。ＲとＳはデータ要求仕様から参照できる。Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌはスケジュールパラメータのため既知である。再送に必要な帯域を増やすためにＮを１パケット増やす。従って、Ｎ＝Ｎ＋１とする。
【００５５】
３２２→現行のＴＸＲで「Ｎデータパケット＋ＡＣＫ（承認）を得るために必要とされる持続時間とからなるバーストを伝送するために必要とされる媒体占有持続時間」Ｄを図７のように試算する。図７の場合はＩＥＥＥ８０２．１１ｅ規格で定められたＢｌｏｃｋ  ＡＣＫ伝送方式での伝送を想定した場合の計算例である。
【００５６】
３２３→ポーリング一回あたりの新たな媒体占有持続時間ＮＥＷ＿Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌはＮＥＷ＿Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌ＝Ｄとする。
【００５７】
３２４→既存ストリームを考慮してスケジューリングを行う。
【００５８】
３２５→スケジューリングが成功したかどうかを確認する。
【００５９】
３２６→スケジュールが成功した場合、制御局ＡＰが、更新された新たなスケジュール情報を含めるフレームを端末ＳＴＡに送信し、通知する（図１１に参照）。３１４のスケジューリングプロセスによって他のストリームのスケジュールも更新された場合、スケジュールが更新されたすべての端末ＳＴＡに対して制御局ＡＰが、更新されたスケジュール情報を含めるフレームを図１１のように送信しなければならない。その後、通知した新たなスケジュール情報どおり端末ＳＴＡにポーリングサービスによるデータ伝送を継続する。その後、３２９に移行する。
【００６０】
３２７→スケジュールが失敗した場合、制御局ＡＰがスケジュールを更新せず元のスケジュール情報に基づいてポーリングサービスによるデータ伝送を継続する。
【００６１】
３２８→スケジュールが失敗したためＮの値を元に戻す。Ｎ＝Ｎ−１とする。その後、３２９に移行する。
【００６２】
３２９→Ａｄｄ＿Ｐａｃｋｅｔを初期化するためＡｄｄ＿Ｐａｃｋｅｔ＝０とする。
【００６３】
図５に、送信側が端末ＳＴＡの場合の「媒体占有持続時間を調整する過程」を示す。送信側は端末ＳＴＡのため、図４におけるプロセスは端末ＳＴＡが制御局ＡＰから協力を得て行う。まず、端末ＳＴＡはＡｄｄ＿Ｐａｃｋｅｔ＝１かどうかを確認する（３０１）。Ａｄｄ＿Ｐａｃｋｅｔ＝０であればＣからスタートする。Ａｄｄ＿Ｐａｃｋｅｔ＝１であればＤからスタートする。
【００６４】
情報伝送レートＴＸＲを変更する場合
３３１→端末ＳＴＡは希望のＴＸＲでトラヒック要求仕様を含めるフレーム（９０２）を制御局に送信し、トラヒック要求仕様の再登録を行う（図１２に参照）。希望のＴＸＲは２１３または２２３で決定された新たな情報伝送レートＴＸＲである。
【００６５】
３３２→制御局ＡＰはＮ＝Ｒｏｕｎｄｕｐ（Ｒ＊Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ／Ｓ）でポーリング１回あたりの伝送可能なパケット数Ｎを計算する。ここで、Ｒは平均データレートで、Ｓはデータサイズである。ＲとＳはデータ要求仕様から参照できる。Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌはスケジュールパラメータのため既知である。その後、新たなＴＸＲで「Ｎデータパケット＋ＡＣＫ（承認）を得るために必要とされる持続時間とからなるバーストを伝送するために必要とされる媒体占有持続時間」Ｄを図６のように試算する。図６の場合はＩＥＥＥ８０２．１１ｅ規格で定められたＢｌｏｃｋ  ＡＣＫ伝送方式での伝送を想定した場合の計算例である。
【００６６】
３３３→ポーリング一回あたりの新たな媒体占有持続時間ＮＥＷ＿Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌはＮＥＷ＿Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌ＝Ｄとする。
【００６７】
３３４→制御局ＡＰは既存ストリームを考慮してスケジューリングを行う。
【００６８】
３３５→制御局ＡＰはスケジューリングが成功したかどうかを確認する。図８に、媒体占有持続時間調整後スケジューリングが成功した一例を示す。図９に、媒体占有持続時間調整後スケジューリングが失敗した一例を示す。
【００６９】
３３６→スケジュールが成功した場合、制御局ＡＰが、更新された新たなスケジュール情報や成功を示すステータスなどを含めるフレーム（９０３）を端末ＳＴＡに送信し、通知する（図１２に参照）。３３４のスケジューリングプロセスによって他のストリームのスケジュールも更新された場合、スケジュールが更新されたすべての端末ＳＴＡに対して制御局ＡＰが、更新されたスケジュール情報を含めるフレームを図１１のように送信しなければならない。その後、通知した新たなスケジュール情報どおり端末ＳＴＡにポーリングを継続する。
【００７０】
３３７→スケジュールが失敗した場合、制御局ＡＰがスケジュールを更新せず、元のスケジュール情報や失敗を示すステータスなどを含めるフレーム（９０３）を端末ＳＴＡに送信し、通知する（図１２に参照）。その後、制御局ＡＰが元のスケジュール情報に基づいてポーリングを継続する。
【００７１】
再送帯域を増やす場合
３４１→端末ＳＴＡはＮ＝Ｒｏｕｎｄｕｐ（Ｒ＊Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ／Ｓ）でポーリング１回あたりの伝送可能なパケット数Ｎを計算する。ここで、Ｒは平均データレートで、Ｓはデータサイズである。ＲとＳはデータ要求仕様から参照できる。Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌはスケジュールパラメータのため既知である。再送に必要な帯域を増やすためにポーリング１回あたりの伝送可能パケット数（Ｎ）を１パケット増やす→Ｎ＝Ｎ＋１
端末ＳＴＡはＮ＝Ｒｏｕｎｄｕｐ（Ｎｅｗ＿Ｒ＊Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ／Ｓ）で新たな要求データレートＮｅｗ＿Ｒを逆算する。ここで、Ｎｅｗ＿Ｒはポーリング１回あたりの伝送可能パケット数（Ｎ）を１パケット増やした場合に必要とされる平均データレートである。Ｎｅｗ＿Ｒを求めた後、端末ＳＴＡはＮｅｗ＿Ｒをトラヒック要求仕様に表示し、前記トラヒック要求仕様を含めるフレーム（９０２）を制御局に送信し、トラヒック要求仕様の再登録を行う（図１２に参照）。ちなみに、Ｎｅｗ＿Ｒの代わりに、余分帯域率（Ｅｘｔｒａ  Ｂａｎｄｗｉｄｔｈ  Ｒａｔｉｏ：ＥＢＲ）＝Ｎｅｗ＿Ｒ／Ｒを表示しても良いである。
【００７２】
３４２→制御局ＡＰはＮ＝Ｒｏｕｎｄｕｐ（Ｎｅｗ＿Ｒ＊Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ／Ｓ）でポーリング１回あたりの伝送可能パケット数Ｎを計算する。端末ＳＴＡにＮｅｗ＿ＲではなくＥＢＲでトラヒック要求仕様の再登録を要求された場合はＮ＝Ｒｏｕｎｄｕｐ（Ｎｅｗ＿Ｒ＊Ｐｏｌｌｉｎｇ＿Ｉｎｔｅｒｖａｌ／Ｓ）でＮを求める。その後、現行のＴＸＲで「Ｎデータパケット＋ＡＣＫ（承認）を得るために必要とされる持続時間とからなるバーストを伝送するために必要とされる媒体占有持続時間」Ｄを図７のように試算する。図７の場合はＩＥＥＥ８０２．１１ｅ規格で定められたＢｌｏｃｋ  ＡＣＫ伝送方式での伝送を想定した場合の計算例である。
【００７３】
３４３→ポーリング一回あたりの新たな媒体占有持続時間ＮＥＷ＿Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌはＮＥＷ＿Ｔｍｉｎ＿ｐｅｒ＿ｐｏｌｌ＝Ｄとする。
【００７４】
３４４→制御局ＡＰは既存ストリームを考慮してスケジューリングを行う。
【００７５】
３４５→制御局ＡＰはスケジューリングが成功したかどうかを確認する。
【００７６】
３４６→スケジュールが成功した場合、制御局ＡＰが、更新された新たなスケジュール情報や成功を示すステータスなどを含めるフレーム（９０３）を端末ＳＴＡに送信し、通知する（図１２に参照）。３４４のスケジューリングプロセスによって他のストリームのスケジュールも更新された場合、スケジュールが更新されたすべての端末ＳＴＡに対して制御局ＡＰが、更新されたスケジュール情報を含めるフレームを図１１のように送信しなければならない。その後、通知した新たなスケジュール情報どおり端末ＳＴＡにポーリングを継続する。その後、３４９に移行する。
【００７７】
３４７→スケジュールが失敗した場合、制御局ＡＰがスケジュールを更新せず、元のスケジュール情報や失敗を示すステータスなどを含めるフレーム（９０３）を端末ＳＴＡに送信し、通知する（図１２に参照）。その後、制御局ＡＰが元のスケジュール情報に基づいてポーリングを継続する。
【００７８】
３４８→スケジュールが失敗したためＮの値を元に戻す。Ｎ＝Ｎ−１とする。その後、３２９に移行する。
【００７９】
３４９→端末ＳＴＡはＡｄｄ＿Ｐａｃｋｅｔを初期化するためＡｄｄ＿Ｐａｃｋｅｔ＝０とする。
【産業上の利用可能性】
【００８０】
本発明は宅内無線ネットワークにおけるテレビ信号やＶｏＩＰ信号の安定的な伝送を実現することに有用である。
【図面の簡単な説明】
【００８１】
【図１】ストリームセットアップ手順を示すフローチャート
【図２】ポーリングスケジュールの例およびスケジュールパラメータの関係を示す図
【図３】エラー状態の変化に応じて対処法を判定するアルゴリズムを示すフローチャート
【図４】媒体占有持続時間を調整する手順を示すフローチャート（制御局がストリーム送信側）
【図５】媒体占有持続時間を調整する手順を示すフローチャート（端末がストリーム送信側）
【図６】情報伝送レートを変更する場合におけるポーリング１回あたりの媒体占有持続時間の算出方法を説明する図
【図７】再送帯域を増やす場合におけるポーリング１回あたりの媒体占有持続時間の算出方法を説明する図
【図８】スケジューリングが成功した場合における媒体占有持続時間調整後のスケジュールの更新方法を説明する図
【図９】スケジューリングが失敗した場合における媒体占有持続時間調整後のスケジュールの更新方法を説明する図
【図１０】本願発明の一実施の形態を説明する図
【図１１】制御局ＡＰがストリーム送信側の場合における媒体占有持続時間を調整するための情報交換について説明する図
【図１２】端末ＳＴＡがストリーム送信側の場合における媒体占有持続時間を調整するための情報交換について説明する図
【図１】
2006080847.tif 000004
【図２】
2006080847.tif 000005
【図３】
2006080847.tif 000006
【図４】
2006080847.tif 000007
【図５】
2006080847.tif 000008
【図６】
2006080847.tif 000009
【図７】
2006080847.tif 000010
【図８】
2006080847.tif 000011
【図９】
2006080847.tif 000012
【図１０】
2006080847.tif 000013
【図１１】
2006080847.tif 000014
【図１２】
2006080847.tif 000015