特許 6087387 無線システムのコーディネータ装置、ソース装置及びリレイ装置の通信方法及びフレーム構造

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6087387

(24)【登録日】2017年2月10日

(45)【発行日】2017年3月1日

(54)【発明の名称】無線システムのコーディネータ装置、ソース装置及びリレイ装置の通信方法及びフレーム構造

(51)【国際特許分類】

   H04W 16/26 20090101AFI20170220BHJP

   H04W 84/20 20090101ALI20170220BHJP

   H04W 72/04 20090101ALI20170220BHJP

【ＦＩ】

   H04W16/26

   H04W84/20

   H04W72/04

【請求項の数】6

【全頁数】25

(21)【出願番号】特願2015-95078(P2015-95078)

(22)【出願日】2015年5月7日

(62)【分割の表示】特願2012-556994(P2012-556994)の分割

【原出願日】2011年3月11日

(65)【公開番号】特開2015-159614(P2015-159614A)

(43)【公開日】2015年9月3日

【審査請求日】2015年6月8日

(31)【優先権主張番号】10-2010-0021942

(32)【優先日】2010年3月11日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】596099882

【氏名又は名称】エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュート

【氏名又は名称原語表記】ＥＬＥＣＴＲＯＮＩＣＳ ＡＮＤ ＴＥＬＥＣＯＭＭＵＮＩＣＡＴＩＯＮＳ ＲＥＳＥＡＲＣＨ ＩＮＳＴＩＴＵＴＥ

(74)【代理人】

【識別番号】100091982

【弁理士】

【氏名又は名称】永井 浩之

(74)【代理人】

【識別番号】100091487

【弁理士】

【氏名又は名称】中村 行孝

(74)【代理人】

【識別番号】100082991

【弁理士】

【氏名又は名称】佐藤 泰和

(74)【代理人】

【識別番号】100105153

【弁理士】

【氏名又は名称】朝倉 悟

(74)【代理人】

【識別番号】100117787

【弁理士】

【氏名又は名称】勝沼 宏仁

(74)【代理人】

【識別番号】100096921

【弁理士】

【氏名又は名称】吉元 弘

(72)【発明者】

【氏名】クウォン、ヒャン、ジン

(72)【発明者】

【氏名】キム、ヨン、スン

(72)【発明者】

【氏名】チャン、カプ、ソク

(72)【発明者】

【氏名】ホン、スン、ユン

(72)【発明者】

【氏名】ジン、スン、グン

(72)【発明者】

【氏名】リー、ウー、ヨン

(72)【発明者】

【氏名】チュン、ヒュン、キュ

【審査官】 松野 吉宏

(56)【参考文献】

【文献】 特開２０００−２４４５２２（ＪＰ，Ａ）

【文献】 国際公開第２００９／０８８９３７（ＷＯ，Ａ１）

【文献】 I. Lakkis, S.Kato, C. Ngo, J. P. K. Gilb，IEEE802.15.3c Beamforming Overview，IEEE 802.11-09/0355r0，米国，IEEE mentor，２００９年 ３月１１日，p.15，ＵＲＬ，https://mentor.ieee.org/802.11/dcn/09/11-09-0355-00-00ad-tg3c-beamforming-overview.pdf

【文献】 Hyoungjin Kwon, Seungeun Hong, Yongsun Kim, Kyeongpyo Kim, Wooyong Lee，Anti-blocking Mechanism by Relay，IEEE 802.15-08-0522-00-003c，米国，IEEE mentor，２００８年 ７月１７日，p.7-16，ＵＲＬ，https://mentor.ieee.org/802.15/dcn/08/15-08-0522-00-003c-anti-blocking-mechanism-for-relay.pdf

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

無線システムのコーディネータ装置の通信方法において、
ソース装置がデスティネーション装置に送信するフレームがリレイ装置を経由して中継されるようにするために、前記ソース装置から前記リレイ装置のためのリソースをリクエストするフレームを受信するステップと、
サービス区間のために拡張されたスケジュール構成要素(Ｅｘｔｅｎｄｅｄ Ｓｃｈｅｄｕｌｅ Ｅｌｅｍｅｎｔ）をリレイ装置に送信するステップと、
前記リレイ装置のためのリソースを割り当てるステップと、
を含み、
前記リレイ装置は、
前記拡張されたスケジュール構成要素に基づいてソース装置から受信したフレームをデスティネーション装置に送信し、
前記拡張されたスケジュール構成要素は、割り当てフィールド（Ａｌｌｏｃａｔｉｏｎ Ｆｉｅｌｄ）を含み、
前記割り当てフィールドは、割り当て制御（Ａｌｌｏｃａｔｉｏｎ ｃｏｎｔｒｏｌ）、ビームフォーミング制御（ＢＦ ｃｏｎｔｒｏｌ）、ソースＡＩＤ（Ｓｏｕｒｃｅ ＡＩＤ）、デスティネーションＡＩＤ（Ｄｅｓｔｉｎａｔｉｏｎ ＡＩＤ）、割り当て開始（Ａｌｌｏｃａｔｉｏｎ ｓｔａｒｔ）、割り当てブロック間隔（Ａｌｌｏｃａｔｉｏｎ Ｂｌｏｃｋ Ｄｕｒａｔｉｏｎ）、ブロック数（Ｎｕｍｂｅｒ ｏｆ Ｂｌｏｃｋｓ）、及び割り当てブロック時間（Ａｌｌｏｃａｔｉｏｎ Ｂｌｏｃｋ Ｐｅｒｉｏｄ）を含むことを特徴とするコーディネータ装置の通信方法。

【請求項2】

リレイ装置の通信方法において、
拡張されたスケジュール構成要素を受信するステップと、
前記拡張されたスケジュール構成要素に含まれたソースＡＩＤとデスティネーションＡＩＤを確認するステップと、
リレイスキームを考慮して、前記ソースＡＩＤに対応するソース装置から受信したフレームをデスティネーションＡＩＤに対応するデスティネーション装置に送信するステップと、
を含み、
前記拡張されたスケジュール構成要素は、割り当てフィールドを含み、
前記割り当てフィールドは、割り当て制御、ビームフォーミング制御、ソースＡＩＤ、デスティネーションＡＩＤ、割り当て開始、割り当てブロック間隔、ブロック数、及び割り当てブロック時間を含むことを特徴とするリレイ装置の通信方法。

【請求項3】

前記拡張されたスケジュール構成要素を受信するステップは、ビーコンフレーム又はアナウンスメントフレームを用いて拡張されたスケジュール構成要素を受信することを特徴とする請求項２に記載のリレイ装置の通信方法。

【請求項4】

前記送信するステップは、フルデュプレックスアンプリファイ・アンド・フォワード（Ｆｕｌｌ Ｄｕｐｌｅｘ Ａｍｐｌｉｆｙ ａｎｄ Ｆｏｒｗａｒｄ； ＦＤ ＡＦ）スキームに基づいて、前記ソースＡＩＤに対応するソース装置から受信したフレームをデスティネーションＡＩＤに対応するデスティネーション装置に送信することを特徴とする請求項２に記載のリレイ装置の通信方法。

【請求項5】

前記送信するステップは、ハーフデュプレックスデコード・アンド・フォワード（Ｈａｌｆ Ｄｕｐｌｅｘ Ｄｅｃｏｄｅ ａｎｄ Ｆｏｒｗａｒｄ； ＨＤ ＤＦ）スキームに基づいて、前記ソースＡＩＤに対応するソース装置から受信したフレームをデスティネーションＡＩＤに対応するデスティネーション装置に送信することを特徴とする請求項２に記載のリレイ装置の通信方法。

【請求項6】

前記送信するステップは、前記ソース装置がリレイ装置のための無線システムのコーディネータ装置にリクエストしたリソースを用いて、前記ソースＡＩＤに対応するソース装置から受信したフレームをデスティネーションＡＩＤに対応するデスティネーション装置に送信することを特徴とする請求項２に記載のリレイ装置の通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

下の実施形態はＷｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＬＡＮ）あるいはＷｉｒｅｌｅｓｓ Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ（ＷＰＡＮ）環境のように予約基盤チャネルアクセスをサポートする無線システムのコーディネータ装置及びリレイ装置の通信方法及びネットワーク内リレイ装置を用いてデータを中継送信するために用いられるフレーム構造に関する。

【背景技術】

【0002】

ＷＬＡＮ環境でデータフレームは、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）のようなコーディネータ装置（ｃｏｏｒｄｉｎａｔｏｒ）を経由して送信されたり、ピアツーピア（ｐｅｅｒ−ｔｏ−ｐｅｅｒ）で直接送信されることができる。しかし、一般的にコーディネータを経由してアップリンク（ｕｐ−ｌｉｎｋ）とダウンリンク（ｄｏｗｎ ｌｉｎｋ）を用いる送信は、ネットワーク内の他の機器（装置、ｓｔａｔｉｏｎ）とチャネルを取得するために競争しなければならため、その処理率が減少することがある。

【0003】

これを補完するために、８０２．１１ｅではＡＰを経由することなく装置間に直接リンク設定（ｄｉｒｅｃｔ ｌｉｎｋ ｓｅｔｕｐ；以下、ＤＬＳ）モードに応じて直接フレームを送信してチャネルの使用効率を２倍以上に向上させうようにしている。

【0004】

しかし、直接リンク設定（ＤＬＳ）モードでもネットワーク内に存在する多重経路、減衰、干渉などによってチャネル状態が悪化すると無線ネットワークの処理率も落ちて、マルチメディアストリーミングのようにＱｏＳ（Ｑｕａｌｉｔｙ Ｏｆ Ｓｅｒｖｉｃｅ）が必要な場合にこれを満足させることができない不具合がある。

【0005】

したがって、このように直接リンク設定（ＤＬＳ）モードだけで充分ではない場合にコーディネータ装置ではないネットワーク内の他の装置を介してもフレームを中継できるように規格でサポートする必要がある。すなわち、他の機器によってフレームを中継するための新しいＷＬＡＮのアドレッシング方法が求められる。

【0006】

また、フレームをさらに安定して伝達するためにコーディネータ装置にリソースをリクエストし、リクエストしたリソースの割当を受けて使用する予約基盤媒体アクセス制御（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ；ＭＡＣ）を用いる場合、中継をサポートする予約リソースと中継をサポートしない予約リソースとを別に分類する必要がある。

【0007】

その理由は、一般的に予約リソースは、そのリソースをリクエストした機器とリクエストした機器とが通信しようとするピア（ｐｅｅｒ）機器を明示し、その機器間だけの通信を許諾する。したがって、中継機器（例えば、リレイ装置）が２つの機器間のピアツーピア通信を受信して伝達する場合、中継機器も該当予約リソースの区間で２つの機器にフレームのやり取りを行わなければならない。

【0008】

したがって、このような動作ができるように予約リソースをリクエストし、該当ネットワークで中継可能なように中継機器に予約リソースを割り当てて通知する方法が求められている。

【発明の概要】

【発明が解決しようとする課題】

【0009】

本発明の一実施形態は、予約基盤チャネルアクセスをサポートする無線システムにおいて、ネットワーク内リレイ装置を用いてデータを中継送信するために用いられるフレームの構造、及び中継可能な無線リソースを予約して割り当てるコーディネータ装置、ソース装置及びリレイ装置の通信方法及びフレーム構造を提供する。

【0010】

本発明の一実施形態は、ＷＬＡＮ環境でピアツーピア通信に参加する一対の装置と中継装置及びその他の装置に現在送信するフレームが中継装置を経由して送信されるフレームという情報を通知することのできるコーディネータ装置、ソース装置及びリレイ装置の通信方法及びフレーム構造を提供する。

【0011】

また、本発明の一実施形態は、無線システムでピアツーピアのフレーム送信をコーディネータではないネットワーク内の他の機器によって中継できるよう無線リソースをリクエストして割り当てるためのコーディネータ装置、ソース装置及びリレイ装置の通信方法及びフレーム構造を提供する。

【課題を解決するための手段】

【0012】

本発明の一実施形態に係るコーディネータ装置の通信方法は、予約基盤の媒体アクセス制御を用いる無線システムのコーディネータ装置の通信方法において、ソース装置がデスティネーション装置に送信するフレームがリレイ装置を経由して中継されるようにするために、前記ソース装置から前記リレイ装置のための予約リソースをリクエストするフレームを受信するステップと、前記リクエストに応じて前記リレイ装置のための予約リソースを割り当てるステップとを含む。

【0013】

本発明の一実施形態に係るソース装置の通信方法は、デスティネーション装置に送信するフレームがリレイ装置を経由して送信されるように、コーディネータ装置に前記リレイ装置のための予約リソースをリクエストするフレームを送信するステップと、前記リレイ装置のための予約リソースをリクエストするフレームに応答して、前記コーディネータ装置から予約リソースに関する情報を受信するステップと、前記リレイ装置の中継スキームまたは前記リレイ装置を経由して中継されるフレームの種類のうち、少なくとも１つによって前記予約リソース内から前記デスティネーション装置に送信するフレームに含まれたアドレスを変更するステップとを含む。

【0014】

本発明の一実施形態に係るリレイ装置の通信方法は、コーディネータ装置から割り当てられた予約リソースに関する情報を受信するステップと、前記予約リソースに関する情報に含まれたソース装置のＩＤ及びデスティネーション装置のＩＤを確認するステップと、前記確認結果に応じて前記予約リソースを用いて前記ソース装置が送信するフレームを前記デスティネーション装置に中継するステップとを含む。

【0015】

前記フレームが前記受信された第１フレームまたは第２フレームに対する応答フレームである場合、前記応答フレームのアドレス１を前記受信された第１フレームまたは第２フレームのアドレス２フィールドアドレス値に設定し、前記応答フレームのアドレス２を前記受信された第１フレームまたは第２フレームのアドレス１フィールドアドレス値に設定するステップを含んでもよい。

【0016】

本発明の一実施形態に係るデスティネーション装置の通信方法は、コーディネータ装置から割り当てられた予約リソースに関する情報を受信するステップと、前記予約リソースに関する情報に含まれたソース装置のＩＤ及びデスティネーション装置のＩＤを確認するステップと、前記確認した結果に応じて前記予約リソース内で前記ソース装置が送信するフレームまたはリレイ装置が送信するフレームを受信するステップとを含む。

【0017】

前記フレームが前記受信された第１フレームまたは第２フレームに対する応答フレームである場合、前記応答フレームのアドレス１を前記受信された第１フレームまたは第２フレームのアドレス２フィールドアドレス値に設定し、前記応答フレームのアドレス２を前記受信された第１フレームまたは第２フレームのアドレス１フィールドアドレス値に設定するステップを含んでもよい。

【発明の効果】

【0018】

本発明の一実施形態によれば、フレーム内にリレイコントロールフィールドを挿入することによって、ＷＬＡＮのアドレッシングフレームワーク（ｆｒａｍｅｗｏｒｋ）が変化することなくソース装置、デスティネーション装置及びリレイ装置に中継されるフレームを示すことができる。

【0019】

また、本発明の一実施形態によれば、リレイ装置の中継スキーム（ｒｅｌａｙｉｎｇ ｓｃｈｅｍｅ）ごとに適切なアドレッシング方法を提供し、迂回（ｄｅｔｏｕｒ）して伝達するデータフレームとリレイリンクに関する情報を取得するための管理フレームを区別するアドレッシング方法を用いることによって、リレイ装置がＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）ヘッダだけでも各フレームを識別することができる。

【図面の簡単な説明】

【0020】

【図1】本発明の一実施形態に係るコーディネータ装置の通信方法を示すフローチャートである。

【図2】ＷＬＡＮビーコンインターバル（Ｂｅａｃｏｎ Ｉｎｔｅｒｖａｌ）構造を示す図である。

【図3】本発明の一実施形態に係る図２のサービス区間（Ｓｅｒｖｉｃｅ Ｐｅｒｉｏｄ；ＳＰ）を提供するための拡張されたスケジュール構成要素（Ｅｘｔｅｎｄｅｄ Ｓｃｈｅｄｕｌｅ Ｅｌｅｍｅｎｔ）及び割当フィールド（Ａｌｌｏｃａｔｉｏｎ Ｆｉｅｌｄ）を示す図である。

【図4】本発明の一実施形態に係るリレイ装置の通信方法を示すフローチャートである。

【図5】本発明の一実施形態に係るソース装置の通信方法を示すフローチャートである。

【図6】本発明の一実施形態に係るＭＡＣフレームフォーマットとそのアドレスフィールドの解釈を示す図である。

【図7】本発明の一実施形態に係るリレイ装置を用いてデータフレームを送信する場合にアドレスフィールドの解釈方法を説明するための図である。

【図8】本発明の一実施形態に係るリレイ装置の中継スキームまたはリレイ装置を経由して中継されるフレームの種類に応じてアドレッシング方法が変更されることを説明するための図である。

【図9】本発明の一実施形態に係るＡＤＤＴＳ Ｒｅｑｕｅｓｔ ｆｒａｍｅ ｂｏｄｙ及び修正されたＴＳＰＥＣ ＩＥを示す図である。

【図10】図９に関連する割当スケジュール（Ａｌｌｏｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ）ＩＥ、割当フィールド（Ａｌｌｏｃａｔｉｏｎ Ｆｉｅｌｄ）、及び割当制御フィールドフレームボディ（Ａｌｌｏｃａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｆｉｅｌｄ Ｆｒａｍｅ Ｂｏｄｙ）を示す図である。

【図11】本発明の一実施形態に係る中継機能を含むリソース予約リクエスト及び予約リソースを割り当てる方法を説明するための図である。

【発明を実施するための形態】

【0021】

以下、本発明に係る実施形態を添付する図面を参照しながら詳細に説明する。しかし、本発明が一実施形態によって制限されたり限定されることはない。また、各図面に提示された同一の参照符号は同一の部材を示す。

【0022】

ＩＥＥＥ ８０２．１１標準規格に基づいた無線ネットワークは、２種類の使用モード、インフラストラクチャーＢＳＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ＢＳＳ）とＩＢＳＳ（Ｉｎｄｅｐｅｎｄｅｎｔ ＢＳＳ、いわゆるａｈ ｈｏｃ）のうち１つに構成される。

【0023】

インフラストラクチャーＢＳＳは、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）と分散システム（Ｄｉｓｔｒｉｂｕｔｅｄ Ｓｙｓｔｅｍ；ＤＳ）を含むことによって、一般的に装置間の通信を含む全ての通信過程においてＡＰが用いられるＢＳＳである。すなわち、インフラストラクチャーＢＳＳは、一般的にＡＰを介してフレームを送信する。一方、ＩＢＳＳは、ＡＰなしで装置だけで構成されたネットワークを形成して分散システム（ＤＳ）への接続を許容しないＢＳＳをいう。一方、ＩＢＳＳには、ＡＰがないことから全ての通信は開始装置がＤＣＦ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）のように競争基盤チャネルのアクセスによってピア装置と直接通信する。

【0024】

ＷＬＡＮは、Ｑ装置（ＱｏＳ装置）間の直接通信のためのダイレクトリンク設定（Ｄｉｒｅｃｔ Ｌｉｎｋ Ｓｅｔｔｉｎｇ；ＤＬＳ）の手続に対して規定されている。これによると、Ｑ装置は、ＱｏＳ ＡＰやＬｅｇａｃｙ ＡＰを介してＤＬＳ ｒｅｑｕｅｓｔフレーム及びＤＬＳ ｒｅｓｐｏｎｓｅフレームをやり取りすることでＱ装置間のダイレクトリンクを設定する。

【0025】

また、最近、標準化が進行中である６０ＧＨｚ帯域のミリメートル波でのＩＥＥＥ ８０２．１１ａｄ Ｔａｓｋ Ｇｒｏｕｐでは、ｄｉｒｅｃｔｉｏｎａｌ ｃｏｍｍｕｎｉｃａｔｉｏｎとＱｏＳをサポートする。また、ＩＥＥＥ ８０２．１１ａｄ Ｔａｓｋ Ｇｒｏｕｐは、ｐｏｗｅｒ ｓａｖｉｎｇ及びｓｐｅｃｔｒｕｍ ｍａｎａｇｅｍｅｎｔを改善するためにインフラストラクチャーＢＳＳで分散システム（ＤＳ）を構成してインターネットに接続する部分のみを除く。そして、ＩＥＥＥ ８０２．１１ａｄ Ｔａｓｋ Ｇｒｏｕｐは、コーディネータ装置を置いてリソース管理、ネットワーク管理を行い、ＩＢＳＳのピアツーピア通信機能のＰｅｒｓｏｎａｌ ＩＢＳＳ（ＰＢＳＳ）を新しく採択した。

【0026】

ＰＢＳＳのＰＣＰ（ＰＢＳＳ Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ）は、アクセスポイント（Ａｃｃｅｓｓ Ｐｏｉｎｔ；ＡＰ）の機能のうち、分散システム（ＤＳ）と接続されて他のネットワークとの通信をサポートする部分を除いた他の機能をほとんどサポートするコーディネータ装置である。

【0027】

本発明の一実施形態では、ＤＬＳ経路やコーディネータ装置を経由した経路ではないネットワーク内の他の装置（例えば、リレイ装置）によってデータを送信する方法について説明する。ここで、リレイ装置によって中継送信するために基盤となるプロトコル（ｐｒｏｔｏｃｏｌ）やプロトコルに対する設定（ｓｅｔｔｉｎｇ）はすでに完了したと仮定する。

【0028】

すなわち、本発明の一実施形態では、リレイ装置によってデータを中継送信するとき、データを中継送信するフレームのアドレッシング方法とコーディネータ装置にリソースをリクエストして割り当てられる方法だけを説明する。

【0029】

第１に、データを中継送信するフレームに対するアドレッシング方法について記述する。

【0030】

説明する前に、以下で中継送信に参加した装置をそれぞれソース装置、デスティネーション装置、リレイ装置と呼ぶことにする。以下、「装置」はステーション（ｓｔａｔｉｏｎ、ＳＴＡ）を含む概念である。

【0031】

ソース装置からリレイ装置を経由してデスティネーション装置にフレームを送信する場合、中継方法によってリレイ装置のアドレスをフレームに記載する必要がある。一般的な無線ＬＡＮネットワークでは、ＢＳＳのいずれかの装置におけるデータを分散システム（ＤＳ）に接続された有線機器や他のＢＳＳに属する装置に伝達する場合に３つ以上の装置のアドレスが用いられる。

【0032】

しかし、本発明の一実施形態のようにソース装置、デスティネーション装置及びリレイ装置のそれぞれが全て無線装置であり、１つのＢＳＳに属する装置である場合、アドレッシングのため新しいフォーマットが要求される。以下、リンク情報を必要としないデータフレーム、制御フレーム及び管理フレームを第１フレームに、リンク情報を必要とするリンク情報リクエストフレーム、またはリレイの動作設定／変更リクエストフレームを第２フレームのように表現することにする。

【0033】

図１は、本発明の一実施形態に係るコーディネータ装置の通信方法を示すフローチャートである。

【0034】

図１を参照すると、コーディネータ装置は、予約基盤の媒体アクセス制御を使用する無線システムのコーディネータ装置として、ソース装置がデスティネーション装置に送信するフレームがリレイ装置を経由して中継されるようにするため、ソース装置からリレイ装置のための予約リソースをリクエストするフレームを受信する（Ｓ１１０）。

【0035】

ここで、リレイ装置のための予約リソースをリクエストするフレームは、予約リソースがリレイ装置を経由して送信されるフレームのためのものである。また、リレイ装置のための予約リソースをリクエストするフレームは、コーディネータ装置に予約リソースをリクエストしたソース装置のＩＤ（ｉｎｉｔｉａｔｏｒ ＩＤ）、ソース装置が通信しようとするデスティネーション装置のＩＤ（ｒｅｓｐｏｎｄｅｒ ＩＤ）、及びこれに関連する情報を含んでもよい。

【0036】

コーディネータ装置は、ソース装置の予約リソースリクエストに応じてリレイ装置のための予約リソースを割り当てる（Ｓ１２０）。

【0037】

ステップＳ１２０において、コーディネータ装置は、予約リソースにリレイ装置のためのサービス区間（Ｓｅｒｖｉｃｅ Ｐｅｒｉｏｄ；ＳＰ）を提供するための拡張されたスケジュール構成要素（Ｅｘｔｅｎｄｅｄ Ｓｃｈｅｄｕｌｅ Ｅｌｅｍｅｎｔ）を提供する。コーディネータ装置は、リレイ装置のための予約リソースを割り当てるためにサービス区間（ＳＰ）に拡張されたスケジュール構成要素を提供してもよい。

【0038】

ここで、拡張されたスケジュール構成要素は、ソース装置のためのソースＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ ＩＤ）領域及びデスティネーション装置のためのデスティネーションＡＩＤ領域を含む少なくとも１つの割当フィールド（Ａｌｌｏｃａｔｉｏｎ Ｆｉｅｌｄ）をサブフィールドとして含んでもよい。

【0039】

サービス区間（ＳＰ）及び拡張されたスケジュール構成要素については図２及び図３を参照して下記で説明する。

【0040】

ここで、ソース装置、デスティネーション装置及びリレイ装置は、ＲＬＳ（Ｒｅｌａｙ ｌｉｎｋ Ｓｅｔｕｐ）の過程を予め行って互いのＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ ＩＤ）を予め把握することも可能である。また、ソース装置は、ＲＬＳ過程を成功的に行なわれれば、他の装置にＲＬＳ ａｎｎｏｕｎｃｅｍｅｎｔフレームを送信してもよい。したがって、コーディネータ装置は、ソース装置から受信されたＲＬＳ ａｎｎｏｕｎｃｅｍｅｎｔフレームに含まれた情報を考慮してリソースを割り当ててもよい。

【0041】

また、コーディネータ装置は。ソース装置及びデスティネーション装置が該当フレームがリレイ装置を経由して中継されることが把握できるように、フレームのＭＡＣヘッダまたはフレームのボディにリレイ装置に対するリレイコントロールフィールド（ｒｅｌａｙ ｃｏｎｔｒｏｌ ｆｉｅｌｄ）を挿入する（Ｓ１３０）。リレイコントロールフィールドについては図５を参照して詳細に説明する。

【0042】

コーディネータ装置は、ビーコンフレームまたはアナウンスフレーム（Ａｎｎｏｕｎｃｅｍｅｎｔ Ｆｒａｍｅ）を用いて予約リソースに関する情報を放送する（Ｓ１４０）。

【0043】

ここで、予約リソースに関する情報はソース装置のＩＤ及びデスティネーション装置のＩＤを含んでもよい。

【0044】

図２は、ＷＬＡＮビーコンインターバル（Ｂｅａｃｏｎ Ｉｎｔｅｒｖａｌ）の構造を示す図である。

【0045】

図２を参照すると、ＷＬＡＮビーコンインターバルは、ＢＴ（Ｂｅａｃｏｎ Ｔｉｍｅ）２１０、Ａ−ＢＦＴ（Ａｓｓｏｃｉａｔｉｏｎ Ｂｅａｍ Ｆｏｒｍｉｎｇ Ｔｒａｉｎｉｎｇ）２２０、ＡＴ（Ａｎｎｏｕｎｃｅ Ｔｉｍｅ）２３０、及びＤＴＴ（Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｔｉｍｅ）２４０を含む。

【0046】

ＢＴ２１０は新しい装置（ＳＴＡｓ）を発見し、コーディネータ装置にリソースをリクエストする時間を示す。

【0047】

Ａ−ＢＦＴ２２０は、例えば、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）またはＰＣＰ（ＰＢＳＳ Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ）のようなコーディネータ装置と他の装置（例えば、ソース装置、デスティネーション装置及びリレイ装置）との間のビームフォーミングをための時間を示す。

【0048】

ＡＴ２３０は、ＡＰまたはＰＣＰのようなコーディネータ装置がネットワーク内の装置に割り当てられた情報をビーコンフレームまたはアナウンスフレームを用いて通知する時間を示す。

【0049】

ＤＴＴ２４０は、装置間のフレーム交換が行われるサービス区間（Ｓｅｒｖｉｃｅ Ｐｅｒｉｏｄ；ＳＰ）及び競争基盤区間（Ｃｏｎｔｅｎｔｉｏｎ−Ｂａｓｅｄ Ｐｅｒｉｏｄ；ＣＢＰ）を含む。

【0050】

以下は、ＡＰまたはＰＣＰのようなコーディネータ装置が送信するビーコンフレームまたはアナウンスフレーム内に割り当てられる拡張されたスケジュール構成要素（Ｅｘｔｅｎｄｅｄ Ｓｃｈｅｄｕｌｅ Ｅｌｅｍｅｎｔ）及び割当フィールド（Ａｌｌｏｃａｔｉｏｎ Ｆｉｅｌｄ）について説明する。

【0051】

図３は、本発明の一実施形態に係る図２のサービス区間（Ｓｅｒｖｉｃｅ Ｐｅｒｉｏｄ；ＳＰ）を提供するための拡張されたスケジュール構成要素（Ｅｘｔｅｎｄｅｄ Ｓｃｈｅｄｕｌｅ Ｅｌｅｍｅｎｔ）及び割当フィールド（Ａｌｌｏｃａｔｉｏｎ Ｆｉｅｌｄ）を示す図である。

【0052】

図３を参照すると、拡張されたスケジュール構成要素は、ソース装置のためのソースＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ ＩＤ）領域３５１及びデスティネーション装置のためのデスティネーションＡＩＤ領域３５３を含む割当フィールド３５０をサブフィールドとして含んでもよい。

【0053】

コーディネータ装置は、ソースＡＩＤ領域３５１にソース装置のアドレスを記録し、デスティネーションＡＩＤ領域３５３にデスティネーション装置のアドレスを記録する。これはリレイ装置が自身にフレームの中継をリクエストしたソース装置とフレームを受信するデスティネーション装置を確認できるようにするためである。

【0054】

図４は、本発明の一実施形態に係るリレイ装置の通信方法を示すフローチャートである。

【0055】

リレイ装置は、コーディネータ装置から割り当てられた予約リソースに関する情報を受信する（Ｓ４１０）。ここで、リレイ装置は、コーディネータ装置が送信するビーコンフレームまたはアナウンスフレームによって予約リソースに関する情報を把握することができる。

【0056】

リレイ装置は、予約リソースに関する情報に含まれたソース装置のＩＤ及びデスティネーション装置のＩＤを確認する（Ｓ４２０）。リレイ装置は、ソース装置のＩＤ及びデスティネーション装置のＩＤがリレイ装置とリレイリンクを形成した装置それぞれのＩＤとが同一であるか否かの確認に応じてＩＤを確認することができる。ここで、ソース装置のＩＤ及びデスティネーション装置のＩＤは、ソース装置のＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ ＩＤ）及びデスティネーション装置のＡＩＤであってもよい。

【0057】

リレイ装置は、４２０の確認結果に応じて予約リソースを用いてソース装置が送信するフレームをデスティネーション装置に中継する（Ｓ４３０）。

【0058】

また、リレイ装置はリレイ装置の中継スキームまたはリレイ装置を経由して中継されるフレームの種類のうち、少なくとも１つによりフレームのＭＡＣヘッダ（ＭＡＣ Ｈｅａｄｅｒ）に含まれた通信をリクエストする装置（ｉｎｉｔｉａｔｏｒ）のアドレスであるアドレス２、及び通信をリクエストする装置が通信しようとする装置（ｒｅｓｐｏｎｄｅｒ）のアドレスであるアドレス１のアドレスを変更する。

【0059】

具体的に、リレイ装置の中継スキームがフルデュプレックスアンプリファイ・アンド・フォワード（Ｆｕｌｌ Ｄｕｐｌｅｘ Ａｍｐｌｉｆｙ ａｎｄ Ｆｏｒｗａｒｄ；ＦＤ ＡＦ）スキームであり、フレームの種類が各リンクの情報を必要とするリンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームである場合、リレイ装置は、リレイ装置とデスティネーション装置との間のＲ−Ｄリンクでアドレス１にデスティネーション装置のアドレスを設定し、アドレス２にリレイ装置のアドレスを設定してもよい。

【0060】

また、リレイ装置は、リレイ装置の中継スキームがハーフデュプレックスデコード・アンド・フォワード（Ｈａｌｆ Ｄｕｐｌｅｘ Ｄｅｃｏｄｅ ａｎｄ Ｆｏｒｗａｒｄ；ＨＤ ＤＦ）スキームである場合、フレームの種類によるアドレッシング方法は次の通りである。

【0061】

リレイ装置は、フレームの種類がデータフレーム、制御フレーム及び管理フレームのいずれか１つである場合、リレイ装置とデスティネーション装置との間のＲ−Ｄリンクそれぞれでアドレス１にデスティネーション装置のアドレスを設定し、アドレス２にソース装置のアドレスを設定してもよい。

【0062】

リレイ装置は、フレームの種類が各リンクの情報を必要とするリンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームである場合、リレイ装置とデスティネーション装置との間のＲ−Ｄリンクでアドレス１にデスティネーション装置のアドレスを設定し、アドレス２にリレイ装置のアドレスを設定してもよい。

【0063】

また、リレイ装置は、フレームの種類がフレームに対する応答フレームである場合、リレイ装置とデスティネーション装置との間のＲ−Ｄリンクでアドレス１にリレイ装置のアドレスを設定し、アドレス２にデスティネーション装置のアドレスを設定する。

【0064】

その他にも、リレイ装置は、リレイ装置を経由してフレームを送信する通信スキームが協力（ｃｏｏｐｅｒａｔｉｏｎ）通信である場合、フレームの種類に応じるアドレッシング方法は次の通りである。

【0065】

フレームの種類がデータフレーム、制御フレーム及び管理フレームのいずれか１つである場合、リレイ装置はリレイ装置とデスティネーション装置との間のＲ−Ｄリンクでアドレス１にデスティネーション装置のアドレスを設定し、アドレス２にソース装置のアドレスを設定してもよい。

【0066】

フレームの種類が各リンクの情報を必要とするリンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームである場合、リレイ装置は、リレイ装置とデスティネーション装置との間のＲ−Ｄリンクでアドレス１にデスティネーション装置のアドレスを設定し、アドレス２にリレイ装置のアドレスを設定してもよい。

【0067】

また、フレームの種類が応答フレームである場合、リレイ装置は、リレイ装置とデスティネーション装置との間のＲ−Ｄリンクそれぞれでアドレス１にソース装置のアドレスを設定し、アドレス２にデスティネーション装置のアドレスを設定してもよい。

【0068】

図５は、本発明の一実施形態に係るソース装置の通信方法を示すフローチャートである。

【0069】

デスティネーション装置に送信するフレームがリレイ装置を経由して送信されるように、ソース装置は、コーディネータ装置にリレイ装置のための予約リソースをリクエストするフレームを送信する（Ｓ５１０）。

【0070】

ソース装置は、リレイ装置のための予約リソースをリクエストするフレームに応答して、コーディネータ装置から予約リソースに関する情報を受信する（Ｓ５２０）。

【0071】

ソース装置は、リレイ装置の中継スキームまたはリレイ装置を経由して中継されるフレームの種類のうち少なくとも１つによってフレームに含まれたアドレスを変更する（Ｓ５３０）。

【0072】

ステップＳ５３０において、ソース装置はリレイ装置の中継スキーム（ｓｃｈｅｍｅ）またはリレイ装置を経由して中継されるフレームの種類のうち少なくとも１つによってフレームのＭＡＣヘッダ（ＭＡＣ Ｈｅａｄｅｒ）に含まれた装置のアドレスを変更してもよい。

【0073】

フレームのＭＡＣヘッダに含まれた装置のアドレスでは通信をリクエストする装置（ｉｎｉｔｉａｔｏｒ）のアドレスであるアドレス１、及び通信をリクエストする装置（ｉｎｉｔｉａｔｏｒ）が通信しようとする装置（ｒｅｓｐｏｎｄｅｒ）のアドレスであるアドレス２が挙げられる。

【0074】

リレイ装置の中継スキームとして、フルデュプレックスアンプリファイ・アンド・フォワード（Ｆｕｌｌ Ｄｕｐｌｅｘ Ａｍｐｌｉｆｙ ａｎｄ Ｆｏｒｗａｒｄ；ＦＤ ＡＦ）スキームと、ハーフデュプレックスデコード・アンド・フォワード（Ｈａｌｆ Ｄｕｐｌｅｘ Ｄｅｃｏｄｅ ａｎｄ Ｆｏｒｗａｒｄ；ＨＤ ＤＦ）スキームが挙げられる。また、リレイ装置を経由して中継されるフレームの種類として、データフレーム、制御フレーム、管理フレーム、リレイ動作設定／変更リクエストフレーム、及び各リンクの情報を必要とするリンク情報リクエストフレームなどが挙げられる。

【0075】

リンク情報リクエストフレームは管理フレームの一種であるが、一般的な管理フレームとは異なって、各リンクの情報が必要な管理フレームという点で本発明の一実施形態では管理フレームと区別される概念として定義される。

【0076】

各リンクの情報は、ソース装置とリレイ装置との間のＳ−Ｒリンク、及びリレイ装置とデスティネーション装置との間のＲ−Ｄリンクに関する情報を含んでもよい。

【0077】

リンク情報リクエストフレームの一例として、ＲＬＳ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ、Ｌｉｎｋ Ｍａｒｇｉｎ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅなどが挙げられる。

【0078】

リレイ装置の中継スキームがフルデュプレックスアンプリファイ・アンド・フォワード（ＦＤ ＡＦ）スキームにおいて、フレームの種類がデータフレーム、制御フレーム及び管理フレームのいずれか１つである場合、ソース装置はアドレス１にデスティネーション装置のアドレスを設定し、アドレス２にソース装置のアドレスを設定してもよい。

【0079】

また、リレイ装置の中継スキームがフルデュプレックスアンプリファイ・アンド・フォワードスキームであり、フレームの種類が各リンクの情報を必要とするリンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームである場合、ソース装置は、ソース装置とリレイ装置との間のＳ−Ｒリンクでアドレス１にリレイ装置のアドレスを設定し、アドレス２にソース装置のアドレスを設定してもよい。

【0080】

リレイ装置の中継スキームがハーフデュプレックスデコード・アンド・フォワードスキームである場合、フレームの種類によるアドレッシング方法は次の通りである。

【0081】

フレームの種類がデータフレーム、制御フレーム及び管理フレームのいずれか１つである場合、ソース装置は、ソース装置とリレイ装置との間のＳ−Ｒリンクでアドレス１にリレイ装置のアドレスを設定し、アドレス２にソース装置のアドレスを設定してもよい。

【0082】

フレームの種類が各リンクの情報を必要とするリンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームである場合、ソース装置は、ソース装置とリレイ装置との間のＳ−Ｒリンクでアドレス１にリレイ装置のアドレスを設定し、アドレス２に前記ソース装置のアドレスを設定してもよい。

【0083】

また、フレームの種類が応答フレームである場合、ソース装置は、ソース装置とリレイ装置との間のＳ−Ｒリンクでアドレス１にソース装置のアドレスを設定し、アドレス２にリレイ装置のアドレスを設定してもよい。

【0084】

その他に、リレイ装置を経由してフレームを送信する通信スキームが協力通信である場合、フレームの種類によるアドレッシング方法は次の通りである。

【0085】

フレームの種類がデータフレーム、制御フレーム及び管理フレームのいずれか１つである場合、ソース装置は、ソース装置とリレイ装置との間のＳ−Ｒリンクでアドレス１にデスティネーション装置のアドレスを設定し、アドレス２にソース装置のアドレスを設定してもよい。

【0086】

フレームの種類が各リンクの情報を必要とするリンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームである場合、ソース装置は、ソース装置とリレイ装置との間のＳ−Ｒリンクでアドレス１にリレイ装置のアドレスを設定し、アドレス２にソース装置のアドレスを設定してもよい。

【0087】

また、フレームの種類が前記フレームに対する応答フレームである場合、ソース装置は、ソース装置とリレイ装置との間のＳ−Ｒリンクでアドレス１にソース装置のアドレスを設定し、アドレス２にデスティネーション装置のアドレスを設定してもよい。

【0088】

協力通信において、リレイ装置は自身が生成したフレームを送信するとき自身（リレイ装置）のアドレスを除いてソース装置とデスティネーション装置のアドレスを各アドレスに記載する。

【0089】

上述した場合、その他のリレイ装置の中継スキームまたはフレームの種類に応じる多様なアドレッシング方法については図８を参考すればよい。

【0090】

図６は、本発明の一実施形態に係るＭＡＣフレームフォーマットとそのアドレスフィールドの解釈を示す図である。

【0091】

図６を参照すると、ＭＡＣフレームフォーマットは、フレームの制御のためのフレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールド６１１、フレームの区間長さを示すデュレーションＩＤ（Ｄｕｒａｔｉｏｎ／ＩＤ）フィールド、フレームの送信のために通信をリクエストする装置（ｉｎｉｔｉａｔｏｒ）のアドレスを設定するためのアドレス（１）６１３、及びリクエストする装置が通信しようとする装置のアドレスを設定するためのアドレス（２）６１５を含むＭＡＣヘッダ（ＭＡＣ Ｈｅａｄｅｒ）６１０と通信しようとする装置に伝達するデータのためのフレームボディ（Ｆｒａｍｅ Ｂｏｄｙ）６３０を含む。

【0092】

フレームボディ６３０は、該当フレームがリレイ装置を経由して中継されるフレームであることを示すためのリレイコントロールフィールド（Ｒｅｌａｙ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ）６３１を含む。また、ＭＡＣヘッダ６１０は、フレームの中継のためにリレイ装置及びＢＳＳＩＤを考慮したアドレス（３）６１７及びアドレス（４）６１９をさらに含んでもよい。

【0093】

８０２．１１ｎでデータフレームの送信時に使用するＭＡＣフレームフォーマット（Ｆｒａｍｅ ｆｏｒｍａｔ）の場合、ソース装置、デスティネーション装置及びリレイ装置のための３つの装置アドレスにＢＳＳＩＤまで考慮した４個のアドレス６１３、６１５、６１７、及び６１９が必要である。したがって、該当フレームがリレイ装置を経由して中継されるフレームであることを通知するために、リレイコントロールフィールド６３１を新しく定義する必要がある。

【0094】

リレイコントロールフィールド６３１は、フレームのＭＡＣヘッダ６１０の部分に有効ビットがあればＭＡＣヘッダで定義し、もし、ＭＡＣヘッダにこれ以上の有効なビットがなければ、図６に示すようにフレームボディ６３１の最初のオクテット（ｏｃｔｅｔ）に挿入してもよい。

【0095】

図７は、本発明の一実施形態に係るリレイ装置を用いてデータフレームを送信する場合にアドレスフィールドの解釈方法を説明するための図である。

【0096】

図７は、図６に示すようなフレームフォーマットを用いる場合、各フィールドに対する解釈を示すものであり、（１）Ｄｉｒｅｃｔ ｌｉｎｋはダイレクトリンクを示し、ダイレクトリンクをデータを送信するためにリレイ装置を使用しないものの、図６に示すフレームフォーマットを使用することができる。

【0097】

（２）及び（３）Ｄｅｔｏｕｒ Ｌｉｎｋはリレイリンクを示す。リレイリンクは該当リンクがＳ−Ｒリンク（（２））あるいはＲ−Ｄリンク（（３））によって各アドレスのコーディングが変わり得る。また、Ｔｏ ＤＳフィールド及びＦｒｏｍ ＤＳフィールドの値で既存アドレスのコーディング方法が変わるため、リレイリンクを用いるときに図７の表を基準にしてアドレスフィールドを変形する。

【0098】

しかし、図６に示すように４個のアドレスを用いる場合、データフレームの送信のみが可能であり、これよりも小さい数のアドレスを用いる制御フレーム、管理（ｍａｎａｇｅｍｅｎｔ）フレーム、またはアクション（ａｃｔｉｏｎ）フレームの送信には適しない。

【0099】

本発明の一実施形態では、４個のアドレスを暗黙的（ｉｍｐｌｉｃｉｔ）に使用することができる。但し、この場合に、リレイ装置は自身に送信されたフレームがソース装置とデスティネーション装置との間に交換されるフレームであるかを予め把握し、競争区間ではない非競争区間でコーディネータ装置が予め予約した区間で中継するものと仮定する。

【0100】

以下は、このような暗黙的アドレッシング（ｉｍｐｌｉｃｉｔ ａｄｄｒｅｓｓｉｎｇ）を用いる場合、中継されるフレームの種類やリレイ装置の中継スキームによってどのようにアドレッシング方法が変わるかについて説明する。

【0101】

第１に、リレイ装置の中継スキームがフルデュプレックスアンプリファイ・アンド・フォワード（Ｆｕｌｌ Ｄｕｐｌｅｘ Ａｍｐｌｉｆｙ ａｎｄ Ｆｏｒｗａｒｄ；ＦＤ ＡＦ）スキームの場合として、リレイ装置は、ソース装置が送信するデータ（ｄａｔａ）フレーム、制御フレーム及び一部を除いた管理（ｍａｎａｇｅｍｅｎｔ）フレームのアドレスに対して修正することなく直ちにデスティネーション装置に該当フレームを送信する。

【0102】

したがって、リレイ装置の中継スキームがＦＤ ＡＦスキームの場合、ダイレクト（Ｄｉｒｅｃｔ）経路でフレームを送信するとき（Ｄｉｒｅｃｔ ｌｉｎｋ（（１））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ）と同じ結果を有する。

【0103】

Ｆｕｌｌ Ｄｕｐｌｅｘ ＡＦ中継の場合
●データフレーム、制御フレーム、管理フレーム（リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームを除いた管理フレーム）の場合
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２）、（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
●リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレーム（例えば、ＲＬＳ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ、Ｌｉｎｋ Ｍａｒｇｉｎ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅなどが該当）の場合
−ＨＤ ＤＦスキームと同一
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２））：Ａｄｄｒｅｓｓ１＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
−Ｄｅｔｏｕｒ ｌｉｎｋ（（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
第２に、リレイ装置の中継スキームがハーフデュプレックスデコード・アンド・フォワード（Ｈａｌｆ Ｄｕｐｌｅｘ Ｄｅｃｏｄｅ ａｎｄ Ｆｏｒｗａｒｄ；ＨＤ ＤＦ）スキームの場合、全てのフレーム（データフレーム、制御フレーム及び管理フレームなど）は下記のように各リンクの送信する装置、受信する装置のアドレスをそれぞれＡｄｄｒｅｓｓ１、Ａｄｄｒｅｓｓ２に記載する。

【0104】

Ｈａｌｆ Ｄｕｐｌｅｘ ＤＦ中継の場合
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２））：Ａｄｄｒｅｓｓ１＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
−Ｄｅｔｏｕｒ ｌｉｎｋ（（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
第３に、リレイ装置を経由してフレームを送信する通信スキームが協力通信である場合である。

【0105】

協力通信の場合
●データフレーム、制御フレーム、管理フレーム（リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームを除いた管理フレーム）の場合
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２））：Ａｄｄｒｅｓｓ１＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
−Ｄｅｔｏｕｒ ｌｉｎｋ（（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
この場合、データ、制御及び一部を除いた管理フレームは、ＨＤ ＤＦ中継スキームにもかかわらず、リレイ−デスティネーションリンクでリレイ装置のアドレスに代わってソース装置のアドレスをＡｄｄｒｅｓｓ１に記録する。ここで、ソース装置のアドレスをＡｄｄｒｅｓｓ１に記録する理由は、ソース−リレイリンクはＨＤ ＤＦ中継スキームと同一であるが、デスティネーション装置でチェース結合（ｃｈａｓｅ ｃｏｍｂｉｎｉｎｇ）を行うためである。

【0106】

第４に、前述の協力（ｃｏｏｐｅｒａｔｉｏｎ）通信から除外された管理フレームである、リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームの場合、ＨＤ ＤＦと同一に各リンクの送受信装置のアドレスを記載する。

【0107】

リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームの場合
−ＨＤ ＤＦスキームと同一
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２））：Ａｄｄｒｅｓｓ１＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
−Ｄｅｔｏｕｒ ｌｉｎｋ（（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
ここで、協力通信から除外されたリンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームとして、ＲＬＳ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ、Ｌｉｎｋ Ｍａｒｇｉｎ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅフレームなどが挙げられる。

【0108】

この場合に、リレイ装置の中継スキームがフルデュプレックスアンプリファイ・アンド・フォワード（Ｆｕｌｌ Ｄｕｐｌｅｘ Ａｍｐｌｉｆｙ ａｎｄ Ｆｏｒｗａｒｄ；ＦＤ ＡＦ）スキームであれば動作も変わるが、ＭＡＣヘッダ（ＭＡＣ Ｈｅａｄｅｒ）を復号化して該当フレームがリレイ装置に送信されたことが把握されたときにデスティネーション装置へのフォワーディングを停止する。

【0109】

その後、リレイ装置は、ソース装置から受けたフレームと同一のフレームをアドレスのみを変えた符号化したフレームをデスティネーション装置に送信する。すなわち、この場合には、ハーフデュプレックスデコード・アンド・フォワード（Ｈａｌｆ Ｄｕｐｌｅｘ Ｄｅｃｏｄｅ ａｎｄ Ｆｏｒｗａｒｄ；ＨＤ ＤＦ）スキームの場合と類似するように動作し、これに対する応答フレームの伝達も（必要な場合）類似にデスティネーション装置からソース装置に伝達する。

【0110】

最後に、図７に示す全てのフレームに対する応答が必要な場合、既存の規格のアドレスを記録する規則と同一にＡｄｄｒｅｓｓ１、Ａｄｄｒｅｓｓ２を交換して記録する。

【0111】

しかし、図７において公開されたパブリックキー（ｐｕｂｌｉｃ ｋｅｙ）を使用することなく各ピアツーピア間にやり取りしたフレームに対するペアワイズキー（ｐａｉｒｗｉｓｅ ｋｅｙ）を用いて保安を維持したい場合には、上述したアドレッシング方法とは異なるアドレッシング方法を適用しなければならない。ここで、ペアワイズキーは、１対１の対称キー（Ｐａｉｒｗｉｓｅ Ｔｒａｎｓｉｅｎｔ Ｋｅｙ）を示す。

【0112】

他の装置と保安を維持したい場合、リレイ装置がソース装置とデスティネーション装置との間のデータを中継するとしても各ソース装置とデスティネーション装置は、該当ペアワイズキーが把握されないため、受信したデータを復号化したり再び符号化して送信することができなくなる。

【0113】

一方、ＭＡＣヘッダ（ｈｅａｄｅｒ）は、受信したデータを復号化したりＣＲＣチェック（ｃｈｅｃｋ）を行ってもよいため、該当フレームが損傷した場合にもこれを表示（ｉｎｄｉｃａｔｉｏｎ）するＡＣＫフレームまたはＢｌｏｃｋＡＣＫフレームを送信してもよい。もし、リレイ装置の中継スキームがＨＤ ＤＦスキームであれば、既存のＨＤ ＤＦスキームとは異なってペアワイズキーの対象者であるソース装置のアドレス、及びデスティネーション装置のアドレスをアドレス１、アドレス２に記載してもよい。

【0114】

しかし、このようにアドレッシング方法を相異にすると、送信されたフレームに対する応答が必要な場合には従来のアドレス１、アドレス２のアドレスを変えて送信する方法ではない他のアドレッシング方法を適用しなければならない。その理由は、送信する装置を通知するために次の図８で示すように使用する迂回リンク（Ｄｅｔｏｕｒ Ｌｉｎｋ（２）または（３））の送受信装置のアドレスを記載する。

【0115】

但し、データフレームを送信する途中に各リンク（Ｄｅｔｏｕｒ Ｌｉｎｋ（２）または（３））の情報をリクエストしたりしてリレイ装置に管理フレーム（ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ）を送信しなければならない場合が発生し得る。このような場合では、リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームがあり、ＲＬＳ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ、Ｌｉｎｋ Ｍａｒｇｉｎ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅフレームを例にすることができる。

【0116】

この場合（リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレーム送信の場合）のみ例外としてデータフレームとは異なって暗号化の重要性が少ないため暗号化が行われず、パブリックキー（ｐｕｂｌｉｃ ｋｅｙ）または各リンクの装置間のペアワイズキー（ｐａｉｒｗｉｓｅ ｋｅｙ）を使用することができ、いずれのものも構わない。したがって、上述した場合には暗号化（ｅｎｃｒｙｐｔｉｏｎ）によってアドレッシングを変更する必要がないため、既存のＨＤ ＤＦスキームのようなアドレッシング方法を用いることができる。

【0117】

協力通信の場合も類似にソース装置とデスティネーション装置との間のペアワイズキーで暗号化したフレームを受信したときにはペアワイズキーの対象者であるソース装置のアドレス及びデスティネーション装置のアドレスをＡｄｄｒｅｓｓ（アドレス）１、Ａｄｄｒｅｓｓ２に記載する。

【0118】

これに対する応答フレームは若干の差があるものの、協力通信は（１）、（３）迂回リンクを介してデスティネーション装置に伝達されたフレームを結合（ｃｏｍｂｉｎｉｎｇ）し、これに対する応答フレームを既存のルールによって、（１）リンクの応答のようにデスティネーション装置及びソース装置のアドレスをＡｄｄｒｅｓｓ１、Ａｄｄｒｅｓｓ２のアドレスにそれぞれ書いて送信する。

【0119】

協力通信もリレイ装置に伝達したり各リンクの情報をリクエストする管理フレーム（Ｍａｎａｇｅｍｅｎｔ Ｆｒａｍｅ）、例えば、ＲＬＳ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ、Ｌｉｎｋ Ｍａｒｇｉｎ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅフレームのようなリンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームの場合には既存のＨＤ ＤＦのようなスキームを用いる。

【0120】

最後に、リレイ装置の中継スキームがＦＤ ＡＦスキームである場合、一般的にデコードアンド・フォワード（ＤＦ）が異なるため暗号化されず、デコードアンド・フォワード（ＤＦ）する一部の管理フレームもＨＤ ＤＦスキームや協力通信のように暗号化を避けることができるため、既存のＨＤ ＤＦのようなスキームを用いることができる。上述の内容を整理すれば、図８のように示すことができる。

【0121】

図８は、本発明の一実施形態に係るリレイ装置の中継スキームまたはリレイ装置を経由して中継されるフレームの種類に応じてアドレッシング方法が変更されることを説明するための図である。

【0122】

リレイ装置の中継スキームによってＦＤ ＡＦスキームとＨＤ ＤＦスキームはフレームを送信する方向が互いに異なってもよい。また、リレイ装置を経由して中継されるフレームがデータフレームであるか、または、制御フレームであるか、または、各リンクの情報が必要な管理フレームであるかに応じてアドレッシング方法が変わり得る。

【0123】

したがって、ソース装置は、リレイ装置の中継スキームまたはリレイ装置を経由して中継されるフレームの種類に応じてアドレッシング方法を相異にしてもよい。

【0124】

ソース装置がそれぞれの場合によってアドレッシング方法を相異にする方法については以下のように説明される。

【0125】

Ｈａｌｆ Ｄｕｐｌｅｘ ＤＦ中継の場合
●データ、制御及び管理フレーム（リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームを除いた管理フレーム）の場合
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２）、（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
●前記フレームに対する応答フレームの場合
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２）応答）：Ａｄｄｒｅｓｓ１＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
−Ｄｅｔｏｕｒ ｌｉｎｋ（（３）応答）：Ａｄｄｒｅｓｓ１＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
●リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームの場合
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２））：Ａｄｄｒｅｓｓ１＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
−Ｄｅｔｏｕｒ ｌｉｎｋ（（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
協力通信の場合
●データ、制御及び管理フレーム（リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームを除いた管理フレーム）の場合
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２）、（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
●前記フレームに対する応答フレームの場合
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２）応答、（３）応答）Ａｄｄｒｅｓｓ１＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
●リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレーム（ＲＬＳ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ、Ｌｉｎｋ Ｍａｒｇｉｎ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ）の場合
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２））：Ａｄｄｒｅｓｓ１＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
−Ｄｅｔｏｕｒ ｌｉｎｋ（（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
Ｆｕｌｌ Ｄｕｐｌｅｘ ＡＦ中継の場合
● ｄａｔａ、ｃｏｎｔｒｏｌ、ｍａｎａｇｅｍｅｎｔフレーム（リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレームを除いたフレーム）
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２）、（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
●リンク情報リクエストフレームまたはリレイ動作設定／変更リクエストフレーム（ＲＬＳ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ、Ｌｉｎｋ Ｍａｒｇｉｎ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ）
−ＨＤ ＤＦスキームと同一
−Ｄｅｔｏｕｒ ｌｉｎｋ（（２））：Ａｄｄｒｅｓｓ１＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｓｏｕｒｃｅ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
−Ｄｅｔｏｕｒ ｌｉｎｋ（（３））：Ａｄｄｒｅｓｓ１＝Ｄｅｓｔｉｎａｔｉｏｎ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ２＝Ｒｅｌａｙ ＳＴＡ Ａｄｄｒｅｓｓ、Ａｄｄｒｅｓｓ３＝ＢＳＳＩＤ
以下、図９〜図１１を参照して中継のために用いる予約リソースを割り当てる方法について説明する。

【0126】

ＷＬＡＮとＷＰＡＮではＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）（ＷＬＡＮの場合）またはＰＮＣ（Ｐｉｃｏ−Ｎｅｔ Ｃｏｏｒｄｉｎａｔｏｒ）（ＷＰＡＮの場合）は時間区域を競争区間と非競争区間に分類することによって、競争スキームと非競争スキームにデータを送信してもよい。

【0127】

競争区間では、ネットワークの全ての装置がチャネルを取得するためにＣＳＭＡ／ＣＡスキームに基づいて競争する。また、非競争区間では、ＡＰあるいはＰＮＣがポーリング（Ｐｏｌｌｉｎｇ）方式、またはスケジューリング情報を送信する方法を用いることによって、該当機器が非競争区間の特定の時間領域で独占的にデータを送信するための方法を提供する。

【0128】

もちろん、ＥＣＭＡ３６８、３８７のようにコーディネータ装置がなくて分散基盤の媒体アクセス制御（ｄｉｓｔｒｉｂｕｔｅｄ ＭＡＣ）を用いるシステムでも他の機器が使用しない非競争区間でスケジューリング情報を放送して予約するスキームを用いることができる。

【0129】

本発明の一実施形態では、非競争区間でピアツーピアに送信されるフレームを直接経路だけでなく、中継機器を経由しても伝達できる予約リソースをリクエストし、このようなリソースを割り当てる方法について説明する。

【0130】

以下、ＩＥＥＥ８０２．１１ＷＬＡＮ基盤でコーディネータが存在する場合について説明する。

【0131】

まず、ピア（ｐｅｅｒ）通信をリクエストする機器をソース装置といい、ピア通信に対するリクエストに応答する機器をデスティネーション装置といい、２つの装置間のフレームを中継する機器をリレイ装置と定義する。

【0132】

上記の３装置間に必要な初期化過程はすでに完了したと仮定する。

【0133】

ソース装置がデスティネーション装置にリレイ装置を経由してデータを送信してもよいリソース予約をコーディネータ装置にリクエストすると仮定する。ここで、コーディネータ装置ではＷＬＡＮのＡＰが挙げらるが、必ずこれに限定されることなく、ＡＰのような機能をサポートするコーディネータは全てコーディネータ装置に該当する。

【0134】

一般的にこのようなリソースを区分するためにリソースをリクエストする装置のＩＤ（ｉｎｉｔｉａｔｏｒ ＩＤと定義する）と、リクエストした装置が通信しようとする装置のＩＤ（ｒｅｓｐｏｎｄｅｒ ＩＤと定義する）を通知する。場合に応じてリソースをリクエストする装置（ｉｎｉｔｉａｔｏｒ）がＡＰにリソースをリクエストするフレームを送信するため、リソースをリクエストする装置（ｉｎｉｔｉａｔｏｒ）がリソースリクエストするとき送信するフィールドにｉｎｉｔｉａｔｏｒ ＩＤは省略してもよい。

【0135】

また、８０２．１１ｅの場合、送信するデータの特性に応じて、ＱｏＳ（Ｑｕａｌｉｔｙ Ｏｆ Ｓｅｒｖｉｃｅ）を相異に適用するためにトラフィックＩＤ（ｔｒａｆｆｉｃ ＩＤ）を追加してもよい。また、他のトラフィック関連のパラメータを定義しているＴＳＰＥＣ ＩＥフィールドを含むＡＤＤＴＳ Ｒｅｑｕｅｓｔフレームを用いてリソースをリクエストし、ＡＰとネゴシエーション（ｎｅｇｏｔｉａｔｉｏｎ）の後でトラフィックストリーム（Ｔｒａｆｆｉｃ Ｓｔｒｅａｍ；以下、ＴＳ）を設定してもよい。

【0136】

このようにトラフィックストリーム（ＴＳ）を設定した後にデータを送信しようとする場合、ＨＣＣＡのＰｏｌｌｅｄ ＴＸＯＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｏｐｐｏｒｔｕｎｉｔｙ）、ＥＤＣＡのＴＸＯＰを得たり８０２．１１ｎのＰＳＭＰを用いることができる。

【0137】

しかし、８０２．１１規格では非競争区間でピアツーピアのための区間をリクエストし、これを割り当てる方法が提案されていない。また、このようなピアツーピアのための予約を行う８０２．１５のＣｈａｎｎｅｌ Ｔｉｍｅ Ａｌｌｏｃａｔｉｏｎ（ＣＴＡ）、ＥＣＭＡ ３６８、３８７のＤＲＰ（Ｄｉｓｔｒｉｂｕｔｅｄ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）を用いるスキームでも該ピアツーピアのトラフィックを中継する場合について扱っていない。

【0138】

より詳細には、一般的な予約スキームは、リクエストするフレームにｉｎｉｔｉａｔｏｒ ＩＤ（装置を区分できるＩＤやａｄｄｒｅｓｓ）とｒｅｓｐｏｎｄｅｒ ＩＤを含む。そして、割り当てられたことを通知するフレームでもｉｎｉｔｉａｔｏｒ ＩＤ、ｒｅｓｐｏｎｄｅｒ ＩＤと共に割り当てられた時間の開始瞬間とｄｕｒａｔｉｏｎを通知してそれぞれ割り当てられた区間をこのＩＤｓで区分する。

【0139】

したがって、８０２．１１でもこのようなスキームを維持することができ、ＩＤが同一であってもトラフィックのクラスが異なるためＴＩＤが追加される。コーディネータ装置は、このように割り当てられた情報をビーコンフレームやアナウンスメントフレーム（ａｎｎｏｕｎｃｅｍｅｎｔ ｆｒａｍｅ）を用いてブロードキャストする。

【0140】

すると、装置は割り当てたリソースのうち自身のＩＤがあるかをチェックして、割り当てられたリソースのうち自身のＩＤがあれば割り当てられた区間でデータ送信を行う。ここで、ｉｎｉｔｉａｔｏｒ ＩＤ及びｒｅｓｐｏｎｄｅｒ ＩＤを用いることは、この２装置のみが該当予約された区間を用いるように許諾したことを示す。

【0141】

したがって、リレイ装置がデータを送受信するときには他のフィールドが必要である。

【0142】

このような中継機能を含むリソース予約をリクエストしたり割り当てる方法は様々である。

【0143】

第１の方法は、ソース装置がＡＰに中継可能なリソースをリクエストするときにこれを表すフィールドを共に示すことで、図９を参照して説明する。

【0144】

図９は、本発明の一実施形態に係るＡＤＤＴＳ Ｒｅｑｕｅｓｔ ｆｒａｍｅのｂｏｄｙ及び修正されたＴＳＰＥＣ ＩＥを示す図である。

【0145】

図９は、第１の方法を実行するためにＡＤＤＴＳ Ｒｅｑｕｅｓｔフレームに挿入されるＴＳＰＥＣ ＩＥのＴＳ Ｉｎｆｏ９１０にＲｅｓｐｏｎｄｅｒ ＩＤ９１１、Ｒｅｌａｙ Ｒｅｓｅｒｖａｔｉｏｎ９１３及びＲｅｌａｙ装置ＩＤ９１５フィールドを挿入する。

【0146】

ここで、Ｒｅｌａｙ Ｒｅｓｅｒｖａｔｉｏｎ９１３フィールドが活性化されれば、リクエストするリソース予約がリレイ機能を用いることを意味し、また、該当フィールドが活性化されればＲｅｌａｙ装置ＩＤ９１５になる。すると、ＡＰは割り当てられたリソース情報を放送するときにＲｅｌａｙ Ｒｅｓｅｒｖａｔｉｏｎ９１３及びＲｅｌａｙ装置ＩＤ９１５フィールドを追加し、これをリクエストしたフィールド値をコピーして送信する。

【0147】

Ｒｅｓｐｏｎｄｅｒ ＩＤ９１１フィールドは、リクエストするリソースでピアツーピアに送信するときｒｅｓｐｏｎｄｅｒのＩＤを意味する。また、Ｒｅｌａｙ Ｒｅｓｅｒｖａｔｉｏｎ９１３フィールドは、該当フレームをリレイ装置を経由して送信する可能性があることを示す（ｉｎｄｉｃａｔｅ）。

【0148】

Ｒｅｌａｙ装置ＩＤ９１５フィールドは、ＡＰが該当フレームを中継するリレイ装置を識別するためのＩＤを他の装置に通知するためのものである。ＡＰのようなコーディネータ装置は、例えば、ビーコンフレームやアナウンスフレームにＡｌｌｏｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ ＩＥを挿入する方法に基づいてリレイ装置のＩＤを通知する。

【0149】

各割当リソース情報は割当フィールド（Ａｌｌｏｃａｔｉｏｎ Ｆｉｅｌｄ）に記述され、割当制御フィールド（Ａｌｌｏｃａｔｉｏｎ Ｃｏｎｔｒｏｌ ｆｉｅｌｄ）は割り当てられたリソースの特性を記述する。Ｒｅｌａｙ Ｒｅｓｅｒｖａｔｉｏｎ９１３フィールド及びＲｅｌａｙ装置ＩＤ９１５フィールドはリレイ機能のために新しく追加されたフィールドであり、これについては図１０を参照して説明する。

【0150】

図１０は、図９に関連する割当スケジュール（Ａｌｌｏｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ）ＩＥ、割当フィールド（Ａｌｌｏｃａｔｉｏｎ Ｆｉｅｌｄ）、及び割当制御フィールドフレームボディ（Ａｌｌｏｃａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｆｉｅｌｄ Ｆｒａｍｅ Ｂｏｄｙ）を示す図である。

【0151】

図１０を参照すると、非競争スキームにピアツーピアのためのリソース割当情報をＡｌｌｏｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ ＩＥを用いて記述してもよい。ここで、各リソース割当ごとに割当フィールド（ａｌｌｏｃａｔｉｏｎ ｆｉｅｌｄ）に対応して挿入し、割当フィールドに割り当てられたリソースの開始時間（Ａｌｌｏｃａｔｉｏｎ Ｓｔａｒｔ Ｔｉｍｅ）、ＩＤ（Ｉｎｉｔｉａｔｏｒ ＩＤ、Ｒｅｓｐｏｎｄｅｒ ＩＤ）などのフィールドを記述する。ここで、Ｒｅｌａｙ装置ＩＤ１０１０フィールド及びＲｅｌａｙ Ｒｅｓｅｒｖａｔｉｏｎ１０３０フィールドについても記述してもよい。

【0152】

上述した第１の方法の場合、従来のフィールドに新しいフィールドを追加しなければならないが、リレイ動作を使用しないリソース予約についても該当フィールドを置くことができる。

【0153】

上述した第２の方法は、従来のリソース予約がピアツーピア通信で２つの装置のＩＤを明示するものであるため、これを拡張してリレイ装置を経由して送信する場合、ソース装置とデスティネーション装置との間のＳ−Ｄリンクに追加的にＳ−ＲリンクとＲ−Ｄリンクを用いることができる。したがって、追加される２つのリンク（Ｓ−ＲリンクとＲ−Ｄリンク）を使用するために２つのリソースに対する予約リクエストが追加されなければならず、そのためにＡＤＤＴＳ Ｒｅｑｕｅｓｔ ｆｒａｍｅをＡＰに送信するときにＴＳＰＥＣ ＩＥを追加してもよい。

【0154】

しかし、上述したようにＴＳＰＥＣ ＩＥにデスティネーションＩＤフィールドのみが存在し、ソースＩＤフィールドが存在しない場合（これがなくてもＡＰがＲｅｑｕｅｓｔ ｆｒａｍｅに含まれたｔｒａｎｓｍｉｔｔｉｎｇ ａｄｄｒｅｓｓによって確認できるため、ないことがさらに効率的である）に３リンクを示すそれぞれの一対のＩＤを挿入できない。

【0155】

したがって、ソース装置がＳ−ＤリンクとＳ−Ｒリンクを示す２つのＴＳＰＥＣ ＩＥを１つのＡＤＤＴＳ Ｒｅｑｕｅｓｔを入れる。残りのＲ−Ｄリンクのリソースリクエストのためには、リレイ装置がＡＤＤＴＳ Ｒｅｑｕｅｓｔフレームを追加的に送信する。

【0156】

上述したＡＤＤＴＳ Ｒｅｑｕｅｓｔフレームを送信するとき自身に必要なリソース割当時間を算出するためには、アプリケーションデータレート（Ｄａｔａ Ｒａｔｅ）と物理階層（ＰＨＹ）におけるレート、その他のｃａｐａｂｉｌｉｔｙ情報が必要である。

【0157】

これによって算出した情報（リソース割当時間に関する情報）をＡＤＤＴＳ Ｒｅｑｕｅｓｔフレームに書いて送信するとき、リレイ装置も同じ情報を送信しなければならないため、ソース装置がリレイ装置に情報を送信する追加シグナリング（ｓｉｇｎａｌｉｎｇ）が必要である。また、ＡＰの立場でも一般的にリレイ装置のＡＤＤＴＳ Ｒｅｑｕｅｓｔフレームの送信がソース装置よりも遅れ、場合に応じてリレイ装置がＡＤＤＴＳ Ｒｅｑｕｅｓｔフレームを同じビーコン区間（または、スーパーフレーム区間）でリクエストしなくてもよい。それにもかかわらず、リレイ装置からのＡＤＤＴＳ Ｒｅｑｕｅｓｔフレームを受信するまでＡＰはスケジューリングを遅らせる。

【0158】

本発明の一実施形態では、ＡＰがスケジューリングを遅らせないために下記のような方法を用いる。

【0159】

リレイ動作を設定したソース装置からこれを設定したデスティネーション装置とのＡＤＤＴＳ Ｒｅｑｕｅｓｔフレームをリクエストした場合、ＡＰは論理的に３つのリソースを割り当てて放送することができる。前述したように、リレイ動作を設定した後ソース装置がリレイ設定をこれに参加した３装置のＩＤと共に含んでＡＰに通知すれば、ＡＰはリレイ装置のＩＤを知っているため３つのリソースを割り当てる。

【0160】

ここで、割り当てられたリソースは物理的に同じ開始時間、同じ区間の長さを有する１つのリソースであるため、割り当てられたリソースの他の情報は全て同じであり、単にｉｎｉｔｉａｔｏｒ ＩＤとｒｅｓｐｏｎｄｅｒ ＩＤのみが異なる。

【0161】

したがって、後述する図１１に示すように図１０に示すＡｌｌｏｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ ＩＥをそのまま用いて３つの割当フィールド（ａｌｌｏｃａｔｉｏｎ ｆｉｅｌｄ）を構成して挿入してもよい。

【0162】

該３つの割当フィールドはそれぞれｉｎｉｔｉａｔｏｒ ＩＤとｒｅｓｐｏｎｄｅｒ ＩＤを除いた全てのフィールドが同一である。他の２つのフィールドはそれぞれリンクを用いる一対の装置（ａ ｐａｉｒ ｏｆ ＳＴＡｓ）を意味する。

【0163】

このＡｌｌｏｃａｔｉｏｎ Ｓｃｈｅｄｕｌｅ ＩＥを受けた３つの装置は、３つの割当フィールドを探索して各フィールド（ｉｎｉｔｉａｔｏｒ ＩＤ、ｒｅｓｐｏｎｄｅｒ ＩＤ）が３つの装置ＩＤの組合である（Ｓ、Ｄ）、（Ｓ、Ｒ）、（Ｒ、Ｄ）を示すと、割り当てられた区間でデータを送信する。ここで、データはリレイ装置を経由して中継しながら使用されてもよく、３つの装置ＩＤはリレイ設定を共にした装置のＩＤである。

【0164】

前述した３つの方法によると、追加されるフィールド（第１）や１つのリソースの割当にも２つのＡＤＤＴＳフレームを送信したり（第２）、３つの割当情報（第３）を必要とするため、重複的（ｒｅｄｕｎｄａｎｔ）であってもよい。

【0165】

以下、予約リソースのリクエスト及び割当に従来のリソース予約及び割当をそのまま使用する方法について説明する。

【0166】

図１１は、本発明の一実施形態に係る中継機能を含む予約リソースのリクエスト及び予約リソースを割り当てる方法を説明するための図である。

【0167】

そのためにソース、デスティネーション装置は、リレイ装置とリレイ機能を用いると設定（ｓｅｔ ｕｐ）し、このように設定されたことをＡＰに通知したと仮定する。

【0168】

すると、ソース装置がＡＰにリソースをリクエストしてＡＰが割り当てたリソース区間情報を放送したとき、放送された割当情報はソース装置ＩＤ、デスティネーション装置ＩＤを含んでいる。したがって、リレイ装置もその２つの装置のＩＤをチェックした後、自身をリレイ（ｒｅｌａｙ）として使用することを設定した２つの装置のＩＤと同一であれば、該当区間に移動してリレイ動作を行ってもよい。

【0169】

原則的に、リレイ装置はデータの送信を許諾されていない。したがって、ソース装置が１１ｎ ｒｅｖｅｒｓｅ ｄｉｒｅｃｔｉｏｎ ｐｒｏｔｏｃｏｌを用いて自身が所有者であるリソースでデスティネーション以外の装置がデータを送信できるようにｒｅｖｅｒｓｅ ｄｉｒｅｃｔｉｏｎ ｇｒａｎｔ ｆｒａｍｅを送信し、権限の受けたリレイ装置が中継して再びソースにｇｒａｎｔを渡す過程を行わなければならない。これはリレイ装置に続けてｇｒａｎｔ ｆｒａｍｅを送信しなければならず、その間にはデータやＡＣＫを送信できないためリソースの浪費になる。

【0170】

しかし、リレイを用いる予約リソースでは、リレイ装置は最終の目的先ではない。したがって、上述したように、リレイ装置が受信装置のアドレスと設定されて受信したフレームに対して応答したり、残りの１つの装置（例えば、デスティネーション装置）に中継することが最も好ましい。この場合、上述した第２の方法におけるｇｒａｎｔ ｆｒａｍｅを使用しなくてもよいためである。

【0171】

上述した方法は、 多様なコンピュータ手段を介して様々な処理を実行することができるプログラム命令の形態で実現され、コンピュータ読取可能な記録媒体に記録されてもよい。コンピュータ読取可能な媒体は、プログラム命令、データファイル、データ構造などのうちの１つまたはその組合せを含んでもよい。媒体に記録されるプログラム命令は、本発明の目的のために特別に設計されて構成されたものでもよく、コンピュータソフトウェア分野の技術を有する当業者にとって公知のものであり、使用可能なものであってもよい。コンピュータ読取可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク及び磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光記録媒体、光ディスクのような光磁気媒体、及びＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を保存して実行するように特別に構成されたハードウェア装置が含まれてもよい。プログラム命令の例としては、コンパイラによって生成されるような機械語コード（ｍａｃｈｉｎｅ ｃｏｄｅ）だけでなく、インタプリタなどを用いてコンピュータによって実行され得る高級言語コード（ｈｉｇｈｅｒ ｌｅｖｅｌ ｃｏｄｅ）を含む。上述したハードウェア装置は、本発明の動作を行うために１つ以上のソフトウェアのレイヤで動作するように構成されてもよい。

【0172】

上述したように、本発明を限定された実施形態と図面によって説明したが、本発明は、上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態から多様な修正及び変形が可能である。

【0173】

したがって、本発明の範囲は、開示された実施形態に限定されるものではなく、特許請求の範囲だけではなく特許請求の範囲と均等なものなどによって定められるものである。

【符号の説明】

【0174】

２１０ ＢＴ（Ｂｅａｃｏｎ Ｔｉｍｅ）
２２０ Ａ−ＢＦＴ（Ａｓｓｏｃｉａｔｉｏｎ Ｂｅａｍ Ｆｏｒｍｉｎｇ Ｔｒａｉｎｉｎｇ）
２３０ ＡＴ（Ａｎｎｏｕｎｃｅ Ｔｉｍｅ）
２４０ ＤＴＴ（Ｄａｔａ Ｔｒａｎｓｆｅｒ Ｔｉｍｅ）

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】