JP5514908B2 - ステータス依存型移動体サービス用通信システム及び装置 - Google Patents

Description

本発明は、パケット交換方式のデータ通信ネットワークにおける通信の分野に関する。より具体的には、本発明は他のデバイスとのローカル接続を備えた移動体端末に関する。

セルラー通信は、早期のＧＳＭ（移動体通信用グローバル・システム（登録商標））ネットワークからＧＰＲＳ（汎用パケット無線サービス）へと、また、世界の様々な大都市で見出すことができるＵＭＴＳ（ユニバーサル移動体通信システム）の最新システムへと一定の進化を遂げてきた。非常に近い将来には、次世代ロング・ターム・エボリューション（ＬＴＥ）ネットワークが展開される予定である。アクセス技術とともに、セルラー通信ネットワークによって提供されるサービスもまた進化しつつある。

今日のセルラー・ネットワークは、今や初歩的な音声通話サービスのみではなく、短いテキスト・メッセージ伝送及びグローバル・インターネットへのアクセスも提供している。近年になって、新しいサービスが、マシン・ツー・マシン（Ｍ２Ｍ）通信といった人間以外の通信を包含するよう拡大されてきた。第３世代移動体通信システム標準化プロジェクト（３ＧＰＰ）は、［非特許文献１］にあるように、セルラー・ネットワークにマシン・タイプ通信をサポートするための要件の定義を開始した。これによって、セルラー・ネットワークが、マシン・タイプ通信のサポートにより適したものとなる。

マシン・タイプ通信は、センサによる測定データの収集からデバイスの遠隔制御にわたる非常に広い範囲のアプリケーションを包含しうる。セルラー・ネットワークを採用している多くの例がある。例えば［特許文献１］は、セルラー・ネットワークを活用して自動運転車両など遠隔地にあるリソースを制御するリソース管理アーキテクチャを開示している。［特許文献３］では、定期的な（標準の）セルラー携帯電話を用いて自動車を制御するシステムもまた記載されている。

セルラー通信システムによって提供されるサービスもまたより個別的になりつつある。例えば、いくつかのサービスは位置固有情報をユーザに提供する。このことは、ネットワークが、［特許文献２］、［特許文献４］及び［特許文献６］に開示されたような技術を用いる携帯電話（又は３ＧＰＰ術語におけるユーザ機器、ＵＥ）の現在位置を取得することを伴う。［特許文献７］に記載されるように、ネットワークがプレゼンス・サーバーを保守することもまた可能である。［特許文献５］によって教示された方法によってプレゼンス情報をアプリケーション・サーバーに開示することによって、アプリケーション・サーバーは情報を携帯電話の現在位置に合わせて調整することができる。

米国特許第７３５６４９４Ｂ２号、Ｅｈｒｍａｎら、「Robust Wireless Communications System Architecture and Asset Management Applications Performed thereof」、２００８年４月 米国特許出願第ＵＳ２００８／０１６２６３７Ａ１号、Ａｄａｍｃｚｙｋら、「Application Services Infrastructure for Next generation Networks including Notification Capability and Related Methods and Computer Program Products」、２００８年７月 特許協力条約出願第ＷＯ２００８／０７９２５４Ａ１号、Ｍｉｋａｎら、「Wireless Device as Programmable Vehicle Key」、２００８年７月 米国特許出願第ＵＳ２００７／０００５１８８Ａ１号、Ｊｏｈｎｓｏｎ、Ｗ、「System and Method for Proactive Content Delivery by Situational Location」、２００７年１月 米国特許出願第ＵＳ２００６／０１２９６９１Ａ１号、Ｃｏｆｆｅｅら、「Location Aware Wireless Data Gateway」、２００６年６月 特許協力条約出願第ＷＯ２００６／０２３２２５Ａ１号、Ｊｕｌｋａ、Ｖ．及びＣｏｌｂａｎ、Ｅ．「Responsive to Receiving an Event Notification Sent by a MSC, Managing Communication Resources in a Packet Switched Network」、２００６年３月 特許協力条約出願第ＷＯ２００２／０９６１２８Ａ２号、Ｋｉｓｓら、「Presence Server in IP Multimedia」、２００２年１１月

３ＧＰＰ ＴＳ ２２．３６８ｖ０．４．０、「Service Requirements for Machine Type Communications」、２００９年５月 ３ＧＰＰ ＴＳ ２３．４０１ｖ９．３．０、「GPRS enhancements for E-UTRAN access」、２００９年１２月 ３ＧＰＰ ＴＳ ３６．４１３ｖ９．１．０、「E-UTRA S1 Application Protocol」、２００９年１２月 ３ＧＰＰ ＴＳ ３６．４２３ｖ９．１．０、「E-UTRA X2 Application Protocol」、２００９年１２月

しかしながら、いくつかのサービスは、ＵＥに、追加サーバーにおける自己の位置ステータスを更新させたり、又は即座の回答が必要ないかもしれない問い合わせへの応答など、ＵＥがアイドル・モードから接続モード（コネクティッド・モード）へと絶えず移動することを必要とするかもしれず、これによって、携帯電話の電池を消耗しうる。いくつかの携帯電話は、信号伝達のためのセッション初期化プロトコル（ＳＩＰ）の使用を必要とし、これによって、係る解決方法を実装するためのコストが増加される。さらに、いくつかのサービスは、携帯電話が要求されたステータスにない場合には、サービスを携帯電話に提供することは無意味となるよう、携帯電話のステータスに固有である。このことは、ＵＥ上のプレゼンス情報としてステータスをサーバーにＵＥが通知するためには、自己の状態（ステート）をアイドル・モードからコネクティッド・モードへと変化させる必要があることを意味する。この必要性によって、携帯電話の電池の消耗をもたらすかもしれない。

シナリオの一例は、スマート・グリッド電力事業者のアプリケーション中での携帯電話の使用であり、ここでは、電力網の供給業者は専門のサーバーを用いて家電製品と通信する。この使用は、各家電製品及び世帯ごとの電力消費統計を収集するためだけでなく、これらデバイスに対して電力使用分析結果及びヒントを提供し、電力網の需要及び供給に基づいて電力消費が最適化できるようにする。係る家電製品（例：空調機器、冷蔵庫）の大部分は、ＳＩＭホスティング機能を持っていないであろうから、スマート・グリッドＭ２Ｍアプリケーション用の伝送媒体としてセルラー・ネットワークを用いるために、携帯電話が採用されてもよい。

セルラー方式の携帯電話は至るところに存在するので、各世帯にはセルラー・ネットワークの少なくとも１名の加入者がいると仮定しても差し支えない。家電製品は、ＷｉＦｉ又はＺｉｇｂｅｅ（登録商標）といったローカル・ネットワーク技術を用いて加入者の携帯電話と接続し、次いで、セルラー・ネットワークを活用してスマート・グリッド電力事業提供者と通信する。これにはいくつか利点がある。まず第１に、家電製品が自己のセルラー・アクセス機構を持つ必要はない。第２に、加入者が在宅していないときには、家電製品は、電源が切られるか又は低電力モードのいずれかとなるであろう。いずれにせよ、それゆえに、スマート・グリッド供給業者が家電製品と通信する真の必要性はない。係る通信が必要となる唯一の時間は、加入者が在宅しているとき、及び、電話も自宅にあるときである。

これは、双方にとってメリットがある取り決めのようであるが、例外として欠点が１つある：携帯電話の電池寿命への影響である。携帯電話が自宅に戻っているときには、明らかにドックに入れることができ、本体から電力を引き出すことができ、したがってその場合は電池寿命の懸念はない。しかしながら、携帯電話が自宅を離れる際は、家電製品との接続が失われ、バッテリー電源に依存する。しかし、スマート・グリッドの電力事業供給者には、このことはわからない。電力事業供給者は、携帯電話との接続を継続して家電製品から電力消費統計情報を収集し、エネルギー使用分析結果及びヒントを家電製品に送信するであろう。携帯電話は家電製品に接続されていないので、係る通信のいかなる試みも消耗であることから、携帯電話の電池寿命の消耗である。

別の例示的シナリオは、Ｍ２Ｍデバイスを取り扱うサーバーがこれらＭ２Ｍデバイスを問い合わせることも可能でありうることである。係る問い合わせには異なる種類がありうる。必要な現在温度などいくつかの問い合わせは、即座の回答を必要とするかもしれない。定期的なソフトウェア更新などいくつかは、即座の回答を必要としないかもしれない。しかし、現在の各メカニズムは、ＵＥの現在の状態−アイドル又はコネクティッド（接続）−にかかわらずＵＥが応答させられることと規定している。また、問い合わせ側エンティティは、サーバーであれ、又は他のデバイスであれいずれも、ＵＥがアイドル・モードにあるか否かについての情報を持っていない。ＵＥがアイドル・モードにあるか否かは、ＵＥ及びネットワーク・ノードのみが知っている。したがって、想像できることは、誰かが問い合わせを行うたびにＵＥが起こされる（ウエィクアップ）ことであり、たとえ当該問い合わせが即座の応答を必要としない場合であってもそうである。したがって、ＵＥはアイドル・モードからコネクティッド・モードへと行き来し、それゆえ大幅に電力資源を消費する。このこともまた、ＵＥの現在のステータスを知らないがゆえに、不必要な電力消耗をもたらす事例である。

本質的に我々が必要なのは、重要ではないときにＵＥがウェイクアップされるのを防ぐための何らかのメカニズムである。特定された先行技術において我々は、主として、着呼側の呼処理を自動化するのに用いられる通話スクリーニング技術において、類似の問題に取り組む何らかの先行技術を見出した。この先行技術では、ユーザは、特定の電話番号又はＩＰアドレスのための一連の規則を登録してもよい。サーバーはそれら規則を用いてブロック（拒否）又は自動回答等、所要のタスクを実行するか、又は、ボイス・メールへと送信してもよい。この後ユーザには、実行された処理が通知される。このことによって、通話がユーザに到達するのを部分的に防ぐ一方で、先に特定された問題の解決に必要となる低電力要件の概念を欠くものとなっている。例えば当該諸規則は、ユーザの移動体装置がアイドル・モードにあるか否かにかかわらず、常に適用される。このことは、電力の節約という点を意図していない。我々は、ＵＥがアイドル・モードにあるときのみサーバーが作動するのを希望している。したがって、先行技術が認識される一方で、解決には、本発明が取り組むアイドル・モード要件の考慮が依然として必要である。

したがって本発明の目的は、先行技術の上述の不都合及び欠点を克服するか又は少なくとも大幅に改善することである。具体的には、本発明の目的は、移動ノード（モバイルノード）が複数のアンカー・ポイントにわたって効率的にパケットを転送することを可能にする機構を提供することである。

したがって、本発明は、セルラー通信システム内の該移動ノード用装置を提供し、前記装置は、該移動ノードのステータスをセルラー・ネットワークに通知するステータス通知手段を備え、該ステータスは、該移動ノードが特定のサービスと関連付けられたデータを処理可能な否かを、該セルラー・ネットワークが判定することを許可し、その結果、該移動ノードが該特定のサービスと関連付けられたデータを処理可能でないと判定される場合には、該特定のサービスと関連付けられたデータ・パケットは該移動ノードに配信されないことを特徴とする。

好適な一実施形態では、該ステータス通知手段は、該セルラー・ネットワークに送信されたトラッキング・エリア更新メッセージに特別な情報を挿入することによって、該移動ノードのステータスを通知する。

他の好適な実施形態では、該ステータス通知手段は、該セルラー・ネットワークに送信されたトラッキング・エリア更新メッセージに特別な情報を挿入することによって、該移動ノードのステータスを該特定のサービスと関連付けられたデータを処理可能であると通知し、該セルラー・ネットワークに送信された特別な情報を付けずに正常なトラッキング・エリア更新メッセージを送信することによって、該移動ノードのステータスを該特定のサービスと関連付けられたデータを処理可能でないと通知する。

他の好適な実施形態では、該特別な情報は、該移動ノードが該サービスをサポートできないことを示す情報である。

さらに他の好適な実施形態では、該装置は、該特定のサービスと関連付けられたデータを処理可能である該移動ノードのステータスが変更されるときに、トラッキング・エリア更新メッセージを該セルラー・ネットワークに送信するトラッキング・エリア更新手段を更に備える。

さらに他の好適な実施形態では、該ステータス通知手段は、該移動ノードが該特定のサービスと関連付けられたデータを処理可能な単一の又は複数の位置の位置情報を該セルラー・ネットワークに登録することによって、該移動ノードのステータスを通知し、その結果、該セルラー・ネットワークに知られている該移動ノードの該位置がいずれの該登録された位置情報の中にもない場合には、該特定のサービスと関連付けられたデータ・パケットが配信されない。

さらに好適な実施形態では、位置情報の該登録が、該セルラー・ネットワークが該移動ノードのために保守する通信ベアラと関連付けられたトラフィック・フロー・テンプレート中に、該位置情報を挿入することによって実行され、その結果、該データ・パケットのパラメータが、該トラフィック・フロー・テンプレート中に含まれる対応するパラメータと一致する場合に、該セルラー・ネットワークに知られている該移動ノードの該位置が、該トラフィック・フロー・テンプレートに挿入された位置情報と一致する場合にのみ、データ・パケットが該セルラー・ネットワークによって該移動ノードに配信される。

さらに好適な実施形態では、該装置は、該移動ノードが該セルラー・ネットワークに登録された位置情報と一致する位置にあるが、しかし、該移動ノードは該特定のサービスと関連付けられたデータを現在処理可能でない場合には、追加情報を備えた位置を該セルラー・ネットワークに報告するよう、該移動ノードが現在接続されている基地局に対して要求する位置更新手段を更に備えており、該報告された位置への該追加情報によって、該セルラー・ネットワークは、該移動ノードが該登録された位置情報と一致する位置にないとして取り扱い、その結果、該特定のサービスと関連付けられたデータ・パケットが該移動ノードに配信されないことを特徴とする。

さらに別の好適な実施形態では、該移動ノードが該特定のサービスと関連付けられたデータを現在処理可能でない場合には、該ステータス通知手段は、該移動ノードが該セルラー・ネットワークに登録された位置情報と一致する位置にある場合にあっても該特定のサービスと関連付けられたデータ・パケットが該セルラー・ネットワークによって配信されないよう、該トラフィック・フロー・テンプレートを修正する。

さらに他の好適な実施形態では、該ステータス通知手段は、該セルラー・ネットワークによって送信されたページング要求に応答して、該セルラー・ネットワークに送信されるサービス要求メッセージ中に、該移動ノードのステータスを該特定のサービスと関連付けられたデータを処理不可能として通知し、該ページング要求は該特定のサービスと関連付けられたデータ・パケット向けのものであるとともに、該サービス要求は、該移動ノードと該セルラー・ネットワークとの間にアクティブな通信ベアラが確立されないようにする特別な指示を有することを特徴とする。

他の好適な実施形態では、該装置は、サービス関連制限リストを構成するように配置され、その結果、該ネットワークが、対応するサービス・データ・トラフィックを該サービス関連制限リスト中の該位置にのみ配信する。

他の好適な実施形態では、該ネットワークは該制限リスト中のセル上でのみ移動ノードをページングする。

他の好適な実施形態では、ＲＲＣ層メッセージを用いて該ステータスの信号を送るよう配置されている。

別の好適な実施形態では、ネットワークは、Ｍ２Ｍ活動がわかっているＩＰパケット処理及び情報更新に着目する。このＭ２Ｍアプリケーションは、特定のＩＰアドレス、又はポート番号、又はＩＰアドレスとポート番号の組み合わせを、ホワイト・リスト又はブラック・リストのいずれかとして用いられると識別することが可能となるように、設計することができる。ホワイト・リストは、これら「フィルタ」が着信パケットによって通過されなければならないことを意味する。ブラック・リストはこれらフィルタが着信パケットによって通過されてはならないことを意味する。簡便さのために、本発明はホワイト・リストに着目する。ここで、Ｍ２Ｍアプリケーション・サーバーは典型的にはコア・ネットワーク要素へのアクセスを持たない。したがって、このフィルタ情報のｐ２ｐ交換の後に、このリストを用意するのはＵＥアプリケーションである。当該アプリケーションは、このリストを３ＧＰＰアーキテクチャ内のＮＡＳ（非アクセス層）といった下位層制御スタックに提供する。次いでＮＡＳはこの情報をコア・ネットワークに提供し、ＵＥがアイドル・モードにあるときにのみこれらフィルタが適用されるものとする旨の指示を提供する。ＮＡＳはまた、フィルタを通過しないパケットのパケット情報をネットワークが保存することを、コア・ネットワークに対して指示する。次いでネットワークは、ＵＥがネットワークに他の理由により再び接続するときにのみ、それらをＵＥに提供する。

上記の方法は２つのことを保証する。第一に、Ｍ２Ｍデバイスがすでにコネクティッド・モードにあるときに、ネットワークは重要でないパケットを不必要に止めない。デバイスが接続されている場合は、当該デバイスは受信しうるあらゆる問い合わせを受信及び回答しても差し支えない。フィルタリングを実行する決定は、Ｍ２Ｍデバイスによって提供される指示に基づく。第二に、フィルタリングが行われ、いくつかのパケットがブロックされるときは、当該ネットワークは確実に、失われたパケットをＭ２Ｍデバイスに即座に通知しないようにする。その理由は、Ｍ２Ｍデバイスに通知することによって目的全体を無効にすると思われるからである。ネットワークは、Ｍ２Ｍデバイスがコア・ネットワークに再び接続するまで、ブロックされたパケット又は不許可パケットのリストのフィルタリング及びリストへの追加を続ける。コネクティッド・モードにＭ２Ｍデバイスを持つこの機会を用いて、当該ネットワークは不許可パケットのリストをＭ２Ｍデバイスへと送信する。ひとたびＭ２Ｍデバイスが不許可パケットのリストを受信すると、Ｍ２Ｍデバイス中のアプリケーションはこの情報を使って、特定のＩＰアドレスを問い合わせてもよく、Ｍ２Ｍデバイスが接続された理由についての情報を得て、特定の上位層プロトコルに基づいて先に進むことを確実にする。

他の好適な実施形態では、本発明は、ＵＥがアイドル・モードにあるときにおけるＵＥでのアップリンク・データのＱｏＳ確認メカニズムを提案する。当該ＱｏＳ確認はデータにリアルタイム要件があるか否かを確認することを伴う。ここでリアルタイムは、様々な意味に用いることができる。例えば、媒体はマルティメディア発信に基づいているか、又は、ＵＥは緊急メッセージ等を送信する必要があるなどである。リアルタイム要件の必要性に基づき、ステータス通知手段はネットワークにリアルタイム要件を通知し、データがいずれのベアラ・コンテキストに関連するかについての情報を提供してもよい。ネットワークは、自己の現在のリソースに基づき、ステータス中の情報を用いて、接続がセットアップされるのを許容するか否かについて決定を行う。

本発明は、ネットワーク・リソース及び携帯電話リソースの消耗を低減する利点を有する。

本発明の好適な実施形態によるユーザ装置の好適な機能アーキテクチャを示す。 サーバーが、ユーザ装置の助けを受けて、セルラー・ネットワークを介して、諸デバイスと通信する配置を示す。 自己のステータスをセルラー・ネットワークに指示する好適な実施形態によるユーザ装置のメッセージ・シーケンス図を示す。 サービスが好適な実施形態によるユーザ装置に提供されることを許可するか又は許可しないセルラー・ネットワーク・ゲートウェイのメッセージ・シーケンス図を示す。 サービスが好適な実施形態によるユーザ装置に提供されることを許可するか又は許可しないセルラー・ネットワーク移動体管理エンティティのメッセージ・シーケンス図を示す。 本発明の好適な実施形態によるユーザ装置によるトラッキング・エリア更新の送信についてのフローチャートを示す。 サービスが有効とされるべき位置を登録する本発明の好適な実施形態によるユーザ装置のメッセージ・シーケンス図を示す。 サービスが有効とされるべき位置を登録する本発明の好適な実施形態によるユーザ装置のメッセージ・シーケンス図を示す。 特定のサービス／ベアラと関連付けられたページングの最適化のためのベアラ管理手続を活用するユーザ装置のメッセージ・シーケンス図を示す。 本発明の好適な実施形態によるｅＮＢの好適な機能アーキテクチャを示す。 本発明の好適な実施形態によるｅＮＢのメッセージ・シーケンス図を示す。 図１０中の構成に基づくより詳細なｅＮＢにおけるプロセスを示す。 活動ベースのフィルタ処理を実行するシステムのシステム構成を示す。 ＵＥの別の好適な装置を示す図である。 ネットワークのための好適な装置を示す図である。 移動性を考慮したパケット・フィルタ情報を構成するＵＥの好適な方法を示す図である。 不許可パケット・リストを処理するＵＥの好適な方法を示す図である。 ネットワーク内において活動ベースのパケット処理を構成するよう要求される好適な方法を示す図である。 ネットワークによる移動性を考慮したパケット・フィルタ処理の好適な方法を示す図である。 アイドル・モード専用パケット・フィルタリングの好適な方法を示す図である。 情報保存を伴うアイドル・モード専用パケット・フィルタリングの好適な方法を示す図である。 ＵＥ装置の別の実施形態を示す図である。 ＵＥ中で処理待ち中のアップリンク・データの好適な評価方法を示す図である。 シグナリング接続のセットアップのためのＵＥのネットワークとの相互作用を示す図である。 ネットワークによるシグナリング接続セットアップの好適な方法を示す図である。

以下の説明において、説明目的のため、具体的な数、回数、構成、プロトコル名、及び他のパラメータは、本発明の完全な理解を提供するために記載される。しかしながら、提示された発明がこれら具体的な詳細事項がなくても実施しうることはいずれの当業者にも明らかであろう。

[第１の実施の形態]
＜発明の原理＞
本発明は次のような態様に適用することができる。すなわち、移動ノードとも呼ばれるユーザ装置（ＵＥ）が、セルラー・ネットワークなどの広域ネットワークに自己のステータスを通知し、その結果、特定のサービスと関連付けられたデータを該ユーザ装置が処理可能か否かを、広域ネットワークが該ステータスにもとづいて判定する。ユーザ装置が、該特定のサービスと関連付けられたデータを処理可能でないと判定される場合には、該特定のサービスと関連付けられたデータ・パケットは、ユーザ装置に配信されない。本発明の以下の好適な実施形態は、本発明の例示的な適用を提供する。

＜装置＞
図１は、無線ブロック１１０、アクセス階層（ＡＳ）ブロック１２０、非アクセス階層（ＮＡＳ）１３０、ＩＰプロトコル・ブロック１４０、アプリケーション・ブロック１５０、ステータス通知手段１６０、及びステータス検知手段１７０から成る、ＵＥの好適な機能アーキテクチャ１００を示す。

無線１１０は、ＵＥがセルラー基地局と通信することを可能にするのに必要なハードウェア及びファームウェアから成る機能ブロックである。無線は、アンテナ、送信側回路及び受信側回路を含んでもよい。これは、システムが有線環境に用いられることを除外しない、すなわち、無線１１０機能は、インタフェース１９１をそのままにして、有線伝送手段によって置き換えることができることは、いずれの当業者にとっても明らかである。無線１１０を、Ｕｎｌｉｃｅｎｓｅｄ Ｍｏｂｉｌｅ Ａｃｃｅｓｓ（ＵＭＡ）又はＧｅｎｅｒｉｃ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（ＧＡＮ）などの通信スタックの上で動作させることもまた可能である。

アクセス階層（ＡＳ）１２０は、無線アクセス制御及びセルラー無線ネットワークへの信号伝達、及び、無線１１０アクセス上の情報の伝送を実装する機能ブロックである。信号経路１９１は、データ及び制御信号がＡＳ１２０と無線１１０との間で送信又は受信されるのを許可する。

非アクセス階層（ＮＡＳ）１３０は、制御プレーン信号伝達、及び、ＵＥとセルラー・ネットワークとの間のデータのユーザ・プレーン伝送の開始を実装する機能ブロックである。信号経路１９２は、ＮＡＳ１３０及びＡＳ１２０が制御情報及び信号伝達メッセージを交換するのを許可する。

ＩＰプロトコル１４０は、ＵＥがグローバル・インターネット上の他のノードと通信するために、セルラー・ネットワーク全体にわたってインターネット・プロトコルを実装するソフトウェアから成る機能ブロックである。経路１９０は、データ・パケットが、送信及び受信のためにＩＰプロトコル１４０とＡＳ１２０の間で転送されるのを許可する。経路１９３は、制御信号が、ＩＰプロトコル１４０とＮＡＳ１３０の間を通過するのを許可する。

アプリケーション１５０は、他のエンティティと通信する必要がある、ＵＥ上で起動しうるソフトウェア及びプログラムから成る機能ブロックである。例えば、アプリケーション１３０は、ユーザがＵＥで音声通話を実行するのを可能にするボイス・オーバーＩＰプログラム、及び、ユーザがＵＥでワールド・ワイド・ウェブを閲覧するのを可能にするウェブ・ブラウザを含んでもよい。データ経路１９４は、データ・パケットがアプリケーション１５０とＩＰプロトコル１４０の間を通過するのを可能にする。

上記の機能ブロックは典型的には、すべてのＵＥ中に存在する。本発明は、ステータス検知手段１７０とステータス通知手段１６０とを導入する。ステータス検知手段１７０は、ＵＥの現在のステータスを検知し、ＵＥのステータスに変化が検知されるときには、信号経路１９７を介してステータス通知手段１６０に通知する。ステータス通知手段１６０は、信号経路１９５を介してＡＳ制御メッセージを送信することによって、又は信号経路１９６を介してＮＡＳ制御メッセージを送信することによって、セルラー・ネットワークにステータスの変化を通知してもよい。

ＮＡＳブロック１３０がＵＥのステータスを含む制御メッセージをネットワークに送信する必要があるときにはいつでも、ＮＡＳブロック１３０は、ステータス通知手段１６０から信号経路１９６を介して指示されるべきステータスを取得することもまた可能である。同様に、ＡＳブロック１２０がＵＥのステータスを含む制御メッセージをネットワークに送信する必要があるときにはいつでも、ＡＳブロック１２０は、ステータス通知手段１６０から信号経路１９５を介して指示されるべきステータスを取得することが可能である。ステータス通知手段１６０が、ＮＡＳ１３０及び／又はＡＳ１２０から信号経路１９６及び１９５をそれぞれ介して、情報を取得してステータス情報を生成することもまた可能である。

＜アプリケーション例：スマート・グリッド＞
本発明が容易に理解されるためには、本実施形態では、図２に示される例示的なアプリケーション・シナリオを用いて、本発明を説明する。図２は、デバイス２１２、２１４とサーバー２１９の間のセルラー・ネットワーク２４０上の通信セッションを示している。これは図解としては、スマート・グリッド電力事業アプリケーション用のマシン・ツー・マシンの通信であってもよい。ここでは、サーバー２１９はスマート・グリッド供給業者に配置されており、デバイス２１２、２１４はユーザの住居に配置されている家電製品である。デバイス２１２、２１４がローカル・エリア・ネットワーク２５０を介してＵＥ２００と接続されているときには、サーバー２１９は、セルラー・ネットワーク２４０及び携帯電話ＵＥ２００を介して、デバイス２１２、２１４と通信する。ローカル・エリア・ネットワーク２５０は、ＩＥＥＥ８０２．１１ ＷｉＦｉ、Ｚｉｇｂｅｅ（登録商標）又は電力線通信を含んでもよいが、これに限定されない。

典型的なセルラー・ネットワーク２４０であれば、様々なセルラー基地局ｅＮＢ２４１及びｅＮＢ２４４、移動体管理エンティティＭＭＥ２４２、サービング・ゲートウェイＳＧＷ２４６、及びパケット・データ・ネットワーク・ゲートウェイＰＤＮ ＧＷ２４８から成る。基地局ｅＮＢ２４１及びｅＮＢ２４４はそれぞれ、各受信可能エリア内の携帯電話にセルラー無線アクセスを提供する。例えば、ＵＥ２００が位置２０１にあるときには、ＵＥ２００は、接続２５１を介してｅＮＢ２４１に接続することによって、ネットワーク２４０へのアクセスを得る。ＵＥ２００が位置２０４にあるときには、ＵＥ２００は、接続２５４を介してｅＮＢ２４４に接続することによって、該ネットワーク２４０へのアクセスを得る。

ＭＭＥ２４２は、セルラー・ネットワークに接続されたＵＥの移動体を管理する。ＳＧＷ２４６は、一群の基地局の中で当該ＵＥのアンカー・ポイントである。ＭＭＥ２４２の指示のもとでは、ＳＧＷ２４６と、現在ＵＥが接続されている基地局との間の適切なベアラが確立される。ＰＤＮ ＧＷ２４８は、セルラー・ネットワークと、他のパケット交換方式ネットワーク（グローバル・インターネットなど）との間のゲートウェイである。あるＵＥに対するデータ・パケットがＰＤＮ ＧＷ２４８によって受信されると、ＰＤＮ ＧＷ２４８は、パケットをサービング・ゲートウェイＳＧＷ２４６へと経路設定する。そして、ＳＧＷ２４６は、基地局との間で確立されたベアラを介してパケットをＵＥへと転送する。

スマート・グリッド電力事業アプリケーションに対するマシン・ツー・マシン通信の例を用いると、サーバー２１９によって開始されるいずれのデータ通信も、ＵＥ２００が位置２０１にあって、デバイス２１２及び／又は２１４に接続されている場合にのみ、有用となる。ＵＥ２００が位置２０４にある場合であっても、サーバー２１９によって開始された通信によって、ＵＥ２００がページングされて、省電力ＩＤＬＥモードからウェイク・アップされ、自己のサービング・ゲートウェイＳＧＷ２４６とのアクティブな通信路が確立されるが、この通信は、サーバー２１９からデータを受信するためだけのものであり、そもそもこのデータはデバイス２１２／２１４へと配信できない。これによって、セルラー・ネットワークとユーザ装置の両方のリソースを消耗することになる。

＜ステータス通知のための新しいＩＥを含むトラッキング・エリア更新＞
本発明の好適な一実施形態は、ＵＥ２００に自己のステータス（状態）をセルラー・ネットワークへ通知させることによって、係る消耗が発生するのを防止する。係るステータスは、ＵＥがある特定のサービスと関連付けられたデータを現在処理可能か否か（ＵＥ２００がデバイス２１２／２１４に接続され、スマート・グリッド・アプリケーション・サービスの配信が可能であるかどうか、など）を、該ネットワークに通知するものであってもよい。

当該ステータスが、ＵＥが前記サービスと関連付けられたデータを現在処理可能な（例えば、ＵＥ２００がデバイス２１２／２１４に接続されている）ことを示す場合、ネットワークは、前記サービスの開始を許可し、前記サービスが開始されるとき（例えば、サーバー２１９がスマート・グリッド・アプリケーション・メッセージを送信するとき）には、ＵＥに通知することができる。当該ステータスが、ＵＥが前記サービスと関連付けられたデータを現在処理可能でない（例えば、ＵＥ２００がデバイス２１２／２１４に接続されていない）ことを示す場合には、ネットワークは前記サービスの開始（起動）を無効にするべきであり、前記サービスの起動をＵＥに通知するべきではない。図３はこのことを図解する汎用のメッセージ・シーケンス図である。

図３では、プロセス・ブロック（ステータス検知）３１０によって図示されるように、ＵＥ２００のステータス検知手段は、まず初めに、ＵＥの現在のステータス（例えば、ＵＥ２００がデバイス２１２／２１４に現在接続されているか否か）を判定する。検知されたステータスが肯定である（例えば、ＵＥ２００がデバイス２１２／２１４に接続されている）と想定すると、ＵＥ２００のステータス通知手段は、ステータス更新メッセージ３１２をネットワーク２４０に送信して、ＵＥ２００が前記サービスを処理可能なことを示す。それゆえに、サーバー２１９がデータ３２０をＵＥ２００に送信する（例えば、デバイス２１２への配信のために）と、ネットワーク２４０はデータ３３０をＵＥ２００に転送するか、又は、ＵＥがＩＤＬＥモードにある場合には、ＵＥ２００をページングしてアクティブな接続を確立する（図３には図示されない）。

しばらく時間が経過した後に、ＵＥ２００のステータス検知手段は、プロセス・ブロック（ステータス検知）３４０によって図示されるように、ＵＥのステータスが変化した、ここでは、ＵＥは、デバイス２１２、２１４との接続が切れたことを検知する。これは、いくつかの理由に起因しうる。当該理由は、ＵＥ２００が位置２０４に移動した（すなわち、ＵＥがコネクティッド・モードである時に、デバイス２１２、２１４との接続を有するセルから他のセルにハンドオーバされた、又は、ＵＥがアイドル・モードである時に、デバイス２１２、２１４との接続を有するセルの受信可能エリアから他のセルの受信可能エリアへと単に移動した）、デバイス２１２、２１４がＵＥとの接続範囲から出て行った、又は、デバイス２１２、２１４の電源が切られたことを含むが、これらに限定されない。

ＵＥ２００のステータス通知手段は、上述の条件のもとで、ステータス更新メッセージ３４２をネットワーク２４０に送信して、ＵＥ２００が前記サービスを処理可能でないことを示す。それゆえに、サーバー２１９がデータ３５０をＵＥ２００に送信する（例えば、デバイス２１２への配信のために）と、プロセス・ブロック（廃棄）３６０によって示されるように、ネットワーク２４０はデータを廃棄する。

本実施形態において記載された手順によって、ＵＥが処理不可能なサービスの配信のための不必要なＵＥのウェイク・アップが低減されるであろうことは、当業者には自明である。それゆえに、本好適な実施形態により、本発明の目的は達成される。

＜ＰＤＮ ＧＷアプローチ＞
上記の図解及び説明は、本発明が容易に理解できるように、概念的な態様でなされている。以下の好適な実施形態では、図３に記載されたものを実装する２つの異なるアプローチが開示される。

第１のアプローチは図４に示され、ＰＤＮ ＧＷがＵＥのステータス通知を受けて、ＵＥのステータスがＵＥが前記特定のサービスを現在処理可能でないことを示す場合には、ＰＤＮ ＧＷは特定のサービスに対するパケットを廃棄する。第２のアプローチは図５に示され、ＭＭＥがＵＥのステータスを通知され、ＵＥのステータスがＵＥが前記特定のサービスを現在処理可能でないことを示す場合には、ＭＭＥは特定のサービスに対するいかなるベアラも起動しない。

図４では、プロセス・ブロック（ステータス検知）３１０ によって図示されるように、ＵＥ２００のステータス検知手段はまず初めに、ＵＥの現在のステータス（例えば、ＵＥ２００がデバイス２１２／２１４に現在接続されているか否か）を判定する。検知されるステータスが肯定である（例えば、ＵＥ２００がデバイス２１２／２１４に接続されている）と想定すると、ＵＥ２００のステータス通知手段は、ステータス情報要素をトラッキング・エリア更新（ＴＡＵ）メッセージ４１２に挿入する。ステータス情報要素は、ＵＥ２００が前記サービスと関連付けられたデータを処理可能なことを示す。

トラッキング・エリア更新メッセージは、ＵＥが、自己が接続している現在の基地局をＭＭＥに通知するために送信する情報要素の一群を含有する、既存の３ＧＰＰ ＮＡＳメッセージである。このメッセージによって、ＭＭＥが、ＵＥが存在するエリアを追跡し、当該ＵＥに対するダウンリンク・データがある場合に選択された基地局群のみをページングできるようになる。本実施形態では、ＵＥのステータスを示す新しい情報要素を挿入する。ＭＭＥ２４２は、ＴＡＵメッセージ４１２中にこの新しい情報要素を見いだすと、メッセージ４１４中のＳＧＷ２４６にステータス通知を送信する。

ＳＧＷ２４６は次いで、このステータス通知をメッセージ４１６内に入れてＰＤＮ ＧＷ２４８に渡す。ＭＭＥがステータス通知メッセージをＰＤＮ ＧＷに直接的に送信できることは、当業者には自明であるはずである。ＳＧＷが図３の実施形態に関与する理由は、現在は、ＭＭＥとＰＤＮ ＧＷの間には３ＧＰＰアーキテクチャで定義される直接通信は存在しないからである。ステータス通知が任意の形態で（新しいメッセージとして、又は既存のメッセージ中に挿入された新しい情報要素として）あってもよいこともまた、当業者には自明であるはずである。

この時点でＰＤＮ ＧＷ２４８がＵＥ２００のステータスがわかるので、サーバー２１９はデータ３２０をＵＥ２００に送信する（例えば、デバイス２１２への配信のために）と、ＰＤＮ ＧＷ２４８は、データ４２２が、ＳＧＷ２４６に転送されるのを許可する。ＳＧＷ２４６がＵＥ２００に向かうアクティブなベアラを有していない場合は、例えば、ＵＥがＩＤＬＥモードにあるときには、ネットワークは、データ３３０をＵＥ２００に転送するか、又はＵＥ２００をページングしてアクティブな接続を確立する（図４には図示されない）。

しばらく時間が経過した後に、ＵＥ２００のステータス検知手段は、プロセス・ブロック（ステータス検知）３４０ によって図示されるように、ＵＥのステータスが変化した、ここでは、ＵＥはデバイス２１２、２１４との接続が切れたことを検知すると想定する。これは、いくつか理由に起因しうる。当該理由は、ＵＥ２００が位置２０４に移動した（すなわち、ＵＥがデバイス２１２、２１４との接続を有するセルから、コネクティッド・モード中に他のセルへとハンドオーバされた、又はＵＥがデバイス２１２、２１４との接続を有するセルの受信可能エリアからＩＤＬＥモード時に、他のセルの受信可能エリアへと単に移動した）、デバイス２１２、２１４がＵＥとの接続範囲から出て行った、又はデバイス２１２、２１４の電源が切られたことを含むが、これらに限定されない。

ＵＥ２００のステータス通知手段は、上述の条件のもとでは、トラッキング・エリアは変更しなかったがセルＩＤは変更したときでさえも、新しいＴＡＵメッセージ４４２を送信する。このＴＡＵメッセージは新しい情報要素を含まない。ゆえに、ＭＭＥ２４２はこのメッセージから、ＵＥは前記サービスと関連付けられたデータをもはや処理可能でないことを検出できる。当業者であれば、ＵＥ２００が前記サービスと関連付けられたデータを処理可能でないことを示すステータス情報要素もまた、同一の作業効果を達成するためにＴＡＵメッセージ４４２に挿入可能なことを理解するであろう。

ＴＡＵメッセージ４４２を受信した後に、ＭＭＥ２４２はステータス通知をメッセージ４４４中に入れてＳＧＷ２４６に送信する。ＳＧＷ２４６は次いで、このステータス通知をメッセージ４４６ 中に入れてＰＤＮ ＧＷ２４８に渡す。サーバー２１９がデータ３５０をＵＥ２００に送信する（例えば、デバイス２１２への配信のために）と、ＰＤＮ ＧＷ２４８は、ＵＥ２００がデータを現在処理可能でないことを知り、このため、プロセス・ブロック（廃棄）４６０によって示されるようにデータを廃棄する。

同じように、ステータス検知手段がＵＥのステータスが変化したことを検知すると、例えば、ＵＥ２００が位置２５０に戻り、ＵＥデバイス２１２、２１４との接続を得る（例えば、ＵＥがデバイス２１２、２１４との接続を有するセルへとコネクティッド・モード中に他のセルからハンドオーバされているか、又はＩＤＬＥモードにある時に、他のセルからＵＥがデバイス２１２、２１４との接続を有するセルの受信可能エリアへと単に移動したか、デバイス２１２、２１４がＵＥとの接続範囲内に戻ってきたか、又はデバイス２１２、２１４の電源が入れられ、ＵＥとの接続が確立されたことなどを理由に）と、ＵＥ２００のステータス通知手段は、上述の条件のもとでは、トラッキング・エリアは変更しなかったがセルＩＤは変更したときでさえも、新しいＴＡＵメッセージ４１２を送信する。このＴＡＵメッセージは新しい情報要素を含む。ゆえに、ＵＥは前記サービスと関連付けられたデータを再び処理可能であることを、ＭＭＥ２４２がこのメッセージから認識することができる。

ＰＤＮ ＧＷ２４８は、ＵＥステータスに基づいて、接続のためのＱｏＳリソースを制御してもよい。例えば、ＵＥ２００が登録された位置から出ると、ＵＥ２００が登録された位置のうち１つに戻って来るまではサービスは可能でないので、ＰＤＮ ＧＷ２４８は、ＰＤＮ接続又は当該サービスのベアラのためのＱｏＳリソースを低減、一時停止又は一時的に削除してもよい（しかしコンテキストは保持してもよい）。次いで、ＵＥ２００が登録された位置のうち１つに戻ると、サービスがＵＥ２００に対して利用可能になるので、ＰＤＮ ＧＷ２４８はサービスに対するＱｏＳリソースを増加、再開、又は（再）確立してもよい。

本実施形態において記載された手順によって、ＵＥが処理可能な状態にないサービスの配信のための不必要なＵＥのウェイク・アップが低減されるであろうことは、当業者には自明であるはずである。それゆえに、本好適な実施形態により、本発明の目的は達成される。

＜ＭＭＥアプローチ＞
図５では、ＭＭＥがＵＥのステータスを通知され、ＵＥのステータスがＵＥが前記特定のサービスと関連付けられたデータを現在処理可能でないことを示す場合には、ＭＭＥは特定のサービスに対するいかなるベアラも起動しないアプローチが図解される。

まず初めに、ＵＥ２００のステータス検知手段は、プロセス・ブロック（ステータス検知）３１０によって図示されるように、ＵＥの現在のステータス（例えば、ＵＥ２００がデバイス２１２／２１４に現在接続されているか否か）を判定する。検知されるステータスが肯定である（例えば、ＵＥ２００がデバイス２１２／２１４に接続されている）と想定すると、ＵＥ２００のステータス通知手段は、ステータス情報要素をＴＡＵメッセージ５１２に挿入する。ステータス情報要素は、ＵＥ２００が前記サービスを処理可能なことを示す。

ここで今やＭＭＥ２４２はＵＥ２００のステータスを知っている。ここでサーバー２１９は、データ・メッセージ３２０（例えば、デバイス２１２への配信のためのデータ）を送信すると仮定する。ＰＤＮ ＧＷ２４８がこのパケットを受信すると、ＰＤＮ ＧＷ２４８は、データ・パケット５２２をＳＧＷ２４６に転送する。ＵＥ２００に対するアクティブなベアラがない場合には、ＳＧＷ２４６はダウンリンク・データ通知５２４をＭＭＥ２４２に送信する。これはＭＭＥ２４２に対してアクティブなベアラを設定するよう要求するものである。このダウンリンク・データ通知は、また、当該ダウンリンク・データと関連付けられたサービスのタイプを含み、その結果、ＭＭＥはＵＥ２００の現在のステータスを確認することができる。

この場合、ＵＥ２００は、サービスと関連付けられたデータを自己が処理可能である（例えば、ＵＥ２００がデバイス２１２／２１４に接続されている）ことを、先にＴＡＵメッセージ５１２中に示している。それゆえにＭＭＥ２４２は、ページング・メッセージ５２５によって示されるように、ＵＥのページングへと進む。ＵＥ２００は次いで、ＩＤＬＥ又は他の省電力モードからウェイク・アップし、サービス要求メッセージ５２６を送信する。このサービス要求メッセージ５２６を受信した後、ただちにＭＭＥ２４２はいずれの基地局にＵＥが現在接続されているかを知る。それゆえに、基地局とＳＧＷ２４６の間でアクティブなベアラを確立することができる。データ・パケット（データ）３３０はＵＥ２００に送信される。

しばらく時間が経過した後に、プロセス・ブロック（ステータス検知）３４０によって図示されるように、ＵＥ２００のステータス検知手段は、ＵＥのステータス（状態）が変化したこと、ここでは、ＵＥがデバイス２１２、２１４との接続が切れたことを検知すると想定する。これは、いくつかの理由に起因しうる。当該理由は、ＵＥ２００が位置２０４に移動した（すなわち、ＵＥがデバイス２１２、２１４との接続を有するセルから、コネクティッド・モード中に他のセルへとハンドオーバされた、又はＵＥがデバイス２１２、２１４との接続を有するセルの受信可能エリアからＩＤＬＥモード時に、ある他のセルの受信可能エリアへと単に移動した）、デバイス２１２、２１４がＵＥとの接続範囲から出て行った、又はデバイス２１２、２１４の電源が切られたことを含むが、これらに限定されない。次いで、ＵＥ２００のステータス通知手段は、上述の条件のもとでは、トラッキング・エリアは変更しなかったがセルＩＤは変更した場合でさえも、新しいＴＡＵメッセージ５４２を送信する。

このＴＡＵメッセージ５４２は新しい情報要素を含まず、このため、ＵＥは前記サービスと関連付けられたデータを、もはや処理可能でないことを、ＭＭＥ２４２が認識することができる。今ここでサーバー２１９がデータ・パケット（データ）３５０（例えば、デバイス２１２への配信のためのデータ）を送信すると仮定する。ＰＤＮ ＧＷ２４８はこのデータ・パケットを受信すると、データ・パケット（データ）５５２をＳＧＷ２４６に転送する。ＵＥ２００に対するアクティブなベアラがないので、ＳＧＷ２４６はダウンリンク・データ通知５５４をＭＭＥ２４２に送信する。

この通知はＭＭＥ２４２に対してアクティブなベアラを設定するよう要求する。このダウンリンク・データ通知はまた、このダウンリンク・データと関連付けられたサービスの種類（タイプ）を、ＭＭＥが識別するための種類（タイプ）又は情報を含み、その結果、ＭＭＥはＵＥ２００の現在のステータスと照合することができる。この場合、ＵＥ２００は、ＴＡＵメッセージ５４２中に、サービスと関連付けられたデータを処理可能でない（例えば、ＵＥ２００がデバイス２１２／２１４に接続されていない）ことを先に示している。それゆえにＭＭＥ２４２は、このダウンリンク要求を拒絶し、ＵＥのページングをしない。ゆえにＳＧＷ２４６は、プロセス・ブロック（廃棄）５６０によって示されるように、データを廃棄する。

同様に、ＵＥのステータス検知手段は、ステータスが変化したこと、例えば、ＵＥ２００が位置２５０に戻り、ＵＥデバイス２１２、２１４との接続を得る（例えば、ＵＥがデバイス２１２、２１４との接続を有するセルへとコネクティッド・モード中に他のセルからハンドオーバされているか、又はＩＤＬＥモード時に、ある他のセルからＵＥがデバイス２１２、２１４との接続を有するセルの受信可能エリアへと単に移動したか、デバイス２１２、２１４がＵＥとの接続範囲内に戻ってきたか、又はデバイス２１２、２１４の電源が入れられ、ＵＥとの接続が確立されたことを理由に）ことを検知した場合には、ＵＥ２００のステータス通知手段は、上述の条件のもとでは、トラッキング・エリアは変更しなかったがセルＩＤは変更したときでさえも、新しいＴＡＵメッセージ５１２を送信する。このＴＡＵメッセージは新しい情報要素を含む。ゆえに、ＵＥは前記サービスと関連付けられたデータを再び処理可能であることを、ＭＭＥ２４２が認識できる。

本実施形態において記載された手順によって、ＵＥが処理不可能なサービスの配信のための不必要なＵＥのウェイク・アップが低減されるであろうことは、当業者には自明であるはずである。それゆえに、本好適な実施形態により、本発明の目的は達成される。

図５に示される信号伝達シーケンスは、ステータス情報が肯定通知である、すなわち、サービスがサポートされていることをＵＥ２００が示したい場合に用いられることを想定している。いずれの当業者にとっても、本発明が、否定通知によって作用する代替例を持ちうること、すなわち、ＵＥ２００がサービスがサポートされていることを示すために正常なＴＡＵを用い、サービスが拒絶されるべきことを示すために否定ステータス情報の付いたＴＡＵを用いることは、明らかである。それでも、図５に図示される信号伝達シーケンスは、メッセージ５１２を正常なＴＡＵすなわち正常なステータス通知で、並びに、メッセージ５４２を、サービスがサポートされていないことを示すステータスを含む特別なＴＡＵで、置き換えるだけでも適用可能である。この否定通知の代替例によって、古いＵＥ動作は影響を受けないであろう、すなわちＭＭＥは常に、ページング５２５を通常通り開始するであろう。

上述のステータス情報は時間成分とも関連付けることが可能なことはいずれの当業者にも明らかである。例えばステータス情報は、例えば、２００９年１０月１日午後２時から２００９年１０月１日午後４時までなど、ステータスの効力を示すこともできる。このように、ステータス更新のための信号伝達はさらに低減されうる。ネットワーク・ノード、例えばＭＭＥ又はＰＤＮ ＧＷは、ＵＥからの明示的な信号伝達を伴わずに、指示された時間に基づいてＵＥステータスを自動的に変更することができる。この方法を用いて、信号伝達のための最良の機会がある場合には、ＵＥ２００は、ステータス通知に対する事前信号伝達もいくつか行うことができる。

ステータス情報は、ＵＥを使用するユーザのＵＥ（通信端末）のサービス又は種類についての情報と関連付けられてもよい。例えばステータス情報は、ユーザＩＤ、ユーザ名、クレジットカード番号、トークンＩＤ、暗証番号、又はＩＭＥＩ（国際移動体装置識別番号）といった端末情報などユーザ情報も指示することができ、ステータス情報は、ユーザ又は端末が、ＰＤＮ中のエンティティなど、ネットワークによって認証及び／又は許可される場合にのみ利用可能である。認証及び／又は許可は、ステータス情報中に含まれる情報によってのみ、ある特定の認証及び／又は許可のための追加的手続によって実行することができる。ＰＤＮ ＧＷは、認証／許可の結果を取得し、認証／許可が成功裏に行われたときにはステータス情報を利用可能にし、そうでなければ、利用不可能にして、その結果、ステータス情報が、ＵＥ及び／又はサービスの実際のユーザ、又は端末の種類にしたがって活用できるようにする。

＜ＵＥのフローチャート＞
図４及び図５にそれぞれ図示された上記２つのアプローチは、ＵＥのステータスを用いて特定のサービスに対する通信を有効にするか又は無効にするかを決定するネットワーク・ノードにおいてのみ異なることが、認識されるであろう。図４に記載された第１のアプローチの場合、決定を行うのはＰＤＮ ＧＷである。図５に記載された第２のアプローチの場合は、ＭＭＥである。両方のアプローチにおいてＵＥの挙動に変更はない。図６はＵＥの挙動を示すフローチャートを図示する。

まず第１に、ＴＡＵメッセージの送信をトリガする２つのプロセス６１０及び６２０がある。プロセス６１０の場合、トリガは、ＵＥのトラッキング・エリア・リスト中にないトラッキング・エリア・コードの付いたセルを入力するとき、又はＴＡＵメッセージを送信するための周囲タイマーの期限が切れるときなど正規の３ＧＰＰ条件である。プロセス６２０の場合、トリガは、ＵＥのステータス検知手段がＵＥのステータスの変化を検知するときである。

両方の場合において、ＵＥが、ＴＡＵメッセージが送信されるべきことを決定すると、ステータス検知手段は次いで、決定ステップ６３０に示されるように、サービスと関連付けられたデータをＵＥが処理可能でないことを、ＵＥのステータスが示唆するか否かを確認する。ステータスが、ＵＥがサービスを処理できないことを示唆すると、プロセス・ブロック６４０に記載の処理はトリガされ、この場合、正常なＴＡＵメッセージが送信される。反対に、ステータスが、ＵＥがサービスと関連付けられたデータを処理可能なことを示唆すると、プロセス・ブロック６５０に記載の処理がトリガされ、ステータス情報要素を伴うＴＡＵメッセージが送信される。

上記のロジックが否定指示の代替例にも採用されうることはいずれの当業者にも明らかである。その場合には、ステップ６３０では、ＵＥのステータスが否定である、すなわち、サービスがサポートされていない場合には、ステップ６５０が実行されて、否定ステータス通知の付いたＴＡＵを生成する。ＵＥのステータスが肯定である、すなわち、サービスがサポートされている場合には、ステップ６４０におけるように正常なＴＡＵが生成される。この代替的な論理によって、古いＵＥはステップ６２０及び６３０を実行せず、したがって、ステップ６４０では正常なＴＡＵを常に生成する。

＜ＵＥは依然としてページングされる＞
図３、４及び５に図示されるアプローチでは、ＵＥは、ネットワークに自己のステータスを通知して、ＵＥのステータスに基づいて、サービスが許可されるべきか否かについて決定できるようになる。図７及び８に図示されるアプローチでは、ＵＥの位置を用いて、サービスが許可されるべきか否かを導き出す。これらのアプローチの目的は、ＵＥがサービスを処理可能でないときのサービスに対する不必要な信号伝達を低減することである。係る目的は全般的には達成されるものの、ＵＥがサービスを処理可能でないときにサービスに対する信号伝達が依然として発生しうる状況がある。

例えば、ＵＥは、ＵＥのステータス又は位置を更新するためのトラッキング・エリア更新メッセージを送信していないかもしれない。これは、ＵＥが依然として同じトラッキング・エリアにあることが理由となる。他の可能性は、ＵＥが依然として同じセル内にあるものの、もはやサービスと関連付けられたデータを処理可能でない（例えば、ＵＥ２００が自宅にあるが、デバイス２１２／２１４に接続されていない）ことである。単純には、ＵＥのステータスが変化するときは常に、ＵＥがトラッキング・エリア更新メッセージを送信して、ステータスの変化を通知する方法をとることができる。しかしながら、係る伝送のためにＵＥがバッテリー電源を浪費することになる。

別のアプローチは、ＵＥがサービスのためにページングされることである。ＵＥがウェイク・アップし、コネクティッド・モードに入ると、ＵＥは次いで、自己のステータスが変化したことをネットワークに通知することができ、その結果、ネットワークはもはや後続するサービスの開始のためにＵＥをページングしない。これは、ひとたびＵＥがコネクティッド・モードに入った後に、トラッキング・エリア更新（アップデート）を送信することによって、又はＵＥがベアラ・リソース修正メッセージを用いて、当該サービスと関連付けられた後続のデータ・パケットがＰＤＮ ＧＷによってフィルタリング除去されるように、トラフィック・フロー・テンプレートを修正することによって行われる。

さらに、ＵＥに送信されるページ要求は、当該ページが特定のサービスからのデータ・パケットに起因していることを示す特別な指示を含んでもよい。この特別な指示は例えば、優先順位指標（プライオリティ・インディケータ）を含んでもよく、この指標は、優先順位が当該指標より低い場合にはネットワークはいかなるベアラ・セットアップも許可しないことを示す。ＵＥがこの特別な指示を確認し、前記サービスと関連付けられたデータを処理可能でない場合は、ＵＥは、ページ要求に応答して特別なサービス要求を送信することができる。この特別サービス要求によって、ネットワークは、ＵＥがサービスを処理可能でないことを知り、このため、いずれのベアラも起動（アクティベート）されない。ＵＥは、特別サービス要求を送信した後、即座に省電モードに戻る。代替的には、例えば、送信するべきデータ又はシグナリング・メッセージが、指示された優先順位よりも低いものを有する場合は、ＵＥはサービス要求の送信を省略し、ページングを受信した後には省電モードに留まってもよい。

＜プレゼンスＡＰＩ＞
不必要なリソース消費をさらに低減するために、ネットワークはプレゼンス・アプリケーション・プログラミング・インタフェース（ＡＰＩ）をサーバーに提供することができ、その結果、サーバーは、当該プレゼンスＡＰＩを介して、ＵＥがサービスと関連付けられたデータを現在処理可能であるか否かについて通知を受けることができる。係るＡＰＩは、ウェブ・アプリケーションの一形態、リモート・プロシージャ・コール（ＲＰＣ）、又はリアリー・シンプル・シンジケーション（ＲＳＳ）フィードとして、実装されてもよい。このようにして、サーバーはＵＥへの通信を開始するか否かを判定することができる。

係るＡＰＩに対する代替例は、ＵＥがサービスと関連付けられたデータを処理可能でない間に、ＰＤＮ ＧＷがサーバーからデータ・パケットを受信するときに、エラー・コードで応答するもである。係るエラー・コードによって、自己のパケットがなぜ到達できなかったかを知ることが可能になり、サーバーは、合理的な長期間にわたり、さらなる再送処理をを抑制することができる。

本発明は本明細書中においてここまで、最も実用的かつ好適な実施形態と考えられるものについて図示及び記載されてきたが、設計及びパラメータの詳細に対する様々な修正が、本発明の範囲及び領域から逸脱することなく行われうることが当業者によって理解されるであろう。

[第２の実施の形態]
＜レガシーＭＭＥ：位置を含有するＴＦＴ＞
図４及び図５に図示された上記２つのアプローチの他の一特徴は、当該アプローチがＭＭＥ及びＰＤＮ ＧＷといった複数のネットワーク・エンティティへの変更を必要とすることである。下位互換性、ハードウェアコスト又はそれ以外の理由により、ネットワーク事業者は一般に、ネットワーク・ノードに必要とされる変更を最小限に保ちたいであろう。さらに、ユーザ装置がどこにあろうと、ユーザ装置には同じＰＤＮ ＧＷを割り当てることができ、その一方ＭＭＥの割り当ては、ＵＥが現在接続された基地局に一般に基づいているので、ＰＤＮ ＧＷのみを変化させることがより望ましい。

基本的な想定及び概念は第１の実施の形態と同じである。この実施形態における唯一の特別な点（すなわち先の実施形態との違い）は、上記に記載されたような実装コストなどの理由から、ＭＭＥが修正されていないことであり、このため、想定、概念及び構成の他の部分はこの実施形態においても同様に用いることができる。

この好適な実施形態は、新しい機能がＰＤＮ ＧＷのみで必要とされる、本発明の動作のノードを開示する。本質的にＵＥは、ＵＥがサービスを処理可能な単一又は複数のセル（例えば、ＥＣＧＩ ＥＵＴＲＡＮセル・グローバル識別子）を、ＰＤＮ ＧＷに登録する。例えば、スマート・グリッド・マシン通信のアプリケーション例では、ＵＥは自宅にあるときにのみ、家電製品に接続される。それゆえに、ＵＥは自宅を包含するセルをＰＤＮ ＧＷに登録することができる。ＵＥが、サービスに関連付けられたデータを処理可能なセル（単数又は複数）を登録することによって、前記サービスが開始されるときにはいつでも、ＰＤＮ ＧＷはＵＥの現在位置を該登録されたセルにもとづいて照合することができ、サービスを開始してもよいか否かを決定する。このことは、図７に図示される。

図７では、ステータス検知手段はプロセス・ブロック（ステータス検知）７１０に示されるように、ＵＥ２００のステータスを検知する。肯定ステータスが検知される（例えば、ＵＥ２００がデバイス２１２又は２１４に接続される）場合には、ステータス通知手段は、現在のセルのＥＣＧＩをＡＳ層から取得する。ＥＣＧＩがネットワーク２４０に登録されていない場合には、ステータス通知手段は、セル登録メッセージ７１２のネットワーク２４０への伝送をトリガする。該セル登録メッセージ７１２は、現在のセルのＥＣＧＩをネットワークに登録する。引き続いて、サーバー２１９がデータ７２０をＵＥ２００に送信する（例えば、デバイス２１２への配信のために）と、ネットワーク２４０はＵＥの現在位置を登録されたセルと照合する。現在位置が登録されたセルのうち１つと一致する場合には、ネットワーク２４０はＵＥ２００をページングしてアクティブな接続を確立し（図７には図示されない）、データ７３０をＵＥ２００に転送する。

しばらく時間が経過した後に、（プロセス・ブロック（他のセルへの移動）７４０によって示されるように）ＵＥが他のセルへと移動すると仮定すると、登録されたセルから任意の未登録セルへのハンドオーバ手続、及び／又は、ＵＥ移動の後にトラッキング・エリアは変化しなかったが、セルのみが変更した場合においても、ＵＥはＴＡＵ手続を実施し、最終的にネットワーク２４０は、ＵＥの位置情報、すなわち、新しいＥＣＧＩを、ハンドオーバ又はＴＡＵ手続を介して取得する。サーバー２１９がデータ７５０をＵＥ２００に送信する（例えば、デバイス２１２への配信のために）と、ネットワーク２４０はＵＥの現在位置を登録されたセルと照合し、現在位置が登録されたセルのいずれとも一致しないことを見出す。ネットワーク２４０はこうして、プロセス・ブロック（廃棄）７６０によって示されるようにデータを廃棄する。

再び、しばらく時間が経過した後に、ＵＥが以前に登録された別のセルへと移動すると仮定する（プロセス・ブロック（別のセルへの移動）７７０によって示されるように）と、任意の未登録のセルから該登録されたセルへのハンドオーバ手続、及び／又はＵＥ移動の後にトラッキング・エリアは変化しなかったが、セルのみが変更した場合においてもＵＥはＴＡＵ手続を実施し、最終的にネットワーク２４０は、ＵＥの位置情報、すなわち、登録されたＥＣＧＩを、ハンドオーバ又はＴＡＵ手続を介して取得する。サーバー２１９は、データ７８０をＵＥ２００に送信する（例えば、デバイス２１２への配信のために）と、ネットワーク２４０はＵＥの現在位置を登録されたセルと照合し、現在位置が登録されたセルのうち１つと一致することを見出す。ネットワーク２４０はこうしてＵＥ２００をページングしてアクティブな接続を確立し（図７には図示されない）、データ７９０をＵＥ２００に転送する。

本実施形態において記載された手順によって、ＵＥが処理不可能なサービスの配信のための不必要なＵＥのウェイク・アップが低減されるであろうことは、当業者には自明であるはずである。さらに、セルの初期登録を除き、ＵＥによる自己のステータスに関する何ら追加的な信号伝達を必要としないため、バッテリー電源をさらに節約する。それゆえに、本好適な実施形態により、本発明の目的は達成される。

上記の図解及び説明は、本発明が容易に理解できるように、概念的な態様でなされている。以下の好適な実施形態では、図７に記載された方法の特定の実装について、図８を活用して説明される。

図８では、ステータス検知手段が、プロセス・ブロック（ステータス検知）７１０に示されるようにＵＥ２００のステータスを検知する。肯定ステータスが検知される（例えば、ＵＥ２００がデバイス２１２又は２１４に接続される）と、ステータス通知手段は、現在のセルのＥＣＧＩをＡＳ層から取得する。ＥＣＧＩがネットワーク２４０に登録されていない場合には、ステータス通知手段はセルの登録をトリガする。この例では、ＵＥ２００は「ＰＤＮ接続要求」メッセージ８１２を送信する。「ＰＤＮ接続要求」メッセージ８１２は、登録されるべきセル・アイデンティティを搬送するプロトコル設定オプション（ＰＣＯ）を含む。既存の３ＧＰＰ機構では、ＵＥが新しいＰＤＮ接続を確立中であるときに「ＰＤＮ接続要求」メッセージが用いられる。

それゆえに、この例の場合、ＵＥはサービスに対するＰＤＮ接続（例えば、マシン・ツー・マシンＰＤＮ接続）を確立すると同時に、セルの登録も実施する。当業者であれば、異なる目的には異なるＰＤＮ接続が確立されるため、これは分別のあるアプローチであると理解するであろう。ＵＥが、サービスに対するＰＤＮ接続を、最初に処理可能となったときに確立するのは通常のことである。当業者ならばまた、他のメッセージを用いることができることも認識する。例えば、ＰＤＮ接続要求プロセスを完了した後ただちに、ＵＥは「ＰＤＮ接続完了」メッセージを送信する。

登録されるべきセル識別子は、このＰＤＮ接続と関連付けられるべき「ＰＤＮ接続完了」メッセージの中で送信される、トラフィック・フロー・テンプレート（ＴＦＴ）として挿入することができる。ＵＥが引き続いて登録されたセルを修正又は追加したい場合には、ＵＥは「ベアラ・リソース修正要求」メッセージを用いて、ＰＤＮ接続と関連付けられたトラフィック・フロー・テンプレートを更新することができる。

ＭＭＥ２４２が「ＰＤＮ接続要求」メッセージ８１２を受信すると、ＳＧＷ２４６経由でＰＤＮ ＧＷ２４８に対して「セッション作成要求／応答」手続８１４を開始する。「ＰＤＮ接続要求」メッセージ８１２に含まれるいずれのＰＣＯも、この「セッション作成要求／応答」手続８１４において、トランスペアレントにＰＤＮ ＧＷ２４８に渡される。ＰＤＮ ＧＷ２４８がセル登録用ＰＣＯを検出すると、ＰＤＮ ＧＷ２４８は、ＵＥがＰＤＮ接続に関連づけられたサービスと、指定されたセルを紐づけようとしていることを認識する。

それゆえにＰＤＮ ＧＷ２４８は、ＵＥ２００の位置更新が必要であることを、「セッション作成要求／応答」手続８１４の中でＭＭＥ２４２に伝えることができる。このことは、引き続いてＵＥの位置が変化するときにはいつでも、ＭＭＥ２４２は、「ＵＥ位置更新」メッセージ８１６及び８４２によって示されるように、例えば、ＭＭＥ２４２からＳＧＷ２４６に送信され、そしてＰＤＮ ＧＷ２４８に転送される「ベアラ要求修正」メッセージの一部として、ＰＤＮ ＧＷ２４８の情報を更新することを意味する。

ここで、サーバー２１９がデータ７２０をＵＥ２００に送信する（例えば、デバイス２１２への配信のために）と、ＰＤＮ ＧＷ２４８はＵＥの現在位置を登録されたセルと照合する。現在位置が登録されたセルのうち１つと一致する場合には、ＰＤＮ ＧＷ２４８は、パケット（データ）８２２をＳＧＷ２４６に転送する。ＵＥ２００に対するアクティブなベアラがない場合は、ＳＧＷ２４６はダウンリンク・データ通知８２４をＭＭＥ２４２に送信する。この通知は、ＭＭＥ２４２に対してアクティブなベアラを設定するよう要求する。ＭＭＥ２４２は、ＵＥへのページングへと進み、ＵＥ２００は、ＩＤＬＥ又は他の省電力モードからウェイク・アップし、サービス要求メッセージを送信する。これによってアクティブなベアラが確立されるものであり、ページング・プロセス８２６として図８に示す（図にはベアラの起動は示されない）。データ・パケット（データ）７３０は、ＵＥ２００に送信される。

しばらく時間が経過した後に、プロセス・ブロック（ＵＥの移動）７４０によって示されるように、ＵＥ２００が移動したと想定する。ＭＭＥ２４２が、係る移動を検知すると、ＭＭＥ２４２はメッセージ８４２により、ＵＥの現在位置でＰＤＮ ＧＷ２４８を更新する。ＵＥ２００が移動したことをＭＭＥ８４２が知る方法は、様々な手段を介しうる。例えばＵＥ２００は、トラッキング・エリア更新メッセージを送信してもよい。この場合は、ＵＥ２００が、ＰＤＮ ＧＷで登録していないセルに移動し、トラッキング・エリアは変化しなかったがセルのみが変化したにもかかわらずトラッキング・エリア更新メッセージを送信し、当該トラッキング・エリア更新メッセージにｅＮＢがＥＣＧＩなど自己のセルＩＤを追加するものとする。

ＰＤＮ ＧＷ２４８は次いで、ＭＭＥを介してＵＥの位置情報としてＥＣＧＩを受信し、通知されたセルＩＤがＵＥの登録済セルのいずれとも一致しないので、ＵＥがサービスを現在処理可能でないことを知る。したがって、サーバー２１９がデータ・パケット（データ）７５０（例えば、デバイス２１２への配信のためのデータ）を送信すると、ＰＤＮ ＧＷ２４８はプロセス・ブロック（廃棄）７６０によって示されるようにパケットを廃棄する。

サービスが可能な位置における位置情報としてのＥＣＧＩ（又はＥＣＧＩリスト）は、ユーザ加入許可（サブスクリプション）又はサービス規則（ルール）中に登録されてもよい。このような場合には、ＰＤＮ ＧＷ２４８は、ＨＳＳに登録されたユーザ加入許可から、又はＰＣＲＦによって提供されるＱｏＳ／課金ポリシー／規則から位置情報を取得し、当該位置情報をデフォルト規則又は最も厳格な（優先度の高い）規則としてＴＦＴに設定する。ＰＤＮ ＧＷ２４８は、位置情報と関連付けられた他の情報、例えば、当該位置にて可能なサービスのＩＤ、位置情報とともに設定されるパケット・フィルタなどを取得してもよい。係る情報は、ＰＣＲＦへのＰＤＮ内にあるサービス・サーバー、オンライン／オフライン課金サーバー又はＨＳＳによって提供されてもよい。

本実施形態において記載された手順によって、ＵＥが処理不可能なサービスの配信のための不必要なＵＥのウェイク・アップが低減されるであろうことは、当業者には自明であるはずである。それゆえに、本好適な実施形態により、本発明の目的は達成される。

＜複数組の装置＞
上記の好適な実施形態は、一組のデバイスとサーバー（すなわち、位置２０１におけるデバイス２１２／２１４及びサーバー２１９）の間の通信を許可するＵＥについて記載された。ＵＥが、異なる位置にある異なる組の装置に伴う通信を許可することが可能である。サービスを有効にするべき位置を登録するトラフィック・フロー・テンプレートの使用は、異なる組の装置が異なる位置に存在する場合を満足させるよう役に立っている。これは、複数のトラフィック・フロー・テンプレートは、単一のＰＤＮ接続と関連付けることが可能だからである。それゆえに、ＵＥは異なる組の装置に対する、異なるトラフィック・フロー・テンプレートを用いることができる。

例として、位置Ｌ１において、ＵＥがデバイスＤ１Ａ及びＤ１Ｂと、サーバーＳ１の間の通信を有効にし、位置Ｌ２において、ＵＥがデバイスＤ２Ａ、Ｄ２Ｂ及びＤ２Ｃと、サーバーＳ２の間の通信を有効にすると考える。ＵＥは次いで、二組のトラフィック・フロー・テンプレートをインストールする。第１のトラフィック・フロー・テンプレートは、サーバーＳ１と、デバイスＤ１Ａ、Ｄ１Ｂの間の、ソース及び宛先ＩＰアドレスといったＩＰセッションの記述を含む。当該テンプレートは一致されるべき新しい位置フィールド、位置Ｌ１も含む。

第２のトラフィック・フロー・テンプレートは、サーバーＳ２と、デバイスＤ２Ａ、Ｄ２Ｂ、Ｄ２Ｃの間の、ソース及び宛先ＩＰアドレスといったＩＰセッションの記述も含む。当該テンプレートは一致されるべき新しい位置フィールド、位置Ｌ２も含む。このように、ＵＥが位置Ｌ１にある場合は、トラフィック・フロー・テンプレート・パラメータ［ソースＩＰ＝Ｓ１；位置＝Ｌ１］が完全に一致するので、サーバーＳ１からのパケットの通過が許可される。しかしながら、パラメータ［ソースＩＰ＝Ｓ２；位置＝Ｌ１］がいずれのインストールされたトラフィック・フロー・テンプレートとも一致しないので、サーバーＳ２からのパケットはＰＤＮ ＧＷによってブロックされる。同様に、ＵＥが位置Ｌ２にある場合には、トラフィック・フロー・テンプレート・パラメータ［ソースＩＰ＝Ｓ２；位置＝Ｌ２］が完全に一致するので、サーバーＳ２からのパケットの通過が許可される。しかしながら、パラメータ［ソースＩＰ＝Ｓ１；位置＝Ｌ２］はいずれのインストールされたトラフィック・フロー・テンプレートとも一致しないので、サーバーＳ１からのパケットはＰＤＮ ＧＷによってブロックされる。

ＵＥが当該位置をネットワークに登録する（すなわち、図７及び８に記載された）場合は、ＵＥの位置と、特定のサービスと関連付けられたデータを処理するＵＥの能力との間に直接的な相関関係があることを、ＵＥは示唆する。多くのアプリケーションでは、固定されたローカル・デバイスと遠隔サーバーの間のマシン・タイプ通信路を仲介するＵＥなど、係る相関が存在する。基地局セルの受信可能エリアが小さい場合に、とりわけこのことがあてはまる。

例えば、住居に設置されるべき（または、時にはホームｅＮｏｄｅＢとしても知られる）フェムトセル基地局は、典型的には、半径２０〜３０メートル、典型的な住居をカバーするにはちょうど十分な受信可能エリアのみを有する。しかしながら、セルの受信可能エリアが大きい場合は、係る相関はより小さい。ＵＥは固定されたローカル・デバイスから遠くに離れて移動したかもしれず、その結果、ＵＥはもはや当該デバイスと通信できないが、それでも、同一セルの受信可能エリア内にある。係る状況において、ＰＤＮ ＧＷはＵＥが登録されたセル内にあることがわかり、及び、該サービスの疎通を許可する。

このことを解消する一方法は、ＵＥがコネクティッド・モードに入り、サービスがフィルタリング除去されるようトラフィック・フロー・テンプレートを修正することである。ＵＥが再びサービスと関連付けられたデータを処理可能になると、ＵＥは元のトラフィック・フロー・テンプレートに戻す。

このことを解消する別の方法は、マシン・タイプ通信毎に別々のＰＤＮ接続を設けることである。ＵＥは、マシン・タイプ通信に対するサービスと関連付けられたデータを処理可能でない場合に、マシン・タイプ通信に対するＰＤＮ接続を終了させ、処理可能な場合にはＰＤＮ接続を確立する。

さらに別の方法は、ＵＥがたとえ同じセルにあっても、すなわち、ハンドオーバ又はＴＡＵが通常は必要とされない場合であっても、ＵＥが異なる位置にあるとネットワークに判断させるトラッキング・エリア更新（ＴＡＵ）メッセージを、ＵＥが送信することであり、その結果、サービスデータ・パケットはトラフィック・フロー・テンプレート中の位置フィールドと一致しないものとなる（したがって、配信されない）。これは、ＵＥがＴＡＵメッセージ中に「ソルト（ｓａｌｔ、見せかけの）」フラグを付加することによって行うことができ、その結果ＭＭＥは、ＵＥが異なる位置を示そうとしていることを認識し、それゆえに、わずかに異なる位置（例えば、時に「ソルティング（見せかけ）」として知られる、追加ビットが挿入された現在のセルのＥＣＧＩ）でＰＤＮＧＷを更新する。

しかしながら、このことは、ＭＭＥ機能に対する修正を必要とする。他の可能性は、ＵＥがｅＮｏｄｅＢに対して報告されたＥＣＧＩを「ソルト」するよう依頼することである。３ＧＰＰで定義された手順では、実際の位置（すなわち、現在のセルのＥＣＧＩ）は、ＵＥではなく、ｅＮｏｄｅＢによって、ＴＡＵメッセージ、ＴＡＵメッセージをＭＭＥへと搬送するメッセージ、又は、ＵＥに固有のあらゆるシグナリング・メッセージに対して挿入される。それゆえに、ＵＥはＴＡＵメッセージ内に特別な無線層フラグを付加することができ、その結果ｅＮｏｄｅＢは、ＴＡＵメッセージ、又は、ＴＡＵメッセージを搬送するメッセージに元のＥＣＧＩの代わりに「ソルトされた」ＥＣＧＩを挿入することができるようになる。ＭＭＥはこのようにして、ＵＥの位置としてＥＣＧＩ及び「ソルト」された値をＰＤＮ ＧＷに報告し、それらはトラフィック・フロー・テンプレート中の位置フィールドとは一致しないものとなる。

位置情報は、ＥＣＧＩ又はＴＡＩのようなセル関連情報だけでなく、ＰＬＭＮ ＩＤ等アクセス・ネットワーク識別子など、ネットワーク関連情報であってもよいことは、当業者には自明であるはずである。それゆえに、サービスは広範に展開され、ユーザ利益が増加する。

[第３の実施の形態]
＜代替例：サービス／ベアラに基づいたページング最適化＞
所定の場合には、ＵＥ２００の受信可能エリアは、例えば、加入者契約（サブスクリプション）、事前登録されたエリア、履歴データ、ユーザ入力などによって事前に判定することができる。例えば、ＵＥがサービスをある特定の位置で提供する場合、ＵＥはセル情報及びＧＰＳなどを用いて一種のフィンガープリントを生成することができる。

このような場合、ＵＥ２００は、ＩＤＬＥ又は他の節電モードにあるときには、ＵＥ２００を不必要にページングすることを回避するための情報を活用するように、ネットワークを設定することができる。この目的のために、ＵＥ２００はＵＥによって要求されるベアラ・リソース修正手続を活用して、ネットワークを設定することができる。図９はそうしたオペレーションにおける信号伝達シーケンスの例を図解するものである。

例えば、「接続（アタッチ）手続」又は「ＵＥ要求ＰＤＮ接続確立」など、対応するＰＤＮ接続確立の後、ＵＥ２００は「ベアラ・リソース修正要求」９１２をＭＭＥ２４２に向けて送信する。「ベアラ・リソース修正要求」９１２メッセージは、サービス受信可能エリア情報、例えば、ＥＣＧＩリスト又はＴＡＩリストの形態でサービスが利用可能である位置リスト、ＡＰＮ又はＴＦＴのいずれかによるサービス記載などを含む。

「ベアラ・リソース修正要求」９１２を受信した後に、ＭＭＥはサービス受信可能エリア情報を保存し、ベアラ・リソース・コマンド９１４を、ＳＧＷ２４６を介してＰＤＮ ＧＷ２４８に送信する。ベアラ・リソース・コマンド９１４には、サービス記述が含まれる。

ＰＤＮ ＧＷ２４８は、ベアラ管理手続９１６を開始して、当該サービスに対応するベアラを作成又は修正する。ＰＤＮ ＧＷ２４８は、ベアラ・リソース・コマンド９１４中の情報及び埋め込まれたサービス記述を活用して、新しいベアラが作成されるべきか又は古いベアラが修正されるべきかを決定する。サービスに対応するダウンリンク・データが受信された場合は、ＰＤＮ ＧＷ２４８によってＳＧＷ２４６に転送される。ＵＥ２００に対してアクティブなベアラが存在しない場合、例えば、ＵＥがＩＤＬＥモードにある場合、ダウンリンク・データ通知９２４は、対応するベアラＩＤとともにＭＭＥ２４２に送られる。

複数のベアラからＳＧＷ２４６に到達したデータがある場合には、ダウンリンク・データ通知９２４は、すべてのベアラＩＤのリストを搬送してもよい。代替的には、異なるベアラからのデータが到着するたびに、ＳＧＷ２４６は複数のダウンリンク・データ通知９２４をＭＭＥ２４２へと送信することができる。ＭＭＥ２４２がダウンリンク・データ通知を制限することを好む場合は、ＭＭＥ２４２は、例えばＱＣＩ、ＡＲＰ等の優先度情報の付いた遅延ダウンリンク・パケット通知要求を送信することができる。指示されたものよりも高い優先度を有するベアラでデータを受信した場合にのみ、ＳＧＷ２４６は、新規のダウンリンク・パケット通知をＭＭＥ２４２へと送信する。

ＭＭＥ２４２は、９１２中に受信したベアラと関連付けられたサービス受信可能エリア情報を検索し、サービス受信可能エリア情報によって許可されるセルへのページングを発行する。ＭＭＥ２４２は代替的には、例えば、位置リスト、ＡＲＰ、ＱＣＩ等のサービス受信可能エリア（カバレッジ）情報又は所定の優先順位情報を搬送するページング・メッセージを発行することができ、サービス受信可能エリア情報に掲載されているセル又は優先順位を満たすセルに対してページング・メッセージを発信する。例えばこのようなページング・メッセージを受信した後のｅＮＢ又はＲＮＣは、セルの輻輳、セルの位置、ローカルなポリシー等、ローカルなステータスに基づいて、ページング・メッセージが送信されるべきか否かを決定する。

ＵＥ２００がサービス受信可能エリア／優先順位情報によって許可されたセルのうち１つにとどまっている場合、ＵＥ２００はページング・メッセージ９２６を受信して、ベアラを起動するべくサービス要求手続９２８を開始する。データ９３０は、ＳＧＷ２４６によってＵＥ２００に転送される。９４０のように、ＵＥ２００がページングを受信する前に、サービス受信可能エリア情報にないセルに移動した場合には、ページングが失敗する。所定の時間の後に、ＭＭＥ２４２はダウンリンク・データ通知拒絶９５８をＳＧＷ２４６に送信する。これによって、ＳＧＷ２４６がこのベアラに対するバッファリングされたパケットを廃棄する。

サービス受信可能エリア情報が、例えば、サービス関連ポリシー、ポリシー制御及び課金フレームワークを介したアプリケーション層など他の手段を介して、ＰＤＮ ＧＷ２４８に対して利用可能である場合、ＰＤＮ ＧＷ２４８は、ＰＤＮ ＧＷ２４８始動（イニシエーティッド）ベアラ管理を実行し、係る情報でＭＭＥ２４２を設定することができることは、いずれの当業者にも明らかである。例えば、ＰＤＮ ＧＷ２４８は、ＵＥ２００によって与えられるトリガを必要とせずにベアラ管理手続９１６を実行することができる。

サービス受信可能エリア情報は、時間的制約要素をさらに含むか、又は時間的制約要素によって置き換えられてもよいことは、いずれの当業者にも明らかである。例えばＵＥ２００は、加入者契約（サブスクリプション）、ユーザ嗜好（プリファレンス）／設定、又は発見的アルゴリズムに基づいて、特定のサービスが許可又はブロックされるべき期間を決定することができる。この期間情報は、サービス受信可能エリア情報中に追加的要素として含まれてもよく、以前に述べた方法を用いて、ＭＭＥ又はＰＤＮ ＧＷなどにシグナリングが送られてもよい。ＭＭＥ又はＰＤＮ ＧＷなど、ネットワーク・ノードは、サービスフローがＵＥに転送されるべきであるか否かを決定する際に、期間情報ならびに他のサービス受信可能エリア情報を活用する。所定の状況において、サービス受信可能エリア情報は時間関連情報のみを含んでもよい、例えば、サービスに対する他の制約はない。

ＵＥ２００が、サービスのライフタイム期間中はいつでも、９１２から９１６中に示す信号伝達を実行することによって、サービス受信可能エリア情報の更新を実行できることもまた、いずれの当業者にも自明である。

＜ステータス信号伝達のためのＲＲＣの使用＞
上述の各実施形態では、サービス・サポート・ステータスの信号伝達がＮＡＳ層内で実行される。別の代替例では、係る機能がアクセス・ネットワークによってサポートされている場合には、同じ目標が、無線リソース制御層を用いる信号伝達によって達成されうる。例えばＵＥは、ＵＥからアクセス・ネットワーク、例えばｅＮｏｄｅＢに時折送信される報告測定（メジャメント・レポート）メッセージ中に、ステータスを通知することができる。このことは、ｅＮｏｄｅＢが一定のベアラ修正、例えば、ＭＭＥに対し、特定のサービスに対するデータ・パケットがブロックされるべきであることを指示する特別なベアラ解放要求を開始することをトリガできる。ＭＭＥは、ＳＧＷ及びＰＤＮ ＧＷにシグナリングを送って、サービスに関連したパケットを落とすことができる。これは、ＵＥがコネクティッド・モードにあるが間欠受信（ＤＲＸ）を使用している場合に有用である。

[第４の実施の形態]
所定のサービスの場合、サービス・エリア又はその位置は、サービス供給業者又は顧客によって、厳格に限定されてもよい。例えば、企業サービスは企業の建造物又は敷地の内部など、特定場所の内部においてのみ提供されてもよい。このような場合には、ネットワーク事業者又はサービス供給業者は、ＵＥが受信契約（サブスクライブ）されたサービスの受信可能範囲の外にある場合には、ＵＥにサービスを提供することを中止してもよい。さらに、ＵＥは、企業エリアの範囲外のいずれのセルに接続することも許可されないかもしれないが、しかしながら会社は、管理のためにＵＥの移動を追跡したいこともありうる。

別の例示的な場合には、ＵＥ２００は、自動販売機に埋め込まれた通信装置などの装置についての課金関連データを収集するという、限定された目的を備えた通信装置であってもよい。ここでは、事業者は別の装置内にあるＵＳＩＭの利用を禁止するであろう。例えば、ＵＳＩＭを正常なＵＥに挿入すること、及び、事業者のネットワークへの接続を実行することが禁止される。事業者ネットワークは、接続を拒否するか又は限定されたリソースのみを割り当てて、ＵＥのユーザ・データ通信を回避するがＵＥの移動を追跡できるようにする。

さらに、ＵＥ２００又はＵＥ２００が埋め込まれた装置は、事前に定められた位置に配置されており、ＵＥが所定の期間、又は永遠に当該位置から離れる（移動する）ことは許可も期待もされないかもしれない。例えば、自動販売機は固定位置にのみ置かれ、移動させることはできない。監視カメラなどいくつかの検知装置もまた、固定された場所、例えば壁などに括りつけられている。別の事例は、ショッピング・モールにある高解像度テレビであるかもしれない。当該テレビは、各店の広告及び他の価値のある情報を顧客に提供しており、これも所定の期間壁に固定されている。

このような場合は、ＵＥ２００が移動し、及び／又は事前に定められた場所の外にある別のエリア（例えば、セル、トラッキング・エリアなど）からネットワークに接続する場合は、ＵＳＩＭの盗難として、又はＵＳＩＭの撤去及び別のＵＥ又は埋め込み装置内での使用として検知することができる。システムが、移動を許可又は期待されていないＵＥ２００の移動を検知した場合は、システムの事業者は、ＵＥ２００を追跡した後に窃盗犯を捕えるために、限定されたリソースを伴う接続を切断したいかもしれないし、又は保持したいかもしれない。

[非特許文献２]では、２種類のハンドオーバ手続、Ｓ１ベースのハンドオーバ及びＸ２ベースのハンドオーバがある。

[非特許文献３]にも記載されているように、上述の実施の形態のＳ１ベースのハンドオーバの場合において、ＵＥ２００はすでに、自己の登録されたセルについての情報をネットワーク、すなわちＭＭＥ又はＰＧＷにすでに提供しており（ＰＧＷの場合であっても、ＭＭＥにはＴＦＴが提供され、ＵＥのＭＭコンテキスト中に保存されるので、ＭＭＥがＵＥのために登録されたセルについて知っていることは、明らかである）、ＭＭＥは、登録されたセルの範囲内から任意の未登録セルへのＵＥ２００の移動を検知する。ＭＭＥは、ＨＳＳ（ホーム加入者サーバー）又はＡＡＡ（認証、許可及びアカウンティング）サーバーなどシステムデータベースから提供されるユーザ加入許可に含まれる制限情報に基づいて、ＵＥ２００の接続又はハンドオーバを許可されていない制限されたセルへの移動のみを検知してもよい。

したがってこの場合には、ＭＭＥは特定の方策を実行して、許可されないリソース消費を回避してもよい。その一例は、ＭＭＥがハンドオーバ手続中にソースｅＮＢからのハンドオーバ要求メッセージを拒絶（又は無視）し、拒絶後にＵＥ２００の接続を単に切断（又は解除）することである。別の例は、ＭＭＥがハンドオーバ要求メッセージを受け取って、ハンドオーバ手続を正常に完了させるが、ＭＭＥは、例えば、窃盗犯のユーザ・データ活動を回避するために、ターゲットｅＮＢ又は他のネットワーク・ノード（例えば、ＳＧＷ、ＰＧＷなど）をトリガして、すべてのアップリンク・データをブロックしてもよい。別の例ではＭＭＥは、ＱｏＳ、ベアラ情報などを含むＵＥコンテキストなどリソースのパラメータを修正（又は新たに設定）して、ターゲット・セル（すなわち、ターゲットｅＮＢ）における当該ＵＥ２００に対するリソースを限定するか、又は割り当てなくてもよい。この場合にはＭＭＥはハンドオーバ手続中に、修正（又は新たに設定）されたパラメータを含むハンドオーバ要求メッセージをターゲットｅＮＢに送信してもよい。ＭＭＥは例えば、デフォルト・ベアラの確立のみをトリガして、いかなる専用（ｄｅｄｉｃａｔｅｄ）ベアラの確立を省略してもよい。

Ｓ１ベースのハンドオーバの場合と同様、ＵＥ２００がＩＤＬＥモードにあり、ある登録されたセルから任意の未登録セルへと移動する場合は、前の実施の形態に記載されたように、ＵＥ２００はトラッキング・エリア更新手続を実行して、自己の新しい位置、すなわち、ＵＥ２００が一時的にとどまっている新しいセルをＭＭＥに通知するので、ＭＭＥは、登録されたセルの範囲内から未登録セルへのＵＥ２００の移動を検知する。こうしてＭＭＥは、ＵＥ２００からのトラッキング・エリア更新要求を拒絶（拒否）するか、又はＵＥ２００の接続を単に切断することができる。ＭＭＥは、ＵＥ２００からのトラッキング・エリア更新要求の拒絶後又は拒絶中に、後にＵＥ２００からサービス要求メッセージ又は接続要求メッセージを受信する際に限定されたリソースをＵＥ２００に割り当てるよう、ターゲットｅＮＢに対して要求してもよい。

しかしながら、非特許文献４にも記載されているように、Ｘ２ベースのハンドオーバの場合には、ＵＥがターゲットｅＮＢに接続される前は、ＭＭＥはターゲットｅＮＢにおけるＵＥ２００に対するリソースを防止又は限定することはできない。その理由は、ＭＭＥは、ＵＥのハンドオーバ後、ターゲットｅＮＢが経路切換要求をＭＭＥに送信した時に初めて、ＵＥの移動を検知するからである。こうして窃盗犯の手に渡ったＵＥ２００は、ターゲット・セルに正常にハンドオーバして、アップリンク及びダウンリンク・データに対する接続を利用したりするかもしれない。

Ｘ２ベースのハンドオーバが適用される場合であっても、窃盗犯によるこのような不正使用を回避するか、又はサービス・エリア、すなわち、登録されたセルの外にあるＵＥ２００に提供されるサービスを限定するために、ＭＭＥはＵＥ２００について、登録されたセルの情報、又は制限されたセルの識別子（例えば、ＥＣＧＩ）など制限情報を、現在の、すなわち許可されたｅＮＢに提供する。制限情報は例えば、制限されたＰＬＭＮ ＩＤ、制限されたトラッキング・エリアＩＤなどの追加情報を含んでもよい。ホワイト・セル・リスト（すなわち、登録されたセルなど許可されたセルのリスト）又はブラック・セル・リスト（すなわち、未登録セル若しくは登録されたセル以外のセルなど、制限されたセルのリスト）は、ＭＭＥからｅＮＢに送信される非特許文献３に定義されるハンドオーバ制限リストの一部であってもよい。ホワイト・セル・リスト、ブラック・セル・リスト又はハンドオーバ制限リストに基づくこのような制限は、ＵＥ２００の位置に基づき、ＵＥ、ＥＰＳベアラ、ＰＤＰコンテキスト、無線ベアラ（ＲＢ）ごとに適用されてもよい。

ソースｅＮＢは、ハンドオーバを回避するか又はハンドオーバ中に割り当てられたリソースを限定するめに、ＵＥ２００に対するホワイト・セル・リスト又はブラック・セル・リストを提供された情報に基づいて、例えば、登録セルＩＤでホワイト・セル・リストを、または未登録セルＩＤ又は制限されたセルＩＤでブラック・セル・リストを構成する。ＵＥ２００が、登録されたセルの中から任意の未登録セル又は任意の制限されたセル、すなわち、ホワイト・セル・リスト中以外のセル又はブラック・セル・リスト中のセルに移動しようと試みていることを、ソースｅＮＢが（例えば、ＵＥによって送信された測定報告に基づいて）検知すると、ソースｅＮＢは、拒絶し（すなわちハンドオーバをトリガしない）、任意でＭＭＥに報告するか、又はソースｅＮＢは、ターゲット・セルへのハンドオーバ要求メッセージ中に、限定又は低減されたリソース（リソースのパラメータを含む）のみを要求する。

ＭＭＥは、ベアラ（例えば、ＥＰＳベアラ、ＰＤＰコンテキスト、ＲＢ）又はＰＤＮ接続単位でサービスを管理してもよい。ＭＭＥがハンドオーバに関与する場合には、ＭＭＥは、ベアラ又はＰＤＮ接続ごとに当該ターゲット・セルにおけるリソースの限定又は低減（削減）を要求するか、ベアラ又はＰＤＮ接続ごとにハンドオーバを拒絶するか、ベアラ又はＰＤＮ接続ごとにハンドオーバ決定を無視するか、又はベアラ又はＰＤＮ接続の解除を実行するかのいずれかを行ってもよい。ＭＭＥがホワイト・セル・リスト及び／又はブラック・セル・リストをソースｅＮＢに提供する場合には、ホワイト・セル・リスト及び／又はブラック・セル・リストは、ＵＥ２００の位置に応じて、上記に記載された措置に対するターゲットＥＰＳベアラ（単数又は複数）、ＰＤＰコンテキスト（単数又は複数）又はＲＢ（単数又は複数）を含んでもよい。

それぞれのエリアにおいてＳ１ベース又はＸ２ベースのハンドオーバのいずれかが適用されるか、又はソース及びターゲットｅＮＢのいずれの組み合わせが適用されるかを、ＭＭＥ又はｅＮＢ（単数又は複数）が（例えば構成などによって）すでにわかっていることは、いずれの当業者にも明らかである。このような場合にはＭＭＥは、Ｘ２ベースのハンドオーバがＭＭＥの受信可能範囲のもとでアクセス・ネットワークに適用される場合にのみ、制限情報、ＵＥ２００に対する登録／未登録セルの情報、ホワイト・セル・リスト及び／又はブラック・セル・リストをｅＮＢ（単数又は複数）に提供する。係る情報は、Ｘ２ベースのハンドオーバが正常に完了した場合は、経路切換要求受信確認メッセージを、又はＳ１ベースのハンドオーバが実行される場合にはハンドオーバ要求メッセージを、又はＵＥ２００が初期接続したり、ＩＤＬＥモードからコネクティッド・モードに遷移する場合には初期コンテキスト設定要求メッセージを、又は新しいＰＤＮ接続又は新しい専用ベアラが確立される場合にはベアラ設定要求メッセージを用いて、ＭＭＥからｅＮＢへと搬送されてもよい。ｅＮＢが、あるＵＥに対して保存された制限情報を全く持たないか又は期限切れの制限情報しか持たない場合、ｅＮＢは、ソースｅＮＢとのＸ２インタフェースをサポートするターゲットｅＮＢへのＵＥ２００のハンドオーバが実行される前に制限情報を提供するよう、ＭＭＥに要求してもよい。

＜ｅＮＢ装置＞
図１０は、無線ブロック１０１０、アクセス階層（ＡＳ）ブロック１０２０、転送手段１０３０、ＧＰＲＳトンネリング・プロトコル（ＧＴＰ）ブロック１０４０、ＵＤＰブロック１０５０、Ｓ１−ＡＰブロック１０６０、Ｘ２−ＡＰブロック１０７０、ＳＣＴＰブロック１０８０、ＩＰプロトコル・ブロック１０９０、バックボーンＬ２／Ｌ１ブロック１１００、ハンドオーバ制御手段１１１０、制限情報処理手段１２００から成る、あるｅＮＢの好適な機能アーキテクチャ１０００を示す。

無線１０１０は、ｅＮＢがＵＥ（単数又は複数）と通信するのを可能にするのに必要なハードウェア及びファームウェアから成る機能ブロックである。当該ブロックは、アンテナ、送信側回路及び受信側回路を備えてもよい。いずれの当業者にとっても、このことはシステムが有線環境に用いられることを除外しないこと、すなわち、無線１１０機能は、ＡＳ１０２０とのインタフェースが損傷を受けていないままである限り、有線伝送手段によって置き換え可能であることは、明らかである。無線１０１０が実際は、無許可移動体アクセス（ＵＭＡ）又は一般的アクセス・ネットワーク（ＧＡＮ）の応用など、異なる通信スタック上で動作させることも可能である。

アクセス階層（ＡＳ）１０２０は、無線アクセス制御及びセルラー無線ネットワークへの信号伝達、及び無線１０１０アクセス上の情報の伝送を実装する機能ブロックである。

バックボーンＬ２／Ｌ１ １１００は、ｅＮＢがＭＭＥ（単数又は複数）、サービング・ゲートウェイ（単数又は複数）及び／又は他のｅＮＢ（単数又は複数）と通信するのを可能にするのに必要なハードウェア及びファームウェアから成る機能ブロックである。当該ブロックは送信側回路及び受信側回路を備えてもよい。いずれの当業者にとっても、このことはシステムが無線環境に用いられることを除外しない、すなわち、バックボーンＬ２／Ｌ１ １１００機能は、ＩＰ１０９０とのインタフェースが損傷を受けていないままである限り、無線伝送手段によって置き換え可能であることは、明らかである。

ＩＰプロトコル１０９０は、ｅＮＢがアクセス・ネットワーク又はコア・ネットワーク内の他のノードと通信するために、インターネット・プロトコルを実装するソフトウェアから成る機能ブロックである。

ＧＴＰ１０４０は、ｅＮＢが、ＧＴＰプロトコルを終了するコア・ネットワーク内の他のノード、すなわち、サービング・ゲートウェイ、ＰＤＮ ゲートウェイと通信するために、及び、ＵＥのデータをコア・ネットワーク・ノード（単数又は複数）に／から送／受信するために、ＧＴＰプロトコルを実装するソフトウェアから成る機能ブロックである。

ＵＤＰ１０５０は、ｅＮＢがＧＴＰプロトコル・メッセージをコア・ネットワーク・ノード（単数又は複数）に／から搬送するために、ＵＤＰプロトコルを実装するソフトウェアから成る機能ブロックである。

Ｓ１−ＡＰ１０６０は、ｅＮＢがコア・ネットワーク内のＭＭＥと通信して、その結果、ｅＮＢがＭＭＥによって制御され、ＵＥ（単数又は複数）に対する信号伝達メッセージがＳ１−ＡＰプロトコル上を搬送されるように、Ｓ１−ＡＰプロトコルを実装するソフトウェアから成る機能ブロックである。

Ｘ２−ＡＰ１０７０は、ｅＮＢがアクセス・ネットワーク内の他のｅＮＢ（単数又は複数）と通信して、その結果、ｅＮＢが当該他のｅＮＢとともにＵＥのハンドオーバを制御し、ＵＥの転送データがＸ２−ＡＰプロトコル上を搬送されるように、Ｘ２−ＡＰプロトコルを実装するソフトウェアから成る機能ブロックである。

ＳＣＴＰ１０８０は、ｅＮＢが、Ｓ１−ＡＰメッセージをＭＭＥに／から、又はＸ２−ＡＰメッセージを他のｅＮＢ（単数又は複数）に／から、送／受信するために、ＳＣＴＰプロトコルを実装するソフトウェアから成る機能ブロックである。

転送手段１０３０は、無線１０１０とバックボーンＬ２／Ｌ１ １１００のインタフェース間に、ＵＥのユーザ・データ及び信号伝達メッセージのための転送機構を実装するソフトウェアから成る機能ブロックである。ＵＥのユーザ・データに対しては、転送手段１０３０はＡＳ１０２０プロトコルとＧＴＰ１０４０プロトコルの間の橋渡しをする役割を果たし、一方、ＵＥの信号伝達メッセージに対しては、ＡＳ１０２０プロトコルとＳ１−ＡＰ１０６０プロトコルの間の橋渡しをする。

ハンドオーバ制御手段１１１０は、ＵＥ（単数又は複数）に対するハンドオーバ制御機構を実装するソフトウェアから成る機能ブロックである。

本発明は、制限情報を利用したハンドオーバのために、制限情報処理手段１２００及びハンドオーバ制御手段１１１０を導入する。制限情報処理手段１２００は、ＭＭＥからＵＥに対して提供される制限情報を取得し、当該ＵＥに対するハンドオーバ決定又はハンドオーバ実行の際に当該制限情報を利用する。

＜ｅＮＢのフローチャート＞
ｅＮＢに関する上記の構成による、本実施形態におけるｅＮＢに対して開示された方法が図１１に示される。

まず第１に、ＭＭＥは制限情報をｅＮＢ（ソースｅＮＢ）に提供し（Ｓ１１０１）、当該制限情報は、上述の情報、すなわち、ブラック・セル・リスト、ホワイト・セル・リスト、未登録セルＩＤ、登録セルＩＤ、制限されたＰＬＭＮ ＩＤ、制限されたトラッキング・エリアＩＤ、制限されたセルＩＤなどを含む。ソースｅＮＢ１１０１内にある制限情報処理手段１２００は、すなわち、セル、トラッキング・エリア、ＰＬＭＮなどエリアの情報を含むハンドオーバ制限リストを構成して、ＵＥの接続又はハンドオーバを制限する。ＭＭＥ２４２からのこのような提供は、ＵＥのｅＮＢとの接続時に、又はｅＮＢが要求するとき、すなわち、ｅＮＢがＭＭＥ２４２に対し当該ＵＥ２００の制限情報を提供するよう要求する任意のときに行われてもよい。またこの提供は、ｅＮＢがハンドオーバのためのＸ２インタフェースをサポートするときにのみ実行されてもよい。

ＵＥ２００が測定報告を提供すると（Ｓ１１０２）、ソースｅＮＢ内にあるハンドオーバ制御手段１１１０は、当該ＵＥ２００に対するハンドオーバが必要であるか否かを測定報告及びポリシーに基づいて、ハンドオーバが制限されていないかどうか、すなわち、制限情報中のセルＩＤがターゲット・セルを包含するか否かを、提供された制限情報基づいて決定する（Ｓ１１０３）。決定後に何の制限も見られない場合は、ハンドオーバ制御手段１１１０はハンドオーバ手続を通常通り進める、すなわち、ハンドオーバ要求をターゲットｅＮＢ１１０２に単に送信する。ソースｅＮＢ１１０１は、登録されたセル、又は制限情報がハンドオーバ決定段階において利用可能ならば、制限情報中で制限されていないセルのうち１つからターゲットｅＮＢ１１０２を選択してもよい。この意味において、ターゲット・セルの候補として制限されたセルのみがある場合は、ソースｅＮＢ１１０１内にあるハンドオーバ制御手段１１１０は、実際のハンドオーバ手続を開始してはならない、すなわち、ＵＥからの測定報告を無視する。

ハンドオーバに対して何らかの制限が発見されると、ハンドオーバ制御手段１１１０は決定を無視する、すなわち、ＵＥ２００からの測定報告を無視してハンドオーバ要求を送信しないか、又は当該ＵＥ２００に対するリソースを限定／低減する要求を含むハンドオーバ要求をターゲットｅＮＢ１１０２に送信する（Ｓ１１０４）。ソースｅＮＢ１１０１からのハンドオーバ要求メッセージを受信する、ターゲットｅＮＢ１１０２内にあるハンドオーバ制御手段１１１０は、ハンドオーバに対してアドミッション制御を実行し、当該ＵＥ２００に対するリソース限定又は低減を決定する（Ｓ１１０５）。

ソースｅＮＢ１１０１は、ターゲットｅＮＢ１１０２に対し、ハンドオーバ要求メッセージ内に入れて搬送されたＱｏＳパラメータ又はポリシー／規則内の、すでに限定済又は低減済のリソースを要求してもよい。この場合には、ターゲットｅＮＢ１１０２は、ＱｏＳパラメータ又はポリシー／規則を、当該ＵＥ２００に対する自己のリソース準備に単に適用する。

ソースｅＮＢ１１０１はまた、ＵＥ２００がターゲットｅＮＢ１１０２へのハンドオーバを許可されていないが、トラッキング目的のため少なくとも信号伝達プレーンが保持される必要があることを、フラグなどを用いてターゲットｅＮＢ１１０２に単に指示してもよい。この場合ターゲットｅＮＢ１１０２は、ＵＥ２００のユーザ・データ、すなわち、ユーザ・プレーンに対するＱｏＳパラメータが例えば０ｋｂｐｓに限定されることを決定する。

アドミッション制御及び他の処理の後に、ターゲットｅＮＢ１１０２内にあるハンドオーバ制御手段１１１０は、ハンドオーバ要求受信確認メッセージをソースｅＮＢ１１０１に返す（Ｓ１１０６）。ターゲットｅＮＢ１１０２の状態を理由に要求自体が許可されない場合は、ターゲットｅＮＢ１１０２はハンドオーバ要求を拒絶してもよく、又はリソースの限定／低減を理由にＵＥ２００に対するハンドオーバが許可されないとターゲットｅＮＢ１１０２が決定する場合には、ハンドオーバは失敗する。その後、正常なＸ２ハンドオーバ手続がＵＥ２００に対して実行され（Ｓ１１０７）、限定／低減されたリソースが当該ＵＥ２００に対してターゲットｅＮＢ１１０２（ターゲット・セル）において適用される。しかし、事業者がＵＥ２００のトラッキングが可能となるよう、少なくとも信号伝達経路は正常に保持される。

図１２は、図１０の構成に基づきｅＮＢ内のプロセスをより詳細に示す。

まず第１に、ハンドオーバ制御手段１１１０は、制限情報取得プロセス（Ｓ１２０１）を実行する。ここでは、ハンドオーバ制御手段１１１０は、自己の需要に応じて、制限に関する情報、すなわち、登録セルＩＤ、未登録セルＩＤ、制限されたＴＡ／ＰＬＭＮ／セルＩＤ、ホワイト・セル・リスト、ブラック・セル・リストなどをＭＭＥから受信又は取得する（Ｓ１２０２）。ハンドオーバ制御手段１１１０は制限情報を記憶装置などに保存する（Ｓ１２０３）。

ハンドオーバ手続プロセス（Ｓ１２０４）において、ハンドオーバ制御手段１１１０は、受信したＵＥからの測定報告に基づいて、当該ＵＥに対してハンドオーバが必要であるか否かを決定する（Ｓ１２０５）。ハンドオーバが必要である場合には、ハンドオーバ制御手段１１１０は、ターゲット・セルがＭＭＥから提供された制限情報のうちいずれか１つにあるいずれかのセルと一致するか否かを確認する（Ｓ１２０６）。ハンドオーバ制御手段１１１０は、セルＩＤ以外の制限パラメータ、例えば、ＰＬＭＮＩＤ、トラッキング・エリアＩＤなどもまた考慮してもよい。任意の一致したセル（又はＰＬＭＮ、ＴＡなど）ＩＤが発見されると（Ｓ１２０７）、ハンドオーバ制御手段１１１０は、当該ＵＥに対するリソース限定又は低減のターゲットｅＮＢへの要求を付けて、ハンドオーバ手続を開始し（すなわち、ハンドオーバ要求メッセージをターゲットｅＮＢに送信する）（Ｓ１２０８）、そうでない場合は、正常なハンドオーバ手続が開始される（Ｓ１２０９）。ソースｅＮＢは、ターゲット・セルが当該ＵＥのハンドオーバを許可されていない場合は、ハンドオーバ手続を中止してもよい。

ハンドオーバ要求メッセージを受信するターゲットｅＮＢでは、ハンドオーバ手続はハンドオーバ制御手段１１１０においてトリガされる（Ｓ１２１１、Ｓ１２１２）。ハンドオーバ制御手段が、ソースｅＮＢからのハンドオーバ要求メッセージ中にリソースを限定又は低減する何らかの要求を検出する（Ｓ１２１３）と、ターゲットｅＮＢ内にあるハンドオーバ制御手段１１１０は、当該ＵＥに対する限定／低減されたリソースを保存（Ｓ１２１４）し、ソースｅＮＢとともにハンドオーバ手続を最後まで進める（Ｓ１２１５、Ｓ１２１０）。

[第５の実施の形態]
あるサービス又はアプリケーションに関して、ターゲットネットワーク（例えば、ＰＤＮ）又はターゲットＰＧＷは、ユーザ（例えば、ＵＥ）の位置に基づいて選択されてもよい。他のケースでは、サービスの内容、サービス許可、又はユーザの位置に基づくサービス／アプリケーションのセキュリティレベルを変えてもよい。例えば、企業では、従業員が制限された場所、例えばその企業が置かれるエリア内から接続する場合にのみ、従業員に企業ネットワーク内で機密データにアクセスすることを許している。一例の詳細として、オフィスの外部から接続している、例えばオフィスの外部に置かれた基地局を介して接続しているユーザは、ファイルサーバー内で機密ファイルにアクセスすることを許されない（又はユーザが通信経路上によりセキュアなプロテクション（保護）を得たときのみ許されるようにしてもよい）が、同じユーザはオフィス内に置かれた他の基地局、例えばフェムト基地局に接続するときアクセスすることを許される。他の例として、オフィス又は家の外部から企業ネットワーク又はホームネットワークにアクセスしようとしているユーザは、リモート接続ユーザに関して、特定のネットワークに接続を強制されるようにしてもよい。その結果、ネットワーク・リソースのクラックを回避するためにセキュリティレベルが高く保たれる。

上述したようなシステム要求を満たすために、この実施の形態においては、そのシステムは、ターゲットネットワーク（例えば、ＰＤＮ）、ＰＧＷ、サービスの内容、サービス許可又はセキュリティのレベルなど調整する。そのシステムはすべて、いずれか、又はそれらのコンビネーションを制御（変更、修正など）する。

ターゲットネットワーク（ＰＤＮ）が配置されるケースにおいて、ＰＧＷは、上記実施の形態で述べたＭＭＥからの通知に基づいてＵＥの位置が変更されることを検知すると、サービングＰＤＮからターゲットＰＤＮに切り替える。

ＰＧＷは、アクセス・ポイント・ネーム（ＡＰＮ）とＵＥの位置情報のコンビネーション、例えばＡＰＮと（Ｅ）ＣＧＩ、ＴＡＩなどのＵＥの位置情報を含むＦＱＤＮからターゲットＰＤＮを取得してもよい。また、ターゲットＰＤＮの情報は、静的又は動的データ、例えばＨＳＳ又はＡＡＡサーバーでのサブスクリプションデータとして供給されてもよく、ターゲットＰＤＮのＩＤは位置ＩＤごとに定義されていてもよい。ターゲットＰＤＮが選択されると、ＵＥのベアラ（例えば、ＥＰＳベアラ、ＰＤＰコンテキストなど）又はＰＤＮ接続は、そのＰＧＷでターゲットＰＤＮにバインドされる。

ターゲットＰＤＮへの変更はＰＧＷの変更による。そのような場合、サービングＰＧＷはターゲットＰＤＮにゲートウェイ・リロケーション手続きを行う。そのとき、サービングＰＧＷはターゲットＰＧＷにＵＥコンテキストを送信し、ターゲットＰＤＮはＵＥコンテキストの維持を開始する。

ＰＤＮかつ／又はＰＧＷが変更されるが、ＵＥのアドレス（例えば、ＩＰアドレス）の保管が適用されない場合、新たなアドレスは、例えばアタッチ、サービス要求、トラッキング・エリア更新などの手続（ベアラ生成応答、ベアラ修正応答のメッセージ）を通じてＵＥに提供される。

サービスの内容、サービス許可が用意される場合では、ＰＧＷは、ＵＥの位置の変更かつ／又は位置情報について、ＰＤＮ内のサービス・サーバー又はアプリケーション・サーバーに通知する。ここで、ＰＧＷは、ＵＥが提供される位置又はエリアにいるとき、ＵＥの位置のみをＰＧＷに通知するためにＰＧＷの位置又はエリア（例えば、（Ｅ）ＣＧＩ、ＴＡＩ、ＣＳＧ ＩＤなど）について既に情報を（ＵＥコンテキストの１つとして）有していてもよい。さもなければ、ＰＧＷはＵＥが位置を変更するたびにＵＥの位置を通知してもよい。

サービス内容又はサービス許可が変更される場合、付加的なアクセス認証が行われるようにしてもよい。例えば、ターゲットＰＤＮ内の認証サーバーへの典型的なアクセス認証（例えば、パスワード、アクセス証明書、セキュリティトークンなどを用いて）、又はＳＩＭとサブスクリプションを用いてＵＥのアタッチメントの際に行われる同じ認証手続が行われてもよい。

セキュリティレベルが用意される場合では、ＰＧＷは、ＭＭＥ（さもなければＭＭＥは自身でＵＥの位置の変化を検出する）に通知し、ＭＭＥはＵＥのベアラセキュリティのパラメータを修正してもよい。例えば、企業の外部のＣＳＧセルからのアクセスの場合、ＭＭＥは、通常より高いベアラセキュリティを確保するためにパラメータを修正し、修正されたパラメータを用いてベアラ再構成を開始する。また、ＰＧＷは、ＰＧＷとＰＤＮ（例えば、ＰＧＷと接続されるターゲットＰＤＮ内のゲートウェイ）との間でのセキュアな経路を構築又は改良（アップグレード）してもよい。さらに、ＰＧＷ又はＭＭＥは、ターゲットＰＤＮ内のサービス／アプリケーション・サーバー又はピア（Ｐｅｅｒ）・デバイス／ターミナルとセキュアな経路（例えば、ＩＰsecトンネル）を構築することをＵＥに指示してもよい。その指示は、ＰＤＮ（例えば、サービス／アプリケーション・サーバー又はピア・デバイス／ターミナル）に送信されてもよい。

システムが、ターゲットＰＤＮかつ／又はＰＧＷ、サービス内容、サービス許可、セキュリティレベルなどを変更／調整／制御／修正することはなので、伸縮性のあるサービス／アプリケーションが配置後でも提供され得る。

[第６の実施の形態]
<ＵＥ活動ベースのフィルタ処理>
以降において、ＵＥ１０又はネットワーク・ノード２０はネットワーキング能力を備えたあらゆるデバイスのことを言う。例えば、ネットワーク・ノード２０の機能の一部が、現在の３ＧＰＰ ＳＡＥアーキテクチャにおいて規定される移動体管理エンティティ（ＭＭＥ）及び／又はサービング・ゲートウェイ（ＳＧＷ）に実装されることが完全に可能かもしれない。また、ＵＥ１０はここでは主として、Ｍ２Ｍデバイスとしての多くのデバイス中に実装される機能のことを言うが、このことは、ここで説明される概念があらゆる他のネットワーキング・デバイスに適用されることを限定しない。ＵＥ１０はここでは、特定のサービスを先のパケット・フィルタ・リストとして設定し、ネットワークは、ＵＥ１０がアイドル・モードにあるときには当該ＵＥはパケット・フィルタ・リストと関連付けられたデータを処理する能力がないと決定する。

図１３は、活動ベースのフィルタ処理を実行するシステムのシステム構成を示す。当該システムは、図中においてＭ２Ｍデバイス１０として示され、アイドル・モードでのみ使用指示を備えた許可パケット・リストをネットワーク・ノード２０に提供するＵＥ１０と、アイドル・モードでのみ使用指示を備えた許可パケット・リストの受信直後に、ＵＥ１０がアイドル・モードにあるときに、許可パケット・リストに基づいてダウンリンク・パケットをフィルタリングするネットワーク・ノード２０とから成る。ＵＥ１０及びネットワーク・ノード２０はネットワーク７１にわたって互いに通信する。ネットワーク７１は無線ネットワークであってもよい。またネットワーク７１はＩＰを可能とさせるものであってもよい。ＵＥ１０はまた、非許可パケット情報保存指示をネットワーク・ノード２０に提供してもよい。非許可パケット情報保存指示の受信直後に、ネットワーク・ノード２０は許可パケット・リストと一致しないパケットのパケット情報を保存する。許可パケット・リストと一致しないパケットの保存された情報は、当該パケットのソース、宛先のＩＰアドレス、又はポート番号であってもよい。ＵＥ１０がコネクティッド・モードへと移動した後、ネットワーク・ノード２０は、不許可パケット・リストを当該ＵＥ１０に送信する。

図１４は、本発明の好適な実施形態におけるＵＥ１０の装置を示している。当該装置は低電力用途のために最適化されたアプリケーション１３から成る。アプリケーション１３はＭ２Ｍデバイスのいかなる特定の使用であってもよい。非制限的な例として、スマート・メータリング、温度センサ、カメラ、物流装置等であってもよい。

アプリケーション１３は、あるメッセージ又はパケットが、重大か又は重大でないか（言い換えれば、緊急か又は緊急でないか、または、重要か又はそれほど重要でないか）を知っている必要がある。これは２つの方法で達成することができる。第一の方法は、ポート番号又はＩＰアドレスの標準化されたリストを用いて、メッセージ又はパケットを重大であると識別することである。例えば、ポート番号「ｘｙｚ」の付いたメッセージのみが重大である。他のポート番号を用いる残りのメッセージは重大ではない。第二の方法は、アプリケーション・サーバーとＵＥ１０の間でＰ２Ｐ交換を行って、この情報を動的に取得することである。

ひとたびこの情報が取得されると、この重大なパケット情報は許可パケット・リスト・マネージャ１２に提供される。典型的な実装では、ＡＴコマンドを用いることによって、当該情報は許可パケット・リスト・マネージャ１２を実装するＮＡＳに提供することができる。許可パケット・リスト・マネージャ１２は、許可パケット・リストをメッセージ処理装置１４へと転送する。メッセージ処理装置１４は、この情報をネットワーク・ノード２０へと送信するためのメッセージを用意する。すべての発信メッセージはメッセージ送信機１５によって送信される。着信メッセージはメッセージ受信機１６によって受信される。本発明に関して、メッセージ受信機１６によって受信されうる各メッセージは、ＵＥ１０がコネクティッド・モードへと移動するときは、ネットワーク・ノード２０がＵＥ１０に提供する不許可パケット・リストであり、そうでないときは、許可パケット・リストに記載された重大なパケットのための呼出メッセージである。メッセージ受信機１６が不許可パケット・リストを受信すると、メッセージ処理装置１４は不許可パケット・リストを取得し、当該リストを不許可パケット・リスト・マネージャ１１に提供する。不許可パケット・リスト・マネージャ１１はアプリケーション１３に不許可パケット・リストを提供する。不許可パケット・リスト・マネージャ１１からアプリケーション１３へと情報を転送するのに、ＡＴコマンドを再び用いることができる。

許可パケット・リストが一般的にＩＰアドレス又はポート番号を用いて、パケットをフィルタリングするものであるとわかるものの、ＩＰｖ４リモート・アドレス・タイプ、ＩＰｖ６リモート・アドレス・タイプ、プロトコル識別子／次ヘッダ・タイプ、ローカル・ポート・レンジ・タイプ、シングル・リモート・ポート・タイプ、リモート・ポート・レンジ・タイプ、セキィリィティ・パラメータ指標タイプ、サービスのタイプ／トラフィック・クラス・タイプ、フロー・ラベル・タイプ、トランスポート層ヘッダのコンテンツ（ＵＤＰ、ＴＣＰ、ＳＣＴＰ等）、別の上位層ヘッダのコンテンツ（ＳＩＰ、ＴＬＳ、ＨＴＴＰ等）、トンネル・ヘッダ構成、及び／又は、ペイロード中のコンテンツの一部（アプリケーション／ユーザ・データ等）といった他のフィルタ基準によって、パケットをフィルタリングすることもまた可能である。

図１５は、本発明の好適な実施形態におけるネットワーク・ノード２０の装置を示す。当該装置は、ＵＥ１０から各メッセージを受信するメッセージ受信機２３から成る。受信された各メッセージはさらなる処理のためにメッセージ処理装置２４に提供される。本発明において、メッセージ処理装置２４は「アイドル・モードでのみ使用」指示（又はフラグ）とともに、オプション的に「不許可パケット情報保存」指示とともに許可パケット・リストをＵＥ１０から受信する。次いでメッセージ処理装置２４は、許可パケット・リスト及び各指示を許可パケット・リスト・マネージャ２７に提供する。許可パケット・リスト・マネージャ２７及び各指示は、ダウンリンク・パケットが許可パケット・リストによって提供されたフィルタを通過するか否かを確認するために、ダウンリンク・パケット・フィルタ２１によって用いられる。ダウンリンク・パケットがパケット受信機２８に到着すると、パケット受信機２８はパケットをダウンリンク・パケット・フィルタ２１へと転送する。「アイドル・モードでのみ使用指示」が存在する場合は、ダウンリンク・パケット・フィルタ２１は、活動ステータス・データベース２５に問い合わせて、ＵＥ１０の現在の活動ステータス（又は移動性ステータス）を確認する。活動ステータス・データベース２５が、ＵＥ１０がコネクティッド・モードにあることをダウンリンク・パケット・フィルタ２１に通知する場合は、ダウンリンク・パケット・フィルタ２１は、各パケットを許可パケット・リストによってフィルタリングせずに、パケットを送信機２２に転送する。活動ステータス・データベース２５が、ＵＥ１０がアイドル・モードにあることをダウンリンク・パケット・フィルタ２１に通知する場合は、ダウンリンク・パケット・フィルタ２１は、パケット受信機によって受信されたパケットが許可パケット・リスト・マネージャ２７と適合するか否かを確認する。

パケットが許可パケット・リストと適合する場合は、ダウンリンク・パケット・フィルタ２１はまず、ＵＥ１０を呼び出すようメッセージ処理装置２４に対して要求する。メッセージ処理装置２４は、呼出メッセージを送信機２２を介してＵＥ１０に送信する。ＵＥ１０がネットワーク・ノード２０との接続を設定すると、メッセージ処理装置２４はメッセージ受信機２３を介して呼出要求メッセージをＵＥ１０から取得し、次いでダウンリンク・パケット・フィルタ２１は、不許可パケット・リスト・マネージャ２７に対して不許可パケット・リスト情報を要求する。ダウンリンク・パケット・フィルタ２１は、パケットを送信機２２へと転送し、当該送信機２２はパケットをＵＥ１０にさらに送信する。

パケットが許可パケット・リストと適合しない場合は、ダウンリンク・パケット・フィルタ２１は、可能であれば「不許可パケット情報保存」指示がないか確認する。当該指示が存在する場合には、ダウンリンク・パケット・フィルタ２１はパケットの詳細を不許可パケット・リスト・マネージャ２６に提供する。これら詳細は、ソースのＩＰアドレス、宛先のＩＰアドレス、ソースのポート番号、宛先のポート番号、ヘッダ（単数又は複数）の他の部分、及び／又は、ペイロードの一部と多岐にわたりうる。本発明は、伝えるべき詳細をこの前の文に提示される例に限定していない。パケット全体を保存するといったさらなる詳細も実行されうる。不許可パケット・リスト・マネージャ２６は不許可パケットの関連詳細事項を保存し、ＵＥ１０がコネクティッド・モードへと移動すると当該詳細事項をＵＥ１０に転送する。「不許可パケット情報保存」指示がない場合は、ダウンリンク・パケット・フィルタ２１はパケットを廃棄するだけであり、パケットに対してはこれ以上作動しない。

図１６は、ＵＥ１０が活動ベースのパケット処理を設定するために必要とされるプロセスを図示する。最初に、ステップ３１では、当該アプリケーションは許可パケット・リストのリストを用意する。アプリケーションは、標的ＩＰアドレス及び／又は標的ポート番号などパケット・リストの一部のみ、すなわち必須のコンテンツを提供してもよく、次いで当該コンテンツから、ＵＥ１０は許可パケット・リストの完全な形式を構築する。次いでステップ３２において、用意された許可パケット・リストは「アイドル・モードでのみ使用」指示とともに、オプション的に「不許可パケット情報保存」指示とともにネットワーク・ノード２０へ送信される。例えば、この概念が３ＧＰＰアーキテクチャ内で実装される場合には、アプリケーションはＡＴコマンドを用いて、ＮＡＳ層とりわけＥＳＭ副層に、これらパケットのリスト、及び、不許可パケットを保存するよりもアイドル・モードでのみでの使用への優先を提供する。ＥＳＭ副層は、ＵＥが要求したベアラ割り当て手順を開始し、アプリケーションによって提供されたフィルタをＴＡＤ（トラフィック集約記述）に投入する。追加的にはＥＳＭ副層は、このメッセージ中に「アイドル・モードでのみ使用」指示 及び「不許可パケット情報保存」指示を投入する。

図１７は、ＵＥ１０が不許可パケット・リストを処理するために必要とされるプロセスを図示する。ＵＥ１０が前に説明した許可パケット・リストの保存を設定済の場合は、ネットワーク・ノード２０は、許可パケット・リストと適合しなかったパケットに関する情報を保存する。保留中のアップリンク・データ、ネットワークからのシグナリング、又は呼出のいずれかを理由に、ＵＥ１０がアイドル・モードからコネクティッド・モードへと遷移するときには、ＵＥ１０はステップ３３に示すように不許可パケット・リストを受信する。３ＧＰＰアーキテクチャのために実装されるときは、このメッセージは、サービス受信又はコンテナＩＥといった新しいメッセージ中で送信されてもよい。サービス受信メッセージ中で受信されるパケットの情報（すなわち不許可パケット・リスト）は、上位層（アプリケーション等）に提供される。この提供は、ＡＴコマンドを介して行われてもよい。ステップ３４では、上位層は、問い合わせメッセージを識別された宛先へと開始しうる。問い合わせメッセージの目的は、なぜＵＥ１０が初期接続されたかを見出し、必要なあらゆる情報を提供することである。

図１８は、ネットワーク・ノード２０が活動（アクティビティ）ベースのパケット処理を構成するために必要とされるプロセスを図示する。まずステップ３５で、ネットワーク・ノード２０は、「アイドル・モードでのみ使用」指示及び「不許可パケット情報保存」指示とともに許可パケット・リストを受信する。ネットワーク・ノード２０が「アイドル・モードでのみ使用」指示を受信すると、ステップ３６でネットワーク・ノード２０は、ＵＥ１０がアイドル・モードにあるときにのみ許可パケット・リストが用いられなければならないことを記憶する。

図１９は、ネットワーク・ノード２０が活動ベースのパケット処理を実行するために必要とされるプロセスを図示する。プロセスは、ステップ３７に示すようにダウンリンク・パケットが到着すると、トリガされる。パケットを受信した後ステップ３８で、ネットワーク・ノード２０は、ＵＥ１０がアイドル・モードにあるか否かを確認する。ＵＥ１０がアイドル・モードにない場合は、ネットワーク・ノード２０は許可パケット・リストを無視し、ステップ３９のように処理を継続する。ＵＥ１０がアイドル・モードにある場合は、ステップ４０に示すように、ＵＥ１０は許可パケット・リストを用いたフィルタリングを有効にする。ステップ４１でネットワーク・ノード２０は、パケットが許可パケット・リスト中のフィルタを通過したか否かを検証する。当該パケットがフィルタをすでに通過した場合は、当該パケットは、重大であるとともにＵＥ１０が呼び出されている間にバッファされる許可されたパケットとしてみなされ、ＵＥ１０が呼び出された後に、バッファされたパケットがＵＥ１０に転送される。パケットが許可パケット・リストを通過しない場合は、ステップ４２でネットワーク・ノード２０は、ＵＥ１０が「不許可パケット情報保存」指示を指示したか否かを確認する。ＵＥ１０が「不許可パケット情報保存」指示をまだ提供していない場合は、ステップ４５に示すようにネットワーク・ノード２０は、パケットを廃棄してもよい。ＵＥ１０が「不許可パケット情報保存」指示をすでに提供した場合は、ステップ４３に示すようにネットワーク・ノード２０は、許可されていないパケット、すなわち許可パケット・リストを通過しなかったパケットの情報を不許可パケット・リスト中に保存してもよい。保存された情報は、宛先又はソースのＩＰアドレス、または宛先又はソースのポート番号と多岐にわたりうる。

図２０は、活動ベースのパケット処理のイベントのシーケンス図を示す。まずＵＥ１０は、ダウンリンク・パケットを確認するのに用いられるフィルタから成る許可パケット・リストを用意する。フィルタは、ＩＰｖ４のリモート又は宛先アドレス・タイプ、ＩＰｖ６のリモート又は宛先アドレス・タイプ、プロトコル識別子／次ヘッダ・タイプ、ローカル・ポート・レンジ・タイプ、シングル・ローカル／リモート・ポート・タイプ、リモート・ポート・レンジ・タイプ、セキィリィティ・パラメータ指標タイプ、サービスのタイプ／トラフィック・クラス・タイプ 及びフロー・ラベル・タイプから成ってもよい。次のステップ４６では、ＵＥ１０は許可パケット・リストを「アイドル・モードでのみ使用」指示とともに送信する。ステップ４７では、ネットワーク・ノード２０は許可パケット・リストを保存し、ＵＥ１０がアイドル・モードにあるときにのみこのリストを適用することを記憶する。ネットワーク・ノード２０は次いでステップ４８で、アイドル・モードのみの場合に許可パケット・リストを適用することを求めるＵＥ１０からの要求を受信確認する。当該受信確認を省略して、ステップ４６でメッセージを送信した後すぐにＵＥ１０がアイドル・モードに入ることができ、電池の消費を低減できるようにしてもよい。

しばらくすると、ステップ４９に示すようにＵＥ１０はアイドル・モードへと進む。例えば３ＧＰＰにおいては、通常これが発生するのは、ＵＥ１０が一定時間インアクティブであるとともに、ＭＭＥがこのインアクティブ状態を検知し、Ｓ１シグナリング接続を解除するときである。ここでは図は簡素化され、ステップ５０では、ネットワーク・ノード２０がＵＥ１０の状態をアイドルとして更新することが示される。ステップ５１に示すように、ＵＥ１０の状態のこの変更は、許可パケット・リストによるダウンリンク・パケットのフィルタリングをトリガする。ダウンリンクＩＰパケットが、例えば内部又は外部ＩＰネットワーク９０からネットワーク・ノード２０に到達すると（ステップ５２）、ネットワーク・ノード２０はステップ４１に示すように、ＩＰパケットが許可パケット・リスト中のフィルタを通過するか否かを確認する。パケットが許可パケット・リスト中のフィルタを通過する場合は、ステップ５４に示すように、ネットワーク・ノード２０はＵＥ１０を呼び出すことを決定する。この呼び出しが必要なのは、ＵＥ１０が重大なパケットを識別するためにこれらフィルタを割り当てたと思われるからである。ダウンリンクＩＰパケットが割り当てられたフィルタを通過しない場合は、ネットワーク・ノード２０はパケットを廃棄し、ＵＥ１０を呼び出さないことを決定する（ステップ５３）。

ここではＩＰパケットは、ＵＥのアイドル・モード状態にもかかわらずパケット自体をフィルタに通過させるための、オプション的な指示、例えばフラグ、パケット・ヘッダ又はペイロード中のビット・フィールド等を含んでもよい。この指示は、緊急性、重要性等を備えたパケットのコンテンツに応じて、パケットの送信者であるコレスポンド・ノードによって、追加することができ、その結果、コレスポンド・ノードへの適用によって、ネットワーク・ノード２０内のフィルタ内にまだ掲載されていいない（又は掲載すると想定されていない）あらゆる重要又は緊急なパケットをＵＥ１０に送るよう強制することができ、それゆえ、アプリケーションの柔軟性が高まる。また、当該指示は、例えばいかなるパケットを通過する前にフィルタへの登録が要求されるという制限を理由として、事業者のネットワークのポリシーを反映するために、コレスポンド・ノードとネットワーク・ノード２０の間の経路上のコレスポンド・ノード以外のノード、例えばＩＰネットワーク９０（すなわちＰＤＮ）内のＰＧＷ又はいくつかのサーバー等によって、管理（すなわち追加、修正又は削除）されてもよい。

さらに、ネットワーク・ノード２０は、パケットをＵＥ１０に送信したコレスポンド・ノードに、自己のアイドル・モード状態に起因するＵＥの利用不能について通知してもよく、その結果、コレスポンド・ノードは、ＵＥの一時的な利用不能を考慮し、さらなるパケットをＵＥ１０に送信することを、例えばコレスポンド・ノードがＵＥ１０から何らかのメッセージ又はパケットを受信するとき、定義されたタイマー時間が期限切れとなるとき、定義された時間（ＵＥ１０に時間管理期間として承認されうる時間であり、この時間にのみＵＥはネットワークにアクセスすることが許可される）が来るとき、ＵＥ１０に送信されるべき重要又は緊急のメッセージが生成されるとき等まで延期することができる。例えば、ネットワーク・ノード２０のすべて又は一部を実装するＳＧＷは、ＵＥ１０をサーブするＰＧＷに対し、アイドル・モードにあることを理由とするＵＥの利用不能について通知し、ＰＧＷは、ＵＥの利用不能をコレスポンド・ノードに通知するか、又は、転送することができる。ネットワーク・ノード２０はまた、ＵＥ１０がコネクティッド・モードになるときに、ＵＥの利用可能性をコレスポンド・ノードに通知することができ、その結果コレスポンド・ノードは、時間を消耗するとともに不効率なＵＥ１０からのパケットを待つことなく、通知を受信した直後に、パケットをＵＥ１０に送信するのを再開することができる。例えば、ＭＭＥはアイドル・モードからコネクティッド・モードへのＵＥの状態の遷移について、ＳＧＷ及びＰＧＷを介してコレスポンド・ノードに通知する。

図２１は、不許可パケット・リストを保存することを伴う活動ベースのパケット処理のためのイベントのシーケンス図を示す。まずＵＥ１０は、ダウンリンク・パケットを確認するのに用いられるフィルタから成る許可パケット・リストを用意する。フィルタは、ＩＰｖ４のリモート又は宛先アドレス・タイプ、ＩＰｖ６のリモート又は宛先アドレス・タイプ、プロトコル識別子／次ヘッダ・タイプ、ローカル・ポート・レンジ・タイプ、シングル・ローカル／リモート・ポート・タイプ、リモート・ポート・レンジ・タイプ、セキィリィティ・パラメータ 指標タイプ、サービスのタイプ／トラフィック・クラス・タイプ 及びフロー・ラベル・タイプから成ってもよい。次にステップ５５では、ＵＥ１０は許可パケット・リストを「アイドル・モードでのみ使用」指示とともに送信する。ステップ５６では、ネットワーク・ノード２０は許可パケット・リストを保存し、このリストをＵＥ１０がアイドル・モードにあるときにのみ適用することを記憶する。ネットワーク・ノード２０は次いでステップ５７で、アイドル・モードのみの場合に許可パケット・リストを適用することを求めるＵＥ１０の要求を受信確認する。当該受信確認を省略して、ステップ５５でメッセージを送信した後すぐにＵＥ１０がアイドル・モードに入ることができ、電池の消耗を低減できるようにしてもよい。

しばらくすると、ステップ５８に示すようにＵＥ１０はアイドル・モードへと進む。３ＧＰＰにおいては、通常これが発生するのは、ＵＥ１０が一定時間インアクティブであるとともに、ＭＭＥがこの不活動を検知し、Ｓ１シグナリング接続を解除するときである。ここでは図は簡素化され、ステップでは５９では、ネットワーク・ノード２０はＵＥ１０の状態をアイドルとして更新することが示される。ステップ６０に示すように、ＵＥ１０の状態のこの変更は、許可パケット・リストによるダウンリンク・パケットのフィルタリングをトリガする。ダウンリンクＩＰパケットが、例えば内部又は外部ＩＰネットワーク９０からネットワーク・ノード２０に到着すると（ステップ６１）、ネットワーク・ノード２０はステップ４１に示すように、ＩＰパケットが許可パケット・リスト中のフィルタを通過するか否かを確認する。パケットが許可パケット・リスト中のフィルタを通過する場合は、ステップ７０に示すように、ネットワーク・ノード２０はＵＥ１０を呼び出すことを決定する。この呼び出しが必要なのは、ＵＥ１０が重大なパケットを識別するためにこれらフィルタを割り当てたと思われるからである。ダウンリンクＩＰパケットが割り当てられたフィルタを通過しない場合は、ステップ６２でネットワーク・ノード２０は、ＵＥ１０が「不許可パケット情報保存」指示をすでに提供したか否かを確認する。

当該指示が提供される場合は、ネットワーク・ノード２０はパケットの情報を保存する（ステップ６３）。この情報は、ソース／宛先のＩＰアドレス、ソース／宛先のポート番号、又はさらには、全パケット自体と多岐にわたりうる。ＵＥ１０が「不許可パケット情報保存」指示をまだ提供していない場合は、ステップ６４に示すようにネットワーク・ノード２０はパケットを廃棄する。しばらくすると、ＵＥ１０はステップ６６に示すように、アップリンク・データが保留中であること、又はネットワークが許可パケット・リストを通過するパケットを受信したことのいずれかを理由に、ネットワークとの接続を再確立する。理由は図中には示されていないが、ＵＥ１０のコネクティッド・モードへの遷移をもたらしうる理由のいずれかであろうと推論されうる（ステップ６５）。ＵＥ１０がネットワーク・ノード２０とのシグナリング接続を確立する（ステップ６６）と、ネットワーク・ノード２０はステップ６７に示すように、この機会を利用して不許可パケット・リストをＵＥ１０に送信してもよい。不許可パケット・リストをＵＥに送信するのに成功した後、ネットワーク・ノード２０は不許可パケット・リストをリセットする（ステップ６８）。ＵＥ１０は不許可パケット・リストを受信し、当該リストを上位層（すなわちアプリケーション）に提供する。アプリケーションはステップ６９に示すように、この情報を使って、ＵＥ１０に送信された初期要求の特性について各送信者に問い合わせてもよい。

本発明の一つの実施形態では、ＵＥ１０は、ＧＥＲＡＮ、ＵＴＲＡＮ及びＥ−ＵＴＲＡＮ無線のうち、いずれか又はすべてを備えた３ＧＰＰ適合ＵＥである。ＳＧＳＮ／ＭＭＥ又はＧＧＳＮ／Ｓ−ＧＷがネットワーク・ノードの機能を実行する。許可パケット・リストは、ＵＥ１０が現在ＧＥＲＡＮ／ＵＴＲＡＮ内にあるか又はＥ−ＵＴＲＡＮ内にあるかに応じて、ＳＧＳＮ又はＳ−ＧＷに保存されている。ＵＥ１０は、ＮＡＳすなわち非アクセス層シグナリングと呼ばれる制御シグナリングを用いて、許可パケット・リストの構成を実行する。ＵＥ１０は、ＵＥによって開始されたベアラ／ＰＤＰコンテキスト修正メッセージを用いて、ダウンリンク・フィルタをＰＤＮ接続のデフォルト・ベアラ／ＰＤＰコンテキストに追加する。ＵＥ１０が複数のＰＤＮ接続を持つ場合は、各ＰＤＮ接続には別々のメッセージが必要になるかもしれない。ダウンリンク・フィルタをデフォルト・ベアラ／ＰＤＰコンテキストに追加することは、ＴＦＴと適合しないダウンリンク・パケットが自動的にブロックされることを保証する。ダウンリンク・フィルタをデフォルト・ベアラ／ＰＤＰコンテキストに追加することは、ＴＦＴと適合しないダウンリンク・パケットが自動的にブロックされることを保証する。

ダウンリンク・フィルタに加えて、フィルタの使用はＵＥ１０がアイドル・モードにあるときのみであるべきことを、ＵＥ１０は示さなければならない。したがって、これらフィルタはおそらく、実際にフィルタリングを行うＧＧＳＮ又はＰ−ＧＷに転送されるべきでない。ＳＧＳＮ又はＳ−ＧＷ中にこれら特徴を実装することには２つの利点がある。第一に、これらエンティティはＵＥの移動性ステータス−アイドル又は接続−を知っている。第二に、これらエンティティ内にこれら特徴を実装することによって、本発明のＧＧＳＮ又はＰ−ＧＷへの影響を排除する。Ｓ１モードでは、すなわち、ＵＥ１０が自己のＥ−ＵＴＲＡＮ無線を使用しているときは、シグナリングがＭＭＥを介して実行される。すなわちＭＭＥは、ＵＥとＳＧＳＮ／Ｓ−ＧＷの間の制御シグナリング・メッセージを転送する。ひとたびダウンリンク・フィルタがＳＧＳＮ／Ｓ−ＧＷ内に保存されると、ＳＧＳＮ／Ｓ−ＧＷはＵＥ１０の動作を知る。ＵＥ１０がコネクティッド・モードにある場合は、その通常動作のいずれにも変更がない。しかしＵＥ１０がアイドル・モードにあると、Ｓ−ＧＷは、「アイドル・モードでのみ使用」とＵＥ１０によって印が付けられたダウンリンク・フィルタのフィルタリングを有効にする。ここで、Ｓ−ＧＷは各ダウンリンク・パケットをこれらダウンリンク・フィルタとの合致について確認する。

パケットがダウンリンク・フィルタを通過する場合は、このことは、パケットが重要（又は重大、緊急、優先度が高い等）であり、ＳＧＳＮ／Ｓ−ＧＷはＵＥを呼び出すことを決定することを意味する。パケットがダウンリンク・フィルタを通過しない場合は、このことは、パケットはそれほど重要ではなく（又は重大でない、緊急でない、優先度が高くない）、パケット情報、主に、ソース／宛先ＩＰアドレス及びソース／宛先ポート番号が保存されていることを意味している。ＵＥ１０がコネクティッド・モードへと遷移すると、すなわち、ＵＥ１０がサービス要求メッセージをＳＧＳＮ／ＭＭＥへと送信すると、ネットワークとのシグナリング接続が確立される。近年の３ＧＰＰシステムでは（すなわちｒｅｌ−８の後は）、制御プレーンとともにユーザ・プレーンさえも確立されると予測され、その結果、ひとたびサービス要求手順が完了すると、ＵＥはシグナリング・ベアラ及びデータ・ベアラの両方を持つと予測される。したがって、ＳＧＳＮ／Ｓ−ＧＷは、シグナリング・ベアラ又はデータ・ベアラのいずれかを用いて、不許可パケット・リストがもしあればＵＥ１０に送信することができる。ＵＥアプリケーション１３は次いでこのリストを用いて、問い合わせメッセージを開始する。

本発明における概念は、Ｍ２Ｍアプリケーション中の各アプリケーションが、デバイスの低電力要件と動作を整合させることである。例えば、当該アプリケーションが中央サーバー及び複数のクライアント（ＰＤＡ、移動体等）を備えた監視カメラであると仮定する。サーバーは監視カメラを監視する責任を負っており、各クライアントは監視カメラが撮像中の現在のビデオを要求してもよい。監視カメラを監視することは、ビデオの最後の２、３分を検索すること、カメラが問題なく作動しているか否かを確認すること、ソフトウェアのアップグレードを送信すること等、多岐にわたりうる。ここで、アプリケーションが設計中であると、メッセージを重要な（例えば、高感度データ、警告データ、緊急データ、優先データ等）メッセージと、重要でない（例えば、非高感度データ、非警告データ、非緊急データ、非優先データ等）メッセージへと分けることができる。重要又は時間依存性のメッセージは５００００等、特定のポート番号に用いられうる。さらに、重要とみなされるＩＰアドレスもまた掲載することができる：例１０．１０．１０．１０、１０．１０．１０．１１。ここで、すべての他のメッセージがこのフィルタ構成と適合するわけではない。アプリケーションが行うことは、フィルタの仕様を低位層（ＮＡＳ）に通知することである。ＮＡＳは次いで、これらフィルタ及びアイドル・モードでのみ使用のポリシーをネットワーク（ＳＧＳＮ又はＳ−ＧＷ）に通知する。

ここで、例えばビデオの最後の５分を得ることが重大であると仮定する。この場合、サーバーは５００００をポート番号として用い、例えばＴＣＰ接続を設定するよう試みる。ＩＰパケットがＳ−ＧＷに到達すると、ＵＥ１０がアイドルである場合は、Ｓ−ＧＷはパケットを重要であるとみなし、ＵＥを呼び出す。したがって、重要なパケットは送信される。

ここで、例えばＵＥがアイドル・モードに戻ると仮定する。サーバーが非緊急のソフトウェア・アップブレードを行う必要がある場合は、５００００以外のポートを用いる。ＩＰパケットがＳ−ＧＷに到達すると、Ｓ−ＧＷは、ＩＰパケットがアイドル・モードでのみの使用のために持つパケット・フィルタと適合しないとみなす。したがってＳ−ＧＷは、パケットのコンテンツを保存することによって、パケットを廃棄することを決定する。ここで、サーバーのＩＰアドレス１０．１０．１０．１０及びポート番号（５０００２等）がＳ−ＧＷによって保存される。ＵＥ１０がコネクティッド・モードへと進むと次に、Ｓ−ＧＷはこの情報（ソースＩＰアドレス：１０．１０．１０．１０及びポート番号：５０００２）をＵＥに送信する。ＵＥアプリケーションは次いで、用いたポート番号に基づいて送信されたメッセージの種類を判定し、応答をすぐに送信するか、又は、ＵＥアプリケーションは、一般的な問い合わせメッセージをサーバーへと送信してもよい。サーバーはここで、ＵＥ１０との接続を持ち、ソフトウェア・アップブレードを継続する。したがって、このようにして、ネットワーク及びアプリケーションは必要なときにのみＵＥを起動し、ＵＥの電力使用の最大化を助ける。

[第７の実施の形態]
＜アップリンク・データの種類に基づくシグナリング・セットアップ＞
図２２は、本発明の別の実施形態におけるＵＥ１８１０の装置を記載する。ＵＥ１８１０は、処理待ち中のアップリンク・データ又はシグナリングの存在を監視する責任を持つアップリンク情報チェッカ１８１１から成る。アップリンク・シグナリングが処理待ちであるときは、アップリンク情報チェッカ１８１１は接続マネージャー１８１３に通知する。アップリンク・データが処理待ちであるときは、アップリンク情報チェッカ１８１１はＵＥ−ＱｏＳチェッカ１８１２に通知する。アップリンク・データとアップリンク・シグナリングの両方が処理待ちであるときは、アップリンク情報チェッカ１８１１はＵＥ−ＱｏＳチェッカ１８１２に通知する。

ＵＥ−ＱｏＳチェッカ１８１２は、データのＱｏＳ特性を確認するモジュールである。データがＩＰである場合は、ＱｏＳはＩＰパケットの「サービス種類」フィールドを確認してもよい。高優先順位を検知するのに用いられうる他の情報は、ＩＰｖ４のリモート／ローカルなアドレスの種類、ＩＰｖ６のリモート／ローカルなアドレスの種類、プロトコル識別子／次ヘッダの種類、ローカル・ポート・レンジの種類、シングル・リモート・ポートの種類、リモート・ポート・レンジの種類、セキュリティ・パラメータ・インデックスの種類、サービスの種類／トラフィック・クラスの種類、及び、フロー・ラベルの種類である。ＵＥ中には、高優先順位のアップリンク・データが送信されるべきときに所定のパラメータの種類を用いることが、事前設定されうる。このようなパラメータがパケット中に用いられるときは、ＵＥ−ＱｏＳチェッカは高優先順位状況を検知してもよい。

あるいは、このアプリケーションは他の形態のＱｏＳ情報をＵＥ−ＱｏＳチェッカ１８１２に提供してもよい。ＱｏＳ情報が行う主な決定は、処理待ち中のアップリンク・データがリアルタイム要件を有するか否かについてである。ＱｏＳ情報チェッカは、この情報を接続マネージャー１８１３に提供する。接続マネージャー１８１３は様々なタスクを持つ。まず最初に接続マネージャー１８１３には、あらゆる処理待ち中のアップリンク・データ又はシグナリングが通知される。

アップリンク・データが処理待ちである場合は、データがリアルタイムであるか否かについての情報が受信される。データがリアルタイムである場合は、接続マネージャー１８１３は、ネットワーク２４０内のネットワーク・ノード２０へと送信されるべきステータス・メッセージを、リアルタイム指示を付けて準備する。データが非リアルタイムである場合は、接続マネージャー１８１３は、ネットワーク２４０内のネットワーク・ノード２０へと送信されるべきステータス・メッセージを、非リアルタイム指示を付けて用意する。

提供する指示の種類を決定した後、接続マネージャー１８１３は、メッセージを適切なコード化されたフォーマットでアップリンク・メッセージ送信機１８１５に提供する。アップリンク・メッセージ送信機１５は、アップリンク情報の論理トランスミッタである。

アップリンク・メッセージ送信機１８１５は実際には、無線リソース管理、並べ替え、暗号化、完全性保護、及び、物理的伝送をさらに実行しうるいくつかのモジュールによって実装されてもよい。ページング受信機１８１６は、ネットワーク２４０内のネットワーク・ノード２０によって発行されたページングを受信するモジュールである。ページングを受信した後、ページング・メッセージは接続マネージャー１８１３に転送される。

３ＧＰＰでは、指示を異なる方法でコード化してもよい。例えば、コード化するための一つの方法は、リアルタイム要件がある場合には、ＵＥ１８１０は単に正規のサービス要求を送信する。リアルタイム要件がないときには、ＵＥはベアラ・コンテキスト・ステータスによって拡張されたサービス要求を提供する。

これを行う別の方法は反対の場合である。リアルタイム要件に対しては、高優先順位の指示によって拡張されたサービス要求が提供されてもよい。高優先順位の指示の付いていない正規のサービス要求は、ネットワーク２４０内のネットワーク・ノード２０によって、低優先順位として取り扱うことができる。当業者は多数の方法で上記方法を体系化しうるので、それゆえ、本発明は用いられるサービス要求の種類によって制約されない。

図２３は、ＵＥ中で処理待ち中のアップリンク・データの好適な評価方法を示す図である。ＵＥ１８１０がアイドル・モードにある間は、ステップ１８３１に示すように、処理待ち中のアップリンク情報を絶えず確認する。処理待ち中のアップリンク情報がある場合は、ステップ１８３５に示すように、ＵＥ１８１０は当該情報がデータかもしくはシグナリングかを確認する。アップリンク情報がシグナリングのみである場合は、ＵＥ１０はステップ１８３２に言及するように、シグナリング指示の付いたステータス・メッセージを送信する。「シグナリング」指示は多くの方法でコード化することができる。

一つの方法は、シグナリング接続が必要なことをネットワーク・ノード２０に通知することを唯一の目的とする、シグナリング・サービス要求と呼ばれる新規のメッセージを指定することである。別の方法は、当該サービス要求はシグナリングを理由とすることを示す、例えば４又は８ビットから成るオプショナルな情報要素を、正規のサービス要求メッセージ中に指定することである。アップリンク情報がデータとシグナリングの両方を有する場合は、ステップ１８３３に示すように、ＵＥ１８１０はデータがリアルタイム要件を持つか否かを判断する。これは様々な方法で確認できる。

一つの可能な方法は、ＩＰデータのＴＯＳフィールドを確認することであり、その結果、既存のリソースをこの目的のために用いることができるので、メッセージ中には何ら追加的なフィールドが必要とされない。高優先順位を検知するのに用いられうる他の情報は、ＩＰｖ４のリモート／ローカルなアドレスの種類、ＩＰｖ６のリモート／ローカルなアドレスの種類、プロトコル識別子／次ヘッダの種類、ローカル・ポート・レンジの種類、シングル・リモート・ポートの種類、リモート ポート・レンジの種類、セキュリティ・パラメータ・インデックスの種類、サービスの種類／トラフィック・クラスの種類、及び、フロー・ラベルの種類である。ＵＥ中には、高優先順位のアップリンク・データが送信されるべきときに所定のパラメータの種類を用いることが、事前設定されうる。このようなパラメータがパケット中に用いられるときは、ＵＥ−ＱｏＳチェッカは高優先順位状況を検知してもよく、その結果、既存のリソースをこの目的のために用いることができるので、メッセージ中には何ら追加的なフィールドが必要とされない。

別の可能な方法は、当該アプリケーション・データが、リアルタイム要件があるか否かをＵＥ−ＱｏＳチェッカ１８１２に対して明示的に指示することであり、その結果、アプリケーション・データからの指示が追加的な評価なく決定のために用いることができるので、ＵＥ−ＱｏＳチェッカ１８１２内での処理コストを低減することができる。別の可能な方法は、ＵＥ−ＱｏＳチェッカ１８１２が、パケットの、ＲＴＰ又はＳＣＴＰ又は他のストリーミング・アプリケーション等、アプリケーション・プロトコルの種類について検査することであり、その結果、アプリケーション・データ中には追加的なインタフェースもメッセージフィールドもいずれも要求されず、既存のアプリケーションをそのまま活用することができる。

これら確認後にリアルタイム要件がある場合は、ステップ１８３６に示されるようにＵＥ１８１０は、リアルタイム指示の付いたステータス・メッセージを送信する。現在の既存のシステムにおけるこのメッセージへの予想される応答は、ネットワーク２４０内のネットワーク・ノード２０が対応するベアラ・コンテキストに対するすべてのベアラをセットアップすることである。しかしながら、データに何らリアルタイム要件がない場合は、ステップ１８３７に示すようにＵＥ１８１０は、非リアルタイム指示の付いたステータス・メッセージを送信する。オプション的には、リアルタイム要件がないときでも、ＵＥはアップリンク・データ・ステータス・メッセージを送信しうる。

図２４は、シグナリング接続のセットアップのためのＵＥのネットワークとの相互作用を示す図である。ステップ１８３８では、ＵＥ１８１０は、処理待ち中のアップリンク・データ、ならびに、データのＱｏＳを検知する。この後に、ＵＥ１８１０はステップ１８３９に示すように、リアルタイムの必要性の指示の付いた関連のステータス更新メッセージを送信する。ステップ１８４０では、ネットワーク２４０内のネットワーク・ノード２０は、少なくとも２つのこと：ネットワーク内で利用可能な現在のリソース、及び、ＵＥ１８１０によるリアルタイム又は緊急の通信の必要性を考慮に入れて要求を評価する。

図２５は、ネットワーク２４０内のネットワーク・ノード２０によるシグナリング接続セットアップの好適な方法を示す図である。最初に、ステップ１８４１に示すように、ネットワーク２４０内のネットワーク・ノード２０は、ネットワークが当該要求のためのリソースを提供することができるか否かを評価する。ネットワーク２４０内のネットワーク・ノード２０は、様々なネットワーク・モジュールのリソースを考慮してもよい。非限定的な例としては、３ＧＰＰにおいてＭＭＥ又はＳＧＳＮは、ＭＭＥ、Ｓ−ＧＷ、Ｐ−ＧＷ、又は、ＡＰＮ（ＰＤＮ）自体の中で利用可能なリソースを考慮してもよい。

ＭＭＥは、各サービス要求を受信した後、又は、リソースの負荷の定期的な更新を受信した後のいずれかに、問い合わせにより当該リソースを知りうる。ネットワーク２４０内のネットワーク・ノード２０が、当該特定のステータス更新メッセージのために十分なリソースがあることを検知した場合は、ネットワーク２４０内のネットワーク・ノード２０は正規として進める。すなわち、他のあらゆる要件（例えば、セキュリティ、加入者契約 (subscription)等）が満たされている場合は、ステップ１８４２に示すように、要求されたベアラが確立され、これは正規処理とみなされる。

ネットワーク２４０内のネットワーク・ノード２０が、当該特定のステータス更新メッセージのために十分なリソースがないことを検知した場合は、ステップ１８４３に示すように、ネットワーク２４０内のネットワーク・ノード２０は、ＵＥ１８１０からのメッセージが、リアルタイムもしくは緊急の要件を有する旨の指示を有するか否かを確認する。ここでは、ネットワーク２４０内のネットワーク・ノード２０は、ステップ１８４４に示すように、リソース制限の種類及び事業者ポリシーといった要素に基づいて、いくつかの種類の決定を行ってもよい。

例えば、十分なＧＢＲベアラを提供するにあたってリソース制限がある場合は、ネットワーク２４０内のネットワーク・ノード２０は、おそらくはアップリンク・データ・ステータス・メッセージが存在すれば当該メッセージを用いて、要求されたベアラのサブセットのみを確立（例：非ＧＢＲベアラをセットアップ）してもよい。リソース制限が重いシグナリング負荷に起因し、かつ、ＵＥ１８１０がリアルタイム要件を指示しなかった場合は、ネットワーク２４０内のネットワーク・ノード２０は、要求を拒絶し、おそらくは、任意の時間の後再試行するようＵＥ１８１０に依頼（指示）してもよい。リソース制限が重いシグナリングに起因し、かつ、ＵＥ１８１０がリアルタイム要件を既に指示していた場合は、ネットワーク２４０内のネットワーク・ノード２０は、要求を許容し、おそらくは、このような要求に対してより高い課金をしてもよい。

上記に記載の実施形態の詳細に用いられた各機能ブロックは、典型的には集積回路によって代表されるＬＳＩ（大規模集積回路）として実現することができる。これらは、１個のチップとして個別に生産されてもよく、又は一部又はすべてを含めて１個のチップとして設計されてもよい。ここでは、機能ブロックは、集積度に依存してＩＣ、システムＬＳＩ、スーパーＬＳＩ、又はウルトラＬＳＩとも呼ばれうるが、ここではＬＳＩと称する。また、集積回路の技法は、ＬＳＩにのみ限定されるのではなく、専用回路又は汎用目的処理装置として実現されてもよい。ＬＳＩの製造の後にプログラミング可能なＦＰＧＡ（フィールド・プログラム可能なゲート・アレイ）、又はＬＳＩ内部の回路セルの接続又は設定が再構成可能な処理装置が用いられてもよい。さらに、半導体技法又はそこから導き出された他の技法の進歩に伴い、ＬＳＩに置き換わる回路集積の技法が出現したときには、機能ブロックはそのような技法を用いて集積されてもよい。例えば、バイオ技術の適応はこれら可能性のうちの１つである。

本発明は、ネットワーク・リソース及び携帯電話リソースの消耗を低減する利点を有する。したがって、本発明はパケット交換方式のデータ通信ネットワークにおける通信の分野として、有利に用いることができる。

Claims (4)

1. アイドル状態のモバイル端末をページングする方法であって、
   サービングゲートウェイが、前記モバイル端末宛のダウンリンクデータパケットをベアラで受信した場合に、前記ベアラのベアラＩＤを含むダウンリンクデータ通知をＭＭＥに送信するステップと、
   前記ＭＭＥが、ダウンリンクデータ通知の数を削減することを要求する情報を含む遅延ダウンリンク・パケット通知要求を前記サービングゲートウェイに送信するステップと、
   前記サービングゲートウェイが、前記ベアラより高い優先度情報を有するベアラで新たなダウンリンクデータパケットを受信した場合のみ、新たなダウンリンクデータ通知を前記ＭＭＥに送信するステップとを、
   有するページング方法。
2. ダウンリンクデータ通知の数を削減することを要求する前記情報は、遅延情報を含む請求項１に記載のページング方法。
3. ＭＭＥにアイドル状態のモバイル端末をページングすることをトリガするサービングゲートウェイであって、
   前記モバイル端末宛のダウンリンクデータパケットをベアラで受信するデータ受信部と、
   前記ベアラのベアラＩＤを含むダウンリンクデータ通知を前記ＭＭＥに送信する送信部と、
   前記ＭＭＥからダウンリンクデータ通知の数を削減することを要求する情報を含む遅延ダウンリンク・パケット通知要求を受信する受信部とを有し、
   前記送信部は、前記サービングゲートウェイが、前記ベアラより高い優先度情報を有するベアラで新たなダウンリンクデータパケットを受信した場合のみ、新たなダウンリンクデータ通知を前記ＭＭＥに送信するサービングゲートウェイ。
4. ダウンリンクデータ通知の数を削減することを要求する前記情報は、遅延情報を含む請求項３にサービングゲートウェイ。