JP6039819B2 - 移動局上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置 - Google Patents

Description

本発明は、無線通信に関する。

（関連出願の相互参照）
本出願は、２０１２年１０月２２日に出願された米国特許仮出願第６１／７１６，６７９号明細書の利益を主張するものであり、この仮出願の内容の全体は、参照により本明細書に組み込まれる。

今日、マシンタイプ通信（ＭＴＣ）アプリケーションおよび非ＭＴＣアプリケーションを含めた、モバイルデバイスのための何十万個ものモバイルデータアプリケーションが存在する。これらのアプリケーションの多くは、モバイルブロードバンド接続を利用して、様々なタイプの通信をワイヤレス送受信ユニット（ＷＴＲＵ）（すなわち移動局）のユーザに提供することができる。

インスタントメッセージング（ＩＭ）、ソーシャルネットワーキングアプリケーション、アラームおよびサーベイランスシステムなど、いくつかの既存の「常時オン」モバイルデータアプリケーションは、現在、オペレータネットワークに課題をもたらしつつある。一般に、ＷＴＲＵ上で実行されるモバイルデータアプリケーションは、オペレータネットワークを介した、インターネット中に位置するアプリケーションサーバ（ＡＳ）との対話式通信を伴うことがある。

ＡＳとモバイルデータアプリケーションは、「ハートビート」メッセージ（「キープアライブ」メッセージとしても知られる）を定期的に交換して、アプリケーションセッションをアライブに維持することができるとともに、進行中のインターネットプロトコル（ＩＰ）セッションを切断させるおそれのあるネットワークアドレス変換（ＮＡＴ）マッピングの失効を回避することもできる。定期的なキープアライブメッセージに加えて、アプリケーションはまた、頻繁なステータス更新メッセージを生成して、アプリケーションに関連するステータス更新についてＷＴＲＵユーザに知らせることもある（例えば、インスタントメッセージング（ＩＭ）バディリスト中のバディのプレゼンス情報、ユーザ「チェックイン」時のユーザ位置の更新、ＷＴＲＵユーザの友達への「フェイスブックの”いいね”表明」の更新など）。

しかし、膨大な数のＷＴＲＵ上で実行される種々のアプリケーションに関連するこれらのキープアライブメッセージおよびステータス更新メッセージは、これらのＷＴＲＵの電池寿命にかなりの損害を与えることがある。さらに、これらのメッセージのせいで、コアネットワーク中のかなりのシグナリングトラフィック輻輳が生じることがある。

ワイヤレス送受信ユニット（ＷＴＲＵ）上で実行されるアプリケーションの「キープアライブ」メッセージ頻度を交渉するための方法および装置について記述される。ノードが、交渉および同期機能（ＮＳＦ）を備えてよく、このＮＳＦは、ＷＴＲＵ上で実行される種々のアプリケーションについてアプリケーションサーバによって必要とされるキープアライブメッセージの頻度を含む情報を収集し、キープアライブメッセージ頻度交渉要求メッセージをアプリケーションサーバに送って、各アプリケーションについてのより適切な頻度をＷＴＲＵに代わって交渉するように構成される。ノードはさらに、バッファリングおよびキャッシング機能（ＢＣＦ）を備えてよく、このＢＣＦは、各アプリケーションが定期的なキープアライブメッセージを関連アプリケーションサーバに送る必要があるかどうかの指示を含めた、アプリケーション特有属性を、キャッシュおよびバッファリングするように構成される。ノードは、パケットデータネットワークゲートウェイ、交渉およびキャッシングゲートウェイ、またはサービングゲートウェイであってよい。

添付の図面と共に例として提供される後続の記述から、より詳細な理解が得られるであろう。
１または複数の開示される実施形態がその中で実現され得る例示的な通信システムを示す図である。 図１Ａに示される通信システム内で使用され得る例示的なワイヤレス送受信ユニット（ＷＴＲＵ）を示す図である。 図１Ａに示される通信システム内で使用され得る例示的な無線アクセスネットワークおよび例示的なコアネットワーク（ＣＮ）を示す図である。 ロングタームエボリューション（ＬＴＥ）大域的アーキテクチャの例を示す図である。 非マシンタイプ通信（非ＭＴＣ）およびＭＴＣアプリケーションの一般的なアーキテクチャの例を示す図である。 電池寿命に対するキープアライブメッセージの影響の例を示す図である。 ＷＴＲＵが頻繁なアイドル−アクティブ状態遷移の問題を経験するときのタイミングの例を示す図である。 モバイルデータアプリケーションステータス更新およびキープアライブメッセージによって引き起こされる、シグナリング非効率性および短縮された電池寿命の例を示す図である。 パケットデータネットワークゲートウェイ（Ｐ−ＧＷ）中の、交渉および同期機能（ＮＳＦ）ならびにバッファリングおよびキャッシング機能（ＢＣＦ）の例を示す図である。 Ｐ−ＧＷ中のＢＣＦと、ポリシ制御および課金規則機能（ＰＣＲＦ）中のＮＳＦとの例を示す図である。 Ｐ−ＧＷ中のＢＣＦと、ポリシ制御および課金規則機能（ＰＣＲＦ）中のＮＳＦとの例を示す図である。 サービングゲートウェイ（Ｓ−ＧＷ）、Ｐ−ＧＷ、ＰＣＲＦ、およびインターネットとインタフェースする、交渉およびキャッシングゲートウェイ（ＮＣ−ＧＷ）中の、ＮＳＦおよびＢＣＦの例を示す図である。 Ｐ−ＧＷとインタフェースするＮＣ−ＧＷ中の、ＮＳＦおよびＢＣＦの例を示す図である。 ＷＴＲＵから発信されるかまたはＷＴＲＵをターゲットとする、Ｐ−ＧＷによって転送されるメッセージの属性の例を示す図である。 ＷＴＲＵ上のアプリケーションの情報の例を示す図である。 ＮＳＦが交渉を実施するのに有用な場合のある情報の例を示す図である。 キープアライブメッセージ頻度交渉要求メッセージの例を示す図である。 キープアライブメッセージ頻度交渉応答メッセージの例を示す図である。 頻度交渉プロシージャのメッセージフロー図の例を示す図である。 更新済み頻度通知メッセージの例を示す図である。 更新済み頻度通知メッセージの例を示す図である。 モバイル発信（ＭＯ）キープアライブメッセージ頻度交渉および更新プロシージャの例の流れ図である。 簡略化された頻度交渉要求メッセージの例を示す図である。 １つのＭＯキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されるときの頻度更新プロシージャの流れ図の例を示す図である。 複数のＭＯキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されてグループに分けられるときの、頻度更新プロシージャの流れ図の例を示す図である。 複数のＭＯキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されてグループに分けられるときの、頻度更新プロシージャの流れ図の例を示す図である。 複数のＭＯキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されてグループに分けられるときの、頻度更新プロシージャの流れ図の例を示す図である。 ＮＳＦによって送られるＭＯキープアライブメッセージ削減要求メッセージの例を示す図である。 ＷＴＲＵによって送られるＭＯキープアライブメッセージ削減応答メッセージの例を示す図である。 ＮＳＦによって開始されるＭＯキープアライブメッセージ削減プロシージャの例示的なメッセージフローを示す図である。 ＷＴＲＵによって送られるＭＯキープアライブメッセージ削減要求メッセージの例を示す図である。 ＷＴＲＵによって開始されるＭＯキープアライブメッセージ削減プロシージャの例示的なメッセージフローを示す図である。

図１Ａに、１または複数の開示される実施形態がその中で実現され得る例示的な通信システム１００を示す。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに提供する多元接続システムであってよい。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含めたシステムリソースの共有を通してこのようなコンテンツにアクセスするのを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１または複数のチャネルアクセス方法を採用することができる。

図１Ａに示されるように、通信システム１００は、ワイヤレス送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク（ＣＮ）１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含んでよいが、開示される実施形態が任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することは理解されるであろう。各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス環境で動作および／または通信するように構成された任意のタイプのデバイスであってよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されてよく、ユーザ機器（ＵＥ）、移動局、固定またはモバイルの加入者ユニット、ページャ、セルラ電話機、パーソナルディジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、消費者電子機器などを含み得る。

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでよい。各基地局１１４ａ、１１４ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインタフェースして、ＣＮ１０６、インターネット１１０、および／または他のネットワーク１１２など、１または複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスであってよい。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバステーション（ＢＴＳ）、Ｎｏｄｅ−Ｂ、進化型（evolved）Ｎｏｄｅ−Ｂ（ｅＮＢ）、Ｈｏｍｅ Ｎｏｄｅ−Ｂ（ＨＮＢ）、Ｈｏｍｅ ｅＮＢ（ＨｅＮＢ）、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどであってよい。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として描かれているが、基地局１１４ａ、１１４ｂが任意の数の相互接続された基地局および／またはネットワーク要素を含んでよいことは理解されるであろう。

基地局１１４ａはＲＡＮ１０４の一部であってよく、ＲＡＮ１０４はまた、他の基地局および／または基地局コントローラ（ＢＳＣ）や無線ネットワークコントローラ（ＲＮＣ）や中継ノードなどのネットワーク要素（図示せず）を含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理領域内でワイヤレス信号を送信および／または受信するように構成されてよく、この地理領域はセル（図示せず）と呼ばれることがある。セルはさらに、セルセクタに分割されてよい。例えば、基地局１１４ａに関連するセルが、３つのセクタに分割されてよい。したがって、一実施形態では、基地局１１４ａは、３つの送受信機、すなわちセルの各セクタにつき１つの送受信機を備えることができる。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用することができ、したがって、セルの各セクタにつき複数の送受信機を利用することができる。

基地局１１４ａ、１１４ｂは、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数と通信することができ、エアインタフェース１１６は、任意の適切なワイヤレス通信リンク（例えば無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であってよい。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてよい。

より具体的には、上記のように、通信システム１００は、多元接続システムであってよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなど、１または複数のチャネルアクセス方式を採用することができる。例えば、ＲＡＮ１０４中の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実装することができ、無線技術は、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインタフェース１１６を確立することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでよい。

別の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、進化型ＵＴＲＡ（Ｅ−ＵＴＲＡ）などの無線技術を実装することができ、無線技術は、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインタフェース１１６を確立することができる。

他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわちワールドワイドインターオペラビリティフォーマイクロウェーブアクセス（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００エボリューションデータオプティマイズド（ＥＶ−ＤＯ）、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ（登録商標））、エンハンストデータレートフォーＧＳＭエボリューション（ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装することができる。

図１Ａ中の基地局１１４ｂは、例えばワイヤレスルータ、ＨＮＢ、ＨｅＮＢ、またはＡＰであってよく、事業所、家庭、車両、キャンパスなどの局所化されたエリア中でのワイヤレス接続性を容易にするために任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えばＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂは、ＣＮ１０６を介してインターネット１１０にアクセスすることは必要とされなくてよい。

ＲＡＮ１０４は、ＣＮ１０６と通信してよく、ＣＮ１０６は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数に提供するように構成された、任意のタイプのネットワークであってよい。例えば、ＣＮ１０６は、呼制御、料金請求サービス、モバイル位置ベースサービス、前払い電話、インターネット接続性、ビデオ配信などを提供することができ、かつ／または、ユーザ認証など、高レベルのセキュリティ機能を実施することができる。図１Ａには示されていないが、ＲＡＮ１０４および／またはＣＮ１０６は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと、直接的または間接的に通信してもよいことは理解されるであろう。例えば、ＣＮ１０６は、Ｅ−ＵＴＲＡ無線技術を利用しているであろうＲＡＮ１０４に接続されるのに加えて、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信してもよい。

ＣＮ１０６はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとしての働きをすることができる。ＰＳＴＮ１０８は、プレーンオールドテレフォンサービス（ＰＯＴＳ）を提供する回路交換電話網を含んでよい。インターネット１１０は、ＴＣＰ／ＩＰスイート中の、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスの地球規模のシステムを含んでよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される、有線またはワイヤレス通信ネットワークを含んでよい。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用するであろう１または複数のＲＡＮに接続された、別のＣＮを含んでよい。

通信システム１００中のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたは全ては、マルチモード能力を備えることができる。すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、種々のワイヤレスリンクを介して種々のワイヤレスネットワークと通信するために、複数の送受信機を備えることができる。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用するであろう基地局１１４ａと、かつＩＥＥＥ８０２無線技術を採用するであろう基地局１１４ｂと、通信するように構成されてよい。

図１Ｂに、図１Ａに示される通信システム１００内で使用され得る例示的なＷＴＲＵ１０２を示す。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送受信要素（例えばアンテナ）１２２、スピーカ／マイクロホン１２４、キーパッド１２６、表示装置／タッチパッド１２８、非取外し可能メモリ１３０、取外し可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および周辺装置１３８を備えてよい。ＷＴＲＵ１０２が実施形態との整合性を維持しながら前述の要素の任意のサブコンビネーションを備えてよいことは理解されるであろう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、マイクロプロセッサ、ＤＳＰコアに関連する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、集積回路（ＩＣ）、状態機械などであってよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／または、ＷＴＲＵ１０２がワイヤレス環境で動作できるようにする他の任意の機能を実施することができる。プロセッサ１１８は送受信機１２０に結合されてよく、送受信機１２０は送受信要素１２２に結合されてよい。図１Ｂではプロセッサ１１８と送受信機１２０とを別々のコンポーネントとして描いているが、プロセッサ１１８と送受信機１２０とは共に電子パッケージまたはチップ中で統合されてもよい。

送受信要素１２２は、エアインタフェース１１６を介して基地局（例えば基地局１１４ａ）との間で信号を送信または受信するように構成されてよい。例えば、一実施形態では、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってよい。別の実施形態では、送受信要素１２２は、例えばＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された、エミッタ／検出器であってよい。さらに別の実施形態では、送受信要素１２２は、ＲＦ信号と光信号の両方を送受信するように構成されてよい。送受信要素１２２は、任意の組合せのワイヤレス信号を送信および／または受信するように構成されてよい。

加えて、図１Ｂでは送受信要素１２２が単一の要素として描かれているが、ＷＴＲＵ１０２は、任意の数の送受信要素１２２を備えてよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用することができる。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６を介してワイヤレス信号を送受信するために、２つ以上の送受信要素１２２（例えば複数のアンテナ）を備えることができる。

送受信機１２０は、送受信要素１２２によって送信されることになる信号を変調し、送受信要素１２２によって受信された信号を復調するように構成されてよい。上記のように、ＷＴＲＵ１０２は、マルチモード能力を有することができる。したがって、送受信機１２０は、ＷＴＲＵ１０２が複数のＲＡＴ（例えばＵＴＲＡおよびＩＥＥＥ８０２．１１など）を介して通信できるようにするために、複数の送受信機を備えることができる。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、表示装置／タッチパッド１２８（例えば液晶表示装置（ＬＣＤ）表示ユニットもしくは有機発光ダイオード（ＯＬＥＤ）表示ユニット）に結合されてよく、これらからユーザ入力データを受け取ることができる。プロセッサ１１８はまた、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、表示装置／タッチパッド１２８にユーザデータを出力することができる。加えて、プロセッサ１１８は、非取外し可能メモリ１３０および／または取外し可能メモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスすること、およびそのようなメモリにデータを記憶することができる。非取外し可能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含んでよい。取外し可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアディジタル（ＳＤ）メモリカードなどを含んでよい。他の実施形態では、プロセッサ１１８は、サーバやホームコンピュータ（図示せず）上のメモリなど、ＷＴＲＵ１０２上に物理的に位置しないメモリからの情報にアクセスすること、およびそのようなメモリにデータを記憶することができる。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２中の他のコンポーネントへの電力を分配および／または制御するように構成されてよい。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスであってよい。例えば、電源１３４は、１または複数の乾電池バッテリ（例えばニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含み得る。

プロセッサ１１８はまた、ＧＰＳチップセット１３６に結合されてよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば経度と緯度）を提供するように構成されてよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれに代えて、ＷＴＲＵ１０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１６を介して位置情報を受信することができ、かつ／または、２つ以上の近隣基地局から受信されている信号のタイミングに基づいてその位置を決定することができる。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら任意の適切な位置決定方法によって位置情報を取得することができる。

プロセッサ１１８はさらに、他の周辺装置１３８に結合されてよく、周辺装置１３８は、追加の特徴、機能、および／または有線もしくはワイヤレス接続性を提供する、１または複数のソフトウェアおよび／またはハードウェアモジュールを含み得る。例えば、周辺装置１３８は、加速度計、電子コンパス、衛星送受信機、ディジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョン送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、ディジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含み得る。

図１Ｃに、図１Ａに示される通信システム１００内で使用され得る例示的なＲＡＮ１０４および例示的なＣＮ１０６を示す。上記のように、ＲＡＮ１０４は、ＵＴＲＡ無線技術を採用して、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０４はまた、ＣＮ１０６とも通信してよい。

ＲＡＮ１０４は、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃを含んでよいが、ＲＡＮ１０４が実施形態との整合性を維持しながら任意の数のｅＮＢを含んでよいことは理解されるであろう。ｅＮＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために、１または複数の送受信機を備えることができる。一実施形態では、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実装することができる。したがって、例えばｅＮＢ１４０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａとの間でワイヤレス信号を送受信することができる。

各ｅＮＢ１４０ａ、１４０ｂ、および１４０ｃは、特定のセル（図示せず）に関連してよく、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを扱うように構成されてよい。図１Ｃに示されるように、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インタフェースを介して相互と通信することができる。

図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含んでよい。前述の各要素はＣＮ１０６の一部として描かれているが、これらの要素の任意の１つがＣＮオペレータ以外のエンティティによって所有および／または運営されてもよいことは理解されるであろう。

ＭＭＥ１４２は、Ｓ１インタフェースを介してＲＡＮ１０４中の各ｅＮＢ１４０ａ、１４０ｂ、１４０ｃに接続されてよく、制御ノードとしての働きをすることができる。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラをアクティブ化／非アクティブ化すること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初のアタッチ中に特定のサービングゲートウェイを選択することなどを担うことができる。ＭＭＥ１４２はまた、ＲＡＮ１０４と、ＧＳＭやＷＣＤＭＡなど他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供することができる。

サービングゲートウェイ１４４は、Ｓ１インタフェースを介してＲＡＮ１０４中の各ｅＮＢ１４０ａ、１４０ｂ、１４０ｃに接続されてよい。サービングゲートウェイ１４４は一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でユーザデータパケットをルーティングおよび転送することができる。サービングゲートウェイ１４４はまた、ｅＮＢ間ハンドオーバ中にユーザプレーンをつなぎ留めること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときにページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなど、他の機能を実施することもできる。

サービングゲートウェイ１４４はまた、ＰＤＮゲートウェイ１４６にも接続されてよく、ＰＤＮゲートウェイ１４６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。

ＣＮ１０６は、他のネットワークとの通信を容易にすることができる。例えば、ＣＮ１０６は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインタフェースとしての働きをするＩＰゲートウェイ（例えばＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、またはそのようなＩＰゲートウェイと通信することができる。加えて、ＣＮ１０６は、他のサービスプロバイダによって所有および／または運営される他の有線またはワイヤレスネットワークを含み得るネットワーク１１２へのアクセスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

ＬＴＥネットワークは、展開された第３世代パートナーシッププロジェクト（３ＧＰＰ）ネットワークの次世代であろう。本明細書で述べられる概念は、ＬＴＥネットワークに限定されず、ＵＭＴＳ、ＧＳＭ、ＣＤＭＡ２０００など、他の３ＧＰＰネットワークにも適用可能とすることができる。

図２に、進化型ＵＭＴＳ地上無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ）２０５と進化型パケットコア（ＥＰＣ）ネットワーク２１０とを含むＬＴＥネットワーク２００の大域的アーキテクチャの例を示す。Ｅ−ＵＴＲＡＮ２０５は、複数のＷＴＲＵ２１５、および進化型Ｎｏｄｅ−Ｂ（ｅＮＢ）２２０を含んでよい。ｅＮＢ２２０は、無線管理などの機能を統合する基地局であってよい。ＥＰＣネットワーク２１０は、ＬＴＥネットワーク２００のＣＮ部分としての働きをすることができる。ＥＰＣネットワーク２１０は、ＷＴＲＵ２１５の全体的な制御、および、ＷＴＲＵ２１５とＰＤＮゲートウェイ（Ｐ−ＧＷ）２２５との間のベアラの確立を担うことができる。ベアラは、ＷＴＲＵ２１５とＰ−ＧＷ２２５との間のパケットフローまたはトンネルであってよい。

ＥＰＣネットワーク２１０中のＰ−ＧＷ２２５は、オペレータのＩＰネットワークとの接続を保証するように構成されてよい。Ｐ−ＧＷ２２５は、ＷＴＲＵ２１５にＩＰアドレスを割り振ることを担うことができる。Ｐ−ＧＷ２２５はまた、ダウンリンクパケットを、種々のサービス品質（ＱｏＳ）および宛先（ＷＴＲＵ）のベアラにフィルタリングすることができる。

ＥＰＣネットワーク２１０は、サービングゲートウェイ（Ｓ−ＧＷ）２３０を含んでよく、Ｓ−ＧＷ２３０は、ＷＴＲＵ２１５がｅＮＢ２２０から別のｅＮＢに移動する（ハンドオーバ）ときに、データベアラのためのアンカとしての働きをすることができる。Ｓ−ＧＷ２３０はまた、ＷＴＲＵ２１５がアイドル状態である（すなわち、電力節約のためにオフに切り替えられて、それが使用する無線帯域幅を他のＷＴＲＵのために解放する）ときに、かつモビリティ管理エンティティ（ＭＭＥ）２３５がＷＴＲＵ２１５とのベアラを再確立する間に、ダウンリンクベアラのデータを保持することができる。

ＭＭＥ２３５は、ＷＴＲＵ２１５とＥＰＣネットワーク２１０との間のシグナリングを処理することを担うことができるので、ＬＴＥアーキテクチャ２００中で重要な要素としての働きをすることができる。ＭＭＥ２３５は、ベアラ管理（確立、維持、および解放）に関係する機能、ならびに、アタッチおよび接続管理（ＥＰＣネットワーク２１０とＷＴＲＵ２１５との間の接続およびセキュリティの確立、認証）に関係する機能を実施することができる。ＭＭＥ２３５は、ＷＴＲＵ２１５に関する情報を保持することによって、無線ネットワーク中のオーバヘッドを低減する助けとなることができ、これは、ＷＴＲＵ２１５がアイドル状態のときに継続性を確実にすることができる。これらの機能は、非アクセス層（ＮＡＳ）プロトコル中のセッション管理レイヤによって扱われてよい。

ポリシ制御および課金規則機能（ＰＣＲＦ）２４０Ａおよび２４０Ｂが、ポリシ制御施行機能（ＰＣＥＦ）中の、ポリシ制御決定とフローベースの課金機能の管理とを担うことができる。ＰＣＥＦは、Ｐ−ＧＷ２２５中にあってよく、ＱｏＳ情報（ＱｏＳクラス識別子（ＱＣＩ）およびビットレート）を提供することができる。この情報は、あるデータフローがＰＣＥＦ中で（Ｐ−ＧＷ２２５によって）どのように扱われ得るかを決定し、また、これがユーザの加入プロファイルに従うことを確実にすることができる。

ＷＴＲＵ上で実行される、人間対話を通常必要とする非ＭＴＣアプリケーションのいくつかは、ウェブを閲覧したり電子メールを読んだりするなど、より「伝統的な」使用事例に焦点を合わせるものである場合があるが、ソーシャルネットワーキングアプリケーションなど、新たに出現しつつある他のアプリケーションは、ユーザが出先で自分の友達と「つながったままでいる」ための助けとなることができる。モバイル非ＭＴＣデータアプリケーションの種々のカテゴリは、ウェブ閲覧、電子メール、天気／ニュース更新、ボイスオーバＩＰ（ＶｏＩＰ）（例えばＳｋｙｐｅなど）、ソーシャルネットワーキング（Ｆａｃｅｂｏｏｋ）、ジオサービス（Ｇｏｏｇｌｅ ｐｌａｃｅｓ／位置にターゲットを絞った広告）、オンラインゲーム、ならびにメッセージング（ショートメッセージサービス（ＳＭＳ）およびインスタントメッセージング）を含み得る。

ＭＴＣアプリケーションは、人間対話を必ずしも必要としない自動化されたマシンまたはデバイス通信とすることができる。ＭＴＣアプリケーションは、今日、軍事応用例から民間応用例までの範囲にわたるほぼどんな日常生活応用例においても使用されることがあり、これらの応用例は、セキュリティ（アラームシステム、自動車／運転手セキュリティ）、トラッキングおよびトレーシング（フリート管理、注文管理、ナビゲーション、交通最適化／操舵）、支払い（販売時点、ゲーミングマシン）、ヘルスケア（バイタルサインの監視、リモート診断）、リモート保守／制御（センサ、照明、ポンプ、エレベータ制御）、計測（電力、ガス、水、グリッド制御）などである。これらのＭＴＣアプリケーションは一般に、ＬＴＥネットワークなどの広く展開されたネットワークを通して、広いエリアにわたって配布される。

図３に、非ＭＴＣ ＷＴＲＵ３０５およびＭＴＣ ＷＴＲＵ３１０上で実行される非ＭＴＣアプリケーションおよびＭＴＣアプリケーションの一般的なアーキテクチャ３００を示す。非ＭＴＣ ＷＴＲＵ３０５およびＭＴＣ ＷＴＲＵ３１０は、外部ネットワーク３２０中にある複数のアプリケーションサーバ（ＡＳ）３１５のうちの１つと、ＬＴＥネットワーク３２５を介して通信することができる。

加入者が始めることができ意識していることができるネットワーク接続に加えて、いわゆるキープアライブメッセージの存在が、非ＭＴＣ ＷＴＲＵ３０５とＭＴＣ ＷＴＲＵ３１０の両方の場合にあることがあり、キープアライブメッセージは、加入者に知られることなく発生する場合がある。ＭＴＣ ＷＴＲＵ３１０の場合、アラームシステム、エレベータ制御、およびバイタルサイン監視をサポートするアプリケーションのいくつかは、ＭＴＣ ＷＴＲＵ３１０がアライブかつ到達可能であることをＡＳ３１５に通知する必要があることがある。非ＭＴＣ ＷＴＲＵ３０５の場合、キープアライブメッセージを使用して、ユーザの（すなわち加入者の）ステータスの更新が提供されることがある（例えば「自分がどこにいるか」、「自分がＩＭメッセージに応答できる状態であるか」など）。これらのキープアライブメッセージは、非ＭＴＣ ＷＴＲＵが使用されていないように見えるときでも、アプリケーションがアクティブである限り、非ＭＴＣ ＷＴＲＵ３０５によって絶えず送られるであろう。キープアライブメッセージは、データトラフィックについてはほとんど生成しないであろうが、膨大な量のシグナリングトラフィックを生成するであろうし、また非ＭＴＣ ＷＴＲＵの予想電池寿命にも影響を及ぼすおそれがある。したがって、キープアライブメッセージを送るのに必要とされるシグナリングトラフィックの量は、有意な量のデータが送られるデータセッションをセットアップするのに必要とされるシグナリングトラフィックの量と何ら違いはないであろう。以下、非ＭＴＣ ＷＴＲＵおよびＭＴＣ ＷＴＲＵは、単にＷＴＲＵとして言及される。

図４に、キープアライブメッセージが電話機の電池をどれだけ消耗させるかに関する例を示す。図４には、様々な頻度を、ＷＴＲＵ上のバックライトがまる１時間にわたってオンに切り替えられる時間量と比較することによって、キープアライブメッセージの影響を示す。例えば、図４に示されるように、７．５３時間（ほぼまる８時間の就業日）にわたる、毎分１つのキープアライブメッセージの頻度は、ＷＴＲＵのバックライトを６０分（まる１時間）にわたってオンに維持するのに必要とされるよりも多くのエネルギーを必要とすることがある。

キープアライブメッセージの頻度は、過剰な電池消耗による問題を呈するおそれがある。ＳｋｙｐｅやＦｒｉｎｇなどのＶｏＩＰアプリケーションは、３０秒ごとから８分ごとにキープアライブメッセージを生成することがある。ステータス更新メッセージの頻度も、同様の問題を呈するおそれがある。ＦｉｎｄＭｅなどのソーシャルネットワーキングアプリケーションは、地理的位置の変化時にステータス更新メッセージを生成することがある。このようなメッセージの頻度は、１日にわたる散発的な頻度（例えば、家から職場へ、ジムへと変化し、次いで家に戻る）から、６０分ごとまでの定期的な頻度までの範囲に及ぶことがある。ソーシャルネットワーキングサーバは、加入者の友達のコンテンツおよびプレゼンス更新メッセージを、ＷＴＲＵ上のアプリケーションにプッシュすることがある（例えば、Ｆａｃｅｂｏｏｋは、自分の友達が特定の記事に「いいね」を表明したときまたは特定のグループの「ファンになった」ときに、アクティビティを投稿することがある）。このようなコンテンツおよびプレゼンス更新メッセージの頻度は、およそ数分ごとに推定されることがある。

ステータス更新およびキープアライブメッセージの影響を悪化させるおそれのある１つの側面は、これらのメッセージが、モバイルによって発信される（以下、モバイル発信）（ＭＯ）か、またはモバイルによって終端される（以下、モバイル終端）（ＭＴ）場合があることであり、例えば、定期的なＦｉｎｄＭｅメッセージは、友達の位置の変化から、またはＷＴＲＵユーザ自身の位置の更新からくる場合がある。別の側面は、複数のアプリケーションが単一のＷＴＲＵにインストールされることが普通にあり、その場合に各アプリケーションがこれらの更新／キープアライブメッセージを自律的に生成する場合があることである。

キープアライブまたはステータス更新メッセージの送信が完了したとき、およびユーザ非アクティブ性の検出時、ＷＴＲＵは、ＷＴＲＵの電池電力を節約するために、低電力状態に（例えば接続状態からアイドル状態に）移行されることがある。結果として、ステータス更新および／またはキープアライブメッセージの平均頻度が非アクティブ性タイマよりも高いとき、ＷＴＲＵは、アイドル、ウェイクアップ、接続の再確立、更新メッセージの送信または受信、アイドルへの回帰、などの間で循環しなければならないことがある。

図５に、ＷＴＲＵが頻繁なアイドル−アクティブ状態遷移の問題を経験するときのタイミングの例を示す。図５に（左から右へ）示されるように、ＷＴＲＵは、いくらかのデータトラフィックの処理を完了した後、しばらくの間アクティブ状態５０５に留まり、次いでアイドル状態５１０に遷移して電池電力を温存することができる。ＷＴＲＵがアイドル状態５１０に入ったすぐ後で、第１のアプリケーション５１５₁が、更新メッセージ５２０を生成し、ＷＴＲＵに対して、ウェイクアップしていくつかのシグナリングメッセージを送受信し接続を確立するようにさせることがある。ＷＴＲＵは、アクティブ状態５０５だがメッセージを送っていないときよりも多くのエネルギーを、シグナリングメッセージの送受信で消費する可能性がある。接続を確立した後、ＷＴＲＵは、更新メッセージ５２０を送り、アイドル状態５１０に移る前に再びしばらくの間アクティブ状態５０５に留まることができる。このサイクルは、他のアプリケーションもまた更新メッセージ５２０を送受信する（例えば、いくつかのＭＴ更新メッセージが第２のアプリケーション５１５₂によってプッシュされることがあり、いくつかのＭＯ更新メッセージが第３のアプリケーション５１５₃によって生成されることがある）間に、繰り返す。

ＷＴＲＵがアクティブ状態とアイドル状態との間で絶えず転回するとき、観察され得る２つの問題がある。第１の問題は、これらの時折起こる非常に小さい更新メッセージを送るための、増大した制御プレーンシグナリング（この場合、過剰なシグナリングオーバヘッドがある（ＲＡＮ中とＣＮ中の両方で））であろう。わずか１つの更新メッセージを送るのに、１ラウンドのアイドル−アクティブ遷移を要することがあり、これはかなりのシグナリングオーバヘッドを課すことがある。このシグナリングオーバヘッドは、ＲＡＮ中の複数の無線リソース制御（ＲＲＣ）メッセージ（例えば、サービス要求、無線ベアラ確立／解放、および、メッセージがＭＴメッセージであるときのページング）、ならびにＥＰＣシグナリングメッセージ（例えば、サービス要求、接続セットアップ／解放）を含む。第２の問題は、ＷＴＲＵの短縮された電池寿命であろう。最悪のケースのシナリオでは、ＷＴＲＵがアイドル状態５１０に入ったすぐ後で複数のアプリケーション５１５が更新メッセージを生成するとき、アクティブ状態５０５とアイドル状態５１０との間で絶えず転回することによって生成される場合のある余分なシグナリングのせいでＷＴＲＵのエネルギー消費が増加することがあり、ＷＴＲＵがアクティブ状態５０５に留まった方が電力消費はよりよいことがある。

図６に、モバイルデータアプリケーションステータス更新およびキープアライブメッセージによって引き起こされる、シグナリング非効率性および短縮された電池寿命を生じさせる可能性のある頻繁なアイドル−アクティブ状態遷移シナリオの、問題シナリオと、問題の根源と、影響を受ける要素とを要約する。

ＷＴＲＵ上で実行される種々のアプリケーションからのステータス更新メッセージおよびキープアライブメッセージに関するシグナリングトラフィックを低減すること、ならびに、ＷＴＲＵのエネルギー消費を低減してその電池寿命を延ばすことが望まれる。これらの目標を達成するために、ＷＴＲＵがより長い期間にわたってアイドル状態に留まることが望まれる。加えて、ＷＴＲＵがアクティブ状態のときにＷＴＲＵが複数の実行中アプリケーションの更新メッセージおよびキープアライブメッセージを受信および送信できるように、キープアライブメッセージをアプリケーションにまたがって同期させることが望まれる。結果として、ＷＴＲＵは、アイドル状態と、接続の再確立と、メッセージの送受信と、アイドル状態への回帰との間で非常に頻繁に循環しなくてもよいであろう。固定された期間中の削減されたサイクル数は、ＷＴＲＵの電池寿命を著しく延ばし、ＣＮおよびＲＡＮ中のシグナリングトラフィックを低減することができる。

交渉および同期機能（ＮＳＦ）と呼ばれる新しいネットワーク機能が、Ｐ−ＧＷ中またはＰ−ＧＷと密接に結合されたノード中など、ＣＮノード中にあってよい。Ｐ−ＧＷは、ＣＮの境界にあってよい。ＭＯメッセージについては、ＮＳＦは、ＷＴＲＵのトラフィックがＰ−ＧＷの中を通って外部ネットワークに行きＡＳに到達し得る場合の、ＷＴＲＵの代理としての役割を果たすことができる。

ＮＳＦは、ＷＴＲＵ上の実行中アプリケーションのＡＳと交渉して、ＷＴＲＵがどれくらいの頻度で更新メッセージおよび／またはキープアライブメッセージを送る必要があるか決定することを担当することができる。次いでＮＳＦは、交渉された頻度（複数可）をＷＴＲＵに通信することができる。交渉に基づいて、１つの頻度が全ての実行中アプリケーションについて同意される場合は、ＷＴＲＵは、その実行中アプリケーションのキープアライブメッセージを、同期された方式で送ることができる。あるいは、１つの頻度が全ての実行中アプリケーションについて同意されることはないが、アプリケーションが種々の同意された頻度パラメータによりグループに分けられ得る場合は、ＷＴＲＵは、実行中アプリケーションの各グループのキープアライブメッセージを、同期された方式で送ることができる。

ＮＳＦは、仮想キープアライブメッセージについてＷＴＲＵと交渉することを担当することができる。非常に低い頻度をＡＳが求める場合、通常の状況では、ＷＴＲＵは、キープアライブメッセージを一定ベースで送ることがあり、代理サーバは、頻度を低減することについてＡＳと同意に達しないことがある。ＮＳＦは、より低い頻度のキープアライブメッセージをＷＴＲＵに要求することができるが、ＮＳＦは、キープアライブメッセージがどれくらい長く有効かを示すことができる。代理サーバは、ＡＳが求める頻度で仮想キープアライブメッセージを送ることができる。他方、ＷＴＲＵは、ＡＳが知ることなくＷＴＲＵの代わりに仮想キープアライブメッセージを送るよう、Ｐ−ＧＷに事前対策的に要求することができる。

ＷＴＲＵは、ＮＳＦによって同意された頻度（複数可）に基づいて、そのアクティブ状態およびアクティブ期間を設定することができる。

バッファリングおよびキャッシング機能（ＢＣＦ）と呼ばれる新しいネットワーク機能が、ＣＮ境界にあってよく、おそらくはＰ−ＧＷ中にあるかまたはＰ−ＧＷに密接に結合されてよい。ＢＣＦは、種々のＡＳからＷＴＲＵへのステータス更新メッセージをバッファリングすることを担当することができる。ＢＣＦは、ＷＴＲＵをターゲットとするアプリケーションメッセージを、優先度または重みを有する種々のタイプに分類することができる。ＢＣＦは、ＷＴＲＵのバッファ空間が一杯のときに、またはＷＴＲＵがアウェイクでありリッスンしていることがわかっている期間中に、メッセージがＷＴＲＵに送達されるのを許可することができる。特定のＡＳからの更新メッセージが、バッファリングされることを許可されない場合、または高優先度として分類される場合は、メッセージはすぐにＷＴＲＵに向けて転送されてよく、ＷＴＲＵは、メッセージを受け取れるようにページングされてよい。

ＢＣＦは、データ維持を担う。ＮＳＦは、制御を担当する。図７、８Ａ、８Ｂ、９Ａ、および９Ｂに、ＷＴＲＵがアクセスおよびＣＮエンティティを介して種々のＡＳと通信する全体的なアーキテクチャの、種々のオプションを示す。

図７に示されるように、ＮＳＦ７０５とＢＣＦ７１０は両方とも、Ｐ−ＧＷ７１５中にあってよい。ＮＳＦ７０５およびＢＣＦ７１０は、ＳＧｉインタフェース７２５を介して種々のＡＳ７２０と通信することができ、Ｓ８インタフェース７３５を介してＳ−ＧＷ７３０と通信することができる。Ｐ−ＧＷ７１５は、インターネット７４０へのアクセスを提供する。

図８Ａおよび８Ｂでは、ＢＣＦ７１０はＰ−ＧＷ７１５中にあってよく、一方ＮＳＦ７０５はＰＣＲＦ８０５中にあってよい。図８Ａには、ＭＴＣシナリオと非ＭＴＣシナリオの両方に適するであろうアーキテクチャおよび参照ポイントを示す。ＢＣＦ７１０は、ＳＧｉ７２５を介してＡＳ７２０と通信することができ、一方ＮＳＦ７０５は、Ｒｘ８１０を介してＡＳ７２０と通信することができる。図８Ｂには、ＭＴＣシナリオの場合のアーキテクチャおよび参照ポイントを示すが、この場合、ＮＳＦ７０５は、参照ポイントを介して（Ｒｘ８１０を介して）ＭＴＣ−ＩＷＦ８１５と通信することができる。ＭＴＣ−ＩＷＦ８１５は、Ｔｓｐ８２５を介してサービス能力サーバ（ＳＣＳ）８２０と通信することができる。ＢＣＦ７１０は、ＳＧｉ７２５を介してＳＣＳ８２０と通信することができる。

図９Ａおよび９Ｂに、ＮＳＦ７０５およびＢＣＦ７１０が、交渉およびキャッシングゲートウェイ（ＮＣ−ＧＷ）９００と呼ばれる新しいスタンドアロンノード中にあるのを示す。図９Ａには、ＮＣ−ＧＷ９００が、新たに定義されたＳｎインタフェース９０５によってＳ−ＧＷ７３０と対話し、新たに定義されたインタフェースＮｉ９１０を介して種々のＡＳ７２０と対話し、新たに定義されたインタフェースＧｎ９１５によってＰ−ＧＷ７１５と対話し、新たに定義されたインタフェースＮｘ９２０によってＰＣＲＦ８０５と対話するのを示す。

図９Ｂでは、ＮＣ−ＧＷ９００は、新たに定義されたインタフェースＧｎ９１５によって、Ｐ−ＧＷ７１５とのみ直接に対話することができるが、Ｐ−ＧＷ７１５を介して、Ｓ−ＧＷ７３０、ＰＣＲＦ８０５、およびインターネット７４０と間接的に通信することができる。

ＢＣＦは、ＷＴＲＵに関係する以下の情報を維持することを担当することができる。すなわち、アクティブおよびアイドルスケジュールと、実行中のアプリケーションと、種々のＡＳからの、ＷＴＲＵをターゲットとするメッセージ（更新メッセージなど）とである。実行中の各アプリケーションは、そのポート識別（ＩＤ）によって識別されることが可能である。各アプリケーションにつき、関連するＡＳに定期的なキープアライブメッセージをアプリケーションが送る必要があるかどうかを示すアプリケーション特有の属性およびメッセージが、キャッシュされバッファリングされる。アプリケーションが定期的なキープアライブメッセージを送る必要がある場合は、時間に伴って変化する場合のある頻度、ならびに、キープアライブメッセージの送信先である関連するＡＳが、示されてよい。この情報は、宛先トランスポートアドレス（例えばＩＰアドレス／ポートＩＤ）として記憶されてよい。アプリケーションが定期的なキープアライブメッセージを送る必要がある場合は、最新のキープアライブメッセージがキャッシュされてよい。

ＷＴＲＵが、延長された間欠受信（ＤＲＸ）サイクルをサポートするように構成された場合、または１日のうちのいくつかの時点で通信するようにプロビジョニングされた場合は、ＢＣＦは、ＷＴＲＵのアクティブ／アイドルスケジュールを、ホーム加入者サーバ（ＨＳＳ）、ＭＭＥ、またはＳＣＳから取得することができる。あるいは、アクティブおよびアイドルスケジュールは、各ＷＴＲＵに向けてＰ−ＧＷによって転送されるメッセージから推論されてもよい。ＷＴＲＵは、ＷＴＲＵからＡＳへのメッセージをＰ−ＧＷが受け取ったときにアクティブであるものとすることができる。したがって、ＢＣＦは、ＷＴＲＵから発信されたメッセージを受け取った時間をキャッシュすることができる。結果として、Ｐ−ＧＷの中を通るトラフィックを有する各ＷＴＲＵにつき、ＢＣＦは、図１０に示されるように、ＷＴＲＵから発信されＰ−ＧＷによって転送されるメッセージの属性を記録することができる。Ｐ−ＧＷはまた、ＷＴＲＵがＰ−ＧＷに事前対策的に知らせることによって、またはＡＳから取り出すによって、アクティブおよびアイドル状態スケジュールを得ることもできる。

ＷＴＲＵ上の実行中の各アプリケーションにつき、ＢＣＦは、図１１に示されるように、アプリケーションに関係する、ステータス、属性、モバイル発信（ＭＯ）または／およびモバイル終端（ＭＴ）メッセージを維持することができる。この情報は、制御のためにＮＳＦによって利用されてよい。

ＮＳＦは、以下の機能を有する。すなわち、元のＭＯキープアライブメッセージ頻度情報照会、ＭＯキープアライブメッセージ頻度交渉および解決、ＭＯキープアライブメッセージ頻度更新、ＭＯキープアライブメッセージ削減、ならびに、ＭＴメッセージバッファリングおよび優先である。

ＷＴＲＵに対して、ＮＳＦは、種々の実行中アプリケーションについてＡＳによって必要とされるキープアライブメッセージの頻度を収集することができる。この情報は、ＮＳＦによって要求されてＢＣＦから取り出されてよい。図１２の情報に基づいて、ＮＳＦは、「常に実行中」のアプリケーションがキープアライブメッセージを種々のＡＳに送ることができるように、ＷＴＲＵ上で実行されるアプリケーションをフィルタにかけることができる。したがって、ＮＳＦは、キープアライブメッセージ頻度、ならびにこれらのアプリケーションの関連ＡＳのコンタクトアドレスを取り出すことができる。Ｐ−ＧＷの中を通るトラフィックを有する各ＷＴＲＵにつき、ＮＳＦは、図１２に示される情報を使用して、以下のプロシージャを実施することができる。

図１３に、キープアライブメッセージ頻度交渉要求メッセージ１３００を示す。ＮＳＦは、要求メッセージ１３００をこれらの関連ＡＳに送って、実行中の各アプリケーションのより適切な頻度を求めてＷＴＲＵに代わって交渉することができる。より適切な頻度は、ＷＴＲＵがキープアライブメッセージを送る先となるであろう種々のＡＳによってこの頻度が同意され得ることを示すものとすることができる。要求メッセージ１３００は、メッセージ識別子（ＩＤ）１３０５、ＷＴＲＵ ＩＤ１３１０、アプリケーション数を示すフィールド１３１５、アプリケーションＩＤフィールド１３２０₁，１３２０₂，．．．，１３２０_n、キープアライブメッセージ頻度フィールド１３２５₁，１３２５₂，．．．，１３２５_n、および、提案される頻度（以下、提案頻度）を示すフィールド１３３０を含んでよい。

メッセージＩＤは、応答メッセージ１４００を要求メッセージ１３００にマッチさせるためにエコーされてよい。アプリケーション数フィールド１３１５は、後続の、アプリケーションＩＤと頻度との組合せの数を示すことができる。ＮＳＦが提案する最適な頻度は、現在の頻度の全てのうちの最大とすることができる。要求メッセージ１３００は、関係するＡＳにマルチキャストまたはユニキャストされてよい。要求メッセージ１３００をマルチキャストすることをＮＳＦが選んだ場合は、要求メッセージ１３００は、図１３に示されるようなフォーマットを有することができる。要求メッセージをユニキャストすることをＮＳＦが選んだ場合は、要求メッセージ１３００は、宛先ＡＳに対応するであろうアプリケーションＩＤフィールド１３２０およびアプリケーション頻度フィールド１３２５を含まなくてよい。例えば、特定のＡＳに送られるであろう頻度交渉要求メッセージ１３００から、フィールド１３２０₁および１３２５₁が除去されてよい。特定のＡＳは、それ自体のデータベースからのＷＴＲＵ ＩＤおよびアプリケーションＩＤに基づいて、頻度を見出すことができるであろう。したがって、要求メッセージ１３００のサイズ、および要求メッセージ１３００を送信するための帯域幅使用量が削減されることが可能である。しかし、ユニキャスティング送信が使用されるかマルチキャスティング送信が使用されるかにかかわらず、要求メッセージ１３００中の全てのアプリケーションＩＤおよび頻度が含まれてもよい。

アプリケーションごとの頻度パラメータが、Ｐ−ＧＷによって、それが転送および検分したキープアライブメッセージから推論されてよいが、この頻度パラメータは、ＡＳがそのデータベースに保持する頻度パラメータと全く同じではない可能性がある。したがって、一見重複する情報を使用して、Ｐ−ＧＷがアプリケーションごとの正しい頻度パラメータを知るかどうか検証することができる。ＡＳは、値を、ローカルに記憶された値と比較し、正しい値をＰ−ＧＷに通知することが可能とすることができる。Ｐ−ＧＷは、パラメータを訂正し、その頻度推論アルゴリズムを将来の使用に向けて調整することができる。

ＡＳが頻度交渉要求メッセージ１３００を受け取ったとき、ＡＳは、ＷＴＲＵ上の全ての実行中アプリケーションのキープアライブメッセージ頻度ならびにＮＳＦからの提案頻度の情報を、取り出すことができる。ＡＳはまず、それ自体のアプリケーションについて必要とする頻度の正しさをチェックし、そのデータベース中のパラメータと比較することができる。正しい場合は、有効コードが応答メッセージに含められてよい。そうでない場合は、無効コードおよび正しいパラメータが含められてよい。ＡＳはまた、提案頻度をチェックして、受諾できるかどうか確認することができる。ＷＴＲＵ上のアプリケーションが提案頻度でキープアライブメッセージを送ることをＡＳが許可できる場合は、この頻度は、応答メッセージ中の提案頻度フィールド中でエコーされてよい。そうでない場合は、ＡＳは、要求メッセージ中の他のアプリケーションの頻度を調べ、それ自体の提案頻度を案出することができる。ＡＳは、元の頻度に固執することもでき、または、他のアプリケーションの頻度とＮＳＦからの提案頻度とを入力として、そのプロプラエタリアルゴリズムを使用することもできる。

図１４に、キープアライブメッセージ頻度交渉応答メッセージ１４００を示すが、このキープアライブメッセージ頻度交渉応答メッセージ１４００は、メッセージＩＤフィールド１４０５、アプリケーションＩＤフィールド１４１０、コードフィールド１４１５、頻度フィールド１４２０、および、提案頻度範囲を示すフィールド１４２５を含む。メッセージＩＤフィールド１４０５は、対応する要求メッセージ１３００中のメッセージＩＤフィールド１３０５と同じであってよく、マッチングを実施するためにＮＳＦにエコーバックされてよい。アプリケーションＩＤフィールド１４１０は、ＡＳが関連付けられているアプリケーションを示すことができる。コードフィールド１４１５は、要求メッセージ１３００に含まれるこの特定のアプリケーションの頻度が有効か否かを示すことができる。無効である場合は、頻度フィールド１４２０は、正しいパラメータを含んでよい。そうでない場合は、コードフィールド１４１５は含まれなくてよい。フィールド１４２５は、ＡＳが要求メッセージ１３００中の情報を入力としてそのプロプラエタリアルゴリズムを実行した後で許可する、頻度範囲を示すことができる。

図１５に、ＭＯキープアライブメッセージ頻度交渉要求メッセージ１５０５および応答メッセージ１５１０のメッセージフロー１５００を示す。要求メッセージ１５０５は、関係する各ＡＳにマルチキャストされるかまたはユニキャストされてよく、応答メッセージ１５１０は別々に返されてよい。ＮＳＦ１５１５が複数のアプリケーションサーバ（ＡＳ）１５２０₁，１５２０₂，．．．，１５２０_nからの全ての応答メッセージ１５１０を収集した後、ＮＳＦ１５１５は、コードおよび提案頻度範囲に基づいて、理想的なシナリオで全てのＡＳ１５２０によって受諾可能な頻度を選ぶことができる。ＮＳＦ１５１５は、同意された頻度を含む頻度交渉確認メッセージ１５２５を、各ＡＳ１５２０に送ることができる。

ＷＴＲＵ上の１つの実行中アプリケーションに関連するあらゆるＡＳは、ＷＴＲＵが同じ頻度でキープアライブメッセージを送るのを可能にすることができる。このシナリオの下では、ＷＴＲＵは、そのアライブおよびアイドルスケジュールを、同意された頻度に基づかせることができ、定期的にアクティブになって、アクティブ期間中に全ての実行中アプリケーションのキープアライブメッセージを送ることができる。

あるいは、ＮＳＦは種々のＡＳからの応答を受け取ることができるが、複数の頻度が同意される。このシナリオの下では、実行中アプリケーションはグループに分けられてよく、各グループは、各グループに関連するそれぞれのアプリケーションサーバ全てが従う必要のあるキープアライブメッセージ頻度を有する。

別のシナリオでは、あらゆるＡＳは、ＮＳＦとのどんな交渉への参加も拒否することができる。このシナリオの下では、全ての実行中アプリケーションは、元の必要とされる頻度に従って、キープアライブメッセージを各ＡＳに送ることができる。

図１６に、複数のアプリケーションおよび頻度１，２，．．．，ｘを識別する、更新済み頻度通知メッセージ１６００を示す。

図１７に、ＷＴＲＵ１７０５およびＮＳＦ１７１０によって実施される更新済み頻度通知プロシージャ１７００のメッセージフローを示す。ＮＳＦ１７１０は、更新済み頻度通知メッセージ１６００をＷＴＲＵ１７０５に送ることができる。ＷＴＲＵ１７０５上の各アプリケーションの頻度属性が、ＮＳＦ１７１０によって相応に更新されてよい。これに応答して、ＷＴＲＵ１７０５は、肯定応答（ＡＣＫ）メッセージ１７１５をＮＳＦ１７１０に送って、各アプリケーション（１，２，．．．，ｘ）がそのＭＯキープアライブメッセージ頻度を更新済み頻度通知メッセージ１６００に基づいて調整したことを確認することができる。

図１８は、モバイル発信（ＭＯ）キープアライブメッセージ頻度交渉および更新プロシージャ１８００の流れ図である。交渉および同期機能（ＮＳＦ）が、ＷＴＲＵに代わって、ＭＯキープアライブメッセージ頻度交渉要求を複数のアプリケーションサーバに送ることができる（１８０５）。ＮＳＦおよびアプリケーションサーバは、ＭＯキープアライブメッセージ頻度交渉および解決プロシージャを実施することができ、それにより、全てのアプリケーションサーバが１つのＭＯキープアライブメッセージ頻度に同意することができるか、または、全てのアプリケーションサーバが複数のＭＯキープアライブメッセージ頻度に同意することができ、アプリケーションサーバはグループに分けられる（１８１０）。ＷＴＲＵ上で、既存のアプリケーションが終了するたびに、またはキープアライブメッセージを必要とする新しいアプリケーションが起動されるたびに、ＮＳＦは、１または複数のキープアライブメッセージ頻度の更新を管理することができる（１８１５）。

図１９に、メッセージＩＤフィールド１９０５および提案頻度フィールド１９１０を含む、簡略化された頻度交渉要求メッセージ１９００の例を示す。

図２０は、１つのＭＯキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されるときの頻度更新プロシージャ２０００の流れ図の例である。結果として、キープアライブメッセージを送ることが必要とされる現在の実行中アプリケーションは、同意された頻度でそれらを送ることができる。アプリケーションが終了した場合は、アプリケーションが終了したことを反映するように、ＢＣＦに記憶されたアプリケーションのステータスが変更されてよい。同意された頻度パラメータは影響を受けないものとすることができる。ＷＴＲＵ上で起動された新しいアプリケーションがある場合は、ＢＣＦは、アプリケーションの元の頻度を推論および記録することができる。

図２０を引き続き参照するが、現在実行中のアプリケーションに加えて、新しいアプリケーションＡＰＰ_NEWが、ＷＴＲＵ上で実行を始めることができる（すなわち起動されてよい）（２００５）。ＮＳＦが、ＡＰＰ_NEWのＭＯキープアライブメッセージ頻度（Ｆ_NEW）を、アプリケーションサーバの現在のグループによって前に同意された１つの頻度（Ｆ_AGREED）と比較することができる（２０１０）。比較２０１０の結果、Ｆ_NEWはＦ_AGREEDよりも大きい（２０１５）か、Ｆ_NEWはＦ_AGREEDよりも小さい（２０２０）か、またはＦ_NEW＝Ｆ_AGREED（２０２５）である場合がある。

図２０に示されるように、ＮＳＦは、提案頻度をＦ_NEWに設定し、現在のグループ中のアプリケーションサーバに頻度交渉要求メッセージを送ることができる（２０３０）。現在のグループ中の全てのアプリケーションサーバが提案頻度（Ｆ_NEW）に同意する（２０３５）という条件で、新しいアプリケーションサーバは現在のグループに追加されてよい（２０４０）。現在のグループ中の全てのアプリケーションサーバが提案頻度（Ｆ_NEW）に同意しない（２０３５）という条件で、ＮＳＦは、提案頻度をＦ_AGREEDに設定し、ＡＰＰ_NEWをサポートする新しいアプリケーションサーバに頻度交渉要求メッセージを送ることができる（２０４５）。新しいアプリケーションサーバが提案頻度（Ｆ_AGREED）に同意する（２０５０）という条件で、新しいアプリケーションサーバは現在のグループに追加されてよい（２０４０）。新しいアプリケーションサーバが提案頻度（Ｆ_AGREED）に同意しない（２０５０）という条件で、２つの新しいアプリケーションサーバグループが確立されてよく、一方はＦ_AGREEDで実行されるグループであり、他方はＦ_NEWで実行されるグループである。

比較２０１０の結果、Ｆ_NEWがＦ_AGREEDよりも大きい（２０１５）ときは、ＮＳＦは、提案頻度を、新しいアプリケーション（ＡＰＰ_NEW）の頻度に設定し、関係するアプリケーションサーバに頻度交渉要求メッセージを送ることができる（図１５の１５０５参照）。アプリケーション間の同意された頻度があるので、頻度交渉要求メッセージ１５０５は、図１９のメッセージ１９００に描かれるように、メッセージＩＤ１９０５および提案頻度１９１０のみを含むように簡略化されてよい。提案頻度が全てのアプリケーションサーバによって同意されない場合は、ＮＳＦは、提案頻度を古い同意された頻度に設定し、新しいアプリケーションに関連するＡＳに、頻度交渉メッセージを送ることができる。このプロシージャは、ＷＴＲＵがより高い速度でキープアライブメッセージを新しいアプリケーションサーバに送れることをＮＳＦが提案することを、示すことができ、したがって、ＷＴＲＵは常に、同じ頻度でウェイクアップして、新しいアプリケーションサーバを含めた全てのアプリケーションサーバにキープアライブメッセージを送る。新しいアプリケーションサーバは、不要なキープアライブメッセージを扱いたくないなどの理由で、提案頻度を拒否することができる。このシナリオが発生した場合、アプリケーション（アプリケーションサーバ）は、２つのグループに分けられてよい。第１のグループは、引き続き、古い同意された頻度に従うことができる。第２のグループは、新しい頻度（これは新しいアプリケーションサーバの頻度である）に従うことができ、このグループは新しいアプリケーションを含む。

比較２０１０の結果、Ｆ_NEWがＦ_AGREEDよりも小さい（２０２０）ときは、ＮＳＦは、提案頻度を、古い同意された頻度に設定し、簡略化された頻度交渉要求メッセージを新しいアプリケーションサーバに送ることができる。新しいアプリケーションサーバが提案頻度を受諾する場合は、新しいアプリケーションを含めた全てのアプリケーションは、１つの同意された頻度を有することができる。そうでない場合は、アプリケーション（アプリケーションサーバ）は、２つのグループに分けられてよい。第１のグループは、引き続き、古い同意された頻度に従うことができ、現在の（古い）アプリケーション全てを含むことができる。第２のグループは、新しい頻度（これは新しいアプリケーションの頻度である）に従うことができ、このグループは新しいアプリケーションのみを含むことができる。

比較２０１０の結果、Ｆ_NEW＝Ｆ_AGREEDである（２０２５）ときは、頻度が同意された頻度と同じである場合は何も更新または変更される必要はなくてよい。

図２１Ａ、２１Ｂ、および２１Ｃは共に、複数のＭＯキープアライブメッセージ頻度が複数のアプリケーションサーバによって同意されてグループに分けられるときの、頻度更新プロシージャ２１００の流れ図の例である。

図２１Ａを参照すると、複数のアプリケーションサーバグループが確立されてよく、各グループは、ＷＴＲＵ上でそれぞれのＭＯキープアライブメッセージ頻度で現在実行されている少なくとも１つのアプリケーションに関連する（２１０５）。新しいアプリケーションＡＰＰ_NEWが、ＷＴＲＵ上で実行を始めることができる（すなわち起動されてよい）（２１１０）。ＮＳＦが、ＡＰＰ_NEWのＭＯキープアライブメッセージ頻度（Ｆ_NEW）を、アプリケーションサーバグループに関連するアプリケーションのそれぞれの頻度（Ｆ_GROUPS）と比較することができる（２１１５）。比較２１１５の結果、Ｆ_NEWはＦ_GROUPSよりも大きい（２１２０）か、Ｆ_NEWはＦ_GROUPSよりも小さい（２１２５）か、Ｆ_NEWはＦ_GROUPSのうちの１つと等しい（２１３０）か、またはＦ_NEWはＦ_GROUP-LESSよりも大きくＦ_GROUP-MOREよりも小さい（２１３５）場合がある。Ｆ_GROUP-LESSおよびＦ_GROUP-MOREは、アプリケーションサーバが動作する際のＭＯキープアライブメッセージ頻度の、頻度下限および上限である。

図２１Ａおよび２１Ｂを参照すると、比較２１１５の結果、Ｆ_NEWがＦ_GROUPSよりも大きい（２１２０）ときは、ＮＳＦは、提案頻度をＦ_NEWに設定し、最も高い頻度（Ｆ_GROUP-MAX）で実行されているアプリケーションサーバのグループ（ＡＰＰ_GROUP-MAX）に頻度交渉要求メッセージを送ることができる（２１４０）。グループ中の全てのアプリケーションサーバが提案頻度（Ｆ_NEW）に同意する（２１４５）という条件で、ＡＰＰ_NEWをサポートする新しいアプリケーションはＡＰＰ_GROUP-MAXに追加されてよい（２１５０）。グループ中の全てのアプリケーションサーバが提案頻度（Ｆ_NEW）に同意しない（２１４５）という条件で、ＮＳＦは、提案頻度をＦ_GROUP-MAXに設定し、ＡＰＰ_NEWをサポートする新しいアプリケーションサーバに頻度交渉要求メッセージを送ることができる（２１５５）。新しいアプリケーションサーバが提案頻度（Ｆ_GROUP-MAX）に同意する（２１６０）という条件で、ＡＰＰ_NEWをサポートする新しいアプリケーションはＡＰＰ_GROUP-MAXに追加されてよい（２１５０）。新しいアプリケーションサーバが提案頻度（Ｆ_GROUP-MAX）に同意しない（２１６０）という条件で、２つの新しいアプリケーションサーバグループが確立されてよく、一方はＦ_GROUP-MAXで実行されるグループであり、他方はＦ_NEWで実行されるグループである（２１６５）。

図２１Ａを参照すると、比較２１１５の結果、Ｆ_NEWがＦ_GROUPSよりも小さい（２１２５）ときは、ＮＳＦは、提案頻度を、アプリケーションサーバグループ（ＡＰＰ_GROUP-MIN）の最も低いＭＯキープアライブメッセージ頻度（Ｆ_GROUP-MIN）に設定し、ＡＰＰ_NEWをサポートする新しいアプリケーションサーバに頻度交渉要求メッセージを送ることができる（２１７０）。新しいアプリケーションサーバが提案頻度（Ｆ_GROUP-MIN）に同意する（２１７２）という条件で、新しいアプリケーションサーバはＡＰＰ_GROUP-MINに追加されてよい（２１７４）。新しいアプリケーションサーバが提案頻度（Ｆ_GROUP-MIN）に同意しない（２１７２）という条件で、２つの新しいアプリケーションサーバグループが確立されてよく、一方はＦ_GROUP-MINで実行されるグループであり、他方はＦ_NEWで実行されるグループである（２１７６）。

図２１Ａおよび２１Ｃを参照すると、比較２１１５の結果、Ｆ_NEWがＦ_GROUP-LESSよりも大きくＦ_GROUP-MOREよりも小さい（２１３５）ときは、ＮＳＦは、提案頻度を、Ｆ_NEWよりも高いアプリケーションサーバグループ（ＡＰＰ_GROUP-MORE）のＭＯキープアライブメッセージ頻度（Ｆ_GROUP-MORE）に設定し、ＡＰＰ_NEWをサポートする新しいアプリケーションサーバに頻度交渉要求メッセージを送ることができる（２１７８）。新しいアプリケーションサーバが提案頻度（Ｆ_GROUP-MORE）に同意する（２１８０）という条件で、新しいアプリケーションサーバはＡＰＰ_GROUP-MOREに追加されてよい（２１８２）。新しいアプリケーションサーバが提案頻度（Ｆ_GROUP-MORE）に同意しない（２１８０）という条件で、ＮＳＦは、提案頻度をＦ_NEWに設定し、Ｆ_NEWよりも低いＭＯキープアライブメッセージ頻度（Ｆ_GROUP-LESS）で実行されているアプリケーションサーバのグループ（ＡＰＰ_GROUP-LESS）に頻度交渉要求メッセージを送ることができる（２１８４）。グループ「ｌｅｓｓ」中の全てのアプリケーションサーバが提案頻度（Ｆ_NEW）に同意する（２１８６）という条件で、新しいアプリケーションサーバは、Ｆ_NEWで実行されるグループ「ｌｅｓｓ」に追加されてよい（２１８８）。グループ「ｌｅｓｓ」中の全てのアプリケーションサーバが提案頻度（Ｆ_NEW）に同意しない（２１８６）という条件で、新しいアプリケーションサーバのみを含む新しいグループが追加されてよい（２１９０）。

図２１Ａを参照すると、比較２１１５の結果、Ｆ_NEWがＦ_GROUPSのうちの１つと等しい（２１３０）ときは、ＡＰＰ_NEWをサポートする新しいアプリケーションサーバは、Ｆ_NEWで実行されているアプリケーションサーバのグループに追加されてよい（２１９２）。

現在のアプリケーションサーバが、グループに分けられてよい（最も望まれないシナリオは、それぞれが１つのアプリケーションを含む複数のアプリケーションサーバグループがあることである）。各グループ中のアプリケーションサーバは、同じ頻度に従うことができる。ＮＳＦは、新しいアプリケーションのキープアライブメッセージ頻度を、既存のグループに関連するアプリケーションの頻度と比較することができる。

比較２１１５の結果、Ｆ_NEWがＦ_GROUPSよりも大きい（２１２０）ときは、ＮＳＦは、提案頻度を新しい頻度に設定し、最も高い頻度を有するアプリケーションサーバ（ＧｒｏｕｐＭａｘとして表される）に頻度交渉要求メッセージを送り、新しいより高い頻度に同意するようにこれらのアプリケーションサーバとの交渉を試みることができる。他のグループ中のアプリケーションサーバは、この交渉要求メッセージに含まれなくてよい。というのは、古い最も高い頻度は、前の交渉で他のグループによって拒否されたはずだからである。

あるシナリオでは、ＧｒｏｕｐＭａｘ中のアプリケーションサーバに関連する全てのアプリケーションと、新しいアプリケーションとは、提案頻度に同意することができる。別のシナリオでは、ＧｒｏｕｐＭａｘ中のアプリケーションサーバに関連するアプリケーションと、新しいアプリケーションとは、２つの新しいグループに分けられてよく、一方は古い最も高い頻度のグループであり、他方は新しい頻度のグループである。

比較２１１５の結果、Ｆ_NEWがＦ_GROUPSよりも小さい（２１２５）ときは、ＮＳＦは、提案頻度を、最も低い頻度（ＧｒｏｕｐＭｉｎ）に設定し、新しいアプリケーションに関連する新しいアプリケーションサーバに、簡略化された交渉要求メッセージを送ることができる。新しいアプリケーションサーバが提案頻度を受諾する場合は、ＧｒｏｕｐＭｉｎ中のアプリケーションサーバと、それに加えて新しいアプリケーションサーバとは、１つの同意された頻度を有することができ、新しいアプリケーションサーバはＧｒｏｕｐＭｉｎに割り当てられてよい。そうでない場合は、１つの新しいグループが生み出されてよく、このグループは、新しいアプリケーションサーバのみを含む。

Ｆ_NEWがＦ_GROUP-LESS（最も低い頻度）よりも大きくＦ_GROUP-MORE（最も高い頻度）よりも小さい（２１３５）ときは、ＮＳＦは、提案頻度をＦ_GROUP-MOREに設定し、新しいアプリケーションサーバに、簡略化された頻度交渉要求メッセージを送ることができる。新しいアプリケーションサーバが提案頻度に同意する場合は、新しいアプリケーションサーバはグループ「ｍｏｒｅ」に割り当てられてよい。新しいアプリケーションサーバが提案頻度を拒否する場合は、ＮＳＦは、提案頻度をＦ_NEWに設定し、グループ「ｌｅｓｓ」中の全てのアプリケーションサーバに頻度交渉要求メッセージを送ることができる。グループ「ｌｅｓｓ」中の全てのアプリケーションサーバが提案頻度に同意する場合は、新しいアプリケーションサーバは、グループ「ｌｅｓｓ」に割り当てられてよく、グループ「ｌｅｓｓ」の頻度は、Ｆ_NEWに変更されてよい。同意に達しない場合は、新しいアプリケーションサーバのみを含む新しいグループが追加されてよい。

Ｆ_NEWがＦ_GROUPSのうちの１つと等しい（２１３０）ときは、新しいアプリケーションサーバは、対応するグループに入れられてよい。

最適化方式がＮＳＦによって提供されてよく、ＮＳＦは、ＷＴＲＵの代理サーバとしての役割を果たすことができる。代理サービスは、ＮＳＦによって事前対策的に提供されてもよく、または、ＡＳもしくはＷＴＲＵによって要求されてもよい。第１のシナリオは、ＮＳＦが、代理サービスをＷＴＲＵに提供しようと事前対策的に望むことができ（または代理サービスはＡＳによって要求されてもよい）、ＷＴＲＵがサービスを受諾することができるというものである。他方、第２のシナリオは、ＷＴＲＵが、それに代理サービスを提供するようＮＳＦに要求することができるというものである。ＮＳＦは、ＷＴＲＵからの要求を受諾することができる。

各アプリケーションが、そのアプリケーションからの１つのキープアライブメッセージが複数のメッセージとして機能することをＮＳＦに対して保証できるという条件下で、ＮＳＦは、全ての実行中アプリケーションについて同じ頻度でキープアライブメッセージを送るようＷＴＲＵと交渉を試みることができる。例えば、前述のプロシージャから、ＮＳＦとアプリケーションサーバとの間の同意された頻度は６秒、１０秒、および１５秒である場合がある。したがって、このＷＴＲＵ上の全ての実行中アプリケーションに対して、ＮＳＦが観察できる最も望まれる同期された頻度は３０秒である。

ＮＳＦは、６秒グループ中のアプリケーションに、３０秒の頻度でキープアライブメッセージを送るよう要求することができるが、次の５つの６秒スロット中でそれがアライブであることを保証することができる。同様に、ＮＳＦは、１０秒グループ中のアプリケーションに、３０秒の頻度でキープアライブメッセージを送るよう要求することができるが、次の３つの１０秒スロット中でそれがアライブであることを保証することができ、１５秒グループ中のアプリケーションに、３０秒の頻度でキープアライブメッセージを送るよう要求することができるが、次の２つの１５秒スロット中でそれがアライブであることを保証することができる。ＮＳＦは、ＷＴＲＵの代理となって、これらのグループ中の各アプリケーションの仮想キープアライブメッセージを、ＡＳが必要とするのと同じフォーマットおよび頻度に従って送ることができる。

図２２に、ＮＳＦによってＷＴＲＵに送られるＭＯキープアライブメッセージ削減要求メッセージ２２００の例を示す。図２３に、ＷＴＲＵによって送られるＭＯキープアライブメッセージ削減応答メッセージ２３００の例を示す。図２２および２３に示されるように、メッセージＩＤフィールド２２０５および２３０５を使用して、ＭＯキープアライブメッセージ削減要求メッセージ２２００とＭＯキープアライブメッセージ削減応答メッセージ２３００とをマッチさせることができる。「グループ数」フィールド２２１０および２３１０は、実行中のアプリケーションが何個のグループに分けられるかを示すことができる。各グループにつき、１つのグループＩＤフィールド２２１５および関連する「アプリケーション数」フィールド２２２０があってよい。ＷＴＲＵ上で実行されている各アプリケーションにつき、アプリケーションＩＤフィールド２２２５があってよい。提案頻度フィールド２２３０は、全てのグループの同意された頻度の最小公倍数であってよい。

ＷＴＲＵがＭＯキープアライブメッセージ削減要求メッセージ２２００を受け取ったとき、ＷＴＲＵは、全ての関係するアプリケーションに対して、新しい頻度を認識して相応に更新するようにさせることができる。これには、隣接する２つのキープアライブメッセージが送出されている間にアプリケーションがアライブであることをアプリケーションが保証する必要があるであろう。アプリケーションがこの保証をすることができない場合、アプリケーションは拒否応答でＰ−ＧＷに答えることができる。結果として、ＭＯキープアライブメッセージ削減応答メッセージ２３００は、アプリケーションが新しい頻度を受諾するか拒否するかを示すことのできる受諾／拒否（ａ／ｒ）フィールド２３１５、ならびに複数のアプリケーションＩＤフィールド２３２０を含んでよい。

ＭＯキープアライブメッセージ削減要求メッセージ２２００中の全てのアプリケーションが新しい頻度を受諾する場合、グループは、ＮＳＦによって管理される１つのグループにマージされてよい。

図２４に、ＮＳＦによって開始されるＭＯキープアライブメッセージ削減プロシージャの例示的なメッセージフローを示す。ＢＣＦは、ＮＳＦによってこれらのアプリケーションについて送られる仮想キープアライブメッセージの数を維持することができ、この数から、ＮＳＦは、何個の仮想キープアライブメッセージがアプリケーションに代わってアプリケーションサーバに送られてよいかを知る。仮想キープアライブメッセージは、それがＷＴＲＵからアプリケーションによって送られるかのように、ＢＣＦ中でキャッシュされた最新の本物のキープアライブメッセージと同じフォーマットを有することができる。アプリケーションのいくつかが拒否で返答した場合、これらのアプリケーションは、古いグループに留まることができる。他のアプリケーションは、新しい頻度を有する新しいグループに移行されてよい。

図２５に、ＷＴＲＵによって送られるＭＯキープアライブメッセージ削減要求メッセージ２５００の例を示す。ＷＴＲＵは、ＮＳＦとアプリケーションサーバとの間で頻度交渉または更新プロシージャがあるかどうかにかかわらず、任意の時点でＭＯキープアライブメッセージ削減要求メッセージ２５００をＮＳＦに送ることができる。ＷＴＲＵは、１または複数のアプリケーションについて、特定の提案頻度（複数可）を含むＭＯキープアライブメッセージ削減要求メッセージ２５００をＮＳＦに送ることができる。提案頻度は、元の値の倍数であってよい。例えば、アプリケーションの元のキープアライブメッセージ頻度が、ＡＳによって最初に必要とされるものであろうと、またはＮＳＦとアプリケーションサーバとの間で交渉されてアプリケーションにプロビジョニングされるものであろうと、この元の頻度が５秒である場合、この削減要求メッセージ中の提案頻度は、１０、１５、２０、３０など、５の倍数であってよい。

図２６に、ＷＴＲＵによって開始されるＭＯキープアライブメッセージ削減プロシージャの例示的なメッセージフローを示す。キープアライブメッセージ削減応答メッセージ２３００は、図２３に示されるものと同様である。アプリケーションが「受諾」応答をＮＳＦから受け取った後、アプリケーションは、キープアライブメッセージを提案頻度で送ることができる。ＮＳＦは、ＷＴＲＵに代わって、アプリケーションサーバが必要とする頻度で仮想キープアライブメッセージを送ることができる。

ＮＳＦは、種々のアプリケーションサーバからの、ＷＴＲＵをターゲットとするメッセージ（ＭＴメッセージ）を、優先度または重みを有する種々のタイプに分類することができる。ＭＴメッセージの優先度または重みは、アプリケーションの優先度属性から、または他の何らかの要因から導出されてよい。前述のプロシージャを実行することによって、ＮＳＦは、いつＷＴＲＵがアイドル状態からアクティブであり得るかを知って、キープアライブメッセージを送ることができる。ＷＴＲＵをできるだけアイドル状態に維持するために、ＮＳＦは、ＷＴＲＵがアクティブである期間中にＭＴメッセージ送信をトリガすることができる。バッファリングされたＭＴメッセージは、優先度の高い順に送られる規則に従って送られてよい。ＭＴメッセージのいくつかが、遅延されることが不可能な非常に高い優先度または重みを有する場合は、これらのメッセージは、ＷＴＲＵのステータスにかかわらず送られてよく、ＷＴＲＵはアイドル状態からアクティブ状態にウェイクされてよい。

実施形態
１．コアネットワーク中のノードによって実施される、それぞれのアプリケーションに関連するアプリケーションサーバとキープアライブメッセージ頻度を交渉する方法であって、
ノードがモバイル発信（ＭＯ）キープアライブメッセージ頻度交渉要求メッセージを複数のアプリケーションサーバに送ること、および、
ノードがＭＯキープアライブメッセージ頻度交渉応答メッセージをアプリケーションサーバから受け取ることを含む方法。

２．ノードが、ワイヤレス送受信ユニット（ＷＴＲＵ）上で実行しおよびアプリケーションサーバに関連するアプリケーションによって送られるキープアライブメッセージの頻度を交渉することをさらに含む、実施形態１の方法。

３．ノードは、ＷＴＲＵをターゲットとするアプリケーションメッセージを、優先度または重みを有する種々のタイプに分類するように構成されたバッファを備える、実施形態２の方法。

４．ノードがＷＴＲＵにメッセージを送ることをさらに含み、メッセージは、交渉された頻度よりも低い頻度でキープアライブメッセージを送るようＷＴＲＵに要求し、かつ、どれくらい長くキープアライブメッセージが有効かを示す、実施形態１〜３のいずれか１つにおける方法。

５．アプリケーションサーバの全ては、共通のＭＯキープアライブメッセージ頻度に同意し、アプリケーションは、同意されたＭＯキープアライブメッセージ頻度でキープアライブメッセージを送る、実施形態１〜４のいずれか１つにおける方法。

６．ＭＯキープアライブメッセージ頻度交渉要求メッセージの各々は、メッセージ識別子フィールドと、ＷＴＲＵ識別子フィールドと、アプリケーション数を示すフィールドとを含む、実施形態１〜５のいずれか１つにおける方法。

７．ＭＯキープアライブメッセージ頻度交渉要求メッセージの各々は、複数のアプリケーション識別子フィールドと、複数のキープアライブメッセージ頻度フィールドと、提案頻度フィールドとをさらに含む、実施形態１〜６のいずれか１つにおける方法。

８．ＭＯキープアライブメッセージ頻度交渉応答メッセージの各々は、メッセージ識別子フィールドと、少なくとも１つのアプリケーション識別子フィールドと、少なくとも１つのキープアライブメッセージ頻度フィールドと、提案頻度範囲を示すフィールドとを含む、実施形態１〜７のいずれか１つにおける方法。

９．ＭＯキープアライブメッセージ頻度交渉応答メッセージの各々は、アプリケーション頻度が有効か無効かを示すコードフィールドをさらに含む、実施形態１〜８のいずれか１つにおける方法。

１０．ノードは、アプリケーションサーバによってＷＴＲＵに送られたキープアライブメッセージおよびステータス更新メッセージをバッファリングするように構成されたバッファをさらに備える、実施形態１〜９のいずれか１つにおける方法。

１１．ノードが、同意された頻度を示すＭＯキープアライブメッセージ頻度交渉確認メッセージをアプリケーションサーバに送ることをさらに含む、実施形態１〜１０のいずれか１つにおける方法。

１２．ノードは、パケットデータネットワークゲートウェイと、交渉およびキャッシングゲートウェイと、サービングゲートウェイとのうちの１つである、実施形態１〜１１のいずれか１つにおける方法。

１３．コアネットワーク中のノードによって実施される、キープアライブメッセージ頻度を交渉する方法であって、
ノードが、ワイヤレス送受信ユニット（ＷＴＲＵ）上で実行を始めるように開始された新しいアプリケーションによって送られるキープアライブメッセージの新しい頻度を、ＷＴＲＵ上で現在実行されているアプリケーションのグループによって送られるキープアライブメッセージの共通頻度と比較すること、および、
新しいアプリケーションをアプリケーションのグループに追加するか、または、共通のキープアライブメッセージ頻度に関連する第１のアプリケーショングループと、新しいアプリケーションキープアライブメッセージ頻度に関連する第２のアプリケーショングループとを確立するかを決定することを含む方法。

１４．ノードは、パケットデータネットワークゲートウェイと、交渉およびキャッシングゲートウェイと、サービングゲートウェイとのうちの１つである、実施形態１３の方法。

１５．ノードは、ＷＴＲＵをターゲットとするアプリケーションメッセージを、優先度または重みを有する種々のタイプに分類するように構成されたバッファを備える、実施形態１３〜１４のいずれか１つにおける方法。

１６．ノードはＷＴＲＵにメッセージを送るように構成され、メッセージは、交渉された頻度よりも低い頻度でキープアライブメッセージを送るようＷＴＲＵに要求し、かつ、どれくらい長くキープアライブメッセージが有効かを示す、実施形態１３〜１５のいずれか１つにおける方法。

１７．ノードが、新しいキープアライブメッセージ頻度を示す提案頻度フィールドを含むモバイル発信（ＭＯ）キープアライブメッセージ頻度交渉要求メッセージを、ＷＴＲＵ上で現在実行されているアプリケーションのグループをサポートする複数のアプリケーションサーバに送ること、および、
ＷＴＲＵ上で現在実行されているアプリケーションのグループをサポートするアプリケーションサーバの全てが新しいキープアライブメッセージ頻度に同意しなかったという条件で、ノードが、共通のキープアライブメッセージ頻度を示す提案頻度フィールドを含むＭＯキープアライブメッセージ頻度交渉要求メッセージを、新しいアプリケーションをサポートするアプリケーションサーバに送ることをさらに含む、実施形態１３〜１６のいずれか１つにおける方法。

１８．モバイル発信（ＭＯ）キープアライブメッセージ頻度交渉要求メッセージを複数のアプリケーションサーバに送って、ワイヤレス送受信ユニット（ＷＴＲＵ）上で実行しおよびアプリケーションサーバに関連するアプリケーションによって送られるキープアライブメッセージの頻度を交渉するように構成された回路と、
ＭＯキープアライブメッセージ頻度交渉応答メッセージをアプリケーションサーバから受け取るように構成された回路とを備えるノード。

１９．ノードは、パケットデータネットワークゲートウェイと、交渉およびキャッシングゲートウェイと、サービングゲートウェイとのうちの１つである、実施形態１８のノード。

２０．アプリケーションメッセージｔを分類するように構成されたバッファを備える、実施形態１８〜１９のいずれか１つにおけるノード。

２１．ＷＴＲＵにメッセージを送るように構成された回路をさらに備え、メッセージは、交渉された頻度よりも低い頻度でキープアライブメッセージを送るようＷＴＲＵに要求し、かつ、どれくらい長くキープアライブメッセージが有効かを示す、実施形態１８〜２０のいずれか１つにおけるノード。

以上では特徴および要素が特定の組合せで記述されているが、各特徴または要素は、単独で、または他の特徴および要素のいずれかとの組合せで使用されてよいことを、当業者なら理解するであろう。加えて、本明細書に記載の実施形態は、コンピュータまたはプロセッサによって実行されるようにコンピュータ可読媒体に組み入れられたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実現されてよい。コンピュータ可読媒体の例は、電子信号（有線またはワイヤレス接続を介して伝送される）、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、磁気媒体（例えば内蔵ハードディスクまたは取外し可能ディスク）、光磁気媒体、および、コンパクトディスク（ＣＤ）やディジタル多用途ディスク（ＤＶＤ）などの光学媒体を含むが、これらに限定されない。プロセッサがソフトウェアと共に使用されて、ＷＴＲＵ、ＵＥ、端末、基地局、Ｎｏｄｅ−Ｂ、ｅＮＢ、ＨＮＢ、ＨｅＮＢ、ＡＰ、ＲＮＣ、ワイヤレスルータ、または任意のホストコンピュータ中で使用される無線周波数送受信機が実現されてよい。

Claims (15)

1. コアネットワーク中のノードによって実施される、それぞれのアプリケーションに関連付けられたアプリケーションサーバとキープアライブメッセージ頻度を交渉する方法であって、
   前記ノードが、モバイル発信（ＭＯ）キープアライブメッセージ頻度交渉要求メッセージを複数のアプリケーションサーバへ送信して、ワイヤレス送受信ユニット（ＷＴＲＵ）上で実行しおよび前記アプリケーションサーバに関連付けられたアプリケーションによって送信されるキープアライブメッセージの頻度を交渉するステップと、
   前記ノードが、ＭＯキープアライブメッセージ頻度交渉応答メッセージを前記アプリケーションサーバから受信するステップと、
   前記ノードが、メッセージを前記ＷＴＲＵへ送信するステップであって、前記メッセージは、交渉された頻度よりも低い頻度でキープアライブメッセージを送信するよう前記ＷＴＲＵに要求し、および、どれくらいの期間前記キープアライブメッセージが有効であるかを示す、ステップと
   を含むことを特徴とする方法。
2. 前記ノードは、パケットデータネットワークゲートウェイ、交渉およびキャッシングゲートウェイ、または、サービングゲートウェイのうちの１つであることを特徴とする請求項１に記載の方法。
3. 前記ノードは、前記ＷＴＲＵをターゲットとするアプリケーションメッセージを、優先度または重みで異なる種類に分類するように構成されたバッファを含むことを特徴とする請求項１に記載の方法。
4. 前記アプリケーションサーバは、共通のＭＯキープアライブメッセージ頻度に同意し、前記アプリケーションは、前記同意されたＭＯキープアライブメッセージ頻度で前記キープアライブメッセージを送信することを特徴とする請求項１に記載の方法。
5. 前記ＭＯキープアライブメッセージ頻度交渉要求メッセージの各々は、メッセージ識別子フィールド、ＷＴＲＵ識別子フィールド、および、アプリケーションの数を示すフィールドを含むことを特徴とする請求項１に記載の方法。
6. 前記ＭＯキープアライブメッセージ頻度交渉要求メッセージの各々は、複数のアプリケーション識別子フィールド、複数のキープアライブメッセージ頻度フィールド、および、提案された頻度フィールドをさらに含むことを特徴とする請求項５に記載の方法。
7. 前記ＭＯキープアライブメッセージ頻度交渉応答メッセージの各々は、メッセージ識別子フィールド、少なくとも１つのアプリケーション識別子フィールド、少なくとも１つのキープアライブメッセージ頻度フィールド、および、提案された頻度範囲を示すフィールドを含むことを特徴とする請求項１に記載の方法。
8. 前記ＭＯキープアライブメッセージ頻度交渉応答メッセージの各々は、アプリケーション頻度パラメータが有効であるかまたは有効ではないかを示すコードフィールドをさらに含むことを特徴とする請求項７に記載の方法。
9. 前記ノードが、同意された頻度を示すＭＯキープアライブメッセージ頻度交渉確認メッセージを前記アプリケーションサーバへ送信するステップをさらに含むことを特徴とする請求項１に記載の方法。
10. コアネットワーク中のノードによって実施される、キープアライブメッセージ頻度を交渉する方法であって、
    前記ノードが、ワイヤレス送受信ユニット（ＷＴＲＵ）上で実行を始めるように開始された新しいアプリケーションによって送信されるキープアライブメッセージの新しい頻度と、前記ＷＴＲＵ上で現在実行しているアプリケーションのグループによって送信されるキープアライブメッセージの共通頻度との比較を実施するステップと、
    前記新しいアプリケーションをアプリケーションの前記グループに追加するか、または、前記共通のキープアライブメッセージ頻度に関連付けられた第１のアプリケーショングループおよび前記新しいアプリケーションキープアライブメッセージ頻度に関連付けられた第２のアプリケーショングループを確立するか、を決定するステップと
    を含むことを特徴とする方法。
11. 前記ノードは、メッセージを前記ＷＴＲＵへ送信するように構成され、前記メッセージは、交渉されたキープアライブメッセージ頻度よりも低い頻度でキープアライブメッセージを送信するよう前記ＷＴＲＵに要求し、および、どれくらいの期間前記キープアライブメッセージが有効であるかを示すことを特徴とする請求項１０に記載の方法。
12. 前記ノードが、前記新しいキープアライブメッセージ頻度を示す提案された頻度フィールドを含むモバイル発信（ＭＯ）キープアライブメッセージ頻度交渉要求メッセージを、前記ＷＴＲＵ上で現在実行しているアプリケーションの前記グループをサポートする複数のアプリケーションサーバへ送信するステップと、
    前記ＷＴＲＵ上で現在実行しているアプリケーションの前記グループをサポートする前記アプリケーションサーバの全てが前記新しいキープアライブメッセージ頻度に同意しなかったという条件で、前記ノードが、前記共通のキープアライブメッセージ頻度を示す提案された頻度フィールドを含むＭＯキープアライブメッセージ頻度交渉要求メッセージを、前記新しいアプリケーションをサポートするアプリケーションサーバへ送信するステップと
    をさらに含むことを特徴とする請求項１０に記載の方法。
13. モバイル発信（ＭＯ）キープアライブメッセージ頻度交渉要求メッセージを複数のアプリケーションサーバへ送信して、ワイヤレス送受信ユニット（ＷＴＲＵ）上で実行しおよび前記アプリケーションサーバに関連付けられたアプリケーションによって送信されるキープアライブメッセージの頻度を交渉するように構成された回路と、
    ＭＯキープアライブメッセージ頻度交渉応答メッセージを前記アプリケーションサーバから受信するように構成された回路と、
    メッセージを前記ＷＴＲＵへ送信するように構成された回路であって、前記メッセージは、交渉された頻度よりも低い頻度でキープアライブメッセージを送信するよう前記ＷＴＲＵに要求し、および、どれくらいの期間前記キープアライブメッセージが有効であるかを示すことを特徴とするノード。
14. 前記ノードは、パケットデータネットワークゲートウェイ、交渉およびキャッシングゲートウェイ、または、サービングゲートウェイのうちの１つであることを特徴とする請求項１３に記載のノード。
15. 前記ノードは、前記ＷＴＲＵをターゲットとするアプリケーションメッセージを、優先度または重みで異なる種類に分類するように構成されたバッファを含むことを特徴とする請求項１３に記載のノード。