<A.実施の形態1>
<A−1.ネットワークシステムの構成>
図1は、本発明の実施の形態1に係るデータ送受信装置を備えた高速PLCネットワークシステムの構成を概略的に示す図である。なお、以下においては、データ送受信装置を端末と呼称する。
図1に示すように、当該高速PLCネットワークシステムは、ネットワーク全体を管理する管理端末1、PLCネットワークシステムに接続されたクライアント端末A3、クライアント端末B5およびクライアント端末B7と、信号ラインともなる電灯線9とを備え、管理端末1、クライアント端末A3、クライアント端末B5およびクライアント端末B7と電灯線9との間は、それぞれ電源コンセント2、4、6および8によって電気的に接続されている。
なお、図1に示された高速PLCネットワークシステムの構成は、本発明のデータ送受信装置が適用できるシステム構成の一例であり、本発明のデータ送受信装置は、他の構成を持つ高速PLCネットワークシステム、無線LANを用いたネットワークシステム、Ethernet(登録商標)を用いたネットワークシステムなどの他のシステムにも適用可能である。また、本発明に係るデータ送受信装置は、TVシステム、DVDレコーダの内部において、Ethernetインターフェイスを介して接続されているものとする。
<A−2.ネットワークシステムの概略動作>
次に、図1を用いて高速PLCネットワーク内での管理端末1の動作を中心として、当該ネットワークシステムの概略動作について説明する。なお、実施の形態1では、MAC(Media Access Control)方式として、従来技術として説明したHiSWANa規格で採用されたTDMA方式を採用した場合を例に説明する。
<A−2−1.管理端末の動作>
管理端末1は、最初にネットワーク全体の時刻同期を管理するために同期情報としてBeacon信号(BCH:Broadcast CHannel)を予め定められた周期で同報通信する。BCH送信後、管理端末1は高速PLCネットワーク内の各クライアント端末のデータ受信およびデータ送信のタイミング情報(FCH:Frame CHannel)を同報通信する。FCH送信後、前フレームで各クライアント端末より出力されるRCH(Random access CHannel)を受信した場合、RCHの送信クライアント端末に対して正常受信したことを通知するACH(Access feedback CHannel)を出力する。
ACH送信後は、FCHにて送信されたスケジュールに基づき管理端末1、クライアント端末A3、クライアント端末B5およびクライアント端末C7は、各クライアント端末間でのデータの送受信を実施する。
また、管理端末1は高速PLCネットワーク内で伝送路上にノイズが発生するなどしてクライアント端末との通信が途切れ、その結果、元はクライアント端末であった端末が新たな管理端末として生起しているのを確認したとき、管理端末からクライアント端末となるよう制御する動作を実施する(詳細は後述)。
<A−2−2.クライアント端末の動作>
次に、クライアント端末の動作について説明する。クライアント端末は、管理端末1より出力されるBCHを受信すると、そのBCHに基づいてクライアント端末内の基準時刻を同期させる。
基準時刻の同期を実施した後、各クライアント端末は管理端末1より出力されるFCHに基づいて、それぞれのデータ送信タイミングおよびデータ受信タイミングを内部に設定し、データの送信および受信準備を開始する。データの送信の場合は、FCHに基づく送信時刻が近づくとPLC送信制御部(詳細は後述)は送信データの生成を開始し、所定のタイミングで電灯線9に送信データを送出する。データの受信の場合は、FCHに基づく受信時刻になるとPLC受信制御部(詳細は後述)が受信データを復調し、誤り検出などのデータ受信動作を実施する。
FCHでのスケジュールに基づくデータの送受信が終了すると、各クライアント端末は送信データを持っている場合はRCHの期間に管理端末1に対して帯域割当要求を出力する。
また、各クライアント端末は、管理端末1との通信状況を監視し、正常に通信ができていなと判断した場合、自クライアント端末のデータ受信状況に基づいて新たな管理端末の候補として生起し、他クライアント端末からの承認により、新たな管理端末として動作を開始する制御を実施する(詳細は後述)。
<A−3.高速PLC端末の構成>
<A−3−1.データ送受信装置の構成>
次に、図2〜図5を用いて高速PLC端末の構成を説明する。
図2は本発明に係るデータ送受信装置を高速PLC端末に適用した場合のデータ送受信装置10の構成を示すブロック図である。
図2に示すように、データ送受信装置10は、CPU(Central Processing Unit)11、Ethernetインターフェイス回路12、ブリッジインターフェイス回路13、ブリッジ用メモリ14、PLCモデム回路15、PLC送信用メモリ16、PLC受信用メモリ17およびCPUバス18を備えている。
ここで、ブリッジインターフェイス回路13は、Ethernetインターフェイス回路12より入力されるEthernetフレームデータ、Ethernetインターフェイス回路12へ出力されるEthernetフレームデータ、PLCモデム回路15へ出力されるEthernetフレームデータ、PLCモデム回路15から入力されるEthernetフレームデータをブリッジする回路である。
また、ブリッジ用メモリ14は、ブリッジインターフェイス回路13に入力されたEthernetフレームが、宛先ごとに振り分けられて記憶するメモリであり、PLC送信用メモリ16は、電灯線9(図1)を介して送出するMACフレームデータを記憶するメモリであり、PLC受信用メモリ17は、電灯線9を介して受信したMACフレームデータを記憶するメモリである。
そして、Ethernetインターフェイス回路12は、入力端子20および出力端子21を介してEthernetフレームデータを、外部からデータ送受信装置10に入力およびデータ送受信装置10から外部に出力する回路であり、PLCモデム回路15は、出力端子22を介して外部にフレームデータを送信し、また入力端子23を介して入力されたPLCフレームを受信する回路である。
一般に、高速PLCネットワークでは、電灯線9(図1)に接続された各端末を論理ポートという概念を用いて、ブリッジインターフェイス回路13において、宛先(図1中の管理端末1、クライアント端末A3、クライアント端末B5およびクライアント端末C7)ごとにデータを振り分けて、ブリッジ用メモリ14内にキューイングする。
具体的にはEthernetインターフェイス回路12より入力されるEthernetフレームデータを、その行き先ごとにブリッジ用メモリ14内に振り分けて記憶する処理である。
<A−3−2.PLCモデム回路の構成>
図3は、図2に示したデータ送受信装置10内のPLCモデム回路15の構成を示すブロック図である。
図3に示すようにPLCモデム回路15は、ブリッジインターフェイス回路13より入力端子30を介して入力されるEthernetデータを複数個連結してPLC用MACフレームデータを生成するPLC送信制御回路40と、電灯線9(図1)を介して受信したPLC用MACフレームデータからEthernetフレームデータを分離して出力端子31を介してブリッジインターフェイス回路13に出力するPLC受信制御回路50とを備えている。また、PLC送信制御回路40は、PLC送信用メモリ16との間で、送信用のMACフレームデータの授受を行い、PLC受信制御回路50は、受信用メモリ17との間で、MACフレームデータの授受を行う。
<A−3−3.PLC送信制御回路の構成>
図4は、図3に示したPLC送信制御回路40の構成を示すブロック図である。
図4に示すようにPLC送信制御回路40は、PLCフレームに付加するMACヘッダを生成するPLCヘッダ生成回路401、ブリッジインターフェイス回路13から入力端子30を介して入力されるEthernetフレームデータを複数個集めて送信データを生成するパケットデータ生成回路402、パケットデータ生成回路402から出力されるデータに暗号化を施す暗号化回路403、後述するPLCネットワーク制御データ生成回路408より出力されるBeaconフレームデータやスケジュールデータ、新たな管理端末の生起に関する情報などと暗号化回路403より出力される暗号化されたデータとの切り換えを行うセレクタ404、セレクタ404より出力されるデータの先頭にPLCヘッダ生成回路401にて生成されたPLC用MACヘッダを付加するヘッダ付加回路405、ヘッダ付加回路405より出力されるデータと、後述するPLC送信用メモリ制御回路409より出力されるデータとの切り換えを行うセレクタ406、後述のPLCネットワーク制御データ生成回路408に基づき、データ送受信装置10よりPLCネットワークへ出力するデータの送出タイミングを生成するPLC送信タイミング生成回路407、PLCネットワーク制御データ生成回路408、PLC送信用メモリ制御回路409および、出力端子22を介して外部に送信するPLCフレームにCRC符号(誤り検出符号)を付加するCRC符号付加回路410を備えている。
ここで、PLCネットワーク制御データ生成回路408は、後述のPLC制御フレームデータ記憶回路505(図5)からの出力によりCPU11が決定したスケジュールデータをもとに、データ送信タイミングをPLC送信タイミング生成回路407へ指示するとともに、CPU11からの情報に基づく自端末の基準時刻情報、前回の受信タイミングで、受信データが正常受信されたか否かを示すACK/NACK情報、送信するデータに付加するシーケンスナンバー、BCH、FCH等の制御チャンネルに付加するBeacon制御データ、管理端末を新たに生起させる制御情報などのデータを生成してセレクタ404に出力する回路である。
また、PLC送信用メモリ制御回路409は、再送制御時に使用する送信フレームを、PLC送信用メモリ16に記憶する際の書き込み制御信号を発生するとともに、再送時にPLC送信用メモリ16内に記憶されているデータを読み出すための読み出し制御信号を発生する回路である。
<A−3−4.PLC受信制御回路の構成>
図5は、図3に示したPLC受信制御回路50の構成を示すブロック図である。
図5に示すようにPLC受信制御回路50は、受信されたPLCフレームよりMACヘッダを分離しその内容を解析するPLCヘッダ解析回路501、受信されたPLCフレームに付加されたCRC情報に基づいて受信PLCフレーム内に発生した誤りを検出するCRC復号回路502、ヘッダ解析回路501より出力される暗号化の施されたデータを復号する暗号復号回路503、PLCフレームに付加されているスケジュール情報などの制御フレーム情報、管理端末を新たに生起させる制御情報などと、Ethernetフレーム情報などを分離するPLC制御フレーム分離回路504、PLC制御フレーム分離回路504により分離されたPLC制御フレーム情報を一時的に記憶するPLC制御フレームデータ記憶回路505、PLC受信用メモリ制御回路506、PLC受信タイミング生成回路507およびPLCネットワーク制御データ解析回路508を備えている。なお、PLCヘッダ解析回路501、暗号復号回路503およびPLC制御フレーム分離回路504は、BCH、FCH等の制御フレーム情報を検出する制御情報検出部を構成している。
ここで、PLC受信用メモリ制御回路506は、PLC制御フレーム分離回路504より出力されるEthernetフレーム情報を、一旦、PLC受信用メモリ17に記憶させるための制御信号を生成するとともに、CRC復号回路502より出力される誤り検出結果に基づいて、PLC受信用メモリ17に記憶されているEthernetフレーム情報の読み出し制御を実施する回路である。
PLC受信タイミング生成回路507は、PLCネットワーク制御データ解析回路508より出力される解析結果に基づき、PLCからのデータ受信タイミングを生成して、ヘッダ解析回路501、CRC復号回路502、暗号復号回路503、PLC制御フレーム分離回路504およびPLC受信用メモリ制御回路506に与える回路である。
また、PLCネットワーク制御データ解析回路508は、PLC制御フレームデータ記憶回路505からの出力に基づいてスケジュールデータを解析し、データ受信タイミングをPLC受信タイミング生成回路507に指示する回路である。
また、PLCネットワーク制御データ解析回路508は管理端末からのBCH、FCHなどの制御情報の受信状況を解析し、BCHあるいはFCHが受信できなかった場合、受信したPLC用MACヘッダに付加された送信端末の時刻情報に基づき、受信端末内の時刻を調整するようにPLC受信タイミング生成回路507に時刻情報を出力すると共に、CPU11に通知する他、管理端末を新たに生起させる制御情報などの受信状況の解析も行う。
<A−4.1フレーム内のデータの送信タイミング>
管理端末1では、PLCネットワーク全体の時刻同期を管理するため、従来の技術としても説明したように、周期的にBCHによりBeacon信号を、またFCHによりスケジュール情報を出力してネットワークを管理する。
図6には、1フレーム内の各種データの送信タイミングを示す。
図6に示すように、1フレームにおいては、BCH、FCHおよびACHの順にネットワーク管理情報を送信した後、データ送受信期間にn個の通信スロットL1〜Lnを送信し、最後にRCHを送信することとなる。
実施の形態1では、BCHなどのPLCネットワーク管理情報は20ms周期で出力されるものとする。よって、管理端末1内のPLC送信制御回路40ではBeaconフレーム、およびスケジュール情報を20msに一度の間隔で生成することになる。
また、実施の形態1では、Beaconフレーム情報としては、Beaconフレームを送出する際の管理端末1の時刻情報をペイロード情報として送出するものとする。
具体的には、Beaconフレーム送出時のPLCネットワーク制御データ生成回路408(図4)内の基準時刻情報を、ペイロード情報としてセレクタ404に出力する。一方、受信側となるクライアント端末では、Beaconフレーム情報を受信すると、内部の受信基準時刻をBeaconフレームに付加された送信側基準時刻に同期させる。管理端末1はBCHの送信に引き続きFCH(スケジュール情報)の送信を実施する。
図6に示すように、FCH内には受信時に受信データの先頭位置、およびクロック位相を検出するためのプリアンブル情報と、プリアンブル情報に続いて送信されるスケジュール情報とが含まれている。そして、スケジュール情報には、データ送受信期間に設けられた通信スロットL1〜Lnにそれぞれ対応させて、送信開始時間、送信時間、どの端末(送信端末)からどの端末(受信端末)へのデータ送信かを示す端末情報、およびデータを送受信する際の送受信関連情報が含まれている。
実施の形態1では、送信端末情報および受信端末情報については、各端末の持つMACアドレス(Media Access Control Address)情報を用いるものとする。なお、MACアドレス情報以外に、例えばそのPLCネットワーク内の論理ポート番号、あるいはネットワーク内でプライベートに定められた識別情報であっても良い。
このように、FCH内のスケジュール情報には通信スロットごとに対応した上記情報が付加されて伝送される。なお、通信スロットについては、映像ストリームの送信を開始するクライアント端末が、管理端末1に対してRCHのタイムスロットを利用し、帯域割当要求を伝送することにより、管理端末1は映像ストリームの送信要求のあった端末に対して通信帯域を割り当てる。その際、管理端末1は、映像ストリームのようにリアルタイム性の要求されるデータに関しては、固定的に帯域を割り当てるようにスケジューリングを実施する。なお、固定的に割り当てられた帯域を、固定帯域、あるいは固定帯域割当と称する。
<A−5.管理端末の動作>
次に、図7〜図9に示すフローチャートを用いてスケジュール情報(FCH)の生成フローを含む管理端末1の動作について説明する。なお、図7における記号(A)と図8における記号(A)とで、図7と図8とが互いに接続されている。また、図8における記号(B)と図9における記号(B)とで、図8と図9とが互いに接続されている。さらに、図9における記号(C)と図7における記号(C)とで、図9と図7とが互いに接続されている。
図7に示すように、管理端末1がデータの送受信を開始すると、管理端末1のCPU11は、は新管理端末が生起しているか否か(他端末からBCHを受信したか否か)についての監視を開始する(ステップS11)。
そして、BCH生成開始タイミングに達したか否かの確認動作を繰り返し(ステップS12)、BCH生成開始タイミングになると管理端末1はPLCネットワークを管理するBCHを生成し(ステップS13)、BCH送信開始タイミングに達したか否かの確認動作を繰り返す(ステップS14)。そして、BCH送信開始タイミングになると、各クライアント端末に向けてBCHを同報通信する(ステップS15)。
上記の動作を終えると、前回までに受信したRCHを解析し(ステップS16)、次の動作でのスケジュール情報(FCH)の生成開始の準備に入る。
そして、FCH生成開始タイミングに達したか否かの確認動作を繰り返し(ステップS17)、FCH生成開始タイミングとなると、管理端末1は固定帯域割当が実施されているクライアント端末があるか否かを確認し(ステップS18)、固定帯域が割り当てられているクライアント端末がある場合は、ステップS19で固定帯域用のタイムスロットを継続して割り当ててステップS20に進む。なお、固定帯域が割り当てられているクライアント端末が存在しない場合は、そのままステップS20に進む。
ステップS20では、前フレームにて固定帯域用タイムスロット割当の解放要求をしているクライアント端末があったか否かを確認し、当該解放要求があった場合は、管理端末1はステップS21で当該要求を出したクライアント端末に対する固定帯域割当を解放してステップS22(図8)に進む。なお、解放要求をしているクライアント端末が存在しない場合は、そのままステップS22に進む。
ステップS22では、管理端末1は前フレームで新たな固定帯域割当要求があったか否か確認する。新たな固定帯域割当要求があった場合は、現在割り当てている固定帯域用のタイムスロットを確認し、1フレーム内の通信スロットの余剰状態から新たな固定帯域を割り当てることができるか否かを確認する(ステップS23)。なお、新たな固定帯域割当要求がなかった場合はステップS26に進む。
そして、新たな固定帯域割当が可能な場合は、新たに固定帯域を要求してきたクライアント端末向けに固定帯域を割り当てる(ステップS24)。一方、新たに固定帯域を割り当てることができなかった場合は、新たに固定帯域を要求してきたクライアント端末向けに固定帯域割当不可通知(ACHに含めて送信される)を生成する(ステップS25)。
次に、管理端末1のCPU11は、制御コマンド用の帯域割当要求が、クライアント端末よりあったか否かを確認する(ステップS26)。そして、制御コマンド用の帯域割当要求があった場合は、ステップS27で制御コマンド用のタイムスロットを割り当ててステップS28に進み、要求がなかった場合は、そのままステップS28に進む。
なお、実施の形態1では映像ストリームなどを伝送する場合、ユーザがリモコンで機器制御を実施する、あるいは著作権管理のために、鍵情報などを交換するなど様々なケースで映像ストリーム以外の制御コマンドがやりとりされることを想定している。従って、新規端末に対してステップS24にて固定帯域を割り当てる場合は、少なくとも1フレーム内に1タイムスロット以上の制御コマンド用の帯域を割り当てられるように帯域を確保した後、新規端末へのタイムスロットを割り当てるものとする。
ステップS28では、管理端末1は各クライアント端末へBCH、FCHを含むPLCネットワーク制御情報などを送信するための管理端末送信用タイムスロットを割り当てる。
次に、管理端末1のCPU11は、前フレームにて固定帯域割当以外の通常の帯域割当(以下、通常帯域割当と表記)の要求があったか否かを確認する(ステップS29)。新たな通常帯域割当要求があった場合は、通常帯域を割り当てることができるか否かを確認する(ステップS30)。なお、新たな通常帯域割当要求がなかった場合はステップS33に進む。
そして、新たに通常帯域割当が可能であった場合は、新たに通常帯域を要求してきたクライアント端末向けに通常帯域を割り当てる(ステップS31)。一方、新たに通常帯域を割り当てることができなかった場合は、新たに通常帯域を要求してきたクライアント端末向けに通常帯域割当不可通知(ACHに含めて送信される)を生成する(ステップS32)。
以上の各タイムスロットの割り当が完了すると、ステップS33では、割り当てを行った管理端末1を含めて、各クライアント端末の上記タイムスロット情報を基にFCHを生成し、管理端末1自身が割り当てたタイムスロットに基づき、FCH送信開始タイミングに達したか否かの確認動作を繰り返し(ステップS34)、FCH送信開始タイミングとなると、図9に示すように各クライアント端末にFCHを送信する(ステップS35)。
そして、ACH送信開始タイミングに達したか否かの確認動作を繰り返し(ステップS36)、ACH送信開始タイミングとなると、管理端末1はタイムスロット割当において生成したACHを各クライアント端末に送信する(ステップS37)。
なお、ステップS33(図8)においてFCHフレームを生成する際、実施の形態1では各クライアント端末に割り当てる固定帯域割当は、フレーム内では基本的に同一位置に割り当てるものとする。これは、以下の理由に基づく。すなわち、固定帯域割当により伝送する映像ストリームのようなデータ(VoIPのような音声データも同様)は、伝送する平均データ伝送レートはほぼ一定である。従って、管理端末1より送信されたFCHフレームを周辺機器ノイズの影響で受信できなかった場合でも、各クライアント端末間の同期が確保されていれば、前回受信したスケジュール情報に基づいて伝送すればデータの送受信を実施することができるからである。また、詳細は後述するがクライアント端末間で映像ストリームを再生中に管理端末1と通信が途切れた場合、各クライアント端末間のクロック同期が確立していれば、前回受信したスケジュール情報を基に映像ストリームを送信すれば、新たな管理端末が生起するまでの間、再生画像を乱すことなく伝送することができるからである。
ACHの各クライアント端末への送信が完了すると、管理端末1および各クライアント端末はスケジュール情報を基にデータの送受信(TCH期間)を実施する(ステップS38)。そして、各クライアント端末からの帯域割当要求を受け付けるためのRCH期間に達したか否かの確認動作を繰り返し(ステップS39)、RCH期間となると、RCHの受信を実施し(ステップS40)、それはRCH期間が終了するまで維持される(ステップS41)。
RCH期間の終了後、管理端末1のCPU11は、ステップS12〜S41の間に、ステップS11(図7)で監視を始めた新管理端末の生起の有無(他クライアント端末からBCHを受信したか否か)を判断し(ステップS42)、新管理端末が生起していないと判断した場合は、次回の送受信においても管理端末として動作し、ステップS11以下の動作を繰り返す。一方、新管理端末が生起していると判断した場合は、次回の送受信においては管理端末としての動作を停止し、クライアント端末としての動作を開始する(ステップS43)。
これにより、新管理端末が生起した後も、現在までの管理端末が管理端末として動作を続けるという状況が防止でき、複数の管理端末が存在して混乱することを防止できる。
また、新管理端末が生起すると、他のクライアント端末は、新管理端末からBCHを受信することで新管理端末の生起を確認し、新管理端末に従った動作を開始し、現在までの管理端末を非管理端末とみなす。
これにより、現在までの管理端末が、管理端末として動作を続けた場合であっても、他のクライアント端末は新管理端末に従うので、仮に、一時的に複数の管理端末が存在しても混乱することがない。
なお、以上説明したステップS11〜S43の動作は、管理端末のCPU11が主体となって行う動作である。
<A−6.クライアント端末の動作>
次に、図10〜図12を用いてクライアント端末のデータ送受信動作について説明する。なお、図10における記号(A)と図11における記号(A)とで、図10と図11とが互いに接続されている。また、図11における記号(B)と図12における記号(B)とで、図11と図12とが互いに接続されている。さらに、図12における記号(C)と図10における記号(C)とで、図12と図10とが互いに接続されている。
図10に示すように、クライアント端末がデータの送受信を開始すると、当該クライアント端末のCPU11は、フラグカウンタBCH・MISS・COUNT、およびFCH・MISS・COUNTを0に初期化する(ステップS101)。
フラグカウンタBCH・MISS・COUNT(詳細は後述)は、管理端末1からのBCHを連続で何回受信できなかったか計数するカウンタであり、フラグカウンタFCH・MISS・COUNT(詳細は後述)は、管理端末1からのFCHを連続で何回受信できなかったかを計数するカウンタである。
なお、これらのカウンタは、図3に示したPLCモデム回路15内のPLC受信制御回路50内に配置され、PLCネットワーク制御データ解析回路508(図5)よりBCH、FCHの受信状況のデータを受け、CPU11によって制御される。
クライアント端末のCPU11は前回までの送受信動作で受信したスケジュール情報に基づき、BCHの受信時刻に達したか否かの確認動作を繰り返し(ステップS102)、BCHの受信時刻となると、管理端末からのBCHの受信の成否を確認する(ステップS103)。
そして、管理端末よりBCHを正常に受信できた場合は、受信したBCHが前回の受信動作における管理端末と同じ端末から送信されたものかどうかを判断する(ステップS104)。クライアント端末はこの判断を行うために、BCHの受信ごとに管理端末の端末情報を記録し、今回の受信動作における管理端末が前回の受信動作における管理端末と同一か否かを判断するのに使用する。
ステップS104において、今回も前回と同じ管理端末からBCHを受信したと判断した場合、今回受信した管理端末(現管理端末)からのBCHを基に自クライアント端末内の基準時刻を同期し(ステップS105)、フラグカウンタBCH・MISS・COUNTを0とする(ステップS106)。
一方、ステップS104において、前回と違う管理端末(新たに生起した管理端末)からBCHを受信したと判断した場合、今回受信した新管理端末からのBCHを基に自クライアント端末内の基準時刻を同期し(ステップS107)、フラグカウンタBCH・MISS・COUNTおよびFCH・MISS・COUNTを0とする(ステップS108)。また、自クライアント端末が新たな管理端末として生起するか否かを示すNEW・FLAGは0とする(ステップS109)。
ここで、NEW・FLAGとは自クライアント端末内で、新たな管理端末となる候補としての動作を実施するか否かの基準となる動作基準フラグであり、これが、例えば1に設定された場合は新たな管理端末となる候補としての動作を実施するものとし、0に設定された場合は新たな管理端末となる候補としての動作は実施しない。
なお、ステップS103において、クライアント端末が管理端末よりのBCHを正常に受信できなかった場合は、BCHを用いた管理端末との基準クロックの同期制御を、前回までに受信したBCHを基に検出した誤差情報を用いて自クライアント端末の基準時刻を補正する(ステップS110)。
これは前回までに受信したBCHで管理端末とクライアント端末間はほぼクロック同期(実際には数ppm以下のクロック周波数誤差が存在)が確立しているため、誤差情報を用いてもBCHが復帰するまでの期間があまり長くなければ、PLCネットワークのクロック同期を確立することができるためである。
これにより、クライアント端末間で映像ストリームの送受信中に管理端末がPLCネットワークから離脱するなどしてクライアント端末がBCH、FCH等のネットワーク管理情報を受信できなかった場合でも同期を継承できネットワークトポロジを回復させることができる。
なお、BCHが正常に受信できなかったので、フラグカウンタBCH・MISS・COUNTを1つインクリメントする(ステップS111)。
次に、CPU11は、FCHの受信時刻に達したか否かの確認動作を繰り返し(ステップS112)、FCHの受信時刻となると、ステップS113(図11)において管理端末からのFCHの受信の成否を確認する。そして、管理端末よりのFCHを正常に受信できた場合は、FCHからスケジュール情報を確認し(ステップS114)、フラグカウンタFCH・MISS・COUNTを0とする(ステップS115)。
なお、ステップS113において管理端末からのFCHが正常に受信できなかった場合は、前回の受信動作で受信したFCHを基にスケジュール情報を確認し(ステップS116)、フラグカウンタFCH・MISS・COUNTを1つインクリメントする(ステップS117)。
ここで、前述の通り、管理端末が各クライアント端末に割り当てる固定帯域割当は、フレーム内では基本的に同一位置に割り当てられているため、FCHが復帰するまでの期間があまり長くなければ、前回受信したFCHに基づいたスケジュール情報による映像ストリームの伝送においても再生画像を乱すことなく実施することができる。
スケジュール情報の確認後は、ステップS118において受信スロットの有無についての確認を行い、受信スロットがある場合は、その受信スロットに合わせた受信時刻情報の生成を行う(ステップS119)。一方、受信スロットがない場合は、図12のステップS123に進む。
そして、受信時刻に達したか否かの確認動作を繰り返し(ステップS120)、受信時刻となるとMACフレームの受信を開始し(ステップS121)、データの受信処理を行う。次に、ステップS122では、受信スロットの受信完了の有無を確認し、受信スロットが複数あり、すべての受信動作が完了していない場合は、ステップS120以下の動作を繰り返し、MACフレームの受信動作を継続する。
一方、受信スロットの受信が完了し、MACフレームの受信動作が完了すると、ステップS123(図12)においてスケジュール情報から送信スロットの有無を確認し、送信スロットがある場合は、その送信スロットに合わせた送信時刻情報の生成を行う(ステップS124)。一方、送信スロットがない場合は、ステップS128に進む。
そして、送信時刻に達したか否かの確認動作を繰り返し(ステップS125)、送信時刻となると、MACフレームの送信を開始し(ステップS126)、データの送信処理を行う。次に、ステップS127では、送信スロットの送信完了の有無を確認し、送信スロットが複数あり、すべての送信動作が完了していない場合は、ステップS125以下の動作を繰り返し、MACフレームの送信動作を継続する。
一方、送信スロットの送信が完了し、MACフレームの送信動作が完了すると、ステップS128においてRCH期間に達したか否かの確認動作を繰り返し、RCH期間となると、クライアント端末は新管理端末の生起動作および帯域割当要求動作(詳細は後述)を行う(ステップS129)。
そして、RCH期間が終了したか否かの確認動作を繰り返し(ステップS130)、RCH期間が終了すると、クライアント端末は次のBCH受信時刻となるまで待機する(ステップ102)。
なお、以上説明したステップS101〜S130の動作は、クライアント端末のCPU11が主体となって行う動作である。
<A−7.新管理端末の生起動作>
次に、図13〜図15を用いてクライアント端末の新管理端末の生起動作および帯域割当要求動作について説明する。なお、図13における記号(A)〜(C)と図14における記号(A)〜(C)とで、図13と図14とが互いに接続され、図13における記号(D)と図15における記号(D)とで、図13と図15とが互いに接続され、図14における記号(E)と図15における記号(E)とで、図14と図15とが互いに接続されている。
図13に示すように新管理端末の生起動作および帯域割当要求動作を開始すると、CPU11は、RCH期間中に各クライアント端末より送信される可能性のある、他クライアント端末からの管理端末通信不良通知(詳細は後述)の受信の有無を管理する(ステップS201)。
次に、自クライアント端末が前回の送受信動作までに管理端末通信不良通知を送信しているか否かについての確認を行う(ステップS202)。
すなわち、ステップS202においては、NEW・FLAGが1かどうかを確認し、NEW・FLAGが0の場合、すなわち、前回の送受信動作までに管理端末通信不良通知を送信していない場合は、固定帯域割当に応じた閾値パラメータNEW・BORDERを設定する(ステップS203)。なお、NEW・FLAGが1の場合、すなわち、前回の送受信動作までに管理端末通信不良通知を送信していた場合はステップS223(図15)に進む。ここで、管理端末通信不良通知は、自クライアント端末が管理端末よりBCH、FCH等のネットワーク管理情報が一定以上受信できず、現在の管理端末に代わって自クライアント端末が新たな管理端末候補となったことを他クライアント端末に示すものである。
閾値パラメータNEW・BORDERは、現在の管理端末からBCH、FCH等のネットワーク管理情報が一定以上受信できなかった場合に、新たな管理端末となる候補を設定する基準となる値であり、データ受信中で固定帯域割当されている割合が多いクライアント端末ほど小さな値を設定するように制御することで、新たな管理端末となる候補の順位付けを行うものである。
例えば、固定帯域割当されている割合がクライアント端末A3が50%、クライアント端末B5が30%、クライアント端末C7が0%であり、クライアント端末A3がデータ送信中、クライアント端末B5がデータ受信中、クライアント端末C7がデータ受信中(通常帯域割当にて)である場合、閾値パラメータNEW・BORDERの値はクライアント端末A3が100、クライアント端末B5が20、クライアント端末C7が50などというように設定し、データ受信中で固定帯域割当されている割合が多いクライアント端末ほど新たな管理端末の候補となり易いように基準を低く設定する制御を行う。
次に、ステップS203において決定した閾値パラメータNEW・BORDERに基づき、フラグカウンタBCH・MISS・COUNTと閾値パラメータNEW・BORDERとの大小関係を判断する(ステップS204)。
そして、フラグカウンタBCH・MISS・COUNTの値が閾値パラメータNEW・BORDERの値以上と判断された場合は、ステップS206に進んでNEW・FLAGを1に設定し、フラグカウンタBCH・MISS・COUNTの値が閾値パラメータNEW・BORDERの値より小さいと判断された場合は、ステップS205に進む。
ステップS205では、フラグカウンタFCH・MISS・COUNTと閾値パラメータNEW・BORDERとの大小関係を判断し、フラグカウンタFCH・MISS・COUNTの値が閾値パラメータNEW・BORDERの値以上と判断された場合は、ステップS206に進んでNEW・FLAGを1に設定し、フラグカウンタFCH・MISS・COUNTの値が閾値パラメータNEW・BORDERの値より小さいと判断された場合は、ステップS207に進んでNEW・FLAGを0に設定する。
NEW・FLAGの設定が完了すると、ステップS201において実施している他クライアント端末からの管理端末通信不良通知の管理結果に基づき、今回のRCH期間中、他端末から管理端末通信不良通知を受信したか否かの確認を行う(ステップS208)。
そして、他端末からの管理端末通信不良通知を受信していない場合はステップS209に進み、自クライアント端末内でのNEW・FLAGが1に設定されているか否かを確認し、NEW・FLAGが1が設定されている場合は、管理端末通信不良通知を生成する(ステップS210)。
その後、生成した管理端末不良通知を他クライアント端末に向けて同報通信し(ステップS211)、ステップS212(図14)において新管理端末の生起動作および帯域割当要求動作を終了して待機する。
なお、ステップS208において、他端末から管理端末通信不良通知を受信したことを確認した場合は、ステップS219(図14)に進み、また、ステップS209において、NEW・FLAGが1に設定されていないことを確認した場合はステップS213(図14)に進む。
ステップS213では、現在の管理端末に対して自クライアント端末が保有する送信データに応じて固定帯域割当の要求を行うか否かを判断する。そして、固定帯域割当要求を行う場合は、固定帯域割当要求を生成し(ステップS214)、固定帯域割当要求を送信する(ステップS215)。なお、固定帯域割当を要求しない場合はステップS216に進む。
また、同様に通常帯域割当の要求を行うか否かの判断を実施し(ステップS216)、通常帯域割当要求を行う場合は、通常帯域割当要求を生成し(ステップS217)、通常帯域割当要求を送信する(ステップS218)。なお、通常帯域割当を要求しない場合および帯域割当要求が完了した場合は、新管理端末の生起動作および帯域割当要求動作を終了して待機する(ステップS212)。
また、ステップS208において、今回のRCH期間中、他クライアント端末から管理端末通信不良通知を受信したと判断した場合は、管理端末通信不良通知を送信したクライアント端末を新たな管理端末として承認する動作を実施する。
すなわち、フラグカウンタBCH・MISS・COUNTおよびFCH・MISS・COUNTを0に初期化し(ステップS219)、NEW・FLAGを0に設定する(ステップS220)。
これにより、最先に管理端末通信不良通知を送信したクライアント端末のみが新たな管理端末となることができ、複数の新たな管理端末が生起して混乱することを防止できる。
次に、新管理端末承認通知を生成し(ステップS221)、管理端末通信不良通知を送信してきたクライアント端末に向けて新管理端末承認通知を送信する(ステップS222)。上記通知の送信が完了すると、新管理端末の生起動作および帯域割当要求動作を終了して待機する(ステップS212)。
また、ステップS202において、前回の送受信動作までに管理端末通信不良通知を送信していたことが確認された場合、すなわち自クライアント端末において前回の送受信動作までに、管理端末通信不良通知の生成および送信(ステップS210、S211)を実施していた場合は、以下の動作を行う。
すなわち、ステップS201において実施している他クライアント端末からの管理端末通信不良通知の管理結果に基づき、前回の送受信動作で、ステップS201〜S211の動作を経て管理端末不良通知を送信してから、他クライアント端末から管理端末通信不良通知を受信したか否かを確認する(ステップS223)。
そして、他クライアント端末から管理端末通信不良通知を受信していなかった場合、再度、管理端末通信不良通知を生成し(ステップS224)、生成した管理端末不良通知を他クライアント端末に向けて同報通信する(ステップS225)。
クライアント端末からの管理端末通信不良通知の送信は、各クライアント端末が帯域割当要求を行うRCH期間中に実施するため、送信タイミングによっては管理端末通信不良通知と帯域割当要求が衝突し、各クライアント端末に同報通信できない可能性がある。そのため、再度、管理端末通信不良通知を生成し、送信することにより、可能な限り各クライアント端末に新たな管理端末の候補が生起していることを通知する効果を奏する。
管理端末通信不良通知を送信すると、各クライアント端末より新管理端末承認の通知がある(すなわち他クライアント端末はステップS208およびS219〜S222の動作を実施する)。そこで、他クライアント端末からの新管理端末承認通知の受信数を管理し(ステップS226)、ステップS227では新管理端末承認通知が予め定めた一定数に達したか否かの確認を行う。
そして、新管理端末承認通知が一定数に達した場合は、以下のように新管理端末としての動作を開始する。すなわち、フラグカウンタBCH・MISS・COUNTおよびFCH・MISS・COUNTを0に初期化し(ステップS228)、NEW・FLAGを0に設定し(ステップS229)、その後、新管理端末として動作を開始する(ステップS230)。
一方、ステップS223において、前回、管理端末不良通知を送信してから、他クライアント端末からも管理端末通信不良通知を受信していたことを確認した場合は、予め定めた一定の確率に基づいてNEW・FLAGを0に設定する制御を行う(ステップS231)。
すなわち、基本的に、管理端末不良通知は複数のクライアント端末から同時に送信されることはない。これはステップS208にて自クライアント端末が他クライアント端末からの管理端末不良通知を受信した場合、自クライアント端末は管理端末不良通知を送信しないよう制御するからである。しかし、RCH期間中の管理端末不良通知の送信タイミング、あるいは管理端末通信不良通知と帯域割当要求との衝突などにより、他クライアント端末が管理端末不良通知を同報通信したにもかかわらず、自クライアント端末でその管理端末不良通知が受信できなかったため、自クライアント端末から管理端末不良通知を同報通信するということが考えられる。
このような場合を想定して、ステップS223では、新たな管理端末の候補となることを一定の確率で取り下げる動作を行う。この動作を実施することで、管理端末不良通知が複数の端末から送信されている状況において、新たな管理端末が複数生起することを防ぐ効果が得られる。
なお、以上説明したステップS201〜S231の動作は、クライアント端末のCPU11が主体となって行う動作である。
<A−8.効果>
以上に説明したように、実施の形態1のデータ送受信装置によれば、クライアント端末間で映像ストリームの送受信中に管理端末がPLCネットワークから離脱するなどしてクライアント端末がBCH、FCH等のネットワーク管理情報を受信できなかった場合でも、データ受信中のクライアント端末が速やかに新たな管理端末として生起し、同期を継承、ネットワークトポロジを回復させることができる。
また、映像ストリームを送信する際に、固定帯域を割り当てるとともに、1フレーム内での固定帯域割当を同じ位置になるようにスケジューリングするので、前回受信したスケジュール情報、および基準時刻情報を基に映像ストリームの送受信をすれば、新たな管理端末が生起するまでの管理端末が不在の期間においても、映像ストリームを中断することなく伝送できる効果がある。
<B.実施の形態2>
以下、本発明に係る実施の形態2のデータ送受信装置について説明する。
実施の形態2のデータ送受信装置では、実施の形態1において説明した新管理端末の生起に関わる動作のみが異なる。
すなわち、実施の形態1では、クライアント端末がBCH、FCH等のネットワーク管理情報を現在の管理端末から受信できなかった場合、新たな管理端末の候補として生起し、基本的には最終的に現在の管理端末と替わって新管理端末として動作を開始する。一方、実施の形態2では、クライアント端末がBCH、FCH等のネットワーク管理情報を現在の管理端末から受信できなかった場合、新たな管理端末の候補として生起するが、他クライアント端末が現在の管理端末よりネットワーク管理情報を受信できている場合は、自らは新たな管理端末の候補となっていることを取り下げる動作を行うことを特徴としている。つまり、1のクライアント端末が現在の管理端末と通信ができなくても、他のクライアント端末が現在の管理端末と通信できている場合は、新たな管理端末を生起しないように制御する。このような制御により、管理端末が頻繁に入れ替わってPLCネットワークの同期通信が不安定化するのを防ぐことができる。
<B−1.新管理端末の生起動作>
次に、図16〜図19に示すフローチャートを用いて、クライアント端末の新管理端末の生起動作および帯域割当要求動作について説明する。なお、上述の通り、実施の形態2のデータ送受信装置においては、図12においてステップS129として説明した新管理端末の生起動作のみが異なり、その他の動作においては実施の形態1と同様である。また、図16における記号(A)と図17における記号(A)とで、図16と図17とが互いに接続され、図17における記号(B)と図19における記号(B)とで、図17と図19とが互いに接続され、図17における記号(C)〜(E)と図18における記号(C)〜(E)とで、図17と図18とが互いに接続されている。さらに、図16における記号(F)と図19における記号(F)とで、図16と図19とが互いに接続されている。
図16に示すように新管理端末の生起動作および帯域割当要求動作を開始すると、CPU11は、RCH期間中に各クライアント端末より送信される可能性のある、他クライアント端末からの管理端末通信不良通知の受信の有無を管理する(ステップS301)。
次に、RCH期間中に各クライアント端末より送信される可能性のある、他端末からの管理端末正常稼働通知(詳細は後述)の受信の有無を管理する(ステップS302)。
次に、自クライアント端末が前回の送受信動作までに管理端末通信不良通知を送信しているか否かについての確認を行う(ステップS303)。
すなわち、ステップS303においては、NEW・FLAGが1かどうかを確認し、NEW・FLAGが0の場合、すなわち、前回の送受信動作までに管理端末通信不良通知を送信していない場合は、固定帯域割当に応じた閾値パラメータNEW・BORDERを設定する(ステップS304)。なお、NEW・FLAGが1の場合、すなわち、前回の送受信動作までに管理端末通信不良通知を送信していた場合はステップS328(図19)に進む。
次に、ステップS304において決定した閾値パラメータNEW・BORDERに基づき、フラグカウンタBCH・MISS・COUNTと閾値パラメータNEW・BORDERとの大小関係を判断する(ステップS305)。
そして、フラグカウンタBCH・MISS・COUNTの値が閾値パラメータNEW・BORDERの値以上と判断された場合は、ステップS307に進んでNEW・FLAGを1に設定し、フラグカウンタBCH・MISS・COUNTの値が閾値パラメータNEW・BORDERの値より小さいと判断された場合は、ステップS306に進む。
ステップS306では、フラグカウンタFCH・MISS・COUNTと閾値パラメータNEW・BORDERとの大小関係を判断し、フラグカウンタFCH・MISS・COUNTの値が閾値パラメータNEW・BORDERの値以上と判断された場合は、ステップS307に進んでNEW・FLAGを1に設定し、フラグカウンタFCH・MISS・COUNTの値が閾値パラメータNEW・BORDERの値より小さいと判断された場合は、ステップS308に進んでNEW・FLAGを0に設定する。
NEW・FLAGの設定が完了すると、ステップS301において実施している他クライアント端末からの管理端末通信不良通知の管理結果に基づき、ステップS309(図17)において、今回のRCH期間中、他クライアント端末から管理端末通信不良通知を受信したか否かの確認を行う。
そして、他端末からの管理端末通信不良通知を受信していない場合はステップS310に進み、自クライアント端末内でのNEW・FLAGが1に設定されているか否かを確認し、NEW・FLAGが1が設定されている場合は、管理端末通信不良通知を生成する(ステップS311)。
その後、生成した管理端末不良通知を他クライアント端末に向けて同報通信し(ステップS312)、ステップS313(図19)において新管理端末の生起動作および帯域割当要求動作を終了して待機する。
なお、ステップS309において、他端末から管理端末通信不良通知を受信したことを確認した場合は、ステップS320(図18)に進み、また、ステップS310において、NEW・FLAGが1に設定されていないことを確認した場合はステップS314に進む。
ステップS314では、現在の管理端末に対して自クライアント端末が保有する送信データに応じて固定帯域割当の要求を行うか否かを判断する。そして、固定帯域割当要求を行う場合は、固定帯域割当要求を生成し(ステップS315)、固定帯域割当要求を送信する(ステップS316)。なお、固定帯域割当を要求しない場合はステップS317に進む。
また、同様に通常帯域割当の要求を行うか否かの判断を実施し(ステップS317)、通常帯域割当要求を行う場合は、通常帯域割当要求を生成し(ステップS318)、通常帯域割当要求を送信する(ステップS319)。なお、通常帯域割当を要求しない場合および帯域割当要求が完了した場合は、新管理端末の生起動作および帯域割当要求動作を終了して待機する(ステップS313)。
また、ステップS309において、今回のRCH期間中、他クライアント端末から管理端末通信不良通知を受信したと判断した場合は、管理端末通信不良通知を送信したクライアント端末を新たな管理端末として承認するか、あるいは管理端末通信不良通知を送信した端末に現在の管理端末が正常に稼働していることを通知する動作を実施する。
すなわち、ステップS320(図18)において、自クライアント端末内のフラグカウンタBCH・MISS・COUNTが0であるか否かを確認し、0である場合は自クライアント端末は現在の管理端末から正常にBCHを受信できているので、その旨を示す管理端末正常稼働通知を生成し(ステップS321)、それを管理端末通信不良通知を送信してきた端末に対して送信する(ステップS322)。
一方、フラグカウンタBCH・MISS・COUNTが0でない場合、ステップS323において、フラグカウンタFCH・MISS・COUNTが0であるか否かを確認し、0である場合は自クライアント端末は現在の管理端末から正常にFCHを受信できているので、その旨を示す管理端末正常稼働通知を生成し(ステップS321)、それを管理端末通信不良通知を送信してきた端末に対して送信する(ステップS322)。
なお、管理端末正常稼働通知を送信した場合、現在の管理端末は正常に動作しているので、ステップS314〜S319における帯域割当要求を実施し、新管理端末の生起動作および帯域割当要求動作を終了して待機する(ステップS313)。
なお、フラグカウンタBCH・MISS・COUNTが0ではなく、フラグカウンタFCH・MISS・COUNTも0ではない場合は、フラグカウンタBCH・MISS・COUNTおよびFCH・MISS・COUNTを0に初期化し(ステップS324)、NEW・FLAGを0に設定する(ステップS325)。さらに、新管理端末承認通知を生成し(ステップS326)、管理端末通信不良通知を送信してきたクライアント端末に向けて新管理端末承認通知を送信する(ステップS327)。上記通知の送信が完了すると、新管理端末の生起動作および帯域割当要求動作を終了して待機する(ステップS313)。
ステップS303(図16)において、前回の送受信動作までに管理端末通信不良通知を送信していたことが確認された場合の動作について説明する。
すなわち、ステップS302(図16)において実施している他クライアント端末からの管理端末正常稼働通知の管理結果に基づき、ステップS328(図19)において、前回、管理端末不良通知を送信してから、他クライアント端末から管理端末正常稼働通知を受信したか否かを確認する。
そして、他クライアント端末から管理端末正常稼働通知を受信していなかった場合は、ステップS301(図16)において実施している他クライアント端末からの管理端末通信不良通知の管理結果に基づき、前回、管理端末不良通知を送信してから、他クライアント端末から管理端末通信不良通知を受信したか否かを確認する(ステップS329)。
そして、他クライアント端末から管理端末通信不良通知を受信していなかった場合、再度、管理端末通信不良通知を生成し(ステップS330)、生成した管理端末不良通知を他クライアント端末に向けて同報通信する(ステップS331)。
管理端末通信不良通知を送信すると、各クライアント端末より新管理端末承認の通知、あるいは管理端末正常稼働の通知がある(すなわち他クライアント端末はステップS309〜S326およびS327の新管理端末承認通知の生成、送信、あるいはステップS309〜S321およびS322の管理端末正常稼働通知の生成、送信の動作を実施する)。そこで、他クライアント端末からの新管理端末承認通知の受信数を管理し(ステップS332)、ステップS333では新管理端末承認通知が予め定めた一定数に達したか否かの確認を行う。
そして、新管理端末承認通知が一定数に達した場合は、以下のように新管理端末としての動作を開始する。すなわち、フラグカウンタBCH・MISS・COUNTおよびFCH・MISS・COUNTを0に初期化し(ステップS334)、NEW・FLAGを0に設定し(ステップS335)、その後、新管理端末として動作を開始する(ステップSS336)。
一方、ステップS329において、前回、管理端末不良通知を送信してから、他クライアント端末からも管理端末通信不良通知を受信していたことを確認した場合は、予め定めた一定の確率に基づいてNEW・FLAGを0に設定する制御を行い(ステップS337)、新管理端末の生起動作および帯域割当要求動作を終了して待機する(ステップS313)。
また、ステップS328において、前回、管理端末不良通知を送信してから、他端末から管理端末正常稼働通知を受信した場合は、NEW・FLAGを0に設定し(ステップS338)、新管理端末の生起動作および帯域割当要求動作を終了して待機する(ステップS313)。
すなわち、新たな管理端末の候補となっていることを取り下げる動作を行うことで、自クライアント端末が新たな管理端末の候補となっていても、他クライアント端末が現在の管理端末から正常にBCH、FCH等のネットワーク管理情報を受信できている場合は、新管理端末として生起しないように制御することができる。
なお、以上説明したステップS301〜S338の動作は、クライアント端末のCPU11が主体となって行う動作である。
<B−2.効果>
以上に説明したように、実施の形態2のデータ送受信装置によれば、クライアント端末間で映像ストリームの送受信中に管理端末がPLCネットワークから離脱するなどしてクライアント端末がBCH、FCH等のネットワーク管理情報を受信できなかった場合で、新管理端末が生起するような条件となったとしても、現在の管理端末が他クライアント端末により正常に稼働していることが通知されれば、新管理端末として生起しないようにすることで、管理端末が頻繁に入れ替わってPLCネットワークの同期通信が不安定化するのを防ぐことができる。
また、映像ストリームを送信する際、固定帯域を割り当てるとともに、1フレーム内での固定帯域割当を同じ位置になるようにスケジューリングするので、前回受信したスケジュール情報、および基準時刻情報をもとに映像ストリームの送受信をすれば、新たな管理端末が生起するまでの管理端末が不在の期間においても、映像ストリームを中断することなく伝送できる効果がある。
<C.変形例>
以上説明した実施の形態1および2においては、本発明の適用例として高速PLC端末に適用する場合について説明したが、本発明の適用はこれに限るものではなく、無線LAN、あるいはUWB(Ultra Wideband)、あるいはTDMA方式、あるいは映像ストリームに固定的な帯域を割り当ててデータを送受信する仕組みを有するデータ送受信方式を採用する他の伝送方式にも適用が可能である。
また、固定帯域が割り当てられた受信クライアント端末側での基準時刻補正を、MACヘッダに付加された送信クライアント端末側の基準時刻情報を用いて実施したが、これに限るものではなく、各クライアント端末内の基準クロックはほぼ管理端末の基準クロックに同期しているので、基準時刻補正を行わずに固定帯域が割り当てられたタイムスロットを使用してデータの送受信を実施することも可能である。
さらに、管理端末のPLCネットワークからの離脱判定をBCHあるいはFCHを受信できなかった場合について説明したが、これに限るものではなく、PLCネットワーク内の同期、および帯域を管理する制御フレームの送受信状態によって判断するよう構成すれば同様の効果を得ることができる。また、固定帯域割当に映像ストリームを伝送する場合について説明したが、これに限るものではなく、オーディオ、あるいは音声等に適用しても良い。