(57)【要約】  無線ローカルエリアネットワークにおけるＱｏＳ（Quality of Service：サービス品質）を管理する方法は、トラフィックフローを受け取ることにより開始する（３０２）。トラフィックフローは、そのトラフィックフローのＱｏＳ要件に基づき、ＴＣ（Traffic Class：トラフィッククラス）に写像される（３０４）。ＡＣ（Access Class：アクセスクラス）（それぞれのＡＣは少なくとも１つのＴＣを含む）の送信予算が計算される（３０６）。その送信予算がトラフィックフローを支援可能か否かを計算することにより、そのトラフィックフローを許可可能か否かの判定が為される（３０８）。トラフィックフローが許可された場合には、ＴＣのパラメータが調整され、既存のトラフィックフローと新規に許可されたトラフィックフローとの間のＴＣにおける衝突が処理される（３１４）。
2007511174.tif 000002
【特許請求の範囲】
【請求項１】
無線ローカルエリアネットワークにおいてサービス品質（ＱｏＳ：Quality of Service）を管理する方法であって、
トラフィックフローを受け取るステップと、
前記トラフィックフローのＱｏＳ要件に基づき、前記トラフィックフローをＴＣ（Traffic Class：トラフィッククラス）へ写像するステップと、
ＡＣ（Access Class：アクセスクラス）の送信予算を計算することであって、それぞれのＡＣが少なくとも１つのＴＣを含むステップと、
前記送信予算が前記トラフィックフローを支援可能か否かを計算することにより、前記トラフィックフローを許可可能か否かを判定するステップと、
前記トラフィックフローが許可された場合には、前記ＴＣのパラメータを調整することと、
前記ＴＣにおける既存のトラフィックフローと前記新規に許可されたトラフィックフローとの間の衝突を処理するステップと
を備えることを特徴とする方法。
【請求項２】
前記送信予算が、ＡＣに対する最大の許容送信予算から該ＡＣにより既に使用された送信予算を差し引いたものに等しいことを特徴とする請求項１に記載の方法。
【請求項３】
前記トラフィックフローの優先度を判定するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記トラフィックフローが許可されなかった場合、前記トラフィックフローの優先度が低い場合には前記トラフィックフローを廃棄することを特徴とする請求項３に記載の方法。
【請求項５】
前記トラフィックフローが許可されなかった場合、前記トラフィックフローの優先度が高い場合には前記トラフィックフローをバッファリングすることを特徴とする請求項３に記載の方法。
【請求項６】
無線ローカルエリアネットワークにおいてサービス品質を管理する方法であって、
トラフィックストリームのパラメータを含むＴＳＰＥＣ（Traffic specification：トラフィック仕様）を含む前記トラフィックストリームの要求を受け取るステップと、
前記ＴＳＰＥＣに含まれる前記パラメータを分析するステップと、
前記分析されたパラメータに基づき、前記トラフィックストリームを許可可能か否かを判定するステップと、
前記パラメータを変更することなく前記トラフィックストリームを許可可能な場合、前記トラフィックストリームを許可するステップと、
前記パラメータを変更することにより前記トラフィックストリームを許可可能な場合、前記パラメータを再折衝し、該再折衝されたパラメータにより前記トラフィックストリームを許可するステップと、
前記トラフィックストリームを許可可能でない場合、前記トラフィックストリームを拒否するステップと
を備えることを特徴とする方法。
【請求項７】
前記許可されたトラフィックストリームによるシステム性能に関してスケジューラにフィードバックを提供するために、トラフィックを監視／ポリシングする機能および適合化機能を呼び出すステップであって、前記スケジューラが違反しているトラフィックストリームを廃棄するステップと、
サービススケジュールを更新するステップと、
前記呼び出すステップおよび更新するステップが、前記許可するステップおよび前記再折衝するステップのうちの一方の後に実行されるステップとをさらに備えることを特徴とする請求項６に記載の方法。
【請求項８】
前記更新するステップは、サービススケジュールがが未だ存在していない場合、サービススケジュールを生成することを含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記判定するステップは、
送信予算を計算することと、
前記トラフィックストリームの要件を前記送信予算と比較することと、
前記送信予算が前記トラフィックストリームを支援可能である場合には、前記トラフィックストリームを許可することと
を含むことを特徴とする請求項６に記載の方法。
【請求項１０】
前記再折衝するステップは、前記トラフィックストリームのデータ速度を変更することを含むことを特徴とする請求項６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＷＬＡＮ（Wireless Local Area Network：無線ローカルエリアネットワーク）に関し、より詳細には、ＷＬＡＮにおけるＱｏＳ（Quality of Service：サービス品質）仕様を管理する方法およびシステムに関する。
【背景技術】
【０００２】
無線通信システムは当技術分野ではよく知られている。一般に、そのようなシステムは通信局（communication station）を含み、通信局は互いの間で無線通信信号を送信かつ受信する。システムの種類により、通信局は通常、基地局か、あるいは移動体端末を含むＷＬＡＮ（Wireless Local Area Network：無線送受信ユニット）の、２つの種類のうちの１つである。
【０００３】
本願にて用いられる用語「基地局」には、限定するものではないが、基地局、ノード（Ｎｏｄｅ）Ｂ、サイト制御装置、アクセスポイント（ＡＰ：Access Point）、または無線の環境においてその基地局に関連付けられているネットワークへの無線アクセスをＷＴＲＵに提供する他のインタフェース装置が含まれる。ＷＬＡＮにおいては、ＡＰが好適な装置であり、本発明を記述するために本願にて使用する。
【０００４】
本願にて用いられる用語「ＷＴＲＵ」には、限定するものではないが、ユーザ設備、移動局、固定式または移動式の加入者ユニット、ページャ、または無線の環境において動作する能力を有する他の種類のいかなる装置もが含まれる。ＷＴＲＵには、電話機、テレビ電話、およびネットワーク接続を有するインターネット対応電話などの、個人用の通信装置が含まれる。さらにＷＴＲＵには、同様のネットワーク能力を有する無線モデムを持つＰＤＡやノートパソコンなどの、携帯型個人用コンピュータ装置が含まれる。携帯可能な、またはそうでなくとも位置を変えることが可能なＷＴＲＵは、移動体ユニットと呼ばれる。ＷＬＡＮにおいては、ＳＴＡ（station：局）が好適な装置であり、本発明を記述するために本願にて使用する。
【０００５】
１つまたは複数のＡＰを有する一般的なＷＬＡＮ環境は、ＩＥＥＥ８０２．１１の規格群のうちの１つに対応して構築される。ＢＳＳ（Basic Service Set：基本サービスセット）は、８０２．１１ＷＬＡＮの基本的な構築ブロックであり、複数のＳＴＡから成る。互いに信号を伝達することができるＳＴＡの１つの集合はＢＳＳを形成することが可能である。複数のＢＳＳが、ＤＳ（Distribution System：接続システム）と呼ばれる構造上の構成要素により相互接続され、ＥＳＳ（Extended Service Set：拡張サービスセット）を形成する。ＡＰはＤＳサービスを供給することによりＤＳへのアクセスを提供するＳＴＡであり、一般に複数のＳＴＡによるＤＳへの同時アクセスを可能とする。
【０００６】
ＷＬＡＮ規格の８０２．１１ａ／ｂ／ｇに適合するシステムは、広範囲に普及している。ＱｏＳ（Quality of Service：サービス品質）を使用できるＷＬＡＮもまた、出現しつつある。ＱｏＳの解決法／仕様は、独自的解決法と標準化された解決法とで異なり、標準の解決法でさえ２つの種類のＱｏＳ方式を有する。すなわち、８０２．１１ｅのＥＤＣＡ（Enhanced Distribution Coordination function：拡張型分散調整機能）および８０２．１１ｅのＨＣＣＡ（Hybrid Coordination function：複合型調整機能）の２つの方式である。
【０００７】
８０２．１１ｅのＱｏＳ機能は、ＱＢＳＳ（QoS Enhanced Basic Service Set：ＱｏＳ拡張型基本サービスセット）だけに使用される新しいＨＣＦ（Hybrid Coordination Function：複合型調整機能）を定義する。ＨＣＦには、２つの動作モードがある。すなわち、競合動作を有するＨＣＦ（また、ＥＤＣＡとしても知られる）、および聞き取り（poll）アクセス動作を有するＨＣＦである。
【０００８】
これらのチャンネルアクセス機能により利用される基本構想はＴＸＯＰ（transmission opportunity：送信機会）である。ＴＸＯＰは、与えられた期間に対して、ＳＴＡがフレームの送信を開始することが可能な時点である。ＴＸＯＰの間、ＳＴＡはそのＴＸＯＰにおいて可能な限り多くのフレームを送信することが可能であり、このＴＸＯＰはデータに関連付けられたＴＣ（Traffic Class：トラフィッククラス）に従って設定される。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ＥＤＣＡとＨＣＣＡとの間の主要な相違点は、受付制御の処理の仕方である。ＥＤＣＡにおいては、受付制御はＤＡＣ（Distributed Admission Control：分散型受付制御）機能により処理され、この機能はそれぞれのＴＣに対しての媒体の利用割合を測定する。未使用の媒体の割合は、そのＴＣに対して利用可能な送信予算として知られる。送信予算がゼロに近付くにつれ、新規トラフィックフローを追加しまたは既存のトラフィックフローを修正することについて、制約が課されることになる。
【００１０】
ＨＣＣＡにおいては、ＳＴＡが、トラフィックフローのＴＣに基づきそれぞれのトラフィックフローに対するその特定の予約パラメータを要求する。そして、ＨＣＦは、拒否するか、受け容れるか、または、要求しているＳＴＡに対して代替のパラメータ群を提供することが可能である。これはＤＡＣより堅固である（ｒｏｂｕｓｔ）ため、トラフィックフローは、適切に計画される必要がある。
【課題を解決するための手段】
【００１１】
無線ＬＡＮにおいてサービス品質（ＱｏＳ）を管理する方法は、トラフィックフローを受け取ることにより開始される。トラフィックフローは、そのトラフィックフローのＱｏＳ要件に基づき、ＴＣ（Traffic Class：トラフィッククラス）に写像される。ＡＣ（Access Class：アクセスクラス）（それぞれのＡＣは、少なくとも１つのＴＣを含む）の送信予算が計算される。その送信予算がトラフィックフローを支援可能か否かを計算することにより、そのトラフィックフローを許可可能か否かの判定が為される。トラフィックフローが許可された場合には、そのＴＣのパラメータが調整され、既存のトラフィックフローと新規に許可されたトラフィックフローとの間のそのＴＣでの衝突が処理（ｍａｎａｇｅ）される。
【００１２】
無線ＬＡＮにおいてサービス品質（ＱｏＳ）を管理する方法は、そのトラフィックストリームのパラメータが入ったトラフィック仕様（ＴＳＰＥＣ：Traffic specification）を含むトラフィックストリーム要求を受け取ることにより開始される。ＴＳＰＥＣに含まれるパラメータが分析され、そしてそのトラフィックストリームを許可できるか否かの判定が為される。パラメータを変更することなく許可できる場合には、そのトラフィックストリームは許可される。パラメータを変更することによりトラフィックストリームを許可できる場合には、パラメータが再折衝（renegotiate）され、そして次に、そのトラフィックストリームは再折衝されたパラメータにより許可される。トラフィックストリームを許可することができなかった場合には、そのトラフィックストリームは拒否される。
【００１３】
本発明のより詳細な理解は、例として与えられた好適な実施例に関する以下の記述から獲得され、そして添付図面に関連して理解されるべきものである。
【発明を実施するための最良の形態】
【００１４】
図１は、一般的なＱｏＳの構造（architecture）１００を示す。構造１００は、ＤＣＦ（Distributed Coordination Function：分散型調整機能）、ＥＤＣＡ（Enhanced Distributed Coordination Function：拡張分散型調整機能）、またはＨＣＦ（Hybrid Coordination Function：複合型調整機能）のＨＣＣＡ（HCF Controlled Channel Access：制御チャンネルアクセス）方式に容易に適用可能である。構造１００は、物理層１０２、ＭＡＣ（Medium Access Control：媒体アクセス制御）層１０４、およびネットワーク層１０６を含む。ネットワーク層１０６は、トラフィック分類子、トラフィックシェイピング（shaping）、スケジューラ、パラメータ化、受付制御、トラフィックの監視／ポリシング（policing）、および適合化（adaptation）などのＱｏＳ手順を含む。
【００１５】
図２には送信に対する通信データ処理のための一般的なＱｏＳ手順２００を図示する。トラフィックフロー（すなわち、少なくとも１つのデータパケット）を、上位層から受け取る（ステップ２０２）。そのトラフィックフローは、受け取られた特定の種類の通信データに対するＱｏＳ要件に従い、１つのＴＣ（Traffic Class：トラフィッククラス）に分類される（ステップ２０４）。
【００１６】
受付制御において、アプリケーションは、帯域幅や待ち時間など、ＡＰからの特定のリソースを要求する。ＱｏＳ要件、ネットワーク負荷、無線媒体の条件、およびトラフィックフローにより、受付制御はこれらの要求を受け容れまたは拒否することが可能である（ステップ２０６）。
【００１７】
トラフィックシェイピング制限が使用され、チャンネルが過負荷にならないよう、トラフィックフローが制御される（ステップ２０８）。トラフィック制限の間に、最大データ速度または量に達した場合には、いくつかのデータ送信を遅延させることが可能であり、および／または、超過したデータを廃棄することが可能である。
【００１８】
スケジューラは、異なるトラフィックフロー群のチャンネルアクセスをそれらの優先度およびそれらのＱｏＳ要件に基づき制御することにより、データパケットを何時送るべきであるかを決定する（ステップ２１０）。
【００１９】
ＭＡＣパラメータ化処理では、ＱｏＳ要件に基づき、システムパラメータを設定し、かつ動的に調整する。これらのパラメータは、それぞれのＴＣに対して設定され、ＣＷｍｉｎ（minimum Contention Window：最小コンテンションウィンドウ）値、ＣＷｍａｘ（maximum Contention Window：最大コンテンションウィンドウ）値、ＡＩＦＳ（Arbitrary Interframe Space：フレーム間隔調整）値、ＰＦ（Persistence Factor：存続係数）値、およびＴＸＯＰ値を含む（ステップ２１２）。ＥＤＣＡにおいては、衝突の後に、ＣＷ（コンテンションウィンドウ）はＰＦ値により拡げられる。ＰＦ値は、衝突の後にＣＷを２倍、３倍などにするべきかを決定するであろう。
【００２０】
トラフィックフローを制御するために、データパケットは監視されポリシングされる（ステップ２１４）。（パケットのタイムスタンプからの）上りストリームのパケット到着時間間隔および下りストリームのパケット送信時間間隔が監視される。期限切れの数（特定のサービスの型に対する許容遅延量より長時間データが遅延した回数）および遅延変化量（すなわち、ジッター）などのフィードバックが、それぞれのフローに対して提供される。
【００２１】
システム設定に対する調整が為され、変化するネットワーク条件に適合させる（ステップ２１６）。適合化の間には、トラフィック監視機能から獲得されたフィードバックにより、スケジューラはその予定を変更し、上位層との取り決めを再折衝し、優先度の低いトラフィックフローを下げ、またはパラメータを変更して、その時点の状況に適合させる。なお、上記再折衝において、スケジューラは、上位層に対してトラフィックを抑えることを要求し、特定のサービスに対する帯域幅の供給を減らすことを要求し、または許可ユーザを減らすことを要求することが可能である。
【００２２】
フィードバック機能は、適合化機能により発生したフィードバックを他の機能に提供する（ステップ２１８）。
【００２３】
（ＤＣＦに基づくＱｏＳ手順）
図２に関連して記述された一般的な概要が、ＤＣＦに基づくＱｏＳのアルゴリズムおよび手順に容易に使用できる。ＤＣＦの場合、すべてのトラフィックフローが同じと仮定することができる。トラフィックフローの間での公平さを保証するために、１ユーザあたりの下りリンクアクセス機会の相対数を、スケジューリングにより制御することが可能である。公平さについては種々の概念を適用することができる。例えば、すべてのユーザが同一量の下りリンク帯域幅を有すること、すべてのユーザが同等なグッドプット（「再送信」を含めたスループット：goodput）を有すること、またはすべてのパケットに同様の待ち行列遅延があることを保証するよう試みることが可能である。
【００２４】
上りリンクのスケジューリングを直接制御することはできないが、ＴＣＰトラフィックに対しては、上りリンクのＴＣＰ  ＡＣＫを接続システムに送る前に、ＡＰは当該ＴＣＰ  ＡＣＫを操作することが可能である。これにより、個々のＳＴＡが送信する上りリンクトラフィックの速度について何らかの間接的な制御が可能となる。
【００２５】
ＤＣＦはまた、トラフィック制限において、スケジューリング方針と一致するパケット廃棄機能を実施可能である（例えば、ユーザ帯域幅が広過ぎる場合、パケットの待ち行列があまりにも長い場合、または、無作為に、パケットを廃棄する）。輻輳時にＭＡＣスケジューリングの機会を減少させることにより、ユーザの最大の下りリンク帯域幅を制限することが可能である。下りリンクスケジューリングは、パケットの待ち行列遅延を制御することに基づき優先化することが可能である。
【００２６】
高い誤り率を有するユーザの下りリンク帯域幅を制限することが可能である。高い誤り率を有するリンクとは、高い確率で次の送信がエラーになる（帯域幅を浪費する）であろうことを意味する。またエラーとは、ＡＰが帯域幅へのアクセスを抑え、そのＣＷを増大させねばならないことを意味する。
【００２７】
ＤＣＦに基づく手順の間、受付制御が使用され、利用可能な無線リソースおよびリンク条件によりユーザを許可する。ユーザが許可された後に、トラフィックシェイピングを使用して、トラフィックを遅延させまたはパケットを廃棄することにより、過負荷な状況を処理する。スケジューラを使用して、公平さを含む多くの判定基準に基づき、どのユーザが次のパケットを送るかを選択する。
【００２８】
（ＥＤＣＡに基づくＱｏＳ手順）
図３には、ＥＤＣＡに基づくＱｏＳ手順３００に関する上位水準のフロー図を示す。上位層からトラフィックフロー（すなわち、１つまたは複数のデータパケット）を受け取る（ステップ３０２）。そのトラフィックフローは、そのＱｏＳ要件に基づき、適切なＴＣ（Traffic Class：トラフィッククラス）に写像される（ステップ３０４）。トラフィックフローは、ネットワーク性能（すなわち、チャンネル品質およびトラヒック負荷）に対するＱｏＳ要件および前回の測定ウィンドウに基づき、種々のＴＣに動的に写像されることが望ましい。システムのその時点のトラヒック負荷、最新のビーコン周期に対する測定値およびネットワーク条件と共に、それぞれのパケットの優先度が確認される（ステップ３０６）。
【００２９】
ＱｏＳの目的は、優先度の低いトラフィックから優先度の高いトラフィックを分離することである。ＷＬＡＮにおいては、媒体の過負荷を回避するために、１つの高優先度トラフィックフローを別の高優先度トラフィックフローから分離することが必要な場合がある。ＷＬＡＮに関する利用可能リソースを監視し、かつ新規なトラフィックフローを許可するか否かの判定を為すことにより、この目的のために受付制御が使用される。
【００３０】
受付制御（ＥＤＣＡを有するＤＡＣ）において、送信予算がそれぞれのＡＣ（Access Category：アクセス分類）に対して定義され、それぞれのＴＣは１つのＡＣに対応し、１つのＡＣは複数のＴＣを含むことが可能である。この方式は、（ＡＣ単位で定義される）ＱｏＳ要件のそれぞれのクラスに対する遅延および待ち時間の要件を考慮し、かつ前回の測定ウィンドウに対する期限切れの数、スループットおよび遅延変化量などの観測された測定値に従って、送信予算が適合させられる。送信予算はまた、トラフィックの監視／ポリシング機能からのフィードバックに応じて調整される。
【００３１】
トラフィックフローが許可判定基準を満たすか否かを判定するために（ステップ３０８）、送信予算が評価される。十分なリソースがある場合（すなわち、送信予算がそのトラフィックフローを支援するのに十分な大きさである場合）にのみ、トラフィックフローは許可されるであろう。ＡＣあたりの送信予算は、そのＡＣに対する最大許容送信予算からそのＡＣによって既に使用された送信予算を差し引いたものと等しい。
【００３２】
許可判定基準が満たされた場合には（ステップ３０８）、次にその時点のトラフィッククラスに対するパラメータが、最新の条件および観測された測定値に基づき動的に調整される（ステップ３１０）。許可判定基準が満たされない場合には、次にそのトラフィックフローは廃棄されるか、またはバッファリングされる（ステップ３１２）。トラフィックフローが廃棄されるかバッファリングされるかは、その優先度（例えば、サービスの種類またはクラス）に基づく。高い優先度のトラフィックフローはバッファリングされ、低い優先度のトラフィックフローは廃棄される。例えば、そのトラフィックフローが緊急サービスのデータに関連する場合には、バッファリングされるであろうが、一方そのトラフィックフローがＦＴＰデータなどの一般の背景的（background）データに関連する場合には、そのトラフィックフローは廃棄されるであろう。トラフィックフローがバッファリングされると、手順３００はステップ３０８を上述したように続行する。
【００３３】
その時点のトラフィックフローが許可または廃棄された後に、スケジューラはそれぞれのトラフィックフローの優先度に基づき内部のデータ衝突を処理し、トラフィック監視レポートに従い、それぞれのＴＣに対するパラメータを動的に調整する（ステップ３１４）。そして、手順は終了する（ステップ３１６）。
【００３４】
（ＨＣＦ制御チャンネルアクセス（ＨＣＣＡ）に基づくＱｏＳ手順）
図４には、ＨＣＦ制御チャンネルアクセス（ＨＣＣＡ）に基づくＱｏＳ手順４００を示す。手順４００は、トラフィックストリームの追加または修正の要求を受け取ることにより開始する（ステップ４０２）。この要求には、そのトラフィックストリームに関連するＴＳＰＥＣにおけるそのトラフィックストリームに対する予約パラメータが含まれる。利用可能なチャンネル容量、リンク条件、再送信の限界、優先度およびＴＳＰＥＣのＱｏＳ要件が確認される（ステップ４０４）。最小および最大のサービス間隔、ＴＸＯＰ持続時間などの、スケジューリングパラメータが決定される（ステップ４０６）。次に、必要な速度および遅延領域にてトラフィックストリームを許可可能か否かの判定が為される（ステップ４０８）。ＴＳＰＥＣパラメータから、トラフィックストリームの要件が、利用可能な送信予算と比較される。ビーコン期間の間にトラフィックストリームを送るために必要な時間が、トラフィックストリームに関するＱｏＳ要件を満たすために必要である使用可能時間より少ない場合には（すなわち、送信予算がトラフィックストリームを収容するに十分な大きさである場合には）、その追加のトラフィックストリームが許可されるであろう。
【００３５】
そのトラフィックストリームが許可されない場合には、次にそのトラフィックストリームの要求は拒否され（ステップ４１０）、手順は終了する（ステップ４１２）。
【００３６】
そのトラフィックストリームをより低い要件で部分的に許可することができる場合には（ステップ４０８）、次に上位層と再折衝することによりＴＳＰＥＣが修正され、これは一般にそのトラフィックストリームが代替えのデータ速度により許可されるであろうことを意味する（ステップ４１４）。他のパラメータを上位層と再折衝することも可能ではあるが、トラフィックストリームに対して割り当てられた帯域幅を減少させるためにはデータ速度が最も頻繁に調整される。
【００３７】
そのトラフィックストリームが許可基準（ステップ４０８）を満足した場合には、そのトラフィックストリームは許可され、トラフィックの監視／ポリシングおよび適合化機能が呼び出され、システム性能に関するフィードバックをスケジューラに提供し、かつ違反しているトラフィックストリームを廃棄することが可能である（ステップ４１６）。違反しているトラフィックストリームは、(１)過大な再送信（これは媒体の時間を浪費する可能性がある）、または、（２）上位層のアプリケーションが予想水準を超えるトラフィックを発信（これは輻輳を引き起こす可能性がある）、により生じる可能性がある。後者の場合は、低優先度トラフィックストリームが廃棄され、輻輳を軽減する場合がある。
【００３８】
サービススケジュールが生成され、または更新され（ステップ４１８）、手順は終了する（ステップ４１２）。サービススケジュールはそれぞれのビーコン期間に、どのトラフィックストリームがそのビーコン期間に送られるかということを含め、どのようにトラフィックを計画するかを指示する。トラフィック監視および前回の測定ウィンドウに対して観測された測定値からのフィードバックに基づき、サービススケジュールを適合させることが望ましい。
【００３９】
以上の記述は、限定するものとしてではなく、単なる一例として、８０２．１１の種類のシステムに対する参照となるものである。本発明に合致する他の変更および修正は通常の当業者によって認識されるであろう。
【００４０】
本発明の特徴および要素を特定の組み合わせにおける好適な実施形態にて記述したが、それぞれの特徴または要素を単独で（好適な実施形態の他の特徴および要素なしで）、または本発明の他の特徴および要素のあるなしにかかわらず様々な組み合わせにて、使用可能である。本発明の特定の実施形態を示し記述してきたが、当業者であれば、本発明の範囲から逸脱することなく、多くの修正および変更を為すことができる。上の記述は、例証するために役立つものであり、特定の発明を、多少なりとも限定しようとするものではない。
【図面の簡単な説明】
【００４１】
【図１】本発明によるＱｏＳ構造のブロック図である。
【図２】本発明による一般的なＱｏＳ手順のフロー図である。
【図３】本発明によるＥＤＣＡに基づくＱｏＳ方式のフロー図である。
【図４】本発明によるＨＣＦ制御チャンネルアクセスに基づくＱｏＳ方式のフロー図である。
【図１】
2007511174.tif 000003
【図２】
2007511174.tif 000004
【図３】
2007511174.tif 000005
【図４】
2007511174.tif 000006
【国際調査報告】
2007511174.tif 000007