JP2005502231A - パケット化されたｓｏｎｅｔ／ｓｄｈペイロードの圧縮方法 - Google Patents

Abstract

パケット化されたＳＯＮＥＴ／ＳＤＨストリームをパケット交換網を通じて送信するために圧縮する方法であって、ストリーム（２０２）中でＣ２バイトを識別し、前記識別に基づいて、Ｃ２バイト関連圧縮アルゴリズムを適用して、ストリームを圧縮する方法。Ｃ２バイトは、パケットペイロードまたはヘッダーからパケットプロセッサにより抽出され、入口パケタイザ内で予め構成され、あるいは、出口パケタイザから入口パケタイザに送り返されたＳＯＮＥＴ回線を検査することにより自動的に識別される。圧縮アルゴリズムの様々な実施形態としては、用意ができていないＣ２＝０×０（２１０）、仮想トリビュタリＣ２＝０×０２（２２０）、ＨＤＬＣ Ｃ２＝０×１６（２３０）、ＰＰＰ Ｃ２＝０×ＣＦ（２４０）、および非同期ＤＳ−３ Ｃ２＝０×０４（２５０）の識別に基づくアルゴリズムが挙げられる。

Description

【技術分野】
【０００１】
関連出願の相互参照
この出願は、２００１年５月２４日に提出された米国仮出願第６０／２９２，９５２号の利益が与えられている。
【０００２】
本発明は、パケット化されたデータストリーム、特にＳＯＮＥＴ／ＳＤＨストリームを圧縮するための方法に関する。
【背景技術】
【０００３】
ＳＯＮＥＴ（光同期伝送網）は、Bellcoreによって開発され且つ光ファイバによって伝送されるように設計された高速同期ネットワーク規格である。ＳＤＨ（同期デジタルハイアラーキ）は、ＳＯＮＥＴ規格の国際版である。ＳＯＮＥＴ規格とＳＤＨ規格との間の違いは、ごく僅かであり、例えば米国規格協会の“光同期伝送網（ＳＯＮＥＴ）−多重構造、比率、フォーマットを含む基本的な説明”ＡＮＳＩ Ｔ１．１０５−１９９５(American National Standards Institute, “Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats,” ANSI T1.105-1995)；ＩＴＵ推奨Ｇ．７０７の“同期デジタルハイアラーキのためのネットワークノードインタフェース”１９９６(ITU Recommendation G.707, “Network Node Interface For The Synchronous Digital Hierarchy”, 1996)；およびTelcordiaテクノロジーの“光同期伝送網（ＳＯＮＥＴ）送信システム：共通一般基準”ＧＲ−２５３−ＣＯＲＥ、刊行物３、２０００年１１月(Telcordia Technologies, “Synchronous Optical Network (SONET) Transport Systems：Common Generic Criteria”, GR-253-CORE, Issue 3, November 2000；を参照のこと。以下の説明において、ＳＯＮＥＴなる専門用語は、ＳＯＮＥＴおよびＳＤＨの両方のために使用され、ＳＤＨは、規格の違いが重要である場合にのみ、明示的に述べる。
ＳＯＮＥＴにおける基本的なビルディングブロック信号は、５１．８４Mbpsで動作する同期伝送信号レベル１（ＳＴＳ−１）である。高速ＳＯＮＥＴ信号は、複数のＳＴＳ−１信号を時分割多重化（ＴＤＭ）することによって構成することができる。例えば、ＳＴＳ−３信号は、３つのＳＴＳ−１信号から成る。この場合、ストリーム中の各バイトは、第１、第２および第３のＳＴＳ−１成分との間で交替する。
ＳＯＮＥＴフレームは、１秒間に８０００回送信される。ＳＯＮＥＴフレームは、伝送オーバーヘッドと、データを運ぶ同期ペイロードエンベロープ（ＳＰＥ）とから成る。ＳＰＥは、オーバーヘッドバイトおよびデータペイロードを運ぶ。パスオーバーヘッド（ＰＯＨ）と称される９個のオーバーヘッドバイトは、ＳＯＮＥＴペイロード内で運ばれるデータ信号タイプを特定するバイトだけでなく、様々な演算アラームおよびメンテナンスタスクにおいて使用される他のバイトを含んでいる。ＳＰＥの開始は、一定のフレーム伝送ヘッダーからのオフセットで始まる。伝送オーバーヘッドバイト（ＴＯＨ）内のポインタは、ＳＰＥの開始を示している。
【０００４】
ＳＯＮＥＴ高速信号を連結して、高速チャンネルを形成することができる。ＳＴＳ−３ｃにおける小さな‘ｃ’は、３つのＳＴＳ−１ｓを時分割多重化する代わりにＳＰＥが連結されて１つのＰＯＨおよびペイロードだけを含んでいることを示している。
ＳＴＳは、ＡＴＭセル、パケット、ＤＳ−３、ＳＯＮＥＴ用語で仮想トリビュタリ（ＶＴｓ）と称されるＴ１（１．５４４Mbps）およびＥ１（２．０４８Mpbs）を含む低速ＴＤＭ回線を運ぶことができる。ＳＯＮＥＴ送信インフラ構造は、これらの様々なタイプの多重化回線を運ぶ。
パケット交換網が順調に普及するにつれて、パケット交換網を通じてＳＯＮＥＴ回線を運ぶ必要性がでてくる。すなわち、ＳＯＮＥＴ／ＳＤＨ“ストリーム”は、パケット交換網を通じて、“ペイロード”として運ばれる。したがって、以下の説明において、“ストリーム”および“ペイロード”は、交換可能に使用される。この必要性に対処すべく多くの提案が成されてきた。ＳＯＮＥＴパケタイザ装置は、ＳＯＮＥＴ ＴＤＭ信号を受け、入力バイトストリームを蓄え、入力バイトストリームをパケットペイロードとしてペーストする。パケットは、パケットからペイロードを抽出し且つ送出するＳＯＮＥＴ信号上に抽出したペイロードをのせる他のＳＯＮＥＴパケタイザに達するまで、パケット送信網を通じて送られる。パケタイザは、ジッタバッファを使用して、パケット送信網のジッタを補償してもよい。また、パケタイザは、様々なアラーム、管理タスク、故障状態処理を行なうようになっている。現在、ある作業が進行中であるが、パケット交換網を通じてＳＯＮＥＴ回線を運ぶための規格はない。例えば、www.ietf.orgのインターネット・タスク・フォース（ＩＥＴＦ）を参照のこと。なお、前記作業は、ＰＷＥ３（擬似ワイヤ・エッジツーエッジ・エミュレーション）作業グループ内で行なわれている。
パケット交換網は、パケット送信を統計的に多重化する。パケットペイロード上のＳＯＮＥＴを圧縮できる場合には、帯域幅の消費は減り、他のパケットフローのためのスペースが残る。したがって、ネットワークを通じて運ばれるＳＯＮＥＴペイロードを効率的に圧縮することが望ましい。現在、ＳＯＮＥＴペイロードを圧縮するために提案された唯一の方法は、未使用の（用意ができていない）ＳＴＳ−１およびＳＴＳ−Ｎｃコンテナを圧縮する方法である。
【非特許文献１】
American National Standards Institute, “Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats,” ANSI T1.105-1995
【非特許文献２】
ITU Recommendation G.707, “Network Node Interface For The Synchronous Digital Hierarchy”, 1996
【非特許文献３】
Telcordia Technologies, “Synchronous Optical Network (SONET) Transport Systems：Common Generic Criteria”, GR-253-CORE, Issue 3, November 2000
【発明の開示】
【発明が解決しようとする課題】
【０００５】
したがって、パケット化されたＳＯＮＥＴ／ＳＤＨペイロードを効率的に圧縮するための方法の必要性が広く認識されるとともに、そのような方法があれば非常に有益である。
本発明は、パケット化されたＳＯＮＥＴ／ＳＤＨペイロードを効率的に圧縮するための方法に関する。
本発明においては、パケット化されたＳＯＮＥＴ／ＳＤＨストリームをパケット交換網を通じて送信するために圧縮する方法であって、ストリーム中でＣ２バイトを識別し、前記識別に基づいて、Ｃ２バイト関連圧縮アルゴリズムを適用して、ストリームを圧縮することを含む方法が提供される。
【課題を解決するための手段】
【０００６】
本発明の方法の１つの特徴において、Ｃ２バイトを識別する前記ステップは、ストリームから前記Ｃ２バイトを抽出することを含む。
本発明の方法の他の特徴において、Ｃ２バイトを識別する前記ステップは、予め構成されたＣ２情報を使用することを含む。
本発明の方法の更に他の特徴において、Ｃ２バイトを識別する前記ステップは、前記Ｃ２圧縮を適用するように構成された入口パケタイザを設け、前記Ｃ２圧縮の結果、圧縮されたストリームが送信され、前記送信された圧縮ストリームを受けて解凍するように構成された出口パケタイザを設け、前記出口パケタイザから前記入口パケタイザに送り返されたＳＯＮＥＴ回線を検査することを含む。
本発明の方法の第１の実施形態において、Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、用意ができていないＣ２＝０×０圧縮アルゴリズムを適用することを含む。
本発明の方法の第２の実施形態において、Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、仮想トリビュタリＣ２＝０×０２圧縮アルゴリズムを適用することを含む。
本発明の方法の第３の実施形態において、Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、ＨＤＬＣ Ｃ２＝０×１６圧縮アルゴリズムを適用することを含む。
本発明の方法の第４の実施形態において、Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、ＰＰＰ Ｃ２＝０×ＣＦ圧縮アルゴリズムを適用することを含む。
本発明の方法の第５の実施形態において、Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、非同期ＤＳ−３ Ｃ２＝０×０４圧縮アルゴリズムを適用することを含む。
【０００７】
本発明の方法の第２の実施形態における１つの特徴において、仮想トリビュタリＣ２＝０×０２圧縮アルゴリズムを適用する前記ステップは、ストリーム中に含まれる複数のＳＰＥ縦列およびＳＰＥ横列から一定の縦列を除去するサブステップと、前記ＳＰＥ縦列を再配列して、再配列縦列を得るサブステップと、前記再配列ＳＰＥ縦列と前記ＳＰＥ横列との間で反転させて、変換ストリームを形成するサブステップと、前記変換ストリームを圧縮するサブステップとを更に含む。
本発明の方法の第２の実施形態における他の特徴において、前記複数のＳＰＥ縦列から一定の縦列を除去する前記サブステップは、前記ＳＰＥ縦列の縦列３０および５９を除去することを含む。
本発明の方法の第２の実施形態における更に他の特徴において、縦列を再配列する前記ステップは、前記ＳＰＥ縦列のＶＴＧアライメントを行なうサブステップと、前記ＳＰＥ縦列間でインターＶＴＧアライメントを行なうサブステップとによって、ストリームのＶＴコンテンツを再配列することを更に含んでいる。
本発明の方法の第２の実施形態における更に他の特徴において、インターＶＴＧアライメントを行なう前記サブステップは、ＶＴ１．５ｓに関して最適化する第１のプロセス、ＶＴ２ｓに関して最適化する第２のプロセスと、ＶＴ１．５ｓとＶＴ２ｓとの組み合わせに関して最適化する第３のプロセスとから成るグループから選択される縦列再配列プロセスを行なうことを含む。
【０００８】
本発明の方法の第３の実施形態における１つの特徴において、ＨＤＬＣ Ｃ２＝０×１６圧縮アルゴリズムを適用する前記ステップは、ストリーム中に含まれる複数のＳＰＥ縦列およびＳＰＥ横列から一定の縦列を除去して変換ストリームを得るサブステップと、前記変換ストリームを圧縮するサブステップとを更に含む。
本発明の方法の第３の実施形態における他の特徴において、前記変換ストリームを圧縮する前記サブステップは、（０×ＦＤ，長さ）を使用した変換ストリームの圧縮と、（０×ＦＤ値，長さ）を使用した変換ストリームの圧縮とから成るグループから選択されるデータ圧縮処理を含んでいる。
本発明の方法の第４の実施形態における１つの特徴において、ＰＰＰ Ｃ２＝０×ＣＦ圧縮アルゴリズムを適用する前記ステップは、ストリーム中に含まれる複数のＳＰＥ縦列およびＳＰＥ横列から一定の縦列を除去して変換ストリームを得るサブステップと、データストリームを解読するサブステップと、前記変換ストリームを圧縮するサブステップとを更に含む。
本発明の方法の第４の実施形態における他の特徴において、前記変換ストリームを圧縮する前記サブステップは、（０×ＦＤ，長さ）を使用した変換ストリームの圧縮と、（０×ＦＤ値，長さ）を使用した変換ストリームの圧縮とから成るグループから選択されるデータ圧縮処理を含んでいる。
本発明の方法の第５の実施形態における１つの特徴において、非同期ＤＳ−３ Ｃ２＝０×０４圧縮アルゴリズムを適用する前記ステップは、ストリームの前記複数のＳＰＥ縦列から一定の且つ未使用の縦列２，３，３０，３１，５９および６０を除去することを含む。
【発明を実施するための最良の形態】
【０００９】
ここで、添付図面を参照しながら、単なる一例として、本発明を説明する。
本発明は、パケット化されたＳＯＮＥＴおよび／またはＳＤＨペイロードをパケット交換網を通じて送信するために効率的に圧縮する方法に関する。パケット化されたＳＯＮＥＴ／ＳＤＨペイロードをパケット交換網を通じて送信するために効率的に圧縮する本発明に係る方法の原理および工程は、図面および付随する説明を参照することにより更に理解することができる。
【００１０】
図１のブロック図に示されるように、好ましい実施形態において、本発明の方法は、入口パケタイザ１００と出口パケタイザ１００’とを有するシステム５０で実行される。これらの両方のパケタイザは、多くの作業またはタスクを行なうことができる。各パケタイザは、一般的に必要なパケタイザのタスクに加えて、ＳＯＮＥＴ ＳＴＳ−１およびＳＴＳ−Ｎｃ信号内で運ばれるペイロードに基づいたＳＯＮＥＴペイロードの圧縮および／または解凍を行なう。特に、本発明の各パケタイザは、ＳＯＮＥＴ ＰＯＨ Ｃ２信号ラベルバイトに基づいて、様々な圧縮および／または解凍アルゴリズムを行なう。
本発明の入口パケタイザおよび出口パケタイザは、ＳＯＮＥＴパケットトラヒックがシステムを通じて双方向であるという点では、交換可能である。すなわち、パケタイザ１００を通じてパケットをシステム５０に入力して、パケタイザ１００’を通じてパケットをシステムから出力することができ、あるいは、その逆も可能である。以下においては、便宜的に、パケタイザ１００を介して入力し（パケタイザ１００で圧縮され）且つパケタイザ１００’を介して出力する（パケタイザ１００’で解凍される）データを中心に説明する。
パケタイザ１００は、ＳＯＮＥＴインタフェース１０２からＳＯＮＥＴプロセッサ１０４を介してＳＯＮＥＴデータを受ける。ＳＯＮＥＴプロセッサ１０４は、パケット交換網１２０を通じて送信する必要があるＳＰＥバイトを抽出するとともに、ＳＯＮＥＴオーバーヘッドバイトを識別する。ＳＯＮＥＴ ＳＴＳ−１回線をパケット化するため、ＳＰＥ抽出は、最初のＰＯＨバイト（Ｊ１バイト）から始まるＳＰＥコンテンツ（７８３バイト）の抽出を含む。その後、ＳＯＮＥＴプロセッサ１０４は、ＳＰＥ ＰＯＨバイト内のＣ２バイトを検査して識別する。その後、ＳＯＮＥＴプロセッサは、ＳＰＥバイトを圧縮装置１０６に転送する。この圧縮装置において、ペイロードは、特定のＳＯＮＥＴ ＳＴＳ−１ペイロードに適したアルゴリズムを使用して圧縮されるとともに、Ｃ２バイトによって選択される。すなわち、本発明の重要なステップにおいて、Ｃ２バイトは、適用される特定の圧縮アルゴリズムのための識別子として機能する。そのため、本発明の圧縮方法は、その様々な実施形態において、“Ｃ２バイト関連圧縮アルゴリズム”と称される。続いて、パケットプロセッサ１０８によってカプセル化ステップが行なわれる。このステップにおいて、圧縮されたペイロードは、１つのパケット内にカプセル化される。ＳＰＥペイロードは、１パケットで運ばれてもよいが、必要な場合には、複数のパケット上で伝送されてもよい。その後、パケットは、第１のパケットインタフェース１１０を介して、パケット交換網１２０へと送られる。パケットは、パケット交換網を通じて移動し、第２のパケットインタフェース１１２を介して第２のパケタイザ１００’へと送られる。第２のパケタイザ１００’では、パケットプロセッサ１０８’、解凍装置１０６’、第２のＳＯＮＥＴプロセッサ１０４’によって一連の逆の作業が行なわれる。解凍されたパケットは、第２のＳＯＮＥＴインタフェース１３０を介して、システム５０から出力される。
【００１１】
パケタイザ１００’は、パケットインタフェース１１２を介してパケットを受けるとともに、逆の順番で作業を行なう。Ｃ２バイトは、パケットプロセッサ１０８’により、パケタイザ１００内で予め構成されたパケットペイロードまたはヘッダーから抽出され、あるいは、パケタイザ１００’からパケタイザ１００へと送り返されるＳＯＮＥＴ回線を検査することにより自動的に識別される。したがって、Ｃ２バイトを“識別する”方法は、主に３つあり、このような“識別”は、本発明の方法の各実施形態における重要なステップとして機能する。このようにして識別されたＣ２バイトによって選択される正確な解凍アルゴリズムが解凍装置１０６’内で行なわれ、これにより、ペイロードが解凍される。解凍されたペイロードは、適当なＰＯＨおよびペイロードバイトと共に、ＳＯＮＥＴプロセッサ１０４’により、ＳＯＮＥＴインタフェース１３０を介して送られる。これにより、伝送オーバーヘッドバイト内の必要な領域を更新できる。
前述したステップ１０４，１０６，１０８によって示されるタスク（および１０８’，１０６’，１０４’によって具体化された逆のタスク）のほか、パケタイザは、エラーを処理したり、他のＰＯＨバイトを含むパケット内の別個の情報を送出することを含む他のタスクを行なうことができる。
高ＳＴＳ−Ｎ信号を処理する場合、このような信号は、最初に、そのＳＴＳ−１成分へと逆多重化され、異なるパケットフローで個別に送られる。高連結信号は、同じステップで処理される。唯一異なる点は、ＳＰＥペイロードが大きく、したがって、ペイロードが複数のパケットを通じて送られる機会が多いという点である。
【００１２】
本発明の圧縮アルゴリズムの幾つかは、後述するように、他のカプセル化技術が使用される場合であっても、使用することができる。技術的に開発中のカプセル化技術（本発明の圧縮アルゴリズムと共に使用できるカプセル化技術）の一例は、Ｊ１ ＰＯＨバイトの後に始めるためにペイロードをアライメントすることなく、ＰＯＨバイトを含むＳＯＮＥＴ ＳＰＥをカプセル化することを含む。この方法においては、ペイロードヘッダー内でＴＯＨポインタが運ばれる。
ＳＯＮＥＴは、多数のエラー監視バイトを与える。Ｂ１バイトおよびＢ２バイトは、ＳＴＳ−１フレームのエラー監視のために使用される。Ｂ１バイトおよびＢ２バイトは、ＴＯＨの一部であり、したがって、各ＳＯＮＥＴリンク上でチェックされて再計算される。Ｂ３バイトは、ＰＯＨの一部であり、ＳＰＥのエラー監視のために使用される。Ｂ３バイトは、ＳＯＮＥＴパス終了ノードでチェックされて再計算される。Ｂ３バイトは、先のＳＰＥのビットインターリーブパリティとして計算される。パケット網は、エラー監視のための他の方法を有している。例えば、ＳＯＮＥＴペイロードがＲＴＰ／ＵＤＰ／ＩＰプロトコルでカプセル化されると、ＵＤＰの１６ビットチェックサム領域は、ペイロードエラー監視を行なう。パケット網エラー監視機構は、Ｂ１／Ｂ２ ＳＯＮＥＴエラー機構に取って代わり、同様に、ＳＯＮＥＴ Ｂ３機構に取って代わってもよい。ＳＯＮＥＴペイロードをＴＤＭチャンネル内に挿入して戻す各パケタイザは、Ｂ３バイトを再計算してもよい。Ｂ３エラー機構をパケット網にわたって維持する必要がある場合には、ＳＯＮＥＴペイロードを圧縮する際に幾つかの注意が必要である。各圧縮機構における仕様については、アルゴリズムを説明する各項目で詳述されている。
【００１３】
図２は、Ｃ２バイトの検査に基づいて実施される本発明の圧縮方法またはアルゴリズムの様々な実施形態のブロック図を示している。前述したように、圧縮中、ＳＯＮＥＴプロセッサ１０４（図１）においてＣ２バイトの識別が行なわれ、同時に圧縮装置１０６において圧縮が行なわれる。図２において、圧縮方法のステップ２０２を選択することにより、５つの方法のうちの１つの実施形態が実施される。
１．用意ができていないＣ２＝０×０ （ブロック２１０）
２．仮想トリビュタリ Ｃ２＝０×０２（ブロック２２０）
３．ＨＤＬＣ Ｃ２＝０×１６ （ブロック２３０）
４．ＰＰＰ Ｃ２＝０×ＣＦ （ブロック２４０）
５．非同期ＤＳ−３ Ｃ２＝０×０４ （ブロック２５０）
【００１４】
用意ができていないＣ２＝０×０ ブロック２１０。
この場合、技術的に成立すれば、用意ができていない信号が重要でないペイロードを運び、入口パケタイザは、ＳＰＥペイロードの全てを廃棄処分するとともに、ペイロードヘッダー内の用意ができていない信号を示すパケットを送る。
仮想トリビュタリ Ｃ２＝０×０２ ブロック２２０。
この場合、ＳＴＳ−１は、７つの仮想トリビュタリ群（ＶＴＧｓ）内でＶＴｓを運ぶ。ＶＴＧは、それぞれが１つのＴ１を保持する４つのＶＴ１．５ｓ、それぞれが１つのＥ１を運ぶ３つのＶＴ２ｓ、それぞれが１つのＤＳ１−Ｃ信号を運ぶ２つのＶＴ３ｓ、または１つのＤＳ−２を運ぶ１つのＶＴ６のいずれかを運ぶことができる。ＶＴＧｓは、バイトごとに多重化される。ＳＰＥペイロードは、通常、縦８６列×横９列の行列に置き換えて説明される。行列内のバイトは、横列ごとに送られる。行列表示は、ＳＰＥペイロード内のＶＴＧおよびＶＴのバイト多重化も縦列方向多重化であるため、有用である。すなわち、ＶＴＧ１のバイトは、ＳＰＥの１２個の縦列２，９，１６，２３，３１，３８，４５，５２，６０，６７，７４および８１を占める。この場合、縦列１は、ＰＯＨである（我々は、標準的な縦列計算を使用する）。最初のＶＴＧの最初のＶＴ１．５は、２，３１，６０ＳＰＥ縦列を占める。同様に、ＶＴＧ内の全てのＶＴは、ＳＰＥ内の一組の所定の縦列を占める。それぞれが１２個の縦列を占めるＶＴＧｓが７つ存在するため、２つの縦列が未使用のままとなる。ＳＰＥの縦列３０および５９は、使用されず、通常、一定の値を持つバイトを有している。
【００１５】
ＶＴバイトは、両方のＶＴオーバーヘッドバイト（ＶＴＯＨ）およびデータを保持する。ＶＴｓは、データを運ぶことができ、あるいは全く使用することができない（用意ができていない）。多くの場合、用意ができていないＶＴｓ内の情報バイトは、一定である（０×０または０×ＦＦ）。他のＶＴｓは、一定のバイトを運んでいてもよい。例えば、ＶＴ１．５は、パケットを運ぶために使用されるアンチャンネルＴ１回線を運んでいてもよい。非作業時間中、ラインは、アイドル状態であってもよく、したがって、一定値０×７Ｅを持つＨＤＬＣアイドルフラグだけを運んでいてもよい。圧縮アルゴリズムは、ＶＴＧコンテンツに関係なく、各縦列が１つのＶＴに属しているという事実を使用する。したがって、このＶＴが用意できていない場合には、縦列の大部分のバイトが一定値であり、したがって、簡単に圧縮できる。
Ｃ２＝０×０２に基づく第２の（仮想トリビュタリ）方法の実施形態において、圧縮は、所定の縦列を除去した後、３段階で行なわれる。この除去においては、未使用の縦列３０および５９がペイロードから除去される。これらの縦列の除去は、ＰＯＨ Ｂ３演算に影響を与えない。これは、これらの縦列が一定値のバイトを運び、したがって、各縦列がパリティ計算に対する他の負担をキャンセルするからである。３つの圧縮段階は、１）ＳＰＥペイロード縦列の再配列２１２、２）ＳＰＥペイロードの横列と縦列との間での反転２１４、および３）圧縮２１６である。
【００１６】
ＳＰＥペイロード縦列の再配列２１２：
ＳＰＥペイロード縦列の再配列は、２つのサブ段階、すなわち、ａ）ＶＴＧアライメントおよびｂ）インターＶＴＧアライメントで行なわれることが好ましい。
ａ．ＶＴＧアライメント：１番目の１２個の縦列がＶＴＧ−１を含み、２番目の１２個の縦列がＶＴＧ−２を含み、それ以降、最大でＶＴＧ−７までの他の全てのＶＴＧｓを含むように、ＳＰＥペイロード縦列が再配列される。各ＶＴＧ内で、縦配列が維持される。例えば、最初のＶＴＧは、１３まで縦列２を占め、一方、最初の縦列２，９，１６，２３等は、縦列２，３，４，５をそれぞれ占める。
ｂ．インターＶＴＧアライメント：各ＶＴＧｓ内の縦列は、用意ができていない回線、またはアイドル回線を圧縮する可能性を最大限にするように再配列される。縦列アライメントは、ＳＰＥペイロードにおいて各ＶＴＧごとに行なわれる。単純で典型的なアルゴリズムを以下に規定する。
１つのＶＴＧおよびその１〜１２までの縦列の数を見よ。以下の表１（背景）は、ＶＴＧ内で運ばれるＴＶタイプにしたがって各回線に属する縦列の番号を示している。
【００１７】
【表１】

インターＶＴＧアライメントにおいては、ＶＴＧがＶＴ１．５回線を運び且つＶＴ＃１が用意できていない場合、縦列１，５および９が一定のバイト値を運ぶ。これらの３つの縦列を連続的に再配列すると、ＳＰＥペイロードの縦列方向を読む際に、連続する一定のバイトの長さが長くなる。しかし、ＶＴＧがＶＴ２回線を運ぶ場合、縦列１，５および９は、それぞれ異なるＶＴに属し、したがって、ＶＴ２ｓのうちの１つが用意できていなかった場合、例えばＶＴ＃１である場合、１つの連続する縦列だけが一定のバイトを運ぶ。
ここでは、幾つかの手法をとることができる。アルゴリズムは、データを動的に検査して、縦列の配列を早急に適合させ、これにより、解凍に必要な選択された縦列配列に関する情報をペイロードヘッダーに加える。あるいは、圧縮装置および解凍装置によって承認される幾つかの所定の最適化が、縦列配列の選択において行なわれる。
ＳＯＮＥＴは、北米および日本で主に使用されており、殆どの場合、ＶＴ１．５をＶＴモードで運ぶ。ＳＤＨは、世界中の他の全ての国々で使用されており、ＴＵ−１２と呼ばれるＶＴ２相当のものをＶＴモードで主に運ぶ。したがって、インターＶＴＧアライメントサブステップにおける所定の縦列再配列の幾つかの最適化は、順序立てられており、ボックス２１２内に示されている。第１のプロセス２１２’は、ＶＴ１．５ｓに関して最適化され、第２のプロセス２１２”は、ＶＴ２ｓに関して最適化され、第３のプロセス２１２”’は、ＶＴ１．５ｓとＶＴ２ｓとの組み合わせに関して最適化される。これらの最適化は、ＳＤＨまたはＳＯＮＥＴが使用されるか否かに基づいて選択することができ、あるいは、コンフィギュレーションによって選択することができる。
【００１８】
第１の最適化プロセス、すなわち最適化ＶＴ１．５縦列選択２１２’は、各ＶＴ１．５の３つの縦列が常に連続的であるように、ＶＴＧ内で縦列を配列する。用意ができていないＶＴ３ｓの圧縮を最適化するため、ＶＴ１．５＃１およびＶＴ１．５＃３が順に配列される。各ＶＴ１．５の縦列は、各ＶＴ１．５の最後の縦列および次のＶＴ１．５の最初の縦列が同じＶＴ２に属するように、配列される。各ＴＶ２が２つの連続する縦列を有するように縦列が配列されるのが好ましいのだろうか。最初のＶＴ縦列は、その最初のバイトとして、常にオーバーヘッドバイトを運ぶので、最初のままである。したがって、好ましいＶＴ１．５最適化縦列の配列は、以下の通りである。
（１，５，９），（３，７，１１），（２，６，１０），（４，８，１２）
第２の最適化プロセス、すなわち、最適化ＶＴ２縦列選択２１２”は、ＶＴ２縦列が常に連続的に配列されるように、前述したアルゴリズムと同じアルゴリズムを使用して、ＶＴＧ内で縦列を配列する。ＶＴ３に関して最適化するため（ＳＤＨ相当のものは規定されないが）、偶数の縦列および奇数の縦列が順に配列される。最後に、１つのＶＴ２の最後の縦列および次のＶＴ２の最初の縦列が同じＶＴ１．５に属するように、ＶＴ２ｓの縦列が配列される。したがって、考えられるＶＴ２最適化縦列の配列は、以下の通りである。
（１，７，４，１０），（２，８，１１，５），（９，３，６，１２）
最適化された縦列配列がＶＴ２とＶＴ１．５最適化との間の折衷案である第３の“ミックス”最適化プロセス２１２”’において、最適化は、考えられる各ＶＴ２またはＶＴ１．５ごとに、少なくとも２つの連続する縦列に関して行なわれる。したがって、考えられるＶＴ２／ＶＴ１．５最適化縦列の配列は、以下の通りである。
（１，７），（３，９），（５，１１），（２，８），（４，１０），（６，１２）
縦列が再配列された後、圧縮装置は、サブ段階２１４において、縦列と横列とを反転させ、これにより、“変換ペイロード”または“変換ストリーム”を形成する。この時、圧縮装置１０６（図１）は、図２のサブ段階２１６で、変換ペイロードを圧縮する。この時点で、幾つかの圧縮アルゴリズムを使用することができる。
【００１９】
用意ができていない回線およびアイドル回線を圧縮するのに適した最も簡単な圧縮アルゴリズム（以下、“（エスケープ、長さ、値）バイトを使用する通常長さ圧縮”と称する）は、同じ値を持つ連続バイトを、値の表示およびストリームの長さに置き換える。圧縮は、カウンタバイトおよび随意的に値バイトが追従することを示す特定のエスケープバイトを使用して行なわれる。使用されるエスケープバイトは、０×ＦＦである。長さバイトは、０×ＦＦを下回る値に限られ、追加の連続する値バイトの数を示す。したがって、２の長さは、最初のペイロード中に３つの連続する値バイトが現われることを意味する。０×ＦＦがペイロード中に現われる場合には、長さ０バイトが後にくるエスケープバイトが出力に挿入される。２つの連続する０×ＦＦバイトがペイロード中に現われる場合には、長さ１バイトが後にくるエスケープバイトが出力に挿入される。ほかに、（エスケープ、長さ、値）バイトを使用する通常の圧縮が使用される。したがって、圧縮された出力サイズは、１つの０×ＦＦエスケープ文字が最初のペイロード中に現われる場合にだけ大きくなる。出力の全長が最初のペイロードよりも長い場合には、ペイロードが圧縮されない状態で送られてもよい。
ＨＤＬＣ Ｃ２＝０×１６、ブロック２２０およびＰＰＰ Ｃ２＝０×ＣＦ、ブロック２３０
【００２０】
ＨＤＬＣおよびＰＰＰ方法の実施形態は、１つの特徴を除き、全て同様である。ＰＰＰは、“解読”サブステップ２４２（図２）を有しているが、ＨＤＬＣは有していない。以下、ＨＤＬＣについて詳細に説明する。また、ＰＰＰについては、ＨＤＬＣとの差異に関するものについてのみ、別個に説明する。
www.ietf.orgから利用できるＩＥＴＦ規格ＲＦＣ−２６１５は、ＳＯＮＥＴ／ＳＤＨ全体にわたってポイント・ツー・ポイント・プロトコル（ＰＰＰ）を実行する方法について定める。ＩＰパケットがＰＰＰヘッダー内にカプセル化され、フレームチェックシーケンス（ＦＳＣ）トレーラが加えられる。その後、ＨＤＬＣバイトスタッフィングが行なわれる。その後、同期スクランブラが選択的に使用される。Ｘ＾４３＋１スクランブリングを伴うＰＰＰを示すために、パス信号ラベル（Ｃ２）が０×１６に設定される。スクランブリングがｏｆｆとなるように構成された場合、スクランブリングが無いＰＰＰを示すために、パス信号ラベルの代わりに値０×ＣＦが使用される。
ＨＤＬＣバイトスタッフィングは、制御エスケープバイト０×７ｄを使用して、フラグバイト０×７Ｅおよび制御エスケープバイトがパケットペイロード内に全く現われないようにする。ある場合には、他のバイトが同様に消去される。ＩＥＴＦ ＲＦＣ−１６６２規格は、バイトスタッフィング処理に関して十分な説明を含んでいる。
【００２１】
ＨＤＬＣ２３０における一定の縦列除去：
ＲＦＣ−１６６２規格は、幾つかのＳＯＮＥＴおよびＳＤＨコンテナ内で、ＨＤＬＣがＳＰＥペイロード全体を占めないことを定める。ＳＴＳ−１において、縦列３０および５９は、一定のままである。この規格にもかかわらず、ＨＤＬＣフレームによって使用されるペイロードの一部としてこれらの縦列を統合する実施が幾つか成されている。ＳＤＨ Ｖｃ−４−Ｎｃ（Ｎ＝４，１６，６４（ＳＴＳ−１２ｃ−ＳＰＥ、ＳＴＳ−４８ｃ−ＳＰＥ、ＳＴＳ−１６ｃ−ＳＰＥに相当））において、最初のＮ−１個の縦列は、データに関して同様に使用されないが、一定の値バイトと共に使用されず且つ存在しない。もう一度、現在の実施において、幾らかのユーザは、これらの縦列を使用して、データを転送する。
圧縮アルゴリズムは、これらの縦列がデータを運ぶか否かを知ることが必要である。縦列がデータを運ばない場合、ペイロードを解読する前にこれらの縦列を除去することが好ましい（後述するＰＰＰ方法の実施形態において）。スクランブリングが行なわれない場合であっても、未使用の縦列を除去して圧縮を向上させることが好ましい。
ＳＤＨ Ｖｃ−４−Ｎｃコンテナ内の一定の縦列の数は、奇数であるため、これらの縦列の除去によってＢ３バイトのパリティ計算が変わる可能性がある。Ｂ３バイトがパケット網を通じて運ばれる場合、入口パケタイザは、残存するＳＰＥペイロードのパリティだけを含むように、Ｂ３バイトを再計算する。一定のスタッフバイトが一定のバイトを運ぶ場合、それらのビットパリティも同様に一定である。新たなＢ３バイトは、一定の縦列から得られる１つのバイトを用いて、入力されるＢ３のビット方向パリティと等しくなるように計算される。計算がＳＰＥペイロードのパリティの再計算を含まないので、終端間でエラーを検出するＢ３の役割が広がる。なお、ＳＯＮＥＴ／ＳＤＨ規格は、他の目的（タンデム接続）のために中間ノードでＢ３バイトが同様の方法で再計算される他の状況を定めることに注目せよ。出口パケタイザは、スタッフ縦列を０バイトで満たすことができ、あるいは、Ｂ３値を同じ方法で再計算することができる。
【００２２】
ＨＤＬＣ圧縮、ブロック２３２：
ＨＤＬＣ ＳＯＮＥＴペイロードを圧縮するため、前述した通常（エスケープ値長さ）の圧縮方法を使用することができる。唯一の違いは、圧縮エスケープバイトとして０×ＦＦを使用する代わりに、ＨＤＬＣフラグバイト０×７Ｅが使用される点である。これにより、圧縮長さが最大で０×７Ｄ＝１２５バイトに制限される。ＨＤＬＣフラグバイト０×７Ｅを圧縮エスケープバイトとして使用すると、圧縮出力サイズが大きくなる可能性を最小限に抑えることができる。
他の代わりの簡単な予測圧縮アルゴリズムは、ＨＤＬＣフラグの後に長さを付加することにより、ＨＤＬＣフラグバイトだけを圧縮する。この実施形態において、ＨＤＬＣフラグバイトシーケンスは、そのシーケンスの長さに続けられる１つのＨＤＬＣフラグバイトに取って代わられる。これは、２つ以上のＨＤＬＣフラグのシーケンスが現われる（２つ以上のバイトのフレーム間のギャップ）時にはいつでもバイトを確保する。この圧縮方法は、圧縮された出力の拡張の可能性を制限するので、安全である。圧縮比は、ＰＰＰ回線の使用ごとに予測する。その利用可能な帯域幅の半分を使用するＰＰＰ回線は、パケットインフラ構造にわたって運ばれる時に帯域幅の約半分を消費する。したがって、ＰＰＰ回線の圧縮比が制御される場合、実施に際しては、パケット送信網から必要とされるリソースだけを保存することができる。
【００２３】
ＰＰＰ解読 ブロック２４２：
情報にスクランブルがかけられると、簡単な圧縮では所望の結果が得られない。したがって、データの解読が必要とされる。スクランブラの概要を以下に示す（ＲＦＣ−２６１５から抜粋）。

【００２４】
入口パケタイザは、ペイロードの圧縮前に、受信側のスクランブラを作動させる。出口パケタイザは、パケットペイロードの解凍後であって且つバイトストリームをＳＯＮＥＴインタフェース内に挿入する前に、送信側のスクランブラを作動させる。
ＲＦＣ−２６１５は、最初の４３ビットスクランブラシード（すなわち、シフトレジスタの最初のコンテンツ）を送信器によって無作為に選択して、動作の安全性を向上させることを定める。その結果、開始動作またはリフレーム動作に続く最初の４３個の送信ビットは、正確にスクランブルが解かれない。パケット網の入口点および出口点で行なわれる別個の解読および再スクランブリングは、２つのスクランブラが同期している限り、パケットコンテンツを変更しない。入口および出口スクランブラによって使用される最初のシードは、同じでなければならない。さもなければ、最初の４３個のビットは、その最初の値に戻るべくスクランブルがかけられず、Ｂ３パリティが機能しなくなる。
パケットが失われると、同期が損なわれる。入口パケタイザは、フレームが失われたことを認識せず、データを解読し続ける。しかし、出口パケタイザは、再同期化のため、最後の４３ビットを推測することができない。例えば、各パケットが１つのＳＰＥペイロードを運ぶと仮定する。また、ｎ番目のパケットが出口パケタイザに到達しないと仮定する。出口パケタイザは、ｎ＋１番目のパケットを受けると、ｎ番目のパケットが失われていることを知る。出口パケタイザは、このエラー状態を処理する必要がある。また、出口パケタイザは、この１つの失われたパケットに対するエラー状態の影響を最小限に抑える必要がある。出口スクランブラは、ｎ＋１番目のパケットが到達すると、入口アンスクランブラおよびＴＤＭ回線上のＳＯＮＥＴパスの終端にあるアンスクランブラの両方との同期が失われたことを知る。フレームが失われ、あるいはＳＰＥが崩壊する場合、同期が失われるのは、当然のことである。しかし、必要以上のダメージをこれ以上受けないように、パケット損失の影響を最小限に抑える必要がある。Ｂ３パリティバイトがパケット網を通じて運ばれると、ｎ＋２番目のパケットによって運ばれるＢ３バイトは、ｎ＋１ＳＰＥのビットパリティを保持する。スクランブラは、入口アンスクランブラとの同期が失われているため、パケットの最初のコンテンツを再構成することができず、したがって、パリティが破壊される。
【００２５】
この問題に対しては２つの解決策がある。最も明白な解決策は、ｎ＋２番目のパケットのＢ３パリティバイトを再計算することである。その場合の欠点は、このＳＰＥに関してエンド・ツー・エンド（終端間）パリティチェックが損なわれるという点である。他の解決策は、入口アンスクランバと出口スクランバとを常に同期させることである。これは、先のＳＰＥの最後の４３ビット（バイトアライメントを維持するための４８ビット）を各パケットに加えることにより行なうことができる。出口パケタイザは、パケットが失われることを知ると、これらの４３ビットを使用して、出口スクランブラを再び同期させる。この時、出口スクランブラは、ＳＰＥペイロードにスクランブルをかけ始める前に、これらの４３ビット（または４８ビット）にスクランブルをかける。
非同期ＤＳ−３ Ｃ２＝０×０４，ブロック２５０
Ｃ２＝０×４である時、ＳＯＮＥＴ ＳＴＳ−１は、非同期ＤＳ−３ ４４．７３６Mbit/sチャンネルを運ぶ。ＳＴＳ−１のＳＰＥへの非同期ＤＳ−３マッピングは、以下のように構成される。
１．縦列３０および５９は、全く使用されず、一定のバイトを運ぶ。
２．縦列２，３，３１および６０は、一定のバイトを運ぶ。
３．他のバイトは、情報ペイロードビットを運ぶ。
この実施形態において、圧縮方法は、圧縮されていない情報ペイロードバイトと、未使用の一定のバイトとを分ける。特に、この方法は、以下のことを行なう。
ペイロードから一定の未使用の縦列２，３，３０，３１，５９および６０を除去する。
【００２６】
この明細書で言及した全ての刊行物、特許および特許出願は、あたかも各個々の刊行物、特許または特許出願が具体的に且つ個別に示唆されて参照によりここに組み込まれると同程度に、これらを参照することにより、その全体が本明細書中に組み込まれる。更に、この出願における任意の引例の引用または識別表示は、そのような引例が本発明に対して従来技術として利用可能であるということを認められたものと解釈されるべきではない。
限られた数の実施形態に関して本発明を説明してきたが、本発明は、多くの変形、改良を成すことができ、また、他の用途に適用できることは、言うまでもない。
【図面の簡単な説明】
【００２７】
【図１】本発明のシステムの好ましい実施形態のブロック図を示している。
【図２】Ｃ２バイトの検査に基づいて実施される本発明の圧縮方法またはアルゴリズムの様々な実施形態のブロック図を示している。
【符号の説明】
【００２８】
５０ システム、１００ 入口パケタイザ、１００’ 出口パケタイザ、１０２、１３０ ＳＯＮＥＴインタフェース、１０４、１０４’ ＳＯＮＥＴプロセッサ、１０６ 圧縮装置、１０６’ 解凍装置、１０８、１０８’ パケットプロセッサ、１１０ 第１のパケットインタフェース、１１２ 第２のパケットインタフェース、１２０ パケット交換網。

Claims (18)

1. パケット化されたＳＯＮＥＴ／ＳＤＨストリームをパケット交換網を通じて送信するために圧縮する方法であって、
   i．ストリーム中でＣ２バイトを識別し、
   ii．前記識別に基づいて、Ｃ２バイト関連圧縮アルゴリズムを適用して、ストリームを圧縮する、
   ことを含むパケット化されたＳＯＮＥＴ／ＳＤＨストリームの圧縮方法。
2. Ｃ２バイトを識別する前記ステップは、ストリームから前記Ｃ２バイトを抽出することを含む請求項１に記載の方法。
3. Ｃ２バイトを識別する前記ステップは、予め構成されたＣ２情報を使用することを含む請求項１に記載の方法。
4. Ｃ２バイトを識別する前記ステップは、
   i．前記Ｃ２圧縮を適用するように構成された入口パケタイザを設け、前記Ｃ２圧縮の結果、圧縮されたストリームが送信され、
   ii．前記送信された圧縮ストリームを受けて解凍するように構成された出口パケタイザを設け、
   iii．前記出口パケタイザから前記入口パケタイザに送り返されたＳＯＮＥＴ回線を検査する、
   ことを含む請求項１に記載の方法。
5. Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、用意ができていないＣ２＝０×０圧縮アルゴリズムを適用することを含む請求項１に記載の方法。
6. Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、仮想トリビュタリＣ２＝０×０２圧縮アルゴリズムを適用することを含む請求項１に記載の方法。
7. Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、ＨＤＬＣ Ｃ２＝０×１６圧縮アルゴリズムを適用することを含む請求項１に記載の方法。
8. Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、ＰＰＰ Ｃ２＝０×ＣＦ圧縮アルゴリズムを適用することを含む請求項１に記載の方法。
9. Ｃ２バイト関連圧縮アルゴリズムを適用する前記ステップは、非同期ＤＳ−３ Ｃ２＝０×０４圧縮アルゴリズムを適用することを含む請求項１に記載の方法。
10. 仮想トリビュタリＣ２＝０×０２圧縮アルゴリズムを適用する前記ステップは、
    i．ストリーム中に含まれる複数のＳＰＥ縦列およびＳＰＥ横列から一定の縦列を除去するサブステップと、
    ii．前記ＳＰＥ縦列を再配列して、再配列縦列を得るサブステップと、
    iii．前記再配列ＳＰＥ縦列と前記ＳＰＥ横列との間で反転させて、変換ストリームを形成するサブステップと、
    iv．前記変換ストリームを圧縮するサブステップと、
    を更に含む請求項６に記載の方法。
11. 前記複数のＳＰＥ縦列から一定の縦列を除去する前記サブステップは、前記ＳＰＥ縦列の縦列３０および５９を除去することを含む請求項１０に記載の方法。
12. 縦列を再配列する前記ステップは、
    i．前記ＳＰＥ縦列のＶＴＧアライメントを行なうサブステップと、
    ii．前記ＳＰＥ縦列間でインターＶＴＧアライメントを行なうサブステップと、
    によって、ストリームのＶＴコンテンツを再配列することを更に含んでいる請求項１０に記載の方法。
13. インターＶＴＧアライメントを行なう前記サブステップは、ＶＴ１．５ｓに関して最適化する第１のプロセス、ＶＴ２ｓに関して最適化する第２のプロセス、およびＶＴ１．５ｓとＶＴ２ｓとの組み合わせに関して最適化する第３のプロセスから成るグループから選択される縦列再配列プロセスを行なうことを含む請求項１２に記載の方法。
14. ＨＤＬＣ Ｃ２＝０×１６圧縮アルゴリズムを適用する前記ステップは、
    i．ストリーム中に含まれる複数のＳＰＥ縦列およびＳＰＥ横列から一定の縦列を除去して、変換ストリームを得るサブステップと、
    ii．前記変換ストリームを圧縮するサブステップと、
    を更に含む請求項７に記載の方法。
15. 前記変換ストリームを圧縮する前記サブステップは、（０×ＦＤ，長さ）を使用した変換ストリームの圧縮と、（０×ＦＤ値，長さ）を使用した変換ストリームの圧縮とから成るグループから選択されるデータ圧縮処理を含んでいる請求項１４に記載の方法。
16. ＰＰＰ Ｃ２＝０×ＣＦ圧縮アルゴリズムを適用する前記ステップは、
    i．ストリーム中に含まれる複数のＳＰＥ縦列およびＳＰＥ横列から一定の縦列を除去して、変換ストリームを得るサブステップと、
    ii．データストリームを解読するサブステップと、
    iii．前記変換ストリームを圧縮するサブステップと、
    を更に含む請求項８に記載の方法。
17. 前記変換ストリームを圧縮する前記サブステップは、（０×ＦＤ，長さ）を使用した変換ストリームの圧縮と、（０×ＦＤ値，長さ）を使用した変換ストリームの圧縮とから成るグループから選択されるデータ圧縮処理を含んでいる請求項１６に記載の方法。
18. 非同期ＤＳ−３ Ｃ２＝０×０４圧縮アルゴリズムを適用する前記ステップは、前記複数のＳＰＥ縦列から一定の且つ未使用の縦列２，３，３０，３１，５９および６０を除去することを含む請求項９に記載の方法。

Images