JP2013059085A - 状態／モード遷移のための方法および装置 - Google Patents

Abstract

【課題】状態／モード遷移のための方法および装置の提供。
【解決手段】ユーザ機器による遷移指示メッセージの使用を制御する方法およびネットワーク要素であって、該方法は、構成メッセージに遷移阻止指示を含むことと、遷移阻止指示を伴う構成メッセージをユーザ機器に送信することとを含む。また、遷移指示を送信するための方法およびユーザ機器であって、該方法は、ネットワーク要素から受信された遷移阻止指示に従ってタイマを設定することと、データ転送が完了したことを検出することと、タイマが作動していないことを検出すると遷移指示を送信することとを含む。
【選択図】図１

Description

本開示は、ユーザ機器（ＵＥ）または他のワイヤレスあるいはモバイルデバイスと、ワイヤレスネットワークとの間の無線リソース制御に関し、具体的には、例えば、Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ（ＵＭＴＳ）ネットワーク等の、ワイヤレスネットワークにおいて、動作の状態およびモードの間で遷移するステップに関する。

Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ（ＵＭＴＳ）は、テキスト、デジタル化音声、ビデオ、およびマルチメディアの伝送用の広帯域でパケットベースのシステムである。それは、第３世代の基準に高度に同意しており、概して、広帯域符号分割多重アクセス（Ｗ−ＣＤＭＡ）に基づく。

ＵＭＴＳネットワークでは、プロトコルスタックの無線リソース制御（ＲＲＣ）部が、ＵＥとＵＴＲＡＮとの間の無線リソースの割当、構成、および解放に関与している。このＲＲＣプロトコルは、３ＧＰＰ ＴＳ ２５．３３１仕様書で詳細に説明されている。ＵＥがとり得る２つの基本モードは、「アイドルモード」および「ＵＴＲＡ ＲＲＣ接続モード」（または単に、本明細書で使用されるような「接続モード」）として定義される。ＵＴＲＡは、ＵＭＴＳ地上波無線アクセスを表す。アイドルモードでは、ＵＥまたは他のモバイルデバイスは、任意のユーザデータを送信したいときはいつでも、または、ＵＴＲＡＮあるいはサービング汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＳＧＳＮ）ページといった、ページに応じて、プッシュサーバ等の外部データネットワークからデータを受信したいときはいつでも、ＲＲＣ接続を要求する必要がある。アイドルモードおよび接続モードの動作は、第３世代パートナーシッププロジェクト（３ＧＰＰ）仕様書ＴＳ ２５．３０４およびＴＳ ２５．３３１で詳細に説明されている。

ＵＴＲＡ ＲＲＣ接続モードであるときに、デバイスは、４つの状態のうちの１つとなり得る。これらは、以下の通りである。
ＣＥＬＬ＿ＤＣＨ：データを交換するように、この状態ではアップリンクおよびダウンリンクで専用チャネルがＵＥに割り当てられる。ＵＥは、３ＧＰＰ ２５．３３１で概説されるようなアクションを行わなければならない。
ＣＥＬＬ＿ＦＡＣＨ：この状態では、いずれの専用チャネルもユーザ機器に割り当てられない。その代わり、少量の集中的データを交換するために共通チャネルが使用される。ＵＥは、３ＧＰＰ ＴＳ ２５．３０４で定義されるようなセル選択過程を含む、３ＧＰＰ
２５．３３１で概説されるようなアクションを行わなければならない。
ＣＥＬＬ＿ＰＣＨ：ＵＥは、ページングインジケータチャネル（ＰＩＣＨ）を介して同報通信メッセージおよびページを監視するために、不連続受信（ＤＲＸ）を使用する。いずれのアップリンク活動も可能ではない。ＵＥは、３ＧＰＰ ＴＳ ２５．３０４で定義されるようなセル選択過程を含む、３ＧＰＰ ２５．３３１で概説されるようなアクションを行わなければならない。ＵＥは、セル再選択後に、セル更新手順を行わなければならない。
ＵＲＡ＿ＰＣＨ：ＵＥは、ページングインジケータチャネル（ＰＩＣＨ）を介して同報通信メッセージおよびページを監視するために、不連続受信（ＤＲＸ）を使用する。いずれのアップリンク活動も可能ではない。ＵＥは、３ＧＰＰ ＴＳ ２５．３０４で定義されるようなセル選択過程を含む、３ＧＰＰ ２５．３３１で概説されるようなアクションを行わなければならない。この状態は、ＵＲＡ更新手順がＵＴＲＡＮ登録エリア（ＵＲＡ）の再選択を介してのみ誘起されることを除いて、ＣＥＬＬ＿ＰＣＨと同様である。

アイドルモードから接続モードへの遷移、およびその逆は、ＵＴＲＡＮによって制御される。アイドルモードＵＥがＲＲＣ接続を要求すると、ネットワークは、ＵＥをＣＥＬＬ＿ＤＣＨまたはＣＥＬＬ＿ＦＡＣＨ状態にするかどうかを決定する。ＵＥがＲＲＣ接続モードであるときは、この場合もやはり、ＲＲＣ接続を解放するときを決定するのはネットワークである。ネットワークはまた、接続を解放する前に、または場合によっては接続を解放する代わりに、ＵＥを１つのＲＲＣ状態から別のＲＲＣ状態にしてもよい。状態遷移は、典型的には、ＵＥとネットワークとの間のデータ活動または非活動によって誘起される。ネットワークは、ＵＥが所与のアプリケーションのためのデータ交換を完了したときを知らない場合があるため、典型的には、ＵＥを往復するさらなるデータを見込んで、しばらくの間ＲＣＣ接続を保つ。これは、典型的には、呼設定および後続の無線リソース設定の待ち時間を削減するように行われる。ＲＲＣ接続解放メッセージは、ＵＴＲＡＮのみによって送信することができる。このメッセージは、ＵＥとＵＴＲＡＮとの間の信号リンク接続および全ての無線リソースを解放する。概して、「無線ベアラ」という用語は、ＵＥとＵＴＲＡＮとの間で割り当てられる無線リソースを指す。そして、「無線アクセスベアラ」とは、概して、ＵＥと、例えばＳＧＳＮ（サービングＧＰＲＳサービスノード）との間で割り当てられる無線リソースを指す。本開示は、時折、無線リソースという用語を指すものであり、そのような用語は、必要に応じて、無線ベアラおよび／または無線アクセスベアラのいずれか一方または両方を指すものである。

上記に関連する問題は、たとえＵＥ上のアプリケーションがデータトランザクションを完了し、さらなるデータ交換を予期していなくても、依然としてネットワークがそれを正しい状態にすることを待つという点である。ネットワークは、ＵＥ上のアプリケーションがそのデータ交換を完了したという事実を認識していない場合さえある。例えば、ＵＥ上のアプリケーションは、ＵＭＴＳコアネットワークを通してアクセスされる、そのアプリケーションサーバとデータを交換するために、独自の確認に基づくプロトコルを使用してもよい。例は、独自の保証された配信を実施する、ユーザデータグラムプロトコル／インターネットプロトコル（ＵＤＰ／ＩＰ）上で作動するアプリケーションである。そのような場合、ＵＥは、アプリケーションサーバが全てのデータパケットを送信または受信したか否かが分かり、さらなるデータ交換が行われるかどうかを判定し、したがって、パケットサービス（ＰＳ）ドメインと関連付けられたＲＲＣ接続を終結させるときを決定するのにより良好な立場にある。ＵＴＲＡＮは、ＲＲＣ接続状態が異なる状態またはアイドルモードに変更されるときを制御し、かつＵＴＲＡＮは、ＵＥと外部サーバとの間のデータ配信の状態を認識していないため、ＵＥは、必要とされるよりも早いデータ転送速度またはモードでありつづけることを余儀なくされる場合があり、移動局の減少したバッテリ寿命をもたらす可能性があり、また、無線リソースが不必要に占有されたままであり、したがって別のユーザに利用可能ではないという事実により、無駄なネットワークリソースをもたらす可能性もある。

上記の１つの解決法は、ＵＥがデータトランザクションを終了したことを自覚すると、ＵＥにＵＴＲＡＮへ信号伝達解放指示を送信させることである。３ＧＰＰ ＴＳ ２５．３３１仕様書の第８．１．１４．３項に準じて、ＵＴＲＡＮは、ＵＥからの信号伝達解放指示の受信時に、信号伝達接続を解放して、ＵＥをアイドルモードまたは何らかの他のＲＲＣ状態に遷移させてもよい。上記の解決法に関連する問題は、ＵＴＲＡＮにＵＥまたは他のＵＥからの信号伝達解放指示メッセージが殺到するかもしれないという点である。

以下で提供される実施例および実施形態は、例えば、ＵＭＴＳネットワーク等のワイヤレスネットワークにおいて、動作の種々の状態／モードの間で、ユーザ機器（ＵＥ）または他のモバイルデバイスを遷移させるための種々の方法およびシステムを説明する。他の種類のネットワークにおける他の実装も可能であることを理解されたい。例えば、同教示は、符号分割多重アクセス（ＣＤＭＡ）ネットワーク（例えば、３ＧＰＰ２ ＩＳ−２０００）、広帯域ＣＤＭＡ（Ｗ−ＣＤＭＡ）ネットワーク（例えば、３ＧＰＰ ＵＭＴＳ ／高速パケットアクセス（ＨＳＰＡ）、進化型ＵＴＲＡＮネットワーク（例えば、ＬＴＥ）に適用することもでき、または、一般的に言えば、ネットワーク制御された無線リソースを使用する無線アクセス技術に基づくか、あるいはデバイスアプリケーションレベルデータ交換の状態の知識を維持しない、任意のネットワークに適用することもできる。以下で説明されるが、ＵＭＴＳネットワークとの関連で簡単にするために提示される、具体的実施例および実装は、これらの他のネットワーク環境にも適用可能である。さらに、ネットワーク要素は、ＵＴＲＡＮとして以下で説明されることもある。しかしながら、ＵＭＴＳの他に他のネットワーク型が利用される場合、ネットワーク型に基づいて、ネットワーク要素を適切に選択することができる。さらに、ネットワーク要素は、ＵＭＴＳシステムまたは任意の他の適切なネットワークシステム内のコアネットワークとなり得て、その場合、ネットワーク要素は、遷移決定を行うエンティティである。

特定の実施例では、本システムおよび方法は、ネットワークにおける意思決定能力を提供しながら、ＲＲＣ接続モードから、よりバッテリ効率の良い、または無線リソース効率の良い状態あるいはモードへの遷移を提供する。具体的には、本方法および装置は、暗示的または明示的に、無線リソースとの特定の信号伝達接続と関連付けられた、ＲＣＣ状態またはモードの別の状態またはモードへの遷移が発生するべきであると示す、ＵＥからの指示の受信に基づいて、遷移を提供する。理解されるように、そのような遷移指示または要求は、現在の基準下での既存の通信、例えば、信号伝達接続解放指示メッセージを利用することができ、または、「好ましいＲＲＣ状態要求」あるいは「データ転送完了指示メッセージ」等の、ＵＥの状態を変更する新規の専用メッセージとなり得る。データ転送完了指示メッセージは、上位層データ転送の完了を示すメッセージである。本明細書で使用されるように、指示は、いずれのシナリオも指すことができ、かつ要求を組み込むことができる。

ＵＥによって発信される遷移指示は、ＵＥ上の１つ以上のアプリケーションがデータの交換を完了したとき、および／または、ＵＥがさらなるデータを交換すると見込まれないという判定が行われたときの、いくつかの状況で送信することができる。次いで、ネットワーク要素は、モバイルデバイスを別のモードまたは状態に遷移させるか、何もしないかについて、ネットワーク特有の決定を行うために、指示およびその中で提供される任意の情報、ならびに、とりわけ、サービスの質、アクセスポイント名（ＡＰＮ）、パケットデータプロトコル（ＰＤＰ）コンテキスト、履歴情報等の、本明細書で無線リソースプロファイルとして定義される、無線リソースに関係する他の情報を使用することができる。ＵＥまたはモバイルデバイスによって提供される遷移指示は、いくつかの形態を取ることができ、かつ異なる条件下で送信することができる。第１の実施例では、遷移指示は、ＵＥ上に常駐するアプリケーションの全ての複合状態に基づいて送信することができる。具体的には、ＵＭＴＳ環境では、ＵＥ上のアプリケーションがデータの交換を終了したと判定した場合、「終了」指示をＵＥソフトウェアの「接続マネージャ」コンポーネントに送信することができる。接続マネージャは、一実施形態では、全ての既存アプリケーション（１つまたは複数のプロトコル上でサービスを提供するものを含む）、関連パケットデータプロトコル（ＰＤＰ）コンテキスト、関連パケット交換（ＰＳ）無線リソース、および関連回線交換（ＣＳ）無線リソースを追跡することができる。ＰＤＰコンテキストは、ＵＭＴＳコアネットワークにわたって作動する、ＵＥとＰＤＮ（公衆データネットワーク）との間の論理的関連付けである。ＵＥ上の１つまたは複数のアプリケーション（例えば、Ｅメールアプリケーションおよびブラウザアプリケーション）は、１つのＰＤＰコンテキストと関連付けられてもよい。場合によっては、ＵＥ上の１つのアプリケーションは、１つの１次ＰＤＰコンテキストと関連付けられ、複数のアプリケーションは、２次ＰＤＰコンテキストと結び付けられてもよい。接続マネージャは、同時にアクティブであるＵＥ上の異なるアプリケーションから、「終了」指示を受信する。例えば、ユーザは、ウェブを閲覧しながらプッシュサーバからＥメールを受信してもよい。Ｅメールアプリケーションは、確認を送信した後に、そのデータトランザクションを完了したことを示してもよい。ブラウザアプリケーションは、異なる行動をし、代わりに、接続マネージャに「終了」指示を送信するときの（例えば、非活動タイマを使用するための）予測判定を行ってもよい。

アクティブアプリケーションからのそのような指示の複合状態に基づいて、ＵＥソフトウェアは、遷移指示を送信することを決定して、１つの状態またはモードから別の状態またはモードへの遷移が発生すべきであることをネットワークに指示または要求することができる。代替として、ＵＥソフトウェアは、代わりに、遷移指示を送信する前に待って遅延を導入し、アプリケーションが本当にデータ交換を終了し、バッテリまたは無線リソース集中状態またはモードで維持される必要がないことを確実にすることができる。遅延は、トラフィック履歴および／またはアプリケーションプロファイルに基づいて動的となり得る。ある確率で、アプリケーションがデータを交換することが見込まれると接続マネージャが判定するときはいつでも、ネットワークに遷移指示を送信して、遷移が発生すべきであると示すことができる。具体的実施例では、遷移指示は、アイドルモードへの遷移を要求する、適切なドメイン（例えば、ＰＳドメイン）のための信号伝達接続解放指示となり得る。代替として、遷移指示は、ＵＴＲＡＮへの接続モード内の状態遷移の要求となり得る。

以下でさらに詳細に説明されるように、遷移指示、および随意で、無線リソースプロファイルの受信に基づいて、ＵＭＴＳ環境内のＵＴＲＡＮ等のネットワーク要素は、１つの状態またはモードから別の状態またはモードにＵＥを遷移させることを決定することができる。

他の遷移指示が可能である。例えば、ＵＥ上の全てのアクティブアプリケーションの複合状態に依存する代わりに、ＵＥソフトウェアは、代替実施形態で、ＵＥアプリケーションがデータの交換を完了するたびに、および／またはアプリケーションがさらなるデータを交換すると見込まれないたびに、遷移指示を送信することができる。この場合、ネットワーク要素（例えば、ＵＴＲＡＮ）は、以下の図１８を参照して説明されるような、ＵＥのオプションの無線リソースプロファイルに基づいて、遷移決定を行うために指示を利用することができる。

さらに別の実施例では、遷移指示は、単に、ＵＥ上の１つ以上のアプリケーションがデータ交換を完了した、および／または、ＵＥアプリケーションがさらなるデータを交換すると見込まれないと示すことができる。その指示およびＵＥのオプションの無線リソースプロファイルに基づいて、ネットワーク（例えば、ＵＴＲＡＮ）は、より適切な状態またはモードまたは動作にＵＥを遷移させるかどうかを決定することができる。

さらなる実施例では、遷移指示は、明示的よりもむしろ暗示的となり得る。例えば、指示は、周期的に送信される状態報告の一部であってもよい。そのような状態報告は、無線リンクバッファがデータを有するかどうか等の情報をふくむことができ、またはアウトバウンドトラフィック上に情報を含むことができる。

ＵＥは、遷移指示を送信するときに、指示に対する行動を決定するのにネットワーク要素を支援するために、追加情報を含んでもよい。この追加情報は、ＵＥがメッセージを送信する理由または原因を含む。この原因または理由（以下でさらに詳細に説明される）は、「急速休眠」のような動作の必要性を判定するＵＥに基づく。そのような追加情報は、新規の情報要素、または遷移指示メッセージ内の新規パラメータを介したものであってもよい。

さらなる実施形態では、以前の遷移指示が送信されてから、ある期間が経過するまで（阻止期間）遷移指示が送信されなくてもよいことを確実にするように、ＵＥ上にタイマが存在することができる。この阻止タイマは、ＵＥが遷移指示メッセージを過剰に頻繁に送信することを制限し、さらに、所与の最大頻度のみで誘起されるメッセージに依存することによって、ネットワークが判定を行うことを可能にする。期間は、その値が事前構成されるか、またはネットワークによって設定される（指示または信号伝達される）タイマによって、判定することができる。値がネットワークによって設定される場合、それは、とりわけ、ＲＲＣ接続要求、ＲＲＣ接続解放、無線ベアラ設定、ＵＴＲＡＮモビリティ情報、またはシステム情報ブロック等の、新規または既存のメッセージの中で伝えることができ、かつこれらのメッセージの中の情報要素となり得る。値は、代替として、例えば、ＵＥから受信されたＲＲＣ接続要求メッセージに応じてＵＴＲＡＮによって送信される、ＲＲＣ接続設定メッセージの遷移阻止指示部分の中で伝えることができる。

代替実施形態では、その種類がＵＥの状態に依存するメッセージの中で、値をＵＥに伝えることができる。例えば、ネットワークは、ＩＤＬＥ、ＵＲＡ＿ＰＣＨ、Ｃｅｌｌ＿ＰＣＨ、またはＣＥＬＬ＿ＦＡＣＨ状態であるときにＵＥによって読み取られるシステム情報メッセージの一部分として、全てのＵＥに値を送信することができる。

さらに別の実施形態では、ＲＲＣ接続設定メッセージの一部分として値を送信することができる。

ネットワーク生成されたメッセージはまた、メッセージの中、またはメッセージ内の情報要素の中に阻止タイマを含まないことにより、暗示阻止タイマ値を伝えてもよい。例えば、阻止タイマが受信メッセージから省略されていることを判定すると、ＵＥは、阻止タイマ値として使用するために所定の値を適用する。阻止タイマ値の省略の１つの例示的な使用は、ＵＥが遷移指示メッセージを送信することを禁止するものである。そのような状況では、ＵＥが受信メッセージの中の予期された阻止タイマ値の省略を検出すると、ＵＥは、省略に基づいて、あらゆる遷移指示メッセージを送信することが禁止されてもよい。このことを達成するための１つの方法は、ＵＥが無限の阻止タイマ値を採択することである。

別の実施形態では、ＵＥは、阻止タイマ値の省略を検出すると（かつ、例えば、無限の阻止タイマ値を採択すると）、いずれの追加情報も含まずに遷移指示を送信してもよく、具体的には、遷移指示の送信を誘起するための原因を省略してもよい（以下でさらに詳細に説明される）。遷移指示メッセージの中の原因要素の省略は、ＵＥが遷移を要求または指示するために既存の遷移指示メッセージ（例えば、信号伝達接続解放指示）を使用できるようにすることによって、後方互換性を確保してもよい。

受信メッセージに阻止タイマを含まないことは、システム情報ブロックがセルの中で同報通信されるか、またはＵＥに送信され、かつシステム情報ブロックが阻止タイマ値を伝えるように構成される、例示的実施形態を参照して、さらに詳述される。この実施形態では、ＵＥが、メッセージまたはメッセージ内の情報要素にＴ３ｘｘとして知られる阻止タイマを含有しない、システム情報ブロックを受信する場合、ＵＥは、例えば、阻止タイマＴ３ｘｘを無限に設定することによって、ＵＥが遷移指示メッセージを送信できなくなることを判定してもよい。

阻止タイマを含まないことは、阻止タイマＴ３ｘｘがＵＴＲＡＮモビリティ情報メッセージから省略される、別の例示的実施形態を参照して、さらに詳述される。そのような状況では、受信ＵＥは、以前に記憶された阻止タイマ値を引き続き適用してもよい。代替として、ＵＥは、阻止タイマＴ３ｘｘの省略を検出すると、例えば、阻止タイマＴ３ｘｘを無限に設定することによって、ＵＥが遷移指示メッセージを送信できなくなることを判定してもよい。

さらに別の例示的実施形態では、ＵＥは、受信メッセージの中またはメッセージ内の情報要素の中の阻止タイマの省略を検出すると、阻止タイマ値を別の事前設定値（例えば、０秒、５秒、１０秒、１５秒、２０秒、３０秒、１分、１分３０秒、２分のうちの１つ）に設定する。代替として、または加えて、これらの実施例は、他のネットワーク生成されたメッセージを適用してもよい。

他の実施形態では、阻止タイマ（値）がメッセージまたは情報要素の中でＵＥに送信または信号伝達されなかった場合、または、１つのセルから別のセルへ遷移する際に、阻止タイマが同報通信システム情報から読み取られないか、または他の専用ＵＴＲＡＮメッセージから受信されなかった場合、遷移指示の送信は、発生してもしなくてもよい。

具体的には、一実施形態で、ＵＥは、いずれの阻止タイマも存在しないことを検出すると、伝送するＰＳがもうないことを判定する上位層に基づいて、遷移指示を開始しない。

代替実施形態では、ＵＥは、いずれの阻止タイマも存在しないことを検出すると、伝送するＰＳがもうないことを判定する上位層に基づいて、遷移指示を開始しなくてもよい。

さらに別の実施形態では、（同報通信または他の方法を介して）いずれのタイマ値も、メッセージ内またはメッセージの中の情報要素内で、ＵＴＲＡＮから受信されなかった場合、ＵＥにおいてタイマ値を無限に設定するよりむしろ、ＵＥは、阻止タイマをゼロに設定するか、または代替として、タイマの任意の構成を削除し、代わりに、遷移指示を送信することを許容されてもよい。この場合、ＵＥは、遷移指示メッセージの中の原因を省略するか、または原因を添付することを禁止され得る。一実施形態では、信号伝達接続解放指示メッセージは、遷移指示の一例として使用される。

一実施形態では、遷移指示は、信号伝達接続解放指示手順を使用して伝えられる。信号伝達接続解放指示手順は、その信号伝達接続のうちの１つが解放されたことを示すために、ＵＥによって使用される。

具体的には、ＴＳ ２５．３３１の第８．１．１４．２項に従って、ＵＥは、特定のＣＮドメインに対する上層から信号伝達接続を解放する要求を受信すると、情報要素「ＣＮドメインアイデンティティ」において識別される特定のＣＮドメインに対する変数「ＥＳＴＡＢＬＩＳＨＥＤ＿ＳＩＧＮＡＬＬＩＮＧ＿ＣＯＮＮＥＣＴＩＯＮＳ」における信号伝達接続が存在するかどうかをチェックする。存在すれば、ＵＥは、信号伝達接続解放指示手順を開始してもよい。

阻止タイマ値が信号伝達されないか、あるいはＵＥに伝えられない場合、いずれの信号伝達接続解放指示原因も信号伝達接続解放指示メッセージの中で特定されない。当業者であれば、この代替実施形態で、タイマ値の欠如は、タイマ値を無限に設定させないことを理解するであろう。

ＵＴＲＡＮ側で、原因を伴わない信号伝達接続解放指示メッセージの受信時に、ＵＴＲＡＮは、上層に、識別されたＣＮドメインアイデンティティに対する信号伝達接続の解放を指示する。次いで、これは、確立された無線リソース制御接続の解放を開始してもよい。

別の代替実施形態の下で、ＵＴＲＡＮが、ＵＥに、タイマ値、例えば、情報要素「接続モードのＵＥタイマまたは制約」の中で（または、ＳＩＢ１、ＳＩＢ３、またはＳＩＢ４等のシステム情報を使用して、あるいは専用ＵＴＲＡＮモビリティ情報メッセージにより）阻止タイマＴ３ｘｘを信号伝達するか、または伝えると、以下に従って解放手順が発生する。第１に、ＵＥは、示された回線交換ドメイン接続があるかどうかをチェックすることができる。そのような接続は、変数「ＥＳＴＡＢＬＩＳＨＥＤ＿ＳＩＧＮＡＬＬＩＮＧ＿ＣＯＮＮＥＣＴＩＯＮＳ」において示されてもよい。いずれの回線交換ドメイン接続もない場合、長期間にわたってパケット交換ドメインデータが生じないことを上層が示すかどうかを判定する、第２のチェックが発生することができる。

いずれの回線交換ドメイン接続もなく、かついずれのパケット交換ドメインデータも長期間にわたって予期されない場合、ＵＥは、次に、タイマＴ３ｘｘが作動しているかどうかをチェックしてもよい。

タイマＴ３ｘｘが作動していない場合、ＵＥは、情報要素「ＣＮドメインアイデンティティ」をパケット交換（ＰＳ）ドメインに設定する。さらに、情報要素「信号伝達接続解放指示原因」は、「ＵＥがＰＳデータセッションの終了を要求した」に設定される。信号伝達接続解放指示メッセージは、ＡＭ ＲＬＣを使用して、ＤＣＣＨ上で伝送される。さらに、伝送後に、タイマＴ３ｘｘが起動される。

上記の手順は、上記の手順でＲＬＣによって確認されるような、信号伝達接続解放指示メッセージの配信成功時に終了する。この実施形態では、タイマＴ３ｘｘが作動している間に、またはタイマＴ３ｘｘが期限切れになるまで、ＵＥは、「ＵＥがＰＳデータセッションの終了を要求した」に設定された信号伝達接続解放指示原因とともに、信号伝達接続解放指示メッセージを送信することが阻止される。

Ｔ３ｘｘタイマが作動しているときに、長期間にわたって、さらなるパケット交換ドメインデータがないため、信号伝達接続解放指示手順が開始される場合、ＵＥは、Ｔ３ｘｘタイマの満了に対して手順を開始するかどうかを実施することに関与している。ＵＥ決定は、送信する後続の信号伝達接続解放指示または要求メッセージがあるかどうかの判定に基づいてもよく、もしあれば、ＵＥ決定は、本明細書で概説されるような手順を開始するために同じチェックのうちのいくつかまたは全てを再チェックするステップを含んでもよい。

ＵＴＲＡＮ側で、信号伝達接続解放指示メッセージが信号伝達接続解放指示原因を含まない場合、ＵＴＲＡＮは、上層からの信号伝達接続の解放を要求してもよく、次いで、上層は、信号伝達接続の解放を開始してもよい。一方で、受信される信号伝達接続解放指示メッセージが原因を含む場合、ＵＴＲＡＮは、信号伝達接続を解放するか、または、よりバッテリ効率の良い状態（例えば、ＣＥＬＬ＿ＦＡＣＨ、ＣＥＬＬ＿ＰＣＨ、ＵＲＡ＿ＰＣＨ、またはＩＤＬＥ＿モード）への状態遷移を開始してもよい。

上記の阻止期間は、ＵＥが遷移したい状態に基づいてもよい。例えば、阻止期間は、携帯電話が、他の状態／モードと対比した、いくつかのＲＲＣ状態／モードの最後の選好を示したかどうかにより、異なってもよい。例えば、それは、携帯電話が、Ｃｅｌｌ＿ＦＡＣＨ状態と対比した、またはＣｅｌｌ＿ＰＣＨ／ＵＲＡ ＰＣＨ状態と対比した、アイドルモードの選好を示した場合に、異なり得る。阻止期間がネットワークによって設定される場合では、これは、シナリオに応じて使用される、携帯電話に値の２つ（以上の）のセットを指示／送信する、ネットワークによって達成されてもよい。代替として、指示は、適切な阻止期間値のみが携帯電話に指示／信号伝達されるような方法で行うことができる。例えば、ＵＥがＣｅｌｌ＿ＰＣＨに遷移したい場合、ＵＥがアイドルに遷移したい場合とは異なる経過期間を設定することができる。

上記からの阻止期間は、携帯電話の現在のＲＲＣ状態／モード（例えば、Ｃｅｌｌ＿ＤＣＨ／Ｃｅｌｌ＿ＦＡＣＨ対Ｃｅｌｌ＿ＰＣＨ／ＵＲＡ＿ＰＣＨ、またはＣｅｌｌ＿ＤＣＨ対Ｃｅｌｌ＿ＦＡＣＨあるいはＣｅｌｌ＿ＰＣＨ／ＵＲＡ＿ＰＣＨ）に応じて、異なってもよい。

上記からの阻止期間は、ネットワークがすでに携帯電話からの選好ＲＲＣ状態情報に作用したかどうかに応じて、異なってもよい。そのような認識は、ネットワーク上で、または携帯電話側で起こってもよい。第１の場合において、これは、ネットワークによって携帯電話に指示／信号伝達される、阻止値に影響を及ぼしてもよい。第２の場合において、阻止期間値の異なるセットは、事前構成されるか、またはネットワークによって指示／信号伝達されてもよい。特定の場合として、ネットワークが携帯電話からの選好ＲＲＣ状態情報に作用した、例えば、ＵＥによって示された状態への状態遷移を開始した場合に、阻止期間／機能性が削減されるか、または取り消されてもよい。

上記からの阻止期間は、例えば、ネットワークの選好、特徴、能力、負荷、または容量に応じて、異なってもよい。ネットワークは、頻繁な遷移指示メッセージを受信することができる場合に、短い阻止期間を示してもよい。ネットワークは、頻繁な遷移指示メッセージを受信できない、またはしたくない場合に、長い阻止期間を示してもよい。ネットワークは、ＵＥが遷移指示メッセージを送信することができない特定の期間を示してもよい。特定の期間は、例えば、数値的に示されてもよい（すなわち、０秒、３０秒、１分、１分３０秒、２分、または無限）。０秒の阻止期間を受信するＵＥは、遅延なしで遷移指示を送信することができる。無限の阻止期間を受信するＵＥは、遷移指示を送信することができない。

阻止期間の代わりに、またはそれに加えて、時間枠あたりのメッセージの最大数（例えば、「１０分ごとにわずか１５のメッセージ」）が使用／特定されてもよい。

上記の阻止期間／時間枠あたりのメッセージの最大数の組み合わせが可能である。

一例として、本開示は、概して、ＵＴＲＡＮによるＵＥからのＲＲＣ接続要求メッセージの受信を記載する。ＲＲＣ接続要求メッセージを受信すると、ＵＴＲＡＮは、例えば、要求を受け入れ、ＵＥにＲＲＣ接続設定メッセージを送信する。ＲＲＣ接続設定は、タイマＴ３ｘｘとして知られる遷移阻止指示を含み得る。ＵＥによるＲＲＣ接続設定メッセージの受信時に、ＵＥは、例えば、以前に記憶された値を置き換えてタイマＴ３ｘｘの値を記憶するか、または、タイマＴ３ｘｘがＲＲＣ接続設定メッセージの中にない場合には、タイマの値を無限に設定する。いくつかの実施形態では、ＲＲＣ接続設定メッセージは、ＵＴＲＡＮが遷移阻止指示信号伝達をサポートすることをＵＥが知っていることを確実にするように、遷移阻止指示を含まなければならない。

一実施形態では、ＤＣＨ状態でのモビリティの間に、ＵＥが阻止タイマに対して、その現在記憶されている値を維持することが仮定される。阻止タイマが無限に設定される、いくつかの場合では、これは、ネットワークデータ非活動タイマが期限切れになること、およびネットワークがＵＥをＲＲＣ状態にすることをＵＥが待たなければならず、その場合、阻止タイマに対する新規の値を受信または判定できることを意味してもよい。阻止タイマがハンドオーバ前に無限以外のある値である、他の場合では、ＵＥがタイマ値を新規セルで示された値に更新することができるまで、この他の値が引き続き使用される。

場合によっては、阻止タイマおよび遷移指示（例えば、信号伝達接続解放指示）メッセージは、いくつかのネットワークの中、またはネットワーク内のいくつかのセルの中で実装されてもよい。モビリティの目的で、遷移指示または要求メッセージを送信する機能にサポートが利用可能ではない場合（特に、原因が使用される場合）、ＵＥは、メッセージを送信しないステップをデフォルトにするべきである。これは、不必要な伝送、および関連するネットワークリソースならびにバッテリリソースの無駄を回避する。

加えて、モビリティの目的で、ネットワーク内で使用される異なる業者のネットワーク機器は、ＵＥがセル間を移動するときに、ＵＥ上で更新される必要のある異なる阻止タイマを使用して、隣接するセルに至ってもよい。

１つの代替実施形態では、これは、全てのハンドオーバおよび関連ベアラ制御メッセージが阻止タイマＴ３ｘｘの値を含むことを定めることによって、取り扱われる。そのようなメッセージは、本明細書ではモビリティメッセージと呼ばれる。これは、ＵＥがセル間を移動するときに新規の阻止タイマ値を受信できるようにする。それはまた、これらのモビリティメッセージが阻止タイマ値を含有しない場合に、ＵＥが阻止タイマのデフォルトタイマ値を設定できるようにもする。理解されるように、いずれの阻止タイマ値もモビリティメッセージの中で受信されなかった場合、これは、セルが急速休眠に有効ではないことを示す。

遷移指示手順の別の実施例として、これ以上ＰＳドメインデータを転送する必要がないと判定したことをＵＴＲＡＮに示すために、データ転送完了指示手順がＵＥによって使用されてもよい。上記で説明される実施例に関連して、タイマＴ３ｘｘが作動している場合、ＵＥは、タイマＴ３ｘｘが期限切れになる前にデータ転送完了指示メッセージを送信しない。

データ転送完了指示手順は、ＲＲＣまたは上層が長期間にわたってこれ以上ＰＳドメインデータを持たないという指示で開始する。ＣＳドメイン接続が確立された信号伝達接続（ESTABLISHED＿ＳＩＧＮＡＬＬＩＮＧ＿ＣＯＮＮＥＣＴＩＯＮＳ）という変数において
示された場合、またはタイマＴ３ｘｘが無限に設定された場合に、手順が終了する。そうでなければ、タイマＴ３ｘｘが作動していない（すなわち、期限切れになった）か、または０秒に設定された場合に、ＡＭ ＲＬＣまたはＤＣＣＨを使用して、データ転送完了指示メッセージが下層に提出され、その後、メッセージが下層に配信されると、タイマＴ３ｘｘが起動またはリセットされる。

ＵＴＲＡＮは、データ転送完了指示の受信時に、よりバッテリ効率の良いＲＲＣ状態またはアイドルモードへのＵＥ遷移を開始することを決定してもよい。

ＵＥは、タイマＴ３ｘｘが作動している間に、データ転送完了指示メッセージを送信しないものである。

本開示は、構成メッセージに遷移阻止指示を含むステップと、遷移阻止指示を伴う構成メッセージをユーザ機器に送信するステップとを含む、ユーザ機器による遷移指示メッセージの使用を制御する方法を提供する。

本開示はさらに、ユーザ機器による遷移指示メッセージの使用を制御するように構成される、ネットワーク要素であって、構成メッセージに遷移阻止指示を含み、遷移阻止指示を伴う構成メッセージをユーザ機器に送信するように構成される、ネットワーク要素を提供する。

本開示はさらに、ユーザ機器（ＵＥ）において遷移指示を送信するための方法であって、ネットワーク要素から受信された遷移阻止指示に従ってタイマを設定するステップと、データ転送が完了したことを検出するステップと、タイマが作動していないことを検出すると遷移指示を送信するステップとを含む、方法を提供する。

本開示は、なおもさらに、遷移指示を送信するように構成される、ユーザ機器であって、ネットワーク要素から受信された遷移阻止指示に従ってタイマを設定し、データ転送が完了したことを検出し、タイマが作動していないことを検出すると遷移指示を送信するように構成される、ユーザ機器を提供する。

本開示は、図面を参照すると、より良好に理解されるであろう。
例えば、本発明は以下の項目を提供する。
（項目１）
ユーザ機器による遷移指示メッセージの使用を制御する方法であって、
構成メッセージに遷移阻止指示を含むことと、
該遷移阻止指示を有する該構成メッセージを該ユーザ機器に送信することと
を含む、方法。
（項目２）
上記遷移阻止指示は、情報要素の一部である、項目１に記載の方法。
（項目３）
上記遷移阻止指示は、阻止タイマ値を含む、項目１または項目２に記載の方法。
（項目４）
上記阻止タイマ値は、所定の値のリストから選択される、項目３に記載の方法。
（項目５）
上記リストは、上記ユーザ機器において阻止タイマを適用する必要がないことを示す値を含む、項目４に記載の方法。
（項目６）
阻止タイマを適用する必要がないことを示す上記値は、ゼロである、項目５に記載の方法。
（項目７）
上記構成メッセージは、ＲＲＣ接続要求メッセージ、ＲＲＣ接続設定メッセージ、ＲＲＣ接続解放メッセージ、無線ベアラ設定メッセージ、システム情報同報通信メッセージ、システム情報ブロック（ＳＩＢ）メッセージ、アクティブセット更新メッセージ、セル更新確認メッセージ、ＵＴＲＡＮコマンドへのハンドオーバメッセージ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、およびＵＴＲＡＮモビリティ情報メッセージから成る群より選択される、項目１〜６のうちのいずれか１項に記載の方法。
（項目８）
上記送信することは、新規セルまたはネットワークが上記ユーザ機器によって取得されると行われる、項目１に記載の方法。
（項目９）
上記送信することは、上記ユーザ機器からの要求の受信に応じる、項目１〜８のうちのいずれか１項に記載の方法。
（項目１０）
ユーザ機器による遷移指示メッセージの使用を制御するように構成される、ネットワーク要素であって、
構成メッセージに遷移阻止指示を含み、
該遷移阻止指示を伴う該構成メッセージを該ユーザ機器に送信するように
構成される、ネットワーク要素。
（項目１１）
上記遷移阻止指示は、情報要素の一部である、項目１０に記載のネットワーク要素。
（項目１２）
上記遷移阻止指示は、阻止タイマ値を含む、項目１０または項目１１に記載のネットワーク要素。
（項目１３）
上記阻止タイマ値は、所定の値のリストから選択される、項目１２に記載のネットワーク要素。
（項目１４）
上記リストは、上記ユーザ機器において阻止タイマを適用する必要がないことを示す値を含む、項目１３に記載のネットワーク要素。
（項目１５）
阻止タイマを適用する必要がないことを示す上記値は、ゼロである、項目１４に記載のネットワーク要素。
（項目１６）
上記構成メッセージは、ＲＲＣ接続要求メッセージ、ＲＲＣ接続設定メッセージ、ＲＲＣ接続解放メッセージ、無線ベアラ設定メッセージ、システム情報同報通信メッセージ、システム情報ブロック（ＳＩＢ）メッセージ、アクティブセット更新メッセージ、セル更新確認メッセージ、ＵＴＲＡＮコマンドへのハンドオーバメッセージ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、およびＵＴＲＡＮモビリティ情報メッセージから成る群より選択される、項目１０〜１５のうちのいずれか１項に記載のネットワーク要素。
（項目１７）
ユーザ機器（ＵＥ）において遷移指示を送信するための方法であって、
ネットワーク要素から受信された遷移阻止指示に従ってタイマを設定することと、
データ転送が完了したことを検出することと、
該タイマが作動していないことを検出すると該遷移指示を送信することと
を含む、方法。
（項目１８）
上記遷移阻止指示は、阻止タイマ値である、項目１７に記載の方法。
（項目１９）
上記遷移指示の上記送信は、上記タイマが期限切れになったことを検出すると行われる、項目１７に記載の方法。
（項目２０）
上記タイマは、任意の遷移指示の上記送信時に起動される、項目１７に記載の方法。
（項目２１）
上記遷移阻止指示は、構成メッセージ中で受信される、項目１７に記載の方法。
（項目２２）
構成メッセージは、モビリティメッセージである、項目２１に記載の方法。
（項目２３）
上記構成メッセージは、ＲＲＣ接続要求メッセージ、ＲＲＣ接続設定メッセージ、ＲＲＣ接続解放メッセージ、無線ベアラ設定メッセージ、システム情報同報通信メッセージ、システム情報ブロック（ＳＩＢ）メッセージ、アクティブセット更新メッセージ、セル更新確認メッセージ、ＵＴＲＡＮコマンドへのハンドオーバメッセージ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、およびＵＴＲＡＮモビリティ情報メッセージから成る群より選択される、項目２１に記載の方法。
（項目２４）
上記遷移指示は、パケット交換データが長期間にわたってこれ以上予期されないことを示す、項目１７に記載の方法。
（項目２５）
上記遷移指示は、信号伝達接続解放指示メッセージである、項目１７に記載の方法。
（項目２６）
上記遷移指示は、データ転送完了指示メッセージである、項目１７に記載の方法。
（項目２７）
遷移指示を送信するように構成される、ユーザ機器であって、
ネットワーク要素から受信された遷移阻止指示に従ってタイマを設定し、
データ転送が完了したことを検出し、
該タイマが作動していないことを検出すると該遷移指示を送信するように、
構成される、ユーザ機器。
（項目２８）
上記遷移阻止指示は、阻止タイマ値である、項目２７に記載のユーザ機器。
（項目２９）
上記遷移指示の上記送信は、上記タイマが期限切れになったことを検出すると行われる、項目２７に記載のユーザ機器。
（項目３０）
上記タイマは、任意の遷移指示の上記送信時に起動される、項目２７に記載のユーザ機器。
（項目３１）
上記遷移阻止指示は、構成メッセージ中で受信される、項目２７に記載のユーザ機器。
（項目３２）
構成メッセージは、モビリティメッセージである、項目３１に記載のユーザ機器。
（項目３３）
上記構成メッセージは、ＲＲＣ接続要求メッセージ、ＲＲＣ接続設定メッセージ、ＲＲＣ接続解放メッセージ、無線ベアラ設定メッセージ、システム情報同報通信メッセージ、システム情報ブロック（ＳＩＢ）メッセージ、アクティブセット更新メッセージ、セル更新確認メッセージ、ＵＴＲＡＮコマンドへのハンドオーバメッセージ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、およびＵＴＲＡＮモビリティ情報メッセージから成る群より選択される、項目３１に記載のユーザ機器。
（項目３４）
上記遷移指示は、パケット交換データが長期間にわたってこれ以上予期されないことを示す、項目２７に記載のユーザ機器。
（項目３５）
上記遷移指示は、信号伝達接続解放指示メッセージである、項目２７に記載のユーザ機器。
（項目３６）
上記遷移指示は、データ転送完了指示メッセージである、項目２７に記載のユーザ機器。

図１は、ＲＲＣ状態および遷移を示す、ブロック図である。 図２は、種々のＵＭＴＳセルおよびＵＲＡを示す、ＵＭＴＳネットワークの概略図である。 図３は、ＲＲＣ接続設定における種々の段階を示す、ブロック図である。 図４Ａは、現在の方法に従ってＵＴＲＡＮによって開始される、ＣＥＬＬ＿ＤＣＨ接続モード状態とアイドルモードとの間の例示的遷移のブロック図である。 図４Ｂは、信号伝達解放指示を利用する、ＣＥＬＬ＿ＤＣＨ状態接続モードとアイドルモードとの間の例示的遷移を示す、ブロック図である。 図５Ａは、ＵＴＲＡＮによって開始される、ＣＥＬＬ＿ＤＣＨ非活動状態、ＣＥＬＬ＿ＦＡＣＨ非活動状態、アイドルモードへの例示的遷移を示す、ブロック図である。 図５Ｂは、信号伝達解放指示を利用する、ＣＥＬＬ＿ＤＣＨ非活動状態とアイドルモードとの間の例示的遷移を示す、ブロック図である。 図６は、ＵＭＴＳプロトコルスタックのブロック図である。 図７は、本方法と関連して使用することができる、例示的ＵＥである。 図８は、本方法およびシステムと関連して使用するための例示ネットワークである。 図９は、ＵＥにおいて信号伝達接続解放指示の原因を追加するステップを示す、フロー図である。 図１０は、原因を有する信号伝達接続解放指示の受信時にＵＥによって取られるステップを示す、フロー図である。 図１１は、複数の同時パケットデータ通信サービスセッションがＵＥに提供される、図８に示されたネットワークの例示的動作中の例示的な論理および物理チャネル割り当てのグラフ表示である。 図１２は、本開示の実施形態に従って、個々のパケットデータサービスの無線リソースを解放する無線リソース解放機能を提供する、ＵＥおよびネットワーク要素の機能的ブロック図を図示する。 図１３は、それによりＰＤＰコンテキストへの無線リソース割り当てを解放するように、本開示の実施形態の操作に従って生成される信号伝達を表す、メッセージシーケンス図を図示する。 図１４は、それにより無線リソース割り当てを解放するように、本開示の実施形態の操作に従って生成される信号伝達を同様に表す、図１３に示された図と同様のメッセージシーケンス図を図示する。 図１５は、本開示の実施形態の過程を表す、過程図を図示する。 図１６は、本開示の実施形態の操作の方法を図示する、方法フロー図を図示する。 図１７は、本開示の実施形態の操作の方法を同様に図示する、方法フロー図を図示する。 図１８は、遷移決定がネットワーク要素において無線リソースプロファイルに基づき行われる、実施形態の方法フロー図を図示する。 図１９は、図１８の方法とともに使用されることが可能なネットワーク要素の簡略化したブロック図を図示する。 図２０は、遷移指示または要求メッセージの送信のためのデータフロー図を図示する。 図２１は、ＵＥにおいて阻止タイマ値を設定するためのデータフロー図を図示する。

ここで図１を参照する。図１は、ＵＭＴＳネットワーク内のプロトコルスタックの無線リソース制御部分に対する種々のモードおよび状態を示す、ブロック図である。具体的には、ＲＲＣは、ＲＲＣアイドルモード１１０またはＲＲＣ接続モード１２０のいずれかとなり得る。

当業者によって理解されるように、ＵＭＴＳネットワークは、２つ地上ネットワークセグメントから成る。これらは、（図８に図示されるような）コアネットワーク（ＣＮ）およびユニバーサル地上波無線アクセスネットワーク（ＵＴＲＡＮ）である。コアネットワークが、データ呼び出しの切替およびルーティング、ならびに外部ネットワークへのデータ接続に関与している一方で、ＵＴＲＡＮは、全ての無線関連機能を取り扱う。

アイドルモード１１０では、ＵＥは、データがＵＥとネットワークとの間で交換される必要があるときはいつでも、ＲＲＣ接続を要求して無線リソースを設定しなければならない。これは、データを送信するように接続に要求するＵＥ上のアプリケーションの結果として、または、ＵＴＲＡＮまたはＳＧＳＮがプッシュサーバ等の外部データネットワークからデータを受信するようにＵＥを呼び出したかどうかを示すように、ＵＥがページングチャネルを監視する結果としてのものとなり得る。加えて、ＵＥはまた、ロケーションエリア更新等のモビリティ管理信号伝達メッセージを送信する必要があるときはいつでも、ＲＲＣ接続を要求する。

いったんＵＥが無線接続を確立するようにＵＴＲＡＮに要求を送信すると、ＵＴＲＡＮは、ＲＲＣ接続がなる状態を選択する。具体的には、ＲＲＣ接続モード１２０は、４つの別個の状態を含む。これらは、ＣＥＬＬ＿ＤＣＨ状態１２２、ＣＥＬＬ＿ＦＡＣＨ状態１２４、ＣＥＬＬ＿ＰＣＨ状態１２６、およびＵＲＡ＿ＰＣＨ状態１２８である。

アイドルモード１１０から、ＵＥは自律的にＣＥＬＬ＿ＦＡＣＨ状態１２４に遷移し、その場合、その初期データ転送を行い、その後、ネットワークがどのＲＣＣ接続状態を継続的なデータ転送に使用するかを判定する。これは、ＵＥをセル専用チャネル（ＣＥＬＬ＿ＤＣＨ）状態１２２にするか、またはＵＥをセル順方向アクセスチャネル（ＣＥＬＬ＿ＦＡＣＨ）状態１２４に保つネットワークを含んでもよい。

ＣＥＬＬ＿ＤＣＨ状態１２２では、データを交換するアップリンクおよびダウンリンクの両方のために、専用チャネルがＵＥに割り当てられる。この状態は、専用物理チャネルがＵＥに割り当てられるため、典型的に、ＵＥから最も多くのバッテリ電力を必要とする。

代替として、ＵＴＲＡＮは、ＵＥをＣＥＬＬ＿ＦＡＣＨ状態１２４で維持することができる。ＣＥＬＬ＿ＦＡＣＨ状態では、いずれのチャネルもＵＥに割り当てられない。その代わり、少量の集中的データにおける信号伝達を送信するために共通チャネルが使用される。しかしながら、ＵＥは依然としてＦＡＣＨを継続的に監視しなければならず、したがって、ＣＥＬＬ＿ＰＣＨ状態、ＵＲＡ＿ＰＣＨ状態、およびアイドルモードよりも多くのバッテリ電力を消費する。

ＲＲＣ接続モード１２０内で、ＲＲＣ状態は、ＵＴＲＡＮの判断で変更することができる。具体的には、データ非活動が特定量の時間またはデータに対して検出されるか、または、ある閾値を下回るデータスループットが検出された場合に、ＵＴＲＡＮは、ＲＲＣ状態を、ＣＥＬＬ＿ＤＣＨ状態１２２からＣＥＬＬ＿ＦＡＣＨ状態１２４、ＣＥＬＬ＿ＰＣＨ状態１２６、またはＵＲＡ＿ＰＣＨ状態１２８にしてもよい。同様に、ペイロードがある閾値を上回ると検出された場合に、ＲＲＣ状態をＣＥＬＬ＿ＦＡＣＨ状態１２４からＣＥＬＬ＿ＤＣＨ状態１２２にすることができる。

ＣＥＬＬ＿ＦＡＣＨ状態１２４から、データ非活動がいくつかのネットワーク内で所定の時間にわたって検出された場合、ＵＴＲＡＮは、ＲＲＣ状態をＣＥＬＬ＿ＦＡＣＨ状態１２４からページングチャネル（ＰＣＨ）状態にすることができる。これは、ＣＥＬＬ＿ＰＣＨ状態１２６からＵＲＡ＿ＰＣＨ状態１２８のいずれか一方となり得る。

ＣＥＬＬ＿ＰＣＨ状態１２６またはＵＲＡ＿ＰＣＨ状態１２８から、ＵＥは、専用チャネルを要求する更新手順を開始するために、ＣＥＬＬ＿ＦＡＣＨ状態１２４とならなければならない。これは、ＵＥが制御する唯一の状態遷移である。

アイドルモード１１０、ならびにＣＥＬＬ＿ＰＣＨ状態１２６およびＵＲＡ＿ＰＣＨ状態１２８は、ページングインジケータチャネル（ＰＩＣＨ）を介して同報通信メッセージおよびページを監視するために、不連続受信サイクル（ＤＲＸ）を使用する。いずれのアップリンク活動も可能ではない。

ＣＥＬＬ＿ＰＣＨ状態１２６とＵＲＡ＿ＰＣＨ状態１２８との間の違いは、ＵＥの現在のＵＴＲＡＮ登録エリア（ＵＲＡ）が、現在のセルに存在するＵＲＡアイデンティティのリストの中にない場合に、ＵＲＡ＿ＰＣＨ状態１２８がＵＲＡ更新手順しか誘起しないことである。具体的には、図２を参照する。図２は、種々のＵＭＴＳセル２１０、２１２、および２１４の説明図を示す。これらのセルの全ては、ＣＥＬＬ＿ＰＣＨ状態に再選択された場合に、セル更新手順を必要とする。しかしながら、ＵＴＲＡＮ登録エリアにおいて、それぞれが同じＵＴＲＡＮ登録エリア（ＵＲＡ）３２０内に入り、したがって、ＵＲＡ更新手順は、ＵＲＡ＿ＰＣＨモードであるときに２１０、２１２、および２１４の間で移動すると誘発されない。

図２で見られるように、他のセル２１８は、ＵＲＡ３２０の外側にあり、別個のＵＲＡの一部となり得るか、またはいずれのＵＲＡの一部にもなり得ない。

当業者によって認識されるように、バッテリ寿命の観点から、アイドル状態は、上記の状態と比較して最低バッテリ使用量を提供する。具体的には、ＵＥは、間隔を置いてのみ、ページングチャネルを監視する必要があるために、無線は継続的にオンである必要はないが、その代わり、周期的に起動する。これに対するトレードオフは、データを送信する待ち時間である。しかしながら、この待ち時間が長過ぎなければ、アイドルモードであること、およびバッテリ電力を節約することの利点は、接続待ち時間の不利点を上回る。

再度、図１を参照する。種々のＵＭＴＳ基礎構造ベンダは、種々の基準に基づいて、状態１２２、１２４、１２６、および１２８の間で移動させる。これらの基準は、とりわけ、信号伝達の節約または無線リソースの節約に関するネットワーク操作者の選好となり得る。例示的な基礎構造を以下で概説する。

第１の例示的基礎構造では、ＣＥＬＬ＿ＦＡＣＨ状態でアクセスを開始した直後に、ＲＲＣは、アイドルモードとＣｅｌｌ＿ＤＣＨ状態との間で移動する。Ｃｅｌｌ＿ＤＣＨ状態では、２秒間の非活動が検出された場合、ＲＲＣ状態はＣｅｌｌ＿ＦＡＣＨ状態１２４に変化する。もし、Ｃｅｌｌ＿ＦＡＣＨ状態１２４で、１０秒間の非活動が検出された場合は、ＲＲＣ状態がＣｅｌｌ＿ＰＣＨ状態１２６に変化する。Ｃｅｌｌ＿ＰＣＨ状態１２６での４５分間の非活動は、ＲＲＣ状態をアイドルモード１１０に戻らせる。

第２の例示的基礎構造では、ＲＲＣ遷移は、ペイロード閾値に応じて、アイドルモード１１０と接続モード１２０との間で発生することができる。第２の基礎構造では、ペイロードがある閾値を下回る場合に、ＵＴＲＡＮはＲＲＣ状態をＣＥＬＬ＿ＦＡＣＨ状態１２４にする。逆に、データペイロードがあるペイロード閾値を上回る場合に、ＵＴＲＡＮはＲＲＣ状態をＣＥＬＬ＿ＤＣＨ状態１２２にする。第２の基礎構造では、２分間の非活動がＣＥＬＬ＿ＤＣＨ状態１２２で検出されると、ＵＴＲＡＮはＲＲＣ状態をＣＥＬＬ＿ＦＡＣＨ状態１２４にする。ＣＥＬＬ＿ＦＡＣＨ状態１２４での５分間の非活動後に、ＵＴＲＡＮはＲＲＣ状態をＣＥＬＬ＿ＰＣＨ状態１２６にする。ＣＥＬＬ＿ＰＣＨ状態１２６では、アイドルモード１１０に戻る前に、２時間の非活動が必要とされる。

第３の例示的基礎構造では、アイドルモード１１０と接続モード１２０との間の移動は、常にＣＥＬＬ＿ＤＣＨ状態１２２に対するものである。ＣＥＬＬ＿ＤＣＨ状態１２２での５秒間の非活動後に、ＵＴＲＡＮはＲＲＣ状態をＣＥＬＬ＿ＦＡＣＨ状態１２４にする。ＣＥＬＬ＿ＦＡＣＨ状態１２４での３０秒間の非活動は、アイドルモード１１０に戻る移動をもたらす。

第４の例示的基礎構造では、ＲＲＣは、アイドルモードから接続モードへと、ＣＥＬＬ＿ＤＣＨ状態１２２に直接遷移する。第４の例示的基礎構造では、ＣＥＬＬ＿ＤＣＨ状態１２２は、２つの構成を含む。第１の構成は、データ転送速度を有する構成を含み、第２の構成は、より低いデータ転送速度を含むが、依然としてＣＥＬＬ＿ＤＣＨ状態内である。第４の例示的基礎構造では、ＲＲＣは、アイドルモード１１０から高データ転送速度のＣＥＬＬ＿ＤＣＨサブ状態に直接遷移する。１０秒間の非活動後に、ＲＲＣ状態は、低データ天測速度のＣＥＬＬ＿ＤＣＨサブ状態に遷移する。ＣＥＬＬ＿ＤＣＨ状態１２２の低データサブ状態からの１７秒間の非活動は、ＲＲＣ状態をアイドルモード１１０に変化させる。

上記の４つの例示的基礎構造は、種々のＵＭＴＳ基礎構造ベンダがどのように状態を実装しているかを示す。当業者によって理解されるように、それぞれの場合において、実データ（Ｅメール等）を交換するのに費やされる時間は、ＣＥＬＬ＿ＤＣＨまたはＣＥＬＬ＿ＦＡＣＨ状態でとどまるために必要とされる時間と比較して、有意に短い。これは、不必要なカレントドレインを引き起こし、ＵＭＴＳ等のより新しい世代のネットワークにおけるユーザ体験を、ＧＰＲＳ等の以前の世代のネットワークよりも不良にする。

さらに、ＣＥＬＬ＿ＰＣＨ状態１２６が、バッテリ寿命の観点からＣＥＬＬ＿ＦＡＣＨ状態１２４よりも最適であるが、ＣＥＬＬ＿ＰＣＨ状態１２６でのＤＲＸサイクルは、典型的に、アイドルモード１１０よりも低い値に設定される。結果として、ＵＥは、アイドルモード１１０よりもＣＥＬＬ＿ＰＣＨ状態１２６で頻繁に起動する必要がある。

アイドル状態１１０のＤＲＸサイクルと同様のＤＲＸサイクルを伴うＵＲＡ＿ＰＣＨ状態１２８は、おそらく、バッテリ寿命と接続のための待ち時間との間の最適なトレードアップである。しかしながら、ＵＲＡ＿ＰＣＨ状態１２８は、現在ＵＴＲＡＮでは実装されていない。したがって、場合によっては、バッテリ寿命の観点から、アプリケーションがデータ交換を終了した後にできるだけ早急に、アイドルモードに早急に遷移することが望ましい。

ここで図３を参照する。アイドルモードから接続モードに遷移するときに、種々の信号伝達およびデータ接続を行う必要がある。図３を参照すると、行われる最初の事項は、ＲＲＣ接続設定３１０である。上記で示されるように、このＲＲＣ接続設定３１０は、ＵＴＲＡＮによってしか解除することができない。

いったんＲＲＣ接続設定３１０が達成されると、信号伝達接続設定３１２が開始される。

いったん信号伝達接続設定３１２が終了されると、暗号化および完全性設定３１４が開始される。これの完了時に、無線ベアラ設定３１６が達成される。この時点で、ＵＥとＵＴＲＡＮとの間でデータを交換することができる。

接続の解除は、一般に逆の順序で、同様に達成される。無線ベアラ設定３１６が取り払われ、次いで、ＲＲＣ接続設定３１０が取り払われる。この時点で、ＲＲＣは、図１に図示されるようなアイドルモード１１０になる。

現在の３ＧＰＰ仕様書は、ＵＥがＲＲＣ接続を解放すること、またはＲＲＣ状態に対するその選好を示すことを許容しないが、ＵＥは、依然として、パケット交換アプリケーションによって使用されるパケット交換（ＰＳ）ドメイン等の特定されたコアネットワークドメインに対する信号伝達接続の終結を示すことができる。３ＧＰＰ ＴＳ ２５．３３１の第８．１．１４．１項によれば、その信号伝達接続のうちの１つが解放されたことをＵＴＲＡＮに示すために、信号伝達接続解放指示手順がＵＥによって使用される。この手順は、順に、ＲＲＣ接続解放手順を開始してもよい。

したがって、現在の３ＧＰＰ仕様書内にとどまって、信号伝達接続設定３１２の解除時に信号伝達接続解放が開始されてもよい。それは、信号伝達接続設定３１２を解除するＵＥの能力内であり、これは順に、仕様書に従って、ＲＲＣ接続解放を開始「してもよい」。

当業者によって開始されるように、信号伝達接続設定３１２が解除された場合、ＵＴＲＡＮはまた、信号伝達接続設定３１２が解除された後に、暗号化および完全性設定３１４、ならびに無線ベアラ設定３１６を整理する必要もある。

信号伝達接続設定３１２が解除された場合、ＲＲＣ接続設定は、典型的には、いずれのＣＳ接続もアクティブではない場合に、現在のベンダ基礎構造のために、ネットワークによって停止させられる。

上述の具体的な遷移指示例のうちの１つにこれを使用して、ＵＥは、データの交換が終了したことを判定し、例えば、ＵＥソフトウェアの「接続マネージャ」構成要素に、データの交換が完了したという指示が提供された場合、接続マネージャは、信号伝達設定３１２を解除するか否かを判定してもよい。例えば、デバイス上のＥメールアプリケーションは、Ｅメールがプッシュサーバによって確かに受信されたというプッシュＥメールサーバからの確認が受信されたという指示を送信する。接続マネージャは、一実施形態では、全ての既存のアプリケーション、関連ＰＤＰコンテキスト、関連ＰＳ無線リソース、および関連回線交換（ＣＳ）無線ベアラを追跡することができる。他の実施形態では、ネットワーク要素（例えば、ＵＴＲＡＮ）が、既存のアプリケーション、関連ＰＤＰコンテキスト、ＱｏＳ、関連ＰＳ無線リソース、および関連ＣＳ無線ベアラを追跡することができる。アプリケーションが本当にデータ交換を終了し、「終了」指示が送信された後でもＲＣＣ接続をもはや必要としないことを確実にするように、ＵＥまたはネットワーク要素のうちのいずれかにおいて遅延を導入することができる。この遅延は、アプリケーションまたはＵＥと関連付けられた非活動タイムアウトと同等にすることができる。各アプリケーションは、独自の非活動タイムアウトを有することができ、したがって、遅延は、アプリケーションタイムアウトの全ての複合物となり得る。例えば、Ｅメールアプリケーションは、５秒間の非活動タイムアウトを有することができるが、アクティブブラウザアプリケーションは、６０秒間のタイムアウトを有することができる。阻止期間タイマはさらに、遷移指示の送信を遅延させることができる。アクティブアプリケーションからの全てのそのような指示の複合状態、ならびにいくつかの実施形態での無線リソースプロファイルおよび／または阻止期間タイマ遅延に基づいて、ＵＥソフトウェアは、適切なコアネットワーク（例えば、ＰＳドメイン）に対する（例えば、信号伝達接続解放指示または状態変更要求のための）遷移指示を送信する前に、どれだけ待つべきか、または待たなければならないかを決定する。ネットワーク要素において遅延が実施された場合、要素は、ＵＥに遷移するかどうか、およびどのようにＵＥに遷移するかの判定を行うが、遅延がその経過をたどった後にしか遷移を操作しない。

非活動タイムアウトは、トラフィックパターン履歴および／またはアプリケーションプロファイルに基づいて動的にすることができる。

ネットワーク要素がＵＥをアイドルモード１１０に遷移する場合、それは図１に図示されるようなＲＲＣ接続モード１２０の任意の段階で起こり得るが、ネットワーク要素は、ＲＲＣ接続を解放し、ＵＥを図１に図示されるようなアイドルモード１１０にする。これはまた、ＵＥが音声電話中にあらゆるパケットデータサービスを行っているときにも適用可能である。この場合、ネットワークは、ＰＳドメイン信号伝達接続のみを解放することを選択し、ＣＳドメイン信号伝達接続を維持してもよく、または代替として、何も解放しないことを選択し、代わりに、ＰＳおよびＣＳドメインの両方への信号伝達接続を維持してもよい。

さらなる実施形態では、指示の理由をＵＴＲＡＮに示す遷移指示に、原因を追加することができる。好ましい実施形態では、原因は、異常な状態が指示を引き起こしたと言う指示、または要求された遷移の結果として指示がＵＥによって開始されたという指示となり得る。他の正常な（すなわち、異常ではない）トランザクションもまた、遷移指示の送信をもたらすことができる。

さらなる好ましい実施形態では、種々のタイムアウトが、異常な状態に対して遷移指示を送信させることができる。以下のタイマの実施例は包括的ではなく、他のタイマまたは異常な状態が可能である。３ＧＰＰ ＴＳ ２４．００８の１０．２．４７は、タイマＴ３３１０を以下のように特定する。

このタイマは、添付失敗を示すために使用される。添付の失敗は、ネットワークの結果となり得るか、または衝突あるいは不良な無線周波数（ＲＦ）等のＲＦの問題となり得る。

添付試行は、複数回発生することができ、添付失敗は、所定数の失敗または明示的拒絶のいずれか一方に起因する。

３ＧＰＰの１０．２．４７の第２のタイマは、以下のように特定されるタイマＴ３３３０である。

このタイマは、ルーティングエリア更新失敗を示すために使用される。タイマの満了時に、さらなるルーティングアリア更新を複数回要求することができ、ルーティングエリア更新失敗は、所定数の失敗または明示的拒絶のいずれか一方に起因する。

３ＧＰＰの１０．２．４７の第３のタイマは、以下のように特定されるタイマＴ３３４０である。

このタイマは、ＧＭＭサービス要求失敗を示すために使用される。タイマの満了時に、さらなるＧＭＭサービス要求を複数回開始することができ、ＧＭＭサービス要求失敗は、所定数の失敗または明示的拒絶のいずれか一方に起因する。

したがって、異常な状態およびＵＥによる解放に限定された遷移指示原因の代わりに、遷移指示原因は、どのタイマが異常な状態のために失敗したかについての情報をさらに含むことができる。信号伝達接続解放指示が遷移指示として使用される、具体的実施例では、指示を以下のように構造化することができる。

このメッセージは、既存の信号伝達接続を解放する要求をＵＴＲＡＮに示すために、ＵＥによって使用される。信号伝達接続解放指示の追加は、ＵＴＲＡＮまたは他のネットワーク要素が、信号伝達接続解放指示の原因、それが異常な状態によるものであったかどうか、および異常な状態がどのようなものであったかどうかを受信することを可能にする。信号伝達接続解放指示の受信に基づいて、ＲＲＣ接続解放手順は、順に、ＵＴＲＡＮにおいて開始されることが許容される。

この実施例の１つの実施において、ＵＥは、特定のＣＮ（コアネットワーク）ドメインに対する上層から、信号伝達接続を解放または中止する要求を受信すると、例えば、ＩＥ（情報要素）「ＣＮドメインアイデンティティ」で識別される特定のＣＮドメインに対して、変数「ＥＳＴＡＢＬＩＳＨＥＤ＿ＳＩＧＮＡＬＬＩＮＧ＿ＣＯＮＮＥＣＴＩＯＮＳ」が存在する場合に、信号伝達接続解放指示手順を開始する。変数がいずれの既存の信号伝達接続も識別しなければ、その特定のＣＮドメインに対する信号伝達接続の任意の継続中の確立が別の方式で中止される。Ｃｅｌｌ＿ＰＣＨまたはＵＲＡ＿ＰＣＨ状態での信号伝達接続解放指示手順の開始時に、ＵＥは、原因「アップリンクデータ伝送」を使用して、セル更新手順を行う。セル更新手順の完了が成功すると、ＵＥは、次に起こる信号伝達接続解放指示手順を続ける。

すなわち、ＵＥは、情報要素（ＩＥ）「ＣＮドメインアイデンティティ」を上位論理層によって示される値に設定する。ＩＥの値は、上層が行っているその関連信号伝達接続が解放される、ＣＮドメインを示す。ＣＮドメインアイデンティティがＰＳドメインに設定された場合、および上層がこの要求を開始する原因を示す場合には、ＩＥ「信号伝達解放指示原因」が、それに応じて設定される。ＵＥはさらに、変数「ＥＳＴＡＢＬＩＳＨＥＤ＿ＳＩＧＮＡＬＬＩＮＧ＿ＣＯＮＮＥＣＴＩＯＮＳ」から上層によって示されたアイデンティティとの信号伝達接続を除去する。ＵＥは、例えば、認知モード無線リンク制御（ＡＭ ＲＬＣ）を使用する専用制御チャネル（ＤＣＣＨ）上で、信号伝達接続解放指示メッセージを伝送する。ＲＬＣによる解放指示メッセージの配信成功の確認時に、手順が終了する。

ＩＥ「信号伝達接続解放指示原因」も、本開示の実施形態に従って使用される。解放原因は、例えば、既存のメッセージ定義と整合される。上層解放原因メッセージは、例えば、以下のように構造化される。

この実施例では、Ｔ３３１０、Ｔ３３０、およびＴ３３４０満了は、以前に識別された、対応する番号のタイマの期限切れに対応する。原因値は、１つの実施では、アイドル遷移に対する選好のＵＥ指示を除去し、状態遷移時に決定するＵＴＲＡＮを提供するように、「ＵＥが要求したアイドル遷移」よりもむしろ「ＵＥが要求したＰＳデータセッション終了」として設定可能であるが、予期された結果は、原因値によって識別されるものに対応する。信号伝達接続解放指示の拡張は、好ましくは、非臨界拡張であるが、必ずしもそうではない。

ここで図９を参照する。図９は、種々のドメイン（例えば、ＰＳまたはＣＳ）に対する信号伝達接続解放指示を送信するか否かを監視する例示的ＵＥのフロー図である。過程は、ステップ９１０で開始する。

ＵＥは、異常な状態が存在するかどうかを確認するようにチェックする、９１２に遷移する。そのような異常な状態は、上記で説明されるようなタイマＴ３３１０、タイマＴ３３２０、またはタイマＴ３３４０の期限切れを含むことができる。これらのタイマがある所定の回数で満了する場合、またはこれらのタイマのうちのいずれかの満了に基づいて明示的拒絶が受信された場合、ＵＥは、信号伝達接続解放指示を送信するステップ９１４に進む。信号伝達接続解放指示メッセージが、信号伝達解放指示原因フィールドに付加される。信号伝達解放指示原因フィールドは、少なくとも、信号伝達解放指示が異常な状況または状態に基づくことを含み、一実施形態は、タイムアウトして異常な状態をもたらした特定のタイマを含む。

逆に、ステップ９１２で、異常な状態が存在しないことをＵＥが見出した場合、ＵＥは、さらなるデータがＵＥで見込まれるかどうかをチェックする、ステップ９２０に進む。これは、上記で説明されるように、Ｅメールが送信され、Ｅメールの送信の確認がＵＥにおいて返信されるときを含むことができる。さらなるデータが見込まれないことをＵＥが判定する場合の他の実施例は、当業者にとって公知であろう。

ステップ９２０で、データ転送が終了したこと（または回線交換ドメインの場合には通話が終了したこと）をＵＥが判定した場合、ＵＥは、信号伝達接続解放指示を送信するステップ９２２に進み、その場合、信号伝達解放指示原因フィールドが追加され、ＵＥがアイドル遷移を要求したか、または単にＰＳセッションの終了を示したという事実を含む。

ステップ９２０から、データが終了していない場合、ＵＥは、元に戻り、ステップ９１２で異常な状態が存在するかどうかを、ステップ９２０でデータが終了したかどうかを引き続きチェックする。

いったん信号伝達接続解放指示がステップ９１４またはステップ９２２に送信されると、過程はステップ９３０に進み、終了する。

ＵＥは、例えば、チェッカーおよび遷移指示送信機を形成する、ＵＥマイクロプロセッサの動作を通して、またはハードウェア実装によって実行される、アプリケーションまたはアルゴリズムによって実装可能な機能的要素を含む。チェッカーは、遷移指示が送信されるべきかどうかをチェックするように構成される。そして、遷移指示送信機は、遷移指示が送信されるべきであるという送信機による指示に対応する遷移指示を送信するように構成される。遷移指示は、遷移指示原因フィールドを含んでもよい。

１つの実施では、ネットワークは、代わりに、暗示的にタイマの時間切れを認識させられ、ＵＥは、タイマの時間切れを示す原因値を送信する必要がない。すなわち、タイマは、ネットワークの承認時に計時を開始する。原因コードが画定され、原因コードは、ネットワークによってＵＥに提供される。そのような原因コードは、タイマを開始するためにＵＥによって使用される。以前にネットワークによって送信された原因コードが、タイマに計時を開始させるにつれて、ネットワークは、タイマの後続の時間切れの理由を暗示的に認識する。結果として、ＵＥは、タイマの時間切れを示す原因値を送信する必要がない。

図９ならびに先述の内容によって示唆されるように、原因は、１）異常な状態、ならびに２）正常な状態（例えば、ＰＳデータセッション終了および／またはアイドルモードへの遷移の要求等の、異常ではない状態）を示すように、遷移指示（例えば、信号伝達接続解放指示）とともに包含可能で、かつ送信される。したがって、種々の実施では、ＵＥにおける操作は、異常な状態を示すように、または代替として、アイドル遷移またはＰＳデータセッション終了、すなわち正常動作の要求に対する選好を示すように、遷移指示への原因の追加を提供する。そのような操作は、当然ながら、異常な状態の指示が行われるときのみに原因が遷移指示に追加される、ＵＥ操作も含む。そして、逆に、そのような操作は、正常な、すなわち、異常ではない動作およびトランザクションを示すだけのために、原因が遷移指示に追加される、ＵＥ操作も含む。すなわち、図９に関して、そのような代替操作では、もし、ステップ９１２で、異常な状態が存在する場合は、「はい」の分岐がステップ９１４に運ばれる一方で、異常な状態が存在しない場合は、ＵＥは終了ステップ９３０に直接進む。逆に、他方のそのような代替操作では、開始ステップ９１２の後に、経路がデータ終了ステップ９２０に直接運ばれる。データが終了している場合、「はい」の分岐がステップ９２０に運ばれ、その後、ステップ９３０に運ばれる。データがステップ９２０において終了していない場合、いずれの分岐も同ステップ、すなわち、ステップ９２０に戻されない。

図１０を参照して、ネットワーク要素がステップ１０１０で遷移指示を受信すると（例えば、示されるような信号伝達接続解放指示）、ネットワーク要素は、ステップ１０１４で、もし存在すれば遷移指示原因フィールドを検査し、ステップ１０１６で、原因が異常な原因であるかどうか、または、それがアイドル遷移および／またはＰＳデータセッション終了を要求するＵＥによるものであるかどうかをチェックする。もし、ステップ１０１６で、信号伝達接続解放指示が異常な原因であれば、ネットワークノードは、性能監視およびアラーム監視の目的でアラームが留意されてもよい、ステップ１０２０に進む。主要性能インジケータを適切に更新することができる。

逆に、もし、ステップ１０１６で、遷移指示（例えば、信号伝達接続解放指示）の原因が異常な状態の結果ではない、または言い換えれば、ＰＳデータセッション終了またはアイドル遷移を要求するＵＥの結果であれば、ネットワークノードは、いずれのアラームも起こらず、指示を性能統計からフィルタにかけることができる、ステップ１０３０に進み、それにより、性能統計が歪曲されることを防止する。ステップ１０２０またはステップ１０３０から、ネットワークノードは、過程が終了するステップ１０４０に進む。

遷移指示の受信または検査は、パケット交換データ接続終結のネットワーク要素による開始、または代替として、別のより好適な状態、例えば、ＣＥＬＬ＿ＦＡＣＨ、ＣＥＬＬ＿ＰＣＨ、ＵＲＡ＿ＰＣＨ、またはＩＤＬＥ＿モードへの遷移をもたらしてもよい。

上記で示唆されるように、いくつかの実施では、遷移指示の原因の欠如はまた、遷移指示が正常または異常な状態の結果であるかどうか、およびアラームを起こさなければならないか否かを判定するために、使用されてもよい。例えば、正常な状態（すなわち、例えば、ＰＳデータセッション終了および／またはアイドルモードへの遷移の要求等に関して、異常ではない）を表すためだけに原因が追加され、原因が追加されていない遷移指示をネットワーク要素が受信する場合、ネットワーク要素は、原因の欠如から、遷移指示が異常な状態の結果であることを推測し、随意で、アラームを起こし得る。逆に、別の実施例では、異常な状態を表すためだけに原因が追加され、ネットワーク要素が原因のない遷移指示を受信する場合、ネットワーク要素は、原因の欠如から、遷移指示が正常な状態（例えば、ＰＳデータセッッション終了および／またはアイドルモードへの遷移の要求）の結果であることを推測し、アラームを起こし得ない。

当業者によって理解されるように、ステップ１０２０は、種々のアラーム状態をさらに区別するために使用することができる。例えば、Ｔ３３１０タイムアウトは、第１の一式の統計値を保つために使用することができ、Ｔ３３３０タイムアウトは、第２の一式の統計値を保つために使用することができる。ステップ１０２０は、異常な状態の原因を区別するために使用することができ、それにより、ネットワーク操作者が性能をより効率的に追跡することを可能にする。

ネットワークは、例えば、検査器およびアラーム発生器を形成する、プロセッサの動作を通して、またはハードウェア実装によって実行される、アプリケーションまたはアルゴリズムによって実装可能な機能的要素を含む。検査器は、遷移指示の遷移指示原因フィールドを検査するように構成される。検査器は、遷移指示原因フィールドが異常な状態を示すかどうかをチェックする。アラーム発生器は、信号伝達接続解放指示原因フィールドが異常な状態を示すことを検査器による検査が判定した場合に、選択的にアラームを生成するように構成される。

１つの実施では、信号伝達接続解放指示の受信時に、ＵＴＲＡＮは、受信される原因と、信号伝達接続の解放のための上層からの要求とを転送する。次いで、上層は、信号伝達接続の解放を開始することができる。ＩＥ信号伝達解放指示原因は、ＵＥのＲＣＣを誘起してメッセージを送信するように、ＵＥの上層の原因を示す。原因は、異常な上層の手順の結果である可能性が高い。メッセージの原因の区別は、ＩＥの受信成功を通して確保される。

可能なシナリオは、信号伝達接続解放指示メッセージの配信成功のＲＬＣによる確認の前に、信号伝達無線ベアラＲＢ２上でＲＬＣエンティティの伝送側の確立が発生する、シナリオを含む。そのような発生の場合、ＵＥは、例えば、信号伝達無線ベアラＲＢ２上のＡＭ ＲＬＣを使用するアップリンクＤＣＣＨ上で、信号伝達接続解放指示メッセージを再伝送する。信号伝達接続解放指示または要求メッセージの配信成功のＲＬＣによる確認の前に、ＵＴＲＡＮ手順からのＲＡＴ（無線アクセス技術）間ハンドオーバが発生する場合では、ＵＥは、新規ＲＡＴであるときに信号伝達接続を中止する。

さらなる実施形態では、「信号伝達接続解放指示」または要求の代わりに、「データ転送完了指示」を利用することができる。上記の図９および１０で説明されるものと同様の機能性が、このデータ転送完了指示に適用可能となる。

一実施形態では、データ転送完了指示は、継続中のＣＳドメインデータ転送がないことをＵＥが判定し、そのＰＳデータ転送を完了したことをＵＴＲＡＮに知らせるために、ＵＥによって使用される。そのようなメッセージは、例えば、ＡＭ ＲＬＣを使用するＤＣＣＨ上で、ＵＥからＵＴＲＡＮに送信される。例示的メッセージを以下に示す。
１０．２．ｘデータ転送完了指示
このメッセージは、継続中のＣＳドメインデータ転送がないことをＵＥが判定し、そのＰＳデータ転送を完了したことをＵＴＲＡＮに知らせるために、ＵＥによって使用される。ＲＬＣ＿ＳＡＰ：ＡＭ
論理チャネル：ＤＣＣＨ
方向：ＵＥ→ＵＴＲＡＮ

ここで図２０を参照する。図２０は、（例えば、信号伝達接続解放指示またはデータ転送完了指示のための）遷移指示または要求がＵＥからＵＴＲＡＮに送信される、実施形態を図示する。過程は、ステップ２０１０から開始し、ＵＥにおける状態が遷移指示メッセージを送信するのに適切であるかどうかを判定するように、チェックがＵＥ上で行われる、ステップ２０１２に進む。そのような状態は、例えば、以下の図１１を参照して、本開示で説明され、ＵＥ上で１つ以上のアプリケーションを含むことができ、それらがデータ交換を終了したことを判定する。そのような状態はまた、タイマＴ３ｘｘが作動していれば、期限切れになるのをある期間にわたって待つステップを含んでもよい。

さらなる代替実施形態では、状態は、タイマＴ３ｘｘが無限に設定された場合に、遷移指示の送信を妨げるステップを含んでもよい。理解されるように、Ｔ３ｘｘは、無数の離散値を含むことができ、その１つが無限値を表す。

もし、ステップ２０１２で、状態が遷移指示または要求メッセージを送信するのに適切でなければ、過程は、元に戻って、状態が遷移指示または要求メッセージを送信するのに適切となるまで引き続き監視する。

いったん状態が適切になると、過程は、遷移指示がＵＴＲＡＮであるステップ２０２０に進む。例示的指示を上記の表に示す。

次いで、過程は、遷移指示が成功したかどうかを判定するようにチェックが行われる、ステップ２０２２に進む。当業者によって理解されるように、これは、ＵＴＲＡＮが遷移指示の受信に成功し、状態遷移を開始したことを意味し得る。「はい」であれば、過程は、ステップ２０３０に進み、終了する。

逆に、ステップ２０２２で、遷移指示が成功しなかったと判定された場合、過程は、ステップ２０２４に進み、ある期間にわたって待機する。そのような待機は、所与の期間が経過する前に携帯電話が別の遷移指示メッセージを送信できないようにする、「阻止期間」、例えば、Ｔ３ｘｘを使用して、実施することができる。代替として、過程は、遷移指示メッセージの数を所定の期間内で限定することができる（例えば、１０分でわずか１５のメッセージ）。阻止期間および所与の期間内のメッセージの数の限定の組み合わせも、可能である。

期間は、基準において定義される値等の、所定のものとなり得て、例えば、ＲＲＣ接続要求メッセージ、ＲＲＣ接続設定メッセージ、ＲＲＣ接続解放、無線ベアラ設定、システム情報同報通信メッセージ、システム情報ブロックメッセージ、アクティブセット更新、セル更新確認、ＵＴＲＡＮモビリティ情報メッセージ、ＵＴＲＡＮコマンドへのハンドオーバ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、または任意の要求、構成、あるいは再構成メッセージの一部として、ネットワーク要素によって設定することができる。さらに、期間は、遷移指示メッセージ内のパラメータに基づいて設定することができる。したがって、期間は、ＵＥがアイドルよりもむしろＣｅｌｌ＿ＰＣＨへの遷移を要求している場合に、より長くなり得る。

ネットワーク要素による期間の信号伝達または送信は、情報要素の形を取ることができる。本明細書で使用されるように、信号伝達または送信は、情報をＵＥに直接送信するステップ、または情報を同報通信するステップを含むことができる。同様に、ＵＥにおいて受信するステップは、同報通信チャネルの直接受信または読取を含むことができる。１つの例示的情報要素は、以下を含む。

Ｔ３ｘｘの値は、一実施形態では以下のように定義される。

一実施形態では、既存のＵＭＴＳ情報要素「接続モードでのＵＥタイマおよび定数」にＴ３ｘｘを含むことができる。したがって、これは、システム情報ブロック型１に含むことによって、セルの中で同報通信することができる。代替実施形態では、タイマ値はまた、ＳＩＢ３またはＳＩＢ４等の他のシステム情報メッセージを使用して信号伝達することもでき、または、代替として、あるいは加えて、専用ＵＴＲＡＮモビリティ情報メッセージで信号伝達することができる。

上記の表で示されるように、Ｔ３ｘｘ値は、設定値の間で変動し、ゼロ値または無限値を含むことができる。ゼロ値は、いずれの阻止も発生する必要がないことを示すために使用される。無限値は、遷移指示メッセージが決して送信されるべきではないことを示す。

１つのモビリティの実施形態では、ＵＥは、新規ネットワークまたはセルが遷移されるときはいつでも、Ｔ３ｘｘ値をリセットする。この実施例では、値は無限に設定される。このことは、遷移メッセージまたは無線ベアラメッセージが阻止タイマ値を含有しない場合に、デフォルトでＵＥが遷移指示メッセージを送信しないものであることを確実にする。したがって、例えば、遷移または無線ベアラメッセージが「遷移阻止指示」を含有しない場合は、タイマの値は無限に設定され、そうでなければ、指示の中で受信されるタイマの値が任意の以前に記憶された値に取って代わる。

別の代替実施形態では、Ｔ３ｘｘの値は、以下のように定義される。タイマＴ３ｘｘの包含は随意的であり、それにより、含まれなければ、ＵＥは、このタイマを構成または使用するステップをサポートする必要がないことを確実にする。

したがって、セルの中の阻止タイマの受信は、セルが遷移指示メッセージの使用を認識するというＵＥへの指示である。ＵＥは、長期間にわたってこれ以上ＰＳドメインデータがないという判定により、ＲＲＣまたは上位層によって開始された場合に、原因値を使用して遷移指示を信号伝達することを判定してもよい。ネットワークがこの原因とともに遷移指示メッセージ（本書でとらえられるように、どのような形態のメッセージでも）を受信すると、よりバッテリ効率の良いＲＲＣ状態への状態遷移変化をＵＥに信号伝達するように判定してもよい。

一方で、代替実施形態では、阻止タイマがセルの中で受信されないか、または読み取られないときに、ＵＥは、遷移指示メッセージを送信するための原因がＵＴＲＡＮによってサポートされていないことを判定することができる。この場合、ＵＥは、Ｔ３ｘｘの値を構成しないこと、また、遷移指示メッセージを送信するステップまたは送信を阻止するステップに関連してＴ３ｘｘを使用しないことも判定することができる。

阻止タイマが省略されることをＵＥが判定した場合には、これ以上伝送するＰＳデータがないことを判定する上位層に基づいて、遷移指示メッセージから原因値を含むことを省略し、遷移指示メッセージを送信するのみであってもよい。

代替実施形態では、ＵＥは、阻止タイマが省略されることを判定すると、これ以上伝送するＰＳデータがないことを判定する上位層に基づいて、遷移指示を開始するべきではない。

この説明された動作の一実施形態では、遷移指示メッセージは、信号伝達接続解放指示メッセージである。

したがって、第１の代替実施形態では、セルの中の阻止タイマの受信は、セルが遷移指示メッセージの使用を認識するという指示である。このメッセージの送信が許容される場合に、Ｔ３ｘｘが無限値に設定されないとき、次いで、ネットワークが遷移指示を受信するときに、よりバッテリ効率の良いＲＲＣ状態（例えば、ＣＥＬＬ＿ＦＡＣＨ、ＣＥＬＬ＿ＰＣＨ、ＵＲＡ＿ＰＣＨ、またはＩＤＬＥ＿モード）への状態遷移変化をＵＥに信号伝達するように判定してもよい。

３ＧＰＰ ＴＳＧ−ＲＡＮ２ ２５．３３１基準を利用する特定の実施例では、次の内容が、以下で識別されるセクションに追加される。

これは、以下のセクションに追加される。
１０．２．４８．８．６ システム情報ブロック型３
１０．２．４８．８．７ システム情報ブロック型４
１０．２．１ アクティブセット更新
１０．２．８ セル更新確認
１０．２．１６ ＵＴＲＡＮコマンドへのハンドオーバ
１０．２．２２ 物理チャネル再構成
１０．２．２７ 無線ベアラ再構成
１０．２．３０ 無線ベアラ解放
１０．２．３３ 無線ベアラ設定
１０．２．４０ ＲＲＣ接続設定
１０．２．５０ 輸送チャネル再構成
１０．２．４８．８．６ システム情報ブロック型３、および１０．２．４８．８．７
システム情報ブロック型４というメッセージ以外に、上記で説明されるメッセージは、全てモビリティ情報メッセージの例である。

上記は、接続およびシステム動作、ならびに種々のセル間の遷移を網羅し、そのセルが遷移指示メッセージをサポートする場合に、ＵＥが阻止タイマ値を有することを確実にする。例えば、ＵＴＲＡＮコマンドへのハンドオーバは、第２世代ネットワーク等の別の無線アクセス技術から第３世代ネットワークへの遷移が、第３世代ネットワークの標的セルによってサポートされるなら阻止タイマ値を提供することを確実にする。

具体的には、図２１を参照すると、セル間の遷移は、「開始」として参照番号２１１０によって示されるように、前提条件として、またはＵＥの他の動作中に，発生している。過程は、構成メッセージが受信される、ブロック２１１２に進む。これは、上記で識別されるメッセージのうちのいずれかとなり得て、モビリティおよび非モビリティメッセージの両方を含む。次いで、過程は、構成メッセージが阻止タイマ値を含むかどうかを確認するようにチェックが行われる、ブロック２１１４に進む。

そうでなければ、過程は、阻止タイマ値が無限に設定される、ブロック２１２０に進む。逆に、ブロック２１１４から、過程は、構成メッセージが阻止タイマ値を含まないことが判定された場合に、ブロック２１３０に進む。ブロック２１３０では、阻止タイマ値がＵＥ上に記憶され、阻止タイマの以前の値に取って代わる。次いで、過程は、ブロック２１４０に進み、終了する。理解されるように、一実施形態では、ネットワークまたはセルの変化が発生したときはいつでも、または遷移指示が送信される必要があるときはいつでも、図２１の過程が呼び出される。

いったん過程がステップ２０２４で所定の時間にわたって待機すると、過程は、ステップ２０１２に戻って、遷移指示を送信するための条件が依然として存在するかどうかを判定する。もし「はい」であれば、過程は、ステップ２０２０および２０２２に戻る。

上記に基づいて、阻止タイマ値は、種々の実施形態で提供されてもよい。第１の実施形態では、それは、阻止タイマ値を伝えるためにＲＲＣ接続設定メッセージのみを使用して提供することができる。

第２の実施形態では、阻止タイマ値を伝えるために、システム情報を使用することができる。

第３の実施形態では、阻止タイマ値を送信して、アイドルモードならびにＣｅｌｌ＿ＰＣＨ／Ｃｅｌｌ＿ＦＡＣＨおよびＤＣＨ状態のＵＥが最新情報を有することを確実にするために、ＲＲＣ接続設定およびシステム情報メッセージの両方を利用することができる。

第４の実施形態では、無線ベアラを持たずにＰＤＰコンテキストが確立されるときに、データメッセージを送信するように無線ベアラが後に確立されると、その時に阻止タイマ値を伝えることができるように、無線ベアラ設定において阻止タイマ値を送信することに加えて、阻止タイマ値を第３の実施形態のように送信することができる。

第５の実施形態では、第４の実施形態を、再構成、セル更新確認、および阻止タイマ値を伝えるＵＴＲＡＮへのハンドオーバコマンドを含む、上記で説明されるような全てのモビリティ関連メッセージと組み合わせることができる。

第１から第４の実施形態では、モビリティ中に、ＵＥがその現在記憶されている阻止タイマ値を維持する。上記で示されるように、阻止タイマが無限に設定される、いくつかの場合において、これは、ネットワークタイマが期限切れになること、およびネットワークが、ＵＥを阻止タイマの新規値を受信または判定することができるＲＣＣ状態にすることを、ＵＥが待たなければならないことを意味してもよい。阻止タイマがハンドオーバ前に無限以外の何らかの値である、他の場合において、ＵＥがタイマ値を新規セルの中で示される値に更新することができるまで、この他の値が引き続き使用される。

第５の実施形態について、阻止タイマ値がモビリティ中に更新されること、および遷移指示メッセージがＵＥから不必要に送信されないことを確実にするために、過程図２１が利用される。

ＲＬＣ再確立またはＲＡＴ間変更に例外が発生してもよい。遷移指示メッセージの配信成功がＲＬＣによって確認される前に、ＲＬＣエンティティの伝送側の再確立が発生した場合、一実施形態では、ＵＥは、ＡＭ ＲＬＣを使用するアップリンクＤＣＣＨ上で遷移指示メッセージを伝送する。

一実施形態では、遷移指示メッセージの配信成功がＲＬＣによって確認される前に、ＵＴＲＡＮ手順からのＲＡＴ間ハンドオーバが発生した場合、ＵＥは、新規ＲＡＴにある間に信号伝達接続を中止する。

ネットワーク側では、過程は、以下の図１８を参照して説明されるものと同様に取り扱われる。

再度、図１を参照すると、アイドルモード１１０よりもＵＲＡ＿ＰＣＨ状態１２８等の接続モード１２０であることが望ましくてもよい。例えば、接続モード１２０におけるＣＥＬＬ＿ＤＣＨ状態１２２またはＣＥＬＬ＿ＦＡＣＨ状態１２４への接続の待ち時間が低くなる必要がある場合、接続モード１２０のＰＣＨ状態であることが好ましい。例えば、基準を改正して、ＵＥが特定の状態（例えば、この場合はＵＲＡ＿ＰＣＨ状態１２８）にすることをＵＴＲＡＮに要求できるようにすること等によって、これを達成する多数の方法がある。

代替として、接続マネージャは、ＲＣＣ接続が現在どのような状態であるか等の他の要因を考慮に入れてもよい。もし、例えば、ＲＲＣ接続がＵＲＡ＿ＰＣＨ状態であれば、アイドルモード１１０にする必要がないことを決定してもよく、したがって、いずれの信号伝達接続解放手順も開始されない。

さらなる代替案では、ネットワーク要素（例えば、ＵＴＲＡＮ）が、ＲＣＣ接続が現在どのような状態であるか等の他の考慮を自ら考慮にいれてもよく、もし、例えば、ＲＲＣ接続がＵＲＡ＿ＰＣＨ状態であれば、アイドルモード１１０にする必要がないことを決定し、接続を解放する代わりに、単にＵＥをより好適な状態に遷移させてもよい。

図４を参照する。図４Ａは、上記の基礎構造の「４」実施例による、現在のＵＭＴＳ実装を示す。図４に図示されるように、時間は水平軸にわたっている。

ＵＥは、ＲＲＣアイドル状態１１０で起動し、伝送される必要のあるローカルまたはモバイル生成データ、またはＵＴＲＡＮから受信されるページに基づいて、ＲＲＣ接続を確立し始める。

図４Ａに図示されるように、ＲＲＣ接続設定３１０が最初に発生することができ、ＲＲＣ状態は、この期間中では接続状態４１０である。

次に、信号伝達接続設定３１２、暗号化および完全性設定３１４、および無線ベアラ設定３１６が発生する。ＲＲＣ状態は、これらの手順中ではＣＥＬＬ＿ＤＣＨ状態１２２である。図４Ａに図示されるように、ＲＲＣアイドルから無線ベアラが設定される時間まで移動するための経過時間は、この実施例では約２秒である。

次に、データが交換される。図４Ａの実施例では、これは約２〜４秒で達成され、ステップ４２０によって図示される。

データがステップ４２０で交換された後、必要に応じた断続的ＲＬＣ信号伝達ＰＤＵを除いて、いずれのデータも交換されず、したがって、無線リソースは、約１０秒後により低いデータ転送速度のＤＣＨ構成となるように、ネットワークによって再構成される。これは、ステップ４２２および４２４で図示される。

より低いデータ転送速度のＤＣＨ構成では、１７秒にわたって何も受信されず、その時点で、ＲＲＣ接続がステップ４２８でネットワークによって解放される。

いったんＲＲＣ接続解放がステップ４２８で開始されると、ＲＲＣ状態は、約４０ミリ秒間の切断状態４３０に進み、その後、ＵＥはＲＲＣアイドル状態１１０である。

同様に図４Ａに図示されるように、ＲＲＣがＣＥＬＬ＿ＤＣＨ状態１２２である期間にわたって、ＵＥ電流消費が図示される。ここで見られるように、電流消費は、ＣＥＬＬ＿ＤＣＨ状態の期間全体にわたって、約２００〜３００ミリアンペアである。切断およびアイドル中に、１．２８秒のＤＲＸサイクルを仮定すると、約３ミリアンペアが利用される。しかしながら、２００〜３００ミリアンペアにおける３５秒の電流消費がバッテリ上で排出している。

ここで、図４Ｂを参照する。図４Ｂは、ここでは信号伝達接続解放のみを実施する、上記からの同じ例示的基礎構造「４」を利用する。

図４Ｂに図示されるように、同じ設定ステップ３１０、３１２、３１４、および３１６が発生し、これは、ＲＲＣアイドル状態１１０とＲＲＣ ＣＥＬＬ＿ＤＣＨ状態１２２との間で移動するときに同じ時間量を要する。

さらに、図４Ａのステップ４２０での例示的Ｅメールに対するＲＲＣデータＰＤＵ交換は、図４Ｂでも行われ、これは、約２〜４秒かかる。

図４Ｂの実施例のＵＥには、図４Ｂの実施例では２秒であり、ステップ４４０によって図示される、アプリケーション特有の非活動タイムアウトがある。特定の時間量にわたって非活動があると接続マネージャが判定した後に、ＵＥは、この場合、ステップ４４２での信号伝達接続解放指示である、遷移指示を送信し、ステップ４４８では、ネットワークは、指示の受信およびＵＥに対する無線リソースプロファイルに基づいて、ＲＲＣ接続を解放するように進む。

図４Ｂで図示されるように、ＣＥＬＬ＿ＤＣＨステップ１２２中の電流消費は、依然として約２００〜３００ミリアンペアである。しかしながら、接続時間は、わずか約８秒である。当業者によって理解されるように、携帯電話がセルＤＣＨ状態１２２のままである、かなり短い時間量は、ＵＥデバイスにとって有意なバッテリ節約をもたらす。

ここで、図５を参照する。図５は、基礎構造「３」として上記で示される基礎構造を使用して、第２の実施例を示す。図４Ａおよび４Ｂと同様に、約２秒かかる接続設定が発生する。これは、ＲＲＣ接続設定３１０、信号伝達接続設定３１２、暗号化および完全性設定３１４、および無線ベアラ設定３１６を必要とする。

この設定中に、ＵＥは、ＲＲＣアイドルモード１１０からＣＥＬＬ＿ＤＣＨ状態１２２になり、その間にＲＲＣ状態接続ステップ４１０を伴う。

図４Ａと同様に、図５Ａでは、ＲＬＣデータＰＤＵ交換がステップ４２０で発生し、図５Ａの実施例では、２〜４秒かかる。

基礎構造３によれば、ＲＬＣ信号伝達ＰＤＵ交換は、必要に応じた断続的ＲＬＣ信号伝達ＰＤＵを除いて、いずれのデータも受信せず、したがって、ステップ４２２で５秒の期間にわたってアイドルであり、その時点で、無線リソースは、ＵＥをＣＥＬＬ＿ＤＣＨ状態１２２からＣＥＬＬ＿ＦＡＣＨ状態１２４に再構成する。これは、ステップ４５０で行われる。

ＣＥＬＬ＿ＦＡＣＨ状態１２４では、ＲＬＣ信号伝達ＰＤＵ交換は、この場合は３０秒である所定の時間量にわたって、必要に応じた断続的ＲＬＣ信号伝達ＰＤＵを除いて、いずれのデータもないことを見出し、その時点で、ネットワークによるＲＲＣ接続解放がステップ４２８で行われる。

図５Ａで見られるように、これは、ＲＲＣ状態をアイドルモード１１０にする。

図５Ａでさらに見られるように、ＤＣＨモード中の電流消費は、２００〜３００ミリアンペアの間である。ＣＥＬＬ＿ＦＡＣＨ状態１２４になるとき、電流消費は、約１２０〜１８０ミリアンペアまで低下する。ＲＲＣコネクタが解放され、ＲＲＣがアイドルモード１１０になった後、電力消費は、約３ミリアンペアである。

ＣＥＬＬ＿ＤＣＨ状態１２２またはＣＥＬＬ＿ＦＡＣＨ状態１２４である、ＵＴＲＡ ＲＲＣ接続モード状態は、図５Ａの実施例では約４０秒にわたって続く。

ここで、図５Ｂを参照する。図５Ｂは、ＲＲＣ接続設定３１０、信号伝達接続設定３１２、暗号化完全性設定３１４、および無線ベアラ設定３１６を得るように、約２秒の同じ接続時間を伴う、図５Ａと同じ基礎構造「３」を図示する。さらに、ＲＬＣデータＰＤＵ交換４２０は、約２〜４秒かかる。

図４Ｂと同様に、ＵＥアプリケーションは、ステップ４４０で特定の非活動タイムアウトを検出し、その時点で、遷移指示（例えば、信号伝達接続解放指示４４２）がＵＥによって送信され、結果として、ネットワークがステップ４４８でＲＲＣ接続を解放する。

図５Ｂでさらに見ることができるように、ＲＲＣは、アイドルモード１１０で起動し、ＣＥＬＬ＿ＦＡＣＨ状態に進むことなくＣＥＬＬ＿ＤＣＨ状態１２２になる。

図５Ｂでさらに見られるように、電流消費は、図５の実施例によれば約８秒である、ＲＲＣ段階がＣＥＬＬ＿ＤＣＨ状態１２２である時間では、約２００〜３００ミリアンペアである。

したがって、図４Ａと４Ｂ、および図５Ａと５Ｂとの間の比較は、有意量の電流消費が排除され、それにより、ＵＥのバッテリ寿命を延長することを示す。当業者によって理解されるように、上記はさらに、現在の３ＧＰＰ仕様書との関連で使用することができる。

ここで、図６を参照する。図６は、ＵＭＴＳネットワーク用のプロトコルスタックを図示する。

図６で見られるように、ＵＭＴＳは、ＣＳ制御プレーン６１０、ＰＳ制御プレーン６１１、およびＰＳユーザプレーン６３０を含む。

これら３つのプレーン内には、非アクセス層（ＮＡＳ）部分６１４およびアクセス層部分６１６が存在する。

ＣＳ制御プレーン６１０におけるＮＡＳ部分６１４は、呼制御（ＣＣ）６１８、付加サービス（ＳＳ）６２０、およびショートメッセージサービス（ＳＭＳ）６２２を含む。

ＰＳ制御プレーン６１１におけるＮＡＳ部分６１４は、モビリティ管理（ＭＭ）およびＧＰＲＳモビリティ管理（ＧＭＭ）６２６の両方を含む。それはさらに、セッション管理／無線アクセスベアラ管理ＳＭ／ＲＡＢＭ６２４およびＧＳＭＳ６２８を含む。

ＣＣ６１８は、回線交換サービス用の呼管理信号伝達を提供する。ＳＭ／ＲＡＢＭ６２４のセッション管理は、ＰＤＰテキスト有効化、無効化、および修正を提供する。ＳＭ／ＲＡＢＭ６２４はまた、サービス交渉の質も提供する。

ＳＭ／ＲＡＢＭ６２４のＲＡＢＭ部分の主要機能は、ＰＤＰコンテキストを無線アクセスベアラに接続することである。したがって、ＳＭ／ＲＡＢＭ６２４は、無線リソースの設定、修正、および解放に関与している。

ＣＳ制御プレーン６１０およびＰＳ制御プレーン６１１は、アクセス層６１６において、無線リソース制御（ＲＲＣ）６１７の上に位置する。

ＰＳユーザプレーン６３０におけるＮＡＳ部分６１４は、アプリケーション層６３８、ＴＣＰ／ＵＤＰ層６３６、およびＰＤＰ層６３４を含む。ＰＤＰ層６３４は、例えば、インターネットプロトコル（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ／ＩＰ）を含むことができる。

アクセス層６１６は、ＰＳユーザプレーン６３０において、パケットデータ集中プロトコル（ＰＤＣＰ）６３２を含む。ＰＤＣＰ６３２は、（図８で見られるように）ＷＣＤＭＡプロトコルを、ＵＥとＲＮＣとの間でＴＣＰ／ＩＰプロトコルを運ぶのに好適にするように設計され、随意で、ＩＰトラッフィック流プロトコルヘッダ圧縮および復元用のものである。

ＵＭＴＳ無線リンク制御（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ／ＲＬＣ）６４０および媒体アクセス制御（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ／ＭＡＣ）層６５０は、ＵＭＴＳ無線インターフェースのデータリンク副層を形成し、ＲＮＣノードおよびユーザ機器上に存在する。

層１（Ｌ１）のＵＭＴＳ層（物理層６６０）は、ＲＬＣ／ＭＡＣ層６４０および６５０の下側にある。この層は、通信用の物理層である。

上記は、種々のモバイルまたはワイヤレスデバイス上に実装することができるが、１つのモバイルデバイスの実施例を、図７に関して以下で概説する。ここで、図７を参照する。

ＵＥ７００は、好ましくは、少なくとも音声およびデータ通信能力を有する、双方向ワイヤレス通信デバイスである。ＵＥ７００は、好ましくは、インターネット上で他のコンピュータシステムと通信する能力を有する。提供される正確な機能性に応じて、ワイヤレスデバイスは、例として、データメッセージングデバイス、双方向ポケットベル、ワイヤレスＥメールデバイス、データメッセージング能力付きの携帯電話、ワイヤレスインターネット機器、またはデータ通信デバイスと呼ばれてもよい。

ＵＥ７００は、双方向通信に有効である場合、受信器７１２および送信器７１４の両方、ならびに、１つ以上の、好ましくは、組み込まれた、または内部のアンテナ要素７１６および７１８、局部発振器（ＬＯ）７１３、およびデジタル信号プロセッサ（ＤＳＰ）７２０等の処理モジュール等の、関連構成要素を含む、通信サブシステム７１１を組み込む。通信の当業者にとって明白となるように、通信サブシステム７１１の特定の設計は、デバイスが動作することを目的とする通信ネットワークに依存する。例えば、ＵＥ７００は、ＧＰＲＳネットワークまたはＵＭＴＳネットワーク内で動作するように設計される、通信サブシステム７１１を含んでもよい。

ネットワークアクセス要件もまた、ネットワーク７１９の種類に応じて変動する。例えば、ＵＭＴＳおよびＧＰＲＳネットワークでは、ネットワークアクセスは、ＵＥ７００の加入者またはユーザと関連付けられる。したがって、例えば、ＧＰＲＳモバイルデバイスは、ＧＰＲＳネットワーク上で動作するために、加入者識別モジュール（ＳＩＭ）カードを必要とする。ＵＭＴＳでは、ＵＳＩＭまたはＳＩＭモジュールが必要とされる。ＣＤＭＡでは、ＲＵＩＭカードまたはモジュールが必要とされる。これらは、本明細書では、ＵＩＭインターフェースと呼ばれる。有効なＵＩＭインターフェースがないと、モバイルデバイスは、完全には機能しない場合がある。ローカルまたは非ネットワーク通信機能、ならびに緊急通話等の法的に必要な機能（もしあれば）が利用可能であってもよいが、モバイルデバイス７００は、ネットワーク７００上の通信を伴う、任意の他の機能を実行することができなくなる。ＵＩＭインターフェース７４４は、通常、ディスケットまたはＰＣＭＣＩＡカードのように、カードを挿入し、取り出すことができる、カードスロットと同様である。ＵＩＭカードは、約６４Ｋのメモリを有し、多くの主要構成７５１と、識別および加入者関連情報等の他の情報７５３とを保持することができる。

必要なネットワーク登録または有効化手順が完了すると、ＵＥ７００は、ネットワーク７１９上で通信信号を送受信してもよい。通信ネットワーク７１９を通してアンテナ７１６によって受信される信号は、信号増幅、周波数下方変換、チャネル選択、および同等物等の一般的な受信器機能、および図７に示された実施例のシステムでは、アナログ・デジタル（Ａ／Ｄ）変換を行ってもよい、受信器７１２への入力である。受信された信号のＡ／Ｄ変換は、ＤＳＰ７２０で行われる復調および復号等の、より複雑な通信機能を可能にする。同様に、伝送される信号は、例えば、ＤＳＰ７２０による復調および復号を含んで処理され、デジタル・アナログ変換、周波数上方変換、フィルタリング、増幅、およびアンテナ７１８を介した通信ネットワーク７１９上の伝送のために、送信器７１４に入力される。ＤＳＰ７２０は、通信信号を処理するだけでなく、受信器および送信器制御も提供する。例えば、受信器７１２および送信器７１４において通信信号に適用される利得は、ＤＳＰ７２０において実装される自動利得制御アルゴリズムを通して、適応的に制御されてもよい。

ネットワーク７１９はさらに、サーバ７６０および他の要素（図示せず）を含む、複数のシステムと通信してもよい。例えば、ネットワーク７１９は、種々のサービスレベルを伴う種々のクライアントに適応するために、企業システムおよびウェブクライアントシステムの両方と通信してもよい。

ＵＥ７００は、好ましくは、デバイスの全体的動作を制御する、マイクロプロセッサ７３８を含む。少なくともデータ通信を含む、通信機能は、通信サブシステム７１１を通して果たされる。マイクロプロセッサ７３８はまた、ディスプレイ７２２、フラッシュメモリ７２４、ランダムアクセスメモリ（ＲＡＭ）７２６、補助入力／出力（Ｉ／Ｏ）サブシステム７２８、シリアルポート７３０、キーボード７３２、スピーカ７３４、マイクロフォン７３６、短距離通信サブシステム７４０、および、概して７４２と指定される任意の他のデバイスサブステム等の、さらなるデバイスサブシステムとも相互作用する。

図７に示されたサブシステムのうちのいくつかは、通信関連機能を果たすが、他のサブシステムは、「常駐」またはオンデバイス機能を提供してもよい。明白に、例えば、キーボード７３２およびディスプレイ７２２等のいくつかのサブシステムは、通信ネットワーク上で伝送するためのテキストメッセージの入力等の通信関連機能と、計算機またはタスクリスト等のデバイス常駐機能との両方に使用されてもよい。

マイクロプロセッサ７３８によって使用されるオペレーティングシステムソフトウェアは、好ましくは、代わりに読み出し専用メモリ（ＲＯＭ）または同様の記憶要素（図示せず）であってもよい、フラッシュメモリ７２４等の持続的記憶部に記憶される。当業者であれば、オペレーティングシステム、特定のデバイスアプリケーション、またはその部分は、ＲＡＭ７２６等の揮発性メモリに一時的に取り込まれてもよいことを理解するであろう。受信された通信信号もまた、ＲＡＭ７２６に記憶されてもよい。さらに、一意の識別子もまた、好ましくは読み取り専用メモリに記憶される。

示されるように、フラッシュメモリ７２４は、コンピュータプログラム７５８と、プログラムデータ記憶部７５０、７５２、７５４、および７５６との両方に対する異なるエリアに分離することができる。これらの異なる記憶型は、各プログラムが、独自のデータ記憶要件のためにフラッシュメモリ７２４の一部分を割り当てることができることを示す。マイクロプロセッサ７３８は、そのオペレーティングシステム機能に加えて、好ましくは、モバイルデバイス上でのソフトウェアアプリケーションの実行を可能にする。例えば、少なくともデータおよび音声通信アプリケーションを含む、基本動作を制御する所定の一式のアプリケーションが、通常、製造中にＵＥ７００にインストールされる。好ましいソフトウェアアプリケーションは、Ｅメール、カレンダーイベント、音声メール、約束、およびタスクアイテム等であるが、それらに限定されない、モバイルデバイスのユーザに関するデータアイテムを整理および管理する能力を有する、個人情報マネージャ（ＰＩＭ）アプリケーションであってもよい。当然ながら、１つ以上のメモリ記憶部が、ＰＩＭデータアイテムの記憶を促進するようにモバイルデバイス上で利用可能となる。そのようなＰＩＭアプリケーションは、好ましくは、ワイヤレスネットワーク７１９を介してデータアイテムを送受信する能力を有する。好ましい実施形態では、ＰＩＭデータアイテムは、ワイヤレスネットワーク７１９を介して、途切れなく統合、同期化、および更新され、モバイルデバイスユーザの対応するデータアイテムが、記憶されるか、またはホストコンピュータシステムと関連付けられる。さらなるアプリケーションもまた、ネットワーク７１９、補助Ｉ／Ｏサブシステム７２８、シリアルポート７３０、短距離通信サブシステム７４０、または任意の他の好適なサブシステム７４２を通して、モバイルデバイス７００上に搭載され、マイクロプロセッサ７３８による実行のために、ＲＡＭ７２６、または好ましくは不揮発性記憶部（図示せず）に、ユーザによってインストールされてもよい。アプリケーションのインストールにおける、そのような融通性は、デバイスの機能性を増加させ、強化オンデバイス機能、通信関連機能、または両方を提供してもよい。例えば、安全な通信アプリケーションは、電子商取引機能および他のそのような金融取引が、ＵＥ７００を使用して行われることを可能にしてもよい。しかしながら、これらのアプリケーションは、上記によれば、多くの場合において、通信事業社によって承認される必要がある。

データ通信モードでは、テキストメッセージまたはウェブページダウンロード等の受信された信号は、通信サブシステム７１１によって処理され、好ましくは、ディスプレイ７２２に、または代替として補助Ｉ／Ｏデバイス７２８に出力するために、受信された信号をさらに処理する、マイクロプロセッサ７３８に入力される。ＵＥ７００のユーザはまた、ディスプレイ７２２、およびおそらく補助Ｉ／Ｏデバイス７２８と併せて、例えば、好ましくは、完全英数字キーボードまたは電話型キーパッドである、キーボード７３２を使用して、Ｅメールメッセージ等のデータアイテムを構成してもよい。次いで、そのような構成されたアイテムは、通信サブシステム７１１を通して通信ネットワーク上で伝送されてもよい。

音声通信については、受信された信号が、好ましくはスピーカ７３４に出力され、伝送するための信号が、マイクロフォン７３６によって生成されることを除いて、ＵＥ７００の全体的動作は同様である。音声メッセージ録音サブシステム等の、代替的な音声またはオーディオＩ／Ｏサブシステムもまた、ＵＥ７００上に実装されてもよい。音声またはオーディオ信号出力は、好ましくは、主にスピーカ７３４を通して達成されるが、ディスプレイ７２２もまた、例えば、発呼者の身元、音声電話の持続時間、または他の音声電話関連情報の指示を提供するために使用されてもよい。

図７のシリアルポート７３０は、通常、ユーザのデスクトップコンピュータ（図示せず）との同期化が望ましくてもよい、携帯情報端末（ＰＤＡ）型モバイルデバイスで実装される。そのようなポート７３０は、外部デバイスまたはソフトウェアアプリケーションを通して、ユーザが選好を設定することを可能にし、ワイヤレス通信ネットワーク以外を通して、ＵＥ７００への情報またはソフトウェアダウンロードを提供することによって、モバイルデバイス７００の能力を拡張する。例えば、直接的であり、したがって確実かつ信頼されている接続を通して、暗号化キーをデバイスに搭載し、それにより、安全なデバイス通信を可能にするために、代替ダウンロード経路が使用されてもよい。

代替として、シリアルポート７３０は、他の通信に使用することができ、かつユニバーサルシリアルバス（ＵＳＢ）ポートとして含むことができる。インターフェースがシリアルポート７３０と関連付けられる。

短距離通信サブシステム等の、他の通信サブシステム７４０は、ＵＥ７００と、必ずしも同様のデバイスである必要はない、異なるシステムまたはデバイスとの間の通信の通信を提供してもよい、さらなるオプションの構成要素である。例えば、サブシステム７４０は、同様に有効化されたシステムおよびデバイスとの通信を提供するように、赤外線デバイスならびに関連回路および構成要素、またはＢｌｕｅｔｏｏｔｈ^ＴＭ通信モジュールを含んでもよい。

ここで、図８を参照する。図８は、ワイヤレス通信ネットワークを通して通信するＵＥ８０２を含む、通信システム８００のブロック図である。

ＵＥ８０２は、１つまたは複数のノードＢ８０６とワイヤレスで通信する。各ノードＢ８０６は、エアインターフェース処理およびいくつかの無線リソース管理機能に関与している。ノードＢ８０６は、ＧＳＭ／ＧＰＲＳネットワークにおけるベーストランシーバ基地局と同様の機能性を提供する。

図８の通信システム８００において示されるワイヤレスリンクは、１つ以上の異なるチャネル、典型的には、異なる無線周波数（ＲＦ）チャネル、およびワイヤレスネットワークとＵＥ８０２との間で使用される関連プロトコルを表す。Ｕｕエアインターフェース８０４は、ＵＥ８０２とノードＢ８０６との間で使用される。

ＲＦチャネルは、典型的には、帯域幅全体の制限およびＵＥ８０２の限定されたバッテリ電力により、節約されなければならない、限定されたリソースである。当業者であれば、実際の実践でのワイヤレスネットワークは、ネットワーク範囲の所望の全体的拡張に応じて、数百のセルを含んでもよい。全ての関連構成要素は、複数のネットワークコントローラによって制御される、複数のスイッチおよびルータ（図示せず）によって接続されてもよい。

各ノードＢ８０６は、無線ネットワークコントローラ（ＲＮＣ）８１０と通信する。ＲＮＣ８１０は、そのエリアでの無線リソースの制御に関与している。１つのＲＮＣ８１０は、複数のノードＢ８０６を制御する。

ＵＭＴＳネットワークにおけるＲＮＣ８１０は、ＧＳＭ／ＧＰＲＳネットワークにおける基地局コントローラ（ＢＳＣ）機能と同等の機能を提供する。しかしながら、ＲＮＣ８１０は、ＭＳＣおよびＳＧＳＮを伴うことなく、例えば、自律ハンドオーバ管理を含む、さらなる知能を含む。

ノードＢ８０６とＲＮＣ８１０との間で使用されるインターフェースは、ｌｕｂインターフェース８０８である。３ＧＰＰ ＴＳ ２５．４３３ Ｖ３．１１．０（２００２−０９）および３ＧＰＰ ＴＳ ２５．４３３ Ｖ５．７．０（２００４−０１）で定義されるように、ＮＢＡＰ（ノードＢアプリケーション部）信号伝達プロトコルが主に使用される。

ユニバーサル地上波無線アクセスネットワーク（ＵＴＲＡＮ）８２０は、ＲＮＣ８１０、ノードＢ８０６、およびＵｕエアインターフェース８０４を備える。

回線交換トラフィックは、携帯電話交換センター（Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ
Ｃｅｎｔｒｅ／ＭＳＣ）８３０に経路指定される。ＭＳＣ８３０は、電話をかけ、加入者から、またはＰＳＴＮ（図示せず）からデータを取り入れ、受信する、コンピュータである。

ＲＮＣ８１０とＭＳＣ８３０との間のトラフィックは、Ｉｕ−ＣＳインターフェース８２８を使用する。Ｉｕ−ＣＳインターフェース８２８は、ＵＴＲＡＮ８２０とコア音声ネットワークとの間で（典型的には）音声トラフィックおよび信号伝達を運ぶための回線交換接続である。使用される主要信号伝達プロトコルは、ＲＡＮＡＰ（無線アクセスネットワークアプリケーション部）である。ＲＡＮＡＰプロトコルは、ＭＳＣ８３０またはＳＧＳＮ８５０（以下でさらに詳細に定義される）となり得る、コアネットワーク８２１と、ＵＴＲＡＮ８２０との間のＵＭＴＳ信号伝達で使用される。ＲＡＮＡＰプロトコルは、３ＧＰＰ ＴＳ ２５．４１３ Ｖ３．１１．１（２００２−０９）およびＴＳ ２５．４１３ Ｖ５．７．０（２００４−０１）で定義される。

ネットワーク操作者により登録された全てのＵＥ８０２について、永久データ（ＵＥ８０２のユーザのプロファイル等）ならびに一時データ（ＵＥ８０２の現在のロケーション等）が、ホームロケーションレジストリ（ＨＬＲ）８３８に記憶される。ＵＥ８０２の音声電話の場合、ＨＬＲ８３８は、ＵＥ８０２の現在のロケーションを判定するように問い合わせられる。ＭＳＣ８３０のビジタロケーションレジスタ（Ｖｉｓｉｔｏｒ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ／ＶＬＲ）８３６は、一群のロケーションアリアに関与しており、現在その責任エリアにある移動局のデータを記憶する。これは、より迅速なアクセスのために、ＨＬＲ８３８からＶＬＲ８３６に伝送された永久移動局データの複数部分を含む。しかしながら、ＭＳＣ８３０のＶＬＲ８３６はまた、一時的識別等のローカルデータを割り当て、記憶してもよい。ＵＥ８０２はまた、ＨＬＲ８３８によるシステムアクセスで認証される。

パケットデータは、サービスＧＰＲＳサポートノード（Ｓｅｒｖｉｃｅ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ／ＳＧＳＮ）８５０を通して経路指定される。ＳＧＳＮ８５０は、ＧＰＲＳ／ＵＭＴＳネットワークにおけるＲＮＣとコアネットワークとの間のゲートウェイであり、その地理的サービスエリア内でＵＥを往復するデータパケットの配信に関与している。Ｉｕ−ＰＳインターフェース８４８は、ＲＮＣ８１０とＳＧＳＮ８５０との間で使用され、ＵＴＲＡＮ８２０とコアデータネットワークとの間で（典型的には）データトラフィックおよび信号伝達を運ぶためのパケット交換接続である。使用される主要信号伝達プロトコルは、ＲＡＮＡＰ（上記で説明される）である。

ＳＧＳＮ８５０は、ゲートウェイＧＰＲＳサポートノード（Ｇａｔｅｗａｙ ＧＰＲＳ
Ｓｕｐｐｏｒｔ Ｎｏｄｅ／ＧＧＳＮ）８６０と通信する。ＧＧＳＮ８６０は、ＵＭＴＳ／ＧＰＲＳネットワークと、インターネットまたはプライベートネットワーク等の他のネットワークとの間のインターフェースである。ＧＧＳＮ８６０は、Ｇｉインターフェース上で公衆データネットワークＰＤＮ８７０に接続される。

当業者であれば、ワイヤレスネットワークは、おそらく、図８で明示的に示されていない他のネットワークを含む、他のシステムと接続されてもよいことを理解するであろう。たとえ交換された実際のパケットデータがなくても、ネットワークは、通常、最低限でも、ある種類のページングおよびシステム情報を継続的に伝送する。ネットワークは多くの部分から成るが、これらの部分は全て、ワイヤレスリンクにおいてある動作をもたらすように協働する。

図１１は、複数の同時パケットデータ通信サービスセッションに従ってＵＥの動作を表す、概して１１０２で示される表現を図示する。ここでは、それぞれＰＤＰ_１およびＰＤＰ_２と指定される特定のＰＤＰコンテキストと関連付けられる、２つのパケットデータサービスが、現在アクティブである。プロット１１０４は、第１のパケットデータサービスに有効化されたＰＤＰコンテキストを表し、プロット１１０６は、第１のパケットデータサービスに割り当てられた無線リソースを表す。そして、プロット１１０８は、第２のパケットデータサービスに有効化されたＰＤＰコンテキストを表し、プロット１１１２は、第２のパケットデータサービスに割り当てられた無線リソースを表す。ＵＥは、セグメント１１１４によって示されるサービス要求を介して、無線アクセスベアラ割当を要求する。そして、ＵＥはまた、本開示の実施形態に従ってセグメント１１１６によって示される、無線ベアラサービス解放も要求する。サービス要求および別個のサービスのためのサービス解放は、相互とは無関係であり、すなわち、独立して生成される。図１１の例示的説明図では、ＰＤＰコンテキストおよび関連ＰＤＰコンテキストに対する無線リソースは、実質的に同時に割り当てられる。そして、無線リソース解放は、示されるように、ＵＥによる要求時に、またはＲＮＣ（無線ネットワークコントローラ）が無線リソースを解放することを決定するときに、許可される。

無線リソース解放要求、または無線リソースを解放する他の決定に対応して、ネットワークは、パケットデータサービスと関連付けられた無線リソースを選択的に解除する。無線解放要求は、信号伝達接続全体ではなく、無線アクセスベアラごとに行われ、それにより、リソース割当の向上した粒度制御を可能にする。

例示的実装では、指定１１１８および１１２２によって示されるような１次サービスおよび１つ以上の２次サービスとして、単一のパケットデータサービスをさらに形成可能である。無線リソース解放は、無線リソース割当がもはや必要ではない、またはそうでなければ解放されることが所望される、１つ以上の１次および２次サービスのどれかを識別するステップのさらなる許容である。それにより、効率的な無線リソース割当が提供される。加えて、不必要な処理に割り当てられたであろうプロセッサ電力を、ここでは他の目的でより良好に利用することができるため、ＵＥ上のプロセッサの最適な利用が提供される。

図１２は、通信システム８００の部品、すなわち、複数の連続パケットデータサービスセッションに関する本開示の実施形態に従って動作する、ＵＥ８０２および無線ネットワークコントローラ（ＲＮＣ）／ＳＧＳＮ８１０／８５０を図示する。ＵＥは、装置１１２６を含み、ＲＮＣ／ＳＧＳＮは、本開示の実施形態の装置１１２８を含む。装置１１２６および１１２８を形成する要素は、処理回路ならびにハードウェアまたはファームウェア実装によって実行可能なアルゴリズムを含む、任意の所望の方式で実装可能であると機能的に表されている。装置１１２８の要素は、ＲＮＣ／ＳＧＳＮにおいて具体化されると表されているが、他の実施では、他のネットワークロケーションにおいて他の場所で形成されるか、または、２つ以上のネットワークロケーションにわたって分布させられる。

装置１１２６は、検出器１１３２および遷移指示送信機１１３４を含む。１つの例示的実施では、要素１１３２および１１３４は、セッション管理層、例えば、ＵＥのＵＭＴＳの中で画定される非アクセス層（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ／ＮＡＳ）の層において具体化される。

別の例示的実装では、要素は、アクセス層（Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ／ＡＳ）の副層において具体化される。ＡＳ副層において実装されると、要素は、１１３６で示される、接続マネージャの一部として実装される。このように実装されると、要素は、ＰＤＰコンテキスト動作またはアプリケーション層動作を認識する必要がない。

検出器は、パケット通信サービスと関連付けられた遷移指示を送信するように、判定が行われるときを検出する。判定は、例えば、アプリケーション層または他の論理層で行われ、セッション管理層およびそこで具体化される検出器に提供される。検出器によって行われる検出の指示は、無線リソース解放指示送信機に提供される。送信機は、図１１に示されたサービス解放要求１１１６を形成する遷移指示を生成し、ＵＥに遷移指示を送信させる。

さらなる実装では、遷移指示は、必要に応じて、ここと上記とで説明される前述の原因のうちのいずれか等の原因を含有する、原因フィールドを含み、または、原因フィールドは、ＵＥを遷移させるよりもＵＥがネットワークを好む、好ましい状態を識別する。

ネットワークにおいて具体化される装置１１２８は、検査器１１４２および許可器１１４４を含む。検査器は、そこで受信されると遷移指示を検査する。そして、遷移許可器１１４４は、遷移指示で要求されたように、ＵＥを選択的に遷移させるように動作する。

信号伝達が無線リソース制御（ＲＲＣ）層で行われる実装では、ＳＧＳＮよりもむしろ、無線ネットワークコントローラ（ＲＮＣ）がＵＥの検査および遷移を行う。そして、それに対応して、ＵＥにおいて具体化される装置は、ＲＲＣ層で形成され、または、装置は、そうでなければ、生成された指示をＲＲＣレベルで送信させる。

例示的な制御フローでは、上位層は、必要に応じて、特定のＰＤＰコンテキストに割り当てられる無線リソースがもはや必要ではないことを、ＮＡＳ／ＲＲＣ層に知らせる。ＲＲＣ層指示メッセージが、ネットワークに送信される。メッセージは、例えば、無線ネットワークコントローラへのパケットデータサービスを識別する、ＲＡＢ ＩＤまたはＲＢ
ＩＤを含む。そして、それに応じて、無線ネットワークコントローラの動作は、ＵＥに返信される無線リソース解放、無線リソース再構成、または無線リソース制御（ＲＲＣ）接続解放メッセージを終了する決意をする手順を誘起する。ＲＮＣ手順は、例えば、３ＧＰＰ文書ＴＳ ２３．０６０第９．２．５項で定められる手順と同様または同等である。ＲＡＢ ＩＤは、例えば、関連ＰＤＰコンテキストを識別するネットワークサービスアクセスポイント識別子（Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｉｄｅｎｔｉｆｉｅｒ／ＮＳＡＰＩ）と同じであるＩＤとして、有利に利用され、アプリケーション層は、概してＮＳＡＰＩを認識している。

具体的実施例では、ＲＲＣ層で形成され、またはそうでなければＲＲＣ層に提供され、かつＲＲＣ層で送信される、無線リソース解放指示が、以下の関連情報とともに表される。ＲＲＣ層で具体化されたときの指示はまた、例えば、無線リソース解放指示とも呼ばれる。

図１３は、図１１に示されたグラフ表示の一部に図式的に示されたもの等の、ＰＤＰコンテキストと関連付けられた無線リソースの解放に従って生成される例示的信号伝達を表す、概して１１３７で示される、メッセージシーケンス図を図示する。解放は、ＵＥによって、またはＲＮＣあるいは他のＵＴＲＡＮエンティティにおいて、開始される。例えば、ＵＥにおいて開始されると、ＵＥは、ＵＴＲＡＮに無線リソース解放指示を送信する。

開始時に、セグメント１１３８によって示されるように、無線アクセスベアラ（ＲＡＢ）解放要求がＲＮＣ／ＵＴＲＡＮによって生成および送信され、ＳＧＳＮに配信される。それに応じて、セグメント１１４０によって示される、ＲＡＢ割当要求がＲＮＣ／ＵＴＲＡＮに返信される。次いで、セグメント１１４２によって示されるように、ＵＥ８０２とＵＴＲＡＮとの間に延在する無線リソースが解放される。次いで、セグメント１１４４によって示されるように、応答が送信される。

図１４は、図１３に示されたメッセージシーケンス図と同様である、概して１１４７で示される、メッセージシーケンス図を図示するが、ここでは、最終ＰＤＰコンテキストのリソースが解放される。開始時に、ＲＮＣがＩｕ解放要求１１５０を生成し、ＳＧＳＮに伝達され、それに対応して、ＳＧＳＮは、セグメント１１５２によって示される、Ｉｕ解放コマンドを返信する。その後、セグメント１１５４によって示されるように、ＵＥとＵＴＲＡＮとの間に形成される無線ベアラが解放される。そして、セグメント１１５６によって示されるように、ＲＮＣ／ＵＴＲＡＮは、ＳＧＳＮにＩｕ解放完了を返信する。

図１５は、ＰＤＰコンテキストに従って割り当てられる無線リソースを解放する本開示の実施形態の過程を表す、概して１１６２で示される、方法フロー図を図示する。

ブロック１１６４によって示される、過程の開始後に、無線リソース解放指示が受信されたかどうかに関して、決定ブロック１１６６によって示される、判定が行われる。受信されていなければ、「いいえ」の分岐が終了ブロック１１６８に運ばれる。

もし、逆に、無線アクセスベアラ解放が要求されていれば、「はい」の分岐が決定ブロック１１７２に運ばれる。決定ブロック１１７２では、解放される無線アクセスベアラが解放される最終無線アクセスベアラであるかどうかに関して、判定が行われる。もしそうでなければ、「いいえ」の分岐がブロック１１７８に運ばれ、好ましい状態が設定される。次いで、図１３に示されたもの等の、または３ＧＰＰ文書第２３．０６０項の第９．２．５．１．１従属節で説明されるもの等の、無線アクセスベアラ解放手順が行われる。

逆に、ＲＡＢが最後に解放されるものであるという判定が決定ブロック１１７２において行われた場合、「はい」の分岐がブロック１１８６に運ばれ、図１４に示されたもの等の、または３ＧＰＰ文書第２３．０６０項の第９．２．５．１．２従属節で説明されるもの等の、Ｉｕ解放手順が行われる。

図１６は、ＰＤＰコンテキストに従って割り当てられる無線リソースを解放する本開示の実施形態の過程を表す、概して１１９２で示される、方法フロー図を図示する。

ブロック１１９４によって示される、過程の開始後に、解放するＲＡＢ（無線アクセスベアラ）があるかどうかに関して、決定ブロック１１９６によって示される決定が行われる。もしなければ、「いいえ」の分岐が終了ブロック１１９８に運ばれる。

もし、逆に、無線アクセスベアラ解放が要求されていれば、「はい」の分岐が決定ブロック１２０２に運ばれる。決定ブロック１２０２では、解放される無線アクセスベアラが解放される最終無線アクセスベアラであるかどうかに関して、判定が行われる。もしそうでなければ、「いいえ」の分岐は、ＲＡＢが設定されるブロック１２０４、好ましい状態が設定されるブロック１２０６、および、図１３に示されたもの等の、または３ＧＰＰ文書第２３．０６０項の第９．２．５．１．１従属節で説明されるもの等の、無線アクセスベアラ解放手順が行われる、ブロック１２０８に運ばれる。

逆に、ＲＡＢが最後に解放されるものであるという判定が決定ブロック１２０２において行われた場合、「はい」の分岐がブロック１２１２に運ばれ、ドメインがＰＳ（パケット交換）に設定される。次いで、ブロック１２１４によって示されるように、解放原因が設定される。そして、ブロック１２１６によって示されるように、信号伝達接続解放指示がＤＣＣＨ上で設定される。図１４に示されたもの等の、または３ＧＰＰ文書第２３．０６０項の第９．２．５．１．２従属節で説明されるもの等の、Ｉｕ解放手順が行われる。

図１７は、本開示の実施形態の操作の方法を表す、概して１２２４で示される方法を図示する。方法は、第１のパケットサービスおよび第２のパケットサービスの同時実行を提供する、無線通信システムにおける無線リソースの効率的な利用を促進する。第１に、ブロック１２２６によって示されるように、第１のパケットサービスおよび第２のパケットサービスのうちの選択されたパケットサービスと関連付けられた無線リソースを解放する選択の検出が行われる。次いで、ブロック１２２８によって示されるように、無線リソースを解放する選択の検出に対応して、無線リソース解放指示が送信される。

次いで、ブロック１２１２では、無線リソース解放指示が検査され、次いで、ブロック１２１４では、無線ベアラの解放の付与が選択的に許可される。

さらなる実施形態では、ネットワークは、ユーザ機器または別のネットワーク要素からの指示の受信と、ユーザ機器に対する無線リソースプロファイルとの両方に基づいて、遷移を開始してもよい。

ユーザ機器またはネットワーク要素から受信されるような指示は、上記で説明される異なる遷移指示のうちのいずれかとなり得る。指示は、受動的となり得るため、単に、あまりバッテリ集約的ではない無線状態になるべきであるという空白指示となり得る。代替として、指示は、おそらく、経時的に、または多数の受信された指示にわたって、ネットワークが判定する、ＵＥから送信された定期的な指示の一部、およびあまりバッテリまたは無線リソース集約的ではない無線状態になるべきであるというＵＥの無線リソースプロファイルとなり得る。代替として、指示は、動的となり得て、遷移する好ましい状態またはモードについてネットワーク要素に情報を提供することができる。上記とどうように、指示は、指示の原因（例えば、正常または異常）を含有することができる。さらなる実施形態では、指示は、異なる状態またはモードに遷移する能力についてユーザ機器が的確であるという確率、または指示を誘起するアプリケーションについての情報等の、無線リソースプロファイルについて他の情報を提供することができる。

別のネットワーク要素からの指示は、例えば、メディアまたはプッシュ・トゥ・トークネットワークエンティティからの指示を含むことができる。この実施例では、指示は、トラッフィク条件が許容するときに遷移に関与しているネットワークエンティティ（例えば、ＵＴＲＡＮ）に送信される。この第２のネットワークエンティティは、インターネットプロトコル（ＩＰ）レベルでトラフィックを見て、遷移指示を送信するかどうか、およびいつ送信するかを判定することができる。

さらなる実施形態では、ＵＥまたは第２のネットワーク要素からの指示は、明示的よりもむしろ暗示的となり得る。例えば、遷移指示は、アウトバウンドトラフィック測定値についてのデバイス状態報告から、遷移に関与しているネットワーク要素（例えば、ＵＴＲＡＮ）によって暗示されてもよい。具体的には、状態報告は、いずれのアウトバウンドデータも存在しなければ、暗示的な指示として解釈され得る、無線リンクバッファ状態を含むことができる。そのような状態報告は、単独では何も要求または指示しないＵＥから繰り返し送信することができる、測定値となり得る。

したがって、指示は、任意の信号となり得て、ユーザ機器のアプリケーションおよび無線リソースの全てに関する情報を提供する、アプリケーションベースの指示、無線リソースベースの指示、または複合指示となり得る。上記は、特定の指示に限定的となるように意図されておらず、当業者であれば、本方法および開示とともに任意の指示を使用できることを理解するであろう。

ここで、図１８を参照する。過程は、ステップ１８０１から開始し、ネットワーク要素が指示を受信するステップ１８１０に進む。

いったんネットワークがステップ１８１０で指示を受信すると、過程は、ユーザ機器に対する無線リソースプロファイルが随意でチェックされる、ステップ１８２０に進む。

本明細書で使用される場合、「無線リソースプロファイル」という用語は、ネットワーク要素の要件に応じて、種々の状況に該当し得る広義語となるように意図されている。広義語では、無線リソースプロファイルは、ユーザ機器によって利用される無線リソースについての情報を含む。

無線リソースプロファイルは、静的プロファイル要素および動的または交渉型プロファイル要素のいずれか一方または両方を含むことができる。そのような要素は、遷移プロファイル内にあるか、または遷移プロファイルから離れている、無線リソースプロファイルの一部となり得て、かつ交渉型または静的となり得る、「時間窓あたりの阻止期間および／または最大指示／要求メッセージ」値を含むことができる。

静的プロファイル要素は、無線リソース（例えば、ＲＡＢまたはＲＢ）のサービスの質、ＰＤＰコンテキスト、ネットワークが知っているＡＰＮ、および加入者プロファイルのうちの１つ以上を含んでもよい。

当業者によって理解されるように、サービスの質の種々のレベルが、無線リソースについて存在することができ、サービスの質のレベルは、異なる状態またはモードに遷移するかどうかについて、ネットワークに情報を提供することができる。したがって、サービスの質がバックグラウンドであれば、ネットワーク要素は、サービスの質が双方向に設定された場合よりも容易に、アイドルに遷移することを考慮してもよい。さらに、複数の無線リソースが同じサービスの質を有する場合、これは、モバイルデバイスをより好適な状態またはモードに遷移させるか、または無線リソースを解除するかどうかについて、ネットワークに指示を提供することができる。いくつかの実施形態では、１次または２次ＰＤＰコンテキストは、異なるサービスの質を有することができ、それはまた、状態／モード遷移を行うかどうかについての決定にも影響を及ぼし得る。

さらに、ＡＰＮは、ネットワークに、ＰＤＰコンテキストが利用する典型的サービスについての情報を提供することができる。例えば、ＡＰＮがｘｙｚ．ｃｏｍであれば、その場合、ｘｙｚ．ｃｏｍは、典型的にはＥメール等のデータサービスの提供に使用され、これは、異なる状態またはモードを遷移するか否かについて、ネットワークに指示を提供することができる。これはさらに、ルーティング特性を示すことができる。

具体的には、本方法および装置は、種々の状態間で遷移プロファイルを設定するために、ＵＥによって特定されるアクセスポイント名（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ／ＡＰＮ）を利用することができる。これは、ＵＥの加入を説明する別の方法であってもよい。理解されるように、ホームロケーションレジスタ（Ｈｏｍｅ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ／ＨＬＲ）が、加入者についての関連情報を記憶してもよく、無線ネットワークコントローラ（ＲＮＣ）にＵＥの加入を提供することができる。加入情報を中央で記憶するために、他のネットワークエンティティも使用することができる。ＨＬＲを使用しても、または他のネットワークエンティティを使用しても、情報は、好ましくは、加入者情報をデータ交換中に使用される関連物理パラメータにマップする、ＲＮＣおよびＳＧＳＮ等の他のネットワーク構成要素にプッシュ配信される。

ＵＴＲＡＮは、種々のＡＰＮまたはＱｏＳパラメータを特定の遷移プロファイルに結び付けることができる、データベースまたはテーブルへのアクセスを含むか、または有することができる。したがって、ＵＥが常時オンデバイスである場合、これはＡＰＮから明白となり、そのＡＰＮに対する適切な遷移プロファイルは、無線リソースプロファイルの一部としてＵＴＲＡＮで記憶することができ、または、ＵＴＲＡＮによって遠隔でアクセス可能となり得る。同様に、ＱｏＳまたはＱｏＳパラメータの一部分が使用されるか、または専用メッセージがプロファイルとともに送信される場合、これは、データベースクエリまたはテーブルの参照に基づいて、特定の遷移プロファイルが所望されることをＵＴＲＡＮに知らせることができる。加えて、ＲＲＣ接続状態遷移プロファイルを越えた数多くの動作を、この手段によって特定することができる。これらは、以下を含むが、それらに限定されない。
速度適応アルゴリズム（ステップの周期性／ステップサイズ）、
初期許可無線ベアラ、
最大許可無線ベアラ、
呼設定時間の最小限化（トラフィック量測定等の不必要なステップの回避）、および
エアインターフェース（ＧＰＲＳ／ＥＤＧＥ／ＵＭＴＳ／ＨＳＤＰＡ／ＨＳＵＰＡ／ＬＴＥ等）。

さらに、１次コンテキスト、２次コンテキスト等の、異なるＱｏＳ要件を有するが、同じＡＰＮ ＩＰアドレスを共有する、複数のＰＤＰコンテキストがある場合、異なる遷移プロファイルを各コンテキストに使用することができる。これは、ＱｏＳまたは専用メッセージを通してＵＴＲＡＮに信号伝達することができる。

複数のアクティブＰＤＰコンテキストが同時に利用される場合、コンテキスト間の最小公分母を使用することができる。ＲＲＣ状態遷移については、１つのアプリケーションが、システムが早急にＣＥＬＬ＿ＤＣＨ状態からＣＥＬＬ＿ＰＣＨまたはアイドル状態になる、遷移プロファイルと関連付けられる第１のＰＤＰコンテキストと、システムがより長くＣＥＬＬ＿ＤＣＨ状態にとどまるものである、遷移プロファイルと関連付けられる第２のＰＤＰコンテキストとを有する場合、ＣＥＬＬ＿ＤＣＨ状態がより長く維持される第２のプロファイルが、第１のプロファイルに優先する。

当業者によって理解されるように、最小公分母は、２つの異なる方法で考慮することができる。本明細書で使用されるような最小公分母は、異なる状態に遷移する前に必要とされる最長の時間を暗示する。第１の実施形態では、最小公分母は、有効化されたＰＤＰの中の最小のものであってもよい。代替実施形態では、最小公分母は、実際にアクティブ無線リソースを有するＰＤＰの中の最小のものであってもよい。無線リソースは、多数の異なる様式で多重化することができるが、最終結果は同じである。

そのような方法の例示的な事例は、常時オンデバイスについて描くことができる。説明されるように、種々のＡＰＮまたはＱｏＳパラメータは、常時オンに対する特定の動作に結び付けることができる。「常時オン」プロファイルに基づいて望ましくてもよい、最初に許可された無線リソースを考慮されたい。ここで、ネットワークは、データバーストが、Ｅメール等の常時オンアプリケーションについて短く集中的であることを「知る」手段を有する。当業者にとって、この情報を考慮すると、ネットワーク上のトランキング効率のためにコード空間を節約する誘因がないことが明確に分かる。したがって、他のユーザのために十分なコード空間を取っておかないという危険性がほとんどなく、最大速度が常時オンデバイスに割り当てられてもよい。加えて、ＵＥは、より急速にデータを受信する恩恵を受け、また、より短い「オン時間」により、バッテリ寿命を節約する。再度、当業者にとって、データ転送速度にかかわらず、電力増幅器が完全にバイアスされるため、高データ転送速度は電流引き込みにほとんど影響を及ぼさない。

上記の実施形態では、ＵＥに対する所与のＲＲＣ接続のために、異なるアプリケーションについて割り当てられる無線リソースに対するリソース制御プロファイルを判定するために、ＵＴＲＡＮによって参照テーブルを使用することができる。ＲＮＣが、利用可能なより最新式のトラフィックリソース（すなわち、許可することができるデータ転送速度）を有するため、プロファイルは、ユーザ加入に基づき、ＨＬＲ等のネットワークエンティティにおいて、または代替としてＲＮＣにおいて、ネットワーク側に記憶することができる。より高速のデータ転送速度を達成することができる場合、より短いタイムアウトが可能であってもよい。

ＡＰＮの代わりに、パケットデータプロトコル（Ｐａｃｋｅｔ Ｄａｔａ Ｐｒｏｔｏｃｏｌ／ＰＤＰ）コンテキスト活性化または修正ＰＤＰコンテキストにおいて設定されるサービスの質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ／ＱｏＳ）パラメータ等の、他の代替案を使用することができる。ＱｏＳフィールドはさらに、同じＡＰＮを共有する複数のＰＤＰコンテキスト、または遷移プロファイルを設定する加入プロファイルの場合に、ＱｏＳ「割当保持優先順位（トラフィックデータ量を推測するために、サービスデータ単位を使用することができる）」を含むことができる。さらなる代替案は、リソース制御プロファイルを信号伝達する上記の指示メッセージ等の専用メッセージ、および時間窓あたりの阻止期間および／または最大指示／要求メッセージ値等の情報を含む。

無線リソースプロファイルに含まれる遷移プロファイルはさらに、アプリケーションの種類に基づいて、ＵＥの状態を全く遷移させるべきかどうかを含むことができる。具体的には、ユーザ機器がデータモデムとして使用されている場合、遷移指示が送信されないように、選好がユーザ機器上で設定されてもよく、または、選好の知識がネットワークにおいて維持される場合、データモデムとして使用されている間にＵＥから受信される任意の遷移指示は、無視されるべきである。したがって、ユーザ機器上で実行されているアプリケーションの性質を、無線リソースプロファイルの一部として使用することができる。

遷移プロファイルのさらなるパラメータは、遷移の種類を伴うことができる。具体的には、ＵＭＴＳネットワークにおいて、ユーザ機器は、種々の理由で、アイドル状態になるよりもむしろＣｅｌｌ＿ＰＣＨ状態になることを好んでもよい。１つの理由は、データが送信または受信される必要がある場合に、ＵＥがより早急にＣｅｌｌ＿ＤＣＨ状態に接続する必要があり、したがって、Ｃｅｌｌ＿ＰＣＨ状態になることは、Ｃｅｌｌ＿ＰＣＨ状態への早急な遷移を依然として提供しながら、いくつかのネットワーク信号伝達およびバッテリリソースを節約するという点となり得る。上記は、非ＵＭＴＳネットワークで同等に適用可能であり、種々の接続状態とアイドル状態との間の遷移プロファイルを提供してもよい。

遷移プロファイルはまた、時間窓あたりの阻止期間および／または最大指示／要求メッセージ、遅延タイマ、および非活動タイマを含むが、それらに限定されない、種々のタイマを含んでもよい。遅延タイマは、新規状態またはモードに遷移する前にネットワーク要素が待つ期間を提供する。理解されるように、たとえアプリケーションが特定の期間にわたって活動していなくても、さらなるデータがアプリケーションから受信または伝送されないことを確実にするために、遅延が有益であってもよい。非活動タイマは、データがプリケーションによって受信または送信されない所定の期間を測定することができる。非活動タイマが期限切れになる前にデータが受信された場合、典型的には、非活動タイマはリセットされる。いったん非活動タイマが期限切れになると、ユーザ機器は、ネットワークにステップ１８１０の指示を送信してもよい。代替として、ユーザ機器は、ステップ１８１０の指示を送信する前に、遅延タイマについて定義される期間等の、ある期間にわたって待ってもよい。

さらに、遅延タイマ、または時間窓あたりの阻止期間および／または最大指示／要求メッセージは、ネットワーク要素に提供されるプロファイルに基づいて変動することができる。したがって、異なるモードまたは状態への遷移を要求したアプリケーションが、Ｅメールアプリケーション等の第１の種類のアプリケーションである場合、ネットワーク要素上の遅延タイマを第１の遅延時間に設定することができ、一方で、アプリケーションが、インスタントメッセージングアプリケーション等の第２の種類である場合、遅延タイマを第２の値に設定することができる。時間窓あたりの阻止期間および／または最大指示／要求メッセージ、遅延タイマ、または非活動タイマの値はまた、特定のＰＤＰに利用されるＡＰＮに基づいて、ネットワークによって導出することもできる。

当業者によって理解されるように、非活動タイマは、同様に、利用されるアプリケーションに基づいて変動することができる。したがって、Ｅメールアプリケーションが別個のメッセージを予期しており、その後にデータを受信しない場合があるため、Ｅメールアプリケーションは、ブラウザアプリケーションよりも短い非活動タイマを有してもよい。逆に、ブラウザアプリケーションは、より長い遅延後でさえもデータを利用し、したがって、より長い非活動タイマを必要としてもよい。

遷移プロファイルはさらに、ユーザ機器が正しく遷移を要求している確率を含んでもよい。これは、特定のユーザ機器またはユーザ機器上のアプリケーションの正確率についてまとめられた統計に基づくことができる。

遷移プロファイルはさらに、種々の不連続受信（ＤＲＸ）時間値を含んでもよい。さらに、ＤＲＸ時間に対する進行プロファイルを、遷移プロファイルの中で提供することができる。

遷移プロファイルは、アプリケーションごとに定義することができるか、または、ユーザ機器上の種々のアプリケーションの複合物となり得る。

当業者によって理解されるように、遷移プロファイルは、無線リソースが割り当てられると動的に作成または修正することができ、加入、ＰＳ登録、ＰＤＰ有効化、ＲＡＢまたはＲＢ有効化の状態で終了するか、またはＰＤＰあるいはＲＡＢ／ＲＢについてオンザフライで変更することができる。遷移プロファイルはまた、ステップ１８１０の指示の一部にもなり得る。この場合、ネットワークは、好ましいＲＲＣ状態指示を考慮して、遷移を可能にするかどうか、およびどの状態／モードにするかを判定してもよい。修正は、とりわけ、利用可能なネットワークリソース、トラフィックパターンに基づいて生じることができる。

したがって、無線リソースプロファイルは、静的および／または動的フィールドから成る。特定のネットワークによって使用される無線リソースプロファイルは、他のネットワークと異なってもよく、上記の説明は、本方法およびシステムを限定するように意図されていない。具体的には、無線リソースプロファイルは、上記で説明される種々の要素を含み、かつ除外することができる。例えば、場合によっては、無線リソースプロファイルは、単に、特定の無線リソースのサービスの質を含み、他の情報を含まない。他の場合においては、無線リソースプロファイルは、遷移プロファイルのみを含む。依然として他の場合においては、無線リソースプロファイルは、とりわけ、サービスの質、ＡＰＮ、ＰＤＰコンテキスト、遷移プロファイルの全てを含む。

随意で、無線リソースプロファイルに加えて、ネットワーク要素はまた、不必要な遷移を回避するために防護対策を利用することもできる。そのような防護対策は、所定期間に受信される指示の数、受信される指示の総数、トラフィックパターン、および履歴データを含むことができるが、それらに限定されない。

所定期間に受信される指示の数は、遷移が発生するべきではないことをネットワークに示すことができる。したがって、ユーザ機器が、例えば、３０秒の期間内に５つの指示を送信した場合、ネットワークは、指示を無視し、遷移を行うべきではないと考慮してもよい。代替として、ネットワークは、無期限に、または、ある構成された期間あるいは所定の期間にわたって、さらなる指示を送信すべきではないことをＵＥに示すことを判定してもよい。これは、ＵＥ上のいずれの「時間窓あたりの阻止期間および／または最大指示／要求メッセージ」とも無関係となり得る。

さらに、ＵＥは、構成された期間、所定の期間、交渉された期間にわたって、さらなる指示を送信しないように構成することができる。ＵＥ構成は、上記で説明されるネットワーク側の防護対策を除くことができる。

トラフィックパターンおよび履歴データは、遷移が発生すべきではないという指示をネットワークに提供することができる。例えば、ユーザが過去に月曜から金曜の午前８：３０から８：３５の間に有意量のデータを受信していた場合、指示が木曜の午前８：３２に受信されると、さらなるデータが午前８：３５よりも前にあり得るため、ネットワークは、ユーザ機器を遷移するべきではないと決定してもよい。

複数の無線リソースがユーザ機器について割り当てられる場合、ネットワークは、ユーザ機器に対する完全無線リソースプロファイルを考慮する必要があってもよい。この場合、ユーザ機器に対する無線リソースプロファイルを検査することができ、複合遷移決定を行うことができる。１つまたは複数の無線リソースの無線リソースプロファイルに基づいて、ネットワークは、遷移が行われるべきか否かを決定することができる。

一実施形態では、ネットワークは、ステップ１８１０で指示を受信したとき、および随意で、ステップ１８２０で１つまたは複数の無線リソースプロファイルを検査したときに、どのように進むかについて複数の選択肢を有する。

第１の選択肢は、何もしないことである。ネットワークは、遷移が保証されないことを決定し、したがって、遷移するユーザ機器指示を受け入れなくてもよい。当業者によって理解されるように、状態が変更されないため、具体的には、遷移が誘起されないため、何もしないことにより、ネットワーク信号伝達を節約する。

第２の選択肢は、デバイスの状態を変化させることである。例えば、ＵＭＴＳネットワークでは、デバイスの状態は、Ｃｅｌｌ＿ＤＣＨからＣｅｌｌ＿ＰＣＨに変化してもよい。非ＵＭＴＳネットワークでは、状態遷移は、接続状態の間で発生してもよい。当業者によって理解されるように、状態を変化させることにより、アイドルモードへの遷移と比較すると、コアネットワーク信号伝達の量が低減する。Ｃｅｌｌ＿ＰＣＨ状態が専用チャネルを必要としないため、状態を変化させることにより、無線リソースを節約することもできる。また、Ｃｅｌｌ＿ＰＣＨは、あまりバッテリ集約的ではない状態であり、ＵＥがバッテリ電力を保存することを可能にする。

ネットワークの第３の選択肢は、ＵＥを同じ状態で保つが、特定のＡＰＮまたはＰＤＰコンテキストと関連付けられた無線リソースを解放することである。接続がその現在の状態で維持され、再確立されることを必要としないため、このアプローチは、無線リソースおよび信号伝達を節約する。しかしながら、ＵＥバッテリ寿命が懸念である状態にとっては、あまり好適ではない場合がある。

ネットワークの第４の選択肢は、ＵＥをアイドルモードに遷移させることである。特に、ＵＭＴＳおよび非ＵＭＴＳの両方では、ネットワークは、接続モードからアイドルモードになってもよい。理解されるように、全く接続が維持されないため、これは無線リソースを節約する。それはさらに、ユーザ機器上のバッテリ寿命を節約する。しかしながら、接続を再確立するために、より大量のコアネットワーク信号伝達が必要とされる。

ネットワークの第５の選択肢は、データ転送速度割当を変更することであり、それは、無線リソースを節約し、典型的には、より多くのユーザがネットワークを利用できるようにする。

他の選択肢が、当業者にとって明白となるであろう。

５つ以上の選択肢のうちのどれを利用するかについてのネットワークの決定は、ネットワークによって異なる。いくつかの過負荷ネットワークは、無線リソースを保存することを好んでもよく、したがって、上記の第３、第４、または第５の選択肢を選択してもよい。他のネットワークは、信号伝達を最小限化することを好み、したがって、上記の第１または第２の選択肢を選択してもよい。

決定は図１８のステップ１８３０で示され、ユーザ機器に対する無線リソースプロファイルとともに、ネットワーク選好に基づいてもよい。決定は、ユーザ機器が、別の状態、例えば、あまりバッテリ集約的ではない状態に遷移したいという、ユーザ機器からの指示を受信する、ネットワークによって誘起される。

ここで、図１９を参照する。図１９は、上記の図１８に示された決定を行うように適合される、簡略化したネットワーク要素を図示する。ネットワーク要素１９１０は、ユーザ機器と通信するように適合される、通信サブシステム１９２０を含む。当業者によって理解されるように、通信サブシステム１９２０は、ユーザ機器と直接通信する必要がなく、ユーザ機器を往復する通信のための通信経路の一部となり得る。

ネットワーク要素１９１０はさらに、プロセッサ１９３０および記憶部１９４０を含むことができる。記憶部１９４０は、ネットワーク要素１９１０によってサービス提供されている各ユーザ機器に対する、事前構成された、または静的な無線リソースプロファイルを記憶するように構成される。プロセッサ１９３０は、通信サブシステム１９２０による指示の受信時に、ユーザ機器に対する無線リソースプロファイルを考慮するように、およびユーザ機器の遷移に関するネットワークアクションを決定するように適合される。当業者によって理解されるように、通信サブシステム１９２０によって受信される指示はさらに、ユーザ機器に対する無線リソースプロファイルの一部分または全てを含むことができ、それは次いで、任意の遷移に関するネットワーク決定を行うために、プロセッサ１９３０によって利用される。

したがって、上記に基づいて、ネットワーク要素は、遷移が順序正しいかもしれない（例えば、データ交換が完了したとき、および／またはＵＥにおいてさらなるデータが見込まれない等）という、ユーザ機器からの指示を受信する。この指示に基づいて、ネットワーク要素は、随意で、静的および動的プロファイル要素の両方を含むことができる、ユーザ機器の無線リソースプロファイルをチェックする。ネットワーク要素はさらに、不必要な遷移が発生していないことを確実にするように、防護対策をチェックしてもよい。次いで、ネットワーク要素は、何もしないこと、または異なるモードあるいは状態に遷移すること、または無線リソースを解除することを決定することができる。理解されるように、これは、ネットワークに、その無線リソースのさらなる制御を提供し、単なるユーザ機器選好よりもむしろネットワーク選好に基づいて、ネットワークが遷移決定を構成することを可能にする。さらに、場合によっては、ネットワークは、遷移するかどうかに関して、デバイスよりも多くの情報を有する。例えば、ユーザ機器には、アップストリーム通信の知識があり、これに基づいて、接続が解除されてもよいことを決定してもよい。しかしながら、ネットワークは、ユーザ機器に対するダウンストリーム通信を受信しており、したがって、接続を解除できないことを自覚している場合がある。この場合、近い将来に、いずれのデータもユーザ機器について受信されないという、さらなる確信を持って、ネットワークを提供するために、遅延タイマを使用して遅延を導入することもできる。

本明細書で説明される実施形態は、本開示の技法の要素に対応する要素を有する、構造、システム、または方法の実施例である。この書面による説明は、当業者が、同様に本開示の技法の要素に対応する代替要素を有する実施形態を作製および使用することを可能にしてもよい。したがって、本開示の技法の対象とする範囲は、本明細書で説明されるような本開示の技法と異ならない、他の構造、システム、または方法を含み、さらに、本明細書で説明されるような本開示の技法とごくわずかに異なる、他の構造、システム、または方法を含む。

Claims (1)

1. 本願明細書に記載されたシステム。

Images