<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(登録商標)を用いたネットワークシステムなどの他のシステムにも適用可能である。
<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は、各クライアント端末間でのデータの送受信を実施する。
FCHでのスケジュールに基づくデータの送受信が終了すると、各クライアント端末は送信データを持っている場合はRCHの期間に管理端末1に対して帯域割り当て要求を出力する。
また、管理端末1は自身がネットワークから離脱する場合に備え、各クライアント端末に、次の管理端末の候補になるものの優先順位の情報を同報通信する。実施の形態1では、上記優先順位はクライアント端末の送受信状況により流動的に設定(詳細は後述)するものとするが、本発明のデータ送受信装置は、優先順位が各クライアント端末に一意的に設定されたネットワークのシステムにも適用できる。
<A−2−2.クライアント端末の動作>
次に、クライアント端末の動作について説明する。クライアント端末は、管理端末1より出力されるBCHを受信すると、そのBCHに基づいてクライアント端末内の基準時刻を同期させる。
基準時刻の同期を実施した後、各クライアント端末は管理端末1より出力されるFCHに基づいて、それぞれのデータ送信タイミングおよびデータ受信タイミングを内部に設定し、データの送信および受信準備を開始する。データの送信の場合は、FCHに基づく送信時刻が近づくとPLC送信制御部(詳細は後述)は送信データの生成を開始し、所定のタイミングで電灯線9に送信データを送出する。データの受信の場合は、FCHに基づく受信時刻になるとPLC受信制御部(詳細は後述)が受信データを復調し、誤り検出などのデータ受信動作を実施する。
また、各クライアント端末は、管理端末1より出力される次の管理端末の候補になる優先順位の情報を受信し、各クライアント端末内に設定する。管理端末1がネットワークより離脱したと判断した場合、上記で設定した優先順位に基づき、自クライアント端末が新たな管理端末になるように動作、あるいは他クライアント端末が新たな管理端末になるのを承認する動作を実施する(詳細は後述)。
本実施の形態1では、管理端末1は居間のTVシステムに内蔵され、クライアント端末Aは寝室のTVシステム3に内蔵され、クライアント端末Bは居間のDVDレコーダ5に内蔵され、クライアント端末Cは居間のDVDレコーダ7に内蔵されている場合を例にとして以下の説明を行う。また、本発明に係るデータ送受信装置は、TVシステム、DVDレコーダの内部において、Ethernetインターフェイスを介して接続されているものとする。
<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内に振り分けて記憶する処理である。実施の形態1で説明する高速PLCを用いたネットワークシステムでは、管理端末1の内蔵されているTVシステムにおいて受信した映像ストリームを、クライアント端末Bの内蔵されているDVDレコーダ5に記録しながら、DVDレコーダ5に記憶されているコンテンツを再生し、管理端末1の内蔵されている居間のTVシステムにて視聴するなど、各端末は複数の端末とデータの授受を実施する。従って、実施の形態1に係るデータ送受信装置10は上記ブリッジインターフェイス回路13を必要とする。
<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、データ送受信装置10よりPLCネットワークへ出力するデータの送出タイミングを生成するPLC送信タイミング生成回路407、PLCネットワーク制御データ生成回路408、PLC送信用メモリ制御回路409および、出力端子22を介して外部に送信するPLCフレームにCRC符号(誤り検出符号)を付加するCRC符号付加回路410を備えている。
ここで、PLCネットワーク制御データ生成回路408は、送信するデータに付加するシーケンスナンバー、自端末の基準時刻情報、前回の受信タイミングで、BCHないしFCHが正常受信されたか否かを示すフラグ情報、前回の受信タイミングで、受信データが正常受信されたか否かを示すACK/NACK情報、BCH、FCH等の制御チャンネルに付加するBeacon制御データ、1フレーム内のスケジュールデータ、および管理端末が正常に動作していないと判断された場合に、新たな管理端末を生起させる制御フレーム情報などを生成して出力する回路である。
また、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ネットワーク制御データ解析回路508は、PLC制御フレームデータ記憶回路505に記憶されたPLC制御フレーム情報を、CPU11(制御部)を介して読み込んで解析し、その結果をPLC受信タイミング生成回路507に出力する回路であり、PLC受信タイミング生成回路507は、PLCネットワーク制御データ解析回路508より出力される解析結果に基づき、PLCからのデータ受信タイミングを生成して、ヘッダ解析回路501、CRC復号回路502、暗号復号回路503、PLC制御フレーム分離回路504およびPLC受信用メモリ制御回路506に与える回路である。
なお、PLCネットワーク制御データ解析回路508では、Beaconフレーム、およびFCHにて送信されるスケジュール情報の受信に失敗した場合、受信したPLC用MACヘッダに付加された送信端末の時刻情報に基づいて、受信端末内の時刻を補正し、それに基づいて受信端末内の時刻を調整する指示をPLC受信タイミング生成回路507に出力するとともに、他のクライアント端末から送信されるBCHまたはFCHが正常受信されたか否かを示すフラグ情報の検出、他のクライアント端末からの通知の検出、および新たな管理端末を生起させる制御フレーム情報の検出なども実施する。
<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に示すフローチャートを用いてスケジュール情報の生成方法について説明する。
データの送受信を開始すると、CPU11(図2)がスケジュール情報の生成開始タイミングであるか否かを確認し(ステップS11)、生成開始タイミングである場合にはステップS12に進み、管理端末は固定帯域割当が実施されているクライアント端末の有無を確認する。
そして、固定帯域割当が実施されているクライアント端末が存在しない場合はステップS14に進み、固定帯域割当が実施されているクライアント端末が存在する場合は、CPU11は、PLCネットワーク制御データ生成回路408(図4)を制御して固定帯域用のタイムスロットを割り当てる(ステップS13)。ただし、当該クライアント端末から前フレームにおいて、固定帯域割り当て用のタイムスロットの解放要求の通知あった場合は、固定帯域割当を実施しない。
固定帯域用のタイムスロットの割り当てが終了すると、管理端末のCPU11は前フレームにおいて、クライアント端末から新規通信用の固定帯域割当要求があったか否かを確認する(ステップS14)。
そして、前フレームにおいて新規固定帯域割当要求がなかった場合はステップS18に進み、新規固定帯域割当要求があった場合は、ステップS15において、現在割り当てている固定帯域用のタイムスロットを確認し、新規要求のあった固定帯域を割り当てることができるか否かを確認する。
新規に固定帯域割当が可能な場合は、CPU11は、PLCネットワーク制御データ生成回路408を制御して新規帯域要求端末に対して固定帯域を割り当て(ステップS16)、固定帯域割当が不可能な場合は、ステップS17において固定帯域割当不可通知をACHデータとして要求のあったクライアント端末に対して出力してステップS18に進む。
次に、ステップS18では、管理端末のCPU11は、前フレームにおいて、クライアント端末から制御コマンド用の帯域割当要求があったか否かを確認する。
そして、前フレームにおいて制御コマンド用の帯域割当要求がなかった場合はステップS20に進み、制御コマンド用の帯域割当要求があった場合は、PLCネットワーク制御データ生成回路408を制御して制御コマンド用のタイムスロットを割り当てる(ステップS19)。
なお、実施の形態1では映像ストリームなどを伝送する場合、ユーザがリモコンで機器制御を実施する、あるいは著作権管理のために、鍵情報などを交換するなど様々なケースで映像ストリーム以外の制御コマンドがやり取りされる。従って、ステップS13において新規端末に対して固定帯域を割り当てる場合は、少なくとも1フレーム内に1タイムスロット以上の制御コマンド用の帯域を割り当てられるように帯域を確保した後、新規端末へのタイムスロットを割り当てるものとする。
制御コマンド用のタイムスロットの割り当てが完了すると、管理端末のCPU11は、PLCネットワーク制御データ生成回路408を制御して、管理端末の送信用のタイムスロットを割り当てる(ステップS20)。
送信用タイムスロットの割り当てが終了すると、管理端末のCPU11は、前フレームにおいて、クライアント端末から固定帯域割当通信以外の新規の帯域割当要求(以下、通常帯域割当と表記)があったか否かを確認する(ステップS21)。
そして、前フレームにおいて新規の通常帯域割当要求がなかった場合はステップS21に進み、新規の通常帯域割当要求があった場合は、帯域を割り当てることができるか否かを確認する(ステップS22)。
新規に通常帯域割当が可能である場合は、当該割り当てを要求するクライアント端末に対して、管理端末のCPU11は、PLCネットワーク制御データ生成回路408を制御して、新規に通常帯域用のタイムスロットを割り当てる(ステップS23)。一方、新規に通常帯域割当が不可能である場合は、ステップS24において通常帯域割当不可通知をACHデータとして要求のあったクライアント端末に対して出力する。
以上説明した各タイムスロットの割り当てが完了すると、管理端末のCPU11は、PLCネットワーク制御データ生成回路408を制御して、管理端末を含む各クライアント端末の各タイムスロット情報に基づいてFCHフレームを生成する(ステップS25)。
なお、ステップS25においてFCHフレームを生成する際、実施の形態1では各クライアント端末に割り当てる固定帯域割当は、フレーム内では基本的に同一のタイムスロットに割り当てられるものとする。これは、以下の理由に基づく。
すなわち、固定帯域割当により伝送する映像ストリームのようなデータ(VoIP:Voice over Internet Protocolのような音声データも同様)は、伝送する平均データ伝送レートはほぼ一定である。従って、管理端末より送信されたFCHフレームを周辺機器ノイズの影響で受信できなかった場合でも、各クライアント端末間の同期が確保されていれば、前回受信したスケジュール情報に基づいて伝送すればデータの送受信を実施することができるからである。また、詳細は後述するが、クライアント端末間で映像ストリームを再生中に管理端末がPLCネットワークより離脱した場合についても、各クライアント端末間のクロック同期が確立していれば、前回のフレーム送信で受信したスケジュール情報に基づいて映像ストリームを送信することで、新たな管理端末が生起するまでの間、再生画像を乱すことなく伝送することができるからである。
図7の説明に戻り、ステップS25にてFCHフレームの生成が終了すると、管理端末のCPU11は、ステップS26において次の管理端末候補の優先順位情報を生成する(詳細は後述)。
優先順位情報の生成の後、管理端末のCPU11は、各クライアント端末に向けて、FCHフレームを送信し(ステップS27)、続いて次の管理端末候補の優先順位情報を送信(ステップS28)した後、ステップS11に戻り、次のスケジュール生成開始タイミングになるまで待機する。
実施の形態1では、現在の管理端末が何らかの事情でネットワークを離脱しても、ステップ26において設定した次の管理端末候補の優先順位情報に基づいて新たな管理端末の生起を実施する。上記優先順位情報は、受信データ用に固定帯域を割り当てられているクライアント端末の順位が上位になるよう設定する。これは以下の理由による。
すなわち、BCHおよびFCHの受信状況のみで管理端末のネットワーク離脱を判断するよう構成した場合、特に住宅内ネットワークにおいては、冷蔵庫などのインバータ機器が動作を始めた際に一時的にデータの受信状態が悪くなり、その影響を受けやすい機器のみがBCHおよびFCHを受信できなくなる場合が想定される。従って、実施の形態1では、固定帯域割当用のタイムスロットを使用してデータを受信するクライアント端末において、管理端末のネットワークからの離脱を判断する。
この場合、BCHおよびFCHの受信に失敗したとしても、上述したように固定帯域として割り当てたタイムスロットに関しては、前回受信したスケジュール情報に基づいてデータの送受信を実施すれば、新たな管理端末が生起するまでの間、再生画像を乱すことなく伝送することができる。
従って、受信端末側では、送信端末側でのBCHおよびFCHの受信情報がMACヘッダに付加されて伝送されてくるため、自クライアント端末以外の情報を用いて管理端末のPLCネットワークからの離脱が判断できるので、管理端末がPLCネットワークから離脱していないにも関わらず、自クライアント端末が新たな管理端末として生起する動作が開始されることを回避する効果がある。
<A−6.優先順位情報の生成方法>
次に、図8に示すフローチャートを用いてステップS26(図7)における優先順位情報の生成方法について説明する。
優先順位情報の生成を開始すると、管理端末のCPU11(図2)は、現在データを受信中のクライアント端末において、受信データ用に固定帯域を割り当てられたクライアント端末があるか否かを確認し(ステップS51)、該当するクライアント端末が存在しない場合はステップS54に進み、該当するクライアント端末が存在する場合には、そのクライアント端末に優先順位の設定がされているか否かを確認する(ステップS52)。
上記該当するクライアント端末に優先順位の設定がなされている場合はステップS54に進み、優先順位の設定がなされていない場合は、ステップS53において、優先順位を設定する(S53)。この場合、固定帯域が割り当てられているデータ受信中のクライアント端末が1つしかない場合は、当該クライアント端末の優先順位を1に設定し、固定帯域が割り当てられているデータ受信中のクライアント端末が複数ある場合は、優先順位が重複しないようランダムにクライアント端末を選択し、順位を設定する。なお、クライアント端末の選択については、ランダム選択の他に、使用帯域割合が多い順に優先順位を設定するなどしても良い。
次の管理端末候補の優先順位の設定が終了すると、ステップS51の処理に戻って、他に受信データ用に固定帯域を割り当てられてデータを受信中のクライアント端末が存在するか否かの確認を行う。
受信データ用に固定帯域が割り当てられていないクライアント端末、すなわち現在データを受信中の通常帯域割当のクライアント端末については、ステップS54において優先順位の設定がされているか否かを確認する(ステップS54)。
上記該当するクライアント端末に優先順位の設定がなされている場合は優先順位情報の生成を終了し、優先順位の設定がなされていない場合は、ステップS55において、該当するクライアント端末に対して優先順位の設定が終了しているか否かを確認する。
そして、該当するクライアント端末に対する優先順位の設定が終了している場合はステップS57に進み、優先順位の設定が終了していない場合は、ステップS56において、現在データ受信中のクライアント端末の優先順位を、ステップS53で設定した順位に続く順位に設定する。なお、ステップS55およびS56の処理は、通常帯域が割り当てられているデータ受信中のクライアント端末が複数ある場合は、その全てについて実行される。この場合、固定帯域が割り当てられている場合と同様に優先順位が重複しないようクライアント端末を選択し、順位を設定する。上記ステップが終了すると、ネットワーク内でデータ受信中の全てのクライアント端末についての優先順位の設定が終了する。
データ受信中のクライアント端末についての優先順位の設定が終了すると、ステップS57において、現在、データ送信中のクライアント端末に対して優先順位の設定が終了しているか否かを確認する。
そして、該当するクライアント端末に対する優先順位の設定が終了している場合はステップS59に進み、優先順位の設定が終了していない場合は、ステップS58において、現在データ送信中のクライアント端末の優先順位を、ステップS56で設定した順位に続く順位に設定する。なお、ステップS57およびS58の処理は、データ送信中のクライアント端末が複数ある場合は、その全てについて実行される。この場合、データ受信中のクライアント端末に優先順位を割り当てる場合と同様に順位が重複しないよう送信端末を選択し、順位を設定する。上記ステップが終了すると、ネットワーク内でデータの受信および送信中の全てのクライアント端末の優先順位の設定が終了する。
ネットワーク内でデータの送信および受信中の全てのクライアント端末についての優先順位の設定が終了した後は、ステップS59において、他のクライアント端末、すなわち現在、データの送受信を行っていないアイドル状態のクライアント端末に対して優先順位の設定が終了しているか否かを確認する。
そして、該当する全てのクライアント端末に対する優先順位の設定が終了している場合は優先順位情報の生成を終了し、優先順位の設定がなされていないアイドル状態のクライアント端末が存在する場合は、ステップS60において、アイドル状態のクライアント端末の優先順位を、ステップS58で設定した順位に続く順位に設定する。なお、ステップS59およびS60の処理は、アイドル状態のクライアント端末が複数ある場合は、その全てについて実行される。この場合、データ送受信中のクライアント端末に優先順位を割り当てる場合と同様に順位が重複しないようアイドル状態のクライアント端末を選択し、順位を設定する。上記ステップが終了すると、ネットワーク内にあるクライアント端末全ての優先順位の設定が終了し、優先順位情報の生成を終了する。
<A−7.クライアント端末の送受信動作>
発明が解決しようとする課題としても説明したが、AV系のネットワークをPLC等を用いて構成した場合、映像ストリームを再生中に、ユーザがPLCネットワークを管理している管理端末の電源をオフする場合がある。本発明においては、このような場合でも、現在再生中の映像ストリームを途切れないように継続するとともに、管理端末を新たに生起させて継承させることを特徴としている。
これを実現するために、映像ストリームを送信するクライアント端末は、管理端末より送信されるBCHおよびFCHが検出できなかった場合でも、前回受信したスケジュール情報に基づいて映像ストリームを送信、あるいは受信用のスロット(固定帯域が割り当てられたタイムスロット)を用いてデータの送受信を実施するように構成されている。
また、クライアント端末内の基準時刻に関しては、前回受信したBCHに基づいて生成したクロック情報で自端末の時刻情報を補正するように構成されている。この構成は、図7を用いて、ステップS25の動作において説明したように、映像ストリームに割り当てられた固定帯域は、フレーム内で同一のタイムスロットに割り当てられるように設定することで実現される。
一方、映像ストリームを受信するクライアント端末では、自端末でのBCHおよびFCHの受信状態に基づいて、受信時のデータ送受信制御を実施する。具体的には、受信側のクライアント端末でも、BCHおよびFCHが正常に受信できなかった場合は、前回受信したFCHに基づいて内部で生成した時刻情報により、受信タイムスロットの位置を推定してデータ受信を実施する。
なお、FCHが受信できなかった場合は、映像ストリームを送信する固定帯域割当に相当するタイムスロットのみデータ受信を実施する。その際、受信側のクライアント端末が、BCHおよびFCHの受信ができず、また、送信側のクライアント端末でもBCHおよびFCHの受信ができていなかった場合は、管理端末がネットワークより離脱した可能性があると判断し、内部の基準時刻を送信側のクライアント端末の時刻情報にあわせるよう制御するとともに、新たな管理端末の生起動作を開始する(詳細は後述)。
また、送信クライアント端末がBCHを受信できなかった場合は、BCHを用いた管理端末との基準クロックの同期制御を、前回までに検出したBCHに基づいて検出した誤差情報を用いて自端末の基準時刻情報を生成する。これは前回までに検出したBCHで、管理端末とクライアント端末間はクロック同期がほぼ確立(実際には数ppm以下のクロック周波数誤差を有する)しているため、誤差情報を用いてもBCHが復帰するまでの期間があまり長くなければPLCネットワークのクロック同期を確立することができるためである。一方、BCHが受信できている場合は、受信したBCHに基づいてクロック周波数の誤差を検出してクロック同期を取り、同期の取れたクロックを使用して内部基準時刻を生成する。
以上概略的に説明したクライアント端末の送受信動作について、以下、図9〜図12に示すフローチャートを用いて、さらに説明する。
なお、実施の形態1においては、送信クライアント端末の送信時刻情報およびFCHを管理端末より正常に受信できたか否かを示すフラグ情報をMACフレームに付加して送信することを特徴とする。
TDMAをベースとするMAC方式では、BCHにより管理端末と各クライアント端末間の時刻同期を確立する。BCHにより時刻同期が確立すると、その基準時刻に基づいて管理端末と各クライアント端末間のMACフレームデータの送受信を実施する。
まず、図9に示すように、クライアント端末での送受信動作を開始すると、クライアント端末のCPU11(図2)は、現在がBCHの受信時刻であるか否かを確認する(ステップS101)。
そして、BCHの受信時刻に達していない場合は、ステップS101の確認処理を繰り返し、BCHの受信時刻に達している場合は、ステップS102において、BCHが受信できたか否かを確認する。
BCHが正常に受信できれば、自クライアント端末内の時刻をBCHに合わせて同期させ(S103)、また、BCHが正常に受信できた旨のOKフラグをセットする(ステップS104)。
一方、BCHが正常に受信できなかった場合は、ステップS105において、前回受信したBCHに基づいて生成したクロック情報で自端末の時刻情報を補正し、BCHが正常に受信できなかった旨のNGフラグをセットする(ステップS106)。なお、OKフラグおよびNGフラグについてはCPU11内において管理される。
次に、CPU11は、現在がFCHの受信時刻であるか否かを確認する(ステップS107)。
そして、FCHの受信時刻に達していない場合は、ステップS107の確認処理を繰り返し、FCHの受信時刻に達している場合は、ステップS108において、FCHが受信できたか否かを確認する。
FCHが正常に受信できれば、その検出結果に基づいてに自クライアント端末のスケジュール情報を確認し(ステップS109)、また、FCHが正常に受信できた旨のOKフラグをセットする(ステップS110)。
一方、FCHが受信できなかった場合は、ステップS111において、前回受信したスケジュール情報に基づいて、固定帯域が割り当てられたタイムスロットのみ、データの送受信を実施するよう自クライアント端末内のスケジュール設定を行い、FCHが正常に受信できなかった旨のNGフラグをセットする(ステップS112)。
また、BCHのNGフラグのセット状況を確認し(ステップS113)、BCHのNGフラグはセットされていない場合は、図10におけるステップS115に進み、BCHのNGフラグもセットされていた場合、すなわちBCHおよびFCHの両方のNGフラグがセットされていた場合、CPU11内に設けられた管理端末のネットワーク離脱回数計測カウンタ(以下、LEAVE NUMと表記)を1カウント分インクリメントする(ステップS114)。LEAVE NUMは、管理端末がネットワークから離脱したかどうかをクライアント端末が認識するための指標とする(詳細は後述)。なお、LEAVE NUMは、CPU11内で管理される。
FCHの受信確認が終了した後の動作については、図10に示すフローチャートを用いて説明する。なお、図9における記号(A)と図10における記号(A)とで、図9と図10とが互いに接続されている。また、図10における記号(B)と図11における記号(B)とで、図10と図11とが互いに接続されている。さらに、図9における記号(C)と図11における記号(C)とで、図9と図11とが互いに接続されている。
CPU11は、図10に示すステップS115において、FCHが正常に受信できた場合は、FCHのスケジュール情報に受信スロットがあるか否か、FCHが正常に受信できなかった場合は前回受信したスケジュール情報で固定帯域が割り当てられた受信スロットがあるか否かの確認を行う(ステップS115)。
そして、何れの受信スロットもない場合は、図11に示す送信スロットの確認処理に進み、何れかの受信スロットがある場合は、現在がMACフレームの受信時刻であるか否かを確認する(ステップS116)。
MACフレームの受信時刻に達していない場合は、ステップS116の確認処理を繰り返し、MACフレームの受信時刻に達している場合は、MACフレームの受信を開始して(ステップS117)、データの受信処理を行う。
続いて、CPU11は、ステップS118において、自クライアント端末でBCHのOKフラグまたはFCHのOKフラグがセットされているか否かを確認し、どちらかがセットされている場合は、管理端末は正常に動作しているものと判断し、LEAVE NUMの値を0にリセットする(ステップS121)。
一方、自クライアント端末でBCHのOKフラグ、FCHのOKフラグの何れもセットされていない場合(すなわち、自クライアント端末でBCHのNGフラグおよびFCHのNGフラグをセットした場合)は、ステップS119において、送信側のクライアント端末から、BCHのOKフラグを受信したか否かを確認する(ステップS119)。
そして、送信側のクライアント端末からのBCHのOKフラグの受信を確認した場合、すなわち、送信側のクライアント端末ではBCHのOKフラグがセットされている場合は、自クライアント端末は伝送路のノイズ状況などの一時的な要因により管理端末からBCHまたはFCHが受信できなかったものの、管理端末は正常に動作しているものと判断して、LEAVE NUMの値を0にリセットする(ステップS121)。
一方、送信側のクライアント端末からのBCHのOKフラグの受信を確認できない場合は、ステップS120において、送信側のクライアント端末から、FCHのOKフラグを受信したか否かを確認する。
そして、送信側のクライアント端末からのFCHのOKフラグの受信を確認した場合、すなわち、送信側のクライアント端末ではFCHのOKフラグがセットされている場合は、BCHのOKフラグを確認した場合と同様の論理により、管理端末は正常に動作しているものと判断し、LEAVE NUMの値を0にリセットする(S121)。
一方、送信側のクライアント端末からのFCHのOKフラグの受信を確認できない場合は、ステップS122において、送信側のクライアント端末から、BCHおよびFCHのNGフラグを受信を確認したか否かを確認する。
そして、送信側のクライアント端末からのBCHおよびFCHのNGフラグの受信を確認した場合、すなわち、送信側のクライアント端末でもBCHおよびFCHのNGフラグがセットされている場合は、ステップS123において、LEAVE NUMを1カウント分インクリメントする。
一方、送信側のクライアント端末からのBCHおよびFCHのNGフラグの受信を確認できない場合は、送信側のクライアント端末からのBCHのOKフラグおよびNGフラグ、FCHのOKフラグおよびNGフラグの何れも正常に受信できなかったものと判断し、自クライアント端末と送信側のクライアント端末との通信に支障が発生しているものとして、自クライアント端末でのLEAVE NUMのリセット動作を行わず、ステップS126に進む。
なお、ステップS123でLEAVE NUMをインクリメントした後、ステップS124において、LEAVE NUMの値が、予め定めた所定の値より大きくなったか否か、すなわちカウント回数が所定回数より大きくなったか否かを確認する。
そして、LEAVE NUMのカウント回数が所定回数より大きくなったことを確認した場合には、自クライアント端末においても、また他の送信クライアント端末においても管理端末からのBCHおよびFCHが受信できなくなっているものと判断し、管理端末がネットワークより離脱したものと判断して、次の管理端末を生起するフラグ(以下、NEW FLAGと表記)を1にセット(ステップS125)する。
なお、LEAVE NUMのカウント回数が所定回数より大きくなっていない場合、およびNEW FLAGを1にセットした後はステップS126に進む。
CPU11は、ステップS126において、全ての受信スロットについて、ステップS116〜S125の処理を施したか否かを確認し、全ての受信スロットについての処理が完了している場合は図11に示す送信スロットの確認処理に進み、処理が完了していないスロットがある場合は、ステップS116以下の処理を繰り返す。
全ての受信スロットについての処理が完了した場合、あるいは受信スロットが存在しない場合は、CPU11は、図11に示すステップS127において送信スロットがあるか否かの確認を行う。すなわち、FCHが正常に受信できた場合はそのFCH中のスケジュール情報に送信スロットがあるか否か、FCHが正常に受信できなかった場合は前回受信したFCH中のスケジュール情報で固定帯域が割り当てられた送信スロットがあるかの否かの確認を実施する。
そして、何れの送信スロットもない場合はステップS133に進み、何れかの送信スロットがある場合は、CPU11は、PLCネットワーク制御データ生成回路408を制御して、送信するMACフレームデータを生成し、受信側のクライアント端末が管理端末からのBCH、FCHを正常に受信できていない場合に基準時刻の補正に用いる送信時刻情報を生成する(ステップS128)。また、自クライアント端末でのBCHのOKフラグまたはNGフラグのセット状況、およびFCHのOKフラグまたはNGフラグのセット状況を、送信するMACフレームデータに付加する(ステップS129)。
その後、現在がMACフレームの送信時刻であるか否かを確認し(ステップ130)、送信時刻に達していれば、MACフレームの送信を開始し(ステップS131)、MACフレームの送信時刻に達していない場合は、ステップS130の確認処理を繰り返す。
次に、CPU11は、全ての送信スロットについてステップS128〜S131の処理を施したか否かを確認し(ステップS132)、処理が完了していないスロットがある場合は、ステップS128以下の処理を繰り返し、全ての送信スロットについての処理が完了している場合は、管理端末に対して帯域割当の要求を行うかどうかの判断を実施する(ステップS133)。
そして、帯域割当要求を行わない場合はステップS138に進み、帯域割当要求を行う場合は、ステップS134において、管理端末の動作が正常であるかどうかの確認を実施する。この判断は、自クライアント端末でBCHおよびFCHのNGフラグをセットしたか否かによって行う。具体的には、BCHおよびFCHのNGフラグをセットしていない場合、すなわち、図9に示したステップS102またはS108において、BCHまたはFCHを正常に受信できたと判断し、ステップS104またはS110で、BCHのOKフラグまたはFCHのOKフラグをセットした場合は、管理端末は正常に動作していると判断する。その場合は、CPU11は、PLCネットワーク制御データ生成回路408を制御して帯域割当要求のRCHを送信する(ステップS135)。
一方、自クライアント端末でBCHおよびFCHのNGフラグをセットした場合は、送信側のクライアント端末からの受信スロットがあるか否かの確認を行う(ステップS136)。
そして、受信スロットが存在しない場合は、自クライアント端末のみでしか管理端末の動作状況を確認できないのでRCHの送信を行わないものとし、ステップS138に進む。一方、受信スロットが存在する場合は、送信側のクライアント端末からBCHまたはFCHのOKフラグを受信したかどうかの確認を行う(ステップS137)。
そして、送信側のクライアント端末からBCHまたはFCHのOKフラグを受信できていればRCHを送信し(ステップS135)、何れも受信できなかった場合は管理端末が正常に動作していない可能性が高いと判断し、RCHの送信を行わないものとし、ステップS138に進む。
管理端末に対して帯域割当の要求を行わない場合、ステップS138においてLEAVE NUMの値が0を越えるか否か、すなわち1以上であるか否かの確認を行う。LEAVE NUMの値が1以上の場合、管理端末が正常に動作していない可能性があるため、ステップS139において、新たな管理端末の生起の確認を実施する(詳細は後述)。新たな管理端末の生起の確認を実施後、またはLEAVE NUMの値が0である場合は、1つのMACフレームについてのデータ送受信は完了し、新たなMACフレームのデータ送受信のために図9に示すステップS101に戻る。
<A−8.新たな管理端末の生起の確認処理>
実施の形態1では、管理端末がネットワークから離脱した場合、新たな管理端末を生起させて継承させることを特徴の1つとしている。また、新たな管理端末は、固定帯域割当によってデータを受信中のクライアント端末が優先して生起されるように設定されている。
以下、図12に示すフローチャートを用いて、ステップS139(図11)における新たな管理端末の生起の確認処理について説明する。
新たな管理端末の生起の確認処理を開始すると、クライアント端末のCPU11(図2)は、自クライアント端末が新たな管理端末候補としての順位が1位に設定されているか否かを確認する(ステップS151)。
そして、新たな管理端末候補としての順位が1位ではない場合はステップS158に進み、順位が1位であった場合は、NEW FLAGが1にセットされているか否かを確認し(ステップS152)、NEW FLAGが1にセットされていない場合は、次の新たな管理端末の生起確認開始タイミングまで待機する(ステップS166)。
一方、NEW FLAGが1にセットされている場合は、CPU11は、PLCネットワーク制御データ生成回路408を制御して、自クライアント端末が新たな管理端末候補となったことを他のクライアント端末に通知する(ステップS153)。なお、当該通知は自クライアント端末内での基準時刻情報に基づいて、前の管理端末が正常に動作していたときにスケジュールされていた、例えばACHのタイミングなどで同報通信を実施すれば良い。
他のクライアント端末への通知が完了すると、ステップS154において、PLCネットワーク制御データ解析回路508において、他のクライアント端末から送信される新たな管理端末を承認するか否かの通知を検出し、新たな管理端末を承認する旨の通知を受信したか否かを確認し(ステップS154)、通知を確認できない場合は確認できるまで待機する。
なお、他のクライアント端末から新たな管理端末候補に対する承認通知は、前の管理端末が正常に動作していたときにスケジュールされていた、例えばRCHのタイミングなどで実施すれば良い。また、他の全クライアント端末からの承認が必要か、または一部のクライアント端末からの承認だけで良いかなどは適宜設定すれば良い。
他のクライアント端末からの承認の通知を受信すると、NEW FLAGを0にリセットし(ステップS155)、また、LEAVE NUMを0にリセットして(ステップS156)、新たな管理端末としてBCHおよびFCHの送信等の動作を開始する(ステップS157)。
一方、ステップS151において、自クライアント端末の新たな管理端末候補としての順位が1位ではないと確認された場合は、ステップS158において、他のクライアント端末から新たな管理端末候補となったことの通知を受信したか否かを確認し、受信を確認できない場合はステップS163に進み、通知を受信した場合は、上記新たな管理端末候補に新たな管理端末を承認する旨の通知を送信する(ステップS159)。
その後、NEW FLAGを0にリセットし(ステップS160)、また、LEAVE NUMを0にリセットして(ステップS161)、新たな管理端末のもとで動作を開始する(ステップS16)。
一方、ステップS158において通知を確認できなかった場合は、ステップS163においてNEW FLAGのセット状況を確認する。
そして、NEW FLAGが1にセットされていない場合は、次の新たな管理端末の生起確認開始タイミングまで待機し(ステップS166)、NEW FLAGが1にセットされている場合は、ステップS164において、他のクライアント端末から新たな管理端末候補となったことの通知がなかったか否かの確認を所定の期間続ける。
このステップS164の処理において所定の期間待機することで、他のクライアント端末での新たな管理端末生起の動向をうかがい、新たな管理端末候補の優先順位が高いクライアント端末が、例えば電源をオフされたなどの理由により新たな管理端末として生起できない場合は、自クライアント端末の新たな管理端末候補の優先順位を1ランク繰り上げるものとする(ステップS165)。その後、次の新たな管理端末の生起確認開始タイミングまで待機する(ステップS166)。
<A−9.効果>
以上説明した実施の形態1のデータ送受信装置10を用いることで、クライアント端末間で映像ストリームの送受信中に管理端末がPLCネットワークから離脱した場合でも、データ受信中のクライアント端末が同期を継承し、新たな管理端末として生起して、ネットワークトポロジを回復させることができる。
また、BCHおよびFCHともに受信できなかった場合に管理端末がPLCネットワークから離脱したものと判断するので、管理端末の離脱を正確に判断することができる。
また、映像ストリームを送信する際、固定帯域を割り当てるとともに、1フレーム内での固定帯域割当を同じ位置になるようにスケジューリングするので、前回受信したスケジュール情報、および基準時刻情報に基づいて映像ストリームの送受信をすれば、新たな管理端末が生起するまでの管理端末が不在の期間においても、映像ストリームを中断することなく伝送できる効果がある。
<B.実施の形態2>
<B−1.動作>
以下、本発明に係る実施の形態2のデータ送受信装置の動作について説明する。なお、データ送受信装置の構成は図2に示したデータ送受信装置10を前提とする。
実施の形態2のデータ送受信装置においては、実施の形態1と比べて、管理端末がPLCネットワークから離脱したか否かを検出する検出方法のみが異なり、管理端末がPLCネットワークから離脱したことをより迅速に判断できるため、各クライアント端末の管理端末からのBCHおよびFCHの受信状況情報を各クライアント端末より同報通信するように構成している。
この構成により、一時的に伝送路の通信状態が悪くなり、その影響を受けたクライアント端末が、管理端末からのBCHおよびFCHを正常に受信できなかった場合でも、PLCネットワークを構成している全てのクライアント端末の管理端末からのBCH、FCHの受信状況情報を得られるので、管理端末のPLCネットワークからの離脱の判断を確実に実施することができる。
以下、図13および図14を用いて、クライアント端末における管理端末のネットワークからの離脱の判断動作、および、BCHおよびFCHの受信状況情報の同報通信の動作について説明する。
なお、本実施の形態2では、同報通信チャンネルとして、管理端末に対してアソシエーション、認証、帯域割当などを要求するRCHチャンネルを用いてBCH、FCHの受信状態を同報通信する場合について説明する。また、クライアント端末の管理端末からのBCHおよびFCHの受信、フラグセット状況などの動作フローは、実施の形態1において図9を用いて説明したフローと同様であり、図13は、図9に続くフローとして示し、図9における記号(A)と図13における記号(A)とで、図9と図13とが互いに接続されている。また、図13における記号(D)と図14における記号(D)とで、図13と図14とが互いに接続されている。さらに、図9における記号(E)と図14における記号(E)とで、図9と図14とが互いに接続されている。
図9を用いて説明した処理を経て、管理端末からのBCHおよびFCHの受信処理等が終了すると、CPU11は、図13に示すステップS201において、FCHが正常に受信できた場合は、FCHのスケジュール情報に受信スロットがあるか否か、FCHが正常に受信できなかった場合は前回受信したスケジュール情報で固定帯域が割り当てられた受信スロットがあるか否かの確認を行う。
そして、何れの受信スロットもない場合は、ステップS205に進み、何れかの受信スロットがある場合は、現在がMACフレームの受信時刻であるか否かを確認する(ステップS202)。
MACフレームの受信時刻に達していない場合は、ステップS202の確認処理を繰り返し、MACフレームの受信時刻に達している場合は、MACフレームの受信を開始して(ステップS203)、データの受信処理を行う。
CPU11は、ステップS204において、全ての受信スロットについて、ステップS202、S203の処理を施したか否かを確認し、全ての受信スロットについての処理が完了している場合はステップS205に進み、処理が完了していないスロットがある場合は、ステップS202、S203の処理を繰り返す。
続いて、CPU11は、ステップS205において送信スロットがあるか否かの確認を行う。すなわち、FCHが正常に受信できた場合はそのFCH中のスケジュール情報に送信スロットがあるか否か、FCHが正常に受信できなかった場合は前回受信したFCH中のスケジュール情報で固定帯域が割り当てられた送信スロットがあるかの否かの確認を実施する。
そして、何れの送信スロットもない場合はステップS210に進み、何れかの送信スロットがある場合は、CPU11は、PLCネットワーク制御データ生成回路408を制御して、送信するMACフレームデータを生成し、受信側のクライアント端末が管理端末からのBCH、FCHを正常に受信できていない場合に基準時刻の補正に用いる送信時刻情報を生成する(ステップS206)。
その後、現在がMACフレームの送信時刻であるか否かを確認し(ステップ207)、送信時刻に達していれば、MACフレームの送信を開始し(ステップS208)、MACフレームの送信時刻に達していない場合は、ステップS207の確認処理を繰り返す。
次に、CPU11は、全ての送信スロットについてステップS206〜S208の処理を施したか否かを確認し(ステップS209)、処理が完了していないスロットがある場合は、ステップS206以下の処理を繰り返し、全ての送信スロットについて処理が完了している場合は、ステップS210において、自クライアント端末での管理端末からのBCHおよびFCHの受信フラグのセット状況を確認する。そして、自クライアント端末において、管理端末からのBCHおよびFCHを受信しておらず、BCHおよびFCHのNGフラグをセットしている場合には図14に示すステップS212に進む。一方、BCHおよびFCHのNGフラグをセットしている場合には、管理端末に対しての帯域割当要求通知であるRCHを送信する(ステップS211)。
すなわち、自クライアント端末にてBCHのNGフラグおよびFCHのNGフラグをセットした場合は、管理端末はネットワークから離脱した可能性があるとしてRCHの送信を実施しないが、BCHのOKフラグまたはFCHのOKフラグをセットした場合は、CPU11は、PLCネットワーク制御データ生成回路408を制御してRCHの送信を実施する。
RCHを送信した後、CPU11は、ステップS212において、現在が、各クライアント端末において、管理端末からのBCHおよびFCHの受信状況を示すフラグセット情報の送受信時間であるか否かを確認する。
そして、フラグセット情報の送受信時間でない場合は、ステップS212の確認処理を繰り返し、フラグセット情報の送受信時間である場合は、ステップS213において、他のクライアント端末からのフラグセット情報を受信し、収集を開始する。
また、ステップS214において、自クライアント端末のフラグセット情報の送信タイミングに達したか否かを確認し、フラグセット情報の送信タイミングに達していない場合は、ステップS214の確認処理を繰り返し、フラグセット情報の送信タイミングに達している場合は、PLCネットワーク制御データ生成回路408を制御して、自クライアント端末のフラグセット情報(BCHおよびFCHの受信状況)を他のクライアント端末に対して同報送信する(ステップS215)。
また、CPU11は、ステップS216において、現在が、各クライアント端末において、管理端末からのBCHおよびFCHの受信状況を示すフラグセット情報の送受信時間であるか否かを確認する。
そして、フラグセット情報の送受信時間である場合は、ステップS216の確認処理を繰り返し、フラグセット情報の送受信時間でない場合は、ステップS217において、他のクライアント端末からのフラグセット情報の受信および収集を終了する。
なお、上記管理端末に向けたRCHの送信、および各クライアント端末間での管理端末からのBCHおよびFCHのフラグセット情報の送受信は、各クライアント端末の送信タイミングが重複しないように制御する。すなわち、クライアント端末どうしが同タイミングでデータを送信した場合、データが衝突して管理端末またはクライアント端末はデータの受信が不可能となるので、送信タイミングをずらして衝突を回避するように制御する。具体的には、各クライアント端末がランダムに送信タイミングを自クライアント端末内で発生させる。または、予め各クライアント端末での上記データの送信順位を設定しておき、データの衝突を回避するように制御しても良い。
CPU11は、ステップS217に続いて、自クライアント端末でBCHのOKフラグまたはFCHのOKフラグがセットされているか否かを確認し、どちらかがセットされている場合は、管理端末は正常に動作しているものと判断し、LEAVE NUMの値を0にリセットする(ステップS219)。
一方、自クライアント端末でBCHのOKフラグ、FCHのOKフラグの何れもセットされていない場合(すなわち、自クライアント端末でBCHのNGフラグおよびFCHのNGフラグをセットした場合)は、ステップS220において、他のクライアント端末から、BCHまたはFCHのOKフラグを受信したか否かを確認する。
そして、他のクライアント端末からのBCHまたはFCHのOKフラグの受信を確認した場合、すなわち、他のクライアント端末ではBCHまたはFCHのOKフラグがセットされている場合は、自クライアント端末は伝送路のノイズ状況などの一時的な要因により管理端末からBCHまたはFCHが受信できなかったものの、管理端末は正常に動作しているものと判断して、LEAVE NUMの値を0にリセットする(ステップS219)。
一方、他のクライアント端末からのBCHまたはFCHのOKフラグの受信を確認できない場合は、ステップS221において、送信側のクライアント端末から、BCHおよびFCHのNGフラグを受信を確認したか否かを確認する。
そして、他のクライアント端末からのBCHおよびFCHのNGフラグの受信を確認した場合、すなわち、他のクライアント端末でもBCHおよびFCHのNGフラグがセットされている場合は、ステップS222において、何台の他のクライアント端末からNGフラグを受信したかについてカウントし、LEAVE NUMの値に当該台数分のカウント数を加算する。
一方、他のクライアント端末からのBCHおよびFCHのNGフラグの受信を確認できない場合は、他のクライアント端末からのBCHのOKフラグおよびNGフラグ、FCHのOKフラグおよびNGフラグの何れも正常に受信できなかったものと判断し、自クライアント端末と送信側のクライアント端末との通信に支障が発生しているものとして、自クライアント端末でのLEAVE NUMのリセット動作を行わず、ステップS225に進む。
ステップS223の後、ステップS224において、LEAVE NUMの値が、予め定めた所定の値より大きくなったか否か、すなわちカウント回数が所定回数より大きくなったか否かを確認する。
そして、LEAVE NUMのカウント回数が所定回数より大きくなったことを確認した場合には、自クライアント端末においても、また他の送信クライアント端末においても管理端末からのBCHおよびFCHが受信できなくなっているものと判断し、管理端末がネットワークより離脱したものと判断して、NEW FLAGを1にセットする(ステップS224)。
なお、LEAVE NUMのカウント回数が所定回数より大きくなっていない場合、およびNEW FLAGを1にセットした後はステップS225に進む。
ステップS225においては、LEAVE NUMの値が0を越えるか否か、すなわち1以上であるか否かの確認を行う。LEAVE NUMの値が1以上の場合、管理端末が正常に動作していない可能性があるため、ステップS226において、新たな管理端末の生起の確認を実施する。なお、ステップS226の処理は、図12を用いて説明したステップS139の処理と同じである。
新たな管理端末の生起の確認を実施後、またはLEAVE NUMの値が0である場合は、1つのMACフレームについてのデータ送受信は完了し、新たなMACフレームのデータ送受信のために図9に示すステップS101に戻る。
<B−2.効果>
以上説明した実施の形態2のデータ送受信装置10を用いることで、クライアント端末間で映像ストリームの送受信中に管理端末がPLCネットワークから離脱した場合、自クライアント端末は、他のクライアント端末の管理端末からのBCHおよびFCHの受信状況を示すフラグ設定情報の収集が迅速に実施でき、早い段階で管理端末のネットワークからの離脱を判断することができる。同時に、各クライアント端末のうちの1つが同期を継承、新たな管理端末として生起し、ネットワークトポロジを回復させることができる。
また、映像ストリームを送信する際、固定帯域を割り当てるとともに、1フレーム内での固定帯域割当を同じ位置になるようにスケジューリングするので、前回受信したスケジュール情報、および基準時刻情報に基づいて映像ストリームの送受信をすれば、新たな管理端末が生起するまでの管理端末が不在の期間においても、映像ストリームを中断することなく伝送できる効果がある。
<C.変形例>
以上説明した実施の形態1および2においては、本発明の適用例として高速PLC端末に適用する場合について説明したが、本発明の適用はこれに限るものではなく、無線LAN、あるいはUWB(Ultra Wideband)、あるいはTDMA方式、あるいは映像ストリームに固定的な帯域を割り当ててデータを送受信する仕組みを有するデータ送受信方式を採用する他の伝送方式にも適用が可能である。
また、固定帯域が割り当てられた受信クライアント端末側での基準時刻補正を、MACヘッダに付加された送信クライアント端末側の基準時刻情報を用いて実施したが、これに限るものではなく、各クライアント端末内の基準クロックはほぼ管理端末の基準クロックに同期しているので、基準時刻補正を行わずに固定帯域が割り当てられたタイムスロットを使用してデータの送受信を実施することも可能である。
さらに、管理端末のPLCネットワークからの離脱判定をBCHおよびFCHともに受信できなかった場合について説明したが、これに限るものではなく、PLCネットワーク内の同期、および帯域を管理する制御フレームの送受信状態によって判断するよう構成すれば同様の効果を得ることができる。また、固定帯域割当に映像ストリームを伝送する場合について説明したが、これに限るものではなく、オーディオ、あるいは音声等に適用して実施することも可能である。