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

Abstract

モバイルユーザ機器への及び／又はモバイルユーザ機器からのインターネットパケットを通信する設備を提供するパケット無線ネットワークを提供する。パケット無線ネットワークは、ゲートウェイサポートノード、サービスサポートノード及び無線ネットワークコントローラを備える。サービスサポートノードは、共通のパケットデータプロトコルコンテキストを要求するパケットデータプロトコルアクティブ化要求メッセージに応じて、ゲートウェイサポートノードと協働して、共通のパケット通信ベアラに関連付けられた共通のパケットデータプロトコルコンテキストを確立する。共通のパケットデータプロトコルコンテキストは、共通のパケット通信ベアラを介してインターネットプロトコルパケットを通信するように確立される。共通のパケット通信ベアラは、少なくとも１つの他の通信セッションと共有され、ゲートウェイサポートノード及びサービスサポートノードによって、共通のトンネルプロトコルベアラを用いて形成される。これにより、異なる通信セッション間で共有できる共通の通信ベアラを提供できるパケット無線ネットワークが提供される。この結果、２つ以上の通信セッションが共通の通信リソースを共有するので、ＨＳＤＰＡ等の高速広帯域通信を効率的にサポートできる。

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：ＣＮ）１２との間でインターネットパケットを通信するＧＰＲＳ／ＵＭＴＳパケット無線ネットワーク１（以下、単にＧＰＲＳネットワーク１と言う。）のブロック図である。図１においては、ＵＥ２は、例えば、ユーザにマルチメディアサービスを提供するアプリケーションプログラムをホストするよう構成されている。図１には、ＧＰＲＳネットワークの要素であるＧＰＲＳゲートウェイサービスノード（serving GPRS support node：ＧＧＳＮ）３、ＧＰＲＳサポートノード（ＳＧＳＮ）４、及び無線ネットワークコントローラ（radio network controller：ＲＮＣ）８が示されている。図１に示すＧＰＲＳネットワークを単純化して表現する図２に示すように、ＧＧＳＮ３及びＳＧＳＮ４は、多くの場合、コアネットワークＣＮの一部を構成し、無線ネットワークコントローラＲＮＣ８は、無線ネットワークＲＮの一部を構成する。説明のための簡潔な形式として図２に示すように、ＧＰＲＳネットワーク１は、パケットデータコンテキストが確立されたインターネットプロトコルベアラ１４を提供する。後述するように、パケットデータプロトコルコンテキストは、ＵＥ２が加入しているサービス品質を提供する適切なベアラが確立されることを確実にし、ベアラの使用に許可を要求するためにプロトコルを提供する。インターネットプロトコルベアラ１４は、ユーザ機器ＵＥ２から、ＧＰＲＳネットワークを介して通信相手ノードにインターネットパケットを搬送するために確立される。ＧＰＲＳネットワーク１からのインターネットパケットは、ＧＧＳＮ３からインターネットプロトコルベアラが確立されたインターネットプロトコルと同じインターネットプロトコルに基づいて動作するパケットデータネットワーク１５に送信される。

なお、ＧＰＲＳは、本発明が適用されるパケット無線ネットワークの１つの具体例である。したがって、本明細書では、ＧＧＳＮは、より包括的にゲートウェイサポートノードと呼んでもよく、ＳＧＳＮは、より包括的にサービスサポートノードと呼んでもよい。

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

既存のＧＰＲＳ／ＵＭＴＳ標準仕様で定義されている、ＧＰＲＳ／ＵＭＴＳセッションを確立するための既知のＰＤＰコンテキストアクティブ化では、各ＧＰＲＳ／ＵＭＴＳセッション／ＰＤＰコンテキストＩＰタイプを固有なものにする以下の情報が要求される。
１．ＰＤＰコンテキストアクティブ化要求は、ＰＰＰタイプ、ＩＰｖ４タイプＩＰｖ６タイプ等、如何なるタイプのＰＤＰをセットアップするかを示す必要がある。
２．ＰＤＰアドレス（ＩＰアドレス）を含むエンドユーザアドレスは、ＵＥが動的ＩＰアドレス割当を選択した場合、ＰＤＰコンテキストのセットアップの成功の結果としてインターネットプロトコルアドレスを割り当てるために空である必要がある。

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

図５に示すように、この実施の形態では、ＩＰｖ４インターネットプロトコルパケット又はＩＰｖ６パケットの何れか、ＩＰｖ４インターネットプロトコルパケット及びＩＰｖ６インターネットプロトコルパケットの両方、若しくは、他の何らかのインターネットプロトコルバージョンパケットをＵＥ２に／から通信するために、共通のＰＤＰが確立される。すなわち、ＵＥ２は、パケットデータネットワークＰＤＮを介して、ＩＰｖ６ソース３０又はＩＰｖ４ソース３２からインターネットパケットを受信できる。

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

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

ここで、ＩＰｖ６コンテキスト及びＩＰｖ４ＰＤＰコンテキストを指定するために２つの代替例がある。ＵＥ２が、自らのＩＰｖ４アドレス又はＩＰｖ６アドレスを使用することを望む場合、エンドユーザアドレス情報要素は、ＵＥが、特定されたＩＰｖ４アドレス又はＩＰｖ６アドレスを埋めたＩＰアドレスフィールド４４にＩＰｖ４アドレス及びＩＰｖ６アドレスの何れかを格納し、一方、図２及び図３に示すように、ＵＥが使用するインターネットプロトコルアドレスは、ＰＤＰコンテキストアクティブ化の一部として要求でき、この場合、ＤＨＣＰサーバがアドレスを提供する。したがって、この場合、ＵＥは、ＩＰアドレスを要求している。図８及び図９に示す各ＰＤＰアドレスフィールド４４は、空のままである（０バイトに設定されている）。

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

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

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

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

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

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

共通のＰＤＰコンテキストのためのＴＦＴにおけるパケットフィルタコンポーネントは、ＩＰタイプに固有ではない。既存の動作要求及びＴＦＴベースのオペレータの手続き（例えば、セカンダリＰＤＰコンテキスト選択／ＱｏＳ差異化）との相互運用性を最大化するために、共通のＰＤＰアドレスタイプ及び共通のＰＤＰアドレスである２つの新たなフィールドが本発明に基づくＴＦＴ情報要素に組み込まれるように定義される。パケットフィルタコンポーネントの１つとして共通のＰＤＰアドレスタイプフィールドを有する共通のＰＤＰコンテキストのための変更されたＴＦＴ情報要素は、以下のように定義される。
８７６５４３２１
００１１０００１ 共通のＰＤＰアドレスタイプ
０００１００００ ＩＰｖ４ソースアドレスタイプ
００１０００００ ＩＰｖ６ソースアドレスタイプ
００１１００００ プロトコル識別子／次のヘッダタイプ
０１００００００ 単一の宛先ポートタイプ
０１０００００１ 宛先ポート範囲タイプ
０１０１００００ 単一のソースポートタイプ
０１０１０００１ ソースポート範囲タイプ
０１１０００００ セキュリティパラメータインデクスタイプ
０１１１００００ サービスのタイプ／トラヒッククラスタイプ
１０００００００ フローラベルタイプ
ＵＥが共通のＰＤＰコンテキストを使用するためのＴＦＴを生成する場合、ＵＥは、共通のＰＤＰソースアドレスタイプを「００１１０００１」に設定し、共通のＰＤＰアドレス自体のためのパケットフィルタコンポーネントの長さは、１６バイトである。プライマリ／セカンダリＰＤＰコンテキストから共通のＰＤＰコンテキストを区別するために、宛先アドレスに基づくパケットフィルタが必要になる場合があるため、共通のＰＤＰアドレスタイプは、ソースアドレスタイプを使用しなくなる。ＩＰｖ４パケットを送受信するＵＥについては、ＰＤＰアドレスのためのパケットフィルタコンポーネントは、１６バイト長のＰＤＰアドレスパケットフィルタコンポーネントの下位４バイトを占め、上位１２バイトは、「０」値で埋められる。ＩＰｖ６パケットを送受信するＵＥについては、ＰＤＰアドレスのためのパケットフィルタコンポーネントは、１６バイト長のパケットフィルタコンポーネントの全体を占める。２つ以上のＵＥが共通のＰＤＰコンテキストを共有する状況では、対応する２つ以上のＴＦＴが共通のＰＤＰコンテキストに関連付けられ、各ＴＦＴは、供給されるパケットを共通のＰＤＰコンテキストに照合するために使用され、これは、共存する「共通のＰＤＰコンテキスト」であるプライマリＰＤＰコンテキスト及びセカンダリＰＤＰコンテキスト（後述）がある場合に必要である。

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

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

共通のＰＤＰコンテキストがプライマリＰＤＰコンテキスト及びセカンダリＰＤＰコンテキストと共存する場合、これらはそれぞれ関連するＴＦＴを有し（各ＰＤＰコンテキストについて異なるサービスの品質が要求される場合に特に有用）、供給されるインターネットプロトコルパケットは、ＴＦＴに基づくパケットフィルタリングを用いて、共通のＰＤＰコンテキスト、若しくはプライマリ又はセカンダリＰＤＰコンテキストに照合される。これは、共通のＰＤＰコンテキストに関連するＴＦＴと、プライマリ／セカンダリＰＤＰコンテキストのＴＦＴとの間でパケットフィルタパラメータが重複するために、パケットヘッダ情報が、どのＰＤＰコンテキストを使用するかを識別するために不十分であるからである。このため、以下に説明するような第２の手法を用いてもよい。

共通のＰＤＰコンテキストのために用いられるＴＦＴをプライマリ／セカンダリＰＤＰコンテキストから区別するために異なるＰＤＰアドレスタイプを使用することに加えて、共通のＰＤＰコンテキスト、プライマリＰＤＰコンテキスト及びセカンダリＰＤＰコンテキストが共存している場合、どのＰＤＰコンテキストを用いて供給されるパケットを提供するかを決定するために、追加的情報が必要である。第２の手法では、インターネットプロトコルパケット宛先アドレス（ＩＰｖ４又はＩＰｖ６の何れか）が、共通のＰＤＰコンテキストのために用いられるパケットフィルタコンポーネントの１つとして加えられる。この結果、ＵＥが、共通のＰＤＰコンテキストをアクティブ化し又は共通のＰＤＰコンテキストに参加する場合、ＵＥは、ＰＤＰアドレスタイプが「００１１０００１」であり、パケットフィルタコンポーネントが自らのＩＰアドレス（ＩＰｖ４又はＩＰｖ６の何れか）を用いるＴＦＴを生成する。

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

共通のＰＤＰコンテキストの確立／共通のＰＤＰコンテキストへの参加
共通のＰＤＰコンテキストは、２つ以上のＵＥで共有できるので、共通のＰＤＰコンテキストをアクティブ化するＵＥは、既に確立されていれば、（静的又は動的にセットアップされた）既存の共通のＰＤＰコンテキストに参加するだけでよい。

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

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

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

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

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

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

共通のＧＰＲＳベアラにおける異なるサービス品質の提供
図１６は、共通のＧＰＲＳベアラを介するインターネットパケットの通信に異なるサービス品質を提供できる構成の具体例を示している。例えば、ある通信セッションは、ウェブブラウズに基づいてインターネットパケットを通信でき、他の通信セッションは、ボイスオーバインターネットプロトコルに基づいてインターネットパケットを通信できる。この技術に基づき、ＩＥＴＦインターネットプロトコル規格が提供する個別のサービス品質（ＱｏＳ）クラスを、ＧＰＲＳコアネットワークに亘る通信のための適切なサービス品質にマッピングすることによって、異なったサービス品質が実現される。インターネットプロトコル規格ｖ６、ｖ４の分野で周知のように、ＩＥＴＦ規格が提供する異なるサービスＱｏＳは、最優先転送（Expedited Forwarding：ＥＦ）、相対的優先転送（Assured Forwarding：ＡＦ）及びベストエフォート（Best Effort：ＢＥ）の３つのカテゴリを有している。図１６に示すように、第１又は第２のユーザ機器ＵＥａ、ＵＥｂの何れかに通信されているインターネットパケットＩＰａ２２０、ＩＰｂ２２４はＧＧＳＮ３が受け取る。各インターネットパケットＩＰａ２２０、ＩＰｂ２２４のそれぞれのヘッダには、異なるサービスＱｏＳが示されている。図１６に示す具体例では、第１のユーザ機器ＩＰａ２２０に宛てられている第１のインターネットパケットに固有のサービスＱｏＳは、ＥＦであり、第２のユーザ機器ＩＰｂ２２４に宛てられている第２のインターネットパケットに固有のサービスＱｏＳは、ＡＦである。ＧＧＳＮ３は、コアネットワークを介するＲＮＣへの通信のために、異なるサービスＱｏＳであるＥＦ及びＡＦを、サービスＱｏＳａ、ＱｏＳｂの適切な品質にマッピングするように動作するＧＴＰフィルタを形成する。ＧＴＰ＿Ｕによって提供されるサービス品質ＱｏＳａ、ＱｏＳｂは、ＩＥＴＦ規格に基づくＥＦ及びＡＦと同じであってもよく、これに代わるサービス品質クラスの代替であってもよい。第１及び第２のインターネットパケットＩＰａ２２０、ＩＰｂ２２４は、トランスポートＩＰ層を介してＲＮＣに通信される。

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

ＲＮＣがインターネットパケットを受信する場合、ＲＡＢフィルタ２００は、図１５に関して説明した処理に対応する処理を行い、各インターネットプロトコルトランスポートレイヤから適切な無線アクセスベアラＲＡＢａ、ＲＡＢｂにパケットを渡す。適切な無線アクセスベアラは、第１又は第２のユーザ機器ＵＥａ、ＵＥｂの宛先アドレスによって特定される。この実施の形態では、ＵＥは、共通のＰＤＰコンテキストが確立されたとき、ＲＡＢフィルタを確立する。したがって、各ＵＥは、ＴＦＴを確立する場合と同様の手法で、トランスポートＩＰ層から受信したインターネットパケットを適切な無線アクセスベアラにフィルタリングすることができるように、ＲＡＢフィルタ内の適切なコンポーネントをセットアップする。

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

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

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

図１７に示す構成では、ＧＧＳＮ３が認証を提供し、ＩＭＳセッションをサポートするために適切なベアラを確立するポリシ強制ポイントとして機能する。なお、図１７では、モバイルユーザ機器３０２、３０４、３０６が共通のＧＰＲＳベアラに亘ってＩＭＳセッションを確立することを望んでいる。

既知のＩＭＳセッショントークン認証手続きでは、ＵＥが共通のＧＰＲＳベアラを共有する通信セッションのための認証を要求し、及び単一のトークンで共有されたＧＰＲＳベアラ上で多重化された通信セッションのための認証を受け取るための規定は存在しない。この目的で、ポリシ決定ポイントとして機能するポリシサーバによって階層的な認証トークンを生成する階層的な認証メカニズムを提案する。階層的な認証トークンの具体例を図１９に示す。図１９に示す階層的な認証トークンは、単一のトークンで、ＩＭＳ通信セッションのグループ又は単一のＩＭＳ通信セッションのための認証を提供する。図１９に示すように、本発明に基づき、ポリシサーバ３１６、３２４によって生成される認証トークンは、認証タイプフィールド４００、グループＩＭＳセッション認証識別子フィールド４０２及び単一ＩＭＳセッション認証識別子フィールド４０４を含む。認証タイプフィールド４００には、ＩＭＳ通信セッションが専用のリソース／ＧＰＲＳベアラを用いるか否か又はＩＭＳ通信セッションが他のＩＭＳ通信セッション及びＵＥと共有されるＧＰＲＳベアラを用いるか否かを特定する所定の値が格納される。認証タイプフィールド４００に格納される値の具体例は、以下の通りである。
０１：グループＩＭＳセッション認証識別子
１０：単一ＩＭＳセッション認証識別子
ＩＭＳ通信セッションが専用のリソース／ＧＰＲＳベアラを用いる場合、グループＩＭＳセッション認証識別子フィールド４０２は、「０」に設定され、単一ＩＭＳセッション認証識別子フィールド４０４には、ＩＭＳセッションに固有の認証トークンが格納される。通信セッションが他のＩＭＳ通信セッションとＧＰＲＳベアラを共有する場合、グループＩＭＳセッション認証識別子フィールド４０２には、そのセッションを定義する固有の認証値が格納され、単一ＩＭＳセッション認証識別子フィールド４０４は、「０」に設定される。上述のように、認証トークンは、ＵＥからの要求、例えば、ＳＩＰ：ＩＮＶＩＴＥメッセージに応じて、ポリシサーバによって生成される。これに応じて、ポリシ決定ポイントとして機能するＰ−ＣＳＣＦ３１６は、ＩＭＳネットワーク内のＳ−ＣＳＣＦ３１２と通信を行う。そして、Ｓ−ＣＳＣＦ３１２は、ＨＳＳ３１４から加入データを検索し、共通のＧＰＲＳベアラを確立するための認証を提供できるか否かを判定する。権限が認証された場合、ＵＥ３０２、３０４、３０６に適切な認証トークンが発行される。

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

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

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

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

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

Ｓ４：Ｐ−ＣＳＣＦ３１６がＳ−ＣＳＣＦ３１２と連携して、ＨＳＳ３１４から加入者情報データを検索する。そして、Ｐ−ＣＳＣＦ３１６は、加入者情報に基づいて、共有されたＩＭＳ通信セッションを受信することをユーザが認証されているか否か、及びこのセッションが共通のＧＰＲＳベアラを介して提供できるか否かを判定する。認証されている場合、Ｐ−ＣＳＣＦ３１６は、認証のタイプ（グループ又は単一）及び共有ベアラ又は専用ベアラのセッション認証識別子を提供する認証トークンを生成し、ＧＧＳＮ３に渡す。

Ｓ８：ＧＧＳＮがモバイルユーザ機器３０２に認証トークンを渡す。

Ｓ１０：モバイルユーザ機器３０２がプロトコルコンフィグレーションオプションフィールドの一部として認証トークンを提供するＰＤＰコンテキストアクティブ化要求をセットアップする。

Ｓ１２：ＳＧＳＮがＰＤＰコンテキストアクティブ化要求を受け取り、ＧＧＳＮ３に認証トークンを渡す。そして、ＧＧＳＮ３は、Ｐ−ＣＳＣＦ３１６によるセッション認証識別子を確認することによって、他のモバイルユーザ機器と共通の通信セッションを確立する権限がモバイルユーザ機器にあるかを確認する。

Ｓ１６：モバイルユーザ機器がＩＭＳセッションのために共通のＧＰＲＳベアラを受け取る権限を有しているかをＰ−ＣＳＣＦ３１６が確認する。

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

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

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

添付資料１
パケットフィルタコンテンツフィールドは、サイズが可変であり、可変数（少なくとも１つ）のパケットフィルタコンポーネントを含む。各パケットフィルタコンポーネントは、１つのオクテットパケットフィルタコンポーネントタイプ識別子及び固定長パケットフィルタコンポーネントバリューフィールドのシーケンスとして符号化される。パケットフィルタコンポーネントタイプ識別子は、先に送信される。

各パケットフィルタにおいては、２つ以上のパケットフィルタコンポーネントタイプは、出現しない。１つのパケットフィルタには、「ＩＰｖ４ソースアドレスタイプ」及び「ＩＰｖ６ソースアドレスタイプ」パケットフィルタコンポーネントのうちの１つのみしか存在しない。また、１つのパケットフィルタには、「単一宛先ポートタイプ」及び「宛先ポート範囲タイプ」パケットフィルタコンポーネントのうちの１つのみしか存在しない。また、１つのパケットフィルタには、「単一ソースポートタイプ」及び「ソースポート範囲タイプ」パケットフィルタコンポーネントのうちの１つのみしか存在しない。

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

「ＩＰｖ４ソースアドレスタイプ」については、パケットフィルタコンポーネントバリューフィールドは、４オクテットのＩＰｖ４アドレスフィールド及び４オクテットのＩＰｖ４アドレスマスクフィールドのシーケンスとして符号化される。ここでは、ＩＰｖ４アドレスフィールドが先に送信される。「ＩＰｖ６ソースアドレスタイプ」については、パケットフィルタコンポーネントバリューフィールドは、１６オクテットのＩＰｖ６アドレスフィールド及び１６オクテットのＩＰｖ６アドレスマスクフィールドのシーケンスとして符号化される。ここでは、ＩＰｖ６アドレスフィールドが先に送信される。「プロトコル識別子／次のヘッダタイプ」については、パケットフィルタコンポーネントバリューフィールドは、ＩＰｖ４プロトコル識別子又はＩＰｖ６の次ヘッダを指定する１オクテットとして符号化されるものとする。

「単一の宛先ポートタイプ」及び「単一のソースポートタイプ」については、パケットフィルタコンポーネントバリューフィールドは、ポート番号を指定する２オクテットとして符号化される。「宛先ポート範囲タイプ」及び「ソースポート範囲タイプ」については、パケットフィルタコンポーネントバリューフィールドは、２オクテットのポート範囲下限フィールド及び２オクテットのポート範囲上限フィールドのシーケンスとして符号化される。ここでは、ポート範囲下限フィールドが先に送信される。

「セキュリティパラメータインデクス」については、パケットフィルタコンポーネントバリューフィールドは、ＩＰＳｅｃセキュリティパラメータインデクスを指定する４オクテットとして符号化される。「サービスタイプ／トラヒッククラスタイプ」については、パケットフィルタコンポーネントバリューフィールドは、１オクテットのサービスタイプ／トラヒッククラスフィールド及び１オクテットのサービスタイプ／トラヒッククラスマスクフィールドのシーケンスとして符号化される。ここでは、サービスタイプ／トラヒッククラスタイプが先に送信される。

「フローラベルタイプ」については、パケットフィルタコンポーネントバリューフィールドは、ＩＰｖ６フローラベルを指定する３オクテットとして符号化される。第１のオクテットのビット８〜５は、予備であり、残りの２０ビットがＩＰｖ６フローラベルを含む。

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

Claims (19)

1. モバイルユーザ機器に及び／又はモバイルユーザ機器からインターネットパケットを通信する設備を提供するパケット無線ネットワークにおいて、
   パケット通信ベアラを介する、上記モバイルユーザ機器から上記パケット無線ネットワークへの、及び／又は該パケット無線ネットワークから該モバイルユーザ機器へのインターネットパケットの通信を制御するためのパケットデータプロトコルコンテキストを提供するゲートウェイサポートノードと、
   上記ゲートウェイサポートノードに接続され、該ゲートウェイサポートノードから上記モバイルユーザ機器への及び／又は該モバイルユーザ機器から該ゲートウェイサポートノードへのインターネットパケットの通信を制御し、パケット通信ベアラを形成するサービスサポートノードと、
   無線アクセスインタフェースを介して、上記モバイルユーザ機器への及び／又は該モバイルユーザ機器からのインターネットパケットを通信する無線アクセスベアラを提供する無線ネットワークコントローラとを備え、
   上記サービスサポートノードは、共通のパケットデータプロトコルコンテキストを要求するパケットデータプロトコルアクティブ化要求メッセージに応じて、上記ゲートウェイサポートノードと協働して、共通のパケット通信ベアラに関連付けられた共通のパケットデータプロトコルコンテキストを確立し、該共通のパケットデータプロトコルコンテキストは、上記共通のパケット通信ベアラを介してインターネットプロトコルパケットを通信するように確立され、該共通のパケット通信ベアラは、少なくとも１つの他の通信セッションと共有され、上記ゲートウェイサポートノード及び上記サービスサポートノードによって、共通のトンネルプロトコルベアラを用いて形成されるパケット無線ネットワーク。
2. 上記ゲートウェイサポートノードは、複数の通信セッションにとって共通のパケット通信ベアラを介して、インターネットプロトコルパケットを通信し、該通信セッションの少なくとも１つは、他の通信セッションとは異なるインターネットプロトコルバージョンを用いることを特徴とする請求項１記載のパケット無線ネットワーク。
3. 上記ゲートウェイサポートノードは、上記サービスサポートノードを介して、該ゲートウェイサポートノード及び上記無線ネットワークコントローラの間で共通のトンネルプロトコルベアラを形成することによって共通の通信ベアラを確立し、該共通のトンネルプロトコルベアラは、上記共通のパケット通信ベアラを共有する各モバイルユーザ機器について共通のトンネルエンドポイント識別子を用いて形成されることを特徴とする請求項１又は２記載のパケット無線ネットワーク。
4. 上記トンネルプロトコルベアラは、インターネットプロトコルトランスポートレイヤによってサポートされ、該トンネルプロトコルベアラは、各通信セッションに基づいて通信されるインターネットパケットのヘッダに示される異なるサービスクラスの品質に基づいて、上記共通のトンネルベアラを共有する各通信セッションにサービス品質を提供することを特徴とする請求項１乃至３何れか１項記載のパケット無線ネットワーク。
5. 上記モバイルユーザ機器によって確立された通信セッションに基づき、該モバイルユーザ機器に及び／又は該モバイルユーザ機器からインターネットパケットを通信するために確立された無線アクセスベアラの１つを特定する無線アクセスベアラフィルタを無線ネットワーク部分に含み、該無線アクセスベアラフィルタは、該モバイルユーザ機器に送信されたインターネットパケットの宛先アドレスから、確立された通信セッションに対応する無線アクセスベアラを特定することを特徴とする請求項１乃至４何れか１項記載のパケット無線ネットワーク。
6. 上記通信セッションのために対応する無線アクセスベアラが特定されるインターネットパケットの宛先アドレスは、上記モバイルユーザ機器によって上記無線アクセスベアラフィルタに供給されることを特徴とする請求項５記載のパケット無線ネットワーク。
7. 上記無線アクセスベアラのそれぞれは、上記モバイルユーザ機器によって通信セッションが確立されたサービス品質を提供することを特徴とする請求項５又は６記載のパケット無線ネットワーク。
8. パケット無線ネットワークを介して、モバイルユーザ機器に及び／又はモバイルユーザ機器からインターネットパケットを通信する通信方法において、
   上記パケット無線ネットワークのゲートウェイサポートノードにおいて、パケット通信ベアラを介する、上記パケット無線ネットワークから上記モバイルユーザ機器への及び／又は上記モバイルユーザ機器から上記パケット無線ネットワークへのインターネットパケットの通信を制御するためのパケットデータプロトコルコンテキストを提供するステップと、
   上記パケット無線ネットワークのサービスサポートノードを用いて、上記モバイルユーザ機器への及び／又はモバイルユーザ機器からのインターネットパケットの通信を制御し、上記パケット通信ベアラを形成するステップと、
   上記パケット無線ネットワークの無線ネットワークコントローラを用いて、無線アクセスインタフェースを介して、上記モバイルユーザ機器への及び／又は上記モバイルユーザ機器からのインターネットパケットを通信するための無線アクセスベアラを提供するステップと、
   共通のパケットデータプロトコルコンテキストを要求するパケットデータプロトコルアクティブ化要求メッセージに応じて、共通のパケット通信ベアラに関連する共通のパケットデータプロトコルコンテキストを確立するステップとを有し、
   上記共通のパケットデータプロトコルコンテキストは、上記共通のパケット通信ベアラを介してインターネットプロトコルパケットを通信するために確立され、該共通のパケット通信ベアラは、共通のトンネルプロトコルベアラを用いて、少なくとも１つの他の通信セッションと共有される通信方法。
9. 上記共通のトンネルプロトコルベアラを用いるステップは、
   上記パケット無線ネットワークのサービスサポートノードを介して、上記ゲートウェイサポートノードと上記無線ネットワークコントローラとの間に、共通のパケット通信ベアラを共有する上記モバイルユーザ機器のそれぞれに共通のトンネルエンドポイント識別子を用いて、共通のトンネルプロトコルベアラを形成するステップを含むことを特徴とする請求項８記載の通信方法。
10. 上記トンネルプロトコルベアラは、インターネットプロトコルトランスポートレイヤによってサポートされ、上記共通のトンネルプロトコルベアラを形成するステップは、各通信セッションに基づいて通信されるインターネットパケットのヘッダに示される異なるサービスクラスの品質に基づいて、共通のトンネルベアラを共有する各通信セッションにサービス品質を提供するステップを含むことを特徴とする請求項８又は９記載の通信方法。
11. 上記無線アクセスベアラを提供するステップは、無線ネットワークコントローラの一部として、上記モバイルユーザ機器によって確立された通信セッションに基づき、該モバイルユーザ機器に及び／又は該モバイルユーザ機器からインターネットパケットを通信するために確立された無線アクセスベアラの１つを特定する無線アクセスベアラフィルタを含み、該無線アクセスベアラフィルタは、上記モバイルユーザ機器に送信されたインターネットパケットの宛先アドレスから、確立された通信セッションに対応する無線アクセスベアラを特定することを特徴とする請求項８乃至１０何れか１項記載の通信方法。
12. 上記モバイルユーザ機器から上記無線アクセスベアラフィルタに、上記通信セッションのために対応する無線アクセスベアラが特定されるインターネットパケットの宛先アドレスを供給するステップを更に有する請求項１１記載の通信方法。
13. 上記無線アクセスベアラのそれぞれは、上記モバイルユーザ機器によって通信セッションが確立されたサービス品質を提供することを特徴とする請求項１１又は１２記載の通信方法。
14. コンピュータにロードされて、請求項８乃至１３何れか１項記載の通信方法を実現するコンピュータ実行可能なコードを提供するコンピュータプログラム。
15. 請求項１４記載のコンピュータプログラムを格納する媒体。
16. 請求項１４記載のコンピュータプログラムを表す信号。
17. パケット無線ネットワークを介して、モバイルユーザ機器に及び／又はモバイルユーザ機器からインターネットパケットを通信する通信装置において、
    上記パケット無線ネットワークのゲートウェイサポートノードにおいて、パケット通信ベアラを介する、上記パケット無線ネットワークから上記モバイルユーザ機器への及び／又は該モバイルユーザ機器から上記パケット無線ネットワークへのインターネットパケットの通信を制御するためのパケットデータプロトコルコンテキストを提供するパケットデータプロトコルコンテキスト提供手段と、
    上記パケット無線ネットワークのサービスサポートノードを用いて、上記モバイルユーザ機器への及び／又は該モバイルユーザ機器からのインターネットパケットの通信を制御し、上記パケット通信ベアラを形成するパケット通信ベアラ形成手段と、
    上記パケット無線ネットワークの無線ネットワークコントローラを用いて、無線アクセスインタフェースを介して、上記モバイルユーザ機器への及び／又は該モバイルユーザ機器からのインターネットパケットを通信するための無線アクセスベアラを提供する無線アクセスベアラ提供手段と、
    パケットデータプロトコルアクティブ化要求メッセージに応じて、共通のパケットデータプロトコルコンテキストを要求するステップと、
    共通のパケット通信ベアラに関連する共通のパケットデータプロトコルコンテキストを確立する共通パケットデータプロトコルコンテキスト手段とを備え、
    該共通のパケットデータプロトコルコンテキストは、共通のパケット通信ベアラを介してインターネットプロトコルパケットを通信するために確立され、該共通のパケット通信ベアラは、共通のトンネルプロトコルベアラを用いて、少なくとも１つの他の通信セッションと共有される通信装置。
18. 添付の図３乃至図１６を参照して明細書に実質的に説明するパケット無線ネットワーク。
19. 添付の図３乃至図１６を参照して明細書に実質的に説明する、パケット無線ネットワークを介して、モバイルユーザ機器に及び／又はモバイルユーザ機器からインターネットパケットを通信する通信方法。

Images