JP5938011B2 - 光通信システム及び衝突検出方法 - Google Patents

Description

本発明は、光通信システム及び衝突検出方法に関する。

通信事業者側に設置されるＯＬＴ（Optical Line Terminal：局側光回線終端装置）と、加入者側に設置されるＯＮＵ（Optical Network Unit：加入者側光回線終端装置）とがイーサネット（登録商標、以下同様）フレームにより通信を行うＰＯＮ（Passive Optical Network：アクセス網形態の１つ）はＥＰＯＮ（Ｅｔｈｅｒｎｅｔ（登録商標、以下同様） ＰＯＮ）と呼ばれる。
また、ＥＰＯＮのうち、伝送速度が１ＧｂｐｓであるＧＥ−ＰＯＮ（Gigabit Ethernet PON）は、高速かつ安価なＦＴＴＨ（Fiber To The Home：光ファイバーを伝送路として加入者宅へ直接引き込む、アクセス系光通信の網構成方式）サービスを提供することができる。このため、ＧＥ−ＰＯＮは、特に国内では広く用いられている。最近では、伝送速度を１０Ｇｂｐｓに高速化した１０Ｇ−ＥＰＯＮの標準仕様が検討されている。

また、近年では、ＰＯＮ用光リピータの検討が進められ、標準規格を拡張して、分岐数を増大することが可能となった。具体的には、これまでのＰＯＮでは光信号強度の制約から３２分岐以下で使われることが多かったのに対し、１０００分岐などの多分岐接続が可能となった。
一般に、ＰＯＮにおいては、ＯＬＴからＯＮＵへの通信の方向を下り方向と呼び、ＯＮＵからＯＬＴへの通信の方向を上り方向と呼ぶ。

１０Ｇ−ＥＰＯＮの標準仕様では、上り信号のＦＥＣ（Forward Error Correction：前方誤り訂正）が必須とされている。１０Ｇ−ＥＰＯＮでは、リードソロモン（２５５，２２３）という方式のＦＥＣが用いられる。
リードソロモン（２５５，２２３）は、２２３Ｂｙｔｅの送信信号に対し３２Ｂｙｔｅの誤り訂正用パリティ信号を多重させ、ノイズ等による元信号の消失をパリティ信号により復元する誤り訂正符号である。送信信号は２５５ＢｙｔｅのＦＥＣ信号ブロック単位（以下、ＦＥＣコードワードという）で送信される。
１Ｇ−ＥＰＯＮでは、ＦＥＣはオプション項目とされ、必要に応じて実装される。１Ｇ−ＥＰＯＮにおいてＦＥＣが用いられる場合には、例えばリードソロモン（２５５，２３９）が用いられる。

ＥＰＯＮを始めとする多くのＰＯＮでは、上り方向の通信は時分割多元接続によって行われる。ＯＬＴにより、それぞれのＯＮＵの送信タイミングを制御することで、複数のＯＮＵがＯＬＴと時分割通信できるようにしている。１０Ｇ−ＥＰＯＮの上り方向の通信も同様に時分割多元接続により行われる。１０Ｇ−ＥＰＯＮでは、１台のＯＬＴに、上り伝送速度が異なる複数のＯＮＵが接続できる方式が検討されている。このとき、異なる速度のＯＮＵとの間であっても、時分割多元接続により上り通信を実現する。

上り方向の通信が時分割多元接続によって行われる多くのＰＯＮでは、上り帯域を効率的に使用するために、それぞれのＯＮＵについての上り通信を許可する時間の長さを、通信の状況に応じて動的に変更するという動的帯域割当機能を備えている。
ここで、ＰＯＮにおけるＯＮＵごとの帯域は、例えばＯＬＴが各ＯＮＵに対して送信許可量を算出し、その送信時間帯を排他的に確保することにより、割り当てることができる。ＯＮＵはＯＬＴによって割り当てられた時間帯にのみ上りデータを送信する。このため、割り当てられた時間帯を待つための待ち時間は伝送遅延時間に加算される。

ＥＰＯＮには、ＭＰＣＰ（Multi Point-Control Protocol）と呼ばれる、１つのＯＬＴが複数のＯＮＵの通信を制御するためのプロトコルが標準で定められている。ＭＰＣＰとしては、未登録のＯＮＵを検出するためのDiscovery Processingと、ＯＮＵの上り信号の送信タイミングを制御するためのREPORT Processing・GATE Processingとが知られている（例えば、非特許文献１参照）。

ＥＰＯＮでは、ＯＮＵがＰＯＮに接続されると、ＯＬＴはそのＯＮＵを発見し、ＯＮＵにＬＬＩＤを付与して通信リンクを自動的に確立する。この機能をＰ２ＭＰディスカバリ（Point to multi-point Discovery）と呼ぶ。ＭＰＣＰのDiscovery Processingは、Ｐ２ＭＰディスカバリを実現するためのプロトコルである。

図１７のシーケンス図は、Discovery ProcessingとしてのＰ２ＭＰディスカバリ処理における通信手順を示している。
Discovery Processingにおいて、先ず、ＯＬＴは、Discovery Information（問い合わせ）を格納したＧＡＴＥフレーム（以下、Discovery GATE）を各ＯＮＵに対して送信して、送信タイミングを通知する（ステップＳ１）。
ＧＡＴＥフレームには、図１７に示すようにパラメータが含まれるが、これらのパラメータは、公知のパラメータであるため、ここでは詳細な説明を省略する。
ＧＡＴＥフレームは、Messages sent on broadcast cannelを用いて送信される。

次に、ＯＬＴに未登録のＯＮＵは、Discovery GATEを受信すると、衝突回避のためランダム待ち時間（Random delay）Ｔ_Ｒの時間だけ待ってから、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを送信する（ステップＳ２）。このＲＥＧＩＳＴＥＲ＿ＲＥＱフレームは、Messages sent on broadcast cannelを用いて送信される。これを受けて、ＯＬＴは、ＯＮＵからのＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを受信する可能性のある時間だけDiscovery Windowを設定し、設定したDiscovery Windowの期間において未登録の各ＯＮＵからのＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを受信する。

次に、ＯＬＴはＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの受信に応じて、ＲＥＧＩＳＴＥＲフレームにより、ＯＮＵ（またはＵＮＩポート）の識別子であるＬＬＩＤ（Logical Link.ID）を通知する（ステップＳ３）。
ＲＥＧＩＳＴＥＲフレームは、Messages sent on broadcast cannelを用いて送信される。

続いて、ＯＬＴは、ＧＡＴＥフレームによりＯＮＵの上り送信許可タイミングを通知し（ステップＳ４）、ＯＮＵは通知された許可タイミングに従ってＲＥＧＩＳＴＥＲ＿ＡＣＫを返す（ステップＳ５）。
上記ステップＳ１〜Ｓ５の各処理により、Ｐ２ＭＰディスカバリ処理が実現されている。このＧＡＴＥフレームと、ＲＥＧＩＳＴＥＲ＿ＡＣＫは、Messages sent on unicast cannelsを用いて送信される。

ここで、Discovery Windowの時間帯において、登録済のＯＮＵは上り方向の送信を行うことはできない。前述のように、ＥＰＯＮの上り方向の通信では、ＯＬＴが各ＯＮＵに対して送信許可量を算出、通知し、その送信時間帯を確保する。Discovery Windowの時間帯は、未登録のＯＮＵからの上り信号（ＲＥＧＩＳＴＥＲ＿ＲＥＱフレーム）が受信される可能性があるため、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレーム以外の信号との衝突を回避するために、登録済みのＯＮＵによる上り方向の送信は許可しない。

IEEEstd802_3-2008sec5_Access.pdf (P264、265)

Ｐ２ＭＰディスカバリ処理のシーケンスにおいて、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの衝突が生じた場合、衝突したＲＥＧＩＳＴＥＲ＿ＲＥＱフレームは廃棄される。この場合、廃棄されたＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの送信元のＯＮＵについてはＰ２ＭＰディスカバリのシーケンスは完了せず、ＯＬＴとのリンクが確立しない。
この場合、衝突したＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの送信元のＯＮＵは、次回のＰ２ＭＰディスカバリ処理により再度登録処理を行う必要がある。
特に、ランダム待ち時間Ｔ_Ｒが短い場合や、リンクを確立すべきＯＮＵ数が多い場合には衝突が発生する可能性が高くなり、Ｐ２ＭＰディスカバリ処理が完了してＯＮＵが通信を開始できるまでに長い時間を要する場合がある。

通信システムにおいて、一般には、リンクの確立から通信開始までの時間が短い方が通信性能は高い。
ＥＰＯＮにおいてＰ２ＭＰディスカバリ処理が実行される間隔は、０．１〜１．５ｓｅｃほどと長い。このために、Ｐ２ＭＰディスカバリ処理について１度のリトライが生じるだけでも遅延への影響度は大きい。さらに、システム起動時などのように多数のＯＮＵと同時にＰ２ＭＰディスカバリ処理を実行する場合には、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの信号の衝突の可能性が増大する。このような状態では、２回以上のリトライとなる場合もあり遅延がさらに拡大する。
このような衝突の発生による通信遅延を抑制するには、例えば、信号の衝突を検出して検出結果に応じて復元などの処理を行うことが有効であるが、この際に衝突検出の精度が低いと復元率なども低下することなる。

本発明は、このような事情に鑑みてなされたもので、局側光回線終端装置が複数の加入者側光回線終端装置から受信した登録要求信号の衝突についての検出精度の向上を図ることを目的とする。

本発明の一態様は、局側光回線終端装置と、前記局側光回線終端装置と光通信路経由で接続される加入者側光回線終端装置とを備え、前記局側光回線終端装置は、複数の加入者側光回線終端装置から受信した登録要求信号を対象として、他の登録要求信号と衝突している衝突部分と他の登録要求信号と衝突していない非衝突部分とを検出する衝突検出部を備える光通信システムである。

本発明の一態様は、上記の光通信システムであって、前記衝突検出部は、登録要求信号のサイズに基づいて決まる登録要求信号の信号継続時間と、複数の登録要求信号が受信されたときの受信継続時間とに基づいて、衝突部分と非衝突部分とを検出する。

本発明の一態様は、上記の光通信システムであって、前記衝突検出部は、受信される登録要求信号の受信光強度が一定以上のレベル変化を示すタイミングに基づいて、衝突部分と非衝突部分とを検出する。

本発明の一態様は、上記の光通信システムであって、前記加入者側光回線終端装置は、前記局側光回線終端装置にて受信される登録要求信号の受信光強度が予め定めた規定値となるように、前記局側光回線終端装置との通信距離に応じて定めた送信光強度により登録要求信号を送信する登録要求送信部を備え、前記衝突検出部は、複数の登録要求信号が受信された期間における受信光強度の前記規定値に対する比率に基づいて衝突部分と非衝突部分とを検出する。

本発明の一態様は、上記の光通信システムであって、前記加入者側光回線終端装置は、一定間隔による既知パターンビット列の挿入部分を含む登録要求信号を送信する登録要求送信部を備え、前記衝突検出部は、受信された複数の登録要求信号における既知パターンビット列の検出の有無に基づいて衝突部分と非衝突部分とを検出する。

本発明の一態様は、局側光回線終端装置と、前記局側光回線終端装置と光通信路経由で接続される加入者側光回線終端装置とを備える光通信システムにおける衝突検出方法であって、前記局側光回線終端装置において、複数の加入者側光回線終端装置から受信した登録要求信号を対象として、他の登録要求信号と衝突している衝突部分と他の登録要求信号と衝突していない非衝突部分とを検出する衝突検出ステップを備える衝突検出方法である。

以上説明したように、本発明によれば、局側光回線終端装置が複数の加入者側光回線終端装置から受信した登録要求信号の衝突についての検出精度の向上が図られるという効果が得られる。

第１実施形態における光通信システムの構成例を示す図である。 Ｐ２ＭＰディスカバリ処理におけるＤｉｓｃｏｖｅｒｙ ＧＡＴＥフレームとＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの送受信タイミングの一例を示す図である。 ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの構造例を示す図である。 ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを格納したＦＥＣコードワード（ＲＥＧＩＳＴＥＲ＿ＲＥＱブロック）の構造例を示す図である。 第１実施形態におけるＯＬＴとＯＮＵの構成例を示す図である。 第１実施形態における衝突検出の手法例を示す図である。 第１実施形態におけるＯＬＴとＯＮＵが実行するＰ２ＭＰディスカバリ処理の手順例を示すフローチャートである。 第１実施形態における衝突検出部が実行する衝突検出のための処理手順例を示すフローチャートである。 第２実施形態における衝突検出の手法例を示す図である。 第２実施形態における衝突検出部が実行する衝突検出のための処理手順例を示すフローチャートである。 第３実施形態における衝突検出の手法例を示す図である。 第３実施形態におけるＯＬＴとＯＮＵが実行するＰ２ＭＰディスカバリ処理の手順例を示すフローチャートである。 第３実施形態における衝突検出部が実行する衝突検出のための処理手順例を示すフローチャートである。 第４実施形態におけるＯＮＵが生成するＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの送信信号の構造例を示す図である。 第４実施形態におけるＯＬＴとＯＮＵが実行するＰ２ＭＰディスカバリ処理の手順例を示すフローチャートである。 第４実施形態における衝突検出部が実行する衝突検出のための処理手順例を示すフローチャートである。 Ｐ２ＭＰディスカバリ処理における通信手順例を示すシーケンス図である。

＜第１実施形態＞
図１は本実施形態における光通信システムの構成例を示している。同図に示す光通信システムは、１０Ｇ−ＥＰＯＮに対応する。
同図に示す光通信システムは、１つのＯＬＴ（Optical Line Terminal：局側光回線終端装置）と複数のＯＮＵ（Optical Network Unit：加入者側光回線終端装置）２００−１〜２００−Ｎとが光通信路５００を介して接続される。
なお、以降の説明において、ＯＮＵ２００−１〜２００−Ｎについて特に区別しない場合には、ＯＮＵ２００と記載する。

ＯＬＴ１００は、通信事業者側に設置される光回線終端装置である。ＯＬＴ１００の上流に対しては上位ネットワーク３００が接続される。上位ネットワーク３００は、例えばインターネット上などに存在する各種のサーバなどを含む。
ＯＬＴ１００は、例えば上位ネットワーク３００と光通信路５００との間の通信において、電気信号と光信号との間での信号変換を行ったり、信号の多重化などを行ったりする。

ＯＮＵ２００は、加入者側に設置される光回線終端装置である。ＯＮＵ２００（２００−１〜２００−Ｎ）の下流側には、下位ネットワーク４００（４００−１〜４００−Ｎ）が接続される。下位ネットワーク４００には、例えば加入者の自宅などで使用されるパーソナルコンピュータなどをはじめとしたネットワーク機器が含まれる。

上記のように構成される光通信システムにおいて、ＯＬＴ１００側で未登録のＯＮＵ２００は、ＯＬＴ１００とのリンクが確立されないためにＯＬＴ１００と通信を行うことができない。そこで、ＯＬＴ２００に未登録のＯＮＵ２００については、ＯＬＴ１００とのリンクを確立して通信が可能な状態とする必要がある。
このために、ＯＬＴ１００と未登録のＯＮＵ２００との間では、図１７に示した手順によるＰ２ＭＰディスカバリ処理を実行する。

そのうえで、Ｐ２ＭＰディスカバリ処理におけるＤｉｓｃｏｖｅｒｙ ＧＡＴＥフレームとＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの送受信は、例えば図２に示すタイミングで実行される。なお、図１７との対応では、同図に示されるＤｉｓｃｏｖｅｒｙ ＧＡＴＥフレームの送受信はステップＳ１に対応し、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの送受信はステップＳ２に対応する。

図２において、先ず、ＯＬＴ１は、時刻ｔ_０においてＤｉｓｃｏｖｅｒｙ ＧＡＴＥフレームをブロードキャストにより、各ＯＮＵ２００に対して送信する。Ｄｉｓｃｏｖｅｒｙ ＧＡＴＥフレームには、ランダム待ち時間Ｔ_Ｒと、ランダム待ち時間Ｔ_Ｒの開始時刻ｔ_１とを指定する情報を含む。
標準の手順に従った場合、未登録のＯＮＵ２００はＤｉｓｃｏｖｅｒｙ ＧＡＴＥフレームの受信に応答して、Ｄｉｓｃｏｖｅｒｙ ＧＡＴＥフレームにより指定されたランダム待ち時間Ｔ_Ｒ内にＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを送信する。ＯＮＵ２００の通信距離を、許容範囲における最長の通信距離とすると、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームが到着する可能性のある時間Ｔ_Ｄ０が図２に示すＤｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗとなる。

Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの時間Ｔ_Ｄ０は、ＯＬＴ１００がＤｉｓｃｏｖｅｒｙ ＧＡＴＥフレームを送信するタイミングに基づいて設定する。Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗは、未登録のＯＮＵ２００からのＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを優先して受け付ける期間である。前述のように、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの時間Ｔ_Ｄ０において、登録済のＯＮＵ２００はＯＬＴ２００に対する上り方向の送信を行うことはできない。これにより、登録済のＯＮＵ２００から送信される信号と、未登録のＯＮＵ２００から送信されるＲＥＧＩＳＴＥＲ＿ＲＥＱフレームとの衝突については回避することができる。

また、標準の手順に加えて、ＯＮＵ２００側でＯＬＴ１００との通信距離に応じてランダム待ち時間の開始時刻を調整することができる。
ＯＬＴ１００との通信距離が最長距離よりも短いＯＮＵ２００は、その通信距離に応じた時間Ｔ_Ａだけランダム時間の開始を遅らせることで、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗを同図において短縮ＤＷ（Discovery Window）として示す時間Ｔ_Ｄ１に短縮することができる。短縮ＤＷとしての時間Ｔ_Ｄ１は、ランダム待ち時間Ｔ_Ｒに距離の誤差を許容するためのマージンを加えた値となる。
本実施形態においては、標準に従ったＤｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗを使用したＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの送受信と、短縮ＤＷを使用したＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの送受信のいずれが適用されてもよい。

ＯＬＴ１００は、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを正常に受信した場合、標準に従って以降の処理を実行する。
しかし、図２に示すように、複数のＯＮＵ２００が送信したＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの受信時間が重複して、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの衝突が発生する場合がある。同図では、２つのＲＥＧＩＳＴＥＲ＿ＲＥＱフレームが衝突している例が示されている。

ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの衝突が発生した場合、その衝突部分の信号については十分な信頼性が確保できないために破棄していた。このようにＲＥＧＩＳＴＥＲ＿ＲＥＱフレームが破棄された場合、衝突したＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの送信元のＯＮＵ２００はＯＬＴ１００に登録されないために、次回のＰ２ＭＰディスカバリ処理においてリトライのための通信が実行される。このようなリトライが通信時間の遅延を招き、例えば光通信システムにおける通信性能劣化の要因となる。

そこで、本実施形態においては、以下に説明するように、ＯＬＴ１００にて受信されたＲＥＧＩＳＴＥＲ＿ＲＥＱフレームに衝突が発生した場合には、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの信号における衝突部分と非衝突部分を検出する衝突検出を行い、衝突検出の検出結果を利用して衝突が発生したＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを復元する。
復元が成功すれば、ＯＬＴ１００は復元されたＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを利用して以降の登録のための処理を実行できるために、Ｐ２ＭＰディスカバリ処理のリトライが不要となる。これにより、通信時間の遅延が抑制され、例えば光通信システムにおける通信性能が向上する。
そのうえで、本実施形態においては、以降説明するように衝突検出を行う。本実施形態の衝突検出では、単に衝突の有無を検出するのにとどまらず、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームにおける衝突部分と非衝突部分とを検出する。この結果、本実施形態においては、高い精度で衝突検出を行える。また、本実施形態では、衝突部分と非衝突部分との検出結果を利用してＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを復元する。これにより、例えばＦＥＣによる誤り訂正のみにより復元する場合と比較して高い復元率を得ることができる。

図３は、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの構造例を示している。
同図に示すＲＥＧＩＳＴＥＲ＿ＲＥＱフレームは、６４Ｂｙｔｅであり、６ＢｙｔｅのＤＡ（Destination Address）フィールド、６ＢｙｔｅのＳＡ（Source Address）フィールド、２ＢｙｔｅのＴｙｐｅフィールド、２ＢｙｔｅのＯｐｃｏｄｅフィールド、４ＢｙｔｅのＴｉｍｅ ｓｔａｍｐフィールド、４０ＢｙｔｅのＤａｔｅ／Ｒｅｓｅｒｖｅｄ／ＰＡＤフィールド、４ＢｙｔｅのＦＣＳ（Frame Check Sequence）フィールドを含む。
Ｏｐｃｏｄｅフィールドは、当該フレームがＲＥＧＩＳＴＥＲ＿ＲＥＱフレームであることを示す「００−０４」を格納する。
ＤＡフィールドは、宛先であるＯＬＴ１００のＭＡＣアドレスを格納する。
ＳＡフィールドは、送信元であるＯＮＵ２００のＭＡＣアドレスを格納する。
「Ｔｉｍｅ ｓｔａｍｐ」フィールドは、当該ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームの送信時刻を格納する。
ＦＣＳフィールドは、ＦＣ方式に対応する誤り検出符号を格納する。

ＯＮＵ２００は、図３に示すＲＥＧＩＳＴＥＲ＿ＲＥＱフレームをＯＬＴ１００に送信するにあたり、ＦＥＣ（Forward Error Correction：前方誤り訂正）の誤り訂正方式に従って誤り訂正符号化を行う。そして、ＯＮＵ２００は、誤り訂正符号化により得られたＦＥＣコードワードによりＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを送信する。

図４は、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを格納したＦＥＣコードワードの構造例を示している。
同図に示すＦＥＣコードワードは、全体で２５５Ｂｙｔｅである。ＦＥＣコードワードにおいて、先頭にはＦＥＣに対応した３２Ｂｙｔｅによる誤り訂正用のパリティ信号が配置され、続けて、６４ＢｙｔｅのＲＥＧＩＳＴＥＲ＿ＲＥＱフレーム（図３参照）が格納される。この場合、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレームが６４Ｂｙｔｅであるために、以降の１５９Ｂｙｔｅが空きとなるので、１５９Ｂｙｔｅの領域は、例えばダミーパターン信号のパディングが行われる。
なお、ＦＥＣコードワードは「データブロック」とも呼ばれる。以降において、図４のようにＲＥＧＩＳＴＥＲ＿ＲＥＱフレームを格納するＦＥＣコードワードについては、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックともいう。

図５を参照して、ＯＬＴ１００とＯＮＵ２００におけるＰ２ＭＰディスカバリ処理に対応する機能構成例について説明する。
同図に示すＯＬＴ１００は、通信部１０１、問い合わせ送信部１０２、登録要求受信部１０３、衝突検出部１０４、復元部１０５及び登録要求応答処理部１０６を備える。
通信部１０１は、光通信路経由でＯＮＵ２００と通信を実行する。

問い合わせ送信部１０２は、未登録のＯＮＵ２００に対する問い合わせを行う。具体的に、問い合わせ送信部１０２は、未登録のＯＮＵ２００に対する問い合わせとして、図１７のステップＳ１として示したように、Ｄｉｓｃｏｖｅｒｙ Ｉｎｆｏｒｍａｔｉｏｎを格納したＤｉｓｃｏｖｅｒｙ ＧＡＴＥをブロードキャストで送信する。Ｄｉｓｃｏｖｅｒｙ Ｉｎｆｏｒｍａｔｉｏｎには、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間において登録要求が受信できるように、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの送信タイミングを通知する情報が格納されている。

登録要求受信部１０３は、問い合わせ送信部１０２によるＤｉｓｃｏｖｅｒｙ ＧＡＴＥの送信に応じてＤｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗを設定する。登録要求受信部１０３は、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間において、Ｄｉｓｃｏｖｅｒｙ ＧＡＴＥに対する応答として未登録のＯＮＵ２００から送信されたＲＥＧＩＳＴＥＲ＿ＲＥＱブロック（図４参照）を受信する。

衝突検出部１０４は、複数のＯＮＵ２００から受信した複数のＲＥＧＩＳＴＥＲ＿ＲＥＱブロックを対象として、他のＲＥＧＩＳＴＥＲ＿ＲＥＱブロック（登録要求信号）と衝突している衝突部分と他のＲＥＧＩＳＴＥＲ＿ＲＥＱブロックと衝突していない非衝突部分とを検出する。
そのうえで、第１実施形態における衝突検出部１０４は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックのサイズに基づいて決まるＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの信号継続時間と、複数のＲＥＧＩＳＴＥＲ＿ＲＥＱブロックが受信されたときの受信継続時間とに基づいて、衝突部分と非衝突部分とを検出する。

復元部１０５は、衝突検出部１０４の検出結果を利用して、衝突部分を含むＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの復元を行う。
例えば、復元部１０５は、衝突部分を含むＲＥＧＩＳＴＥＲ＿ＲＥＱブロックについて、衝突検出部１０４により検出された衝突部分の信号区間をランダム信号で置き換え、このランダム信号で置き換えられた衝突部分と非衝突部分とを結合させて復元対象ブロックを生成する。さらに、復元部１０５は、復元対象ブロックについて誤り訂正を行ってペイロードを推定し、推定したペイロードについて誤り訂正符号化を行って送信レプリカ信号を生成する。送信レプリカ信号にはＲＥＧＩＳＴＥＲ＿ＲＥＱブロックとして衝突部分が復元された部分を含む。そこで、復元部１０５は、受信したＲＥＧＩＳＴＥＲ＿ＲＥＱブロックにおける非衝突部分と、送信レプリカ信号における衝突部分が復元された部分とを結合する。これにより、復元されたＲＥＧＩＳＴＥＲ＿ＲＥＱブロックが得られる。

登録要求応答処理部１０６は、登録要求応答処理を実行する。登録要求応答処理は、受信したＲＥＧＩＳＴＥＲ＿ＲＥＱブロックごとに応答した処理である。登録要求応答処理は、具体的には、図１７に示したステップＳ３によるＬＬＩＤ（Logical Link.ID）の通知、ステップＳ４による送信許可タイミングの通知、ステップＳ５に応じたＲＥＧＩＳＴＥＲ＿ＡＣＫの受信である。

ＯＮＵ２００は、通信部２０１、登録要求送信部２０２及びリンク識別子取得部２０３を備える。
通信部２０１は、光通信路経由でＯＬＴ１００と通信を実行する。
登録要求送信部２０２は、登録要求を送信する。つまり、登録要求送信部２０２は、ＯＬＴ１００が未登録のＯＮＵを問い合わせるために送信したＤｉｓｃｏｖｅｒｙ ＧＡＴＥの受信に応答して、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックをＯＬＴ１００に対して送信する。

リンク識別子取得部２０３は、ＯＬＴ１００から送信されたＬＬＩＤを取得する。ＬＬＩＤは、ＯＬＴ１００がＯＮＵ２００とのリンクを確立するために、ＯＮＵ２００ごとに付与したリンク識別子である。
リンク識別子取得部２０３によりＬＬＩＤが取得されることで、ＯＬＴ１００とＯＮＵ２００とでＬＬＩＤが共有され、以降においてリンクを確立させることができる。

次に、図６を参照して、第１実施形態における衝突検出部１０４による衝突検出の手法例について説明する。
同図においては、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間における２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２の受信タイミングが示されている。同図では、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１の終端側の部分と、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２の先頭側の部分とが衝突している状態が示されている。

衝突検出部１０４は、図６に示すＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２について、以下のように衝突部分と非衝突部分を検出する。
ここで、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックは、図４に示したように２５５Ｂｙｔｅで固定であるためレートが一定であれば信号継続時間Ｔ_ＢＬも一定になる。
具体的に、１０Ｇ−ＰＯＮのレートは１０．３１２５Ｇｂｉｔ／ｓｅｃであるので、信号継続時間Ｔ_ＢＬは、以下の式１により表される。
Ｔ_ＢＬ＝２５５×８／（１０．３１２５×１０^９）＝１．９８＝１０^−８ｓｅｃ・・・（式１）

ここで、２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックが衝突している場合には、両者の受信時間の一部が重複する。従って、互いに衝突した２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの受信継続時間Ｔ_ＳＤは、１つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの信号継続時間Ｔ_ＢＬより長く、かつ、信号継続時間Ｔ_ＢＬの２倍よりも短くなる。つまり、２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックが衝突している場合には、以下の式２が成立する。
Ｔ_ＢＬ＜Ｔ_ＳＤ＜２Ｔ_ＢＬ・・・（式２）

衝突検出部１０４は、受信継続時間Ｔ_ＳＤを測定したうえで、式２が成立するか否かにより２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックで衝突が発生しているか否かについて判定する。従って、図６の例では式２が成立し、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２で衝突が発生していることが判定される。
このように衝突の発生していることを判定した場合、衝突検出部１０４は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２のそれぞれについて、衝突している衝突部分と、衝突していない非衝突部分とを検出する。
このために、衝突検出部１０４は、衝突部分に対応する衝突時間Ｔ_Ｃを検出する。衝突時間Ｔ_Ｃは、時間軸におけるＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２の重複部分であるから、以下の式３により求めることができる。
Ｔ_Ｃ＝２Ｔ_ＢＬ−Ｔ_ＳＤ・・・（式３）

図６からも分かるように、２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２の衝突部分は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２による受信継続時間Ｔ_ＳＤの中間に位置する。
そのうえで、前方のＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１は終端側が衝突部分で、これより前の部分が非衝突部分になる。一方、後方のＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２は先端側が衝突部分で、これより後の部分が非衝突部分になる。

そこで、衝突検出部１０４は、受信継続時間Ｔ_ＳＤの開始から衝突時間Ｔ_Ｃが開始されるまでの時間Ｔ_ＮＣ１の区間（Ｔ_ＢＬ−Ｔ_Ｃ）をＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１の非衝突部分として求める。
また、衝突検出部１０４は、時間Ｔ_ＮＣ１に続く衝突時間Ｔ_Ｃの区間を、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２の衝突部分として求める。
また、衝突検出部１０４は、衝突時間Ｔ_Ｃの終了位置から受信継続時間Ｔ_ＳＤが終了するまでの時間Ｔ_ＮＣ２の区間（Ｔ_ＢＬ−Ｔ_Ｃ）を、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２の非衝突部分として求める。

図７のフローチャートは、第１実施形態におけるＯＬＴ１００とＯＮＵ２００が実行するＰ２ＭＰディスカバリ処理の手順例を示している。
先ず、ＯＬＴ１００における問い合わせ送信部１０２は、Ｄｉｓｃｏｖｅｒｙ ＧＡＴＥを送信する（ステップＳ１０１）。
次に、登録要求受信部１０３は、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗを設定する。そのうえで、登録要求受信部１０３は、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間において、ステップＳ１０１により送信したＤｉｓｃｏｖｅｒｙ ＧＡＴＥに応答して未登録のＯＮＵ２００から送信されたＲＥＧＩＳＴＥＲ＿ＲＥＱブロックを受信する（ステップＳ１０２）。

次に、衝突検出部１０４は、ステップＳ１０２にて受信されたＲＥＧＩＳＴＥＲ＿ＲＥＱブロックを対象として衝突検出を実行する（ステップＳ１０３）。ここでの衝突検出部１０４による衝突検出は、図６にて説明した手法によって行われる。
衝突検出部１０４は、ステップＳ１０３による衝突検出によって、衝突の有無を検出し、衝突が有ることを検出した場合には、衝突部分と非衝突部分を検出する。

次に、復元部１０５は、ステップＳ１０３の衝突検出によって衝突有りと検出されたか否かについて判定する（ステップＳ１０４）。
衝突有りの場合（ステップＳ１０４−ＹＥＳ）、復元部１０５は、ステップＳ１０３による衝突検出結果を利用して、衝突部分を含むＲＥＧＩＳＴＥＲ＿ＲＥＱブロックを復元する処理を実行する（ステップＳ１０５）。
一方、衝突無しの場合（ステップＳ１０４−ＮＯ）、ステップＳ１０５はスキップされる。

次に、登録要求応答処理部１０６は、衝突部分の無かったＲＥＧＩＳＴＥＲ＿ＲＥＱブロック、あるいはステップＳ１０５によって復元されたＲＥＧＩＳＴＥＲ＿ＲＥＱブロックに応答した処理を以下のように実行する。

つまり、登録要求応答処理部１０６は、ＲＥＧＩＳＴＥＲフレームを含むＦＥＣコードワードの送信によって、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの送信元のＯＮＵ２００にＬＬＩＤを通知する（ステップＳ１０６）。
次に、登録要求応答処理部１０６は、ＧＡＴＥフレームを含むＦＥＣコードワードの送信によって、ＲＥＧＩＳＴＥＲ＿ＡＣＫの送信許可タイミングを通知する（ステップＳ１０７）。
登録要求応答処理部１０６は、ステップＳ１０７により通知した送信許可タイミングに従ってＯＮＵ２００が送信したＲＥＧＩＳＴＥＲ＿ＡＣＫを受信する（ステップＳ１０８）。

また、ＯＮＵ２００における登録要求送信部２０２は、ステップＳ１０１によりＯＬＴ１００が送信したＤｉｓｃｏｖｅｒｙ ＧＡＴＥの受信に応じて、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックを生成する（ステップＳ２０１）。ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックは、ＲＥＧＩＳＴＥＲ＿ＲＥＱフレーム（図３）を含むＦＥＣコードワード（図４）である。
登録要求送信部２０２は、生成したＲＥＧＩＳＴＥＲ＿ＲＥＱブロックをＯＬＴ１００に対して送信する（ステップＳ２０２）。

次に、リンク識別子取得部２０３は、ステップＳ１０６によってＯＬＴ１００が送信したＲＥＧＩＳＴＥＲフレームを受信することによって、通知されたＬＬＩＤを取得する（ステップＳ２０３）。
リンク識別子取得部２０３は、ステップＳ１０７によってＯＬＴ１００が送信したＧＡＴＥフレームを受信することによって、通知された送信許可タイミングを取得する（ステップＳ２０４）。
リンク識別子取得部２０３は、送信許可タイミングに従ったタイミングで、ＬＬＩＤの通知に対する応答であるＲＥＧＩＳＴＥＲ＿ＡＣＫをＯＬＴ１００に対して送信する（ステップＳ２０５）。

図８のフローチャートは、図７のステップＳ１０３としての衝突検出の処理手順例を示している。
衝突検出部１０４は、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間においてＲＥＧＩＳＴＥＲ＿ＲＥＱブロックが継続して受信された受信継続期間Ｔ_ＳＤを測定する（ステップＳ３０１）。
衝突検出部１０４は、測定した受信継続期間Ｔ_ＳＤと、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックのサイズに応じて決まる信号継続時間Ｔ_ＢＬとについて、先の式２が成立するか否かについて判定する（ステップＳ３０２）。

式２が成立する場合（ステップＳ３０２−ＹＥＳ）、衝突検出部１０４は衝突有りと検出する（ステップＳ３０３）。また、衝突有りと検出するのに応じて、衝突検出部１０４は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの信号継続時間Ｔ_ＢＬと受信継続期間Ｔ_ＳＤとを利用して、先に図６にて説明したように衝突部分と非衝突部分とを検出する（ステップＳ３０４）。

式２が成立しない場合（ステップＳ３０２−ＮＯ）、衝突検出部１０４は衝突無しと検出する（ステップＳ３０５）。

＜第２実施形態＞
次に、第２実施形態について説明する。
第２実施形態における衝突検出部１０４は、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間において受信されるＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの受信光強度を測定する。そして、衝突検出部１０４は、受信光強度が一定以上のレベル変化を示すタイミングに基づいて衝突検出を行う。

図９は、第２実施形態における衝突検出部１０４による衝突検出の手法例を示している。
本実施形態においては、最小受光感度が定められており、最小受光感度未満に対応する受信光強度については処理対象とならない。この場合において、図９のように２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２が衝突している場合、先ず、受信継続時間Ｔ_ＳＤの開始時点以降においてＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１のみに対応する受信光強度が維持される。

これに対して、衝突部分ではＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２の受信光強度が合成されるので、衝突時間Ｔ_Ｃの開始タイミングにおいては、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１のみに対応する受信光強度からＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２が合成された受信光強度に変化する。
このとき、衝突時間Ｔ_Ｃの開始タイミングにおける受信光強度のレベル変化Δｌｖ１は、最小受光感度以上になる。例えば、最小受光感度が−３０ｍｄＢである場合、レベル変化Δｌｖ１は、−３０ｍｄＢ以上になる。

また、衝突時間Ｔ_Ｃの開始からさらに時間が経過して衝突時間Ｔ_Ｃが終了するタイミングにおいて、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２が合成された受信光強度から、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２のみに対応した受信光強度に変化する。
このときも、衝突時間Ｔ_Ｃの終了タイミングに対応する受信光強度のレベル変化Δｌｖ２は、最小受光感度以上になる。

このように、２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２が衝突している場合、衝突部分に対応する区間は、前後に対してレベルが突出する。
そのうえで、受信継続時間Ｔ_ＳＤにおける受信光強度は、衝突時間Ｔ_Ｃの開始タイミングにおいて最小受光感度以上で増加するレベル変化を示し、続く衝突時間Ｔ_Ｃの終了タイミングにおいて最小受光感度以上で減少するレベル変化を示す。
そこで、第２実施形態の衝突検出部１０４は、受信継続時間Ｔ_ＳＤにおける受信光強度が最小受光感度以上で増加し、次に、最小受光感度以上で低下するレベル変化を示した場合に、衝突が発生していると検出する。

衝突の発生の検出に伴って、衝突検出部１０４は、受信継続時間Ｔ_ＳＤにおいて、受信光強度が最小受光感度以上で増加し、次に、最小受光感度以上で低下するまでの衝突時間Ｔ_Ｃで表される区間（突出区間）を衝突部分として検出する。
また、衝突検出部１０４は、受信継続時間Ｔ_ＳＤの開始時点から衝突時間Ｔ_Ｃの開始時点までのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１に対応する受信光強度が維持されている時間Ｔ_ＮＣ１をＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１の非衝突部分として検出する。
また、衝突検出部１０４は、衝突時間Ｔ_Ｃの終了時点から受信継続時間Ｔ_ＳＤの終了時点までのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２に対応する受信光強度が維持されている時間Ｔ_ＮＣ２をＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２の非衝突部分として検出する。

図１０のフローチャートは、第２実施形態における衝突検出部１０４が図７のステップＳ１０３として実行する処理手順例を示している。なお、ＯＬＴ１００とＯＮＵ２００が実行するＰ２ＭＰディスカバリ処理としては、図７と同様でよい。

衝突検出部１０４は、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間において受信されるＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの受信光強度を測定する（ステップＳ４０１）。
次に、衝突検出部１０４は、受信光強度が前後の信号区間に対して最小受光感度レベル以上で突出する突出区間を探索する（ステップＳ４０２）。つまり、受信継続時間Ｔ_ＳＤにおいて、受信光強度が最小受光感度以上で増加し、次に、最小受光感度以上で低下する区間を探索する。
衝突検出部１０４は、ステップＳ４０２によって突出区間が探索されたか否かについて判定する（ステップＳ４０３）。

突出区間が探索された場合（ステップＳ４０３−ＹＥＳ）、衝突検出部１０４は衝突有りと検出する（ステップＳ４０４）。
衝突有りと検出されるのに応じて、衝突検出部１０４は、上記したように、衝突時間Ｔ_Ｃに対応する突出区間を衝突部分として検出し、受信継続時間Ｔ_ＳＤの開始時点からほぼ一定の受信光強度が維持されている時間Ｔ_ＮＣ１の区間と、衝突部分が終了してから受信継続時間Ｔ_ＳＤが終了するまでの時間Ｔ_ＮＣ２の区間とを、それぞれ非衝突部分として検出する（ステップＳ４０５）。

また、突出区間が検出されない場合（ステップＳ４０３−ＮＯ）、衝突検出部１０４は衝突無しと検出する（ステップＳ４０６）。

＜第３実施形態＞
次に、第３実施形態について説明する。
第３実施形態においては、ＯＮＵ２００がＯＬＴ１００との通信距離に応じた送信光強度によりＲＥＧＩＳＴＥＲ＿ＲＥＱブロックを送信する。これにより、ＯＬＴ１００にて受信される複数のＯＮＵ２００からのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの受信光強度は、通信距離にかかわらず所定の規定値でほぼ一定になる。

なお、通信距離は、ＯＮＵ２００に対して予め入力しておけばよい。あるいは、ＯＮＵ２００が自己で通信距値を取得してもよい。ＯＮＵ２００が自己で通信距値を取得するための手法としては特に限定されるものではなく、例えば波長分散量に基づいて取得してもよいし、絶対時間による遅延時間に基づいて取得してもよいし、異なる波長の遅延時間差に基づいて取得してもよい。

そのうえで、第３実施形態における衝突検出部１０４は、例えば図１１に示すように衝突検出を行う。
図１１には、受信継続時間Ｔ_ＳＤにおいて、３つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２、Ｒ３が衝突して受信された例が示されている。
受信継続時間Ｔ_ＳＤにおける衝突時間Ｔ_Ｃ１は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２、Ｒ３がともに衝突している区間である。衝突時間Ｔ_Ｃ１の前の衝突時間Ｔ_Ｃ２は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ３が衝突している区間である。衝突時間Ｔ_Ｃ２の後の衝突時間Ｔ_Ｃ３は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２、Ｒ３が衝突している区間である。
また、受信継続時間Ｔ_ＳＤの開始から衝突時間Ｔ_Ｃ２に至るまでの時間Ｔ_ＮＣ１は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１の非衝突部分の区間である。衝突時間Ｔ_Ｃ３の終了から受信継続時間Ｔ_ＳＤの終了までの時間Ｔ_ＮＣ２は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２の非衝突部分の区間である。
この場合、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２の非衝突部分は存在しない。

第３実施形態においては、前述のように、各ＯＮＵ２００から送信されたＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの受信光強度は、それぞれ、規定値でほぼ同じとなる。以下の説明にあたり、規定値は、最小受光感度に対応する−３０ｍｄＢである場合を例に挙げる。

この場合、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１の非衝突部分に対応する時間Ｔ_ＮＣ１の区間の受信光強度のレベルＬＶ１１は、−３０ｍｄＢのほぼ等倍である。
これに対して、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ３が衝突する衝突時間Ｔ_Ｃ２においては２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの受信光強度が合成される。このために、衝突時間Ｔ_Ｃ２の区間における受信光強度のレベルＬＶ１２は、−３０ｍｄＢのほぼ２倍になる。
また、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ１、Ｒ２、Ｒ３が衝突する衝突時間Ｔ_Ｃ１においては３つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの受信光強度が合成される。このために、衝突時間Ｔ_Ｃ１の区間における受信光強度のレベルＬＶ１３は、−３０ｍｄＢのほぼ３倍になる。
また、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２、Ｒ３が衝突する衝突時間Ｔ_Ｃ３においては２つのＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの受信光強度が合成される。このために、衝突時間Ｔ_Ｃ３の区間における受信光強度のレベルＬＶ１４は、−３０ｍｄＢのほぼ２倍になる。
また、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックＲ２のみとなる時間Ｔ_ＮＣ２の区間における受信光強度のレベルＬＶ１５は、−３０ｍｄＢのほぼ等倍になる。

そこで、第３実施形態の衝突検出部１０４は、受信継続時間Ｔ_ＳＤにおける受信光強度について規定値の２倍以上の整数倍となる区間があれば衝突有りと検出する。
また、衝突有りと検出した場合、衝突検出部１０４は、受信継続時間Ｔ_ＳＤにおける受信光強度の規定値に対する比率に基づいて衝突部分と非衝突部分とを検出する。
つまり、衝突検出部１０４は、受信継続時間Ｔ_ＳＤにおいて、受信光強度が規定値に対して１倍（等倍）の区間を非衝突部分として検出する。また、衝突検出部１０４は、受信継続時間Ｔ_ＳＤにおいて、受信光強度が規定値に対して２倍以上の整数倍の区間を衝突部分として検出する。

図１２のフローチャートは、第３実施形態におけるＯＬＴ１００とＯＮＵ２００が実行するＰ２ＭＰディスカバリ処理の手順例を示している。なお、同図において図７と同様の処理となるステップについては同一符号を付して説明を省略する。
ＯＮＵ２００における登録要求送信部２０２は、ステップＳ２０１にて生成したＲＥＧＩＳＴＥＲ＿ＲＥＱブロックを、ＯＬＴ１００との通信距離に基づいて定めた光強度でＯＬＴ１００に対して送信する（ステップＳ２０２Ａ）。

図１３のフローチャートは、第３実施形態における衝突検出部１０４が図１２のステップＳ１０３において実行する処理手順例を示している。
衝突検出部１０４は、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間において受信されるＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの受信光強度を測定する（ステップＳ５０１）。
衝突検出部１０４は、受信継続時間Ｔ_ＳＤにおいて受信光強度が既定値に対して２倍以上の整数倍となっている区間（整数倍区間）を探索する（ステップＳ５０２）。
衝突検出部１０４は、ステップＳ５０２による探索の結果、整数倍区間が探索されたか否かについて判定する（ステップＳ５０３）。

整数倍区間が探索された場合（ステップＳ５０３−ＹＥＳ）、衝突検出部１０４は衝突有りと検出する（ステップＳ５０４）。
これに伴って、衝突検出部１０４は、衝突部分と非衝突部分を検出する（ステップＳ５０５）。このために、衝突検出部１０４は、例えば受信継続時間Ｔ_ＳＤにおける受信光強度を既定値で除算することで、受信光強度が規定値の何倍であるのかを求める。そして、衝突検出部１０４は、受信光強度が既定値のほぼ１倍である区間については非衝突部分として検出する。また、衝突検出部１０４は、受信光強度が既定値に対して２倍以上の整数倍である区間については衝突部分として検出する。さらに、この場合の衝突検出部１０４は、除算の結果に基づいて、衝突部分において衝突しているＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの数を判定することができる。

また、突出区間が検出されない場合（ステップＳ５０３−ＮＯ）、衝突検出部１０４は衝突無しと検出する（ステップＳ５０６）。

＜第４実施形態＞
次に、第４実施形態について説明する。
図１４は、第４実施形態におけるＯＮＵ２００が送信するＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの送信信号の構造を示している。同図に示すように、ＯＮＵ２００は、一定間隔ごとに既知パターンビット列を挿入したＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの送信信号を生成する。
なお、図示は省略するが、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックの送信信号は、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックが格納するＲＥＧＩＳＴＥＲ＿ＲＥＱフレームに対して一定間隔ごとに既知パターンビット列を挿入した構造であってもよい。
このように、第４実施形態のＲＥＧＩＳＴＥＲ＿ＲＥＱブロックは、一定間隔による既知パターンビット列の挿入部分を含む。

ＯＬＴ１００では、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間において、上記のように既知パターンビット列が挿入されたＲＥＧＩＳＴＥＲ＿ＲＥＱブロックを受信する。ここで、ＲＥＧＩＳＴＥＲ＿ＲＥＱブロックに衝突が発生していた場合、衝突部分では既知パターンビット列にエラーが生じて、既知パターンビット列の本来のビットパターン（既知ビットパターン）が得られていない状態になっている。
そこで、第４実施形態における衝突検出部１０４は、受信継続時間において一定間隔ごとに既知パターンビット列の既知ビットパターンを検出していく。そして、既知ビットパターンの検出されない区間が有れば、衝突有りと検出する。
衝突有りの場合、衝突検出部１０４は、既知ビットパターンが検出されない区間を衝突部分として検出し、既知ビットパターンが検出される区間を非衝突部分として検出する。

図１５のフローチャートは、第４実施形態におけるＯＬＴ１００とＯＮＵ２００が実行するＰ２ＭＰディスカバリ処理の手順例を示している。なお、同図において図７と同様の処理となるステップについては同一符号を付して説明を省略する。
ＯＮＵ２００における登録要求送信部２０２は、図１４に示したように、一定間隔で既知パターンビット列を挿入したＲＥＧＩＳＴＥＲ＿ＲＥＱブロックを生成する（ステップＳ２０１Ａ）。登録要求送信部２０２は、ステップＳ２０２によって、既知パターンビット列が挿入されたＲＥＧＩＳＴＥＲ＿ＲＥＱブロックをＯＬＴ１００に対して送信する。

図１６のフローチャートは、第４実施形態における衝突検出部１０４が図１５のステップＳ１０３において実行する処理手順例を示している。
衝突検出部１０４は、Ｄｉｓｃｏｖｅｒｙ Ｗｉｎｄｏｗの期間において受信されるＲＥＧＩＳＴＥＲ＿ＲＥＱブロック（受信信号）から、既知パターンビット列と同じビットパターン（既知ビットパターン）を検出する（ステップＳ６０１）。
衝突検出部１０４は、受信信号において既知ビットパターンが検出されない区間が有ったか否かについて判定する（ステップＳ６０２）。

既知ビットパターンが検出されない区間が有った場合、（ステップＳ６０２−ＹＥＳ）、衝突検出部１０４は衝突有りと検出する（ステップＳ６０３）。
この場合、衝突検出部１０４は、前述のように既知ビットパターンが検出されない区間を衝突部分として検出し、既知ビットパターンが検出される区間を非衝突部分として検出する（ステップＳ６０４）。

また、既知ビットパターンがすべて正常に検出された場合（ステップＳ６０２−ＮＯ）、衝突検出部１０４は衝突無しと検出する（ステップＳ６０５）。

上述した実施形態におけるＯＬＴ１００とＯＮＵ２００をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよく、ＦＰＧＡ（Field Programmable Gate Array）等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１００…ＯＬＴ， １０１…通信部， １０２…問い合わせ送信部， １０３…登録要求受信部， １０４…衝突検出部， １０５…復元部， １０６…登録要求応答処理部， ２００…ＯＮＵ， ２０１…通信部， ２０２…登録要求送信部， ２０３…リンク識別子取得部， ３００…上位ネットワーク， ４００…下位ネットワーク， ５００…光通信路

Claims (6)

1. 局側光回線終端装置と、前記局側光回線終端装置と光通信路経由で接続される加入者側光回線終端装置とを備え、
   前記局側光回線終端装置は、
   複数の加入者側光回線終端装置から受信した登録要求信号を対象として、他の登録要求信号と衝突している衝突部分と他の登録要求信号と衝突していない非衝突部分とを検出する衝突検出部を備える
   光通信システム。
2. 前記衝突検出部は、
   登録要求信号のサイズに基づいて決まる登録要求信号の信号継続時間と、複数の登録要求信号が受信されたときの受信継続時間とに基づいて、衝突部分と非衝突部分とを検出する
   請求項１に記載の光通信システム。
3. 前記衝突検出部は、
   受信される登録要求信号の受信光強度が一定以上のレベル変化を示すタイミングに基づいて、衝突部分と非衝突部分とを検出する
   請求項１に記載の光通信システム。
4. 前記加入者側光回線終端装置は、
   前記局側光回線終端装置にて受信される登録要求信号の受信光強度が予め定めた規定値となるように、前記局側光回線終端装置との通信距離に応じて定めた送信光強度により登録要求信号を送信する登録要求送信部を備え、
   前記衝突検出部は、
   複数の登録要求信号が受信された期間における受信光強度の前記規定値に対する比率に基づいて衝突部分と非衝突部分とを検出する
   請求項１に記載の光通信システム。
5. 前記加入者側光回線終端装置は、
   一定間隔による既知パターンビット列の挿入部分を含む登録要求信号を送信する登録要求送信部を備え、
   前記衝突検出部は、
   受信された複数の登録要求信号における既知パターンビット列の検出の有無に基づいて衝突部分と非衝突部分とを検出する
   請求項１に記載の光通信システム。
6. 局側光回線終端装置と、前記局側光回線終端装置と光通信路経由で接続される加入者側光回線終端装置とを備える光通信システムにおける衝突検出方法であって、
   前記局側光回線終端装置において、複数の加入者側光回線終端装置から受信した登録要求信号を対象として、他の登録要求信号と衝突している衝突部分と他の登録要求信号と衝突していない非衝突部分とを検出する衝突検出ステップを備える
   衝突検出方法。

Images