JP2015109544A - 無線通信システム - Google Patents

Abstract

【課題】
パケット欠落/順序逆転の対策を不要とするので、送受信ノードのCPU/メモリ資源の過大な消費を抑制し、パケットの圧縮効率・圧縮計算効率を高くする。
【解決手段】
無線通信システムは、圧縮用コンテキストを用いて複数のショートパケットを圧縮する圧縮処理部、圧縮した複数のショートパケットと圧縮用コンテキストとをジャンボフレームに格納するフレーム処理部、及び、ジャンボフレームを送信するU-Plane処理部を有する送信ノード、並びに、送信されたジャンボフレームを受信する受信ノードを有する。
【選択図】図１１

Description

本発明は、無線通信システムに関わり、特に無線システムなどのバックホール区間における、パケット圧縮に関する。

近年、スマートフォンの普及に伴い、無線システムのネットワーク負荷が増大しており、帯域利用の効率化技術の重要性が増している。帯域利用の効率化技術の一つとして、パケットを圧縮して帯域使用量を削減する技術が広く普及している。また、複数のパケットを纏めて送信することで、ネットワーク負荷を下げる技術が存在する。

非特許文献1及び非特許文献2では、送信ノードは、パケットヘッダ情報のうち、直前に送信したパケットとの差分情報を送信し、パケットヘッダ中で変化が無い又は受信ノードで再現可能な情報の送信を省くことで、パケットサイズの圧縮を実現している。受信ノードは、直前に受信したパケットの解凍後のヘッダ情報(コンテキスト)を保持しており、これと受信した差分情報とから、元の情報（送信ノードが送信しようとした情報）を再現できる。

この方法では、ネットワーク上でパケットの欠落や到着順序の逆転が発生すると、送信ノードと受信ノードとの間で、認識するコンテキストにずれが生じるため、元の情報の再現に失敗する。この状態を、ノード間でコンテキスト同期が外れた状態と呼ぶ。

非特許文献1及び非特許文献2では、コンテキスト同期外れへの対策として、下記の手段を採用している。
・何らかの手段を用い、解凍の前段階で、パケット到着順序を保証する。例えば、圧縮通信を、PPP（Point-to-Point Protocol）等の到着順序保証されたリンクでのみ、実施する。
・同期外れを検出後に、再同期を実行する。具体的には、コンテキスト同期外れにより、解凍に失敗した受信ノードは、送信ノードに対して非圧縮パケットの送信を要求する。送信ノードは上記要求を受けて、圧縮を停止し、非圧縮のパケット送信を開始する。受信ノードは非圧縮パケットを受信したら、その旨を送信ノードに通知する。これにより、送信ノードと受信ノードの間で、再びコンテキストが一致したことの合意が取れるので、圧縮通信が再開可能となる。

非特許文献3では、様々なアルゴリズムを使用し、IPパケットのペイロードを圧縮する。具体的な圧縮計算アルゴリズムは規定されていないが、パケットの欠落や到着順序の逆転に備えて、下記の手段を採用している。
・あるパケットを圧縮する際に、当該パケット内に記載された情報のみを用いる。これにより、他パケットが欠落・順序逆転した場合でも、その影響を受けず、解凍が可能となる。

非特許文献4では、半二重ギガイーサ通信において、フレームバーストが規定されている。これは、従来は最小フレーム長以下の小さなフレームはパディングを付与するところを、複数個の小さなフレームを纏めて大きなフレームとして送信することで、パディングによるオーバーヘッドを減らす技術である。

特許文献１では、複数のIPパケットを一つのIPパケットに纏めて送信することで、ネットワークの負荷を軽減している。

特開平１１−７４３３号公報

RFC1144 Compressing TCP/IP Headers RFC4815 RObust Header Compression RFC2393 IP Payload Compression Protocol IEEE 802.3ab 1000BASE-T

非特許文献１及び非特許文献２では、パケット到着順序保証のために、順序保証特性を持つシリアルリンクしか利用できない、若しくは順序逆転したパケットを並べ替える処理により、CPU/メモリ資源を消費する。また、コンテキストの同期処理とコンテキストの記憶処理のために、CPU/メモリ資源を消費する。さらに、一度、同期が外れた場合、再同期がとれるまで、圧縮通信は行えない。かつ再同期のための非圧縮パケットが送信されるまで、解凍不能な圧縮パケットが送信され、通信帯域を無駄に消費する。

非特許文献３では、もし複数パケットに跨って冗長な情報が有った場合でも、それを利用した圧縮は実施しない仕様規定であるので、ヘッダ部分の圧縮効率に限れば、非特許文献１及び非特許文献２のようなコンテキストを利用する方式に比べ、圧縮効率が低くなる。また、辞書式圧縮のアルゴリズムを用いる場合、1つのパケットを送信する度に、辞書のリセット・再学習が必要なので、圧縮計算に必要な時間も増大する。

以上のように、既存のパケット圧縮技術における、パケット欠落/順序逆転の対策は、対策処理の実行に伴いノードのCPU/メモリ資源を消費する、又は圧縮効率・圧縮計算効率を犠牲にするといったデメリットがある。

開示する無線通信システムは、圧縮用コンテキストを用いて複数のショートパケットを圧縮する圧縮処理部、圧縮した複数のショートパケットと圧縮用コンテキストとをジャンボフレームに格納するフレーム処理部、及び、ジャンボフレームを送信するU-Plane処理部を有する送信ノード、並びに、送信されたジャンボフレームを受信する受信ノードを有する。

本発明によれば、パケット欠落/順序逆転の対策を不要とするので、送受信ノードのCPU/メモリ資源の過大な消費を抑制し、パケットの圧縮効率・圧縮計算効率を高くすることができる。

無線通信システムの構成図である。 ショートパケットの構造の一例である。 ジャンボフレームの構造の詳細である。 ミドルフレームの構造の詳細である。 分割後のジャンボフレームの構造の詳細である。 送信ノードの構成図である。 送信ノード内の圧縮ネゴ管理テーブルである。 送信ノード内のセッション情報テーブルである。 バッファ管理テーブルである。 アルゴリズム優先順位テーブルである。 送信ノードによる送信処理のフローチャートである。 圧縮ネゴのためのパケットフォーマットである。 圧縮ネゴの初回のシーケンス図である。 圧縮ネゴの再ネゴのシーケンス図である。 受信ノードの構成図である。 受信ノード内の圧縮ネゴ管理テーブルである。 受信ノード内のセッション情報テーブルである。 受信ノードによる受信処理のフローチャートである。 中継ノードの構成図である。 中継ノード内の圧縮ネゴ管理テーブルである。 中継ノードによる中継処理のフローチャートである。

図１に、本実施形態の無線通信システムの構成図を示す。無線通信システムは、データを送受信する送信ノード１１、中継ノード１２、および受信ノード１３がバックホール１４に接続されており、例えば携帯電話等の無線端末１５と無線端末の通信対象１６（たとえば、サーバ）間の通信データ（たとえば、通信対象１６から無線端末１５へのダウンロードデータ）の経路となっている。この無線通信システムにおいて、送信ノード１１から受信ノード１３へのバックホール１４を流れるショートパケットデータの圧縮通信を行う。

図２に、ショートパケットの構造の一例として、GRE（Generic Routing Encapsulation）カプセリングされたショートパケット２１０１を示す。通信対象１６はIPヘッダ２１０５及びペイロード２１０６から構成されるInnerパケットを送信ノード１１へ送信する。IPヘッダ２１０５の宛先アドレスは、無線端末１５のアドレスである。

非圧縮通信の場合、送信ノード１１が、このInnerパケットに、Ethヘッダ２１０２、IPヘッダ２１０３、及びGREヘッダ２１０４から構成されるOuterヘッダを付与し、カプセリングを行う。Ethヘッダ２１０２の宛先アドレスは、送信ノード１１が接続するルーターのMACアドレスである。IPヘッダ２１０３の宛先アドレスは、受信ノード１３のIPアドレスである。GREヘッダ２１０４は、受信ノード１３が、通信端末１５を特定する為のGRE Key情報を持つ。以降、このショートパケットを例として説明する。

図３に、ジャンボフレームの構造の詳細を示す。ジャンボフレーム２２０１は標準のEthヘッダ２２０２、フレーム終端（FCSフィールド等）２２０６を持つ。また標準のIPヘッダ２２０３を持ち、IPヘッダ２２０３が示す宛先は受信ノード１３宛である。ジャンボフレームのサイズは、中継ノード１２と送信ノード１１との間の、Path MTU（Maximum Transmission Unit）以下である。

ジャンボフレーム２２０１のペイロード部分に、圧縮情報領域を設ける。圧縮情報領域の各領域について説明する。

・コンテキスト・辞書領域２２０４
圧縮に使用するコンテキスト・辞書に関する情報を示す。この領域２２０４は、コンテキスト・辞書領域全体長領域２２０７と、Outer領域２２０８と、レイヤ毎の情報領域に分かれる。
コンテキスト・辞書領域全体長２２０７(13bit)
コンテキスト・辞書領域２２０４全体の長さを示し、最長2^13=8KBである。
Outer(3bit)
圧縮されたヘッダの内、Outerヘッダ部分の、レイヤの数であり、中継ノードがヘッダ解凍する際、このレイヤ数分のみ、解凍する。
図２のショートパケット２１０１の例では、１（GREヘッダのみ）である。
Innerヘッダ以降を解凍する無駄手順を省くための情報であり、最大2^3＝8レイヤである。Outerが9レイヤ以上のパケットは無い。
第一レイヤ
ショートパケットの、一番目のレイヤの圧縮に関する情報を示し、図２のショートパケット２１０１の例では、GREヘッダ２１０４を示す。
アルゴリズム２２０９(4bit)
第一レイヤの圧縮に使用する、圧縮アルゴリズム名を示す。2^4＝16種類の圧縮アルゴリズム名を表すことができる。
第一レイヤコンテキスト・辞書長２２１０(12bit)
第一レイヤコンテキスト・辞書情報のフィールド２２１１の長さ(byte)を示す。最長は4096byteである。
第一レイヤコンテキスト・辞書情報(可変長)２２１１
第一レイヤの圧縮に使用する、コンテキスト又は辞書情報を格納する。コンテキスト及び辞書情報の内容は、各圧縮アルゴリズムの標準規定に準拠する。
第二レイヤ
ショートパケットの、二番目のレイヤに関する情報を示し、図２のショートパケット２１０１の例では、IPヘッダ２１０５を示す。領域構造は第一レイヤと同様であるので、説明を省略する。

以降、同様の領域構造を、最終レイヤまで繰り返す。図２のショートパケットの２１０１例では、最終レイヤは第三レイヤであり、ペイロード２１０６である。

・ミドルフレーム領域２２０５
ミドルフレーム領域２２０５は、圧縮されたデータが格納される。圧縮データは、後述するミドルフレームという形式に、分割されて格納される。これは、中継ノード１２がジャンボフレーム２２０１を分割して転送する処理において、ジャンボフレーム２２０１を解凍・再圧縮せずに分割できるように、予めこのミドルフレーム単位で分割しておく。詳細は後述する。

図４にミドルフレームの構造の詳細を示す。ミドルフレーム２３０１は、第一レイヤ長２３０２、第二レイヤ長２３０３、・・・、最終レイヤ長２３０４のデータ長領域と、圧縮後第一レイヤ２３０５、圧縮後第二レイヤ２３０６、・・・、圧縮後最終レイヤ２３０７の圧縮データ領域で構成される。

（1）データ長領域(2byte×N)
この領域は、下記(2)で示す、圧縮後データの長さ（レイヤ長）を格納する。長さはレイヤ毎に分けて記述し、たとえば、圧縮後第一レイヤ長＝0x00FF、圧縮後第二レイヤ長＝0x0FFFのように、各レイヤの長さを2byteで表現する。

（2）圧縮データ領域(可変長)
この領域は、レイヤ毎の圧縮後データを格納する。圧縮後データには、複数のショートパケットの圧縮後データが含まれる。図２のショートパケット２１０１の例では、圧縮後第一レイヤ（1パケット目のGREヘッダ、2パケット目のGREヘッダ、・・・）、圧縮後第二レイヤ（1パケット目のIPヘッダ、2パケット目のIPヘッダ、・・・）、圧縮後最終レイヤ（1パケット目のペイロード、2パケット目のペイロード、・・・）である。

なお、ミドルフレームのサイズは、受信ノード１３と中継ノード１２との間のPath MTU結果を元に、次式を満足する。
（ミドルフレーム）＋（コンテキスト・辞書領域）＝（分割後ジャンボフレーム）≦（受信Path MTU）
図５に、中継ノード１２で分割後のジャンボフレームの構造の詳細を示す。
分割後のジャンボフレーム２４０１の構造は、図３のジャンボフレーム２２０１とほぼ同じであるが、含まれるミドルフレームは一つ（図５では、第Ｎミドルフレーム）である。分割後ジャンボフレーム２４０１のサイズは、受信ノード１３と中継ノード１２との間のPath MTU以下となるようにする（前述の式参照）。分割後のジャンボフレーム２４０１に含まれる各ミドルフレームは、共通のコンテキスト・辞書情報を使用して圧縮されるので、どのミドルフレームも、ジャンボフレーム２２０１中のコンテキスト・辞書情報で解凍可能である。たとえば、圧縮後の第一ミドルフレームは第一レイヤコンテキスト・辞書情報２２１１で解凍可能である。

図６に、送信ノードの構成を示す。送信ノード３１００(図１の１１)は、IP網と接続するインターフェイス（IP-IF）３１０１と、各種処理を実行するCPU３１０２と、このCPU３１０２のワークエリアとなるＲＡＭ３１０３を持つ。送信ノード３１００は、IP-IF３１０１経由でIP網と接続している。

CPU３１０２は、ユーザデータパケットの送受信処理を実行するU-Plane処理部３１０４、受信ノード１３との呼制御（回線制御）を実行するC-Plane処理部３１０５、パケットの圧縮処理を実行する圧縮処理部３１０６、フレーム組立を実行するフレーム処理部３１０７、受信ノード１３及び中継ノード１２と圧縮能力のネゴ(ネゴシエーション)処理を実行する圧縮ネゴ処理部３１０８、フレームを格納する各バッファを管理するバッファ管理部３１０９、並びに、圧縮アルゴリズムを選択するアルゴリズム選択処理部３１１４(図中、アルゴリズム選択部）を持つ。

ＲＡＭ３１０３には、圧縮ネゴ処理部３１０８により作成される圧縮ネゴ管理テーブル３１１３が格納される。図７に、圧縮ネゴ結果管理テーブル３１１３を示す。圧縮ネゴ結果管理テーブル３１１３には、宛先受信ノード１３のIPアドレス２５０２、宛先受信ノード１３までの経路のPathMTU結果２５０３、中継ノードのPathMTU結果２５０４、及び宛先受信ノード１３までの経路の対応圧縮アルゴリズムのリスト２５０５が格納されている。対応圧縮アルゴリズムのリスト２５０５には、図７に示すように、レイヤ毎の対応圧縮アルゴリズム情報が含まれる。圧縮アルゴリズム情報は、第一レイヤのアルゴリズム、第二レイヤのアルゴリズム、・・・という形式で、表現方式はビットマスク(16bit列)である。たとえば、1bit目が立っていれば(１ならば)LZW対応、2bit目が立っていればVJ対応等々である。また、圧縮ネゴ結果管理テーブル３１１３の開始行(図示略)には、予め管理者により設定された送信ノード１１自身のMTUと、予め管理者により設定された送信ノード１１自身の対応圧縮アルゴリズムのリストとが格納されている。

ＲＡＭ３１０３は、C-Plane処理部３１０５により確立されたセッションに関するセッション情報テーブル３１１０を持つ。図８に、セッション情報テーブル３１１０を示す。セッション情報テーブル３１１０には、端末１５の端末IPアドレス２６０２、端末１５が収容される受信ノード１３のIPアドレス２６０３、当該セッションを一意に特定するセッションID２６０４、および対応するバッファを一意に特定するバッファID２６０５が格納されている。

ＲＡＭ３１０３には、確立したセッション毎に、フレーム処理部３１０７により作成される、組立途中のフレームを格納する、バッファ３１１１が設けられている。ＲＡＭ３１０３には、各バッファ３１１１を管理するバッファ管理部３１０９により管理される、バッファ管理テーブル３１１２が設けられている。図９に、バッファ管理テーブル３１１２を示す。バッファ管理テーブル３１１２には、バッファID２７０３に対応させて、バッファ初期化時刻２７０４、圧縮ネゴ結果管理テーブル３１１３からコピーされた、当該受信ノードまでの経路のPathMTU結果２７０５及び中継ノードのPathMTU結果２７０６、各レイヤで使用する圧縮アルゴリズム２７０７が格納されている。また、図示を省略するが、管理者により予め設定された滞留時間上限が、バッファ管理テーブル３１１２またはＲＡＭ３１０３の所定の領域に格納されている。

ＲＡＭ３１０３には、管理者によりあらかじめ設定された圧縮アルゴリズム優先順位を格納するアルゴリズム優先順位テーブル３１１５ が設けられている。図１０に、アルゴリズム優先順位テーブル３１１５を示す。アルゴリズム優先順位テーブル３１１５は、圧縮アルゴリズム２８０３のビットマスク(16bit列)のbit毎の、優先順位２８０４を格納する。たとえば、図示するように、16bit目（最上位ビット）の優先順位16位、15bit目は1位のように格納する。

図１１に、送信ノード３１００(図１の１１)による圧縮フレームの送信処理のフローチャートを示す。処理開始時、バッファ管理部３１０９は、バッファ管理テーブル３１１２をチェックし、満了しているタイマの有無を確認する(Ｓ１１００)。具体的には、バッファ管理テーブル３１１２の各行毎のバッファ初期化時刻２７０４と、現時点の時刻を比較し、その差分が管理者により予め設定された滞留時間上限を超えているか否かを確認する。滞留時間上限を超えていれば、そのタイマは満了している。満了しているタイマ（満了タイマ）が存在しない場合、Ｓ１１０４に進む。

満了タイマが存在する場合、満了タイマに対応するバッファID２７０３によりバッファを特定し、フレーム処理部３１０７を呼び出す。フレーム処理部３１０７は当該バッファの内容をジャンボフレーム２２０１としてU-Plane処理部３１０４経由で、受信ノード１３宛に送信する(Ｓ１１０１)。送信後、フレーム処理部３１０７は当該バッファ内容を初期化(データ消去、新たなジャンボフレーム領域・ミドルフレーム領域をバッファ内に確保)する(Ｓ１１０２)。

バッファ管理部３１０９は、バッファ管理テーブル３１１２の、初期化したバッファのバッファID２７０３に対応するバッファ初期化時刻２７０４を、現在時刻に初期化する（Ｓ１１０３）。また、バッファ管理部３１０９は、アルゴリズム選択処理部３１１４を呼び出し、各レイヤで使用する圧縮アルゴリズムを選択し、バッファ管理テーブル３１１２の圧縮アルゴリズム２７０７に格納する。圧縮アルゴリズムの選択方法は、圧縮ネゴ結果管理テーブル３１１３に格納されている対応圧縮アルゴリズム２５０５の中から、アルゴリズム優先順位テーブル３１１５に従って、最も高い優先順位の圧縮アルゴリズムを選択する。その後、Ｓ１１００に戻る。

満了タイマが存在しない場合、U-Plane処理部３１０４は、パケット受信の有無を判定する（Ｓ１１０４）。パケット受信が無い場合、Ｓ１１００に戻る。パケット受信が有る場合、受信パケット（図２のショートパケット２１０１のInnerパケット部分）のIPヘッダ２１０５の宛先IPアドレスに対応する、セッション情報テーブル３１１０に格納されている端末IPアドレス２６０２を取得する。取得した端末IPアドレス２６０２に対応する、セッション情報テーブル３１１０のセッションID２６０４を特定し、また受信パケットを送信すべき受信ノード１３のIPアドレス２６０３を取得する(Ｓ１１０５)。

U-Plane処理部３１０４は、取得した受信ノードIPアドレス２６０３と一致する、圧縮ネゴ結果管理テーブル３１１３に格納されている宛先受信ノード１３のIPアドレス２５０２に対応する、受信ノード１３までの経路の対応圧縮アルゴリズムのリスト２５０５を取得する。対応アルゴリズムリスト２５０５が非圧縮のみ(0x0000・・・・)であれば(Ｓ１１０６)、U-Plane処理部３１０４は受信パケットを圧縮せずにそのまま受信ノード１３に送信し(Ｓ１１０７)、Ｓ１１００に戻る。

対応アルゴリズムが非圧縮以外であれば(Ｓ１１０６)、フレーム処理部３１０７は、受信パケットに対応するバッファが存在するかを確認する(Ｓ１１０８)。バッファが存在すれば、Ｓ１１１２へ進む。セッション確立直後の初回のパケット受信時は、バッファを作成していない。バッファが存在しなければ、バッファ３１１１を新規に獲得する(Ｓ１１０９)。フレーム処理部３１０７は、獲得したバッファの内容を初期化(データ消去、新たなジャンボフレーム領域・ミドルフレーム領域をバッファ内に確保)する。

バッファ管理部３１０９は、バッファ管理テーブル３１１２に、獲得した新規のバッファ３１１１に対応する行を追加し、バッファ初期化時刻２７０４に、現在時刻を設定することによりタイマを初期化する(Ｓ１１１０)。バッファ管理部３１０９は、アルゴリズム選択処理部３１１４を呼び出し、各レイヤで使用する圧縮アルゴリズムを選択し、バッファ管理テーブル３１１２の圧縮アルゴリズム２７０７に格納する。圧縮アルゴリズムの選択方法は、圧縮ネゴ結果管理テーブル３１１３の対応圧縮アルゴリズム２５０５の中から、アルゴリズム優先順位テーブル３１１５の優先度２８０４に従い、最も高い優先順位の圧縮アルゴリズムを選択する。

圧縮処理部３１０６は、圧縮前のショートパケットを用いて、圧縮コンテキストまたは辞書の初期設定を行い（Ｓ１１１１）、フレーム処理部３１０７経由でバッファ３１１１内のジャンボフレーム２２０１に格納する。コンテキスト及び辞書２２０４の内容は、圧縮アルゴリズム次第なので格納せずに、フレーム処理部３１０７は、ジャンボフレーム２２０１内のコンテキスト・辞書領域２２０４の、各レイヤアルゴリズム（たとえば、２２０９）及び各レイヤコンテキスト・辞書長（たとえば、２２１０）を格納する。

次に、圧縮処理部３１０６は、受信パケットを圧縮する（Ｓ１１１２）。圧縮処理部３１０６は、受信パケットを圧縮するための圧縮アルゴリズムとして、バッファ管理テーブル３１１２に格納されている圧縮アルゴリズム２７０７を使用する。

受信パケットを圧縮する際、バッファ３１１１に格納されているジャンボフレーム２２０１にミドルフレームが一つしかない(第一ミドルフレーム)場合（Ｓ１１１３）、圧縮アルゴリズムにおける辞書学習を許容する（Ｓ１１１４）。解凍処理において、各ミドルフレームは、一つのコンテキスト・辞書を共用する。もし第二ミドルフレーム以降の圧縮で、辞書の内容を書き換えてしまうと、第一ミドルフレームの圧縮時に使用した辞書とは辞書内容が変わってしまうことになるので、第一ミドルフレームの解凍が不可能になる。したがって、第二ミドルフレーム以降では、辞書の書換えを禁止する。第一ミドルフレームの圧縮の際に辞書を更新するか否かは、圧縮アルゴリズム依存する。スライド辞書方式やハフマン符号化では、圧縮対象データが入力される都度、学習してよいし、辞書サイズを制限するために、途中で学習を打ち切っても良い。辞書サイズの大きさに比例して圧縮/解凍処理が重くなるので、どこかで打ち切るのが一般的である。辞書学習した場合、フレーム処理部３１０７はジャンボフレーム２２０１内の各レイヤにおいて、コンテキスト・辞書情報(たとえば、２２１１)と、コンテキスト・辞書長(たとえば、２２１０)を更新する。またコンテキスト・辞書領域全体長２２０７も更新する。

フレーム処理部３１０７は、該当セッションに対応するバッファ３１１１の残量を確認し、ジャンボフレーム２１０１に圧縮後のショートパケット２３０１を格納するに十分なバッファが残っているかを確認する（Ｓ１１１５）。具体的には、バッファ３１１１の現時点のジャンボフレームサイズと、バッファ管理テーブル３１１２に格納されている中継ノード１４までのPathMTU結果２７０７とを比較し、差分が圧縮後ショートパケット２３０１のサイズ以上か否かを確認する。現時点のジャンボフレームサイズがPathMTU結果２７０７より圧縮後ショートパケット２３０１のサイズ以上小さければ、バッファの残量は十分であり、バッファの残量が十分な場合、Ｓ１１２１に進む。

バッファ残量が不十分であれば、タイマ満了時の処理Ｓ１１０１と同様に、フレーム処理部３１０７は、バッファの内容をジャンボフレーム２２０１としてU-Plane処理部３１０４経由で受信ノード宛に送信する（Ｓ１１１６）。アルゴリズム選択処理部３１１４によるアルゴリズム選択も、タイマ満了時の処理と同様に行う。バッファの内容の送信後、フレーム処理部３１０７は、Ｓ１１０２と同様に、当該バッファ内容を初期化する（Ｓ１１１７）。また、バッファ管理部３１０９は、Ｓ１１０３と同様に、バッファ管理テーブル３１１２のバッファ初期化時刻情報２７０４を、現在時刻に初期化する（Ｓ１１１８）。アルゴリズム選択処理部３１１４によるアルゴリズム選択もタイマ満了時の処理と同様である。さらに、圧縮処理部３１０６は、Ｓ１１１１と同様に、圧縮前のショートパケットを用いて、圧縮コンテキスト・辞書の初期設定を行い、バッファ３１１１に格納する（Ｓ１１１９）。圧縮処理部３１０６は、初期設定したコンテキストまたは辞書を用いて、再度パケット圧縮をやり直す（Ｓ１１２０）。圧縮後、Ｓ１１２３に進む。

次に、フレーム処理部３１０７は、該当セッションに対応するバッファ３１１１の残量を確認し、ミドルフレームに圧縮後ショートパケットを格納することが可能かを確認する（Ｓ１１２１）。具体的には、バッファ３１１１の現時点のミドルフレームサイズと、ジャンボフレーム２２０１の、バッファ管理テーブル３１１２に格納されている受信ノード１３までのPathMTU結果２７０５とを比較し、差分が圧縮後ショートパケット２３０１とコンテキストまたは辞書領域全体長２２０７の合計値以上か否かを確認する。バッファ残量が十分な場合、Ｓ１１２３に進む。

バッファ残量が不十分であれば、フレーム処理部３１０７は、ミドルフレームを分割する（Ｓ１１２２）。具体的には、ジャンボフレーム２２０１の現時点のミドルフレームを書込み禁止とし、次のミドルフレーム領域をジャンボフレーム２２０１内に確保する。たとえば、いまジャンボフレーム２２０１内に第Nミドルフレームがあれば、第N+1ミドルフレーム領域を確保する。

フレーム処理部３１０７は、圧縮後ショートパケットを、バッファ３１１１内のジャンボフレーム２２０１のミドルフレーム２２０５内に格納する（Ｓ１１２３）。その際、ミドルフレーム２３０１内の各レイヤ長領域２３０１、・・、２３０４を更新する。その後、Ｓ１１００に戻る。

図１２に圧縮ネゴのためのパケットフォーマットを示す。圧縮ネゴパケット４００１は、標準のPath MTU 探索のICMP（Internet Control Message Protocol）パケット（ＩＰヘッダ４００２、ＩＣＭＰヘッダ４００３を有する）のペイロード４００８に、Rビット４００４、alg数４００５、中継Path MTU４００６、及び対応アルゴリズムリスト４００７の領域を追加する。

Rビット４００４は、1bitのネゴノード有無を示すフラグであり、送信ノード１１は、R=0で圧縮ネゴパケットを送信する。受信ノード１３は、応答パケット送信時、Rビットを立てて（R=1）応答する。送信ノード１１は、R=1の応答を受信した場合、圧縮が可能と判断する。送信ノード１１は、R=0の応答を受信した場合、圧縮不可と判断、alg数４００５以降の領域を無視する。

alg数４００５は、3bitで、対応アルゴリズムリスト４００７の数を表す。alg数４００５の最大は2^3＝8個である。

中継Path MTU４００６は、12bitで、中継ノード間のPathMTU値を表す。送信ノード１１は、中継Path MTU４００６を０にして、圧縮ネゴパケット４００１を送信する。中継ノード１２は、応答パケットの中継時、中継Path MTU４００６を送信ノード１１と自身（中継ノード１２）の間のPath MTU値に書き換えて中継する。受信ノード１３は、応答パケットの送信時、中継Path MTU４００６を中継ノード１２と自身（受信ノード１３）の間のPath MTU値に書き換えて送信する。

対応アルゴリズムリスト４００７は、2byte×N個の可変長の領域であり、ネゴするアルゴリズムのリストを表す。送信ノード１１は、自身（送信ノード１１）の対応するアルゴリズムのリストを付与する。リストは2byte(16bit)×レイヤ数分のビット列で表現される。受信ノード１３は、通知されたアルゴリズムリストと、自身（受信ノード１３）の対応するアルゴリズムの論理積を付与して、応答する。中継ノード１２は、応答パケットの中継時、中継するアルゴリズムリストと、自身（中継ノード１２）の対応するアルゴリズムの論理積を付与して、転送する。

図１３に圧縮ネゴの初回のシーケンス図を示す。後述するが、送信ノード１１と同様に、受信ノード１３は圧縮ネゴ部４１０８及び圧縮ネゴ結果管理テーブル４１１０、中継ノード１２は圧縮ネゴ部５１０８及び圧縮ネゴ結果管理テーブル５１１３を有する。

送信ノード１１の圧縮ネゴ処理部３１０８は、セッション確立（Ｓ１３００）後、受信ノード１３にICMPパケット(Path MTU要求)４００１を送信する（Ｓ１３０１）。送信ノード１１は、ICMPパケット４００１の対応アルゴリズムリスト４００７に、圧縮ネゴ結果管理テーブル３１１３に格納されている、送信ノード１１自身の対応圧縮アルゴリズムリスト２５０５(図１３ではA)を格納する。Rビット４００４は、Ｒ=0とし、中継Path MTU４００６は、初回送信パケットサイズとして、自身（送信ノード１１）のMTU(10KB)とする。ICMP(Datagram Too Big)を受信した場合（Ｓ１３０２）、標準通り、Next Hop MTU(9KB)で指定されたサイズ(9KB)でICMPパケット(Path MTU要求)を送信する（Ｓ１３０３）。

中継ノード１２は、ICMPパケット(Path MTU要求)４００１を中継する。中継ノード１２の圧縮ネゴ部５１０８（後述）は、ICMPパケット(Path MTU要求)４００１の中継時、圧縮ネゴ結果管理テーブル５１１３（後述）を参照し、同一の宛先（受信ノード１３）のIPアドレス・送信元（送信ノード１１）のIPアドレスの組合せの登録の有無を確認する(Ｓ１３０４)。登録が無ければ、中継するICMPパケット(Path MTU要求)４００１の宛先IPアドレス・送信元IPアドレスを、圧縮ネゴ結果管理テーブル５１１３に格納する(Ｓ１３０５)。また受信したパケット４００１のサイズ(9KB)を、送信ノード間PathMTUとして、圧縮ネゴ結果管理テーブル５１１３に格納する。このPath MTU要求パケットのサイズは、送信ノードと中継ノードとの間のPathMTUとみなせる。

中継ノード１２によるICMPパケット(Path MTU要求)４００１の中継に伴ってICMP(Datagram Too Big)を受信した場合（Ｓ１３０６）、NHMTUで示されるサイズ(4KB)でICMPパケット(Path MTU要求)を送信する（Ｓ１３０７）。さらに、受信ノード１３からICMP(Datagram Too Big)を受信した場合（Ｓ１３０８）、NHMTUで示されるサイズ(2KB)でICMPパケット(Path MTU要求)を送信する（Ｓ１３０９）。

受信ノード１３の圧縮ネゴ部４１０８（後述）は、ICMPパケット(Path MTU要求)４００１を受信時、通知されたアルゴリズムリスト(A)と、圧縮ネゴ管理テーブル４１１０（後述）にある、自身（受信ノード１３）の対応するアルゴリズムリスト(B)の論理積(A&B)を対応アルゴリズムリスト４００７に格納し、Rビットを立てて(R=1)、応答する（Ｓ１３１０）。受信ノード１３が圧縮アルゴリズムに非対応であれば、Rビットを立てずに(R=0)、単なるPathMTU応答となる。また受信したICMPパケット(Path MTU要求)４００１のパケットサイズ(2KB)を、応答パケットの中継Path MTU領域に格納する。

中継ノード１２は、PathMTU応答を中継時、Rビット内容を確認する（Ｓ１３１１）。Rbit=0であれば、中継ノード１２は、何もせずにそのままPathMTU応答パケットを中継する。Rbit＝１であれば、中継ノード１２は、PathMTU応答パケット中の対応アルゴリズム(A&B)と、圧縮ネゴ結果管理テーブル５１１３にある、自身（中継ノード１２）の対応アルゴリズム(C)の論理積を計算し、PathMTU応答パケットの対応アルゴリズムリストに計算結果(A&B&C)格納して、中継する（Ｓ１３１２）。またPathMTU応答パケット内の中継Path MTU(2KB)を、受信ノード間PathMTUとして、圧縮ネゴ結果管理テーブル５１１３に登録する（Ｓ１３１３）。受信ノード１３の中継Path MTUは、受信ノード１３と中継ノード１２との間のPathMTUとみなせる。

送信ノード１１は、PathMTU応答を受信時、Rビットが1であれば（Ｓ１３１４）、受信PMTU結果(2KB)と、中継ノードPMTU(9KB)と、PathMTU応答に格納されたアルゴリズムのリスト(A&B&C)を、圧縮ネゴ結果管理テーブル３１１３の受信PMTU２５０３と、中継PMTU２５０４と対応圧縮アルゴリズム２５０５に格納し（Ｓ１３１５）、ネゴを終了する。Rビット＝０であれば、圧縮ネゴ結果管理テーブル３１１３には、受信ノード１３が圧縮非対応であることを格納し、ネゴを終了する。

ネゴの結果、送信ノード１１は、対応可能アルゴリズムのリスト(A&B&C)を得るので、受信ノード１３及び中継ノード１２が対応可能な圧縮アルゴリズムの選択が可能となる。また、受信ノード１３までのPathMTU値(2KB)を得るので、このサイズでミドルフレーム２３０１の構成が可能になる。さらに、中継ノード１２までのPathMTU値(9KB)を得るので、このサイズでジャンボフレーム２２０１の構成が可能になる。

中継ノード１２は、受信ノード１３までのPathMTU値(2KB)を得るので、ジャンボフレーム２２０１の受信時に、このサイズ（PathMTU値(2KB)）となるよう、ミドルフレーム２３０１に分割して送信することが可能となる。

図１４に、圧縮ネゴの再ネゴのシーケンス図を示す。受信ノード１３は、対応しない圧縮アルゴリズムのフレームを受信した場合、またはフラグメントされた圧縮フレームを受信した場合(Ｓ１４０１)、送信ノード１１宛に図１２に示したフィールドを持つICMPパケット(Path MTU要求)を送信する(Ｓ１４０２)。このとき、Rビットは0、アルゴリズムは自身（受信ノード１３）の対応するアルゴリズムのリストを格納する。送信ノード１１は、初回ネゴ終了後にICMPパケット(Path MTU要求)を受信した場合、対応するセッションの圧縮ネゴ結果管理テーブル内容を破棄した上で、バッファ内容を全て非圧縮で送信した後、ネゴを再実行する(Ｓ１４０３)。

なお、このような再ネゴは、たとえば、中継ノード１２がRebootして、圧縮ネゴ結果管理テーブル５１１３を初期化した場合などに必要となる。

図１５に、受信ノードの構成図を示す。受信ノード４１００(図１の１３)は、IP網と接続するインターフェイス（IP-IF）４１０１と、各種処理を実行するCPU４１０２と、このCPU４１０２のワークエリアとなるＲＡＭ４１０３を持つ。受信ノード４１００は、IP-IF４１０１経由でIP網と接続している。

CPU４１０２は、ユーザデータパケットの送受信処理を実行するU-Plane処理部４１０４、送信ノード１１との呼制御(回線制御)を実行するC-Plane処理部４１０５、パケットの解凍処理を実行する解凍処理部４１０６、解凍したパケットの組立を実行するフレーム処理部４１０７、並びに、送信ノード１１及び中継ノード１２と圧縮能力のネゴ処理を実行する圧縮ネゴ処理部４１０８を持つ。

RAM４１０３には、解凍処理部４１０６が解凍したデータを格納するバッファ４１０９を持つ。ＲＡＭ４１０３には、圧縮ネゴ処理部４１０８により使用される、圧縮ネゴ管理テーブル４１１０が設けられている。図１６に圧縮ネゴ管理テーブル４１１０を示す。圧縮ネゴ管理テーブル４１１０には、受信ノード１３自身を示すIPアドレス１６０１、及び、受信ノード１３の持つ対応圧縮アルゴリズムのリスト１６０２が格納されている。

ＲＡＭ４１０３は、C-Plane処理部４１０５により確立されたセッションに関する情報を格納するセッション情報テーブル４１１１を持つ。図１７に、セッション情報テーブル４１１１を示す。セッション情報テーブル４１１１には、端末１５のIPアドレス１７０１、当該セッションにおける送信ノード１１のIPアドレス１７０２、及び、当該セッションを一意に特定するセッションID１７０３が格納されている。

図１８に、受信ノード４１００（図１の１３）による圧縮フレーム受信処理のフローチャートを示す。U-Plane処理部４１０４は、パケット受信の有無を判定する（Ｓ１８０１）。パケット受信が無い場合、Ｓ１８０１に戻る。

パケット受信がある場合、受信したパケットのIPヘッダ２２０３に含まれる特定のプロトコルを示す情報を参照して、圧縮されたジャンボフレーム２２０１であるか判定する（Ｓ１８０２）。圧縮されたジャンボフレームでない場合、Ｓ１８０１へ移る。

受信したパケットが圧縮されたジャンボフレーム２２０１である場合、コンテキスト・辞書領域２２０４の各レイヤのアルゴリズムに、受信ノード４１００が対応しているか判定する（Ｓ１８０３）。全てのアルゴリズムには対応していない場合、受信ノード４１００は圧縮の再ネゴを実行するために、送信ノード１１に図１２に示したICMPパケット４００１を送信し（Ｓ１８０４）、受信パケットを破棄して、Ｓ１８０１に戻る。Ｓ１８０４は、図１４に示した再ネゴのＳ１４０２に相当する。

受信ノード４１００が、全てのアルゴリズムに対応している場合、各ミドルフレーム２３０１を切り出して（Ｓ１８０５）、各ミドルフレーム２３０１の解凍処理を実行する。 各ミドルフレーム２３０１の切り出し（Ｓ１８０５）は、次のようにする。ジャンボフレーム２２０１のコンテキスト又は辞書領域全体長２２０７を元に、コンテキスト・辞書領域２２０４を切り出す。切り出したコンテキスト・辞書領域２２０４から、各レイヤのアルゴリズム（たとえば、２２０９）、及びコンテキスト辞書情報（たとえば、２２１１）を切り出す。各レイヤの切れ目は、各レイヤのコンテキスト・辞書長（たとえば、２２１０）から判別する。ジャンボフレーム２２０１のミドルフレーム領域２２０５から、各ミドルフレーム２３０１を切り出す。各ミドルフレーム２３０１の第一レイヤ長２３０２〜最終レイヤ長２３０４の合計が、各ミドルフレーム長であるので、ミドルフレーム領域２２０５の先頭から各ミドルフレーム長に対応する切れ目に応じて、各ミドルフレーム２３０１を切り出す。各ミドルフレーム２３０１から、第一レイヤ長２３０２〜最終レイヤ長２３０４を参照して、圧縮後第一レイヤ２３０５〜最終レイヤ２３０７を切り出す。

切り出したミドルフレーム２３０１の圧縮後第一レイヤ２３０５〜最終レイヤ２３０７を解凍する（Ｓ１８０６）。この解凍には、コンテキスト・辞書領域２２０４から切り出した、各レイヤのアルゴリズム（たとえば、２２０９）、及びコンテキスト・辞書情報（たとえば、２２１１）を使用する。

解凍したデータを第Ｎパケット毎に組み立てて、パケットデータを組み立てる（Ｓ１８０７）。Ｓ１８０６及びＳ１８０７をミドルフレーム領域２２０５の最終ミドルフレームまで繰り返し（Ｓ１８０８）、終了したらＳ１８０１へ戻る。

図１９に、中継ノードの構成図を示す。中継ノード５１００(図１の１２)は、IP網と接続するインターフェイス（IP-IF）５１０１と、各種処理を実行するCPU５１０２と、このCPU５１０２のワークエリアとなるＲＡＭ５１０３を持つ。中継ノード５１００は、IP-IF５１０１経由でIP網と接続している。

CPU５１０２は、ユーザデータパケットの転送処理を実行するU-Plane処理部５１０４、圧縮フレーム解凍処理を実行する解凍処理部５１０６、フレームの分割を実行するフレーム処理部５１０７、並びに、受信ノード及び送信ノードと圧縮能力ネゴを実行する圧縮ネゴ処理部５１０８を持つ。

ＲＡＭ５１０３には、圧縮ネゴ処理部５１０８により作成される圧縮ネゴ管理テーブル５１１３が設けられている。図２０に、圧縮ネゴ管理テーブル５１１３を示す。圧縮ネゴ結果管理テーブル５１１３には、受信ノード１３のIPアドレス２００１、受信ノード１３から当該中継ノード１２までの経路の受信PathMTU結果２００２、送信ノード１１のIPアドレス２００３、及び、送信ノード１１から当該中継ノード１２までの送信PathMTU結果２００４が格納されている。

図２１に、中継ノード５１００(図１の１２)による圧縮フレーム中継処理のフローチャートを示す。中継ノード５１００のU-Plane処理部５１０４は、は、パケット受信の有無を確認する（Ｓ２１０１）。パケット受信が無い場合、Ｓ２１０１に戻る。

パケット受信が有る場合、U-Plane処理部５１０４は、受信したパケットが圧縮されたジャンボフレーム２２０１か否かを、パケット中のIPヘッダ２２０３に含まれるコンテキスト・辞書領域有無に関する情報を暗唱して判定する（Ｓ２１０２）。圧縮されたジャンボフレーム２２０１でなければ、そのままパケット転送し（Ｓ２１０７）、Ｓ２１０１に戻る。

圧縮されたジャンボフレーム２２０１であれば、フレーム処理部５１０７は、圧縮されたジャンボフレーム２２０１のIPヘッダ２２０３に含まれる送受信IPアドレスと、圧縮ネゴ管理テーブル５１１３に登録済の送受信アドレス２００１、２００３を比較し、圧縮ネゴ管理テーブル５１１３の一致する行を特定し（Ｓ２１０３）、転送先受信ノード２００１迄のPathMTU２００２を取得し、IPヘッダ２２０３に含まれる、受信した圧縮されたジャンボフレーム２２０１のサイズと、取得したPathMTU２００２を比較する（Ｓ２１０４）。

フレームサイズがPathMTU２００２を超えていれば、フレーム処理部５１０７は、ジャンボフレームサイズがPathMTU以下となるよう、フレームを分割する（Ｓ２１０５）。次のようにフレームを分割する。ジャンボフレーム２２０１のコンテキスト又は辞書領域全体長２２０７を元に、コンテキスト・辞書領域２２０４を切り出す。切り出したコンテキスト・辞書領域２２０４から、各レイヤのアルゴリズム（たとえば、２２０９）、及びコンテキスト・辞書情報（たとえば、２２１１）を切り出す。各レイヤの切れ目は、各レイヤのコンテキスト・辞書長（たとえば、２２１０）から判別する。このとき、圧縮されたジャンボフレーム２２０１のレイヤ数(何レイヤ存在するか)を取得する。ジャンボフレーム２２０１のミドルフレーム領域２２０５から、各ミドルフレーム２３０１を切り出す。各ミドルフレーム２３０１の、第一レイヤ長２３０２〜最終レイヤ長２３０４の合計が、各ミドルフレーム長であるので、ミドルフレーム領域２２０５の先頭から各ミドルフレーム長に対応する切れ目に応じて、各ミドルフレーム２３０１を切り出す。

以上の処理により、コンテキスト・辞書領域２２０４と、各ミドルフレーム領域２２０５を切り出し、各ミドルフレーム２４０５に、コンテキスト・辞書領域２４０４を付与し、分割後ジャンボフレーム２４０１を作成する。このとき、コンテキスト・辞書領域２４０４とミドルフレーム２４０５とのサイズは、受信ノード１３と中継ノード１２との間のPathMTU以下とする。作成された各分割後ジャンボフレーム２４０１は、解凍処理部５１０６に渡される。

フレームサイズがPathMTU２００２以下であれば（Ｓ２１０４）、圧縮されたジャンボフレーム２２０１は解凍処理部５１０６渡される。

解凍処理部５１０６は、次のように圧縮されたジャンボフレーム２２０１（または分割後ジャンボフレーム２４０１、以下、ジャンボフレーム２２０１を例に説明する。）の解凍処理を実行する（Ｓ２１０６）。ジャンボフレーム２２０１のコンテキスト又は辞書領域全体長２２０７を元に、コンテキスト・辞書領域２２０４を切り出す。切り出したコンテキスト・辞書領域２２０４の先頭から、各レイヤのアルゴリズム（たとえば、２２０９）、及びコンテキスト・辞書情報を切り出す（たとえば、２２１１）。各レイヤの切れ目は、各レイヤのコンテキスト・辞書長から判別する（たとえば、２２１０）。このとき、圧縮されたジャンボフレーム２２０１のレイヤ数(何レイヤ存在するか)を取得する。ジャンボフレーム２２０１のOuter領域より、Outerヘッダ部分のレイヤの数を得る。ジャンボフレーム２２０１のミドルフレーム領域２２０５から、各ミドルフレーム２３０１を切り出す。各ミドルフレーム２３０１の第一レイヤ長２３０２〜最終レイヤ長２３０４の合計が、各ミドルフレーム長であるので、ミドルフレーム領域２２０５の先頭から各ミドルフレーム長に対応する切れ目に応じて、各ミドルフレーム２３０１を切り出す。

ミドルフレーム２３０１の第一レイヤ長２３０２〜最終レイヤ長２３０４を参照して、切り出したミドルフレーム２３０１の圧縮後第一レイヤ２３０５〜最終レイヤ２３０７を切り出す。切り出した各ミドルフレーム２３０１の圧縮後第一レイヤ２３０５〜最終レイヤ２３０７のうち、前述のOuterヘッダ部分のレイヤの数だけ解凍する。解凍には前述の各レイヤのアルゴリズム（たとえば、２２０９）、及びコンテキスト・辞書情報（たとえば、２２１１）を使用する。

解凍されたヘッダ情報と、圧縮されたジャンボフレーム２２０１または分割後ジャンボフレーム２４０１は、U-Plane処理部５１０４に渡される。U-Plane処理部５１０４は、解凍されたヘッダ情報を元に、圧縮されたジャンボフレーム２２０１または分割後ジャンボフレーム２４０１を転送し（Ｓ２１０７）、S２１０１に戻る。

本実施形態によれば、複数のショートパケットを纏めて一つのジャンボフレームに格納し、そのジャンボフレームには圧縮のアルゴリズムやコンテキスト又は辞書などのコンテキスト情報を含み、そのジャンボフレーム内に閉じる圧縮を行うので、ジャンボフレーム内でショートパケット間の順序逆転は発生しない。またネットワーク上での欠落は、ジャンボフレームの欠落となるので、ジャンボフレーム内の特定のショートパケットだけ欠落することはない。これにより、順序保証されていないリンクを使用した通信が可能になる。また、コンテキスト同期外れが発生しないので、再同期の処理は不要となる。さらに、同期外れ中による解凍失敗も発生しなくなる。さらに、コンテキストはフレーム内に存在するので、送受信ノードがコンテキストを記憶する必要がない。

また、圧縮がフレーム内に閉じるので、辞書リセット・再学習処理はジャンボフレーム毎に実行することになり、パケット毎に実行する場合と比較して実行頻度が下がる。またコンテキスト情報はフレーム内に存在する為、中継ノードもヘッダを解凍可能となる。

また、本実施形態によれば、ヘッダ単位で圧縮するので、解凍もヘッダ単位で可能となり、ヘッダ単位で異なる圧縮アルゴリズムの選択も可能となる。これにより、ヘッダを解凍する際に、不要な部分まで解凍する必要が無くなる。さらに、副次的な効果として、ヘッダとペイロードで、それぞれ異なる圧縮アルゴリズムを使用可能となる。

さらに、本実施形態によれば、複数ノード間での、ツリー状の圧縮アソシエーション網を構築する。具体的には、通信経路上で、最下流のノードが自身の対応する圧縮アルゴリズムを上流のノードに通知する。通知された上流ノードは、通知されたアルゴリズムと自身の対応するアルゴリズムの論理積を計算し、更に上流のノードに通知する。このように圧縮能力通知を、最上流のノードまで繰り返す。これにより、送信ノードは、接続先の中継ノードおよび受信ノードの全てが対応可能な圧縮アルゴリズムを把握できるので、送信ノードは、自身が対応している圧縮アルゴリズムの中から、中継ノードおよび受信ノードが対応可能な圧縮アルゴリズムの選択が可能となる。選択可能なアルゴリズムの範囲内であれば、任意のタイミングで、パケット毎にアルゴリズムを変更できる。

他の観点で、本実施形態の効果を纏めると次のようになる。まず、バックホール区間における圧縮通信の計算資源コストを下げることができる。一般的にバックホール区間のノードでは、CPU・メモリといった計算資源は貴重であり、多大な計算資源を投入してまで、圧縮処理を実施するメリットは薄いと考えられている。本実施形態では、パケット順序逆転/パケット欠落への考慮が不要であるので、それに備えた再同期等に要する計算資源が不要である。また、同期外れによる解凍失敗と、それに伴う再送が無いので、再送のための計算資源/帯域資源を軽減できる。コンテキスト情報をジャンボフレーム内に含み、ノードがコンテキスト情報を記憶する必要がないので、使用する記憶容量を低減できる。辞書リセット/再学習処理はジャンボフレーム毎に実行するので、パケット毎実施と比較して実施頻度が下がり、リセット/再学習に必要な計算資源を軽減できる。

本実施形態の他の効果として、通信バックボーンを問わず、圧縮通信を可能とする。バックホール区間においては、L2レイヤとして様々な種類のリンクが使用されており、例えば広域Etherのような順序保証されていないリンクも広く使用されているので、圧縮通信を実行する上での阻害要因の一つである。これに対して、本実施形態では、順序保証についての考慮が不要となる為、L2レイヤの種類を問わず、圧縮通信が可能である。

本実施形態のさらに他の効果として、NATPやOpenFlow等、中継ノードがヘッダ情報を元にインテリジェンスな処理を行う技術との親和性を高める。本実施形態では、中継ノードも圧縮ヘッダを解凍可能であり、かつそのための計算資源消費量も従来に比べて低減されるので、インテリジェンスな処理の実行が容易である。

１１：送信ノード、１２：中継ノード、１３：受信ノード、１４：バックホール、１５：無線端末、１６：通信対象、２１０１：ショートパケット、２２０１：ジャンボフレーム、２３０１：ミドルフレーム、２４０１：分割後のジャンボフレーム、３１０４：U-Plane処理部、３１０５：C-Plane処理部、３１０６：圧縮処理部、３１０７：フレーム処理部、３１０８：圧縮ネゴ処理部、３１０９：バッファ管理部、３１１４：アルゴリズム選択処理部、３１１３：圧縮ネゴ管理テーブル、３１１０：セッション情報テーブル、３１１２：バッファ管理テーブル、３１１５：アルゴリズム優先順位テーブル、４００１：圧縮ネゴパケット、４１０４：U-Plane処理部、４１０５：C-Plane処理部、４１０６：解凍処理部、：４１０７：フレーム処理部、４１０８：圧縮ネゴ処理部、４１０９：バッファ、４１１０：圧縮ネゴ管理テーブル、４１１１：セッション情報テーブル、５１０４：U-Plane処理部、５１０６：解凍処理部、５１０７：フレーム処理部、５１０８：圧縮ネゴ処理部、５１１３：圧縮ネゴ管理テーブル。

Claims (9)

1. 圧縮用コンテキストを用いて複数のショートパケットを圧縮する圧縮処理部、圧縮した複数の前記ショートパケットと前記圧縮用コンテキストとをジャンボフレームに格納するフレーム処理部、及び、前記ジャンボフレームを送信するU-Plane処理部を有する送信ノード、並びに、
   送信された前記ジャンボフレームを受信する受信ノードを有することを特徴とする無線通信システム。
2. さらに、前記送信ノードから送信された前記ジャンボフレームを受信し、前記受信ノードへ中継する中継ノードを有することを特徴とする請求項１記載の無線通信システム。
3. 前記圧縮処理部は、前記ショートパケットをヘッダ及びペイロードに分けて圧縮することを特徴とする請求項１または請求項２記載の無線通信システム。
4. 前記圧縮処理部は、前記ヘッダ及び前記ペイロードの圧縮に、圧縮アルゴリズムを選択的に用いることを特徴とする請求項３記載の無線通信システム。
5. 前記圧縮処理部が選択した前記圧縮アルゴリズムを示す情報を、前記フレーム処理部は、前記ジャンボフレームに前記圧縮用コンテキストとして格納することを特徴とする請求項４記載の無線通信システム。
6. 前記圧縮処理部は、前記送信ノード、前記中継ノードおよび前記受信ノードのいずれもが対応できる圧縮アルゴリズムの中から前記圧縮アルゴリズムを選択的に用いることを特徴とする請求項４または請求項５記載の無線通信システム。
7. 前記中継ノードは、圧縮された前記ヘッダを、選択的に用いた前記圧縮アルゴリズムにより解凍することを特徴とする請求項４から請求項６のいずれか１項に記載の無線通信システム。
8. 前記ジャンボフレームのサイズは、前記送信ノードと前記中継ノードとの間の第１のPath MTU以下であることを特徴とする請求項１から請求項７のいずれか１項に記載の無線通信システム。
9. 前記ジャンボフレームのサイズが、前記中継ノードと前記受信ノードとの間の第２のPath MTUを超えているとき、前記中継ノードは、前記ジャンボフレームを前記第２のPath MTU以下のサイズのフレームに分割し、分割した前記フレームを前記受信ノードに中継することを特徴とする請求項８記載の無線通信システム。

Images