JP4970422B2 - パケット無線ネットワーク及び通信方法 - Google Patents

Description

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

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

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

本発明は、移動ユーザ機器（mobile user equipment）に／から、インターネットパケットを通信するパケット無線ネットワークを提供する。パケット無線ネットワークは、ゲートウェイサポートノードと、サービングサポートノードと、無線ネットワーク部（radio network part）とを備える。ゲートウェイサポートノードは、パケット無線ネットワークに対する移動ユーザ機器への／からの、パケット通信ベアラによるインターネットパケットの通信を制御するパケットデータプロトコルコンテキストを供給する。サービングサポートノードは、ゲートウェイサポートノードに接続され、ゲートウェイサポートノードに対する移動ユーザ機器への／からのインターネットパケットの通信を制御し、パケット通信ベアラを形成する。無線ネットワーク部は、移動ユーザ機器に／から無線アクセスインタフェースを介して、インターネットパケットを通信する無線アクセスベアラを提供する。サービングサポートノードは、共通パケットデータプロトコルコンテキスト（common packet data protocol context）を要求するパケットデータプロトコル起動要求メッセージ（packet data protocol activation request message）に応じて、ゲートウェイサポートノードと協働して、共通パケット通信ベアラ（common packet communications bearer）に関連する共通パケットデータプロトコルコンテキスト（common packet data protocol context）を確立する。共通パケットデータプロトコルコンテキストは、１つ以上の通信セッションに対して移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づくパケット通信ベアラを介して、インターネットプロトコルパケットを通信するように確立される。

本発明の実施の形態により、共通パケットデータプロトコルコンテキストタイプを提供することによって、インターネットプロトコルバージョンに固有のＧＰＲＳ／ＵＭＴＳ通信セッション管理によって課される制約を少なくすることにより、既存のパケット無線ネットワークの制限を解決することができる。

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

本発明の実施の形態は、移動ユーザ機器による指定に応じて、ＩＰｖ４インターネットパケット及びＩＰｖ６インターネットパケットの両方を送信する機能を移動ユーザ機器に与える。このような要求は、例えば、移動ユーザ機器がＩＰｖ４／ＩＰｖ６デュアルスタックの移動ユーザ機器である場合に生じる。更に、例示的な実施の形態に基づくパケット無線ネットワークは、高速／広帯域無線ベアラを含む共通パケット通信ベアラを用いる同じＧＰＲＳ／ＵＭＴＳ通信セッションを共有する構成を有する。通常、１つのゲートウェイサポートノード当たり、共通パケット通信ベアラは１つのみである。

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

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

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

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

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

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

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

既存のＧＰＲＳ／ＵＭＴＳ標準規格で定義されているように、ＧＰＲＳ／ＵＭＴＳ通信セッションを確立する既知のＰＤＰコンテキストの起動では、各ＧＰＲＳ／ＵＭＴＳ通信セッション／ＰＤＰコンテキストのＩＰタイプ（PDP Context IP type）を固有なものにすることができる以下の情報が要求される。
１．ＰＤＰコンテキスト起動要求は、ＰＤＰをどのタイプ、すなわちＰＰＰタイプ、ＩＰｖ４タイプ、ＩＰｖ６タイプに設定するかを示さなければならない。
２．ＰＤＰアドレス（PDP Address、ＩＰアドレス）を含むエンドユーザアドレスは、ＵＥが動的ＩＰアドレス割当を選択する場合、ＰＤＰコンテキストの設定の成功の結果として、インターネットプロトコルアドレスを割り当てるために空である必要がある。

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

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

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

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

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

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

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

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

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

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

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

共通ＰＤＰコンテキスト用のＴＦＴのパケットフィルタコンポーネントは、ＩＰタイプに固有ではない。既存の動作要求及びＴＦＴベースのオペレータの手順（例えば、セカンダリＰＤＰコンテキストの選択／ＱｏＳの差別化（secondary PDP Context selection/QoS differentiation））との相互運用性を最大にするために、本発明に基づいて、共通ＰＤＰアドレスタイプ及び共通ＰＤＰアドレス（common PDP Address）である２つの新たなフィールドが、ＴＦＴ情報要素内に組み込まれるように定義される。パケットフィルタコンポーネントの１つとして、共通ＰＤＰコンテキスト用の、共通ＰＤＰアドレスタイプフィールド（common PDP Address Type field）によって変更されたＴＦＴ情報要素は、以下のように定義される。
８７６５４３２１
００１１０００１ 共通ＰＤＰアドレスタイプ
０００１００００ ＩＰｖ４送信元アドレスタイプ
００１０００００ ＩＰｖ６送信元アドレスタイプ
００１１００００ プロトコル識別子／次ヘッダタイプ（Protocol identifier/Next header type）
０１００００００ シングル宛先ポートタイプ（Single destination port type）
０１０００００１ 宛先ポート範囲タイプ（Destination port range type）
０１０１００００ シングル送信元ポートタイプ（Single source port type）
０１０１０００１ 送信元ポート範囲タイプ（Source port range type）
０１１０００００ セキュリティパラメータインデクスタイプ（Security parameter index type）
０１１１００００ サービスタイプ／トラヒッククラスタイプ（Type of service/Traffic class type）
１０００００００ フローラベルタイプ（Flow label type）
ＵＥが、共通ＰＤＰコンテキストを使用するためのＴＦＴを生成する場合、ＵＥは、共通ＰＤＰアドレスタイプを「００１１０００１」に設定し、共通ＰＤＰアドレス自体のパケットフィルタコンポーネントの長さは、１６バイトである。共通ＰＤＰコンテキストをプライマリ／セカンダリＰＤＰコンテキスト（Primary/Secondary PDP Context）と区別するのに、宛先アドレスに基づくパケットフィルタが必要になる可能性があるので、共通ＰＤＰアドレスタイプは、最早送信元アドレスタイプを使用しない。ＵＥがＩＰｖ４パケットを送信及び受信する場合、ＰＤＰアドレスのパケットフィルタコンポーネントは、１６バイト長のＰＤＰアドレスパケットフィルタコンポーネントの下位の４バイトを使用し、上位の１２バイトは、「０」値で埋められる。ＵＥがＩＰｖ６パケットを送信及び受信する場合、ＰＤＰアドレスのパケットフィルタコンポーネントは、１６バイト長のパケットフィルタコンポーネントの全体を使用する。２つ以上のＵＥが共通ＰＤＰコンテキストを共有している状況の場合、対応して、共通ＰＤＰコンテキストに関連した２つ以上のＴＦＴがあり、各ＴＦＴは、入力パケットを共通ＰＤＰコンテキストに照合するために使用され、これは、共通ＰＤＰコンテキスト、プライマリＰＤＰコンテキスト及びセカンダリＰＤＰコンテキスト（後述）が共存するときに必要である。

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

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

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

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

入力パケットがＧＧＳＮに到着したときのＴＦＴベースの処理手順は、以下の通りである。
１．ＰＤＰ送信元アドレスタイプ（ＩＰｖ４の場合０００１００００、ＩＰｖ６の場合００１０００００）に対応する各ＴＦＴを確認し、一致するＰＤＰコンテキストが利用可能であるかを判定する。該当する場合、一致するＰＤＰコンテキスト（プライマリ又はセカンダリ）を用いてパケットを配信する。
２．処理１において、一致するＴＦＴが検出されなかった場合、共通ＰＤＰアドレスタイプ（００１１０００１）のＴＦＴを確認し、入力パケットの宛先アドレスがＴＦＴ内のパケットフィルタコンポーネントの１つに一致するかを判定する。該当する場合、一致するＰＤＰコンテキストを用いてパケットを配信する。
３．処理１及び処理２の何れにおいても一致するＴＦＴが検出されなかった場合、ＴＦＴがないＰＤＰコンテキストがあるかを判定する。該当する場合、このＰＤＰコンテキストを用いてパケットを配信し、この他の場合、パケットを破棄（discard）する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

既知のＩＭＳセッショントークン認証手順では、ＵＥが、共通ＧＰＲＳベアラを共有する通信セッションの認証を要求して、シングルトークン（single token）で、共有ＧＰＲＳベアラ（shared GPRS bearer）上に通信セッションを多重化する認証を受信する規定は存在しない。この目的で、階層的な認証機構（hierarchical authorisation mechanism）を提案し、この階層的な認証機構では、階層的認証トークン（hierarchical authorisation token）が、ポリシ決定ポイントとして機能するポリシサーバ３２４によって生成される。階層的認証トークンの具体例を図１９に示す。図１９に示す階層的認証トークンは、シングルトークンで、グループＩＭＳ通信セッション（group IMS communications session）又はシングルＩＭＳ通信セッション（single IMS communications session）を認証する。図１９に示すように、本発明に基づき、Ｐ−ＣＳＣＦ３１６又はポリシサーバ３２４によって生成される階層的認証トークンは、認証タイプフィールド４００と、グループＩＭＳセッション認証識別子フィールド４０２と、シングルＩＭＳセッション認証識別子フィールド４０４とを含む。認証タイプフィールド４００には、ＩＭＳ通信セッションが専用リソース／ＧＰＲＳベアラ（dedicated resource/GPRS bearer）を用いるか否か、又はＩＭＳ通信セッションが他のＩＭＳ通信セッション及びＵＥによって共有されるＧＰＲＳベアラを用いるか否かを識別する所定の値が格納される。認証タイプフィールド４００に格納される値の具体例は、以下の通りである。
０１：グループＩＭＳセッション認証識別子
１０：シングルＩＭＳセッション認証識別子
ＩＭＳ通信セッションが専用リソース／ＧＰＲＳベアラを用いる場合、グループＩＭＳセッション認証識別子フィールド４０２は、「０」に設定され、シングルＩＭＳセッション認証識別子フィールド４０４には、ＩＭＳ通信セッションに固有の認証トークンが格納される。通信セッションが他のＩＭＳ通信セッションとＧＰＲＳベアラを共有する場合、グループＩＭＳセッション認証識別子フィールド４０２には、そのセッションを定義する固有の認証値が格納され、シングルＩＭＳセッション認証識別子フィールド４０４は、「０」に設定される。上述のように、認証トークンは、ＵＥからの要求、例えば以下のＳＩＰ：ＩＮＶＩＴＥメッセージ（SIP: INVITE message）に応じて、ポリシサーバによって生成される。これに応じて、ポリシ決定ポイントとして機能するＰ−ＣＳＣＦ３１６は、ＩＭＳネットワーク内のＳ−ＣＳＣＦ３１２と通信する。そして、Ｓ−ＣＳＣＦ３１２は、ＨＳＳ３１４から加入者情報データを読み出して、共通ＧＰＲＳベアラを確立する認証が得られるか否かを判定する。認証される場合、適切な認証トークンがＵＥ３０２、３０４、３０６に発行される。

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

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

認証タイプフィールド４００の値が、認証されたセッションがシングルＩＭＳ通信セッションであることを示している場合、ＧＧＳＮ３０７は、専用ＧＰＲＳベアラを確立する。そして、ＧＧＳＮ３０７は、シングルＩＭＳセッション認証識別子を解析して、Ｐ−ＣＳＣＦ３１６（ポリシ決定ポイントとして機能する）に問い合わせ、ＩＭＳ３０８によるＩＭＳ通信セッション要求に対する認証を確認する。他の例として、図２０に示す構造の階層的認証トークンを生成してもよい。
図２０に示す具体例では、階層的認証トークンは、図１９に示す階層的認証トークンの認証タイプフィールド４００に対応する認証タイプフィールド４００を含む。なお、この具体例では、ＩＭＳセッション認証識別子を表すフィールド４０６は、１つだけであり、フィールド４０６は、グループＩＭＳセッション認証識別子とシングルＩＭＳセッション認証識別子との両方によって共有されなければならない。したがって、図２０に示す具体例は、簡単であるが、グループＩＭＳセッション識別子又はシングルＩＭＳセッション識別子のどちらかであるかを正しく識別するために、アドレス範囲を区切る必要がある。

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

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

Ｓ４：そして、Ｐ−ＣＳＣＦ３１６は、Ｓ−ＣＳＣＦ３１２と協働して、ＨＳＳ３１４から加入者情報データを読み出す。そして、Ｐ−ＣＳＣＦ３１６は、加入者情報データに基づいて、ユーザが共有ＩＭＳ通信セッション（shared IMS communications session）を受信する許可が与えられているか否か、この共有ＩＭＳ通信セッションが共通ＧＰＲＳベアラを介して提供できるか否かを判定する。そして、与えられている場合、Ｐ−ＣＳＣＦ３１６は、認証のタイプ（グループ又はシングル）と、共有ベアラ又は専用ベアラのセッション認証識別子を提供する認証トークンを生成して、ＧＧＳＮ３０７に渡す。

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

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

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

Ｓ１６：そして、Ｐ−ＣＳＣＦ３１６は、移動ユーザ機器３０２がＩＭＳセッション用の共通ＧＰＲＳベアラを受信する許可が与えられていることを確認する。

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

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

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

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

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

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

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

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

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

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

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

Claims (18)

1. 移動ユーザ機器に／から、インターネットパケットを通信するパケット無線ネットワークにおいて、
   当該パケット無線ネットワークに対する上記移動ユーザ機器への／からの、パケット通信ベアラによる上記インターネットパケットの通信を制御するパケットデータプロトコルコンテキストを供給するゲートウェイサポートノードと、
   上記ゲートウェイサポートノードに接続され、該ゲートウェイサポートノードに対する上記移動ユーザ機器への／からの上記インターネットパケットの通信を制御し、上記パケット通信ベアラを形成するサービングサポートノードと、
   上記移動ユーザ機器に／から無線アクセスインタフェースを介して、上記インターネットパケットを通信する無線アクセスベアラを提供する無線ネットワーク部とを備え、
   上記サービングサポートノードは、共通パケットデータプロトコルコンテキストを要求するパケットデータプロトコル起動要求メッセージに応じて、上記ゲートウェイサポートノードと協働して、上記パケット通信ベアラに関連する共通パケットデータプロトコルコンテキストを確立し、該共通パケットデータプロトコルコンテキストは、１つ以上の通信セッションに対して上記移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づく上記パケット通信ベアラを介して、インターネットプロトコルパケットを通信するように確立されることを特徴とするパケット無線ネットワーク。
2. 上記移動ユーザ機器から上記サービングサポートノードに通信される上記パケットデータプロトコル起動要求メッセージは、非固有インターネットプロトコルバージョンに基づいてインターネットパケットを通信する共通パケットデータコンテキストの要求を示す所定の値に設定された値を有するパケットデータプロトコルタイプ番号フィールドと、上記共通パケットデータプロトコルコンテキストを用いて上記インターネットパケットを通信する移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づくアドレスを表すアドレスフィールドとを有するエンドユーザアドレス情報要素を含むことを特徴とする請求項１記載のパケット無線ネットワーク。
3. 上記アドレスフィールドは、上記移動ユーザ機器によって指定することができるインターネットプロトコルバージョンのそれぞれのうちの最も長いアドレスに対応する長さを有し、
   上記移動ユーザ機器は、上記ゲートウェイサポートノードがインターネットプロトコルアドレスを供給する場合、該インターネットプロトコルアドレス内のキャラクタの数を、所定のキャラクタによって表すことによって、上記共通パケットデータプロトコルコンテキストで用いられるインターネットプロトコルバージョンに基づいてアドレスを表し、あるいは該インターネットプロトコルアドレスが該移動ユーザ機器によって指定される場合、該インターネットプロトコルアドレスを供給することを特徴とする請求項２記載のパケット無線ネットワーク。
4. 上記インターネットプロトコルアドレスを供給するアドレスフィールドは、ＩＰｖ４アドレスとＩＰｖ６アドレスの両方を入れることができる長さを有し、
   上記移動ユーザ機器が、上記ゲートウェイサポートノードに、ＩＰｖ４アドレスを供給することを要求する場合、該移動ユーザ機器は、上記インターネットプロトコルアドレスのアドレスフィールドの第１の部分を、ＩＰｖ４インターネットプロトコルアドレスのキャラクタが全部揃っていることを示す所定のキャラクタに設定し、その第２の部分を、キャラクタが必要でないことを示すように設定し、
   上記移動ユーザ機器が、ＩＰｖ６インターネットプロトコルアドレスを要求する場合、上記インターネットプロトコルアドレスのアドレスフィールドは、該アドレスフィールドがＩＰｖ６アドレスで満たされていることを示す所定のキャラクタに設定されることを特徴とする請求項３記載のパケット無線ネットワーク。
5. 上記移動ユーザ機器は、上記ゲートウェイサポートノード内に、上記共通パケットデータプロトコルコンテキスト用のトラヒックフローテンプレートを確立し、
   上記トラヒックフローテンプレートは、上記共通パケットデータプロトコルコンテキストのインターネットパケットが、非指定インターネットプロトコルアドレスバージョンに基づいて識別されることを表す共通パケットデータプロトコルアドレスタイプフィルタ識別子を含み、対応するアドレスパラメータは、上記移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づくアドレスを表すことを特徴とする請求項１乃至４何れか１項記載のパケット無線ネットワーク。
6. 上記トラヒックフローテンプレートの対応するアドレスパラメータは、上記移動ユーザ機器によって指定することができるインターネットプロトコルバージョンのそれぞれのうちの最も長いアドレスに対応する長さを有し、
   上記移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づくアドレスは、上記インターネットプロトコルアドレスで用いられない全てのキャラクタを所定の値に設定し、残りのキャラクタをパケットフィルタリングが実行されるアドレスに設定することによって表されることを特徴とする請求項５記載のパケット無線ネットワーク。
7. 上記ゲートウェイサポートノードは、上記移動ユーザ機器からの要求に応じて、プライマリ／セカンダリパケットデータプロトコルコンテキストを供給し、
   上記プライマリ／セカンダリパケットデータプロトコルコンテキスト及び上記共通パケットデータプロトコルコンテキスト毎にトラヒックテンプレートフィルタが確立されている場合、上記トラヒックフローテンプレートは、該プライマリ／セカンダリパケットデータプロトコルコンテキスト及び共通パケットデータプロトコルコンテキスト毎に確立された通信セッションのインターネットプロトコル宛先アドレスを含むように配置されることを特徴とする請求項５又は６記載のパケット無線ネットワーク。
8. 上記共通パケットデータプロトコルコンテキストは、複数の通信セッション間で共有され、該複数の通信セッションのそれぞれには、専用のトンネルプロトコルベアラを用いる異なるパケット通信ベアラが提供されることを特徴とする請求項１乃至７何れか１項記載のパケット無線ネットワーク。
9. 上記共通パケットデータプロトコルコンテキストは、複数の通信セッション間で共有され、該複数の通信セッションのそれぞれは、上記パケット無線ネットワークに亘って上記インターネットプロトコルパケットを通信する共通パケット通信ベアラを共有し、該共通パケット通信ベアラは、同じトンネルプロトコルベアラを用いることを特徴とする請求項１乃至７何れか１項記載のパケット無線ネットワーク。
10. 上記各通信セッションは、異なる移動ユーザ機器に供給されることを特徴とする請求項８又は９記載のパケット無線ネットワーク。
11. 移動ユーザ機器に／から、パケット無線ネットワークを介して、インターネットパケットを通信する通信方法において、
    上記パケット無線ネットワークに対する上記移動ユーザ機器への／からの、パケット通信ベアラによるインターネットパケットの通信を制御するパケットデータプロトコルコンテキストを、該パケット無線ネットワークのゲートウェイサポートノードによって供給するステップと、
    上記パケット無線ネットワークのサービングサポートノードによって、上記移動ユーザ機器への／からの上記インターネットパケットの通信を制御し、上記パケット通信ベアラを提供するステップと、
    上記移動ユーザ機器に／から無線アクセスインタフェースを介して、上記インターネットパケットを通信する無線アクセスベアラを、上記パケット無線ネットワークの無線ネットワーク部から提供するステップとを有し、
    上記パケットデータプロトコルコンテキストを供給するステップは、
    共通パケットデータプロトコルコンテキストを要求するパケットデータプロトコル起動要求メッセージに応じて、上記パケット通信ベアラに関連する共通パケットデータプロトコルコンテキストを確立するステップを含み、
    上記共通パケットデータプロトコルコンテキストは、１つ以上の通信セッションに対して上記移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づく上記パケット通信ベアラを介して、インターネットプロトコルパケットを通信するように確立されることを特徴とする通信方法。
12. 上記移動ユーザ機器から上記サービングサポートノードに通信される上記パケットデータプロトコル起動要求メッセージは、非固有インターネットプロトコルバージョンに基づいてインターネットパケットを通信する共通パケットデータプロトコルコンテキストの要求を示す所定の値に設定された値を有するパケットデータプロトコルタイプ番号フィールドと、上記共通パケットデータプロトコルコンテキストを用いて上記インターネットパケットを通信する移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づくアドレスを表すアドレスフィールドとを有するエンドユーザアドレス情報要素を含むことを特徴とする請求項１１記載の通信方法。
13. 上記アドレスフィールドは、上記移動ユーザ機器によって指定することができるインターネットプロトコルバージョンのそれぞれのうちの最も長いアドレスを収容することができる長さを有し、
    上記移動ユーザ機器は、上記ゲートウェイサポートノードが上記インターネットプロトコルアドレスを供給する場合、該インターネットプロトコルアドレス内のキャラクタの数を、所定のキャラクタによって表すことによって、上記共通パケットデータプロトコルコンテキストで用いられるインターネットプロトコルバージョンに基づいてアドレスを表し、あるいは該インターネットプロトコルアドレスが該移動ユーザ機器によって指定される場合、該インターネットプロトコルアドレスを供給することを特徴とする請求項１２記載の通信方法。
14. 上記ゲートウェイサポートノード内で上記共通パケットデータプロトコルコンテキスト用のトラヒックフローテンプレートを確立するステップを更に有し、
    上記トラヒックフローテンプレートは、上記共通パケットデータプロトコルコンテキストのインターネットパケットが、非指定インターネットプロトコルアドレスバージョンに基づいて識別されることを表す共通パケットデータプロトコルアドレスタイプフィルタ識別子を含み、対応するアドレスパラメータは、上記移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づくアドレスを表すことを特徴とする請求項１１乃至１３何れか１項記載の通信方法。
15. 上記トラヒックフローテンプレートの対応するアドレスパラメータは、上記移動ユーザ機器によって指定することができるインターネットプロトコルバージョンのそれぞれのうちの最も長いアドレスに対応する長さを有し、
    上記移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づくアドレスは、上記インターネットプロトコルアドレスで用いられない全てのキャラクタを所定の値に設定し、残りのキャラクタをパケットフィルタリングが実行されるアドレスに設定することによって表されることを特徴とする請求項１４記載の通信方法。
16. コンピュータにロードされて、請求項１１乃至１５何れか１項記載の通信方法を実行させるコンピュータ実行可能コードを有するコンピュータプログラム。
17. 請求項１６記載のコンピュータプログラムを格納した媒体。
18. 移動ユーザ機器に／から、パケット無線ネットワークを介して、インターネットパケットを通信する通信装置において、
    上記パケット無線ネットワークに対する上記移動ユーザ機器への／からの、パケット通信ベアラによるインターネットパケットの通信を制御するパケットデータプロトコルコンテキストを、該パケット無線ネットワークのゲートウェイサポートノードによって供給する手段と、
    上記パケット無線ネットワークのサービングサポートノードによって、上記移動ユーザ機器への／からの上記インターネットパケットの通信を制御し、上記パケット通信ベアラを提供する手段と、
    上記移動ユーザ機器に／から無線アクセスインタフェースを介して、上記インターネットパケットを通信する無線アクセスベアラを、上記パケット無線ネットワークの無線ネットワーク部から提供する手段とを備え、
    上記パケットデータプロトコルコンテキストを供給する手段は、
    共通パケットデータプロトコルコンテキストを要求するパケットデータプロトコル起動要求メッセージに応じて、上記パケット通信ベアラに関連する共通パケットデータプロトコルコンテキストを確立する手段を備え、
    上記共通パケットデータプロトコルコンテキストは、１つ以上の通信セッションに対して上記移動ユーザ機器によって指定されたインターネットプロトコルバージョンに基づく上記パケット通信ベアラを介して、インターネットプロトコルパケットを通信するように確立されることを特徴とする通信装置。

Images