TOP > 国内特許検索 > 子局装置 > 明細書

明細書 :子局装置

発行国 日本国特許庁(JP)
公報種別 公開特許公報(A)
公開番号 特開2016-140011 (P2016-140011A)
公開日 平成28年8月4日(2016.8.4)
発明の名称または考案の名称 子局装置
国際特許分類 H04L  12/44        (2006.01)
FI H04L 12/44 200
請求項の数または発明の数 5
出願形態 OL
全頁数 24
出願番号 特願2015-015183 (P2015-015183)
出願日 平成27年1月29日(2015.1.29)
発明者または考案者 【氏名】大島 一能
出願人 【識別番号】503420833
【氏名又は名称】学校法人常翔学園
個別代理人の代理人 【識別番号】100115749、【弁理士】、【氏名又は名称】谷川 英和
【識別番号】100121223、【弁理士】、【氏名又は名称】森本 悟道
審査請求 未請求
テーマコード 5K033
Fターム 5K033AA02
5K033AA04
5K033CB01
5K033DA15
5K033DB01
5K033DB13
5K033DB25
要約 【課題】省電力化とリアルタイム性の確保のそれぞれを実現できるように周期的なスリープを制御する。
【解決手段】ONU2は、送信バッファ21のバッファ状況を取得するバッファ状況取得部25、下位のレイヤにおける第1の通信に関する接続状態について判断する第1の判断部43、上位のレイヤにおける第2の通信に関する接続状態について判断する第2の判断部44、バッファ状況に応じて光受信部42を周期的にスリープさせるスリープ制御部45を備え、スリープ制御部45は、スリープ時間を、第1の通信が接続状態であり、第2の通信が接続状態でなければ、バッファ状況に応じて、第1のスリープ時間以下にし、第2の通信が接続状態であれば、第1のスリープ時間よりも小さい第2のスリープ時間にし、第1及び第2の通信が接続状態でなければ、第1のスリープ時間よりも大きい第3のスリープ時間にする。
【選択図】図3
特許請求の範囲 【請求項1】
親局装置と複数の子局装置とが、スプリッタを有する光通信路により接続された受動光ネットワークシステムにおける子局装置であって、
前記親局装置に送信されるデータがバッファリングされる送信バッファと、
前記送信バッファでバッファリングされているデータを前記親局装置に送信する光送信部と、
前記親局装置から送信されたデータを受信する光受信部と、
前記送信バッファにおけるデータのバッファリングの状況に関するバッファ状況を取得するバッファ状況取得部と、
前記光送信部によって送信されるデータ、及び前記光受信部によって受信されるデータの少なくとも一方に応じて、第1のレイヤにおける第1の通信に関する接続状態について判断する第1の判断部と、
前記光送信部によって送信されるデータ、及び前記光受信部によって受信されるデータの少なくとも一方に応じて、前記第1のレイヤより上位のレイヤである第2のレイヤにおける第2の通信に関する接続状態について判断する第2の判断部と、
前記バッファ状況取得部によって取得されたバッファ状況に応じて、前記光受信部を周期的にスリープさせるスリープ制御部と、を備え、
前記スリープ制御部は、
周期的なスリープにおけるスリープ期間の長さを、前記第1の判断部によって前記第1の通信が接続状態であると判断され、かつ、前記第2の判断部によって前記第2の通信が接続状態でないと判断された場合に、前記バッファ状況取得部によって取得されたバッファ状況に応じて、第1のスリープ時間以下に決定し、前記第2の判断部によって前記第2の通信が接続状態であると判断された場合に、前記第1のスリープ時間よりも小さい第2のスリープ時間に決定し、前記第1の判断部によって前記第1の通信が接続状態でないと判断され、かつ、前記第2の判断部によって前記第2の通信が接続状態でないと判断された場合に、前記第1のスリープ時間よりも大きい第3のスリープ時間に決定する、子局装置。
【請求項2】
前記スリープ制御部は、前記光受信部をスリープさせる場合に、スリープ申請を前記光送信部によって前記親局装置に送信し、当該スリープ申請の送信に応じて前記親局装置から送信されたスリープ許可が、前記光受信部によって受信された場合に、前記光受信部を周期的にスリープさせる、請求項1記載の子局装置。
【請求項3】
前記スリープ制御部は、前記バッファ状況取得部によって取得されたバッファ状況に応じて、前記光送信部をもスリープさせる、請求項1または請求項2記載の子局装置。
【請求項4】
前記スリープ制御部は、前記バッファ状況によって送信対象のデータのないことが示される場合に、前記光送信部をスリープさせる、請求項3記載の子局装置。
【請求項5】
前記バッファ状況は、データ到着間隔及びバッファ量の少なくとも一方である、請求項1から請求項4のいずれか記載の子局装置。
発明の詳細な説明 【技術分野】
【0001】
本発明は、受動光ネットワークシステムにおける子局装置であって、周期的なスリープ制御を行う子局装置に関する。
【背景技術】
【0002】
従来、受動光ネットワーク(PON:Passive Optical Network)システムにおいて、子局装置(ONU:Optical Network Unit)の消費電力削減が重要な課題となっており、2013年には、国際標準規格IEEE1904.1 SIEPON(Service Interoperability in EPON)などにより、基本的な省電力化機能が規定された。
【0003】
そのような省電力化のため、通信トラフィックがない状態のONUでは、光送受信器などへの電力供給を休止すること(スリープ)が行われている。そのスリープ中に親局装置(OLT:Optical Line Terminal)に到達した下り受信データは、OLTでバッファされ、アクティブ期間(受信可能期間)となった後に、OLTからONUに送信されていた。なお、そのようなスリープ制御において、通信のリアルタイム性を確保するため、短い期間でスリープ期間とアクティブ期間とを周期的に繰り返すことが行われている(例えば、特許文献1参照)。
【先行技術文献】
【0004】

【特許文献1】特開2014-57192号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
サイクリックスリープなどの周期的なスリープにおいて、省電力化のためには、スリープ期間の長さであるスリープ時間を長くすることが求められる。一方、リアルタイム性を高めるためには、アクティブ期間の長さであるアクティブ時間を長くすることが求められる。
【0006】
本発明は、上述のような状況においてなされたものであり、PONシステムにおけるONUであって、省電力化と、リアルタイム性の確保とのそれぞれを実現できるように周期的なスリープを制御する子局装置を提供することを目的とする。
【課題を解決するための手段】
【0007】
上記目的を達成するため、本発明による子局装置は、親局装置と複数の子局装置とが、スプリッタを有する光通信路により接続された受動光ネットワークシステムにおける子局装置であって、親局装置に送信されるデータがバッファリングされる送信バッファと、送信バッファでバッファリングされているデータを親局装置に送信する光送信部と、親局装置から送信されたデータを受信する光受信部と、送信バッファにおけるデータのバッファリングの状況に関するバッファ状況を取得するバッファ状況取得部と、光送信部によって送信されるデータ、及び光受信部によって受信されるデータの少なくとも一方に応じて、第1のレイヤにおける第1の通信に関する接続状態について判断する第1の判断部と、光送信部によって送信されるデータ、及び光受信部によって受信されるデータの少なくとも一方に応じて、第1のレイヤより上位のレイヤである第2のレイヤにおける第2の通信に関する接続状態について判断する第2の判断部と、バッファ状況取得部によって取得されたバッファ状況に応じて、光受信部を周期的にスリープさせるスリープ制御部と、を備え、スリープ制御部は、周期的なスリープにおけるスリープ期間の長さを、第1の判断部によって第1の通信が接続状態であると判断され、かつ、第2の判断部によって第2の通信が接続状態でないと判断された場合に、バッファ状況取得部によって取得されたバッファ状況に応じて、第1のスリープ時間以下に決定し、第2の判断部によって第2の通信が接続状態であると判断された場合に、第1のスリープ時間よりも小さい第2のスリープ時間に決定し、第1の判断部によって第1の通信が接続状態でないと判断され、かつ、第2の判断部によって第2の通信が接続状態でないと判断された場合に、第1のスリープ時間よりも大きい第3のスリープ時間に決定する、ものである。
【0008】
このような構成により、第1の通信が接続状態(例えば、TCP(Transmission Control Protocol)のコネクションが確立されている状態)である場合には、たとえ上り送信データがなかったとしても、ユーザが次の操作を行うことによって上り送信データが発生しうるため、スリープ期間の長さを第1のスリープ時間以下とすることにより、そのような上り送信データの発生等に対する応答性を向上させることができる。また、例えば、第1の通信がトランスポート層の通信である場合には、上位のアプリケーション層における通信に関係なく、第1の通信の接続に応じてスリープ期間の長さを制御できるようになる。そのため、第1のレイヤよりも上位のレイヤにおいて新たな通信規格(プロトコル)による通信が追加されたとしても、その通信が第1の通信によって行われる場合には、その通信に対して適切なスリープ制御を行うことができる。また、第2の通信が接続状態(例えば、SIP(Session Initiation Protocol)のセッションが確立されている状態)である場合には、通常、リアルタイム性が要求されると考えられるため、たとえ上り送信データがなかったとしてもスリープ期間の長さを第2のスリープ時間とすることにより、通信の遅延を防止することができる。また、第1及び第2の通信が行われていない場合には、スリープ期間の長さを第3のスリープ時間とすることにより、例えば、夜間や不在時などの通信トラフィックがほとんど発生しない状況において、効果的に省電力化を図ることができるようになる。
【0009】
また、本発明による子局装置では、スリープ制御部は、光受信部をスリープさせる場合に、スリープ申請を光送信部によって親局装置に送信し、スリープ申請の送信に応じて親局装置から送信されたスリープ許可が、光受信部によって受信された場合に、光受信部を周期的にスリープさせてもよい。
このような構成により、親局装置においてもスリープが許可された場合に周期的なスリープが行われることになり、より確実なスリープ制御を行うことができるようになる。
【0010】
また、本発明による子局装置では、スリープ制御部は、バッファ状況取得部によって取得されたバッファ状況に応じて、光送信部をもスリープさせてもよい。
このような構成により、光受信部のみでなく、光送信部もスリープ制御の対象とすることができ、子局装置における消費電力をより削減することができるようになる。
【0011】
また、本発明による子局装置では、スリープ制御部は、バッファ状況によって送信対象のデータのないことが示される場合に、光送信部をスリープさせてもよい。
このような構成により、上り送信データのない状況において、その送信を行う光送信部をスリープさせることになり、上り送信データの送信への影響を低減させながら、省電力化を図ることができるようになる。
【0012】
また、本発明による子局装置では、バッファ状況は、データ到着間隔及びバッファ量の少なくとも一方であってもよい。
【発明の効果】
【0013】
本発明による子局装置によれば、省電力化と、リアルタイム性の確保とのそれぞれを実現できるように周期的なスリープを制御することができるようになる。
【図面の簡単な説明】
【0014】
【図1】本発明の実施の形態によるPONシステムの構成を示すブロック図
【図2】同実施の形態によるOLTの構成を示すブロック図
【図3】同実施の形態によるONUの構成を示すブロック図
【図4】同実施の形態によるOLTの動作を示すフローチャート
【図5】同実施の形態によるONUの動作を示すフローチャート
【図6】同実施の形態によるスリープ制御について説明するための図
【図7】同実施の形態によるスリープ時間について説明するための図
【図8A】TCPの接続開始について説明するための図
【図8B】TCPの接続終了について説明するための図
【図8C】SIPのセッションの生成及び切断について説明するための図
【発明を実施するための形態】
【0015】
以下、本発明のPONシステムについて、実施の形態を用いて説明する。なお、以下の実施の形態において、同じ符号を付した構成要素及びステップは同一または相当するものであり、再度の説明を省略することがある。本実施の形態によるPONシステムは、ONUにおいて、周期的なスリープ時間を制御するものである。

【0016】
図1は、本実施の形態によるPONシステム(受動光ネットワークシステム)の構成を示すブロック図である。本実施の形態によるPONシステムは、受動素子であるスプリッタ3を有する光通信路で接続されたOLT(親局装置)1と複数のONU(子局装置)2-1,2-2,…,2-N(Nは2以上の整数である)とを備える。なお、特に区別しなくてよい場合には、ONU2-1,2-2,…,2-Nを、ONU2と呼ぶこともある。また、OLT1は、局側光終端装置と呼ばれることもあり、ONU2は、加入者側光終端装置と呼ばれることもある。OLT1から光ファイバを介して送信された光信号は、スプリッタ3によって分岐され、各ONU2に到達する。また、各ONU2から光ファイバを介して送信された光信号は、スプリッタ3を経由してOLT1に到達する。なお、ONU2から送信されるデータが、他のONU2から送信されるデータと衝突しないようにするため、OLT1は各ONU2の送信タイミングを制御する。OLT1の上流側には、サーバやネットワーク等が接続される。また、ONU2の下流側には、PCやその他のユーザ端末等が接続される。

【0017】
図2は、PONシステムにおけるOLT1の構成を示すブロック図である。図2において、OLT1は、送信バッファ11と、受信バッファ12と、光送受信部13と、WDM14と、バッファ状況取得部15と、制御部16と、インターフェース17とを備える。光送受信部13は、光送信部31と、光受信部32とを有している。制御部16は、スリープ判断部33を有している。

【0018】
送信バッファ11では、ONU2に送信される下り送信データが、ONU2ごとにバッファリングされる。受信バッファ12では、ONU2から送信された上り受信データがバッファリングされる。光送受信部13の光送信部31は、送信バッファ11でバッファリングされているデータをONU2に送信する。その送信において、光送信部31は、電気信号のデータを光信号に変換して送信する。光送受信部13の光受信部32は、ONU2から送信されたデータを受信する。その受信において、光受信部32は、光信号を受信して電気信号のデータに変換する。WDM(Wavelength Division Multiplexing)14は、波長の違う光信号を多重したり分離したりする。光送信部31からの光信号は、WDM14を介して光ファイバで送信され、光ファイバからの光信号は、WDM14を介して光受信部32に入力される。

【0019】
バッファ状況取得部15は、送信バッファ11におけるデータのバッファリングの状況に関するバッファ状況を取得する。バッファ状況は、例えば、データ到着間隔及びバッファ量の少なくとも一方であってもよい。バッファ量は、送信バッファ11に蓄積されたデータ量である。そのバッファ状況は、最新の所定の期間に応じた平均値であってもよい。

【0020】
制御部16は、PONプロトコルに基づいてOLT側の制御を行うものであり、スリープ判断部33を有している。制御部16は、インターフェース17を介して受信した下り送信データを送信バッファ11に蓄積すると共に、そのバッファリングされている下り送信データを読み出して、光送受信部13を介してONU2に送信する。また、制御部16は、ONU2から送信された上り受信データを、光送受信部13を介して受信し、受信バッファ12に蓄積すると共に、そのバッファリングされている上り受信データを読み出して、インターフェース17を介して上流側の装置やネットワークに送信する。また、制御部16は、各ONU2から送信される上りデータが衝突しないように、それらの光通信を制御する。なお、スリープ判断部33以外の制御部16の処理については、従来のPONシステムにおいて公知であり、その詳細な説明を省略する。

【0021】
スリープ判断部33は、OLT1がONU2から送信されたスリープ申請を受信した場合に、そのスリープ申請を送信したONU2がスリープしてよいかどうかについて、取得されたバッファ状況を用いて判断する。そして、その判断の結果、スリープしてもよい場合には、スリープ判断部33は、スリープ申請を送信したONU2に、スリープ許可を送信する。一方、その判断の結果、スリープしてはよくない場合には、スリープ判断部33は、例えば、スリープ申請を送信したONU2に、スリープ不許可を送信してもよく、または、何も送信しなくてもよい。また、ONU2から送信されたスリープ申請にスリープ時間が含まれていてもよい。そして、スリープ申請にスリープ時間が含まれている場合には、スリープ判断部33は、バッファ状況を用いて決定したスリープ時間が、スリープ申請に含まれているスリープ時間よりも短いときに、その決定したスリープ時間を含むスリープ許可を送信してもよい。なお、そのスリープ判断部33の処理の詳細については後述する。
インターフェース17は、上流側の装置やネットワークとのインターフェース機能を実現するものである。

【0022】
図3は、PONシステムにおけるONU2の構成を示すブロック図である。図3において、ONU2は、送信バッファ21と、受信バッファ22と、光送受信部23と、WDM24と、バッファ状況取得部25と、制御部26と、インターフェース27とを備える。光送受信部23は、光送信部41と、光受信部42とを有している。制御部26は、第1の判断部43と、第2の判断部44と、スリープ制御部45とを有している。

【0023】
送信バッファ21では、OLT1に送信される上り送信データがバッファリングされる。受信バッファ22では、OLT1から送信された下り受信データがバッファリングされる。光送受信部23の光送信部41は、送信バッファ21でバッファリングされているデータをOLT1に送信する。その送信において、光送信部41は、電気信号のデータを光信号に変換して送信する。光送受信部23の光受信部42は、OLT1から送信されたデータを受信する。その受信において、光受信部42は、光信号を受信して電気信号のデータに変換する。なお、光送受信部23は、受信した下りデータのうち、自らのONU2宛のデータのみを受信し、他のONU2宛のデータは破棄する。WDM24は、波長の違う光信号を多重したり分離したりする。光送信部41からの光信号は、WDM24を介して光ファイバで送信され、光ファイバからの光信号は、WDM24を介して光受信部42に入力される。

【0024】
バッファ状況取得部25は、送信バッファ21におけるデータのバッファリングの状況に関するバッファ状況を取得する。バッファ状況は、例えば、フレーム到着間隔及びバッファ量の少なくとも一方であってもよい。バッファ量は、送信バッファ21に蓄積されたデータ量である。そのバッファ状況は、最新の所定の期間に応じた平均値であってもよい。

【0025】
制御部26は、PONプロトコルに基づいてONU側の制御を行うものであり、第1の判断部43、第2の判断部44、及びスリープ制御部45を有している。制御部26は、インターフェース27を介して受信した上り送信データを送信バッファ21に蓄積すると共に、そのバッファリングされている上り送信データを読み出して、光送受信部23を介してOLT1に送信する。また、制御部26は、OLT1から送信された下り受信データを、光送受信部23を介して受信し、受信バッファ22に蓄積すると共に、そのバッファリングされている下り受信データを読み出して、インターフェース27を介して下流側の装置やネットワークに送信する。また、制御部26は、各ONU2から送信される上りデータが衝突しないようにするため、OLT1からの指示に応じて上り送信データが送信されるように制御する。なお、第1及び第2の判断部43,44、並びにスリープ制御部45以外の制御部26の処理については、従来のPONシステムにおいて公知であり、その詳細な説明を省略する。

【0026】
第1の判断部43は、光送信部41によって送信されるデータ、及び光受信部42によって受信されるデータの少なくとも一方に応じて、第1のレイヤにおける第1の通信に関する接続状態について判断する。その判断は、第1の通信が接続状態であるかどうかに関する判断である。本実施の形態では、第1のレイヤがトランスポート層であり、第1の通信がTCPの通信である場合について主に説明するが、第1の通信は、通信の確立と通信の終了とが存在する通信であればよく、TCPの通信に限定されない。また、第1のレイヤは、トランスポート層以外であってもよい。

【0027】
第1の通信がTCPである場合には、TCPのコネクションが確立している状態が接続状態となる。TCPでは、図8Aで示されるように通信の確立が行われる(3ウェイ・ハンドシェイク)。まず、装置AがSYNパケットを装置Bに送信する。装置Bは、そのSYNパケットを受信すると、それに応じてSYN+ACKパケットを装置Aに送信する。装置Aは、そのSYN+ACKパケットを受信すると、接続開始を示すACKパケットを装置Bに送信し、装置A,Bの間でTCPの通信が行われる。また、TCPでは、図8Bで示されるように通信の終了が行われる。まず、装置Aから装置Bに送信するデータがなくなると、装置AはFINパケットを装置Bに送信する。装置Bは、そのFINパケットを受信すると、それに応じてACKパケットを装置Aに送信する。その後、装置Bから装置Aに送信するデータもなくなると、装置BはFINパケットを装置Aに送信する。装置Aは、そのFINパケットを受信すると、それに応じてACKパケットを装置Bに送信する。そのようにして、装置A,Bの間でのTCPの通信が終了することになる。なお、図8Bに示されるようにしてTCPの通信が終了されることもあるが、そうでないこともある。例えば、通信中に装置Bの電源が落ちた場合にも通信は終了される。そのような状況であっても、装置Aは、接続終了の処理を行っていないため、装置Bとのコネクションが確立した状態であると判断してしまう。そのため、TCPでは、キープアライブ(Keep Alive)パケットを定期的に送受信することによって、通信が確立状態であることを確認することもできる。すなわち、装置Bの電源が落ちた場合には、装置Aは、キープアライブパケットが到着しなくなることにより、または、キープアライブパケットに対する応答がないことにより、装置Bとのコネクションが終了していることを知ることができる。なお、装置B側から接続開始の処理が行われてもよく、また装置B側から接続終了の処理が行われてもよいことは言うまでもない。

【0028】
第1の判断部43は、例えば、上り送信データや下り受信データを観測し、3ウェイ・ハンドシェイクの処理が行われたことを検知した場合に、第1の通信が接続状態になった(すなわち、TCPのコネクションが確立した)と判断してもよい。また、第1の判断部43は、例えば、上り送信データや下り受信データを観測し、接続終了の処理が行われたことを検知した場合に、第1の通信が接続状態でなくなった(すなわち、TCPのコネクションが解除された)と判断してもよい。また、第1の判断部43は、例えば、上り送信データや下り受信データを観測し、第1の通信が接続状態であると判断されている場合に、あらかじめ決められた時間以上、キープアライブの送受信が行われていないときに、第1の通信が接続状態でなくなった(すなわち、TCPのコネクションが解除された)と判断してもよい。そのあらかじめ決められた時間は、例えば、30秒であってもよく、それより長い1分や5分、30分などであってもよく、または、30秒より短い10秒などであってもよい。その時間は、ユーザによって手動設定されてもよく、または、定期的に送信されるキープアライブの送信間隔に基づいて自動設定されてもよい。また、第1の判断部43は、第1の通信に関する判断を、上りまたは下りのデータのみを観測することによって行ってもよい。例えば、SYNパケットまたはSYN+ACKパケットの一方が観測された場合に、TCPのコネクションが確立したと判断されてもよく、FINパケットが観測された場合に、TCPのコネクションが終了したと判断されてもよい。

【0029】
第2の判断部44は、光送信部41によって送信されるデータ、及び光受信部42によって受信されるデータの少なくとも一方に応じて、第1のレイヤより上位のレイヤである第2のレイヤにおける第2の通信に関する接続状態について判断する。その判断は、第2の通信が接続状態であるかどうかに関する判断である。なお、その第2の通信では、第1のレイヤにおいて第1の通信以外の通信が行われるものとする。例えば、第1の通信がトランスポート層におけるTCPの通信である場合には、第2の通信はトランスポート層においてUDP(User Datagram Protocol)の通信を行ってもよい。本実施の形態では、第2のレイヤがアプリケーション層であり、第2の通信がUDPを用いるSIPの通信である場合について主に説明するが、第2の通信は、通信の確立と通信の終了とが存在する通信であればよく、SIPの通信に限定されない。また、第2のレイヤは、第1のレイヤよりも上位であれば、アプリケーション層以外であってもよい。

【0030】
第2の通信がSIPである場合には、SIPのセッションが確立している状態が接続状態となる。SIPでは、図8Cで示されるように、通信の確立及び切断が行われる。まず、発呼側は、INVITEメッセージを着呼側に送信する。そのINVITEメッセージの送信に応じて、INVITEを実行中であることを通知する暫定応答である100 Tryingが送信される。そのINVITEメッセージを受信した着呼側は、呼び出し音を鳴らすなどの呼び出し処理を行うと共に、発呼側に呼び出し中であることを通知する暫定応答である180 Ringingを送信する。また、着呼側において、呼び出し音に応じて受話器がオフフックになるなどのユーザの処理があると、それに応じて着呼側から発呼側に200 OKが送信される。発呼側は、その200 OKの受信に応じて、セッションの確立を了解するACKを送信し、その結果、発呼側と着呼側との間にSIPのセッションが確立されることになる。その結果、両者間で音声データ等がやりとりされ、通話状態となる。なお、接続を切断する場合には、例えば、一方のユーザが受話器をオンフックにするなどの処理を行うと、そのユーザ側から、BYEメッセージが相手方に送信される。そして、その相手方が、BYEメッセージの受信に応じて200 OKを送信することによって、SIPのセッションが切断され、通話が終了することになる。なお、図8Cでは、発呼側からBYEメッセージが送信される場合について示しているが、着呼側からBYEメッセージが送信されてもよいことは言うまでもない。

【0031】
第2の判断部44は、例えば、上り送信データや下り受信データを観測し、SIPのセッションの確立処理がUDPによって行われたことを検知した場合に、第2の通信が接続状態になった(すなわち、SIPのセッションが確立した)と判断してもよい。また、第2の判断部44は、例えば、上り送信データや下り受信データを観測し、接続終了の処理が行われたことを検知した場合に、第2の通信が接続状態でなくなった(すなわち、SIPのセッションが切断された)と判断してもよい。また、第2の判断部44は、SIP以外の第2の通信についても、接続状態になったかどうかを判断してもよい。すなわち、第2の判断部44は、1種類の第2の通信について判断を行ってもよく、または複数種類の第2の通信について判断を行ってもよい。また、第2の判断部44は、第2の通信に関する判断を、上りまたは下りのデータのみを観測することによって行ってもよい。例えば、INVITEメッセージが観測された場合、または100 Trying,180 Ringing,200 OKの順番で行われる一連の送信が観測された場合に、SIPのセッションが確立したと判断されてもよく、BYEメッセージが観測された場合、または200 OKが観測された後に、一定期間、何も通信が観測されない場合に、SIPのセッションが終了したと判断されてもよい。

【0032】
スリープ制御部45は、バッファ状況取得部25によって取得されたバッファ状況に応じて、光受信部42を周期的にスリープさせる。すなわち、スリープ制御部45は、バッファ状況が受信に関するスリープ条件を満たす場合に、光受信部42をスリープモード(省電力モード)にすると判断し、受信に関するスリープ条件を満たさない場合に、光受信部42をスリープモードにしないと判断してもよい。また、スリープ制御部45は、バッファ状況取得部25によって取得されたバッファ状況に応じて、光送信部41をスリープさせてもよい。すなわち、スリープ制御部45は、バッファ状況が送信に関するスリープ条件を満たす場合に、光送信部41をスリープモードにすると判断し、送信に関するスリープ条件を満たさない場合に、光送信部41をスリープモードにしないと判断してもよい。光受信部42がスリープモードになるとは、光受信部42が周期的にスリープすることである。OLT1からの下り受信データを、短い遅延によって受信できるようにするためである。一方、光送信部41がスリープモードになるとは、光送信部41が周期的にスリープすることであってもよく、または、周期的ではなくスリープすることであってもよい。光送信部41の場合には、上り送信データの発生に応じて適宜、スリープを解除することができるからである。また、受信に関するスリープ条件と、送信に関するスリープ条件とは、同じであってもよく、または、異なっていてもよい。本実施の形態では、両者が同じであり、スリープ制御部45が、光送信部41と光受信部42とを同時にスリープさせる場合について主に説明する。すなわち、本実施の形態では、周期的なTRxスリープであるサイクリックスリープ(Cyclic Sleep)が行われる場合について主に説明する。なお、光送信部41や光受信部42がスリープするとは、光送信部41や光受信部42への電力供給が停止されることである。そのように電力供給が停止されることによって、消費電力を削減することができる。また、周期的なスリープとは、スリープ状態と、スリープしていない状態であるアクティブ状態とが交互に繰り返されることである。スリープ状態の期間をスリープ期間と呼び、アクティブ状態の期間をアクティブ期間と呼ぶと、周期的なスリープでは、スリープ期間と、アクティブ期間とが交互に繰り返されることになる。なお、スリープ期間の時間的な長さをスリープ時間(Ts)と呼び、アクティブ期間の時間的な長さをアクティブ時間(Ta)と呼び、スリープ時間とアクティブ時間とを足した時間を周期(Tp)と呼ぶことにする。すなわち、Ts+Ta=Tpとなる。なお、周期的なスリープにおいては、周期(Tp)は、一定であってもよく、または、そうでなくてもよい。後者の場合には、アクティブ時間(Ta)が一定であり、スリープ時間(Ts)の変動に応じて周期(Tp)が変化してもよい。

【0033】
次に、スリープ時間を決定する方法について説明する。スリープ制御部45は、第1の判断部43によって第1の通信が接続状態であると判断され、かつ、第2の判断部44によって第2の通信が接続状態でないと判断された場合に、バッファ状況取得部15によって取得されたバッファ状況に応じて、スリープ時間を、第1のスリープ時間(Ts1)以下に決定する。また、スリープ制御部45は、第2の判断部44によって第2の通信が接続状態であると判断された場合に、スリープ時間を、第1のスリープ時間よりも小さい第2のスリープ時間(Ts2)に決定する。また、スリープ制御部45は、第1の判断部43によって第1の通信が接続状態でないと判断され、かつ、第2の判断部44によって第2の通信が接続状態でないと判断された場合に、スリープ時間を、第1のスリープ時間よりも大きい第3のスリープ時間(Ts3)に決定する。なお、第1のスリープ時間Ts1は、例えば、100~800(ms)の範囲に含まれる時間であってもよい。また、第2のスリープ時間Ts2は、例えば、10~100(ms)の範囲に含まれる時間であってもよい。また、第3のスリープ時間は、例えば、800(ms)以上、1(s)未満の範囲に含まれる時間であってもよい。また、周期Tpは、例えば、1(s)であってもよい。なお、第1から第3のスリープ時間や周期は、Ts2<Ts1<Ts3となるのであれば、上述した時間以外であってもよい。ただし、現在のPONの規格では、OLT1とONU2との確実なリンク接続性維持のため、1(s)以上、通信トラフィックがない場合には、回線接続断となるため、周期Tpを、1(s)以下とし、その周期内に含まれるアクティブ期間に少なくとも通信が行われるようにすることが好適である。なお、その回線接続断となる時間に関する国際標準規格が改訂された場合や、その時間が運用上で拡大可能となる場合は、1(s)を超える周期Tpとしてもよいことは言うまでもない。また、前述のように、アクティブ時間Taを一定として、Ta+Tsが変化するようにしてもよいが、その場合であっても、スリープ時間Tsが変化しない期間においては、周期Tp=Ta+Tsは一定となる。また、第1及び第2のスリープ時間は、固定値であってもよく、または、そうでなくてもよい。第2のスリープ時間が変化しうる場合については後述する。第3のスリープ時間は、通常、固定値である。

【0034】
ここで、1の判断部43によって第1の通信が接続状態であると判断され、かつ、第2の判断部44によって第2の通信が接続状態でないと判断された場合に、スリープ制御部45がスリープ時間を決定する方法について簡単に説明する。そのような場合に、スリープ制御部45は、例えば、バッファ状況によって示されるデータ到着間隔が短いほど、短いスリープ時間となるように、スリープ時間を決定してもよく、バッファ状況によって示されるバッファ量が多いほど、短いスリープ時間となるように、スリープ時間を決定してもよく、または、その両方の組み合わせであってもよい。なお、いずれの場合であっても、前述のように、スリープ制御部45が決定するスリープ時間は、第1のスリープ時間以下であるとする。なお、そのスリープ時間に0より大きい下限値が設定されていてもよく、または、そうでなくてもよい。後者の場合には、下限値が0であると考えてもよい。

【0035】
なお、スリープ制御部45は、光受信部42をスリープさせる場合に、スリープ申請を光送信部41によってOLT1に送信し、そのスリープ申請の送信に応じてOLT1から送信されたスリープ許可が、光受信部42によって受信されたときに、光受信部42をスリープモードに移行させてもよい。なお、そのスリープ申請には、決定されたスリープ時間が含まれていてもよい。また、スリープ許可には、最終的に設定されるスリープ時間が含まれていてもよい。スリープ許可にスリープ時間が含まれている場合には、スリープ制御部45は、そのスリープ許可に含まれるスリープ時間を用いて、スリープの制御を行ってもよい。すなわち、そのスリープ許可に含まれるスリープ時間に応じたスリープ期間と、アクティブ期間とが繰り返されるようにスリープの制御が行われてもよい。そのスリープ許可に含まれるスリープ時間は、スリープ申請に含まれるスリープ時間と同じであってもよく、異なっていてもよい。後者の場合には、通常、スリープ許可に含まれるスリープ時間は、スリープ申請に含まれるスリープ時間よりも短いことになる。ONU2で決定されたスリープ時間と、OLT1で決定されたスリープ時間とのうち、短い方のスリープ時間を採用することが好適だからである。なお、スリープ許可にスリープ時間が含まれていない場合には、スリープ制御部45は、自らが決定したスリープ時間を用いてスリープの制御を行ってもよい。一方、そのスリープ申請の送信に応じてOLT1からスリープ許可が送信されなかった場合、または、OLT1から送信されたスリープ不許可が、光受信部42によって受信された場合に、スリープ制御部45は、光受信部42等をスリープモードに移行させなくてもよい。なお、スリープモードへの移行後、スリープ制御部45は、設定されたスリープ時間ごとのスリープが繰り返されるように、光送受信部23への電力供給を制御する。また、スリープモードにおいて、ONU2がアクティブ期間であることをOLT1に通知するため、例えば、ONU2は、アクティブ期間の開始時に、アクティブ期間となった旨をOLT1に送信してもよく、または、そうでなくてもよい。

【0036】
インターフェース27は、下流側の装置やネットワークとのインターフェース機能を実現するものである。なお、下流側の装置等が複数存在する場合に、複数のインターフェース27が存在してもよい。

【0037】
ここで、スリープ条件について説明する。そのスリープ条件は、例えば、バッファ量が、バッファ量の閾値より少ないことであってもよく、データ到着間隔が、到着間隔の閾値より大きいことであってもよく、または、その両方であってもよい。なお、バッファ量が閾値と等しい場合に、閾値より少ないと判断されてもよく、またはそうでなくてもよい。また、データ到着間隔が閾値と等しい場合に、閾値より大きいと判断されてもよく、またはそうでなくてもよい。後述するOLT1で行われる閾値との比較でも同様であるとする。そのバッファ量の閾値は、例えば、あらかじめ決められた値であってもよく、または、スリープ時間に応じた値であってもよい。前者の場合に、その閾値は、0であってもよい。その場合には、バッファされている上り送信データのないことがスリープモードに移行する必要条件となる。なお、その後者の場合について説明する。周期的なスリープの周期をTp(s)とし、スリープ時間をTs(s)とし、アクティブ期間におけるデータの送信レートをR1(b/s)とすると、1周期に送信できるデータ量(bit)は、(Tp-Ts)×R1となる。そして、スリープ制御部45は、スリープモードに移行した場合のスリープ時間Tsを用いて、そのデータ量(Tp-Ts)×R1を算出し、バッファ量の閾値としてもよい。バッファ量が、その閾値以下であれば、バッファリングされている上り送信データを一回のアクティブ期間で送信できるため、スリープしても問題ないと考えられるからである。なお、送信レートR1は、あらかじめ設定されていてもよく、または、測定されてもよい。また、データの到着間隔の閾値は、例えば、あらかじめ決められた値であってもよく、または、スリープ時間に応じた値であってもよい。後者の場合に、スリープ時間が長いほど、到着間隔の閾値も長く設定されてもよい。その場合に、到着間隔の閾値は、例えば、スリープ時間を引数とする増加関数を用いて算出されてもよく、スリープ時間と閾値とを対応付けるテーブル等を用いて特定されてもよい。また、スリープ条件を満たすかどうかの判断で用いられるバッファ状況は、例えば、あらかじめ決められた時間に対応する情報であってもよく、または、スリープ時間に応じた時間に対応する情報であってもよい。後者の場合には、例えば、スリープ時間が長い場合には、より長い時間に応じたバッファ状況を用いて判断が行われてもよい。例えば、スリープ時間がTs2である場合には、1秒間のバッファ状況に応じて判断が行われ、スリープ時間がTs3である場合には、50秒間のバッファ状況に応じて判断が行われてもよい。そのように、異なる時間に応じたバッファ状況が用いられる場合には、バッファ状況取得部15は、それらの異なる時間に応じたバッファ状況を取得することができる情報(例えば、1秒ごとのバッファ状況など)をあらかじめ取得しておき、その情報を用いて、所望の時間に応じたバッファ状況を取得してもよい。また、スリープ条件の判断等において、スリープ時間が必要である場合には、その時点でスリープモードに移行した場合のスリープ時間が用いられてもよい。そのスリープ時間の算出方法は、上述の通りである。なお、ONU2が用いるスリープ条件の一例について説明したが、スリープ条件は、上述の説明以外のものであってもよいことは言うまでもない。例えば、すでに公知であるスリープ条件が用いられてもよい。

【0038】
次に、OLT1で用いられるスリープ条件、及びOLT1で算出されるスリープ時間について説明する。そのスリープ条件は、ONU2の場合と同様に、例えば、バッファ量が、バッファ量の閾値より少ないことであってもよく、データ到着間隔が、到着間隔の閾値より大きいことであってもよく、または、その両方であってもよい。そのバッファ量の閾値が、例えば、あらかじめ決められた値でもよく、またはスリープ時間に応じた値でもよいことも、ONU2の場合と同様である。なお、バッファ量の閾値は、(Tp-Ts)×R2で算出されてもよい。そのR2は、アクティブ期間における、OLT1からONU2への送信レート(b/s)である。また、到着間隔の閾値は、ONU2の場合と同様であってもよい。また、スリープ時間Tsとしては、スリープ申請に含まれるスリープ時間を用いてもよい。なお、スリープ判断部33は、スリープ申請に含まれるスリープ時間を用いてスリープ条件が満たされないと判断した場合に、スリープ条件を満たすスリープ時間が存在するかどうか判断してもよい。そして、スリープ条件を満たすスリープ時間が存在する場合に、スリープ条件が満たされると判断してもよい。例えば、データの到達間隔に関する条件は満たされており、バッファ量に関する条件が満たされていなかったとする。そのバッファ量をB(bit)とすると、B/R2が周期Tpより短いのであれば、スリープ時間を短くすることによって、バッファ量に関する条件を満たすことができるようになる。したがって、B/R2<Tpが満たされる場合には、スリープ判断部33は、スリープ条件が満たされると判断してもよい。そして、スリープ判断部33は、スリープ申請に含まれていたスリープ時間がTp-B/R2以上である場合には、スリープ時間を、そのスリープ申請に含まれていたスリープ時間に決定し、そうでない場合には、スリープ時間を、Tp-B/R2以下のスリープ時間に決定してもよい。そして、その決定されたスリープ時間を含むスリープ許可がONU2に送信されるようにしてもよい。一方、B/R2<Tpが満たされない場合には、スリープ判断部33は、スリープ不許可が送信されるように制御し、ONU2がスリープモードに移行しないようにしてもよい。ここで、B/R2<Tpが満たされるかどうか判断することは、バッファ量がTp×R2未満であるかどうか判断することと同じである。なお、OLT1が用いるスリープ条件の一例について説明したが、スリープ条件は、上述の説明以外のものであってもよいことは言うまでもない。例えば、すでに公知であるスリープ条件が用いられてもよい。

【0039】
また、PONシステムにおいて送受信されるデータは、通常、フレームである。したがって、上述の送信データや受信データは、送信フレームや受信フレームであると考えてもよい。なお、フレーム以外のデータが送受信されてもよい。

【0040】
次に、第1及び第2の通信の関係、及び第1及び第2の通信の接続状態とスリープ時間との関係について、図6,図7を用いて説明する。OLT1とONU2との間で、セッションやコネクション等の通信が接続状態である場合には、仮にデータの送受信がなされていない状況であったとしても、その後、データが送受信される可能性が高いため、リアルタイム性を確保する観点から、スリープ時間をあまり大きくしないことが好適である。また、通信が接続状態であるかどうかを判断する際に、下位レイヤの第1の通信で判断すれば、より多くの通信をカバーできることになる。例えば、図6で示されるように、TCPの通信が接続状態であるかどうかを判断することによって、HTTP(Hypertext Transfer Protocol)やFTP(File Transfer Protocol)等の通信をカバーできることになる。一方、第1の通信の接続状態のみを判断する場合には、UDPの通信が漏れてしまうことになる。したがって、本実施の形態では、UDPの通信に関しては、上位レイヤのSIPや、テレビ会議等のセッションを確立するその他の通信等によって個別に判断することになる。なお、例えば、SIPは、その規格上、TCPでも通信できるが、TCPによるSIPが行われた場合には、第1の通信に含まれることになる。また、SIPやテレビ会議等がTCPでなくUDPを用いて通信する主な理由は、リアルタイム性を向上させることにある。したがって、通常、第2の通信の方が第1の通信よりもリアルタイム性の要求が高いと考えることができるため、図7で示されるように、第2の通信が接続状態である場合には、スリープ時間は、最も短い第2のスリープ時間に設定される。また、第2の通信が行われていないが、第1の通信が行われている状況として、例えば、ユーザがウェブサイトの閲覧を行っており、HTTPの通信が行われている場合が考えられる。そのような場合に、ユーザが頻繁に閲覧先を変更しているときには、応答性のよい方がユーザの体感品質が高くなると考えられる。一方、ユーザがあまり閲覧先を変更しないときには、応答性がよくなくても、ユーザの体感品質が低くならないと考えられる。したがって、第2の通信が行われていないが、第1の通信が行われている状況では、バッファ状況に応じて、第1のスリープ時間以下となるようにスリープ時間を制御することによって、ユーザの体感品質を損なわない範囲で、消費電力の抑制効果を高めることができうる。なお、バッファ状況に応じてスリープ時間を制御するとは、バッファ状況によって、通信がより頻繁であることが示されるほど、短いスリープ時間となるように制御し、通信が頻繁でない(疎である)ことが示されるほど、長いスリープ時間となるように制御することであってもよい。一方、第1及び第2の通信が接続状態でない場合には、OLT1とONU2との間で、セッションやコネクション等の通信が接続状態でないことになるため、データの送受信がないときには、ユーザが外出中や就寝中であるといったように、実質的に通信がなされていない状況であると考えることができる。したがって、そのような状況におけるスリープモードでは、スリープ時間は、最も長い第3のスリープ時間に設定され、消費電力がより低減されることになる。このようにして、通信の状況に応じて、リアルタイム性の確保と、消費電力の低減とのそれぞれを適切に実現することができる。

【0041】
次に、OLT1の動作について図4のフローチャートを用いて説明する。なお、図4のフローチャートは、スリープ制御に関するOLT1の処理を示すものであり、OLT1とONU2との間での光通信に関する処理は、このフローチャートで示される処理とは別に行われるものとする。

【0042】
(ステップS101)バッファ状況取得部15は、バッファ状況を取得するタイミングであるかどうか判断する。そして、バッファ状況を取得するタイミングである場合には、ステップS102に進み、そうでない場合には、ステップS106に進む。なお、バッファ状況取得部15は、例えば、バッファ状況を取得するタイミングであると定期的に判断してもよい。

【0043】
(ステップS102)バッファ状況取得部15は、ONU2ごとのバッファ状況を取得する。

【0044】
(ステップS103)スリープ判断部33は、現在、スリープモードであるONU2が存在するかどうか判断する。そして、存在する場合には、ステップS104に進み、そうでない場合には、ステップS101に戻る。なお、このステップの判断において、OLT1で管理されている、各ONU2がスリープモードであるかどうかを示す情報が用いられてもよい。

【0045】
(ステップS104)スリープ判断部33は、現在、スリープモードであるONU2に関してスリープ条件が満たされているかどうかを、ステップS102で取得されたバッファ状況を用いて判断する。そして、スリープ条件が満たされている場合には、ステップS101に戻り、スリープ条件が満たされていない場合には、ステップS105に進む。

【0046】
(ステップS105)スリープ判断部33は、スリープ条件が満たされていないと判断したONU2について、スリープ解除指示(ウェイクアップ指示)が送信されるように制御する。なお、そのスリープ解除指示は、スリープモードのONU2がアクティブ期間となったときに光送信部31を介して送信されることになる。

【0047】
なお、ステップS103において、2以上のONU2がスリープモードであると判断された場合には、各ONU2について、ステップS104,S105の処理が行われるものとする。

【0048】
(ステップS106)スリープ判断部33は、ONU2から送信されたスリープ申請が光受信部32で受信されたかどうか判断する。そして、スリープ申請が受信された場合には、ステップS107に進み、そうでない場合には、ステップS101に戻る。

【0049】
(ステップS107)スリープ判断部33は、スリープ申請を送信したONU2に関する最新のバッファ状況を用いて、そのONU2がスリープ条件を満たしているかどうか判断する。そして、スリープ条件を満たしている場合には、ステップS108に進み、スリープ条件を満たしていない場合には、ステップS111に進む。例えば、上述の説明のように、スリープ判断部33は、B/R2<Tpが満たされない場合に、スリープ条件が満たされていないと判断してもよい。

【0050】
(ステップS108)スリープ判断部33は、スリープ申請に含まれていたスリープ時間が適切であるかどうかについて、スリープ申請を送信したONU2に関する最新のバッファ状況を用いて判断する。そして、適切である場合には、ステップS109に進み、適切でない場合には、ステップS110に進む。例えば、上述の説明のように、スリープ判断部33は、最新のバッファ状況の示すバッファ量が(Tp-Ts)×R2以下でない場合に、スリープ時間が適切でないと判断してもよい。

【0051】
(ステップS109)スリープ判断部33は、スリープ申請を送信したONU2に、スリープモードへの移行を許可するスリープ許可が送信されるように制御する。なお、そのスリープ許可には、スリープ時間が含まれていなくてもよく、または、スリープ申請に含まれていたスリープ時間が含まれていてもよい。そして、ステップS101に戻る。

【0052】
(ステップS110)スリープ判断部33は、スリープ申請を送信したONU2に、スリープモードへの移行を許可するスリープ許可が送信されるように制御する。なお、そのスリープ許可には、スリープ申請を送信したONU2に関する最新のバッファ状況を用いて決定されたスリープ時間が含まれているものとする。そのスリープ時間は、通常、スリープ申請に含まれていたスリープ時間より短いものである。そして、ステップS101に戻る。例えば、上述の説明のように、スリープ判断部33は、スリープ時間をTp-B/R2に決定してもよい。

【0053】
(ステップS111)スリープ判断部33は、スリープ申請を送信したONU2に、スリープモードへの移行を許可しないスリープ不許可が送信されるように制御する。そして、ステップS101に戻る。

【0054】
なお、図4のフローチャートにおいて、スリープを許可しない場合に、スリープ不許可を送信しないようにしてもよい。また、図4のフローチャートにおける処理の順序は一例であり、同様の結果を得られるのであれば、各ステップの順序を変更してもよい。また、図4のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

【0055】
次に、ONU2の動作について図5のフローチャートを用いて説明する。なお、図5のフローチャートは、スリープ制御に関するONU2の処理を示すものであり、OLT1とONU2との間での光通信に関する処理や、設定されたスリープ時間に応じたスリープ制御の処理は、このフローチャートで示される処理とは別に行われるものとする。

【0056】
(ステップS201)バッファ状況取得部25は、バッファ状況を取得するタイミングであるかどうか判断する。そして、バッファ状況を取得するタイミングである場合には、ステップS202に進み、そうでない場合には、ステップS216に進む。なお、バッファ状況取得部25は、例えば、バッファ状況を取得するタイミングであると定期的に判断してもよい。

【0057】
(ステップS202)バッファ状況取得部25は、バッファ状況を取得する。

【0058】
(ステップS203)スリープ制御部45は、ステップS202で取得されたバッファ状況を用いて、スリープ条件が満たされているかどうか判断する。そして、スリープ条件が満たされている場合には、ステップS204に進み、スリープ条件が満たされていない場合には、ステップS214に進む。

【0059】
(ステップS204)スリープ制御部45は、第2の通信が接続状態であるかどうかについて、第2の判断部44による最新の判断結果を用いて判断する。そして、接続状態である場合には、ステップS205に進み、そうでない場合には、ステップS211に進む。

【0060】
(ステップS205)スリープ制御部45は、スリープ時間を第2のスリープ時間に決定する。

【0061】
(ステップS206)スリープ制御部45は、スリープ申請を送信するかどうか判断する。そして、スリープ申請を送信する場合には、ステップS207に進み、そうでない場合には、ステップS201に戻る。なお、スリープ制御部45は、例えば、ONU2が現在、スリープモードでない場合には、スリープ申請を送信すると判断してもよい。また、スリープ制御部45は、例えば、ONU2が現在、スリープモードであり、ステップS205等において決定されたスリープ時間が、現在のスリープモードのスリープ時間と異なる場合に、スリープ申請を送信すると判断してもよい。決定されたスリープ時間が、現在のスリープ時間と同じである場合には、スリープ申請を送信しないと判断してもよい。

【0062】
(ステップS207)スリープ制御部45は、ステップS205等で決定されたスリープ時間を含むスリープ申請がOLT1に送信されるように制御する。そのスリープ申請は、ONU2がOLT1への送信を行うことができるタイミングで送信されることになる。

【0063】
(ステップS208)スリープ制御部45は、OLT1から送信されたスリープ許可が光受信部42で受信されたかどうか判断する。そして、スリープ許可が受信された場合には、ステップS209に進み、そうでない場合には、ステップS210に進む。

【0064】
(ステップS209)スリープ許可にスリープ時間が含まれない場合、または、スリープ申請に含まれていたスリープ時間がスリープ許可に含まれている場合には、スリープ制御部45は、ONU2で決定したスリープ時間のスリープモードとなるように設定する。一方、スリープ申請に含まれていたスリープ時間と異なるスリープ時間がスリープ許可に含まれている場合には、スリープ制御部45は、そのスリープ許可に含まれているスリープ時間のスリープモードとなるように設定する。その後、その設定されたスリープ時間を用いた周期的なスリープが行われることになる。そして、ステップS201に戻る。

【0065】
(ステップS210)スリープ制御部45は、OLT1から送信されたスリープ不許可が光受信部42で受信されたかどうか判断する。そして、スリープ不許可が受信された場合には、ステップS201に戻り、そうでない場合には、ステップS208に戻る。

【0066】
(ステップS211)スリープ制御部45は、第1の通信が接続状態であるかどうかについて、第1の判断部43による最新の判断結果を用いて判断する。そして、接続状態である場合には、ステップS212に進み、そうでない場合には、ステップS213に進む。

【0067】
(ステップS212)スリープ制御部45は、最新のバッファ状況に応じて、スリープ時間が第1のスリープ時間以下となるように決定する。

【0068】
(ステップS213)スリープ制御部45は、スリープ時間を第3のスリープ時間に決定する。

【0069】
(ステップS214)スリープ制御部45は、ONU2がスリープモードであるかどうか判断する。そして、スリープモードである場合には、ステップS215に進み、そうでない場合には、ステップS201に戻る。

【0070】
(ステップS215)スリープ制御部45は、スリープモードを解除する。なお、スリープモードが解除されたことは、OLT1に通知されることになる。

【0071】
(ステップS216)スリープ制御部45は、第1及び第2の判断部43,44による判断を行うタイミングであるかどうか判断する。そして、その判断のタイミングである場合には、ステップS217に進み、そうでない場合には、ステップS218に進む。なお、スリープ制御部45は、例えば、判断を行うタイミングであると定期的に判断してもよい。

【0072】
(ステップS217)第1の判断部43は、第1の通信が接続状態であるかどうかを判断する。また、第2の判断部44は、第2の通信が接続状態であるかどうかを判断する。なお、第2の通信が複数存在する場合には、第2の判断部44は、各通信について判断を行ってもよい。そして、ステップS201に戻る。

【0073】
(ステップS218)スリープ制御部45は、OLT1から送信されたスリープ解除指示が光受信部42で受信されたかどうか判断する。そして、スリープ解除指示が受信された場合には、ステップS219に進み、そうでない場合には、ステップS201に戻る。

【0074】
(ステップS219)スリープ制御部45は、スリープモードを解除する。そして、ステップS201に戻る。

【0075】
なお、ONU2がスリープ中に、そのONU2のスリープ条件が満たされなくなったとOLT1が判断した場合には、OLT1からONU2にスリープ解除指示が送信されるため、図5のフローチャートにおいて、ONU2がスリープ中にスリープ不許可を受信することはないと考えられるが、仮にそのようなスリープ不許可の受信があった場合には、ステップS210でYESと判断された後に、スリープモードが解除されてもよい。また、ステップS210においてスリープ不許可が受信されてからあらかじめ決められた期間は、ステップS203において、スリープ条件を満たすと判断しないようにしてもよい。OLT1における下り送信データについてスリープ条件が満たされておらず、ONU2における上り送信データについてスリープ条件が満たされている場合に、短期間にスリープ申請の送信と、スリープ不許可の受信とが繰り返される事態を回避するためである。また、図5のフローチャートにおける処理の順序は一例であり、同様の結果を得られるのであれば、各ステップの順序を変更してもよい。また、図5のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。

【0076】
また、スリープ時間を決定する以外の処理、例えば、OLT1がONU2のスリープのタイミングを知る処理や、OLT1がONU2のスリープのタイミングを変更する処理等についてはすでに公知であり(例えば、上記特許文献1を参照されたい)、その詳細な説明を省略する。

【0077】
次に、本実施の形態による受動光ネットワークシステムの動作について、具体例を用いて説明する。この具体例では、第1の通信がTCPの通信であり、第2の通信がSIPを用いた通話であるとする。また、この具体例では、第1から第3のスリープ時間Ts1~Ts3、アクティブ時間Taが次のように設定されているものとする。また、周期Tpはスリープ時間に応じて異なる値をとり、Ts+Taとなるものとする。なお、このようにアクティブ時間Taを短い一定の時間とすることにより、スリープ時間が長い場合にはアクティブ時間の割合が短くなり、結果として消費電力をより低減することができる。一方、スリープ時間が短い場合には、それに応じてアクティブ時間の割合が大きくなるため、それだけ多くのデータを通信できるようになる。したがって、スリープ時間を制御するだけで、省電力の程度や、通信できるデータ量をコントロールできることになる。
第1のスリープ時間Ts1:200(ms)
第2のスリープ時間Ts2:50(ms)
第3のスリープ時間Ts3:900(ms)
アクティブ時間Ta:20(ms)

【0078】
ONU2-1の下流側の装置を操作しているユーザが、デジタルカメラで撮影した複数の画像をクラウドにアップロードしていたとする。その場合には、ONU2-1の上り送信フレームが多いため、スリープモードへの移行は行われない(ステップS201~S203,S214)。その後、画像のアップロードが終了し、ユーザがブラウザを起動してウェブサイトの閲覧を開始したとする。すると、第1の判断部43は、TCPの3ウェイ・ハンドシェイクを検知し、TCPが接続状態になったと判断する(ステップS216,S217)。なお、この時点では、SIPの通話の開始は検知されていないものとする。また、ユーザは、あるウェブサイトに記載された文書をじっくり読んでいたとする。その後、バッファ状況取得部25によって送信バッファ21のバッファ状況が取得されたタイミングにおいて、上り送信フレームの送信間隔が大きく、バッファ量も少ないため、スリープ制御部45によって、スリープ条件が満たされると判断されたとする(ステップS201~S203)。また、スリープ制御部45は、SIPの通話は行われておらず、TCPの通信は行われているため、バッファ状況に応じて、スリープ時間Tsを第1のスリープ時間「200(ms)」に決定する(ステップS204,S211,S212)。そして、そのスリープ時間Tsを含むスリープ申請が、OLT1に送信されることになる(ステップS206,S207)。

【0079】
そのスリープ申請は、OLT1の光受信部32で受信され、スリープ判断部33に渡される(ステップS106)。スリープ判断部33は、そのスリープ申請を受け取ると、スリープ時間「200(ms)」を用いて、スリープ条件が満たされるかどうか判断する(ステップS107)。この場合には、下り送信フレームもほとんどないため、スリープ時間を変更することなく、その条件が満たされたとする(ステップS108)。すると、OLT1からONU2-1に、スリープ時間「200(ms)」を含むスリープ許可が送信される(ステップS109)。

【0080】
そのスリープ許可は、ONU2-1の光受信部42で受信され、スリープ制御部45に渡される(ステップS208)。スリープ制御部45は、そのスリープ許可を受け取ると、そのスリープ許可に含まれているスリープ時間「200(ms)」を用いた周期的なスリープが行われるように、スリープモードの設定を行う(ステップS209)。そのようにして、200(ms)のスリープ期間と、20(ms)のアクティブ期間とを繰り返す周期的なスリープが行われることになる。

【0081】
その後、ユーザが、調べ物をするため、ウェブサイトのリンク先を高い頻度でクリックしたとする。ただし、その状況においても、スリープ条件は満たされていたとする。すると、スリープ制御部45は、上り送信フレームの到着間隔に応じて、スリープ時間Tsを、第1のスリープ時間Ts1以下の100(ms)に決定したとする(ステップS201~S204,S211,S212)。そして、再度、スリープ申請の送信が行われる(ステップS206,S207)。この場合にも、OLT1からスリープ時間「100(ms)」を含むスリープ許可が送信されたとすると、それに応じて、スリープ時間が100(ms)に短縮されることになる(ステップS208,S209)。なお、そのようにスリープ時間が短縮されることによって、ユーザによるリンク先のクリックに対する応答性が向上することになり、ユーザの体感品質が高められることになる。

【0082】
次に、他のユーザによってSIPの通話が開始され、ONU2-1のユーザが、それに応答したとする。すると、下り送信フレームが多くなるため、OLT1からONU2-1にスリープ解除指示が送信され(ステップS101~S105)、それに応じて、ONU2-1におけるスリープが解除される(ステップS218,S219)。また、第2の判断部44によって、SIPの通話が接続状態になったと判断される(ステップS216,S217)。その後、その通話において、両者が黙っている期間があり、その間は、音声データの送受信が行われず、スリープ条件が満たされたとする(ステップS201~S203)。この場合には、SIPの通話が接続状態であるため、スリープ制御部45は、スリープ時間Tsを第2のスリープ時間「50(ms)」に決定し、そのスリープ時間を含むスリープ申請をOLT1に送信する(ステップS204~S207)。この場合にも、OLT1からスリープ時間「50(ms)」を含むスリープ許可が送信されたとすると、スリープ制御部45は、そのスリープ時間を用いた周期的なスリープが行われるように、スリープモードの設定を行う(ステップS208,S209)。そのため、短期間のスリープを繰り返すことによって消費電力を削減しながらも、会話が再開されたときに大きな遅延を生じることがないようにすることができる。なお、会話が再開されたときには、スリープ条件が満たされなくなり、スリープが解除されることになる(ステップS201~S203,S214,S215)。なお、そのスリープの解除は、OLT1からONU2-1にスリープ解除指示が送信されることによって行われてもよい。

【0083】
その後、ユーザがSIPの通話もウェブサイトの閲覧も終了し、就寝したとする。すると、第1の判断部43は、TCPの通信が接続状態でなくなったと判断し、また第2の判断部44は、SIPの通話が接続状態でなくなったと判断する(ステップS216,S217)。そして、スリープ条件が満たされた後に、スリープ時間Tsが第3のスリープ時間「900(ms)」に決定される(ステップS201~S204,S211,S213)。また、そのスリープ時間を含むスリープ申請がOLT1に送信される(ステップS206,S207)。この場合にも、OLT1からスリープ時間「900(ms)」を含むスリープ許可が送信されたとすると、そのスリープ時間「900(ms)」を用いたスリープモードへの移行が行われることになる(ステップS208,S209)。このように、まったく通信が行われない夜間などには、長時間のスリープを実現することができ、省電力の効果が大きくなる。一方、OLT1とONU2-1との間の回線は接続された状態を維持できるため、例えば、他のユーザから、ONU2-1のユーザに対してSIPの発呼が行われた場合であっても、ユーザの端末は、そのINVITEメッセージを受信することができる。なお、そのような長時間のスリープが行われている場合には、発呼への応答が遅くなりうるが、そのような遅延があったとしても、ユーザの体感品質が大きく低下することはないため、特に問題にはならないと考えられる。

【0084】
なお、例えば、第1の通信であるTCPの通信が行われている際に、所定のアプリケーションに応じたセッションの確立に応じてRTP(Real-time Transport Protocol)による通信が行われ、そのRTPの通信が第2の通信に該当する場合には、第2の判断部44によって、第2の通信が開始されたと判断されてもよい。また、そのRTPの通信が終了された場合(例えば、RTCP(Real-time Transport Control Protocol)のBYEメッセージが通信された場合等)には、第2の判断部44によって第2の通信が終了されたと判断されてもよい。

【0085】
以上のように、本実施の形態による受動光ネットワークシステムによれば、通信が接続状態であるかどうかに応じてスリープ時間を決定するため、仮にバッファ量が少なかったとしても、通信が接続中であれば比較的短いスリープ時間が設定されることになる。その結果、接続状態の通信においてデータの送受信が再開された際に、その再開に対する応答性を向上させることができる。その結果、例えば、ユーザの体感品質を向上させることが可能となる。また、そのような通信の接続状態を、下位レイヤの第1の通信で網羅的に把握すると共に、上位レイヤの第2の通信によって個別的にも把握することができ、より抜け落ちが少なくなるように通信の接続状態を把握することができる。また、下位レイヤの通信状態を把握することによって、その下位レイヤの第1の通信を用いる上位レイヤにおける新たな通信規格(プロトコル)による通信が追加されたとしても、その通信規格にも対応することができるようになる。また、スリープ申請をOLT1に送信し、その送信に対応するスリープ許可がOLT1から送信されたことに応じて、ONU2におけるスリープモードへの移行を行うことにより、スリープモードに移行してよいかどうかの判断を、より厳密に行うことができるようになる。

【0086】
なお、本実施の形態では、第2の通信がSIPの通信である場合について主に説明したが、そうでなくてもよいことは言うまでもない。第2の通信は、例えば、トランスポート層においてUDPを用いる、SIP以外のセッション確立プロトコルを用いた通信であってもよい。

【0087】
また、本実施の形態では、ONU2がスリープモードに移行する際に、スリープ申請をOLT1に送信し、その送信に応じてスリープ許可が送信されるとONU2がスリープモードに移行する場合について説明したが、そうでなくてもよい。ONU2においてスリープ条件が満たされた場合には、OLT1における判断に関係なく、そのONU2は、スリープモードに移行するようにしてもよい。その場合であっても、OLT1が、スリープモードに移行したONU2のアクティブ期間を知ることができるようにするため、スリープモードに移行した旨が、ONU2からOLT1に送信されることが好適である。そのスリープモードに移行した旨には、スリープ時間も含まれていることが好適である。

【0088】
また、本実施の形態では、ONU2において、光送信部41と光受信部42とを同じタイミングで周期的にスリープさせるサイクリックスリープを行う場合について説明したが、そうでなくてもよい。例えば、光受信部42については、上述のように、周期的なスリープを行い、光送信部41については、バッファ状況に応じてスリープさせてもよい。すなわち、スリープ制御部45は、バッファ状況取得部25によって取得されたバッファ状況によって、上り送信データのないことが示される場合に、光送信部41をスリープさせ、上り送信データが生じた場合には、光送信部41のスリープを解除して、その送信を行うようにしてもよい。その場合には、光送信部41について周期的にアクティブ期間を設ける必要もないため、スリープ期間を最大限に長くすることができ、消費電力削減の効果が大きくなる。なお、上り送信データが生じた後であっても、すぐに上りの送信を行うことができない場合もある。すなわち、OLT1によって決められた各ONU2の送信スケジュールによっては、上りの送信を少し待たなくてはならないこともありうる。そのような場合には、例えば、上り送信データが生じた後であっても、実際の送信が可能となるまで、光送信部41のスリープを継続してもよい。なお、光送信部41については、スリープを行わないように制御してもよい。

【0089】
また、本実施の形態において、特定の通信が行われている場合には、スリープ条件が満たされないと判断してもよい。例えば、リアルタイム性の要求されるゲームの通信が行われている場合には、仮にバッファ量が少なかったとしても、スリープしない方がよいこともある。例えば、スリープ時間が50(ms)程度であったとしても、その遅延によってゲームの結果が異なることもあるからである。したがって、リアルタイム性の要求されるゲームの通信が行われる場合には、スリープ制御部45は、スリープ条件が満たされないと判断してもよい。なお、そのようなリアルタイム性の要求されるゲームが行われている場合には、データの送信頻度が高いと考えられる。したがって、スリープ条件におけるデータ到着間隔の閾値を適切に設定することにより、そのようなゲームの通信が行われている場合には、スリープ条件が満たされないように設定してもよい。

【0090】
また、本実施の形態では、第2の通信が、第1のレイヤにおいて第1の通信以外の通信を行う通信であるとしたが、そうでなくてもよい。第2の通信は、第2のレイヤにおける特定の通信であれば、第1のレイヤにおける通信方式は問わなくてもよい。その場合には、例えば、TCPによるSIPの通信も第2の通信であると考えてもよい。そのようにすることで、ある通信が第2の通信かどうかを判断するのに第2のレイヤのみを見ればよくなり、判断処理が簡単になる。一方、第2の通信が、第1のレイヤにおいて第1の通信以外の通信を行う通信である場合には、例えば、TCPのように、UDPと比較して高い応答性の要求されないプロトコルについて、短いスリープ時間を設定することがなくなるため、省電力化の観点からはメリットがありうることになる。

【0091】
また、本実施の形態において、スリープ制御部45は、通信の相手先とのRTT(ラウンドトリップタイム)を用いて、第1の通信が接続状態であり、第2の通信が接続状態でない場合のスリープ時間を決定したり、第2のスリープ時間を決定したりしてもよい。具体的には、スリープ制御部45は、第1の通信や第2の通信のRTTを測定する。その測定は、例えば、TCPコネクション確立のために送受信されるパケットを用いて行われてもよく、その他の送受信(例えば、送信に対してACKが返されるものなど)を用いて行われてもよい。そして、スリープ制御部45は、RTTが大きい場合には、スリープ時間が長くなるように制御し、RTTが小さい場合には、スリープ時間が短くなるように制御してもよい。例えば、RTTが1200(ms)である場合に、スリープ時間を200(ms)から50(ms)に短くしても、ユーザの体感品質は変わらないと考えられる。一方、RTTが200(ms)である場合には、スリープ時間を200(ms)から50(ms)に短くすると、ユーザの体感品質は向上すると考えられる。したがって、上述のようなRTTに応じたスリープ時間の制御を行うことによって、ユーザの体感品質を損なうことなく、スリープ時間を長くすることができ、より消費電力を低減させることができるようになる。なお、そのRTTの計測時にスリープ期間をまたぐことが考えられる。すなわち、あるパケットが送信されてから、それに応じたACKが返ってくるまでに、スリープ期間の入ることがある。その場合には、正確なRTTを計測できないため、スリープ制御部45は、スリープ期間をまたがないRTTを用いて、上述の制御を行うようにしてもよい。

【0092】
また、上記実施の形態において、各処理または各機能は、単一の装置または単一のシステムによって集中処理されることによって実現されてもよく、または、複数の装置または複数のシステムによって分散処理されることによって実現されてもよい。

【0093】
また、上記実施の形態において、各構成要素間で行われる情報の受け渡しは、例えば、その情報の受け渡しを行う2個の構成要素が物理的に異なるものである場合には、一方の構成要素による情報の出力と、他方の構成要素による情報の受け付けとによって行われてもよく、または、その情報の受け渡しを行う2個の構成要素が物理的に同じものである場合には、一方の構成要素に対応する処理のフェーズから、他方の構成要素に対応する処理のフェーズに移ることによって行われてもよい。

【0094】
また、上記実施の形態において、各構成要素が実行する処理に関係する情報、例えば、各構成要素が受け付けたり、取得したり、選択したり、生成したり、送信したり、受信したりした情報や、各構成要素が処理で用いる閾値や数式、アドレス等の情報等は、上記説明で明記していなくても、図示しない記録媒体において、一時的に、または長期にわたって保持されていてもよい。また、その図示しない記録媒体への情報の蓄積を、各構成要素、または、図示しない蓄積部が行ってもよい。また、その図示しない記録媒体からの情報の読み出しを、各構成要素、または、図示しない読み出し部が行ってもよい。

【0095】
また、上記実施の形態において、各構成要素等で用いられる情報、例えば、各構成要素が処理で用いる閾値やアドレス、各種の設定値等の情報がユーザによって変更されてもよい場合には、上記説明で明記していなくても、ユーザが適宜、それらの情報を変更できるようにしてもよく、または、そうでなくてもよい。それらの情報をユーザが変更可能な場合には、その変更は、例えば、ユーザからの変更指示を受け付ける図示しない受付部と、その変更指示に応じて情報を変更する図示しない変更部とによって実現されてもよい。その図示しない受付部による変更指示の受け付けは、例えば、入力デバイスからの受け付けでもよく、通信回線を介して送信された情報の受信でもよく、所定の記録媒体から読み出された情報の受け付けでもよい。

【0096】
また、上記実施の形態において、各構成要素は専用のハードウェアにより構成されてもよく、または、ソフトウェアにより実現可能な構成要素については、プログラムを実行することによって実現されてもよい。例えば、ハードディスクや半導体メモリ等の記録媒体に記録されたソフトウェア・プログラムをCPU等のプログラム実行部が読み出して実行することによって、各構成要素が実現されうる。その実行時に、プログラム実行部は、記憶部や記録媒体にアクセスしながらプログラムを実行してもよい。また、そのプログラムは、サーバなどからダウンロードされることによって実行されてもよく、所定の記録媒体(例えば、光ディスクや磁気ディスク、半導体メモリなど)に記録されたプログラムが読み出されることによって実行されてもよい。また、このプログラムは、プログラムプロダクトを構成するプログラムとして用いられてもよい。また、そのプログラムを実行するコンピュータは、単数であってもよく、複数であってもよい。すなわち、集中処理を行ってもよく、または分散処理を行ってもよい。

【0097】
また、本発明は、以上の実施の形態に限定されることなく、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【産業上の利用可能性】
【0098】
以上より、本発明による子局装置によれば、省電力化とリアルタイム性の確保とのそれぞれを実現できるように周期的なスリープを制御することができるという効果が得られ、PONシステムにおけるONUとして有用である。
【符号の説明】
【0099】
2 ONU(子局装置)
21 送信バッファ
22 受信バッファ
23 光送受信部
25 バッファ状況取得部
26 制御部
41 光送信部
42 光受信部
43 第1の判断部
44 第2の判断部
45 スリープ制御部
図面
【図1】
0
【図2】
1
【図3】
2
【図4】
3
【図5】
4
【図6】
5
【図7】
6
【図8A】
7
【図8B】
8
【図8C】
9