UMTSネットワークで解放理由指示を信号伝達する方法およびシステム
【課題】ユーザ設備と無線アクセスネットワークとの間の無線リソース制御をするために、両者間での信号伝達解放指示理由を処理する方法を提供すること。
【解決手段】ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法であって、a.該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、b.該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、c.該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、d.該信号伝達接続解放指示を該無線ネットワークで受信するステップと、e.該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する、方法。
【解決手段】ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法であって、a.該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、b.該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、c.該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、d.該信号伝達接続解放指示を該無線ネットワークで受信するステップと、e.該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する、方法。
【発明の詳細な説明】
【技術分野】
【0001】
(出願の分野)
本出願は、ユーザ設備(UE)とユニバーサル陸上無線アクセスネットワーク(UTRAN)との間の無線リソース制御に関し、特に、UMTSネットワーク内の既存の信号伝達接続の解放に関する。
【背景技術】
【0002】
(背景)
ユニバーサル移動電気通信システム(UMTS)は、テキスト、デジタル化された音声、映像、およびマルチメディアを送信する広帯域パケットベースのシステムである。これは、第三世代に対する標準として認知され、広帯域符号分割多重アクセス(W−CDMA)に一般的に基づく。
【0003】
UMTSネットワークにおいて、プロトコルスタックの無線リソース制御(RRC)パーツは、UEとUTRANとの間の無線リソースの割り当て、構成、および解放を担う。このRRCプロトコルは、詳細には、3GGPの仕様書TS 25.331に記載されている。UEが入り得る2つの基本的モードは、「アイドルモード」および「UTRA接続モード」として定義されている。UTRAは、UMTS陸上無線アクセスを略したものである。アイドルモードにおいて、UEが任意のユーザデータを送信したいときはいつでも、あるいはUTRANまたはサービングGPRSサポートノード(SGSN)が、ページングに応答して、それをページングしてプッシュサーバのような外部データネットワークから受信するときはいつでも、UEは、RRC接続をリクエストするように要求される。アイドルモードおよび接続モードの挙動は、3GPPの仕様書のTS 25.304およびTS 25.331に詳細に記載されている。
【0004】
UTRA RRC接続モードにおいて、デバイスは、4つの状態の1つであり得る。これらは、
CELL_DCH:専用チャネルが、データ交換するために、この状態で、アップリンクおよびダウンリンク中のUEに割り当てられる。UEは、3GPP 25.331に概略されたアクションを実行しなくてはならない。
CELL_FACH:この状態において、ユーザ設備には専用チャネルは割り当てられない。その代わりに、共通チャネルが、少量のバースティ(bursty)なデータを交換するために使用される。UEは、3GPP 25.331(3GPP TS 25.304で規定されるセル選択プロセスを含む)に概略されるようなアクションを実行しなくてはならない。
CELL_PCH:UEは、不連続受信(DRX)を使用して、ページングインジケータチャネル(PICH)を介する放送メッセージとページングとをモニタする。アップリンク活動は可能ではない。UEは、3GPP 25.331(3GPP TS 25.304で規定されるようなセル選択プロセスを含む)に概略されるようなアクションを実行しなくてはならない。UEは、セル再選択の後に、CELL UPDATE手順を実行しなくてはならない。
URA_PCH:UEは、不連続受信(DRX)を用い、ページングインディケータチャネル(PICH)を介する放送メッセージおよびページングをモニタする。アップリンク活動は可能ではない。UEは、3GPP 25.331(3GPP TS 25.304で規定されるようなセル選択プロセスを含む)に概略されるようなアクションを実行しなくてはならない。URA UPDATE手順が、UTRAN登録エリア(URA)再選択をのみ介してトリガされる点を除いて、この状態はCELL_PCHに類似する。
【0005】
アイドルモードから接続モードへの移行とこの逆の移行とは、UTRANによって制御される。アイドルモードUEが、RRC接続をリクエストするとき、ネットワークは、UEをCELL_DCHまたはCELL_FACH状態に移動させるかどうかを判断する。UEがRRC接続モードにあるとき、この場合も、RRC接続を解放するときを決定するのは、またネットワークである。ネットワークは、接続を解放する前に、あるいは場合によっては接続を解放する代わりに、UEを一つのRRC状態から別の状態に移動させ得る。状態移行は、UEとネットワークとの間でのデータ活性または不活性によって、典型的にはトリガされる。ネットワークは、所与のアプリケーションに対するデータ交換がいつ完了したかを知り得ないので、ネットワークは、UEへの/からのさらなるデータを期待して、RRC接続をしばらくの間、典型的には保つ。これは、コール設定および引き続く無線ベアラ設定の待ち時間を減らすために、典型的に行われる。RRC接続解放メッセージは、UTRANによって送信され得るのみである。このメッセージは、UEとUTRANとの間の信号リンク接続および全ての無線ベアラを解放する。
【0006】
上記における問題は、UE上のアプリケーションがそのデータ移行を完了し、さらなるデータ交換を一切期待できない場合ですら、そのアプリケーションは、ネットワークがUEを正しい状態に移動させることを、ネットワークを待っていることである。ネットワークは、UE上のアプリケーションが自身のデータ交換を完了した事実に気付いていないことさえあり得る。例えば、UE上のアプリケーションは、それ自身の承認ベースのプロトコルを使用して、UMTSコアネットワークに接続されるそのアプリケーションサーバとデータ交換し得る。例えば、自身に保証された配信をインプリメントするUDP/IPを介してランするアプリケーションである。そのような場合において、UEは、アプリケーションサーバが全てのデータパケットを送信または受信したかどうかを知っており、任意のさらなるデータ交換が生じるかどうかを決定するためにより良い位置にあり、そして、それゆえ、いつパケットサービス(PS)ドメインと関連するRRC接続を終了するかを決定する。UTRANは、いつRRC接続状態が異なる状態に、あるいはアイドルモードへと変化するかを制御するので、また、UTRANがUEと外部サーバとの間におけるデータ伝送の状態に気付いていないという事実により、UEは、要求される状態またはモードよりも、さらに高いデータレートおよび強いバッテリ状態に留まることになり、それによって、バッテリ寿命を使い果たす。このことは、また無線ベアラリソースが不必要に使用中のまま保たれるという事実によって、ネットワークリソースを無駄使いさせる結果となる。
【0007】
上述に対する一つの解決策は、UEがデータトランザクションを終了されたと、UEが認識するときに、UEにUTRANへ信号伝達解放指示(signaling release indication)を送信するようにさせることである。3GPP TS 25.331仕様書の8.1.14.3節に従うと、UTRANは、UEから信号伝達接続解放指示を受信すると、信号伝達接続を解放し得、その結果、UEはアイドルモードに移行する。上述における問題は、信号伝達解放指示が、警告であると考慮され得ることである。ネットワークは、GMMサービスリクエストの失敗、RAUの失敗、あるいはアタッチの失敗が生じたときに、典型的には、信号伝達解放指示を期待するのみである。UEが信号伝達解放をリクエストするときに警告を発することは、ネットワークでの性能モニタおよび警告モニタを非効率なものとする結果になる。
【発明の概要】
【課題を解決するための手段】
【0008】
本発明は、以下の手段を提供する。
【0009】
(項目1)
ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法であって、
a.該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、
b.該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、
c.該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、
d.該信号伝達接続解放指示を該無線ネットワークで受信するステップと、
e.該理由をフィルタリングし、警告を発するかどうかを判断するステップと
を包含する、方法。
【0010】
(項目2)
上記理由は、異常な状態である、項目1に記載の方法。
【0011】
(項目3)
上記異常な状態は、タイマの時間切れである、項目2に記載の方法。
【0012】
(項目4)
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびGMMサービスリクエストタイマからなる群から選択される、項目3に記載の方法。
【0013】
(項目5)
上記理由は、PSデータセッションを終了して、それによってアイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目1に記載の方法。
【0014】
(項目6)
上記フィルタリングするステップは、上記理由が異常な状態であるとき、警告を発する、項目1に記載の方法。
【0015】
(項目7)
上記フィルタリングするステップは、上記理由が上記ユーザ設備によるアイドル移行リクエストであるとき、上記信号伝達接続解放指示を無視する、項目1に記載の方法。
【0016】
(項目8)
信号伝達解放指示理由を処理するのに適合したシステムであって、該システムは、
a.ユーザ設備であって、該ユーザ設備は、ネットワークと通信するのに適合した無線を含む無線サブシステムと;デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと;メモリと;ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有する、ユーザ設備であって、
i.信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、
ii.該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付する手段と、
iii.該添付信号伝達接続解放指示を該無線ネットワークに送信する手段と
を有することによって特徴付けられる、ユーザ設備と、
b.該ユーザ設備と通信するのに適合した無線ネットワークであって、
i.該信号伝達接続解放指示を受信する手段と、
ii.該理由をフィルタリングし、警告を発するかどうかを判断する手段と
によってさらに特徴付けられる、無線ネットワークと
を備える、システム。
【0017】
(項目9)
上記理由は、異常な状態である、項目8に記載のシステム。
【0018】
(項目10)
上記異常な状態は、タイマの時間切れである、項目9に記載のシステム。
【0019】
(項目11)
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびGMMサービスリクエストタイマからなる群から選択される、項目10に記載のシステム。
【0020】
(項目12)
上記理由は、PSデータセッションを終了し、アイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目11に記載のシステム。
【0021】
(項目13)
上記フィルタリングする手段は、上記理由が異常な状態であるとき、警告を発するのに適合する、項目8に記載のシステム。
【0022】
(項目14)
上記フィルタリングする手段は、上記理由が上記ユーザ設備によるアイドル移行リクエストであるとき、上記信号伝達接続解放指示を無視するのに適合する、項目8に記載のシステム。
【0023】
(項目15)
無線ネットワークで改善された警告を追跡するために、ユーザ設備で信号伝達解放指示理由を処理する方法であって、
a.信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、
b.該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、
c.該理由が添付された該添付信号伝達接続解放指示を送信し、これによって、該信号伝達接続解放指示の該理由を識別する該信号伝達接続解放をリクエストする、ステップと
を包含する、方法。
【0024】
(項目16)
上記理由は、異常な状態である、項目15に記載の方法。
【0025】
(項目17)
上記異常な状態は、タイマの時間切れである、項目16に記載の方法。
【0026】
(項目18)
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびGMMサービスリクエストタイマからなる群から選択される、項目17に記載の方法。
【0027】
(項目19)
上記理由は、PSデータセッションを終了し、アイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目15に記載の方法。
【0028】
(項目20)
ネットワーク内で、信号伝達解放指示理由を提供するのに適合したユーザ設備であって、該ユーザ設備は、該ネットワークと通信するのに適合した無線を含む無線サブシステムと;デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと;メモリと;ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有し、該ユーザ設備は、
a.信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、
b.該信号伝達接続解放指示に、該信号伝達接続解放指示に対する理由を添付する手段と、
c.該理由を含む該添付信号伝達接続解放指示を送信し、これによって、該信号伝達接続解放指示の該理由を該信号伝達接続解放指示とともに識別する手段と
を有することによって特徴付けられる、ユーザ設備。
【0029】
(項目21)
信号伝達接続の解放を容易にするためのユーザ設備用装置であって、該装置は、
a.信号伝達接続解放指示が、送信されるべきかどうかをチェックするように構成されたチェッカと、
b.信号伝達接続解放指示が送信されるべきであるという該チェッカによる指示に応答して、該信号伝達接続解放指示を送信するように構成された信号伝達接続解放指示センダであって、該信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む信号伝達解放指示を含む、信号伝達接続解放指示センダと
を備える、装置。
【0030】
(項目22)
上記チェッカは、上記信号伝達接続解放指示を送信するのに引き続き、該信号伝達接続解放指示の配信を確認する前に、上記ユーザ設備の信号伝達接続が必要とされるかどうかをチェックするようにさらに構成される、項目21に記載の装置。
【0031】
(項目23)
上記信号伝達接続解放指示センダは、上記信号伝達接続解放指示を再送信するようにさらに構成される、項目22に記載の装置。
【0032】
(項目24)
信号伝達接続解放指示によって、動作するネットワーク装置であって、該ネットワーク装置は、
a.該信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験して、該信号伝達解放指示理由フィールドが異常な状態を指示するかどうかをチェックするように構成された試験機と、
b.該試験機による試験が、該信号伝達解放指示理由フィールドが該異常な状態を指示すると判断する場合、警告を選択的に生成するように構成された警告生成器と
を備える、ネットワーク装置。
【0033】
(項目25)
上記ネットワーク装置は、複数のロジカル層を備え、上記試験機は、該複数のロジカル層の第一のロジカル層で具現化され、該試験機は、該複数のロジカル層の第二のロジカル層に、信号伝達接続解放をリクエストするようにさらに構成される、項目24に記載のネットワーク装置。
【0034】
(摘要)
ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法およびシステムであって、該方法は、該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、該信号伝達接続解放指示を該無線ネットワークで受信するステップと、該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する、方法。
【0035】
(詳細な説明)
本システムおよび方法は、RRC接続モードから、より効率的なバッテリ状態またはモードへ移行させる一方で、信号伝達解放指示の理由がUEのアイドル移行リクエストである場合、ネットワークが、信号伝達解放指示を警告と考慮しないこと保証することを提供する。特に、本方法および装置は、特定されたコアネットワークドメインに対する信号接続の終了をUEが開始すること、または、移行が一つの接続状態から他の接続状態へと生じるべきであるとUTRANに指示することのいずれかに基づいて移行を提供する。以下の説明は、UMTSの例示的なインプリメンテーションに関して記載される。しかしながら、本発明の教示は、他の無線通信システムにも同様に適用可能であることは、理解されるべきである。
【0036】
特に、UE上のアプリケーションは、それがデータの交換を用いてなされたと決定する場合、好適には、それは「なされた」との指示を、UEソフトウェアの「RRC接続マネージャ」コンポーネントへ送信する。RRC接続マネージャは、関連パケットデータプロトコル(PDP)コンテキスト、関連パケット交換(PS)無線ベアラ、および関連回路交換(CS)無線ベアラなどの全ての現行のアプリケーション(一つまたは複数のプロトコルを介したサービスを提供するものを含む)を追跡し続ける。PDPコンテキストは、UMTSコアネットワークにわたってランするUEとPDN(公衆データネットワーク)との間の論理関係である。UE上の一つまたは複数のアプリケーション(例えば、eメールアプリケーションおよびブラウザアプリケーション)は、一つのPDPコンテキストと関連し得る。一部の場合において、UE上の一つのアプリケーションは、一次PDPコンテキストと関連し、複数のアプリケーションは、二次PDPコンテキストに結合され得る。RRC接続マネージャは、同時に活性であるUE上の異なるアプリケーションから、「なされた」との指示を受信する。例えば、ユーザは、ウェブを閲覧している間に、プッシュサーバからeメールを受信し得る。eメールアプリケーションが承認を送信した後、それは、そのデータトランザクションを完了したことを指示し得るが、しかしながら、ブラウザアプリケーションは、そのような指示を送信し得ない。活性なアプリケーションからのそのような指示の合成状態に基づいて、UEソフトウェアは、それが、コアネットワークパケットサービスドメインの信号伝達接続解放を開始し得る前に、どの程度待機するべきかを決定し得る。この場合における遅延は、そのアプリケーションがデータ交換を真に終了させ、RRC接続を要求しないことを保証するために導入され得る。その遅延は、トラフィック履歴および/またはアプリケーションプロフィールに基づいてダイナミックであり得る。どのアプリケーションも一切データを交換することが期待されないという可能性が幾分かあると、RRC接続マネージャが判断するときはいつも、RRC接続マネージャは適切なドメイン(例えば、PSドメイン)に対して、信号伝達接続解放指示手順を送信し得る。あるいは、UTRANに接続されたモード内において、状態移行のリクエストを送信し得る。
【0037】
上述の判断はまた、ネットワークが、URA_PCH状態およびこの状態への移行挙動をサポートするかどうかを考慮し得る。
【0038】
UEによって開始されたアイドルモードへの移行は、RRC接続モードの任意の状態から生じ得、ネットワークをRRC接続から解放させ、UEをアイドルモードへと移動させることによって終わる。当業者によって理解されるように、アイドルモード中のUEは、接続状態中のUEよりも、バッテリがはるかに低い。
【0039】
しかしながら、信号伝達接続解放指示の送信は、ネットワークに、結果として、警告が起こったことを考慮させ得る。信号伝達解放指示が、トラフィックが一切期待されないというRRCによる判断の結果の場合、好ましい実施形態において、ネットワークは、信号伝達解放指示が、異常な状態であるのではなく、リクエストされたアイドル移行の結果であることを区別し得る。この区別によって、キー性能インディケータ(KPI)のようなインディケータがより正確になり、性能のモニタと警告のモニタとを改善することができる。
【0040】
本方法は、UEが、既存の信号伝達解放指示に、信号伝達解放指示の理由を提供するフィールドを添付することを可能にする。ネットワークは、次いで、添付されたフィールドを用いて、真の警告状態をUEがアイドル状態に置かせるようにリクエストした状況からフィルタリングし得る。なぜなら、このリクエストした状況は、さらなるデータが一切期待できないからである。これは、警告および性能のモニタの効率を改善し、その一方で、UEをより迅速にアイドルモードに移動させて、そのバッテリリソースを節約することを可能にする。
【0041】
本出願は、それゆえ、ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法を提供し、該方法は、該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、該信号伝達接続解放指示を該無線ネットワークで受信するステップと、該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する。
【0042】
本出願は、さらに、信号伝達解放指示理由を処理するのに適合したシステムをさらに提供し、該システムは、ユーザ設備であって、該ユーザ設備は、UMTSネットワークと通信するのに適合した無線を含む無線サブシステムと;デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと;メモリと;ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有する、ユーザ設備であって、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付する手段と、該添付信号伝達接続解放指示を該無線ネットワークに送信する手段とを有することによって特徴付けられる、ユーザ設備と、該ユーザ設備と通信するのに適合した無線ネットワークであって、該信号伝達接続解放指示を受信する手段と、該理由をフィルタリングし、警告を発するかどうかを判断する手段とによってさらに特徴付けられる、無線ネットワークとを備える。
【0043】
本出願は、またさらに、無線ネットワークで改善された警告を追跡するために、ユーザ設備で信号伝達解放指示理由を処理する方法を提供し、該方法は、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップであって、該無線ネットワークは、該信号伝達接続解放指示の該理由の指示を提供する、ステップとを包含する。
【0044】
本出願は、またさらに、信号伝達接続の解放を容易にするユーザ設備用装置を提供する。チェッカは、信号伝達接続解放指示が、送信されるべきかどうかをチェックするように構成される。信号伝達接続解放指示センダは、信号伝達接続解放指示が送信されるべきであるという該チェッカによる指示に応答して、該信号伝達接続解放指示を送信するように構成される。該信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む。
【0045】
本出願は、またさらに、信号伝達接続解放指示によって、動作するネットワーク装置を提供する。試験機は、該信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験するように構成される。該試験機は、該信号伝達解放指示理由フィールドが異常な状態を指示するかどうかをチェックする。警告生成機は、該試験機による試験が、該信号伝達解放指示理由フィールドが該異常な状態を指示すると判断する場合、警告を選択的に生成するように構成される。
【0046】
本出願は、またさらに、UMTSネットワーク内で、信号伝達解放指示理由を提供するのに適合したユーザ設備を提供し、該ユーザ設備は、該UMTSネットワークと通信するのに適合した無線を含む無線サブシステムと;デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと;メモリと;ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有し、該ユーザ設備は、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、該信号伝達接続解放指示に、該信号伝達接続解放指示に対する理由を添付する手段と、該理由を含む該添付信号伝達接続解放指示を送信する手段であって、該無線ネットワークは、該信号伝達接続解放指示の該理由の指示を提供する、手段とを有することによって特徴付けられる。
【図面の簡単な説明】
【0047】
本出願は、図面を参照することで、よりよく理解される。
【図1】図1は、RRC状態および移行を示すブロック図である。
【図2】図2は、様々なUMTSセルおよびURAを示すUMTSネットワークの模式図である。
【図3】図3は、RRC接続設定の様々な段階を示すブロック図である。
【図4A】図4Aは、CELL_DCH接続モード状態と、現行方法に従うUTRANによって起動されるとアイドルモードとの間の例示的な移行のブロック図である。
【図4B】図4Bは、信号伝達解放指示を利用して、CELL_DCH状態接続モードからアイドルモードへの移行との間の例示的な移行を示すブロック図である。
【図5A】UTRANによって開始された、CELL_DCH不活動からCELL_FACH不活動へ、およびアイドルモードへの例示的な移行のブロック図である。
【図5B】図5Bは、信号伝達解放指示を利用して、CELL_DCH不活性とアイドルモードとの間の例示的な移行のブロック図である。
【図6】図6は、UMTSプロトコルスタックのブロック図である。
【図7】図7は、本方法と関連して用いられる例示的なUEである。
【図8】図8は、本方法と関連して用いられる例示的なネットワークである。
【図9】図9は、UEで、信号伝達接続解放指示に対する理由を追加するステップを示す流れ図である。
【図10】図10は、理由を有する信号伝達接続解放指示を受信した後に、UEによって取られるステップを示す流れ図である。
【発明を実施するための形態】
【0048】
ここで、図1を参照する。図1は、UMTSネットワークにおけるプロトコルスタックの無線リソース制御部分に対する様々なモードおよび状態を示すブロック図である。特に、RRCは、RRCアイドル状態110またはRRC接続状態120のいずれかであり得る。
【0049】
当業者には理解されるように、UMTSネットワークは、2つの陸上ベースのネットワークセグメントからなる。これらは、コアネットワーク(CN)および(図8に示されるような)ユニバーサル陸上無線アクセスネットワーク(UTRAN)である。コアネットワークは、外部ネットワークへのデータコールおよびデータ接続の交換およびルーティングを担い、UTRANは、全ての無線関連機能性を扱う。
【0050】
アイドルモード110において、UEとネットワークとの間でデータが交換される必要があるときはいつも、UEはRRC接続をリクエストし、無線リソースを設定しなくてはならない。これは、UEが接続を要求してデータを送信するアプリケーションの結果として、あるいはUEが、UTRANまたはSGSNがUEをページングしたかどうかを指示するページングチャネルをモニタして、プッシュサーバのような外部データネットワークからデータを受信する結果としてのいずれかであり得る。さらに、UEは、また、ロケーションエリア更新のような信号伝達メッセージを移動管理(Mobility Management)に送信する必要があるときは、いつでもRRC接続をリクエストする。
【0051】
一度、UEがUTRANにリクエストを送信すると、無線接続が確立し、UTRANは、RRC接続が中に入るようにするために状態を選択する。特に、RRC接続モード120は、4つの個別状態を含む。これらは、CELL_DCH状態122、CELL_FACH状態124、CELL_PCH状態126、およびURA_PCH状態128である。
【0052】
アイドルモード110から、RRC接続状態は、セル専用チャネル(CELL_DCH)状態122またはセル転送アクセスチャネル(CELL_FACH)状態124のいずれかに進み得る。
【0053】
CELL_DCH状態122において、専用チャネルが、アップリンクとダウンリンクとの双方のためにUEに割り当てられ、データ交換する。この状態は、UEに割り当てられた専用物理的チャネルを有するので、UEから最も多くのバッテリ電力を典型的に要求する。
【0054】
代替として、UTRANは、アイドルモード110からCELL_FACH状態124に移動し得る。CELL_FACH状態において、専用チャネルはUEに割り当てられない。その代わりに、共通チャネルが、信号伝達を少量のバースティなデータで送信するために使用される。しかしながら、UEは、相変わらずFACHを連続的にモニタしなくてはならない。それゆえ、バッテリ電力を消費する。
【0055】
RRC接続モード120内において、RRC状態は、UTRANの行動(discretion)を変更し得る。特に、データ不活性が特定の時間の間に検出された場合、あるいは所定の閾値未満のスループットが検出された場合、UTRANは、RRC状態をCELL_DCH状態122から、CELL_FACH状態124、CELL_PCH状態126、またはURA_PCH状態128に、移動させ得る。同様に、ペイロードが所定の閾値を超えることが検出される場合、RRC状態は、CELL_FACH124からCELL_DCH122に移動し得る。
【0056】
CELL_FACH状態124から、データ不活性が一部のネットワークにおいて、所定の時間にわたって検出された場合、UTRANは、RRC状態をCELL_FACH状態124からページングチャネル(PCH)状態に移動させ得る。これは、CELL_PCH 状態126またはURA_PCH状態128のいずれかであり得る。
【0057】
CELL_PCH状態126またはURA_PCH状態128から、UEは、専用チャネルをリクエストする更新手順を開始するために、CELL_FACH状態124に移動されなくてはならない。これは、UEが制御する唯一の状態移行である。
【0058】
CELL_PCH状態126およびURA_PCH状態128は、不連続受信サイクル(DRX)を使用し、包装メッセージおよびページングインディケータチャネル(PICH)によるページングをモニタする。アップリンク活動は、一切不可能である。
【0059】
CELL_PCH状態126とURA_PCH状態128との間の差は、URA_PCH状態が、現在のセルの中に存在するURAアイデンティティのリストの中にUEの現在のUTRAN登録エリア(URA)がない場合、URA更新手順をトリガすることのみである。具体的には、図2を参照する。図2は、様々なUMTSセル210、212、および214の図を示す。これらのセルの全ては、CELL_PCH状態が再選択された場合、セル更新手順を要求する。しかしながら、UTRAN登録エリアにおいて、各セルは、同じUTRAN登録エリア220内にあり、したがって、URA更新手順は、URA_PCHモードのときに、210、212、および214の間で移動するとき、トリガされない。
【0060】
図2に示されるように、他のセル218は、URA220の外側にアップリンク、別個のURAの一部となり得るか、あるいはURAになり得ない。
【0061】
当業者には理解されるように、バッテリ寿命見通しから、アイドル状態は、上述の状態と比べて、最も少ないバッテリ使用法を提供する。具体的に、UEは、ページングチャネルをインターバルだけにおいて、モニタすることを要求されるので、無線は、連続的にオンである必要はないが、その代わりに、定期的に目覚める必要がある。これに対するトレードオフは、データを送信する待ち時間である。しかしながら、この待ち時間は、さほど長くもない場合、アイドルモードであってバッテリ電力を節約することのメリットは、接続の待ち時間のデメリットを上回る。
【0062】
再び、図1を参照する。様々なUMTSインフラベンダは、様々な基準に基づいて、122、124、126、および128の状態間を移動する。例示的なインフラは、以下に概略される。
【0063】
第一の例示的なインフラにおいて、RRCは、アイドルモードとCell_DCH状態との間を直接移動する。Cell_DCH状態において、2秒間活性でないことが検出されると、RRC状態は、Cell_FACH状態124に変化する。Cell_FACH状態124において、10秒間活性でないことが検出されたら、RRC状態は、PCH状態126に変化する。Cell_PCH状態126において、45分間活性でないことが検出されたら、その結果、RRC状態は、アイドル状態110に戻る。
【0064】
第二の例示的なインフラにおいて、RRC移行は、ペイロード閾値に依存して、アイドルモード110と接続モード120との間で発生し得る。第二のインフラにおいて、ペイロードが、所定の閾値未満であれば、UTRANは、RRC状態からCELL_FACH状態124に移動する。逆に、データが所定のペイロードを上回る場合、UTRANは、RR状態をCELL_DCH状態122に移行する。第二のインフラで、CELL_DCH状態122において、2分間活性でないことが検出されると、UTRANは、RRCをCELL_FACH状態124に移動する。CELL_FACH状態124において、5分間活性でないことが検出されると、UTRANは、RRC段階をCELL_PCH状態126に移動する。CELL_PCH状態126において、アイドルモード110に戻る前に、2時間の不活動が要求される。
【0065】
第三の例示的なインフラにおいて、アイドルモードと接続モード120との間の移動は、常に、CELL_DCH状態122である。CELL_DCH状態122において、5秒間活性でなかった後に、UTRANは、RRC状態をCELL_FACH状態124に移動する。CELL_FACH状態124において、30秒間活性でないと、その結果、アイドル状態110に移動して戻る。
【0066】
第四の例示的なインフラにおいて、RRCは、アイドルモードから接続モードに直接移行し、CELL_DCH状態122になる。第四の例示的なインフラにおいて、CELL_DCH状態122は、2つのサブ状態を含む。第一は、高いデータレートを有するサブ状態であり、第二のサブ状態は、より低いデータレートを含むが、それでもなおCELL_DCH状態の範囲内である。第四の例示的なインフラにおいて、RRCは、アイドルモード110から、高いデータレートのCELL_DCHサブ状態へと直接移行する。10秒間活性でない後、RRC状態は、低いCELL_DCH状態に移行する。低データのCELL_DCH状態122から17秒間活性でないと、その結果、RRC状態は、アイドルモード110に変化する。
【0067】
上述の4つの例示的なインフラは、様々なUMTSのインフラベンダが、状態をインプリメントしているかを示す。当業者には理解されるように、各場合において、実際のデータ交換(例えば、eメール)に要した時間は、CELL_DCHまたはCELL_FACH状態に留まっていることを要求される時間に比べ、かなり短い。このため、不必要なカレントドレインが生じ、その結果、ユーザは、UMTSのような新たな世代のネットワークにおいて、GPRSのような以前の世代のネットワークよりも、悪化するのを体験する。
【0068】
さらに、CELL_PCH状態は、CELL_FACH状態よりも最適であるが、バッテリ寿命の観点から、CELL_PCH状態におけるDRXサイクルは、典型的には、アイドルモード110より低い値に設定される。その結果、UEは、アイドルモードよりも、CELL_PCH状態で、より頻繁に目覚めていることが要求される。
【0069】
アイドル状態のサイクルと同様のDRXサイクルを有するURA_PCH状態は、バッテリ寿命と接続における待ち時間との最適なトレードアップのように思われる。しかしながら、URA_PCHは、現在、UTRANでサポートされていない。それゆえ、バッテリ寿命の観点から、アプリケーションがデータ交換で終了したら、できるだけ迅速に、アイドルモードに移行することが望ましい。
【0070】
ここで、図3を参照する。アイドルモードから接続モードへ移行するとき、様々な信号伝達およびデータ接続が、生成される必要がある。図3を参照すると、実行されるべき必要のある第一のアイテムは、RRC接続設定である。上述のように、このRRC接続設定は、UTRANによってのみ、解体され得る。
【0071】
一度、RRC接続設定310が達成されると、信号接続設定312が開始される。
【0072】
一度、信号設定312が終了すると、暗号化・保全性設定(ciphering and integrity setup)314が開始される。これが完了すると、無線ベアラ設定316が達成される。この時点で、データは、UEとUTRANとの間で交換され得る。
【0073】
接続解体は、一般的に、この逆順で同様に達成される。無線ベアラ設定316は、解体され、次いで、RRC接続設定310が取り払われる。この時点で、RRCは、図1に示すように、アイドルモード110へと移動する。
【0074】
現在の3GPP仕様によれば、UEが、RRC接続を解放すること、または、RRC状態にとってその好みを指示することはできないが、それでも、UEは、特定のコアネットワークドメイン(例えば、パケット交換アプリケーションで使用されるPacket Switched(PS))に対する信号伝達接続の終了を指示し得る。3GPP TS 25.331の8.1.14.1節に従うと、信号伝達接続解放指示手順は、UEによって使用され、UTRANに、その信号伝達接続の一つが解放されたことを指示する。この手順は、順に、RRC接続解放手順を開始し得る。
【0075】
このように、現行の3GGP仕様の範囲に留まると、信号伝達接続解放は、信号接続設定312の解体によって、開始され得る。信号伝達接続設定312を解体する(tear
down)ことは、UEの能力の範囲内であり、次いで、仕様に従えば、このことは、RRC接続解放を開始し「得る」。
【0076】
当業者には理解されるように、信号伝達接続設定312が、解体される場合、UTRANは、また、解読・保全性設定312を一掃し、信号接続設定312が解体された後に、無線ベアラ設定316を一掃する必要がある。
【0077】
信号伝達接続設定312が、解体される場合、RRC接続設定は、典型的には、現在のベンダのインフラに対するネットワークによって停止される。
【0078】
上述を用いて、データ交換とともに行われるとUEが決定する場合、例えば、UEソフトウェアの「RRC接続マネージャ」コンポーネントが、データ交換が完了したという指示を提供された場合、RRC接続マネージャは、信号伝達接続設定312を解体するかどうかを判断し得る。例えば、デバイス上でのeメールアプリケーションは、eメールが本当にプッシュサーバによって受信されたという、プッシュeメールサーバからの通知を受信したという指示を送信する。RRCマネージャは、関連PDPコンテキスト、関連PS無線ベアラおよび関連回路交換(CS)無線ベアラの全ての現行のアプリケーションを追跡し得る。この場合の遅延は、データ交換でもって、そのアプリケーションが本当に終了し、もはや、「完了」指示を送信した後もRRC接続をもはや必要としない。この遅延は、このアプリケーションと関連する非活性なタイムアウトと同等である。各アプリケーションは、それ自身の非活性なタイムアウトを有し得る。例えば、eメールアプリケーションは、5秒の非活性なタイムアウトを有し得るが、活性なブラウザアプリケーションは、60秒の非活性なタイムアウトを有し得る。活性なアプリケーションからの全てのこのような指示の復号ステータスに基づいて、UEソフトウェアは、UEソフトウェアが、適切なコアネットワーク(例えば、PSドメイン)の信号伝達接続解放を開始し得るまでに、どのくらい待つべきであるかを判断する。
【0079】
非活性なタイムアウトは、トラフィックパターン履歴および/またはアプリケーションプロファイルに基づいて、ダイナミックベースでなされ得る。
【0080】
RRC接続マネージャが、どのアプリケーションもデータ交換を期待されないとある程度の確率で判断するときはいつも、RCC接続マネージャは、適切なドメインに対する信号伝達接続解放指示手順を送信し得る。
【0081】
上述のUEで開始されたアイドルモードへの移行は、図1に示すようなRRC接続モード120の任意の段階で起こり得て、また、RRC接続ネットワークから解放させ、図1に示すようなアイドルモード110に移動させて終了する。これは、また、音声コール中に、UEが任意のパケットデータサービスを実行しているときにも、適用可能である。この場合、PSドメインのみが解放されるが、CSドメインは接続されたままである。
【0082】
上述のネットワークの考え方における問題は、UEによって送信された信号伝達接続解放指示が、警告として解釈されることである。信号伝達ネットワーク解放が、適用タイマ時間切れのためにより、UEによって明確なアクションの結果であり、それゆえ、さらなるデータが期待されない場合、上記の指示によって生じた警告は、性能および警告指示をスキューする。キー性能インディケータは、これによって変更され得、効率の損失へと導く。
【0083】
好ましくは、理由が、UTRANに指示に対する理由を指示する信号伝達接続解放指示に追加されるべきである。好ましい実施形態において、その理由は、異常な状態が指示の理由となったという指示か、あるいはリクエストされたアイドル移行の結果として、UEによって開始されたという指示であり得る。他の正常(すなわち、異常でない)トランザクションは、結果として、信号伝達接続解放指示の送信であり得る。
【0084】
さらなる好ましい実施形態において、様々なタイムアウトは、異常な状態に対する信号伝達接続指示の理由となり得る。以下のタイマの例は、網羅的なものでなく、他のタイマ、あるいは他の条件も可能である。例えば、3GPP.TS 24.008の10.2.47は、タイマT3310として、以下を特定する。
【0085】
【表1】
このタイマは、アタッチ失敗を指示するために使用される。アタッチ失敗は、ネットワークの結果であり得るか、あるいは衝突または不良無線周波数(RF)のようなRF問題であり得る。
【0086】
添付の試みは、複数回起こり得、アタッチ失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【0087】
3GPPの10.2.47の第二のタイマは、T3330であり、以下のように特定される。
【0088】
【表2】
このタイマは、ルーティングエリア更新失敗を指示するために使用される。タイマが時間切れになると、さらなるルーティングエリア更新が、複数回リクエストされ得て、ルーティングエリア更新失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【0089】
3GPPの10.2.47の第三のタイマは、T3340であり、以下のように特定される。
【0090】
【表3】
このタイマは、GMMサービスリクエスト失敗を指示するために使用される。タイマが時間切れになると、さらなるGMMサービスリクエストが、複数回開始され得、GMMサービスリクエスト失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【0091】
このように、信号伝達解放指示は、異常な状態およびUEによる解放に限られる代わりに、信号伝達解放指示は、さらに、異常な状態に対してどのタイマが失敗したかに関する情報を含み得る。信号伝達接続解放指示は、以下のように構造化され得る。
【0092】
【表4】
このメッセージは、UEによって使用され、UTRANに既存の信号伝達接続を解放するように指示する。信号伝達解放指示を追加すると、UTRANまたは他のネットワークエレメントは、信号伝達解放指示の理由、つまり異常な状態によるものであったのか、あるいは異常な状態とは何であったかを受信することができる。そして、RRC接続解放手順が、次いで、開始されることが可能になる。
【0093】
一つのインプリメンテーションにおいて、UEは、解放または中断するようにというリクエストを受信すると、特定のCN(コアネットワーク)ドメインに対する上部層からの信号伝達接続は、IE(情報エレメント)「CNドメインアイデンティティ」で識別される特定のCNドメインに対する変数(例えば、変数ESTABLISHED_SIGNALING_CONNECTIONS)で識別されるような信号伝達接続が存在する場合、信号伝達接続解放指示を開始する。変数が、既存の信号伝達接続を一切識別しない場合、その特定のCNドメインに対する信号伝達接続の進行中の確立は、いずれも別の方法で中断される。そして、CELL_PCHまたはURA_PCH状態で、信号伝達接続解放指示手順が開始すると、UEは、「アップリンクデータ送信」理由を用いて、セル更新手順を実行する。そして、セル更新手順が成功裏に完了したとき、UEは、その後の信号伝達接続解放指示手順を続ける。
【0094】
すなわち、UEは、IE「CNドメインアイデンティティ」を上部ロジカル層によって指示された値に設定する。IEの値は、CNドメインを指示し、その関連信号伝達接続は、上部層が解放されるべきことを指示する関連信号伝達接続である。CNドメインアイデンティティが、PSドメインに設定される場合で、上部層は、このリクエストを開始する理由を指示する場合、IE「信号伝達解放指示理由」は、これに従って設定される。UEは、変数「established_signaling_connections」から上部層によって指示されたアイデンティティを有する信号伝達接続をさらに除去する。そして、UEは、信号伝達接続解放指示メッセージを、例えば、AM RLCを用いて、DCCH上で送信する。RLCによって解放指示メッセージの配信が成功したことを確認すると、この手順は終了する。
【0095】
IE「Signaling Release Indication Cause」も、また本開示の実施形態に関して用いられる。解放理由は、例えば、既存のメッセージ定義で、アラインされる。上部層解放理由メッセージも例えば、以下のように構造化される。
【0096】
【表5】
この例において、T3310、T3330、およびT3340は、上記で識別された対応するように番号付けされたタイマの時間切れに相当する。理由値は、一つの実施形態において、状態移行によって判断するUTRANに提供する「UE Requested idle transition」よりも、むしろ「UE Requested PS Data session end」として、設定可能である。しかしながら、期待される結果は、理由値によって識別される結果に対応する。信号伝達接続解放指示への拡張(extension)は、好ましいが、必ずしも必要ではなく、クリティカルでない拡張である。
【0097】
ここで、図9を参照する。図9は、様々なドメイン(例えば、PSまたはCS)に対する信号伝達接続解放指示を送信するかしないかを例示的にUEをモニタする流れ図である。プロセス910は、ステップ910で開始する。
【0098】
UEは、ステップ912へ移行し、ここで、異常な状態が存在するかどうかを見るためにチェックする。このような異常な状態には、例えば、上述したような、タイマT3310、タイマT3320、またはタイマT3340の時間切れを含み得る。これらのタイマが、ある所定の回数、時間切れとなった場合、あるいはこれらのタイマのいずれかの時間切れに基づいて、明確な拒絶を受信する場合、UEは、ステップ914に進み、ここで、信号伝達接続解放指示を送信する。信号伝達接続解放指示メッセージは、信号伝達解放指示理由フィールドを用いて添付される。信号伝達解放指示理由フィールドは、信号伝達接続解放指示が異常な状態(conditionまたはstate)に基づくことを少なくとも含み、好ましい実施形態は、異常な状態の結果としてタイムアウトする特定のタイマを含む。
【0099】
逆に、ステップ912で、UEが異常な状態が存在しないことを見出す場合、UEは、ステップ920に進み、ここで、さらなるデータがUEで期待されるかどうかをチェックする。これは、上述のように、eメールが送信され、そのeメールの送信確認がUEに返信されたときを含む。UEがさらなるデータがもはや期待されないかどうかを判断する他の例は、当業者には周知である。
【0100】
ステップ920で、データ伝達が終了した(あるいは、回路交換の場合、ドメインコールが終了した)と、UEが判断する場合、UEは、ステップ922に進み、ここで、信号伝達接続解放指示を送信する。この信号伝達接続解放指示の中に、信号伝達解放指示理由フィールドが追加され、このフィールドはUEがアイドル移行をリクエストしたという事実を含む。
【0101】
データが終了しない場合、ステップ920から、UEはループを戻り、ステップ912で異常な状態が存在しないかどうかをチェックし、ステップ920でデータが終了するかどうかをチェックし続ける。
【0102】
一度、ステップ914またはステップ922で、信号伝達接続解放指示が送信されると、プロセスは、ステップ930に進み、終了する。
【0103】
UEは、機能エレメントを含む。これらの機能エレメントは、例えば、UEマイクロプロセッサの動作を介して実行されるアプリケーションまたはアルゴリズムによって、あるいは、ハードウェアインプリメンテーションによって、インプリメント可能であり、チェッカおよび信号伝達接続解放指示センダを形成する。チェッカは、信号伝達接続解放指示が送信されるべきかどうかをチェックするように構成される。そして、信号伝達接続解放指示センダが、チェッカによる信号伝達接続解放指示を送信すべきであるという指示に応答して、信号伝達接続解放指示を送信するように構成される。信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む。
【0104】
一つのインプリメンテーションにおいて、ネットワークは、代わりに、暗黙にタイマのタイムアウトに気付くようにされ、UEはタイマのタイムアウトを指示する理由値を送信する必要はない。つまり、タイマは、ネットワークの承諾を受けて、時間計測を開始する。理由コードが規定され、その理由コードは、ネットワークによってUEに提供される。このような理由コードは、タイマを開始するために、UEによって使用される。そして、ネットワークによって以前に送信された理由コードが、タイマに時間測定をさせると、ネットワークは、暗黙のうちに、タイマの次のタイムアウトに対する根拠に気付く。そして、その結果として、UEは、タイマの時間切れを指示する理由値を送信する必要がなくなる。
【0105】
図10を参照すると、ネットワークエレメントが、ステップ1010で信号伝達接続解放指示を受信するとき、ネットワークエレメントは、ステップ1014で信号伝達解放指示理由フィールドを試験し、ステップ1016で、その理由が異常な理由であるかどうか、あるいはその理由はUEがアイドル移行をリクエストしたことによるかどうかをチェックする。ステップ1016で、信号伝達接続解放指示が、異常な理由である場合、ネットワークノードは、ステップ1020に進み、ここでは、警告は、性能をモニタするため、および警告モニタの目的であると注記される。キー性能インディケータは、適切に更新され得る。
【0106】
逆に、ステップ1016で、信号伝達接続解放指示の理由が、異常な状態の結果でない場合、あるいは換言すれば、UEがアイドル移行をリクエストした結果である場合、ネットワークノードは、ステップ1030に進み、ここで、警告が発せられず、指示は、性能統計からフィルタリングされ得、これによって、性能統計がスキューすることが妨げられる。ステップ1020またはステップ1030から、ネットワークノードは、ステップ1040に進み、プロセスは終了する。
【0107】
信号伝達解放指示理由フィールドを受信し、試験すると、その結果、ネットワークエレメントによって、RRC接続解放手順が開始される。そして、パケット交換データ接続が終了する。
【0108】
当業者には理解されるように、ステップ1020は、様々な警告状態の間でさらに区分するために使用され得る。例えば、T3310のタイムアウトは、第一の統計セットを維持するために使用され得、T3330のタイムアウトは、第二の統計セットを維持するために使用され得る。ステップ1020は、異常な状態の理由で区別し得る。これによって、ネットワークオペレータは、性能をより効率的に追跡可能となる。
【0109】
ネットワークは、機能エレメントを含む。これらの機能エレメントは、例えば、UEマイクロプロセッサの動作を介して実行されるアプリケーションまたはアルゴリズムによって、あるいは、ハードウェアインプリメンテーションによって、インプリメント可能であり、試験機および警告生成機を形成する。試験機は、信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験するように構成される。試験機は、信号伝達解放指示理由フィールドが異常な状態であるかどうかをチェックする。警告生成機は、試験機による試験が信号伝達解放指示理由フィールドが異常な状態を示す場合、警告を選択的に生成するように構成される。
【0110】
一つのインプリメンテーションにおいて、UTRANは、信号伝達接続解放指示を受信すると、上部層から受信された理由を転送し、信号伝達接続の解放をリクエストする。上部層は、信号伝達接続の解放を開始することが可能である。IE信号伝達解放指示理由は、UEの上部層に指示することで、UEのRRCをトリガし、メッセージを送信させるようにする。その理由は、おそらく、異常な上部層手順の結果である。メッセージの理由の区分は、IEを成功裏に受信することで確保される。
【0111】
可能性のあるシナリオには、信号伝達接続解放指示メッセージが成功裏に配信されたことがRLCによって確認される前に、信号伝達無線ベアラRB2上のRLC全体の送信側の再確立が起こるシナリオを含む。このようなことが起こった場合、UEは、例えば、信号伝達無線ベアラRB2上のAM RLCを用いて、アップリンクDCCH上の信号伝達接続解放指示メッセージを再送信する。信号伝達接続解放指示メッセージが成功裏に配信されたことの確認が、RLCによって成功裏に配信される前に、UTRAN手順の性能からのエンターRATの引き継ぎが起こった場合、UEは、新たなRATの間に、信号伝達接続を中断する。
【0112】
再び、図1を参照すると、一部の場合において、アイドルモードにあるよりも、接続モード状態URA_PCHにあることが、より望ましい。例えば、CELL_DCHまたはCELL_FACH接続モード状態に接続する待ち時間が少なくなることを要求される場合、接続モードPCH状態にあることが望ましい。これを達成するには、2つの方法がある。第一は、3GPP仕様を変更して、UEがUTRANに、自身を特定の状態(この場合は、URA_PCH状態128)に移動するように要求することである。
【0113】
代替として、RRC接続マネージャは、RRCの接続が現状どのような状態であるかのような他の要因を考慮に入れ得る。例えば、RRC接続がURA_PCH状態である場合、RRC接続は、自身がアイドルモード110に移動する必要がなく、それゆえ、信号接続解放の手順は、開始されない。
【0114】
図4を参照する。図4Aは、上述のインフラストラクチャの「4つ」の例に従って、現在のUMTSのインプリメンテーションを示す。図4に示すように、時間は横軸に沿う。
【0115】
UEは、RRCアイドル状態110で開始し、送信されるべきローカルデータ、または、UTRANから受領したページに基づいて、RRC接続の確立を始める。
【0116】
図4Aに示されるように、RRC接続設定310は、最初に起こり、RRC状態は、この時間中、接続状態410である。
【0117】
次いで、信号接続設定312、暗号化・保全性設定314、および、無線ベアラ設定316が起こる。RRC状態は、この間、CELL_DCH状態122である。図4Aに示されるように、RRCアイドルから移動する時間と、無線ベアラが設定される時間との比率は、この例において、ほぼ2秒である。
【0118】
次いで、データが交換される。図4Aの例において、これは、約2〜4秒で達成され、ステップ420によって示される。
【0119】
ステップ420において、データが交換された後、必要に応じての断続的なRLC信号PDUを除くと、データは全く交換されない。こうして、無線ベアラは、約10秒後に、低データレートのDCH状態に移動するように、ネットワークによって再構成される。これは、ステップ422および424で示されている。
【0120】
低データレートのDCH状態において、17秒間にわたって何も受信されない。この時点で、ステップ428で、RRC接続は、ネットワークによって解放される。
【0121】
一度、RRC接続が、ステップ428で開始されると、RRC状態は、約40ミリ秒にわたって非接続状態430に入り、その後、UEがRRCアイドル状態110になる。
【0122】
また、図4Aに示されているように、UEの電流消費は、RRCがCELL_DCH状態122にあるときの期間にわたって示される。図示のように、電流消費は、CELL_DCH状態の全期間にわたって、約200〜300ミリアンペアである。非接続およびアイドルの間に、DRXサイクルを1.28秒と仮定すると、約3ミリアンペアが使用される。しかしながら、35秒間の電流消費200〜300ミリアンペアは、バッテリを消耗させる。
【0123】
ここで、図4Bを参照する。図4Bは、上記から同じ例示的なインフラストラクチャ「4つ」を利用しているが、ここでのみ、信号接続解放をインプリメントしている。
【0124】
図4Bに示すように、同じ設定ステップ310、312、314および316が起こり、これには、RRCアイドル状態110とRRC CELL_DCH状態122との間を移動するときと、同じ時間量を要する。
【0125】
さらに、図4Aの例示的なeメール用のRRCデータPDU交換も、また、図4Bで行われ、これに、約2〜4秒を要する。
【0126】
図4Bの例の中のUEは、アプリケーション特有の不活動タイムアウトを有する。図4Bの例におけるこのタイムアウトは2秒であり、ステップ440によって描かれている。RRC接続マネージャが特定の時間量にわたって、不活動があると判断した後、ステップ442で、UEは信号接続設定を解放し、ステップ428で、RRC接続はネットワークによって解放される。
【0127】
図4Bに示すように、ステップ122のCELL_DCHの電流消費は、それでもなお、約200〜300ミリアンペアである。しかしながら、接続時間は、約8秒のみである。当業者には理解されるように、モバイルがセルDCH状態122のままである時間が、かなり短い時間量なので、その結果、常にオンであるUEデバイス上のバッテリ節約は、著しいものとなる。
【0128】
ここで、図5を参照する。図5は、上述で示したインフラストラクチャ「3」と示されるインフラを用いる第二の例である。図4Aおよび図4Bと同様、接続設定は、約2秒を要して起こる。これは、RRC接続設定310、信号接続設定312、暗号化・保全性設定314、および、無線ベアラ316を要する。
【0129】
この設定の間に、UEは、RRCアイドルモード110からCELL_DCH状態122に移動する。この両者の間に、RRC状態接続ステップ410がある。
【0130】
図4Aと同様に、図5Aにおいて、RLCデータPDU交換が起こり、図5Aの例においては、約2〜4秒を要する。
【0131】
インフラストラクチャ3に従うと、RLC信号PDU交換は、データを全く受信しないので、必要に応じての断続的なRLC信号PDUを除き、こうして、ステップ422で、5秒の間、アイドルである。この時点において、無線ベアラは、CELL_DCH状態122からCELL_FACH状態124に移動するために、ネットワークを再構成する。これは、ステップ450で行われる。
【0132】
CELL_FACH状態124において、RLC信号PDU交換は、この場合、30秒である所定の時間量に対し必要とされるような断続的なRLC信号PDUを除くと、全くデータがないことを見出す。この時点において、ステップ428で、RRC接続のネットワークによる解放が実行される。
【0133】
図5Aに示すように、これは、RRC状態をアイドルモード110に移動する。
【0134】
さらに、図5Aに示すように、DCHモードの間の電流消費は、200〜300ミリアンペアの間である。CELL_FACH状態124に移動するとき、電流消費は、約120〜180ミリアンペアに下がる。RRCコネクタが、解放され、RRCがアイドルモード110に移動すると、電力消費は約3ミリアンペアになる。
【0135】
UTRA RRC Connected Mode状態は、CELL_DCH状態122またはCELL_FACH状態124であり、図5Aの例では、約40秒続く。
【0136】
ここで、図5Bを参照する。図5Bは、図5Aと同じインフラストラクチャ「3」を示し、RRC接続設定310、信号接続設定312、暗号化・保全性設定314、および、無線ベアラ設定316を得るために、約2秒の同じ接続時間を有する。さらに、RLCデータPDU交換420は、約2〜4秒を要する。
【0137】
図4Bと同様に、UEアプリケーションは、ステップ440で、特定の不活動タイムアウトを検出する。この検出した時点で、信号接続解放指示手順は、UEによって開始され、その結果、RRC接続は、ステップ448で、ネットワークによって解放される。
【0138】
さらに、図5Bから分かるように、RRCは、アイドルモード110にて始まり、CELL_FACH状態を経ずして、CELL_DCH状態122に移動する。
【0139】
さらに、図5Bから分かるように、RRC段階が、CELL_DCH状態122である時間(図5の例に従うと、約8秒である)における電流消費は、約200〜300ミリアンペアの間である。
【0140】
それゆえ、図4Aおよび図4Bと図5Aおよび図5Bとを比較すると、著しい量の電流消費が、除去されている。こうして、UEのバッテリ寿命が著しく伸びる。当業者には理解されるように、上述は、現行の3GPP仕様の関連において、さらに使用され得る。
【0141】
ここで、図6を参照する。図6は、UMTSネットワークに対するプロトコルスタックを示す。
【0142】
図6に示すように、UMTSは、CS制御プレーン610、PS制御プレーン611、および、PSユーザプレーン630を含む。
【0143】
これら3つのプレーンの中には、非アクセス層(non−access stratum)(NAS)部分614およびアクセス層部分616が存在する。
【0144】
CS制御プレーン610内のNAS部分614は、コール制御(CC)618、追加サービス(supplementary services)(SS)620、および、ショートメッセージサービス(SMS)622を含む。
【0145】
PS制御プレーン611のNAS部分614は、移動管理(MM)およびGPRS移動管理(GMM)626を含む。さらに、PS制御プレーン611のNAS部分614は、SM/RABM624およびGSMS628を含む。
【0146】
CC618は、回路交換サービス向けのコール管理信号を提供する。SM/RABM624のセッション管理部分は、PDPコンテキスト活性化、不活性化および修正を提供する。SM/RABM624は、また、サービスの質交渉にも提供する。
【0147】
SM/RABM624のRBAM部分の主機能は、PDPコンテキストを無線アクセスベアラに接続することである。このように、SM/RABM624は、無線ベアラの設定、修正、および解放を担っている。
【0148】
アクセス層616中のCS制御プレーン610およびPS制御プレーン611は、無線リソース制御(RRC)617の上に座している。
【0149】
PSユーザプレーン630内のNAS部分614は、アプリケーション層638、TCP/UDP層636、および、PDP層634を含む、PDP層634は、例えば、インターネットプロトコル(IP)を含む。
【0150】
PSユーザプレーン630内のアクセス層616は、パケットデータ収束プロトコル(PDCP)632を含む。PDCP632は、UEとRNCとの間で、TCP/IPプロトコルを運搬するのに適切なWCDMAプロトコルを作成するように設計され(図8に見られるように)、オプションとして、IPトラフィックストリームプロトコルヘッダ圧縮・解凍用である。
【0151】
UMTS Radio Link Control(RLC)640およびMedium Access Control(MAC)層650は、UMTS無線インターフェースのデータリンクサブレイヤを形成し、RNCノードおよびUser Equipment上に存在する。
【0152】
層1(L1)UMTS層(物理層660)は、RLC/MAC層640および650の下にある。この層は、通信用の物理層である。
【0153】
以上の記述は、様々な移動体デバイス上でインプリメントされ得るが、一つの移動体デバイスの例が、以下に、図7と関連付けて述べられる。ここで、図7を参照する。
【0154】
UE1100は、少なくとも音声およびデータ通信能力を有する双方向ワイヤレス通信デバイスであることが好ましい。UE1100は、インターネット上の他のコンピュータシステムと通信する能力を有することが好ましい。提供された正確な機能性に依存して、ワイヤレスデバイスは、例えば、データメッセージデバイス、双方向ページャ、ワイヤレスeメールデバイス、データメッセージ能力を備えた携帯電話、ワイヤレスインターネット機器、または、データ通信デバイスであり得る。
【0155】
UE1100が双方向通信可能な場合、UE1100は、受信機1112および送信機1114を含む通信サブシステム1111、ならびに、1つ以上の好ましくは内蔵または内部のアンテナエレメント1116および1118、局部発振器(LO)1113、および、デジタル信号プロセッサ(DSP)1120のような処理モジュールのような関連するコンポーネントを組み込む。通信分野の当業者には明らかなように、通信サブシステムの特定の設計は、そのデバイスが動作することを意図される通信ネットワークに依存する。例えば、UE1100は、GPRSネットワークまたはUMTSネットワーク内で動作するように設計された通信サブシステムを含み得る。
【0156】
ネットワークアクセス必要条件はまた、ネットワーク1119のタイプに依存して変化する。例えば、UMTSおよびGPRSネットワークにおいて、ネットワークアクセスは、UE1100の加入者またはユーザと関連する。例えば、GPRS移動体デバイスは、従って、GPRSネットワークで作動するために、加入者識別モジュール(SIM)カードを要求する。UMTSにおいては、USIMまたはSIMモジュールが要求される。CDMAにおいては、RUIMカードまたはモジュールが要求される。これらは、本明細書においては、UIMインターフェースと称される。有効なUIMインターフェースがなければ、移動体デバイスは完全には機能しない。局所または非ネットワーク通信機能、および例えば緊急通話など法的に要求される機能が(もしあれば)利用し得るが、しかし、移動体デバイス1100は、ネットワーク1100での通信を含む任意の他の機能を実行することはできない。UIMインターフェース1144は通常、ディスケットまたはPCMCIAカードのように、カードが挿入されかつ取り出され得るカードスロットに似ている。UIMカードは、約64Kのメモリを有し得て、かつ多くのキー構成1151、ならびに例えば識別および加入者関連の情報のような他の情報1153を保持し得る。
【0157】
要求されたネットワーク登録または起動手順が完了したときには、UE1100は、ネットワーク1119で通信信号を送受信し得る。通信ネットワーク1119を通して、アンテナ1116によって受信された信号は、受信機1112へ入力され、受信機1112は、例えば信号増幅、周波数下方変換、フィルタリング、チャネル選択などのような普通の受信機機能を、および図7に示される例示的システムでは、アナログデジタル(A/D)変換を実行し得る。受信された信号のA/D変換により、例えば、DSP1120で実行される復調および復号のようなさらに複雑な通信機能が可能になる。同様に、送信される信号は、例えばDSP1120によって、変調およびコード化を含んで、処理されて、かつデジタルアナログ変換、周波数上方変換、フィルタリング、増幅およびアンテナ1118を介しての通信ネットワーク1119での送信のために送信機1114へ入力される。DSP1120は、通信信号を処理するのみならず、受信機および送信機の制御も提供する。例えば、受信機1112および送信機1114において通信信号に適用されるゲインは、DSP1120にインプリメントされた自動ゲイン制御アルゴリズムを通して、適応可能に制御され得る。
【0158】
ネットワーク1119は、サーバ1160および他の要素(図示されず)を含む、複数のシステムとさらに通信し得る。例えば、ネットワーク1119は、さまざまなサービスレベルでさまざまなクライアントに便宜を図るために、企業システムとウェブクライアントシステムとの両方と通信し得る。
【0159】
UE1100は、デバイスの全体的な作動を制御するマイクロプロセッサ1138を含むほうが好ましい。少なくともデータ通信を含む通信機能は、通信サブシステム1111を通じ実行される。マイクロプロセッサ1138はまた、例えば表示デバイス1122、フラッシュメモリ1124、ランダムアクセスメモリ(RAM)1126、補助入力/出力(I/O)サブシステム1128、シリアルポート1130、キーボード1132、スピーカ1134、マイクロフォン1136、近距離通信サブシステム1140および一般的に1142として指定される任意の他のデバイスサブシステムのようなさらなるデバイスサブシステムとも相互作用する。
【0160】
図7に示されるサブシステムの一部は、通信関連の機能を実行する一方、他のサブシステムは、「レジデント」またはオンデバイス(on−device)機能を提供し得る。特に、例えばキーボード1132および表示デバイス1122のような一部のサブシステムは、例えば通信ネットワークで送信するためのテキストメッセージを入力するような通信関連機能と、例えば計算機またはタスクリストのようなデバイスレジデント機能との両方のために使用され得る。
【0161】
マイクロプロセッサ1138によって使用されるオペレーティングシステムソフトウエアは、例えばフラッシュメモリ1124のような永続的な記憶デバイスに格納されることが好ましいが、フラッシュメモリ1124の代わりに、読み出し専用メモリ(ROM)または類似の格納要素(図示されず)であり得る。当業者は、作動システム、特定のデバイスアプリケーションまたはその部分は、例えばRAM1126のような揮発性のメモリに一時的に書き込み得るということを理解する。受信された通信信号はまた、RAM1126にも格納され得る。さらに、一意的な識別子が、好ましくも読み出し専用メモリに格納される。
【0162】
図示されているように、フラッシュメモリ1124は、コンピュータプログラム1158ならびにプログラムデータ格納1150、1152、1154および1156両方に対する異なるエリアに分離され得る。これらの異なる格納タイプは、各プログラムが、それら自身のデータ格納必要条件のために、フラッシュメモリ1124の一部を割り当て得ることを示す。マイクロプロセッサ1138は、そのオペレーティングシステム機能に加えて、移動体デバイスでソフトウエアアプリケーションの実行を可能にすることが好ましい。例えば、少なくともデータおよび音声通信アプリケーションを含む、基本オペレーションを制御する所定のアプリケーションのセットは、製造中にUE1100に通常インストールされる。好ましいソフトウエアアプリケーションは、例えば、しかし限定されず、Eメール、カンレンダーイベント、ボイスメール、アポイントメントおよびタスク項目のような、移動体デバイスのユーザに関連するデータ項目を組織化および管理する能力を有するパーソナルインフォメーションマネジャー(PIM)アプリケーションであり得る。当然、1つ以上のメモリ記憶デバイスが、PIMデータ項目の格納を助長するために、移動体デバイスで利用し得る。そのようなPIMアプリケーションは、無線ネットワーク1119を介して、データ項目を送受信する能力を有することが好ましい。好ましい実施形態において、PIMデータ項目は、格納されまたはホストコンピュータシステムと関連づけられる移動体デバイスユーザの対応するデータ項目と、無線ネットワーク1119を介してシームレスに(seamless)に統合され、同期されおよび更新される。さらなるアプリケーションがまた、ネットワーク1119、補助入力/出力(I/O)サブシステム1128、シリアルポート1130、近距離通信サブシステム1140または任意の他の適切なサブシステム1142を通して、移動体デバイス1100にロードされ得て、かつ、マイクロプロセッサ1138による実行のために、RAM1126にまたは好ましくは不揮発性の記憶デバイス(図示されず)に、ユーザによってインストールされ得る。アプリケーションインストールにおけるそのような柔軟性は、デバイスの機能性を高め、かつ向上したオンデバイス機能、通信関連機能またはその両方を提供し得る。例えば、安全な通信アプリケーションは、電子商取引機能および他のそのような金融取引が、UE1100を使用して実行されることを可能にする。しかしながら、これらのアプリケーションは、上記によると、多くの場合、通信業者によって同意される必要がある。
【0163】
データ通信モードにおいて、例えばテキストメッセージまたはウェブページダウンロードのような受信された信号は、通信サブシステム1111によって処理され、かつマイクロプロセッサ1138に入力され、マイクロプロセッサ1138は、表示デバイス1122へまたはあるいは補助I/Oデバイス1128への入力のために、受信された信号をさらに処理することが好ましい。UE1100のユーザはまた、好ましくは完全な英数字キーボードまたは電話タイプのキーパッドであるキーボード1132を、表示デバイス1122およびおそらく補助I/Oデバイス1128と共に使用して、例えばEメールメッセージのようなデータ項目を構成し得る。そのように構成された項目は、通信サブシステム1111を通して、通信ネットワーク上で送信され得る。
【0164】
音声通信に対して、UE1100の全体的な作動は同様であるが、ただし、受信された信号は、スピーカ1134に出力されることが好ましく、送信のための信号は、マイクロフォン1136によって生成される点は除く。例えば音声メッセージ録音サブシステムのような代替案の音声またはオーディオI/Oサブシステムもまた、UE1100でインプリメントされ得る。音声またはオーディオ信号出力は主にスピーカ1134を通して達成されることが好ましいけれども、表示デバイス1122もまた、例えば発呼者の識別、音声通話の継続時間または他の音声通話関連情報の指示を提供するために使用され得る。
【0165】
図7におけるシリアルポート1130は通常、ユーザのデスクトップコンピュータ(図示されず)との同期が望まれる携帯情報端末(PDA)タイプの移動体デバイスにインプリメントされる。そのようなポート1130は、ユーザが、外部デバイスまたはソフトウエアアプリケーションを通して、好みを設定することを可能にし、かつ無線通信ネットワークを経由する以外にもUE1100に情報またはソフトウエアダウンロードを提供することによって移動体デバイス1100の能力を拡張する。代替案のダウンロード経路は、例えば、安全なデバイス通信を可能にするために、直接的な故に確実で信用のある接続を通して、デバイスに暗号化キーをロードするために使用され得る。
【0166】
あるいは、シリアルポート1130は他の通信のために使用され得、かつユニバーサルシリアルバス(USB)ポートとして含み得る。インターフェースが、シリアルポート1130と関連する。
【0167】
例えば、近距離通信サブシステムのような他の通信サブシステム1140は、UE1100と必ずしも類似のデバイスである必要はない異なるシステムまたはデバイスとの間の通信を提供する、さらなる随意のコンポーネントである。例えば、サブシステム1140は、同様にイネーブル化されたシステムおよびデバイスとの通信を提供するために、赤外線デバイスならびに関連回路およびコンポーネント、またはBluetoothTM通信モジュールを含み得る。
【0168】
ここで図8が参照される。図8は、無線通信ネットワークを通して通信するUE802を含む通信システム800のブロック図である。
【0169】
UE802は、複数のNode B 806のうち1つと無線で通信する。各Node
B 806は、エアーインタフェース処理および一部の無線リソース管理機能に対する責任を負う。Node B 806は、GSM/GPRSネットワークにおけるBase
Transceiver Stationと類似の機能性を提供する。
【0170】
図8の通信システム800において示される無線リンクは、1つ以上の異なるチャネル、一般的には異なる無線周波数(RF)チャネル、および無線ネットワークとUE802との間で使用される関連プロトコルを表す。Uuエアーインタフェース804はUE802とNode B 806との間で使用される。
【0171】
RFチャネルは、一般的に、全体的な帯域幅の制限、およびUE802の制限されたバッテリーパワーのために、節約されるべき必要のある限りあるリソースである。当業者は、実際の実用における無線ネットワークは、所望の全体的なネットワーク利用可能範囲の広がりに依存して何百ものセルを含み得るということを理解するであろう。すべての関連のコンポーネントは複数のスイッチおよびルータ(図示されず)によって接続され得て、複数のネットワークコントローラによって制限され得る。
【0172】
各Node B 806は、無線ネットワークコントローラ(RNC)810と通信する。RNC810は、そのエリアにおける無線リソースの制限に対する責任を負う。1つのRNC810は複数のNode B 806を制御する。
【0173】
UMTSネットワークにおけるRNC810は、GSM/GPRSネットワークにおけるBase Station Controller(BSC)機能と同等の機能を提供する。しかしながら、RNC810は、例えば、MSCおよびSGSNを含まない自律的なハンドオーバ管理を含む、より多くの情報を含む。
【0174】
Node B 806とRNC810との間で使用されるインターフェースはIubインターフェース808である。NBAP(Node Bアプリケーションパート)の信号を送るプロトコルが、3GPP TS25.433 V3.11.0(2002−09)および3GPP TS 25.433 V5.7.0(2004−01)に規定されているように、主に使用される。
【0175】
Universal Terrestrial Radio Access Network(UTRAN)820は、RNC810、Node B 806およびUuエアーインタフェース804を備える。
【0176】
回線交換トラフィックが、Mobile Switching Centre(MSC)830へ回送される。MSC830は、呼び出しを行い、加入者またはPSTN(図示されず)からデータを取り、かつ受けるコンピュータである。
【0177】
RNC810とMSC830との間のトラフィックは、Iu−CSインターフェース828を使用する。Iu−CSインターフェース828は、UTRAN810と中心音声ネットワークとの間で音声トラフィックを(通常)運びかつ信号を送るための回線交換接続である。使用される主な信号プロトコルはRANAP(Radio Access Network Application Part)である。RANAPプロトコルは、(下記により詳細に規定される)MSC830またはSSGN850であり得るCore Network 821とUTRAN820との間でのUMTS信号発信に使用される。RANAPプロトコルは、3GPP TS 25.413 V3.11.1(2002−09)およびTS 25.413 V5.7.0(2004−01)に規定される。
【0178】
ネットワークオペレータに登録されたすべてのUE802に対して、パーマネントデータ(例えばUE102ユーザのプロファイルのような)および一時的なデータ(例えばUE802の現在位置のような)はホームロケーションレジストリ(HLR)838に格納される。UE802への音声通話の場合には、HLR838が、UE802の現在位置を決定するためにクエリされる。MSC830のVisitor Location Register(VLR)836が、位置エリアのグループに対する責任を負い、かつ現在その責任のエリア内にある移動局のデータを格納する。これは、より速いアクセスのために、HLR838からVLR836へ送信されたパーマネント移動局データの部分を含む。しかしながら、MSC830のVLR836はまた、例えば一時的な識別のような局所データを割り当てかつ格納し得る。UE802はまた、HLR838によって、システムアクセスについて認証される。
【0179】
パケットデータは、Service GPRS Support Node (SGSN)850を介して回送される。SGSN850は、RNCとGPRS/UMTSネットワークにおける中心ネットワークとの間の出入り口であり、その地理的サービスエリア内でUEとの相互のデータパケットの引渡しに対する責任を負う。Iu−PSインターフェース848は、RNC810とSGSN850との間で使用され、UTRAN820と中心データネットワークとの間でデータトラフィックを(一般的に)運びかつ信号を送るためのパケット交換接続である。使用される主な信号プロトコルは(上記の)RANAPである。
【0180】
SSGN850は、Gateway GPRS Support Node (GGSN)860と通信する。GGSN860は、UMTS/GPRSネットワークと、例えばインターネットまたは個人のネットワークのような他のネットワークとの間のインターフェースである。GGSN860は、Giインターフェース上で、パブリックデータネットワークPDN870へ接続される。
【0181】
当業者は、無線ネットワークは、図8に明確には示されていないが、おそらく他のネットワークを含む、他のシステムに接続され得るということを理解する。ネットワークは、通常は、たとえ交換される実際のパケットデータがない場合であっても。少なくとも何らかの種類のページングおよびシステム情報を、進行中の基礎に基づいて、送信している。ネットワークは多くの部分から成るものの、これらの部分はすべて共に働いて、無線リンクにおいて特定の挙動を生じる。
【0182】
本明細書に記述された実施形態は、本出願の技術の要素に対応する要素を有する構造、システムまたは方法の例である。ここに記された記載内容に基づいて、当業者は、本出願の技術の要素に類似して対応する代替の要素を有する実施形態を作成し使用することができる。従って本出願の技術の意図された範囲は、本明細書に記述されたとおりの本出願の技術と異ならない他の構造、システムまたは方法を含み、かつ本明細書に記述された通りの本出願の技術と本質的に異ならない他の構造、システムまたは方法をさらに含む。
【符号の説明】
【0183】
110 RRCアイドル状態
120 RRC接続状態
122 CELL_DCH状態、
124 CELL_FACH状態、
126 CELL_PCH状態
128 URA_PCH状態
【技術分野】
【0001】
(出願の分野)
本出願は、ユーザ設備(UE)とユニバーサル陸上無線アクセスネットワーク(UTRAN)との間の無線リソース制御に関し、特に、UMTSネットワーク内の既存の信号伝達接続の解放に関する。
【背景技術】
【0002】
(背景)
ユニバーサル移動電気通信システム(UMTS)は、テキスト、デジタル化された音声、映像、およびマルチメディアを送信する広帯域パケットベースのシステムである。これは、第三世代に対する標準として認知され、広帯域符号分割多重アクセス(W−CDMA)に一般的に基づく。
【0003】
UMTSネットワークにおいて、プロトコルスタックの無線リソース制御(RRC)パーツは、UEとUTRANとの間の無線リソースの割り当て、構成、および解放を担う。このRRCプロトコルは、詳細には、3GGPの仕様書TS 25.331に記載されている。UEが入り得る2つの基本的モードは、「アイドルモード」および「UTRA接続モード」として定義されている。UTRAは、UMTS陸上無線アクセスを略したものである。アイドルモードにおいて、UEが任意のユーザデータを送信したいときはいつでも、あるいはUTRANまたはサービングGPRSサポートノード(SGSN)が、ページングに応答して、それをページングしてプッシュサーバのような外部データネットワークから受信するときはいつでも、UEは、RRC接続をリクエストするように要求される。アイドルモードおよび接続モードの挙動は、3GPPの仕様書のTS 25.304およびTS 25.331に詳細に記載されている。
【0004】
UTRA RRC接続モードにおいて、デバイスは、4つの状態の1つであり得る。これらは、
CELL_DCH:専用チャネルが、データ交換するために、この状態で、アップリンクおよびダウンリンク中のUEに割り当てられる。UEは、3GPP 25.331に概略されたアクションを実行しなくてはならない。
CELL_FACH:この状態において、ユーザ設備には専用チャネルは割り当てられない。その代わりに、共通チャネルが、少量のバースティ(bursty)なデータを交換するために使用される。UEは、3GPP 25.331(3GPP TS 25.304で規定されるセル選択プロセスを含む)に概略されるようなアクションを実行しなくてはならない。
CELL_PCH:UEは、不連続受信(DRX)を使用して、ページングインジケータチャネル(PICH)を介する放送メッセージとページングとをモニタする。アップリンク活動は可能ではない。UEは、3GPP 25.331(3GPP TS 25.304で規定されるようなセル選択プロセスを含む)に概略されるようなアクションを実行しなくてはならない。UEは、セル再選択の後に、CELL UPDATE手順を実行しなくてはならない。
URA_PCH:UEは、不連続受信(DRX)を用い、ページングインディケータチャネル(PICH)を介する放送メッセージおよびページングをモニタする。アップリンク活動は可能ではない。UEは、3GPP 25.331(3GPP TS 25.304で規定されるようなセル選択プロセスを含む)に概略されるようなアクションを実行しなくてはならない。URA UPDATE手順が、UTRAN登録エリア(URA)再選択をのみ介してトリガされる点を除いて、この状態はCELL_PCHに類似する。
【0005】
アイドルモードから接続モードへの移行とこの逆の移行とは、UTRANによって制御される。アイドルモードUEが、RRC接続をリクエストするとき、ネットワークは、UEをCELL_DCHまたはCELL_FACH状態に移動させるかどうかを判断する。UEがRRC接続モードにあるとき、この場合も、RRC接続を解放するときを決定するのは、またネットワークである。ネットワークは、接続を解放する前に、あるいは場合によっては接続を解放する代わりに、UEを一つのRRC状態から別の状態に移動させ得る。状態移行は、UEとネットワークとの間でのデータ活性または不活性によって、典型的にはトリガされる。ネットワークは、所与のアプリケーションに対するデータ交換がいつ完了したかを知り得ないので、ネットワークは、UEへの/からのさらなるデータを期待して、RRC接続をしばらくの間、典型的には保つ。これは、コール設定および引き続く無線ベアラ設定の待ち時間を減らすために、典型的に行われる。RRC接続解放メッセージは、UTRANによって送信され得るのみである。このメッセージは、UEとUTRANとの間の信号リンク接続および全ての無線ベアラを解放する。
【0006】
上記における問題は、UE上のアプリケーションがそのデータ移行を完了し、さらなるデータ交換を一切期待できない場合ですら、そのアプリケーションは、ネットワークがUEを正しい状態に移動させることを、ネットワークを待っていることである。ネットワークは、UE上のアプリケーションが自身のデータ交換を完了した事実に気付いていないことさえあり得る。例えば、UE上のアプリケーションは、それ自身の承認ベースのプロトコルを使用して、UMTSコアネットワークに接続されるそのアプリケーションサーバとデータ交換し得る。例えば、自身に保証された配信をインプリメントするUDP/IPを介してランするアプリケーションである。そのような場合において、UEは、アプリケーションサーバが全てのデータパケットを送信または受信したかどうかを知っており、任意のさらなるデータ交換が生じるかどうかを決定するためにより良い位置にあり、そして、それゆえ、いつパケットサービス(PS)ドメインと関連するRRC接続を終了するかを決定する。UTRANは、いつRRC接続状態が異なる状態に、あるいはアイドルモードへと変化するかを制御するので、また、UTRANがUEと外部サーバとの間におけるデータ伝送の状態に気付いていないという事実により、UEは、要求される状態またはモードよりも、さらに高いデータレートおよび強いバッテリ状態に留まることになり、それによって、バッテリ寿命を使い果たす。このことは、また無線ベアラリソースが不必要に使用中のまま保たれるという事実によって、ネットワークリソースを無駄使いさせる結果となる。
【0007】
上述に対する一つの解決策は、UEがデータトランザクションを終了されたと、UEが認識するときに、UEにUTRANへ信号伝達解放指示(signaling release indication)を送信するようにさせることである。3GPP TS 25.331仕様書の8.1.14.3節に従うと、UTRANは、UEから信号伝達接続解放指示を受信すると、信号伝達接続を解放し得、その結果、UEはアイドルモードに移行する。上述における問題は、信号伝達解放指示が、警告であると考慮され得ることである。ネットワークは、GMMサービスリクエストの失敗、RAUの失敗、あるいはアタッチの失敗が生じたときに、典型的には、信号伝達解放指示を期待するのみである。UEが信号伝達解放をリクエストするときに警告を発することは、ネットワークでの性能モニタおよび警告モニタを非効率なものとする結果になる。
【発明の概要】
【課題を解決するための手段】
【0008】
本発明は、以下の手段を提供する。
【0009】
(項目1)
ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法であって、
a.該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、
b.該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、
c.該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、
d.該信号伝達接続解放指示を該無線ネットワークで受信するステップと、
e.該理由をフィルタリングし、警告を発するかどうかを判断するステップと
を包含する、方法。
【0010】
(項目2)
上記理由は、異常な状態である、項目1に記載の方法。
【0011】
(項目3)
上記異常な状態は、タイマの時間切れである、項目2に記載の方法。
【0012】
(項目4)
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびGMMサービスリクエストタイマからなる群から選択される、項目3に記載の方法。
【0013】
(項目5)
上記理由は、PSデータセッションを終了して、それによってアイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目1に記載の方法。
【0014】
(項目6)
上記フィルタリングするステップは、上記理由が異常な状態であるとき、警告を発する、項目1に記載の方法。
【0015】
(項目7)
上記フィルタリングするステップは、上記理由が上記ユーザ設備によるアイドル移行リクエストであるとき、上記信号伝達接続解放指示を無視する、項目1に記載の方法。
【0016】
(項目8)
信号伝達解放指示理由を処理するのに適合したシステムであって、該システムは、
a.ユーザ設備であって、該ユーザ設備は、ネットワークと通信するのに適合した無線を含む無線サブシステムと;デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと;メモリと;ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有する、ユーザ設備であって、
i.信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、
ii.該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付する手段と、
iii.該添付信号伝達接続解放指示を該無線ネットワークに送信する手段と
を有することによって特徴付けられる、ユーザ設備と、
b.該ユーザ設備と通信するのに適合した無線ネットワークであって、
i.該信号伝達接続解放指示を受信する手段と、
ii.該理由をフィルタリングし、警告を発するかどうかを判断する手段と
によってさらに特徴付けられる、無線ネットワークと
を備える、システム。
【0017】
(項目9)
上記理由は、異常な状態である、項目8に記載のシステム。
【0018】
(項目10)
上記異常な状態は、タイマの時間切れである、項目9に記載のシステム。
【0019】
(項目11)
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびGMMサービスリクエストタイマからなる群から選択される、項目10に記載のシステム。
【0020】
(項目12)
上記理由は、PSデータセッションを終了し、アイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目11に記載のシステム。
【0021】
(項目13)
上記フィルタリングする手段は、上記理由が異常な状態であるとき、警告を発するのに適合する、項目8に記載のシステム。
【0022】
(項目14)
上記フィルタリングする手段は、上記理由が上記ユーザ設備によるアイドル移行リクエストであるとき、上記信号伝達接続解放指示を無視するのに適合する、項目8に記載のシステム。
【0023】
(項目15)
無線ネットワークで改善された警告を追跡するために、ユーザ設備で信号伝達解放指示理由を処理する方法であって、
a.信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、
b.該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、
c.該理由が添付された該添付信号伝達接続解放指示を送信し、これによって、該信号伝達接続解放指示の該理由を識別する該信号伝達接続解放をリクエストする、ステップと
を包含する、方法。
【0024】
(項目16)
上記理由は、異常な状態である、項目15に記載の方法。
【0025】
(項目17)
上記異常な状態は、タイマの時間切れである、項目16に記載の方法。
【0026】
(項目18)
上記タイマは、アタッチ失敗タイマ、ルーティングエリア更新タイマ、およびGMMサービスリクエストタイマからなる群から選択される、項目17に記載の方法。
【0027】
(項目19)
上記理由は、PSデータセッションを終了し、アイドルモードへ移行するようにという上記ユーザ設備によるリクエストである、項目15に記載の方法。
【0028】
(項目20)
ネットワーク内で、信号伝達解放指示理由を提供するのに適合したユーザ設備であって、該ユーザ設備は、該ネットワークと通信するのに適合した無線を含む無線サブシステムと;デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと;メモリと;ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有し、該ユーザ設備は、
a.信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、
b.該信号伝達接続解放指示に、該信号伝達接続解放指示に対する理由を添付する手段と、
c.該理由を含む該添付信号伝達接続解放指示を送信し、これによって、該信号伝達接続解放指示の該理由を該信号伝達接続解放指示とともに識別する手段と
を有することによって特徴付けられる、ユーザ設備。
【0029】
(項目21)
信号伝達接続の解放を容易にするためのユーザ設備用装置であって、該装置は、
a.信号伝達接続解放指示が、送信されるべきかどうかをチェックするように構成されたチェッカと、
b.信号伝達接続解放指示が送信されるべきであるという該チェッカによる指示に応答して、該信号伝達接続解放指示を送信するように構成された信号伝達接続解放指示センダであって、該信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む信号伝達解放指示を含む、信号伝達接続解放指示センダと
を備える、装置。
【0030】
(項目22)
上記チェッカは、上記信号伝達接続解放指示を送信するのに引き続き、該信号伝達接続解放指示の配信を確認する前に、上記ユーザ設備の信号伝達接続が必要とされるかどうかをチェックするようにさらに構成される、項目21に記載の装置。
【0031】
(項目23)
上記信号伝達接続解放指示センダは、上記信号伝達接続解放指示を再送信するようにさらに構成される、項目22に記載の装置。
【0032】
(項目24)
信号伝達接続解放指示によって、動作するネットワーク装置であって、該ネットワーク装置は、
a.該信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験して、該信号伝達解放指示理由フィールドが異常な状態を指示するかどうかをチェックするように構成された試験機と、
b.該試験機による試験が、該信号伝達解放指示理由フィールドが該異常な状態を指示すると判断する場合、警告を選択的に生成するように構成された警告生成器と
を備える、ネットワーク装置。
【0033】
(項目25)
上記ネットワーク装置は、複数のロジカル層を備え、上記試験機は、該複数のロジカル層の第一のロジカル層で具現化され、該試験機は、該複数のロジカル層の第二のロジカル層に、信号伝達接続解放をリクエストするようにさらに構成される、項目24に記載のネットワーク装置。
【0034】
(摘要)
ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法およびシステムであって、該方法は、該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、該信号伝達接続解放指示を該無線ネットワークで受信するステップと、該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する、方法。
【0035】
(詳細な説明)
本システムおよび方法は、RRC接続モードから、より効率的なバッテリ状態またはモードへ移行させる一方で、信号伝達解放指示の理由がUEのアイドル移行リクエストである場合、ネットワークが、信号伝達解放指示を警告と考慮しないこと保証することを提供する。特に、本方法および装置は、特定されたコアネットワークドメインに対する信号接続の終了をUEが開始すること、または、移行が一つの接続状態から他の接続状態へと生じるべきであるとUTRANに指示することのいずれかに基づいて移行を提供する。以下の説明は、UMTSの例示的なインプリメンテーションに関して記載される。しかしながら、本発明の教示は、他の無線通信システムにも同様に適用可能であることは、理解されるべきである。
【0036】
特に、UE上のアプリケーションは、それがデータの交換を用いてなされたと決定する場合、好適には、それは「なされた」との指示を、UEソフトウェアの「RRC接続マネージャ」コンポーネントへ送信する。RRC接続マネージャは、関連パケットデータプロトコル(PDP)コンテキスト、関連パケット交換(PS)無線ベアラ、および関連回路交換(CS)無線ベアラなどの全ての現行のアプリケーション(一つまたは複数のプロトコルを介したサービスを提供するものを含む)を追跡し続ける。PDPコンテキストは、UMTSコアネットワークにわたってランするUEとPDN(公衆データネットワーク)との間の論理関係である。UE上の一つまたは複数のアプリケーション(例えば、eメールアプリケーションおよびブラウザアプリケーション)は、一つのPDPコンテキストと関連し得る。一部の場合において、UE上の一つのアプリケーションは、一次PDPコンテキストと関連し、複数のアプリケーションは、二次PDPコンテキストに結合され得る。RRC接続マネージャは、同時に活性であるUE上の異なるアプリケーションから、「なされた」との指示を受信する。例えば、ユーザは、ウェブを閲覧している間に、プッシュサーバからeメールを受信し得る。eメールアプリケーションが承認を送信した後、それは、そのデータトランザクションを完了したことを指示し得るが、しかしながら、ブラウザアプリケーションは、そのような指示を送信し得ない。活性なアプリケーションからのそのような指示の合成状態に基づいて、UEソフトウェアは、それが、コアネットワークパケットサービスドメインの信号伝達接続解放を開始し得る前に、どの程度待機するべきかを決定し得る。この場合における遅延は、そのアプリケーションがデータ交換を真に終了させ、RRC接続を要求しないことを保証するために導入され得る。その遅延は、トラフィック履歴および/またはアプリケーションプロフィールに基づいてダイナミックであり得る。どのアプリケーションも一切データを交換することが期待されないという可能性が幾分かあると、RRC接続マネージャが判断するときはいつも、RRC接続マネージャは適切なドメイン(例えば、PSドメイン)に対して、信号伝達接続解放指示手順を送信し得る。あるいは、UTRANに接続されたモード内において、状態移行のリクエストを送信し得る。
【0037】
上述の判断はまた、ネットワークが、URA_PCH状態およびこの状態への移行挙動をサポートするかどうかを考慮し得る。
【0038】
UEによって開始されたアイドルモードへの移行は、RRC接続モードの任意の状態から生じ得、ネットワークをRRC接続から解放させ、UEをアイドルモードへと移動させることによって終わる。当業者によって理解されるように、アイドルモード中のUEは、接続状態中のUEよりも、バッテリがはるかに低い。
【0039】
しかしながら、信号伝達接続解放指示の送信は、ネットワークに、結果として、警告が起こったことを考慮させ得る。信号伝達解放指示が、トラフィックが一切期待されないというRRCによる判断の結果の場合、好ましい実施形態において、ネットワークは、信号伝達解放指示が、異常な状態であるのではなく、リクエストされたアイドル移行の結果であることを区別し得る。この区別によって、キー性能インディケータ(KPI)のようなインディケータがより正確になり、性能のモニタと警告のモニタとを改善することができる。
【0040】
本方法は、UEが、既存の信号伝達解放指示に、信号伝達解放指示の理由を提供するフィールドを添付することを可能にする。ネットワークは、次いで、添付されたフィールドを用いて、真の警告状態をUEがアイドル状態に置かせるようにリクエストした状況からフィルタリングし得る。なぜなら、このリクエストした状況は、さらなるデータが一切期待できないからである。これは、警告および性能のモニタの効率を改善し、その一方で、UEをより迅速にアイドルモードに移動させて、そのバッテリリソースを節約することを可能にする。
【0041】
本出願は、それゆえ、ユーザ設備と無線ネットワークとの間で信号伝達解放指示理由を処理する方法を提供し、該方法は、該ユーザ設備で、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該ユーザ設備で、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップと、該信号伝達接続解放指示を該無線ネットワークで受信するステップと、該理由をフィルタリングし、警告を発するかどうかを判断するステップとを包含する。
【0042】
本出願は、さらに、信号伝達解放指示理由を処理するのに適合したシステムをさらに提供し、該システムは、ユーザ設備であって、該ユーザ設備は、UMTSネットワークと通信するのに適合した無線を含む無線サブシステムと;デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと;メモリと;ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有する、ユーザ設備であって、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付する手段と、該添付信号伝達接続解放指示を該無線ネットワークに送信する手段とを有することによって特徴付けられる、ユーザ設備と、該ユーザ設備と通信するのに適合した無線ネットワークであって、該信号伝達接続解放指示を受信する手段と、該理由をフィルタリングし、警告を発するかどうかを判断する手段とによってさらに特徴付けられる、無線ネットワークとを備える。
【0043】
本出願は、またさらに、無線ネットワークで改善された警告を追跡するために、ユーザ設備で信号伝達解放指示理由を処理する方法を提供し、該方法は、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタするステップと、該信号伝達接続解放指示に該信号伝達接続解放指示に対する理由を添付するステップと、該添付信号伝達接続解放指示を該無線ネットワークに送信するステップであって、該無線ネットワークは、該信号伝達接続解放指示の該理由の指示を提供する、ステップとを包含する。
【0044】
本出願は、またさらに、信号伝達接続の解放を容易にするユーザ設備用装置を提供する。チェッカは、信号伝達接続解放指示が、送信されるべきかどうかをチェックするように構成される。信号伝達接続解放指示センダは、信号伝達接続解放指示が送信されるべきであるという該チェッカによる指示に応答して、該信号伝達接続解放指示を送信するように構成される。該信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む。
【0045】
本出願は、またさらに、信号伝達接続解放指示によって、動作するネットワーク装置を提供する。試験機は、該信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験するように構成される。該試験機は、該信号伝達解放指示理由フィールドが異常な状態を指示するかどうかをチェックする。警告生成機は、該試験機による試験が、該信号伝達解放指示理由フィールドが該異常な状態を指示すると判断する場合、警告を選択的に生成するように構成される。
【0046】
本出願は、またさらに、UMTSネットワーク内で、信号伝達解放指示理由を提供するのに適合したユーザ設備を提供し、該ユーザ設備は、該UMTSネットワークと通信するのに適合した無線を含む無線サブシステムと;デジタル信号プロセッサを有し、該無線サブシステムと相互作用するのに適合した無線プロセッサと;メモリと;ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、ユーザインターフェースと;ユーザアプリケーションをランさせて、該メモリ、該無線、および該ユーザインターフェースと相互作用するのに適合し、アプリケーションをランさせるのに適合したプロセッサとを有し、該ユーザ設備は、信号伝達接続解放指示が、該無線ネットワークに送信されるべきかどうかをモニタする手段と、該信号伝達接続解放指示に、該信号伝達接続解放指示に対する理由を添付する手段と、該理由を含む該添付信号伝達接続解放指示を送信する手段であって、該無線ネットワークは、該信号伝達接続解放指示の該理由の指示を提供する、手段とを有することによって特徴付けられる。
【図面の簡単な説明】
【0047】
本出願は、図面を参照することで、よりよく理解される。
【図1】図1は、RRC状態および移行を示すブロック図である。
【図2】図2は、様々なUMTSセルおよびURAを示すUMTSネットワークの模式図である。
【図3】図3は、RRC接続設定の様々な段階を示すブロック図である。
【図4A】図4Aは、CELL_DCH接続モード状態と、現行方法に従うUTRANによって起動されるとアイドルモードとの間の例示的な移行のブロック図である。
【図4B】図4Bは、信号伝達解放指示を利用して、CELL_DCH状態接続モードからアイドルモードへの移行との間の例示的な移行を示すブロック図である。
【図5A】UTRANによって開始された、CELL_DCH不活動からCELL_FACH不活動へ、およびアイドルモードへの例示的な移行のブロック図である。
【図5B】図5Bは、信号伝達解放指示を利用して、CELL_DCH不活性とアイドルモードとの間の例示的な移行のブロック図である。
【図6】図6は、UMTSプロトコルスタックのブロック図である。
【図7】図7は、本方法と関連して用いられる例示的なUEである。
【図8】図8は、本方法と関連して用いられる例示的なネットワークである。
【図9】図9は、UEで、信号伝達接続解放指示に対する理由を追加するステップを示す流れ図である。
【図10】図10は、理由を有する信号伝達接続解放指示を受信した後に、UEによって取られるステップを示す流れ図である。
【発明を実施するための形態】
【0048】
ここで、図1を参照する。図1は、UMTSネットワークにおけるプロトコルスタックの無線リソース制御部分に対する様々なモードおよび状態を示すブロック図である。特に、RRCは、RRCアイドル状態110またはRRC接続状態120のいずれかであり得る。
【0049】
当業者には理解されるように、UMTSネットワークは、2つの陸上ベースのネットワークセグメントからなる。これらは、コアネットワーク(CN)および(図8に示されるような)ユニバーサル陸上無線アクセスネットワーク(UTRAN)である。コアネットワークは、外部ネットワークへのデータコールおよびデータ接続の交換およびルーティングを担い、UTRANは、全ての無線関連機能性を扱う。
【0050】
アイドルモード110において、UEとネットワークとの間でデータが交換される必要があるときはいつも、UEはRRC接続をリクエストし、無線リソースを設定しなくてはならない。これは、UEが接続を要求してデータを送信するアプリケーションの結果として、あるいはUEが、UTRANまたはSGSNがUEをページングしたかどうかを指示するページングチャネルをモニタして、プッシュサーバのような外部データネットワークからデータを受信する結果としてのいずれかであり得る。さらに、UEは、また、ロケーションエリア更新のような信号伝達メッセージを移動管理(Mobility Management)に送信する必要があるときは、いつでもRRC接続をリクエストする。
【0051】
一度、UEがUTRANにリクエストを送信すると、無線接続が確立し、UTRANは、RRC接続が中に入るようにするために状態を選択する。特に、RRC接続モード120は、4つの個別状態を含む。これらは、CELL_DCH状態122、CELL_FACH状態124、CELL_PCH状態126、およびURA_PCH状態128である。
【0052】
アイドルモード110から、RRC接続状態は、セル専用チャネル(CELL_DCH)状態122またはセル転送アクセスチャネル(CELL_FACH)状態124のいずれかに進み得る。
【0053】
CELL_DCH状態122において、専用チャネルが、アップリンクとダウンリンクとの双方のためにUEに割り当てられ、データ交換する。この状態は、UEに割り当てられた専用物理的チャネルを有するので、UEから最も多くのバッテリ電力を典型的に要求する。
【0054】
代替として、UTRANは、アイドルモード110からCELL_FACH状態124に移動し得る。CELL_FACH状態において、専用チャネルはUEに割り当てられない。その代わりに、共通チャネルが、信号伝達を少量のバースティなデータで送信するために使用される。しかしながら、UEは、相変わらずFACHを連続的にモニタしなくてはならない。それゆえ、バッテリ電力を消費する。
【0055】
RRC接続モード120内において、RRC状態は、UTRANの行動(discretion)を変更し得る。特に、データ不活性が特定の時間の間に検出された場合、あるいは所定の閾値未満のスループットが検出された場合、UTRANは、RRC状態をCELL_DCH状態122から、CELL_FACH状態124、CELL_PCH状態126、またはURA_PCH状態128に、移動させ得る。同様に、ペイロードが所定の閾値を超えることが検出される場合、RRC状態は、CELL_FACH124からCELL_DCH122に移動し得る。
【0056】
CELL_FACH状態124から、データ不活性が一部のネットワークにおいて、所定の時間にわたって検出された場合、UTRANは、RRC状態をCELL_FACH状態124からページングチャネル(PCH)状態に移動させ得る。これは、CELL_PCH 状態126またはURA_PCH状態128のいずれかであり得る。
【0057】
CELL_PCH状態126またはURA_PCH状態128から、UEは、専用チャネルをリクエストする更新手順を開始するために、CELL_FACH状態124に移動されなくてはならない。これは、UEが制御する唯一の状態移行である。
【0058】
CELL_PCH状態126およびURA_PCH状態128は、不連続受信サイクル(DRX)を使用し、包装メッセージおよびページングインディケータチャネル(PICH)によるページングをモニタする。アップリンク活動は、一切不可能である。
【0059】
CELL_PCH状態126とURA_PCH状態128との間の差は、URA_PCH状態が、現在のセルの中に存在するURAアイデンティティのリストの中にUEの現在のUTRAN登録エリア(URA)がない場合、URA更新手順をトリガすることのみである。具体的には、図2を参照する。図2は、様々なUMTSセル210、212、および214の図を示す。これらのセルの全ては、CELL_PCH状態が再選択された場合、セル更新手順を要求する。しかしながら、UTRAN登録エリアにおいて、各セルは、同じUTRAN登録エリア220内にあり、したがって、URA更新手順は、URA_PCHモードのときに、210、212、および214の間で移動するとき、トリガされない。
【0060】
図2に示されるように、他のセル218は、URA220の外側にアップリンク、別個のURAの一部となり得るか、あるいはURAになり得ない。
【0061】
当業者には理解されるように、バッテリ寿命見通しから、アイドル状態は、上述の状態と比べて、最も少ないバッテリ使用法を提供する。具体的に、UEは、ページングチャネルをインターバルだけにおいて、モニタすることを要求されるので、無線は、連続的にオンである必要はないが、その代わりに、定期的に目覚める必要がある。これに対するトレードオフは、データを送信する待ち時間である。しかしながら、この待ち時間は、さほど長くもない場合、アイドルモードであってバッテリ電力を節約することのメリットは、接続の待ち時間のデメリットを上回る。
【0062】
再び、図1を参照する。様々なUMTSインフラベンダは、様々な基準に基づいて、122、124、126、および128の状態間を移動する。例示的なインフラは、以下に概略される。
【0063】
第一の例示的なインフラにおいて、RRCは、アイドルモードとCell_DCH状態との間を直接移動する。Cell_DCH状態において、2秒間活性でないことが検出されると、RRC状態は、Cell_FACH状態124に変化する。Cell_FACH状態124において、10秒間活性でないことが検出されたら、RRC状態は、PCH状態126に変化する。Cell_PCH状態126において、45分間活性でないことが検出されたら、その結果、RRC状態は、アイドル状態110に戻る。
【0064】
第二の例示的なインフラにおいて、RRC移行は、ペイロード閾値に依存して、アイドルモード110と接続モード120との間で発生し得る。第二のインフラにおいて、ペイロードが、所定の閾値未満であれば、UTRANは、RRC状態からCELL_FACH状態124に移動する。逆に、データが所定のペイロードを上回る場合、UTRANは、RR状態をCELL_DCH状態122に移行する。第二のインフラで、CELL_DCH状態122において、2分間活性でないことが検出されると、UTRANは、RRCをCELL_FACH状態124に移動する。CELL_FACH状態124において、5分間活性でないことが検出されると、UTRANは、RRC段階をCELL_PCH状態126に移動する。CELL_PCH状態126において、アイドルモード110に戻る前に、2時間の不活動が要求される。
【0065】
第三の例示的なインフラにおいて、アイドルモードと接続モード120との間の移動は、常に、CELL_DCH状態122である。CELL_DCH状態122において、5秒間活性でなかった後に、UTRANは、RRC状態をCELL_FACH状態124に移動する。CELL_FACH状態124において、30秒間活性でないと、その結果、アイドル状態110に移動して戻る。
【0066】
第四の例示的なインフラにおいて、RRCは、アイドルモードから接続モードに直接移行し、CELL_DCH状態122になる。第四の例示的なインフラにおいて、CELL_DCH状態122は、2つのサブ状態を含む。第一は、高いデータレートを有するサブ状態であり、第二のサブ状態は、より低いデータレートを含むが、それでもなおCELL_DCH状態の範囲内である。第四の例示的なインフラにおいて、RRCは、アイドルモード110から、高いデータレートのCELL_DCHサブ状態へと直接移行する。10秒間活性でない後、RRC状態は、低いCELL_DCH状態に移行する。低データのCELL_DCH状態122から17秒間活性でないと、その結果、RRC状態は、アイドルモード110に変化する。
【0067】
上述の4つの例示的なインフラは、様々なUMTSのインフラベンダが、状態をインプリメントしているかを示す。当業者には理解されるように、各場合において、実際のデータ交換(例えば、eメール)に要した時間は、CELL_DCHまたはCELL_FACH状態に留まっていることを要求される時間に比べ、かなり短い。このため、不必要なカレントドレインが生じ、その結果、ユーザは、UMTSのような新たな世代のネットワークにおいて、GPRSのような以前の世代のネットワークよりも、悪化するのを体験する。
【0068】
さらに、CELL_PCH状態は、CELL_FACH状態よりも最適であるが、バッテリ寿命の観点から、CELL_PCH状態におけるDRXサイクルは、典型的には、アイドルモード110より低い値に設定される。その結果、UEは、アイドルモードよりも、CELL_PCH状態で、より頻繁に目覚めていることが要求される。
【0069】
アイドル状態のサイクルと同様のDRXサイクルを有するURA_PCH状態は、バッテリ寿命と接続における待ち時間との最適なトレードアップのように思われる。しかしながら、URA_PCHは、現在、UTRANでサポートされていない。それゆえ、バッテリ寿命の観点から、アプリケーションがデータ交換で終了したら、できるだけ迅速に、アイドルモードに移行することが望ましい。
【0070】
ここで、図3を参照する。アイドルモードから接続モードへ移行するとき、様々な信号伝達およびデータ接続が、生成される必要がある。図3を参照すると、実行されるべき必要のある第一のアイテムは、RRC接続設定である。上述のように、このRRC接続設定は、UTRANによってのみ、解体され得る。
【0071】
一度、RRC接続設定310が達成されると、信号接続設定312が開始される。
【0072】
一度、信号設定312が終了すると、暗号化・保全性設定(ciphering and integrity setup)314が開始される。これが完了すると、無線ベアラ設定316が達成される。この時点で、データは、UEとUTRANとの間で交換され得る。
【0073】
接続解体は、一般的に、この逆順で同様に達成される。無線ベアラ設定316は、解体され、次いで、RRC接続設定310が取り払われる。この時点で、RRCは、図1に示すように、アイドルモード110へと移動する。
【0074】
現在の3GPP仕様によれば、UEが、RRC接続を解放すること、または、RRC状態にとってその好みを指示することはできないが、それでも、UEは、特定のコアネットワークドメイン(例えば、パケット交換アプリケーションで使用されるPacket Switched(PS))に対する信号伝達接続の終了を指示し得る。3GPP TS 25.331の8.1.14.1節に従うと、信号伝達接続解放指示手順は、UEによって使用され、UTRANに、その信号伝達接続の一つが解放されたことを指示する。この手順は、順に、RRC接続解放手順を開始し得る。
【0075】
このように、現行の3GGP仕様の範囲に留まると、信号伝達接続解放は、信号接続設定312の解体によって、開始され得る。信号伝達接続設定312を解体する(tear
down)ことは、UEの能力の範囲内であり、次いで、仕様に従えば、このことは、RRC接続解放を開始し「得る」。
【0076】
当業者には理解されるように、信号伝達接続設定312が、解体される場合、UTRANは、また、解読・保全性設定312を一掃し、信号接続設定312が解体された後に、無線ベアラ設定316を一掃する必要がある。
【0077】
信号伝達接続設定312が、解体される場合、RRC接続設定は、典型的には、現在のベンダのインフラに対するネットワークによって停止される。
【0078】
上述を用いて、データ交換とともに行われるとUEが決定する場合、例えば、UEソフトウェアの「RRC接続マネージャ」コンポーネントが、データ交換が完了したという指示を提供された場合、RRC接続マネージャは、信号伝達接続設定312を解体するかどうかを判断し得る。例えば、デバイス上でのeメールアプリケーションは、eメールが本当にプッシュサーバによって受信されたという、プッシュeメールサーバからの通知を受信したという指示を送信する。RRCマネージャは、関連PDPコンテキスト、関連PS無線ベアラおよび関連回路交換(CS)無線ベアラの全ての現行のアプリケーションを追跡し得る。この場合の遅延は、データ交換でもって、そのアプリケーションが本当に終了し、もはや、「完了」指示を送信した後もRRC接続をもはや必要としない。この遅延は、このアプリケーションと関連する非活性なタイムアウトと同等である。各アプリケーションは、それ自身の非活性なタイムアウトを有し得る。例えば、eメールアプリケーションは、5秒の非活性なタイムアウトを有し得るが、活性なブラウザアプリケーションは、60秒の非活性なタイムアウトを有し得る。活性なアプリケーションからの全てのこのような指示の復号ステータスに基づいて、UEソフトウェアは、UEソフトウェアが、適切なコアネットワーク(例えば、PSドメイン)の信号伝達接続解放を開始し得るまでに、どのくらい待つべきであるかを判断する。
【0079】
非活性なタイムアウトは、トラフィックパターン履歴および/またはアプリケーションプロファイルに基づいて、ダイナミックベースでなされ得る。
【0080】
RRC接続マネージャが、どのアプリケーションもデータ交換を期待されないとある程度の確率で判断するときはいつも、RCC接続マネージャは、適切なドメインに対する信号伝達接続解放指示手順を送信し得る。
【0081】
上述のUEで開始されたアイドルモードへの移行は、図1に示すようなRRC接続モード120の任意の段階で起こり得て、また、RRC接続ネットワークから解放させ、図1に示すようなアイドルモード110に移動させて終了する。これは、また、音声コール中に、UEが任意のパケットデータサービスを実行しているときにも、適用可能である。この場合、PSドメインのみが解放されるが、CSドメインは接続されたままである。
【0082】
上述のネットワークの考え方における問題は、UEによって送信された信号伝達接続解放指示が、警告として解釈されることである。信号伝達ネットワーク解放が、適用タイマ時間切れのためにより、UEによって明確なアクションの結果であり、それゆえ、さらなるデータが期待されない場合、上記の指示によって生じた警告は、性能および警告指示をスキューする。キー性能インディケータは、これによって変更され得、効率の損失へと導く。
【0083】
好ましくは、理由が、UTRANに指示に対する理由を指示する信号伝達接続解放指示に追加されるべきである。好ましい実施形態において、その理由は、異常な状態が指示の理由となったという指示か、あるいはリクエストされたアイドル移行の結果として、UEによって開始されたという指示であり得る。他の正常(すなわち、異常でない)トランザクションは、結果として、信号伝達接続解放指示の送信であり得る。
【0084】
さらなる好ましい実施形態において、様々なタイムアウトは、異常な状態に対する信号伝達接続指示の理由となり得る。以下のタイマの例は、網羅的なものでなく、他のタイマ、あるいは他の条件も可能である。例えば、3GPP.TS 24.008の10.2.47は、タイマT3310として、以下を特定する。
【0085】
【表1】
このタイマは、アタッチ失敗を指示するために使用される。アタッチ失敗は、ネットワークの結果であり得るか、あるいは衝突または不良無線周波数(RF)のようなRF問題であり得る。
【0086】
添付の試みは、複数回起こり得、アタッチ失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【0087】
3GPPの10.2.47の第二のタイマは、T3330であり、以下のように特定される。
【0088】
【表2】
このタイマは、ルーティングエリア更新失敗を指示するために使用される。タイマが時間切れになると、さらなるルーティングエリア更新が、複数回リクエストされ得て、ルーティングエリア更新失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【0089】
3GPPの10.2.47の第三のタイマは、T3340であり、以下のように特定される。
【0090】
【表3】
このタイマは、GMMサービスリクエスト失敗を指示するために使用される。タイマが時間切れになると、さらなるGMMサービスリクエストが、複数回開始され得、GMMサービスリクエスト失敗は、所定回数の失敗または明確な拒絶のいずれかの結果である。
【0091】
このように、信号伝達解放指示は、異常な状態およびUEによる解放に限られる代わりに、信号伝達解放指示は、さらに、異常な状態に対してどのタイマが失敗したかに関する情報を含み得る。信号伝達接続解放指示は、以下のように構造化され得る。
【0092】
【表4】
このメッセージは、UEによって使用され、UTRANに既存の信号伝達接続を解放するように指示する。信号伝達解放指示を追加すると、UTRANまたは他のネットワークエレメントは、信号伝達解放指示の理由、つまり異常な状態によるものであったのか、あるいは異常な状態とは何であったかを受信することができる。そして、RRC接続解放手順が、次いで、開始されることが可能になる。
【0093】
一つのインプリメンテーションにおいて、UEは、解放または中断するようにというリクエストを受信すると、特定のCN(コアネットワーク)ドメインに対する上部層からの信号伝達接続は、IE(情報エレメント)「CNドメインアイデンティティ」で識別される特定のCNドメインに対する変数(例えば、変数ESTABLISHED_SIGNALING_CONNECTIONS)で識別されるような信号伝達接続が存在する場合、信号伝達接続解放指示を開始する。変数が、既存の信号伝達接続を一切識別しない場合、その特定のCNドメインに対する信号伝達接続の進行中の確立は、いずれも別の方法で中断される。そして、CELL_PCHまたはURA_PCH状態で、信号伝達接続解放指示手順が開始すると、UEは、「アップリンクデータ送信」理由を用いて、セル更新手順を実行する。そして、セル更新手順が成功裏に完了したとき、UEは、その後の信号伝達接続解放指示手順を続ける。
【0094】
すなわち、UEは、IE「CNドメインアイデンティティ」を上部ロジカル層によって指示された値に設定する。IEの値は、CNドメインを指示し、その関連信号伝達接続は、上部層が解放されるべきことを指示する関連信号伝達接続である。CNドメインアイデンティティが、PSドメインに設定される場合で、上部層は、このリクエストを開始する理由を指示する場合、IE「信号伝達解放指示理由」は、これに従って設定される。UEは、変数「established_signaling_connections」から上部層によって指示されたアイデンティティを有する信号伝達接続をさらに除去する。そして、UEは、信号伝達接続解放指示メッセージを、例えば、AM RLCを用いて、DCCH上で送信する。RLCによって解放指示メッセージの配信が成功したことを確認すると、この手順は終了する。
【0095】
IE「Signaling Release Indication Cause」も、また本開示の実施形態に関して用いられる。解放理由は、例えば、既存のメッセージ定義で、アラインされる。上部層解放理由メッセージも例えば、以下のように構造化される。
【0096】
【表5】
この例において、T3310、T3330、およびT3340は、上記で識別された対応するように番号付けされたタイマの時間切れに相当する。理由値は、一つの実施形態において、状態移行によって判断するUTRANに提供する「UE Requested idle transition」よりも、むしろ「UE Requested PS Data session end」として、設定可能である。しかしながら、期待される結果は、理由値によって識別される結果に対応する。信号伝達接続解放指示への拡張(extension)は、好ましいが、必ずしも必要ではなく、クリティカルでない拡張である。
【0097】
ここで、図9を参照する。図9は、様々なドメイン(例えば、PSまたはCS)に対する信号伝達接続解放指示を送信するかしないかを例示的にUEをモニタする流れ図である。プロセス910は、ステップ910で開始する。
【0098】
UEは、ステップ912へ移行し、ここで、異常な状態が存在するかどうかを見るためにチェックする。このような異常な状態には、例えば、上述したような、タイマT3310、タイマT3320、またはタイマT3340の時間切れを含み得る。これらのタイマが、ある所定の回数、時間切れとなった場合、あるいはこれらのタイマのいずれかの時間切れに基づいて、明確な拒絶を受信する場合、UEは、ステップ914に進み、ここで、信号伝達接続解放指示を送信する。信号伝達接続解放指示メッセージは、信号伝達解放指示理由フィールドを用いて添付される。信号伝達解放指示理由フィールドは、信号伝達接続解放指示が異常な状態(conditionまたはstate)に基づくことを少なくとも含み、好ましい実施形態は、異常な状態の結果としてタイムアウトする特定のタイマを含む。
【0099】
逆に、ステップ912で、UEが異常な状態が存在しないことを見出す場合、UEは、ステップ920に進み、ここで、さらなるデータがUEで期待されるかどうかをチェックする。これは、上述のように、eメールが送信され、そのeメールの送信確認がUEに返信されたときを含む。UEがさらなるデータがもはや期待されないかどうかを判断する他の例は、当業者には周知である。
【0100】
ステップ920で、データ伝達が終了した(あるいは、回路交換の場合、ドメインコールが終了した)と、UEが判断する場合、UEは、ステップ922に進み、ここで、信号伝達接続解放指示を送信する。この信号伝達接続解放指示の中に、信号伝達解放指示理由フィールドが追加され、このフィールドはUEがアイドル移行をリクエストしたという事実を含む。
【0101】
データが終了しない場合、ステップ920から、UEはループを戻り、ステップ912で異常な状態が存在しないかどうかをチェックし、ステップ920でデータが終了するかどうかをチェックし続ける。
【0102】
一度、ステップ914またはステップ922で、信号伝達接続解放指示が送信されると、プロセスは、ステップ930に進み、終了する。
【0103】
UEは、機能エレメントを含む。これらの機能エレメントは、例えば、UEマイクロプロセッサの動作を介して実行されるアプリケーションまたはアルゴリズムによって、あるいは、ハードウェアインプリメンテーションによって、インプリメント可能であり、チェッカおよび信号伝達接続解放指示センダを形成する。チェッカは、信号伝達接続解放指示が送信されるべきかどうかをチェックするように構成される。そして、信号伝達接続解放指示センダが、チェッカによる信号伝達接続解放指示を送信すべきであるという指示に応答して、信号伝達接続解放指示を送信するように構成される。信号伝達接続解放指示は、信号伝達解放指示理由フィールドを含む。
【0104】
一つのインプリメンテーションにおいて、ネットワークは、代わりに、暗黙にタイマのタイムアウトに気付くようにされ、UEはタイマのタイムアウトを指示する理由値を送信する必要はない。つまり、タイマは、ネットワークの承諾を受けて、時間計測を開始する。理由コードが規定され、その理由コードは、ネットワークによってUEに提供される。このような理由コードは、タイマを開始するために、UEによって使用される。そして、ネットワークによって以前に送信された理由コードが、タイマに時間測定をさせると、ネットワークは、暗黙のうちに、タイマの次のタイムアウトに対する根拠に気付く。そして、その結果として、UEは、タイマの時間切れを指示する理由値を送信する必要がなくなる。
【0105】
図10を参照すると、ネットワークエレメントが、ステップ1010で信号伝達接続解放指示を受信するとき、ネットワークエレメントは、ステップ1014で信号伝達解放指示理由フィールドを試験し、ステップ1016で、その理由が異常な理由であるかどうか、あるいはその理由はUEがアイドル移行をリクエストしたことによるかどうかをチェックする。ステップ1016で、信号伝達接続解放指示が、異常な理由である場合、ネットワークノードは、ステップ1020に進み、ここでは、警告は、性能をモニタするため、および警告モニタの目的であると注記される。キー性能インディケータは、適切に更新され得る。
【0106】
逆に、ステップ1016で、信号伝達接続解放指示の理由が、異常な状態の結果でない場合、あるいは換言すれば、UEがアイドル移行をリクエストした結果である場合、ネットワークノードは、ステップ1030に進み、ここで、警告が発せられず、指示は、性能統計からフィルタリングされ得、これによって、性能統計がスキューすることが妨げられる。ステップ1020またはステップ1030から、ネットワークノードは、ステップ1040に進み、プロセスは終了する。
【0107】
信号伝達解放指示理由フィールドを受信し、試験すると、その結果、ネットワークエレメントによって、RRC接続解放手順が開始される。そして、パケット交換データ接続が終了する。
【0108】
当業者には理解されるように、ステップ1020は、様々な警告状態の間でさらに区分するために使用され得る。例えば、T3310のタイムアウトは、第一の統計セットを維持するために使用され得、T3330のタイムアウトは、第二の統計セットを維持するために使用され得る。ステップ1020は、異常な状態の理由で区別し得る。これによって、ネットワークオペレータは、性能をより効率的に追跡可能となる。
【0109】
ネットワークは、機能エレメントを含む。これらの機能エレメントは、例えば、UEマイクロプロセッサの動作を介して実行されるアプリケーションまたはアルゴリズムによって、あるいは、ハードウェアインプリメンテーションによって、インプリメント可能であり、試験機および警告生成機を形成する。試験機は、信号伝達接続解放指示の信号伝達解放指示理由フィールドを試験するように構成される。試験機は、信号伝達解放指示理由フィールドが異常な状態であるかどうかをチェックする。警告生成機は、試験機による試験が信号伝達解放指示理由フィールドが異常な状態を示す場合、警告を選択的に生成するように構成される。
【0110】
一つのインプリメンテーションにおいて、UTRANは、信号伝達接続解放指示を受信すると、上部層から受信された理由を転送し、信号伝達接続の解放をリクエストする。上部層は、信号伝達接続の解放を開始することが可能である。IE信号伝達解放指示理由は、UEの上部層に指示することで、UEのRRCをトリガし、メッセージを送信させるようにする。その理由は、おそらく、異常な上部層手順の結果である。メッセージの理由の区分は、IEを成功裏に受信することで確保される。
【0111】
可能性のあるシナリオには、信号伝達接続解放指示メッセージが成功裏に配信されたことがRLCによって確認される前に、信号伝達無線ベアラRB2上のRLC全体の送信側の再確立が起こるシナリオを含む。このようなことが起こった場合、UEは、例えば、信号伝達無線ベアラRB2上のAM RLCを用いて、アップリンクDCCH上の信号伝達接続解放指示メッセージを再送信する。信号伝達接続解放指示メッセージが成功裏に配信されたことの確認が、RLCによって成功裏に配信される前に、UTRAN手順の性能からのエンターRATの引き継ぎが起こった場合、UEは、新たなRATの間に、信号伝達接続を中断する。
【0112】
再び、図1を参照すると、一部の場合において、アイドルモードにあるよりも、接続モード状態URA_PCHにあることが、より望ましい。例えば、CELL_DCHまたはCELL_FACH接続モード状態に接続する待ち時間が少なくなることを要求される場合、接続モードPCH状態にあることが望ましい。これを達成するには、2つの方法がある。第一は、3GPP仕様を変更して、UEがUTRANに、自身を特定の状態(この場合は、URA_PCH状態128)に移動するように要求することである。
【0113】
代替として、RRC接続マネージャは、RRCの接続が現状どのような状態であるかのような他の要因を考慮に入れ得る。例えば、RRC接続がURA_PCH状態である場合、RRC接続は、自身がアイドルモード110に移動する必要がなく、それゆえ、信号接続解放の手順は、開始されない。
【0114】
図4を参照する。図4Aは、上述のインフラストラクチャの「4つ」の例に従って、現在のUMTSのインプリメンテーションを示す。図4に示すように、時間は横軸に沿う。
【0115】
UEは、RRCアイドル状態110で開始し、送信されるべきローカルデータ、または、UTRANから受領したページに基づいて、RRC接続の確立を始める。
【0116】
図4Aに示されるように、RRC接続設定310は、最初に起こり、RRC状態は、この時間中、接続状態410である。
【0117】
次いで、信号接続設定312、暗号化・保全性設定314、および、無線ベアラ設定316が起こる。RRC状態は、この間、CELL_DCH状態122である。図4Aに示されるように、RRCアイドルから移動する時間と、無線ベアラが設定される時間との比率は、この例において、ほぼ2秒である。
【0118】
次いで、データが交換される。図4Aの例において、これは、約2〜4秒で達成され、ステップ420によって示される。
【0119】
ステップ420において、データが交換された後、必要に応じての断続的なRLC信号PDUを除くと、データは全く交換されない。こうして、無線ベアラは、約10秒後に、低データレートのDCH状態に移動するように、ネットワークによって再構成される。これは、ステップ422および424で示されている。
【0120】
低データレートのDCH状態において、17秒間にわたって何も受信されない。この時点で、ステップ428で、RRC接続は、ネットワークによって解放される。
【0121】
一度、RRC接続が、ステップ428で開始されると、RRC状態は、約40ミリ秒にわたって非接続状態430に入り、その後、UEがRRCアイドル状態110になる。
【0122】
また、図4Aに示されているように、UEの電流消費は、RRCがCELL_DCH状態122にあるときの期間にわたって示される。図示のように、電流消費は、CELL_DCH状態の全期間にわたって、約200〜300ミリアンペアである。非接続およびアイドルの間に、DRXサイクルを1.28秒と仮定すると、約3ミリアンペアが使用される。しかしながら、35秒間の電流消費200〜300ミリアンペアは、バッテリを消耗させる。
【0123】
ここで、図4Bを参照する。図4Bは、上記から同じ例示的なインフラストラクチャ「4つ」を利用しているが、ここでのみ、信号接続解放をインプリメントしている。
【0124】
図4Bに示すように、同じ設定ステップ310、312、314および316が起こり、これには、RRCアイドル状態110とRRC CELL_DCH状態122との間を移動するときと、同じ時間量を要する。
【0125】
さらに、図4Aの例示的なeメール用のRRCデータPDU交換も、また、図4Bで行われ、これに、約2〜4秒を要する。
【0126】
図4Bの例の中のUEは、アプリケーション特有の不活動タイムアウトを有する。図4Bの例におけるこのタイムアウトは2秒であり、ステップ440によって描かれている。RRC接続マネージャが特定の時間量にわたって、不活動があると判断した後、ステップ442で、UEは信号接続設定を解放し、ステップ428で、RRC接続はネットワークによって解放される。
【0127】
図4Bに示すように、ステップ122のCELL_DCHの電流消費は、それでもなお、約200〜300ミリアンペアである。しかしながら、接続時間は、約8秒のみである。当業者には理解されるように、モバイルがセルDCH状態122のままである時間が、かなり短い時間量なので、その結果、常にオンであるUEデバイス上のバッテリ節約は、著しいものとなる。
【0128】
ここで、図5を参照する。図5は、上述で示したインフラストラクチャ「3」と示されるインフラを用いる第二の例である。図4Aおよび図4Bと同様、接続設定は、約2秒を要して起こる。これは、RRC接続設定310、信号接続設定312、暗号化・保全性設定314、および、無線ベアラ316を要する。
【0129】
この設定の間に、UEは、RRCアイドルモード110からCELL_DCH状態122に移動する。この両者の間に、RRC状態接続ステップ410がある。
【0130】
図4Aと同様に、図5Aにおいて、RLCデータPDU交換が起こり、図5Aの例においては、約2〜4秒を要する。
【0131】
インフラストラクチャ3に従うと、RLC信号PDU交換は、データを全く受信しないので、必要に応じての断続的なRLC信号PDUを除き、こうして、ステップ422で、5秒の間、アイドルである。この時点において、無線ベアラは、CELL_DCH状態122からCELL_FACH状態124に移動するために、ネットワークを再構成する。これは、ステップ450で行われる。
【0132】
CELL_FACH状態124において、RLC信号PDU交換は、この場合、30秒である所定の時間量に対し必要とされるような断続的なRLC信号PDUを除くと、全くデータがないことを見出す。この時点において、ステップ428で、RRC接続のネットワークによる解放が実行される。
【0133】
図5Aに示すように、これは、RRC状態をアイドルモード110に移動する。
【0134】
さらに、図5Aに示すように、DCHモードの間の電流消費は、200〜300ミリアンペアの間である。CELL_FACH状態124に移動するとき、電流消費は、約120〜180ミリアンペアに下がる。RRCコネクタが、解放され、RRCがアイドルモード110に移動すると、電力消費は約3ミリアンペアになる。
【0135】
UTRA RRC Connected Mode状態は、CELL_DCH状態122またはCELL_FACH状態124であり、図5Aの例では、約40秒続く。
【0136】
ここで、図5Bを参照する。図5Bは、図5Aと同じインフラストラクチャ「3」を示し、RRC接続設定310、信号接続設定312、暗号化・保全性設定314、および、無線ベアラ設定316を得るために、約2秒の同じ接続時間を有する。さらに、RLCデータPDU交換420は、約2〜4秒を要する。
【0137】
図4Bと同様に、UEアプリケーションは、ステップ440で、特定の不活動タイムアウトを検出する。この検出した時点で、信号接続解放指示手順は、UEによって開始され、その結果、RRC接続は、ステップ448で、ネットワークによって解放される。
【0138】
さらに、図5Bから分かるように、RRCは、アイドルモード110にて始まり、CELL_FACH状態を経ずして、CELL_DCH状態122に移動する。
【0139】
さらに、図5Bから分かるように、RRC段階が、CELL_DCH状態122である時間(図5の例に従うと、約8秒である)における電流消費は、約200〜300ミリアンペアの間である。
【0140】
それゆえ、図4Aおよび図4Bと図5Aおよび図5Bとを比較すると、著しい量の電流消費が、除去されている。こうして、UEのバッテリ寿命が著しく伸びる。当業者には理解されるように、上述は、現行の3GPP仕様の関連において、さらに使用され得る。
【0141】
ここで、図6を参照する。図6は、UMTSネットワークに対するプロトコルスタックを示す。
【0142】
図6に示すように、UMTSは、CS制御プレーン610、PS制御プレーン611、および、PSユーザプレーン630を含む。
【0143】
これら3つのプレーンの中には、非アクセス層(non−access stratum)(NAS)部分614およびアクセス層部分616が存在する。
【0144】
CS制御プレーン610内のNAS部分614は、コール制御(CC)618、追加サービス(supplementary services)(SS)620、および、ショートメッセージサービス(SMS)622を含む。
【0145】
PS制御プレーン611のNAS部分614は、移動管理(MM)およびGPRS移動管理(GMM)626を含む。さらに、PS制御プレーン611のNAS部分614は、SM/RABM624およびGSMS628を含む。
【0146】
CC618は、回路交換サービス向けのコール管理信号を提供する。SM/RABM624のセッション管理部分は、PDPコンテキスト活性化、不活性化および修正を提供する。SM/RABM624は、また、サービスの質交渉にも提供する。
【0147】
SM/RABM624のRBAM部分の主機能は、PDPコンテキストを無線アクセスベアラに接続することである。このように、SM/RABM624は、無線ベアラの設定、修正、および解放を担っている。
【0148】
アクセス層616中のCS制御プレーン610およびPS制御プレーン611は、無線リソース制御(RRC)617の上に座している。
【0149】
PSユーザプレーン630内のNAS部分614は、アプリケーション層638、TCP/UDP層636、および、PDP層634を含む、PDP層634は、例えば、インターネットプロトコル(IP)を含む。
【0150】
PSユーザプレーン630内のアクセス層616は、パケットデータ収束プロトコル(PDCP)632を含む。PDCP632は、UEとRNCとの間で、TCP/IPプロトコルを運搬するのに適切なWCDMAプロトコルを作成するように設計され(図8に見られるように)、オプションとして、IPトラフィックストリームプロトコルヘッダ圧縮・解凍用である。
【0151】
UMTS Radio Link Control(RLC)640およびMedium Access Control(MAC)層650は、UMTS無線インターフェースのデータリンクサブレイヤを形成し、RNCノードおよびUser Equipment上に存在する。
【0152】
層1(L1)UMTS層(物理層660)は、RLC/MAC層640および650の下にある。この層は、通信用の物理層である。
【0153】
以上の記述は、様々な移動体デバイス上でインプリメントされ得るが、一つの移動体デバイスの例が、以下に、図7と関連付けて述べられる。ここで、図7を参照する。
【0154】
UE1100は、少なくとも音声およびデータ通信能力を有する双方向ワイヤレス通信デバイスであることが好ましい。UE1100は、インターネット上の他のコンピュータシステムと通信する能力を有することが好ましい。提供された正確な機能性に依存して、ワイヤレスデバイスは、例えば、データメッセージデバイス、双方向ページャ、ワイヤレスeメールデバイス、データメッセージ能力を備えた携帯電話、ワイヤレスインターネット機器、または、データ通信デバイスであり得る。
【0155】
UE1100が双方向通信可能な場合、UE1100は、受信機1112および送信機1114を含む通信サブシステム1111、ならびに、1つ以上の好ましくは内蔵または内部のアンテナエレメント1116および1118、局部発振器(LO)1113、および、デジタル信号プロセッサ(DSP)1120のような処理モジュールのような関連するコンポーネントを組み込む。通信分野の当業者には明らかなように、通信サブシステムの特定の設計は、そのデバイスが動作することを意図される通信ネットワークに依存する。例えば、UE1100は、GPRSネットワークまたはUMTSネットワーク内で動作するように設計された通信サブシステムを含み得る。
【0156】
ネットワークアクセス必要条件はまた、ネットワーク1119のタイプに依存して変化する。例えば、UMTSおよびGPRSネットワークにおいて、ネットワークアクセスは、UE1100の加入者またはユーザと関連する。例えば、GPRS移動体デバイスは、従って、GPRSネットワークで作動するために、加入者識別モジュール(SIM)カードを要求する。UMTSにおいては、USIMまたはSIMモジュールが要求される。CDMAにおいては、RUIMカードまたはモジュールが要求される。これらは、本明細書においては、UIMインターフェースと称される。有効なUIMインターフェースがなければ、移動体デバイスは完全には機能しない。局所または非ネットワーク通信機能、および例えば緊急通話など法的に要求される機能が(もしあれば)利用し得るが、しかし、移動体デバイス1100は、ネットワーク1100での通信を含む任意の他の機能を実行することはできない。UIMインターフェース1144は通常、ディスケットまたはPCMCIAカードのように、カードが挿入されかつ取り出され得るカードスロットに似ている。UIMカードは、約64Kのメモリを有し得て、かつ多くのキー構成1151、ならびに例えば識別および加入者関連の情報のような他の情報1153を保持し得る。
【0157】
要求されたネットワーク登録または起動手順が完了したときには、UE1100は、ネットワーク1119で通信信号を送受信し得る。通信ネットワーク1119を通して、アンテナ1116によって受信された信号は、受信機1112へ入力され、受信機1112は、例えば信号増幅、周波数下方変換、フィルタリング、チャネル選択などのような普通の受信機機能を、および図7に示される例示的システムでは、アナログデジタル(A/D)変換を実行し得る。受信された信号のA/D変換により、例えば、DSP1120で実行される復調および復号のようなさらに複雑な通信機能が可能になる。同様に、送信される信号は、例えばDSP1120によって、変調およびコード化を含んで、処理されて、かつデジタルアナログ変換、周波数上方変換、フィルタリング、増幅およびアンテナ1118を介しての通信ネットワーク1119での送信のために送信機1114へ入力される。DSP1120は、通信信号を処理するのみならず、受信機および送信機の制御も提供する。例えば、受信機1112および送信機1114において通信信号に適用されるゲインは、DSP1120にインプリメントされた自動ゲイン制御アルゴリズムを通して、適応可能に制御され得る。
【0158】
ネットワーク1119は、サーバ1160および他の要素(図示されず)を含む、複数のシステムとさらに通信し得る。例えば、ネットワーク1119は、さまざまなサービスレベルでさまざまなクライアントに便宜を図るために、企業システムとウェブクライアントシステムとの両方と通信し得る。
【0159】
UE1100は、デバイスの全体的な作動を制御するマイクロプロセッサ1138を含むほうが好ましい。少なくともデータ通信を含む通信機能は、通信サブシステム1111を通じ実行される。マイクロプロセッサ1138はまた、例えば表示デバイス1122、フラッシュメモリ1124、ランダムアクセスメモリ(RAM)1126、補助入力/出力(I/O)サブシステム1128、シリアルポート1130、キーボード1132、スピーカ1134、マイクロフォン1136、近距離通信サブシステム1140および一般的に1142として指定される任意の他のデバイスサブシステムのようなさらなるデバイスサブシステムとも相互作用する。
【0160】
図7に示されるサブシステムの一部は、通信関連の機能を実行する一方、他のサブシステムは、「レジデント」またはオンデバイス(on−device)機能を提供し得る。特に、例えばキーボード1132および表示デバイス1122のような一部のサブシステムは、例えば通信ネットワークで送信するためのテキストメッセージを入力するような通信関連機能と、例えば計算機またはタスクリストのようなデバイスレジデント機能との両方のために使用され得る。
【0161】
マイクロプロセッサ1138によって使用されるオペレーティングシステムソフトウエアは、例えばフラッシュメモリ1124のような永続的な記憶デバイスに格納されることが好ましいが、フラッシュメモリ1124の代わりに、読み出し専用メモリ(ROM)または類似の格納要素(図示されず)であり得る。当業者は、作動システム、特定のデバイスアプリケーションまたはその部分は、例えばRAM1126のような揮発性のメモリに一時的に書き込み得るということを理解する。受信された通信信号はまた、RAM1126にも格納され得る。さらに、一意的な識別子が、好ましくも読み出し専用メモリに格納される。
【0162】
図示されているように、フラッシュメモリ1124は、コンピュータプログラム1158ならびにプログラムデータ格納1150、1152、1154および1156両方に対する異なるエリアに分離され得る。これらの異なる格納タイプは、各プログラムが、それら自身のデータ格納必要条件のために、フラッシュメモリ1124の一部を割り当て得ることを示す。マイクロプロセッサ1138は、そのオペレーティングシステム機能に加えて、移動体デバイスでソフトウエアアプリケーションの実行を可能にすることが好ましい。例えば、少なくともデータおよび音声通信アプリケーションを含む、基本オペレーションを制御する所定のアプリケーションのセットは、製造中にUE1100に通常インストールされる。好ましいソフトウエアアプリケーションは、例えば、しかし限定されず、Eメール、カンレンダーイベント、ボイスメール、アポイントメントおよびタスク項目のような、移動体デバイスのユーザに関連するデータ項目を組織化および管理する能力を有するパーソナルインフォメーションマネジャー(PIM)アプリケーションであり得る。当然、1つ以上のメモリ記憶デバイスが、PIMデータ項目の格納を助長するために、移動体デバイスで利用し得る。そのようなPIMアプリケーションは、無線ネットワーク1119を介して、データ項目を送受信する能力を有することが好ましい。好ましい実施形態において、PIMデータ項目は、格納されまたはホストコンピュータシステムと関連づけられる移動体デバイスユーザの対応するデータ項目と、無線ネットワーク1119を介してシームレスに(seamless)に統合され、同期されおよび更新される。さらなるアプリケーションがまた、ネットワーク1119、補助入力/出力(I/O)サブシステム1128、シリアルポート1130、近距離通信サブシステム1140または任意の他の適切なサブシステム1142を通して、移動体デバイス1100にロードされ得て、かつ、マイクロプロセッサ1138による実行のために、RAM1126にまたは好ましくは不揮発性の記憶デバイス(図示されず)に、ユーザによってインストールされ得る。アプリケーションインストールにおけるそのような柔軟性は、デバイスの機能性を高め、かつ向上したオンデバイス機能、通信関連機能またはその両方を提供し得る。例えば、安全な通信アプリケーションは、電子商取引機能および他のそのような金融取引が、UE1100を使用して実行されることを可能にする。しかしながら、これらのアプリケーションは、上記によると、多くの場合、通信業者によって同意される必要がある。
【0163】
データ通信モードにおいて、例えばテキストメッセージまたはウェブページダウンロードのような受信された信号は、通信サブシステム1111によって処理され、かつマイクロプロセッサ1138に入力され、マイクロプロセッサ1138は、表示デバイス1122へまたはあるいは補助I/Oデバイス1128への入力のために、受信された信号をさらに処理することが好ましい。UE1100のユーザはまた、好ましくは完全な英数字キーボードまたは電話タイプのキーパッドであるキーボード1132を、表示デバイス1122およびおそらく補助I/Oデバイス1128と共に使用して、例えばEメールメッセージのようなデータ項目を構成し得る。そのように構成された項目は、通信サブシステム1111を通して、通信ネットワーク上で送信され得る。
【0164】
音声通信に対して、UE1100の全体的な作動は同様であるが、ただし、受信された信号は、スピーカ1134に出力されることが好ましく、送信のための信号は、マイクロフォン1136によって生成される点は除く。例えば音声メッセージ録音サブシステムのような代替案の音声またはオーディオI/Oサブシステムもまた、UE1100でインプリメントされ得る。音声またはオーディオ信号出力は主にスピーカ1134を通して達成されることが好ましいけれども、表示デバイス1122もまた、例えば発呼者の識別、音声通話の継続時間または他の音声通話関連情報の指示を提供するために使用され得る。
【0165】
図7におけるシリアルポート1130は通常、ユーザのデスクトップコンピュータ(図示されず)との同期が望まれる携帯情報端末(PDA)タイプの移動体デバイスにインプリメントされる。そのようなポート1130は、ユーザが、外部デバイスまたはソフトウエアアプリケーションを通して、好みを設定することを可能にし、かつ無線通信ネットワークを経由する以外にもUE1100に情報またはソフトウエアダウンロードを提供することによって移動体デバイス1100の能力を拡張する。代替案のダウンロード経路は、例えば、安全なデバイス通信を可能にするために、直接的な故に確実で信用のある接続を通して、デバイスに暗号化キーをロードするために使用され得る。
【0166】
あるいは、シリアルポート1130は他の通信のために使用され得、かつユニバーサルシリアルバス(USB)ポートとして含み得る。インターフェースが、シリアルポート1130と関連する。
【0167】
例えば、近距離通信サブシステムのような他の通信サブシステム1140は、UE1100と必ずしも類似のデバイスである必要はない異なるシステムまたはデバイスとの間の通信を提供する、さらなる随意のコンポーネントである。例えば、サブシステム1140は、同様にイネーブル化されたシステムおよびデバイスとの通信を提供するために、赤外線デバイスならびに関連回路およびコンポーネント、またはBluetoothTM通信モジュールを含み得る。
【0168】
ここで図8が参照される。図8は、無線通信ネットワークを通して通信するUE802を含む通信システム800のブロック図である。
【0169】
UE802は、複数のNode B 806のうち1つと無線で通信する。各Node
B 806は、エアーインタフェース処理および一部の無線リソース管理機能に対する責任を負う。Node B 806は、GSM/GPRSネットワークにおけるBase
Transceiver Stationと類似の機能性を提供する。
【0170】
図8の通信システム800において示される無線リンクは、1つ以上の異なるチャネル、一般的には異なる無線周波数(RF)チャネル、および無線ネットワークとUE802との間で使用される関連プロトコルを表す。Uuエアーインタフェース804はUE802とNode B 806との間で使用される。
【0171】
RFチャネルは、一般的に、全体的な帯域幅の制限、およびUE802の制限されたバッテリーパワーのために、節約されるべき必要のある限りあるリソースである。当業者は、実際の実用における無線ネットワークは、所望の全体的なネットワーク利用可能範囲の広がりに依存して何百ものセルを含み得るということを理解するであろう。すべての関連のコンポーネントは複数のスイッチおよびルータ(図示されず)によって接続され得て、複数のネットワークコントローラによって制限され得る。
【0172】
各Node B 806は、無線ネットワークコントローラ(RNC)810と通信する。RNC810は、そのエリアにおける無線リソースの制限に対する責任を負う。1つのRNC810は複数のNode B 806を制御する。
【0173】
UMTSネットワークにおけるRNC810は、GSM/GPRSネットワークにおけるBase Station Controller(BSC)機能と同等の機能を提供する。しかしながら、RNC810は、例えば、MSCおよびSGSNを含まない自律的なハンドオーバ管理を含む、より多くの情報を含む。
【0174】
Node B 806とRNC810との間で使用されるインターフェースはIubインターフェース808である。NBAP(Node Bアプリケーションパート)の信号を送るプロトコルが、3GPP TS25.433 V3.11.0(2002−09)および3GPP TS 25.433 V5.7.0(2004−01)に規定されているように、主に使用される。
【0175】
Universal Terrestrial Radio Access Network(UTRAN)820は、RNC810、Node B 806およびUuエアーインタフェース804を備える。
【0176】
回線交換トラフィックが、Mobile Switching Centre(MSC)830へ回送される。MSC830は、呼び出しを行い、加入者またはPSTN(図示されず)からデータを取り、かつ受けるコンピュータである。
【0177】
RNC810とMSC830との間のトラフィックは、Iu−CSインターフェース828を使用する。Iu−CSインターフェース828は、UTRAN810と中心音声ネットワークとの間で音声トラフィックを(通常)運びかつ信号を送るための回線交換接続である。使用される主な信号プロトコルはRANAP(Radio Access Network Application Part)である。RANAPプロトコルは、(下記により詳細に規定される)MSC830またはSSGN850であり得るCore Network 821とUTRAN820との間でのUMTS信号発信に使用される。RANAPプロトコルは、3GPP TS 25.413 V3.11.1(2002−09)およびTS 25.413 V5.7.0(2004−01)に規定される。
【0178】
ネットワークオペレータに登録されたすべてのUE802に対して、パーマネントデータ(例えばUE102ユーザのプロファイルのような)および一時的なデータ(例えばUE802の現在位置のような)はホームロケーションレジストリ(HLR)838に格納される。UE802への音声通話の場合には、HLR838が、UE802の現在位置を決定するためにクエリされる。MSC830のVisitor Location Register(VLR)836が、位置エリアのグループに対する責任を負い、かつ現在その責任のエリア内にある移動局のデータを格納する。これは、より速いアクセスのために、HLR838からVLR836へ送信されたパーマネント移動局データの部分を含む。しかしながら、MSC830のVLR836はまた、例えば一時的な識別のような局所データを割り当てかつ格納し得る。UE802はまた、HLR838によって、システムアクセスについて認証される。
【0179】
パケットデータは、Service GPRS Support Node (SGSN)850を介して回送される。SGSN850は、RNCとGPRS/UMTSネットワークにおける中心ネットワークとの間の出入り口であり、その地理的サービスエリア内でUEとの相互のデータパケットの引渡しに対する責任を負う。Iu−PSインターフェース848は、RNC810とSGSN850との間で使用され、UTRAN820と中心データネットワークとの間でデータトラフィックを(一般的に)運びかつ信号を送るためのパケット交換接続である。使用される主な信号プロトコルは(上記の)RANAPである。
【0180】
SSGN850は、Gateway GPRS Support Node (GGSN)860と通信する。GGSN860は、UMTS/GPRSネットワークと、例えばインターネットまたは個人のネットワークのような他のネットワークとの間のインターフェースである。GGSN860は、Giインターフェース上で、パブリックデータネットワークPDN870へ接続される。
【0181】
当業者は、無線ネットワークは、図8に明確には示されていないが、おそらく他のネットワークを含む、他のシステムに接続され得るということを理解する。ネットワークは、通常は、たとえ交換される実際のパケットデータがない場合であっても。少なくとも何らかの種類のページングおよびシステム情報を、進行中の基礎に基づいて、送信している。ネットワークは多くの部分から成るものの、これらの部分はすべて共に働いて、無線リンクにおいて特定の挙動を生じる。
【0182】
本明細書に記述された実施形態は、本出願の技術の要素に対応する要素を有する構造、システムまたは方法の例である。ここに記された記載内容に基づいて、当業者は、本出願の技術の要素に類似して対応する代替の要素を有する実施形態を作成し使用することができる。従って本出願の技術の意図された範囲は、本明細書に記述されたとおりの本出願の技術と異ならない他の構造、システムまたは方法を含み、かつ本明細書に記述された通りの本出願の技術と本質的に異ならない他の構造、システムまたは方法をさらに含む。
【符号の説明】
【0183】
110 RRCアイドル状態
120 RRC接続状態
122 CELL_DCH状態、
124 CELL_FACH状態、
126 CELL_PCH状態
128 URA_PCH状態
【特許請求の範囲】
【請求項1】
ユーザ設備(1100)において指示メッセージを処理する方法であって、
前記方法は、
前記ユーザ設備(1100)において、さらなるデータが期待されていないという理由を前記指示メッセージの中に設定することと、
前記指示メッセージを前記ユーザ設備(1100)から無線ネットワークに送信することと
を含む、方法。
【請求項2】
前記指示メッセージは、信号接続解放指示メッセージである、請求項1に記載の方法。
【請求項3】
前記理由は、「UEが、PSデータセッションの終了をリクエストした」に設定される、請求項1に記載の方法。
【請求項4】
前記理由は、PSデータセッションを終了するようにとの前記ユーザ設備によるリクエストを示す、請求項1に記載の方法。
【請求項5】
前記理由は、「その他の理由」に設定される、請求項1に記載の方法。
【請求項6】
前記指示メッセージは、AM RLCを用いてDCCH上で送信される、請求項1〜5のいずれか一項に記載の方法。
【請求項7】
信号接続解放指示メッセージが送信されるべきであることを決定することをさらに含む、請求項1〜6のいずれか一項に記載の方法。
【請求項8】
信号接続解放指示メッセージが送信されるべきであることを決定することは、前記ユーザ設備(1100)において、特定のコアネットワーク(CN)ドメインに対する上位層からの信号接続を解放または中断するリクエストを受信することをさらに含む、請求項7に記載の方法。
【請求項9】
前記無線ネットワークは、UMTS地上無線アクセスネットワーク(UTRAN)である、請求項1〜8のいずれか一項に記載の方法。
【請求項10】
前記理由は、前記指示メッセージの情報エレメント(IE)である、請求項1〜9のいずれか一項に記載の方法。
【請求項11】
前記指示メッセージは、ユーザ設備のタイマの時間切れ後に前記理由とともに送信される、請求項1〜10のいずれか一項に記載の方法。
【請求項12】
指示メッセージを処理するように構成されたユーザ設備(1100)であって、前記ユーザ設備は、無線サブシステム(1111)と、プロセッサとを有し、前記プロセッサは、メモリ(1124、1126)と前記無線サブシステム(1111)とユーザインターフェースとに相互作用するように構成されており、
前記ユーザ設備は、請求項1〜11のいずれか一項に記載の方法を実行する手段によって特徴付けられている、ユーザ設備。
【請求項13】
無線ネットワーク(1119)においてメッセージを処理する方法であって、
前記方法は、
理由が設定されている指示メッセージをユーザ設備から受信すること(1010)と、
前記理由に基づいて、信号接続のための状態遷移を開始することと
を含む、方法。
【請求項14】
前記理由は、「UEが、PSデータセッションの終了をリクエストした」に設定される、請求項13に記載の方法。
【請求項15】
前記理由は、PSデータセッションを終了するようにとの前記ユーザ設備(1100)によるリクエストを示す、請求項13に記載の方法。
【請求項16】
前記理由は、「その他の理由」に設定される、請求項13に記載の方法。
【請求項17】
前記指示メッセージは、AM RLCを用いてDCCH上で送信される、請求項13〜16のいずれか一項に記載の方法。
【請求項18】
前記無線ネットワークは、UMTS地上無線アクセスネットワーク(UTRAN)である、請求項13〜17のいずれか一項に記載の方法。
【請求項19】
前記理由は、前記指示メッセージの情報エレメント(IE)である、請求項13〜18のいずれか一項に記載の方法。
【請求項20】
指示メッセージを処理する無線ネットワーク装置(1119)であって、前記無線ネットワーク装置(1119)は、請求項13〜19のいずれか一項に記載の方法を実行する手段によって特徴付けられている、無線ネットワーク装置(1119)。
【請求項1】
ユーザ設備(1100)において指示メッセージを処理する方法であって、
前記方法は、
前記ユーザ設備(1100)において、さらなるデータが期待されていないという理由を前記指示メッセージの中に設定することと、
前記指示メッセージを前記ユーザ設備(1100)から無線ネットワークに送信することと
を含む、方法。
【請求項2】
前記指示メッセージは、信号接続解放指示メッセージである、請求項1に記載の方法。
【請求項3】
前記理由は、「UEが、PSデータセッションの終了をリクエストした」に設定される、請求項1に記載の方法。
【請求項4】
前記理由は、PSデータセッションを終了するようにとの前記ユーザ設備によるリクエストを示す、請求項1に記載の方法。
【請求項5】
前記理由は、「その他の理由」に設定される、請求項1に記載の方法。
【請求項6】
前記指示メッセージは、AM RLCを用いてDCCH上で送信される、請求項1〜5のいずれか一項に記載の方法。
【請求項7】
信号接続解放指示メッセージが送信されるべきであることを決定することをさらに含む、請求項1〜6のいずれか一項に記載の方法。
【請求項8】
信号接続解放指示メッセージが送信されるべきであることを決定することは、前記ユーザ設備(1100)において、特定のコアネットワーク(CN)ドメインに対する上位層からの信号接続を解放または中断するリクエストを受信することをさらに含む、請求項7に記載の方法。
【請求項9】
前記無線ネットワークは、UMTS地上無線アクセスネットワーク(UTRAN)である、請求項1〜8のいずれか一項に記載の方法。
【請求項10】
前記理由は、前記指示メッセージの情報エレメント(IE)である、請求項1〜9のいずれか一項に記載の方法。
【請求項11】
前記指示メッセージは、ユーザ設備のタイマの時間切れ後に前記理由とともに送信される、請求項1〜10のいずれか一項に記載の方法。
【請求項12】
指示メッセージを処理するように構成されたユーザ設備(1100)であって、前記ユーザ設備は、無線サブシステム(1111)と、プロセッサとを有し、前記プロセッサは、メモリ(1124、1126)と前記無線サブシステム(1111)とユーザインターフェースとに相互作用するように構成されており、
前記ユーザ設備は、請求項1〜11のいずれか一項に記載の方法を実行する手段によって特徴付けられている、ユーザ設備。
【請求項13】
無線ネットワーク(1119)においてメッセージを処理する方法であって、
前記方法は、
理由が設定されている指示メッセージをユーザ設備から受信すること(1010)と、
前記理由に基づいて、信号接続のための状態遷移を開始することと
を含む、方法。
【請求項14】
前記理由は、「UEが、PSデータセッションの終了をリクエストした」に設定される、請求項13に記載の方法。
【請求項15】
前記理由は、PSデータセッションを終了するようにとの前記ユーザ設備(1100)によるリクエストを示す、請求項13に記載の方法。
【請求項16】
前記理由は、「その他の理由」に設定される、請求項13に記載の方法。
【請求項17】
前記指示メッセージは、AM RLCを用いてDCCH上で送信される、請求項13〜16のいずれか一項に記載の方法。
【請求項18】
前記無線ネットワークは、UMTS地上無線アクセスネットワーク(UTRAN)である、請求項13〜17のいずれか一項に記載の方法。
【請求項19】
前記理由は、前記指示メッセージの情報エレメント(IE)である、請求項13〜18のいずれか一項に記載の方法。
【請求項20】
指示メッセージを処理する無線ネットワーク装置(1119)であって、前記無線ネットワーク装置(1119)は、請求項13〜19のいずれか一項に記載の方法を実行する手段によって特徴付けられている、無線ネットワーク装置(1119)。
【図1】
【図2】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】
【図2】
【図3】
【図4A】
【図4B】
【図5A】
【図5B】
【図6】
【図7】
【図8】
【図9】
【図10】
【公開番号】特開2011−176856(P2011−176856A)
【公開日】平成23年9月8日(2011.9.8)
【国際特許分類】
【出願番号】特願2011−83176(P2011−83176)
【出願日】平成23年4月4日(2011.4.4)
【分割の表示】特願2007−131146(P2007−131146)の分割
【原出願日】平成19年5月17日(2007.5.17)
【出願人】(500043574)リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Research In Motion Limited
【住所又は居所原語表記】295 Phillip Street, Waterloo, Ontario N2L 3W8 Canada
【Fターム(参考)】
【公開日】平成23年9月8日(2011.9.8)
【国際特許分類】
【出願日】平成23年4月4日(2011.4.4)
【分割の表示】特願2007−131146(P2007−131146)の分割
【原出願日】平成19年5月17日(2007.5.17)
【出願人】(500043574)リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Research In Motion Limited
【住所又は居所原語表記】295 Phillip Street, Waterloo, Ontario N2L 3W8 Canada
【Fターム(参考)】
[ Back to top ]