特許 6367254 無線通信システムにおける拡張されたユーザ設備支援情報のための装置、方法及びコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6367254

(24)【登録日】2018年7月13日

(45)【発行日】2018年8月1日

(54)【発明の名称】無線通信システムにおける拡張されたユーザ設備支援情報のための装置、方法及びコンピュータプログラム

(51)【国際特許分類】

   H04W 52/02 20090101AFI20180723BHJP

   H04W 52/28 20090101ALI20180723BHJP

   H04W 76/20 20180101ALI20180723BHJP

【ＦＩ】

   H04W52/02 111

   H04W52/28

   H04W76/20

【請求項の数】7

【外国語出願】

【全頁数】20

(21)【出願番号】特願2016-57889(P2016-57889)

(22)【出願日】2016年3月23日

(62)【分割の表示】特願2015-510518(P2015-510518)の分割

【原出願日】2013年5月11日

(65)【公開番号】特開2016-136767(P2016-136767A)

(43)【公開日】2016年7月28日

【審査請求日】2016年3月23日

(31)【優先権主張番号】61/646,223

(32)【優先日】2012年5月11日

(33)【優先権主張国】US

(31)【優先権主張番号】13/719,362

(32)【優先日】2012年12月19日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】コチ，アリ ティー．

(72)【発明者】

【氏名】マルティネス タラデル，マルタ

(72)【発明者】

【氏名】バンゴラエ，サンギータ エル．

(72)【発明者】

【氏名】ジャハ，サティシュ シー．

(72)【発明者】

【氏名】ヴァニサムビー，ラス

(72)【発明者】

【氏名】ジュウ，ジーン

【審査官】 望月 章俊

(56)【参考文献】

【文献】 特表２００９−５０５４８３（ＪＰ，Ａ）

【文献】 特表２０１０−５２２４９９（ＪＰ，Ａ）

【文献】 国際公開第２００７／１４５０３５（ＷＯ，Ａ１）

【文献】 Intel Corporation，Evaluation of UE Power Consumption and Latency using DRX Parameters Switching，3GPP TSG-RAN WG2 #77b R2-121747，２０１２年 ３月２０日

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｗ４／００−Ｈ０４Ｗ９９／００

Ｈ０４Ｂ７／２４−Ｈ０４Ｂ７／２６

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

ユーザ設備（ＵＥ）のための方法であって、
３ＧＰＰ ＬＴＥ無線ネットワークにおけるアップリンク専用制御チャネル（ＵＬ−ＤＣＣＨ）メッセージを生成するステップであって、該ＵＬ−ＤＣＣＨメッセージは、電力節約設定の選択においてｅＮｏｄｅＢを支援するよう、単一ビットを有する電力選好インジケーションパラメータを含む、ステップと、
前記電力選好インジケーションパラメータの前記単一ビットを通常電力消費設定又は低電力消費設定のいずれか一方に設定するステップと、
前記設定された電力選好インジケーションパラメータが、前に送信されたＵＬ−ＤＣＣＨメッセージに含まれた電力選好インジケーションパラメータと異なる場合に、前記ｅＮｏｄｅＢへの前記ＵＬ−ＤＣＣＨメッセージの送信を開始するステップと、
前記ｅＮｏｄｅＢによって選択された前記電力節約設定を処理するステップと
を有する方法。

【請求項2】

前記選択された電力節約設定は、間欠受信（ＤＲＸ）設定を有する、
請求項１に記載の方法。

【請求項3】

コンピュータによって実行される場合に、該コンピュータに、
電力節約設定の選択においてｅＮｏｄｅＢを支援するよう、単一ビットを有する電力選好インジケーションパラメータを含むアップリンク専用制御チャネル（ＵＬ−ＤＣＣＨ）メッセージを生成するステップと、
前記電力選好インジケーションパラメータの前記単一ビットを通常電力消費設定又は低電力消費設定のいずれか一方に設定するステップと、
前記設定された電力選好インジケーションパラメータが、前に送信されたＵＬ−ＤＣＣＨメッセージに含まれた電力選好インジケーションパラメータと異なる場合に、前記ｅＮｏｄｅＢへの前記ＵＬ−ＤＣＣＨメッセージの送信を開始するステップと、
前記ｅＮｏｄｅＢによって選択された前記電力節約設定を処理するステップと
を有する方法を実施させるコンピュータプログラム。

【請求項4】

前記選択された電力節約設定は、間欠受信（ＤＲＸ）設定を有する、
請求項３に記載のコンピュータプログラム。

【請求項5】

ユーザ設備（ＵＥ）のための装置であって、
電力節約設定の選択においてｅＮｏｄｅＢを支援するよう、単一ビットを有する電力選好インジケーションパラメータを含むアップリンク専用制御チャネル（ＵＬ−ＤＣＣＨ）メッセージを生成する手段と、
前記電力選好インジケーションパラメータの前記単一ビットを通常電力消費設定又は低電力消費設定のいずれか一方に選択的に設定する手段と、
前記設定された電力選好インジケーションパラメータが、前に送信されたＵＬ−ＤＣＣＨメッセージに含まれた電力選好インジケーションパラメータと異なる場合に、前記ｅＮｏｄｅＢへの前記ＵＬ−ＤＣＣＨメッセージの送信を開始する手段と、
前記ｅＮｏｄｅＢによって選択された前記電力節約設定を処理する手段と
を有する装置。

【請求項6】

前記ｅＮｏｄｅＢによって選択された前記電力節約設定は、間欠受信（ＤＲＸ）設定を有する、
請求項５に記載の装置。

【請求項7】

請求項３又は４に記載のコンピュータプログラムを記憶しているコンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、無線通信ネットワークに関する。具体的に、本開示は、無線通信システムにおいてノード間で拡張されたユーザ設備支援情報を通信するシステム及び方法に関する。

【背景技術】

【0002】

無線モバイル通信技術は、基地局と無線モバイル装置との間でデータを送信するために、様々な標準規格及びプロトコルを使用する。無線通信システムの標準規格及びプロトコルは、３ＧＰＰ（third generation partnership project）ＬＴＥ（long term evolution）、ＷｉＭａｘ（Worldwide interoperability for Microwave Access）として業界団体に広く知られているＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１６スタンダード、及びＷｉＦｉとして業界団体に広く知られているＩＥＥＥ８０２．１１スタンダードを含むことができる。ＬＴＥシステムにおける３ＧＰＰ無線アクセスネットワーク（radio access network）（ＲＡＮ）において、基地局は、Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）ノードＢ（一般的にエボルブドＮｏｄｅ Ｂ、エンハンスドＮｏｄｅ Ｂ、ｅＮｏｄｅＢ、又はｅＮＢとも表される。）とＥ−ＵＴＲＡＮ内の無線ネットワークコントローラ（Radio Network Controller）（ＲＮＣ）との組み合わせであることができ、ユーザ設備（user equipment）（ＵＥ）として知られる無線モバイル装置と通信する。ダウンリンク（ＤＬ）伝送は、基地局（すなわち、ｅＮｏｄｅＢ）から無線モバイル装置（すなわち、ＵＥ）への通信であることができ、アップリンク（ＵＬ）伝送は、無線モバイル装置から基地局への通信であることができる。

【0003】

従前のＬＴＥシステムを含む多くの無線システムにおいて、ＵＥは、ＵＥのバッテリを長持ちさせ及び／又はＵＥで実行されるアプリケーションについてより良い性能（例えば、レイテンシーに関する。）を達成する特定の機能及び処理に対してほとんど又は全く制御を有さない。むしろ、多くのそのような機能及び処理は、ＵＥからの入力によらずにｅＮｏｄｅＢによって決定される。

【図面の簡単な説明】

【0004】

【図1】一実施形態に従って、ＵＥがＵＥ支援情報をｅＮｏｄｅＢへ送信する例を表す。

【図2A】特定の実施形態に従って、トラフィックタイプ情報を含むＵＥ支援情報のデータ構造を表す。

【図2B】特定の実施形態に従って、トラフィックタイプ情報を含むＵＥ支援情報のデータ構造を表す。

【図3A】一実施形態に従って、タイプ識別子及び１以上の到着間隔の値を含むＵＥ支援情報のデータ構造を表す。

【図3B】一実施形態に従って、異なるトラフィックタイプについて、図３に示されたタイプ識別子の記述例を表す。

【図4】一実施形態に従って、パケット到着間隔又は次回パケット到着時間を選択的に報告するフローチャートである。

【図5A】一実施形態に従って、トグルビットを含むＵＥ支援情報のデータ構造を表す。

【図5B】特定の実施形態に従って、図５Ａに示されたトグルビットの記述例を表す。

【図6】一実施形態に従って、移動状態インジケータビットを含むＵＥ支援情報のデータ構造を表す。

【図7】一実施形態に従って、トラフィックタイプビットを含むＵＥ支援情報のデータ構造を表す。

【図8】一実施形態に従って、電力選好ビットを含むＵＥ支援情報のデータ構造を表す。

【図9】特定の例となる実施形態に従って、ＵＥとｅＮｏｄｅＢとの間のＵＥ支援情報のやり取りを表す。

【図10】一実施形態に従って、間欠受信パラメータのセットを選択又は変更する方法のフローチャートである。

【図11】本願で開示される実施形態の１又はそれ以上により使用され得るモバイル装置の実例を提供する。

【発明を実施するための形態】

【0005】

本開示の実施形態と一致するシステム及び方法の詳細な説明が以下で与えられる。幾つかの実施形態が記載されるが、開示はいずれか１つの実施形態に制限されず、代わりに、多数の代替、変更、及び等価物を包含することが理解されるべきである。加えて、多数の具体的な詳細が、本願で開示される実施形態の完全な理解を提供するために以下の記載で説明されるが、一部の実施形態は、それら詳細の一部又は全てによらずに保護され得る。更に、明りょうさのために、関連技術において知られている一部の技術的事項は、本開示を不必要に不明瞭にすることを避けるために、詳細には記載されていない。

【0006】

上述されたように、ＵＥは、ＵＥのバッテリを長持ちさせ及び／又はＵＥで実行されるアプリケーションについてレイテンシーを最小限とする特定の機能及び処理に対してほとんど又は全く制御を有さない。例えば、ｅＮｏｄｅＢのような基地局が、ＵＥをサポートするようＲＡＮ機能を制御する。しかし、多様なモバイルインターネットアプリケーションを実行するスマートフォン及び他のモバイル装置の急増により、ＵＥは、電力節約及びレイテンシーの要求を、その選好、制約及び／又は要件をＵＥ支援情報の形でｅＮｏｄｅＢへ送信することが可能である場合に、より有効に達成することができる。

【0007】

図１は、一実施形態に従って、ＵＥ１００がＵＥ支援情報１１２をｅＮｏｄｅＢ１１４へ送信する例を表す。ＵＥ１００は、トランシーバモジュール１１６及びプロセッシングモジュール１１８を含む。プロセッシングモジュール１１８は、ＵＥ支援情報１１２を生成し、且つ、本願で記載されるＵＥの他の機能を実行するよう構成される。トランシーバモジュール１１６は、ＵＥ支援情報１１２をｅＮｏｄｅＢ１１４へ送信し、且つ、本願で記載される他の信号及びメッセージを送信及び受信するよう構成される。ｅＮｏｄｅＢ１１４は、トランシーバモジュール１２０及びプロセッシングモジュール１２２を含む。トランシーバモジュール１２０は、ＵＥ支援情報１１２をＵＥ１００から受信し、且つ、本願で記載される他の信号及びメッセージを送信及び受信するよう構成される。プロセッシングモジュール１２２は、ＵＥ１００から受信されたＵＥ支援情報１１２を処理し、且つ、本願で記載される他の機能を実行するよう構成される。

【0008】

ｅＮｏｄｅＢ１１４は、ＵＥ及びネットワークの性能を高めるよう特定のＲＡＮ機能及びパラメータを導入するために、ＵＥ支援情報１１２を使用することができる。例えば、ＵＥ支援情報１１２は、改善された電力節約をＵＥ１００で達成するために最適な間欠受信（ＤＲＸ）設定を選択することにおいてｅＮｏｄｅＢ１１４にとって有用であってよい。

【0009】

本願で開示される特定の実施形態は、ｅＮｏｄｅＢ１１４が、所望の性能要件を達成するよう及び／又は電力を節約するよう、ＵＥインジケーション（例えば、パケット到着間隔及び／又はトラフィックタイプ特性）に基づきＵＥ１００ごとにＤＲＸパラメータを調整することを可能にするＵＥ支援情報１１２への拡張を提供する。例えば、特定の実施形態に従うＵＥ支援情報１１２は、パケット到着間隔（inter-arrival time）（ＩＡＴ）、移動状態インジケータ（mobility state indicator）（ＭＳＩ）、データ及び／又はトラフィックタイプ特性、時間アライメントタイマ（time alignment timer）（ＴＡＴ）フィードバック値、並びにそれらの組み合わせを含んでよい。それらの種々のタイプのＵＥ支援情報１１２の夫々は、以下で詳細に論じられる。当業者は、本開示から、他の実施形態が、他のＤＲＸパラメータ若しくはパラメータセット、バッテリ制約インジケータ、クオリティ・オブ・エクスペリエンス（quality of experience）（ＱｏＥ）メトリクス、及び／又はアイドルモードに入るリクエストのような追加の又は異なる要素を持ったＵＥ支援情報１１２を使用してよいことを認識するであろう。ＵＥ支援情報の例を議論した後、ＵＥ支援情報を信号により伝える例として、例となるＵＥが与えられる。

【0010】

Ｉ．ＵＥ支援情報の例
Ａ．パケットＩＡＴ
一実施形態において、ＵＥ支援情報１１２は、ＵＥ１００でのＵＬパケットＩＡＴに関連するデータを含む。パケットＩＡＴは、ＵＥ１００でのパケット到着どうし間の時間期間の測定であり、ＵＥ１００で現在実行されているアプリケーションのタイプに対応してよい。ＵＥ１００は、パケットＩＡＴを測定してよいが、ｅＮｏｄｅＢ１１４は、ＵＥ１００でのＵＬパケットのパケットＩＡＴを知らない。ｅＮｏｄｅＢ１１４は、ｅＮｏｄｅＢ１１４でＵＬパケットを処理することによって、ＵＥ１００でのＵＬパケットＩＡＴを推測することが可能である。しかし、ｅＮｏｄｅＢ１１４によるそのような推測は、ｅＮｏｄｅＢ１１４によって見られるパケットのパケットＩＡＴが、ｅＮｏｄｅＢのＵＥスケジューラがセル内の様々なＵＥへ与える許諾に基づき変更され得るので、概して正確でない。よって、特定の実施形態は、パケット到着に関連するデータを含め、ＵＥ支援情報１１２をＵＥ１００からｅＮｏｄｅＢ１１４へ供給する。

【0011】

ＵＥ１００で現在実行されているアプリケーションのタイプを知ることは、ｅＮｏｄｅＢ１１４にとって有用であり得る。例えば、ＵＥ１００が長いパケットＩＡＴを決定する場合は、ｅＮｏｄｅＢ１１４は、電力を節約するよう、ＵＥ１００をアイドルモードに置くか、又はより長いＤＲＸサイクル長を設定してよい。なお、ＵＥ１００が短いパケットＩＡＴを測定する場合は、ｅＮｏｄｅＢ１１４は、より短いＤＲＸサイクル長を設定してよい。

【0012】

以下で論じられる実施形態は、単一ビットのパケットＩＡＴ ＵＥ支援情報を使用すること、複数ビットのパケットＩＡＴ ＵＥ支援情報を使用すること、異なるフォーマットのパケットＩＡＴを選択的に報告すること、及びパケットＩＡＴ情報又は次回パケット到着情報を選択的に報告することを含む。

【0013】

Ａ（１）−単一ビットトラフィックタイプ又はパケットＩＡＴ ＵＥ支援情報
特定の実施形態において、ＵＥ１００は、トラフィックタイプ特性を通信するよう構成されてよい。トラフィックタイプは、パケットＩＡＴ又は他の因子、例えば、アプリケーションがバックグラウンドで実行中若しくはアクティブであるかどうか、又はユーザが装置と相互作用していないためにＵＥのスクリーンセーバがアクティブであるかどうかに関連してよい。よって、パケットＩＡＴは、ＵＬトラフィックがバックグラウンドトラフィック又はアクティブトラフィックであるかどうかを決定するためにＵＥが利用可能な幾つかの方法のうちの１つである。例えば、ＵＥ１００は、内部計算又は処理における使用のためにパケットＩＡＴ測定を実行してよい。測定されたパケットＩＡＴが比較的短い（例えば、１若しくは２秒又はそれ未満）場合は、ＵＥ１００は、ＵＥトラフィックがアクティブトラフィックであると決定してよい。しかし、測定されたパケットＩＡＴが比較的長い（例えば、数秒、数十秒、又は分）場合は、ＵＥ１００は、ＵＥトラフィックがバックグラウンドトラフィックであると決定してよい。加えて、又は他の実施形態において、ＵＥ１００は、ＵＥ１００で実行される如何なるアクティブ又はオープンアプリケーションも存在しないので現在のトラフィックはバックグラウンドトラフィックであると認識してよい。

【0014】

図２Ａは、一実施形態に従って、単一ビット２１０のトラフィックタイプ情報を含むＵＥ支援情報１１２のデータ構造を表す。この例では、ＵＥ１００は、現在のトラフィックがバックグラウンドトラフィックであることを示すようビット２１０を“０”に設定し、ＵＥ１００は、現在のトラフィックがアクティブトラフィックであることを示すようビット２１０を“１”に設定する。

【0015】

Ａ（２）−多ビットトラフィックタイプ又はパケットＩＡＴ ＵＥ支援情報
他の実施形態において、ＵＥ１００は、複数ビットのＵＥ支援情報１１２を用いてｅＮｏｄｅＢ１１４へトラフィックタイプ情報（例えば、パケットＩＡＴ情報又は他の方法により決定される。）を通信するよう構成される。よって、ＵＥ１００は、使用されるビットの数に依存して、異なるレベルの精度をトラフィックタイプに与えてよい。

【0016】

図２Ｂは、一実施形態に従って、２ビット２１２のトラフィックタイプ情報を含むＵＥ支援情報１１２のデータ構造を表す。この例では、ＵＥ１００は、パケットＩＡＴがまばらであり遠く離れているところのバックグラウンドトラフィックによりアプリケーションのタイプを示すようビット２１２を“００”に設定する。よって、アプリケーションは、低いアプリケーション性能要件（例えば、レイテンシー、ジッタ、及び他のパラメータに関する。）を有する。ＵＥ１００は、中位の性能優先トラフィックを必要とする１又はそれ以上のアプリケーションが実行されていることを示すようビット２１２を“０１”に設定する。このようなトラフィックは、例えば、ハイパー・トランスファ・プロトコル（hyper transfer protocol）（ＨＴＴＰ）ウェブ検索又はダウンロードのために、それほど周期的でない。ＵＥ１００は、高い優先度並びに厳しいレイテンシー及び／又は性能要件を伴うアクティブトラフィックによりアプリケーションのタイプを示すようビット２１２を“１０”に設定する。極めてアクティブなトラフィック要件を伴うアプリケーションの例には、ボイス・オーバ・インターネット・プロトコル（ＶｏＩＰ）又はオンラインのゲームアプリケーションがある。ＵＥ１００は、トラフィックが期待されないことを示すようビット２１２を“１１”に設定する。これは、ＵＥ１００からｅＮｏｄｅＢ１１４への無線リソース制御（radio resource control）（ＲＲＣ）解放インジケータとして解釈されてよい。

【0017】

他の実施形態において、ＵＥ支援情報１１２は、トラフィックタイプ情報又はパケットＩＡＴ情報の精度を高めるよう３又はそれ以上のビットを使用してよい。例えば、複数のビットが、実際のパケットＩＡＴ時間（例えば、１０秒）を通信するために使用されてよい。

【0018】

Ａ（３）−異なるパケットＩＡＴフォーマットの選択的報告
特定の実施形態において、ＵＥ１００は、異なるフォーマット又は統計的表示を用いてパケットＩＡＴ情報を選択的に通信するよう構成されてよい。その選択は、例えば、トラフィックの現在のタイプに基づいてよい。パケットＩＡＴは、パケットごとに異なってよい。パケットごとに異なるパケットＩＡＴを送信するよりむしろ、幾つかの実施形態は、特定の期間にわたる又は指定されるイベントについてのパケットＩＡＴの統計的表示を用いて１よりも多いパケットを表してよい。例えば、パケットＩＡＴは、最小ＩＡＴ及び最大ＩＡＴとして表されてよい。他の例として、パケットＩＡＴは、平均ＩＡＴ及び最大ＩＡＴとして表されてよい（例えば、最小ＩＡＴがゼロであり得るとの理解の下。）。

【0019】

特定のアプリケーションについて、トラフィックはバースト的及び／又は不定期である。例えば、複数又はバーストのパケットが、数秒ごとかそこらで送信されてよい。バーストパケットトラフィックについての平均ＩＡＴは、如何にしてパケットが到着するかを示さないので、十分な情報を提供しない。パケットのバーストの存続期間についてのパケットＩＡＴは“ショートＩＡＴ”とここでは呼ばれ、２つの連続するバーストの間の存続期間についてのパケットＩＡＴは“ロングＩＡＴ”とここでは呼ばれる。ショートＩＡＴは極めて小さく、例えば、１又は数ミリ秒の大きさであってよい。ロングＩＡＴは極めて大きく、例えば、１秒又はそれ以上の大きさであってよい。一実施形態において、ＵＥ１００は、バースト的トラフィックを正確に表すようショートＩＡＴ及びロングＩＡＴの両方を報告する。ＵＥ１００は、ショートＩＡＴ及び／又はロングＩＡＴの平均値を報告してよい。

【0020】

図３Ａは、一実施形態に従って、タイプ識別子（ＩＤ）３１０及び１又はそれ以上のＩＡＴ値３１２を含むＵＥ支援情報１１２のデータ構造を表す。ＵＥ１００は、１又はそれ以上のＩＡＴ値３１２をｅＮｏｄｅＢ１１４へ送信するのに使用されるフォーマット及びトラフィックのタイプを認識する。ｅＮｏｄｅＢ１１４が１又はそれ以上のＩＡＴ値３１２を正確に解釈するために、タイプＩＤ３１０はフォーマットを特定する。図３Ｂは、一実施形態に従って、異なるトラフィックタイプについて、図３Ａに示されたタイプＩＤ３１０の記述例３１４を表す。図３Ｂに示されるように、タイプＩＤ３１０は２ビットを含む。なお、他の実施形態は、単一ビット又は２よりも多いビットを使用してよい。この例では、ＵＥ１００は、報告されるＩＡＴ値３１２が平均のショートＩＡＴ及びロングＩＡＴを含むことを示すよう、トラフィックがバースト的及び／又は不定期である場合に、タイプＩＤ３１０を“００”に設定する。規則的な（例えば、バースト的でない）トラフィックに関し、ＵＥ１００は、タイプＩＤ３１０を、報告されるＩＡＴ値３１２が最小及び最大のＩＡＴを含むことを示すよう“０１”に、報告されるＩＡＴ値３１２が平均及び最大のＩＡＴを含むことを示すよう“１０”に、且つ、報告されるＩＡＴ値３１２が他の所定の（例えば、ＵＥ１００及びｅＮｏｄｅＢ１１４の両方に知られる）フォーマット（所定の期間にわたる又は所定のイベントについてのＩＡＴの他の統計的表示を含んでよい。）を含むことを示すよう“１１”に設定する。

【0021】

Ａ（４）−ＩＡＴ又は次回パケット到着情報の選択的報告
特定の実施形態において、ＵＥ１００は、パケットＩＡＴ値（例えば、平均ＩＡＴ又は最大ＩＡＴ）よりもむしろ、選択的に、次回パケット到着情報を報告してよい。次回パケット到着情報は、ＵＥ１００による予測であってよく、あるいは、アプリケーションからアプリケーションプログラミングインターフェース（ＡＰＩ）を介して装置／媒体アクセス制御（ＭＡＣ）層へ渡される情報に基づいてよい。幾つかの場合に、直ぐ次のパケット到着間隔に関する情報は、平均又は最大ＩＡＴよりも有益であり得る。

【0022】

上述されたように、パケットＩＡＴは、２つの連続して到着するパケット又はバースト若しくはパケットの間の間隔の指標である。パケットＩＡＴは、例えば、接続モードの現在のＤＲＸコンフィグレーションが適切であるか、又はそれが調整されるべきであるかどうかを決定するのに有用である。次回パケット到着時間は、他方で、現在のアップリンク伝送と次の到着パケットとの間の間隔に対応する。次回パケット到着時間は、例えば、パケットが近い将来において期待されない場合にＵＥ１００がアイドルモードに置かれるべきであるかどうか、又はパケットが直ぐに期待される場合にＵＥ１００が接続モードに保たれるべきであるかどうかを決定するのに有用である。

【0023】

図４は、一実施形態に従って、パケットＩＡＴ又は次回パケット到着情報を選択的に報告するフローチャートである。この例において、ＵＥ１００は、そのＵＬ伝送バッファにおいて更なるパケットが存在するかどうかをクエリする（４００）。ＵＥ伝送バッファにおいて更なるパケットが存在しない場合は、ＵＥ１００は、次回パケット到着時間を送信し（４１０）、それにより、ｅＮｏｄｅＢ１１４は、ＵＥ１００がアイドルモードに置かれるべきか又は接続モードに保たれるべきかどうかを決定することができる。しかし、ＵＬ伝送バッファにおいて依然としてパケットが存在する場合は、ＵＥ１００は、パケットＩＡＴ情報を（例えば、上述されたように）送信し（４１２）、それにより、ｅＮｏｄｅＢ１１４は、ＲＡＮ機能性最適化、例えば、接続モードのＤＲＸコンフィグレーションが適切であるかどうか、又はＤＲＸコンフィグレーションが調整されるべきであるかどうかを決定すること、を実行することができる。

【0024】

幾つかのＵＥは、パケットＩＡＴを決定するための及び／又は次回パケット到着時間を予測するための機能を有さないことがある。よって、特定の実施形態において、ＵＥ１００は、パケットＩＡＴを決定し且つ次回パケット到着時間を予測する自身の機能をｅＮｏｄｅＢ１１４に示すよう構成される（例えば、ｅＮｏｄｅＢ１１４との接続を確立する場合）。この機能情報は、例えば、フィーチャグループインジケータ（feature group indicator）（ＦＧＩ）ビットを用いて、通信されてよい。例えば、ビット番号３８のような現在未定義のＦＧＩビット（ビット番号３７乃至６４）のうちの１つが使用され得る。

【0025】

図５Ａは、一実施形態に従って、到着時間値５１２がパケットＩＡＴ又は次回パケット到着時間値に対応するかどうかを示すトグルビット５１０を含むＵＥ支援情報１１２のデータ構造を表す。図５ＡにおけるＵＥ支援情報１１２は、例えば、ＭＡＣプロトコルデータユニット（ＰＤＵ）に付加され得るＭＡＣ制御要素（ＣＥ）を介して通信されてよい。一実施形態において、アップリンク共有チャネル（ＵＬ−ＳＣＨ）のための論理制御識別（ＬＣＩＤ）値（例えば、０１０１１〜１１０００）の１つが、ＭＡＣ ＣＥのために使用される。この例では、５ビットが到着時間値５１２を表すために使用され、残りのビットは、図示されるように、将来の使用のために留保されてよい。他の実施形態では、５よりも少ないビット又は５よりも多いビットが、到着時間値５１２を表すために使用されてよい。

【0026】

後述されるように、他のタイプのメッセージ（例えば、ＲＲＣメッセージ）がまた、到着時間値及び他のタイプのＵＥ支援情報を通信するために使用されてよい。例えば、ＵＥに特有のＩＡＴ又は次回パケット到着情報は、アップリンク専用制御チャネル（ＵＬ−ＤＣＣＨ）メッセージの情報要素（ＩＥ）の１つにおいて情報を含めることによって、ｅＮｏｄｅＢ１１４へ送信されてよい。一実施形態において、“ＵＥ−ＩＡＴ−ＮｅｘｔＰａｃｋｅｔＡｒｒｉｖａｌ”と呼ばれるＩＥは、ＩＡＴ又は次回パケット到着情報を含み、ｅＮｏｄｅＢ１１４によって要求される情報を転送するためにＵＥ１００によって使用されるＵＥＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅメッセージに含まれてよい。ＵＥ−ＩＡＴ−ＮｅｘｔＰａｃｋｅｔＡｒｒｉｖａｌメッセージの構造の例が以下で示され、ショート（Ｓｈｏｒｔ）ＩＡＴ、ロング（Ｌｏｎｇ）ＩＡＴ、及び規則的な（Ｒｅｇｕｌａｒ）ＩＡＴを含む：

【0027】

【数1】

【0028】

図５Ｂは、特定の実施形態に従って、図５Ａに示されたトグルビット５１０及び到着時間値５１２の記述例５１４を表す。この例において、ＵＥ１００は、トグルビット５１０を、到着時間値５１２がパケットＩＡＴ情報を含むことを示すよう“０”に、且つ、到着時間値５１２が次回パケット到着時間情報を含むことを示すよう“１”に設定する。図５Ｂに示されるように、到着時間値５１２のビットは、一実施形態では絶対時間値を表し、他の実施形態では指標値を表す。絶対時間値は、例えば、１ミリ秒、１０ミリ秒、１００ミリ秒、１秒、１０秒、又はその他時間値を示してよい。代替的に、指標値は、時間値の範囲に対応してよい。５ビットによれば、例えば、とり得る指標は、“０００００”から“１１１１１”の範囲に及ぶ。指標は、実際のＩＡＴ値又は値範囲にマッピングされてよい。例えば、“０００００”の指標は、１ミリ秒から１００ミリ秒の範囲にマッピングされてよく、“００００１”の指標は、１０１ミリ秒から２００ミリ秒の範囲にマッピングされてよい、等。

【0029】

Ｂ．移動状態インジケータ（ＭＳＩ）
一実施形態において、ＵＥ支援情報１１２は、ＵＥ１００のＭＳＩを含む。ＵＥ１００がセル間を移動している場合に、第１のｅＮｏｄｅＢから第２のｅＮｏｄｅＢへのハンドオーバに必要とされるオーバヘッド又はリソースは、ＵＥ１００がアイドルモードにある場合に比べて、ＵＥ１００がアクティブモードにある場合に、より大きい。ＵＥ１００がアクティブモードにある場合に、第１のｅＮｏｄｅＢは、ハンドオーバに必要な情報を第２のｅＮｏｄｅＢへ送る。しかし、ＵＥ１００がアイドルモードにある場合に、ハンドオーバに必要な情報は第１のｅＮｏｄｅＢにない。むしろ、アイドルモードにおける情報は、エボルブド・パケット・コア（evolved packet core）の移動管理エンティティ（mobility management entity）（ＭＳＥ）にある。よって、例えば、ＭＳＩをＵＥ１００からｅＮｏｄｅＢ１１４へ送ることは、ｅＮｏｄｅＢ１１４がＲＲＣ接続を解放し、ＵＥ１００を、それが高速で移動している場合に、ＲＲＣアイドル状態に移すことを可能にすることによって、シグナリングオーバヘッド及びシステムリソースを低減する。

【0030】

図６は、一実施形態に従って、ＭＳＩビット６１０を含むＵＥ支援情報１１２のデータ構造を表す。この例において、ＵＥ１００は、ＭＳＩビット６１０を、ＵＥ１００の移動度が低いか又はないことを示すよう“０”に設定し、ＵＥ１００は、ＭＳＩビット６１０を、ＵＥ１００の移動度が高いことを示すよう“１”に設定する。当業者は、本開示から、追加ビットが精度を上げるために使用されてよいと認識するであろう（例えば、高位の移動状態、中位の移動状態、通常の移動状態、及び低位又は無の移動状態を示すため）。

【0031】

一実施形態において、ＭＳＩビット６１０は、オープンモバイルアライアンス・デバイスマネージメント（open mobile alliance device management）（ＯＭＡ−ＤＭ）又はオペレータによりシグナリングを介して予め設定される（例えば、固定位置又はマシンタイプコミュニケーション（machine type communication）（ＭＴＣ）専用装置のため）。他の実施形態において、ＭＳＩビット６１０は、全地球航法衛星システム（global navigation satellite system）（ＧＮＳＳ）又は他のナビゲーションシステムからのシグナリングに基づき更新される。他の実施形態において、ＭＳＩビット６１０は、所定の時間期間の間に実行されるセル再設定又はハンドオーバの回数及びＭＳＥにより更新される。例えば、ＲＲＣアイドル状態において、追跡は、選択された期間内にセル再選択の数を数えることに基づき行われてよい。一方、ＲＲＣ接続状態において、追跡は、選択された期間内にハンドオーバの数を数えることに基づき行われてよい。当業者は、１又は複数の解決法がＵＥ１００の移動状態を識別するために使用され得ることを理解するであろう。インジケータ（例えば、図６におけるＭＳＩビット）へのＵＥ１００において利用可能な移動状態情報のマッピング、及びＵＥ支援情報１１２の部分としてＭＳＩビット６１０をｅＮｏｄｅＢ１１４へ運ぶことは、ｅＮｏｄｅＢ１１４がより速く且つより正確なＵＥ設定決定を行うのを助け、ひいては、ＵＥ１００がバッテリ寿命を節約するのを助ける。

【0032】

Ｃ．データ及び／又はトラフィックタイプ特性
一実施形態において、ＵＥ支援情報１１２は、データタイプ特性及び／又はトラフィックタイプ特性を含む。トラフィックタイプの例は、図２Ａ及び図２Ｂに関して上述されたバックグラウンド又はアクティブトラフィックである。他の例として、ＵＥ支援情報１１２は、トラフィックがモバイル発信（ＭＯ）タイプのトラフィック又はモバイル着信（ＭＴ）タイプのトラフィックであるかどうかのインジケーションを含んでよい。ＭＯ及びＭＴタイプトラフィックは、トラフィックがＵＬ専用、ＤＬ専用、又はＵＬ及びＤＬの両タイプのトラフィックであると期待されるかどうかを指す。図７は、一実施形態に従って、トラフィックタイプビット７１０を含むＵＥ支援情報１１２のデータ構造を表す。この例において、ＵＥ１００は、トラフィックタイプビット７１０を、トラフィックがＵＥトリガデータ（例えば、テキスト及び／又は写真をアップロードするソーシャルネットワーキングアプリケーション）であることを示すよう“０”に設定し、ＵＥ１００は、トラフィックタイプビット７１０を、トラフィックがＤＬトリガデータ（例えば、ウェブページをダウンロードするウェブブラウザアプリケーション）であることを示すよう“１”に設定する。ｅＮｏｄｅＢ１１４は、示されるトラフィックタイプの期待される周期性に基づきそのＵＬ割り当て及び／又はＤＲＸサイクルを調整するためにトラフィックタイプ情報を使用してよい。

【0033】

一実施形態において、データ及び／又はトラフィックタイプは、電力選好インジケーションの形をとってよい。例えば、ＵＥ１００は、アクティブトラフィックを処理する場合に通常の電力設定の選好を、そして、バックグラウンドトラフィックを処理する場合に低減された又は低い電力設定の選好を送ってよい。図８は、一実施形態に従って、電力選好ビット８１０を含むＵＥ支援情報１１２のデータ構造を表す。この例において、ＵＥ１００は、電力選好ビット８１０を、通常の電力設定（例えば、アクティブモードにある。）の選好を示すよう“０”に設定し、ＵＥ１００は、電力選好ビット８１０を、低電力設定（例えば、バックグラウンドモードにある。）の選好を示すよう“１”に設定する。電力選好ビット８１０に基づき、ｅＮｏｄｅＢ１１４は、ＵＥのＤＲＸコンフィグレーション設定及び他のパラメータを選択的に調整することができる。電力選好ビット８１０が低電力設定（例えば、最適化された電力節約）のために設定される場合に、例えば、ｅＮｏｄｅＢ１１４は、長いＤＲＸサイクル又はＲＲＣ接続解放を選択してよい。

【0034】

Ｄ．時間アライメントタイマ（ＴＡＴ）フィードバック
一実施形態において、ＵＥ支援情報１１２は、ＴＡＴについて特定の又は所望の値を示すＴＡＴフィードバックを含む。ＬＴＥシステムにおいて、ｅＮｏｄｅＢ１１４は、夫々のＵＥについてＴＡＴを設定する。ＵＥは、自身らのＴＡＴタイマを用いて、ＵＬ時間アライメントを維持する。ＴＡＴが特定のＵＥについて満了する場合に、ｅＮｏｄｅＢ１１４は、そのＵＥについてＵＬ制御チャネルを解放し、ＵＥは、ＵＬ時間アライメントプロシージャを実行するまでＵＬ伝送を提供することができない。

【0035】

特定の実施形態において、ＵＥ１００は、そのＵＬ制御チャネルを解放するようｅＮｏｄｅＢ１１４に示すためにＴＡＴタイマを用いてフィードバックを提供するよう構成される。１つのそのような実施形態において、ＵＥ１００は、ＴＡＴ値が最小値に設定されることを要求することによって、又は他の特定の値を要求することによって、フィードバックを提供する（例えば、ＵＥ１００は、より長い時間接続されたままであるが、ＵＬリソースを浪費したくない場合）。加えて、又は他の実施形態において、ＵＥ１００は、より長い時間、例えば、より長いＤＲＸスリープ期間の間、タイマが満了することを防ぐよう、ＴＡＴ値が非常に高い値に設定されることを要求してよい。高いＴＡＴ値は、例えば、ＵＥ１００の移動度が低いか又はない場合に（例えば、スマートメータ又はセンサのような装置のような特定のＭＴＣ装置に関する。）、有用であり得る。

【0036】

ＩＩ．ＵＥ支援情報のシグナリングの例
ＵＥ支援情報をＵＥ１００からｅＮｏｄｅＢ１１４へ送るための下記の実施形態は、一例として与えられている。当業者は、本開示から、多数の異なるタイプのメッセージ、フォーマット、又はプロトコルが使用されてよいと認識するであろう。

【0037】

図９は、特定の例となる実施形態に従って、ＵＥ支援情報に基づきＤＲＸセットを割り当てるためのＵＥ１００とｅＮｏｄｅＢ１１４との間のやり取りを表す。後述されるように、図９に示されるやり取りは、ｅＮｏｄｅＢ１１４が、利用可能なＤＲＸセットのリストを、ＭＡＣ−ＭａｉｎＣｏｎｆｉｇ情報要素（ＩＥ）９１０を用いてＵＥ１００へ送信すること、ＵＥ１００がＵＥ支援情報をＵＥ−ＡｓｓｉｓｔａｎｃｅＩｎｆｏＩＥ９１２においてｅＮｏｄｅＢ１１４へ送信すること、及びｅＮｏｄｅＢ１１４が、割り当てられたＤＲＸセット（又はインデックス）をｄｒｘＳｅｔ−ＣｏｎｆｉｇＩＥ９１４においてＵＥ１００へ送信することを含む。

【0038】

ｅＮｏｄｅＢ１１４は、ＭＡＣ−ＭａｉｎＣｏｎｆｉｇＩＥ９１０を変更するようＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄＩＥを用いて、接続確立又は再確立時に、ＤＲＸセットのリストをＵＥ１００へ送信する。ｅＮｏｄｅＢ１１４は、例えば、リストが変わる場合は、いつでもＤＲＸセットのリストを送信してよい。一実施形態において、ＭＡＣ−ＭａｉｎＣｏｎｆｉｇＩＥ９１０は、ｅＮｏｄｅＢ１１４で利用可能なＮ個のＤＲＸセットをリストアップする。マルチＤＲＸスイッチングをサポートするよう、複数組のＤＲＸセット（＜＝Ｎ）が使用されてよい。ＤＲＸセットのうちの１又はそれ以上は、例えば、最小のエンドツーエンド遅延のために、性能最適化されてよい。他のＤＲＸセットは、例えば、電力節約のために最適化されてよい。他のタイプのＤＲＸセットは、性能と電力節約との間のバランスを提供してよい。

【0039】

ＭＡＣ−ＭａｉｎＣｏｎｆｉｇＩＥ９１０は、ｅＮｏｄｅＢ１１４で利用可能な特定のＤＲＸセットを識別する“ｄｒｘ−ｉｎｄｅｘ”を含んでよい。ｄｒｘ−ｉｎｄｅｘは、ｅＮｏｄｅＢ１１４が、その特定のＤＲＸセットに関連したＤＲＸパラメータの全てよりむしろｄｒｘ−ｉｎｄｅｘ（Ｎの値に依存して数ビットであってよい。）を送信することができるので、マルチＤＲＸ実施形態のためのシグナリングオーバヘッドを低減するのに役立つ。しかし、特定の実施形態において、ｅＮｏｄｅＢ１１４は、最初に、ｅＮｏｄｅＢ１１４で利用可能な全てのＤＲＸセットのリストをＵＥ１００へ送信する。ＭＡＣ−ＭａｉｎＣｏｎｆｉｇＩＥ９１０は、ＤＲＸセットのリストを得た後の最初の時間に使用されるＤＲＸセット番号をＵＥ１００に示す“ａｓｓｉｇｎｅｄ−ＤｒｘＳｅｔＩｎｄｅｘ”パラメータを更に含んでよい。

【0040】

再び図９を参照すると、ＵＥ−ＡｓｓｉｓｔａｎｃｅＩｎｆｏＩＥ９１２は、例えば、好ましいＤＲＸセット若しくは好ましいＤＲＸインデックス、期待されるデータ、電力若しくは性能の選好、ＭＳＩ、又は他のタイプのＵＥ支援情報（例えば、上述されたバックグラウンド／アクティブトラフィック、他のトラフィック特性、ＴＡＴタイマフィードバック、ＩＡＴ、及び／又は次回パケット到着時間）を含んでよい。一実施形態において、ＵＥ１００からｅＮｏｄｅＢ１１４へ送信されるＵＥ−ＡｓｓｉｓｔａｎｃｅＩｎｆｏＩＥ９１２は、ＵＬ−ＤＣＣＨにおいて含まれる。ＵＥ−ＡｓｓｉｓｔａｎｃｅＩｎｆｏＩＥ９１２を含むＵＬ−ＤＣＣＨメッセージの構造の例は、次のように与えられる：

【0041】

【数2】

【0042】

他の実施形態において、ＵＥ−ＡｓｓｉｓｔａｎｃｅＩｎｆｏＩＥ９１２は、上記のＵＬ−ＤＣＣＨメッセージの構造の例において示される“ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ”、“ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣｏｍｐｌｅｔｅ”、“ｒｒｃＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅ”、及び／又は“ｕｅＩｎｆｏｒｍａｔｉｏｎＲｅｓｐｏｎｓｅ”のような、ＵＬ−ＤＣＣＨメッセージによって搬送され得る既存のＩＥの重要でない拡張子のうちの１つとして定義される。そのようなメッセージは、概して、何らかのｅＮｏｄｅＢにより開始されたＲＲＣメッセージに応答して送信される。よって、ＵＥは、そのようなメッセージの１つがトリガされるのを待っているので、厳密に必要とされるときに、ＵＥ支援情報を送信することができないことがある。図９に示されるように、ＵＥ−ＡｓｓｉｓｔａｎｃｅＩｎｆｏＩＥ９１２の特定の実施形態は、ＵＥによってトリガされるＵＥ支援情報伝送を送信するための新たなＵＬ ＲＲＣＵＥＡｓｓｉｓｔａｎｃｅＭｅｓｓａｇｅを含む。そのような実施形態では、ＵＥは、いつでもＵＥへＵＥ支援情報を送信することができる。

【0043】

例えば、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅメッセージは、データが近い将来に到来すると期待されることを示す“ｄａｔａ−Ｅｘｐｅｃｔｅｄ”フィールド、電力節約選好又は性能選好に関して実行中のアプリケーションの特性を示す“ｐｏｗｅｒ−Ｏｒ−Ｐｅｒｆｏｍａｎｃｅ−ｐｒｅｆｅｒｒｅｄ”フィールド、移動度を（例えば、単位時間ごとのハンドオーバ又はセル再選択の関数に関して）示す“ｍｏｂｉｌｉｔｙ−Ｓｔａｔｅ−Ｉｎｄｉｃａｔｉｏｎ”フィールド、ＵＥ１００によって自身の性能を最適化するために要求されるＤＲＸ設定の特定のセットを示す“ｐｒｅｆｅｒｒｅｄ−ＤｒｘＳｅｔ”フィールド、ＵＥ１００が将来設定したいと望むＤＲＸセットに対応するインデックス値を含む“ｐｒｅｆｅｒｒｅｄ−Ｄｒｘｓｅｔ−ｉｎｄｅｘ”フィールド、それらの組み合わせ、及び／又は本願で開示されるＵＥ支援情報を送信するための他のフィールドを含んでよい。

【0044】

一例として、“ｐｏｗｅｒＰｒｅｆｅｒｅｎｃｅ−Ｉｎｄｉｃａｔｉｏｎ”と呼ばれるＵＥ支援パラメータは、ＵＥ１００が（上記の）電力選好インジケーションに対応するかどうかを示すために使用されてよく、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、ＵＥの電力節約選好に関連した情報を提供するために使用される“ｐｏｗｅｒＰｒｅｆＩｎｄｉｃａｔｉｏｎＣｏｎｆｉｇ”ＩＥを含んでよい。ｐｏｗｅｒＰｒｅｆＩｎｄｉｃａｔｉｏｎＣｏｎｆｉｇＩＥは、ＵＥ１００が、電力節約のために主として最適化されるコンフィグレーションを選ぶことを示すよう“ｌｏｗｐｏｗｅｒｃｏｎｓｕｍｐｔｉｏｎ”に設定され得る“ＰｏｗｅｒＰｒｅｆＩｎｄｉｃａｔｉｏｎ”フィールドを含む。さもなければ、ＵＥ１００は、ＰｏｗｅｒＰｒｅｆＩｎｄｉｃａｔｉｏｎフィールドを“ｎｏｒｍａｌ”状態に設定する。

【0045】

一実施形態において、電力選好インジケーションを提供することができるＵＥは、電力選好インジケーションを提供するよう構成されるとき及び電力選好の変更時を含む幾つかの異なる状況において、自身の電力選好を送信するプロシージャを開始してよい。プロシージャを開始すると、ＵＥ１００は、電力選好インジケーションを提供するよう構成されてから電力選好インジケーションを送信したかどうかを決定する。送信していない場合は、ＵＥ１００は、ＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎメッセージの送信を開始する。ＵＥ１００が既に電力選好インジケーションを送信していた場合は、ＵＥ１００は、自身の現在の電力選好情報が、ＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎメッセージの最後の送信において示されたものと異なるかどうかを決定する。現在の電力選好が異なり、且つ、電力選好インジケーションタイマが満了している場合は、ＵＥ１００は、現在の情報を含むＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎメッセージの送信を開始する。また、ＵＥ１００が、ハンドオーバの直前に、更新された電力選好インジケーションをソースセルへ送信していた場合は、ハンドオーバが完了された後、ＵＥ１００は、現在の情報を含むＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎメッセージの送信を開始する。

【0046】

ＰｏｗｅｒＰｒｅｆＩｎｄｉｃａｔｉｏｎフィールドを含むＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎメッセージの構造の例は、次のように与えられる：

【0047】

【数3】

【0048】

ＵＥ−ＡｓｓｉｓｔａｎｃｅＩｎｆｏＩＥ９１２に応答して、ｅＮｏｄｅＢ１１４は、１又はそれ以上のアクションを起こしてよく、あるいは、如何なるアクションも起こさないと決定してよい。例えば、ｅＮｏｄｅＢ１１４は、ＵＥ１００を解放すること（例えば、ＵＥ１００をアイドルモードに入らせること）によって応答してよい。図９に示されるように、ｅＮｏｄｅＢ１１４はまた、ＤＲＸ設定を変更するリクエストとともにｄｒｘＳｅｔ−ＣｏｎｆｉｇＩＥ９１４をＵＥ１００へ送信することによって、ＵＥ−ＡｓｓｉｓｔａｎｃｅＩｎｆｏＩＥ９１２に応答してよい。ｄｒｘＳｅｔ−ＣｏｎｆｉｇＩＥ９１４は、新たに割り当てられたＤＲＸセット又はＤＲＸセットインデックスを含んでよい。一実施形態において、ｄｒｘＳｅｔ−ＣｏｎｆｉｇＩＥ９１４は、ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄＩＥの拡張である。ＭＡＣメインコンフィグレーション情報は、ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄを用いてｅＮｏｄｅＢ１１４からＵＥ１００へ送信される。ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄＩＥは、無線ベアラ（ＲＢ）をセットアップ、変更、及び解放するために、ＭＡＣメインコンフィグレーションを変更するために、半永続スケジューリング（semi-persistent scheduling）（ＳＰＳ）コンフィグレーションを変更するために、且つ、専用の物理コンフィグレーションを変更するために、使用される。特定の実施形態において、ＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄＩＥは、ＤＲＸコンフィグレーションを変更するためにも使用され得る“ｄｒｘＳｅｔ−Ｃｏｎｆｉｇ”ＩＥと本願で呼ばれる新しい要素を含むよう変更される。

【0049】

図１０は、一実施形態に従って、ＤＲＸセットを選択又は変更する方法１０００のフローチャートである。方法１０００は、ＵＥ１００においてｒａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄメッセージを受信すること１０１０を含む。最初に、ＵＥ１００は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがｆｕｌｌＣｏｎｆｉｇＩＥを含むかどうかをクエリする（１０１２）。それがｆｕｌｌＣｏｎｆｉｇＩＥを含まない場合は、ＵＥ１００は、ＭＡＣ−ＭａｉｎＣｏｎｆｉｇＩＥからのＤＲＸセット更新を実行する。ＤＲＸＳｅｔ（ｅＮｏｄｅＢ１１４で利用可能なＤＲＸセットのリストである。）における夫々のｄｒｘｓｅｔ−ｉｎｄｅｘについて、ＵＥ１００は、ＤＲＸセットを生成し（１０１４）、それを対応するｄｒｘｓｅｔ−ｉｎｄｅｘと関連付ける。ＤＲＸセットが、受信されたｄｒｘ−ｉｎｄｅｘに対応付けて既に設定されている場合は、ＵＥ１００は、現在のｒａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄ ＤＲＸＳｅｔ ＩＥに基づきＤＲＸセットを変更する（１０１６）。次いで、ＵＥ１００は、ａｓｓｉｇｎｅｄ−ＤｒｘＳｅｔＩｎｄｅｘ値に基づき現在のＤＲＸセットを設定する（１０１８）。

【0050】

ＵＥ１００は、ｄｒｘＳｅｔ−ＣｏｎｆｉｇＩＥがｒａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄメッセージにおいて存在するかどうかをクエリする（１０２０）。ｆｕｌｌＣｏｎｆｉｇＩＥがＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージにおいて存在する場合に、ｒａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄメッセージは、通常はｄｒｘＳｅｔ−ＣｏｎｆｉｇＩＥを含まない。しかし、ｄｒｘＳｅｔ−ＣｏｎｆｉｇＩＥが存在する場合は、ＵＥ１００は、ｄｒｘｓｅｔ−ｉｄｅｘがメッセージにおいて存在するかどうかをクエリする（１０２２）。ｄｒｘｓｅｔ−ｉｎｄｅｘが存在する場合は、ＵＥ１００は、ｄｒｘＳｅｔ−ＣｏｎｆｉｇＩＥにおいて含まれる現在のｄｒｘｓｅｔ−ｉｎｄｅｘを読み出し、対応するＤＲＸセットを、更なる変化まで、使用すべき現在のＤＲＸ設定として設定する（１０２４）。しかし、ｄｒｘｓｅｔ−ｉｎｄｅｘが存在しない場合は、ＵＥ１００は、Ｃｕｒｒｅｎｔ−ｄｒｘＳｅｔを得て、対応するＤＲＸセットを、更なる変化まで、使用すべきＤＲＸ設定として設定する（１０２６）。

【0051】

ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージがｆｕｌｌＣｏｎｆｉｇＩＥを含まない場合は、ＵＥ１００は、ＭＡＣ−ＭａｉｎＣｏｎｆｉｇＩＥからのＤＲＸセット更新を実行しない。むしろ、新しいｒａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄメッセージを受信した後、ＵＥ１００は、ｄｒｘｓｅｔ−ｉｎｄｅｘがそのメッセージにおいて存在するかどうかをクエリする（１０２２）。ｄｒｘｓｅｔ−ｉｎｄｅｘが存在する場合は、ｄｒｘＳｅｔ−ＣｏｎｆｉｇＩＥにおいて含まれる現在のｄｒｘｓｅｔ−ｉｎｄｅｘを読み出し、対応するＤＲＸセットを、更なる変化まで、使用すべき現在のＤＲＸ設定として設定する（１０２４）。しかし、ｄｒｘｓｅｔ−ｉｎｄｅｘが存在しない場合は、ＵＥ１００は、Ｃｕｒｒｅｎｔ−ｄｒｘＳｅｔを得て、対応するＤＲＸセットを、更なる変化まで、使用すべきＤＲＸ設定として設定する（１０２６）。

【0052】

ＩＩＩ．モバイル装置の例
図１１は、本願で開示される実施形態の１又はそれ以上により使用され得るモバイル装置の実例を与える。モバイル装置は、例えば、ＵＥ、移動局（mobile station）（ＭＳ）、移動無線装置、移動通信装置、タブレット、ハンドセット、又は他のタイプの移動無線装置であってよい。モバイル装置は、ｅＮｏｄｅＢ、ベースバンドユニット（base band unit）（ＢＢＵ）、遠隔無線ヘッド（remote radio head）（ＲＲＨ）、遠隔無線設備（remote radio equipment）（ＲＲＥ）、中継局（relay station）（ＲＳ）、無線設備（radio equipment）（ＲＥ）、又は他のタイプの無線ワイドエリアネットワーク（wireless wide area network）（ＷＷＡＮ）アクセスポイントのような基地局と通信するよう構成される１又はそれ以上のアンテナを含むことができる。モバイル装置は、３ＧＰＰ ＬＴＥ、ＷｉＭＡＸ、高速パケットアクセス（High Speed Packet Access）（ＨＳＰＡ）、ブルートゥース、及びＷｉＦｉを含む少なくとも１つの無線通信標準規格を用いて通信するよう構成され得る。モバイル装置は、夫々の無線通信標準規格のための別個のアンテナ又は複数の無線通信標準規格のための共有アンテナを用いて通信することができる。モバイル装置は、無線ローカルエリアネットワーク（wireless local area network）（ＷＬＡＮ）、無線パーソナルエリアネットワーク（wireless personal area network）（ＷＰＡＮ）、及び／又はＷＷＡＮにおいて通信することができる。

【0053】

図１１は、モバイル装置からの音声入力及び出力のために使用され得るマイクロホン及び１以上のスピーカの実例を更に与える。ディスプレイスクリーンは、液晶ディスプレイ（liquid crystal display）（ＬＣＤ）スクリーン、又は有機発光ダイオード（organic light emitting diode）（ＯＬＥＤ）ディスプレイのような他のタイプのディスプレイスクリーンであってよい。ディスプレイスクリーンは、タッチスクリーンとして構成され得る。タッチスクリーンは、容量性、抵抗性、又は他のタイプのタッチスクリーン技術を使用してよい。アプリケーションプロセッサ及びグラフィクスプロセッサは、プロセッシング及びディスプレイ機能を提供するよう内部メモリへ結合され得る。不揮発性メモリポートはまた、データ入出力選択肢をユーザに与えるために使用され得る。不揮発性メモリポートはまた、モバイル装置のメモリ機能を拡張するために使用されてよい。キーボードは、更なるユーザ入力を提供するようモバイル装置と一体化されるか又はモバイル装置へ無線により接続されてよい。仮想キーボードがまた、タッチスクリーンを用いて提供されてよい。

【0054】

様々な技術、又はその特定の態様若しくは部分は、フロッピー（登録商標）ディスケット、ＣＤ−ＲＯＭ、ハードドライブ、非一時的コンピュータ可読記憶媒体、又はその他機械可読記憶媒体において収容されるプログラムコード（すなわち、命令）の形をとってよく、プログラムコードが機械（例えば、コンピュータ）にロードされて該機械によって実行される場合に、機械は、様々な技術を実施する装置になる。プログラム可能なコンピュータでのプログラムコード実行の場合に、コンピュータ装置は、プロセッサと、プロセッサによって読出可能な記憶媒体（揮発性及び不揮発性メモリ並びに／又は記憶素子を含む。）と、少なくとも１つの入力装置と、少なくとも１つの出力装置とを含んでよい。揮発性及び不揮発性メモリ並びに／又は記憶素子は、ＲＡＭ、ＥＰＲＯＭ、フラッシュドライブ、光学ドライブ、磁気ハードドライブ、又は電気データを記憶するための他の媒体であってよい。基地局及び移動局は、トランシーバモジュール、カウンタモジュール、プロセッシングモジュール、及び／又はクロックモジュール若しくはタイマモジュールを更に含んでよい。本願で記載される様々な技術を実施又は利用し得る１又はそれ以上のプログラムは、アプリケーションプログラミングインターフェース（ＡＰＩ）、再利用可能な制御、及び同様のものを使用してよい。そのようなプログラムは、コンピュータシステムと通信するために高度な手続き型又はオブジェクト指向のプログラミング言語において実施されてよい。なお、プログラムは、必要に応じて、アセンブリ又は機械言語において実施されてよい。いずれの場合にも、言語は、コンパイル又は解釈された言語であり、ハードウェア実装と組み合わされてよい。

【0055】

本明細書で記載される機能ユニットの多くは、１又はそれ以上のモジュールとして実施されてよいことが理解されるべきである。なお、モジュールは、とりわけそれらの実施独立性を強調するために使用される語である。例えば、モジュールは、カスタムＶＬＳＩ回路若しくはゲートアレイ、ロジックチップのような市販の半導体、トランジスタ、又は他のディスクリート部品を有するハードウェア回路として実施されてよい。モジュールはまた、フィールドプログラマブルゲートアレイ、プログラマブルアレイロジック、プログラマブルロジックデバイス又は同様のもののようなプログラム可能なハードウェア装置において実施されてよい。

【0056】

モジュールはまた、様々なタイプのプロセッサによる実行のために、ソフトウェアにおいて実施されてよい。実行可能コードの識別されるモジュールは、例えば、オブジェクト、プロシージャ、又は関数として編成され得るコンピュータ命令の１以上の物理的又は論理的ブロックを有してよい。それでもなお、識別されるモジュールの実行ファイルは、物理的にまとめて位置付けられる必要はなく、異なった場所に記憶された別個の命令を有してよく、それらの命令は、論理的にまとめられる場合に、モジュールを有し、そのモジュールのための定められた目的を達成する。

【0057】

実際に、実行可能コードのモジュールは、単一の命令、又は多数の命令であってよく、複数の異なるコードセグメントにわたって、異なるプログラムの間で、そして複数のメモリ装置にわたって分配されてよい。同様に、オペレーショナルデータは、識別され、本願ではモジュール内で表されてよく、如何なる適切な形態においても具現され、如何なる適切なタイプのデータ構造内でも編成されてよい。オペレーショナルデータは、単一のデータセットとして集められてよく、あるいは、異なる記憶装置にわたること含め、異なる場所にわたって分配されてよく、少なくとも部分的に、単に、システム又はネットワークにおける電子信号として、存在してよい。モジュールは、受動的又は能動的であってよく、所望の機能を実行するよう動作するエージェントを含む。

【0058】

本明細書の全体を通して“例”との言及は、その例に関連して記載される特定の特徴、構造、又は特性が本発明の少なくとも一実施形態に含まれることを意味する。よって、本明細書の全体を通して様々な箇所における“例において”との表現の出現は、必ずしも全てが同じ実施形態に言及しているわけではない。

【0059】

本願で使用されるように、複数の項目、構造部品、成分要素、及び／又は材料は、便宜上、共通の羅列において提示されることがある。しかし、そのような羅列は、あたかも挙げられているものの夫々が別個の且つ一意のものとして個々に識別されるかのように解釈されるべきである。よって、そのような個々の列挙は、反対に指し示すことなしに共通のグループにおけるそれらの提示にのみ基づき同じ羅列内の何らかの他の列挙の事実上の等価物として解釈されるべきである。加えて、本発明の様々な実施形態及び例は、それらの様々な構成要素の代替とともに本願で参照されてよい。そのような実施形態、例、及び代替は、互いの事実上の等価物として解釈されるべきでなく、本発明の別個の自立した表現として解釈されるべきであることが理解される。

【0060】

上記は、明りょうさのために幾らか詳細に記載されてきたが、特定の変更及び改良がその原理から逸脱することなしになされてよいことは明らかである。本願で記載される処理及び装置の両方を実施する多くの代替方法が存在することが留意されるべきである。然るに、本実施形態は、限定ではなく実例として解釈されるべきであり、本発明は、本願で与えられている詳細に制限されず、添付の特許請求の範囲の適用範囲及び均等の範囲内で変更されてよい。

【0061】

当業者には当然に、多くの変更は、本発明の基礎をなし原理から逸脱することなしに、上記の実施形態の詳細に対してなされてよい。従って、本発明の適用範囲は、特許請求の範囲によってのみ決定されるべきである。

【図1】

【図2A】

【図2B】

【図3A】

【図3B】

【図4】

【図5A】

【図5B】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】