状態/モード遷移のための方法および装置
【課題】状態/モード遷移のための方法および装置の提供。
【解決手段】異なる状態または異なるモードにユーザ機器を遷移させるために遷移指示を送信する方法であって、該方法は、ネットワークから構成メッセージを受信することと、該ユーザ機器から遷移指示を伝送することであって、該遷移指示は、該構成メッセージが遷移阻止指示を含む場合には原因のみを含む、こととを包含する。また、ユーザ機器からの遷移の指示であって、該ユーザ機器が異なる状態または異なるモードへの遷移を所望することを指示する、指示を処理する方法であって、該方法は、該ユーザ機器から該遷移指示を受信することと、該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することとを包含する。
【解決手段】異なる状態または異なるモードにユーザ機器を遷移させるために遷移指示を送信する方法であって、該方法は、ネットワークから構成メッセージを受信することと、該ユーザ機器から遷移指示を伝送することであって、該遷移指示は、該構成メッセージが遷移阻止指示を含む場合には原因のみを含む、こととを包含する。また、ユーザ機器からの遷移の指示であって、該ユーザ機器が異なる状態または異なるモードへの遷移を所望することを指示する、指示を処理する方法であって、該方法は、該ユーザ機器から該遷移指示を受信することと、該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することとを包含する。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ユーザ機器(UE)または他のワイヤレスあるいはモバイルデバイスと、ワイヤレスネットワークとの間の無線リソース制御に関し、具体的には、例えば、Universal Mobile Telecommunication System(UMTS)ネットワーク等の、ワイヤレスネットワークにおいて、動作の状態およびモードの間で遷移するステップに関する。
【背景技術】
【0002】
Universal Mobile Telecommunication System(UMTS)は、テキスト、デジタル化音声、ビデオ、およびマルチメディアの伝送用の広帯域でパケットベースのシステムである。それは、第3世代の基準に高度に同意しており、概して、広帯域符号分割多重アクセス(W−CDMA)に基づく。
【0003】
UMTSネットワークでは、プロトコルスタックの無線リソース制御(RRC)部が、UEとUTRANとの間の無線リソースの割当、構成、および解放に関与している。このRRCプロトコルは、3GPP TS 25.331仕様書で詳細に説明されている。UEがとり得る2つの基本モードは、「アイドルモード」および「UTRA RRC接続モード」(または単に、本明細書で使用されるような「接続モード」)として定義される。UTRAは、UMTS地上波無線アクセスを表す。アイドルモードでは、UEまたは他のモバイルデバイスは、任意のユーザデータを送信したいときはいつでも、または、UTRANあるいはサービング汎用パケット無線サービス(GPRS)サポートノード(SGSN)ページといった、ページに応じて、プッシュサーバ等の外部データネットワークからデータを受信したいときはいつでも、RRC接続を要求する必要がある。アイドルモードおよび接続モードの動作は、第3世代パートナーシッププロジェクト(3GPP)仕様書TS 25.304およびTS 25.331で詳細に説明されている。
【0004】
UTRA RRC接続モードであるときに、デバイスは、4つの状態のうちの1つとなり得る。これらは、以下の通りである。
CELL_DCH:データを交換するように、この状態ではアップリンクおよびダウンリンクで専用チャネルがUEに割り当てられる。UEは、3GPP 25.331で概説されるようなアクションを行わなければならない。
CELL_FACH:この状態では、いずれの専用チャネルもユーザ機器に割り当てられない。その代わり、少量の集中的データを交換するために共通チャネルが使用される。UEは、3GPP TS 25.304で定義されるようなセル選択過程を含む、3GPP
25.331で概説されるようなアクションを行わなければならない。
CELL_PCH:UEは、ページングインジケータチャネル(PICH)を介して同報通信メッセージおよびページを監視するために、不連続受信(DRX)を使用する。いずれのアップリンク活動も可能ではない。UEは、3GPP TS 25.304で定義されるようなセル選択過程を含む、3GPP 25.331で概説されるようなアクションを行わなければならない。UEは、セル再選択後に、セル更新手順を行わなければならない。
URA_PCH:UEは、ページングインジケータチャネル(PICH)を介して同報通信メッセージおよびページを監視するために、不連続受信(DRX)を使用する。いずれのアップリンク活動も可能ではない。UEは、3GPP TS 25.304で定義されるようなセル選択過程を含む、3GPP 25.331で概説されるようなアクションを行わなければならない。この状態は、URA更新手順がUTRAN登録エリア(URA)の再選択を介してのみ誘起されることを除いて、CELL_PCHと同様である。
【0005】
アイドルモードから接続モードへの遷移、およびその逆は、UTRANによって制御される。アイドルモードUEがRRC接続を要求すると、ネットワークは、UEをCELL_DCHまたはCELL_FACH状態にするかどうかを決定する。UEがRRC接続モードであるときは、この場合もやはり、RRC接続を解放するときを決定するのはネットワークである。ネットワークはまた、接続を解放する前に、または場合によっては接続を解放する代わりに、UEを1つのRRC状態から別のRRC状態にしてもよい。状態遷移は、典型的には、UEとネットワークとの間のデータ活動または非活動によって誘起される。ネットワークは、UEが所与のアプリケーションのためのデータ交換を完了したときを知らない場合があるため、典型的には、UEを往復するさらなるデータを見込んで、しばらくの間RCC接続を保つ。これは、典型的には、呼設定および後続の無線リソース設定の待ち時間を削減するように行われる。RRC接続解放メッセージは、UTRANのみによって送信することができる。このメッセージは、UEとUTRANとの間の信号リンク接続および全ての無線リソースを解放する。概して、「無線ベアラ」という用語は、UEとUTRANとの間で割り当てられる無線リソースを指す。そして、「無線アクセスベアラ」とは、概して、UEと、例えばSGSN(サービングGPRSサービスノード)との間で割り当てられる無線リソースを指す。本開示は、時折、無線リソースという用語を指すものであり、そのような用語は、必要に応じて、無線ベアラおよび/または無線アクセスベアラのいずれか一方または両方を指すものである。
【0006】
上記に関連する問題は、たとえUE上のアプリケーションがデータトランザクションを完了し、さらなるデータ交換を予期していなくても、依然としてネットワークがそれを正しい状態にすることを待つという点である。ネットワークは、UE上のアプリケーションがそのデータ交換を完了したという事実を認識していない場合さえある。例えば、UE上のアプリケーションは、UMTSコアネットワークを通してアクセスされる、そのアプリケーションサーバとデータを交換するために、独自の確認に基づくプロトコルを使用してもよい。例は、独自の保証された配信を実施する、ユーザデータグラムプロトコル/インターネットプロトコル(UDP/IP)上で作動するアプリケーションである。そのような場合、UEは、アプリケーションサーバが全てのデータパケットを送信または受信したか否かが分かり、さらなるデータ交換が行われるかどうかを判定し、したがって、パケットサービス(PS)ドメインと関連付けられたRRC接続を終結させるときを決定するのにより良好な立場にある。UTRANは、RRC接続状態が異なる状態またはアイドルモードに変更されるときを制御し、かつUTRANは、UEと外部サーバとの間のデータ配信の状態を認識していないため、UEは、必要とされるよりも早いデータ転送速度またはモードでありつづけることを余儀なくされる場合があり、移動局の減少したバッテリ寿命をもたらす可能性があり、また、無線リソースが不必要に占有されたままであり、したがって別のユーザに利用可能ではないという事実により、無駄なネットワークリソースをもたらす可能性もある。
【0007】
上記の1つの解決法は、UEがデータトランザクションを終了したことを自覚すると、UEにUTRANへ信号伝達解放指示を送信させることである。3GPP TS 25.331仕様書の第8.1.14.3項に準じて、UTRANは、UEからの信号伝達解放指示の受信時に、信号伝達接続を解放して、UEをアイドルモードまたは何らかの他のRRC状態に遷移させてもよい。上記の解決法に関連する問題は、UTRANにUEまたは他のUEからの信号伝達解放指示メッセージが殺到するかもしれないという点である。
【発明の概要】
【課題を解決するための手段】
【0008】
以下で提供される実施例および実施形態は、例えば、UMTSネットワーク等のワイヤレスネットワークにおいて、動作の種々の状態/モードの間で、ユーザ機器(UE)または他のモバイルデバイスを遷移させるための種々の方法およびシステムを説明する。他の種類のネットワークにおける他の実装も可能であることを理解されたい。例えば、同教示は、符号分割多重アクセス(CDMA)ネットワーク(例えば、3GPP2 IS−2000)、広帯域CDMA(W−CDMA)ネットワーク(例えば、3GPP UMTS /高速パケットアクセス(HSPA)、進化型UTRANネットワーク(例えば、LTE)に適用することもでき、または、一般的に言えば、ネットワーク制御された無線リソースを使用する無線アクセス技術に基づくか、あるいはデバイスアプリケーションレベルデータ交換の状態の知識を維持しない、任意のネットワークに適用することもできる。以下で説明されるが、UMTSネットワークとの関連で簡単にするために提示される、具体的実施例および実装は、これらの他のネットワーク環境にも適用可能である。さらに、ネットワーク要素は、UTRANとして以下で説明されることもある。しかしながら、UMTSの他に他のネットワーク型が利用される場合、ネットワーク型に基づいて、ネットワーク要素を適切に選択することができる。さらに、ネットワーク要素は、UMTSシステムまたは任意の他の適切なネットワークシステム内のコアネットワークとなり得て、その場合、ネットワーク要素は、遷移決定を行うエンティティである。
【0009】
特定の実施例では、本システムおよび方法は、ネットワークにおける意思決定能力を提供しながら、RRC接続モードから、よりバッテリ効率の良い、または無線リソース効率の良い状態あるいはモードへの遷移を提供する。具体的には、本方法および装置は、暗示的または明示的に、無線リソースとの特定の信号伝達接続と関連付けられた、RCC状態またはモードの別の状態またはモードへの遷移が発生するべきであると示す、UEからの指示の受信に基づいて、遷移を提供する。理解されるように、そのような遷移指示または要求は、現在の基準下での既存の通信、例えば、信号伝達接続解放指示メッセージを利用することができ、または、「好ましいRRC状態要求」あるいは「データ転送完了指示メッセージ」等の、UEの状態を変更する新規の専用メッセージとなり得る。データ転送完了指示メッセージは、上位層データ転送の完了を示すメッセージである。本明細書で使用されるように、指示は、いずれのシナリオも指すことができ、かつ要求を組み込むことができる。
【0010】
UEによって発信される遷移指示は、UE上の1つ以上のアプリケーションがデータの交換を完了したとき、および/または、UEがさらなるデータを交換すると見込まれないという判定が行われたときの、いくつかの状況で送信することができる。次いで、ネットワーク要素は、モバイルデバイスを別のモードまたは状態に遷移させるか、何もしないかについて、ネットワーク特有の決定を行うために、指示およびその中で提供される任意の情報、ならびに、とりわけ、サービスの質、アクセスポイント名(APN)、パケットデータプロトコル(PDP)コンテキスト、履歴情報等の、本明細書で無線リソースプロファイルとして定義される、無線リソースに関係する他の情報を使用することができる。UEまたはモバイルデバイスによって提供される遷移指示は、いくつかの形態を取ることができ、かつ異なる条件下で送信することができる。第1の実施例では、遷移指示は、UE上に常駐するアプリケーションの全ての複合状態に基づいて送信することができる。具体的には、UMTS環境では、UE上のアプリケーションがデータの交換を終了したと判定した場合、「終了」指示をUEソフトウェアの「接続マネージャ」コンポーネントに送信することができる。接続マネージャは、一実施形態では、全ての既存アプリケーション(1つまたは複数のプロトコル上でサービスを提供するものを含む)、関連パケットデータプロトコル(PDP)コンテキスト、関連パケット交換(PS)無線リソース、および関連回線交換(CS)無線リソースを追跡することができる。PDPコンテキストは、UMTSコアネットワークにわたって作動する、UEとPDN(公衆データネットワーク)との間の論理的関連付けである。UE上の1つまたは複数のアプリケーション(例えば、Eメールアプリケーションおよびブラウザアプリケーション)は、1つのPDPコンテキストと関連付けられてもよい。場合によっては、UE上の1つのアプリケーションは、1つの1次PDPコンテキストと関連付けられ、複数のアプリケーションは、2次PDPコンテキストと結び付けられてもよい。接続マネージャは、同時にアクティブであるUE上の異なるアプリケーションから、「終了」指示を受信する。例えば、ユーザは、ウェブを閲覧しながらプッシュサーバからEメールを受信してもよい。Eメールアプリケーションは、確認を送信した後に、そのデータトランザクションを完了したことを示してもよい。ブラウザアプリケーションは、異なる行動をし、代わりに、接続マネージャに「終了」指示を送信するときの(例えば、非活動タイマを使用するための)予測判定を行ってもよい。
【0011】
アクティブアプリケーションからのそのような指示の複合状態に基づいて、UEソフトウェアは、遷移指示を送信することを決定して、1つの状態またはモードから別の状態またはモードへの遷移が発生すべきであることをネットワークに指示または要求することができる。代替として、UEソフトウェアは、代わりに、遷移指示を送信する前に待って遅延を導入し、アプリケーションが本当にデータ交換を終了し、バッテリまたは無線リソース集中状態またはモードで維持される必要がないことを確実にすることができる。遅延は、トラフィック履歴および/またはアプリケーションプロファイルに基づいて動的となり得る。ある確率で、アプリケーションがデータを交換することが見込まれると接続マネージャが判定するときはいつでも、ネットワークに遷移指示を送信して、遷移が発生すべきであると示すことができる。具体的実施例では、遷移指示は、アイドルモードへの遷移を要求する、適切なドメイン(例えば、PSドメイン)のための信号伝達接続解放指示となり得る。代替として、遷移指示は、UTRANへの接続モード内の状態遷移の要求となり得る。
【0012】
以下でさらに詳細に説明されるように、遷移指示、および随意で、無線リソースプロファイルの受信に基づいて、UMTS環境内のUTRAN等のネットワーク要素は、1つの状態またはモードから別の状態またはモードにUEを遷移させることを決定することができる。
【0013】
他の遷移指示が可能である。例えば、UE上の全てのアクティブアプリケーションの複合状態に依存する代わりに、UEソフトウェアは、代替実施形態で、UEアプリケーションがデータの交換を完了するたびに、および/またはアプリケーションがさらなるデータを交換すると見込まれないたびに、遷移指示を送信することができる。この場合、ネットワーク要素(例えば、UTRAN)は、以下の図18を参照して説明されるような、UEのオプションの無線リソースプロファイルに基づいて、遷移決定を行うために指示を利用することができる。
【0014】
さらに別の実施例では、遷移指示は、単に、UE上の1つ以上のアプリケーションがデータ交換を完了した、および/または、UEアプリケーションがさらなるデータを交換すると見込まれないと示すことができる。その指示およびUEのオプションの無線リソースプロファイルに基づいて、ネットワーク(例えば、UTRAN)は、より適切な状態またはモードまたは動作にUEを遷移させるかどうかを決定することができる。
【0015】
さらなる実施例では、遷移指示は、明示的よりもむしろ暗示的となり得る。例えば、指示は、周期的に送信される状態報告の一部であってもよい。そのような状態報告は、無線リンクバッファがデータを有するかどうか等の情報をふくむことができ、またはアウトバウンドトラフィック上に情報を含むことができる。
【0016】
UEは、遷移指示を送信するときに、指示に対する行動を決定するのにネットワーク要素を支援するために、追加情報を含んでもよい。この追加情報は、UEがメッセージを送信する理由または原因を含む。この原因または理由(以下でさらに詳細に説明される)は、「急速休眠」のような動作の必要性を判定するUEに基づく。そのような追加情報は、新規の情報要素、または遷移指示メッセージ内の新規パラメータを介したものであってもよい。
【0017】
さらなる実施形態では、以前の遷移指示が送信されてから、ある期間が経過するまで(阻止期間)遷移指示が送信されなくてもよいことを確実にするように、UE上にタイマが存在することができる。この阻止タイマは、UEが遷移指示メッセージを過剰に頻繁に送信することを制限し、さらに、所与の最大頻度のみで誘起されるメッセージに依存することによって、ネットワークが判定を行うことを可能にする。期間は、その値が事前構成されるか、またはネットワークによって設定される(指示または信号伝達される)タイマによって、判定することができる。値がネットワークによって設定される場合、それは、とりわけ、RRC接続要求、RRC接続解放、無線ベアラ設定、UTRANモビリティ情報、またはシステム情報ブロック等の、新規または既存のメッセージの中で伝えることができ、かつこれらのメッセージの中の情報要素となり得る。値は、代替として、例えば、UEから受信されたRRC接続要求メッセージに応じてUTRANによって送信される、RRC接続設定メッセージの遷移阻止指示部分の中で伝えることができる。
【0018】
代替実施形態では、その種類がUEの状態に依存するメッセージの中で、値をUEに伝えることができる。例えば、ネットワークは、IDLE、URA_PCH、Cell_PCH、またはCELL_FACH状態であるときにUEによって読み取られるシステム情報メッセージの一部分として、全てのUEに値を送信することができる。
【0019】
さらに別の実施形態では、RRC接続設定メッセージの一部分として値を送信することができる。
【0020】
ネットワーク生成されたメッセージはまた、メッセージの中、またはメッセージ内の情報要素の中に阻止タイマを含まないことにより、暗示阻止タイマ値を伝えてもよい。例えば、阻止タイマが受信メッセージから省略されていることを判定すると、UEは、阻止タイマ値として使用するために所定の値を適用する。阻止タイマ値の省略の1つの例示的な使用は、UEが遷移指示メッセージを送信することを禁止するものである。そのような状況では、UEが受信メッセージの中の予期された阻止タイマ値の省略を検出すると、UEは、省略に基づいて、あらゆる遷移指示メッセージを送信することが禁止されてもよい。このことを達成するための1つの方法は、UEが無限の阻止タイマ値を採択することである。
【0021】
別の実施形態では、UEは、阻止タイマ値の省略を検出すると(かつ、例えば、無限の阻止タイマ値を採択すると)、いずれの追加情報も含まずに遷移指示を送信してもよく、具体的には、遷移指示の送信を誘起するための原因を省略してもよい(以下でさらに詳細に説明される)。遷移指示メッセージの中の原因要素の省略は、UEが遷移を要求または指示するために既存の遷移指示メッセージ(例えば、信号伝達接続解放指示)を使用できるようにすることによって、後方互換性を確保してもよい。
【0022】
受信メッセージに阻止タイマを含まないことは、システム情報ブロックがセルの中で同報通信されるか、またはUEに送信され、かつシステム情報ブロックが阻止タイマ値を伝えるように構成される、例示的実施形態を参照して、さらに詳述される。この実施形態では、UEが、メッセージまたはメッセージ内の情報要素にT3xxとして知られる阻止タイマを含有しない、システム情報ブロックを受信する場合、UEは、例えば、阻止タイマT3xxを無限に設定することによって、UEが遷移指示メッセージを送信できなくなることを判定してもよい。
【0023】
阻止タイマを含まないことは、阻止タイマT3xxがUTRANモビリティ情報メッセージから省略される、別の例示的実施形態を参照して、さらに詳述される。そのような状況では、受信UEは、以前に記憶された阻止タイマ値を引き続き適用してもよい。代替として、UEは、阻止タイマT3xxの省略を検出すると、例えば、阻止タイマT3xxを無限に設定することによって、UEが遷移指示メッセージを送信できなくなることを判定してもよい。
【0024】
さらに別の例示的実施形態では、UEは、受信メッセージの中またはメッセージ内の情報要素の中の阻止タイマの省略を検出すると、阻止タイマ値を別の事前設定値(例えば、0秒、5秒、10秒、15秒、20秒、30秒、1分、1分30秒、2分のうちの1つ)に設定する。代替として、または加えて、これらの実施例は、他のネットワーク生成されたメッセージを適用してもよい。
【0025】
他の実施形態では、阻止タイマ(値)がメッセージまたは情報要素の中でUEに送信または信号伝達されなかった場合、または、1つのセルから別のセルへ遷移する際に、阻止タイマが同報通信システム情報から読み取られないか、または他の専用UTRANメッセージから受信されなかった場合、遷移指示の送信は、発生してもしなくてもよい。
【0026】
具体的には、一実施形態で、UEは、いずれの阻止タイマも存在しないことを検出すると、伝送するPSがもうないことを判定する上位層に基づいて、遷移指示を開始しない。
【0027】
代替実施形態では、UEは、いずれの阻止タイマも存在しないことを検出すると、伝送するPSがもうないことを判定する上位層に基づいて、遷移指示を開始しなくてもよい。
【0028】
さらに別の実施形態では、(同報通信または他の方法を介して)いずれのタイマ値も、メッセージ内またはメッセージの中の情報要素内で、UTRANから受信されなかった場合、UEにおいてタイマ値を無限に設定するよりむしろ、UEは、阻止タイマをゼロに設定するか、または代替として、タイマの任意の構成を削除し、代わりに、遷移指示を送信することを許容されてもよい。この場合、UEは、遷移指示メッセージの中の原因を省略するか、または原因を添付することを禁止され得る。一実施形態では、信号伝達接続解放指示メッセージは、遷移指示の一例として使用される。
【0029】
一実施形態では、遷移指示は、信号伝達接続解放指示手順を使用して伝えられる。信号伝達接続解放指示手順は、その信号伝達接続のうちの1つが解放されたことを示すために、UEによって使用される。
【0030】
具体的には、TS 25.331の第8.1.14.2項に従って、UEは、特定のCNドメインに対する上層から信号伝達接続を解放する要求を受信すると、情報要素「CNドメインアイデンティティ」において識別される特定のCNドメインに対する変数「ESTABLISHED_SIGNALLING_CONNECTIONS」における信号伝達接続が存在するかどうかをチェックする。存在すれば、UEは、信号伝達接続解放指示手順を開始してもよい。
【0031】
阻止タイマ値が信号伝達されないか、あるいはUEに伝えられない場合、いずれの信号伝達接続解放指示原因も信号伝達接続解放指示メッセージの中で特定されない。当業者であれば、この代替実施形態で、タイマ値の欠如は、タイマ値を無限に設定させないことを理解するであろう。
【0032】
UTRAN側で、原因を伴わない信号伝達接続解放指示メッセージの受信時に、UTRANは、上層に、識別されたCNドメインアイデンティティに対する信号伝達接続の解放を指示する。次いで、これは、確立された無線リソース制御接続の解放を開始してもよい。
【0033】
別の代替実施形態の下で、UTRANが、UEに、タイマ値、例えば、情報要素「接続モードのUEタイマまたは制約」の中で(または、SIB1、SIB3、またはSIB4等のシステム情報を使用して、あるいは専用UTRANモビリティ情報メッセージにより)阻止タイマT3xxを信号伝達するか、または伝えると、以下に従って解放手順が発生する。第1に、UEは、示された回線交換ドメイン接続があるかどうかをチェックすることができる。そのような接続は、変数「ESTABLISHED_SIGNALLING_CONNECTIONS」において示されてもよい。いずれの回線交換ドメイン接続もない場合、長期間にわたってパケット交換ドメインデータが生じないことを上層が示すかどうかを判定する、第2のチェックが発生することができる。
【0034】
いずれの回線交換ドメイン接続もなく、かついずれのパケット交換ドメインデータも長期間にわたって予期されない場合、UEは、次に、タイマT3xxが作動しているかどうかをチェックしてもよい。
【0035】
タイマT3xxが作動していない場合、UEは、情報要素「CNドメインアイデンティティ」をパケット交換(PS)ドメインに設定する。さらに、情報要素「信号伝達接続解放指示原因」は、「UEがPSデータセッションの終了を要求した」に設定される。信号伝達接続解放指示メッセージは、AM RLCを使用して、DCCH上で伝送される。さらに、伝送後に、タイマT3xxが起動される。
【0036】
上記の手順は、上記の手順でRLCによって確認されるような、信号伝達接続解放指示メッセージの配信成功時に終了する。この実施形態では、タイマT3xxが作動している間に、またはタイマT3xxが期限切れになるまで、UEは、「UEがPSデータセッションの終了を要求した」に設定された信号伝達接続解放指示原因とともに、信号伝達接続解放指示メッセージを送信することが阻止される。
【0037】
T3xxタイマが作動しているときに、長期間にわたって、さらなるパケット交換ドメインデータがないため、信号伝達接続解放指示手順が開始される場合、UEは、T3xxタイマの満了に対して手順を開始するかどうかを実施することに関与している。UE決定は、送信する後続の信号伝達接続解放指示または要求メッセージがあるかどうかの判定に基づいてもよく、もしあれば、UE決定は、本明細書で概説されるような手順を開始するために同じチェックのうちのいくつかまたは全てを再チェックするステップを含んでもよい。
【0038】
UTRAN側で、信号伝達接続解放指示メッセージが信号伝達接続解放指示原因を含まない場合、UTRANは、上層からの信号伝達接続の解放を要求してもよく、次いで、上層は、信号伝達接続の解放を開始してもよい。一方で、受信される信号伝達接続解放指示メッセージが原因を含む場合、UTRANは、信号伝達接続を解放するか、または、よりバッテリ効率の良い状態(例えば、CELL_FACH、CELL_PCH、URA_PCH、またはIDLE_モード)への状態遷移を開始してもよい。
【0039】
上記の阻止期間は、UEが遷移したい状態に基づいてもよい。例えば、阻止期間は、携帯電話が、他の状態/モードと対比した、いくつかのRRC状態/モードの最後の選好を示したかどうかにより、異なってもよい。例えば、それは、携帯電話が、Cell_FACH状態と対比した、またはCell_PCH/URA PCH状態と対比した、アイドルモードの選好を示した場合に、異なり得る。阻止期間がネットワークによって設定される場合では、これは、シナリオに応じて使用される、携帯電話に値の2つ(以上の)のセットを指示/送信する、ネットワークによって達成されてもよい。代替として、指示は、適切な阻止期間値のみが携帯電話に指示/信号伝達されるような方法で行うことができる。例えば、UEがCell_PCHに遷移したい場合、UEがアイドルに遷移したい場合とは異なる経過期間を設定することができる。
【0040】
上記からの阻止期間は、携帯電話の現在のRRC状態/モード(例えば、Cell_DCH/Cell_FACH対Cell_PCH/URA_PCH、またはCell_DCH対Cell_FACHあるいはCell_PCH/URA_PCH)に応じて、異なってもよい。
【0041】
上記からの阻止期間は、ネットワークがすでに携帯電話からの選好RRC状態情報に作用したかどうかに応じて、異なってもよい。そのような認識は、ネットワーク上で、または携帯電話側で起こってもよい。第1の場合において、これは、ネットワークによって携帯電話に指示/信号伝達される、阻止値に影響を及ぼしてもよい。第2の場合において、阻止期間値の異なるセットは、事前構成されるか、またはネットワークによって指示/信号伝達されてもよい。特定の場合として、ネットワークが携帯電話からの選好RRC状態情報に作用した、例えば、UEによって示された状態への状態遷移を開始した場合に、阻止期間/機能性が削減されるか、または取り消されてもよい。
【0042】
上記からの阻止期間は、例えば、ネットワークの選好、特徴、能力、負荷、または容量に応じて、異なってもよい。ネットワークは、頻繁な遷移指示メッセージを受信することができる場合に、短い阻止期間を示してもよい。ネットワークは、頻繁な遷移指示メッセージを受信できない、またはしたくない場合に、長い阻止期間を示してもよい。ネットワークは、UEが遷移指示メッセージを送信することができない特定の期間を示してもよい。特定の期間は、例えば、数値的に示されてもよい(すなわち、0秒、30秒、1分、1分30秒、2分、または無限)。0秒の阻止期間を受信するUEは、遅延なしで遷移指示を送信することができる。無限の阻止期間を受信するUEは、遷移指示を送信することができない。
【0043】
阻止期間の代わりに、またはそれに加えて、時間枠あたりのメッセージの最大数(例えば、「10分ごとにわずか15のメッセージ」)が使用/特定されてもよい。
【0044】
上記の阻止期間/時間枠あたりのメッセージの最大数の組み合わせが可能である。
【0045】
一例として、本開示は、概して、UTRANによるUEからのRRC接続要求メッセージの受信を記載する。RRC接続要求メッセージを受信すると、UTRANは、例えば、要求を受け入れ、UEにRRC接続設定メッセージを送信する。RRC接続設定は、タイマT3xxとして知られる遷移阻止指示を含み得る。UEによるRRC接続設定メッセージの受信時に、UEは、例えば、以前に記憶された値を置き換えてタイマT3xxの値を記憶するか、または、タイマT3xxがRRC接続設定メッセージの中にない場合には、タイマの値を無限に設定する。いくつかの実施形態では、RRC接続設定メッセージは、UTRANが遷移阻止指示信号伝達をサポートすることをUEが知っていることを確実にするように、遷移阻止指示を含まなければならない。
【0046】
一実施形態では、DCH状態でのモビリティの間に、UEが阻止タイマに対して、その現在記憶されている値を維持することが仮定される。阻止タイマが無限に設定される、いくつかの場合では、これは、ネットワークデータ非活動タイマが期限切れになること、およびネットワークがUEをRRC状態にすることをUEが待たなければならず、その場合、阻止タイマに対する新規の値を受信または判定できることを意味してもよい。阻止タイマがハンドオーバ前に無限以外のある値である、他の場合では、UEがタイマ値を新規セルで示された値に更新することができるまで、この他の値が引き続き使用される。
【0047】
場合によっては、阻止タイマおよび遷移指示(例えば、信号伝達接続解放指示)メッセージは、いくつかのネットワークの中、またはネットワーク内のいくつかのセルの中で実装されてもよい。モビリティの目的で、遷移指示または要求メッセージを送信する機能にサポートが利用可能ではない場合(特に、原因が使用される場合)、UEは、メッセージを送信しないステップをデフォルトにするべきである。これは、不必要な伝送、および関連するネットワークリソースならびにバッテリリソースの無駄を回避する。
【0048】
加えて、モビリティの目的で、ネットワーク内で使用される異なる業者のネットワーク機器は、UEがセル間を移動するときに、UE上で更新される必要のある異なる阻止タイマを使用して、隣接するセルに至ってもよい。
【0049】
1つの代替実施形態では、これは、全てのハンドオーバおよび関連ベアラ制御メッセージが阻止タイマT3xxの値を含むことを定めることによって、取り扱われる。そのようなメッセージは、本明細書ではモビリティメッセージと呼ばれる。これは、UEがセル間を移動するときに新規の阻止タイマ値を受信できるようにする。それはまた、これらのモビリティメッセージが阻止タイマ値を含有しない場合に、UEが阻止タイマのデフォルトタイマ値を設定できるようにもする。理解されるように、いずれの阻止タイマ値もモビリティメッセージの中で受信されなかった場合、これは、セルが急速休眠に有効ではないことを示す。
【0050】
遷移指示手順の別の実施例として、これ以上PSドメインデータを転送する必要がないと判定したことをUTRANに示すために、データ転送完了指示手順がUEによって使用されてもよい。上記で説明される実施例に関連して、タイマT3xxが作動している場合、UEは、タイマT3xxが期限切れになる前にデータ転送完了指示メッセージを送信しない。
【0051】
データ転送完了指示手順は、RRCまたは上層が長期間にわたってこれ以上PSドメインデータを持たないという指示で開始する。CSドメイン接続が確立された信号伝達接続(ESTABLISHED_SIGNALLING_CONNECTIONS)という変数において
示された場合、またはタイマT3xxが無限に設定された場合に、手順が終了する。そうでなければ、タイマT3xxが作動していない(すなわち、期限切れになった)か、または0秒に設定された場合に、AM RLCまたはDCCHを使用して、データ転送完了指示メッセージが下層に提出され、その後、メッセージが下層に配信されると、タイマT3xxが起動またはリセットされる。
【0052】
UTRANは、データ転送完了指示の受信時に、よりバッテリ効率の良いRRC状態またはアイドルモードへのUE遷移を開始することを決定してもよい。
【0053】
UEは、タイマT3xxが作動している間に、データ転送完了指示メッセージを送信しないものである。
【0054】
本開示は、異なる状態または異なるモードにユーザ機器を遷移させるために遷移指示を送信する方法を提供し、該方法は、ネットワークから構成メッセージを受信することと、該ユーザ機器から遷移指示を伝送することであって、該遷移指示は、該構成メッセージが遷移阻止指示を含む場合には原因のみを含む、こととを包含する。
【0055】
本開示は、また、異なる状態または異なるモードに遷移するために遷移指示を送信するように構成されているユーザ機器を提供し、該ユーザ機器は、ネットワークから構成メッセージを受信することと、該ユーザ機器から遷移指示を送信することであって、該遷移指示は、該構成メッセージが遷移阻止支持を含む場合には原因のみを含む、こととを行うように構成されている。
【0056】
本開示は、さらに、ユーザ機器からの遷移の指示を処理する方法であって、該指示は、該ユーザ機器が異なる状態または異なるモードへの遷移を所望することを指示する、方法を提供し、該方法は、該ユーザ機器から該遷移指示を受信することと、該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することとを包含する。
【0057】
本開示は、さらに、ユーザ機器の状態またはモードを遷移させるように構成されているネットワーク要素を提供し、該ネットワーク要素は、該ユーザ機器から遷移指示を受信することと、該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することとを行うように構成されている。
【0058】
本開示は、図面を参照すると、より良好に理解されるであろう。
例えば、本発明は以下の項目を提供する。
(項目1)
異なる状態または異なるモードにユーザ機器を遷移させるために遷移指示を送信する方法であって、該方法は、
ネットワークから構成メッセージを受信することと、
該ユーザ機器から遷移指示を伝送することであって、該遷移指示は、該構成メッセージが遷移阻止指示を含む場合には原因のみを含む、ことと
を包含する、方法。
(項目2)
上記遷移阻止支持は、阻止タイマ値である、項目1に記載の方法。
(項目3)
上記構成メッセージが阻止タイマ値を含む場合、該受信された阻止タイマ値に従って、タイマを設定することをさらに包含する、項目2に記載の方法。
(項目4)
上記伝送することは、上記タイマが動作していない場合に起こる、項目3に記載の方法。
(項目5)
上記伝送することは、上記タイマが満了した場合に起こる、項目3に記載の方法。
(項目6)
新しいセルまたは新しいネットワークを獲得する際に、上記タイマをリセットすることをさらに包含する、項目3〜項目5のいずれか1項に記載の方法。
(項目7)
上記遷移指示は、信号伝達接続解放指示メッセージである、項目1〜項目6のいずれか1項に記載の方法。
(項目8)
上記遷移指示は、データ転送完了指示メッセージである、項目1〜項目7のいずれか1項に記載の方法。
(項目9)
上記ユーザ機器が新しいネットワークまたは新しいセルを獲得する際に、上記構成メッセージが受信される、項目1〜項目8のいずれか1項に記載の方法。
(項目10)
上記構成メッセージは、RRC接続要求メッセージ、RRC接続設定メッセージ、RRC接続解放メッセージ、無線ベアラ設定メッセージ、システム情報同報通信メッセージ、システム情報ブロック(SIB)メッセージ、アクティブセット更新メッセージ、セル更新確認メッセージ、UTRANコマンドへのハンドオーバメッセージ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、およびUTRANモビリティ情報メッセージから成る群より選択される、項目1〜項目9のいずれか1項に記載の方法。
(項目11)
異なる状態または異なるモードに遷移するために遷移指示を送信するように構成されているユーザ機器であって、該ユーザ機器は、
ネットワークから構成メッセージを受信することと、
該ユーザ機器から遷移指示を送信することであって、該遷移指示は、該構成メッセージが遷移阻止支持を含む場合には原因のみを含む、ことと
を行うように構成されている、ユーザ機器。
(項目12)
上記遷移阻止支持は、阻止タイマ値である、項目11に記載のユーザ機器。
(項目13)
上記構成メッセージが上記阻止タイマ値を含む場合、該受信された阻止タイマ値に従って、タイマを設定するようにさらに構成されている、項目12に記載のユーザ機器。
(項目14)
上記送信することは、上記タイマが動作していない場合に起こる、項目13に記載のユーザ機器。
(項目15)
上記送信することは、上記タイマが満了した場合に起こる、項目13に記載のユーザ機器。
(項目16)
新しいセルまたは新しいネットワークを獲得する際に、上記タイマをリセットすることをさらに包含する、項目13〜項目15のいずれか1項に記載のユーザ機器。
(項目17)
上記遷移指示は、信号伝達接続解放指示メッセージである、項目11〜項目16のいずれか1項に記載のユーザ機器。
(項目18)
上記遷移指示は、データ転送完了指示メッセージである、項目11〜項目17のいずれか1項に記載のユーザ機器。
(項目19)
上記ユーザ機器が新しいセルまたは新しいネットワークを獲得する際に、上記構成メッセージが受信される、項目11〜項目18のいずれか1項に記載のユーザ機器。
(項目20)
上記構成メッセージは、RRC接続要求メッセージ、RRC接続設定メッセージ、RRC接続解放メッセージ、無線ベアラ設定メッセージ、システム情報同報通信メッセージ、システム情報ブロック(SIB)メッセージ、アクティブセット更新メッセージ、セル更新確認メッセージ、UTRANコマンドへのハンドオーバメッセージ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、およびUTRANモビリティ情報メッセージから成る群より選択される、項目11〜項目19のいずれか1項に記載のユーザ機器。
(項目21)
ユーザ機器からの遷移の指示であって、該ユーザ機器が異なる状態または異なるモードへの遷移を所望することを指示する、指示を処理する方法であって、該方法は、
該ユーザ機器から該遷移指示を受信することと、
該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、
該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することと
を包含する、方法。
(項目22)
上記信号伝達接続を解放することは、上記ユーザ機器のための無線リソース制御(RRC)の解放を開始する、項目21に記載の方法。
(項目23)
上記信号伝達接続は、識別されたコアネットワークドメインのためである、項目22に記載の方法。
(項目24)
上記遷移することは、電池効率のより良い状態またはモードになるように行われる、項目21〜項目23のいずれか1項に記載の方法。
(項目25)
ユーザ機器の状態またはモードを遷移させるように構成されているネットワーク要素であって、該ネットワーク要素は、
該ユーザ機器から遷移指示を受信することと、
該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、
該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することと
を行うように構成されている、ネットワーク要素。
(項目26)
上記信号伝達接続を解放することは、上記ユーザ機器のための無線リソース制御(RRC)の解放を開始する、項目25に記載のネットワーク要素。
(項目27)
上記信号伝達接続は、識別されたコアネットワークドメインのためである、項目26に記載のネットワーク要素。
(項目28)
上記遷移は、電池効率のより良い状態またはモードになるように行われる、項目25〜項目27のいずれか1項に記載のネットワーク要素。
【図面の簡単な説明】
【0059】
【図1】図1は、RRC状態および遷移を示す、ブロック図である。
【図2】図2は、種々のUMTSセルおよびURAを示す、UMTSネットワークの概略図である。
【図3】図3は、RRC接続設定における種々の段階を示す、ブロック図である。
【図4A】図4Aは、現在の方法に従ってUTRANによって開始される、CELL_DCH接続モード状態とアイドルモードとの間の例示的遷移のブロック図である。
【図4B】図4Bは、信号伝達解放指示を利用する、CELL_DCH状態接続モードとアイドルモードとの間の例示的遷移を示す、ブロック図である。
【図5A】図5Aは、UTRANによって開始される、CELL_DCH非活動状態、CELL_FACH非活動状態、アイドルモードへの例示的遷移を示す、ブロック図である。
【図5B】図5Bは、信号伝達解放指示を利用する、CELL_DCH非活動状態とアイドルモードとの間の例示的遷移を示す、ブロック図である。
【図6】図6は、UMTSプロトコルスタックのブロック図である。
【図7】図7は、本方法と関連して使用することができる、例示的UEである。
【図8】図8は、本方法およびシステムと関連して使用するための例示ネットワークである。
【図9】図9は、UEにおいて信号伝達接続解放指示の原因を追加するステップを示す、フロー図である。
【図10】図10は、原因を有する信号伝達接続解放指示の受信時にUEによって取られるステップを示す、フロー図である。
【図11】図11は、複数の同時パケットデータ通信サービスセッションがUEに提供される、図8に示されたネットワークの例示的動作中の例示的な論理および物理チャネル割り当てのグラフ表示である。
【図12】図12は、本開示の実施形態に従って、個々のパケットデータサービスの無線リソースを解放する無線リソース解放機能を提供する、UEおよびネットワーク要素の機能的ブロック図を図示する。
【図13】図13は、それによりPDPコンテキストへの無線リソース割り当てを解放するように、本開示の実施形態の操作に従って生成される信号伝達を表す、メッセージシーケンス図を図示する。
【図14】図14は、それにより無線リソース割り当てを解放するように、本開示の実施形態の操作に従って生成される信号伝達を同様に表す、図13に示された図と同様のメッセージシーケンス図を図示する。
【図15】図15は、本開示の実施形態の過程を表す、過程図を図示する。
【図16】図16は、本開示の実施形態の操作の方法を図示する、方法フロー図を図示する。
【図17】図17は、本開示の実施形態の操作の方法を同様に図示する、方法フロー図を図示する。
【図18】図18は、遷移決定がネットワーク要素において無線リソースプロファイルに基づき行われる、実施形態の方法フロー図を図示する。
【図19】図19は、図18の方法とともに使用されることが可能なネットワーク要素の簡略化したブロック図を図示する。
【図20】図20は、遷移指示または要求メッセージの送信のためのデータフロー図を図示する。
【図21】図21は、UEにおいて阻止タイマ値を設定するためのデータフロー図を図示する。
【発明を実施するための形態】
【0060】
ここで図1を参照する。図1は、UMTSネットワーク内のプロトコルスタックの無線リソース制御部分に対する種々のモードおよび状態を示す、ブロック図である。具体的には、RRCは、RRCアイドルモード110またはRRC接続モード120のいずれかとなり得る。
【0061】
当業者によって理解されるように、UMTSネットワークは、2つ地上ネットワークセグメントから成る。これらは、(図8に図示されるような)コアネットワーク(CN)およびユニバーサル地上波無線アクセスネットワーク(UTRAN)である。コアネットワークが、データ呼び出しの切替およびルーティング、ならびに外部ネットワークへのデータ接続に関与している一方で、UTRANは、全ての無線関連機能を取り扱う。
【0062】
アイドルモード110では、UEは、データがUEとネットワークとの間で交換される必要があるときはいつでも、RRC接続を要求して無線リソースを設定しなければならない。これは、データを送信するように接続に要求するUE上のアプリケーションの結果として、または、UTRANまたはSGSNがプッシュサーバ等の外部データネットワークからデータを受信するようにUEを呼び出したかどうかを示すように、UEがページングチャネルを監視する結果としてのものとなり得る。加えて、UEはまた、ロケーションエリア更新等のモビリティ管理信号伝達メッセージを送信する必要があるときはいつでも、RRC接続を要求する。
【0063】
いったんUEが無線接続を確立するようにUTRANに要求を送信すると、UTRANは、RRC接続がなる状態を選択する。具体的には、RRC接続モード120は、4つの別個の状態を含む。これらは、CELL_DCH状態122、CELL_FACH状態124、CELL_PCH状態126、およびURA_PCH状態128である。
【0064】
アイドルモード110から、UEは自律的にCELL_FACH状態124に遷移し、その場合、その初期データ転送を行い、その後、ネットワークがどのRCC接続状態を継続的なデータ転送に使用するかを判定する。これは、UEをセル専用チャネル(CELL_DCH)状態122にするか、またはUEをセル順方向アクセスチャネル(CELL_FACH)状態124に保つネットワークを含んでもよい。
【0065】
CELL_DCH状態122では、データを交換するアップリンクおよびダウンリンクの両方のために、専用チャネルがUEに割り当てられる。この状態は、専用物理チャネルがUEに割り当てられるため、典型的に、UEから最も多くのバッテリ電力を必要とする。
【0066】
代替として、UTRANは、UEをCELL_FACH状態124で維持することができる。CELL_FACH状態では、いずれのチャネルもUEに割り当てられない。その代わり、少量の集中的データにおける信号伝達を送信するために共通チャネルが使用される。しかしながら、UEは依然としてFACHを継続的に監視しなければならず、したがって、CELL_PCH状態、URA_PCH状態、およびアイドルモードよりも多くのバッテリ電力を消費する。
【0067】
RRC接続モード120内で、RRC状態は、UTRANの判断で変更することができる。具体的には、データ非活動が特定量の時間またはデータに対して検出されるか、または、ある閾値を下回るデータスループットが検出された場合に、UTRANは、RRC状態を、CELL_DCH状態122からCELL_FACH状態124、CELL_PCH状態126、またはURA_PCH状態128にしてもよい。同様に、ペイロードがある閾値を上回ると検出された場合に、RRC状態をCELL_FACH状態124からCELL_DCH状態122にすることができる。
【0068】
CELL_FACH状態124から、データ非活動がいくつかのネットワーク内で所定の時間にわたって検出された場合、UTRANは、RRC状態をCELL_FACH状態124からページングチャネル(PCH)状態にすることができる。これは、CELL_PCH状態126からURA_PCH状態128のいずれか一方となり得る。
【0069】
CELL_PCH状態126またはURA_PCH状態128から、UEは、専用チャネルを要求する更新手順を開始するために、CELL_FACH状態124とならなければならない。これは、UEが制御する唯一の状態遷移である。
【0070】
アイドルモード110、ならびにCELL_PCH状態126およびURA_PCH状態128は、ページングインジケータチャネル(PICH)を介して同報通信メッセージおよびページを監視するために、不連続受信サイクル(DRX)を使用する。いずれのアップリンク活動も可能ではない。
【0071】
CELL_PCH状態126とURA_PCH状態128との間の違いは、UEの現在のUTRAN登録エリア(URA)が、現在のセルに存在するURAアイデンティティのリストの中にない場合に、URA_PCH状態128がURA更新手順しか誘起しないことである。具体的には、図2を参照する。図2は、種々のUMTSセル210、212、および214の説明図を示す。これらのセルの全ては、CELL_PCH状態に再選択された場合に、セル更新手順を必要とする。しかしながら、UTRAN登録エリアにおいて、それぞれが同じUTRAN登録エリア(URA)320内に入り、したがって、URA更新手順は、URA_PCHモードであるときに210、212、および214の間で移動すると誘発されない。
【0072】
図2で見られるように、他のセル218は、URA320の外側にあり、別個のURAの一部となり得るか、またはいずれのURAの一部にもなり得ない。
【0073】
当業者によって認識されるように、バッテリ寿命の観点から、アイドル状態は、上記の状態と比較して最低バッテリ使用量を提供する。具体的には、UEは、間隔を置いてのみ、ページングチャネルを監視する必要があるために、無線は継続的にオンである必要はないが、その代わり、周期的に起動する。これに対するトレードオフは、データを送信する待ち時間である。しかしながら、この待ち時間が長過ぎなければ、アイドルモードであること、およびバッテリ電力を節約することの利点は、接続待ち時間の不利点を上回る。
【0074】
再度、図1を参照する。種々のUMTS基礎構造ベンダは、種々の基準に基づいて、状態122、124、126、および128の間で移動させる。これらの基準は、とりわけ、信号伝達の節約または無線リソースの節約に関するネットワーク操作者の選好となり得る。例示的な基礎構造を以下で概説する。
【0075】
第1の例示的基礎構造では、CELL_FACH状態でアクセスを開始した直後に、RRCは、アイドルモードとCell_DCH状態との間で移動する。Cell_DCH状態では、2秒間の非活動が検出された場合、RRC状態はCell_FACH状態124に変化する。もし、Cell_FACH状態124で、10秒間の非活動が検出された場合は、RRC状態がCell_PCH状態126に変化する。Cell_PCH状態126での45分間の非活動は、RRC状態をアイドルモード110に戻らせる。
【0076】
第2の例示的基礎構造では、RRC遷移は、ペイロード閾値に応じて、アイドルモード110と接続モード120との間で発生することができる。第2の基礎構造では、ペイロードがある閾値を下回る場合に、UTRANはRRC状態をCELL_FACH状態124にする。逆に、データペイロードがあるペイロード閾値を上回る場合に、UTRANはRRC状態をCELL_DCH状態122にする。第2の基礎構造では、2分間の非活動がCELL_DCH状態122で検出されると、UTRANはRRC状態をCELL_FACH状態124にする。CELL_FACH状態124での5分間の非活動後に、UTRANはRRC状態をCELL_PCH状態126にする。CELL_PCH状態126では、アイドルモード110に戻る前に、2時間の非活動が必要とされる。
【0077】
第3の例示的基礎構造では、アイドルモード110と接続モード120との間の移動は、常にCELL_DCH状態122に対するものである。CELL_DCH状態122での5秒間の非活動後に、UTRANはRRC状態をCELL_FACH状態124にする。CELL_FACH状態124での30秒間の非活動は、アイドルモード110に戻る移動をもたらす。
【0078】
第4の例示的基礎構造では、RRCは、アイドルモードから接続モードへと、CELL_DCH状態122に直接遷移する。第4の例示的基礎構造では、CELL_DCH状態122は、2つの構成を含む。第1の構成は、データ転送速度を有する構成を含み、第2の構成は、より低いデータ転送速度を含むが、依然としてCELL_DCH状態内である。第4の例示的基礎構造では、RRCは、アイドルモード110から高データ転送速度のCELL_DCHサブ状態に直接遷移する。10秒間の非活動後に、RRC状態は、低データ天測速度のCELL_DCHサブ状態に遷移する。CELL_DCH状態122の低データサブ状態からの17秒間の非活動は、RRC状態をアイドルモード110に変化させる。
【0079】
上記の4つの例示的基礎構造は、種々のUMTS基礎構造ベンダがどのように状態を実装しているかを示す。当業者によって理解されるように、それぞれの場合において、実データ(Eメール等)を交換するのに費やされる時間は、CELL_DCHまたはCELL_FACH状態でとどまるために必要とされる時間と比較して、有意に短い。これは、不必要なカレントドレインを引き起こし、UMTS等のより新しい世代のネットワークにおけるユーザ体験を、GPRS等の以前の世代のネットワークよりも不良にする。
【0080】
さらに、CELL_PCH状態126が、バッテリ寿命の観点からCELL_FACH状態124よりも最適であるが、CELL_PCH状態126でのDRXサイクルは、典型的に、アイドルモード110よりも低い値に設定される。結果として、UEは、アイドルモード110よりもCELL_PCH状態126で頻繁に起動する必要がある。
【0081】
アイドル状態110のDRXサイクルと同様のDRXサイクルを伴うURA_PCH状態128は、おそらく、バッテリ寿命と接続のための待ち時間との間の最適なトレードアップである。しかしながら、URA_PCH状態128は、現在UTRANでは実装されていない。したがって、場合によっては、バッテリ寿命の観点から、アプリケーションがデータ交換を終了した後にできるだけ早急に、アイドルモードに早急に遷移することが望ましい。
【0082】
ここで図3を参照する。アイドルモードから接続モードに遷移するときに、種々の信号伝達およびデータ接続を行う必要がある。図3を参照すると、行われる最初の事項は、RRC接続設定310である。上記で示されるように、このRRC接続設定310は、UTRANによってしか解除することができない。
【0083】
いったんRRC接続設定310が達成されると、信号伝達接続設定312が開始される。
【0084】
いったん信号伝達接続設定312が終了されると、暗号化および完全性設定314が開始される。これの完了時に、無線ベアラ設定316が達成される。この時点で、UEとUTRANとの間でデータを交換することができる。
【0085】
接続の解除は、一般に逆の順序で、同様に達成される。無線ベアラ設定316が取り払われ、次いで、RRC接続設定310が取り払われる。この時点で、RRCは、図1に図示されるようなアイドルモード110になる。
【0086】
現在の3GPP仕様書は、UEがRRC接続を解放すること、またはRRC状態に対するその選好を示すことを許容しないが、UEは、依然として、パケット交換アプリケーションによって使用されるパケット交換(PS)ドメイン等の特定されたコアネットワークドメインに対する信号伝達接続の終結を示すことができる。3GPP TS 25.331の第8.1.14.1項によれば、その信号伝達接続のうちの1つが解放されたことをUTRANに示すために、信号伝達接続解放指示手順がUEによって使用される。この手順は、順に、RRC接続解放手順を開始してもよい。
【0087】
したがって、現在の3GPP仕様書内にとどまって、信号伝達接続設定312の解除時に信号伝達接続解放が開始されてもよい。それは、信号伝達接続設定312を解除するUEの能力内であり、これは順に、仕様書に従って、RRC接続解放を開始「してもよい」。
【0088】
当業者によって開始されるように、信号伝達接続設定312が解除された場合、UTRANはまた、信号伝達接続設定312が解除された後に、暗号化および完全性設定314、ならびに無線ベアラ設定316を整理する必要もある。
【0089】
信号伝達接続設定312が解除された場合、RRC接続設定は、典型的には、いずれのCS接続もアクティブではない場合に、現在のベンダ基礎構造のために、ネットワークによって停止させられる。
【0090】
上述の具体的な遷移指示例のうちの1つにこれを使用して、UEは、データの交換が終了したことを判定し、例えば、UEソフトウェアの「接続マネージャ」構成要素に、データの交換が完了したという指示が提供された場合、接続マネージャは、信号伝達設定312を解除するか否かを判定してもよい。例えば、デバイス上のEメールアプリケーションは、Eメールがプッシュサーバによって確かに受信されたというプッシュEメールサーバからの確認が受信されたという指示を送信する。接続マネージャは、一実施形態では、全ての既存のアプリケーション、関連PDPコンテキスト、関連PS無線リソース、および関連回線交換(CS)無線ベアラを追跡することができる。他の実施形態では、ネットワーク要素(例えば、UTRAN)が、既存のアプリケーション、関連PDPコンテキスト、QoS、関連PS無線リソース、および関連CS無線ベアラを追跡することができる。アプリケーションが本当にデータ交換を終了し、「終了」指示が送信された後でもRCC接続をもはや必要としないことを確実にするように、UEまたはネットワーク要素のうちのいずれかにおいて遅延を導入することができる。この遅延は、アプリケーションまたはUEと関連付けられた非活動タイムアウトと同等にすることができる。各アプリケーションは、独自の非活動タイムアウトを有することができ、したがって、遅延は、アプリケーションタイムアウトの全ての複合物となり得る。例えば、Eメールアプリケーションは、5秒間の非活動タイムアウトを有することができるが、アクティブブラウザアプリケーションは、60秒間のタイムアウトを有することができる。阻止期間タイマはさらに、遷移指示の送信を遅延させることができる。アクティブアプリケーションからの全てのそのような指示の複合状態、ならびにいくつかの実施形態での無線リソースプロファイルおよび/または阻止期間タイマ遅延に基づいて、UEソフトウェアは、適切なコアネットワーク(例えば、PSドメイン)に対する(例えば、信号伝達接続解放指示または状態変更要求のための)遷移指示を送信する前に、どれだけ待つべきか、または待たなければならないかを決定する。ネットワーク要素において遅延が実施された場合、要素は、UEに遷移するかどうか、およびどのようにUEに遷移するかの判定を行うが、遅延がその経過をたどった後にしか遷移を操作しない。
【0091】
非活動タイムアウトは、トラフィックパターン履歴および/またはアプリケーションプロファイルに基づいて動的にすることができる。
【0092】
ネットワーク要素がUEをアイドルモード110に遷移する場合、それは図1に図示されるようなRRC接続モード120の任意の段階で起こり得るが、ネットワーク要素は、RRC接続を解放し、UEを図1に図示されるようなアイドルモード110にする。これはまた、UEが音声電話中にあらゆるパケットデータサービスを行っているときにも適用可能である。この場合、ネットワークは、PSドメイン信号伝達接続のみを解放することを選択し、CSドメイン信号伝達接続を維持してもよく、または代替として、何も解放しないことを選択し、代わりに、PSおよびCSドメインの両方への信号伝達接続を維持してもよい。
【0093】
さらなる実施形態では、指示の理由をUTRANに示す遷移指示に、原因を追加することができる。好ましい実施形態では、原因は、異常な状態が指示を引き起こしたと言う指示、または要求された遷移の結果として指示がUEによって開始されたという指示となり得る。他の正常な(すなわち、異常ではない)トランザクションもまた、遷移指示の送信をもたらすことができる。
【0094】
さらなる好ましい実施形態では、種々のタイムアウトが、異常な状態に対して遷移指示を送信させることができる。以下のタイマの実施例は包括的ではなく、他のタイマまたは異常な状態が可能である。3GPP TS 24.008の10.2.47は、タイマT3310を以下のように特定する。
【0095】
【表1】
このタイマは、添付失敗を示すために使用される。添付の失敗は、ネットワークの結果となり得るか、または衝突あるいは不良な無線周波数(RF)等のRFの問題となり得る。
【0096】
添付試行は、複数回発生することができ、添付失敗は、所定数の失敗または明示的拒絶のいずれか一方に起因する。
【0097】
3GPPの10.2.47の第2のタイマは、以下のように特定されるタイマT3330である。
【0098】
【表2】
このタイマは、ルーティングエリア更新失敗を示すために使用される。タイマの満了時に、さらなるルーティングアリア更新を複数回要求することができ、ルーティングエリア更新失敗は、所定数の失敗または明示的拒絶のいずれか一方に起因する。
【0099】
3GPPの10.2.47の第3のタイマは、以下のように特定されるタイマT3340である。
【0100】
【表3】
このタイマは、GMMサービス要求失敗を示すために使用される。タイマの満了時に、さらなるGMMサービス要求を複数回開始することができ、GMMサービス要求失敗は、所定数の失敗または明示的拒絶のいずれか一方に起因する。
【0101】
したがって、異常な状態およびUEによる解放に限定された遷移指示原因の代わりに、遷移指示原因は、どのタイマが異常な状態のために失敗したかについての情報をさらに含むことができる。信号伝達接続解放指示が遷移指示として使用される、具体的実施例では、指示を以下のように構造化することができる。
【0102】
【表4】
このメッセージは、既存の信号伝達接続を解放する要求をUTRANに示すために、UEによって使用される。信号伝達接続解放指示の追加は、UTRANまたは他のネットワーク要素が、信号伝達接続解放指示の原因、それが異常な状態によるものであったかどうか、および異常な状態がどのようなものであったかどうかを受信することを可能にする。信号伝達接続解放指示の受信に基づいて、RRC接続解放手順は、順に、UTRANにおいて開始されることが許容される。
【0103】
この実施例の1つの実施において、UEは、特定のCN(コアネットワーク)ドメインに対する上層から、信号伝達接続を解放または中止する要求を受信すると、例えば、IE(情報要素)「CNドメインアイデンティティ」で識別される特定のCNドメインに対して、変数「ESTABLISHED_SIGNALLING_CONNECTIONS」が存在する場合に、信号伝達接続解放指示手順を開始する。変数がいずれの既存の信号伝達接続も識別しなければ、その特定のCNドメインに対する信号伝達接続の任意の継続中の確立が別の方式で中止される。Cell_PCHまたはURA_PCH状態での信号伝達接続解放指示手順の開始時に、UEは、原因「アップリンクデータ伝送」を使用して、セル更新手順を行う。セル更新手順の完了が成功すると、UEは、次に起こる信号伝達接続解放指示手順を続ける。
【0104】
すなわち、UEは、情報要素(IE)「CNドメインアイデンティティ」を上位論理層によって示される値に設定する。IEの値は、上層が行っているその関連信号伝達接続が解放される、CNドメインを示す。CNドメインアイデンティティがPSドメインに設定された場合、および上層がこの要求を開始する原因を示す場合には、IE「信号伝達解放指示原因」が、それに応じて設定される。UEはさらに、変数「ESTABLISHED_SIGNALLING_CONNECTIONS」から上層によって示されたアイデンティティとの信号伝達接続を除去する。UEは、例えば、認知モード無線リンク制御(AM RLC)を使用する専用制御チャネル(DCCH)上で、信号伝達接続解放指示メッセージを伝送する。RLCによる解放指示メッセージの配信成功の確認時に、手順が終了する。
【0105】
IE「信号伝達接続解放指示原因」も、本開示の実施形態に従って使用される。解放原因は、例えば、既存のメッセージ定義と整合される。上層解放原因メッセージは、例えば、以下のように構造化される。
【0106】
【表5】
この実施例では、T3310、T330、およびT3340満了は、以前に識別された、対応する番号のタイマの期限切れに対応する。原因値は、1つの実施では、アイドル遷移に対する選好のUE指示を除去し、状態遷移時に決定するUTRANを提供するように、「UEが要求したアイドル遷移」よりもむしろ「UEが要求したPSデータセッション終了」として設定可能であるが、予期された結果は、原因値によって識別されるものに対応する。信号伝達接続解放指示の拡張は、好ましくは、非臨界拡張であるが、必ずしもそうではない。
【0107】
ここで図9を参照する。図9は、種々のドメイン(例えば、PSまたはCS)に対する信号伝達接続解放指示を送信するか否かを監視する例示的UEのフロー図である。過程は、ステップ910で開始する。
【0108】
UEは、異常な状態が存在するかどうかを確認するようにチェックする、912に遷移する。そのような異常な状態は、上記で説明されるようなタイマT3310、タイマT3320、またはタイマT3340の期限切れを含むことができる。これらのタイマがある所定の回数で満了する場合、またはこれらのタイマのうちのいずれかの満了に基づいて明示的拒絶が受信された場合、UEは、信号伝達接続解放指示を送信するステップ914に進む。信号伝達接続解放指示メッセージが、信号伝達解放指示原因フィールドに付加される。信号伝達解放指示原因フィールドは、少なくとも、信号伝達解放指示が異常な状況または状態に基づくことを含み、一実施形態は、タイムアウトして異常な状態をもたらした特定のタイマを含む。
【0109】
逆に、ステップ912で、異常な状態が存在しないことをUEが見出した場合、UEは、さらなるデータがUEで見込まれるかどうかをチェックする、ステップ920に進む。これは、上記で説明されるように、Eメールが送信され、Eメールの送信の確認がUEにおいて返信されるときを含むことができる。さらなるデータが見込まれないことをUEが判定する場合の他の実施例は、当業者にとって公知であろう。
【0110】
ステップ920で、データ転送が終了したこと(または回線交換ドメインの場合には通話が終了したこと)をUEが判定した場合、UEは、信号伝達接続解放指示を送信するステップ922に進み、その場合、信号伝達解放指示原因フィールドが追加され、UEがアイドル遷移を要求したか、または単にPSセッションの終了を示したという事実を含む。
【0111】
ステップ920から、データが終了していない場合、UEは、元に戻り、ステップ912で異常な状態が存在するかどうかを、ステップ920でデータが終了したかどうかを引き続きチェックする。
【0112】
いったん信号伝達接続解放指示がステップ914またはステップ922に送信されると、過程はステップ930に進み、終了する。
【0113】
UEは、例えば、チェッカーおよび遷移指示送信機を形成する、UEマイクロプロセッサの動作を通して、またはハードウェア実装によって実行される、アプリケーションまたはアルゴリズムによって実装可能な機能的要素を含む。チェッカーは、遷移指示が送信されるべきかどうかをチェックするように構成される。そして、遷移指示送信機は、遷移指示が送信されるべきであるという送信機による指示に対応する遷移指示を送信するように構成される。遷移指示は、遷移指示原因フィールドを含んでもよい。
【0114】
1つの実施では、ネットワークは、代わりに、暗示的にタイマの時間切れを認識させられ、UEは、タイマの時間切れを示す原因値を送信する必要がない。すなわち、タイマは、ネットワークの承認時に計時を開始する。原因コードが画定され、原因コードは、ネットワークによってUEに提供される。そのような原因コードは、タイマを開始するためにUEによって使用される。以前にネットワークによって送信された原因コードが、タイマに計時を開始させるにつれて、ネットワークは、タイマの後続の時間切れの理由を暗示的に認識する。結果として、UEは、タイマの時間切れを示す原因値を送信する必要がない。
【0115】
図9ならびに先述の内容によって示唆されるように、原因は、1)異常な状態、ならびに2)正常な状態(例えば、PSデータセッション終了および/またはアイドルモードへの遷移の要求等の、異常ではない状態)を示すように、遷移指示(例えば、信号伝達接続解放指示)とともに包含可能で、かつ送信される。したがって、種々の実施では、UEにおける操作は、異常な状態を示すように、または代替として、アイドル遷移またはPSデータセッション終了、すなわち正常動作の要求に対する選好を示すように、遷移指示への原因の追加を提供する。そのような操作は、当然ながら、異常な状態の指示が行われるときのみに原因が遷移指示に追加される、UE操作も含む。そして、逆に、そのような操作は、正常な、すなわち、異常ではない動作およびトランザクションを示すだけのために、原因が遷移指示に追加される、UE操作も含む。すなわち、図9に関して、そのような代替操作では、もし、ステップ912で、異常な状態が存在する場合は、「はい」の分岐がステップ914に運ばれる一方で、異常な状態が存在しない場合は、UEは終了ステップ930に直接進む。逆に、他方のそのような代替操作では、開始ステップ912の後に、経路がデータ終了ステップ920に直接運ばれる。データが終了している場合、「はい」の分岐がステップ920に運ばれ、その後、ステップ930に運ばれる。データがステップ920において終了していない場合、いずれの分岐も同ステップ、すなわち、ステップ920に戻されない。
【0116】
図10を参照して、ネットワーク要素がステップ1010で遷移指示を受信すると(例えば、示されるような信号伝達接続解放指示)、ネットワーク要素は、ステップ1014で、もし存在すれば遷移指示原因フィールドを検査し、ステップ1016で、原因が異常な原因であるかどうか、または、それがアイドル遷移および/またはPSデータセッション終了を要求するUEによるものであるかどうかをチェックする。もし、ステップ1016で、信号伝達接続解放指示が異常な原因であれば、ネットワークノードは、性能監視およびアラーム監視の目的でアラームが留意されてもよい、ステップ1020に進む。主要性能インジケータを適切に更新することができる。
【0117】
逆に、もし、ステップ1016で、遷移指示(例えば、信号伝達接続解放指示)の原因が異常な状態の結果ではない、または言い換えれば、PSデータセッション終了またはアイドル遷移を要求するUEの結果であれば、ネットワークノードは、いずれのアラームも起こらず、指示を性能統計からフィルタにかけることができる、ステップ1030に進み、それにより、性能統計が歪曲されることを防止する。ステップ1020またはステップ1030から、ネットワークノードは、過程が終了するステップ1040に進む。
【0118】
遷移指示の受信または検査は、パケット交換データ接続終結のネットワーク要素による開始、または代替として、別のより好適な状態、例えば、CELL_FACH、CELL_PCH、URA_PCH、またはIDLE_モードへの遷移をもたらしてもよい。
【0119】
上記で示唆されるように、いくつかの実施では、遷移指示の原因の欠如はまた、遷移指示が正常または異常な状態の結果であるかどうか、およびアラームを起こさなければならないか否かを判定するために、使用されてもよい。例えば、正常な状態(すなわち、例えば、PSデータセッション終了および/またはアイドルモードへの遷移の要求等に関して、異常ではない)を表すためだけに原因が追加され、原因が追加されていない遷移指示をネットワーク要素が受信する場合、ネットワーク要素は、原因の欠如から、遷移指示が異常な状態の結果であることを推測し、随意で、アラームを起こし得る。逆に、別の実施例では、異常な状態を表すためだけに原因が追加され、ネットワーク要素が原因のない遷移指示を受信する場合、ネットワーク要素は、原因の欠如から、遷移指示が正常な状態(例えば、PSデータセッッション終了および/またはアイドルモードへの遷移の要求)の結果であることを推測し、アラームを起こし得ない。
【0120】
当業者によって理解されるように、ステップ1020は、種々のアラーム状態をさらに区別するために使用することができる。例えば、T3310タイムアウトは、第1の一式の統計値を保つために使用することができ、T3330タイムアウトは、第2の一式の統計値を保つために使用することができる。ステップ1020は、異常な状態の原因を区別するために使用することができ、それにより、ネットワーク操作者が性能をより効率的に追跡することを可能にする。
【0121】
ネットワークは、例えば、検査器およびアラーム発生器を形成する、プロセッサの動作を通して、またはハードウェア実装によって実行される、アプリケーションまたはアルゴリズムによって実装可能な機能的要素を含む。検査器は、遷移指示の遷移指示原因フィールドを検査するように構成される。検査器は、遷移指示原因フィールドが異常な状態を示すかどうかをチェックする。アラーム発生器は、信号伝達接続解放指示原因フィールドが異常な状態を示すことを検査器による検査が判定した場合に、選択的にアラームを生成するように構成される。
【0122】
1つの実施では、信号伝達接続解放指示の受信時に、UTRANは、受信される原因と、信号伝達接続の解放のための上層からの要求とを転送する。次いで、上層は、信号伝達接続の解放を開始することができる。IE信号伝達解放指示原因は、UEのRCCを誘起してメッセージを送信するように、UEの上層の原因を示す。原因は、異常な上層の手順の結果である可能性が高い。メッセージの原因の区別は、IEの受信成功を通して確保される。
【0123】
可能なシナリオは、信号伝達接続解放指示メッセージの配信成功のRLCによる確認の前に、信号伝達無線ベアラRB2上でRLCエンティティの伝送側の確立が発生する、シナリオを含む。そのような発生の場合、UEは、例えば、信号伝達無線ベアラRB2上のAM RLCを使用するアップリンクDCCH上で、信号伝達接続解放指示メッセージを再伝送する。信号伝達接続解放指示または要求メッセージの配信成功のRLCによる確認の前に、UTRAN手順からのRAT(無線アクセス技術)間ハンドオーバが発生する場合では、UEは、新規RATであるときに信号伝達接続を中止する。
【0124】
さらなる実施形態では、「信号伝達接続解放指示」または要求の代わりに、「データ転送完了指示」を利用することができる。上記の図9および10で説明されるものと同様の機能性が、このデータ転送完了指示に適用可能となる。
【0125】
一実施形態では、データ転送完了指示は、継続中のCSドメインデータ転送がないことをUEが判定し、そのPSデータ転送を完了したことをUTRANに知らせるために、UEによって使用される。そのようなメッセージは、例えば、AM RLCを使用するDCCH上で、UEからUTRANに送信される。例示的メッセージを以下に示す。
10.2.xデータ転送完了指示
このメッセージは、継続中のCSドメインデータ転送がないことをUEが判定し、そのPSデータ転送を完了したことをUTRANに知らせるために、UEによって使用される。RLC_SAP:AM
論理チャネル:DCCH
方向:UE→UTRAN
【0126】
【表6】
ここで図20を参照する。図20は、(例えば、信号伝達接続解放指示またはデータ転送完了指示のための)遷移指示または要求がUEからUTRANに送信される、実施形態を図示する。過程は、ステップ2010から開始し、UEにおける状態が遷移指示メッセージを送信するのに適切であるかどうかを判定するように、チェックがUE上で行われる、ステップ2012に進む。そのような状態は、例えば、以下の図11を参照して、本開示で説明され、UE上で1つ以上のアプリケーションを含むことができ、それらがデータ交換を終了したことを判定する。そのような状態はまた、タイマT3xxが作動していれば、期限切れになるのをある期間にわたって待つステップを含んでもよい。
【0127】
さらなる代替実施形態では、状態は、タイマT3xxが無限に設定された場合に、遷移指示の送信を妨げるステップを含んでもよい。理解されるように、T3xxは、無数の離散値を含むことができ、その1つが無限値を表す。
【0128】
もし、ステップ2012で、状態が遷移指示または要求メッセージを送信するのに適切でなければ、過程は、元に戻って、状態が遷移指示または要求メッセージを送信するのに適切となるまで引き続き監視する。
【0129】
いったん状態が適切になると、過程は、遷移指示がUTRANであるステップ2020に進む。例示的指示を上記の表に示す。
【0130】
次いで、過程は、遷移指示が成功したかどうかを判定するようにチェックが行われる、ステップ2022に進む。当業者によって理解されるように、これは、UTRANが遷移指示の受信に成功し、状態遷移を開始したことを意味し得る。「はい」であれば、過程は、ステップ2030に進み、終了する。
【0131】
逆に、ステップ2022で、遷移指示が成功しなかったと判定された場合、過程は、ステップ2024に進み、ある期間にわたって待機する。そのような待機は、所与の期間が経過する前に携帯電話が別の遷移指示メッセージを送信できないようにする、「阻止期間」、例えば、T3xxを使用して、実施することができる。代替として、過程は、遷移指示メッセージの数を所定の期間内で限定することができる(例えば、10分でわずか15のメッセージ)。阻止期間および所与の期間内のメッセージの数の限定の組み合わせも、可能である。
【0132】
期間は、基準において定義される値等の、所定のものとなり得て、例えば、RRC接続要求メッセージ、RRC接続設定メッセージ、RRC接続解放、無線ベアラ設定、システム情報同報通信メッセージ、システム情報ブロックメッセージ、アクティブセット更新、セル更新確認、UTRANモビリティ情報メッセージ、UTRANコマンドへのハンドオーバ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、または任意の要求、構成、あるいは再構成メッセージの一部として、ネットワーク要素によって設定することができる。さらに、期間は、遷移指示メッセージ内のパラメータに基づいて設定することができる。したがって、期間は、UEがアイドルよりもむしろCell_PCHへの遷移を要求している場合に、より長くなり得る。
【0133】
ネットワーク要素による期間の信号伝達または送信は、情報要素の形を取ることができる。本明細書で使用されるように、信号伝達または送信は、情報をUEに直接送信するステップ、または情報を同報通信するステップを含むことができる。同様に、UEにおいて受信するステップは、同報通信チャネルの直接受信または読取を含むことができる。1つの例示的情報要素は、以下を含む。
【0134】
【表7】
T3xxの値は、一実施形態では以下のように定義される。
【0135】
【表8】
一実施形態では、既存のUMTS情報要素「接続モードでのUEタイマおよび定数」にT3xxを含むことができる。したがって、これは、システム情報ブロック型1に含むことによって、セルの中で同報通信することができる。代替実施形態では、タイマ値はまた、SIB3またはSIB4等の他のシステム情報メッセージを使用して信号伝達することもでき、または、代替として、あるいは加えて、専用UTRANモビリティ情報メッセージで信号伝達することができる。
【0136】
上記の表で示されるように、T3xx値は、設定値の間で変動し、ゼロ値または無限値を含むことができる。ゼロ値は、いずれの阻止も発生する必要がないことを示すために使用される。無限値は、遷移指示メッセージが決して送信されるべきではないことを示す。
【0137】
1つのモビリティの実施形態では、UEは、新規ネットワークまたはセルが遷移されるときはいつでも、T3xx値をリセットする。この実施例では、値は無限に設定される。このことは、遷移メッセージまたは無線ベアラメッセージが阻止タイマ値を含有しない場合に、デフォルトでUEが遷移指示メッセージを送信しないものであることを確実にする。したがって、例えば、遷移または無線ベアラメッセージが「遷移阻止指示」を含有しない場合は、タイマの値は無限に設定され、そうでなければ、指示の中で受信されるタイマの値が任意の以前に記憶された値に取って代わる。
【0138】
別の代替実施形態では、T3xxの値は、以下のように定義される。タイマT3xxの包含は随意的であり、それにより、含まれなければ、UEは、このタイマを構成または使用するステップをサポートする必要がないことを確実にする。
【0139】
【表9】
したがって、セルの中の阻止タイマの受信は、セルが遷移指示メッセージの使用を認識するというUEへの指示である。UEは、長期間にわたってこれ以上PSドメインデータがないという判定により、RRCまたは上位層によって開始された場合に、原因値を使用して遷移指示を信号伝達することを判定してもよい。ネットワークがこの原因とともに遷移指示メッセージ(本書でとらえられるように、どのような形態のメッセージでも)を受信すると、よりバッテリ効率の良いRRC状態への状態遷移変化をUEに信号伝達するように判定してもよい。
【0140】
一方で、代替実施形態では、阻止タイマがセルの中で受信されないか、または読み取られないときに、UEは、遷移指示メッセージを送信するための原因がUTRANによってサポートされていないことを判定することができる。この場合、UEは、T3xxの値を構成しないこと、また、遷移指示メッセージを送信するステップまたは送信を阻止するステップに関連してT3xxを使用しないことも判定することができる。
【0141】
阻止タイマが省略されることをUEが判定した場合には、これ以上伝送するPSデータがないことを判定する上位層に基づいて、遷移指示メッセージから原因値を含むことを省略し、遷移指示メッセージを送信するのみであってもよい。
【0142】
代替実施形態では、UEは、阻止タイマが省略されることを判定すると、これ以上伝送するPSデータがないことを判定する上位層に基づいて、遷移指示を開始するべきではない。
【0143】
この説明された動作の一実施形態では、遷移指示メッセージは、信号伝達接続解放指示メッセージである。
【0144】
したがって、第1の代替実施形態では、セルの中の阻止タイマの受信は、セルが遷移指示メッセージの使用を認識するという指示である。このメッセージの送信が許容される場合に、T3xxが無限値に設定されないとき、次いで、ネットワークが遷移指示を受信するときに、よりバッテリ効率の良いRRC状態(例えば、CELL_FACH、CELL_PCH、URA_PCH、またはIDLE_モード)への状態遷移変化をUEに信号伝達するように判定してもよい。
【0145】
3GPP TSG−RAN2 25.331基準を利用する特定の実施例では、次の内容が、以下で識別されるセクションに追加される。
【0146】
【表10】
これは、以下のセクションに追加される。
10.2.48.8.6 システム情報ブロック型3
10.2.48.8.7 システム情報ブロック型4
10.2.1 アクティブセット更新
10.2.8 セル更新確認
10.2.16 UTRANコマンドへのハンドオーバ
10.2.22 物理チャネル再構成
10.2.27 無線ベアラ再構成
10.2.30 無線ベアラ解放
10.2.33 無線ベアラ設定
10.2.40 RRC接続設定
10.2.50 輸送チャネル再構成
10.2.48.8.6 システム情報ブロック型3、および10.2.48.8.7
システム情報ブロック型4というメッセージ以外に、上記で説明されるメッセージは、全てモビリティ情報メッセージの例である。
【0147】
上記は、接続およびシステム動作、ならびに種々のセル間の遷移を網羅し、そのセルが遷移指示メッセージをサポートする場合に、UEが阻止タイマ値を有することを確実にする。例えば、UTRANコマンドへのハンドオーバは、第2世代ネットワーク等の別の無線アクセス技術から第3世代ネットワークへの遷移が、第3世代ネットワークの標的セルによってサポートされるなら阻止タイマ値を提供することを確実にする。
【0148】
具体的には、図21を参照すると、セル間の遷移は、「開始」として参照番号2110によって示されるように、前提条件として、またはUEの他の動作中に,発生している。過程は、構成メッセージが受信される、ブロック2112に進む。これは、上記で識別されるメッセージのうちのいずれかとなり得て、モビリティおよび非モビリティメッセージの両方を含む。次いで、過程は、構成メッセージが阻止タイマ値を含むかどうかを確認するようにチェックが行われる、ブロック2114に進む。
【0149】
そうでなければ、過程は、阻止タイマ値が無限に設定される、ブロック2120に進む。逆に、ブロック2114から、過程は、構成メッセージが阻止タイマ値を含まないことが判定された場合に、ブロック2130に進む。ブロック2130では、阻止タイマ値がUE上に記憶され、阻止タイマの以前の値に取って代わる。次いで、過程は、ブロック2140に進み、終了する。理解されるように、一実施形態では、ネットワークまたはセルの変化が発生したときはいつでも、または遷移指示が送信される必要があるときはいつでも、図21の過程が呼び出される。
【0150】
いったん過程がステップ2024で所定の時間にわたって待機すると、過程は、ステップ2012に戻って、遷移指示を送信するための条件が依然として存在するかどうかを判定する。もし「はい」であれば、過程は、ステップ2020および2022に戻る。
【0151】
上記に基づいて、阻止タイマ値は、種々の実施形態で提供されてもよい。第1の実施形態では、それは、阻止タイマ値を伝えるためにRRC接続設定メッセージのみを使用して提供することができる。
【0152】
第2の実施形態では、阻止タイマ値を伝えるために、システム情報を使用することができる。
【0153】
第3の実施形態では、阻止タイマ値を送信して、アイドルモードならびにCell_PCH/Cell_FACHおよびDCH状態のUEが最新情報を有することを確実にするために、RRC接続設定およびシステム情報メッセージの両方を利用することができる。
【0154】
第4の実施形態では、無線ベアラを持たずにPDPコンテキストが確立されるときに、データメッセージを送信するように無線ベアラが後に確立されると、その時に阻止タイマ値を伝えることができるように、無線ベアラ設定において阻止タイマ値を送信することに加えて、阻止タイマ値を第3の実施形態のように送信することができる。
【0155】
第5の実施形態では、第4の実施形態を、再構成、セル更新確認、および阻止タイマ値を伝えるUTRANへのハンドオーバコマンドを含む、上記で説明されるような全てのモビリティ関連メッセージと組み合わせることができる。
【0156】
第1から第4の実施形態では、モビリティ中に、UEがその現在記憶されている阻止タイマ値を維持する。上記で示されるように、阻止タイマが無限に設定される、いくつかの場合において、これは、ネットワークタイマが期限切れになること、およびネットワークが、UEを阻止タイマの新規値を受信または判定することができるRCC状態にすることを、UEが待たなければならないことを意味してもよい。阻止タイマがハンドオーバ前に無限以外の何らかの値である、他の場合において、UEがタイマ値を新規セルの中で示される値に更新することができるまで、この他の値が引き続き使用される。
【0157】
第5の実施形態について、阻止タイマ値がモビリティ中に更新されること、および遷移指示メッセージがUEから不必要に送信されないことを確実にするために、過程図21が利用される。
【0158】
RLC再確立またはRAT間変更に例外が発生してもよい。遷移指示メッセージの配信成功がRLCによって確認される前に、RLCエンティティの伝送側の再確立が発生した場合、一実施形態では、UEは、AM RLCを使用するアップリンクDCCH上で遷移指示メッセージを伝送する。
【0159】
一実施形態では、遷移指示メッセージの配信成功がRLCによって確認される前に、UTRAN手順からのRAT間ハンドオーバが発生した場合、UEは、新規RATにある間に信号伝達接続を中止する。
【0160】
ネットワーク側では、過程は、以下の図18を参照して説明されるものと同様に取り扱われる。
【0161】
再度、図1を参照すると、アイドルモード110よりもURA_PCH状態128等の接続モード120であることが望ましくてもよい。例えば、接続モード120におけるCELL_DCH状態122またはCELL_FACH状態124への接続の待ち時間が低くなる必要がある場合、接続モード120のPCH状態であることが好ましい。例えば、基準を改正して、UEが特定の状態(例えば、この場合はURA_PCH状態128)にすることをUTRANに要求できるようにすること等によって、これを達成する多数の方法がある。
【0162】
代替として、接続マネージャは、RCC接続が現在どのような状態であるか等の他の要因を考慮に入れてもよい。もし、例えば、RRC接続がURA_PCH状態であれば、アイドルモード110にする必要がないことを決定してもよく、したがって、いずれの信号伝達接続解放手順も開始されない。
【0163】
さらなる代替案では、ネットワーク要素(例えば、UTRAN)が、RCC接続が現在どのような状態であるか等の他の考慮を自ら考慮にいれてもよく、もし、例えば、RRC接続がURA_PCH状態であれば、アイドルモード110にする必要がないことを決定し、接続を解放する代わりに、単にUEをより好適な状態に遷移させてもよい。
【0164】
図4を参照する。図4Aは、上記の基礎構造の「4」実施例による、現在のUMTS実装を示す。図4に図示されるように、時間は水平軸にわたっている。
【0165】
UEは、RRCアイドル状態110で起動し、伝送される必要のあるローカルまたはモバイル生成データ、またはUTRANから受信されるページに基づいて、RRC接続を確立し始める。
【0166】
図4Aに図示されるように、RRC接続設定310が最初に発生することができ、RRC状態は、この期間中では接続状態410である。
【0167】
次に、信号伝達接続設定312、暗号化および完全性設定314、および無線ベアラ設定316が発生する。RRC状態は、これらの手順中ではCELL_DCH状態122である。図4Aに図示されるように、RRCアイドルから無線ベアラが設定される時間まで移動するための経過時間は、この実施例では約2秒である。
【0168】
次に、データが交換される。図4Aの実施例では、これは約2〜4秒で達成され、ステップ420によって図示される。
【0169】
データがステップ420で交換された後、必要に応じた断続的RLC信号伝達PDUを除いて、いずれのデータも交換されず、したがって、無線リソースは、約10秒後により低いデータ転送速度のDCH構成となるように、ネットワークによって再構成される。これは、ステップ422および424で図示される。
【0170】
より低いデータ転送速度のDCH構成では、17秒にわたって何も受信されず、その時点で、RRC接続がステップ428でネットワークによって解放される。
【0171】
いったんRRC接続解放がステップ428で開始されると、RRC状態は、約40ミリ秒間の切断状態430に進み、その後、UEはRRCアイドル状態110である。
【0172】
同様に図4Aに図示されるように、RRCがCELL_DCH状態122である期間にわたって、UE電流消費が図示される。ここで見られるように、電流消費は、CELL_DCH状態の期間全体にわたって、約200〜300ミリアンペアである。切断およびアイドル中に、1.28秒のDRXサイクルを仮定すると、約3ミリアンペアが利用される。しかしながら、200〜300ミリアンペアにおける35秒の電流消費がバッテリ上で排出している。
【0173】
ここで、図4Bを参照する。図4Bは、ここでは信号伝達接続解放のみを実施する、上記からの同じ例示的基礎構造「4」を利用する。
【0174】
図4Bに図示されるように、同じ設定ステップ310、312、314、および316が発生し、これは、RRCアイドル状態110とRRC CELL_DCH状態122との間で移動するときに同じ時間量を要する。
【0175】
さらに、図4Aのステップ420での例示的Eメールに対するRRCデータPDU交換は、図4Bでも行われ、これは、約2〜4秒かかる。
【0176】
図4Bの実施例のUEには、図4Bの実施例では2秒であり、ステップ440によって図示される、アプリケーション特有の非活動タイムアウトがある。特定の時間量にわたって非活動があると接続マネージャが判定した後に、UEは、この場合、ステップ442での信号伝達接続解放指示である、遷移指示を送信し、ステップ448では、ネットワークは、指示の受信およびUEに対する無線リソースプロファイルに基づいて、RRC接続を解放するように進む。
【0177】
図4Bで図示されるように、CELL_DCHステップ122中の電流消費は、依然として約200〜300ミリアンペアである。しかしながら、接続時間は、わずか約8秒である。当業者によって理解されるように、携帯電話がセルDCH状態122のままである、かなり短い時間量は、UEデバイスにとって有意なバッテリ節約をもたらす。
【0178】
ここで、図5を参照する。図5は、基礎構造「3」として上記で示される基礎構造を使用して、第2の実施例を示す。図4Aおよび4Bと同様に、約2秒かかる接続設定が発生する。これは、RRC接続設定310、信号伝達接続設定312、暗号化および完全性設定314、および無線ベアラ設定316を必要とする。
【0179】
この設定中に、UEは、RRCアイドルモード110からCELL_DCH状態122になり、その間にRRC状態接続ステップ410を伴う。
【0180】
図4Aと同様に、図5Aでは、RLCデータPDU交換がステップ420で発生し、図5Aの実施例では、2〜4秒かかる。
【0181】
基礎構造3によれば、RLC信号伝達PDU交換は、必要に応じた断続的RLC信号伝達PDUを除いて、いずれのデータも受信せず、したがって、ステップ422で5秒の期間にわたってアイドルであり、その時点で、無線リソースは、UEをCELL_DCH状態122からCELL_FACH状態124に再構成する。これは、ステップ450で行われる。
【0182】
CELL_FACH状態124では、RLC信号伝達PDU交換は、この場合は30秒である所定の時間量にわたって、必要に応じた断続的RLC信号伝達PDUを除いて、いずれのデータもないことを見出し、その時点で、ネットワークによるRRC接続解放がステップ428で行われる。
【0183】
図5Aで見られるように、これは、RRC状態をアイドルモード110にする。
【0184】
図5Aでさらに見られるように、DCHモード中の電流消費は、200〜300ミリアンペアの間である。CELL_FACH状態124になるとき、電流消費は、約120〜180ミリアンペアまで低下する。RRCコネクタが解放され、RRCがアイドルモード110になった後、電力消費は、約3ミリアンペアである。
【0185】
CELL_DCH状態122またはCELL_FACH状態124である、UTRA RRC接続モード状態は、図5Aの実施例では約40秒にわたって続く。
【0186】
ここで、図5Bを参照する。図5Bは、RRC接続設定310、信号伝達接続設定312、暗号化完全性設定314、および無線ベアラ設定316を得るように、約2秒の同じ接続時間を伴う、図5Aと同じ基礎構造「3」を図示する。さらに、RLCデータPDU交換420は、約2〜4秒かかる。
【0187】
図4Bと同様に、UEアプリケーションは、ステップ440で特定の非活動タイムアウトを検出し、その時点で、遷移指示(例えば、信号伝達接続解放指示442)がUEによって送信され、結果として、ネットワークがステップ448でRRC接続を解放する。
【0188】
図5Bでさらに見ることができるように、RRCは、アイドルモード110で起動し、CELL_FACH状態に進むことなくCELL_DCH状態122になる。
【0189】
図5Bでさらに見られるように、電流消費は、図5の実施例によれば約8秒である、RRC段階がCELL_DCH状態122である時間では、約200〜300ミリアンペアである。
【0190】
したがって、図4Aと4B、および図5Aと5Bとの間の比較は、有意量の電流消費が排除され、それにより、UEのバッテリ寿命を延長することを示す。当業者によって理解されるように、上記はさらに、現在の3GPP仕様書との関連で使用することができる。
【0191】
ここで、図6を参照する。図6は、UMTSネットワーク用のプロトコルスタックを図示する。
【0192】
図6で見られるように、UMTSは、CS制御プレーン610、PS制御プレーン611、およびPSユーザプレーン630を含む。
【0193】
これら3つのプレーン内には、非アクセス層(NAS)部分614およびアクセス層部分616が存在する。
【0194】
CS制御プレーン610におけるNAS部分614は、呼制御(CC)618、付加サービス(SS)620、およびショートメッセージサービス(SMS)622を含む。
【0195】
PS制御プレーン611におけるNAS部分614は、モビリティ管理(MM)およびGPRSモビリティ管理(GMM)626の両方を含む。それはさらに、セッション管理/無線アクセスベアラ管理SM/RABM624およびGSMS628を含む。
【0196】
CC618は、回線交換サービス用の呼管理信号伝達を提供する。SM/RABM624のセッション管理は、PDPテキスト有効化、無効化、および修正を提供する。SM/RABM624はまた、サービス交渉の質も提供する。
【0197】
SM/RABM624のRABM部分の主要機能は、PDPコンテキストを無線アクセスベアラに接続することである。したがって、SM/RABM624は、無線リソースの設定、修正、および解放に関与している。
【0198】
CS制御プレーン610およびPS制御プレーン611は、アクセス層616において、無線リソース制御(RRC)617の上に位置する。
【0199】
PSユーザプレーン630におけるNAS部分614は、アプリケーション層638、TCP/UDP層636、およびPDP層634を含む。PDP層634は、例えば、インターネットプロトコル(Internet Protocol/IP)を含むことができる。
【0200】
アクセス層616は、PSユーザプレーン630において、パケットデータ集中プロトコル(PDCP)632を含む。PDCP632は、(図8で見られるように)WCDMAプロトコルを、UEとRNCとの間でTCP/IPプロトコルを運ぶのに好適にするように設計され、随意で、IPトラッフィック流プロトコルヘッダ圧縮および復元用のものである。
【0201】
UMTS無線リンク制御(Radio Link Control/RLC)640および媒体アクセス制御(Medium Access Control/MAC)層650は、UMTS無線インターフェースのデータリンク副層を形成し、RNCノードおよびユーザ機器上に存在する。
【0202】
層1(L1)のUMTS層(物理層660)は、RLC/MAC層640および650の下側にある。この層は、通信用の物理層である。
【0203】
上記は、種々のモバイルまたはワイヤレスデバイス上に実装することができるが、1つのモバイルデバイスの実施例を、図7に関して以下で概説する。ここで、図7を参照する。
【0204】
UE700は、好ましくは、少なくとも音声およびデータ通信能力を有する、双方向ワイヤレス通信デバイスである。UE700は、好ましくは、インターネット上で他のコンピュータシステムと通信する能力を有する。提供される正確な機能性に応じて、ワイヤレスデバイスは、例として、データメッセージングデバイス、双方向ポケットベル、ワイヤレスEメールデバイス、データメッセージング能力付きの携帯電話、ワイヤレスインターネット機器、またはデータ通信デバイスと呼ばれてもよい。
【0205】
UE700は、双方向通信に有効である場合、受信器712および送信器714の両方、ならびに、1つ以上の、好ましくは、組み込まれた、または内部のアンテナ要素716および718、局部発振器(LO)713、およびデジタル信号プロセッサ(DSP)720等の処理モジュール等の、関連構成要素を含む、通信サブシステム711を組み込む。通信の当業者にとって明白となるように、通信サブシステム711の特定の設計は、デバイスが動作することを目的とする通信ネットワークに依存する。例えば、UE700は、GPRSネットワークまたはUMTSネットワーク内で動作するように設計される、通信サブシステム711を含んでもよい。
【0206】
ネットワークアクセス要件もまた、ネットワーク719の種類に応じて変動する。例えば、UMTSおよびGPRSネットワークでは、ネットワークアクセスは、UE700の加入者またはユーザと関連付けられる。したがって、例えば、GPRSモバイルデバイスは、GPRSネットワーク上で動作するために、加入者識別モジュール(SIM)カードを必要とする。UMTSでは、USIMまたはSIMモジュールが必要とされる。CDMAでは、RUIMカードまたはモジュールが必要とされる。これらは、本明細書では、UIMインターフェースと呼ばれる。有効なUIMインターフェースがないと、モバイルデバイスは、完全には機能しない場合がある。ローカルまたは非ネットワーク通信機能、ならびに緊急通話等の法的に必要な機能(もしあれば)が利用可能であってもよいが、モバイルデバイス700は、ネットワーク700上の通信を伴う、任意の他の機能を実行することができなくなる。UIMインターフェース744は、通常、ディスケットまたはPCMCIAカードのように、カードを挿入し、取り出すことができる、カードスロットと同様である。UIMカードは、約64Kのメモリを有し、多くの主要構成751と、識別および加入者関連情報等の他の情報753とを保持することができる。
【0207】
必要なネットワーク登録または有効化手順が完了すると、UE700は、ネットワーク719上で通信信号を送受信してもよい。通信ネットワーク719を通してアンテナ716によって受信される信号は、信号増幅、周波数下方変換、チャネル選択、および同等物等の一般的な受信器機能、および図7に示された実施例のシステムでは、アナログ・デジタル(A/D)変換を行ってもよい、受信器712への入力である。受信された信号のA/D変換は、DSP720で行われる復調および復号等の、より複雑な通信機能を可能にする。同様に、伝送される信号は、例えば、DSP720による復調および復号を含んで処理され、デジタル・アナログ変換、周波数上方変換、フィルタリング、増幅、およびアンテナ718を介した通信ネットワーク719上の伝送のために、送信器714に入力される。DSP720は、通信信号を処理するだけでなく、受信器および送信器制御も提供する。例えば、受信器712および送信器714において通信信号に適用される利得は、DSP720において実装される自動利得制御アルゴリズムを通して、適応的に制御されてもよい。
【0208】
ネットワーク719はさらに、サーバ760および他の要素(図示せず)を含む、複数のシステムと通信してもよい。例えば、ネットワーク719は、種々のサービスレベルを伴う種々のクライアントに適応するために、企業システムおよびウェブクライアントシステムの両方と通信してもよい。
【0209】
UE700は、好ましくは、デバイスの全体的動作を制御する、マイクロプロセッサ738を含む。少なくともデータ通信を含む、通信機能は、通信サブシステム711を通して果たされる。マイクロプロセッサ738はまた、ディスプレイ722、フラッシュメモリ724、ランダムアクセスメモリ(RAM)726、補助入力/出力(I/O)サブシステム728、シリアルポート730、キーボード732、スピーカ734、マイクロフォン736、短距離通信サブシステム740、および、概して742と指定される任意の他のデバイスサブステム等の、さらなるデバイスサブシステムとも相互作用する。
【0210】
図7に示されたサブシステムのうちのいくつかは、通信関連機能を果たすが、他のサブシステムは、「常駐」またはオンデバイス機能を提供してもよい。明白に、例えば、キーボード732およびディスプレイ722等のいくつかのサブシステムは、通信ネットワーク上で伝送するためのテキストメッセージの入力等の通信関連機能と、計算機またはタスクリスト等のデバイス常駐機能との両方に使用されてもよい。
【0211】
マイクロプロセッサ738によって使用されるオペレーティングシステムソフトウェアは、好ましくは、代わりに読み出し専用メモリ(ROM)または同様の記憶要素(図示せず)であってもよい、フラッシュメモリ724等の持続的記憶部に記憶される。当業者であれば、オペレーティングシステム、特定のデバイスアプリケーション、またはその部分は、RAM726等の揮発性メモリに一時的に取り込まれてもよいことを理解するであろう。受信された通信信号もまた、RAM726に記憶されてもよい。さらに、一意の識別子もまた、好ましくは読み取り専用メモリに記憶される。
【0212】
示されるように、フラッシュメモリ724は、コンピュータプログラム758と、プログラムデータ記憶部750、752、754、および756との両方に対する異なるエリアに分離することができる。これらの異なる記憶型は、各プログラムが、独自のデータ記憶要件のためにフラッシュメモリ724の一部分を割り当てることができることを示す。マイクロプロセッサ738は、そのオペレーティングシステム機能に加えて、好ましくは、モバイルデバイス上でのソフトウェアアプリケーションの実行を可能にする。例えば、少なくともデータおよび音声通信アプリケーションを含む、基本動作を制御する所定の一式のアプリケーションが、通常、製造中にUE700にインストールされる。好ましいソフトウェアアプリケーションは、Eメール、カレンダーイベント、音声メール、約束、およびタスクアイテム等であるが、それらに限定されない、モバイルデバイスのユーザに関するデータアイテムを整理および管理する能力を有する、個人情報マネージャ(PIM)アプリケーションであってもよい。当然ながら、1つ以上のメモリ記憶部が、PIMデータアイテムの記憶を促進するようにモバイルデバイス上で利用可能となる。そのようなPIMアプリケーションは、好ましくは、ワイヤレスネットワーク719を介してデータアイテムを送受信する能力を有する。好ましい実施形態では、PIMデータアイテムは、ワイヤレスネットワーク719を介して、途切れなく統合、同期化、および更新され、モバイルデバイスユーザの対応するデータアイテムが、記憶されるか、またはホストコンピュータシステムと関連付けられる。さらなるアプリケーションもまた、ネットワーク719、補助I/Oサブシステム728、シリアルポート730、短距離通信サブシステム740、または任意の他の好適なサブシステム742を通して、モバイルデバイス700上に搭載され、マイクロプロセッサ738による実行のために、RAM726、または好ましくは不揮発性記憶部(図示せず)に、ユーザによってインストールされてもよい。アプリケーションのインストールにおける、そのような融通性は、デバイスの機能性を増加させ、強化オンデバイス機能、通信関連機能、または両方を提供してもよい。例えば、安全な通信アプリケーションは、電子商取引機能および他のそのような金融取引が、UE700を使用して行われることを可能にしてもよい。しかしながら、これらのアプリケーションは、上記によれば、多くの場合において、通信事業社によって承認される必要がある。
【0213】
データ通信モードでは、テキストメッセージまたはウェブページダウンロード等の受信された信号は、通信サブシステム711によって処理され、好ましくは、ディスプレイ722に、または代替として補助I/Oデバイス728に出力するために、受信された信号をさらに処理する、マイクロプロセッサ738に入力される。UE700のユーザはまた、ディスプレイ722、およびおそらく補助I/Oデバイス728と併せて、例えば、好ましくは、完全英数字キーボードまたは電話型キーパッドである、キーボード732を使用して、Eメールメッセージ等のデータアイテムを構成してもよい。次いで、そのような構成されたアイテムは、通信サブシステム711を通して通信ネットワーク上で伝送されてもよい。
【0214】
音声通信については、受信された信号が、好ましくはスピーカ734に出力され、伝送するための信号が、マイクロフォン736によって生成されることを除いて、UE700の全体的動作は同様である。音声メッセージ録音サブシステム等の、代替的な音声またはオーディオI/Oサブシステムもまた、UE700上に実装されてもよい。音声またはオーディオ信号出力は、好ましくは、主にスピーカ734を通して達成されるが、ディスプレイ722もまた、例えば、発呼者の身元、音声電話の持続時間、または他の音声電話関連情報の指示を提供するために使用されてもよい。
【0215】
図7のシリアルポート730は、通常、ユーザのデスクトップコンピュータ(図示せず)との同期化が望ましくてもよい、携帯情報端末(PDA)型モバイルデバイスで実装される。そのようなポート730は、外部デバイスまたはソフトウェアアプリケーションを通して、ユーザが選好を設定することを可能にし、ワイヤレス通信ネットワーク以外を通して、UE700への情報またはソフトウェアダウンロードを提供することによって、モバイルデバイス700の能力を拡張する。例えば、直接的であり、したがって確実かつ信頼されている接続を通して、暗号化キーをデバイスに搭載し、それにより、安全なデバイス通信を可能にするために、代替ダウンロード経路が使用されてもよい。
【0216】
代替として、シリアルポート730は、他の通信に使用することができ、かつユニバーサルシリアルバス(USB)ポートとして含むことができる。インターフェースがシリアルポート730と関連付けられる。
【0217】
短距離通信サブシステム等の、他の通信サブシステム740は、UE700と、必ずしも同様のデバイスである必要はない、異なるシステムまたはデバイスとの間の通信の通信を提供してもよい、さらなるオプションの構成要素である。例えば、サブシステム740は、同様に有効化されたシステムおよびデバイスとの通信を提供するように、赤外線デバイスならびに関連回路および構成要素、またはBluetoothTM通信モジュールを含んでもよい。
【0218】
ここで、図8を参照する。図8は、ワイヤレス通信ネットワークを通して通信するUE802を含む、通信システム800のブロック図である。
【0219】
UE802は、1つまたは複数のノードB806とワイヤレスで通信する。各ノードB806は、エアインターフェース処理およびいくつかの無線リソース管理機能に関与している。ノードB806は、GSM/GPRSネットワークにおけるベーストランシーバ基地局と同様の機能性を提供する。
【0220】
図8の通信システム800において示されるワイヤレスリンクは、1つ以上の異なるチャネル、典型的には、異なる無線周波数(RF)チャネル、およびワイヤレスネットワークとUE802との間で使用される関連プロトコルを表す。Uuエアインターフェース804は、UE802とノードB806との間で使用される。
【0221】
RFチャネルは、典型的には、帯域幅全体の制限およびUE802の限定されたバッテリ電力により、節約されなければならない、限定されたリソースである。当業者であれば、実際の実践でのワイヤレスネットワークは、ネットワーク範囲の所望の全体的拡張に応じて、数百のセルを含んでもよい。全ての関連構成要素は、複数のネットワークコントローラによって制御される、複数のスイッチおよびルータ(図示せず)によって接続されてもよい。
【0222】
各ノードB806は、無線ネットワークコントローラ(RNC)810と通信する。RNC810は、そのエリアでの無線リソースの制御に関与している。1つのRNC810は、複数のノードB806を制御する。
【0223】
UMTSネットワークにおけるRNC810は、GSM/GPRSネットワークにおける基地局コントローラ(BSC)機能と同等の機能を提供する。しかしながら、RNC810は、MSCおよびSGSNを伴うことなく、例えば、自律ハンドオーバ管理を含む、さらなる知能を含む。
【0224】
ノードB806とRNC810との間で使用されるインターフェースは、lubインターフェース808である。3GPP TS 25.433 V3.11.0(2002−09)および3GPP TS 25.433 V5.7.0(2004−01)で定義されるように、NBAP(ノードBアプリケーション部)信号伝達プロトコルが主に使用される。
【0225】
ユニバーサル地上波無線アクセスネットワーク(UTRAN)820は、RNC810、ノードB806、およびUuエアインターフェース804を備える。
【0226】
回線交換トラフィックは、携帯電話交換センター(Mobile Switching
Centre/MSC)830に経路指定される。MSC830は、電話をかけ、加入者から、またはPSTN(図示せず)からデータを取り入れ、受信する、コンピュータである。
【0227】
RNC810とMSC830との間のトラフィックは、Iu−CSインターフェース828を使用する。Iu−CSインターフェース828は、UTRAN820とコア音声ネットワークとの間で(典型的には)音声トラフィックおよび信号伝達を運ぶための回線交換接続である。使用される主要信号伝達プロトコルは、RANAP(無線アクセスネットワークアプリケーション部)である。RANAPプロトコルは、MSC830またはSGSN850(以下でさらに詳細に定義される)となり得る、コアネットワーク821と、UTRAN820との間のUMTS信号伝達で使用される。RANAPプロトコルは、3GPP TS 25.413 V3.11.1(2002−09)およびTS 25.413 V5.7.0(2004−01)で定義される。
【0228】
ネットワーク操作者により登録された全てのUE802について、永久データ(UE802のユーザのプロファイル等)ならびに一時データ(UE802の現在のロケーション等)が、ホームロケーションレジストリ(HLR)838に記憶される。UE802の音声電話の場合、HLR838は、UE802の現在のロケーションを判定するように問い合わせられる。MSC830のビジタロケーションレジスタ(Visitor Location Register/VLR)836は、一群のロケーションアリアに関与しており、現在その責任エリアにある移動局のデータを記憶する。これは、より迅速なアクセスのために、HLR838からVLR836に伝送された永久移動局データの複数部分を含む。しかしながら、MSC830のVLR836はまた、一時的識別等のローカルデータを割り当て、記憶してもよい。UE802はまた、HLR838によるシステムアクセスで認証される。
【0229】
パケットデータは、サービスGPRSサポートノード(Service GPRS Support Node/SGSN)850を通して経路指定される。SGSN850は、GPRS/UMTSネットワークにおけるRNCとコアネットワークとの間のゲートウェイであり、その地理的サービスエリア内でUEを往復するデータパケットの配信に関与している。Iu−PSインターフェース848は、RNC810とSGSN850との間で使用され、UTRAN820とコアデータネットワークとの間で(典型的には)データトラフィックおよび信号伝達を運ぶためのパケット交換接続である。使用される主要信号伝達プロトコルは、RANAP(上記で説明される)である。
【0230】
SGSN850は、ゲートウェイGPRSサポートノード(Gateway GPRS
Support Node/GGSN)860と通信する。GGSN860は、UMTS/GPRSネットワークと、インターネットまたはプライベートネットワーク等の他のネットワークとの間のインターフェースである。GGSN860は、Giインターフェース上で公衆データネットワークPDN870に接続される。
【0231】
当業者であれば、ワイヤレスネットワークは、おそらく、図8で明示的に示されていない他のネットワークを含む、他のシステムと接続されてもよいことを理解するであろう。たとえ交換された実際のパケットデータがなくても、ネットワークは、通常、最低限でも、ある種類のページングおよびシステム情報を継続的に伝送する。ネットワークは多くの部分から成るが、これらの部分は全て、ワイヤレスリンクにおいてある動作をもたらすように協働する。
【0232】
図11は、複数の同時パケットデータ通信サービスセッションに従ってUEの動作を表す、概して1102で示される表現を図示する。ここでは、それぞれPDP1およびPDP2と指定される特定のPDPコンテキストと関連付けられる、2つのパケットデータサービスが、現在アクティブである。プロット1104は、第1のパケットデータサービスに有効化されたPDPコンテキストを表し、プロット1106は、第1のパケットデータサービスに割り当てられた無線リソースを表す。そして、プロット1108は、第2のパケットデータサービスに有効化されたPDPコンテキストを表し、プロット1112は、第2のパケットデータサービスに割り当てられた無線リソースを表す。UEは、セグメント1114によって示されるサービス要求を介して、無線アクセスベアラ割当を要求する。そして、UEはまた、本開示の実施形態に従ってセグメント1116によって示される、無線ベアラサービス解放も要求する。サービス要求および別個のサービスのためのサービス解放は、相互とは無関係であり、すなわち、独立して生成される。図11の例示的説明図では、PDPコンテキストおよび関連PDPコンテキストに対する無線リソースは、実質的に同時に割り当てられる。そして、無線リソース解放は、示されるように、UEによる要求時に、またはRNC(無線ネットワークコントローラ)が無線リソースを解放することを決定するときに、許可される。
【0233】
無線リソース解放要求、または無線リソースを解放する他の決定に対応して、ネットワークは、パケットデータサービスと関連付けられた無線リソースを選択的に解除する。無線解放要求は、信号伝達接続全体ではなく、無線アクセスベアラごとに行われ、それにより、リソース割当の向上した粒度制御を可能にする。
【0234】
例示的実装では、指定1118および1122によって示されるような1次サービスおよび1つ以上の2次サービスとして、単一のパケットデータサービスをさらに形成可能である。無線リソース解放は、無線リソース割当がもはや必要ではない、またはそうでなければ解放されることが所望される、1つ以上の1次および2次サービスのどれかを識別するステップのさらなる許容である。それにより、効率的な無線リソース割当が提供される。加えて、不必要な処理に割り当てられたであろうプロセッサ電力を、ここでは他の目的でより良好に利用することができるため、UE上のプロセッサの最適な利用が提供される。
【0235】
図12は、通信システム800の部品、すなわち、複数の連続パケットデータサービスセッションに関する本開示の実施形態に従って動作する、UE802および無線ネットワークコントローラ(RNC)/SGSN810/850を図示する。UEは、装置1126を含み、RNC/SGSNは、本開示の実施形態の装置1128を含む。装置1126および1128を形成する要素は、処理回路ならびにハードウェアまたはファームウェア実装によって実行可能なアルゴリズムを含む、任意の所望の方式で実装可能であると機能的に表されている。装置1128の要素は、RNC/SGSNにおいて具体化されると表されているが、他の実施では、他のネットワークロケーションにおいて他の場所で形成されるか、または、2つ以上のネットワークロケーションにわたって分布させられる。
【0236】
装置1126は、検出器1132および遷移指示送信機1134を含む。1つの例示的実施では、要素1132および1134は、セッション管理層、例えば、UEのUMTSの中で画定される非アクセス層(Non−Access Stratum/NAS)の層において具体化される。
【0237】
別の例示的実装では、要素は、アクセス層(Access Stratum/AS)の副層において具体化される。AS副層において実装されると、要素は、1136で示される、接続マネージャの一部として実装される。このように実装されると、要素は、PDPコンテキスト動作またはアプリケーション層動作を認識する必要がない。
【0238】
検出器は、パケット通信サービスと関連付けられた遷移指示を送信するように、判定が行われるときを検出する。判定は、例えば、アプリケーション層または他の論理層で行われ、セッション管理層およびそこで具体化される検出器に提供される。検出器によって行われる検出の指示は、無線リソース解放指示送信機に提供される。送信機は、図11に示されたサービス解放要求1116を形成する遷移指示を生成し、UEに遷移指示を送信させる。
【0239】
さらなる実装では、遷移指示は、必要に応じて、ここと上記とで説明される前述の原因のうちのいずれか等の原因を含有する、原因フィールドを含み、または、原因フィールドは、UEを遷移させるよりもUEがネットワークを好む、好ましい状態を識別する。
【0240】
ネットワークにおいて具体化される装置1128は、検査器1142および許可器1144を含む。検査器は、そこで受信されると遷移指示を検査する。そして、遷移許可器1144は、遷移指示で要求されたように、UEを選択的に遷移させるように動作する。
【0241】
信号伝達が無線リソース制御(RRC)層で行われる実装では、SGSNよりもむしろ、無線ネットワークコントローラ(RNC)がUEの検査および遷移を行う。そして、それに対応して、UEにおいて具体化される装置は、RRC層で形成され、または、装置は、そうでなければ、生成された指示をRRCレベルで送信させる。
【0242】
例示的な制御フローでは、上位層は、必要に応じて、特定のPDPコンテキストに割り当てられる無線リソースがもはや必要ではないことを、NAS/RRC層に知らせる。RRC層指示メッセージが、ネットワークに送信される。メッセージは、例えば、無線ネットワークコントローラへのパケットデータサービスを識別する、RAB IDまたはRB
IDを含む。そして、それに応じて、無線ネットワークコントローラの動作は、UEに返信される無線リソース解放、無線リソース再構成、または無線リソース制御(RRC)接続解放メッセージを終了する決意をする手順を誘起する。RNC手順は、例えば、3GPP文書TS 23.060第9.2.5項で定められる手順と同様または同等である。RAB IDは、例えば、関連PDPコンテキストを識別するネットワークサービスアクセスポイント識別子(Network Service Access Point Identifier/NSAPI)と同じであるIDとして、有利に利用され、アプリケーション層は、概してNSAPIを認識している。
【0243】
具体的実施例では、RRC層で形成され、またはそうでなければRRC層に提供され、かつRRC層で送信される、無線リソース解放指示が、以下の関連情報とともに表される。RRC層で具体化されたときの指示はまた、例えば、無線リソース解放指示とも呼ばれる。
【0244】
【表11】
図13は、図11に示されたグラフ表示の一部に図式的に示されたもの等の、PDPコンテキストと関連付けられた無線リソースの解放に従って生成される例示的信号伝達を表す、概して1137で示される、メッセージシーケンス図を図示する。解放は、UEによって、またはRNCあるいは他のUTRANエンティティにおいて、開始される。例えば、UEにおいて開始されると、UEは、UTRANに無線リソース解放指示を送信する。
【0245】
開始時に、セグメント1138によって示されるように、無線アクセスベアラ(RAB)解放要求がRNC/UTRANによって生成および送信され、SGSNに配信される。それに応じて、セグメント1140によって示される、RAB割当要求がRNC/UTRANに返信される。次いで、セグメント1142によって示されるように、UE802とUTRANとの間に延在する無線リソースが解放される。次いで、セグメント1144によって示されるように、応答が送信される。
【0246】
図14は、図13に示されたメッセージシーケンス図と同様である、概して1147で示される、メッセージシーケンス図を図示するが、ここでは、最終PDPコンテキストのリソースが解放される。開始時に、RNCがIu解放要求1150を生成し、SGSNに伝達され、それに対応して、SGSNは、セグメント1152によって示される、Iu解放コマンドを返信する。その後、セグメント1154によって示されるように、UEとUTRANとの間に形成される無線ベアラが解放される。そして、セグメント1156によって示されるように、RNC/UTRANは、SGSNにIu解放完了を返信する。
【0247】
図15は、PDPコンテキストに従って割り当てられる無線リソースを解放する本開示の実施形態の過程を表す、概して1162で示される、方法フロー図を図示する。
【0248】
ブロック1164によって示される、過程の開始後に、無線リソース解放指示が受信されたかどうかに関して、決定ブロック1166によって示される、判定が行われる。受信されていなければ、「いいえ」の分岐が終了ブロック1168に運ばれる。
【0249】
もし、逆に、無線アクセスベアラ解放が要求されていれば、「はい」の分岐が決定ブロック1172に運ばれる。決定ブロック1172では、解放される無線アクセスベアラが解放される最終無線アクセスベアラであるかどうかに関して、判定が行われる。もしそうでなければ、「いいえ」の分岐がブロック1178に運ばれ、好ましい状態が設定される。次いで、図13に示されたもの等の、または3GPP文書第23.060項の第9.2.5.1.1従属節で説明されるもの等の、無線アクセスベアラ解放手順が行われる。
【0250】
逆に、RABが最後に解放されるものであるという判定が決定ブロック1172において行われた場合、「はい」の分岐がブロック1186に運ばれ、図14に示されたもの等の、または3GPP文書第23.060項の第9.2.5.1.2従属節で説明されるもの等の、Iu解放手順が行われる。
【0251】
図16は、PDPコンテキストに従って割り当てられる無線リソースを解放する本開示の実施形態の過程を表す、概して1192で示される、方法フロー図を図示する。
【0252】
ブロック1194によって示される、過程の開始後に、解放するRAB(無線アクセスベアラ)があるかどうかに関して、決定ブロック1196によって示される決定が行われる。もしなければ、「いいえ」の分岐が終了ブロック1198に運ばれる。
【0253】
もし、逆に、無線アクセスベアラ解放が要求されていれば、「はい」の分岐が決定ブロック1202に運ばれる。決定ブロック1202では、解放される無線アクセスベアラが解放される最終無線アクセスベアラであるかどうかに関して、判定が行われる。もしそうでなければ、「いいえ」の分岐は、RABが設定されるブロック1204、好ましい状態が設定されるブロック1206、および、図13に示されたもの等の、または3GPP文書第23.060項の第9.2.5.1.1従属節で説明されるもの等の、無線アクセスベアラ解放手順が行われる、ブロック1208に運ばれる。
【0254】
逆に、RABが最後に解放されるものであるという判定が決定ブロック1202において行われた場合、「はい」の分岐がブロック1212に運ばれ、ドメインがPS(パケット交換)に設定される。次いで、ブロック1214によって示されるように、解放原因が設定される。そして、ブロック1216によって示されるように、信号伝達接続解放指示がDCCH上で設定される。図14に示されたもの等の、または3GPP文書第23.060項の第9.2.5.1.2従属節で説明されるもの等の、Iu解放手順が行われる。
【0255】
図17は、本開示の実施形態の操作の方法を表す、概して1224で示される方法を図示する。方法は、第1のパケットサービスおよび第2のパケットサービスの同時実行を提供する、無線通信システムにおける無線リソースの効率的な利用を促進する。第1に、ブロック1226によって示されるように、第1のパケットサービスおよび第2のパケットサービスのうちの選択されたパケットサービスと関連付けられた無線リソースを解放する選択の検出が行われる。次いで、ブロック1228によって示されるように、無線リソースを解放する選択の検出に対応して、無線リソース解放指示が送信される。
【0256】
次いで、ブロック1212では、無線リソース解放指示が検査され、次いで、ブロック1214では、無線ベアラの解放の付与が選択的に許可される。
【0257】
さらなる実施形態では、ネットワークは、ユーザ機器または別のネットワーク要素からの指示の受信と、ユーザ機器に対する無線リソースプロファイルとの両方に基づいて、遷移を開始してもよい。
【0258】
ユーザ機器またはネットワーク要素から受信されるような指示は、上記で説明される異なる遷移指示のうちのいずれかとなり得る。指示は、受動的となり得るため、単に、あまりバッテリ集約的ではない無線状態になるべきであるという空白指示となり得る。代替として、指示は、おそらく、経時的に、または多数の受信された指示にわたって、ネットワークが判定する、UEから送信された定期的な指示の一部、およびあまりバッテリまたは無線リソース集約的ではない無線状態になるべきであるというUEの無線リソースプロファイルとなり得る。代替として、指示は、動的となり得て、遷移する好ましい状態またはモードについてネットワーク要素に情報を提供することができる。上記とどうように、指示は、指示の原因(例えば、正常または異常)を含有することができる。さらなる実施形態では、指示は、異なる状態またはモードに遷移する能力についてユーザ機器が的確であるという確率、または指示を誘起するアプリケーションについての情報等の、無線リソースプロファイルについて他の情報を提供することができる。
【0259】
別のネットワーク要素からの指示は、例えば、メディアまたはプッシュ・トゥ・トークネットワークエンティティからの指示を含むことができる。この実施例では、指示は、トラッフィク条件が許容するときに遷移に関与しているネットワークエンティティ(例えば、UTRAN)に送信される。この第2のネットワークエンティティは、インターネットプロトコル(IP)レベルでトラフィックを見て、遷移指示を送信するかどうか、およびいつ送信するかを判定することができる。
【0260】
さらなる実施形態では、UEまたは第2のネットワーク要素からの指示は、明示的よりもむしろ暗示的となり得る。例えば、遷移指示は、アウトバウンドトラフィック測定値についてのデバイス状態報告から、遷移に関与しているネットワーク要素(例えば、UTRAN)によって暗示されてもよい。具体的には、状態報告は、いずれのアウトバウンドデータも存在しなければ、暗示的な指示として解釈され得る、無線リンクバッファ状態を含むことができる。そのような状態報告は、単独では何も要求または指示しないUEから繰り返し送信することができる、測定値となり得る。
【0261】
したがって、指示は、任意の信号となり得て、ユーザ機器のアプリケーションおよび無線リソースの全てに関する情報を提供する、アプリケーションベースの指示、無線リソースベースの指示、または複合指示となり得る。上記は、特定の指示に限定的となるように意図されておらず、当業者であれば、本方法および開示とともに任意の指示を使用できることを理解するであろう。
【0262】
ここで、図18を参照する。過程は、ステップ1801から開始し、ネットワーク要素が指示を受信するステップ1810に進む。
【0263】
いったんネットワークがステップ1810で指示を受信すると、過程は、ユーザ機器に対する無線リソースプロファイルが随意でチェックされる、ステップ1820に進む。
【0264】
本明細書で使用される場合、「無線リソースプロファイル」という用語は、ネットワーク要素の要件に応じて、種々の状況に該当し得る広義語となるように意図されている。広義語では、無線リソースプロファイルは、ユーザ機器によって利用される無線リソースについての情報を含む。
【0265】
無線リソースプロファイルは、静的プロファイル要素および動的または交渉型プロファイル要素のいずれか一方または両方を含むことができる。そのような要素は、遷移プロファイル内にあるか、または遷移プロファイルから離れている、無線リソースプロファイルの一部となり得て、かつ交渉型または静的となり得る、「時間窓あたりの阻止期間および/または最大指示/要求メッセージ」値を含むことができる。
【0266】
静的プロファイル要素は、無線リソース(例えば、RABまたはRB)のサービスの質、PDPコンテキスト、ネットワークが知っているAPN、および加入者プロファイルのうちの1つ以上を含んでもよい。
【0267】
当業者によって理解されるように、サービスの質の種々のレベルが、無線リソースについて存在することができ、サービスの質のレベルは、異なる状態またはモードに遷移するかどうかについて、ネットワークに情報を提供することができる。したがって、サービスの質がバックグラウンドであれば、ネットワーク要素は、サービスの質が双方向に設定された場合よりも容易に、アイドルに遷移することを考慮してもよい。さらに、複数の無線リソースが同じサービスの質を有する場合、これは、モバイルデバイスをより好適な状態またはモードに遷移させるか、または無線リソースを解除するかどうかについて、ネットワークに指示を提供することができる。いくつかの実施形態では、1次または2次PDPコンテキストは、異なるサービスの質を有することができ、それはまた、状態/モード遷移を行うかどうかについての決定にも影響を及ぼし得る。
【0268】
さらに、APNは、ネットワークに、PDPコンテキストが利用する典型的サービスについての情報を提供することができる。例えば、APNがxyz.comであれば、その場合、xyz.comは、典型的にはEメール等のデータサービスの提供に使用され、これは、異なる状態またはモードを遷移するか否かについて、ネットワークに指示を提供することができる。これはさらに、ルーティング特性を示すことができる。
【0269】
具体的には、本方法および装置は、種々の状態間で遷移プロファイルを設定するために、UEによって特定されるアクセスポイント名(Access Point Name/APN)を利用することができる。これは、UEの加入を説明する別の方法であってもよい。理解されるように、ホームロケーションレジスタ(Home Location Register/HLR)が、加入者についての関連情報を記憶してもよく、無線ネットワークコントローラ(RNC)にUEの加入を提供することができる。加入情報を中央で記憶するために、他のネットワークエンティティも使用することができる。HLRを使用しても、または他のネットワークエンティティを使用しても、情報は、好ましくは、加入者情報をデータ交換中に使用される関連物理パラメータにマップする、RNCおよびSGSN等の他のネットワーク構成要素にプッシュ配信される。
【0270】
UTRANは、種々のAPNまたはQoSパラメータを特定の遷移プロファイルに結び付けることができる、データベースまたはテーブルへのアクセスを含むか、または有することができる。したがって、UEが常時オンデバイスである場合、これはAPNから明白となり、そのAPNに対する適切な遷移プロファイルは、無線リソースプロファイルの一部としてUTRANで記憶することができ、または、UTRANによって遠隔でアクセス可能となり得る。同様に、QoSまたはQoSパラメータの一部分が使用されるか、または専用メッセージがプロファイルとともに送信される場合、これは、データベースクエリまたはテーブルの参照に基づいて、特定の遷移プロファイルが所望されることをUTRANに知らせることができる。加えて、RRC接続状態遷移プロファイルを越えた数多くの動作を、この手段によって特定することができる。これらは、以下を含むが、それらに限定されない。
速度適応アルゴリズム(ステップの周期性/ステップサイズ)、
初期許可無線ベアラ、
最大許可無線ベアラ、
呼設定時間の最小限化(トラフィック量測定等の不必要なステップの回避)、および
エアインターフェース(GPRS/EDGE/UMTS/HSDPA/HSUPA/LTE等)。
【0271】
さらに、1次コンテキスト、2次コンテキスト等の、異なるQoS要件を有するが、同じAPN IPアドレスを共有する、複数のPDPコンテキストがある場合、異なる遷移プロファイルを各コンテキストに使用することができる。これは、QoSまたは専用メッセージを通してUTRANに信号伝達することができる。
【0272】
複数のアクティブPDPコンテキストが同時に利用される場合、コンテキスト間の最小公分母を使用することができる。RRC状態遷移については、1つのアプリケーションが、システムが早急にCELL_DCH状態からCELL_PCHまたはアイドル状態になる、遷移プロファイルと関連付けられる第1のPDPコンテキストと、システムがより長くCELL_DCH状態にとどまるものである、遷移プロファイルと関連付けられる第2のPDPコンテキストとを有する場合、CELL_DCH状態がより長く維持される第2のプロファイルが、第1のプロファイルに優先する。
【0273】
当業者によって理解されるように、最小公分母は、2つの異なる方法で考慮することができる。本明細書で使用されるような最小公分母は、異なる状態に遷移する前に必要とされる最長の時間を暗示する。第1の実施形態では、最小公分母は、有効化されたPDPの中の最小のものであってもよい。代替実施形態では、最小公分母は、実際にアクティブ無線リソースを有するPDPの中の最小のものであってもよい。無線リソースは、多数の異なる様式で多重化することができるが、最終結果は同じである。
【0274】
そのような方法の例示的な事例は、常時オンデバイスについて描くことができる。説明されるように、種々のAPNまたはQoSパラメータは、常時オンに対する特定の動作に結び付けることができる。「常時オン」プロファイルに基づいて望ましくてもよい、最初に許可された無線リソースを考慮されたい。ここで、ネットワークは、データバーストが、Eメール等の常時オンアプリケーションについて短く集中的であることを「知る」手段を有する。当業者にとって、この情報を考慮すると、ネットワーク上のトランキング効率のためにコード空間を節約する誘因がないことが明確に分かる。したがって、他のユーザのために十分なコード空間を取っておかないという危険性がほとんどなく、最大速度が常時オンデバイスに割り当てられてもよい。加えて、UEは、より急速にデータを受信する恩恵を受け、また、より短い「オン時間」により、バッテリ寿命を節約する。再度、当業者にとって、データ転送速度にかかわらず、電力増幅器が完全にバイアスされるため、高データ転送速度は電流引き込みにほとんど影響を及ぼさない。
【0275】
上記の実施形態では、UEに対する所与のRRC接続のために、異なるアプリケーションについて割り当てられる無線リソースに対するリソース制御プロファイルを判定するために、UTRANによって参照テーブルを使用することができる。RNCが、利用可能なより最新式のトラフィックリソース(すなわち、許可することができるデータ転送速度)を有するため、プロファイルは、ユーザ加入に基づき、HLR等のネットワークエンティティにおいて、または代替としてRNCにおいて、ネットワーク側に記憶することができる。より高速のデータ転送速度を達成することができる場合、より短いタイムアウトが可能であってもよい。
【0276】
APNの代わりに、パケットデータプロトコル(Packet Data Protocol/PDP)コンテキスト活性化または修正PDPコンテキストにおいて設定されるサービスの質(Quality of Service/QoS)パラメータ等の、他の代替案を使用することができる。QoSフィールドはさらに、同じAPNを共有する複数のPDPコンテキスト、または遷移プロファイルを設定する加入プロファイルの場合に、QoS「割当保持優先順位(トラフィックデータ量を推測するために、サービスデータ単位を使用することができる)」を含むことができる。さらなる代替案は、リソース制御プロファイルを信号伝達する上記の指示メッセージ等の専用メッセージ、および時間窓あたりの阻止期間および/または最大指示/要求メッセージ値等の情報を含む。
【0277】
無線リソースプロファイルに含まれる遷移プロファイルはさらに、アプリケーションの種類に基づいて、UEの状態を全く遷移させるべきかどうかを含むことができる。具体的には、ユーザ機器がデータモデムとして使用されている場合、遷移指示が送信されないように、選好がユーザ機器上で設定されてもよく、または、選好の知識がネットワークにおいて維持される場合、データモデムとして使用されている間にUEから受信される任意の遷移指示は、無視されるべきである。したがって、ユーザ機器上で実行されているアプリケーションの性質を、無線リソースプロファイルの一部として使用することができる。
【0278】
遷移プロファイルのさらなるパラメータは、遷移の種類を伴うことができる。具体的には、UMTSネットワークにおいて、ユーザ機器は、種々の理由で、アイドル状態になるよりもむしろCell_PCH状態になることを好んでもよい。1つの理由は、データが送信または受信される必要がある場合に、UEがより早急にCell_DCH状態に接続する必要があり、したがって、Cell_PCH状態になることは、Cell_PCH状態への早急な遷移を依然として提供しながら、いくつかのネットワーク信号伝達およびバッテリリソースを節約するという点となり得る。上記は、非UMTSネットワークで同等に適用可能であり、種々の接続状態とアイドル状態との間の遷移プロファイルを提供してもよい。
【0279】
遷移プロファイルはまた、時間窓あたりの阻止期間および/または最大指示/要求メッセージ、遅延タイマ、および非活動タイマを含むが、それらに限定されない、種々のタイマを含んでもよい。遅延タイマは、新規状態またはモードに遷移する前にネットワーク要素が待つ期間を提供する。理解されるように、たとえアプリケーションが特定の期間にわたって活動していなくても、さらなるデータがアプリケーションから受信または伝送されないことを確実にするために、遅延が有益であってもよい。非活動タイマは、データがプリケーションによって受信または送信されない所定の期間を測定することができる。非活動タイマが期限切れになる前にデータが受信された場合、典型的には、非活動タイマはリセットされる。いったん非活動タイマが期限切れになると、ユーザ機器は、ネットワークにステップ1810の指示を送信してもよい。代替として、ユーザ機器は、ステップ1810の指示を送信する前に、遅延タイマについて定義される期間等の、ある期間にわたって待ってもよい。
【0280】
さらに、遅延タイマ、または時間窓あたりの阻止期間および/または最大指示/要求メッセージは、ネットワーク要素に提供されるプロファイルに基づいて変動することができる。したがって、異なるモードまたは状態への遷移を要求したアプリケーションが、Eメールアプリケーション等の第1の種類のアプリケーションである場合、ネットワーク要素上の遅延タイマを第1の遅延時間に設定することができ、一方で、アプリケーションが、インスタントメッセージングアプリケーション等の第2の種類である場合、遅延タイマを第2の値に設定することができる。時間窓あたりの阻止期間および/または最大指示/要求メッセージ、遅延タイマ、または非活動タイマの値はまた、特定のPDPに利用されるAPNに基づいて、ネットワークによって導出することもできる。
【0281】
当業者によって理解されるように、非活動タイマは、同様に、利用されるアプリケーションに基づいて変動することができる。したがって、Eメールアプリケーションが別個のメッセージを予期しており、その後にデータを受信しない場合があるため、Eメールアプリケーションは、ブラウザアプリケーションよりも短い非活動タイマを有してもよい。逆に、ブラウザアプリケーションは、より長い遅延後でさえもデータを利用し、したがって、より長い非活動タイマを必要としてもよい。
【0282】
遷移プロファイルはさらに、ユーザ機器が正しく遷移を要求している確率を含んでもよい。これは、特定のユーザ機器またはユーザ機器上のアプリケーションの正確率についてまとめられた統計に基づくことができる。
【0283】
遷移プロファイルはさらに、種々の不連続受信(DRX)時間値を含んでもよい。さらに、DRX時間に対する進行プロファイルを、遷移プロファイルの中で提供することができる。
【0284】
遷移プロファイルは、アプリケーションごとに定義することができるか、または、ユーザ機器上の種々のアプリケーションの複合物となり得る。
【0285】
当業者によって理解されるように、遷移プロファイルは、無線リソースが割り当てられると動的に作成または修正することができ、加入、PS登録、PDP有効化、RABまたはRB有効化の状態で終了するか、またはPDPあるいはRAB/RBについてオンザフライで変更することができる。遷移プロファイルはまた、ステップ1810の指示の一部にもなり得る。この場合、ネットワークは、好ましいRRC状態指示を考慮して、遷移を可能にするかどうか、およびどの状態/モードにするかを判定してもよい。修正は、とりわけ、利用可能なネットワークリソース、トラフィックパターンに基づいて生じることができる。
【0286】
したがって、無線リソースプロファイルは、静的および/または動的フィールドから成る。特定のネットワークによって使用される無線リソースプロファイルは、他のネットワークと異なってもよく、上記の説明は、本方法およびシステムを限定するように意図されていない。具体的には、無線リソースプロファイルは、上記で説明される種々の要素を含み、かつ除外することができる。例えば、場合によっては、無線リソースプロファイルは、単に、特定の無線リソースのサービスの質を含み、他の情報を含まない。他の場合においては、無線リソースプロファイルは、遷移プロファイルのみを含む。依然として他の場合においては、無線リソースプロファイルは、とりわけ、サービスの質、APN、PDPコンテキスト、遷移プロファイルの全てを含む。
【0287】
随意で、無線リソースプロファイルに加えて、ネットワーク要素はまた、不必要な遷移を回避するために防護対策を利用することもできる。そのような防護対策は、所定期間に受信される指示の数、受信される指示の総数、トラフィックパターン、および履歴データを含むことができるが、それらに限定されない。
【0288】
所定期間に受信される指示の数は、遷移が発生するべきではないことをネットワークに示すことができる。したがって、ユーザ機器が、例えば、30秒の期間内に5つの指示を送信した場合、ネットワークは、指示を無視し、遷移を行うべきではないと考慮してもよい。代替として、ネットワークは、無期限に、または、ある構成された期間あるいは所定の期間にわたって、さらなる指示を送信すべきではないことをUEに示すことを判定してもよい。これは、UE上のいずれの「時間窓あたりの阻止期間および/または最大指示/要求メッセージ」とも無関係となり得る。
【0289】
さらに、UEは、構成された期間、所定の期間、交渉された期間にわたって、さらなる指示を送信しないように構成することができる。UE構成は、上記で説明されるネットワーク側の防護対策を除くことができる。
【0290】
トラフィックパターンおよび履歴データは、遷移が発生すべきではないという指示をネットワークに提供することができる。例えば、ユーザが過去に月曜から金曜の午前8:30から8:35の間に有意量のデータを受信していた場合、指示が木曜の午前8:32に受信されると、さらなるデータが午前8:35よりも前にあり得るため、ネットワークは、ユーザ機器を遷移するべきではないと決定してもよい。
【0291】
複数の無線リソースがユーザ機器について割り当てられる場合、ネットワークは、ユーザ機器に対する完全無線リソースプロファイルを考慮する必要があってもよい。この場合、ユーザ機器に対する無線リソースプロファイルを検査することができ、複合遷移決定を行うことができる。1つまたは複数の無線リソースの無線リソースプロファイルに基づいて、ネットワークは、遷移が行われるべきか否かを決定することができる。
【0292】
一実施形態では、ネットワークは、ステップ1810で指示を受信したとき、および随意で、ステップ1820で1つまたは複数の無線リソースプロファイルを検査したときに、どのように進むかについて複数の選択肢を有する。
【0293】
第1の選択肢は、何もしないことである。ネットワークは、遷移が保証されないことを決定し、したがって、遷移するユーザ機器指示を受け入れなくてもよい。当業者によって理解されるように、状態が変更されないため、具体的には、遷移が誘起されないため、何もしないことにより、ネットワーク信号伝達を節約する。
【0294】
第2の選択肢は、デバイスの状態を変化させることである。例えば、UMTSネットワークでは、デバイスの状態は、Cell_DCHからCell_PCHに変化してもよい。非UMTSネットワークでは、状態遷移は、接続状態の間で発生してもよい。当業者によって理解されるように、状態を変化させることにより、アイドルモードへの遷移と比較すると、コアネットワーク信号伝達の量が低減する。Cell_PCH状態が専用チャネルを必要としないため、状態を変化させることにより、無線リソースを節約することもできる。また、Cell_PCHは、あまりバッテリ集約的ではない状態であり、UEがバッテリ電力を保存することを可能にする。
【0295】
ネットワークの第3の選択肢は、UEを同じ状態で保つが、特定のAPNまたはPDPコンテキストと関連付けられた無線リソースを解放することである。接続がその現在の状態で維持され、再確立されることを必要としないため、このアプローチは、無線リソースおよび信号伝達を節約する。しかしながら、UEバッテリ寿命が懸念である状態にとっては、あまり好適ではない場合がある。
【0296】
ネットワークの第4の選択肢は、UEをアイドルモードに遷移させることである。特に、UMTSおよび非UMTSの両方では、ネットワークは、接続モードからアイドルモードになってもよい。理解されるように、全く接続が維持されないため、これは無線リソースを節約する。それはさらに、ユーザ機器上のバッテリ寿命を節約する。しかしながら、接続を再確立するために、より大量のコアネットワーク信号伝達が必要とされる。
【0297】
ネットワークの第5の選択肢は、データ転送速度割当を変更することであり、それは、無線リソースを節約し、典型的には、より多くのユーザがネットワークを利用できるようにする。
【0298】
他の選択肢が、当業者にとって明白となるであろう。
【0299】
5つ以上の選択肢のうちのどれを利用するかについてのネットワークの決定は、ネットワークによって異なる。いくつかの過負荷ネットワークは、無線リソースを保存することを好んでもよく、したがって、上記の第3、第4、または第5の選択肢を選択してもよい。他のネットワークは、信号伝達を最小限化することを好み、したがって、上記の第1または第2の選択肢を選択してもよい。
【0300】
決定は図18のステップ1830で示され、ユーザ機器に対する無線リソースプロファイルとともに、ネットワーク選好に基づいてもよい。決定は、ユーザ機器が、別の状態、例えば、あまりバッテリ集約的ではない状態に遷移したいという、ユーザ機器からの指示を受信する、ネットワークによって誘起される。
【0301】
ここで、図19を参照する。図19は、上記の図18に示された決定を行うように適合される、簡略化したネットワーク要素を図示する。ネットワーク要素1910は、ユーザ機器と通信するように適合される、通信サブシステム1920を含む。当業者によって理解されるように、通信サブシステム1920は、ユーザ機器と直接通信する必要がなく、ユーザ機器を往復する通信のための通信経路の一部となり得る。
【0302】
ネットワーク要素1910はさらに、プロセッサ1930および記憶部1940を含むことができる。記憶部1940は、ネットワーク要素1910によってサービス提供されている各ユーザ機器に対する、事前構成された、または静的な無線リソースプロファイルを記憶するように構成される。プロセッサ1930は、通信サブシステム1920による指示の受信時に、ユーザ機器に対する無線リソースプロファイルを考慮するように、およびユーザ機器の遷移に関するネットワークアクションを決定するように適合される。当業者によって理解されるように、通信サブシステム1920によって受信される指示はさらに、ユーザ機器に対する無線リソースプロファイルの一部分または全てを含むことができ、それは次いで、任意の遷移に関するネットワーク決定を行うために、プロセッサ1930によって利用される。
【0303】
したがって、上記に基づいて、ネットワーク要素は、遷移が順序正しいかもしれない(例えば、データ交換が完了したとき、および/またはUEにおいてさらなるデータが見込まれない等)という、ユーザ機器からの指示を受信する。この指示に基づいて、ネットワーク要素は、随意で、静的および動的プロファイル要素の両方を含むことができる、ユーザ機器の無線リソースプロファイルをチェックする。ネットワーク要素はさらに、不必要な遷移が発生していないことを確実にするように、防護対策をチェックしてもよい。次いで、ネットワーク要素は、何もしないこと、または異なるモードあるいは状態に遷移すること、または無線リソースを解除することを決定することができる。理解されるように、これは、ネットワークに、その無線リソースのさらなる制御を提供し、単なるユーザ機器選好よりもむしろネットワーク選好に基づいて、ネットワークが遷移決定を構成することを可能にする。さらに、場合によっては、ネットワークは、遷移するかどうかに関して、デバイスよりも多くの情報を有する。例えば、ユーザ機器には、アップストリーム通信の知識があり、これに基づいて、接続が解除されてもよいことを決定してもよい。しかしながら、ネットワークは、ユーザ機器に対するダウンストリーム通信を受信しており、したがって、接続を解除できないことを自覚している場合がある。この場合、近い将来に、いずれのデータもユーザ機器について受信されないという、さらなる確信を持って、ネットワークを提供するために、遅延タイマを使用して遅延を導入することもできる。
【0304】
本明細書で説明される実施形態は、本開示の技法の要素に対応する要素を有する、構造、システム、または方法の実施例である。この書面による説明は、当業者が、同様に本開示の技法の要素に対応する代替要素を有する実施形態を作製および使用することを可能にしてもよい。したがって、本開示の技法の対象とする範囲は、本明細書で説明されるような本開示の技法と異ならない、他の構造、システム、または方法を含み、さらに、本明細書で説明されるような本開示の技法とごくわずかに異なる、他の構造、システム、または方法を含む。
【技術分野】
【0001】
本開示は、ユーザ機器(UE)または他のワイヤレスあるいはモバイルデバイスと、ワイヤレスネットワークとの間の無線リソース制御に関し、具体的には、例えば、Universal Mobile Telecommunication System(UMTS)ネットワーク等の、ワイヤレスネットワークにおいて、動作の状態およびモードの間で遷移するステップに関する。
【背景技術】
【0002】
Universal Mobile Telecommunication System(UMTS)は、テキスト、デジタル化音声、ビデオ、およびマルチメディアの伝送用の広帯域でパケットベースのシステムである。それは、第3世代の基準に高度に同意しており、概して、広帯域符号分割多重アクセス(W−CDMA)に基づく。
【0003】
UMTSネットワークでは、プロトコルスタックの無線リソース制御(RRC)部が、UEとUTRANとの間の無線リソースの割当、構成、および解放に関与している。このRRCプロトコルは、3GPP TS 25.331仕様書で詳細に説明されている。UEがとり得る2つの基本モードは、「アイドルモード」および「UTRA RRC接続モード」(または単に、本明細書で使用されるような「接続モード」)として定義される。UTRAは、UMTS地上波無線アクセスを表す。アイドルモードでは、UEまたは他のモバイルデバイスは、任意のユーザデータを送信したいときはいつでも、または、UTRANあるいはサービング汎用パケット無線サービス(GPRS)サポートノード(SGSN)ページといった、ページに応じて、プッシュサーバ等の外部データネットワークからデータを受信したいときはいつでも、RRC接続を要求する必要がある。アイドルモードおよび接続モードの動作は、第3世代パートナーシッププロジェクト(3GPP)仕様書TS 25.304およびTS 25.331で詳細に説明されている。
【0004】
UTRA RRC接続モードであるときに、デバイスは、4つの状態のうちの1つとなり得る。これらは、以下の通りである。
CELL_DCH:データを交換するように、この状態ではアップリンクおよびダウンリンクで専用チャネルがUEに割り当てられる。UEは、3GPP 25.331で概説されるようなアクションを行わなければならない。
CELL_FACH:この状態では、いずれの専用チャネルもユーザ機器に割り当てられない。その代わり、少量の集中的データを交換するために共通チャネルが使用される。UEは、3GPP TS 25.304で定義されるようなセル選択過程を含む、3GPP
25.331で概説されるようなアクションを行わなければならない。
CELL_PCH:UEは、ページングインジケータチャネル(PICH)を介して同報通信メッセージおよびページを監視するために、不連続受信(DRX)を使用する。いずれのアップリンク活動も可能ではない。UEは、3GPP TS 25.304で定義されるようなセル選択過程を含む、3GPP 25.331で概説されるようなアクションを行わなければならない。UEは、セル再選択後に、セル更新手順を行わなければならない。
URA_PCH:UEは、ページングインジケータチャネル(PICH)を介して同報通信メッセージおよびページを監視するために、不連続受信(DRX)を使用する。いずれのアップリンク活動も可能ではない。UEは、3GPP TS 25.304で定義されるようなセル選択過程を含む、3GPP 25.331で概説されるようなアクションを行わなければならない。この状態は、URA更新手順がUTRAN登録エリア(URA)の再選択を介してのみ誘起されることを除いて、CELL_PCHと同様である。
【0005】
アイドルモードから接続モードへの遷移、およびその逆は、UTRANによって制御される。アイドルモードUEがRRC接続を要求すると、ネットワークは、UEをCELL_DCHまたはCELL_FACH状態にするかどうかを決定する。UEがRRC接続モードであるときは、この場合もやはり、RRC接続を解放するときを決定するのはネットワークである。ネットワークはまた、接続を解放する前に、または場合によっては接続を解放する代わりに、UEを1つのRRC状態から別のRRC状態にしてもよい。状態遷移は、典型的には、UEとネットワークとの間のデータ活動または非活動によって誘起される。ネットワークは、UEが所与のアプリケーションのためのデータ交換を完了したときを知らない場合があるため、典型的には、UEを往復するさらなるデータを見込んで、しばらくの間RCC接続を保つ。これは、典型的には、呼設定および後続の無線リソース設定の待ち時間を削減するように行われる。RRC接続解放メッセージは、UTRANのみによって送信することができる。このメッセージは、UEとUTRANとの間の信号リンク接続および全ての無線リソースを解放する。概して、「無線ベアラ」という用語は、UEとUTRANとの間で割り当てられる無線リソースを指す。そして、「無線アクセスベアラ」とは、概して、UEと、例えばSGSN(サービングGPRSサービスノード)との間で割り当てられる無線リソースを指す。本開示は、時折、無線リソースという用語を指すものであり、そのような用語は、必要に応じて、無線ベアラおよび/または無線アクセスベアラのいずれか一方または両方を指すものである。
【0006】
上記に関連する問題は、たとえUE上のアプリケーションがデータトランザクションを完了し、さらなるデータ交換を予期していなくても、依然としてネットワークがそれを正しい状態にすることを待つという点である。ネットワークは、UE上のアプリケーションがそのデータ交換を完了したという事実を認識していない場合さえある。例えば、UE上のアプリケーションは、UMTSコアネットワークを通してアクセスされる、そのアプリケーションサーバとデータを交換するために、独自の確認に基づくプロトコルを使用してもよい。例は、独自の保証された配信を実施する、ユーザデータグラムプロトコル/インターネットプロトコル(UDP/IP)上で作動するアプリケーションである。そのような場合、UEは、アプリケーションサーバが全てのデータパケットを送信または受信したか否かが分かり、さらなるデータ交換が行われるかどうかを判定し、したがって、パケットサービス(PS)ドメインと関連付けられたRRC接続を終結させるときを決定するのにより良好な立場にある。UTRANは、RRC接続状態が異なる状態またはアイドルモードに変更されるときを制御し、かつUTRANは、UEと外部サーバとの間のデータ配信の状態を認識していないため、UEは、必要とされるよりも早いデータ転送速度またはモードでありつづけることを余儀なくされる場合があり、移動局の減少したバッテリ寿命をもたらす可能性があり、また、無線リソースが不必要に占有されたままであり、したがって別のユーザに利用可能ではないという事実により、無駄なネットワークリソースをもたらす可能性もある。
【0007】
上記の1つの解決法は、UEがデータトランザクションを終了したことを自覚すると、UEにUTRANへ信号伝達解放指示を送信させることである。3GPP TS 25.331仕様書の第8.1.14.3項に準じて、UTRANは、UEからの信号伝達解放指示の受信時に、信号伝達接続を解放して、UEをアイドルモードまたは何らかの他のRRC状態に遷移させてもよい。上記の解決法に関連する問題は、UTRANにUEまたは他のUEからの信号伝達解放指示メッセージが殺到するかもしれないという点である。
【発明の概要】
【課題を解決するための手段】
【0008】
以下で提供される実施例および実施形態は、例えば、UMTSネットワーク等のワイヤレスネットワークにおいて、動作の種々の状態/モードの間で、ユーザ機器(UE)または他のモバイルデバイスを遷移させるための種々の方法およびシステムを説明する。他の種類のネットワークにおける他の実装も可能であることを理解されたい。例えば、同教示は、符号分割多重アクセス(CDMA)ネットワーク(例えば、3GPP2 IS−2000)、広帯域CDMA(W−CDMA)ネットワーク(例えば、3GPP UMTS /高速パケットアクセス(HSPA)、進化型UTRANネットワーク(例えば、LTE)に適用することもでき、または、一般的に言えば、ネットワーク制御された無線リソースを使用する無線アクセス技術に基づくか、あるいはデバイスアプリケーションレベルデータ交換の状態の知識を維持しない、任意のネットワークに適用することもできる。以下で説明されるが、UMTSネットワークとの関連で簡単にするために提示される、具体的実施例および実装は、これらの他のネットワーク環境にも適用可能である。さらに、ネットワーク要素は、UTRANとして以下で説明されることもある。しかしながら、UMTSの他に他のネットワーク型が利用される場合、ネットワーク型に基づいて、ネットワーク要素を適切に選択することができる。さらに、ネットワーク要素は、UMTSシステムまたは任意の他の適切なネットワークシステム内のコアネットワークとなり得て、その場合、ネットワーク要素は、遷移決定を行うエンティティである。
【0009】
特定の実施例では、本システムおよび方法は、ネットワークにおける意思決定能力を提供しながら、RRC接続モードから、よりバッテリ効率の良い、または無線リソース効率の良い状態あるいはモードへの遷移を提供する。具体的には、本方法および装置は、暗示的または明示的に、無線リソースとの特定の信号伝達接続と関連付けられた、RCC状態またはモードの別の状態またはモードへの遷移が発生するべきであると示す、UEからの指示の受信に基づいて、遷移を提供する。理解されるように、そのような遷移指示または要求は、現在の基準下での既存の通信、例えば、信号伝達接続解放指示メッセージを利用することができ、または、「好ましいRRC状態要求」あるいは「データ転送完了指示メッセージ」等の、UEの状態を変更する新規の専用メッセージとなり得る。データ転送完了指示メッセージは、上位層データ転送の完了を示すメッセージである。本明細書で使用されるように、指示は、いずれのシナリオも指すことができ、かつ要求を組み込むことができる。
【0010】
UEによって発信される遷移指示は、UE上の1つ以上のアプリケーションがデータの交換を完了したとき、および/または、UEがさらなるデータを交換すると見込まれないという判定が行われたときの、いくつかの状況で送信することができる。次いで、ネットワーク要素は、モバイルデバイスを別のモードまたは状態に遷移させるか、何もしないかについて、ネットワーク特有の決定を行うために、指示およびその中で提供される任意の情報、ならびに、とりわけ、サービスの質、アクセスポイント名(APN)、パケットデータプロトコル(PDP)コンテキスト、履歴情報等の、本明細書で無線リソースプロファイルとして定義される、無線リソースに関係する他の情報を使用することができる。UEまたはモバイルデバイスによって提供される遷移指示は、いくつかの形態を取ることができ、かつ異なる条件下で送信することができる。第1の実施例では、遷移指示は、UE上に常駐するアプリケーションの全ての複合状態に基づいて送信することができる。具体的には、UMTS環境では、UE上のアプリケーションがデータの交換を終了したと判定した場合、「終了」指示をUEソフトウェアの「接続マネージャ」コンポーネントに送信することができる。接続マネージャは、一実施形態では、全ての既存アプリケーション(1つまたは複数のプロトコル上でサービスを提供するものを含む)、関連パケットデータプロトコル(PDP)コンテキスト、関連パケット交換(PS)無線リソース、および関連回線交換(CS)無線リソースを追跡することができる。PDPコンテキストは、UMTSコアネットワークにわたって作動する、UEとPDN(公衆データネットワーク)との間の論理的関連付けである。UE上の1つまたは複数のアプリケーション(例えば、Eメールアプリケーションおよびブラウザアプリケーション)は、1つのPDPコンテキストと関連付けられてもよい。場合によっては、UE上の1つのアプリケーションは、1つの1次PDPコンテキストと関連付けられ、複数のアプリケーションは、2次PDPコンテキストと結び付けられてもよい。接続マネージャは、同時にアクティブであるUE上の異なるアプリケーションから、「終了」指示を受信する。例えば、ユーザは、ウェブを閲覧しながらプッシュサーバからEメールを受信してもよい。Eメールアプリケーションは、確認を送信した後に、そのデータトランザクションを完了したことを示してもよい。ブラウザアプリケーションは、異なる行動をし、代わりに、接続マネージャに「終了」指示を送信するときの(例えば、非活動タイマを使用するための)予測判定を行ってもよい。
【0011】
アクティブアプリケーションからのそのような指示の複合状態に基づいて、UEソフトウェアは、遷移指示を送信することを決定して、1つの状態またはモードから別の状態またはモードへの遷移が発生すべきであることをネットワークに指示または要求することができる。代替として、UEソフトウェアは、代わりに、遷移指示を送信する前に待って遅延を導入し、アプリケーションが本当にデータ交換を終了し、バッテリまたは無線リソース集中状態またはモードで維持される必要がないことを確実にすることができる。遅延は、トラフィック履歴および/またはアプリケーションプロファイルに基づいて動的となり得る。ある確率で、アプリケーションがデータを交換することが見込まれると接続マネージャが判定するときはいつでも、ネットワークに遷移指示を送信して、遷移が発生すべきであると示すことができる。具体的実施例では、遷移指示は、アイドルモードへの遷移を要求する、適切なドメイン(例えば、PSドメイン)のための信号伝達接続解放指示となり得る。代替として、遷移指示は、UTRANへの接続モード内の状態遷移の要求となり得る。
【0012】
以下でさらに詳細に説明されるように、遷移指示、および随意で、無線リソースプロファイルの受信に基づいて、UMTS環境内のUTRAN等のネットワーク要素は、1つの状態またはモードから別の状態またはモードにUEを遷移させることを決定することができる。
【0013】
他の遷移指示が可能である。例えば、UE上の全てのアクティブアプリケーションの複合状態に依存する代わりに、UEソフトウェアは、代替実施形態で、UEアプリケーションがデータの交換を完了するたびに、および/またはアプリケーションがさらなるデータを交換すると見込まれないたびに、遷移指示を送信することができる。この場合、ネットワーク要素(例えば、UTRAN)は、以下の図18を参照して説明されるような、UEのオプションの無線リソースプロファイルに基づいて、遷移決定を行うために指示を利用することができる。
【0014】
さらに別の実施例では、遷移指示は、単に、UE上の1つ以上のアプリケーションがデータ交換を完了した、および/または、UEアプリケーションがさらなるデータを交換すると見込まれないと示すことができる。その指示およびUEのオプションの無線リソースプロファイルに基づいて、ネットワーク(例えば、UTRAN)は、より適切な状態またはモードまたは動作にUEを遷移させるかどうかを決定することができる。
【0015】
さらなる実施例では、遷移指示は、明示的よりもむしろ暗示的となり得る。例えば、指示は、周期的に送信される状態報告の一部であってもよい。そのような状態報告は、無線リンクバッファがデータを有するかどうか等の情報をふくむことができ、またはアウトバウンドトラフィック上に情報を含むことができる。
【0016】
UEは、遷移指示を送信するときに、指示に対する行動を決定するのにネットワーク要素を支援するために、追加情報を含んでもよい。この追加情報は、UEがメッセージを送信する理由または原因を含む。この原因または理由(以下でさらに詳細に説明される)は、「急速休眠」のような動作の必要性を判定するUEに基づく。そのような追加情報は、新規の情報要素、または遷移指示メッセージ内の新規パラメータを介したものであってもよい。
【0017】
さらなる実施形態では、以前の遷移指示が送信されてから、ある期間が経過するまで(阻止期間)遷移指示が送信されなくてもよいことを確実にするように、UE上にタイマが存在することができる。この阻止タイマは、UEが遷移指示メッセージを過剰に頻繁に送信することを制限し、さらに、所与の最大頻度のみで誘起されるメッセージに依存することによって、ネットワークが判定を行うことを可能にする。期間は、その値が事前構成されるか、またはネットワークによって設定される(指示または信号伝達される)タイマによって、判定することができる。値がネットワークによって設定される場合、それは、とりわけ、RRC接続要求、RRC接続解放、無線ベアラ設定、UTRANモビリティ情報、またはシステム情報ブロック等の、新規または既存のメッセージの中で伝えることができ、かつこれらのメッセージの中の情報要素となり得る。値は、代替として、例えば、UEから受信されたRRC接続要求メッセージに応じてUTRANによって送信される、RRC接続設定メッセージの遷移阻止指示部分の中で伝えることができる。
【0018】
代替実施形態では、その種類がUEの状態に依存するメッセージの中で、値をUEに伝えることができる。例えば、ネットワークは、IDLE、URA_PCH、Cell_PCH、またはCELL_FACH状態であるときにUEによって読み取られるシステム情報メッセージの一部分として、全てのUEに値を送信することができる。
【0019】
さらに別の実施形態では、RRC接続設定メッセージの一部分として値を送信することができる。
【0020】
ネットワーク生成されたメッセージはまた、メッセージの中、またはメッセージ内の情報要素の中に阻止タイマを含まないことにより、暗示阻止タイマ値を伝えてもよい。例えば、阻止タイマが受信メッセージから省略されていることを判定すると、UEは、阻止タイマ値として使用するために所定の値を適用する。阻止タイマ値の省略の1つの例示的な使用は、UEが遷移指示メッセージを送信することを禁止するものである。そのような状況では、UEが受信メッセージの中の予期された阻止タイマ値の省略を検出すると、UEは、省略に基づいて、あらゆる遷移指示メッセージを送信することが禁止されてもよい。このことを達成するための1つの方法は、UEが無限の阻止タイマ値を採択することである。
【0021】
別の実施形態では、UEは、阻止タイマ値の省略を検出すると(かつ、例えば、無限の阻止タイマ値を採択すると)、いずれの追加情報も含まずに遷移指示を送信してもよく、具体的には、遷移指示の送信を誘起するための原因を省略してもよい(以下でさらに詳細に説明される)。遷移指示メッセージの中の原因要素の省略は、UEが遷移を要求または指示するために既存の遷移指示メッセージ(例えば、信号伝達接続解放指示)を使用できるようにすることによって、後方互換性を確保してもよい。
【0022】
受信メッセージに阻止タイマを含まないことは、システム情報ブロックがセルの中で同報通信されるか、またはUEに送信され、かつシステム情報ブロックが阻止タイマ値を伝えるように構成される、例示的実施形態を参照して、さらに詳述される。この実施形態では、UEが、メッセージまたはメッセージ内の情報要素にT3xxとして知られる阻止タイマを含有しない、システム情報ブロックを受信する場合、UEは、例えば、阻止タイマT3xxを無限に設定することによって、UEが遷移指示メッセージを送信できなくなることを判定してもよい。
【0023】
阻止タイマを含まないことは、阻止タイマT3xxがUTRANモビリティ情報メッセージから省略される、別の例示的実施形態を参照して、さらに詳述される。そのような状況では、受信UEは、以前に記憶された阻止タイマ値を引き続き適用してもよい。代替として、UEは、阻止タイマT3xxの省略を検出すると、例えば、阻止タイマT3xxを無限に設定することによって、UEが遷移指示メッセージを送信できなくなることを判定してもよい。
【0024】
さらに別の例示的実施形態では、UEは、受信メッセージの中またはメッセージ内の情報要素の中の阻止タイマの省略を検出すると、阻止タイマ値を別の事前設定値(例えば、0秒、5秒、10秒、15秒、20秒、30秒、1分、1分30秒、2分のうちの1つ)に設定する。代替として、または加えて、これらの実施例は、他のネットワーク生成されたメッセージを適用してもよい。
【0025】
他の実施形態では、阻止タイマ(値)がメッセージまたは情報要素の中でUEに送信または信号伝達されなかった場合、または、1つのセルから別のセルへ遷移する際に、阻止タイマが同報通信システム情報から読み取られないか、または他の専用UTRANメッセージから受信されなかった場合、遷移指示の送信は、発生してもしなくてもよい。
【0026】
具体的には、一実施形態で、UEは、いずれの阻止タイマも存在しないことを検出すると、伝送するPSがもうないことを判定する上位層に基づいて、遷移指示を開始しない。
【0027】
代替実施形態では、UEは、いずれの阻止タイマも存在しないことを検出すると、伝送するPSがもうないことを判定する上位層に基づいて、遷移指示を開始しなくてもよい。
【0028】
さらに別の実施形態では、(同報通信または他の方法を介して)いずれのタイマ値も、メッセージ内またはメッセージの中の情報要素内で、UTRANから受信されなかった場合、UEにおいてタイマ値を無限に設定するよりむしろ、UEは、阻止タイマをゼロに設定するか、または代替として、タイマの任意の構成を削除し、代わりに、遷移指示を送信することを許容されてもよい。この場合、UEは、遷移指示メッセージの中の原因を省略するか、または原因を添付することを禁止され得る。一実施形態では、信号伝達接続解放指示メッセージは、遷移指示の一例として使用される。
【0029】
一実施形態では、遷移指示は、信号伝達接続解放指示手順を使用して伝えられる。信号伝達接続解放指示手順は、その信号伝達接続のうちの1つが解放されたことを示すために、UEによって使用される。
【0030】
具体的には、TS 25.331の第8.1.14.2項に従って、UEは、特定のCNドメインに対する上層から信号伝達接続を解放する要求を受信すると、情報要素「CNドメインアイデンティティ」において識別される特定のCNドメインに対する変数「ESTABLISHED_SIGNALLING_CONNECTIONS」における信号伝達接続が存在するかどうかをチェックする。存在すれば、UEは、信号伝達接続解放指示手順を開始してもよい。
【0031】
阻止タイマ値が信号伝達されないか、あるいはUEに伝えられない場合、いずれの信号伝達接続解放指示原因も信号伝達接続解放指示メッセージの中で特定されない。当業者であれば、この代替実施形態で、タイマ値の欠如は、タイマ値を無限に設定させないことを理解するであろう。
【0032】
UTRAN側で、原因を伴わない信号伝達接続解放指示メッセージの受信時に、UTRANは、上層に、識別されたCNドメインアイデンティティに対する信号伝達接続の解放を指示する。次いで、これは、確立された無線リソース制御接続の解放を開始してもよい。
【0033】
別の代替実施形態の下で、UTRANが、UEに、タイマ値、例えば、情報要素「接続モードのUEタイマまたは制約」の中で(または、SIB1、SIB3、またはSIB4等のシステム情報を使用して、あるいは専用UTRANモビリティ情報メッセージにより)阻止タイマT3xxを信号伝達するか、または伝えると、以下に従って解放手順が発生する。第1に、UEは、示された回線交換ドメイン接続があるかどうかをチェックすることができる。そのような接続は、変数「ESTABLISHED_SIGNALLING_CONNECTIONS」において示されてもよい。いずれの回線交換ドメイン接続もない場合、長期間にわたってパケット交換ドメインデータが生じないことを上層が示すかどうかを判定する、第2のチェックが発生することができる。
【0034】
いずれの回線交換ドメイン接続もなく、かついずれのパケット交換ドメインデータも長期間にわたって予期されない場合、UEは、次に、タイマT3xxが作動しているかどうかをチェックしてもよい。
【0035】
タイマT3xxが作動していない場合、UEは、情報要素「CNドメインアイデンティティ」をパケット交換(PS)ドメインに設定する。さらに、情報要素「信号伝達接続解放指示原因」は、「UEがPSデータセッションの終了を要求した」に設定される。信号伝達接続解放指示メッセージは、AM RLCを使用して、DCCH上で伝送される。さらに、伝送後に、タイマT3xxが起動される。
【0036】
上記の手順は、上記の手順でRLCによって確認されるような、信号伝達接続解放指示メッセージの配信成功時に終了する。この実施形態では、タイマT3xxが作動している間に、またはタイマT3xxが期限切れになるまで、UEは、「UEがPSデータセッションの終了を要求した」に設定された信号伝達接続解放指示原因とともに、信号伝達接続解放指示メッセージを送信することが阻止される。
【0037】
T3xxタイマが作動しているときに、長期間にわたって、さらなるパケット交換ドメインデータがないため、信号伝達接続解放指示手順が開始される場合、UEは、T3xxタイマの満了に対して手順を開始するかどうかを実施することに関与している。UE決定は、送信する後続の信号伝達接続解放指示または要求メッセージがあるかどうかの判定に基づいてもよく、もしあれば、UE決定は、本明細書で概説されるような手順を開始するために同じチェックのうちのいくつかまたは全てを再チェックするステップを含んでもよい。
【0038】
UTRAN側で、信号伝達接続解放指示メッセージが信号伝達接続解放指示原因を含まない場合、UTRANは、上層からの信号伝達接続の解放を要求してもよく、次いで、上層は、信号伝達接続の解放を開始してもよい。一方で、受信される信号伝達接続解放指示メッセージが原因を含む場合、UTRANは、信号伝達接続を解放するか、または、よりバッテリ効率の良い状態(例えば、CELL_FACH、CELL_PCH、URA_PCH、またはIDLE_モード)への状態遷移を開始してもよい。
【0039】
上記の阻止期間は、UEが遷移したい状態に基づいてもよい。例えば、阻止期間は、携帯電話が、他の状態/モードと対比した、いくつかのRRC状態/モードの最後の選好を示したかどうかにより、異なってもよい。例えば、それは、携帯電話が、Cell_FACH状態と対比した、またはCell_PCH/URA PCH状態と対比した、アイドルモードの選好を示した場合に、異なり得る。阻止期間がネットワークによって設定される場合では、これは、シナリオに応じて使用される、携帯電話に値の2つ(以上の)のセットを指示/送信する、ネットワークによって達成されてもよい。代替として、指示は、適切な阻止期間値のみが携帯電話に指示/信号伝達されるような方法で行うことができる。例えば、UEがCell_PCHに遷移したい場合、UEがアイドルに遷移したい場合とは異なる経過期間を設定することができる。
【0040】
上記からの阻止期間は、携帯電話の現在のRRC状態/モード(例えば、Cell_DCH/Cell_FACH対Cell_PCH/URA_PCH、またはCell_DCH対Cell_FACHあるいはCell_PCH/URA_PCH)に応じて、異なってもよい。
【0041】
上記からの阻止期間は、ネットワークがすでに携帯電話からの選好RRC状態情報に作用したかどうかに応じて、異なってもよい。そのような認識は、ネットワーク上で、または携帯電話側で起こってもよい。第1の場合において、これは、ネットワークによって携帯電話に指示/信号伝達される、阻止値に影響を及ぼしてもよい。第2の場合において、阻止期間値の異なるセットは、事前構成されるか、またはネットワークによって指示/信号伝達されてもよい。特定の場合として、ネットワークが携帯電話からの選好RRC状態情報に作用した、例えば、UEによって示された状態への状態遷移を開始した場合に、阻止期間/機能性が削減されるか、または取り消されてもよい。
【0042】
上記からの阻止期間は、例えば、ネットワークの選好、特徴、能力、負荷、または容量に応じて、異なってもよい。ネットワークは、頻繁な遷移指示メッセージを受信することができる場合に、短い阻止期間を示してもよい。ネットワークは、頻繁な遷移指示メッセージを受信できない、またはしたくない場合に、長い阻止期間を示してもよい。ネットワークは、UEが遷移指示メッセージを送信することができない特定の期間を示してもよい。特定の期間は、例えば、数値的に示されてもよい(すなわち、0秒、30秒、1分、1分30秒、2分、または無限)。0秒の阻止期間を受信するUEは、遅延なしで遷移指示を送信することができる。無限の阻止期間を受信するUEは、遷移指示を送信することができない。
【0043】
阻止期間の代わりに、またはそれに加えて、時間枠あたりのメッセージの最大数(例えば、「10分ごとにわずか15のメッセージ」)が使用/特定されてもよい。
【0044】
上記の阻止期間/時間枠あたりのメッセージの最大数の組み合わせが可能である。
【0045】
一例として、本開示は、概して、UTRANによるUEからのRRC接続要求メッセージの受信を記載する。RRC接続要求メッセージを受信すると、UTRANは、例えば、要求を受け入れ、UEにRRC接続設定メッセージを送信する。RRC接続設定は、タイマT3xxとして知られる遷移阻止指示を含み得る。UEによるRRC接続設定メッセージの受信時に、UEは、例えば、以前に記憶された値を置き換えてタイマT3xxの値を記憶するか、または、タイマT3xxがRRC接続設定メッセージの中にない場合には、タイマの値を無限に設定する。いくつかの実施形態では、RRC接続設定メッセージは、UTRANが遷移阻止指示信号伝達をサポートすることをUEが知っていることを確実にするように、遷移阻止指示を含まなければならない。
【0046】
一実施形態では、DCH状態でのモビリティの間に、UEが阻止タイマに対して、その現在記憶されている値を維持することが仮定される。阻止タイマが無限に設定される、いくつかの場合では、これは、ネットワークデータ非活動タイマが期限切れになること、およびネットワークがUEをRRC状態にすることをUEが待たなければならず、その場合、阻止タイマに対する新規の値を受信または判定できることを意味してもよい。阻止タイマがハンドオーバ前に無限以外のある値である、他の場合では、UEがタイマ値を新規セルで示された値に更新することができるまで、この他の値が引き続き使用される。
【0047】
場合によっては、阻止タイマおよび遷移指示(例えば、信号伝達接続解放指示)メッセージは、いくつかのネットワークの中、またはネットワーク内のいくつかのセルの中で実装されてもよい。モビリティの目的で、遷移指示または要求メッセージを送信する機能にサポートが利用可能ではない場合(特に、原因が使用される場合)、UEは、メッセージを送信しないステップをデフォルトにするべきである。これは、不必要な伝送、および関連するネットワークリソースならびにバッテリリソースの無駄を回避する。
【0048】
加えて、モビリティの目的で、ネットワーク内で使用される異なる業者のネットワーク機器は、UEがセル間を移動するときに、UE上で更新される必要のある異なる阻止タイマを使用して、隣接するセルに至ってもよい。
【0049】
1つの代替実施形態では、これは、全てのハンドオーバおよび関連ベアラ制御メッセージが阻止タイマT3xxの値を含むことを定めることによって、取り扱われる。そのようなメッセージは、本明細書ではモビリティメッセージと呼ばれる。これは、UEがセル間を移動するときに新規の阻止タイマ値を受信できるようにする。それはまた、これらのモビリティメッセージが阻止タイマ値を含有しない場合に、UEが阻止タイマのデフォルトタイマ値を設定できるようにもする。理解されるように、いずれの阻止タイマ値もモビリティメッセージの中で受信されなかった場合、これは、セルが急速休眠に有効ではないことを示す。
【0050】
遷移指示手順の別の実施例として、これ以上PSドメインデータを転送する必要がないと判定したことをUTRANに示すために、データ転送完了指示手順がUEによって使用されてもよい。上記で説明される実施例に関連して、タイマT3xxが作動している場合、UEは、タイマT3xxが期限切れになる前にデータ転送完了指示メッセージを送信しない。
【0051】
データ転送完了指示手順は、RRCまたは上層が長期間にわたってこれ以上PSドメインデータを持たないという指示で開始する。CSドメイン接続が確立された信号伝達接続(ESTABLISHED_SIGNALLING_CONNECTIONS)という変数において
示された場合、またはタイマT3xxが無限に設定された場合に、手順が終了する。そうでなければ、タイマT3xxが作動していない(すなわち、期限切れになった)か、または0秒に設定された場合に、AM RLCまたはDCCHを使用して、データ転送完了指示メッセージが下層に提出され、その後、メッセージが下層に配信されると、タイマT3xxが起動またはリセットされる。
【0052】
UTRANは、データ転送完了指示の受信時に、よりバッテリ効率の良いRRC状態またはアイドルモードへのUE遷移を開始することを決定してもよい。
【0053】
UEは、タイマT3xxが作動している間に、データ転送完了指示メッセージを送信しないものである。
【0054】
本開示は、異なる状態または異なるモードにユーザ機器を遷移させるために遷移指示を送信する方法を提供し、該方法は、ネットワークから構成メッセージを受信することと、該ユーザ機器から遷移指示を伝送することであって、該遷移指示は、該構成メッセージが遷移阻止指示を含む場合には原因のみを含む、こととを包含する。
【0055】
本開示は、また、異なる状態または異なるモードに遷移するために遷移指示を送信するように構成されているユーザ機器を提供し、該ユーザ機器は、ネットワークから構成メッセージを受信することと、該ユーザ機器から遷移指示を送信することであって、該遷移指示は、該構成メッセージが遷移阻止支持を含む場合には原因のみを含む、こととを行うように構成されている。
【0056】
本開示は、さらに、ユーザ機器からの遷移の指示を処理する方法であって、該指示は、該ユーザ機器が異なる状態または異なるモードへの遷移を所望することを指示する、方法を提供し、該方法は、該ユーザ機器から該遷移指示を受信することと、該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することとを包含する。
【0057】
本開示は、さらに、ユーザ機器の状態またはモードを遷移させるように構成されているネットワーク要素を提供し、該ネットワーク要素は、該ユーザ機器から遷移指示を受信することと、該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することとを行うように構成されている。
【0058】
本開示は、図面を参照すると、より良好に理解されるであろう。
例えば、本発明は以下の項目を提供する。
(項目1)
異なる状態または異なるモードにユーザ機器を遷移させるために遷移指示を送信する方法であって、該方法は、
ネットワークから構成メッセージを受信することと、
該ユーザ機器から遷移指示を伝送することであって、該遷移指示は、該構成メッセージが遷移阻止指示を含む場合には原因のみを含む、ことと
を包含する、方法。
(項目2)
上記遷移阻止支持は、阻止タイマ値である、項目1に記載の方法。
(項目3)
上記構成メッセージが阻止タイマ値を含む場合、該受信された阻止タイマ値に従って、タイマを設定することをさらに包含する、項目2に記載の方法。
(項目4)
上記伝送することは、上記タイマが動作していない場合に起こる、項目3に記載の方法。
(項目5)
上記伝送することは、上記タイマが満了した場合に起こる、項目3に記載の方法。
(項目6)
新しいセルまたは新しいネットワークを獲得する際に、上記タイマをリセットすることをさらに包含する、項目3〜項目5のいずれか1項に記載の方法。
(項目7)
上記遷移指示は、信号伝達接続解放指示メッセージである、項目1〜項目6のいずれか1項に記載の方法。
(項目8)
上記遷移指示は、データ転送完了指示メッセージである、項目1〜項目7のいずれか1項に記載の方法。
(項目9)
上記ユーザ機器が新しいネットワークまたは新しいセルを獲得する際に、上記構成メッセージが受信される、項目1〜項目8のいずれか1項に記載の方法。
(項目10)
上記構成メッセージは、RRC接続要求メッセージ、RRC接続設定メッセージ、RRC接続解放メッセージ、無線ベアラ設定メッセージ、システム情報同報通信メッセージ、システム情報ブロック(SIB)メッセージ、アクティブセット更新メッセージ、セル更新確認メッセージ、UTRANコマンドへのハンドオーバメッセージ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、およびUTRANモビリティ情報メッセージから成る群より選択される、項目1〜項目9のいずれか1項に記載の方法。
(項目11)
異なる状態または異なるモードに遷移するために遷移指示を送信するように構成されているユーザ機器であって、該ユーザ機器は、
ネットワークから構成メッセージを受信することと、
該ユーザ機器から遷移指示を送信することであって、該遷移指示は、該構成メッセージが遷移阻止支持を含む場合には原因のみを含む、ことと
を行うように構成されている、ユーザ機器。
(項目12)
上記遷移阻止支持は、阻止タイマ値である、項目11に記載のユーザ機器。
(項目13)
上記構成メッセージが上記阻止タイマ値を含む場合、該受信された阻止タイマ値に従って、タイマを設定するようにさらに構成されている、項目12に記載のユーザ機器。
(項目14)
上記送信することは、上記タイマが動作していない場合に起こる、項目13に記載のユーザ機器。
(項目15)
上記送信することは、上記タイマが満了した場合に起こる、項目13に記載のユーザ機器。
(項目16)
新しいセルまたは新しいネットワークを獲得する際に、上記タイマをリセットすることをさらに包含する、項目13〜項目15のいずれか1項に記載のユーザ機器。
(項目17)
上記遷移指示は、信号伝達接続解放指示メッセージである、項目11〜項目16のいずれか1項に記載のユーザ機器。
(項目18)
上記遷移指示は、データ転送完了指示メッセージである、項目11〜項目17のいずれか1項に記載のユーザ機器。
(項目19)
上記ユーザ機器が新しいセルまたは新しいネットワークを獲得する際に、上記構成メッセージが受信される、項目11〜項目18のいずれか1項に記載のユーザ機器。
(項目20)
上記構成メッセージは、RRC接続要求メッセージ、RRC接続設定メッセージ、RRC接続解放メッセージ、無線ベアラ設定メッセージ、システム情報同報通信メッセージ、システム情報ブロック(SIB)メッセージ、アクティブセット更新メッセージ、セル更新確認メッセージ、UTRANコマンドへのハンドオーバメッセージ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、およびUTRANモビリティ情報メッセージから成る群より選択される、項目11〜項目19のいずれか1項に記載のユーザ機器。
(項目21)
ユーザ機器からの遷移の指示であって、該ユーザ機器が異なる状態または異なるモードへの遷移を所望することを指示する、指示を処理する方法であって、該方法は、
該ユーザ機器から該遷移指示を受信することと、
該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、
該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することと
を包含する、方法。
(項目22)
上記信号伝達接続を解放することは、上記ユーザ機器のための無線リソース制御(RRC)の解放を開始する、項目21に記載の方法。
(項目23)
上記信号伝達接続は、識別されたコアネットワークドメインのためである、項目22に記載の方法。
(項目24)
上記遷移することは、電池効率のより良い状態またはモードになるように行われる、項目21〜項目23のいずれか1項に記載の方法。
(項目25)
ユーザ機器の状態またはモードを遷移させるように構成されているネットワーク要素であって、該ネットワーク要素は、
該ユーザ機器から遷移指示を受信することと、
該遷移指示が原因を含む場合には、該ユーザ機器の信号伝達接続を解放するか、あるいは異なる状態または異なるモードに該ユーザ機器を遷移させることと、
該遷移指示が該原因を含まない場合には、該信号伝達接続を解放することと
を行うように構成されている、ネットワーク要素。
(項目26)
上記信号伝達接続を解放することは、上記ユーザ機器のための無線リソース制御(RRC)の解放を開始する、項目25に記載のネットワーク要素。
(項目27)
上記信号伝達接続は、識別されたコアネットワークドメインのためである、項目26に記載のネットワーク要素。
(項目28)
上記遷移は、電池効率のより良い状態またはモードになるように行われる、項目25〜項目27のいずれか1項に記載のネットワーク要素。
【図面の簡単な説明】
【0059】
【図1】図1は、RRC状態および遷移を示す、ブロック図である。
【図2】図2は、種々のUMTSセルおよびURAを示す、UMTSネットワークの概略図である。
【図3】図3は、RRC接続設定における種々の段階を示す、ブロック図である。
【図4A】図4Aは、現在の方法に従ってUTRANによって開始される、CELL_DCH接続モード状態とアイドルモードとの間の例示的遷移のブロック図である。
【図4B】図4Bは、信号伝達解放指示を利用する、CELL_DCH状態接続モードとアイドルモードとの間の例示的遷移を示す、ブロック図である。
【図5A】図5Aは、UTRANによって開始される、CELL_DCH非活動状態、CELL_FACH非活動状態、アイドルモードへの例示的遷移を示す、ブロック図である。
【図5B】図5Bは、信号伝達解放指示を利用する、CELL_DCH非活動状態とアイドルモードとの間の例示的遷移を示す、ブロック図である。
【図6】図6は、UMTSプロトコルスタックのブロック図である。
【図7】図7は、本方法と関連して使用することができる、例示的UEである。
【図8】図8は、本方法およびシステムと関連して使用するための例示ネットワークである。
【図9】図9は、UEにおいて信号伝達接続解放指示の原因を追加するステップを示す、フロー図である。
【図10】図10は、原因を有する信号伝達接続解放指示の受信時にUEによって取られるステップを示す、フロー図である。
【図11】図11は、複数の同時パケットデータ通信サービスセッションがUEに提供される、図8に示されたネットワークの例示的動作中の例示的な論理および物理チャネル割り当てのグラフ表示である。
【図12】図12は、本開示の実施形態に従って、個々のパケットデータサービスの無線リソースを解放する無線リソース解放機能を提供する、UEおよびネットワーク要素の機能的ブロック図を図示する。
【図13】図13は、それによりPDPコンテキストへの無線リソース割り当てを解放するように、本開示の実施形態の操作に従って生成される信号伝達を表す、メッセージシーケンス図を図示する。
【図14】図14は、それにより無線リソース割り当てを解放するように、本開示の実施形態の操作に従って生成される信号伝達を同様に表す、図13に示された図と同様のメッセージシーケンス図を図示する。
【図15】図15は、本開示の実施形態の過程を表す、過程図を図示する。
【図16】図16は、本開示の実施形態の操作の方法を図示する、方法フロー図を図示する。
【図17】図17は、本開示の実施形態の操作の方法を同様に図示する、方法フロー図を図示する。
【図18】図18は、遷移決定がネットワーク要素において無線リソースプロファイルに基づき行われる、実施形態の方法フロー図を図示する。
【図19】図19は、図18の方法とともに使用されることが可能なネットワーク要素の簡略化したブロック図を図示する。
【図20】図20は、遷移指示または要求メッセージの送信のためのデータフロー図を図示する。
【図21】図21は、UEにおいて阻止タイマ値を設定するためのデータフロー図を図示する。
【発明を実施するための形態】
【0060】
ここで図1を参照する。図1は、UMTSネットワーク内のプロトコルスタックの無線リソース制御部分に対する種々のモードおよび状態を示す、ブロック図である。具体的には、RRCは、RRCアイドルモード110またはRRC接続モード120のいずれかとなり得る。
【0061】
当業者によって理解されるように、UMTSネットワークは、2つ地上ネットワークセグメントから成る。これらは、(図8に図示されるような)コアネットワーク(CN)およびユニバーサル地上波無線アクセスネットワーク(UTRAN)である。コアネットワークが、データ呼び出しの切替およびルーティング、ならびに外部ネットワークへのデータ接続に関与している一方で、UTRANは、全ての無線関連機能を取り扱う。
【0062】
アイドルモード110では、UEは、データがUEとネットワークとの間で交換される必要があるときはいつでも、RRC接続を要求して無線リソースを設定しなければならない。これは、データを送信するように接続に要求するUE上のアプリケーションの結果として、または、UTRANまたはSGSNがプッシュサーバ等の外部データネットワークからデータを受信するようにUEを呼び出したかどうかを示すように、UEがページングチャネルを監視する結果としてのものとなり得る。加えて、UEはまた、ロケーションエリア更新等のモビリティ管理信号伝達メッセージを送信する必要があるときはいつでも、RRC接続を要求する。
【0063】
いったんUEが無線接続を確立するようにUTRANに要求を送信すると、UTRANは、RRC接続がなる状態を選択する。具体的には、RRC接続モード120は、4つの別個の状態を含む。これらは、CELL_DCH状態122、CELL_FACH状態124、CELL_PCH状態126、およびURA_PCH状態128である。
【0064】
アイドルモード110から、UEは自律的にCELL_FACH状態124に遷移し、その場合、その初期データ転送を行い、その後、ネットワークがどのRCC接続状態を継続的なデータ転送に使用するかを判定する。これは、UEをセル専用チャネル(CELL_DCH)状態122にするか、またはUEをセル順方向アクセスチャネル(CELL_FACH)状態124に保つネットワークを含んでもよい。
【0065】
CELL_DCH状態122では、データを交換するアップリンクおよびダウンリンクの両方のために、専用チャネルがUEに割り当てられる。この状態は、専用物理チャネルがUEに割り当てられるため、典型的に、UEから最も多くのバッテリ電力を必要とする。
【0066】
代替として、UTRANは、UEをCELL_FACH状態124で維持することができる。CELL_FACH状態では、いずれのチャネルもUEに割り当てられない。その代わり、少量の集中的データにおける信号伝達を送信するために共通チャネルが使用される。しかしながら、UEは依然としてFACHを継続的に監視しなければならず、したがって、CELL_PCH状態、URA_PCH状態、およびアイドルモードよりも多くのバッテリ電力を消費する。
【0067】
RRC接続モード120内で、RRC状態は、UTRANの判断で変更することができる。具体的には、データ非活動が特定量の時間またはデータに対して検出されるか、または、ある閾値を下回るデータスループットが検出された場合に、UTRANは、RRC状態を、CELL_DCH状態122からCELL_FACH状態124、CELL_PCH状態126、またはURA_PCH状態128にしてもよい。同様に、ペイロードがある閾値を上回ると検出された場合に、RRC状態をCELL_FACH状態124からCELL_DCH状態122にすることができる。
【0068】
CELL_FACH状態124から、データ非活動がいくつかのネットワーク内で所定の時間にわたって検出された場合、UTRANは、RRC状態をCELL_FACH状態124からページングチャネル(PCH)状態にすることができる。これは、CELL_PCH状態126からURA_PCH状態128のいずれか一方となり得る。
【0069】
CELL_PCH状態126またはURA_PCH状態128から、UEは、専用チャネルを要求する更新手順を開始するために、CELL_FACH状態124とならなければならない。これは、UEが制御する唯一の状態遷移である。
【0070】
アイドルモード110、ならびにCELL_PCH状態126およびURA_PCH状態128は、ページングインジケータチャネル(PICH)を介して同報通信メッセージおよびページを監視するために、不連続受信サイクル(DRX)を使用する。いずれのアップリンク活動も可能ではない。
【0071】
CELL_PCH状態126とURA_PCH状態128との間の違いは、UEの現在のUTRAN登録エリア(URA)が、現在のセルに存在するURAアイデンティティのリストの中にない場合に、URA_PCH状態128がURA更新手順しか誘起しないことである。具体的には、図2を参照する。図2は、種々のUMTSセル210、212、および214の説明図を示す。これらのセルの全ては、CELL_PCH状態に再選択された場合に、セル更新手順を必要とする。しかしながら、UTRAN登録エリアにおいて、それぞれが同じUTRAN登録エリア(URA)320内に入り、したがって、URA更新手順は、URA_PCHモードであるときに210、212、および214の間で移動すると誘発されない。
【0072】
図2で見られるように、他のセル218は、URA320の外側にあり、別個のURAの一部となり得るか、またはいずれのURAの一部にもなり得ない。
【0073】
当業者によって認識されるように、バッテリ寿命の観点から、アイドル状態は、上記の状態と比較して最低バッテリ使用量を提供する。具体的には、UEは、間隔を置いてのみ、ページングチャネルを監視する必要があるために、無線は継続的にオンである必要はないが、その代わり、周期的に起動する。これに対するトレードオフは、データを送信する待ち時間である。しかしながら、この待ち時間が長過ぎなければ、アイドルモードであること、およびバッテリ電力を節約することの利点は、接続待ち時間の不利点を上回る。
【0074】
再度、図1を参照する。種々のUMTS基礎構造ベンダは、種々の基準に基づいて、状態122、124、126、および128の間で移動させる。これらの基準は、とりわけ、信号伝達の節約または無線リソースの節約に関するネットワーク操作者の選好となり得る。例示的な基礎構造を以下で概説する。
【0075】
第1の例示的基礎構造では、CELL_FACH状態でアクセスを開始した直後に、RRCは、アイドルモードとCell_DCH状態との間で移動する。Cell_DCH状態では、2秒間の非活動が検出された場合、RRC状態はCell_FACH状態124に変化する。もし、Cell_FACH状態124で、10秒間の非活動が検出された場合は、RRC状態がCell_PCH状態126に変化する。Cell_PCH状態126での45分間の非活動は、RRC状態をアイドルモード110に戻らせる。
【0076】
第2の例示的基礎構造では、RRC遷移は、ペイロード閾値に応じて、アイドルモード110と接続モード120との間で発生することができる。第2の基礎構造では、ペイロードがある閾値を下回る場合に、UTRANはRRC状態をCELL_FACH状態124にする。逆に、データペイロードがあるペイロード閾値を上回る場合に、UTRANはRRC状態をCELL_DCH状態122にする。第2の基礎構造では、2分間の非活動がCELL_DCH状態122で検出されると、UTRANはRRC状態をCELL_FACH状態124にする。CELL_FACH状態124での5分間の非活動後に、UTRANはRRC状態をCELL_PCH状態126にする。CELL_PCH状態126では、アイドルモード110に戻る前に、2時間の非活動が必要とされる。
【0077】
第3の例示的基礎構造では、アイドルモード110と接続モード120との間の移動は、常にCELL_DCH状態122に対するものである。CELL_DCH状態122での5秒間の非活動後に、UTRANはRRC状態をCELL_FACH状態124にする。CELL_FACH状態124での30秒間の非活動は、アイドルモード110に戻る移動をもたらす。
【0078】
第4の例示的基礎構造では、RRCは、アイドルモードから接続モードへと、CELL_DCH状態122に直接遷移する。第4の例示的基礎構造では、CELL_DCH状態122は、2つの構成を含む。第1の構成は、データ転送速度を有する構成を含み、第2の構成は、より低いデータ転送速度を含むが、依然としてCELL_DCH状態内である。第4の例示的基礎構造では、RRCは、アイドルモード110から高データ転送速度のCELL_DCHサブ状態に直接遷移する。10秒間の非活動後に、RRC状態は、低データ天測速度のCELL_DCHサブ状態に遷移する。CELL_DCH状態122の低データサブ状態からの17秒間の非活動は、RRC状態をアイドルモード110に変化させる。
【0079】
上記の4つの例示的基礎構造は、種々のUMTS基礎構造ベンダがどのように状態を実装しているかを示す。当業者によって理解されるように、それぞれの場合において、実データ(Eメール等)を交換するのに費やされる時間は、CELL_DCHまたはCELL_FACH状態でとどまるために必要とされる時間と比較して、有意に短い。これは、不必要なカレントドレインを引き起こし、UMTS等のより新しい世代のネットワークにおけるユーザ体験を、GPRS等の以前の世代のネットワークよりも不良にする。
【0080】
さらに、CELL_PCH状態126が、バッテリ寿命の観点からCELL_FACH状態124よりも最適であるが、CELL_PCH状態126でのDRXサイクルは、典型的に、アイドルモード110よりも低い値に設定される。結果として、UEは、アイドルモード110よりもCELL_PCH状態126で頻繁に起動する必要がある。
【0081】
アイドル状態110のDRXサイクルと同様のDRXサイクルを伴うURA_PCH状態128は、おそらく、バッテリ寿命と接続のための待ち時間との間の最適なトレードアップである。しかしながら、URA_PCH状態128は、現在UTRANでは実装されていない。したがって、場合によっては、バッテリ寿命の観点から、アプリケーションがデータ交換を終了した後にできるだけ早急に、アイドルモードに早急に遷移することが望ましい。
【0082】
ここで図3を参照する。アイドルモードから接続モードに遷移するときに、種々の信号伝達およびデータ接続を行う必要がある。図3を参照すると、行われる最初の事項は、RRC接続設定310である。上記で示されるように、このRRC接続設定310は、UTRANによってしか解除することができない。
【0083】
いったんRRC接続設定310が達成されると、信号伝達接続設定312が開始される。
【0084】
いったん信号伝達接続設定312が終了されると、暗号化および完全性設定314が開始される。これの完了時に、無線ベアラ設定316が達成される。この時点で、UEとUTRANとの間でデータを交換することができる。
【0085】
接続の解除は、一般に逆の順序で、同様に達成される。無線ベアラ設定316が取り払われ、次いで、RRC接続設定310が取り払われる。この時点で、RRCは、図1に図示されるようなアイドルモード110になる。
【0086】
現在の3GPP仕様書は、UEがRRC接続を解放すること、またはRRC状態に対するその選好を示すことを許容しないが、UEは、依然として、パケット交換アプリケーションによって使用されるパケット交換(PS)ドメイン等の特定されたコアネットワークドメインに対する信号伝達接続の終結を示すことができる。3GPP TS 25.331の第8.1.14.1項によれば、その信号伝達接続のうちの1つが解放されたことをUTRANに示すために、信号伝達接続解放指示手順がUEによって使用される。この手順は、順に、RRC接続解放手順を開始してもよい。
【0087】
したがって、現在の3GPP仕様書内にとどまって、信号伝達接続設定312の解除時に信号伝達接続解放が開始されてもよい。それは、信号伝達接続設定312を解除するUEの能力内であり、これは順に、仕様書に従って、RRC接続解放を開始「してもよい」。
【0088】
当業者によって開始されるように、信号伝達接続設定312が解除された場合、UTRANはまた、信号伝達接続設定312が解除された後に、暗号化および完全性設定314、ならびに無線ベアラ設定316を整理する必要もある。
【0089】
信号伝達接続設定312が解除された場合、RRC接続設定は、典型的には、いずれのCS接続もアクティブではない場合に、現在のベンダ基礎構造のために、ネットワークによって停止させられる。
【0090】
上述の具体的な遷移指示例のうちの1つにこれを使用して、UEは、データの交換が終了したことを判定し、例えば、UEソフトウェアの「接続マネージャ」構成要素に、データの交換が完了したという指示が提供された場合、接続マネージャは、信号伝達設定312を解除するか否かを判定してもよい。例えば、デバイス上のEメールアプリケーションは、Eメールがプッシュサーバによって確かに受信されたというプッシュEメールサーバからの確認が受信されたという指示を送信する。接続マネージャは、一実施形態では、全ての既存のアプリケーション、関連PDPコンテキスト、関連PS無線リソース、および関連回線交換(CS)無線ベアラを追跡することができる。他の実施形態では、ネットワーク要素(例えば、UTRAN)が、既存のアプリケーション、関連PDPコンテキスト、QoS、関連PS無線リソース、および関連CS無線ベアラを追跡することができる。アプリケーションが本当にデータ交換を終了し、「終了」指示が送信された後でもRCC接続をもはや必要としないことを確実にするように、UEまたはネットワーク要素のうちのいずれかにおいて遅延を導入することができる。この遅延は、アプリケーションまたはUEと関連付けられた非活動タイムアウトと同等にすることができる。各アプリケーションは、独自の非活動タイムアウトを有することができ、したがって、遅延は、アプリケーションタイムアウトの全ての複合物となり得る。例えば、Eメールアプリケーションは、5秒間の非活動タイムアウトを有することができるが、アクティブブラウザアプリケーションは、60秒間のタイムアウトを有することができる。阻止期間タイマはさらに、遷移指示の送信を遅延させることができる。アクティブアプリケーションからの全てのそのような指示の複合状態、ならびにいくつかの実施形態での無線リソースプロファイルおよび/または阻止期間タイマ遅延に基づいて、UEソフトウェアは、適切なコアネットワーク(例えば、PSドメイン)に対する(例えば、信号伝達接続解放指示または状態変更要求のための)遷移指示を送信する前に、どれだけ待つべきか、または待たなければならないかを決定する。ネットワーク要素において遅延が実施された場合、要素は、UEに遷移するかどうか、およびどのようにUEに遷移するかの判定を行うが、遅延がその経過をたどった後にしか遷移を操作しない。
【0091】
非活動タイムアウトは、トラフィックパターン履歴および/またはアプリケーションプロファイルに基づいて動的にすることができる。
【0092】
ネットワーク要素がUEをアイドルモード110に遷移する場合、それは図1に図示されるようなRRC接続モード120の任意の段階で起こり得るが、ネットワーク要素は、RRC接続を解放し、UEを図1に図示されるようなアイドルモード110にする。これはまた、UEが音声電話中にあらゆるパケットデータサービスを行っているときにも適用可能である。この場合、ネットワークは、PSドメイン信号伝達接続のみを解放することを選択し、CSドメイン信号伝達接続を維持してもよく、または代替として、何も解放しないことを選択し、代わりに、PSおよびCSドメインの両方への信号伝達接続を維持してもよい。
【0093】
さらなる実施形態では、指示の理由をUTRANに示す遷移指示に、原因を追加することができる。好ましい実施形態では、原因は、異常な状態が指示を引き起こしたと言う指示、または要求された遷移の結果として指示がUEによって開始されたという指示となり得る。他の正常な(すなわち、異常ではない)トランザクションもまた、遷移指示の送信をもたらすことができる。
【0094】
さらなる好ましい実施形態では、種々のタイムアウトが、異常な状態に対して遷移指示を送信させることができる。以下のタイマの実施例は包括的ではなく、他のタイマまたは異常な状態が可能である。3GPP TS 24.008の10.2.47は、タイマT3310を以下のように特定する。
【0095】
【表1】
このタイマは、添付失敗を示すために使用される。添付の失敗は、ネットワークの結果となり得るか、または衝突あるいは不良な無線周波数(RF)等のRFの問題となり得る。
【0096】
添付試行は、複数回発生することができ、添付失敗は、所定数の失敗または明示的拒絶のいずれか一方に起因する。
【0097】
3GPPの10.2.47の第2のタイマは、以下のように特定されるタイマT3330である。
【0098】
【表2】
このタイマは、ルーティングエリア更新失敗を示すために使用される。タイマの満了時に、さらなるルーティングアリア更新を複数回要求することができ、ルーティングエリア更新失敗は、所定数の失敗または明示的拒絶のいずれか一方に起因する。
【0099】
3GPPの10.2.47の第3のタイマは、以下のように特定されるタイマT3340である。
【0100】
【表3】
このタイマは、GMMサービス要求失敗を示すために使用される。タイマの満了時に、さらなるGMMサービス要求を複数回開始することができ、GMMサービス要求失敗は、所定数の失敗または明示的拒絶のいずれか一方に起因する。
【0101】
したがって、異常な状態およびUEによる解放に限定された遷移指示原因の代わりに、遷移指示原因は、どのタイマが異常な状態のために失敗したかについての情報をさらに含むことができる。信号伝達接続解放指示が遷移指示として使用される、具体的実施例では、指示を以下のように構造化することができる。
【0102】
【表4】
このメッセージは、既存の信号伝達接続を解放する要求をUTRANに示すために、UEによって使用される。信号伝達接続解放指示の追加は、UTRANまたは他のネットワーク要素が、信号伝達接続解放指示の原因、それが異常な状態によるものであったかどうか、および異常な状態がどのようなものであったかどうかを受信することを可能にする。信号伝達接続解放指示の受信に基づいて、RRC接続解放手順は、順に、UTRANにおいて開始されることが許容される。
【0103】
この実施例の1つの実施において、UEは、特定のCN(コアネットワーク)ドメインに対する上層から、信号伝達接続を解放または中止する要求を受信すると、例えば、IE(情報要素)「CNドメインアイデンティティ」で識別される特定のCNドメインに対して、変数「ESTABLISHED_SIGNALLING_CONNECTIONS」が存在する場合に、信号伝達接続解放指示手順を開始する。変数がいずれの既存の信号伝達接続も識別しなければ、その特定のCNドメインに対する信号伝達接続の任意の継続中の確立が別の方式で中止される。Cell_PCHまたはURA_PCH状態での信号伝達接続解放指示手順の開始時に、UEは、原因「アップリンクデータ伝送」を使用して、セル更新手順を行う。セル更新手順の完了が成功すると、UEは、次に起こる信号伝達接続解放指示手順を続ける。
【0104】
すなわち、UEは、情報要素(IE)「CNドメインアイデンティティ」を上位論理層によって示される値に設定する。IEの値は、上層が行っているその関連信号伝達接続が解放される、CNドメインを示す。CNドメインアイデンティティがPSドメインに設定された場合、および上層がこの要求を開始する原因を示す場合には、IE「信号伝達解放指示原因」が、それに応じて設定される。UEはさらに、変数「ESTABLISHED_SIGNALLING_CONNECTIONS」から上層によって示されたアイデンティティとの信号伝達接続を除去する。UEは、例えば、認知モード無線リンク制御(AM RLC)を使用する専用制御チャネル(DCCH)上で、信号伝達接続解放指示メッセージを伝送する。RLCによる解放指示メッセージの配信成功の確認時に、手順が終了する。
【0105】
IE「信号伝達接続解放指示原因」も、本開示の実施形態に従って使用される。解放原因は、例えば、既存のメッセージ定義と整合される。上層解放原因メッセージは、例えば、以下のように構造化される。
【0106】
【表5】
この実施例では、T3310、T330、およびT3340満了は、以前に識別された、対応する番号のタイマの期限切れに対応する。原因値は、1つの実施では、アイドル遷移に対する選好のUE指示を除去し、状態遷移時に決定するUTRANを提供するように、「UEが要求したアイドル遷移」よりもむしろ「UEが要求したPSデータセッション終了」として設定可能であるが、予期された結果は、原因値によって識別されるものに対応する。信号伝達接続解放指示の拡張は、好ましくは、非臨界拡張であるが、必ずしもそうではない。
【0107】
ここで図9を参照する。図9は、種々のドメイン(例えば、PSまたはCS)に対する信号伝達接続解放指示を送信するか否かを監視する例示的UEのフロー図である。過程は、ステップ910で開始する。
【0108】
UEは、異常な状態が存在するかどうかを確認するようにチェックする、912に遷移する。そのような異常な状態は、上記で説明されるようなタイマT3310、タイマT3320、またはタイマT3340の期限切れを含むことができる。これらのタイマがある所定の回数で満了する場合、またはこれらのタイマのうちのいずれかの満了に基づいて明示的拒絶が受信された場合、UEは、信号伝達接続解放指示を送信するステップ914に進む。信号伝達接続解放指示メッセージが、信号伝達解放指示原因フィールドに付加される。信号伝達解放指示原因フィールドは、少なくとも、信号伝達解放指示が異常な状況または状態に基づくことを含み、一実施形態は、タイムアウトして異常な状態をもたらした特定のタイマを含む。
【0109】
逆に、ステップ912で、異常な状態が存在しないことをUEが見出した場合、UEは、さらなるデータがUEで見込まれるかどうかをチェックする、ステップ920に進む。これは、上記で説明されるように、Eメールが送信され、Eメールの送信の確認がUEにおいて返信されるときを含むことができる。さらなるデータが見込まれないことをUEが判定する場合の他の実施例は、当業者にとって公知であろう。
【0110】
ステップ920で、データ転送が終了したこと(または回線交換ドメインの場合には通話が終了したこと)をUEが判定した場合、UEは、信号伝達接続解放指示を送信するステップ922に進み、その場合、信号伝達解放指示原因フィールドが追加され、UEがアイドル遷移を要求したか、または単にPSセッションの終了を示したという事実を含む。
【0111】
ステップ920から、データが終了していない場合、UEは、元に戻り、ステップ912で異常な状態が存在するかどうかを、ステップ920でデータが終了したかどうかを引き続きチェックする。
【0112】
いったん信号伝達接続解放指示がステップ914またはステップ922に送信されると、過程はステップ930に進み、終了する。
【0113】
UEは、例えば、チェッカーおよび遷移指示送信機を形成する、UEマイクロプロセッサの動作を通して、またはハードウェア実装によって実行される、アプリケーションまたはアルゴリズムによって実装可能な機能的要素を含む。チェッカーは、遷移指示が送信されるべきかどうかをチェックするように構成される。そして、遷移指示送信機は、遷移指示が送信されるべきであるという送信機による指示に対応する遷移指示を送信するように構成される。遷移指示は、遷移指示原因フィールドを含んでもよい。
【0114】
1つの実施では、ネットワークは、代わりに、暗示的にタイマの時間切れを認識させられ、UEは、タイマの時間切れを示す原因値を送信する必要がない。すなわち、タイマは、ネットワークの承認時に計時を開始する。原因コードが画定され、原因コードは、ネットワークによってUEに提供される。そのような原因コードは、タイマを開始するためにUEによって使用される。以前にネットワークによって送信された原因コードが、タイマに計時を開始させるにつれて、ネットワークは、タイマの後続の時間切れの理由を暗示的に認識する。結果として、UEは、タイマの時間切れを示す原因値を送信する必要がない。
【0115】
図9ならびに先述の内容によって示唆されるように、原因は、1)異常な状態、ならびに2)正常な状態(例えば、PSデータセッション終了および/またはアイドルモードへの遷移の要求等の、異常ではない状態)を示すように、遷移指示(例えば、信号伝達接続解放指示)とともに包含可能で、かつ送信される。したがって、種々の実施では、UEにおける操作は、異常な状態を示すように、または代替として、アイドル遷移またはPSデータセッション終了、すなわち正常動作の要求に対する選好を示すように、遷移指示への原因の追加を提供する。そのような操作は、当然ながら、異常な状態の指示が行われるときのみに原因が遷移指示に追加される、UE操作も含む。そして、逆に、そのような操作は、正常な、すなわち、異常ではない動作およびトランザクションを示すだけのために、原因が遷移指示に追加される、UE操作も含む。すなわち、図9に関して、そのような代替操作では、もし、ステップ912で、異常な状態が存在する場合は、「はい」の分岐がステップ914に運ばれる一方で、異常な状態が存在しない場合は、UEは終了ステップ930に直接進む。逆に、他方のそのような代替操作では、開始ステップ912の後に、経路がデータ終了ステップ920に直接運ばれる。データが終了している場合、「はい」の分岐がステップ920に運ばれ、その後、ステップ930に運ばれる。データがステップ920において終了していない場合、いずれの分岐も同ステップ、すなわち、ステップ920に戻されない。
【0116】
図10を参照して、ネットワーク要素がステップ1010で遷移指示を受信すると(例えば、示されるような信号伝達接続解放指示)、ネットワーク要素は、ステップ1014で、もし存在すれば遷移指示原因フィールドを検査し、ステップ1016で、原因が異常な原因であるかどうか、または、それがアイドル遷移および/またはPSデータセッション終了を要求するUEによるものであるかどうかをチェックする。もし、ステップ1016で、信号伝達接続解放指示が異常な原因であれば、ネットワークノードは、性能監視およびアラーム監視の目的でアラームが留意されてもよい、ステップ1020に進む。主要性能インジケータを適切に更新することができる。
【0117】
逆に、もし、ステップ1016で、遷移指示(例えば、信号伝達接続解放指示)の原因が異常な状態の結果ではない、または言い換えれば、PSデータセッション終了またはアイドル遷移を要求するUEの結果であれば、ネットワークノードは、いずれのアラームも起こらず、指示を性能統計からフィルタにかけることができる、ステップ1030に進み、それにより、性能統計が歪曲されることを防止する。ステップ1020またはステップ1030から、ネットワークノードは、過程が終了するステップ1040に進む。
【0118】
遷移指示の受信または検査は、パケット交換データ接続終結のネットワーク要素による開始、または代替として、別のより好適な状態、例えば、CELL_FACH、CELL_PCH、URA_PCH、またはIDLE_モードへの遷移をもたらしてもよい。
【0119】
上記で示唆されるように、いくつかの実施では、遷移指示の原因の欠如はまた、遷移指示が正常または異常な状態の結果であるかどうか、およびアラームを起こさなければならないか否かを判定するために、使用されてもよい。例えば、正常な状態(すなわち、例えば、PSデータセッション終了および/またはアイドルモードへの遷移の要求等に関して、異常ではない)を表すためだけに原因が追加され、原因が追加されていない遷移指示をネットワーク要素が受信する場合、ネットワーク要素は、原因の欠如から、遷移指示が異常な状態の結果であることを推測し、随意で、アラームを起こし得る。逆に、別の実施例では、異常な状態を表すためだけに原因が追加され、ネットワーク要素が原因のない遷移指示を受信する場合、ネットワーク要素は、原因の欠如から、遷移指示が正常な状態(例えば、PSデータセッッション終了および/またはアイドルモードへの遷移の要求)の結果であることを推測し、アラームを起こし得ない。
【0120】
当業者によって理解されるように、ステップ1020は、種々のアラーム状態をさらに区別するために使用することができる。例えば、T3310タイムアウトは、第1の一式の統計値を保つために使用することができ、T3330タイムアウトは、第2の一式の統計値を保つために使用することができる。ステップ1020は、異常な状態の原因を区別するために使用することができ、それにより、ネットワーク操作者が性能をより効率的に追跡することを可能にする。
【0121】
ネットワークは、例えば、検査器およびアラーム発生器を形成する、プロセッサの動作を通して、またはハードウェア実装によって実行される、アプリケーションまたはアルゴリズムによって実装可能な機能的要素を含む。検査器は、遷移指示の遷移指示原因フィールドを検査するように構成される。検査器は、遷移指示原因フィールドが異常な状態を示すかどうかをチェックする。アラーム発生器は、信号伝達接続解放指示原因フィールドが異常な状態を示すことを検査器による検査が判定した場合に、選択的にアラームを生成するように構成される。
【0122】
1つの実施では、信号伝達接続解放指示の受信時に、UTRANは、受信される原因と、信号伝達接続の解放のための上層からの要求とを転送する。次いで、上層は、信号伝達接続の解放を開始することができる。IE信号伝達解放指示原因は、UEのRCCを誘起してメッセージを送信するように、UEの上層の原因を示す。原因は、異常な上層の手順の結果である可能性が高い。メッセージの原因の区別は、IEの受信成功を通して確保される。
【0123】
可能なシナリオは、信号伝達接続解放指示メッセージの配信成功のRLCによる確認の前に、信号伝達無線ベアラRB2上でRLCエンティティの伝送側の確立が発生する、シナリオを含む。そのような発生の場合、UEは、例えば、信号伝達無線ベアラRB2上のAM RLCを使用するアップリンクDCCH上で、信号伝達接続解放指示メッセージを再伝送する。信号伝達接続解放指示または要求メッセージの配信成功のRLCによる確認の前に、UTRAN手順からのRAT(無線アクセス技術)間ハンドオーバが発生する場合では、UEは、新規RATであるときに信号伝達接続を中止する。
【0124】
さらなる実施形態では、「信号伝達接続解放指示」または要求の代わりに、「データ転送完了指示」を利用することができる。上記の図9および10で説明されるものと同様の機能性が、このデータ転送完了指示に適用可能となる。
【0125】
一実施形態では、データ転送完了指示は、継続中のCSドメインデータ転送がないことをUEが判定し、そのPSデータ転送を完了したことをUTRANに知らせるために、UEによって使用される。そのようなメッセージは、例えば、AM RLCを使用するDCCH上で、UEからUTRANに送信される。例示的メッセージを以下に示す。
10.2.xデータ転送完了指示
このメッセージは、継続中のCSドメインデータ転送がないことをUEが判定し、そのPSデータ転送を完了したことをUTRANに知らせるために、UEによって使用される。RLC_SAP:AM
論理チャネル:DCCH
方向:UE→UTRAN
【0126】
【表6】
ここで図20を参照する。図20は、(例えば、信号伝達接続解放指示またはデータ転送完了指示のための)遷移指示または要求がUEからUTRANに送信される、実施形態を図示する。過程は、ステップ2010から開始し、UEにおける状態が遷移指示メッセージを送信するのに適切であるかどうかを判定するように、チェックがUE上で行われる、ステップ2012に進む。そのような状態は、例えば、以下の図11を参照して、本開示で説明され、UE上で1つ以上のアプリケーションを含むことができ、それらがデータ交換を終了したことを判定する。そのような状態はまた、タイマT3xxが作動していれば、期限切れになるのをある期間にわたって待つステップを含んでもよい。
【0127】
さらなる代替実施形態では、状態は、タイマT3xxが無限に設定された場合に、遷移指示の送信を妨げるステップを含んでもよい。理解されるように、T3xxは、無数の離散値を含むことができ、その1つが無限値を表す。
【0128】
もし、ステップ2012で、状態が遷移指示または要求メッセージを送信するのに適切でなければ、過程は、元に戻って、状態が遷移指示または要求メッセージを送信するのに適切となるまで引き続き監視する。
【0129】
いったん状態が適切になると、過程は、遷移指示がUTRANであるステップ2020に進む。例示的指示を上記の表に示す。
【0130】
次いで、過程は、遷移指示が成功したかどうかを判定するようにチェックが行われる、ステップ2022に進む。当業者によって理解されるように、これは、UTRANが遷移指示の受信に成功し、状態遷移を開始したことを意味し得る。「はい」であれば、過程は、ステップ2030に進み、終了する。
【0131】
逆に、ステップ2022で、遷移指示が成功しなかったと判定された場合、過程は、ステップ2024に進み、ある期間にわたって待機する。そのような待機は、所与の期間が経過する前に携帯電話が別の遷移指示メッセージを送信できないようにする、「阻止期間」、例えば、T3xxを使用して、実施することができる。代替として、過程は、遷移指示メッセージの数を所定の期間内で限定することができる(例えば、10分でわずか15のメッセージ)。阻止期間および所与の期間内のメッセージの数の限定の組み合わせも、可能である。
【0132】
期間は、基準において定義される値等の、所定のものとなり得て、例えば、RRC接続要求メッセージ、RRC接続設定メッセージ、RRC接続解放、無線ベアラ設定、システム情報同報通信メッセージ、システム情報ブロックメッセージ、アクティブセット更新、セル更新確認、UTRANモビリティ情報メッセージ、UTRANコマンドへのハンドオーバ、物理チャネル再構成メッセージ、無線ベアラ再構成メッセージ、無線ベアラ解放メッセージ、輸送チャネル再構成メッセージ、または任意の要求、構成、あるいは再構成メッセージの一部として、ネットワーク要素によって設定することができる。さらに、期間は、遷移指示メッセージ内のパラメータに基づいて設定することができる。したがって、期間は、UEがアイドルよりもむしろCell_PCHへの遷移を要求している場合に、より長くなり得る。
【0133】
ネットワーク要素による期間の信号伝達または送信は、情報要素の形を取ることができる。本明細書で使用されるように、信号伝達または送信は、情報をUEに直接送信するステップ、または情報を同報通信するステップを含むことができる。同様に、UEにおいて受信するステップは、同報通信チャネルの直接受信または読取を含むことができる。1つの例示的情報要素は、以下を含む。
【0134】
【表7】
T3xxの値は、一実施形態では以下のように定義される。
【0135】
【表8】
一実施形態では、既存のUMTS情報要素「接続モードでのUEタイマおよび定数」にT3xxを含むことができる。したがって、これは、システム情報ブロック型1に含むことによって、セルの中で同報通信することができる。代替実施形態では、タイマ値はまた、SIB3またはSIB4等の他のシステム情報メッセージを使用して信号伝達することもでき、または、代替として、あるいは加えて、専用UTRANモビリティ情報メッセージで信号伝達することができる。
【0136】
上記の表で示されるように、T3xx値は、設定値の間で変動し、ゼロ値または無限値を含むことができる。ゼロ値は、いずれの阻止も発生する必要がないことを示すために使用される。無限値は、遷移指示メッセージが決して送信されるべきではないことを示す。
【0137】
1つのモビリティの実施形態では、UEは、新規ネットワークまたはセルが遷移されるときはいつでも、T3xx値をリセットする。この実施例では、値は無限に設定される。このことは、遷移メッセージまたは無線ベアラメッセージが阻止タイマ値を含有しない場合に、デフォルトでUEが遷移指示メッセージを送信しないものであることを確実にする。したがって、例えば、遷移または無線ベアラメッセージが「遷移阻止指示」を含有しない場合は、タイマの値は無限に設定され、そうでなければ、指示の中で受信されるタイマの値が任意の以前に記憶された値に取って代わる。
【0138】
別の代替実施形態では、T3xxの値は、以下のように定義される。タイマT3xxの包含は随意的であり、それにより、含まれなければ、UEは、このタイマを構成または使用するステップをサポートする必要がないことを確実にする。
【0139】
【表9】
したがって、セルの中の阻止タイマの受信は、セルが遷移指示メッセージの使用を認識するというUEへの指示である。UEは、長期間にわたってこれ以上PSドメインデータがないという判定により、RRCまたは上位層によって開始された場合に、原因値を使用して遷移指示を信号伝達することを判定してもよい。ネットワークがこの原因とともに遷移指示メッセージ(本書でとらえられるように、どのような形態のメッセージでも)を受信すると、よりバッテリ効率の良いRRC状態への状態遷移変化をUEに信号伝達するように判定してもよい。
【0140】
一方で、代替実施形態では、阻止タイマがセルの中で受信されないか、または読み取られないときに、UEは、遷移指示メッセージを送信するための原因がUTRANによってサポートされていないことを判定することができる。この場合、UEは、T3xxの値を構成しないこと、また、遷移指示メッセージを送信するステップまたは送信を阻止するステップに関連してT3xxを使用しないことも判定することができる。
【0141】
阻止タイマが省略されることをUEが判定した場合には、これ以上伝送するPSデータがないことを判定する上位層に基づいて、遷移指示メッセージから原因値を含むことを省略し、遷移指示メッセージを送信するのみであってもよい。
【0142】
代替実施形態では、UEは、阻止タイマが省略されることを判定すると、これ以上伝送するPSデータがないことを判定する上位層に基づいて、遷移指示を開始するべきではない。
【0143】
この説明された動作の一実施形態では、遷移指示メッセージは、信号伝達接続解放指示メッセージである。
【0144】
したがって、第1の代替実施形態では、セルの中の阻止タイマの受信は、セルが遷移指示メッセージの使用を認識するという指示である。このメッセージの送信が許容される場合に、T3xxが無限値に設定されないとき、次いで、ネットワークが遷移指示を受信するときに、よりバッテリ効率の良いRRC状態(例えば、CELL_FACH、CELL_PCH、URA_PCH、またはIDLE_モード)への状態遷移変化をUEに信号伝達するように判定してもよい。
【0145】
3GPP TSG−RAN2 25.331基準を利用する特定の実施例では、次の内容が、以下で識別されるセクションに追加される。
【0146】
【表10】
これは、以下のセクションに追加される。
10.2.48.8.6 システム情報ブロック型3
10.2.48.8.7 システム情報ブロック型4
10.2.1 アクティブセット更新
10.2.8 セル更新確認
10.2.16 UTRANコマンドへのハンドオーバ
10.2.22 物理チャネル再構成
10.2.27 無線ベアラ再構成
10.2.30 無線ベアラ解放
10.2.33 無線ベアラ設定
10.2.40 RRC接続設定
10.2.50 輸送チャネル再構成
10.2.48.8.6 システム情報ブロック型3、および10.2.48.8.7
システム情報ブロック型4というメッセージ以外に、上記で説明されるメッセージは、全てモビリティ情報メッセージの例である。
【0147】
上記は、接続およびシステム動作、ならびに種々のセル間の遷移を網羅し、そのセルが遷移指示メッセージをサポートする場合に、UEが阻止タイマ値を有することを確実にする。例えば、UTRANコマンドへのハンドオーバは、第2世代ネットワーク等の別の無線アクセス技術から第3世代ネットワークへの遷移が、第3世代ネットワークの標的セルによってサポートされるなら阻止タイマ値を提供することを確実にする。
【0148】
具体的には、図21を参照すると、セル間の遷移は、「開始」として参照番号2110によって示されるように、前提条件として、またはUEの他の動作中に,発生している。過程は、構成メッセージが受信される、ブロック2112に進む。これは、上記で識別されるメッセージのうちのいずれかとなり得て、モビリティおよび非モビリティメッセージの両方を含む。次いで、過程は、構成メッセージが阻止タイマ値を含むかどうかを確認するようにチェックが行われる、ブロック2114に進む。
【0149】
そうでなければ、過程は、阻止タイマ値が無限に設定される、ブロック2120に進む。逆に、ブロック2114から、過程は、構成メッセージが阻止タイマ値を含まないことが判定された場合に、ブロック2130に進む。ブロック2130では、阻止タイマ値がUE上に記憶され、阻止タイマの以前の値に取って代わる。次いで、過程は、ブロック2140に進み、終了する。理解されるように、一実施形態では、ネットワークまたはセルの変化が発生したときはいつでも、または遷移指示が送信される必要があるときはいつでも、図21の過程が呼び出される。
【0150】
いったん過程がステップ2024で所定の時間にわたって待機すると、過程は、ステップ2012に戻って、遷移指示を送信するための条件が依然として存在するかどうかを判定する。もし「はい」であれば、過程は、ステップ2020および2022に戻る。
【0151】
上記に基づいて、阻止タイマ値は、種々の実施形態で提供されてもよい。第1の実施形態では、それは、阻止タイマ値を伝えるためにRRC接続設定メッセージのみを使用して提供することができる。
【0152】
第2の実施形態では、阻止タイマ値を伝えるために、システム情報を使用することができる。
【0153】
第3の実施形態では、阻止タイマ値を送信して、アイドルモードならびにCell_PCH/Cell_FACHおよびDCH状態のUEが最新情報を有することを確実にするために、RRC接続設定およびシステム情報メッセージの両方を利用することができる。
【0154】
第4の実施形態では、無線ベアラを持たずにPDPコンテキストが確立されるときに、データメッセージを送信するように無線ベアラが後に確立されると、その時に阻止タイマ値を伝えることができるように、無線ベアラ設定において阻止タイマ値を送信することに加えて、阻止タイマ値を第3の実施形態のように送信することができる。
【0155】
第5の実施形態では、第4の実施形態を、再構成、セル更新確認、および阻止タイマ値を伝えるUTRANへのハンドオーバコマンドを含む、上記で説明されるような全てのモビリティ関連メッセージと組み合わせることができる。
【0156】
第1から第4の実施形態では、モビリティ中に、UEがその現在記憶されている阻止タイマ値を維持する。上記で示されるように、阻止タイマが無限に設定される、いくつかの場合において、これは、ネットワークタイマが期限切れになること、およびネットワークが、UEを阻止タイマの新規値を受信または判定することができるRCC状態にすることを、UEが待たなければならないことを意味してもよい。阻止タイマがハンドオーバ前に無限以外の何らかの値である、他の場合において、UEがタイマ値を新規セルの中で示される値に更新することができるまで、この他の値が引き続き使用される。
【0157】
第5の実施形態について、阻止タイマ値がモビリティ中に更新されること、および遷移指示メッセージがUEから不必要に送信されないことを確実にするために、過程図21が利用される。
【0158】
RLC再確立またはRAT間変更に例外が発生してもよい。遷移指示メッセージの配信成功がRLCによって確認される前に、RLCエンティティの伝送側の再確立が発生した場合、一実施形態では、UEは、AM RLCを使用するアップリンクDCCH上で遷移指示メッセージを伝送する。
【0159】
一実施形態では、遷移指示メッセージの配信成功がRLCによって確認される前に、UTRAN手順からのRAT間ハンドオーバが発生した場合、UEは、新規RATにある間に信号伝達接続を中止する。
【0160】
ネットワーク側では、過程は、以下の図18を参照して説明されるものと同様に取り扱われる。
【0161】
再度、図1を参照すると、アイドルモード110よりもURA_PCH状態128等の接続モード120であることが望ましくてもよい。例えば、接続モード120におけるCELL_DCH状態122またはCELL_FACH状態124への接続の待ち時間が低くなる必要がある場合、接続モード120のPCH状態であることが好ましい。例えば、基準を改正して、UEが特定の状態(例えば、この場合はURA_PCH状態128)にすることをUTRANに要求できるようにすること等によって、これを達成する多数の方法がある。
【0162】
代替として、接続マネージャは、RCC接続が現在どのような状態であるか等の他の要因を考慮に入れてもよい。もし、例えば、RRC接続がURA_PCH状態であれば、アイドルモード110にする必要がないことを決定してもよく、したがって、いずれの信号伝達接続解放手順も開始されない。
【0163】
さらなる代替案では、ネットワーク要素(例えば、UTRAN)が、RCC接続が現在どのような状態であるか等の他の考慮を自ら考慮にいれてもよく、もし、例えば、RRC接続がURA_PCH状態であれば、アイドルモード110にする必要がないことを決定し、接続を解放する代わりに、単にUEをより好適な状態に遷移させてもよい。
【0164】
図4を参照する。図4Aは、上記の基礎構造の「4」実施例による、現在のUMTS実装を示す。図4に図示されるように、時間は水平軸にわたっている。
【0165】
UEは、RRCアイドル状態110で起動し、伝送される必要のあるローカルまたはモバイル生成データ、またはUTRANから受信されるページに基づいて、RRC接続を確立し始める。
【0166】
図4Aに図示されるように、RRC接続設定310が最初に発生することができ、RRC状態は、この期間中では接続状態410である。
【0167】
次に、信号伝達接続設定312、暗号化および完全性設定314、および無線ベアラ設定316が発生する。RRC状態は、これらの手順中ではCELL_DCH状態122である。図4Aに図示されるように、RRCアイドルから無線ベアラが設定される時間まで移動するための経過時間は、この実施例では約2秒である。
【0168】
次に、データが交換される。図4Aの実施例では、これは約2〜4秒で達成され、ステップ420によって図示される。
【0169】
データがステップ420で交換された後、必要に応じた断続的RLC信号伝達PDUを除いて、いずれのデータも交換されず、したがって、無線リソースは、約10秒後により低いデータ転送速度のDCH構成となるように、ネットワークによって再構成される。これは、ステップ422および424で図示される。
【0170】
より低いデータ転送速度のDCH構成では、17秒にわたって何も受信されず、その時点で、RRC接続がステップ428でネットワークによって解放される。
【0171】
いったんRRC接続解放がステップ428で開始されると、RRC状態は、約40ミリ秒間の切断状態430に進み、その後、UEはRRCアイドル状態110である。
【0172】
同様に図4Aに図示されるように、RRCがCELL_DCH状態122である期間にわたって、UE電流消費が図示される。ここで見られるように、電流消費は、CELL_DCH状態の期間全体にわたって、約200〜300ミリアンペアである。切断およびアイドル中に、1.28秒のDRXサイクルを仮定すると、約3ミリアンペアが利用される。しかしながら、200〜300ミリアンペアにおける35秒の電流消費がバッテリ上で排出している。
【0173】
ここで、図4Bを参照する。図4Bは、ここでは信号伝達接続解放のみを実施する、上記からの同じ例示的基礎構造「4」を利用する。
【0174】
図4Bに図示されるように、同じ設定ステップ310、312、314、および316が発生し、これは、RRCアイドル状態110とRRC CELL_DCH状態122との間で移動するときに同じ時間量を要する。
【0175】
さらに、図4Aのステップ420での例示的Eメールに対するRRCデータPDU交換は、図4Bでも行われ、これは、約2〜4秒かかる。
【0176】
図4Bの実施例のUEには、図4Bの実施例では2秒であり、ステップ440によって図示される、アプリケーション特有の非活動タイムアウトがある。特定の時間量にわたって非活動があると接続マネージャが判定した後に、UEは、この場合、ステップ442での信号伝達接続解放指示である、遷移指示を送信し、ステップ448では、ネットワークは、指示の受信およびUEに対する無線リソースプロファイルに基づいて、RRC接続を解放するように進む。
【0177】
図4Bで図示されるように、CELL_DCHステップ122中の電流消費は、依然として約200〜300ミリアンペアである。しかしながら、接続時間は、わずか約8秒である。当業者によって理解されるように、携帯電話がセルDCH状態122のままである、かなり短い時間量は、UEデバイスにとって有意なバッテリ節約をもたらす。
【0178】
ここで、図5を参照する。図5は、基礎構造「3」として上記で示される基礎構造を使用して、第2の実施例を示す。図4Aおよび4Bと同様に、約2秒かかる接続設定が発生する。これは、RRC接続設定310、信号伝達接続設定312、暗号化および完全性設定314、および無線ベアラ設定316を必要とする。
【0179】
この設定中に、UEは、RRCアイドルモード110からCELL_DCH状態122になり、その間にRRC状態接続ステップ410を伴う。
【0180】
図4Aと同様に、図5Aでは、RLCデータPDU交換がステップ420で発生し、図5Aの実施例では、2〜4秒かかる。
【0181】
基礎構造3によれば、RLC信号伝達PDU交換は、必要に応じた断続的RLC信号伝達PDUを除いて、いずれのデータも受信せず、したがって、ステップ422で5秒の期間にわたってアイドルであり、その時点で、無線リソースは、UEをCELL_DCH状態122からCELL_FACH状態124に再構成する。これは、ステップ450で行われる。
【0182】
CELL_FACH状態124では、RLC信号伝達PDU交換は、この場合は30秒である所定の時間量にわたって、必要に応じた断続的RLC信号伝達PDUを除いて、いずれのデータもないことを見出し、その時点で、ネットワークによるRRC接続解放がステップ428で行われる。
【0183】
図5Aで見られるように、これは、RRC状態をアイドルモード110にする。
【0184】
図5Aでさらに見られるように、DCHモード中の電流消費は、200〜300ミリアンペアの間である。CELL_FACH状態124になるとき、電流消費は、約120〜180ミリアンペアまで低下する。RRCコネクタが解放され、RRCがアイドルモード110になった後、電力消費は、約3ミリアンペアである。
【0185】
CELL_DCH状態122またはCELL_FACH状態124である、UTRA RRC接続モード状態は、図5Aの実施例では約40秒にわたって続く。
【0186】
ここで、図5Bを参照する。図5Bは、RRC接続設定310、信号伝達接続設定312、暗号化完全性設定314、および無線ベアラ設定316を得るように、約2秒の同じ接続時間を伴う、図5Aと同じ基礎構造「3」を図示する。さらに、RLCデータPDU交換420は、約2〜4秒かかる。
【0187】
図4Bと同様に、UEアプリケーションは、ステップ440で特定の非活動タイムアウトを検出し、その時点で、遷移指示(例えば、信号伝達接続解放指示442)がUEによって送信され、結果として、ネットワークがステップ448でRRC接続を解放する。
【0188】
図5Bでさらに見ることができるように、RRCは、アイドルモード110で起動し、CELL_FACH状態に進むことなくCELL_DCH状態122になる。
【0189】
図5Bでさらに見られるように、電流消費は、図5の実施例によれば約8秒である、RRC段階がCELL_DCH状態122である時間では、約200〜300ミリアンペアである。
【0190】
したがって、図4Aと4B、および図5Aと5Bとの間の比較は、有意量の電流消費が排除され、それにより、UEのバッテリ寿命を延長することを示す。当業者によって理解されるように、上記はさらに、現在の3GPP仕様書との関連で使用することができる。
【0191】
ここで、図6を参照する。図6は、UMTSネットワーク用のプロトコルスタックを図示する。
【0192】
図6で見られるように、UMTSは、CS制御プレーン610、PS制御プレーン611、およびPSユーザプレーン630を含む。
【0193】
これら3つのプレーン内には、非アクセス層(NAS)部分614およびアクセス層部分616が存在する。
【0194】
CS制御プレーン610におけるNAS部分614は、呼制御(CC)618、付加サービス(SS)620、およびショートメッセージサービス(SMS)622を含む。
【0195】
PS制御プレーン611におけるNAS部分614は、モビリティ管理(MM)およびGPRSモビリティ管理(GMM)626の両方を含む。それはさらに、セッション管理/無線アクセスベアラ管理SM/RABM624およびGSMS628を含む。
【0196】
CC618は、回線交換サービス用の呼管理信号伝達を提供する。SM/RABM624のセッション管理は、PDPテキスト有効化、無効化、および修正を提供する。SM/RABM624はまた、サービス交渉の質も提供する。
【0197】
SM/RABM624のRABM部分の主要機能は、PDPコンテキストを無線アクセスベアラに接続することである。したがって、SM/RABM624は、無線リソースの設定、修正、および解放に関与している。
【0198】
CS制御プレーン610およびPS制御プレーン611は、アクセス層616において、無線リソース制御(RRC)617の上に位置する。
【0199】
PSユーザプレーン630におけるNAS部分614は、アプリケーション層638、TCP/UDP層636、およびPDP層634を含む。PDP層634は、例えば、インターネットプロトコル(Internet Protocol/IP)を含むことができる。
【0200】
アクセス層616は、PSユーザプレーン630において、パケットデータ集中プロトコル(PDCP)632を含む。PDCP632は、(図8で見られるように)WCDMAプロトコルを、UEとRNCとの間でTCP/IPプロトコルを運ぶのに好適にするように設計され、随意で、IPトラッフィック流プロトコルヘッダ圧縮および復元用のものである。
【0201】
UMTS無線リンク制御(Radio Link Control/RLC)640および媒体アクセス制御(Medium Access Control/MAC)層650は、UMTS無線インターフェースのデータリンク副層を形成し、RNCノードおよびユーザ機器上に存在する。
【0202】
層1(L1)のUMTS層(物理層660)は、RLC/MAC層640および650の下側にある。この層は、通信用の物理層である。
【0203】
上記は、種々のモバイルまたはワイヤレスデバイス上に実装することができるが、1つのモバイルデバイスの実施例を、図7に関して以下で概説する。ここで、図7を参照する。
【0204】
UE700は、好ましくは、少なくとも音声およびデータ通信能力を有する、双方向ワイヤレス通信デバイスである。UE700は、好ましくは、インターネット上で他のコンピュータシステムと通信する能力を有する。提供される正確な機能性に応じて、ワイヤレスデバイスは、例として、データメッセージングデバイス、双方向ポケットベル、ワイヤレスEメールデバイス、データメッセージング能力付きの携帯電話、ワイヤレスインターネット機器、またはデータ通信デバイスと呼ばれてもよい。
【0205】
UE700は、双方向通信に有効である場合、受信器712および送信器714の両方、ならびに、1つ以上の、好ましくは、組み込まれた、または内部のアンテナ要素716および718、局部発振器(LO)713、およびデジタル信号プロセッサ(DSP)720等の処理モジュール等の、関連構成要素を含む、通信サブシステム711を組み込む。通信の当業者にとって明白となるように、通信サブシステム711の特定の設計は、デバイスが動作することを目的とする通信ネットワークに依存する。例えば、UE700は、GPRSネットワークまたはUMTSネットワーク内で動作するように設計される、通信サブシステム711を含んでもよい。
【0206】
ネットワークアクセス要件もまた、ネットワーク719の種類に応じて変動する。例えば、UMTSおよびGPRSネットワークでは、ネットワークアクセスは、UE700の加入者またはユーザと関連付けられる。したがって、例えば、GPRSモバイルデバイスは、GPRSネットワーク上で動作するために、加入者識別モジュール(SIM)カードを必要とする。UMTSでは、USIMまたはSIMモジュールが必要とされる。CDMAでは、RUIMカードまたはモジュールが必要とされる。これらは、本明細書では、UIMインターフェースと呼ばれる。有効なUIMインターフェースがないと、モバイルデバイスは、完全には機能しない場合がある。ローカルまたは非ネットワーク通信機能、ならびに緊急通話等の法的に必要な機能(もしあれば)が利用可能であってもよいが、モバイルデバイス700は、ネットワーク700上の通信を伴う、任意の他の機能を実行することができなくなる。UIMインターフェース744は、通常、ディスケットまたはPCMCIAカードのように、カードを挿入し、取り出すことができる、カードスロットと同様である。UIMカードは、約64Kのメモリを有し、多くの主要構成751と、識別および加入者関連情報等の他の情報753とを保持することができる。
【0207】
必要なネットワーク登録または有効化手順が完了すると、UE700は、ネットワーク719上で通信信号を送受信してもよい。通信ネットワーク719を通してアンテナ716によって受信される信号は、信号増幅、周波数下方変換、チャネル選択、および同等物等の一般的な受信器機能、および図7に示された実施例のシステムでは、アナログ・デジタル(A/D)変換を行ってもよい、受信器712への入力である。受信された信号のA/D変換は、DSP720で行われる復調および復号等の、より複雑な通信機能を可能にする。同様に、伝送される信号は、例えば、DSP720による復調および復号を含んで処理され、デジタル・アナログ変換、周波数上方変換、フィルタリング、増幅、およびアンテナ718を介した通信ネットワーク719上の伝送のために、送信器714に入力される。DSP720は、通信信号を処理するだけでなく、受信器および送信器制御も提供する。例えば、受信器712および送信器714において通信信号に適用される利得は、DSP720において実装される自動利得制御アルゴリズムを通して、適応的に制御されてもよい。
【0208】
ネットワーク719はさらに、サーバ760および他の要素(図示せず)を含む、複数のシステムと通信してもよい。例えば、ネットワーク719は、種々のサービスレベルを伴う種々のクライアントに適応するために、企業システムおよびウェブクライアントシステムの両方と通信してもよい。
【0209】
UE700は、好ましくは、デバイスの全体的動作を制御する、マイクロプロセッサ738を含む。少なくともデータ通信を含む、通信機能は、通信サブシステム711を通して果たされる。マイクロプロセッサ738はまた、ディスプレイ722、フラッシュメモリ724、ランダムアクセスメモリ(RAM)726、補助入力/出力(I/O)サブシステム728、シリアルポート730、キーボード732、スピーカ734、マイクロフォン736、短距離通信サブシステム740、および、概して742と指定される任意の他のデバイスサブステム等の、さらなるデバイスサブシステムとも相互作用する。
【0210】
図7に示されたサブシステムのうちのいくつかは、通信関連機能を果たすが、他のサブシステムは、「常駐」またはオンデバイス機能を提供してもよい。明白に、例えば、キーボード732およびディスプレイ722等のいくつかのサブシステムは、通信ネットワーク上で伝送するためのテキストメッセージの入力等の通信関連機能と、計算機またはタスクリスト等のデバイス常駐機能との両方に使用されてもよい。
【0211】
マイクロプロセッサ738によって使用されるオペレーティングシステムソフトウェアは、好ましくは、代わりに読み出し専用メモリ(ROM)または同様の記憶要素(図示せず)であってもよい、フラッシュメモリ724等の持続的記憶部に記憶される。当業者であれば、オペレーティングシステム、特定のデバイスアプリケーション、またはその部分は、RAM726等の揮発性メモリに一時的に取り込まれてもよいことを理解するであろう。受信された通信信号もまた、RAM726に記憶されてもよい。さらに、一意の識別子もまた、好ましくは読み取り専用メモリに記憶される。
【0212】
示されるように、フラッシュメモリ724は、コンピュータプログラム758と、プログラムデータ記憶部750、752、754、および756との両方に対する異なるエリアに分離することができる。これらの異なる記憶型は、各プログラムが、独自のデータ記憶要件のためにフラッシュメモリ724の一部分を割り当てることができることを示す。マイクロプロセッサ738は、そのオペレーティングシステム機能に加えて、好ましくは、モバイルデバイス上でのソフトウェアアプリケーションの実行を可能にする。例えば、少なくともデータおよび音声通信アプリケーションを含む、基本動作を制御する所定の一式のアプリケーションが、通常、製造中にUE700にインストールされる。好ましいソフトウェアアプリケーションは、Eメール、カレンダーイベント、音声メール、約束、およびタスクアイテム等であるが、それらに限定されない、モバイルデバイスのユーザに関するデータアイテムを整理および管理する能力を有する、個人情報マネージャ(PIM)アプリケーションであってもよい。当然ながら、1つ以上のメモリ記憶部が、PIMデータアイテムの記憶を促進するようにモバイルデバイス上で利用可能となる。そのようなPIMアプリケーションは、好ましくは、ワイヤレスネットワーク719を介してデータアイテムを送受信する能力を有する。好ましい実施形態では、PIMデータアイテムは、ワイヤレスネットワーク719を介して、途切れなく統合、同期化、および更新され、モバイルデバイスユーザの対応するデータアイテムが、記憶されるか、またはホストコンピュータシステムと関連付けられる。さらなるアプリケーションもまた、ネットワーク719、補助I/Oサブシステム728、シリアルポート730、短距離通信サブシステム740、または任意の他の好適なサブシステム742を通して、モバイルデバイス700上に搭載され、マイクロプロセッサ738による実行のために、RAM726、または好ましくは不揮発性記憶部(図示せず)に、ユーザによってインストールされてもよい。アプリケーションのインストールにおける、そのような融通性は、デバイスの機能性を増加させ、強化オンデバイス機能、通信関連機能、または両方を提供してもよい。例えば、安全な通信アプリケーションは、電子商取引機能および他のそのような金融取引が、UE700を使用して行われることを可能にしてもよい。しかしながら、これらのアプリケーションは、上記によれば、多くの場合において、通信事業社によって承認される必要がある。
【0213】
データ通信モードでは、テキストメッセージまたはウェブページダウンロード等の受信された信号は、通信サブシステム711によって処理され、好ましくは、ディスプレイ722に、または代替として補助I/Oデバイス728に出力するために、受信された信号をさらに処理する、マイクロプロセッサ738に入力される。UE700のユーザはまた、ディスプレイ722、およびおそらく補助I/Oデバイス728と併せて、例えば、好ましくは、完全英数字キーボードまたは電話型キーパッドである、キーボード732を使用して、Eメールメッセージ等のデータアイテムを構成してもよい。次いで、そのような構成されたアイテムは、通信サブシステム711を通して通信ネットワーク上で伝送されてもよい。
【0214】
音声通信については、受信された信号が、好ましくはスピーカ734に出力され、伝送するための信号が、マイクロフォン736によって生成されることを除いて、UE700の全体的動作は同様である。音声メッセージ録音サブシステム等の、代替的な音声またはオーディオI/Oサブシステムもまた、UE700上に実装されてもよい。音声またはオーディオ信号出力は、好ましくは、主にスピーカ734を通して達成されるが、ディスプレイ722もまた、例えば、発呼者の身元、音声電話の持続時間、または他の音声電話関連情報の指示を提供するために使用されてもよい。
【0215】
図7のシリアルポート730は、通常、ユーザのデスクトップコンピュータ(図示せず)との同期化が望ましくてもよい、携帯情報端末(PDA)型モバイルデバイスで実装される。そのようなポート730は、外部デバイスまたはソフトウェアアプリケーションを通して、ユーザが選好を設定することを可能にし、ワイヤレス通信ネットワーク以外を通して、UE700への情報またはソフトウェアダウンロードを提供することによって、モバイルデバイス700の能力を拡張する。例えば、直接的であり、したがって確実かつ信頼されている接続を通して、暗号化キーをデバイスに搭載し、それにより、安全なデバイス通信を可能にするために、代替ダウンロード経路が使用されてもよい。
【0216】
代替として、シリアルポート730は、他の通信に使用することができ、かつユニバーサルシリアルバス(USB)ポートとして含むことができる。インターフェースがシリアルポート730と関連付けられる。
【0217】
短距離通信サブシステム等の、他の通信サブシステム740は、UE700と、必ずしも同様のデバイスである必要はない、異なるシステムまたはデバイスとの間の通信の通信を提供してもよい、さらなるオプションの構成要素である。例えば、サブシステム740は、同様に有効化されたシステムおよびデバイスとの通信を提供するように、赤外線デバイスならびに関連回路および構成要素、またはBluetoothTM通信モジュールを含んでもよい。
【0218】
ここで、図8を参照する。図8は、ワイヤレス通信ネットワークを通して通信するUE802を含む、通信システム800のブロック図である。
【0219】
UE802は、1つまたは複数のノードB806とワイヤレスで通信する。各ノードB806は、エアインターフェース処理およびいくつかの無線リソース管理機能に関与している。ノードB806は、GSM/GPRSネットワークにおけるベーストランシーバ基地局と同様の機能性を提供する。
【0220】
図8の通信システム800において示されるワイヤレスリンクは、1つ以上の異なるチャネル、典型的には、異なる無線周波数(RF)チャネル、およびワイヤレスネットワークとUE802との間で使用される関連プロトコルを表す。Uuエアインターフェース804は、UE802とノードB806との間で使用される。
【0221】
RFチャネルは、典型的には、帯域幅全体の制限およびUE802の限定されたバッテリ電力により、節約されなければならない、限定されたリソースである。当業者であれば、実際の実践でのワイヤレスネットワークは、ネットワーク範囲の所望の全体的拡張に応じて、数百のセルを含んでもよい。全ての関連構成要素は、複数のネットワークコントローラによって制御される、複数のスイッチおよびルータ(図示せず)によって接続されてもよい。
【0222】
各ノードB806は、無線ネットワークコントローラ(RNC)810と通信する。RNC810は、そのエリアでの無線リソースの制御に関与している。1つのRNC810は、複数のノードB806を制御する。
【0223】
UMTSネットワークにおけるRNC810は、GSM/GPRSネットワークにおける基地局コントローラ(BSC)機能と同等の機能を提供する。しかしながら、RNC810は、MSCおよびSGSNを伴うことなく、例えば、自律ハンドオーバ管理を含む、さらなる知能を含む。
【0224】
ノードB806とRNC810との間で使用されるインターフェースは、lubインターフェース808である。3GPP TS 25.433 V3.11.0(2002−09)および3GPP TS 25.433 V5.7.0(2004−01)で定義されるように、NBAP(ノードBアプリケーション部)信号伝達プロトコルが主に使用される。
【0225】
ユニバーサル地上波無線アクセスネットワーク(UTRAN)820は、RNC810、ノードB806、およびUuエアインターフェース804を備える。
【0226】
回線交換トラフィックは、携帯電話交換センター(Mobile Switching
Centre/MSC)830に経路指定される。MSC830は、電話をかけ、加入者から、またはPSTN(図示せず)からデータを取り入れ、受信する、コンピュータである。
【0227】
RNC810とMSC830との間のトラフィックは、Iu−CSインターフェース828を使用する。Iu−CSインターフェース828は、UTRAN820とコア音声ネットワークとの間で(典型的には)音声トラフィックおよび信号伝達を運ぶための回線交換接続である。使用される主要信号伝達プロトコルは、RANAP(無線アクセスネットワークアプリケーション部)である。RANAPプロトコルは、MSC830またはSGSN850(以下でさらに詳細に定義される)となり得る、コアネットワーク821と、UTRAN820との間のUMTS信号伝達で使用される。RANAPプロトコルは、3GPP TS 25.413 V3.11.1(2002−09)およびTS 25.413 V5.7.0(2004−01)で定義される。
【0228】
ネットワーク操作者により登録された全てのUE802について、永久データ(UE802のユーザのプロファイル等)ならびに一時データ(UE802の現在のロケーション等)が、ホームロケーションレジストリ(HLR)838に記憶される。UE802の音声電話の場合、HLR838は、UE802の現在のロケーションを判定するように問い合わせられる。MSC830のビジタロケーションレジスタ(Visitor Location Register/VLR)836は、一群のロケーションアリアに関与しており、現在その責任エリアにある移動局のデータを記憶する。これは、より迅速なアクセスのために、HLR838からVLR836に伝送された永久移動局データの複数部分を含む。しかしながら、MSC830のVLR836はまた、一時的識別等のローカルデータを割り当て、記憶してもよい。UE802はまた、HLR838によるシステムアクセスで認証される。
【0229】
パケットデータは、サービスGPRSサポートノード(Service GPRS Support Node/SGSN)850を通して経路指定される。SGSN850は、GPRS/UMTSネットワークにおけるRNCとコアネットワークとの間のゲートウェイであり、その地理的サービスエリア内でUEを往復するデータパケットの配信に関与している。Iu−PSインターフェース848は、RNC810とSGSN850との間で使用され、UTRAN820とコアデータネットワークとの間で(典型的には)データトラフィックおよび信号伝達を運ぶためのパケット交換接続である。使用される主要信号伝達プロトコルは、RANAP(上記で説明される)である。
【0230】
SGSN850は、ゲートウェイGPRSサポートノード(Gateway GPRS
Support Node/GGSN)860と通信する。GGSN860は、UMTS/GPRSネットワークと、インターネットまたはプライベートネットワーク等の他のネットワークとの間のインターフェースである。GGSN860は、Giインターフェース上で公衆データネットワークPDN870に接続される。
【0231】
当業者であれば、ワイヤレスネットワークは、おそらく、図8で明示的に示されていない他のネットワークを含む、他のシステムと接続されてもよいことを理解するであろう。たとえ交換された実際のパケットデータがなくても、ネットワークは、通常、最低限でも、ある種類のページングおよびシステム情報を継続的に伝送する。ネットワークは多くの部分から成るが、これらの部分は全て、ワイヤレスリンクにおいてある動作をもたらすように協働する。
【0232】
図11は、複数の同時パケットデータ通信サービスセッションに従ってUEの動作を表す、概して1102で示される表現を図示する。ここでは、それぞれPDP1およびPDP2と指定される特定のPDPコンテキストと関連付けられる、2つのパケットデータサービスが、現在アクティブである。プロット1104は、第1のパケットデータサービスに有効化されたPDPコンテキストを表し、プロット1106は、第1のパケットデータサービスに割り当てられた無線リソースを表す。そして、プロット1108は、第2のパケットデータサービスに有効化されたPDPコンテキストを表し、プロット1112は、第2のパケットデータサービスに割り当てられた無線リソースを表す。UEは、セグメント1114によって示されるサービス要求を介して、無線アクセスベアラ割当を要求する。そして、UEはまた、本開示の実施形態に従ってセグメント1116によって示される、無線ベアラサービス解放も要求する。サービス要求および別個のサービスのためのサービス解放は、相互とは無関係であり、すなわち、独立して生成される。図11の例示的説明図では、PDPコンテキストおよび関連PDPコンテキストに対する無線リソースは、実質的に同時に割り当てられる。そして、無線リソース解放は、示されるように、UEによる要求時に、またはRNC(無線ネットワークコントローラ)が無線リソースを解放することを決定するときに、許可される。
【0233】
無線リソース解放要求、または無線リソースを解放する他の決定に対応して、ネットワークは、パケットデータサービスと関連付けられた無線リソースを選択的に解除する。無線解放要求は、信号伝達接続全体ではなく、無線アクセスベアラごとに行われ、それにより、リソース割当の向上した粒度制御を可能にする。
【0234】
例示的実装では、指定1118および1122によって示されるような1次サービスおよび1つ以上の2次サービスとして、単一のパケットデータサービスをさらに形成可能である。無線リソース解放は、無線リソース割当がもはや必要ではない、またはそうでなければ解放されることが所望される、1つ以上の1次および2次サービスのどれかを識別するステップのさらなる許容である。それにより、効率的な無線リソース割当が提供される。加えて、不必要な処理に割り当てられたであろうプロセッサ電力を、ここでは他の目的でより良好に利用することができるため、UE上のプロセッサの最適な利用が提供される。
【0235】
図12は、通信システム800の部品、すなわち、複数の連続パケットデータサービスセッションに関する本開示の実施形態に従って動作する、UE802および無線ネットワークコントローラ(RNC)/SGSN810/850を図示する。UEは、装置1126を含み、RNC/SGSNは、本開示の実施形態の装置1128を含む。装置1126および1128を形成する要素は、処理回路ならびにハードウェアまたはファームウェア実装によって実行可能なアルゴリズムを含む、任意の所望の方式で実装可能であると機能的に表されている。装置1128の要素は、RNC/SGSNにおいて具体化されると表されているが、他の実施では、他のネットワークロケーションにおいて他の場所で形成されるか、または、2つ以上のネットワークロケーションにわたって分布させられる。
【0236】
装置1126は、検出器1132および遷移指示送信機1134を含む。1つの例示的実施では、要素1132および1134は、セッション管理層、例えば、UEのUMTSの中で画定される非アクセス層(Non−Access Stratum/NAS)の層において具体化される。
【0237】
別の例示的実装では、要素は、アクセス層(Access Stratum/AS)の副層において具体化される。AS副層において実装されると、要素は、1136で示される、接続マネージャの一部として実装される。このように実装されると、要素は、PDPコンテキスト動作またはアプリケーション層動作を認識する必要がない。
【0238】
検出器は、パケット通信サービスと関連付けられた遷移指示を送信するように、判定が行われるときを検出する。判定は、例えば、アプリケーション層または他の論理層で行われ、セッション管理層およびそこで具体化される検出器に提供される。検出器によって行われる検出の指示は、無線リソース解放指示送信機に提供される。送信機は、図11に示されたサービス解放要求1116を形成する遷移指示を生成し、UEに遷移指示を送信させる。
【0239】
さらなる実装では、遷移指示は、必要に応じて、ここと上記とで説明される前述の原因のうちのいずれか等の原因を含有する、原因フィールドを含み、または、原因フィールドは、UEを遷移させるよりもUEがネットワークを好む、好ましい状態を識別する。
【0240】
ネットワークにおいて具体化される装置1128は、検査器1142および許可器1144を含む。検査器は、そこで受信されると遷移指示を検査する。そして、遷移許可器1144は、遷移指示で要求されたように、UEを選択的に遷移させるように動作する。
【0241】
信号伝達が無線リソース制御(RRC)層で行われる実装では、SGSNよりもむしろ、無線ネットワークコントローラ(RNC)がUEの検査および遷移を行う。そして、それに対応して、UEにおいて具体化される装置は、RRC層で形成され、または、装置は、そうでなければ、生成された指示をRRCレベルで送信させる。
【0242】
例示的な制御フローでは、上位層は、必要に応じて、特定のPDPコンテキストに割り当てられる無線リソースがもはや必要ではないことを、NAS/RRC層に知らせる。RRC層指示メッセージが、ネットワークに送信される。メッセージは、例えば、無線ネットワークコントローラへのパケットデータサービスを識別する、RAB IDまたはRB
IDを含む。そして、それに応じて、無線ネットワークコントローラの動作は、UEに返信される無線リソース解放、無線リソース再構成、または無線リソース制御(RRC)接続解放メッセージを終了する決意をする手順を誘起する。RNC手順は、例えば、3GPP文書TS 23.060第9.2.5項で定められる手順と同様または同等である。RAB IDは、例えば、関連PDPコンテキストを識別するネットワークサービスアクセスポイント識別子(Network Service Access Point Identifier/NSAPI)と同じであるIDとして、有利に利用され、アプリケーション層は、概してNSAPIを認識している。
【0243】
具体的実施例では、RRC層で形成され、またはそうでなければRRC層に提供され、かつRRC層で送信される、無線リソース解放指示が、以下の関連情報とともに表される。RRC層で具体化されたときの指示はまた、例えば、無線リソース解放指示とも呼ばれる。
【0244】
【表11】
図13は、図11に示されたグラフ表示の一部に図式的に示されたもの等の、PDPコンテキストと関連付けられた無線リソースの解放に従って生成される例示的信号伝達を表す、概して1137で示される、メッセージシーケンス図を図示する。解放は、UEによって、またはRNCあるいは他のUTRANエンティティにおいて、開始される。例えば、UEにおいて開始されると、UEは、UTRANに無線リソース解放指示を送信する。
【0245】
開始時に、セグメント1138によって示されるように、無線アクセスベアラ(RAB)解放要求がRNC/UTRANによって生成および送信され、SGSNに配信される。それに応じて、セグメント1140によって示される、RAB割当要求がRNC/UTRANに返信される。次いで、セグメント1142によって示されるように、UE802とUTRANとの間に延在する無線リソースが解放される。次いで、セグメント1144によって示されるように、応答が送信される。
【0246】
図14は、図13に示されたメッセージシーケンス図と同様である、概して1147で示される、メッセージシーケンス図を図示するが、ここでは、最終PDPコンテキストのリソースが解放される。開始時に、RNCがIu解放要求1150を生成し、SGSNに伝達され、それに対応して、SGSNは、セグメント1152によって示される、Iu解放コマンドを返信する。その後、セグメント1154によって示されるように、UEとUTRANとの間に形成される無線ベアラが解放される。そして、セグメント1156によって示されるように、RNC/UTRANは、SGSNにIu解放完了を返信する。
【0247】
図15は、PDPコンテキストに従って割り当てられる無線リソースを解放する本開示の実施形態の過程を表す、概して1162で示される、方法フロー図を図示する。
【0248】
ブロック1164によって示される、過程の開始後に、無線リソース解放指示が受信されたかどうかに関して、決定ブロック1166によって示される、判定が行われる。受信されていなければ、「いいえ」の分岐が終了ブロック1168に運ばれる。
【0249】
もし、逆に、無線アクセスベアラ解放が要求されていれば、「はい」の分岐が決定ブロック1172に運ばれる。決定ブロック1172では、解放される無線アクセスベアラが解放される最終無線アクセスベアラであるかどうかに関して、判定が行われる。もしそうでなければ、「いいえ」の分岐がブロック1178に運ばれ、好ましい状態が設定される。次いで、図13に示されたもの等の、または3GPP文書第23.060項の第9.2.5.1.1従属節で説明されるもの等の、無線アクセスベアラ解放手順が行われる。
【0250】
逆に、RABが最後に解放されるものであるという判定が決定ブロック1172において行われた場合、「はい」の分岐がブロック1186に運ばれ、図14に示されたもの等の、または3GPP文書第23.060項の第9.2.5.1.2従属節で説明されるもの等の、Iu解放手順が行われる。
【0251】
図16は、PDPコンテキストに従って割り当てられる無線リソースを解放する本開示の実施形態の過程を表す、概して1192で示される、方法フロー図を図示する。
【0252】
ブロック1194によって示される、過程の開始後に、解放するRAB(無線アクセスベアラ)があるかどうかに関して、決定ブロック1196によって示される決定が行われる。もしなければ、「いいえ」の分岐が終了ブロック1198に運ばれる。
【0253】
もし、逆に、無線アクセスベアラ解放が要求されていれば、「はい」の分岐が決定ブロック1202に運ばれる。決定ブロック1202では、解放される無線アクセスベアラが解放される最終無線アクセスベアラであるかどうかに関して、判定が行われる。もしそうでなければ、「いいえ」の分岐は、RABが設定されるブロック1204、好ましい状態が設定されるブロック1206、および、図13に示されたもの等の、または3GPP文書第23.060項の第9.2.5.1.1従属節で説明されるもの等の、無線アクセスベアラ解放手順が行われる、ブロック1208に運ばれる。
【0254】
逆に、RABが最後に解放されるものであるという判定が決定ブロック1202において行われた場合、「はい」の分岐がブロック1212に運ばれ、ドメインがPS(パケット交換)に設定される。次いで、ブロック1214によって示されるように、解放原因が設定される。そして、ブロック1216によって示されるように、信号伝達接続解放指示がDCCH上で設定される。図14に示されたもの等の、または3GPP文書第23.060項の第9.2.5.1.2従属節で説明されるもの等の、Iu解放手順が行われる。
【0255】
図17は、本開示の実施形態の操作の方法を表す、概して1224で示される方法を図示する。方法は、第1のパケットサービスおよび第2のパケットサービスの同時実行を提供する、無線通信システムにおける無線リソースの効率的な利用を促進する。第1に、ブロック1226によって示されるように、第1のパケットサービスおよび第2のパケットサービスのうちの選択されたパケットサービスと関連付けられた無線リソースを解放する選択の検出が行われる。次いで、ブロック1228によって示されるように、無線リソースを解放する選択の検出に対応して、無線リソース解放指示が送信される。
【0256】
次いで、ブロック1212では、無線リソース解放指示が検査され、次いで、ブロック1214では、無線ベアラの解放の付与が選択的に許可される。
【0257】
さらなる実施形態では、ネットワークは、ユーザ機器または別のネットワーク要素からの指示の受信と、ユーザ機器に対する無線リソースプロファイルとの両方に基づいて、遷移を開始してもよい。
【0258】
ユーザ機器またはネットワーク要素から受信されるような指示は、上記で説明される異なる遷移指示のうちのいずれかとなり得る。指示は、受動的となり得るため、単に、あまりバッテリ集約的ではない無線状態になるべきであるという空白指示となり得る。代替として、指示は、おそらく、経時的に、または多数の受信された指示にわたって、ネットワークが判定する、UEから送信された定期的な指示の一部、およびあまりバッテリまたは無線リソース集約的ではない無線状態になるべきであるというUEの無線リソースプロファイルとなり得る。代替として、指示は、動的となり得て、遷移する好ましい状態またはモードについてネットワーク要素に情報を提供することができる。上記とどうように、指示は、指示の原因(例えば、正常または異常)を含有することができる。さらなる実施形態では、指示は、異なる状態またはモードに遷移する能力についてユーザ機器が的確であるという確率、または指示を誘起するアプリケーションについての情報等の、無線リソースプロファイルについて他の情報を提供することができる。
【0259】
別のネットワーク要素からの指示は、例えば、メディアまたはプッシュ・トゥ・トークネットワークエンティティからの指示を含むことができる。この実施例では、指示は、トラッフィク条件が許容するときに遷移に関与しているネットワークエンティティ(例えば、UTRAN)に送信される。この第2のネットワークエンティティは、インターネットプロトコル(IP)レベルでトラフィックを見て、遷移指示を送信するかどうか、およびいつ送信するかを判定することができる。
【0260】
さらなる実施形態では、UEまたは第2のネットワーク要素からの指示は、明示的よりもむしろ暗示的となり得る。例えば、遷移指示は、アウトバウンドトラフィック測定値についてのデバイス状態報告から、遷移に関与しているネットワーク要素(例えば、UTRAN)によって暗示されてもよい。具体的には、状態報告は、いずれのアウトバウンドデータも存在しなければ、暗示的な指示として解釈され得る、無線リンクバッファ状態を含むことができる。そのような状態報告は、単独では何も要求または指示しないUEから繰り返し送信することができる、測定値となり得る。
【0261】
したがって、指示は、任意の信号となり得て、ユーザ機器のアプリケーションおよび無線リソースの全てに関する情報を提供する、アプリケーションベースの指示、無線リソースベースの指示、または複合指示となり得る。上記は、特定の指示に限定的となるように意図されておらず、当業者であれば、本方法および開示とともに任意の指示を使用できることを理解するであろう。
【0262】
ここで、図18を参照する。過程は、ステップ1801から開始し、ネットワーク要素が指示を受信するステップ1810に進む。
【0263】
いったんネットワークがステップ1810で指示を受信すると、過程は、ユーザ機器に対する無線リソースプロファイルが随意でチェックされる、ステップ1820に進む。
【0264】
本明細書で使用される場合、「無線リソースプロファイル」という用語は、ネットワーク要素の要件に応じて、種々の状況に該当し得る広義語となるように意図されている。広義語では、無線リソースプロファイルは、ユーザ機器によって利用される無線リソースについての情報を含む。
【0265】
無線リソースプロファイルは、静的プロファイル要素および動的または交渉型プロファイル要素のいずれか一方または両方を含むことができる。そのような要素は、遷移プロファイル内にあるか、または遷移プロファイルから離れている、無線リソースプロファイルの一部となり得て、かつ交渉型または静的となり得る、「時間窓あたりの阻止期間および/または最大指示/要求メッセージ」値を含むことができる。
【0266】
静的プロファイル要素は、無線リソース(例えば、RABまたはRB)のサービスの質、PDPコンテキスト、ネットワークが知っているAPN、および加入者プロファイルのうちの1つ以上を含んでもよい。
【0267】
当業者によって理解されるように、サービスの質の種々のレベルが、無線リソースについて存在することができ、サービスの質のレベルは、異なる状態またはモードに遷移するかどうかについて、ネットワークに情報を提供することができる。したがって、サービスの質がバックグラウンドであれば、ネットワーク要素は、サービスの質が双方向に設定された場合よりも容易に、アイドルに遷移することを考慮してもよい。さらに、複数の無線リソースが同じサービスの質を有する場合、これは、モバイルデバイスをより好適な状態またはモードに遷移させるか、または無線リソースを解除するかどうかについて、ネットワークに指示を提供することができる。いくつかの実施形態では、1次または2次PDPコンテキストは、異なるサービスの質を有することができ、それはまた、状態/モード遷移を行うかどうかについての決定にも影響を及ぼし得る。
【0268】
さらに、APNは、ネットワークに、PDPコンテキストが利用する典型的サービスについての情報を提供することができる。例えば、APNがxyz.comであれば、その場合、xyz.comは、典型的にはEメール等のデータサービスの提供に使用され、これは、異なる状態またはモードを遷移するか否かについて、ネットワークに指示を提供することができる。これはさらに、ルーティング特性を示すことができる。
【0269】
具体的には、本方法および装置は、種々の状態間で遷移プロファイルを設定するために、UEによって特定されるアクセスポイント名(Access Point Name/APN)を利用することができる。これは、UEの加入を説明する別の方法であってもよい。理解されるように、ホームロケーションレジスタ(Home Location Register/HLR)が、加入者についての関連情報を記憶してもよく、無線ネットワークコントローラ(RNC)にUEの加入を提供することができる。加入情報を中央で記憶するために、他のネットワークエンティティも使用することができる。HLRを使用しても、または他のネットワークエンティティを使用しても、情報は、好ましくは、加入者情報をデータ交換中に使用される関連物理パラメータにマップする、RNCおよびSGSN等の他のネットワーク構成要素にプッシュ配信される。
【0270】
UTRANは、種々のAPNまたはQoSパラメータを特定の遷移プロファイルに結び付けることができる、データベースまたはテーブルへのアクセスを含むか、または有することができる。したがって、UEが常時オンデバイスである場合、これはAPNから明白となり、そのAPNに対する適切な遷移プロファイルは、無線リソースプロファイルの一部としてUTRANで記憶することができ、または、UTRANによって遠隔でアクセス可能となり得る。同様に、QoSまたはQoSパラメータの一部分が使用されるか、または専用メッセージがプロファイルとともに送信される場合、これは、データベースクエリまたはテーブルの参照に基づいて、特定の遷移プロファイルが所望されることをUTRANに知らせることができる。加えて、RRC接続状態遷移プロファイルを越えた数多くの動作を、この手段によって特定することができる。これらは、以下を含むが、それらに限定されない。
速度適応アルゴリズム(ステップの周期性/ステップサイズ)、
初期許可無線ベアラ、
最大許可無線ベアラ、
呼設定時間の最小限化(トラフィック量測定等の不必要なステップの回避)、および
エアインターフェース(GPRS/EDGE/UMTS/HSDPA/HSUPA/LTE等)。
【0271】
さらに、1次コンテキスト、2次コンテキスト等の、異なるQoS要件を有するが、同じAPN IPアドレスを共有する、複数のPDPコンテキストがある場合、異なる遷移プロファイルを各コンテキストに使用することができる。これは、QoSまたは専用メッセージを通してUTRANに信号伝達することができる。
【0272】
複数のアクティブPDPコンテキストが同時に利用される場合、コンテキスト間の最小公分母を使用することができる。RRC状態遷移については、1つのアプリケーションが、システムが早急にCELL_DCH状態からCELL_PCHまたはアイドル状態になる、遷移プロファイルと関連付けられる第1のPDPコンテキストと、システムがより長くCELL_DCH状態にとどまるものである、遷移プロファイルと関連付けられる第2のPDPコンテキストとを有する場合、CELL_DCH状態がより長く維持される第2のプロファイルが、第1のプロファイルに優先する。
【0273】
当業者によって理解されるように、最小公分母は、2つの異なる方法で考慮することができる。本明細書で使用されるような最小公分母は、異なる状態に遷移する前に必要とされる最長の時間を暗示する。第1の実施形態では、最小公分母は、有効化されたPDPの中の最小のものであってもよい。代替実施形態では、最小公分母は、実際にアクティブ無線リソースを有するPDPの中の最小のものであってもよい。無線リソースは、多数の異なる様式で多重化することができるが、最終結果は同じである。
【0274】
そのような方法の例示的な事例は、常時オンデバイスについて描くことができる。説明されるように、種々のAPNまたはQoSパラメータは、常時オンに対する特定の動作に結び付けることができる。「常時オン」プロファイルに基づいて望ましくてもよい、最初に許可された無線リソースを考慮されたい。ここで、ネットワークは、データバーストが、Eメール等の常時オンアプリケーションについて短く集中的であることを「知る」手段を有する。当業者にとって、この情報を考慮すると、ネットワーク上のトランキング効率のためにコード空間を節約する誘因がないことが明確に分かる。したがって、他のユーザのために十分なコード空間を取っておかないという危険性がほとんどなく、最大速度が常時オンデバイスに割り当てられてもよい。加えて、UEは、より急速にデータを受信する恩恵を受け、また、より短い「オン時間」により、バッテリ寿命を節約する。再度、当業者にとって、データ転送速度にかかわらず、電力増幅器が完全にバイアスされるため、高データ転送速度は電流引き込みにほとんど影響を及ぼさない。
【0275】
上記の実施形態では、UEに対する所与のRRC接続のために、異なるアプリケーションについて割り当てられる無線リソースに対するリソース制御プロファイルを判定するために、UTRANによって参照テーブルを使用することができる。RNCが、利用可能なより最新式のトラフィックリソース(すなわち、許可することができるデータ転送速度)を有するため、プロファイルは、ユーザ加入に基づき、HLR等のネットワークエンティティにおいて、または代替としてRNCにおいて、ネットワーク側に記憶することができる。より高速のデータ転送速度を達成することができる場合、より短いタイムアウトが可能であってもよい。
【0276】
APNの代わりに、パケットデータプロトコル(Packet Data Protocol/PDP)コンテキスト活性化または修正PDPコンテキストにおいて設定されるサービスの質(Quality of Service/QoS)パラメータ等の、他の代替案を使用することができる。QoSフィールドはさらに、同じAPNを共有する複数のPDPコンテキスト、または遷移プロファイルを設定する加入プロファイルの場合に、QoS「割当保持優先順位(トラフィックデータ量を推測するために、サービスデータ単位を使用することができる)」を含むことができる。さらなる代替案は、リソース制御プロファイルを信号伝達する上記の指示メッセージ等の専用メッセージ、および時間窓あたりの阻止期間および/または最大指示/要求メッセージ値等の情報を含む。
【0277】
無線リソースプロファイルに含まれる遷移プロファイルはさらに、アプリケーションの種類に基づいて、UEの状態を全く遷移させるべきかどうかを含むことができる。具体的には、ユーザ機器がデータモデムとして使用されている場合、遷移指示が送信されないように、選好がユーザ機器上で設定されてもよく、または、選好の知識がネットワークにおいて維持される場合、データモデムとして使用されている間にUEから受信される任意の遷移指示は、無視されるべきである。したがって、ユーザ機器上で実行されているアプリケーションの性質を、無線リソースプロファイルの一部として使用することができる。
【0278】
遷移プロファイルのさらなるパラメータは、遷移の種類を伴うことができる。具体的には、UMTSネットワークにおいて、ユーザ機器は、種々の理由で、アイドル状態になるよりもむしろCell_PCH状態になることを好んでもよい。1つの理由は、データが送信または受信される必要がある場合に、UEがより早急にCell_DCH状態に接続する必要があり、したがって、Cell_PCH状態になることは、Cell_PCH状態への早急な遷移を依然として提供しながら、いくつかのネットワーク信号伝達およびバッテリリソースを節約するという点となり得る。上記は、非UMTSネットワークで同等に適用可能であり、種々の接続状態とアイドル状態との間の遷移プロファイルを提供してもよい。
【0279】
遷移プロファイルはまた、時間窓あたりの阻止期間および/または最大指示/要求メッセージ、遅延タイマ、および非活動タイマを含むが、それらに限定されない、種々のタイマを含んでもよい。遅延タイマは、新規状態またはモードに遷移する前にネットワーク要素が待つ期間を提供する。理解されるように、たとえアプリケーションが特定の期間にわたって活動していなくても、さらなるデータがアプリケーションから受信または伝送されないことを確実にするために、遅延が有益であってもよい。非活動タイマは、データがプリケーションによって受信または送信されない所定の期間を測定することができる。非活動タイマが期限切れになる前にデータが受信された場合、典型的には、非活動タイマはリセットされる。いったん非活動タイマが期限切れになると、ユーザ機器は、ネットワークにステップ1810の指示を送信してもよい。代替として、ユーザ機器は、ステップ1810の指示を送信する前に、遅延タイマについて定義される期間等の、ある期間にわたって待ってもよい。
【0280】
さらに、遅延タイマ、または時間窓あたりの阻止期間および/または最大指示/要求メッセージは、ネットワーク要素に提供されるプロファイルに基づいて変動することができる。したがって、異なるモードまたは状態への遷移を要求したアプリケーションが、Eメールアプリケーション等の第1の種類のアプリケーションである場合、ネットワーク要素上の遅延タイマを第1の遅延時間に設定することができ、一方で、アプリケーションが、インスタントメッセージングアプリケーション等の第2の種類である場合、遅延タイマを第2の値に設定することができる。時間窓あたりの阻止期間および/または最大指示/要求メッセージ、遅延タイマ、または非活動タイマの値はまた、特定のPDPに利用されるAPNに基づいて、ネットワークによって導出することもできる。
【0281】
当業者によって理解されるように、非活動タイマは、同様に、利用されるアプリケーションに基づいて変動することができる。したがって、Eメールアプリケーションが別個のメッセージを予期しており、その後にデータを受信しない場合があるため、Eメールアプリケーションは、ブラウザアプリケーションよりも短い非活動タイマを有してもよい。逆に、ブラウザアプリケーションは、より長い遅延後でさえもデータを利用し、したがって、より長い非活動タイマを必要としてもよい。
【0282】
遷移プロファイルはさらに、ユーザ機器が正しく遷移を要求している確率を含んでもよい。これは、特定のユーザ機器またはユーザ機器上のアプリケーションの正確率についてまとめられた統計に基づくことができる。
【0283】
遷移プロファイルはさらに、種々の不連続受信(DRX)時間値を含んでもよい。さらに、DRX時間に対する進行プロファイルを、遷移プロファイルの中で提供することができる。
【0284】
遷移プロファイルは、アプリケーションごとに定義することができるか、または、ユーザ機器上の種々のアプリケーションの複合物となり得る。
【0285】
当業者によって理解されるように、遷移プロファイルは、無線リソースが割り当てられると動的に作成または修正することができ、加入、PS登録、PDP有効化、RABまたはRB有効化の状態で終了するか、またはPDPあるいはRAB/RBについてオンザフライで変更することができる。遷移プロファイルはまた、ステップ1810の指示の一部にもなり得る。この場合、ネットワークは、好ましいRRC状態指示を考慮して、遷移を可能にするかどうか、およびどの状態/モードにするかを判定してもよい。修正は、とりわけ、利用可能なネットワークリソース、トラフィックパターンに基づいて生じることができる。
【0286】
したがって、無線リソースプロファイルは、静的および/または動的フィールドから成る。特定のネットワークによって使用される無線リソースプロファイルは、他のネットワークと異なってもよく、上記の説明は、本方法およびシステムを限定するように意図されていない。具体的には、無線リソースプロファイルは、上記で説明される種々の要素を含み、かつ除外することができる。例えば、場合によっては、無線リソースプロファイルは、単に、特定の無線リソースのサービスの質を含み、他の情報を含まない。他の場合においては、無線リソースプロファイルは、遷移プロファイルのみを含む。依然として他の場合においては、無線リソースプロファイルは、とりわけ、サービスの質、APN、PDPコンテキスト、遷移プロファイルの全てを含む。
【0287】
随意で、無線リソースプロファイルに加えて、ネットワーク要素はまた、不必要な遷移を回避するために防護対策を利用することもできる。そのような防護対策は、所定期間に受信される指示の数、受信される指示の総数、トラフィックパターン、および履歴データを含むことができるが、それらに限定されない。
【0288】
所定期間に受信される指示の数は、遷移が発生するべきではないことをネットワークに示すことができる。したがって、ユーザ機器が、例えば、30秒の期間内に5つの指示を送信した場合、ネットワークは、指示を無視し、遷移を行うべきではないと考慮してもよい。代替として、ネットワークは、無期限に、または、ある構成された期間あるいは所定の期間にわたって、さらなる指示を送信すべきではないことをUEに示すことを判定してもよい。これは、UE上のいずれの「時間窓あたりの阻止期間および/または最大指示/要求メッセージ」とも無関係となり得る。
【0289】
さらに、UEは、構成された期間、所定の期間、交渉された期間にわたって、さらなる指示を送信しないように構成することができる。UE構成は、上記で説明されるネットワーク側の防護対策を除くことができる。
【0290】
トラフィックパターンおよび履歴データは、遷移が発生すべきではないという指示をネットワークに提供することができる。例えば、ユーザが過去に月曜から金曜の午前8:30から8:35の間に有意量のデータを受信していた場合、指示が木曜の午前8:32に受信されると、さらなるデータが午前8:35よりも前にあり得るため、ネットワークは、ユーザ機器を遷移するべきではないと決定してもよい。
【0291】
複数の無線リソースがユーザ機器について割り当てられる場合、ネットワークは、ユーザ機器に対する完全無線リソースプロファイルを考慮する必要があってもよい。この場合、ユーザ機器に対する無線リソースプロファイルを検査することができ、複合遷移決定を行うことができる。1つまたは複数の無線リソースの無線リソースプロファイルに基づいて、ネットワークは、遷移が行われるべきか否かを決定することができる。
【0292】
一実施形態では、ネットワークは、ステップ1810で指示を受信したとき、および随意で、ステップ1820で1つまたは複数の無線リソースプロファイルを検査したときに、どのように進むかについて複数の選択肢を有する。
【0293】
第1の選択肢は、何もしないことである。ネットワークは、遷移が保証されないことを決定し、したがって、遷移するユーザ機器指示を受け入れなくてもよい。当業者によって理解されるように、状態が変更されないため、具体的には、遷移が誘起されないため、何もしないことにより、ネットワーク信号伝達を節約する。
【0294】
第2の選択肢は、デバイスの状態を変化させることである。例えば、UMTSネットワークでは、デバイスの状態は、Cell_DCHからCell_PCHに変化してもよい。非UMTSネットワークでは、状態遷移は、接続状態の間で発生してもよい。当業者によって理解されるように、状態を変化させることにより、アイドルモードへの遷移と比較すると、コアネットワーク信号伝達の量が低減する。Cell_PCH状態が専用チャネルを必要としないため、状態を変化させることにより、無線リソースを節約することもできる。また、Cell_PCHは、あまりバッテリ集約的ではない状態であり、UEがバッテリ電力を保存することを可能にする。
【0295】
ネットワークの第3の選択肢は、UEを同じ状態で保つが、特定のAPNまたはPDPコンテキストと関連付けられた無線リソースを解放することである。接続がその現在の状態で維持され、再確立されることを必要としないため、このアプローチは、無線リソースおよび信号伝達を節約する。しかしながら、UEバッテリ寿命が懸念である状態にとっては、あまり好適ではない場合がある。
【0296】
ネットワークの第4の選択肢は、UEをアイドルモードに遷移させることである。特に、UMTSおよび非UMTSの両方では、ネットワークは、接続モードからアイドルモードになってもよい。理解されるように、全く接続が維持されないため、これは無線リソースを節約する。それはさらに、ユーザ機器上のバッテリ寿命を節約する。しかしながら、接続を再確立するために、より大量のコアネットワーク信号伝達が必要とされる。
【0297】
ネットワークの第5の選択肢は、データ転送速度割当を変更することであり、それは、無線リソースを節約し、典型的には、より多くのユーザがネットワークを利用できるようにする。
【0298】
他の選択肢が、当業者にとって明白となるであろう。
【0299】
5つ以上の選択肢のうちのどれを利用するかについてのネットワークの決定は、ネットワークによって異なる。いくつかの過負荷ネットワークは、無線リソースを保存することを好んでもよく、したがって、上記の第3、第4、または第5の選択肢を選択してもよい。他のネットワークは、信号伝達を最小限化することを好み、したがって、上記の第1または第2の選択肢を選択してもよい。
【0300】
決定は図18のステップ1830で示され、ユーザ機器に対する無線リソースプロファイルとともに、ネットワーク選好に基づいてもよい。決定は、ユーザ機器が、別の状態、例えば、あまりバッテリ集約的ではない状態に遷移したいという、ユーザ機器からの指示を受信する、ネットワークによって誘起される。
【0301】
ここで、図19を参照する。図19は、上記の図18に示された決定を行うように適合される、簡略化したネットワーク要素を図示する。ネットワーク要素1910は、ユーザ機器と通信するように適合される、通信サブシステム1920を含む。当業者によって理解されるように、通信サブシステム1920は、ユーザ機器と直接通信する必要がなく、ユーザ機器を往復する通信のための通信経路の一部となり得る。
【0302】
ネットワーク要素1910はさらに、プロセッサ1930および記憶部1940を含むことができる。記憶部1940は、ネットワーク要素1910によってサービス提供されている各ユーザ機器に対する、事前構成された、または静的な無線リソースプロファイルを記憶するように構成される。プロセッサ1930は、通信サブシステム1920による指示の受信時に、ユーザ機器に対する無線リソースプロファイルを考慮するように、およびユーザ機器の遷移に関するネットワークアクションを決定するように適合される。当業者によって理解されるように、通信サブシステム1920によって受信される指示はさらに、ユーザ機器に対する無線リソースプロファイルの一部分または全てを含むことができ、それは次いで、任意の遷移に関するネットワーク決定を行うために、プロセッサ1930によって利用される。
【0303】
したがって、上記に基づいて、ネットワーク要素は、遷移が順序正しいかもしれない(例えば、データ交換が完了したとき、および/またはUEにおいてさらなるデータが見込まれない等)という、ユーザ機器からの指示を受信する。この指示に基づいて、ネットワーク要素は、随意で、静的および動的プロファイル要素の両方を含むことができる、ユーザ機器の無線リソースプロファイルをチェックする。ネットワーク要素はさらに、不必要な遷移が発生していないことを確実にするように、防護対策をチェックしてもよい。次いで、ネットワーク要素は、何もしないこと、または異なるモードあるいは状態に遷移すること、または無線リソースを解除することを決定することができる。理解されるように、これは、ネットワークに、その無線リソースのさらなる制御を提供し、単なるユーザ機器選好よりもむしろネットワーク選好に基づいて、ネットワークが遷移決定を構成することを可能にする。さらに、場合によっては、ネットワークは、遷移するかどうかに関して、デバイスよりも多くの情報を有する。例えば、ユーザ機器には、アップストリーム通信の知識があり、これに基づいて、接続が解除されてもよいことを決定してもよい。しかしながら、ネットワークは、ユーザ機器に対するダウンストリーム通信を受信しており、したがって、接続を解除できないことを自覚している場合がある。この場合、近い将来に、いずれのデータもユーザ機器について受信されないという、さらなる確信を持って、ネットワークを提供するために、遅延タイマを使用して遅延を導入することもできる。
【0304】
本明細書で説明される実施形態は、本開示の技法の要素に対応する要素を有する、構造、システム、または方法の実施例である。この書面による説明は、当業者が、同様に本開示の技法の要素に対応する代替要素を有する実施形態を作製および使用することを可能にしてもよい。したがって、本開示の技法の対象とする範囲は、本明細書で説明されるような本開示の技法と異ならない、他の構造、システム、または方法を含み、さらに、本明細書で説明されるような本開示の技法とごくわずかに異なる、他の構造、システム、または方法を含む。
【特許請求の範囲】
【請求項1】
本願明細書に記載されたシステム。
【請求項1】
本願明細書に記載されたシステム。
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図2】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【公開番号】特開2013−59084(P2013−59084A)
【公開日】平成25年3月28日(2013.3.28)
【国際特許分類】
【出願番号】特願2012−241734(P2012−241734)
【出願日】平成24年11月1日(2012.11.1)
【分割の表示】特願2010−533398(P2010−533398)の分割
【原出願日】平成20年11月13日(2008.11.13)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.WCDMA
2.GSM
【出願人】(500043574)リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Research In Motion Limited
【住所又は居所原語表記】295 Phillip Street, Waterloo, Ontario N2L 3W8 Canada
【Fターム(参考)】
【公開日】平成25年3月28日(2013.3.28)
【国際特許分類】
【出願日】平成24年11月1日(2012.11.1)
【分割の表示】特願2010−533398(P2010−533398)の分割
【原出願日】平成20年11月13日(2008.11.13)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.WCDMA
2.GSM
【出願人】(500043574)リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Research In Motion Limited
【住所又は居所原語表記】295 Phillip Street, Waterloo, Ontario N2L 3W8 Canada
【Fターム(参考)】
[ Back to top ]