ＵＭＴＳネットワークで解放理由指示を信号伝達する方法およびシステム
【課題】ユーザ設備と無線アクセスネットワークとの間の無線リソース制御をするために、両者間での信号伝達解放指示理由を処理する方法を提供すること。
【解決手段】ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法であって、ａ．該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、ｂ．該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、ｃ．該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、ｄ．該信号伝達接続解放指示を該無線ネットワークで受信するステップと、ｅ．該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する、方法。
【解決手段】ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法であって、ａ．該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、ｂ．該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、ｃ．該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、ｄ．該信号伝達接続解放指示を該無線ネットワークで受信するステップと、ｅ．該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（出願の分野）
本出願は、ユーザ設備（ＵＥ）とユニバーサル陸上無線アクセスネットワーク（ＵＴＲＡＮ）との間の無線リソース制御に関し、特に、ＵＭＴＳネットワーク内の既存の信号伝達接続の解放に関する。
【背景技術】
【０００２】
（背景）
ユニバーサル移動電気通信システム（ＵＭＴＳ）は、テキスト、デジタル化された音声、映像、およびマルチメディアを送信する広帯域パケットベースのシステムである。これは、第三世代に対する標準として認知され、広帯域符号分割多重アクセス（Ｗ−ＣＤＭＡ）に一般的に基づく。
【０００３】
ＵＭＴＳネットワークにおいて、プロトコルスタックの無線リソース制御（ＲＲＣ）パーツは、ＵＥとＵＴＲＡＮとの間の無線リソースの割り当て、構成、および解放を担う。このＲＲＣプロトコルは、詳細には、３ＧＧＰの仕様書ＴＳ ２５．３３１に記載されている。ＵＥが入り得る２つの基本的モードは、「アイドルモード」および「ＵＴＲＡ接続モード」として定義されている。ＵＴＲＡは、ＵＭＴＳ陸上無線アクセスを略したものである。アイドルモードにおいて、ＵＥが任意のユーザデータを送信したいときはいつでも、あるいはＵＴＲＡＮまたはサービングＧＰＲＳサポートノード（ＳＧＳＮ）が、ページングに応答して、それをページングしてプッシュサーバのような外部データネットワークから受信するときはいつでも、ＵＥは、ＲＲＣ接続をリクエストするように要求される。アイドルモードおよび接続モードの挙動は、３ＧＰＰの仕様書のＴＳ ２５．３０４およびＴＳ ２５．３３１に詳細に記載されている。
【０００４】
ＵＴＲＡ ＲＲＣ接続モードにおいて、デバイスは、４つの状態の１つであり得る。これらは、
ＣＥＬＬ＿ＤＣＨ：専用チャネルが、データ交換するために、この状態で、アップリンクおよびダウンリンク中のＵＥに割り当てられる。ＵＥは、３ＧＰＰ ２５．３３１に概略されたアクションを実行しなくてはならない。
ＣＥＬＬ＿ＦＡＣＨ：この状態において、ユーザ設備には専用チャネルは割り当てられない。その代わりに、共通チャネルが、少量のバースティ（ｂｕｒｓｔｙ）なデータを交換するために使用される。ＵＥは、３ＧＰＰ ２５．３３１（３ＧＰＰ ＴＳ ２５．３０４で規定されるセル選択プロセスを含む）に概略されるようなアクションを実行しなくてはならない。
ＣＥＬＬ＿ＰＣＨ：ＵＥは、不連続受信（ＤＲＸ）を使用して、ページングインジケータチャネル（ＰＩＣＨ）を介する放送メッセージとページングとをモニタする。アップリンク活動は可能ではない。ＵＥは、３ＧＰＰ ２５．３３１（３ＧＰＰ ＴＳ ２５．３０４で規定されるようなセル選択プロセスを含む）に概略されるようなアクションを実行しなくてはならない。ＵＥは、セル再選択の後に、ＣＥＬＬ ＵＰＤＡＴＥ手順を実行しなくてはならない。
ＵＲＡ＿ＰＣＨ：ＵＥは、不連続受信（ＤＲＸ）を用い、ページングインディケータチャネル（ＰＩＣＨ）を介する放送メッセージおよびページングをモニタする。アップリンク活動は可能ではない。ＵＥは、３ＧＰＰ ２５．３３１（３ＧＰＰ ＴＳ ２５．３０４で規定されるようなセル選択プロセスを含む）に概略されるようなアクションを実行しなくてはならない。ＵＲＡ ＵＰＤＡＴＥ手順が、ＵＴＲＡＮ登録エリア（ＵＲＡ）再選択をのみ介してトリガされる点を除いて、この状態はＣＥＬＬ＿ＰＣＨに類似する。
【０００５】
アイドルモードから接続モードへの移行とこの逆の移行とは、ＵＴＲＡＮによって制御される。アイドルモードＵＥが、ＲＲＣ接続をリクエストするとき、ネットワークは、ＵＥをＣＥＬＬ＿ＤＣＨまたはＣＥＬＬ＿ＦＡＣＨ状態に移動させるかどうかを判断する。ＵＥがＲＲＣ接続モードにあるとき、この場合も、ＲＲＣ接続を解放するときを決定するのは、またネットワークである。ネットワークは、接続を解放する前に、あるいは場合によっては接続を解放する代わりに、ＵＥを一つのＲＲＣ状態から別の状態に移動させ得る。状態移行は、ＵＥとネットワークとの間でのデータ活性または不活性によって、典型的にはトリガされる。ネットワークは、所与のアプリケーションに対するデータ交換がいつ完了したかを知り得ないので、ネットワークは、ＵＥへの／からのさらなるデータを期待して、ＲＲＣ接続をしばらくの間、典型的には保つ。これは、コール設定および引き続く無線ベアラ設定の待ち時間を減らすために、典型的に行われる。ＲＲＣ接続解放メッセージは、ＵＴＲＡＮによって送信され得るのみである。このメッセージは、ＵＥとＵＴＲＡＮとの間の信号リンク接続および全ての無線ベアラを解放する。
【０００６】
上記における問題は、ＵＥ上のアプリケーションがそのデータ移行を完了し、さらなるデータ交換を一切期待できない場合ですら、そのアプリケーションは、ネットワークがＵＥを正しい状態に移動させることを、ネットワークを待っていることである。ネットワークは、ＵＥ上のアプリケーションが自身のデータ交換を完了した事実に気付いていないことさえあり得る。例えば、ＵＥ上のアプリケーションは、それ自身の承認ベースのプロトコルを使用して、ＵＭＴＳコアネットワークに接続されるそのアプリケーションサーバとデータ交換し得る。例えば、自身に保証された配信をインプリメントするＵＤＰ／ＩＰを介してランするアプリケーションである。そのような場合において、ＵＥは、アプリケーションサーバが全てのデータパケットを送信または受信したかどうかを知っており、任意のさらなるデータ交換が生じるかどうかを決定するためにより良い位置にあり、そして、それゆえ、いつパケットサービス（ＰＳ）ドメインと関連するＲＲＣ接続を終了するかを決定する。ＵＴＲＡＮは、いつＲＲＣ接続状態が異なる状態に、あるいはアイドルモードへと変化するかを制御するので、また、ＵＴＲＡＮがＵＥと外部サーバとの間におけるデータ伝送の状態に気付いていないという事実により、ＵＥは、要求される状態またはモードよりも、さらに高いデータレートおよび強いバッテリ状態に留まることになり、それによって、バッテリ寿命を使い果たす。このことは、また無線ベアラリソースが不必要に使用中のまま保たれるという事実によって、ネットワークリソースを無駄使いさせる結果となる。
【０００７】
上述に対する一つの解決策は、ＵＥがデータトランザクションを終了されたと、ＵＥが認識するときに、ＵＥにＵＴＲＡＮへ信号伝達解放指示（ｓｉｇｎａｌｉｎｇ ｒｅｌｅａｓｅ ｉｎｄｉｃａｔｉｏｎ）を送信するようにさせることである。３ＧＰＰ ＴＳ ２５．３３１仕様書の８．１．１４．３節に従うと、ＵＴＲＡＮは、ＵＥから信号伝達接続解放指示を受信すると、信号伝達接続を解放し得、その結果、ＵＥはアイドルモードに移行する。上述における問題は、信号伝達解放指示が、警告であると考慮され得ることである。ネットワークは、ＧＭＭサービスリクエストの失敗、ＲＡＵの失敗、あるいはアタッチの失敗が生じたときに、典型的には、信号伝達解放指示を期待するのみである。ＵＥが信号伝達解放をリクエストするときに警告を発することは、ネットワークでの性能モニタおよび警告モニタを非効率なものとする結果になる。
【発明の概要】
【課題を解決するための手段】
【０００８】
本発明は、以下の手段を提供する。
【０００９】
（項目１）
ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法であって、
ａ．該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、
ｂ．該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、
ｃ．該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、
ｄ．該信号伝達接続解放指示を該無線ネットワークで受信するステップと、
ｅ．該理由をフィルタリングし、警告を発するかどうかを判断するステップと
を包含する、方法。
【００１０】
（項目２）
上記理由は、異常な状態である、項目１に記載の方法。
【００１１】
（項目３）
上記異常な状態は、タイマの時間切れである、項目２に記載の方法。
【００１２】
（項目４）
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびＧＭＭサービスリクエストタイマからなる群から選択される、項目３に記載の方法。
【００１３】
（項目５）
上記理由は、ＰＳデータセッションを終了して、それによってアイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目１に記載の方法。
【００１４】
（項目６）
上記フィルタリングするステップは、上記理由が異常な状態であるとき、警告を発する、項目１に記載の方法。
【００１５】
（項目７）
上記フィルタリングするステップは、上記理由が上記ユーザ設備によるアイドル移行リクエストであるとき、上記信号伝達接続解放指示を無視する、項目１に記載の方法。
【００１６】
（項目８）
信号伝達解放指示理由を処理するのに適合したシステムであって、該システムは、
ａ．ユーザ設備であって、該ユーザ設備は、ネットワークと通信するのに適合した無線を含む無線サブシステムと；デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと；メモリと；ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有する、ユーザ設備であって、
ｉ．信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、
ｉｉ．該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付する手段と、
ｉｉｉ．該添付信号伝達接続解放指示を該無線ネットワークに送信する手段と
を有することによって特徴付けられる、ユーザ設備と、
ｂ．該ユーザ設備と通信するのに適合した無線ネットワークであって、
ｉ．該信号伝達接続解放指示を受信する手段と、
ｉｉ．該理由をフィルタリングし、警告を発するかどうかを判断する手段と
によってさらに特徴付けられる、無線ネットワークと
を備える、システム。
【００１７】
（項目９）
上記理由は、異常な状態である、項目８に記載のシステム。
【００１８】
（項目１０）
上記異常な状態は、タイマの時間切れである、項目９に記載のシステム。
【００１９】
（項目１１）
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびＧＭＭサービスリクエストタイマからなる群から選択される、項目１０に記載のシステム。
【００２０】
（項目１２）
上記理由は、ＰＳデータセッションを終了し、アイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目１１に記載のシステム。
【００２１】
（項目１３）
上記フィルタリングする手段は、上記理由が異常な状態であるとき、警告を発するのに適合する、項目８に記載のシステム。
【００２２】
（項目１４）
上記フィルタリングする手段は、上記理由が上記ユーザ設備によるアイドル移行リクエストであるとき、上記信号伝達接続解放指示を無視するのに適合する、項目８に記載のシステム。
【００２３】
（項目１５）
無線ネットワークで改善された警告を追跡するために、ユーザ設備で信号伝達解放指示理由を処理する方法であって、
ａ．信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、
ｂ．該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、
ｃ．該理由が添付された該添付信号伝達接続解放指示を送信し、これによって、該信号伝達接続解放指示の該理由を識別する該信号伝達接続解放をリクエストする、ステップと
を包含する、方法。
【００２４】
（項目１６）
上記理由は、異常な状態である、項目１５に記載の方法。
【００２５】
（項目１７）
上記異常な状態は、タイマの時間切れである、項目１６に記載の方法。
【００２６】
（項目１８）
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびＧＭＭサービスリクエストタイマからなる群から選択される、項目１７に記載の方法。
【００２７】
（項目１９）
上記理由は、ＰＳデータセッションを終了し、アイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目１５に記載の方法。
【００２８】
（項目２０）
ネットワーク内で、信号伝達解放指示理由を提供するのに適合したユーザ設備であって、該ユーザ設備は、該ネットワークと通信するのに適合した無線を含む無線サブシステムと；デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと；メモリと；ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有し、該ユーザ設備は、
ａ．信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、
ｂ．該信号伝達接続解放指示に、該信号伝達接続解放指示に対する理由を添付する手段と、
ｃ．該理由を含む該添付信号伝達接続解放指示を送信し、これによって、該信号伝達接続解放指示の該理由を該信号伝達接続解放指示とともに識別する手段と
を有することによって特徴付けられる、ユーザ設備。
【００２９】
（項目２１）
信号伝達接続の解放を容易にするためのユーザ設備用装置であって、該装置は、
ａ．信号伝達接続解放指示が、送信されるべきかどうかをチェックするように構成されたチェッカと、
ｂ．信号伝達接続解放指示が送信されるべきであるという該チェッカによる指示に応答して、該信号伝達接続解放指示を送信するように構成された信号伝達接続解放指示センダであって、該信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む信号伝達解放指示を含む、信号伝達接続解放指示センダと
を備える、装置。
【００３０】
（項目２２）
上記チェッカは、上記信号伝達接続解放指示を送信するのに引き続き、該信号伝達接続解放指示の配信を確認する前に、上記ユーザ設備の信号伝達接続が必要とされるかどうかをチェックするようにさらに構成される、項目２１に記載の装置。
【００３１】
（項目２３）
上記信号伝達接続解放指示センダは、上記信号伝達接続解放指示を再送信するようにさらに構成される、項目２２に記載の装置。
【００３２】
（項目２４）
信号伝達接続解放指示によって、動作するネットワーク装置であって、該ネットワーク装置は、
ａ．該信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験して、該信号伝達解放指示理由フィールドが異常な状態を指示するかどうかをチェックするように構成された試験機と、
ｂ．該試験機による試験が、該信号伝達解放指示理由フィールドが該異常な状態を指示すると判断する場合、警告を選択的に生成するように構成された警告生成器と
を備える、ネットワーク装置。
【００３３】
（項目２５）
上記ネットワーク装置は、複数のロジカル層を備え、上記試験機は、該複数のロジカル層の第一のロジカル層で具現化され、該試験機は、該複数のロジカル層の第二のロジカル層に、信号伝達接続解放をリクエストするようにさらに構成される、項目２４に記載のネットワーク装置。
【００３４】
（摘要）
ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法およびシステムであって、該方法は、該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、該信号伝達接続解放指示を該無線ネットワークで受信するステップと、該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する、方法。
【００３５】
（詳細な説明）
本システムおよび方法は、ＲＲＣ接続モードから、より効率的なバッテリ状態またはモードへ移行させる一方で、信号伝達解放指示の理由がＵＥのアイドル移行リクエストである場合、ネットワークが、信号伝達解放指示を警告と考慮しないこと保証することを提供する。特に、本方法および装置は、特定されたコアネットワークドメインに対する信号接続の終了をＵＥが開始すること、または、移行が一つの接続状態から他の接続状態へと生じるべきであるとＵＴＲＡＮに指示することのいずれかに基づいて移行を提供する。以下の説明は、ＵＭＴＳの例示的なインプリメンテーションに関して記載される。しかしながら、本発明の教示は、他の無線通信システムにも同様に適用可能であることは、理解されるべきである。
【００３６】
特に、ＵＥ上のアプリケーションは、それがデータの交換を用いてなされたと決定する場合、好適には、それは「なされた」との指示を、ＵＥソフトウェアの「ＲＲＣ接続マネージャ」コンポーネントへ送信する。ＲＲＣ接続マネージャは、関連パケットデータプロトコル（ＰＤＰ）コンテキスト、関連パケット交換（ＰＳ）無線ベアラ、および関連回路交換（ＣＳ）無線ベアラなどの全ての現行のアプリケーション（一つまたは複数のプロトコルを介したサービスを提供するものを含む）を追跡し続ける。ＰＤＰコンテキストは、ＵＭＴＳコアネットワークにわたってランするＵＥとＰＤＮ（公衆データネットワーク）との間の論理関係である。ＵＥ上の一つまたは複数のアプリケーション（例えば、ｅメールアプリケーションおよびブラウザアプリケーション）は、一つのＰＤＰコンテキストと関連し得る。一部の場合において、ＵＥ上の一つのアプリケーションは、一次ＰＤＰコンテキストと関連し、複数のアプリケーションは、二次ＰＤＰコンテキストに結合され得る。ＲＲＣ接続マネージャは、同時に活性であるＵＥ上の異なるアプリケーションから、「なされた」との指示を受信する。例えば、ユーザは、ウェブを閲覧している間に、プッシュサーバからｅメールを受信し得る。ｅメールアプリケーションが承認を送信した後、それは、そのデータトランザクションを完了したことを指示し得るが、しかしながら、ブラウザアプリケーションは、そのような指示を送信し得ない。活性なアプリケーションからのそのような指示の合成状態に基づいて、ＵＥソフトウェアは、それが、コアネットワークパケットサービスドメインの信号伝達接続解放を開始し得る前に、どの程度待機するべきかを決定し得る。この場合における遅延は、そのアプリケーションがデータ交換を真に終了させ、ＲＲＣ接続を要求しないことを保証するために導入され得る。その遅延は、トラフィック履歴および／またはアプリケーションプロフィールに基づいてダイナミックであり得る。どのアプリケーションも一切データを交換することが期待されないという可能性が幾分かあると、ＲＲＣ接続マネージャが判断するときはいつも、ＲＲＣ接続マネージャは適切なドメイン（例えば、ＰＳドメイン）に対して、信号伝達接続解放指示手順を送信し得る。あるいは、ＵＴＲＡＮに接続されたモード内において、状態移行のリクエストを送信し得る。
【００３７】
上述の判断はまた、ネットワークが、ＵＲＡ＿ＰＣＨ状態およびこの状態への移行挙動をサポートするかどうかを考慮し得る。
【００３８】
ＵＥによって開始されたアイドルモードへの移行は、ＲＲＣ接続モードの任意の状態から生じ得、ネットワークをＲＲＣ接続から解放させ、ＵＥをアイドルモードへと移動させることによって終わる。当業者によって理解されるように、アイドルモード中のＵＥは、接続状態中のＵＥよりも、バッテリがはるかに低い。
【００３９】
しかしながら、信号伝達接続解放指示の送信は、ネットワークに、結果として、警告が起こったことを考慮させ得る。信号伝達解放指示が、トラフィックが一切期待されないというＲＲＣによる判断の結果の場合、好ましい実施形態において、ネットワークは、信号伝達解放指示が、異常な状態であるのではなく、リクエストされたアイドル移行の結果であることを区別し得る。この区別によって、キー性能インディケータ（ＫＰＩ）のようなインディケータがより正確になり、性能のモニタと警告のモニタとを改善することができる。
【００４０】
本方法は、ＵＥが、既存の信号伝達解放指示に、信号伝達解放指示の理由を提供するフィールドを添付することを可能にする。ネットワークは、次いで、添付されたフィールドを用いて、真の警告状態をＵＥがアイドル状態に置かせるようにリクエストした状況からフィルタリングし得る。なぜなら、このリクエストした状況は、さらなるデータが一切期待できないからである。これは、警告および性能のモニタの効率を改善し、その一方で、ＵＥをより迅速にアイドルモードに移動させて、そのバッテリリソースを節約することを可能にする。
【００４１】
本出願は、それゆえ、ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法を提供し、該方法は、該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、該信号伝達接続解放指示を該無線ネットワークで受信するステップと、該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する。
【００４２】
本出願は、さらに、信号伝達解放指示理由を処理するのに適合したシステムをさらに提供し、該システムは、ユーザ設備であって、該ユーザ設備は、ＵＭＴＳネットワークと通信するのに適合した無線を含む無線サブシステムと；デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと；メモリと；ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有する、ユーザ設備であって、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付する手段と、該添付信号伝達接続解放指示を該無線ネットワークに送信する手段とを有することによって特徴付けられる、ユーザ設備と、該ユーザ設備と通信するのに適合した無線ネットワークであって、該信号伝達接続解放指示を受信する手段と、該理由をフィルタリングし、警告を発するかどうかを判断する手段とによってさらに特徴付けられる、無線ネットワークとを備える。
【００４３】
本出願は、またさらに、無線ネットワークで改善された警告を追跡するために、ユーザ設備で信号伝達解放指示理由を処理する方法を提供し、該方法は、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップであって、該無線ネットワークは、該信号伝達接続解放指示の該理由の指示を提供する、ステップとを包含する。
【００４４】
本出願は、またさらに、信号伝達接続の解放を容易にするユーザ設備用装置を提供する。チェッカは、信号伝達接続解放指示が、送信されるべきかどうかをチェックするように構成される。信号伝達接続解放指示センダは、信号伝達接続解放指示が送信されるべきであるという該チェッカによる指示に応答して、該信号伝達接続解放指示を送信するように構成される。該信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む。
【００４５】
本出願は、またさらに、信号伝達接続解放指示によって、動作するネットワーク装置を提供する。試験機は、該信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験するように構成される。該試験機は、該信号伝達解放指示理由フィールドが異常な状態を指示するかどうかをチェックする。警告生成機は、該試験機による試験が、該信号伝達解放指示理由フィールドが該異常な状態を指示すると判断する場合、警告を選択的に生成するように構成される。
【００４６】
本出願は、またさらに、ＵＭＴＳネットワーク内で、信号伝達解放指示理由を提供するのに適合したユーザ設備を提供し、該ユーザ設備は、該ＵＭＴＳネットワークと通信するのに適合した無線を含む無線サブシステムと；デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと；メモリと；ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有し、該ユーザ設備は、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、該信号伝達接続解放指示に、該信号伝達接続解放指示に対する理由を添付する手段と、該理由を含む該添付信号伝達接続解放指示を送信する手段であって、該無線ネットワークは、該信号伝達接続解放指示の該理由の指示を提供する、手段とを有することによって特徴付けられる。
【図面の簡単な説明】
【００４７】
本出願は、図面を参照することで、よりよく理解される。
【図１】図１は、ＲＲＣ状態および移行を示すブロック図である。
【図２】図２は、様々なＵＭＴＳセルおよびＵＲＡを示すＵＭＴＳネットワークの模式図である。
【図３】図３は、ＲＲＣ接続設定の様々な段階を示すブロック図である。
【図４Ａ】図４Ａは、ＣＥＬＬ＿ＤＣＨ接続モード状態と、現行方法に従うＵＴＲＡＮによって起動されるとアイドルモードとの間の例示的な移行のブロック図である。
【図４Ｂ】図４Ｂは、信号伝達解放指示を利用して、ＣＥＬＬ＿ＤＣＨ状態接続モードからアイドルモードへの移行との間の例示的な移行を示すブロック図である。
【図５Ａ】ＵＴＲＡＮによって開始された、ＣＥＬＬ＿ＤＣＨ不活動からＣＥＬＬ＿ＦＡＣＨ不活動へ、およびアイドルモードへの例示的な移行のブロック図である。
【図５Ｂ】図５Ｂは、信号伝達解放指示を利用して、ＣＥＬＬ＿ＤＣＨ不活性とアイドルモードとの間の例示的な移行のブロック図である。
【図６】図６は、ＵＭＴＳプロトコルスタックのブロック図である。
【図７】図７は、本方法と関連して用いられる例示的なＵＥである。
【図８】図８は、本方法と関連して用いられる例示的なネットワークである。
【図９】図９は、ＵＥで、信号伝達接続解放指示に対する理由を追加するステップを示す流れ図である。
【図１０】図１０は、理由を有する信号伝達接続解放指示を受信した後に、ＵＥによって取られるステップを示す流れ図である。
【発明を実施するための形態】
【００４８】
ここで、図１を参照する。図１は、ＵＭＴＳネットワークにおけるプロトコルスタックの無線リソース制御部分に対する様々なモードおよび状態を示すブロック図である。特に、ＲＲＣは、ＲＲＣアイドル状態１１０またはＲＲＣ接続状態１２０のいずれかであり得る。
【００４９】
当業者には理解されるように、ＵＭＴＳネットワークは、２つの陸上ベースのネットワークセグメントからなる。これらは、コアネットワーク（ＣＮ）および（図８に示されるような）ユニバーサル陸上無線アクセスネットワーク（ＵＴＲＡＮ）である。コアネットワークは、外部ネットワークへのデータコールおよびデータ接続の交換およびルーティングを担い、ＵＴＲＡＮは、全ての無線関連機能性を扱う。
【００５０】
アイドルモード１１０において、ＵＥとネットワークとの間でデータが交換される必要があるときはいつも、ＵＥはＲＲＣ接続をリクエストし、無線リソースを設定しなくてはならない。これは、ＵＥが接続を要求してデータを送信するアプリケーションの結果として、あるいはＵＥが、ＵＴＲＡＮまたはＳＧＳＮがＵＥをページングしたかどうかを指示するページングチャネルをモニタして、プッシュサーバのような外部データネットワークからデータを受信する結果としてのいずれかであり得る。さらに、ＵＥは、また、ロケーションエリア更新のような信号伝達メッセージを移動管理（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ）に送信する必要があるときは、いつでもＲＲＣ接続をリクエストする。
【００５１】
一度、ＵＥがＵＴＲＡＮにリクエストを送信すると、無線接続が確立し、ＵＴＲＡＮは、ＲＲＣ接続が中に入るようにするために状態を選択する。特に、ＲＲＣ接続モード１２０は、４つの個別状態を含む。これらは、ＣＥＬＬ＿ＤＣＨ状態１２２、ＣＥＬＬ＿ＦＡＣＨ状態１２４、ＣＥＬＬ＿ＰＣＨ状態１２６、およびＵＲＡ＿ＰＣＨ状態１２８である。
【００５２】
アイドルモード１１０から、ＲＲＣ接続状態は、セル専用チャネル（ＣＥＬＬ＿ＤＣＨ）状態１２２またはセル転送アクセスチャネル（ＣＥＬＬ＿ＦＡＣＨ）状態１２４のいずれかに進み得る。
【００５３】
ＣＥＬＬ＿ＤＣＨ状態１２２において、専用チャネルが、アップリンクとダウンリンクとの双方のためにＵＥに割り当てられ、データ交換する。この状態は、ＵＥに割り当てられた専用物理的チャネルを有するので、ＵＥから最も多くのバッテリ電力を典型的に要求する。
【００５４】
代替として、ＵＴＲＡＮは、アイドルモード１１０からＣＥＬＬ＿ＦＡＣＨ状態１２４に移動し得る。ＣＥＬＬ＿ＦＡＣＨ状態において、専用チャネルはＵＥに割り当てられない。その代わりに、共通チャネルが、信号伝達を少量のバースティなデータで送信するために使用される。しかしながら、ＵＥは、相変わらずＦＡＣＨを連続的にモニタしなくてはならない。それゆえ、バッテリ電力を消費する。
【００５５】
ＲＲＣ接続モード１２０内において、ＲＲＣ状態は、ＵＴＲＡＮの行動（ｄｉｓｃｒｅｔｉｏｎ）を変更し得る。特に、データ不活性が特定の時間の間に検出された場合、あるいは所定の閾値未満のスループットが検出された場合、ＵＴＲＡＮは、ＲＲＣ状態をＣＥＬＬ＿ＤＣＨ状態１２２から、ＣＥＬＬ＿ＦＡＣＨ状態１２４、ＣＥＬＬ＿ＰＣＨ状態１２６、またはＵＲＡ＿ＰＣＨ状態１２８に、移動させ得る。同様に、ペイロードが所定の閾値を超えることが検出される場合、ＲＲＣ状態は、ＣＥＬＬ＿ＦＡＣＨ１２４からＣＥＬＬ＿ＤＣＨ１２２に移動し得る。
【００５６】
ＣＥＬＬ＿ＦＡＣＨ状態１２４から、データ不活性が一部のネットワークにおいて、所定の時間にわたって検出された場合、ＵＴＲＡＮは、ＲＲＣ状態をＣＥＬＬ＿ＦＡＣＨ状態１２４からページングチャネル（ＰＣＨ）状態に移動させ得る。これは、ＣＥＬＬ＿ＰＣＨ 状態１２６またはＵＲＡ＿ＰＣＨ状態１２８のいずれかであり得る。
【００５７】
ＣＥＬＬ＿ＰＣＨ状態１２６またはＵＲＡ＿ＰＣＨ状態１２８から、ＵＥは、専用チャネルをリクエストする更新手順を開始するために、ＣＥＬＬ＿ＦＡＣＨ状態１２４に移動されなくてはならない。これは、ＵＥが制御する唯一の状態移行である。
【００５８】
ＣＥＬＬ＿ＰＣＨ状態１２６およびＵＲＡ＿ＰＣＨ状態１２８は、不連続受信サイクル（ＤＲＸ）を使用し、包装メッセージおよびページングインディケータチャネル（ＰＩＣＨ）によるページングをモニタする。アップリンク活動は、一切不可能である。
【００５９】
ＣＥＬＬ＿ＰＣＨ状態１２６とＵＲＡ＿ＰＣＨ状態１２８との間の差は、ＵＲＡ＿ＰＣＨ状態が、現在のセルの中に存在するＵＲＡアイデンティティのリストの中にＵＥの現在のＵＴＲＡＮ登録エリア（ＵＲＡ）がない場合、ＵＲＡ更新手順をトリガすることのみである。具体的には、図２を参照する。図２は、様々なＵＭＴＳセル２１０、２１２、および２１４の図を示す。これらのセルの全ては、ＣＥＬＬ＿ＰＣＨ状態が再選択された場合、セル更新手順を要求する。しかしながら、ＵＴＲＡＮ登録エリアにおいて、各セルは、同じＵＴＲＡＮ登録エリア２２０内にあり、したがって、ＵＲＡ更新手順は、ＵＲＡ＿ＰＣＨモードのときに、２１０、２１２、および２１４の間で移動するとき、トリガされない。
【００６０】
図２に示されるように、他のセル２１８は、ＵＲＡ２２０の外側にアップリンク、別個のＵＲＡの一部となり得るか、あるいはＵＲＡになり得ない。
【００６１】
当業者には理解されるように、バッテリ寿命見通しから、アイドル状態は、上述の状態と比べて、最も少ないバッテリ使用法を提供する。具体的に、ＵＥは、ページングチャネルをインターバルだけにおいて、モニタすることを要求されるので、無線は、連続的にオンである必要はないが、その代わりに、定期的に目覚める必要がある。これに対するトレードオフは、データを送信する待ち時間である。しかしながら、この待ち時間は、さほど長くもない場合、アイドルモードであってバッテリ電力を節約することのメリットは、接続の待ち時間のデメリットを上回る。
【００６２】
再び、図１を参照する。様々なＵＭＴＳインフラベンダは、様々な基準に基づいて、１２２、１２４、１２６、および１２８の状態間を移動する。例示的なインフラは、以下に概略される。
【００６３】
第一の例示的なインフラにおいて、ＲＲＣは、アイドルモードとＣｅｌｌ＿ＤＣＨ状態との間を直接移動する。Ｃｅｌｌ＿ＤＣＨ状態において、２秒間活性でないことが検出されると、ＲＲＣ状態は、Ｃｅｌｌ＿ＦＡＣＨ状態１２４に変化する。Ｃｅｌｌ＿ＦＡＣＨ状態１２４において、１０秒間活性でないことが検出されたら、ＲＲＣ状態は、ＰＣＨ状態１２６に変化する。Ｃｅｌｌ＿ＰＣＨ状態１２６において、４５分間活性でないことが検出されたら、その結果、ＲＲＣ状態は、アイドル状態１１０に戻る。
【００６４】
第二の例示的なインフラにおいて、ＲＲＣ移行は、ペイロード閾値に依存して、アイドルモード１１０と接続モード１２０との間で発生し得る。第二のインフラにおいて、ペイロードが、所定の閾値未満であれば、ＵＴＲＡＮは、ＲＲＣ状態からＣＥＬＬ＿ＦＡＣＨ状態１２４に移動する。逆に、データが所定のペイロードを上回る場合、ＵＴＲＡＮは、ＲＲ状態をＣＥＬＬ＿ＤＣＨ状態１２２に移行する。第二のインフラで、ＣＥＬＬ＿ＤＣＨ状態１２２において、２分間活性でないことが検出されると、ＵＴＲＡＮは、ＲＲＣをＣＥＬＬ＿ＦＡＣＨ状態１２４に移動する。ＣＥＬＬ＿ＦＡＣＨ状態１２４において、５分間活性でないことが検出されると、ＵＴＲＡＮは、ＲＲＣ段階をＣＥＬＬ＿ＰＣＨ状態１２６に移動する。ＣＥＬＬ＿ＰＣＨ状態１２６において、アイドルモード１１０に戻る前に、２時間の不活動が要求される。
【００６５】
第三の例示的なインフラにおいて、アイドルモードと接続モード１２０との間の移動は、常に、ＣＥＬＬ＿ＤＣＨ状態１２２である。ＣＥＬＬ＿ＤＣＨ状態１２２において、５秒間活性でなかった後に、ＵＴＲＡＮは、ＲＲＣ状態をＣＥＬＬ＿ＦＡＣＨ状態１２４に移動する。ＣＥＬＬ＿ＦＡＣＨ状態１２４において、３０秒間活性でないと、その結果、アイドル状態１１０に移動して戻る。
【００６６】
第四の例示的なインフラにおいて、ＲＲＣは、アイドルモードから接続モードに直接移行し、ＣＥＬＬ＿ＤＣＨ状態１２２になる。第四の例示的なインフラにおいて、ＣＥＬＬ＿ＤＣＨ状態１２２は、２つのサブ状態を含む。第一は、高いデータレートを有するサブ状態であり、第二のサブ状態は、より低いデータレートを含むが、それでもなおＣＥＬＬ＿ＤＣＨ状態の範囲内である。第四の例示的なインフラにおいて、ＲＲＣは、アイドルモード１１０から、高いデータレートのＣＥＬＬ＿ＤＣＨサブ状態へと直接移行する。１０秒間活性でない後、ＲＲＣ状態は、低いＣＥＬＬ＿ＤＣＨ状態に移行する。低データのＣＥＬＬ＿ＤＣＨ状態１２２から１７秒間活性でないと、その結果、ＲＲＣ状態は、アイドルモード１１０に変化する。
【００６７】
上述の４つの例示的なインフラは、様々なＵＭＴＳのインフラベンダが、状態をインプリメントしているかを示す。当業者には理解されるように、各場合において、実際のデータ交換（例えば、ｅメール）に要した時間は、ＣＥＬＬ＿ＤＣＨまたはＣＥＬＬ＿ＦＡＣＨ状態に留まっていることを要求される時間に比べ、かなり短い。このため、不必要なカレントドレインが生じ、その結果、ユーザは、ＵＭＴＳのような新たな世代のネットワークにおいて、ＧＰＲＳのような以前の世代のネットワークよりも、悪化するのを体験する。
【００６８】
さらに、ＣＥＬＬ＿ＰＣＨ状態は、ＣＥＬＬ＿ＦＡＣＨ状態よりも最適であるが、バッテリ寿命の観点から、ＣＥＬＬ＿ＰＣＨ状態におけるＤＲＸサイクルは、典型的には、アイドルモード１１０より低い値に設定される。その結果、ＵＥは、アイドルモードよりも、ＣＥＬＬ＿ＰＣＨ状態で、より頻繁に目覚めていることが要求される。
【００６９】
アイドル状態のサイクルと同様のＤＲＸサイクルを有するＵＲＡ＿ＰＣＨ状態は、バッテリ寿命と接続における待ち時間との最適なトレードアップのように思われる。しかしながら、ＵＲＡ＿ＰＣＨは、現在、ＵＴＲＡＮでサポートされていない。それゆえ、バッテリ寿命の観点から、アプリケーションがデータ交換で終了したら、できるだけ迅速に、アイドルモードに移行することが望ましい。
【００７０】
ここで、図３を参照する。アイドルモードから接続モードへ移行するとき、様々な信号伝達およびデータ接続が、生成される必要がある。図３を参照すると、実行されるべき必要のある第一のアイテムは、ＲＲＣ接続設定である。上述のように、このＲＲＣ接続設定は、ＵＴＲＡＮによってのみ、解体され得る。
【００７１】
一度、ＲＲＣ接続設定３１０が達成されると、信号接続設定３１２が開始される。
【００７２】
一度、信号設定３１２が終了すると、暗号化・保全性設定（ｃｉｐｈｅｒｉｎｇ ａｎｄ ｉｎｔｅｇｒｉｔｙ ｓｅｔｕｐ）３１４が開始される。これが完了すると、無線ベアラ設定３１６が達成される。この時点で、データは、ＵＥとＵＴＲＡＮとの間で交換され得る。
【００７３】
接続解体は、一般的に、この逆順で同様に達成される。無線ベアラ設定３１６は、解体され、次いで、ＲＲＣ接続設定３１０が取り払われる。この時点で、ＲＲＣは、図１に示すように、アイドルモード１１０へと移動する。
【００７４】
現在の３ＧＰＰ仕様によれば、ＵＥが、ＲＲＣ接続を解放すること、または、ＲＲＣ状態にとってその好みを指示することはできないが、それでも、ＵＥは、特定のコアネットワークドメイン（例えば、パケット交換アプリケーションで使用されるＰａｃｋｅｔ Ｓｗｉｔｃｈｅｄ（ＰＳ））に対する信号伝達接続の終了を指示し得る。３ＧＰＰ ＴＳ ２５．３３１の８．１．１４．１節に従うと、信号伝達接続解放指示手順は、ＵＥによって使用され、ＵＴＲＡＮに、その信号伝達接続の一つが解放されたことを指示する。この手順は、順に、ＲＲＣ接続解放手順を開始し得る。
【００７５】
このように、現行の３ＧＧＰ仕様の範囲に留まると、信号伝達接続解放は、信号接続設定３１２の解体によって、開始され得る。信号伝達接続設定３１２を解体する（ｔｅａｒ
ｄｏｗｎ）ことは、ＵＥの能力の範囲内であり、次いで、仕様に従えば、このことは、ＲＲＣ接続解放を開始し「得る」。
【００７６】
当業者には理解されるように、信号伝達接続設定３１２が、解体される場合、ＵＴＲＡＮは、また、解読・保全性設定３１２を一掃し、信号接続設定３１２が解体された後に、無線ベアラ設定３１６を一掃する必要がある。
【００７７】
信号伝達接続設定３１２が、解体される場合、ＲＲＣ接続設定は、典型的には、現在のベンダのインフラに対するネットワークによって停止される。
【００７８】
上述を用いて、データ交換とともに行われるとＵＥが決定する場合、例えば、ＵＥソフトウェアの「ＲＲＣ接続マネージャ」コンポーネントが、データ交換が完了したという指示を提供された場合、ＲＲＣ接続マネージャは、信号伝達接続設定３１２を解体するかどうかを判断し得る。例えば、デバイス上でのｅメールアプリケーションは、ｅメールが本当にプッシュサーバによって受信されたという、プッシュｅメールサーバからの通知を受信したという指示を送信する。ＲＲＣマネージャは、関連ＰＤＰコンテキスト、関連ＰＳ無線ベアラおよび関連回路交換（ＣＳ）無線ベアラの全ての現行のアプリケーションを追跡し得る。この場合の遅延は、データ交換でもって、そのアプリケーションが本当に終了し、もはや、「完了」指示を送信した後もＲＲＣ接続をもはや必要としない。この遅延は、このアプリケーションと関連する非活性なタイムアウトと同等である。各アプリケーションは、それ自身の非活性なタイムアウトを有し得る。例えば、ｅメールアプリケーションは、５秒の非活性なタイムアウトを有し得るが、活性なブラウザアプリケーションは、６０秒の非活性なタイムアウトを有し得る。活性なアプリケーションからの全てのこのような指示の復号ステータスに基づいて、ＵＥソフトウェアは、ＵＥソフトウェアが、適切なコアネットワーク（例えば、ＰＳドメイン）の信号伝達接続解放を開始し得るまでに、どのくらい待つべきであるかを判断する。
【００７９】
非活性なタイムアウトは、トラフィックパターン履歴および／またはアプリケーションプロファイルに基づいて、ダイナミックベースでなされ得る。
【００８０】
ＲＲＣ接続マネージャが、どのアプリケーションもデータ交換を期待されないとある程度の確率で判断するときはいつも、ＲＣＣ接続マネージャは、適切なドメインに対する信号伝達接続解放指示手順を送信し得る。
【００８１】
上述のＵＥで開始されたアイドルモードへの移行は、図１に示すようなＲＲＣ接続モード１２０の任意の段階で起こり得て、また、ＲＲＣ接続ネットワークから解放させ、図１に示すようなアイドルモード１１０に移動させて終了する。これは、また、音声コール中に、ＵＥが任意のパケットデータサービスを実行しているときにも、適用可能である。この場合、ＰＳドメインのみが解放されるが、ＣＳドメインは接続されたままである。
【００８２】
上述のネットワークの考え方における問題は、ＵＥによって送信された信号伝達接続解放指示が、警告として解釈されることである。信号伝達ネットワーク解放が、適用タイマ時間切れのためにより、ＵＥによって明確なアクションの結果であり、それゆえ、さらなるデータが期待されない場合、上記の指示によって生じた警告は、性能および警告指示をスキューする。キー性能インディケータは、これによって変更され得、効率の損失へと導く。
【００８３】
好ましくは、理由が、ＵＴＲＡＮに指示に対する理由を指示する信号伝達接続解放指示に追加されるべきである。好ましい実施形態において、その理由は、異常な状態が指示の理由となったという指示か、あるいはリクエストされたアイドル移行の結果として、ＵＥによって開始されたという指示であり得る。他の正常（すなわち、異常でない）トランザクションは、結果として、信号伝達接続解放指示の送信であり得る。
【００８４】
さらなる好ましい実施形態において、様々なタイムアウトは、異常な状態に対する信号伝達接続指示の理由となり得る。以下のタイマの例は、網羅的なものでなく、他のタイマ、あるいは他の条件も可能である。例えば、３ＧＰＰ．ＴＳ ２４．００８の１０．２．４７は、タイマＴ３３１０として、以下を特定する。
【００８５】
【表１】
このタイマは、アタッチ失敗を指示するために使用される。アタッチ失敗は、ネットワークの結果であり得るか、あるいは衝突または不良無線周波数（ＲＦ）のようなＲＦ問題であり得る。
【００８６】
添付の試みは、複数回起こり得、アタッチ失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【００８７】
３ＧＰＰの１０．２．４７の第二のタイマは、Ｔ３３３０であり、以下のように特定される。
【００８８】
【表２】
このタイマは、ルーティングエリア更新失敗を指示するために使用される。タイマが時間切れになると、さらなるルーティングエリア更新が、複数回リクエストされ得て、ルーティングエリア更新失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【００８９】
３ＧＰＰの１０．２．４７の第三のタイマは、Ｔ３３４０であり、以下のように特定される。
【００９０】
【表３】
このタイマは、ＧＭＭサービスリクエスト失敗を指示するために使用される。タイマが時間切れになると、さらなるＧＭＭサービスリクエストが、複数回開始され得、ＧＭＭサービスリクエスト失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【００９１】
このように、信号伝達解放指示は、異常な状態およびＵＥによる解放に限られる代わりに、信号伝達解放指示は、さらに、異常な状態に対してどのタイマが失敗したかに関する情報を含み得る。信号伝達接続解放指示は、以下のように構造化され得る。
【００９２】
【表４】
このメッセージは、ＵＥによって使用され、ＵＴＲＡＮに既存の信号伝達接続を解放するように指示する。信号伝達解放指示を追加すると、ＵＴＲＡＮまたは他のネットワークエレメントは、信号伝達解放指示の理由、つまり異常な状態によるものであったのか、あるいは異常な状態とは何であったかを受信することができる。そして、ＲＲＣ接続解放手順が、次いで、開始されることが可能になる。
【００９３】
一つのインプリメンテーションにおいて、ＵＥは、解放または中断するようにというリクエストを受信すると、特定のＣＮ（コアネットワーク）ドメインに対する上部層からの信号伝達接続は、ＩＥ（情報エレメント）「ＣＮドメインアイデンティティ」で識別される特定のＣＮドメインに対する変数（例えば、変数ＥＳＴＡＢＬＩＳＨＥＤ＿ＳＩＧＮＡＬＩＮＧ＿ＣＯＮＮＥＣＴＩＯＮＳ）で識別されるような信号伝達接続が存在する場合、信号伝達接続解放指示を開始する。変数が、既存の信号伝達接続を一切識別しない場合、その特定のＣＮドメインに対する信号伝達接続の進行中の確立は、いずれも別の方法で中断される。そして、ＣＥＬＬ＿ＰＣＨまたはＵＲＡ＿ＰＣＨ状態で、信号伝達接続解放指示手順が開始すると、ＵＥは、「アップリンクデータ送信」理由を用いて、セル更新手順を実行する。そして、セル更新手順が成功裏に完了したとき、ＵＥは、その後の信号伝達接続解放指示手順を続ける。
【００９４】
すなわち、ＵＥは、ＩＥ「ＣＮドメインアイデンティティ」を上部ロジカル層によって指示された値に設定する。ＩＥの値は、ＣＮドメインを指示し、その関連信号伝達接続は、上部層が解放されるべきことを指示する関連信号伝達接続である。ＣＮドメインアイデンティティが、ＰＳドメインに設定される場合で、上部層は、このリクエストを開始する理由を指示する場合、ＩＥ「信号伝達解放指示理由」は、これに従って設定される。ＵＥは、変数「ｅｓｔａｂｌｉｓｈｅｄ＿ｓｉｇｎａｌｉｎｇ＿ｃｏｎｎｅｃｔｉｏｎｓ」から上部層によって指示されたアイデンティティを有する信号伝達接続をさらに除去する。そして、ＵＥは、信号伝達接続解放指示メッセージを、例えば、ＡＭ ＲＬＣを用いて、ＤＣＣＨ上で送信する。ＲＬＣによって解放指示メッセージの配信が成功したことを確認すると、この手順は終了する。
【００９５】
ＩＥ「Ｓｉｇｎａｌｉｎｇ Ｒｅｌｅａｓｅ Ｉｎｄｉｃａｔｉｏｎ Ｃａｕｓｅ」も、また本開示の実施形態に関して用いられる。解放理由は、例えば、既存のメッセージ定義で、アラインされる。上部層解放理由メッセージも例えば、以下のように構造化される。
【００９６】
【表５】
この例において、Ｔ３３１０、Ｔ３３３０、およびＴ３３４０は、上記で識別された対応するように番号付けされたタイマの時間切れに相当する。理由値は、一つの実施形態において、状態移行によって判断するＵＴＲＡＮに提供する「ＵＥ Ｒｅｑｕｅｓｔｅｄ ｉｄｌｅ ｔｒａｎｓｉｔｉｏｎ」よりも、むしろ「ＵＥ Ｒｅｑｕｅｓｔｅｄ ＰＳ Ｄａｔａ ｓｅｓｓｉｏｎ ｅｎｄ」として、設定可能である。しかしながら、期待される結果は、理由値によって識別される結果に対応する。信号伝達接続解放指示への拡張（ｅｘｔｅｎｓｉｏｎ）は、好ましいが、必ずしも必要ではなく、クリティカルでない拡張である。
【００９７】
ここで、図９を参照する。図９は、様々なドメイン（例えば、ＰＳまたはＣＳ）に対する信号伝達接続解放指示を送信するかしないかを例示的にＵＥをモニタする流れ図である。プロセス９１０は、ステップ９１０で開始する。
【００９８】
ＵＥは、ステップ９１２へ移行し、ここで、異常な状態が存在するかどうかを見るためにチェックする。このような異常な状態には、例えば、上述したような、タイマＴ３３１０、タイマＴ３３２０、またはタイマＴ３３４０の時間切れを含み得る。これらのタイマが、ある所定の回数、時間切れとなった場合、あるいはこれらのタイマのいずれかの時間切れに基づいて、明確な拒絶を受信する場合、ＵＥは、ステップ９１４に進み、ここで、信号伝達接続解放指示を送信する。信号伝達接続解放指示メッセージは、信号伝達解放指示理由フィールドを用いて添付される。信号伝達解放指示理由フィールドは、信号伝達接続解放指示が異常な状態（ｃｏｎｄｉｔｉｏｎまたはｓｔａｔｅ）に基づくことを少なくとも含み、好ましい実施形態は、異常な状態の結果としてタイムアウトする特定のタイマを含む。
【００９９】
逆に、ステップ９１２で、ＵＥが異常な状態が存在しないことを見出す場合、ＵＥは、ステップ９２０に進み、ここで、さらなるデータがＵＥで期待されるかどうかをチェックする。これは、上述のように、ｅメールが送信され、そのｅメールの送信確認がＵＥに返信されたときを含む。ＵＥがさらなるデータがもはや期待されないかどうかを判断する他の例は、当業者には周知である。
【０１００】
ステップ９２０で、データ伝達が終了した（あるいは、回路交換の場合、ドメインコールが終了した）と、ＵＥが判断する場合、ＵＥは、ステップ９２２に進み、ここで、信号伝達接続解放指示を送信する。この信号伝達接続解放指示の中に、信号伝達解放指示理由フィールドが追加され、このフィールドはＵＥがアイドル移行をリクエストしたという事実を含む。
【０１０１】
データが終了しない場合、ステップ９２０から、ＵＥはループを戻り、ステップ９１２で異常な状態が存在しないかどうかをチェックし、ステップ９２０でデータが終了するかどうかをチェックし続ける。
【０１０２】
一度、ステップ９１４またはステップ９２２で、信号伝達接続解放指示が送信されると、プロセスは、ステップ９３０に進み、終了する。
【０１０３】
ＵＥは、機能エレメントを含む。これらの機能エレメントは、例えば、ＵＥマイクロプロセッサの動作を介して実行されるアプリケーションまたはアルゴリズムによって、あるいは、ハードウェアインプリメンテーションによって、インプリメント可能であり、チェッカおよび信号伝達接続解放指示センダを形成する。チェッカは、信号伝達接続解放指示が送信されるべきかどうかをチェックするように構成される。そして、信号伝達接続解放指示センダが、チェッカによる信号伝達接続解放指示を送信すべきであるという指示に応答して、信号伝達接続解放指示を送信するように構成される。信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む。
【０１０４】
一つのインプリメンテーションにおいて、ネットワークは、代わりに、暗黙にタイマのタイムアウトに気付くようにされ、ＵＥはタイマのタイムアウトを指示する理由値を送信する必要はない。つまり、タイマは、ネットワークの承諾を受けて、時間計測を開始する。理由コードが規定され、その理由コードは、ネットワークによってＵＥに提供される。このような理由コードは、タイマを開始するために、ＵＥによって使用される。そして、ネットワークによって以前に送信された理由コードが、タイマに時間測定をさせると、ネットワークは、暗黙のうちに、タイマの次のタイムアウトに対する根拠に気付く。そして、その結果として、ＵＥは、タイマの時間切れを指示する理由値を送信する必要がなくなる。
【０１０５】
図１０を参照すると、ネットワークエレメントが、ステップ１０１０で信号伝達接続解放指示を受信するとき、ネットワークエレメントは、ステップ１０１４で信号伝達解放指示理由フィールドを試験し、ステップ１０１６で、その理由が異常な理由であるかどうか、あるいはその理由はＵＥがアイドル移行をリクエストしたことによるかどうかをチェックする。ステップ１０１６で、信号伝達接続解放指示が、異常な理由である場合、ネットワークノードは、ステップ１０２０に進み、ここでは、警告は、性能をモニタするため、および警告モニタの目的であると注記される。キー性能インディケータは、適切に更新され得る。
【０１０６】
逆に、ステップ１０１６で、信号伝達接続解放指示の理由が、異常な状態の結果でない場合、あるいは換言すれば、ＵＥがアイドル移行をリクエストした結果である場合、ネットワークノードは、ステップ１０３０に進み、ここで、警告が発せられず、指示は、性能統計からフィルタリングされ得、これによって、性能統計がスキューすることが妨げられる。ステップ１０２０またはステップ１０３０から、ネットワークノードは、ステップ１０４０に進み、プロセスは終了する。
【０１０７】
信号伝達解放指示理由フィールドを受信し、試験すると、その結果、ネットワークエレメントによって、ＲＲＣ接続解放手順が開始される。そして、パケット交換データ接続が終了する。
【０１０８】
当業者には理解されるように、ステップ１０２０は、様々な警告状態の間でさらに区分するために使用され得る。例えば、Ｔ３３１０のタイムアウトは、第一の統計セットを維持するために使用され得、Ｔ３３３０のタイムアウトは、第二の統計セットを維持するために使用され得る。ステップ１０２０は、異常な状態の理由で区別し得る。これによって、ネットワークオペレータは、性能をより効率的に追跡可能となる。
【０１０９】
ネットワークは、機能エレメントを含む。これらの機能エレメントは、例えば、ＵＥマイクロプロセッサの動作を介して実行されるアプリケーションまたはアルゴリズムによって、あるいは、ハードウェアインプリメンテーションによって、インプリメント可能であり、試験機および警告生成機を形成する。試験機は、信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験するように構成される。試験機は、信号伝達解放指示理由フィールドが異常な状態であるかどうかをチェックする。警告生成機は、試験機による試験が信号伝達解放指示理由フィールドが異常な状態を示す場合、警告を選択的に生成するように構成される。
【０１１０】
一つのインプリメンテーションにおいて、ＵＴＲＡＮは、信号伝達接続解放指示を受信すると、上部層から受信された理由を転送し、信号伝達接続の解放をリクエストする。上部層は、信号伝達接続の解放を開始することが可能である。ＩＥ信号伝達解放指示理由は、ＵＥの上部層に指示することで、ＵＥのＲＲＣをトリガし、メッセージを送信させるようにする。その理由は、おそらく、異常な上部層手順の結果である。メッセージの理由の区分は、ＩＥを成功裏に受信することで確保される。
【０１１１】
可能性のあるシナリオには、信号伝達接続解放指示メッセージが成功裏に配信されたことがＲＬＣによって確認される前に、信号伝達無線ベアラＲＢ２上のＲＬＣ全体の送信側の再確立が起こるシナリオを含む。このようなことが起こった場合、ＵＥは、例えば、信号伝達無線ベアラＲＢ２上のＡＭ ＲＬＣを用いて、アップリンクＤＣＣＨ上の信号伝達接続解放指示メッセージを再送信する。信号伝達接続解放指示メッセージが成功裏に配信されたことの確認が、ＲＬＣによって成功裏に配信される前に、ＵＴＲＡＮ手順の性能からのエンターＲＡＴの引き継ぎが起こった場合、ＵＥは、新たなＲＡＴの間に、信号伝達接続を中断する。
【０１１２】
再び、図１を参照すると、一部の場合において、アイドルモードにあるよりも、接続モード状態ＵＲＡ＿ＰＣＨにあることが、より望ましい。例えば、ＣＥＬＬ＿ＤＣＨまたはＣＥＬＬ＿ＦＡＣＨ接続モード状態に接続する待ち時間が少なくなることを要求される場合、接続モードＰＣＨ状態にあることが望ましい。これを達成するには、２つの方法がある。第一は、３ＧＰＰ仕様を変更して、ＵＥがＵＴＲＡＮに、自身を特定の状態（この場合は、ＵＲＡ＿ＰＣＨ状態１２８）に移動するように要求することである。
【０１１３】
代替として、ＲＲＣ接続マネージャは、ＲＲＣの接続が現状どのような状態であるかのような他の要因を考慮に入れ得る。例えば、ＲＲＣ接続がＵＲＡ＿ＰＣＨ状態である場合、ＲＲＣ接続は、自身がアイドルモード１１０に移動する必要がなく、それゆえ、信号接続解放の手順は、開始されない。
【０１１４】
図４を参照する。図４Ａは、上述のインフラストラクチャの「４つ」の例に従って、現在のＵＭＴＳのインプリメンテーションを示す。図４に示すように、時間は横軸に沿う。
【０１１５】
ＵＥは、ＲＲＣアイドル状態１１０で開始し、送信されるべきローカルデータ、または、ＵＴＲＡＮから受領したページに基づいて、ＲＲＣ接続の確立を始める。
【０１１６】
図４Ａに示されるように、ＲＲＣ接続設定３１０は、最初に起こり、ＲＲＣ状態は、この時間中、接続状態４１０である。
【０１１７】
次いで、信号接続設定３１２、暗号化・保全性設定３１４、および、無線ベアラ設定３１６が起こる。ＲＲＣ状態は、この間、ＣＥＬＬ＿ＤＣＨ状態１２２である。図４Ａに示されるように、ＲＲＣアイドルから移動する時間と、無線ベアラが設定される時間との比率は、この例において、ほぼ２秒である。
【０１１８】
次いで、データが交換される。図４Ａの例において、これは、約２〜４秒で達成され、ステップ４２０によって示される。
【０１１９】
ステップ４２０において、データが交換された後、必要に応じての断続的なＲＬＣ信号ＰＤＵを除くと、データは全く交換されない。こうして、無線ベアラは、約１０秒後に、低データレートのＤＣＨ状態に移動するように、ネットワークによって再構成される。これは、ステップ４２２および４２４で示されている。
【０１２０】
低データレートのＤＣＨ状態において、１７秒間にわたって何も受信されない。この時点で、ステップ４２８で、ＲＲＣ接続は、ネットワークによって解放される。
【０１２１】
一度、ＲＲＣ接続が、ステップ４２８で開始されると、ＲＲＣ状態は、約４０ミリ秒にわたって非接続状態４３０に入り、その後、ＵＥがＲＲＣアイドル状態１１０になる。
【０１２２】
また、図４Ａに示されているように、ＵＥの電流消費は、ＲＲＣがＣＥＬＬ＿ＤＣＨ状態１２２にあるときの期間にわたって示される。図示のように、電流消費は、ＣＥＬＬ＿ＤＣＨ状態の全期間にわたって、約２００〜３００ミリアンペアである。非接続およびアイドルの間に、ＤＲＸサイクルを１．２８秒と仮定すると、約３ミリアンペアが使用される。しかしながら、３５秒間の電流消費２００〜３００ミリアンペアは、バッテリを消耗させる。
【０１２３】
ここで、図４Ｂを参照する。図４Ｂは、上記から同じ例示的なインフラストラクチャ「４つ」を利用しているが、ここでのみ、信号接続解放をインプリメントしている。
【０１２４】
図４Ｂに示すように、同じ設定ステップ３１０、３１２、３１４および３１６が起こり、これには、ＲＲＣアイドル状態１１０とＲＲＣ ＣＥＬＬ＿ＤＣＨ状態１２２との間を移動するときと、同じ時間量を要する。
【０１２５】
さらに、図４Ａの例示的なｅメール用のＲＲＣデータＰＤＵ交換も、また、図４Ｂで行われ、これに、約２〜４秒を要する。
【０１２６】
図４Ｂの例の中のＵＥは、アプリケーション特有の不活動タイムアウトを有する。図４Ｂの例におけるこのタイムアウトは２秒であり、ステップ４４０によって描かれている。ＲＲＣ接続マネージャが特定の時間量にわたって、不活動があると判断した後、ステップ４４２で、ＵＥは信号接続設定を解放し、ステップ４２８で、ＲＲＣ接続はネットワークによって解放される。
【０１２７】
図４Ｂに示すように、ステップ１２２のＣＥＬＬ＿ＤＣＨの電流消費は、それでもなお、約２００〜３００ミリアンペアである。しかしながら、接続時間は、約８秒のみである。当業者には理解されるように、モバイルがセルＤＣＨ状態１２２のままである時間が、かなり短い時間量なので、その結果、常にオンであるＵＥデバイス上のバッテリ節約は、著しいものとなる。
【０１２８】
ここで、図５を参照する。図５は、上述で示したインフラストラクチャ「３」と示されるインフラを用いる第二の例である。図４Ａおよび図４Ｂと同様、接続設定は、約２秒を要して起こる。これは、ＲＲＣ接続設定３１０、信号接続設定３１２、暗号化・保全性設定３１４、および、無線ベアラ３１６を要する。
【０１２９】
この設定の間に、ＵＥは、ＲＲＣアイドルモード１１０からＣＥＬＬ＿ＤＣＨ状態１２２に移動する。この両者の間に、ＲＲＣ状態接続ステップ４１０がある。
【０１３０】
図４Ａと同様に、図５Ａにおいて、ＲＬＣデータＰＤＵ交換が起こり、図５Ａの例においては、約２〜４秒を要する。
【０１３１】
インフラストラクチャ３に従うと、ＲＬＣ信号ＰＤＵ交換は、データを全く受信しないので、必要に応じての断続的なＲＬＣ信号ＰＤＵを除き、こうして、ステップ４２２で、５秒の間、アイドルである。この時点において、無線ベアラは、ＣＥＬＬ＿ＤＣＨ状態１２２からＣＥＬＬ＿ＦＡＣＨ状態１２４に移動するために、ネットワークを再構成する。これは、ステップ４５０で行われる。
【０１３２】
ＣＥＬＬ＿ＦＡＣＨ状態１２４において、ＲＬＣ信号ＰＤＵ交換は、この場合、３０秒である所定の時間量に対し必要とされるような断続的なＲＬＣ信号ＰＤＵを除くと、全くデータがないことを見出す。この時点において、ステップ４２８で、ＲＲＣ接続のネットワークによる解放が実行される。
【０１３３】
図５Ａに示すように、これは、ＲＲＣ状態をアイドルモード１１０に移動する。
【０１３４】
さらに、図５Ａに示すように、ＤＣＨモードの間の電流消費は、２００〜３００ミリアンペアの間である。ＣＥＬＬ＿ＦＡＣＨ状態１２４に移動するとき、電流消費は、約１２０〜１８０ミリアンペアに下がる。ＲＲＣコネクタが、解放され、ＲＲＣがアイドルモード１１０に移動すると、電力消費は約３ミリアンペアになる。
【０１３５】
ＵＴＲＡ ＲＲＣ Ｃｏｎｎｅｃｔｅｄ Ｍｏｄｅ状態は、ＣＥＬＬ＿ＤＣＨ状態１２２またはＣＥＬＬ＿ＦＡＣＨ状態１２４であり、図５Ａの例では、約４０秒続く。
【０１３６】
ここで、図５Ｂを参照する。図５Ｂは、図５Ａと同じインフラストラクチャ「３」を示し、ＲＲＣ接続設定３１０、信号接続設定３１２、暗号化・保全性設定３１４、および、無線ベアラ設定３１６を得るために、約２秒の同じ接続時間を有する。さらに、ＲＬＣデータＰＤＵ交換４２０は、約２〜４秒を要する。
【０１３７】
図４Ｂと同様に、ＵＥアプリケーションは、ステップ４４０で、特定の不活動タイムアウトを検出する。この検出した時点で、信号接続解放指示手順は、ＵＥによって開始され、その結果、ＲＲＣ接続は、ステップ４４８で、ネットワークによって解放される。
【０１３８】
さらに、図５Ｂから分かるように、ＲＲＣは、アイドルモード１１０にて始まり、ＣＥＬＬ＿ＦＡＣＨ状態を経ずして、ＣＥＬＬ＿ＤＣＨ状態１２２に移動する。
【０１３９】
さらに、図５Ｂから分かるように、ＲＲＣ段階が、ＣＥＬＬ＿ＤＣＨ状態１２２である時間（図５の例に従うと、約８秒である）における電流消費は、約２００〜３００ミリアンペアの間である。
【０１４０】
それゆえ、図４Ａおよび図４Ｂと図５Ａおよび図５Ｂとを比較すると、著しい量の電流消費が、除去されている。こうして、ＵＥのバッテリ寿命が著しく伸びる。当業者には理解されるように、上述は、現行の３ＧＰＰ仕様の関連において、さらに使用され得る。
【０１４１】
ここで、図６を参照する。図６は、ＵＭＴＳネットワークに対するプロトコルスタックを示す。
【０１４２】
図６に示すように、ＵＭＴＳは、ＣＳ制御プレーン６１０、ＰＳ制御プレーン６１１、および、ＰＳユーザプレーン６３０を含む。
【０１４３】
これら３つのプレーンの中には、非アクセス層（ｎｏｎ−ａｃｃｅｓｓ ｓｔｒａｔｕｍ）（ＮＡＳ）部分６１４およびアクセス層部分６１６が存在する。
【０１４４】
ＣＳ制御プレーン６１０内のＮＡＳ部分６１４は、コール制御（ＣＣ）６１８、追加サービス（ｓｕｐｐｌｅｍｅｎｔａｒｙ ｓｅｒｖｉｃｅｓ）（ＳＳ）６２０、および、ショートメッセージサービス（ＳＭＳ）６２２を含む。
【０１４５】
ＰＳ制御プレーン６１１のＮＡＳ部分６１４は、移動管理（ＭＭ）およびＧＰＲＳ移動管理（ＧＭＭ）６２６を含む。さらに、ＰＳ制御プレーン６１１のＮＡＳ部分６１４は、ＳＭ／ＲＡＢＭ６２４およびＧＳＭＳ６２８を含む。
【０１４６】
ＣＣ６１８は、回路交換サービス向けのコール管理信号を提供する。ＳＭ／ＲＡＢＭ６２４のセッション管理部分は、ＰＤＰコンテキスト活性化、不活性化および修正を提供する。ＳＭ／ＲＡＢＭ６２４は、また、サービスの質交渉にも提供する。
【０１４７】
ＳＭ／ＲＡＢＭ６２４のＲＢＡＭ部分の主機能は、ＰＤＰコンテキストを無線アクセスベアラに接続することである。このように、ＳＭ／ＲＡＢＭ６２４は、無線ベアラの設定、修正、および解放を担っている。
【０１４８】
アクセス層６１６中のＣＳ制御プレーン６１０およびＰＳ制御プレーン６１１は、無線リソース制御（ＲＲＣ）６１７の上に座している。
【０１４９】
ＰＳユーザプレーン６３０内のＮＡＳ部分６１４は、アプリケーション層６３８、ＴＣＰ／ＵＤＰ層６３６、および、ＰＤＰ層６３４を含む、ＰＤＰ層６３４は、例えば、インターネットプロトコル（ＩＰ）を含む。
【０１５０】
ＰＳユーザプレーン６３０内のアクセス層６１６は、パケットデータ収束プロトコル（ＰＤＣＰ）６３２を含む。ＰＤＣＰ６３２は、ＵＥとＲＮＣとの間で、ＴＣＰ／ＩＰプロトコルを運搬するのに適切なＷＣＤＭＡプロトコルを作成するように設計され（図８に見られるように）、オプションとして、ＩＰトラフィックストリームプロトコルヘッダ圧縮・解凍用である。
【０１５１】
ＵＭＴＳ Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）６４０およびＭｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ）層６５０は、ＵＭＴＳ無線インターフェースのデータリンクサブレイヤを形成し、ＲＮＣノードおよびＵｓｅｒ Ｅｑｕｉｐｍｅｎｔ上に存在する。
【０１５２】
層１（Ｌ１）ＵＭＴＳ層（物理層６６０）は、ＲＬＣ／ＭＡＣ層６４０および６５０の下にある。この層は、通信用の物理層である。
【０１５３】
以上の記述は、様々な移動体デバイス上でインプリメントされ得るが、一つの移動体デバイスの例が、以下に、図７と関連付けて述べられる。ここで、図７を参照する。
【０１５４】
ＵＥ１１００は、少なくとも音声およびデータ通信能力を有する双方向ワイヤレス通信デバイスであることが好ましい。ＵＥ１１００は、インターネット上の他のコンピュータシステムと通信する能力を有することが好ましい。提供された正確な機能性に依存して、ワイヤレスデバイスは、例えば、データメッセージデバイス、双方向ページャ、ワイヤレスｅメールデバイス、データメッセージ能力を備えた携帯電話、ワイヤレスインターネット機器、または、データ通信デバイスであり得る。
【０１５５】
ＵＥ１１００が双方向通信可能な場合、ＵＥ１１００は、受信機１１１２および送信機１１１４を含む通信サブシステム１１１１、ならびに、１つ以上の好ましくは内蔵または内部のアンテナエレメント１１１６および１１１８、局部発振器（ＬＯ）１１１３、および、デジタル信号プロセッサ（ＤＳＰ）１１２０のような処理モジュールのような関連するコンポーネントを組み込む。通信分野の当業者には明らかなように、通信サブシステムの特定の設計は、そのデバイスが動作することを意図される通信ネットワークに依存する。例えば、ＵＥ１１００は、ＧＰＲＳネットワークまたはＵＭＴＳネットワーク内で動作するように設計された通信サブシステムを含み得る。
【０１５６】
ネットワークアクセス必要条件はまた、ネットワーク１１１９のタイプに依存して変化する。例えば、ＵＭＴＳおよびＧＰＲＳネットワークにおいて、ネットワークアクセスは、ＵＥ１１００の加入者またはユーザと関連する。例えば、ＧＰＲＳ移動体デバイスは、従って、ＧＰＲＳネットワークで作動するために、加入者識別モジュール（ＳＩＭ）カードを要求する。ＵＭＴＳにおいては、ＵＳＩＭまたはＳＩＭモジュールが要求される。ＣＤＭＡにおいては、ＲＵＩＭカードまたはモジュールが要求される。これらは、本明細書においては、ＵＩＭインターフェースと称される。有効なＵＩＭインターフェースがなければ、移動体デバイスは完全には機能しない。局所または非ネットワーク通信機能、および例えば緊急通話など法的に要求される機能が（もしあれば）利用し得るが、しかし、移動体デバイス１１００は、ネットワーク１１００での通信を含む任意の他の機能を実行することはできない。ＵＩＭインターフェース１１４４は通常、ディスケットまたはＰＣＭＣＩＡカードのように、カードが挿入されかつ取り出され得るカードスロットに似ている。ＵＩＭカードは、約６４Ｋのメモリを有し得て、かつ多くのキー構成１１５１、ならびに例えば識別および加入者関連の情報のような他の情報１１５３を保持し得る。
【０１５７】
要求されたネットワーク登録または起動手順が完了したときには、ＵＥ１１００は、ネットワーク１１１９で通信信号を送受信し得る。通信ネットワーク１１１９を通して、アンテナ１１１６によって受信された信号は、受信機１１１２へ入力され、受信機１１１２は、例えば信号増幅、周波数下方変換、フィルタリング、チャネル選択などのような普通の受信機機能を、および図７に示される例示的システムでは、アナログデジタル（Ａ／Ｄ）変換を実行し得る。受信された信号のＡ／Ｄ変換により、例えば、ＤＳＰ１１２０で実行される復調および復号のようなさらに複雑な通信機能が可能になる。同様に、送信される信号は、例えばＤＳＰ１１２０によって、変調およびコード化を含んで、処理されて、かつデジタルアナログ変換、周波数上方変換、フィルタリング、増幅およびアンテナ１１１８を介しての通信ネットワーク１１１９での送信のために送信機１１１４へ入力される。ＤＳＰ１１２０は、通信信号を処理するのみならず、受信機および送信機の制御も提供する。例えば、受信機１１１２および送信機１１１４において通信信号に適用されるゲインは、ＤＳＰ１１２０にインプリメントされた自動ゲイン制御アルゴリズムを通して、適応可能に制御され得る。
【０１５８】
ネットワーク１１１９は、サーバ１１６０および他の要素（図示されず）を含む、複数のシステムとさらに通信し得る。例えば、ネットワーク１１１９は、さまざまなサービスレベルでさまざまなクライアントに便宜を図るために、企業システムとウェブクライアントシステムとの両方と通信し得る。
【０１５９】
ＵＥ１１００は、デバイスの全体的な作動を制御するマイクロプロセッサ１１３８を含むほうが好ましい。少なくともデータ通信を含む通信機能は、通信サブシステム１１１１を通じ実行される。マイクロプロセッサ１１３８はまた、例えば表示デバイス１１２２、フラッシュメモリ１１２４、ランダムアクセスメモリ（ＲＡＭ）１１２６、補助入力／出力（Ｉ／Ｏ）サブシステム１１２８、シリアルポート１１３０、キーボード１１３２、スピーカ１１３４、マイクロフォン１１３６、近距離通信サブシステム１１４０および一般的に１１４２として指定される任意の他のデバイスサブシステムのようなさらなるデバイスサブシステムとも相互作用する。
【０１６０】
図７に示されるサブシステムの一部は、通信関連の機能を実行する一方、他のサブシステムは、「レジデント」またはオンデバイス（ｏｎ−ｄｅｖｉｃｅ）機能を提供し得る。特に、例えばキーボード１１３２および表示デバイス１１２２のような一部のサブシステムは、例えば通信ネットワークで送信するためのテキストメッセージを入力するような通信関連機能と、例えば計算機またはタスクリストのようなデバイスレジデント機能との両方のために使用され得る。
【０１６１】
マイクロプロセッサ１１３８によって使用されるオペレーティングシステムソフトウエアは、例えばフラッシュメモリ１１２４のような永続的な記憶デバイスに格納されることが好ましいが、フラッシュメモリ１１２４の代わりに、読み出し専用メモリ（ＲＯＭ）または類似の格納要素（図示されず）であり得る。当業者は、作動システム、特定のデバイスアプリケーションまたはその部分は、例えばＲＡＭ１１２６のような揮発性のメモリに一時的に書き込み得るということを理解する。受信された通信信号はまた、ＲＡＭ１１２６にも格納され得る。さらに、一意的な識別子が、好ましくも読み出し専用メモリに格納される。
【０１６２】
図示されているように、フラッシュメモリ１１２４は、コンピュータプログラム１１５８ならびにプログラムデータ格納１１５０、１１５２、１１５４および１１５６両方に対する異なるエリアに分離され得る。これらの異なる格納タイプは、各プログラムが、それら自身のデータ格納必要条件のために、フラッシュメモリ１１２４の一部を割り当て得ることを示す。マイクロプロセッサ１１３８は、そのオペレーティングシステム機能に加えて、移動体デバイスでソフトウエアアプリケーションの実行を可能にすることが好ましい。例えば、少なくともデータおよび音声通信アプリケーションを含む、基本オペレーションを制御する所定のアプリケーションのセットは、製造中にＵＥ１１００に通常インストールされる。好ましいソフトウエアアプリケーションは、例えば、しかし限定されず、Ｅメール、カンレンダーイベント、ボイスメール、アポイントメントおよびタスク項目のような、移動体デバイスのユーザに関連するデータ項目を組織化および管理する能力を有するパーソナルインフォメーションマネジャー（ＰＩＭ）アプリケーションであり得る。当然、１つ以上のメモリ記憶デバイスが、ＰＩＭデータ項目の格納を助長するために、移動体デバイスで利用し得る。そのようなＰＩＭアプリケーションは、無線ネットワーク１１１９を介して、データ項目を送受信する能力を有することが好ましい。好ましい実施形態において、ＰＩＭデータ項目は、格納されまたはホストコンピュータシステムと関連づけられる移動体デバイスユーザの対応するデータ項目と、無線ネットワーク１１１９を介してシームレスに（ｓｅａｍｌｅｓｓ）に統合され、同期されおよび更新される。さらなるアプリケーションがまた、ネットワーク１１１９、補助入力／出力（Ｉ／Ｏ）サブシステム１１２８、シリアルポート１１３０、近距離通信サブシステム１１４０または任意の他の適切なサブシステム１１４２を通して、移動体デバイス１１００にロードされ得て、かつ、マイクロプロセッサ１１３８による実行のために、ＲＡＭ１１２６にまたは好ましくは不揮発性の記憶デバイス（図示されず）に、ユーザによってインストールされ得る。アプリケーションインストールにおけるそのような柔軟性は、デバイスの機能性を高め、かつ向上したオンデバイス機能、通信関連機能またはその両方を提供し得る。例えば、安全な通信アプリケーションは、電子商取引機能および他のそのような金融取引が、ＵＥ１１００を使用して実行されることを可能にする。しかしながら、これらのアプリケーションは、上記によると、多くの場合、通信業者によって同意される必要がある。
【０１６３】
データ通信モードにおいて、例えばテキストメッセージまたはウェブページダウンロードのような受信された信号は、通信サブシステム１１１１によって処理され、かつマイクロプロセッサ１１３８に入力され、マイクロプロセッサ１１３８は、表示デバイス１１２２へまたはあるいは補助Ｉ／Ｏデバイス１１２８への入力のために、受信された信号をさらに処理することが好ましい。ＵＥ１１００のユーザはまた、好ましくは完全な英数字キーボードまたは電話タイプのキーパッドであるキーボード１１３２を、表示デバイス１１２２およびおそらく補助Ｉ／Ｏデバイス１１２８と共に使用して、例えばＥメールメッセージのようなデータ項目を構成し得る。そのように構成された項目は、通信サブシステム１１１１を通して、通信ネットワーク上で送信され得る。
【０１６４】
音声通信に対して、ＵＥ１１００の全体的な作動は同様であるが、ただし、受信された信号は、スピーカ１１３４に出力されることが好ましく、送信のための信号は、マイクロフォン１１３６によって生成される点は除く。例えば音声メッセージ録音サブシステムのような代替案の音声またはオーディオＩ／Ｏサブシステムもまた、ＵＥ１１００でインプリメントされ得る。音声またはオーディオ信号出力は主にスピーカ１１３４を通して達成されることが好ましいけれども、表示デバイス１１２２もまた、例えば発呼者の識別、音声通話の継続時間または他の音声通話関連情報の指示を提供するために使用され得る。
【０１６５】
図７におけるシリアルポート１１３０は通常、ユーザのデスクトップコンピュータ（図示されず）との同期が望まれる携帯情報端末（ＰＤＡ）タイプの移動体デバイスにインプリメントされる。そのようなポート１１３０は、ユーザが、外部デバイスまたはソフトウエアアプリケーションを通して、好みを設定することを可能にし、かつ無線通信ネットワークを経由する以外にもＵＥ１１００に情報またはソフトウエアダウンロードを提供することによって移動体デバイス１１００の能力を拡張する。代替案のダウンロード経路は、例えば、安全なデバイス通信を可能にするために、直接的な故に確実で信用のある接続を通して、デバイスに暗号化キーをロードするために使用され得る。
【０１６６】
あるいは、シリアルポート１１３０は他の通信のために使用され得、かつユニバーサルシリアルバス（ＵＳＢ）ポートとして含み得る。インターフェースが、シリアルポート１１３０と関連する。
【０１６７】
例えば、近距離通信サブシステムのような他の通信サブシステム１１４０は、ＵＥ１１００と必ずしも類似のデバイスである必要はない異なるシステムまたはデバイスとの間の通信を提供する、さらなる随意のコンポーネントである。例えば、サブシステム１１４０は、同様にイネーブル化されたシステムおよびデバイスとの通信を提供するために、赤外線デバイスならびに関連回路およびコンポーネント、またはＢｌｕｅｔｏｏｔｈＴＭ通信モジュールを含み得る。
【０１６８】
ここで図８が参照される。図８は、無線通信ネットワークを通して通信するＵＥ８０２を含む通信システム８００のブロック図である。
【０１６９】
ＵＥ８０２は、複数のＮｏｄｅ Ｂ ８０６のうち１つと無線で通信する。各Ｎｏｄｅ
Ｂ ８０６は、エアーインタフェース処理および一部の無線リソース管理機能に対する責任を負う。Ｎｏｄｅ Ｂ ８０６は、ＧＳＭ／ＧＰＲＳネットワークにおけるＢａｓｅ
Ｔｒａｎｓｃｅｉｖｅｒ Ｓｔａｔｉｏｎと類似の機能性を提供する。
【０１７０】
図８の通信システム８００において示される無線リンクは、１つ以上の異なるチャネル、一般的には異なる無線周波数（ＲＦ）チャネル、および無線ネットワークとＵＥ８０２との間で使用される関連プロトコルを表す。Ｕｕエアーインタフェース８０４はＵＥ８０２とＮｏｄｅ Ｂ ８０６との間で使用される。
【０１７１】
ＲＦチャネルは、一般的に、全体的な帯域幅の制限、およびＵＥ８０２の制限されたバッテリーパワーのために、節約されるべき必要のある限りあるリソースである。当業者は、実際の実用における無線ネットワークは、所望の全体的なネットワーク利用可能範囲の広がりに依存して何百ものセルを含み得るということを理解するであろう。すべての関連のコンポーネントは複数のスイッチおよびルータ（図示されず）によって接続され得て、複数のネットワークコントローラによって制限され得る。
【０１７２】
各Ｎｏｄｅ Ｂ ８０６は、無線ネットワークコントローラ（ＲＮＣ）８１０と通信する。ＲＮＣ８１０は、そのエリアにおける無線リソースの制限に対する責任を負う。１つのＲＮＣ８１０は複数のＮｏｄｅ Ｂ ８０６を制御する。
【０１７３】
ＵＭＴＳネットワークにおけるＲＮＣ８１０は、ＧＳＭ／ＧＰＲＳネットワークにおけるＢａｓｅ Ｓｔａｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ（ＢＳＣ）機能と同等の機能を提供する。しかしながら、ＲＮＣ８１０は、例えば、ＭＳＣおよびＳＧＳＮを含まない自律的なハンドオーバ管理を含む、より多くの情報を含む。
【０１７４】
Ｎｏｄｅ Ｂ ８０６とＲＮＣ８１０との間で使用されるインターフェースはＩｕｂインターフェース８０８である。ＮＢＡＰ（Ｎｏｄｅ Ｂアプリケーションパート）の信号を送るプロトコルが、３ＧＰＰ ＴＳ２５．４３３ Ｖ３．１１．０（２００２−０９）および３ＧＰＰ ＴＳ ２５．４３３ Ｖ５．７．０（２００４−０１）に規定されているように、主に使用される。
【０１７５】
Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（ＵＴＲＡＮ）８２０は、ＲＮＣ８１０、Ｎｏｄｅ Ｂ ８０６およびＵｕエアーインタフェース８０４を備える。
【０１７６】
回線交換トラフィックが、Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｒｅ（ＭＳＣ）８３０へ回送される。ＭＳＣ８３０は、呼び出しを行い、加入者またはＰＳＴＮ（図示されず）からデータを取り、かつ受けるコンピュータである。
【０１７７】
ＲＮＣ８１０とＭＳＣ８３０との間のトラフィックは、Ｉｕ−ＣＳインターフェース８２８を使用する。Ｉｕ−ＣＳインターフェース８２８は、ＵＴＲＡＮ８１０と中心音声ネットワークとの間で音声トラフィックを（通常）運びかつ信号を送るための回線交換接続である。使用される主な信号プロトコルはＲＡＮＡＰ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）である。ＲＡＮＡＰプロトコルは、（下記により詳細に規定される）ＭＳＣ８３０またはＳＳＧＮ８５０であり得るＣｏｒｅ Ｎｅｔｗｏｒｋ ８２１とＵＴＲＡＮ８２０との間でのＵＭＴＳ信号発信に使用される。ＲＡＮＡＰプロトコルは、３ＧＰＰ ＴＳ ２５．４１３ Ｖ３．１１．１（２００２−０９）およびＴＳ ２５．４１３ Ｖ５．７．０（２００４−０１）に規定される。
【０１７８】
ネットワークオペレータに登録されたすべてのＵＥ８０２に対して、パーマネントデータ（例えばＵＥ１０２ユーザのプロファイルのような）および一時的なデータ（例えばＵＥ８０２の現在位置のような）はホームロケーションレジストリ（ＨＬＲ）８３８に格納される。ＵＥ８０２への音声通話の場合には、ＨＬＲ８３８が、ＵＥ８０２の現在位置を決定するためにクエリされる。ＭＳＣ８３０のＶｉｓｉｔｏｒ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ（ＶＬＲ）８３６が、位置エリアのグループに対する責任を負い、かつ現在その責任のエリア内にある移動局のデータを格納する。これは、より速いアクセスのために、ＨＬＲ８３８からＶＬＲ８３６へ送信されたパーマネント移動局データの部分を含む。しかしながら、ＭＳＣ８３０のＶＬＲ８３６はまた、例えば一時的な識別のような局所データを割り当てかつ格納し得る。ＵＥ８０２はまた、ＨＬＲ８３８によって、システムアクセスについて認証される。
【０１７９】
パケットデータは、Ｓｅｒｖｉｃｅ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ （ＳＧＳＮ）８５０を介して回送される。ＳＧＳＮ８５０は、ＲＮＣとＧＰＲＳ／ＵＭＴＳネットワークにおける中心ネットワークとの間の出入り口であり、その地理的サービスエリア内でＵＥとの相互のデータパケットの引渡しに対する責任を負う。Ｉｕ−ＰＳインターフェース８４８は、ＲＮＣ８１０とＳＧＳＮ８５０との間で使用され、ＵＴＲＡＮ８２０と中心データネットワークとの間でデータトラフィックを（一般的に）運びかつ信号を送るためのパケット交換接続である。使用される主な信号プロトコルは（上記の）ＲＡＮＡＰである。
【０１８０】
ＳＳＧＮ８５０は、Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ （ＧＧＳＮ）８６０と通信する。ＧＧＳＮ８６０は、ＵＭＴＳ／ＧＰＲＳネットワークと、例えばインターネットまたは個人のネットワークのような他のネットワークとの間のインターフェースである。ＧＧＳＮ８６０は、Ｇｉインターフェース上で、パブリックデータネットワークＰＤＮ８７０へ接続される。
【０１８１】
当業者は、無線ネットワークは、図８に明確には示されていないが、おそらく他のネットワークを含む、他のシステムに接続され得るということを理解する。ネットワークは、通常は、たとえ交換される実際のパケットデータがない場合であっても。少なくとも何らかの種類のページングおよびシステム情報を、進行中の基礎に基づいて、送信している。ネットワークは多くの部分から成るものの、これらの部分はすべて共に働いて、無線リンクにおいて特定の挙動を生じる。
【０１８２】
本明細書に記述された実施形態は、本出願の技術の要素に対応する要素を有する構造、システムまたは方法の例である。ここに記された記載内容に基づいて、当業者は、本出願の技術の要素に類似して対応する代替の要素を有する実施形態を作成し使用することができる。従って本出願の技術の意図された範囲は、本明細書に記述されたとおりの本出願の技術と異ならない他の構造、システムまたは方法を含み、かつ本明細書に記述された通りの本出願の技術と本質的に異ならない他の構造、システムまたは方法をさらに含む。
【符号の説明】
【０１８３】
１１０ ＲＲＣアイドル状態
１２０ ＲＲＣ接続状態
１２２ ＣＥＬＬ＿ＤＣＨ状態、
１２４ ＣＥＬＬ＿ＦＡＣＨ状態、
１２６ ＣＥＬＬ＿ＰＣＨ状態
１２８ ＵＲＡ＿ＰＣＨ状態
【技術分野】
【０００１】
（出願の分野）
本出願は、ユーザ設備（ＵＥ）とユニバーサル陸上無線アクセスネットワーク（ＵＴＲＡＮ）との間の無線リソース制御に関し、特に、ＵＭＴＳネットワーク内の既存の信号伝達接続の解放に関する。
【背景技術】
【０００２】
（背景）
ユニバーサル移動電気通信システム（ＵＭＴＳ）は、テキスト、デジタル化された音声、映像、およびマルチメディアを送信する広帯域パケットベースのシステムである。これは、第三世代に対する標準として認知され、広帯域符号分割多重アクセス（Ｗ−ＣＤＭＡ）に一般的に基づく。
【０００３】
ＵＭＴＳネットワークにおいて、プロトコルスタックの無線リソース制御（ＲＲＣ）パーツは、ＵＥとＵＴＲＡＮとの間の無線リソースの割り当て、構成、および解放を担う。このＲＲＣプロトコルは、詳細には、３ＧＧＰの仕様書ＴＳ ２５．３３１に記載されている。ＵＥが入り得る２つの基本的モードは、「アイドルモード」および「ＵＴＲＡ接続モード」として定義されている。ＵＴＲＡは、ＵＭＴＳ陸上無線アクセスを略したものである。アイドルモードにおいて、ＵＥが任意のユーザデータを送信したいときはいつでも、あるいはＵＴＲＡＮまたはサービングＧＰＲＳサポートノード（ＳＧＳＮ）が、ページングに応答して、それをページングしてプッシュサーバのような外部データネットワークから受信するときはいつでも、ＵＥは、ＲＲＣ接続をリクエストするように要求される。アイドルモードおよび接続モードの挙動は、３ＧＰＰの仕様書のＴＳ ２５．３０４およびＴＳ ２５．３３１に詳細に記載されている。
【０００４】
ＵＴＲＡ ＲＲＣ接続モードにおいて、デバイスは、４つの状態の１つであり得る。これらは、
ＣＥＬＬ＿ＤＣＨ：専用チャネルが、データ交換するために、この状態で、アップリンクおよびダウンリンク中のＵＥに割り当てられる。ＵＥは、３ＧＰＰ ２５．３３１に概略されたアクションを実行しなくてはならない。
ＣＥＬＬ＿ＦＡＣＨ：この状態において、ユーザ設備には専用チャネルは割り当てられない。その代わりに、共通チャネルが、少量のバースティ（ｂｕｒｓｔｙ）なデータを交換するために使用される。ＵＥは、３ＧＰＰ ２５．３３１（３ＧＰＰ ＴＳ ２５．３０４で規定されるセル選択プロセスを含む）に概略されるようなアクションを実行しなくてはならない。
ＣＥＬＬ＿ＰＣＨ：ＵＥは、不連続受信（ＤＲＸ）を使用して、ページングインジケータチャネル（ＰＩＣＨ）を介する放送メッセージとページングとをモニタする。アップリンク活動は可能ではない。ＵＥは、３ＧＰＰ ２５．３３１（３ＧＰＰ ＴＳ ２５．３０４で規定されるようなセル選択プロセスを含む）に概略されるようなアクションを実行しなくてはならない。ＵＥは、セル再選択の後に、ＣＥＬＬ ＵＰＤＡＴＥ手順を実行しなくてはならない。
ＵＲＡ＿ＰＣＨ：ＵＥは、不連続受信（ＤＲＸ）を用い、ページングインディケータチャネル（ＰＩＣＨ）を介する放送メッセージおよびページングをモニタする。アップリンク活動は可能ではない。ＵＥは、３ＧＰＰ ２５．３３１（３ＧＰＰ ＴＳ ２５．３０４で規定されるようなセル選択プロセスを含む）に概略されるようなアクションを実行しなくてはならない。ＵＲＡ ＵＰＤＡＴＥ手順が、ＵＴＲＡＮ登録エリア（ＵＲＡ）再選択をのみ介してトリガされる点を除いて、この状態はＣＥＬＬ＿ＰＣＨに類似する。
【０００５】
アイドルモードから接続モードへの移行とこの逆の移行とは、ＵＴＲＡＮによって制御される。アイドルモードＵＥが、ＲＲＣ接続をリクエストするとき、ネットワークは、ＵＥをＣＥＬＬ＿ＤＣＨまたはＣＥＬＬ＿ＦＡＣＨ状態に移動させるかどうかを判断する。ＵＥがＲＲＣ接続モードにあるとき、この場合も、ＲＲＣ接続を解放するときを決定するのは、またネットワークである。ネットワークは、接続を解放する前に、あるいは場合によっては接続を解放する代わりに、ＵＥを一つのＲＲＣ状態から別の状態に移動させ得る。状態移行は、ＵＥとネットワークとの間でのデータ活性または不活性によって、典型的にはトリガされる。ネットワークは、所与のアプリケーションに対するデータ交換がいつ完了したかを知り得ないので、ネットワークは、ＵＥへの／からのさらなるデータを期待して、ＲＲＣ接続をしばらくの間、典型的には保つ。これは、コール設定および引き続く無線ベアラ設定の待ち時間を減らすために、典型的に行われる。ＲＲＣ接続解放メッセージは、ＵＴＲＡＮによって送信され得るのみである。このメッセージは、ＵＥとＵＴＲＡＮとの間の信号リンク接続および全ての無線ベアラを解放する。
【０００６】
上記における問題は、ＵＥ上のアプリケーションがそのデータ移行を完了し、さらなるデータ交換を一切期待できない場合ですら、そのアプリケーションは、ネットワークがＵＥを正しい状態に移動させることを、ネットワークを待っていることである。ネットワークは、ＵＥ上のアプリケーションが自身のデータ交換を完了した事実に気付いていないことさえあり得る。例えば、ＵＥ上のアプリケーションは、それ自身の承認ベースのプロトコルを使用して、ＵＭＴＳコアネットワークに接続されるそのアプリケーションサーバとデータ交換し得る。例えば、自身に保証された配信をインプリメントするＵＤＰ／ＩＰを介してランするアプリケーションである。そのような場合において、ＵＥは、アプリケーションサーバが全てのデータパケットを送信または受信したかどうかを知っており、任意のさらなるデータ交換が生じるかどうかを決定するためにより良い位置にあり、そして、それゆえ、いつパケットサービス（ＰＳ）ドメインと関連するＲＲＣ接続を終了するかを決定する。ＵＴＲＡＮは、いつＲＲＣ接続状態が異なる状態に、あるいはアイドルモードへと変化するかを制御するので、また、ＵＴＲＡＮがＵＥと外部サーバとの間におけるデータ伝送の状態に気付いていないという事実により、ＵＥは、要求される状態またはモードよりも、さらに高いデータレートおよび強いバッテリ状態に留まることになり、それによって、バッテリ寿命を使い果たす。このことは、また無線ベアラリソースが不必要に使用中のまま保たれるという事実によって、ネットワークリソースを無駄使いさせる結果となる。
【０００７】
上述に対する一つの解決策は、ＵＥがデータトランザクションを終了されたと、ＵＥが認識するときに、ＵＥにＵＴＲＡＮへ信号伝達解放指示（ｓｉｇｎａｌｉｎｇ ｒｅｌｅａｓｅ ｉｎｄｉｃａｔｉｏｎ）を送信するようにさせることである。３ＧＰＰ ＴＳ ２５．３３１仕様書の８．１．１４．３節に従うと、ＵＴＲＡＮは、ＵＥから信号伝達接続解放指示を受信すると、信号伝達接続を解放し得、その結果、ＵＥはアイドルモードに移行する。上述における問題は、信号伝達解放指示が、警告であると考慮され得ることである。ネットワークは、ＧＭＭサービスリクエストの失敗、ＲＡＵの失敗、あるいはアタッチの失敗が生じたときに、典型的には、信号伝達解放指示を期待するのみである。ＵＥが信号伝達解放をリクエストするときに警告を発することは、ネットワークでの性能モニタおよび警告モニタを非効率なものとする結果になる。
【発明の概要】
【課題を解決するための手段】
【０００８】
本発明は、以下の手段を提供する。
【０００９】
（項目１）
ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法であって、
ａ．該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、
ｂ．該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、
ｃ．該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、
ｄ．該信号伝達接続解放指示を該無線ネットワークで受信するステップと、
ｅ．該理由をフィルタリングし、警告を発するかどうかを判断するステップと
を包含する、方法。
【００１０】
（項目２）
上記理由は、異常な状態である、項目１に記載の方法。
【００１１】
（項目３）
上記異常な状態は、タイマの時間切れである、項目２に記載の方法。
【００１２】
（項目４）
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびＧＭＭサービスリクエストタイマからなる群から選択される、項目３に記載の方法。
【００１３】
（項目５）
上記理由は、ＰＳデータセッションを終了して、それによってアイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目１に記載の方法。
【００１４】
（項目６）
上記フィルタリングするステップは、上記理由が異常な状態であるとき、警告を発する、項目１に記載の方法。
【００１５】
（項目７）
上記フィルタリングするステップは、上記理由が上記ユーザ設備によるアイドル移行リクエストであるとき、上記信号伝達接続解放指示を無視する、項目１に記載の方法。
【００１６】
（項目８）
信号伝達解放指示理由を処理するのに適合したシステムであって、該システムは、
ａ．ユーザ設備であって、該ユーザ設備は、ネットワークと通信するのに適合した無線を含む無線サブシステムと；デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと；メモリと；ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有する、ユーザ設備であって、
ｉ．信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、
ｉｉ．該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付する手段と、
ｉｉｉ．該添付信号伝達接続解放指示を該無線ネットワークに送信する手段と
を有することによって特徴付けられる、ユーザ設備と、
ｂ．該ユーザ設備と通信するのに適合した無線ネットワークであって、
ｉ．該信号伝達接続解放指示を受信する手段と、
ｉｉ．該理由をフィルタリングし、警告を発するかどうかを判断する手段と
によってさらに特徴付けられる、無線ネットワークと
を備える、システム。
【００１７】
（項目９）
上記理由は、異常な状態である、項目８に記載のシステム。
【００１８】
（項目１０）
上記異常な状態は、タイマの時間切れである、項目９に記載のシステム。
【００１９】
（項目１１）
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびＧＭＭサービスリクエストタイマからなる群から選択される、項目１０に記載のシステム。
【００２０】
（項目１２）
上記理由は、ＰＳデータセッションを終了し、アイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目１１に記載のシステム。
【００２１】
（項目１３）
上記フィルタリングする手段は、上記理由が異常な状態であるとき、警告を発するのに適合する、項目８に記載のシステム。
【００２２】
（項目１４）
上記フィルタリングする手段は、上記理由が上記ユーザ設備によるアイドル移行リクエストであるとき、上記信号伝達接続解放指示を無視するのに適合する、項目８に記載のシステム。
【００２３】
（項目１５）
無線ネットワークで改善された警告を追跡するために、ユーザ設備で信号伝達解放指示理由を処理する方法であって、
ａ．信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、
ｂ．該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、
ｃ．該理由が添付された該添付信号伝達接続解放指示を送信し、これによって、該信号伝達接続解放指示の該理由を識別する該信号伝達接続解放をリクエストする、ステップと
を包含する、方法。
【００２４】
（項目１６）
上記理由は、異常な状態である、項目１５に記載の方法。
【００２５】
（項目１７）
上記異常な状態は、タイマの時間切れである、項目１６に記載の方法。
【００２６】
（項目１８）
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびＧＭＭサービスリクエストタイマからなる群から選択される、項目１７に記載の方法。
【００２７】
（項目１９）
上記理由は、ＰＳデータセッションを終了し、アイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目１５に記載の方法。
【００２８】
（項目２０）
ネットワーク内で、信号伝達解放指示理由を提供するのに適合したユーザ設備であって、該ユーザ設備は、該ネットワークと通信するのに適合した無線を含む無線サブシステムと；デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと；メモリと；ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有し、該ユーザ設備は、
ａ．信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、
ｂ．該信号伝達接続解放指示に、該信号伝達接続解放指示に対する理由を添付する手段と、
ｃ．該理由を含む該添付信号伝達接続解放指示を送信し、これによって、該信号伝達接続解放指示の該理由を該信号伝達接続解放指示とともに識別する手段と
を有することによって特徴付けられる、ユーザ設備。
【００２９】
（項目２１）
信号伝達接続の解放を容易にするためのユーザ設備用装置であって、該装置は、
ａ．信号伝達接続解放指示が、送信されるべきかどうかをチェックするように構成されたチェッカと、
ｂ．信号伝達接続解放指示が送信されるべきであるという該チェッカによる指示に応答して、該信号伝達接続解放指示を送信するように構成された信号伝達接続解放指示センダであって、該信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む信号伝達解放指示を含む、信号伝達接続解放指示センダと
を備える、装置。
【００３０】
（項目２２）
上記チェッカは、上記信号伝達接続解放指示を送信するのに引き続き、該信号伝達接続解放指示の配信を確認する前に、上記ユーザ設備の信号伝達接続が必要とされるかどうかをチェックするようにさらに構成される、項目２１に記載の装置。
【００３１】
（項目２３）
上記信号伝達接続解放指示センダは、上記信号伝達接続解放指示を再送信するようにさらに構成される、項目２２に記載の装置。
【００３２】
（項目２４）
信号伝達接続解放指示によって、動作するネットワーク装置であって、該ネットワーク装置は、
ａ．該信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験して、該信号伝達解放指示理由フィールドが異常な状態を指示するかどうかをチェックするように構成された試験機と、
ｂ．該試験機による試験が、該信号伝達解放指示理由フィールドが該異常な状態を指示すると判断する場合、警告を選択的に生成するように構成された警告生成器と
を備える、ネットワーク装置。
【００３３】
（項目２５）
上記ネットワーク装置は、複数のロジカル層を備え、上記試験機は、該複数のロジカル層の第一のロジカル層で具現化され、該試験機は、該複数のロジカル層の第二のロジカル層に、信号伝達接続解放をリクエストするようにさらに構成される、項目２４に記載のネットワーク装置。
【００３４】
（摘要）
ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法およびシステムであって、該方法は、該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、該信号伝達接続解放指示を該無線ネットワークで受信するステップと、該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する、方法。
【００３５】
（詳細な説明）
本システムおよび方法は、ＲＲＣ接続モードから、より効率的なバッテリ状態またはモードへ移行させる一方で、信号伝達解放指示の理由がＵＥのアイドル移行リクエストである場合、ネットワークが、信号伝達解放指示を警告と考慮しないこと保証することを提供する。特に、本方法および装置は、特定されたコアネットワークドメインに対する信号接続の終了をＵＥが開始すること、または、移行が一つの接続状態から他の接続状態へと生じるべきであるとＵＴＲＡＮに指示することのいずれかに基づいて移行を提供する。以下の説明は、ＵＭＴＳの例示的なインプリメンテーションに関して記載される。しかしながら、本発明の教示は、他の無線通信システムにも同様に適用可能であることは、理解されるべきである。
【００３６】
特に、ＵＥ上のアプリケーションは、それがデータの交換を用いてなされたと決定する場合、好適には、それは「なされた」との指示を、ＵＥソフトウェアの「ＲＲＣ接続マネージャ」コンポーネントへ送信する。ＲＲＣ接続マネージャは、関連パケットデータプロトコル（ＰＤＰ）コンテキスト、関連パケット交換（ＰＳ）無線ベアラ、および関連回路交換（ＣＳ）無線ベアラなどの全ての現行のアプリケーション（一つまたは複数のプロトコルを介したサービスを提供するものを含む）を追跡し続ける。ＰＤＰコンテキストは、ＵＭＴＳコアネットワークにわたってランするＵＥとＰＤＮ（公衆データネットワーク）との間の論理関係である。ＵＥ上の一つまたは複数のアプリケーション（例えば、ｅメールアプリケーションおよびブラウザアプリケーション）は、一つのＰＤＰコンテキストと関連し得る。一部の場合において、ＵＥ上の一つのアプリケーションは、一次ＰＤＰコンテキストと関連し、複数のアプリケーションは、二次ＰＤＰコンテキストに結合され得る。ＲＲＣ接続マネージャは、同時に活性であるＵＥ上の異なるアプリケーションから、「なされた」との指示を受信する。例えば、ユーザは、ウェブを閲覧している間に、プッシュサーバからｅメールを受信し得る。ｅメールアプリケーションが承認を送信した後、それは、そのデータトランザクションを完了したことを指示し得るが、しかしながら、ブラウザアプリケーションは、そのような指示を送信し得ない。活性なアプリケーションからのそのような指示の合成状態に基づいて、ＵＥソフトウェアは、それが、コアネットワークパケットサービスドメインの信号伝達接続解放を開始し得る前に、どの程度待機するべきかを決定し得る。この場合における遅延は、そのアプリケーションがデータ交換を真に終了させ、ＲＲＣ接続を要求しないことを保証するために導入され得る。その遅延は、トラフィック履歴および／またはアプリケーションプロフィールに基づいてダイナミックであり得る。どのアプリケーションも一切データを交換することが期待されないという可能性が幾分かあると、ＲＲＣ接続マネージャが判断するときはいつも、ＲＲＣ接続マネージャは適切なドメイン（例えば、ＰＳドメイン）に対して、信号伝達接続解放指示手順を送信し得る。あるいは、ＵＴＲＡＮに接続されたモード内において、状態移行のリクエストを送信し得る。
【００３７】
上述の判断はまた、ネットワークが、ＵＲＡ＿ＰＣＨ状態およびこの状態への移行挙動をサポートするかどうかを考慮し得る。
【００３８】
ＵＥによって開始されたアイドルモードへの移行は、ＲＲＣ接続モードの任意の状態から生じ得、ネットワークをＲＲＣ接続から解放させ、ＵＥをアイドルモードへと移動させることによって終わる。当業者によって理解されるように、アイドルモード中のＵＥは、接続状態中のＵＥよりも、バッテリがはるかに低い。
【００３９】
しかしながら、信号伝達接続解放指示の送信は、ネットワークに、結果として、警告が起こったことを考慮させ得る。信号伝達解放指示が、トラフィックが一切期待されないというＲＲＣによる判断の結果の場合、好ましい実施形態において、ネットワークは、信号伝達解放指示が、異常な状態であるのではなく、リクエストされたアイドル移行の結果であることを区別し得る。この区別によって、キー性能インディケータ（ＫＰＩ）のようなインディケータがより正確になり、性能のモニタと警告のモニタとを改善することができる。
【００４０】
本方法は、ＵＥが、既存の信号伝達解放指示に、信号伝達解放指示の理由を提供するフィールドを添付することを可能にする。ネットワークは、次いで、添付されたフィールドを用いて、真の警告状態をＵＥがアイドル状態に置かせるようにリクエストした状況からフィルタリングし得る。なぜなら、このリクエストした状況は、さらなるデータが一切期待できないからである。これは、警告および性能のモニタの効率を改善し、その一方で、ＵＥをより迅速にアイドルモードに移動させて、そのバッテリリソースを節約することを可能にする。
【００４１】
本出願は、それゆえ、ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法を提供し、該方法は、該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、該信号伝達接続解放指示を該無線ネットワークで受信するステップと、該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する。
【００４２】
本出願は、さらに、信号伝達解放指示理由を処理するのに適合したシステムをさらに提供し、該システムは、ユーザ設備であって、該ユーザ設備は、ＵＭＴＳネットワークと通信するのに適合した無線を含む無線サブシステムと；デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと；メモリと；ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有する、ユーザ設備であって、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付する手段と、該添付信号伝達接続解放指示を該無線ネットワークに送信する手段とを有することによって特徴付けられる、ユーザ設備と、該ユーザ設備と通信するのに適合した無線ネットワークであって、該信号伝達接続解放指示を受信する手段と、該理由をフィルタリングし、警告を発するかどうかを判断する手段とによってさらに特徴付けられる、無線ネットワークとを備える。
【００４３】
本出願は、またさらに、無線ネットワークで改善された警告を追跡するために、ユーザ設備で信号伝達解放指示理由を処理する方法を提供し、該方法は、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップであって、該無線ネットワークは、該信号伝達接続解放指示の該理由の指示を提供する、ステップとを包含する。
【００４４】
本出願は、またさらに、信号伝達接続の解放を容易にするユーザ設備用装置を提供する。チェッカは、信号伝達接続解放指示が、送信されるべきかどうかをチェックするように構成される。信号伝達接続解放指示センダは、信号伝達接続解放指示が送信されるべきであるという該チェッカによる指示に応答して、該信号伝達接続解放指示を送信するように構成される。該信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む。
【００４５】
本出願は、またさらに、信号伝達接続解放指示によって、動作するネットワーク装置を提供する。試験機は、該信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験するように構成される。該試験機は、該信号伝達解放指示理由フィールドが異常な状態を指示するかどうかをチェックする。警告生成機は、該試験機による試験が、該信号伝達解放指示理由フィールドが該異常な状態を指示すると判断する場合、警告を選択的に生成するように構成される。
【００４６】
本出願は、またさらに、ＵＭＴＳネットワーク内で、信号伝達解放指示理由を提供するのに適合したユーザ設備を提供し、該ユーザ設備は、該ＵＭＴＳネットワークと通信するのに適合した無線を含む無線サブシステムと；デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと；メモリと；ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、ユーザインターフェースと；ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有し、該ユーザ設備は、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、該信号伝達接続解放指示に、該信号伝達接続解放指示に対する理由を添付する手段と、該理由を含む該添付信号伝達接続解放指示を送信する手段であって、該無線ネットワークは、該信号伝達接続解放指示の該理由の指示を提供する、手段とを有することによって特徴付けられる。
【図面の簡単な説明】
【００４７】
本出願は、図面を参照することで、よりよく理解される。
【図１】図１は、ＲＲＣ状態および移行を示すブロック図である。
【図２】図２は、様々なＵＭＴＳセルおよびＵＲＡを示すＵＭＴＳネットワークの模式図である。
【図３】図３は、ＲＲＣ接続設定の様々な段階を示すブロック図である。
【図４Ａ】図４Ａは、ＣＥＬＬ＿ＤＣＨ接続モード状態と、現行方法に従うＵＴＲＡＮによって起動されるとアイドルモードとの間の例示的な移行のブロック図である。
【図４Ｂ】図４Ｂは、信号伝達解放指示を利用して、ＣＥＬＬ＿ＤＣＨ状態接続モードからアイドルモードへの移行との間の例示的な移行を示すブロック図である。
【図５Ａ】ＵＴＲＡＮによって開始された、ＣＥＬＬ＿ＤＣＨ不活動からＣＥＬＬ＿ＦＡＣＨ不活動へ、およびアイドルモードへの例示的な移行のブロック図である。
【図５Ｂ】図５Ｂは、信号伝達解放指示を利用して、ＣＥＬＬ＿ＤＣＨ不活性とアイドルモードとの間の例示的な移行のブロック図である。
【図６】図６は、ＵＭＴＳプロトコルスタックのブロック図である。
【図７】図７は、本方法と関連して用いられる例示的なＵＥである。
【図８】図８は、本方法と関連して用いられる例示的なネットワークである。
【図９】図９は、ＵＥで、信号伝達接続解放指示に対する理由を追加するステップを示す流れ図である。
【図１０】図１０は、理由を有する信号伝達接続解放指示を受信した後に、ＵＥによって取られるステップを示す流れ図である。
【発明を実施するための形態】
【００４８】
ここで、図１を参照する。図１は、ＵＭＴＳネットワークにおけるプロトコルスタックの無線リソース制御部分に対する様々なモードおよび状態を示すブロック図である。特に、ＲＲＣは、ＲＲＣアイドル状態１１０またはＲＲＣ接続状態１２０のいずれかであり得る。
【００４９】
当業者には理解されるように、ＵＭＴＳネットワークは、２つの陸上ベースのネットワークセグメントからなる。これらは、コアネットワーク（ＣＮ）および（図８に示されるような）ユニバーサル陸上無線アクセスネットワーク（ＵＴＲＡＮ）である。コアネットワークは、外部ネットワークへのデータコールおよびデータ接続の交換およびルーティングを担い、ＵＴＲＡＮは、全ての無線関連機能性を扱う。
【００５０】
アイドルモード１１０において、ＵＥとネットワークとの間でデータが交換される必要があるときはいつも、ＵＥはＲＲＣ接続をリクエストし、無線リソースを設定しなくてはならない。これは、ＵＥが接続を要求してデータを送信するアプリケーションの結果として、あるいはＵＥが、ＵＴＲＡＮまたはＳＧＳＮがＵＥをページングしたかどうかを指示するページングチャネルをモニタして、プッシュサーバのような外部データネットワークからデータを受信する結果としてのいずれかであり得る。さらに、ＵＥは、また、ロケーションエリア更新のような信号伝達メッセージを移動管理（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ）に送信する必要があるときは、いつでもＲＲＣ接続をリクエストする。
【００５１】
一度、ＵＥがＵＴＲＡＮにリクエストを送信すると、無線接続が確立し、ＵＴＲＡＮは、ＲＲＣ接続が中に入るようにするために状態を選択する。特に、ＲＲＣ接続モード１２０は、４つの個別状態を含む。これらは、ＣＥＬＬ＿ＤＣＨ状態１２２、ＣＥＬＬ＿ＦＡＣＨ状態１２４、ＣＥＬＬ＿ＰＣＨ状態１２６、およびＵＲＡ＿ＰＣＨ状態１２８である。
【００５２】
アイドルモード１１０から、ＲＲＣ接続状態は、セル専用チャネル（ＣＥＬＬ＿ＤＣＨ）状態１２２またはセル転送アクセスチャネル（ＣＥＬＬ＿ＦＡＣＨ）状態１２４のいずれかに進み得る。
【００５３】
ＣＥＬＬ＿ＤＣＨ状態１２２において、専用チャネルが、アップリンクとダウンリンクとの双方のためにＵＥに割り当てられ、データ交換する。この状態は、ＵＥに割り当てられた専用物理的チャネルを有するので、ＵＥから最も多くのバッテリ電力を典型的に要求する。
【００５４】
代替として、ＵＴＲＡＮは、アイドルモード１１０からＣＥＬＬ＿ＦＡＣＨ状態１２４に移動し得る。ＣＥＬＬ＿ＦＡＣＨ状態において、専用チャネルはＵＥに割り当てられない。その代わりに、共通チャネルが、信号伝達を少量のバースティなデータで送信するために使用される。しかしながら、ＵＥは、相変わらずＦＡＣＨを連続的にモニタしなくてはならない。それゆえ、バッテリ電力を消費する。
【００５５】
ＲＲＣ接続モード１２０内において、ＲＲＣ状態は、ＵＴＲＡＮの行動（ｄｉｓｃｒｅｔｉｏｎ）を変更し得る。特に、データ不活性が特定の時間の間に検出された場合、あるいは所定の閾値未満のスループットが検出された場合、ＵＴＲＡＮは、ＲＲＣ状態をＣＥＬＬ＿ＤＣＨ状態１２２から、ＣＥＬＬ＿ＦＡＣＨ状態１２４、ＣＥＬＬ＿ＰＣＨ状態１２６、またはＵＲＡ＿ＰＣＨ状態１２８に、移動させ得る。同様に、ペイロードが所定の閾値を超えることが検出される場合、ＲＲＣ状態は、ＣＥＬＬ＿ＦＡＣＨ１２４からＣＥＬＬ＿ＤＣＨ１２２に移動し得る。
【００５６】
ＣＥＬＬ＿ＦＡＣＨ状態１２４から、データ不活性が一部のネットワークにおいて、所定の時間にわたって検出された場合、ＵＴＲＡＮは、ＲＲＣ状態をＣＥＬＬ＿ＦＡＣＨ状態１２４からページングチャネル（ＰＣＨ）状態に移動させ得る。これは、ＣＥＬＬ＿ＰＣＨ 状態１２６またはＵＲＡ＿ＰＣＨ状態１２８のいずれかであり得る。
【００５７】
ＣＥＬＬ＿ＰＣＨ状態１２６またはＵＲＡ＿ＰＣＨ状態１２８から、ＵＥは、専用チャネルをリクエストする更新手順を開始するために、ＣＥＬＬ＿ＦＡＣＨ状態１２４に移動されなくてはならない。これは、ＵＥが制御する唯一の状態移行である。
【００５８】
ＣＥＬＬ＿ＰＣＨ状態１２６およびＵＲＡ＿ＰＣＨ状態１２８は、不連続受信サイクル（ＤＲＸ）を使用し、包装メッセージおよびページングインディケータチャネル（ＰＩＣＨ）によるページングをモニタする。アップリンク活動は、一切不可能である。
【００５９】
ＣＥＬＬ＿ＰＣＨ状態１２６とＵＲＡ＿ＰＣＨ状態１２８との間の差は、ＵＲＡ＿ＰＣＨ状態が、現在のセルの中に存在するＵＲＡアイデンティティのリストの中にＵＥの現在のＵＴＲＡＮ登録エリア（ＵＲＡ）がない場合、ＵＲＡ更新手順をトリガすることのみである。具体的には、図２を参照する。図２は、様々なＵＭＴＳセル２１０、２１２、および２１４の図を示す。これらのセルの全ては、ＣＥＬＬ＿ＰＣＨ状態が再選択された場合、セル更新手順を要求する。しかしながら、ＵＴＲＡＮ登録エリアにおいて、各セルは、同じＵＴＲＡＮ登録エリア２２０内にあり、したがって、ＵＲＡ更新手順は、ＵＲＡ＿ＰＣＨモードのときに、２１０、２１２、および２１４の間で移動するとき、トリガされない。
【００６０】
図２に示されるように、他のセル２１８は、ＵＲＡ２２０の外側にアップリンク、別個のＵＲＡの一部となり得るか、あるいはＵＲＡになり得ない。
【００６１】
当業者には理解されるように、バッテリ寿命見通しから、アイドル状態は、上述の状態と比べて、最も少ないバッテリ使用法を提供する。具体的に、ＵＥは、ページングチャネルをインターバルだけにおいて、モニタすることを要求されるので、無線は、連続的にオンである必要はないが、その代わりに、定期的に目覚める必要がある。これに対するトレードオフは、データを送信する待ち時間である。しかしながら、この待ち時間は、さほど長くもない場合、アイドルモードであってバッテリ電力を節約することのメリットは、接続の待ち時間のデメリットを上回る。
【００６２】
再び、図１を参照する。様々なＵＭＴＳインフラベンダは、様々な基準に基づいて、１２２、１２４、１２６、および１２８の状態間を移動する。例示的なインフラは、以下に概略される。
【００６３】
第一の例示的なインフラにおいて、ＲＲＣは、アイドルモードとＣｅｌｌ＿ＤＣＨ状態との間を直接移動する。Ｃｅｌｌ＿ＤＣＨ状態において、２秒間活性でないことが検出されると、ＲＲＣ状態は、Ｃｅｌｌ＿ＦＡＣＨ状態１２４に変化する。Ｃｅｌｌ＿ＦＡＣＨ状態１２４において、１０秒間活性でないことが検出されたら、ＲＲＣ状態は、ＰＣＨ状態１２６に変化する。Ｃｅｌｌ＿ＰＣＨ状態１２６において、４５分間活性でないことが検出されたら、その結果、ＲＲＣ状態は、アイドル状態１１０に戻る。
【００６４】
第二の例示的なインフラにおいて、ＲＲＣ移行は、ペイロード閾値に依存して、アイドルモード１１０と接続モード１２０との間で発生し得る。第二のインフラにおいて、ペイロードが、所定の閾値未満であれば、ＵＴＲＡＮは、ＲＲＣ状態からＣＥＬＬ＿ＦＡＣＨ状態１２４に移動する。逆に、データが所定のペイロードを上回る場合、ＵＴＲＡＮは、ＲＲ状態をＣＥＬＬ＿ＤＣＨ状態１２２に移行する。第二のインフラで、ＣＥＬＬ＿ＤＣＨ状態１２２において、２分間活性でないことが検出されると、ＵＴＲＡＮは、ＲＲＣをＣＥＬＬ＿ＦＡＣＨ状態１２４に移動する。ＣＥＬＬ＿ＦＡＣＨ状態１２４において、５分間活性でないことが検出されると、ＵＴＲＡＮは、ＲＲＣ段階をＣＥＬＬ＿ＰＣＨ状態１２６に移動する。ＣＥＬＬ＿ＰＣＨ状態１２６において、アイドルモード１１０に戻る前に、２時間の不活動が要求される。
【００６５】
第三の例示的なインフラにおいて、アイドルモードと接続モード１２０との間の移動は、常に、ＣＥＬＬ＿ＤＣＨ状態１２２である。ＣＥＬＬ＿ＤＣＨ状態１２２において、５秒間活性でなかった後に、ＵＴＲＡＮは、ＲＲＣ状態をＣＥＬＬ＿ＦＡＣＨ状態１２４に移動する。ＣＥＬＬ＿ＦＡＣＨ状態１２４において、３０秒間活性でないと、その結果、アイドル状態１１０に移動して戻る。
【００６６】
第四の例示的なインフラにおいて、ＲＲＣは、アイドルモードから接続モードに直接移行し、ＣＥＬＬ＿ＤＣＨ状態１２２になる。第四の例示的なインフラにおいて、ＣＥＬＬ＿ＤＣＨ状態１２２は、２つのサブ状態を含む。第一は、高いデータレートを有するサブ状態であり、第二のサブ状態は、より低いデータレートを含むが、それでもなおＣＥＬＬ＿ＤＣＨ状態の範囲内である。第四の例示的なインフラにおいて、ＲＲＣは、アイドルモード１１０から、高いデータレートのＣＥＬＬ＿ＤＣＨサブ状態へと直接移行する。１０秒間活性でない後、ＲＲＣ状態は、低いＣＥＬＬ＿ＤＣＨ状態に移行する。低データのＣＥＬＬ＿ＤＣＨ状態１２２から１７秒間活性でないと、その結果、ＲＲＣ状態は、アイドルモード１１０に変化する。
【００６７】
上述の４つの例示的なインフラは、様々なＵＭＴＳのインフラベンダが、状態をインプリメントしているかを示す。当業者には理解されるように、各場合において、実際のデータ交換（例えば、ｅメール）に要した時間は、ＣＥＬＬ＿ＤＣＨまたはＣＥＬＬ＿ＦＡＣＨ状態に留まっていることを要求される時間に比べ、かなり短い。このため、不必要なカレントドレインが生じ、その結果、ユーザは、ＵＭＴＳのような新たな世代のネットワークにおいて、ＧＰＲＳのような以前の世代のネットワークよりも、悪化するのを体験する。
【００６８】
さらに、ＣＥＬＬ＿ＰＣＨ状態は、ＣＥＬＬ＿ＦＡＣＨ状態よりも最適であるが、バッテリ寿命の観点から、ＣＥＬＬ＿ＰＣＨ状態におけるＤＲＸサイクルは、典型的には、アイドルモード１１０より低い値に設定される。その結果、ＵＥは、アイドルモードよりも、ＣＥＬＬ＿ＰＣＨ状態で、より頻繁に目覚めていることが要求される。
【００６９】
アイドル状態のサイクルと同様のＤＲＸサイクルを有するＵＲＡ＿ＰＣＨ状態は、バッテリ寿命と接続における待ち時間との最適なトレードアップのように思われる。しかしながら、ＵＲＡ＿ＰＣＨは、現在、ＵＴＲＡＮでサポートされていない。それゆえ、バッテリ寿命の観点から、アプリケーションがデータ交換で終了したら、できるだけ迅速に、アイドルモードに移行することが望ましい。
【００７０】
ここで、図３を参照する。アイドルモードから接続モードへ移行するとき、様々な信号伝達およびデータ接続が、生成される必要がある。図３を参照すると、実行されるべき必要のある第一のアイテムは、ＲＲＣ接続設定である。上述のように、このＲＲＣ接続設定は、ＵＴＲＡＮによってのみ、解体され得る。
【００７１】
一度、ＲＲＣ接続設定３１０が達成されると、信号接続設定３１２が開始される。
【００７２】
一度、信号設定３１２が終了すると、暗号化・保全性設定（ｃｉｐｈｅｒｉｎｇ ａｎｄ ｉｎｔｅｇｒｉｔｙ ｓｅｔｕｐ）３１４が開始される。これが完了すると、無線ベアラ設定３１６が達成される。この時点で、データは、ＵＥとＵＴＲＡＮとの間で交換され得る。
【００７３】
接続解体は、一般的に、この逆順で同様に達成される。無線ベアラ設定３１６は、解体され、次いで、ＲＲＣ接続設定３１０が取り払われる。この時点で、ＲＲＣは、図１に示すように、アイドルモード１１０へと移動する。
【００７４】
現在の３ＧＰＰ仕様によれば、ＵＥが、ＲＲＣ接続を解放すること、または、ＲＲＣ状態にとってその好みを指示することはできないが、それでも、ＵＥは、特定のコアネットワークドメイン（例えば、パケット交換アプリケーションで使用されるＰａｃｋｅｔ Ｓｗｉｔｃｈｅｄ（ＰＳ））に対する信号伝達接続の終了を指示し得る。３ＧＰＰ ＴＳ ２５．３３１の８．１．１４．１節に従うと、信号伝達接続解放指示手順は、ＵＥによって使用され、ＵＴＲＡＮに、その信号伝達接続の一つが解放されたことを指示する。この手順は、順に、ＲＲＣ接続解放手順を開始し得る。
【００７５】
このように、現行の３ＧＧＰ仕様の範囲に留まると、信号伝達接続解放は、信号接続設定３１２の解体によって、開始され得る。信号伝達接続設定３１２を解体する（ｔｅａｒ
ｄｏｗｎ）ことは、ＵＥの能力の範囲内であり、次いで、仕様に従えば、このことは、ＲＲＣ接続解放を開始し「得る」。
【００７６】
当業者には理解されるように、信号伝達接続設定３１２が、解体される場合、ＵＴＲＡＮは、また、解読・保全性設定３１２を一掃し、信号接続設定３１２が解体された後に、無線ベアラ設定３１６を一掃する必要がある。
【００７７】
信号伝達接続設定３１２が、解体される場合、ＲＲＣ接続設定は、典型的には、現在のベンダのインフラに対するネットワークによって停止される。
【００７８】
上述を用いて、データ交換とともに行われるとＵＥが決定する場合、例えば、ＵＥソフトウェアの「ＲＲＣ接続マネージャ」コンポーネントが、データ交換が完了したという指示を提供された場合、ＲＲＣ接続マネージャは、信号伝達接続設定３１２を解体するかどうかを判断し得る。例えば、デバイス上でのｅメールアプリケーションは、ｅメールが本当にプッシュサーバによって受信されたという、プッシュｅメールサーバからの通知を受信したという指示を送信する。ＲＲＣマネージャは、関連ＰＤＰコンテキスト、関連ＰＳ無線ベアラおよび関連回路交換（ＣＳ）無線ベアラの全ての現行のアプリケーションを追跡し得る。この場合の遅延は、データ交換でもって、そのアプリケーションが本当に終了し、もはや、「完了」指示を送信した後もＲＲＣ接続をもはや必要としない。この遅延は、このアプリケーションと関連する非活性なタイムアウトと同等である。各アプリケーションは、それ自身の非活性なタイムアウトを有し得る。例えば、ｅメールアプリケーションは、５秒の非活性なタイムアウトを有し得るが、活性なブラウザアプリケーションは、６０秒の非活性なタイムアウトを有し得る。活性なアプリケーションからの全てのこのような指示の復号ステータスに基づいて、ＵＥソフトウェアは、ＵＥソフトウェアが、適切なコアネットワーク（例えば、ＰＳドメイン）の信号伝達接続解放を開始し得るまでに、どのくらい待つべきであるかを判断する。
【００７９】
非活性なタイムアウトは、トラフィックパターン履歴および／またはアプリケーションプロファイルに基づいて、ダイナミックベースでなされ得る。
【００８０】
ＲＲＣ接続マネージャが、どのアプリケーションもデータ交換を期待されないとある程度の確率で判断するときはいつも、ＲＣＣ接続マネージャは、適切なドメインに対する信号伝達接続解放指示手順を送信し得る。
【００８１】
上述のＵＥで開始されたアイドルモードへの移行は、図１に示すようなＲＲＣ接続モード１２０の任意の段階で起こり得て、また、ＲＲＣ接続ネットワークから解放させ、図１に示すようなアイドルモード１１０に移動させて終了する。これは、また、音声コール中に、ＵＥが任意のパケットデータサービスを実行しているときにも、適用可能である。この場合、ＰＳドメインのみが解放されるが、ＣＳドメインは接続されたままである。
【００８２】
上述のネットワークの考え方における問題は、ＵＥによって送信された信号伝達接続解放指示が、警告として解釈されることである。信号伝達ネットワーク解放が、適用タイマ時間切れのためにより、ＵＥによって明確なアクションの結果であり、それゆえ、さらなるデータが期待されない場合、上記の指示によって生じた警告は、性能および警告指示をスキューする。キー性能インディケータは、これによって変更され得、効率の損失へと導く。
【００８３】
好ましくは、理由が、ＵＴＲＡＮに指示に対する理由を指示する信号伝達接続解放指示に追加されるべきである。好ましい実施形態において、その理由は、異常な状態が指示の理由となったという指示か、あるいはリクエストされたアイドル移行の結果として、ＵＥによって開始されたという指示であり得る。他の正常（すなわち、異常でない）トランザクションは、結果として、信号伝達接続解放指示の送信であり得る。
【００８４】
さらなる好ましい実施形態において、様々なタイムアウトは、異常な状態に対する信号伝達接続指示の理由となり得る。以下のタイマの例は、網羅的なものでなく、他のタイマ、あるいは他の条件も可能である。例えば、３ＧＰＰ．ＴＳ ２４．００８の１０．２．４７は、タイマＴ３３１０として、以下を特定する。
【００８５】
【表１】
このタイマは、アタッチ失敗を指示するために使用される。アタッチ失敗は、ネットワークの結果であり得るか、あるいは衝突または不良無線周波数（ＲＦ）のようなＲＦ問題であり得る。
【００８６】
添付の試みは、複数回起こり得、アタッチ失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【００８７】
３ＧＰＰの１０．２．４７の第二のタイマは、Ｔ３３３０であり、以下のように特定される。
【００８８】
【表２】
このタイマは、ルーティングエリア更新失敗を指示するために使用される。タイマが時間切れになると、さらなるルーティングエリア更新が、複数回リクエストされ得て、ルーティングエリア更新失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【００８９】
３ＧＰＰの１０．２．４７の第三のタイマは、Ｔ３３４０であり、以下のように特定される。
【００９０】
【表３】
このタイマは、ＧＭＭサービスリクエスト失敗を指示するために使用される。タイマが時間切れになると、さらなるＧＭＭサービスリクエストが、複数回開始され得、ＧＭＭサービスリクエスト失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【００９１】
このように、信号伝達解放指示は、異常な状態およびＵＥによる解放に限られる代わりに、信号伝達解放指示は、さらに、異常な状態に対してどのタイマが失敗したかに関する情報を含み得る。信号伝達接続解放指示は、以下のように構造化され得る。
【００９２】
【表４】
このメッセージは、ＵＥによって使用され、ＵＴＲＡＮに既存の信号伝達接続を解放するように指示する。信号伝達解放指示を追加すると、ＵＴＲＡＮまたは他のネットワークエレメントは、信号伝達解放指示の理由、つまり異常な状態によるものであったのか、あるいは異常な状態とは何であったかを受信することができる。そして、ＲＲＣ接続解放手順が、次いで、開始されることが可能になる。
【００９３】
一つのインプリメンテーションにおいて、ＵＥは、解放または中断するようにというリクエストを受信すると、特定のＣＮ（コアネットワーク）ドメインに対する上部層からの信号伝達接続は、ＩＥ（情報エレメント）「ＣＮドメインアイデンティティ」で識別される特定のＣＮドメインに対する変数（例えば、変数ＥＳＴＡＢＬＩＳＨＥＤ＿ＳＩＧＮＡＬＩＮＧ＿ＣＯＮＮＥＣＴＩＯＮＳ）で識別されるような信号伝達接続が存在する場合、信号伝達接続解放指示を開始する。変数が、既存の信号伝達接続を一切識別しない場合、その特定のＣＮドメインに対する信号伝達接続の進行中の確立は、いずれも別の方法で中断される。そして、ＣＥＬＬ＿ＰＣＨまたはＵＲＡ＿ＰＣＨ状態で、信号伝達接続解放指示手順が開始すると、ＵＥは、「アップリンクデータ送信」理由を用いて、セル更新手順を実行する。そして、セル更新手順が成功裏に完了したとき、ＵＥは、その後の信号伝達接続解放指示手順を続ける。
【００９４】
すなわち、ＵＥは、ＩＥ「ＣＮドメインアイデンティティ」を上部ロジカル層によって指示された値に設定する。ＩＥの値は、ＣＮドメインを指示し、その関連信号伝達接続は、上部層が解放されるべきことを指示する関連信号伝達接続である。ＣＮドメインアイデンティティが、ＰＳドメインに設定される場合で、上部層は、このリクエストを開始する理由を指示する場合、ＩＥ「信号伝達解放指示理由」は、これに従って設定される。ＵＥは、変数「ｅｓｔａｂｌｉｓｈｅｄ＿ｓｉｇｎａｌｉｎｇ＿ｃｏｎｎｅｃｔｉｏｎｓ」から上部層によって指示されたアイデンティティを有する信号伝達接続をさらに除去する。そして、ＵＥは、信号伝達接続解放指示メッセージを、例えば、ＡＭ ＲＬＣを用いて、ＤＣＣＨ上で送信する。ＲＬＣによって解放指示メッセージの配信が成功したことを確認すると、この手順は終了する。
【００９５】
ＩＥ「Ｓｉｇｎａｌｉｎｇ Ｒｅｌｅａｓｅ Ｉｎｄｉｃａｔｉｏｎ Ｃａｕｓｅ」も、また本開示の実施形態に関して用いられる。解放理由は、例えば、既存のメッセージ定義で、アラインされる。上部層解放理由メッセージも例えば、以下のように構造化される。
【００９６】
【表５】
この例において、Ｔ３３１０、Ｔ３３３０、およびＴ３３４０は、上記で識別された対応するように番号付けされたタイマの時間切れに相当する。理由値は、一つの実施形態において、状態移行によって判断するＵＴＲＡＮに提供する「ＵＥ Ｒｅｑｕｅｓｔｅｄ ｉｄｌｅ ｔｒａｎｓｉｔｉｏｎ」よりも、むしろ「ＵＥ Ｒｅｑｕｅｓｔｅｄ ＰＳ Ｄａｔａ ｓｅｓｓｉｏｎ ｅｎｄ」として、設定可能である。しかしながら、期待される結果は、理由値によって識別される結果に対応する。信号伝達接続解放指示への拡張（ｅｘｔｅｎｓｉｏｎ）は、好ましいが、必ずしも必要ではなく、クリティカルでない拡張である。
【００９７】
ここで、図９を参照する。図９は、様々なドメイン（例えば、ＰＳまたはＣＳ）に対する信号伝達接続解放指示を送信するかしないかを例示的にＵＥをモニタする流れ図である。プロセス９１０は、ステップ９１０で開始する。
【００９８】
ＵＥは、ステップ９１２へ移行し、ここで、異常な状態が存在するかどうかを見るためにチェックする。このような異常な状態には、例えば、上述したような、タイマＴ３３１０、タイマＴ３３２０、またはタイマＴ３３４０の時間切れを含み得る。これらのタイマが、ある所定の回数、時間切れとなった場合、あるいはこれらのタイマのいずれかの時間切れに基づいて、明確な拒絶を受信する場合、ＵＥは、ステップ９１４に進み、ここで、信号伝達接続解放指示を送信する。信号伝達接続解放指示メッセージは、信号伝達解放指示理由フィールドを用いて添付される。信号伝達解放指示理由フィールドは、信号伝達接続解放指示が異常な状態（ｃｏｎｄｉｔｉｏｎまたはｓｔａｔｅ）に基づくことを少なくとも含み、好ましい実施形態は、異常な状態の結果としてタイムアウトする特定のタイマを含む。
【００９９】
逆に、ステップ９１２で、ＵＥが異常な状態が存在しないことを見出す場合、ＵＥは、ステップ９２０に進み、ここで、さらなるデータがＵＥで期待されるかどうかをチェックする。これは、上述のように、ｅメールが送信され、そのｅメールの送信確認がＵＥに返信されたときを含む。ＵＥがさらなるデータがもはや期待されないかどうかを判断する他の例は、当業者には周知である。
【０１００】
ステップ９２０で、データ伝達が終了した（あるいは、回路交換の場合、ドメインコールが終了した）と、ＵＥが判断する場合、ＵＥは、ステップ９２２に進み、ここで、信号伝達接続解放指示を送信する。この信号伝達接続解放指示の中に、信号伝達解放指示理由フィールドが追加され、このフィールドはＵＥがアイドル移行をリクエストしたという事実を含む。
【０１０１】
データが終了しない場合、ステップ９２０から、ＵＥはループを戻り、ステップ９１２で異常な状態が存在しないかどうかをチェックし、ステップ９２０でデータが終了するかどうかをチェックし続ける。
【０１０２】
一度、ステップ９１４またはステップ９２２で、信号伝達接続解放指示が送信されると、プロセスは、ステップ９３０に進み、終了する。
【０１０３】
ＵＥは、機能エレメントを含む。これらの機能エレメントは、例えば、ＵＥマイクロプロセッサの動作を介して実行されるアプリケーションまたはアルゴリズムによって、あるいは、ハードウェアインプリメンテーションによって、インプリメント可能であり、チェッカおよび信号伝達接続解放指示センダを形成する。チェッカは、信号伝達接続解放指示が送信されるべきかどうかをチェックするように構成される。そして、信号伝達接続解放指示センダが、チェッカによる信号伝達接続解放指示を送信すべきであるという指示に応答して、信号伝達接続解放指示を送信するように構成される。信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む。
【０１０４】
一つのインプリメンテーションにおいて、ネットワークは、代わりに、暗黙にタイマのタイムアウトに気付くようにされ、ＵＥはタイマのタイムアウトを指示する理由値を送信する必要はない。つまり、タイマは、ネットワークの承諾を受けて、時間計測を開始する。理由コードが規定され、その理由コードは、ネットワークによってＵＥに提供される。このような理由コードは、タイマを開始するために、ＵＥによって使用される。そして、ネットワークによって以前に送信された理由コードが、タイマに時間測定をさせると、ネットワークは、暗黙のうちに、タイマの次のタイムアウトに対する根拠に気付く。そして、その結果として、ＵＥは、タイマの時間切れを指示する理由値を送信する必要がなくなる。
【０１０５】
図１０を参照すると、ネットワークエレメントが、ステップ１０１０で信号伝達接続解放指示を受信するとき、ネットワークエレメントは、ステップ１０１４で信号伝達解放指示理由フィールドを試験し、ステップ１０１６で、その理由が異常な理由であるかどうか、あるいはその理由はＵＥがアイドル移行をリクエストしたことによるかどうかをチェックする。ステップ１０１６で、信号伝達接続解放指示が、異常な理由である場合、ネットワークノードは、ステップ１０２０に進み、ここでは、警告は、性能をモニタするため、および警告モニタの目的であると注記される。キー性能インディケータは、適切に更新され得る。
【０１０６】
逆に、ステップ１０１６で、信号伝達接続解放指示の理由が、異常な状態の結果でない場合、あるいは換言すれば、ＵＥがアイドル移行をリクエストした結果である場合、ネットワークノードは、ステップ１０３０に進み、ここで、警告が発せられず、指示は、性能統計からフィルタリングされ得、これによって、性能統計がスキューすることが妨げられる。ステップ１０２０またはステップ１０３０から、ネットワークノードは、ステップ１０４０に進み、プロセスは終了する。
【０１０７】
信号伝達解放指示理由フィールドを受信し、試験すると、その結果、ネットワークエレメントによって、ＲＲＣ接続解放手順が開始される。そして、パケット交換データ接続が終了する。
【０１０８】
当業者には理解されるように、ステップ１０２０は、様々な警告状態の間でさらに区分するために使用され得る。例えば、Ｔ３３１０のタイムアウトは、第一の統計セットを維持するために使用され得、Ｔ３３３０のタイムアウトは、第二の統計セットを維持するために使用され得る。ステップ１０２０は、異常な状態の理由で区別し得る。これによって、ネットワークオペレータは、性能をより効率的に追跡可能となる。
【０１０９】
ネットワークは、機能エレメントを含む。これらの機能エレメントは、例えば、ＵＥマイクロプロセッサの動作を介して実行されるアプリケーションまたはアルゴリズムによって、あるいは、ハードウェアインプリメンテーションによって、インプリメント可能であり、試験機および警告生成機を形成する。試験機は、信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験するように構成される。試験機は、信号伝達解放指示理由フィールドが異常な状態であるかどうかをチェックする。警告生成機は、試験機による試験が信号伝達解放指示理由フィールドが異常な状態を示す場合、警告を選択的に生成するように構成される。
【０１１０】
一つのインプリメンテーションにおいて、ＵＴＲＡＮは、信号伝達接続解放指示を受信すると、上部層から受信された理由を転送し、信号伝達接続の解放をリクエストする。上部層は、信号伝達接続の解放を開始することが可能である。ＩＥ信号伝達解放指示理由は、ＵＥの上部層に指示することで、ＵＥのＲＲＣをトリガし、メッセージを送信させるようにする。その理由は、おそらく、異常な上部層手順の結果である。メッセージの理由の区分は、ＩＥを成功裏に受信することで確保される。
【０１１１】
可能性のあるシナリオには、信号伝達接続解放指示メッセージが成功裏に配信されたことがＲＬＣによって確認される前に、信号伝達無線ベアラＲＢ２上のＲＬＣ全体の送信側の再確立が起こるシナリオを含む。このようなことが起こった場合、ＵＥは、例えば、信号伝達無線ベアラＲＢ２上のＡＭ ＲＬＣを用いて、アップリンクＤＣＣＨ上の信号伝達接続解放指示メッセージを再送信する。信号伝達接続解放指示メッセージが成功裏に配信されたことの確認が、ＲＬＣによって成功裏に配信される前に、ＵＴＲＡＮ手順の性能からのエンターＲＡＴの引き継ぎが起こった場合、ＵＥは、新たなＲＡＴの間に、信号伝達接続を中断する。
【０１１２】
再び、図１を参照すると、一部の場合において、アイドルモードにあるよりも、接続モード状態ＵＲＡ＿ＰＣＨにあることが、より望ましい。例えば、ＣＥＬＬ＿ＤＣＨまたはＣＥＬＬ＿ＦＡＣＨ接続モード状態に接続する待ち時間が少なくなることを要求される場合、接続モードＰＣＨ状態にあることが望ましい。これを達成するには、２つの方法がある。第一は、３ＧＰＰ仕様を変更して、ＵＥがＵＴＲＡＮに、自身を特定の状態（この場合は、ＵＲＡ＿ＰＣＨ状態１２８）に移動するように要求することである。
【０１１３】
代替として、ＲＲＣ接続マネージャは、ＲＲＣの接続が現状どのような状態であるかのような他の要因を考慮に入れ得る。例えば、ＲＲＣ接続がＵＲＡ＿ＰＣＨ状態である場合、ＲＲＣ接続は、自身がアイドルモード１１０に移動する必要がなく、それゆえ、信号接続解放の手順は、開始されない。
【０１１４】
図４を参照する。図４Ａは、上述のインフラストラクチャの「４つ」の例に従って、現在のＵＭＴＳのインプリメンテーションを示す。図４に示すように、時間は横軸に沿う。
【０１１５】
ＵＥは、ＲＲＣアイドル状態１１０で開始し、送信されるべきローカルデータ、または、ＵＴＲＡＮから受領したページに基づいて、ＲＲＣ接続の確立を始める。
【０１１６】
図４Ａに示されるように、ＲＲＣ接続設定３１０は、最初に起こり、ＲＲＣ状態は、この時間中、接続状態４１０である。
【０１１７】
次いで、信号接続設定３１２、暗号化・保全性設定３１４、および、無線ベアラ設定３１６が起こる。ＲＲＣ状態は、この間、ＣＥＬＬ＿ＤＣＨ状態１２２である。図４Ａに示されるように、ＲＲＣアイドルから移動する時間と、無線ベアラが設定される時間との比率は、この例において、ほぼ２秒である。
【０１１８】
次いで、データが交換される。図４Ａの例において、これは、約２〜４秒で達成され、ステップ４２０によって示される。
【０１１９】
ステップ４２０において、データが交換された後、必要に応じての断続的なＲＬＣ信号ＰＤＵを除くと、データは全く交換されない。こうして、無線ベアラは、約１０秒後に、低データレートのＤＣＨ状態に移動するように、ネットワークによって再構成される。これは、ステップ４２２および４２４で示されている。
【０１２０】
低データレートのＤＣＨ状態において、１７秒間にわたって何も受信されない。この時点で、ステップ４２８で、ＲＲＣ接続は、ネットワークによって解放される。
【０１２１】
一度、ＲＲＣ接続が、ステップ４２８で開始されると、ＲＲＣ状態は、約４０ミリ秒にわたって非接続状態４３０に入り、その後、ＵＥがＲＲＣアイドル状態１１０になる。
【０１２２】
また、図４Ａに示されているように、ＵＥの電流消費は、ＲＲＣがＣＥＬＬ＿ＤＣＨ状態１２２にあるときの期間にわたって示される。図示のように、電流消費は、ＣＥＬＬ＿ＤＣＨ状態の全期間にわたって、約２００〜３００ミリアンペアである。非接続およびアイドルの間に、ＤＲＸサイクルを１．２８秒と仮定すると、約３ミリアンペアが使用される。しかしながら、３５秒間の電流消費２００〜３００ミリアンペアは、バッテリを消耗させる。
【０１２３】
ここで、図４Ｂを参照する。図４Ｂは、上記から同じ例示的なインフラストラクチャ「４つ」を利用しているが、ここでのみ、信号接続解放をインプリメントしている。
【０１２４】
図４Ｂに示すように、同じ設定ステップ３１０、３１２、３１４および３１６が起こり、これには、ＲＲＣアイドル状態１１０とＲＲＣ ＣＥＬＬ＿ＤＣＨ状態１２２との間を移動するときと、同じ時間量を要する。
【０１２５】
さらに、図４Ａの例示的なｅメール用のＲＲＣデータＰＤＵ交換も、また、図４Ｂで行われ、これに、約２〜４秒を要する。
【０１２６】
図４Ｂの例の中のＵＥは、アプリケーション特有の不活動タイムアウトを有する。図４Ｂの例におけるこのタイムアウトは２秒であり、ステップ４４０によって描かれている。ＲＲＣ接続マネージャが特定の時間量にわたって、不活動があると判断した後、ステップ４４２で、ＵＥは信号接続設定を解放し、ステップ４２８で、ＲＲＣ接続はネットワークによって解放される。
【０１２７】
図４Ｂに示すように、ステップ１２２のＣＥＬＬ＿ＤＣＨの電流消費は、それでもなお、約２００〜３００ミリアンペアである。しかしながら、接続時間は、約８秒のみである。当業者には理解されるように、モバイルがセルＤＣＨ状態１２２のままである時間が、かなり短い時間量なので、その結果、常にオンであるＵＥデバイス上のバッテリ節約は、著しいものとなる。
【０１２８】
ここで、図５を参照する。図５は、上述で示したインフラストラクチャ「３」と示されるインフラを用いる第二の例である。図４Ａおよび図４Ｂと同様、接続設定は、約２秒を要して起こる。これは、ＲＲＣ接続設定３１０、信号接続設定３１２、暗号化・保全性設定３１４、および、無線ベアラ３１６を要する。
【０１２９】
この設定の間に、ＵＥは、ＲＲＣアイドルモード１１０からＣＥＬＬ＿ＤＣＨ状態１２２に移動する。この両者の間に、ＲＲＣ状態接続ステップ４１０がある。
【０１３０】
図４Ａと同様に、図５Ａにおいて、ＲＬＣデータＰＤＵ交換が起こり、図５Ａの例においては、約２〜４秒を要する。
【０１３１】
インフラストラクチャ３に従うと、ＲＬＣ信号ＰＤＵ交換は、データを全く受信しないので、必要に応じての断続的なＲＬＣ信号ＰＤＵを除き、こうして、ステップ４２２で、５秒の間、アイドルである。この時点において、無線ベアラは、ＣＥＬＬ＿ＤＣＨ状態１２２からＣＥＬＬ＿ＦＡＣＨ状態１２４に移動するために、ネットワークを再構成する。これは、ステップ４５０で行われる。
【０１３２】
ＣＥＬＬ＿ＦＡＣＨ状態１２４において、ＲＬＣ信号ＰＤＵ交換は、この場合、３０秒である所定の時間量に対し必要とされるような断続的なＲＬＣ信号ＰＤＵを除くと、全くデータがないことを見出す。この時点において、ステップ４２８で、ＲＲＣ接続のネットワークによる解放が実行される。
【０１３３】
図５Ａに示すように、これは、ＲＲＣ状態をアイドルモード１１０に移動する。
【０１３４】
さらに、図５Ａに示すように、ＤＣＨモードの間の電流消費は、２００〜３００ミリアンペアの間である。ＣＥＬＬ＿ＦＡＣＨ状態１２４に移動するとき、電流消費は、約１２０〜１８０ミリアンペアに下がる。ＲＲＣコネクタが、解放され、ＲＲＣがアイドルモード１１０に移動すると、電力消費は約３ミリアンペアになる。
【０１３５】
ＵＴＲＡ ＲＲＣ Ｃｏｎｎｅｃｔｅｄ Ｍｏｄｅ状態は、ＣＥＬＬ＿ＤＣＨ状態１２２またはＣＥＬＬ＿ＦＡＣＨ状態１２４であり、図５Ａの例では、約４０秒続く。
【０１３６】
ここで、図５Ｂを参照する。図５Ｂは、図５Ａと同じインフラストラクチャ「３」を示し、ＲＲＣ接続設定３１０、信号接続設定３１２、暗号化・保全性設定３１４、および、無線ベアラ設定３１６を得るために、約２秒の同じ接続時間を有する。さらに、ＲＬＣデータＰＤＵ交換４２０は、約２〜４秒を要する。
【０１３７】
図４Ｂと同様に、ＵＥアプリケーションは、ステップ４４０で、特定の不活動タイムアウトを検出する。この検出した時点で、信号接続解放指示手順は、ＵＥによって開始され、その結果、ＲＲＣ接続は、ステップ４４８で、ネットワークによって解放される。
【０１３８】
さらに、図５Ｂから分かるように、ＲＲＣは、アイドルモード１１０にて始まり、ＣＥＬＬ＿ＦＡＣＨ状態を経ずして、ＣＥＬＬ＿ＤＣＨ状態１２２に移動する。
【０１３９】
さらに、図５Ｂから分かるように、ＲＲＣ段階が、ＣＥＬＬ＿ＤＣＨ状態１２２である時間（図５の例に従うと、約８秒である）における電流消費は、約２００〜３００ミリアンペアの間である。
【０１４０】
それゆえ、図４Ａおよび図４Ｂと図５Ａおよび図５Ｂとを比較すると、著しい量の電流消費が、除去されている。こうして、ＵＥのバッテリ寿命が著しく伸びる。当業者には理解されるように、上述は、現行の３ＧＰＰ仕様の関連において、さらに使用され得る。
【０１４１】
ここで、図６を参照する。図６は、ＵＭＴＳネットワークに対するプロトコルスタックを示す。
【０１４２】
図６に示すように、ＵＭＴＳは、ＣＳ制御プレーン６１０、ＰＳ制御プレーン６１１、および、ＰＳユーザプレーン６３０を含む。
【０１４３】
これら３つのプレーンの中には、非アクセス層（ｎｏｎ−ａｃｃｅｓｓ ｓｔｒａｔｕｍ）（ＮＡＳ）部分６１４およびアクセス層部分６１６が存在する。
【０１４４】
ＣＳ制御プレーン６１０内のＮＡＳ部分６１４は、コール制御（ＣＣ）６１８、追加サービス（ｓｕｐｐｌｅｍｅｎｔａｒｙ ｓｅｒｖｉｃｅｓ）（ＳＳ）６２０、および、ショートメッセージサービス（ＳＭＳ）６２２を含む。
【０１４５】
ＰＳ制御プレーン６１１のＮＡＳ部分６１４は、移動管理（ＭＭ）およびＧＰＲＳ移動管理（ＧＭＭ）６２６を含む。さらに、ＰＳ制御プレーン６１１のＮＡＳ部分６１４は、ＳＭ／ＲＡＢＭ６２４およびＧＳＭＳ６２８を含む。
【０１４６】
ＣＣ６１８は、回路交換サービス向けのコール管理信号を提供する。ＳＭ／ＲＡＢＭ６２４のセッション管理部分は、ＰＤＰコンテキスト活性化、不活性化および修正を提供する。ＳＭ／ＲＡＢＭ６２４は、また、サービスの質交渉にも提供する。
【０１４７】
ＳＭ／ＲＡＢＭ６２４のＲＢＡＭ部分の主機能は、ＰＤＰコンテキストを無線アクセスベアラに接続することである。このように、ＳＭ／ＲＡＢＭ６２４は、無線ベアラの設定、修正、および解放を担っている。
【０１４８】
アクセス層６１６中のＣＳ制御プレーン６１０およびＰＳ制御プレーン６１１は、無線リソース制御（ＲＲＣ）６１７の上に座している。
【０１４９】
ＰＳユーザプレーン６３０内のＮＡＳ部分６１４は、アプリケーション層６３８、ＴＣＰ／ＵＤＰ層６３６、および、ＰＤＰ層６３４を含む、ＰＤＰ層６３４は、例えば、インターネットプロトコル（ＩＰ）を含む。
【０１５０】
ＰＳユーザプレーン６３０内のアクセス層６１６は、パケットデータ収束プロトコル（ＰＤＣＰ）６３２を含む。ＰＤＣＰ６３２は、ＵＥとＲＮＣとの間で、ＴＣＰ／ＩＰプロトコルを運搬するのに適切なＷＣＤＭＡプロトコルを作成するように設計され（図８に見られるように）、オプションとして、ＩＰトラフィックストリームプロトコルヘッダ圧縮・解凍用である。
【０１５１】
ＵＭＴＳ Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ（ＲＬＣ）６４０およびＭｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ）層６５０は、ＵＭＴＳ無線インターフェースのデータリンクサブレイヤを形成し、ＲＮＣノードおよびＵｓｅｒ Ｅｑｕｉｐｍｅｎｔ上に存在する。
【０１５２】
層１（Ｌ１）ＵＭＴＳ層（物理層６６０）は、ＲＬＣ／ＭＡＣ層６４０および６５０の下にある。この層は、通信用の物理層である。
【０１５３】
以上の記述は、様々な移動体デバイス上でインプリメントされ得るが、一つの移動体デバイスの例が、以下に、図７と関連付けて述べられる。ここで、図７を参照する。
【０１５４】
ＵＥ１１００は、少なくとも音声およびデータ通信能力を有する双方向ワイヤレス通信デバイスであることが好ましい。ＵＥ１１００は、インターネット上の他のコンピュータシステムと通信する能力を有することが好ましい。提供された正確な機能性に依存して、ワイヤレスデバイスは、例えば、データメッセージデバイス、双方向ページャ、ワイヤレスｅメールデバイス、データメッセージ能力を備えた携帯電話、ワイヤレスインターネット機器、または、データ通信デバイスであり得る。
【０１５５】
ＵＥ１１００が双方向通信可能な場合、ＵＥ１１００は、受信機１１１２および送信機１１１４を含む通信サブシステム１１１１、ならびに、１つ以上の好ましくは内蔵または内部のアンテナエレメント１１１６および１１１８、局部発振器（ＬＯ）１１１３、および、デジタル信号プロセッサ（ＤＳＰ）１１２０のような処理モジュールのような関連するコンポーネントを組み込む。通信分野の当業者には明らかなように、通信サブシステムの特定の設計は、そのデバイスが動作することを意図される通信ネットワークに依存する。例えば、ＵＥ１１００は、ＧＰＲＳネットワークまたはＵＭＴＳネットワーク内で動作するように設計された通信サブシステムを含み得る。
【０１５６】
ネットワークアクセス必要条件はまた、ネットワーク１１１９のタイプに依存して変化する。例えば、ＵＭＴＳおよびＧＰＲＳネットワークにおいて、ネットワークアクセスは、ＵＥ１１００の加入者またはユーザと関連する。例えば、ＧＰＲＳ移動体デバイスは、従って、ＧＰＲＳネットワークで作動するために、加入者識別モジュール（ＳＩＭ）カードを要求する。ＵＭＴＳにおいては、ＵＳＩＭまたはＳＩＭモジュールが要求される。ＣＤＭＡにおいては、ＲＵＩＭカードまたはモジュールが要求される。これらは、本明細書においては、ＵＩＭインターフェースと称される。有効なＵＩＭインターフェースがなければ、移動体デバイスは完全には機能しない。局所または非ネットワーク通信機能、および例えば緊急通話など法的に要求される機能が（もしあれば）利用し得るが、しかし、移動体デバイス１１００は、ネットワーク１１００での通信を含む任意の他の機能を実行することはできない。ＵＩＭインターフェース１１４４は通常、ディスケットまたはＰＣＭＣＩＡカードのように、カードが挿入されかつ取り出され得るカードスロットに似ている。ＵＩＭカードは、約６４Ｋのメモリを有し得て、かつ多くのキー構成１１５１、ならびに例えば識別および加入者関連の情報のような他の情報１１５３を保持し得る。
【０１５７】
要求されたネットワーク登録または起動手順が完了したときには、ＵＥ１１００は、ネットワーク１１１９で通信信号を送受信し得る。通信ネットワーク１１１９を通して、アンテナ１１１６によって受信された信号は、受信機１１１２へ入力され、受信機１１１２は、例えば信号増幅、周波数下方変換、フィルタリング、チャネル選択などのような普通の受信機機能を、および図７に示される例示的システムでは、アナログデジタル（Ａ／Ｄ）変換を実行し得る。受信された信号のＡ／Ｄ変換により、例えば、ＤＳＰ１１２０で実行される復調および復号のようなさらに複雑な通信機能が可能になる。同様に、送信される信号は、例えばＤＳＰ１１２０によって、変調およびコード化を含んで、処理されて、かつデジタルアナログ変換、周波数上方変換、フィルタリング、増幅およびアンテナ１１１８を介しての通信ネットワーク１１１９での送信のために送信機１１１４へ入力される。ＤＳＰ１１２０は、通信信号を処理するのみならず、受信機および送信機の制御も提供する。例えば、受信機１１１２および送信機１１１４において通信信号に適用されるゲインは、ＤＳＰ１１２０にインプリメントされた自動ゲイン制御アルゴリズムを通して、適応可能に制御され得る。
【０１５８】
ネットワーク１１１９は、サーバ１１６０および他の要素（図示されず）を含む、複数のシステムとさらに通信し得る。例えば、ネットワーク１１１９は、さまざまなサービスレベルでさまざまなクライアントに便宜を図るために、企業システムとウェブクライアントシステムとの両方と通信し得る。
【０１５９】
ＵＥ１１００は、デバイスの全体的な作動を制御するマイクロプロセッサ１１３８を含むほうが好ましい。少なくともデータ通信を含む通信機能は、通信サブシステム１１１１を通じ実行される。マイクロプロセッサ１１３８はまた、例えば表示デバイス１１２２、フラッシュメモリ１１２４、ランダムアクセスメモリ（ＲＡＭ）１１２６、補助入力／出力（Ｉ／Ｏ）サブシステム１１２８、シリアルポート１１３０、キーボード１１３２、スピーカ１１３４、マイクロフォン１１３６、近距離通信サブシステム１１４０および一般的に１１４２として指定される任意の他のデバイスサブシステムのようなさらなるデバイスサブシステムとも相互作用する。
【０１６０】
図７に示されるサブシステムの一部は、通信関連の機能を実行する一方、他のサブシステムは、「レジデント」またはオンデバイス（ｏｎ−ｄｅｖｉｃｅ）機能を提供し得る。特に、例えばキーボード１１３２および表示デバイス１１２２のような一部のサブシステムは、例えば通信ネットワークで送信するためのテキストメッセージを入力するような通信関連機能と、例えば計算機またはタスクリストのようなデバイスレジデント機能との両方のために使用され得る。
【０１６１】
マイクロプロセッサ１１３８によって使用されるオペレーティングシステムソフトウエアは、例えばフラッシュメモリ１１２４のような永続的な記憶デバイスに格納されることが好ましいが、フラッシュメモリ１１２４の代わりに、読み出し専用メモリ（ＲＯＭ）または類似の格納要素（図示されず）であり得る。当業者は、作動システム、特定のデバイスアプリケーションまたはその部分は、例えばＲＡＭ１１２６のような揮発性のメモリに一時的に書き込み得るということを理解する。受信された通信信号はまた、ＲＡＭ１１２６にも格納され得る。さらに、一意的な識別子が、好ましくも読み出し専用メモリに格納される。
【０１６２】
図示されているように、フラッシュメモリ１１２４は、コンピュータプログラム１１５８ならびにプログラムデータ格納１１５０、１１５２、１１５４および１１５６両方に対する異なるエリアに分離され得る。これらの異なる格納タイプは、各プログラムが、それら自身のデータ格納必要条件のために、フラッシュメモリ１１２４の一部を割り当て得ることを示す。マイクロプロセッサ１１３８は、そのオペレーティングシステム機能に加えて、移動体デバイスでソフトウエアアプリケーションの実行を可能にすることが好ましい。例えば、少なくともデータおよび音声通信アプリケーションを含む、基本オペレーションを制御する所定のアプリケーションのセットは、製造中にＵＥ１１００に通常インストールされる。好ましいソフトウエアアプリケーションは、例えば、しかし限定されず、Ｅメール、カンレンダーイベント、ボイスメール、アポイントメントおよびタスク項目のような、移動体デバイスのユーザに関連するデータ項目を組織化および管理する能力を有するパーソナルインフォメーションマネジャー（ＰＩＭ）アプリケーションであり得る。当然、１つ以上のメモリ記憶デバイスが、ＰＩＭデータ項目の格納を助長するために、移動体デバイスで利用し得る。そのようなＰＩＭアプリケーションは、無線ネットワーク１１１９を介して、データ項目を送受信する能力を有することが好ましい。好ましい実施形態において、ＰＩＭデータ項目は、格納されまたはホストコンピュータシステムと関連づけられる移動体デバイスユーザの対応するデータ項目と、無線ネットワーク１１１９を介してシームレスに（ｓｅａｍｌｅｓｓ）に統合され、同期されおよび更新される。さらなるアプリケーションがまた、ネットワーク１１１９、補助入力／出力（Ｉ／Ｏ）サブシステム１１２８、シリアルポート１１３０、近距離通信サブシステム１１４０または任意の他の適切なサブシステム１１４２を通して、移動体デバイス１１００にロードされ得て、かつ、マイクロプロセッサ１１３８による実行のために、ＲＡＭ１１２６にまたは好ましくは不揮発性の記憶デバイス（図示されず）に、ユーザによってインストールされ得る。アプリケーションインストールにおけるそのような柔軟性は、デバイスの機能性を高め、かつ向上したオンデバイス機能、通信関連機能またはその両方を提供し得る。例えば、安全な通信アプリケーションは、電子商取引機能および他のそのような金融取引が、ＵＥ１１００を使用して実行されることを可能にする。しかしながら、これらのアプリケーションは、上記によると、多くの場合、通信業者によって同意される必要がある。
【０１６３】
データ通信モードにおいて、例えばテキストメッセージまたはウェブページダウンロードのような受信された信号は、通信サブシステム１１１１によって処理され、かつマイクロプロセッサ１１３８に入力され、マイクロプロセッサ１１３８は、表示デバイス１１２２へまたはあるいは補助Ｉ／Ｏデバイス１１２８への入力のために、受信された信号をさらに処理することが好ましい。ＵＥ１１００のユーザはまた、好ましくは完全な英数字キーボードまたは電話タイプのキーパッドであるキーボード１１３２を、表示デバイス１１２２およびおそらく補助Ｉ／Ｏデバイス１１２８と共に使用して、例えばＥメールメッセージのようなデータ項目を構成し得る。そのように構成された項目は、通信サブシステム１１１１を通して、通信ネットワーク上で送信され得る。
【０１６４】
音声通信に対して、ＵＥ１１００の全体的な作動は同様であるが、ただし、受信された信号は、スピーカ１１３４に出力されることが好ましく、送信のための信号は、マイクロフォン１１３６によって生成される点は除く。例えば音声メッセージ録音サブシステムのような代替案の音声またはオーディオＩ／Ｏサブシステムもまた、ＵＥ１１００でインプリメントされ得る。音声またはオーディオ信号出力は主にスピーカ１１３４を通して達成されることが好ましいけれども、表示デバイス１１２２もまた、例えば発呼者の識別、音声通話の継続時間または他の音声通話関連情報の指示を提供するために使用され得る。
【０１６５】
図７におけるシリアルポート１１３０は通常、ユーザのデスクトップコンピュータ（図示されず）との同期が望まれる携帯情報端末（ＰＤＡ）タイプの移動体デバイスにインプリメントされる。そのようなポート１１３０は、ユーザが、外部デバイスまたはソフトウエアアプリケーションを通して、好みを設定することを可能にし、かつ無線通信ネットワークを経由する以外にもＵＥ１１００に情報またはソフトウエアダウンロードを提供することによって移動体デバイス１１００の能力を拡張する。代替案のダウンロード経路は、例えば、安全なデバイス通信を可能にするために、直接的な故に確実で信用のある接続を通して、デバイスに暗号化キーをロードするために使用され得る。
【０１６６】
あるいは、シリアルポート１１３０は他の通信のために使用され得、かつユニバーサルシリアルバス（ＵＳＢ）ポートとして含み得る。インターフェースが、シリアルポート１１３０と関連する。
【０１６７】
例えば、近距離通信サブシステムのような他の通信サブシステム１１４０は、ＵＥ１１００と必ずしも類似のデバイスである必要はない異なるシステムまたはデバイスとの間の通信を提供する、さらなる随意のコンポーネントである。例えば、サブシステム１１４０は、同様にイネーブル化されたシステムおよびデバイスとの通信を提供するために、赤外線デバイスならびに関連回路およびコンポーネント、またはＢｌｕｅｔｏｏｔｈＴＭ通信モジュールを含み得る。
【０１６８】
ここで図８が参照される。図８は、無線通信ネットワークを通して通信するＵＥ８０２を含む通信システム８００のブロック図である。
【０１６９】
ＵＥ８０２は、複数のＮｏｄｅ Ｂ ８０６のうち１つと無線で通信する。各Ｎｏｄｅ
Ｂ ８０６は、エアーインタフェース処理および一部の無線リソース管理機能に対する責任を負う。Ｎｏｄｅ Ｂ ８０６は、ＧＳＭ／ＧＰＲＳネットワークにおけるＢａｓｅ
Ｔｒａｎｓｃｅｉｖｅｒ Ｓｔａｔｉｏｎと類似の機能性を提供する。
【０１７０】
図８の通信システム８００において示される無線リンクは、１つ以上の異なるチャネル、一般的には異なる無線周波数（ＲＦ）チャネル、および無線ネットワークとＵＥ８０２との間で使用される関連プロトコルを表す。Ｕｕエアーインタフェース８０４はＵＥ８０２とＮｏｄｅ Ｂ ８０６との間で使用される。
【０１７１】
ＲＦチャネルは、一般的に、全体的な帯域幅の制限、およびＵＥ８０２の制限されたバッテリーパワーのために、節約されるべき必要のある限りあるリソースである。当業者は、実際の実用における無線ネットワークは、所望の全体的なネットワーク利用可能範囲の広がりに依存して何百ものセルを含み得るということを理解するであろう。すべての関連のコンポーネントは複数のスイッチおよびルータ（図示されず）によって接続され得て、複数のネットワークコントローラによって制限され得る。
【０１７２】
各Ｎｏｄｅ Ｂ ８０６は、無線ネットワークコントローラ（ＲＮＣ）８１０と通信する。ＲＮＣ８１０は、そのエリアにおける無線リソースの制限に対する責任を負う。１つのＲＮＣ８１０は複数のＮｏｄｅ Ｂ ８０６を制御する。
【０１７３】
ＵＭＴＳネットワークにおけるＲＮＣ８１０は、ＧＳＭ／ＧＰＲＳネットワークにおけるＢａｓｅ Ｓｔａｔｉｏｎ Ｃｏｎｔｒｏｌｌｅｒ（ＢＳＣ）機能と同等の機能を提供する。しかしながら、ＲＮＣ８１０は、例えば、ＭＳＣおよびＳＧＳＮを含まない自律的なハンドオーバ管理を含む、より多くの情報を含む。
【０１７４】
Ｎｏｄｅ Ｂ ８０６とＲＮＣ８１０との間で使用されるインターフェースはＩｕｂインターフェース８０８である。ＮＢＡＰ（Ｎｏｄｅ Ｂアプリケーションパート）の信号を送るプロトコルが、３ＧＰＰ ＴＳ２５．４３３ Ｖ３．１１．０（２００２−０９）および３ＧＰＰ ＴＳ ２５．４３３ Ｖ５．７．０（２００４−０１）に規定されているように、主に使用される。
【０１７５】
Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ（ＵＴＲＡＮ）８２０は、ＲＮＣ８１０、Ｎｏｄｅ Ｂ ８０６およびＵｕエアーインタフェース８０４を備える。
【０１７６】
回線交換トラフィックが、Ｍｏｂｉｌｅ Ｓｗｉｔｃｈｉｎｇ Ｃｅｎｔｒｅ（ＭＳＣ）８３０へ回送される。ＭＳＣ８３０は、呼び出しを行い、加入者またはＰＳＴＮ（図示されず）からデータを取り、かつ受けるコンピュータである。
【０１７７】
ＲＮＣ８１０とＭＳＣ８３０との間のトラフィックは、Ｉｕ−ＣＳインターフェース８２８を使用する。Ｉｕ−ＣＳインターフェース８２８は、ＵＴＲＡＮ８１０と中心音声ネットワークとの間で音声トラフィックを（通常）運びかつ信号を送るための回線交換接続である。使用される主な信号プロトコルはＲＡＮＡＰ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ Ａｐｐｌｉｃａｔｉｏｎ Ｐａｒｔ）である。ＲＡＮＡＰプロトコルは、（下記により詳細に規定される）ＭＳＣ８３０またはＳＳＧＮ８５０であり得るＣｏｒｅ Ｎｅｔｗｏｒｋ ８２１とＵＴＲＡＮ８２０との間でのＵＭＴＳ信号発信に使用される。ＲＡＮＡＰプロトコルは、３ＧＰＰ ＴＳ ２５．４１３ Ｖ３．１１．１（２００２−０９）およびＴＳ ２５．４１３ Ｖ５．７．０（２００４−０１）に規定される。
【０１７８】
ネットワークオペレータに登録されたすべてのＵＥ８０２に対して、パーマネントデータ（例えばＵＥ１０２ユーザのプロファイルのような）および一時的なデータ（例えばＵＥ８０２の現在位置のような）はホームロケーションレジストリ（ＨＬＲ）８３８に格納される。ＵＥ８０２への音声通話の場合には、ＨＬＲ８３８が、ＵＥ８０２の現在位置を決定するためにクエリされる。ＭＳＣ８３０のＶｉｓｉｔｏｒ Ｌｏｃａｔｉｏｎ Ｒｅｇｉｓｔｅｒ（ＶＬＲ）８３６が、位置エリアのグループに対する責任を負い、かつ現在その責任のエリア内にある移動局のデータを格納する。これは、より速いアクセスのために、ＨＬＲ８３８からＶＬＲ８３６へ送信されたパーマネント移動局データの部分を含む。しかしながら、ＭＳＣ８３０のＶＬＲ８３６はまた、例えば一時的な識別のような局所データを割り当てかつ格納し得る。ＵＥ８０２はまた、ＨＬＲ８３８によって、システムアクセスについて認証される。
【０１７９】
パケットデータは、Ｓｅｒｖｉｃｅ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ （ＳＧＳＮ）８５０を介して回送される。ＳＧＳＮ８５０は、ＲＮＣとＧＰＲＳ／ＵＭＴＳネットワークにおける中心ネットワークとの間の出入り口であり、その地理的サービスエリア内でＵＥとの相互のデータパケットの引渡しに対する責任を負う。Ｉｕ−ＰＳインターフェース８４８は、ＲＮＣ８１０とＳＧＳＮ８５０との間で使用され、ＵＴＲＡＮ８２０と中心データネットワークとの間でデータトラフィックを（一般的に）運びかつ信号を送るためのパケット交換接続である。使用される主な信号プロトコルは（上記の）ＲＡＮＡＰである。
【０１８０】
ＳＳＧＮ８５０は、Ｇａｔｅｗａｙ ＧＰＲＳ Ｓｕｐｐｏｒｔ Ｎｏｄｅ （ＧＧＳＮ）８６０と通信する。ＧＧＳＮ８６０は、ＵＭＴＳ／ＧＰＲＳネットワークと、例えばインターネットまたは個人のネットワークのような他のネットワークとの間のインターフェースである。ＧＧＳＮ８６０は、Ｇｉインターフェース上で、パブリックデータネットワークＰＤＮ８７０へ接続される。
【０１８１】
当業者は、無線ネットワークは、図８に明確には示されていないが、おそらく他のネットワークを含む、他のシステムに接続され得るということを理解する。ネットワークは、通常は、たとえ交換される実際のパケットデータがない場合であっても。少なくとも何らかの種類のページングおよびシステム情報を、進行中の基礎に基づいて、送信している。ネットワークは多くの部分から成るものの、これらの部分はすべて共に働いて、無線リンクにおいて特定の挙動を生じる。
【０１８２】
本明細書に記述された実施形態は、本出願の技術の要素に対応する要素を有する構造、システムまたは方法の例である。ここに記された記載内容に基づいて、当業者は、本出願の技術の要素に類似して対応する代替の要素を有する実施形態を作成し使用することができる。従って本出願の技術の意図された範囲は、本明細書に記述されたとおりの本出願の技術と異ならない他の構造、システムまたは方法を含み、かつ本明細書に記述された通りの本出願の技術と本質的に異ならない他の構造、システムまたは方法をさらに含む。
【符号の説明】
【０１８３】
１１０ ＲＲＣアイドル状態
１２０ ＲＲＣ接続状態
１２２ ＣＥＬＬ＿ＤＣＨ状態、
１２４ ＣＥＬＬ＿ＦＡＣＨ状態、
１２６ ＣＥＬＬ＿ＰＣＨ状態
１２８ ＵＲＡ＿ＰＣＨ状態
【特許請求の範囲】
【請求項１】
本願明細書に記載された発明。
【請求項１】
本願明細書に記載された発明。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１３−６６２２２（Ｐ２０１３−６６２２２Ａ）
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願番号】特願２０１２−２６３０１５（Ｐ２０１２−２６３０１５）
【出願日】平成２４年１１月３０日（２０１２．１１．３０）
【分割の表示】特願２０１１−８３１７６（Ｐ２０１１−８３１７６）の分割
【原出願日】平成１９年５月１７日（２００７．５．１７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＣＤＭＡ
２．ＧＳＭ
【出願人】（５０００４３５７４）リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Ｒｅｓｅａｒｃｈ Ｉｎ Ｍｏｔｉｏｎ Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】２９５ Ｐｈｉｌｌｉｐ Ｓｔｒｅｅｔ， Ｗａｔｅｒｌｏｏ， Ｏｎｔａｒｉｏ Ｎ２Ｌ ３Ｗ８ Ｃａｎａｄａ
【Ｆターム（参考）】
【公開日】平成２５年４月１１日（２０１３．４．１１）
【国際特許分類】
【出願日】平成２４年１１月３０日（２０１２．１１．３０）
【分割の表示】特願２０１１−８３１７６（Ｐ２０１１−８３１７６）の分割
【原出願日】平成１９年５月１７日（２００７．５．１７）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＷＣＤＭＡ
２．ＧＳＭ
【出願人】（５０００４３５７４）リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Ｒｅｓｅａｒｃｈ Ｉｎ Ｍｏｔｉｏｎ Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】２９５ Ｐｈｉｌｌｉｐ Ｓｔｒｅｅｔ， Ｗａｔｅｒｌｏｏ， Ｏｎｔａｒｉｏ Ｎ２Ｌ ３Ｗ８ Ｃａｎａｄａ
【Ｆターム（参考）】
[ Back to top ]