JP6115961B2 - ネットワークトラヒックを処理するための技術 - Google Patents

Description

本発明は、ネットワークトラヒックを処理するための技術に関する。

移動通信ネットワークでは、特定のサービスに関係するネットワークトラヒックを所定のサービス品質（ＱｏＳ）を持つベアラに向けることが知られている。この点で、ベアラは、情報送信コンテクスト、または、例えば容量、遅延および／またはビット誤り率のような、定義された特性の経路であると考えられる。典型的には、移動通信ネットワークのゲートウェイと、例えば移動電話や他のタイプの移動端末のような、ユーザ装置との間には、複数のベアラが確立されるであろう。ベアラは、ネットワークからユーザ装置への方向で下り（ＤＬ）データトラヒックを搬送し、ユーザ装置からネットワークへの上り（ＵＬ）方向でデータトラヒックを搬送してもよい。ゲートウェイおよびユーザ装置において、複数のＩＰデータパケット（ＩＰ：「インターネットプロトコル」）を含むデータトラヒックを、ＩＰの５タプルのパケットフィルタを用いてフィルタリングし、それによってＩＰデータパケットを所望のベアラへ向けることができる。

具体的には、例えばモバイルＴＶのような、特定のサービスに関係するデータトラヒックを、所定のＱｏＳを提供するベアラに向けることが所望される。この目的で、特定のサービスに関係するデータパケットを識別するために、ＤＬデータトラヒックが、パケット検査を受けてもよい。所定のサービスのデータパケットが検出されると、これがポリシー制御器にシグナリングされてもよい。次いで、ポリシー制御器が、対応するパケットフィルタを生成し、これらのパケットフィルタをゲートウェイにシグナリングしてもよい。次いでゲートウェイが、受信したパケットフィルタを用いてデータパケットを所望のベアラへとルーティングする。ベアラは、典型的には、特定のサービスのためにネットワークオペレータによって選択されたＱｏＳクラスを有する。また、このプロセスにおいて、例えば、ベアラを確立し、ＵＬデータトラヒックをベアラにルーティングするために用いる目的で、ＵＬパケットフィルタをユーザ装置に知らせるために、ユーザ装置へのシグナリングが行われてもよい。

しかし、既知の解決策には、例えば所定のピア・ツー・ピア・ファイル共有アプリケーションによって行われるように、あるサービスがそのサービスに関連するＩＰパケットフローを頻繁に開始および終了するという点で、問題がありうる。この場合、結果として、データパケットを所望のベアラにルーティングする目的でパケットフィルタを確立するために、多量のシグナリングが行われるであろう。加えて、５タプルベースのパケットフィルタを用いてＤＬデータトラヒックをルーティングするには、ゲートウェイにおいてかなり多くの処理リソースが必要になる。さらに、場合によっては、パケット検査機能が特定のサービスに関連するＩＰパケットフローを十分に記述して、これをポリシー制御器にシグナリングすることが、困難または不可能となりうる。例えば、ＩＰパケットフローが暗号化されるかまたはサービスが多数のＩＰパケットフローに関連付けられる場合、例えば所定のピア・ツー・ピア・ファイル共有アプリケーションの場合に、それが起こり得る。

従って、特定のサービスのデータトラヒックに所望のＱｏＳレベルを割り当てることを可能にするような、ネットワークトラヒックを処理するための強力かつ効率的な技術が必要である。

本発明の一実施形態によって、ネットワークトラヒックを処理する方法を提供する。前記方法は、特定のユーザ及び特定のサービスのうちの少なくとも一方に関するサービス関連データトラヒックを示すパケット検査データを受信するステップと、前記ユーザ及び前記サービスのうちの少なくとも一方に関するポリシーデータを受信するステップと、前記パケット検査データ及び前記ポリシーデータに基づいてパケットフィルタを決定するステップと、を備える。前記パケットフィルタは、パケット検査に応えて前記サービス関連データトラヒックのデータパケット中に含められる識別子に基づいてデータトラヒックをフィルタリングするように構成される。

本発明の別の実施形態によって、ネットワークコンポーネントを提供する。前記ネットワークコンポーネントは、特定のユーザ及び特定のサービスのうちの少なくとも一方に関するサービス関連データトラヒックを示すパケット検査データを受信するパケット検査データインタフェースと、前記ユーザ及び前記サービスのうちの少なくとも一方に関係するポリシーデータを受信するポリシー制御器と、を備える。加えて、前記ネットワークコンポーネントは、前記パケット検査データ及び前記ポリシーデータに基づいてパケットフィルタを決定するフィルタ生成器を備え、前記パケットフィルタは、パケット検査に応えて前記サービス関連データトラヒックのデータパケット中に含められる識別子に基づいてデータトラヒックをフィルタリングするように構成される。

本発明の別の実施形態によって、ネットワークトラヒックを処理する方法を提供する。前記方法は、第１の識別子を含む着信データパケットを複数のベアラのうちの１つから受信するステップを備える。前記方法は、更に、前記第１の識別子に関して相補的な第２の識別子を含む発信データパケットを検出するステップと、前記第２の識別子を持つ前記検出された発信データパケットを、前記第１の識別子を持つ前記着信データパケットが受信されたベアラと同一のベアラへとルーティングするステップと、を備える。

本発明の別の実施形態によって、通信デバイスを提供する。ユーザ装置またはネットワークコンポーネントであってもよい前記通信デバイスは、着信データパケットを複数のベアラから受信する受信器と、前記複数のベアラ上で発信データパケットを送信する送信器と、を備える。更に、前記通信デバイスは、第１の識別子を含む着信データパケットと、前記第１の識別子に関して相補的な第２の識別子を含む発信データパケットと、を検出し、前記発信データパケットをフィルタリングすることにより、前記第２の識別子を持つ発信データパケットが、前記第１の識別子を持つ着信データパケットが受信されたベアラと同一のベアラへとルーティングされるようにするミラーリング機能を備える。

ＤＬデータトラヒックを処理するために本発明の実施形態による概念が適用されうる移動通信環境を略示する図である。 本発明の一実施形態で用いられるデータパケットの一例を略示する図である。 本発明の一実施形態で用いられるデータパケットの別の例を略示する図である。 データパケットのヘッダセクションの中の情報フィールドを略示する図である。 本発明の一実施形態によるＤＬデータトラヒックを処理する方法を示すフローチャートである。 ＵＬデータトラヒックを処理するために本発明の実施形態による概念が適用されうる移動通信環境を略示する図である。 データパケット内の識別子および相補的識別子を略示する図である。 本発明の一実施形態によるＵＬデータトラヒックを処理する方法を示すフローチャートである。

以下で、例示的な実施形態および添付の図面を参照することによって、本発明についてより詳細に説明しよう。例示した実施形態は、例えば３ＧＰＰ（第３世代パートナーシップ・プロジェクト）仕様による、移動通信ネットワークにおいてデータトラヒックを処理する方法に関する。しかし、理解されるべきだが、本書で記述する概念は、他のタイプの通信ネットワークにも適用されうる。図１乃至５に関して、ＤＬすなわちユーザ装置へのデータトラヒックを処理するための概念について記述しよう。図６乃至８に関して、ＵＬすなわちユーザ装置からのデータトラヒックを処理するための概念について記述しよう。従って、ＤＬデータトラヒックを処理するという概念と、ＵＬデータトラヒックを処理するという概念とについて、別個に記述しよう。とはいえ、理解されるべきだが、これらの概念が、別個に適用されても、組み合わせて適用されてもよい。

図１は、本発明の一実施形態によってＤＬデータトラヒックが処理される移動通信環境を略示する図である。

ネットワーク環境は、端末と呼ばれることもあるユーザ装置１０と、複数のネットワーク構成要素２２、２４、２６、３０、１００とを含んでいる。これらのネットワーク構成要素の中に、ＲＡＮ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：無線アクセスネットワーク）２２がある。ＲＡＮは、或るタイプまたは複数のタイプの無線アクセス技術、例えば、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）（登録商標）、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ Ｒａｔｅ ｆｏｒ ＧＳＭ （登録商標）Ｅｖｏｌｕｔｉｏｎ）、またはＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）に基づいている。ＲＡＮ２２は単一のノードとして図示されているが、ＲＡＮ２２が実際には複数の構成要素で形成されてもよいことは理解されるべきであり、それについては本書ではこれ以上説明しない。ＲＡＮ２２は、トランスポートノード２４に連結されており、それが次には、ゲートウェイ２６に連結されている。ここで理解されるべきだが、代わりに、２つ以上のトランスポートノード２４が、ＲＡＮ２２とゲートウェイ２６との間に連結されてもよいし、または、ＲＡＮ２２が、直接ゲートウェイ２６に連結されてもよい。ゲートウェイ２６は、ＧＰＲＳ（Ｇｅｎｅｒａｌ Ｐａｃｋｅｔ Ｒａｄｉｏ Ｓｅｒｖｉｃｅ）ベースのサービスの接続を１つ以上の外部パケットデータネットワークに提供するＧＧＳＮ（Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ）であってもよい。また、ゲートウェイ２６は、３ＧＰＰ仕様によるＳＡＥ ＧＷ（Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ Ｇａｔｅｗａｙ）であってもよい。

加えて、移動通信ネットワークは、３ＧＰＰ仕様によるＰＣＲＦ（Ｐｏｌｉｃｙ ａｎｄ Ｃｈａｒｇｉｎｇ Ｒｕｌｅｓ Ｆｕｎｃｔｉｏｎ）として実装されるポリシー制御器３０と、パケット検査器１００とを含んでいる。ポリシー制御器は、専用のハードウェアによって、またはプロセッサによって実行されるソフトウェア機能として実装されてもよい。パケット検査器１００は、専用のハードウェアによって、またはプロセッサによって実行されるソフトウェア機能として実装されてもよい。パケット検査器１００は、ＤＰＩ（Ｄｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ）を実装するように構成されてもよく、ＤＰＩは、データパケットのヘッダセクションとデータセクションとを両方検査することに基づいてもよい。さらに、検査は、パケット到着間隔、送信パタン、パケットサイズのようなヒューリスティック尺度を集めることに基づいてもよい。そのようなヒューリスティックは、暗号化の場合にすら適用できる。ヘッダセクションおよびデータセクションは、異なるサービスまたはプロトコルを識別するために、異なるプロトコルレイヤに関して、例えばアプリケーションレイヤまたは低位レイヤに関して検査されてもよい。また、検査は、セッションに関係する制御シグナリングに関して行われてもよい。しかし、他のタイプのパケット検査プロセスを、例えばヘッダセクションの検査に基づくだけで、同様に実装することもできる。

ゲートウェイ２６と、ポリシー制御器３０と、パケット検査器１００とは、典型的には、コアネットワークの構成要素であるとみなされる。

ポリシー制御器３０は、シグナリングパス５を介してパケット検査器１００と通信する。シグナリングパス５は、３ＧＰＰ仕様によるＲｘインタフェースまたはＧｘインタフェースを用いて実装されてもよい。さらに、ポリシー制御器３０は、シグナリングパス６を介してゲートウェイ２６と通信するが、シグナリングパス６は、３ＧＰＰ仕様によるＧｘインタフェースを用いて実装されてもよい。

ポリシー制御器３０は、さらに、例えば３ＧＰＰ仕様によるＳｐインタフェースを用いて実装される、シグナリングパス８を介して加入データベース３２およびサービスポリシーデータベース３４に連結される。このようにしてポリシー制御器３０は、特定のユーザに関する、および／または、例えばモバイルＴＶのような、移動通信ネットワーク内で利用可能な特定のサービスに関するポリシーデータを受信してもよい。

このようにしてポリシー制御器３０は、シグナリングパス５、６、８をサポートするためのインタフェースを提供する。

さらに図示するように、ネットワークとユーザ装置１０との間のサービス関連データトラヒックは、複数のベアラ５２、５４によって搬送される。サービス関連データトラヒックは、典型的には、ユーザ装置１０で実行される１つ以上のクライアント／ピアアプリケーション１２に関連する。ベアラ５２、５４は、ユーザ装置１０とゲートウェイ２６との間に確立される。ベアラ５２、５４は、ＤＬ方向とＵＬ方向の両方でデータトラヒックを搬送し、すなわち、ＤＬベアラおよびＵＬベアラを形成しているとみなしてもよい。ベアラ５２、５４での双方向通信をサポートするため、ユーザ装置１０には、トランシーバ構造体、すなわち、ベアラ５２、５４から着信データパケットを受信するための受信器１４と、ベアラ５２、５４でデータパケットを送信するための送信器１６との両方が設けられている。ベアラ５２、５４は、パケットベースのサービスをユーザ装置１０に提供するために一般的に確立されたデフォルトベアラと、デフォルトベアラとは異なるＱｏＳレベル、例えばより高いＱｏＳレベルを有しうる、１つ以上の専用ベアラ５４とを含んでもよい。各ベアラ５２、５４は、対応するＱｏＳプロファイルに関連付けられてもよい。ＱｏＳプロファイルのパラメータは、ＱＣＩ（ＱｏＳクラス識別子）と、ＡＲＰ（割り当て／保持優先度）と、ＭＢＲ（最大ビットレート）と、および／またはＧＢＲ（保証ビットレート）とであってもよい。従って、各ベアラ５２、５４は、対応するＱｏＳクラスに関連付けられてもよい。

ユーザ装置１０では、データパケットが、対応する構成されたＵＬパケットフィルタ６２、６４を用いて所望のベアラ５２、５４にルーティングされる。ゲートウェイ２６では、データパケットが、対応する構成されたＤＬパケットフィルタ７２、７４を用いて所望のベアラ５２、５４にルーティングされる。ＱｏＳプロファイルのパラメータは、シグナリングパス６を用いてポリシー制御器３０からゲートウェイ２６へとシグナリングされてもよい。同様に、ゲートウェイ２６において用いられることになるＤＬパケットフィルタ７２、７４は、シグナリングパス６を介してポリシー制御器３０からゲートウェイ２６へとシグナリングされてもよい。ユーザ装置１０で用いられるＵＬパケットフィルタ６２、６４に関しては、これらは、ポリシー制御器３０からゲートウェイ２６を介してシグナリングされてもよい。しかし、図６乃至８に関してさらに説明するように、実施形態によっては、ＵＬパケットフィルタ６２，６４は、ユーザ装置１０で受信されたデータトラヒックに応じて生成されてもよい。

図１に図示した移動通信ネットワークでは、ユーザ装置１０のＤＬデータトラヒックは、ゲートウェイ２６によって受信される前にパケット検査器１００を通過する。パケット検査器１００は、１つ以上の所定のサービスに関連するか、および／または特定のユーザに関連するデータパケットを識別する。これは、ポリシー制御器３０から受信されたパケット検査制御データに基づいて行われてもよい。特定の事前定義されたサービスに関係するデータパケットが識別された場合、パケット検査器１００が、パケット検査データを送信することによって、それぞれの表示情報(indication)をポリシー制御器３０に提供する。加えて、パケット検査器１００は、マーキング機能１２０を含んでおり、これは、検査されたデータパケットに識別子を含める。マーキング機能１２０は、専用ハードウェアによって、または、プロセッサで実行されるソフトウェア機能として、実装されてもよい。識別子は、データパケットが関係する識別されたサービスに従って選択される。例えば、所定のファイル共有サービスに関係するデータパケットには第１の識別子が与えられ、所定のメディアストリーミングサービスに関係するデータパケットには第２の識別子が与えられてもよい。このようにして、識別子をデータパケットに含める工程またはデータパケットをマークする工程は、パケット検査の結果に基づいて行なわれるか、または、パケット検査プロセスの一部であってもよい。識別子は、例えば特定のＤｉｆｆＳｅｒｖコードポイント（ＤＳＣＰ：ｄｉｆｆｅｒｅｎｔｉａｔｅｄ ｓｅｒｖｉｃｅｓ ｃｏｄｅ ｐｏｉｎｔ）を設定することによって、データパケットのヘッダセクションの中に情報フィールドを設定することによってデータパケットに含まれてもよい。特定のサービスの対応する識別子へのマッピングは、ポリシー制御器３０によって、パケット検査制御データを用いて動的に制御されてもよい。このようにして、対応する識別子への特定のサービスのマッピングは、ポリシーデータに基づいて動的に制御されてもよい。例えば、マッピングは、時刻または曜日に依存して変化することもできるだろう。

パケット検査器１００から受信したパケット検査データに基づいて、かつ、ポリシーデータに基づいて、ポリシー制御器３０は、データパケットを所望のベアラ５２、５４へルーティングするためにゲートウェイ２６で用いられるＤＬパケットフィルタ７２、７４の選択および／または構成を制御する。これを目的として、ポリシー制御器３０は、フィルタ生成器３５を含んでいる。フィルタ生成器は、専用のハードウェアによって、または、プロセッサによって実行されるソフトウェア機能として、実装されてもよい。フィルタ生成器３５は、ＤＬパケットフィルタを構築し、事前に構成されたＤＬパケットフィルタをリストから選択し、および／または、選択されたＤＬパケットフィルタを構成してもよい。ＤＬパケットフィルタ７２、７４は、ＤＬデータトラヒックを、パケット検査器１００によってデータパケットに含められた識別子に基づいてフィルタリングする。ＤＬパケットフィルタ７２，７４は、パケット検査器１００によって含められた識別子を単に考慮に入れればよいのだから、これによって、大いに効率的で信頼性のあるフィルタリングプロセスが可能になる。例えば、識別子が、データパケットのヘッダセクション中のＤＳＣＰである場合、ＤＬパケットフィルタ７２、７４は、単に、データパケットのヘッダセクション中のＤＳＣＰ情報フィールドを分析すればよい。このようにして、特定のサービスに関係するデータトラヒックは、対応するＱｏＳクラスを持つ所望のベアラ５２、５４に動的にルーティングされてもよい。

以下で、検査されたデータパケットをマーキングするという概念について、例示するタイプのデータパケットを参照することによって、より詳細に説明しよう。

図２は、ＩＰバージョン４のタイプのＩＰデータパケットを略示する図である。図示するように、データパケットのヘッダセクションは、複数の情報フィールドを含み、それらは、「Ｖｅｒｓｉｏｎ（バージョン）」、「ＩＨＬ（ＩＰ Ｈｅａｄｅｒ Ｌｅｎｇｔｈ：ＩＰヘッダ長）」、「Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ」、「Ｔｏｔａｌ Ｌｅｎｇｔｈ（全体の長さ）」、「Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ（識別子）」、「Ｆｌａｇｓ（フラグ）」、「Ｆｒａｇｍｅｎｔ Ｏｆｆｓｅｔ（フラグメントオフセット）」、「Ｔｉｍｅ ｔｏ Ｌｉｖｅ（有効期間）」、「Ｐｒｏｔｏｃｏｌ（プロトコル）」、「Ｈｅａｄｅｒ Ｃｈｅｃｋｓｕｍ（ヘッダチェックサム）」、「Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ（ソースアドレス）」、「Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ（宛先アドレス）」、「Ｏｐｔｉｏｎｓ（オプション）」、「Ｐａｄｄｉｎｇ（パディング）」と呼ばれる。これらのフィールドに関する詳細は、ＲＦＣ７９１仕様書に定義されている。「Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ」と名付けられた情報フィールドは、ＲＦＣ２４７５仕様書に定義されている。加えて、ＩＰデータパケットのヘッダセクションは、「Ｓｏｕｒｃｅ Ｐｏｒｔ（ソースポート）」および「Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ（宛先ポート）」と呼ばれる情報フィールドも含んでいる。対応する情報フィールドは、例えば、ＲＦＣ７９３仕様書に定義されているＴｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（ＴＣＰ）およびＲＦＣ７６８仕様書に定義されているＵｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（ＵＤＰ）によって定義されている。

ヘッダセクションに続いて、ＩＰデータパケットは、典型的にはデータセクションを備えており、その中にはさまざまなタイプのペイロードデータトラヒックが含まれうる。

図３は、ＩＰバージョン６のタイプによるＩＰデータパケットを略示する図である。この場合もやはり、ヘッダセクションは複数の情報フィールドを含み、それらは、「Ｖｅｒｓｉｏｎ（バージョン）」、「Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ」、「Ｆｌｏｗ Ｌａｂｅｌ（フローラベル）」、「Ｐａｙｌｏａｄ Ｌｅｎｇｔｈ（ペイロード長）」、「Ｎｅｘｔ Ｈｅａｄｅｒ（次のヘッダ）」、「Ｈｏｐ Ｌｉｍｉｔ（ホップリミット）」、「Ｓｏｕｒｃｅ Ａｄｄｒｅｓｓ（ソースアドレス）」、「Ｄｅｓｔｉｎａｔｉｏｎ Ａｄｄｒｅｓｓ（宛先アドレス）」と呼ばれる。ヘッダセクションのこの構造は、ＲＦＣ２４６０仕様書に定義されている。加えて、ヘッダセクションは、例えばＴＣＰまたはＵＤＰによって定義される、「Ｓｏｕｒｃｅ Ｐｏｒｔ（ソースポート）」および「Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ（宛先ポート）」と呼ばれる情報フィールドも含んでいてもよい。この場合もやはり、ヘッダセクションの後に、典型的には、各種のペイロードデータを搬送するデータセクションが続くであろう。

本開示では、「Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ」、「ソースアドレス」、「宛先アドレス」、「ソースポート」、「宛先ポート」と呼ばれる情報フィールドだけについて、これ以降論じる。その他の情報フィールドに関しては、さらなる説明を上記のＲＦＣ仕様書から得ることができる。

「ソースアドレス」という情報フィールドは、データパケットが発信されるＩＰアドレスを示す。同様に、「宛先アドレス」という情報フィールドは、データパケットの宛先であるＩＰアドレスを示す。ＩＰバージョン４では、ソースアドレスおよび宛先アドレスは３２ビット値である。ＩＰバージョン６では、ソースアドレスおよび宛先アドレスは１２８ビット値である。

「ソースポート」という情報フィールドは、データパケットのソースにおけるポート番号を示し、「宛先ポート」という情報フィールドは、データパケットの宛先ポイントにおけるポート番号を示す。

ソースアドレスと宛先アドレスとソースポートと宛先ポートとに基づいて、ソースアドレスおよびソースポートによって定義される第１のエンドポイントと宛先アドレスおよび宛先ポートによって定義される第２のエンドポイントとの間のＩＰパケットのフローとして、ＩＰパケットフローを定義することができる。ソースアドレスと宛先アドレスとソースポートと宛先ポートとプロトコル識別子とを含むエンティティは、「ＩＰの５タプル」とも呼ばれる。

「Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ」という情報フィールドは、ＩＰバージョン４のデータパケットにもＩＰバージョン６のデータパケットにも含まれている。ＲＦＣ２４７４仕様書で定義されているように、「Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ」という情報フィールドは、８ビット値である。この情報フィールドの構造を、図４に略示する。

図４に示すように、情報フィールドの６個のビット、すなわちビット０乃至５は、ＤｉｆｆＳｅｒｖコードポイント（ＤＳＣＰ：Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｃｏｄｅ Ｐｏｉｎｔ）を定義するのに用いられる。他の２つのビットは未使用である。ＤＳＣＰを用いて、ネットワークノードによるデータパケットの転送が制御されてもよい。異なるタイプのサービスに関係するデータパケットには、異なる転送手順が選択されてもよい。ＤＳＣＰは、標準化されてもよい。また、さまざまな標準外ＤＳＣＰが利用可能である。

以下に、本発明の一実施形態によるＤＬデータトラヒックを処理するプロセスをより詳細に記述しよう。これは、図１に示した移動通信ネットワーク環境を参照することによって行う。

上記のように、移動通信ネットワークは、異なるベアラに関連する複数のＱｏＳクラスをサポートしてもよい。ＱｏＳクラスは、対応するＱＣＩによって識別されてもよい。識別された特定のサービスのデータパケットをパケット検査器１００の中でマークするために、専用のＤＳＣＰが、例えば標準外ＤＳＣＰの範囲から、定義される。結果として、各ベアラについて専用のＤＳＣＰがあってもよい。

さらに、パケット検査器１００によって検出されることになる各サービスを専用のＤＳＣＰにマッピングするマッピングテーブルが定義される。異なる専用のＤＳＣＰが、こうして、異なるサービスに関係するデータパケットをマークするために用いられてもよい。しかし、例えば、これらのサービスに同じＱｏＳクラスが割り当てられるべき場合には、異なるサービスのデータパケットが、同じＤＳＣＰでマークされることも可能である。このマッピングテーブルは、ポリシー制御器３０によって維持され、さらに、例えばシグナリングパス５を用いて、パケット検査器１００へと通信されてもよい。あるいは、パケット検査器１００は、マッピングテーブルを使って静的に構成されてもよい。パケット検査器１００においてマッピングテーブルが、ポリシー制御器３０によって動的に構成可能な場合、ポリシーデータに基づいてマッピングテーブルを再構成することも可能である。例えば、マッピングテーブルを、時刻または曜日に基づいて再構成することができるだろう。

パケット検査器１００が、事前定義されたサービスに関係するＩＰパケットフローを検出した場合、これは、パケット検査データの中でポリシー制御器３０へとシグナリングされる。さらに、パケット検査器１００のマーキング機能が、サービスに関係するデータパケットを、マッピングテーブルの中で定義されたＤＳＣＰを使ってマークする。その他のデータパケット、すなわち、前定義されたサービスに関係するとして識別されなかったデータパケットについては、デフォルトＤＳＣＰが設定されてもよい。例えば、デフォルトＤＳＣＰはゼロであってもよい。代わりに、前定義されたサービスに関係するとして識別されなかったデータパケットについては、ＤＳＣＰの設定が省略されてもよい。またパケット検査データの中で、パケット検査器１００がサービス識別子をポリシー制御器３０にシグナリングしてもよい。サービス識別子を使って、識別されたサービス、および／または、対応するデータパケットをマークするのに用いられたＤＳＣＰが、ポリシー制御器３０にシグナリングされてもよい。ポリシー制御器３０へのシグナリングの頻度またはイベントに基づくトリガリングが、適切に選択されてもよい。

パケット検査データに応じて、ポリシー制御器３０は、識別されたサービスのデータパケットをマーキングするために用いられたＤＳＣＰに基づいて動作するＤＬパケットフィルタを決定する。一実施形態では、ＤＬパケットフィルタは、実質的にデータパケットをマーキングするために用いられたＤＳＣＰに基づいてのみ、動作してもよい。ＤＬパケットフィルタは、ゲートウェイ２６にシグナリングされる。

次いで、ＤＬパケットフィルタを用いて、ゲートウェイ２６は、ＤＳＣＰを使ってマーキングされたＤＬデータパケットを、対応するベアラ５２、５４へとルーティングする。ベアラ５２、５４は、すでに存在していてもよい。ベアラが存在していない場合、ポリシー制御器３０からシグナリングを受信した時点で、ベアラが確立されてもよい。すなわち、ＤＳＣＰに関連するＱｏＳクラスを有するベアラ５２、５４がすでに確立されている場合、ＤＬパケットフィルタは、フィルタリングされたデータパケットを、このすでに存在するベアラへとルーティングするであろう。そのようなベアラが存在しない場合、ポリシー制御器３０からＤＬパケットフィルタのシグナリングを受信した時点で、ＤＳＣＰに関連するＱｏＳクラスのベアラが確立されるであろう。

図５は、上記の概念に従ってＤＬデータトラヒックを処理する方法２００を略示するフローチャートである。

ステップ２１０で、例えばポリシー制御器３０において、パケット検査データが受信される。受信されたパケット検査データは、識別されたデータパケットが関係するサービスを示すサービス識別子を含んでもよい。さらに、パケット検査データは、例えば専用ＤＳＣＰのような、パケット検査に応じてデータパケットをマーキングするのに用いられる識別子を示してもよい。

ステップ２２０で、ポリシーデータが受信される。ポリシーデータは、特定のサービスのデータパケットをどのように処理するかという、移動通信ネットワークのオペレータによって定義された一般的なポリシーを含んでもよいし、あるいは、ユーザに関連付けられてもよく、すなわち、特定のサービスおよび特定のユーザのデータパケットをどのように処理するかを定義してもよい。また、ポリシーデータは、異なる加入者グループを区別してもよいし、ユーザ、加入者、加入者グループまたはサービスの量的な割当を定義してもよい。特に、ポリシーデータは、特定のサービスに関係するデータパケットにはどのサービス品質クラスが与えられるべきかを示してもよい。この情報は、例えば時刻、曜日、または使用される量的な割当に基づいて、動的に変化してもよい。

ステップ２３０で、ＤＬパケットフィルタが、パケット検査データとポリシーデータとに基づいて決定される。特に、パケット検査プロセスに応じてデータパケットに含まれる識別子に基づいて動作するＤＬパケットフィルタが、決定される。ＤＬパケットフィルタは、次いで、マーキングされたデータパケットを、所望のＱｏＳクラスを有するベアラにルーティングするのに用いられる。この目的で、決定されたＤＬパケットフィルタが、ポリシー制御器、例えばポリシー制御器３０から、ゲートウェイ、例えばゲートウェイ２６へ、シグナリングされてもよい。

図６は、本発明の一実施形態によってＵＬデータトラヒックが処理される移動通信環境を略示する図である。図６の移動通信環境は、一般に図１のそれと同様であり、同様の構成要素は、同じ引用符号で示されている。さらなる詳細については、図１に関連する対応する説明を参照する。

図６に示す概念によれば、ＤＬデータパケットにおける情報が、ＵＬデータパケットをルーティングするためのローカルルールを形成するためにユーザ装置１０において用いられる。ここで留意すべきことだが、移動通信のシナリオでは、ＩＰデータパケットのフローは典型的には双方向である。ペイロードデータのトランスポートが、例えばＴＣＰパケットに基づいて、一方向においてのみ行われる場合であってさえ、ＩＰパケットフローは、典型的には、例えば、ＴＣＰ確認応答パケットのような、反対方向に送信される制御パケットも含むであろう。さらに、ＩＰパケットフローのソースＩＰアドレスおよび宛先ＩＰアドレス、およびそれらのポート番号は、典型的には対称的であり、すなわち、一方向における（ＩＰアドレスおよびポート番号によって識別される）宛先エンドポイントは、他方向における（ＩＰアドレスおよびポート番号によって識別される）ソースエンドポイントと同じであり、逆も同様である。対称性に起因して、同じＩＰパケットフローのうちの反対方向に流れているパケットは、「相補的」アドレス識別子と「相補的」ポート識別子とを有するであろうし、それは、一方向におけるソース識別子は、他方向における宛先識別子と同じであることを意味する。

下記で説明するようなＵＬデータトラヒックを処理するという概念では、ＤＬデータトラヒックはすでにＱｏＳクラスおよび対応するベアラにマッピングされていると想定されるであろう。これは、図１に関して上述した概念に従って行われてもよい。すなわち、図６の移動通信環境は、パケット検査器１００と、図１に関して説明したＤＬデータトラヒックを処理するための関連する機能性とを含んでもよいだろう。とはいえ、理解されるべきことだが、ＤＬデータトラヒックをＱｏＳクラスおよびベアラにマッピングするという概念も、同様に適用可能である。

図６に示すように、ユーザ装置１０は、さらに、ミラーリング機能２２０を含む。ミラーリング機能２２０は、専用のハードウェアによって、またはプロセッサ上で実行されるソフトウェア機能として実装されてもよい。ミラーリング機能２２０は、第１の識別子を含む着信データパケットと、第１の識別子に関して相補的な第２の識別子を含む発信データパケットとを検出するように構成される。相補的な識別子において、宛先エンドポイント識別子、例えば宛先ＩＰアドレスおよび／または宛先ポートは、識別子の中の、ソースエンドポイント識別子、例えばソースＩＰアドレスおよび／またはソースポートと同じである。第１および第２の識別子は、それぞれ、ＩＰの５タプルであってもよい。ミラーリング機能２２０は、ＩＰの５タプルに基づくＵＬパケットフィルタ６２、６４を、相補的な第２の識別子を有する発信データパケットが、第１の識別子を有する着信データパケットが受信されたのと同じベアラにルーティングされるような形で、制御する。このように、ＵＬパケットフィルタ６２、６４を選択または構成するのに、ゲートウェイ２６とユーザ装置１０との間の明示的なシグナリングは必要ない。ミラーリング機能２２０が、新たなＩＰパケットフローがベアラ５２、５４上にマッピングされたこと、または新規のベアラ５２、５４が確立されたことを検出した場合、ミラーリング機能２２０は、対応するＵＬパケットフィルタ６２、６４を自動的に生成してもよい。ＤＬ方向の着信データパケットが、特定のＩＰの５タプルによって識別された場合、ＵＬパケットフィルタ６２、６４は、相補的なＩＰの５タプルを搬送する発信データパケットを、着信データパケットが受信されたのと同じベアラにルーティングするように構成されるであろう。

ＩＰの５タプルに基づいている識別子と相補的な識別子との構造を、図７に示す。しかし、理解されるべきことだが、同様に他のタイプの識別子および相補的な識別子もありうる。一般に、相補的な識別子は、着信データパケットの識別子の中で識別されたソースを、発信データパケットの宛先として示す。

図７に示すように、ＩＰの５タプルに基づく識別子は、ソースアドレスＡと宛先アドレスＢとソースポートＣと宛先ポートＤとプロトコル識別子Ｘとを含んでもよい。次いで、対応する相補的識別子は、ソースアドレスＢと宛先アドレスＡとソースポートＤと宛先ポートＣとプロトコル識別子Ｘとを有するであろう。言い換えると、識別子と比べて相補的識別子では、ソースアドレスと宛先アドレスとが、交換されている。同様に、識別子と比べて相補的識別子では、ソースポートと宛先ポートとが、交換されている。プロトコル識別子は、そのまま変わらない。他の実施形態では、さまざまなタイプの識別子および相補的識別子が、例えばＩＰの５タプルの一部だけに基づいて、用いられてもよい。例えば、識別子と比べて相補的識別子では、ソースアドレスおよび宛先アドレスだけが、交換されてもよいだろう。

以下で、本発明の一実施形態によるＵＬデータパケットを処理するプロセスについて、図６に示す構造を参照しながら詳細に説明しよう。

最初に、特定のサービスに関係するＵＬデータパケットが、ユーザ装置１０からゲートウェイ２６へ任意のベアラ、例えばデフォルトベアラで送信されてもよい。次いで、対応するＩＰパケットフローは、ＤＬ方向に送信されたデータパケットを含むであろう。これらのデータパケットは、例えば図１に関して説明した概念を用いて、所望のＱｏＳクラスおよび対応するベアラ５２、５４にマッピングされるであろう。また、このプロセスは、所望のＱｏＳクラスに関連する新規ベアラを確立することを含んでもよい。

次いで、ユーザ装置１０の中のミラーリング機能２２０は、このベアラ５２、５４から受信された着信データパケットを検出して、受信された着信データパケットの中のＩＰの５タプルに対して相補的なＩＰの５タプルに基づいて動作する、「ミラーリングされた」ＵＬパケットフィルタ６２，６４を生成する。ここで、理解されるべきだが、単一のベアラ５２、５４上に異なるＩＰパケットフローが存在してもよく、また、複数のＵＬパケットフィルタ６２、６４が、発信データパケットを同じベアラ５２、５４へルーティングしてもよい。着信データパケットを持つ新規ＩＰパケットフローがベアラ５２、５４上に存在する場合、または、新規ベアラが確立された場合、対応する新規ＵＬデータパケットフィルタ６２、６４が生成されるであろう。

上記の概念を適用する場合、ユーザ装置１０には、ユーザ装置１０がミラーリング機能２２０をサポートすることを移動通信ネットワークに示す機能性が与えられてもよい。例えば、これは、例えばユーザ装置１０とコアネットワークとの間の接続手順の間に、セッション管理シグナリングに含まれてもよいだろう。一例として、情報要素がシグナリングプロセスに追加され、その中でユーザ装置１０は、ユーザ装置１０がミラーリング機能２２０をサポートすることを示すこともできるだろう。図６は、ユーザ装置１０から伸びる、対応するシグナリングパス２を略示する。ここで、理解されるべきだが、シグナリングパス２は、ユーザ装置１０から特定のネットワークノード、例えば図示されるようにポリシー制御器３０へ直接伸びているように略示されているが、典型的には、他のネットワークノードを介して実装されてもよい。例えば、ＵＭＴＳ通信ネットワークでは、シグナリングパス２は、ユーザ装置１０からＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ：サービングＧＰＲＳサポートノード）へ伸びることもできるだろう。ＳＡＥ／ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ／Ｓｅｒｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ）通信ネットワークでは、シグナリングパス２は、ユーザ装置１０からＭＭＥ（Ｍｏｂｉｌｅ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ：モビリティ管理エンティティ）へ伸びることもできるだろう。次いで、これらのネットワークノードから、シグナリング情報が、他のネットワークノード、例えばポリシー制御器３０へ転送または配信されてもよい。

一部の実施形態では、ユーザ装置１０がミラーリング機能２２０をサポートするという情報が、コアネットワークノード間で、例えばポリシー制御器３０へ配信されるか、またはパケット検査機能をサポートするノード、例えば図１に示すパケット検査器１００へ配信されてもよい。この目的で、３ＧＰＰ仕様書によるＧｘインタフェースまたはＲｘインタフェースが、再利用されてもよい。

一部の実施形態では、別のシグナリングパス４が、移動通信ネットワークからユーザ装置１０へ提供されてもよい。このシグナリングパス４を用いれば、ベアラ毎にミラーリング機能２２０を起動または停止することが可能となりうる。これは、すべてのアプリケーションまたはサービスがこの機能を起動させる必要があるとは限らない場合に、有利でありうる。例えば、場合によっては、或るサービスのデータパケットの中でＩＰの５タプルが静的に定義され、対応する静的なＵＬパケットフィルタ６２、６４がユーザ装置１０の中で用いられてもよい。この場合もやはり理解されるべきだが、シグナリングパス４は、特定のネットワークノードから、例えば図示されるようにポリシー制御器３０から直接ユーザ装置１０へ伸びているように略示されているが、典型的には、他のネットワークノードを介して実装されてもよい。例えば、ＵＭＴＳ通信ネットワークでは、シグナリングパス２は、ＳＧＳＮ（Ｓｅｒｖｉｎｇ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ：サービングＧＰＲＳサポートノード）からユーザ装置１０へ伸びることもできるだろう。ＳＡＥ／ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ／Ｓｅｒｖｉｃｅ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ）通信ネットワークでは、シグナリングパス４は、ＭＭＥ（Ｍｏｂｉｌｅ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ：モビリティ管理エンティティ）からユーザ装置１０へと伸びることもできるだろう。次には、これらのネットワークノードが、他のネットワークノード、例えばポリシー制御器３０から、シグナリング情報を受信してもよい。

一部の実施形態では、移動通信ネットワークは、ミラーリング機能２２０が適用されるべきか否かを、例えば、３ＧＰＰ仕様書に定義されている標準化されたベアラ確立手順またはベアラ変更手順を用いて、ユーザ装置１０にシグナリングすることができる。このための対応する情報要素が、標準化されたベアラ確立手順またはベアラ変更手順に追加されてもよいだろう。そのような場合、ユーザ装置１０から、ミラーリング機能２２０がサポートされている移動通信ネットワークへのシグナリングも、同様にベアラ毎に実装されてもよいだろう。すなわち、対応するシグナリングは、新規ベアラについてはミラーリング機能２２０のサポートを指定してもよいだろうし、すでに確立されているベアラについてはサポート情報を変更してもよいだろう。

図８は、上記の概念によるＵＬデータトラヒックを処理するための方法３００を示すフローチャートである。

ステップ３１０で、第１の識別子を持つ着信データパケットが、ベアラから受信される。上記で説明したように、ベアラには、対応するＱｏＳクラスが関連付けられていてもよく、また、第１の識別子は、ＩＰの５タプルであってもよい。

ステップ３２０で、相補的な第２の識別子を持つ発信データパケットが検出される。これは、ベアラから受信された着信データパケットの中のＩＰの５タプルに対して相補的なＩＰの５タプルに基づいて動作する「ミラーリングされた」ＵＬパケットフィルタを生成または構成することによって行われてもよい。

ステップ３３０では、第２の識別子を持つ発信データパケットが、第１の識別子を持つ着信データパケットが受信されるのと同じベアラへルーティングされる。この場合もやはり、これは、例えば相補的識別子またはその一部に基づいて動作する、対応する「ミラーリングされた」ＵＬパケットフィルタを選択または構成することによって行われてもよい。

上記で説明した概念によって、サービス関連データトラヒックを所望のＱｏＳクラスに、例えばユーザ固有ポリシーデータに基づいて、および／または、サービス固有ポリシーデータに基づいて、動的にマッピングすることが可能である。さらに、このマッピングは、時刻、曜日、または他のパラメータに依存することもできるだろう。従って、さまざまな異なるポリシーが、サービス関連データトラヒックのＱｏＳクラスへのマッピングを制御するためのポリシーデータの中で定義されてもよい。１つのそのようなポリシーは、ゲートウェイにおいて特定のサービスに関係するデータトラヒックを遮断することすらありうる。

さらに、ポリシーデータに基づくＱｏＳの制御は、コアネットワークインタフェースまたはユーザ装置への過度のシグナリングを必要とすることなく、効率的に行われてもよい。図１乃至５に関して説明した、ＤＬデータトラヒックを処理するという概念を、図６乃至８に関して説明したＵＬデータトラヒックを処理するという概念と組み合わせると、ＤＬデータトラヒックとＵＬデータトラヒックとを両方処理することを可能にする効率的な解決策が得られる。

加えて、上記の概念は、必要とされないベアラを確立することには依存しない。むしろ、ベアラは、必要に応じて確立されてもよく、それによって、利用可能なネットワークリソースを効率的に使用してもよい。

理解されるべきだが、上記の概念は、単に例示しているのであって、各種の変更が可能である。例えば、図１および図６に示すネットワークノードは、別個のノードとして実装される必要はなく、単一のネットワーク構成要素の中に統合されてもよい。また、例えば、パケット検査器１００は、ゲートウェイ２６に組み込まれてもよいだろう。概念は、各種の移動通信ネットワークに適用されうる。最後に、留意されるべきだが、図６乃至８に関して説明したＵＬデータトラヒックを処理するための解決策は、ユーザ装置からのＵＬデータトラヒックを処理することに限定されない。そうではなく、これらの概念は、着信データパケットがすでに特定のベアラにマッピングされていて、対応する発信データパケットが存在するようなすべての状況に一般的に適用することができる。

Claims (11)

1. ネットワークトラヒックを処理する方法であって、
   パケット検査器（１００）が、データパケットのパケット検査を実行するステップと、
   前記パケット検査器（１００）が、前記データパケットが特定の事前定義サービスに関係するということを識別するステップと、
   前記パケット検査器（１００）が、パケット検査データをPolicy and Charging Rules Function（ＰＣＲＦ）（３０）へ送信するステップであって、前記パケット検査データは前記特定の事前定義サービスに関するサービス関連データトラヒックを示すと共に前記識別されたデータパケットが関係する前記特定の事前定義サービスを示すサービス識別子を含む、ステップと、
   前記パケット検査器（１００）が、前記識別されたデータパケットの中に識別子を含めることにより前記識別されたデータパケットをマーキングするステップと、
   を備え、
   前記パケット検査器（１００）と前記ＰＣＲＦ（３０）とは、移動通信ネットワークを介して相互に結合された別個のネットワークコンポーネントである
   ことを特徴とする方法。
2. 前記パケット検査は、前記データパケットのヘッダセクションの検査により実行される
   ことを特徴とする請求項１に記載の方法。
3. 前記パケット検査は、前記データパケットのヘッダセクション及びデータセクションの両方の検査により実行される
   ことを特徴とする請求項１又は２に記載の方法。
4. 前記識別子は、前記データパケットのヘッダセクションの中にDifferentiated Services Code Pointフィールドをセットすることにより含められる
   ことを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記パケット検査データは、前記データパケットをマーキングするために使用される前記識別子を示す
   ことを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記パケット検査器（１００）が、前記ＰＣＲＦ（３０）からパケット検査制御データを受信するステップであって、前記パケット検査制御データは前記特定の事前定義サービスを前記識別子にマッピングする、ステップ
   を備えることを特徴とする請求項１乃至５のいずれか１項に記載の方法。
7. 前記マッピングは、マッピングテーブルの中で定義される
   ことを特徴とする請求項６に記載の方法。
8. 前記マッピングは、時刻又は曜日に応じて変化する
   ことを特徴とする請求項６又は７に記載の方法。
9. 前記パケット検査器（１００）が、前記パケット検査制御データに基づいて前記サービス関連データトラヒックの前記データパケットをマーキングするステップ
   を備えることを特徴とする請求項６乃至８のいずれか１項に記載の方法。
10. ネットワークコンポーネントであって、
    データパケットのパケット検査を実行し、前記データパケットが特定の事前定義サービスに関係するということを識別し、前記識別されたデータパケットの中に識別子を含めることにより前記識別されたデータパケットをマーキングするように構成されたパケット検査器（１００）と、
    前記特定の事前定義サービスに関するサービス関連データトラヒックを示すパケット検査データをPolicy and Charging Rules Function（ＰＣＲＦ）（３０）へ送信するように構成されたパケット検査データインタフェース（５）であって、前記パケット検査データは前記識別されたデータパケットが関係する前記特定の事前定義サービスを示すサービス識別子を含む、パケット検査データインタフェース（５）と、
    を備え、
    前記ＰＣＲＦ（３０）は、前記パケット検査器（１００）を含む前記ネットワークコンポーネントとは別個のネットワークコンポーネントであり、
    前記パケット検査器（１００）は、移動通信ネットワークを介して前記ＰＣＲＦ（３０）に結合される
    ことを特徴とするネットワークコンポーネント。
11. 前記パケット検査器（１００）は、請求項１乃至９のいずれか１項に記載の方法の各ステップを実行するように構成される
    ことを特徴とする請求項１０に記載のネットワークコンポーネント。

Images