(57)【要約】  予定された媒体アクセス制御（ＭＡＣ）アーキテクチャを提供するシステムおよび方法が示される。実施形態により提供される予定されたＭＡＣアーキテクチャは、局に並行プロセス媒体アクセスが与えられる一度に１機能のアプローチとなる。局間の通信用として通信フレームワークが設定され、通信フレームワークがアクセス要求方法、データフレーム送信方法および／または機能的間隔の点からセッションを終了する方法を規定することが望ましい。公平性、スループット効率、競合、トラフィックフロー管理および待ち時間が考慮されるように、機能的間隔を配列することが望ましい。スーパーフレーム構成は、種々の機能的間隔から規定されることが望ましい。予定されたＭＡＣアーキテクチャは、キャリア・センサー多重アクセススキームに基づくものなど他のＭＡＣプロトコルと共存することができる。
2009507422.tif 000002
【特許請求の範囲】
【請求項１】
共有媒体用の媒体アクセス制御を提供する方法であって、
共有媒体に対する複数の局による相互作用を規定するために複数の媒体アクセス機能を規定し、そして
共有媒体にアクセスする必要性を現在持つ各局に対応するために、一度に前記複数の媒体アクセス機能のうちの１つの媒体アクセス機能を行なうよう共有媒体へのアクセスを制御する、方法。
【請求項２】
請求項１の方法であって、
共有媒体へのアクセスの前記制御は、
共有媒体にアクセスする必要性を現在持つ前記各局が、第２媒体アクセス機能を使用してデータ送信を行う前に、第１媒体アクセス機能を使用して媒体アクセス要求を行うことにより行われる、方法。
【請求項３】
請求項１の方法であって、さらに、
共有媒体へのアクセス用にプロトコルを規定する予定された媒体アクセス制御アーキテクチャを提供し、
共有媒体へのアクセスの前記制御が前記予定された媒体アクセス制御アーキテクチャに従う、方法。
【請求項４】
請求項３の方法であって、
前記プロトコルがスーパーフレーム・アーキテクチャを備え、前記複数の媒体アクセス機能が前記スーパーフレーム・アーキテクチャ内の複数の機能的な間隔を備える、方法。
【請求項５】
請求項４の方法であって、さらに、
媒体アクセス制御パフォーマンスパラメータを最適化するために前記スーパーフレーム・アーキテクチャの属性を調節する、方法。
【請求項６】
請求項５の方法であって、
前記属性の調節が、スーパーフレームの長さを調節し、前記パフォーマンスパラメータがスループットを構成することにより行われる、方法。
【請求項７】
請求項５の方法であって、
前記属性の調節が、アクセスの公平性を最適化するために前記スーパーフレーム・アーキテクチャのスーパーフレーム内のトラフィックフロー制御を調節することにより行われる、方法。
【請求項８】
請求項５の方法であって、
前記属性の調節が、スループットを最適化するために前記スーパーフレーム・アーキテクチャのスーパーフレーム内のフレームのフレーム間間隔を調節することにより行われる、方法。
【請求項９】
請求項８の方法であって、
前記フレーム間間隔の調節が、共有媒体上の伝播遅延に関する情報を決定することにより行われる、方法。
【請求項１０】
請求項５の方法であって、
前記属性の調節が、前記スーパーフレーム中の前記複数の媒体アクセス機能を提供する機能的な間隔の順序を調節することにより行われる、方法。
【請求項１１】
請求項１の方法であって、
前記媒体アクセス機能がアクセス必要機能からなり、共有媒体にアクセスする必要性を現在持つ前記各局が、前記アクセス必要機能を使用してアクセスの必要性を表示する、方法。
【請求項１２】
請求項１１の方法であって、
前記アクセス必要機能を使用したアクセスの必要性の表示が、複数の可能性がある状態のうちの１つを示す短いフレームからなる、方法。
【請求項１３】
請求項１２の方法であって、
前記複数の可能性がある状態が３つの可能性がある状態であり、前記３つの可能性がある状態は、共有媒体にアクセスする必要性がある状態、共有媒体にアクセスする必要がない状態、そして休止状態である、方法。
【請求項１４】
請求項１１の方法であって、
前記媒体アクセス機能がさらにリソース要求機能からなり、共有媒体にアクセスする必要性を現在持つ前記各局が、前記リソース要求機能を使用して、要求されるリソースに関する情報を提供する、方法。
【請求項１５】
請求項１４の方法であって、
前記要求されるリソースに関する情報が複数のデータフレーム送信を予約するための情報からなる、方法。
【請求項１６】
請求項１４の方法であって、
前記媒体アクセス機能がさらに、前記リソース要求機能に対するスケジューリングを提供するリソース要求スケジュール機能からなり、リソース要求スケジューリング機能のスケジュールが、前記アクセス必要機能に対して提供される情報から少なくとも部分的に決定される、方法。
【請求項１７】
請求項１４の方法であって、
前記媒体アクセス機能がさらに送信時期機能からなり、そこでは、共有媒体にアクセスする必要性を現在持つ前記局の局が、共有媒体へのアクセスに関する情報を前記送信時期機能を使用して提供する、方法。
【請求項１８】
請求項１７の方法であって、
共有媒体へのアクセスに関する前記情報がデータフレーム送信のスケジュールである、方法。
【請求項１９】
請求項１７の方法であって、
共有媒体へのアクセスに関する前記情報がデータフレーム送信のサイズである方法。
【請求項２０】
請求項１７の方法であって、
前記媒体アクセス機能がさらにデータフレーム送信機能からなり、共有媒体へのアクセスに関する情報を提供した前記局に関するペイロード・データが前記データフレーム送信機能のデータフレームで送られる、方法。
【請求項２１】
請求項２０の方法であって、
前記データフレーム送信機能のデータフレーム送信が、発信局から宛先局へ直接的である、方法。
【請求項２２】
請求項２０の方法であって、
前記データフレーム送信機能のデータフレーム送信が、発信局から宛先局へトランジット点を経由する、方法。
【請求項２３】
請求項２２の方法であって、
前記トランシット点が、共有媒体へのアクセスの前記制御を提供する点調整を運営するゲートウエイである、方法。
【請求項２４】
請求項１の方法であって、
前記媒体アクセス機能が、リソース要求機能と送信時期機能からなり、そこでは、共有媒体にアクセスする必要性を現在持つ前記各局が、前記リソース要求機能を使用して、要求されるリソースに関する情報を提供し、共有媒体にアクセスする必要性を現在持つ前記局の局が、共有媒体へのアクセスに関する情報を前記送信時期機能を使用して提供する、方法。
【請求項２５】
さらに以下を備える請求項１の方法であって、さらに、共有媒体へのアクセスの前記制御を実施するための点調整を提供する、方法。
【請求項２６】
共有媒体用の媒体アクセス制御を提供する方法であって、
複数の機能的間隔を含むスーパーフレームを規定し、前記機能的間隔は各機能に関して複数の局に対応し、
共有媒体にアクセスする必要性を現在持つすべての局が、現在のスーパーフレームにおける前記複数の機能的間隔のうちの特定のものに関連した機能を、前記現在のスーパーフレームにおける前記複数の機能的間隔のうちの異なるものに関連した機能をいかなる局もが行う前に、行うよう操作する、方法。
【請求項２７】
請求項２６の方法であって、
前記複数の機能的間隔が、共有媒体上の各アクティブな局が共有媒体にアクセスする必要性を示すためのタイムスロットを持つ機能的間隔を備える、方法。
【請求項２８】
請求項２７の方法であって、
前記複数の機能的間隔が、共有媒体にアクセスする必要性を示した各局に、共有媒体へのアクセスに関する情報を提供するタイムスロットを持つ機能的間隔を備える、方法。
【請求項２９】
請求項２７の方法であって、
前記複数の機能的間隔が、共有媒体にアクセスする必要性を示した各局が要求するリソースに関する情報を提供するタイムスロットを持つ機能的間隔を備える、方法。
【請求項３０】
請求項２６の方法であって、
前記複数の機能的間隔が、共有媒体にアクセスする必要性を持つ各局が要求するリソースに関する情報を提供するためのタイムスロットを持つ機能的間隔を備える、方法。
【請求項３１】
請求項２６の方法であって、
前記複数の機能的間隔が、共有媒体にアクセスする必要性を持つ各局がデータフレームを送信するためのタイムスロットを持つ機能的間隔を備える、方法。
【請求項３２】
請求項２６の方法であって、
共有媒体にアクセスする必要性を現在持つすべての局の前記操作が、前記局を管理する点調整を使用することである、方法。
【請求項３３】
請求項３２の方法であって、
前記点調整が前記局による共有媒体への競合なしのアクセスを提供する、方法。
【請求項３４】
請求項３２の方法であって、
前記点調整が、共有媒体に関するトラフィック要件の知識を前記機能的間隔の１つ以上を介して与えられる、方法。
【請求項３５】
請求項３２の方法であって、さらに、
前記調整が、共有媒体に関するアクセス公平性を前記機能的間隔における局タイムスロット割当てを通して提供することである、方法。
【請求項３６】
請求項３５の方法であって、
前記アクセス公平性が、管理者によって前記点調整に識別された少なくとも１つの局にアクセス優先権を与える、方法。
【請求項３７】
共有媒体と、
前記共有媒体につながれた複数の局と、
前記共有媒体につながれた点調整ホストノードと、を備え、
各スーパーフレーム間隔に関して、複数の媒体アクセス機能のうちの関数の１つの媒体アクセス機能を、いかなる局もが前記複数の媒体アクセス機能のうちの次の媒体アクセス機能を行なう前に、行うよう前記ホストノード上で動作可能な点調整ロジックが前記複数局の局を制御するシステム。
【請求項３８】
請求項３７のシステムであって、
前記複数局の局が、前記局の標準化されたフィジカル層インタフェースの使用のために前記点調整に応答する媒体アクセス制御ロジックを有する、システム。
【請求項３９】
請求項３８のシステムであって、
前記標準化されたフィジカル層インタフェースがイーサネット・ネットワークインターフェース・フィジカル層である、システム。
【請求項４０】
請求項３８のシステムであって、
前記標準化されたフィジカル層インタフェースがＷｉＦｉネットワークインターフェース・フィジカル層である、システム。
【請求項４１】
請求項３７のシステムであって、
前記複数局の局が、前記ポイント管理の動作を前記局の標準ネットワーク・アダプタに透明にするよう動作可能なプロトコルアダプタを備える、システム。
【請求項４２】
請求項３７のシステムであって、前記ホストノードがゲートウエイであるシステム。
【請求項４３】
請求項３７のシステムであって、
前記ホストノードが、
インターフェースに前記共有媒体を備えるメディアインターフェースと、
前記媒体アクセス機能のデータフレームに対して前記媒体アクセス機能の制御フレームを結合及び分離させるマルチプレクサ／デマルチプレクサ機能と、
を備える、システム。
【請求項４４】
請求項３７のシステムであって、
前記複数局の局が、
インターフェースに前記共有媒体を備えるメディアインターフェースと、
前記媒体アクセス機能のデータフレームに対して前記媒体アクセス機能の制御フレームを結合及び分離させるマルチプレクサ／デマルチプレクサ機能と、
を備える、システム。
【請求項４５】
請求項３７のシステムであって、
前記点調整ロジックが、    前記複数の局のどの局が前記共有媒体へのアクセスを提供されるかを制御するためのフロー制御アルゴリズムを備える、システム。
【請求項４６】
請求項４５のシステムであって、
前記フロー制御アルゴリズムが、前記局に提供される前記共有媒体へのアクセス量をさらに制御する、システム。
【請求項４７】
請求項３７のシステムであって、
前記点調整ロジックが、前記スーパーフレーム間隔内の調節可能なフレーム間スペースを提供のためのフレーム間スペース調節アルゴリズムを備える、システム。
【請求項４８】
請求項４７のシステムであって、
前記フレーム間スペースが、前記点調整ロジックによって収集された媒体伝播情報に少なくとも部分的に基づいて調節される、システム。
【請求項４９】
請求項３７のシステムであって、
前記点調整ロジックが、    前記スーパーフレーム間隔に関して前記媒体アクセス間隔の調節可能なシーケンスを提供するためのスーパーフレームシーケンス調節アルゴリズムを備える、システム。
【請求項５０】
請求項３７のシステムであって、
前記点調整ロジックが、    前記複数の局の特定の局に関して複数のデータフレームの予約を容易にするためのデータフレーム予約アルゴリズムを備える、システム。
【請求項５１】
請求項５０のシステムであって、
前記複数のデータフレームが連続したスーパーフレーム間隔にある、システム。
【請求項５２】
請求項５０のシステムであって、
前記複数のデータフレームが不連続のスーパーフレーム間隔にある、システム。
【発明の詳細な説明】
【技術分野】
【０００１】
〔関連出願の相互参照〕
本件出願は、２００５年９月１日付米国仮出願シリアルNo.６０／７１３，０５２、名称「複合アクセス制御アーキテクチャ」、の優先権を主張し、言及することによってそれを本書に取り込む。
【０００２】
〔技術分野〕
本発明は、一般に通信、特に共有される通信媒体に対する媒体アクセス制御を提供することに関する。
【背景技術】
【０００３】
〔発明の背景〕
接続ベース（例えば交換リンク）および非接続ベース（例えばパケットルーティッド）の通信技術は、国際電信電話諮問委員会（ＣＣＩＴＴ）および国際電気通信連合（ＩＴＵ）の電気通信基準で、ずっと前から規定されている。接続ベースの通信では、通信局間のすべての送信は同じ通信路（例えば交換リンク）を使用する。接続ベースの通信は、公衆交換電話網（ＰＳＴＮ）が伝統的に過去に作動したようなやり方である。例えば、呼び出しが接続されると、終端間の接続が全通話時間中維持され、局間の送信はすべてその接続を通じて通信される。接続ベースの通信とは対照的に、非接続ベースの通信では、通信局間の送信はそれぞれ、ネットワーク内の異なる経路を通るかもしれない（例えば、個々のパケットは、端点から端点までネットワークを通る、その時の「ベスト」の経路を通される）。典型的には、公衆データ網（インターネット）、ローカルエリアネットワーク（ＬＡＮ）、都市内ネットワーク（ＭＡＮ）、広域ネットワーク（ＷＡＮ）などのようなデータ網は、非接続のアーキテクチャに基づく。
【０００４】
通信媒体（例えば銅の伝送回線、電力線、空気、光ファイバーなど）が、非接続のアーキテクチャなどにおける複数の局によって共有される場合、媒体の使用を調停し、かつ媒体の共有を容易にするために、通常なんらかの媒体アクセス制御（ＭＡＣ）が望まれる。ＬＡＮ、ＷＡＮ、インターネットなどは、図１に示すような共有媒体を介して多数の局に対応し、恐らく最も一般的なＭＡＣスキームを提供するように設計されている。ＭＡＣに提供される多重アクセス能力は、ユーザ端末１０１〜１０５などの局が、共有の媒体、例えば図１ではゲートウェイ１１１として示される、システムによってアクセス・ポイント、ルータ、スイッチ、ゲートウェイ、ベース・ステーションなどを備える銅の伝送回路、電力線、空気、光ファイバーなどからなる媒体１００、を介して通信するために不可欠であるとしばしば考えられる。
【０００５】
通常は、ＭＡＣと物理層仕様は常に密接に関連し、したがって、単一の仕様書として発行される。その結果、媒体の物理的特性の相違のために多くの異なるＭＡＣスキームが使用されている（例えばワイヤ・ライン用イーサネット、無線通信用のＩＥＥＥ  ８０２．１１（ＷｉＦｉ）、電力線その他用の電力線通信システム）。
【０００６】
種々のＭＡＣスキームが実施されているが、ＭＡＣ層設計へのアプローチにいくつかの共通点がある。種々の媒体用として異なるメーカーによって実施された種々のＭＡＣスキームは、しばしば衝突回避スキームまたは衝突検出スキームのいずれかを実施する。そのようなＭＡＣスキームの例は、ＴＩＡ／ＩＳ−９４（ＴＤＭＡセルラー仕様）、ＴＩＡ／ＥＪＡ  ９５−Ｂ（ＣＤＭＡセルラー仕様）、ＴＩＡ／ＥＩＡ／ＩＳ−２０００シリーズ（ＣＤＭＡ２０００セルラー仕様）、ＴＩＡ／ＥＩＡ−７３２シリーズ（セルラー・データパケット・データ仕様）、ＩＥＥＥ  ８０２．３−２００２（搬送波感知多重アクセス／衝突検出（ＣＳＭＡＩＣＤ）アクセス方式および物理層仕様）およびＩＥＥＥ  ８０２．１１（無線ＬＡＮ媒体アクセス制御（ＭＡＣ）および物理層（ＰＲＹ）仕様）に見られるが、言及によってそれらを本書に取り込む。これらのＭＡＣスキームは、相互の互換性がなく、調停を要し（例えば異なるＭＡＣスキームを使用するネットワーク間のブリッジまたはゲートウエイ）、それぞれが自己のハードウェアおよびソフトウェア設定を利用する。
【０００７】
多くのそのようなＭＡＣスキーム（例えばｉＥＥＥ  ８０２．１１）は、衝突回避を可能にし、したがって共有媒体へのアクセスを調停するために、「一度に一局」つまりシリアル処理を実施する。他のＭＡＣスキーム（例えばＩＥＥＥ  ８０２．３などのイーサネット）は、共有媒体へのアクセスを調停するために、衝突検出およびバック・オフ期間が提供されるランダムアクセス処理を実施する。以下の記載からよりよく理解されるように、これらのスキームの各々にはそれに関連した不都合がある。
【０００８】
受け入れ可能な解決策を提供するために、ＭＡＣスキームは共有媒体へのアクセスの調停に加えて、典型的には種々の問題に対処する必要がある。そのような他の問題は、アクセス公平、競合制御、スループット効率、ネットワーク安定および待ち時間などのパフォーマンス目標を含む。従って、ＭＡＣ層設計性能特性は、一般にそのようなパフォーマンス目標間のバランスを含む。スループットと待ち時間は通常、他の種々の下位のパフォーマンス目標と交換される。一般に、装置供給者は生の伝送速度（スループット率ではない）を提示し、典型的なユーザ転送要件では、媒体はボトルネックではないから、上記バランスでのスループット効率の優先度は低い。
【０００９】
現在のＭＡＣスキームについての理解のよりよい助けとして、２つの広く使用されているデータ網ＭＡＣスキームに関する詳細を以下に示す。具体的には、衝突検出スキームの例を提供するＩＥＥＥ  ８０２．１１（ＷｉＦｉ）ＭＡＣスキームと、衝突回避スキームの例を提供するイーサネットＭＡＣスキームとを、以下で述べる。
【００１０】
ＩＥＥＥ  ８０２．１１は２つのＭＡＣ構成に備える。一方は「インフラストラクチャー」構成としてのしばしば呼ばれる点調整機能（ポイント調整機能；ＰＣＦ）であり、他方は「アドホック」ないしピア・ツー・ピア構成としばしば呼ばれる分散協調機能（ＤＣＦ）である。ＰＣＦは局とのアクセス・ポイント通信用の媒体を制御し、ＤＣＦは個別局の通信用媒体の制御を行う。
【００１１】
ＰＣＦ動作（例えば「インフラストラクチャー」構成）は、媒体の合計制御を常時行う点調整に基づき、従って衝突回避スキームを提供する。局との通信方法は、図２に示すように一度に一局ポーリングすることからなる。各反復間隔（例えば反復間隔２００）はそれぞれ、新しい反復の開始を局に通知し、制御メッセージを送信するビーコンフレーム（例えばビーコンフレーム（ＢＥＡＣＯＮ）２０１）で開始する。次に、ポーリング・フレーム（例えばポーリングフレーム（ＰＯＬＬ）２０２）が第１局へ送られる。このポーリングフレームは、第１局用のデータを含んでいてもよい。第１局は「ＡＣＫ」フレーム（例えばＡＣＫフレーム２０３）で答える。ＡＣＫフレームは、第１局からのデータを含んでいてもよい。ＰＣＦ動作は、個々の局に関連したポーリングフレーム（例えばポーリングフレーム２０４、２０６および２０７）を使用して、他の局に対して、一度に一局、ポーリングを続ける。局は上記のようにＡＣＫフレーム（例えばＡＣＫフレーム２０５および２０８）でポーリングフレームに応答するが、局の電源が落とされたか、休止したなどの状況ではＡＣＫフレームで応答しないかもしれない。
【００１２】
図２で見ることができるように、最短フレーム間スペース（ＳＩＰＳ）およびＰＦＣフレーム間スペース（ＰＩFＳ）は、時間間隔を提供するために前述のフレーム間に設けられる。例えば、ＳＩＰＳは伝播遅延に対応するようにフレーム間の間隔に使用される。ＰＩFＳは、ポーリングされた局が応答しなかった時、ポーリングフレームの一端から次のポーリングフレームの開始までの間隔に使用される。
【００１３】
ＰＣＦ  ＭＡＣ層のスループットの上限は、ポーリングフレーム、ＳＩＦＳおよびデータフレーム（ＤＡＴＡ  ＦＲＡＭＥ）を備えたＡＣＫの反復の流れからなる、図３の反復間隔３１０で表わされたケースである。ポーリングフレーム、ＳＩＦＳおよびデータフレームを備えたＡＣＫが典型的にそれぞれ約６２バイト、１０μｓおよび５００バイトであると仮定すると、上限スループット効率は、それぞれ１Ｍｂ／ｓ〜１Ｇｂ／ｓの生ビットレートで、８９％から１６％である。他の興味ある上限は単一の局スループットである。５局のモデルであって、モデル中の１つの局が常時アクティブで他の４つが休止である（図３の反復間隔３２０を参照）と仮定すると、単一局のスループット効率の上限は、それぞれ１Ｍｂ／ｓ〜１Ｇｂ／ｓの生ビットレートで、５０％から４％である。図３の表３３０は上限スループット対生ビットレート（媒体中のビットレート）を示す。
【００１４】
上記ＰＦＣスキームの主な利点は、システムが競合なしの環境で作動するということである。しかし、送るべきデータを持たないか活動していない局に費やす時間、かなりの非アクティブ時間（例えばＳＩＦＳとＰＩＦＳ）および可変遅れを含むスキームに関連した幾つかの欠点がある。ＰＣＦパフォーマンス特性は以下のとおりである：（１）競合、競合なし、これはシステム作動とスループットを単純化する；（２）公平性、高い公平性、すべての局が媒体にアクセスする等しい機会を得る；（３）待ち時間、待ち時間はトラフィック負荷とともに変化する；そして（４）スループット、スループット効率は低い。
【００１５】
ＤＣＦ動作（例えば「アドホック」またはピア・ツー・ピアの構成）は、点調整のない媒体制御を提供するために衝突回避に基づく。具体的には、ＩＥＥＥ  ８０２．１１によって実施されるようなＤＣＦは、送信要求（ＲＴＳ）および送信可（ＣＴＳ）と共に、搬送波検知多重アクセス方式（ＣＳＭＡ）、衝突回避（ＣＡ）、（ＣＳＭＡ／ＣＡ）を利用する。ＩＥＥＥ  ８０２．１１のＤＣＦスキームとイーサネットとの主な違いは、隠れノードを取り扱うＤＣＦの能力である。隠れノードとは、ネットワーク中の１つ以上の局が他局の送信状態を検出することができず、したがって、そのような他局がその局に対して「隠れている」（隠れノード）であることを意味する。無線と電力線の通信ネットワークでは、隠れノードは、いくつかの局間の高い経路損失のために一般的である。ＲＴＳ／ＣＴＳを備えたＣＳＭＡ／ＣＡは隠れノードの問題に取り組むために開発された。
【００１６】
ＲＴＳ／ＣＴＳを備えたＣＳＭＡ／ＣＡの単独接続プロセス例が図４に示される。ソースは、媒体が分散フレーム間隔（ＤＩＰＳ）と等しい時間使用されていなかった後、ＲＴＳ（例えばＲＴＳ４０１）を送った局であり得る。このＲＴＳは、送信要求だけでなく、宛先以外の他のすべての局へのネットワーク割付けベクトル（ＮＡＶ）としても働く。ある局がＮＡＶ（ここではＲＴＳ）を検出すると、それは媒体が次の２つのデータフレームに使用中であることを意味する。宛先（例えばアクセス・ポイント）はＳＩＦＳ間隔の後にＣＴＳ（例えばＣＴＳ４０２）でＲＴＳに応答してもよい。オリジナルソースはＣＴＳを検出し、「媒体が空いている」そして「宛先はマッサージを受け取る準備ができている」と解釈し、ＳＩＦＳ間隔の後にそのデータ（例えばデータ４０３）を送信する。ＣＴＳは、ＲＴＳと同様、局間のハンドシェーキング・パケットだけでなく、媒体が１つのデータフレームの後にフリーになることを示す、他局へのＮＡＶとしても働く。宛先はＳＩＰＳ間隔の後に、データに応じてＡＣＫ（例えばＡＣＫ４０４）を提供して、宛先は送信が成功したことをソースに通知する。媒体へのアクセスに関して公平を確立するために、ソース（それはデータ送信に媒体を使用したばかりである）は、それが次のフレームで媒体・アクセスの競合を防止する競合ウィンドウ（例えば競合ウィンドウ４０５）を呼び出す。
【００１７】
図５は、多数局環境でのＣＳＭＡ／ＣＡ動作の例を示す。図５の例では、局Ａは、上記の送信要求４０１、送信可４０２、データ４０３およびＡＣＫ４０４に対応し得るフレーム５０１の送信を終え、公平のために上記の競合ウィンドウ４０５に対応し得る競合ウィンドウ５０２を呼び出す。図示の実施形態の局Ｂ〜Ｄのそれぞれはフレーム５０１の間に媒体アクセス処理を始めたが、前述のＮＡＶの使用を通じて、フレーム５０１プラスＤＩＦＳ期間（図５の時系列で５０３として示す）の終わりまでそれらのアクセスを遅らせた。フレームが完了すると、各局Ｂ〜Ｄは媒体が空いたことを検知し、媒体にアクセスする（例えば、送信要求を送信する）のを少なくともＤＩＦＳ期間だけ待つ。しかし、媒体競合または通信衝突を回避するために、図示の例のＣＳＭＡ／ＣＡは、局Ｂ、ＣおよびＤのためのバック・オフ期間５０４、５０５および５０６としてここに示された、各局のアクセス保留時間に加えられたランダムアクセス時間またはバック・オフ期間を含んでいる。媒体が局のバック・オフ期間の終了時に空のままであれば、局は送信要求を送信することができる。
【００１８】
図示の例で、局Ｃは最短のバック・オフ期間を持ち、したがって、上記送信要求４０１、送信可（ＣＴＳ）４０２、データ（ＤＡＴＡ）４０３およびＡＣＫ４０４に対応し得るフレーム（ＦＲＡＭＥ）５０７の送信を完了するために媒体にアクセスし、公平のために上記の競合ウィンドウ４０５に対応し得る競合ウィンドウ５０８を呼び出す。図示の例に示すように、局ＢおよびＤはフレーム５０７の間にバック・オフ期間を終え、したがって媒体が使用中であると知る。局ＢおよびＤは、上記のように、再び送信保留およびランダムバック・オフを開始する。また、図示の例に示すように、局Ｂはフレーム５０７の間に媒体アクセス処理を始めたが、媒体が使用中であり、前述のようにフレーム５０７プラスＤＩＦＳ期間（図５の時系列で５０９として示す）の終わりまでアクセスを遅らせた。
【００１９】
局Ｃによるフレーム５０７が完了すると、各局Ｂ〜Ｅは、媒体が空であることを検知し、前述のように、媒体にアクセスすることを少なくともＤＩＦＳ期間およびそれぞれのバック・オフ期間だけ待つ。図示の例で、バック・オフ期間５１０（局Ｂ）および５１２（局Ｂ）は、バック・オフ期間５１１（局Ｄ）より長く、したがって局Ｄは媒体が空であると知り、フレーム５１３の送信を終えるために媒体にアクセスする。
【００２０】
公平を期すために、局Ｂが以前媒体を待ったことがあるので、局Ｂのバック・オフ期間は、期間５１０として（バック・オフ期間５０４と比べて）短縮される。しかし、図示の実施形態で、局Ｅの任意に選択されたバック・オフ期間（バック・オフ期間５１２）は局Ｂの対応するバック・オフ期間（バック・オフ期間５１０）より当初短かったので、局Ｂはフレーム５１３の終了後に媒体を確保することができる。つまり、両局ＢおよびＥは、それらの後のバック・オフ期間を短くしたが、その結果生じるそれぞれのバック・オフ期間は、局Ｅが最初に媒体にアクセスするようなものであった。
【００２１】
上述の衝突回避は、各局がＮＡＶを検出できることが条件であることを理解すべきである。隠されノード状況（つまり、ある局が別の局からの送信を検出することができない）では、特定の局からの送信要求のような前述のＮＡＶは、別の局によって検出されないかもしれない。従って、媒体は複数の局によって同時に使用され、各々の送信を使用不可にするよう試みることができる。そのような衝突は、スループットのかなりの低下と、局の数および特定のトポロジーによってそのような検知されない衝突が増加する可能性を生じるかもしれない。
【００２２】
上記ＤＣＦスキームの主な利点は、システムが休眠端末（例えば電源が落とされたか、休止した局）に対して休止期間あるいはポーリング期間を実施しないということである。しかし、競合制御、かなりの非アクティブ時間（例えばＳＩＦＳとＤＩＦＳ）および隠れノードに影響されるスループットに関連したかなりの休止期間を含む、スキームに関連した幾つかの欠点がある。ＤＣＦパフォーマンス特性は以下のとおりである：（１）競合、複合システムオペレーションおよび低下したスループットに帰着するかなりの競合；（２）  公平性、中程度の公平性、ランダム化によってある局が媒体にアクセスする機会が増加する；（３）待ち時間、待ち時間はトラフィック負荷とともに変化する；そして（４）スループット、スループット効率は低い。
【００２３】
上記から、バック・オフ期間による衝突検出を使用した競合の解決を通じて公平性が保証されず、また、点調整競合解決を通じて公平性を達成することができるが、衝突回避競合解決を可能にする点調整の結果、スループットがしばしば低下することが理解されよう。さらに、前述のＳＩＦＳ、ＤＩＦＳおよびバック・オフ期間などの媒体不使用の期間がスループットに影響する。
【発明の開示】
【発明が解決しようとする課題】
【００２４】
〔発明の要約〕
本発明は、予定された媒体アクセス制御（ＭＡＣ）アーキテクチャを提供するシステムと方法に関する。本発明の実施形態の予定されたＭＡＣを使用して、通信のために局が同期されることが望ましい。発明の実施形態によって提供される予定されたＭＡＣは、衝突回避アーキテクチャを介する競合制御を提供するだけでなく、アクセス公平性、平等なアクセスまたは不平等なアクセス（例えばサービス品質（ＱｏＳ）ベースのアクセス、加重利点アクセス、優先アクセスなど）、競合制御をも、を提供する。
【課題を解決するための手段】
【００２５】
発明の実施形態は、媒体から独立した予定されたＭＡＣの実施を通して、フィジカル層からＭＡＣ層を分断する。従って、実施形態のＭＡＣアーキテクチャは、二重か単信か、時分割多重アクセス（ＴＤＭＡ）、チャンネル分割多重アクセス（例えば３周波数分割多重アクセス（ＦＤＭＡ）、符号分割多重アクセス（ＣＤＭＡ）など）にかかわらず、フィジカル層に依存しない。本発明の実施形態は様々な媒体に対して媒体アクセス制御を提供するのに利用することができる。例えば、発明の実施形態は、無線通信、電力線および／またはワイヤー・ライン・インフラストラクチャーに関して使用されるＭＡＣアーキテクチャを提供することができる。同様に、本発明の実施形態によれば、異なるパフォーマンス基準に関して恐らく最適化された異なるＭＡＣアーキテクチャを１つのフィジカル層（例えば共通のハードウェアプラットフォーム）での使用に提供することができる。
【００２６】
発明の実施形態によって提供される予定されたＭＡＣアーキテクチャは、局に並行プロセス媒体アクセスが与えられる一度に１機能のアプローチとなる。例えば、媒体にアクセスする必要のある各局は、そのような各局がデータ送信を行なうに先立って、媒体アクセス要求を行ない、それによって並行プロセス・アプローチで作動する。
【００２７】
発明の実施形態によれば、点調整（ＰＣ）運営局、ゲートウエイ、ブリッジ、ユーザー端末および他の局の間のように共有媒体上での局間の通信用として通信フレームワークが設定される。通信フレームワークは、アクセス要求方法、データフレーム送信方法および機能的間隔の点からセッションを終了する方法を規定することが望ましい。公平性、スループット効率、競合、トラフィックフロー管理および待ち時間が考慮されるように、機能的間隔を配列することが望ましい。従って、発明の実施形態の予定されたＭＡＣアーキテクチャは、アーキテクチャを使用して、機能の時間系列と、各機能が競合制御、アクセス公平性、スループット効率、ネットワーク安定性および待ち時間などの希望のパフォーマンス目標を満たす間隔とを最適化して、支持される機能の選択を通じて提供される。発明の実施形態によって実施される一度に１機能のアプローチは、機能的間隔の管理に使用されるプロセスを単純化する。
【００２８】
発明の実施形態によって実施される予定されたＭＡＣアーキテクチャは、単一の共有媒体で接続型と非接続型の両方の通信に対応することができる。例えば、非接続型の通信は、媒体へのアクセスが必要な局が、アクセス必要の機能的間隔時に次のデータフレーム機能的間隔を求めるアドホックな要求を発信することによって行われ、接続型の通信は、アクセス必要の機能的間隔時に、一連のデータフレームの機能的間隔時に媒体アクセスを予定するか予約する局を通して行われる。
【００２９】
発明の実施形態による動作で、共有媒体と通信するゲートウェイ、ブリッジ、アクセス・ポイントあるいは他のノードまたは局などで実施（運営）される点調整は、予定されたＭＡＣスーパーフレームの開始を示すビーコンを提供する。媒体へのアクセスを必要とする各局は、アクセス必要（ＮＦＡ）機能的間隔で受信確認（ＡＣＫ）、またはアクセスの必要性があることの他の表示で応答することができる。さらにあるいは代替として、媒体へのアクセスを必要とする各局は、必要とされるリソースに関する情報（例えば、望まれる帯域幅、優先順位表示、予定されたアクセス継続時間など）を、受信確認自体または他の通信（例えば、リソース要求（ＲＦＲ）機能的間隔）で提供してもよい。点調整は、データフレームの機能的間隔でデータを送信する時期、および各局に割り付けられたデータ量伝送帯域幅の量などの、リソースの割付けに関する情報を送信時期（ＷＴＳ）機能的間隔で提供することが望ましい。局は、データフレーム機能的間隔内の適切なタイムスロット中でデータを送信するためにこの情報を利用することができる。
【００３０】
局へ送信されたデータは、送信時期機能的間隔などの上記機能的間隔のうちの１つ、ダウンリンク伝送用の他のデータフレーム機能的間隔で提供されてもよい。送信時期機能的間隔などで点調整から局へ提供される情報は、特定の局による使用のためのアップリンク・データ伝送および／またはダウンリンク・データ機能的間隔伝送タイムスロットを識別してもよい。
【００３１】
スーパーフレームおよびその中の種々の機能的間隔は、即座のトラフィック・ニーズに対応するため可変長であることが望ましい。例えば、媒体アクセスを要求する局がない場合、スーパーフレームは、データが含まれないリソース要求、送信時期およびデータ伝送機能的間隔によって実質的に短縮されてもよい。
【００３２】
上記の機能的間隔と、追加ないし代替の機能的間隔も同様に、上に概説された以外のスーパーフレームにおいて組織され得ることを理解すべきである。例えば、１つ以上の関連する機能的間隔は、異なるスーパーフレームで提供されてもよい。１つの実施形態によれば、アクセス必要およびリソース要求機能的間隔が第１のスーパーフレームで提供され、関連する送信時期およびデータフレームの機能的間隔は後のスーパーフレームで提供される。
【００３３】
発明の実施形態によれば、機能的間隔は、本発明の予定されたＭＡＣの機能以外の機能に利用することができる。例えば、予定されたＭＡＣスーパーフレーム・アーキテクチャの機能的間隔は、既存のＭＡＣプロトコルのために取っておいてもよい。例えば、ＣＳＭＡプロトコルとの共存は、機能間隔がＣＳＭＡプロトコル用である以外、他のすべての機能間隔がＤＩＥＳより長い媒体不使用間隔を持たないことを保証することにより対応することができる。言いかえれば、すべての予定されたＭＡＣプロトコル手段からの送信が禁止されるブランク間隔が生じるまで、予定されたＭＡＣプロトコル手段は正常に作動する。そして、媒体は予定されたＭＡＣプロトコル手段から解放され、媒体が非接続であるからＣＳＭＡプロトコル手段がアクティブになる。
【００３４】
本発明の実施形態は、ＭＡＣ性能を高めるために前述の機能的間隔を利用する最適化アルコリズムを実行する。そのような最適化アルコリズムは、１つ以上のパフォーマンスパラメータを最適化ないし高めるが、他の関心のあるパフォーマンスパラメータに関してマイナスの影響がないという点で中立であることが望ましい。発明の実施形態による機能的間隔を持った通信フレームワークを使用すると、ネットワーク特性の決定性挙動を用いて公平性、スループット効率、競合、トラフィックフロー管理および待ち時間を最適化するために、トラフィック状態についての十分な知識に基づいて、アルゴリズムが割り付けの決定を動的に行うよう作動できる。例えば、第１の機能的間隔で提供される種々の局の媒体アクセスの必要性に関する情報（例えばリソース要求で提供される）は、そのようなアルゴリズムによって次の機能的間隔の利用を割り付ける際に利用され得る（例えば、データ伝送フレームへのアクセスを特定の局に割り付ける、データ伝送フレームの利用が許可された局へデータ伝送フレーム内のキャパシティーを割り付けるなど）。
【００３５】
さらにあるいは代替として、そのようなアルゴリズムは、他のパフォーマンス目標を下げずにスループットを最適化するために、機能的間隔の１つ以上を動的に調節してもよい。１つの実施形態によれば、最短のフレーム間スペース（ＳＩＦＳ）は、一定の時間間隔ではなく、同期された通信と計算された伝播遅延情報を使用して決定された、動的に調整されたタイムスロット間隔である。
【００３６】
本発明の概念に従って提供されたＭＡＣアーキテクチャは、バックオフ・プロセスのない競合解除、スループットを犠牲にしない公平性、短縮されたアイドルタイム（例えば、減少したＳＩＦＳ、ＤＩＰＳなど）、局の数および生のビットレートにかかわらない高スループット効率、そして待ち時間に関する改良された一貫性を提供する。さらに、本発明の実施形態のＭＡＣアーキテクチャは異なる状態下のネットワーク挙動に関して決定性パフォーマンスを提供し、それはシステムの開発、検査およびメンテナンスを単純化する。
【００３７】
以上、後記する発明の詳細な説明が一層よく理解されるように本発明の特徴および技術的な利点をやや大まかに述べた。発明のさらなる特徴と利点は以下に記載するが、それらは請求項の主題を形成する。開示された概念および特定の実施形態が、本発明の同じ目的を達成するための他の構造を修正または設計する根拠として、容易に利用され得ることは当業者に理解されるはずである。また、そのような等価の構造が、付加された請求項に記載された発明の趣旨および範囲から外れないことが当業者に理解されるはずである。発明の特徴であると考えられる新規特徴は、その構成と動作方法に関して、さらなる特徴と利点とともに、添付図と関連して考慮される以下の説明から一層よく理解されよう。しかし、各図が例示と説明のみの目的で提供され、本発明の範囲の限定として意図されないことを明確に理解されたい。
【００３８】
〔図面の簡単な説明〕
本発明のより完全な理解のため、添付図に関連した以下の説明を参照する。
【００３９】
図１は、共有の媒体によって通信を提供するネットワーク構成を示す。
【００４０】
図２は、一度に１つの局をポーリングすることによって媒体アクセス制御を行う従来の点調整機能を示す。
【００４１】
図３は、従来の点調整機能、媒体アクセス制御層のスループットの上限を示す。
【００４２】
図４は、搬送波検知多重アクセス方式衝突回避に送信要求／送信可を備える従来の分散協調機能結合プロセスを示す。
【００４３】
図５は、多局環境における従来の搬送波検知多重アクセス方式衝突回避動作の例を示す。
【００４４】
図６は、本発明の実施形態による共有の媒体を介する通信を提供するネットワーク構成を示す。
【００４５】
図７（Ａ）〜図７（Ｃ）は、本発明の実施形態の予定された媒体アクセス制御アーキテクチャによって定義されたスーパーフレームの種々の構成を示す。
【００４６】
図８は、本発明の予定された媒体アクセス制御アーキテクチャの実施形態を示す。
【００４７】
図９（Ａ）〜図９（Ｇ）は、本発明の予定された媒体アクセス制御アーキテクチャのフレーム構造の実施形態を示す。
【００４８】
図１０（Ａ）〜図１０（Ｃ）は、本発明の実施形態による種々の処理を提供するためのフレーム交換プロトコルを示す。
【００４９】
図１１（Ａ）〜図１１（Ｃ）は、発明の実施形態によるデータ通信のためのデータフレーム交換を示す。
【００５０】
図１２は、本発明の実施形態の予定された媒体アクセス制御アーキテクチャを実施するイーサネットまたはＷｉＦｉ局の適応例を示す。
【００５１】
図１３は、本発明の実施形態による予定された媒体アクセス制御アーキテクチャを標準ネットワーク装置に対して透明にするために媒体のまわりに構築されるプロトコルアダプタの例を示す。
【００５２】
図１４は、本発明の実施形態による予定された媒体アクセス制御機能ブロック図を示す。
【００５３】
図１５は、本発明の実施形態による予定された媒体アクセス制御アクセス機能ブロック図を示す。
【００５４】
図１６は、発明の実施形態のトラフィックフロー制御アルゴリズムの動作のフロー図を示す。
【００５５】
図１７は、媒体中のフレーム間スペース対観測点の位置を示す。
【００５６】
図１８（Ａ）は、種々の局およびゲートウェイの位置とともに論理網を示す。
【００５７】
図１８（Ｂ）は、本発明の実施形態のフレーム間スペース・マトリックスを示す。
【００５８】
そして、図１９は、本発明の実施形態による最小のフレーム間スペース値の検出と、フレーム間スペース補正の実施のフロー図を示す。
【発明を実施するための最良の形態】
【００５９】
〔発明の詳細な説明〕
発明の実施形態の媒体アクセス制御（ＭＡＣ）プラットフォームは、点調整（ＰＣ）（例えば図６のＰＣ６０１）、ゲートウェイ（例えば図６のゲートウェイ１１０）、ブリッジ、局（例えば図６のユーザー端末１０１〜１０５）および／または共有媒体（例えば図６の媒体１００）用の他の装置の間で基本の通信フレームワークを設定する。実施形態の点調整６０１は本書に記載される媒体アクセス制御を提供するホスト・プロセッサーに基づくシステム（例えばゲートウェイ１１０、ブリッジ、サーバーあるいは他の局）上で動作可能な制御アルゴリズム（例えばソフトウェアコード）を備える。実施形態の点調整６０１を運営するために、ゲートウェイ１１０などの種々の局は、より高い処理能力、より大きいメモリ、追加の入出力機能性などの追加的リソースを含むよう構成することができる。点調整６０１に従って提供される制御に応答するために、媒体１００を共有する局（例えばユーザー端末１０２〜１０５およびゲートウェイ１１０）は、本書に記載されるように媒体アクセス制御を実行する制御アルゴリズムを含むよう構成される。例えば、媒体アクセス制御層ソフトウェア・アルゴリズムは、本書に記載されるように各ユーザー端末１０１〜１０５での動作を規定するために提供することができる。
【００６０】
発明の実施形態は、共有される通信媒体に競合制御を提供するための予定された媒体アクセス制御（ＭＡＣ）アーキテクチャを実施する。発明の実施形態によって提供される、予定されたＭＡＣは、一度に１つの機能の方式に帰着する可変長のスーパーフレーム用の機能的な間隔フレームワークを実施する。発明の実施形態のＭＡＣアーキテクチャはＭＡＣプラットフォームおよび最適化アルコリズム機能モジュールを備え、そこでは、ニュートラルのアルゴリズムが他のパフォーマンス目標を下げずに、１つ以上のパフォーマンス目標を高めるように、ニュートラルのアルゴリズムが多数目標環境に対して動作可能であることが望ましい。
【００６１】
本発明の実施形態は、種々の媒体および／またはネットワークに対して媒体アクセス制御を提供するのに利用できる。例えば、発明の実施形態は、無線、電力線および／またはワイヤー・ライン・インフラストラクチャーで利用されるＭＡＣアーキテクチャを提供することができる。発明の実施形態のＭＡＣアーキテクチャは、公衆データ網（インターネット）、ローカルエリアネットワーク（ＬＡＮ）、都市内ネットワーク（ＭＡＮ）、広域ネットワーク（ＷＡＮ）、公衆交換電話網（ＰＳＴＮ）、有線伝送システム、衛星送信システムなどのネットワークに利用できる。
【００６２】
発明の実施形態の予定されたＭＡＣアーキテクチャは、共有される媒体通信ビット・ストリームを反復スーパーフレーム間隔に分割する。各スーパーフレーム間隔は、前述の機能的な間隔を提供するサブ間隔を含むことが望ましい。実施形態のＭＡＣプラットフォームの点調整（ＰＣ）は、ゲートウエイ１１０あるいは他の点調整ホスト、ユーザー端末１０１〜１０５などの局に指示を与えることにより、上記スーパーフレームおよび関連する機能的間隔を管理するスケジューラを提供する。ポイント調整は、トラフィック要件についての十分な知識を持ってスケジューリングを管理することが望ましく、それによって、公平性、スループット効率、競合、トラフィックフロー管理および／または待ち時間を達成する際の典型的なＭＡＣスキームに対する優位を確保する。
【００６３】
発明の実施形態の点調整によってすべてのアップストリーム・トラフィックが管理されることで、点調整とそのホスト（例えばゲートウエイ）の組合せは、ネットワーク・トラフィックについての十分な知識を持つ。従って、ネットワーク・トラフィック管理およびネットワークパフォーマンス（例えばフレーム・ロス、過負荷状態など）は、ソフトウエアで対処することができる。
【００６４】
実施形態のスーパーフレームの機能的な間隔は、１つ以上のデータフレーム（ＤＡＴＡ  ＦＲＡＭＥ）サブ間隔、アクセス必要（ＮＦＡ）サブ間隔、リソース要求（ＲＦＲ）サブ間隔、応答（ＡＣＫ）サブ間隔、ビーコン（ＢＥＡＣＯＮ）サブ間隔、そして送信時期（ＷＴＳ）サブ間隔を含む。上記サブ間隔は、スーパーフレームのアップストリーム（例えば端末から点調整運営ゲートウエイへ）および／またはダウンストリーム（例えば点調整運営ゲートウエイから端末へ）部分に備えることができる。例えば、ビーコンサブ間隔、ＷＴＳサブ間隔および／またはデータフレーム・サブ間隔は、スーパーフレームのダウンストリーム部分に対応付け、ＮＥＡサブ間隔、ＲＦＲサブ間隔、ＡＣＫサブ間隔および／または別のデータフレームサブ間隔は、スーパーフレームのアップストリーム部分対応付けることができる。
【００６５】
発明の実施形態による動作で、点調整と予定されたＭＡＣを調整する局との間の制御通信は、ビーコンサブ間隔、ＮＦＡサブ間隔、ＲＦＲサブ間隔、ＷＴＳサブ間隔、ＡＣＫサブ間隔およびデータフレームサブ間隔の制御フレームを介する。ペイロード・データ（例えばゲートウエイと関連する端末との間で運ばれるネットワーク・トラフィック）は、データフレームサブ間隔を介して運ばれる。局は、点調整によって規定された、予定されたスロットに基づいてデータフレームを送る。点調整の１つ以上の最適化アルコリズムは、最適のあるいは望ましいパフォーマンスのために機能的な間隔（例えば順序、長さ、局へのリソースの割り当て等）を操作することが望ましい。
【００６６】
図７（Ａ）〜図７（Ｃ）に注目すると、本発明の実施形態の予定されたＭＡＣアーキテクチャによって規定されたスーパーフレームの種々の構成が示される。図示の実施形態の予定されたＭＡＣアーキテクチャは、共有の媒体ビット・ストリームを、Ｎ−１番目のスーパーフレーム間隔、Ｎ番目のスーパーフレーム間隔およびＮ＋１番目のスーパーフレーム間隔として示された反復スーパー・フレーム間隔に分割する。図示の実施形態の各スーパー・フレームは、そこに規定された複数の機能的間隔を含むことが望ましく、それらはビーコンサブ間隔７０１、アクセス必要（ＮＦＡ）サブ間隔７０２、リソース要求（ＲＦＲ）サブ間隔７０３、送信時期（ＷＴＳ）サブ間隔７０４、ダウンストリーム・データフレームサブ間隔７０５およびアップストリーム・データフレームサブ間隔７０６を含む。
【００６７】
以下の記載によってよく理解されるように、発明の実施形態によれば機能的な間隔の順序と長さは可変である。従って、図７（Ａ）〜図７（Ｃ）の実施形態は、本発明の予定されたＭＡＣアーキテクチャのスーパーフレーム内の機能的な間隔のいくつかの配置を示す。発明の実施形態により実施される機能的な間隔の配置は、複数のスーパーフレーム間隔にわたって対応する機能的な間隔を広げることを含んでもよい。例えば、リソース要求サブ間隔は、リソース要求サブ間隔での要求に応じて情報を提供する送信時期サブ間隔と異なる（例えば直前の）スーパーフレーム間隔に提供されてもよい。
【００６８】
データフレームサブ間隔を、他の機能的な間隔（例えば、ビーコンサブ間隔、ＮＦＡサブ間隔、ＲＦＲサブ間隔および／またはＷＴＳサブ間隔）に関して図示されたものと異なるスーパーフレームに位置づけ得るばかりでなく、アップストリームとダウンストリームのデータフレームサブ間隔を互いに図示と異なるよう位置づけてもよい（例えばアップストリーム・データフレームサブ間隔がダウンストリームのデータフレームサブ間隔の前にスーパー・フレーム間隔に生じる）ことを理解すべきである。データフレームサブ間隔の配置を他の機能的な間隔と他のデータフレームサブ間隔に関して変えてもよく、可能な構成が非常に多くなるから、データフレームサブ間隔は図７（Ｂ）および図７（Ｃ）において明示されておらず、図面を簡単にするために図７（Ａ）で１つの構成を示すのみである。
【００６９】
図７（Ａ）〜図７（Ｃ）の実施形態に明示しないが、発明の実施形態によれば受信確認（ＡＣＫ）サブ間隔が使用される。例えば、ＡＣＫサブ間隔は、受信局による受信確認が望まれる別の機能的な間隔の後のスーパーフレーム間隔の時系列に配置されてもよい。唯一の例として、ＡＣＫサブ間隔はダウンストリームのデータフレームサブ間隔７０５に続くアップストリームのビット流れに形成されてもよく、これはダウンストリームのデータフレームサブ間隔７０５のデータフレームを割り当てられた局が該当データフレームの受信を認めることを容易にするためである。
【００７０】
発明の実施形態のスーパー・フレーム間隔の開始は、図示の実施形態のビーコンサブ間隔７０１に提供されるような送信ビーコンによって区切られる。そのような送信ビーコンは、媒体を共有する種々の局を同期させるために、特に本発明の好適実施形態のようにスーパーフレーム間隔が可変長である場合に使用することができる。従って、実施形態の送信ビーコンは、新しいスーパー・フレームの開始の時間表示を提供する。送信ビーコンは、局がビーコンとして容易に認識しうる一意のデータストリングまたは他の送信でよい。ビーコン・ストリングに加えて、本発明の実施形態はビーコンサブ間隔内に、あるデータ量（例えば制御データ）を提供してもよい。例えば、サブ間隔タイミング情報、サブ間隔長さ情報、サブ間隔組織情報、タイミング・オフセット（例えばタイミング前進）情報、機能的な間隔時間スロット情報（例えば適切なサブ間隔中でアクセス必要および／またはリソース要求情報を送る特定局用のタイムスロット）などを、発明の実施形態のビーコンサブ間隔内に設定することができる。
【００７１】
発明の実施形態による動作で、送信ビーコンは予定されたＭＡＣ実施および制御のための種々の全体的なメッセージを提供する。そのような全体的メッセージは、各局が興味のある間隔を見つけるのを助けるために、例えばスーパーフレーム長さ、上下ストリームでの各間隔の開始時間など、各間隔の時間位置を含んでもよい。以下に述べるように、リソース要求スケジューリングが使用される場合、送信ビーコンによって提供される全体的メッセージは、スーパーフレーム間隔の前部に間隔の時間位置を提供してもよい。実施形態の送信ビーコンによって提供される全体的メッセージは、種々の局によって実施されるトラフィックフロー管理アルゴリズムが、アクセス必要メッセージングの制御など、共有媒体へのアクセスを制御することを可能にする、負荷状態（例えば軽い、中程度、そして高い）などのトラフィックフロー管理情報を含む。例えば、負荷状態が中程度であれば、現在のスーパーフレーム間隔でデータを送った局は、次のスーパーフレーム間隔でデータフレームを要求するのに不適格となり得る（例えば、局は共有媒体にアクセスすることを必要とするが、局はアクセス必要サブ間隔で否定応答を与える）。実施形態の全体的メッセージは、全体的なソフトウエア更新などを提供するために全局の送信機をオフ・オンにするなどの保守メッセージをさらに、または代わりに含んでもよい。例えば、局追加および／または除去メッセージをすべてのスーパーフレーム間隔の送信ビーコンに含んでもよい。
【００７２】
実施形態のスーパーフレーム・アーキテクチャは、すべてのスーパー・フレーム間隔のトラフィック要件のスナップショットを作成する機会を提供する。図示の実施形態では、トラフィック要件情報は、データ伝送のために共有媒体にアクセスすることを望む種々の局からアップストリームに提供されるＲＦＲサブ間隔７０３を介して点調整によって収集される。必要とされるリソースに関する情報（例えば、望まれる帯域幅、送信されるデータの種類、送信されるデータ量、サービス優先度または品質情報、一連のスーパーフレームなどの将来のデータフレームサブ間隔の予約またはスケジューリングなど）は、ＲＦＲサブ間隔で通信されることが望ましい。現在リソースを要求している各局のリソースに関する情報は、即座のトラフィック要件の十分な知識をトラフィック計画用として点調整に与えるために、連続的な間隔で、ここではＲＦＲサブ間隔７０３で行われることが望ましい。
【００７３】
実施形態の点調整６０１は、ダウンストリームで送られる送信時期サブ間隔（例えばＷＴＳサブ間隔７０４）に含まれる情報を介してデータフレーム（例えば次のスーパーフレーム間隔中のデータフレーム）を送ることを、リソースを要求する特定の局に許可する。上記のリソース要求サブ間隔の場合と同様に、データフレーム位置メッセージの単純化のために、現在リソースを要求しており、共有媒体へのアクセスが許可された各局がデータフレームを受信するおよび／または送信する時期に関する情報は、連続的な間隔で、ここではＷＴＳサブ間隔７０４で行われることが望ましい。
【００７４】
リソース要求サブ間隔の長さが、媒体を共有するすべての局からの要求に適応すると決定された長さに設定され得ることを理解するべきである。しかし、特定のスーパーフレーム間隔ですべての局より少ない局がリソースを要求している場合、そのような間隔はかなりの媒体アイドルタイムにを生じ得る。媒体を共有する局の数が少ない場合、リソース要求サブ間隔でのリソース要求にすべて適応することは競合問題の回避に望ましいかもしれない。代案として、媒体を共有する局の数が多いか、それがアイドルタイムを最小化することが望まれる場合、リソース要求サブ間隔の長さは、統計的に適切な局数に適応するなど、媒体を共有するすべての局未満からの要求に適応するよう設定してもよい。しかし、リソース要求サブ間隔の長さが特定のスーパーフレーム間隔でリソースを要求するあらゆる局に対応できなければ、局はスーパーフレーム間隔でのスロットの割付け競争をすることになり、競合問題を解決する必要が生じる。
【００７５】
本発明の実施形態は、アイドルタイムを最小化する競合がない解決策を提供するために、可変長のリソース要求サブ間隔を実施する。例えば、どの局が共有媒体へのアクセスを求めているかを発見し、したがってそのような各局からの要求に適応するよう点調整がリソース要求サブ間隔の長さを調節することを可能にするために、図示の実施形態によればリソースサブ間隔（例えばＮＦＡサブ間隔７０２）が提供される。
【００７６】
好適実施形態による動作で、共有媒体にアクセスする必要がある局は、リソースを必要とする局の数を点調整に通知するために、アクセス必要サブ間隔中で短い肯定応答（例えばＡＣＫ）を通信する。さらにあるいは代替として、共有媒体にアクセスする必要がない局は、リソースを必要とする局の数を点調整に通知するために、アクセス必要サブ間隔中で短い否定応答（例えばＮＡＫ）を通信してもよい。そのような短い応答を使用することで、アクセス必要サブ間隔は非常に短くなるが、しかし共有媒体上のすべての局が同時にアクセスを必要することも恐らく統計的に起こり得る（現在の局数、歴史的なネットワーク活動、予測されるネットワーク活動などにもとづいて時々調整されるように）。
【００７７】
どの局が共有媒体へのアクセスを望んでいるかの知識を点調整が一旦入手すれば、点調整はそれらの局のみからの要求に適応するようリソース要求サブ間隔を調整することができる。例えば、点調整は、前のスーパーフレーム間隔（例えばＮ番目のスーパーフレーム間隔）のアクセス必要サブ間隔で肯定応答を提供した各局の要求に適応する適切な長さの間隔のリソース要求サブ間隔を設定する情報を、次のスーパーフレーム間隔（例えばＮ＋１番目のスーパーフレーム間隔）のビーコンサブ間隔で提供することができる。発明の実施形態は、リソース要求サブ間隔で共有媒体へのアクセスを求める各局に、望まれる帯域幅、送信されるデータの種類、送信されるデータ量、サービス優先度または品質情報、一連のスーパーフレームなどの将来のデータフレームサブ間隔の予約またはスケジューリングなどのデータを提供するから、どの局がそのようなアクセスを望んでいるかについての知識と、それに応じてリソース要求サブ間隔の長さを調整することはかなりの効率で達成される。
【００７８】
上記のように、ＮＦＡサブ間隔７０２、ＲＦＲサブ間隔７０３、ＷＴＳサブ間隔７０４などの種々の機能的な間隔のタイミング関係は、図示の実施形態で示されたものと異なり、種々のパフォーマンス基準を最適化するように構成されてもよい。１つの実施形態で、特定のスーパーフレーム間隔（例えばＮ番目のスーパーフレーム間隔）のＲＦＲサブ間隔７０３とＷＴＳサブ間隔７０４は、次のスーパーフレーム間隔（例えばＮ＋１番目のスーパーフレーム間隔）のデータフレームサブ間隔と対応付けられる。この実施形態で、特定スーパーフレーム間隔（例えばＮ番目のスーパーフレーム間隔）のＮＦＡサブ間隔７０２は、２つ後のスーパーフレーム間隔（例えばＮ＋２番目のスーパーフレーム間隔）のデータフレームサブ間隔と対応付けられる。この実施形態は、１つのスーパーフレーム間隔によるデータ送信がさらに遅れることになる。しかし、すべての局からのリソース要求メッセージの合計が、すべての局からのアクセス必要メッセージと共有媒体へのアクセスを求める局からのリソース要求メッセージの合計より大きいと仮定すると、オーバーヘッドにおける全体的な利得が得られる。これは、好適実施形態のアクセス必要メッセージが非常に短いからである（例えば、「ＹＥＳ」または「ＮＯ」の２進メッセージ。）。
【００７９】
発明の実施形態は、リソース要求に関連したアイドルタイムを減らし、データ送信の遅れを減らすために、ＲＦＲスケジューリングサブ間隔７０７として図７（Ｃ）に示す追加の機能的間隔を提供する。図７（Ｃ）に示す実施形態で、ＮＦＡサブ間隔７０２、ＲＦＲスケジューリングサブ間隔７０７、ＲＦＲサブ間隔７０３およびＷＴＳサブ間隔７０４のタイミング関係は、次のスーパーフレーム（例えばＮ＋１番目のスーパーフレーム間隔）のデータフレームに関係する。アクセス必要情報の収集が、実施形態によれば、リソース要求サブ間隔７０３を含む種々の機能的な間隔の構成、長さなどに関して局に情報を提供するビーコンサブ間隔の後であるから、機能的な間隔のそのような配置はＲＦＲサブ間隔７０３の長さに関して未知の変数を導入する。
【００８０】
従って、図７（Ｃ）の実施形態は、スーパーフレーム間隔を、前部と後部として示された２部分に分割する。図示の実施形態の前部は、スーパーフレーム間隔の開始からＲＦＲスケジューリングサブ間隔７０７の開始まで延び、アクセス必要サブ間隔７０２を含んでいる。図示の実施形態の後部は、ＲＦＲスケジュールサブ間隔７０７の開始からスーパーフレーム間隔の終わりまで延び、ＲＦＲサブ間隔７０３を含んでいる。好適実施形態による動作で、後部のためのスケジュール（例えば、後部中の機能的な間隔の構成、長さなど）は、ＲＦＲスケジューリングサブ間隔７０７で送信される。したがって、ポイント調整は、アクセス必要情報を収集して、同じスーパーフレーム間隔におけるＲＦＲサブ間隔７０３、ＷＴＳサブ間隔７０４、データフレームサブ間隔７０５（図７（Ｃ）に明示せず）および／またはデータフレームサブ間隔７０６（これも図７（Ｃ）に明示せず）などの対応する機能的な間隔を適切に構成することが可能になる。
【００８１】
上記リソース要求スケジューリングサブ間隔はペイロード・データの送信の遅れを減らすために利用できるが、その使用は予定されたＭＡＣの実施形態へ付加的な複雑さを導入するが、それは実現される遅れの減少によってもメリットとならない場合もある。従って、本発明の実施形態は、リソース要求スケジューリングサブ間隔を実施しなくてもよい。
【００８２】
図８に注目すると、図６のネットワークで作動可能な本発明の予定されたＭＡＣアーキテクチャの実施形態が示され、それは１つ以上のパフォーマンスパラメータの最適化のために構成された種々の機能的な間隔のタイミング関係を持つ。具体的には、図８は１つの可能なスーパーフレーム構成を示し、そこではデータフレームサブ間隔がスーパーフレーム間隔の初めに置かれ、アクセスの必要、リソース要求スケジューリング、リソース要求および送信時期サブ間隔がスーパーフレーム間隔の終わりの方に置かれて、そこに最新のトラフィック情報を提供する。アップストリームおよびダウンストリーム間隔が、個別または独立した媒体（例えば異なる無線周波数チャンネルあるいは別のワイヤーライン）を使用して送信されるか、同じ媒体を使用して（例えば、時分割二重（ＴＤＤ）を使用して）送信され得ることを理解するべきである。
【００８３】
図８に示された実施形態のスーパーフレーム間隔のダウンストリーム部分は、ビーコンサブ間隔７０１から始まる。共有媒体１００上のユーザー端末１０１〜１０５が好適実施形態のビーコンサブ間隔７０１に含まれた送信ビーコン・メッセージを解読した後、そのようなユーザー端末はそれぞれスーパーフレーム開始時間を知るはずであり、したがって、前のスーパーフレーム間隔における送信時期メッセージから、許可されたデータフレームがあればそれを送るべき時間を計算することができる。そのような各ユーザー端末は、解読された送信ビーコンメッセージのために、ＮＦＡサブ間隔７０２のタイミング、ＲＦＲスケジューリングサブ間隔７０７のタイミング、リソース要求があれば、ＲＦＲサブ間隔７０３でそれを送るタイミング、前のスーパーフレームで送ったデータフレームに対する受信確認があれば、ＡＣＫサブ間隔８０１でそれを受け取るタイミング、そしてこのスーパーフレーム間隔で受信したデータフレームに対する受信確認があれば、ＡＣＫサブ間隔８０２でそれを送るタイミングをも知るはずである。
【００８４】
図８に示された実施形態のスーパーフレーム間隔のダウンストリーム部分を続けると、ＡＣＫサブ間隔８０１が次に示され、それは前のスーパーフレーム間隔でゲートウエイ１１０からユーザー端末１０１〜１０５によって受信されたデータフレームに対するユーザー端末１０１〜１０５から点調整６０１へのデータフレームの確認用の受信確認フレームを提供する。図示のダウンストリーム構成で示される次の機能的な間隔は、ゲートウエイ１１０がユーザー端末１０１〜１０５へデータフレームを送るためのデータフレームサブ間隔７０５である。好適実施形態による動作で、ユーザー端末はそれぞれ、データフレームのヘッダー中の識別を解読し、データフレームがこの局あるいは別の局に宛てられたものかを判断する。
【００８５】
図８に示されたダウンストリーム構成で、ＲＦＲスケジュールサブ間隔７０７はデータフレームサブ間隔７０５の次にくる。ＲＦＲスケジューラサブ間隔は、ユーザー端末１０１〜１０５によって、例えばＮＦＡサブ間隔７０２内で提供されるアクセス必要情報に基づくことが望ましい。ポイント調整６０１は、アクセス必要情報を利用して、どの局がＲＦＲサブ間隔７０３でアクセスを必要とするか決定し、誰そしていつアクセスを許可するかについてのスケジュールを構築することが望ましい。図示の実施形態によれば、誰がそしていつ局がアクセスを許可されるかの決定は、残りのスーパーフレーム間隔のタイミング、例えばＷＴＳサブ間隔７０４の開始時間、そして全継続時間を満たす恐らく１つ以上のデータフレームまたは埋めバイトをも決める。
【００８６】
図８に示されるダウンストリーム構成中の次の機能的な間隔は、ＷＴＳサブ間隔７０４である。好適実施形態による動作で、ＷＴＳサブ間隔７０４の送信時期情報は、ユーザー端末１０１〜１０５のうち、共有媒体１００にアクセスする必要があるものによってＲＦＲサブ間隔７０３に提供されるリソース要求情報に基づいて、点調整６０１によって完成される。実施形態の各送信時期メッセージは、媒体１００上で次のスーパーフレーム間隔にアップストリームのデータフレームを挿入するための局識別子および開始時間を含む。
【００８７】
本発明の実施形態は、異なる局からの隣接したアップストリームのデータフレームがゲートウェイ１１０でオーバーラップしないことを確実にするよう作動する。従って、発明の実施形態は、そのようなオーバーラップを回避するためにフレーム間間隔（例えばサブ間隔（それらは縮尺どおりに示されていない）の間のギャップ）を実施する。しかし、フレーム間スペース継続時間は、１つのスーパーフレームにわたって何度も生じるから、スループット効率に大きく影響する。従って、以下でさらに詳細に説明するように、発明の実施形態はこの間隔を最小化するよう作動する。
【００８８】
図８のスーパーフレーム間隔のアップストリーム部分はデータフレームサブ間隔７０６で始まり、それは、前のスーパーフレーム間隔からの送信時期メッセージによって予定されたユーザー端末１０１〜１０５からのデータフレームを含んでいる。図示の実施形態のアップストリームにおけるデータフレームサブ間隔７０６の次のＮＦＡサブ間隔７０２は、ユーザー端末１０１〜１０５がそれぞれリソースを必要とするかを示すことを可能にする。好適実施形態によれば、すべての局はＮＦＡサブ間隔７０２にスロットを持っている。ＮＦＡサブ間隔７０２内に提供される各局からのアクセス必要メッセージは、ＮＦＡサブ間隔７０２が共有媒体１００のスループットをあまり影響しないように、非常に短いこと（例えば２進の「ＹＥＳ」または「ＮＯ」）が望ましい。本発明の実施形態によるＮＦＡサブ間隔７０２の使用が、共有媒体１００の競合をなくすことを理解すべきである。
【００８９】
図８に示された実施形態のスーパーフレーム間隔のアップストリーム部分を続けると、ＲＦＲサブ間隔７０３が次に示される。上記のように、ユーザー端末１０１〜１０５のうち、共有媒体１００へのアクセスを必要とする（例えばＮＦＡサブ間隔７０２に示される）ので、アクセスが認められるもの（例えばＲＦＲスケジュールサブ間隔７０７に示されるもの）は、ＲＦＲスケジューリングサブ間隔７０７のメッセージによって提供される情報に従ってリソース要求メッセージ（例えば、局ｎおよびデータフレーム長さｋなどのリソース要件情報を含む）を送る。
【００９０】
好適実施形態による動作で、データフレームサブ間隔７０６および／またはデータフレームサブ間隔７０５のデータフレームを送る順序は、ＮＦＡサブ間隔７０２の局順と同じである。ある局がＮＦＡサブ間隔７０２でアクセス必要を送信した後、その局は、ＲＦＲサブ間隔７０３で局のリソース要求メッセージ送るべき時期を示すＲＦＲスケジュールサブ間隔７０７によって提供されるスケジューリング情報を待つ。ある局がＲＦＲサブ間隔７０３でリソース要求を送信した後、その局は、ＷＴＳサブ間隔７０４によって提供されるスケジューリング情報を待つ。その情報は、後の（例えば、次の）スーパーフレーム間隔のデータフレームをいつ送るべきかに関して指示を与える。局は、同じスーパーフレーム間隔において受信したダウンストリームのデータフレームについてＡＣＫサブ間隔８０２で受信確認のメッセージを送ることが望ましい。ＡＣＫサブ間隔８０２での受信確認メッセージの順序はデータフレームが送られたのと同じ順序であることが望ましい。
【００９１】
上記説明から、実施形態の予定されたＭＡＣアーキテクチャが平等アクセス・スキームを容易にすることが理解されよう。しかし、ネットワーク管理者が各局のアクセス権をカスタマイズすることを可能にしてもよい。例えば、アクセスの頻度（例えば、すべての、あるいはより少ないスーパーフレーム）を指定しもよく、ネットワーク管理者によって指定されたアクセス権に従ってアクセス必要サブ間隔で提供される特定の局に関連したアクセス・スロットの必要頻度を調節する点調整を通じてそれを制御してもよい。さらにあるいは代替として、複数フレームアクセスを許可または不許可とするか、あるいは提供されるフレーム予約のレベルに関して変更してもよい。アクセス権のそのような制御は、共有媒体上の特定の局に関してサービス品質を指定することを容易にする。
【００９２】
以上、実施形態による種々の機能的な間隔と、それらのタイミングおよび構成を記載したが、発明の実施形態によるそのような機能的な間隔内でデータを運ぶためのフレームの構造は以下の通りである。発明の実施形態によれば、スーパーフレーム間隔およびスーパーフレーム間隔内の種々の機能的な間隔が可変長であることに加えて、発明の実施形態によれば、機能的な間隔内のフレームは可変長であってもよい。例えば、データフレーム長さは、トラフィック負荷、共有媒体にアクセスする局の数などに基づいて変更してもよい。発明の実施形態は、受信品質（例えば受信エラー率）に基づいてデータフレーム長さを調節するよう作動し、例えば、受信品質が下がるとデータフレーム長さを短くし、受信品質が改善するとデータフレーム長さを増し、それによって、受信データが回復不能の場合、再送されなければならない個別データフレームのサイズを小さくする。
【００９３】
実施形態によって利用される発信および宛先ポートの識別スキームを理解することは、発明の実施形態によって使用されるフレーム構成の理解に役立つ。共有媒体に接続したいかなる局または他のノードも、送るか受けるかによって、発信側または宛先側と見なすことができる。共有媒体との物理的接続またはインターフェースは、物理的接続またはインターフェースの後ろに、異なる機能用の多数の論理結合があるかも知れないが、それと関連した一意の名を持つことが望ましい。各機能は共有媒体との接続を介してデータフレームを送信および／または受信することができる。そのような各機能は、その関連する物理的接続またはインターフェースの発信元／宛先ポート番号によって共有媒体上で識別され、そのポート番号は特定の共有媒体から形成されたネットワーク内で一意である。言いかえれば、特定の物理的接続またはインターフェースに関連したヘッダーにポート番号を持つデータフレームは、その物理的接続あるいはインターフェースを使用して、媒体への直接アクセスを機能に与える。これは低価格の多機能局にとって非常に魅力的な特徴である。実施形態によれば、ポート番号に関連した個々の論理ポートを決定する論理ポート番号がデータグラムにある。実施形態は、ポート番号に関連した前述の論理ポートを使用することなどによって、ポート番号を最少限に維持することが望ましい。各ポート番号が媒体へのアクセスを求める権利を持ち（例えばＮＦＡ）、したがってポート番号を最少に維持することで、インタビューおよびスケジューリングの複雑さを減らすことを助けるからである。局が全データフレーム長さのアクセス必要要求を送る場合、その要求は多数の論理ポートデータグラムまたは多数のデータフレームに関してあることが望ましい。１つのデータフレーム中の多数のデータグラムは、データグラムがすべて同じ発信元からの同じ宛先へ行くことを意味する。
【００９４】
実施形態の送信ビーコン・フレーム構成が図９（Ａ）に示される。図示の送信ビーコン・フレーム構成は、１つのデータとして誤解されないように好ましくは選択される一意のプリアンブル（前置語）で始まる。送信ビーコン・フレーム構成の次の部分は、スーパーフレーム間隔内の種々の機能的な間隔用の開始時間を設定するメッセージからなる。局が２つの隣接した開始時間の相違から機能的間隔長さを計算できることを理解すべきである。さらに、実施形態の局は標準メッセージ継続時間が判り、これは機能的な間隔に含められるメッセージの数から機能的間隔長さの計算を容易にする。
【００９５】
実施形態のデータフレーム構成が図９（Ｂ）に示される。図示のデータフレーム構成は、各局の多数の同時の接続を支援するように設計されている。各局での異なる接続（例えば局で動作可能な異なる機能の接続）は、個々の一意の（例えば、論理的）ポート番号によって識別される。発明の実施形態によれば、そのような論理ポート番号は物理的なポート番号のサブレイヤでもよい。言いかえれば、各受信者は２層区別を実施し、第１ソート層はポート番号で、第２層は論理ポート番号であり得る。根底にあるスキームにかかわらず、各接続は発信元ポート番号および宛先ポート番号によって識別されることが望ましく、宛先は、データフレームがトランシット位置の言及なしで終了する箇所を意味する。従って、図示の実施形態のデータフレーム・ヘッダーは、接続識別用の発信元ポート番号および宛先ポート番号を含んでいる。
【００９６】
好適実施形態による動作で、局はそれぞれ２つの接続マッピングテーブルを含み、一方のテーブルはそれ自身の局ＩＤ、ポート番号対局上で作動する関数を含み、他方のテーブルは、局ＩＤ、支援する機能などの宛先情報を備える。接続をセット・アップするために、接続を始める局は宛先局のポート番号を最初は知らないかもしれないから、ヘッダーは宛先ポート番号の代わりに、宛先局ＩＤおよび機能を含むことが望ましい。接続が設定されると、発信局はデータフレーム中の宛先局ＩＤを宛先ポート番号に取り替えることが望ましい。
【００９７】
図９（Ｂ）に示されたデータフレーム・ヘッダーは、データフレームが乱れて着信するか、あるいは欠落フレームのための再送信に備えて、処理シーケンスを追跡するよう構成される。具体的には、図９（Ｂ）のデータフレーム構成のヘッダーは、処理シーケンス・トラッキング用のシーケンス番号を含んでいる。
【００９８】
図示の実施形態のデータフレーム構成は、ヘッダーを始め、データグラムが後続するが、データグラムはペイロード・データからなることが望ましい。データグラムは一般に６４バイトから５０００バイトまで長さが変化し得るが、発明の実施形態によれば大体約１０００バイトである。図示の実施形態のデータフレーム構成は、伝送エラーを検出する、および／または再送信なしでデータの回復を可能にするために、円形の冗長符号チェックサムとしてここに示されたエラー検出および／または補正をさらに備える。
【００９９】
実施形態の受信確認フレーム構成が図９（Ｃ）に示される。図示の受信確認フレーム構成は、データフレームが正確にあるいは不正確に着信したこと述べる受信確認メッセージを提供する。図示の受信確認フレーム構成は、発信元ポート番号およびシーケンスとそれに続く受信データフレームの状態からなる。好適実施形態は非リアル・タイム・データフレームへのみ、そのような受信確認メッセージを適用する。リアル・タイム・データフレーム（例えばボイス・オーバ・インターネット・プロトコル（ＶｏＩＰ）データ・ストリーム）は、失われたか損傷したデータフレームの再送信から通常は利益を得ないからである。
【０１００】
実施形態のアクセス必要フレーム構成が図９（Ｄ）に示される。上記のように、各局はアクセス必要サブ間隔にそれ自身のスロットを持っていることが望ましい。アクセス必要サブ間隔内のシーケンス割り当ては、初期セットアップ時に行われることが望ましい。スーパーフレーム間隔の初めの送信ビーコンから、各局のアクセス必要スロット位置は、各受信確認の固定継続時間に基づいて、ＮＦＡサブ間隔の開始時間から計算することができる。図示の実施形態のアクセス必要フレーム構成は「ＹＥＳ」、「不使用」または「無応答」用の発信元ポート番号である。例えばある局は、スロット時間であることを知ると、アクティブであることを意味する「ＹＥＳ」で、オンだがアクティブ・モードでないことを意味する「不使用」で、あるいは局がオフ、休止中または不在であるから応答しないことを意味する「無応答」として応答することができる。
【０１０１】
発明の実施形態は、点調整へのプラグ・アンド・プレイのプラグ宣言を使用するなど、新しい局がネットワークにアクセスすることを容易にするために、アクセス必要サブ間隔中のさもなければ割り当てられないスロットを提供する。従って、局はネットワーク上での初期化用に発信元ポート番号を備えることが望ましい。局は、さらにネットワーク上での初期化に使用するために、点調整を運営するゲートウェイのそれのような宛先ポート番号を備えていてもよい。さらにあるいは代替として、点調整に関連した宛先ポート番号は、ネットワーク上での初期化で使用するために、送信ビーコン内などで送信されてもよい。
【０１０２】
実施形態のリソース要求スケジュール・フレーム構成の要請が図９（Ｅ）に示される。好適実施形態による動作で、点調整のリソース要求スケジューリングアルゴリズムは、アクセス必要サブ間隔中の「ＹＥＳ」回答のすべての発信元ポート番号を集めるが、不使用とのメッセージおよび無応答は破棄することが望ましい。リソース要求スケジューリングアルゴリズムは、リソース要求サブ間隔および／またはデータフレームサブ間隔でのタイムスロットが局に割り当てられるシーケンスでリソースが与えられることになる発信元ポート番号を、リソース要求スケジューリングサブ間隔で再送することが望ましい。従って、図示の実施形態のリソース要求スケジュール・フレームは複数の発信元ポート番号メッセージを含んでいる。さらに、図示の実施形態のリソース要求スケジュール・フレームは、上記のようなスーパーフレーム間隔の第２部分の構成を定めるために、リソース要求サブ間隔の開始、送信時期サブ間隔の開始および次のスーパーフレーム間隔の開始に関する情報をさらに含む。
【０１０３】
実施形態のリソース要求フレーム構成が図９（Ｆ）に示される。リソース要求スケジュールサブ間隔にリストされた局は、リソース要求フレーム構成で示された情報を、リソース要求サブ間隔の適切なタイムスロットで送ることが望ましい。図示の実施形態のリソース要求フレーム構成に含まれる情報は、発信元ポート番号、接続およびサービス要件のタイプ、継続時間および頻度を含んでいる。接続の種類は、単一フレーム処理または、複数フレーム処理（例えば将来のある期間のため、ある確認された数のデータフレームのため、所定のデータ量のため、局がリンクを終了する要請を与えるまで、などの予備データフレーム）を示すような情報を含んでいてもよい。複数フレーム予約の目的は、永続的なリンクが望まれる場合に、アクセスの必要およびリソース要求を連続的に行うプロセスを回避することである（例えばリアル・タイム通信のための接続に基づくリンクに対応するために）。リソース要求フレーム構成で指定されるサービスは、リアル・タイムあるいは非リアル・タイムなどの情報であってもよい。リソース要求フレーム構成で指定される継続時間は、この局による使用のために用意しておくべきデータフレームサブ間隔の量および／またはサブ間隔から要求されるデータの期間の数などの情報であってもよい。継続時間がデータフレームごとに大きく変わる場合、複数フレーム処理はあまり有用ではないかもしれないことを理解すべきである。しかし、音声信号を送信する場合のように、継続時間が実質的に一定の場合、そのような複数フレーム処理は特に有用かもしれない。リソース要求フレーム構成で指定される頻度は、例えば各スーパーフレーム間隔、１つおきのスーパーフレーム間隔などの、予約データフレームの頻度などの情報であってもよい。
【０１０４】
実施形態の送信時期フレーム構成が図９（Ｇ）に示される。好適実施形態の送信時期フレームは、リソースを要求し、共有媒体へのアクセスが認められた局に、自己のデータを送るべき時期を知らせる指示からなる。従って、図示の実施形態の送信時期フレーム構成はポート番号とデータ送信の開始時間からなる。
【０１０５】
発明の実施形態のスーパーフレームと、スーパーフレームからなる種々の機能的な間隔内のフレームの構成を説明したが、発明の実施形態によって実施されるフレーム交換プロトコルは以下の通りである。接続のセット・アップ、データフレームの交換、新しい局の登録など、特定の処理を行なうために種々のフレーム交換プロトコルが実施され得ることを理解すべきである。典型的な処理を可能にするフレーム交換プロトコルの例を説明する。しかし、当業者なら理解されるように、本発明のフレームおよびフレーム構成は、異なるフレーム・プロトコルに関して、および／または記載されたものに加えて、あるいは代わりとして、処理を可能にするために容易に使用することができる。
【０１０６】
ポイント間の任意の通信のため、データ転送の前にハンドシェイクを行なうことが通常望ましい。例えば、宛先局の電源が入っていないか。あるいは、それに接続することができる局に関して選択的であることを希望するかもしれない。ハンドシェーキングは、発信局を識別する、発信局から宛先局へメッセージでよく、宛先局が接続を受け入れる場合、接続が受け入れられたことを示すある形式の情報で宛先局が応答する。発明の実施形態による動作で、宛先局へ送られる最初のメッセージは発信局のポート番号および宛先ＩＤを含み、宛先局による肯定の応答は宛先ポート番号を含む。宛先局からの宛先ポート番号を受領することは、接続が宛先局によって受け入れられたことを発信局に示し得る。従って、初期接続要請ハンドシェイク処理において宛先ＩＤが使用されたが、発信局は以後のデータフレーム送信に宛先ポート番号を使用してもよい。
【０１０７】
図１０（Ａ）〜図１０（Ｃ）および図１１（Ａ）〜図１１（Ｃ）は種々の処理を可能にするフレーム交換プロトコルを示す。これらの図に示す実施形態はすべてのトラフィックがゲートウェイまたは他の集中ノード（例えばアクセス・ポイント、ブリッジなど）を通るインフラストラクチャー構成を提供しているが、本発明の概念は、フレームが局から局へ直接送信される分散型の構成に適用可能であることを理解すべきである。
【０１０８】
図１０（Ａ）に注目すると、データフレームを送信するために共有媒体にアクセスするためのフレーム交換プロトコルが示される。図１０（Ａ）のフレーム交換プロトコルは、上記動作に従った、アクセス必要、アクセス・スケジュール要求、アクセス要求、送信時期およびデータフレームの情報の交換からなる。図１０（Ａ）に示されたフレーム交換プロトコルで、プロセスにおいて動作可能な予定されたＭＡＣアーキテクチャは、媒体が過負荷状態でなければ、データフレームが次のスーパーフレーム間隔において送られることを保証する。発明の実施形態によれば、媒体へのアクセスが個々のそのようなネットワーク構成中の調整ポイントによって制御されるから、図１０（Ａ）のフレーム交換プロトコルはインフラストラクチャーおよび分散ネットワーク構成の両方に適用されることを理解すべきである。
【０１０９】
データフレームの送信は、宛先局がデータフレームを受け取る準備ができていなければ通常有用ではない。図１０（Ｂ）は、データフレームを受け取るための宛先局との接続の設定のためのフレーム交換プロトコルを示し、従って、そこに示されたデータフレームは上記のハンドシェーキング情報を備える。図１０（Ｂ）に示された局Ａからのデータフレームは、図１０（Ａ）に示されたデータフレームに相当するものでもよく、したがって、このデータフレームの送信用に共有媒体にアクセスするために図１０（Ａ）のフレーム交換プロトコルを使用してもよい。図１０（Ｂ）に示すように、データフレームは局Ａからゲートウェイに送信され、次に局Ｂへ転送される（この図示の実施形態で、局Ａと局Ｂはイントラネットワーク接続を設定していると仮定する）。上記実施形態のように、局Ｂは、受信確認フレームとデータフレーム（局Ｂの接続用ポート番号を含むことが望ましい）とで応答し、それがゲートウェイを通して局Ａへ送信される。図示する実施形態で、局Ａは受信確認フレームで応答し、これもゲートウェイを通して送信される。
【０１１０】
外部ネットワーク（例えば、図７のゲートウェイ１１０の左側に配置されたネットワーク）の局との通信は、本発明の実施形態の予定されたＭＡＣのスーパーフレーム間隔のデータフレーム内に外部ネットワーク・プロトコル・フレーム（例えばヘッダー、データフレームなど）をカプセル化することにより遂行され得る。すなわち、外部ネットワーク・プロトコル・フレームは、スーパーフレーム間隔のデータフレームサブ間隔内のペイロードからなるものでもよい。好適実施形態による動作では、外部ネットワーク接続に使用される外部インタフェースは、論理局として扱われる。従って、実施形態によれば、そのような外部ネットワークインタフェースは自己のポート番号を持っている。したがって、ゲートウェイが間で通信を調停する形で、予定されたＭＡＣネットワークおよび外部インタフェース内の局間と、外部ネットワークおよび外部ネットワークインタフェースの局間で接続を設定することができる。例えば、内部ヘッダーは、外部ネットワークインタフェースポート番号に向けられたデータフレーム（予定されたＭＡＣネットワークから外部ネットワークへ行くデータ）から引き取られるか、あるいはデータフレームに（外部ネットワークから予定されたＭＡＣネットワークへ行くデータ）に挿入される。そして、ゲートウェイは、実際の宛先への送達用として再構成されたデータを適切なネットワークへ渡す。
【０１１１】
図１０（Ｃ）は、発明の実施形態の予定されたＭＡＣネットワークの局と外部ネットワークの局との間の通信のためのフレーム交換プロトコルを示す。図示の実施形態によれば、外部ネットワーク・プロトコルのフレームをカプセル化したデータフレームは、局Ａからゲートウェイに送信され、ゲートウェイはデータフレームから予定されたＭＡＣヘッダ情報を取り出し、外部ネットワーク・プロトコルの残りのデータを外部ネットワーク上に置く。データフレームは、外部ネットワーク・プロトコルに従って外部ネットワークの適切な局へ送られる。外部ネットワークの局は、受信確認フレームとデータフレーム（それぞれ外部ネットワーク・プロトコルに従って）で応答し、それがゲートウェイの外部インターフェースへ送信される。ゲートウェイは、予定されたＭＡＣネットワークに適合したヘッダーとともにこれらのフレームをカプセル化して、局Ａへそれらを転送する。図示の実施形態で、局Ａは受信確認フレームで応答し、これも上記のようにゲートウェイを通して送信される。
【０１１２】
上記フレーム交換プロトコルを用いるなどして一旦接続が設定されれば、データ通信を行なうことができる。図１１（Ａ）〜図１１（Ｃ）は、発明の実施形態によるデータ通信のためのデータフレーム交換を示す。具体的には、図１０（Ａ）は、図１０（Ｂ）のフレーム交換プロトコルに従って設定された接続を使用するデータ通信用として、局Ａからゲートウェイを通って局Ｂへのデータフレームの送信を示す。図１０（Ｂ）は、図１０（Ｃ）のフレーム交換プロトコルに従って設定された接続を使用するデータ通信用として、局Ａからゲートウェイを通ってインターネット上の局へのデータフレームの送信を示す。図１０（Ｃ）は、データ通信用としてインターネット上の局からゲートウェイを通って局Ａへのデータフレームの送信を示す。
【０１１３】
新しい局が共有媒体に接続される場合、発明の実施形態によるアクセス必要サブ間隔にその特定局のためのアクセス・スロットの必要はない。ポイント調整には様々な方法で新しい局について知らせることができる。新しい局は、ネットワーク管理者によって割り当てられるか、あるいは一意のＭＡＣ番号として提供されるような、ポート番号の一意のセットを持つことが望ましい。一意のポート番号があると、新しい局はアクセス必要サブ間隔に関連タイムスロットを加えるために点調整が識別することができる。ネットワーク管理者は、ポート番号の入力などによって局を点調整に登録するか、あるいはプラグ・アンド・プレイ・プロトコルの使用などを通じて局が自動的に認識されてもよい。一旦点調整が新しい局を認識すれば、送信ビーコンはこの新しい局のポート番号を、アクセス必要サブ間隔のアクセス必要タイム・スロットとともに送信することが望ましい。新しい局は「イエス」のメッセージ応答してもよく、希望なら新しい局は登録手続全体を完了するよう点調整と通信することができる。一旦新しい局がアクセス必要サブ間隔にアクセスすることができれば、新しい局は共有のＭＡＣネットワーク上の他の局に関して上記ように共有媒体へのアクセスを求め、受けることができる。
【０１１４】
多くの非アクティブ局がある場合、使用されていないアクセス必要サブ間隔のアクセス必要スロットの大きなスペースが割り付けられ得る。従って、発明の実施形態は、オフ・ラインにするとの局からの通知を受けるか、あるいは関連するアクセス必要スロットに関して所定の不使用期間の後に、そのような局をアクセス必要スロット割付けから退かせるよう作動する。本発明の実施形態は、以前に非アクティブであった局にアクセス必要スロットを再び提供するために再活性化スキームを実行する。
【０１１５】
非アクティブ局は少なくとも２つのクラスに分類することができる。関連するアクセス必要スロットに信号のない局は、おそらく電源オフまたは休眠モードにある。一旦それらがオン・ラインで戻っても、これらの局は高速アクセスを要求しないかもしれない。ある期間の後の関連アクセス必要スロット中の「ＮＯ」で応答した局はおそらくアイドルモードにある。これらの局は高速アクセス能力を要求するかもしれない。発明の実施形態の再活性化スキームは、アイドルまたは非アクティブ局のサブセットにアクセス必要サブ間隔に少数のスロットを割り付け、それによって、周期的にそのような局にアクセスを提供する。アイドル局に関してより速いアクセスを提供するために、実施形態の再活性化スキームは、それらの局を完全に非アクティブ局より頻繁にアクセス必要サブ間隔時間スロットに含めるよう作動してもよい。
【０１１６】
ショートメッセージサービスに対応することは、オーバーヘッドが非常に高く、ショートメッセージサービスの対応を非効率にするから、通常、既存の有線または無線ＬＡＮでは問題である。ショートメッセージサービスに関して実時間性がある場合、非能率はさらに悪化する。しかし、本発明の実施形態の予定されたＭＡＣアーキテクチャは、短いオーバーヘッド（ヘッダーおよびフレーム間スペース）と複数フレーム予約スキームのために、イントラ・ネットワーク通信用のそのようなサービスに容易に対応できる。
【０１１７】
本発明の実施形態の予定されたＭＡＣアーキテクチャは、イーサネットＭＡＣプロトコル、ＩＥＥＥ  ８０２．３およびＷｉＦｉ  ＭＡＣプロトコル、ＩＥＥＥ  ８０２．１１、などの既存のＭＡＣアーキテクチャの直接の代替として使用し得る。しかし、発明の実施形態の予定されたＭＡＣアーキテクチャは、イーサネットとＷｉＦｉの物理インタフェースがそのままであるように、フィジカル層からのＭＡＣ層を分断する。従って、ルータ、スイッチ、ゲートウェイ、ブリッジ、ユーザー端末などのインフラストラクチャーは本発明の実施形態の予定されたＭＡＣを実行するのに容易に適合できる。
【０１１８】
図１２に注目すると、本発明の実施形態の予定されたＭＡＣアーキテクチャを実施するイーサネットまたはＷｉＦｉ局の適応例が示される。図１２に示す実施形態で、ＭＡＣ機能が、予定されたＭＡＣ点調整１２０１および予定されたＭＡＣアクセス１２０２として示された本発明の実施形態の予定されたＭＡＣアルゴリズムと取り替えられたという点を除いて、局構成はイーサネットとＷｉＦｉ局のそれと実質的に同じである。図１３は別実施形態を示し、そこでは予定されたＭＡＣアーキテクチャを標準ネットワーク装置に透明にするために、ゲートウェイ・アダプター１３０１および局アダプター１３０２として示されたプロトコルアダプタが媒体のまわりに構築される。
【０１１９】
図１４は、図１２および１３の予定されたＭＡＣおよび点調整１２０１の提供に使用されものに相当する、予定されたＭＡＣおよび点調整を提供する回路の実施形態に関する詳細を提供する予定されたＭＡＣ機能ブロック図を示す。図１４に示された機能ブロックは、本書に記載される動作を提供するためにソフトウエア、ファームウェアおよび／または周知の電子回路（例えばコントローラ、マルチプレクサ、デマルチプレクサ、メモリ、バッファなど）で実施され得る。さらにあるいは代替として、図１４に示された機能ブロックは、所有権付きの回路（例えば特定用途向け集積回路（ＡＳＩＣ）、プログラム可能なゲート・アレイ（ＰＧＡ）など）で実施されてもよい。上記のように機能ブロックのうちのいくつかあるいはすべては集積回路で実施されなくてもよいが、図１４に示された機能ブロックの組合せは、便宜上、ＭＡＣチップ１４００と呼ぶ。
【０１２０】
図示の実施形態のＭＡＣチップ１４００の動作で、外部データ（例えば外部ネットワークの局に関連したデータ）が、ＭＡＣチップ１４００に入るか出て行くとき、付加／除去ヘッダブロック１４０１によって内部ヘッダが除去されるか、あるいは挿入される。ヘッダの除去は、発明の実施形態によれば単純である。しかし、ヘッダの挿入は、どの内部ヘッダを使用すべきか知らなければならないから、より困難である。この問題は、実施形態によれば、イーサネット・ネットワークへのＴＣＰ／ＩＰネットワークなどの既存のネットワーク転移点を使用して解決される。
【０１２１】
ゲートウエイまたはスケジューリング・コントロール・センターにおける使用が意図された図示の実施形態のＭＡＣチップ１４００は、データと制御フレームがそれぞれ組み合わせるか分離するＭＵＸ／ＤＥＭＵＸ１４０２として示されたマルチプレクサとデマルチプレクサの機能を含む。図示の実施形態のｍｕｘ／ｄｅｍｕｘ１４０２の媒体側は、ＭＡＣチップ１４００が予定されたＭＡＣアーキテクチャを提供する共有媒体上に信号を送ったり、そこから信号を取り出したりする媒体インターフェース１４０３としてここに示された媒体インターフェース・モジュールにつながれる。実施形態の制御機能メッセージは、データフレームと同様に、同じスーパーフレーム間隔において制御フレームに入れて運ばれ、それらは同じフォーマットであることが望ましい。しかし、制御機能メッセージは、それと関連する接続がゲートウエイあるいは点調整を運用する多の局で終端する（例えば、制御機能メッセージはゲートウエイの一意のポート番号を持つ）点でデータフレームと異なることが望ましい。
【０１２２】
図示の実施形態のｍｕｘ／ｄｅｍｕｘ１４０２によって媒体ビット・ストリームから逆多重化された制御機能メッセージは、ｍｕｘ／ｄｅｍｕｘ１４０５として示されたさらなるマルチプレクサおよびデマルチプレクサ機能に提供される。ｍｕｘ／ｄｅｍｕｘ１４０５は、図示の実施形態のＭＡＣフレーム管理１４０６によって提供されるＭＡＣスーパーフレーム管理による処理用に、種々の制御機能メッセージを多重化し逆多重化する。図示の実施形態のＭＡＣフレーム管理１４０６は、ＭＡＣプロセッサ１４０７としてここに示されたＭＡＣコントローラの管理の下で作動する。ＭＡＣプロセッサ１４０７は、（例えば、タイミング・ジェネレータ１４０８を使用して）スケジューリング、メッセージ・フォーマットおよびタイミング間隔生成などの個々のスーパーフレームの決まったタスクを調整する。実施形態のＭＡＣプロセッサ１４０７は、さらに局の登録／登録抹消、メンテナンス、故障モニタリングなどの不定期のタスクを調整する。
【０１２３】
実施形態のドロップ・アンド・インサート１４０４は種々の場合に使用される中継機能を提供する。例えば、データフレームがすべてゲートウエイを介して宛先へ送信されるインフラストラクチャー構成のゲートウエイでドロップ・アンド・インサート１４０４の中継機能が使用され、そこではドロップ・アンド・インサート１４０４がすべてのイントラ・ネットワークトラフィックのために実施される。別の用途で、局Ａの送信が局Ｂに到達できないか、その逆であるが、局Ｃが局ＡおよびＢの両方に達することができる場合に、ドロップ・アンド・インサート１４０４は局ＡおよびＢ間の通信の中継機能に使用される。実施形態による動作で、局Ｃは局ＡおよびＢの両方から始まり、局Ｃはドロップ・アンド・インサート１４０４を使用して、局ＡおよびＢのうちの適切な方へデータフレームを再送する。
【０１２４】
図１５は、予定されたＭＡＣアクセスを提供する回路の実施形態に関する詳細を提供する局で使用される予定されたＭＡＣアクセス関数ブロック図を示すものであり、図１２および１３の予定されたＭＡＣアクセス１２０２の提供に使用されものに相当する。図１４の関数ブロックと同様に、図１５に示す関数ブロックは、ソフトウエア、ファームウェアおよび／または周知の電子回路（例えばコントローラ、マルチプレクサ、デマルチプレクサ、メモリ、バッファなど）、および／または所有権付きの回路（例えば特定用途向け集積回路（ＡＳＩＣ）、プログラム可能なゲート・アレイ（ＰＧＡ）など）で実行することができる。上記のように機能ブロックのうちのいくつかあるいはすべては集積回路で実施されなくてもよいが、図１５に示された機能ブロックの組合せは、便宜上、ＭＡＣチップ１５００と呼ぶ。
【０１２５】
図１２および１３の予定されたＭＡＣアクセス１２０２を提供するのに使用されたものに相当し、実施形態の予定されたＭＡＣアクセスを提供する回路の予定されたＭＡＣ機能ブロックは、ＭＡＣチップ１４００に関して示されたものと実質的に同じでよく、好ましくは機能が縮小される。例えば、ヘッダー挿入は、実施形態の予定されたＭＡＣアクセス１２０２中の小量のヘッダーを管理し、したがって付加／除去ヘッダー１５０１は、付加／除去ヒーター１４０１に関して上記したような機能性を提供してもよいが、この機能性はそれに応じて計られ得る。同様に、図示の実施形態のｍｕｘ／ｄｅｍｕｘ１５０２に提供されるマルチプレクサおよびデマルチプレクサの機能性は、ｍｕｘ／ｄｅｍｕｘ１４０２と同様でよいが、この機能性は予定されたＭＡＣアクセス１５００の動作に関連した、制御機能メッセージおよびデータフレームの減量に対応する計られることが望ましい。図示の実施形態のｍｕｘ／ｄｅｍｕｘ１５０２の媒体側は、ＭＡＣチップ１５００が予定されたＭＡＣアーキテクチャを提供する共有媒体上に信号を送ったり、そこから信号を取り出す媒体インターフェース１５０３としてここに示された媒体インターフェース・モジュールにつながれる。ドロップ・アンド・インサート１５０４は、ドロップ・アンド・インサート１４０４に関して説明したように作動することが望ましい。
【０１２６】
図示の実施形態のｍｕｘ／ｄｅｍｕｘ１５０２によって媒体ビット・ストリームから逆多重化された制御機能メッセージは、ｍｕｘ／ｄｅｍｕｘ１５０５として示されたさらなるマルチプレクサおよびデマルチプレクサ機能に提供される。ｍｕｘ／ｄｅｍｕｘ１５０５は、図示の実施形態のＭＡＣフレーム管理１５０６によって提供されるＭＡＣスーパーフレーム管理による処理用に、種々の制御機能メッセージを多重化し逆多重化する。図示の実施形態のＭＡＣフレーム管理１５０６は、ＭＡＣプロセッサ１５０７としてここに示されたＭＡＣコントローラの管理の下で作動する。ＭＡＣプロセッサ１５０７は、（例えば、タイミング・ジェネレータ１５０８を使用して）スケジューリング、メッセージ・フォーマットおよびタイミング間隔生成などの個々のスーパーフレームの種々のタスクと、対応する局の登録／登録抹消、メンテナンス、故障モニタリングなどの定期的または不規則に行われるタスクを調整する。
【０１２７】
発明の実施形態によれば、予定されたＭＡＣアクセス機能性を提供するＭＡＣチップ１５００は、パケットを送るためにスケジューリングや時間の経過を追ことを使用する（あるいは含む）必要はない（例えば、タイミング・ジェネレータ１５０８を省略する）。この実施形態の予定されたＭＡＣアーキテクチャは、ゲートウエイまたは他の点調整ホストへ複雑さの多くを移して、局を単純化する。典型的には１つだけのゲートウエイ（あるいは他の点調整ホスト）と他の多くの局が存在するから、そのような実施形態は望ましいかもしれない。
【０１２８】
本発明の実施形態の予定されたＭＡＣの動作によって提供される競合がない媒体アクセス制御の効率を理解することを助けるために、異なるＭＡＣスキームで１つのデータフレームを送るためのオーバーヘッドの比較を以下に示す。
１つのデータフレームを送るための平均ＰＣＦオーバーヘッド：
２ＳＩＦＳ+Ｐｏｌｌ+ＡＣＫ+（(Ｎ−ｎ)(２ＳＩＦＳ+Ｐｏｌｌ+ＡＣＫ)）／ｎ
１つのデータフレームを送るための平均ＤＣＦオーバーヘッド：
ＤＩＦＳ+３ＳＩＦＳ+ＲＴＳ+ＣＴＳ+ＡＣＫ
１つのデータフレームを送るための平均予定されたＭＡＣオーバーヘッド（ＲＦＲスケジューリングサブ間隔なし）：
２ＩＦＳ+ＮＦＡ+ＲＦＲ+ＷＴＳ+ＡＣＫ+((Ｎ−ｎ)(ＩＦＳ+ＮＦＡ))／ｎ  
１つのデータフレームを送るための平均予定されたＭＡＣオーバーヘッド（ＲＦＲスケジューリングサブ間隔あり）：
２ＳＩＦＳ+ＮＦＡ+ＲＦＲスケジュール+ＲＦＲ+ＷＴＳ+ＡＣＫ
+((Ｎ−ｎ)(ＩＦＳ＋ＮＦＡ))／ｎ
式中：
Ｎは局の合計数である；
ｎは送信するべきデータがある局の数である；そして
ＩＦＳはフレーム間スペースである。
送信時期（ＷＴＳ）情報が連続的なブロックであるから、本発明の実施形態の予定されたＭＡＣのダウンストリームがフレーム間間隔（ＩＦＳ）を必要とすることに注意されたい。
【０１２９】
競合がない媒体共有スキームを提供する本発明の実施形態の予定されたＭＡＣに、平均オーバーヘッドが非常に好都合であることは上記から理解されよう。さらに、データフレーム予約、ＩＦＳ最適化、トラフィックフロー管理およびヘッダー単純化に関しての最適化アルコリズムの実施を通じて、本発明の実施形態の予定されたＭＡＣに関しての上記例示する平均オーバーヘッドの利点をさらに高めることができる。
【０１３０】
本発明の予定されたＭＡＣの構成および最適化に使用されるいくつかの根本的考察は、スーパーフレーム間隔および機能的間隔長さ、スーパーフレーム間隔内の機能的間隔の配置、およびスーパーフレーム間隔同士の機能的間隔の関連づけを含む。機能的間隔の長さを含むスーパーフレーム間隔のすべての機能的間隔は、スループット、待ち時間および公平性のためのトラフィックフロー管理を最適化するためにスーパーフレーム間隔ごとに異なることが望ましい。種々の機能的間隔のタイミング関係を構成するのに使用される最適化アルコリズムを案内するためのいくつかの基本的な規則は、次のものを含んでいる：スーパーフレームは、最少の詰めビットでできるだけ短くあるべきである；最大のスーパーフレーム長さはアップストリームのニーズによってセットされるべきだが、最大長に対する制限は動作ニーズによって設定される；そして、最小のスーパーフレーム長さはダウンストリーム・ニーズによって設定されるべきである（例えば、スーパーフレーム長さは、１つの、好ましくは最先のスーパーフレームでアクセス必要要求をすべて完成するよう設定することができる）。最適化された性能のための本発明の予定されたＭＡＣを構成するのに役立つ追加の考察は、新しい局へのプラグ・アンド・プレイ・アクセスを支援し（例えば、新しい局は、アクセス必要サブ間隔にタイムスロットを加えるように、スーパーフレーム構成への加入のために点調整に宣言することができる）、リアル・タイムおよび非リアル・タイムのデータフレームに対応することを含む（例えば、局は、リアル・タイム通信用に接続に基づくタイプのリンクを可能にするために一連のデータフレームを保存してもよく、他のデータはより高い待ち時間に適応し、したがって延期されたスケジューリングを可能にする非リアル・タイムでもよい）。発明の実施形態は、異なるタイプのフィジカル層に関して最適化のための機能的間隔の位置および長さを設定する。
【０１３１】
本発明の実施形態の予定されたＭＡＣアーキテクチャは、ＭＡＣ層がどのように作動すべきかの基礎を備える。好適実施形態は、図１４のＭＡＣプロセッサ１４０７で操作可能な１つ以上の最適化アルコリズムを実施し、それは予定されたＭＡＣプラットフォームの柔軟性を利用してＭＡＣの性能を高めるよう作動する。
【０１３２】
例えば、最適化アルコリズムは、スーパーフレーム間隔長さを変えることにより、最適化されたスループットのために予定されたＭＡＣパフォーマンスパラメータを最適化するよう提供されてもよい。スーパーフレーム間隔長さは、発明の実施形態のリソース要求サブ間隔で識別されたデータフレーム要件に対応することが望ましい。従って、トラフィックが多ければスーパーフレーム間隔長さはより長く、トラフィックが少なければより短い。より短いスーパー・フレーム間隔では、リソース要求サブ間隔の頻度が増加する。しかし、オーバーヘッドは、ソース要求、送信時期および受信確認サブ間隔を短くすることにより減少する。トータルスループットは減少するが、１つの局当たりのスループットは増加し、それによって、局の数と無関係の高スループットを維持する。この最適化アルコリズムは、アクセス公平さ、競合制御、ネットワーク安定性および待ち時間などの他のＭＡＣパフォーマンスパラメータに関してマイナスの影響がないから、中立であると考えられる。
【０１３３】
さらにあるいは代替として、最適化アルコリズムは、アクセス予約アルゴリズムの実施によって、待ち時間などの予定されたＭＡＣパフォーマンスパラメータを最適化するよう提供されてもよい。発明の実施形態によって提供されるアクセス予約は、リソース要求が直ちに多数のデータフレームを、および／または将来のスーパーフレームで一連のデータフレームを要求してもよいことを意味する。そのような多数のデータフレーム予約は、局が希望の帯域幅を予約することを可能にしながら、発明の実施形態のリソース要求サブ間隔のトラフィックを減らす。実施形態のアクセス予約アルゴリズムによって容易にされる将来のスーパーフレームでの一連のリソース予約は、連続的で規則的なトラフィックが必要な場合、リアル・タイム・トラフィックに特に魅力的である。例えば、アクセス予約アルゴリズムを実行する予定されたＭＡＣは、特定の局のために規則的な発生に近いデータフレームを計画し得る。そのようなリソース予約を使用すれば、リソース要求のローディングを減少しながら、待ち時間を最小化できる。
【０１３４】
さらにあるいは代替として、アクセス予約アルゴリズムは、適切な局に関してデータフレーム・スロットを予約することにより、トラフィックの多い局も少ない局もより公平に扱うよう使用できる。さらに、発明の実施形態のアクセス予約アルゴリズムは局の数にかかわらずスループットを維持する。例えば、スーパーフレームについてのスループットは、全データフレームを全オーバーヘッドと全データフレームの合計で割ったものになる。アクセス予約アルゴリズムの動作によって、スーパーフレームがｎ個のデータフレームを持つとすれば、これらｎ個のデータフレームは１個〜ｎ個の局からであり得る。これは、スループット能力が局の数で変化しないことを意味する。このアルコリズムは、アクセス公平さ、競合制御、スループットおよびネットワーク安定性などの他のＭＡＣパフォーマンスパラメータに関してマイナスの影響がないから、中立であると考えられる。
【０１３５】
最適化アルコリズムは、トラフィックフロー制御の実施によって、アクセス公平さなどの予定されたＭＡＣパフォーマンスパラメータを最適化するよう、さらにあるいは代替として提供されてもよい。発明の実施形態のトラフィックフロー制御アルゴリズムはアクセスの公平さを保証するよう作動してもよく、トラフィックが全容量に達すると、そのスループットが維持される。発明の実施形態の予定されたＭＡＣアーキテクチャの動作では、要求されたすべてのリソースは、次のスーパーフレーム間隔で与えられる。トラフィックが増加すると、スーパーフレーム間隔長さが長くなる。長いスーパー・フレーム間隔は、新しい要求の機会を減らす。従って、本発明の実施形態は、最大のスーパー・フレーム間隔長さに、スーパーフレーム長さでのしきい値を設定する。例えば、最大のスーパーフレーム間隔長さのしきい値は、好適実施形態によれば各局の最少アクセス割合に基づいて設定される。実施形態による動作で、トラフィックによりスーパーフレーム間隔長さがしきい値を越えると、トラフィックフロー制御アルゴリズム動作が以下に記載されるような措置を次のスーパーフレームに対して講じられる。従って、本発明の実施形態のトラフィックフロー制御アルゴリズムは、全体的なスループットを低下させずに、新しいアクセスの機会を受け入れ可能なレート以上に維持する。
【０１３６】
図１６に注目すると、発明の実施形態のトラフィックフロー制御アルゴリズムの動作のフロー図が示される。示されたフロー図は、ブロック１６０１で始まり、そこでリソース要求が受信される。好適実施形態による動作では、リソース要求はスーパーフレーム間隔ごとに更新される。従って、図示する実施形態のブロック１６０２では、現在のリソース要求と残りの満たされないリソース要求（ブロック１６０５によって与えられる）から総リソース要求が決定される。つまり、総リソース要求は、現在のスーパーフレーム間隔のリソース要求と前のスーパーフレームから残されたリソース要求との合計である。
【０１３７】
ブロック１６０３では、総データフレーム長さは総リソース要求から計算される。総データフレーム長さがトラフィックフロー制御のしきい値未満である（例えば、各局のアクセス割合が最低未満にならない）場合、総リソース要求は受け入れられ、ブロック１６０６で次のスーパーフレーム間隔での要求を受け入れるよう送信時期情報が決定される。しかし、総データフレーム長さがしきい値より大きい場合、超過データフレーム長さが計算され、次のスーパーフレーム間隔で受け入れられるものを越えるリソース要求についての送信時期情報がブロック１６０５で決定される。残りのリソース要求は次の次のスーパーフレームで受け入れられることが望ましい。送るべきデータフレームの量と、次の次のスーパーフレームに持ち越す量の決定は因子によって行うことができる。過負荷が続く場合、因子は小さく増加するかもしれない。しかし、いかなる優先データフレームも第１リストに載っているべきである。
【０１３８】
最適化アルコリズムは、フレーム間スペース・アルゴリズムの実施によって、スループットなどの予定されたＭＡＣパフォーマンスパラメータを最適化するよう、さらにあるいは代替として提供されてもよい。フレーム間スペース（ＩＦＳ）は、スーパーフレームでも、スーパーフレーム内のフレームでも、連続した２つのフレームを分離する不使用のスペースとして規定される。このスペースは、連続した２つのフレームが検出点（例えばゲートウェイ）でオーバーラップしないことを保証することが望ましい。しかし、フレーム間スペースのサイズは、それがすべてのフレームに通常使用されるから、スループットに大きく影響する。従って、本発明の実施形態のフレーム間スペースアルゴリズムは、ネットワーク環境の変化につれてフレーム間スペースを自動的に最適化するように作動する。
【０１３９】
現在、イーサネットとＷｉＦｉは、アクセス制御にフレーム間スペースを使用する。例えば、局１が媒体にアクセスするために最短のフレーム間スペース（ＳＩＰＳ）間隔の休止期間を待ち、他の局が媒体にアクセスするために最短のフレーム間スペースより長い間隔を待たなければならない場合、局１は他の局の前に媒体にアクセスする特典を持っている。衝突検出システムのバック・オフ条件は、公平さを高めるために、アクセス制御用として最短のフレーム間スペース間隔へ加えられる可変期間を実施してもよい。
【０１４０】
現在のＭＡＣアーキテクチャは媒体における伝播遅延を考慮していない。しかし、実際の動作環境において起こっていることを反映するために伝播遅延を含むことは重要である。図１７に示すように局１および２が媒体上の伝播遅延τで通信伝達していると仮定する。局１が局２へフレームを送ると、局２は時間τ後にフレームを受け取る。応答で、局２は、最短のフレーム間スペースを待った後にフレームを局１へ送るが、それは時間τ後に局１に到着する、等々。しかし、局がそれぞれ異なる時に他の局のネットワーク活動を見るから、フレーム間間隔は媒体に沿った観測点の関数である。次の表はフレーム間間隔対観測点を示す。
【表１】
2009507422.tif 000003
ここで、τXは局Ｘと観測点の間の遅れであり、τはτ1とτ2の合計である。
【０１４１】
多くの局を備えたネットワークでは、フレーム間スペースは計算がもう少し複雑で、特に局に対する観測点の関係（つまり、観測点が局同士の間にあるか、あるいは局の外側か）を知る必要がある。現在のイーサネットおよびＷｉＦｉ  ＭＡＣアーキテクチャでは、最短のフレーム間スペースおよび遅れは時間的に一定である。従って、生のビットレートが増加すると、同じフレーム・サイズはより短くなる。最短のフレーム間スペースとτが生のビットレートに対応しない場合、最短のビットレートおよびτはスループットを下げる重要な因子になり得る。
【０１４２】
発明の実施形態の予定されたＭＡＣアーキテクチャでは、公平性の制御としてフレーム間スペースを使用する必要はない。従って、本発明の実施形態のフレーム間スペース・アルゴリズムは、フレーム間間隔を生のビットレートに対応させる。言いかえれば、フレーム間間隔は、リアル・タイム・スケールの単位（例えばミクロ秒）ではなく、生のビットレートとの関係になり得る。そのような実施形態は、スループット・パーセンテージを生のビットレートと無関係にする。フレームが点調整ホストインタフェース（例えばゲートウェイ入力）でオーバーラップしない限り、そのような実施形態のフレーム間間隔は非常に小さくなり得る。
【０１４３】
最適化されたフレーム間間隔を提供するために、種々の手法が発明の実施形態のフレーム間スペース・アルゴリズムによって実施され得る。希望次第で、本発明の実施形態は１つ以上のそのような技術を単独であるいは組合せで実施可能なことを理解すべきである。
【０１４４】
フレーム間間隔の最適化用に実施される１つの方法は、ネットワークに許可される最大の媒体遅れを決定し、この最大の遅れプラス余裕（例えば１０％）を時間的に定められたフレーム間スペースとして２回使用することからなる。このフレーム間スペース時間から、等価数ビットを計算することができる。このビット数が受け入れ可能な場合（例えばビーコンＮＰＡ、ＲＦＲ、ＷＴＳ、ＡＣＫおよびフレーム間間隔を含むオーバーヘッドが、ビットレートの約２０％以下である場合）、送っている局にかかわらず、すべてのフレームに対して一定のフレーム間スペースを実施することができる。このアルゴリズムは、１０Ｍｂ／ｓ以下の生のビットレートの使用に望ましい可能性が大である。しかし、フレーム間スペースのビット数が受け入れがたい場合は、マージンを減らしたり、可変長フレーム間スペースを使用するなどがある。
【０１４５】
フレーム間最適化のより高度な解決策は伝播遅延を補償することである。従って、本発明の実施形態は、特定の局の送信時期を制御するためのフレーム間スペース・マトリックスを実施し、それによって可変長フレーム間間隔を実施する。
【０１４６】
図１８（Ａ）に注目すると、種々の局とゲートウェイ（本発明の実施形態の予定されたＭＡＣアーキテクチャの点調整を運営する）の位置を持つ論理ネットワークが示される。フレーム間スペース測定アルゴリズムがゲートウェイに位置することが望ましい。アルゴリズムは、連続する一対のアップストリーム・フレームから情報を集めるよう作動することが望ましい。例えば、実施形態のフレーム間スペース測定アルゴリズムは、第１および第２フレームがどの局からのものか、そしてその間のフレーム間スペース間隔に関する情報を収集するよう作動する。この情報を使用して、図１８（Ｂ）に示すように、フレーム間スペース・マトリックスを完成することができる。
【０１４７】
図１８（Ｂ）のマトリックス中の各要素は、フレームを送った局に基づく１つのフレーム間スペースを表わす。遅延が生じない場合、フレーム間スペースをδｃとする。各要素の値は終始一定ではないかもしれない。（例えば、ワイヤー・ライン・システムでの温度または無線システムの多経路によって媒体遅延時間が変動したり、局が異なる位置へ（長期的には）移動するなど）。最小のフレーム間スペースは、それが小さすぎる場合、２つの隣接したフレームをオーバーラップさせる可能性があるから、重要な値である。従って、発明の実施形態は最小のフレーム間スペースの経過を追うよう作動する。図１８（Ｂ）のフレーム間スペース・マトリックスの要素は、最小のフレーム間スペース値である。
【０１４８】
図１９は、発明の実施形態による最小のフレーム間スペースの経過を追うアルゴリズムの動作のフロー図を示す。特定の局ペアに関連したフレーム間スペースが決定されると、それらのフレーム間スペースは、フレーム間スペース・マトリックスに格納されたフレーム間スペースと比較される。フレーム間スペース入力が格納されたフレーム間スペース値未満ならば、格納されたフレーム間スペース値はフレーム間スペース入力値に更新される。しかし、フレーム間スペース入力が格納されたフレーム間スペース値より大きければ、格納されたフレーム間スペース値は前の格納された値より少し高いように増加されることが望ましい。そのような実施形態は、観察されたネットワーク状態に基づいてフレーム間スペース値を下げることを容易にするだけでなく、最小値が高められ場合（例えば、局が再配置され、媒体伝播状態が変化するなど）に適切なフレーム間スペース値を追跡することを容易にする。
【０１４９】
測定された最小のフレーム間スペースが希望のフレーム間スペースより大きければ、対応する局の送信時期を早めることにより実施形態の送信時期サブ間隔の情報が補正されることになる。測定されたフレーム間スペースが希望のフレーム間スペースより小さかった場合、この処置は逆になる。上記フレーム間スペース補正の目的は、測定された最小のフレーム間スペースを希望のフレーム間スペースと等しくすることである。実施形態のフレーム間スペース補正アルゴリズムの動作は、図１９のフロー図のフレーム間補正部分に示される。
【０１５０】
発明の好適実施形態による動作で、ネットワークに加入する新しい局（または新しく展開されたネットワークの局）は、オーバーラップからフレームを保護するのに十分に大きいデフォルト・フレーム間スペース値を使用する。一旦局が媒体にアクセスすれば、発明の実施形態のフレーム間スペース・アルゴリズムは局に関連したフレーム間間隔を測定し、フレーム間スペース値を目標値に下げるように作動する。
【０１５１】
本発明とその利点を詳細に記載したが、付加された請求項で定義された発明の趣旨と範囲から外れずに、種々の変更、置換および改変を行なうことができることは理解されよう。さらに、本件出願の範囲は、明細書に記載されたプロセス、機械、製造、組成、手段、方法およびステップの特定の実施形態に限定されるようには意図されない。当業者なら本発明の開示から容易に理解されるように、本書に記載した対応実施形態と実質的に同じ機能を行う、あるいは実質的に同じ効果を達成する、既存の、あるいは後で開発されるプロセス、機械、製造、組成、手段、方法あるいはステップを、本発明に従って使用することができる。従って、付加されたクレームは、そのようなプロセス、機械、製造、組成、手段、方法あるいはステップをその範囲に含むよう意図される。
【図面の簡単な説明】
【０１５２】
【図１】共有の媒体によって通信を提供するネットワーク構成を示す図
【図２】一度に１つの局をポーリングすることによって媒体アクセス制御を行う従来の点調整機能を示す図
【図３】従来の点調整機能、媒体アクセス制御層のスループットの上限を示す図
【図４】搬送波検知多重アクセス方式衝突回避に送信要求／送信可を備える従来の分散協調機能結合プロセスを示す図
【図５】多局環境における従来の搬送波検知多重アクセス方式衝突回避動作の例を示す図
【図６】本発明の実施形態による共有の媒体を介する通信を提供するネットワーク構成を示す図
【図７】本発明の実施形態の予定された媒体アクセス制御アーキテクチャによって定義されたスーパーフレームの種々の構成を示す図
【図８】本発明の予定された媒体アクセス制御アーキテクチャの実施形態を示す図
【図９】本発明の予定された媒体アクセス制御アーキテクチャのフレーム構造の実施形態を示す図
【図１０】本発明の実施形態による種々の処理を提供するためのフレーム交換プロトコルを示す図
【図１１】発明の実施形態によるデータ通信のためのデータフレーム交換を示す図
【図１２】本発明の実施形態の予定された媒体アクセス制御アーキテクチャを実施するイーサネットまたはＷｉＦｉ局の適応例を示す図
【図１３】本発明の実施形態による予定された媒体アクセス制御アーキテクチャを標準ネットワーク装置に対して透明にするために媒体のまわりに構築されるプロトコルアダプタの例を示す図
【図１４】本発明の実施形態による予定された媒体アクセス制御機能ブロック図
【図１５】本発明の実施形態による予定された媒体アクセス制御アクセス機能ブロック図
【図１６】発明の実施形態のトラフィックフロー制御アルゴリズムの動作のフロー図
【図１７】媒体中のフレーム間スペース対観測点の位置を示す図
【図１８】（Ａ）種々の局およびゲートウェイの位置とともに論理網を示す図、（Ｂ）本発明の実施形態のフレーム間スペース・マトリックス
【図１９】本発明の実施形態による最小のフレーム間スペース値の検出と、フレーム間スペース補正を実施のフロー図
【図１】
2009507422.tif 000004
【図２】
2009507422.tif 000005
【図３】
2009507422.tif 000006
【図４】
2009507422.tif 000007
【図５】
2009507422.tif 000008
【図６】
2009507422.tif 000009
【図７】
2009507422.tif 000010
【図８】
2009507422.tif 000011
【図９】
2009507422.tif 000012
【図１０】
2009507422.tif 000013
【図１１】
2009507422.tif 000014
【図１２】
2009507422.tif 000015
【図１３】
2009507422.tif 000016
【図１４】
2009507422.tif 000017
【図１５】
2009507422.tif 000018
【図１６】
2009507422.tif 000019
【図１７】
2009507422.tif 000020
【図１８】
2009507422.tif 000021
【図１９】
2009507422.tif 000022
【国際調査報告】
2009507422.tif 000023