(57)【要約】【課題】クライアント端末間で映像ストリームを伝送中に、管理端末が動作しなくなった場合でも、クライアント間の同期を保ち、映像ストリームを途切れることなく伝送させるとともに、再びネットワーク内に管理端末を生起させるデータ送受信装置を提供する。【解決手段】管理端末は、ＦＣＨフレームの生成が終了すると、次の管理端末候補の優先順位情報を生成する（Ｓ２６）。優先順位情報の生成の後、管理端末は、各クライアント端末に向けて、ＦＣＨフレームを送信し（Ｓ２７）、続いて次の管理端末候補の優先順位情報を送信（Ｓ２８）する。優先順位情報は、受信データ用に固定帯域を割り当てられているクライアント端末の順位が上位になるよう設定する。【選択図】図７
2008270945.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークシステムの複数の端末のそれぞれに含まれるデータ送受信装置であって、
前記複数の端末は、他の端末を管理する管理端末と、該管理端末により管理されるクライアント端末を複数含み、
前記データ送受信装置は、
１フレーム内に含まれる同期情報およびスケジュール情報を検出する制御情報検出部と、
前記同期情報および前記スケジュール情報が自機および他の前記クライアント端末において正常に受信できたか否かの受信状況情報を確認するとともに、前記受信状況情報に基づいて前記同期情報および前記スケジュールの送信元が正常に動作しているかどうかを判断する制御部とを備え、
前記データ送受信装置は、前記管理端末として機能する場合に、前記同期情報および前記スケジュール情報を定期的に出力するとともに、新たな管理端末となる前記クライアント端末の優先順位を定め、
前記データ送受信装置は、前記クライアント端末として機能する場合に、前記管理端末から送信される前記同期情報および前記スケジュール情報に基づいて、映像データおよび制御データの送受信を実行し、
前記制御部において、前記管理端末から出力される前記受信状況情報に基づいて、前記管理端末が正常に動作していないと判断された場合は、前記優先順位に従って、前記クライアント端末の中から前記新たな管理端末を決定し、決定した前記新たな管理端末が、前記管理端末の動作を承継する、データ送受信装置。
【請求項２】
前記データ送受信装置は、
前記同期情報および前記スケジュール情報の少なくとも一方が受信できなかった場合、前回までに受信した各フレーム内の前記スケジュール情報に基づいて検出したクロックの誤差情報を用いて内部の時刻情報を補正する、ネットワーク制御データ解析部を備える、請求項１記載のデータ送受信装置。
【請求項３】
前記データ送受信装置は、前記クライアント端末として機能する場合に、前記同期情報および前記スケジュール情報が自機および他の前記クライアント端末において、正常に受信できなかった場合に、前記管理端末が正常に動作していないと判断する、請求項１記載のデータ送受信装置。
【請求項４】
前記データ送受信装置は、前記管理端末として機能する場合に、リアルタイムが要求されるデータの送信要求のあった前記クライアント端末に対しては、固定帯域を割り当てる固定帯域割当を実施する、請求項１記載のデータ送受信装置。
【請求項５】
前記データ送受信装置は、前記管理端末として機能する場合に、前記制御部において、固定帯域割当てが実施されて前記データを受信中の前記クライアント端末に対して、前記新たな管理端末となるべき前記優先順位を設定する、請求項４記載のデータ送受信装置。
【請求項６】
前記データ送受信装置は、前記クライアント端末として機能する場合に、前記制御部において、前記管理端末が正常に動作していないと判断され、かつ、自機が、前記新たな管理端末の候補としての前記優先順位が１位に設定されている場合に、自らが前記新たな管理端末候補となったことを、生起情報として他の前記クライアント端末に通知し、他の前記クライアント端末からの承認の通知を受けた場合には、前記新たな管理端末として、前記管理端末の動作を承継する、請求項１記載のデータ送受信装置。
【請求項７】
前記データ送受信装置は、前記クライアント端末として機能する場合に、他の前記クライアント端末から前記生起情報を受信した場合、前記制御部において、自機が、前記新たな管理端末の候補としての前記優先順位が１位でないと確認された場合は、前記生起情報を送信した、他の前記クライアント端末に対して、前記承認の通知を送信する、請求項６記載のデータ送受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ送受信装置に関し、特に、無線通信あるいは高速ＰＬＣ（Power Line Communication）などのネットワークシステムにおいて映像ストリーム等のデータを送受信するデータ送受信装置に関する。
【背景技術】
【０００２】
昨今の無線通信、あるいは高速ＰＬＣなどのネットワークシステムの高速化に伴い、これらのシステムを用いて家庭内の映像ネットワークを構築する研究がなされている。無線通信、あるいは高速ＰＬＣなどを用いて、映像あるいは音声などのリアルタイム性を要求されるデータを送受信するためには、映像、音声を途切れなくスムーズに伝送するために、予め送信するデータの伝送帯域を確保した上で伝送する必要がある。そのため、無線ＬＡＮ（Local Area Network）等では、ＴＤＭＡ（Time Division Multiple Access）方式を採用し、データの伝送帯域を予め確保してデータを伝送する方式なども導入されつつある。具体的には、例えばＡＲＩＢ（社団法人電波産業会）にて標準規格化されたＨｉＳＷＡＮａ（High Speed Wireless Access Networking Type a：ARIB STD-T70 1.0版）などがある。
【０００３】
以下、上記ＨｉＳＷＡＮａ規格に採用されたＴＤＭＡ方式の概要を簡単に説明する。ＨｉＳＷＡＮａで採用されたＴＤＭＡ方式は、管理端末と呼ばれる１台の端末（データ送受信装置）によりネットワーク内の各端末（データ送受信装置）が管理される。なお、管理端末により管理される端末をクライアント端末と呼称する。
【０００４】
管理端末は、ネットワーク全体の時刻同期を管理するために、Ｂｅａｃｏｎ信号と呼ばれるパケットデータ（以下、ＢＣＨ：Broadcast CHannelと表記）を予め定められた周期で同報通信する（ＨｉＳＷＡＮａでは２ｍｓ周期）。
【０００５】
ネットワーク内に配置された各クライアント端末は、ＢＣＨを受信すると、それを基準に、端末内の基準時刻情報をリセットするとともに、管理端末より送信される各種制御パケットの受信準備を開始する。管理端末は、ＢＣＨ送出後、ネットワークに接続された各クライアント端末のデータ送信スケジュールを含むネットワークシステム制御用のパケットデータ（以下、ＦＣＨ：Frame CHannelと表記）を、各クライアント端末に対して同報通信する。
【０００６】
上記ＦＣＨには、ネットワークに接続された各クライアント端末のデータ送信、および受信のスケジュール（データの送受信スロット情報（送受信開始タイミング情報、データ送受信時間情報など））が付加され送信される。各クライアント端末は、ＦＣＨを受信すると、自端末がデータを受信するタイミングおよび自端末がデータを送信するタイミングを検出する。
【０００７】
管理端末は、ＦＣＨの送信に引き続き、各クライアント端末に対して送信要求受信通知のパケットデータ（以下、ＡＣＨ：Access feedback CHannelと表記）を送信する。管理端末より、上記ＢＣＨ、ＦＣＨ、ＡＣＨの各パケットデータの送信が完了すると、ＦＣＨにて通知されたスケジュールに基づき各クライアント端末はパケットデータの受信、および送信動作を開始する（以下、各端末間でデータの送受信を行う期間をＴＣＨと表記）。
【０００８】
ＴＤＭＡ方式では、管理端末は送信したいデータを持つクライアント端末についてのみデータ送信スロットをスケジューリングする。従って、送信したいデータを持つクライアント端末は、管理端末に対して自端末のデータを送信するためのスロットを割り振るよう要求する必要がある。上記ＨｉＳＷＡＮａ規格で採用されたＴＤＭＡ方式では、各クライアント端末より送信リクエストを受け付けるため、１Ｂｅａｃｏｎ周期内（以下、１フレームと表記）の最後に、各端末からの上記送信スロット要求リクエスト（帯域割り当て要求）を受け付けるためのＣＳＭＡ（Carrier Sense Multiple Access）期間（以下、ＲＣＨ：Random access CHannel期間と表記）を準備している。
【０００９】
管理端末は、ＲＣＨ期間に上記送信スロット要求リクエストを受け取った端末に対しては、次のＢｅａｃｏｎ周期内のＡＣＨにて帯域割り当て要求を受け取った旨を通知する。
【００１０】
次に、上述したＨｉＳＷＡＮａ規格をベースとしたＴＤＭＡ方式を、例えば高速ＰＬＣに適用した従来のデータ送受信装置におけるシステム構成について説明する。
【００１１】
一般に、無線ＬＡＮや高速ＰＬＣをベースとしたデータ送受信装置では、クライアント端末間でデータの送受信を実施する際は、管理端末経由でデータの送受信を実施する。具体的には、第１のクライアント端末から第２のクライアント端末にデータを送信する際は、第１のクライアント端末は管理端末に対して送信データを送り、データを受け取った管理端末は第２のクライアント端末に受信したデータを送信する。この場合、第１のクライアント端末から第２のクライアント端末に対してのデータの送信であるにもかかわらず、管理端末を経由するため、限られた帯域を２倍使用することになる。
【００１２】
このような問題を解決するため、クライアント端末間で直接にデータの送受信を実施する方法がある。すなわち、ＴＤＭＡ方式では、先に説明したように、管理端末と各クライアント端末間の同期は、定期的に管理端末から出力されるＢｅａｃｏｎ信号によって確保されている。従って、スケジューリングの概念を拡張することにより同期の取れたクライアント端末間の直接通信が可能となる。
【００１３】
例えば、特許文献１では、無線ネットワーク上で、特定の無線端末が管理端末（マスタ）として動作し、全ての無線端末が管理端末に同期して動作するのではなく、アドホックネットワークを構成して、近隣の無線端末間で自律分散的に同期を取る同期方式が開示されている。
【００１４】
【特許文献１】特開２００５−３４１１４８号公報
【発明の開示】
【発明が解決しようとする課題】
【００１５】
しかしながら、高速ＰＬＣを家庭内で使用するＡＶ（Audio Visual）機器などに内蔵した場合、以下のような問題が発生する。例えば、居間に置かれたＡＶレコーダをクライアント端末の１つとし、再生された映像ストリームを他のクライアント端末である寝室に置かれたＴＶ（Television）システムに送信中に、管理端末である、居間にあるＴＶシステムの電源コンセントがユーザによって抜かれた場合を考える。
【００１６】
この場合、管理端末である居間にあるＴＶシステムの電源が切られたため、ＰＬＣネットワークとしてはＢＣＨ、ＦＣＨ等の制御フレーム情報を送信する管理端末がなくなり、各クライアント端末間の同期が取れなくなるとともに、スケジュールデータが受信できなくなるため、居間にあるＡＶレコーダと寝室にあるＴＶシステムとの間の映像ストリームの送受信が中断するといった問題点があった。
【００１７】
例えば、特許文献１で述べられている自律分散型のアドホックネットワークでは、近隣端末間の同期を取ることはできるが、映像ストリームなどのリアルタイム性の要求されるデータを伝送する場合、送信される映像ストリームの送信帯域が確保されるとは限らないので、表示画像が一時的に止まる、あるいは乱れるといった問題が発生する。
【００１８】
また、特許文献１の技術では、各クライアント端末が同期を取るために、タイムスロット（スーパーフレームを６４個に分割したものの１つ）内に、自己のビーコン送信位置が設定され、一定周期でビーコンが送信される。そのため、データを送信しない端末も一定周期でビーコンを送出するため送信帯域が必要となり、送信帯域を無駄に使用してしまうといった問題点があった。
【００１９】
特に高速ＰＬＣでは１ＯＦＤＭシンボルのシンボル長が長く設定されている場合が多い。従って、ネットワークに接続されている各クライアント端末が一定周期でビーコンを送出した場合、同期を取るためのオーバーヘッド（無駄な帯域使用）期間が長くなるといった問題点があった。例えば、１ＯＦＤＭシンボル長を５０μｓとし、プリアンブルを４シンボル、ペイロードを１シンボルとした場合でも、１クライアント端末あたり少なくともビーコン送出に２５０μｓの伝送再域を使用することになる。
【００２０】
本発明は上記のような問題点を解消するためになされたもので、クライアント端末間でデータの送受信が実施可能なネットワークを構成するデータ送受信装置において、クライアント端末間で映像ストリームを伝送中に、管理端末の電源が切られるなどして管理端末が動作しなくなった場合でも、クライアント間の同期を保ち、映像ストリームを途切れることなく伝送させるとともに、再びネットワーク内に管理端末を生起させるデータ送受信装置を提供することを目的とする。
【課題を解決するための手段】
【００２１】
本発明に係る請求項１記載のデータ送受信装置は、ネットワークシステムの複数の端末のそれぞれに含まれるデータ送受信装置であって、前記複数の端末は、他の端末を管理する管理端末と、該管理端末により管理されるクライアント端末を複数含み、前記データ送受信装置は、１フレーム内に含まれる同期情報およびスケジュール情報を検出する制御情報検出部と、前記同期情報および前記スケジュール情報が自機および他の前記クライアント端末において正常に受信できたか否かの受信状況情報を確認するとともに、前記受信状況情報に基づいて前記同期情報および前記スケジュールの送信元が正常に動作しているかどうかを判断する制御部とを備え、前記データ送受信装置は、前記管理端末として機能する場合に、前記同期情報および前記スケジュール情報を定期的に出力するとともに、新たな管理端末となる前記クライアント端末の優先順位を定め、前記データ送受信装置は、前記クライアント端末として機能する場合に、前記管理端末から送信される前記同期情報および前記スケジュール情報に基づいて、映像データおよび制御データの送受信を実行し、前記制御部において、前記管理端末から出力される前記受信状況情報に基づいて、前記管理端末が正常に動作していないと判断された場合は、前記優先順位に従って、前記クライアント端末の中から前記新たな管理端末を決定し、決定した前記新たな管理端末が、前記管理端末の動作を承継する。
【発明の効果】
【００２２】
本発明に係る請求項１記載のデータ送受信装置によれば、管理端末が正常に動作していないと判断された場合は、優先順位に従って、クライアント端末の中から新たな管理端末を決定し、決定した新たな管理端末が管理端末の動作を承継するので、クライアント端末間で映像ストリーム等を伝送中に管理端末の電源がオフされた場合でも、映像ストリームを途切れることなく伝送させることができるとともに、再びネットワーク内に新たな管理端末を生起させることができる。
【発明を実施するための最良の形態】
【００２３】
＜Ａ．実施の形態１＞
＜Ａ−１．ネットワークシステムの構成＞
図１は、本発明の実施の形態１に係るデータ送受信装置を備えた高速ＰＬＣネットワークシステムの構成を概略的に示す図である。なお、以下においては、データ送受信装置を端末と呼称する。
【００２４】
図１に示すように、当該高速ＰＬＣネットワークシステムは、ネットワーク全体を管理する管理端末１、ＰＬＣネットワークシステムに接続されたクライアント端末Ａ３、クライアント端末Ｂ５およびクライアント端末Ｂ７と、信号ラインともなる電灯線９とを備え、管理端末１、クライアント端末Ａ３、クライアント端末Ｂ５およびクライアント端末Ｂ７と電灯線９との間は、それぞれ電源コンセント２、４、６および８によって電気的に接続されている。
【００２５】
なお、図１に示された高速ＰＬＣネットワークシステムの構成は、本発明のデータ送受信装置が適用できるシステム構成の一例であり、本発明のデータ送受信装置は、他の構成を持つ高速ＰＬＣネットワークシステム、無線ＬＡＮを用いたネットワークシステム、Ｅｔｈｅｒｎｅｔ（登録商標）を用いたネットワークシステムなどの他のシステムにも適用可能である。
【００２６】
＜Ａ−２．ネットワークシステムの概略動作＞
次に、図１を用いて高速ＰＬＣネットワーク内での管理端末１の動作を中心として、当該ネットワークシステムの概略動作について説明する。なお、実施の形態１では、ＭＡＣ（Media Access Control）方式として、従来技術として説明したＨｉＳＷＡＮａ規格で採用されたＴＤＭＡ方式を採用した場合を例に説明する。
【００２７】
＜Ａ−２−１．管理端末の動作＞
管理端末１は、最初にネットワーク全体の時刻同期を管理するために同期情報としてＢｅａｃｏｎ信号（ＢＣＨ：Broadcast CHannel）を予め定められた周期で同報通信する。ＢＣＨ送信後、管理端末１は高速ＰＬＣネットワーク内の各クライアント端末のデータ受信およびデータ送信のタイミング情報（ＦＣＨ：Frame CHannel）を同報通信する。ＦＣＨ送信後、前フレームで各クライアント端末より出力されるＲＣＨ（Random access CHannel）を受信した場合、ＲＣＨの送信クライアント端末に対して正常受信したことを通知するＡＣＨ（Access feedback CHannel）を出力する。
【００２８】
ＡＣＨ送信後は、ＦＣＨにて送信されたスケジュールに基づき管理端末１、クライアント端末Ａ３、クライアント端末Ｂ５およびクライアント端末Ｃ７は、各クライアント端末間でのデータの送受信を実施する。
【００２９】
ＦＣＨでのスケジュールに基づくデータの送受信が終了すると、各クライアント端末は送信データを持っている場合はＲＣＨの期間に管理端末１に対して帯域割り当て要求を出力する。
【００３０】
また、管理端末１は自身がネットワークから離脱する場合に備え、各クライアント端末に、次の管理端末の候補になるものの優先順位の情報を同報通信する。実施の形態１では、上記優先順位はクライアント端末の送受信状況により流動的に設定（詳細は後述）するものとするが、本発明のデータ送受信装置は、優先順位が各クライアント端末に一意的に設定されたネットワークのシステムにも適用できる。
【００３１】
＜Ａ−２−２．クライアント端末の動作＞
次に、クライアント端末の動作について説明する。クライアント端末は、管理端末１より出力されるＢＣＨを受信すると、そのＢＣＨに基づいてクライアント端末内の基準時刻を同期させる。
【００３２】
基準時刻の同期を実施した後、各クライアント端末は管理端末１より出力されるＦＣＨに基づいて、それぞれのデータ送信タイミングおよびデータ受信タイミングを内部に設定し、データの送信および受信準備を開始する。データの送信の場合は、ＦＣＨに基づく送信時刻が近づくとＰＬＣ送信制御部（詳細は後述）は送信データの生成を開始し、所定のタイミングで電灯線９に送信データを送出する。データの受信の場合は、ＦＣＨに基づく受信時刻になるとＰＬＣ受信制御部（詳細は後述）が受信データを復調し、誤り検出などのデータ受信動作を実施する。
【００３３】
また、各クライアント端末は、管理端末１より出力される次の管理端末の候補になる優先順位の情報を受信し、各クライアント端末内に設定する。管理端末１がネットワークより離脱したと判断した場合、上記で設定した優先順位に基づき、自クライアント端末が新たな管理端末になるように動作、あるいは他クライアント端末が新たな管理端末になるのを承認する動作を実施する（詳細は後述）。
【００３４】
本実施の形態１では、管理端末１は居間のＴＶシステムに内蔵され、クライアント端末Ａは寝室のＴＶシステム３に内蔵され、クライアント端末Ｂは居間のＤＶＤレコーダ５に内蔵され、クライアント端末Ｃは居間のＤＶＤレコーダ７に内蔵されている場合を例にとして以下の説明を行う。また、本発明に係るデータ送受信装置は、ＴＶシステム、ＤＶＤレコーダの内部において、Ｅｔｈｅｒｎｅｔインターフェイスを介して接続されているものとする。
【００３５】
＜Ａ−３．高速ＰＬＣ端末の構成＞
＜Ａ−３−１．データ送受信装置の構成＞
次に、図２〜図５を用いて高速ＰＬＣ端末の構成を説明する。
図２は本発明に係るデータ送受信装置を高速ＰＬＣ端末に適用した場合のデータ送受信装置１０の構成を示すブロック図である。
【００３６】
図２に示すように、データ送受信装置１０は、ＣＰＵ（Central Processing Unit）１１、Ｅｔｈｅｒｎｅｔインターフェイス回路１２、ブリッジインターフェイス回路１３、ブリッジ用メモリ１４、ＰＬＣモデム回路１５、ＰＬＣ送信用メモリ１６、ＰＬＣ受信用メモリ１７およびＣＰＵバス１８を備えている。
【００３７】
ここで、ブリッジインターフェイス回路１３は、Ｅｔｈｅｒｎｅｔインターフェイス回路１２より入力されるＥｔｈｅｒｎｅｔフレームデータ、Ｅｔｈｅｒｎｅｔインターフェイス回路１２へ出力されるＥｔｈｅｒｎｅｔフレームデータ、ＰＬＣモデム回路１５へ出力されるＥｔｈｅｒｎｅｔフレームデータ、ＰＬＣモデム回路１５から入力されるＥｔｈｅｒｎｅｔフレームデータをブリッジする回路である。
【００３８】
また、ブリッジ用メモリ１４は、ブリッジインターフェイス回路１３に入力されたＥｔｈｅｒｎｅｔフレームが、宛先ごとに振り分けられて記憶するメモリであり、ＰＬＣ送信用メモリ１６は、電灯線９（図１）を介して送出するＭＡＣフレームデータを記憶するメモリであり、ＰＬＣ受信用メモリ１７は、電灯線９を介して受信したＭＡＣフレームデータを記憶するメモリである。
【００３９】
そして、Ｅｔｈｅｒｎｅｔインターフェイス回路１２は、入力端子２０および出力端子２１を介してＥｔｈｅｒｎｅｔフレームデータを、外部からデータ送受信装置１０に入力およびデータ送受信装置１０から外部に出力する回路であり、ＰＬＣモデム回路１５は、出力端子２２を介して外部にフレームデータを送信し、また入力端子２３を介して入力されたＰＬＣフレームを受信する回路である。
【００４０】
一般に、高速ＰＬＣネットワークでは、電灯線９（図１）に接続された各端末を論理ポートという概念を用いて、ブリッジインターフェイス回路１３において、宛先（図１中の管理端末１、クライアント端末Ａ３、クライアント端末Ｂ５およびクライアント端末Ｃ７）ごとにデータを振り分けて、ブリッジ用メモリ１４内にキューイングする。
【００４１】
具体的にはＥｔｈｅｒｎｅｔインターフェイス回路１２より入力されるＥｔｈｅｒｎｅｔフレームデータを、その行き先ごとにブリッジ用メモリ１４内に振り分けて記憶する処理である。実施の形態１で説明する高速ＰＬＣを用いたネットワークシステムでは、管理端末１の内蔵されているＴＶシステムにおいて受信した映像ストリームを、クライアント端末Ｂの内蔵されているＤＶＤレコーダ５に記録しながら、ＤＶＤレコーダ５に記憶されているコンテンツを再生し、管理端末１の内蔵されている居間のＴＶシステムにて視聴するなど、各端末は複数の端末とデータの授受を実施する。従って、実施の形態１に係るデータ送受信装置１０は上記ブリッジインターフェイス回路１３を必要とする。
【００４２】
＜Ａ−３−２．ＰＬＣモデム回路の構成＞
図３は、図２に示したデータ送受信装置１０内のＰＬＣモデム回路１５の構成を示すブロック図である。
図３に示すようにＰＬＣモデム回路１５は、ブリッジインターフェイス回路１３より入力端子３０を介して入力されるＥｔｈｅｒｎｅｔデータを複数個連結してＰＬＣ用ＭＡＣフレームデータを生成するＰＬＣ送信制御回路４０と、電灯線９（図１）を介して受信したＰＬＣ用ＭＡＣフレームデータからＥｔｈｅｒｎｅｔフレームデータを分離して出力端子３１を介してブリッジインターフェイス回路１３に出力するＰＬＣ受信制御回路５０とを備えている。また、ＰＬＣ送信制御回路４０は、ＰＬＣ送信用メモリ１６との間で、送信用のＭＡＣフレームデータの授受を行い、ＰＬＣ受信制御回路５０は、受信用メモリ１７との間で、ＭＡＣフレームデータの授受を行う。
【００４３】
＜Ａ−３−３．ＰＬＣ送信制御回路の構成＞
図４は、図３に示したＰＬＣ送信制御回路４０の構成を示すブロック図である。
図４に示すようにＰＬＣ送信制御回路４０は、ＰＬＣフレームに付加するＭＡＣヘッダを生成するＰＬＣヘッダ生成回路４０１、ブリッジインターフェイス回路１３から入力端子３０を介して入力されるＥｔｈｅｒｎｅｔフレームデータを複数個集めて送信データを生成するパケットデータ生成回路４０２、パケットデータ生成回路４０２から出力されるデータに暗号化を施す暗号化回路４０３、後述するＰＬＣネットワーク制御データ生成回路４０８より出力されるＢｅａｃｏｎフレームデータやスケジュールデータと、暗号化回路４０３より出力される暗号化されたデータとの切り換えを行うセレクタ４０４、セレクタ４０４より出力されるデータの先頭にＰＬＣヘッダ生成回路４０１にて生成されたＰＬＣ用ＭＡＣヘッダを付加するヘッダ付加回路４０５、ヘッダ付加回路４０５より出力されるデータと、後述するＰＬＣ送信用メモリ制御回路４０９より出力されるデータとの切り換えを行うセレクタ４０６、データ送受信装置１０よりＰＬＣネットワークへ出力するデータの送出タイミングを生成するＰＬＣ送信タイミング生成回路４０７、ＰＬＣネットワーク制御データ生成回路４０８、ＰＬＣ送信用メモリ制御回路４０９および、出力端子２２を介して外部に送信するＰＬＣフレームにＣＲＣ符号（誤り検出符号）を付加するＣＲＣ符号付加回路４１０を備えている。
【００４４】
ここで、ＰＬＣネットワーク制御データ生成回路４０８は、送信するデータに付加するシーケンスナンバー、自端末の基準時刻情報、前回の受信タイミングで、ＢＣＨないしＦＣＨが正常受信されたか否かを示すフラグ情報、前回の受信タイミングで、受信データが正常受信されたか否かを示すＡＣＫ／ＮＡＣＫ情報、ＢＣＨ、ＦＣＨ等の制御チャンネルに付加するＢｅａｃｏｎ制御データ、１フレーム内のスケジュールデータ、および管理端末が正常に動作していないと判断された場合に、新たな管理端末を生起させる制御フレーム情報などを生成して出力する回路である。
【００４５】
また、ＰＬＣ送信用メモリ制御回路４０９は、再送制御時に使用する送信フレームを、ＰＬＣ送信用メモリ１６に記憶する際の書き込み制御信号を発生するとともに、再送時にＰＬＣ送信用メモリ１６内に記憶されているデータを読み出すための読み出し制御信号を発生する回路である。
【００４６】
＜Ａ−３−４．ＰＬＣ受信制御回路の構成＞
図５は、図３に示したＰＬＣ受信制御回路５０の構成を示すブロック図である。
図５に示すようにＰＬＣ受信制御回路５０は、受信されたＰＬＣフレームよりＭＡＣヘッダを分離しその内容を解析するＰＬＣヘッダ解析回路５０１、受信されたＰＬＣフレームに付加されたＣＲＣ情報に基づいて受信ＰＬＣフレーム内に発生した誤りを検出するＣＲＣ復号回路５０２、ヘッダ解析回路５０１より出力される暗号化の施されたデータを復号する暗号復号回路５０３、ＰＬＣフレームに付加されているスケジュール情報などの制御フレーム情報、Ｅｔｈｅｒｎｅｔフレーム情報などを分離するＰＬＣ制御フレーム分離回路５０４、ＰＬＣ制御フレーム分離回路５０４により分離されたＰＬＣ制御フレーム情報を一時的に記憶するＰＬＣ制御フレームデータ記憶回路５０５、ＰＬＣ受信用メモリ制御回路５０６、ＰＬＣ受信タイミング生成回路５０７およびＰＬＣネットワーク制御データ解析回路５０８を備えている。なお、ＰＬＣヘッダ解析回路５０１、暗号復号回路５０３およびＰＬＣ制御フレーム分離回路５０４は、ＢＣＨ、ＦＣＨ等の制御フレーム情報を検出する制御情報検出部を構成している。
【００４７】
ここで、ＰＬＣ受信用メモリ制御回路５０６は、ＰＬＣ制御フレーム分離回路５０４より出力されるＥｔｈｅｒｎｅｔフレーム情報を、一旦、ＰＬＣ受信用メモリ１７に記憶させるための制御信号を生成するとともに、ＣＲＣ復号回路５０２より出力される誤り検出結果に基づいて、ＰＬＣ受信用メモリ１７に記憶されているＥｔｈｅｒｎｅｔフレーム情報の読み出し制御を実施する回路である。
【００４８】
また、ＰＬＣネットワーク制御データ解析回路５０８は、ＰＬＣ制御フレームデータ記憶回路５０５に記憶されたＰＬＣ制御フレーム情報を、ＣＰＵ１１（制御部）を介して読み込んで解析し、その結果をＰＬＣ受信タイミング生成回路５０７に出力する回路であり、ＰＬＣ受信タイミング生成回路５０７は、ＰＬＣネットワーク制御データ解析回路５０８より出力される解析結果に基づき、ＰＬＣからのデータ受信タイミングを生成して、ヘッダ解析回路５０１、ＣＲＣ復号回路５０２、暗号復号回路５０３、ＰＬＣ制御フレーム分離回路５０４およびＰＬＣ受信用メモリ制御回路５０６に与える回路である。
【００４９】
なお、ＰＬＣネットワーク制御データ解析回路５０８では、Ｂｅａｃｏｎフレーム、およびＦＣＨにて送信されるスケジュール情報の受信に失敗した場合、受信したＰＬＣ用ＭＡＣヘッダに付加された送信端末の時刻情報に基づいて、受信端末内の時刻を補正し、それに基づいて受信端末内の時刻を調整する指示をＰＬＣ受信タイミング生成回路５０７に出力するとともに、他のクライアント端末から送信されるＢＣＨまたはＦＣＨが正常受信されたか否かを示すフラグ情報の検出、他のクライアント端末からの通知の検出、および新たな管理端末を生起させる制御フレーム情報の検出なども実施する。
【００５０】
＜Ａ−４．１フレーム内のデータの送信タイミング＞
管理端末１では、ＰＬＣネットワーク全体の時刻同期を管理するため、従来の技術としても説明したように、周期的にＢＣＨによりＢｅａｃｏｎ信号を、またＦＣＨによりスケジュール情報を出力する。
【００５１】
図６には、１フレーム内の各種データの送信タイミングを示す。
図６に示すように、１フレームにおいては、ＢＣＨ、ＦＣＨおよびＡＣＨの順にネットワーク管理情報を送信した後、データ送受信期間にｎ個の通信スロットＬ１〜Ｌｎを送信し、最後にＲＣＨを送信することとなる。
【００５２】
実施の形態１では、ＢＣＨなどのＰＬＣネットワーク管理情報は２０ｍｓ周期で出力されるものとする。よって、管理端末１内のＰＬＣ送信制御回路４０ではＢｅａｃｏｎフレーム、およびスケジュール情報を２０ｍｓに一度の間隔で生成することになる。
【００５３】
また、実施の形態１では、Ｂｅａｃｏｎフレーム情報としては、Ｂｅａｃｏｎフレームを送出する際の管理端末１の時刻情報をペイロード情報として送出するものとする。
【００５４】
具体的には、Ｂｅａｃｏｎフレーム送出時のＰＬＣネットワーク制御データ生成回路４０８（図４）内の基準時刻情報を、ペイロード情報としてセレクタ４０４に出力する。一方、受信側となるクライアント端末では、Ｂｅａｃｏｎフレーム情報を受信すると、内部の受信基準時刻をＢｅａｃｏｎフレームに付加された送信側基準時刻に同期させる。管理端末１はＢＣＨの送信に引き続きＦＣＨ（スケジュール情報）の送信を実施する。
【００５５】
図６に示すように、ＦＣＨ内には受信時に受信データの先頭位置、およびクロック位相を検出するためのプリアンブル情報と、プリアンブル情報に続いて送信されるスケジュール情報とが含まれている。そして、スケジュール情報には、データ送受信期間に設けられた通信スロットＬ１〜Ｌｎにそれぞれ対応させて、送信開始時間、送信時間、どの端末（送信端末）からどの端末（受信端末）へのデータ送信かを示す端末情報、およびデータを送受信する際の送受信関連情報が含まれている。
【００５６】
実施の形態１では、送信端末情報および受信端末情報については、各端末の持つＭＡＣアドレス（Media Access Control Address）情報を用いるものとする。なお、ＭＡＣアドレス情報以外に、例えばそのＰＬＣネットワーク内の論理ポート番号、あるいはネットワーク内でプライベートに定められた識別情報であっても良い。
【００５７】
このように、ＦＣＨ内のスケジュール情報には通信スロットごとに対応した上記情報が付加されて伝送される。なお、通信スロットについては、映像ストリームの送信を開始するクライアント端末が、管理端末１に対してＲＣＨのタイムスロットを利用し、帯域割当要求を伝送することにより、管理端末１は映像ストリームの送信要求のあった端末に対して通信帯域を割り当てる。その際、管理端末１は、映像ストリームのようにリアルタイム性の要求されるデータに関しては、固定的に帯域を割り当てるようにスケジューリングを実施する。なお、固定的に割り当てられた帯域を、固定帯域、あるいは固定帯域割当と称する。
【００５８】
＜Ａ−５．スケジュール情報の生成方法＞
次に、図７に示すフローチャートを用いてスケジュール情報の生成方法について説明する。
【００５９】
データの送受信を開始すると、ＣＰＵ１１（図２）がスケジュール情報の生成開始タイミングであるか否かを確認し（ステップＳ１１）、生成開始タイミングである場合にはステップＳ１２に進み、管理端末は固定帯域割当が実施されているクライアント端末の有無を確認する。
【００６０】
そして、固定帯域割当が実施されているクライアント端末が存在しない場合はステップＳ１４に進み、固定帯域割当が実施されているクライアント端末が存在する場合は、ＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８（図４）を制御して固定帯域用のタイムスロットを割り当てる（ステップＳ１３）。ただし、当該クライアント端末から前フレームにおいて、固定帯域割り当て用のタイムスロットの解放要求の通知あった場合は、固定帯域割当を実施しない。
【００６１】
固定帯域用のタイムスロットの割り当てが終了すると、管理端末のＣＰＵ１１は前フレームにおいて、クライアント端末から新規通信用の固定帯域割当要求があったか否かを確認する（ステップＳ１４）。
【００６２】
そして、前フレームにおいて新規固定帯域割当要求がなかった場合はステップＳ１８に進み、新規固定帯域割当要求があった場合は、ステップＳ１５において、現在割り当てている固定帯域用のタイムスロットを確認し、新規要求のあった固定帯域を割り当てることができるか否かを確認する。
【００６３】
新規に固定帯域割当が可能な場合は、ＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８を制御して新規帯域要求端末に対して固定帯域を割り当て（ステップＳ１６）、固定帯域割当が不可能な場合は、ステップＳ１７において固定帯域割当不可通知をＡＣＨデータとして要求のあったクライアント端末に対して出力してステップＳ１８に進む。
【００６４】
次に、ステップＳ１８では、管理端末のＣＰＵ１１は、前フレームにおいて、クライアント端末から制御コマンド用の帯域割当要求があったか否かを確認する。
【００６５】
そして、前フレームにおいて制御コマンド用の帯域割当要求がなかった場合はステップＳ２０に進み、制御コマンド用の帯域割当要求があった場合は、ＰＬＣネットワーク制御データ生成回路４０８を制御して制御コマンド用のタイムスロットを割り当てる（ステップＳ１９）。
【００６６】
なお、実施の形態１では映像ストリームなどを伝送する場合、ユーザがリモコンで機器制御を実施する、あるいは著作権管理のために、鍵情報などを交換するなど様々なケースで映像ストリーム以外の制御コマンドがやり取りされる。従って、ステップＳ１３において新規端末に対して固定帯域を割り当てる場合は、少なくとも１フレーム内に１タイムスロット以上の制御コマンド用の帯域を割り当てられるように帯域を確保した後、新規端末へのタイムスロットを割り当てるものとする。
【００６７】
制御コマンド用のタイムスロットの割り当てが完了すると、管理端末のＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８を制御して、管理端末の送信用のタイムスロットを割り当てる（ステップＳ２０）。
【００６８】
送信用タイムスロットの割り当てが終了すると、管理端末のＣＰＵ１１は、前フレームにおいて、クライアント端末から固定帯域割当通信以外の新規の帯域割当要求（以下、通常帯域割当と表記）があったか否かを確認する（ステップＳ２１）。
【００６９】
そして、前フレームにおいて新規の通常帯域割当要求がなかった場合はステップＳ２１に進み、新規の通常帯域割当要求があった場合は、帯域を割り当てることができるか否かを確認する（ステップＳ２２）。
【００７０】
新規に通常帯域割当が可能である場合は、当該割り当てを要求するクライアント端末に対して、管理端末のＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８を制御して、新規に通常帯域用のタイムスロットを割り当てる（ステップＳ２３）。一方、新規に通常帯域割当が不可能である場合は、ステップＳ２４において通常帯域割当不可通知をＡＣＨデータとして要求のあったクライアント端末に対して出力する。
【００７１】
以上説明した各タイムスロットの割り当てが完了すると、管理端末のＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８を制御して、管理端末を含む各クライアント端末の各タイムスロット情報に基づいてＦＣＨフレームを生成する（ステップＳ２５）。
【００７２】
なお、ステップＳ２５においてＦＣＨフレームを生成する際、実施の形態１では各クライアント端末に割り当てる固定帯域割当は、フレーム内では基本的に同一のタイムスロットに割り当てられるものとする。これは、以下の理由に基づく。
【００７３】
すなわち、固定帯域割当により伝送する映像ストリームのようなデータ（ＶｏＩＰ：Voice over Internet Protocolのような音声データも同様）は、伝送する平均データ伝送レートはほぼ一定である。従って、管理端末より送信されたＦＣＨフレームを周辺機器ノイズの影響で受信できなかった場合でも、各クライアント端末間の同期が確保されていれば、前回受信したスケジュール情報に基づいて伝送すればデータの送受信を実施することができるからである。また、詳細は後述するが、クライアント端末間で映像ストリームを再生中に管理端末がＰＬＣネットワークより離脱した場合についても、各クライアント端末間のクロック同期が確立していれば、前回のフレーム送信で受信したスケジュール情報に基づいて映像ストリームを送信することで、新たな管理端末が生起するまでの間、再生画像を乱すことなく伝送することができるからである。
【００７４】
図７の説明に戻り、ステップＳ２５にてＦＣＨフレームの生成が終了すると、管理端末のＣＰＵ１１は、ステップＳ２６において次の管理端末候補の優先順位情報を生成する（詳細は後述）。
【００７５】
優先順位情報の生成の後、管理端末のＣＰＵ１１は、各クライアント端末に向けて、ＦＣＨフレームを送信し（ステップＳ２７）、続いて次の管理端末候補の優先順位情報を送信（ステップＳ２８）した後、ステップＳ１１に戻り、次のスケジュール生成開始タイミングになるまで待機する。
【００７６】
実施の形態１では、現在の管理端末が何らかの事情でネットワークを離脱しても、ステップ２６において設定した次の管理端末候補の優先順位情報に基づいて新たな管理端末の生起を実施する。上記優先順位情報は、受信データ用に固定帯域を割り当てられているクライアント端末の順位が上位になるよう設定する。これは以下の理由による。
【００７７】
すなわち、ＢＣＨおよびＦＣＨの受信状況のみで管理端末のネットワーク離脱を判断するよう構成した場合、特に住宅内ネットワークにおいては、冷蔵庫などのインバータ機器が動作を始めた際に一時的にデータの受信状態が悪くなり、その影響を受けやすい機器のみがＢＣＨおよびＦＣＨを受信できなくなる場合が想定される。従って、実施の形態１では、固定帯域割当用のタイムスロットを使用してデータを受信するクライアント端末において、管理端末のネットワークからの離脱を判断する。
【００７８】
この場合、ＢＣＨおよびＦＣＨの受信に失敗したとしても、上述したように固定帯域として割り当てたタイムスロットに関しては、前回受信したスケジュール情報に基づいてデータの送受信を実施すれば、新たな管理端末が生起するまでの間、再生画像を乱すことなく伝送することができる。
【００７９】
従って、受信端末側では、送信端末側でのＢＣＨおよびＦＣＨの受信情報がＭＡＣヘッダに付加されて伝送されてくるため、自クライアント端末以外の情報を用いて管理端末のＰＬＣネットワークからの離脱が判断できるので、管理端末がＰＬＣネットワークから離脱していないにも関わらず、自クライアント端末が新たな管理端末として生起する動作が開始されることを回避する効果がある。
【００８０】
＜Ａ−６．優先順位情報の生成方法＞
次に、図８に示すフローチャートを用いてステップＳ２６（図７）における優先順位情報の生成方法について説明する。
【００８１】
優先順位情報の生成を開始すると、管理端末のＣＰＵ１１（図２）は、現在データを受信中のクライアント端末において、受信データ用に固定帯域を割り当てられたクライアント端末があるか否かを確認し（ステップＳ５１）、該当するクライアント端末が存在しない場合はステップＳ５４に進み、該当するクライアント端末が存在する場合には、そのクライアント端末に優先順位の設定がされているか否かを確認する（ステップＳ５２）。
【００８２】
上記該当するクライアント端末に優先順位の設定がなされている場合はステップＳ５４に進み、優先順位の設定がなされていない場合は、ステップＳ５３において、優先順位を設定する（Ｓ５３）。この場合、固定帯域が割り当てられているデータ受信中のクライアント端末が１つしかない場合は、当該クライアント端末の優先順位を１に設定し、固定帯域が割り当てられているデータ受信中のクライアント端末が複数ある場合は、優先順位が重複しないようランダムにクライアント端末を選択し、順位を設定する。なお、クライアント端末の選択については、ランダム選択の他に、使用帯域割合が多い順に優先順位を設定するなどしても良い。
【００８３】
次の管理端末候補の優先順位の設定が終了すると、ステップＳ５１の処理に戻って、他に受信データ用に固定帯域を割り当てられてデータを受信中のクライアント端末が存在するか否かの確認を行う。
【００８４】
受信データ用に固定帯域が割り当てられていないクライアント端末、すなわち現在データを受信中の通常帯域割当のクライアント端末については、ステップＳ５４において優先順位の設定がされているか否かを確認する（ステップＳ５４）。
【００８５】
上記該当するクライアント端末に優先順位の設定がなされている場合は優先順位情報の生成を終了し、優先順位の設定がなされていない場合は、ステップＳ５５において、該当するクライアント端末に対して優先順位の設定が終了しているか否かを確認する。
【００８６】
そして、該当するクライアント端末に対する優先順位の設定が終了している場合はステップＳ５７に進み、優先順位の設定が終了していない場合は、ステップＳ５６において、現在データ受信中のクライアント端末の優先順位を、ステップＳ５３で設定した順位に続く順位に設定する。なお、ステップＳ５５およびＳ５６の処理は、通常帯域が割り当てられているデータ受信中のクライアント端末が複数ある場合は、その全てについて実行される。この場合、固定帯域が割り当てられている場合と同様に優先順位が重複しないようクライアント端末を選択し、順位を設定する。上記ステップが終了すると、ネットワーク内でデータ受信中の全てのクライアント端末についての優先順位の設定が終了する。
【００８７】
データ受信中のクライアント端末についての優先順位の設定が終了すると、ステップＳ５７において、現在、データ送信中のクライアント端末に対して優先順位の設定が終了しているか否かを確認する。
【００８８】
そして、該当するクライアント端末に対する優先順位の設定が終了している場合はステップＳ５９に進み、優先順位の設定が終了していない場合は、ステップＳ５８において、現在データ送信中のクライアント端末の優先順位を、ステップＳ５６で設定した順位に続く順位に設定する。なお、ステップＳ５７およびＳ５８の処理は、データ送信中のクライアント端末が複数ある場合は、その全てについて実行される。この場合、データ受信中のクライアント端末に優先順位を割り当てる場合と同様に順位が重複しないよう送信端末を選択し、順位を設定する。上記ステップが終了すると、ネットワーク内でデータの受信および送信中の全てのクライアント端末の優先順位の設定が終了する。
【００８９】
ネットワーク内でデータの送信および受信中の全てのクライアント端末についての優先順位の設定が終了した後は、ステップＳ５９において、他のクライアント端末、すなわち現在、データの送受信を行っていないアイドル状態のクライアント端末に対して優先順位の設定が終了しているか否かを確認する。
【００９０】
そして、該当する全てのクライアント端末に対する優先順位の設定が終了している場合は優先順位情報の生成を終了し、優先順位の設定がなされていないアイドル状態のクライアント端末が存在する場合は、ステップＳ６０において、アイドル状態のクライアント端末の優先順位を、ステップＳ５８で設定した順位に続く順位に設定する。なお、ステップＳ５９およびＳ６０の処理は、アイドル状態のクライアント端末が複数ある場合は、その全てについて実行される。この場合、データ送受信中のクライアント端末に優先順位を割り当てる場合と同様に順位が重複しないようアイドル状態のクライアント端末を選択し、順位を設定する。上記ステップが終了すると、ネットワーク内にあるクライアント端末全ての優先順位の設定が終了し、優先順位情報の生成を終了する。
【００９１】
＜Ａ−７．クライアント端末の送受信動作＞
発明が解決しようとする課題としても説明したが、ＡＶ系のネットワークをＰＬＣ等を用いて構成した場合、映像ストリームを再生中に、ユーザがＰＬＣネットワークを管理している管理端末の電源をオフする場合がある。本発明においては、このような場合でも、現在再生中の映像ストリームを途切れないように継続するとともに、管理端末を新たに生起させて継承させることを特徴としている。
【００９２】
これを実現するために、映像ストリームを送信するクライアント端末は、管理端末より送信されるＢＣＨおよびＦＣＨが検出できなかった場合でも、前回受信したスケジュール情報に基づいて映像ストリームを送信、あるいは受信用のスロット（固定帯域が割り当てられたタイムスロット）を用いてデータの送受信を実施するように構成されている。
【００９３】
また、クライアント端末内の基準時刻に関しては、前回受信したＢＣＨに基づいて生成したクロック情報で自端末の時刻情報を補正するように構成されている。この構成は、図７を用いて、ステップＳ２５の動作において説明したように、映像ストリームに割り当てられた固定帯域は、フレーム内で同一のタイムスロットに割り当てられるように設定することで実現される。
【００９４】
一方、映像ストリームを受信するクライアント端末では、自端末でのＢＣＨおよびＦＣＨの受信状態に基づいて、受信時のデータ送受信制御を実施する。具体的には、受信側のクライアント端末でも、ＢＣＨおよびＦＣＨが正常に受信できなかった場合は、前回受信したＦＣＨに基づいて内部で生成した時刻情報により、受信タイムスロットの位置を推定してデータ受信を実施する。
【００９５】
なお、ＦＣＨが受信できなかった場合は、映像ストリームを送信する固定帯域割当に相当するタイムスロットのみデータ受信を実施する。その際、受信側のクライアント端末が、ＢＣＨおよびＦＣＨの受信ができず、また、送信側のクライアント端末でもＢＣＨおよびＦＣＨの受信ができていなかった場合は、管理端末がネットワークより離脱した可能性があると判断し、内部の基準時刻を送信側のクライアント端末の時刻情報にあわせるよう制御するとともに、新たな管理端末の生起動作を開始する（詳細は後述）。
【００９６】
また、送信クライアント端末がＢＣＨを受信できなかった場合は、ＢＣＨを用いた管理端末との基準クロックの同期制御を、前回までに検出したＢＣＨに基づいて検出した誤差情報を用いて自端末の基準時刻情報を生成する。これは前回までに検出したＢＣＨで、管理端末とクライアント端末間はクロック同期がほぼ確立（実際には数ｐｐｍ以下のクロック周波数誤差を有する）しているため、誤差情報を用いてもＢＣＨが復帰するまでの期間があまり長くなければＰＬＣネットワークのクロック同期を確立することができるためである。一方、ＢＣＨが受信できている場合は、受信したＢＣＨに基づいてクロック周波数の誤差を検出してクロック同期を取り、同期の取れたクロックを使用して内部基準時刻を生成する。
【００９７】
以上概略的に説明したクライアント端末の送受信動作について、以下、図９〜図１２に示すフローチャートを用いて、さらに説明する。
【００９８】
なお、実施の形態１においては、送信クライアント端末の送信時刻情報およびＦＣＨを管理端末より正常に受信できたか否かを示すフラグ情報をＭＡＣフレームに付加して送信することを特徴とする。
【００９９】
ＴＤＭＡをベースとするＭＡＣ方式では、ＢＣＨにより管理端末と各クライアント端末間の時刻同期を確立する。ＢＣＨにより時刻同期が確立すると、その基準時刻に基づいて管理端末と各クライアント端末間のＭＡＣフレームデータの送受信を実施する。
【０１００】
まず、図９に示すように、クライアント端末での送受信動作を開始すると、クライアント端末のＣＰＵ１１（図２）は、現在がＢＣＨの受信時刻であるか否かを確認する（ステップＳ１０１）。
【０１０１】
そして、ＢＣＨの受信時刻に達していない場合は、ステップＳ１０１の確認処理を繰り返し、ＢＣＨの受信時刻に達している場合は、ステップＳ１０２において、ＢＣＨが受信できたか否かを確認する。
【０１０２】
ＢＣＨが正常に受信できれば、自クライアント端末内の時刻をＢＣＨに合わせて同期させ（Ｓ１０３）、また、ＢＣＨが正常に受信できた旨のＯＫフラグをセットする（ステップＳ１０４）。
【０１０３】
一方、ＢＣＨが正常に受信できなかった場合は、ステップＳ１０５において、前回受信したＢＣＨに基づいて生成したクロック情報で自端末の時刻情報を補正し、ＢＣＨが正常に受信できなかった旨のＮＧフラグをセットする（ステップＳ１０６）。なお、ＯＫフラグおよびＮＧフラグについてはＣＰＵ１１内において管理される。
【０１０４】
次に、ＣＰＵ１１は、現在がＦＣＨの受信時刻であるか否かを確認する（ステップＳ１０７）。
【０１０５】
そして、ＦＣＨの受信時刻に達していない場合は、ステップＳ１０７の確認処理を繰り返し、ＦＣＨの受信時刻に達している場合は、ステップＳ１０８において、ＦＣＨが受信できたか否かを確認する。
【０１０６】
ＦＣＨが正常に受信できれば、その検出結果に基づいてに自クライアント端末のスケジュール情報を確認し（ステップＳ１０９）、また、ＦＣＨが正常に受信できた旨のＯＫフラグをセットする（ステップＳ１１０）。
【０１０７】
一方、ＦＣＨが受信できなかった場合は、ステップＳ１１１において、前回受信したスケジュール情報に基づいて、固定帯域が割り当てられたタイムスロットのみ、データの送受信を実施するよう自クライアント端末内のスケジュール設定を行い、ＦＣＨが正常に受信できなかった旨のＮＧフラグをセットする（ステップＳ１１２）。
【０１０８】
また、ＢＣＨのＮＧフラグのセット状況を確認し（ステップＳ１１３）、ＢＣＨのＮＧフラグはセットされていない場合は、図１０におけるステップＳ１１５に進み、ＢＣＨのＮＧフラグもセットされていた場合、すなわちＢＣＨおよびＦＣＨの両方のＮＧフラグがセットされていた場合、ＣＰＵ１１内に設けられた管理端末のネットワーク離脱回数計測カウンタ（以下、ＬＥＡＶＥ  ＮＵＭと表記）を１カウント分インクリメントする（ステップＳ１１４）。ＬＥＡＶＥ  ＮＵＭは、管理端末がネットワークから離脱したかどうかをクライアント端末が認識するための指標とする（詳細は後述）。なお、ＬＥＡＶＥ  ＮＵＭは、ＣＰＵ１１内で管理される。
【０１０９】
ＦＣＨの受信確認が終了した後の動作については、図１０に示すフローチャートを用いて説明する。なお、図９における記号（Ａ）と図１０における記号（Ａ）とで、図９と図１０とが互いに接続されている。また、図１０における記号（Ｂ）と図１１における記号（Ｂ）とで、図１０と図１１とが互いに接続されている。さらに、図９における記号（Ｃ）と図１１における記号（Ｃ）とで、図９と図１１とが互いに接続されている。
【０１１０】
ＣＰＵ１１は、図１０に示すステップＳ１１５において、ＦＣＨが正常に受信できた場合は、ＦＣＨのスケジュール情報に受信スロットがあるか否か、ＦＣＨが正常に受信できなかった場合は前回受信したスケジュール情報で固定帯域が割り当てられた受信スロットがあるか否かの確認を行う（ステップＳ１１５）。
【０１１１】
そして、何れの受信スロットもない場合は、図１１に示す送信スロットの確認処理に進み、何れかの受信スロットがある場合は、現在がＭＡＣフレームの受信時刻であるか否かを確認する（ステップＳ１１６）。
【０１１２】
ＭＡＣフレームの受信時刻に達していない場合は、ステップＳ１１６の確認処理を繰り返し、ＭＡＣフレームの受信時刻に達している場合は、ＭＡＣフレームの受信を開始して（ステップＳ１１７）、データの受信処理を行う。
【０１１３】
続いて、ＣＰＵ１１は、ステップＳ１１８において、自クライアント端末でＢＣＨのＯＫフラグまたはＦＣＨのＯＫフラグがセットされているか否かを確認し、どちらかがセットされている場合は、管理端末は正常に動作しているものと判断し、ＬＥＡＶＥ  ＮＵＭの値を０にリセットする（ステップＳ１２１）。
【０１１４】
一方、自クライアント端末でＢＣＨのＯＫフラグ、ＦＣＨのＯＫフラグの何れもセットされていない場合（すなわち、自クライアント端末でＢＣＨのＮＧフラグおよびＦＣＨのＮＧフラグをセットした場合）は、ステップＳ１１９において、送信側のクライアント端末から、ＢＣＨのＯＫフラグを受信したか否かを確認する（ステップＳ１１９）。
【０１１５】
そして、送信側のクライアント端末からのＢＣＨのＯＫフラグの受信を確認した場合、すなわち、送信側のクライアント端末ではＢＣＨのＯＫフラグがセットされている場合は、自クライアント端末は伝送路のノイズ状況などの一時的な要因により管理端末からＢＣＨまたはＦＣＨが受信できなかったものの、管理端末は正常に動作しているものと判断して、ＬＥＡＶＥ  ＮＵＭの値を０にリセットする（ステップＳ１２１）。
【０１１６】
一方、送信側のクライアント端末からのＢＣＨのＯＫフラグの受信を確認できない場合は、ステップＳ１２０において、送信側のクライアント端末から、ＦＣＨのＯＫフラグを受信したか否かを確認する。
【０１１７】
そして、送信側のクライアント端末からのＦＣＨのＯＫフラグの受信を確認した場合、すなわち、送信側のクライアント端末ではＦＣＨのＯＫフラグがセットされている場合は、ＢＣＨのＯＫフラグを確認した場合と同様の論理により、管理端末は正常に動作しているものと判断し、ＬＥＡＶＥ  ＮＵＭの値を０にリセットする（Ｓ１２１）。
【０１１８】
一方、送信側のクライアント端末からのＦＣＨのＯＫフラグの受信を確認できない場合は、ステップＳ１２２において、送信側のクライアント端末から、ＢＣＨおよびＦＣＨのＮＧフラグを受信を確認したか否かを確認する。
【０１１９】
そして、送信側のクライアント端末からのＢＣＨおよびＦＣＨのＮＧフラグの受信を確認した場合、すなわち、送信側のクライアント端末でもＢＣＨおよびＦＣＨのＮＧフラグがセットされている場合は、ステップＳ１２３において、ＬＥＡＶＥ  ＮＵＭを１カウント分インクリメントする。
【０１２０】
一方、送信側のクライアント端末からのＢＣＨおよびＦＣＨのＮＧフラグの受信を確認できない場合は、送信側のクライアント端末からのＢＣＨのＯＫフラグおよびＮＧフラグ、ＦＣＨのＯＫフラグおよびＮＧフラグの何れも正常に受信できなかったものと判断し、自クライアント端末と送信側のクライアント端末との通信に支障が発生しているものとして、自クライアント端末でのＬＥＡＶＥ  ＮＵＭのリセット動作を行わず、ステップＳ１２６に進む。
【０１２１】
なお、ステップＳ１２３でＬＥＡＶＥ  ＮＵＭをインクリメントした後、ステップＳ１２４において、ＬＥＡＶＥ  ＮＵＭの値が、予め定めた所定の値より大きくなったか否か、すなわちカウント回数が所定回数より大きくなったか否かを確認する。
【０１２２】
そして、ＬＥＡＶＥ  ＮＵＭのカウント回数が所定回数より大きくなったことを確認した場合には、自クライアント端末においても、また他の送信クライアント端末においても管理端末からのＢＣＨおよびＦＣＨが受信できなくなっているものと判断し、管理端末がネットワークより離脱したものと判断して、次の管理端末を生起するフラグ（以下、ＮＥＷ  ＦＬＡＧと表記）を１にセット（ステップＳ１２５）する。
【０１２３】
なお、ＬＥＡＶＥ  ＮＵＭのカウント回数が所定回数より大きくなっていない場合、およびＮＥＷ  ＦＬＡＧを１にセットした後はステップＳ１２６に進む。
【０１２４】
ＣＰＵ１１は、ステップＳ１２６において、全ての受信スロットについて、ステップＳ１１６〜Ｓ１２５の処理を施したか否かを確認し、全ての受信スロットについての処理が完了している場合は図１１に示す送信スロットの確認処理に進み、処理が完了していないスロットがある場合は、ステップＳ１１６以下の処理を繰り返す。
【０１２５】
全ての受信スロットについての処理が完了した場合、あるいは受信スロットが存在しない場合は、ＣＰＵ１１は、図１１に示すステップＳ１２７において送信スロットがあるか否かの確認を行う。すなわち、ＦＣＨが正常に受信できた場合はそのＦＣＨ中のスケジュール情報に送信スロットがあるか否か、ＦＣＨが正常に受信できなかった場合は前回受信したＦＣＨ中のスケジュール情報で固定帯域が割り当てられた送信スロットがあるかの否かの確認を実施する。
【０１２６】
そして、何れの送信スロットもない場合はステップＳ１３３に進み、何れかの送信スロットがある場合は、ＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８を制御して、送信するＭＡＣフレームデータを生成し、受信側のクライアント端末が管理端末からのＢＣＨ、ＦＣＨを正常に受信できていない場合に基準時刻の補正に用いる送信時刻情報を生成する（ステップＳ１２８）。また、自クライアント端末でのＢＣＨのＯＫフラグまたはＮＧフラグのセット状況、およびＦＣＨのＯＫフラグまたはＮＧフラグのセット状況を、送信するＭＡＣフレームデータに付加する（ステップＳ１２９）。
【０１２７】
その後、現在がＭＡＣフレームの送信時刻であるか否かを確認し（ステップ１３０）、送信時刻に達していれば、ＭＡＣフレームの送信を開始し（ステップＳ１３１）、ＭＡＣフレームの送信時刻に達していない場合は、ステップＳ１３０の確認処理を繰り返す。
【０１２８】
次に、ＣＰＵ１１は、全ての送信スロットについてステップＳ１２８〜Ｓ１３１の処理を施したか否かを確認し（ステップＳ１３２）、処理が完了していないスロットがある場合は、ステップＳ１２８以下の処理を繰り返し、全ての送信スロットについての処理が完了している場合は、管理端末に対して帯域割当の要求を行うかどうかの判断を実施する（ステップＳ１３３）。
【０１２９】
そして、帯域割当要求を行わない場合はステップＳ１３８に進み、帯域割当要求を行う場合は、ステップＳ１３４において、管理端末の動作が正常であるかどうかの確認を実施する。この判断は、自クライアント端末でＢＣＨおよびＦＣＨのＮＧフラグをセットしたか否かによって行う。具体的には、ＢＣＨおよびＦＣＨのＮＧフラグをセットしていない場合、すなわち、図９に示したステップＳ１０２またはＳ１０８において、ＢＣＨまたはＦＣＨを正常に受信できたと判断し、ステップＳ１０４またはＳ１１０で、ＢＣＨのＯＫフラグまたはＦＣＨのＯＫフラグをセットした場合は、管理端末は正常に動作していると判断する。その場合は、ＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８を制御して帯域割当要求のＲＣＨを送信する（ステップＳ１３５）。
【０１３０】
一方、自クライアント端末でＢＣＨおよびＦＣＨのＮＧフラグをセットした場合は、送信側のクライアント端末からの受信スロットがあるか否かの確認を行う（ステップＳ１３６）。
【０１３１】
そして、受信スロットが存在しない場合は、自クライアント端末のみでしか管理端末の動作状況を確認できないのでＲＣＨの送信を行わないものとし、ステップＳ１３８に進む。一方、受信スロットが存在する場合は、送信側のクライアント端末からＢＣＨまたはＦＣＨのＯＫフラグを受信したかどうかの確認を行う（ステップＳ１３７）。
【０１３２】
そして、送信側のクライアント端末からＢＣＨまたはＦＣＨのＯＫフラグを受信できていればＲＣＨを送信し（ステップＳ１３５）、何れも受信できなかった場合は管理端末が正常に動作していない可能性が高いと判断し、ＲＣＨの送信を行わないものとし、ステップＳ１３８に進む。
【０１３３】
管理端末に対して帯域割当の要求を行わない場合、ステップＳ１３８においてＬＥＡＶＥ  ＮＵＭの値が０を越えるか否か、すなわち１以上であるか否かの確認を行う。ＬＥＡＶＥ  ＮＵＭの値が１以上の場合、管理端末が正常に動作していない可能性があるため、ステップＳ１３９において、新たな管理端末の生起の確認を実施する（詳細は後述）。新たな管理端末の生起の確認を実施後、またはＬＥＡＶＥ  ＮＵＭの値が０である場合は、１つのＭＡＣフレームについてのデータ送受信は完了し、新たなＭＡＣフレームのデータ送受信のために図９に示すステップＳ１０１に戻る。
【０１３４】
＜Ａ−８．新たな管理端末の生起の確認処理＞
実施の形態１では、管理端末がネットワークから離脱した場合、新たな管理端末を生起させて継承させることを特徴の１つとしている。また、新たな管理端末は、固定帯域割当によってデータを受信中のクライアント端末が優先して生起されるように設定されている。
【０１３５】
以下、図１２に示すフローチャートを用いて、ステップＳ１３９（図１１）における新たな管理端末の生起の確認処理について説明する。
新たな管理端末の生起の確認処理を開始すると、クライアント端末のＣＰＵ１１（図２）は、自クライアント端末が新たな管理端末候補としての順位が１位に設定されているか否かを確認する（ステップＳ１５１）。
【０１３６】
そして、新たな管理端末候補としての順位が１位ではない場合はステップＳ１５８に進み、順位が１位であった場合は、ＮＥＷ  ＦＬＡＧが１にセットされているか否かを確認し（ステップＳ１５２）、ＮＥＷ  ＦＬＡＧが１にセットされていない場合は、次の新たな管理端末の生起確認開始タイミングまで待機する（ステップＳ１６６）。
【０１３７】
一方、ＮＥＷ  ＦＬＡＧが１にセットされている場合は、ＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８を制御して、自クライアント端末が新たな管理端末候補となったことを他のクライアント端末に通知する（ステップＳ１５３）。なお、当該通知は自クライアント端末内での基準時刻情報に基づいて、前の管理端末が正常に動作していたときにスケジュールされていた、例えばＡＣＨのタイミングなどで同報通信を実施すれば良い。
【０１３８】
他のクライアント端末への通知が完了すると、ステップＳ１５４において、ＰＬＣネットワーク制御データ解析回路５０８において、他のクライアント端末から送信される新たな管理端末を承認するか否かの通知を検出し、新たな管理端末を承認する旨の通知を受信したか否かを確認し（ステップＳ１５４）、通知を確認できない場合は確認できるまで待機する。
【０１３９】
なお、他のクライアント端末から新たな管理端末候補に対する承認通知は、前の管理端末が正常に動作していたときにスケジュールされていた、例えばＲＣＨのタイミングなどで実施すれば良い。また、他の全クライアント端末からの承認が必要か、または一部のクライアント端末からの承認だけで良いかなどは適宜設定すれば良い。
【０１４０】
他のクライアント端末からの承認の通知を受信すると、ＮＥＷ  ＦＬＡＧを０にリセットし（ステップＳ１５５）、また、ＬＥＡＶＥ  ＮＵＭを０にリセットして（ステップＳ１５６）、新たな管理端末としてＢＣＨおよびＦＣＨの送信等の動作を開始する（ステップＳ１５７）。
【０１４１】
一方、ステップＳ１５１において、自クライアント端末の新たな管理端末候補としての順位が１位ではないと確認された場合は、ステップＳ１５８において、他のクライアント端末から新たな管理端末候補となったことの通知を受信したか否かを確認し、受信を確認できない場合はステップＳ１６３に進み、通知を受信した場合は、上記新たな管理端末候補に新たな管理端末を承認する旨の通知を送信する（ステップＳ１５９）。
【０１４２】
その後、ＮＥＷ  ＦＬＡＧを０にリセットし（ステップＳ１６０）、また、ＬＥＡＶＥ  ＮＵＭを０にリセットして（ステップＳ１６１）、新たな管理端末のもとで動作を開始する（ステップＳ１６）。
【０１４３】
一方、ステップＳ１５８において通知を確認できなかった場合は、ステップＳ１６３においてＮＥＷ  ＦＬＡＧのセット状況を確認する。
【０１４４】
そして、ＮＥＷ  ＦＬＡＧが１にセットされていない場合は、次の新たな管理端末の生起確認開始タイミングまで待機し（ステップＳ１６６）、ＮＥＷ  ＦＬＡＧが１にセットされている場合は、ステップＳ１６４において、他のクライアント端末から新たな管理端末候補となったことの通知がなかったか否かの確認を所定の期間続ける。
【０１４５】
このステップＳ１６４の処理において所定の期間待機することで、他のクライアント端末での新たな管理端末生起の動向をうかがい、新たな管理端末候補の優先順位が高いクライアント端末が、例えば電源をオフされたなどの理由により新たな管理端末として生起できない場合は、自クライアント端末の新たな管理端末候補の優先順位を１ランク繰り上げるものとする（ステップＳ１６５）。その後、次の新たな管理端末の生起確認開始タイミングまで待機する（ステップＳ１６６）。
【０１４６】
＜Ａ−９．効果＞
以上説明した実施の形態１のデータ送受信装置１０を用いることで、クライアント端末間で映像ストリームの送受信中に管理端末がＰＬＣネットワークから離脱した場合でも、データ受信中のクライアント端末が同期を継承し、新たな管理端末として生起して、ネットワークトポロジを回復させることができる。
【０１４７】
また、ＢＣＨおよびＦＣＨともに受信できなかった場合に管理端末がＰＬＣネットワークから離脱したものと判断するので、管理端末の離脱を正確に判断することができる。
【０１４８】
また、映像ストリームを送信する際、固定帯域を割り当てるとともに、１フレーム内での固定帯域割当を同じ位置になるようにスケジューリングするので、前回受信したスケジュール情報、および基準時刻情報に基づいて映像ストリームの送受信をすれば、新たな管理端末が生起するまでの管理端末が不在の期間においても、映像ストリームを中断することなく伝送できる効果がある。
【０１４９】
＜Ｂ．実施の形態２＞
＜Ｂ−１．動作＞
以下、本発明に係る実施の形態２のデータ送受信装置の動作について説明する。なお、データ送受信装置の構成は図２に示したデータ送受信装置１０を前提とする。
【０１５０】
実施の形態２のデータ送受信装置においては、実施の形態１と比べて、管理端末がＰＬＣネットワークから離脱したか否かを検出する検出方法のみが異なり、管理端末がＰＬＣネットワークから離脱したことをより迅速に判断できるため、各クライアント端末の管理端末からのＢＣＨおよびＦＣＨの受信状況情報を各クライアント端末より同報通信するように構成している。
【０１５１】
この構成により、一時的に伝送路の通信状態が悪くなり、その影響を受けたクライアント端末が、管理端末からのＢＣＨおよびＦＣＨを正常に受信できなかった場合でも、ＰＬＣネットワークを構成している全てのクライアント端末の管理端末からのＢＣＨ、ＦＣＨの受信状況情報を得られるので、管理端末のＰＬＣネットワークからの離脱の判断を確実に実施することができる。
【０１５２】
以下、図１３および図１４を用いて、クライアント端末における管理端末のネットワークからの離脱の判断動作、および、ＢＣＨおよびＦＣＨの受信状況情報の同報通信の動作について説明する。
【０１５３】
なお、本実施の形態２では、同報通信チャンネルとして、管理端末に対してアソシエーション、認証、帯域割当などを要求するＲＣＨチャンネルを用いてＢＣＨ、ＦＣＨの受信状態を同報通信する場合について説明する。また、クライアント端末の管理端末からのＢＣＨおよびＦＣＨの受信、フラグセット状況などの動作フローは、実施の形態１において図９を用いて説明したフローと同様であり、図１３は、図９に続くフローとして示し、図９における記号（Ａ）と図１３における記号（Ａ）とで、図９と図１３とが互いに接続されている。また、図１３における記号（Ｄ）と図１４における記号（Ｄ）とで、図１３と図１４とが互いに接続されている。さらに、図９における記号（Ｅ）と図１４における記号（Ｅ）とで、図９と図１４とが互いに接続されている。
【０１５４】
図９を用いて説明した処理を経て、管理端末からのＢＣＨおよびＦＣＨの受信処理等が終了すると、ＣＰＵ１１は、図１３に示すステップＳ２０１において、ＦＣＨが正常に受信できた場合は、ＦＣＨのスケジュール情報に受信スロットがあるか否か、ＦＣＨが正常に受信できなかった場合は前回受信したスケジュール情報で固定帯域が割り当てられた受信スロットがあるか否かの確認を行う。
【０１５５】
そして、何れの受信スロットもない場合は、ステップＳ２０５に進み、何れかの受信スロットがある場合は、現在がＭＡＣフレームの受信時刻であるか否かを確認する（ステップＳ２０２）。
【０１５６】
ＭＡＣフレームの受信時刻に達していない場合は、ステップＳ２０２の確認処理を繰り返し、ＭＡＣフレームの受信時刻に達している場合は、ＭＡＣフレームの受信を開始して（ステップＳ２０３）、データの受信処理を行う。
【０１５７】
ＣＰＵ１１は、ステップＳ２０４において、全ての受信スロットについて、ステップＳ２０２、Ｓ２０３の処理を施したか否かを確認し、全ての受信スロットについての処理が完了している場合はステップＳ２０５に進み、処理が完了していないスロットがある場合は、ステップＳ２０２、Ｓ２０３の処理を繰り返す。
【０１５８】
続いて、ＣＰＵ１１は、ステップＳ２０５において送信スロットがあるか否かの確認を行う。すなわち、ＦＣＨが正常に受信できた場合はそのＦＣＨ中のスケジュール情報に送信スロットがあるか否か、ＦＣＨが正常に受信できなかった場合は前回受信したＦＣＨ中のスケジュール情報で固定帯域が割り当てられた送信スロットがあるかの否かの確認を実施する。
【０１５９】
そして、何れの送信スロットもない場合はステップＳ２１０に進み、何れかの送信スロットがある場合は、ＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８を制御して、送信するＭＡＣフレームデータを生成し、受信側のクライアント端末が管理端末からのＢＣＨ、ＦＣＨを正常に受信できていない場合に基準時刻の補正に用いる送信時刻情報を生成する（ステップＳ２０６）。
【０１６０】
その後、現在がＭＡＣフレームの送信時刻であるか否かを確認し（ステップ２０７）、送信時刻に達していれば、ＭＡＣフレームの送信を開始し（ステップＳ２０８）、ＭＡＣフレームの送信時刻に達していない場合は、ステップＳ２０７の確認処理を繰り返す。
【０１６１】
次に、ＣＰＵ１１は、全ての送信スロットについてステップＳ２０６〜Ｓ２０８の処理を施したか否かを確認し（ステップＳ２０９）、処理が完了していないスロットがある場合は、ステップＳ２０６以下の処理を繰り返し、全ての送信スロットについて処理が完了している場合は、ステップＳ２１０において、自クライアント端末での管理端末からのＢＣＨおよびＦＣＨの受信フラグのセット状況を確認する。そして、自クライアント端末において、管理端末からのＢＣＨおよびＦＣＨを受信しておらず、ＢＣＨおよびＦＣＨのＮＧフラグをセットしている場合には図１４に示すステップＳ２１２に進む。一方、ＢＣＨおよびＦＣＨのＮＧフラグをセットしている場合には、管理端末に対しての帯域割当要求通知であるＲＣＨを送信する（ステップＳ２１１）。
【０１６２】
すなわち、自クライアント端末にてＢＣＨのＮＧフラグおよびＦＣＨのＮＧフラグをセットした場合は、管理端末はネットワークから離脱した可能性があるとしてＲＣＨの送信を実施しないが、ＢＣＨのＯＫフラグまたはＦＣＨのＯＫフラグをセットした場合は、ＣＰＵ１１は、ＰＬＣネットワーク制御データ生成回路４０８を制御してＲＣＨの送信を実施する。
【０１６３】
ＲＣＨを送信した後、ＣＰＵ１１は、ステップＳ２１２において、現在が、各クライアント端末において、管理端末からのＢＣＨおよびＦＣＨの受信状況を示すフラグセット情報の送受信時間であるか否かを確認する。
【０１６４】
そして、フラグセット情報の送受信時間でない場合は、ステップＳ２１２の確認処理を繰り返し、フラグセット情報の送受信時間である場合は、ステップＳ２１３において、他のクライアント端末からのフラグセット情報を受信し、収集を開始する。
【０１６５】
また、ステップＳ２１４において、自クライアント端末のフラグセット情報の送信タイミングに達したか否かを確認し、フラグセット情報の送信タイミングに達していない場合は、ステップＳ２１４の確認処理を繰り返し、フラグセット情報の送信タイミングに達している場合は、ＰＬＣネットワーク制御データ生成回路４０８を制御して、自クライアント端末のフラグセット情報（ＢＣＨおよびＦＣＨの受信状況）を他のクライアント端末に対して同報送信する（ステップＳ２１５）。
【０１６６】
また、ＣＰＵ１１は、ステップＳ２１６において、現在が、各クライアント端末において、管理端末からのＢＣＨおよびＦＣＨの受信状況を示すフラグセット情報の送受信時間であるか否かを確認する。
【０１６７】
そして、フラグセット情報の送受信時間である場合は、ステップＳ２１６の確認処理を繰り返し、フラグセット情報の送受信時間でない場合は、ステップＳ２１７において、他のクライアント端末からのフラグセット情報の受信および収集を終了する。
【０１６８】
なお、上記管理端末に向けたＲＣＨの送信、および各クライアント端末間での管理端末からのＢＣＨおよびＦＣＨのフラグセット情報の送受信は、各クライアント端末の送信タイミングが重複しないように制御する。すなわち、クライアント端末どうしが同タイミングでデータを送信した場合、データが衝突して管理端末またはクライアント端末はデータの受信が不可能となるので、送信タイミングをずらして衝突を回避するように制御する。具体的には、各クライアント端末がランダムに送信タイミングを自クライアント端末内で発生させる。または、予め各クライアント端末での上記データの送信順位を設定しておき、データの衝突を回避するように制御しても良い。
【０１６９】
ＣＰＵ１１は、ステップＳ２１７に続いて、自クライアント端末でＢＣＨのＯＫフラグまたはＦＣＨのＯＫフラグがセットされているか否かを確認し、どちらかがセットされている場合は、管理端末は正常に動作しているものと判断し、ＬＥＡＶＥ  ＮＵＭの値を０にリセットする（ステップＳ２１９）。
【０１７０】
一方、自クライアント端末でＢＣＨのＯＫフラグ、ＦＣＨのＯＫフラグの何れもセットされていない場合（すなわち、自クライアント端末でＢＣＨのＮＧフラグおよびＦＣＨのＮＧフラグをセットした場合）は、ステップＳ２２０において、他のクライアント端末から、ＢＣＨまたはＦＣＨのＯＫフラグを受信したか否かを確認する。
【０１７１】
そして、他のクライアント端末からのＢＣＨまたはＦＣＨのＯＫフラグの受信を確認した場合、すなわち、他のクライアント端末ではＢＣＨまたはＦＣＨのＯＫフラグがセットされている場合は、自クライアント端末は伝送路のノイズ状況などの一時的な要因により管理端末からＢＣＨまたはＦＣＨが受信できなかったものの、管理端末は正常に動作しているものと判断して、ＬＥＡＶＥ  ＮＵＭの値を０にリセットする（ステップＳ２１９）。
【０１７２】
一方、他のクライアント端末からのＢＣＨまたはＦＣＨのＯＫフラグの受信を確認できない場合は、ステップＳ２２１において、送信側のクライアント端末から、ＢＣＨおよびＦＣＨのＮＧフラグを受信を確認したか否かを確認する。
【０１７３】
そして、他のクライアント端末からのＢＣＨおよびＦＣＨのＮＧフラグの受信を確認した場合、すなわち、他のクライアント端末でもＢＣＨおよびＦＣＨのＮＧフラグがセットされている場合は、ステップＳ２２２において、何台の他のクライアント端末からＮＧフラグを受信したかについてカウントし、ＬＥＡＶＥ  ＮＵＭの値に当該台数分のカウント数を加算する。
【０１７４】
一方、他のクライアント端末からのＢＣＨおよびＦＣＨのＮＧフラグの受信を確認できない場合は、他のクライアント端末からのＢＣＨのＯＫフラグおよびＮＧフラグ、ＦＣＨのＯＫフラグおよびＮＧフラグの何れも正常に受信できなかったものと判断し、自クライアント端末と送信側のクライアント端末との通信に支障が発生しているものとして、自クライアント端末でのＬＥＡＶＥ  ＮＵＭのリセット動作を行わず、ステップＳ２２５に進む。
【０１７５】
ステップＳ２２３の後、ステップＳ２２４において、ＬＥＡＶＥ  ＮＵＭの値が、予め定めた所定の値より大きくなったか否か、すなわちカウント回数が所定回数より大きくなったか否かを確認する。
【０１７６】
そして、ＬＥＡＶＥ  ＮＵＭのカウント回数が所定回数より大きくなったことを確認した場合には、自クライアント端末においても、また他の送信クライアント端末においても管理端末からのＢＣＨおよびＦＣＨが受信できなくなっているものと判断し、管理端末がネットワークより離脱したものと判断して、ＮＥＷ  ＦＬＡＧを１にセットする（ステップＳ２２４）。
【０１７７】
なお、ＬＥＡＶＥ  ＮＵＭのカウント回数が所定回数より大きくなっていない場合、およびＮＥＷ  ＦＬＡＧを１にセットした後はステップＳ２２５に進む。
【０１７８】
ステップＳ２２５においては、ＬＥＡＶＥ  ＮＵＭの値が０を越えるか否か、すなわち１以上であるか否かの確認を行う。ＬＥＡＶＥ  ＮＵＭの値が１以上の場合、管理端末が正常に動作していない可能性があるため、ステップＳ２２６において、新たな管理端末の生起の確認を実施する。なお、ステップＳ２２６の処理は、図１２を用いて説明したステップＳ１３９の処理と同じである。
【０１７９】
新たな管理端末の生起の確認を実施後、またはＬＥＡＶＥ  ＮＵＭの値が０である場合は、１つのＭＡＣフレームについてのデータ送受信は完了し、新たなＭＡＣフレームのデータ送受信のために図９に示すステップＳ１０１に戻る。
【０１８０】
＜Ｂ−２．効果＞
以上説明した実施の形態２のデータ送受信装置１０を用いることで、クライアント端末間で映像ストリームの送受信中に管理端末がＰＬＣネットワークから離脱した場合、自クライアント端末は、他のクライアント端末の管理端末からのＢＣＨおよびＦＣＨの受信状況を示すフラグ設定情報の収集が迅速に実施でき、早い段階で管理端末のネットワークからの離脱を判断することができる。同時に、各クライアント端末のうちの１つが同期を継承、新たな管理端末として生起し、ネットワークトポロジを回復させることができる。
【０１８１】
また、映像ストリームを送信する際、固定帯域を割り当てるとともに、１フレーム内での固定帯域割当を同じ位置になるようにスケジューリングするので、前回受信したスケジュール情報、および基準時刻情報に基づいて映像ストリームの送受信をすれば、新たな管理端末が生起するまでの管理端末が不在の期間においても、映像ストリームを中断することなく伝送できる効果がある。
【０１８２】
＜Ｃ．変形例＞
以上説明した実施の形態１および２においては、本発明の適用例として高速ＰＬＣ端末に適用する場合について説明したが、本発明の適用はこれに限るものではなく、無線ＬＡＮ、あるいはＵＷＢ（Ultra Wideband）、あるいはＴＤＭＡ方式、あるいは映像ストリームに固定的な帯域を割り当ててデータを送受信する仕組みを有するデータ送受信方式を採用する他の伝送方式にも適用が可能である。
【０１８３】
また、固定帯域が割り当てられた受信クライアント端末側での基準時刻補正を、ＭＡＣヘッダに付加された送信クライアント端末側の基準時刻情報を用いて実施したが、これに限るものではなく、各クライアント端末内の基準クロックはほぼ管理端末の基準クロックに同期しているので、基準時刻補正を行わずに固定帯域が割り当てられたタイムスロットを使用してデータの送受信を実施することも可能である。
【０１８４】
さらに、管理端末のＰＬＣネットワークからの離脱判定をＢＣＨおよびＦＣＨともに受信できなかった場合について説明したが、これに限るものではなく、ＰＬＣネットワーク内の同期、および帯域を管理する制御フレームの送受信状態によって判断するよう構成すれば同様の効果を得ることができる。また、固定帯域割当に映像ストリームを伝送する場合について説明したが、これに限るものではなく、オーディオ、あるいは音声等に適用して実施することも可能である。
【図面の簡単な説明】
【０１８５】
【図１】本発明に係るデータ送受信装置を適用した高速ＰＬＣネットワークシステムの構成を示す図である。
【図２】本発明に係るデータ送受信装置の構成を説明するブロック図である。
【図３】本発明に係るデータ送受信装置内のＰＬＣモデム回路の構成を示すブロック図である。
【図４】ＰＬＣモデム回路内のＰＬＣ送信制御回路の構成を示すブロック図である。
【図５】ＰＬＣモデム回路内のＰＬＣ受信制御回路の構成を示すブロック図である。
【図６】高速ＰＬＣを用いたデータ送受信装置にてデータ送受信を行う際の、１フレーム内のデータフォーマットおよびＦＣＨ内のスケジュールデータの構成を示す図である。
【図７】本発明に係るデータ送受信装置を管理端末として使用する場合の動作を説明するフローチャートである。
【図８】本発明に係るデータ送受信装置を管理端末として使用する場合の、新たな管理端末候補の優先順位情報の生成方法を説明するフローチャートである。
【図９】本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態１の動作を説明するフローチャートである。
【図１０】本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態１の動作を説明するフローチャートである。
【図１１】本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態１の動作を説明するフローチャートである。
【図１２】本発明に係るデータ送受信装置をクライアント端末として使用する場合の、新たな管理端末の生起を説明するフローチャートである。
【図１３】本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態２の動作を説明するフローチャートである。
【図１４】本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態２の動作を説明するフローチャートである。
【図１】
2008270945.tif 000003
【図２】
2008270945.tif 000004
【図３】
2008270945.tif 000005
【図４】
2008270945.tif 000006
【図５】
2008270945.tif 000007
【図６】
2008270945.tif 000008
【図７】
2008270945.tif 000009
【図８】
2008270945.tif 000010
【図９】
2008270945.tif 000011
【図１０】
2008270945.tif 000012
【図１１】
2008270945.tif 000013
【図１２】
2008270945.tif 000014
【図１３】
2008270945.tif 000015
【図１４】
2008270945.tif 000016