JP3913016B2 - 無線通信を行うデバイス、及び方法 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、無線ネットワークを介した通信分野に関し、より詳細には、ネットワーク層を必要とすることなく、第２層においてアドミッション制御を実行することによりネットワークを形成する無線通信を行うデバイス、及び方法に関する。
【０００２】
【従来の技術】
データを転送するためにローカルエリアネットワーク（ＬＡＮ）を使用することが増加している。ＷＬＡＮとしても知られる無線ＬＡＮは比較的新しいアプリケーションである。これら無線ＬＡＮは異なる局を物理的に互いに結合することなく、有線ＬＡＮの利点を提供できる。また、データを転送するために同軸線、ツィストペア・ケーブル、光ファイバなどの伝送ワイヤを購入する必要がない。その代わりにマイクロウェーブとしても知られる無線周波数（ＲＦ）波または光波、例えば赤外線（ＩＲ）光のいずれかを使用して空中を通してデータを転送する。伝送線を構成部品に接続することなく、構成部品を接近させることによってネットワークを形成できる。
【０００３】
無線に基づくＷＬＡＮは有線ＬＡＮの特徴と異なるいくつかの特徴を有する。これら特徴として、達成できるデータ容量が低いことが挙げられるが、これは多数の要因によるものである。これら要素としては、バンド幅および電力が限られていること、エラーレートがより高いこと、通信容量が時間と共に変化し、また特定の送信源および送信宛て先地に応じて変わり得ることが挙げられる。通信容量の変化は妨害信号によっても生じ得る。
【０００４】
その他の多数の特徴は同じままである。これら特徴の１つとして、通信を実現するための主要なソフトウェアアーキテクチャがある。ＷＬＡＮは多層通信プロトコルスタック、例えば標準の開放型システム間相互接続（ＯＳＩ）管理にコンパーチブルなアーキテクチャを使用できる。このアーキテクチャはインターネットにも使用されている。このアーキテクチャの多くはインターネット技術標準化委員会（ＩＥＴＦ）によって作成された文献に文書化されている。
【０００５】
ＯＳＩアーキテクチャの一例について次に示す。特に説明しない限り、本明細書における用語は、ＩＥＴＦの定義と一致するように解釈すべきである。なお、ＩＥＴＦはこれら規格をサーチできるウェブサイトを維持しており、このウェブサイトのアドレスは本明細書を最初に米国特許庁に出願した日の時点で、ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／となっている。
【０００６】
図１は、周辺局から予約リクエストを解決する従来技術におけるＡＰデバイスのアーキテクチャの図である。図１を参照すると、アクセスポイント（ＡＰ）デバイス１１０は物理媒体１２０を含み、この媒体１２０は送信アンテナ、受信アンテナなどでよく、この媒体１２０はＷＬＡＮにおける他の無線通信デバイスとのデータの無線交換を行うためのものである。
【０００７】
ＡＰデバイス１１０はＯＳＩによって定められた多数の層を含むソフトウェア構造も含む。これら層は物理層１３０とも称される層Ｌ１（１３０）を含み、この層は物理媒体１２０を制御するためのものである。この層Ｌ１（１３０）の上位には層Ｌ２（１４０）が設けられ、この層Ｌ２（１４０）の上位に層Ｌ３（１５０）が設けられている。層Ｌ３（１５０）はネットワーク層１５０とも称される。他の層（図１には示されず）を設けることもできる。
【０００８】
従来の有線ＬＡＮと同じ別の特徴として、多数の周辺局から同時に送信がなされることを防止する必要があることが挙げられる。同時送信はこれが認められた場合、受信中のデータが劣化することになる。
【０００９】
一旦、通信スキームを確立すれば、同時送信は一般にポーリング技術によって防止される。かかるポーリング技術では周辺局はＡＰデバイス１１０によるポーリングに応答して送信を行う。このように、多数の局が同時送信することが防止される。
【００１０】
通信スキームを確立するために、競合する周辺デバイスからリクエストを受信する。これらリクエストはリソース、例えばバンド幅およびメモリを予約するためのリクエストであり、よって予約リクエストとしても知られている。
【００１１】
ひき続き、図１を参照する。ネットワーク層１５０はアドミッション制御モジュール１６０を含む。このモジュール１６０は各予約リクエストを受信し、これを検討し、次にこのリクエストを許可または拒否する。リクエストを許可する場合、直接ネットワークが既に形成されている。
【００１２】
更にＡＰデバイス１１０は物理媒体１２０からスタートし、物理層Ｌ１（１３０），層Ｌ２（１４０）を通過し、アドミッション制御モジュール１６０で終了するパス１６５を含む。このパス１６５は、物理媒体１２０によって受信された物理信号が、層Ｌ１（１３０），Ｌ２（１４０），Ｌ３（１５０）などで取り次がれるようなソフトウェア信号に変換されることを示すアイコン状の道程となっている。
【００１３】
第１無線周辺通信デバイス１８０がＡＰデバイス１１０にデータを送信したいことがある。従って、この場合、無線通信デバイス１８０は通信リンク１８２を通してＡＰデバイス１１０へデータグループ１８４を送信する。
【００１４】
データグループ１８４は、コード化された予約リクエストを含む予約リクエストフレームであり、この予約リクエストは、パス１６５に沿って転送され、このリクエストはアドミッション制御モジュール１６０で受信される。次にアドミッション制御モジュール１６０はリクエストされた予約を許可するか、拒否するかを判断する。
【００１５】
同時にリソースを求めることにより、予約リクエストが競合する場合、問題が残る。競合する予約リクエストを解決するための、ＷＬＡＮのための種々の方法が既に提案されている。これら方法は利用できる全体の通信容量の一部を各無線局に割り当てるランダムアクセスを含む技術を使用している。例えば、ＩＥＥＥ８０２.１１の媒体アクセス制御標準は、衝突回避（ＣＳＭＡ／ＣＡ）スキームと共に搬送波感知を使用するランダムアクセス技術である。
【００１６】
【発明が解決しようとする課題】
ＩＥＥＥ８０２標準とコンパーチブルなデバイスはタイプ８０２デバイスとしても知られている。これらデバイスは、予約リクエストをレベルＬ３（１５０）に固有なものにするデータを、予約リクエストが含まなければならないという問題に直面している。このため、予約リクエストは過度に長くなり、この結果、通信スキームの設定が遅延することになる。
【００１７】
本発明は、上述のごとき実状に鑑みてなされたものであり、無線ＬＡＮにおいて予約フレームが長くなることによる通信スキームの設定の遅れを防止することが可能な無線通信を行うデバイス、及び方法を提供することをその目的とする。
【００２３】
【課題を解決するための手段】
第１の技術手段は、物理媒体と、該物理媒体に連結されたプロセッサとを備え、ＩＥＥＥ８０２．１１標準環境においてデータ通信を行うためのデバイスであって、前記プロセッサが、
前記データを送信するためのＩＥＥＥ８０２．１１に準拠した予約リクエストフレームを生成し、
前記データを送信するための優先度を決定し、
該優先度をコード化するＩＥＥＥ８０２．１Ｑに準拠したタグを生成し、
前記データおよび前記タグを媒体アクセス制御層に送り、
前記データを検査し、送信に必要なバンド幅を決定し、
前記予約リクエストフレーム内に前記タグおよび前記バンド幅をコード化し、
該コード化した予約リクエストフレームを送信することを特徴としたものである。
【００２４】
第２の技術手段は、第１の技術手段において、前記プロセッサが更に、前記データを送った後であって、該データを検査する前に、該データをバッファ内に蓄積することを特徴としたものである。
【００２６】
第３の技術手段は、物理媒体と、該物理媒体に連結されているプロセッサとを備え、ＩＥＥＥ８０２．１１標準環境においてデータ通信を行うためのデバイスであって、前記プロセッサが、
ＩＥＥＥ８０２．１１に準拠した予約リクエストフレームを受信し、
該予約リクエストフレームを分解し、予約リクエストを抽出し、
媒体アクセス制御層内において、前記予約リクエストからＩＥＥＥ８０２．１Ｑに準拠したタグをデコードし、
前記媒体アクセス制御層内において、前記タグを読み出し、優先度を識別し、
前記媒体アクセス制御層内において、利用できるリソースに対し、前記優先度を検査し、
前記媒体アクセス制御層内において、前記検査された優先度によって前記予約リクエストに対する許可／拒否の決定を行うことを特徴としたものである。
【００２７】
第４の技術手段は、第３の技術手段において、前記予約リクエストに対する許可／拒否の決定は、前記予約リクエストを満たすにはリソースが十分か不十分かを判断し、不十分であると判断した場合に、予約リクエスト拒否フレームを発生し、該予約リクエスト拒否フレームを送信することを含むことを特徴としたものである。
【００２８】
第５の技術手段は、第３の技術手段において、前記予約リクエストに対する許可／拒否の決定は、前記優先度に基づき、送信の機会のスケジューリングをすることを含むことを特徴としたものである。
【００３５】
第６の技術手段は、ＩＥＥＥ８０２．１１標準環境においてデータ通信を行うための方法であって、
データを送信するためのＩＥＥＥ８０２．１１に準拠した予約リクエストフレームを生成するステップと、
前記データを送信するための優先度を決定するステップと、
該優先度をコード化するＩＥＥＥ８０２．１Ｑに準拠したタグを生成するステップと、
前記データおよび前記タグを媒体アクセス制御層に送るステップと、
前記データを検査して、送信に必要なバンド幅を決定するステップと、
前記予約リクエストフレーム内に前記タグおよび前記バンド幅をコード化するステップと、
該コード化した予約リクエストフレームを送信するステップとを含むことを特徴としたものである。
【００３６】
第７の技術手段は、第６の技術手段において、前記データを送った後であって、該データを検査する前に、バッファに該データを蓄積するステップを更に含むことを特徴としたものである。
【００３８】
第８の技術手段は、ＩＥＥＥ８０２．１１標準環境においてデータ通信を行うための方法であって、
ＩＥＥＥ８０２．１１に準拠した予約リクエストフレームを受信し、
該予約リクエストフレームを分解し、予約リクエストを抽出するステップと、
媒体アクセス制御層内において、前記予約リクエストからＩＥＥＥ８０２．１Ｑに準拠したタグをデコードするステップと、
前記媒体アクセス制御層内において、前記タグを読み出して優先度を識別するステップと、
前記媒体アクセス制御層内において、利用できるリソースに対し、前記優先度を検査するステップと、
前記媒体アクセス制御層内において、前記検査された優先度によって予約リクエストに対する許可／拒否の決定を行うステップとを含むことを特徴としたものである。
【００３９】
第９の技術手段は、第８の技術手段において、前記予約リクエストに対する許可／拒否の決定を行うステップは、前記予約リクエストを満たすにはリソースが十分か不十分かを判断し、不十分であると判断した場合に、予約リクエスト拒否フレームを発生し、該予約リクエスト拒否フレームを送信するステップを含むことを特徴としたものである。
【００４０】
第１０の技術手段は、第８の技術手段において、前記予約リクエストに対する許可／拒否の決定を行うステップは、前記優先度に基づき、送信の機会をスケジューリングするステップを含むことを特徴としたものである。
【００４１】
【発明の実施の形態】
一般に、本発明は、第２層においてアドミッション制御を実行することによってネットワークを形成する無線通信デバイス、デバイス、方法、及び製品を提供するものである。
【００４２】
本発明に係わる周辺局は、予約リクエストフレーム内で送信されるタグ内にデータの優先度をコード化する。協力する相補的アクセスポイントが予約リクエストフレームを受信し、このタグを読み取る。タグの優先情報を使って第２レベルでリクエストを最終的に決定（許可または拒否）する。
【００４３】
本発明は、アドミッション制御プロセスがアクセスポイントのネットワーク層に達する必要はないという利点を有する。このように、予約リクエストフレームをアクセスポイントの第３レベルに固有のものにする必要はない。このように、予約リクエストフレームをより短くすることができる。
【００４４】
添付図面を参照しながら、次の詳細な説明を読めば、本発明についてより容易に理解できよう。
既に述べたように、本発明は、第２層においてアドミッション制御を行う無線通信デバイス、デバイス、方法、及び製品を提供するものである。以下、本発明についてより詳細に説明する。
【００４５】
次に、図２を参照しながら、本発明に従って製造されたアクセスポイント（ＡＰ）デバイス２１０について説明する。図２は、予約リクエストを決定する本発明の一実施例に従って製造されたＡＰデバイスおよび予約リクエストを生成する本発明の一実施例に従って製造された、協働する周辺局のアーキテクチャの図である。ＡＰデバイス２１０は物理媒体２２０を含む。媒体２２０は送信アンテナ、受信アンテナなどでよく、この媒体２２０はＷＬＡＮにおける他の無線通信デバイスとのデータの無線交換を行うためのものである。
【００４６】
ＡＰデバイス２１０は、ＯＳＩによって定められた多数の層を含むソフトウェア構造も含む。これら層は物理層２３０とも称される層Ｌ１（２３０）を含み、この層は媒体２２０を制御するためのものである。この層Ｌ１（２３０）の上位には層Ｌ２（２４０）が設けられ、この層Ｌ２（２４０）の上位に層Ｌ３（２５０）が設けられている。層Ｌ３（２５０）はネットワーク層Ｌ３（２５０）とも称される。他の層（図２には示されず）を設けることもできる。
【００４７】
層Ｌ２（２４０）は一般にＭＡＣサブ層（図２には別個に示されず）を含む。このＭＡＣサブ層の重要性は、第２層Ｌ２（２４０）全体を媒体アクセス制御（ＭＡＣ）層と時々称するようなものとなっていることである。
【００４８】
層Ｌ２（２４０）はアドミッション制御モジュール２６０を含み、モジュール２６０は各予約リクエストを受信し、これを許可するか拒否するかを判断する。
【００４９】
更にＡＰデバイス２１０は物理媒体２２０からスタートし、物理層２３０を通過し、アドミッション制御モジュール２６０で終了するパス２６５を含む。このパス２６５は、物理媒体２２０によって受信された物理信号が、層Ｌ１（２３０），Ｌ２（２４０）などで取り次がれるようなソフトウェア信号に変換されることを示すアイコン状の道程となっている。
【００５０】
周辺デバイス３１０によって設定された通信リンク２８２を通して、物理信号が受信される。物理信号は予約リクエストフレーム２８４を含む。この予約リクエストフレーム２８４には予約リクエスト（ＲＲ）がコード化される。
【００５１】
予約リクエストフレーム２８４内ではタグ２８６がコード化される。タグ２８６はデバイス３１０によりＩＥＥＥ８０２.１１標準に従ってコード化されている。
【００５２】
重要なことに、本発明によれば、デバイス３１０から送信すべきデータの優先度を更にコード化するために、タグ２８６が使用される。アドミッション制御モジュール２６０はタグ２８６内にコード化されている優先度を解読することによって、その判断を行う。
【００５３】
周辺局デバイス３１０も本発明に従って製造されているものとする。このデバイス３１０は物理媒体３２０を含む。この媒体３２０は送信アンテナ，受信アンテナなどでよく、この媒体３２０はＷＬＡＮにおける他の無線通信デバイスとの間のデータの無線交換を行うためのものである。
【００５４】
デバイス３１０は、ＯＳＩによって定められた多数の層を含むソフトウェア構造も含む。これら層は物理層３３０と称され、媒体３２０を制御するためのものである層Ｌ１（３３０）を含む。層Ｌ１（３３０）の上位には層Ｌ２（３４０）が設けられ、層Ｌ２（３４０）の上位には層Ｌ３（３５０）が設けられるこの層Ｌ３（３５０）はネットワーク層Ｌ３（３５０）とも称される。他の層（図２には示されず）を設けることもできる。
【００５５】
重要なことに、層Ｌ３（３５０）はタグ生成モジュール３６０を含む。モジュール３６０は、本明細書に係る米国仮出願第６０／２３３，３６６号明細書において最初に米国特許庁に出願した日に定められているように、ＩＥＥＥ８０２.１Ｑ標準に従ってタグ２８６を生成する。更に、タグ２８６はリンク２８２に沿って送信すべきデータの優先度を含む。このように、ＱｏＳの検討事項に基づき、優先度が最終的に決定される。
【００５６】
理解できるように、予約リクエストは層Ｌ２（２４０）にてアドミッション制御モジュール２６０によって決定される。従って、予約リクエストは層Ｌ３（２５０）の要求を満たす必要はない。換言すれば、ＲＲ（予約リクエスト）はより高度なレベルで不可知である。
【００５７】
次に図３を参照すると、ここには図２のデバイスの構成要素がより詳細に示されている。この技術は多数の標準化された用語およびこの用語に従った同義語を必要としている。更に読者の利益のために、最も有効な頭字語のリストを次に示す。
【００５８】
ＡＰ − アクセスポイント
ＢＭＥ − バッファ管理エンティティ
ＣＣＩ − 集中コンテンションインターバル
ＣＥ − 分類エンティティ
ＣＴＳ − 送信のためにクリア
ＤＣＦ − 分配コーディネーション機能
ＤＳＢＭ − 指定サブネットバンド幅マネージャ
Ｅ−ＳＭＥ − エンハンスト局管理エンティティ
ＬＬＣ − 論理リンク制御
ＭＡＣ − 媒体アクセス制御
ＭＬＭＥ − ＭＡＣ層管理エンティティ
ＯＳＩ −開放型システム間相互接続
ＰＣＦ − ポイントコーディネーション機能
ＰＥ − ポライシングエンティティ
ＰＬＣＦ − 物理層コンバージェンスプロトコル
ＰＬＭＥ − 物理層管理エンティティ
ＰＭ − 物理媒体
ＰＭＤ − 物理媒体従属
ＱｏＳ − サービスの品質
ＲＭＥ − 予約管理エンティティ
ＲＲ − 予約リクエスト
ＳＥ − スケジュールリングエンティティ
ＳＴＡ − 局
【００５９】
図３から判るように、ＡＰデバイス２１０では層Ｌ１（２３０）はＰＬＣＰ２３２，ＰＭＤ２３４，ＰＬＭＥ２３６を含み、層Ｌ２（２４０）はＬＬＣ２４１，媒体アクセス制御（ＭＡＣ）サブ層２４３，ＭＬＭＥ２４４を含む。ＭＡＣサブ層２４３はＢＭＥ２４６，ＳＥ２４７，ＲＭＥ２４８を含む。層Ｌ３（２５０）は特に、ＣＥ２５２およびＤＳＢＭ２５４を含む。Ｅ−ＳＭＥ２５８によって、すべての３つの層Ｌ１（２３０），Ｌ２（２４０），Ｌ３（２５０）がつながっている。
【００６０】
更に周辺局３１０では、層Ｌ１（３３０）はＰＬＣＰ３３２，ＰＭＤ３３４，ＰＬＭＥ３３６を含む。層Ｌ２（３４０）はＬＬＣ３４１，媒体アクセス制御（ＭＡＣ）サブ層３４３，ＭＬＭＥ３４４を含む。層Ｌ２（３４０）はＭＡＣサブ層３４３を含むので、媒体アクセス制御（ＭＡＣ）層とも称される。ＭＡＣサブ層３４３はＢＭＥ３４６を含む。層Ｌ３（３５０）は特にＣＥ３５２を含む。分類エンティティ（ＣＥ）３５２は図２のタグ生成モジュール３６０であることが好ましい。Ｅ−ＳＭＥ３５８によって、すべての３つの層Ｌ１（３３０）、Ｌ２（３４０），Ｌ３（３５０）がつながっている。
【００６１】
本発明は論理回路を含む１つ以上のデバイスによって実現できることが明らかである。更に本発明は、マイクロコントローラまたはマイクロプロセッサを含むことができる専用処理システムを備えたデバイスによっても実現できる。かかる別の実施例について、以下に示す。
【００６２】
図４は、本発明に係わる無線アクセスポイントおよび無線基地局のための異なる実施例を示すブロック図である。図４を参照し、本発明の実施例に係わるアクセスポイントＡＰ４２０についてより詳細に説明する。ＡＰ４２０は任意の通信デバイス、例えば無線通信デバイス（局、周辺局など）でよい。
【００６３】
アクセスポイントＡＰ４２０はプロセッサ４２２を有し、このプロセッサはデジタル信号プロセッサ（ＤＳＰ）、中央処理ユニット（ＣＰＵ）、または当技術分野で公知の、他の任意の均等な方法で実現できる。
【００６４】
アクセスポイントＡＰ４２０は更にメモリ４２４を含み、このメモリにプログラム４２６が常駐できる。プロセッサ４２２の機能は後に明らかとなるように、プログラム４２６によって制御できる。
【００６５】
さらに図４を参照して、本発明の実施例に係わる周辺局ＳＴＡ４４０についてより詳細に説明する。局ＳＴＡ４４０は任意の通信デバイス、例えば無線通信デバイス（局、周辺局など）でよい。
【００６６】
局ＳＴＡ４４０はプロセッサ４４２を有し、このプロセッサはデジタル信号プロセッサ（ＤＳＰ）、中央処理ユニット（ＣＰＵ）、または当技術分野で公知の、他の任意の均等な方法で実現できる。
【００６７】
局ＳＴＡ４４０は更にメモリ４４４を含み、このメモリにプログラム４４６が常駐できる。プロセッサ４４２の機能は後に明らかとなるように、プログラム４４６によって制御できる。
【００６８】
アクセスポイントＡＰ４２０と周辺局ＳＴＡ４４０とは、両者の間でデータを交換するために通信接続リンク４８２を確立できる。
【００６９】
本発明は更に、後述するような方法も提供する。更に本発明は、本発明の方法を実行し、またはそれを補助する装置を提供する。この装置は、必要な目的のために特別に製造してもよいし、また、コンピュータ内に蓄積されるコンピュータプログラムによって選択的に附勢または再構成される汎用コンピュータを含んでもよい。本明細書に説明する方法およびアルゴリズムは必ずしも特定のコンピュータまたは他の装置に本来的に関係するものではない。特に本明細書の要旨に従ってプログラムと共に種々の汎用装置を使用することもできるし、また、必要な方法のステップを実行するように、より特殊な装置を製造するほうが、より便利となる場合もある。これら種々の装置に必要な構造は次の説明から明らかとなろう。
【００７０】
本発明に係るオペレーションを実行するための有効な装置または製品（アーティクル）は、汎用デジタルコンピュータまたは他の同様なデバイスを含む。いずれの場合においても、コンピュータをオペレートする方法とその計算方法との間の違いを念頭に入れるべきである。本発明はコンピュータをオペレートするための方法のステップおよび電気的または他の物理的信号を処理し、その他の所望する物理的信号を発生させるための方法のステップにも関するものである。
【００７１】
本発明は更に、プログラムおよびそのプログラムのオペレーション方法も提供する。このプログラムは計算装置、例えば汎用コンピュータ，特殊用途コンピュータ，マイクロプロセッサなどのためのプログラムとして最も有利に実現できる。
【００７２】
本発明は内部に蓄積された本発明のプログラムを有する記憶媒体を提供するものである。この記憶媒体はコンピュータで読み取り可能な媒体、例えばメモリであり、上記計算装置によって読み取られる。
【００７３】
通常、プログラムは所望する結果を与える一連のステップとして定義される。命令（インストラクション）としても知られるこれらステップは物理量を物理的に操作することを必要とするステップである。通常、これら量は蓄積し、転送し、組み合わせ、比較し、更に他の方法で操作し、または処理することができる電気信号または磁気信号の形態をとり得るが、必ずしもそのような形態でなくてもよい。これら信号を蓄積する際、コンピュータ読み取り可能な任意の媒体にこれら信号を蓄積することができる。主に共通に使用する理由から、これら信号をビット，データビット，サンプル，値，要素，シンボル，キャラクタ，信号，画像，用語，数または同様なものと称すと便利な場合がある。しかしながら、これら同様な用語のすべては適当な物理量に関連しており、これら用語は単にこれら物理量に適用される便宜的な標識にすぎないと念頭に入れるべきである。
【００７４】
この詳細な説明は、主にコンピュータで読み取り可能な媒体、例えばメモリ内のデータビットの演算のフローチャート、ディスプレイ画像、アルゴリズムおよびシンボル表示として示される。かかる説明および表示はプログラムおよび／またはデータ処理技術の当業者が他の当業者に自らの作品の要旨を効果的に伝えるために使用するタイプの便利な標識である。プログラミング技術の当業者であれば、本発明に係わるプログラムを実現するための特定の命令を容易に生成するために、この説明を使用することができよう。しかしながら、簡潔にするために、本明細書では本発明に係わるソフトウェアを記述するために、本発明の方法を説明するのに使用するフローチャートを繰り返すことはない。
【００７５】
単に便宜上、全体にソフトウェアとしても知られる種々の相互に接続された別々のソフトウェアモジュールまたは機能としてプログラムを実現し、記述することが好ましいことが多い。しかしながらこのことは必要ではないが、不明瞭な境界を有する単一のプログラムとなるようにモジュールを均等に寄せ集めるようなケースもあり得る。いずれの場合においても、本発明のソフトウェアモジュールまたは機能は自ら、または他のものと組み合わせて実現できる。プログラムをコンピュータが読み取り可能な媒体に蓄積できると述べたが、当業者にはこの媒体は単一のメモリでなくてもよく、また単一のマシンでなくてもよいことは明らかなはずである。別個のメモリまたは別個のマシンにさえも、プログラムの種々の部分、モジュールまたは機能が常駐してもよい。別個のマシンを直接接続したり、またはネットワーク、例えばローカルエリアネットワーク（ＬＡＮ）またはグローバルネットワーク、例えばインターネットを介して接続することができる。
【００７６】
本ケースでは、本発明の方法はマシンのオペレーションによって実現される。換言すれば、本発明のプログラムの実施例は、本明細書に記載されている本発明の方法を実現するように作成されている。これら実施例は、プログラムのすべてではない一部を実施する一人以上のオペレータと共にオプションとして実施してもよい。上記に関し、ユーザは互いに会話する必要はなく、各ユーザはプログラムの一部を収納するマシンを有しているだけでよい。これとは異なり、ユーザが存在せず、および／またはユーザが互いに別々な状態でこれらマシンの一部が自動的に作動してもよい。
【００７７】
以下、本発明の方法について説明する。
次に図５を参照すると、本発明の実施例に係わる方法を示すためのフローチャート５００が示されている。フローチャート５００の方法は、データをアクセスポイントのデバイスへ伝送（送信）しようとする周辺局によって実施できる。
【００７８】
ボックス５１０によれば、データを送信するために予約リクエストが生成される。
【００７９】
次のボックス５２０によれば、データを送信するための優先度が決定される。この優先度は分類エンティティによって決定してもよい。また、この優先度はデフォルトクラスまたはＡＰ指定クラスのいずれかに従うことができる。かかるクラスにおいては優先度は数字、例えば７，６，４などによって指定できる。
【００８０】
次のボックス５３０によれば、タグが生成される。このタグはＩＥＥＥ８０２.１Ｑ標準に従ったものである。重要なことに、このタグは優先度もコード化している。
【００８１】
次のボックス５４０によれば、データおよびタグはＯＳＩアーキテクチャの第２層へ送られる。このＯＳＩアーキテクチャはＭＡＣサブ層と称されることが多い。ＬＬＣが介入する場合、このデータはＭＡＣサブ層へ送られる。
【００８２】
オプションの次のボックス５５０によれば、データはバッファに蓄積される。次のボックス５６０によれば、データを検査し、送信に必要なバンド幅を決定する。アドレスも検査される。検査はＢＭＥによって行うことが好ましい。
【００８３】
オプションの次のボックス５７０によれば、タグおよびバンド幅が予約リクエストフレーム内にコード化される。この予約リクエストフレームはアクセスポイントのネットワーク層のタイプに固有である必要はない。換言すれば、第３の層から独立する、すなわち第３層に不可知であってよい。
【００８４】
オプションの次のボックス５８０によれば、この予約リクエストフレームが送信され、ＡＰデバイスによって受信される。送信は集中コンテンションインターバル中に行うことが好ましい。この送信はＤＣＦモードでもよいし、またはＰＣＦモードでもよい。
【００８５】
次に図６を参照し、フローチャート６００を使って本発明の別の実施例に係わる方法について説明する。フローチャート６００の方法は、予約リクエストを受信し、これを決定するアクセスポイントデバイスによって実施できる。
【００８６】
ボックス６１０によれば、予約リクエストフレームが受信される。
【００８７】
次のボックス６２０によれば、予約リクエストを抽出するように予約リクエストフレームが分解される。
【００８８】
次のボックス６３０によれば、予約リクエストからＩＥＥＥ８０２.１Ｑタグがデコードされる。このデコードはＭＡＣ層においてネットワーク層に進むことなく行われる。これがアドミッション制御の第１部分である。
【００８９】
オプションの次のボックス６４０によれば、リクエストされた優先度を識別するためにタグが読み出される。更にバンド幅条件を決定するために予約リクエストも読み出される。これがアドミッション制御の第２部分である。
【００９０】
オプションの次のボックス６５０によれば、優先度が検査される。予約リクエストを満たすための十分なリソースがあるかどうかが問われる。このリクエストは利用可能なリソースに対して検査される。
【００９１】
十分なリソースがない場合、次のボックス６６０によれば、予約リクエスト拒否フレームを生成し、これを送信する。このことは、ＭＡＣ層にある時に起きる。
【００９２】
十分なリソースがあれば、次のボックス６７０によれば、優先度に従って送信する機会のスケジューリングが行われる。このスケジューリングは、ＭＡＣ層内にある間に行われる。好ましい実施例では、第２層におけるスケジューリングエンティティ（ＳＥ）によってスケジューリングが実行される。次に、スケジューリング、バッファウィンドのサイズなどをアナウンスするために交換が行われる。
【００９３】
従って、結果に拘らず、このように専ら第２層においてしかアドミッション制御が行われない。この制御は第２層におけるＢＭＥおよびＲＭＥも必要とする。
【００９４】
当業者であれば、全体として見なすべき本明細書に記載された説明を検討すれば、本発明を実施することができよう。本発明の理解をより完全にするために多数の細部が記載されている。他の状況では、本発明を不必要に不明確にしないよう、周知の特徴については詳細には説明していない。
【００９５】
以上で本発明を好ましい形態として開示したが、本書に開示し、説明した特定の実施例は限定的なものと見なすべきでない。当業者がこの説明を検討すれば、本発明は種々の方法で変形できることは容易に明らかであるはずである。発明者は、発明の要旨が本書に開示した種々の要素、特徴、機能および／または特性のすべての組み合わせおよび準組み合わせを含むものと考えている。
【００９６】
特許請求の範囲は新規であり、かつ進歩性があると考えられる所定の組み合わせおよび準組み合わせについて記載したものであり、本明細書および関連する明細書に特徴，機能，要素および／または特性の他の組み合わせ、および準組み合わせに関する別の請求項を示すことができる。
【図面の簡単な説明】
【図１】周辺局から予約リクエストを解決する従来技術におけるＡＰデバイスのアーキテクチャの図である。
【図２】予約リクエストを決定する本発明の一実施例に従って製造されたＡＰデバイスおよび予約リクエストを生成する本発明の一実施例に従って製造された、協働する周辺局のアーキテクチャの図である。
【図３】図２のアクセスポイントおよび周辺局の構成部品のブロック図である。
【図４】本発明に係わる無線アクセスポイントおよび無線基地局のための異なる実施例を示すブロック図である。
【図５】本発明の実施例に係わる方法を示すフローチャートである。
【図６】本発明の一実施例に係わる方法を示すフローチャートである。
【符号の説明】
２１０…アクセスポイントデバイス、２２０，３２０…媒体、２３０，３３０…層Ｌ１、２４０，３４０…層Ｌ２、２５０，３５０…層Ｌ３、２６０…アドミッション制御モジュール、２６５…パス、２８２…通信リンク、２８４…予約リクエストフレーム、２８６…タグ、３１０…周辺デバイス、３６０…タグ生成モジュール。

Claims (10)

1. 物理媒体と、該物理媒体に連結されたプロセッサとを備え、ＩＥＥＥ８０２．１１標準環境においてデータ通信を行うためのデバイスであって、前記プロセッサが、
   前記データを送信するためのＩＥＥＥ８０２．１１に準拠した予約リクエストフレームを生成し、
   前記データを送信するための優先度を決定し、
   該優先度をコード化するＩＥＥＥ８０２．１Ｑに準拠したタグを生成し、
   前記データおよび前記タグを媒体アクセス制御層に送り、
   前記データを検査し、送信に必要なバンド幅を決定し、
   前記予約リクエストフレーム内に前記タグおよび前記バンド幅をコード化し、
   該コード化した予約リクエストフレームを送信することを特徴とするデバイス。
2. 前記プロセッサが更に、前記データを送った後であって、該データを検査する前に、該データをバッファ内に蓄積することを特徴とする請求項１記載のデバイス。
3. 物理媒体と、該物理媒体に連結されているプロセッサとを備え、ＩＥＥＥ８０２．１１標準環境においてデータ通信を行うためのデバイスであって、前記プロセッサが、
   ＩＥＥＥ８０２．１１に準拠した予約リクエストフレームを受信し、
   該予約リクエストフレームを分解し、予約リクエストを抽出し、
   媒体アクセス制御層内において、前記予約リクエストからＩＥＥＥ８０２．１Ｑに準拠したタグをデコードし、
   前記媒体アクセス制御層内において、前記タグを読み出し、優先度を識別し、
   前記媒体アクセス制御層内において、利用できるリソースに対し、前記優先度を検査し、
   前記媒体アクセス制御層内において、前記検査された優先度によって前記予約リクエストに対する許可／拒否の決定を行うことを特徴とするデバイス。
4. 前記予約リクエストに対する許可／拒否の決定は、前記予約リクエストを満たすにはリソースが十分か不十分かを判断し、不十分であると判断した場合に、予約リクエスト拒否フレームを発生し、該予約リクエスト拒否フレームを送信することを含むことを特徴とする請求項３記載のデバイス。
5. 前記予約リクエストに対する許可／拒否の決定は、前記優先度に基づき、送信の機会のスケジューリングをすることを含むことを特徴とする請求項３記載のデバイス。
6. ＩＥＥＥ８０２．１１標準環境においてデータ通信を行うための方法であって、
   データを送信するためのＩＥＥＥ８０２．１１に準拠した予約リクエストフレームを生成するステップと、
   前記データを送信するための優先度を決定するステップと、
   該優先度をコード化するＩＥＥＥ８０２．１Ｑに準拠したタグを生成するステップと、
   前記データおよび前記タグを媒体アクセス制御層に送るステップと、
   前記データを検査して、送信に必要なバンド幅を決定するステップと、
   前記予約リクエストフレーム内に前記タグおよび前記バンド幅をコード化するステップと、
   該コード化した予約リクエストフレームを送信するステップとを含むことを特徴とする方法。
7. 前記データを送った後であって、該データを検査する前に、バッファに該データを蓄積するステップを更に含むことを特徴とする請求項６記載の方法。
8. ＩＥＥＥ８０２．１１標準環境においてデータ通信を行うための方法であって、
   ＩＥＥＥ８０２．１１に準拠した予約リクエストフレームを受信し、
   該予約リクエストフレームを分解し、予約リクエストを抽出するステップと、
   媒体アクセス制御層内において、前記予約リクエストからＩＥＥＥ８０２．１Ｑに準拠したタグをデコードするステップと、
   前記媒体アクセス制御層内において、前記タグを読み出して優先度を識別するステップと、
   前記媒体アクセス制御層内において、利用できるリソースに対し、前記優先度を検査するステップと、
   前記媒体アクセス制御層内において、前記検査された優先度によって予約リクエストに対する許可／拒否の決定を行うステップとを含むことを特徴とする方法。
9. 前記予約リクエストに対する許可／拒否の決定を行うステップは、前記予約リクエストを満たすにはリソースが十分か不十分かを判断し、不十分であると判断した場合に、予約リクエスト拒否フレームを発生し、該予約リクエスト拒否フレームを送信するステップを含むことを特徴とする請求項８記載の方法。
10. 前記予約リクエストに対する許可／拒否の決定を行うステップは、前記優先度に基づき、送信の機会をスケジューリングするステップを含むことを特徴とする請求項８記載の方法。

Images