(57)【要約】【課題】省電力化とリアルタイム性の確保のそれぞれを実現できるように周期的なスリープを制御する。【解決手段】ＯＮＵ２は、送信バッファ２１のバッファ状況を取得するバッファ状況取得部２５、下位のレイヤにおける第１の通信に関する接続状態について判断する第１の判断部４３、上位のレイヤにおける第２の通信に関する接続状態について判断する第２の判断部４４、バッファ状況に応じて光受信部４２を周期的にスリープさせるスリープ制御部４５を備え、スリープ制御部４５は、スリープ時間を、第１の通信が接続状態であり、第２の通信が接続状態でなければ、バッファ状況に応じて、第１のスリープ時間以下にし、第２の通信が接続状態であれば、第１のスリープ時間よりも小さい第２のスリープ時間にし、第１及び第２の通信が接続状態でなければ、第１のスリープ時間よりも大きい第３のスリープ時間にする。【選択図】図３
2016140011.tif 000002
【特許請求の範囲】
【請求項１】
親局装置と複数の子局装置とが、スプリッタを有する光通信路により接続された受動光ネットワークシステムにおける子局装置であって、
前記親局装置に送信されるデータがバッファリングされる送信バッファと、
前記送信バッファでバッファリングされているデータを前記親局装置に送信する光送信部と、
前記親局装置から送信されたデータを受信する光受信部と、
前記送信バッファにおけるデータのバッファリングの状況に関するバッファ状況を取得するバッファ状況取得部と、
前記光送信部によって送信されるデータ、及び前記光受信部によって受信されるデータの少なくとも一方に応じて、第１のレイヤにおける第１の通信に関する接続状態について判断する第１の判断部と、
前記光送信部によって送信されるデータ、及び前記光受信部によって受信されるデータの少なくとも一方に応じて、前記第１のレイヤより上位のレイヤである第２のレイヤにおける第２の通信に関する接続状態について判断する第２の判断部と、
前記バッファ状況取得部によって取得されたバッファ状況に応じて、前記光受信部を周期的にスリープさせるスリープ制御部と、を備え、
前記スリープ制御部は、
周期的なスリープにおけるスリープ期間の長さを、前記第１の判断部によって前記第１の通信が接続状態であると判断され、かつ、前記第２の判断部によって前記第２の通信が接続状態でないと判断された場合に、前記バッファ状況取得部によって取得されたバッファ状況に応じて、第１のスリープ時間以下に決定し、前記第２の判断部によって前記第２の通信が接続状態であると判断された場合に、前記第１のスリープ時間よりも小さい第２のスリープ時間に決定し、前記第１の判断部によって前記第１の通信が接続状態でないと判断され、かつ、前記第２の判断部によって前記第２の通信が接続状態でないと判断された場合に、前記第１のスリープ時間よりも大きい第３のスリープ時間に決定する、子局装置。
【請求項２】
前記スリープ制御部は、前記光受信部をスリープさせる場合に、スリープ申請を前記光送信部によって前記親局装置に送信し、当該スリープ申請の送信に応じて前記親局装置から送信されたスリープ許可が、前記光受信部によって受信された場合に、前記光受信部を周期的にスリープさせる、請求項１記載の子局装置。
【請求項３】
前記スリープ制御部は、前記バッファ状況取得部によって取得されたバッファ状況に応じて、前記光送信部をもスリープさせる、請求項１または請求項２記載の子局装置。
【請求項４】
前記スリープ制御部は、前記バッファ状況によって送信対象のデータのないことが示される場合に、前記光送信部をスリープさせる、請求項３記載の子局装置。
【請求項５】
前記バッファ状況は、データ到着間隔及びバッファ量の少なくとも一方である、請求項１から請求項４のいずれか記載の子局装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受動光ネットワークシステムにおける子局装置であって、周期的なスリープ制御を行う子局装置に関する。
【背景技術】
【０００２】
従来、受動光ネットワーク（ＰＯＮ：Passive Optical Network）システムにおいて、子局装置（ＯＮＵ：Optical Network Unit）の消費電力削減が重要な課題となっており、２０１３年には、国際標準規格IEEE1904.1 SIEPON（Service Interoperability in EPON）などにより、基本的な省電力化機能が規定された。
【０００３】
そのような省電力化のため、通信トラフィックがない状態のＯＮＵでは、光送受信器などへの電力供給を休止すること（スリープ）が行われている。そのスリープ中に親局装置（ＯＬＴ：Optical Line Terminal）に到達した下り受信データは、ＯＬＴでバッファされ、アクティブ期間（受信可能期間）となった後に、ＯＬＴからＯＮＵに送信されていた。なお、そのようなスリープ制御において、通信のリアルタイム性を確保するため、短い期間でスリープ期間とアクティブ期間とを周期的に繰り返すことが行われている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１４−５７１９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
サイクリックスリープなどの周期的なスリープにおいて、省電力化のためには、スリープ期間の長さであるスリープ時間を長くすることが求められる。一方、リアルタイム性を高めるためには、アクティブ期間の長さであるアクティブ時間を長くすることが求められる。
【０００６】
本発明は、上述のような状況においてなされたものであり、ＰＯＮシステムにおけるＯＮＵであって、省電力化と、リアルタイム性の確保とのそれぞれを実現できるように周期的なスリープを制御する子局装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上記目的を達成するため、本発明による子局装置は、親局装置と複数の子局装置とが、スプリッタを有する光通信路により接続された受動光ネットワークシステムにおける子局装置であって、親局装置に送信されるデータがバッファリングされる送信バッファと、送信バッファでバッファリングされているデータを親局装置に送信する光送信部と、親局装置から送信されたデータを受信する光受信部と、送信バッファにおけるデータのバッファリングの状況に関するバッファ状況を取得するバッファ状況取得部と、光送信部によって送信されるデータ、及び光受信部によって受信されるデータの少なくとも一方に応じて、第１のレイヤにおける第１の通信に関する接続状態について判断する第１の判断部と、光送信部によって送信されるデータ、及び光受信部によって受信されるデータの少なくとも一方に応じて、第１のレイヤより上位のレイヤである第２のレイヤにおける第２の通信に関する接続状態について判断する第２の判断部と、バッファ状況取得部によって取得されたバッファ状況に応じて、光受信部を周期的にスリープさせるスリープ制御部と、を備え、スリープ制御部は、周期的なスリープにおけるスリープ期間の長さを、第１の判断部によって第１の通信が接続状態であると判断され、かつ、第２の判断部によって第２の通信が接続状態でないと判断された場合に、バッファ状況取得部によって取得されたバッファ状況に応じて、第１のスリープ時間以下に決定し、第２の判断部によって第２の通信が接続状態であると判断された場合に、第１のスリープ時間よりも小さい第２のスリープ時間に決定し、第１の判断部によって第１の通信が接続状態でないと判断され、かつ、第２の判断部によって第２の通信が接続状態でないと判断された場合に、第１のスリープ時間よりも大きい第３のスリープ時間に決定する、ものである。
【０００８】
このような構成により、第１の通信が接続状態（例えば、ＴＣＰ（Transmission Control Protocol）のコネクションが確立されている状態）である場合には、たとえ上り送信データがなかったとしても、ユーザが次の操作を行うことによって上り送信データが発生しうるため、スリープ期間の長さを第１のスリープ時間以下とすることにより、そのような上り送信データの発生等に対する応答性を向上させることができる。また、例えば、第１の通信がトランスポート層の通信である場合には、上位のアプリケーション層における通信に関係なく、第１の通信の接続に応じてスリープ期間の長さを制御できるようになる。そのため、第１のレイヤよりも上位のレイヤにおいて新たな通信規格（プロトコル）による通信が追加されたとしても、その通信が第１の通信によって行われる場合には、その通信に対して適切なスリープ制御を行うことができる。また、第２の通信が接続状態（例えば、ＳＩＰ（Session Initiation Protocol）のセッションが確立されている状態）である場合には、通常、リアルタイム性が要求されると考えられるため、たとえ上り送信データがなかったとしてもスリープ期間の長さを第２のスリープ時間とすることにより、通信の遅延を防止することができる。また、第１及び第２の通信が行われていない場合には、スリープ期間の長さを第３のスリープ時間とすることにより、例えば、夜間や不在時などの通信トラフィックがほとんど発生しない状況において、効果的に省電力化を図ることができるようになる。
【０００９】
また、本発明による子局装置では、スリープ制御部は、光受信部をスリープさせる場合に、スリープ申請を光送信部によって親局装置に送信し、スリープ申請の送信に応じて親局装置から送信されたスリープ許可が、光受信部によって受信された場合に、光受信部を周期的にスリープさせてもよい。
このような構成により、親局装置においてもスリープが許可された場合に周期的なスリープが行われることになり、より確実なスリープ制御を行うことができるようになる。
【００１０】
また、本発明による子局装置では、スリープ制御部は、バッファ状況取得部によって取得されたバッファ状況に応じて、光送信部をもスリープさせてもよい。
このような構成により、光受信部のみでなく、光送信部もスリープ制御の対象とすることができ、子局装置における消費電力をより削減することができるようになる。
【００１１】
また、本発明による子局装置では、スリープ制御部は、バッファ状況によって送信対象のデータのないことが示される場合に、光送信部をスリープさせてもよい。
このような構成により、上り送信データのない状況において、その送信を行う光送信部をスリープさせることになり、上り送信データの送信への影響を低減させながら、省電力化を図ることができるようになる。
【００１２】
また、本発明による子局装置では、バッファ状況は、データ到着間隔及びバッファ量の少なくとも一方であってもよい。
【発明の効果】
【００１３】
本発明による子局装置によれば、省電力化と、リアルタイム性の確保とのそれぞれを実現できるように周期的なスリープを制御することができるようになる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施の形態によるＰＯＮシステムの構成を示すブロック図
【図２】同実施の形態によるＯＬＴの構成を示すブロック図
【図３】同実施の形態によるＯＮＵの構成を示すブロック図
【図４】同実施の形態によるＯＬＴの動作を示すフローチャート
【図５】同実施の形態によるＯＮＵの動作を示すフローチャート
【図６】同実施の形態によるスリープ制御について説明するための図
【図７】同実施の形態によるスリープ時間について説明するための図
【図８Ａ】ＴＣＰの接続開始について説明するための図
【図８Ｂ】ＴＣＰの接続終了について説明するための図
【図８Ｃ】ＳＩＰのセッションの生成及び切断について説明するための図
【発明を実施するための形態】
【００１５】
以下、本発明のＰＯＮシステムについて、実施の形態を用いて説明する。なお、以下の実施の形態において、同じ符号を付した構成要素及びステップは同一または相当するものであり、再度の説明を省略することがある。本実施の形態によるＰＯＮシステムは、ＯＮＵにおいて、周期的なスリープ時間を制御するものである。
【００１６】
図１は、本実施の形態によるＰＯＮシステム（受動光ネットワークシステム）の構成を示すブロック図である。本実施の形態によるＰＯＮシステムは、受動素子であるスプリッタ３を有する光通信路で接続されたＯＬＴ（親局装置）１と複数のＯＮＵ（子局装置）２−１，２−２，…，２−Ｎ（Ｎは２以上の整数である）とを備える。なお、特に区別しなくてよい場合には、ＯＮＵ２−１，２−２，…，２−Ｎを、ＯＮＵ２と呼ぶこともある。また、ＯＬＴ１は、局側光終端装置と呼ばれることもあり、ＯＮＵ２は、加入者側光終端装置と呼ばれることもある。ＯＬＴ１から光ファイバを介して送信された光信号は、スプリッタ３によって分岐され、各ＯＮＵ２に到達する。また、各ＯＮＵ２から光ファイバを介して送信された光信号は、スプリッタ３を経由してＯＬＴ１に到達する。なお、ＯＮＵ２から送信されるデータが、他のＯＮＵ２から送信されるデータと衝突しないようにするため、ＯＬＴ１は各ＯＮＵ２の送信タイミングを制御する。ＯＬＴ１の上流側には、サーバやネットワーク等が接続される。また、ＯＮＵ２の下流側には、ＰＣやその他のユーザ端末等が接続される。
【００１７】
図２は、ＰＯＮシステムにおけるＯＬＴ１の構成を示すブロック図である。図２において、ＯＬＴ１は、送信バッファ１１と、受信バッファ１２と、光送受信部１３と、ＷＤＭ１４と、バッファ状況取得部１５と、制御部１６と、インターフェース１７とを備える。光送受信部１３は、光送信部３１と、光受信部３２とを有している。制御部１６は、スリープ判断部３３を有している。
【００１８】
送信バッファ１１では、ＯＮＵ２に送信される下り送信データが、ＯＮＵ２ごとにバッファリングされる。受信バッファ１２では、ＯＮＵ２から送信された上り受信データがバッファリングされる。光送受信部１３の光送信部３１は、送信バッファ１１でバッファリングされているデータをＯＮＵ２に送信する。その送信において、光送信部３１は、電気信号のデータを光信号に変換して送信する。光送受信部１３の光受信部３２は、ＯＮＵ２から送信されたデータを受信する。その受信において、光受信部３２は、光信号を受信して電気信号のデータに変換する。ＷＤＭ（Wavelength Division Multiplexing）１４は、波長の違う光信号を多重したり分離したりする。光送信部３１からの光信号は、ＷＤＭ１４を介して光ファイバで送信され、光ファイバからの光信号は、ＷＤＭ１４を介して光受信部３２に入力される。
【００１９】
バッファ状況取得部１５は、送信バッファ１１におけるデータのバッファリングの状況に関するバッファ状況を取得する。バッファ状況は、例えば、データ到着間隔及びバッファ量の少なくとも一方であってもよい。バッファ量は、送信バッファ１１に蓄積されたデータ量である。そのバッファ状況は、最新の所定の期間に応じた平均値であってもよい。
【００２０】
制御部１６は、ＰＯＮプロトコルに基づいてＯＬＴ側の制御を行うものであり、スリープ判断部３３を有している。制御部１６は、インターフェース１７を介して受信した下り送信データを送信バッファ１１に蓄積すると共に、そのバッファリングされている下り送信データを読み出して、光送受信部１３を介してＯＮＵ２に送信する。また、制御部１６は、ＯＮＵ２から送信された上り受信データを、光送受信部１３を介して受信し、受信バッファ１２に蓄積すると共に、そのバッファリングされている上り受信データを読み出して、インターフェース１７を介して上流側の装置やネットワークに送信する。また、制御部１６は、各ＯＮＵ２から送信される上りデータが衝突しないように、それらの光通信を制御する。なお、スリープ判断部３３以外の制御部１６の処理については、従来のＰＯＮシステムにおいて公知であり、その詳細な説明を省略する。
【００２１】
スリープ判断部３３は、ＯＬＴ１がＯＮＵ２から送信されたスリープ申請を受信した場合に、そのスリープ申請を送信したＯＮＵ２がスリープしてよいかどうかについて、取得されたバッファ状況を用いて判断する。そして、その判断の結果、スリープしてもよい場合には、スリープ判断部３３は、スリープ申請を送信したＯＮＵ２に、スリープ許可を送信する。一方、その判断の結果、スリープしてはよくない場合には、スリープ判断部３３は、例えば、スリープ申請を送信したＯＮＵ２に、スリープ不許可を送信してもよく、または、何も送信しなくてもよい。また、ＯＮＵ２から送信されたスリープ申請にスリープ時間が含まれていてもよい。そして、スリープ申請にスリープ時間が含まれている場合には、スリープ判断部３３は、バッファ状況を用いて決定したスリープ時間が、スリープ申請に含まれているスリープ時間よりも短いときに、その決定したスリープ時間を含むスリープ許可を送信してもよい。なお、そのスリープ判断部３３の処理の詳細については後述する。
インターフェース１７は、上流側の装置やネットワークとのインターフェース機能を実現するものである。
【００２２】
図３は、ＰＯＮシステムにおけるＯＮＵ２の構成を示すブロック図である。図３において、ＯＮＵ２は、送信バッファ２１と、受信バッファ２２と、光送受信部２３と、ＷＤＭ２４と、バッファ状況取得部２５と、制御部２６と、インターフェース２７とを備える。光送受信部２３は、光送信部４１と、光受信部４２とを有している。制御部２６は、第１の判断部４３と、第２の判断部４４と、スリープ制御部４５とを有している。
【００２３】
送信バッファ２１では、ＯＬＴ１に送信される上り送信データがバッファリングされる。受信バッファ２２では、ＯＬＴ１から送信された下り受信データがバッファリングされる。光送受信部２３の光送信部４１は、送信バッファ２１でバッファリングされているデータをＯＬＴ１に送信する。その送信において、光送信部４１は、電気信号のデータを光信号に変換して送信する。光送受信部２３の光受信部４２は、ＯＬＴ１から送信されたデータを受信する。その受信において、光受信部４２は、光信号を受信して電気信号のデータに変換する。なお、光送受信部２３は、受信した下りデータのうち、自らのＯＮＵ２宛のデータのみを受信し、他のＯＮＵ２宛のデータは破棄する。ＷＤＭ２４は、波長の違う光信号を多重したり分離したりする。光送信部４１からの光信号は、ＷＤＭ２４を介して光ファイバで送信され、光ファイバからの光信号は、ＷＤＭ２４を介して光受信部４２に入力される。
【００２４】
バッファ状況取得部２５は、送信バッファ２１におけるデータのバッファリングの状況に関するバッファ状況を取得する。バッファ状況は、例えば、フレーム到着間隔及びバッファ量の少なくとも一方であってもよい。バッファ量は、送信バッファ２１に蓄積されたデータ量である。そのバッファ状況は、最新の所定の期間に応じた平均値であってもよい。
【００２５】
制御部２６は、ＰＯＮプロトコルに基づいてＯＮＵ側の制御を行うものであり、第１の判断部４３、第２の判断部４４、及びスリープ制御部４５を有している。制御部２６は、インターフェース２７を介して受信した上り送信データを送信バッファ２１に蓄積すると共に、そのバッファリングされている上り送信データを読み出して、光送受信部２３を介してＯＬＴ１に送信する。また、制御部２６は、ＯＬＴ１から送信された下り受信データを、光送受信部２３を介して受信し、受信バッファ２２に蓄積すると共に、そのバッファリングされている下り受信データを読み出して、インターフェース２７を介して下流側の装置やネットワークに送信する。また、制御部２６は、各ＯＮＵ２から送信される上りデータが衝突しないようにするため、ＯＬＴ１からの指示に応じて上り送信データが送信されるように制御する。なお、第１及び第２の判断部４３，４４、並びにスリープ制御部４５以外の制御部２６の処理については、従来のＰＯＮシステムにおいて公知であり、その詳細な説明を省略する。
【００２６】
第１の判断部４３は、光送信部４１によって送信されるデータ、及び光受信部４２によって受信されるデータの少なくとも一方に応じて、第１のレイヤにおける第１の通信に関する接続状態について判断する。その判断は、第１の通信が接続状態であるかどうかに関する判断である。本実施の形態では、第１のレイヤがトランスポート層であり、第１の通信がＴＣＰの通信である場合について主に説明するが、第１の通信は、通信の確立と通信の終了とが存在する通信であればよく、ＴＣＰの通信に限定されない。また、第１のレイヤは、トランスポート層以外であってもよい。
【００２７】
第１の通信がＴＣＰである場合には、ＴＣＰのコネクションが確立している状態が接続状態となる。ＴＣＰでは、図８Ａで示されるように通信の確立が行われる（３ウェイ・ハンドシェイク）。まず、装置ＡがＳＹＮパケットを装置Ｂに送信する。装置Ｂは、そのＳＹＮパケットを受信すると、それに応じてＳＹＮ＋ＡＣＫパケットを装置Ａに送信する。装置Ａは、そのＳＹＮ＋ＡＣＫパケットを受信すると、接続開始を示すＡＣＫパケットを装置Ｂに送信し、装置Ａ，Ｂの間でＴＣＰの通信が行われる。また、ＴＣＰでは、図８Ｂで示されるように通信の終了が行われる。まず、装置Ａから装置Ｂに送信するデータがなくなると、装置ＡはＦＩＮパケットを装置Ｂに送信する。装置Ｂは、そのＦＩＮパケットを受信すると、それに応じてＡＣＫパケットを装置Ａに送信する。その後、装置Ｂから装置Ａに送信するデータもなくなると、装置ＢはＦＩＮパケットを装置Ａに送信する。装置Ａは、そのＦＩＮパケットを受信すると、それに応じてＡＣＫパケットを装置Ｂに送信する。そのようにして、装置Ａ，Ｂの間でのＴＣＰの通信が終了することになる。なお、図８Ｂに示されるようにしてＴＣＰの通信が終了されることもあるが、そうでないこともある。例えば、通信中に装置Ｂの電源が落ちた場合にも通信は終了される。そのような状況であっても、装置Ａは、接続終了の処理を行っていないため、装置Ｂとのコネクションが確立した状態であると判断してしまう。そのため、ＴＣＰでは、キープアライブ（Keep Alive）パケットを定期的に送受信することによって、通信が確立状態であることを確認することもできる。すなわち、装置Ｂの電源が落ちた場合には、装置Ａは、キープアライブパケットが到着しなくなることにより、または、キープアライブパケットに対する応答がないことにより、装置Ｂとのコネクションが終了していることを知ることができる。なお、装置Ｂ側から接続開始の処理が行われてもよく、また装置Ｂ側から接続終了の処理が行われてもよいことは言うまでもない。
【００２８】
第１の判断部４３は、例えば、上り送信データや下り受信データを観測し、３ウェイ・ハンドシェイクの処理が行われたことを検知した場合に、第１の通信が接続状態になった（すなわち、ＴＣＰのコネクションが確立した）と判断してもよい。また、第１の判断部４３は、例えば、上り送信データや下り受信データを観測し、接続終了の処理が行われたことを検知した場合に、第１の通信が接続状態でなくなった（すなわち、ＴＣＰのコネクションが解除された）と判断してもよい。また、第１の判断部４３は、例えば、上り送信データや下り受信データを観測し、第１の通信が接続状態であると判断されている場合に、あらかじめ決められた時間以上、キープアライブの送受信が行われていないときに、第１の通信が接続状態でなくなった（すなわち、ＴＣＰのコネクションが解除された）と判断してもよい。そのあらかじめ決められた時間は、例えば、３０秒であってもよく、それより長い１分や５分、３０分などであってもよく、または、３０秒より短い１０秒などであってもよい。その時間は、ユーザによって手動設定されてもよく、または、定期的に送信されるキープアライブの送信間隔に基づいて自動設定されてもよい。また、第１の判断部４３は、第１の通信に関する判断を、上りまたは下りのデータのみを観測することによって行ってもよい。例えば、ＳＹＮパケットまたはＳＹＮ＋ＡＣＫパケットの一方が観測された場合に、ＴＣＰのコネクションが確立したと判断されてもよく、ＦＩＮパケットが観測された場合に、ＴＣＰのコネクションが終了したと判断されてもよい。
【００２９】
第２の判断部４４は、光送信部４１によって送信されるデータ、及び光受信部４２によって受信されるデータの少なくとも一方に応じて、第１のレイヤより上位のレイヤである第２のレイヤにおける第２の通信に関する接続状態について判断する。その判断は、第２の通信が接続状態であるかどうかに関する判断である。なお、その第２の通信では、第１のレイヤにおいて第１の通信以外の通信が行われるものとする。例えば、第１の通信がトランスポート層におけるＴＣＰの通信である場合には、第２の通信はトランスポート層においてＵＤＰ（User Datagram Protocol）の通信を行ってもよい。本実施の形態では、第２のレイヤがアプリケーション層であり、第２の通信がＵＤＰを用いるＳＩＰの通信である場合について主に説明するが、第２の通信は、通信の確立と通信の終了とが存在する通信であればよく、ＳＩＰの通信に限定されない。また、第２のレイヤは、第１のレイヤよりも上位であれば、アプリケーション層以外であってもよい。
【００３０】
第２の通信がＳＩＰである場合には、ＳＩＰのセッションが確立している状態が接続状態となる。ＳＩＰでは、図８Ｃで示されるように、通信の確立及び切断が行われる。まず、発呼側は、ＩＮＶＩＴＥメッセージを着呼側に送信する。そのＩＮＶＩＴＥメッセージの送信に応じて、ＩＮＶＩＴＥを実行中であることを通知する暫定応答である１００  Ｔｒｙｉｎｇが送信される。そのＩＮＶＩＴＥメッセージを受信した着呼側は、呼び出し音を鳴らすなどの呼び出し処理を行うと共に、発呼側に呼び出し中であることを通知する暫定応答である１８０  Ｒｉｎｇｉｎｇを送信する。また、着呼側において、呼び出し音に応じて受話器がオフフックになるなどのユーザの処理があると、それに応じて着呼側から発呼側に２００  ＯＫが送信される。発呼側は、その２００  ＯＫの受信に応じて、セッションの確立を了解するＡＣＫを送信し、その結果、発呼側と着呼側との間にＳＩＰのセッションが確立されることになる。その結果、両者間で音声データ等がやりとりされ、通話状態となる。なお、接続を切断する場合には、例えば、一方のユーザが受話器をオンフックにするなどの処理を行うと、そのユーザ側から、ＢＹＥメッセージが相手方に送信される。そして、その相手方が、ＢＹＥメッセージの受信に応じて２００  ＯＫを送信することによって、ＳＩＰのセッションが切断され、通話が終了することになる。なお、図８Ｃでは、発呼側からＢＹＥメッセージが送信される場合について示しているが、着呼側からＢＹＥメッセージが送信されてもよいことは言うまでもない。
【００３１】
第２の判断部４４は、例えば、上り送信データや下り受信データを観測し、ＳＩＰのセッションの確立処理がＵＤＰによって行われたことを検知した場合に、第２の通信が接続状態になった（すなわち、ＳＩＰのセッションが確立した）と判断してもよい。また、第２の判断部４４は、例えば、上り送信データや下り受信データを観測し、接続終了の処理が行われたことを検知した場合に、第２の通信が接続状態でなくなった（すなわち、ＳＩＰのセッションが切断された）と判断してもよい。また、第２の判断部４４は、ＳＩＰ以外の第２の通信についても、接続状態になったかどうかを判断してもよい。すなわち、第２の判断部４４は、１種類の第２の通信について判断を行ってもよく、または複数種類の第２の通信について判断を行ってもよい。また、第２の判断部４４は、第２の通信に関する判断を、上りまたは下りのデータのみを観測することによって行ってもよい。例えば、ＩＮＶＩＴＥメッセージが観測された場合、または１００  Ｔｒｙｉｎｇ，１８０  Ｒｉｎｇｉｎｇ，２００  ＯＫの順番で行われる一連の送信が観測された場合に、ＳＩＰのセッションが確立したと判断されてもよく、ＢＹＥメッセージが観測された場合、または２００  ＯＫが観測された後に、一定期間、何も通信が観測されない場合に、ＳＩＰのセッションが終了したと判断されてもよい。
【００３２】
スリープ制御部４５は、バッファ状況取得部２５によって取得されたバッファ状況に応じて、光受信部４２を周期的にスリープさせる。すなわち、スリープ制御部４５は、バッファ状況が受信に関するスリープ条件を満たす場合に、光受信部４２をスリープモード（省電力モード）にすると判断し、受信に関するスリープ条件を満たさない場合に、光受信部４２をスリープモードにしないと判断してもよい。また、スリープ制御部４５は、バッファ状況取得部２５によって取得されたバッファ状況に応じて、光送信部４１をスリープさせてもよい。すなわち、スリープ制御部４５は、バッファ状況が送信に関するスリープ条件を満たす場合に、光送信部４１をスリープモードにすると判断し、送信に関するスリープ条件を満たさない場合に、光送信部４１をスリープモードにしないと判断してもよい。光受信部４２がスリープモードになるとは、光受信部４２が周期的にスリープすることである。ＯＬＴ１からの下り受信データを、短い遅延によって受信できるようにするためである。一方、光送信部４１がスリープモードになるとは、光送信部４１が周期的にスリープすることであってもよく、または、周期的ではなくスリープすることであってもよい。光送信部４１の場合には、上り送信データの発生に応じて適宜、スリープを解除することができるからである。また、受信に関するスリープ条件と、送信に関するスリープ条件とは、同じであってもよく、または、異なっていてもよい。本実施の形態では、両者が同じであり、スリープ制御部４５が、光送信部４１と光受信部４２とを同時にスリープさせる場合について主に説明する。すなわち、本実施の形態では、周期的なＴＲｘスリープであるサイクリックスリープ（Cyclic Sleep）が行われる場合について主に説明する。なお、光送信部４１や光受信部４２がスリープするとは、光送信部４１や光受信部４２への電力供給が停止されることである。そのように電力供給が停止されることによって、消費電力を削減することができる。また、周期的なスリープとは、スリープ状態と、スリープしていない状態であるアクティブ状態とが交互に繰り返されることである。スリープ状態の期間をスリープ期間と呼び、アクティブ状態の期間をアクティブ期間と呼ぶと、周期的なスリープでは、スリープ期間と、アクティブ期間とが交互に繰り返されることになる。なお、スリープ期間の時間的な長さをスリープ時間（Ｔｓ）と呼び、アクティブ期間の時間的な長さをアクティブ時間（Ｔａ）と呼び、スリープ時間とアクティブ時間とを足した時間を周期（Ｔｐ）と呼ぶことにする。すなわち、Ｔｓ＋Ｔａ＝Ｔｐとなる。なお、周期的なスリープにおいては、周期（Ｔｐ）は、一定であってもよく、または、そうでなくてもよい。後者の場合には、アクティブ時間（Ｔａ）が一定であり、スリープ時間（Ｔｓ）の変動に応じて周期（Ｔｐ）が変化してもよい。
【００３３】
次に、スリープ時間を決定する方法について説明する。スリープ制御部４５は、第１の判断部４３によって第１の通信が接続状態であると判断され、かつ、第２の判断部４４によって第２の通信が接続状態でないと判断された場合に、バッファ状況取得部１５によって取得されたバッファ状況に応じて、スリープ時間を、第１のスリープ時間（Ｔｓ１）以下に決定する。また、スリープ制御部４５は、第２の判断部４４によって第２の通信が接続状態であると判断された場合に、スリープ時間を、第１のスリープ時間よりも小さい第２のスリープ時間（Ｔｓ２）に決定する。また、スリープ制御部４５は、第１の判断部４３によって第１の通信が接続状態でないと判断され、かつ、第２の判断部４４によって第２の通信が接続状態でないと判断された場合に、スリープ時間を、第１のスリープ時間よりも大きい第３のスリープ時間（Ｔｓ３）に決定する。なお、第１のスリープ時間Ｔｓ１は、例えば、１００〜８００（ｍｓ）の範囲に含まれる時間であってもよい。また、第２のスリープ時間Ｔｓ２は、例えば、１０〜１００（ｍｓ）の範囲に含まれる時間であってもよい。また、第３のスリープ時間は、例えば、８００（ｍｓ）以上、１（ｓ）未満の範囲に含まれる時間であってもよい。また、周期Ｔｐは、例えば、１（ｓ）であってもよい。なお、第１から第３のスリープ時間や周期は、Ｔｓ２＜Ｔｓ１＜Ｔｓ３となるのであれば、上述した時間以外であってもよい。ただし、現在のＰＯＮの規格では、ＯＬＴ１とＯＮＵ２との確実なリンク接続性維持のため、１（ｓ）以上、通信トラフィックがない場合には、回線接続断となるため、周期Ｔｐを、１（ｓ）以下とし、その周期内に含まれるアクティブ期間に少なくとも通信が行われるようにすることが好適である。なお、その回線接続断となる時間に関する国際標準規格が改訂された場合や、その時間が運用上で拡大可能となる場合は、１（ｓ）を超える周期Ｔｐとしてもよいことは言うまでもない。また、前述のように、アクティブ時間Ｔａを一定として、Ｔａ＋Ｔｓが変化するようにしてもよいが、その場合であっても、スリープ時間Ｔｓが変化しない期間においては、周期Ｔｐ＝Ｔａ＋Ｔｓは一定となる。また、第１及び第２のスリープ時間は、固定値であってもよく、または、そうでなくてもよい。第２のスリープ時間が変化しうる場合については後述する。第３のスリープ時間は、通常、固定値である。
【００３４】
ここで、１の判断部４３によって第１の通信が接続状態であると判断され、かつ、第２の判断部４４によって第２の通信が接続状態でないと判断された場合に、スリープ制御部４５がスリープ時間を決定する方法について簡単に説明する。そのような場合に、スリープ制御部４５は、例えば、バッファ状況によって示されるデータ到着間隔が短いほど、短いスリープ時間となるように、スリープ時間を決定してもよく、バッファ状況によって示されるバッファ量が多いほど、短いスリープ時間となるように、スリープ時間を決定してもよく、または、その両方の組み合わせであってもよい。なお、いずれの場合であっても、前述のように、スリープ制御部４５が決定するスリープ時間は、第１のスリープ時間以下であるとする。なお、そのスリープ時間に０より大きい下限値が設定されていてもよく、または、そうでなくてもよい。後者の場合には、下限値が０であると考えてもよい。
【００３５】
なお、スリープ制御部４５は、光受信部４２をスリープさせる場合に、スリープ申請を光送信部４１によってＯＬＴ１に送信し、そのスリープ申請の送信に応じてＯＬＴ１から送信されたスリープ許可が、光受信部４２によって受信されたときに、光受信部４２をスリープモードに移行させてもよい。なお、そのスリープ申請には、決定されたスリープ時間が含まれていてもよい。また、スリープ許可には、最終的に設定されるスリープ時間が含まれていてもよい。スリープ許可にスリープ時間が含まれている場合には、スリープ制御部４５は、そのスリープ許可に含まれるスリープ時間を用いて、スリープの制御を行ってもよい。すなわち、そのスリープ許可に含まれるスリープ時間に応じたスリープ期間と、アクティブ期間とが繰り返されるようにスリープの制御が行われてもよい。そのスリープ許可に含まれるスリープ時間は、スリープ申請に含まれるスリープ時間と同じであってもよく、異なっていてもよい。後者の場合には、通常、スリープ許可に含まれるスリープ時間は、スリープ申請に含まれるスリープ時間よりも短いことになる。ＯＮＵ２で決定されたスリープ時間と、ＯＬＴ１で決定されたスリープ時間とのうち、短い方のスリープ時間を採用することが好適だからである。なお、スリープ許可にスリープ時間が含まれていない場合には、スリープ制御部４５は、自らが決定したスリープ時間を用いてスリープの制御を行ってもよい。一方、そのスリープ申請の送信に応じてＯＬＴ１からスリープ許可が送信されなかった場合、または、ＯＬＴ１から送信されたスリープ不許可が、光受信部４２によって受信された場合に、スリープ制御部４５は、光受信部４２等をスリープモードに移行させなくてもよい。なお、スリープモードへの移行後、スリープ制御部４５は、設定されたスリープ時間ごとのスリープが繰り返されるように、光送受信部２３への電力供給を制御する。また、スリープモードにおいて、ＯＮＵ２がアクティブ期間であることをＯＬＴ１に通知するため、例えば、ＯＮＵ２は、アクティブ期間の開始時に、アクティブ期間となった旨をＯＬＴ１に送信してもよく、または、そうでなくてもよい。
【００３６】
インターフェース２７は、下流側の装置やネットワークとのインターフェース機能を実現するものである。なお、下流側の装置等が複数存在する場合に、複数のインターフェース２７が存在してもよい。
【００３７】
ここで、スリープ条件について説明する。そのスリープ条件は、例えば、バッファ量が、バッファ量の閾値より少ないことであってもよく、データ到着間隔が、到着間隔の閾値より大きいことであってもよく、または、その両方であってもよい。なお、バッファ量が閾値と等しい場合に、閾値より少ないと判断されてもよく、またはそうでなくてもよい。また、データ到着間隔が閾値と等しい場合に、閾値より大きいと判断されてもよく、またはそうでなくてもよい。後述するＯＬＴ１で行われる閾値との比較でも同様であるとする。そのバッファ量の閾値は、例えば、あらかじめ決められた値であってもよく、または、スリープ時間に応じた値であってもよい。前者の場合に、その閾値は、０であってもよい。その場合には、バッファされている上り送信データのないことがスリープモードに移行する必要条件となる。なお、その後者の場合について説明する。周期的なスリープの周期をＴｐ（ｓ）とし、スリープ時間をＴｓ（ｓ）とし、アクティブ期間におけるデータの送信レートをＲ１（ｂ／ｓ）とすると、１周期に送信できるデータ量（ｂｉｔ）は、（Ｔｐ−Ｔｓ）×Ｒ１となる。そして、スリープ制御部４５は、スリープモードに移行した場合のスリープ時間Ｔｓを用いて、そのデータ量（Ｔｐ−Ｔｓ）×Ｒ１を算出し、バッファ量の閾値としてもよい。バッファ量が、その閾値以下であれば、バッファリングされている上り送信データを一回のアクティブ期間で送信できるため、スリープしても問題ないと考えられるからである。なお、送信レートＲ１は、あらかじめ設定されていてもよく、または、測定されてもよい。また、データの到着間隔の閾値は、例えば、あらかじめ決められた値であってもよく、または、スリープ時間に応じた値であってもよい。後者の場合に、スリープ時間が長いほど、到着間隔の閾値も長く設定されてもよい。その場合に、到着間隔の閾値は、例えば、スリープ時間を引数とする増加関数を用いて算出されてもよく、スリープ時間と閾値とを対応付けるテーブル等を用いて特定されてもよい。また、スリープ条件を満たすかどうかの判断で用いられるバッファ状況は、例えば、あらかじめ決められた時間に対応する情報であってもよく、または、スリープ時間に応じた時間に対応する情報であってもよい。後者の場合には、例えば、スリープ時間が長い場合には、より長い時間に応じたバッファ状況を用いて判断が行われてもよい。例えば、スリープ時間がＴｓ２である場合には、１秒間のバッファ状況に応じて判断が行われ、スリープ時間がＴｓ３である場合には、５０秒間のバッファ状況に応じて判断が行われてもよい。そのように、異なる時間に応じたバッファ状況が用いられる場合には、バッファ状況取得部１５は、それらの異なる時間に応じたバッファ状況を取得することができる情報（例えば、１秒ごとのバッファ状況など）をあらかじめ取得しておき、その情報を用いて、所望の時間に応じたバッファ状況を取得してもよい。また、スリープ条件の判断等において、スリープ時間が必要である場合には、その時点でスリープモードに移行した場合のスリープ時間が用いられてもよい。そのスリープ時間の算出方法は、上述の通りである。なお、ＯＮＵ２が用いるスリープ条��の一例について説明したが、スリープ条件は、上述の説明以外のものであってもよいことは言うまでもない。例えば、すでに公知であるスリープ条件が用いられてもよい。
【００３８】
次に、ＯＬＴ１で用いられるスリープ条件、及びＯＬＴ１で算出されるスリープ時間について説明する。そのスリープ条件は、ＯＮＵ２の場合と同様に、例えば、バッファ量が、バッファ量の閾値より少ないことであってもよく、データ到着間隔が、到着間隔の閾値より大きいことであってもよく、または、その両方であってもよい。そのバッファ量の閾値が、例えば、あらかじめ決められた値でもよく、またはスリープ時間に応じた値でもよいことも、ＯＮＵ２の場合と同様である。なお、バッファ量の閾値は、（Ｔｐ−Ｔｓ）×Ｒ２で算出されてもよい。そのＲ２は、アクティブ期間における、ＯＬＴ１からＯＮＵ２への送信レート（ｂ／ｓ）である。また、到着間隔の閾値は、ＯＮＵ２の場合と同様であってもよい。また、スリープ時間Ｔｓとしては、スリープ申請に含まれるスリープ時間を用いてもよい。なお、スリープ判断部３３は、スリープ申請に含まれるスリープ時間を用いてスリープ条件が満たされないと判断した場合に、スリープ条件を満たすスリープ時間が存在するかどうか判断してもよい。そして、スリープ条件を満たすスリープ時間が存在する場合に、スリープ条件が満たされると判断してもよい。例えば、データの到達間隔に関する条件は満たされており、バッファ量に関する条件が満たされていなかったとする。そのバッファ量をＢ（ｂｉｔ）とすると、Ｂ／Ｒ２が周期Ｔｐより短いのであれば、スリープ時間を短くすることによって、バッファ量に関する条件を満たすことができるようになる。したがって、Ｂ／Ｒ２＜Ｔｐが満たされる場合には、スリープ判断部３３は、スリープ条件が満たされると判断してもよい。そして、スリープ判断部３３は、スリープ申請に含まれていたスリープ時間がＴｐ−Ｂ／Ｒ２以上である場合には、スリープ時間を、そのスリープ申請に含まれていたスリープ時間に決定し、そうでない場合には、スリープ時間を、Ｔｐ−Ｂ／Ｒ２以下のスリープ時間に決定してもよい。そして、その決定されたスリープ時間を含むスリープ許可がＯＮＵ２に送信されるようにしてもよい。一方、Ｂ／Ｒ２＜Ｔｐが満たされない場合には、スリープ判断部３３は、スリープ不許可が送信されるように制御し、ＯＮＵ２がスリープモードに移行しないようにしてもよい。ここで、Ｂ／Ｒ２＜Ｔｐが満たされるかどうか判断することは、バッファ量がＴｐ×Ｒ２未満であるかどうか判断することと同じである。なお、ＯＬＴ１が用いるスリープ条件の一例について説明したが、スリープ条件は、上述の説明以外のものであってもよいことは言うまでもない。例えば、すでに公知であるスリープ条件が用いられてもよい。
【００３９】
また、ＰＯＮシステムにおいて送受信されるデータは、通常、フレームである。したがって、上述の送信データや受信データは、送信フレームや受信フレームであると考えてもよい。なお、フレーム以外のデータが送受信されてもよい。
【００４０】
次に、第１及び第２の通信の関係、及び第１及び第２の通信の接続状態とスリープ時間との関係について、図６，図７を用いて説明する。ＯＬＴ１とＯＮＵ２との間で、セッションやコネクション等の通信が接続状態である場合には、仮にデータの送受信がなされていない状況であったとしても、その後、データが送受信される可能性が高いため、リアルタイム性を確保する観点から、スリープ時間をあまり大きくしないことが好適である。また、通信が接続状態であるかどうかを判断する際に、下位レイヤの第１の通信で判断すれば、より多くの通信をカバーできることになる。例えば、図６で示されるように、ＴＣＰの通信が接続状態であるかどうかを判断することによって、ＨＴＴＰ（Hypertext Transfer Protocol）やＦＴＰ（File Transfer Protocol）等の通信をカバーできることになる。一方、第１の通信の接続状態のみを判断する場合には、ＵＤＰの通信が漏れてしまうことになる。したがって、本実施の形態では、ＵＤＰの通信に関しては、上位レイヤのＳＩＰや、テレビ会議等のセッションを確立するその他の通信等によって個別に判断することになる。なお、例えば、ＳＩＰは、その規格上、ＴＣＰでも通信できるが、ＴＣＰによるＳＩＰが行われた場合には、第１の通信に含まれることになる。また、ＳＩＰやテレビ会議等がＴＣＰでなくＵＤＰを用いて通信する主な理由は、リアルタイム性を向上させることにある。したがって、通常、第２の通信の方が第１の通信よりもリアルタイム性の要求が高いと考えることができるため、図７で示されるように、第２の通信が接続状態である場合には、スリープ時間は、最も短い第２のスリープ時間に設定される。また、第２の通信が行われていないが、第１の通信が行われている状況として、例えば、ユーザがウェブサイトの閲覧を行っており、ＨＴＴＰの通信が行われている場合が考えられる。そのような場合に、ユーザが頻繁に閲覧先を変更しているときには、応答性のよい方がユーザの体感品質が高くなると考えられる。一方、ユーザがあまり閲覧先を変更しないときには、応答性がよくなくても、ユーザの体感品質が低くならないと考えられる。したがって、第２の通信が行われていないが、第１の通信が行われている状況では、バッファ状況に応じて、第１のスリープ時間以下となるようにスリープ時間を制御することによって、ユーザの体感品質を損なわない範囲で、消費電力の抑制効果を高めることができうる。なお、バッファ状況に応じてスリープ時間を制御するとは、バッファ状況によって、通信がより頻繁であることが示されるほど、短いスリープ時間となるように制御し、通信が頻繁でない（疎である）ことが示されるほど、長いスリープ時間となるように制御することであってもよい。一方、第１及び第２の通信が接続状態でない場合には、ＯＬＴ１とＯＮＵ２との間で、セッションやコネクション等の通信が接続状態でないことになるため、データの送受信がないときには、ユーザが外出中や就寝中であるといったように、実質的に通信がなされていない状況であると考えることができる。したがって、そのような状況におけるスリープモードでは、スリープ時間は、最も長い第３のスリープ時間に設定され、消費電力がより低減されることになる。こ��ようにして、通信の状況に応じて、リアルタイム性の確保と、消費電力の低減とのそれぞれを適切に実現することができる。
【００４１】
次に、ＯＬＴ１の動作について図４のフローチャートを用いて説明する。なお、図４のフローチャートは、スリープ制御に関するＯＬＴ１の処理を示すものであり、ＯＬＴ１とＯＮＵ２との間での光通信に関する処理は、このフローチャートで示される処理とは別に行われるものとする。
【００４２】
（ステップＳ１０１）バッファ状況取得部１５は、バッファ状況を取得するタイミングであるかどうか判断する。そして、バッファ状況を取得するタイミングである場合には、ステップＳ１０２に進み、そうでない場合には、ステップＳ１０６に進む。なお、バッファ状況取得部１５は、例えば、バッファ状況を取得するタイミングであると定期的に判断してもよい。
【００４３】
（ステップＳ１０２）バッファ状況取得部１５は、ＯＮＵ２ごとのバッファ状況を取得する。
【００４４】
（ステップＳ１０３）スリープ判断部３３は、現在、スリープモードであるＯＮＵ２が存在するかどうか判断する。そして、存在する場合には、ステップＳ１０４に進み、そうでない場合には、ステップＳ１０１に戻る。なお、このステップの判断において、ＯＬＴ１で管理されている、各ＯＮＵ２がスリープモードであるかどうかを示す情報が用いられてもよい。
【００４５】
（ステップＳ１０４）スリープ判断部３３は、現在、スリープモードであるＯＮＵ２に関してスリープ条件が満たされているかどうかを、ステップＳ１０２で取得されたバッファ状況を用いて判断する。そして、スリープ条件が満たされている場合には、ステップＳ１０１に戻り、スリープ条件が満たされていない場合には、ステップＳ１０５に進む。
【００４６】
（ステップＳ１０５）スリープ判断部３３は、スリープ条件が満たされていないと判断したＯＮＵ２について、スリープ解除指示（ウェイクアップ指示）が送信されるように制御する。なお、そのスリープ解除指示は、スリープモードのＯＮＵ２がアクティブ期間となったときに光送信部３１を介して送信されることになる。
【００４７】
なお、ステップＳ１０３において、２以上のＯＮＵ２がスリープモードであると判断された場合には、各ＯＮＵ２について、ステップＳ１０４，Ｓ１０５の処理が行われるものとする。
【００４８】
（ステップＳ１０６）スリープ判断部３３は、ＯＮＵ２から送信されたスリープ申請が光受信部３２で受信されたかどうか判断する。そして、スリープ申請が受信された場合には、ステップＳ１０７に進み、そうでない場合には、ステップＳ１０１に戻る。
【００４９】
（ステップＳ１０７）スリープ判断部３３は、スリープ申請を送信したＯＮＵ２に関する最新のバッファ状況を用いて、そのＯＮＵ２がスリープ条件を満たしているかどうか判断する。そして、スリープ条件を満たしている場合には、ステップＳ１０８に進み、スリープ条件を満たしていない場合には、ステップＳ１１１に進む。例えば、上述の説明のように、スリープ判断部３３は、Ｂ／Ｒ２＜Ｔｐが満たされない場合に、スリープ条件が満たされていないと判断してもよい。
【００５０】
（ステップＳ１０８）スリープ判断部３３は、スリープ申請に含まれていたスリープ時間が適切であるかどうかについて、スリープ申請を送信したＯＮＵ２に関する最新のバッファ状況を用いて判断する。そして、適切である場合には、ステップＳ１０９に進み、適切でない場合には、ステップＳ１１０に進む。例えば、上述の説明のように、スリープ判断部３３は、最新のバッファ状況の示すバッファ量が（Ｔｐ−Ｔｓ）×Ｒ２以下でない場合に、スリープ時間が適切でないと判断してもよい。
【００５１】
（ステップＳ１０９）スリープ判断部３３は、スリープ申請を送信したＯＮＵ２に、スリープモードへの移行を許可するスリープ許可が送信されるように制御する。なお、そのスリープ許可には、スリープ時間が含まれていなくてもよく、または、スリープ申請に含まれていたスリープ時間が含まれていてもよい。そして、ステップＳ１０１に戻る。
【００５２】
（ステップＳ１１０）スリープ判断部３３は、スリープ申請を送信したＯＮＵ２に、スリープモードへの移行を許可するスリープ許可が送信されるように制御する。なお、そのスリープ許可には、スリープ申請を送信したＯＮＵ２に関する最新のバッファ状況を用いて決定されたスリープ時間が含まれているものとする。そのスリープ時間は、通常、スリープ申請に含まれていたスリープ時間より短いものである。そして、ステップＳ１０１に戻る。例えば、上述の説明のように、スリープ判断部３３は、スリープ時間をＴｐ−Ｂ／Ｒ２に決定してもよい。
【００５３】
（ステップＳ１１１）スリープ判断部３３は、スリープ申請を送信したＯＮＵ２に、スリープモードへの移行を許可しないスリープ不許可が送信されるように制御する。そして、ステップＳ１０１に戻る。
【００５４】
なお、図４のフローチャートにおいて、スリープを許可しない場合に、スリープ不許可を送信しないようにしてもよい。また、図４のフローチャートにおける処理の順序は一例であり、同様の結果を得られるのであれば、各ステップの順序を変更してもよい。また、図４のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。
【００５５】
次に、ＯＮＵ２の動作について図５のフローチャートを用いて説明する。なお、図５のフローチャートは、スリープ制御に関するＯＮＵ２の処理を示すものであり、ＯＬＴ１とＯＮＵ２との間での光通信に関する処理や、設定されたスリープ時間に応じたスリープ制御の処理は、このフローチャートで示される処理とは別に行われるものとする。
【００５６】
（ステップＳ２０１）バッファ状況取得部２５は、バッファ状況を取得するタイミングであるかどうか判断する。そして、バッファ状況を取得するタイミングである場合には、ステップＳ２０２に進み、そうでない場合には、ステップＳ２１６に進む。なお、バッファ状況取得部２５は、例えば、バッファ状況を取得するタイミングであると定期的に判断してもよい。
【００５７】
（ステップＳ２０２）バッファ状況取得部２５は、バッファ状況を取得する。
【００５８】
（ステップＳ２０３）スリープ制御部４５は、ステップＳ２０２で取得されたバッファ状況を用いて、スリープ条件が満たされているかどうか判断する。そして、スリープ条件が満たされている場合には、ステップＳ２０４に進み、スリープ条件が満たされていない場合には、ステップＳ２１４に進む。
【００５９】
（ステップＳ２０４）スリープ制御部４５は、第２の通信が接続状態であるかどうかについて、第２の判断部４４による最新の判断結果を用いて判断する。そして、接続状態である場合には、ステップＳ２０５に進み、そうでない場合には、ステップＳ２１１に進む。
【００６０】
（ステップＳ２０５）スリープ制御部４５は、スリープ時間を第２のスリープ時間に決定する。
【００６１】
（ステップＳ２０６）スリープ制御部４５は、スリープ申請を送信するかどうか判断する。そして、スリープ申請を送信する場合には、ステップＳ２０７に進み、そうでない場合には、ステップＳ２０１に戻る。なお、スリープ制御部４５は、例えば、ＯＮＵ２が現在、スリープモードでない場合には、スリープ申請を送信すると判断してもよい。また、スリープ制御部４５は、例えば、ＯＮＵ２が現在、スリープモードであり、ステップＳ２０５等において決定されたスリープ時間が、現在のスリープモードのスリープ時間と異なる場合に、スリープ申請を送信すると判断してもよい。決定されたスリープ時間が、現在のスリープ時間と同じである場合には、スリープ申請を送信しないと判断してもよい。
【００６２】
（ステップＳ２０７）スリープ制御部４５は、ステップＳ２０５等で決定されたスリープ時間を含むスリープ申請がＯＬＴ１に送信されるように制御する。そのスリープ申請は、ＯＮＵ２がＯＬＴ１への送信を行うことができるタイミングで送信されることになる。
【００６３】
（ステップＳ２０８）スリープ制御部４５は、ＯＬＴ１から送信されたスリープ許可が光受信部４２で受信されたかどうか判断する。そして、スリープ許可が受信された場合には、ステップＳ２０９に進み、そうでない場合には、ステップＳ２１０に進む。
【００６４】
（ステップＳ２０９）スリープ許可にスリープ時間が含まれない場合、または、スリープ申請に含まれていたスリープ時間がスリープ許可に含まれている場合には、スリープ制御部４５は、ＯＮＵ２で決定したスリープ時間のスリープモードとなるように設定する。一方、スリープ申請に含まれていたスリープ時間と異なるスリープ時間がスリープ許可に含まれている場合には、スリープ制御部４５は、そのスリープ許可に含まれているスリープ時間のスリープモードとなるように設定する。その後、その設定されたスリープ時間を用いた周期的なスリープが行われることになる。そして、ステップＳ２０１に戻る。
【００６５】
（ステップＳ２１０）スリープ制御部４５は、ＯＬＴ１から送信されたスリープ不許可が光受信部４２で受信されたかどうか判断する。そして、スリープ不許可が受信された場合には、ステップＳ２０１に戻り、そうでない場合には、ステップＳ２０８に戻る。
【００６６】
（ステップＳ２１１）スリープ制御部４５は、第１の通信が接続状態であるかどうかについて、第１の判断部４３による最新の判断結果を用いて判断する。そして、接続状態である場合には、ステップＳ２１２に進み、そうでない場合には、ステップＳ２１３に進む。
【００６７】
（ステップＳ２１２）スリープ制御部４５は、最新のバッファ状況に応じて、スリープ時間が第１のスリープ時間以下となるように決定する。
【００６８】
（ステップＳ２１３）スリープ制御部４５は、スリープ時間を第３のスリープ時間に決定する。
【００６９】
（ステップＳ２１４）スリープ制御部４５は、ＯＮＵ２がスリープモードであるかどうか判断する。そして、スリープモードである場合には、ステップＳ２１５に進み、そうでない場合には、ステップＳ２０１に戻る。
【００７０】
（ステップＳ２１５）スリープ制御部４５は、スリープモードを解除する。なお、スリープモードが解除されたことは、ＯＬＴ１に通知されることになる。
【００７１】
（ステップＳ２１６）スリープ制御部４５は、第１及び第２の判断部４３，４４による判断を行うタイミングであるかどうか判断する。そして、その判断のタイミングである場合には、ステップＳ２１７に進み、そうでない場合には、ステップＳ２１８に進む。なお、スリープ制御部４５は、例えば、判断を行うタイミングであると定期的に判断してもよい。
【００７２】
（ステップＳ２１７）第１の判断部４３は、第１の通信が接続状態であるかどうかを判断する。また、第２の判断部４４は、第２の通信が接続状態であるかどうかを判断する。なお、第２の通信が複数存在する場合には、第２の判断部４４は、各通信について判断を行ってもよい。そして、ステップＳ２０１に戻る。
【００７３】
（ステップＳ２１８）スリープ制御部４５は、ＯＬＴ１から送信されたスリープ解除指示が光受信部４２で受信されたかどうか判断する。そして、スリープ解除指示が受信された場合には、ステップＳ２１９に進み、そうでない場合には、ステップＳ２０１に戻る。
【００７４】
（ステップＳ２１９）スリープ制御部４５は、スリープモードを解除する。そして、ステップＳ２０１に戻る。
【００７５】
なお、ＯＮＵ２がスリープ中に、そのＯＮＵ２のスリープ条件が満たされなくなったとＯＬＴ１が判断した場合には、ＯＬＴ１からＯＮＵ２にスリープ解除指示が送信されるため、図５のフローチャートにおいて、ＯＮＵ２がスリープ中にスリープ不許可を受信することはないと考えられるが、仮にそのようなスリープ不許可の受信があった場合には、ステップＳ２１０でＹＥＳと判断された後に、スリープモードが解除されてもよい。また、ステップＳ２１０においてスリープ不許可が受信されてからあらかじめ決められた期間は、ステップＳ２０３において、スリープ条件を満たすと判断しないようにしてもよい。ＯＬＴ１における下り送信データについてスリープ条件が満たされておらず、ＯＮＵ２における上り送信データについてスリープ条件が満たされている場合に、短期間にスリープ申請の送信と、スリープ不許可の受信とが繰り返される事態を回避するためである。また、図５のフローチャートにおける処理の順序は一例であり、同様の結果を得られるのであれば、各ステップの順序を変更してもよい。また、図５のフローチャートにおいて、電源オフや処理終了の割り込みにより処理は終了する。
【００７６】
また、スリープ時間を決定する以外の処理、例えば、ＯＬＴ１がＯＮＵ２のスリープのタイミングを知る処理や、ＯＬＴ１がＯＮＵ２のスリープのタイミングを変更する処理等についてはすでに公知であり（例えば、上記特許文献１を参照されたい）、その詳細な説明を省略する。
【００７７】
次に、本実施の形態による受動光ネットワークシステムの動作について、具体例を用いて説明する。この具体例では、第１の通信がＴＣＰの通信であり、第２の通信がＳＩＰを用いた通話であるとする。また、この具体例では、第１から第３のスリープ時間Ｔｓ１〜Ｔｓ３、アクティブ時間Ｔａが次のように設定されているものとする。また、周期Ｔｐはスリープ時間に応じて異なる値をとり、Ｔｓ＋Ｔａとなるものとする。なお、このようにアクティブ時間Ｔａを短い一定の時間とすることにより、スリープ時間が長い場合にはアクティブ時間の割合が短くなり、結果として消費電力をより低減することができる。一方、スリープ時間が短い場合には、それに応じてアクティブ時間の割合が大きくなるため、それだけ多くのデータを通信できるようになる。したがって、スリープ時間を制御するだけで、省電力の程度や、通信できるデータ量をコントロールできることになる。
第１のスリープ時間Ｔｓ１：２００（ｍｓ）
第２のスリープ時間Ｔｓ２：５０（ｍｓ）
第３のスリープ時間Ｔｓ３：９００（ｍｓ）
アクティブ時間Ｔａ：２０（ｍｓ）
【００７８】
ＯＮＵ２−１の下流側の装置を操作しているユーザが、デジタルカメラで撮影した複数の画像をクラウドにアップロードしていたとする。その場合には、ＯＮＵ２−１の上り送信フレームが多いため、スリープモードへの移行は行われない（ステップＳ２０１〜Ｓ２０３，Ｓ２１４）。その後、画像のアップロードが終了し、ユーザがブラウザを起動してウェブサイトの閲覧を開始したとする。すると、第１の判断部４３は、ＴＣＰの３ウェイ・ハンドシェイクを検知し、ＴＣＰが接続状態になったと判断する（ステップＳ２１６，Ｓ２１７）。なお、この時点では、ＳＩＰの通話の開始は検知されていないものとする。また、ユーザは、あるウェブサイトに記載された文書をじっくり読んでいたとする。その後、バッファ状況取得部２５によって送信バッファ２１のバッファ状況が取得されたタイミングにおいて、上り送信フレームの送信間隔が大きく、バッファ量も少ないため、スリープ制御部４５によって、スリープ条件が満たされると判断されたとする（ステップＳ２０１〜Ｓ２０３）。また、スリープ制御部４５は、ＳＩＰの通話は行われておらず、ＴＣＰの通信は行われているため、バッファ状況に応じて、スリープ時間Ｔｓを第１のスリープ時間「２００（ｍｓ）」に決定する（ステップＳ２０４，Ｓ２１１，Ｓ２１２）。そして、そのスリープ時間Ｔｓを含むスリープ申請が、ＯＬＴ１に送信されることになる（ステップＳ２０６，Ｓ２０７）。
【００７９】
そのスリープ申請は、ＯＬＴ１の光受信部３２で受信され、スリープ判断部３３に渡される（ステップＳ１０６）。スリープ判断部３３は、そのスリープ申請を受け取ると、スリープ時間「２００（ｍｓ）」を用いて、スリープ条件が満たされるかどうか判断する（ステップＳ１０７）。この場合には、下り送信フレームもほとんどないため、スリープ時間を変更することなく、その条件が満たされたとする（ステップＳ１０８）。すると、ＯＬＴ１からＯＮＵ２−１に、スリープ時間「２００（ｍｓ）」を含むスリープ許可が送信される（ステップＳ１０９）。
【００８０】
そのスリープ許可は、ＯＮＵ２−１の光受信部４２で受信され、スリープ制御部４５に渡される（ステップＳ２０８）。スリープ制御部４５は、そのスリープ許可を受け取ると、そのスリープ許可に含まれているスリープ時間「２００（ｍｓ）」を用いた周期的なスリープが行われるように、スリープモードの設定を行う（ステップＳ２０９）。そのようにして、２００（ｍｓ）のスリープ期間と、２０（ｍｓ）のアクティブ期間とを繰り返す周期的なスリープが行われることになる。
【００８１】
その後、ユーザが、調べ物をするため、ウェブサイトのリンク先を高い頻度でクリックしたとする。ただし、その状況においても、スリープ条件は満たされていたとする。すると、スリープ制御部４５は、上り送信フレームの到着間隔に応じて、スリープ時間Ｔｓを、第１のスリープ時間Ｔｓ１以下の１００（ｍｓ）に決定したとする（ステップＳ２０１〜Ｓ２０４，Ｓ２１１，Ｓ２１２）。そして、再度、スリープ申請の送信が行われる（ステップＳ２０６，Ｓ２０７）。この場合にも、ＯＬＴ１からスリープ時間「１００（ｍｓ）」を含むスリープ許可が送信されたとすると、それに応じて、スリープ時間が１００（ｍｓ）に短縮されることになる（ステップＳ２０８，Ｓ２０９）。なお、そのようにスリープ時間が短縮されることによって、ユーザによるリンク先のクリックに対する応答性が向上することになり、ユーザの体感品質が高められることになる。
【００８２】
次に、他のユーザによってＳＩＰの通話が開始され、ＯＮＵ２−１のユーザが、それに応答したとする。すると、下り送信フレームが多くなるため、ＯＬＴ１からＯＮＵ２−１にスリープ解除指示が送信され（ステップＳ１０１〜Ｓ１０５）、それに応じて、ＯＮＵ２−１におけるスリープが解除される（ステップＳ２１８，Ｓ２１９）。また、第２の判断部４４によって、ＳＩＰの通話が接続状態になったと判断される（ステップＳ２１６，Ｓ２１７）。その後、その通話において、両者が黙っている期間があり、その間は、音声データの送受信が行われず、スリープ条件が満たされたとする（ステップＳ２０１〜Ｓ２０３）。この場合には、ＳＩＰの通話が接続状態であるため、スリープ制御部４５は、スリープ時間Ｔｓを第２のスリープ時間「５０（ｍｓ）」に決定し、そのスリープ時間を含むスリープ申請をＯＬＴ１に送信する（ステップＳ２０４〜Ｓ２０７）。この場合にも、ＯＬＴ１からスリープ時間「５０（ｍｓ）」を含むスリープ許可が送信されたとすると、スリープ制御部４５は、そのスリープ時間を用いた周期的なスリープが行われるように、スリープモードの設定を行う（ステップＳ２０８，Ｓ２０９）。そのため、短期間のスリープを繰り返すことによって消費電力を削減しながらも、会話が再開されたときに大きな遅延を生じることがないようにすることができる。なお、会話が再開されたときには、スリープ条件が満たされなくなり、スリープが解除されることになる（ステップＳ２０１〜Ｓ２０３，Ｓ２１４，Ｓ２１５）。なお、そのスリープの解除は、ＯＬＴ１からＯＮＵ２−１にスリープ解除指示が送信されることによって行われてもよい。
【００８３】
その後、ユーザがＳＩＰの通話もウェブサイトの閲覧も終了し、就寝したとする。すると、第１の判断部４３は、ＴＣＰの通信が接続状態でなくなったと判断し、また第２の判断部４４は、ＳＩＰの通話が接続状態でなくなったと判断する（ステップＳ２１６，Ｓ２１７）。そして、スリープ条件が満たされた後に、スリープ時間Ｔｓが第３のスリープ時間「９００（ｍｓ）」に決定される（ステップＳ２０１〜Ｓ２０４，Ｓ２１１，Ｓ２１３）。また、そのスリープ時間を含むスリープ申請がＯＬＴ１に送信される（ステップＳ２０６，Ｓ２０７）。この場合にも、ＯＬＴ１からスリープ時間「９００（ｍｓ）」を含むスリープ許可が送信されたとすると、そのスリープ時間「９００（ｍｓ）」を用いたスリープモードへの移行が行われることになる（ステップＳ２０８，Ｓ２０９）。このように、まったく通信が行われない夜間などには、長時間のスリープを実現することができ、省電力の効果が大きくなる。一方、ＯＬＴ１とＯＮＵ２−１との間の回線は接続された状態を維持できるため、例えば、他のユーザから、ＯＮＵ２−１のユーザに対してＳＩＰの発呼が行われた場合であっても、ユーザの端末は、そのＩＮＶＩＴＥメッセージを受信することができる。なお、そのような長時間のスリープが行われている場合には、発呼への応答が遅くなりうるが、そのような遅延があったとしても、ユーザの体感品質が大きく低下することはないため、特に問題にはならないと考えられる。
【００８４】
なお、例えば、第１の通信であるＴＣＰの通信が行われている際に、所定のアプリケーションに応じたセッションの確立に応じてＲＴＰ（Real-time Transport Protocol）による通信が行われ、そのＲＴＰの通信が第２の通信に該当する場合には、第２の判断部４４によって、第２の通信が開始されたと判断されてもよい。また、そのＲＴＰの通信が終了された場合（例えば、ＲＴＣＰ（Real-time Transport Control Protocol）のＢＹＥメッセージが通信された場合等）には、第２の判断部４４によって第２の通信が終了されたと判断されてもよい。
【００８５】
以上のように、本実施の形態による受動光ネットワークシステムによれば、通信が接続状態であるかどうかに応じてスリープ時間を決定するため、仮にバッファ量が少なかったとしても、通信が接続中であれば比較的短いスリープ時間が設定されることになる。その結果、接続状態の通信においてデータの送受信が再開された際に、その再開に対する応答性を向上させることができる。その結果、例えば、ユーザの体感品質を向上させることが可能となる。また、そのような通信の接続状態を、下位レイヤの第１の通信で網羅的に把握すると共に、上位レイヤの第２の通信によって個別的にも把握することができ、より抜け落ちが少なくなるように通信の接続状態を把握することができる。また、下位レイヤの通信状態を把握することによって、その下位レイヤの第１の通信を用いる上位レイヤにおける新たな通信規格（プロトコル）による通信が追加されたとしても、その通信規格にも対応することができるようになる。また、スリープ申請をＯＬＴ１に送信し、その送信に対応するスリープ許可がＯＬＴ１から送信されたことに応じて、ＯＮＵ２におけるスリープモードへの移行を行うことにより、スリープモードに移行してよいかどうかの判断を、より厳密に行うことができるようになる。
【００８６】
なお、本実施の形態では、第２の通信がＳＩＰの通信である場合について主に説明したが、そうでなくてもよいことは言うまでもない。第２の通信は、例えば、トランスポート層においてＵＤＰを用いる、ＳＩＰ以外のセッション確立プロトコルを用いた通信であってもよい。
【００８７】
また、本実施の形態では、ＯＮＵ２がスリープモードに移行する際に、スリープ申請をＯＬＴ１に送信し、その送信に応じてスリープ許可が送信されるとＯＮＵ２がスリープモードに移行する場合について説明したが、そうでなくてもよい。ＯＮＵ２においてスリープ条件が満たされた場合には、ＯＬＴ１における判断に関係なく、そのＯＮＵ２は、スリープモードに移行するようにしてもよい。その場合であっても、ＯＬＴ１が、スリープモードに移行したＯＮＵ２のアクティブ期間を知ることができるようにするため、スリープモードに移行した旨が、ＯＮＵ２からＯＬＴ１に送信されることが好適である。そのスリープモードに移行した旨には、スリープ時間も含まれていることが好適である。
【００８８】
また、本実施の形態では、ＯＮＵ２において、光送信部４１と光受信部４２とを同じタイミングで周期的にスリープさせるサイクリックスリープを行う場合について説明したが、そうでなくてもよい。例えば、光受信部４２については、上述のように、周期的なスリープを行い、光送信部４１については、バッファ状況に応じてスリープさせてもよい。すなわち、スリープ制御部４５は、バッファ状況取得部２５によって取得されたバッファ状況によって、上り送信データのないことが示される場合に、光送信部４１をスリープさせ、上り送信データが生じた場合には、光送信部４１のスリープを解除して、その送信を行うようにしてもよい。その場合には、光送信部４１について周期的にアクティブ期間を設ける必要もないため、スリープ期間を最大限に長くすることができ、消費電力削減の効果が大きくなる。なお、上り送信データが生じた後であっても、すぐに上りの送信を行うことができない場合もある。すなわち、ＯＬＴ１によって決められた各ＯＮＵ２の送信スケジュールによっては、上りの送信を少し待たなくてはならないこともありうる。そのような場合には、例えば、上り送信データが生じた後であっても、実際の送信が可能となるまで、光送信部４１のスリープを継続してもよい。なお、光送信部４１については、スリープを行わないように制御してもよい。
【００８９】
また、本実施の形態において、特定の通信が行われている場合には、スリープ条件が満たされないと判断してもよい。例えば、リアルタイム性の要求されるゲームの通信が行われている場合には、仮にバッファ量が少なかったとしても、スリープしない方がよいこともある。例えば、スリープ時間が５０（ｍｓ）程度であったとしても、その遅延によってゲームの結果が異なることもあるからである。したがって、リアルタイム性の要求されるゲームの通信が行われる場合には、スリープ制御部４５は、スリープ条件が満たされないと判断してもよい。なお、そのようなリアルタイム性の要求されるゲームが行われている場合には、データの送信頻度が高いと考えられる。したがって、スリープ条件におけるデータ到着間隔の閾値を適切に設定することにより、そのようなゲームの通信が行われている場合には、スリープ条件が満たされないように設定してもよい。
【００９０】
また、本実施の形態では、第２の通信が、第１のレイヤにおいて第１の通信以外の通信を行う通信であるとしたが、そうでなくてもよい。第２の通信は、第２のレイヤにおける特定の通信であれば、第１のレイヤにおける通信方式は問わなくてもよい。その場合には、例えば、ＴＣＰによるＳＩＰの通信も第２の通信であると考えてもよい。そのようにすることで、ある通信が第２の通信かどうかを判断するのに第２のレイヤのみを見ればよくなり、判断処理が簡単になる。一方、第２の通信が、第１のレイヤにおいて第１の通信以外の通信を行う通信である場合には、例えば、ＴＣＰのように、ＵＤＰと比較して高い応答性の要求されないプロトコルについて、短いスリープ時間を設定することがなくなるため、省電力化の観点からはメリットがありうることになる。
【００９１】
また、本実施の形態において、スリープ制御部４５は、通信の相手先とのＲＴＴ（ラウンドトリップタイム）を用いて、第１の通信が接続状態であり、第２の通信が接続状態でない場合のスリープ時間を決定したり、第２のスリープ時間を決定したりしてもよい。具体的には、スリープ制御部４５は、第１の通信や第２の通信のＲＴＴを測定する。その測定は、例えば、ＴＣＰコネクション確立のために送受信されるパケットを用いて行われてもよく、その他の送受信（例えば、送信に対してＡＣＫが返されるものなど）を用いて行われてもよい。そして、スリープ制御部４５は、ＲＴＴが大きい場合には、スリープ時間が長くなるように制御し、ＲＴＴが小さい場合には、スリープ時間が短くなるように制御してもよい。例えば、ＲＴＴが１２００（ｍｓ）である場合に、スリープ時間を２００（ｍｓ）から５０（ｍｓ）に短くしても、ユーザの体感品質は変わらないと考えられる。一方、ＲＴＴが２００（ｍｓ）である場合には、スリープ時間を２００（ｍｓ）から５０（ｍｓ）に短くすると、ユーザの体感品質は向上すると考えられる。したがって、上述のようなＲＴＴに応じたスリープ時間の制御を行うことによって、ユーザの体感品質を損なうことなく、スリープ時間を長くすることができ、より消費電力を低減させることができるようになる。なお、そのＲＴＴの計測時にスリープ期間をまたぐことが考えられる。すなわち、あるパケットが送信されてから、それに応じたＡＣＫが返ってくるまでに、スリープ期間の入ることがある。その場合には、正確なＲＴＴを計測できないため、スリープ制御部４５は、スリープ期間をまたがないＲＴＴを用いて、上述の制御を行うようにしてもよい。
【００９２】
また、上記実施の形態において、各処理または各機能は、単一の装置または単一のシステムによって集中処理されることによって実現されてもよく、または、複数の装置または複数のシステムによって分散処理されることによって実現されてもよい。
【００９３】
また、上記実施の形態において、各構成要素間で行われる情報の受け渡しは、例えば、その情報の受け渡しを行う２個の構成要素が物理的に異なるものである場合には、一方の構成要素による情報の出力と、他方の構成要素による情報の受け付けとによって行われてもよく、または、その情報の受け渡しを行う２個の構成要素が物理的に同じものである場合には、一方の構成要素に対応する処理のフェーズから、他方の構成要素に対応する処理のフェーズに移ることによって行われてもよい。
【００９４】
また、上記実施の形態において、各構成要素が実行する処理に関係する情報、例えば、各構成要素が受け付けたり、取得したり、選択したり、生成したり、送信したり、受信したりした情報や、各構成要素が処理で用いる閾値や数式、アドレス等の情報等は、上記説明で明記していなくても、図示しない記録媒体において、一時的に、または長期にわたって保持されていてもよい。また、その図示しない記録媒体への情報の蓄積を、各構成要素、または、図示しない蓄積部が行ってもよい。また、その図示しない記録媒体からの情報の読み出しを、各構成要素、または、図示しない読み出し部が行ってもよい。
【００９５】
また、上記実施の形態において、各構成要素等で用いられる情報、例えば、各構成要素が処理で用いる閾値やアドレス、各種の設定値等の情報がユーザによって変更されてもよい場合には、上記説明で明記していなくても、ユーザが適宜、それらの情報を変更できるようにしてもよく、または、そうでなくてもよい。それらの情報をユーザが変更可能な場合には、その変更は、例えば、ユーザからの変更指示を受け付ける図示しない受付部と、その変更指示に応じて情報を変更する図示しない変更部とによって実現されてもよい。その図示しない受付部による変更指示の受け付けは、例えば、入力デバイスからの受け付けでもよく、通信回線を介して送信された情報の受信でもよく、所定の記録媒体から読み出された情報の受け付けでもよい。
【００９６】
また、上記実施の形態において、各構成要素は専用のハードウェアにより構成されてもよく、または、ソフトウェアにより実現可能な構成要素については、プログラムを実行することによって実現されてもよい。例えば、ハードディスクや半導体メモリ等の記録媒体に記録されたソフトウェア・プログラムをＣＰＵ等のプログラム実行部が読み出して実行することによって、各構成要素が実現されうる。その実行時に、プログラム実行部は、記憶部や記録媒体にアクセスしながらプログラムを実行してもよい。また、そのプログラムは、サーバなどからダウンロードされることによって実行されてもよく、所定の記録媒体（例えば、光ディスクや磁気ディスク、半導体メモリなど）に記録されたプログラムが読み出されることによって実行されてもよい。また、このプログラムは、プログラムプロダクトを構成するプログラムとして用いられてもよい。また、そのプログラムを実行するコンピュータは、単数であってもよく、複数であってもよい。すなわち、集中処理を行ってもよく、または分散処理を行ってもよい。
【００９７】
また、本発明は、以上の実施の形態に限定されることなく、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【産業上の利用可能性】
【００９８】
以上より、本発明による子局装置によれば、省電力化とリアルタイム性の確保とのそれぞれを実現できるように周期的なスリープを制御することができるという効果が得られ、ＰＯＮシステムにおけるＯＮＵとして有用である。
【符号の説明】
【００９９】
２  ＯＮＵ（子局装置）
２１  送信バッファ
２２  受信バッファ
２３  光送受信部
２５  バッファ状況取得部
２６  制御部
４１  光送信部
４２  光受信部
４３  第１の判断部
４４  第２の判断部
４５  スリープ制御部
【図１】
2016140011.tif 000003
【図２】
2016140011.tif 000004
【図３】
2016140011.tif 000005
【図４】
2016140011.tif 000006
【図５】
2016140011.tif 000007
【図６】
2016140011.tif 000008
【図７】
2016140011.tif 000009
【図８Ａ】
2016140011.tif 000010
【図８Ｂ】
2016140011.tif 000011
【図８Ｃ】
2016140011.tif 000012