特許7152488 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ 華為技術有限公司の特許一覧

特許7152488データ符号化方法および装置、データ復号方法および装置、ＯＬＴ、ＯＮＵ、ならびにＰＯＮシステム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3(a)
3(b)
3(c)
3(d)
3(e)
3(f)
4(1)
4(2)
4(3)
4(4)
4(5)
4(6)
4(7)
4(8)
4(9)
4(10)
4(11)
4(12)
4(13)
4(14)
4(15)
4(16)
4(17)
4(18)
5
6
7
8
9

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

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

(11)【特許番号】

(24)【登録日】2022-10-03

(45)【発行日】2022-10-12

(54)【発明の名称】データ符号化方法および装置、データ復号方法および装置、ＯＬＴ、ＯＮＵ、ならびにＰＯＮシステム

(51)【国際特許分類】

H04L 1/00 20060101AFI20221004BHJP

H03M 7/14 20060101ALI20221004BHJP

H04B 10/272 20130101ALI20221004BHJP

H04L 12/44 20060101ALN20221004BHJP

【ＦＩ】

H04L1/00 B

H03M7/14 B

H04B10/272

H04L12/44 200

【請求項の数】 17

(21)【出願番号】P 2020529745

(86)(22)【出願日】2018-11-30

(65)【公表番号】

(43)【公表日】2021-02-15

(86)【国際出願番号】 CN2018118665

(87)【国際公開番号】W WO2019105471

(87)【国際公開日】2019-06-06

【審査請求日】2020-07-13

(31)【優先権主張番号】201711245941.1

(32)【優先日】2017-12-01

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】503433420

【氏名又は名称】華為技術有限公司

【氏名又は名称原語表記】ＨＵＡＷＥＩＴＥＣＨＮＯＬＯＧＩＥＳＣＯ．，ＬＴＤ．

【住所又は居所原語表記】ＨｕａｗｅｉＡｄｍｉｎｉｓｔｒａｔｉｏｎＢｕｉｌｄｉｎｇ，Ｂａｎｔｉａｎ，ＬｏｎｇｇａｎｇＤｉｓｔｒｉｃｔ，Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ５１８１２９，Ｐ．Ｒ．Ｃｈｉｎａ

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100133569

【弁理士】

【氏名又は名称】野村進

(72)【発明者】

【氏名】景磊

(72)【発明者】

【氏名】高波

(72)【発明者】

【氏名】▲聶▼ 世▲ウェイ▼

(72)【発明者】

【氏名】▲劉▼ ▲徳▼坤

【審査官】吉江一明

(56)【参考文献】

【文献】特表２０１０－５００７９６（ＪＰ，Ａ）

【文献】特開２００８－０８５９７０（ＪＰ，Ａ）

【文献】特表２０１６－５１０５２０（ＪＰ，Ａ）

【文献】中国特許出願公開第１０１４８８８２７（ＣＮ，Ａ）

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

Ｈ０４Ｌ１／００

Ｈ０３Ｍ７／１４

Ｈ０４Ｂ１０／２７２

Ｈ０４Ｌ１２／４４

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

【請求項1】

PONシステムにおけるデータ符号化方法であって、前記方法は、
物理コーディングサブレイヤにおいて入力64B／66Bもしくは64B／65Bデータブロックを128B／129Bもしくは256B／257Bデータブロックにコード変換するステップと、
前記物理コーディングサブレイヤにおいてN個のデータブロックを収集し、前記N個のデータブロックを組み合わせて有効データを生成するステップであって、Nが整数であり、順方向誤り訂正FECコードタイプに対応するペイロード長さ値を前記データブロックの長さで割って得られた商以下であり、前記収集されたデータブロックが128B／129Bもしくは256B／257Bデータブロックである、ステップと、
前記物理コーディングサブレイヤにおいてペイロードを生成するステップであって、前記ペイロードが前記有効データを備え、前記ペイロードの長さが前記ペイロード長さ値に等しい、ステップと、
前記物理コーディングサブレイヤにおいて、チェック部分を生成するために、前記FECコードタイプに基づいて前記ペイロードに対してFEC符号化を実行するステップであって、前記チェック部分の長さが、FECコードタイプに対応するFECコードワード長さ値と前記ペイロード長さ値との間の差に等しい、ステップと、
前記物理コーディングサブレイヤにおいてコードワード構造を生成するステップであって、前記コードワード構造が、前記有効データ、前記チェック部分、および同期ヘッダを備え、前記同期ヘッダが、前記コードワード構造の先頭に配置されるか、または前記コードワード構造の末尾に配置されるか、または前記有効データと前記チェック部分との間に配置される、ステップと
を備える、方法。

【請求項2】

前記同期ヘッダの長さがSであり、前記入力データブロックの長さがXであり、前記FECコードワード長さ値をXで割って得られた余りがYあるとき、S＝tX－Yであり、tが整数であり、Y≠0であるとき、t≧1であり、またはY＝0であるとき、t≧0であり、Y＝0かつt＝0であるとき、パディング部分の全体または一部が前記同期ヘッダとして直接使用される、請求項1に記載の方法。

【請求項3】

FECコードタイプが、LDPC（18493、15677）、RS（2047、1739）、RS（1023、847）、RS（1023、845）、RS（1023、843）、RS（1023、841）、RS（1015、839）、RS（1017、839）、またはRS（1019、839）である、請求項1に記載の方法。

【請求項4】

前記有効データの長さが前記ペイロード長さ値に等しいとき、前記ペイロードが前記有効データから構成される、請求項1に記載の方法。

【請求項5】

前記有効データの長さが前記ペイロード長さ値より小さいとき、前記コードワード構造がパディング部分をさらに備え、前記ペイロードが、前記有効データおよび前記パディング部分から構成され、前記有効データの前記長さおよび前記パディング部分の長さの合計が前記ペイロード長さ値に等しい、請求項1に記載の方法。

【請求項6】

前記パディング部分が、前記コードワード構造の長さ、前記有効データの前記長さ、前記有効データの前記長さおよび前記チェック部分の前記長さの合計、前記ペイロードの前記長さ、または前記ペイロードの前記長さおよび前記チェック部分の前記長さの合計を示すために使用される、請求項5に記載の方法。

【請求項7】

PONシステムにおけるデータ復号方法であって、前記方法は、
物理コーディングサブレイヤにおいてコードワード構造を受信するステップであって、前記コードワード構造が、有効データ、チェック部分、および同期ヘッダを備え、前記同期ヘッダが、前記コードワード構造の先頭に配置されるか、または前記コードワード構造の末尾に配置されるか、または前記有効データと前記チェック部分との間に配置され、前記有効データがN個のデータブロックを備え、前記データブロックが、入力64B／66Bもしくは64B／65Bデータブロックからコード変換された128B／129Bもしくは256B／257Bデータブロックであり、Nが整数であり、順方向誤り訂正FECコードタイプに対応するペイロード長さ値を前記データブロックの長さで割って得られた商以下であり、前記チェック部分の長さが、FECコードタイプに対応するFECコードワード長さ値と前記ペイロード長さ値との間の差に等しい、ステップと、
前記物理コーディングサブレイヤにおいて、前記同期ヘッダに基づいて前記受信されたコードワード構造を同期させるステップと、
前記物理コーディングサブレイヤにおいて、ペイロードおよび前記チェック部分を抽出するステップであって、前記ペイロードが前記有効データを備え、前記ペイロードの長さが前記ペイロード長さ値に等しい、ステップと、
前記物理コーディングサブレイヤにおいて、前記FECコードタイプに基づいて前記ペイロードに対して順方向誤り訂正復号を実行するステップと
を備える、方法。

【請求項8】

前記同期ヘッダの長さがSであるとき、
前記有効データに含まれる前記データブロックが、入力データブロックまたは前記入力データブロックからコード変換されたデータブロックであって、前記入力データブロックが64B／66Bまたは64B／65Bデータブロックであり、前記入力データブロックの長さがXであり、前記FECコードワード長さ値をXで割って得られた余りがYあり、S＝tX－Yであり、tが整数であり、Y≠0であるとき、t≧1であり、またはY＝0であるとき、t≧0であり、Y＝0かつt＝0であるとき、パディング部分の全体または一部が前記同期ヘッダとして直接使用される
請求項7に記載の方法。

【請求項9】

使用される順方向誤り訂正復号方式が、LDPC（18493、15677）、RS（2047、1739）、RS（1023、847）、RS（1023、845）、RS（1023、843）、RS（1023、841）、RS（1015、839）、RS（1017、839）、またはRS（1019、839）である、請求項7に記載の方法。

【請求項10】

前記有効データの長さが前記ペイロード長さ値に等しいとき、前記ペイロードが前記有効データから構成される、請求項7に記載の方法。

【請求項11】

前記有効データの長さが前記ペイロード長さ値より小さいとき、前記コードワード構造がパディング部分をさらに備え、前記ペイロードが、前記有効データおよび前記パディング部分から構成される、請求項7に記載の方法。

【請求項12】

PONシステムにおけるデータ符号化装置であって、前記装置は、
入力64B／66Bもしくは64B／65Bデータブロックを128B／129Bもしくは256B／257Bデータブロックにコード変換するように構成されたコード変換モジュールと、
N個のデータブロックを収集し、前記N個のデータブロックを組み合わせて有効データを生成するように構成された収集モジュールであって、Nが整数であり、順方向誤り訂正FECコードタイプに対応するペイロード長さ値を前記データブロックの長さで割って得られた商以下であり、前記収集されたデータブロックが128B／129Bもしくは256B／257Bデータブロックである、収集モジュールと、
ペイロードを生成するように構成された生成モジュールであって、前記ペイロードが前記有効データを備え、前記ペイロードの長さが前記ペイロード長さ値に等しい、生成モジュールと、
チェック部分を生成するために、前記FECコードタイプに基づいて前記ペイロードに対してFEC符号化を実行するように構成された順方向誤り訂正符号化モジュールであって、前記ペイロードの前記長さが前記ペイロード長さ値に等しく、前記チェック部分の長さが、FECコードタイプに対応するFECコードワード長さ値と前記ペイロード長さ値との間の差に等しい、順方向誤り訂正符号化モジュールと
を備え、
前記生成モジュールがコードワード構造を生成するようにさらに構成され、前記コードワード構造が、前記有効データ、前記チェック部分、および同期ヘッダを備え、前記同期ヘッダが、前記コードワード構造の先頭に配置されるか、または前記コードワード構造の末尾に配置されるか、または前記有効データと前記チェック部分との間に配置される、
装置。

【請求項13】

【請求項14】

PONシステムにおけるデータ復号装置であって、前記装置は、
コードワード構造を受信するように構成された受信モジュールであって、前記コードワード構造が、有効データ、チェック部分、および同期ヘッダを備え、前記同期ヘッダが、前記コードワード構造の先頭に配置されるか、または前記コードワード構造の末尾に配置されるか、または前記有効データと前記チェック部分との間に配置され、前記有効データがN個のデータブロックを備え、前記データブロックが、入力64B／66Bもしくは64B／65Bデータブロックからコード変換された128B／129Bもしくは256B／257Bデータブロックであり、Nが整数であり、順方向誤り訂正FECコードタイプに対応するペイロード長さ値を前記データブロックの長さで割って得られた商以下であり、前記チェック部分の長さが、FECコードワード長さ値と前記ペイロード長さ値との間の差に等しい、受信モジュールと、
前記同期ヘッダに基づいて前記受信されたコードワード構造を同期させるように構成された同期モジュールと、
ペイロードおよび前記チェック部分を抽出するように構成された抽出モジュールであって、前記ペイロードが前記有効データを備え、前記ペイロードの長さが前記ペイロード長さ値に等しい、抽出モジュールと、
前記FECコードタイプに基づいて前記ペイロードに対して順方向誤り訂正復号を実行するように構成された順方向誤り訂正復号モジュールと
を備える、装置。

【請求項15】

請求項12から14のいずれか一項に記載の装置を備える、光回線終端装置。

【請求項16】

請求項12から14のいずれか一項に記載の装置を備える、光ネットワークユニット。

【請求項17】

請求項15に記載の光回線終端装置と、請求項16に記載の光ネットワークユニットとを備える、PONシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、光通信の分野に関し、より詳細には、PONシステムにおけるデータ符号化方法および装置ならびにデータ復号方法および装置、光回線終端装置、光ネットワークユニット、ならびにPONシステムに関する。

【背景技術】

【0002】

パッシブ光ネットワーク（Passive Optical Network、PON）技術は、ポイントツーマルチポイントの光ファイバアクセス技術である。PONシステムは、光回線終端装置（Optical Line Terminal、OLT）、光配信ネットワーク（Optical Distribution Network、ODN）、および少なくとも1つの光ネットワークユニット（Optical Network Unit、ONU）を含んでよい。OLTはODNに接続され、ODNは複数のONUに接続される。

【0003】

イーサネットパッシブ光ネットワーク（Ethernet Passive Optical Network、EPON）技術は、メンテナンスが容易で、コストが低く、伝送帯域幅が高く、価格性能比が高いという主な特徴を有する、好ましいアクセス技術である。

【0004】

EPONはパッシブ光伝送技術であり、増幅機能および中継機能を有する構成部品を使用しない。したがって、EPONネットワークの伝送距離および分岐の数は、電力バジェットおよび様々な伝送損失に依存する。伝送距離または分岐の数が増えると、データ伝送の信号対雑音比（Signal Noise Ratio、SNR）が徐々に減少し、ビットエラーが多くなる。この問題を解決するために、EPONシステムにFEC技術が導入されて、システムの干渉防止機能が改善され、システムの電力バジェットが増大する。

【0005】

順方向誤り訂正（Forward Error Correction、FEC）コーディングでは、送信される前に、信号は特定の方式で前処理され、次いで、エラービットを検出し訂正するために、対応するアルゴリズムに基づいて受信側で復号される。EPONシステムにおけるFECコーディングの基本的な動作原理は以下の通りである。送信側で送信対象の情報データの後にFECチェックコードワードが付加され、チェックコードワードは、指定された規則に従って、チェック対象の情報データと関連付けられる（それによって制約される）。受信側は、指定された規則に従って、情報データとチェックコードワードとの間の関係をチェックする。送信中にエラーが発生すると、関係が破棄され、エラービットを自動的に検出し修正することができる。FEC技術は、最小数のチェックバイトを使用して最大数のエラーを修正し、オーバーヘッド（チェックバイトの増加）と取得されるコーディングゲインとの間の最適なバランスを達成しようと試みる。

【発明の概要】

【0006】

既存の10GEPONおよび1GEPONで使用されているFECコードタイプおよびラインコードは、以下の欠点：複雑な同期プロセスおよび低い同期速度を有する。

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

【0007】

これを考慮して、本出願は、同期プロセスを簡素化し、高速同期を実現するために、PONシステムにおけるデータ符号化方法および装置、データ復号方法および装置、ならびにプレコーディング指示方法および装置、光回線終端装置、光ネットワークユニット、ならびにPONシステムを提供する。

【0008】

第1の態様によれば、PONシステムにおけるデータ符号化方法が提供され、方法は、PONシステムにおけるネットワークデバイスによって実行されてよい。たとえば、OLTは、OLTがONUにデータを送信する場合に符号化を実行することができ、またはONUは、ONUがOLTにデータを送信する場合に符号化を実行することができる。符号化方法は物理コーディングサブレイヤにおいて実行され、方法は、物理コーディングサブレイヤにおいてN個のデータブロックを収集し、N個のデータブロックを組み合わせて有効データを生成するステップであって、Nが整数であり、順方向誤り訂正FECコードタイプに対応するペイロード長さ値を収集されたデータブロックの長さで割って得られた商以下であり（言い換えれば、Nがデータブロックの長さに対するFECコードタイプのペイロード長さ値の比以下であり）、FECコードワード長さ値およびペイロード長さ値がFECコードタイプに対応して設定される、ステップと、物理コーディングサブレイヤにおいてペイロードを生成するステップであって、ペイロードが有効データを含み、ペイロードの長さがFECコードタイプのペイロード長さ値に等しい、ステップと、チェック部分を生成するために、FECコードタイプに基づいてペイロードに対してFEC符号化を実行するステップであって、チェック部分の長さが、FECコードワード長さ値とペイロード長さ値との間の差に等しい、ステップと、物理コーディングサブレイヤにおいてコードワード構造を生成するステップであって、コードワード構造が、有効データ、チェック部分、および同期ヘッダを含み、有効データ、チェック部分、および同期ヘッダが、コードワード構造内で独立して分散される、ステップとを含む。これにより、同期ヘッダを迅速に配置することができるので、高速でシンプルな同期を実現することができる。

【0009】

同期ヘッダは、高速同期をさらに実現するために、コードワード構造の先頭または末尾に配置することができる。同期ヘッダは、代替として、有効データとチェック部分との間に配置されてよい。

【0010】

収集されたデータブロックは、128B／129Bまたは256B／257Bデータブロックであり、物理コーディングサブレイヤに入力されたデータブロックは、64B／66Bまたは64B／65Bデータブロックである。この場合、物理コーディングサブレイヤは、入力された64B／66Bまたは64B／65Bデータブロックを128B／129Bまたは256B／257Bデータブロックにコード変換する必要がある。コード変換により、符号化のオーバーヘッドが低減され、帯域幅の効率を効果的に改善することができる。

【0011】

あるいは、収集されたデータブロックは、64B／66Bまたは64B／65Bデータブロックであってよい。

【0012】

FECコードタイプは、LDPC（18493、15677）、RS（2047、1739）、RS（1023、847）、RS（1023、845）、RS（1023、843）、RS（1023、841）、RS（1015、839）、RS（1017、839）、またはRS（1019、839）である。誤り訂正機能は改善することができる。

【0013】

FECコードワード長さ値は、ペイロード長さ値およびチェック長値の合計に等しい。具体的には、その数がチェック長値であるチェックビットは、その数がペイロード長さ値である有効ビットに対してFEC符号化が実行された後に生成され、有効ビットの長さおよびチェックビットの長さの合計はFECコードワード長さ値に等しい。

【0014】

有効データの長さがペイロード長さ値に等しいとき、ペイロードは有効データから構成される。ペイロードはすべて有効データであり、したがって、符号化効率および帯域幅効率は高い。

【0015】

有効データの長さは、代替として、使用されたFECコードタイプのペイロード長さ値より小さくてよく、コードワード構造はパディング部分をさらに含む。この場合、ペイロードは有効データおよびパディング部分から構成される。ペイロードの長さは、使用されたFECコードタイプのペイロード長さ値に等しい。言い換えれば、パディング部分の長さは、ペイロード長さ値と有効データの長さとの間の差に等しくてよい。パディング部分の長さは、代替として、ペイロード長さ値を収集されたデータブロックの長さで割って得られた余りに等しくてよい。パディングフィールドを追加することにより、様々なFECコードタイプとラインコードとの間で効果的な互換性および適応性を実現することができる。

【0016】

入力レートおよび出力レートが変更されないままであることを保証にするために、同期ヘッダの長さは以下の方式で計算されてよい：同期ヘッダの長さがSであり、入力データブロックの長さがXであり、FECコードワード長さ値をXで割って得られた余りがYである場合、S＝tX－Yであり、ここで、tは整数であり、Y≠0であるときt≧1であり、またはY＝0であるときt≧0である。

【0017】

Y＝0およびt＝0であるとき、S＝0である。この場合、パディング部分が同期ヘッダとして使用されてよい。パディング部分全体が同期ヘッダとして使用されてもよく、パディング部分内のいくつかのビットが同期ヘッダとして使用されてもよい。追加のビットは必要でないが、代わりにパディング部分が同期ヘッダとして直接使用される。これにより、無効データのビットが効果的に削減され、帯域幅効率および符号化効率が改善される。

【0018】

パディング部分は、コードワード構造の長さ、有効データの長さ、有効データの長さおよびチェック部分の長さの合計、ペイロードの長さ、またはペイロードの長さおよびチェック部分の長さの合計を示すためにさらに使用されてよい。パディング部分は、その中にパディング部分が配置されたコードワード構造を示してもよく、次のコードワード構造または別のコードワード構造を示してもよい。あるいは、コードワード構造は指示部分をさらに含んでよい。指示部分は、コードワード構造の長さ、有効データの長さ、有効データの長さおよびチェック部分の長さの合計、ペイロードの長さ、またはペイロードの長さおよびチェック部分の長さの合計を示すために使用される。指示部分は、その中に指示部分が配置されたコードワード構造を示してもよく、次のコードワード構造または別のコードワード構造を示してもよい。同期ヘッダ内のいくつかのビットが指示に使用されてよい。パディング部分または指示部分により、ターゲットネットワークデバイスが正しい構文解析を実施するためにコードワード構造の長さを知ることが可能になる。

【0019】

前述の実装形態の詳細は組み合わされてよいことが理解されよう。たとえば、コードワード構造はパディング部分と指示部分の両方を含んでよく、パディング部分内のいくつかまたはすべてのビットは同期ヘッダとして使用される。あるいは、コードワード構造はパディング部分と同期ヘッダの両方を含んでよく、パディング部分内のいくつかまたはすべてのビットは同期ヘッダとして使用される。この場合、2つの同期ヘッダが存在する。あるいは、パディング部分内のいくつかのビットは同期ヘッダとして使用され、他のビットは、コードワード構造の長さ、有効データの長さ、有効データの長さおよびチェック部分の長さの合計、ペイロードの長さ、またはペイロードの長さおよびチェック部分の長さの合計を示すために使用される。この場合、前述のさらなる同期ヘッダは含まれてもよく、含まれなくてもよい。

【0020】

第2の態様によれば、PONシステムにおけるデータ復号方法が提供され、方法は、PONシステムにおけるネットワークデバイスによって実行されてよい。たとえば、ONUは、OLTがONUにデータを送信する場合に復号を実行することができ、またはOLTは、ONUがOLTにデータを送信する場合に復号を実行することができる。復号方法は物理コーディングサブレイヤにおいて実行され、方法は、物理コーディングサブレイヤにおいてコードワード構造を受信するステップであって、コードワード構造が、有効データ、チェック部分、および同期ヘッダを含み、有効データ、チェック部分、および同期ヘッダが、コードワード構造内で独立して分散され、有効データがN個のデータブロックを含み、Nが整数であり、データブロックの長さに対する順方向誤り訂正FECコードタイプに対応するペイロード長さ値の比以下であり、FECコードワード長さ値およびペイロード長さ値がFECコードタイプに対応して設定され、チェック部分の長さが、FECコードワード長さ値とペイロード長さ値との間の差に等しい、ステップと、物理コーディングサブレイヤにおいて、同期ヘッダに基づいて受信されたコードワード構造を同期させるステップと、ペイロードおよびチェック部分を抽出するステップであって、ペイロードが有効データを含み、ペイロードの長さがペイロード長さ値に等しい、ステップと、FECコードタイプに基づいてペイロードに対して順方向誤り訂正復号を実行するステップとを含む。有効データ、チェック部分、および同期ヘッダがコードワード構造内で独立して分散されるので、高速同期を実現することができ、帯域幅効率および誤り訂正機能を改善することができる。

【0021】

第3の態様によれば、PONシステムにおけるプリコーディング指示方法が提供される。方法は、OLTの物理コーディングサブレイヤによって実行されてもよく、ONUの物理コーディングサブレイヤによって実行されてもよい。方法は、物理コーディングサブレイヤにより、コードワード構造がプリコーディングされているかどうかを示す指示情報を同期ヘッダに追加するステップを含む。同期ヘッダ内の事前設定された位置にあるビットは、指示情報として使用されてよい。具体的な位置は、ソースネットワークデバイスおよびターゲットネットワークデバイスによって合意されてよい。たとえば、同期ヘッダ内の最後のビットが「0」である場合、それはコードワード構造がプリコーディングされていることを示し、同期ヘッダ内の最後のビットが「1」である場合、それはコードワード構造がプリコーディングされていないことを示す。方法は、物理コーディングサブレイヤにより、コードワード構造を生成するステップであって、コードワード構造が、ペイロード、チェックデータ、および同期ヘッダを含む、ステップと、物理コーディングサブレイヤにより、コードワード構造を送信するステップとをさらに含む。このようにして、ターゲットネットワークデバイスは、指示情報に基づいて、コードワード構造がプリコーディングされているかどうかを判定することができる。

【0022】

第4の態様によれば、PONシステムにおけるプリコーディング指示方法が提供される。方法は、OLTの物理コーディングサブレイヤによって実行されてもよく、ONUの物理コーディングサブレイヤによって実行されてもよい。方法は、物理コーディングサブレイヤにより、コードワード構造を受信するステップであって、コードワード構造が、ペイロード、チェックデータ、および同期ヘッダを含み、同期ヘッダが、コードワード構造がプリコーディングされているかどうかを示すために使用される指示情報を含む、ステップと、物理コーディングサブレイヤにより、同期ヘッダ内の指示情報に基づいて、コードワード構造がプリコーディングされているかどうかを判定するステップとを含む。

【0023】

ターゲットネットワークデバイスは、ブラインド検出を介して、受信されたコードワード構造がプリコーディングされているかどうかを判定することができる。ターゲットネットワークデバイスは、第1の同期シーケンスおよび第2の同期シーケンスを事前に記憶することができる。第1の同期シーケンスは、プリコーディング前のコードワード構造用の元の同期シーケンスであってよく、第2の同期シーケンスは、プリコーディング後のコードワード構造用の出力同期シーケンスであってよい。同期ヘッダが第1の同期シーケンスと一致する場合、コードワード構造がプリコーディングされていないと判断される。この場合、ターゲットネットワークデバイスは、コードワード構造から有効データおよびチェック部分を直接抽出する。同期ヘッダが第2の同期シーケンスと一致する場合、コードワード構造がプリコーディングされていると判断される。ターゲットネットワークデバイスはコードワード構造をデプリコーディングし、ターゲットネットワークデバイスは、デプリコーディングされたコードワード構造から有効データおよびチェック部分を抽出する。コードワード構造がプリコーディングされているかどうかを示す指示情報が同期ヘッダに追加され、その結果、ターゲットネットワークデバイスは、その情報に基づいて、以前のブラインド検出結果が正しいかどうかをさらに判定して、ダブルチェックを行うことができる。

【0024】

第5の態様によれば、PONシステムにおけるプリコーディング指示方法が提供される。方法は、OLTのMACサブレイヤまたはプロセッサによって実行されてもよく、ONUまたはONUのMACサブレイヤによって実行されてもよい。方法は、ソースネットワークデバイスにより、データフレームを生成するステップであって、データフレームが、ソースネットワークデバイスがプリコーディング機能を有するかどうかを示すために使用されるか、またはターゲットネットワークデバイスがプリコーディングもしくはデプリコーディングを実行する必要があるかどうかを示すために使用されるか、またはプリコーディングイネーブルビットを有効もしくは無効にするようにターゲットネットワークデバイスに示すために使用される指示情報を含む、ステップと、ソースネットワークデバイスにより、ターゲットネットワークデバイスにデータフレームを送信するステップとを含む。このようにして、ターゲットネットワークデバイスは、指示情報に基づいて、プリコーディングおよびデプリコーディングを実行するべきかどうかを判定することができる。

【0025】

ソースネットワークデバイスはONUであってよく、ターゲットネットワークデバイスはOLTであってよい。データフレームは登録要求メッセージを搬送し、登録要求メッセージには、ONUがプリコーディング機能を有するかどうかを示すために使用される指示情報を含む。ソースネットワークデバイスによって送信されたデータフレームがデプリコーディングされる必要があるかどうか、およびソースネットワークデバイスに送信されるべきデータフレームがプリコーディングされる必要があるかどうかをターゲットネットワークデバイスに通知するために、ソースネットワークデバイスがプリコーディング機能を有するかどうかを示す指示情報がデータフレームに追加される。

【0026】

ソースネットワークデバイスはOLTであってよく、ターゲットネットワークデバイスはONUであってよい。データフレームは発見ゲートメッセージを搬送し、発見ゲートメッセージは、ONUがプリコーディングまたはデプリコーディングを実行する必要があるかどうかを示すために使用される指示情報を含む。具体的には、OLTは、ダウンストリーム内でONUに送信されたメッセージがプリコーディングされているかどうかを示す、すなわち、ONUがダウンストリーム内で受信されたデータをデプリコーディングする必要があるかどうかを示すことができ、さらに、アップストリーム内でONUによってOLTに送信されるべきアップストリームデータがプリコーディングされる必要があるかどうかを示すことができる。データフレームがプリコーディングされているかどうかを示す指示情報がデータフレームに追加され、その結果、ターゲットネットワークデバイスは、その情報に基づいて、以前のブラインド検出結果が正しいかどうかをさらに判定して、ダブルチェックを行うことができる。加えて、アップストリームまたはダウンストリーム内でプリコーディングが必要であるかどうかが示され、その結果、ソースネットワークデバイスおよびターゲットネットワークデバイスは、その指示に基づいてプリコーディングおよびデプリコーディングを実行することができる。これにより、エラーが回避され、効率が改善される。

【0027】

ソースネットワークデバイスはOLTであってよく、ターゲットネットワークデバイスはONUであってよい。データフレームは登録メッセージを搬送し、登録メッセージは、プリコーディングイネーブルビットを有効または無効にするようにONUに示すために使用される指示情報を含む。指示情報を受信した後、ONUはプリコーディングイネーブルビットを有効または無効にする。

【0028】

第6の態様によれば、PONシステムにおけるプリコーディング指示方法が提供される。方法は、OLTのMACサブレイヤまたはプロセッサによって実行されてもよく、ONUまたはONUのMACサブレイヤによって実行されてもよい。方法は、ターゲットネットワークデバイスにより、ソースネットワークデバイスによって送信されたデータフレームを受信するステップであって、データフレームが、データフレームがプリコーディングされているかどうか、ソースネットワークデバイスがプリコーディング機能を有するかどうか、またはターゲットネットワークデバイスがプリコーディングもしくはデプリコーディングを実行する必要があるかどうかを示すために使用される指示情報を含む、ステップと、ターゲットネットワークデバイスにより、指示情報に基づいて、データフレームをデプリコーディングするべきかどうか、またはソースネットワークデバイスとの間で送信されるデータフレームをプリコーディングおよびデプリコーディングするべきかどうかを判定するステップとを含む。

【0029】

第7の態様によれば、PONシステムにおけるデータ符号化装置が提供される。装置は、N個のデータブロックを収集し、N個のデータブロックを組み合わせて有効データを生成するように構成された収集モジュールであって、Nが整数であり、データブロックの長さに対する順方向誤り訂正FECコードタイプに対応するペイロード長さ値の比以下であり、FECコードワード長さ値およびペイロード長さ値がFECコードタイプに対応して設定される、収集モジュールと、ペイロードを生成するように構成された生成モジュールであって、ペイロードが有効データを含み、ペイロードの長さがペイロード長さ値に等しい、生成モジュールと、チェック部分を生成するために、FECコードタイプに基づいてペイロードに対してFEC符号化を実行するように構成された順方向誤り訂正符号化モジュールであって、ペイロードの長さがペイロード長さ値に等しく、チェック部分の長さがFECコードワード長さ値とペイロード長さ値との間の差に等しい、順方向誤り訂正符号化モジュールとを含む。生成モジュールは、コードワード構造を生成するようにさらに構成され、コードワード構造は、有効データ、チェック部分、および同期ヘッダを含み、高速同期を実現し、帯域幅効率および誤り訂正機能を改善するために、有効データ、チェック部分、および同期ヘッダは、コードワード構造内で独立して分散される。

【0030】

第8の態様によれば、PONシステムにおけるデータ復号装置が提供される。装置は、コードワード構造を受信するように構成された受信モジュールであって、コードワード構造が、有効データ、チェック部分、および同期ヘッダを含み、有効データ、チェック部分、および同期ヘッダが、コードワード構造内で独立して分散され、FECコードワード長さ値およびペイロード長さ値が使用される順方向誤り訂正FECコードタイプに対応して設定され、有効データがN個のデータブロックを含み、Nが整数であり、データブロックの長さに対するFECコードタイプに対応するペイロード長さ値の比以下であり、FECコードワード長さ値およびペイロード長さ値がFECコードタイプに対応して設定され、チェック部分の長さが、FECコードワード長さ値とペイロード長さ値との間の差に等しい、受信モジュールと、同期ヘッダに基づいて受信されたコードワード構造を同期させるように構成された同期モジュールと、ペイロードおよびチェック部分を抽出するように構成された抽出モジュールであって、ペイロードが有効データを含み、ペイロードの長さがペイロード長さ値に等しい、抽出モジュールと、FECコードタイプに基づいてペイロードに対して順方向誤り訂正復号を実行するように構成された順方向誤り訂正復号モジュールとを含む。有効データ、チェック部分、および同期ヘッダがコードワード構造内で独立して分散されるので、高速同期を実現することができ、帯域幅効率および誤り訂正機能を改善することができる。

【0031】

第9の態様によれば、PONシステムにおけるプリコーディング指示装置が提供される。装置は、コードワード構造がプリコーディングされているかどうかを示す指示情報を同期ヘッダに追加するように構成された追加モジュールと、コードワード構造を生成するように構成された生成モジュールであって、コードワード構造が、ペイロード、チェックデータ、および同期ヘッダを含む、生成モジュールと、コードワード構造を送信するように構成された送信モジュールとを含む。このようにして、コードワード構造を受信するネットワークデバイスは、指示情報に基づいて、コードワード構造がプリコーディングされているかどうかを判定することができる。

【0032】

第10の態様によれば、PONシステムにおけるプリコーディング指示装置が提供される。装置は、コードワード構造を受信するように構成された受信モジュールであって、コードワード構造が、ペイロード、チェックデータ、および同期ヘッダを含み、同期ヘッダが、コードワード構造がプリコーディングされているかどうかを示すために使用される指示情報を含む、受信モジュールと、同期ヘッダ内の指示情報に基づいて、コードワード構造がプリコーディングされているかどうかを判定するように構成された判定モジュールとを含む。コードワード構造がプリコーディングされているかどうかを示す指示情報が同期ヘッダに追加され、その結果、ターゲットネットワークデバイスは、その情報に基づいて、以前のブラインド検出結果が正しいかどうかをさらに判定して、ダブルチェックを行うことができる。

【0033】

第11の態様によれば、PONシステムにおけるプリコーディング指示装置が提供される。装置は、データフレームを生成するように構成された生成モジュールであって、データフレームが、データフレームがプリコーディングされているかどうか、装置がプリコーディング機能を有するかどうか、またはターゲットネットワークデバイスがプリコーディングもしくはデプリコーディングを実行する必要があるかどうかを示すために使用される指示情報を含む、生成モジュールと、ターゲットネットワークデバイスにデータフレームを送信するように構成された送信モジュールとを含む。このようにして、ターゲットネットワークデバイスは、指示情報に基づいて、プリコーディングおよびデプリコーディングを実行するべきかどうかを判定することができる。

【0034】

第12の態様によれば、PONシステムにおけるプリコーディング指示装置が提供される。装置は、ソースネットワークデバイスによって送信されたデータフレームを受信するように構成された受信モジュールであって、データフレームが、データフレームがプリコーディングされているかどうか、ソースネットワークデバイスがプリコーディング機能を有するかどうか、または装置がプリコーディングもしくはデプリコーディングを実行する必要があるかどうかを示すために使用される指示情報を含む、受信モジュールと、指示情報に基づいて、データフレームをデプリコーディングするべきかどうか、またはソースネットワークデバイスとの間で送信されるデータフレームをプリコーディングおよびデプリコーディングするべきかどうかを判定するように構成された判定モジュールとを含む。

【0035】

第13の態様によれば、ネットワークデバイスが提供される。ネットワークデバイスはOLTまたはONUであってよい。ネットワークデバイスはチップを含んでよく、チップはMACチップであってよい。チップは、物理コーディングサブレイヤにおいてN個のデータブロックを収集し、N個のデータブロックを組み合わせて有効データを生成することであって、Nが整数であり、データブロックの長さに対する順方向誤り訂正FECコードタイプに対応するペイロード長さ値の比以下であり、FECコードワード長さ値およびペイロード長さ値がFECコードタイプに対応して設定される、生成することと、物理コーディングサブレイヤにおいてペイロードを生成することであって、ペイロードが有効データを含み、ペイロードの長さがペイロード長さ値に等しい、生成することと、チェック部分を生成するために、FECコードタイプに基づいて、物理コーディングサブレイヤにおいてペイロードに対してFEC符号化を実行することであって、チェック部分の長さが、FECコードワード長さ値とペイロード長さ値との間の差に等しい、実行することと、物理コーディングサブレイヤにおいてコードワード構造を生成することであって、コードワード構造が、有効データ、チェック部分、および同期ヘッダを含み、高速同期を実現し、帯域幅効率および誤り訂正機能を改善するために、有効データ、チェック部分、および同期ヘッダが、コードワード構造内で独立して分散される、生成することとを行うように構成される。

【0036】

第14の態様によれば、ネットワークデバイスが提供される。ネットワークデバイスはOLTまたはONUであってよい。ネットワークデバイスはチップを含んでよく、チップはMACチップであってよい。チップは、物理コーディングサブレイヤにおいてコードワード構造を受信することであって、コードワード構造が、有効データ、チェック部分、および同期ヘッダを含み、有効データ、チェック部分、および同期ヘッダが、コードワード構造内で独立して分散され、有効データがN個のデータブロックを含み、Nが整数であり、データブロックの長さに対する順方向誤り訂正FECコードタイプに対応するペイロード長さ値の比以下であり、FECコードワード長さ値およびペイロード長さ値がFECコードタイプに対応して設定され、チェック部分の長さが、FECコードワード長さ値とペイロード長さ値との間の差に等しい、受信することと、物理コーディングサブレイヤにおいて、同期ヘッダに基づいて受信されたコードワード構造を同期させることと、ペイロードおよびチェック部分を抽出することであって、ペイロードが有効データを含み、ペイロードの長さがペイロード長さ値に等しい、抽出することと、FECコードタイプに基づいてペイロードに対して順方向誤り訂正復号を実行することとを行うように構成される。有効データ、チェック部分、および同期ヘッダがコードワード構造内で独立して分散されるので、高速同期を実現することができ、帯域幅効率および誤り訂正機能を改善することができる。ネットワークデバイスはチップを含んでよく、チップはMACチップであってよく、MACチップは物理コーディングサブレイヤを含む。

【0037】

第15の態様によれば、ネットワークデバイスが提供される。ネットワークデバイスはOLTまたはONUであってよい。ネットワークデバイスは物理コーディングサブレイヤを含む。物理コーディングサブレイヤは、コードワード構造がプリコーディングされているかどうかを示す指示情報を同期ヘッダに追加する。同期ヘッダ内の事前設定された位置にあるビットは、指示情報として使用されてよい。具体的な位置は、ソースネットワークデバイスおよびターゲットネットワークデバイスによって合意されてよい。たとえば、同期ヘッダ内の最後のビットが「0」である場合、それはコードワード構造がプリコーディングされていることを示し、同期ヘッダ内の最後のビットが「1」である場合、それはコードワード構造がプリコーディングされていないことを示す。物理コーディングサブレイヤはコードワード構造を生成し、コードワード構造は、ペイロード、チェックデータ、および同期ヘッダを含み、物理コーディングサブレイヤはコードワード構造を送信する。このようにして、ターゲットネットワークデバイスは、指示情報に基づいて、コードワード構造がプリコーディングされているかどうかを判定することができる。ネットワークデバイスはチップを含んでよく、チップはMACチップであってよく、MACチップは物理コーディングサブレイヤを含む。

【0038】

第16の態様によれば、ネットワークデバイスが提供される。ネットワークデバイスはOLTまたはONUであってよい。ネットワークデバイスは物理コーディングサブレイヤを含む。物理コーディングサブレイヤはコードワード構造を受信し、コードワード構造は、ペイロード、チェックデータ、および同期ヘッダを含み、同期ヘッダは、コードワード構造がプリコーディングされているかどうかを示すために使用される指示情報を含み、物理コーディングサブレイヤは、同期ヘッダ内の指示情報に基づいて、コードワード構造がプリコーディングされているかどうかを判定する。ネットワークデバイスはチップを含んでよく、チップはMACチップであってよく、MACチップは物理コーディングサブレイヤを含む。

【0039】

第17の態様によれば、ネットワークデバイスが提供される。ネットワークデバイスはOLTまたはONUであってよい。ネットワークデバイスは、MACサブレイヤ、プロセッサ、およびトランシーバを含む。MACサブレイヤまたはプロセッサはデータフレームを生成し、データフレームは、ネットワークデバイスがプリコーディング機能を有するかどうかを示すために使用されるか、またはターゲットネットワークデバイスがプリコーディングもしくはデプリコーディングを実行する必要があるかどうかを示すために使用されるか、またはプリコーディングイネーブルビットを有効もしくは無効にするようにターゲットネットワークデバイスに示すために使用される指示情報を含む。トランシーバはターゲットネットワークデバイスにデータフレームを送信する。このようにして、ターゲットネットワークデバイスは、指示情報に基づいて、プリコーディングおよびデプリコーディングを実行するべきかどうかを判定することができる。

【0040】

第18の態様によれば、ネットワークデバイスが提供される。ネットワークデバイスはOLTまたはONUであってよい。ネットワークデバイスは、MACサブレイヤ、プロセッサ、およびトランシーバを含む。トランシーバは、ソースネットワークデバイスによって送信されたデータフレームを受信し、データフレームは、データフレームがプリコーディングされているかどうか、ソースネットワークデバイスがプリコーディング機能を有するかどうか、またはネットワークデバイスがプリコーディングもしくはデプリコーディングを実行する必要があるかどうかを示すために使用される指示情報を含む。MACサブレイヤまたはプロセッサは、指示情報に基づいて、データフレームをデプリコーディングするべきかどうか、またはソースネットワークデバイスとの間で送信されたデータフレームをプリコーディングおよびデプリコーディングするべきかどうかを判定する。

【0041】

異なる実施形態は異なる特許請求された主題を有するが、特定の実装形態の詳細に対して相互参照が行われてよいことが理解されよう。実装形態の詳細がないいくつかの特許請求された主題については、他の主題に対して参照が行われてよい。

【0042】

第19の態様によれば、光回線終端装置が提供される。光回線終端装置は、第7から第12の態様のいずれか1つによる装置、または第13から第18の態様のいずれか1つによるネットワークデバイスを含む。

【0043】

第20の態様によれば、光ネットワークユニットが提供され、光ネットワークユニットは、第7から第12の態様のいずれか1つによる装置、または第13から第18の態様のいずれか1つによるネットワークデバイスを含む。

【0044】

本出願の別の態様によれば、コードワード構造が提供される。コードワード構造は、ペイロード、チェック部分、および同期ヘッダを含む。チェック部分は、ペイロードに対してFEC符号化が実行された後に生成され、ペイロードは有効データを含む。有効データはN個のデータブロックを含み、FECコードワード長さ値およびペイロード長さ値は各FECコードタイプに対応して設定され、Nは整数であり、ペイロード長さ値をデータブロックの長さで割って得られた商以下である。ペイロードの長さはペイロード長さ値に等しく、チェック部分の長さは、FECコードワード長さ値とペイロード長さ値との間の差に等しい。有効データ、チェック部分、および同期ヘッダは、コードワード構造内で独立して分散される。

【0045】

同期ヘッダ、データブロック、FECコードタイプ、コードワード構造などの具体的な詳細については、他の態様を参照されたい。詳細は本明細書では再び記載されない。

【0046】

本出願のまた別の態様によれば、MACチップが提供される。MACチップは、第7から第12の態様のいずれか1つによる装置を含む。

【0047】

本出願のさらに別の態様によれば、PONシステムが提供される。システムは、第19の態様による光回線終端装置および第20の態様による光ネットワークユニットを含む。

【0048】

本出願のまたさらに別の態様によれば、コンピュータ可読記憶媒体が提供される。コンピュータ可読記憶媒体は、第7から第12の態様のいずれか1つによる装置によって使用されるコンピュータソフトウェア命令を記憶するか、または第13から第18の態様のいずれか1つによるネットワークデバイスによって使用されるコンピュータソフトウェア命令を記憶する。コンピュータソフトウェア命令がコンピュータ上で実行されると、コンピュータは前述の態様による方法を実行することが可能になる。

【図面の簡単な説明】

【0049】

【図1】本発明の一実施形態による、PONシステムの概略アーキテクチャ図である。

【図2】本発明の一実施形態による、データ符号化および復号方法の例示的なフローチャートである。

【図3(a)】本発明の一実施形態による、データブロックコード変換の概略図である。

【図3(b)】本発明の一実施形態による、データブロックコード変換の別の概略図である。

【図3(c)】本発明の一実施形態による、データブロックコード変換のまた別の概略図である。

【図3(d)】本発明の一実施形態による、データブロックコード変換のさらに別の概略図である。

【図3(e)】本発明の一実施形態による、データブロックコード変換のまたさらに別の概略図である。

【図3(f)】本発明の一実施形態による、データブロックコード変換のさらなる概略図である。

【図4(1)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの概略図である。

【図4(2)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(3)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(4)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(5)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(6)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(7)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(8)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(9)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(10)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(11)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(12)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(13)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(14)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(15)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(16)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(17)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図4(18)】本発明の一実施形態による、FECコーディングとラインコーディングの組合せの別の概略図である。

【図5】本発明の一実施形態による、プリコーディング指示方法の例示的なフローチャートである。

【図6】本発明の別の実施形態による、プリコーディング指示方法の例示的なフローチャートである。

【図7】本発明の一実施形態による、ネットワークデバイスのハードウェア構造の概略図である。

【図8】本発明の一実施形態による、データ符号化装置の例示的な機能モジュールの概略図である。

【図9】本発明の一実施形態による、データ復号装置の例示的な機能モジュールの別の概略図である。

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

【0050】

本発明の発明目的、特徴、および利点をより明確かつより分かりやすくするために、以下では、本発明の実施形態における添付図面を参照して、本発明の実施形態における技術的解決策を明確かつ完全に記載する。明らかに、以下に記載される実施形態は、本発明の実施形態のすべてではなく、一部にすぎない。創造的な努力なしに本発明の実施形態に基づいて当業者によって取得されるすべての他の実施形態は、本発明の保護範囲内に入るべきである。

【0051】

本発明の実施形態における技術的解決策は、様々なイーサネットパッシブ光ネットワーク（Ethernet Passive Optical Network、EPON）およびギガビット対応パッシブ光ネットワーク（gigabit-capable passive optical network、GPON）、たとえば10G EPON、単一波長25G EPON、2×25G EPON、単一波長50G EPON、2×50G EPON、100G EPON、および様々なGPONに適用されてよい。

【0052】

図1は、本発明の実施形態に適用可能なPONシステムの概略アーキテクチャ図である。図1に示されたように、PONシステム100は、少なくとも1つのOLT110、少なくとも1つのODN120、および複数のONU130を含む。OLT110はPONシステム100にネットワーク側インターフェースを提供し、ONU130はPONシステム100にユーザ側インターフェースを提供し、ODN120に接続される。ONU130がユーザポート機能を直接提供する場合、ONU130は、光ネットワーク端末（Optical Network Terminal、ONT）と呼ばれる。説明を簡単にするために、以下で言及されるONU130は、ユーザポート機能を直接提供することができるONT、およびユーザ側インターフェースを提供することができるONUを包含する包括的な用語として使用される。ODN120は光ファイバおよびパッシブ光スプリッタを含むネットワークであり、ODNは、OLT110デバイスとONU130デバイスを接続するように構成され、OLT110とONU130との間でデータ信号を分配または多重化するように構成される。

【0053】

PONシステム100では、OLT110からONU130への方向がダウンストリーム方向として定義され、ONU130からOLT110への方向がアップストリーム方向として定義される。ダウンストリーム方向では、OLT110は、OLT110によって管理される複数のONU130にダウンストリームデータを時分割多重化（Time Division Multiplexing、TDM）モードでブロードキャストし、各ONU130は、ONU130の識別子を搬送するデータのみを受信する。アップストリーム方向では、複数のONU130が時分割多元接続（Time Division Multiple Access、TDMA）モードでOLT110と通信し、各ONU130は、OLT110によってONU130に割り当てられた時間領域リソースを使用してアップストリームデータを送信する。前述のメカニズムによれば、OLT110によって送信されるダウンストリーム光信号は連続光信号であり、ONU130によって送信されるアップストリーム光信号はバースト光信号である。

【0054】

OLT110は、通常、中央オフィス（Central Office、CO）に配置され、少なくとも1つのONU130を無差別に管理し、ONU130と上位層ネットワークとの間でデータを送信することができる。具体的には、OLT110は、ONU130と上位層ネットワーク（たとえば、インターネットまたは公衆交換電話網（Public Switched Telephone Network、PSTN））との間の仲介者として機能して、上位層ネットワークから受信されたデータをONU130に転送し、ONU130から受信されたたデータを上位層ネットワークに転送することができる。OLT110の特定の構造構成は、特定のタイプのPONシステム100によって異なってよい。たとえば、一実施形態では、OLT110は送信機および受信機を含んでよい。送信機は、ONU130に連続ダウンストリーム光信号を送信するように構成され、受信機は、ONU130からバーストアップストリーム光信号を受信するように構成される。ダウンストリーム光信号およびアップストリーム光信号は、ODN120を介して送信されてよい。しかしながら、本発明の実施形態は、この例によって限定されない。

【0055】

ONU130は、ユーザ側の位置（たとえば、顧客構内）で分散されてよい。ONU130は、OLT110およびユーザと通信するように構成されたネットワークデバイスであってよい。具体的には、ONU130は、OLT110とユーザとの間の仲介者として機能することができる。たとえば、ONU130は、OLT110から受信されたデータをユーザに転送し、ユーザから受信されたデータをOLT110に転送することができる。

【0056】

ODN120はデータ配信ネットワークであってよく、光ファイバ、光カプラ、光スプリッタ、または別のデバイスを含んでよい。一実施形態では、光ファイバ、光カプラ、光スプリッタ、または別のデバイスは、パッシブ光構成部品であってよい。具体的には、光ファイバ、光カプラ、光スプリッタ、または別のデバイスは、OLT110とONU130との間でデータ信号を分配するために給電される必要がない構成部品であってよい。具体的には、一例として光スプリッタ（Splitter）が使用される。光スプリッタは、OLT110とONU130との間のポイントツーマルチポイント接続を実現するために、フィーダファイバを介してOLT110に接続され、複数の分配ファイバを介して複数のONU130に接続されてよい。加えて、別の実施形態では、ODN120は、1つまたは複数の処理デバイス、たとえば、光増幅器またはリレーデバイス（Relay device）をさらに含んでよい。加えて、ODN120は、具体的に、OLT110から複数のONU130に延在することができ、または任意の他のポイントツーマルチポイント構造で構成されてよい。このことは本発明の実施形態では限定されない。

【0057】

以下に記載される本発明の実施形態の技術的解決策では、OLT110は、符号化を実行してコードワード構造を生成し、ONU130がコードワード構造を復号するように、ONU130にコードワード構造を送信することができる。あるいは、ONU130は、コードワード構造を符号化し、OLT110がコードワード構造を復号するように、OLT110にコードワード構造を送信することができる。説明を簡単にするために、送信機として使用されるOLT110およびONU130の一方はソースネットワークデバイスと呼ばれ、受信機として使用される他方はターゲットネットワークデバイスと呼ばれる。

【0058】

したがって、以下で、データ符号化および復号方法を提供する。以下で、添付図面を参照して、本発明のこの実施形態において提供されるデータ符号化および復号方法を詳細に記載する。図2に示されたように、方法はステップS200～S209を含む。ステップの具体的な実装形態は以下の通りである。

【0059】

S200．ソースネットワークデバイスの物理コーディングサブレイヤが、入力64B／66Bまたは64B／65Bデータブロックを受信する。

【0060】

この実施形態では、入力データブロックは送信される必要があるデータコンテンツである。物理コーディングサブレイヤは、PCS（Physical Coding Sublayer）とも呼ばれる。

【0061】

64B／66Bデータブロックの全長は66ビットであり、64ビットデータ、およびデータブロック内の64ビットデータがデータ情報か制御情報かを示すために使用される2ビットの指示情報を含む。2ビットの指示情報は、データブロックの先頭または末尾に配置されてよい。

【0062】

同様に、64B／65Bデータブロックの全長は65ビットであり、64ビットデータ、およびデータブロック内の64ビットデータがデータ情報か制御情報かを示すために使用される1ビットの指示情報を含む。1ビットの指示情報は、データブロックの先頭または末尾に配置されてよい。

【0063】

同様に、以下の実施形態に記載される128B／129Bデータブロックおよび256B／257Bデータブロックは、前述のデータブロックと同様であり、詳細は本明細書では再び記載されない。

【0064】

S201．物理コーディングサブレイヤが、入力64B／66Bまたは64B／65Bデータブロックを128B／129Bまたは256B／257Bデータブロックにコード変換する。ステップS201はオプションのステップである。ステップS202において収集されたデータブロックが64B／66Bまたは64B／65Bデータブロックである場合、ステップS201は省略されてよい。ステップS202において収集されたデータブロックが128B／129Bまたは256B／257Bデータブロックである場合、ステップS201は実行されてよい。

【0065】

64B／66Bデータブロックを128B／129Bデータブロックにコード変換することが図3（a）～図3（d）に示される。2つの64B／66Bデータブロックごとに1つの128B／129Bデータブロックにコード変換される。

【0066】

64B／66Bデータブロックは、2つのタイプ：データ情報を搬送するデータブロックおよび制御情報を搬送するデータブロックに分類される。一例として図3（a）～図3（d）を使用すると、データブロック内の2ビットの指示情報が「01」である場合、それは、データブロック内の64ビットデータがデータ情報であることを示す。データブロック内の2ビットの指示情報が「10」である場合、それは、データブロック内の64ビットデータが制御情報であることを示す。

【0067】

図3（a）に示されたように、データ情報を搬送する2つの64B／66Bデータブロックは、1つの128B／129Bデータブロックにコード変換される。2つの64B／66Bデータブロックの各々の中の2ビットの指示情報が削除されてよく、コード変換されたデータブロック内で搬送される128ビットデータの（2つのタイプ：データ情報および制御情報を含む）データタイプを示すために、1ビットの指示情報が追加される。図3（a）に示されたように、DB1（64）およびDB2（64）は、2つのデータブロック内の64ビットのデータ情報を表す。

【0068】

図3（b）に示されたように、制御情報を搬送する2つの64B／66Bデータブロックは、1つの128B／129Bデータブロックにコード変換される。制御情報を搬送する64B／66Bデータブロックは、4ビットのS1（4）を含む。データブロックの1つの中の4ビットのS1（4）が削除されてよく、2ビットの指示情報は2つの64B／66Bデータブロック内に保持され、さらに1ビットが追加される。コード変換された129ビットのデータブロック内の情報の配列規則は、相互作用を実現するために、実際の要件に従って設定されてよい。一例として図3（b）を使用すると、追加の1ビットがデータブロックの先頭に置かれ、2つの64B／66Bデータブロックのそれぞれの2ビットの指示情報、4ビットのS1（4）が削除された64B／66Bデータブロック内の制御情報、および4ビットのS1（4）が削除されていない64B／66Bデータブロック内の制御情報が連続して続く。別の配列が代替として使用されてよいことが理解されよう。

【0069】

図3（c）に示されたように、制御情報を搬送する1つの64B／66Bデータブロックおよびデータ情報を搬送する1つの64B／66Bデータブロックは、1つの128B／129Bデータブロックにコード変換される。制御情報を搬送する64B／66Bデータブロックは、4ビットのS1（4）を含む。データブロック内の4ビットのS1（4）が削除されてよく、2ビットの指示情報は2つの64B／66Bデータブロック内に保持され、さらに1ビットが追加される。コード変換された129ビットのデータブロック内の情報の配列規則は、相互作用を実現するために、実際の要件に従って設定されてよい。一例として図3（c）を使用すると、追加の1ビットがデータブロックの先頭に置かれ、制御情報を搬送する64B／66Bデータブロックおよびデータ情報を搬送する64B／66Bデータブロックのそれぞれの2ビットの指示情報、4ビットのS1（4）が削除された64B／66Bデータブロック内の制御情報、ならびにデータ情報を搬送する64B／66Bデータブロック内のデータ情報が連続して続く。別の配列が代替として使用されてよいことが理解されよう。

【0070】

図3（d）に示されたように、データ情報を搬送する1つの64B／66Bデータブロックおよび制御情報を搬送する1つの64B／66Bデータブロックは、1つの128B／129Bデータブロックにコード変換される。図3（c）とは異なり、追加の1ビットがデータブロックの先頭に置かれ、データ情報を搬送する64B／66Bデータブロックおよび制御情報を搬送する64B／66Bデータブロックのそれぞれの2ビットの指示情報、データ情報を搬送する64B／66Bデータブロック内のデータ情報、ならびに4ビットのS1（4）が削除された64B／66Bデータブロック内の制御情報が連続して続く。別の配列が代替として使用されてよいことが理解されよう。

【0071】

図3（e）に示されたように、データ情報を搬送する2つの64B／65Bデータブロックは、1つの128B／129Bデータブロックにコード変換される。2つの64B／65Bデータブロックの各々の中の1ビットの指示情報が削除されてよく、コード変換されたデータブロック内で搬送される128ビットデータの（2つのタイプ：データ情報および制御情報を含む）データタイプを示すために、1ビットの指示情報が追加される。図3（e）に示されたように、DB1（64）およびDB2（64）は、2つのデータブロック内の64ビットのデータ情報を表す。

【0072】

図3（f）に示されたように、データ情報を搬送する4つの64B／65Bデータブロックは、1つの256B／257Bデータブロックにコード変換される。4つの64B／65Bデータブロックの各々の中の1ビットの指示情報が削除されてよく、コード変換されたデータブロック内で搬送される256ビットデータの（2つのタイプ：データ情報および制御情報を含む）データタイプを示すために、1ビットの指示情報が追加される。図3（f）に示されたように、DB1（64）、DB2（64）、DB3（64）、およびDB4（64）、は、4つのデータブロック内の64ビットのデータ情報を表す。

【0073】

64B／66Bデータブロックを256B／257Bデータブロックにコード変換する場合、4つの64B／66Bデータブロックごとに1つの256B／257Bデータブロックにコード変換される。具体的なコード変換の原理は前述の説明と同様である。有効なデータ情報および制御情報が保持されてよく、指示情報またはS1（4）が削除されてよく、1つまたは複数の追加ビットが追加されてよい。結論として、有効データはコード変換されたデータブロックで失われず、ビットの総数は256である。

【0074】

64B／65Bデータブロックを128B／129Bまたは256B／257Bデータブロックにコード変換する具体的な実装解決策については、64B／66Bデータブロックの前述のコード変換解決策を参照されたい。詳細は本明細書では再び記載されない。

【0075】

帯域幅効率はコード変換を介して効果的に改善することができる。

【0076】

一実施形態では、データブロックはコード変換後にさらにスクランブルされてよく、ステップS202において収集されたデータブロックはスクランブルされたデータブロックである。

【0077】

S202．ソースネットワークデバイスの物理コーディングサブレイヤが、N個のデータブロックを収集し、N個のデータブロックを組み合わせて有効データを生成する。

【0078】

ソースネットワークデバイスによって収集されたN個のデータブロックは、256B／257Bデータブロック（すなわち、ラインコードが256B／257Bである）、または128B／129Bデータブロック（すなわち、ラインコードが128B／129Bである）、または64B／66Bデータブロック（すなわち、ラインコードが64B／66Bである）、または64B／65Bデータブロック（すなわち、ラインコードが64B／65Bである）であってよい。収集されたN個のデータブロックの長さは同じである。言い換えれば、N個のデータブロックは、すべて256B／257Bデータブロック、またはすべて128B／129Bデータブロック、またはすべて64B／66Bデータブロック、またはすべて64B／65Bデータブロックである。

【0079】

S203．物理コーディングサブレイヤがペイロードを生成し、ペイロードは有効データを含む。

【0080】

S204．ソースネットワークデバイスの物理コーディングサブレイヤが、チェック部分を生成するためにペイロードに対してFEC符号化を実行する。FECコードワード値およびペイロード値は各FECコードタイプに対応して設定され、Nは整数であり、ペイロード値を収集されたデータブロックの長さで割って得られた商以下である（言い換えれば、Nはデータブロックの長さに対するペイロード値の比以下である）。ペイロードの長さはペイロード値に等しく、チェック部分の長さは、FECコードワード値とペイロード値との間の差に等しい。

【0081】

S205．ソースネットワークデバイスの物理コーディングサブレイヤがコードワード構造を生成し、コードワード構造は、有効データ、チェック部分、および同期ヘッダを含む。

【0082】

FECコードタイプは、低密度パリティチェック（Low Density Parity Check、LDPC）コードまたはリードソロモン（Reed－Solomon code、RS）コードであってよく、LDPC（18493、15677）、RS（2047、1739）、RS（1023、847）、RS（1023、845）、RS（1023、843）、RS（1023、841）、RS（1015、839）、RS（1017、839）、RS（1019、839）などを含むが、それらに限定されない。

【0083】

FECコードワード値およびペイロード値は、各FECコードタイプに対応して設定される。たとえば、粒度が1ビットであるLDPC（18493、15677）の場合、FECコードワード値は18493×1ビットであり、ペイロード値は15677×1ビットである。別の例では、粒度が10ビットであるRS（1023、847）の場合、FECコードワード値は1023×10ビットであり、ペイロード値は847×10ビットである。他のFECコードタイプはそれらに類似し、詳細は本明細書では記載されない。RS（1023、845）、RS（1023、843）、RS（1023、841）、RS（1015、839）、RS（1017、839）、およびRS（1019、839）の粒度はすべて10ビットである。RS（2047、1739）の粒度は11ビットであり、FECコードワード値は2047×11＝22517ビットであり、ペイロード値は1739×11＝19129ビットであることを示す。

【0084】

別の表現方式が代替としてFECコードタイプに使用されてよく、たとえば、FECコードワード値およびペイロード値は間接的に示されてよいことが理解されよう。

【0085】

FECコードワード値は、ペイロード値およびチェック長値の合計に等しい。具体的には、その数がチェック長値であるチェックビットは、その数がペイロード値である有効ビットに対してFEC符号化が実行された後に生成され、有効ビットの長さおよびチェックビットの長さの合計はFECコードワード値に等しい。たとえば、LDPC（18493、15677）は、15677ビットのデータに対してFEC符号化が実行された後に2816ビットのチェックデータが生成され、FEC符号化されたデータの全長が18493ビットであることを示す。別の例では、RS（1023、847）は、8470ビットのデータに対してFEC符号化が実行された後に1760ビットのチェックデータが生成され、FEC符号化されたデータの全長が10230ビットであることを示す。

【0086】

有効データの長さは、使用されたFECコードタイプのペイロード値以下である。有効データの長さはNを調整することによって調整されてよい。Nは整数であり、ペイロード値を収集されたデータブロックの長さで割って得られた商に等しくてよい。Nはまた、ペイロード値を収集されたデータブロックの長さで割って得られた商より小さくてもよい。Nは1に等しくてよい。この場合、ペイロードは1つのデータブロックを含む。Nは2以上であってもよい。

【0087】

一実装形態では、有効データの長さは使用されたFECコードタイプのペイロード値に等しい。この場合、ペイロードは有効データから構成される。言い換えれば、ペイロード値を収集されたデータブロックの長さで割って得られた商が、整数、すなわち、整数Nである。この場合、有効データはペイロードと呼ばれてもよい。一例としてLDPC（18493、15677）が使用される。収集されたデータブロックが256B／257Bデータブロックである場合、156777／257＝61、すなわち、Nは61であり、61個の256B／257Bデータブロックによって構成される有効データの長さは15677である。この方式では、すべてのペイロードは有効データであり、したがって、符号化効率および帯域幅効率は高い。

【0088】

別の実装形態では、有効データの長さは使用されたFECコードタイプのペイロード値より小さい。コードワード構造はパディング部分をさらに含む。この場合、ペイロードは有効データおよびパディング部分から構成され、有効データの長さおよびパディング部分の長さの合計はペイロード値に等しい。ペイロードの長さは、使用されたFECコードタイプのペイロード値に等しい。言い換えれば、パディング部分の長さは、ペイロード値と有効データの長さとの間の差に等しくてよい。パディング部分の長さは、代替として、ペイロード値を収集されたデータブロックの長さで割って得られた余りに等しくてよい。一例としてLDPC（18493、15677）が使用される。収集されたデータブロックが128B／129Bデータブロックである場合、15677を129で割って得られた商は121であり、余りは68であり、すなわち、Nは121である。121個の128B／129Bデータブロックによって構成される有効データの長さは15609であり、さらに68ビットがパディング部分としてパディングされる必要があり、その結果、有効データの長さおよびパディング部分の長さの合計はペイロード値15677に等しい。ステップS203は具体的には以下の通りである：ソースネットワークデバイスの物理コーディングサブレイヤが、チェック部分を生成するためにペイロードに対してFEC符号化を実行する。ソースネットワークデバイスは、チェック部分を生成するために、全体として有効データおよびパディング部分から構成される15677ビットのフィールドに対してFEC符号化を実行することができる。このようにして、パディングフィールドが追加され、様々なFECコードタイプとラインコードとの間で効果的な互換性および適応性を実現することができる。

【0089】

この実施形態では、チェック部分および有効データは、各々同期ヘッダを含まない。言い換えれば、同期ヘッダはチェック部分または有効データに含まれない。この実施形態では、有効データ、チェック部分、および同期ヘッダは、コードワード構造内で独立して分散される。

【0090】

同期ヘッダは、高速同期をさらに実現するために、コードワード構造の先頭または末尾に配置することができる。

【0091】

同期ヘッダは、代替として、有効データとチェック部分との間に配置されてよい。

【0092】

入力レートおよび出力レートが変更されないままであることを保証にするために、同期ヘッダの長さは以下の方式で計算されてよい：同期ヘッダの長さがSであり、入力データブロックの長さがXであり、FECコードワード値をXで割って得られた余りがYである場合、S＝tX－Yであり、ここで、tは整数であり、Y≠0であるときt≧1であり、またはY＝0であるときt≧0である。

【0093】

例1
FECコードタイプはLDPC（18493、15677）であり、入力データブロックは64B／66Bデータブロックであり、64B／66Bデータブロックは256B／257Bデータブロックにコード変換され、収集されたデータブロックは256B／257Bデータブロックである。

【0094】

図4（1）に示されたように、15677／257＝61である。したがって、コードワード構造にはパディング部分が必要でない。Nは61であり、有効データは61個の256B／257Bデータブロックによって構成される。有効データの長さは15677ビットである、すなわち、ペイロードの長さは15677ビットであり、それはFEC要件を満たすことができる。チェック部分の長さは2816ビットである。

【0095】

61個の256B／257Bデータブロックは、61×4＝244個の64B／66Bデータブロックをコード変換することによって生成されてよい。

【0096】

18493／66＝280．197であるため、入力レートおよび出力レートが変更されないままであることを保証するために、特定の数の66ビットのプレースホルダブロック（すなわち、各プレースホルダブロックのサイズは66ビットである）は、プレースホルダブロックの数および入力データブロックの数の合計が少なくとも281であるようにさらに生成される必要がある。図4（1）に示されたように、この実施形態では、一例として281（すなわち、t＝1）の数が使用される。したがって、281－244＝37個のプレースホルダブロックが必要である。この場合、符号化効率を最大化することができ、帯域幅効率を改善することができる。

【0097】

281×66＝18546であり、18546－18493＝53である。したがって、同期ヘッダの長さは53ビットである。

【0098】

同様に、プレースホルダブロックの数が38、すなわち、t＝2であるとき、同期ヘッダの長さは119ビットである。残りは類似によって推論されてよい。

【0099】

例2
FECコードタイプはLDPC（18493、15677）であり、入力データブロックは64B／66Bデータブロックであり、64B／66Bデータブロックは128B／129Bデータブロックにコード変換され、収集されたデータブロックは128B／129Bデータブロックである。

【0100】

図4（2）に示されたように、15677を129で割って得られた商は121であり、余りは68である。したがって、コードワード構造にはパディング部分が必要であり、パディング部分の長さは68ビットである。Nは121であり、有効データは121個の128B／129Bデータブロックによって構成される。有効データの長さは15609ビットである。有効データの長さおよびパディング部分の長さの合計は15677ビットである、すなわち、ペイロードの長さは15677ビットであり、それはFEC要件を満たすことができる。チェック部分の長さは2816ビットである。

【0101】

121個の128B／129Bデータブロックは、121×2＝242個の64B／66Bデータブロックをコード変換することによって生成されてよい。

【0102】

18493／66＝280．197であるため、入力レートおよび出力レートが変更されないままであることを保証するために、特定の数の66ビットのプレースホルダブロック（すなわち、各プレースホルダブロックのサイズは66ビットである）は、プレースホルダブロックの数および入力データブロックの数の合計が少なくとも281であるようにさらに生成される必要がある。図4（2）に示されたように、この実施形態では、一例として281（すなわち、t＝1）の数が使用される。したがって、281－242＝39個のプレースホルダブロックが必要である。

【0103】

281×66＝18546であり、18546－18493＝53である。したがって、同期ヘッダの長さは53ビットである。

【0104】

同様に、プレースホルダブロックの数が40、すなわち、t＝2であるとき、同期ヘッダの長さは119ビットである。残りは類似によって推論されてよい。

【0105】

例3
FECコードタイプはLDPC（18493、15677）であり、収集されたデータブロックは64B／66Bデータブロックである。計算プロセスは前述の例と同じであり、詳細は本明細書では再び記載されない。図4（3）に示されたように、有効データは237個の64B／66Bデータブロックによって構成され、有効データの長さは15642ビットであり、パディング部分の長さは35ビットであり、チェック部分の長さは2816ビットであり、t＝1であるとき、同期ヘッダの長さは53ビットである。

【0106】

例4
FECコードタイプはRS（1023、847）であり、入力データブロックは64B／66Bデータブロックであり、64B／66Bデータブロックは128B／129Bデータブロックにコード変換され、収集されたデータブロックは128B／129Bデータブロックである。FECコードワード値は10230であり、ペイロード値は8470である。

【0107】

図4（4）に示されたように、8470を129で割って得られた商は65であり、余りは85である。したがって、コードワード構造にはパディング部分が必要であり、パディング部分の長さは85ビットである。Nは65であり、有効データは65個の128B／129Bデータブロックによって構成される。有効データの長さは8385ビットである。有効データの長さおよびパディング部分の長さの合計は8470ビットである、すなわち、ペイロードの長さは8470ビットであり、それはFEC要件を満たすことができる。チェック部分の長さは1760ビットである。

【0108】

65個の128B／129Bデータブロックは、65×2＝130個の64B／66Bデータブロックをコード変換することによって生成されてよい。

【0109】

10230／66＝155であり、余りは0である、すなわち、Y＝0であるため、入力レートおよび出力レートが変更されないままであることを保証するために、特定の数の66ビットのプレースホルダブロック（すなわち、各プレースホルダブロックのサイズは66ビットである）は、プレースホルダブロックの数および入力データブロックの数の合計が少なくとも155であるようにさらに生成される必要がある。一例として、155の数が使用される（すなわち、t＝0である）。したがって、155－130＝25個のプレースホルダブロックが必要である。この場合、同期ヘッダとして余分なビットは使用されないが、パディング部分が同期ヘッダとして直接使用されてよい。パディング部分全体が同期ヘッダとして使用されてよく、たとえば、85ビットすべてが同期に使用される。あるいは、パディング部分の一部が同期ヘッダとして使用されてよい。たとえば、パディング部分内の50ビットが同期に使用される。追加のビットは必要でないが、代わりにパディング部分が同期ヘッダとして直接使用される。これにより、無効データのビットが効果的に削減され、帯域幅効率および符号化効率が改善される。

【0110】

プレースホルダブロックの数は、代替として26である、すなわち、t＝1であってよいことが理解されよう。この場合、同期ヘッダの長さは66ビットである。残りは類似によって推論されてよい。

【0111】

例5
FECコードタイプはRS（1023、847）であり、入力データブロックは64B／66Bデータブロックであり、64B／66Bデータブロックは256B／257Bデータブロックにコード変換され、収集されたデータブロックは256B／257Bデータブロックである。FECコードワード値は10230であり、ペイロード値は8470である。

【0112】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（5）を参照されたい。有効データの長さは8224ビットであり、パディング部分の長さは246ビットである。

【0113】

例6
FECコードタイプはRS（1023、847）であり、収集されたデータブロックは64B／66Bデータブロックである。FECコードワード値は10230であり、ペイロード値は8470である。具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（6）を参照されたい。有効データの長さは8448ビットであり、パディング部分の長さは22ビットである。

【0114】

例7
FECコードタイプはRS（2047、1739）であり、入力データブロックは64B／66Bデータブロックであり、64B／66Bデータブロックは256B／257Bデータブロックにコード変換され、収集されたデータブロックは256B／257Bデータブロックである。FECコードワード値は22517であり、ペイロード値は19129である。

【0115】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（7）を参照されたい。有効データの長さは19018ビットであり、パディング部分の長さは111ビットであり、同期ヘッダの長さは55ビットであり、チェック部分の長さは3388ビットである。

【0116】

例8
FECコードタイプはRS（2047、1739）であり、入力データブロックは64B／66Bデータブロックであり、64B／66Bデータブロックは128B／129Bデータブロックにコード変換され、収集されたデータブロックは128B／129Bデータブロックである。FECコードワード値は22517であり、ペイロード値は19129である。

【0117】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（8）を参照されたい。有効データの長さは19092ビットであり、パディング部分の長さは37ビットであり、同期ヘッダの長さは55ビットであり、チェック部分の長さは3388ビットである。

【0118】

例9
FECコードタイプはRS（2047、1739）であり、入力データブロックは64B／66Bデータブロックであり、収集されたデータブロックは64B／66Bデータブロックである。FECコードワード値は22517であり、ペイロード値は19129である。

【0119】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（9）を参照されたい。有効データの長さは19074ビットであり、パディング部分の長さは55ビットであり、同期ヘッダの長さは55ビットであり、チェック部分の長さは3388ビットである。

【0120】

例10
FECコードタイプはLDPC（18493、15677）であり、入力データブロックは64B／65Bデータブロックであり、64B／65Bデータブロックは256B／257Bデータブロックにコード変換され、収集されたデータブロックは256B／257Bデータブロックである。FECコードワード値は18493であり、ペイロード値は15677である。

【0121】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（10）を参照されたい。有効データの長さは15677ビットであり、パディング部分はなく、同期ヘッダの長さは32ビットであり、チェック部分の長さは2816ビットである。

【0122】

例11
FECコードタイプはLDPC（18493、15677）であり、入力データブロックは64B／65Bデータブロックであり、64B／65Bデータブロックは128B／129Bデータブロックにコード変換され、収集されたデータブロックは128B／129Bデータブロックである。FECコードワード値は18493であり、ペイロード値は15677である。

【0123】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（11）を参照されたい。有効データの長さは15609ビットであり、パディング部分の長さは68ビットであり、同期ヘッダの長さは32ビットであり、チェック部分の長さは2816ビットである。

【0124】

例12
FECコードタイプはLDPC（18493、15677）であり、入力データブロックは64B／65Bデータブロックであり、収集されたデータブロックは64B／65Bデータブロックである。FECコードワード値は18493であり、ペイロード値は15677である。

【0125】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（12）を参照されたい。有効データの長さは15665ビットであり、パディング部分の長さは12ビットであり、同期ヘッダの長さは32ビットであり、チェック部分の長さは2816ビットである。

【0126】

例13
FECコードタイプはRS（1023、847）であり、入力データブロックは64B／65Bデータブロックであり、64B／65Bデータブロックは256B／257Bデータブロックにコード変換され、収集されたデータブロックは256B／257Bデータブロックである。FECコードワード値は10230であり、ペイロード値は8470である。

【0127】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（13）を参照されたい。有効データの長さは8224ビットであり、パディング部分の長さは246ビットであり、同期ヘッダの長さは40ビットであり、チェック部分の長さは1760ビットである。

【0128】

例14
FECコードタイプはRS（1023、847）であり、入力データブロックは64B／65Bデータブロックであり、64B／65Bデータブロックは128B／129Bデータブロックにコード変換され、収集されたデータブロックは128B／129Bデータブロックである。FECコードワード値は10230であり、ペイロード値は8470である。

【0129】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（14）を参照されたい。有効データの長さは8385ビットであり、パディング部分の長さは85ビットであり、同期ヘッダの長さは40ビットであり、チェック部分の長さは1760ビットである。

【0130】

例15
FECコードタイプはRS（1023、847）であり、入力データブロックは64B／65Bデータブロックであり、収集されたデータブロックは64B／65Bデータブロックである。FECコードワード値は10230であり、ペイロード値は8470である。

【0131】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（15）を参照されたい。有効データの長さは8450ビットであり、パディング部分の長さは20ビットであり、同期ヘッダの長さは40ビットであり、チェック部分の長さは1760ビットである。

【0132】

例16
FECコードタイプはRS（2047、1739）であり、入力データブロックは64B／65Bデータブロックであり、64B／65Bデータブロックは256B／257Bデータブロックにコード変換され、収集されたデータブロックは256B／257Bデータブロックである。FECコードワード値は22517であり、ペイロード値は19129である。

【0133】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（16）を参照されたい。有効データの長さは19018ビットであり、パディング部分の長さは111ビットであり、同期ヘッダの長さは38ビットであり、チェック部分の長さは3388ビットである。

【0134】

例17
FECコードタイプはRS（2047、1739）であり、入力データブロックは64B／65Bデータブロックであり、64B／65Bデータブロックは128B／129Bデータブロックにコード変換され、収集されたデータブロックは128B／129Bデータブロックである。FECコードワード値は22517であり、ペイロード値は19129である。

【0135】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（17）を参照されたい。有効データの長さは19092ビットであり、パディング部分の長さは37ビットであり、同期ヘッダの長さは38ビットであり、チェック部分の長さは3388ビットである。

【0136】

例18
FECコードタイプはRS（2047、1739）であり、入力データブロックは64B／65Bデータブロックであり、収集されたデータブロックは64B／65Bデータブロックである。FECコードワード値は22517であり、ペイロード値は19129である。

【0137】

具体的な計算プロセスは上述されたものと同じであり、詳細は本明細書では再び記載されない。具体的な原理については、図4（18）を参照されたい。有効データの長さは19110ビットであり、パディング部分の長さは19ビットであり、同期ヘッダの長さは38ビットであり、チェック部分の長さは3388ビットである。

【0138】

RS（1023、845）、RS（1023、843）、RS（1023、841）、RS（1015、839）、RS（1017、839）、およびRS（1019、839）などの他のFECコードタイプの場合、原理は上述された原理と同じであり、詳細は記載されない。

【0139】

別のFECコードタイプが使用されてよいことが理解されよう。たとえば、RS方式のFECコードワード値は、10230、20470、10150、10170、10190などに限定されず、代替として、10210または別の値であってよい。RS方式のペイロード値は、8390、8310、8330、8350、17390などに限定されず、代替として、8370、17310、または別の値であってよい。加えて、前述の計算原理を満たすことができれば、前述のFECコードワード値およびペイロード値は、RS方式を形成するために自由に組み合わされてよい。

【0140】

一実施形態では、同期ヘッダとして余分なビットが使用されるとき（たとえば、FECコードワード値を入力情報ブロックの長さで割って得られた余りが0でないとき）、パディング部分は依然として同時に同期ヘッダとして使用されてよい。具体的には、パディング部分全体が同期ヘッダとして使用されてもよく、パディング部分の一部が同期ヘッダとして使用されてもよい。たとえば、同期ヘッダの長さが比較的短く、同期要件を満たすことができないとき、パディング部分は同時に同期ヘッダとして使用されてよい。この場合、パディング部分全体が同期ヘッダとして使用されてもよく、パディング部分の一部が同期ヘッダとして使用されてもよい。

【0141】

一実施形態では、パディング部分はさらに、コードワード構造の長さ、有効データの長さ、有効データの長さおよびチェック部分の長さの合計、ペイロードの長さ、またはペイロードの長さおよびチェック部分の長さの合計を示すために使用される。パディング部分のいくつかまたはすべてのビットが指示に使用されてよい。

【0142】

別の実施形態では、コードワード構造は指示部分をさらに含む。指示部分は、コードワード構造の長さ、有効データの長さ、有効データの長さおよびチェック部分の長さの合計、ペイロードの長さ、またはペイロードの長さおよびチェック部分の長さの合計を示すために使用される。同期ヘッダ内のいくつかのビットが指示に使用されてよい。

【0143】

たとえば、アップストリーム方向では、バーストテールトランケーションが発生する場合があり、有効データの長さがFEC符号化のペイロード値より小さいか、または有効データの長さおよびパディング部分の長さの合計がFEC符号化のペイロード値より小さいことをもたらす。たとえば、LDPC（18493、15677）が使用されるとき、アップストリームで送信された最後のコードワード構造内の有効データの長さは15677より小さくてよく、またはアップストリームで送信された最後のコードワード構造内の有効データの長さおよびパディング部分の長さの合計は15677より小さくてよい。したがって、パディング部分または指示部分により、ターゲットネットワークデバイスが正しい構文解析を実施するためにコードワード構造の長さを知ることが可能になる。

【0144】

S206．ターゲットネットワークデバイスの物理コーディングサブレイヤがコードワード構造を受信する。

【0145】

S207．ターゲットネットワークデバイスの物理コーディングサブレイヤが、同期ヘッダに基づいて、受信されたコードワード構造を同期させる。

【0146】

たとえば、ターゲットネットワークデバイスは、同期シーケンスを事前に記憶し、コードワード構造内の同期ヘッダが事前に記憶された同期シーケンスと一致し、次いで同期が完了するまで、受信されたコードワード構造内の事前に記憶された同期シーケンスをトラバースすることができる。

【0147】

S208．ターゲットネットワークデバイスの物理コーディングサブレイヤがペイロードおよびチェック部分を抽出する。

【0148】

S209．ターゲットネットワークデバイスの物理コーディングサブレイヤが、抽出されたチェック部分を使用することにより、ペイロードに対して順方向誤り訂正復号を実行する。

【0149】

本明細書のFEC復号は前述のFEC符号化に対応し、同じ方式を使用してFECコードタイプを表すことができることが理解されよう。たとえば、FEC復号方式は、LDPC（18493、15677）、RS（1023、847）、RS（1023、845）、RS（1023、843）、RS（1023、841）、RS（2047、1739）、RS（1015、839）、RS（1017、839）、またはRS（1019、839）である。一例としてLDPC（18493、15677）が使用される。ターゲットネットワークデバイスは、2816ビットのチェックデータフィールドを使用することにより、15677ビットの有効データに対して順方向誤り訂正復号を実行する。

【0150】

コードワード構造がパディング部分を含む場合、S210は、具体的に、ターゲットネットワークデバイスが、チェック部分を使用することにより、有効データおよびパディング部分に対して順方向誤り訂正復号を実行することであることが理解されよう。

【0151】

具体的な詳細については、順方向誤り訂正符号化の前述の説明を参照されたい。詳細は本明細書では再び記載されない。

【0152】

本発明のこの実施形態におけるデータ符号化および復号方法によれば、生成されたコードワード構造は、有効データ、チェック部分、および同期ヘッダを含み、有効データ、チェック部分、および同期ヘッダは、コードワード構造内で独立して分散され、その結果、高速同期を実現することができ、帯域幅効率および誤り訂正機能が改善される。

【0153】

本発明はプリコーディング指示方法をさらに提供する。本発明のこの実施形態におけるソースネットワークデバイスおよびターゲットネットワークデバイスの具体的な詳細については、前述の実施形態を参照されたい。詳細は本明細書では再び記載されない。ソースネットワークデバイスはターゲットネットワークデバイスにコードワード構造を送信する。ソースネットワークデバイスは、コードワード構造をプリコーディングしてもしなくてもよく、指示情報を使用することにより、コードワード構造がプリコーディングされているかどうかを示すことができる。ターゲットネットワークデバイスは、指示情報に基づいて、コードワード構造がプリコーディングされているかどうかを判定し、コードワード構造をデプリコーディングするべきかどうかをさらに判定することができる。この実施形態における同期ヘッダの具体的な詳細については、前述のデータ符号化および復号方法の実施形態を参照されたい。詳細は本明細書では再び記載されない。

【0154】

図5に示されたように、プリコーディング指示方法は以下のステップを含む：

【0155】

S301．ソースネットワークデバイスの物理コーディングサブレイヤが、コードワード構造がプリコーディングされているかどうかを示す指示情報を同期ヘッダに追加する。

【0156】

たとえば、同期ヘッダ内の事前設定された位置にあるビットは、指示情報として使用されてよい。具体的な位置は、ソースネットワークデバイスおよびターゲットネットワークデバイスによって合意されてよい。たとえば、同期ヘッダ内の最後のビットが「0」である場合、それはコードワード構造がプリコーディングされていることを示し、同期ヘッダ内の最後のビットが「1」である場合、それはコードワード構造がプリコーディングされていないことを示す。

【0157】

具体的には、プリコーディングは排他的論理和方式で実行されてよい。

【0158】

一実施形態では、元のコードワード構造内の事前設定された初期ビットおよび最初のビットに対して排他的論理和演算が実行されてよく、得られたビットは出力コードワード構造内の最初のビットとして使用される。元のコードワード構造内の2番目のビットおよび出力コードワード構造内の最初のビットに対して排他的論理和演算が実行され、得られたビットは出力コードワード構造内の2番目のビットとして使用される。元のコードワード構造内の3番目のビットおよび出力コードワード構造内の2番目のビットに対して排他的論理和演算が実行され、得られたビットは出力コードワード構造内の3番目のビットとして使用され、元のコードワード構造内の最後のビットおよび出力コードワード構造内の最後から2番目のビットに対して排他的論理和演算が実行され、得られたビットが出力コードワード構造の最後のビットとして使用されるまで、以下同様である。

【0159】

事前設定された初期ビットは「0」または「1」であってよい。

【0160】

たとえば、元のコードワード構造内の元のシーケンスが「0110101110」であると仮定する。事前設定された初期ビットが「0」であるとき、出力シーケンスは「0100110100」であり、または事前設定された初期ビットが「1」であるとき、出力シーケンスは「1011001011」である。

【0161】

別の実施形態では、代替として、事前設定された初期ビットおよび元のコードワード構造内の各ビットに対して排他的論理和演算が実行されてよい。具体的には、出力コードワード構造内の最初のビットを取得するために、元のコードワード構造内の初期ビットおよび最初のビットに対して排他的論理和演算が実行され、出力コードワード構造内の2番目のビットを取得するために、元のコードワード構造内の初期ビットおよび2番目のビットに対して排他的論理和演算が実行され、以下同様である。

【0162】

S302．ソースネットワークデバイスの物理コーディングサブレイヤがコードワード構造を生成し、コードワード構造は、ペイロード、チェックデータ、および同期ヘッダを含む。コードワード構造の具体的な詳細については、前述の実施形態を参照されたい。詳細は本明細書では再び記載されない。コードワード構造と前述の実施形態のコードワード構造との間の違いは、コードワード構造がプリコーディングされているかどうかを示す指示情報が同期ヘッダに追加されることである。

【0163】

S303．ソースネットワークデバイスの物理コーディングサブレイヤがコードワード構造を送信する。

【0164】

物理コーディングサブレイヤは、次の処理のために、ソースネットワークデバイスの物理媒体接続（Physical Medium Attachment、PMA）サブレイヤにコードワード構造を送信することができる。

【0165】

S304．ターゲットネットワークデバイスの物理コーディングサブレイヤがコードワード構造を受信する。ターゲットネットワークデバイスの物理コーディングサブレイヤは、ターゲットネットワークデバイスのPMAサブレイヤによって送信されたコードワード構造を受信することができる。

【0166】

S305．ターゲットネットワークデバイスの物理コーディングサブレイヤが、同期ヘッダに基づいて、受信されたコードワード構造を同期させる。

【0167】

一実施形態では、ソースネットワークデバイスおよびターゲットネットワークデバイスは、プリコーディングを実行するべきかどうかについて事前に合意することができるか、またはプリコーディング用の初期ビットを事前に合意することができる。このようにして、コードワード構造を受信した後、ターゲットネットワークデバイスは、以前の合意に基づいて、デプリコーディングを実行するべきかどうかを判定し、デプリコーディングに使用される初期ビットを決定することができる。具体的には、ソースネットワークデバイスおよびターゲットネットワークデバイスが、プリコーディングが実行されないことに事前に同意すると、ターゲットネットワークデバイスは、事前に記憶された同期シーケンスに基づいてコードワード構造を直接同期させることができる。ソースネットワークデバイスおよびターゲットネットワークデバイスが、プリコーディングが実行されることに事前に同意すると、ターゲットネットワークデバイスは、最初にコードワード構造に対してデプリコーディングを実行し、次いで、事前に記憶された同期シーケンスに基づいてコードワード構造を同期させることができる。あるいは、同期はデプリコーディングの前に実行されてよい。

【0168】

別の実施形態では、ソースネットワークデバイスおよびターゲットネットワークデバイスは、プリコーディングを実行するべきかどうかについて事前に合意しなくてよい。ターゲットネットワークデバイスは、ブラインド検出を介して、受信されたコードワード構造がプリコーディングされているかどうかを判定することができる。

【0169】

具体的には、ターゲットネットワークデバイスは、第1の同期シーケンスおよび第2の同期シーケンスを事前に記憶することができる。第1の同期シーケンスは、プリコーディング前のコードワード構造用の元の同期シーケンスであってよく、第2の同期シーケンスは、プリコーディング後のコードワード構造用の出力同期シーケンスであってよい。2つのタイプの第2の同期シーケンス：元のビット「0」を使用してプリコーディングが実行された後に出力される同期シーケンス、および元のビット「1」を使用してプリコーディングが実行された後に出力される同期シーケンスが存在してよいことが理解されよう。

【0170】

同期ヘッダが第1の同期シーケンスと一致する場合、コードワード構造がプリコーディングされていないと判断される。この場合、ターゲットネットワークデバイスは、コードワード構造から有効データおよびチェック部分を直接抽出する。

【0171】

同期ヘッダが第2の同期シーケンスと一致する場合、コードワード構造がプリコーディングされていると判断される。ターゲットネットワークデバイスはコードワード構造をデプリコーディングし、ターゲットネットワークデバイスは、デプリコーディングされたコードワード構造から有効データおよびチェック部分を抽出する。

【0172】

S306．ターゲットネットワークデバイスの物理コーディングサブレイヤが、同期ヘッダ内の指示情報に基づいて、コードワード構造がプリコーディングされているかどうかを判定する。

【0173】

この実施形態では、コードワード構造がプリコーディングされているかどうかを示す指示情報が同期ヘッダに追加され、その結果、ターゲットネットワークデバイスは、その情報に基づいて、以前のブラインド検出結果が正しいかどうかをさらに判定して、ダブルチェックを行うことができる。

【0174】

本発明はプリコーディング指示方法をさらに提供する。本発明のこの実施形態におけるソースネットワークデバイスおよびターゲットネットワークデバイスの具体的な詳細については、前述の実施形態を参照されたい。詳細は本明細書では再び記載されない。ソースネットワークデバイスはターゲットネットワークデバイスにデータフレームを送信する。ソースネットワークデバイスは、データフレームをプリコーディングしてもしなくてもよく、指示情報を使用することにより、データフレームがプリコーディングされているかどうかを示すことができる。ターゲットネットワークデバイスは、指示情報に基づいて、データフレームがプリコーディングされているかどうかを判定し、データフレームをデプリコーディングするべきかどうかをさらに判定することができる。方法は、MAC制御サブレイヤによって実行されてもよく、プロセッサによって実行されてもよい。図6に示されたように、方法は以下のステップを含む。

【0175】

S401．ソースネットワークデバイスがデータフレームを生成し、データフレームは、ソースネットワークデバイスがプリコーディング機能を有するかどうかを示すために使用されるか、またはターゲットネットワークデバイスがプリコーディングもしくはデプリコーディングを実行する必要があるかどうかを示すために使用されるか、またはプリコーディングイネーブルビットを有効もしくは無効にするようにターゲットネットワークデバイスに示すために使用される指示情報を含む。

【0176】

S402．ソースネットワークデバイスがターゲットネットワークデバイスにデータフレームを送信する。

【0177】

S403．ターゲットネットワークデバイスがソースネットワークデバイスによって送信されたデータフレームを受信する。

【0178】

S404．ターゲットネットワークデバイスが、指示情報に基づいて、データフレームをデプリコーディングするべきかどうかを判定し、またはソースネットワークデバイスとの間で送信されたデータフレームをプリコーディングおよびデプリコーディングするべきかどうかを判定する。

【0179】

ターゲットネットワークデバイスもデータフレームを同期させる必要があることが理解されよう。具体的な同期方法の詳細については、前述の実施形態を参照されたい。詳細は本明細書では再び記載されない。

【0180】

一実施形態では、ソースネットワークデバイスはONUであり、ターゲットネットワークデバイスはOLTである。データフレームは登録要求メッセージ（REGISTER＿REQ）を搬送し、登録要求メッセージには、ONUがプリコーディング機能を有するかどうかを示すために使用される指示情報を含む。言い換えれば、ONUは、ONUがプリコーディング機能を有するかどうかをOLTに報告する。OLTは、指示情報に基づいて、ONUに送信されるべきデータをプリコーディングするべきかどうかを判定することができる。ソースネットワークデバイスによって送信されたデータフレームがデプリコーディングされる必要があるかどうか、およびソースネットワークデバイスに送信されるべきデータフレームがプリコーディングされる必要があるかどうかをターゲットネットワークデバイスに通知するために、ソースネットワークデバイスがプリコーディング機能を有するかどうかを示す指示情報がデータフレームに追加される。

【0181】

別の実施形態では、ソースネットワークデバイスはOLTであり、ターゲットネットワークデバイスはONUである。データフレームは発見ゲート（Discovery Gate）メッセージを搬送し、発見ゲートメッセージは、ONUがプリコーディングまたはデプリコーディングを実行する必要があるかどうかを示すために使用される指示情報を含む。具体的には、OLTは、ダウンストリーム内でONUに送信されたメッセージがプリコーディングされているかどうかを示す、すなわち、ONUがダウンストリーム内で受信されたデータをデプリコーディングする必要があるかどうかを示すことができ、さらに、アップストリーム内でONUによってOLTに送信されるべきアップストリームデータがプリコーディングされる必要があるかどうかを示すことができる。データフレームは、アップストリーム指示部分およびダウンストリーム指示部分を含んでよい。アップストリーム指示部分は、アップストリーム送信中にプリコーディングが実行されるかどうかを示すために使用され、ダウンストリーム指示部分は、ダウンストリーム送信中にプリコーディングが実行されるかどうかを示すために使用される。アップストリーム指示部分およびダウンストリーム指示部分は、事前設定された位置に配置されてよく、OLTおよびONUによって事前に合意される。あるいは、指示部分がアップストリーム指示部分であるかダウンストリーム指示部分であるかを示すために、アップストリーム識別子およびダウンストリーム識別子が追加されてよい。この実施形態では、データフレームがプリコーディングされているかどうかを示す指示情報がデータフレームに追加され、その結果、ターゲットネットワークデバイスは、その情報に基づいて、以前のブラインド検出結果が正しいかどうかをさらに判定して、ダブルチェックを行うことができる。加えて、アップストリームまたはダウンストリーム内でプリコーディングが必要であるかどうかが示され、その結果、ソースネットワークデバイスおよびターゲットネットワークデバイスは、その指示に基づいてプリコーディングおよびデプリコーディングを実行することができる。これにより、エラーが回避され、効率が改善される。

【0182】

別の実施形態では、ソースネットワークデバイスはOLTであり、ターゲットネットワークデバイスはONUである。データフレームは登録（Register）メッセージを搬送し、メッセージは、プリコーディングイネーブルビットを有効または無効にするようにONUに示すために使用される指示情報を含む。指示情報を受信した後、ONUはプリコーディングイネーブルビットを有効または無効にする。たとえば、プリコーディングイネーブルビットが有効であるとき、ONUはプリコーディングまたはデプリコーディングを実行する。プリコーディングイネーブルビットが無効であるとき、ONUはプリコーディングまたはデプリコーディングを実行しない。あるいは、プリコーディングイネーブルビットが有効であるとき、ONUはプリコーディングまたはデプリコーディングを実行せず、プリコーディングイネーブルビットが無効であるとき、ONUはプリコーディングまたはデプリコーディングを実行する。プリコーディングイネーブルビットは、事前設定された位置にあるビットであってよく、たとえば、1ビットもしくは2ビットであってよく、または別の数のビットであってよい。一例として1ビットを使用すると、ビットが「0」であるとき、それはプリコーディングイネーブルビットが無効であることを示し、ビットが「1」であるとき、それはプリコーディングイネーブルビットが有効であることを示す。ONUは、登録応答メッセージ（Register＿ACK）にイネーブル応答指示情報を追加することにより、OLTにイネーブル応答指示情報をフィードバックして、ONUがプリコーディングイネーブルビットを有効にしたかどうかをOLTに通知することができる。

【0183】

本発明はネットワークデバイスをさらに提供する。ネットワークデバイスは、OLT110であってもよく、ONU130であってもよい。

【0184】

図7に示されたように、ネットワークデバイスは、プロセッサ510、メモリ520、媒体アクセス制御（medium access control、MAC）チップ530、トランシーバ540、および波長分割マルチプレクサ550を含む。

【0185】

プロセッサ510は、本発明のこの実施形態において提供された技術的解決策を実施するために、汎用中央処理装置（Central Processing Unit、CPU）、マイクロプロセッサ、特定用途向け集積回路ASIC、または少なくとも1つの集積回路を使用して関連プログラムを実行することができる。

【0186】

メモリ520は、読取り専用メモリ（Read Only Memory、ROM）、静的ストレージデバイス、動的ストレージデバイス、またはランダムアクセスメモリ（Random Access Memory、RAM）であってよい。メモリ520は、オペレーティングシステムおよび別のアプリケーションプログラムを記憶することができる。本発明のこの実施形態において提供された技術的解決策がソフトウェアまたはファームウェアを使用して実施されるとき、本発明のこの実施形態において提供された技術的解決策を実施するためのプログラムコードは、メモリ520に記憶され、プロセッサ510によって実行される。

【0187】

一実施形態では、プロセッサ510はメモリ520を含んでよい。別の実施形態では、プロセッサ510およびメモリ520は、2つの独立した構造である。

【0188】

一実施形態では、プロセッサ510およびMACチップ530は、2つの独立した構造であってよい。別の実施形態では、プロセッサ510はMACチップ530を含んでよい。MACチップ530は、物理コーディングサブレイヤおよびMAC制御サブレイヤを含んでよい。

【0189】

トランシーバ540は、光送信機および／または光受信機を含んでよい。光送信機は光信号を送信するように構成されてよく、光受信機は光信号を受信するように構成されてよい。光送信機は、発光デバイス、たとえば、ガスレーザ、固体レーザ、液体レーザ、半導体レーザ、または直接変調レーザを使用して実装されてよい。光受信機は、光検出器、たとえば、光検出器またはフォトダイオード（たとえば、アバランシェダイオード）を使用して実装されてよい。トランシーバ540は、デジタル－アナログ変換器およびアナログ－デジタル変換器をさらに含んでよい。

【0190】

波長分割マルチプレクサ550はトランシーバ540に接続される。ネットワークデバイスが光信号を送信するとき、波長分割マルチプレクサはマルチプレクサとして機能する。ネットワークデバイスが光信号を受信するとき、波長分割マルチプレクサはデマルチプレクサとして機能する。波長分割マルチプレクサは光カプラと呼ばれる場合もある。

【0191】

前述の実施形態から、ネットワークデバイスが前述のソースネットワークデバイスとして使用されるとき、ソースネットワークデバイスの物理コーディングサブレイヤがステップS200、S201、S202、S203、S204、およびS205を実行するように構成されることを知ることができる。ソースネットワークデバイスの物理コーディングサブレイヤは、ステップS301、S302、およびS303を実行するように構成される。ソースネットワークデバイスのMAC制御サブレイヤまたはプロセッサはステップS401を実行するように構成され、トランシーバはステップS402を実行するように構成される。

【0192】

前述の実施形態から、ネットワークデバイスが前述のターゲットネットワークデバイスとして使用されるとき、ターゲットネットワークデバイスの物理コーディングサブレイヤがステップS206、S207、S208、およびS209を実行するように構成され、ターゲットネットワークデバイスの物理コーディングサブレイヤがステップS304、S305、およびS306を実行するようにさらに構成されることを知ることができる。ターゲットネットワークデバイスのMAC制御サブレイヤまたはプロセッサ510はステップS404を実行するように構成され、トランシーバ540はステップS403を実行するように構成される。

【0193】

プロセッサ510、トランシーバ540、MAC制御サブレイヤ、および物理コーディングサブレイヤによる前述のステップの実行のさらなる詳細については、前述の方法実施形態および添付図面の関連する説明を参照されたい。詳細は本明細書では再び記載されない。

【0194】

本発明のこの実施形態はまた、前述の方法実施形態に記載された様々な有益な効果を有する。詳細は本明細書では再び記載されない。

【0195】

本発明はPONシステムにおけるデータ符号化装置をさらに提供する。装置は、前述の実施形態におけるソースネットワークデバイスに統合されてよく、たとえば、ソースネットワークデバイスのMACチップに統合されてよい。図8に示されたように、装置は、収集モジュール610、順方向誤り訂正符号化モジュール620、および生成モジュール630を含む。

【0196】

前述の実施形態から、収集モジュール610がステップS200およびS202を実行するように構成され、順方向誤り訂正符号化モジュール620がステップS204を実行するように構成され、生成モジュール630がステップS203およびS205を実行するように構成されることを知ることができる。

【0197】

装置は、コード変換モジュール640をさらに含み、コード変換モジュールはステップS201を実行するように構成される。

【0198】

装置内のモジュールによって前述のステップを実行することのさらなる詳細については、前述の方法実施形態および添付図面の関連する説明を参照されたい。詳細は本明細書では再び記載されない。

【0199】

本発明のこの実施形態はまた、前述の方法実施形態に記載された様々な有益な効果を有する。詳細は本明細書では再び記載されない。

【0200】

本発明はPONシステムにおけるデータ復号装置をさらに提供する。装置は、前述の実施形態におけるターゲットネットワークデバイスに統合されてよく、たとえば、ターゲットネットワークデバイスのMACチップに統合されてよい。図9に示されたように、装置は、受信モジュール710、同期モジュール720、抽出モジュール730、および順方向誤り訂正復号モジュール740を含む。

【0201】

前述の実施形態から、受信モジュール710がステップS206を実行するように構成され、同期モジュール720がステップS207を実行するように構成され、抽出モジュール730がステップS208を実行するように構成され、順方向誤り訂正復号モジュール740がステップS209を実行するように構成されることを知ることができる。

【0202】

【0203】

本発明のこの実施形態はまた、前述の方法実施形態に記載された様々な有益な効果を有する。詳細は本明細書では再び記載されない。

【0204】

本発明はPONシステムにおけるプリコーディング指示装置をさらに提供する。装置は、前述の実施形態におけるソースネットワークデバイスに統合されてよく、たとえば、ソースネットワークデバイスのMACチップに統合されてよい。装置は、追加モジュール、生成モジュール、および送信モジュールを含む。

【0205】

前述の実施形態から、追加モジュールがステップS301を実行するように構成され、生成モジュールがステップS302を実行するように構成され、送信モジュールがステップS303を実行するように構成されることを知ることができる。

【0206】

【0207】

本発明のこの実施形態はまた、前述の方法実施形態に記載された様々な有益な効果を有する。詳細は本明細書では再び記載されない。

【0208】

本発明はPONシステムにおけるプリコーディング指示装置をさらに提供する。装置は、前述の実施形態におけるターゲットネットワークデバイスに統合されてよく、たとえば、ターゲットネットワークデバイスのMACチップに統合されてよい。装置は、受信モジュール、同期モジュール、および判定モジュールを含む。

【0209】

前述の実施形態から、受信モジュールがステップS304を実行するように構成され、同期モジュールがステップS305を実行するように構成され、判定モジュールがステップS306を実行するように構成されることを知ることができる。

【0210】

【0211】

本発明のこの実施形態はまた、前述の方法実施形態に記載された様々な有益な効果を有する。詳細は本明細書では再び記載されない。

【0212】

本発明はPONシステムにおけるプリコーディング指示装置をさらに提供する。装置は、前述の実施形態におけるソースネットワークデバイスに統合されてよく、たとえば、ソースネットワークデバイスのMACチップまたはプロセッサに統合されてよい。装置は生成モジュールおよび送信モジュールを含む。

【0213】

前述の実施形態から、生成モジュールがステップS401を実行するように構成され、送信モジュールがステップS402を実行するように構成されることを知ることができる。

【0214】

【0215】

本発明のこの実施形態はまた、前述の方法実施形態に記載された様々な有益な効果を有する。詳細は本明細書では再び記載されない。

【0216】

本発明はPONシステムにおけるプリコーディング指示装置をさらに提供する。装置は、前述の実施形態におけるターゲットネットワークデバイスに統合されてよく、たとえば、ターゲットネットワークデバイスのMACチップまたはプロセッサに統合されてよい。装置は、受信モジュールおよび判定モジュールを含む。

【0217】

前述の実施形態から、受信モジュールがステップS403を実行するように構成され、判定モジュールがステップS404を実行するように構成されることを知ることができる。

【0218】

【0219】

本発明のこの実施形態はまた、前述の方法実施形態に記載された様々な有益な効果を有する。詳細は本明細書では再び記載されない。

【0220】

本発明は光回線終端装置をさらに提供する。光回線終端装置は、前述の実施形態のいずれか1つによるデータ符号化装置を含むか、または光回線終端装置は、前述の実施形態のいずれか1つによるデータ復号装置を含むか、または光回線終端装置は、前述の実施形態のいずれか1つによるプリコーディング指示装置を含む。

【0221】

本発明は光ネットワークユニットをさらに提供する。光ネットワークユニットは、前述の実施形態のいずれか1つによるデータ符号化装置を含むか、または光ネットワークユニットは、前述の実施形態のいずれか1つによるデータ復号装置を含むか、または光ネットワークユニットは、前述の実施形態のいずれか1つによるプリコーディング指示装置を含む。

【0222】

本発明はPONシステムをさらに提供し、システムは、前述の光回線終端装置および前述の光ネットワークユニットを含む。

【0223】

前述の実施形態のすべてまたはいくつかは、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せを使用して実装されてよい。実施形態を実装するためにソフトウェアが使用されるとき、実施形態はコンピュータプログラム製品の形態で完全または部分的に実装されてよい。コンピュータプログラム製品は1つまたは複数のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされ実行されると、本発明の実施形態による手順または機能が、すべてまたは部分的に生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、または別のプログラム可能な装置であってよい。コンピュータ命令は、コンピュータ可読記憶媒体に記憶されてもよく、コンピュータ可読記憶媒体から別のコンピュータ可読記憶媒体に送信されてもよい。たとえば、コンピュータ命令は、ウェブサイト、コンピュータ、サーバ、またはデータセンタから、別のウェブサイト、コンピュータ、サーバ、またはデータセンタに、有線（たとえば、同軸ケーブル、光ファイバ、もしくはデジタル加入者回線（DSL））、またはワイヤレス（たとえば、赤外線、無線、もしくはマイクロ波）で送信されてよい。コンピュータ可読記憶媒体は、コンピュータによってアクセス可能な任意の使用可能媒体、または1つもしくは複数の使用可能媒体を統合するサーバもしくはデータセンタなどの、データストレージデバイスであってよい。使用可能媒体は、磁気媒体（たとえば、フロッピーディスク、ハードディスク、または磁気ディスク）、光学媒体（たとえば、DVD）、半導体媒体（たとえば、ソリッドステートドライブ（solid-state drive、SSD））などであってよい。

【0224】

要約すれば、前述の説明は本発明の実施形態にすぎず、本発明の保護範囲を限定するものではない。本発明の趣旨および原理から逸脱することなく行われるいかなる修正、均等な置換、および改善も、本発明の保護範囲内に入るべきである。

【符号の説明】

【0225】

110 光回線終端装置OLT
120 光配信ネットワークODN
130 光ネットワークユニットONU
510 プロセッサ
520 メモリ
530 MACチップ
540 トランシーバ
550 波長分割マルチプレクサ
610 収集モジュール
620 順方向誤り訂正符号化モジュール
630 生成モジュール
640 コード変換モジュール
710 受信モジュール
720 同期モジュール
730 抽出モジュール
740 順方向誤り訂正復号モジュール

【図1】