(57)【特許請求の範囲】
【請求項１】
ユーザ機器ＵＥとＩＰネットワークとの間でモバイル・ネットワークを通じてユーザ・プレーン・トランザクションをサポートするためのアーキテクチャであって、前記モバイル・ネットワークは、コントロール・プレーン・ベアラを通じて前記ＵＥと前記モバイル・ネットワークとの間のコントロール・プレーン・トランザクションをサポートする、コントロール・プレーン・ノードと呼ばれる、少なくとも１つのノードを含む、アーキテクチャにおいて、
−  前記ＵＥ、およびコントロール・プレーン・ベアラを通じて前記ＵＥと前記コントロール・プレーン・ノードとの間で前記モバイル・ネットワークを通じたユーザ・プレーン・トランザクションをサポートするように構成された前記コントロール・プレーン・ノードと、
−  前記モバイル・ネットワークのユーザ・プレーン・ベアラの必要なしに、前記コントロール・プレーン・ノードと前記ＩＰネットワークとの間で前記モバイル・ネットワークを通じて、ユーザ・プレーン・トランザクションをサポートするように構成された前記コントロール・プレーン・ノードであって、前記ＩＰネットワークとインターフェースするゲートウェイ機能（ＤＯＣＰ  ＧＷ）とインターフェースし、前記コントロール・プレーン・ノードと前記ゲートウェイ機能との間のインターフェースを通じたＩＰ転送は、ＩＰトンネリングを用いて、またはＩＰトンネルリングなしで実行される、前記コントロール・プレーン・ノードと
を含むアーキテクチャ。
【請求項２】
−  ゲートウェイ機能を選択し、前記ゲートウェイ機能とのＩＰトンネルを確立するように構成された前記コントロール・プレーン・ノード
を含む請求項１に記載のアーキテクチャ。
【請求項３】
−  前記コントロール・プレーン・ノードに、Ｒａｄｉｕｓ／Ｄｉａｍｅｔｅｒアカウンティング機能および／またはＤＨＣＰ機能を提供するよう構成された前記ゲートウェイ機能
を含む請求項１または２に記載のアーキテクチャ。
【請求項４】
請求項１乃至３のいずれか１項に記載のアーキテクチャにおいて、ユーザ・プレーン・トランザクション・サービスにＵＥがアクセスするための方法であって、前記サービスのために前記ＵＥについてユーザ・プレーン・ベアラが必要ないという前記コントロール・プレーン・ノードへの指示に基づく少なくとも１つのステップを含む方法。
【請求項５】
前記指示は、
−  前記ＵＥが、前記ユーザ・プレーン・トランザクション・サービスへのアクセス要求で前記指示を提供すること、および
−  モバイル・ネットワーク加入者データベースが、前記コントロール・プレーン・ノードから受信された要求に応じて前記指示を提供すること
の少なくとも１つにより前記コントロール・プレーン・ノードに提供される請求項４に記載の方法。
【請求項６】
−  前記ＵＥから前記指示を受信するときに、前記コントロール・プレーン・ノードが、前記ＵＥが前記サービス使用の許可を有することを検証するステップ
を含む請求項４または５に記載の方法。
【請求項７】
−  前記ＵＥが前記サービス使用の許可を有することを検証するときに、前記コントロール・プレーン・ノードが、前記ゲートウェイ機能からＩＰアドレス情報を取得し、前記ＵＥによって前記サービスに使用されるＩＰアドレス情報を含む肯定応答を用いて、前記サービスへのアクセスに対するＵＥの要求に応えるステップ
を含む請求項４乃至６のいずれか１項に記載の方法。
【請求項８】
−  前記コントロール・プレーン・ノードが、ＵＥ識別子情報と前記サービスについての前記ＵＥのＩＰアドレス情報との間のマッピングを格納するステップ
を含む請求項４乃至７のいずれか１項に記載の方法。
【請求項９】
−  前記ゲートウェイ機能が、前記ＵＥに割り当てられた前記ＩＰアドレス情報を用いて前記サービス環境に通知するステップ
を含む請求項４乃至８のいずれか１項に記載の方法。
【請求項１０】
前記コントロール・プレーン・ノードが、前記ゲートウェイ機能に送られたアドレス割り当てサーバ・プロトコルの使用を介して、前記ＵＥのＩＰアドレス情報を要求するステップを含む、請求項１乃至３のいずれか１項に記載のアーキテクチャにおいて、ユーザ・プレーン・トランザクション・サービスのために前記ＵＥにＩＰアドレスを割り当てるための方法。
【請求項１１】
−  前記コントロール・プレーン・ノードから前記ゲートウェイ機能に送られる前記アドレス割り当てサーバ・プロトコル信号送信において、前記ＵＥ識別情報およびターゲットＡＰＮを示すステップ
を含む請求項１０に記載の方法。
【請求項１２】
−  前記コントロール・プレーン・ノードと前記ゲートウェイ機能との間の信号交換においてノード再開カウンターを示すステップと、
−  他方のノードの再開カウンターが変更された場合、この他方のノードに関連するリソースを解放するステップと
を含む請求項１０または１１に記載の方法。
【請求項１３】
請求項１乃至３のいずれか１項に記載のアーキテクチャにおいて、ユーザ・プレーン・トランザクションをサポートするための方法であって、ユーザ・プレーン・ベアラを必要としない、ユーザ・プレーン・トランザクションのサポートに基づく少なくとも１つのステップを含む方法。
【請求項１４】
アップリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記コントロール・プレーン・ノードの中継機能が、前記ＵＥの前記ゲートウェイ機能を用いてＵＥからＩＰトンネルにマッピングを提供するステップ
を含む請求項１３に記載の方法。
【請求項１５】
ダウンリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記ゲートウェイ機能が、前記ＵＥに割り当てられたＩＰアドレスに対応し、前記ＵＥにサービスを提供する前記コントロール・プレーン・ノードに関連する前記ＩＰパケットの宛先ＩＰアドレスに基づいて、前記コントロール・プレーン・ノードに向けて前記ＩＰパケットを転送するステップ
を含む請求項１３に記載の方法。
【請求項１６】
ダウンリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記コントロール・プレーン・ノードの中継機能が、ＵＥのコントロール・プレーン・ベアラにＵＥのＩＰアドレスからのマッピングを提供するステップ
を含む請求項１３または１５に記載の方法。
【請求項１７】
請求項１乃至３のいずれか１項に記載のアーキテクチャにおけるコントロール・プレーン・ノード間モビリティのための方法であって、前記コントロール・プレーン・ノード間モビリティの間に、ユーザ・プレーン・ベアラの必要なしに、ユーザ・プレーン・サービスを非アクティブ化および再アクティブ化することに基づく少なくとも１つのステップを含む、方法。
【請求項１８】
請求項１乃至３のいずれか１項に記載のアーキテクチャのための、またはコントロール・プレーン・ノードに関係する請求項４乃至１７のいずれか１項に記載の方法のステップを実行するように構成されたコントロール・プレーン・ノード。
【請求項１９】
請求項１乃至３のいずれか１項に記載のアーキテクチャのための、またはゲートウェイ機能に関係する請求項４乃至１７のいずれか１項に記載の方法のステップを実行するように構成されたゲートウェイ機能。
【請求項２０】
請求項１乃至３のいずれか１項に記載のアーキテクチャのための、またはユーザ機器に関係する請求項４乃至１７のいずれか１項による方法のステップを実行するように構成されたユーザ機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、モバイル通信ネットワークおよびシステムに関する。
【背景技術】
【０００２】
モバイル通信ネットワークおよびシステムについての詳細な記述は、特に、たとえば３ＧＰＰ（第３世代パートナーシップ・プロジェクト）などの標準化団体によって公開されている技術仕様書などの文献で見ることができる。
【０００３】
パケット・モバイル通信システムの例として、進化型パケット・システムＥＰＳ（Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｓｙｓｔｅｍ）（３ＧＰＰ  ＴＳ２３．４０１に特に明記）、ＧＰＲＳ／ＵＭＴＳ（３ＧＰＰ  ＴＳ２３．０６０に特に明記）、ＣＤＭＡ  ＥＶＤＯ、ＷｉＭＡＸなどがある。
【０００４】
３ＧＰＰ  ＴＳ２３．４０１からの図１に見られるように、ＥＰＳは、たとえば、特にＥ−ＵＴＲＡＮまたはＵＴＲＡＮによってアクセスできるＥＰＣ（進化型パケット・コア）を含む。ＥＰＳは、ユーザ機器ＵＥと外部ＩＰネットワーク（パケット・データ・ネットワークＰＤＮとも呼ぶ）との間にＩＰ接続を提供する。ＥＰＳにおけるユーザ・プレーン・トランザクションのサポートは、ＰＤＮ接続およびベアラの概念、またはネットワーク全体およびネットワークの異なるインターフェースを通じてユーザ・プレーン・トランザクションについて割り当てられたネットワーク・リソースに基づいている。手順は、そのようなＰＤＮ接続およびベアラ、ならびにネットワークの異なるノードの関連するコンテキストを管理（たとえば、確立または解放）するために規定されている。ＥＰＳ以外のシステムにも同様の概念がある。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】３ＧＰＰ  ＴＳ２３．４０１
【非特許文献２】３ＧＰＰ  ＴＳ２３．０６０
【非特許文献３】３ＧＰＰ  ＴＲ２３．８８８
【非特許文献４】３ＧＰＰ  ＳＡ１
【非特許文献５】３ＧＰＰ  ＴＳ２９．３０３
【非特許文献６】３ＧＰＰ  ２９．０６１
【非特許文献７】３ＧＰＰ  ＴＳ２３．２３６
【発明の概要】
【発明が解決しようとする課題】
【０００６】
発明者らによって認識され、後により詳細に記述するように、モバイル・ネットワークを通じたユーザ・プレーン・トランザクションには、新しい概念に基づいて、たとえば、マシン・タイプ通信ＭＴＣ（マシン・トゥ・マシンＭ２Ｍとも呼ばれる）または他の低帯域幅データ通信など、新しいタイプの通信について改善されたサポートに対するニーズがある。より一般的には、たとえば、ＭＴＣまたは他の低帯域幅データ通信など、新しいタイプの通信の特定の性質のために、ネットワークおよびシステムの改善が必要である。
【０００７】
本発明の実施形態は、特に、そのようなニーズに対処するものである。
【課題を解決するための手段】
【０００８】
これらおよび他の目的は、一態様では、ユーザ機器ＵＥとＩＰネットワークとの間でモバイル・ネットワークを通じてユーザ・プレーン・トランザクションをサポートするためのアーキテクチャによって達成され、コントロール・プレーン・ノードとも呼ばれる、少なくとも１つのノードを含む前記モバイル・ネットワークは、コントロール・プレーン・ベアラを通じて前記ＵＥと前記モバイル・ネットワークとの間のコントロール・プレーン・トランザクションをサポートする。一実施形態では、前記アーキテクチャは、
−  前記ＵＥ、およびコントロール・プレーン・ベアラを通じて前記ＵＥと前記コントロール・プレーン・ノードとの間で前記モバイル・ネットワークを通じたユーザ・プレーン・トランザクションをサポートするように構成された前記コントロール・プレーン・ノードと、
−  前記モバイル・ネットワークのユーザ・プレーン・ベアラの必要なしに、前記コントロール・プレーン・ノードと前記ＩＰネットワークとの間で前記モバイル・ネットワークを通じて、ユーザ・プレーン・トランザクションをサポートするように構成された前記コントロール・プレーン・ノードであって、ＩＰトンネリングあり、またはなしで、前記ＩＰネットワークとインターフェースするゲートウェイ機能とインターフェースする前記コントロール・プレーン・ノードと
を含む。
【０００９】
これらおよび他の目的は、他の態様において、特にそのようなアーキテクチャにおいてなど、モバイル・ネットワークのユーザ・プレーン・ベアラの必要なく、前記モバイル・ネットワークを通じてユーザ・プレーン・トランザクション・サービスにＵＥがアクセスするための方法によって達成される。一実施形態では、前記方法は、前記サービスのために前記ＵＥについてユーザ・プレーン・ベアラは必要ないという前記コントロール・プレーン・ノードへの指示に基づく少なくとも１つのステップを含む。
【００１０】
これらおよび他の目的は、他の態様において、特にそのようなアーキテクチャにおいてなど、前記モバイル・ネットワークのユーザ・プレーン・ベアラの必要なく、モバイル・ネットワークを通じてユーザ・プレーン・トランザクション・サービスについてＵＥにＩＰアドレスを割り当てるための方法によって達成される。一実施形態では、前記方法は、前記コントロール・プレーン・ノードが、前記ゲートウェイ機能へのアドレス割り当てサーバ・プロトコル（ＤＨＣＰまたは他のプロトコルなど）の使用を介して、ＵＥのＩＰアドレス情報を要求するステップを含む。
【００１１】
これらおよび他の目的は、他の態様において、特にそのようなアーキテクチャにおいてなど、前記モバイル・ネットワークのユーザ・プレーン・ベアラを必要とせずに、モバイル・ネットワークを通じてユーザ・プレーン・トランザクションをサポートするための方法によって達成される。一実施形態では、前記方法は、ユーザ・プレーン・ベアラを必要としない、ユーザ・プレーン・トランザクションのサポートに基づく少なくとも１つのステップを含む。
【００１２】
これらおよび他の目的は、他の態様では、特にそのようなアーキテクチャにおいてなど、前記モバイル・ネットワークのユーザ・プレーン・ベアラを必要としない、モバイル・ネットワークを通じたコントロール・プレーン・ノード間モビリティのための方法によって達成される。一実施形態では、前記方法は、前記コントロール・プレーン・ノード間モビリティの間に、ユーザ・プレーン・ベアラの必要なしに、ユーザ・プレーン・サービスを非アクティブ化および再アクティブ化することに基づく少なくとも１つのステップを含む。
【００１３】
これらおよび他の目的は、他の態様では、そのようなアーキテクチャに対する、および／またはそのような方法（複数可）を実行するためのエンティティによって達成され、前記エンティティは、特に（しかし排他的でなく）、ユーザ機器ＵＥ、コントロール・プレーン・ノード、およびゲートウェイ機能を含む。
【００１４】
本発明の実施形態による装置および／または方法の一部の実施形態について、単に例示を目的として、添付の図に関してここに記述する。
【図面の簡単な説明】
【００１５】
【図１】ＥＰＳのアーキテクチャの例を示す図である。
【図２】ＥＰＣへのＥ−ＵＴＲＡＮアクセスのためのユーザ・プレーン・プロトコル・スタックを示す図である。
【図３】ＥＰＣへのＥ−ＵＴＲＡＮアクセスのためのコントロール・プレーン・プロトコル・スタックを示す図である。
【図４】ＥＰＣへのＵＴＲＡＮアクセスのためのユーザ・プレーン・プロトコル・スタックを示す図である。
【図５】ＥＰＣへのＥ−ＵＴＲＡＮアクセスのためにＰＤＮ接続を確立するのに必要な信号送信を示す図である。
【図６】ＧＰＲＳコアへのＵＴＲＡＮアクセスのためにＰＤＰコンテキストを確立するのに必要な信号送信を示す図である。
【図７】ＥＰＣへのＵＴＲＡＮアクセスのためにＰＤＰコンテキストを確立するのに必要な信号送信を示す図である。
【図８】現在３ＧＰＰ  ＴＲ２３．８８８に提案されている少量のデータ送信のためのエンドトゥエンド・データ経路を示す図である。
【図９】ＥＰＣへのＥ−ＵＴＲＡＮアクセスのために、例示を目的として、本発明の実施形態によるユーザ・プレーン・プロトコル・スタックの第１の例を示す図である。
【図１０】ＥＰＣへのＥ−ＵＴＲＡＮアクセスのために、例示を目的として、本発明の他の実施形態によるユーザ・プレーン・プロトコル・スタックの第２の例を示す図である。
【図１１】ＥＰＣへのＥ−ＵＴＲＡＮアクセスのために、例示を目的として、本発明の他の実施形態によるユーザ・プレーン・プロトコル・スタックの第３の例を示す図である。
【発明を実施するための形態】
【００１６】
本発明の実施形態は、マシン・トゥ・マシン（Ｍ２Ｍ）、またはより一般的に「マシン・タイプ通信」（ＭＴＣ）モバイル・デバイスもしくは他の低帯域幅データ・サービスのために、端末とネットワークとの間で短期間および散発的なユーザ・プレーン・トランザクションの頻繁でない送信を行うために効率的なソリューションを提供する。
【００１７】
ターゲット・デバイスの例には、ａ）１日に１度、２、３の測定値を報告するセンサー、ｂ）週に１度、補充が必要であることを通知する（コーヒー）マシンがある。
【００１８】
知られている既存のソリューションはすべて、通常のユーザに対する通常のデータ・サービスに対するものと同じパケット・コア・ネットワーク手順を使用するため、頻度が少ない短いトランザクションを低コストで伝達するには適していない。特に、それらは、そのようなデバイスが、非常に少数のパケットを送るためだけに、時々ウェイク・アップするときに大量の信号送信を伴うか、かつ／またはＥＰＣユーザ・プレーン（ＳＧＷおよびＰＧＷ）においてリソースの永久的な割り当てを必要とする。
【００１９】
ＬＴＥアクセスの場合：
１）ユーザ・プレーンは、図２に示すプロトコル・スタックに基づく（３ＧＰＰ  ＴＳ２３．４０１、図５．１．２．１−１を参照）。
２）図３に示す、対応するＵＥ−ＭＭＥコントロール・プレーン・プロトコル・スタックを用いる（３ＧＰＰ  ＴＳ２３．４０１、図５．１．１．３−１を参照）。
【００２０】
ＵＭＴＳアクセスの場合：
３）ユーザ・プレーンは、進化型パケット・コアにおいて図４（３ＧＰＰ  ＴＳ２３．４０１、図５．１．２．４−１を参照）に示すプロトコル・スタックに基づく：（最善の場合、つまりＵＴＲＡＮとＳＧＷとの間に直接的なトンネルを用いる場合を示す）
４）ＧＰＲＳコアのユーザ・プレーンについて同様の図が存在する。３ＧＰＰ  ＴＳ２３．０６０を参照。
【００２１】
これらのすべての場合に、Ｅ−ＵＴＲＡＮまたはＵＴＲＡＮについて図５、図６、図７にそれぞれ示すように、ＵＥからＰＤＮ  ＧＷ（進化型パケット・コア）まで、またはＧＧＳＮ（ＧＰＲＳコア）に、ＰＤＮ接続を確立するためにネットワークの全体にわたって、大規模な信号送信が必要である（３ＧＰＰ  ＴＳ２３．４０１、図５．３．２．１−１および３ＧＰＰ  ＴＳ２３．０６０、図６４および図６４ａをそれぞれ参照）。
【００２２】
また、これらのすべての場合において、パケット・コア（ＳＧＷ／ＰＧＷ）は、ＵＥにアドレス指定された着信パケットをＰＧＷからＳＧＷに（そしてＷＣＤＭＡおよびＧＳＭアクセスのためにＳＧＳＮに）ルーティングするために確立された永久的な接続が必要である。頻度が少ない少量のデータ送信サービスの場合には、これはネットワーク・リソースの浪費である。
【００２３】
したがって、現在のパケット・ネットワーク手順は、送られるデータの実際の量に対して多くの信号送信（および処理）オーバヘッドが発生するため、頻度が少ない少量のデータ送信には非効率的である。
【００２４】
これは、Ｓｙｓｔｅｍ  Ｉｍｐｒｏｖｅｍｅｎｔｓ  ｆｏｒ  Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓに関する３ＧＰＰ  ＳＡ２の研究において主要な課題として認識されている。３ＧＰＰ  ＴＲ２３．８８８、５．４項を参照。
【００２５】
１つの解決策は、ＮＡＳ（非アクセス層信号送信）内の少量のデータの転送を許可することによってＵＥとＭＭＥとの間の信号送信を最適化するＴＲ２３．８８８、６．５３項（「Ｓｏｌｕｔｉｏｎ−Ｓｍａｌｌ  Ｄａｔａ  Ｔｒａｎｓｆｅｒ（Ｅ−ＵＴＲＡＮ）：Ｕｓｅ  ｏｆ  ｐｒｅ−ｅｓｔａｂｌｉｓｈｅｄ  ＮＡＳ  ｓｅｃｕｒｉｔｙ  ｃｏｎｔｅｘｔ  ｔｏ  ｔｒａｎｓｆｅｒ  ｔｈｅ  ｌＰ  ｐａｃｋｅｔ  ａｓ  ＮＡＳ  ｓｉｇｎａｌｌｉｎｇ  ｗｉｔｈｏｕｔ  ｅｓｔａｂｌｉｓｈｉｎｇ  ＲＲＣ  ｓｅｃｕｒｉｔｙ」）に提案されており、ＵＥがアイドル・モードにある場合、少量のデータの発生のたびにＳ１および無線ベアラを確立する必要を回避できる。この解決策は図８に示している。
【００２６】
しかし、この解決策は、まだ、ネットワーク全体でＰＤＮ接続を確立することが必要である。したがって頻度が少ない少量のデータ送信に適していない（これは頻繁な少量のデータ送信より可能性の高いシナリオである）。
【００２７】
ＳＭＳは、また、短いユーザ・プレーン・パケットの転送に適した手法ではない。以下にその理由を述べる。
−  これはＩＰベースの通信を許可しない。
−  ＳＭＳペイロード（１６０オクテット）が小さすぎる。３ＧＰＰ  ＳＡ１要件により、１Ｋオクテットまでの少量のデータを転送することが可能であるべきである。複数のＳＭＳを連結するのは、かなり非効率的である。
−  ＳＭＳのインフラストラクチャおよび処理におけるオーバヘッド。
−  ＳＭＳは、ＬＴＥではＰＳのみのデバイスにはサポートされていない。
【００２８】
Ｍ２ＭまたはＭＴＣのデバイスは、多くの場合、短いパケット長で頻度が少ないトランザクションを含む（たとえば、月１回のガス計測の報告）。
課題
−  ＬＴＥ／ＥＰＣネットワークは、まれにしか使用されないＰＧＷおよびＳＧＷのリソースを永久的に固定するデフォルト・ベアラの確立割り当てを必要とする。
−  ＭＴＣデバイスがトランザクションを開始する必要があるたびに、最初にＳＧＷへのユーザ・プレーン接続を再確立するために一連のコントロール・プレーン・トランザクションを開始する必要がある。多くの場合、実際のユーザ・プレーン・メッセージと比べ、より多くの無線インターフェースおよびネットワーク・トラフィックが、これらのコントロール・プレーン・メッセージで浪費される。
【００２９】
通常のＥＰＣユーザ・プレーンの必要性を回避する、ＭＴＣサービス・データ送信のための新しいメカニズムを決定する必要がある。
【００３０】
本発明の実施形態は、特に、そのような問題を解決するか、またはそのような欠点を回避することができる。
【００３１】
以下、本発明の実施形態について、ＥＰＳを通じたＭ２ＭまたはＭＴＣの通信の場合について、例示および説明を目的としてより詳細に記述する。しかし、本発明はそのような場合に限定されない。
【００３２】
本発明の実施形態は、ＴＲ２３．８８８、６．５３項に提案された解決策に基礎を置き、（散発的で少量のデータ・トランザクションについて）モバイルの「コントロール・プレーンを通じたデータ（Ｄａｔａ  ｏｖｅｒ  Ｃｏｎｔｒｏｌ  Ｐｌａｎｅ）」オプションを規定し、コントロール・プレーン・ノード（たとえばＬＴＥアクセスに対してＭＭＥまたはレガシ３ｇｐｐ無線に対してＳＧＳＮ）に、（たとえばブロードバンド・ネットワーク・ゲートウェイＢＮＧなど、既存のネットワーク・ノードによって実装することができる）新しい「コントロール・プレーン・ゲートウェイを通じたデータ（Ｄａｔａ  ｏｖｅｒ  Ｃｏｎｔｒｏｌ  Ｐｌａｎｅ  Ｇａｔｅｗａｙ）」機能を介してこのトラフィックをルーティングさせ、したがって、ＰＧＷ／ＧＧＳＮへのＰＤＮ接続を確立する必要がない）。
【００３３】
無線を通じて、およびＲＡＮ（無線アクセス・ネットワーク）とコアとの間のインターフェースを通じて、専用のユーザ・プレーン・ベアラを確立する必要を回避するために、短いユーザ・プレーンＩＰトランザクションは、３ＧＰＰ  ＴＲ２３．８８８の６．５３項に規定された解決策に類似する原理により、ネットワークのＵＥとコントロール・プレーン・ノードとの間でコントロール・プレーン信号送信チャネルを通じて伝えられる。ＩＰトラフィックは、ＵＥとコア・ネットワーク・ノードとの間の信号送信リンクを通じて運ばれる。
【００３４】
「コントロール・プレーンを通じたデータ」（ＤＯＣＰ）サービスを提供するための本発明の様々な実施形態について、以下に記述する。
【００３５】
図９、図１０、図１１は、たとえば、ＥＰＣへのＥ−ＵＴＲＡＮアクセスについて、ＤＯＣＰサービスのプロトコル・スタックの例を示している。図９および図１０に示した例では、コントロール・プレーン・ノードＭＭＥは、ＤＯＣ  ＧＷと示されたゲートウェイ機能を介して、外部のＩＰネットワークとインターフェースする。
【００３６】
図９に示した例では、コントロール・プレーン・ノードＭＭＥは、ＩＰトンネリングを用いて、ＩＰネットワークとインターフェースするゲートウェイ機能ＤＯＣＰ  ＧＷとインターフェースする。図１０に示した例では、コントロール・プレーン・ノードＭＭＥは、ＩＰトンネリングを用いずに、ＩＰネットワークとインターフェースするゲートウェイ機能ＤＯＣＰ  ＧＷとインターフェースする。図９は、たとえば、加入者が歩き回っている場合など、特に、コントロール・プレーン・ノードおよびゲートウェイ機能が異なるＰＬＭＮに位置する場合に使用することができる一方、図１０は、たとえば、加入者が歩き回っていない場合など、特に、コントロール・プレーン・ノードおよびゲートウェイ機能が同じＰＬＭＮに位置する場合に使用することができる。
【００３７】
図９では、コントロール・プレーン・ノードＭＭＥが、ＩＰトンネリングを用いて、ゲートウェイ機能ＤＯＣＰ  ＧＷとインターフェースする場合について最初に考える。
【００３８】
図９の例において、ＩＰトンネリングは、任意の適切なＩＰトンネル・プロトコルの場合がある、「ＶＰＮ」レイヤによって示されている（Ｌ２−ＴＰ、Ｌ２−ＶＰＮ、Ｌ３−ＶＰＮ、ＧＲＥなど）。
【００３９】
３ＧＰＰアクセスの場合について、「コントロール・プレーンを通じたデータ」（ＤＯＣＰ）サービスは、限られた数のＩＰパケットをまれに送る、すべてまたはごく特定のデータ・セッションについて、特定のモバイル端末（ＵＥ）によって使用される（正規のＰＤＮ接続／ＰＤＰコンテキストへの）代替アクセス・メカニズムとして提供される。
【００４０】
ＬＴＥを通じて、アタッチメント段階の間に、ＤＯＣＰを使用するように構成されたＵＥは、デフォルト・ベアラを確立する必要はないが、むしろ代替ＤＯＣＰ手順を使用するべきであるという指示をアタッチメント・メッセージに含む（この指示は、たとえば、ＤＯＣＰ  ＰＤＮ接続指標が提供される変更されたＰＤＮ  ＣＯＮＮＥＣＴＩＶＩＴＹ  ＲＥＱＵＥＳＴメッセージの形を取ることができる）。あるいは、代替ＤＯＣＰ手順を使用してデフォルト・ベアラおよびＰＤＮ接続確立を処理するべきことを、ＭＭＥに示すために、ＵＥおよび／またはＨＳＳレコードが使用する特別なＡＰＮを規定することができる。
【００４１】
ＲＡＮノード（Ｅ−ＵＴＲＡＮノードなど）を１つを超えるコントロール・プレーン・ノード（ＭＭＥまたはＳＧＳＮなど）に接続できるシステム（Ｓ１−ＦｌｅｘをサポートするＥＰＳなど）では、ＵＥは、ＤＯＣＰサービスをサポートするコントロール・プレーン・ノードを選択することをＲＡＮノードに要求する、サービスを提供するＲＡＮノードへの指示を含むことができる。ＵＥは、アタッチした後にＤＯＣＰサービスの使用を開始できるため、ＤＯＣＰ対応コントロール・プレーン・ノードに向けたこのＵＥの操作は、ＵＥがサポートし、後にＤＯＣＰサービスを使用できるというＵＥアタッチメントの間の指示に依存する場合がある。
【００４２】
特定のＭＴＣデバイスの加入が、以前にＤＯＣＰサービスを使用する許可を認められていたことを検証した後、次に、ＭＭＥは、正規のＰＤＮ接続の場合のようにＤＯＣＰサービスを使用するときに、ＵＥによって使用されるアドレス指定（たとえばＩＰｖ６）を含む肯定応答で応える（この肯定応答は、たとえば、変更されたＡＣＴＩＶＡＴＥ  ＤＥＦＡＵＬＴ  ＥＰＳ  ＢＥＡＲＥＲ  ＣＯＮＴＥＸＴ  ＲＥＱＵＥＳＴメッセージの形を取ることができる）。選択されたＭＭＥまたはＳＧＳＮがＤＯＣＰサービスをサポートしない場合、それは、ＤＯＣＰサービスをサポートする代替コントロール・プレーン・ノードにアタッチメント要求をリダイレクトするために、マルチオペレータ・コア・ネットワーク（ＭＯＣＮ）手順を使用することができる。
【００４３】
２Ｇ／３Ｇ（ＧＳＭ、ＷＢ−ＣＤＭＡ）３ｇｐｐ無線を通じて、ＤＯＣＰを使用するように構成されたＵＥは、ベアラを作成する必要がなく、むしろ代替ＤＯＣＰ手順を使用するべきであるという指示をＡＣＴＩＶＡＴＥ  ＰＤＰ  ＣＯＮＴＥＸＴ  ＲＥＱＵＥＳＴメッセージに含む。特定のＭＴＣデバイスの加入が、以前にＤＯＣＰサービスを使用する許可を認められていたことを検証した後、次に、ＳＧＳＮは、正規のＰＤＰコンテキストの場合のようにＤＯＣＰサービスを使用するときに、ＵＥによって使用されるアドレス指定（たとえばＩＰｖ６）を含むことができる肯定応答で応える。
【００４４】
注記１：この解決策により、ＧＰＲＳコアにおいてＧＥＲＡＮ／ＵＴＲＡＮでサポートされるように、ＰＧＷへのデフォルト・ベアラを設定することなく、Ｅ−ＵＴＲＡＮを介してＵＥがアタッチされる可能性が生じる。これは、すべてのＵＥがデフォルト・ベアラを確立するべきという、またはデファクト・デフォルト・ベアラとしてＤＯＣＰ手順を使用するというルールの変更として正式に扱うことができる。
【００４５】
注記２：コントロール・プレーン・ノード（たとえばＬＴＥアクセスに対してＭＭＥまたはＧＥＲＡＮ／ＵＴＲＡＮに対してＳＧＳＮ）は、ＵＥからＮＡＳ信号で受信されたＤＯＣＰ指示、ＵＥがデータを送ることを要求するＡＰＮ、ＨＳＳから受信された加入パラメータ（たとえば、このＡＰＮが、頻度が少ない少量のデータ送信に関連するかどうかを識別するＡＰＮ構成パラメータ）、現地の事業者ポリシー、および／または過去のトラフィック交換についての可能な知識（たとえば、ＵＥのトラフィックがＤＯＣＰサービスの一部の上部しきい値を超えることの検出）に基づいて、この小さなパケット（ＤＯＣＰ）解決策を使用するか、またはＰＧＷ／ＧＧＳＮへの正規のＰＤＮ接続を確立するかを決定することができる。
【００４６】
注記３：ＤＯＣＰ手順を使用するＵＥは、通常のＰＧＷを介して第２のＰＤＮ接続を開くために既存の手順を使用することができる。このデュアルＰＤＮ手法は、ＵＥの高トラフィック期間または特定の用途（たとえばＵＥのＳＷダウンロード）をサポートするために、アプリケーション・レイヤで使用することができ、ＤＯＣＰ接続を通じてアプリケーション・レイヤの信号送信を使用してトリガーすることができる（つまり、通常は頻度が少ない少量のデータ送信サービスのみをサポートする必要があるＵＥを含む一括の更新またはダウンロードのプロセスについて）。
【００４７】
注記４：ＭＭＥまたはＳＧＳＮは、通常のＰＤＮ手順を使用して、ＤＯＣＰ接続されたＵＥを再アタッチさせるため、かつ／または通常の手順を使用して接続されたＤＯＣＰ対応ＵＥに、ＤＯＣＰ手順を使用して再アタッチさせるために、既存の手順を使用することができる。この代替ＰＤＮ手法は、ＤＯＣＰと通常のメカニズムとの間でＵＥ接続の平衡を保つために、ネットワークによって使用することができる。
【００４８】
注記５：ＤＯＣＰサービスをサポートする専用のＭＭＥまたはＳＧＳＮを展開することができる一方、ＤＯＣＰサービスを必要としないＵＥにサービスを提供するために「通常の」ＭＭＥまたはＳＧＳＮを配置し続ける。ＤＯＣＰ対応コントロール・プレーン・ノードの選択は、たとえば、上記のように実行することができる。
【００４９】
このＤＯＣＰサービスのユーザ・プレーン（ＩＰパケット）トラフィックを運ぶために、無線インターフェースを通じて、およびＲＡＮ（たとえば、３ｇｐｐによって規定されたＵＴＲＡＮまたはＥ−ＵＴＲＡＮの場合がある無線アクセス・ネットワーク）と（たとえばＳ１−ｕおよびＩｕを通じた）コア・ネットワークとの間のインターフェースを通じて、専用のベアラ・チャネルは確立されない。
【００５０】
アップリンク方向（端末からネットワーク）では、ＤＯＣＰベアラを通じて運ばれるユーザ・プレーン・トラフィックは、専用のＮＡＳメッセージ内にカプセル化され、以下を通じてＵＥからＭＭＥ（またはＳＧＳＮ）に透過的に運ばれる通常のＩＰパケットに対応する。
−  無線インターフェースＬＴＥ−Ｕｕ（またはＵＴＲＡＮ−Ｕｕ）、および
−  ｅＮＢからＭＭＥへのコントロール・プレーン・インターフェースＳ１−ＭＭＥ（またはＵＴＲＡＮからＳＧＳＮへのＩｕ−ＰＳ）。
【００５１】
注記：これは、ＵＥとコントロール・プレーン・ノードとの間でコントロール・プレーン信号送信チャネルを通じて短いユーザ・プレーンＩＰパケットを伝送するために使用できる３ＧＰＰ  ＴＲ２３．８８８の６．５３項に提案されている解決策の原理に類似している。
【００５２】
ＭＭＥ（またはＳＧＳＮ）内において、特定のＮＡＳメッセージ・タイプ、たとえば「ＤＯＣＰの透過的な転送」が、ＭＭＥ（またはＳＧＳＮ）自体で通常は終了する他のＮＡＳメッセージから、ＤＯＣＰユーザ・プレーン・トラフィックを分離するために使用される。このトラフィック分離は、通常の信号送信およびＤＯＣＰトラフィックに異なるＱｏＳを提供するために使用することができる（たとえば、伝送またはノードの輻輳の場合）。
【００５３】
特定の端末が、以前にＤＯＣＰベアラを使用する許可を認められていたことを検証した後、ＭＭＥ（またはＳＧＳＮ）は、本来のＩＰネットワークに向けてこのトラフィックを送ることを担当するＤＯＣＰゲートウェイに向けて、インターフェースを通じてＩＰパケットをルーティングする。
【００５４】
注記：「ＤＯＣＰゲートウェイ」（または「ＤＯＣＰ  ＧＷ」）という用語は、この文書の全体にわたって、既存のネットワーク・ノードによって実装できる「コントロール・プレーン・ゲートウェイを通じたデータ」機能を表す（下に記述した可能な実施形態を参照）。
【００５５】
ＵＥがアイドル・モードにあった場合（アップリンク・トラフィックを送る必要がある場合）、ＵＥは、最初に、ＵＥによってトリガーされたサービス要求を開始する（たとえば、ＬＴＥについて３ＧＰＰ  ＴＳ２３．４０１、５．３．４．１項に記述）。しかし、ＵＥによってトリガーされたサービス要求の手順は、以下のように変更される。
−  サービス要求は、ユーザ・プレーン・ベアラを確立する必要がないという指標を含む。したがって、ＭＭＥ／ＳＧＳＮは、Ｓ１−Ｕ接続の（再）確立を開始しない。
−  ＵＥは、セキュリティが確保されたモードへの移行を承認するＲＲＣメッセージ（たとえばＬＴＥに対する無線ベアラ・セットアップ完了）で無線を通じてピギーバックされたＮＡＳ（たとえば「ＤＯＣＰの透過的な転送」）メッセージ自体にカプセル化されたＤＯＣＰ手順を介してアップリンクに送ることを望む第１のユーザ・プレーン・パケットを送る。
−  続くアップリンクおよびダウンリンクのパケットは、次に、アクティブな信号送信ベアラを通じてＮＡＳメッセージ（たとえば「ＤＯＣＰの透過的な転送」）として運ばれる。
【００５６】
ダウンリンク（ネットワークから端末）ユーザ・プレーン・トラフィックについて、ＤＯＣＰゲートウェイは、サービスを提供するＭＭＥ（またはＳＧＳＮ）に向けた宛先アドレスに基づいてＩＰパケットをルーティングする。−宛先アドレスは、ＤＯＣＰ  ＧＷによってサービスを提供するＭＭＥ／ＳＧＳＮに割り当てられたアドレスのブロックに関係する場合がある（下に記述したＩＰアドレス割り当てメカニズムを参照）。次に、このＭＭＥ（またはＳＧＳＮ）は、ターゲットＵＥを決定するために宛先ＩＰアドレスを使用し、ＲＡＮに向けて（たとえば「ＤＯＣＰの透過的な転送」）ＮＡＳメッセージにダウンリンクＩＰパケットをカプセル化して、ＲＡＮ（ＥＮＢまたはＵＴＲＡＮ）は、無線を通じてＵＥにメッセージを伝えるために、確立されたＮＡＳ伝送手順を使用する。
【００５７】
注記１：ユーザ・プレーンの実際の転送に専用されるこの（たとえば「ＤＯＣＰの透過的な転送」）ＮＡＳメッセージを転送する場合、正規のＮＡＳ信号送信に割り当てられる優先度より低い優先度は無線を通じて使用することができる。ＵＥへのＮＡＳ  ＴＲＡＮＳＰＯＲＴをＲＡＮから要求するＳ１／ＩｕメッセージをＲＡＮに送る場合（つまりＳ１−ＡＰ  ＤＯＷＮＬＩＮＫ  ＮＡＳ  ＴＲＡＮＳＰＯＲＴおよびＩｕ  ＤＩＲＥＣＴ  ＴＲＡＮＳＦＥＲメッセージ）、このより低い優先度は、ＭＭＥ／ＳＧＳＮによって信号送信される。
【００５８】
注記２：ＤＯＣＰメッセージは、ＵＥへのパケットの伝達を保証するために、Ｓ１−ＡＰ（ＬＴＥ）またはＩｕ（ＵＴＲＡＮ）に依存するＮＡＳベアラ、ＳＣＴＰ、ならびにＲＲＣ、ＰＤＣＰ、およびＲＬＣの無線インターフェース機能を通じて伝えられる。
【００５９】
受信時に、ＵＥは、メッセージをカプセル解除し、確立されたＩＰエンド・スタック手順を使用して、アプリケーション・レイヤにＩＰパケットを送る。
【００６０】
ＵＥがアイドル・モードにあった場合、ＭＭＥ／ＳＧＳＮは、最初に、ネットワーク・トリガード・サービス要求（Ｎｅｔｗｏｒｋ  Ｔｒｉｇｇｅｒｅｄ  Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ）を開始し、したがって、ＵＥをページングする必要がある（たとえば、ＬＴＥについて３ＧＰＰ  ＴＳ２３．４０１、５．３．４．３項に記述）。
【００６１】
いつでもＵＥは、複数のＰＤＮ／マルチＰＤＰコンテキスト手順を使用して（たとえば、ＬＴＥについて３ＧＰＰ  ＴＳ２３．４０１、５．１０項に記述）、デフォルトおよび任意に１つまたは複数の専用ベアラを用いて追加のＰＤＮ／ＰＤＰコンテキストを確立することができる。この場合、ＵＥは、ＤＯＣＰ手順を使用する１つのＰＤＮアクセス／ＰＤＰコンテキスト、およびＰＤＮ  ＧＷ／ＧＧＳＮを介して通常の３ＧＰＰ手順を使用する１つまたは複数の追加的なＰＤＮアクセス／ＰＤＰコンテキストを持つ。ＵＥは、ＵＥ・トリガード・サービス要求（ＵＥ  Ｔｒｉｇｇｅｒｅｄ  Ｓｅｒｖｉｃｅ  Ｒｅｑｕｅｓｔ）メッセージの間に、通常のＰＤＮがいつ使用されるかを示すべきである。
【００６２】
同じＰＤＮアクセスに対して通常のＰＤＮ手順の使用とＤＯＣＰ手順の使用との間で移行するために、いつでもＵＥまたはＭＭＥ／ＳＧＳＮは、アタッチ手順の前に、確立された明示的なデタッチ手順を使用することができるか（たとえば、ＬＴＥについて３ＧＰＰ  ＴＳ２３．４０１、５．３．８項に記述）、またはＵＥが複数のＰＤＮ接続を使用する場合、ＵＥに要求されたＰＤＮ接続手順（たとえば、３ＧＰＰ  ＴＳ２３．４０１、５．１０．２項に記述）の前に、確立されたＰＤＮ切断手順を使用することができる（たとえば、ＬＴＥについて３ＧＰＰ  ＴＳ２３．４０１、５．３．１０項に記述）。ネットワークによって開始された場合、デタッチ・メッセージは、デタッチ・タイプ情報要素に「再アタッチが必要（Ｒｅ−ａｔｔａｃｈ  ｒｅｑｕｉｒｅｄ）」という指示を含むべきであり、ＥＰＳベアラ・コンテキスト非アクティブ化要求（Ｄｅａｃｔｉｖａｔｅ  ＥＰＳ  Ｂｅａｒｅｒ  Ｃｏｎｔｅｘｔ  Ｒｅｑｕｅｓｔ）（ＬＴＥ）またはＰＤＰコンテキスト非アクティブ化要求（Ｄｅａｃｔｉｖａｔｅ  ＰＤＰ  Ｃｏｎｔｅｘｔ  Ｒｅｑｕｅｓｔ）（ＵＴＲＡＮ）メッセージは、「再アクティブ化を要求（ｒｅａｃｔｉｖａｔｉｏｎ  ｒｅｑｕｅｓｔｅｄ）」原因値、ならびにネットワークがＵＥに従うことを要求する手順（ＤＯＣＰまたは通常のＰＤＮ接続）の指示を含むべきである。
【００６３】
ＭＭＥ／ＳＧＳＮは、ここではＳｘｘと呼ぶＤＯＣＰ  ＧＷを用いる専用のインターフェースを持つ。Ｓｘｘは、以下から構成される。
−  ＶＰＮトンネリングを用いるＩＰ転送（ＭＭＥ／ＳＧＳＮおよびＤＯＣＰ  ＧＷは、異なるＰＬＭＮ（複数可）にある可能性があるため）
−  以下を許可するＤＨＣＰインターフェース
−  デバイスに対してＩＰｖ４アドレス／ＩＰｖ６プレフィックスを取得／解放するＭＭＥ／ＳＧＳＮ
−  ＨＰＬＭＮによるデバイスのＩＰアドレス指定機能の管理：たとえば、Ｒａｄｉｕｓ／Ｄｉａｍｅｔｅｒアカウンティング生成、動的ＤＮＳ更新など。
【００６４】
ＭＭＥ／ＳＧＳＮ機能は、以下の機能を用いて強化される。
−  ＤＯＣＰ  ＧＷに向けたＶＰＮトンネル確立、
−  ＮＡＳ信号送信とＤＯＣＰ  ＧＷへのＶＰＮトンネルとの間でＩＰパケットを転送する中継機能、
−  ＵＥサービスを管理するためにＤＯＣＰ  ＧＷに向けたＤＨＣＰ機能（たとえばＩＰアドレス割り当て、充電、傍受）、
−  ＤＯＣＰメッセージに使用されるＮＡＳ信号送信を通じた正規のＮＡＳ信号の優先度付け。
【００６５】
注記：ＭＭＥ／ＳＧＳＮは、信号送信の法的な傍受を既にサポートしている。これは、ＮＡＳ信号送信でカプセル化されたＤＯＣＰメッセージの傍受に再使用することができる。
【００６６】
ＤＯＣＰ  ＧＷは、ＵＥのＩＰアドレス割り当て、法的な傍受、充電、ファイヤウォール、ユーザ・プレーン・トラフィックのＮＡＴ処理を担当する。
【００６７】
注記：ＤＯＣＰ  ＧＷは、また、ＵＥに割り当てられたＩＰアドレスをＵＥのピアに認識させることも担当する（たとえば、マシン−マシン通信のＤＯＣＰ機能を使用する場合におけるＭＴＣサーバ）。これは、ＵＥに関連するＤＮＳレコードを更新するＤＯＣＰ  ＧＷによって、または、どのＩＰアドレスがどのＵＥに割り当てられているかを通知するために、Ｒａｄｉｕｓアカウンティングを使用するなど他の手段によって、サポートすることができる。
【００６８】
ＤＯＣＰ手順を使用するＰＤＮ接続／ＰＤＰコンテキストのアクティブ化で、ＭＭＥ／ＳＧＳＮは、
−  １つまたは複数の適切なＤＯＣＰ  ＧＷを選択する（３ＧＰＰ  ＴＳ２９．３０３で規定されたＤＮＳ手順の拡張を使用）。
−  ＵＥに代わってＤＨＣＰ要求を送る。このＤＨＣＰ要求は、ＵＥおよびターゲットＡＰＮのＩＭＳＩを含む。
−  このＤＨＣＰ要求は、選択されたＤＯＣＰ  ＧＷに向けてＩＰトンネルで送られる。
【００６９】
ＤＯＣＰ  ＧＷは、ＩＰアドレスをＵＥに割り当てるときに、たとえば、以下のアドレス割り当て方式を適用することができる。
−  ＤＯＣＰ  ＧＷは、ＵＥのＩＰｖ６  ６４ビットのネットワーク・プレフィックス（またはＩＰｖ４アドレス）を割り当て、ＭＭＥ／ＳＧＳＮに向けたトンネルに、このＵＥのＩＰｖ６  ６４ビットのネットワーク・プレフィックス（またはＩＰｖ４アドレス）を関連させる。
−  たとえば、ＵＥは、サービスを提供するＭＭＥ／ＳＧＳＮのグローバルに一意のＩＰｖ６プレフィックスのサブプレフィックスを割り当てられる。
−  （結果的に、ＤＯＣＰ  ＧＷは、サービスを提供するＭＭＥ／ＳＧＳＮに向けてダウンリンク・ユーザ・プレーン・パケットをルーティングする）
【００７０】
ＵＥにＩＰアドレスまたはプレフィックスを割り当てたら、ＤＯＣＰ  ＧＷは、ＩＰサービスに対しＵＥが到達可能であることをアプリケーション環境に通知することができる。これは、以下を含むことができる。
−ＡＡＡサーバへのＡＡＡ信号を生成する（たとえば、３ｇｐｐ  ２９．０６１に記述されているＰＤＮ接続のアクティブ化でＰＧＷ／ＧＧＳＮが生成する、またはＩＰセッションをアクティブ化したときにＢＮＧが生成するようなＲａｄｉｕｓアカウンティング）
−  ＵＥに代わって動的ＤＮＳ更新を発行する
−  その他
【００７１】
同様に、ＵＥのＩＰアドレス／プレフィックスを解放するＤＨＣＰ要求を受信する場合、ＤＯＣＰ  ＧＷは、ＩＰサービスに対してＵＥが到達可能ではないことをアプリケーション環境に通知する。これは、以下を含むことができる。
−  ＡＡＡサーバへのＡＡＡ信号を生成する（たとえば、３ｇｐｐ  ２９．０６１に記述されているＰＤＮ接続の非アクティブ化でＰＧＷ／ＧＧＳＮが生成する、またはＩＰセッションを非アクティブ化したときにＢＮＧが生成するようなＲａｄｉｕｓアカウンティング）
−  ＵＥに代わって動的ＤＮＳ更新を発行する
−  その他
【００７２】
ＭＭＥ／ＳＧＳＮとＤＯＣＰ  ＧＷとの間のＤＨＣＰ信号送信は、他方のノードが再開されていること、したがって他方のノードに関連するリソースを解放しなければならないことを各ノードが検出することを可能にする再開カウンターを含む。
【００７３】
ＭＭＥ／ＳＧＳＮは、ＵＥのＩＭＳＩまたはＴＭＳＩと、ＵＥに割り当てられたＩＰアドレスとの間のマッピングを格納する。
【００７４】
注記１：ＩＰｖ６のステートレス・アドレス自動設定について、ＵＥは、ネットワークを含めることなく、リンク・ローカル以外に、ＩＰｖ６アドレスを生成するために任意のインターフェース識別子を選択することができる。またプライバシー保護のため、ＵＥは、ネットワークを含めることなく、完全なＩＰｖ６アドレスを生成するために使用されるインターフェース識別子を変更することができる。３ＧＰＰ  ＴＳ２３．４０１、５．３．１．２．２項を参照。結果的に、ＤＯＣＰ  ＧＷでのＩＰｖ６アドレス割り当て方式は、ＵＥに影響を与えること、および既存のＩＰｖ６ステートレス・アドレス自動設定の原理を変更することを回避するために、各ＵＥにグローバルに一意のＩＰｖ６プレフィックスを割り当てることを目的とするべきである。
【００７５】
注記２：ＩＰｖ４アドレス指定（ＭＴＣ  ＵＥに割り当てられたプライベートなＩＰｖ４アドレス）の場合には、ＮＡＴを使用せずにインターネットを通じて、ＭＴＣ  ＵＥ（プライベートＩＰアドレスを持つ）がＭＴＣサーバに到達することを可能にするトンネルに、ＡＰＮを関連させることが必要な場合がある（３ＧＰＰ  ＴＲ２３．８８８、６．２９．２下位項を参照）。これは、ＭＴＣデバイスの第１のホップ・ルータがＨＰＬＭＮにある場合有効に機能するが（ＭＴＣサーバとＨＰＬＭＮとの間のサービス内容合意書により、そのようなトンネルを規定）、ＶＰＬＭＮにおいてそのようなトンネリングをサポートするようにＤＯＣＰ  ＧＷ（または任意のボックス）に求めると運用面が複雑であろう。
解決法：
−  ＩＰｖ６のみを使用する、または
−  ＨＰＬＭＮにおけるＤＯＣＰ  ＧＷの割り当て（つまり、サービスを提供するＭＭＥ／ＳＧＳＮは、ＰＧＷ選択に関して似ているＤＮＳ手順を用いてＨＰＬＭＮのＤＯＣＰ  ＧＷを選択する）。
−  ＤＯＣＰ  ＧＷからＭＴＣサーバへのトンネルのセットアップを必要としない、代替ＮＡＴソリューション（たとえば制御されたＮＡＴ）に依存する。
【００７６】
ＵＥが移動し、サービスを提供するＭＭＥ／ＳＧＳＮを変更することを必要とする場合、ＵＥは、新しいＭＭＥ／ＳＧＳＮから新しいＩＰｖ４アドレスまたはＩＰｖ６プレフィックスを得るべきである。ノード間（ＳＧＳＮ／ＭＭＥ間）の移動の間に、ＤＯＣＰ  ＰＤＮ接続に関連するベアラ・コンテキストは、非アクティブ化される。たとえば、ＬＴＥについて、ＴＲＡＣＫＩＮＧ  ＡＲＥＡ  ＵＰＤＡＴＥ  ＲＥＱＵＥＳＴがＤＯＣＰ  ＰＤＮ接続を用いてＵＥから受信される場合、ＭＭＥは、ＤＯＣＰ  ＰＤＮ接続に関連するＤＯＣＰベアラ・コンテキストをローカルで非アクティブ化する。アクティブなベアラ・コンテキストがＵＥに対して残り、ＴＲＡＣＫＩＮＧ  ＡＲＥＡ  ＵＰＤＡＴＥ  ＲＥＱＵＥＳＴ要求メッセージが承認される場合、ＭＭＥは、ＤＯＣＰベアラ・コンテキストがローカルで非アクティブ化されたことをＴＲＡＣＫＩＮＧ  ＡＲＥＡ  ＵＰＤＡＴＥ  ＡＣＣＥＰＴメッセージで、ＥＰＳベアラ・コンテキスト状態ＩＥを介してＵＥに通知する。ＵＥは、ＵＥに要求されたＰＤＮ接続手順を開始することによって、ＤＯＣＰ  ＰＤＮ接続を再確立することができる。
【００７７】
注記１：ＭＭＥ／ＳＧＳＮプールの展開（つまり、複数のコア・ネットワーク（ＣＮ）ノードへの無線アクセス・ネットワーク（ＲＡＮ）ノードのドメイン内接続を使用する、３ＧＰＰ  ＴＳ２３．２３６を参照）は、ＭＭＥ間またはＳＧＳＮ間のモビリティを大幅に低下させる。ＭＭＥ／ＳＧＳＮの組み合わせの展開は、また、ＭＭＥとＳＧＳＮとの間のモビリティを大幅に低下させる。結果的に、ＣＮノード間の移動においてＵＥのＩＰアドレスを新しくする必要性は、特に頻度が少ない少量のデータ送信について課題と見なされない。異なるＣＮノード間のＵＥの移動のために一部のパケットが失われた場合、適用可能な再送信メカニズムも典型的に使用されるだろう。
【００７８】
本発明の実施形態は、コントロール・プレーン・ベアラを通じて新しい「ＵｎｉｔＤａｔａ」メッセージを使用して、短いパケット・トランザクションについて最適化された新しい伝送メカニズムを追加し、主要なネットワーク・コントロール・プレーン・ノード（ＬＴＥアクセスに対するＭＭＥ、ＧＳＭ／ＷＣＤＭＡに対するＳＧＳＮ、ＣＤＭＡ／ＤＯに対するＨＳＧＷ）に、新しい「コントロール・プレーン・ゲートウェイを通じたデータ」ノードに向けてＩＰ中継機能を提供させる。
【００７９】
本発明の実施形態は、以下の特定の特徴を提供する。
−  コントロール・プレーン・ベアラを通じて透過的に運ばれるデータ・フロー（ＬＴＥアクセスに対してＮＡＳ）
−  コントロール・プレーン・メッセージを通じてデータを示す、規定される新しいメッセージ・タイプ
−  ＲＡＮを通じた新しい（より低い）信号優先度（ＤＯＣＰユーザ・プレーンについて）
−  すべての接続された「制御を通じたデータ」デバイスと共有される共通のプレフィックスを使用するデバイスに割り当てられたＩＰアドレスおよび特定のデバイスを識別するために使用される一意のサフィックス
−  コントロール・プレーン・ノードは、中継機能マッピングを持つ。
−  ＵＬ：そのユーザにサービスを提供するＤＯＣＰ  ＧＷに向けたトンネルへのＵＥ
−  ＤＬ：特定のデバイスのコントロール・プレーン・ベアラへのＩＰヘッダから
【００８０】
本発明の実施形態では、ＭＭＥは、ＩＰフローだけで機能するＤＯＣＰＧＷにＵＥごとにＩＰフローを提示し、特定のＭＭＥに接続されたＵＥへのトラフィックを、これらのＵＥがすべてＭＭＥによって制御されたサブドメイン内にＩＰアドレスを持つという事実を使用して、すべてそのＭＭＥにルーティングする。
【００８１】
本発明の実施形態では、ＤＯＣＰＧＷ機能は、最小限にされ「ＩＰのみ」である（ＧＴＰ、モビリティ、または他の３ＧＰＰ機能はない）。第２のＡＡＡ段階がアタッチメントの間（つまりＩＰアドレス割り当て中）に追加され、ＤＯＣＰＧＷがワイヤー・ラインＢＮＧに非常に似ている場合、ＵＥごとの処理を行う役割を持つことができる。
【００８２】
図１０は、コントロール・プレーン・ノードＭＭＥが、ＩＰトンネリングを用いずに、ゲートウェイ機能ＤＯＣＰ  ＧＷとインターフェースする場合の例を示している。
【００８３】
図１０については、より詳細には記述しない。その理由は、図９について既に記述した原理は、図１０にも適用され、ＭＭＥとＤＯＣＰ  ＧＷとの間のインターフェースを通じたＩＰ転送は、図１０においてＩＰトンネリングなしで実行される一方、図９ではＩＰトンネリングを用いて実行されることを考慮するためである。図１０において、ＭＭＥとＤＯＣＰ  ＧＷとの間のインターフェースは、ＤＯＣＰ  ＧＷと外部のＩＰネットワークとの間のインターフェースと同様に、モバイル・ネットワークと外部ＩＰネットワークとの間のＳＧｉインターフェースの機能を持つ。
【００８４】
図１１は、たとえばＥＰＣへのＥ−ＵＴＲＡＮアクセスについて、ＤＯＣＰサービスのプロトコル・スタックの他の例を示している。この例では、コントロール・プレーン・ノードＭＭＥは、外部ＩＰネットワークと直接的にインターフェースする。
【００８５】
図１１に示した例では、ＭＭＥは、すべてのＩＰ機能を扱い、ＳＧｉインターフェースを直接的に提供する。この例では、ＭＭＥは、ＬＩ、課金、および評価の機能をすべて実行する。
【００８６】
様々な上記実施形態の代替案には、以下が含まれる。
１．ＧＳＭおよびＷＣＤＭＡアクセスを使用する場合、ＳＧＳＮは、ＭＭＥと同様の役割を実行する。
２．ＣＤＭＡ  ＥＶＤＯアクセスを使用する場合、ＨＳＧＷは、ＭＭＥと同様の役割を実行する。
３．ＷｉＭＡＸアクセスを使用する場合、ＡＳＮＧＷは、ＭＭＥと同様の役割を実行する。
４．「ＥＭＭ−ＲＥＧＩＳＴＥＲＥＤ」は、通常のＰＤＮアクセスに対応し、新しい「ＥＭＭ−ＲＥＧＩＳＴＥＲＥＤ＿ＵＳＩＮＧ＿ＤＯＣＰ」は、ＤＯＣＰベースのＰＤＮアクセスに対応する場合に、新しいＥＭＭ状態を使用してＤＯＣＰと通常のＰＤＮアクセス・モードとの間で移行するための手順。
５．ＤＯＣＰサービスをサポートするために変更される特定のコントロール・プレーン・ノードを選択するための手順の使用。
【００８７】
様々な上記実施形態の代替案は、以下を含む。
ａ）ＤＯＣＰ  ＧＷは、統合されたノードとしてＭＭＥを用いて実装される
ｂ）ＤＯＣＰ  ＧＷは、統合されたノードとしてＰＤＮ  ＧＷを用いて実装される
【００８８】
一態様では、ユーザ機器ＵＥとＩＰネットワークとの間でモバイル・ネットワークを通じてユーザ・プレーン・トランザクションをサポートするためのアーキテクチャが提供され、前記モバイル・ネットワークは、コントロール・プレーン・ベアラを通じて前記ＵＥと前記モバイル・ネットワークとの間のコントロール・プレーン・トランザクションをサポートする、コントロール・プレーン・ノードと呼ばれる、少なくとも１つのノードを含む。
【００８９】
様々な組み合わせにより、単独または組み合わせで採用できる、様々な実施形態が提供される。
【００９０】
一実施形態では、前記アーキテクチャは、
−  前記ＵＥ、およびコントロール・プレーン・ベアラを通じて前記ＵＥと前記コントロール・プレーン・ノードとの間で前記モバイル・ネットワークを通じたユーザ・プレーン・トランザクションをサポートするように構成された前記コントロール・プレーン・ノードと、
−  前記モバイル・ネットワークのユーザ・プレーン・ベアラの必要なしに、前記コントロール・プレーン・ノードと前記ＩＰネットワークとの間で前記モバイル・ネットワークを通じて、ユーザ・プレーン・トランザクションをサポートするように構成された前記コントロール・プレーン・ノードであって、ＩＰトンネリングあり、またはなしで、前記ＩＰネットワークとインターフェースするゲートウェイ機能とインターフェースする前記コントロール・プレーン・ノードと
を含む。
【００９１】
一実施形態では、前記アーキテクチャは、
−  ゲートウェイ機能を選択し、かつ前記ゲートウェイ機能を用いてＩＰトンネルを確立するように構成された前記コントロール・プレーン・ノード
を含む。
【００９２】
一実施形態では、前記アーキテクチャは、
−  前記コントロール・プレーン・ノードに、Ｒａｄｉｕｓ／Ｄｉａｍｅｔｅｒアカウンティング機能および／またはＤＨＣＰ機能を提供するよう構成された前記ゲートウェイ機能
を含む。
【００９３】
一実施形態では、前記アーキテクチャは、
−  前記コントロール・プレーン・ノード、または前記ＩＰネットワークとインターフェースするモバイル・ネットワーク・ノードに実装された前記ゲートウェイ機能
を含む。
【００９４】
一実施形態では、前記アーキテクチャは、
−  前記ＵＥ、および前記ＵＥと前記コントロール・プレーン・ノードとの間で、コントロール・プレーン・ベアラを通じて送られたコントロール・プレーン・メッセージでカプセル化されたユーザ・プレーンＩＰパケットを透過的に運ぶように構成された前記コントロール・プレーン・ノード
を含む。
【００９５】
上に記述した他の実施形態を含む他の実施形態は、もちろん可能である。
【００９６】
他の態様では、特にそのようなアーキテクチャにおいてなど、モバイル・ネットワークのユーザ・プレーン・ベアラの必要なしに、前記モバイル・ネットワークを通じてユーザ・プレーン・トランザクション・サービスにＵＥがアクセスするための方法が提供される。
【００９７】
様々な組み合わせにより、単独または組み合わせで採用できる、様々な実施形態が提供される。
【００９８】
一実施形態では、前記方法は、前記サービスのために前記ＵＥについてユーザ・プレーン・ベアラが必要ないという前記コントロール・プレーン・ノードへの指示に基づく少なくとも１つのステップを含む。
【００９９】
一実施形態では、前記指示は、以下の少なくとも１つにより前記コントロール・プレーン・ノードに提供される。
−  前記ＵＥが前記ユーザ・プレーン・トランザクション・サービスへのアクセス要求で前記指示を提供すること、および
−  モバイル・ネットワーク加入者データベースが、前記コントロール・プレーン・ノードから受信された要求に応じて前記指示を提供すること。
【０１００】
一実施形態では、前記方法は、
−  前記ＵＥから前記指示を受信するときに、前記コントロール・プレーン・ノードは、前記ＵＥが前記サービス使用の許可を有することを検証するステップ
を含む。
【０１０１】
一実施形態では、前記方法は、
−  前記ＵＥが前記サービス使用の許可を有することを検証するときに、前記サービスについて前記ＵＥに対するユーザ・プレーン・ベアラの必要なく、前記コントロール・プレーン・ノードがユーザ・プレーン・トランザクションをサポートするステップ
を含む。
【０１０２】
一実施形態では、前記方法は、
−  前記ＵＥが前記サービス使用の許可を有することを検証するときに、前記コントロール・プレーン・ノードは、前記ゲートウェイ機能からＩＰアドレス情報を取得し、前記ＵＥによって前記サービスに使用されるＩＰアドレス情報を含む肯定応答を用いて、前記サービスへのアクセスに対するＵＥの要求に応えるステップ
を含む。
【０１０３】
一実施形態では、前記方法は、
−  前記コントロール・プレーン・ノードは、ＵＥ識別子情報と前記サービスについて前記ＵＥに対するＩＰアドレス情報との間のマッピングを格納するステップ
を含む。
【０１０４】
一実施形態では、前記方法は、
−  前記ゲートウェイ機能は、前記ＵＥにサービスを提供するコントロール・プレーン・ノードに、前記ＵＥのＩＰアドレス情報を関連させるステップ
を含む。
【０１０５】
一実施形態では、前記方法は、
−  前記ゲートウェイ機能は、ＵＥに割り当てられたＩＰアドレス情報を用いてサービス環境に通知するステップ
を含む。
【０１０６】
上に記述した他の実施形態を含む他の実施形態は、もちろん可能である。
【０１０７】
他の態様では、特にそのようなアーキテクチャにおいてなど、モバイル・ネットワークのユーザ・プレーン・ベアラの必要なく、前記モバイル・ネットワークを通じてユーザ・プレーン・トランザクション・サービスについてＵＥにＩＰアドレスを割り当てるための方法が提供される。
【０１０８】
様々な組み合わせにより、単独または組み合わせで採用できる、様々な実施形態が提供される。
【０１０９】
一実施形態では、前記方法は、前記コントロール・プレーン・ノードが、前記ゲートウェイ機能へのアドレス割り当てサーバ・プロトコル（ＤＨＣＰまたは他のプロトコルなど）の使用を介して、ＵＥのＩＰアドレス情報を要求するステップを含む。
【０１１０】
一実施形態では、前記方法は、
−  前記コントロール・プレーン・ノードから前記ゲートウェイ機能に送られるアドレス割り当てサーバ・プロトコル（ＤＨＣＰまたは他のプロトコルなど）信号送信において、ＵＥ識別情報およびターゲットＡＰＮを示すステップ
を含む。
【０１１１】
一実施形態では、前記方法は、
−  前記コントロール・プレーン・ノードと前記ゲートウェイ機能との間の信号交換においてノード再開カウンターを示すステップと、
−  他方のノードの再開カウンターが変更された場合、この他方のノードに関連するリソースを解放するステップと
を含む。
【０１１２】
一実施形態では、前記方法は、
−  前記ＵＥが、コントロール・プレーン・ノード間モビリティの場合、前記ＵＥにサービスを提供する新しいコントロール・プレーン・ノードから新しいＩＰアドレスを取得するステップ
を含む。
【０１１３】
上に記述した他の実施形態を含む他の実施形態は、もちろん可能である。
【０１１４】
他の態様では、特にそのようなアーキテクチャにおいてなど、モバイル・ネットワークのユーザ・プレーン・ベアラの必要なく、前記モバイル・ネットワークを通じてユーザ・プレーン・トランザクションをサポートするための方法が提供される。
【０１１５】
様々な組み合わせにより、単独または組み合わせで採用できる、様々な実施形態が提供される。
【０１１６】
一実施形態では、前記方法は、ユーザ・プレーン・ベアラを必要としない、ユーザ・プレーン・トランザクションのサポートに基づく少なくとも１つのステップを含む。
【０１１７】
一実施形態では、前記方法は、アップリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記ＵＥは、前記コントロール・プレーン・ノードに前記ＵＥによってコントロール・プレーン・ベアラを通じて送られたコントロール・プレーン・メッセージに前記ＩＰパケットをカプセル化し、それぞれ前記コントロール・プレーン・ノードは、前記ＩＰパケットをカプセル解除するステップ
を含む。
【０１１８】
一実施形態では、前記方法は、アップリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記ＵＥは、ユーザ・プレーン・トラフィックがコントロール・プレーンを通じて伝えられることを示す特定のメッセージ・タイプを使用するステップ
を含む。
【０１１９】
一実施形態では、前記方法は、アップリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記コントロール・ペイン・ノードは、異なるタイプのトラフィックに異なるＱｏＳを提供するために、前記特定のメッセージ・タイプを使用するステップ
を含む。
【０１２０】
一実施形態では、前記方法は、アップリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記コントロール・プレーン・ノードは、ＩＰトンネリングあり、またはなしで、前記ゲートウェイ機能に向けて前記ＩＰパケットを転送するステップ
を含む。
【０１２１】
一実施形態では、前記方法は、アップリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記コントロール・プレーン・ノードの中継機能は、ＩＰトンネリングあり、またはなしで、前記ＵＥについて、ＵＥからゲートウェイ機能にマッピングを提供するステップ
を含む。
【０１２２】
一実施形態では、前記方法は、アップリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記ＩＰパケットを送る必要があるときに前記ＵＥがアイドル・モードにあった場合、前記ＵＥは、最初に、前記トランザクションについてユーザ・プレーン・ベアラを確立する必要がないという指示を含むサービス要求を前記コントロール・プレーン・ノードに送るステップ
を含む。
【０１２３】
一実施形態では、前記方法は、アップリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記サービス要求を受信するときに、前記コントロール・プレーン・ノードは、前記ＵＥのユーザ・プレーン・ベアラの確立を開始しないステップ
を含む。
【０１２４】
一実施形態では、前記方法は、ダウンリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記コントロール・プレーン・ノードは、前記ＵＥに割り当てられたＩＰアドレスに対応する、前記ＩＰパケットの宛先ＩＰアドレスに基づいて、前記ＩＰパケットに対してターゲットＵＥを決定するステップ
を含む。
【０１２５】
一実施形態では、前記方法は、ダウンリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記コントロール・プレーン・ノードは、前記ＵＥに前記コントロール・プレーン・ノードによってコントロール・プレーン・ベアラを通じて送られたコントロール・プレーン・メッセージに前記ＩＰパケットをカプセル化し、それぞれ前記ＵＥは、前記ＩＰパケットをカプセル解除するステップ
を含む。
【０１２６】
一実施形態では、前記方法は、
−  前記コントロール・プレーン・ノードは、ユーザ・プレーン・トラフィックがコントロール・プレーンを通じて伝送されることを示す特定のメッセージ・タイプを使用するステップ
を含む。
【０１２７】
一実施形態では、前記方法は、ダウンリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記コントロール・ペイン・ノードは、異なるタイプのトラフィックに異なるＱｏＳを提供するために、前記特定のメッセージ・タイプを使用するステップ
を含む。
【０１２８】
一実施形態では、前記方法は、ダウンリンクのユーザ・プレーンＩＰパケットの伝送について、
−  前記ゲートウェイ機能は、前記ＵＥに割り当てられたＩＰアドレスに対応しており前記ＵＥにサービスを提供するコントロール・プレーン・ノードに関連する前記ＩＰパケットの宛先ＩＰアドレスに基づいて、前記コントロール・プレーン・ノードに向けて前記ＩＰパケットを転送するステップ
を含む。
【０１２９】
一実施形態では、前記方法は、
−  前記コントロール・プレーン・ノードの中継機能は、ＵＥコントロール・プレーン・ベアラにＵＥのＩＰアドレスからのマッピングを提供するステップ
を含む。
【０１３０】
上に記述した他の実施形態を含む他の実施形態は、もちろん可能である。
【０１３１】
他の態様では、特にそのようなアーキテクチャにおいてなど、モバイル・ネットワークのユーザ・プレーン・ベアラの必要なく、前記モバイル・ネットワークを通じてコントロール・プレーン・ノード間モビリティのための方法が提供される。
【０１３２】
様々な組み合わせにより、単独または組み合わせで採用できる、様々な実施形態が提供される。
【０１３３】
一実施形態では、前記方法は、前記コントロール・プレーン・ノード間モビリティの間に、ユーザ・プレーン・ベアラの必要なしに、ユーザ・プレーン・サービスを非アクティブ化および再アクティブ化することに基づく少なくとも１つのステップを含む。
【０１３４】
上に記述した他の実施形態を含む他の実施形態は、もちろん可能である。
【０１３５】
他の態様では、特にそのようなアーキテクチャにおいてなど、モバイル・ネットワークのユーザ機器ＵＥのユーザ・プレーン・ベアラの必要なく、ユーザ・プレーン・トランザクション・サービスをサポートするサービスを提供するコントロール・プレーン・ノードを選択するための方法が提供される。
【０１３６】
様々な組み合わせにより、単独または組み合わせで採用できる、様々な実施形態が提供される。
【０１３７】
一実施形態では、前記方法は、前記モバイル・ネットワークへのアタッチメントの間に、前記ＵＥが前記サービスをサポートし、かつ／または前記モバイル・ネットワークへのアタッチメントの後に前記サービスを使用できるという指示を前記ＵＥが提供することに基づく、少なくとも１つのステップを含む。
【０１３８】
上に記述した他の実施形態を含む他の実施形態は、もちろん可能である。
【０１３９】
他の態様では、そのようなアーキテクチャのための、かつ／またはそのような方法（複数可）を実行するための手段を含むエンティティが提供され、前記エンティティは、特に（しかし排他的でなく）、ユーザ機器ＵＥ、コントロール・プレーン・ノード、ゲートウェイ機能を含む。
【０１４０】
前記コントロール・プレーン・ノードは、たとえば、以下のモバイル・ネットワーク・ノードの１つに対応する：
−  進化型パケット・システムＥＰＳに対するモビリティ管理エンティティＭＭＥ、
−  ＧＰＲＳ／ＵＭＴＳに対するサービスを提供するＧＰＲＳサポート・ノードＳＧＳＮ、
−  ＣＤＭＡ／ＥＶＤＯに対するＨＳＧＷ、
−  ＷｉＭＡＸに対するアクセス・サービス・ネットワーク・ゲートウェイＡＳＮＧＷ。
【０１４１】
当業者は、プログラムされたコンピュータによって様々な上記方法のステップを実行することができることを容易に認識するだろう。本明細書において、一部の実施形態は、また、機械またはコンピュータで読み取り可能であり、装置で実行可能またはコンピュータで実行可能なプログラム命令をエンコードする、たとえば、デジタル・データ記憶メディアなど、プログラム記憶装置を包含することを意図するものであり、前記命令は、上記方法のステップの一部またはすべてを実行する。プログラム記憶装置は、たとえば、デジタル・メモリ、磁気ディスクや磁気テープなどの磁気記憶メディア、ハード・ドライブ、または光学的に読み取り可能なデジタル・データ記憶メディアなどでもよい。また、実施形態は、上記方法の前記ステップを実行するようにプログラムされたコンピュータを包含することを意図するものである。
【図１】
0005947394.tif 000002
【図２】
0005947394.tif 000003
【図３】
0005947394.tif 000004
【図４】
0005947394.tif 000005
【図８】
0005947394.tif 000006
【図９】
0005947394.tif 000007
【図１０】
0005947394.tif 000008
【図１１】
0005947394.tif 000009
【図５】
0005947394.tif 000010
【図６】
0005947394.tif 000011
【図７】
0005947394.tif 000012