JP2009526426A - パケット伝送 - Google Patents

Abstract

ＩＰパケットをＩＰネットワークのノード（１１、１２、１３、２１、２２、２３）間で伝送する方法であって、第１のネットワークノード（１１）においてパケットを受信し、それぞれのストリームのパケットが共通のＩＰヘッダを共有するように、受信されたパケットを複数のストリームへと分ける。複数のパケットは併合されて、併合されたパケットを形成し、併合されたパケットは第２のネットワークノードへと送信される。

Description

本発明は、パケット伝送方法に関し、特にある１つのネットワークノードと他の１つのネットワークノードとの間でのパケット伝送に関する。

図１は、第２のネットワークであるネットワーク２に存在するデバイス２１、２２、２３と通信している、第１のネットワークであるネットワーク１に存在するデバイス１１、１２、１３を概略的に示す図である。例えば、ネットワーク１に存在するデバイス１１が、ネットワーク２に存在するデバイス２１および２３にパケットを送っていてもよいし、ネットワーク１に存在するデバイス１２が、ネットワーク２に存在するデバイス２２にパケットを送っていてもよい。ネットワーク１に存在するデバイス１１、１２、１３から送信されたパケットは、まずネットワーク１に存在するホスト１へとルーティングされ、そして、例えばＩＰバックボーン３のような通信リンクを通して、ネットワーク２に存在するホスト２へと送信される。ネットワーク２に存在するホスト２は、受信したパケットを、パケット内で指定された宛先に従って、デバイス２１、デバイス２２、またはデバイス２３へとルーティングする。ネットワーク１からネットワーク２へと通っていく、あるいは、その逆向きに通っていく、全てのバケットは、リンク３上を通っていく。

１つのパケットは、一般的には、１つのヘッダと１つのペイロードとから構成されている。ヘッダは、パケットの送信先およびパケットの送信元のような、そのパケットのルーティングの詳細を含んでいる。このため、例えば、デバイス１１によって生成されてデバイス２１へと向かうパケットは、とりわけそのパケットの送信先がデバイス２１であることを示す、ヘッダを持っているであろう。パケットがホスト１に受信されると、ホスト１はそのパケットのヘッダから送信先を読み取り、送信先がネットワーク２に存在すると確認し、リンク３を通してネットワーク２のホスト２へとそのパケットを転送するだろう。パケットがネットワーク２のホスト２に受信されると、ホスト２はそのパケットのヘッダから送信先を読み取り、送信先がデバイス２１であることを確認するだろう。

デバイスの（または、より一般的には、「ネットワークノード」の）アドレスは、通常はＩＰ（インターネット・プロトコル）アドレスである。

特定のデバイスは、例えば電子メールシステムやウェブブラウザなどのような、いくつかの異なったアプリケーションのために働いてもよい。パケットのヘッダは、それゆえに、一般的には、送信先デバイスを示すだけではなく、パケットの内容が関連する特定のアプリケーションも示す。この特定のアプリケーションは、一般的には「ＵＤＰポート番号」により示される。リンク３を通して送信されるパケットのヘッダは、それゆえに、典型的にはＩＰアドレスフィールドとＵＤＰポートフィールドを含むだろう。

パケットのヘッダは、そのパケットの内容が関連するアプリケーションに依存して、例えば「リアル・タイム・プロトコル」（ＲＴＰ）フィールドのような、更なるフィールドを含んでいてもよい。ＲＴＰフィールドは、ＶｏＩＰデータのようなリアルタイムデータのフレーミングと取り扱いとに関係する。よって、リンク３を通して送信されるＶｏＩＰパケットのヘッダは、それゆえに、典型的には、ＩＰアドレスフィールドとＵＤＰアドレスフィールドとに加えて、ＲＴＰフィールドを含むだろう。

現時点において、電話の通話をインターネットを通して送信すること、すなわち「ＶｏＩＰ」（ボイス・オーバ・インターネット・プロトコル）、に対して多くの努力が費やされている。ＶｏＩＰにおける主要な問題の１つが、パケットヘッダのＩＰ／ＵＤＰ／ＲＴＰフレーミングにより引き起こされる、大きな量のオーバヘッドである。ＩＰｖ６（インターネット・プロトコル・バージョン６・アドレス領域）では、ＩＰフィールド、ＵＤＰフィールド、およびＲＴＰフィールドを持つヘッダは、計６０バイトの長さを持つが、パケットの実際のペイロードはせいぜい１５−２０バイトだろう。このことは、７５％以上の帯域幅が、パケットのヘッダによって消費されるであろうことを意味する。

いくつかの、ヘッダを圧縮する仕組みが、この問題を克服するために提案されてきたが、それらの仕組みは、図１のように共通のリンクを通して多数の異なったパケットのフローが送信される事例のためというよりは、ポイント・ツー・ポイント接続のために設計されてきた。これらのヘッダを圧縮する仕組みは、無線インタフェースにおける場合を除いて、実際問題としては役に立たない。さらに、もしヘッダ圧縮が固定ネットワークに導入されたとすれば、公衆商業ＩＰネットワークでは従うことがおそらく不可能であるような、圧縮に対する厳密な要求が課されるだろう。よって、３ＧＰＰ規格に従ったコアネットワークで、ＶｏＩＰの要求帯域幅を減らす、他の手段が求められている。

本発明の第１の態様は、ＩＰネットワークのノード間でＩＰパケットを伝送する方法を提供する。この方法は、パケットを第１のネットワークノードで受信する工程と、受信したパケットを、それぞれのストリームのパケットが同じＩＰヘッダを共有するように、複数のストリームに分ける工程と、複数のパケットを併合して、１つの併合されたパケットを形成する工程と、併合されたパケットを第２のネットワークノードへと送信する工程と、を備えることを特徴とする。

本発明の方法によれば、２つ以上のパケットが併合される（あるいは、「多重化される」）。併合されたパケットを形成するために使われた、その構成要素であるパケット（コンポーネントパケット）のペイロードは、共通ヘッダの下、併合されたパケットの中で送信される。併合されたパケットのヘッダは、１つのパケットのヘッダが占める割合と比べ、併合されたパケットの長さのうち、より小さい割合しか占有しない。すなわち、もし（例として）２つのパケットが併合されたなら、併合されたパケットのヘッダ長は、２つのコンポーネントパケットのヘッダ長の和よりも短くなるだろう。

リアルタイム・トラフィックの場合は、併合されたパケットが含むパケットは、どのストリームからのものであれ、１つを超えないことが好ましい。しかしながら、非リアルタイム・トラフィックの場合は、原理的には、ストリームが２つ以上のパケットを併合されたパケットに与えることが可能である。

併合しているパケットを通信ネットワークを通して送信することは、ネットワークに対する修正を必要としない。

併合されたパケットが第２のネットワークノードで受信されると、そのコンポーネントパケットに分離される。

本発明の方法は、例えば、メディアゲートウェイ（ＭＧＷ）相互間のＮｂインタフェースを介した、あるいは、ＲＮＣとＭＧＷの間のＩｕインタフェースを介した、３ＧＰＰ ＵＭＴＳネットワークでのＩＰで伝送される会話トラフィックに、応用されてもよい。しかしながら、パケットの併合（または多重化）は、本質的に、同じＩＰアドレスに向かう全てのパケットに対して行われうる。また、本発明は全ての種類のＵＤＰトラフィックに対して使われうる。本発明の多重化方法は、特に、通常はＩＰ／ＵＤＰパケットによって運ばれ続けるかもしれないＲＴＰパケットについて使われてもよい（ただし、ＲＴＣＰ（リアルタイム制御プロトコル）には応用可能ではないかもしれない））。多重化方法はＩＰの下のプロトコルから独立しており、例えば、ＭＰＬＳ（マルチ・プロトコル・ラベル・スイッチング）対応のネットワークにおいても、また、他のＩＰベースのいかなるネットワークにおいても、使われうる。

本発明の好適な実施形態が、これより、添付の図面を参照して、説明のための例を用いて説明されるだろう。

例として、図１に示されるネットワークを参照して、本発明を説明する。一例として、ネットワーク１に存在するデバイスによって制御される様々なアプリケーションがパケットをネットワーク２のデバイスに送るということを想定するが、ネットワーク２に存在するデバイスがネットワーク１にパケットを送る場合にも、本発明は等しく適用されてもよい。

ある実施形態では、ネットワーク１に存在する１つのデバイス、例えばデバイス１１が、ネットワーク２上に存在するデバイスに向かう、２以上のパケットのストリームの送信元である。複数のストリームが同じＤｉｆｆＳｅｒｖクラスを持つことが仮定される。このことは、実際には、１つのストリームのトラフィックが、他のストリームのトラフィックと非常に似通っていることを要求する。多くの場合、２つのストリームは同じアプリケーションに関係しそうである。

デバイス同士の間でアドレスが既に交渉されていることがさらに仮定され、その結果、例えば、デバイス１１からデバイス２１へと行くパケットは、デバイス１１のＩＰアドレスを送信元アドレスとして、デバイス２１のＩＰアドレスを送信先アドレスとして持っているものとする。この例では、デバイス１１からデバイス２１へと行くストリーム中のパケットは、デバイス１１からデバイス２１へと行く他の１以上のストリーム中のパケットとのみ併合されうる。また、これらのストリームの多重化は、デバイス１１で実行される。（同様に、デバイス１２からデバイス２１へと行くストリームの併合はデバイス１２で行われ、デバイス２１からデバイス１１へと行くストリームの併合は、デバイス２１で行われるだろう。他のデバイスでも同様である。）ホスト１とホスト２は、この例では、ルータとしてのみ用いられる。

この例では、最初に、パケットがデバイス１１によって受信される（図２のステップ１）。この例では、とりわけ、デバイス２１へと向かう２以上のパケットのストリームを含み、また、同一のＤｉｆｆＳｅｒｖクラスであることが仮定される（ネットワーク２に存在する別の送信先デバイスを持つことと、他のＤｉｆｆＳｅｒｖクラスに関係することとの、少なくとも一方に該当する、更なるパケットのストリームを含んでいてもよい）。デバイス２１へと向かうパケットは、とりわけ、デバイス２１のＩＰアドレスを含むヘッダを持ち、また、デバイス２２（２３）へと向かうパケットは、とりわけ、デバイス２２（２３）のＩＰアドレスを含むヘッダを持つだろう。

次に、デバイス１１で受信されたパケットは、それぞれのストリームが１つのＩＰアドレスに対応する、２以上のストリームに分類される（図２のステップ２）。この例では、この分類ステップは、デバイス１１からデバイス２１へと向かい、同じＤｉｆｆＳｅｒｖクラスに関係する、２つ（またはそれ以上）のパケットのストリームを生じるだろう。また、ネットワーク２に存在する別の送信先デバイスを持つことと、他のＤｉｆｆＳｅｒｖクラスに関係することとの、少なくとも一方に該当する、他のパケットのストリームを生じる可能性があってもよい。

ステップ２で生成されたそれぞれのストリームは、１つのタイプのパケットのみを含むことが好ましい（より正式には、それぞれのストリームは１つのＤｉｆｆＳｅｒｖクラスのパケットのみを含むことが好ましい）。よって、ネットワーク１に存在するデバイス１１によって制御される２つ（またはそれ以上）の異なったアプリケーション（例えばＶｏＩＰと電子メール）が、パケットをネットワーク２に存在するデバイス２１に送るような例では、例えば、ＶｏＩＰパケットと電子メールパケットとがもう片方のパケットと同じストリームに含まれないように、デバイス１１に到着するパケットが複数のストリームに分類されることが好ましい。

次に、複数のパケットが選択され（図２のステップ３）、併合されて、併合されたパケットを形成する（図２のステップ４）。併合するように選択されたパケットは、相互に同じＩＰアドレスを持つ。例えば、選択されたパケットは全てがデバイス２１へと向かい、よってデバイス２１のＩＰアドレスを送信先アドレスとして持つ。併合されたパケットは１つのＩＰフィールドをヘッダに含む。なぜなら、併合されたパケットの全てのコンポーネントパケットは、同じＩＰアドレスに向かうからである。併合されたパケットはまた、複数のペイロードフィールドをも含み、それぞれのコンポーネントパケットに対して１つのペイロードフィールドとなる。

リアルタイム・トラフィックの場合には、併合されたパケットは、どのストリームからのものであれ、１つのストリームにつき１つを超えるパケットを含まないことが好ましい。この場合は、選択ステップは、それぞれのストリームから１つのパケットを選択することから成るだろう（または、より一般的には、それぞれの空でないストリームから１つのパケットを選択することから成るだろう）。もしストリームが２以上のパケットを含んでいるなら、選択されたパケットは、ストリーム中で最も長く待っていたパケットであることが好ましい。

しかしながら、非リアル・タイム・トラフィックの場合には、原理的には併合されたパケットが１つのストリームからの２以上のパケットを含むことが可能である。

本発明の好適な実施形態によれば、併合されたパケットは、同じタイプのパケットのみを含む（すなわち、ただ１つのＤｉｆｆＳｅｒｖクラスのパケットのみを含む）。この実施形態では、併合されたパケットは、例えばデバイス２１へと向かう複数のＶｏＩＰパケットに関するあるストリームからのパケットと、デバイス２１へと向かう複数のＶｏＩＰパケットに関する他のストリームからのパケットとを、併合することによって形成されてもよい。同様に、併合されたパケットは、例えばデバイス２１へと向かう複数の電子メールパケットに関するあるストリームからのパケットと、デバイス２１へと向かう複数の電子メールパケットに関する他のストリームからのパケットとを併合することによって形成されてもよいし、例えばデバイス２２へと向かう複数のＶｏＩＰパケットに関するあるストリームからのパケットと、デバイス２２へと向かう複数のＶｏＩＰパケットに関する他のストリームからのパケットとを併合することによって形成されてもよいし、他の例でもよい。

次に、併合されたパケットは、併合されたパケットのヘッダのＩＰアドレスフィールドによって示される送信先へと送信される（図２のステップ５）。この例では、デバイス２１へと向かうＶｏＩＰパケットの２つのストリームからのパケットを併合することにより形成された併合されたパケットはデバイス２１へと送信され、デバイス２２へと向かうパケットの２つのストリームからのパケットを併合することによって形成された併合されたパケットはデバイス２２へと送信されるといった具合である。

併合されたパケットが、その併合されたパケットのヘッダのＩＰアドレスフィールドによって示される送信先で受信されたときは、併合されたパケットは、そのコンポーネントパケットに分割される。

本発明の好適な実施形態によれば、併合されたパケットのヘッダは、そのパケットが併合されたパケットであることを示す印を含む。特に好適な実施形態によれば、これは、併合されたパケットのヘッダに、そのパケットが併合されたパケットであることを示すＵＤＰポート番号を含むことによって、なされる。このＵＤＰポート番号は、併合されたパケットのために予約されている、送信先デバイスのＵＤＰポートに対応する。１つのＵＤＰポートが、全ての併合されたパケットが送られる「多重化ポート」として割り当てられる。このポートは併合されたパケットのために予約されているので、個別の接続には、どのようなものであっても割り当てられることは許されない。よって、このポートは併合されたパケットのみを受信する。送信先のデバイスは、こうして、到着するパケットが併合されたパケットである時を、認識する。本実施形態では、併合されたパケットが、併合されたパケットのヘッダのＩＰアドレスフィールドによって示される送信先デバイスで受信された時には、その併合されたパケットは、併合されたパケットのために予約されている送信先デバイスのＵＤＰポートへと向かわせられるだろう。

ＵＤＰポート番号を併合されたパケットのヘッダに含めることで、追加のマッピング表が必要とされなくなる。

併合されたパケットのために予約されるＵＤＰポート番号は、ポート２００２であることが提案される。

図３（ａ）は、本発明の方法で用いられる併合されたパケット１４を示す概略図である。パケット１４は、通常通り、ヘッダ４とペイロード５とを持つ。ヘッダは、ＩＰアドレスフィールド６を含む。ＩＰアドレスフィールド６は、併合されたパケットの送信先デバイスのＩＰアドレスを含む。上で説明した通り、ヘッダ４は、送信先デバイスにおいて併合されたパケットのために予約されているＵＤＰポートのポート番号を特定する、ＵＤＰフィールド７も含んでいてもよい。他の方法として、ヘッダは、そのパケットが併合されたパケットであることを特定する、他のフィールドを含んでいてもよい。

非リアルタイム・トラフィックにおいては、併合されたパケットを形成するために使われる全てのコンポーネントパケットが同じＵＤＰポート番号を持つことが可能であり、この場合にはヘッダ４のＵＤＰフィールド７は、併合されたパケットに明確に割り当てられたＵＤＰポート番号ではなく、元々のＵＤＰポート番号を含むことができるだろう。しかしながら、このことは、全てのＵＤＰポートが併合されたパケットを検出して扱うことが可能でなければならないであろうことを要求するだろう。それゆえに、実用上は、従来のアプリケーションＵＤＰポートとは区別される、併合されたパケットを扱うために明確に割り当てられたＵＤＰポートを持つことが好適である。もし、併合されたパケットを扱うために１つのＵＤＰポートが割り当てられたなら、他の全てのポートは通常通りにパケットを受信することができ、本発明のパケット多重化には影響を受けない。

併合されたパケット１４のペイロード５は、いくつかの多重化パケットフィールド５ａ、５ｂを含み、１つの多重化パケットフィールドが、それぞれのコンポーネントパケットに対応する。図３（ａ）は、２つのコンポーネントパケットを併合することにより形成された併合されたパケットを表し、それゆえに併合されたパケットは２つの多重化パケットフィールドを持つ。しかしながら、本発明はこれに限られるものではなく、２つを超えるパケットが併合されて、１つの併合されたパケットを形成してもよい。

パケット１４のヘッダ４は、ヘッダ４中の情報が全ての多重化パケットフィールド５ａ、５ｂに共通であるという点において、「共通ヘッダ」である。

それぞれの多重化パケットフィールド５ａ、５ｂは、多重化ヘッダ（「ＭＵＸヘッダ」）８ａ、８ｂと、ペイロードフィールド９ａ、９ｂとを含む。多重化ヘッダは、図３（ｃ）に示される。多重化ヘッダ８ａ、８ｂは、多重化ＩＤフィールド１５を含む。多重化ＩＤフィールド１５は、ＵＤＰポート情報の全体を含んでいてもよい。多重化ＩＤフィールド１５は、異なった接続を特定するためのものである。その値は、パケットが本発明の多重化を用いずに通常の方法で送信されたとした場合の、ＵＤＰ送信先ポートと同じである。すなわち、多重化ＩＤフィールド１５は、元々のコンポーネントパケットのＵＤＰポート番号である。

多重化ヘッダ８ａ、８ｂは、ペイロード長表示フィールド１６も含むことが好ましい。多重化ＩＤフィールド１５が、いつ次の多重化パケットフィールドが始まるかを示さないので、ペイロード長表示フィールド１６が提供される。よって、ペイロード長表示フィールド１６は、次の多重化パケットフィールドの開始点が決定されることを可能にするために、それぞれの多重化パケットフィールド（ヘッダ８ａ、８ｂとペイロード９ａ、９ｂ）のバイト数を示す。

ある実施形態では、多重化ＩＤフィールドは１６ビット（２バイト）のフィールドであり、ペイロード長表示フィールドは８ビット（１バイト）のフィールドである（ペイロード長表示フィールドに続くフィールドに、最大で２５６バイトの長さを与える）。この実施形態では、この結果、全体として、ＭＵＸヘッダフィールドは、３バイトのフィールドとなる。

それぞれの多重化パケットフィールド５ａ、５ｂは、次の通りに構成される。
｜｜ＭＵＸ ＩＤ／ＵＤＰポート（２バイト）｜｜長さ表示（１バイト）｜｜ペイロード（１−２５６バイト）｜｜

併合されたパケット１４のヘッダ４は、図３（ａ）に表されるフィールドに加えて、他のフィールドを含んでいてもよい。例として、併合されたパケットのヘッダ４は、併合されたパケットのＲＴＰ情報を含む、ＲＴＰヘッダフィールドをさらに含んでいてもよい。図３（ｂ）は、併合されたパケット１４’を概略的に表す図であり、ここで、併合されたパケット１４のヘッダ４は、ＲＴＰヘッダフィールド１０をさらに含む。

３ＧＰＰネットワークにおける音声トラフィックのような、いくつかのアプリケーションでは、ＲＴＰ情報が必須である。図３（ｂ）に示されるパケット構造は、併合されたパケットの全てのコンポーネントパケットが、共通のＩＰ／ＵＤＰ／ＲＴＰヘッダを共有する場合に、使われてもよい。また、それぞれのパケットに対する個々のＲＴＰ情報が必要とされない場合にも使われることができる。しかしながら、いくつかのアプリケーションでは、それぞれのパケットに対する個々のＲＴＰ情報が必要とされ、そのような場合には、図３（ｂ）のパケット構造は適していない。

図３（ｄ）は、それぞれの多重化パケットフィールド５ａ、５ｂのヘッダ８ａ、８ｂがＲＴＰ情報を含む際の、更なるパケット構造を表している。ＲＴＰ情報は、ＭＵＸヘッダ８ａ、８ｂの中の、ＲＴＰフィールド１７ａ、１７ｂの中で提供される。この例では、ＲＴＰフィールド１７ａ、１７ｂは、１２バイトの長さを持つ。

図４は、図３（ｄ）の併合されたパケットの構造を表している。併合されたパケットの共通ヘッダ４は、ＩＰアドレスフィールド６と、ＵＤＰヘッダフィールド７とを含んでいる。ＵＤＰヘッダフィールドは、そのパケットが併合されたパケットであることを示す、ＵＤＰポート番号（例えば２００２）を含んでいる。それぞれの多重化パケットフィールド５ａ、５ｂは、コンポーネントパケットのＵＤＰポート番号に対応するＵＤＰポート番号を含むＭＵＸヘッダと、ペイロード長表示フィールド（非図示）とを持つ。それぞれの多重化パケットフィールド５ａ、５ｂは、さらにＲＴＰヘッダフィールド１７ａ、１７ｂと、ペイロードフィールド９ａ、９ｂとを持つ（この例では、ペイロードはＮｂＵＰフレームとして表される）。ペイロード長表示フィールドに続くフィールド、すなわちＲＴＰヘッダフィールド１７ａ、１７ｂと、ペイロードフィールド９ａ、９ｂとは、（１バイトのペイロード長表示フィールドの例においては）全体で最大２５６バイトの長さを持つ。

ネットワークに追加の遅延をもたらすことを防止するために、パケットがそれぞれのストリームに投入されてすぐに、図２のステップ３において、パケットが併合のために選択されることが好ましい。ある実施形態では、併合ステップは、所定のタイムフレーム内にネットワークノードに到着したパケットを選択すること（および、タイムフレームの終了後すぐに併合されたパケットを形成すること）によって行われる。タイムフレームの長さは、１つのタイムフレームにおいて、いくつかのストリームに乗ってパケットが到着していることが見込まれることを保証するのに十分な長さとされるべきである（所定のタイムフレーム内にネットワークノードに到着したパケットを選択することによって併合ステップを実行することは、事実上、１つの併合されたパケットに併合されるコンポーネントパケットの数を制限する）。これは、有益な帯域幅の節約を得ることを確実にするためであるが、著しい遅延と、多重化ジッタとが持ち込まれるほどに、タイムフレームの長さが長くてはいけない。タイムフレームの長さは１ミリ秒程度の長さであることが、多くのアプリケーションにおいて適当なはずである。この程度のタイムフレームは、いくつかのパケットを集めて併合されたパケットにするのに十分に長く、遅延と多重化ジッタを低く保つのに十分に短いはずである。

時間に敏感ではないアプリケーションに対する場合、あるいはより大きい帯域幅の節約を得るためにユーザがより大きな遅延やジッタを受け入れる準備ができている場合には、より長いタイムフレームが用いられることができる。しかしながら、１ミリ秒の長さは、リアルタイム・トラフィックに対しては好ましい値である。

著しい遅延をネットワークに持ち込まないという要望に従うことを条件として、本質的には、１つの併合されたパケットへと多重化されうるパケットの数に制限は存在しない。ＩＰデータグラムの最大の長さは６５５３５バイトであり、イーサネット（登録商標）フレームの最大の長さは１５１８バイトである。このことは、１つの併合されたパケットへと多重化されうるパケットの数を制限するのは、実用上、イーサネット（登録商標）のフレームサイズであることを意味する。

帯域幅の削減に加えた、本発明のさらなる利点は、ネットワーク中のパケット数も削減されることである。一度に２つのパケットだけが１つの併合されたパケットへと多重化される場合でも、ネットワーク中のパケット数は、ただちに、多重化前の値の５０％にまで削減される。さらには、何十ものパケットが１つの併合されたパケットへと多重化されてもよい。このことは、ネットワーク中のパケット数が、多重化が用いられない場合におけるネットワーク中のパケット数の数パーセントにまで削減されるかもしれないことを意味する。（例えば、もし一度に１０パケットが１つの併合されたパケットへと多重化されるなら、ネットワーク中のパケットの数は、多重化前の値の１０％にまで削減される。）この、ネットワーク中のパケット数の削減は、パケット単位でトラフィックを処理するネットワークルータにおいて、非常に大きな処理の節約をもたらす。このことは、ＶｏＩＰの事例においては、音声品質にも肯定的な影響をもつ。なぜなら、ネットワーク中のパケットが少なくなり、それゆえに伝送中に廃棄されるパケットの数が少なくなるであろうからである。もし、何らかの理由によりパケットが廃棄されるとしても、その影響は複数の接続に分散するので、実用上、１つの接続に対する実際の影響は大したものではない。

表１は、本発明により得られる帯域幅削減の例を表している。表１は、ＩＰｖ４およびＩＰｖ６双方のＰｏＳと、ＩＰｖ４およびＩＰｖ６双方のイーサネット（登録商標）という、４つの異なった事例における結果を表す。ＰｏＳの例では、ネットワークは、ダブルＭＰＬＳフレーミング（ＶＰＮおよびトラフィック種別区別）を使うことが想定され、イーサネット（登録商標）の例ではＶＬＡＮタグが使われることを想定する。数字は、アクティビティファクタが６０％のＡＭＲ１２．２パケットに対するものである。

表１は、４つの事例のそれぞれについて、多重化しない場合の帯域幅（ＢＷ）と、２つのパケットが１つの併合されたパケットへと多重化された場合の帯域幅と、１０のパケットが１つの併合されたパケットへと多重化された場合の帯域幅とを表している。この結果は、併合されたパケットが共通のＩＰ／ＵＤＰヘッダを持ち、それぞれのＭＵＸヘッダ内にＲＴＰ情報を持つ、図３（ｄ）に表される構成を取ることを想定している。

（２または１０のコンポーネントパケットが１つに併合された場合に対して表される帯域幅は、コンポーネントパケット１つ当たりの実効帯域幅である。すなわち、２つのコンポーネントパケットをもつ併合されたパケットは、ＰｏＳ、ＩＰｖ４の事例では、３６．１４ｋｂｐｓの帯域幅を持つだろう。）

本発明のさらなる好適な実施形態によれば、さらに良好な帯域幅の節約を得るために、ＲＴＰヘッダフィールドは圧縮される。これは、ＲＴＰヘッダが、１回のＲＴＰセッションの間、変わらないままである多くの静的なフィールドを含んでおり、多くの場合、ＲＴＰヘッダが圧縮されてもよいために、可能である。ＲＴＰ圧縮は、パケットを併合されたパケットへと多重化することに対する追加的なものであるので、ＲＴＰ圧縮が使われなくてもよい状況下では、純粋な多重化へと戻ることが常に可能である。

特に好適な実施形態によれば、ＲＴＰヘッダ圧縮を用いる併合されたパケットは、ＲＴＰヘッダ圧縮を伴う併合されたパケットのために予約されているＵＤＰポートへと送られる。よって、ＲＴＰヘッダ圧縮を伴う併合されたパケットのために予約された１つのＵＤＰポートがあり、また、ＲＴＰヘッダ圧縮を伴わない併合されたパケットのためにもう１つのＵＤＰポートが予約されることが好ましい。

ＲＴＰヘッダ圧縮を伴う併合されたパケットのために予約されているＵＤＰポートは、ポート２００４であることが提案される。このポートは、ポート２００２がＲＴＰヘッダ圧縮を伴わない併合されたパケットのために用いられるのと同じように、用いられるだろう。

圧縮には、完全なヘッダが受信者へと転送される、初期化段階が、常に最初に存在する。完全なヘッダは保管され、復元で用いられる。初期化段階の後は、ヘッダ中の情報があまりにも変わって完全なヘッダを送信することが必要であろう場合を除いて、圧縮されたヘッダだけが送られる。他の方法として、完全なヘッダが受信されていて初期化段階が行われていることを確認するために、ヘッダが圧縮されたパケットの送信は、最初のパケットのすぐ後に開始されなくてもよい。例えば、最初の１０パケットが非圧縮パケットであり、これに続くパケットが圧縮されたパケットであってもよい。そして、同じ手続き（すなわち、最初の１０パケットを非圧縮パケットとして送ること）が、ヘッダが更新されなければならない場合に繰り返されてもよい。

多重化パケットフィールドの、ヘッダ８ａ、８ｂの可能な構造の一つが、図５に示される。図４の多重化ヘッダは、１ビットの長さを持つ、種別フィールド１８を含む。種別フィールド１８は、０と１という２つの状態を取り得る。０はＲＴＰヘッダ圧縮を伴わない併合されたパケットを示し、１はＲＴＰヘッダ圧縮を伴う併合されたパケットを示す。

図５のヘッダ８ａは、多重化ＩＤフィールド１５と、ペイロード長表示フィールド１６と、をも含む。多重化ＩＤフィールド１５は、１５ビットの長さを持ち、異なった接続を特定するためのものである。多重化ＩＤフィールド１５の値は、非多重化パケットのＵＤＰ送信先ポートを２で割ったものと同じである（偶数のポートのみが、ＲＴＰセッションでは用いられる）。ペイロード長表示フィールド１６は８ビットの長さを持ち、多重化ＲＴＰパケットの長さ（ヘッダ＋ペイロード）を、バイト単位で与える。

図６は、圧縮されたＲＴＰヘッダ１７’の、可能な形式の１つを表す。図６のＲＴＰヘッダ圧縮機構は、一つの例であって、他の機構が使われてもよい。

ＲＴＰヘッダは、接続の間変化し、それぞれのパケット内にあって渡される必要がある、２つのフィールドを含む。それは、シーケンス番号とタイムスタンプである。しかしながら、双方のフィールドは、明確に定義された方法で変化する。シーケンス番号は１つずつ進み、全ての送信されたパケットはどんなパケットの損失をも示す。また、タイムスタンプは、連続するパケットの間の時間差を表す。

図６の圧縮されたＲＴＰヘッダ１７’は、３ビットの長さのシーケンス番号（ＳＮ）フィールド１９を含む。シーケンス番号フィールド１９は、本来のシーケンス番号と同じように変化するが、８つの状態のみを持つ。パケットは一般的には非常に低いＢＥＲのネットワークで送られるため、８つの状態のみを持つことで十分なはずである。もし、シーケンス番号フィールドが十分でない場合には、完全なＲＴＰヘッダが使われるべきである。

図６の圧縮されたＲＴＰヘッダ１７’は、５ビットの長さの、タイムスタンプ（ＴＳ）フィールド２０をも含む。タイムスタンプフィールド２０は、基本的には本来のタイムスタンプと同じように変化するが、タイムスタンプフィールドの１ステップによって示される実際の時間差は、ペイロードの種類が初期化メッセージに基づいて知られているために、ペイロードの種類に依存する。圧縮されたＲＴＰヘッダ１７’のタイムスタンプフィールド２０の１ステップは、タイムスタンプフィールドにおいて本来のステップに変換されたときには、ＰＣＭ音声に対しては８０ステップ（５ｍｓ×１６ｋＨｚ＝８０）を表し、ＡＭＲコーディングされた音声に対しては３２０ステップ（２０ｍｓ×１６ｋＨｚ＝３２０）を表す。もし、タイムスタンプフィールドが何らかの理由で十分でないときは、完全なＲＴＰヘッダが使われるべきである。

圧縮されたＲＴＰヘッダ１７’は、併合されたパケットの完全な（すなわち、圧縮されていない）ＲＴＰヘッダフィールドの、例えば図３（ｄ）の併合されたパケットの完全なＲＴＰヘッダフィールド１７ａ、１７ｂの、代わりに使われてもよい。

他の方法として、図６の圧縮されたＲＴＰヘッダ中で、シーケンス番号ＳＮフィールドが８ビットであってもよく、タイムスタンプＴＳフィールドが１６ビットであってもよい。この場合には、それぞれのフィールドは、Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ３５５０に従った圧縮されていないヘッダにおいて持つであろう長さの、半分の長さを持つ。ＴＳフィールドは元のタイムスタンプと同じように変化する（ＲＦＣ３５５０）が、長さは元の半分であり、１６ｋＨｚのクロック基準においては４秒で割った余りとなる。

表２は、ＲＴＰ圧縮が採用された場合の、本発明により得られうる帯域幅削減の例を表す。表２は、表１に対してなされたのと同じ仮定の下、表１で検討された４つの場合に対する結果を表す。

全てのデバイスが、併合されたパケットを形成する多重化と、ＲＴＰヘッダ圧縮との、少なくとも片方をサポートできるというわけではないことに留意されたい。従って、パケットを送信する前に、送信ノードと受信ノードとが、併合されたパケットを形成する多重化が使われることに同意する必要があり、ＲＴＰヘッダ圧縮が使われるかどうかも同意する必要がある。

ＮｂインタフェースとＩｕインタフェースの双方におけるベアラの初期化段階は、例えば会話トラフィックのために使用される、サポートモードのための義務的なメッセージを含む。Ｎｂ／Ｉｕ ＵＰ ＰＤＵ Ｔｙｐｅ１４は、初期化で用いられ、メッセージは、何らかの追加機能のために用いられ得る、予備の拡張フィールドを（初期化フレームと確認応答フレームの双方に）含む。これらのフィールドが、本発明の多重化方法が適用可能であるかを検出するために使われることが提案される。（Ｉｕインタフェースでの透過モードは、初期化段階を持たないため多重化をサポートしないだろう。しかし、このモードはリアルタイムアプリケーションにでは使われない。）

多重化をサポートする発信ノード（例えばＭＧＷ（メディアゲートウェイ）またはＲＮＣ）が初期化メッセージを送るとき、例えば初期化フレームの予備の拡張フィールド中で最初のビットを１に設定するか、または特定の配列を使うかして、多重化を使いたいことを初期化メッセージ中で示すだろう。受信ノードは、初期化メッセージ中のそのビットまたは配列から、多重化が使われうることを知る。もし受信ノードが多重化をサポートしているなら、そのビットまたは配列を、通知のために、肯定的な確認応答メッセージの予備の拡張フィールドにコピーし、その確認応答メッセージを発信ノードへと送信する。このことは、発信ノードに、多重化が使われうることを確認する。しかし、もし受信ノードが多重化をサポートしていないなら、受信ノードは単に初期化メッセージの予備の拡張を無視し、通常の確認応答を送信する。初期化を開始した発信ノードは、そうして、多重化を使わないことを知る。

ノードが多重化をサポートしているが、ＲＴＰヘッダ圧縮はサポートしていないかもしれないため、多重化とＲＴＰヘッダ圧縮の双方をサポートできる発信ノードによって送られる初期化メッセージは、多重化とＲＴＰヘッダ圧縮に関して、別々の通知を含まなければならない。例えば、もし初期化メッセージの最初のビットが、発信ノードが多重化をサポートできることを示すなら、そのとき、発信ノードが更にＲＴＰヘッダ圧縮をサポートできるという事実は、最初の２ビットによって（あるいは異なった配列によって）示され得る。受信ノードは、そのとき、３つの方法で返信することができる。受信ノードは、ＲＴＰヘッダ圧縮を伴う多重化が使われてもよいことを、例えば、そのビットまたは配列を繰り返すことで、示してもよい。しかし、受信ノードは、（例えば、通常の多重化を示す、１ビット、または配列と共に返信することで）多重化は使われてもよいがＲＴＰヘッダ圧縮は使われてはいけない、ということを示すことで返事をしてもよいし、または、（例えば、多重化の通知を全く伴わないで返信することで）多重化は使われてはいけないことを示すことで返事をしてもよい。

Ｎｂインタフェースに対しては、ベアラの制御のための規格化されたプロトコルである、ＩＰベアラ制御プロトコル（ＩＰＢＣＰ）が既に存在する。このプロトコルは、多重化の適用可否を検知するためにも使われ得る。しかしながら、ＩＰＢＣＰは、Ｉｕインタフェースに対しては使われることができず、それ故に、多重化が可能かどうかを決定する必要がある時は、より一般的な解決策として、ＵＰ初期化の方が初期化には適しているかもしれない。一般的には、多重化が適用可能かどうかの決定工程は、移行段階の機能として見られ得る。すなわち、全ての関係するノードが多重化をサポートすることが知られている時には、省かれうる。この場合、多重化パケットは、常にＵＤＰポートに基づいて検知されうる（例えば、通常の多重化パケットに対してはポート２００２、ＲＴＰヘッダ圧縮を伴う多重化パケットに対してはポート２００４）。

原理的には、ＲＴＰヘッダ圧縮は、（図３（ｂ）のように）共通のＲＴＰヘッダを持つ併合されたパケット、あるいは従来からの併合されていないパケットにさえも、適用されうる。しかしながら、これらの場合には、ＲＴＰヘッダ圧縮に伴う帯域幅削減は、５−１０％程度にすぎないだろう。このことは、ＲＴＰヘッダ圧縮が接続の取り扱いに加えるであろう複雑さを正当化しそうにはない。

上で提示された例では、例えば、デバイス１１から２１へと向かうパケットはデバイス１１のＩＰアドレスを発信元アドレスとして持ち、デバイス２１のＩＰアドレスを送信先アドレスとして持つように、アドレスがデバイス間で交渉されていることが想定される。この例では、１つの発信元デバイス１１、１２、１３から、１つの着信デバイス２１、２２、２３へのストリームだけが、併合されてもよい。そして、併合は、発信元デバイスで行われる。ホスト１および２は、この例では、ルータとしてのみ使われる。しかしながら、本発明はこれに限られない。

例えば、ネットワーク１および２が、いくつかの他の内部ルーティングメカニズムを持っており、デバイス１ｘとデバイス２ｘとの間の全てのストリームに対して、ホスト１と２との間の接続が個々に確立されなければならない、かもしれない。（「デバイス１ｘ」は、ネットワーク１に存在するデバイス１１、１２、１３を示し、「デバイス２ｘ」は、ネットワーク２に存在するデバイス２１、２２、２３を示す。）このことは、例えば、ＩＰトランスポートネットワークがホスト１とホスト２との間で使われ、また、ネットワーク１と２が実際にはＩＰの代わりにＴＤＭまたはＡＴＭを用いる無線アクセスネットワークである、３ＧＰＰベースのネットワークである場合に、当てはまる。ホスト１および２は、その時は、メディア変換と交渉を扱ってネットワーク１がネットワーク２へと接続され得るようにするメディアゲートウェイである（前の例のような直接の通信が、中間の異なったトランスポートネットワークのために、不可能であるためである）。ホスト１と２との間の接続が個々に交渉され、実際の送信元および送信先から独立していることから、ネットワーク１からネットワーク２へと向かう全てのパケットのストリームは、リンク３において、同じＩＰ送信元アドレスおよび送信先アドレスのペアを持ち、ネットワーク１からネットワーク２へと向かうパケットについては、それらは全て、ホスト１において、併合（多重化）され得る（そして、ネットワーク２からネットワーク１へと向かうパケットの場合には、ホスト２において多重化され得る）。

この代替例においては、ホスト１に到着するパケット（ネットワーク１からネットワーク２へと渡されるパケットの場合）は、複数のストリームへと分類される。それぞれのストリームは、単一のＤｉｆｆＳｅｒｖクラスのパケットを備えることが好ましい。そして、併合されたパケットが、２以上のストリームからのパケットを併合することにより形成され、併合されたパケットはホスト２へと送信される。併合されたパケットはホスト２において併合を解かれ、そのコンポーネントパケットは、ネットワーク２に存在するそれぞれの送信先へと渡される。

この第２の例は、多重化による利得が、多重化されうるストリームの数に直接に比例し、この場合には、通常は通信量が最も多く、最も高価であるリンク（すなわち、隔離した場所間のコアリンク）において併合が行われうるために、このメカニズムの潜在能力を特に示す。併合がホスト１において実行される時は、デバイス１１から発せられてデバイス２１へと向かうストリームからのパケットを、ネットワーク１に存在するデバイス１ｘから発せられてネットワーク２に存在するデバイス２ｘへと向かう他のどんなストリームからのパケットとも併合することができる（１つのＤｉｆｆＳｅｒｖクラスのみのパケットが好ましくは併合されるという、条件に従う）。

本発明の方法は、ＩＭＳパケットに適用されてもよい。このことは、ＳＩＰを伴った他の種類の初期化工程を必要とするだろう。

本発明の方法は、適切にプログラムされたプロセッサによって実現されてもよい。本発明の方法を実行するためにプロセッサを制御するためのプログラムは、例えばコンピュータディスク、磁気ディスク、または光ディスクのように、どのような適切な記憶媒体に保存されてもよい。

通信システムの概略図である。 本発明の方法のブロックフロー図である。 本発明の方法で用いられるパケットの概略図である。 本発明の方法で用いられるパケットの概略図である。 多重化ヘッダの概略図である。 本発明の方法で用いられる他のパケットの概略図である。 併合されたパケットの構造を示す概略図である。 多重化ヘッダの概略図である。 圧縮されたＲＴＰヘッダの概略図である。

Claims (22)

1. ＩＰネットワークのノード間でＩＰパケットを伝送する方法であって、
   パケットを第１のネットワークノードで受信する工程と、
   前記受信したパケットを、それぞれのストリームのパケットが共通のＩＰヘッダを共有するように、複数のストリームに分ける工程と、
   複数のパケットを併合して、１つの併合されたパケットを形成する工程と、
   前記併合されたパケットを第２のネットワークノードへ送信する工程と、
   を備えることを特徴とする方法。
2. １つのストリームのパケットが、同じタイプの情報を含むことを特徴とする、請求項１に記載の方法。
3. 少なくとも１つのストリームのパケットがＶｏＩＰパケットであることを特徴とする、請求項２に記載の方法。
4. 複数のパケットを併合して、１つの併合されたパケットを形成する前記工程は、少なくとも第１のストリームからパケットを選択し、少なくとも第２のストリームからパケットを選択することと、当該選択したパケットを併合して、前記併合されたパケットを形成することとを含むことを特徴とする、請求項１乃至３の何れか１項に記載の方法。
5. 前記第１のストリームのパケットと、前記第２のストリームのパケットとが、同じタイプの情報を含むことを特徴とする、請求項２又は３に従属する、請求項４に記載の方法。
6. 複数のパケットを併合する前記工程は、あらかじめ決定されたタイムウインドウ内に前記第１のネットワークノードで受信されたパケットを併合することを特徴とする、請求項１乃至５の何れか１項に記載の方法。
7. 前記タイムウインドウが、１ミリ秒の長さを持つことを特徴とする、請求項６に記載の方法。
8. 前記併合されたパケットが、共通ヘッダと、２以上の多重化パケットフィールドとを含み、それぞれの多重化パケットフィールドは、当該併合されたパケットのそれぞれのコンポーネントパケットに相当することを特徴とする、請求項１乃至７の何れか１項に記載の方法。
9. 前記併合されたパケットの前記共通ヘッダ中で、当該パケットが併合されたパケットであることを示す工程を更に備えることを特徴とする、請求項８に記載の方法。
10. 前記併合されたパケットの前記共通ヘッダに、併合されたパケットであることを示すＵＤＰフィールドを割り当てる工程を備えることを特徴とする、請求項９に記載の方法。
11. 選択されたＵＤＰポートを、併合されたパケットのみを扱うように割り当てる工程を更に備えることを特徴とする、請求項１０に記載の方法。
12. 前記共通ヘッダ中で共通のＲＴＰ情報を提供する工程を備えることを特徴とする、請求項８乃至１１の何れか１項に記載の方法。
13. それぞれの前記多重化パケットフィールド中で、それぞれのコンポーネントパケットに対し、ＲＴＰ情報を提供する工程を備えることを特徴とする、請求項８乃至１１の何れか１項に記載の方法。
14. それぞれの前記多重化パケットフィールド中で、それぞれのコンポーネントパケットに対し、圧縮されたＲＴＰ情報を提供する工程を備えることを特徴とする、請求項１３に記載の方法。
15. 前記併合されたパケットにおいて、当該パケットが圧縮されたＲＴＰ情報を含んでいることを示す工程を備えることを特徴とする、請求項１４に記載の方法。
16. それぞれの前記多重化パケットフィールドがそれぞれのヘッダを含み、
    前記方法は、それぞれの前記ヘッダ中において前記パケットが圧縮されたＲＴＰ情報を含むことを示す工程を更に備えることを特徴とする、請求項１５に記載の方法。
17. 前記第２のネットワークノードにおいて前記併合されたパケットをコンポーネントパケットへと分離する工程を更に備えることを特徴とする、請求項１乃至１６の何れか１項に記載の方法。
18. 請求項１乃至１７の何れか１項に定義される方法を実行するようにプロセッサを制御するためのプログラムを含む記憶媒体。
19. ＩＰネットワークのノードであって、
    パケットを受信する手段と、
    前記受信したパケットを、それぞれのストリームのパケットが共通のＩＰヘッダを共有するように、複数のストリームに分ける手段と、
    複数のパケットを併合して、１つの併合されたパケットを形成する手段と、
    前記併合されたパケットを第２のネットワークノードへ送信する手段と、
    を備えることを特徴とするノード。
20. １つのストリームのパケットが同じタイプの情報を含むように、前記受信したパケットを複数のストリームに分けるように構成されたことを特徴とする、請求項１９に記載のノード。
21. 少なくとも第１のストリームからパケットを選択し、少なくとも第２のストリームからパケットを選択して、当該選択されたパケットを併合して前記併合されたパケットを形成することにより、前記併合されたパケットを形成するように構成されたことを特徴とする、請求項１９又は２０に記載のノード。
22. 前記第１のストリームのパケットと前記第２のストリームのパケットとが、同じタイプの情報を含むことを特徴とする、請求項１９乃至２１の何れか１項に記載のノード。

Images