JP2023523462A - サービスデータ処理方法、サービスデータ交換方法、サービスデータ抽出方法およびコンピュータ可読媒体 - Google Patents

Abstract

本出願は、サービスデータ処理方法を提供する。前記サービスデータ処理方法は、複数のクライアントサービスのサービスデータに基づいて、各前記クライアントサービスのサービスブロックをそれぞれ生成することと、各前記クライアントサービスのサービスブロックを、少なくとも１つのサブスライシングフレームＳＳＦのペイロード領域にマッピングすることと、前記少なくとも１つのＳＳＦフレームを取得するよう、各前記ＳＳＦフレームのオーバヘッド領域フィールドを設定することと、を含む。ここで、各前記ＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックをそれぞれ運ぶ。本出願は、サービスデータ交換方法、サービスデータ抽出方法、プロバイダエッジデバイス、プロバイダ交換デバイス、およびコンピュータ可読媒体をさらに提供する【選択図】図１

Description

本開示の実施形態は、通信の技術分野に関するが、これに限定されない。

フレックスイーサネット（ＦｌｅｘＥ：Ｆｌｅｘｉｂｌｅ Ｅｔｈｅｒｎｅｔ）技術は、２０１５年３月に国際標準化機構ＯＩＦ（Ｏｐｔｉｃａｌ Ｉｎｔｅｒｎｅｔｗｏｒｋｉｎｇ Ｆｏｒｕｍ）によって研究が開始され、２０１６年３月に投票により関連する技術標準が正式に決定された。フレキシブルイーサネット技術は、共通のメカニズムによって、メディアアクセスコントロール（ＭＡＣ：Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）速度が異なる一連のサービスを送信する。送信されるサービスは、単一のＭＡＣ速度のサービスに限定されず、単一のＭＡＣ速度が高いサービスであってもよいし、複数のＭＡＣ速度が小さサービスの集合であってもよい。

本開示の実施形態は、サービスデータ処理方法、サービスデータ交換方法、サービスデータ抽出方法、プロバイダエッジデバイス、プロバイダ交換デバイス、及びコンピュータ可読媒体を提供する。

本開示の実施形態の第１方面は、サービスデータ処理方法を提供する。このサービスデータ処理方法は、複数のクライアントサービスのサービスデータに基づいて、各前記クライアントサービスのサービスブロックをそれぞれ生成することと、各前記クライアントサービスのサービスブロックを、少なくとも１つのサブスライシングフレームＳＳＦのペイロード領域にマッピングすることと、少なくとも１つのＳＳＦフレームを取得するよう、各前記ＳＳＦフレームのオーバヘッド領域フィールドを設定することとを含む。ここで、各前記ＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ。

本開示の実施形態の第２方面は、サービスデータ交換方法を提供する。このサービスデータ交換方法は、インバウンドポートにより受信されたインバウンドＳＳＦフレーム内の各サービスブロックのアウトバウンドポートを特定することと、同一のアウトバウンドポートに対応するサービスブロックを少なくとも１つのアウトバウンドＳＳＦフレームにマッピングすることと、アウトバウンドポートを介して前記アウトバウンドＳＳＦフレームを送信することとを含む。ここで、各前記インバウンドＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ。各前記アウトバウンドＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ。

本開示の実施形態の第３方面は、サービスデータ抽出方法を提供する。このサービスデータ抽出方法は、少なくとも１つのＳＳＦフレームから所定のクライアントサービスのサービスブロックを抽出することと、前記所定のクライアントサービスのサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出することとを含む。ここで、各前記ＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ。

本開示の実施形態の第４方面は、プロバイダエッジデバイス（ＰＥ）を提供する。前記プロバイダエッジデバイス（ＰＥ）は、１つ以上のプロセッサと、１つ以上のプログラムが格納されている記憶装置と、前記プロセッサと記憶装置との間に接続され、前記プロセッサと記憶装置との情報通信が行われるように設置される１つ以上のＩ／Ｏインターフェースとを備える。前記１つ以上のプログラムが前記１つ以上のプロセッサにより実行されるとき、前記１つ以上のプロセッサに上記いずれか１つのサービスデータ処理方法または上記いずれか１つのサービスデータ抽出方法を実現させる。

本開示の実施形態の第５方面は、プロバイダ交換デバイスを提供する。前記プロバイダ交換デバイスは、１つ以上のプロセッサと、１つ以上のプログラムが格納されている記憶装置と、前記プロセッサと記憶装置との間に接続され、前記プロセッサと記憶装置との情報通信が行われるように設置される１つ以上のＩ／Ｏインターフェースとを備える。前記１つ以上のプログラムが前記１つ以上のプロセッサにより実行されるとき、前記１つ以上のプロセッサに上記いずれか１つのサービスデータ交換方法を実現させる。

本開示の実施形態の第６方面は、コンピュータプログラムが記憶されているコンピュータ可読媒体を提供する。前記プログラムがプロセッサによって実行されるとき、上記いずれか１つのサービスデータ処理方法、上記いずれか１つのサービスデータ交換方法、または上記いずれか１つのサービスデータ抽出方法を実現させる。

図面は、本開示の実施形態をさらに理解するためのものであり、本明細書の一部を構成する。また、図面は、本開示の実施形態と共に本開示を解釈するためのものであり、本開示を限定するものではない。図面を参照して例示した実施形態を詳しく説明することにより、当業者は、上記の特徴、その他の特徴およびメリットについてさらに明確になるであろう。

図１は本開示の一実施形態に係るサービスデータ処理方法を示すフローチャートである。 図２は本開示の一実施形態におけるサービスベアラの階層を示す模式図である。 図３は、本開示の一実施形態に係る別のサービスデータ処理方法の一部のステップを示すフローチャートである。 図４は、本開示の一実施形態におけるクライアントサービスの対応するＳＳＣタイムスロットへのマッピングを示す模式図である。 図５は、６４／６６Ｂブロックのフォーマットを示す模式図である。 図６は、本開示の一実施形態に係るターミネートブロックの一実施形態を示す模式図である。 図７は、本開示の一実施形態におけるＳＳＦフレーム構造およびタイムスロット分割の一実施形態を示す模式図である。 図８は、本開示の一実施形態におけるＳＳＭＦマルチフレーム構造およびタイムスロット分割の一実施形態を示す模式図である。 図９は、本開示の一実施形態におけるＳＳＦフレーム構造およびタイムスロット分割の別の実施形態を示す模式図である。 図１０は、本開示の一実施形態に係る別のサービスデータ処理方法の一部のステップを示すフローチャートである。 本開示の一実施形態に係る更なるサービスデータ処理方法の一部のステップを示すフローチャートである。 図１２は、本開示の一実施形態に係るＳＳＦフレームにおけるオーバヘッドの一実施形態を示す模式図である。 図１３は、本開示の一実施形態に係る更なるサービスデータ処理方法の一部のステップを示すフローチャートである。 図１４は、本開示の一実施形態に係る更なるサービスデータ処理方法の一部のステップを示すフローチャートである。 図１５は、本開示の一実施形態に係るＳＳＦフレームにおけるオーバヘッドの特定フィールドの定義を示す模式図である。 図１６は、本開示の一実施形態に係る更なるサービスデータ処理方法の一部のステップを示すフローチャートである。 図１７は、本開示の一実施形態に係る更なるサービスデータ処理方法の一部のステップを示すフローチャートである。 図１８は、本開示の一実施形態に係る更なるサービスデータ処理方法の一部のステップを示すフローチャートである。 図１９は、本開示の一実施形態におけるＳＳＣチャネルデータストリームの一実施形態を示す模式図である 図２０は、本開示の一実施形態に係る更なるサービスデータ処理方法の一部のステップを示すフローチャートである。 図２１は、本開示の一実施形態に係るサービスデータ交換方法を示すフローチャートである。 図２２は、本開示の一実施形態に係る別のサービスデータ交換方法の一部のステップを示すフローチャートである。 図２３は、本開示の一実施形態におけるスロット交差の実施方式を示す模式図である。 図２４は、本開示の一実施形態に係る別のサービスデータ交換方法の一部のステップを示すフローチャートである。 図２５は、本開示の一実施形態に係る別のサービスデータ交換方法の一部のステップを示すフローチャートである。 図２６は、本開示の一実施形態に係る別のサービスデータ交換方法の一部のステップを示すフローチャートである。 図２７は、本開示の一実施形態に係るサービスデータ抽出方法を示すフローチャートである。 図２８は、本開示の一実施形態に係る別のサービスデータ抽出方法の一部のステップを示すフローチャートである。 図２９は、本開示の一実施形態に係る別のサービスデータ抽出方法の一部のステップを示すフローチャートである。 図３０は、本開示の一実施形態におけるＳＳＣチャネルを構築する実施方式を示す模式図である。 図３１は、本開示の一実施形態におけるＳＳＣチャネルを構築する別の実施方式を示す模式図である。 図３２は、本開示の一実施形態におけるＳＣＬ交差の実施方式を示す模式図である。 図３３は、本開示の一実施形態係るプロバイダエッジデバイスのブロック構成図である。 図３４は、本開示の一実施形態係るプロバイダ交換デバイスのブロック構成図である。 図３５は、本開示の一実施形態係るコンピュータ可読媒体のブロック構成図である。

当業者が本開示の技術案をよりよく理解できるように、以下、図面を参照して、本開示に係るサービスデータ処理方法、サービスデータ交換方法、サービスデータ抽出方法、プロバイダエッジデバイス、プロバイダ交換デバイス、及びコンピュータ可読媒体を詳しく説明する。

以下、図面を参照して実施形態を詳細に説明するが、例示した実施形態は、異なる形式で実現されることができ、本開示に説明された実施形態に限定されない。なお、これらの実施形態は、本開示を明確かつ完全に説明するためのものであり、当業者は、これらの実施形態から本開示の範囲を十分理解できるであろう。

矛盾しない場合に、本開示の各実施形態におけるそれぞれの特徴を組み合わせてもよい。

本明細書で使用される「および／または」という用語は、列挙された１つ以上の関連素子の任意のおよび全ての組み合わせを含む。

本明細書で使用される用語は、特定の実施形態を説明することだけを目的としており、本開示を限定することを意図しない。本明細書で使用される単数形「一つの」および「当該」は、文脈が明確に示さない限り、複数形も含むことを意図している。さらに、本明細書で使用される「・・・を含む」および／または「・・・からなる」という用語は、前記の特徴、全体、ステップ、操作、素子および／または構成要素の存在を指定しているが、１つまたは複数のその他の特徴、全体、ステップ、操作、素子および／またはそのグループの存在または追加を除外しない。

別途定義しない限り、本明細書で使用される全ての用語（技術用語および科学用語を含む）は、当業者によって一般的に理解されるものと同じ意味を有する。なお、一般的に使用される辞書で定義されているような用語は、関連技術および本開示の文脈における意味と一致する意味を有すべきであり、本明細書で明確的に限定されない限り、理想化されたまたは過度に形式的な意味を有すると解釈されない。

スライシング・パケット・ネットワーク（ＳＰＮ：Ｓｌｉｃｉｎｇ Ｐａｃｋｅｔ Ｎｅｔｗｏｒｋ）とメトロ・トランスポート・ネットワーク（ＭＴＮ：Ｍｅｔｒｏ Ｔｒａｎｓｐｏｒｔ Ｎｅｔｗｏｒｋ）は、ＦｌｅｘＥをサービス層として、エンドツーエンドのサービスのリジッドチャネル（Ｃｈａｎｎｅｌ）を実現している。しかし、現在のＦｌｅｘＥ、ＳＰＮ、およびＭＴＮ規格でサポートされているクライアントサービスの最小粒度は５Ｇｂ／ｓであり、５Ｇｂ／ｓより小さいサービスのハードアイソレーションとリジッドチャネルをサポートしない。また、光トランスポートネットワーク（ＯＴＮ：ＯｐｔｉｃａｌＴｒａｎｓｐｏｒｔＮｅｔｗｏｒｋ）技術は、最小粒度が１．２５Ｇｂ／ｓであるサービスをサポートするが、１．２５Ｇｂ／ｓより小さいサービスをサポートしない。本開示の発明者は、従来技術における小粒度のクライアントサービスをサポートする方法は、いずれもＦｌｅｘＥの５Ｇ粒度のタイムスロットから改善されたものであり、主に次の問題があることを発見した。（１）サービスの粒度について依然として制限されている。例えば、サービスの粒度が１Ｇｂ／ｓ以上であることが要求され、１０Ｍｂ／ｓや１００Ｍｂ／ｓなどの粒度の小さいサービスをサポートしない。（２）柔軟性が低く、送信されるサービスは単一のＭＡＣレートのサービスに限定されなくなったものの、１つの５Ｇのタイムスロットで粒度の異なる小粒度のクライアントサービスの混合送信をサポートすることが難しい。（３）互換性が低く、現在のイーサネット、ＦｌｅｘＥ、ＳＰＮ、およびＭＴＮ規格と互換性がなく、標準のＳＰＮ機器のＰ（Ｐｒｏｖｉｄｅｒ）ノードを通過できないなど、既存の機器と通信できない。

上記のことを鑑み、図１を参照して、本開示の実施形態の第１方面は、サービスデータ処理方法を提供する。このサービスデータ処理方法は、ステップＳ１１０、ステップＳ１２０、ステップＳ１３０を含む。ステップＳ１１０において、複数のクライアントサービスのサービスデータに基づいて、各前記クライアントサービスのサービスブロックをそれぞれ生成する。ステップＳ１２０において、各前記クライアントサービスのサービスブロックをすべて、少なくとも１つのサブスライシングフレームＳＳＦのペイロード領域にマッピングする。ステップＳ１３０において、少なくとも１つのＳＳＦフレームを取得するよう、各ＳＳＦフレームのオーバヘッド領域フィールドを構成する。ここで、各前記ＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ。

本開示の実施形態において、サブスライシングフレーム（ＳＳＦ：Ｓｕｂ Ｓｌｉｃｉｎｇ Ｆｒａｍｅ）が提案された。このＳＳＦフレームは、オーバヘッド領域と、少なくとも１つのクライアントサービスを運ぶ可能なペイロード領域とを含む。各クライアントサービスは、１つのサブスライシングチャネル（ＳＳＣ：Ｓｕｂ Ｓｌｉｃｉｎｇ Ｃｈａｎｎｅｌ）に対応し、全てのクライアントサービスのＳＳＣチャネルによりサブスライシングチャネル層（ＳＳＣＬ：ＳＳＣ Ｌａｙｅｒ）が構成される。

なお、本開示の実施形態において、前記ＳＳＣチャネルは、サービス層チャネル上に構成された論理チャネルであり、前記ＳＳＣＬは、サービス層に構成された論理チャネル副層である。例えば、ＳＳＣＬは、ＩＥＥＥ８０２．３の物理符号化副層（ＰＣＳ：Ｐｈｙｓｉｃａｌ Ｃｏｄｉｎｇ Ｓｕｂｌａｙｅｒ）と、媒体アクセス制御層（ＭＡＣ：Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）との間に位置されるチャネル副層である。本開示の実施形態は、前記サービス層を特に限定しない。例えば、図２に示すように、前記サービス層は、ＳＰＮスライシングチャネル（ＳＰＮ ＳｌｉｃｉｎｇＣｈａｎｎｅｌ）に対応する、ＳＰＮのスライシングチャネル層（ＳＣＬ：Ｓｌｉｃｉｎｇ Ｃｈａｎｎｅｌ Ｌａｙｅｒ）であってもよいし、ＭＴＮパスチャネルに対応する、ＭＴＮのパス層（Ｐａｔｈ Ｌａｙｅｒ）であってもよいし、ＦｌｅｘＥであってもよいし、さらに、イーサネットポートの物理層（ＰＨＹ：Ｐｈｙｓｉｃａｌ）、即ち、図２のＩＥＥＥ８０２．３ＰＨＹであってもよい。また、前記サービス層は、光トランスポートネットワーク（ＯＴＮ：Ｏｐｔｉｃａｌ Ｔｒａｎｓｐｏｒｔ Ｎｅｔｗｏｒｋ）であってもよい。

本開示の実施形態において、ＳＳＦフレームについてフレーム構造が予め定義されているが、本開示は、前記予め定義されたフレーム構造について特に限定しない。ソースプロバイダエッジ（ＰＥ：Ｐｒｏｖｉｄｅｒ Ｅｄｇｅ）ノードでは、ステップＳ１１０により、所定のフォーマットに従って異なるクライアントサービスのサービスデータをパッケージング／符号化し、ＳＳＦフレームの所定のフレーム構造に準拠するサービスブロックを生成する。なお、前記ＳＳＦフレームの予め定義されたフレーム構造に準拠する異なるクライアントサービスのサービスブロックは、フォーマットとサイズがいずれも同一である。ステップＳ１２０において、所定のマッピング方式により、各クライアントサービスのサービスブロックが組み立てられる。ステップＳ１３０において、各ＳＳＦフレームのオーバヘッドフィールドが設定され、前記予め定義されたフレーム構造に準拠するＳＳＦフレームが少なくとも１つ生成される。おな、本開示の実施形態において、ステップＳ１１０およびステップＳ１２０に対するステップＳ１３０の実行順序は限定されない。例えば、各クライアントサービスのサービスブロックを少なくとも１つのＳＳＦフレームにマッピングする前に、ＳＳＦフレームのオーバヘッドフィールドを設定してもよい。また、各クライアントサービスのサービスブロックを少なくとも１つのＳＳＦフレームにマッピングする後に、ＳＳＦフレームのオーバヘッドフィールドを設定してもよい。

本開示の実施形態は、クライアントサービスの種類を特に限定しない。例えば、図２に示すように、前記クライアント（Ｃｌｉｅｎｔ）サービスはイーサネットサービス（Ｅｔｈｅｒｎｅｔ Ｓｅｒｖｉｃｅ）であってもよいし、固定レートを有する時分割多重（ＴＤＭ：ＴｉｍｅＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅｘｉｎｇ）サービス（ＴＤＭＳｅｒｖｉｃｅ）であってもよい。さらに、ステップＳ１１０において、前記複数のクライアントサービスは、Ｎ個のイーサネットサービスであってもよいし、Ｎ個のＴＤＭサービスであってもよい。また、Ｍ個のイーサネットサービスおよびＬ個のＴＤＭサービスであってもよく、ただし、Ｍ＋Ｌ＝Ｎ、Ｎは正の整数であり、ＬおよびＭは自然数である。本開示の実施形態は、特にこれに限定されない。

本開示の実施形態では、クライアントサービスの粒度について特に限定されない。前記クライアントサービスは粒度が５Ｇより小さいサービスであってもよい。例えば、前記クライアントサービスの粒度が１Ｇｂ／ｓ、１００Ｍｂ／ｓ、１０Ｍｂ／ｓ等である。また、粒度が５Ｇであるサービスであってもよい。即ち、前記クライアントサービスの粒度が５Ｇｂ／ｓである。さらに、粒度が５Ｇより大きいサービスであってもよい。例えば、前記クライアントサービスの粒度が６Ｇｂ／ｓ、８Ｇｂ／ｓ等である。

なお、本開示の実施形態において、各ＳＳＦフレームは、いずれも複数の異なるクライアントサービスを運ぶ。即ち、各ＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックからなる。本開示の実施形態において、複数のクライアントサービスがある場合、複数のクライアントサービスのサービスブロックを同じＳＳＦフレームに組み入れてもよい。また、隣接する２つ以上のＳＳＦフレームを結合してサブスライシングマルチフレーム（ＳＳＭＦ：Ｓｕｂ Ｓｌｉｃｉｎｇ Ｍｕｌｔｉ－Ｆｒａｍｅ）にし、複数のクライアントサービスを前記ＳＳＭＦマルチフレームにマッピングしてもよい。本開示の実施形態は、特にこれに限定されない。例えば、ＳＳＦフレームの予め定義されたフレーム長、各クライアントサービスの数および粒度に基づいて、複数のクライアントサービスを１つのＳＳＦフレームにマッピングするか、または複数のＳＳＦフレームからなるＳＳＭＦマルチフレームにマッピングするかを特定する。

本開示の実施形態において、前記複数のクライアントサービスの粒度が異なってもよい。ステップＳ１２０において、異なる粒度のクライアントサービスは、ＳＳＦフレームまたはＳＳＭＦマルチフレームにマッピングされたサービスブロックの数が異なることで、異なる粒度のクライアントサービスを運ぶ可能な異なる帯域幅のＳＳＣチャネルを実現する。なお、ステップＳ１１０～ステップＳ１３０により、任意の帯域幅のＳＳＣチャネルを実現できる。つまり、本開示の実施形態は、クライアントサービスの粒度が限定されない。

さらに、ソースＰＥノードによって生成されるＳＳＦフレームには、ＳＳＦフレームを構成するその他のデータ、例えば、操作保守管理（ＯＡＭ：Ｏｐｅｒａｔｉｏｎ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ ａｎｄ Ｍａｉｎｔｅｎａｎｃｅ）情報なども含まれるが、本開示の実施形態はこれに限定されない。

本開示の実施形態に係るサービスデータ処理方法において、ＳＳＦフレームが提案された。各ＳＳＦフレームは、いずれも複数の異なるクライアントサービスを運ぶことができる。複数のＳＳＦフレームにより、ＳＳＭＦマルチフレームが構成される。本開示の実施形態において、予め定義されたＳＳＦフレームフォーマットに従って異なるクライアントサービスをパッケージングしおよび符号化し、異なるクライアントサービスのサービスブロックを生成すると共に、異なるクライアントサービスの粒度に応じて、対応する数のサービスブロックをＳＳＦフレームまたはＳＳＭＦマルチフレームにマッピングして、ＳＳＦフレームまたはＳＳＭＦマルチフレームを構成する。このように、異なる粒度のクライアントサービスの同時送信が実現できる。本開示の実施形態に係るサービスデータ処理方法は、異なる粒度のサービスのリジッドチャネルでの送信を実現し、低遅延、低ジッター、ハードイソレーション、異なる帯域幅の伝送要件を満たし、最小粒度のクライアントサービスの従来のＦｌｅｘＥ、ＳＰＮ、ＭＴＮ等の規格により制限されることがなくなる。また、複数のイーサネットサービス、または／およびＴＤＭサービスを同時にサポートすることができ、サービスの速度が柔軟である。さらに、ＳＰＮ、ＭＴＮ、イーサネット、ＯＴＮ等のうちのいずれか１つをサービス層として、ＳＳＦフレームを送信可能であり、Ｅｔｈｅｒｎｅｔ、ＦｌｅｘＥ、ＳＰＮ、ＭＴＮ、ＯＴＮなどの既存の標準システムとの良好な互換性を実現する。

本開示の実施形態において、ステップＳ１２０における、各前記クライアントサービスのサービスブロックを少なくとも１つのサブスライシングフレームＳＳＦのペイロード領域にマッピングするマッピング方法について特に限定しない。一つの選択可能な実施形態として、タイムスロットスケジューリングの方式を利用して、異なるクライアントサービスのサービスブロックをＳＳＦフレームまたはＳＳＭＦマルチフレームにマッピングしてもよい。具体的には、ＳＳＦフレームまたはＳＳＭＦマルチフレームのペイロード領域を固定長のタイムスロットに分割して、ＳＳＦフレームが運ばれる異なるクライアントサービスのサービスについて固定速度の帯域幅とリジッドイソレーションを提供することが確保される。

それに応じて、図３を参照して、いくつかの実施形態において、ステップＳ１２０は、具体的にステップＳ１２１、ステップＳ１２２を含む。ステップＳ１２１において、前記少なくとも１つのＳＳＦフレームのペイロード領域を複数のタイムスロットに分割する。ステップＳ１２２において、前記クライアントサービスのサービスブロックをそれぞれ、前記複数のタイムスロットにおける異なるタイムスロットにマッピングする。ここで、異なる前記クライアントサービスに対応するタイムスロットは、各前記クライアントサービスをそれぞれ運ぶサブスライシングチャネルＳＳＣを構成する。

本開示の実施形態において、１つの選択可能な実施形態として、ステップＳ１２１において、単一のＳＳＦフレームのペイロード領域を分割して、複数のタイムスロットを得てもよい。

また、別の１つの選択可能な実施形態として、ステップＳ１２１において、２つ以上のＳＳＦフレームからＳＳＭＦマルチフレームを構成し、ＳＳＭＦマルチフレームのペイロード領域を分割して複数のタイムスロットを得てもよい。

本開示の実施形態において、ＳＳＦフレームまたはＳＳＭＦマルチフレームのペイロード領域を分割して得られるタイムスロットのサイズは特に限定されない。例えば、前記タイムスロットのサイズをステップＳ１１０におけるサービスブロックのサイズと等しくすることができる。前記サービスブロックがＩＥＥＥ ８０２．３符号化規格に準拠する６４／６６Ｂブロックである場合、前記タイムスロットのサイズは６６ｂｉｔである。また、前記タイムスロットのサイズは、各クライアントサービスの粒度に応じて特定してもよい。さらに、例えば、複数のクライアントサービスののうち、粒度の最も小さいクライアントサービスの粒度サイズをタイムスロットのサイズとして特定してもよい。さらに、前記タイムスロットのサイズは、複数のクライアントサービスの粒度の公約数に基づいて特定してもよい。

ステップＳ１２２において、各クライアントサービスの粒度と、式（１）によって特定されるタイムスロットの速度に基づいて、各クライアントサービスのサービスブロックをそれぞれ、前記複数のタイムスロット内の異なるタイムスロットにマッピングする。

なお、同一のクライアントサービスのサービスブロックは、隣接する複数のタイムスロットにマッピングされてもよく、隣接しない複数のタイムスロットにマッピングされてもよい。本開示の実施形態はこれに限定されない。なお、クライアントサービスを運ぶタイムスロットは、該クライアントサービスを運ぶＳＳＣチャネルと見なしてもよい。異なるクライアントサービスを運ぶＳＳＣチャネルを構成するタイムスロットが異なる場合、異なるクライアントサービスを運ぶＳＳＣチャネルの帯域幅も異なる。一方、同一のクライアントサービスは、クライアントサービスを運ぶタイムスロット内において、連続するコードストリームと見なしてもよい。

第１の実施形態
第１の実施形態では、図４に示すように、ＳＳＦフレームは、オーバヘッド（ＯＨ：ｏｖｅｒｈｅａｄ）と、ペイロール（Ｐａｙｌｏａｄ）とを含むが、これらに限定されない。

図４において、ＳＳＦフレームのペイロードは、同一サイズのｍ個のタイムスロットｓｌｏｔ１～ｓｌｏｔｍに分割されている。ｓｌｏｔ１とｓｌｏｔ２とにより、クライアントサービスＣｌｉｅｎｔＡを運ぶＳＳＣＡチャネルが構成され、ｓｌｏｔｉにより、クライアントサービスＣｌｉｅｎｔＢを運ぶＳＳＣＢチャネルが構成される。ＳＳＣＡチャネルの帯域幅はｓｌｏｔ１とｓｌｏｔ２の速度の合計に等しく、ＳＳＣＢチャネルの帯域幅はｓｌｏｔｉの速度に等しい。

なお、第１の実施形態では、その他の異なるクライアントサービスも存在してもよい。各クライアントサービスは、いずれも図４に示すｓｌｏｔ１～ｓｌｏｔｍの内の対応するタイムスロットにより構成されるＳＳＣチャネルによって運ばれる。異なるクライアントサービスを運ぶＳＳＣチャネルの帯域幅は異なってもよい。

第２の実施形態
第２の実施形態において、ＳＳＦフレームの構造は、ＩＥＥＥ８０２．３のＰＣＳ層の６４／６６Ｂ符号化規格に基づいて定義される。

ＳＳＦフレームを構成する６４／６６Ｂブロックには３つのタイプがある。つまり、１つのスタートブロック（Ｓｔａｒｔ Ｂｌｏｃｋ、Ｓブロックとも称す）、ｎ個のデータブロック（Ｄａｔａ Ｂｌｏｃｋ、Ｄブロックとも称す）、および１つのターミネートブロック（Ｔｅｒｍｉｎａｔｅ Ｂｌｏｃｋ、Ｔブロックとも称す）である。ＳＳＦフレームの長さは（ｎ＋２）＊６６ｂｉｔである。ここで、ｎは設計によって値が異なる。即ち、ＳＳＦフレームはその他の固定長であってもよい。例えば、ｎ＝４９５とすると、ＳＳＦフレームの長さは３２８０２ｂｉｔになる。

第２の実施形態において、Ｓブロック、Ｄブロック、Ｔブロックは、ＩＥＥＥ８０２．３ ＰＣＳ６４／６６Ｂ符号化規格に準拠する６６Ｂブロックである。図５は、ＩＥＥＥ８０２．３規格による６４／６６Ｂブロックのフォーマットを示している。図５に示すように、６６Ｂブロックの最初の２ビットは、コントロールブロック（Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ）とデータブロック（Ｄａｔａ Ｂｌｏｃｋ）とを区別するために使用されるシンクヘッダー（ｓｙｎｃ ｈｅａｄｅｒ）である。図５において、１０はＣｏｎｔｒｏｌ Ｂｌｏｃｋを表し、０１はＤａｔａ Ｂｌｏｃｋを表す。ここで、ＳブロックとＴブロックはＣｏｎｔｒｏｌ Ｂｌｏｃｋに属し、ＤブロックはＤａｔａ Ｂｌｏｃｋに属す。Ｃｏｎｔｒｏｌ Ｂｌｏｃｋについて、シンクヘッダーの後の１番目のバイトはブロックタイプ（Ｂｌｏｃｋ Ｔｙｐｅ）を表す。第２の実施形態において、ＳＳＦフレームの最初のブロック（Ｓブロック）のブロックタイプは０ｘ７８であり、ＳＳＦフレームの最後のブロック（Ｔブロック）のブロックタイプは０ｘＦＦである。図６に示すように、ＴブロックのバイトＤ０～Ｄ６（ｂｉｔ１０～６５）がペイロードデータである。

第２の実施形態において、ＳＳＦフレームのＤブロックとＴブロックは、ペイロードを運ぶために用いられる。異なるクライアントサービスは、ＤブロックまたはＴブロックの形式でパッケージング／符号化され、サービスブロックとしてＤブロックまたはＴブロックが生成される。ＳＳＦフレームのＳブロックおよび最初のＤブロック拡張が、オーバヘッドを運ぶために用いられる。

図７は、第２の実施形態において単一のＳＳＦフレームを複数のタイムスロットに分割する模式図である。図７に示すように、ＳＳＦフレームの２番目からｎ番目のＤブロックとＴブロックによって運ばれるペイロードが分割され、同一サイズのｍ個のタイムスロットｓｌｏｔ１～ｓｌｏｔｍが得られる。

図８は、第２の実施形態においてＳＳＭＦマルチフレームを複数のタイムスロットに分割する模式図である。図８に示すように、図８に示すように、ＳＳＭＦマルチフレームを構成するｋ個のＳＳＦフレームは同様の方法で分割され、つまり、各ＳＳＦフレームの２番目からｎ番目のＤブロックとＴブロックによって運ばれるペイロードが、同一サイズのｍ個のタイムスロットｓｌｏｔ１～ｓｌｏｔｍに分割され、合計でｍ×ｋ個のタイムスロットが得られる。

第３の実施形態
第３の実施形態において、ＳＳＦフレームの構造は、ＩＥＥＥ８０２．３のＰＣＳ層の６４／６６Ｂ符号化規格に基づいて定義される。ＳＳＦフレームを構成するＳブロック、Ｄブロック、およびＴブロックの定義は、第２の実施形態で説明した通りである。

いくつかの実施形態において、図１０に示されるように、ステップＳ１２２は、具体的にステップＳ１２２１、ステップＳ１２２２を含む。ステップＳ１２２１において、異なるクライアントサービスの粒度に基づいて、前記複数のタイムスロットにおいて、異なるクライアントサービスをそれぞれ運ぶタイムスロットの位置および数を特定する。ステップＳ１２２２において、異なるクライアントサービスを運ぶタイムスロットの位置と数とに基づいて、異なるクライアントサービスのサービスブロックを、対応するタイムスロットにマッピングする。

本開示の実施形態において、ステップＳ１２１により、ＳＳＦフレームまたはＳＳＭＦマルチフレームのペイロード領域を同一サイズの複数のタイムスロットに分割する場合、異なる数のタイムスロットによって構成されるＳＳＣチャネルの帯域幅も異なる。それに応じて、粒度が異なるクライアントサービスについては、各クライアントサービスを運ぶＳＳＣチャネルを構成するタイムスロットの数も異なる。例えば、図４において、クライアントサービスＣｌｉｅｎｔＡの粒度はクライアントサービスＣｌｉｅｎｔＢの粒度の２倍であり、それに応じて、クライアントサービスＣｌｉｅｎｔＡを運ぶＳＳＣＡチャネルは、ｓｌｏｔ１とｓｌｏｔ２とにより構成され、クライアントサービスＣｌｉｅｎｔＢを運ぶＳＳＣＢチャネルはｓｌｏｔｉにより構成され、ＳＳＣＡチャネルの帯域幅がＳＳＣＢチャネルの帯域幅の２倍である。

本開示の実施形態において、ＳＳＦフレームまたはＳＳＭＦフレームにおいて、異なるクライアントサービスを運ぶＳＳＣチャネルを構成するタイムスロットの位置をどのように決定するかについて、特に限定しない。例えば、各クライアントサービスについて、ＳＳＦフレームまたはＳＳＭＦフレーム内のいくつかの連続するタイムスロットを選択して、当該クライアントサービスを運ぶＳＳＣチャネルを構成する。或いは、各クライアントサービスについて、ＳＳＦフレームまたはＳＳＭＦフレームにおける隣接または非隣接のタイムスロットをいくつか選択して、当該クライアントサービスを運ぶＳＳＣチャネルを構成する。或いは、均一な分配方法により、ＳＳＦフレームまたはＳＳＭＦフレームにおいてタイムスロットをいくつか選択して、クライアントサービスを運ぶＳＳＣチャネルを構成する。

いくつかの実施形態において、図１１に示すように、ステップＳ１３０は、具体的にステップＳ１３１、ステップＳ１３２を含む。ステップＳ１３１において、前記少なくとも１つのＳＳＦフレームのオーバヘッド領域において、各前記クライアントサービスと、各前記クライアントサービスをそれぞれ運ぶタイムスロットとの対応関係を設定する。ステップＳ１３２において、前記少なくとも１つのＳＳＦフレームの他のオーバヘッドフィールドを設定して、前記少なくとも１つのＳＳＦフレームを得る。

第４の実施形態
第４の実施形態において、ＳＳＦフレームの構造は、ＩＥＥＥ８０２．３のＰＣＳ層の６４／６６Ｂ符号化規格に基づいて定義される。ＳＳＦフレームを構成するＳブロック、Ｄブロック、およびＴブロックの定義は、第２の実施形態で説明した通りである。

第４の実施形態において、図１２に示すように、拡張ＳブロックのＤ１～Ｄ７バイト（ｂｉｔ１０～６５）は、オーバヘッドを格納するために使用される。

第５の実施形態
第５の実施形態において、ＳＳＦフレームの構造は、ＩＥＥＥ８０２．３のＰＣＳ層の６４／６６Ｂ符号化規格に基づいて定義される。ＳＳＦフレームを構成するＳブロック、Ｄブロック、およびＴブロックの定義は、第２の実施形態で説明した通りである。第５の実施形態において、拡張ＳブロックおよびＤブロックは、オーバヘッドを格納するために使用される。

第５の実施形態において、図７に示すように、オーバヘッドを格納するために、ＳＳＦフレームにおけるＳブロックと１番目のＤブロックを拡張する。

第５の実施形態において、図８に示すように、オーバヘッドを格納するために、ＳＳＭＦマルチフレームを構成する各ＳＳＦフレームのＳブロックと１番目のＤブロックを拡張する。

なお、本開示の実施形態において、オーバヘッドの、ＳＳＦフレームまたはＳＳＭＦマルチフレームのＳブロック、Ｔブロック、Ｄブロックにおける位置およびサイズは特に限定されない。第１の実施形態、第２の実施形態、第３の実施形態、第４の実施形態および第５の実施形態は、Ｓブロック、Ｔブロック、またはＤブロックを用いてオーバヘッドを運ぶことを例示的に説明するためのものであり、本開示の実施形態を限定するものではない。

本開示の実施形態において、異なるクライアントサービスと、クライアントサービスを運ぶＳＳＣチャネルとは、１対１で対応する。１つの選択可能な実施形態として、各ＳＳＣチャネルに、チャネル識別子ＳＳＣＩＤを付与してもよい。ＳＳＣチャネルを構成するタイムスロットを特定すれば、クライアントサービスとタイムスロットとの対応関係が特定される。

それに応じて、いくつかの実施形態において、図１３に示すように、ステップＳ１３１は、具体的にステップＳ１３１１、ステップＳ１３１２を含む。ステップＳ１３１１において、前記オーバヘッド領域のタイムスロット識別フィールドにクライアントサービスを運ぶタイムスロット情報を設定する。ステップＳ１３１２において、前記オーバヘッド領域のチャネル識別フィールドにクライアントサービスを運ぶＳＳＣチャネル情報を設定する。

なお、前記タイムスロット識別フィールドは、クライアントサービスを運ぶタイムスロットを識別するために用いられる。前記チャネル識別フィールドは、クライアントサービスを運ぶＳＳＣチャネルを識別するために用いられる。

本開示の実施形態において、１つの選択可能な実施例として、タイムスロット識別子はタイムスロット番号であってもよい。なお、ステップＳ１２１において、ＳＳＦフレームを分割して複数のタイムスロットが得られる場合、ＳＳＦフレーム内のタイムスロットに番号を付けて、各タイムスロットのタイムスロット番号を、前記タイムスロット識別子とする。ステップＳ１２１において、複数のＳＳＦフレームからなるＳＳＭＦマルチフレームを分割して複数のタイムスロットが得られる場合、ＳＳＭＦマルチフレームを構成する全てのＳＳＦフレームにおけるタイムスロットに番号を付けて、各タイムスロットのタイムスロット番号を得る。

いくつかの実施形態において、複数のＳＳＦフレームによりＳＳＭＦマルチフレームを構成する場合、図１４に示すように、ステップＳ１３１は、上記のステップＳ１３１１からＳ１３１２に加えて、更にステップＳ１３１３を含む。ステップＳ１３１３において、前記オーバヘッド領域のマルチフレーム指示フィールドに、複数のＳＳＦフレームからなるＳＳＭＦマルチフレームにおけるＳＳＦフレームの位置情報が設定される。

いくつかの実施形態において、前記ＳＳＦフレームのその他のオーバヘッドフィールドには、前記ＳＳＦフレーム構造を示すためのフレームタイプフィールドと、サービス層チャネルの障害状態を示す障害指示フィールドと、クライアントサービスのタイプを識別するためのサービスタイプフィールドと、チェック情報を記憶するためのチェックフィールドとが含まれる。

第６の実施形態
第６の実施形態において、ＳＳＦフレームの構造は、ＩＥＥＥ８０２．３のＰＣＳ層の６４／６６Ｂ符号化規格に基づいて定義される。ＳＳＦフレームを構成するＳブロック、Ｄブロック、およびＴブロックの定義は、第２の実施形態で説明した通りである。

第６の実施形態において、１番目のＤブロックの最初の７バイト、合計５６ビットでオーバヘッドを運ぶ。図１５に示すように、第６の実施形態においてオーバヘッドには、以下のフィールドが含まれる。

フレームタイプフィールドＦｒａｍｅＴｙｐｅ（４ｂｉｔ）：異なるＳＳＦフレーム構造定義を示す。例えば、ＳＳＦフレーム構造をＦｒａｍｅＴｙｐｅ＝０ｘ１として定義する。他のＦｒａｍｅＴｙｐｅタイプのＳＳＦフレーム構造については、実際の状況に応じて定義を拡張してもよい。

障害表示フィールドＲＰＦ／ＲＤＩ（１ｂｉｔ）：サービス層がＥｔｈｅｒｎｅｔＰＨＹである場合、ＲＰＦ（Ｒｅｍｏｔｅ ＰＨＹ Ｆａｕｌｔ）を示す。サービス層がＳＣＬ／ＭＴＮチャネルである場合、ＲＤＩ（Ｒｅｍｏｔｅ Ｄｅｆｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）を表す。１つの選択可能な実施形態として、ローカルサービス層に障害がある場合は、ＲＰＦ／ＲＤＩフィールドを１に設定し、ローカルサービス層に障害がない場合は、ＲＰＦ／ＲＤＩフィールドを１に設定する。

マルチフレーム指示フィールドＭｕｌｔｉＦｒａｍｅＳＮ（１０ｂｉｔ）：ＳＳＦのマルチフレーム内におけるシーケンス番号を示し、１から増加し、循環する。１つの選択可能な実施形態として、ＭｕｌｔｉＦｒａｍｅＳＮは、ＳＳＣＭａｐおよびＣＳ＿ＴｙｐｅＭａｐに対応するタイムスロット番号を示し、即ち、タイムスロット番号＝ＭｕｌｔｉＦｒａｍｅＳＮ。この場合、マルチフレーム内のＳＳＦフレームの数は、タイムスロットの数と同一である。

チャネル識別フィールドＳＳＣＭａｐ（２０ｂｉｔ）：タイムスロットが属するＳＳＣチャネルのＳＳＣＩＤ番号を示し、タイムスロットはＭｕｌｔｉＦｒａｍｅＳＮで示される。

サービスタイプフィールドＣＳ＿ＴｙｐｅＭａｐ（４ビット）：タイムスロットに搭載されるサービスタイプを示し、タイムスロットはＭｕｌｔｉＦｒａｍｅＳＮで示される。１つの選択可能な実施形態として、ＣＳ＿ＴｙｐｅＭａｐの値が次の通り規定される：００００ｂはクライアントサービスが運ばれていないことを示し、０００１ｂは運ばれたクライアントサービスがイーサネットサービスであることを示し、００１０ｂは運ばれたクライアントサービスがＴＤＭサービスであることを示す。

Ｒｅｓｅｒｖｅｄ（１３ｂｉｔ）：保留、全て０である。

チェックフィールドＣＲＣ４（４ｂｉｔ）：ＣＲＣ４チェック情報は、オーバヘッドにおける（ＣＲＣ４を除く）最初の５２ビットをチェックする。アルゴリズムの多項式はＸ４＋Ｘ＋１であり、初期値は０である。ＣＲＣチェック結果の上位ビットはｂｉｔ５３に格納され、最下位ビットはｂｉｔ５６に格納される。ＣＲＣ４は、更に、ＳＳＦフレームの識別に使用可能である。

いくつかの実施形態において、図１６に示すように、前記サービスデータ処理方法は、ステップＳ１１０の後に更にステップＳ１４０を含む。ステップＳ１４０において、同一タイプのクライアントサービスのサービスブロックからなるサービスブロックコードストリームには、操作保守管理（ＯＡＭ）ブロックが挿入される。

なお、サービスブロックコードストリームにＯＡＭブロックが挿入された後、ステップＳ１２０において、クライアントサービスのサービスブロックとＯＡＭブロックをＳＳＦフレームまたはＳＳＭＦマルチフレームにマッピングする。

第７の実施形態
第７の実施形態において、ＳＳＦフレームの構造は、ＩＥＥＥ８０２．３のＰＣＳ層の６４／６６Ｂ符号化規格に基づいて定義される。ＳＳＦフレームを構成するＳブロック、Ｄブロック、およびＴブロックの定義は、第２の実施形態で説明した通りである。

第７の実施形態において、クライアントサービスがパッケージング／符号化されて、６４／６６Ｂブロックコードストリームが生成される。ＳＳＣチャネル内において、サービスコードストリームのフレーム間ギャップ（ＩＰＧ、Ｉｎｔｅｒ Ｐａｃｋｅｔ Ｇａｐ）の位置にＯＡＭブロックが挿入されてもよい。第７の実施形態において、ＯＡＭブロックの挿入／抽出メカニズムとＯＡＭブロックの定義は、ＳＰＮのＳＣＬ ＯＡＭ（またはＭＴＮのＰａｔｈ ＯＡＭ）のメカニズムと定義をそのまま使用してもよい。

いくつかの実施形態において、図１７に示すように、前記サービスデータ処理方法は、ステップＳ１１０の後に更にステップＳ１５０を含む。ステップＳ１５０において、同一タイプのクライアントサービスのサービスブロックからなるサービスブロックコードストリームには、サービスアイドルブロック（Ｉｄｌｅブロック）が挿入される。

なお、前記サービスＩｄｌｅブロックは、クライアントサービスが運ばれていないサービスブロックである。本開示の実施形態では、クライアントサービスの速度とタイムスロットの速度とを適合させるよう、前記サービスＩｄｌｅブロックを追加または削除してもよい。

なお、サービスブロックコードストリームにサービスＩｄｌｅブロックが挿入された後、ステップＳ１２０において、クライアントサービスのサービスブロックとＯＡＭブロックをＳＳＦフレームまたはＳＳＭＦマルチフレームにマッピングする。

いくつかの実施形態において、図１８に示すように、前記サービスデータ処理方法は、ステップＳ１３０の後に更にステップＳ１６０を含む。ステップＳ１６０において、ＳＳＦフレームの速度とサービス層ポートの速度に応じて、隣接する前記ＳＳＦフレームの間にフレーム間Ｉｄｌｅブロックが挿入される。

第８の実施形態
第８の実施形態において、ＳＳＦフレームの構造は、ＩＥＥＥ８０２．３のＰＣＳ層の６４／６６Ｂ符号化規格に基づいて定義される。ＳＳＦフレームを構成するＳブロック、Ｄブロック、およびＴブロックの定義は、第２の実施形態で説明した通りである。

第８の実施形態において、ＳＳＦフレーム構造の定義に準拠するＳブロック＋Ｄブロック＋ＴブロックをＳＳＦブロックと呼ぶ。図１９に示すように、第８の実施形態において、ＳＳＣチャネルのデータストリームは、ＳＳＦブロックとフレーム間Ｉｄｌｅブロックとで構成される。図１９において、Ｉブロックはフレーム間Ｉｄｌｅブロックである。第８の実施形態において、フレーム間Ｉｄｌｅブロックのブロックタイプは０ｘ１Ｅであり、ＳＳＦブロック間に０以上のフレーム間Ｉｄｌｅブロックが存在してもよい。ＳＳＦフレームのレートと、サービス層のレートとのマッチングは、ＳＳＣチャネルにおけるフレーム間Ｉｄｌｅブロックを追加または削除することによって行われてもよい。

いくつかの実施形態において、本開示の実施形態に係る前記ＳＳＦフレームは、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂブロックからなる。

いくつかの実施形態において、前記ＳＳＦフレームには、スタートブロックと、少なくとも１つのデータブロックと、ターミネートブロックとが含まれる。また、前記ＳＳＦフレームのフレーム長さは固定である。

ＳＳＦフレームおよびＳＳＦフレームにおけるスタートブロック、データブロック、ターミネートブロックなどの定義については、第２の実施形態が参照され、ここでは詳細な説明を繰り返しない。

いくつかの実施形態において、前記サービスデータ処理方法は、前記データブロックおよび／または前記ターミネートブロックに、ＳＳＦフレームのペイロードを運ぶことと、在前記スタートブロック、前記データブロック、および前記ターミネートブロックの内の少なくとも１つに、ＳＳＦフレームのオーバヘッドを運ぶこととを更に含む。

前記スタートブロック、前記データブロック、および前記ターミネートブロックの内の少なくとも１つに、ＳＳＦフレームのオーバヘッドを運ぶ具体的な実施形態は、第２の実施形態～第５の実施形態が参照され、ここでは詳細な説明を繰り返しない。

上記のように、本開示の実施形態において、クライアントサービスはイーサネットサービスであってもよいし、ＴＤＭサービスであってもよい。

それに応じて、いくつかの実施形態において、前記クライアントサービスはイーサネットサービスを含む。

なお、イーサネットサービスは、ＩＥＥＥ８０２．３のＰＣＳにより符号化されると、６４／６６Ｂブロックコードストリームが形成される。

いくつかの実施形態において、イーサネットサービスのコードストリームにおける６４／６６Ｂブロックは、そのままステップＳ１１０におけるサービスブロックとする。また、ステップＳ１２０において、異なるクライアントサービスのイーサネットサービスブロックを、少なくとも１つの前記ＳＳＦフレームにマッピングする。

いくつかの実施形態において、ステップＳ１１０において、前記サービスブロックを生成するよう、クライアントサービスのイーサネットサービスブロックを圧縮してトランスコードする。

第９の実施形態
第９の実施形態において、２５６／２５７Ｂ符号化を利用して、イーサネットサービスの６４／６６Ｂブロックを圧縮しトランスコードして、イーサネットサービスのサービスブロックを生成する。

第９の実施形態において、６４／６６Ｂ符号化から２５６／２５７Ｂ符号化へのトランスコーディング方式は、ＩＥＥＥ８０２．３規格に準拠する。つまり、４つの６４／６６Ｂブロックは１つの２５６／２５７Ｂブロックに圧縮しトランスコードされる。

第１０の実施形態
第１０の実施形態において、６５Ｂ符号化を利用して、イーサネットサービスの６４／６６Ｂブロックを圧縮しトランスコードして、イーサネットサービスのサービスブロックを生成する。

第１０の実施形態において、６４／６６Ｂブロックを６５Ｂブロックに圧縮しトランスコードする場合、６４／６６Ｂブロックのシンクヘッダーの２ビットを１ビットに圧縮する。例えば、６４／６６Ｂブロックのシンクヘッダーの１番目のビットのみを取得し、２番目のビットを削除してもよい。或いは、６４／６６Ｂブロックのシンクヘッダーの２番目のビットのみを取得し、１番目のビットを削除してもよい。

いくつかの実施形態において、前記クライアントサービスは、時分割多重ＴＤＭサービスを含む。

第１１の実施形態
標準化団体メトロ・イーサネット・フォーラム（ＭＥＦ：ＭｅｔｒｏＥｔｈｅｒｎｅｔＦｏｒｕｍ）が発行する「ＭＥＦ ８ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ Ａｇｒｅｅｍｅｎｔ ｆｏｒ ｔｈｅ Ｅｍｕｌａｔｉｏｎ ｏｆ ＰＤＨ Ｃｉｒｃｕｉｔｓ ｏｖｅｒ Ｍｅｔｒｏ Ｅｔｈｅｒｎｅｔ Ｎｅｔｗｏｒｋｓ」規格に規定されているイーサネット回線エミュレーションサービス（ＣＥＳｏＥＴＨ、Ｃｉｒｃｕｉｔ Ｅｍｕｌａｔｉｏｎ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ）に基づいて、ＴＤＭサービスをイーサネットパケットにマッピングし、パッケージングする。第９の実施形態または第１０の実施形態に従って、ＴＤＭサービスがパッケージングされたイーサネットパケットからＴＤＭサービスのサービスブロックを生成する。

第１２の実施形態
一定レートのＴＤＭサービスのビットストリームを、サービスバイトまたはビットによってそのままパッケージングし符号化して、ＴＤＭサービスのサービスブロックとしてＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂブロックを生成する。

いくつかの実施形態において、図２０に示すように、前記サービスデータ処理方法は、上記のステップＳ１１０～ステップＳ１３０に加えて、ステップＳ１７０をさらに含む。ステップＳ１７０において、サービス層を介してＳＳＦフレームを伝送するよう、前記ＳＳＦフレームに対してサービス層処理を行う。

いくつかの実施形態において、前記サービス層は、ＩＥＥＥ８０２．３イーサネットポートの物理層（Ｅｔｈｅｒｎｅｔ ＰＨＹ）、スライシング・パケット・ネットワーク（ＳＰＮ）、メトロポリタンエリアトランスポートネットワーク（ＭＴＮ）、フレキシブルイーサネット（ＦｌｅｘＥ）、および光トランスポートネットワーク（ＯＴＮ）のいずれか１つを含む。

前記サービス層がＩＥＥＥ８０２．３イーサネットポートの物理層（ＰＨＹ、Ｐｙｈｓｉｃａｌ）である場合、つまり、ソースＰＥノードがＩＥＥＥ８０２．３イーサネットＰＨＹを介してデータを送信する場合、ステップＳ１７０において、具体的に、ＳＳＦフレームは、ＩＥＥＥ８０２．３Ｐｈｙｓｉｃａｌ Ｃｏｄｉｎｇ Ｓｕｂｌａｙｅｒ（ＰＣＳ、Ｐｈｙｓｉｃａｌ Ｃｏｄｉｎｇ Ｓｕｂｌａｙｅｒ）によって６４／６６Ｂブロックの形式でスクランブルされ、配布され、物理媒体アダプテーション層（ＰＭＡ）、物理媒体関連層インターフェイス（ＰＭＤ）を介して、イーサネットポートから送信される。

前記サービス層がスライシング・パケット・ネットワーク（ＳＰＮ）、メトロポリタンエリアトランスポートネットワーク（ＭＴＮ）、フレキシブルイーサネット（ＦｌｅｘＥ）、または光トランスポートネットワーク（ＯＴＮ）の場合、ステップＳ１７０において、ＳＳＦフレームは、対応するサービス層処理が行われた後に送信される。

図２１を参照して、本開示の実施形態の第２方面は、サービスデータ交換方法を提供する。このサービスデータ交換方法は、ステップＳ２１０、ステップＳ２２０、ステップＳ２３０を含む。ステップＳ２１０において、インバウンドポートにより受信されたインバウンドＳＳＦフレーム内の各サービスブロックのアウトバウンドポートを特定する。ここで、各インバウンドＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ。ステップＳ２２０において、同一のアウトバウンドポートに対応するサービスブロックを少なくとも１つのアウトバウンドＳＳＦフレームにマッピングする。ここで、各アウトバウンドＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ。ステップＳ２３０において、アウトバウンドポートを介して前記アウトバウンドＳＳＦフレームを送信する。

なお、プロバイダ交換デバイス（ｐｒｏｖｉｄｅｒ、Ｐノードとも称す）において、ＳＳＦフレームを受信するポートがインバウンドポートであり、ＳＳＦフレームを送信するポートがアウトバウンドポートである。それに応じて、前記インバウンドポートにより受信されたＳＳＦフレームはインバウンドＳＳＦフレームであり、前記アウトバウンドポートにより送信されたＳＳＦフレームはアウトバウンドＳＳＦフレームである。

本開示の実施形態において、Ｐノードのインバウンドポートにより受信されたインバウンドＳＳＦフレームには、複数の異なるクライアントサービスのサービスブロックが運ばれており、異なるクライアントサービスは異なるアウトバウンドポートに対応する。Ｐノードにおいて、インバウンドＳＳＦフレームにおける各クライアントサービスのサービスブロックを対応するアウトバウンドポートに送信して、アウトバウンドポートにおいて、異なるクライアントサービスのサービスブロックを改めてアウトバウンドＳＳＦフレームにマッピングし、組み込んで、該アウトバウンドポートから前記アウトバウンドＳＳＦフレームを送信する。なお、各アウトバウンドＳＳＦフレームには、それぞれ異なるクライアントサービスが運ばれている。

なお、インバウンドポートは、複数のインバウンドＳＳＦフレームからなるインバウンドＳＳＭＦマルチフレームを受信してもよい。アウトバウンドポートにおいて、複数のアウトバウンドＳＳＦフレームでアウトバウンドＳＳＭＦマルチフレームを構成し、異なるクライアントサービスのサービスブロックをＳＳＭＦマルチフレームにマッピングしてもよい。

本開示の実施形態に係るサービスデータ交換方法は、複数の異なるクライアントサービスを運ぶ可能なＳＳＦフレーム、または複数のＳＳＦフレームからなるＳＳＭＦマルチフレームに基づいて、Ｐノードのインバウンドポートとアウトバウンドポートの間で異なるクライアントサービスの交換を行うことにより、異なるクライアントサービスを運ぶＳＳＣチャネルを確立し、異なる粒度のクライアントサービスを同時に伝送することができる。本開示の実施形態に係るサービスデータ交換方法は、異なる粒度のサービスのリジッドチャネルでの送信を実現し、低遅延、低ジッター、ハードイソレーション、異なる帯域幅の伝送要件を満たし、クライアントサービスの最小粒度が、従来のＦｌｅｘＥ、ＳＰＮ、ＭＴＮ等の規格により制限されることがなくなる。また、複数のイーサネットサービス、または／およびＴＤＭサービスを同時にサポートすることができ、サービスのレートが柔軟である。さらに、ＳＰＮ、ＭＴＮ、イーサネット、ＯＴＮ等のうちのいずれか１つをサービス層として、ＳＳＦフレームを送信可能であり、Ｅｔｈｅｒｎｅｔ、ＦｌｅｘＥ、ＳＰＮ、ＭＴＮ、ＯＴＮなどの既存の標準システムとの良好な互換性を実現する。

１つの選択可能な実施形態として、本開示の実施形態において、タイムスロットスケジューリングの方式を利用して、Ｐノードにおいて、インバウンドＳＳＭＦフレームにおけるタイムスロットからアウトバウンドＳＳＦフレームにおけるタイムスロットまで、またはインバウンドＳＳＭＦマルチフレームにおけるタイムスロットからアウトバウンドＳＳＭＦマルチフレームにおけるタイムスロットまでのタイムスロット交差を行ってもよい。

それに応じて、図２２に示すように、ステップＳ２１０は、具体的に、ステップＳ２１１を含む。ステップＳ２１１において、インバウンドポートにより受信された異なるインバウンドタイムスロットにおけるサービスブロックのアウトバウンドポートを特定する。ここで、前記インバウンドスロットは、少なくとも１つのインバウンドＳＳＦフレームにおけるタイムスロットである。また、ステップＳ２２０は、具体的に、ステップＳ２２１を含む。ステップＳ２２１において、同一のアウトバウンドポートに対応する異なるインバウンドタイムスロットにおけるサービスブロックを、それぞれ、異なるアウトバウンドタイムスロットにマッピングする。ここで、前記アウトバウンドタイムスロットは、少なくとも１つのアウトバウンドＳＳＦフレームにおけるタイムスロットである。

図２３は、Ｐノードでのタイムスロット交差の一つの選択可能な実施形態を示す。

図２３において、Ｐノードには２つのインバウンドポートＳＳＣＳＩ１およびＳＳＣＳＩ２と、２つのアウトバウンドポートＳＳＣＳＩ３およびＳＳＣＳＩ４とが備えられる。ＳＳＣＳＩ１によって受信されたインバウンドＳＳＦフレームにおけるタイムスロットは、一部がＳＳＣＳＩ３におけるアウトバウンドＳＳＦフレームの一部のタイムスロットに対応し、他の一部が、ＳＳＣＳＩ４におけるアウトバウンドＳＳＦフレームの一部のタイムスロットに対応する。同様に、ＳＳＣＳＩ２により受信されたインバウンドＳＳＦフレームのタイムスロットは、一部がＳＳＣＳＩ３におけるアウトバウンドＳＳＦフレームの一部のタイムスロットに対応し、他の一部がＳＳＣＳＩ４におけるアウトバウンドＳＳＦフレームの一部のタイムスロットに対応する。

１つの選択可能な実施形態として、本開示の実施形態において、Ｐノードには、異なるインバウンドポートにおけるインバウンドＳＳＦフレームまたはインバウンドＳＳＭＦフレームのタイムスロットと、異なるアウトバウンドポートにおけるアウトバウンドＳＳＦフレームまたはアウトバウンドＳＳＭＦフレームのタイムスロットとの対応関係が格納されている。

それに応じて、いくつかの実施形態において、図２４に示すように、ステップＳ２１１は、具体的に、ステップＳ２１１１を含む。ステップＳ２１１１において、各インバウンドタイムスロットと各アウトバウンドタイムスロットとの対応関係が格納されているタイムスロット交差構成テーブルに従って、インバウンドポートにより受信された異なるインバウンドタイムスロットにおけるサービスブロックのアウトバウンドポートを特定する。

なお、本開示の実施形態において、タイムスロット交差構成テーブルは、ネットワークマネージャー、ソフトウェア定義ネットワーク（ＳＤＮ：Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋ）コントローラ、または動的プロトコルによって予め構成してもよい。

本開示の実施形態において、Ｐノードの各アウトバウンドポートと各インバウンドポートとのレートはわずかな差（２００ｐｐｍ以下）が存在する場合がある。１つの選択可能な実施例として、送信方向において、ＳＳＦフレームまたはＳＳＭＦマルチフレームの各タイムスロットにおけるサービスＩｄｌｅブロックを追加または削除して、各インバウンドポートのタイムスロットから各アウトバウンドポートのタイムスロットへのレートマッチングを実現してもよい。

それに応じて、いくつかの実施形態において、図２５に示すように、前記サービスデータ交換方法は、ステップＳ２１１～ステップＳ２２１に加えて、ステップＳ２４１および／またはステップＳ２４２をさらに含む。ステップＳ２４１において、ローカルシステムクロックとアウトバウンドタイムスロットのレートに基づき、同一のアウトバウンドタイムスロットにおけるサービスブロックで構成されるサービスブロックコードストリーム内のサービスＩｄｌｅブロックを追加または削除する。ステップＳ２４２において、ローカルシステムクロックとインバウンドタイムスロットのレートに基づき、同一のインバウンドタイムスロットにおけるサービスブロックで構成されるサービスブロックコードストリーム内のサービスＩｄｌｅブロックを追加または削除する。

なお、本開示の実施形態において、ステップＳ２４１のみを実行し、ステップＳ２４２を実行しなくてもよい。また、ステップＳ２４２のみを実行し、ステップＳ２４１を実行しなくてもよい。或いは、ステップＳ２４１およびステップＳ２４２を両方とも実行してもよい。例えば、アウトバウンドタイムスロットにおけるクライアントサービスのレートとアウトバウンドタイムスロットのレートとをマッチングする必要がある場合、ステップＳ２４１を実行する。インバウンドタイムスロットにおけるクライアントサービスのレートとインバウンドタイムスロットのレートとをマッチングする必要がある場合、ステップＳ２４２を実行する。インバウンドタイムスロットにおけるクライアントサービスのレートとインバウンドタイムスロットのレートとのマッチング、アウトバウンドタイムスロットにおけるクライアントサービスのレートとアウトバウンドタイムスロットのレートとのマッチングの必要がある場合、ステップＳ２４１およびステップＳ２４２を両方とも実行する。また、本開示は、ステップＳ２４１および／またはステップＳ２４２の実行順を特に限定しない。

本開示の実施形態において、アウトバウンドＳＳＦフレームのレートとアウトバウンドポートのレートにわずかな差が存在する場合がある。一つの選択可能な実施形態として、ＳＳＦフレーム間にフレーム間Ｉｄｌｅブロックが挿入されて、ＳＳＦフレームのレートとサービス層のレートとのマッチングを行ってもよい。

それに応じて、いくつかの実施形態において、図２６に示すように、前記サービスデータ交換方法は、ステップＳ２１１～ステップＳ２２１に加えて、ステップＳ２５１および／またはステップＳ２５２をさらに含む。ステップＳ２５１において、ローカルシステムクロックとアウトバウンドポートのレートとに基づいて、同一のアウトバウンドポートにおけるアウトバウンドＳＳＦフレーム間にフレーム間Ｉｄｌｅブロックを追加または削除する（ステップＳ２５１）。ステップＳ２５２において、ローカルシステムクロックとインバウンドポートのレートとに基づいて、同一のインバウンドポートにおけるインバウンドＳＳＦフレーム間にフレーム間Ｉｄｌｅブロックを追加または削除する。

なお、本開示の実施形態において、ステップＳ２５１のみを実行し、ステップＳ２５２を実行しなくてもよい。また、ステップＳ２５２のみを実行し、ステップＳ２５１を実行しなくてもよい。さらに、ステップＳ２５１およびステップＳ２５２を両方とも実行してもよい。例えば、アウトバウンドポートにおけるＳＳＦフレームのレートとアウトバウンドポートのレートとをマッチングする必要がある場合、ステップＳ２５１を実行する。インバウンドポートにおけるＳＳＦフレームのレートとインバウンドポートのレートとをマッチングする必要がある場合、ステップＳ２５２を実行する。インバウンドポートのＳＳＦフレームのレートとインバウンドポートのサービス層レートとのマッチング、アウトバウンドポートのＳＳＦフレームのレートとアウトバウンドポートのサービス層レートとのマッチングの必要がある場合、ステップＳ２５１およびステップＳ２５２を両方とも実行する。また、本開示は、ステップＳ２５１および／またはステップＳ２５２の実行順を特に限定しない。

いくつかの実施形態において、前記インバウンドポート、および／または、前記アウトバウンドポートはイーサネットポート、スライスチャネル層ＳＣＬポート、ＭＴＮパスチャネルポート、ＦｌｅｘＥクライアントポート、およびＯＴＮのＯＤＵｋインターフェイスの内のいずれか１つを含む。

参照図２７を参照して、本開示の実施形態の第３方面は、サービスデータ抽出方法を提供する。このサービスデータ抽出方法は、ステップＳ３１０、ステップＳ３２０を含む。ステップＳ３１０において、少なくとも１つのＳＳＦフレームから所定のクライアントサービスのサービスブロックを抽出する。ここで、各前記ＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ。ステップＳ３２０において、前記所定のクライアントサービスのサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出する。

なお、本開示の実施形態において、前記所定のクライアントサービスは、ソースＰＥノードによって現在のシンクＰＥノードに送信されるクライアントサービスである。シンクＰＥノードは、ＳＳＦフレームまたはＳＳＭＦマルチフレームを受信すると、ＳＳＦフレームまたはＳＳＭＦマルチフレームから前記所定のクライアントサービスのサービスブロックを抽出し、前記所定のクライアントサービスのサービスブロックを復号化して、クライアントサービスのサービスデータを抽出する。

なお、シンクＰＥノードで所定のクライアントサービスのサービスブロックを復号化することは、ソースＰＥノードでクライアントサービスに従ってサービスブロックを生成することの逆のプロセスである。

本開示の実施形態に係るサービスデータ抽出方法によれば、複数の異なるクライアントサービスを運ぶ可能なＳＳＦフレーム、または複数の ＳＳＦフレームからなるＳＳＭＦマルチフレームから所定のクライアントサービスを抽出し、ソースＰＥノードからシンクＰＥノードまでのＳＳＣチャネルを確立し、異なる粒度のクライアントサービスに対応するＳＳＣチャネルの帯域幅が異なる。本開示の実施形態に係るサービスデータ抽出方法は、異なる粒度のサービスのリジッドチャネルでの送信を実現し、低遅延、低ジッター、ハードイソレーション、異なる帯域幅の伝送要件を満たし、クライアントサービスの最小粒度が従来のＦｌｅｘＥ、ＳＰＮ、ＭＴＮ等の規格により制限されることがなくなる。また、複数のイーサネットサービス、または／およびＴＤＭサービスを同時にサポートすることができ、サービスのレートが柔軟である。さらに、ＳＰＮ、ＭＴＮ、イーサネット、ＯＴＮ等のうちのいずれか１つをサービス層としてＳＳＦフレームを送信可能であり、イーサネット、ＦｌｅｘＥ、ＳＰＮ、ＭＴＮ、ＯＴＮなどの既存の標準システムとの良好な互換性を実現する。

１つの選択可能な実施例として、本開示の実施形態において、シンクＰＥノードは、タイムスロットスケジューリングの方式により、ＳＳＦフレームまたはＳＳＭＦマルチフレームのタイムスロットから所定のクライアントサービスのサービスブロックを抽出してもよい。

それに応じて、いくつかの実施形態において、図２８に示すように、ステップＳ３１０は、具体的には、ステップＳ３１１を含む。ステップＳ３１１において、ＳＳＦフレームの所定のタイムスロットから所定のクライアントサービスのサービスブロックを抽出する。ここで、前記所定のタイムスロットは、少なくとも１つのＳＳＦフレーム内の所定のクライアントサービスを運ぶタイムスロットである。

いくつかの実施形態において、図２９に示すように、ステップＳ３１１に次いで、前記サービスデータ抽出方法は、ステップＳ３１２をさらに含む。ステップＳ３１２において、前記所定のタイムスロットから抽出されたＯＡＭブロックを分離させる。

上記のように、本開示の実施形態において、前記クライアントサービスはイーサネットサービスであってもよいし、ＴＤＭサービスであってもよい。

それに応じて、いくつかの実施形態において、前記所定のクライアントサービスは、イーサネットサービスを含む。

いくつかの実施形態において、ソースＰＥノードは、イーサネットサービスのコードストリーム内の６４／６６Ｂブロックを、所定のサービスのサービスブロックとする場合、ステップＳ３２０において、前記所定のクライアントサービスの、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出する。

いくつかの実施形態において、ソースＰＥノードは、前記所定のクライアントサービスのイーサネットサービスブロックを圧縮しトランスコードして、前記所定のクライアントサービスのサービスブロックを生成する。この場合、前記所定のクライアントサービスのサービスブロックをＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックに解凍し、６４／６６Ｂイーサネットサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出する必要がある。

第１３の実施形態
第１３の実施形態において、ソースＰＥノードは、２５６／２５７Ｂ符号化を利用してイーサネットサービスの６４／６６Ｂブロックを圧縮しトランスコードして、前記所定のクライアントサービスのサービスブロックを生成する。それに応じて、シンクＰＥノードにおいて、２５６／２５７Ｂ符号化を利用して、前記所定のクライアントサービスのサービスブロックを前記６４／６６Ｂイーサネットサービスブロックに解凍する。

２５６／２５７Ｂ符号化から６４／６６Ｂ符号化へのトランスコーディング方式は、ＩＥＥＥ８０２．３規格に準拠する。つまり、１つの２５６／２５７Ｂブロックは、解凍しトランスコードされて４つの６４／６６Ｂブロックになる。

第１４の実施形態
第１４の実施形態において、ソースＰＥノードは、６５Ｂ符号化を利用して、イーサネットサービスの６４／６６Ｂブロックを圧縮しトランスコードして、前記所定のクライアントサービスのサービスブロックを生成する。それに応じて、シンクＰＥノードにおいて、６５Ｂ符号化を利用して、前記所定のクライアントサービスのサービスブロックを前記６４／６６Ｂイーサネットサービスブロックに解凍する。

なお、ソースＰＥノードにおいて、６４／６６Ｂブロックを６５Ｂブロックに圧縮しトランスコードするときに、６４／６６Ｂブロックのシンクヘッダーにおける１番目のビットを削除した場合、第１４の実施形態において、６５Ｂブロックのシンクヘッダーの１番目のビットの前に１ビットを新たに追加する。ソースＰＥノードにおいて、６４／６６Ｂブロックを６５Ｂブロックに圧縮しトランスコードするときに、６４／６６Ｂブロックのシンクヘッダーにおける２番目のビットを削除した場合、第１４の実施形態において、６５Ｂブロックのシンクヘッダーの１番目のビットの後に１ビットを新たに追加する。

いくつかの実施形態において、前記所定のクライアントサービスは、時分割多重ＴＤＭサービスを含む。

第１５の実施形態
第１５の実施形態において、ソースＰＥノードは、標準化団体メトロ・イーサネット・フォーラム（ＭＥＦ：ＭｅｔｒｏＥｔｈｅｒｎｅｔＦｏｒｕｍ）が発行する「ＭＥＦ ８ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ Ａｇｒｅｅｍｅｎｔ ｆｏｒ ｔｈｅ Ｅｍｕｌａｔｉｏｎ ｏｆ ＰＤＨ Ｃｉｒｃｕｉｔｓ ｏｖｅｒ Ｍｅｔｒｏ Ｅｔｈｅｒｎｅｔ Ｎｅｔｗｏｒｋｓ」規格に規定されているイーサネット回線エミュレーションサービス（ＣＥＳｏＥＴＨ、Ｃｉｒｃｕｉｔ Ｅｍｕｌａｔｉｏｎ Ｓｅｒｖｉｃｅｓ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ）に基づいて、ＴＤＭサービスをイーサネットパケットにマッピングし、パッケージングすると共に、第９の実施形態または第１０の実施形態に従って、前記所定クライアントサービスのサービスブロックを生成する。それに応じて、シンクＰＥノードにおいて、ＣＥＳｏＥＴＨに従って、前記所定のクライアントサービスのサービスブロックをＴＤＭサービスコードストリームにデマッピングして、前記ＴＤＭサービスコードストリームから前記所定のクライアントサービスのサービスデータを抽出する。

第１６の実施形態
第１６の実施形態において、ソースＰＥノードは、一定レートのＴＤＭサービスのビットストリームを、サービスバイトまたはビットによってそのままパッケージングし符号化して、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂブロックを生成して前記所定クライアントサービスのサービスブロックとする。それに応じて、シンクＰＥノードにおいて、ＩＥＥＥ８０２．３符号化規格に従って、前記６４／６６ＢブロックをＴＤＭサービスコードストリームに復号化して、前記ＴＤＭサービスコードストリームから前記所定のクライアントサービスのサービスデータを抽出する。

第１７の実施形態
第１７の実施形態において、図３０に示すように、サービス層はイーサネットであり、イーサネットリンクとＰノードのＳＳＣ層のタイムスロット交差により、粒度が柔軟であるサービスを運ぶ可能なエンドツーエンドのＳＳＣチャネル、即ち、図３０におけるＳｕｂ Ｓｌｉｃｉｎｇ Ｃｈａｎｎｅｌを確立する。図３０に示すように、ソースＰＥノードとＰノードとの間、およびシンクＰＥノードとＰノードとの間は、いずれも標準のイーサネット接続（１０ＧＥなど）である。この２つのイーサネット接続で伝送されるクライアントサービスは、ＰノードにおいてＳＳＣタイムスロット交差により、ＰＥソースノードからＰＥシンクノードまでのエンドツーエンドのＳＳＣチャネルが形成される。

第１８の実施形態
第１８の実施形態において、図３１に示すように、サービス層はＳＰＮであり、ＳＰＮにより提供されるスライシングチャネル接続と、Ｐ３ノードのＳＳＣ層のタイムスロット交差とにより、粒度が柔軟であるサービスを運ぶ可能なエンドツーエンドのＳＳＣチャネル、即ち、図３１におけるサブスライシングチャネル１～５が確立される。図３１に示すように、ＰノードＰ２とＰ４のＳＣＬ交差により、ＳＳＣチャネルのサービス層チャネルＳｌｉｃｉｎｇ Ｃｈａｎｎｅｌ １－３とＳｌｉｃｉｎｇ Ｃｈａｎｎｅｌ ３－５とが形成される。この２つのＳＣＬチャネルにおいて、クライアントサービスＣｌｉｅｎｔ Ｓｅｒｖｉｃｅ Ａを運ぶＳＳＣチャネルは、Ｐ３ノードにおいてタイムスロット交差により、ＰＥ１ノードからＰＥ５ノードまでの、クライアントサービスＡを運ぶエンドツーエンドのＳＳＣチャネル、即ち、図３１におけるサブスライシングチャネル１～５が形成される。

Ｐ２ノードとＰ４ノードのＳＰＮ ＳＣＬ層のＳＣＬ交差の場合、ＳＳＦフレームは標準のＳ＋Ｄ＋Ｔ構造であるため、ＳＣＬ（またはＭＴＮ Ｐａｔｈ）にとっては、ＳＳＦフレームそのものがサービスデータであり、ＳＣＬ（またはＭＴＮ Ｐａｔｈ）はＳＳＦフレームを感知する必要はなく、そのままＳＣＬ（またはＭＴＮ Ｐａｔｈ）交差を完了する。Ｐ２ノードまたはＰ４ノードのＳＣＬ（またはＭＴＮ Ｐａｔｈ）交差方式は、図３２に示す通りである。

さらに、Ｐ２ノードとＰ４ノードは、ＳＣＬ（またはＭＴＮ Ｐａｔｈ）交差のみを行い、ＳＳＦフレームを感知する必要がないため、従来のＳＰＮデバイスであればよい。一方、ＰＥ１ノード、Ｐ３ノード、およびＰＥ５ノードはＳＳＣチャネルをサポートするデバイスである。したがって、第１４の実施形態も、ＳＳＣチャネルをサポートするデバイスと従来のＳＰＮデバイスとが互いに通信するシナリオである。

本開示の実施形態の第４方面は、プロバイダエッジデバイス（ＰＥ）を提供する。このプロバイダエッジデバイス（ＰＥ）は、１つ以上のプロセッサ１０１と、１つ以上のプログラムが格納され、前記１つ以上のプログラムが前記１つ以上のプロセッサにより実行されると、前記１つ以上のプロセッサに上記いずれか１つのサービスデータ交換方法を実現させるメモリ１０２と、前記プロセッサとメモリとの間に接続され、前記プロセッサと記憶装置との情報通信が行われるように配置される１つ以上のＩ／Ｏインターフェース１０３とを備える。

ここで、プロセッサ１０１は、データを処理する能力を有するデバイスであり、中央処理ユニット（ＣＰＵ）などを含むがこれに限定されない。メモリ１０２は、データを記憶する能力を有するデバイスであり、ランダムアクセスメモリ（ＲＡＭ、より具体的にはＳＤＲＡＭ、ＤＤＲなど）、読み取り専用メモリ（ＲＯＭ）、電気的に消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ （ＦＬＡＳＨ）を含むが、これらに限定されない。Ｉ／Ｏインターフェース（読み書きインターフェース）１０３は、プロセッサ１０１とメモリ１０２との間に接続され、プロセッサ１０１とメモリ１０２との情報通信を実現することができ、データバス（Ｂｕｓ）を含むがこれに限定されない。

いくつかの実施形態において、プロセッサ１０１、メモリ１０２、およびＩ／Ｏインターフェース１０３は、バス１０４を介して互いに接続され、さらにコンピューティングデバイスの他の構成要素に接続される。

なお、前記ＰＥデバイスは、データを送信する場合、ソースＰＥノードとして機能し、データを受信する場合、シンクＰＥノードとして機能する。

前記サービスデータ処理方法および前記サービスデータ抽出方法は、上記において詳細に説明したため、ここでは繰り返さない。

図３４を参照して、本開示の実施形態の第５方面は、プロバイダ交換デバイスを提供する。このプロバイダ交換デバイスは、１つ以上のプロセッサ２０１と、１つ以上のプログラムが格納され、前記１つ以上のプログラムが前記１つ以上のプロセッサにより実行されると、前記１つ以上のプロセッサに上記いずれか１つのサービスデータ交換方法を実現させるメモリ２０２と、前記プロセッサとメモリとの間に接続され、前記プロセッサとメモリとの情報通信が行われるように配置される１つ以上のＩ／Ｏインターフェース２０３とを備える。

ここで、プロセッサ２０１は、データを処理する能力を有するデバイスであり、中央処理ユニット（ＣＰＵ）などを含むがこれに限定されない。メモリ２０２は、データを記憶する能力を有するデバイスであり、ランダムアクセスメモリ（ＲＡＭ、より具体的にはＳＤＲＡＭ、ＤＤＲなど）、読み取り専用メモリ（ＲＯＭ）、電気的に消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ（ＦＬＡＳＨ）を含むが、これらに限定されない。Ｉ／Ｏインターフェース（読み書きインターフェース）２０３は、プロセッサ２０１とメモリ２０２との間に接続され、プロセッサ２０１とメモリ２０２との情報通信を実現することができ、データバス（Ｂｕｓ）を含むがこれに限定されない。

いくつかの実施形態において、プロセッサ２０１、メモリ２０２、およびＩ／Ｏインターフェース２０３は、バス２０４を介して互いに接続され、さらにコンピューティングデバイスの他の構成要素に接続される。

前記サービスデータ交換方法について、上記において詳細に説明したため、ここでは繰り返さない。

図３５を参照して、本開示の実施形態の第６方面は、コンピュータ可読媒体を提供する。このコンピュータ可読媒体には、コンピュータプログラムが記憶され、前記プログラムがプロセッサによって実行されると、上記いずれか１つのサービスデータ処理方法、上記いずれか１つのサービスデータ交換方法、または上記いずれか１つのサービスデータ抽出方法を実現させる。前記コンピュータ可読媒体は、ランダムアクセスメモリ（ＲＡＭ、より具体的にはＳＤＲＡＭ、ＤＤＲなど）、読み取り専用メモリ（ＲＯＭ）、電気的に消去可能なプログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ（ＦＬＡＳＨ）を含むが、これらに限定されない。

前記サービスデータ処理方法、前記サービスデータ抽出方法、および前記サービスデータ交換方法について、上記において詳細に説明したため、ここでは繰り返さない。

上記にて開示された方法における全てまたは一部のステップ、システム、デバイスにおける機能モジュール／ユニットが、ソフトウェア、ファームウェア、ハードウェア、およびそれらの適切な組み合わせとして実装され得ることは、当業者が理解することができる。ハードウェアの場合、上記の説明で言及された機能モジュール／ユニット間の分割は、必ずしも物理コンポーネントの分割に対応するわけではない。例えば、１つの物理コンポーネントが複数の機能を持ってもよい。或いは、複数の物理コンポーネントが協力して、１つの機能またはステップを実行してもよい。一部または全ての物理コンポーネントは、中央処理ユニット、デジタル信号プロセッサ、またはマイクロプロセッサなどのプロセッサによって実行されるソフトウェアとして実施されてもよい。或いは、ハードウェア、または特定用途向け集積回路などの集積回路として実施されてもよい。このようなソフトウェアは、コンピュータ記憶媒体（または非一時的媒体）および通信媒体（または一時的媒体）を含むコンピュータ可読媒体上で配布されてもよい。当業者が周知のように、コンピュータ記憶媒体という用語は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための任意の方法または技術で実施される揮発性および不揮発性媒体、リムーバブルおよび非リムーバブル媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはその他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）またはその他の光ディスクストレージ、磁気カートリッジ、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、または所望の情報を記憶し、コンピュータからアクセスできるその他の媒体を含むが、これらに限定されない。また、通信媒体は通常、コンピュータ可読命令、データ構造、プログラムモジュール、搬送波またはその他の伝送機構などの変調データ信号における他のデータ、および任意の情報配信媒体を含むことが当業者にとって公知なことである。

本開示の実施形態に使用された具体的な用語は、一般的な説明の意味として解釈されるべきであり、限定するためのものではない。いくつかの実例において、特に明確に示さない限り、特定の実施形態において説明された特徴、特性、および／または要素を単独で使用してもよく、または別の実施形態において説明された特徴、特性、および／または要素と組み合わせて使用してもよいことは、当業者にとって自明なことである。したがって、添付の特許請求の範囲に記載された本開示の範囲から逸脱することなく、種々の変更が可能であることは、当業者が理解できるであろう。

Claims (45)

1. 複数のクライアントサービスのサービスデータに基づいて、各前記クライアントサービスのサービスブロックをそれぞれ生成することと、
   各前記クライアントサービスのサービスブロックを、少なくとも１つのサブスライシングフレームＳＳＦのペイロード領域にマッピングすることと、
   少なくとも１つのＳＳＦフレームを取得するよう、各前記ＳＳＦフレームのオーバヘッド領域フィールドを設定することと、
   を含み、
   各前記ＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ、
   サービスデータ処理方法。
2. 各前記クライアントサービスのサービスブロックを、少なくとも１つのサブスライシングフレームＳＳＦのペイロード領域にマッピングすることは、
   前記少なくとも１つのＳＳＦフレームのペイロード領域を複数のタイムスロットに分割することと、
   各前記クライアントサービスのサービスブロックをそれぞれ、前記複数のタイムスロットにおける異なるタイムスロットにマッピングすることと、
   を含み、
   異なる前記クライアントサービスが対応するタイムスロットにより、各前記クライアントサービスをそれぞれ運ぶサブスライシングチャネルＳＳＣが構成される、
   請求項１に記載のサービスデータ処理方法。
3. 各前記クライアントサービスのサービスブロックを、少なくとも１つのサブスライシングフレームＳＳＦのペイロード領域にマッピングすることにおいて、各前記クライアントサービスのサービスブロックを複数のＳＳＦフレームのペイロード領域にマッピングし、
   前記少なくとも１つのＳＳＦフレームのペイロード領域を複数のタイムスロットに分割することは、
   複数の前記ＳＳＦフレームを含むサブスライシングマルチフレームＳＳＭＦのペイロード領域を前記複数のタイムスロットに分割することを含む、
   請求項２に記載のサービスデータ処理方法。
4. 
5. 各前記クライアントサービスのサービスブロックをそれぞれ、前記複数のタイムスロットにおける異なるタイムスロットにマッピングすることは、
   異なるクライアントサービスの粒度に応じて、前記複数のタイムスロットにおいて、異なるクライアントサービスをそれぞれ運ぶタイムスロットの位置および数を特定することと、
   異なるクライアントサービスを運ぶタイムスロットの位置および数に基づいて、異なるクライアントサービスのサービスブロックを、対応するタイムスロットにマッピングすることと、
   を含む、請求項２または３に記載のサービスデータ処理方法。
6. 少なくとも１つのＳＳＦフレームを取得するよう、各前記ＳＳＦフレームのオーバヘッド領域フィールドを設定することは、
   前記少なくとも１つのＳＳＦフレームのオーバヘッド領域において、各前記クライアントサービスと、各前記クライアントサービスをそれぞれ運ぶタイムスロットとの対応関係を設定することと、
   前記少なくとも１つのＳＳＦフレームの他のオーバヘッドフィールドを設定して、前記少なくとも１つのＳＳＦフレームを取得することと、
   を含む、請求項２に記載のサービスデータ処理方法。
7. 前記少なくとも１つのＳＳＦフレームのオーバヘッド領域において、各前記クライアントサービスと、各前記クライアントサービスをそれぞれ運ぶタイムスロットとの対応関係を設定することは、
   前記オーバヘッド領域のタイムスロット識別フィールドに、クライアントサービスを運ぶタイムスロットの情報を設定することと、
   前記オーバヘッド領域のチャネル識別フィールドに、クライアントサービスを運ぶＳＳＣチャネルの情報を設定することと、
   を含む、請求項６に記載のサービスデータ処理方法。
8. 前記少なくとも１つのＳＳＦフレームのペイロード領域を複数のタイムスロットに分割することにおいて、複数のＳＳＦフレームのペイロード領域を複数のタイムスロットに分割し、
   前記少なくとも１つのＳＳＦフレームのオーバヘッド領域において、各前記クライアントサービスと、各前記クライアントサービスをそれぞれ運ぶタイムスロットとの対応関係を設定することは、
   前記オーバヘッド領域のマルチフレーム指示フィールドに、複数のＳＳＦフレームからなるＳＳＭＦマルチフレームにおける前記ＳＳＦフレームの位置情報を設定することをさらに含む、
   請求項７に記載のサービスデータ処理方法。
9. 前記ＳＳＦフレームの他のオーバヘッドフィールドは、
   前記ＳＳＦフレームの構造を示すためのフレームタイプフィールドと、
   サービス層チャネルの障害状態を示すための障害指示フィールドと、
   クライアントサービスのタイプを識別するためのサービスタイプフィールドと、
   チェック情報を記憶するためのチェックフィールドと、
   を含む、請求項６～８のいずれか１項に記載のサービスデータ処理方法。
10. 複数のクライアントサービスのサービスデータに基づいて、各前記クライアントサービスのサービスブロックをそれぞれ生成することの後に、前記サービスデータ処理方法は、
    同一タイプのクライアントサービスのサービスブロックからなるサービスブロックコードストリームに、操作保守管理ＯＡＭブロックを挿入することをさらに含む、
    請求項１に記載のサービスデータ処理方法。
11. 複数のクライアントサービスのサービスデータに基づいて、各前記クライアントサービスのサービスブロックをそれぞれ生成することの後に、前記サービスデータ処理方法は、
    同一タイプのクライアントサービスのサービスブロックからなるサービスブロックコードストリームに、サービスアイドルブロックを挿入することをさらに含む、
    請求項１に記載のサービスデータ処理方法。
12. 少なくとも１つのサブスライシングフレームＳＳＦを取得するよう、各前記ＳＳＦフレームのオーバヘッド領域フィールドを設定することの後に、前記サービスデータ処理方法は、
    前記ＳＳＦフレームのレートとサービス層ポートのレートに応じて、隣接する前記ＳＳＦフレームの間にフレーム間アイドルブロックを挿入することをさらに含む、
    請求項１に記載のサービスデータ処理方法。
13. 前記ＳＳＦフレームは、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂブロックからなる、
    請求項１に記載のサービスデータ処理方法。
14. 前記ＳＳＦフレームには、スタートブロックと、少なくとも１つのデータブロックと、ターミネートブロックとが含まれ、且つ、前記ＳＳＦフレームのフレーム長さは固定である、
    請求項１３に記載のサービスデータ処理方法。
15. 前記データブロックおよび／または前記ターミネートブロックにおいて、前記ＳＳＦフレームのペイロードを運ぶことと、
    前記スタートブロック、前記データブロック、および前記ターミネートブロックの内の少なくとも１つにおいて、前記ＳＳＦフレームのオーバヘッドを運ぶことと、
    をさらに含む、請求項１４に記載のサービスデータ処理方法。
16. 前記クライアントサービスは、イーサネットサービスを含む、
    請求項１３に記載のサービスデータ処理方法。
17. 複数のクライアントサービスのサービスデータに基づいて、各前記クライアントサービスのサービスブロックをそれぞれ生成することにおいて、クライアントサービスの、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックを前記サービスブロックとする、
    請求項１６に記載のサービスデータ処理方法。
18. 複数のクライアントサービスのサービスデータに基づいて、各前記クライアントサービスのサービスブロックをそれぞれ生成することは、
    クライアントサービスの、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックを圧縮しトランスコードして、前記サービスブロックを生成することを含む、
    請求項１６に記載のサービスデータ処理方法。
19. クライアントサービスの、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックを圧縮しトランスコードして、前記サービスブロックを生成することは、
    ２５６／２５７Ｂ符号化を利用して、前記６４／６６ＢイーサネットサービスブロックをＩＥＥＥ８０２．３規格に準拠する２５６／２５７Ｂブロックに圧縮しトランスコードすることを含む、
    請求項１８に記載のサービスデータ処理方法。
20. クライアントサービスの、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックを圧縮しトランスコードして、前記サービスブロックを生成することは、
    ６５Ｂ符号化を利用して、前記６４／６６Ｂイーサネットサービスブロックを６５Ｂブロックに圧縮しトランスコードすることを含む、
    請求項１８に記載のサービスデータ処理方法。
21. ６５Ｂ符号化を利用して、前記６４／６６Ｂイーサネットサービスブロックを６５Ｂブロックに圧縮しトランスコードすることは、
    所定のルールに従って、前記６４／６６Ｂイーサネットサービスブロックのシンクヘッダー内の１ビットを削除して前記６５Ｂブロックを取得することを含み、
    前記所定のルールは、前記シンクヘッダーの１番目のビットを削除すること、または前記シンクヘッダーの２番目のビットを削除することを含む、
    請求項２０に記載のサービスデータ処理方法。
22. 前記クライアントサービスは、時分割多重ＴＤＭサービスを含む、
    請求項１３に記載のサービスデータ処理方法。
23. 複数のクライアントサービスのサービスデータに基づいて、各前記クライアントサービスのサービスブロックをそれぞれ生成することは、
    イーサネット回線エミュレーションサービスＣＥＳｏＥＴＨに基づいて、前記ＴＤＭサービスのサービスコードストリームをイーサネットサービスコードストリームにマッピングして、イーサネットサービスブロックを生成することを含む、
    請求項２２に記載のサービスデータ処理方法。
24. 複数のクライアントサービスのサービスデータに基づいて、複数のサービスブロックをそれぞれ生成することは、
    ＴＤＭサービスのサービスコードストリームを符号化して、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂブロックを生成することを含む、
    請求項２２に記載のサービスデータ処理方法。
25. サービス層を介して前記ＳＳＦフレームを送信するよう、前記ＳＳＦフレームに対して前記サービス層処理を行うことをさらに含む、
    請求項１～３、６～８、１０～２４の内のいずれか１項に記載のサービスデータ処理方法。
26. インバウンドポートにより受信されたインバウンドＳＳＦフレーム内の各サービスブロックのアウトバウンドポートを特定することと、
    同一のアウトバウンドポートに対応するサービスブロックを少なくとも１つのアウトバウンドＳＳＦフレームにマッピングすることと、
    アウトバウンドポートを介して前記アウトバウンドＳＳＦフレームを送信することと、
    を含み、
    ここで、各前記インバウンドＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運び、
    各前記アウトバウンドＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ、
    サービスデータ交換方法。
27. インバウンドポートにより受信されたインバウンドＳＳＦフレーム内の各サービスブロックのアウトバウンドポートを特定することは、
    インバウンドポートにより受信された異なるインバウンドタイムスロットにおけるサービスブロックのアウトバウンドポートを特定することを含み、ここで、前記インバウンドタイムスロットは、少なくとも１つのインバウンドＳＳＦフレーム内のタイムスロットであり、
    同一のアウトバウンドポートに対応するサービスブロックを少なくとも１つのアウトバウンドＳＳＦフレームにマッピングすることは、
    同一のアウトバウンドポートに対応する異なるインバウンドタイムスロットにおけるサービスブロックをそれぞれ、異なるアウトバウンドタイムスロットにマッピングすることを含み、ここで、前記アウトバウンドタイムスロットは、少なくとも１つのアウトバウンドＳＳＦフレーム内のタイムスロットである、
    請求項２６に記載のサービスデータ交換方法。
28. インバウンドポートにより受信された異なるインバウンドタイムスロットにおけるサービスブロックのアウトバウンドポートを特定することは、
    各インバウンドタイムスロットと各アウトバウンドタイムスロットとの対応関係が格納されているタイムスロット交差構成テーブルに従って、インバウンドポートにより受信された異なるインバウンドタイムスロットにおけるサービスブロックのアウトバウンドポートを特定することを含む、
    請求項２７に記載のサービスデータ交換方法。
29. ローカルシステムクロックとアウトバウンドタイムスロットのレートとに基づき、同一のアウトバウンドタイムスロットにおけるサービスブロックで構成されるサービスブロックコードストリーム内のサービスアイドルブロックに対して追加または削除する処理を行うこと、および／または、
    ローカルシステムクロックとインバウンドタイムスロットのレートとに基づき、同一のインバウンドタイムスロットにおけるサービスブロックで構成されるサービスブロックコードストリーム内のサービスアイドルブロックに対して追加または削除する処理を行うこと、
    をさらに含む、請求項２７または２８に記載のサービスデータ交換方法。
30. ローカルシステムクロックとアウトバウンドポートのレートとに基づき、同一のアウトバウンドポートにおけるアウトバウンドＳＳＦフレーム間のフレーム間アイドルブロックに対して追加または削除する処理を行うこと、および／または、
    ローカルシステムクロックとインバウンドポートのレートとに基づき、同一のインバウンドポートにおけるインバウンドＳＳＦフレーム間のフレーム間アイドルブロックに対して追加または削除する処理を行うこと、
    をさらに含む、請求項２７または２８に記載のサービスデータ交換方法。
31. 少なくとも１つのＳＳＦフレームから所定のクライアントサービスのサービスブロックを抽出することと、
    前記所定のクライアントサービスのサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出することと、
    を含み、
    ここで、各前記ＳＳＦフレームは、いずれも複数の異なるクライアントサービスのサービスブロックを運ぶ、
    サービスデータ抽出方法。
32. 少なくとも１つのＳＳＦフレームから所定のクライアントサービスのサービスブロックを抽出することは、
    少なくとも１つの前記ＳＳＦフレームの所定のタイムスロットから前記所定のクライアントサービスのサービスブロックを抽出することを含み、
    ここで、前記所定のタイムスロットは、少なくとも１つのＳＳＦフレーム内の、前記所定のクライアントサービスを運ぶタイムスロットである、
    請求項３１に記載のサービスデータ抽出方法。
33. 少なくとも１つの前記ＳＳＦフレームの所定のタイムスロットから前記所定のクライアントサービスのサービスブロックを抽出することの後に、
    前記所定のタイムスロットから抽出されたＯＡＭブロックを分離させることをさらに含む、
    請求項３２に記載のサービスデータ抽出方法。
34. 前記所定のクライアントサービスは、イーサネットサービスを含む、
    請求項３１～３３のいずれか１項に記載のサービスデータ抽出方法。
35. 前記所定のクライアントサービスのサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出することは、
    前記所定のクライアントサービスの、ＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出することを含む、
    請求項３４に記載のサービスデータ抽出方法。
36. 前記所定のクライアントサービスのサービスブロックは、圧縮しトランスコードされて生成されたサービスブロックであり、
    前記所定のクライアントサービスのサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出することは、
    前記所定のクライアントサービスのサービスブロックをＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックに解凍することと、
    前記６４／６６Ｂイーサネットサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出することと、を含む、
    請求項３４に記載のサービスデータ抽出方法。
37. 前記所定のクライアントサービスのサービスブロックは、２５６／２５７Ｂ符号化を利用して圧縮しトランスコードして生成された２５６／２５７Ｂブロックであり、
    前記所定のクライアントサービスのサービスブロックをＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックに解凍することは、
    ２５６／２５７Ｂ符号化を利用して、前記所定のクライアントサービスのサービスブロックを前記６４／６６Ｂイーサネットサービスブロックに解凍することを含む、
    請求項３６に記載のサービスデータ抽出方法。
38. 前記所定のクライアントサービスのサービスブロックは、６５Ｂ符号化を利用して圧縮しトランスコードして生成された６５Ｂブロックであり、
    前記所定のクライアントサービスのサービスブロックをＩＥＥＥ８０２．３符号化規格に準拠する６４／６６Ｂイーサネットサービスブロックに解凍することは、
    ６５Ｂ符号化を利用して、前記所定のクライアントサービスのサービスブロックを前記６４／６６Ｂイーサネットサービスブロックに解凍することを含む、
    請求項３６に記載のサービスデータ抽出方法。
39. ６５Ｂ符号化を利用して、前記所定のクライアントサービスのサービスブロックを前記６４／６６Ｂイーサネットサービスブロックに解凍することは、
    所定のルールに従って、前記６５Ｂブロックのシンクヘッダーに１ビットを追加して、前記６４／６６Ｂイーサネットサービスブロックを取得することを含み、
    前記所定のルールは、前記シンクヘッダーの１番目のビットの前に１ビットを追加すること、または前記シンクヘッダーの１番目のビットの後に１ビットを追加することを含む、
    請求項３８に記載のサービスデータ抽出方法。
40. 前記所定のクライアントサービスは、時分割多重ＴＤＭサービスを含む、
    請求項３１～３３のいずれか１項に記載のサービスデータ抽出方法。
41. 前記所定のクライアントサービスのサービスブロックは、ＣＥＳｏＥＴＨに従って、ＴＤＭサービスコードストリームをイーサネットサービスコードストリームにマッピングして生成されたイーサネットサービスブロックであり、
    前記所定のクライアントサービスのサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出することは、
    ＣＥＳｏＥＴＨに従って、前記所定のクライアントサービスのサービスブロックをＴＤＭサービスコードストリームにデマッピングして、前記ＴＤＭサービスコードストリームから前記所定のクライアントサービスのサービスデータを抽出することを含む、
    請求項４０に記載のサービスデータ抽出方法。
42. 前記所定のクライアントサービスのサービスブロックは、ＩＥＥＥ８０２．３符号化規格に従って、ＴＤＭサービスコードストリームを符号化して生成された６４／６６Ｂブロックであり、
    前記所定のクライアントサービスのサービスブロックを復号化して、前記所定のクライアントサービスのサービスデータを抽出することは、
    ＩＥＥＥ８０２．３符号化規格に従って、前記６４／６６ＢブロックをＴＤＭサービスコードストリームに復号化して、前記ＴＤＭサービスコードストリームから前記所定のクライアントサービスのサービスデータを抽出することを含む、
    請求項４０に記載のサービスデータ抽出方法。
43. １つ以上のプロセッサと、
    １つ以上のプログラムが格納され、前記１つ以上のプログラムが前記１つ以上のプロセッサにより実行される場合、前記１つ以上のプロセッサに請求項１～２５のいずれか１項に記載のサービスデータ処理方法、または請求項３１～４２のいずれか１項に記載のサービスデータ抽出方法を実現させる記憶装置と、
    前記プロセッサと記憶装置との間に接続され、前記プロセッサと記憶装置との情報通信が行われるように設置される１つ以上の入出力Ｉ／Ｏインターフェースと
    を備える、プロバイダエッジデバイス。
44. １つ以上のプロセッサと、
    １つ以上のプログラムが格納され、前記１つ以上のプログラムが前記１つ以上のプロセッサにより実行される場合、前記１つ以上のプロセッサに請求項２６～３０のいずれか１項に記載のサービスデータ交換方法を実現させる記憶装置と、
    前記プロセッサと記憶装置との間に接続され、前記プロセッサと記憶装置との情報通信が行われるように設置される１つ以上のＩ／Ｏインターフェースと
    を備える、プロバイダ交換デバイス。
45. コンピュータプログラムが格納され、前記プログラムがプロセッサによって実行される場合、請求項１～２５のいずれか１項に記載のサービスデータ処理方法、または請求項２６～３０のいずれか１項に記載のサービスデータ交換方法、または請求項３１～４２のいずれか１項に記載のサービスデータ抽出方法を実現させる
    コンピュータ可読媒体。

Images