JP5178405B2 - データ送受信装置 - Google Patents

Description

本発明はデータ送受信装置に関し、特に、無線通信あるいは高速ＰＬＣ（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期間と表記）を準備している。

管理端末は、ＲＣＨ期間に上記送信スロット要求リクエストを受け取った端末に対しては、次の１フレームのＢｅａｃｏｎ周期内のＡＣＨにて帯域割当要求を受け取った旨を通知する。

次に、上述したＨｉＳＷＡＮａ規格をベースとしたＴＤＭＡ方式を、例えば高速ＰＬＣに適用した従来のデータ送受信装置におけるシステム構成について説明する。

一般に、無線ＬＡＮや高速ＰＬＣをベースとしたデータ送受信装置では、クライアント端末間でデータの送受信を実施する際は、管理端末経由でデータの送受信を実施する。具体的には、第１のクライアント端末から第２のクライアント端末にデータを送信する際は、第１のクライアント端末は管理端末に対して送信データを送り、データを受け取った管理端末は第２のクライアント端末に受信したデータを送信する。この場合、第１のクライアント端末から第２のクライアント端末に対してのデータの送信であるにもかかわらず、管理端末を経由するため、限られた帯域を２倍使用することになる。

このような問題を解決するため、クライアント端末間で直接にデータの送受信を実施する方法がある。すなわち、ＴＤＭＡ方式では、先に説明したように、管理端末と各クライアント端末間の同期は、定期的に管理端末から出力されるＢｅａｃｏｎ信号によって確保されている。従って、スケジューリングの概念を拡張することにより同期の取れたクライアント端末間の直接通信が可能となる。

以下、管理端末により同期の取れたクライアント端末間で直接通信を行う事例として、管理端末である寝室のＴＶ（Television）システムと、クライアント端末である子供部屋のＴＶシステム、同じくクライアント端末である居間のレコーダの３つのＡＶ（Audio Visual）機器が高速ＰＬＣに接続されており、居間のレコーダから子供部屋のＴＶシステムに映像ストリームデータが送信され、子供部屋のＴＶシステムで映像を表示している例を挙げる。

この例においては、寝室のＴＶシステムから出力されるＢＣＨにより子供部屋のテレビおよび居間のレコーダは同期の取れた通信が可能となっており、また、寝室のＴＶシステムから出力されるＦＣＨにより居間のレコーダの映像データ送信タイミングがスケジューリングされ、子供部屋のＴＶは居間のレコーダからの映像データ受信タイミングがスケジューリングされている。

しかし、上記事例において高速ＰＬＣの伝送路上にノイズが発生し、寝室のＴＶシステムと子供部屋のＴＶシステムの通信が途切れたものとする。このとき子供部屋のＴＶシステムとしては管理端末からのＢＣＨ、ＦＣＨ等の制御情報が受信できなくなり、同期がとれなくなると共に、スケジュールデータが受信できなくなるため、映像表示が中断ないしは乱れるという状況が発生する。

以上述べたように、管理端末によりクライアント端末間の直接通信の制御が行われるネットワークの場合においては、管理端末とクライアント端末との通信が伝送路の不具合により途切れると、クライアント端末間の通信は伝送路の不具合がなくともそれらクライアント端末間のデータ送受信が途切れるといった問題がある。

ここで、特許文献１では、管理端末を有しないクライアント端末間で直接にデータを送受信する自律分散的なアドホックネットワークにおいて、各通信装置間で複雑な同期処理を実行しなくとも、各通信装置間で通信処理を実行することが可能な通信システムについての記載がなされている。

そして、特許文献１には、制御局と被制御局の関係を有しない複数の通信装置から構成される通信システムにおいて、信号の送信および／ 又は受信する複数の時間枠から構成された所定周期のスーパーフレームを自己の通信装置のクロック情報に基づいて設定するステップと； スーパーフレームにおいて， 少なくともビーコン信号を送信するための時間枠を決定するステップと； 自己の通信装置と通信可能な通信エリア内に存在する他の通信装置によりスーパーフレームの周期で送信されたビーコン信号を自己の通信装置が受信するステップと； 他の通信装置からのビーコン信号に記載された信号を送信および／ 又は受信するための時間枠と， 少なくとも自己の通信装置がビーコン信号を送信するための時間枠とを時間枠管理表に自己の通信装置のクロック情報に基づいて割当てるステップを有するものに関する記載がある。

しかしながら、特許文献１では、各クライアント端末が時間枠管理表の制御においてスーパーフレームに自己の通信装置のビーコン送信位置を割り当て、一定周期でビーコン信号が送信される。そのためデータを送信しない端末も一定周期でビーコン信号を送信するため、不必要な送信帯域を使用してしまうといった問題がある。

特に高速ＰＬＣでは１ＯＦＤＭシンボルのシンボル長が長くとられている場合が多く、ネットワークに接続されている各クライアント端末が一定周期でビーコン信号を送出した場合、同期をとるためのオーバーヘッド（無駄な帯域使用）が発生するといった問題点がある。例えば、１ＯＦＤＭシンボル長を５０μｓとし、プリアンブルを４シンボル、ペイロードを１シンボルとした場合でも、１クライアント端末あたり少なくともビーコン送出に２５０μｓの伝送帯域を使用することになる。

特開２００６−１２１３３２号公報

本発明は上記のような問題点を解消するためになされたものであり、クライアント端末間で直接通信が可能なネットワークシステムにおいて、管理端末とクライアント端末との通信が途切れた場合でも、クライアント端末間で伝送中の映像ストリームデータが途切れることなくクライアント端末間での同期を保持し、ネットワーク内に新たな管理端末を生起させることが可能なデータ送受信装置を提供することを目的とする。

本発明に係る請求項１記載のデータ送受信装置は、ネットワークシステムの複数の端末のそれぞれに含まれるデータ送受信装置であって、前記複数の端末は、他の端末を管理する管理端末と、該管理端末により管理されるクライアント端末を複数含み、前記管理端末より定期的に出力される同期情報、およびスケジュール情報に基づいて前記複数の端末間での映像データおよび制御データの送受信が実行され、前記データ送受信装置は、前記管理端末より出力される同期情報およびスケジュール情報を検出する制御情報検出部と、前記同期情報および前記スケジュール情報が前記管理端末から正常に受信できたか否かの受信状況情報を確認するとともに、前記受信状況情報に基づいて前記管理端末と継続して正常に通信ができているか否かを判断して、受信状況経過情報を生成する制御部と、前記制御情報検出部で検出された前記スケジュール情報に基づいてデータの受信タイミングを含むタイミング情報を生成するタイミング生成部とを備え、前記制御部は、データ受信中で固定帯域割当てされている割合が多い端末ほど小さな値が設定された閾値を有し、前記受信状況経過情報により前記管理端末と継続して正常に通信できない回数が前記閾値以上と判断されたときに、管理端末通信不良通知を生成して他のクライアント端末に送信し、前記他のクライアント端末から前記管理端末に代わる新管理端末候補としての承認を得ることで、自機が、前記新管理端末として動作を開始するように制御し、前記同期情報および前記スケジュール情報の少なくとも一方が受信できなかった場合、前回までに受信したスケジュール情報に基づいて前記タイミング生成部を制御するとともに、前回までに受信した前記スケジュール情報に基づいて検出したクロックの誤差情報を用いて基準時刻を補正し、自機が前記管理端末通信不良通知を出していない場合であって、前記他のクライアント端末から前記管理端末通信不良通知を受信した場合、自機において前記同期情報を受信できなかったときは、前記管理端末通信不良通知の送信元に対して、前記新管理端末として生起することを承認する新管理端末承認通知を送信し、自機において前記同期情報を受信できたときは前記管理端末通信不良通知の送信元に対して、前記新管理端末承認通知を送信せず、前記管理端末が正常に稼働していることを示す管理端末正常稼働通知を生成して、前記管理端末通信不良通知の送信元に送信するものであって、前記管理端末通信不良通知の送信元は、他の端末から前記管理端末正常稼働通知を受信した場合は、自機を前記新管理端末として動作を開始しないように制御する。

本発明に係る請求項１記載のデータ送受信装置によれば、クライアント端末において、受信状況経過情報により管理端末と継続して正常に通信できないないと判断された場合、管理端末通信不良通知を生成して他のクライアント端末に送信し、他のクライアント端末から管理端末に代わる新管理端末候補としての承認を得ることで、自機が、新管理端末として動作を開始するので、再びネットワーク内に新たな管理端末を生起させることができる。また、同期情報およびスケジュール情報の少なくとも一方が受信できなかった場合、前回までに受信したスケジュール情報に基づいてタイミング生成部を制御し、までに受信した前記スケジュール情報に基づいて検出したクロックの誤差情報を用いて基準時刻を補正するので、同期情報やスケジュール情報が受信できなかった場合でも同期を承継できネットワークトポロジを回復させることができる。また、管理端末通信不良通知の送信元は、他の端末から前記管理端末正常稼働通知を受信した場合は、自機を前記新管理端末として動作を開始しないように制御するので、管理端末が頻繁に入れ替わってネットワークシステムの同期通信が不安定化するのを防ぐことができる。

＜Ａ．実施の形態１＞
＜Ａ−１．ネットワークシステムの構成＞
図１は、本発明の実施の形態１に係るデータ送受信装置を備えた高速ＰＬＣネットワークシステムの構成を概略的に示す図である。なお、以下においては、データ送受信装置を端末と呼称する。

図１に示すように、当該高速ＰＬＣネットワークシステムは、ネットワーク全体を管理する管理端末１、ＰＬＣネットワークシステムに接続されたクライアント端末Ａ３、クライアント端末Ｂ５およびクライアント端末Ｂ７と、信号ラインともなる電灯線９とを備え、管理端末１、クライアント端末Ａ３、クライアント端末Ｂ５およびクライアント端末Ｂ７と電灯線９との間は、それぞれ電源コンセント２、４、６および８によって電気的に接続されている。

なお、図１に示された高速ＰＬＣネットワークシステムの構成は、本発明のデータ送受信装置が適用できるシステム構成の一例であり、本発明のデータ送受信装置は、他の構成を持つ高速ＰＬＣネットワークシステム、無線ＬＡＮを用いたネットワークシステム、Ｅｔｈｅｒｎｅｔ（登録商標）を用いたネットワークシステムなどの他のシステムにも適用可能である。また、本発明に係るデータ送受信装置は、ＴＶシステム、ＤＶＤレコーダの内部において、Ｅｔｈｅｒｎｅｔインターフェイスを介して接続されているものとする。

＜Ａ−２．ネットワークシステムの概略動作＞
次に、図１を用いて高速ＰＬＣネットワーク内での管理端末１の動作を中心として、当該ネットワークシステムの概略動作について説明する。なお、実施の形態１では、ＭＡＣ（Media Access Control）方式として、従来技術として説明したＨｉＳＷＡＮａ規格で採用されたＴＤＭＡ方式を採用した場合を例に説明する。

＜Ａ−２−１．管理端末の動作＞
管理端末１は、最初にネットワーク全体の時刻同期を管理するために同期情報としてＢｅａｃｏｎ信号（ＢＣＨ：Broadcast CHannel）を予め定められた周期で同報通信する。ＢＣＨ送信後、管理端末１は高速ＰＬＣネットワーク内の各クライアント端末のデータ受信およびデータ送信のタイミング情報（ＦＣＨ：Frame CHannel）を同報通信する。ＦＣＨ送信後、前フレームで各クライアント端末より出力されるＲＣＨ（Random access CHannel）を受信した場合、ＲＣＨの送信クライアント端末に対して正常受信したことを通知するＡＣＨ（Access feedback CHannel）を出力する。

ＡＣＨ送信後は、ＦＣＨにて送信されたスケジュールに基づき管理端末１、クライアント端末Ａ３、クライアント端末Ｂ５およびクライアント端末Ｃ７は、各クライアント端末間でのデータの送受信を実施する。

また、管理端末１は高速ＰＬＣネットワーク内で伝送路上にノイズが発生するなどしてクライアント端末との通信が途切れ、その結果、元はクライアント端末であった端末が新たな管理端末として生起しているのを確認したとき、管理端末からクライアント端末となるよう制御する動作を実施する（詳細は後述）。

＜Ａ−２−２．クライアント端末の動作＞
次に、クライアント端末の動作について説明する。クライアント端末は、管理端末１より出力されるＢＣＨを受信すると、そのＢＣＨに基づいてクライアント端末内の基準時刻を同期させる。

基準時刻の同期を実施した後、各クライアント端末は管理端末１より出力されるＦＣＨに基づいて、それぞれのデータ送信タイミングおよびデータ受信タイミングを内部に設定し、データの送信および受信準備を開始する。データの送信の場合は、ＦＣＨに基づく送信時刻が近づくとＰＬＣ送信制御部（詳細は後述）は送信データの生成を開始し、所定のタイミングで電灯線９に送信データを送出する。データの受信の場合は、ＦＣＨに基づく受信時刻になるとＰＬＣ受信制御部（詳細は後述）が受信データを復調し、誤り検出などのデータ受信動作を実施する。

ＦＣＨでのスケジュールに基づくデータの送受信が終了すると、各クライアント端末は送信データを持っている場合はＲＣＨの期間に管理端末１に対して帯域割当要求を出力する。

また、各クライアント端末は、管理端末１との通信状況を監視し、正常に通信ができていなと判断した場合、自クライアント端末のデータ受信状況に基づいて新たな管理端末の候補として生起し、他クライアント端末からの承認により、新たな管理端末として動作を開始する制御を実施する（詳細は後述）。

＜Ａ−３．高速ＰＬＣ端末の構成＞
＜Ａ−３−１．データ送受信装置の構成＞
次に、図２〜図５を用いて高速ＰＬＣ端末の構成を説明する。
図２は本発明に係るデータ送受信装置を高速ＰＬＣ端末に適用した場合のデータ送受信装置１０の構成を示すブロック図である。

図２に示すように、データ送受信装置１０は、ＣＰＵ（Central Processing Unit）１１、Ｅｔｈｅｒｎｅｔインターフェイス回路１２、ブリッジインターフェイス回路１３、ブリッジ用メモリ１４、ＰＬＣモデム回路１５、ＰＬＣ送信用メモリ１６、ＰＬＣ受信用メモリ１７およびＣＰＵバス１８を備えている。

ここで、ブリッジインターフェイス回路１３は、Ｅｔｈｅｒｎｅｔインターフェイス回路１２より入力されるＥｔｈｅｒｎｅｔフレームデータ、Ｅｔｈｅｒｎｅｔインターフェイス回路１２へ出力されるＥｔｈｅｒｎｅｔフレームデータ、ＰＬＣモデム回路１５へ出力されるＥｔｈｅｒｎｅｔフレームデータ、ＰＬＣモデム回路１５から入力されるＥｔｈｅｒｎｅｔフレームデータをブリッジする回路である。

また、ブリッジ用メモリ１４は、ブリッジインターフェイス回路１３に入力されたＥｔｈｅｒｎｅｔフレームが、宛先ごとに振り分けられて記憶するメモリであり、ＰＬＣ送信用メモリ１６は、電灯線９（図１）を介して送出するＭＡＣフレームデータを記憶するメモリであり、ＰＬＣ受信用メモリ１７は、電灯線９を介して受信したＭＡＣフレームデータを記憶するメモリである。

そして、Ｅｔｈｅｒｎｅｔインターフェイス回路１２は、入力端子２０および出力端子２１を介してＥｔｈｅｒｎｅｔフレームデータを、外部からデータ送受信装置１０に入力およびデータ送受信装置１０から外部に出力する回路であり、ＰＬＣモデム回路１５は、出力端子２２を介して外部にフレームデータを送信し、また入力端子２３を介して入力されたＰＬＣフレームを受信する回路である。

一般に、高速ＰＬＣネットワークでは、電灯線９（図１）に接続された各端末を論理ポートという概念を用いて、ブリッジインターフェイス回路１３において、宛先（図１中の管理端末１、クライアント端末Ａ３、クライアント端末Ｂ５およびクライアント端末Ｃ７）ごとにデータを振り分けて、ブリッジ用メモリ１４内にキューイングする。

具体的にはＥｔｈｅｒｎｅｔインターフェイス回路１２より入力されるＥｔｈｅｒｎｅｔフレームデータを、その行き先ごとにブリッジ用メモリ１４内に振り分けて記憶する処理である。

＜Ａ−３−２．ＰＬＣモデム回路の構成＞
図３は、図２に示したデータ送受信装置１０内のＰＬＣモデム回路１５の構成を示すブロック図である。
図３に示すようにＰＬＣモデム回路１５は、ブリッジインターフェイス回路１３より入力端子３０を介して入力されるＥｔｈｅｒｎｅｔデータを複数個連結してＰＬＣ用ＭＡＣフレームデータを生成するＰＬＣ送信制御回路４０と、電灯線９（図１）を介して受信したＰＬＣ用ＭＡＣフレームデータからＥｔｈｅｒｎｅｔフレームデータを分離して出力端子３１を介してブリッジインターフェイス回路１３に出力するＰＬＣ受信制御回路５０とを備えている。また、ＰＬＣ送信制御回路４０は、ＰＬＣ送信用メモリ１６との間で、送信用のＭＡＣフレームデータの授受を行い、ＰＬＣ受信制御回路５０は、受信用メモリ１７との間で、ＭＡＣフレームデータの授受を行う。

＜Ａ−３−３．ＰＬＣ送信制御回路の構成＞
図４は、図３に示したＰＬＣ送信制御回路４０の構成を示すブロック図である。
図４に示すようにＰＬＣ送信制御回路４０は、ＰＬＣフレームに付加するＭＡＣヘッダを生成するＰＬＣヘッダ生成回路４０１、ブリッジインターフェイス回路１３から入力端子３０を介して入力されるＥｔｈｅｒｎｅｔフレームデータを複数個集めて送信データを生成するパケットデータ生成回路４０２、パケットデータ生成回路４０２から出力されるデータに暗号化を施す暗号化回路４０３、後述するＰＬＣネットワーク制御データ生成回路４０８より出力されるＢｅａｃｏｎフレームデータやスケジュールデータ、新たな管理端末の生起に関する情報などと暗号化回路４０３より出力される暗号化されたデータとの切り換えを行うセレクタ４０４、セレクタ４０４より出力されるデータの先頭にＰＬＣヘッダ生成回路４０１にて生成されたＰＬＣ用ＭＡＣヘッダを付加するヘッダ付加回路４０５、ヘッダ付加回路４０５より出力されるデータと、後述するＰＬＣ送信用メモリ制御回路４０９より出力されるデータとの切り換えを行うセレクタ４０６、後述のＰＬＣネットワーク制御データ生成回路４０８に基づき、データ送受信装置１０よりＰＬＣネットワークへ出力するデータの送出タイミングを生成するＰＬＣ送信タイミング生成回路４０７、ＰＬＣネットワーク制御データ生成回路４０８、ＰＬＣ送信用メモリ制御回路４０９および、出力端子２２を介して外部に送信するＰＬＣフレームにＣＲＣ符号（誤り検出符号）を付加するＣＲＣ符号付加回路４１０を備えている。

ここで、ＰＬＣネットワーク制御データ生成回路４０８は、後述のＰＬＣ制御フレームデータ記憶回路５０５（図５）からの出力によりＣＰＵ１１が決定したスケジュールデータをもとに、データ送信タイミングをＰＬＣ送信タイミング生成回路４０７へ指示するとともに、ＣＰＵ１１からの情報に基づく自端末の基準時刻情報、前回の受信タイミングで、受信データが正常受信されたか否かを示すＡＣＫ／ＮＡＣＫ情報、送信するデータに付加するシーケンスナンバー、ＢＣＨ、ＦＣＨ等の制御チャンネルに付加するＢｅａｃｏｎ制御データ、管理端末を新たに生起させる制御情報などのデータを生成してセレクタ４０４に出力する回路である。

また、ＰＬＣ送信用メモリ制御回路４０９は、再送制御時に使用する送信フレームを、ＰＬＣ送信用メモリ１６に記憶する際の書き込み制御信号を発生するとともに、再送時にＰＬＣ送信用メモリ１６内に記憶されているデータを読み出すための読み出し制御信号を発生する回路である。

＜Ａ−３−４．ＰＬＣ受信制御回路の構成＞
図５は、図３に示したＰＬＣ受信制御回路５０の構成を示すブロック図である。
図５に示すようにＰＬＣ受信制御回路５０は、受信されたＰＬＣフレームよりＭＡＣヘッダを分離しその内容を解析するＰＬＣヘッダ解析回路５０１、受信されたＰＬＣフレームに付加されたＣＲＣ情報に基づいて受信ＰＬＣフレーム内に発生した誤りを検出するＣＲＣ復号回路５０２、ヘッダ解析回路５０１より出力される暗号化の施されたデータを復号する暗号復号回路５０３、ＰＬＣフレームに付加されているスケジュール情報などの制御フレーム情報、管理端末を新たに生起させる制御情報などと、Ｅｔｈｅｒｎｅｔフレーム情報などを分離するＰＬＣ制御フレーム分離回路５０４、ＰＬＣ制御フレーム分離回路５０４により分離されたＰＬＣ制御フレーム情報を一時的に記憶するＰＬＣ制御フレームデータ記憶回路５０５、ＰＬＣ受信用メモリ制御回路５０６、ＰＬＣ受信タイミング生成回路５０７およびＰＬＣネットワーク制御データ解析回路５０８を備えている。なお、ＰＬＣヘッダ解析回路５０１、暗号復号回路５０３およびＰＬＣ制御フレーム分離回路５０４は、ＢＣＨ、ＦＣＨ等の制御フレーム情報を検出する制御情報検出部を構成している。

ここで、ＰＬＣ受信用メモリ制御回路５０６は、ＰＬＣ制御フレーム分離回路５０４より出力されるＥｔｈｅｒｎｅｔフレーム情報を、一旦、ＰＬＣ受信用メモリ１７に記憶させるための制御信号を生成するとともに、ＣＲＣ復号回路５０２より出力される誤り検出結果に基づいて、ＰＬＣ受信用メモリ１７に記憶されているＥｔｈｅｒｎｅｔフレーム情報の読み出し制御を実施する回路である。

ＰＬＣ受信タイミング生成回路５０７は、ＰＬＣネットワーク制御データ解析回路５０８より出力される解析結果に基づき、ＰＬＣからのデータ受信タイミングを生成して、ヘッダ解析回路５０１、ＣＲＣ復号回路５０２、暗号復号回路５０３、ＰＬＣ制御フレーム分離回路５０４およびＰＬＣ受信用メモリ制御回路５０６に与える回路である。

また、ＰＬＣネットワーク制御データ解析回路５０８は、ＰＬＣ制御フレームデータ記憶回路５０５からの出力に基づいてスケジュールデータを解析し、データ受信タイミングをＰＬＣ受信タイミング生成回路５０７に指示する回路である。

また、ＰＬＣネットワーク制御データ解析回路５０８は管理端末からのＢＣＨ、ＦＣＨなどの制御情報の受信状況を解析し、ＢＣＨあるいはＦＣＨが受信できなかった場合、受信したＰＬＣ用ＭＡＣヘッダに付加された送信端末の時刻情報に基づき、受信端末内の時刻を調整するようにＰＬＣ受信タイミング生成回路５０７に時刻情報を出力すると共に、ＣＰＵ１１に通知する他、管理端末を新たに生起させる制御情報などの受信状況の解析も行う。

＜Ａ−４．１フレーム内のデータの送信タイミング＞
管理端末１では、ＰＬＣネットワーク全体の時刻同期を管理するため、従来の技術としても説明したように、周期的にＢＣＨによりＢｅａｃｏｎ信号を、またＦＣＨによりスケジュール情報を出力してネットワークを管理する。

図６には、１フレーム内の各種データの送信タイミングを示す。
図６に示すように、１フレームにおいては、ＢＣＨ、ＦＣＨおよびＡＣＨの順にネットワーク管理情報を送信した後、データ送受信期間にｎ個の通信スロットＬ１〜Ｌｎを送信し、最後にＲＣＨを送信することとなる。

実施の形態１では、ＢＣＨなどのＰＬＣネットワーク管理情報は２０ｍｓ周期で出力されるものとする。よって、管理端末１内のＰＬＣ送信制御回路４０ではＢｅａｃｏｎフレーム、およびスケジュール情報を２０ｍｓに一度の間隔で生成することになる。

また、実施の形態１では、Ｂｅａｃｏｎフレーム情報としては、Ｂｅａｃｏｎフレームを送出する際の管理端末１の時刻情報をペイロード情報として送出するものとする。

具体的には、Ｂｅａｃｏｎフレーム送出時のＰＬＣネットワーク制御データ生成回路４０８（図４）内の基準時刻情報を、ペイロード情報としてセレクタ４０４に出力する。一方、受信側となるクライアント端末では、Ｂｅａｃｏｎフレーム情報を受信すると、内部の受信基準時刻をＢｅａｃｏｎフレームに付加された送信側基準時刻に同期させる。管理端末１はＢＣＨの送信に引き続きＦＣＨ（スケジュール情報）の送信を実施する。

図６に示すように、ＦＣＨ内には受信時に受信データの先頭位置、およびクロック位相を検出するためのプリアンブル情報と、プリアンブル情報に続いて送信されるスケジュール情報とが含まれている。そして、スケジュール情報には、データ送受信期間に設けられた通信スロットＬ１〜Ｌｎにそれぞれ対応させて、送信開始時間、送信時間、どの端末（送信端末）からどの端末（受信端末）へのデータ送信かを示す端末情報、およびデータを送受信する際の送受信関連情報が含まれている。

実施の形態１では、送信端末情報および受信端末情報については、各端末の持つＭＡＣアドレス（Media Access Control Address）情報を用いるものとする。なお、ＭＡＣアドレス情報以外に、例えばそのＰＬＣネットワーク内の論理ポート番号、あるいはネットワーク内でプライベートに定められた識別情報であっても良い。

このように、ＦＣＨ内のスケジュール情報には通信スロットごとに対応した上記情報が付加されて伝送される。なお、通信スロットについては、映像ストリームの送信を開始するクライアント端末が、管理端末１に対してＲＣＨのタイムスロットを利用し、帯域割当要求を伝送することにより、管理端末１は映像ストリームの送信要求のあった端末に対して通信帯域を割り当てる。その際、管理端末１は、映像ストリームのようにリアルタイム性の要求されるデータに関しては、固定的に帯域を割り当てるようにスケジューリングを実施する。なお、固定的に割り当てられた帯域を、固定帯域、あるいは固定帯域割当と称する。

＜Ａ−５．管理端末の動作＞
次に、図７〜図９に示すフローチャートを用いてスケジュール情報（ＦＣＨ）の生成フローを含む管理端末１の動作について説明する。なお、図７における記号（Ａ）と図８における記号（Ａ）とで、図７と図８とが互いに接続されている。また、図８における記号（Ｂ）と図９における記号（Ｂ）とで、図８と図９とが互いに接続されている。さらに、図９における記号（Ｃ）と図７における記号（Ｃ）とで、図９と図７とが互いに接続されている。

図７に示すように、管理端末１がデータの送受信を開始すると、管理端末１のＣＰＵ１１は、は新管理端末が生起しているか否か（他端末からＢＣＨを受信したか否か）についての監視を開始する（ステップＳ１１）。

そして、ＢＣＨ生成開始タイミングに達したか否かの確認動作を繰り返し（ステップＳ１２）、ＢＣＨ生成開始タイミングになると管理端末１はＰＬＣネットワークを管理するＢＣＨを生成し（ステップＳ１３）、ＢＣＨ送信開始タイミングに達したか否かの確認動作を繰り返す（ステップＳ１４）。そして、ＢＣＨ送信開始タイミングになると、各クライアント端末に向けてＢＣＨを同報通信する（ステップＳ１５）。

上記の動作を終えると、前回までに受信したＲＣＨを解析し（ステップＳ１６）、次の動作でのスケジュール情報（ＦＣＨ）の生成開始の準備に入る。

そして、ＦＣＨ生成開始タイミングに達したか否かの確認動作を繰り返し（ステップＳ１７）、ＦＣＨ生成開始タイミングとなると、管理端末１は固定帯域割当が実施されているクライアント端末があるか否かを確認し（ステップＳ１８）、固定帯域が割り当てられているクライアント端末がある場合は、ステップＳ１９で固定帯域用のタイムスロットを継続して割り当ててステップＳ２０に進む。なお、固定帯域が割り当てられているクライアント端末が存在しない場合は、そのままステップＳ２０に進む。

ステップＳ２０では、前フレームにて固定帯域用タイムスロット割当の解放要求をしているクライアント端末があったか否かを確認し、当該解放要求があった場合は、管理端末１はステップＳ２１で当該要求を出したクライアント端末に対する固定帯域割当を解放してステップＳ２２（図８）に進む。なお、解放要求をしているクライアント端末が存在しない場合は、そのままステップＳ２２に進む。

ステップＳ２２では、管理端末１は前フレームで新たな固定帯域割当要求があったか否か確認する。新たな固定帯域割当要求があった場合は、現在割り当てている固定帯域用のタイムスロットを確認し、１フレーム内の通信スロットの余剰状態から新たな固定帯域を割り当てることができるか否かを確認する（ステップＳ２３）。なお、新たな固定帯域割当要求がなかった場合はステップＳ２６に進む。

そして、新たな固定帯域割当が可能な場合は、新たに固定帯域を要求してきたクライアント端末向けに固定帯域を割り当てる（ステップＳ２４）。一方、新たに固定帯域を割り当てることができなかった場合は、新たに固定帯域を要求してきたクライアント端末向けに固定帯域割当不可通知（ＡＣＨに含めて送信される）を生成する（ステップＳ２５）。

次に、管理端末１のＣＰＵ１１は、制御コマンド用の帯域割当要求が、クライアント端末よりあったか否かを確認する（ステップＳ２６）。そして、制御コマンド用の帯域割当要求があった場合は、ステップＳ２７で制御コマンド用のタイムスロットを割り当ててステップＳ２８に進み、要求がなかった場合は、そのままステップＳ２８に進む。

なお、実施の形態１では映像ストリームなどを伝送する場合、ユーザがリモコンで機器制御を実施する、あるいは著作権管理のために、鍵情報などを交換するなど様々なケースで映像ストリーム以外の制御コマンドがやりとりされることを想定している。従って、新規端末に対してステップＳ２４にて固定帯域を割り当てる場合は、少なくとも１フレーム内に１タイムスロット以上の制御コマンド用の帯域を割り当てられるように帯域を確保した後、新規端末へのタイムスロットを割り当てるものとする。

ステップＳ２８では、管理端末１は各クライアント端末へＢＣＨ、ＦＣＨを含むＰＬＣネットワーク制御情報などを送信するための管理端末送信用タイムスロットを割り当てる。

次に、管理端末１のＣＰＵ１１は、前フレームにて固定帯域割当以外の通常の帯域割当（以下、通常帯域割当と表記）の要求があったか否かを確認する（ステップＳ２９）。新たな通常帯域割当要求があった場合は、通常帯域を割り当てることができるか否かを確認する（ステップＳ３０）。なお、新たな通常帯域割当要求がなかった場合はステップＳ３３に進む。

そして、新たに通常帯域割当が可能であった場合は、新たに通常帯域を要求してきたクライアント端末向けに通常帯域を割り当てる（ステップＳ３１）。一方、新たに通常帯域を割り当てることができなかった場合は、新たに通常帯域を要求してきたクライアント端末向けに通常帯域割当不可通知（ＡＣＨに含めて送信される）を生成する（ステップＳ３２）。

以上の各タイムスロットの割り当が完了すると、ステップＳ３３では、割り当てを行った管理端末１を含めて、各クライアント端末の上記タイムスロット情報を基にＦＣＨを生成し、管理端末１自身が割り当てたタイムスロットに基づき、ＦＣＨ送信開始タイミングに達したか否かの確認動作を繰り返し（ステップＳ３４）、ＦＣＨ送信開始タイミングとなると、図９に示すように各クライアント端末にＦＣＨを送信する（ステップＳ３５）。

そして、ＡＣＨ送信開始タイミングに達したか否かの確認動作を繰り返し（ステップＳ３６）、ＡＣＨ送信開始タイミングとなると、管理端末１はタイムスロット割当において生成したＡＣＨを各クライアント端末に送信する（ステップＳ３７）。

なお、ステップＳ３３（図８）においてＦＣＨフレームを生成する際、実施の形態１では各クライアント端末に割り当てる固定帯域割当は、フレーム内では基本的に同一位置に割り当てるものとする。これは、以下の理由に基づく。すなわち、固定帯域割当により伝送する映像ストリームのようなデータ（ＶｏＩＰのような音声データも同様）は、伝送する平均データ伝送レートはほぼ一定である。従って、管理端末１より送信されたＦＣＨフレームを周辺機器ノイズの影響で受信できなかった場合でも、各クライアント端末間の同期が確保されていれば、前回受信したスケジュール情報に基づいて伝送すればデータの送受信を実施することができるからである。また、詳細は後述するがクライアント端末間で映像ストリームを再生中に管理端末１と通信が途切れた場合、各クライアント端末間のクロック同期が確立していれば、前回受信したスケジュール情報を基に映像ストリームを送信すれば、新たな管理端末が生起するまでの間、再生画像を乱すことなく伝送することができるからである。

ＡＣＨの各クライアント端末への送信が完了すると、管理端末１および各クライアント端末はスケジュール情報を基にデータの送受信（ＴＣＨ期間）を実施する（ステップＳ３８）。そして、各クライアント端末からの帯域割当要求を受け付けるためのＲＣＨ期間に達したか否かの確認動作を繰り返し（ステップＳ３９）、ＲＣＨ期間となると、ＲＣＨの受信を実施し（ステップＳ４０）、それはＲＣＨ期間が終了するまで維持される（ステップＳ４１）。

ＲＣＨ期間の終了後、管理端末１のＣＰＵ１１は、ステップＳ１２〜Ｓ４１の間に、ステップＳ１１（図７）で監視を始めた新管理端末の生起の有無（他クライアント端末からＢＣＨを受信したか否か）を判断し（ステップＳ４２）、新管理端末が生起していないと判断した場合は、次回の送受信においても管理端末として動作し、ステップＳ１１以下の動作を繰り返す。一方、新管理端末が生起していると判断した場合は、次回の送受信においては管理端末としての動作を停止し、クライアント端末としての動作を開始する（ステップＳ４３）。

これにより、新管理端末が生起した後も、現在までの管理端末が管理端末として動作を続けるという状況が防止でき、複数の管理端末が存在して混乱することを防止できる。

また、新管理端末が生起すると、他のクライアント端末は、新管理端末からＢＣＨを受信することで新管理端末の生起を確認し、新管理端末に従った動作を開始し、現在までの管理端末を非管理端末とみなす。

これにより、現在までの管理端末が、管理端末として動作を続けた場合であっても、他のクライアント端末は新管理端末に従うので、仮に、一時的に複数の管理端末が存在しても混乱することがない。

なお、以上説明したステップＳ１１〜Ｓ４３の動作は、管理端末のＣＰＵ１１が主体となって行う動作である。

＜Ａ−６．クライアント端末の動作＞
次に、図１０〜図１２を用いてクライアント端末のデータ送受信動作について説明する。なお、図１０における記号（Ａ）と図１１における記号（Ａ）とで、図１０と図１１とが互いに接続されている。また、図１１における記号（Ｂ）と図１２における記号（Ｂ）とで、図１１と図１２とが互いに接続されている。さらに、図１２における記号（Ｃ）と図１０における記号（Ｃ）とで、図１２と図１０とが互いに接続されている。

図１０に示すように、クライアント端末がデータの送受信を開始すると、当該クライアント端末のＣＰＵ１１は、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴ、およびＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴを０に初期化する（ステップＳ１０１）。

フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴ（詳細は後述）は、管理端末１からのＢＣＨを連続で何回受信できなかったか計数するカウンタであり、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴ（詳細は後述）は、管理端末１からのＦＣＨを連続で何回受信できなかったかを計数するカウンタである。

なお、これらのカウンタは、図３に示したＰＬＣモデム回路１５内のＰＬＣ受信制御回路５０内に配置され、ＰＬＣネットワーク制御データ解析回路５０８（図５）よりＢＣＨ、ＦＣＨの受信状況のデータを受け、ＣＰＵ１１によって制御される。

クライアント端末のＣＰＵ１１は前回までの送受信動作で受信したスケジュール情報に基づき、ＢＣＨの受信時刻に達したか否かの確認動作を繰り返し（ステップＳ１０２）、ＢＣＨの受信時刻となると、管理端末からのＢＣＨの受信の成否を確認する（ステップＳ１０３）。

そして、管理端末よりＢＣＨを正常に受信できた場合は、受信したＢＣＨが前回の受信動作における管理端末と同じ端末から送信されたものかどうかを判断する（ステップＳ１０４）。クライアント端末はこの判断を行うために、ＢＣＨの受信ごとに管理端末の端末情報を記録し、今回の受信動作における管理端末が前回の受信動作における管理端末と同一か否かを判断するのに使用する。

ステップＳ１０４において、今回も前回と同じ管理端末からＢＣＨを受信したと判断した場合、今回受信した管理端末（現管理端末）からのＢＣＨを基に自クライアント端末内の基準時刻を同期し（ステップＳ１０５）、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴを０とする（ステップＳ１０６）。

一方、ステップＳ１０４において、前回と違う管理端末（新たに生起した管理端末）からＢＣＨを受信したと判断した場合、今回受信した新管理端末からのＢＣＨを基に自クライアント端末内の基準時刻を同期し（ステップＳ１０７）、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴおよびＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴを０とする（ステップＳ１０８）。また、自クライアント端末が新たな管理端末として生起するか否かを示すＮＥＷ・ＦＬＡＧは０とする（ステップＳ１０９）。

ここで、ＮＥＷ・ＦＬＡＧとは自クライアント端末内で、新たな管理端末となる候補としての動作を実施するか否かの基準となる動作基準フラグであり、これが、例えば１に設定された場合は新たな管理端末となる候補としての動作を実施するものとし、０に設定された場合は新たな管理端末となる候補としての動作は実施しない。

なお、ステップＳ１０３において、クライアント端末が管理端末よりのＢＣＨを正常に受信できなかった場合は、ＢＣＨを用いた管理端末との基準クロックの同期制御を、前回までに受信したＢＣＨを基に検出した誤差情報を用いて自クライアント端末の基準時刻を補正する（ステップＳ１１０）。

これは前回までに受信したＢＣＨで管理端末とクライアント端末間はほぼクロック同期（実際には数ｐｐｍ以下のクロック周波数誤差が存在）が確立しているため、誤差情報を用いてもＢＣＨが復帰するまでの期間があまり長くなければ、ＰＬＣネットワークのクロック同期を確立することができるためである。

これにより、クライアント端末間で映像ストリームの送受信中に管理端末がＰＬＣネットワークから離脱するなどしてクライアント端末がＢＣＨ、ＦＣＨ等のネットワーク管理情報を受信できなかった場合でも同期を継承できネットワークトポロジを回復させることができる。

なお、ＢＣＨが正常に受信できなかったので、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴを１つインクリメントする（ステップＳ１１１）。

次に、ＣＰＵ１１は、ＦＣＨの受信時刻に達したか否かの確認動作を繰り返し（ステップＳ１１２）、ＦＣＨの受信時刻となると、ステップＳ１１３（図１１）において管理端末からのＦＣＨの受信の成否を確認する。そして、管理端末よりのＦＣＨを正常に受信できた場合は、ＦＣＨからスケジュール情報を確認し（ステップＳ１１４）、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴを０とする（ステップＳ１１５）。

なお、ステップＳ１１３において管理端末からのＦＣＨが正常に受信できなかった場合は、前回の受信動作で受信したＦＣＨを基にスケジュール情報を確認し（ステップＳ１１６）、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴを１つインクリメントする（ステップＳ１１７）。

ここで、前述の通り、管理端末が各クライアント端末に割り当てる固定帯域割当は、フレーム内では基本的に同一位置に割り当てられているため、ＦＣＨが復帰するまでの期間があまり長くなければ、前回受信したＦＣＨに基づいたスケジュール情報による映像ストリームの伝送においても再生画像を乱すことなく実施することができる。

スケジュール情報の確認後は、ステップＳ１１８において受信スロットの有無についての確認を行い、受信スロットがある場合は、その受信スロットに合わせた受信時刻情報の生成を行う（ステップＳ１１９）。一方、受信スロットがない場合は、図１２のステップＳ１２３に進む。

そして、受信時刻に達したか否かの確認動作を繰り返し（ステップＳ１２０）、受信時刻となるとＭＡＣフレームの受信を開始し（ステップＳ１２１）、データの受信処理を行う。次に、ステップＳ１２２では、受信スロットの受信完了の有無を確認し、受信スロットが複数あり、すべての受信動作が完了していない場合は、ステップＳ１２０以下の動作を繰り返し、ＭＡＣフレームの受信動作を継続する。

一方、受信スロットの受信が完了し、ＭＡＣフレームの受信動作が完了すると、ステップＳ１２３（図１２）においてスケジュール情報から送信スロットの有無を確認し、送信スロットがある場合は、その送信スロットに合わせた送信時刻情報の生成を行う（ステップＳ１２４）。一方、送信スロットがない場合は、ステップＳ１２８に進む。

そして、送信時刻に達したか否かの確認動作を繰り返し（ステップＳ１２５）、送信時刻となると、ＭＡＣフレームの送信を開始し（ステップＳ１２６）、データの送信処理を行う。次に、ステップＳ１２７では、送信スロットの送信完了の有無を確認し、送信スロットが複数あり、すべての送信動作が完了していない場合は、ステップＳ１２５以下の動作を繰り返し、ＭＡＣフレームの送信動作を継続する。

一方、送信スロットの送信が完了し、ＭＡＣフレームの送信動作が完了すると、ステップＳ１２８においてＲＣＨ期間に達したか否かの確認動作を繰り返し、ＲＣＨ期間となると、クライアント端末は新管理端末の生起動作および帯域割当要求動作（詳細は後述）を行う（ステップＳ１２９）。

そして、ＲＣＨ期間が終了したか否かの確認動作を繰り返し（ステップＳ１３０）、ＲＣＨ期間が終了すると、クライアント端末は次のＢＣＨ受信時刻となるまで待機する（ステップ１０２）。

なお、以上説明したステップＳ１０１〜Ｓ１３０の動作は、クライアント端末のＣＰＵ１１が主体となって行う動作である。

＜Ａ−７．新管理端末の生起動作＞
次に、図１３〜図１５を用いてクライアント端末の新管理端末の生起動作および帯域割当要求動作について説明する。なお、図１３における記号（Ａ）〜（Ｃ）と図１４における記号（Ａ）〜（Ｃ）とで、図１３と図１４とが互いに接続され、図１３における記号（Ｄ）と図１５における記号（Ｄ）とで、図１３と図１５とが互いに接続され、図１４における記号（Ｅ）と図１５における記号（Ｅ）とで、図１４と図１５とが互いに接続されている。

図１３に示すように新管理端末の生起動作および帯域割当要求動作を開始すると、ＣＰＵ１１は、ＲＣＨ期間中に各クライアント端末より送信される可能性のある、他クライアント端末からの管理端末通信不良通知（詳細は後述）の受信の有無を管理する（ステップＳ２０１）。

次に、自クライアント端末が前回の送受信動作までに管理端末通信不良通知を送信しているか否かについての確認を行う（ステップＳ２０２）。

すなわち、ステップＳ２０２においては、ＮＥＷ・ＦＬＡＧが１かどうかを確認し、ＮＥＷ・ＦＬＡＧが０の場合、すなわち、前回の送受信動作までに管理端末通信不良通知を送信していない場合は、固定帯域割当に応じた閾値パラメータＮＥＷ・ＢＯＲＤＥＲを設定する（ステップＳ２０３）。なお、ＮＥＷ・ＦＬＡＧが１の場合、すなわち、前回の送受信動作までに管理端末通信不良通知を送信していた場合はステップＳ２２３（図１５）に進む。ここで、管理端末通信不良通知は、自クライアント端末が管理端末よりＢＣＨ、ＦＣＨ等のネットワーク管理情報が一定以上受信できず、現在の管理端末に代わって自クライアント端末が新たな管理端末候補となったことを他クライアント端末に示すものである。

閾値パラメータＮＥＷ・ＢＯＲＤＥＲは、現在の管理端末からＢＣＨ、ＦＣＨ等のネットワーク管理情報が一定以上受信できなかった場合に、新たな管理端末となる候補を設定する基準となる値であり、データ受信中で固定帯域割当されている割合が多いクライアント端末ほど小さな値を設定するように制御することで、新たな管理端末となる候補の順位付けを行うものである。

例えば、固定帯域割当されている割合がクライアント端末Ａ３が５０％、クライアント端末Ｂ５が３０％、クライアント端末Ｃ７が０％であり、クライアント端末Ａ３がデータ送信中、クライアント端末Ｂ５がデータ受信中、クライアント端末Ｃ７がデータ受信中（通常帯域割当にて）である場合、閾値パラメータＮＥＷ・ＢＯＲＤＥＲの値はクライアント端末Ａ３が１００、クライアント端末Ｂ５が２０、クライアント端末Ｃ７が５０などというように設定し、データ受信中で固定帯域割当されている割合が多いクライアント端末ほど新たな管理端末の候補となり易いように基準を低く設定する制御を行う。

次に、ステップＳ２０３において決定した閾値パラメータＮＥＷ・ＢＯＲＤＥＲに基づき、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴと閾値パラメータＮＥＷ・ＢＯＲＤＥＲとの大小関係を判断する（ステップＳ２０４）。

そして、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴの値が閾値パラメータＮＥＷ・ＢＯＲＤＥＲの値以上と判断された場合は、ステップＳ２０６に進んでＮＥＷ・ＦＬＡＧを１に設定し、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴの値が閾値パラメータＮＥＷ・ＢＯＲＤＥＲの値より小さいと判断された場合は、ステップＳ２０５に進む。

ステップＳ２０５では、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴと閾値パラメータＮＥＷ・ＢＯＲＤＥＲとの大小関係を判断し、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴの値が閾値パラメータＮＥＷ・ＢＯＲＤＥＲの値以上と判断された場合は、ステップＳ２０６に進んでＮＥＷ・ＦＬＡＧを１に設定し、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴの値が閾値パラメータＮＥＷ・ＢＯＲＤＥＲの値より小さいと判断された場合は、ステップＳ２０７に進んでＮＥＷ・ＦＬＡＧを０に設定する。

ＮＥＷ・ＦＬＡＧの設定が完了すると、ステップＳ２０１において実施している他クライアント端末からの管理端末通信不良通知の管理結果に基づき、今回のＲＣＨ期間中、他端末から管理端末通信不良通知を受信したか否かの確認を行う（ステップＳ２０８）。

そして、他端末からの管理端末通信不良通知を受信していない場合はステップＳ２０９に進み、自クライアント端末内でのＮＥＷ・ＦＬＡＧが１に設定されているか否かを確認し、ＮＥＷ・ＦＬＡＧが１が設定されている場合は、管理端末通信不良通知を生成する（ステップＳ２１０）。

その後、生成した管理端末不良通知を他クライアント端末に向けて同報通信し（ステップＳ２１１）、ステップＳ２１２（図１４）において新管理端末の生起動作および帯域割当要求動作を終了して待機する。

なお、ステップＳ２０８において、他端末から管理端末通信不良通知を受信したことを確認した場合は、ステップＳ２１９（図１４）に進み、また、ステップＳ２０９において、ＮＥＷ・ＦＬＡＧが１に設定されていないことを確認した場合はステップＳ２１３（図１４）に進む。

ステップＳ２１３では、現在の管理端末に対して自クライアント端末が保有する送信データに応じて固定帯域割当の要求を行うか否かを判断する。そして、固定帯域割当要求を行う場合は、固定帯域割当要求を生成し（ステップＳ２１４）、固定帯域割当要求を送信する（ステップＳ２１５）。なお、固定帯域割当を要求しない場合はステップＳ２１６に進む。

また、同様に通常帯域割当の要求を行うか否かの判断を実施し（ステップＳ２１６）、通常帯域割当要求を行う場合は、通常帯域割当要求を生成し（ステップＳ２１７）、通常帯域割当要求を送信する（ステップＳ２１８）。なお、通常帯域割当を要求しない場合および帯域割当要求が完了した場合は、新管理端末の生起動作および帯域割当要求動作を終了して待機する（ステップＳ２１２）。

また、ステップＳ２０８において、今回のＲＣＨ期間中、他クライアント端末から管理端末通信不良通知を受信したと判断した場合は、管理端末通信不良通知を送信したクライアント端末を新たな管理端末として承認する動作を実施する。

すなわち、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴおよびＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴを０に初期化し（ステップＳ２１９）、ＮＥＷ・ＦＬＡＧを０に設定する（ステップＳ２２０）。

これにより、最先に管理端末通信不良通知を送信したクライアント端末のみが新たな管理端末となることができ、複数の新たな管理端末が生起して混乱することを防止できる。

次に、新管理端末承認通知を生成し（ステップＳ２２１）、管理端末通信不良通知を送信してきたクライアント端末に向けて新管理端末承認通知を送信する（ステップＳ２２２）。上記通知の送信が完了すると、新管理端末の生起動作および帯域割当要求動作を終了して待機する（ステップＳ２１２）。

また、ステップＳ２０２において、前回の送受信動作までに管理端末通信不良通知を送信していたことが確認された場合、すなわち自クライアント端末において前回の送受信動作までに、管理端末通信不良通知の生成および送信（ステップＳ２１０、Ｓ２１１）を実施していた場合は、以下の動作を行う。

すなわち、ステップＳ２０１において実施している他クライアント端末からの管理端末通信不良通知の管理結果に基づき、前回の送受信動作で、ステップＳ２０１〜Ｓ２１１の動作を経て管理端末不良通知を送信してから、他クライアント端末から管理端末通信不良通知を受信したか否かを確認する（ステップＳ２２３）。

そして、他クライアント端末から管理端末通信不良通知を受信していなかった場合、再度、管理端末通信不良通知を生成し（ステップＳ２２４）、生成した管理端末不良通知を他クライアント端末に向けて同報通信する（ステップＳ２２５）。

クライアント端末からの管理端末通信不良通知の送信は、各クライアント端末が帯域割当要求を行うＲＣＨ期間中に実施するため、送信タイミングによっては管理端末通信不良通知と帯域割当要求が衝突し、各クライアント端末に同報通信できない可能性がある。そのため、再度、管理端末通信不良通知を生成し、送信することにより、可能な限り各クライアント端末に新たな管理端末の候補が生起していることを通知する効果を奏する。

管理端末通信不良通知を送信すると、各クライアント端末より新管理端末承認の通知がある（すなわち他クライアント端末はステップＳ２０８およびＳ２１９〜Ｓ２２２の動作を実施する）。そこで、他クライアント端末からの新管理端末承認通知の受信数を管理し（ステップＳ２２６）、ステップＳ２２７では新管理端末承認通知が予め定めた一定数に達したか否かの確認を行う。

そして、新管理端末承認通知が一定数に達した場合は、以下のように新管理端末としての動作を開始する。すなわち、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴおよびＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴを０に初期化し（ステップＳ２２８）、ＮＥＷ・ＦＬＡＧを０に設定し（ステップＳ２２９）、その後、新管理端末として動作を開始する（ステップＳ２３０）。

一方、ステップＳ２２３において、前回、管理端末不良通知を送信してから、他クライアント端末からも管理端末通信不良通知を受信していたことを確認した場合は、予め定めた一定の確率に基づいてＮＥＷ・ＦＬＡＧを０に設定する制御を行う（ステップＳ２３１）。

すなわち、基本的に、管理端末不良通知は複数のクライアント端末から同時に送信されることはない。これはステップＳ２０８にて自クライアント端末が他クライアント端末からの管理端末不良通知を受信した場合、自クライアント端末は管理端末不良通知を送信しないよう制御するからである。しかし、ＲＣＨ期間中の管理端末不良通知の送信タイミング、あるいは管理端末通信不良通知と帯域割当要求との衝突などにより、他クライアント端末が管理端末不良通知を同報通信したにもかかわらず、自クライアント端末でその管理端末不良通知が受信できなかったため、自クライアント端末から管理端末不良通知を同報通信するということが考えられる。

このような場合を想定して、ステップＳ２２３では、新たな管理端末の候補となることを一定の確率で取り下げる動作を行う。この動作を実施することで、管理端末不良通知が複数の端末から送信されている状況において、新たな管理端末が複数生起することを防ぐ効果が得られる。

なお、以上説明したステップＳ２０１〜Ｓ２３１の動作は、クライアント端末のＣＰＵ１１が主体となって行う動作である。

＜Ａ−８．効果＞
以上に説明したように、実施の形態１のデータ送受信装置によれば、クライアント端末間で映像ストリームの送受信中に管理端末がＰＬＣネットワークから離脱するなどしてクライアント端末がＢＣＨ、ＦＣＨ等のネットワーク管理情報を受信できなかった場合でも、データ受信中のクライアント端末が速やかに新たな管理端末として生起し、同期を継承、ネットワークトポロジを回復させることができる。

また、映像ストリームを送信する際に、固定帯域を割り当てるとともに、１フレーム内での固定帯域割当を同じ位置になるようにスケジューリングするので、前回受信したスケジュール情報、および基準時刻情報を基に映像ストリームの送受信をすれば、新たな管理端末が生起するまでの管理端末が不在の期間においても、映像ストリームを中断することなく伝送できる効果がある。

＜Ｂ．実施の形態２＞
以下、本発明に係る実施の形態２のデータ送受信装置について説明する。
実施の形態２のデータ送受信装置では、実施の形態１において説明した新管理端末の生起に関わる動作のみが異なる。

すなわち、実施の形態１では、クライアント端末がＢＣＨ、ＦＣＨ等のネットワーク管理情報を現在の管理端末から受信できなかった場合、新たな管理端末の候補として生起し、基本的には最終的に現在の管理端末と替わって新管理端末として動作を開始する。一方、実施の形態２では、クライアント端末がＢＣＨ、ＦＣＨ等のネットワーク管理情報を現在の管理端末から受信できなかった場合、新たな管理端末の候補として生起するが、他クライアント端末が現在の管理端末よりネットワーク管理情報を受信できている場合は、自らは新たな管理端末の候補となっていることを取り下げる動作を行うことを特徴としている。つまり、１のクライアント端末が現在の管理端末と通信ができなくても、他のクライアント端末が現在の管理端末と通信できている場合は、新たな管理端末を生起しないように制御する。このような制御により、管理端末が頻繁に入れ替わってＰＬＣネットワークの同期通信が不安定化するのを防ぐことができる。

＜Ｂ−１．新管理端末の生起動作＞
次に、図１６〜図１９に示すフローチャートを用いて、クライアント端末の新管理端末の生起動作および帯域割当要求動作について説明する。なお、上述の通り、実施の形態２のデータ送受信装置においては、図１２においてステップＳ１２９として説明した新管理端末の生起動作のみが異なり、その他の動作においては実施の形態１と同様である。また、図１６における記号（Ａ）と図１７における記号（Ａ）とで、図１６と図１７とが互いに接続され、図１７における記号（Ｂ）と図１９における記号（Ｂ）とで、図１７と図１９とが互いに接続され、図１７における記号（Ｃ）〜（Ｅ）と図１８における記号（Ｃ）〜（Ｅ）とで、図１７と図１８とが互いに接続されている。さらに、図１６における記号（Ｆ）と図１９における記号（Ｆ）とで、図１６と図１９とが互いに接続されている。

図１６に示すように新管理端末の生起動作および帯域割当要求動作を開始すると、ＣＰＵ１１は、ＲＣＨ期間中に各クライアント端末より送信される可能性のある、他クライアント端末からの管理端末通信不良通知の受信の有無を管理する（ステップＳ３０１）。

次に、ＲＣＨ期間中に各クライアント端末より送信される可能性のある、他端末からの管理端末正常稼働通知（詳細は後述）の受信の有無を管理する（ステップＳ３０２）。

次に、自クライアント端末が前回の送受信動作までに管理端末通信不良通知を送信しているか否かについての確認を行う（ステップＳ３０３）。

すなわち、ステップＳ３０３においては、ＮＥＷ・ＦＬＡＧが１かどうかを確認し、ＮＥＷ・ＦＬＡＧが０の場合、すなわち、前回の送受信動作までに管理端末通信不良通知を送信していない場合は、固定帯域割当に応じた閾値パラメータＮＥＷ・ＢＯＲＤＥＲを設定する（ステップＳ３０４）。なお、ＮＥＷ・ＦＬＡＧが１の場合、すなわち、前回の送受信動作までに管理端末通信不良通知を送信していた場合はステップＳ３２８（図１９）に進む。

次に、ステップＳ３０４において決定した閾値パラメータＮＥＷ・ＢＯＲＤＥＲに基づき、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴと閾値パラメータＮＥＷ・ＢＯＲＤＥＲとの大小関係を判断する（ステップＳ３０５）。

そして、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴの値が閾値パラメータＮＥＷ・ＢＯＲＤＥＲの値以上と判断された場合は、ステップＳ３０７に進んでＮＥＷ・ＦＬＡＧを１に設定し、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴの値が閾値パラメータＮＥＷ・ＢＯＲＤＥＲの値より小さいと判断された場合は、ステップＳ３０６に進む。

ステップＳ３０６では、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴと閾値パラメータＮＥＷ・ＢＯＲＤＥＲとの大小関係を判断し、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴの値が閾値パラメータＮＥＷ・ＢＯＲＤＥＲの値以上と判断された場合は、ステップＳ３０７に進んでＮＥＷ・ＦＬＡＧを１に設定し、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴの値が閾値パラメータＮＥＷ・ＢＯＲＤＥＲの値より小さいと判断された場合は、ステップＳ３０８に進んでＮＥＷ・ＦＬＡＧを０に設定する。

ＮＥＷ・ＦＬＡＧの設定が完了すると、ステップＳ３０１において実施している他クライアント端末からの管理端末通信不良通知の管理結果に基づき、ステップＳ３０９（図１７）において、今回のＲＣＨ期間中、他クライアント端末から管理端末通信不良通知を受信したか否かの確認を行う。

そして、他端末からの管理端末通信不良通知を受信していない場合はステップＳ３１０に進み、自クライアント端末内でのＮＥＷ・ＦＬＡＧが１に設定されているか否かを確認し、ＮＥＷ・ＦＬＡＧが１が設定されている場合は、管理端末通信不良通知を生成する（ステップＳ３１１）。

その後、生成した管理端末不良通知を他クライアント端末に向けて同報通信し（ステップＳ３１２）、ステップＳ３１３（図１９）において新管理端末の生起動作および帯域割当要求動作を終了して待機する。

なお、ステップＳ３０９において、他端末から管理端末通信不良通知を受信したことを確認した場合は、ステップＳ３２０（図１８）に進み、また、ステップＳ３１０において、ＮＥＷ・ＦＬＡＧが１に設定されていないことを確認した場合はステップＳ３１４に進む。

ステップＳ３１４では、現在の管理端末に対して自クライアント端末が保有する送信データに応じて固定帯域割当の要求を行うか否かを判断する。そして、固定帯域割当要求を行う場合は、固定帯域割当要求を生成し（ステップＳ３１５）、固定帯域割当要求を送信する（ステップＳ３１６）。なお、固定帯域割当を要求しない場合はステップＳ３１７に進む。

また、同様に通常帯域割当の要求を行うか否かの判断を実施し（ステップＳ３１７）、通常帯域割当要求を行う場合は、通常帯域割当要求を生成し（ステップＳ３１８）、通常帯域割当要求を送信する（ステップＳ３１９）。なお、通常帯域割当を要求しない場合および帯域割当要求が完了した場合は、新管理端末の生起動作および帯域割当要求動作を終了して待機する（ステップＳ３１３）。

また、ステップＳ３０９において、今回のＲＣＨ期間中、他クライアント端末から管理端末通信不良通知を受信したと判断した場合は、管理端末通信不良通知を送信したクライアント端末を新たな管理端末として承認するか、あるいは管理端末通信不良通知を送信した端末に現在の管理端末が正常に稼働していることを通知する動作を実施する。

すなわち、ステップＳ３２０（図１８）において、自クライアント端末内のフラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴが０であるか否かを確認し、０である場合は自クライアント端末は現在の管理端末から正常にＢＣＨを受信できているので、その旨を示す管理端末正常稼働通知を生成し（ステップＳ３２１）、それを管理端末通信不良通知を送信してきた端末に対して送信する（ステップＳ３２２）。

一方、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴが０でない場合、ステップＳ３２３において、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴが０であるか否かを確認し、０である場合は自クライアント端末は現在の管理端末から正常にＦＣＨを受信できているので、その旨を示す管理端末正常稼働通知を生成し（ステップＳ３２１）、それを管理端末通信不良通知を送信してきた端末に対して送信する（ステップＳ３２２）。

なお、管理端末正常稼働通知を送信した場合、現在の管理端末は正常に動作しているので、ステップＳ３１４〜Ｓ３１９における帯域割当要求を実施し、新管理端末の生起動作および帯域割当要求動作を終了して待機する（ステップＳ３１３）。

なお、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴが０ではなく、フラグカウンタＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴも０ではない場合は、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴおよびＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴを０に初期化し（ステップＳ３２４）、ＮＥＷ・ＦＬＡＧを０に設定する（ステップＳ３２５）。さらに、新管理端末承認通知を生成し（ステップＳ３２６）、管理端末通信不良通知を送信してきたクライアント端末に向けて新管理端末承認通知を送信する（ステップＳ３２７）。上記通知の送信が完了すると、新管理端末の生起動作および帯域割当要求動作を終了して待機する（ステップＳ３１３）。

ステップＳ３０３（図１６）において、前回の送受信動作までに管理端末通信不良通知を送信していたことが確認された場合の動作について説明する。

すなわち、ステップＳ３０２（図１６）において実施している他クライアント端末からの管理端末正常稼働通知の管理結果に基づき、ステップＳ３２８（図１９）において、前回、管理端末不良通知を送信してから、他クライアント端末から管理端末正常稼働通知を受信したか否かを確認する。

そして、他クライアント端末から管理端末正常稼働通知を受信していなかった場合は、ステップＳ３０１（図１６）において実施している他クライアント端末からの管理端末通信不良通知の管理結果に基づき、前回、管理端末不良通知を送信してから、他クライアント端末から管理端末通信不良通知を受信したか否かを確認する（ステップＳ３２９）。

そして、他クライアント端末から管理端末通信不良通知を受信していなかった場合、再度、管理端末通信不良通知を生成し（ステップＳ３３０）、生成した管理端末不良通知を他クライアント端末に向けて同報通信する（ステップＳ３３１）。

管理端末通信不良通知を送信すると、各クライアント端末より新管理端末承認の通知、あるいは管理端末正常稼働の通知がある（すなわち他クライアント端末はステップＳ３０９〜Ｓ３２６およびＳ３２７の新管理端末承認通知の生成、送信、あるいはステップＳ３０９〜Ｓ３２１およびＳ３２２の管理端末正常稼働通知の生成、送信の動作を実施する）。そこで、他クライアント端末からの新管理端末承認通知の受信数を管理し（ステップＳ３３２）、ステップＳ３３３では新管理端末承認通知が予め定めた一定数に達したか否かの確認を行う。

そして、新管理端末承認通知が一定数に達した場合は、以下のように新管理端末としての動作を開始する。すなわち、フラグカウンタＢＣＨ・ＭＩＳＳ・ＣＯＵＮＴおよびＦＣＨ・ＭＩＳＳ・ＣＯＵＮＴを０に初期化し（ステップＳ３３４）、ＮＥＷ・ＦＬＡＧを０に設定し（ステップＳ３３５）、その後、新管理端末として動作を開始する（ステップＳＳ３３６）。

一方、ステップＳ３２９において、前回、管理端末不良通知を送信してから、他クライアント端末からも管理端末通信不良通知を受信していたことを確認した場合は、予め定めた一定の確率に基づいてＮＥＷ・ＦＬＡＧを０に設定する制御を行い（ステップＳ３３７）、新管理端末の生起動作および帯域割当要求動作を終了して待機する（ステップＳ３１３）。

また、ステップＳ３２８において、前回、管理端末不良通知を送信してから、他端末から管理端末正常稼働通知を受信した場合は、ＮＥＷ・ＦＬＡＧを０に設定し（ステップＳ３３８）、新管理端末の生起動作および帯域割当要求動作を終了して待機する（ステップＳ３１３）。

すなわち、新たな管理端末の候補となっていることを取り下げる動作を行うことで、自クライアント端末が新たな管理端末の候補となっていても、他クライアント端末が現在の管理端末から正常にＢＣＨ、ＦＣＨ等のネットワーク管理情報を受信できている場合は、新管理端末として生起しないように制御することができる。

なお、以上説明したステップＳ３０１〜Ｓ３３８の動作は、クライアント端末のＣＰＵ１１が主体となって行う動作である。

＜Ｂ−２．効果＞
以上に説明したように、実施の形態２のデータ送受信装置によれば、クライアント端末間で映像ストリームの送受信中に管理端末がＰＬＣネットワークから離脱するなどしてクライアント端末がＢＣＨ、ＦＣＨ等のネットワーク管理情報を受信できなかった場合で、新管理端末が生起するような条件となったとしても、現在の管理端末が他クライアント端末により正常に稼働していることが通知されれば、新管理端末として生起しないようにすることで、管理端末が頻繁に入れ替わってＰＬＣネットワークの同期通信が不安定化するのを防ぐことができる。

また、映像ストリームを送信する際、固定帯域を割り当てるとともに、１フレーム内での固定帯域割当を同じ位置になるようにスケジューリングするので、前回受信したスケジュール情報、および基準時刻情報をもとに映像ストリームの送受信をすれば、新たな管理端末が生起するまでの管理端末が不在の期間においても、映像ストリームを中断することなく伝送できる効果がある。

＜Ｃ．変形例＞
以上説明した実施の形態１および２においては、本発明の適用例として高速ＰＬＣ端末に適用する場合について説明したが、本発明の適用はこれに限るものではなく、無線ＬＡＮ、あるいはＵＷＢ（Ultra Wideband）、あるいはＴＤＭＡ方式、あるいは映像ストリームに固定的な帯域を割り当ててデータを送受信する仕組みを有するデータ送受信方式を採用する他の伝送方式にも適用が可能である。

また、固定帯域が割り当てられた受信クライアント端末側での基準時刻補正を、ＭＡＣヘッダに付加された送信クライアント端末側の基準時刻情報を用いて実施したが、これに限るものではなく、各クライアント端末内の基準クロックはほぼ管理端末の基準クロックに同期しているので、基準時刻補正を行わずに固定帯域が割り当てられたタイムスロットを使用してデータの送受信を実施することも可能である。

さらに、管理端末のＰＬＣネットワークからの離脱判定をＢＣＨあるいはＦＣＨを受信できなかった場合について説明したが、これに限るものではなく、ＰＬＣネットワーク内の同期、および帯域を管理する制御フレームの送受信状態によって判断するよう構成すれば同様の効果を得ることができる。また、固定帯域割当に映像ストリームを伝送する場合について説明したが、これに限るものではなく、オーディオ、あるいは音声等に適用しても良い。

本発明に係るデータ送受信装置を適用した高速ＰＬＣネットワークシステムの構成を示す図である。 本発明に係るデータ送受信装置の構成を説明するブロック図である。 本発明に係るデータ送受信装置内のＰＬＣモデム回路の構成を示すブロック図である。 ＰＬＣモデム回路内のＰＬＣ送信制御回路の構成を示すブロック図である。 ＰＬＣモデム回路内のＰＬＣ受信制御回路の構成を示すブロック図である。 高速ＰＬＣを用いたデータ送受信装置にてデータ送受信を行う際の、１フレーム内のデータフォーマットおよびＦＣＨ内のスケジュールデータの構成を示す図である。 実施の形態１に係るデータ送受信装置を管理端末として使用する場合の１フレーム内のデータ送受信動作を説明するフローチャートである。 実施の形態１に係るデータ送受信装置を管理端末として使用する場合の１フレーム内のデータ送受信動作を説明するフローチャートである。 実施の形態１に係るデータ送受信装置を管理端末として使用する場合の１フレーム内のデータ送受信動作を説明するフローチャートである。 実施の形態１に係るデータ送受信装置をクライアント端末として使用する場合の１フレーム内のデータ送受信動作を説明するフローチャートである。 実施の形態１に係るデータ送受信装置をクライアント端末として使用する場合の１フレーム内のデータ送受信動作を説明するフローチャートである。 実施の形態１に係るデータ送受信装置をクライアント端末として使用する場合の１フレーム内のデータ送受信動作を説明するフローチャートである。 実施の形態１に係るデータ送受信装置をクライアント端末として使用する場合の新管理端末生起動作および帯域割当要求動作を説明するフローチャートである。 実施の形態１に係るデータ送受信装置をクライアント端末として使用する場合の新管理端末生起動作および帯域割当要求動作を説明するフローチャートである。 実施の形態１に係るデータ送受信装置をクライアント端末として使用する場合の新管理端末生起動作および帯域割当要求動作を説明するフローチャートである。 実施の形態２に係るデータ送受信装置をクライアント端末として使用する場合の新管理端末生起動作および帯域割当要求動作を説明するフローチャートである。 実施の形態２に係るデータ送受信装置をクライアント端末として使用する場合の新管理端末生起動作および帯域割当要求動作を説明するフローチャートである。 実施の形態２に係るデータ送受信装置をクライアント端末として使用する場合の新管理端末生起動作および帯域割当要求動作を説明するフローチャートである。 実施の形態２に係るデータ送受信装置をクライアント端末として使用する場合の新管理端末生起動作および帯域割当要求動作を説明するフローチャートである。

Claims (3)

1. ネットワークシステムの複数の端末のそれぞれに含まれるデータ送受信装置であって、 前記複数の端末は、他の端末を管理する管理端末と、該管理端末により管理されるクライアント端末を複数含み、前記管理端末より定期的に出力される同期情報、およびスケジュール情報に基づいて前記複数の端末間での映像データおよび制御データの送受信が実行され、
   前記データ送受信装置は、
   前記管理端末より出力される同期情報およびスケジュール情報を検出する制御情報検出部と、
   前記同期情報および前記スケジュール情報が前記管理端末から正常に受信できたか否かの受信状況情報を確認するとともに、前記受信状況情報に基づいて前記管理端末と継続して正常に通信ができているか否かを判断して、受信状況経過情報を生成する制御部と、
   前記制御情報検出部で検出された前記スケジュール情報に基づいてデータの受信タイミングを含むタイミング情報を生成するタイミング生成部とを備え、
   前記制御部は、
   データ受信中で固定帯域割当てされている割合が多い端末ほど小さな値が設定された閾値を有し、
   前記受信状況経過情報により前記管理端末と継続して正常に通信できない回数が前記閾値以上と判断されたときに、管理端末通信不良通知を生成して他のクライアント端末に送信し、前記他のクライアント端末から前記管理端末に代わる新管理端末候補としての承認を得ることで、自機が、前記新管理端末として動作を開始するように制御し、
   前記同期情報および前記スケジュール情報の少なくとも一方が受信できなかった場合、前回までに受信したスケジュール情報に基づいて前記タイミング生成部を制御するとともに、前回までに受信した前記スケジュール情報に基づいて検出したクロックの誤差情報を用いて基準時刻を補正し、
   自機が前記管理端末通信不良通知を出していない場合であって、前記他のクライアント端末から前記管理端末通信不良通知を受信した場合、自機において前記同期情報を受信できなかったときは、前記管理端末通信不良通知の送信元に対して、前記新管理端末として生起することを承認する新管理端末承認通知を送信し、自機において前記同期情報を受信できたときは前記管理端末通信不良通知の送信元に対して、前記新管理端末承認通知を送信せず、前記管理端末が正常に稼働していることを示す管理端末正常稼働通知を生成して、前記管理端末通信不良通知の送信元に送信するものであって、
   前記管理端末通信不良通知の送信元は、他の端末から前記管理端末正常稼働通知を受信した場合は、自機を前記新管理端末として動作を開始しないように制御するデータ送受信装置。
2. 前記制御部は、
   自機が前記管理端末である場合に、前記同期情報を前記クライアント端末から受けることで、前記クライアント端末の何れかが自機に代わって前記新管理端末として生起したものと判断し、非管理端末として動作するように自機を制御する、請求項１記載のデータ送受信装置。
3. 前記制御部は、
   自機が前記他のクライアント端末である場合に、前記同期情報を前記新管理端末から受けることで、前記新管理端末に従った動作を開始し、前記管理端末を非管理端末とみなす、請求項１または請求項２に記載のデータ送受信装置。

Images