特許 5804566 スリープ制御方法、光通信システム、及び光ネットワーク終端装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5804566

(24)【登録日】2015年9月11日

(45)【発行日】2015年11月4日

(54)【発明の名称】スリープ制御方法、光通信システム、及び光ネットワーク終端装置

(51)【国際特許分類】

   H04L 12/44 20060101AFI20151015BHJP

【ＦＩ】

   H04L12/44 200

【請求項の数】8

【全頁数】16

(21)【出願番号】特願2012-151955(P2012-151955)

(22)【出願日】2012年7月6日

(65)【公開番号】特開2014-17568(P2014-17568A)

(43)【公開日】2014年1月30日

【審査請求日】2014年6月26日

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(73)【特許権者】

【識別番号】504157024

【氏名又は名称】国立大学法人東北大学

(74)【代理人】

【識別番号】100119677

【弁理士】

【氏名又は名称】岡田 賢治

(74)【代理人】

【識別番号】100115794

【弁理士】

【氏名又は名称】今下 勝博

(72)【発明者】

【氏名】氏川 裕隆

(72)【発明者】

【氏名】吉本 直人

(72)【発明者】

【氏名】鈴木 謙一

(72)【発明者】

【氏名】西山 大樹

(72)【発明者】

【氏名】加藤 寧

【審査官】 大石 博見

(56)【参考文献】

【文献】 国際公開第２０１０／０９８２６２（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／４４

(57)【特許請求の範囲】

【請求項1】

光加入者線終端装置（ＯＬＴ：Ｏｐｔｉｃａｌ Ｌｉｎｅ Ｔｅｒｍｉｎａｌ）と光ネットワーク終端装置（ＯＮＵ：Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ Ｕｎｉｔ）とが光ファイバ伝送路を介して光通信を行う光通信システムにおいて、受信側においてデータの受信時に受信確認フレームを送信側へ返信するデータ伝送方式を採用しており、前記ＯＮＵもしくは前記ＯＮＵより前記受信側で、前記送信側へ転送する前記受信確認フレームを所定ルールに基づいて間引く間引き動作を行い、前記受信確認フレームに基づいて、前記ＯＮＵのスリープ可能なブロックへ出されるスリープ解除指令の出力回数を減じることを特徴とするスリープ制御方法。

【請求項2】

前記所定ルールは、前記受信確認フレームのカウント開始からの数が、又は前記受信確認フレームのカウント開始時刻からの経過時間が、別途定めた閾値になるまで一定の要件に合致した複数の前記受信確認フレームをグルーピングし、少なくとも最新の受信確認フレームのみとすることを特徴とする請求項１に記載のスリープ制御方法。

【請求項3】

前記別途定めた閾値を、輻輳ウィンドウ、広告ウィンドウ、又は往復遅延時間を基に設定することを特徴とする請求項２に記載のスリープ制御方法。

【請求項4】

前記別途定めた閾値を、単位時間あたりの前記受信確認フレームの数を維持できる程度まで初期値から増加させていくことを特徴とする請求項２に記載のスリープ制御方法。

【請求項5】

受信確認番号が同じ前記受信確認フレームが一定数以上となった場合、前記ＯＮＵをスリープ状態から起床状態とすることを特徴とする請求項１から４のいずれかに記載のスリープ制御方法。

【請求項6】

単位時間あたりの前記受信確認フレームの量が規定値以上になった場合、前記間引き動作を開始し、単位時間あたりの前記受信確認フレームの量が規定値未満になった場合、前記間引き動作を停止することを特徴とする請求項１から５のいずれかに記載のスリープ制御方法。

【請求項7】

ＯＬＴとＯＮＵとが光ファイバ伝送路を介して光通信を行う光通信システムであって、請求項１から６のいずれかのスリープ制御方法を実施するスリープ制御手段を備える光通信システム。

【請求項8】

請求項７に記載の光通信システムが備える前記スリープ制御手段を有するＯＮＵ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、光加入者線終端装置（ＯＬＴ：Ｏｐｔｉｃａｌ Ｌｉｎｅ Ｔｅｒｍｉｎａｌ）及び光ネットワーク終端装置（ＯＮＵ：Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ Ｕｎｉｔ）を光ファイバ伝送路を介して接続して、光信号により送受信する光通信システムにおける低消費電力化技術に関する。

【背景技術】

【0002】

光ネットワークは、１つのＯＬＴが、１つあるいは複数のＯＮＵと、光ファイバ伝送路を介してポイントツーポイントあるいはポイントツーマルチポイントの通信を行うネットワークである。

【0003】

光ネットワークの低消費電力化のために、データトラヒックがない場合にＯＮＵの主要機能を停止させるＯＮＵスリープ機能が議論されている。その中でも、ＤｏｚｅやＣｙｃｌｉｃ ｓｌｅｅｐと呼ばれる手法は、ＩＴＵ−ＴのＧ．９８７．３やＩＥＥＥ１９０４．１などによって標準化が進められており、ＯＮＵの低消費電力化の有効な手法として期待されている。

【0004】

本明細書に関連する光通信システムの構成を図１に示す。光通信システムは、ＯＬＴ１、ＯＮＵ２、光ファイバ伝送路８及び光スプリッタ９から構成される。ＯＬＴ１は、ロジック部４１、送受信部４２及びＳＮＩ（Ｓｅｒｖｉｃｅ Ｎｏｄｅ Ｉｎｔｅｒｆａｃｅ）物理層部４３から構成される。ＯＮＵ２は、ロジック部１１、送受信部１２及びＵＮＩ（Ｕｓｅｒ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ）物理層部１３から構成される。

【0005】

Ｄｏｚｅでは、上りのデータトラヒックがないことをロジック部１１のＵＮＩ監視によって確認し、ロジック部４１によってスリープ制御を行い、ロジック部１１によって状態切替を行い、ＯＮＵ２は起床状態からＤｏｚｅ状態に移行する。Ｄｏｚｅ状態では、ＯＮＵ２は下りトラヒック受信に関わる機能を維持したまま、上りトラヒックの送信機能に関わる一部または全部を停止することで、消費電力を低減する。

【0006】

Ｃｙｃｌｉｃ ｓｌｅｅｐでは、上りのデータトラヒックがないことをロジック部１１のＵＮＩ監視によって確認し、下りのデータトラヒックもないことをロジック部４１のＳＮＩ監視によって確認し、ロジック部１１及びロジック部４１がその旨のメッセージを交換する。ロジック部４１によってスリープ制御を行い、ロジック部１１によって状態切替を行い、ＯＮＵ２は起床状態からＣｙｃｌｉｃ ｓｌｅｅｐ状態に移行する。

【0007】

ＯＮＵ２がＤｏｚｅ状態もしくはＣｙｃｌｉｃ ｓｌｅｅｐ状態の時にＯＮＵ２に上りトラヒックが入力されると、ＯＮＵ２はＤｏｚｅ状態もしくはＣｙｃｌｉｃ ｓｌｅｅｐ状態を解除しデータ疎通を開始する。

【0008】

ＯＮＵ２はＣｙｃｌｉｃ ｓｌｅｅｐ状態の時に上りトラヒック入力がない場合でも、あらかじめ決められたスリープ継続時間の後にスリープ継続確認のために起動する。Ｃｙｃｌｉｃ ｓｌｅｅｐ状態の間にＯＮＵ２あての下りトラヒックがＯＬＴ１へ入力されていた場合は、スリープ継続確認時にＯＬＴ１は下りトラヒックありのメッセージをＯＮＵ２に送信し、ＯＮＵ２はスリープ中止を判断し下りデータの受け取りを開始する。Ｃｙｃｌｉｃ ｓｌｅｅｐ中にＯＮＵ２あての下りトラヒックがＯＬＴ１へ入力されていない場合は、ＯＮＵ２は再びＣｙｃｌｉｃ ｓｌｅｅｐ状態に遷移する。

【0009】

上記のように、下りトラヒックがない場合には、Ｃｙｃｌｉｃ ｓｌｅｅｐ状態への移行とトラヒック確認の起動を周期的に繰り返すので、このスリープ方式をＣｙｃｌｉｃ ｓｌｅｅｐと呼ぶ。なお、以下の説明において、ＤｏｚｅとＣｙｃｌｉｃ ｓｌｅｅｐを区別しないときは単にスリープと記載する。

【0010】

スリープ中にＯＮＵ２のどの部分を停止させるかによって、消費電力と、スリープ状態に移行するまでにかかる時間と、スリープ状態から起床状態に移行するまでの時間が変化する。Ｇ．９８７．３では、下りトラヒックの受信機能に関わる部分を止めないＤｏｚｅと、スリープ状態で下りトラヒックの受信機能に関わる部分を止めてもよいＣｙｃｌｉｃ ｓｌｅｅｐが分けて記述されている。また、ＩＥＥＥ１９０４．１では、前者をＴｘスリープ、後者をＴＲｘスリープと記述している。

【0011】

スリープに入る条件として、遅延を低減するために一定時間トラヒックが到着しないことをトリガにする方式や、省電力効果を高めるためにキューに溜まっているフレームの量が閾値より小さくなったことをトリガとする方式が提案されている（例えば、非特許文献１を参照。）。

【先行技術文献】

【非特許文献】

【0012】

【非特許文献1】久保亮吾、可児淳一、藤本幸洋、吉本直人、雲崎清美、省電力機能を搭載した１０ギガクラスＰＯＮシステムの性能解析、電子情報通信学会信学技報、ＣＳ２００９−２、ｐｐ．７−１２

【発明の概要】

【発明が解決しようとする課題】

【0013】

ＴＣＰによるデータ伝送方式は、受信側においてデータの受信時にＡＣＫフレームを送信側へ返信する（図４（ａ）区間）。もし、送信側においてＡＣＫフレームを受け取れなかった時にデータを受信側へ再送することで、データの到達性を確保することができる。

【0014】

ＡＣＫフレームを受け取るまでに次のフレームを送れないと、往復遅延時間が大きい場合には、単位時間あたりに送信できるデータ量が著しく制限されるため、ＴＣＰではＡＣＫフレームを受け取るまでに複数のフレームを送信してよいウィンドウ制御を行う（図４の（ｂ）区間）。ウィンドウ制御では、ＡＣＫフレームを受け取るまでに送信可能なデータ量をウィンドウサイズで制限する。送信データのロストが生じると、輻輳が発生したと判断し、ウィンドウサイズを減らす。これによって、通信路が伝送できる以上のデータ量を送信することを防ぎ、輻輳を回避する。

【0015】

ＯＮＵ２の配下の端末がＴＣＰを用いてファイルのダウンロードなどを行う場合、下りデータがＴＣＰで連続的に送信され、ＯＮＵ２に下りトラヒックが到着する。また、ＯＮＵ２には、ＯＮＵ２配下の端末から送られたＡＣＫフレームが短い間隔で断続的に到着する（図４（ｃ）区間）。

【0016】

上述した一定時間トラヒックが到着しないことをトリガにするスリープ方式では、閾値よりもＡＣＫフレームの到着が短い場合に全くスリープに入ることができず、省電力効果が得にくいという課題があった。

【0017】

また、キューに溜まっているフレームの量を閾値とするスリープ方式においても、到着したＡＣＫフレームが閾値を超える度に起床する必要がある。頻繁に起床を繰り返す間、ＯＮＵ２の一部機能を停止するまでの時間と、該当機能を起動するまでの時間を要するため、ＡＣＫフレームの断続的な到着によって省電力効果が低減するという課題もあった。

【0018】

そこで、前記課題を解決するために、本発明は、ＴＣＰのトラヒックが流れている間であってもスリープによる省電力効果を得られるスリープ制御方法、光通信システム、及び光ネットワーク終端装置を提供することを目的とする。

【課題を解決するための手段】

【0019】

上記目的を達成するため、本発明は、スリープに入り易くするためにデータフレームに対するＡＣＫフレームを間引き、かつ、ＴＣＰの送信レート低減を抑制するために、輻輳ウィンドウを使い切るより前に１回以上ＡＣＫフレームを送信する。図５は、本発明におけるフレームの動作を説明した図である。本発明では、送信側からのデータフレームに対してＡＣＫフレームを毎回返送するのではなく、複数回に１度程度のＡＣＫフレームを返送する。このようにすることで、ＡＣＫフレームを送信するブロックをスリープさせる機会が増加する。

【0020】

具体的には本発明に係るスリープ制御方法は、光加入者線終端装置（ＯＬＴ：Ｏｐｔｉｃａｌ Ｌｉｎｅ Ｔｅｒｍｉｎａｌ）と光ネットワーク終端装置（ＯＮＵ：Ｏｐｔｉｃａｌ Ｎｅｔｗｏｒｋ Ｕｎｉｔ）とが光ファイバ伝送路を介して光通信を行う光通信システムにおいて、前記ＯＮＵを経由するトラヒックの単位時間当たりの量に基づいて前記ＯＮＵをスリープ状態又は起床状態とするスリープ制御方法であって、前記トラヒックに含まれる受信確認フレームと他のフレームとを区別して管理し、前記受信確認フレームを所定ルールに基づいて間引く間引き動作を行うことを特徴とする。

【0021】

本発明は、ＴＣＰトラヒックのＡＣＫフレーム（受信確認フレーム）を間引くように制御することで、ＯＮＵがスリープに入る機会を多くし、効率のよい低消費電力化を実現する。従って、本発明は、ＴＣＰのトラヒックが流れている間であってもスリープによる省電力効果を得られるスリープ制御方法を提供することができる。

【0022】

本発明に係るスリープ制御方法は、前記所定ルールについて、前記受信確認フレームのカウント開始からの数が、又は前記受信確認フレームのカウント開始時刻からの経過時間が、別途定めた閾値になるまで一定の要件に合致した複数の前記受信確認フレームをグルーピングし、少なくとも最新の受信確認フレームのみとしてもよい。

【0023】

ＡＣＫフレームのカウント開始から所定数に達するまで、又はＡＣＫフレームのカウント開始から所定時間が液化するまでに１度だけあるいは複数回だけＡＣＫフレームを送信可能とする。このようにＡＣＫフレームを間引くことでＯＮＵのスリープの機会を増やすことができる。

【0024】

キューに溜まっているフレームの量を閾値とするスリープ方式において、通信品質を鑑みずに閾値を非常に大きくした場合には、スリープによる省電力効果が得られる一方で、ＡＣＫフレームが戻らないことによるＴＣＰの送信レート低下や、更にはタイムアウトによってＴＣＰセッションが切れる恐れがある。送信レート低下やタイムアウトは、通信品質に影響を与えるだけでなく、通信時間が長くなり、スリープの機会損失にもなる。

【0025】

そこで、本発明に係るスリープ制御方法は、前記別途定めた閾値を、輻輳ウィンドウ、広告ウィンドウ、又は往復遅延時間を基に設定することが好ましい。ＴＣＰのトラヒックが流れている間であってもスリープによる省電力効果を得られ、かつ、ＴＣＰの送信レート低減およびセッション切断の抑制を両立できるスリープ制御方法、光通信システム、及び光ネットワーク終端装置を提供することが可能である。

【0026】

そこで、本発明に係るスリープ制御方法は、前記別途定めた閾値を、単位時間あたりの前記受信確認フレームの数を維持できる程度まで初期値から増加させていくとしてもよい。適切な閾値が不明な場合であっても、適応的に閾値を変更することで、送信レートを低下させずに適切な閾値を設定することが可能となる。

【0027】

そこで、本発明に係るスリープ制御方法は、受信確認番号が同じ前記受信確認フレームが一定数以上となった場合、前記ＯＮＵをスリープ状態から起床状態としてもよい。受信確認番号の重複はデータフレームが受信側へ伝達されていない証拠である。従って、受信確認番号が重複するＡＣＫフレームが存在したときＯＮＵを起床させることで送信側に欠落したデータフレームの再送を迅速に促すことができる。

【0028】

そこで、本発明に係るスリープ制御方法は、単位時間あたりの前記受信確認フレームの量が規定値以上になった場合、前記間引き動作を開始し、単位時間あたりの前記受信確認フレームの量が規定値未満になった場合、前記間引き動作を停止するとしてもよい。応答の高速性が求められるアプリケーションに対しても、受信確認フレームが即座に送信されるため、応答の高速性を損なわない制御が可能になる。

【0029】

前記スリープ制御方法は、光通信システム内のＯＬＴ、ＯＮＵ、ホームゲート装置（ＨＧＷ）のいずれかが受信確認フレームの間引き動作の機能を有することで実行される。

【発明の効果】

【0030】

本発明は、ＴＣＰのトラヒックが流れている間であってもスリープによる省電力効果を得られるスリープ制御方法、光通信システム、及び光ネットワーク終端装置を提供することができる。

【図面の簡単な説明】

【0031】

【図1】本発明に関連する光通信システムの構成を説明する図である。

【図2】本発明に係る光通信システムの構成を説明する図である。

【図3】本発明に係る光通信システムの構成を説明する図である。

【図4】本発明に関連するウィンドウ制御を説明する図である。

【図5】本発明に係るスリープ制御方法の効果を説明する図である。ＡＣＫフレームをＲＴＴ毎に１回程度返す。

【発明を実施するための形態】

【0032】

添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施の例であり、本発明は以下の実施形態に制限されるものではない。

【0033】

（実施形態１）
本実施形態の光通信システムでは、ＯＮＵがＡＣＫフレームを間引く。具体的には、ＯＮＵは送信機能ブロックをスリープ状態としておき、所定時のみ起床させる。ＯＮＵがこのように動作することでスリープの機会が増加する。ＡＣＫフレームはＯＮＵの起床時のみ転送されることになりＡＣＫフレームの間引きが行われる。また、ＡＣＫフレームの転送先の装置においてもＡＣＫフレーム到着間隔が長くなるので、受信ブロックのスリープ機会が増加する。

【0034】

［光通信システムの構成］
本実施形態の光通信システムの構成を図２に示す。光通信システムは、ＯＬＴ１、ＯＮＵ２及び光ファイバ伝送路３から構成される。図２において、１つのＯＬＴ１及び１つのＯＮＵ２が、光ファイバ伝送路３を介して、ポイントツーポイントで接続されているが、図１のように、１つのＯＬＴ１及び複数のＯＮＵ２が、光ファイバ伝送路３及び光スプリッタ９を介して、ポイントツーマルチポイントで接続されてもよい。

【0035】

［ＯＮＵの構成］
ＯＮＵ２は、トラヒック監視部２１、バッファ２２、送受信部２３、送信部２４、受信部２５、スリープ判断／指示部２６、及び受信確認フレーム監視部２８から構成される。

【0036】

［トラヒックが経由する各部の説明］
下りトラヒックは、ＯＬＴ１から、送受信部２３及び受信部２５を介して、下流側に伝送される。上りトラヒックは、下流側から、トラヒック監視部２１、バッファ２２、送信部２４及び送受信部２３を介して、ＯＬＴ１に伝送される。

【0037】

［トラヒック監視部の説明］
トラヒック監視部２１は、上りトラヒックがあるかどうかを監視する。そして、上りトラヒックがあることをスリープ判断／指示部２６に通知する。ＯＮＵ２のスリープ可能な各ブロックは、スリープ判断／指示部２６からの後述のスリープ開始指令を受けて、スリープ状態に移行する。そして、スリープ判断／指示部２６からの後述のスリープ解除指令を受けて、起床状態に移行する。

【0038】

［受信確認フレームの判別方法の説明］
トラヒック監視部２１は、受信確認フレームに該当するフレームの到着を検知し、受信確認フレームである場合にはスリープ判断／指示部２６に直接通知せず、受信確認フレーム監視部２８に通知する。受信確認フレームに該当するかどうかを判別するには、例えばフレームサイズが指定した値と等しいことや、特定のビットが指定した値と等しいことを用いる。ＴＣＰのＡＣＫフレームであれば、ＩＰヘッダのプロトコル番号がＴＣＰになっており、ＴＣＰヘッダのＡフラグがセットされており、ペイロード長さが０、つまりＥｔｈｅｒｎｅｔ（登録商標）フレーム長が、プリアンブルとインターフレームギャップを除いて６４バイトであることを確認することが例として挙げられる。

【0039】

［スリープ判断／指示部によるスリープ解除指令の説明］
スリープ判断／指示部２６は、上りトラヒックがあることをトラヒック監視部２１から通知される。そして、単位時間あたりの流量が別途定めた閾値を上回った際に、スリープ解除指令をスリープ可能な各ブロックに出力する。

【0040】

［スリープ判断／指示部２６によるスリープ開始指令の説明］
スリープ判断／指示部２６は、上りトラヒックがないと判断した際に、スリープ開始指令をスリープ可能な各ブロックへ出力する。上りトラヒックがないという判断は、例えば、上りトラヒックがあることをトラヒック監視部２１から通知されてからの一定時間の経過や、バッファ２２を監視し、特定のキューが空になったことをトリガにすることが挙げられる。

【0041】

［受信確認フレーム監視部の説明］
受信確認フレーム監視部２８は、トラヒック監視部２１から受信確認フレームに関わる情報を通知される。受信確認フレーム監視部２８は、この通知される情報を基に、スリープ判断／指示部２６に上りトラヒックの有無を通知する。

【0042】

［受信確認フレームのグルーピング（後述の（５）（８））］
受信確認フレーム監視部２８は、例えば、送信元ＩＰアドレスと送信先ＩＰアドレスの組み合わせが同じ受信確認フレームを１つのコネクションにおける受信確認フレーム群とみなし、同一のコネクションにおける受信確認フレームが、後述する受信確認フレーム数閾値を越えるまではスリープ判断／指示部２６に通知せず、受信確認フレーム数閾値を越えた時にスリープ判断／指示部２６に通知することで、受信確認フレームによるスリープ解除指令の出力回数を減じる。

【0043】

［受信確認フレームのグルーピング（後述の（６）（７））］
複数の受信確認フレームを同一コネクションとみなす判断基準として、送信元アドレスと送信先アドレスの組み合わせではなく、シーケンス番号が同一のものを同一コネクションとみなしてもよいし、受信確認番号の増加が一定範囲内である場合に同一コネクションとみなしてもよいし、これらを組み合わせて同一コネクションと判断してもよい。
ＴＣＰにおけるＡＣＫであれば、同一コネクションにおける確認応答パケットのシーケンス番号は同一である。
受信確認番号の増加は例えば、セグメントサイズが１４６０バイトに設定されている場合で、かつ２つのデータセグメントに対して１回のＡＣＫを返す遅延ＡＣＫが有効になっている場合を考慮し、受信確認番号の増分が２９２０以内である場合に同一コネクションとみなす例が挙げられる。

【0044】

［受信確認フレームの送信タイミングを時間の閾値で制御（後述の（９））］
また、受信確認フレーム監視部２８は、受信確認フレーム数閾値の代わりに受信確認フレーム時間閾値を設け、同一のコネクションにおける受信確認フレームを最後に送信してから受信確認フレーム時間閾値を越えるまではスリープ判断／指示部２６に通知せず、受信確認フレーム時間閾値を越えた時にスリープ判断／指示部２６に通知することで、受信確認フレームによるスリープ解除指令の出力回数を減じても良い。

【0045】

［広告ウィンドウサイズから数の閾値を設定（後述の（１０）（１３））］
受信確認フレーム監視部２８における、受信確認フレーム数閾値の設定は例えば、ＴＣＰにおけるＡＣＫであれば、受信確認フレーム内に記載されるウィンドウサイズを基に設定することが例として挙げられる。具体的には、受信確認フレームに記載されたウィンドウサイズが６５５３５バイトであり、受信確認フレームの受信確認番号の増分が２７２０である場合には、前回同一コネクションにおける受信確認フレームを送信してからの、受信確認番号の増分が、６５５３５から２７２０を差し引いた６２８１５を超えた時点でスリープ判断／指示部２６に通知してもよいし、６２８１５を２７２０で割ることで求まる受信確認フレーム数２３を超えた時点でスリープ判断／指示部２６に通知してもよいし、安全側の側面からこれらの値に０以上１以下の係数をかけた値を閾値として設定しても良い。

【0046】

［タイムスタンプ値から閾値を設定（後述の（１１）（１３））］
また、受信確認フレーム監視部２８における、受信確認フレーム時間閾値の設定は例えば、ＴＣＰにおけるＡＣＫであれば、受信確認フレーム内に記載されるタイムスタンプ値を基に設定することが例として挙げられる。

【0047】

［広告ウィンドウサイズから時間の閾値を設定（後述の（１０）（１３））］
また、受信確認フレーム監視部２８における、受信確認フレーム時間閾値の設定は、受信確認フレーム内に記載されるウィンドウサイズを基に設定してもよい。具体的には、受信確認フレームに記載されたウィンドウサイズが６５５３５バイトである場合には、前回同一コネクションにおける受信確認フレームを送信してからの、受信確認番号の増分が、６５５３５を超える時間をカウントし、安全側の側面からこの値に０以上１以下の係数をかけた値を閾値として設定しても良い。

【0048】

［他の機器から閾値の基になる値を取得（後述の（１７））］
また、受信確認フレーム監視部２８における、受信確認フレーム数閾値および受信確認フレーム時間閾値の設定は、ＯＮＵ２の配下に接続された、より正確に輻輳ウィンドウサイズや往復遅延時間を把握している機器から通知される値を基に設定しても良い。

【0049】

［受信確認フレームの到着間隔を基に設定（後述の（１８））］
また、受信確認フレーム監視部２８における、受信確認フレーム時間閾値の設定は、同一コネクションにおける受信確認フレームの到着間隔を基に設定してもよい。具体的には、ＴＣＰにおけるＡＣＫであれば、コネクション開始直後にウィンドウサイズが帯域遅延積よりも小さく、ＡＣＫ群の到着間隔が往復遅延時間とほぼ等しいことを用いて、受信確認フレームの到着間隔をカウントして受信確認フレーム時間閾値として設定してもよいし、安全側の側面からこの値に０以上１以下の係数をかけた値を閾値として設定しても良い。

【0050】

［本光通信システムの効果］
スリープ判断／指示部２６は、同一コネクションにおける受信確認フレームが多数到着した場合であっても、受信確認フレーム監視部２８からの通知を受けるまでは、スリープ可能な各ブロックに対してスリープ解除指令を送信しないため、スリープ可能な各ブロックはスリープ状態に長く滞在することができ、また、起動状態とスリープ状態の遷移回数も減じることができる。

【0051】

また、受信確認フレーム監視部２８における、受信確認フレーム時間閾値あるいは受信確認フレーム数閾値の設定により、ＴＣＰの送信端末がウィンドウサイズを使い切る間隔よりも短い周期で、受信確認フレーム監視部２８がスリープ判断／指示部２６に通知を送るため、ＯＮＵ２が起動状態に遷移し、受信確認フレームが送信され、ＴＣＰの送信端末がウィンドウサイズを使い切る前に受信確認フレームを受信できる。これにより、ＴＣＰの送信端末の送信レート低下やセッション切断を抑止できる。

【0052】

［閾値の可変（後述の（１２））］
また、受信確認フレーム監視部２８における、受信確認フレーム時間閾値あるいは受信確認フレーム数閾値の設定は、同一コネクションにおける受信確認フレームの単位時間あたりの受信数を監視し、送信レートが低下していないことを確認しながら受信確認フレーム時間閾値あるいは受信確認フレーム数閾値を小さな初期値から増加させていっても良い。

【0053】

具体的には、例えば受信確認フレーム数閾値の初期値を１に設定し、受信確認フレームを受信する度に受信確認フレーム監視部２８からスリープ判断／指示部２６へ通知を送る設定から開始し、この受信確認フレーム数閾値における受信確認フレームの単位時間あたりの受信数に、０以上１以下の係数をかけたものを、送信レート低下判断閾値として保持する。受信確認フレーム数閾値を指数的に増加させていき、受信確認フレームの単位時間あたりの受信数が送信レート低下判断閾値を下回った場合には、受信確認フレーム数閾値を１段階低いものに戻すことが例として挙げられる。増加方法は、指数的な増加の代わりに、比例的に増加させても良い。また、変化させる閾値は受信確認フレーム数閾値の代わりに、受信確認フレーム時間閾値としても良い。

【0054】

具体的には、例えばＴＣＰのＡＣＫの場合、ＯＮＵ２がＩＰヘッダやＴＣＰヘッダの内容を全ては取得できない場合が考えられ、例えばオプション扱いであるタイムスタンプは、送信端末と受信端末の両方で有効になっていない場合には取得することができない。このように、適切な閾値が不明な場合であっても、適応的に閾値を変更することで、送信レートを低下させない、適切な閾値を設定することが可能となる。

【0055】

本実施形態の光通信システムは、次に説明する機能を有していてもよい。
［受信確認フレームの間引き（後述の（１４））］
受信確認フレーム監視部２８は、同一コネクションの受信確認フレームのうち、受信確認番号が最新のものだけを残し、受信確認番号が古い受信確認フレームを破棄してもよい。古い受信確認フレームを破棄することにより、与えられた送信許可１回分でバッファ内に蓄積していた受信確認フレームを全て送信できる可能性が上がり、次の送信許可を待たずにスリープ状態に遷移することが可能となる。

【0056】

［ロス検知後即座に再送催促（後述の（１５））］
また、受信確認フレーム監視部２８は、同一コネクションの受信確認フレームのうち、
受信確認番号が重複した受信確認フレームを一定数以上連続して受信した場合は、即座にスリープ判断／指示部２６に通知を送っても良い。具体的には、例えばＴＣＰのＡＣＫの場合に、受信確認番号が重複した受信確認フレームを３つ以上受信した場合に、即座にスリープ判断／指示部２６に通知を送ることで、欠落したセグメントの再送を迅速に促すことができる。

【0057】

ＴＣＰ通信において、ＴＣＰの受信者は受信できたセグメントまでを受信確認番号に記載して受信確認フレームを送信する。このため、受信できなかったセグメントが存在する場合に、そのセグメントに連なるセグメントを受信する度に、受信確認番号が重複した受信確認フレームが送信される。ＴＣＰの送信者は、３つ以上の受信確認番号が重複した受信確認フレームを受信すると、欠落したセグメントの再送を行う。

【0058】

［レート増加遅延の抑制（後述の（１６））］
また、受信確認フレーム監視部２８は、同一コネクションにおける受信確認フレームの単位時間あたりの受信数が別途定める閾値を越えるまでは、受信確認フレームを受信する度にスリープ判断／指示部２６へ通知を送り、同一コネクションにおける受信確認フレームの単位時間あたりの受信数が別途定める閾値を下回るまでは、スリープ判断／指示部２６への通知を抑制してもよい。

【0059】

具体的には、例えば、ＴＣＰにおけるＡＣＫの場合、通信開始直後でＴＣＰの送信端末のウィンドウサイズが小さく帯域遅延積に到達していない間は、受信確認フレームを間引くと、ウィンドウサイズの増加が遅れる懸念がある。

【0060】

ＴＣＰ通信において、特に通信開始直後はスロースタートという、ＡＣＫの受信を契機にＴＣＰの送信端末がウィンドウサイズを指数的に増加させる仕組みがあり、この期間にＡＣＫの送信タイミングが遅れると、ウィンドウサイズの増加が遅れ得る。

【0061】

具体的な閾値の設定は、例えば、機械的に１ｓ中１０００フレームと決めても良く、この例では、フレームサイズを１２５０バイトとした時に、１０Ｍｂｐｓ以上の速度で通信が行われているコネクションに対してのみ、スリープ判断／指示部２６への通知が抑制されることになる。

【0062】

この閾値による制御の切り替えを導入することで、更に、単位時間あたりの受信数が少なく、応答の高速性が求められるアプリケーションに対しても、受信確認フレームが即座に送信されるため、応答の高速性を損なわない制御が可能になる。

【0063】

（実施形態２）
本実施形態の光通信システムでは、ホームゲートウェイ装置（ＨＧＷ）がＡＣＫフレームを検出し、ＯＮＵに対してＡＣＫフレームを間引くように指示する。具体的には、ＨＧＷはＯＮＵに対して送信機能ブロックをスリープ状態にさせておき、所定時のみ起床させる。ＨＧＷがこのように動作することでＯＮＵのスループの機会が増加する。ＡＣＫフレームはＯＮＵの起床時のみ転送されることになりＡＣＫフレームの間引きが行われる。また、ＡＣＫフレームの転送先の装置においてもＡＣＫフレーム到着間隔が長くなるので、受信ブロックのスリープ機会が増加する。

【0064】

［光通信システムの構成］
本実施形態の光通信システムの構成を図３に示す。光通信システムは、ＯＬＴ１、ＯＮＵ６、光ファイバ伝送路３、およびＨＧＷ５から構成される。図２で示した実施例１との構成の違いは、ＯＮＵ６の配下にＨＧＷ５が接続されている点である。

【0065】

［ＯＮＵの構成］
ＯＮＵ６は、バッファ６２、送受信部６３、送信部６４、受信部６５及びスリープ判断スイッチ部６７から構成される。

【0066】

［ＨＧＷの構成］
ＨＧＷ５は、トラヒック監視部５１、バッファ５２、送受信部５３、スリープ判断部５６及び受信確認フレーム監視部５８から構成される。

【0067】

［トラヒックが経由する各部の説明］
下りトラヒックは、ＯＬＴ１から、送受信部６３、受信部６５および送受信部５３を介して、下流側に伝送される。上りトラヒックは、下流側から、トラヒック監視部５１、バッファ５２、送受信部５３、スリープ判断スイッチ部６７、バッファ６２、送信部６４及び送受信部６３を介して、ＯＬＴ１に伝送される。

【0068】

［トラヒック監視部、スリープ判断部、スリープ指示部の説明］
トラヒック監視部５１は、上りトラヒックがあるかどうかを監視する。そして、上りトラヒックがあることをスリープ判断部５６に通知する。スリープ判断部５６は、別途設けるスリープの閾値に従い、単位時間あたりの起床すべきトラヒック量が到着していないと判断した場合にはＯＮＵ６宛にスリープ開始指令を送信する。また、スリープ判断部５６は、別途設けるスリープの閾値に従い、単位時間あたりの起床すべきトラヒック量が到着していると判断した場合にはＯＮＵ６宛にスリープ解除指令を送信する。

【0069】

スリープ判断スイッチ部６７は、ＨＧＷ５から送信されたスリープ開始指令もしくはスリープ解除指令を受信した際には、ＯＮＵ６のスリープ可能な各ブロックに対してスリープ指令を通知し、それ以外のフレームはバッファ６２へ転送する。ＯＮＵ６のスリープ可能な各ブロックは、スリープ判断スイッチ部６７からのスリープ開始指令を受けて、スリープ状態に移行する。そして、スリープ判断スイッチ部６７からのスリープ解除指令を受けて、起床状態に移行する。

【0070】

実施形態１との違いは、スリープ判断をＯＮＵ６ではなく、ＨＧＷ５が行うことによって、ＯＮＵ６の構成をより単純化している。また一般的に、ＯＮＵと比較してＨＧＷには、より上位レイヤの制御機能が付属していることが多いため、受信確認フレーム監視部５８の実現が比較的容易である。

【0071】

トラヒック監視部５１は、受信確認フレームに該当するフレームの到着を検知し、受信確認フレームである場合にはスリープ判断部５６に直接通知せず、受信確認フレーム監視部５８に通知する。受信確認フレーム監視部５８の動作は、実施形態１で説明した受信確認フレーム監視部２８の動作と同様である。

【0072】

以下は、実施形態１及び２の光通信システムをまとめたものである。
［課題］
ＰＯＮ方式にスリープ方式を採用した場合、ＴＣＰトラヒックが流れていると、そのＡＣＫフレームを起因として、全くスリープに入れない場合があり低消費効率が低下するという課題があった。そこで、本光通信システムは、ＴＣＰトラヒックのＡＣＫフレームの送信回数を制御することで、ＯＮＵがスリープに入る機会を多くし、効率のよい低消費電力化を実現する。

【0073】

（１）［ＯＮＵがＡＣＫを特別扱いする］
ＯＮＵを備える光通信システムであって、前記ＯＮＵは、観測するトラヒックの単位時間あたりの量が、一定量を下回ると判断した時に起床状態からスリープ状態に移行し、
前記ＯＮＵは、観測したトラヒックに受信確認フレームが含まれると判断した時に、受信確認フレームについては観測するトラヒックの単位時間あたりの量として、他のフレームとは異なる算出方法を用いることを特徴とする光通信システム。

【0074】

（２）［ＨＧＷがＡＣＫを間引く］
ＯＮＵおよびＨＧＷを備える光通信システムであって、前記ＯＮＵは、観測するトラヒックの単位時間あたりの量が、一定量を下回ると判断した時に起床状態からスリープ状態に移行し、
前記ＨＧＷは、観測したトラヒックに受信確認フレームが含まれると判断した時に、受信確認フレームの送信回数を減じることを特徴とする光通信システム。

【0075】

（３）［ＯＬＴがＡＣＫを間引く（下り）］
ＯＬＴ及びＯＮＵを備える光通信システムであって、前記ＯＮＵは、観測するトラヒックの単位時間あたりの量が、一定量を下回ると判断した時に起床状態からスリープ状態に移行し、
前記ＯＬＴは、観測したトラヒックに受信確認レームが含まれると判断した時に、受信確認フレームの送信回数を減じることを特徴とする光通信システム。

【0076】

（４）［ＡＣＫ送信側のエンドがＡＣＫ送信回数を減らす］
ＯＮＵを備える光通信システムを介して通信を行う通信端末であって、前記ＯＮＵは、観測するトラヒックの単位時間あたりの量が、一定量を下回ると判断した時に起床状態からスリープ状態に移行し、
前記通信端末は、通信相手から送信されたデータフレームに対する、受信確認フレームの送信回数を減じることを特徴とする、通信端末。

【0077】

（５）［ＡＣＫのグルーピングを、宛先と送信元のペアで行う］
フレームに記載された宛先と送信元から、連続した受信確認フレームであることを判断することを特徴とする、（１）〜（４）のいずれかに記載の光通信システム、および通信端末。

【0078】

（６）［ＡＣＫのグルーピングを、ＡＣＫ番号の増分が閾値以下で行う］
前回に受信した受信確認フレームに記載された受信確認番号から、受信した受信確認フレームの受信確認番号との増分が指定した閾値以内である場合に、連続した受信確認フレームであることを判断することを特徴とする、（１）〜（４）のいずれかに記載の光通信システム、および通信端末。

【0079】

（７）［ＡＣＫのグルーピングを、シーケンス番号で行う］
フレームに記載されたシーケンス番号から、連続した受信確認フレームであることを判断することを特徴とする、（１）〜（４）のいずれかに記載の光通信システム、および通信端末。

【0080】

（８）［ＡＣＫを送信するタイミングを、数の閾値で決める場合］
受信した受信確認フレームの数が別途定めた閾値以上になった時に、受信確認フレームのうち、少なくとも、最も受信確認番号が進んでいる受信確認フレームを送信することを特徴とする、（５）〜（７）のいずれかに記載の光通信システム、および通信端末。

【0081】

（９）［ＡＣＫを送信するタイミングを、時間の閾値で決める場合］
受信した受信確認フレームのうち、最初に受信した時間から、別途定めた閾値以上経過した時に、受信確認フレームのうち、少なくとも、最も受信確認番号が進んでいる受信確認フレームを送信することを特徴とする、（５）〜（７）のいずれかに記載の光通信システム、および通信端末。

【0082】

（１０）［受信ＡＣＫの閾値を輻輳ウィンドウを基に設定する場合］
受信確認フレームの閾値を、輻輳ウィンドウもしくは広告ウィンドウを基に算出することを特徴とする、（８）又は（９）に記載の光通信システム、および通信端末。

【0083】

（１１）［受信ＡＣＫの閾値を往復遅延時間を基に設定する場合］
受信確認フレームの閾値を、往復遅延時間を基に算出することを特徴とする、（８）又は（９）に記載の光通信システム、および通信端末。

【0084】

（１２）［受信ＡＣＫの閾値を可変にする場合］
受信確認フレームの閾値を、単位時間あたりに受信する受信確認フレームの数が減少しない間、初期値から増加させていくことを特徴とする、（８）又は（９）に記載の光通信システム、および通信端末。

【0085】

（１３）［閾値をスヌープして取得する場合］
受信確認フレームの閾値の算出の基準として用いる、ウィンドウサイズまたは往復遅延時間を、受信確認フレームのスヌープによって取得することを特徴とする、（１０）又は（１１）に記載の光通信システム、および通信端末。

【0086】

（１４）［ＡＣＫを間引く］
受信確認フレームを、最も受信確認番号が進んでいるフレームだけを残し、それ以外の受信確認フレームを破棄することを特徴とする、（８）又は（９）に記載の光通信システム、および通信端末。

【0087】

（１５）［ロス検知後すぐに送信］
受信確認番号が同じ受信確認フレームを、別途定める閾値以上受信した際には受信確認フレームを即座に送信することを特徴とする、（８）又は（９）に記載の光通信システム、および通信端末。

【0088】

（１６）［レート増加遅延を抑止する］
単位時間あたりに受信する受信確認フレームの量が別途定める閾値以上になった際に、受信確認フレームの送信数を減ずる動作を開始し、別途定める閾値以下になった際に、受信確認フレームの送信数を減ずる動作を停止することを特徴とする、（８）又は（９）に記載の光通信システム、および通信端末。

【0089】

（１７）［他の端末から閾値を通知される］
受信確認フレームの閾値の算出の基準として用いる、往復遅延時間、または輻輳ウィンドウの値を、他の端末から通知され、設定することを特徴とする、（８）又は（９）に記載の光通信システム、および通信端末。

【0090】

（１８）［ＲＴＴを、ＡＣＫ群の到着間隔から取得する］
受信確認フレームの閾値の算出の基準として用いる、往復遅延時間を、受信確認フレームの到着間隔から取得し、設定することを特徴とする、（１１）に記載の光通信システム。

【0091】

これらの構成によれば、ＴＣＰ通信のように受信確認を返す必要のある通信が行われている場合であっても、通信レートを制限しない、単位時間あたりの受信確認の送信回数がわかるので、これを基に受信確認の送信回数や送信周期を設定することができる。

【0092】

本発明は、ＴＣＰ通信のように受信確認を返す必要のある通信において、通信レートを制限しない範囲で受信確認の送信頻度を減じることにより、スリープに有効なアイドル時間確保に伴う省電力効果と、通信品質の維持を両立する技術を提供することができる。

【産業上の利用可能性】

【0093】

本発明は、ＯＬＴ及びＯＮＵを備えるＰＯＮにおける低消費電力化技術として適用することができる。

【符号の説明】

【0094】

１：ＯＬＴ
２、６：ＯＮＵ
３、８：光ファイバ伝送路
５：ＨＧＷ
９：光スプリッタ
１１：ロジック部
１２：送受信部
１３：ＵＮＩ物理層部
２１、５１：トラヒック監視部
２２、５２、６２：バッファ
２３、５３、６３：送受信部
２４、６４：送信部
２５、６５：受信部
２６：スリープ判断／指示部
２８：受信確認フレーム監視部
４１：ロジック部
４２：送受信部
４３：ＳＮＩ物理層部
５６：スリープ判断部
６７：スリープ判断スイッチ部

【図1】

【図2】

【図3】

【図4】

【図5】