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

データ送受信装置 Download PDF

Info

Publication number
JP4980123B2
JP4980123B2 JP2007107992A JP2007107992A JP4980123B2 JP 4980123 B2 JP4980123 B2 JP 4980123B2 JP 2007107992 A JP2007107992 A JP 2007107992A JP 2007107992 A JP2007107992 A JP 2007107992A JP 4980123 B2 JP4980123 B2 JP 4980123B2
Authority
JP
Japan
Prior art keywords
management terminal
data
terminal
reception
transmission
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2007107992A
Other languages
English (en)
Other versions
JP2008270945A (ja
JP2008270945A5 (ja
Inventor
裕志 笠原
禎之 井上
靖之 橋詰
淳子 貴島
正博 内藤
美樹 菅野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP2007107992A priority Critical patent/JP4980123B2/ja
Publication of JP2008270945A publication Critical patent/JP2008270945A/ja
Publication of JP2008270945A5 publication Critical patent/JP2008270945A5/ja
Application granted granted Critical
Publication of JP4980123B2 publication Critical patent/JP4980123B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Small-Scale Networks (AREA)
  • Cable Transmission Systems, Equalization Of Radio And Reduction Of Echo (AREA)

Description

本発明はデータ送受信装置に関し、特に、無線通信あるいは高速PLC(Power Line Communication)などのネットワークシステムにおいて映像ストリーム等のデータを送受信するデータ送受信装置に関する。
昨今の無線通信、あるいは高速PLCなどのネットワークシステムの高速化に伴い、これらのシステムを用いて家庭内の映像ネットワークを構築する研究がなされている。無線通信、あるいは高速PLCなどを用いて、映像あるいは音声などのリアルタイム性を要求されるデータを送受信するためには、映像、音声を途切れなくスムーズに伝送するために、予め送信するデータの伝送帯域を確保した上で伝送する必要がある。そのため、無線LAN(Local Area Network)等では、TDMA(Time Division Multiple Access)方式を採用し、データの伝送帯域を予め確保してデータを伝送する方式なども導入されつつある。具体的には、例えばARIB(社団法人電波産業会)にて標準規格化されたHiSWANa(High Speed Wireless Access Networking Type a:ARIB STD-T70 1.0版)などがある。
以下、上記HiSWANa規格に採用されたTDMA方式の概要を簡単に説明する。HiSWANaで採用されたTDMA方式は、管理端末と呼ばれる1台の端末(データ送受信装置)によりネットワーク内の各端末(データ送受信装置)が管理される。なお、管理端末により管理される端末をクライアント端末と呼称する。
管理端末は、ネットワーク全体の時刻同期を管理するために、Beacon信号と呼ばれるパケットデータ(以下、BCH:Broadcast CHannelと表記)を予め定められた周期で同報通信する(HiSWANaでは2ms周期)。
ネットワーク内に配置された各クライアント端末は、BCHを受信すると、それを基準に、端末内の基準時刻情報をリセットするとともに、管理端末より送信される各種制御パケットの受信準備を開始する。管理端末は、BCH送出後、ネットワークに接続された各クライアント端末のデータ送信スケジュールを含むネットワークシステム制御用のパケットデータ(以下、FCH:Frame CHannelと表記)を、各クライアント端末に対して同報通信する。
上記FCHには、ネットワークに接続された各クライアント端末のデータ送信、および受信のスケジュール(データの送受信スロット情報(送受信開始タイミング情報、データ送受信時間情報など))が付加され送信される。各クライアント端末は、FCHを受信すると、自端末がデータを受信するタイミングおよび自端末がデータを送信するタイミングを検出する。
管理端末は、FCHの送信に引き続き、各クライアント端末に対して送信要求受信通知のパケットデータ(以下、ACH:Access feedback CHannelと表記)を送信する。管理端末より、上記BCH、FCH、ACHの各パケットデータの送信が完了すると、FCHにて通知されたスケジュールに基づき各クライアント端末はパケットデータの受信、および送信動作を開始する(以下、各端末間でデータの送受信を行う期間をTCHと表記)。
TDMA方式では、管理端末は送信したいデータを持つクライアント端末についてのみデータ送信スロットをスケジューリングする。従って、送信したいデータを持つクライアント端末は、管理端末に対して自端末のデータを送信するためのスロットを割り振るよう要求する必要がある。上記HiSWANa規格で採用されたTDMA方式では、各クライアント端末より送信リクエストを受け付けるため、1Beacon周期内(以下、1フレームと表記)の最後に、各端末からの上記送信スロット要求リクエスト(帯域割り当て要求)を受け付けるためのCSMA(Carrier Sense Multiple Access)期間(以下、RCH:Random access CHannel期間と表記)を準備している。
管理端末は、RCH期間に上記送信スロット要求リクエストを受け取った端末に対しては、次のBeacon周期内のACHにて帯域割り当て要求を受け取った旨を通知する。
次に、上述したHiSWANa規格をベースとしたTDMA方式を、例えば高速PLCに適用した従来のデータ送受信装置におけるシステム構成について説明する。
一般に、無線LANや高速PLCをベースとしたデータ送受信装置では、クライアント端末間でデータの送受信を実施する際は、管理端末経由でデータの送受信を実施する。具体的には、第1のクライアント端末から第2のクライアント端末にデータを送信する際は、第1のクライアント端末は管理端末に対して送信データを送り、データを受け取った管理端末は第2のクライアント端末に受信したデータを送信する。この場合、第1のクライアント端末から第2のクライアント端末に対してのデータの送信であるにもかかわらず、管理端末を経由するため、限られた帯域を2倍使用することになる。
このような問題を解決するため、クライアント端末間で直接にデータの送受信を実施する方法がある。すなわち、TDMA方式では、先に説明したように、管理端末と各クライアント端末間の同期は、定期的に管理端末から出力されるBeacon信号によって確保されている。従って、スケジューリングの概念を拡張することにより同期の取れたクライアント端末間の直接通信が可能となる。
例えば、特許文献1では、無線ネットワーク上で、特定の無線端末が管理端末(マスタ)として動作し、全ての無線端末が管理端末に同期して動作するのではなく、アドホックネットワークを構成して、近隣の無線端末間で自律分散的に同期を取る同期方式が開示されている。
特開2005−341148号公報
しかしながら、高速PLCを家庭内で使用するAV(Audio Visual)機器などに内蔵した場合、以下のような問題が発生する。例えば、居間に置かれたAVレコーダをクライアント端末の1つとし、再生された映像ストリームを他のクライアント端末である寝室に置かれたTV(Television)システムに送信中に、管理端末である、居間にあるTVシステムの電源コンセントがユーザによって抜かれた場合を考える。
この場合、管理端末である居間にあるTVシステムの電源が切られたため、PLCネットワークとしてはBCH、FCH等の制御フレーム情報を送信する管理端末がなくなり、各クライアント端末間の同期が取れなくなるとともに、スケジュールデータが受信できなくなるため、居間にあるAVレコーダと寝室にあるTVシステムとの間の映像ストリームの送受信が中断するといった問題点があった。
例えば、特許文献1で述べられている自律分散型のアドホックネットワークでは、近隣端末間の同期を取ることはできるが、映像ストリームなどのリアルタイム性の要求されるデータを伝送する場合、送信される映像ストリームの送信帯域が確保されるとは限らないので、表示画像が一時的に止まる、あるいは乱れるといった問題が発生する。
また、特許文献1の技術では、各クライアント端末が同期を取るために、タイムスロット(スーパーフレームを64個に分割したものの1つ)内に、自己のビーコン送信位置が設定され、一定周期でビーコンが送信される。そのため、データを送信しない端末も一定周期でビーコンを送出するため送信帯域が必要となり、送信帯域を無駄に使用してしまうといった問題点があった。
特に高速PLCでは1OFDMシンボルのシンボル長が長く設定されている場合が多い。従って、ネットワークに接続されている各クライアント端末が一定周期でビーコンを送出した場合、同期を取るためのオーバーヘッド(無駄な帯域使用)期間が長くなるといった問題点があった。例えば、1OFDMシンボル長を50μsとし、プリアンブルを4シンボル、ペイロードを1シンボルとした場合でも、1クライアント端末あたり少なくともビーコン送出に250μsの伝送再域を使用することになる。
本発明は上記のような問題点を解消するためになされたもので、クライアント端末間でデータの送受信が実施可能なネットワークを構成するデータ送受信装置において、クライアント端末間で映像ストリームを伝送中に、管理端末の電源が切られるなどして管理端末が動作しなくなった場合でも、クライアント間の同期を保ち、映像ストリームを途切れることなく伝送させるとともに、再びネットワーク内に管理端末を生起させるデータ送受信装置を提供することを目的とする。
本発明に係る請求項1記載のデータ送受信装置は、ネットワークシステムの複数の端末のそれぞれに含まれるデータ送受信装置であって、前記複数の端末は、他の端末を管理する管理端末と、該管理端末により管理されるクライアント端末を複数含み、前記データ送受信装置は、1フレーム内に含まれる同期情報およびスケジュール情報を検出する制御情報検出部と、前記同期情報および前記スケジュール情報が自機および他の前記クライアント端末において正常に受信できたか否かの受信状況情報を確認するとともに、前記受信状況情報に基づいて前記同期情報および前記スケジュールの送信元が正常に動作しているかどうかを判断する制御部とを備え、前記データ送受信装置は、前記管理端末として機能する場合に、前記同期情報および前記スケジュール情報を定期的に出力するとともに、新たな管理端末となる前記クライアント端末の優先順位を定め、前記データ送受信装置は、前記クライアント端末として機能する場合に、前記管理端末から送信される前記同期情報および前記スケジュール情報に基づいて、映像データおよび制御データの送受信を実行し、前記制御部において、自機および他の前記クライアント端末からの前記受信状況情報に基づいて、前記管理端末が正常に動作していないと判断され、かつ、自機が、前記新たな管理端末の候補としての前記優先順位が1位に設定されている場合に、自らが前記新たな管理端末候補となったことを、生起情報として他の前記クライアント端末に通知し、他の前記クライアント端末からの承認の通知を受けた場合には、前記新たな管理端末として、前記管理端末の動作を承継する。
本発明に係る請求項1記載のデータ送受信装置によれば、管理端末が正常に動作していないと判断され、かつ、自機が、新たな管理端末の候補としての優先順位が1位に設定されている場合に、自らが前記新たな管理端末候補となったことを、生起情報として他の前記クライアント端末に通知し、他の前記クライアント端末からの承認の通知を受けた場合には、新たな管理端末として管理端末の動作を承継するので、クライアント端末間で映像ストリーム等を伝送中に管理端末の電源がオフされた場合でも、映像ストリームを途切れることなく伝送させることができるとともに、再びネットワーク内に新たな管理端末を生起させることができる。
<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ネットワーク内の同期、および帯域を管理する制御フレームの送受信状態によって判断するよう構成すれば同様の効果を得ることができる。また、固定帯域割当に映像ストリームを伝送する場合について説明したが、これに限るものではなく、オーディオ、あるいは音声等に適用して実施することも可能である。
本発明に係るデータ送受信装置を適用した高速PLCネットワークシステムの構成を示す図である。 本発明に係るデータ送受信装置の構成を説明するブロック図である。 本発明に係るデータ送受信装置内のPLCモデム回路の構成を示すブロック図である。 PLCモデム回路内のPLC送信制御回路の構成を示すブロック図である。 PLCモデム回路内のPLC受信制御回路の構成を示すブロック図である。 高速PLCを用いたデータ送受信装置にてデータ送受信を行う際の、1フレーム内のデータフォーマットおよびFCH内のスケジュールデータの構成を示す図である。 本発明に係るデータ送受信装置を管理端末として使用する場合の動作を説明するフローチャートである。 本発明に係るデータ送受信装置を管理端末として使用する場合の、新たな管理端末候補の優先順位情報の生成方法を説明するフローチャートである。 本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態1の動作を説明するフローチャートである。 本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態1の動作を説明するフローチャートである。 本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態1の動作を説明するフローチャートである。 本発明に係るデータ送受信装置をクライアント端末として使用する場合の、新たな管理端末の生起を説明するフローチャートである。 本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態2の動作を説明するフローチャートである。 本発明に係るデータ送受信装置をクライアント端末として使用する場合の実施の形態2の動作を説明するフローチャートである。

Claims (4)

  1. ネットワークシステムの複数の端末のそれぞれに含まれるデータ送受信装置であって、
    前記複数の端末は、他の端末を管理する管理端末と、該管理端末により管理されるクライアント端末を複数含み、
    前記データ送受信装置は、
    1フレーム内に含まれる同期情報およびスケジュール情報を検出する制御情報検出部と、
    前記同期情報および前記スケジュール情報が自機および他の前記クライアント端末において正常に受信できたか否かの受信状況情報を確認するとともに、前記受信状況情報に基づいて前記同期情報および前記スケジュールの送信元が正常に動作しているかどうかを判断する制御部とを備え、
    前記データ送受信装置は、前記管理端末として機能する場合に、前記同期情報および前記スケジュール情報を定期的に出力するとともに、新たな管理端末となる前記クライアント端末の優先順位を定め、
    前記データ送受信装置は、前記クライアント端末として機能する場合に、前記管理端末から送信される前記同期情報および前記スケジュール情報に基づいて、映像データおよび制御データの送受信を実行し、
    前記制御部において、自機および他の前記クライアント端末からの前記受信状況情報に基づいて、前記管理端末が正常に動作していないと判断され、かつ、自機が、前記新たな管理端末の候補としての前記優先順位が1位に設定されている場合に、自らが前記新たな管理端末候補となったことを、生起情報として他の前記クライアント端末に通知し、他の前記クライアント端末からの承認の通知を受けた場合には、前記新たな管理端末として、前記管理端末の動作を承継する、データ送受信装置。
  2. 前記データ送受信装置は、
    前記同期情報および前記スケジュール情報の少なくとも一方が受信できなかった場合、前回までに受信した各フレーム内の前記スケジュール情報に基づいて検出したクロックの誤差情報を用いて内部の時刻情報を補正する、ネットワーク制御データ解析部を備える、請求項1記載のデータ送受信装置。
  3. 前記データ送受信装置は、前記管理端末として機能する場合に、リアルタイムが要求されるデータの送信要求のあった前記クライアント端末に対しては、固定帯域を割り当てる固定帯域割当てを実施する、請求項1記載のデータ送受信装置。
  4. 前記データ送受信装置は、前記管理端末として機能する場合に、前記制御部において、前記固定帯域割当てが実施されて前記データを受信中の前記クライアント端末に対して、前記新たな管理端末となるべき前記優先順位を設定する、請求項記載のデータ送受信装置。
JP2007107992A 2007-04-17 2007-04-17 データ送受信装置 Expired - Fee Related JP4980123B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007107992A JP4980123B2 (ja) 2007-04-17 2007-04-17 データ送受信装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007107992A JP4980123B2 (ja) 2007-04-17 2007-04-17 データ送受信装置

Publications (3)

Publication Number Publication Date
JP2008270945A JP2008270945A (ja) 2008-11-06
JP2008270945A5 JP2008270945A5 (ja) 2010-01-14
JP4980123B2 true JP4980123B2 (ja) 2012-07-18

Family

ID=40049909

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007107992A Expired - Fee Related JP4980123B2 (ja) 2007-04-17 2007-04-17 データ送受信装置

Country Status (1)

Country Link
JP (1) JP4980123B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5137787B2 (ja) * 2008-11-14 2013-02-06 三菱電機株式会社 データ送受信装置
JP5446239B2 (ja) * 2008-12-16 2014-03-19 ソニー株式会社 電力供給システム

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3114705B2 (ja) * 1998-07-30 2000-12-04 日本電気株式会社 Tdma通信ネットワークシステム
JP4806868B2 (ja) * 2000-08-30 2011-11-02 ソニー株式会社 通信装置及び通信方法
KR100552490B1 (ko) * 2003-06-13 2006-02-15 삼성전자주식회사 무선 애드혹 네트워크 환경에서 중재자 교체방법 및 그방법을 사용하는 통신시스템
JP2008211536A (ja) * 2007-02-27 2008-09-11 Meidensha Corp リモートio伝送システム

Also Published As

Publication number Publication date
JP2008270945A (ja) 2008-11-06

Similar Documents

Publication Publication Date Title
EP2482596B1 (en) Syncronizing wireless devices
JP5153782B2 (ja) アドホックネットワーク内の簡略化された自動コンフィギュレーションおよびサービスディスカバリ
US9673858B2 (en) Fast frequency-hopping schedule recovery
US7460555B2 (en) Terminal apparatus
KR100669130B1 (ko) 공유 병렬 데이터 채널에 채널 액세스를 조정하는 방법 및 장치
TWI433506B (zh) 媒體存接控制方法及系統
US20080040759A1 (en) System And Method For Establishing And Maintaining Synchronization Of Isochronous Audio And Video Information Streams in Wireless Multimedia Applications
US9848446B2 (en) System and methods for synchronizing edge devices on channels without carrier sense
US20120033620A1 (en) Synchronization for data transfers between physical layers
TW200935800A (en) Multiple channel support in distributed wireless systems
JP2008252925A (ja) 複数の局を含むネットワークの通信チャネルにアクセスする方法
WO2001056180A1 (en) Two-dimensional scheduling scheme for a broadband wireless access system
US8565258B2 (en) Terminal capable of substituting for control station
JP2006217619A (ja) 無線オーディオ信号送信の干渉を回避する方法および装置
JP2008118548A (ja) 通信装置および通信装置としてコンピュータを機能させるためのプログラム
JP2008263584A (ja) 少なくとも1つの加入者局と少なくとも2つの基地局との間の通信方法
US8737433B2 (en) Method for synchronizing clocks in a communication system
JP2007267082A (ja) データ送受信装置及びデータ送受信方法
JP4980123B2 (ja) データ送受信装置
JP2008263511A (ja) データ送受信装置
JP5178405B2 (ja) データ送受信装置
US20110085523A1 (en) Method for managing a distribution of bandwidth in a communications network, corresponding storage means and slave node
JP2009027327A (ja) データ送受信装置
JP2011147124A (ja) スタートポロジを有する無線ネットワーク及びその無線ネットワークを動作させる方法
JP2003505929A (ja) コンピュータ・ネットワーク通信チャネル用のネットワーク・スロットの同期方法

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20091112

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091112

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20111216

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120110

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120301

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120321

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120418

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150427

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4980123

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees