(58)【調査した分野】(Int.Cl.,DB名)
前記リンクを設定するステップは、前記グループに属する少なくとも1つのノードから受信されたサービスリクエストフレームに基づいてLDR情報を取得するステップと、
前記取得したLDR情報に基づいて前記ノードのLDRの利用可能性を確認するステップと、
前記取得したLDR情報に基づいてマルチキャストサービス及びブロードキャストサービスを開始するステップと、
前記確認されたLDRの利用可能性に基づいてLDR利用可能なノードとLDRリンクを設定するステップとを含むことを特徴とする請求項1に記載の通信方法。
前記リンクを設定するステップは、マルチキャストサービス及びブロードキャストサービスを開始するクエリフレームを前記グループに属する少なくとも1つのノードに送信するステップと、
前記クエリフレームに対するクエリ応答フレームを受信するステップと、
前記クエリ応答フレームに基づいて、前記グループに属する少なくとも1つのノードのLDRの利用可能性を確認するステップと、
前記確認されたLDRの利用可能性に基づいてLDR利用可能なノードとLDRリンクを設定するステップとを含むことを特徴とする請求項1に記載の通信方法。
前記リンク設定部は、前記グループに属する少なくとも1つのノードから受信されたサービスリクエストフレームを用いてLDR情報を取得し、前記取得したLDR情報に基づいて前記ノードのLDRの利用可能性を確認するLDR情報取得部と、
前記取得したLDR情報に基づいてマルチキャストサービス及びブロードキャストサービスを開始し、前記確認されたLDRの利用可能性に基づいてLDR利用可能なノードとLDRリンクを設定するLDRリンク設定部とを含むことを特徴とする請求項8に記載の通信装置。
前記リンク設定部は、マルチキャスト及びブロードキャストサービスを開始するクエリフレームを前記グループに属する少なくとも1つのノードに送信し、前記クエリフレームに対するクエリ応答フレームを受信してLDR情報を取得するLDR情報取得部と、
前記LDR情報に基づいて前記グループに属する少なくとも1つのノードのLDRの利用可能性を確認し、前記確認されたLDRの利用可能性に基づいてLDR利用可能なノードとLDRリンクを設定するLDRリンク設定部とを含むことを特徴とする請求項8に記載の通信装置。
前記ACKを前記ヘッドに送信するステップは、前記ACKリクエストフレームに含まれたACKオフセット情報に基づいて前記ACKを送信するための送信時点を決定するステップと、
前記決定された送信時点にて前記ACKをLDR又はHDRのいずれか1つを用いて前記ヘッドに送信するステップとを含むことを特徴とする請求項15に記載の通信方法。
前記リンク設定部は、前記ヘッドからLDRリンクリクエストフレームを受信し、前記LDRリンクリクエストフレームに対するLDRリンク応答フレームを前記ヘッドに送信することによって前記ヘッドとのLDRリンクを設定することを特徴とする請求項21に記載の通信装置。
【発明の概要】
【発明が解決しようとする課題】
【0004】
本発明の目的は、複数のグループ間の衝突を防止又は減少させながらもデータの信頼性を増加させることのできるマルチキャスト及びブロードキャスト通信方法で、マルチラジオを用いた通信方法及び通信装置を提供することにある。
【課題を解決するための手段】
【0005】
本発明の一態様によれば、通信方法は、
予めHDR(High Data−rate Radio)リンクが設定されたマルチキャスト及びブロードキャスト通信を提供するグループのヘッドとグループに属するノードを含むネットワークシステムにおいて、グループに属する少なくとも1つのノードのLDR(Low Data−rate Radio)の利用可能性を確認し、
LDRが利用可能な場合、前記グループに属する少なくとも1つのノードと
LDRリンクを設定するステップと、前記グループに属する少なくとも1つのノードに
HDRを用いてデータフレームを送信するステップと、前記確認されたLDRの利用可能性に基づいて
LDRが利用可能な場合はLDRを用い、LDRが利用不可の場合はHDRを用いるマルチラジオを用いて前記送信されたデータフレームに対するACKを受信するステップとを有することを特徴とする。
【0006】
前記
LDRリンクを設定するステップは、プロアクティブ方式又はリアクティブ方式のいずれか1つを用いて
LDR情報を取得し、該LDR情報に基づいて前記グループに属する少なくとも1つのノードと
LDRリンクを設定することが好ましい。
前記リンクを設定するステップは、前記グループに属する少なくとも1つのノードから受信されたサービスリクエストフレームに基づいてLDR情報を取得するステップと、前記取得したLDR情報に基づいて前記ノードのLDRの利用可能性を確認するステップと、前記取得したLDR情報に基づいてマルチキャストサービス及びブロードキャストサービスを開始するステップと、前記確認されたLDRの利用可能性に基づいてLDR利用可能なノードとLDRリンクを設定するステップとを含むことが好ましい。
【0007】
前記リンクを設定するステップは、マルチキャストサービス及びブロードキャストサービスを開始するクエリフレームを前記グループに属する少なくとも1つのノードに送信するステップと、前記クエリフレームに対するクエリ応答フレームを受信するステップと、前記クエリ応答フレームに基づいて、前記グループに属する少なくとも1つのノードのLDRの利用可能性を確認するステップと、前記確認されたLDRの利用可能性に基づいてLDR利用可能なノードとLDRリンクを設定するステップとを含むことが好ましい。
前記グループに属する少なくとも1つのノードからチャネルリポートフレームを受信するステップと、前記チャネルリポートフレームに含まれるチャネル情報に基づいてCTSノードを決定するステップと、前記決定されたCTSノードに基づいてRTS及びCTS制御を行うステップとをさらに有することが好ましい。
前記送信したデータフレームに対するACKリクエストフレームを送信するステップをさらに有
し、前記ACKリクエストフレームは、前記確認されたLDRの利用可能性に基づいて、LDRが利用可能な場合はLDRに設定し、LDRが利用不可の場合はHDRに設定するACKラジオ情報及びACKオフセット情報を含むことが好ましい。
前記ACKリクエストフレームを送信するステップは、前記確認されたLDRの利用可能性に基づいてLDRが利用可能な場合はLDRを用い、LDRが利用不可の場合はHDRを用いるよう前記ACKラジオ情報を設定することが好ましい。
【0008】
本発明の一態様によれば、通信装置は、
予めHDR(High Data−rate Radio)リンクが設定されたマルチキャスト及びブロードキャスト通信を提供するグループのヘッドとグループに属するノードを含むネットワークシステムの通信装置において、グループに属する少なくとも1つのノードのLDRの利用可能性を確認し、
LDRが利用可能な場合、前記グループに属する少なくとも1つのノードと
LDRリンクを設定するリンク設定部と、前記グループに属する少なくとも1つのノードに
HDRを用いてデータフレームを送信するデータフレーム送信部と、前記確認されたLDRの利用可能性に基づいて
LDRが利用可能な場合はLDRを用い、LDRが利用不可の場合はHDRを用いるマルチラジオを用いて前記送信されたデータフレームに対するACKを受信するACK受信部とを備えることを特徴とする。
【0009】
前記リンク設定部は、前記グループに属する少なくとも1つのノードから受信されたサービスリクエストフレームを用いてLDR情報を取得し、前記取得したLDR情報に基づいて前記ノードのLDRの利用可能性を確認するLDR情報取得部と、前記取得したLDR情報に基づいてマルチキャストサービス及びブロードキャストサービスを開始し、前記確認されたLDRの利用可能性に基づいてLDR利用可能なノードとLDRリンクを設定するLDRリンク設定部とを含むことが好ましい。
前記リンク設定部は、マルチキャスト及びブロードキャストサービスを開始するクエリフレームを前記グループに属する少なくとも1つのノードに送信し、前記クエリフレームに対するクエリ応答フレームを受信してLDR情報を取得するLDR情報取得部と、前記LDR情報に基づいて前記グループに属する少なくとも1つのノードのLDRの利用可能性を確認し、前記確認されたLDRの利用可能性に基づいてLDR利用可能なノードとLDRリンクを設定するLDRリンク設定部とを含むことが好ましい。
チャネルリポートフレームに含まれたチャネル情報に基づいてCTSノードを決定するCTSノード決定部と、前記決定されたCTSノードに基づいてRTS及びCTS制御を行うRTS/CTS制御部とをさらに備えることが好ましい。
前記送信したデータフレームに対するACKリクエストフレームを送信するACKリクエストフレーム送信部をさらに備え
、前記ACKリクエストフレームは、前記確認されたLDRの利用可能性に基づいて、LDRが利用可能な場合はLDRに設定し、LDRが利用不可の場合はHDRに設定するACKラジオ情報及びACKオフセット情報を含むことが好ましい。
【0010】
本発明の一態様によれば、通信方法は、
予めHDR(High Data−rate Radio)リンクが設定されたマルチキャスト及びブロードキャスト通信を提供するグループのヘッドとグループに属するノードを含むネットワークシステムにおいて、LDR情報を含むフレームをグループのヘッドに送信し
、LDRが利用可能な場合、前記ヘッドと
LDRリンクを設定するステップと、前記リンクが設定されたヘッドから
HDRを用いて送信されたデータフレームを受信するステップと、前記ヘッドからACKリクエストフレームを受信するステップと、前記ACKリクエストフレームに基づいてACKを前記ヘッドに送信するステップとを有することを特徴とする。
【0011】
前記ACKを前記ヘッドに送信するステップは、
LDRが利用可能な場合はLDR
、LDRが利用不可の場合はHD
Rを用いることが好ましい。
少なくとも1つの隣接ヘッドから送信されたビーコン信号を受信するステップと、前記ビーコン信号に基づいて前記隣接ヘッドのチャネル情報を取得するステップと、前記隣接ヘッドのチャネル情報を含むチャネルリポートフレームを前記グループのヘッドに送信するステップとをさらに有することが好ましい。
前記ACKを前記ヘッドに送信するステップは、前記ACKリクエストフレームに含まれたACKオフセット情報に基づいて前記ACKを送信するための送信時点を決定するステップと、前記決定された送信時点にて前記ACKをLDR又はHDRのいずれか1つを用いて前記ヘッドに送信するステップとを含むことが好ましい。
【0012】
本発明の一態様によれば、通信装置は、
予めHDR(High Data−rate Radio)リンクが設定されたマルチキャスト及びブロードキャスト通信を提供するグループのヘッドとグループに属するノードを含むネットワークシステムの通信装置において、LDR情報を含むフレームをグループのヘッドに送信し
、LDRが利用可能な場合、前記ヘッドと
LDRリンクを設定するリンク設定部と、前記リンクが設定されたヘッドからデータフレームを受信するデータフレーム受信部と、前記ヘッドからACKリクエストフレームを受信するACKリクエストフレーム受信部と、前記ACKリクエストフレームに基づいてACKを前記ヘッドに送信するACK送信部とを備えることを特徴とする。
【0013】
前記ACK送信部は、
LDRが利用可能な場合はLDR
、LDRが利用不可の場合はHD
Rを用いて前記ACKを前記ヘッドに送信することが好ましい。
前記リンク設定部は、前記ヘッドからLDRリンクリクエストフレームを受信し、前記LDRリンクリクエストフレームに対するLDRリンク応答フレームを前記ヘッドに送信することによって前記ヘッドとのLDRリンクを設定することが好ましい。
少なくとも1つの隣接ヘッドから送信されたビーコン信号を受信するビーコン信号受信部と、前記ビーコン信号に基づいて前記隣接ヘッドのチャネル情報を取得するチャネル情報取得部と、前記隣接ヘッドのチャネル情報を含むチャネルリポートフレームを前記グループのヘッドに送信するチャネルリポートフレーム送信部とをさらに備えることが好ましい。
【発明の効果】
【0014】
本発明に係るマルチラジオを用いた通信方法及び通信装置によれば、LDRを用いてACKを受信することによって電力消費を減少させ、バッテリ使用時間を増加させることができるという効果がある。
また、HDRを用いてデータフレームを送信することによって大容量マルチメディアストリーミングを提供するだけではなく、LDRを用いてACKを受信してデータの信頼性を向上させることができるという効果がある。
【発明を実施するための形態】
【0016】
以下、添付する図面を参照しながら本発明に係る実施形態を詳細に説明する。
しかし、本発明が実施形態によって制限されたり限定されることはない。
また、各図面に提示された同一の参照符号は同一の部材を示す。
【0017】
図1は、マルチキャスト及びブロードキャスト通信を提供するグループのヘッドとグループに属するノードを含むネットワークシステムを示す図である。
図1において、ヘッド及びノードは、スマートフォン、DMB(Digital Media Broadcasting)フォン、ノート型パソコン、パーソナルコンピュータ(PC)などの移動端末や固定端末を含む。
【0018】
図1に示すように、グループのヘッド(H)10は、グループに属するノードにデータフレームを送信する送信ノードである。そして、ノード(N1〜N3)20〜40は、ヘッド10からデータフレームを受信する受信ノードである。ヘッド10と複数のノード(N1〜N3)20〜40はネットワークを形成している。ここで、ヘッド10及びノード(N1〜N3)20〜40は全てHDRを搭載しており、LDRは選択的に搭載してもよい。言い換えれば、ヘッド10及びノード(N1〜N3)20〜40のうち少なくとも1つはLDRを搭載してもよい。
【0019】
図2は、マルチラジオを用いてマルチキャスト及びブロードキャスト通信を行う工程を説明するためのフローチャートである。
まず、ステップS210において、ヘッド10はグループに属する少なくとも1つのノードとリンクを設定する。
一例として、ヘッド10は、プロアクティブ方式(Proactive Approach)又はリアクティブ方式(Reactive Approach)を用いてリンクを設定する。
ここで、ヘッド10は1つ以上のノードとグループを形成してもよいが、以下、ヘッド10が複数のノードとグループを形成した場合を仮定して説明することにする。
【0020】
次に、ステップS220において、ヘッド10は、グループに属する複数のノードのうち少なくとも1つのノードから受信されたチャネルリポートフレーム(NB_CH_REPORT)に基づいてCTSノードを決定する。
一例として、ヘッド10は、チャネルリポートフレームをLDRを用いて受信する。
ここで、チャネルリポートフレームを送信したノードが複数である場合、ヘッド10は、チャネルリポートフレームを送信したノードのいずれか1つをCTSノードに決定する。これによって、ヘッド10はCTSノードを用いてRTS(Request To Send)/CTS(Clear To Send)制御を行うことができる。
【0021】
そして、ステップS230において、ヘッド10は、グループに属する複数のノードにデータフレームを送信する。
そして、ステップS240において、ヘッド10は、グループに属する複数のノードにACKリクエストフレーム(MR_ACK_REQ)を送信する。
一例として、ヘッド10はデータフレームを送信した後、予め設定された基準時間が経過した時、ACKリクエストフレームを送信する。ここで、ACKリクエストフレームは送信したデータフレームに対するノードの受信確認をリクエストするフレームであり、ラジオ情報及びオフセット情報を含んでもよい。
【0022】
そして、ステップS250において、ヘッド10は、マルチラジオを用いて複数のノードから送信されたACKを受信する。
一例として、ヘッド10は、LDR及びHDRのいずれか1つを用いて送信されたACKを受信する。言い換えれば、ノードがLDRを利用可能な場合にヘッド10は、ノードでLDRを用いて送信したACKを受信する。そして、ノードがLDRを用いることができない場合にヘッド10はノードがHDRを用いて送信したACKを受信する。
【0023】
以下、
図3及び
図4を参照してプロアクティブ方式又はリアクティブ方式を用いてリンクを設定する工程について詳細に説明する。
図3は、プロアクティブ方式を用いてリンクを設定する工程を説明するためのフローチャートである。
プロアクティブ方式は、ヘッドがノードにマルチキャストサービスを提供する前にノードのLDR情報を取得する方式を意味する。
図3においては、ヘッドと複数のノードとの間にHDRリンクは予め設定された状態であることを仮定する。
【0024】
まず、
図3及び
図8を参照すれば、ステップS310において、LDR情報取得部811は、サービスリクエストフレーム(ASSOCIATION_REQ)を受信する。
ここで、LDR情報取得部811は、HDRを用いてサービスリクエストフレームを受信する。言い換えれば、LDR情報取得部811は、ノードに搭載されたHDRを用いて送信されたサービスリクエストフレームをヘッドに搭載されたHDRを用いて受信する。ここで、サービスリクエストフレームは、サービスをリクエストするノードのLDR情報を含んでもよい。
【0025】
一例として、LDRを搭載した場合、サービスをリクエストするノードは、LDR MACアドレスを含むLDR情報をヘッドに送信する。
そして、ノードにLDRが搭載されていない場合、ノードはLDR情報を「0」に設定してヘッドに送信する。
【0026】
次に、ステップS320において、LDR情報取得部811は、サービスリクエストフレームを用いてLDR情報を取得することによって、ノードのLDRの利用可能性を確認する。
一例として、LDR情報取得部811は、サービスリクエストフレームでLDR情報を分離する。そして、分離されたLDR情報がLDR MACアドレスを含む場合、LDR情報取得部811はノードがLDRを利用可能であると確認することができる。ここで、分離されたLDR情報が「0」と設定された場合、LDR情報取得部811はノードがLDRを搭載しないものと確認する。
【0027】
そして、ステップS330において、LDR情報取得部811は、サービスリクエストフレームを送信したノードにサービス応答フレーム(ASSOCIATION_REP)を送信する。
ここで、LDR情報取得部811は、サービス応答フレームをHDRを用いて送信する。このように、サービスリクエスト応答フレームが受信されることによって、ヘッドとノードとの間にはマルチキャスト及びブロードキャストサービスが開始される。
【0028】
次に、ステップS340において、LDRリンクリクエスト部812は、確認されたLDRの利用可能性に基づいてLDR接続リクエストフレームを送信する。
一例として、LDRリンクリクエスト部812は、LDR MACアドレスを用いてLDRが利用可能であると確認されたノードにLDRリンクリクエストフレームを送信する。そして、LDRリンクリクエスト部812は、搭載されたLDRを用いてLDRリンクリクエストフレームを送信する。
【0029】
ここで、LDRを利用可能なノードが複数である場合、LDRリンクリクエスト部812は、LDRを利用可能なノードに順次LDRリンクリクエストフレームを送信してもよい。言い換えれば、LDRとしてブルートゥース(登録商標)が用いられ、HDRとしてWLANが用いられる場合、LDRリンクリクエスト部812は、ブルートゥース(登録商標)を用いてLDR接続リクエストフレームを送信してもよい。このようにLDRを用いてヘッドとノードとの間にLDRリンクを設定することによって、インクエリプロセス(inquiry process)をスキップする。これによって、迅速にLDR接続を設定することができる。
【0030】
そして、ステップS350において、LDRリンクリクエスト部812は、LDRリンク応答フレームを受信することによってLDRリンクを設定する。
ここで、LDRリンクリクエスト部812はLDRを用いてLDR接続応答フレームを受信する。ここで、LDRリンク応答フレームはACCEPTフレーム又はREJECTフレームを含む。
【0031】
一例として、LDR設定リクエストフレームを受信したノードはLDRを搭載した場合、ACCEPTフレームをLDRを用いてヘッドに送信する。
他の例として、LDRを搭載したとしてもLDRを用いることが難しい場合、ノードはREJECTフレームをLDRを用いてヘッドに送信する。これによって、LDRリンクリクエスト部812は、REJECTフレームを受信することでノードがLDRを用いることが難しい状態であることを確認できる。
【0032】
図4は、リアクティブ方式を用いてリンクを設定する工程を説明するためのフローチャートである。
リアクティブ方式は、マルチキャストサービスを提供する前にヘッドとグループに属するノード間にいずれの情報も交換しない方式を意味する。
図4において、ヘッドと複数のノードとの間にHDRリンクは予め設定された状態であると仮定する。
【0033】
まず、
図4及び
図8を参照すれば、ステップS410において、LDR情報取得部811は、クエリフレーム(LDR_QUERY)をHDRを用いてグループに属する複数のノードに送信する。
一例として、
図1を参照すれば、ヘッド10と、ノード(N1)20、ノード(N2)30、及びノード(N3)30がグループを形成する場合、LDR情報取得部811は、クエリフレームをノード(N1)〜ノード(N3)に送信する。ここで、LDR情報取得部811は、マルチキャスト及びブロードキャストサービスを開始した後、クエリフレームを送信する。
【0034】
次に、ステップS420において、LDR情報取得部811は、グループに属する複数のノードで送信したクエリ応答フレーム(LDR_QUER_REP)を受信する。
ここで、クエリ応答フレームはLDR情報を含んでもよい。
一例として、ノードがLDRを搭載した場合、ノードは、LDR MACアドレスを含むLDR情報をクエリ応答フレームに挿入してヘッドに送信する。ここで、LDRを搭載していない場合、ノードは「0」に設定したLDR情報をクエリ応答フレームに挿入して送信する。
【0035】
そして、ステップS430において、LDR情報取得部811はクエリ応答フレームを受信し、受信されたクエリ応答フレームでLDR情報を取得する。
ここで、LDR情報取得部811は、LDR情報に基づいてノードのLDRの利用可能性を確認する。
一例として、LDR情報取得部811は、LDR情報にLDR MACアドレスが含まれた場合、ノードがLDRを利用可能であると確認する。そして、LDR情報が「0」に設定された場合、LDR情報取得部811はノードがLDRを搭載しないと確認する。
【0036】
次に、ステップS440において、LDRリンクリクエスト部812は、確認されたノードのLDRの利用可能性に基づいてLDRリンクリクエストフレーム(LDR_CONN_REQ)を送信する。
一例として、LDRリンクリクエスト部812は、LDR MACアドレスを用いてLDRを利用可能であると確認されたノードにLDRリンクリクエストフレームを送信する。そして、LDRリンクリクエスト部812は、搭載されたLDRを用いてLDR接続リクエストフレームを送信する。このように、リアクティブ方式を用いる場合にもLDRを用いてリンクレベルのLDR接続をリクエストすることによってインクエリプロセスをスキップすることができる。
【0037】
そして、ステップS450において、LDRリンクリクエスト部812は、LDRリンク応答フレームを受信することによってLDRリンクを設定する。
ここで、LDRリンクリクエスト部812は、LDRを用いてLDRリンク応答フレームを受信する。ここで、LDRリンク応答フレームは、ACCEPTフレーム又はREJECTフレームを含んでもよい。
一例として、LDRを搭載した場合、LDR接続リクエストフレームを受信したノードは、ACCEPTフレームをLDRを用いてヘッドに送信する。他の例として、LDRを搭載したとしてもLDRを用いることが難しい場合、ノードはREJECTフレームをLDRを用いてヘッドに送信する。
【0038】
これによって、ヘッドは、グループに属する複数のノードのうちACCEPTフレームを送信したノードとはLDR接続を設定することができる。
すると、LDRリンクを設定したノード及びヘッドは、HDR及びLDRのうち少なくとも1つを用いてマルチキャスト及びブロードキャスト通信を行うことができる。
そして、REJECTフレームを送信したノード及びヘッドはHDR接続を維持することができる。
【0039】
図5及び
図6は、グループに属する複数のノードのうちCTSノードを決定する工程を説明するための図である。
図5に示す符号510を参照すると、ヘッド(H1)511は、ノード(N1)〜ノード(N3)512〜514とグループを形成し、ヘッド(H2)515はノード(N4)〜ノード(N6)516〜518とグループを形成している。
【0040】
ここで、ヘッド(H2)515は、ヘッド(H1)511に隣接する隣接ヘッドである。
そして、ノード(N3)514は、ヘッド(H2)515で送信したビーコン信号を受信できる地域に位置している。これによって、ノード(N3)514は自身のグループのヘッド(H1)511から送信される信号のみならず、ヘッド(H2)515から送信された信号によって干渉を受けることがある。
【0041】
同様に、ノード(N4)516は、自身のグループのヘッド(H2)515から送信される信号のみならず、ヘッド(H1)511から送信された信号によって干渉を受けることがある。
このような干渉を減少又は除去するために、各グループのヘッドはCTSノードを決定し、決定されたCTSノードを用いてRTS(Request To Send)/CTS(Clear To Send)制御を行う。
【0042】
以下、
図6を参照してCTSノードを決定する構成についてより詳細に説明する。
図6において、ノード1〜ノード3(120〜140)はヘッド110と同一のグループを形成する。
そして、ノード1(120)及びノード2(130)は、
図5に示す符号520のように、隣接ヘッドで送信したビーコン信号を受信して干渉を受けるノードであり、ノード3(140)は、隣接ヘッドから干渉を受けないノードであることと仮定する。
【0043】
まず、
図6を参照すると、ノード1〜ノード3(120〜140)は、周辺に他のマルチキャストグループが存在するかを周期的に探索することができる。
ここで、ステップS610において、ノード1(120)及びノード2(130)は、隣接ヘッド150から送信したビーコン信号を受信する。
一例として、ノード1(120)及びノード2(130)は、HDRを用いて隣接ヘッド150から送信したビーコン信号を受信する。
【0044】
そして、ステップS620において、ノード1(120)及びノード2(130)は、受信したビーコン信号に基づいて隣接ヘッドのチャネル情報をそれぞれ取得する。
ここで、チャネル情報は、隣接ヘッドの識別情報及びRSSI(Received Signal Strength Indicator)情報を含んでもよい。ここで、隣接ヘッドの識別情報は、隣接ヘッドが属するグループを識別するためのIDを含んでもよい。そして、RSSI情報はHDRを介して受信された信号の強度を意味する。
【0045】
次に、ステップS630において、ノード1(120)及びノード2(130)は、取得したチャネル情報を含むチャネルリポートフレーム(NB_CH_REPORT)を生成してヘッド110にそれぞれ送信する。
一例として、ヘッド110とLDRリンクが設定された場合、ノード1(120)及びノード2(130)は、LDRを用いてチャネルリポートフレームをそれぞれ送信する。ここで、LDRリンクが設定されていない場合、ノード1(120)及びノード2(130)は、HDRを用いてチャネルリポートフレームをそれぞれ送信してもよい。これによって、ヘッド110は、ノード1(120)及びノード2(130)それぞれとのLDRリンク設定に基づいてLDR又はHDRを介してチャネルリポートフレームを受信する。
【0046】
そして、ステップS640において、ヘッド110は、ノード1(120)及びノード2(130)でそれぞれ送信したチャネルリポートフレームからチャネル情報をそれぞれ抽出し、抽出されたチャネル情報を用いてCTSノードを決定する。
ここで、ヘッド110は、抽出したチャネル情報に基づいてノード1(120)のRSSI情報とノード2(130)のRSSI情報とを比較し、比較結果、高いRSSIを有するノードをCTSノードに決定する。
【0047】
一例として、
図5に示す符号520を参照すれば、ノード(N1)522のRSSIがノード(N2)523のRSSIよりも高い場合、ヘッド521はノード(N1)522をCTSノードに決定する。
他の例として、
図5に示す符号510を参照すれば、チャネルリポートフレームを送信したノードが1つである場合、ヘッド511はチャネルリポートフレームを送信したノード(N3)514をCTSノードに決定してもよい。
【0048】
次に、ステップS650において、ヘッド110は、RTSパケットをグループに属する複数のノードにブロードキャストする。
これによって、複数のノードはRTSパケットを受信する。
一例として、ヘッド110はノード1〜ノード3(120〜140)にRTSパケットをブロードキャストする。ここで、RTSパケットは、決定されたCTSノード情報を含んでもよい。そして、CTSノード情報は、CTSノードに決定されたノードを識別するためのノードIDを意味する。
ここで、複数のグループごとにCTSノードがそれぞれ決定された場合、RTSパケットはCTS送信情報をさらに含んでもよい。ここで、CTS送信情報は、CTSノードでCTSパケットをブロードキャストする送信順序を意味する。
【0049】
そして、ステップS660において、CTSノードに決定されたノード1(120)はCTSパケットをブロードキャストする。
一例として、ヘッド110とグループを形成しているノード1〜ノード3(120〜140)はRTSパケットを受信する。そして、ノード1〜ノード3(120〜140)は、RTSパケットからCTSノード情報を抽出してもよい。ここで、ノード2(130)及びノード3(140)は、CTSノード情報に基づいて自身がCTSノードと決定されないことを確認することができる。
そして、ノード1(120)は、抽出されたCTSノード情報に基づいて自身がCTSノードと決定されたことを確認することができる。これによって、ノード1(120)は、CTS送信情報に基づいてCTSパケットをブロードキャストする。
【0050】
そして、ステップS670において、隣接ヘッド150は、ノード1(120)からブロードキャストされたCTSパケットを受信する。
その後、ステップS680において、隣接ヘッド150は、データフレームの送信を所定の時間の間中止する。
これによって、ノード1(120)は、隣接ヘッド150及び自身が属するグループのヘッド110で送信したデータフレームの衝突を防止することができる。
【0051】
図7は、マルチラジオを用いてデータフレームに対するACKを受信する工程を説明するためのフローチャートである。
まず、
図7及び
図8を参照すると、ステップS710において、ヘッド110は、データフレームをグループに属する複数のノードにデータフレームを送信する。
一例として、
図6を参照して説明したように、隣接ヘッドによるデータ衝突を防止するためにRTS/CTS制御が完了すれば、ヘッド110はデータフレームを送信する。ここで、ヘッド110はHDRを用いてデータフレームを送信する。
【0052】
次に、ステップS720において、ヘッド110は、送信したデータフレームに対するACKリクエストフレーム(MR_ACK_REQ)をグループに属する複数のノードに送信する。
ここで、ヘッド110はHDRを用いてACKリクエストフレームを送信する。
ここで、ACKリクエストフレームは、ACKラジオ情報及びACKオフセット情報を含んでもよい。そして、ヘッド110は、ノードのLDRの利用可能性に基づいてACKラジオ情報をLDR又はHDRのいずれか1つとして設定してもよい。ACKラジオ情報は、LDR又はHDRのいずれかのラジオを介してACKを送信するかをノードに通知する情報を意味する。
【0053】
そして、ACKオフセット情報は、ACKをいつ送信するかをノードに通知する情報を意味する。
ここで、ACKオフセット情報は、ACKリクエストフレームを送信した時点を基準とするオフセット値を含んでもよい。
一例として、ACKオフセット情報が「a」秒である場合、ACKリクエストフレームを送信した時点に基づいて「a」秒後にノードでACKを送信することを意味する。
【0054】
これによって、ステップS730において、ヘッド110は、グループに属する複数のノードそれぞれからマルチラジオを用いてACKを受信する。
一例として、ノード1及びノード2は、LDRリンクを設定し、ノード3は、LDRリンクを設定していない場合、ヘッド110はACKラジオ情報をLDRに設定したACKリクエストフレームをノード1及びノード2に送信する。
そして、ヘッド110は、ACKラジオ情報をHDRと設定したACKリクエストフレームをノード3に送信する。これによって、ヘッド110は、ノード1及びノード2でLDRを用いて送信したACKをそれぞれ受信し、ノード3でHDRを用いて送信したACKを受信することができる。
【0055】
図8は、LDR情報を受信する通信装置の構成を示すブロック図である。
図8に示す通信装置は、グループのヘッドを意味する。
そして、ヘッドとグループに属する複数のノード間にはHDR接続が予め設定されたことと仮定する。
【0056】
図8に示すように、通信装置800は、リンク設定部810、CTSノード決定部820、RTS/CTS制御部830、データフレーム送信部840、ACKリクエストフレーム送信部850、及びACK受信部860を備える。
【0057】
リンク設定部810は、LDR情報取得部811及びLDRリンクリクエスト部812を備える。
ここで、リンク設定部810は、プロアクティブ方式及びリアクティブ方式のいずれか1つを用いてグループに属する少なくとも1つのノードとリンクを設定する。
一例として、プロアクティブ方式を用いる場合、LDR情報取得部811は、サービスリクエストフレームからLDR情報を抽出することによってLDR情報を取得する。ここで、LDR情報は、サービスリクエストフレームを送信したノードのLDR MACアドレス又は「0」を含んでもよい。これによって、LDR情報取得部811は、取得したLDR情報に基づいてノードのLDRの利用可能性を確認する。
【0058】
他の例として、リアクティブ方式を用いる場合、LDR情報取得部811は、クエリフレームを用いて取得したLDR情報に基づいてノードのLDRの利用可能性を確認する。
これによって、LDRリンクリクエスト部812は、確認されたノードの利用可能性に基づいてLDRを利用可能なノードにリンクリクエストフレームを送信する。そして、LDRリンクリクエスト部812は、LDRリンクリクエストフレームに対するLDRリンク応答フレームを受信することによってLDRリンクを設定する。このように、リンク設定部810は、グループに属する複数のノードのLDRの利用可能性を確認し、LDRを利用可能なノードとリンクを設定する。
【0059】
CTSノード決定部820は、チャネルリポートフレームでチャネル情報を抽出し、チャネル情報を用いてグループに属するノードのうちCTSノードを決定する。
ここで、チャネル情報は、隣接ヘッドの識別情報及びRSSI(Received Signal Strength Indicator)情報を含む。ここで、CTSノード決定部820は、ノードでLDRを用いて送信されたチャネルリポートフレームを受信する。
一例として、チャネルリポートフレームを送信したノードが複数である場合、CTSノード決定部820はRSSIが最も高いノードをCTSノードに決定する。
他の例として、チャネルリポートフレームを送信したノードが1つである場合、CTSノード決定部820は、チャネルリポートフレームを送信したノードをCTSノードに決定する。
【0060】
これによって、RTS/CTS制御部830は、RTSパケットをグループに属する複数のノードにブロードキャストする。
ここで、RTSパケットは決定されたCTSノード情報を含む。そして、CTSノード情報は、CTSノードに決定されたノードを識別するためのノードIDを意味する。そして、CTSノードは、RTSパケットに基づいて自身がCTSノードとして決定されることを確認し、CTSパケットをブロードキャストする。これによって、CTSパケットを受信した隣接ヘッドは、所定の時間の間、データフレーム送信を中止する。
ここで、RTS/CTS制御を行う工程については
図6を参照して詳細に説明したため、繰り返しの説明は省略する。
【0061】
そして、データフレーム送信部840は、グループに属する複数のノードにデータフレームを送信する。
ここで、データフレーム送信部840は、HDRを用いてデータフレームを送信する。
【0062】
次に、ACKリクエストフレーム送信部850は、送信したデータフレームに対するACKリクエストフレームをグループに属する複数のノードに送信する。
ここで、ACKリクエストフレーム送信部850は、HDRを用いてACKリクエストフレームを送信する。ここで、ACKリクエストフレームは、ACKラジオ情報及びACKオフセット情報を含んでもよい。
【0063】
一例として、ACKリクエストフレーム送信部850は、ノードのLDRの利用可能性に基づいてACKラジオ情報をLDR又はHDRのいずれか1つとして設定してもよい。そして、ノードごとにACKラジオ情報が設定されたACKリクエストフレームをグループに属する複数のノードにそれぞれ送信する。
【0064】
ACK受信部860は、送信したデータフレームに対するACKをマルチラジオを用いて受信する。
一例として、ACK受信部860は、ACKラジオ情報に基づいてLDR又はHDRを用いて送信されたACKを受信する。ここで、グループに属する複数のノードは、ACKオフセット情報に基づいて互いに異なる送信時点にACKをそれぞれ送信する。これによって、LDR又はHDRを用いたACK送信は並列に行われるため、各ラジオのACK送信時点は他のラジオの送信時点にその影響を与えない。
【0065】
図9は、LDR情報を送信する通信装置の構成を示すブロック図である。
図9に示す通信装置はグループに属するノードを意味する。
そして、ヘッドとグループに属する複数のノード間にはHDR接続が予め設定されたことと仮定する。
【0066】
図9に示すように、通信装置900は、リンク設定部910、ビーコン信号受信部920、チャネル情報取得部930、チャネルリポートフレーム送信部940、RTS/CTS制御部950、データフレーム受信部960、及びACK送信部970を備える。
【0067】
リンク設定部910は、LDR情報を含むフレームをグループのヘッドに送信してヘッドとリンクを設定する。
ここで、リンク設定部910は、プロアクティブ方式又はリアクティブ方式を用いてヘッドとリンクを設定してもよい。ここで、LDR情報はLDR MACアドレス又は「0」を含んでもよい。
一例として、リンク設定部910はLDRを搭載した場合、LDR情報をLDR MACアドレスに設定し、LDR情報が設定されたフレームをグループのヘッドに送信する。ここで、LDR情報が設定されたフレームはサービスリクエストフレーム又はクエリ応答フレームを含んでもよい。
他の例として、リンク設定部910はLDRを搭載していない場合、LDR情報を「0」に設定し、LDR情報が設定されたフレームをグループのヘッドに送信する。
【0068】
そして、LDRリンクリクエストフレームを受信した場合、リンク設定部910は、LDRリンク応答フレームをヘッドに送信することによってヘッドとのLDRリンクを設定する。
ここで、LDRリンク応答フレームは、ACCEPTフレーム又はREJECTフレームを含んでもよい。ここで、LDRを利用可能な場合、リンク設定部910は、LDRを用いてACCETフレームをヘッドに送信する。そして、LDRを搭載したとしてもLDRを用いることが難しい場合、リンク設定部910は、LDRを用いてREJECTフレームをヘッドに送信する。
【0069】
ビーコン信号受信部920は、隣接ヘッドから送信されたビーコン信号を受信する。
チャネル情報取得部930は、受信されたビーコン信号に基づいて隣接ヘッドのチャネル情報を取得する。
ここで、チャネル情報は、隣接ヘッドの識別情報及びRSSI(Received Signal Strength Indicator)情報を含んでもよい。ここで、隣接ヘッドの識別情報は、隣接ヘッドが属するグループを識別するためのIDを含んでもよい。
【0070】
チャネルリポートフレーム送信部940は、隣接ヘッドのチャネル情報を含むチャネルリポートフレームをグループのヘッドに送信する。
ここで、LDRリンクが設定された場合、チャネルリポートフレーム送信部940はLDRを用いてチャネルリポートフレームを送信する。そして、LDRリンクが設定されていない場合、チャネルリポートフレーム送信部940はHDRを用いてチャネルリポートフレームをヘッドに送信する。
【0071】
RTS/CTS制御部950は、ヘッドからRTSパケットを受信してCTSノード情報を抽出する。
そして、RTS/CTS制御部950は、抽出したCTSノード情報に基づいて通信装置900がCTSノードとして決定されたか否かを確認する。
ここで、通信装置900がCTSノードとして決定された場合、RTS/CTS制御部950はCTSパケットをブロードキャストする。これによって、CTSパケットを受信した隣接ヘッドはデータフレームを所定の時間の間中止する。このように、RTS/CTS制御部950はRTS/CTS制御を行うことによって、隣接ヘッドから送信されたデータフレームによる衝突を防止することができる。
【0072】
データフレーム受信部960は、ヘッドから送信されたデータフレームを受信する。
ここで、データフレーム受信部960は、RTS/CTS制御が完了した後、HDRを用いてデータフレームを受信する。
そして、データフレーム受信部960は、データフレームを受信した後、ヘッドから送信されたACKリクエストフレームを受信する。ここで、ACKリクエストフレームは、ACKラジオ情報及びACKオフセット情報を含んでもよい。
【0073】
ACK送信部970は、ACKオフセット情報に基づいてACKの送信時点を算出する。
ここで、ACK送信部970は、ヘッドからACKリクエストフレームが送信された時点に基づいてACKオフセット情報を演算してACK送信時点を算出することができる。
そして、ACK送信部970は、ACKラジオ情報に基づいてLDR又はHDRのいずれか1つを用いてACK送信時点でACKをヘッドに送信する。
【0074】
これによって、ヘッドはグループに属する複数の各ノードで互いに異なるラジオを用いて送信されたACKを受信する。
一例として、ヘッドは、ノード1及びノード2でLDRを用いて送信されたACKを受信し、ノード3でHDRを用いて送信されたACKを受信してもよい。
【0075】
上記本発明の実施形態に係る方法は、多様なコンピュータ手段を介して様々な処理を実行することができるプログラム命令の形態で実現され、コンピュータ読取可能な記録媒体に記録することができる。
コンピュータ読取可能な媒体は、プログラム命令、データファイル、データ構造などのうちの1つ又はその組み合わせを含んでもよい。
記録媒体に記録されるプログラム命令は、本発明の目的のために特別に設計されて構成されたものでもよく、コンピュータソフトウェア分野の技術を有する当業者にとって公知のものであり、使用可能なものであってもよい。
【0076】
コンピュータ読取可能な記録媒体の例としては、ハードディスク、フロッピー(登録商標)ディスク、及び磁気テープのような磁気媒体、CD−ROM、DVDのような光記録媒体、光ディスクのような光磁気媒体、及びROM、RAM、フラッシュメモリなどのようなプログラム命令を保存して実行するように特別に構成されたハードウェア装置が含まれる。
プログラム命令の例としては、コンパイラによって生成されるような機械語コード(machine code)だけでなく、インタプリタなどを用いてコンピュータによって実行され得る高級言語コード(higher level code)を含む。上述したハードウェア装置は、本発明の動作を行うために1つ以上のソフトウェアのレイヤで動作するように構成されてもよい。
【0077】
上述したように、本発明を限定された実施形態と図面によって説明したが、本発明は、上記の実施形態に限定されることなく、本発明が属する分野における通常の知識を有する者であれば、このような実施形態から多様な修正及び変形が可能である。
したがって、本発明の範囲は、開示された実施形態に限定されるものではなく、特許請求の範囲だけではなく特許請求の範囲と均等なものなどによって定められるものである。