JP5129233B2 - 通信ネットワーク - Google Patents

Description

本発明は、コネクションレス通信ネットワークに関し、特に帯域が複数の使用者によって共用されるそのようなネットワークに関する。

インターネット・プロトコル・ネットワーク（ＩＰパケット・ネットワーク）の使用者に影響を与える最も重大な問題は、サービスの質（ＱｏＳ）が補償されないことである。この結果、例えばＶｏＩＰ通話を行なうことが可能である一方で、パケット遅延によって通話の質が粗末なものになる。

ファイル共有が、ＶｏＩＰ通話の最初に確立する際に遅延を起こし得るというさらなる問題がある。その理由は、ピア・ツー・ピア・ファイル共有ネットワークは、ファイル転送速度を上げるために、その優先順位が比較的低いにも関わらず、利用可能な帯域の全てを使用するからである。

したがって、ネットワーク上での輻輳は、遅れたり失われたりしたパケットが、約３００ｍｓｅｃ（音声）の有用時間（time-useful）ウィンドウしか有さないゆえに再送され得ないため、特に双方向ＶｏＩＰまたは動画通話にとって特に問題である。したがって、バックボーンまたはＭボーンを外れたネットワークの使用が増加し、またホーム・ルータ上での局所無線ネットワーク機構「ピギーバック」ゆえに、高優先度または時間重視の（タイムクリティカルな（time-critical））送信は保護される必要がある。

時間重視の送信に対する保護を導入する試みがなされてきたが、それらの多くはルータおよび他のネットワーク共用設備に対して複雑な変更を施すことを含んでいる。この１つの例は、ＥＰ０７０６２９７に見られる。ＥＰ０７０６２９７は、ＡＴＭ切り替えで輻輳を制御する方法を記述している。この方法は、ＵＤＰ、ＴＣＰに対しては実際には効果を持たないとともにピア・ツー・ピア・トラフィックが多い場合にはあっさりと輻輳が最大になる硬直的な輻輳制御機構をもたらす。

既知の別の仕組みは、ＵＳ２００４／０１７２４６４に開示されている。これは、２つのサイト（現実には、おそらく２つの接続されたビジネス上の位置）の間に２つのＱｏＳクラスを定める。この仕組みは、２つの場所の間のパイプの両端において、リアル・タイムのトラフィックのためにこのパイプの一部を確保しておく（事実上、仮想的な賃貸されたライン）受け入れ制御アルゴリズムを有することによって実現されている。厳格なＱｏＳ割り当てを課すことに対する要求があり、また、両端においてゲートウェイまたはルータを変更する必要があり得る。

ＩＰネットワーク上でスピードが重視されるパケットが優先されるようにする問題に対する別の解決策が提案されている。これには、ＡＴＭまたはＭＰＬＳのような下層のネットワーク構成要素を用いること、詳細なパケット検査技術を用いること、サービスに優先順位をつけること、終端対終端輻輳通知機構、極端なものにはネットワークをさらに提供すること、が含まれる。

これらの解決策は、全て、用いられているルータに対する変更やプロトコルの変更が必要になることに関連する著しい費用または複雑な問題を有しており、この問題をＩＰレイヤー９から移動することになってＩＰを用いる利点が減少したり、トラフィックのフローが上がると高価になる。詳細パケット検査法は、パケットが暗号化されていると機能しないというさらなる欠点を有している。

公共のＩＰネットワークにおけるＱｏＳの問題のほとんどは、フローは利用可能な帯域とは無関係にネットワーク容量を埋め尽くすピア・ツー・ピア・トラフィックに起因しているので、運用者は、ＱｏＳ機構を導入することなく音声または動画サービスを提供することが困難となる。Ｐ２Ｐトラフィックは、これらのサービスに、これらのサービスからは特に悪影響を受けることなく、悪影響を与えるからである。
欧州特許第０７０６２９７号明細書 米国特許出願公開第２００４／０１７２４６４号明細書

本発明によれば、共用通信ネットワーク内で帯域を確保する方法であって、
前記ネットワークの第１ノードと第２ノードとの間で予め定められたレートでダミー・データ・パケットのストリームを送信する工程と、
前記第２ノードから前記第１ノードに送信された対応するダミー・データ・パケットのストリームを受信する工程と、
前記第１、第２ノードの間の遅延および（または）パケット紛失を割り出す工程と、
前記パケットの遅延および（または）紛失を、それ以下では後続の時間重視の（time critical）トラフィックについてのサービスの質が不十分となる閾値と比較する工程と、
前記サービスの質が不十分な場合に前記第１、第２ノードの間のダミー・データ・パケットの送信レートを上げる工程と、
を備える方法が提供される。

前記第１、第２ノードの間で前記ダミー・データ・パケットを送信することは、トラフィックの輻輳が高まることが予想される予め定められた時点に生じ得るか、時間重視のトラフィックが前記第１、第２ノードの一方で開始する時点に先立つ予め設定された時点に生じ得る。

本発明の特徴によれば、通信システムであって、前記システムは前記システムの１つのノードにおける制御手段が前記システムの少なくとも１つの別のノードへの保障された経路を前記少なくとも１つの別のノードにダミー・データ・パケットのストリームを送信することによって確立するとともに前記別のノードから対応するダミー・データ・パケットのストリームを受け取る共用通信ネットワークを備え、前記制御手段が、前記送信の際の遅延および（または）パケット紛失を割り出し、サービスの質が時間重視のデータ・パケットを満足に送信するための予め定められた閾値を下回っている場合に前記ダミー・データ・パケットの送信レートを上げる、通信システムが提供される。

前記第１、第２ノードの間で前記ダミー・データ・パケットを送信することは、トラフィックの輻輳が高まることが予想される予め定められた時点に生じ得るか、時間重視のトラフィックが前記第１、第２ノードの一方で開始する時点に先立つ予め設定された時点に生じ得る。

前記１つのノードで開始する時間重視のデータ・パケット・ストリームの開始を検出した際に、前記制御手段は時間重視のパケットを前記ダミー・データ・パケットと置き換え得、また、前記時間重視のデータ・ストリームの送信の完了の際に、前記制御手段は前記ダミー・データ・パケットを送信することを再開し得る。

本発明の特徴に従った通信ネットワークおよび本発明の方法の使用法が、添付の図面をあくまで例として参照しながら、次に説明される。

まず、回路エミュレーション機構であるＩＥＴＦ ＩｎｔＳｅｒｖシステムと時に呼ばれる、従来技術の解決策を引き続き考察するべきである。この機構は、パケットがあらゆる個数の異なる経路を介して流れるはずである通常の原理とは対照的に、パケットに対して特定の経路を設ける。続いて図４を参照すると、データ経路１上にある各ルータは、フローのために特定の帯域を確保していなければならない。フローの仕様は、ＲＳＶＰプロトコルを用いてネットワークを介して知らされ、また各ルータは（ルータの変更を要求する）特定のソフトウェア上で動作することが必要になっているとともに付加的な処理およびルータのメモリを必要とする多数のキューを生成する。この機構は大きなネットワーク内では管理することが困難であり、また、ルータが１つでも帯域外で動作すると、上記の確保しようとする試みが失敗する。

帯域について協調する複雑なシステムが必要であり、また、確保を行なう際の遅れは非常に長くなることがあり、次の、例えばＶｏＩＰ通話上でのユーザの番号をかける動作が遅れる結果となる。この機構をより大きなネットワークへと広げようとすると、深刻な問題も生じる。

次に、図１を参照すると、本発明は、最低限のパケット遅延を有る程度保証する必要がある場合にユーザが帯域を利用できることを確実にするという課題に対する簡単な解決策を提供する。多数（簡略化のために２個のみが図示されている）のルータ３を備えるＩＰネットワーク２は、例えば別のネットワーク・ユーザ４、５によって引き起こされるＰ２Ｐトラフィックに起因する輻輳にさらされ得る。

第１ユーザ端末６が第２ユーザ端末７への保証された経路を必要としているとすると、端末６はデータ・パケットの連なりを送信し始める。時間とともに、このデータ・パケットのフローは、輻輳が生じた結果、優先度のより低いデータ・パケットを退ける。これが起こるのには、保証されたフローの要求に先立ってダミー・データ・パケットのフローを確立することによってスピードが重視されるデータ・パケットの送信の要求に先立って端末６、７間で経路が確立されるようにするために、ある程度の時間がかかる。したがって、端末６のユーザが保証されたフローを要求する際に、スピードが重視されるパケットはダミー・データ・パケットのフローに置換される。これは、スピードが重視されるデータ・パケットのためのフローを、輻輳しているネットワーク内で要求があったときに確立しようとするよりもずっと旨く機能する。

したがって、ダミー・フローがＰ２Ｐトラフィックを制限し（このような制限がないと、Ｐ２Ｐトラフィックによって利用可能な帯域の全てが使い尽くされる）、Ｐ２Ｐトラフィックが退くまで待っている間に著しい遅延をもたらすことなしに、音声または映像通話を確立することが可能である。

図１は、本発明の概念を最も簡単な形態で示している。これが、標準的なＴＣＰ／ＩＰスタック上に位置している特別なネットワーク・ソフトウェアを動かす端末ノード６、７に基づいているので、ルータまたは他のネットワーク構成部品に対する変更は全く必要ない。

したがって、図２を参照すると、本発明を実行するのに唯一求められている調整は、その間にダミー・フローが確立される予定の端末点を変更することである。ダミー・フロー・アプリケーション８は、最大１００ｍｓの遅延で６４ｋｂ／ｓｅｃのフローを監視するとともにこのフロー・レートが維持されるようにパケット送信を調整する標準的なパケット・フローと同様に、ＲＣＰ／ＵＤＰを用いるＴＣＰ／ＩＰスタック上に位置している。これは、リアルタイム・フローについては普通であるようにＲＴＣＰフィードバックを用いて行なわれ、またＲＴＰ／ＲＴＣＰ層９の動作に対して何の変更も必要ない。

したがって、ＵＤＰ層１０、ＩＰ層１１、および物理層は、本発明を実行することによって何も変更しない。また、ＲＴＣＰレスポンスを監視することによって、Ｐ２Ｐトラフィックを輻輳している経路から退けるとともにダミー・フロー層８とアプリケーション・インターフェース（例えばＶｏＩＰ１２）との間のインターフェースが輻輳を引き起こしている他のトラフィック・フローが停止するのを待つことなくすぐに確立された経路を用いることができるようにダミー・フロー・アプリケーションが必要に応じて６４ｋＢｉｔｓ／ｓｅｃ以上へと送信レートを増やすことができる。

本発明の利点の例を検討するために、次に、図３を参照する。図３は、別のいわゆる広帯域トラフィックと共用されているＶｏＩＰネットワークの一部を示している。ルータまたはＤＳＬモデム２０（これは、時に「ホーム・ハブ（Home Hub）」と呼ばれる）は、多くのコンピュータ２１、２２、および例えば家庭電話２３によって共用されているかもしれない。家庭用ビデオ・レコーダー（図示せず）のような別の装置も、時間重視でないダウンロードするのに家庭用ハブを用いているかもしれず、また、非常警報器のような装置が時間重視でない通信モードで非常事態サービスに接続するためにホーム・ハブを用いているかも知れない。
多くのＤＳＬ広帯域接続において、アップリンク帯域は、ダウンリンク帯域よりも著しく狭い。ＡＤＳＬにおける典型的な違いは、２５６ｋＢｉｔ／ｓのアップリンクと２ＭＢｉｔ／ｓのダウンリンクである。したがって、家庭におけるユーザの誰かが（例えば映画を後で観るためにレコーダーにダウンロードするために）時間重視でない通信のために全アップリンクまたは全ダウンリンクを使用している場合、同じＤＳＬリンクを用いて電話２３から音声通話を行なおうとしても、みな失敗するであろう。

そこで、ルータ２０と例えば広帯域遠隔アクセス・サーバ（Ｂ−ＲＡＳ）２５との間にディジタル加入者線アプリケーション・マルチプレクサ（ＤＳＬＡＭ）２４を用いてダミー・フローを確立することによって（ＤＳＬＡＭ２４は、これを実施することによって影響を受けず、本発明を実行するための変更は全く必要ない）、時間重視のパケットのための保証された経路が利用可能になるとともにＰＳＴＮのＰＯＴＳの側面の一部として受け入れられることになった「インスタント・テレフォニー（instant telephony）」の類のものを、電話または広帯域アプリケーションのための別のラインを必要とすることなく引き続き提供することができる。

Ｂ−ＲＡＳ２４への経路（これは顧客とＩＰネットワークとの間の最初のゲートウェイである）が保証されることによって、通話や動画通話を即座に構成する際の遅延を回避することができる。この結果、電話２３と電話２６との間の通話は、ルータ２０とＢ−ＲＡＳ２５との間の別のＩＰトラフィックによって悪影響を受けない。

本発明は、ダミー・フロー・トラフィックの具体的な値を参照して記述されたが、予測されるトラフィックの種類に応じて、トラフィックのより高いまたは低い保証されたフローが提供されてもよい。同様に、保証されたパケット・フローがアプリケーション層１２によって引き継がれるのと同時に、１つ目のフローが用いられていながらさらなるリアルタイム・アプリケーションの開始に備えてスピードが重要でないパケットを退けるために新たなダミー・フローが開始されてもよい。

ダミー・フロー・アプリケーションは、トラフィック量が多いときのみ、またはホーム・ハブ２０が輻輳することが予想される予め定められたときに動作し得る。したがって、ダミー・フロー・アプリケーション８は、事前設定された時間帯のみ動作し得る。この事前設定された時間帯は、１日における時刻／１週間における時刻によって、またはホーム・ハブ２０において輻輳が起こりそうな時間を突き止めることを含めることによって、変えることができる。

本方法は、家庭用（ホーム・ハブ）アプリケーションに適用されるだけでなく、あらゆる種類のＬＡＮ、無線ネットワーク等においても同様に実施され得る。特に、無線ネットワークが共同体で共用される場合、無線ルータの所有者は、自身の時間重視のパケット・フローのために保証された通信フローを要求するとともに例えば営業時間の間Ｐ２Ｐトラフィックを退ける必要があるかもしれない。

ＩＰネットワーク内で、簡略化された形での実施の概要を示している。 用いられているネットワーク層を概略的に示している。 ＤＳＬまたはＡＤＳＬ通信環境で本発明を用いることを示す概略的なブロック図である。 従来技術の仕組みの概略的なブロック図である。

Claims (12)

1. 共用通信ネットワーク内で帯域を確保する方法であって、
   前記ネットワークの第１ノードと第２ノードとの間で予め定められたレートでダミー・データ・パケットのストリームを送信する工程と、
   前記第２ノードから前記第１ノードに送信された対応するダミー・データ・パケットのストリームを受信する工程と、
   前記第１、第２ノードの間の遅延および（または）パケット紛失を割り出す工程と、
   前記遅延および（または）パケット紛失を、それ以下では後続の時間重視のトラフィックについてのサービスの質が不十分となる閾値と比較する工程と、
   前記サービスの質が不十分な場合に前記第１、第２ノードの間のダミー・データ・パケットの送信レートを上げる工程と、
   前記第１ノードおよび前記第２ノードの間の時間重視のデータ・パケット・ストリームの開始を検出した際に、前記時間重視のパケットを前記ダミー・データ・パケットに代えて前記ストリームおよび前記対応するストリーム中へと置き換える工程と、
   を備える方法。
2. 前記第１、第２ノードの間で前記ダミー・データ・パケットを送信することが、トラフィックの輻輳が高まることが予想される予め定められた時点に生じる、請求項１の方法。
3. 前記第１、第２ノードの間で前記ダミー・データ・パケットを送信することが、時間重視のトラフィックが前記第１、第２ノードの一方で開始する時点に先立つ予め設定された時点に生じる、請求項１または２の方法。
4. 前記時間重視のデータ・ストリームの送信の完了の際に、前記ダミー・データ・パケットを送信することを再開する、
   ことをさらに備える、請求項１乃至３のいずれか１項の方法。
5. 通信システムであって、前記システムは前記システムの１つのノードにおける制御手段が前記システムの少なくとも１つの別のノードへの保障された経路を前記少なくとも１つの別のノードにダミー・データ・パケットのストリームを送信することによって確立するとともに前記別のノードから対応するダミー・データ・パケットのストリームを受け取る共用通信ネットワークを備え、
   前記制御手段が、前記送信の際の遅延および（または）パケット紛失を割り出し、サービスの質が時間重視のデータ・パケットを満足に送信するための予め定められた閾値を下回っている場合に前記ダミー・データ・パケットの送信レートを上げ、
   前記第１ノードおよび前記第２ノードの間の時間重視のデータ・パケット・ストリームの開始を検出した際に、前記制御手段が前記時間重視のパケットを前記ダミー・データ・パケットに代えて前記ストリームおよび前記対応するストリーム中へと置き換えるように動作可能である、
   通信システム。
6. 前記制御手段が、選択されたノード相互間の輻輳が高いことが予想される予め定められた時点に前記ダミー・データ・パケットの送信を行なう、請求項５の通信システム。
7. 時間重視のトラフィックが前記ノードの１つにおいて開始することが予想される時点に先立つ予め定められた時点に、前記第１、第２ノードの間での前記ダミー・データ・パケットの送信を行なう、請求項５の通信システム。
8. 前記時間重視のデータ・ストリームの送信の完了の際に、前記制御手段が前記ダミー・データ・パケットを送信することを再開する、請求項５の通信システム。
9. 前記ノードの１つが共用家庭内ルータであって、前記制御手段が前記家庭内ルータに取り付けられている端末内に位置する、請求項５乃至８のいずれか１項の通信システム。
10. 前記共用家庭内ルータが無線ハブである、請求項９の通信システム。
11. 前記無線ハブがＶｏＩＰ通話を送信する、請求項１０の通信システム。
12. 前記ノードの１つが広帯域遠隔アクセス・サーバである、請求項５乃至１１のいずれか１項の通信システム。

Images