JP7627287B2 - サービス処理方法および装置およびデバイス - Google Patents

Description

この出願は、2020年4月27日に中国国家知識産権局に出願された、発明の名称を「サービスマッピング方法およびデバイス」とする中国特許出願第202010344926.8号、および2020年6月15日に中国国家知識産権局に出願された、発明の名称を「サービス処理方法および装置およびデバイス」とする中国特許出願第202010544327.0号の優先権を主張し、これらは、それらの全体が参照によりここに組み込まれる。

この出願の実施形態は、通信技術の分野、特に、サービス処理方法および装置およびデバイスに関する。

高帯域幅、大容量、高信頼性、低遅延、および同様のものを特色として、光転送ネットワーク(optical transport network、OTN)は、転送ネットワークにおいて使用される主流の技術になっている。OTNは、基幹ネットワーク、メトロポリタン・エリア・コア・ネットワーク、アグリゲーション・ネットワーク、および同様のものに適用されてよく、さらに、アクセスネットワークに延びる。n*1.25Gbpsおよびn*5Gbpsなどの高帯域幅の伝送能力を提供することに加えて、OTNは、将来、毎秒数メガビットの低さの伝送能力を有する必要がある。

パケットサービスは、OTNによって搬送される最も重要なサービスタイプである。現在、パケットサービスをOTN伝送フレームにマッピングするために、通常、汎用フレーミング手順フレーマ(generic framing procedure-framer、GFP-F)およびアイドルマッピング手順(idle mapping procedure、IMP)が使用される。しかし、GFP-FおよびIMPのマッピング方式において帯域幅の浪費の課題が存在する。

この出願の実施形態は、帯域幅の浪費の課題を解決するために、サービス処理方法および装置およびデバイスを提供する。

第1の態様によれば、この出願の実施形態は、サービス処理方法を提供する。方法は、サービスデータを取得するステップと、サービスデータを符号化して符号化されたサービスデータを取得するステップであって、符号化されたサービスデータが、制御情報およびサービスデータ情報を含む、ステップと、制御情報を光転送ネットワークOTN伝送フレームのオーバーヘッド領域にマッピングし、制御情報を検査して検査情報を取得し、検査情報をOTN伝送フレームのオーバーヘッド領域にマッピングするステップと、サービスデータ情報をOTN伝送フレームのペイロード領域にマッピングするステップと、符号化されたサービスデータを搬送するOTN伝送フレームを送信するステップとを含む。

この出願のこの実施形態において提供される解決策によれば、サービスデータ情報が、OTN伝送フレームのペイロード領域にマッピングされ、制御情報が、オーバーヘッド領域にマッピングされ、それによって、OTNのペイロード領域のビットレートが、サービスデータの伝送レートに一致し、それにより、帯域幅の利用を改善する。加えて、制御情報に対してビット誤り保護を実行するために、検査後に取得された情報がオーバーヘッド領域にマッピングされ、それによって、ビット誤りが発生するとき、受信端は、適時な方式で誤りを発見することができ、受信端は、誤りのあるデータパケットを正しいデータパケットとして処理することを防止され、それにより、伝送の信頼性を改善する。

可能な設計において、サービスデータは、パケットデータであってよく、パケットデータは、媒体アクセス制御(medium access control、MAC)フレームデータ、インターネットプロトコルIPパケット、マルチプロトコルラベルスイッチング(multi-protocol label switching、MPLS)パケット、フレキシブルイーサネット(Flex Ethernet、FlexE)サービスコードブロックストリーム、または66bコードブロックストリームである。

可能な設計において、サービスデータを符号化することは、サービスデータに対して64b/66b符号化を実行して符号化されたサービスデータを取得するステップを含む。サービスデータが66bコードブロックストリームであるとき、サービスデータに対して64b/66b符号化を実行する必要がないことがある。

可能な設計において、サービスデータを符号化することは、サービスデータに対して64b/66b符号化を実行して66bコードブロックストリームを取得するステップと、66bコードブロックストリームに対して256b/257b符号化処理を実行して257bコードブロックストリームを取得するステップであって、257bコードブロックストリームが、符号化されたサービスデータである、ステップとを含む。サービスデータが66bコードブロックストリームであるとき、サービスデータに対して64b/66b符号化を実行する必要がないことがある。

可能な設計において、サービスデータは、66bコードブロックストリームであり、サービスデータを符号化することは、サービスデータに対して256b/257b符号化処理を実行して符号化されたサービスデータを取得するステップを含む。

たとえば、66bコードブロックストリームに対して256b/257b符号化が実行されるとき、同期ヘッダによって引き起こされる帯域幅の浪費を減らし、帯域幅の利用を改善するために、66bコードブロックの同期ヘッダが除去され、1ビットの制御情報が追加される。

可能な設計において、制御情報は、コードブロックタイプ指示を含む。コードブロックタイプ指示は、257bコードブロックのコードブロックタイプを示すために使用される。

可能な設計において、コードブロックタイプ指示が、257bコードブロックが制御コードブロックであることを示すとき、符号化されたサービスデータは、第1のコードブロックパターン指示をさらに含み、第1のコードブロックパターン指示は、第1のコードブロックパターン指示が位置するコードブロックに含まれる66bコードブロックのパターンを示すために使用される。第1のコードブロックパターン指示は、OTN伝送フレームのペイロード領域にマッピングされることが留意されるべきである。

可能な設計において、符号化されたサービスデータに含まれる第1のコードブロックパターン指示は、第2のコードブロックパターン指示に符号化され、第2のコードブロックパターン指示の異なる値の間の最小ハミング距離は、2である。たとえば、符号化されたサービスデータに含まれる第1のコードブロックパターン指示は、第2のコードブロックパターン指示によって置き換えられる。ここでの第2のコードブロックパターン指示は、第2のコードブロックパターン指示が位置する257bコードブロックに含まれる66bコードブロックのパターンを間接的に示す。たとえば、第2のコードブロックパターン指示および第1のコードブロックパターン指示は、同じ数量のビット、すなわち、4ビットを占有する。

上述の設計において、4ビットがより強い誤り耐性能力を有することを保証するために、第2のコードブロックパターン指示が、最小ハミング距離が2である方式で符号化され、受信端は、4ビットのうちのいずれか1つに発生するビット誤りを適時な方式で発見することができ、それによって、受信端は、誤りのあるデータパケットを正しいデータパケットとして処理することを防止され、それにより、伝送の信頼性を改善する。

可能な設計において、コードブロックタイプ指示が、257bコードブロックが257b制御コードブロックであることを示すとき、方法は、第3のコードブロックパターン指示を符号化されたサービスデータに追加するステップであって、第3のコードブロックパターン指示が、第3のコードブロックパターン指示が位置するコードブロックに含まれる66bコードブロックのパターンを示すために使用され、第3のコードブロックパターン指示の異なる値の間の最小ハミング距離が2である、ステップをさらに含む。上述の設計において、4ビットがより強い誤り耐性能力を有することを保証するために、第3のコードブロックパターン指示が、最小ハミング距離が2である方式で符号化され、受信端は、4ビットのうちのいずれか1つに発生するビット誤りを適時な方式で発見することができ、それによって、受信端は、誤りのあるデータパケットを正しいデータパケットとして処理することを防止され、それにより、伝送の信頼性を改善する。

可能な設計において、OTN伝送フレームは、フレキシブル光サービスユニットOSUflexフレームである。

可能な設計において、OSUflexフレームの長さは、192バイト、240バイト、128バイト、または64バイトである。この出願のこの実施形態において提供されるトランスコーディングの解決策は、複数の長さのOSUflexフレームに適用可能であり、それによって、互換性が改善される。

可能な設計において、検査情報は、巡回冗長検査CRC情報である。

可能な設計において、検査情報は、制御情報の1つ以上のバックアップである。

可能な設計において、サービスデータ情報のビットレートは、OTN伝送フレームのペイロード領域に対応するレートに等しい。

可能な設計において、サービスデータ情報のビットレートは、レート適応を実行するためにアイドルコードブロックが追加または削除された後に取得されるレートであり、レート適応後に取得されたサービスデータ情報のビットレートは、OTN伝送フレームのペイロード領域に対応するレートに等しい。上述の設計において、アイドルコードブロックは、サービスデータ情報のビットレートがOTN伝送フレームのペイロード領域のレートに適応することを可能にするために使用され、それによって、帯域幅の利用が最大化される。

第2の態様によれば、この出願の実施形態は、サービス処理方法を提供する。方法は、光転送ネットワークOTN伝送フレームを受信するステップであって、OTN伝送フレームが、符号化されたサービスデータを搬送するために使用され、符号化されたサービスデータが、制御情報およびサービスデータ情報を含む、ステップと、OTN伝送フレームのオーバーヘッド領域から制御情報および制御情報の検査情報を取得し、検査情報に基づいて制御情報を検査するステップと、検査結果が正しいならば、OTN伝送フレームのペイロード領域からサービスデータ情報を取得し、制御情報およびサービスデータ情報を再組み立てして符号化されたサービスデータを取得するステップと、符号化されたサービスデータを復号してサービスデータを取得するステップとを含む。

第2の態様の有益な効果については、第1の態様の説明を参照されたい。詳細は、ここで再度説明されない。

可能な設計において、サービスデータは、パケットデータであり、パケットデータは、媒体アクセス制御MACフレームデータ、インターネットプロトコルIPパケット、マルチプロトコルラベルスイッチングMPLSパケット、フレキシブルイーサネットFlexEサービスコードブロックストリーム、または66bコードブロックストリームである。

可能な設計において、符号化されたサービスデータを復号することは、符号化されたサービスデータに対して64b/66b復号を実行してサービスデータを取得するステップを含む。

可能な設計において、符号化されたサービスデータを復号することは、符号化されたサービスデータに対して256b/257b復号を実行して66bコードブロックストリームを取得するステップと、66bコードブロックストリームに対して64b/66b復号を実行してサービスデータを取得するステップとを含む。

可能な設計において、サービスデータは、66bコードブロックストリームであり、符号化されたサービスデータを復号することは、具体的には、符号化されたサービスデータに対して256b/257b復号を実行してサービスデータを取得するステップを含む。

可能な設計において、制御情報は、コードブロックタイプ指示を含む。

可能な設計において、コードブロックタイプ指示が、コードブロックタイプ指示が位置する257bコードブロックが制御コードブロックであることを示すとき、符号化されたサービスデータに対して256b/257b復号を実行する前に、方法は、
符号化されたサービスデータに含まれる第2のコードブロックパターン指示を第1のコードブロックパターン指示に復号するステップであって、第1のコードブロックパターン指示が、第1のコードブロックタイプ指示が位置するコードブロックに含まれる66bコードブロックのパターンを示すために使用され、第2のコードブロックパターン指示の異なる値の間の最小ハミング距離が2である、ステップをさらに含む。

可能な設計において、符号化されたサービスデータに対して256b/257b復号を実行することは、符号化されたサービスデータを復号して第3のコードブロックパターン指示を取得するステップであって、第3のコードブロックパターン指示が、第3のコードブロックパターン指示が位置する257bコードブロックに含まれる66bコードブロックのパターンを示すために使用され、第3のコードブロックパターン指示の異なる値の間の最小ハミング距離が2である、ステップを含む。

可能な設計において、OTN伝送フレームは、フレキシブル光サービスユニットOSUflexフレームである。

可能な設計において、OSUflexフレームの長さは、192バイト、240バイト、128バイト、または64バイトである。

可能な設計において、検査情報は、CRC検査情報である。

可能な設計において、検査情報は、制御情報の1つ以上のバックアップである。

可能な設計において、サービスデータ情報のビットレートは、OTN伝送フレームのペイロード領域に対応するレートに等しい。

第3の態様によれば、この出願の実施形態は、サービス処理装置を提供する。装置は、OTNデバイスに適用される。装置は、プロセッサおよびメモリを含む。メモリは、プログラムコードを記憶するように構成される。プロセッサは、第1の態様および第1の態様の設計のいずれか1つによる方法を実行し、または第2の態様および第2の態様の設計のいずれか1つによる方法を実行するために、メモリに記憶されたプログラムコードを読み出し、実行するように構成される。

第4の態様によれば、この出願の実施形態は、OTNデバイスを提供する。OTNデバイスは、第3の態様による装置と、光トランシーバとを含む。光トランシーバは、装置によって送信されたOTN伝送フレームを受信し、OTN伝送フレームを送信するように構成され、またはOTN伝送フレームを受信し、OTN伝送フレームを装置に送信するように構成される。

第5の態様によれば、この出願の実施形態は、コンピュータ可読記憶媒体を提供する。記憶媒体は、ソフトウェアプログラムを記憶する。ソフトウェアプログラムが1つ以上のプロセッサによって読み出され、実行されるとき、第1の態様または第2の態様のいずれかの設計において提供される方法が、実行され得る。

第6の態様によれば、この出願の実施形態は、命令を含むコンピュータプログラム製品を提供する。コンピュータプログラム製品がコンピュータにおいて動作するとき、コンピュータは、第1の態様または第2の態様のいずれかの設計において提供される方法を実行する。

第7の態様によれば、この出願の実施形態は、チップを提供する。チップは、メモリに接続され、第1の態様または第2の態様のいずれかの設計において提供される方法を実行するために、メモリに記憶されたソフトウェアプログラムを読み出し、実行するように構成される。

この出願の実施形態によるOTNネットワークアーキテクチャの可能な概略図である。 この出願の実施形態によるOTNデバイスの構造の可能な概略図である。 この出願の実施形態によるサービス処理方法の可能な概略フローチャートである。 この出願の実施形態によるOSUflexフレームの構造の概略図である。 この出願の実施形態による257bデータコードブロックの可能な概略図である。 この出願の実施形態による257b制御コードブロックの別の可能な概略図である。 この出願の実施形態による257b制御コードブロックのさらに別の可能な概略図である。 この出願の実施形態による257b制御コードブロックのさらに別の可能な概略図である。 この出願の実施形態による、257bコードブロックストリームをOSUflexフレームにマッピングする可能な例示図である。 この出願の実施形態によるOSUflexフレームの構造の可能な概略図である。 この出願の実施形態によるOSUflexフレームの構造の可能な概略図である。 この出願の実施形態によるOSUflexフレームの構造の可能な概略図である。 この出願の実施形態によるサービス処理方法の可能な概略フローチャートである。 この出願の実施形態によるサービス処理装置の構造の可能な概略図である。 この出願の実施形態によるサービス処理装置の構造の別の可能な概略図である。 この出願の実施形態によるサービス処理装置の構造の可能な概略図である。

この出願の実施形態は、OTNなどの光ネットワークに適用可能である。1つのOTNは、通常、光ファイバを使用することによって複数のデバイスを接続することによって形成され、特定の要件に基づいて、リニアトポロジー、リングトポロジー、およびメッシュトポロジーなどの異なるトポロジータイプを構成し得る。図1は、この出願の実施形態によるOTNネットワークアーキテクチャの可能な概略図である。図1に表されるように、OTN 200は、8つのOTNデバイス201、すなわち、デバイスAからHを含む。202は、2つのデバイスを接続するように構成された光ファイバを示す。203は、顧客サービスデータを受信または送信するように構成された顧客サービスインターフェースを示す。1つのOTNデバイスは、実際の要件に基づいて異なる機能を有し得る。一般に、OTNデバイスは、光レイヤデバイス、電気レイヤデバイス、および光電子ハイブリッドデバイスに分類される。光レイヤデバイスは、光レイヤ信号を処理することができるデバイス、たとえば、光増幅器(optical amplifier、OA)または光アドドロップマルチプレクサ(optical add-drop multiplexer、OADM)である。OAは、光回線増幅器(optical line amplifier、OLA)とも呼ばれることがあり、主に、光信号の特定の性能を損なうことなく、より長い距離にわたる伝送をサポートするために光信号を増幅するよう構成される。OADMは、光信号が異なる出力ポート(これは、時々、方向と呼ばれる)から出力されることが可能であるように、光信号に対して空間変換を実行するように構成される。電気レイヤデバイスは、電気レイヤ信号を処理することができるデバイス、たとえば、OTN信号を処理することができるデバイスである。光電子ハイブリッドデバイスは、光レイヤ信号および電気レイヤ信号を処理することが可能なデバイスである。特定の統合の要件に基づいて、複数の異なる機能が1つのOTNデバイスに統合され得ることが留意されるべきである。この出願において提供される技術的解決策は、電気レイヤの機能を含む、異なる形式および統合のOTNデバイスに適用可能である。

図2は、この出願の実施形態によるOTNデバイスの構造の可能な概略図である。たとえば、OTNデバイスは、図1におけるデバイスAである。具体的には、OTNデバイス300は、分岐基板301、クロスコネクト基板302、回線基板303、光レイヤ処理基板(図に表されない)、ならびにシステム制御および通信基板304を含む。ネットワークデバイスは、特定の要件に基づいて、異なる数量の異なるタイプの基板を含んでよい。たとえば、コアノードとして働くネットワークデバイスは、分岐基板301を含まない。別の例として、エッジノードとして働くネットワークデバイスは、複数の分岐基板301を含み、または光クロスコネクト基板302を含まない。さらに別の例として、電気レイヤ機能のみをサポートするネットワークデバイスは、光レイヤ処理基板を含まなくてよい。

分岐基板301、クロスコネクト基板302、および回線基板303は、OTNの電気レイヤ信号を処理するように構成される。分岐基板301は、SDHサービス、パケットサービス、イーサネットサービス、およびフォワードサービスなどの様々な顧客サービスを受信および送信するように構成される。さらに、分岐基板301は、クライアント側の光モジュールおよび信号プロセッサに分割されてよい。クライアント側の光モジュールは、サービスデータを受信および／または送信するように構成された光トランシーバであってよい。信号プロセッサは、サービスデータをデータフレームにマッピングし、サービスデータをデータフレームからデマッピングするように構成される。クロスコネクト基板302は、1つ以上のタイプのデータフレームを交換することを完了するために、データフレームを交換するように構成される。回線基板303は、主に、回線側のデータフレームを処理する。具体的には、回線基板303は、回線側の光モジュールおよび信号プロセッサに分割されてよい。回線側の光モジュールは、データフレームを受信および／または送信するように構成された、回線側の光トランシーバであってよい。信号プロセッサは、回線側のデータフレームを多重化および多重化解除し、または回線側のデータフレームをマッピングおよびデマッピングするように構成される。システム制御および通信基板304は、システム制御を実現するように構成される。具体的には、システム制御および通信基板304は、バックプレーンを使用することによって異なる基板から情報を収集し、または対応する基板に制御命令を送信してよい。異なって指定されなければ、1つ以上の特定のコンポーネント(たとえば、信号プロセッサ)があってよいことが留意されるべきである。これは、この出願において限定されない。デバイスに含まれる基板のタイプ、基板の機能設計、および基板の数量は、この出願において限定されないことがさらに留意されるべきである。特定の実装の間、上記で言及された2つの基板が1つの基板として設計されてよいことが留意されるべきである。加えて、ネットワークデバイスは、予備電源、放熱ファン、および同様のものをさらに含んでよい。

この出願の実施形態における技術的概念が、まず、以下で説明される。

(1)64B/66B符号化は、64ビット(bit)のサービスデータまたはサービスデータに対応する64ビットの制御情報を、伝送のために66ビットのコードブロックに符号化する。66ビットのコードブロックは、単に、66bコードブロックと呼ばれる。この出願のこの実施形態において、66b、64b/66b、および同様のものは、66Bおよび64B/66Bとも表現されることがあり、名称はこの出願において具体的に限定されないことが留意されるべきである。66bコードブロックの最初の2ビットは、主に、データ整列および受信端においてデータビットストリームを受信する同期のために使用される同期ヘッダを示す。2つのタイプの同期ヘッダ、すなわち、「01」および「10」がある。「01」は、66bコードブロックが66bデータコードブロックであることを示し、同期ヘッダに続く64ビットは、サービスデータを搬送する。「10」は、66bコードブロックが66b制御コードブロックであることを示し、同期ヘッダに続く64ビットは、データおよび制御情報を含む混合データを含む。同期ヘッダの次にある、66b制御コードブロック内の8ビットは、タイプフィールドであり、続く56ビットは、制御情報、または制御情報および64ビットのデータの混合データを含む。66b制御コードブロックは、開始コードブロック、末尾コードブロック、アイドル(IDLE)コードブロック、または同様のものであってよい。

(2)OTNデバイスによって使用されるデータフレーム構造は、OTNフレームである。OTNフレームは、OTN伝送フレームとも呼ばれることがある。OTNフレームは、様々なサービスデータを搬送するために使用され、豊富な管理および監視機能を提供する。OTNフレームは、フレキシブル光サービスユニット(flexible optical service unit、OSUflex)フレームであってよく、OSUflexフレームは、単にOSUフレームとも呼ばれることがある。代替的に、OTNフレームは、光データユニットk(optical data unit k、ODUk)フレーム、ODUCnフレーム、ODUflexフレーム、光転送ユニットk(optical transport unit k、OTUk)フレーム、OTUCnフレーム、フレキシブルOTN(flexible OTN、FlexO)フレーム、または同様のものであってよい。ODUフレームとOTUフレームの間の違いは、OTUフレームがODUフレームおよびOTUオーバーヘッドを含むことにあり、kは、異なるレートレベルを表現し、たとえば、k=1は、2.5Gbpsを示し、k=4は、100Gbpsを示し、Cnは、可変レート、具体的には、100Gbpsの正の整数倍であるレートを示す。異なって注記されなければ、ODUフレームは、ODUkフレーム、ODUCnフレーム、およびODUflexフレームのうちのいずれか1つであり、OTUフレームは、OTUkフレーム、OTUCnフレーム、およびFlexOフレームのうちのいずれか1つである。OTN技術の発展にともなって、新しいタイプのOTNフレームが定義されることがあり、新しいタイプのOTNフレームもこの出願に適用可能であることがさらに留意されるべきである。

(3)Ceiling(x)は、x以上の最小の整数値を返すために使用される天井関数を示す。

(4)ハミング距離が、データ伝送誤り制御コードにおいて使用される。ハミング距離は、(同じ長さの)2つのワード内の対応するビットの異なる数量を示し、d(x, y)が、2つのワードxおよびyの間のハミング距離を示すために使用される。たとえば、排他的論理和演算が、2つの文字列に対して実行され、1である結果の数量が、カウントされる。この場合、数量は、ハミング距離である。最小ハミング距離が2であることは、同じ長さの2つのワードの間のハミング距離の最小値が2であること、言い換えると、同じ長さの2つのワードの間のハミング距離が2以上であることを意味する。

(5)「複数の」は、2つまたは2つより多くを指す。「および／または」は、関連付けられた対象の間の関連付けの関係を説明する。3つの関係があり得る。たとえば、Aおよび／またはBは、以下の3つの場合、すなわち、Aのみが存在する、AとBの両方が存在する、および、Bのみが存在する、を表現し得る。

(6)本発明の実施形態において使用される用語は、単に、特定の実施形態を例示する目的のためであり、本発明を限定するように意図されない。本発明の実施形態および添付の請求項において使用される単数形の用語「1つの」、「前述の」、および「前記」は、また、文脈において明確に異なって指定されなければ、複数形を含むように意図される。

(7)用語「第1の」、「第2の」、「第3の」、および同様のものは、様々なメッセージ、要求、およびネットワークデバイスを説明するために本発明の実施形態において使用され得るが、メッセージ、要求、およびネットワークデバイスは、これらの用語によって限定されない。これらの用語は、単に、メッセージ、要求、およびネットワークデバイスの間で区別するために使用される。たとえば、本発明の実施形態の範囲を逸脱することなく、第1のネットワークデバイスは、また、第2のネットワークデバイスと呼ばれてもよく、同様に、第2のネットワークデバイスは、また、第1のネットワークデバイスと呼ばれてもよい。

GFP-FおよびIMPのマッピング方式において帯域幅の浪費が存在し、サービストラフィックが増加するにつれて、将来、改良された方式で帯域幅が運用される必要があり、特に、パケットサービスがOTNの主流のベアラサービスとして働くので、この出願は、帯域幅の利用を改善するために、サービス処理方法および装置を提供する。

添付の図面を参照して、以下は、伝送端および受信端の観点から、この出願の実施形態において提供される解決策を詳細に個々に説明する。

図3は、この出願の実施形態によるサービス処理方法の可能な概略フローチャートである。サービス処理方法は、伝送端に適用されてよい。図3に表されるように、サービス処理方法は、S301からS305を含む。たとえば、伝送端におけるOTNデバイスが、サービス処理方法の手順を実行してよい。具体的には、伝送端におけるOTNデバイス内のプロセッサ、チップ、チップシステム、サービス処理機能を有するモジュール、または同様のものが、S301からS304を実行してよい。

OTNデバイスは、光トランシーバ(これは、時々、光トランシーバモジュールである)を使用することによって直接S305を実行し、すなわち、OTN伝送フレームを送信してよい。

S301:サービスデータを取得する。

たとえば、サービスデータが属するサービスは、パケットサービス、または固定ビットレートのサービスであってよい。パケットサービスは、通常、PKTによって表現される。たとえば、パケットサービスは、通常、媒体アクセス制御(medium access control、MAC)フレームデータストリームであってよく、またはIPパケットデータストリーム(IPパケットとも呼ばれる)であってよい。パケットサービスは、代替的に、マルチプロトコルラベルスイッチング(multi-protocol label switching、MPLS)パケットデータストリームまたはフレキシブルイーサネット(Flex Ethernet、FlexE)サービスコードブロックストリームであってよい。代替的に、パケットサービスは、64b/66b(bはビットを示す)符号化後に形成された66bコードブロックストリームであってよい。固定ビットレートのサービスは、64b/66b符号化後に形成された66bコードブロックストリームである。

S302:サービスデータを符号化して符号化されたサービスデータを取得し、符号化されたサービスデータは、制御情報およびサービスデータ情報を含む。

符号化されたサービスデータを取得するためにサービスデータが符号化されるとき、以下の方式1から3のいずれか1つが使用されてよい。以下のいくつかの方式は、単にこの出願における例として説明され、方式は、網羅的に説明されないことが理解されるべきである。

方式1:サービスデータが66bコードブロックストリームであるならば、符号化されたサービスデータを取得するためにサービスデータが符号化されるとき、66bコードブロックストリームは、Qbコードブロックストリームを取得するためにトランスコードされてよい。Q=256K+1またはQ=256K+1*Kであり、Kは、正の整数である。たとえば、Kは1であり、Q=257である。すなわち、66bコードブロックストリームが、257bコードブロックストリームを取得するためにトランスコードされる。別の例として、Kは2であり、Q=513/514である。すなわち、66bコードブロックストリームが、513bまたは514bコードブロックストリームを取得するためにトランスコードされる。続く説明において、257bコードブロックストリームを取得するために66bコードブロックストリームに対して256b/257b符号化処理が実行される例が使用される。257bコードブロックストリームが、符号化されたサービスデータである。

方式2:サービスデータが非66bコードブロックストリームであるならば、符号化されたサービスデータを取得するためにサービスデータが符号化されるとき、66bコードブロックストリームを取得するためにサービスデータに対して64b/66b符号化処理がまず実行されてよい。そして、257bコードブロックストリームを取得するために66bコードブロックストリームに対して256b/257b符号化処理が実行される。

非66bコードブロックストリームは、MACフレームデータストリーム、IPパケットデータストリーム、MPLSパケットデータストリーム、またはFlexEサービスコードブロックストリームであり得る。

方式3:サービスデータが非66bコードブロックストリームであるならば、符号化されたサービスデータを取得するためにサービスデータが符号化されるとき、66bコードブロックストリームを取得するためにサービスデータに対して64b/66b符号化処理がまず実行されてよい。66bコードブロックストリームが、符号化されたサービスデータである。

66bコードブロックストリームを257bコードブロックストリームに符号化する方式が、後に詳細に説明される。図6および関連する説明を参照されたい。詳細は、ここで繰り返して説明されない。

S303:制御情報をOTN伝送フレームのオーバーヘッド領域にマッピングし、制御情報を検査して検査情報を取得し、検査情報をOTN伝送フレームのオーバーヘッド領域にマッピングする。

検査情報は、CRC情報を含んでよく、または検査情報は、制御情報の1つ以上のバックアップであってよい。

たとえば、制御情報は、コードブロックタイプ指示を含んでよい。符号化されたサービスデータが257bコードブロックストリームである例において、コードブロックタイプ指示は、コードブロックタイプ指示を搬送する257bコードブロックのコードブロックタイプを示すために使用され、たとえば、257bコードブロックが制御コードブロックまたはデータコードブロックであることを示すために使用される。言い換えると、コードブロックタイプ指示は、OTN伝送フレームのオーバーヘッド領域にマッピングされる。

S304:サービスデータ情報をOTN伝送フレームのペイロード領域にマッピングする。

S305:符号化されたサービスデータを搬送するOTN伝送フレームを送信する。

たとえば、OTN伝送フレームがOSUflexフレームであるならば、OSUflexフレームは、光トランシーバ(これは、時々、光トランシーバモジュールである)を使用することによって直接送信されてよく、またはOSUflexフレームは、まず、別のOTNフレーム(たとえば、ODUフレームまたはFlexOフレーム)にマッピングされてよく、そして、別のOTNフレームが、光トランシーバモジュールを使用することによって送信されてよい。これは、この出願のこの実施形態において具体的に限定されない。

この出願のこの実施形態において、サービスデータ情報のビットレートは、OTN伝送フレームのペイロード領域のレートに等しく、言い換えると、符号化されたサービスデータの伝送レートは、OTN伝送フレームのペイロード領域のレートに適応される。たとえば、最終的に符号化されたサービスデータの伝送レートがOTN伝送フレームのペイロード領域のレートと一致するように、レート適応が、アイドルコードブロック(66b IDLE)を使用することによって実行されてよい。

たとえば、OTN伝送フレームは、OSUflexフレームである。図4は、この出願の実施形態によるOSUflexフレームの構造の概略図である。図4に表されるように、OSUflexフレームの構造は、2つの部分、すなわち、(W_OHビットを占有する)オーバーヘッド領域および(W_PLDビットを占有する)ペイロード領域を含む。オーバーヘッド領域は、バージョン識別子、サービス識別子、マッピング情報、および巡回冗長検査-Xビット(cyclic redundancy check-X bits、CRC-X)などのオーバーヘッド情報を含むがこれに限定されない。ペイロード領域は、サービスデータ情報を搬送するために使用される。OSUflexフレームの長さは、固定サイズを有する。たとえば、OSUflexフレームの長さは、Wによって表現される。言い換えると、W=W_OH+W_PLDである。たとえば、OSUflexフレームの長さは、192バイト、240バイト、128バイト、または64バイトである。

OSUflexフレームのビットレートがRであると仮定すると、パケットサービスが適応される必要があるレートは、R*W_PLD/W、すなわち、OSUflexフレームのペイロード領域のレートである。OSUflexフレームのビットレートRは、基準ビットレートのC倍である。基準ビットレートは、予め設定された値であり、Cの値は、ceiling[(パケットサービスのビットレート*W/W_PLD)/基準ビットレート]である。たとえば、基準ビットレートは、OTN伝送フレーム内で搬送される必要がある様々な低レートのサービスに適応するために、約2Mbps、10Mbps、または同様のものであってよい。計算の間、パケットサービスのビットレートは、有効なデータのビットレート、すなわち、66bコードブロック内の64bデータ(各66bコードブロック内の2ビットの同期ヘッダ以外の64ビットのデータ)に対応するビットレートである。上述のレート適応の後、符号化後のOSUflexフレームにマッピングされたサービスデータ情報のビットレートが、帯域幅の利用を最大化するためにパケットサービスに適応される。

たとえば、パケットサービスのビットレートがOSUflexフレームのペイロード領域のレートより小さいならば、66b IDLEコードブロックが、パケットサービスの66bコードブロックストリームに挿入されてよい。たとえば、IDLEコードブロックは、コードブロックTの後およびコードブロックSの前に挿入されてよい。代替的に、特別なコードブロックが、充填コードブロックとしてユーザ定義されてよい。充填コードブロックが挿入される位置は、限定されない。コードブロックTは、66bコードブロックストリームの開始コードブロックを示し、コードブロックSは、66bコードブロックストリームの末尾コードブロックを示す。MACフレームデータストリームを例として用いると、MACフレームが66bコードブロックストリームに符号化された後、MACフレームのフレームヘッダが、開始コードブロックに符号化され、MACフレームのフレーム末尾が、末尾コードブロックに符号化される。

以下は、66bコードブロックストリームを257bコードブロックストリームに変換する方式を詳細に説明する。

この出願のこの実施形態においては、各々の4つの66bコードブロックが、符号化を通して1つの257bコードブロックに変換される。符号化変換方式は、IEEE 802.3において定義された方法、または別のユーザ定義された符号化変換方法に従ってよい。

可能な実施形態において、符号化変換の動作は、4つの連続する66bコードブロックの2ビットの同期ヘッダを削除して256bを取得することと、256bの1ビットのコードブロックタイプ指示を追加して257bコードブロックを取得することとを含む。コードブロックタイプ指示が第1の値であるとき、257bコードブロックは、データコードブロックであり、またはコードブロックタイプ指示が第2の値であるとき、257bコードブロックは、制御コードブロックである。たとえば、第1の値が1であり、第2の値が0である、または第1の値が0であり、第2の値が1である。257bデータコードブロック内の4つの66bコードブロックのすべては、データコードブロックであり、257b制御コードブロック内の4つの66bコードブロックは、少なくとも1つの66b制御コードブロックを含む。コードブロックタイプ指示は、代替的に、257bコードブロックの制御情報であってよい。

例において、4つの66bコードブロックのすべてがデータコードブロックであるならば、257bデータコードブロックを取得するために、4つの66bコードブロックの2ビットの同期ヘッダが直接削除され、1ビットのコードブロックタイプ指示が追加される。コードブロックタイプ指示の値は、第1の値である。たとえば、図5は、この出願の実施形態による257bデータコードブロックの可能な概略図である。図5において、第1の値が1である例が使用される。図5において、括弧内の数字は、ビットの数量を示し、01は、66bデータコードブロックの2ビットの同期ヘッダであり、DB(data block)は、66bデータコードブロックの有効なデータを示す。

別の例において、4つの66bコードブロックが少なくとも1つの66b制御コードブロックを含むならば、4つの66bコードブロックの2ビットの同期ヘッダが削除され、1ビットのコードブロックタイプ指示が、また、追加される。コードブロックタイプ指示の値は、第2の値である。

4つの66bコードブロックが制御コードブロックであるか、またはデータコードブロックであるかを受信端が知ることを可能にするために、66bコードブロックパターンを示すために使用される指示情報が、257b制御コードブロックを取得するためにさらに追加される必要がある。

例1:66bコードブロックパターンを示すために使用される指示情報が第1のコードブロックパターン指示と呼ばれる例が、使用される。第1のコードブロックパターン指示は、4ビットを占有し、第1のコードブロックパターン指示は、257b制御コードブロックに含まれる4つの66bコードブロックのパターン、すなわち、4つの66bコードブロックの(66b制御コードブロックまたは66bデータコードブロックを含む)コードブロックタイプおよびコードブロック位置を示すために使用される。第1のコードブロックパターン指示において、第iのビットは、257b制御コードブロック内の第iの66bコードブロックがデータコードブロックであるか、または制御コードブロックであるかを示す。

図6は、この出願の実施形態による257b制御コードブロックの別の可能な概略図である。図6に表されるように、4つの66bコードブロックの2ビットの同期ヘッダが削除され、1ビットのコードブロックタイプ指示が追加され、第1の66b制御コードブロックの8ビットのタイプフィールドの最後の4ビットが削除され、残りの66b制御コードブロックのタイプフィールドが削除も変更もされず、完全に透過的な伝送が実行される。さらに、最終的に、図6に表される257b制御コードブロックを取得するために、4ビットの第1のコードブロックパターン指示が追加される。図6において、括弧内の数字は、ビットの数量を示し、10および01は、66bの2ビットの同期ヘッダである。01は、66bデータコードブロックを示し、10は、66b制御コードブロックを示し、FおよびSは、66b制御コードブロックのタイプフィールドのタイプ情報を示す。図6において、4つの66bコードブロックが3つの66b制御コードブロックおよび1つのデータコードブロックを含む例が、使用される。第1から第3の66bコードブロックは、66b制御コードブロックであり、第4の66bコードブロックは、66bデータコードブロックである。1が66bデータコードブロックを示し、0が66b制御コードブロックを示す例において、図6に表されるように、第1のコードブロックパターン指示の値は0001である。

例2:例1に基づいて信頼性をさらに改善するために、符号化を通して4つの66bコードブロックを変換することによって取得された257bコードブロックに対して、ビット誤り耐性保護がさらに実行されてよい。具体的には、4つの66bコードブロックが例1の方式で符号化を通して257bコードブロックに変換された後、257b制御コードブロック内の第1のコードブロックパターン指示が、第2のコードブロックパターン指示にさらに符号化されてよい。第2のコードブロックパターン指示の異なる値の間の最小ハミング距離は、2である。符号化は、予め設定された規則に従って実行される置換、または特定のアルゴリズムを使用することによって実行される取得として理解されてもよいことが理解されるべきである。

たとえば、表1は、第1のコードブロックパターン指示の異なる値と第2のコードブロックパターン指示の異なる値との間のマッピング関係を表す。表1における第3列内の第iのビットの値が1であるとき、それは、66bコードブロックが66bデータコードブロックであることを示し、または第iのビットの値が0であるとき、それは、66bコードブロックが66b制御コードブロックであることを示す。表1は、単に、第1のコードブロックパターン指示の異なる値と第2のコードブロックパターン指示の異なる値との間のマッピング関係の例であり、特定の限定を構成しないことが理解されるべきである。

表1における第1列は、4つの66bコードブロックが257bコードブロックを形成する前の元の66bコードブロックの組み合わせのパターンを表す。Sは、開始コードブロックを示し、Tは、末尾コードブロックを示し、Iは、アイドルコードブロックを示し、Dは、データコードブロックを示す。

図7は、この出願の実施形態による257b制御コードブロックのさらに別の可能な概略図である。図6の上述の例を続けて、表1を例として用いて、図7における257b制御コードブロックは、図6に表された257b制御コードブロック内の第2のビットから第5のビットまでの第1のコードブロックパターン指示の値0001を0100に符号化することによって取得される。

上述の実施形態において、257b制御コードブロック内の66bコードブロックのパターンを示すために使用される第1のコードブロックパターン指示が、最小ハミング距離が2である第2のコードブロックパターン指示にさらに符号化され、それによって、257b制御コードブロック内の66bコードブロックのパターンについての情報を示す4ビットがより強い誤り耐性能力を有することが保証され、4ビットのうちのいずれか1つに発生するビット誤りが適時な方式で発見されることが可能である。

例3:66bコードブロックパターンを示すために使用される指示情報が第3のコードブロックパターン指示と呼ばれる例が、使用される。第3のコードブロックパターン指示は、4ビットを占有し、第1のコードブロックパターン指示は、4つの66bコードブロックのパターン、すなわち、4つの66bコードブロックの(66b制御コードブロックまたは66bデータコードブロックを含む)コードブロックタイプおよびコードブロック位置を示すために使用される。異なるコードブロックタイプの66bコードブロックの組み合わせは、第3のコードブロックパターン指示の異なる値に対応する。第3のコードブロックパターン指示の異なる値の間の最小ハミング距離は、たとえば、表2に表されるように2である。

図8は、この出願の実施形態による257b制御コードブロックのさらに別の可能な概略図である。図8に表されるように、4つの66bコードブロックの2ビットの同期ヘッダが削除され、1ビットのコードブロックタイプ指示が追加され、第1の66b制御コードブロックの8ビットのタイプフィールドの最後の4ビットが削除され、残りの66b制御コードブロックのタイプフィールドが削除も変更もされず、完全に透過的な伝送が実行される。さらに、最終的に、図8に表される257b制御コードブロックを取得するために、4ビットの第3のコードブロックパターン指示が追加される。図8において、括弧内の数字は、ビットの数量を示し、10および01は、66bの2ビットの同期ヘッダである。01は、66bデータコードブロックを示し、10は、66b制御コードブロックを示し、FおよびSは、66b制御コードブロックのタイプフィールドのタイプ情報を示す。図8において、4つの66bコードブロックが3つの66b制御コードブロックおよび1つのデータコードブロックを含む例が、使用される。第1から第3の66bコードブロックは、66b制御コードブロックであり、第4の66bコードブロックは、66bデータコードブロックである。表2に表される、66bコードブロックの組み合わせと第3のコードブロックパターン指示の値との間のマッピング関係を例として用いて、図8に表されるように、第3のコードブロックパターン指示の値は、0100である。

この出願のこの実施形態においては、66bコードブロックストリームが符号化されるとき、66bコードブロックストリームは、符号化を通して別のフォーマットのコードブロックストリームにさらに変換され、たとえば、513bコードブロックストリームまたは514bコードブロックストリームに符号化されてよい。

たとえば、66bコードブロックストリームは、513bコードブロックストリームに符号化され、各々の8つの66bコードブロックが、符号化を通して1つの513bコードブロックに変換されてよい。512bを取得するために8つの連続する66bコードブロックの2ビットの同期ヘッダが削除され、513bコードブロックを取得するために512bの1ビットのコードブロックタイプ指示が追加される。コードブロックタイプ指示が第1の値であるとき、513bコードブロックは、513bデータコードブロックであり、またはコードブロックタイプ指示が第2の値であるとき、513bコードブロックは、513b制御コードブロックである。513bデータコードブロック内の8つの66bコードブロックのすべては、データコードブロックであり、513b制御コードブロック内の8つの66bコードブロックは、少なくとも1つの66b制御コードブロックを含む。

513b制御コードブロックについて、8つの66bコードブロックが制御コードブロックであるか、またはデータコードブロックであるかを受信端が知ることを可能にするために、66bコードブロックパターンを示すために使用される指示情報が、513b制御コードブロックを取得するためにさらに追加される必要がある。たとえば、4ビットまたは8ビットが占有されてよい。たとえば、1つの制御コードブロックのみがあるとき、第1の66b制御コードブロックの8ビットのタイプフィールドの最後の4ビットが削除されてよく、または2つ以上の制御コードブロックがあるとき、第1および第2の66b制御コードブロックの各々の8ビットのタイプフィールドの最後の4ビットが削除されてよく、残りの66b制御コードブロックのタイプフィールドが削除も変更もされず、完全に透過的な伝送が実行される。さらに、最終的に513b制御コードブロックを取得するために、66bコードブロックパターンを示すために使用される4ビットまたは8ビットの指示情報が追加される。66bコードブロックパターンを示すために使用される4ビットまたは8ビットの指示情報を構成する方式は、257b制御コードブロック内にあり、66bコードブロックパターンを示すために使用される4ビットの指示情報と同様である。たとえば、第1のコードブロックパターン指示の形式が使用され、第3のコードブロックパターン指示の形式が使用され、または第1のコードブロックパターン指示をさらに符号化することによって取得される第2のコードブロックパターン指示の形式が使用される。

たとえば、66bコードブロックストリームは、514bコードブロックストリームに符号化され、各々の8つの66bコードブロックが、符号化を通して1つの514bコードブロックに変換されてよい。512bを取得するために8つの連続する66bコードブロックの2ビットの同期ヘッダが削除され、514bコードブロックを取得するために512bの2ビットのコードブロックタイプ指示が追加される。たとえば、第1のビットが、第1から第4の66bコードブロックを含む第1の組み合わせ(256ビット)のコードブロックタイプを示し、第2のビットが、第5から第8の66bコードブロックを含む第2の組み合わせ(256ビット)のコードブロックタイプを示す。たとえば、第1のビットが1であるならば、第1の組み合わせは、4つの66bデータコードブロックを含み、または第1のビットが0であるならば、第1の組み合わせに含まれる4つの66bコードブロックのうちの少なくとも1つは、66b制御コードブロックである。第1の組み合わせおよび第2の組み合わせが4つの66b制御コードブロックを含むならば、257b制御コードブロック内と同じ方式で、コードブロックパターン指示(たとえば、第1のコードブロックパターン指示、第2のコードブロックパターン指示、または第3のコードブロックパターン指示)が追加されてよい。詳細は、ここで再度説明されない。

以下は、符号化されたサービスデータが257bコードブロックストリームである例を使用することによって、符号化されたサービスデータの制御情報および制御情報の検査情報をOTN伝送フレームのオーバーヘッド領域にマッピングすること、およびサービスデータ情報をOTN伝送フレームのペイロード領域にマッピングすることを説明する。

257bコードブロック内のコードブロックタイプ指示は、OSUflexフレームのオーバーヘッド領域にマッピングされ、CRC検査が実行される。コードブロックタイプ指示以外の情報は、OSUflexフレームのペイロード領域にマッピングされる。説明の容易さのために、コードブロックタイプ指示は、257bコードブロックの第1の部分と呼ばれ、257bコードブロック内のコードブロックタイプ指示以外の情報は、第2の部分と呼ばれる。たとえば、257bデータコードブロックについて、コードブロックタイプ指示が第1の部分であり、残りのサービスデータ情報が、第2の部分である。別の例として、257b制御コードブロックについて、コードブロックタイプ指示が第1の部分であり、残りのサービスデータ情報および残りのコードブロックパターン指示(第1のコードブロックパターン指示、第2のコードブロックパターン指示、または第3のコードブロックパターン指示)が第2の部分である。たとえば、図9を参照されたい。図9は、この出願の実施形態による、257bコードブロックストリームをOSUflexフレームにマッピングする可能な例示図である。

たとえば、コードブロックタイプ指示は、1ビットを占有する。具体的には、伝送端は、連続した257bコードブロックストリームをOSUflexフレームにマッピングする。各257bコードブロックの1ビットのコードブロックタイプ指示は、残りの256ビットの第2の部分から分離される。257bコードブロックの1ビットの第1の部分(コードブロックタイプ指示)は、OSUflexフレームのオーバーヘッド領域にマッピングされる。257bコードブロックの残りの256ビットの第2の部分は、OSUflexフレームのペイロード領域にマッピングされる。

上記で説明されたように、66bコードブロックストリームに対してレート適応が実行された。したがって、257bコードブロックの第2の部分に対応するビットレートは、OSUflexフレームのペイロード領域のビットレートと正確に等しい。第2の部分は、ビット同期マッピングを通してOSUflexフレームのペイロード領域にマッピングされる。各257bコードブロックの256ビットの第2の部分は、32バイトであり、第2の部分は、OSUflexフレームのペイロード境界バイトと整列される。

可能な実装において、符号化されたサービスデータを搬送するOTN伝送フレームを送信するS305の前に、OSUflexフレームのペイロード領域にマッピングされた最初の完全な257bコードブロックに対応する開始位置情報が、OSUflexフレームのオーバーヘッド領域に配置される。開始位置情報は、ポインタオーバーヘッドとも呼ばれることがある。受信端は、OSUflexフレームのペイロード領域内で搬送される各257bコードブロックの256ビットを復元するために、ポインタオーバーヘッドに基づいて、OSUflexフレームのペイロード領域内で搬送される最初の完全な257bコードブロックの開始位置を発見することができる。受信端は、また、ポインタオーバーヘッドに基づいて、開始バイトが現在のOSUflexフレームのペイロード領域に含まれる257bコードブロックの数量を知り、言い換えると、コードブロックタイプ指示がOSUflexフレームのオーバーヘッド領域に含まれる257bコードブロックの数量を知ることができる。

可能な実装において、伝送端は、さらに、OSUflexフレームのオーバーヘッド領域に含まれる、257bコードブロックのコードブロックタイプ指示およびポインタオーバーヘッドに対して巡回冗長検査(CRC-X)を実行して、Xビットの巡回冗長検査情報を生成し、OSUflexフレームのオーバーヘッド領域にXビットの巡回冗長検査情報を追加してよい。伝送端は、257bコードブロックのコードブロックタイプ指示およびポインタオーバーヘッドに対してCRC-Xを個々に実行してよく、または257bコードブロックのコードブロックタイプ指示およびポインタオーバーヘッドに対してCRC-Xを一緒に実行してよいことが留意されるべきである。コードブロックタイプ指示およびポインタオーバーヘッドに対して実行されるCRC-Xは、OSUflexフレームの別のオーバーヘッドに対して実行されるCRC-Xと独立であってよい。伝送端は、代替的に、コードブロックタイプ指示、ポインタオーバーヘッド、およびCRC-Xが実行される必要がある別のオーバーヘッドに対してCRC-X演算を共同で実行してよく、それによって、OSUflexフレーム内のオーバーヘッド情報が、同じCRC-X検査を共有し、それにより、さらに、帯域幅を減らし、処理の複雑さを減らす。

回線ビット誤りが、回線伝送プロセスにおいて発生することがある。完全な257bコードブロックが全体としてペイロード領域にマッピングされ、ビット誤りが257bコードブロックの1ビットのコードブロックタイプ情報において正確に発生し、たとえば、1ビットのコードブロックタイプ情報が0から1に変化するならば、受信端は、257b制御コードブロックを257bデータコードブロックとして誤ってみなし、復号を通して257b制御コードブロックを4つの66bデータコードブロックに直接変換することがある。それに対応して、受信された誤りのあるパケットが、パケットサービスにおいて正しいパケットとして処理され、言い換えると、信頼性の課題が引き起こされる。この出願において、257bコードブロックの第1の部分(コードブロックタイプ指示)および第2の部分(残りの256ビット)は個々にマッピングされ、コードブロックタイプ指示は、CRC-Xを実行するためにOSUflexフレームのオーバーヘッド領域に配置され、言い換えると、コードブロックタイプ指示に対してビット誤り保護が実行される。回線伝送プロセスにおいてビット誤りが発生する、たとえば、257bコードブロックのコードブロックタイプ指示において誤りが発生するとき、誤りは、CRC-X検査情報を使用することによって適時な方式で発見されることが可能であり、それによって、コードブロックタイプ指示に対応する257bコードブロックは破棄され、受信された誤りのあるパケットがパケットサービスにおいて正しいパケットとして処理される場合が回避され、それにより、伝送の信頼性を改善する。

任意選択で、レート適応後に取得された66bコードブロックストリームが、符号化を通して、別のフォーマットのコードブロックストリーム、たとえば、513bコードブロックストリームまたは514bコードブロックストリームに変換されるならば、513bコードブロックストリームまたは514bコードブロックストリームの制御情報およびサービスデータ情報が、それに対応してマッピングされる。たとえば、513bコードブロックストリームについて、各513bコードブロックの1ビットのコードブロックタイプ指示が、OSUflexフレームのオーバーヘッド領域にマッピングされてよく、残りの512ビットが、OSUflexフレームのペイロード領域にマッピングされる。514bコードブロックストリームについて、各514bコードブロックの2ビットのコードブロックタイプ指示が、OSUflexフレームのオーバーヘッド領域にマッピングされてよく、残りの512ビットが、OSUflexフレームのペイロード領域にマッピングされる。加えて、現在のOSUflexフレームのペイロード領域内で搬送される最初の完全なコードブロックの開始位置を示すために、OSUflexフレームのオーバーヘッド領域にポインタオーバーヘッドが追加されることも必要である。そして、OSUflexフレームにマッピングされたこれらの513bコードブロックのコードブロックタイプ指示およびポインタオーバーヘッドに対してCRC検査が実行され、CRC検査後に取得された検査情報がOSUflexフレームのオーバーヘッド領域に追加される。

信頼性を提供するためにCRCを使用する方法は、単に例であることがさらに留意されるべきである。代替的に、複数のオーバーヘッド情報のバックアップが、OSUflexフレームのオーバーヘッド領域にマッピングされてよく、信頼性を改善するために多数決が使用されてよい。

たとえば、以下は、OSUflexフレームサイズが192バイトである例を使用して257bコードブロックデータストリームをOSUflexフレームにマッピングするプロセスを説明する。図10A、図10B、および図10Cは、この出願の実施形態によるOSUflexフレームの構造の可能な概略図である。

図10A、図10B、および図10Cに表されるように、OSUflexフレームサイズは、192バイトであり、オーバーヘッド領域は、7バイトを含み、ペイロード領域は、185バイトである。5つの完全な257bコードブロックの第2の部分と1つの257bコードブロックの第2の部分に含まれる20バイトとが、各OSUflexフレームのペイロード領域にマッピングされてよく、言い換えると、5つの完全な257bコードブロックに対応する256ビットの情報と1つの257bコードブロックに対応する256ビットの情報の中の20バイトとが、各OSUflexフレームのペイロード領域にマッピングされてよい。257bコードブロックデータストリームをOSUflexフレームにマッピングするプロセスにおいて、1つの257bコードブロックが2つの連続するOSUflexフレームに配置されることが知られ得る。この場合は、クロスフレームマッピングと呼ばれることがある。

5ビットのPOINTER[4:0]が、OSUflexフレームのオーバーヘッド領域内で予約され、POINTERは、ポインタオーバーヘッドを示し、OSUflexフレームのペイロード領域内の最初の完全な257bコードブロックに対応する開始位置を示すために使用される。POINTER[4:0]は、POINTERオーバーヘッド内の5ビットを示す。たとえば、ポインタオーバーヘッドの値は、0から31までの範囲である。「0」は、現在のOSUflexフレームのペイロード領域内で搬送される最初の完全な257bコードブロックの開始位置が、OSUflexフレームのペイロード領域内の最初のバイトであることを示す。「1から31」は、それぞれ、現在のOSUflexフレームのペイロード領域内で搬送される最初の完全な257bコードブロックの開始位置が、OSUflexフレームのペイロード領域の第2のバイトから第32のバイトであることを示す。この場合は、クロスフレームマッピングである。すなわち、1から31バイトの不完全な257bコードブロックデータが、まず、現在のフレームのペイロード領域の開始部分にマッピングされ、そして、最初の完全な257bコードブロックがマッピングされる。

それに対応して、OSUflexフレームのペイロード領域にマッピングされた257bコードブロックに対応するコードブロックタイプ情報が、OSUflexフレームのオーバーヘッド領域にマッピングされる。6ビットの257b_IND[5:0]が、OSUflexフレームのオーバーヘッド領域内で予約され、具体的には、257bコードブロックのコードブロックタイプ指示を搬送するために使用される。257b_IND[5:0]は、指示オーバーヘッドとも呼ばれることがあり、または別の名称として呼ばれることがある。これは、この出願において限定されない。たとえば、図10Aおよび図10Cに表されるように、現在のOSUflexフレーム内で搬送される6つの257bコードブロックが6つの257bコードブロックの開始バイトを含むならば、対応する6つの257bコードブロックのコードブロックタイプ指示は、257b_IND[5:0]に直接配置される。たとえば、図10Bに表されるように、現在のOSUflexフレーム内で搬送される6つの257bコードブロックが5つの257bコードブロックの開始バイトを含むならば、5つの257bコードブロックの開始バイトを含む257bコードブロックのタイプ指示のみが、257b_INDオーバーヘッド内の5ビットの257b_IND[4:0]に配置される。

CRC8情報を生成し、CRC8情報をCRC8オーバーヘッド位置に配置するために、制御情報(257b_IND)およびポインタオーバーヘッド(POINTER)などのオーバーヘッド情報に対してCRC8巡回冗長検査の計算が実行される。CRC8の計算のために使用される検査多項式は、X8+X2+X+1を含むがこれに限定されず、初期値は、すべて1である。誤りを検出することに加えて、CRC8は、誤り訂正機能のために1ビットを使用してよい。

この出願のこの実施形態において言及された制御情報(257b_IND)、オーバーヘッド指示(POINTER)、および検査情報(CRC8)などのオーバーヘッドの特定の命名方式、およびOSUflexフレームのオーバーヘッド領域におけるオーバーヘッドの特定のオーバーヘッド位置は、限定されない。

以下は、受信端の観点からこの出願の実施形態において提供される解決策を説明する。

図11は、この出願の実施形態によるサービス処理方法の可能な概略フローチャートである。サービス処理方法は、受信端に適用されてよい。異なって指定されなければ、受信端によって実行される動作は、伝送側で実行される動作の逆のプロセスであることが理解されるべきである。図11に表されるように、サービス処理方法は、S1101からS1105を含む。たとえば、受信端におけるOTNデバイスが、サービス処理方法の手順を実行してよい。具体的には、受信端におけるOTNデバイス内のプロセッサ、チップ、チップシステム、サービス処理機能を有するモジュール、または同様のものが、S1102からS1105を実行してよい。具体的には、OTNデバイスは、光トランシーバ(これは、時々、光トランシーバモジュールである)を使用することによってS1101を直接実行し、すなわち、OTN伝送フレームを受信してよい。

S1101:OTN伝送フレームを受信し、OTN伝送フレームは、符号化されたサービスデータを搬送するために使用され、符号化されたサービスデータは、制御情報およびサービスデータ情報を含む。

さらに、OTN伝送フレームのオーバーヘッド領域のオーバーヘッド情報および検査情報が抽出される。オーバーヘッド情報は、(コードブロックタイプ指示を含む)制御情報を含み、オーバーヘッド指示をさらに含んでよい。オーバーヘッド情報は、検査情報に基づいて検査される。

ある方式では、検査情報がCRC情報であるならば、CRC検査処理が、検査情報に基づいてオーバーヘッド情報に対して実行されてよい。再計算されたCRC-Xの値がOSUflexフレームのオーバーヘッド領域から抽出されたCRC-Xの値と同じであるならば、オーバーヘッド領域の検査情報において誤りが発生しないとみなされる。再計算されたCRC-Xの値がOSUflexフレームのオーバーヘッド領域から抽出されたCRC-Xの値と異なるならば、オーバーヘッド領域内にビット誤りが存在するとみなされ、OSUflexフレームのペイロード領域内で搬送されたデータが直接破棄されてよい。

別の方式では、伝送端が検査情報として1つ以上の同じオーバーヘッド情報を送信するならば、オーバーヘッドが正しいかどうかを判定するために、複数のオーバーヘッド情報の値が同じかどうかが判定されてよい。具体的には、多数決が使用されてよく、または複数のオーバーヘッド情報が一致しているかどうかについての判断が使用されてよい。たとえば、3つの同じオーバーヘッドがあるならば、オーバーヘッドが完全に同じであるならば伝送が正しいとみなされてよく、または相対的に大きな数量の同じオーバーヘッドのオーバーヘッド値が正しい値として使用される。これは、この出願において限定されない。

図11において、制御情報および制御情報の検査情報がOTN伝送フレームのオーバーヘッド領域から抽出される例が使用される。

S1102:OTN伝送フレームのオーバーヘッド領域から制御情報および制御情報の検査情報を取得し、検査情報に基づいて制御情報を検査する。

たとえば、検査情報がCRC情報であるならば、受信端は、CRC情報に基づいて制御情報に対してCRC検査処理を実行する。別の例として、検査情報は、制御情報の1つ以上のバックアップであり、オーバーヘッド領域から抽出された制御情報を検査するために、値が同じであるかどうかを判定するために検査情報内の1つ以上の制御情報がオーバーヘッド領域から抽出された制御情報と比較される。

S1103:検査結果が正しいならば、OTN伝送フレームのペイロード領域からサービスデータ情報を取得し、制御情報およびサービスデータ情報を再組み立てして符号化されたサービスデータを取得する。

OTN伝送フレームがOSUflexフレームであり、符号化されたサービスデータが257bコードブロックストリームである例が、依然として使用される。受信端は、ポインタオーバーヘッドに基づいて、現在のOSUflexフレーム内で搬送された最初の完全な257bコードブロックに対応する開始位置を取得し、解析を通して、各257bコードブロックに対応する256ビットのデータを取得してよい。192バイトのサイズを有するOSUflexフレームについて、最初の完全な257bコードブロックの開始位置は、OSUflexフレームのペイロード領域の第1から第32のバイトである。さらに、受信端は、OSUflexフレームのオーバーヘッド領域内のポインタオーバーヘッドに基づいて、コードブロックタイプ指示が現在のOSUflexフレームのオーバーヘッド領域に含まれる257bコードブロックの数量を取得する。言い換えると、ポインタオーバーヘッドを取得した後、受信端は、開始バイトが現在のOSUflexフレームのペイロード領域に含まれる257bコードブロックの数量を決定し、言い換えると、コードブロックタイプ指示がOSUflexフレームのオーバーヘッド領域に含まれる257bコードブロックの数量を知ることができる。192バイトのサイズを有するOSUflexフレームについて、OSUflexフレームのペイロード領域は、185バイトである。ポインタオーバーヘッドの値が0から24の値であるならば、それは、OSUflexフレームのペイロード領域が6つの257bコードブロックの開始バイトを含み、言い換えると、OSUflexフレームのオーバーヘッド領域が6つの257bコードブロックのコードブロックタイプ指示を含むことを示し、257b_IND[5:0]から6ビットのコードブロックタイプ指示が抽出される。ポインタオーバーヘッドの値が25から31の値であるならば、それは、OSUflexフレームのペイロード領域が5つの257bコードブロックの開始バイトを含み、言い換えると、OSUflexフレームのオーバーヘッド領域が5つの257bコードブロックのタイプ指示情報を含むことを示し、257b_IND[4:0]から5ビットのコードブロックタイプ指示が抽出される。

さらに、取得されたコードブロックタイプ指示およびペイロード領域に対応する256ビットのデータが、257bコードブロックストリームへと再結合される。

各257bコードブロック内の取得された1ビットのコードブロックタイプ指示は、CRC検査が実行された後に取得されるので、各257bコードブロック内の取得された1ビットのコードブロックタイプ指示においてビット誤りが発生しないことが保証される。したがって、以下の場合、すなわち、1ビットのコードブロックタイプ指示においてビット誤りが発生し、受信端は、257b制御コードブロックが257bデータコードブロックであると誤ってみなし、復号を通して257b制御コードブロックを4つの66bデータコードブロックに変換し、それに対応して、受信された誤りのあるパケットがパケットサービスにおいて正しいパケットとして処理されること、が回避されることが源から保証される。したがって、伝送の信頼性が改善される。

S1104:符号化されたサービスデータを復号してサービスデータを取得する。

S1104において説明される復号プロセスは、図3に対応する実施形態において説明されたS302の逆プロセスである。

図3に対応する実施形態において説明された3つの符号化方式について、この実施形態は、3つの復号方式を例として提供する。

方式1:符号化されたサービスデータに対して64b/66b復号を実行して、サービスデータを取得する。

方式2:符号化されたサービスデータに対して256b/257b復号を実行して、66bコードブロックストリームを取得し、66bコードブロックストリームに対して64b/66b復号を実行して、サービスデータを取得する。

方式3:符号化されたサービスデータに対して256b/257b復号を実行して、サービスデータを取得する。

上述の実施形態と同じ発明概念に基づいて、この出願の実施形態は、サービス処理装置をさらに提供する。方法、装置、およびシステムは、同じ発明概念に基づく。課題を解決するための方法、装置、およびシステムの原理は、同様である。したがって、装置および方法の実装について、相互参照が行われてよく、繰り返される部分の詳細は説明されない。

図12および図13は、この出願の実施形態によるサービス処理装置の構造の2つの可能な概略図である。図12に表されるサービス処理装置1200は、伝送端におけるOTNデバイスによって実行される上述の方法におけるサービス取得、サービス処理、および送信動作を個々に実行するサービスデータ取得ユニット1201、マッピングユニット1202、および送信ユニット1203を含む。たとえば、サービスデータ取得ユニット1201は、S301を実行するように構成され、マッピングユニット1202は、S302からS304を実行するように構成され、送信ユニット1203は、S305を実行するように構成される。図13に表されるサービス処理装置1300は、受信端におけるOTNデバイスの上述の方法におけるサービス受信およびデマッピング動作を個々に実行する受信ユニット1301およびデマッピングユニット1302を含む。たとえば、受信ユニット1301は、S1101を実行するように構成され、デマッピングユニット1302は、S1102からS1104を実行するように構成される。

この技術分野の当業者は、装置1200および装置1300に含まれるユニットが1つ以上のプロセッサを使用することによって実現されてよいことを理解すべきである。

この出願の実施形態において、ユニットへの分割は例であり、単に論理的な機能分割である。実際の実装の間、別の分割方式が使用されてよい。加えて、この出願の実施形態における機能ユニットが、1つのプロセッサに統合されてよく、またはユニットの各々が、物理的に独立して存在してよく、または2つ以上のユニットが、1つのユニットに統合される。統合されたユニットは、ハードウェアの形式で実現されてよく、またはソフトウェア機能ユニットの形式で実現されてよい。

図14は、この出願の実施形態によるサービス処理装置の構造の可能な概略図である。図14に表されるように、サービス処理装置1400は、プロセッサ1401およびメモリ1402を含んでよい。サービス処理装置は、伝送端におけるOTNデバイス(図3に対応する実施形態)に適用されてよく、受信端におけるOTNデバイス(図11に対応する実施形態)に適用されてもよい。上述の方法を実行するためにプロセッサ1401によって使用されるプログラムコードが、メモリ1402に記憶されてよい。メモリ1402は、プロセッサ1401に結合される。プロセッサ1401は、メモリ1402と協働してよい。

例において、図12に表されたサービスデータ取得ユニット1201、マッピングユニット1202、および送信ユニット1203のすべてが、プロセッサ1401によって実現されてよい。たとえば、プロセッサ1401は、図2に表された回線基板または分岐基板における信号プロセッサであってよい。プロセッサ1401は、図3の伝送端におけるOTNデバイスによって実行される方法を実行するように構成される。実装プロセスにおいて、処理手順におけるステップは、図3の伝送端におけるOTNデバイスによって実行される方法を完了するために、プロセッサ1401におけるハードウェアの集積論理回路またはソフトウェアの形式の命令を使用することによって実行されてよい。

別の例において、図13に表された受信ユニット1301とデマッピングユニット1302の両方が、プロセッサ1401によって実現されてよい。たとえば、プロセッサ1401は、図2に表された回線基板または分岐基板における信号プロセッサであってよい。プロセッサ1401は、図11の受信端におけるOTNデバイスによって実行される方法を実行するように構成される。実装プロセスにおいて、処理手順におけるステップは、図11の受信端におけるOTNデバイスによって実行される方法を完了するために、プロセッサ1401におけるハードウェアの集積論理回路またはソフトウェアの形式の命令を使用することによって実行されてよい。

プロセッサ1401が送信ステップを実行するとき、プロセッサ1401は光トランシーバに送信することを実行してよく、それによって、光トランシーバはピアデバイスに送信することを実行することがさらに留意されるべきである。受信ステップを実行するとき、プロセッサ1401は、別の続く処理ステップを実行するために、光トランシーバからOTNデータを受信してよい。

この出願の実施形態において、プロセッサ1401は、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、フィールド・プログラマブル・ゲート・アレイもしくは別のプログラム可能な論理デバイス、個別ゲートもしくはトランジスタ論理デバイス、または個別ハードウェアコンポーネントであってよく、この出願の実施形態において開示された方法、ステップ、および論理ブロック図を実現または実行してよい。汎用プロセッサは、マイクロプロセッサまたは任意の従来のプロセッサ、または同様のものであってよい。この出願の実施形態を参照して開示された方法のステップは、ハードウェアプロセッサによって直接実行されてよく、またはプロセッサ内のハードウェアとソフトウェアユニットの組み合わせを使用することによって実行されてよい。この出願の実施形態における結合は、電気的形式、機械的形式、または別の形式の、装置、ユニット、またはモジュール間の間接的な結合または通信接続であってよく、装置、ユニット、またはモジュール間の情報交換のために使用される。メモリ1402は、ハードディスクドライブ(hard disk drive、HDD)などの不揮発性メモリであってよく、またはランダムアクセスメモリ(random-access memory、RAM)などの揮発性メモリ(volatile memory)であってよい。メモリ1402は、期待されるプログラムコードを命令またはデータ構造の形式で担持または記憶することができ、コンピュータによってアクセスされることが可能である任意の他の媒体であるがそれに限定されない。

上述の実施形態に基づいて、この出願の実施形態は、コンピュータ可読記憶媒体をさらに提供する。記憶媒体は、ソフトウェアプログラムを記憶し、ソフトウェアプログラムが1つ以上のプロセッサによって読み出され、実行されるとき、上述の実施形態のうちの1つ以上において提供される方法が実行されてよい。コンピュータ可読記憶媒体は、プログラムコードを記憶することができる任意の媒体、たとえば、USBフラッシュドライブ、取り外し可能なハードディスク、読み出し専用メモリ、ランダムアクセスメモリ、磁気ディスク、または光ディスクを含んでよい。

上述の実施形態に基づいて、この出願の実施形態は、チップをさらに提供する。チップは、上述の実施形態のいずれか1つ以上に含まれる機能を実現し、たとえば、上述の方法に含まれるデータフレームを取得または処理するように構成されたプロセッサを含む。任意選択で、チップは、メモリをさらに含み、メモリは、プロセッサの実行のために必要であるプログラム命令およびデータを記憶するように構成される。チップは、チップを含んでよく、またはチップおよび別の個別コンポーネントを含んでよい。

この技術分野の当業者は、この出願の実施形態が方法、システム、またはコンピュータプログラム製品として提供され得ることを理解すべきである。したがって、この出願は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアの組み合わせを用いた実施形態の形式を使用し得る。さらに、この出願は、コンピュータ使用可能プログラムコードを含む(ディスクメモリ、CD-ROM、光学式メモリ、および同様のものを含むがこれらに限定されない)1つ以上のコンピュータ使用可能記憶媒体において実現されるコンピュータプログラム製品の形式を使用し得る。

この出願は、この出願の実施形態による方法、デバイス(システム)、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して説明される。フローチャートおよび／またはブロック図における各プロセスおよび／または各ブロックと、フローチャートおよび／またはブロック図におけるプロセスおよび／またはブロックの組み合わせとを実現するためにコンピュータプログラム命令が使用され得ることが理解されるべきである。これらのコンピュータプログラム命令は、コンピュータまたは任意の他のプログラム可能なデータ処理デバイスのプロセッサによって実行される命令が、フローチャートにおける1つ以上のプロセスにおける、および／またはブロック図における1つ以上のブロックにおける特定の機能を実現するための装置を生成するように、マシンを生成するために汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、または任意の他のプログラム可能なデータ処理デバイスのプロセッサのために提供され得る。

これらのコンピュータプログラム命令は、また、コンピュータ可読メモリに記憶された命令が命令装置を含む人工物を生成するように、特定の方式で動作するようにコンピュータまたは任意の他のプログラム可能なデータ処理デバイスに命令することができるコンピュータ可読メモリに記憶され得る。命令装置は、フローチャートにおける1つ以上のプロセスにおける、および／またはブロック図における1つ以上のブロックにおける特定の機能を実現する。

これらのコンピュータプログラム命令は、また、コンピュータで実現される処理を生成するために、一連の動作およびステップがコンピュータまたは任意の他のプログラム可能なデバイスにおいて実行されるように、コンピュータまたは任意の他のプログラム可能なデータ処理デバイスにロードされ得る。したがって、コンピュータまたは任意の他のプログラム可能なデバイスにおいて実行される命令が、フローチャートにおける1つ以上のプロセスにおける、および／またはブロック図における1つ以上のブロックにおける特定の機能を実現するためのステップを提供する。

明確に、この技術分野の当業者は、この出願の実施形態の範囲から逸脱することなくこの出願の実施形態に様々な修正および変形を行うことができる。このようにして、この出願は、この出願の実施形態へのこれらの修正および変形を、それらが以下の請求項およびそれらの等価な技術によって定義される保護の範囲内に入るという条件で、包含するように意図される。

200 OTN
201 OTNデバイス
202 光ファイバ
203 顧客サービスインターフェース
300 OTNデバイス
301 分岐基板
302 クロスコネクト基板
303 回線基板
304 システム制御および通信基板
1200 サービス処理装置
1201 サービスデータ取得ユニット
1202 マッピングユニット
1203 送信ユニット
1300 サービス処理装置
1301 受信ユニット
1302 デマッピングユニット
1400 サービス処理装置
1401 プロセッサ
1402 メモリ

Claims (32)

1. サービス処理方法であって、前記方法は、
   サービスデータを取得するステップと、
   前記サービスデータを符号化して符号化されたサービスデータを取得するステップであって、前記符号化されたサービスデータが、制御情報およびサービスデータ情報を含む、ステップと、
   前記制御情報を光転送ネットワーク(OTN)伝送フレームのオーバーヘッド領域にマッピングし、前記制御情報を検査するための計算を実行して検査情報を取得し、前記検査情報を前記OTN伝送フレームの前記オーバーヘッド領域にマッピングするステップと、
   前記サービスデータ情報を前記OTN伝送フレームのペイロード領域にマッピングするステップと、
   前記符号化されたサービスデータを搬送する前記OTN伝送フレームを送信するステップとを含む、サービス処理方法。
2. 前記サービスデータが、媒体アクセス制御(MAC)フレームデータ、インターネットプロトコル(IP)パケット、マルチプロトコルラベルスイッチング(MPLS)パケット、フレキシブルイーサネット(FlexE)サービスコードブロックストリーム、または66bコードブロックストリームである、請求項1に記載の方法。
3. 前記サービスデータを符号化することが、
   前記サービスデータに対して64b/66b符号化を実行して前記符号化されたサービスデータを取得するステップを含む、請求項1または2に記載の方法。
4. 前記サービスデータを符号化することが、
   前記サービスデータに対して64b/66b符号化を実行して66bコードブロックストリームを取得するステップと、
   前記66bコードブロックストリームに対して256b/257b符号化処理を実行して257bコードブロックストリームを取得するステップであって、前記257bコードブロックストリームが、前記符号化されたサービスデータである、ステップとを含む、請求項1または2に記載の方法。
5. 前記サービスデータが、66bコードブロックストリームであり、前記サービスデータを符号化することが、
   前記サービスデータに対して256b/257b符号化処理を実行して前記符号化されたサービスデータを取得するステップを含む、請求項1または2に記載の方法。
6. 前記制御情報が、コードブロックタイプ指示を含む、請求項4または5に記載の方法。
7. 前記コードブロックタイプ指示が、257bコードブロックが制御コードブロックであることを示すとき、前記符号化されたサービスデータが、第1のコードブロックパターン指示をさらに含み、前記第1のコードブロックパターン指示が、前記第1のコードブロックパターン指示が位置するコードブロックに含まれる66bコードブロックのパターンを示すために使用される、請求項6に記載の方法。
8. 前記方法が、前記符号化されたサービスデータに含まれる前記第1のコードブロックパターン指示を第2のコードブロックパターン指示に符号化するステップであって、前記第2のコードブロックパターン指示の異なる値の間の最小ハミング距離が2である、ステップをさらに含む、請求項7に記載の方法。
9. 前記コードブロックタイプ指示が、前記257bコードブロックが257b制御コードブロックであることを示すとき、前記方法が、
   第3のコードブロックパターン指示を追加して前記符号化されたサービスデータを取得するステップであって、前記第3のコードブロックパターン指示が、前記第3のコードブロックパターン指示が位置するコードブロックに含まれる66bコードブロックのパターンを示すために使用され、前記第3のコードブロックパターン指示の異なる値の間の最小ハミング距離が2である、ステップをさらに含む、請求項7に記載の方法。
10. 前記OTN伝送フレームが、フレキシブル光サービスユニット(OSUflex)フレームである、請求項1から8のいずれか一項に記載の方法。
11. 前記OSUflexフレームの長さが、192バイト、240バイト、128バイト、または64バイトである、請求項10に記載の方法。
12. 前記検査情報が、巡回冗長検査(CRC)情報である、請求項1から11のいずれか一項に記載の方法。
13. 前記検査情報が、前記制御情報の1つ以上のバックアップである、請求項1から11のいずれか一項に記載の方法。
14. 前記サービスデータ情報のビットレートが、前記OTN伝送フレームの前記ペイロード領域に対応するレートに等しい、請求項1から13のいずれか一項に記載の方法。
15. 前記サービスデータ情報の前記ビットレートが、レート適応を実行するためにアイドルコードブロックが追加または削除された後に取得されるレートであり、レート適応後に取得された前記サービスデータ情報の前記ビットレートが、前記OTN伝送フレームの前記ペイロード領域に対応する前記レートに等しい、請求項14に記載の方法。
16. サービス処理方法であって、前記方法が、
    光転送ネットワーク(OTN)伝送フレームを受信するステップであって、前記OTN伝送フレームが、符号化されたサービスデータを搬送するために使用され、前記符号化されたサービスデータが、制御情報およびサービスデータ情報を含む、ステップと、
    前記OTN伝送フレームのオーバーヘッド領域から前記制御情報および前記制御情報の検査情報を取得し、前記検査情報に基づいて前記制御情報を検査するステップと、
    検査結果が正しいならば、前記OTN伝送フレームのペイロード領域から前記サービスデータ情報を取得し、前記制御情報および前記サービスデータ情報を再組み立てして前記符号化されたサービスデータを取得するステップと、
    前記符号化されたサービスデータを復号して前記サービスデータを取得するステップと
    を含む、サービス処理方法。
17. 前記サービスデータが、媒体アクセス制御(MAC)フレームデータ、インターネットプロトコル(IP)パケット、マルチプロトコルラベルスイッチング(MPLS)パケット、フレキシブルイーサネット(FlexE)サービスコードブロックストリーム、または66bコードブロックストリームである、請求項16に記載の方法。
18. 前記符号化されたサービスデータを復号することが、
    前記符号化されたサービスデータに対して64b/66b復号を実行して前記サービスデータを取得するステップを含む、請求項16または17に記載の方法。
19. 前記符号化されたサービスデータを復号することが、
    前記符号化されたサービスデータに対して256b/257b復号を実行して66bコードブロックストリームを取得するステップと、
    前記66bコードブロックストリームに対して64b/66b復号を実行して前記サービスデータを取得するステップとを含む、請求項16または17に記載の方法。
20. 前記サービスデータが、66bコードブロックストリームであり、前記符号化されたサービスデータを復号することが、具体的には、
    前記符号化されたサービスデータに対して256b/257b復号を実行して前記サービスデータを取得するステップを含む、請求項16または17に記載の方法。
21. 前記制御情報が、コードブロックタイプ指示を含む、請求項19または20に記載の方法。
22. 前記コードブロックタイプ指示が、257bコードブロックが制御コードブロックであることを示すとき、前記符号化されたサービスデータに対して256b/257b復号を実行する前に、前記方法が、
    前記符号化されたサービスデータに含まれる第2のコードブロックパターン指示を第1のコードブロックパターン指示に復号するステップであって、前記第1のコードブロックパターン指示が、前記第1のコードブロックパターン指示が位置するコードブロックに含まれる66bコードブロックのパターンを示すために使用され、前記第2のコードブロックパターン指示の異なる値の間の最小ハミング距離が2である、ステップをさらに含む、請求項21に記載の方法。
23. 前記符号化されたサービスデータに対して256b/257b復号を実行することが、
    前記符号化されたサービスデータから第3のコードブロックパターン指示を取得するステップであって、前記第3のコードブロックパターン指示が、前記第3のコードブロックパターン指示が位置する257bコードブロックに含まれる66bコードブロックのパターンを示すために使用され、前記第3のコードブロックパターン指示の異なる値の間の最小ハミング距離が2である、ステップを含む、請求項19または20に記載の方法。
24. 前記OTN伝送フレームが、フレキシブル光サービスユニット(OSUflex)フレームである、請求項16から23のいずれか一項に記載の方法。
25. 前記OSUflexフレームの長さが、192バイト、240バイト、128バイト、または64バイトである、請求項24に記載の方法。
26. 前記検査情報が、CRC情報である、請求項16から25のいずれか一項に記載の方法。
27. 前記検査情報が、前記制御情報の1つ以上のバックアップである、請求項16から26のいずれか一項に記載の方法。
28. 前記サービスデータ情報のビットレートが、前記OTN伝送フレームの前記ペイロード領域に対応するレートに等しい、請求項16から27のいずれか一項に記載の方法。
29. サービス処理装置であって、前記装置が、プロセッサとメモリとを含み、
    前記メモリが、プログラムコードを記憶し、
    前記プロセッサが、請求項1から15のいずれか一項に記載の方法を実行するために、前記メモリに記憶された前記プログラムコードを読み出し、実行するように構成された、サービス処理装置。
30. OTNデバイスであって、前記デバイスが、請求項29に記載の装置と、光トランシーバとを含み、前記光トランシーバが、前記装置によって送信されたOTN伝送フレームを受信し、前記OTN伝送フレームを送信するように構成された、OTNデバイス。
31. サービス処理装置であって、前記装置が、プロセッサとメモリとを含み、
    前記メモリが、プログラムコードを記憶し、
    前記プロセッサが、請求項16から28のいずれか一項に記載の方法を実行するために、前記メモリに記憶された前記プログラムコードを読み出し、実行するように構成された、サービス処理装置。
32. OTNデバイスであって、前記デバイスが、請求項31に記載の装置と、光トランシーバとを含み、前記光トランシーバが、OTN伝送フレームを受信し、前記OTN伝送フレームを前記装置に送信するように構成された、OTNデバイス。

Images