ＬＴＥ＿ＡＣＴＩＶＥにおけるＤＲＸタイミング非同期から回復する方法およびシステム
【課題】ＬＴＥ＿ＡＣＴＩＶＥ状態におけるＵＥとｅＮＢとの間の不連続受信（ＤＲＸ）タイミング非同期から回復する方法を提供すること。
【解決手段】ＬＴＥ＿ＡＣＴＩＶＥ状態におけるＵＥとｅＮＢとの間の不連続受信（ＤＲＸ）タイミング非同期から回復する方法であって、該方法は、ｅＮＢがＤＲＸタイミング非同期を検出するステップと、連続受信を再開するためにユーザ装置（ＵＥ）にインディケータを送信するステップと、連続受信応答かまたは連続受信通知が受信されたかどうかの指示をＵＥから待つステップとを有する。
【解決手段】ＬＴＥ＿ＡＣＴＩＶＥ状態におけるＵＥとｅＮＢとの間の不連続受信（ＤＲＸ）タイミング非同期から回復する方法であって、該方法は、ｅＮＢがＤＲＸタイミング非同期を検出するステップと、連続受信を再開するためにユーザ装置（ＵＥ）にインディケータを送信するステップと、連続受信応答かまたは連続受信通知が受信されたかどうかの指示をＵＥから待つステップとを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、概して第３世代パートナーシッププロジェクト（３ＧＰＰ）のロングタームエボリューション（ＬＴＥ）に関し、特にＬＴＥ＿ＡＣＴＩＶＥ状態におけるＤＲＸタイミング非同期に関する。
【背景技術】
【０００２】
ロングタームエボリューション（ｌｏｎｇ−ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）インフラストラクチャにおいて、ＵＥは２つの無線資源制御（ＲＲＣ）状態のうちの１つであり得る。これらは、ＬＴＥ＿ＩＤＬＥおよびＬＴＥ＿ＡＣＴＩＶＥである。
【０００３】
ＵＥは、ＬＴＥ＿ＩＤＬＥ状態およびＬＴＥ＿ＡＣＴＩＶＥ状態の両方において不連続受信（ＤＲＸ）するように構成され得る。ＬＴＥ＿ＩＤＬＥ状態において、ＤＲＸは、ＵＥがその聴取期間をネットワークの公知のパージングサイクルに同期させることを可能にする。聴取期間を同期させることによって、ＵＥは、スタンバイ期間中、その無線トランシーバの電源を切り、それによって電池資源を実質的に節約し得る。ＤＲＸパラメータは、モバイルがネットワークと同期すること、および所定の時間が経過するまでモバイルが別の信号を受信しないということを知ることを可能にする。
【０００４】
ＵＥがＬＴＥ＿ＡＣＴＩＶＥ状態であるときもＤＲＸが使用されるようにすべきということが３ＧＰＰ ＴＳＧ−ＲＡＮワーキンググループにおいて提案される。ＬＴＥ＿ＡＣＴＩＶＥ状態のユーザ装置（ＵＥ）による不連続受信（ＤＲＸ）であるとき、正規ＤＲＸ構成は、無線資源制御（ＲＲＣ）プロトコルメッセージによって信号を送られ、一時ＤＲＸ（再）構成は、例えばＭＡＣプロトコルデータユニット（ＭＡＣ−ＰＤＵ）ヘッダまたはＭＡＣ制御ＰＤＵにおいて、媒体アクセス制御（ＭＡＣ）信号によって信号を送られることがさらに提案される。
【０００５】
ＬＴＥにおいて、ユーザデータがダウンリンク共用チャネルで送られる前に、ｅＮＢは、ダウンリンク共用制御チャネル（ＤＬＳＣＣＨ）でスケジューリング指示を送り、ＵＥがデータを復調するために用いるパラメータを提供する。しかしながら、ＵＥがＤＬＳＣＣＨスケジューリング指示を見のがした場合、ＵＥはユーザデータを受信したことを知らず、従ってＵＥは、ユーザＭＡＣ−ＰＤＵを肯定応答（ＡＣＫ）するかまたは否定的応答（ＮＡＣＫ）することを知らない。ｅＮＢは、ＡＣＫまたはＮＡＣＫ、すなわちハイブリッドＡＲＱ（ＨＡＲＱ）応答を待つ。ｅＮＢがその応答を得ないとき、それは不連続送信（ＤＴＸ）と見なされる。ダウンリンク共用制御チャネル（ＤＬＳＣＣＨ）でのデータ指示がＵＥによって見のがされ、ＨＡＲＱフィードバックチャネルでの後の不連続送信（ＤＴＸ）が強化型ノードＢ（ｅＮＢ）によってＡＣＫとして誤って解釈された場合、ＭＡＣ−ＰＤＵが失われ得る。さらに、ＵＥが、規則例えばある持続期間データ活動なし、に従って、ＤＲＸ長を自動的に増加させた場合、ＵＥがそれ自身のＤＲＸ値を増加させながら、ｅＮＢはその現在のＤＲＸ値を維持する。これは、ＤＲＸタイミング非同期という結果になり、すなわちｅＮＢおよびＵＥは異なるＤＲＸ期間で動作している。
【０００６】
理解されるように、このことは、ダウンリンクメッセージ送達の待ち時間を増加させ、ダウンリンク無線資源を浪費する。より長い送達待ち時間は、特に重大なダウンリンク制御メッセージに関して、回避されるべきである。一旦ＤＲＸタイミング非同期が起こると、ｅＮＢは、新しいデータをＵＥに送るためにＵＥ ＤＲＸタイミングを決定しなければならない。ＵＥがおそらくウェイクアップしているであろうことをｅＮＢが知っているとき、それらの時間に様々なプロービングメッセージ（ｐｒｏｂｉｎｇ ｍｅｓｓａｇｅ）を送ることによって、ｅＮＢはこのＵＥ ＤＲＸタイミングを決定する。いくつかの試みの後に、ｅＮＢはＵＥ ＤＲＸタイミングを見つけ、同期を回復させるためにＵＥをウェイクアップさせる。
【発明の概要】
【課題を解決するための手段】
【０００７】
（概要）
ＵＥがＬＴＥ＿ＡＣＴＩＶＥであり、ＤＲＸが活動化されている場合、ダウンリンクデータの到着時、ｅＮＢは、ＤＬＳＣＣＨ上のスケジューリング指示を送信し得、ＵＥがウェイクアップしているときにＤＬ−ＳＣＨ上のＭＡＣ−ＰＤＵを送信する。ｅＮＢがＵＥからどのハイブリッドの自動繰り返し要求（ＨＡＲＱ）フィードバック信号も得ない場合、ｅＮＢは、ＵＥがＤＲＸタイミングにおいて同期がずれていると考え得る。そのような状態から回復するために、２つの方法が下記に説明される。
【０００８】
第１の方法は、システム情報におけるＤＲＸタイミング非同期化の指示であり得る。特に、ＤＲＸタイミングにおいてＵＥの同期がずれていることをｅＮＢが検出したとき、所定のシステム情報ブロックにおいてＵＥの無線ネットワーク一時識別子（ＲＮＴＩ）を同報通信し得る。ＵＥがウェイクアップするとき、ＵＥは、システム情報ブロックを読み取り得る。ＵＥのＲＮＴＩが指示された場合、ＵＥは、ＤＲＸモードを非活動化し得、ｅＮＢへのＬ１／Ｌ２の信号方式またはＭＡＣ信号方式を用いて連続受信通知メッセージを送信する。連続受信通知メッセージの受信次第、ｅＮＢはそのバッファ内で待つデータをＵＥに再送信する。データが肯定応答されるか、またはＵＥからのＨＡＲＱフィードバックが受信されたとき、ｅＮＢはシステム情報からＲＮＴＩを除去し得る。
【０００９】
さらなる実施形態において、ＤＲＸ非同期化から回復する方法は、絶対ウェイクアップ時間を事前に構成することであり得る。特に、会話形通信もしくは背景通信のための無線ベアラ（ｒａｄｉｏ ｂｅａｒｅｒ）が設定されたときまたはそのベアラにおいてＤＲＸが活動化されたとき、絶対ウェイクアップ時間がＲＲＣによってＵＥに通知され得る。絶対ウェイクアップタイミングは、システム無線フレームタイミングに対する無線フレームオフセット（ＡＲＦｏｆｆ）およびＤＲＸ間隔（ＡＩｎｔ）によって定義され得る。現在のＤＲＸ設定に関わらず、ＵＥはＡＲＦｏｆｆ＋Ｎ＊ＡＩｎｔの無線フレームにおいてウェイクアップしなければならない。ここで、Ｎ＝０、１、・・・である。ｅＮＢが２．５６秒内の回復を保証することを望む場合、ＡＩｎｔは２．５６秒に設定され得る。
【００１０】
ＤＲＸタイミングにおいてＵＥの同期がずれていることをｅＮＢが検出したとき、ｅＮＢは、Ｌ１／Ｌ２信号方式またはＭＡＣ信号方式における連続受信コマンド（すなわち、ＤＲＸ非同期化）を絶対ウェイクアップ時間にＵＥに送る。ＵＥが絶対ウェイクアップ時間にウェイクアップしたとき、ＵＥは連続受信コマンドが受信されたか否かをチェックし得る。受信された場合、ＵＥはトランシーバの電源を入れ、連続受信に戻り、アップリンク同期化および必要に応じスケジューリング認可を得、連続受信応答をｅＮＢに送る。連続受信応答を受領次第、ｅＮＢはそのバッファ内のデータをＵＥに送信し得る。
【００１１】
ＵＥがアップリンク同期を再調整することをｅＮＢが望む場合、ｅＮＢはＬ１／Ｌ２信号方式チャネルを介して連続受信コマンドを送り得、該連続受信コマンドは、アップリンク同期が再調整されるべきであるという指示および連続受信応答に対して割り当てられた専用のアップリンク資源に関する情報を含む。そのような連続受信コマンドの受信次第、ＵＥはアップリンクタイミングを再調整し得、連続受信コマンドにおいて指示された資源を用いて連続受信コマンドを送ることによって応答する。
【００１２】
さらなる代替の実施形態において、絶対ウェイクアップ無線フレームオフセットは、３ＧＰＰ ＴＳ２５．３０４に説明されるＵＭＴＳにおいてページング機会が計算される方法と類似する方法で、ＩＭＳＩ（国際モバイルステーションアイデンティティ）などのＵＥアイデンティティから計算され得る。この場合において、ＤＲＸ間隔は、専用のＲＲＣメッセージを介して信号を送られるよりはむしろシステム情報に含まれ得る。
【００１３】
従って本開示は、ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信（ＤＲＸ）タイミング非同期から回復する方法を提供し得、該方法は、ＤＲＸタイミング非同期を検出するステップと、ユーザ装置（ＵＥ）にインディケータを送信し、連続受信を再開するステップと、連続受信応答が受信されたかどうかの指示を待つステップとを包含する。
【００１４】
本開示は、ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信（ＤＲＸ）タイミング非同期によるユーザ装置における連続受信に進む方法をさらに提供し得、該方法は、ＤＲＸからウェイクアップするステップと、連続受信に進むべきかどうかを決定するインディケータをチェックするステップと、連続受信に進むべきというインディケータが存在する場合、ＤＲＸを非活動化し、連続受信に進み、連続受信応答を送信するステップとを包含する。
【００１５】
本開示は、ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信（ＤＲＸ）タイミング非同期から回復するように適合された強化型ノードＢ（ｅＮＢ）をさらに提供し得、本開示は、ＤＲＸタイミング非同期を検出する手段と、連続受信を再開するインディケータをユーザ装置（ＵＥ）に送信する手段と、連続受信応答が受信されたかどうかの指示を待つ手段とを特徴とする。
【００１６】
本開示は、ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信（ＤＲＸ）タイミング非同期による連続受信に進むように適合されたユーザ装置「ＵＥ」をさらに提供し得、ＤＲＸからウェイクアップする手段と、連続受信に進むべきかどうかを決定するインディケータをチェックする手段と、連続受信に進むべきというインディケータが存在する場合、ＤＲＸを非活動化し、連続受信に進み、連続受信応答を送信する手段とを特徴とする。
本発明は、例えば、以下を提供する。
（項目１）
ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信「ＤＲＸ」タイミング非同期から回復する、ワイヤレス通信システムにおける方法であって、
ＤＲＸタイミング非同期を検出する（４１４、５１４）ステップと、
連続受信を再開するために、ユーザ装置「ＵＥ」にインディケータを送信する（４１６、５２０）ステップと、
連続受信応答または連続受信通知が受信されたか否かの指示を待つ（４１８、５２２）ステップと
を包含する、方法。
（項目２）
上記送信するステップは、上記ユーザ装置に対する無線ネットワーク一時識別子「ＲＮＴＩ」を所定のシステム情報ブロックに追加することを包含する、項目１に記載の方法。
（項目３）
上記検出するステップは、
媒体アクセス制御プロトコルデータユニット「ＭＡＣ−ＰＤＵ」を上記ＵＥに送るかまたは再送信することと、
ハイブリッド自動繰り返し要求「ＨＡＲＱ」フィードバック信号を所定の時間内に受信しないことと
を包含する、項目２に記載の方法。
（項目４）
上記連続受信通知の指示を受信する（４１８）ステップと、
上記ＭＡＣ−ＰＤＵを再送信する（４２０）ステップと
をさらに包含する、項目３に記載の方法。
（項目５）
上記ＭＡＣ−ＰＤＵが受信されたことの確認次第、上記ユーザ装置に対する上記ＲＮＴＩを上記所定のシステム情報ブロックから除去する（４３５）ステップをさらに包含する、項目４に記載の方法。
（項目６）
上記送信するステップは、
絶対ウェイクアップ時間から待つことと、
連続受信コマンドを送る（５２０）ことと
を包含する、項目１に記載の方法。
（項目７）
上記検出するステップは、
媒体アクセス制御プロトコルデータユニット「ＭＡＣ−ＰＤＵ」を上記ＵＥに送るかまたは再送信することと、
ハイブリッド自動繰り返し要求「ＨＡＲＱ」フィードバック信号を所定の時間内に受信しないことと
を包含する、項目６に記載の方法。
（項目８）
上記連続受信応答の指示を受信する（５２２）ステップと、
上記ＭＡＣ−ＰＤＵを再送信する（５２４）ステップと
をさらに包含する、項目７に記載の方法。
（項目９）
上記連続受信応答の指示が受信されない場合、または上記ＭＡＣ−ＰＤＵの再送信が不成功である場合、ハンドオーバが起こったかどうかまたはＲＲＣ接続が解除されたかどうかをチェックし（５４０）、ハンドオーバが起こったかまたはＲＲＣ接続が解除された場合、プロセスを終了させる（５３０）ステップをさらに包含する、項目８に記載の方法。
（項目１０）
ハンドオーバが起らず、ＲＲＣ接続が解除されなかった場合、再試行期間が終了したかどうかをチェックし（５４２）、
再試行期間が終了した場合、該ＲＲＣ接続を解除し（５４４）、
再試行期間が終了していない場合、上記待つステップおよび送るステップ（５２０）を繰り返す、項目９に記載の方法。
（項目１１）
絶対ウェイクアップタイミングは、システム無線フレームタイミングに対する無線フレームオフセットおよびＤＲＸ間隔によって定義される、項目６〜１０のいずれか１項に記載の方法。
（項目１２）
上記絶対ウェイクアップタイミングは、正の整数または０が掛けられた上記ＤＲＸ間隔に加算された上記無線フレームオフセットによって定義される無線フレームである、項目１１に記載の方法。
（項目１３）
絶対ウェイクアップタイミングは、ＲＲＣによって上記ＵＥに送信される、項目１２に記載の方法。
（項目１４）
上記無線フレームオフセットは、加入者識別またはＵＥ識別から計算される、項目１２または項目１３に記載の方法。
（項目１５）
上記識別は、国際モバイルステーション識別である、項目１４に記載の方法。
（項目１６）
ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信「ＤＲＸ」タイミング非同期によるユーザ装置における連続受信に進む方法であって、
ＤＲＸからウェイクアップする（４５２、５５２）ステップと、
連続受信に進むべきかどうかを決定するインディケータをチェックする（４６０、５５８）ステップと、
連続受信に進むべきというインディケータが存在する場合、ＤＲＸを非活動化（４６６、５７０）し、連続受信に進み、連続受信応答または連続受信通知を送信する（４６８、５７２）ステップと
を包含する、方法。
（項目１７）
上記チェックするステップは、
所定のシステム情報ブロックを読み取る（４５６）ことと、
上記ユーザ装置に対する無線ネットワーク一時識別子「ＲＮＴＩ」が該所定のシステム情報ブロック内にあるかどうかを決定する（４６０）ことと
を包含し、該決定するステップが、該ユーザ装置の該ＲＮＴＩが該所定のシステム情報ブロックにあることを見つけた場合、チェックするステップは上記インディケータが存在するということを見つける、項目１６に記載の方法。
（項目１８）
連続受信に進みかつアップリンク同期を得るインディケータが存在する場合、アップリンク同期を得ることと、連続受信応答を送る認可をスケジューリングすることとを行う、項目１６または項目１７に記載の方法。
（項目１９）
上記チェックするステップは、
連続受信コマンドが絶対ウェイクアップ時間に受信されるかどうかを決定する（５５６、５５８）ことを包含し、
該連続受信コマンドが絶対ウェイクアップ時間に受信された場合、該チェックするステップは上記インディケータが存在するということを見つける、項目１６に記載の方法。
（項目２０）
ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信「ＤＲＸ」タイミング非同期から回復するように適合された強化型ノードＢ「ｅＮＢ」であって、
ＤＲＸタイミング非同期を検出する手段と、
連続受信を再開するインディケータをユーザ装置「ＵＥ」に送信する手段と、
連続受信応答かまたは連続受信通知が受信されたかどうかの指示を待つ手段と
を備えている、強化型ノードＢ「ｅＮＢ」。
（項目２１）
インディケータを上記ＵＥに送信する手段は、アップリンク同期および連続コマンド応答のために用いられる無線資源に対するニーズを該インディケータに含むように適合される、項目２０に記載のｅＮＢ。
（項目２２）
上記送信する手段は、上記ユーザ装置に対する無線ネットワーク一時識別子「ＲＮＴＩ」を所定のシステム情報ブロックに追加するように適合される、項目２０または項目２１に記載のｅＮＢ。
（項目２３）
上記送信する手段は、
絶対ウェイクアップ時間から待つことと、
連続受信コマンドを送ることと
を行なうように適合される、項目２０または項目２１に記載のｅＮＢ。
（項目２４）
ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信「ＤＲＸ」タイミング非同期による連続受信に進むように適合されたユーザ装置「ＵＥ」であって、
ＤＲＸからウェイクアップする手段と、
連続受信に進むべきかどうかを決定するインディケータをチェックする手段と、
連続受信に進むべきというインディケータが存在する場合、ＤＲＸを非活動化し、連続受信に進み、連続受信応答または連続受信通知を送信する手段と
を備えている、ユーザ装置。
（項目２５）
上記チェックする手段は、
所定のシステム情報ブロックを読み取ることと、
上記ユーザ装置に対する無線ネットワーク一時識別子「ＲＮＴＩ」が該所定のシステム情報ブロック内にあるかどうかを決定することと
を行うように適合され、
該ユーザ装置の該ＲＮＴＩが該所定のシステム情報ブロックにある場合、該チェックする手段は上記インディケータが存在するということを見つけるように適合される、項目２４に記載のＵＥ。
（項目２６）
上記チェックする手段は、連続受信コマンドが絶対ウェイクアップ時間に受信されるかどうかを決定するように適合され、
該連続受信コマンドが絶対ウェイクアップ時間に受信された場合、該チェックする手段は上記インディケータが存在するということを見つけるように適合される、項目２４に記載のＵＥ。
（項目２７）
項目２０〜２３のいずれか１項に記載の少なくとも１つの強化型ノードＢと項目２４〜２６のいずれか１項に記載の複数のユーザ装置とを備えているワイヤレス通信システム。
【００１７】
本開示は、図面を参照してより良く理解される。
【図面の簡単な説明】
【００１８】
【図１】図１は、ロングタームエボリューションユーザ面プロトコルスタックを示すブロック図である。
【図２】図２は、ロングタームエボリューション制御面プロトコルスタックを示すブロック図である。
【図３ａ】図３ａは、ｅＮＢ側からＭＡＣ−ＰＤＵヘッダまたはＭＡＣ制御ＰＤＵを用いることによって、ＤＲＸ期間を活動化、非活動化および再構成する方法を示すフローチャートである。
【図３ｂ】図３ｂは、ＵＥ側からＤＲＸ期間の活動化、非活動化または再構成を応答する方法を示すフローチャートである。
【図４ａ】図４ａは、ｅＮＢ側からシステム情報内のＤＲＸタイミング非同期化を指示する方法を示すフローチャートである。
【図４ｂ】図４ｂは、ＵＥ側からシステム情報内のＤＲＸタイミング非同期化を実現する方法を示すフローチャートである。
【図５ａ】図５ａは、ｅＮＢ観点から、起こり得るＤＲＸタイミング非同期化からの事前構成されたウェイクアップ時間回復の方法を示すフローチャートである。
【図５ｂ】図５ｂは、ＵＥ観点から、起こり得るＤＲＸタイミング非同期化からの事前構成されたウェイクアップ時間回復の方法を示すフローチャートである。
【発明を実施するための形態】
【００１９】
（好ましい実施形態の説明）
図面がここで参照される。図１は、ロングタームエボリューション（ＬＴＥ）ユーザ面プロトコルスタックを例示するブロック図を示す。
【００２０】
ＵＥ１１０は、強化型ノードＢ（ｅＮＢ）１２０およびアクセスゲートウェイ（ａＧＷ）１３０の両方と通信する。
【００２１】
様々な層がプロトコルスタックに例示される。パケットデータ収束プロトコル（ＰＤＣＰ）層１４０が、ＵＥ１１０およびａＧＷ１３０の両方に例示される。ＰＤＣＰ層１４０は、インターネットプロトコル（ＩＰ）ヘッダ圧縮および解凍と、ユーザデータの暗号化と、ユーザデータの転送と、無線ベアラに対するシリアルナンバー（ＳＮ）のメンテナンスとを実行する。
【００２２】
ＰＤＣＰ層１４０の下には、ｅＮＢ１２０上の無線リンク制御プロトコル層１４２と通信する無線リンク制御プロトコル層１４２がある。理解されるように、通信は、図１および図２に例示されるようなプロトコルスタックにおいて物理層を介して行われる。しかしながら、ＵＥのＲＬＣ層１４２からのＲＬＣ−ＰＤＵは、ｅＮＢ１２０上のＲＬＣ層１４２によって解釈される。
【００２３】
ＲＬＣ層１４２の下には、媒体アクセス制御（ＭＡＣ）データ通信プロトコル層１４６がある。当業者によって理解されるように、ＲＬＣおよびＭＡＣプロトコルは、ＬＴＥ無線インタフェースのデータリンク副層を形成し、ＬＴＥおよびユーザ装置におけるｅＮＢ上にある。
【００２４】
層１（Ｌ１）ＬＴＥ（物理層１４８）は、ＲＬＣ／ＭＡＣ層１４４および１４６の下にある。この層は、通信のための物理層である。
【００２５】
図２を参照すると、図２は、ＬＴＥ制御面プロトコルアーキテクチャを例示する。図１において用いられる参照数字に類似の参照数字が、図２において用いられる。特に、ＵＥ１１０は、ｅＮＢ１２０およびａＧＷ１３０と通信する。さらに、物理層１４８、ＭＡＣ層１４６、ＲＬＣ層１４２およびＰＤＣＰ層１４０は、図２内に存在する。
【００２６】
図２はまた、非アクセスストラタム（ｎｏｎ−ａｃｃｅｓｓ ｓｔｒａｔｕｍ）（ＮＡＳ）層２１０を示す。理解されるように、ＮＡＳ層２１０は、移動管理およびセッション管理を含み得る。
【００２７】
無線資源制御プロトコル層（ＲＲＣ）２２０は、ＵＥとＥ−ＵＴＲＡＮ（進化型汎用地上無線アクセスネットワーク）との間の無線資源の割当てと、構成と、放出とに責任を負うプロトコルスタックの一部である。ＬＴＥのためのＲＲＣプロトコルの基本機能は、３ＧＰＰ ＴＲ２５．８１３において説明される。
【００２８】
当業者によって理解されるように、ＵＭＴＳにおいて、自動繰り返し要求（ＡＲＱ）機能は、無線ネットワークコントローラ（ＲＮＣ）にあるＲＬＣ層内で実行される。ロングタームエボリューション（ＬＴＥ）は、ＡＲＱ機能をＲＮＣからｅＮＢに移動させ、ｅＮＢにおいて、ＡＲＱとＨＡＲＱ（ＭＡＣ層内にあり、これもｅＮＢに位置を決められる）との間により緊密な相互作用が存在し得る。
【００２９】
ＬＴＥ＿ＡＣＴＩＶＥ状態におけるＤＲＸに関する様々な問題は、本明細書において考慮される。
【００３０】
（ＤＲＸ信号方式手順）
ＬＴＥ＿ＡＣＴＩＶＥ状態でＤＲＸを用いているセルにおいて、ＵＥの大母集団をサポートするためにＤＲＸを活動化、非活動化し、そしてＤＲＸ期間の持続期間を指定するための非常に効率的な信号方式手順が必要とされる。
【００３１】
当業者によって理解されるように、強化型ノードＢ（ｅＮＢ）がＤＲＸ動作によりＵＥの受信器のオフの期間中にＵＥにデータを送信する場合、ＵＥはデータを受信し得ない。従って、ＤＲＸが活動化されそして非活動化されるときに関してＵＥとｅＮＢとが同期されることを確実にするために特別の努力が必要とされる。
【００３２】
ｅＮＢとＵＥとの間の指示は、無線資源制御（ＲＲＣ）または層１／層２（Ｌ１／Ｌ２）の信号方式によって明示的に信号が送られ得る。しかしながら、理解されるように、明示的な信号方式は、所望されるほど効率的ではない場合がある。
【００３３】
より効率的な解決策は、ＤＲＸ活動化および非活動化を指示する、ＭＡＣ−ＰＤＵ（ＭＡＣプロトコルデータユニット）のＭＡＣヘッダまたはＭＡＣ制御ＰＤＵ（ＭＡＣ制御情報のみを含むＭＡＣ ＰＤＵ）にオプションのフィールドを含めることである。フィールドは、好ましくは活動化および非活動化のためのＤＲＸ値およびタイミング余裕を示す。０値は、例えば、好ましい実施形態においてＤＲＸ値フィールドにおけるＤＲＸ非活動化を意味し得る。逆に、次のＭＡＣ−ＰＤＵにおいて送信されるべきデータがＵＥのためのバッファにおける最後のデータである場合、ｅＮＢはＤＲＸ長初期値を含むようにＭＡＣヘッダフィールドを広げ得る。例えば、これは３２０ミリ秒であり得る。
【００３４】
ＭＡＣ−ＰＤＵヘッダ内のＤＲＸ期間に信号を送るいくつかの異なる方法が、考えられ得る。例えば、ＤＲＸ期間の８個の値を示すために３ビットがＭＡＣヘッダに追加され得る。従って特定の時間値が送られるよりはむしろ、０００から１１１までのビット値は、８個の別個の値のうちの１つを示し得る。
【００３５】
代替案においてＭＡＣヘッダにおける、より小さいフィールド（例えば２ビット）が、インクリメントまたはディクリメントを示すために用いられ得る。ＲＲＣはディフォルト値を示し得、ＭＡＣヘッダがインクリメントまたはディクリメントを示す場合、ＵＥは受信した指示に従って所定の値に変化し得る。同様にＲＲＣは、実際のＤＲＸと、より小さいフィールドに含まれる値との間のマッピングを定義し得る。
【００３６】
ＵＥが一旦ＤＲＸ値を受信すると、ＵＥは、ＨＡＲＫ ＡＣＫを送信することによってｅＮＢにＤＲＸ値の肯定応答し、伝播遅延およびｅＮＢにおける処理遅延を考慮して、適切なシステムフレームにおいてＤＲＸを開始させる。ｅＮＢがＵＥからＡＣＫを受信したとき、ｅＮＢもまた適切なシステムフレーム時間においてＤＲＸを開始させる。理解されるように、ｅＮＢはそのトランシーバをオフにしないで、単に個々のＵＥにメッセージを送信しないことを知っているだけである。
【００３７】
ＤＲＸ期間のウェイクアップサイクル中、新しいデータが送信のためにｅＮＢに到着した場合、バッファにおけるデータ量またはサービス要求の質に従って、ｅＮＢは、ヘッダ延長がＤＲＸ非活動化またはより短いＤＲＸ長に設定されて、ＭＡＣ−ＰＤＵを送り得る。ＵＥは、従ってＤＲＸを再構成し、ＭＡＣ−ＰＤＵの肯定応答をする。ｅＮＢがＡＣＫを受信したとき、ｅＮＢはＤＲＸを再構成する。上記のように、非活動化は単に長さ値を０に設定することによって達成され得る。
【００３８】
図３ａおよび図３ｂがここで参照される。図３ａは、ＬＴＥ＿ＡＣＴＩＶＥ状態においてＤＲＸ活動化を制御する例示的方法を示す。プロセスは、ステップ３００で開始し、ステップ３１０に進み、ステップ３１０においてデータはＵＥに送信される。当業者によって理解されるように、ＬＴＥ＿ＡＣＴＩＶＥ状態におけるデータ送信は、データリンク層においてＭＡＣ−ＰＤＵを用い、データを転送する。
【００３９】
プロセスは次にステップ３１２に進み、ステップ３１２においてＵＥに送られるデータのバッファが次の送信後に空であるかどうかを調べるためにチェックが行われる。空でなければ、プロセスはステップ３１０に戻り、ステップ３１０においてデータはＵＥに送信される。あるいは、バッファが次の送信後に空であり、データ到着速度が閾値よりも低い場合、プロセスはステップ３１４に進む。
【００４０】
ステップ３１４において、ｅＮＢは、ＭＡＣ−ＰＤＵヘッダにおいてＤＲＸ活動化を設定する。上記のように、ｅＮＢは、ＤＲＸ期間の長さ、および、必要な場合、例えばＤＲＸ活動化が実行されるときのシステム無線フレームナンバーなどのＤＲＸ活動時間を示すＤＲＸ活動化値を含む。別の実施形態において、ｅＮＢは、単にＤＲＸ間隔の増加を指示し得る。ＵＥは、現在のＤＲＸ間隔を所定の減少した間隔に再構成する。所定の間隔は、ｅＮＢおよびＵＥの両方に既知であるかまたは、システム同報通信またはＲＲＣ信号方式による明白な信号方式によってｅＮＢからＵＥに事前に信号を送られるかのいずれかであり得る。
【００４１】
プロセスは次いでステップ３１６に進み、ステップ３１６において修正されたＭＡＣ−ＰＤＵヘッダを含むデータは、ＵＥに送られる。
【００４２】
図３ｂがここで参照される。ステップ３１８において、ＵＥは、データを受信し、ＤＲＸ活動化がＭＡＣ−ＰＤＵヘッダに指定されていることを調べる。プロセスはステップ３２０に進み、ステップ３２０においてＵＥは、肯定応答（ＡＣＫ）をｅＮＢに送り、伝播遅延およびｅＮＢにおける処理遅延を考慮して、適切なシステムフレームにおいてＤＲＸを開始させる。指定されたＤＲＸの活動化時間が受信されたＭＡＣ−ＰＤＵヘッダにおいて指示される場合、ＵＥおよびｅＮＢの両方はその時間に新しいＤＲＸ値を適用する。
【００４３】
図３ａのステップ３３０において、ｅＮＢは、ＵＥからＡＣＫを受信し、同じ適切なシステムフレームにおいてＤＲＸを開始させる。
【００４４】
理解されるように、ＤＲＸが調整されることを要求し得る様々なイベントが起るまで、ＤＲＸは継続し得る。１つのイベントは、ＵＥのためのｅＮＢによるａＧＷからのデータの受信である。受信されたデータ量に従って、ＤＲＸが非活動化されるかまたはＤＲＸの期間が減少され得る。ＤＲＸの調整を必要とし得る他のイベントは、ｅＮＢとＵＥとの間の信号出力レベルの変化、または、とりわけ継続したデータの非活動性によるＤＲＸにおけるゆるやかな増加を含む。
【００４５】
ステップ３３２において、ｅＮＢは、ＤＲＸが調整される必要があるかどうかを調べるためにチェックする。上記のように、これは、ＵＥに送られるデータが受信される状況であり得る。ここで、ＤＲＸが非活動化されるか、または期間が調整され得る。
【００４６】
ステップ３３２から、ＤＲＸが調整される必要がない場合、プロセスはステップ３３２に戻り、ＤＲＸが調整される必要があるかないかをチェックし続ける。
【００４７】
ステップ３３２におけるプロセスが一旦、ＤＲＸが調整される必要がないということを見つけると、プロセスは、ステップ３３４に進み、ステップ３３４において、ＤＲＸを調整する。このことは、ＤＲＸに対して０値を送信するか、または必要に応じ、より短いＤＲＸかまたはより長いＤＲＸを送信することによってＤＲＸを非活動化し得る。
【００４８】
修正されたヘッダ（修正されたＤＲＸ値および必要に応じ新しいＤＲＸ値に対する活動化時間を含む）を有するＭＡＣ−ＰＤＵは、ステップ３３６においてＵＥに送られる。ステップ３３６おけるＭＡＣ−ＰＤＵはまた、ＵＥに送信される必要のある、ｅＮＢによって受信された任意のデータを含み得る。どのデータも含まれない場合、ＭＡＣ−ＰＤＵは、ＭＡＣ制御ＰＤＵであると考えられる。
【００４９】
図３ｂを参照すると、プロセスは次いで、ステップ３１８に進み、ステップ３１８において、修正されたヘッダを有するＭＡＣ−ＰＤＵは、ＵＥにおいて受信される。ＵＥは、ＤＲＸ期間が調整されることを認識し、ステップ３２０においてＵＥは、肯定応答をｅＮＢに送り、伝播遅延およびｅＮＢにおける処理遅延を考慮して、適切なシステムフレームにおいてＵＥのＤＲＸ期間を調整する。活動化時間がＭＡＣ−ＰＤＵヘッダにおいて指示される場合、ＵＥおよびｅＮＢの両方はその時間に新しいＤＲＸ値を適用する。
【００５０】
図３ａを参照すると、ステップ３４２において、ｅＮＢは、ＡＣＫを受信し、同じ適切なシステムフレームにおいて修正されたＤＲＸ期間を開始させる。プロセスは次いでステップ３３２に戻り、ＤＲＸが再び調整される必要があるかどうかを調べる。
【００５１】
当業者によって理解されるように、上記に関する１つの問題は、ＡＣＫまたはＮＡＣＫの誤った解釈の場合に起る。特に、ＡＲＱエラー制御方法の変形である、送信器のハイブリッド自動繰返し要求（ＨＡＲＱ）エンティティは、おそらく不良のチャネル状態によりＡＣＫまたはＮＡＣＫを必ずしも常に正しく復調するとは限らない。従って、一部の状況において、一方がもう一方のものとして解釈され得る。ＤＲＸ活動化および非活動化をＭＡＣ−ＰＤＵヘッダに起こすことによって、ＡＣＫからＮＡＣＫまたはＮＡＣＫからＡＣＫへの誤った解釈は、ｅＮＢとＵＥとの間で信号送信された制御情報の誤った解釈がデータまたはおそらくは無線接続の喪失に導き得るので、処理される必要がある。
【００５２】
（ＤＲＸ自動インクリメンテーション）
さらなる考慮は、ＤＲＸのインクリメントの拡張である。好ましい実施形態において、ＤＲＸ期間がインクリメントまたはディクリメントされ得る仕方（例えば、２の因数によって）を指示する規則は、無線ベアラ（ｒａｄｉｏ ｂｅａｒｅｒ）（ＲＢ）セットアップ中に信号が送られ得る。規則は、ＲＲＣ ＲＢセットアップ／再構成または測定制御メッセージでＵＥに運ばれる。この場合、Ｎの現在のＤＲＸサイクル後にどのデータも受信されない場合、ｅＮＢおよびＵＥは、ＤＲＸ長を次のより大きな値に自動的に増加させる。このことは、ＤＲＸ長を増加させるためにｅＮＢとＵＥとの間へ信号を送る必要性を除去し、従ってネットワーク資源および電池資源を節約する。
【００５３】
（システム情報におけるＤＲＸタイミング非同期化の指示）
ＵＥがＵＥのＤＲＸタイミング内において同期がずれているとｅＮＢが決定したとき、ｅＮＢは所定のシステム情報ブロックにおいてＵＥのＲＮＴＩを示す。ＵＥがウェイクアップすると、ＵＥはシステム情報ブロックを読み取る。ＵＥのＲＮＴＩが指示された場合、ＵＥは、ＤＲＸモードを非活動化し、ｅＮＢへのＬ１／Ｌ２の信号方式またはＭＡＣ信号方式を用いて連続受信通知メッセージを送信する。連続受信通知メッセージの受信次第、ｅＮＢはバッファ内で待つデータをＵＥに再送信する。データが肯定応答されるか、またはＵＥからのＨＡＲＱフィードバックが受信されたとき、ｅＮＢはシステム情報からＲＮＴＩを除去する。
【００５４】
図４ａがここで参照される。図４ａは、システム情報においてＲＮＴＩに信号を送り、ＤＲＸ非同期化から回復する方法のフローチャートを示す。プロセスはステップ４１０で開始する。
【００５５】
プロセスはステップ４１２に進み、ステップ４１２においてｅＮＢは次のＭＡＣ−ＰＤＵを送信する。
【００５６】
プロセスは次いで、ステップ４１４に進み、ステップ４１４においてプロセスは、ＤＲＸタイミング非同期化が起こったかどうかをチェックする。上記のように、これは、ｅＮＢがどのＨＡＲＱフィードバック信号もＵＥから入手しない場合であり得、この場合ｅＮＢはＤＲＸタイミングにおいて同期がずれていることを考慮し得る。
【００５７】
ステップ４１４において、どのＤＲＸタイミング非同期化も検出されない場合、プロセスは、ステップ４１２に戻り、ＤＲＸタイミング非同期化が検出されるまで継続する。
【００５８】
ステップ４１４においてＤＲＸタイミング非同期化が検出された場合、プロセスはステップ４１６に進み、ステップ４１６においてＵＥのＲＮＴＩは、所定のシステム情報ブロックに追加される。理解されるように、ＵＥは、ＤＲＸからウェイクアップしたとき、下記の図４ｂを参照して説明されるように、システム情報チェックし、ＵＥのＲＮＴＩを検出する。
【００５９】
図４ａにおけるステップ４１６から、プロセスは次いで、連続受信通知メッセージを待つ。連続受信通知メッセージがステップ４１８において受信される場合、プロセスはステップ４２０に進み、ステップ４２０においてプロセスは、ＭＡＣ−ＰＤＵを再送信する。理解されるように、これは、ステップ４１４においてＤＲＸタイミング非同期化が検出される前に、ｅＮＢがステップ４１２において送信を試みたことと同じＭＡＣ−ＰＤＵであり得る。ＭＡＣ−ＰＤＵの再送信はステップ４２０で行われる。
【００６０】
プロセスは、次いでステップ４２２に進み、ステップ４２２においてプロセスは成功またはＨＡＲＱフィードバックが受信されたかをチェックする。
【００６１】
ステップ４１８において、連続受信通知メッセージが受信されないかまたはステップ４２２において、成功またはＨＡＲＱフィードバックが受信されない場合、プロセスはステップ４３０に進み、ステップ４３０においてハンドオーバが起ったかまたはＲＲＣ接続が解除されたかどうかを調べるためにチェックがなされる。
【００６２】
ステップ４３０において別のセルへのハンドオーバが検出されるかまたはＲＲＣ接続が解除されるのが見つかった場合、プロセスはステップ４３５に進み、ステップ４３５においてＵＥのＲＮＴＩは、所定のシステム情報ブロックから除去される。同様に、ステップ４２２から成功が達成されるかまたはＨＡＲＱフィードバックが受信される場合、プロセスは、ステップ４３５に進み、ステップ４３５においてＵＥのＲＮＴＩが所定のシステム情報ブロックから除去される。
【００６３】
プロセスは次いで、ステップ４３５からステップ４４０に進み、ステップ４４０においてプロセスは終了する。
【００６４】
あるいは、ステップ４３０において別のセルへのハンドオーバまたはＲＲＣ接続解除が見つかった場合、プロセスは４４０に進み、ステップ４４０においてプロセスは終了する。
【００６５】
図４ｂがここで参照される。ＵＥ側において、プロセスはステップ４５０において開始する。
【００６６】
ステップ４５２において、ＵＥはＤＲＸからウェイクアップする。
【００６７】
プロセスは次いでステップ４５４に進み、ステップ４５４においてＵＥは、データがダウンリンク共用制御チャネル（ＤＬＳＣＣＨ）に指示された場合データを受信し、測定または必要に応じて他の機能を実行する。
【００６８】
プロセスは次いでステップ４５６に進み、ステップ４５６においてプロセスは、ＤＲＸタイミング非同期化においてＵＥのリストのために所定のシステム情報ブロックを読み取る。
【００６９】
プロセスは次いでステップ４６０に進み、ステップ４６０においてプロセスは、ＵＥのＲＮＴＩがシステム情報ブロックにおけるＵＥのリストに含まれるかどうかをチェックする。含まれない場合、ＵＥはステップ４６２におけるＤＲＸに戻り、次いでステップ４５２においてＤＲＸのウェイクアップを待つ。
【００７０】
あるいは、ステップ４６０から、ＵＥのＲＮＴＩがシステム情報ブロックに含まれる場合、プロセスはステップ４６６に進み、ステップ４６６においてＤＲＸは非活動化され、連続受信が開始される。
【００７１】
プロセスは次いで、ステップ４６８に進み、ステップ４６８において連続受信通知は送信され、ステップ４７０においてプロセスが終了する。
【００７２】
上記から理解されるように、非同期化は従って、所定のシステム情報ブロックにおいてＵＥがそのＲＮＴＩを検出することによって次のＤＲＸサイクルにおいて回復される。
【００７３】
（起こり得るＤＲＸタイミング非同期からの回復のための事前構成されたウェイクアップ時間）
さらなる実施形態において、会話形通信もしくは背景通信のための無線ベアラが設定されたときまたはそのベアラにおいてＤＲＸが活動化されたとき、絶対ウェイクアップ時間がＲＲＣによってＵＥに通知され得る。絶対ウェイクアップタイミングは、システム無線フレームタイミングに対する無線フレームオフセット（ＡＲＦｏｆｆ）およびＤＲＸ間隔（ＡＩＮＴ）によって定義される。現在のＤＲＸ設定に関わらず、ＵＥはＡＲＦｏｆｆ＋Ｎ＊ＡＩｎｔの無線フレームにおいてウェイクアップしなければならない。ここでＮは整数である。
【００７４】
プロセスはステップ５１０において開始し、ステップ５１２に進み、ステップ５１２において次のＭＡＣ−ＰＤＵが送信される。
【００７５】
プロセスは、次いでステップ５１４に進み、ステップ５１４においてｅＮＢは、ＤＲＸに対するタイミング非同期化が起こったかどうかを調べるためにチェックする。上記のように、これはＵＥからのＨＡＲＱフィードバックの受信の不足に基づき起こり得る。
【００７６】
ＤＲＸタイミング非同期化がステップ５１４において検出されない場合、プロセスはステップ５１２に戻り、次のＭＡＣ−ＰＤＵを送信し続ける。
【００７７】
ステップ５１４から、ＤＲＸタイミング非同期化が検出された場合、プロセスはステップ５２０に進み、ステップ５２０において連続受信コマンドが、無線資源制御によって構成される絶対ウェイクアップ時間に送信される。
【００７８】
プロセスは次いで、ステップ５２２に進み、ステップ５２２においてプロセスは、連続受信応答がＵＥから受信されたかどうかをチェックする。受信された場合、プロセスはステップ５２４に進み、ステップ５２４において、どのＨＡＲＱフィードバックも受信されないステップ５１２からのＭＡＣ−ＰＤＵが、ステップ５２４において再送信される。
【００７９】
プロセスは次いで５２６に進み、ステップ５２６においてプロセスは、成功があるかどうかまたはＨＡＲＱフィードバックが受信されたかどうかをチェックする。そうである場合、プロセスはステップ５３０において終了する。
【００８０】
ステップ５２２から、連続受信応答が受信されなかった場合、またはステップ５２６から、ＨＡＲＱフィードバックが受信されないかもしくはどの成功も決定されなかった場合、プロセスはステップ５４０に進み、ステップ５４０においてハンドオーバが起ったかまたはＲＲＣ接続が解除されたかどうかを調べるためにチェックがなされる。ハンドオーバが起ったかまたはＲＲＣ接続が解除されたということがステップ５４０において決定された場合、プロセスはステップ５３０に進み、終了する。
【００８１】
ステップ５４０において、どのハンドオーバも起らなかったかまたはＲＲＣ接続が解除されたということが決定された場合、プロセスはステップ５４２に進み、ステップ５４２においてプロセスは再試行期間が終了するかどうかをチェックする。終了しない場合、プロセスはステップ５２０に戻る。終了する場合、プロセスはステップ５４４に進み、ステップ５４４においてＲＲＣ接続が解除され、プロセスは次いでステップ５３０において終了する。
【００８２】
図５ｂがここで参照される。ＵＥの観点から、プロセスはステップ５５０において開始し、ステップ５５２に進み、ステップ５５２においてＵＥはＤＲＸからウェイクアップする。プロセスは次いでステップ５５４に進み、ステップ５５４においてＵＥは、データがダウンリンク共用制御チャネル（ＤＬＳＣＣＨ）に指示された場合データを受信し、測定または必要に応じて他の機能を実行する。
【００８３】
プロセスは次いでステップ５５６に進み、ステップ５５６においてプロセスは、時間が絶対ウェイクアップ時間であるかどうかをチェックする。絶対ウェイクアップ時間である場合、プロセスはステップ５５８に進み、ステップ５５８においてＵＥは、連続受信コマンドが受信されたかどうかをチェックする。
【００８４】
ステップ５５６から、時間が絶対ウェイクアップ時間でない場合、またはステップ５５８において連続受信コマンドが受信されなかった場合、プロセスはステップ５６０に進み、ステップ５６０においてＵＥはＤＲＸに戻る。ステップ５６０からプロセスは、ステップ５５２においてＤＲＸからウェイクアップすることによって継続する。
【００８５】
あるいは、連続受信コマンドがステップ５５８において受信される場合、プロセスはステップ５７０に進み、ステップ５７０においてＤＲＸが非活動化され、連続受信が開始される。プロセスは次いで、ステップ５７２に進み、ステップ５７２において連続受信応答が送信され、プロセスはステップ５７４において終了する。
【００８６】
上記に基づき、ＤＲＸタイミングにおいてＵＥの同期がずれていることをｅＮＢが検出したとき、ｅＮＢは、Ｌ１／Ｌ２信号方式またはＭＡＣ信号方式における連続受信コマンドを絶対ウェイクアップ時間にＵＥに送る。ＵＥは、絶対ウェイクアップ時間にウェイクアップし、連続受信コマンドが受信されたか否かをチェックし、受信された場合、ＵＥはそのトランシーバの電源を入れ、連続受信に戻る。
【００８７】
さらなる代替案において、絶対ウェイクアップ無線フレームオフセットＡＲＦｏｆｆは、３ＧＰＰ ＴＳ２５．３０４に説明されるＵＭＴＳにおいてページング機会が計算される方法と類似する方法で、ＩＭＳＩなどのＵＥアイデンティティから計算され得る。そのような場合において、ＤＲＸ間隔は、専用のＲＲＣメッセージを介してセーブされるよりはむしろシステム情報に含まれ得る。
【００８８】
理解されるように、ＡＲＦｏｆｆの信号をＵＥに送る利益は、ｅＮＢが絶対ウェイクアップ時間を現在のＤＲＸ設定に整合させ得、その結果、さらなる電池節約が達成され得ることである。
【００８９】
本明細書において説明される実施形態は、本開示の技術の要素に対応する要素を有する構造、システムまたは方法の例である。この説明は、当業者が本開示の要素または技術に同様に対応する代替の要素を有する実施形態を用いることを可能にし得る。従って本開示の技術の意図された範囲は、本明細書において説明される本開示の技術とは異ならない構造、システムまたは方法を含み、本明細書において説明される本開示の技術とは実質的でない相違を有する他の構造、システムまたは方法をさらに含む。
【技術分野】
【０００１】
本開示は、概して第３世代パートナーシッププロジェクト（３ＧＰＰ）のロングタームエボリューション（ＬＴＥ）に関し、特にＬＴＥ＿ＡＣＴＩＶＥ状態におけるＤＲＸタイミング非同期に関する。
【背景技術】
【０００２】
ロングタームエボリューション（ｌｏｎｇ−ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）インフラストラクチャにおいて、ＵＥは２つの無線資源制御（ＲＲＣ）状態のうちの１つであり得る。これらは、ＬＴＥ＿ＩＤＬＥおよびＬＴＥ＿ＡＣＴＩＶＥである。
【０００３】
ＵＥは、ＬＴＥ＿ＩＤＬＥ状態およびＬＴＥ＿ＡＣＴＩＶＥ状態の両方において不連続受信（ＤＲＸ）するように構成され得る。ＬＴＥ＿ＩＤＬＥ状態において、ＤＲＸは、ＵＥがその聴取期間をネットワークの公知のパージングサイクルに同期させることを可能にする。聴取期間を同期させることによって、ＵＥは、スタンバイ期間中、その無線トランシーバの電源を切り、それによって電池資源を実質的に節約し得る。ＤＲＸパラメータは、モバイルがネットワークと同期すること、および所定の時間が経過するまでモバイルが別の信号を受信しないということを知ることを可能にする。
【０００４】
ＵＥがＬＴＥ＿ＡＣＴＩＶＥ状態であるときもＤＲＸが使用されるようにすべきということが３ＧＰＰ ＴＳＧ−ＲＡＮワーキンググループにおいて提案される。ＬＴＥ＿ＡＣＴＩＶＥ状態のユーザ装置（ＵＥ）による不連続受信（ＤＲＸ）であるとき、正規ＤＲＸ構成は、無線資源制御（ＲＲＣ）プロトコルメッセージによって信号を送られ、一時ＤＲＸ（再）構成は、例えばＭＡＣプロトコルデータユニット（ＭＡＣ−ＰＤＵ）ヘッダまたはＭＡＣ制御ＰＤＵにおいて、媒体アクセス制御（ＭＡＣ）信号によって信号を送られることがさらに提案される。
【０００５】
ＬＴＥにおいて、ユーザデータがダウンリンク共用チャネルで送られる前に、ｅＮＢは、ダウンリンク共用制御チャネル（ＤＬＳＣＣＨ）でスケジューリング指示を送り、ＵＥがデータを復調するために用いるパラメータを提供する。しかしながら、ＵＥがＤＬＳＣＣＨスケジューリング指示を見のがした場合、ＵＥはユーザデータを受信したことを知らず、従ってＵＥは、ユーザＭＡＣ−ＰＤＵを肯定応答（ＡＣＫ）するかまたは否定的応答（ＮＡＣＫ）することを知らない。ｅＮＢは、ＡＣＫまたはＮＡＣＫ、すなわちハイブリッドＡＲＱ（ＨＡＲＱ）応答を待つ。ｅＮＢがその応答を得ないとき、それは不連続送信（ＤＴＸ）と見なされる。ダウンリンク共用制御チャネル（ＤＬＳＣＣＨ）でのデータ指示がＵＥによって見のがされ、ＨＡＲＱフィードバックチャネルでの後の不連続送信（ＤＴＸ）が強化型ノードＢ（ｅＮＢ）によってＡＣＫとして誤って解釈された場合、ＭＡＣ−ＰＤＵが失われ得る。さらに、ＵＥが、規則例えばある持続期間データ活動なし、に従って、ＤＲＸ長を自動的に増加させた場合、ＵＥがそれ自身のＤＲＸ値を増加させながら、ｅＮＢはその現在のＤＲＸ値を維持する。これは、ＤＲＸタイミング非同期という結果になり、すなわちｅＮＢおよびＵＥは異なるＤＲＸ期間で動作している。
【０００６】
理解されるように、このことは、ダウンリンクメッセージ送達の待ち時間を増加させ、ダウンリンク無線資源を浪費する。より長い送達待ち時間は、特に重大なダウンリンク制御メッセージに関して、回避されるべきである。一旦ＤＲＸタイミング非同期が起こると、ｅＮＢは、新しいデータをＵＥに送るためにＵＥ ＤＲＸタイミングを決定しなければならない。ＵＥがおそらくウェイクアップしているであろうことをｅＮＢが知っているとき、それらの時間に様々なプロービングメッセージ（ｐｒｏｂｉｎｇ ｍｅｓｓａｇｅ）を送ることによって、ｅＮＢはこのＵＥ ＤＲＸタイミングを決定する。いくつかの試みの後に、ｅＮＢはＵＥ ＤＲＸタイミングを見つけ、同期を回復させるためにＵＥをウェイクアップさせる。
【発明の概要】
【課題を解決するための手段】
【０００７】
（概要）
ＵＥがＬＴＥ＿ＡＣＴＩＶＥであり、ＤＲＸが活動化されている場合、ダウンリンクデータの到着時、ｅＮＢは、ＤＬＳＣＣＨ上のスケジューリング指示を送信し得、ＵＥがウェイクアップしているときにＤＬ−ＳＣＨ上のＭＡＣ−ＰＤＵを送信する。ｅＮＢがＵＥからどのハイブリッドの自動繰り返し要求（ＨＡＲＱ）フィードバック信号も得ない場合、ｅＮＢは、ＵＥがＤＲＸタイミングにおいて同期がずれていると考え得る。そのような状態から回復するために、２つの方法が下記に説明される。
【０００８】
第１の方法は、システム情報におけるＤＲＸタイミング非同期化の指示であり得る。特に、ＤＲＸタイミングにおいてＵＥの同期がずれていることをｅＮＢが検出したとき、所定のシステム情報ブロックにおいてＵＥの無線ネットワーク一時識別子（ＲＮＴＩ）を同報通信し得る。ＵＥがウェイクアップするとき、ＵＥは、システム情報ブロックを読み取り得る。ＵＥのＲＮＴＩが指示された場合、ＵＥは、ＤＲＸモードを非活動化し得、ｅＮＢへのＬ１／Ｌ２の信号方式またはＭＡＣ信号方式を用いて連続受信通知メッセージを送信する。連続受信通知メッセージの受信次第、ｅＮＢはそのバッファ内で待つデータをＵＥに再送信する。データが肯定応答されるか、またはＵＥからのＨＡＲＱフィードバックが受信されたとき、ｅＮＢはシステム情報からＲＮＴＩを除去し得る。
【０００９】
さらなる実施形態において、ＤＲＸ非同期化から回復する方法は、絶対ウェイクアップ時間を事前に構成することであり得る。特に、会話形通信もしくは背景通信のための無線ベアラ（ｒａｄｉｏ ｂｅａｒｅｒ）が設定されたときまたはそのベアラにおいてＤＲＸが活動化されたとき、絶対ウェイクアップ時間がＲＲＣによってＵＥに通知され得る。絶対ウェイクアップタイミングは、システム無線フレームタイミングに対する無線フレームオフセット（ＡＲＦｏｆｆ）およびＤＲＸ間隔（ＡＩｎｔ）によって定義され得る。現在のＤＲＸ設定に関わらず、ＵＥはＡＲＦｏｆｆ＋Ｎ＊ＡＩｎｔの無線フレームにおいてウェイクアップしなければならない。ここで、Ｎ＝０、１、・・・である。ｅＮＢが２．５６秒内の回復を保証することを望む場合、ＡＩｎｔは２．５６秒に設定され得る。
【００１０】
ＤＲＸタイミングにおいてＵＥの同期がずれていることをｅＮＢが検出したとき、ｅＮＢは、Ｌ１／Ｌ２信号方式またはＭＡＣ信号方式における連続受信コマンド（すなわち、ＤＲＸ非同期化）を絶対ウェイクアップ時間にＵＥに送る。ＵＥが絶対ウェイクアップ時間にウェイクアップしたとき、ＵＥは連続受信コマンドが受信されたか否かをチェックし得る。受信された場合、ＵＥはトランシーバの電源を入れ、連続受信に戻り、アップリンク同期化および必要に応じスケジューリング認可を得、連続受信応答をｅＮＢに送る。連続受信応答を受領次第、ｅＮＢはそのバッファ内のデータをＵＥに送信し得る。
【００１１】
ＵＥがアップリンク同期を再調整することをｅＮＢが望む場合、ｅＮＢはＬ１／Ｌ２信号方式チャネルを介して連続受信コマンドを送り得、該連続受信コマンドは、アップリンク同期が再調整されるべきであるという指示および連続受信応答に対して割り当てられた専用のアップリンク資源に関する情報を含む。そのような連続受信コマンドの受信次第、ＵＥはアップリンクタイミングを再調整し得、連続受信コマンドにおいて指示された資源を用いて連続受信コマンドを送ることによって応答する。
【００１２】
さらなる代替の実施形態において、絶対ウェイクアップ無線フレームオフセットは、３ＧＰＰ ＴＳ２５．３０４に説明されるＵＭＴＳにおいてページング機会が計算される方法と類似する方法で、ＩＭＳＩ（国際モバイルステーションアイデンティティ）などのＵＥアイデンティティから計算され得る。この場合において、ＤＲＸ間隔は、専用のＲＲＣメッセージを介して信号を送られるよりはむしろシステム情報に含まれ得る。
【００１３】
従って本開示は、ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信（ＤＲＸ）タイミング非同期から回復する方法を提供し得、該方法は、ＤＲＸタイミング非同期を検出するステップと、ユーザ装置（ＵＥ）にインディケータを送信し、連続受信を再開するステップと、連続受信応答が受信されたかどうかの指示を待つステップとを包含する。
【００１４】
本開示は、ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信（ＤＲＸ）タイミング非同期によるユーザ装置における連続受信に進む方法をさらに提供し得、該方法は、ＤＲＸからウェイクアップするステップと、連続受信に進むべきかどうかを決定するインディケータをチェックするステップと、連続受信に進むべきというインディケータが存在する場合、ＤＲＸを非活動化し、連続受信に進み、連続受信応答を送信するステップとを包含する。
【００１５】
本開示は、ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信（ＤＲＸ）タイミング非同期から回復するように適合された強化型ノードＢ（ｅＮＢ）をさらに提供し得、本開示は、ＤＲＸタイミング非同期を検出する手段と、連続受信を再開するインディケータをユーザ装置（ＵＥ）に送信する手段と、連続受信応答が受信されたかどうかの指示を待つ手段とを特徴とする。
【００１６】
本開示は、ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信（ＤＲＸ）タイミング非同期による連続受信に進むように適合されたユーザ装置「ＵＥ」をさらに提供し得、ＤＲＸからウェイクアップする手段と、連続受信に進むべきかどうかを決定するインディケータをチェックする手段と、連続受信に進むべきというインディケータが存在する場合、ＤＲＸを非活動化し、連続受信に進み、連続受信応答を送信する手段とを特徴とする。
本発明は、例えば、以下を提供する。
（項目１）
ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信「ＤＲＸ」タイミング非同期から回復する、ワイヤレス通信システムにおける方法であって、
ＤＲＸタイミング非同期を検出する（４１４、５１４）ステップと、
連続受信を再開するために、ユーザ装置「ＵＥ」にインディケータを送信する（４１６、５２０）ステップと、
連続受信応答または連続受信通知が受信されたか否かの指示を待つ（４１８、５２２）ステップと
を包含する、方法。
（項目２）
上記送信するステップは、上記ユーザ装置に対する無線ネットワーク一時識別子「ＲＮＴＩ」を所定のシステム情報ブロックに追加することを包含する、項目１に記載の方法。
（項目３）
上記検出するステップは、
媒体アクセス制御プロトコルデータユニット「ＭＡＣ−ＰＤＵ」を上記ＵＥに送るかまたは再送信することと、
ハイブリッド自動繰り返し要求「ＨＡＲＱ」フィードバック信号を所定の時間内に受信しないことと
を包含する、項目２に記載の方法。
（項目４）
上記連続受信通知の指示を受信する（４１８）ステップと、
上記ＭＡＣ−ＰＤＵを再送信する（４２０）ステップと
をさらに包含する、項目３に記載の方法。
（項目５）
上記ＭＡＣ−ＰＤＵが受信されたことの確認次第、上記ユーザ装置に対する上記ＲＮＴＩを上記所定のシステム情報ブロックから除去する（４３５）ステップをさらに包含する、項目４に記載の方法。
（項目６）
上記送信するステップは、
絶対ウェイクアップ時間から待つことと、
連続受信コマンドを送る（５２０）ことと
を包含する、項目１に記載の方法。
（項目７）
上記検出するステップは、
媒体アクセス制御プロトコルデータユニット「ＭＡＣ−ＰＤＵ」を上記ＵＥに送るかまたは再送信することと、
ハイブリッド自動繰り返し要求「ＨＡＲＱ」フィードバック信号を所定の時間内に受信しないことと
を包含する、項目６に記載の方法。
（項目８）
上記連続受信応答の指示を受信する（５２２）ステップと、
上記ＭＡＣ−ＰＤＵを再送信する（５２４）ステップと
をさらに包含する、項目７に記載の方法。
（項目９）
上記連続受信応答の指示が受信されない場合、または上記ＭＡＣ−ＰＤＵの再送信が不成功である場合、ハンドオーバが起こったかどうかまたはＲＲＣ接続が解除されたかどうかをチェックし（５４０）、ハンドオーバが起こったかまたはＲＲＣ接続が解除された場合、プロセスを終了させる（５３０）ステップをさらに包含する、項目８に記載の方法。
（項目１０）
ハンドオーバが起らず、ＲＲＣ接続が解除されなかった場合、再試行期間が終了したかどうかをチェックし（５４２）、
再試行期間が終了した場合、該ＲＲＣ接続を解除し（５４４）、
再試行期間が終了していない場合、上記待つステップおよび送るステップ（５２０）を繰り返す、項目９に記載の方法。
（項目１１）
絶対ウェイクアップタイミングは、システム無線フレームタイミングに対する無線フレームオフセットおよびＤＲＸ間隔によって定義される、項目６〜１０のいずれか１項に記載の方法。
（項目１２）
上記絶対ウェイクアップタイミングは、正の整数または０が掛けられた上記ＤＲＸ間隔に加算された上記無線フレームオフセットによって定義される無線フレームである、項目１１に記載の方法。
（項目１３）
絶対ウェイクアップタイミングは、ＲＲＣによって上記ＵＥに送信される、項目１２に記載の方法。
（項目１４）
上記無線フレームオフセットは、加入者識別またはＵＥ識別から計算される、項目１２または項目１３に記載の方法。
（項目１５）
上記識別は、国際モバイルステーション識別である、項目１４に記載の方法。
（項目１６）
ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信「ＤＲＸ」タイミング非同期によるユーザ装置における連続受信に進む方法であって、
ＤＲＸからウェイクアップする（４５２、５５２）ステップと、
連続受信に進むべきかどうかを決定するインディケータをチェックする（４６０、５５８）ステップと、
連続受信に進むべきというインディケータが存在する場合、ＤＲＸを非活動化（４６６、５７０）し、連続受信に進み、連続受信応答または連続受信通知を送信する（４６８、５７２）ステップと
を包含する、方法。
（項目１７）
上記チェックするステップは、
所定のシステム情報ブロックを読み取る（４５６）ことと、
上記ユーザ装置に対する無線ネットワーク一時識別子「ＲＮＴＩ」が該所定のシステム情報ブロック内にあるかどうかを決定する（４６０）ことと
を包含し、該決定するステップが、該ユーザ装置の該ＲＮＴＩが該所定のシステム情報ブロックにあることを見つけた場合、チェックするステップは上記インディケータが存在するということを見つける、項目１６に記載の方法。
（項目１８）
連続受信に進みかつアップリンク同期を得るインディケータが存在する場合、アップリンク同期を得ることと、連続受信応答を送る認可をスケジューリングすることとを行う、項目１６または項目１７に記載の方法。
（項目１９）
上記チェックするステップは、
連続受信コマンドが絶対ウェイクアップ時間に受信されるかどうかを決定する（５５６、５５８）ことを包含し、
該連続受信コマンドが絶対ウェイクアップ時間に受信された場合、該チェックするステップは上記インディケータが存在するということを見つける、項目１６に記載の方法。
（項目２０）
ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信「ＤＲＸ」タイミング非同期から回復するように適合された強化型ノードＢ「ｅＮＢ」であって、
ＤＲＸタイミング非同期を検出する手段と、
連続受信を再開するインディケータをユーザ装置「ＵＥ」に送信する手段と、
連続受信応答かまたは連続受信通知が受信されたかどうかの指示を待つ手段と
を備えている、強化型ノードＢ「ｅＮＢ」。
（項目２１）
インディケータを上記ＵＥに送信する手段は、アップリンク同期および連続コマンド応答のために用いられる無線資源に対するニーズを該インディケータに含むように適合される、項目２０に記載のｅＮＢ。
（項目２２）
上記送信する手段は、上記ユーザ装置に対する無線ネットワーク一時識別子「ＲＮＴＩ」を所定のシステム情報ブロックに追加するように適合される、項目２０または項目２１に記載のｅＮＢ。
（項目２３）
上記送信する手段は、
絶対ウェイクアップ時間から待つことと、
連続受信コマンドを送ることと
を行なうように適合される、項目２０または項目２１に記載のｅＮＢ。
（項目２４）
ＬＴＥ＿ＡＣＴＩＶＥ状態における不連続受信「ＤＲＸ」タイミング非同期による連続受信に進むように適合されたユーザ装置「ＵＥ」であって、
ＤＲＸからウェイクアップする手段と、
連続受信に進むべきかどうかを決定するインディケータをチェックする手段と、
連続受信に進むべきというインディケータが存在する場合、ＤＲＸを非活動化し、連続受信に進み、連続受信応答または連続受信通知を送信する手段と
を備えている、ユーザ装置。
（項目２５）
上記チェックする手段は、
所定のシステム情報ブロックを読み取ることと、
上記ユーザ装置に対する無線ネットワーク一時識別子「ＲＮＴＩ」が該所定のシステム情報ブロック内にあるかどうかを決定することと
を行うように適合され、
該ユーザ装置の該ＲＮＴＩが該所定のシステム情報ブロックにある場合、該チェックする手段は上記インディケータが存在するということを見つけるように適合される、項目２４に記載のＵＥ。
（項目２６）
上記チェックする手段は、連続受信コマンドが絶対ウェイクアップ時間に受信されるかどうかを決定するように適合され、
該連続受信コマンドが絶対ウェイクアップ時間に受信された場合、該チェックする手段は上記インディケータが存在するということを見つけるように適合される、項目２４に記載のＵＥ。
（項目２７）
項目２０〜２３のいずれか１項に記載の少なくとも１つの強化型ノードＢと項目２４〜２６のいずれか１項に記載の複数のユーザ装置とを備えているワイヤレス通信システム。
【００１７】
本開示は、図面を参照してより良く理解される。
【図面の簡単な説明】
【００１８】
【図１】図１は、ロングタームエボリューションユーザ面プロトコルスタックを示すブロック図である。
【図２】図２は、ロングタームエボリューション制御面プロトコルスタックを示すブロック図である。
【図３ａ】図３ａは、ｅＮＢ側からＭＡＣ−ＰＤＵヘッダまたはＭＡＣ制御ＰＤＵを用いることによって、ＤＲＸ期間を活動化、非活動化および再構成する方法を示すフローチャートである。
【図３ｂ】図３ｂは、ＵＥ側からＤＲＸ期間の活動化、非活動化または再構成を応答する方法を示すフローチャートである。
【図４ａ】図４ａは、ｅＮＢ側からシステム情報内のＤＲＸタイミング非同期化を指示する方法を示すフローチャートである。
【図４ｂ】図４ｂは、ＵＥ側からシステム情報内のＤＲＸタイミング非同期化を実現する方法を示すフローチャートである。
【図５ａ】図５ａは、ｅＮＢ観点から、起こり得るＤＲＸタイミング非同期化からの事前構成されたウェイクアップ時間回復の方法を示すフローチャートである。
【図５ｂ】図５ｂは、ＵＥ観点から、起こり得るＤＲＸタイミング非同期化からの事前構成されたウェイクアップ時間回復の方法を示すフローチャートである。
【発明を実施するための形態】
【００１９】
（好ましい実施形態の説明）
図面がここで参照される。図１は、ロングタームエボリューション（ＬＴＥ）ユーザ面プロトコルスタックを例示するブロック図を示す。
【００２０】
ＵＥ１１０は、強化型ノードＢ（ｅＮＢ）１２０およびアクセスゲートウェイ（ａＧＷ）１３０の両方と通信する。
【００２１】
様々な層がプロトコルスタックに例示される。パケットデータ収束プロトコル（ＰＤＣＰ）層１４０が、ＵＥ１１０およびａＧＷ１３０の両方に例示される。ＰＤＣＰ層１４０は、インターネットプロトコル（ＩＰ）ヘッダ圧縮および解凍と、ユーザデータの暗号化と、ユーザデータの転送と、無線ベアラに対するシリアルナンバー（ＳＮ）のメンテナンスとを実行する。
【００２２】
ＰＤＣＰ層１４０の下には、ｅＮＢ１２０上の無線リンク制御プロトコル層１４２と通信する無線リンク制御プロトコル層１４２がある。理解されるように、通信は、図１および図２に例示されるようなプロトコルスタックにおいて物理層を介して行われる。しかしながら、ＵＥのＲＬＣ層１４２からのＲＬＣ−ＰＤＵは、ｅＮＢ１２０上のＲＬＣ層１４２によって解釈される。
【００２３】
ＲＬＣ層１４２の下には、媒体アクセス制御（ＭＡＣ）データ通信プロトコル層１４６がある。当業者によって理解されるように、ＲＬＣおよびＭＡＣプロトコルは、ＬＴＥ無線インタフェースのデータリンク副層を形成し、ＬＴＥおよびユーザ装置におけるｅＮＢ上にある。
【００２４】
層１（Ｌ１）ＬＴＥ（物理層１４８）は、ＲＬＣ／ＭＡＣ層１４４および１４６の下にある。この層は、通信のための物理層である。
【００２５】
図２を参照すると、図２は、ＬＴＥ制御面プロトコルアーキテクチャを例示する。図１において用いられる参照数字に類似の参照数字が、図２において用いられる。特に、ＵＥ１１０は、ｅＮＢ１２０およびａＧＷ１３０と通信する。さらに、物理層１４８、ＭＡＣ層１４６、ＲＬＣ層１４２およびＰＤＣＰ層１４０は、図２内に存在する。
【００２６】
図２はまた、非アクセスストラタム（ｎｏｎ−ａｃｃｅｓｓ ｓｔｒａｔｕｍ）（ＮＡＳ）層２１０を示す。理解されるように、ＮＡＳ層２１０は、移動管理およびセッション管理を含み得る。
【００２７】
無線資源制御プロトコル層（ＲＲＣ）２２０は、ＵＥとＥ−ＵＴＲＡＮ（進化型汎用地上無線アクセスネットワーク）との間の無線資源の割当てと、構成と、放出とに責任を負うプロトコルスタックの一部である。ＬＴＥのためのＲＲＣプロトコルの基本機能は、３ＧＰＰ ＴＲ２５．８１３において説明される。
【００２８】
当業者によって理解されるように、ＵＭＴＳにおいて、自動繰り返し要求（ＡＲＱ）機能は、無線ネットワークコントローラ（ＲＮＣ）にあるＲＬＣ層内で実行される。ロングタームエボリューション（ＬＴＥ）は、ＡＲＱ機能をＲＮＣからｅＮＢに移動させ、ｅＮＢにおいて、ＡＲＱとＨＡＲＱ（ＭＡＣ層内にあり、これもｅＮＢに位置を決められる）との間により緊密な相互作用が存在し得る。
【００２９】
ＬＴＥ＿ＡＣＴＩＶＥ状態におけるＤＲＸに関する様々な問題は、本明細書において考慮される。
【００３０】
（ＤＲＸ信号方式手順）
ＬＴＥ＿ＡＣＴＩＶＥ状態でＤＲＸを用いているセルにおいて、ＵＥの大母集団をサポートするためにＤＲＸを活動化、非活動化し、そしてＤＲＸ期間の持続期間を指定するための非常に効率的な信号方式手順が必要とされる。
【００３１】
当業者によって理解されるように、強化型ノードＢ（ｅＮＢ）がＤＲＸ動作によりＵＥの受信器のオフの期間中にＵＥにデータを送信する場合、ＵＥはデータを受信し得ない。従って、ＤＲＸが活動化されそして非活動化されるときに関してＵＥとｅＮＢとが同期されることを確実にするために特別の努力が必要とされる。
【００３２】
ｅＮＢとＵＥとの間の指示は、無線資源制御（ＲＲＣ）または層１／層２（Ｌ１／Ｌ２）の信号方式によって明示的に信号が送られ得る。しかしながら、理解されるように、明示的な信号方式は、所望されるほど効率的ではない場合がある。
【００３３】
より効率的な解決策は、ＤＲＸ活動化および非活動化を指示する、ＭＡＣ−ＰＤＵ（ＭＡＣプロトコルデータユニット）のＭＡＣヘッダまたはＭＡＣ制御ＰＤＵ（ＭＡＣ制御情報のみを含むＭＡＣ ＰＤＵ）にオプションのフィールドを含めることである。フィールドは、好ましくは活動化および非活動化のためのＤＲＸ値およびタイミング余裕を示す。０値は、例えば、好ましい実施形態においてＤＲＸ値フィールドにおけるＤＲＸ非活動化を意味し得る。逆に、次のＭＡＣ−ＰＤＵにおいて送信されるべきデータがＵＥのためのバッファにおける最後のデータである場合、ｅＮＢはＤＲＸ長初期値を含むようにＭＡＣヘッダフィールドを広げ得る。例えば、これは３２０ミリ秒であり得る。
【００３４】
ＭＡＣ−ＰＤＵヘッダ内のＤＲＸ期間に信号を送るいくつかの異なる方法が、考えられ得る。例えば、ＤＲＸ期間の８個の値を示すために３ビットがＭＡＣヘッダに追加され得る。従って特定の時間値が送られるよりはむしろ、０００から１１１までのビット値は、８個の別個の値のうちの１つを示し得る。
【００３５】
代替案においてＭＡＣヘッダにおける、より小さいフィールド（例えば２ビット）が、インクリメントまたはディクリメントを示すために用いられ得る。ＲＲＣはディフォルト値を示し得、ＭＡＣヘッダがインクリメントまたはディクリメントを示す場合、ＵＥは受信した指示に従って所定の値に変化し得る。同様にＲＲＣは、実際のＤＲＸと、より小さいフィールドに含まれる値との間のマッピングを定義し得る。
【００３６】
ＵＥが一旦ＤＲＸ値を受信すると、ＵＥは、ＨＡＲＫ ＡＣＫを送信することによってｅＮＢにＤＲＸ値の肯定応答し、伝播遅延およびｅＮＢにおける処理遅延を考慮して、適切なシステムフレームにおいてＤＲＸを開始させる。ｅＮＢがＵＥからＡＣＫを受信したとき、ｅＮＢもまた適切なシステムフレーム時間においてＤＲＸを開始させる。理解されるように、ｅＮＢはそのトランシーバをオフにしないで、単に個々のＵＥにメッセージを送信しないことを知っているだけである。
【００３７】
ＤＲＸ期間のウェイクアップサイクル中、新しいデータが送信のためにｅＮＢに到着した場合、バッファにおけるデータ量またはサービス要求の質に従って、ｅＮＢは、ヘッダ延長がＤＲＸ非活動化またはより短いＤＲＸ長に設定されて、ＭＡＣ−ＰＤＵを送り得る。ＵＥは、従ってＤＲＸを再構成し、ＭＡＣ−ＰＤＵの肯定応答をする。ｅＮＢがＡＣＫを受信したとき、ｅＮＢはＤＲＸを再構成する。上記のように、非活動化は単に長さ値を０に設定することによって達成され得る。
【００３８】
図３ａおよび図３ｂがここで参照される。図３ａは、ＬＴＥ＿ＡＣＴＩＶＥ状態においてＤＲＸ活動化を制御する例示的方法を示す。プロセスは、ステップ３００で開始し、ステップ３１０に進み、ステップ３１０においてデータはＵＥに送信される。当業者によって理解されるように、ＬＴＥ＿ＡＣＴＩＶＥ状態におけるデータ送信は、データリンク層においてＭＡＣ−ＰＤＵを用い、データを転送する。
【００３９】
プロセスは次にステップ３１２に進み、ステップ３１２においてＵＥに送られるデータのバッファが次の送信後に空であるかどうかを調べるためにチェックが行われる。空でなければ、プロセスはステップ３１０に戻り、ステップ３１０においてデータはＵＥに送信される。あるいは、バッファが次の送信後に空であり、データ到着速度が閾値よりも低い場合、プロセスはステップ３１４に進む。
【００４０】
ステップ３１４において、ｅＮＢは、ＭＡＣ−ＰＤＵヘッダにおいてＤＲＸ活動化を設定する。上記のように、ｅＮＢは、ＤＲＸ期間の長さ、および、必要な場合、例えばＤＲＸ活動化が実行されるときのシステム無線フレームナンバーなどのＤＲＸ活動時間を示すＤＲＸ活動化値を含む。別の実施形態において、ｅＮＢは、単にＤＲＸ間隔の増加を指示し得る。ＵＥは、現在のＤＲＸ間隔を所定の減少した間隔に再構成する。所定の間隔は、ｅＮＢおよびＵＥの両方に既知であるかまたは、システム同報通信またはＲＲＣ信号方式による明白な信号方式によってｅＮＢからＵＥに事前に信号を送られるかのいずれかであり得る。
【００４１】
プロセスは次いでステップ３１６に進み、ステップ３１６において修正されたＭＡＣ−ＰＤＵヘッダを含むデータは、ＵＥに送られる。
【００４２】
図３ｂがここで参照される。ステップ３１８において、ＵＥは、データを受信し、ＤＲＸ活動化がＭＡＣ−ＰＤＵヘッダに指定されていることを調べる。プロセスはステップ３２０に進み、ステップ３２０においてＵＥは、肯定応答（ＡＣＫ）をｅＮＢに送り、伝播遅延およびｅＮＢにおける処理遅延を考慮して、適切なシステムフレームにおいてＤＲＸを開始させる。指定されたＤＲＸの活動化時間が受信されたＭＡＣ−ＰＤＵヘッダにおいて指示される場合、ＵＥおよびｅＮＢの両方はその時間に新しいＤＲＸ値を適用する。
【００４３】
図３ａのステップ３３０において、ｅＮＢは、ＵＥからＡＣＫを受信し、同じ適切なシステムフレームにおいてＤＲＸを開始させる。
【００４４】
理解されるように、ＤＲＸが調整されることを要求し得る様々なイベントが起るまで、ＤＲＸは継続し得る。１つのイベントは、ＵＥのためのｅＮＢによるａＧＷからのデータの受信である。受信されたデータ量に従って、ＤＲＸが非活動化されるかまたはＤＲＸの期間が減少され得る。ＤＲＸの調整を必要とし得る他のイベントは、ｅＮＢとＵＥとの間の信号出力レベルの変化、または、とりわけ継続したデータの非活動性によるＤＲＸにおけるゆるやかな増加を含む。
【００４５】
ステップ３３２において、ｅＮＢは、ＤＲＸが調整される必要があるかどうかを調べるためにチェックする。上記のように、これは、ＵＥに送られるデータが受信される状況であり得る。ここで、ＤＲＸが非活動化されるか、または期間が調整され得る。
【００４６】
ステップ３３２から、ＤＲＸが調整される必要がない場合、プロセスはステップ３３２に戻り、ＤＲＸが調整される必要があるかないかをチェックし続ける。
【００４７】
ステップ３３２におけるプロセスが一旦、ＤＲＸが調整される必要がないということを見つけると、プロセスは、ステップ３３４に進み、ステップ３３４において、ＤＲＸを調整する。このことは、ＤＲＸに対して０値を送信するか、または必要に応じ、より短いＤＲＸかまたはより長いＤＲＸを送信することによってＤＲＸを非活動化し得る。
【００４８】
修正されたヘッダ（修正されたＤＲＸ値および必要に応じ新しいＤＲＸ値に対する活動化時間を含む）を有するＭＡＣ−ＰＤＵは、ステップ３３６においてＵＥに送られる。ステップ３３６おけるＭＡＣ−ＰＤＵはまた、ＵＥに送信される必要のある、ｅＮＢによって受信された任意のデータを含み得る。どのデータも含まれない場合、ＭＡＣ−ＰＤＵは、ＭＡＣ制御ＰＤＵであると考えられる。
【００４９】
図３ｂを参照すると、プロセスは次いで、ステップ３１８に進み、ステップ３１８において、修正されたヘッダを有するＭＡＣ−ＰＤＵは、ＵＥにおいて受信される。ＵＥは、ＤＲＸ期間が調整されることを認識し、ステップ３２０においてＵＥは、肯定応答をｅＮＢに送り、伝播遅延およびｅＮＢにおける処理遅延を考慮して、適切なシステムフレームにおいてＵＥのＤＲＸ期間を調整する。活動化時間がＭＡＣ−ＰＤＵヘッダにおいて指示される場合、ＵＥおよびｅＮＢの両方はその時間に新しいＤＲＸ値を適用する。
【００５０】
図３ａを参照すると、ステップ３４２において、ｅＮＢは、ＡＣＫを受信し、同じ適切なシステムフレームにおいて修正されたＤＲＸ期間を開始させる。プロセスは次いでステップ３３２に戻り、ＤＲＸが再び調整される必要があるかどうかを調べる。
【００５１】
当業者によって理解されるように、上記に関する１つの問題は、ＡＣＫまたはＮＡＣＫの誤った解釈の場合に起る。特に、ＡＲＱエラー制御方法の変形である、送信器のハイブリッド自動繰返し要求（ＨＡＲＱ）エンティティは、おそらく不良のチャネル状態によりＡＣＫまたはＮＡＣＫを必ずしも常に正しく復調するとは限らない。従って、一部の状況において、一方がもう一方のものとして解釈され得る。ＤＲＸ活動化および非活動化をＭＡＣ−ＰＤＵヘッダに起こすことによって、ＡＣＫからＮＡＣＫまたはＮＡＣＫからＡＣＫへの誤った解釈は、ｅＮＢとＵＥとの間で信号送信された制御情報の誤った解釈がデータまたはおそらくは無線接続の喪失に導き得るので、処理される必要がある。
【００５２】
（ＤＲＸ自動インクリメンテーション）
さらなる考慮は、ＤＲＸのインクリメントの拡張である。好ましい実施形態において、ＤＲＸ期間がインクリメントまたはディクリメントされ得る仕方（例えば、２の因数によって）を指示する規則は、無線ベアラ（ｒａｄｉｏ ｂｅａｒｅｒ）（ＲＢ）セットアップ中に信号が送られ得る。規則は、ＲＲＣ ＲＢセットアップ／再構成または測定制御メッセージでＵＥに運ばれる。この場合、Ｎの現在のＤＲＸサイクル後にどのデータも受信されない場合、ｅＮＢおよびＵＥは、ＤＲＸ長を次のより大きな値に自動的に増加させる。このことは、ＤＲＸ長を増加させるためにｅＮＢとＵＥとの間へ信号を送る必要性を除去し、従ってネットワーク資源および電池資源を節約する。
【００５３】
（システム情報におけるＤＲＸタイミング非同期化の指示）
ＵＥがＵＥのＤＲＸタイミング内において同期がずれているとｅＮＢが決定したとき、ｅＮＢは所定のシステム情報ブロックにおいてＵＥのＲＮＴＩを示す。ＵＥがウェイクアップすると、ＵＥはシステム情報ブロックを読み取る。ＵＥのＲＮＴＩが指示された場合、ＵＥは、ＤＲＸモードを非活動化し、ｅＮＢへのＬ１／Ｌ２の信号方式またはＭＡＣ信号方式を用いて連続受信通知メッセージを送信する。連続受信通知メッセージの受信次第、ｅＮＢはバッファ内で待つデータをＵＥに再送信する。データが肯定応答されるか、またはＵＥからのＨＡＲＱフィードバックが受信されたとき、ｅＮＢはシステム情報からＲＮＴＩを除去する。
【００５４】
図４ａがここで参照される。図４ａは、システム情報においてＲＮＴＩに信号を送り、ＤＲＸ非同期化から回復する方法のフローチャートを示す。プロセスはステップ４１０で開始する。
【００５５】
プロセスはステップ４１２に進み、ステップ４１２においてｅＮＢは次のＭＡＣ−ＰＤＵを送信する。
【００５６】
プロセスは次いで、ステップ４１４に進み、ステップ４１４においてプロセスは、ＤＲＸタイミング非同期化が起こったかどうかをチェックする。上記のように、これは、ｅＮＢがどのＨＡＲＱフィードバック信号もＵＥから入手しない場合であり得、この場合ｅＮＢはＤＲＸタイミングにおいて同期がずれていることを考慮し得る。
【００５７】
ステップ４１４において、どのＤＲＸタイミング非同期化も検出されない場合、プロセスは、ステップ４１２に戻り、ＤＲＸタイミング非同期化が検出されるまで継続する。
【００５８】
ステップ４１４においてＤＲＸタイミング非同期化が検出された場合、プロセスはステップ４１６に進み、ステップ４１６においてＵＥのＲＮＴＩは、所定のシステム情報ブロックに追加される。理解されるように、ＵＥは、ＤＲＸからウェイクアップしたとき、下記の図４ｂを参照して説明されるように、システム情報チェックし、ＵＥのＲＮＴＩを検出する。
【００５９】
図４ａにおけるステップ４１６から、プロセスは次いで、連続受信通知メッセージを待つ。連続受信通知メッセージがステップ４１８において受信される場合、プロセスはステップ４２０に進み、ステップ４２０においてプロセスは、ＭＡＣ−ＰＤＵを再送信する。理解されるように、これは、ステップ４１４においてＤＲＸタイミング非同期化が検出される前に、ｅＮＢがステップ４１２において送信を試みたことと同じＭＡＣ−ＰＤＵであり得る。ＭＡＣ−ＰＤＵの再送信はステップ４２０で行われる。
【００６０】
プロセスは、次いでステップ４２２に進み、ステップ４２２においてプロセスは成功またはＨＡＲＱフィードバックが受信されたかをチェックする。
【００６１】
ステップ４１８において、連続受信通知メッセージが受信されないかまたはステップ４２２において、成功またはＨＡＲＱフィードバックが受信されない場合、プロセスはステップ４３０に進み、ステップ４３０においてハンドオーバが起ったかまたはＲＲＣ接続が解除されたかどうかを調べるためにチェックがなされる。
【００６２】
ステップ４３０において別のセルへのハンドオーバが検出されるかまたはＲＲＣ接続が解除されるのが見つかった場合、プロセスはステップ４３５に進み、ステップ４３５においてＵＥのＲＮＴＩは、所定のシステム情報ブロックから除去される。同様に、ステップ４２２から成功が達成されるかまたはＨＡＲＱフィードバックが受信される場合、プロセスは、ステップ４３５に進み、ステップ４３５においてＵＥのＲＮＴＩが所定のシステム情報ブロックから除去される。
【００６３】
プロセスは次いで、ステップ４３５からステップ４４０に進み、ステップ４４０においてプロセスは終了する。
【００６４】
あるいは、ステップ４３０において別のセルへのハンドオーバまたはＲＲＣ接続解除が見つかった場合、プロセスは４４０に進み、ステップ４４０においてプロセスは終了する。
【００６５】
図４ｂがここで参照される。ＵＥ側において、プロセスはステップ４５０において開始する。
【００６６】
ステップ４５２において、ＵＥはＤＲＸからウェイクアップする。
【００６７】
プロセスは次いでステップ４５４に進み、ステップ４５４においてＵＥは、データがダウンリンク共用制御チャネル（ＤＬＳＣＣＨ）に指示された場合データを受信し、測定または必要に応じて他の機能を実行する。
【００６８】
プロセスは次いでステップ４５６に進み、ステップ４５６においてプロセスは、ＤＲＸタイミング非同期化においてＵＥのリストのために所定のシステム情報ブロックを読み取る。
【００６９】
プロセスは次いでステップ４６０に進み、ステップ４６０においてプロセスは、ＵＥのＲＮＴＩがシステム情報ブロックにおけるＵＥのリストに含まれるかどうかをチェックする。含まれない場合、ＵＥはステップ４６２におけるＤＲＸに戻り、次いでステップ４５２においてＤＲＸのウェイクアップを待つ。
【００７０】
あるいは、ステップ４６０から、ＵＥのＲＮＴＩがシステム情報ブロックに含まれる場合、プロセスはステップ４６６に進み、ステップ４６６においてＤＲＸは非活動化され、連続受信が開始される。
【００７１】
プロセスは次いで、ステップ４６８に進み、ステップ４６８において連続受信通知は送信され、ステップ４７０においてプロセスが終了する。
【００７２】
上記から理解されるように、非同期化は従って、所定のシステム情報ブロックにおいてＵＥがそのＲＮＴＩを検出することによって次のＤＲＸサイクルにおいて回復される。
【００７３】
（起こり得るＤＲＸタイミング非同期からの回復のための事前構成されたウェイクアップ時間）
さらなる実施形態において、会話形通信もしくは背景通信のための無線ベアラが設定されたときまたはそのベアラにおいてＤＲＸが活動化されたとき、絶対ウェイクアップ時間がＲＲＣによってＵＥに通知され得る。絶対ウェイクアップタイミングは、システム無線フレームタイミングに対する無線フレームオフセット（ＡＲＦｏｆｆ）およびＤＲＸ間隔（ＡＩＮＴ）によって定義される。現在のＤＲＸ設定に関わらず、ＵＥはＡＲＦｏｆｆ＋Ｎ＊ＡＩｎｔの無線フレームにおいてウェイクアップしなければならない。ここでＮは整数である。
【００７４】
プロセスはステップ５１０において開始し、ステップ５１２に進み、ステップ５１２において次のＭＡＣ−ＰＤＵが送信される。
【００７５】
プロセスは、次いでステップ５１４に進み、ステップ５１４においてｅＮＢは、ＤＲＸに対するタイミング非同期化が起こったかどうかを調べるためにチェックする。上記のように、これはＵＥからのＨＡＲＱフィードバックの受信の不足に基づき起こり得る。
【００７６】
ＤＲＸタイミング非同期化がステップ５１４において検出されない場合、プロセスはステップ５１２に戻り、次のＭＡＣ−ＰＤＵを送信し続ける。
【００７７】
ステップ５１４から、ＤＲＸタイミング非同期化が検出された場合、プロセスはステップ５２０に進み、ステップ５２０において連続受信コマンドが、無線資源制御によって構成される絶対ウェイクアップ時間に送信される。
【００７８】
プロセスは次いで、ステップ５２２に進み、ステップ５２２においてプロセスは、連続受信応答がＵＥから受信されたかどうかをチェックする。受信された場合、プロセスはステップ５２４に進み、ステップ５２４において、どのＨＡＲＱフィードバックも受信されないステップ５１２からのＭＡＣ−ＰＤＵが、ステップ５２４において再送信される。
【００７９】
プロセスは次いで５２６に進み、ステップ５２６においてプロセスは、成功があるかどうかまたはＨＡＲＱフィードバックが受信されたかどうかをチェックする。そうである場合、プロセスはステップ５３０において終了する。
【００８０】
ステップ５２２から、連続受信応答が受信されなかった場合、またはステップ５２６から、ＨＡＲＱフィードバックが受信されないかもしくはどの成功も決定されなかった場合、プロセスはステップ５４０に進み、ステップ５４０においてハンドオーバが起ったかまたはＲＲＣ接続が解除されたかどうかを調べるためにチェックがなされる。ハンドオーバが起ったかまたはＲＲＣ接続が解除されたということがステップ５４０において決定された場合、プロセスはステップ５３０に進み、終了する。
【００８１】
ステップ５４０において、どのハンドオーバも起らなかったかまたはＲＲＣ接続が解除されたということが決定された場合、プロセスはステップ５４２に進み、ステップ５４２においてプロセスは再試行期間が終了するかどうかをチェックする。終了しない場合、プロセスはステップ５２０に戻る。終了する場合、プロセスはステップ５４４に進み、ステップ５４４においてＲＲＣ接続が解除され、プロセスは次いでステップ５３０において終了する。
【００８２】
図５ｂがここで参照される。ＵＥの観点から、プロセスはステップ５５０において開始し、ステップ５５２に進み、ステップ５５２においてＵＥはＤＲＸからウェイクアップする。プロセスは次いでステップ５５４に進み、ステップ５５４においてＵＥは、データがダウンリンク共用制御チャネル（ＤＬＳＣＣＨ）に指示された場合データを受信し、測定または必要に応じて他の機能を実行する。
【００８３】
プロセスは次いでステップ５５６に進み、ステップ５５６においてプロセスは、時間が絶対ウェイクアップ時間であるかどうかをチェックする。絶対ウェイクアップ時間である場合、プロセスはステップ５５８に進み、ステップ５５８においてＵＥは、連続受信コマンドが受信されたかどうかをチェックする。
【００８４】
ステップ５５６から、時間が絶対ウェイクアップ時間でない場合、またはステップ５５８において連続受信コマンドが受信されなかった場合、プロセスはステップ５６０に進み、ステップ５６０においてＵＥはＤＲＸに戻る。ステップ５６０からプロセスは、ステップ５５２においてＤＲＸからウェイクアップすることによって継続する。
【００８５】
あるいは、連続受信コマンドがステップ５５８において受信される場合、プロセスはステップ５７０に進み、ステップ５７０においてＤＲＸが非活動化され、連続受信が開始される。プロセスは次いで、ステップ５７２に進み、ステップ５７２において連続受信応答が送信され、プロセスはステップ５７４において終了する。
【００８６】
上記に基づき、ＤＲＸタイミングにおいてＵＥの同期がずれていることをｅＮＢが検出したとき、ｅＮＢは、Ｌ１／Ｌ２信号方式またはＭＡＣ信号方式における連続受信コマンドを絶対ウェイクアップ時間にＵＥに送る。ＵＥは、絶対ウェイクアップ時間にウェイクアップし、連続受信コマンドが受信されたか否かをチェックし、受信された場合、ＵＥはそのトランシーバの電源を入れ、連続受信に戻る。
【００８７】
さらなる代替案において、絶対ウェイクアップ無線フレームオフセットＡＲＦｏｆｆは、３ＧＰＰ ＴＳ２５．３０４に説明されるＵＭＴＳにおいてページング機会が計算される方法と類似する方法で、ＩＭＳＩなどのＵＥアイデンティティから計算され得る。そのような場合において、ＤＲＸ間隔は、専用のＲＲＣメッセージを介してセーブされるよりはむしろシステム情報に含まれ得る。
【００８８】
理解されるように、ＡＲＦｏｆｆの信号をＵＥに送る利益は、ｅＮＢが絶対ウェイクアップ時間を現在のＤＲＸ設定に整合させ得、その結果、さらなる電池節約が達成され得ることである。
【００８９】
本明細書において説明される実施形態は、本開示の技術の要素に対応する要素を有する構造、システムまたは方法の例である。この説明は、当業者が本開示の要素または技術に同様に対応する代替の要素を有する実施形態を用いることを可能にし得る。従って本開示の技術の意図された範囲は、本明細書において説明される本開示の技術とは異ならない構造、システムまたは方法を含み、本明細書において説明される本開示の技術とは実質的でない相違を有する他の構造、システムまたは方法をさらに含む。
【特許請求の範囲】
【請求項１】
ワイヤレス通信ネットワークにおいてユーザ装置（ＵＥ）を動作させる方法であって、前記方法は、前記ＵＥによって実行され、
前記方法は、
前記ＵＥが不連続受信（ＤＲＸ）動作にある間に、オフセットにＮ倍されたＤＲＸ間隔を加えた値に基づいて、ウェイクアップ時間において、前記ＵＥの受信器をウェイクアップすることであって、Ｎは、ゼロ以上の整数である、ことと、
前記ＵＥがウェイクアップしている間に、前記ＵＥに対してアドレス指定されたデータがネットワーク要素から入手可能であるかどうかをチェックすることと
を含む、方法。
【請求項２】
前記オフセットまたは前記ＤＲＸ間隔のうちの少なくとも１つを含む無線資源制御（ＲＲＣ）プロトコルメッセージを受信することをさらに含む、請求項１に記載の方法。
【請求項３】
前記ＵＥは、ロングタームエボリューション（ＬＴＥ）ネットワークと関連付けられるように構成されている、請求項１に記載の方法。
【請求項４】
ワイヤレス通信ネットワークにおいて動作するユーザ装置（ＵＥ）であって、
前記ＵＥは、
ワイヤレス受信器と、
プロセッサと
を含み、
前記ＵＥが不連続受信（ＤＲＸ）動作にある間に、前記ＵＥは、オフセットにＮ倍されたＤＲＸ間隔を加えた値に基づいて、ウェイクアップ時間において、前記受信器をウェイクアップするように構成されており、Ｎは、ゼロ以上の整数であり、
前記ＵＥは、前記ＵＥがウェイクアップしている間に、前記ＵＥに対してアドレス指定されたデータがネットワーク要素から入手可能であるかどうかをチェックするようにさらに構成されている、ユーザ装置。
【請求項５】
前記ＵＥは、前記オフセットまたは前記ＤＲＸ間隔のうちの少なくとも１つを含む無線資源制御（ＲＲＣ）プロトコルメッセージを受信するようにさらに構成されている、請求項４に記載のユーザ装置。
【請求項６】
前記ＵＥは、ロングタームエボリューション（ＬＴＥ）ネットワークと関連付けられるように構成されている、請求項４に記載のユーザ装置。
【請求項７】
ワイヤレス通信ネットワークにおいて動作する強化型ノードＢ（ｅＮＢ）であって、
前記ｅＮＢは、
ユーザ装置（ＵＥ）と通信することにより、前記ＵＥを構成するように構成された通信サブシステムであって、前記ＵＥが不連続受信（ＤＲＸ）動作にある間に、オフセットにＮ倍されたＤＲＸ間隔を加えた値に基づいて、ウェイクアップ時間において、前記ＵＥがウェイクアップすることであって、Ｎは、ゼロ以上の整数である、通信サブシステム
を含み、
前記ｅＮＢは、前記ＵＥがウェイクアップしている間に、前記ＵＥに対してデータを送るように構成されている、ｅＮＢ。
【請求項８】
前記ｅＮＢは、前記オフセットまたは前記ＤＲＸ間隔のうちの少なくとも１つを含む無線資源制御（ＲＲＣ）プロトコルメッセージを送信するように構成されている、請求項７に記載のｅＮＢ。
【請求項９】
前記ｅＮＢは、ロングタームエボリューション（ＬＴＥ）ネットワークの一部分である、請求項７に記載のｅＮＢ。
【請求項１０】
ワイヤレス通信ネットワークにおいて強化型ノードＢ（ｅＮＢ）を動作させる方法であって、前記方法は、前記ｅＮＢによって実行され、
前記方法は、
ユーザ装置（ＵＥ）と通信することにより、前記ＵＥを構成することであって、前記ＵＥが不連続受信（ＤＲＸ）動作にある間に、オフセットにＮ倍されたＤＲＸ間隔を加えた値に基づいて、ウェイクアップ時間において、前記ＵＥがウェイクアップすることであって、Ｎは、ゼロ以上の整数である、ことと、
前記ＵＥがウェイクアップしている間に、前記ＵＥに対してデータを送信することと
を含む、方法。
【請求項１１】
前記ユーザ装置と通信することは、前記オフセットまたは前記ＤＲＸ間隔のうちの少なくとも１つを含む無線資源制御（ＲＲＣ）プロトコルメッセージを送ることを含む、請求項１０に記載の方法。
【請求項１２】
前記ｅＮＢは、ロングタームエボリューション（ＬＴＥ）ネットワークの一部分である、請求項１０に記載の方法。
【請求項１】
ワイヤレス通信ネットワークにおいてユーザ装置（ＵＥ）を動作させる方法であって、前記方法は、前記ＵＥによって実行され、
前記方法は、
前記ＵＥが不連続受信（ＤＲＸ）動作にある間に、オフセットにＮ倍されたＤＲＸ間隔を加えた値に基づいて、ウェイクアップ時間において、前記ＵＥの受信器をウェイクアップすることであって、Ｎは、ゼロ以上の整数である、ことと、
前記ＵＥがウェイクアップしている間に、前記ＵＥに対してアドレス指定されたデータがネットワーク要素から入手可能であるかどうかをチェックすることと
を含む、方法。
【請求項２】
前記オフセットまたは前記ＤＲＸ間隔のうちの少なくとも１つを含む無線資源制御（ＲＲＣ）プロトコルメッセージを受信することをさらに含む、請求項１に記載の方法。
【請求項３】
前記ＵＥは、ロングタームエボリューション（ＬＴＥ）ネットワークと関連付けられるように構成されている、請求項１に記載の方法。
【請求項４】
ワイヤレス通信ネットワークにおいて動作するユーザ装置（ＵＥ）であって、
前記ＵＥは、
ワイヤレス受信器と、
プロセッサと
を含み、
前記ＵＥが不連続受信（ＤＲＸ）動作にある間に、前記ＵＥは、オフセットにＮ倍されたＤＲＸ間隔を加えた値に基づいて、ウェイクアップ時間において、前記受信器をウェイクアップするように構成されており、Ｎは、ゼロ以上の整数であり、
前記ＵＥは、前記ＵＥがウェイクアップしている間に、前記ＵＥに対してアドレス指定されたデータがネットワーク要素から入手可能であるかどうかをチェックするようにさらに構成されている、ユーザ装置。
【請求項５】
前記ＵＥは、前記オフセットまたは前記ＤＲＸ間隔のうちの少なくとも１つを含む無線資源制御（ＲＲＣ）プロトコルメッセージを受信するようにさらに構成されている、請求項４に記載のユーザ装置。
【請求項６】
前記ＵＥは、ロングタームエボリューション（ＬＴＥ）ネットワークと関連付けられるように構成されている、請求項４に記載のユーザ装置。
【請求項７】
ワイヤレス通信ネットワークにおいて動作する強化型ノードＢ（ｅＮＢ）であって、
前記ｅＮＢは、
ユーザ装置（ＵＥ）と通信することにより、前記ＵＥを構成するように構成された通信サブシステムであって、前記ＵＥが不連続受信（ＤＲＸ）動作にある間に、オフセットにＮ倍されたＤＲＸ間隔を加えた値に基づいて、ウェイクアップ時間において、前記ＵＥがウェイクアップすることであって、Ｎは、ゼロ以上の整数である、通信サブシステム
を含み、
前記ｅＮＢは、前記ＵＥがウェイクアップしている間に、前記ＵＥに対してデータを送るように構成されている、ｅＮＢ。
【請求項８】
前記ｅＮＢは、前記オフセットまたは前記ＤＲＸ間隔のうちの少なくとも１つを含む無線資源制御（ＲＲＣ）プロトコルメッセージを送信するように構成されている、請求項７に記載のｅＮＢ。
【請求項９】
前記ｅＮＢは、ロングタームエボリューション（ＬＴＥ）ネットワークの一部分である、請求項７に記載のｅＮＢ。
【請求項１０】
ワイヤレス通信ネットワークにおいて強化型ノードＢ（ｅＮＢ）を動作させる方法であって、前記方法は、前記ｅＮＢによって実行され、
前記方法は、
ユーザ装置（ＵＥ）と通信することにより、前記ＵＥを構成することであって、前記ＵＥが不連続受信（ＤＲＸ）動作にある間に、オフセットにＮ倍されたＤＲＸ間隔を加えた値に基づいて、ウェイクアップ時間において、前記ＵＥがウェイクアップすることであって、Ｎは、ゼロ以上の整数である、ことと、
前記ＵＥがウェイクアップしている間に、前記ＵＥに対してデータを送信することと
を含む、方法。
【請求項１１】
前記ユーザ装置と通信することは、前記オフセットまたは前記ＤＲＸ間隔のうちの少なくとも１つを含む無線資源制御（ＲＲＣ）プロトコルメッセージを送ることを含む、請求項１０に記載の方法。
【請求項１２】
前記ｅＮＢは、ロングタームエボリューション（ＬＴＥ）ネットワークの一部分である、請求項１０に記載の方法。
【図３ａ】
【図３ｂ】
【図４ａ】
【図４ｂ】
【図５ａ】
【図５ｂ】
【図１】
【図２】
【図３ｂ】
【図４ａ】
【図４ｂ】
【図５ａ】
【図５ｂ】
【図１】
【図２】
【公開番号】特開２０１２−１３５０５８（Ｐ２０１２−１３５０５８Ａ）
【公開日】平成２４年７月１２日（２０１２．７．１２）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−８９４６６（Ｐ２０１２−８９４６６）
【出願日】平成２４年４月１０日（２０１２．４．１０）
【分割の表示】特願２００９−５４９３４５（Ｐ２００９−５４９３４５）の分割
【原出願日】平成２０年２月１２日（２００８．２．１２）
【出願人】（５０００４３５７４）リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Ｒｅｓｅａｒｃｈ Ｉｎ Ｍｏｔｉｏｎ Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】２９５ Ｐｈｉｌｌｉｐ Ｓｔｒｅｅｔ， Ｗａｔｅｒｌｏｏ， Ｏｎｔａｒｉｏ Ｎ２Ｌ ３Ｗ８ Ｃａｎａｄａ
【Ｆターム（参考）】
【公開日】平成２４年７月１２日（２０１２．７．１２）
【国際特許分類】
【出願番号】特願２０１２−８９４６６（Ｐ２０１２−８９４６６）
【出願日】平成２４年４月１０日（２０１２．４．１０）
【分割の表示】特願２００９−５４９３４５（Ｐ２００９−５４９３４５）の分割
【原出願日】平成２０年２月１２日（２００８．２．１２）
【出願人】（５０００４３５７４）リサーチ イン モーション リミテッド (531)
【氏名又は名称原語表記】Ｒｅｓｅａｒｃｈ Ｉｎ Ｍｏｔｉｏｎ Ｌｉｍｉｔｅｄ
【住所又は居所原語表記】２９５ Ｐｈｉｌｌｉｐ Ｓｔｒｅｅｔ， Ｗａｔｅｒｌｏｏ， Ｏｎｔａｒｉｏ Ｎ２Ｌ ３Ｗ８ Ｃａｎａｄａ
【Ｆターム（参考）】
[ Back to top ]