JP2009542047A - リアルタイムサービスのための優先度特定の方法及び装置 - Google Patents

Abstract

データパケットを多数のホップからなるネットワーク経路を介して発信元から宛先へ送信するためのシステム及び方法が開示される。データパケットに関連する再生時間とホップ数の合計がデータパケットのヘッダ内に記憶される。データパケットはネットワーク経路を介して発信元から宛先に送信される。

Description

本発明は概略としてインターネットプロトコル（ＩＰ）ネットワークにおけるサービス品質に関し、より具体的にはＩＰネットワークにおけるデータパケットの優先付けに関する。

インターネットプロトコル（ＩＰ）ネットワークにおけるサービス品質（ＱｏＳ）とは、ＩＰネットワークを介して伝送される異なるデータストリームに対してＩＰネットワークによって提供されるスループット保障（即ち、保障されたスループットレベル）である。

ルーターのようなネットワーク構成物はパケットを正しくルーティングするためにＩＰヘッダ内の表示メカニズムに依存することが多い。いくつかのＩＰパケット標準又はバージョンが存在する。例えば、パケットはインターネットプロトコルバージョン４（ＩＰｖ４）（即ち、ＩＰｖ４パケット）又はインターネットプロトコルバージョン６（ＩＰｖ６）（即ち、ＩＰｖ６パケット）によって規定される標準に従う。

図１はサービスのタイプ（ＴＯＳ）フィールド１０４を含むＩＰｖ４パケットヘッダ１００のブロック図である。ＴＯＳフィールド１０４はインターネットサービス品質の選択のためのものである。サービスのタイプは優先度（Precedence）、遅延（Delay）、スループット（Throughput）、及び信頼性（Reliability）等のパラメータを介して指定される。ＩＰｖ４ヘッダ１００はまた、生存時間（ＴＴＬ)フィールド１０８を含む。ＴＴＬフィールド１０８は、パケットがネットワーク内に相当長く存在し、廃棄されるべきか否かをネットワークルーター又はスイッチに示す値を含む。様々な理由のために、パケットが合理的な長さの時間内にその宛先に配信されないことがある。例えば、正しくないルーティングテーブルによってパケットが２つのルーター間を無限にループしてしまうことがある。解決策は所定時間後にそのパケットを廃棄することである。初期ＴＴＬ値１０８はパケットヘッダの８ビットフィールドにおいて設定される。各ルーターがＴＴＬフィールドから少なくとも１カウントを引くことを要求されるので、通常カウントはパケットが廃棄される前に許されるルーターホップ数を示すのに使用される。

図２はトラフィッククラス（ＴＣ)フィールド１０４を含むＩＰｖ６ヘッダ２００のブロック図である。ＩＰｖ６ヘッダ２００はまた、ホップ限界フィールド２０８を含む。ホップ限界フィールド２０８はパケットが廃棄前に移動できる最大ホップ数を示す。

図３（ａ）にＩＰｖ４ＴＯＳフィールド１０４の詳細を示す。ＴＯＳフィールド１０４は優先度(precedence)フィールド３０４及び優先権(priority)フィールド３０６を含む。優先度フィールド３０４はＩＰｖ４パケットに優先を与えるために使用されるフィールドである。優先度フィールド３０４は、ネットワークが優先権フィールド３０６を用いてパケットの優先度を決定するのか、又は優先権フィールド３０６が無視されてネットワークはパケットの優先度を決定しないのかを指定する。優先権フィールド３０６によってネットワークがネットワーク内で存在し得る種々の待ち行列処理及び輻輳制御メカニズムの利益を受けることができる。

図３（ｂ）にＩＰｖ６ＴＣフィールド２０４の詳細を示す。ＴＣフィールド２０４は開始ルーター及び／又は転送ルーターによる使用においてＩＰｖ６パケットの異なるクラス又は優先権を識別し、区別するために利用できる。ＴＣフィールド２０４はＩＰｖ６パケットに対する種々の形態の「差異付けられたサービス」を提供するために使用される。ディファレンシャル・サービス・コード・ポイント（ＤＳＣＰ）又はＤｉｆｆＳｅｒｖｉｃｅは、ネットワークルーターに差異付けられたグレードのサービスを様々なパケットストリームに適用するよう促し、それらを異なるパー・ホップ・ビヘイビア（ＰＨＢ）に従って転送する各ＩＰパケットヘッダ内のマーカーである。これによってインターネット及び他のＩＰに基づくネットワークサービスプロバイダが、差異付けられたレベルのサービスを顧客及び彼らの情報ストリームに提供することが可能となる。ＤｉｆｆＳｅｒｖはＩＰｖ４パケットのＴＯＳフィールドにも実装されている。

パケットがＩＰルーターに入ると、そのＩＰヘッダが検査される。検査によって、パケットが現在のルーターから転送される次のホップ及び優先度が決定される。優先度はＩＰｖ４パケットのＴＯＳフィールド１０４についての優先度フィールド３０４及び優先権フィールド３０６並びにＩＰｖ６パケットのＴＣフィールド２０４内のディファレンシャル・サービス・コード・ポイント（ＤＳＣＰ）値を検査することによって決定される。パケットのヘッダフィールドがその優先度を決定するのに十分な情報を提供しない場合は、優先度決定が行えるような更に多くの情報を得るために深いパケット検査が実行される。

パケットの優先度は、いつパケットがその次のホップに送信されるようにスケジューリングされるかに影響する。有線ネットワークにおいては、パケットスケジューリングの作業は（一定の電力、データレートで、１つの共有チャネルを介して）パケットをタイムスロットに関連付けることである。有線ネットワークにおいては、パケットのスケジューリングは、パケットが転送されるときにその機能がタイムスロット、電力、データレート、又はこれらの組合せ等のリソースをスケジューリングすることよりも大雑把なものと言える。具体的には、発信元の特性、ＱｏＳ要求、チャネル状態及び／又は待ち行列長に基づいて、無線スケジューラはタイムスロット、電力、データレート及び／又はチャネルを送信用パケットに割り当てる。

リアルタイム・トランスポート・プロトコル（ＲＴＰ）はオーディオ及びビデオのようなリアルタイムデータを送信するためのインターネットプロトコルである。ＲＴＰはデータのストリーミングをサポートする。ＲＴＰ音声ストリームを無線チャネル上でスケジューリングするために、パケットが宛先ルーターで期限となる時間（即ち、パケットの期限）が音声ストリームを送信するルーターによって知られる必要がある。しかし、ＲＴＰ音声ストリームのパケットは暗号化されていることがある。音声ストリームが暗号化されている場合、パケットから期限が取得されることはない。具体的には、パケットが暗号化されている場合、パケット検査を関与させるあらゆる方法は通常、パケットデータの重要度についての更なる知識・情報が暗号化のために取得され得ないので、有効なものとはならない。

無線リンクはネットワークにおいて通常は最初か最後のリンクにある。ＱｏＳの大部分は最後の無線ホップノード（即ち、ルーター）の挙動によって決定されることが多い。最後の無線ホップノードは、同じサービスアンサンブル（例えば、単一のボイス・オーバー・インターネット・プロトコル（ＶｏＩＰ）電話呼）のパケット間でパケットの相対的重要度を決定するために、パケットのヘッダを単独で使用することは通常はできない。

従って、最後のホップノードにおけるパケットの優先度を識別するための改善された方法が必要である。

本発明は多数のホップを有するネットワーク経路を介して発信元から宛先までパケットを送信するための方法及び装置である。データパケットに関連する再生遅延及びホップ数の合計がデータパケットのヘッダに記憶される。データパケットは発信元から宛先へネットワーク経路を介して送信される。

一実施例では、再生遅延及びホップ数の合計が発信元で計算される。あるいは、その合計が宛先側で計算される。

一実施例では、データパケットは再生遅延及びホップ数の合計が尽きる前にＶｏＩＰ電話呼中に処理される（例えば、無線電話によって再生される）。再生遅延及びホップ数の合計はパケットのヘッダのＴＴＬフィールドに記憶される。ホップ数は、例えば、発信元によって送信先をピングする（テスト送信して応答を求める）ことによって決定され得る。データパケットの優先度は再生遅延及びホップ数から決定され得る。

これら及び他の発明の有利な効果は以下の発明の詳細な説明及び添付図面を参照することによって当業者に明らかなものとなる。

本発明の実施例によると、図４は送信ノード４０４から受信ノード４０６へ送信される通信のブロック図を示す。一実施例では、送信ノード４０４及び／又は受信ノード４０６は無線電話である。送信ノード４０４はパケットを送信ルーター４０８（例えば、基地局ルーター（ＢＳＲ））に送信する。送信ルーター４０８はパケットのＴＯＳ又はＴＣフィールドをＤｉｆｆＳｅｒｖに準拠するように設定できる。

送信ルーター４０８はＴＴＬ値を所定の最大値（即ち、ＴＴＬ_ＭＡＸ）に設定する。この所定の最大値は（例えば、セッション開始プロトコル（ＳＩＰ）／セッション記述プロトコル（ＳＤＰ）セッションニゴシエーションにおいて）送信ルーター４０８と宛先ルーター４２４（例えば、ＢＳＲ）間で交渉されたパラメータ（ＴＴＬ_ＮＥＧ）とすることができる。あるいは、所定の最大値はデフォルトの最大値とすることもできる。

パケットは第２のホップ４１２、第３のホップ４１６、及び第４のホップ４２０へ送信される。これらのホップ４１２、４１６、４２０の各々は、例えば、ルーター又はスイッチであればよい。各ルーター４１２、４１６、４２０はパケットヘッダのＴＴＬフィールドから１を引く。パケットは宛先ルーター４２４に送信される。宛先ルーター４２４は受信ＴＴＬ（即ち、ＴＴＬ_ＲＸ）を抽出する。一実施例では、宛先ルーター４２４はホップカウントを決定する。ホップカウントは、
Ｈｏｐｓ＝ＴＴＬ_ＭＡＸ−ＴＴＬ_ＲＸ、
又は、
Ｈｏｐｓ＝ＴＴＬ_ＮＥＧ−ＴＴＬ_ＲＸ
から決定される。

宛先ルーター４２４はスケジューラ４２８を含む。スケジューラ４２８はパケットがそのホップカウントを使い切る前に受信ノード４０６に到着することを保障する。スケジューラ４２８はスケジュールするパケットにどれくらい柔軟性があるかを判断するためにホップカウントを使用する。パケット時間（即ち、パケットに関連する所定の時間間隔）毎に、スケジューラ４２８はホップカウントから１を引く。

宛先ルーター４２４は後続のリアルタイム（ＲＴ）パケットについてＴＴＬ値を、ＴＴＬ＝Ｈｏｐｓ＋１に設定する。宛先ルーター４２４はＴＴＬ_ＲＸについて連続的なチェックを実行する。ＴＴＬ_ＲＸ≠０の場合、宛先ルーター４２４はホップカウントを再評価し、必要に応じてホップ数を再計算する。ＴＴＬ_ＲＸ＝０の場合、宛先ルーター４２４はＴＴＬ＝Ｈｏｐｓ＋１を使用し続ける。

上記はＴＴＬフィールドを使用するものとして記載したが、発明はまた、ＩＰｖ６パケットに、特にホップ限界フィールドを用いることにも適合する。以下に詳細を記載するように、本発明のある実施例ではＴＯＳ又はＴＣフィールドをＴＴＬ又はホップ限界フィールドとの関係で使用する。

図５は音声ストリームパケットの期限を決定するための発明の一実施例において実施されるステップを示すフローチャートである。修正されたＴＴＬ（又はホップ限界）フィールドの使用のため、パケットの期限を決定するのに深いパケット検査は必要ではない。

まず、パケットを送信ルーター４０８から宛先ルーター４２４へＩＰネットワークを介して搬送するのに必要なホップ数がステップ５０４で決定される。一実施例では、送信ルーター４０８が宛先ルーター４２４をピングしてホップ数を決定する。ホップ数を決定する理由は、宛先ルーター４２４がその後、パケットの期限を決定するために送信ルーター４０８と宛先ルーター４２４間のＩＰルーターホップカウントを使用するためである。

次に、（例えば、無線電話で出力する等）パケットを処理するのに必要な期間が宛先ルーター４２４によって決定される。通常のＶｏＩＰアプリケーションは入着パケットを再生出力バッファにバッファリングし、種々のネットワーク遅延（即ち、ジッタ）を補償するためにそれらの再生出力を遅らせる。これによって、最も遅いパケットが再生出力されるのに間に合うように到着する。宛先ルーター４２４によって課された再生遅延の長さ（即ち、再生出力バッファの長さ）はステップ５０８で決定される。

宛先ルーター４２４における再生出力バッファ長を決定する理由は、どれくらい多くの追加「仮想」ホップがホップカウントに追加される必要があるかの判断によって、パケットの期限を示すことが可能となるためである。「仮想」ホップを決定することは、ホップについてＴＴＬフィールドに追加された合計に等しい再生出力バッファについてのＴＴＬフィールドの合計を追加することである。

例えば、送信ルーターと宛先ルーター間のホップカウントがＮ回ホップであり、宛先ルーター内の再生出力バッファがＸ個のパケットである場合、ホップカウントはＮ＋Ｘに設定される必要がある。従って、Ｘはそのパケットの他のパケットに対する重要度を表している。

パケットが宛先ルーターによって受信されたときに残っているホップカウントは、ステップ５１２において、パケット期限のスケジューラに対するインジケータとして使用される。音声パケットがＩＰネットワークを介して送信ルーターから宛先ルーターまで進むとき、ＩＰルーター毎に、送信ルーターによって設定されたホップカウントから１を引く。

宛先ルーターはホップカウントＸを受け取る。上述したように、その後宛先ルーターはこの残りのホップカウントＸを、パケットのスケジューリングにおいてスケジューラがどれだけの柔軟性を有しているかの、無線チャネルスケジューラに対するインジケータとして使用する。パケット時間毎に無線チャネルスケジューラはＸから１を引く。Ｘが大きい場合、小さい値Ｘの場合と比較して、無線チャネルスケジューラは端末にパケットを配信するためにより積極的なスケジューリングメカニズムを用いることができる。Ｘが増加すると、スケジューラはパケットが使われなければならない前により長い時間を持つことになるので、Ｘはパケットの相対的重要度を表す。同様に、Ｘが減少すると、スケジューラはパケットが使われなければならない前により短い時間を持つことになる。その結果、Ｘはパケットの重要度を表すことになる（即ち、パケットの重要度が高いほどＸは小さい）。

受信ノード４０６によって送信ノード４０４に送信されたパケットについて、同じ処理が適用される。従って、宛先ルーター４２４が受信ノード４０６から送信ノード４０４へ送信するパケットを受信するとき、宛先ルーター４２４は、宛先ルーター４２４が送信ルーター４０８から以前に受信したパケットに基づいてパケットのホップカウントをどう設定するかを既に「知っている」ことになる。ホップカウントが設定されると、ステップ５１２において、送信ルーター４０８はパケットを受信し、パケットが例えば高い優先度を有し、送信ノード４０４に早く配信される必要があると判断することができる。

図６は宛先ルーター４２４によってパケット受信時に実行されるステップのフローチャートである。宛先ルーター４２４はステップ６０４においてＩＰネットワークから到着パケットを受信し、ステップ６０８においてＴＯＳ（又はＴＣ）フィールド及びＴＴＬ（又はホップ限界）フィールドをチェックする。ステップ６１２において、宛先ルーター５２４はＴＯＳ（又はＴＣ）フィールドが「即時（immediate）」又は「優先（priority）」に等しいかを判断する。ステップ６１２においてＴＯＳフィールドが「即時」又は「優先」に等しくない場合、宛先ルーター４２４（即ち、スケジューラ４２８）は、ステップ６１４において「通常」優先度扱いの方法を使用する。通常優先度扱いの方法は、（例えば、ＴＴＬフィールドが宛先ルーター４２４から送出される前にＴＴＬフィールドがゼロまで減少しない程に十分に高いときに）パケットが待ち行列に向かった順序でパケットを宛先ルーターの待ち行列に並ばせるステップを含む。

ステップ６１２においてＴＯＳフィールドが「即時」又は「優先」の場合、ステップ６１６において宛先ルーター４２４はＴＴＬ＝０か否かを判断する。肯定の場合、ステップ６２０において宛先ルーター４２４（即ち、スケジューラ４２８）はパケットを送信のために優先権を与える（即ち、そのパケットを迅速に処理する）。宛先ルーター４２４は、そのパケットをできるだけ早く「再生」するために宛先ルーターの待ち行列内でそのパケットを繰り上げ移動することによってそのパケットを迅速に処理する。否定の場合、ステップ６２４において、宛先ルーター４２４は通常の優先度での送信をそのパケットに用いる。宛先ルーター４２４は受信ノード４０６からパケットを受信することもできる。この場合、宛先ルーター４２４はＴＴＬフィールドを１だけ減少させる（即ち、通常ＴＴＬ扱いの挙動をとる）。

前述の説明は、発明の実施例を実施するのに必要な処理ステップという観点で本発明の実施例を記載するものである。これらのステップは適切にプログラムされた（その構成が本技術分野で周知の）コンピュータによって実行され得る。適切なコンピュータは、例えば、公知のコンピュータプロセッサ、メモリユニット、記憶装置、コンピュータソフトウェア及び他の部材を用いて実施できる。そのようなコンピュータの高レベルのブロック図を図７に示す。コンピュータ７０２は、そのような動作を規定するコンピュータプログラムインストラクションを実行することによってコンピュータ７０２の全体動作を制御するプロセッサ７０４を含む。コンピュータプログラムインストラクションは記憶装置７１２（例えば磁気ディスク）に記憶され、コンピュータプログラムインストラクションの実行が望まれるときにメモリ７１０に読み込まれる。コンピュータ７０２はまた、他の装置と（例えば、ローカルに、又はネットワークを介して）通信するために１以上のインターフェイス７０６を含む。コンピュータ７０２はまた、コンピュータ７０２とのユーザ相互作用を可能とする装置を表す入出力部７０８（例えば、ディスプレイ、キーボード、マウス、スピーカ、ボタン等）を含む。

当業者であれば、実際のコンピュータの実施が他の部材も同様に含み、図７がそのようなコンピュータの部材の一部の高レベルの例示目的の代表例であることが分かるはずである。例えば、コンピュータ７０２は図４の送信ルーター及び／又は受信ルーターを表すものといえる。さらに、当業者であれば、ここに記載される処理ステップは専用ハードウェア（その回路にはそのような処理ステップを実行するために具体的に構成されている）を用いても実施できることが分かるはずである。あるいは、処理ステップはハードウェア及びソフトウェアの様々な組合せを用いて実施できる。また、処理ステップはコンピュータ内で行われてもよいし、より大きな機械の一部であってもよい。

以上の詳細な説明はそれぞれの説明及び例示ごとに理解されるべきものであり、限定的なものではない。ここに開示される発明の範囲はこの詳細な説明によってではなく、特許法によって認められる全幅で解釈されるように特許請求の範囲で決定される。ここに開示又は説明した実施例は本発明の原理の説明のためだけのものであり、種々の変形例が当業者によって発明の範囲と精神から離れることなく実施され得る。当業者は発明の範囲と精神から逸脱することなく種々の他の構成の組合せを実施し得る。

図１は従来技術のＩＰｖ４パケットヘッダのブロック図である。 図２は従来技術のＩＰｖ６パケットヘッダのブロック図である。 従来のＩＰｖ４パケットヘッダのサービスタイプ（ＴＯＳ）フィールドのブロック図である。 従来のＩＰｖ６パケットヘッダのトラフィッククラス（ＴＣ）フィールドのブロック図である。 図４は本発明の実施例による、送信ルーターがパケットを宛先ルーターに送信するブロック図である。 図５は本発明の実施例による、パケットの期限をスケジューリングするために実行されるステップのフローチャートである。 図６は本発明の実施例による、送信ルーターから受信されたパケットの優先度を決定するために宛先ルーターで実行されるステップのフローチャートである。 図７は本発明の実施例によるコンピュータの高レベルのブロック図である。

Claims (10)

1. データパケットを多数のホップからなるネットワーク経路を介して発信元から宛先へ送信するための方法であって、該方法が、
   前記データパケットのヘッダ内に、前記データパケットに関連する再生時間と前記ホップ数の合計を記憶するステップ、及び
   前記データパケットを前記発信元から前記宛先へ前記ネットワーク経路を介して送信するステップ
   からなる方法。
2. 請求項１の方法であって、さらに、前記合計を前記発信元及び前記宛先の少なくとも１つにおいて計算するステップを含む方法。
3. 請求項１の方法であって、さらに、前記再生時間及び前記ホップ数から前記データパケットの優先度を決定するステップからなる方法。
4. 請求項１の方法において、前記記憶するステップが、前記合計を前記データパケットのヘッダの生存時間（ＴＴＬ）フィールド及びホップカウントフィールドの少なくとも１つに記憶するステップからなる方法。
5. 請求項１の方法であって、スケジューリングの順序を決定するために前記合計を使用するステップからなる方法。
6. 請求項１の方法であって、前記データパケットに関連する再生時間を決定するステップからなる方法。
7. データパケットを多数のホップからなるネットワーク経路を介して発信元から宛先へ送信するためのシステムであって、該システムが、
   前記データパケットのヘッダ内に、前記データパケットに関連する再生時間と前記ホップ数の合計を記憶するように構成され、前記データパケットを前記発信元から前記宛先へ前記ネットワーク経路を介して送信するように構成された発信元
   からなるシステム。
8. 請求項７のシステムであって、さらに、前記データパケットに関連する再生時間を決定するように構成されたプロセッサからなるシステム。
9. 請求項７のシステムにおいて、前記宛先が、前記再生時間と前記ホップ数の合計が尽きる前に前記データパケットを処理するシステム。
10. 請求項７のシステムにおいて、前記宛先が前記再生時間及び前記ホップ数から前記データパケットの優先度を決定するシステム。

Images