JP5491650B2 - 移動ユーザ機器 - Google Patents

Description

本発明は、例えば、汎用パケット無線システム（General Packet Radio System：ＧＰＲＳ）に基づいて動作するパケット無線ネットワークを介してインターネットプロトコルパケットを通信する移動ユーザ機器に関する。

ＧＰＲＳは、無線アクセスインタフェースを介してインターネットパケットを通信するために開発された。ＧＰＲＳネットワークは、第２世代移動通信システム（Global System for Mobiles：ＧＳＭ）又は第３世代移動通信システム（Universal Mobile Telecommunications System：ＵＭＴＳ）バックボーンネットワークを用いて形成することができる。ＧＰＲＳは、パケット指向サービスをサポートし、パケットデータ通信、例えばインターネットパケット（Internet Packet：ＩＰ）用のネットワーク及び無線リソースを最適化するよう試みる。ＧＰＲＳは、移動無線システムの回線交換アーキテクチャに関連する論理アーキテクチャを提供する。

ＧＰＲＳ／ＵＭＴＳネットワークでは、各移動ユーザ機器は、データを送信及び受信するために、パケットデータプロトコル（ＰＤＰ）コンテキストによって表される少なくとも１つのＧＰＲＳ／ＵＭＴＳ通信セッションを設定する必要がある。各ＧＰＲＳ／ＵＭＴＳ通信セッションは、それぞれ、移動ユーザ機器に固有のセッションである。このように、移動ユーザ機器は、データを送信及び受信するために、それ自体に固有のＰＤＰコンテキストを用いる必要がある。更に、ＰＤＰコンテキストは、移動ユーザ機器がＧＰＲＳ／ＵＭＴＳ通信セッションを介して送信するインターネットデータパケットのタイプに固有である。移動ユーザ機器が確立したインターネットプロトコルの接続性のタイプに応じて、以下のように、３つの異なるタイプのＰＤＰコンテキストがある。
・ポイントツーポイントプロトコルタイプ
・インターネットプロトコルバージョン４（ＩＰｖ４）タイプ
・インターネットプロトコルバージョン６（ＩＰｖ６）タイプ
このインターネットプロトコルバージョンに固有のＰＤＰコンテキストは、移動ユーザ機器が、ＧＰＲＳ／ＵＭＴＳネットワークに亘ってＩＰｖ４インターネットパケットを送信する場合、ＩＰｖ４タイプのＰＤＰコンテキストを設定する必要があることを意味する。同様に、移動ユーザ機器は、ＧＰＲＳ／ＵＭＴＳネットワークに亘ってＩＰｖ６インターネットパケットを送信及び受信する場合、ＩＰｖ６タイプのＰＤＰコンテキストを設定する必要がある。このため、パケット無線ネットワーク上の通信リソースの利用効率を悪くする可能性がある。

本発明は、パケット無線ネットワークを介して、インターネットパケットを通信する移動ユーザ機器を提供する。移動ユーザ機器は、パケット無線ネットワークのゲートウェイサポートノードに対して、パケット無線ネットワークへの／からの、パケット通信ベアラによるインターネットパケットの通信を制御するパケットデータプロトコルコンテキストを供給する手段と、ゲートウェイサポートノードに接続されたパケット無線ネットワークのサービングサポートノードを用いて、インターネットパケットの通信を制御し、パケット通信ベアラを形成する手段と、パケット無線ネットワークの無線ネットワーク制御装置を用いて、移動ユーザ機器に／から無線アクセスインタフェースを介して、インターネットパケットを通信する無線アクセスベアラを提供する手段と、パケットデータプロトコル起動要求メッセージに応じて、共通パケットデータプロトコルコンテキストを要求する手段と、共通パケット通信ベアラに関連する共通パケットデータプロトコルコンテキストを確立する手段とを備える。共通パケットデータプロトコルコンテキストは、共通パケット通信ベアラによってインターネットプロトコルパケットを通信するように確立され、共通パケット通信ベアラは、共通トンネルプロトコルベアラを用いる少なくとも１つの他の通信セッションと共有される。ゲートウェイサポートノードは、複数の通信セッションのインターネットプロトコルパケットを共通パケット通信ベアラによって通信し、通信セッションの少なくとも１つは、他の通信セッションとは異なるインターネットプロトコルバージョンを用いる。

新たな無線アクセス技術の進歩により、例えば、高速無線リンク技術、例えば高速ダウンリンクパケットデータ（High Speed Downlink Packet Data：ＨＳＤＰＡ）及び高速アップリンクパケットデータ（High Speed Uplink Packet Data：ＨＳＵＰＡ）が利用可能になり、リソースの利用効率を高めるために、２つ以上のユーザ機器間で同じ無線ベアラを共有することが望ましくなっている。更に、ＩＰｖ６技術の急激な進歩により、端末機器及び装置、例えば移動ユーザ機器において、ＩＰｖ６がますます普及している。更に、既存のＩＰｖ４方式が存在するために、ＩＰｖ４／ＩＰｖ６デュアルインターネットプロトコルスタックを有する移動ユーザ機器の開発が促進されている。従来、ＩＰｖ４パケットは、ＩＰｖ４タイプのＰＤＰコンテキストによって配信しなければならず、一方、ＩＰｖ６パケットは、ＩＰｖ６タイプのＰＤＰコンテキストによって配信しなければならない。この結果、同じ高速／広帯域のＧＰＲＳベアラ（例えば、無線ベアラであるＨＳＤＰＡ／ＨＳＵＰＡ）を共有しなければ、リソースを効率的に利用することができない。更に、デュアルインターネットプロトコルＩＰｖ４及びＩＰｖ６スタックを有する移動ユーザ機器は、例えば、それぞれＩＰｖ４及びＩＰｖ６ベースのサービスに接続するＩＰｖ４及びＩＰｖ６パケットの両方を同時に送信する必要がある場合もある。しかしながら、既存のインターネットプロトコルタイプ固有のパケットデータプロトコルコンテキストは、移動ユーザ機器が、一方がＩＰｖ４タイプであり、他方がＩＰｖ６タイプである少なくとも２つのパケットデータプロトコルコンテキストを設定することを要求することがある。

本発明の実施の形態では、異なる通信セッション間で共有することができる共通パケット通信ベアラを提供することができるパケット無線ネットワークが提供される。この結果、２つ以上の通信セッションが共通の通信リソースを共有するので、高速広帯域通信、例えばＨＳＤＰＡを効率的にサポートすることができる。このように、例示的な実施の形態に基づくパケット無線ネットワークは、共通パケット通信ベアラを用いて、同じＧＰＲＳ／ＵＭＴＳ通信セッションを共有する構成を有し、共通パケットデータプロトコルコンテキストによってサポートされる。通常、１ゲートウェイサポートノード当たり、共通パケット通信ベアラは１つのみである。

共通ＰＤＰコンテキストは、パケットデータプロトコルに基づき、ＧＰＲＳネットワークに亘ってインターネットパケットを通信する共通パケット通信ベアラを確立する。パケットデータプロトコルの一部として、確立された共通パケット通信ベアラによってインターネットプロトコルパケットを通信するように配置するために、ポリシ実行、サービス品質（以下、ＱｏＳという。）及びルーティングが確立される。なお、共通ＰＤＰコンテキストは、あらゆるインターネットプロトコルバージョンに固有ではなく、更に、２つ以上の通信セッション間で共有することができる共通パケット通信ベアラを確立する。更に、通信セッションは、異なる移動ユーザ機器から開始されてもよい。

あるいは、他の具体例では、通信セッションは、別々のインターネットプロトコルベアラを用いてもよいが、２つ以上の通信セッションに対して１つの共通ＰＤＰコンテキストを確立してもよい。したがって、共通ＰＤＰコンテキストは、ＰＰＰデータフレームと、ＩＰｖ４及びＩＰｖ６パケットと、あるいは他のあらゆるインターネットプロトコルバージョン又は他のデータプロトコルを用いて通信されるパケットとに共通のＰＤＰコンテキストとして定義される。

ＧＰＲＳ／ＵＭＴＳの具体例では、ＧＰＲＳ／ＵＭＴＳネットワークを介する通信セッションは、共通ＰＤＰコンテキストによって確立することができ、共通パケット通信ベアラを確立する共通ＰＤＰコンテキストを用いて、ＰＰＰフレームと、ＩＰｖ４及びＩＰｖ６パケットと、データ転送プロトコル又は他のインターネットプロトコルバージョンに準拠するあらゆる他のフォーマットのデータパケットとを送信及び受信することができる。

本発明の様々な更なる側面及び特徴は、特許請求の範囲において定義されている。

ＧＰＲＳ／ＵＭＴＳ規格に準拠したパケット無線ネットワークを含む電気通信システムのブロック図である。 パケット通信ベアラによるインターネットパケットの通信を説明する、図１に示すＧＰＲＳ／ＵＭＴＳネットワークの単純化された表現を示すブロック図である。 移動ユーザ機器が共通パケットデータプロトコルコンテキストを設定する構成を示す、図２に示すＧＰＲＳ／ＵＭＴＳネットワークのブロック図である。 パケットデータプロトコル起動要求を実行する処理を説明するメッセージのフローチャートである。 共通パケットデータプロトコルコンテキストを設定する処理の更なる動作を示す、図３に示すＧＰＲＳ／ＵＭＴＳネットワークのブロック図である。 パケットデータプロトコル（ＰＤＰ）コンテキスト起動の一部として提供されるエンドユーザアドレス情報要素の略図である。 図６のエンドユーザ情報要素内のＰＤＰタイプ編成フィールドに格納される値のテーブルを示す図である。 ＩＰｖ４ＰＤＰコンテキストを確立するエンドユーザアドレス情報要素の略図である。 ＩＰｖ６ＰＤＰコンテキストを確立するエンドユーザアドレス情報要素の略図である。 移動ユーザ機器がＩＰｖ６を用いた通信を望んだ際に、共通パケットデータプロトコルコンテキストを確立するエンドユーザアドレス情報要素の略図である。 移動ユーザ機器がＩＰｖ４を用いた通信を望んだ際に、共通パケットデータプロトコルコンテキストを確立するエンドユーザアドレス情報要素の略図である。 トラヒックフローテンプレート情報要素の略図である。 共通ＧＰＲＳベアラを用いて通信することができる共通パケットデータプロトコルコンテキストを含むパケットデータプロトコルコンテキストを確立する複数の移動ユーザ機器を説明する、図３に示すＧＰＲＳ／ＵＭＴＳネットワークも略図である。 共通パケットデータプロトコルコンテキストを共有する図１３に示す２つの移動ユーザ機器に別々のＧＰＲＳベアラを提供する、図３及び図５に示すＧＰＲＳ／ＵＭＴＳネットワークの一部の略図である。 共通パケットデータプロトコルコンテキストを共有する図１３に示す２つの移動ユーザ機器への／からのインターネットプロトコル通信をサポートする共通ＧＰＲＳベアラを提供する、図３及び図５に示すＧＰＲＳ／ＵＭＴＳネットワークの一部の略図である。 無線アクセスベアラフィルタを用いて、共通パケットデータプロトコルコンテキスト及び共通のパケットデータプロトコルベアラを共有する２つの移動ユーザ機器にインターネットパケットを通信する無線ネットワーク制御装置の動作を説明する、図１５に示すＧＰＲＳ／ＵＭＴＳネットワークの一部の略図である。 ３つの移動ユーザ機器が１つのＩＭＳ通信セッションを共有しているインターネットプロトコルマルチメディアサブシステム（ＩＭＳ）を有する、図３及び図５に示す表現に対応したＧＰＲＳ／ＵＭＴＳネットワークの一部のブロック図である。 ＩＭＳを用いて通信する、メディア認証によって設定されたセッションを実行するために用いられる要素の一般的な表現のブロック図である。 シングルＩＭＳセッション又はグループＩＭＳセッションの何れかを認証するように適合された図１８に示すセッション認証手順の一部として生成される認証トークンの略図である。 シングルＩＭＳセッション又はグループＩＭＳセッションの何れかを認証するように適合された図１８に示すセッション認証手順の一部として生成される認証トークンの更なる具体例の略図である。 共通ＧＰＲＳベアラを共有するグループ通信セッションのためのセッション設定及び認証を実行する複数のモバイル機器の処理を示すメッセージのフローチャートである。

図１は、移動ユーザ機器（mobile user equipment：ＵＥ）２と、外部のパケットデータ網１５に接続された通信相手ノード（correspondent node：ＣＮ）１２との間でインターネットパケットを通信するＧＰＲＳ／ＵＭＴＳパケット無線ネットワーク（以下、単にＧＰＲＳネットワークという。）１のブロック図である。図１においては、ＵＥ２は、例えば、ユーザにマルチメディアサービスを提供するアプリケーションプログラムをホストする。図１には、ＧＰＲＳネットワーク１の構成要素であるゲートウェイＧＰＲＳサポートノード（gateway GPRS support node：ＧＧＳＮ、以下、単にゲートウェイサポートノードともいう。）３と、サービングＧＰＲＳサポートノード（serving GPRS support node：ＳＧＳＮ、以下、単にサービングサポートノードともいう。）４と、無線ネットワーク制御装置（radio network controller：ＲＮＣ）８とが示されている。図１に示すＧＰＲＳネットワーク１を単純化して表した図２に示すように、ＧＧＳＮ３及びＳＧＳＮ４は、一般的には、コアネットワーク（core network：ＣＮ）の一部を構成し、一方、ＲＮＣ８は、無線ネットワーク（radio network：ＲＮ）の一部を構成している。説明のための簡潔な形式として図２に示すように、ＧＰＲＳネットワーク１は、パケットデータコンテキストが確立されたインターネットプロトコルベアラ１４を提供している。後述するように、パケットデータプロトコルコンテキストは、ＵＥ２が契約しているサービス品質を提供する適切なベアラが確立されることを保証するとともに、ベアラの認証された使用を実行するプロトコルを提供する。インターネットプロトコルベアラ１４は、ユーザ機器（ＵＥ）２対し、ＧＰＲＳネットワーク１を介して通信相手ノード１２にインターネットパケットを搬送するために確立される。インターネットパケットは、ＧＰＲＳネットワーク１から、すなわちＧＧＳＮ３から、インターネットプロトコルベアラ１４が確立されたインターネットプロトコルと同じインターネットプロトコルに基づいて動作するパケットデータ網１５に送出される。

なお、ＧＰＲＳネットワーク１は、本発明が適用されるパケット無線ネットワークの一具体例である。このように、本明細書では、ＧＧＳＮ３は、より一般的には、ゲートウェイサポートノードと呼ぶことができ、ＳＧＳＮは、より一般的には、サービングサポートノードと呼ぶことができる。

［共通ＰＤＰコンテキスト］
移動ユーザ機器（ＵＥ）が共通ＰＤＰコンテキストを確立する本発明の具体例を図３に示す。図２にも示す部分には、対応する参照符号を付している。図３に示すように、ＵＥ２は、デュアルプロトコルスタックを有する。すなわち、ＵＥ２は、ＩＰｖ４インターネットプロトコルスタック２０と、ＩＰｖ６インターネットプロトコルスタック２２とを有する。したがって、ＵＥ２は、ＩＰｖ４及びＩＰｖ６に基づいて通信セッションをそれぞれ確立するＩＰｖ４アドレス及びＩＰｖ６アドレスの一方又は両方を用いることができる。このために、ＵＥ２は、矢印２４によって示すように、パケットデータプロトコル（packet data protocol：ＰＤＰ）コンテキスト起動要求をＳＧＳＮ４に送信する。ＧＰＲＳ規格に詳しい当業者には周知のように、ＰＤＰコンテキスト起動手順は、パケットデータプロトコルに基づいて、ＧＰＲＳネットワーク１に亘るベアラの起動のための適切な制御及びルーティングを確立する。図４は、ＰＤＰコンテキスト起動手順を示している。ＧＰＲＳベアラを確立した後のＰＤＰコンテキスト起動手順については、３ＧＰＰ仕様ＴＳ２４．２２９に開示されているので、詳細には説明しないが、そして、ＵＥ２は、トラヒックフローテンプレート（Traffic Flow Template：ＴＦＴ）１９を確立する情報を、ゲートウェイサポートノード（ＧＧＳＮ）３に通信する（図２にも示す）。後述するように、ＴＦＴ１９は、ＵＥ２によって確立された適切なＰＤＰコンテキストを識別するように構成され、着信パケットをフィルタリングして、ＧＰＲＳネットワーク１に亘る対応するインターネットパケットベアラを選択することができる。

既存のＧＰＲＳ／ＵＭＴＳ標準規格で定義されているように、ＧＰＲＳ／ＵＭＴＳ通信セッションを確立する既知のＰＤＰコンテキストの起動では、各ＧＰＲＳ／ＵＭＴＳ通信セッション／ＰＤＰコンテキストのＩＰタイプを固有なものにすることができる以下の情報が要求される。

１．ＰＤＰコンテキスト起動要求は、ＰＤＰをどのタイプ、すなわちＰＰＰタイプ、ＩＰｖ４タイプ、ＩＰｖ６タイプに設定するかを示さなければならない。

２．ＰＤＰアドレス（ＩＰアドレス）を含むエンドユーザアドレスは、ＵＥが動的ＩＰアドレス割当を選択する場合、ＰＤＰコンテキストの設定の成功の結果として、インターネットプロトコルアドレスを割り当てるために空である必要がある。

ＰＤＰタイプ及びＰＤＰアドレスの両方は、後述するエンドユーザアドレス情報要素（ＴＳ２９．０６０参照）でコード化される。

図５に示すように、この実施の形態では、ＩＰｖ４インターネットプロトコルパケット又はＩＰｖ６インターネットプロトコルパケットの何れか、あるいはＩＰｖ４インターネットプロトコルパケット及びＩＰｖ６インターネットプロトコルパケットの両方、あるいは他のあらゆるインターネットプロトコルバージョンのパケットをＵＥ２に／から通信する共通ＰＤＰコンテキストが確立される。このように、ＵＥ２は、ＩＰｖ６ソース３０又はＩＰｖ４ソース３２からインターネットパケットを、パケットデータ網（ＰＤＮ）１５を介して受信することができる。

上述のように、ＰＤＰコンテキストは、ＩＰｖ４アドレス及びＩＰｖ６アドレスの何れか、又はポイントツーポイントプロトコル（ＰＰＰ）アドレスタイプに対して確立される。ＩＰｖ４ベアラ及びＩＰｖ６ベアラの何れかを確立するために、移動ユーザ機器（ＵＥ）は、ＰＤＰコンテキストの一部として、特定のパラメータを識別する所定のバイト数のフィールドを含むエンドユーザアドレス情報要素を通信する。エンドユーザアドレス情報要素の一般的な形式の具体例を図６に示す。図６に示すように、フィールドの１つであるＰＤＰタイプ編成フィールド４０は、パケットデータプロトコル（ＰＤＰ）タイプ編成を提供し、更なるフィールドであるＰＤＰタイプ番号フィールド４２は、ＰＤＰタイプ番号を指定し、更なるフィールドであるＰＤＰアドレスフィールド４４は、ＰＤＰアドレスを指定する。現在の３ＧＰＰ仕様によれば、図６に示すエンドユーザアドレス情報要素のデータフィールド４０、４２が提供するＰＤＰタイプ編成値及びＰＤＰタイプ番号は、図７に示す通りであり、これは、既知の規格の一部であるので、これ以上は説明しない。

ＵＥ２がＩＰｖ４ベアラのＰＤＰコンテキストを起動する場合、図６のエンドユーザアドレス情報要素は、図８に示す形式に適合される。一方、ＵＥ２がＩＰｖ６ベアラのＰＤＰコンテキストを起動する場合、図６のエンドユーザアドレス情報要素は、図９に示す形式に適合される。図８及び図９に示すように、ＰＤＰタイプ編成フィールド４０は、図７に示すテーブルに基づき、１に設定される。ＩＰｖ４ＰＤＰコンテキストの場合、ＰＤＰタイプ番号フィールド４２の情報要素は、１６進数（２１）に設定される。ＩＰｖ６ＰＤＰコンテキストの場合、図９に示すエンドユーザアドレス情報要素では、また、ＰＤＰタイプ編成フィールド４０は、１を指定するが、ＰＤＰタイプ番号フィールド４２は、ベアラをＩＰｖ６ベアラとしなければならないことを示す１６進数（５７）を指定する。

ここで、ＩＰｖ６ＰＤＰコンテキスト及びＩＰｖ４ＰＤＰコンテキストを指定する２つの選択肢がある。ＵＥ２が、それ自体のＩＰｖ４アドレス又はＩＰｖ６アドレスを使用することを望む場合、エンドユーザアドレス情報要素は、ＰＤＰアドレスフィールド４４に、ＵＥ２によって入れられた特定のＩＰｖ４アドレス又はＩＰｖ６アドレスを含んでいる。一方、図２及び図３に示すように、ＵＥ２が使用するインターネットプロトコルアドレスを、ＰＤＰコンテキスト起動の一部として要求することができ、この場合、ＵＥ２は、ＤＨＣＰサーバ１７によってアドレスが供給される。したがって、この場合、ＵＥ２は、ＩＰアドレスを要求している。図８及び図９に示す各ＰＤＰアドレスフィールド４４は、空のままである（０バイトに設定されている）。

本実施の形態では、図３及び図５に示すように、移動ユーザ機器（ＵＥ）２は、共通ＰＤＰコンテキストを確立することができる。共通ＰＤＰコンテキストは、パケットデータプロトコルに基づき、ＧＰＲＳネットワーク１に亘って通信インターネットパケットを通信するベアラを確立する。パケットデータプロトコルの一部として、確立されたベアラによってインターネットパケットを通信するように配置するために、ポリシ実行、サービス品質及びルーティングが確立される。なお、共通ＰＤＰコンテキストは、あらゆるインターネットプロトコルバージョンに固有ではなく、更に、２つ以上の通信セッション間で共有することができるベアラを確立する。更に、通信セッションは、異なる移動ユーザ機器から開始されてもよい。あるいは、通信セッションは、別々のインターネットプロトコルベアラを用いてもよいが、２つ以上の通信セッションに対して共通ＰＤＰコンテキストを確立してもよい。したがって、共通ＰＤＰコンテキストは、ＰＰＰデータフレームと、ＩＰｖ４パケット及びＩＰｖ６パケットと、実際にはあらゆる他のデータプロトコルとに共通のＰＤＰコンテキストとして定義される。共通ＰＤＰコンテキストによるＧＰＲＳ／ＵＭＴＳ通信セッションを用いて、ＰＰＰフレームと、ＩＰｖ４及びＩＰｖ６パケットと、データ転送プロトコルに準拠したあらゆる他のフォーマットのデータパケットとを送信及び受信にすることができる。

共通ＰＤＰコンテキストによってＧＰＲＳ／ＵＭＴＳ通信セッションを設定する手順は、ＰＤＰタイプがヌルである点を除いて、上述した従来のＰＤＰコンテキストの場合と同様である。ＰＤＰタイプは、既存のＧＰＲＳ／ＵＭＴＳ通信セッション管理プロセスとの相互運用性を最大化するために、ヌルに設定される。ＵＥが動的ＩＰアドレス（ＩＰｖ４及びＩＰｖ６の何れか）を要求する場合、エンドユーザアドレス情報要素のＰＤＰアドレスは、既存のＧＰＲＳ／ＵＭＴＳ通信セッション設定プロセスにおいて定義されるので、実際には空のままにされる。実際に、このＩＰアドレス固有の要素により、複数のＵＥは、同じ共通ＰＤＰコンテキストを共有しながら、ＩＰｖ４パケット又はＩＰｖ６パケットの何れかを生成し、受信することができる。

本実施の形態では、共通ＰＤＰコンテキストは、ゲートウェイサポートノード３が共通ＰＤＰコンテキストを確立しなければならないことを識別する所定の値に設定されたＰＤＰタイプ番号を含むエンドユーザアドレス情報要素を用いる非固有インターネットプロトコルバージョンに対して確立される。一旦、ＰＤＰコンテキストが確立されると、ゲートウェイサポートノード３が共通ＰＤＰコンテキストの更なる要求を受信した場合、そのＰＤＰコンテキストが開始される通信セッションは、共通ＰＤＰコンテキストに加わる。なお、共通ＰＤＰコンテキストは、特定のインターネットプロトコルバージョンに固有ではないが、ＵＥ２は、更に、通信セッションが確立されるインターネットプロトコルバージョンに基づいて用いられるアドレスを指定する。このように、ＵＥ２は、例えばＩＰｖ４アドレス又はＩＰｖ６アドレスによって、共通ＰＤＰコンテキストを確立する。本実施の形態では、ＩＰｖ６の共通ＰＤＰコンテキスト用のエンドユーザアドレス情報要素は、ＰＤＰタイプ番号フィールド４２内の、例えば「ＮＵＬＬ（ヌル）」に設定された所定の文字を識別することによって、ＰＤＰタイプが共通であることを識別する。そして、ＰＤＰアドレスフィールド４４は、ＵＥ２が、それらが使用することを望むＩＰｖ６アドレスを指定している場合、ＩＰｖ６アドレスが入れられ、あるいはエンドユーザアドレス情報要素のバイト６〜２１に「ゼロ」が設定される（図１０参照）。このように、ゲートウェイサポートノード３は、指定されたアドレスを用いるＩＰｖ６アドレスに対して共通ＰＤＰコンテキストが確立されようとしていることを知っているか、あるいは、ＰＤＰアドレスフィールド４４がゼロに設定されている場合、ＤＨＣＰサーバ１７にＩＰｖ６アドレスを要求する。

一方、ＵＥ２がＩＰｖ４アドレスに対して共通ＰＤＰコンテキストを確立している場合、図１１に示すように、「ヌル」に設定されたＰＤＰタイプ番号フィールド４２によって、ＩＰｖ４アドレスは、ＰＤＰアドレスフィールド４４の下位の４バイトに設定される。残りの１２バイトは、「１」に設定される。これに代えて、移動ユーザ機器２がゲートウェイサポートノード３にＩＰｖ４アドレスを要求することを望む場合、下位の４バイトは、所定の値、例えば「０」に設定され、残りの１２バイトは、「１」に設定される。したがって、ゲートウェイサポートノード３は、ＩＰｖ４アドレスをＤＨＣＰサーバ１７からフェッチして、下位の４バイトにＩＰｖ４アドレスを入れる。

図２及び図３に関して上述したように、共通ＰＤＰコンテキストが一旦確立されると、ＵＥ２によって、ＧＧＳＮ３にトラヒックフローテンプレート（ＴＦＴ）１９が設定される。このために、ＰＤＰコンテキスト起動処理の一部として、トラヒックフローテンプレート情報要素が、ＵＥ２によってＧＧＳＮ３に送信される。図１２は、既知の３ＧＰＰ仕様に基づくトラヒックフローテンプレート情報要素の各フィールドを示している。図１２に示すように、トラフィックフローテンプレート情報要素のフィールドの１つであるパケットフィルタリストフィールド５０は、パケットフィルタリストを提供し、他のフィールドであるパラメータリストフィールド５２は、パラメータリストを提供する。パケットフィルタリストフィールド５０は、インターネットパケットがフィルタリングされることになっているパケットフィルタコンポーネントタイプ識別子を指定する。添付資料１は、パケットフィルタコンポーネントタイプ識別子の仕様を示している。これらは、ＩＰｖ４送信元アドレスタイプ、又はＩＰｖ６送信元アドレスタイプ、又は様々な他のパラメータを含んでいる。したがって、一旦、パケットフィルタリストフィールド５０にコンポーネントタイプが指定されると、そのコンポーネントタイプがフィルタリングされることになっているパラメータが、パラメータリストフィールド５２に指定される。

［共通ＰＤＰコンテキスト用のトラヒックフローテンプレート］
この実施の形態では、一旦、ＵＥが共通ＰＤＰコンテキストを確立すると、ＩＰパケットをフィルタリングし、共通ＰＤＰコンテキストを識別するパケットフィルタコンポーネントタイプ識別子が指定される。したがって、移動ユーザ機器は、共通ＰＤＰコンテキスト用のＴＦＴを確立する。このために、例えばビットパターン「００１１０００１」を有する更なるパケットフィルタコンポーネントタイプ識別子が確立される。したがって、一旦、ＵＥ用の共通ＰＤＰコンテキストが確立されると、そのＵＥに対して、共通ＰＤＰアドレスタイプ用のパケットフィルタコンポーネントを指定するＴＦＴが設定される。そして、共通ＰＤＰアドレスタイプをフィルタリングするパラメータは、共通ＰＤＰコンテキストを用いるために、移動ユーザ機器が指定したＩＰｖ４アドレス又はＩＰｖ６アドレスの何れかである。

共通ＰＤＰコンテキスト用のＴＦＴのパケットフィルタコンポーネントは、ＩＰタイプに固有ではない。ＴＦＴベースの演算子の既存の動作要求及び手順（例えばセカンダリＰＤＰコンテキストの選択／ＱｏＳの差別化）との相互運用性を最大にするために、本発明に基づいて、共通ＰＤＰアドレスタイプ及び共通ＰＤＰアドレスである２つの新たなフィールドが、ＴＦＴ情報要素内に組み込まれるように定義される。パケットフィルタコンポーネントの１つとして、共通ＰＤＰコンテキスト用の、共通ＰＤＰアドレスタイプフィールドによって変更されたＴＦＴ情報要素は、以下のように定義される。

８７６５４３２１
００１１０００１ 共通ＰＤＰアドレスタイプ
０００１００００ ＩＰｖ４送信元アドレスタイプ
００１０００００ ＩＰｖ６送信元アドレスタイプ
００１１００００ プロトコル識別子／次ヘッダタイプ
０１００００００ シングル宛先ポートタイプ
０１０００００１ 宛先ポート範囲タイプ
０１０１００００ シングル送信元ポートタイプ
０１０１０００１ 送信元ポート範囲タイプ
０１１０００００ セキュリティパラメータインデクスタイプ
０１１１００００ サービスタイプ／トラヒッククラスタイプ
１０００００００ フローラベルタイプ

ＵＥが、共通ＰＤＰコンテキストを使用するためのＴＦＴを生成するとき、ＵＥは、共通ＰＤＰアドレスタイプを「００１１０００１」に設定し、共通ＰＤＰアドレス自体のパケットフィルタコンポーネントの長さは、１６バイトである。共通ＰＤＰコンテキストをプライマリ／セカンダリＰＤＰコンテキストと区別するのに、宛先アドレスに基づくパケットフィルタが必要になる可能性があるので、共通ＰＤＰアドレスタイプは、最早送信元アドレスタイプを使用しない。ＵＥがＩＰｖ４パケットを送信及び受信する場合、ＰＤＰアドレスのパケットフィルタコンポーネントは、１６バイト長のＰＤＰアドレスパケットフィルタコンポーネントの下位の４バイトを使用し、上位の１２バイトは、「０」の値で埋められる。ＵＥがＩＰｖ６パケットを送信及び受信する場合、ＰＤＰアドレスのパケットフィルタコンポーネントは、１６バイト長のパケットフィルタコンポーネントの全体を使用する。２つ以上のＵＥが共通ＰＤＰコンテキストを共有している状況の場合、対応して、共通ＰＤＰコンテキストに関連した２つ以上のＴＦＴがあり、各ＴＦＴは、着信パケットを共通ＰＤＰコンテキストに照合するために使用され、これは、「共通ＰＤＰコンテキスト」、プライマリＰＤＰコンテキスト及びセカンダリＰＤＰコンテキスト（後述）が共存するときに必要である。

［他のＰＤＰコンテキストから共通ＰＤＰコンテキストを選択］
上述したように、幾つかのＵＥは、同時に有効な異なるタイプのＰＤＰコンテキストを有することができ、これらは、全てＧＧＳＮ３によって管理及び終了される。異なるＰＤＰコンテキストは、共通ＰＤＰコンテキストと、プライマリＩＰｖ４ＰＤＰコンテキスト又はプライマリＩＰｖ６ＰＤＰコンテキストと、セカンダリＩＰｖ４ＰＤＰコンテキスト又はセカンダリＩＰｖ６ＰＤＰコンテキストとすることができる（後者の２つは、３ＧＰＰ仕様に定義されている）。ＧＧＳＮ３に到着するパケットは、固有の要求、例えばサービス品質、課金、セキュリティ等のために、適切なＰＤＰコンテキストによって配信する必要がある。３ＧＰＰ仕様に定義されたＴＦＴは、パケットフィルタの組合せを用いて、プライマリＰＤＰコンテキストとセカンダリＰＤＰコンテキスト（ＩＰｖ４又はＩＰｖ６の何れか）を区別し、選択するために使用される。ＩＰｖ４パケットとＩＰｖ６パケットの両方を送信及び受信する複数のＵＥによって共有することができる共通ＰＤＰコンテキストの場合、共通ＰＤＰコンテキストを既存の規格によって定義されたプライマリ／セカンダリＰＤＰコンテキストと区別する２つの選択肢があり、これらについては、以下に説明する。

第１の選択肢では、ＴＦＴの組合せを用いることができる。共通ＰＤＰコンテキストを用いるＵＥのそれぞれは、上述したように、それ自体のＴＦＴを生成することができる。ＧＧＳＮ３に到着するパケットは、ＰＤＰアドレスパケットフィルタを用いる標準のＴＦＴの動作と同じ手順に従う。異なる点は、共通ＰＤＰコンテキストを使用／共有するＴＦＴは、上述したように、「００１１０００１」であるＰＤＰアドレスタイプコードを有する点である。（プライマリＰＤＰコンテキスト又はセカンダリＰＤＰコンテキストについて）１つの共通ＰＤＰコンテキストだけがあるとき、ＧＧＳＮ３に到着するインターネットプロトコルパケットは、共通ＰＤＰコンテキストをデフォルトとして用いて、適切なベアラを選択することによって、ＵＥ２に到達する。共通ＰＤＰコンテキストとプライマリＰＤＰコンテキストが共存するとき、且つ、プライマリＰＤＰコンテキストがＴＦＴを有さない場合、着信ＩＰパケットは、まず、共通ＰＤＰコンテキストに関連するＴＦＴに照合される。一致が検出されない場合、プライマリＰＤＰコンテキストは、ＴＦＴなしで使用される。

共通ＰＤＰコンテキストが、プライマリＰＤＰコンテキスト及びセカンダリＰＤＰコンテキストと共存するとき、これらは、それぞれ関連するＴＦＴを有し（特に、各ＰＤＰコンテキストに対して異なるサービス品質が要求されるときに、有用である）、着信インターネットプロトコルパケットは、ＴＦＴベースのパケットフィルタリングを用いて、共通ＰＤＰコンテキスト、プライマリＰＤＰコンテキスト又はセカンダリＰＤＰコンテキストに照合することができる。これは、共通ＰＤＰコンテキストに関連するＴＦＴとプライマリ／セカンダリＰＤＰコンテキストのＴＦＴ間でパケットフィルタパラメータが重複するために、パケットヘッダ情報が、どのＰＤＰコンテキストを使用するかを区別するためには不十分であるからである。このため、第２の選択肢を用いてもよい。

共通ＰＤＰコンテキストに用いられるＴＦＴをプライマリ／セカンダリＰＤＰコンテキストのＴＦＴと区別するために異なるＰＤＰアドレスタイプを使用することに加えて、共通ＰＤＰコンテキスト、プライマリＰＤＰコンテキスト及びセカンダリＰＤＰコンテキストが共存しているとき、着信パケットを配信するために、どのＰＤＰコンテキストを用いるかを決定する余分な情報が必要である。第２の選択肢では、インターネットプロトコルパケットの宛先アドレス（ＩＰｖ４又はＩＰｖ６の何れか）が、共通ＰＤＰコンテキストに用いられるパケットフィルタコンポーネントの１つとして加えられる。この結果、ＵＥが、共通ＰＤＰコンテキストを起動し又は共通ＰＤＰコンテキストに加わるとき、ＵＥは、「００１１０００１」のＰＤＰアドレスタイプと、それ自体のＩＰアドレス（ＩＰｖ４又はＩＰｖ６の何れか）を用いるパケットフィルタコンポーネントとを有するＴＦＴを生成する。

着信パケットがＧＧＳＮ３に到着したときのＴＦＴベースの処理手順は、以下の通りである。

１．ＰＤＰ送信元アドレスタイプ（ＩＰｖ４の場合０００１００００、ＩＰｖ６の場合００１０００００）に対応する各ＴＦＴを確認し、一致するＰＤＰコンテキストが利用可能であるかを判定する。該当する場合、一致するＰＤＰコンテキスト（プライマリ又はセカンダリ）を用いてパケットを配信する。

２．処理１において、一致するＴＦＴが検出されなかった場合、共通ＰＤＰアドレスタイプ（００１１０００１）のＴＦＴを確認し、着信パケットの宛先アドレスがＴＦＴ内のパケットフィルタコンポーネントの１つに一致するかを判定する。該当する場合、一致するＰＤＰコンテキストを用いてパケットを配信する。

３．処理１及び処理２の何れにおいても一致するＴＦＴが検出されなかった場合、ＴＦＴがないＰＤＰコンテキストがあるかを判定する。該当する場合、このＰＤＰコンテキストを用いてパケットを配信し、この他の場合、パケットを破棄する。

［共通ＰＤＰコンテキストの確立／共通ＰＤＰコンテキストへの参加］
共通ＰＤＰコンテキストは、２つ以上のＵＥによって共有することができるので、共通ＰＤＰコンテキストを起動するＵＥは、既に確立されていれば、（静的又は動的に設定された）既存の共通ＰＤＰコンテキストに参加するだけでよい。

［共通ＰＤＰコンテキストによるＧＰＲＳ／ＵＭＴＳ通信セッションの変更］
既存のＧＰＲＳ／ＵＭＴＳ標準規格（ＴＳ２３．０６０）で定義されている処理と同じ処理を用いて、通信セッションを変更することができる。なお、他のＵＥによって使用されている既存の共通ＰＤＰコンテキストを変更する代わりに、ＵＥは、まず、共通ＰＤＰコンテキストから離脱する必要があり、異なる共通ＰＤＰコンテキストを開始又は参加することを選択してもよい。

［共通ＰＤＰコンテキストからの離脱又は共通ＰＤＰコンテキストの削除］
既存のＧＰＲＳ／ＵＭＴＳ標準規格に定義されているＰＤＰコンテキストを削除する処理と同じ処理を、共通ＰＤＰコンテキストに対しても用いることができる。なお、他のＵＥによって共通ＰＤＰコンテキストがまだ用いられている場合、共通ＰＤＰコンテキストは解放されない。共通ＰＤＰコンテキストを削除しようとするＵＥは、そのＴＦＴを削除し、関連するＧＴＰ＿Ｃ／ＧＴＰ＿Ｕトンネルを解放することによってこの共通ＰＤＰコンテキストから離脱する。

［異なるＰＤＰコンテキストの共存の具体例］
図１３は、複数のＵＥがＰＤＰコンテキストを確立した構成の具体例を示している。この具体例では、複数のＵＥのうちの２つのＵＥが共通ＰＤＰコンテキストを確立している。図１３に示すように、この具体例では、３つのＵＥである移動ユーザ機器ＵＥａ、ＵＥｂ、ＵＥｃが、ＧＰＲＳネットワーク１を介してインターネットプロトコルパケットを通信している。２つの移動ユーザ機器ＵＥａ、ＵＥｂは、共通ＧＰＲＳベアラ９０を確立している。例えば、第１の移動ユーザ機器ＵＥａは、上述のように、ＰＤＰコンテキストとして共通ＰＤＰコンテキストを指定するＰＤＰコンテキスト起動要求を実行することによって、共通ＧＰＲＳベアラ９０を確立することができる。そして、ＧＧＳＮ３は、第１の移動ユーザ機器ＵＥａ用の共通ＰＤＰコンテキスト１００ａを確立する。そして、第１の移動ユーザ機器ＵＥａは、ＧＧＳＮ３と協働して、パラメータリストに共通ＰＤＰアドレスタイプを含むトラヒックフローテンプレート（ＴＦＴａ）１０２を確立する。図１３に示す具体例では、第１の移動ユーザ機器ＵＥａは、その通信セッションに用いるインターネットプロトコルアドレスを、ＩＰｖ４アドレスとすることを指定する。したがって、ＴＦＴａ１０２によって指定される共通ＰＤＰアドレスタイプは、ＴＦＴａ１０２のパラメータリスト１０４に示すように、ＩＰｖ４アドレスである。

また、第２の移動ユーザ機器ＵＥｂは、ＧＧＳＮ３と協働して、共通ＰＤＰコンテキストを設定する。共通ＰＤＰコンテキスト１００ａが、第１の移動ユーザ機器ＵＥａによって既に確立されているので、ＧＧＳＮ３は、第２の移動ユーザ機器ＵＥｂを共通ＰＤＰコンテキスト１００ｂに参加させる。なお、別の共通ＰＤＰコンテキスト１００ｂは、第２の移動ユーザ機器ＵＥｂ用のＴＦＴであるＴＦＴｂ１０６に関連付けられている。また、ＴＦＴｂ１０６は、パケットフィルタコンポーネントが共通ＰＤＰアドレスタイプであることを指定し、第２の移動ユーザ機器ＵＥｂの場合、ＩＰｖ６アドレスが、フィルタコンポーネントとしてフィールド１０８に指定される。このように、各移動ユーザ機器ＵＥａ、ＵＥｂ、ＵＥｃは、それ自体のＴＦＴを確立する。一方、第３の移動ユーザ機器ＵＥｃは、それ自体の専用ＧＰＲＳベアラ１１２用の従来のプライマリＰＤＰコンテキスト起動を要求する。図１３には、１つの専用ＧＰＲＳベアラ１１２だけしか示していないが、第３の移動ユーザ機器ＵＥｃは、ＩＰパケットをＧＰＲＳベアラによって通信するセカンダリＰＤＰコンテキスト１１３を確立することもできる。第３の移動ユーザ機器ＵＥｃの場合、パケットをフィルタリングするために、従来の構成に基づいて、ＴＦＴｃ１１４がプライマリＰＤＰコンテキスト１１０又はセカンダリＰＤＰコンテキスト１１３に対して確立される。したがって、図１３に示すように、２つの移動ユーザ機器ＵＥａ、ＵＥｂは、それぞれ、それ自体の専用のトラヒックフローテンプレート（ＴＦＴａ）１０２、（ＴＦＴｂ）１０６を有するが、共通ＰＤＰコンテキスト１００を用いる共通ＧＰＲＳベアラ９０を介して、通信を行っている。他の構成においては、第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂは、別々のＧＰＲＳベアラ９０、１１２を確立し、共通ＰＤＰコンテキストを共有する場合であっても、これらの別々のＧＰＲＳベアラ９０、１１２によって、インターネットパケットを通信することができる。

［共通ＧＰＲＳベアラ］
図１３に示す構成における第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂの場合、共有の共通ＰＤＰコンテキストを用い、ＧＰＲＳネットワーク１を介して通信する２つの可能なシナリオがある。１つの具体例を図１４に示す。図１４では、ＧＧＳＮ３は、第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂ毎に別々のＧＰＲＳトンネルプロトコル（GPRS Tunnelling Protocol：ＧＴＰ）ベアラＧＴＰ＿Ｕａ、ＧＴＰ＿Ｕｂを確立する。図１４に示すように、第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂは、共通ＰＤＰコンテキストを共有するが、インターネットプロトコルパケットは、別々のＧＴＰベアラＧＴＰ＿Ｕａ、ＧＴＰ＿Ｕｂによって、ＧＰＲＳネットワーク１に亘って通信される。インターネットプロトコルパケットが、無線アクセスベアラ（Radio Access Bearer：ＲＡＢ）によって通信するＲＮＣ８に到達したとき、別々のＧＴＰベアラＧＴＰ＿Ｕａ、ＧＴＰ＿Ｕｂは、対応する無線アクセスベアラＲＡＢａ、ＲＡＢｂにマッピングされる。したがって、無線アクセスベアラＲＡＢａ、ＲＡＢｂ及び第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂ毎に確立されたＧＴＰベアラＧＴＰ＿Ｕａ、ＧＴＰ＿Ｕｂのそれぞれは、異なるサービス品質ＱｏＳａ、ＱｏＳｂを指定することができる。したがって、無線アクセスベアラとＧＴＰベアラ間には、一対一のマッピングが存在する。すなわち、図１４は、共通ＰＤＰコンテキストであるが、異なるＧＰＲＳベアラを用いる具体例である。

図１５は、共通ＰＤＰコンテキストを確立した第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂが共通ＧＰＲＳベアラを利用する他の構成を示している。このように、ＧＧＳＮ３によって確立されたＧＴＰベアラは、区別されない。すなわち、ＧＰＲＳベアラは、第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂ間で共有される。インターネットパケットを、ＲＮＣ８によって確立された無線アクセスインタフェースを介し、ＧＰＲＳネットワーク１に亘って正しく通信するために、ＲＮＣ８は、インターネットプロトコルパケットが第１の移動ユーザ機器ＵＥａ又は第２の移動ユーザ機器ＵＥｂのどちら宛てかを識別しなければならない。このために、ＲＮＣ８は、無線アクセスベアラフィルタ２００を備える。無線アクセスベアラフィルタ２００は、ＧＴＰベアラＧＴＰ＿Ｕからインターネットパケットを受信し、２つの無線アクセスベアラＲＡＢａ、ＲＡＢｂのうちの、インターネットパケットを第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂに／からそれぞれ通信するのに適した１つを識別する。インターネットパケットを適切な無線アクセスベアラＲＡＢａ、ＲＡＢｂ上に正しく通過するために、ＲＡＢフィルタ２００には、第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂの宛先アドレスが供給される。したがって、図１５に示すように、ＲＡＢフィルタ２００は、ＧＴＰ部によって受信されるインターネットプロトコルパケット２０２のヘッダ２０４における宛先アドレスを識別する。ＲＡＢフィルタ２００は、第１又は第２の移動ユーザ機器ＵＥａ、ＵＥｂの宛先アドレスに基づいて、インターネットプロトコルパケット２０２を、対応する第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂに配信するのに適した無線アクセスベアラに通過する。

［共通ＧＰＲＳベアラ上で異なるサービス品質の提供］
図１６は、共通ＧＰＲＳベアラによるインターネットパケットの通信に異なるサービス品質を提供できる構成の具体例を示している。例えば、ある通信セッションは、ウェブ閲覧に基づいてインターネットパケットを通信し、一方、他の通信セッションは、ボイスオーバインターネットプロトコルに基づいてインターネットパケットを通信することができる。ＩＥＴＦインターネットプロトコル規格内で提供される差別化サービス（differential service）のサービス品質（ＱｏＳ）クラスを、ＧＰＲＳコアネットワークに亘る通信のための適切なサービス品質にマッピングすることによって、本発明に基づき、サービス品質を異ならせることができる。ＩＥＴＦインターネットプロトコル規格ｖ６、ｖ４に詳しい当業者には明らかなように、ＩＥＴＦインターネットプロトコル規格によって提供される差別化サービスのＱｏＳは、優先転送（Expedited Forwarding：ＥＦ）、帯域保証転送（Assured Forwarding：ＡＦ）及びベストエフォート（Best Effort：ＢＥ）の３つのカテゴリを有している。図１６に示すように、第１の移動ユーザ機器ＵＥａ又は第２の移動ユーザ機器ＵＥｂに通信されているインターネットパケットＩＰａ２２０、ＩＰｂ２２４は、ＧＧＳＮ３で受信される。インターネットパケットＩＰａ２２０、ＩＰｂ２２４のそれぞれのヘッダには、差別化サービスのＱｏＳが示されている。図１６に示す具体例では、第１の移動ユーザ機器宛の第１のインターネットパケットＩＰａ２２０用の差別化サービスのＱｏＳは、ＥＦであり、第２の移動ユーザ機器宛の第２のインターネットパケットＩＰｂ２２４用の差別化サービスのＱｏＳは、ＡＦである。ＧＧＳＮ３は、差別化サービスのサービス品質ＥＦ、ＡＦを、コアネットワークを亘ってＲＮＣ８までの通信に適したサービス品質ＱｏＳａ、ＱｏＳｂにマッピングするＧＴＰフィルタを形成する。ＧＴＰベアラＧＴＰ＿Ｕによって提供されるサービス品質ＱｏＳａ、ＱｏＳｂは、ＩＥＴＦインターネットプロトコル規格に基づくサービス品質ＥＦ、ＡＦと同じであってもよく、あるいは、サービス品質クラスにおける他の差別化サービスのサービス品質であってもよい。そして、第１及び第２のインターネットパケットＩＰａ２２０、ＩＰｂ２２４は、ＩＰトランスポートレイヤ２４６を介してＲＮＣ８に通信される。

図１６に示すように、コアネットワークの構成要素であるＧＧＳＮ３とＳＧＳＮ４間の通信と、ＲＮＣ８への通信は、異なるプロトコルレベルによって行われる。これらは、高いレベルのエンドツーエンドインターネットプロトコルレベル２４０と、ＧＴＰ＿Ｕインターネットプロトコルレベル２４２と、ＵＤＰレイヤ２４４と、インターネットプロトコルトランスポートレイヤ２４６とである。したがって、ＧＧＳＮ３は、第１及び第２の移動ユーザ機器ＵＥａ、ＵＥｂのそれぞれに通信する各パケットのヘッダで識別される差別化サービス品質ＡＦ、ＥＦから識別されるサービス品質ＱｏＳａ、ＱｏＳｂを用いて、インターネットパケットをインターネットプロトコルトランスポートレイヤ２４６を介して通信する。

ＲＮＣ８でインターネットパケットが受信されたとき、ＲＡＢフィルタ２００は、図１５に関して説明した方法で動作し、インターネットプロトコルトランスポートレイヤ２４６のそれぞれからのパケットが適切な無線アクセスベアラＲＡＢａ、ＲＡＢｂを通過する。適切な無線アクセスベアラＲＡＢａ、ＲＡＢｂは、第１又は第２の移動ユーザ機器ＵＥａ、ＵＥｂの宛先アドレスによって識別される。この実施の形態では、移動ユーザ機器（ＵＥ）は、共通ＰＤＰコンテキストが確立されたときに、ＲＡＢフィルタ２００を確立する。したがって、各移動ユーザ機器（ＵＥ）は、ＴＦＴを確立する方法に類似した方法で、ＲＡＢフィルタ２００に適切なコンポーネントを設定し、それによって、ＩＰトランスポートレイヤ２４６から受信されたインターネットパケットを、適切な無線アクセスベアラにフィルタリングすることができる。

［ＩＭＳセッション多重化の認証のサポート］
図１７は、上述したように、ＧＧＳＮ３０７と、ＳＧＳＮ３０９と、ＲＮＣ３１１と、ノードＢ３１５とを含むＧＰＲＳネットワークを介する通信セッションのために、３つの移動ユーザ機器（ＵＥ）３０２、３０４、３０６によって用いられる共通ＧＰＲＳベアラ３００の具体例を示している。図１７に示すように、ＵＥ３０２、３０４、３０６は、インターネットプロトコルマルチメディアサブシステム３０８によって提供される共通マルチメディア通信セッションを共有することを望む。インターネットプロトコルマルチメディアサブシステム（ＩＭＳ）３０８は、セッション開始プロトコル（ＳＩＰ）サーバ３１０と、サービング呼状態制御機能（Serving-Call State Control Function：Ｓ−ＣＳＣＦ）３１２と、ホーム加入者サーバ（Home Subscriber Server：ＨＳＳ）３１４とを備える。ＩＭＳ３０８は、更に、プロキシ呼状態制御機能（proxy call state control function：Ｐ−ＣＳＣＦ）３１６を含む。

移動ユーザ機器３０２は、ＳＩＰメッセージをＳＩＰサーバ３１０に送信することによって、ＩＭＳ通信セッションを開くことができる。これは、ＳＩＰ：ＩＮＶＩＴＥメッセージをＰ−ＣＳＣＦ３１６に送信することによって確立される。Ｐ−ＣＳＣＦ３１６は、ＩＭＳ３０８のポリシ決定ポイントを形成し、したがって、ＨＳＳ３１４内に保持されている加入者情報に関する要求を解析する。要求が承認された場合、Ｐ−ＣＳＣＦ３１６は、ＵＥ３０２がＩＭＳ通信セッションに適したベアラを用いることを認証する認証トークンを発行する。この認証トークンは、３ＧＰＰ技術仕様ＴＳ２３．２２８、ＴＳ２３．２０７に基づいて生成される。

図１８は、上述した３ＧＰＰ技術仕様で確立されるＩＭＳ認証手順を説明している。図１８は、ＵＥ３０２からの要求に応じて認証トークンを生成する処理及び発行された認証トークンに基づく以後の通信セッションの実行の一般的な表現を示している。図１８に示すように、１つのＵＥ３０２は、ＩＭＳ通信セッションの認証を要求する。ＵＥ３０２は、ベアラの要求３２０をポリシ実行ポイント３２２に送信する。ポリシ実行ポイント３２２は、ベアラを要求するトークンを、ポリシサーバ３２４であるポリシ決定ポイントに転送する。そして、ポリシサーバ３２４は、移動ユーザ機器３０２が、ＧＰＲＳネットワーク上の適切なベアラを用いて、ＩＭＳ通信セッションを開く権利を与えられているか否かを判定する。そして、ポリシサーバ３２４であるポリシ決定ポイントは、要求を受け入れる場合、通信セッションの認証を表す認証トークンを生成し、この認証トークンをポリシ実行ポイント３２２に通信する。そして、ポリシ実行ポイント３２２は、適切なＩＭＳベアラをＵＥ３０２に提供できることを、ＵＥ３０２に通知する。このように、移動ユーザ機器３０２がポリシ実行ポイント３２２に適切なベアラを要求したとき、トークンを用いて、ベアラが、認証されて、移動ユーザ機器３０２に提供される。

図１７に示す構成では、ＧＧＳＮ３０７が、認証を与え、ＩＭＳ通信セッションをサポートする適切なベアラを確立するポリシ実行ポイントとして機能する。なお、図１７では、移動ユーザ機器３０２、３０４、３０６が、共通ＧＰＲＳベアラ３００に亘ってＩＭＳ通信セッションを確立することを望んでいる。

既知のＩＭＳセッショントークン認証手順では、ＵＥが、共通ＧＰＲＳベアラを共有する通信セッションの認証を要求して、シングルトークンで、共有ＧＰＲＳベアラ上に通信セッションを多重化する認証を受信する規定は存在しない。この目的で、階層的な認証機構を提案し、この認証機構では、階層的認証トークンが、ポリシ決定ポイントとして機能するポリシサーバによって生成される。階層的認証トークンの具体例を図１９に示す。図１９に示す階層的認証トークンは、シングルトークンで、グループＩＭＳ通信セッション又はシングルＩＭＳ通信セッションを認証する。図１９に示すように、本発明に基づき、Ｐ−ＣＳＣＦ３１６又はポリシサーバ３２４によって生成される階層的認証トークンは、認証タイプフィールド４００と、グループＩＭＳセッション認証識別子フィールド４０２と、シングルＩＭＳセッション認証識別子フィールド４０４とを含む。認証タイプフィールド４００には、ＩＭＳ通信セッションが専用リソース／ＧＰＲＳベアラを用いるか否か、又はＩＭＳ通信セッションが他のＩＭＳ通信セッション及びＵＥによって共有されるＧＰＲＳベアラを用いるか否かを識別する所定の値が格納される。認証タイプフィールド４００に格納される値の具体例は、以下の通りである。

０１：グループＩＭＳセッション認証識別子
１０：シングルＩＭＳセッション認証識別子

ＩＭＳ通信セッションが専用リソース／ＧＰＲＳベアラを用いる場合、グループＩＭＳセッション認証識別子フィールド４０２は、「０」に設定され、シングルＩＭＳセッション認証識別子フィールド４０４には、ＩＭＳ通信セッションに固有の認証トークンが格納される。通信セッションが他のＩＭＳ通信セッションとＧＰＲＳベアラを共有する場合、グループＩＭＳセッション認証識別子フィールド４０２には、そのセッションを定義する固有の認証値が格納され、シングルＩＭＳセッション認証識別子フィールド４０４は、「０」に設定される。上述のように、認証トークンは、ＵＥ３０２からの要求、例えば以下のＳＩＰ：ＩＮＶＩＴＥメッセージに応じて、ポリシサーバ３２４によって生成される。これに応じて、ポリシ決定ポイントとして機能するＰ−ＣＳＣＦ３１６は、ＩＭＳネットワーク内のＳ−ＣＳＣＦ３１２と通信する。そして、Ｓ−ＣＳＣＦ３１２は、ＨＳＳ３１４から加入者情報データを読み出して、共通ＧＰＲＳベアラを確立する認証が得られるか否かを判定する。認証される場合、適切な認証トークンがＵＥ３０２、３０４、３０６に発行される。

通信セッションを確立するＰＤＰコンテキスト起動手順に基づき、ＵＥ３０２、３０４、３０６のそれぞれは、ＩＭＳセッション認証識別子を提供する階層的認証トークンを、ＧＧＳＮ３０７に送信する。そして、ＧＧＳＮ３０７は、認証タイプフィールド４００をチェックして、通信セッションがグループセッションであるか、シングルセッションであるかを判定する。

認証タイプフィールド４００の値が、認証されたセッションが共有ＧＰＲＳベアラ上のグループＩＭＳ通信セッションであることを示している場合、ＧＧＳＮ３０７は、共通ＧＰＲＳベアラを確立する。そして、ＧＧＳＮ３０７は、グループＩＭＳセッション認証識別子を解析し、Ｐ−ＣＳＣＦ３１６（ポリシ実行ポイントとして機能する）に問い合わせて、ＩＭＳ３０８によるＩＭＳ通信セッション要求に対する認証を確認する。

認証されたセッションがシングルＩＭＳ通信セッションであることを認証タイプフィールド４００の値が示している場合、ＧＧＳＮ３０７は、専用ＧＰＲＳベアラを確立する。そして、ＧＧＳＮ３０７は、シングルＩＭＳセッション認証識別子を解析し、Ｐ−ＣＳＣＦ３１６（ポリシ実行ポイントとして機能する）に問い合わせて、ＩＭＳ３０８によるＩＭＳ通信セッション要求に対する認証を確認する。

他の例として、階層的認証トークンは、図２０に示すような構成によって生成してもよい。図２０の階層的認証トークンは、図１９に示す具体的な認証トークンの認証タイプフィールド４００に対応した認証タイプフィールド４００を含んでいる。なお、ＩＭＳセッション認証識別子を表すフィールド４０６は、１つだけであり、フィールド４０６は、グループ認証識別子とシングル認証識別子との両方によって共有されなければならない。したがって、図２０に示す具体例は、簡単であるが、グループＩＭＳセッション識別子又はシングルＩＭＳセッション識別子を正しく識別するために、アドレス範囲を区切る必要がある。

移動ユーザ機器３０２からの要求に応じて、認証トークンを生成及び通信するメッセージフローを図２１に示し、以下に説明する。

Ｓ２：移動ユーザ機器３０２からＰ−ＣＳＣＦ３１６にＳＩＰ：ＩＮＶＩＴＥメッセージが送信される。

Ｓ４：そして、Ｐ−ＣＳＣＦ３１６は、Ｓ−ＣＳＣＦ３１２と協働して、ＨＳＳ３１４から加入者情報データを読み出す。そして、Ｐ−ＣＳＣＦ３１６は、加入者情報データに基づいて、ユーザが共有ＩＭＳ通信セッションを受信する許可が与えられているか否か、この共有ＩＭＳ通信セッションが共通ＧＰＲＳベアラによって提供できるか否かを判定する。

Ｓ６：そして、許可されている場合、Ｐ−ＣＳＣＦ３１６は、認証のタイプ（グループ又はシングル）と、共有ベアラ又は専用ベアラのセッション認証識別子とを提供する認証トークンを生成して、ＧＧＳＮ３０７に渡す。

Ｓ８：そして、ＧＧＳＮ３０７は、認証トークンを移動ユーザ機器３０２に渡す。

Ｓ１０：そして、移動ユーザ機器３０２は、認証トークンをプロトコル構成オプションフィールドの一部として提供するＰＤＰコンテキスト起動要求を設定する。

Ｓ１２：ＳＧＳＮ３０９は、ＰＤＰコンテキスト起動要求を受信して、認証トークンをＧＧＳＮ３０７に渡す。そして、ＧＧＳＮ３０７は、Ｐ−ＣＳＣＦ３１６によるセッション認証識別子を確認することによって、移動ユーザ機器３０２が他の移動ユーザ機器と共通の通信セッションを確立する権限を有するかを確認する。

Ｓ１６：そして、Ｐ−ＣＳＣＦ３１６は、移動ユーザ機器３０２がＩＭＳ通信セッション用の共通ＧＰＲＳベアラを受信する権限を有するかを確認する。

Ｓ１７：そして、ＧＧＳＮ３０７は、共通ＧＰＲＳベアラを確立し、移動ユーザ機器３０２に、共通ＧＰＲＳベアラが割り当てられたことを通知する。

本発明の様々な更なる側面及び特徴は、特許請求の範囲に定義されている。

上述した本発明の実施の形態は、例示的なものであり、本発明の範囲から逸脱することなく、これらの実施の形態を様々に変更することができる。例えば、ＧＰＲＳ／ＵＭＴＳは、本発明が適用されるアーキテクチャの一例に過ぎないことは明らかである。

添付資料１
パケットフィルタコンテンツフィールドは、可変長であり、パケットフィルタコンポーネントの（少なくとも１つの）変数を含む。各パケットフィルタコンポーネントは、連続した１バイトのパケットフィルタコンポーネントタイプ識別子及び固定長のパケットフィルタコンポーネント値フィールドとしてコード化されなければならない。パケットフィルタコンポーネントタイプ識別子が、最初に送信されなければならない。

各パケットフィルタにおいては、２つ以上のパケットフィルタコンポーネントタイプが出現してはならない。１つのパケットフィルタには、「ＩＰｖ４送信元アドレスタイプ」及び「ＩＰｖ６送信元アドレスタイプ」のパケットフィルタコンポーネントのうちの唯１つが存在しなければならない。また、１つのパケットフィルタには、「シングル宛先ポートタイプ」及び「宛先ポート範囲タイプ」のパケットフィルタコンポーネントのうちの唯１つが存在しなければならない。また、１つのパケットフィルタには、「シングル送信元ポートタイプ」及び「送信元ポート範囲タイプ」のパケットフィルタコンポーネントのうちの唯１つが存在しなければならない。

［パケットフィルタコンポーネントタイプ識別子］
ビット
８７６５４３２１
０００１００００ ＩＰｖ４送信元アドレスタイプ
００１０００００ ＩＰｖ６送信元アドレスタイプ
００１１００００ プロトコル識別子／次ヘッダタイプ
０１００００００ シングル宛先ポートタイプ
０１０００００１ 宛先ポート範囲タイプ
０１０１００００ シングル送信元ポートタイプ
０１０１０００１ 送信元ポート範囲タイプ
０１１０００００ セキュリティパラメータインデクスタイプ
０１１１００００ サービスタイプ／トラヒッククラスタイプ
１０００００００ フローラベルタイプ
他の全ての値は、予備である。

「ＩＰｖ４送信元アドレスタイプ」の場合、パケットフィルタコンポーネント値フィールドは、連続した４バイトのＩＰｖ４アドレスフィールド及び４バイトのＩＰｖ４アドレスマスクフィールドとしてコード化されなければならない。ＩＰｖ４アドレスフィールドが、最初に送信されなければならない。「ＩＰｖ６送信元アドレスタイプ」の場合、パケットフィルタコンポーネント値フィールドは、連続した１６バイトのＩＰｖ６アドレスフィールド及び１６バイトのＩＰｖ６アドレスマスクフィールドとしてコード化されなければならない。ＩＰｖ６アドレスフィールドが、最初に送信されなければならない。「プロトコル識別子／次ヘッダタイプ」の場合、パケットフィルタコンポーネント値フィールドは、ＩＰｖ４プロトコル識別子又はＩＰｖ６の次ヘッダを指定する１バイトとしてコード化されなければならない。

「シングル宛先ポートタイプ」及び「シングル送信元ポートタイプ」の場合、パケットフィルタコンポーネント値フィールドは、ポート番号を指定する２バイトとしてコード化されなければならない。「宛先ポート範囲タイプ」及び「送信元ポート範囲タイプ」の場合、パケットフィルタコンポーネント値フィールドは、連続した２バイトのポート範囲下限フィールド及び２バイトのポート範囲上限フィールドとしてコード化されなければならない。ポート範囲下限フィールドが、最初に送信されなければならない。

「セキュリティパラメータインデクス」の場合、パケットフィルタコンポーネント値フィールドは、ＩＰＳｅｃセキュリティパラメータインデクスを指定する４バイトとしてコード化されなければならない。「サービスタイプ／トラヒッククラスタイプ」の場合、パケットフィルタコンポーネント値フィールドは、連続した１バイトのサービスタイプ／トラヒッククラスフィールド及び１バイトのサービスタイプ／トラヒッククラスマスクフィールドとしてコード化されなければならない。サービスタイプ／トラヒッククラスタイプが、最初に送信されなければならない。

「フローラベルタイプ」の場合、パケットフィルタコンポーネント値フィールドは、ＩＰｖ６フローラベルを指定する３バイトとしてコード化されなければならない。第１バイトのビット８〜５は、予備であり、残りの２０ビットがＩＰｖ６フローラベルを含む。

Claims (6)

1. パケット無線ネットワークを介して、インターネットパケットを通信する移動ユーザ機器において、
   上記パケット無線ネットワークのゲートウェイサポートノードに対して、上記パケット無線ネットワークへの／からの、パケット通信ベアラによるインターネットパケットの通信を制御するパケットデータプロトコルコンテキストを供給する手段と、
   上記ゲートウェイサポートノードに接続された上記パケット無線ネットワークのサービングサポートノードを用いて、インターネットパケットの通信を制御し、上記パケット通信ベアラを形成する手段と、
   上記パケット無線ネットワークの無線ネットワーク制御装置を用いて、上記移動ユーザ機器に／から無線アクセスインタフェースを介して、上記インターネットパケットを通信する無線アクセスベアラを提供する手段と、
   パケットデータプロトコル起動要求メッセージに応じて、共通パケットデータプロトコルコンテキストを要求する手段と、
   共通パケット通信ベアラに関連する上記共通パケットデータプロトコルコンテキストを確立する手段とを備え、
   上記共通パケットデータプロトコルコンテキストは、上記共通パケット通信ベアラによってインターネットプロトコルパケットを通信するように確立され、該共通パケット通信ベアラは、共通トンネルプロトコルベアラを用いる少なくとも１つの他の通信セッションと共有され、
   上記ゲートウェイサポートノードは、複数の通信セッションのインターネットプロトコルパケットを上記共通パケット通信ベアラによって通信し、該通信セッションの少なくとも１つは、他の通信セッションとは異なるインターネットプロトコルバージョンを用いることを特徴とする移動ユーザ機器。
2. 上記ゲートウェイサポートノードは、上記サービングサポートノードを介する該ゲートウェイサポートノードと上記無線ネットワーク制御装置間に、上記共通パケット通信ベアラを確立し、上記共通トンネルプロトコルベアラは、該共通パケット通信ベアラを共有している移動ユーザ機器毎の共通トンネルエンドポイント識別子を用いて形成されることを特徴とする請求項１記載の移動ユーザ機器。
3. 上記共通トンネルプロトコルベアラは、インターネットプロトコルトランスポートレイヤによってサポートされており、該共通トンネルプロトコルベアラは、上記通信セッションのそれぞれに基づいて通信されるインターネットパケットのヘッダで供給される差別化サービス品質クラスに基づいて、当該共通トンネルプロトコルベアラを共有している通信セッションのそれぞれにサービス品質を提供するように配置されていることを特徴とする請求項１又は２記載の移動ユーザ機器。
4. 上記無線ネットワーク制御装置は、上記移動ユーザ機器によって確立された通信セッションに基づき、当該移動ユーザ機器に／からインターネットパケットを通信するために確立された無線アクセスベアラのうちの１つを識別する無線アクセスベアラフィルタを含み、該無線アクセスベアラフィルタは、該移動ユーザ機器に通信するインターネットパケットの宛先アドレスから、該確立された通信セッションに対応する無線アクセスベアラを識別することを特徴とする請求項１〜３いずれか１項記載の移動ユーザ機器。
5. 上記通信セッションの識別された上記対応する無線アクセスベアラに関するインターネットパケットの宛先アドレスは、上記移動ユーザ機器によって上記無線アクセスベアラフィルタに供給されることを特徴とする請求項４記載の移動ユーザ機器。
6. 上記無線アクセスベアラのそれぞれは、当該移動ユーザ機器によって確立された通信セッションにサービス品質を提供することを特徴とする請求項４又は５記載の移動ユーザ機器。

Images