JP6787324B2 - 通信制御装置、通信制御方法、プログラム、及びシステム - Google Patents

Description

本開示は、通信制御装置、通信制御方法、及びプログラムに関する。

近年、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１に代表される無線ＬＡＮ（Local Area Network）の普及が進み、それに伴い、無線ＬＡＮに対応した無線通信装置が増加している。また、このような無線通信装置間の通信に関する技術の一例として、複数の無線通信装置に対して同一のデータを同時に配信する、所謂マルチキャスト（Multicast）と呼ばれる技術についても検討されている。

また、ＩＥＥＥ８０２．１１等の規格では、無線通信装置間の通信においては、送信元となる無線通信装置からデータを送信した場合に、送信されたデータが送信先となる無線通信装置に送達したか否かを確認するための技術が提案されている。送信元となる無線通信装置は、このような技術を利用することで、例えば、データの送達が確認されていない送信先となる無線通信装置に対して、当該データを再送することで、通信品質の低下を防止することも可能となる。例えば、特許文献１には、データの送信元となる無線通信装置が、送信先となる無線通信装置へのデータの送達を確認するための技術の一例が開示されている。

特開２０１４−５３８３２号公報

ここで、マルチキャストのような、複数の無線通信装置に対するデータの送信に際し、送信先となる無線通信装置への当該データの送達を確認する場合に着目する。この場合には、データの送達を確認する無線通信端末の数が多いほど、当該通信の信頼性は向上する傾向にある。

その一方で、複数の無線通信装置に対してデータの送達を確認する場合には、当該送達の確認のために複数の通信が発生し、当該通信により通信リソースが消費されることとなる。そのため、無線通信装置間の通信の状態によっては、データの送達を確認する無線通信端末の数が増大すると、当該送達の確認により無線通信装置間の通信が圧迫され、結果として通信品質が低下する場合がある。

そこで、本開示では、通信の状態に応じて、より好適な態様で信頼性を担保し、かつ通信リソースの消費を抑制することが可能な、通信制御装置、通信制御方法、及びプログラムを提案する。

本開示によれば、無線の通信経路を介して接続された通信装置との間の通信を制御する制御部と、１以上の前記通信装置との間の前記通信に関する情報を取得する取得部と、を備え、前記制御部は、取得された前記通信に関する情報に基づき、前記通信装置に対するデータの送達を確認するための応答の送信要求を送信する当該通信装置を決定する、通信制御装置が提供される。

また、本開示によれば、無線の通信経路を介して接続された通信装置との間の通信に関する情報に応じて、データの送達を確認するための応答の送信要求の送信先に決定された場合に、前記通信装置から送信された前記送信要求を取得する取得部と、取得された前記送信要求に対する、前記データの受信状況に応じた前記応答が、前記通信装置に送信させるように制御する制御部と、を備える、通信制御装置が提供される。

また、本開示によれば、プロセッサが、無線の通信経路を介して接続された通信装置との間の通信を制御することと、１以上の前記通信装置との間の前記通信に関する情報を取得することと、取得された前記通信に関する情報に基づき、前記通信装置に対するデータの送達を確認するための応答の送信要求を送信する当該通信装置を決定することと、を含む、通信制御方法が提供される。

また、本開示によれば、無線の通信経路を介して接続された通信装置との間の通信に関する情報に応じて、データの送達を確認するための応答の送信要求の送信先に決定された場合に、前記通信装置から送信された前記送信要求を取得することと、プロセッサが、取得された前記送信要求に対する、前記データの受信状況に応じた前記応答が、前記通信装置に送信させるように制御することと、を含む、通信制御方法が提供される。

また、本開示によれば、コンピュータに、無線の通信経路を介して接続された通信装置との間の通信を制御することと、１以上の前記通信装置との間の前記通信に関する情報を取得することと、取得された前記通信に関する情報に基づき、前記通信装置に対するデータの送達を確認するための応答の送信要求を送信する当該通信装置を決定することと、を実行させる、プログラムが提供される。

また、本開示によれば、コンピュータに、無線の通信経路を介して接続された通信装置との間の通信に関する情報に応じて、データの送達を確認するための応答の送信要求の送信先に決定された場合に、前記通信装置から送信された前記送信要求を取得することと、
取得された前記送信要求に対する、前記データの受信状況に応じた前記応答が、前記通信装置に送信させるように制御することと、を実行させる、プログラムが提供される。

以上説明したように本開示によれば、通信の状態に応じて、より好適な態様で信頼性を担保し、かつ通信リソースの消費を抑制することが可能な、通信制御装置、通信制御方法、及びプログラムが提供される。

なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

本開示の一実施形態に係る通信制御装置および通信装置で構成される通信システムを例示する図である。 親局が複数の子機に対してデータをマルチキャストし、当該データの送達確認を行う場合の処理の流れの一例について説明するための説明図である。 ＢＡＲの宛先となる子機の数とパケットロスレートとの関係の一例を示したグラフである。 ＢＡＲの宛先となる子機の数と遅延時間との関係の一例を示したグラフである。 本開示の第１の実施形態に係る通信装置の概略的な機能構成を示すブロック図である。 同実施形態に係る親局が、チャネルの混雑度の観測結果に応じてＢＡＲ宛先数を決定するための制御テーブルの一例である。 複数の子機を宛先としてＢＡＲを送信するためのＤＬフレームの構造の一例を示した図である。 同実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。 同実施形態に係る通信システムにおいて、親局として動作する通信装置の一連の動作の流れの一例を示したフローチャートである。 同実施形態に係る親局による、ＢＡＲ宛先数の決定に係る処理の一例を示したフローチャートである。 同実施形態に係る通信システムにおいて、子機として動作する通信装置の一連の動作の流れの一例を示したフローチャートである。 同実施形態の変形例に係る通信システムの処理シーケンスの一例について説明するための説明図である。 同実施形態の変形例に係る親局が、データの送信までに要した時間に応じて、ＢＡＲ宛先数を決定するための制御テーブルの一例である。 同実施形態の変形例に係る親局による、ＢＡＲ宛先数の決定に係る処理の一例を示したフローチャートである。 本開示の第２の実施形態に係る通信システムにおいて、親局が子機に対して、ＢＡＲの宛先の候補とする子機の条件を通知するためのフレームの構造の一例を示した図である。 同実施形態に係る通信システムにおいて、子機が親局に対して、自身をＢＡＲの宛先とすることを要請するためのフレームの構造の一例を示した図である。 同実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。 同実施形態に係る通信システムにおいて、親局として動作する通信装置の一連の動作の流れの一例を示したフローチャートである。 同実施形態に係る親機による、ＢＡＲ宛先候補条件の決定に係る処理の一例を示したフローチャートである。 同実施形態に係る通信システムにおいて、子機として動作する通信装置の一連の動作の流れの一例を示したフローチャートである。 同実施形態の変形例に係る通信システムの処理シーケンスの一例について説明するための説明図である。 同実施形態の変形例に係る親局による、ＢＡＲ宛先候補条件の決定に係る処理の一例を示したフローチャートである。 本開示の第３の実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。 同実施形態に係る通信システムにおいて、親局として動作する通信装置の一連の動作の流れの一例を示したフローチャートである。 同実施形態に係る親機による、ＢＡＲの宛先とする子機の決定に係る処理の一例を示したフローチャートである。 同実施形態に係る通信システムにおいて、子機として動作する通信装置の一連の動作の流れの一例を示したフローチャートである。 本開示の第４の実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。 本開示の第５の実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。 スマートフォンの概略的な構成の一例を示すブロック図である。 カーナビゲーション装置の概略的な構成の一例を示すブロック図である。 無線アクセスポイントの概略的な構成の一例を示すブロック図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．本開示の一実施形態に係る通信システムの概要
２．マルチキャストにおける送達確認に関する検討
３．第１の実施形態：チャネルの混雑度に基づくＢＡＲの宛先数の決定
３−１．装置の構成
３−２．装置の処理
３−３．変形例
３−４．まとめ
４．第２の実施形態：子機側からの要請に基づくＢＡＲの宛先の決定
４−１．装置の構成
４−２．装置の処理
４−３．変形例
４−４．まとめ
５．第３の実施形態：子機側でチャネルの混雑度を測定する態様
５−１．装置の構成
５−２．装置の処理
５−３．まとめ
６．第４の実施形態：親局側の通信状態に応じたＢＡＲの宛先の決定
６−１．装置の構成
６−２．装置の処理
６−３．まとめ
７．第５の実施形態：子機側の通信状態に応じたＢＡＲの宛先の決定
７−１．装置の構成
７−２．装置の処理
７−３．まとめ
８．応用例
９．むすび

＜１．本開示の一実施形態に係る通信システムの概要＞
まず、図１を参照して、本開示の一実施形態に係る通信制御装置および通信装置の概要について説明する。図１は、本開示の一実施形態に係る通信制御装置および通信装置で構成される通信システムを例示する図である。なお、以下では、通信制御装置および通信装置をまとめて通信装置とも称する。

通信システムは、複数の通信装置１０で構成される。通信装置１０は、無線通信機能を有し、多重化を用いた通信を行う。また、通信装置１０は、所謂アクセスポイント（以下、「ＡＰ（Access Point）」とも称する）として動作し、または端末（以下、「ＳＴＡ（Station）」とも称する）として動作する。以下、ＡＰとして動作する通信装置を親局、端末として動作する通信装置を子機とも称する。このため、通信システムでは、親局と子機との間で多重化を用いた１対多の通信が可能である。なお、親局から子機への通信をＤＬ（ダウンリンク）通信、子機から親局への通信をＵＬ（アップリンク）通信とも称する。

例えば、通信システムは、図１に示したように、複数の通信装置１０＃０〜１０＃Ｎを備える。親局である通信装置１０＃０と子機である通信装置１０＃１〜１０＃Ｎとは、無線通信を介して接続され、直接的に互いにフレームの送受信を行う。

また、親局である通信装置１０＃０は、所謂マルチキャスト（Multicast）と呼ばれる技術に基づき、複数の子機（例えば、通信装置１０＃１〜１０＃Ｎ）に対して、同一のデータを同時に送信することが可能である。

また、親局である通信装置１０＃０と、子機である通信装置１０＃１〜１０＃Ｎとは、ＩＥＥＥ８０２．１１に準拠する通信装置であって、例えば、送信元である親局は、送信したデータの子機への送達を確認することが可能である。具体的には、親局は、データの送信先である子機から、送達確認を示すＡｃｋまたはＢＡ（Block Ack）が返送されるか否かを確認することで、当該データが送信先である子機に正しく送達したか否かを確認する。このような仕組みを利用することで、親局は、例えば、データの少なくとも一部の送達が確認できなかった子機に対して対象となるデータを再送することにより、通信品質の低下を防止する（換言すると、通信の信頼性を向上させる）ことも可能となる。

以上、図１を参照して、本開示の一実施形態に係る通信制御装置および通信装置の概要について説明した。

＜２．マルチキャストにおける送達確認に関する検討＞
ここで、親局である通信装置１０＃０が、複数の子機（例えば、通信装置１０＃１〜１０＃Ｎ）に対して、同一のデータを送信する場合（即ち、マルチキャストする場合）における、当該データの送達の確認に係る動作の一例について説明したうえで、本実施形態に係る通信システムの課題について整理する。

例えば、図２は、親局が複数の子機に対してデータをマルチキャストし、当該データの送達確認を行う場合の処理の流れの一例について説明するための説明図である。なお、図２において、横軸は時間を示している。また、以降の説明では、マルチキャストされるデータを、「マルチキャストデータ」と称する場合がある。

具体的な一例として、親局である通信装置１０＃０は、マルチキャストデータの送信後に、子機（例えば、信装置１０＃１〜１０＃Ｎの少なくともいずれか）に対して送達確認要求（以下、「ＢＡＲ（Block Ack Request）」とも称する）を送信する。そして、通信装置１０＃０は、当該送達確認要求の送信先となる子機から送達確認（以下、「ＢＡ（Block Ack）」とも称する）を受信することで、当該子機にマルチキャストデータが送達したことを確認する。なお、本開示の説明におけるＢＡＲは、ＩＥＥＥ８０２．１１規格に基づく「Block Ack Request」でもよく、送達確認要求を通知するための他のフレームであってもよい。また、本開示の説明におけるＢＡは、ＩＥＥＥ８０２．１１規格に基づく「Block Ack」または「Ack」であってもよく、送達確認を通知するための他のフレームであってもよい。

例えば、図２は、親局である通信装置１０＃０が、子機である通信装置１０＃１〜１０＃４に対してデータをマルチキャストし、当該データの送達を確認する場合の動作の一例を示している。

図２に示す例では、まず、通信装置１０＃０は、通信装置１０＃１〜１０＃４に対してマルチキャストデータを送信した後に、通信装置１０＃２及び１０＃４に対してＢＡＲを送信している。なお、このとき、通信装置１０＃２は、マルチキャストデータの受信に成功し、通信装置１０＃４は、マルチキャストデータの少なくとも一部の受信に失敗したものとする。

この場合には、通信装置１０＃２は、通信装置１０＃０からＢＡＲに対してＢＡを応答として返信することで、マルチキャストデータの送達を当該通信装置１０＃０に通知する。これにより、通信装置１０＃０は、通信装置１０＃２にマルチキャストデータが正しく送達したことを確認することが可能となる。一方で、通信装置１０＃４では、マルチキャストデータが正しく受信されていない。そのため、当該通信装置１０＃４は、通信装置１０＃０からのＢＡＲに対してＢＡを返信しないか、もしくは、マルチキャストデータの少なくとも一部の受信に失敗したことを示すＢＡを返信する。これにより、通信装置１０＃０は、通信装置１０＃４がマルチキャストデータの少なくとも一部の受信に失敗したことを認識することが可能となる。

次いで、図２に示す例では、通信装置１０＃０は、通信装置１０＃４がマルチキャストデータの少なくとも一部の受信に失敗したことを認識したため、当該マルチキャストデータを通信装置１０＃１〜１０＃４に再送している。このような動作により、図２に示す例では、マルチキャストデータの送信に係る通信の信頼性を向上させる（換言すると、通信品質を向上させる）ことが可能となる。なお、このとき、ＢＡＲの送信、ＢＡＲに対するＢＡの応答、マルチキャストデータの再送に係る一連の処理が、マルチキャストデータを送信する際のオーバーヘッドとなる。

図２に示すように、親局が複数の子機に対してデータをマルチキャストし、当該データの送達を親局が確認する場合には、当該送達の確認のために複数の通信が発生することとなる。そのため、親局がマルチキャストデータの送達を確認する子機の数が増大すると、上述したオーバーヘッドがより大きくなる傾向にある。特に、複数の通信装置１０間でデータの送受信が行われる通信環境下においては、図２に示すような、信頼性を向上させるためのオーバーヘッド自体が通信リソースを消費し、ひいては、通信品質を低下させる要因ともなり得る。また、マルチキャストデータの送信先となる子機のうち、特に、データの受信状況が好ましくない子機に対してデータの送達を確認するような状況下では、当該データの再送を行う回数が増え、システム全体としての通信の特性を劣化させる要因となり得る場合がある。また、システムが取り扱うトラフィックにおいて要求される遅延時間が短い場合には、送達の確認や再送が行われる回数が増大すると、当該要求される遅延時間を超過するような状況も想定され得る。

ここで、図３及び図４を参照して、データの送達確認要求（ＢＡＲ）の宛先となる子機の数（以降では、「ＢＡＲ宛先数」とも称する）と、システム特性との間の関係の一例について説明する。

例えば、図３は、ＢＡＲの宛先となる子機の数と、システム全体の特性としてのパケットロスレートとの関係の一例を示したグラフである。図３において、横軸は、ＢＡＲの宛先となる子機の数を示しており、縦軸は、システム全体の特性としてのパケットロスレートを示している。図３に示すように、ＢＡＲ宛先数が比較的少ない範囲（例えば、ＢＡＲ宛先数がｎ_１以下の範囲）においては、ＢＡＲ宛先数が増加するほど通信の信頼性が向上するため、システム全体としてのパケットロスレートは低下し、通信品質が向上する傾向にある。一方で、ＢＡＲ宛先数がある値を超えると（例えば、ＢＡＲ宛先数がｎ_１を超えると）、ＢＡＲ宛先数の増加に伴い、システム全体としてのパケットロスレートが上昇し、通信品質が劣化する傾向にあることがわかっている。これは、送達確認のための通信の増加や、それに伴うデータの再送回数の増加により、システム全体として通信が圧迫されることによるものである。

また、図４は、ＢＡＲの宛先となる子機の数と、システム全体の特性としての遅延時間との関係の一例を示したグラフである。図４において、横軸は、ＢＡＲの宛先となる子機の数を示しており、縦軸は、システム全体の特性としての遅延時間を示している。図４に示すように、システム全体としての遅延時間は、ＢＡＲ宛先数が増加するほど、より長くなる傾向にあることがわかっている。

即ち、図３及び図４に示すように、親局が複数の子機に対してデータをマルチキャストし、当該データの送達を親局が確認するような状況下においては、ＢＡＲ宛先数をより好適な値に設定することで、信頼性を担保しつつ通信リソースの消費を抑制し、ひいてはシステム全体としての通信品質を向上させることが可能であることが推測される。

一方で、システム全体としての通信品質を向上させることが可能なＢＡＲ宛先数の設定は、必ずしも常に一定とは限らず、例えば、通信状態に応じて変化する場合がある。具体的な一例として、通信装置１０間でデータを送信するための通信リソースの使用率が高い状況下（即ち、混雑している状況下）では、通信リソースの使用率が低い状況下（即ち、混雑していない状況下）に比べて、ＢＡＲ宛先数がより少ない方が、システム全体の通信品質を向上させることが可能な場合がある。

そこで、本開示では、通信状態に応じてＢＡＲの宛先となる子機（換言すると、ＢＡＲ宛先数）を設定することで、より好適な態様で、信頼性を担保しつつ通信リソースの消費を抑制することが可能な仕組みについて提案する。以降では、本開示の一実施形態に係る通信装置１０の詳細について説明する。

＜３．第１の実施形態：チャネルの混雑度に基づくＢＡＲの宛先数の決定＞
まず、本開示の第１の実施形態に係る通信装置１０について説明する。なお、以降の説明では、本実施形態に係る通信装置１０を他の実施形態に係る通信装置１０と特に区別して説明する場合には、「通信装置１０−１」と称する場合がある。

＜３−１．装置の構成＞
まず、図５を参照して、本開示の第１の実施形態に係る通信装置１０−１の構成の一例について説明する。図５は、本開示の第１の実施形態に係る通信装置１０−１の概略的な機能構成を示すブロック図である。

通信装置１０−１は、図５に示したように、データ処理部１１、通信部１２、及び制御部１８を備える。まず、通信装置１０−１の基本的な機能について説明する。

（（基本機能））
データ処理部１１は、データに対して送受信のための処理を行う。具体的には、データ処理部１１は、通信上位層からのデータに基づいてフレームを生成し、生成されるフレームを後述する信号処理部１４に提供する。例えば、データ処理部１１は、データからフレーム（またはパケット）を生成し、生成されるフレームにヘッダの付加および誤り検出符号の付加等の処理を行う。また、データ処理部１１は、受信されるフレームからデータを抽出し、抽出されるデータを通信上位層に提供する。例えば、データ処理部１１は、受信されるフレームについて、ヘッダの解析、符号誤りの検出および訂正、ならびにリオーダ処理等を行うことによりデータを取得する。

通信部１２は、図５に示したように、変復調部１３、信号処理部１４、チャネル推定部１５、無線インタフェース部１６および増幅部１７を備える。なお、図示しないが、通信装置１０−１には、固定電源またはバッテリ等の電源が設けられる。

変復調部１３は、フレームについて変調処理等を行う。具体的には、変復調部１３は、データ処理部１１から提供されるフレームについて、制御部１８によって設定されるコーディングおよび変調方式等に従って、エンコード、インタリーブおよび変調を行うことによりシンボルストリームを生成する。そして、変復調部１３は、生成したシンボルストリームを信号処理部１４に提供する。また、変復調部１３は、空間処理により得られるシンボルストリームを信号処理部１４から取得し、当該シンボルストリームについて、復調およびデコード等を行うことによりフレームを取得し、取得されるフレームをデータ処理部１１または制御部１８に提供する。

また、信号処理部１４は、空間分割多重通信に係る処理を行う。具体的には、信号処理部１４は、変復調部１３により生成されるシンボルストリームについて空間分離に係る信号処理を行い、処理により得られるシンボルストリームの各々をそれぞれ無線インタフェース部１６に提供する。また、信号処理部１４は、無線インタフェース部１６から得られる信号に係るシンボルストリームについて空間処理、例えばシンボルストリームの分離処理等を行い、処理により得られるシンボルストリームを変復調部１３に提供する。

チャネル推定部１５は、チャネル利得を推定する。具体的には、チャネル推定部１５は、無線インタフェース部１６から得られるシンボルストリームに係る信号のうちの、プリアンブル部分またはトレーニング用の参照信号部分から複素チャネル利得情報を算出する。なお、算出される複素チャネル利得情報は、制御部１８を介して信号処理部１４に提供され、復調処理および空間分離処理等に利用される。

無線インタフェース部１６は、アンテナを介して送受信される信号の生成を行う。具体的には、無線インタフェース部１６は、信号処理部１４から提供されるシンボルストリームに係る信号を、アナログ信号に変換し、フィルタリングし、および周波数アップコンバートする。そして、無線インタフェース部１６は、得られる信号を増幅部１７に提供する。また、無線インタフェース部１６は、増幅部１７から得られる信号について、信号送信の際と逆の処理、例えば周波数ダウンコンバートおよびデジタル信号変換等を行い、処理により得られる信号をチャネル推定部１５および信号処理部１４に提供する。なお、無線インタフェース部１６は複数備えられなくてもよい。

増幅部１７は、信号の増幅を行う。具体的には、増幅部１７は、無線インタフェース部１６から提供されるアナログ信号を所定の電力まで増幅し、増幅により得られる信号を、アンテナを介して送信させる。また、増幅部１７は、アンテナを介して受信される電波に係る信号を所定の電力まで増幅し、増幅により得られる信号を無線インタフェース部１６に提供する。例えば、増幅部１７はパワーアンプモジュール等であり得る。なお、増幅部１７の送信電波の増幅機能および受信電波の増幅機能のうちのいずれかまたは両方が無線インタフェース部１６に内包されてもよい。

なお、以下では、変復調部１３、信号処理部１４、チャネル推定部１５、無線インタフェース部１６および増幅部１７をまとめて通信部１２とも称する。

制御部１８は、通信装置１０−１の動作を全体的に制御する。具体的には、制御部１８は、各機能間の情報の受け渡し、通信パラメタの設定、送信電力制御、およびデータ処理部１１におけるフレーム（またはパケット）のスケジューリング等の処理を行う。

（（親局として動作する場合の機能））
次に、通信装置１０−１が親局として動作する場合の機能について詳細に説明する。

（チャネル混雑度の観測機能）
制御部１８は、例えば、キャリアセンスによりチャネルの使用状況を確認することで、チャネルの混雑度を観測する。ここで、チャネルの混雑度とは、親局である通信装置１０−１＃０がデータの送信に用いる時間的・空間的通信リソースが他の通信装置１０によって使用されている時間の割合を示している。ここで、他の通信装置１０とは、例えば、親局である通信装置１０−１＃０により通信が制御される通信装置１０（即ち、子機）であってもよいし、当該通信装置１０−１＃０による制御下にはない、親局または子機としての通信装置１０であってもよい。

より具体的な一例として、制御部１８は、例えば、受信した信号のヘッダの解析結果を変復調部１３から取得し、その取得結果から他の機器がそのチャネルを使用しているかを確認することで、チャネルの空き状況を確認する。もちろん、チャネルの混雑度に相当する情報を制御部１８が取得可能であれば、当該情報の種別や、当該情報を取得する方法は特に限定されないことは言うまでもない。

（マルチキャスト機能）
制御部１８は、宛先として指定された複数の子機に対して、送信対象となる同一のデータが送信されるようにデータ処理部１１及び通信部１２の動作を制御する。

具体的な一例として、制御部１８は、マルチキャストのためのアドレス（例えば、マルチキャストＩＰアドレス）により、宛先として指定された複数の子機をグループ化し、当該アドレスをデータ処理部１１に出力する。データ処理部１１は、制御部１８から出力されるアドレス（例えば、マルチキャストＩＰアドレス）に対応する制御情報（例えば、マルチキャストＭＡＣアドレス）を、送信対象のデータから生成されたフレームのヘッダに付加する。そして、制御部１８は、通信部１２に、当該制御情報が付加されたフレームを子機に宛てて送信させる。このような制御により、子機側は、受信した当該フレームのヘッダ中に付加された制御情報を参照することで、当該フレームが自身に宛てて送信されたフレームか否かを確認することが可能となる。

なお、上記に説明したマルチキャストの動作はあくまで一例であり、親局である通信装置１０−１＃０が、子機である複数の通信装置１０に対して同一のデータを送信する（即ち、マルチキャストする）ことが可能であれば、その方法は、上記に示す例には限定されない。

また、制御部１８は、後述する「データ送達の確認機能」により、データをマルチキャストした複数の子機のうち、少なくとも一部の子機に対して当該データの少なくとも一部が正しく送達しなかったことを認識した場合には、当該データが再送されるように、データ処理部１１及び通信部１２を制御してもよい。この場合には、制御部１８は、例えば、従前にデータをマルチキャストした複数の子機に対して、当該データが再度マルチキャストされるように制御してもよい。

（ＢＡＲ宛先数の決定機能）
制御部１８は、チャネルの混雑度の観測結果に応じてＢＡＲ宛先数を決定する。例えば、図６は、チャネルの混雑度とＢＡＲ宛先数との対応関係の一例であり、制御部１８がチャネルの混雑度の観測結果に応じてＢＡＲ宛先数を決定するための制御テーブルの一例を示している。

例えば、制御部１８は、図６に示す制御テーブルに基づき、チャネルの混雑度Ｘが０≦Ｘ＜Ｃ１（Ｃ１は定数）の場合には、閾値Ｄ１ｍａｘ以下となるようにＢＡＲ宛先数Ｄを決定する。また、制御部１８は、チャネルの混雑度ＸがＣ１≦Ｘ＜Ｃ２（Ｃ２は、Ｃ２＞Ｃ１となる定数）の場合には、閾値Ｄ２ｍａｘ（ただし、Ｄ２ｍａｘ≦Ｄ１ｍａｘ）以下となるようにＢＡＲ宛先数Ｄを決定する。以上のように、図６に示す制御テーブルでは、チャネルの混雑度Ｘが小さいほど、ＢＡＲ宛先数Ｄとしてより大きい値が設定されるように、チャネルの混雑度に応じたＢＡＲ宛先数の最大値が設定されている。

なお、図６に示す制御テーブルは、例えば、チャネルの混雑度と、当該チャネルの混雑度に応じたより好適なＢＡＲ宛先数の設定との関係を事前の実験等により確認し、当該確認結果に基づき生成して、制御部１８が読み出し可能な領域にあらかじめ記憶させておくとよい。

（データ送達の確認機能）
制御部１８は、データが送信された子機に対する当該データの送達を確認する。具体的には、制御部１８は、データ処理部１１に、データの送達確認の送信を要求するためのＢＡＲを含むＤＬフレーム（例えば、ＢＡＲフレーム）を生成させ、通信部１２に、当該ＤＬフレームを子機に宛てて送信させる。

なお、制御部１８は、複数の子機に対してデータをマルチキャストした場合には、当該複数の子機のうち少なくとも一部の子機を、ＢＡＲの宛先として決定してもよい。具体的には、制御部１８は、データをマルチキャストした複数の子機の中から、事前に決定したＢＡＲ宛先数の範囲内で、ＢＡＲの宛先となる子機を決定する。そして、制御部１８は、宛先として決定した子機それぞれに対してＢＡＲが個々に送信されるように（即ち、子機ごとに当該子機に宛ててＢＡＲが送信されるように）、データ処理部１１及び通信部１２の動作を制御すればよい。

また、制御部１８は、複数の子機を宛先として、ＢＡＲが送信されるようにデータ処理部１１及び通信部１２の動作を制御してもよい。この場合には、例えば、データ処理部１１は、複数の子機に宛ててＢＡＲが送信されるようにＤＬフレームを生成する。例えば、図７は、複数の子機を宛先としてＢＡＲを送信するためのＤＬフレームの構造の一例を示した図である。

図７に示すＤＬフレームは、例えば、「Frame Control」、「Duration / ID」、「RA」、「TA」、「BAR Control」、及び「BAR Information」を含む。なお、「BAR Information」は、宛先となる子機の数だけ設けられる。「Frame Control」には、フレームに関する情報が含まれる。また、「Duration / ID」には、フレームの長さに関する情報が含まれる。また、「RA」には、複数の子機に宛てたフレームであることを示すアドレスが含まれる。また、「TA」には、送信元（例えば、親局）のアドレスが含まれる。また、「BAR Control」には、後に続く「BAR Information」に関する情報が含まれる。また、「BAR Information」には、子機及びどのトラフィックに対するＢＡＲであるかを識別するための情報が含まれる。具体的には、「BAR Information」は、「AID」と「TID Value」とを含む。「AID」は、各子機を識別するための情報を含む。また、「TID Value」は、トラフィックを識別するための情報を含む。なお、「BAR Information」は、「AID」と「TID Value」とを複数含み得る。

次いで、制御部１８は、ＢＡＲに対する応答として子機から送信されるＢＡに基づき、当該子機へのデータの送達を確認する。具体的には、ＢＡを含むＵＬフレーム（例えば、ＢＡフレーム）が受信されると、データ処理部１１は、当該ＵＬフレームから送信元を示す情報とＢＡとを取得し、取得した送信元を示す情報とＢＡとを制御部１８に出力する。制御部１８は、取得されたＢＡの内容に応じて、当該ＢＡの送信元となる子機に対してデータが正しく送達したか否かを確認する。また、制御部１８は、ＢＡＲ含むＤＬフレームを送信した子機から、所定期間内に当該ＢＡＲに対する応答としてＢＡを含むＵＬフレームが送信されない場合には、当該子機に対するデータの少なくとも一部の送信が失敗したものと認識してもよい。なお、以降の説明では、ＢＡＲを含むＤＬフレーム（例えば、ＢＡＲフレーム）を、単にＢＡＲと称し、ＢＡを含むＵＬフレーム（例えば、ＢＡフレーム）を、単にＢＡと称する場合がある。

また、各子機から送信されるＢＡは、多重化されていてもよい。なお、本説明における多重化とは、例えば、空間多重、周波数多重、時間多重、及びＯＦＤＭＡ（Orthogonal frequency-division multiple access）であり得る。なお、ＢＡが多重化される場合には、制御部１８は、当該多重化を行うために必要な制御情報を子機側に通知してもよい。この場合には、例えば、制御部１８は、当該制御情報をＢＡＲに含めることで子機に通知されるように制御してもよい。また、他の一例として、制御部１８は、当該制御情報を含むフレームが、ＢＡＲに連結されるように制御してもよい。また、他の一例として、制御部１８は、当該制御情報を、ＢＡＲの前後の他のフレームとして子機に通知されるように制御してもよい。

（（子機として動作する場合の機能））
次に、通信装置１０−１が子機として動作する場合の機能について詳細に説明する。

（データ送達の通知機能）
制御部１８は、親局から送信されるＢＡＲに対する応答として、対応するデータの受信状況に応じた親局へのＢＡの通知処理を制御する。具体的には、制御部１８は、親局から送信されたＢＡＲが受信されると、当該ＢＡＲに対応するデータ（即ち、当該ＢＡＲに先行して受信したデータ）の受信に成功したか否かを確認する。そして、制御部１８は、ＢＡＲの応答として、当該データの受信状況に応じたＢＡが、当該ＢＡＲの送信元である親局に送信されるように、データ処理部１１及び通信部１２の動作を制御する。

データ処理部１１は、制御部１８からの指示に基づいてＢＡを生成し、生成したＢＡを通信部１２に出力する。

通信部１２は、データ処理部１１から出力されるＢＡを親局に向けて送信する。

なお、前述したように、ＢＡは多重化されて送信されてもよい。この場合には、制御部１８は、親局から通知される多重化のための制御情報に基づき、ＢＡが多重化されて送信されるように、データ処理部１１及び通信部１２の動作を制御すればよい。

以上、図５〜図７を参照して、本開示の第１の実施形態に係る通信装置１０−１の構成の一例について説明した。

＜３−２．装置の処理＞
次に、図８〜図１１を参照して、本実施形態に係る通信システムおよび通信装置１０−１の処理について、特に、親局が複数の子機に対してデータをマルチキャストし、当該データの送達を確認する場合の動作に着目して説明する。

（通信システムの処理シーケンス）
まず、図８を参照して、本実施形態に係る通信システムの処理シーケンスの一例について説明する。図８は、本実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。

図８に示すように、本実施形態に係る通信システムでは、親局（ＡＰ）である通信装置１０−１＃０は、キャリアセンスを実行することでチャネルの混雑度を観測し、複数の子機に対してデータを送信する（例えば、データをマルチキャストする）場合におけるＢＡＲ宛先数を、当該観測結果に基づき決定する。なお、本説明では、通信装置１０−１＃０は、複数の子機に対してデータをマルチキャストするものとして説明する。そして、通信装置１０−１＃０は、複数の子機（例えば、通信装置１０＃１〜１０−１＃Ｎ）に対してデータをマルチキャストした場合に、当該複数の子機の中から、決定したＢＡＲ宛先数の範囲内でＢＡＲの宛先を決定し、当該宛先に対してＢＡＲを送信する。

子機（ＳＴＡ）である通信装置１０−１は、親局である通信装置１０−１＃０から送信されたマルチキャストデータを受信した後に、当該通信装置１０−１＃０からＢＡＲを受信する場合がある。この場合には、当該通信装置１０−１は、受信したＢＡＲに対応するデータ（即ち、当該ＢＡＲに先行して受信したマルチキャストデータ）の受信状況に応じたＢＡを、ＢＡＲの送信元である通信装置１０−１＃０に送信する。

そして、親局である通信装置１０−１＃０は、ＢＡＲに対する応答として子機から送信されるＢＡの受信状況や、受信したＢＡの内容（即ち、当該ＢＡが、データが正しく送達されたことを示すか否か）に応じて、当該子機におけるマルチキャストデータの受信状況を認識する。

なお、図８に示す例では、親局である通信装置１０−１＃０は、マルチキャストデータの送信の直前に、混雑度の観測に係る処理（即ち、キャリアセンス）と、ＢＡＲ宛先数の決定に係る処理とを実行しているが、必ずしも、当該処理の実行タイミングを限定するものではない。具体的には、通信装置１０−１＃０が、子機に対してＢＡＲを送信するまでに、ＢＡＲ宛先数を決定できれば、混雑度の観測に係る処理とＢＡＲ宛先数の決定に係る処理との実行タイミングは特に限定されない。そのため、例えば、通信装置１０−１＃０は、マルチキャストデータを送信した後、かつ、ＢＡＲの送信前に、混雑度の観測に係る処理を実行し、観測結果に基づきＢＡＲ宛先数を決定してもよい。

（親局の処理フロー）
次に、図９を参照して、通信装置１０−１が親局として動作する場合の処理フローの一例について説明する。図９は、本実施形態に係る通信システムにおいて、親局として動作する通信装置１０−１の一連の動作の流れの一例を示したフローチャートである。

（ステップＳ１０１）
親局は、送信対象となるマルチキャストデータが存在しない限りは（Ｓ１０１、ＮＯ）、マルチキャストデータの送信に係る指示を待つ。

（ステップＳ１２０）
そして、親局は、送信対象となるマルチキャストデータが存在する場合には（Ｓ１０１、ＹＥＳ）、ＢＡＲ宛先数を決定する。ここで、図１０を参照して、ＢＡＲ宛先数の決定に係る処理の一例について説明する。図１０は、本実施形態に係る親局による、ＢＡＲ宛先数の決定に係る処理の一例を示したフローチャートである。

（ステップＳ１２１、Ｓ１２５）
具体的には、制御部１８は、キャリアセンスによりチャネルの使用状況を確認することで、チャネルの混雑度を観測する（Ｓ１２１）。そして、制御部１８は、チャネルの混雑度の観測結果に応じてＢＡＲ宛先数を決定する（Ｓ１２５）。以上のようにして、ＢＡＲ宛先数が決定される。ここで、図９を再度参照する。

（ステップＳ１０３）
次いで、親局は、マルチキャストデータを、当該マルチキャストデータの送信先となる複数の子機に送信する。

（ステップＳ１０５、Ｓ１０７）
マルチキャストデータを複数の子機に送信した後に、親局は、当該データの送達を確認する。具体的には、制御部１８は、データをマルチキャストした複数の子機の中から、事前に決定したＢＡＲ宛先数の範囲内で、当該データの送達を確認する子機（即ち、ＢＡＲの宛先）を決定し、当該子機に対してＢＡＲが送信されるように、データ処理部１１及び通信部１２の動作を制御する（Ｓ１０５）。そして、制御部１８は、ＢＡＲに対する応答として子機から送信されるＢＡの受信結果に基づき、当該子機へのデータの送達を確認する（Ｓ１０７）。

（ステップＳ１０９）
親局は、上記に説明したＢＡＲの送信に係る処理（Ｓ１０５）と、当該ＢＡＲに対する応答として子機から送信されるＢＡの受信結果に基づく当該子機へのデータの送達の確認に係る処理（Ｓ１０７）とを、対象となる宛先（即ち、子機）すべてに対して実行する（Ｓ１０９、ＮＯ）。

（ステップＳ１１３）
親局は、データをマルチキャストした複数の子機のうち、少なくとも一部の子機に対して当該データの少なくとも一部が正しく送達しなかったことを認識した場合には（Ｓ１１１、ＮＯ）、当該データを当該複数の子機に対して再度マルチキャストする（即ち、再送する）。具体的な一例として、親局は、子機から送信されたＢＡの内容が、マルチキャストデータの少なくとも一部が正常に受信されなかったことを示す場合、または、ＢＡＲを送信した子機から所定期間内にＢＡが送信されない場合に、子機に対してマルチキャストデータの少なくとも一部が正しく送達しなかったものと認識すればよい。

（ステップＳ１１１）
そして、親局は、ＢＡＲを送信したすべての子機から、マルチキャストデータが正常に送達したことを示すＢＡを受信した場合には（Ｓ１１１、ＹＥＳ）、当該マルチキャストデータの送信に係る一連の動作を終了する。

以上、図９を参照して、通信装置１０−１が親局として動作する場合の処理フローの一例について説明した。

（子機の処理フロー）
次に、図１１を参照して、通信装置１０−１が子機として動作する場合の処理フローの一例について説明する。図１１は、本実施形態に係る通信システムにおいて、子機として動作する通信装置１０−１の一連の動作の流れの一例を示したフローチャートである。

（ステップＳ１５１）
マルチキャスの対象に設定されている子機には、親局から当該マルチキャストデータが送信される。この場合には、対象となる子機は、まずマルチキャストデータの受信が完了するまで、当該受信に係る処理を実行する（Ｓ１５１、ＮＯ）。

（ステップＳ１５５）
次いで、マルチキャストの対象に設定されている子機のうち、ＢＡＲの宛先として設定されている子機には、マルチキャストデータが送信された後に、親局からＢＡＲが送信される。子機は、ＢＡＲを受信した場合には（Ｓ１５３、ＹＥＳ）、当該ＢＡＲに対する応答として、マルチキャストデータの受信状況に応じたＢＡを、当該ＢＡＲの送信元である親局に対して送信する。このような仕組みにより、親局は、子機から送信されたＢＡに基づき、当該子機に対してマルチキャストデータが正しく送達したか否かを認識することが可能となる。

（ステップＳ１５３）
なお、ＢＡＲの宛先となっていない子機に対しては、もちろん、親局からＢＡＲは送信されず、当該子機はＢＡＲを受信しない（Ｓ１５３、ＮＯ）。そのため、この場合には、子機は、ＢＡの送信に係る処理（Ｓ１５５）を実行せずに、マルチキャストデータの受信に係る一連の動作を終了することとなる。

以上、図１１を参照して、通信装置１０−１が子機として動作する場合の処理フローの一例について説明した。

＜３−３．変形例＞
次に、本実施形態の変形例について説明する。上記に説明した例では、本実施形態に係る通信システムにおいて、親局は、キャリアセンスに基づきチャネルの混雑度を観測し、観測結果に応じてＢＡＲ宛先数を決定していた。一方で、親局は、子機との間の通信の状態や状況に応じてＢＡＲ宛先数を決定できれば、その方法は必ずしも上記に説明した例には限定されない。そこで、変形例では、親局が、子機との間の通信の状態や状況に応じてＢＡＲ宛先数を決定する方法の他の一例について、図１２〜図１４を参照して説明する。

例えば、図１２は、本実施形態の変形例に係る通信システムについて説明するための説明図であり、同通信システムの処理シーケンスの一例について示している。より具体的には、図１２は、親局である通信装置１０−１＃０が、所謂衝突回避アルゴリズム（ＢＯ（Buck-Off）アルゴリズム）に基づき、複数の子機（例えば、通信装置１０−１＃１〜１０−１＃Ｎ）に対してデータをマルチキャストし、当該データの送達を確認する場合の一例を示している。

図１２に示す例では、親局は、子機に対してデータ（例えば、マルチキャストデータ、ＢＡＲ）を送信する場合には、ＩＦＳ（Inter Frame Space）及びＢＯの経過を待ち、当該経過後にチャネルが空いている場合には、当該チャネルを介して子機にデータを送信する。なお、ＩＦＳ及びＢＯが経過する前に、チャネルが他の通信装置により使用された場合には、親局は、時間経過（即ち、ＩＦＳ及びＢＯ）のカウントを一時的に停止して、他の通信装置によるチャネルの使用の終了を待つ。そして、親局は、当該他の通信装置によるチャネルの使用が終了し、かつ、所定の期間（固定時間）が経過した後に、停止した時間経過のカウントを、停止したところから再開する。なお、親局が子機に対してデータの送信を開始した際に、確率的には、同じタイミングでデータの送信を開始する他の通信装置が存在する可能性があり、その場合には、衝突によりデータの送信先では、当該データの少なくとも一部の受信に失敗する。親局は、送信先における当該データの少なくとも一部の受信失敗により、ＢＡやＡｃｋが送信先から返送されなかった場合には、ＢＯの期間を広げ、上記に説明した衝突回避アルゴリズムの手順を再度実行することとなる。

図１２において、参照符号Ｔａは、親局が、複数の子機に対してデータをマルチキャストするまで期間の一例を示している。例えば、期間Ｔａは、親局が、固定時間（例えば、ＤＩＦＳ（Distributed Inter Frame Space））とランダムな時間（ＢＯ）の経過後に、子機に対してマルチキャストデータを送信するまでの期間を示している。また、参照符号Ｔｂは、親局が、複数の子機に対してデータをマルチキャストし、次いで、当該データの送達を確認するために、対象となる子機に対してＢＡＲを送信するまでの期間の一例を示している。

ここで、期間Ｔａに着目する。親局が子機に対してデータを送信する場合に、前回のデータの送信において衝突が発生している場合には、当該衝突によりＢＯの期間がより長くなるように広げられている場合がある。即ち、親局と子機との間の通信経路が混雑している状況下（即ち、チャネルが混雑している状況下）では、データ（例えば、マルチキャストデータ）の送信までに要する期間Ｔａがより長くなる傾向にある。また、期間Ｔｂについても同様である。即ち、親局が子機に対してＢＡＲを送信する場合にも、衝突回避アルゴリズムが有効とあり、チャネルが混雑している状況下では、ＢＡＲの送信までに要する期間Ｔｂがより長くなる傾向にある。なお、このことは、データのマルチキャストやＢＡＲの送信に限らず、通常のデータを送信する場合についても同様である。

即ち、親局が、衝突回避アルゴリズムに基づき子機に対してデータを送信する場合には、当該データを送信するまでに要する時間は、チャネルの混雑状況に応じて変化し得る。そこで、本実施形態の変形例に係る通信システムでは、親局は、チャネルを介してデータを送信したときに、当該データの送信に要した時間Ｔ（例えば、図１２に示す期間Ｔａまたは期間Ｔｂ）を計測しておき、当該時間Ｔの計測結果に基づきチャネルの混雑状況を推定する。そして、親局は、チャネルの混雑状況の推定結果に応じて、ＢＡＲ宛先数を決定する。例えば、図１３は、変形例に係る親局（制御部１８）が、データの送信までに要した時間に応じて、ＢＡＲ宛先数を決定するための制御テーブルの一例を示している。

例えば、親局は、図１３に示す制御テーブルに基づき、前回のデータの送信時に当該データの送信に要した時間ＴがＮ０≦Ｘ＜Ｎ１（Ｎ０、Ｎ１は定数）の場合には、閾値Ｄ１ｍａｘ以下となるようにＢＡＲ宛先数Ｄを決定する。また、親局は、データの送信に要した時間ＴがＴ１≦Ｘ＜Ｔ２（Ｔ２は、Ｔ２＞Ｔ１となる定数）の場合には、閾値Ｄ２ｍａｘ（ただし、Ｄ２ｍａｘ≦Ｄ１ｍａｘ）以下となるようにＢＡＲ宛先数Ｄを決定する。以上のように、図１３に示す制御テーブルでは、データの送信に要した時間Ｔが短いほど、ＢＡＲ宛先数Ｄとしてより大きい値が設定されるように、データの送信に要した時間Ｔに応じたＢＡＲ宛先数の最大値が設定されている。なお、図１３に示す例では、データの送信に要した時間ＴがＮｎ≦Ｔ（Ｎｎは、Ｎｎ＞Ｎｎ−１＞・・・＞Ｎ１＞Ｎ０となる定数）の場合には、ＢＡＲ宛先数Ｄ＝０（即ち、ＢＡＲの送信を行わない設定）としてもよい。

なお、図１３に示す制御テーブルは、例えば、データの送信に要した時間と、当該時間に応じたより好適なＢＡＲ宛先数の設定との関係を事前の実験等により確認し、当該確認結果に基づき生成して、制御部１８が読み出し可能な領域にあらかじめ記憶させておくとよい。

次に、変形例に係る親局の動作の一例について説明する。なお、変形例に係る親局は、図９に示した一連の処理のうち、ＢＡＲ宛先数の決定に係る処理（Ｓ１２０）の内容が、前述した実施形態と異なり、その他の処理については、前述した実施形態と同様である。そこで、本説明では、変形例に係る親局の動作の一例について、ＢＡＲ宛先数の決定に係る処理にのみ着目して説明する。例えば、図１４は、変形例に係る親局の動作の一例について説明するためのフローチャートの一例であり、ＢＡＲ宛先数の決定に係る処理の一例を示している。

（ステップＳ１２３、Ｓ１２５）
具体的には、親局（制御部１８）は、マルチキャストデータの送信に際し、当該データの送信までに要した時間を計測する（Ｓ１２３）。そして、親局は、マルチキャストデータの送信に要した時間の計測結果に応じてＢＡＲ宛先数を決定する（Ｓ１２５）。以上のようにして、ＢＡＲ宛先数が決定される。なお、以降の動作については、前述した実施形態（図９参照）と同様である。

以上、本実施形態の変形例について、図１２〜図１４を参照して説明した。なお、図１３に示した制御テーブルに基づきＢＡＲ宛先数が決定される例はあくまで一例であり、親局が、衝突回避アルゴリズムにおける経過時間のカウントに際しチャネルの混雑度を推定し、ＢＡＲ宛先数を決定することが可能であれば、その方法は特に限定されない。具体的な一例として、親局は、衝突回避アルゴリズムにおける経過時間（即ち、ＩＦＳ及びＢＯ）のカウント中に、他の通信装置によりチャネルが使用された回数に基づきチャネルの混雑度を推定し、推定結果に基づきＢＡＲ宛先数を決定してもよい。

＜３−４．まとめ＞
以上、説明したように、本開示の第１の実施形態に係る通信システムでは、親局は、例えば、キャリアセンス等を実行することでチャネルの混雑度を観測（または推定）し、観測結果に応じてＢＡＲ宛先数を決定する。このような制御により、本実施形態に係る通信システムでは、例えば、チャネルが混雑している（即ち、通信リソースの使用率が高い）状況下では、ＢＡＲ宛先数がより少なくなるように制御され、データの送達の確認に係る通信の負荷が軽減される。また、チャネルが混雑していない（即ち、通信リソースの使用率が低い）状況下では、ＢＡＲ宛先数がより多くなるように制御され、データの送信に係る信頼性がより向上する。即ち、本実施形態に係る通信システムに依れば、通信状態に応じてＢＡＲ宛先数を設定することで、より好適な態様で、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

＜４．第２の実施形態：子機側からの要請に基づくＢＡＲの宛先の決定＞
次に、本開示の第２の実施形態に係る通信装置１０について説明する。なお、以降の説明では、本実施形態に係る通信装置１０を他の実施形態に係る通信装置１０と特に区別して説明する場合には、「通信装置１０−２」と称する場合がある。

＜４−１．装置の構成＞
まず、通信装置１０−２の機能構成について、前述した第１の実施形態に係る通信装置１０と異なる部分に着目して説明する。なお、前述した実施形態に係る通信装置１０と実質的に同一の部分については詳細な説明は省略する。

（（親局として動作する場合の機能））
まず、通信装置１０−２が親局として動作する場合の機能について説明する。

（ＢＡＲの宛先候補の条件通知機能）
本実施形態に係る親局は、ＢＡＲの宛先の候補を子機側からの要請に基づき決定することを想定し、当該子機に対して、ＢＡＲの宛先の候補とする子機の条件を通知する。例えば、図１５は、親局が子機に対して、ＢＡＲの宛先の候補とする子機の条件を通知するためのフレーム（以降では、「情報フレーム」とも称する）の構造の一例を示した図である。図１５に示すように、情報フレームには、「閾値とする特性指標の識別子」、「閾値」、及び、「特性の計算に必要な情報」が含まれ得る。

「閾値とする特性指標の識別子」とは、子機自身が、ＢＡＲの宛先となり得るか否かを判別するための、通信特性の指標を識別するための識別子である。なお、通信特性の指標としては、例えば、パケットエラーレート、スループット、信号対雑音比（ＳＮＲ（signal-to-noise ratio））、受信パケット数、再送による受信パケット数等が挙げられる。また、「閾値」は、上記識別子で示された通信特性の指標に基づき、子機自身が、ＢＡＲの宛先となり得るか否かを判別するための閾値を示している。また、「特性の計算に必要な情報」は、子機が、上記通信特性に関する情報を取得するために必要な情報を示しており、例えば、親局からの送信パケット数や、当該通信特性の導出に用いる期間を示す情報等も含まれ得る。

より具体的には、制御部１８は、チャネルの混雑度を観測または推定し、当該観測結果に基づき、データの送達に係る通信を実行するためにより好適な条件、即ち、通信特性の指標及び閾値を決定する。なお、チャネルの混雑度については、制御部１８は、例えば、前述した実施形態にて説明した「チャネル混雑度の観測機能」に基づき観測してもよい。また、このとき制御部１８は、子機が、対象となる通信特性に関する情報を取得するための情報を取得してもよい。

次いで、制御部１８は、決定した通信特性の指標の識別子と、当該通信特性の閾値と、当該通信特性に関する情報を取得するための情報と、をデータ処理部１１に出力し、当該データ処理部１１に情報フレームを生成させる。そして、制御部１８は、データ処理部１１により生成された情報フレームが、対象となる子機（例えば、マルチキャストの対象となる子機）に送信されるように、通信部１２の動作を制御する。以上のような制御により、対象となる子機に対して、ＢＡＲの宛先の候補とする子機の条件が通知される。

（ＢＡＲの宛先の決定機能）
本実施形態に係る親局は、ＢＡＲの宛先の候補とする子機の条件を示した情報フレームに対する応答として、当該情報フレームを送信した子機から、ＢＡＲの宛先とすることを要請するための情報（即ち、ＢＡＲの宛先に立候補したことを示す情報）を取得する。例えば、図１６は、子機が親局に対して、自身をＢＡＲの宛先とすることを要請するためのフレーム（以降では、「候補者フレーム」とも称する）の構造の一例を示した図である。図１６に示すように、候補者フレームには、「閾値とする特性指標の識別子」、「ＢＡＲ宛先とされることを要請する情報」、及び、「特性に関する情報」が含まれ得る。

「閾値とする特性指標の識別子」は、子機から親局に対して通知される通信特性の指標を識別するための情報であり、図１５に示した情報フレームと同様である。また、「ＢＡＲ宛先とされることを要請する情報」は、子機が、自身をＢＡＲの宛先とするように親局に要請するか否かを通知するための情報である。具体的な一例として、「ＢＡＲ宛先とされることを要請する情報」としては、子機が親局に対して、自身をＢＡＲの宛先とすることを要請する場合には「１」が設定され、ＢＡＲの宛先となることを辞退する場合には「０」が設定される。また、「特性に関する情報」は、「閾値とする特性指標の識別子」で示された特性の測定結果を示す情報を示している。

例えば、制御部１８は、各子機から送信された候補者フレームが受信されると、当該候補者フレームに含まれる情報の抽出結果を、データ処理部１１から取得する。そして、制御部１８は、取得した情報に基づき、ＢＡＲの宛先とする子機を決定する。なお、制御部１８は、候補者フレームから抽出された「ＢＡＲ宛先とされることを要請する情報」に基づき、ＢＡＲの宛先とすることを要請している子機を、ＢＡＲの宛先としてもよい。また、このとき制御部１８は、各子機からの候補者フレームから抽出された「特性に関する情報」を比較し、ＢＡＲの宛先とする子機を絞り込んでもよい。以上のようにして、本実施形態に係る制御部１８は、ＢＡＲの宛先とする子機を決定する。

（（子機として動作する場合の機能））
次に、通信装置１０−２が子機として動作する場合の機能について詳細に説明する。

（ＢＡＲの送信要請機能）
本実施形態に係る子機は、親局から送信される情報フレームに含まれる情報に基づき、対象となる通信特性を測定し、当該通信特性の測定結果に基づき、ＢＡＲの宛先の候補とすることを親局に要請するか否か（即ち、ＢＡＲの宛先として立候補するか否か）を判断し、当該判断の結果を親局に通知する。

具体的には、制御部１８は、親局から送信された情報フレームが受信されると、当該情報フレームに含まれる情報の抽出結果を、データ処理部１１から取得する。制御部１８は、情報フレームから抽出された「閾値とする特性指標の識別子」に基づき、当該識別子が示す通信特性に関する情報の測定に係る動作を制御する。また、このとき制御部１８は、情報フレームから抽出された「特性の計算に必要な情報」が、通信特性に関する情報の測定に使用されるように制御してもよい。

次いで、制御部１８は、通信特性に関する情報の測定結果と、情報フレームから抽出された「閾値」とを比較することで、ＢＡＲの宛先の候補となり得るか否かを判断する。ＢＡＲの宛先の候補となり得る場合には、制御部１８は、ＢＡＲの宛先の候補とすることを親局に要請するか否かを判断し、判断結果に基づく候補者フレームをデータ処理部１１に生成させる。また、このとき制御部１８は、通信特性の測定結果をデータ処理部１１に出力することで、データ処理部１１に、当該測定結果を含む候補者フレームを生成させてもよい。そして、制御部１８は、データ処理部１１により生成された候補者フレームが、親局に送信されるように、通信部１２の動作を制御する。

以上、図１５及び図１６を参照して、本開示の第２の実施形態に係る通信装置１０−２の構成の一例について説明した。

＜４−２．装置の処理＞
次に、図１７〜図２０を参照して、本実施形態に係る通信システムおよび通信装置１０−２の処理について、特に、親局が複数の子機に対してデータをマルチキャストし、当該データの送達を確認する場合の動作に着目して説明する。

（通信システムの処理シーケンス）
まず、図１７を参照して、本実施形態に係る通信システムの処理シーケンスの一例について説明する。図１７は、本実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。

図１７に示すように、本実施形態に係る通信システムでは、親局（ＡＰ）である通信装置１０−２＃０は、キャリアセンスを実行することでチャネルの混雑度を観測し、当該観測結果に基づき、ＢＡＲの宛先の候補とする子機の条件を決定する。親局は、決定した条件を通知するための情報フレームを生成し、生成した情報フレームを、マルチキャストの対象となる子機（例えば、通信装置１０＃２〜１０−２＃Ｎ）それぞれに送信する。

情報フレームを受信した各子機は、情報フレームに含まれる情報に基づき、ＢＡＲの宛先の候補とする子機の条件として指定された通信特性を測定する。なお、このとき子機は、情報フレームに含まれる情報を、当該通信特性の測定に利用してもよい。そして、子機は、通信特性の測定結果に基づき、自身をＢＡＲの宛先の候補とするように親局に要請するか否かを判断し、判断結果に応じて候補者フレームを生成して親局に送信する。

そして、親局は、情報フレームに対する応答として子機から送信される候補者フレームを受信し、受信した候補者フレームに含まれる情報に応じて、マルチキャストの対象となる複数の子機の中から、ＢＡＲの宛先とする子機を決定する。

なお、以降の動作については、前述した第１の実施形態に係る通信システム（例えば、図８）と同様である。即ち、親局は、対象となる複数の子機に対してデータをマルチキャストし、その後、ＢＡＲの宛先として決定した子機に対してＢＡＲを送信する。子機は、ＢＡＲを受信した場合には、対応するマルチキャストデータの受信状況に応じたＢＡを親局に送信する。親局は、ＢＡＲに対する応答として子機から送信されるＢＡに基づき、当該子機におけるマルチキャストデータの受信状況を認識する。

なお、図１７に示す例では、親局である通信装置１０−１＃０は、マルチキャストデータの送信の直前に、ＢＡＲの宛先の決定に係る処理（即ち、子機への情報フレームの送信、子機からの候補者フレームの受信、及び、当該候補者フレームに基づくＢＡＲの宛先の決定）を実行しているが、必ずしも、当該処理の実行タイミングを限定するものではない。具体的には、通信装置１０−２＃０が、子機に対してＢＡＲを送信するまでに、ＢＡＲの宛先を決定できれば、ＢＡＲの宛先の決定に係る各処理の実行タイミングは特に限定されない。そのため、例えば、通信装置１０−２＃０は、マルチキャストデータの送信後に、ＢＡＲの宛先の決定に係る各処理を実行し、その後に、決定した宛先に対してＢＡＲを送信してもよい。

（親局の処理フロー）
次に、図１８を参照して、通信装置１０−２が親局として動作する場合の処理フローの一例について説明する。図１８は、本実施形態に係る通信システムにおいて、親局として動作する通信装置１０−２の一連の動作の流れの一例を示したフローチャートである。なお、本説明では、主に、前述した第１の実施形態に係る通信装置１０−１とは異なる部分に着目して説明し、当該通信装置１０−１と実質的に同一の部分については詳細な説明は省略する。

（ステップＳ２０１）
親局は、送信対象となるマルチキャストデータが存在しない限りは（Ｓ２０１、ＮＯ）、マルチキャストデータの送信に係る指示を待つ。

（ステップＳ２２０）
そして、親局は、送信対象となるマルチキャストデータ存在する場合には（Ｓ２０１、ＹＥＳ）、ＢＡＲの宛先の候補とする子機の条件（以降では、「ＢＡＲ宛先候補条件」とも称する）を決定する。ここで、図１９を参照して、ＢＡＲ宛先候補条件の決定に係る処理の一例について説明する。図１９は、本実施形態に係る親機による、ＢＡＲ宛先候補条件の決定に係る処理の一例を示したフローチャートである。

（ステップＳ２２１、Ｓ２２５）
具体的には、制御部１８は、キャリアセンスによりチャネルの使用状況を確認することで、チャネルの混雑度を観測する（Ｓ２２１）。そして、制御部１８は、チャネルの混雑度の観測結果に応じてＢＡＲ宛先候補条件を決定する（Ｓ１２５）。以上のようにして、ＢＡＲ宛先候補条件が決定される。ここで、図１８を再度参照する。

（ステップＳ２０３、Ｓ２０５）
次いで、親局は、決定したＢＡＲ宛先候補条件を子機に通知するための情報フレームを生成し、生成した情報フレームをマルチキャストの対象となる複数の子機それぞれに送信する（Ｓ２０３）。また、親局は、情報フレームに対する応答として、当該情報フレームを送信した子機から、ＢＡＲの宛先とすることを要請するための情報（即ち、ＢＡＲの宛先に立候補したことを示す情報）を含む候補者フレームを受信する。そして、親局は、受信した候補者フレームに含まれる情報に基づき、ＢＡＲの宛先とする子機を決定する（Ｓ２０５）。

なお、以降の処理（即ち、Ｓ２０７〜Ｓ２１７に係る処理）については、前述した第１の実施形態に係る通信装置１０−１と同様であるため、詳細な説明は省略する。以上、図１８及び図１９を参照して、通信装置１０−２が親局として動作する場合の処理フローの一例について説明した。

（子機の処理フロー）
次に、図２０を参照して、通信装置１０−２が子機として動作する場合の処理フローの一例について説明する。図２０は、本実施形態に係る通信システムにおいて、子機として動作する通信装置１０−２の一連の動作の流れの一例を示したフローチャートである。なお、本説明では、主に、前述した第１の実施形態に係る通信装置１０−１とは異なる部分に着目して説明し、当該通信装置１０−１と実質的に同一の部分については詳細な説明は省略する。

（ステップＳ２５１）
マルチキャスの対象に設定されている子機には、親局から、ＢＡＲ宛先候補条件を示す情報が含まれた情報フレームが送信される。

（ステップＳ２５３）
子機は、親局から送信される情報フレームに含まれる情報に基づき、対象となる通信特性を測定し、当該通信特性の測定結果に基づき、自身が、ＢＡＲの宛先の候補となる条件を満たすか否かを判断する。

（ステップＳ２５５）
ＢＡＲの宛先の候補となり得る場合には（Ｓ２５３、ＹＥＳ）、子機は、ＢＡＲの宛先の候補とすることを親局に要請するか否か（即ち、ＢＡＲの宛先として立候補するか否か）を判断し、判断結果を示す情報（以降では、「ＢＡＲ宛先立候補」とも称する）を含む候補者フレームを生成して親局に送信する。なお、このとき子機は、通信特性の測定結果を示す情報を、候補者フレームに含めてもよい。また、ＢＡＲの宛先の候補となる条件を満たしていない場合には（Ｓ２５３、ＮＯ）、ＢＡＲ宛先立候補を含む候補者フレームの生成及び送信に係る処理は実行されない。

なお、以降の処理（即ち、Ｓ２５７〜Ｓ２６１に係る処理）については、前述した第１の実施形態に係る通信装置１０−１と同様であるため、詳細な説明は省略する。以上、図２０を参照して、通信装置１０−２が子機として動作する場合の処理フローの一例について説明した。

＜４−３．変形例＞
次に、本実施形態の変形例について説明する。例えば、図２１は、本実施形態の変形例に係る通信システムについて説明するための説明図であり、同通信システムの処理シーケンスの一例について示している。より具体的には、図２１は、親局である通信装置１０−２＃０が、衝突回避アルゴリズムに基づき、複数の子機（例えば、通信装置１０−２＃１〜１０−２＃Ｎ）に対してデータをマルチキャストし、当該データの送達を確認する場合の一例を示している。図２１に示す期間Ｔａ及びＴｂは、前述した第１の実施形態の変形例（図１２参照）における期間Ｔａ及びＴｂと同様である。

即ち、本実施形態の変形例に係る親局は、前述した第１の実施形態の変形例に係る親局と同様に、親局が子機に対してデータを送信する場合における、当該データの送信に要する時間Ｔを計測し、当該時間Ｔの計測結果に基づきチャネルの混雑状況を推測する。そして、変形例に係る親局は、データの送信に要する時間の計測結果に基づきチャネルの混雑状況を推測し、当該推測結果に基づきＢＡＲ宛先候補条件を決定する。

なお、以降の動作については、前述した本実施形態に係る通信システム（図１７参照）と同様である。即ち、親局は、決定した条件を通知するための情報フレームを生成し、生成した情報フレームを、マルチキャストの対象となる子機（例えば、通信装置１０＃２〜１０−２＃Ｎ）それぞれに送信する。情報フレームを受信した各子機は、情報フレームに含まれる情報により、ＢＡＲの宛先の候補とする子機の条件として指定された通信特性を測定し、当該測定結果に基づき、ＢＡＲの宛先として立候補するか否かを判断する。子機は、ＢＡＲの宛先として立候補する場合には、候補者フレームを生成して親局に送信する。親局は、子機から送信される候補者フレームを受信し、受信した候補者フレームに含まれる情報に応じて、マルチキャストの対象となる複数の子機の中から、ＢＡＲの宛先とする子機を決定することとなる。

なお、親局である通信装置１０−１＃０が、子機に対してＢＡＲを送信するまでに、ＢＡＲの宛先を決定できれば、ＢＡＲの宛先の決定に係る各処理の実行タイミングが特に限定されない点は、前述した実施形態に係る親局の場合（図１７参照）と同様である。

次に、変形例に係る親局の動作の一例について説明する。なお、変形例に係る親局は、図１８に示した一連の処理のうち、ＢＡＲ宛先候補条件の決定に係る処理（Ｓ２２０）の内容が、前述した実施形態と異なり、その他の処理については、前述した実施形態と同様である。そこで、本説明では、変形例に係る親局の動作の一例について、ＢＡＲ宛先候補条件の決定に係る処理にのみ着目して説明する。例えば、図２２は、変形例に係る親局の動作の一例について説明するためのフローチャートの一例であり、ＢＡＲ宛先候補条件の決定に係る処理の一例を示している。

（ステップＳ２２３、Ｓ２２５）
具体的には、親局（制御部１８）は、マルチキャストデータの送信に際し、当該データの送信までに要した時間を計測する（Ｓ１２３）。そして、親局は、マルチキャストデータの送信に要した時間の計測結果に応じてチャネルの混雑度を推測し、当該推測結果に基づきＢＡＲ宛先候補条件を決定する（Ｓ１２５）。以上のようにして、ＢＡＲ宛先候補条件が決定される。なお、以降の動作については、前述した実施形態（図１８参照）と同様である。

以上、本実施形態の変形例について、図２１及び図２２を参照して説明した。

＜４−４．まとめ＞
以上、説明したように、本開示の第２の実施形態に係る通信システムでは、親局は、例えば、キャリアセンス等を実行することでチャネルの混雑度を観測（または推定）し、観測結果に応じてＢＡＲ宛先候補条件を決定して、マルチキャストの対象となる各子機に通知する。子機側は、親局からの通知に基づき対応する通信特性を測定して、測定結果を親局から通知された条件と比較することで、自身がＢＡＲの宛先の候補となり得るかを判定する。そして、子機側は、自身がＢＡＲの宛先の候補となり得る場合には、親局側に自信をＢＡＲの宛先とすることを要請する。このような仕組みにより、親局は、条件に合致する子機（換言すると、通信特性のより良い子機）を選択的にＢＡＲの宛先とすることが可能となる。また、このとき親局は、子機から通知される通信特性の測定結果に応じて、ＢＡＲの宛先とする子機の数を制限することも可能である。即ち、本実施形態に係る通信システムに依れば、例えば、通信状態のより良い子機をＢＡＲの宛先として設定し、かつ、必要に応じてＢＡＲの宛先数を制限することも可能となるため、より好適な態様で、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

＜５．第３の実施形態：子機側でチャネルの混雑度を測定する態様＞
次に、本開示の第３の実施形態に係る通信装置１０について説明する。なお、以降の説明では、本実施形態に係る通信装置１０を他の実施形態に係る通信装置１０と特に区別して説明する場合には、「通信装置１０−３」と称する場合がある。

＜５−１．装置の構成＞
まず、通信装置１０−３の機能構成の一例について、前述した各実施形態に係る通信装置１０と異なる部分に着目して説明する。なお、前述した各実施形態に係る通信装置１０と実質的に同一の部分については詳細な説明は省略する。

（（親局として動作する場合の機能））
まず、通信装置１０−３が親局として動作する場合の機能について説明する。

（キャリアセンス情報の収集機能）
前述した第１の実施形態に係る通信システムでは、親局は、自身でチャネルの混雑度を観測し、観測結果に基づきＢＡＲ宛先数を設定していた。これに対して、本開示の第３の実施形態に係る通信システムでは、親局は、子機側におけるチャネル混雑度の観測結果に基づきＢＡＲ宛先数（または、ＢＡＲ宛先候補条件）を決定することを想定し、当該子機に対して、チャネル混雑度の観測と当該観測結果の通知とを依頼する。そして、親局は、当該依頼に対する応答として、子機からチャネル混雑度の観測結果の通知を受ける。なお、以降の説明では、当該依頼を「キャリアセンス情報リクエスト」とも称する。また、子機側から通知されるチャネルの混雑度の観測結果を含む情報を「キャリアセンス情報」とも称する。

より具体的には、制御部１８は、データ処理部１１に対してキャリアセンス情報リクエストを含むフレームの生成を指示し、データ処理部１１により生成された当該フレームが、対象となる子機（例えば、マルチキャストの対象となる子機）に送信されるように、通信部１２の動作を制御する。また、制御部１８は、各子機からキャリアセンス情報リクエストに対する応答として送信された、キャリアセンス情報を含むフレームが受信されると、当該フレームからのキャリアセンス情報の抽出結果を、データ処理部１１から取得する。以上のような制御により、制御部１８は、各子機からチャネルの混雑度の観測結果を収集することが可能となる。

本実施形態に係る制御部１８は、以上のようにして各子機から収集されたチャネルの混雑度の観測結果に基づき、前述の各実施形態で説明した、ＢＡＲ宛先数またはＢＡＲ宛先候補条件を決定し、ひいてはＢＡＲの宛先とする子機を決定する。なお、ＢＡＲ宛先数やＢＡＲ宛先候補条件の決定に係る処理や、決定されたＢＡＲ宛先数またはＢＡＲ宛先候補条件に基づくＢＡＲの宛先の決定に係る処理は、前述した対応する実施形態と同様のため、詳細な説明は省略する。

（（子機として動作する場合の機能））
次に、通信装置１０−２が子機として動作する場合の機能について詳細に説明する。

（キャリアセンス情報の通知機能）
本実施形態に係る子機は、親局から送信されるキャリアセンス情報リクエストに基づき、チャネルの混雑度を観測し、当該観測結果をキャリアセンス情報として親局に通知する。

具体的には、制御部１８は、親局から送信されたキャリアセンス情報リクエストを含むフレームが受信されると、当該フレームからのキャリアセンス情報リクエストの抽出結果を、データ処理部１１から取得する。制御部１８は、取得したキャリアセンス情報リクエストに基づき、チャネルの混雑度を観測する。なお、チャネルの混雑度を観測する方法は、例えば、前述した各実施形態において親局がチャネルの混雑度を観測する場合と同様の方法が適用可能であるため、詳細な説明は省略する。

次いで、制御部１８は、チャネルの混雑度の観測結果をキャリアセンス情報としてデータ処理部１１に出力し、データ処理部１１に対して当該キャリアセンス情報を含むフレームを生成させる。そして、制御部１８は、データ処理部１１により生成された、キャリアセンス情報を含むフレームが、親局に送信されるように、通信部１２の動作を制御する。

以上、本開示の第３の実施形態に係る通信装置１０−３の構成の一例について説明した。

＜５−２．装置の処理＞
次に、図２３〜図２６を参照して、本実施形態に係る通信システムおよび通信装置１０−３の処理について、特に、親局が複数の子機に対してデータをマルチキャストし、当該データの送達を確認する場合の動作に着目して説明する。

（通信システムの処理シーケンス）
まず、図２３を参照して、本実施形態に係る通信システムの処理シーケンスの一例について説明する。図２３は、本実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。

図２３に示すように、本実施形態に係る通信システムでは、親局（ＡＰ）である通信装置１０−２＃０は、マルチキャストの対象となる子機（例えば、通信装置１０−２＃１〜１０−２＃Ｎ）にキャリアセンス情報リクエストを送信し、その応答として当該子機からキャリアセンス情報（即ち、チャネルの混雑度の観測結果）を収集する。

そして、親局は、各子機から収集したキャリアセンス情報に基づき、各子機との間の通信におけるチャネルの混雑度に応じて、マルチキャストの対象となる複数の子機の中から、ＢＡＲの宛先とする子機を決定する。なお、このとき、親局が、ＢＡＲの宛先とする子機を決定する方法については特に限定されない。例えば、親局は、前述した第１の実施形態と同様に、各子機から収集したチャネルの混雑度に応じてＢＡＲ宛先数を決定し、当該ＢＡＲ宛先数の範囲内で、ＢＡＲの宛先とする子機を決定してもよい。また、他の一例として、親局は、前述した第２の実施形態と同様に、各子機から収集したチャネルの混雑度に応じてＢＡＲ宛先候補条件を決定してもよい。この場合には、親局は、決定したＢＡＲ宛先候補条件を含む情報フレームをマルチキャストの対象となる各子機に送信し、その応答として当該子機から送信される候補者フレームに基づき、ＢＡＲの宛先とする子機を決定してもよい。

なお、以降の動作については、前述した各実施形態に係る通信システム（例えば、図８、図１７等）と同様である。即ち、親局は、対象となる複数の子機に対してデータをマルチキャストし、その後、ＢＡＲの宛先として決定した子機に対してＢＡＲを送信する。子機は、ＢＡＲを受信した場合には、対応するマルチキャストデータの受信状況に応じたＢＡを親局に送信する。親局は、ＢＡＲに対する応答として子機から送信されるＢＡに基づき、当該子機におけるマルチキャストデータの受信状況を認識する。

なお、図２３に示す例では、親局である通信装置１０−３＃０は、マルチキャストデータの送信の直前に、キャリアセンス情報の収集に係る処理（即ち、子機へのキャリアセンス情報リクエストの送信、及び、子機からのキャリアセンス情報の受信）や、収集されたキャリアセンス情報に基づきＢＡＲの宛先を決定する処理を実行しているが、必ずしも、当該処理の実行タイミングを限定するものではない。具体的には、通信装置１０−３＃０が、子機に対してＢＡＲを送信するまでに、ＢＡＲの宛先を決定できれば、キャリアセンス情報の収集に係る処理や、収集されたキャリアセンス情報に基づきＢＡＲの宛先を決定する処理の実行タイミングは特に限定されない。そのため、例えば、通信装置１０−３＃０は、マルチキャストデータの送信後に、キャリアセンス情報の収集に係る処理と、当該キャリアセンス情報に基づくＢＡＲの宛先の決定に係る処理とを実行し、その後に、決定した宛先に対してＢＡＲを送信してもよい。

（親局の処理フロー）
次に、図２４を参照して、通信装置１０−３が親局として動作する場合の処理フローの一例について説明する。図２４は、本実施形態に係る通信システムにおいて、親局として動作する通信装置１０−３の一連の動作の流れの一例を示したフローチャートである。なお、本説明では、主に、前述した各実施形態に係る通信装置１０（例えば、第１の実施形態に係る通信装置１０−１や、第２の実施形態に係る通信装置１０−２）とは異なる部分に着目して説明し、当該通信装置１０と実質的に同一の部分については詳細な説明は省略する。

（ステップＳ３０１）
親局は、送信対象となるマルチキャストデータが存在しない限りは（Ｓ３０１、ＮＯ）、マルチキャストデータの送信に係る指示を待つ。

（ステップＳ３０３、Ｓ３０５）
親局は、送信対象となるマルチキャストデータ存在する場合には（Ｓ３０１、ＹＥＳ）、キャリアセンス情報リクエストをマルチキャストの対象となる子機に送信する。そして、親局は、キャリアセンス情報リクエストに対する応答として、子機からキャリアセンス情報を受信する。

（ステップＳ３２０）
親局は、子機から取得したキャリアセンス情報に基づき、マルチキャストの対象となる子機の中から、ＢＡＲの宛先とする子機を決定する。ここで、図２５を参照して、ＢＡＲＢＡＲの宛先とする子機の決定に係る処理の一例について説明する。図２５は、本実施形態に係る親機による、ＢＡＲの宛先とする子機の決定に係る処理の一例を示したフローチャートである。

（ステップＳ３２３）
例えば、親局側が能動的にＢＡＲの宛先を決定する場合には（Ｓ３２１、ＹＥＳ）、親局は、収集したキャリアセンス情報（即ち、子機によるチャネルの混雑度の観測結果）に基づき、ＢＡＲ宛先数を決定する。なお、チャネルの混雑度の観測結果に応じたＢＡＲ宛先数の決定に係る処理については、前述した第１の実施形態と同様である。そして、親局は、マルチキャストの対象となる子機の中から、決定したＢＡＲ宛先数の範囲内で、ＢＡＲの宛先とする子機を決定する。

（ステップＳ３２５）
また、他の一例として、親局側が受動的にＢＡＲの宛先を決定する場合には（Ｓ３２１、ＮＯ）、親局は、収取したキャリアセンス情報に基づき、ＢＡＲ宛先候補条件を決定する。なお、チャネルの混雑度の観測結果に応じたＢＡＲ宛先候補条件の決定に係る処理については、前述した第２の実施形態と同様である。

（ステップＳ３２７、Ｓ３２９）
次いで、親局は、決定したＢＡＲ宛先候補条件を子機に通知するための情報フレームを生成し、生成した情報フレームをマルチキャストの対象となる複数の子機それぞれに送信する（Ｓ３２７）。また、親局は、情報フレームに対する応答として、当該情報フレームを送信した子機から、ＢＡＲの宛先とすることを要請するための情報（即ち、ＢＡＲの宛先に立候補したことを示す情報）を含む候補者フレームを受信する。そして、親局は、受信した候補者フレームに含まれる情報に基づき、ＢＡＲの宛先とする子機を決定する（Ｓ３２９）。

以上のようにして、親局は、マルチキャストの対象となる子機の中から、ＢＡＲの宛先とする子機を決定する。なお、親局側が能動的にＢＡＲの宛先を決定するか否かについては、あらかじめ決定されていてもよいし、設定の変更等により動的に切り替えられてもよい。

なお、以降の処理（即ち、図２５に示すＳ３０７〜Ｓ３１７に係る処理）については、前述した各実施形態に係る通信装置１０（即ち、第１の実施形態に係る通信装置１０−１や、第２の実施形態に係る通信装置１０−２）と同様であるため、詳細な説明は省略する。以上、図２５及び図２６を参照して、通信装置１０−３が親局として動作する場合の処理フローの一例について説明した。

（子機の処理フロー）
次に、図２６を参照して、通信装置１０−３が子機として動作する場合の処理フローの一例について説明する。図２６は、本実施形態に係る通信システムにおいて、子機として動作する通信装置１０−３の一連の動作の流れの一例を示したフローチャートである。なお、本説明では、主に、前述した各実施形態に係る通信装置１０（例えば、第１の実施形態に係る通信装置１０−１や、第２の実施形態に係る通信装置１０−２）とは異なる部分に着目して説明し、当該通信装置１０と実質的に同一の部分については詳細な説明は省略する。

（ステップＳ３５１、Ｓ３５３）
マルチキャスの対象に設定されている子機には、親局から、キャリアセンス情報リクエストが送信される（Ｓ３５１）。子機は、親局から送信されるキャリアセンス情報リクエストを受信すると、チャネルの混雑度を観測し、当該観測結果をキャリアセンス情報として親局に通知する（Ｓ３５３）。なお、チャネルの混雑度を観測する方法は、例えば、前述した各実施形態において親局がチャネルの混雑度を観測する場合と同様の方法を適用し得る。

（ステップＳ３５５）
次いで、子機は、親局におけるＢＡＲの宛先の決定方法に応じて、ＢＡＲ宛先立候補条件を示す情報が含まれた情報フレームを親局から受信する場合がある。親局から情報フレームを受信した場合には（Ｓ３５５、ＹＥＳ）、子機は、当該情報フレームに含まれる情報に基づき、対象となる通信特性を測定し、当該通信特性の測定結果に基づき、自身が、ＢＡＲの宛先の候補となる条件を満たすか否かを判断する。

（ステップＳ３５９）
ＢＡＲの宛先の候補となり得る場合には（Ｓ３５７、ＹＥＳ）、子機は、ＢＡＲの宛先の候補とすることを親局に要請するか否か（即ち、ＢＡＲの宛先として立候補するか否か）を判断し、判断結果を示す情報（即ち、ＢＡＲ宛先立候補）を含む候補者フレームを生成して親局に送信する。なお、親局から情報フレームを受信していない場合（Ｓ３５５、ＮＯ）や、ＢＡＲの宛先の候補となる条件を満たしていない場合には（Ｓ３５７、ＮＯ）、ＢＡＲ宛先立候補を含む候補者フレームの生成及び送信に係る処理は実行されない。

なお、以降の処理（即ち、Ｓ３６１〜Ｓ３６５に係る処理）については、前述した各実施形態に係る通信装置１０（即ち、第１の実施形態に係る通信装置１０−１や、第２の実施形態に係る通信装置１０−２）と同様であるため、詳細な説明は省略する。以上、図２６を参照して、通信装置１０−３が子機として動作する場合の処理フローの一例について説明した。

＜５−３．まとめ＞
以上、説明したように、本開示の第３の実施形態に係る通信システムでは、親局は、子機側にチャネル混雑度の観測結果を通知させ、各子機から収集したチャネル混雑度の観測結果に基づき、ＢＡＲの宛先とする子機を決定する。このような仕組みにより、親局は、子機との間の通信におけるチャネルの状態に応じて、ＢＡＲを送信する子機の数を制限したり、通信状態のより良い子機をＢＡＲの宛先として設定することが可能となる。特に、本実施形態に係る通信システムでは、親局と子機との間で周囲の通信の状態や状況が異なるような状況下においても、子機側における通信の状態や状況に応じて、ＢＡＲの宛先とする子機を決定することが可能となる。即ち、本実施形態に係る通信システムに依れば、子機側における通信の状態や状況に応じて、より好適な態様で、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

＜６．第４の実施形態：親局側の通信状態に応じたＢＡＲの宛先の決定＞
次に、本開示の第４の実施形態に係る通信装置１０について説明する。なお、以降の説明では、本実施形態に係る通信装置１０を他の実施形態に係る通信装置１０と特に区別して説明する場合には、「通信装置１０−４」と称する場合がある。

＜６−１．装置の構成＞
まず、通信装置１０−４の機能構成について、前述した各実施形態に係る通信装置１０と異なる部分に着目して説明する。なお、前述した各実施形態に係る通信装置１０と実質的に同一の部分については詳細な説明は省略する。

（（親局として動作する場合の機能））
まず、通信装置１０−４が親局として動作する場合の機能について説明する。

（ＢＡＲの宛先の決定機能）
前述した各実施形態に係る通信システムでは、親局は、子機との間の通信におけるチャネルの状態や状況に応じてＢＡＲ宛先数やＢＡＲ宛先候補条件を決定していた。これに対して、本開示の第４の実施形態に係る通信システムでは、親局（制御部１８）は、子機との間の通信における当該親局側の通信状況を示す各種情報に基づき、ＢＡＲ宛先数やＢＡＲ宛先候補条件を決定する。なお、通信状況を示す各種情報としては、例えば、取り扱われるトラフィックのパケットサイズ、変調方式及び符号化方式（ＭＣＳ（Modulation Coding Scheme））、ＡＣ（Access Category）、遅延時間、パケットロスレート、スループット等が挙げられる。親局は、これらの情報のうち少なくとも１つの情報に基づき、ＢＡＲ宛先数やＢＡＲ宛先候補条件を決定する。また、上記情報の取得対象となるトラフィックは、必ずしもＢＡＲやＢＡの送受信を要求するトラフィックに限らず、他のトラフィックであってもよい。また、以降の説明では、上記に説明した通信状況を示す各種情報を、「デバイス情報」とも称し、特に、親局における通信状況を示すデバイス情報を示す場合には、「親局側のデバイス情報」と称する場合がある。

例えば、制御部１８は、取得したデバイス情報に基づきＢＡＲ宛先数を決定する。具体的な一例として、制御部１８は、親局側のデバイス情報と、マルチキャストデータの再送回数とに基づき、親局によるチャネルの使用時間を推定する。なお、当該推定に利用される、マルチキャストデータの再送回数は、事前に決められた設定としての再送回数であってもよいし、通信実績に基づき予測される再送回数であってもよい。制御部１８は、推定した親局によるチャネルの使用時間と、チャネルの混雑度から算出されるチャネル使用時間とから、ＢＡＲ宛先数を決定する。なお、チャネルの混雑度を観測する方法は、前述した各実施形態と同様のため、詳細な説明は省略する。

より、具体的には、制御部１８は、親局によるチャネルの使用時間によりチャネルの混雑度が所定の割合（例えば、１００％）を超え、パケットが送信できずに破棄されることによるパケットロスレートが、要求値を超えない範囲でＢＡＲ宛先数を決定する。具体的な一例として、制御部１８は、以下に（式１）として示す条件式を満たすように、ＢＡＲ宛先数を決定してもよい。なお、以下に示す（式１）において、「有効マルチキャストデータ」とは、再送を含まない１回の送信により、子機に送信されるマルチキャストデータを示す。

また、制御部１８は、親局で扱われるトラフィックの要求遅延時間に基づいて、ＢＡＲ宛先数を決定してもよい。具体的な一例として、制御部１８は、ＢＡＲ、ＢＡ、及び、マルチキャストデータの再送回数に基づいて算出される遅延時間が、トラフィックの要求遅延時間を超えない範囲でＢＡＲ宛先数を決定する。なお、ここでのマルチキャストデータの再送回数は、前述のように、事前に決められた設定としての再送回数であってもよいし、通信実績に基づき予測される再送回数であってもよい。

また、上記では、親局（制御部１８）が、ＢＡＲ宛先数を決定する例について説明したが、親局は、前述した第２の実施形態と同様に、ＢＡＲ宛先候補条件を決定してもよい。この場合には、親局は、決定したＢＡＲ宛先候補条件を含む情報フレームを、マルチキャストの対象となる各子機に対して通知し、その応答として子機から送信される候補者フレームに含まれる情報（即ち、ＢＡＲ宛先立候補）に基づき、ＢＡＲの宛先とする子機を決定すればよい。

以上、本開示の第４の実施形態に係る通信装置１０−４の構成の一例について説明した。

＜６−２．装置の処理＞
次に、図２７を参照して、本実施形態に係る通信システムおよび通信装置１０−４の処理について、特に、親局が複数の子機に対してデータをマルチキャストし、当該データの送達を確認する場合の動作に着目して説明する。図２７は、本実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。

前述の通り、本実施形態に係る通信システムでは、親局は、自身のデバイス情報（即ち、親局における通信状況を示す情報）を取得し、取得したデバイス情報に基づきＢＡＲの宛先とする子機を決定する。例えば、図２７に示す例では、親局である通信装置１０−４＃０は、自身のデバイス情報に基づき、マルチキャストの対象となる子機（例えば、通信装置１０−４＃１〜１０−４＃Ｎ）の中から、ＢＡＲの宛先とする子機を決定する。

なお、親局である通信装置１０−４＃０は、子機に対してＢＡＲを送信するまでに、ＢＡＲの宛先を決定できれば、ＢＡＲの宛先の決定に係る各処理（即ち、デバイス情報の取得や当該デバイス情報に基づくＢＡＲの宛先とする子機の決定に係る処理）の実行タイミングは特に限定されない。例えば、通信装置１０−４＃０は、マルチキャストデータの送信前に、自身のデバイス情報を取得し、取得したデバイス情報に基づきＢＡＲの宛先とする子機を決定してもよい。また、他の一例として、通信装置１０−４＃０は、マルチキャストデータの送信後に、ＢＡＲの宛先の決定に係る各処理を実行し、その後に、宛先として決定した子機に対してＢＡＲを送信してもよい。

＜６−３．まとめ＞
以上、説明したように、本開示の第４の実施形態に係る通信システムでは、親局は、自身の通信状況を示す各種情報（即ち、デバイス情報）を取得し、取得した当該情報に基づきＢＡＲの宛先とする子機を決定する。このような構成により、親局は、例えば、取得したデバイス情報に基づき、マルチキャストデータの送信時における子機との間の通信の特性（例えば、パケットロスレートや遅延時間）を推定し、当該特性が要求値を超えない範囲で、ＢＡＲ宛先数を決定することが可能となる。即ち、本実施形態に係る通信システムに依れば、親局と子機との間の通信状態を推定し、推定結果に基づき、より好適な態様で、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

＜７．第５の実施形態：子機側の通信状態に応じたＢＡＲの宛先の決定＞
次に、本開示の第５の実施形態に係る通信装置１０について説明する。なお、以降の説明では、本実施形態に係る通信装置１０を他の実施形態に係る通信装置１０と特に区別して説明する場合には、「通信装置１０−５」と称する場合がある。

＜７−１．装置の構成＞
まず、通信装置１０−５の機能構成について、前述した各実施形態に係る通信装置１０と異なる部分に着目して説明する。なお、前述した各実施形態に係る通信装置１０と実質的に同一の部分については詳細な説明は省略する。

（（親局として動作する場合の機能））
まず、通信装置１０−４が親局として動作する場合の機能について説明する。

（デバイス情報の収集機能）
前述した第４の実施形態に係る通信システムでは、親局は、自身のデバイス情報を取得し、取得したデバイス情報に基づきＢＡＲの宛先となる子機を決定していた。これに対して、本開示の第５の実施形態に係る通信システムでは、親局は、子機側のデバイス情報（即ち、子機側における通信状況を示す各種情報）に基づきＢＡＲの宛先とする子機を決定することを想定し、当該子機に対して、デバイス情報の取得と当該デバイス情報の通知とを依頼する。そして、親局は、当該依頼に対する応答として、子機からデバイス情報の通知を受ける。なお、以降の説明では、当該依頼を「デバイス情報リクエスト」とも称する。また、以降の説明では、特に、子機における通信状況を示すデバイス情報を示す場合には、「子機側のデバイス情報」と称する場合がある。

子機側のデバイス情報としては、例えば、取り扱われるトラフィックの受信パケット数、再送を除く受信パケット数、遅延時間、パケットロスレート、スループット、信号対干渉雑音比（ＳＩＮＲ（signal-to-interference noise ratio））、受信電力、取り扱われる他のトラフィックの有無等が挙げられる。親局は、これらの情報のうち少なくとも１つの情報を、対象となる各子機から収集する。また、上記情報の取得対象となるトラフィックは、必ずしもＢＡＲやＢＡの送受信を要求するトラフィックに限らず、他のトラフィックであってもよい。また、子機側のデバイス情報としては、子機の位置、測度、加速度、電源状態等のように、当該子機の状態を示す情報が取得されてもよい。具体的な一例として、位置情報や速度情報から、親局は、対象となる子機が自身に対して近づいているか、または、遠ざかっているかを認識することができる。そのため、例えば、親局は、子機が近づいている場合には、当該子機側における受信状況が改善する可能性があるものと認識することが可能となる。また、他の一例として、親局は、子機が遠ざかっている場合には、当該子機側における受信状況が劣化する可能性があり、ひいては、自身が通信可能な範囲の外に移動する可能性があるものと認識することが可能となる。

ここで、親局の動作についてより具体的に説明する。制御部１８は、データ処理部１１に対してデバイス情報リクエストを含むフレーム（以降では、「要求フレーム」とも称する）の生成を指示する。なお、デバイス情報リクエストには、例えば、子機側で観測する内容（換言すると、取得するデバイス情報の種別）、観測する期間に関する情報、観測結果（即ち、取得したデバイス情報）の送信方法に関する情報等が含まれ得る。なお、観測結果の送信方法に関する情報としては、例えば、送信時に用いられる周波数チャネルの中心周波数、帯域幅、空間多重用のプリアンブル割当て、送信時刻、送信電力、変調方式及び符号化方式等の情報が含まれ得る。そして、制御部１８は、データ処理部１１により生成された当該要求フレームが、対象となる子機（例えば、マルチキャストの対象となる子機）に宛てて送信されるように、通信部１２の動作を制御する。

また、制御部１８は、各子機からデバイス情報リクエストに対する応答として送信された、子機側のデバイス情報を含むフレームが受信されると、当該フレームからの子機側のデバイス情報の抽出結果を、データ処理部１１から取得する。以上のような制御により、制御部１８は、各子機からデバイス情報を収集することが可能となる。

（ＢＡＲの宛先の決定機能）
本実施形態に係る親局は、各子機から収取したデバイス情報に基づき、ＢＡＲの宛先とする子機を決定する。例えば、親局（制御部１８）は、取得した子機側のデバイス情報に基づきＢＡＲ宛先数を決定する。具体的な一例として、制御部１８は、取得したデバイス情報に基づき、子機側で取り扱われるトラフィックに関する情報から、当該トラフィックがチャネルを占有する時間を推定する。そして、親局（制御部１８）は、当該推定結果に基づき、対応するチャネルを親局が使用する時間により当該チャネルの混雑度が所定の割合（例えば、１００％）を超え、パケットが送信できずに破棄されることによるパケットロスレートが、要求値を超えない範囲でＢＡＲ宛先数を決定する。

もちろん、上記に説明した子機側のデバイス情報に基づくＢＡＲ宛先数の決定方法はあくまで一例であり、パケットロスレートや遅延時間等の通信の状況を示す情報が、要求値を超えない範囲でＢＡＲ宛先数を決定することが可能であれば、その方法は特に限定されない。

また、上記では、親局（制御部１８）が、ＢＡＲ宛先数を決定する例について説明したが、親局は、前述した第２の実施形態と同様に、ＢＡＲ宛先候補条件を決定してもよい。この場合には、親局は、決定したＢＡＲ宛先候補条件を含む情報フレームを、マルチキャストの対象となる各子機に対して通知し、その応答として子機から送信される候補者フレームに含まれる情報（即ち、ＢＡＲ宛先立候補）に基づき、ＢＡＲの宛先とする子機を決定すればよい。

（（子機として動作する場合の機能））
次に、通信装置１０−５が子機として動作する場合の機能について詳細に説明する。

（通信状況の取得機能）
本実施形態に係る子機は、親局から送信されるデバイス情報リクエストに基づき、デバイス情報を取得し、取得したデバイス情報を親局に通知する。

具体的には、制御部１８は、親局から送信されたデバイス情報リクエストを含む要求フレームが受信されると、当該要求フレームからのデバイス情報リクエストの抽出結果を、データ処理部１１から取得する。制御部１８は、取得したデバイス情報リクエストにより指示されたデバイス情報（即ち、観測対象となる情報）を、当該デバイス情報リクエストにより指示された観測方法に基づき取得する。

制御部１８は、取得したデバイス情報をデータ処理部１１に出力し、データ処理部１１に対して当該デバイス情報を含むフレームを生成させる。そして、制御部１８は、データ処理部１１により生成された、デバイス情報を含むフレームが、デバイス情報リクエストにより指示された送信方法に基づき親局に送信されるように、通信部１２の動作を制御する。

以上、本開示の第５の実施形態に係る通信装置１０−５の構成の一例について説明した。

＜７−２．装置の処理＞
次に、図２８を参照して、本実施形態に係る通信システムおよび通信装置１０−５の処理について、特に、親局が複数の子機に対してデータをマルチキャストし、当該データの送達を確認する場合の動作に着目して説明する。図２８は、本実施形態に係る通信システムの処理シーケンスの一例について説明するための説明図である。

図２８に示すように、本実施形態に係る通信システムでは、親局（ＡＰ）である通信装置１０−５＃０は、マルチキャストの対象となる子機（例えば、通信装置１０−５＃１〜１０−５＃Ｎ）にデバイス情報リクエストを送信する。

子機は、親局からデバイス情報リクエストを受信すると、当該デバイス情報リクエストで指示されたデバイス情報を、当該デバイス情報リクエストで指示された観測方法に基づき取得する。そして、子機は、デバイス情報リクエストで指示された送信方法に基づき、取得したデバイス情報を親局に送信する。

親局は、デバイス情報リクエストに対する応答として、子機から当該子機側のデバイス情報を収取する。そして、親局は、収集した子機側のデバイス情報に基づき、マルチキャストの対象となる子機（例えば、通信装置１０−４＃１〜１０−４＃Ｎ）の中から、ＢＡＲの宛先とする子機を決定する。

なお、以降の動作については、前述した第４の実施形態に係る通信システム（図２８参照）と同様である。即ち、親局は、対象となる複数の子機に対してデータをマルチキャストし、その後、ＢＡＲの宛先として決定した子機に対してＢＡＲを送信する。子機は、ＢＡＲを受信した場合には、対応するマルチキャストデータの受信状況に応じたＢＡを親局に送信する。親局は、ＢＡＲに対する応答として子機から送信されるＢＡに基づき、当該子機におけるマルチキャストデータの受信状況を認識する。

また、親局である通信装置１０−５＃０は、子機に対してＢＡＲを送信するまでに、ＢＡＲの宛先を決定できれば、ＢＡＲの宛先の決定に係る各処理（即ち、デバイス情報の収集や当該デバイス情報に基づくＢＡＲの宛先とする子機の決定に係る処理）の実行タイミングは特に限定されない。例えば、通信装置１０−５＃０は、マルチキャストデータの送信後に、各子機に対してデバイス情報リクエストを送信し、その応答として当該子機から取得するデバイス情報に基づきＢＡＲの宛先とする子機を決定し、その後に、宛先として決定した子機に対してＢＡＲを送信してもよい。

＜７−３．まとめ＞
以上、説明したように、本開示の第５の実施形態に係る通信システムでは、親局は、各子機から、子機側の通信状況を示す各種情報（即ち、デバイス情報）を収集し、収集した当該情報に基づきＢＡＲの宛先とする子機を決定する。このような構成により、親局は、例えば、収集した各子機のデバイス情報に基づき、マルチキャストデータの送信時における子機との間の通信の特性（例えば、パケットロスレートや遅延時間）を推定することが可能である。これにより、親局は、例えば、推定した通信の特性が、要求値を超えない範囲で、ＢＡＲ宛先数を決定することが可能となる。即ち、本実施形態に係る通信システムに依れば、子機側で取得された情報を基に親局と子機との間の通信状態を推定し、推定結果に基づき、より好適な態様で、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

＜８．応用例＞
本開示に係る技術は、様々な製品へ応用可能である。例えば、子機として動作する通信装置１０は、スマートフォン、タブレットＰＣ（Personal Computer）、ノートＰＣ、携帯型ゲーム端末若しくはデジタルカメラなどのモバイル端末、テレビジョン受像機、プリンタ、デジタルスキャナ若しくはネットワークストレージなどの固定端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、子機は、スマートメータ、自動販売機、遠隔監視装置又はＰＯＳ（Point Of Sale）端末などの、Ｍ２Ｍ（Machine To Machine）通信を行う端末（ＭＴＣ（Machine Type Communication）端末ともいう）として実現されてもよい。さらに、子機は、これら端末に搭載される無線通信モジュール（例えば、１つのダイで構成される集積回路モジュール）であってもよい。

一方、例えば、親局として動作する通信装置１０は、ルータ機能を有し又はルータ機能を有しない無線ＬＡＮアクセスポイント（無線基地局ともいう）として実現されてもよい。また、親局は、モバイル無線ＬＡＮルータとして実現されてもよい。さらに、親局は、これら装置に搭載される無線通信モジュール（例えば、１つのダイで構成される集積回路モジュール）であってもよい。

［８−１．第１の応用例］
図２９は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１３、アンテナスイッチ９１４、アンテナ９１５、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。

プロセッサ９０１は、例えばＣＰＵ（Central Processing Unit）又はＳｏＣ（System on Chip）であってよく、スマートフォン９００のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ９０２は、ＲＡＭ（Random Access Memory）及びＲＯＭ（Read Only Memory）を含み、プロセッサ９０１により実行されるプログラム及びデータを記憶する。ストレージ９０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース９０４は、メモリーカード又はＵＳＢ（Universal Serial Bus）デバイスなどの外付けデバイスをスマートフォン９００へ接続するためのインタフェースである。

カメラ９０６は、例えば、ＣＣＤ（Charge Coupled Device）又はＣＭＯＳ（Complementary Metal Oxide Semiconductor）などの撮像素子を有し、撮像画像を生成する。センサ９０７は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン９０８は、スマートフォン９００へ入力される音声を音声信号へ変換する。入力デバイス９０９は、例えば、表示デバイス９１０の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９１０は、液晶ディスプレイ（ＬＣＤ）又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの画面を有し、スマートフォン９００の出力画像を表示する。スピーカ９１１は、スマートフォン９００から出力される音声信号を音声に変換する。

無線通信インタフェース９１３は、ＩＥＥＥ８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ、１１ａｃ及び１１ａｄなどの無線ＬＡＮ標準のうちの１つ以上をサポートし、無線通信を実行する。無線通信インタフェース９１３は、インフラストラクチャーモードにおいては、他の装置と無線ＬＡＮアクセスポイントを介して通信し得る。また、無線通信インタフェース９１３は、アドホックモード又はＷｉ−Ｆｉ Ｄｉｒｅｃｔ（登録商標）等のダイレクト通信モードにおいては、他の装置と直接的に通信し得る。なお、Ｗｉ−Ｆｉ Ｄｉｒｅｃｔでは、アドホックモードとは異なり２つの端末の一方がアクセスポイントとして動作するが、通信はそれら端末間で直接的に行われる。無線通信インタフェース９１３は、典型的には、ベースバンドプロセッサ、ＲＦ（Radio Frequency）回路及びパワーアンプなどを含み得る。無線通信インタフェース９１３は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を集積したワンチップのモジュールであってもよい。無線通信インタフェース９１３は、無線ＬＡＮ方式に加えて、近距離無線通信方式、近接無線通信方式又はセルラ通信方式などの他の種類の無線通信方式をサポートしてもよい。アンテナスイッチ９１４は、無線通信インタフェース９１３に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９１５の接続先を切り替える。アンテナ９１５は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９１３による無線信号の送信及び受信のために使用される。

なお、図２９の例に限定されず、スマートフォン９００は、複数のアンテナ（例えば、無線ＬＡＮ用のアンテナ及び近接無線通信方式用のアンテナ、など）を備えてもよい。その場合に、アンテナスイッチ９１４は、スマートフォン９００の構成から省略されてもよい。

バス９１７は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１３及び補助コントローラ９１９を互いに接続する。バッテリー９１８は、図中に破線で部分的に示した給電ラインを介して、図２９に示したスマートフォン９００の各ブロックへ電力を供給する。補助コントローラ９１９は、例えば、スリープモードにおいて、スマートフォン９００の必要最低限の機能を動作させる。

図２９に示したスマートフォン９００において、図５を用いて説明したデータ処理部１１、通信部１２、及び制御部１８は、無線通信インタフェース９１３において実装されてもよい。また、これら機能の少なくとも一部は、プロセッサ９０１又は補助コントローラ９１９において実装されてもよい。例えば、制御部１８が、チャネルの混雑度の観測結果に基づいてＢＡＲの宛先となるスマートフォン９００を決定し、通信部１２が、当該スマートフォン９００に対してのみＢＡＲを送信することにより、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

なお、スマートフォン９００は、プロセッサ９０１がアプリケーションレベルでアクセスポイント機能を実行することにより、無線アクセスポイント（ソフトウェアＡＰ）として動作してもよい。また、無線通信インタフェース９１３が無線アクセスポイント機能を有していてもよい。

［８−２．第２の応用例］
図３０は、本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。カーナビゲーション装置９２０は、プロセッサ９２１、メモリ９２２、ＧＰＳ（Global Positioning System）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、アンテナスイッチ９３４、アンテナ９３５及びバッテリー９３８を備える。

プロセッサ９２１は、例えばＣＰＵ又はＳｏＣであってよく、カーナビゲーション装置９２０のナビゲーション機能及びその他の機能を制御する。メモリ９２２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９２１により実行されるプログラム及びデータを記憶する。

ＧＰＳモジュール９２４は、ＧＰＳ衛星から受信されるＧＰＳ信号を用いて、カーナビゲーション装置９２０の位置（例えば、緯度、経度及び高度）を測定する。センサ９２５は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース９２６は、例えば、図示しない端子を介して車載ネットワーク９４１に接続され、車速データなどの車両側で生成されるデータを取得する。

コンテンツプレーヤ９２７は、記憶媒体インタフェース９２８に挿入される記憶媒体（例えば、ＣＤ又はＤＶＤ）に記憶されているコンテンツを再生する。入力デバイス９２９は、例えば、表示デバイス９３０の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９３０は、ＬＣＤ又はＯＬＥＤディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ９３１は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。

無線通信インタフェース９３３は、ＩＥＥＥ８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ、１１ａｃ及び１１ａｄなどの無線ＬＡＮ標準のうちの１つ以上をサポートし、無線通信を実行する。無線通信インタフェース９３３は、インフラストラクチャーモードにおいては、他の装置と無線ＬＡＮアクセスポイントを介して通信し得る。また、無線通信インタフェース９３３は、アドホックモード又はＷｉ−Ｆｉ Ｄｉｒｅｃｔ等のダイレクト通信モードにおいては、他の装置と直接的に通信し得る。無線通信インタフェース９３３は、典型的には、ベースバンドプロセッサ、ＲＦ回路及びパワーアンプなどを含み得る。無線通信インタフェース９３３は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を集積したワンチップのモジュールであってもよい。無線通信インタフェース９３３は、無線ＬＡＮ方式に加えて、近距離無線通信方式、近接無線通信方式又はセルラ通信方式などの他の種類の無線通信方式をサポートしてもよい。アンテナスイッチ９３４は、無線通信インタフェース９３３に含まれる複数の回路の間でアンテナ９３５の接続先を切り替える。アンテナ９３５は、単一の又は複数のアンテナ素子を有し、無線通信インタフェース９３３による無線信号の送信及び受信のために使用される。

なお、図３０の例に限定されず、カーナビゲーション装置９２０は、複数のアンテナを備えてもよい。その場合に、アンテナスイッチ９３４は、カーナビゲーション装置９２０の構成から省略されてもよい。

バッテリー９３８は、図中に破線で部分的に示した給電ラインを介して、図３０に示したカーナビゲーション装置９２０の各ブロックへ電力を供給する。また、バッテリー９３８は、車両側から給電される電力を蓄積する。

図３０に示したカーナビゲーション装置９２０において、図５を用いて説明したデータ処理部１１、通信部１２、及び制御部１８は、無線通信インタフェース９３３において実装されてもよい。また、これら機能の少なくとも一部は、プロセッサ９２１において実装されてもよい。例えば、制御部１８が、チャネルの混雑度の観測結果に基づいてＢＡＲの宛先となるカーナビゲーション装置９２０を決定し、通信部１２が、当該カーナビゲーション装置９２０に対してのみＢＡＲを送信することにより、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

また、無線通信インタフェース９３３は、上述した親局である通信装置１０として動作し、車両に乗るユーザが有する端末に無線接続を提供してもよい。その際、例えば、制御部１８は、チャネルの混雑度の観測結果に基づいてＢＡＲの宛先となる他の通信装置を決定し、通信部１２が、当該他の通信装置に対してのみＢＡＲを送信することにより、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。車両側モジュール９４２は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク９４１へ出力する。

［８−３．第３の応用例］
図３１は、本開示に係る技術が適用され得る無線アクセスポイント９５０の概略的な構成の一例を示すブロック図である。無線アクセスポイント９５０は、コントローラ９５１、メモリ９５２、入力デバイス９５４、表示デバイス９５５、ネットワークインタフェース９５７、無線通信インタフェース９６３、アンテナスイッチ９６４及びアンテナ９６５を備える。

コントローラ９５１は、例えばＣＰＵ又はＤＳＰ（Digital Signal Processor）であってよく、無線アクセスポイント９５０のＩＰ（Internet Protocol）レイヤ及びより上位のレイヤの様々な機能（例えば、アクセス制限、ルーティング、暗号化、ファイアウォール及びログ管理など）を動作させる。メモリ９５２は、ＲＡＭ及びＲＯＭを含み、コントローラ９５１により実行されるプログラム、及び様々な制御データ（例えば、端末リスト、ルーティングテーブル、暗号鍵、セキュリティ設定及びログなど）を記憶する。

入力デバイス９５４は、例えば、ボタン又はスイッチなどを含み、ユーザからの操作を受け付ける。表示デバイス９５５は、ＬＥＤランプなどを含み、無線アクセスポイント９５０の動作ステータスを表示する。

ネットワークインタフェース９５７は、無線アクセスポイント９５０が有線通信ネットワーク９５８に接続するための有線通信インタフェースである。ネットワークインタフェース９５７は、複数の接続端子を有してもよい。有線通信ネットワーク９５８は、イーサネット（登録商標）などのＬＡＮであってもよく、又はＷＡＮ（Wide Area Network）であってもよい。

無線通信インタフェース９６３は、ＩＥＥＥ８０２．１１ａ、１１ｂ、１１ｇ、１１ｎ、１１ａｃ及び１１ａｄなどの無線ＬＡＮ標準のうちの１つ以上をサポートし、近傍の端末へアクセスポイントとして無線接続を提供する。無線通信インタフェース９６３は、典型的には、ベースバンドプロセッサ、ＲＦ回路及びパワーアンプなどを含み得る。無線通信インタフェース９６３は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を集積したワンチップのモジュールであってもよい。アンテナスイッチ９６４は、無線通信インタフェース９６３に含まれる複数の回路の間でアンテナ９６５の接続先を切り替える。アンテナ９６５は、単一の又は複数のアンテナ素子を有し、無線通信インタフェース９６３による無線信号の送信及び受信のために使用される。

図３１に示した無線アクセスポイント９５０において、図５を用いて説明したデータ処理部１１、通信部１２、及び制御部１８は、無線通信インタフェース９６３において実装されてもよい。また、これら機能の少なくとも一部は、コントローラ９５１において実装されてもよい。例えば、制御部１８は、チャネルの混雑度の観測結果に基づいてＢＡＲの宛先となる他の通信装置を決定し、通信部１２が、当該他の通信装置に対してのみＢＡＲを送信することにより、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

＜９．むすび＞
以上、本開示の第１の実施形態に依れば、チャネルの混雑度の観測結果に応じて、システム全体の特性が当該システムの要求値を超えない範囲内でＢＡＲの宛先となる子機の数を決定することが可能となる。そのため、親局が複数の子機に対してデータをマルチキャストするような状況下においても、親局と各子機との間の通信の状況に応じて、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

また、本開示の第２の実施形態に依れば、子機から通知される通信特性の測定結果に応じて、ＢＡＲの宛先とする子機を設定することが可能なため、通信状態のより良い子機をＢＡＲの宛先として設定することで、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

また、本開示の第３の実施形態に依れば、子機側で測定されたチャネルの混雑度に応じて、ＢＡＲの宛先とする子機を決定することが可能となる。そのため、例えば、親局と子機との間で周囲の通信の状態や状況が異なるような状況下においても、子機側における通信の状態や状況に応じて、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

また、本開示の第４の実施形態に依れば、親局側の通信状況を示す各種情報に基づき、親局と子機との間の通信の特性を推定することが可能なため、当該特性が要求値を超えない範囲でＢＡＲ宛先数を決定することで、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

また、本開示の第５の実施形態に依れば、子機側の通信状況を示す各種情報に基づき、親局と子機との間の通信の特性を推定することが可能なため、当該特性が要求値を超えない範囲でＢＡＲ宛先数を決定することで、通信の信頼性を担保しつつ通信リソースの消費を抑制することが可能となる。

なお、上記に説明した例では、親局と子機とを明示的に区別し、親局側が子機へのデータの送達を確認する例について説明したが、本開示に係る通信システムの構成は、必ずしも同構成には限定されない。具体的な一例として、本開示に係る通信システムは、所謂メッシュネットワークを形成し、ネットワーク内の複数の通信装置（通信機能を有する機器）が相互にデータを送受信するように構成されていてもよい。この場合には、データの送信元となる通信装置が前述した親局に相当し、データの送信先となる通信装置が前述した子機に相当するものとして動作するように構成されていればよい。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
無線の通信経路を介して接続された通信装置との間の通信を制御する制御部と、
１以上の前記通信装置との間の前記通信に関する情報を取得する取得部と、
を備え、
前記制御部は、取得された前記通信に関する情報に基づき、前記通信装置に対するデータの送達を確認するための応答の送信要求を送信する当該通信装置を決定する、
通信制御装置。
（２）
前記制御部は、複数の前記通信装置に対して前記データが送信されるように制御する場合に、取得された当該複数の通信装置との間の前記通信に関する情報に基づき、前記送信要求を送信する当該通信装置を決定する、前記（１）に記載の通信制御装置。
（３）
前記制御部は、取得された前記通信に関する情報に基づき、前記送信要求を送信する前記通信装置の数を決定し、当該数の範囲内で、当該送信要求を送信する前記通信装置を決定する、前記（１）または（２）に記載の通信制御装置。
（４）
前記取得部は、前記通信に関する情報として、前記通信装置に対して前記データを送信するためのチャネルの状況を示す情報を取得する、前記（１）〜（３）のいずれか一項に記載の通信制御装置。
（５）
前記取得部は、前記チャネルの状況を示す情報として、当該チャネルに対応する通信リソースの使用状況を示す情報を取得する、前記（４）に記載の通信制御装置。
（６）
前記取得部は、前記通信の監視結果に基づき、前記通信リソースの使用状況を示す情報を取得する、前記（５）に記載の通信制御装置。
（７）
前記取得部は、前記通信装置から、前記通信リソースの使用状況を示す情報を取得する、前記（５）に記載の通信制御装置。
（８）
前記取得部は、前記チャネルの状況を示す情報として、過去に当該チャネルを介して前記通信装置へデータを送信したときの、当該送信に要した時間を示す情報を取得する、前記（４）に記載の通信制御装置。
（９）
前記制御部は、前記送信要求の送信先の候補となる条件を示す情報が、前記通信装置に送信されるように制御し、
前記取得部は、前記通信に関する情報として、前記送信要求の送信を要請する情報を前記通信装置から取得する、
前記（１）〜（３）のいずれか一項に記載の通信制御装置。
（１０）
前記制御部は、前記通信装置に対して前記データを送信するためのチャネルの状況に応じて前記条件を決定する、前記（９）に記載の通信制御装置。
（１１）
前記取得部は、前記データの送信元における通信の状況を示す情報を取得し、
前記制御部は、取得された前記通信の状況を示す情報と、あらかじめ決められたデータの再送回数及び過去の実績に基づき予測される前記再送回数のいずれかと、に基づき、前記送信要求を送信する前記通信装置を決定する、
前記（１）〜（３）のいずれか一項に記載の通信制御装置。
（１２）
前記取得部は、前記通信装置における通信の状況を示す情報を取得し、
前記制御部は、取得された前記通信の状況を示す情報と、あらかじめ決められたデータの再送回数及び過去の実績に基づき予測される前記再送回数のいずれかと、に基づき、前記送信要求を送信する前記通信装置を決定する、
前記（１）〜（３）のいずれか一項に記載の通信制御装置。
（１３）
無線の通信経路を介して接続された通信装置との間の通信に関する情報に応じて、データの送達を確認するための応答の送信要求の送信先に決定された場合に、前記通信装置から送信された前記送信要求を取得する取得部と、
取得された前記送信要求に対する、前記データの受信状況に応じた前記応答が、前記通信装置に送信させるように制御する制御部と、
を備える、通信制御装置。
（１４）
前記取得部は、前記送信要求が取得される前に、当該送信要求の送信先の候補となる条件を示す情報を前記通信装置から取得し、
前記制御部は、前記条件に応じて、前記送信要求の送信を要請する情報が前記通信装置に送信されるように制御する、
前記（１３）に記載の通信制御装置。
（１５）
前記制御部は、前記通信に関する情報として、前記通信装置が前記データを送信するためのチャネルの状況を示す情報が、当該通信装置に送信されるように制御し、
前記取得部は、前記通信に関する情報が前記通信装置に送信された後に、前記送信要求を取得する、
前記（１３）に記載の通信制御装置。
（１６）
前記制御部は、前記通信に関する情報として、前記データの送信先における通信の状況を示す情報が、前記通信装置に送信されるように制御し、
前記取得部は、前記通信に関する情報が前記通信装置に送信された後に、前記送信要求を取得する、
前記（１３）に記載の通信制御装置。
（１７）
プロセッサが、無線の通信経路を介して接続された通信装置との間の通信を制御することと、
１以上の前記通信装置との間の前記通信に関する情報を取得することと、
取得された前記通信に関する情報に基づき、前記通信装置に対するデータの送達を確認するための応答の送信要求を送信する当該通信装置を決定することと、
を含む、通信制御方法。
（１８）
無線の通信経路を介して接続された通信装置との間の通信に関する情報に応じて、データの送達を確認するための応答の送信要求の送信先に決定された場合に、前記通信装置から送信された前記送信要求を取得することと、
プロセッサが、取得された前記送信要求に対する、前記データの受信状況に応じた前記応答が、前記通信装置に送信させるように制御することと、
を含む、通信制御方法。
（１９）
コンピュータに、
無線の通信経路を介して接続された通信装置との間の通信を制御することと、
１以上の前記通信装置との間の前記通信に関する情報を取得することと、
取得された前記通信に関する情報に基づき、前記通信装置に対するデータの送達を確認するための応答の送信要求を送信する当該通信装置を決定することと、
を実行させる、プログラム。
（２０）
コンピュータに、
無線の通信経路を介して接続された通信装置との間の通信に関する情報に応じて、データの送達を確認するための応答の送信要求の送信先に決定された場合に、前記通信装置から送信された前記送信要求を取得することと、
取得された前記送信要求に対する、前記データの受信状況に応じた前記応答が、前記通信装置に送信させるように制御することと、
を実行させる、プログラム。

１０、１０−１〜１０−５ 通信装置
１１ データ処理部
１２ 通信部
１３ 変復調部
１４ 信号処理部
１５ チャネル推定部
１６ 無線インタフェース部
１７ 増幅部
１８ 制御部

Claims (6)

1. 自装置と無線の通信経路を介して接続された１以上の通信装置との間のマルチキャスト通信を制御する制御部と、
   自装置と前記通信装置それぞれとの間の通信リソースの使用状況を示す情報をキャリアセンスにより取得する取得部と、
   を備え、
   前記制御部は、取得された前記通信リソースの使用状況を示す情報に含まれる前記通信装置に対してデータを送信するためのチャネルの状況を示す情報に基づいて前記チャネルの混雑度を観測し、前記通信装置へ前記データをマルチキャスト送信する際に、前記混雑度が大きいほど小さくなるように前記データの送達を確認する前記通信装置の数を決定する、
   通信制御装置。
2. 前記制御部は、前記混雑度に基づいて決定した前記通信装置の数の範囲内で、前記データの送達を確認する送信要求を送信する前記通信装置を決定する、請求項１に記載の通信制御装置。
3. 前記制御部は、前記混雑度と前記通信装置の数とを対応付けた制御テーブルをあらかじめ保存した領域から読み出し、前記制御テーブルに基づいて前記通信装置の数を決定する、請求項１または２に記載の通信制御装置。
4. プロセッサが、
   自装置と無線の通信経路を介して接続された１以上の通信装置との間のマルチキャスト通信を制御することと、
   自装置と前記通信装置それぞれとの間の通信リソースの使用状況を示す情報をキャリアセンスにより取得することと、
   取得された前記通信リソースの使用状況を示す情報に含まれる前記通信装置に対してデータを送信するためのチャネルの状況を示す情報に基づいて前記チャネルの混雑度を観測し、前記通信装置へ前記データをマルチキャスト送信する際に、前記混雑度が大きいほど小さくなるように前記データの送達を確認する前記通信装置の数を決定することと、
   を含む、通信制御方法。
5. コンピュータに、
   自装置と無線の通信経路を介して接続された１以上の通信装置との間のマルチキャスト通信を制御することと、
   自装置と前記通信装置それぞれとの間の通信リソースの使用状況を示す情報をキャリアセンスにより取得することと、
   取得された前記通信リソースの使用状況を示す情報に含まれる前記通信装置に対してデータを送信するためのチャネルの状況を示す情報に基づいて前記チャネルの混雑度を観測し、前記通信装置へ前記データをマルチキャスト送信する際に、前記混雑度が大きいほど小さくなるように前記データの送達を確認する前記通信装置の数を決定することと、
   を実行させる、プログラム。
6. 通信制御装置と、
   前記通信制御装置と無線の通信経路を介して接続された１以上の通信装置と、
   を備え、
   前記通信制御装置は、
   前記通信装置との間のマルチキャスト通信を制御する制御部と、
   前記通信装置それぞれとの間の通信リソースの使用状況を示す情報をキャリアセンスにより取得する取得部と、
   を備え、
   前記制御部は、取得された前記通信リソースの使用状況を示す情報に含まれる前記通信装置に対してデータを送信するためのチャネルの状況を示す情報に基づいて前記チャネルの混雑度を観測し、前記通信装置へ前記データをマルチキャスト送信する際に、前記混雑度が大きいほど小さくなるように前記データの送達を確認する前記通信装置の数を決定する、システム。

Images