JP2011520341A - ワイヤレスネットワークにおける不連続受信の制御のための方法およびシステム - Google Patents

Abstract

モバイルデバイス上の不連続受信を制御するため、具体的には、媒体アクセス制御の制御要素の受信に応じて、短期不連続受信タイマーを制御するための方法および装置。方法および装置は、短期不連続受信タイマーを停止、再開、または維持するステップを含む。再送タイマーの開始を停止または防止するように、ユーザ機器に伝送の最大再試行値を提供することによって、最大冗長バージョン値を提供することによって、または、媒体アクセス制御の制御要素を提供することによって、再送タイマーを制限または停止するための方法および装置。

Description

（開示の分野）
本開示は、第三世代パートナーシッププロジェクト（３ＧＰＰ）のロングタームエボリューション（Ｅ−ＵＴＲＡ）に関し、具体的には、Ｅ−ＵＴＲＡインフラストラクチャにおけるユーザ機器（ＵＥ）のための不連続受信（ＤＲＸ）に関する。

（背景）
ロングタームエボリューションインフラストラクチャにおいて、ＵＥは、２つの無線リソース制御（ＲＲＣ）状態のうちの１つであり得る。これらは、ＬＴＥ＿ＩＤＬＥおよびＬＴＥ＿ＡＣＴＩＶＥである。

ＵＥは、ＬＴＥ＿ＩＤＬＥおよびＬＴＥ＿ＡＣＴＩＶＥの両方の状態において不連続受信（ＤＲＸ）に構成され得る。ＤＲＸによって、ＵＥはそのリスニング期間をネットワークの周知のページングサイクルに同期化することが可能になる。リスニング期間をネットワークから受容可能な伝送時間に同期することによって、ＵＥは、ネットワークが伝送を予定しない時、その無線受信器を切断することができ、したがって、電池リソースを大幅に節約する。当業者によって理解されるように、ＵＥが広範囲にわたって使用されない限り、その電池の大部分の損失は、ページングチャネル（または制御チャネル）を監視し、サービスしている近接のセルを測定する、スタンドバイサイクルから発生する。ＤＲＸパラメータによって、モバイルは、ネットワークと同期すること、かつ特定時間が経過するまで別の信号を受信することはないことを知ることが可能になる。

ＩＤＬＥ状態においてＤＲＸを利用することは、現在のＵＭＴＳシステムにおいて実施されており、ＵＥにＤＲＸパラメータを発信し、ＵＥとネットワークとを同期化しているネットワークによって、実行される。

しかしながら、ＡＣＴＩＶＥ状態において、ＤＲＸパラメータに基づいて受信器を切断するためには、多様な問題が存在する。これには、ＬＴＥ＿ＡＣＴＩＶＥ状態において、ネットワーク制御のハンドオーバーだけが可能であるという事実が挙げられる。また、他の問題には、ＤＲＸの有効化と無効化の効率的な発信、ＤＲＸの間のネットワーク信号の測定要件、ハンドオーバー機会損失の処理、およびネットワークのエンティティが、ＤＲＸの有効化およびＤＲＸ期間の再構成を要求できる、ＤＲＸ値の長さの対応問題が挙げられる。

さらなる問題には、長期ＤＲＸの多様なタイマーの構成および制御が関与する。

本開示は、ＬＴＥ＿ＡＣＴＩＶＥ状態におけるＤＲＸに関して先行技術の不具合に対応するための多様な方法およびシステムを提供する。

本開示は、媒体アクセス制御の制御要素を受信するステップと、短期ＤＲＸサイクルが構成されているかどうかを確認するステップと、確認に応答して短期ＤＲＸタイマーを停止するステップと、長期ＤＲＸサイクルを利用するステップと、を含む、短期不連続受信「ＤＲＸ」タイマーを制御する方法を提供する。

本開示は、媒体アクセス制御の制御要素を受信するステップと、短期ＤＲＸサイクルが構成されているかどうかを確認するステップと、確認に応答して短期ＤＲＸタイマーを再開するステップと、を含む、短期不連続受信「ＤＲＸ」タイマーを制御する方法をさらに提供する。

本開示は、媒体アクセス制御の制御要素を受信するステップと、短期ＤＲＸサイクルが構成されているかどうかを確認するステップと、確認に応答して短期ＤＲＸタイマーを維持するステップと、を含む、短期不連続受信「ＤＲＸ」タイマーを制御する方法をまたさらに提供する。

本開示は、ネットワーク要素と通信するように、かつさらに媒体アクセス制御の制御要素を受信するように適合される、通信サブシステムと、プロセッサであって、短期ＤＲＸサイクルが構成されているかどうかを確認し、確認に応答して、短期ＤＲＸタイマーを停止し、かつユーザ機器を長期ＤＲＸサイクルに遷移するように適合される、プロセッサと、を備える、短期不連続受信「ＤＲＸ」タイマーを制御するように適合される、ユーザ機器をさらに提供する。

本開示は、ネットワーク要素と通信するように、かつさらに媒体アクセス制御の制御要素を受信するように適合される、通信サブシステムと、プロセッサであって、短期ＤＲＸサイクルが実行中であるかどうかを確認し、確認に応答して、短期ＤＲＸタイマーを再開するように適合される、プロセッサと、を備える、短期不連続受信「ＤＲＸ」タイマーを制御するように適合される、ユーザ機器をさらに提供する。

本開示は、ネットワーク要素と通信するように、かつさらに媒体アクセス制御の制御要素を受信するように適合される、通信サブシステムと、プロセッサであって、短期ＤＲＸサイクルが構成されているかどうかを確認し、確認に応答して、短期ＤＲＸタイマーを維持するように適合された、プロセッサと、を備える、短期不連続受信「ＤＲＸ」タイマーを制御するように適合される、ユーザ機器をさらに提供する。

本開示は、ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の最大回数の値を受信するステップと、ハイブリッド確認応答要求プロセスのためのダウンリンク伝送回数が値以上であるかどうかを確認するステップと、確認に応答して、再送タイマーが開始することを防止するステップと、を含む、再送タイマーの開始を防止する方法をさらに提供する。

本開示は、特定の冗長バージョンの値を受信するステップと、ハイブリッド確認応答要求プロセスの冗長バージョンが値に等しいかどうかを確認するステップと、確認に応答して、再送タイマーが開始することを防止するステップと、を含む、再送タイマーの開始を防止する方法をさらに提供する。

本開示は、ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の回数の満了値を受信するステップと、ハイブリッド確認応答要求プロセスのためのダウンリンク伝送回数が満了値以上であるかどうかを確認するステップと、確認に応答して、再送タイマーが開始することを防止するステップと、を含む、再送タイマーの開始を防止する方法をさらに提供する。

本開示は、不連続受信媒体アクセス制御の制御要素を受信するステップと、不連続受信媒体アクセス制御の制御要素に対応するハイブリッド確認要求プロセスを識別するステップと、ハイブリッド確認要求プロセスのための再送タイマーの開始を防止するまたは停止するステップと、を含む、再送タイマーの持続時間を制限する、または再送タイマーの開始を防止する方法を提供する。

本開示は、ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の最大回数の値を受信するように適合される、通信サブシステムと、ハイブリッド確認応答要求プロセスのためのダウンリンク伝送回数が値以上であるかどうかを確認するように適合されるプロセッサであって、確認に応答して、再送タイマーが開始することを防止するように適合される、プロセッサと、を備える、再送タイマーが開始することを防止するように適合される、ユーザ機器をさらに提供する。

本開示は、特定の冗長バージョンの値を受信するように適合されるサブシステムと、ハイブリッド確認要求プロセスの冗長バージョンが値に等しいかどうかを確認するように適合されるプロセッサであって、確認に応答して、再送タイマーが開始することを防止するように適合される、プロセッサと、を備える、再送タイマーが開始することを防止するように適合される、ユーザ機器をさらに提供する。

本開示は、ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の回数の満了値を受信するように適合される通信サブシステムと、ハイブリッド確認応答要求プロセスのためのダウンリンク伝送回数が満了値以上であるかどうかを確認するように適合されるプロセッサであって、確認に応答して、再送タイマーが開始することを防止するように適合される、プロセッサと、を備える、再送タイマーが開始することを防止するように適合される、ユーザ機器をさらに提供する。

本開示は、不連続受信媒体アクセス制御の制御要素を受信するように適合される通信サブシステムと、不連続受信媒体アクセス制御の制御要素に対応するハイブリッド確認要求プロセスを識別するように適合されるプロセッサであって、ハイブリッド確認要求プロセスのための再送タイマーの開始を防止するまたは停止するようにさらに適合される、プロセッサと、を備える、再送タイマーの持続時間を制限するように、または再送タイマーが開始することを防止するように適合される、ユーザ機器をさらに提供する。

本出願は、以下の図面を参照することにより、より良く理解される。
図１は、ロングタームエボリューションのユーザプレーンプロトコルスタックを示すブロック図である。 図２は、ロングタームエボリューションの制御プレーンプロトコルアーキテクチャを示すブロック図である。 図３ａは、ｅＮＢ側からＭＡＣ−ＰＤＵヘッダを使用して、ＤＲＸ期間を有効化、無効化、および再構成する方法を示す流れ図である。 図３ｂは、ＵＥ側からＤＲＸ期間の有効化、無効化、または再構成を確認する方法を示す流れ図である。 図４ａは、ｅＮＢ側からＭＡＣ−ＰＤＵヘッダを使用して、長期ＤＲＸ期間へ直接遷移するための方法を示す流れ図である。 図４ｂは、ＵＥ側から長期ＤＲＸ期間へ直接遷移し、実行している場合は短期ＤＲＸタイマーを停止する方法を示す流れ図である。 図４ｃは、ＵＥ側から長期ＤＲＸ期間へ直接遷移し、実行している場合は短期ＤＲＸタイマーを再構成する方法を示す流れ図である。 図４ｄは、ＵＥ側から長期ＤＲＸ期間へ直接遷移し、実行している場合は短期ＤＲＸタイマーを停止する方法を維持する流れ図である。 図５ａは、再試行の最大回数が発生したことを発信するための、ネットワーク側の方法を示す流れ図である。 図５ｂは、再送タイマーを開始するかどうかを決定するための、ＵＥ側の方法を示す流れ図である。 図６ａは、再試行の最大回数が発生したことを発信するための、ネットワーク側の方法を示す流れ図である。 図６ｂは、再送タイマーを開始するかどうかを決定するための、ＵＥ側の方法を示す流れ図である。 図７ａは、再試行の回数の満了値を発信するための、ネットワーク側の方法を示す流れ図である。 図７ｂは、再送タイマーを開始するかどうかを決定するための、ＵＥ側の方法を示す流れ図である。 図８ａは、最大冗長バージョン番号を発信するための、ネットワーク側の方法を示す流れ図である。 図８ｂは、再送タイマーを開始するかどうかを決定するための、ＵＥ側の方法を示す流れ図である。 図９は、本開示での使用に適した例示的なモバイルデバイスのブロック図である。 図１０は、本開示での使用に適した簡素化されたネットワーク要素のブロック図である。

ここで図面を参照する。図１は、ロングタームエボリューション（ＬＴＥ）ユーザプレーンプロトコルスタックを示すブロック図である。

ＵＥ１１０は、進化型ノードＢ（ｅＮＢ）１２０と通信する。

プロトコルスタックには多様なレイヤが示される。パケットデータ収束プロトコル（ＰＤＣＰ）レイヤ１４０は、ＵＥ１１０上およびｅＮＢ１２０上の両方に示される。ＰＤＣＰレイヤ１４０は、インターネットプロトコル（ＩＰ）ヘッダの圧縮および解凍、ユーザデータの暗号化、ユーザデータの転送および無線ベアラのＰＤＣＰシーケンス番号（ＳＮ）の維持を実施する。

ＰＤＣＰレイヤ１４０の下には、無線リンク制御プロトコルレイヤ１４２があり、ｅＮＢ上の無線リンク制御プトロコルレイヤ１４２と通信する。理解されるように、通信は、図１および２に示されたようなプロトコルスタックの物理的レイヤを介して発生する。しかしながら、ＵＥのＲＬＣレイヤ１４２からのＲＬＣ−ＰＤＵは、ｅＮＢ１２０上のＲＬＣレイヤ１４２によって変換される。

ＲＬＣレイヤ１４２の下には、媒体アクセス制御（ＭＡＣ）データ通信プロトコルレイヤ１４６がある。当業者によって理解されるように、ＬＴＥ無線のデータリンクサブレイヤからのＲＬＣおよびＭＡＣプロトコルは、ＬＴＥのｅＮＢおよびユーザ機器上とインターフェースし、この上に存在する。

レイヤ１（Ｌ１）ＬＴＥ（物理レイヤ１４８）は、ＲＬＣ／ＭＡＣレイヤ１４２および１４６の下にある。このレイヤは、通信のための物理レイヤである。

図２を参照すると、図２は、ＬＴＥ制御プレーンプロトコルアーキテクチャを示す。図１において使用された同様な参照番号が図２で使用される。具体的には、ＵＥ１１０は、ｅＮＢ１２０およびアクセスゲートウェイ（ａＧＷ）１３０と通信する。さらに、図２には、物理レイヤ１４８、ＭＡＣレイヤ１４６、ＲＬＣレイヤ１４２およびＰＤＣＰレイヤ１４０が存在する。

また、図２は、非アクセス層（ＮＡＳ）レイヤ２１０も示す。理解されるように、ＮＡＳ層２１０は、移動性管理およびセッション管理を含むことができる。

無線リソース制御プロトコルレイヤ（ＲＲＣ）２２０は、ＵＥとＥ−ＵＴＲＡＮ（進化型ユニバーサル地上無線アクセスネットワーク）との間の無線リソースの割り当て、構成および解放の役割を果たす、プロトコルスタックの部分である。ＬＴＥに対するＲＲＣプロトコルの基本的な機能は、３ＧＰＰ ＴＳ ３６．３３１に説明される。

当業者によって理解されるように、ＵＭＴＳにおいて、自動反復要求（ＡＲＱ）機能は、無線ネットワークコントローラ（ＲＮＣ）に存在するＲＬＣレイヤ内で実行される。ロングタームエボリューション（ＬＴＥ）は、ＡＲＱ機能をＲＮＣから、より緊密な相互作用がＡＲＱとＨＡＲＱとの間（ｅＮＢにも存在する、ＭＡＣレイヤ内）に存在する可能性がある、ｅＮＢに移動させる。

ＬＴＥ−ＡＣＴＩＶＥ状態のＤＲＸに関する多様な問題をここで検討する。
ＤＲＸ発信手順
ＬＴＥ＿ＡＣＴＩＶＥ状態においてＤＲＸを利用している、セルにおいて大量のＵＥをサポートするためには、ＤＲＸを有効化および無効化し、かつＤＲＸ期間の持続時間を指定するための非常に効率的な発信手順が必要とされる。

当業者によって理解されるように、進化型ノードＢ（ｅＮＢ）が、ＤＲＸ操作のためにその受信器がオフの期間にＵＥにデータを伝送する場合、ＵＥはデータを受信することができない。したがって、ＤＲＸがいつ有効化および無効化されているかについて、ＵＥとｅＮＢとが必ず同期されていることの指標が必要である。

ＵＥとｅＮＢとの間の指標は、無線リソース制御（ＲＲＣ）またはレイヤ１／レイヤ２（Ｌ１／Ｌ２）発信によって、明示的に発信することができる。しかしながら、理解されるように、明示的な発信は、所望されるほど効率的ではない場合がある。

より効率的なソリューションは、ＭＡＣ−ＰＤＵ（ＭＡＣプロトコルデータユニット）のＭＡＣヘッダにオプションのフィールドを含めて、ＤＲＸの有効化および無効化を示すことである。フィールドは、有効化および無効化に対するＤＲＸの値およびタイミングマージンを示すことが好ましい。例えば、一実施形態において、ゼロの値は、ＤＲＸ値フィールドにおいてＤＲＸの無効化を意味することができる。このため、次のＭＡＣ−ＰＤＵにおいて伝送される予定のデータが、ＵＥのバッファの最後の１つである場合、ｅＮＢは、ＤＲＸの長さの初期値を含めるように、ＭＡＣヘッダを拡張することができる。例えば、これは、３２０ミリ秒であり得る。タイミングマージンは以下で説明されるが、ＵＥとｅＮＢとの間のＭＡＣ−ＰＤＵの受信ステータスに対して、ＮＡＣＫからＡＣＫ、またはＡＣＫからＮＡＣＫの誤変換の影響を軽減するように利用される。

例えば、ＤＲＸ期間の８つの値を示すために、３ビットがＭＡＣヘッダに追加されてもよい。このように、特定の時間の値が送信されるのではなく、０００から１１１までのビット値が、８つの離散値を示すことができる。

代替実施形態において、ＭＡＣヘッダのより小さいフィールドが使用されて（例えば、２ビット）、増分または減分を示すことができる。ＲＲＣは、デフォルト値を示すことができ、ＭＡＣヘッダが増分または減分を示す場合、ＵＥは、事前に指定された値に変更することができる。

例えば、ダウンリンク共有チャネル（ＤＬ−ＳＣＨ）の論理チャネルＩＤフィールド（ＬＣＩＤ）は、以下であり得る。

上記のように、ＤＲＸ制御要素は、インデックスの１１１１０であり得る。

ＵＥがＤＲＸ値を受信すると、ＨＡＲＱ ＡＣＫを伝送することによって、それをｅＮＢに応答確認し、ｅＮＢでの伝播遅延および処理遅延を考慮して、システムフレーム時間でＤＲＸを開始する。ｅＮＢは、ＵＥからＡＣＫを受信すると、次のシステムフレーム時間でもＤＲＸを開始する。理解されるように、ｅＮＢは、その受信器を切断しないが、個別のＵＥにメッセージを伝送しないことだけを理解する。

ＤＲＸ期間、ｅＮＢに新しいデータが到着すると、ｅＮＢは、バッファ内のデータ量またはサービス品質の要件に応答して、ヘッダ拡張をＤＲＸ無効または短期ＤＲＸの長さに設定して、ＭＡＣ−ＰＤＵを送信することができる。ＵＥは、これに応答してＤＲＸを再構成し、ＭＡＣ−ＰＤＵに応答する。ｅＮＢがＡＣＫを受信すると、ＤＲＸを再構成する。上記のように、無効化は、長さの値をゼロに設定することだけによって、実現され得る。

ここで、図３ａおよび３ｂを参照する。図３は、ＬＴＥ−ＡＣＴＩＶＥ状態でＤＲＸの有効化を制御するための例示的な方法を示す。プロセスは、ブロック３００で開始し、ブロック３１０に進み、ここで、データがＵＥへ伝送される。当業者によって理解されるように、ＬＴＥ＿ＡＣＴＩＶＥ状態のデータ伝送は、データリンクレイヤでＭＡＣ−ＰＤＵを利用して、データを伝送する。

プロセスは次にブロック３１２に進み、ここで、次の伝送後、ＵＥに送信されるデータのバッファが空であるかどうかの確認が行われる。空でない場合、プロセスはブロック３１０に戻り、ここでデータがＵＥへ伝送される。代替として、次の伝送後、バッファが空であり、データの到着速度が閾値よりも低い場合、プロセスは、ブロック３１４に進む。

ブロック３１４において、ｅＮＢは、ＭＡＣ−ＰＤＵヘッダにＤＲＸの有効化を設定する。
上記のように、これは、ＤＲＸ期間の長さを示すＤＲＸ有効値を含む。別の実施形態において、ｅＮＢは、ＤＲＸ間隔の増加を示すだけの場合がある。ＵＥは、既存のＤＲＸの間隔を既定の間隔に再構成する。既定の間隔は、ｅＮＢおよびＵＥの両方にわかっている場合、または明示的な発信を経由して、ｅＮＢからＵＥへ事前に発信されている場合があるが、これは、システムブロードキャストまたはＲＲＣ発信のいずれかによって行われる。

プロセスは、その後、ブロック３１６に進み、ここで、変更されたＭＡＣ−ＰＤＵヘッダを含むデータがＵＥに送信される。

ここで図３ｂを参照する。ブロック３１８において、ＵＥはデータを受信し、ＤＲＸの有効化がＭＡＣ−ＰＤＵヘッダに指定されていることを確認する。プロセスハブロック３２０に進み、ここで、ＵＥは、ｅＮＢに応答（ＡＣＫ）を送信し、ｅＮＢでの伝播遅延および処理遅延を考慮して、システムフレーム時間でＤＲＸを開始する。

図３ａのブロック３３０において、ｅＮＢはＵＥからＡＣＫを受信し、次のシステムフレーム時間でＤＲＸを開始する。

理解されるように、ＤＲＸは、ＤＲＸが調整されることを必要とする可能性がある、多様なイベントが発生するまで、継続することができる。１つのイベントは、ｅＮＢによって、ＵＥのための、ＧＷからのデータの受信である。受信されたデータ量に応答して、ＤＲＸが無効化されるか、またはＤＲＸの期間が削減されるか、のいずれかが可能である。ＤＲＸの調整を必要とする可能性がある他のイベントは、特に、ｅＮＢとＵＥとの間の信号強度の変化、または、可能性として、データ非活動の継続によるＤＲＸサイクルの段階的な増加を含む。これらの他のイベントは、以下に詳細を説明する。

ブロック３３２において、ｅＮＢは、ＤＲＸが調整されることが必要であるかどうかを確認する。上記のように、これは、データが受信されてＵＥへ送信される状況であり得る。ここでは、ＤＲＸは、無効化されているか、または調整された期間のいずれかであり得る。

ブロック３３２から、ＤＲＸが調整される必要がない場合、プロセスはブロック３３２に戻り、ＤＲＸが調整される必要があるかどうかを引き続き確認する。

ブロック３３２のプロセスが、ＤＲＸが調整される必要があることを発見すると、プロセスは、ブロック３３２に進み、ここで、ＤＲＸを調整する。これは、必要に応じて、ＤＲＸのゼロ値またはこれより短期ＤＲＸまたはこれより長期ＤＲＸを伝送することによって、ＤＲＸを無効化することであり得る。

ブロック３３６において、ヘッダが変更されたＭＡＣ−ＰＤＵは、ＵＥに送信される。
ブロック３３６のＭＡＣ−ＰＤＵは、ＵＥに伝送されることが必要である、ｅＮＢによって受信されていた任意のデータも含むことができる。

図３ｂを参照すると、プロセスは次にブロック３１８に進み、ここで、ヘッダが変更されたＭＡＣ−ＰＤＵは、ＵＥで受信される。このヘッダが変更されたＭＡＣ−ＰＤＵは、本明細書においては、ＭＡＣ制御要素（ＣＥ）として参照される。ＵＥは、ＤＲＸ期間が調整されることを認識し、ブロック３２０において、ｅＮＢに応答を送信し、伝播遅延および処理遅延を考慮して、ｅＮＢと同様な同じシステムフレーム時間でＤＲＸ期間を調整する。

図３ａを参照すると、ブロック３４２において、ｅＮＢはＡＣＫを受信し、適切なシステムフレーム時間で変更されたＤＲＸ期間を開始する。プロセスは次にブロック３３２に戻り、ＤＲＸが再び調整される必要があるかどうかを確認する。

一実施形態において、ＤＲＸコマンドのＭＡＣ制御要素は、ＵＥに対して、ＤＲＸ期間への遷移を示すことができる。この場合、ｅＮＢが、アップリンクおよびダウンリンクトラフィックの欠落、ならびに非リアルタイムＤＲＸのトラフィックの低速度に基づいて、ＵＥを長期ＤＲＸ期間へ遷移させたい場合、現在のＥ−ＵＴＲＡ規格においては、これは、ＤＲＸ構成の変更を必要とし、ＲＲＣ構成メッセージで行われる。これは、「スリープ状態に入る」ＣＥの場合がある。これに関する問題は、ｅＮＢが後で、これより短期ＤＲＸ期間を要求するトラフィックパターンを受信すると、ＵＥ上のＤＲＸ構成を再構成するために、ＲＲＣ構成メッセージが再び送信されることを必要とする点である。

代わりに、ＭＡＣ ＣＥは、「長期スリープ状態に入る」可能性を含むことができる。このため、ｅＮＢは、ＵＥに、再構成メッセージを明示的に送信することなく、長期ＤＲＸ期間またはサイクルに直接入るオプションを提供することができる。

ここで図４ａを参照する。図４ａにおいて、プロセスはブロック４１０で開始し、ブロック４１２に進み、ここで、長期ＤＲＸサイクルのための事前条件が存在するかどうかを決定するための確認が行われる。当業者によって理解されるように、このような事前条件は、特に、ＤＲＸが構成されていること、ＵＥのアップリンクおよびダウンリンクのトラフィックが十分でないこと、ＵＥへのデータ伝送の低下、セル内のＵＥの位置、および遷移が発生する可能性、のうちの１つ以上を含むことができる。

ブロック４１２において、事前条件が存在するという決定が行われた場合、プロセスはブロック４２０に進み、ここで、長期ＤＲＸ ＭＡＣ ＣＥがＵＥに送信される。

逆に、ブロック４１２の事前条件が存在しない場合、プロセスはブロック４３０に進み、ここでは短期ＤＲＸ期間が維持され、プロセスはブロック４１２に戻る。

（短期ＤＲＸタイマーの停止）
ＵＥの観点から、ここで図４ｂを参照する。図４ｂのプロセスは、ブロック４５０で開始し、ブロック４５２に進み、ここで、短期ＤＲＸサイクルが構成されているかどうかを決定するために確認が行われる。構成されていない場合は、プロセスはブロック４６０に進み、ここで、長期ＤＲＸサイクルが使用される。

反対に、ブロック４５２で、短期ＤＲＸサイクルが構成されていると決定された場合、プロセスはブロック４７０に進み、ここで、ＤＲＸ ＭＡＣ ＣＥコマンドが受信されたかどうかを決定するために確認が行われる。

ブロック４７０から、ＤＲＸ ＭＡＣ ＣＥコマンドが受信されていた場合、プロセスはブロック４７２に進み、ここで、短期ＤＲＸタイマーが開始されたかどうかの確認が行われる。開始されていた場合は、プロセスはブロック４７３に進み、ここで、短期ＤＲＸタイマーが停止される。理解されるように、これによって、短期ＤＲＸサイクルがタイマーの期限切れ時に開始することを回避する。

プロセスはブロック４７６に進み、ここで、長期ＤＲＸサイクルが使用される。

逆に、ブロック４７２で短期ＤＲＸタイマーが開始されていないと決定された場合、プロセスはブロック４７６に直接進み、長期ＤＲＸサイクルを使用する。

（短期ＤＲＸタイマーの再開）
代替として、ブロック４７３で短期ＤＲＸサイクルタイマーを停止する代わりに、他のオプションが利用可能である。第１は、ＤＲＸの短期サイクルタイマーを再開することである。

ここで図４ｃを参照する。図４ｃでは、図４ｂのブロック４７３が図４ｃではブロック４７４に置換されていることを除き、図４ｂと同じブロックが実施される。ブロック４７４は、短期ＤＲＸタイマーを再開する。当業者によって理解されるように、これは、ＤＲＸ ＭＡＣ ＣＥの受信時にＤＲＸの短期サイクルタイマーが既に開始されていた場合、短期ＤＲＸの継続期間が延長されるという状況を実現する。この場合、長期ＤＲＸサイクルは、短期ＤＲＸタイマーの有効期限まで、遷移されない。
ブロック４７４から、プロセスはブロック４８０に進み、終了する。

（短期ＤＲＸタイマーの維持）
さらなる代替のオプションは、現在のＤＲＸの短期サイクルタイマーを保持することである。

この場合、短期ＤＲＸサイクルの持続時間は、ＤＲＸ ＭＡＣ ＣＥの受信に関わらず、変更されない。

ここで図４ｄを参照すると、図４ｂのブロック４７３がブロック４７５に置換されている。ブロック４７５において、プロセスは現在の短期ＤＲＸタイマーを維持する。これは、現在のＤＲＸ遷移時間を、短期ＤＲＸサイクルから長期ＤＲＸサイクルに保持する。ブロック４７５から、プロセスはブロック４８０に進み、終了する。

この実施形態では、ＤＲＸの短期サイクルタイマーが終了すると、ＵＥは長期ＤＲＸサイクルへ遷移する。

このように、上記の３つの実施形態は、ＤＲＸの短期サイクルタイマーを再開することによって、現在のＤＲＸの短期サイクルタイマーを維持することによって現在のＤＲＸの短期サイクル期間を維持することによって、またはＤＲＸの短期サイクルタイマーを停止することによって長期ＤＲＸに直ちに遷移することによって、短期ＤＲＸのサイクル期間を延長するオプションを提示した。電池の観点およびネットワーク発信の観点からは、現在のＤＲＸの短期サイクルタイマーの維持、または長期ＤＲＸへの直接遷移が好ましい。ＤＲＸの短期サイクルタイマーを再開して、短期ＤＲＸ期間を延長すると、長期ＤＲＸのＵＥよりも多くの電池およびネットワークリソースを利用する。

ブロック４７６から、プロセスはブロック４８０に進み、終了する。

ブロック４７０から、ＤＲＸ ＭＡＣ ＣＥが受信されていない場合、プロセスはブロック４９０に進み、ここで、短期ＤＲＸタイマーが開始される。プロセスは、次にブロック４９２に進み、ここで、ＵＥは短期ＤＲＸ期間またはサイクルを使用する。短期ＤＲＸタイマーの使用によって、ＵＥは、タイマーの期限が終了した後、タイマー期間にデータが受信または送信されない場合、長期ＤＲＸサイクルに遷移することが可能になる。

ブロック４９２から、プロセスはブロック４８０に進み、終了する。

上記は、非常に低いトラフィックがｅＮＢによって監視される場合、電池の消費およびネットワークリソースを節約する。ソリューションは、ＲＲＣレベルの再構成メッセージを送信することよって、長期ＤＲＸサイクルへ遷移する、より効率的な方式を提供する。

（ＤＲＸ再送タイマー）
ＤＲＸの制御のためのさらなる問題は、再送タイマーに関する。３ＧＰＰ ＴＳ ３６．３２１に示されているように、ＤＲＸ再送タイマーは、ＵＥによって予想されるダウンリンク再送のタイミングに関して、ＵＥがパケットデータ制御チャネル（ＰＤＣＣＨ）を監視することになる、連続的なダウンリンクサブフレームの最大回数を指定する。パケットの受信に問題があり、パケットの再送が要求される状況において、利用される。

再送を待機する間、ＵＥがこの時間にその無線を切断する能力を可能にするように、ＨＡＲＱ往復遅延時間（ＲＴＴ）タイマーが利用される。ＨＡＲＱ ＲＴＴタイマーは、パラメータで、ダウンリンクＨＡＲＱ再送がＵＥによって予想される前のサブフレームの最低量を指定する。

一実施形態において、本明細書においては再送カウンタと呼ばれる、カウンタが、再送タイマーがＵＥによって開始または停止される回数をカウントする。

３ＧＰＰ標準における不連続受信の現在の機能は、以下を含む。
ＤＲＸサイクルが構成されていた場合、ＵＥは、各ダウンリンクサブフレームに対して、
ＨＡＲＱ ＲＴＴタイマーがこのダウンリンクサブフレームで有効期限切れになり、対応するＨＡＲＱプロセスのソフトオファーのデータが、問題なくデコードされなかった場合、
ＵＥは、対応するＨＡＲＰプロセスのＤＲＸ再送を開始する。

標準は、ＤＲＸ再送タイマーが停止されることをさらに指定する。
ＰＤＣＣＨがＤＬ伝送を示す場合、
対応するＨＡＲＱプロセスのＨＡＲＱ ＲＴＴタイマーを開始する。
対応するＨＡＲＱプロセスのＤＲＸ再送タイマーを停止する。
上記に関する１つの問題は、この状況において、伝送または再送の最大回数に到達すると、ＭＡＣ ＰＤＵが問題なくデコードされないことである。再送の最大回数に到達したため、ｅＮＢは別の再送を送信することはないが、ＵＥはまだ再送を受信することを予想することになる。この場合、ＤＲＸ再送タイマーが開始されるが、伝送の最大数に到達しているため、再送は送信されず、対応するＨＡＲＱプロセスの再送タイマーは、同じＨＡＲＰプロセスを使用している他の新しい伝送が、ＰＤＣＣＨ上で示されるまで、またはタイマーの有効期限が切れるまで、停止されることはない。ＵＥは、何も受信しなくても、追加の再送ウィンドウを起動することができる。この結果、所与の場合において、所与のＨＡＲＱプロセスのＤＲＸ再送タイマーは、不必要に実行されている可能性があり、これによって、ＵＥに、ＰＤＣＣＨを不必要に連続して監視させ、さらに、ＵＥに、サウンディング基準信号（ＳＲＳ）およびチャネル品質インジケータ（ＣＱＩ）、ならびにより効率的なダウンリンク伝送を促進する他のフィードバックをアップリンクで不必要に伝送させることになる。

（ＤＲＸ ＭＡＣ ＣＥをＵＥに送信）
上記に対する多様なソリューションが可能である。第１のソリューションにおいて、ネットワークは、ＤＲＸ ＭＡＣ制御要素をＵＥに送信することができる。

ＤＲＸ ＭＡＣ ＣＥの受信によって、継続期間内タイマーおよび非活動タイマーが停止されることになる。これは、再送タイマーを停止することにも拡張され得る。

当業者によって理解されるように、再送タイマーを停止するには、ＨＡＲＱプロセスを識別することが必要である。一実施形態において、これは、ＤＲＸ ＭＡＣ ＣＥ内にオプションのフィールドを含めることによって実行され得る。例えば、ＤＲＸ ＭＡＣ ＣＥに、３ビットのＨＡＲＱプロセス識別子フィールドが含まれ得る。

代替の実施形態において、ＵＥは、最大回数の再送タイマー、または伝送の最大回数を有するＨＡＲＱプロセスを停止することが可能である。

ここで図５ａを参照する。図５は、ＤＲＸ ＭＡＣ ＣＥを送信するために使用されるネットワーク側のブロックの流れ図を示す。プロセスはブロック５１０で開始し、ここでは再試行の最大回数が発生したという事前条件が存在する。

プロセスは次にブロック５１２に進み、ここで、ＤＲＸ ＭＡＣ ＣＥはＵＥに送信される。

任意選択的に、プロセスはブロック５１４に進み、ブロック５１２で送信されたＤＲＸ ＭＡＣ ＣＥは、ＨＡＲＱプロセス識別子を含むように変更される。

プロセスは次にブロック５２０に進み、終了する。

図５ｂを参照すると、この図は、再送タイマーを停止するためのＵＥ側の機能を示す。プロセスはブロック５３０で開始し、ブロック５３２に進み、ここで、ＤＲＸ ＭＡＣ ＣＥは、ＵＥで受信される。

ＤＲＸ ＭＡＣ ＣＥが、ＨＡＲＱプロセス識別子を有するオプションの拡張を含む場合、プロセスは、ブロック５３２からブロック５３４に進み、ここで、ＨＡＲＱプロセス識別子は、ＤＲＸ ＭＡＣ ＣＥから読み取られる。

逆に、プロセス識別子のオプションのフィールドがＤＲＸ ＭＡＣ ＣＥに存在しない場合、プロセスはブロック５３６に進み、ここで、プロセスは、伝送の最大回数を有するＨＡＲＱプロセス、または最大値を有する再送タイマーを識別する。このように、ブロック５３４または５３６は、停止される、または開始を防止される、再送タイマーを識別する。

ブロック５３４または５３６から、プロセスはブロック５４０に進み、ここで、ブロック５３４または５３６で識別されたプロセスの再送タイマーが停止または開始を防止される。

プロセスは次にブロック５５０に進み、終了する。

当業者によって理解されるように、上記は、ＤＲＸ ＭＡＣ ＣＥをＵＥに提供して、再送タイマーが開始されてはならないこと、または停止されるべきことを示すことによって、再試行の最大回数後、再送タイマーが実行されることを防止する。

（最大ダウンリンク再試行値の提供）
さらなるオプションとして、ネットワークは、ＵＥへのダウンリンク伝送の最大回数を発信することができる。この場合、したがって、ＵＥは、再送タイマーを停止または開始を防止するタイミングを認識する。

ここで図６ａを参照する。図６ａは、ＵＥへのダウンリンク伝送の最大回数を発信するための、ネットワーク側の流れ図を示す。

図６ａのプロセスは、ブロック６１０で開始し、ブロック６１２に進み、ここで、ダウンリンク伝送の最大回数はＵＥに発信される。当業者によって理解されるように、再送の最大回数は、半永久または「構成された」場合のサービス品質（ＱｏＳ）等の因子に基づいて、変わり得る。プロセスは次にブロック６１４に進み、終了する。

図６ｂを参照すると、この図はＵＥ側のプロセスを示す。
プロセスはブロック６２０で開始し、ブロック６２２に進み、ここでは、ＵＥは、ネットワークから可能なダウンリンク伝送の最大回数を受信および格納する。

通信は正常に進み、最終的にブロック６２４に到達し、ここでは、ＨＡＲＱプロセスが問題なくデコードされたかどうかを決定するための確認が行われる。問題ない場合、プロセスはブロック６３０に進み、終了する。代替として、プロセスは、引き続き、ＨＡＲＱプロセスを受信してデコードする可能性がある。

ブロック６２４において、ＨＡＲＱプロセスが問題なくデコードされていないと決定された場合、プロセスはブロック６４０に進み、そのプロセスのダウンリンク伝送の最大回数に到達したかどうかを確認する。これは、上記のように再送カウンタを利用して、発生した再送の回数を決定することによって、実行され得る。到達していた場合、プロセスはブロック６３０に進み、終了する。

逆に、ブロック６４０でダウンリンク伝送の最大回数に到達していないと決定された場合、プロセスはブロック６４２に進み、現在の基準に応じて再送タイマーが開始される。

上記は、したがって、再送がそれ以上発生しない場合、再送タイマーの開始を防止する。

（有効期限再試行値の提供）
さらなるオプションとして、ネットワークは、満了値をＵＥに発信し、ＵＥが指定のＨＡＲＱプロセスに対して再送タイマーを開始することができる回数を発信することができる。満了値は、再送カウンタに関連し、再送カウンタは、再送タイマーが開始された回数をカウントする。この場合、したがって、ＵＥは、再送タイマーを停止または開始を防止するタイミングを認識する。

当業者によって理解されるように、満了値は、ネットワークによって設定され得る。このため、ネットワーク運用者は、ボイスオーバーインターネットプロトコル等の所与のサービスに対して、所与の回数よりも多く再送タイマーを開始すると、ユーザ体験の悪化につながると判断することができ、このため、再送タイマーが開始する回数を制限する満了値を設定することができる。

一実施形態において、有効期限再試行値は、最大のダウンリンク再試行値よりも小さい。

ここで図７ａを参照する。図７ａは、満了値をＵＥに発信するための、ネットワーク側の流れ図を示す。一実施形態において、異なる満了値は、異なるタイプのＨＡＲＱプロセスに対して設定され得る。

図７ａのプロセスは、ブロック７１０で開始し、ブロック７１２に進み、ここで、満了値はＵＥに発信される。プロセスは次にブロック７１４に進み、終了する。

図７ｂを参照すると、この図はＵＥ側のプロセスを示す。
プロセスはブロック７２０で開始し、ブロック７２２に進み、ここで、ＵＥは、ネットワークから満了値を受信および格納する。

通信は正常に進み、最終的にブロック７２４に到達し、ここで、ＨＡＲＱプロセスが問題なくデコードされたかどうかを決定するための確認が行われる。デコードされていた場合、プロセスはブロック７３０に進み、終了する。代替として、プロセスは、引き続き、ＨＡＲＱプロセスを受信し、デコードすることができる。

ブロック７２４において、ＨＡＲＱプロセスが問題なくデコードされていないと決定された場合、プロセスはブロック７４０に進み、その再送の回数がＨＡＲＱプロセスの満了値以上であるかどうかを確認する。これは、上記のように再送カウンタを利用して、発生した再送の回数を決定することによって、実行され得る。満了値以上であった場合、プロセスはブロック７３０に進み、終了する。

逆に、再送回数が、ＨＡＲＱプロセスの満了値以上ではないとブロック７４０で決定された場合、プロセスはブロック７４２に進み、再送タイマーは、現在の基準に応じて開始される。

上記は、したがって、満了値に到達していた場合、再送タイマーの開始を防止する。

（特定の冗長バージョン番号の提供）
さらなるオプションとして、ダウンリンク送信の最大回数を発信する代わりに、ＵＥには、ＵＥがネットワークからの最後の再送がいつであったかを認識するように、最後の再送に関連する特定の冗長バージョン番号が発信され得る。

ここで図８ａを参照する。図８ａは、最後の再送に関連する特定の冗長バージョン番号を発信するためのネットワーク観点からのプロセスを示す。プロセスは、ブロック８１０で開始し、ブロック８１１に進み、ここで、特定の冗長バージョン番号がＵＥへ発信される。プロセスは次にブロック８１４に進み、終了する。

ＵＥの観点から、ここで図８ｂを参照する。
ＵＥ側の図８ｂはブロック８２０で開始し、ブロック８２２に進み、ここで、ＵＥは、冗長バージョン番号を受信および格納する。

次にプロセスは進み、ＨＡＲＱプロセスのデコードを開始する。ブロック８２４で、特定のＨＡＲＱプロセスが問題なくデコードされたかどうかを決定するための確認が行われる。問題なくデコードされた場合、プロセスはブロック８３０に進み、終了する。

逆に、ブロック８２４から、ＨＡＲＱプロセスが問題なくデコードされていなかった場合、プロセスはブロック８４０に進み、ここで、最後のＨＡＲＱプロセスが、ブロック８２２で受信された特定の冗長バージョン番号に一致する、冗長バージョン番号を有するかどうかを決定するための確認が行われる。一致する場合、プロセスはブロック８５０に進み、終了する。逆に、プロセスはブロック８４２に進み、再送タイマーを開始する。ここでも、これは、さらなる再送が予想されない場合、再送タイマーの開始を防止する。

上記の多様なオプションは、他のオプションに対する利点を提示する。再送タイマーに満了値を設定することは容易に実装され、最低限の発信を必要とする。

逆に、ＤＲＸ ＭＡＣ ＣＥの送信は、再送タイマーの開始を防止するが、さらなる発信を必要とする。同様に、ダウンリンク再送の最大回数または特定の冗長バージョン番号を格納することによって、再送タイマーが不必要に開始することを防止する。

上記は、任意のＵＥ上において実装され得る。このようなＵＥは、特に、パーソナルデジタル機器、セルラ電話、ワイヤレスデータ端末を含むが、これらに限定されない。ここで図９を参照する。

ＵＥ９００は、少なくとも音声およびデータ通信機能を有する双方向ワイヤレス通信端末であることが好ましい。ＵＥ９００は、インターネット上で他のコンピュータシステムと通信する機能を有することが好ましい。提供される正確な機能に応じて、ワイヤレス端末は、例えば、データメッセージング端末、双方向ポケットベル、ワイヤレス電子メール端末、データメッセージング機能を備えるセルラ電話、ワイヤレスインターネット端末、またはデータ通信端末と称され得る。

ＵＥ９００の双方向通信が可能な場合、受信器９１２および伝送器９１４の両方を含む、通信サブシステム９１１、ならびに１つ以上の、埋め込み型または内蔵型であることが好ましい、アンテナ要素９１６および９１８、局部発振器（ＬＯ）９１３、およびデジタル信号プロセッサ（ＤＳＰ）９２０等の処理モジュールを組み込む。通信分野の当業者には明らかであるように、通信サブシステム９１１の特定の設計は、端末の操作が予定される通信ネットワークに依存する。例えば、ＵＥ９００は、ＬＴＥネットワーク内で運用するように設計される、通信サブシステム９１１を含む場合がある。

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

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

ネットワーク９１９は、さらに、サーバ９６０および他の要素（表示せず）を含む、複数のシステムと通信することができる。例えば、ネットワーク９１９は、多様なクライアントに多様なサービスレベルで対応するために、エンタープライズシステムおよびウェブクライアントシステムの両方と通信する場合がある。

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

図９に示されたサブシステムの一部は、通信関連機能を実施し、他のサブシステムは、「居住」または端末上の機能を提供することができる。特に、例えば、キーボード９３２およびディスプレイ９２２等の一部のサブシステムは、通信ネットワーク上に伝送するためのテキストメッセージの入力等の通信関連システム、および計算機またはタスクリスト等の端末上の機能の両方のために使用されてもよい。

マイクロプロセッサ９３８によって使用されるオペレーティングソフトウェアは、フラッシュメモリ９２４等の永久的ストレージに格納されることが好ましいが、代わりに、読み取り専用メモリ（ＲＯＭ）または同様なストレージ要素（表示せず）であってもよい。当業者は、オペレーティングシステム、特定の端末アプリケーション、またはこれらの一部が、ＲＡＭ９２６等の揮発性メモリに一時的にロードされる場合があることを理解するであろう。受信された通信信号もＲＡＭ９２６に格納されてもよい。さらに、一意の識別子も読み取り専用メモリに格納されることが好ましい。

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

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

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

図９のシリアルポート９３０は、通常、ユーザのデスクトップ型コンピュータ（表示せず）との同期が所望される場合、パーソナルデジタル機器（ＰＤＡ）のようなモバイルデバイスに実装される。このようなポート９３０によって、ユーザは、外部の端末またはソフトウェアを介して、詳細を設定することが可能になり、ワイヤレス通信ネットワークを介する以外に、ＵＥ９００に情報またはソフトウェアのダウンロードを提供することによって、モバイルデバイス９００の機能を拡張することになる。代替のダウンロードパスは、例えば、直接的、従って信頼性が高く、トラストされる接続を介して、端末に暗号キーをロードするために使用される場合があり、これによって、安全な端末通信を可能にする。

代替として、シリアルポート９３０は、他の通信のために使用され得て、ユニバーサルシリアルバス（ＵＳＢ）ポートとして含まれ得る。インターフェースは、シリアルポート９３０に関連付けられる。

短距離通信サブシステム等の他の通信サブシステム９４０は、ＵＥ９００と、必ずしも同様な端末である必要はない、異種のシステムまたは端末との間の通信を提供することができる、さらなるオプションの構成要素である。例えば、サブシステム９４０は、同様に有効なシステムおよび端末との通信を提供するために、赤外線端末および関連回路ならびに構成要素、またはＢｌｕｅｔｏｏｔｈ（登録商標）通信モジュールを含む場合がある。

ここで図１０を参照する。図１０は、上記の図３ａ、４ａ、５ａ、６ａ、７ａおよび８ａに示された決定を行うように適合される、簡素化されたネットワーク要素を示す。ネットワーク要素１０１０は、ユーザ機器と通信するように適用された通信サブシステム１０２０を含む。当業者によって理解されるように、通信サブシステム１０２０は、ユーザ機器と直接通信する必要はないが、ユーザ機器との通信のための通信パスの一部であり得る。

ネットワーク要素１０１０は、プロセッサ１０３０と、ストレージ１０４０と、をさらに含む。ストレージ１０４０は、ネットワーク要素１０１０によってサービスされている各ユーザ機器のための情報を格納するように適合される。プロセッサ１０３０は、通信サブシステム１９２０によって、再試行の最大回数、最大冗長バージョン、ＤＲＸ ＭＡＣ ＣＥ、または満了値等の情報を提供するように適合される。

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

Claims (18)

1. 短期不連続受信「ＤＲＸ」タイマーを制御する方法であって、
   媒体アクセス制御の制御要素が受信されているかどうかと、短期ＤＲＸサイクルが構成されているかどうかとを確認することと、
   該確認に応答して、該短期ＤＲＸタイマーを停止することと、
   長期ＤＲＸサイクルを利用することと
   を含む、方法。
2. 短期不連続受信「ＤＲＸ」タイマーを制御する方法であって、
   媒体アクセス制御の制御要素が受信されているかどうかと、短期ＤＲＸサイクルが構成されているかどうかとを確認することと、
   該確認に応答して、該短期ＤＲＸタイマーを再開することと
   を含む、方法。
3. 短期不連続受信「ＤＲＸ」タイマーを制御する方法であって、
   媒体アクセス制御の制御要素が受信されているかどうかと、短期ＤＲＸサイクルが構成されているかどうかとを確認することと、
   該確認に応答して、該短期ＤＲＸタイマーを維持することと
   を含む、方法。
4. 短期不連続受信「ＤＲＸ」タイマーを制御するためのユーザ機器であって、
   ネットワーク要素と通信するように、さらに、媒体アクセス制御の制御要素を受信するように適合されている、通信サブシステムと、
   プロセッサであって、該プロセッサは、該媒体アクセス制御の制御要素が受信されているかどうかと、短期ＤＲＸサイクルが構成されているかどうかとを確認することと、該確認に応答して、該短期ＤＲＸタイマーを停止し、該ユーザ機器を長期ＤＲＸサイクルへ遷移することとを行うように適合されている、プロセッサと
   を備えている、ユーザ機器。
5. 短期不連続受信「ＤＲＸ」タイマーを制御するためのユーザ機器であって、
   ネットワーク要素と通信するように、さらに媒体アクセス制御の制御要素を受信するように適合されている、通信サブシステムと、
   プロセッサであって、該プロセッサは、該媒体アクセス制御の制御要素が受信されているかどうかと、短期ＤＲＸサイクルが構成されているかどうかとを確認することと、該確認に応答して、該短期ＤＲＸタイマーを再開することとを行うように適合されている、プロセッサと
   を備えている、ユーザ機器。
6. 短期不連続受信「ＤＲＸ」タイマーを制御するためのユーザ機器であって、
   ネットワーク要素と通信するように、さらに媒体アクセス制御の制御要素を受信するように適合される、通信サブシステムと、
   プロセッサであって、該プロセッサは、該媒体アクセス制御の制御要素が受信されているかどうかと、短期ＤＲＸサイクルが構成されているかどうかとを確認し、該確認に応答して、該短期ＤＲＸタイマーを維持することとを行うように適合される、プロセッサと
   を備えている、ユーザ機器。
7. 再送タイマーが開始することを防止する方法であって、
   ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の最大回数の値を受信することと、
   該ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の該回数が該値以上であるかどうかを確認することと、
   該確認に応答して、該再送タイマーが開始することを防止することと
   を含む、方法。
8. 再送タイマーが開始することを防止する方法であって、
   特定の冗長バージョンの値を受信することと、
   該ハイブリッド確認応答要求プロセスの該冗長バージョンが該値に等しいかどうかを確認することと、
   該確認に応答して、該再送タイマーが開始することを防止することと
   を含む、方法。
9. 再送タイマーが開始することを防止する方法であって、
   ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の回数の満了値を受信することと、
   該ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の該回数が該満了値以上であるかどうかを確認することと、
   該確認に応答して、該再送タイマーが開始することを防止することと
   を含む、方法。
10. 再送タイマーの持続時間を制限するか、または該再送タイマーの開始を防止する方法であって、
    不連続受信媒体アクセス制御の制御要素を受信することと、
    該不連続受信媒体アクセス制御の制御要素に対応するハイブリッド確認応答要求プロセスを識別することと、
    該ハイブリッド確認応答要求プロセスのための該再送タイマーの開始を防止するか、または該再送タイマーを停止することと
    を含む、方法。
11. 前記識別することは、前記不連続受信媒体アクセス制御の制御要素内のプロセス識別子を利用する、請求項１０に記載の方法。
12. 前記識別することは、伝送の最大回数を有する前記ハイブリッド確認応答要求プロセス、または最大値を有する前記再送タイマーを選択する、請求項１０に記載の方法。
13. 再送タイマーが開始することを防止するように適合される、ユーザ機器であって、
    ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の最大回数の値を受信するように適合される、通信サブシステムと、
    該ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の該回数が該値以上であるかどうかを確認し、該確認に応答して、該再送タイマーが開始することを防止するように適合されている、プロセッサと
    を備えている、ユーザ機器。
14. 再送タイマーが開始することを防止するように適合されているユーザ機器であって、
    特定の冗長バージョンの値を受信するように適合されている通信サブシステムと、
    該ハイブリッド確認応答要求プロセスの該冗長バージョンが該値以上であるかどうかを確認することと、該確認に応答して、該再送タイマーが開始することを防止することとを行うように適合されている、プロセッサと
    を備えている、ユーザ機器。
15. 再送タイマーが開始することを防止するように適合されているユーザ機器であって、
    ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の回数の満了値を受信するように適合されている、通信サブシステムと、
    該ハイブリッド確認応答要求プロセスのためのダウンリンク伝送の該回数が該満了値以上であるかどうかを確認することと、該確認に応答して、該再送タイマーが開始することを防止することとを行うように適合されている、プロセッサと
    を備えている、ユーザ機器。
16. 再伝送タイマーの持続時間を制限するように、または該再伝送タイマーの開始を防止するように適合されているユーザ機器であって、
    不連続受信媒体アクセス制御の制御要素を受信するように適合されている通信サブシステムと、
    該不連続受信媒体アクセス制御の制御要素に対応するハイブリッド確認応答要求プロセスを識別するように適合されているプロセッサであって、該プロセッサは、該ハイブリッド確認応答要求プロセスのための該再送タイマーの開始を防止するように、または該再送タイマーを停止するようにさらに適合されている、プロセッサと
    を備えている、ユーザ機器。
17. 前記プロセッサは、前記ハイブリッド確認応答要求プロセスを識別するように、前記不連続受信媒体アクセス制御の制御要素内のプロセス識別子を利用する、請求項１６に記載のユーザ機器。
18. 前記プロセッサは、伝送の最大回数を有する前記ハイブリッド確認応答要求プロセス、または該ハイブリッド確認応答要求プロセスを識別する最大値を有する前記再送タイマーを選択する、請求項１６に記載の方法。

Images