(57)【要約】【課題】複数のＯＮＵから受信した登録要求信号の衝突に対応してＯＬＴが登録要求信号を復元する際の復元率の向上を図る。【解決手段】ＯＬＴについて、複数のＯＮＵから受信したＲＥＧＩＳＴＥＲ＿ＲＥＱブロックのうち他のＲＥＧＩＳＴＥＲ＿ＲＥＱと衝突しているＲＥＧＩＳＴＥＲ＿ＲＥＱを復元対象として、復元対象のＲＥＧＩＳＴＥＲ＿ＲＥＱの衝突部分をランダム信号で置換した衝突部分置換信号を生成し、衝突部分置換信号について誤り訂正を行って推定ペイロードを生成し、推定ペイロードを誤り訂正符号化して送信レプリカ信号を生成し、復元対象の登録要求信号における非衝突部分と送信レプリカ信号における衝突部分に対応する信号部分とを結合して復元されたＲＥＧＩＳＴＥＲ＿ＲＥＱを生成するように構成する。【選択図】図７
2014236485.tif 000002
【特許請求の範囲】
【請求項１】
局側光回線終端装置と、前記局側光回線終端装置と光通信路経由で接続される加入者側光回線終端装置とを備え、
前記局側光回線終端装置は、
複数の加入者側光回線終端装置から受信した登録要求信号のうち他の登録要求信号と衝突している登録要求信号を復元対象として、前記復元対象の登録要求信号の衝突部分をランダム信号で置換した衝突部分置換信号を生成するランダム信号置換処理と、前記衝突部分置換信号について誤り訂正を行って推定ペイロードを生成する誤り訂正処理と、前記推定ペイロードを誤り訂正符号化して疑似送信信号を生成する誤り訂正符号化処理と、前記復元対象の登録要求信号における非衝突部分と前記疑似送信信号における衝突部分に対応する信号部分とを結合して復元登録要求信号を生成する結合処理とを実行する復元部を備える
光通信システム。
【請求項２】
前記復元部は、
１つの復元対象の登録要求信号を復元するにあたり、前記ランダム信号置換処理を実行した後において、前記誤り訂正処理、前記誤り訂正符号化処理及び前記結合処理による一連の処理を所定回数繰り返し実行する
請求項１に記載の光通信システム。
【請求項３】
局側光回線終端装置と、前記局側光回線終端装置と光通信路経由で接続される加入者側光回線終端装置とを備える光通信システムにおける信号復元方法であって、
前記局側光回線終端装置において、複数の加入者側光回線終端装置から受信した登録要求信号のうち他の登録要求信号と衝突している登録要求信号を復元対象として、前記復元対象の登録要求信号の衝突部分をランダム信号で置換した衝突部分置換信号を生成するランダム信号置換処理と、前記衝突部分置換信号について誤り訂正を行って推定ペイロードを生成する誤り訂正処理と、前記推定ペイロードを誤り訂正符号化して疑似送信信号を生成する誤り訂正符号化処理と、前記復元対象の登録要求信号における非衝突部分と前記疑似送信信号における衝突部分に対応する信号部分とを結合して復元登録要求信号を生成する結合処理とを実行する復元ステップを有する信号復元方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、光通信システム及び信号復元方法に関する。
【背景技術】
【０００２】
通信事業者側に設置されるＯＬＴ（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）等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。
【符号の説明】
【００７６】
１００…ＯＬＴ，  １０１…通信部，  １０２…問い合わせ送信部，  １０３…登録要求受信部，  １０４…衝突検出部，  １０５…復元部，  １０６…登録要求応答処理部，  ２００…ＯＮＵ，  ２０１…通信部，  ２０２…登録要求送信部，  ２０３…リンク識別子取得部，  ３００…上位ネットワーク，  ４００…下位ネットワーク，  ５００…光通信路
【図１】
2014236485.tif 000003
【図２】
2014236485.tif 000004
【図３】
2014236485.tif 000005
【図４】
2014236485.tif 000006
【図５】
2014236485.tif 000007
【図６】
2014236485.tif 000008
【図７】
2014236485.tif 000009
【図８】
2014236485.tif 000010
【図９】
2014236485.tif 000011
【図１０】
2014236485.tif 000012
【図１１】
2014236485.tif 000013