JP5830543B2 - 輻輳公開対応ネットワークで輻輳管理をサポートする方法 - Google Patents

Description

本発明は、輻輳公開対応ネットワークで輻輳管理をサポートする方法に関する。送信側ホストおよび受信側ホストが、中間ルータ経由のネットワーク経路を通じてパケットのフローを送信することにより相互に通信する。中間ルータは、輻輳を検出すると、輻輳情報を含めることにより、前記フローのパケットを輻輳パケットとしてマーキングする。輻輳は、輻輳フィードバックメカニズムによって送信側ホストに通知される。送信側ホストは、輻輳通知を受信すると、輻輳応答パケットの量が通知された輻輳レベルと一致するか否かに応じて、輻輳情報を含めることにより、送信するパケットの一部を輻輳応答パケットとして宣言する。

また、本発明は、輻輳公開対応ネットワークシステムに関する。該システムは、送信側ホスト、受信側ホストおよび中間ルータを備える。前記送信側ホストおよび前記受信側ホストが、前記中間ルータ経由のネットワーク経路を通じてパケットのフローを送信することにより相互に通信する。前記中間ルータは、輻輳を検出すると、輻輳情報を含めることにより、前記フローのパケットを輻輳パケットとしてマーキングする。送信側ホストに輻輳を通知するように構成された輻輳フィードバックメカニズムが設けられる。送信側ホストは、輻輳通知を受信すると、輻輳応答パケットの量が通知された輻輳レベルと一致するか否かに応じて、輻輳情報を含めることにより、送信するパケットの一部を輻輳応答パケットとして宣言する。

最後に、本発明は、輻輳公開対応ネットワークで用いられる中間ルータに関する。送信側ホストおよび受信側ホストが、前記中間ルータ経由のネットワーク経路を通じてパケットのフローを送信することにより相互に通信する。前記中間ルータは、輻輳を検出すると、輻輳情報を含めることにより、前記フローのパケットを輻輳パケットとしてマーキングするように構成される。送信側ホストに輻輳を通知するように構成された輻輳フィードバックメカニズムが設けられる。送信側ホストは、輻輳通知を受信すると、輻輳応答パケットの量が通知された輻輳レベルと一致するか否かに応じて、輻輳情報を含めることにより、送信するパケットの一部を輻輳応答パケットとして宣言する。

輻輳公開に基づく輻輳ベースのネットワークトラフィックポリシングは、ネットワーク輻輳時にユーザトラフィックを計測するネットワークリソース制御方式として期待されている。例えば非特許文献１において、フローレート公平性（これは従来から用いられてきた）は、ネットワークリソースのリソース配分および計測可能性に対する妥当なメカニズムではないことが論じられている。代わりに、コストベースのメカニズムが、より良好なリソース配分方式を提供することが示唆されている。この場合、「コスト」は、与えられた利用可能なネットワークリソースの下で、各ユーザの送信が他の送信を制限する程度を意味する。このコストを測定する尺度として、各ユーザによって引き起こされるネットワーク輻輳量が提案されている。輻輳に基づくネットワークトラフィックポリシングメカニズムは、ネットワーク事業者が自己のネットワーク上のトラフィックを管理するためのネット中立的な手段を提供する。

輻輳ベースのネットワークトラフィックポリシングを実現するためのいくつかの提案がなされている。例えば、Ｒｅ−ＥＣＮ（Relay or Re-feedback of Explicit Congestion Notification）は、ＩＥＴＦ（Internet Engineering Task Force）ＣＯＮＥＸ（Congestion Exposure）ワーキンググループでなされた提案であり、例えば非特許文献２に記載されている。以下でさらに詳細に説明するように、Ｒｅ−ＥＣＮ、すなわち明示的輻輳通知の再フィードバックは、パケットが引き起こすと予想される輻輳を公開するためのフィードバックメカニズムである。主要な特徴は、リソース使用量に基づくのではなく、ネットワーク内の他者に対してユーザトラフィックが引き起こしている輻輳に基づくユーザベースの計測可能性である。なお、注意すべき重要な点であるが、Ｒｅ−ＥＣＮは輻輳公開メカニズムを実行する一手段にすぎず、代替手段も可能である。

例えば、輻輳公開システムの特定の実施態様である図１に示すようなＲｅ−ＥＣＮシステムには、次のような複数の機能エンティティが存在する。ルータは、輻輳を検出し、明示的輻輳通知（Explicit Congestion Notification, ＥＣＮ）を自己のキュー内のパケットに適用する。受信側エンドポイントは、この輻輳情報を収集し、それをセンダ（送信側）に返送する。センダは、トランスポートプロトコル（例えばＴＣＰ）を実行し、トランスポートプロトコルの輻輳制御アルゴリズムのためにこの情報を使用することができる。また、センダは、後続のパケット送信に対して、輻輳への自己の寄与を宣言することにより、受信したフィードバックに応答することが期待される。これは、一部のパケットを適切にマーキングすることによって行われる。事業者が提供する輻輳公開対応ポリサは、この情報を使用することにより、それに応じてトラフィックをポリシングまたは計測することができる。

このように、輻輳公開アプローチは、センダが、例えばＴＣＰ送信レートを減少させることによって、ネットワークからの輻輳通知に適応し、ネットワークへの自己の現在の輻輳寄与を宣言するというアイデアに基づく。これにより、ネットワーク（例えばルータ、ホスト、ポリサ等）は、経路上の現在の輻輳を知ることができる。例えば、このような情報を用いて、何らかの事業者ポリシーに従って、自己の輻輳寄与に基づいてトラフィックをポリシングすることができる。

このようなポリシングにより、課金等の事業者の措置につながる可能性があるので、ユーザは通常、自己の現在の輻輳寄与を過大に宣言することには興味がない。輻輳公開フレームワークでは、監査機能という追加的なエンティティが存在する。監査機能は、不適合（例えば詐欺）が起こらないようにするため、輻輳寄与が過少宣言もされていないことを強制することができる。不適合が検出された場合、監査機能は通常、識別された不適合フローのパケットの廃棄を開始して、その特定のフローに対する送信レートの低下を強制する。要約すれば、輻輳公開において、センダが、ネットワークへの自己の輻輳寄与を正確に宣言することが重要である。

また、このアプローチは、さまざまな場面（例えば、固定またはモバイル通信の場面）で機能する。輻輳公開をモバイル通信ネットワークに導入する場合、主要な課題は、新たなネットワークアタッチメントによって引き起こされる経路変化の扱いである。基本的に、次の２つの主要な問題点がある。

・新たなワイヤレスアクセスポイントとの関連づけにより、モバイルノードとの間で現在のフローに対する経路が変化すること。新たな経路は輻輳が増減する可能性があるが、現在の送信動作および現在の輻輳宣言は、前に受信したフィードバックに基づいており、新たな経路の条件に合致しないかもしれない。特に、モバイルユーザは、より高い輻輳の領域に移動した場合、出口監査機能において意図せずに不足を生じる可能性があり、出口監査機能は、これに応じて、特定の一部のトラフィックを不適合として分類するかもしれない。

・複数のアクセスネットワークがハンドオーバー決定のために利用可能なとき、モバイルノードは現在、平均経路輻輳に関して最適なものを選択する手段を有しない。いくつかのモビリティアーキテクチャは、現在のアクセスポイント負荷に基づいてハンドオーバー決定を行うが、輻輳が経路中の異なる位置で生じている場合にはそれでは不十分である。

B. Briscoe, "Flow Rate Fairness: Dismantling a Religion", ACM Computer Communications Review, 37(2), 63-74 (Apr. 2007) B. Briscoe, A. Jacquet, C. Di Cairano-Gilfedder, A. Salvatori, A. Soppera, and M. Koyabe, "Policing Congestion Response in an Internetwork using Re-feedback", Proc. ACM SIGCOMM'05, CCR, 35(4):277-288, Aug. 2005 Bob Briscoe, Arnaud Jacquet, Toby Moncaster, and Alan Smith, "Re-ECN: Adding accountability for causing congestion to TCP/IP", Internet Draft http://tools.ietf.org/id/draft-briscoe-tsvwg-re-ecn-tcp-08.txt, Internet Engineering Task Force, September 2009

したがって、上記のことから、本発明の目的は、輻輳公開対応ネットワークで輻輳管理をサポートする頭書のような方法において、実施の容易なメカニズムを使用することにより、モバイルユーザが、モビリティイベントにおける経路変更の処理に関して体感品質が向上するような改良およびさらなる展開を行うことである。

本発明によれば、上記の目的は、請求項１の構成を備えた方法によって達成される。この請求項に記載の通り、該方法は、前記送信側ホストと前記受信側ホストとの間の前記ネットワーク経路を通じて送信されるパケットに含まれる輻輳情報に基づいて集約輻輳が求められることを特徴とする。

また、上記の目的は、請求項１７の構成を備えた輻輳公開対応ネットワークシステムによって達成される。この請求項に記載の通り、該ネットワークシステムは、前記送信側ホストと前記受信側ホストとの間の前記ネットワーク経路を通じて送信されるパケットに含まれる輻輳情報に基づいて集約輻輳を求めるようにさらに構成されたことを特徴とする。

最後に、上記の目的は、請求項１８の構成を備えた中間ルータによって達成される。この請求項に記載の通り、該中間ルータは、前記送信側ホストと前記受信側ホストとの間で該中間ルータ経由の前記ネットワーク経路を通じて送信されるパケットに含まれる輻輳情報に基づいて集約輻輳を求めるようにさらに構成されたことを特徴とする。

本発明によって初めて認識されたこととして、経路変更の処理に関してモバイルユーザの体感品質の向上は、公開された輻輳情報を考慮することによって実現可能である。具体的には、本発明によれば、公開されたネットワーク経路輻輳情報に基づいて集約輻輳が求められる。すなわち、集約輻輳は、送信側ホストと受信側ホストとの間の経路を通じて送信されるデータパケットに含まれる輻輳情報に基づいて計算することができる。実際の物理経路を細かい粒度で見る代わりに、データパケットにおいて（例えば輻輳パケットおよび／または輻輳応答パケットにおいて）利用可能な輻輳情報を活用し、輻輳情報は、トラフィックのいずれかの方向に対する事業者ドメイン内の経路上の関連するネットワーク要素（例えば中間ルータ）に基づいて集約される。こうして、集約輻輳を使用することにより、ユーザは、前もってエンドホストで適時かつ安全に輻輳応答を調整することができるように支援されることが可能となるため、モバイルユーザは、移動しながら、より良好な体感品質が得られる。結果として、モバイルノードは、特にモビリティイベントにおいてモバイルの場面での最適な体感品質が得られるように、経路変更における支援を受けることができる。

好ましい実施形態によれば、集約輻輳は、輻輳マーキングパケットの割合を計算することによって求めてもよい。それぞれのノード（例えばルータ、ｅノードＢ等）に対して、ダウンリンク方向における輻輳マーキングパケットの割合を計算する集約メカニズムが提供されてもよい。

これに加えて、または別法として、集約輻輳は、特にダウンリンク方向において、所定期間にわたり輻輳マーキングパケットの数を合計することによって求めてもよい。

結果として、この粗視化計算により、エンドホスト（モバイルノードと称してもよい）のセットがダウンリンク方向で受けている輻輳の全体的な推定が可能となる。この計算が粗視化であるのは、アプリケーション、通信相手、経路、トポロジー等に依存しないからである。アップリンク方向では、このような計算は、ネットワークのエッジ付近のノード（例えばゲートウェイ）に委譲されてもよい。

有利な態様として、輻輳情報は、Ｒｅ−ＥＣＮ固有のマーキングを含んでもよい。これにより、輻輳情報は、Ｒｅ−ＥＣＮの指定されたプロトコルフィールドを見ることによってデータパケットから取得することが可能となる。

好ましい実施形態において、経路上で予想される輻輳レベルに関する経路輻輳予測が、特に経路輻輳予測係数を計算することによって、集約輻輳から導出されるようにしてもよい。これにより、モバイル通信ネットワークにおける輻輳およびハンドオーバー決定に対するモバイルノードの応答を改善することができる。

有利な態様として、ネットワークにより生成されるヒント（ネットワーク生成ヒント）が提供されてもよい。ヒントは、経路輻輳予測を含む。

また、ネットワーク生成ヒントが、ネットワーク要素および／またはエンドホストに配信されてもよい。ネットワーク要素は、例えば、中間ルータ、アクセスポイントまたは２つのエンドホストの間の任意のノードを含む。これにより、輻輳情報を、ネットワーク内に、および、エンドホスト（例えば、ネットワークリソースを使用しているモバイルノード）に、拡散することができる。したがって、より良好なネットワーク利用が可能となり、モバイルユーザによる輻輳寄与を制限することによって、より良好なパフォーマンスを達成することができる。

モバイルノード（エンドホストと称してもよい）の体感品質を改善することに関して、ネットワーク生成ヒントが、モビリティイベントにおいて、特にハンドオーバーイベントの期間中に、ホストを支援するために使用されてもよい。トランスポートプロトコルインスタンスがユーザプリファレンスも考慮することができるような輻輳ベースのポリシングメカニズムである輻輳公開において、モバイルノードが新たなセルに入り、このセルの輻輳が高いというネットワーク生成ヒントを受信したときの可能な対処として、所定の輻輳レベル以上で特定のアプリケーションのデータトラフィックを継続しないと決定してもよい。例えば、輻輳ヒントが、あるしきい値よりも大きいというヒントの場合である。

有利な実施形態において、ネットワーク生成ヒントは、エンドホストにおける輻輳応答を調整するために使用されてもよい。このヒントメカニズムに対する可能性および関連性のある最適化として、モバイルノードがあるアクセスポイントから別のアクセスポイントへ移動しているときにその輻輳応答を調整するためにモバイルノードを支援することが挙げられる。この組織的アプローチを通じて、モバイルノードが最初のデータパケットのセットを実際に送信する前に、予想される輻輳レベルに関する情報がモバイルノードに提供される。そのヒントに基づいて、モバイルノードは、ネットワークに送信するパケットを多くするか少なくするかを決定してもよい。これにより、モバイルノードは、受信機から輻輳通知を実際に受信し始める前に、予想される輻輳レベルに、より迅速に適応する。また、これにより、ネットワークにかける負荷が少なくなる可能性がある。なお、輻輳公開環境で予測される監査機能は、輻輳応答パケットが輻輳パケットよりも影響が大きいという不変性を維持する。このため、通信の適応が遅すぎるときには、監査機能は、エンドシステムが送信レートの正しいレベルに適応するまでの間、廃棄数を増やし、スループットを大きく低下させてもよい。

有利な態様として、ネットワーク生成ヒントは、モビリティ管理決定に影響を与えるために、モビリティ管理エンティティに配信されてもよい。例えば、ヒントは、特定のアタッチメントポイントについて決定するために使用されてもよい。これにより、例えば、モバイルＩＰベースのモビリティ方式の場合にはモバイルノードにおいて、あるいは３ＧＰＰの場合には３ＧＰＰ ＭＭＥにおいて、モビリティ管理機能は、輻輳レベルに関するヒントを受信し、その情報に応じて、モバイルノードを移動させるか否かを決定してもよい。なお、負荷ベースのモビリティ管理方式（これは、それぞれのコンポーネントに対する負荷が等しくなるように最適化することを試みる）とは異なり、ここで提案する方式は、ネットワーク内の複数のエンドツーエンド経路を用いてすべてのモバイルノードの輻輳を発見的に推測しようと試みるので、全体的な状況が考慮され、輻輳の場合に対処するだけでなく、相異なる輻輳レベルにも対処することができる。

有利な態様として、ネットワーク生成ヒントの生成は、経路上の一部のノード間の輻輳を示すローカル輻輳ビューを構成するために、個別のネットワーク要素（例えばルータ）間で独立していてもよい。

好ましい実施形態によれば、ローカル輻輳ビューは、割合として表現されてもよい。

さらなる好ましい実施形態によれば、経路全体に対する輻輳を予測するために、経路に沿った一部に対するローカル輻輳ビューを組み合わせてグローバル輻輳ビューを生成してもよい。

さらなる好ましい実施形態によれば、ネットワーク生成ヒントの計算に関する精度情報がヒントとともに通知されてもよい。

有利な態様として、ネットワーク生成ヒントの通信が、ネットワーク要素（例えばｅノードＢ）のエアインタフェースに関するヒントをホスト（例えばモバイルノード）のインタフェースと交換することによって実行されてもよい。

また、ネットワーク生成ヒントの通信が、ＩＣＭＰ（Internet Control Message Protocol）制御メッセージを使用することによって実行されるようにしてもよい。

本発明を好ましい態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。

既知の輻輳公開フレームワークの概略図である。 ハンドオーバーイベントによる経路変更を例示する模式図である。 本発明による方法の適用場面を例示する模式図である。 本発明による方法の別の適用場面を例示する模式図である。

図１は、輻輳公開フレームワークおよびその機能エンティティの概略を示している。輻輳公開（Congestion Exposure）については、例えば非特許文献２に記載されている。

図１に示すように、センダ１０２（例えばＴＣＰセンダ）とレシーバ１０４（例えばＴＣＰレシーバ）が、ルータ１０６、１０８、および１１０ならびにポリサ１１２および監査機能１１４を含む経路を通じて通信する。センダ１０２およびレシーバ１０４に対して、経路は、過渡的または永続的な輻輳により、遅延、パケット損失またはＣＥ（"Congestion Experienced",「輻輳を受けている」）マーキングレートに関して相異なる特性を示し得る。ルータ１０６、１０８、および１１０のようなルータは、アクティブキュー管理（active queue management, ＡＱＭ）メカニズムを実装しており、初期輻輳を検出すると、斜線を施した矩形で示すパケット１２２のようなＩＰパケット内の明示的輻輳通知（ＥＣＮ）ビットを確率的に（ランダム早期検出（random early detection, ＲＥＤ）を用いて）セットする。レシーバ１０４は、パケット１２２のような輻輳マーキングパケットを受信すると、そのトランスポートプロトコルのフィードバックメカニズムを通じて（例えばＴＣＰヘッダフィールドを用いて）、現在の輻輳レベルについてセンダに通知する。すると、センダ１０２は、受信した輻輳通知に応答して、特定のトランスポートプロトコルの輻輳制御メカニズムに従って送信レートを適応させ、塗りつぶした矩形で示す輻輳応答パケット１２０のような送信されるパケットに再エコー（re-echo）情報を書き込むことによって、このコネクション上で送信されるＩＰトラフィックの一部をネットワークへの自己の輻輳寄与として宣言する。これは、「負」のバイト（すなわち、輻輳フィードバックによって報告される輻輳寄与）の数と、「正」のバイト（すなわち、センダにより宣言された輻輳寄与応答）の数とを一致させることを目標とする。

このように、輻輳公開の基本原理は、受けた輻輳に関する情報をネットワークに再挿入することである。これにより、入口ポリサ１１２は、ネットワークポリシーに従って、許容される輻輳に関してユーザにどのような権限があるかを決定することができる。これに対して、監査機能１１４は、パケットドロッパとして実現され、宣言されていることが正しいか否かを検証し、場合によっては、負の下流輻輳を永続的に宣言している（すなわち、自己の輻輳寄与を過少宣言している）フロー中のパケットを廃棄する。

事業者は、例えば与えられた期間にユーザが引き起こすことが許容される輻輳をレート制限するため、または、ある特定の計測方式を適用するために、ポリサ１１２をネットワーク入口に配置することを選択してもよい。所定の割当量が消費された場合には、例えばサービスレートを低下させる等の、ある種のペナルティが可能である。なお、入口ポリサ１１２は、宣言された輻輳をレート制限するだけである。したがって、輻輳を過少宣言することにより、効用の増大に対応する、より高いビットレートにつながる可能性が依然として存在する。正直なユーザの場合、応答および輻輳の割合は出口で相殺するはずである。輻輳を過少宣言しているユーザの場合にはこれは成り立たず、そのトラフィックは結局出口で正味の不足を生じる。したがって、監査機能は、不適合フローにペナルティを科するために、経路における最終エンティティであることが提案されている。

ホスト間のトラフィックは双方向的であるので、コネクション設定中に輻輳公開機能をネゴシエートした後、各エンドポイントは、コネクションの半分に対するＣＥイベントを記録するためのローカルな３ビットのカウンタを維持管理する。センダにおけるカウンタはローカルカウンタと呼ばれる一方、レシーバにおけるカウンタはリモートカウンタと呼ばれる。この方式は、コネクションの他方の半分に対して対称的である。輻輳中、レシーバにおけるローカルカウンタが各ＣＥパケット到着ごとにインクリメントされる。受信側ホストは、そのトランスポートサポートを通じて、ちょうど次の確認応答時にリモートセンダを更新する。それぞれの到着する確認応答に対して、センダは、そのローカルカウンタ値を新しい値と比較し、その差を記録する。その差は、ユーザがネットワークへのトラフィックに対して有するデビット（debit, 負債）（塗りつぶした矩形で示す輻輳応答パケット１２０）である。

輻輳公開において、変化する経路（ネットワーク）条件に適応するのはトランスポートプロトコルインスタンスの責任である。輻輳公開は任意のトランスポートプロトコルとともに機能するはずなので、経路適応のメカニズムは、エンドポイントで実装されるいかなる輻輳制御メカニズムとも直交する。

さらに、応答調整のため、トランスポートプロトコルインスタンスは、到着する確認応答から次の２つのパラメータを推定する。
・経路輻輳推定
・輻輳が静的でなくなってから（すなわち動的に変化してから）の応答における誤り訂正

最初に、輻輳推定および誤り訂正は両方とも送信側ホストにとって未知であるので、フィードバック状態は最新でないと安全に述べることができる。非最新状態において、センダは、逆方向チャネル上で確認応答を受信し始めるまで、順方向経路においてプレクレジット（pre-credit, 前払い入金）を使用する。それぞれの確認応答は、レシーバが記録している輻輳情報を伝達する。また、例えばｎ個の確認応答を受信した後、経路状態に関する十分な知識が得られたということができる。

ＴＣＰのようなウィンドウ方式のトランスポートの場合、ｎ＝１は上記の一般化の特殊な場合であり、状態遷移は最初に到着する確認応答で行われてもよい。ＴＣＰは「ａｃｋ」駆動型であるので、経路状態は、すでに受信した確認応答から追跡することができ、その推定に基づいて、それに応じて誤り訂正を適用することができる。誤り訂正の動機は２つある。第１に、必ずしも輻輳と相殺しない順方向およびフィードバックチャネルと、出口における応答パケットとの間に差がある。さらに、経路輻輳は、最後のラウンドトリップ時間（round trip time, ＲＴＴ）で記録された通りに静的ではない。したがって、センダにおける推定は、その中に何らかの誤りを有する。それぞれの送信動作ごとに、センダは、観測された経路輻輳の推定値を有し、その推定値に基づいて、さらに、それらのパケットの確認応答が到着するときにどの程度の輻輳が予想されるかを推定する。応答パケットは、ＣＥパケットと一対一対応で送信される。輻輳ウィンドウおよびすでに発行されたポストクレジット（post-credit, 後払い入金）を追跡することにより、センダは、ネットワーク出口における監査機能を安全に通過するのに十分な順方向経路における残高を有することを保証する。

非特許文献３によれば、所定期間（ｔ≧１ｓｅｃ）の間無活動の場合、センダにおけるフィードバック情報が破棄されるべきこともプロトコル設計者によって推奨されている。これは、コネクションをフィードバック非最新状態にする遷移としても表現される。

与えられた経路上において、輻輳宣言コントローラの主要な機能は、ある特定の経路特性を有する与えられた経路上のユーザ送信レートを適応（増減）させながら、送出トラフィックに対する輻輳公開コードポイント（プレクレジット、ポストクレジット）をインテリジェントに設定することである。

トランスポートレベル（例えばＴＣＰ）で、ネットワークにおいて確認応答のないパケットの最大数は、実行中の任意の時刻における輻輳ウィンドウサイズによって決定される。最初に、センダは、最小の輻輳ウィンドウサイズ（例えば１）から開始し、それぞれの到着する確認応答とともにその送信レートをゆっくりと（スロースタートで）上昇させる（ウィンドウサイズを大きくする）（ウィンドウサイズの増大は、使用されるＴＣＰの種類に依存する）。平均として、スロースタート段階の後、輻輳ウィンドウを各ＲＴＴ後に１だけ増大させる。いずれのストラテジでも、機能エンティティを安全に通過するため、いずれのＴＣＰ上昇段階においてもこのコードポイント数をインテリジェントに設定することで、出口における不足がプレクレジットパケットとポストクレジットパケットとの和よりも小さくなるようにする。

モビリティ（例えば図２に示すようなハンドオーバー）の導入により、経路適応に注目する代わりに、経路変更に関連する問題が、特に輻輳ウィンドウサイズが大きくなった場合に解決されなければならない。図２は、モバイルノードＵＥ／ＭＮとして機能するユーザ機器を示している。モバイルノードＵＥ／ＭＮは、アクセスポイントＡＰ経由で、相手ノードＵＥ／ＣＮとして機能する別のユーザ機器と通信する。特にシームレスなモビリティの場合、ユーザは、新たな経路上で予想される輻輳のレベルについて事前に知識を有しない。経路適応は、ユーザが新たな経路を通じて実際に送信したデータパケットの確認応答を受信した後に初めて起こり得る。このような新たに到着する確認応答は、新たに追加されたトラフィックバーストによって導入される、提供される負荷における変化による経路ビューを伝達する。課題は、アタッチメントポイントにおける変更が生じた後に起こる次のトラフィックバーストに対して、例えば輻輳を通知するために、どのようにパケットコードポイントを設定するかである。

具体的には、図２に例示するようなモビリティイベントにおけるエンドポイントに対して、以下の問題点が解決されなければならない。
・新たな経路の状態（輻輳、負荷等）が確実にはわからない
・予想される輻輳レベルについてどのようにして妥当な推定をするか？
・経路がどのくらい実際に変更されているかの推定（例えば３ＧＰＰにおいて状況に依存）
・伝送中のパケットおよび確認応答のためフィードバックループはやや不確実である
・確認応答が新旧いずれの経路をたどったかわからないので、新たに到着するフィードバックは最新でない（信頼できない）可能性がある
・シームレスなモビリティの場合、現在のウィンドウサイズに依存する次のパケットに対するコードポイントの選択
・ハンドオーバー時間の長さはアイドル時間イベントよりも大きくなるべきでないので、センダはハンドオーバー時間の長さも考慮しなければならない

図３は、本発明による方法の適用場面を例示する模式図である。モバイルノードＵＥ／ＭＮが、旧アクセスポイントＯ−ＡＰから新アタッチメントポイント（すなわち新アクセスポイント）Ｎ−ＡＰに移動する。新アクセスポイントＮ−ＡＰにおいて、モバイルノードＵＥ／ＭＮに対する経路の残部は不変であり、予測係数は、旧アクセスポイントＯ−ＡＰと新アクセスポイントＮ−ＡＰのマーキングレートの差のみである。この情報は、２つのアクセスポイント間で、例えばＬＴＥの場合にはＸ２インタフェースを通じて交換されることが可能であり、ハンドオーバー手続き中に、新アクセスポイントＮ−ＡＰはこの情報をモバイルノードＵＥ／ＭＮにとって利用可能とする。こうして、ハンドオーバーイベントの際に経路輻輳予測係数が計算されて、モバイルノードＵＥ／ＭＮに渡される。

図４は、本発明による方法の別の適用場面を例示する模式図である。

事業者ドメイン内の可能な経路は制限される。実際の物理経路を細かい粒度で見る代わりに、データパケットにおいて利用可能な輻輳情報を活用し、輻輳情報は、トラフィックのいずれかの方向に対する事業者ドメイン内の経路上の関連するネットワーク要素に基づいて集約される。

ヒント計算メカニズムを個別のネットワーク要素間で独立させることにより、経路上のノード間のローカル輻輳ビューが構成される。したがって、事業者ドメイン内の経路は、新たな経路上の予想される輻輳を予測するために多重化され、これらの経路の各セットに沿ったローカル輻輳が集約されて、グローバル輻輳ビューというヒントが構成される。

図４は、グローバル輻輳ビューを必要とする可能性のある場面を示している。ｅノードＢ間ハンドオーバーおよびＳＧＷ（Serving Gateway, サービングゲートウェイ）間ハンドオーバーの、２つのハンドオーバーの場合が示されている。ｅノードＢ間の場合は簡単である。というのは、輻輳における差はローカルビューを通じて（例えば、ｅノードＢ上のマーキングレート間の差を通じて）捕捉できるからである。

しかし、ＳＧＷ間の場合、新たな（変更された）経路上の輻輳に対する予測係数を計算するためには、ネットワークはＳ−ＧＷ−１とＰ−ＧＷ−０（Packet Data Network Gateway, パケットデータネットワークゲートウェイ）との間で生じている輻輳の情報を組み合わせなければならない。これらの情報を組み合わせる動機は、Ｓ−ＧＷ−１からＰ−ＧＷ−０への輻輳がアタッチメントポイントにおいて確実にはわからないという理由による。

輻輳公開において、輻輳は経路に沿ったすべてのリソース（ボトルネック）にわたる累積的なマーキングレートを意味する。単純なアプローチとしては、通信しているエンドポイント間の一部または全体の経路に沿った割合（％）として輻輳を表現することが挙げられる。その場合、経路の一部に沿った割合どうしを組み合わせて、経路全体に対するトラフィックを予測する際の輻輳のグローバルビューを構成してもよい。

予測の精度は、事業者ドメイン内のさまざまなネットワーク要素間で情報が交換される時間スケール等の因子に依存し得る。あるいは精度は、マーキング率の統計的変化等に基づいて推論されることも可能である。しかし、計算されたネットワーク生成ヒントの精度がネットワーク生成ヒント自体とともに通知され、このヒントにどのように対処するか、および、このヒントをどの程度重大なものとして考慮するかをヒントの受信側に決定させることも考えられる。

ヒントの通信はさまざまな方法で行うことができる。可能な例として、ｅノードＢ上のエアインタフェースからモバイルノードインタフェースへの輻輳の情報の交換が挙げられる。他の例として、ＩＣＭＰ制御メッセージをモビリティ管理シグナリング（モバイルＩＰまたは３ＧＰＰモビリティシグナリングプロトコル）等のシグナリングメッセージにピギーバックすることが挙げられる。

上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。

Claims (16)

1. 輻輳公開対応ネットワークで輻輳管理をサポートする方法において、
   送信側ホストおよび受信側ホストが、中間ルータ経由のネットワーク経路を通じてパケットのフローを送信することにより相互に通信し、中間ルータは、輻輳を検出すると、輻輳情報を含めることにより、前記フローのパケットを輻輳パケットとしてマーキングし、
   輻輳は、輻輳フィードバックメカニズムによって送信側ホストに通知され、
   送信側ホストは、輻輳通知を受信すると、現在の輻輳応答パケットの量が通知された輻輳レベルと一致しているか否かに応じて、輻輳情報を含めることにより、送信するパケットの一部を輻輳応答パケットとして宣言し、
   前記送信側ホストと前記受信側ホストとの間の前記ネットワーク経路を通じて送信されるパケットに含まれる輻輳情報に基づいて集約輻輳が求められ、
   新たな経路上で予想される輻輳レベルに関する経路輻輳予測が、前記集約輻輳から導出され、
   前記経路輻輳予測を含むネットワーク生成ヒントが提供され、
   前記ネットワーク生成ヒントが、ネットワーク要素および／またはエンドホストに配信され、
   前記ネットワーク生成ヒントが、モビリティイベントにおいて、すなわちハンドオーバーイベントの際に、前記エンドホストを支援するために使用される
   ことを特徴とする、輻輳公開対応ネットワークで輻輳管理をサポートする方法。
2. 前記集約輻輳が、特にダウンリンク方向において、輻輳マーキングパケットの割合を計算することによって求められることを特徴とする請求項１に記載の方法。
3. 前記集約輻輳が、特にダウンリンク方向において、所定期間にわたり輻輳マーキングパケットの数を合計することによって求められることを特徴とする請求項１または２に記載の方法。
4. 前記輻輳情報が、Ｒｅ−ＥＣＮ固有のマーキングを含むことを特徴とする請求項１ないし３のいずれか１項に記載の方法。
5. 前記経路輻輳予測が、経路輻輳予測係数を計算することによって、前記集約輻輳から導出されることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
6. 前記ネットワーク生成ヒントが、ハンドオーバーイベントの期間中に、前記エンドホストを支援するために使用されることを特徴とする請求項１に記載の方法。
7. 前記ネットワーク生成ヒントが、前記エンドホストにおける輻輳応答パケットの量を調整するために使用されることを特徴とする請求項１または６に記載の方法。
8. 前記ネットワーク生成ヒントが、モビリティ管理決定に影響を与えるために、モビリティ管理エンティティに配信されることを特徴とする請求項１、６および７のいずれか１項に記載の方法。
9. 前記ネットワーク生成ヒントの計算が、経路上の一部のノード間の輻輳を示すローカル輻輳ビューを構成するために、個別のネットワーク要素間で独立していることを特徴とする請求項１、６ないし８のいずれか１項に記載の方法。
10. 前記ローカル輻輳ビューが割合として表現されることを特徴とする請求項９に記載の方法。
11. 経路全体に対する輻輳を予測するために、前記経路に沿った一部に対するローカル輻輳ビューを組み合わせてグローバル輻輳ビューを生成することを特徴とする請求項９または１０に記載の方法。
12. 前記ネットワーク生成ヒントの計算に関する精度情報が前記ヒントとともに通知されることを特徴とする請求項１、６ないし１１のいずれか１項に記載の方法。
13. 前記ネットワーク生成ヒントの通信が、ネットワーク要素、例えばｅノードＢ、のエアインタフェースに関する前記ヒントをホスト、例えばモバイルノード、のインタフェースと交換することによって実行されることを特徴とする請求項１、６ないし１２のいずれか１項に記載の方法。
14. 前記ネットワーク生成ヒントの通信が、ＩＣＭＰ制御メッセージを使用することによって実行されることを特徴とする請求項１、６ないし１３のいずれか１項に記載の方法。
15. 輻輳公開対応ネットワークシステムにおいて、該システムは、送信側ホスト、受信側ホストおよび中間ルータを備え、
    前記送信側ホストおよび前記受信側ホストが、前記中間ルータ経由のネットワーク経路を通じてパケットのフローを送信することにより相互に通信し、前記中間ルータは、輻輳を検出すると、輻輳情報を含めることにより、前記フローのパケットを輻輳パケットとしてマーキングし、
    送信側ホストに輻輳を通知するように構成された輻輳フィードバックメカニズムが設けられ、
    送信側ホストは、輻輳通知を受信すると、現在の輻輳応答パケットの量が通知された輻輳レベルと一致しているか否かに応じて、輻輳情報を含めることにより、送信するパケットの一部を輻輳応答パケットとして宣言し、
    該ネットワークシステムが、前記送信側ホストと前記受信側ホストとの間の前記ネットワーク経路を通じて送信されるパケットに含まれる輻輳情報に基づいて集約輻輳を求めるようにさらに構成され、
    新たな経路上で予想される輻輳レベルに関する経路輻輳予測が、前記集約輻輳から導出され、
    前記経路輻輳予測を含むネットワーク生成ヒントが提供され、
    前記ネットワーク生成ヒントが、ネットワーク要素および／またはエンドホストに配信され、
    前記ネットワーク生成ヒントが、モビリティイベントにおいて、すなわちハンドオーバーイベントの際に、前記エンドホストを支援するために使用される
    ことを特徴とする、輻輳公開対応ネットワークシステム。
16. 輻輳公開対応ネットワークで用いられる中間ルータにおいて、
    送信側ホストおよび受信側ホストが、前記中間ルータ経由のネットワーク経路を通じてパケットのフローを送信することにより相互に通信し、
    前記中間ルータは、輻輳を検出すると、輻輳情報を含めることにより、前記フローのパケットを輻輳パケットとしてマーキングするように構成され、
    送信側ホストに輻輳を通知するように構成された輻輳フィードバックメカニズムが設けられ、
    送信側ホストは、輻輳通知を受信すると、現在の輻輳応答パケットの量が通知された輻輳レベルと一致しているか否かに応じて、輻輳情報を含めることにより、送信するパケットの一部を輻輳応答パケットとして宣言し、
    該中間ルータが、前記送信側ホストと前記受信側ホストとの間で該中間ルータ経由の前記ネットワーク経路を通じて送信されるパケットに含まれる輻輳情報に基づいて集約輻輳を求めるようにさらに構成され、
    新たな経路上で予想される輻輳レベルに関する経路輻輳予測が、前記集約輻輳から導出され、
    前記経路輻輳予測を含むネットワーク生成ヒントが提供され、
    前記ネットワーク生成ヒントが、ネットワーク要素および／またはエンドホストに配信され、
    前記ネットワーク生成ヒントが、モビリティイベントにおいて、すなわちハンドオーバーイベントの際に、前記エンドホストを支援するために使用される
    ことを特徴とする中間ルータ。
    

Images