JP5815571B2

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

Info

Publication number: JP5815571B2
Application number: JP2012556994A
Authority: JP
Inventors: クウォン、ヒャン、ジン; キム、ヨン、スン; チャン、カプ、ソク; ホン、スン、ユン; ジン、スン、グン; リー、ウー、ヨン; チュン、ヒュン、キュ
Original assignee: Electronics and Telecommunications Research Institute ETRI
Current assignee: Electronics and Telecommunications Research Institute ETRI
Priority date: 2010-03-11
Filing date: 2011-03-11
Publication date: 2015-11-17
Anticipated expiration: 2031-03-11
Also published as: US20150373589A1; JP6087387B2; KR20110102847A; KR20190075890A; US9906987B2; KR102246837B1; KR101755013B1; US9125105B2; EP3570458B1; EP2547008A2; KR20170081156A; KR20180100536A; JP2013522951A; CN102812648A; US20180184335A1; KR20200054929A; WO2011112056A3; EP2547008A4; KR101993876B1; US10764790B2

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本発明の一実施形態に係るコーディネータ装置の通信方法を示すフローチャートである。ＷＬＡＮビーコンインターバル（ＢｅａｃｏｎＩｎｔｅｒｖａｌ）構造を示す図である。本発明の一実施形態に係る図２のサービス区間（ＳｅｒｖｉｃｅＰｅｒｉｏｄ；ＳＰ）を提供するための拡張されたスケジュール構成要素（ＥｘｔｅｎｄｅｄＳｃｈｅｄｕｌｅＥｌｅｍｅｎｔ）及び割当フィールド（ＡｌｌｏｃａｔｉｏｎＦｉｅｌｄ）を示す図である。本発明の一実施形態に係るリレイ装置の通信方法を示すフローチャートである。本発明の一実施形態に係るソース装置の通信方法を示すフローチャートである。本発明の一実施形態に係るＭＡＣフレームフォーマットとそのアドレスフィールドの解釈を示す図である。本発明の一実施形態に係るリレイ装置を用いてデータフレームを送信する場合にアドレスフィールドの解釈方法を説明するための図である。本発明の一実施形態に係るリレイ装置の中継スキームまたはリレイ装置を経由して中継されるフレームの種類に応じてアドレッシング方法が変更されることを説明するための図である。本発明の一実施形態に係るＡＤＤＴＳＲｅｑｕｅｓｔｆｒａｍｅｂｏｄｙ及び修正されたＴＳＰＥＣＩＥを示す図である。図９に関連する割当スケジュール（ＡｌｌｏｃａｔｉｏｎＳｃｈｅｄｕｌｅ）ＩＥ、割当フィールド（ＡｌｌｏｃａｔｉｏｎＦｉｅｌｄ）、及び割当制御フィールドフレームボディ（ＡｌｌｏｃａｔｉｏｎＣｏｎｔｒｏｌＦｉｅｌｄＦｒａｍｅＢｏｄｙ）を示す図である。本発明の一実施形態に係る中継機能を含むリソース予約リクエスト及び予約リソースを割り当てる方法を説明するための図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

予約基盤の媒体アクセス制御を用いる無線システムのコーディネータ装置の通信方法において、
ソース装置がデスティネーション装置に送信するフレームがリレイ装置を経由して中継されるようにするために、前記ソース装置から前記リレイ装置のための予約リソースをリクエストするフレームを受信するステップと、
サービス区間のために拡張されたスケジュール構成要素（ＥｘｔｅｎｄｅｄＳｃｈｅｄｕｌｅＥｌｅｍｅｎｔ）をリレイ装置に送信するステップと、
前記リクエストに応じて前記リレイ装置のための予約リソースを割り当てるステップと、
を含み、
前記拡張されたスケジュール構成要素は、
ソース装置に対応するソースＡＩＤとデスティネーション装置に対応するデスティネーションＡＩＤとに区分される割り当てフィールドを含み、ビーコンフレームまたはアナウンスメントフレームを用いて送信され、
前記リレイ装置は、拡張されたスケジュール構成要素に含まれるソースＡＩＤに対応するソース装置からフレームを受信し、フルデュプレックスアンプリファイ・アンド・フォワード（ＦｕｌｌＤｕｐｌｅｘＡｍｐｌｉｆｙａｎｄＦｏｒｗａｒｄ：ＦＤＡＦ）スキームまたはハーフデュプレックスデコード・アンド・フォワード（ＨａｌｆＤｕｐｌｅｘＤｅｃｏｄｅａｎｄＦｏｒｗａｒｄと、ＨＤＤＦ）スキームを用いて拡張されたスケジュール構成要素に含まれるデスティネーションＡＩＤに対応するデスティネーション装置にフレームを中継する装置を含むことを特徴とするコーディネータ装置の通信方法。
ビーコンフレームまたはアナウンスメントフレームを用いてコーディネータ装置から割り当てられた予約リソースに関する情報を受信するステップと、
前記予約リソースに関する情報に含まれたソース装置に対応するソースＡＩＤとデスティネーション装置に対応するデスティネーションＡＩＤとに区分される割り当てフィールドからソース装置のＡＩＤ及びデスティネーション装置のＡＩＤを確認するステップと、
前記確認結果に応じてフルデュプレックスアンプリファイ・アンド・フォワード（ＦｕｌｌＤｕｐｌｅｘＡｍｐｌｉｆｙａｎｄＦｏｒｗａｒｄ：ＦＤＡＦ）スキームまたはハーフデュプレックスデコード・アンド・フォワード（ＨａｌｆＤｕｐｌｅｘＤｅｃｏｄｅａｎｄＦｏｒｗａｒｄと、ＨＤＤＦ）スキームに基づいて前記予約リソースを用いて前記ソース装置のＡＩＤに対応するソース装置が送信するフレームを前記デスティネーション装置のＡＩＤに対応するデスティネーション装置に中継するステップと、を含み、
前記割り当てられた予約リソースに関する情報は、前記ソース装置から前記コーディネータ装置に送信された前記リレイ装置のための予約リソースをリクエストするフレームに基づくことを特徴とするリレイ装置の通信方法。