JP5753318B2 - プロービングに基づくベアラ制御 - Google Patents

Description

本発明はデータトラフィックを制御する方法とその対応する機器に関する。

通信ネットワークにおいて、ネットワークトラフィックの差別化された扱いが用いられて、ネットワークトラフィックのタイプに依存するサービス品質（ＱｏＳ）に関する要求を満たすことができる。このため、データパケットの転送処理、即ち、ノードによるデータパケットを転送する方法は、調整され所望のＱｏＳを得るために、或いは、一定のタイプのトラフィックを他のものに対して優先処理するために調整される。

例えば、移動体通信ネットワークにおいて、特定のサービスに関係したネットワークトラフィックは一定のＱｏＳレベルを提供するベアラへと導くものであるかもしれない。この点に関して、ベアラは、例えば、キャパシティと遅延とビットエラー率との内の少なくともいずれかのような規定された特性の情報送信環境又は経路であると考えられる。移動体通信ネットワークのゲートウェイと、例えば、移動体電話又は他のタイプの移動体端末のようなユーザ機器（ＵＥ）との間で数多くのベアラを確立することが可能である。ベアラはネットワークからユーザ機器への方向のダウンリンク（ＤＬ）データトラフィックを搬送することができるし、ユーザ機器からネットワークへのアップリンク（ＵＬ）方向のデータトラフィックを搬送することができる。そのゲートウェイとＵＥとにおいて、複数のＩＰデータパケットを含むデータトラフィックは、例えば、ＩＰ ５テュープル（５-tuple）パケットフィルタを用いてフィルタされ、これによりＩＰデータパケットを所望のベアラへと進めることができる（ＩＰ“インターネットプロトコル”はＩＰｖ４としても言及されるＩＰバージョン４でも良いし、或いは、ＩＰｖ６としても言及されるＩＰバージョン６でも良い）。

しかしながら、一定のタイプのデータトラフィックを対応するベアラへと導くことにより差別化された扱いを実行するとき、利用可能な資源が最善の方法で用いられない状況が生じるかもしれない。例えば、優先されるデータトラフィックが優先ベアラに割当てられるが、この優先ベアラを用いることが実際には、ＵＥにおける所望の実体験の質（ＱｏＥ）を達成するのには必ずしも必要ではない状況があるかもしれない。例えば、ネットワークが低負荷であるなら、そのような場合であるかもしれない。

従って、データトラフィックの差別化された扱いを実行するときに、資源の効率的な利用を可能とする技術の必要がある。

本発明の実施例によれば、データトラフィックを制御する方法が備えられる。その方法によれば、ユーザ機器に関して確立されたベアラを介して、少なくとも１つのプローブパケットが送信される。それから、前記プローブパケットに応じて返された少なくとも１つの応答パケットが受信され、前記プローブパケットの送信と前記応答パケットの受信との間の時間に対応するパラメータが測定される。その測定されたパラメータに基づいて、前記ユーザ機器に関するベアラ制御手順が開始される。

本発明の別の実施例によれば機器が備えられる。その機器には、パケットインタフェース、メモリ、及び、プロセッサが備えられる。そのパケットインタフェースは、ユーザ機器に関して確立されたベアラを介して、少なくとも１つのプローブパケットを送信し、前記プローブパケットに応じて返された少なくとも１つの応答パケットを受信するよう構成される。そのプロセッサは、前記プローブパケットの送信と前記応答パケットの受信との間の時間に対応するパラメータを測定し、その測定されたパラメータに基づいて、前記ユーザ機器に関するベアラ制御手順を開始するよう構成される。

本発明のさらに別の実施例によれば、上記の方法を実施する他の方法、機器、或いは、コンピュータプログラムが備えられる。

本発明の実施例に従う概念が実現される通信システムを模式的に示す図である。 図１の通信システムに本発明の実施例に従う概念を実施することを模式的に示す図である。 本発明の実施例に従いプロービングに基づくベアラ制御を模式的に示すシグナリングの図である。 本発明の実施例に従う概念がコンテンツブースターアーキテクチュアにおいて適用される通信ネットワーク環境を示す図である。 本発明の実施例に従う機器を模式的に示す図である。 本発明の実施例に従う方法を示すフローチャートである。

次に、代表的な実施例と添付図面とを参照して本発明について詳細に説明する。例示された実施例はネットワークトラフィック処理の概念に関するものである。図１に例示されているように、その概念は３ＧＰＰ（第３世代パートナーシッププロジェクト）技術仕様（ＴＳ）に従う移動体通信ネットワークにおいて適用される。しかしながら、この例示された概念は、例えば、ＤＳＬのような固定アクセス技術、ファイバー光アクセス、或いは、同軸ケーブルアクセスを用いた他のタイプの通信ネットワークにおいても同様に適用できることを理解されたい。

図１は、本発明の実施例に従う概念が適用される通信ネットワーク環境を模式的に図示している。

その通信ネットワーク環境は、端末としても言及されるＵＥ１０と、複数のネットワーク構成要素２２、２４、２６、３０とを含む。これらのネットワーク構成要素の間には、無線アクセスネットワーク（ＲＡＮ）２２がある。ＲＡＮは、例えば、ＧＳＭ（登録商標：移動体通信用グローバルシステム）、ＥＤＧＥ（発展型ＧＳＭ用改良データ速度）、ＵＭＴＳ（全球規模移動体通信システム）、ＨＳＰＡ（高速パケットアクセス）、或いは、ＬＴＥ（ロングタームエボルーション）のようなある種のタイプの、又は、ある複数種のタイプの無線アクセス技術に基づいている。ＲＡＮ２２は単一のノードとして図示されているが、ＲＡＮ２２は実際には複数の構成要素から形成されても良いが、ここではさらに説明はしない。ＲＡＮ２２はトランスポートノード２４に接続され、それはゲートウェイ（ＧＷ）２６に接続される。ここで、２つ以上のトランスポートノード２４が代わりにＲＡＮ２２とゲートウェイ２６との間に接続されても良いし、或いは、ＲＡＮが直接ゲートウェイ２６に接続されても良いことを理解されたい。ゲートウェイ２６は、ＧＰＲＳベースのサービスの接続を１つ以上の外部パケットデータネットワークに提供するゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）であっても良い。また、ゲートウェイ２６は、３ＧＰＰ ＴＳに従うシステムアーキテクチュアエボルーション ゲートウェイ（ＳＡＥ ＧＷ）であっても良い。

さらに、移動体通信ネットワークは、３ＧＰＰ ＴＳに従うポリシー課金ルール機能（ＰＣＲＦ）として実装されるポリシーコントローラ３０を含む。ポリシーコントローラ３０は、専用ハードウェアによって実現されることと、或いは、プロセッサによって実行されるソフトウェア機能を含むことの内の少なくともいずれかで良い。ゲートウェイ２６とポリシーコントローラ３０とは通常、コアネットワークの構成要素としてみなされる。ポリシーコントローラ３０はシグナリング経路６を介してゲートウェイ２６と通信する。シグナリング経路６は、３ＧＰＰ ＴＳに従うＧｘインタフェースを用いて実装されても良い。ポリシーコントローラ３０はさらに、加入者データベース３２とサービスポリシーデータベース３４とに、例えば、３ＧＰＰ ＴＳに従うＳｐインタフェースを用いて実装されるシグナリング経路８を介して接続されると良い。従って、ポリシーコントローラ３０は、例えば、移動体ＴＶ又はコンテンツ配信のような、移動体通信ネットワークにおいて利用可能な、特定のユーザに関係するか、或いは、特定のサービスに関係するかの内の少なくともいずれかであるポリシーデータを受信することができる。

他の機能の中でも特に、ポリシーコントローラ３０は、フィルタ生成器３５を含むと良い。フィルタ生成器３５は、加入者データベース３２からの加入者データとサービスポリシーデータベース３４からのサービスポリシーとに基づいて達成されても良く、ＵＥ１０と、ゲートウェイ２６とにおいて使用されるパケットフィルタを特定するように適合される。

さらに図示されているように、ネットワークとユーザ機器１０との間のデータトラフィックは複数のベアラ５２、５４によって搬送される。データトラフィックは通常、ＵＥ１０で実行する１つ以上のクライアント／ピアアプリケーション１２に関係する。例えば、それは一定のサービスに関係するかもしれない。図示されているように、データトラフィックはＵＥ１０と種々のネットワークリソース８０、図示された例では、第１のネットワークリソース（ＮＲ１）、第２のネットワークリソース（ＮＲ２）、第３のネットワークリソース（ＮＲ３）との間で通信される。図示された例では、ＵＥ１０と第１のネットワークリソースＮＲ１との間で通信されるデータトラフィックとＵＥ１０と第２のネットワークリソースＮＲ２との間で通信されるデータトラフィックとはベアラ５２により搬送される。ＵＥ１０と第３のネットワークリソースＮＲ３との間で通信されるデータトラフィックはベアラ５４により搬送される。従って、選択されたデータトラフィックはベアラ５２、５４の内の１つに導かれる。

ベアラ５２、５４は、ユーザ機器１０とゲートウェイ２６との間で確立される。ベアラ５２、５４は、ＤＬ方向とＵＬ方向の両方でデータトラフィックを搬送する。即ち、これらはまた、ＤＬベアラとＵＬベアラとで形成されるものとみなされる。ベアラ５２、５４で双方向通信をサポートするために、ＵＥ１０には対応するインタフェース１５が備えられ、これによりベアラ５２、５４から到来するデータパケットを受信し、ベアラ５２、５４で発信するデータパケットを送信することを可能にする。同様に、ゲートウェイ２６には対応するインタフェース２５が備えられ、これによりベアラ５２、５４から到来するデータパケットを受信し、ベアラ５２、５４で発信するデータパケットを送信することを可能にする。

ベアラ５２、５４は、一般的にはパケットベースのサービスをユーザ機器１０に提供するために確立されたデフォルトベアラ５２を、オプション的には、異なるＱｏＳレベル、例えば、デフォルトベアラよりも高いか、或いは、低いＱｏＳレベルをもつ１つ以上の専用ベアラ５４を含むことができる。ＵＥ１０がゲートウェイ２６にアタッチするときには、デフォルトベアラ５２が通常、確立される。例えば、一定のＱｏＳレベルを要求する選択されたデータトラフィックのデータパケットが送信される必要があるときには、専用ベアラがオンデマンドで確立されても良い。

各ベアラ５２、５４は対応するＱｏＳプロファイルに関係づけられる。ＱｏＳプロファイルは、ＱｏＳクラス識別子（ＱＣＩ）と、アロケーション／リテンション優先度（ＡＲＰ）と、トラフィックハンドリング優先度（ＴＨＰ）と、最大ビット速度（ＭＢＲ）と、総最大ビット速度（ＡＭＢＲ）と、保証ビット速度（ＧＢＲ）との内、少なくともいずれかのようなＱｏＳパラメータを通して定義される。従って、一定のＱｏＳレベルが、データパケットを対応するベアラに関係づけすることにより、ＵＥ１０とゲートウェイ２６との間でデータパケットを通信するために備えらえる。加えて、そのデータパケットを通信するために備えられたＱｏＳレベルはまた、例えば、デフォルトベアラ５２のような現存するベアラを修正することにより適合されても良い。通常、専用ベアラは複数のＱｏＳパラメータの内の少なくとも１つにおいてデフォルトベアラ５２とは異なるであろう。

ＵＥ１０では、データパケットが、対応して構成されたＵＬパケットフィルタ６２、６４を用いて所望のベアラ５２、５４に導かれる。ゲートウェイ２６では、データパケットが、対応して構成されたＤＬパケットフィルタ７２、７４を用いて所望のベアラ５２、５４に導かれる。ＱｏＳプロファイルのパラメータはポリシーコントローラ３０からゲートウェイ２６へシグナリング経路６を介してシグナリングされる。同様に、ゲートウェイ２６において用いられるＤＬパケットフィルタ７２、７４は、ポリシーコントローラ３０からゲートウェイ２６へシグナリング経路６を介してシグナリングされる。ＵＥ１０において用いられるＵＬパケットフィルタ６２、６４に関しては、これらはゲートウェイ２６を介してポリシーコントローラ３０からＵＥ１０にシグナリングされる。

次に、あるタイプのデータパケットに関し、即ち、選択されたデータトラフィックに対する所望のレベルのＱｏＳを提供する一方、リソースの効率的な使用を可能にする、本発明の実施例に従う概念について説明する。これらの概念は、ＵＥ１０に関して確立された１つ以上のベアラをプローブすることに基づいている。即ち、次の説明にはデフォルトベアラ５２と専用ベアラ５４とをプローブすることが関係している。しかしながら、例えば、２つの異なる専用ベアラのような複数のベアラの他の組み合わせや、デフォルトベアラやある特定の専用ベアラだけのような単一のベアラだけが、次に説明するようにプローブが行われても良い。

説明したように、専用ベアラ５４は選択されたデータトラフィックをＵＥ１０へ搬送したり、ＵＥ１０から搬送するために確立される。選択されたデータトラフィックは、例えば、より高いレベルのＱｏＳが求められる優先的なコンテンツやプレミアムコンテンツを含むかもしれない。このようにして、ＵＥ１０のユーザには、選択されたデータトラフィック、例えば、コンテンツデータネットワーク（ＣＤＮ）からのコンテンツ配信に基づいたサービスを用いるとき、改善されたＱｏＳが提供され、図１に図示されているように、ネットワークリソース８０が例として与えられている。

ある状況では、例えば、ネットワークにおいて負荷が低いなら、選択されたデータトラフィックに対してデフォルトベアラ５２を用いるのと比較してＱｏＥにおける改善はユーザによって気付かないものであるかもしれない。そのような状況では、それ故に、専用ベアラ５４を確立することは、例えば、無線バンド幅、ネットワークにおけるシグナリング、信号やデータの処理、ＵＥ１０の電池寿命などのリソースを不必要に用いてしまう結果となるかもしれない。例えば、ＵＥ１０がそのセルでただ１つであるなら、即ち、ＲＡＮ２２が他のＵＥではなくＵＥ１０だけにサービスを提供しているなら、優先順位を付けなければならない他のデータトラフィックはないかもしれない。そのようなリソースの不必要な使用は望ましいことではない。

従って、ここで説明するような概念には、ベアラ５２、５４の少なくとも１つをプローブすることが関係する。このように、所望のＱｏＥを依然として提供する間にではなく、デフォルトベアラ５２が選択されたデータトラフィックを搬送するために用いられても良いかどうかを判断する。より具体的には、そのプローブには、プローブされるベアラを介して少なくとも１つのプローブパケットを送信することと、そのプローブパケットに応じて返される少なくとも１つの応答パケットを受信することとを含む。その応答パケットはプローブされるベアラを介して同様に受信されても良い。例えば、そのプローブパケットはプローブされるベアラのＤＬ部分を介してＵＥ１０に送信され、その応答パケットはプローブされるベアラのＵＬ部分を介してＵＥ１０から送信される。それから、プローブパケットの送信と応答パケットの受信との間の時間に対応するパラメータが測定される。このパラメータはプローブされるベアラで送信されるとき選択されたデータトラフィックが経験する遅延を表わす。例えば、このパラメータは往復時間（ラウンドトリップタイム：ＲＴＴ）として測定される。

測定されたパラメータに基づいて、例えば、専用ベアラ５４を確立し、専用ベアラ５４を解放し、データパケットをベアラ５２、５４の１つへ、或いは、ベアラ５２、５４の１つからデータパケットを導き、或いは、１つ以上のベアラ５２、５４の少なくとも１つのＱｏＳパラメータを修正し、例えば、専用ベアラ５４の質を低下させたり、或いは、デフォルトベアラ５２の質を向上させることなどのベアラ制御手順が開始される。例えば、デフォルトベアラ５２がプローブされ、パラメータがデフォルトベアラ５２で選択されたデータトラフィックにより経験する遅延が輻輳が生じていないネットワークで経験する遅延に相当することを示すなら、優先順位付けは必要とはされず、専用ベアラ５４は解放されても良い。専用ベアラ５４はまた、１つ以上のＱｏＳパラメータを修正することによりその質を低下させて、例えば、ベストエフォートベアラに対応するようにしても良い。そのとき、選択されたトラフィックは専用ベアラ５４により配信されても良い。もし、専用ベアラ５４がまだ確立されていないなら、専用ベアラ５４を確立することを留め、むしろ、選択されたトラフィックを搬送するためにデフォルトベアラ５２を用いるように決定しても良い。もし、そのパラメータがデフォルトベアラ５２で選択されたデータトラフィックが経験する遅延がほとんど輻輳が生じていないネットワークにおいて経験する遅延に相当することを示すなら、デフォルトベアラ５２の質を向上させても良い。

パラメータは、例えば、ベアラ５２、５４のいずれか１つで選択されたデータトラフィックの進行中の通信がある限り、繰り返し測定されると良い。もし、そのような繰り返される測定が、例えば、ネットワークにおける負荷増加のために遅延が増すことを示唆するなら、以前に解放された専用ベアラ５４を再確立したり、以前に品質を低下させた専用ベアラ５４の質を向上させると良い。

上記のベアラ制御処理は、１つのベアラから別のベアラへ選択されたデータをリダイレクトすることが関係しており、それは１つ以上のパケットフィルタ６２、６４、７２、７４を適合させることにより達成される。特に、選択されたデータトラフィックは、もしプローブがこのベアラが依然として所望のＱｏＳを得るのに適切であることを示すなら、より低いＱｏＳレベルをもつベアラへとリダイレクトされても良い。

本発明の実施例に従う上記プロービングの概念を実施することはさらに図２において図示されている。即ち、図２は、ネットワークノード１００とＵＥ１０とＲＡＮ２２とＧＷ２６とポリシーコントローラ３０との間での相互作用を示している。トランスポートノード２４は図示されていないが、同様に存在しても良い。図２において、プロービングはネットワークノード１００、例えば、ユーザへのコンテンツ配信を制御するネットワークノードにより実行される。図示のように、そのネットワークノードは、遅延モニタ１１０とパケットインタフェース１３０とを含む。さらに、ネットワークノード１００はまた、ポリシーコントローラ３０へのシグナリング経路５に関するインタフェースも含む。シグナリング経路５は、３ＧＰＰ ＴＳに従うＲｘインタフェースを用いて実装されると良い。

図２のシナリオでは、優先的な、さもなければ、差別化された扱いを要求する選択されたデータトラフィックの送信はＵＥ１０に関して専用ベアラ５４を確立することを既にトリガしているか、或いは、専用ベアラ５４が既に別の理由のために確立されており、そして、選択されたデータトラフィックが通常は専用ベアラ５４により搬送されることを仮定している。さらに、デフォルトベアラ５２もＵＥ１０に関して確立されている。この状況で、ネットワークノード１００の遅延モニタ１１０はパケットインタフェース１３０を用いて、ＵＥ１０に対してデフォルトベアラ５２でプローブパケットを定期的に送信する。プローブパケットを受信することに応じて、ＵＥ１０はネットワークノード１００に応答パケットを送信する。即ち、各プローブパケットは対応する応答パケットのトリガを与える。例えば、プローブパケットは、ピンパケットとしても言及されるインターネット制御メッセージプロトコル（ＩＣＭＰ）のエコー要求パケットであることが可能であり、それは、ネットワークノード１００により、例えば、ＵＥ１０のＩＰアドレスのようなネットワークアドレスに向かって送信され、ＵＥ１０にネットワークノード１００に対してＩＣＭＰエコー応答パケットを返信することにより応答を行わせる。しかしながら、他のタイプのプローブパケットが用いられても良い。例えば、データパケットの受信が、送信制御プロトコル（ＴＣＰ）の受信確認パケットのような応答パケットの送信のトリガとなることを仮定するなら、選択されたデータトラフィックのデータパケット、又は、他のデータトラフィックのデータパケット、例えば、優先的ではないデータトラフィックをプローブパケットとして用いることも可能であろう。今述べたことの可能性は、例えば、選択されたデータトラフィックがネットワークノード１００を通ってルーティングされるなら、使用できるかもしれない。例えば、今述べたことの可能性は。選択されたデータトラフィックがネットワークノード１００を通ってルーティングされるなら、使用できるかもしれない。

応答パケットはパケットインタフェース１３０を介して受信され、プローブパケットの送信と対応する応答パケットの受信との間の時間、例えば、ＲＴＴに対応するパラメータを測定する遅延モニタ１１０により検出される。その測定パラメータに基づいて、ネットワークノード１００はベアラ制御手順を開始することができる。例えば、デフォルトベアラ５２で測定されたパラメータが所定数の連続測定の間、閾値未満であるなら、専用ベアラ５４は解放され、選択されたデータトラフィックはデフォルトベアラ５２へと導かれると良い。もし、パラメータがＲＴＴとして測定されるなら、その閾値は負荷のないネットワークにおける典型的なＲＴＴに対応し、オプション的には、典型的なＲＴＴを決定する際の不確実性を考慮に入れるために、例えば、それに一定のマージンを加えたものに対応する。ベアラ制御手順を開始するかどうかに係らず、ネットワークノード１００は、選択されたデータトラフィックがデフォルトベアラ５２又は専用ベアラ５２を流れている限り、デフォルトベアラ５２のプロービングを続行すると良い。例示のシナリオでは、ネットワークノード１００はポリシーコントローラ３０へ制御信号、例えば、専用ベアラ５４を解放する要求を送信することにより、ベアラ制御手順を開始するためのシグナリング経路５を使用する。ポリシーコントローラ３０は次に、シグナリング経路６を用いて、ゲートウェイ２６へ制御信号、例えば、専用ベアラ５４を解放する命令を送信することによりベアラ制御手順を実行すると良い。

専用ベアラ５４を解放することの代替案として、ベアラ制御手順はまた、専用ベアラ５４をアクティブ状態に保ち、１つ以上のパケットフィルタ６２、６４、７２、７４を修正して選択されたデータトラフィックがデフォルトベアラ５２に導かれるようにすることに関係する。１つ以上のパケットフィルタ６２、６４、７２、７４を修正することの代替案として、所望のベアラへと導かれるようにパケットフィルタにより用いられるデータパケットにマーキングすること、例えば、差別化サービスコードポイント（ＤＳＣＰ）マーキングも修正される。

上述のベアラ制御手順は、従って、選択されたデータトラフィックがデフォルトベアラ５２により搬送されているという状況へと導くものとなる。そのような状況で、もし、デフォルトベアラ５２の品質が、例えば、負荷の増大のために低下するなら、別のベアラ制御手順を開始するための基礎としてパラメータの連続測定が用いられるかもしれない。例えば、デフォルトベアラ５２での測定パラメータが所定回数の連続測定の間、更なる閾値を越えて増加し、負荷が増加し、キューがネットワークにおいて増大していることを示すなら、ネットワークノード１００により別のベアラ制御手順が開始され、最初のベアラ制御手順以前の状況を回復するようにすることができる。この更なる閾値とは、最初のベアラ制御手順を開始するために用いられたものとを同じ閾値で良いが、制御プロセスにおけるいくつかのヒステリシスを実現するために異なる値を設定するようにもできる。従って、デフォルトベアラ５２で測定されたパラメータが、そのデフォルトベアラはもはや選択されたデータトラフィックを搬送するためには適切ではないことを示すなら、専用ベアラ５４が再確立され、選択されたデータトラフィックを搬送するために再び用いられても良いし、或いは、１つ以上のパケットフィルタ６２、６４、７２、７４或いはデータパケットのマーキングを修正することにより、その選択されたデータトラフィックがデフォルトベアラ５２から専用ベアラへとリダイレクトされても良い。

専用ベアラ５４をアクティブな状態に保つ場合には、専用ベアラ５４にも図２に示すようなプロービングが施される。この場合、遅延モニタ１１０はまた、パケットインタフェース１３０を用いて専用ベアラ５４で更なるプローブパケットをＵＥ１０に定期的に送信する。更なるプローブパケットを受信することに応じて、ＵＥ１０はネットワークノード１００に更なる応答パケットを送信する。即ち、更なるプローブパケット各々は、対応する更なる応答パケットのトリガとなる。更なる応答パケットはパケットインタフェース１３０を介して受信され、更なるプローブパケットの送信と対応する応答パケットの受信との間の時間、例えば、ＲＴＴに対応するパラメータを測定する遅延モニタ１１０により検出される。デフォルトベアラ５２と専用ベアラ５４とは従って、同時にプロービングがなされる。専用ベアラ５４で測定されるパラメータは、ベアラ制御手順を開始するための付加的な或いは代替的な基礎として用いられる。特に、デフォルトベアラ５２で測定されたパラメータは専用ベアラ５４で測定されたパラメータと比較されると良い。例えば、専用ベアラで測定されたパラメータに対するデフォルトベアラで測定されたパラメータの差が閾値、例えば、ある適切に選択された正のマージンより小さいなら、このことはデフォルトベアラ５２が選択されたデータトラフィックを搬送するのに適切であることを示し、専用ベアラ５４の代わりに用いられ、対応するベアラ制御手順を開始し、例えば、１つ以上のパケットフィルタ、例えば、１つ以上のパケットフィルタ６２、６４、７２、７４や、データパケットにおけるマーキングを上述のように修正することを関与させることにより選択されたデータトラフィックを搬送するようにできる。デフォルトベアラ５２で測定されたパラメータと専用ベアラ５４で測定されたパラメータとの差が所定の閾値より大きいなら、このことは、デフォルトベアラ５２が、例えば、輻輳のために選択されたデータトラフィックを搬送するのには適切ではないことを示し、専用ベアラ５４が用いられ選択されたデータトラフィックを搬送するようにできる。異なるベアラで測定されたそのようなパラメータの比較を用いて、絶対的な閾値の設定を行うことが回避できる。

図３は本発明の実施例に従うプロービングに基づいたベアラ制御を例示するシグナリングを示す図である。その信号図では、ＵＥ１０とＧＷ２６とポリシーコントローラ３０とネットワークノード１００とが図示されている。図１のトランスポートノード２４や図１〜図２のＲＡＮのような他のノードは図示されていないが、同様に存在するものである。

図３に図示されているように、デフォルトベアラ５２と専用ベアラ５４とは初めにステップ３０１で確立される。ここで、デフォルトベアラと専用ベアラとは同時に確立される必要はないことを理解されたい。例えば、デフォルトベアラはＵＥ１０が移動体ネットワークにアタッチしたときに確立される一方、専用ベアラはあるタイプの差別化された扱い、例えば、優先順位付けを必要とする選択されたデータトラフィックがＵＥ１０に関して通信される必要があるときに確立することができる。しかしながら、あるシナリオでは、デフォルトベアラ５２と専用ベアラ５４の両方が、ＵＥ１０が移動体ネットワークにアタッチしたときに確立されることが可能である。

それから、ネットワークノード１００は１つ以上のプローブパケットをデフォルトベアラ５２を介してＵＥ１０に送信する。そのようなプローブパケット３０２の受信時、ＵＥ１０は対応する応答パケット３０３をネットワークノード１００に返す。上述のように、プローブパケット３０２は、例えば、ＩＣＭＰエコー要求パケット又はパケット受信者が対応する応答パケット３０３を返すようになる他のタイプのパケットでも良い。例えば、プローブパケット３０２はまた、ＴＣＰ又は受信者が確認応答パケットを返すようになる他のトランスポートプロトコルに従って送信される選択されたデータトラフィックのデータパケットでも良い。

ステップ３０４に図示されているように、それから、ネットワークノード１００はデフォルトベアラ５２のＲＴＴを測定する。ＲＴＴは実質的に、ネットワークノード１００からのプローブパケット３０２の送信とネットワークノード１００における対応する応答パケット３０３の受信との間の時間に対応している。他の実施形では、デフォルトベアラ５２での遅延を表現する他のパラメータが測定される。

加えて、ネットワークノード１００はまた１つ以上の更なるプローブパケット３０５を専用ベアラ５４を介してＵＥ１０に送信する。そのような更なるプローブパケット３０５の受信時、ＵＥ１０は対応する更なる応答パケット３０６をネットワークノード１００に返す。更なるプローブパケット３０５と更なる応答パケット３０６とは、プローブパケット３０２と応答パケット３０３と同じタイプのもので良い。

ステップ３０７により図示されているように、それからネットワーク１００は専用ベアラ５４のＲＴＴを測定する。ＲＴＴは実質的に、ネットワークノード１００からの更なるプローブパケット３０５の送信とネットワークノード１００における対応する更なる応答パケット３０６の受信との間の時間に対応している。他の実施形では、専用ベアラ５４での遅延を表現する他のパラメータが測定される。

デフォルトベアラ５２での遅延をプロービングすることと、専用ベアラ５４での遅延をプロービングすることの上記処理は図示された順番で発生する必要はないことを理解されたい。むしろ、プローブパケット３０２を送信し、対応する応答パケット３０３を受信し、デフォルトベアラ５２でＲＴＴを測定することを繰り返し行うことにより、デフォルトベアラ５２をプロービングする連続処理と、更なるプローブパケット３０５を送信し、対応する更なる応答パケット３０６を受信し、専用ベアラ５４でＲＴＴを測定することを繰り返し行うことにより、専用ベアラ５４をプロービングする連続処理とがあっても良く、これらの連続処理が並列に実行されても良い。

ステップ３０８で図示されるように、ネットワークノード１００はそれから、デフォルトベアラ５２の測定ＲＴＴと専用ベアラ５４の測定ＲＴＴとに基づいたベアラ制御手順を開始できる。特に、ネットワークノード１００は、デフォルトベアラ５２の測定ＲＴＴと専用ベアラ５４の測定ＲＴＴとを比較し、その比較に基づいて、デフォルトベアラが通常は専用ベアラ５４により搬送される選択されたデータトラフィックを搬送するのに適切であるかどうかを決定する。例えば、デフォルトベアラ５２の測定ＲＴＴと専用ベアラ５４の測定ＲＴＴとの差が一定の数の連続測定の間、一定の値より小さいなら、これはネットワークノード１００により、デフォルトベアラが選択されたデータトラフィックを搬送するのに適していることの示唆であるとして解釈される。デフォルトベアラ５２が選択されたデータトラフィックを搬送するのに適していることが分かったなら、ネットワークノードはベアラ制御手順を開始し、上述のように、例えば、１つ以上のパケットフィルタやパケットのマーキングを変更することにより、選択されたデータトラフィックがデフォルトベアラ５２に導かれるようにする。

ネットワークノード１００は制御信号３０９をポリシーコントローラ３０に送信することによりベアラ制御手順を開始する。次に、ポリシーコントローラ３０は制御信号３１０をＧＷ２６に送信することによりベアラ制御手順を実行する。更に、ベアラ制御手順はまた、ＧＷ２６からＵＥ１０への制御信号３１１のシグナリングも関係する。他の実施形では、ベアラ制御手順は異なる方法で、例えば、ネットワークノード１００からＧＷ２６への制御信号の直接シグナリングを用いて実装される。

デフォルトベアラ５２と専用ベアラ５４をプロービングすることはベアラ制御手順の後も、即ち、選択されたデータトラフィックがデフォルトベアラ５２により搬送される間にも継続されることを理解されたい。ある時点での連続プロービングがデフォルトベアラ５２がもはや選択されたデータトラフィックを搬送するのに適切ではないことを示すなら、更なるベアラ制御手順がネットワークノード１００により開始され、専用ベアラ５４に選択されたデータトラフィックを導くようにする。

図４はプロービングに基づくベアラ制御の上記概念が適用されるコンテンツブースターアーキテクチュアを備えた通信ネットワーク環境を示す。このコンテンツブースターアーキテクチュアの目的は、図１に図示されているようにネットワークリソース８０の例として挙げられている１つ以上のコンテンツプロバイダからのコンテンツ配信において改善したＱｏＥを提供することにある。図示されているように、コンテンツブースターアーキテクチュアは、移動体ブロードバンド（ＭＢＢ）運用者のインフラストラクチュア、即ち、ＵＥ４１０がアタッチするＧＷ４２０、ポリシーコントローラ４３０、ローカルドメイン名システム（ＤＮＳ）４２５、インターネットピアリングポイントＧｉＵＰを含む。このインフラストラクチュアと同じ場所にコンテンツブースターインフラストラクチュア４５０が設置される。これは、ブースティングコントローラ４６０を含む。さらに、コンテンツブースターインフラストラクチュア４５０はＣＤＮのエッジサーバ４７０とＣＤＮのキャッシュサーバ４８０との内の少なくともいずれかを含む。エッジサーバ４７０とキャッシュサーバ４８０の目的は、ローカルプロキシとローカルキャッシュとしてぞれぞれ作用させることにより、コンテンツプロバイダ（ＣＰ）サーバ５１０からＧＷ４２０へのコンテンツ配信を高速にすることにある。更に、ＭＢＢ運用者のインフラストラクチュアと設置場所を同じにすることによってもＧＷ４２０からＵＥ１０へのコンテンツ配信を高速にすることを可能にしている。

加えて、図４はまた、ＣＰ ＤＮＳ５２０、外部ＣＤＮ ＤＮＳ５６０、外部サーバ５８０、例えば、何らかのタイプのインターネットサーバを図示している。コンテンツブースターインフラストラクチュア４５０は実際には複数のＭＢＢネットワーク、複数のＣＰ、複数のＣＤＮに向かうインタフェースを有することができることを理解されたい。

一般的な用語で言えば、コンテンツブースターアーキテクチュアの思想は、ブローカーとして作用するコンテンツブースターインフラストラクチュアを用いて通信経路上のデータトラフィックに差別化した扱いを実行することである。ブローカーは一つには１つ以上のＣＰ、例えば、インターネットオークションプロバイダとのサービス合意があり、またこれに対して、各ＵＥと関係する加入者をもつ１つ以上のＭＢＢ運用者とのサービス合意がある。複数のＣＰはまた、コンテンツのホストとなり、それが異なる方法で、例えば、より高いサービス品質でユーザに送信可能とするために複数のＣＤＮプロバイダとの合意がある。ブローカーはＧＷ４２０とＵＥ４１０との間のトラフィックの優先順位を上げたり、下げたりする制御を行うことができる。このため、ブースティングコントローラ４６０はエンドユーザのコンテンツ要求メッセージを調べ、エンドユーザＤＮＳ応答を調べ、課金及びサービス合意の達成度を追跡し、優先度向上要求にトリガをかけ、或いは、優先度低下要求にトリガをかけることができる。これらの目的のため、ブースティングコントローラ４６０と一般にはコンテンツブースターアーキテクチュア４５０とは図４に描かれているようなインタフェースを有する。即ち、ブースティングコントローラ４６０は、例えば、ベアラ制御手順を開始することにより、トラフィックの優先度を上げたり、下げたりするために、ポリシーコントローラ４３０に関してインタフェースを備える。図示のように、このインタフェースは、３ＧＰＰ ＴＳに従うＲインタフェースとして実施されると良い。さらに、ブースティングコントローラ４６０はＧＥ４２０とローカルＤＮＳ４２５との間の複製されたＤＮＳトラフィックＣＤを受信するインタフェースを備える。これにより、ブースティングコントローラ４６０はＤＮＳ要求がコンテンツブースティングインフラストラクチュア４５０による優先付けされたコンテンツ配信を要求するピアＣＰからのコンテンツに関するものであるかどうかを識別することが可能になる。更に、ブースティングコントローラ４６０は、ＧＷ４２０に関する複製された認証シグナリングＣＲ、例えば、ラディウス（Ｒａｄｉｕｓ）プロトコルやダイアメータ（Ｄｉａｍｅｔｅｒ）プロトコルに従うシグナリングを受信するＧＷ４２０に関するインタフェースを備える。さらにその上、ブースティングコントローラ４６０にはエッジサーバ４７０とキャッシュサーバ４８０との内の少なくともいずれかへのインタフェースとともに、ＧＷ４２０に関するインタフェースが備えられる。後者のインタフェースは、エッジサーバ４７０とキャッシュサーバ４８０との内の少なくともいずれかのサーバと、ＧＷ４２０との間のブースティングコントローラを介したトラフィックをルーティングする目的がある。このトラフィックは優先順位が付けられる選択されたデータトラフィックを含む。

次に、エッジサーバ４７０にはＣＰサーバ５１０に関した外部パケットインタフェースが備えられる。そのインタフェースによりエッジサーバ４７０はＧＷ４２０に接続された複数のＵＥに対して配信するコンテンツデータを取得することができ、また、エッジサーバ４７０にはブースティングコントローラ４６０とキャッシュサーバ４８０とに関した内部パケットインタフェースも備えられる。同様に、キャッシュサーバ４８０には、ブースティングコントローラ４６０とエッジサーバ４７０とに関した内部パケットインタフェースが備えられる。キャッシュサーバ４８０の内部パケットインタフェースによりキャッシュサーバ４８０はエッジサーバ４７０により取得されたコンテンツデータをキャッシュし、キャッシュされたコンテンツデータをブースティングコントローラ４６０とＧＷ４２０とを介して複数のＵＥに提供することが可能になる。いくつかの実施形、例えば、エッジサーバ４７０を備えない実施形では、キャッシュサーバ４８０にはＣＰサーバ５１０に関する外部パケットインタフェースも備えられ、そのインタフェースによりキャッシュサーバ４８０がＧＷ４２０に接続された複数のＵＥへの配信のためにコンテンツデータを直接取得することが可能になる。

ここで、コンテンツブースティングアーキテクチュア４５０の上記実施例の内部パケットインタフェースは、例えば、プライベートサブネットからのＩＰアドレスのような特定の範囲からのネットワークアドレスを用いて実施されることが好ましいことに注意されたい。従って、コンテンツブースティングインフラストラクチュア４５０からのトラフィックと、例えば、サーバ５８０からのトラフィックとを、そのトラフィックのデータパケットのネットワークアドレスを用いて効率的に区別することが可能である。即ち、ＧＷ４２０とＵＥ４１０との内の少なくともいずれかは、特定の範囲からのネットワークアドレスにマッチングするパケットフィルタを用いると良い。

いくつかの実施形では、コンテンツブースティングアーキテクチュア４５０は２つの異なる特定のネットワークアドレス範囲、例えば、２つの異なるプライベートサブネットからのＩＰアドレスをもつように構成される。１つの具体的な範囲は、優先順位が付けられたコンテンツ配信を要求する複数のピアＣＰと関係づけされる一方、他の具体的な範囲は、優先順位が付けられたコンテンツ配信や異なるレベルの優先順位付けを要求しない複数のピアＣＰと関係づけされる。

ＣＤＮ ＤＮＳ５６０は従って、複数のピアＣＰに向かうＤＮＳ要求を解決するように構成される。例えば、それは、コンテンツブースティングインフラストラクチュアにより用いられるネットワークアドレスの具体的な１つ以上の範囲からの対応するアドレスを返すことができる。ＣＤＮ ＤＮＳ５６０はローカルＤＮＳ４２５のネットワークアドレスによりＭＢＢ運用者を識別できる。

図４に図示されているようなコンテンツブースティングアーキテクチュアにおいて、プロービングを行うことに基づいたベアラ制御の上記概念はブースティングコントローラ４６０において適用される。即ち、ブースティングコントローラ４６０は、図２〜図３のネットワークノード１００、図２〜図３のＵＥ１０に対応するＵＥ４１０、図２〜図３のＧＷ２６に対応するＧＷ４２０として作用しても良い。この場合、ブースティングコントローラ４６０は優先順位付けが実際に必要とされる場合にだけ、ＧＷ４２０とＵＥ４１０との間の一定の専用ベアラの使用を求める可能性をもつ。これは、無線リソースのより効率的な使用を可能にするのでＭＢＢ運用者にとって有益である。例えば、ＨＳＰＡやＬＴＥにおいて、トラフィックの優先順位付けを適用することにより、次善の無線スケジューリング、従って、削減されたシステム容量が導かれることになる。更に、このことは無線インタフェースのより効率的な構成により電池消費を削減するＵＥ４１０を用いる加入者にとっても有益である。

図５はさらにプロービングに基づくベアラ制御の上記概念を実施する機器を図示している。この機器は、図２〜図３のネットワークノード１００に対応している。しかしながら、その機器はある別のネットワークノードやＵＥ１０に対応していても良い。

図示された例では、その機器はパケットを送受信するパケットインタフェース１３０を含む。パケットインタフェース１３０は、特に、例えば、ＩＣＭＰパケットのようなＩＰパケット、或いは、正規のデータトラフィックのデータパケットのような形式で、上述のプローブパケットを送信し、対応する応答パケットを受信するために用いられると良い。更に、その機器には制御インタフェース１４０も備えられると良い。制御インタフェース１４０は上述のように、ベアラ制御手順を開始するために制御信号を送信するために用いられる。例示の３ＧＰＰシナリオでは、制御インタフェース１４０は、３ＧＰＰ ＴＳに従うＲｘインタフェースとして実施されると良い。もし、その機器がＵＥとして実施されるなら、パケットインタフェース１３０は無線インタフェースであり、制御インタフェースは同じ無線インタフェースを用いて、例えば、無線インタフェースを介して確立される制御チャネルにより実現される。

更に、その機器は、インタフェース１３０、１４０に接続されたプロセッサ１５０と、プロセッサ１５０に接続されたメモリ１６０とを含む。メモリ１６０は、例えば、フラッシュＲＯＭのような読出専用メモリ（ＲＯＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）やスタティックＲＡＭ（ＳＲＡＭ）のようなランダムアクセスメモリ（ＲＡＭ）、ハードディスクや半導体ディスクなどの大容量記憶部などを含む。メモリ１６０は、プロービングに基づく上述のベアラ制御機能を実施するために、プロセッサ１５０により実行される適切に構成されたプログラムコードを含む。即ち、メモリ１６０は、上述のプローブパケットの送信、応答パケットの受信、あるベアラではトラフィックが経験する遅延を表現するパラメータの測定を実施するためのプロービングモジュール１７０と、測定されたパラメータに基づく上述したベアラ制御手順の開始を実現するための制御モジュール１８０とを含む。プロービングモジュール１７０に関係するプロセッサ１５０は、図２で図示したような遅延モニタ１１０の機能を実装する一方、制御モジュールに関係するプロセッサ１５０は上述のような種々の制御機能を実装、即ち、ベアラ制御手順やその他の制御機能を開始させることを担当するコントローラを実装する。

図５で例示した構造は単に模式的なものであり、その機器は実際には更に構成要素を含むものであるが、説明を簡単にするために、例えば、更なるインタフェースなどは図示していないことを理解されたい。また、メモリ１６０は更に、ここでは図示していない種々のタイプのプログラムコードモジュール、例えば、適切にプローブパケットを生成するプログラムコードモジュールを含むことができることを理解されたい。幾つかの実施例に従えば、コンピュータプログラム製品、例えば、メモリ１６０に格納されることになるプログラムコードを格納する記憶媒体もまた、本発明の実施例に従う概念を実現するために、提供されるものである。

図６は本発明の実施例に従う方法を示すフローチャートを示している。その方法は、図１に例示するような移動体通信システムにおいて使用され、特に、ネットワークノード１００により実施される。しかしながら、その方法は、ＵＥ１０のような他の機器においても実施することができることを理解されたい。

ステップ６１０では、１つ以上のプローブパケットがＵＥに関して確立された１つ以上のベアラを介して送信される。これらベアラの少なくとも１つは、選択されたデータトラフィックを搬送するのに用いられる。例えば、上述のように、プローブパケットは１つのベアラ、例えば、図２〜図３のデフォルトベアラ５２で送信され、更なるプローブパケットが更なるベアラ、例えば、図２〜図３の専用ベアラ５４で送信される。プローブパケットはパケットの受信者が応答パケット、例えば、ＩＣＭＰエコー要求パケットや、確認応答パケットの送信を要求するトランスポートプロトコル、例えば、ＴＣＰを用いて送信される選択されたデータトラフィックや他のデータトラフィックのデータパケットを返すようにさせるパケットであれば任意のタイプのもので良い。

あるベアラをプローブすることを可能にするために、プローブパケットは、そのプローブパケットが所望のベアラに導かれるようにする識別子、例えば、適切に選択された送信元ネットワークアドレスや、例えば、ＤＳＣＰなどのパケットマーキングを含む。プローブパケットは従って、例えば、対応して構成されたパケット生成器により生成される。

ステップ６２０では、プローブパケットに応じて返される少なくとも１つの応答パケットが受信される。応答パケットのタイプは用いられるタイプのプローブパケットに依存する。例えば、プローブパケットがＩＣＭＰエコー要求パケットであれば、応答パケットはＩＣＭＰエコー応答パケットである。

ステップ６３０では、プローブパケットの送信と応答パケットの受信との間の時間に対応するパラメータが測定される。例えば、そのパラメータはＲＴＴとして測定される。そのパラメータは、プローブされるベアラで選択されたデータトラフィックが経験する遅延を示すものである。

ステップ６４０では、ベアラ制御手順が測定されたパラメータに基づいて開始される。このため、そのパラメータはプローブされるベアラが選択されたデータトラフィックを搬送するのに適しているかどうかを判断するために用いられる。例えば、測定されたパラメータが閾値と比較される。もし、選択されたデータトラフィックがプローブされたベアラとは別のベアラにより搬送されており、閾値との比較がプローブされたベアラが選択されたデータトラフィックを搬送するのに適切であることを示すなら、ベアラ制御手順が開始され、データパケットをプローブされたベアラへと導くようにできる。もし、選択されたデータトラフィックがプローブされたベアラにより搬送されており、閾値との比較がプローブされたベアラが選択されたデータトラフィックを搬送するのに適切ではないことを示すなら、ベアラ制御手順が開始され、データパケットをプローブされたベアラから別のベアラへと導くようにできる。

ベアラ制御手順は、例えば、パケットフィルタを構成設定したり、或いは、データパケットのマーキングを修正したりすることにより、選択されたデータトラフィックのデータパケットをプローブされたベアラへと導くことを含む。また、そのベアラ制御手順は、例えば、パケットフィルタを構成設定したり、或いは、データパケットのマーキングを修正したりすることにより、選択されたデータトラフィックのデータパケットを更なるベアラへと導くことを含む。その更なるベアラはプローブされたベアラとは異なるサービス品質のパラメータをもつと良い。そのベアラ制御手順はまた、更なるベアラを確立したり、その更なるベアラを解放したりすることを含む。そのベアラ制御手順はまた、プローブされたベアラの少なくとも１つのサービス品質のパラメータを修正し、これにより、ベアラの質を向上させたり、低下させたりすることを含む。

いくつかの実施例では、複数のベアラがプローブされ、異なるベアラについての測定されたパラメータがベアラ制御手順を開始するための基礎として用いられる。例えば、ＵＥに関して確立された１つのベアラ、例えば、デフォルトベアラ５２でプローブパケットを送信するのに加えて、１つ以上の更なるプローブパケットがそのＵＥに関して確立された更なるベアラ、例えば、専用ベアラ５４で送信されても良い。この場合も、更なるプローブパケットを受信するのに応じて返される更なる応答パケットが受信され、前記更なるプローブパケットの送信と前記更なる応答パケットの受信との間の時間に対応する更なるパラメータが測定される。それから、ベアラ制御手順が、そのパラメータと更なるパラメータとに基づいて、例えば、そのパラメータと更なるパラメータとの比較や、又は、そのパラメータと更なるパラメータとの差と閾値との比較に基づいて開始される。

プローブパケットと更なるプローブパケットの送信がなされる一方で、データパケットがそのベアラで送信され続けて搬送され、例えば、規則正しい時間間隔でベアラのプローブを繰り返し行うようにできる。しかしながら、そのベアラに他のデータトラフィックがないなら、ベアラのプローブもまた停止され、不必要なリソース利用を回避することができる。

理解されるように、プロービングに基づく上述したベアラ制御の概念は、例えば、トラフィックの優先順位付けや、他のタイプの差別化された扱いに関し、不要なベアラの使用を回避することにより、効率的なリソースの使用を可能にしている。

上述の例や実施例は単に例示的なものであり、種々の変型を許すことができることを理解されたい。例えば、その概念は他のタイプのベアラを用いた通信ネットワーク環境において使用可能である。また、そのプロービングは、図４のブースティングコントローラ４６０のようなネットワークノードや、ゲートウェイやＵＥのような移動体通信ネットワークにおけるネットワークを含む種々のデバイスにより実行される。さらに、上述の概念は、存在するデバイスのプロセッサにより実行される対応して設計されたソフトウェアを用いて、又は、専用デバイスハードウェアを用いて実装されることを理解されたい。

Claims (17)

1. データトラフィックを制御する方法であって、
   ユーザ機器（１０）に関して確立されたデフォルトベアラ（５２）を介して、少なくとも１つのプローブパケット（３０２，３０５）を送信する工程と、
   前記プローブパケット（３０２，３０５）に応じて返された少なくとも１つの応答パケット（３０３，３０６）を受信する工程と、
   前記プローブパケット（３０２，３０５）の送信と前記応答パケット（３０３，３０６）の受信との間の時間に対応するパラメータを測定する工程と、
   前記測定されたパラメータに基づいて、前記ユーザ機器（１０）に関するベアラ制御手順を開始する工程とを有し、
   前記ベアラ制御手順は、選択されたデータトラフィックのデータパケットを、前記ユーザ機器（１０）に関して確立された前記デフォルトベアラ（５２）又は専用ベアラ（５４）へと導くことを含むことを特徴とする方法。
2. 前記ベアラ制御手順は、前記専用ベアラ（５４）を確立することを含むことを特徴とする請求項１に記載の方法。
3. 前記ベアラ制御手順は、前記専用ベアラ（５４）を解放すること含むことを特徴とする請求項１又は２に記載の方法。
4. 前記データパケットを導くことは、１つ以上のパケットフィルタ（６４，６４，７２，７４）を修正することにより達成されることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記データパケットを導くことは、前記データパケットにおける識別子を修正することにより達成されることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記ベアラ制御手順は、前記デフォルトベアラ（５２）の少なくとも１つのサービス品質パラメータを修正することを含むことを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記ベアラ制御手順は、前記パラメータと閾値との比較に基づいて開始されることを特徴とする請求項１乃至６のいずれか１項に記載の方法。
8. 前記プローブパケットは、前記プローブパケット（３０２，３０５）が前記デフォルトベアラ（５２）へと導かれるようにする識別子を含むことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
9. 前記専用ベアラ（５４）を介して、少なくとも１つの更なるプローブパケット（３０２，３０５）を送信する工程と、
   前記更なるプローブパケット（３０２，３０５）の受信に応じて返された少なくとも１つの更なる応答パケット（３０３，３０６）を受信する工程と、
   前記更なるプローブパケット（３０２，３０５）の送信と前記更なる応答パケット（３０３，３０６）の受信との間の時間に対応する更なるパラメータを測定する工程とをさらに有し、
   前記ベアラ制御手順は、前記パラメータと前記更なるパラメータに基づいて開始されることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 前記ベアラ制御手順は、前記パラメータと前記更なるパラメータとの比較に基づいて開始されることを特徴とする請求項９に記載の方法。
11. 前記ベアラ制御手順は、前記パラメータと前記更なるパラメータの差と閾値との比較に基づいて開始されることを特徴とする請求項１０に記載の方法。
12. 前記更なるプローブパケットは、前記更なるプローブパケット（３０２，３０５）が前記専用ベアラ（５４）へと導かれるようにする識別子を含むことを特徴とする請求項９乃至１１のいずれか１項に記載の方法。
13. 前記プローブパケット（３０２，３０５）の送信がなされる一方で、データパケットが前記専用ベアラ（５４）で送信されることを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
14. 前記プローブパケット（３０２，３０５）と前記応答パケット（３０３，３０６）とは前記ユーザ機器（１０）に関するデータトラフィック通信のためのデータパケットであることを特徴とする請求項１乃至１３のいずれか１項に記載の方法。
15. ユーザ機器（１０）に関して確立されたデフォルトベアラ（５２）を介して、少なくとも１つのプローブパケット（３０２，３０５）を送信し、前記プローブパケット（３０２，３０５）に応じて返された少なくとも１つの応答パケット（３０３，３０６）を受信するパケットインタフェース（１３０）と、
    前記プローブパケット（３０２，３０５）の送信と前記応答パケット（３０３，３０６）の受信との間の時間に対応するパラメータを測定し、前記測定されたパラメータに基づいて、前記ユーザ機器（１０）に関するベアラ制御手順を開始するよう構成されたプロセッサ（１５０）とを有し、
    前記ベアラ制御手順は、選択されたデータトラフィックのデータパケットを、前記ユーザ機器（１０）に関して確立された前記デフォルトベアラ（５２）又は専用ベアラ（５４）へと導くことを含むことを特徴とする機器。
16. 前記ベアラ制御手順を開始するために制御信号（３０９）を送信する制御インタフェース（１４０）をさらに有することを特徴とする請求項１５に記載の機器。
17. 前記機器は、請求項１乃至１４のいずれか１項に記載の方法に従って動作するよう構成されていることを特徴とする請求項１５又は１６に記載の機器。

Images