特開 2024-1272 ＵＥ支援情報を送信することに関するユーザ装置

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

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024001272

(43)【公開日】2024-01-09

(54)【発明の名称】ＵＥ支援情報を送信することに関するユーザ装置

(51)【国際特許分類】

   H04W 72/044 20230101AFI20231226BHJP

   H04W 72/1268 20230101ALI20231226BHJP

   H04W 52/28 20090101ALI20231226BHJP

   H04W 52/02 20090101ALI20231226BHJP

【ＦＩ】

H04W72/044

H04W72/1268

H04W52/28

H04W52/02 110

【審査請求】有

【請求項の数】14

【出願形態】ＯＬ

(21)【出願番号】P 2023184577

(22)【出願日】2023-10-27

(62)【分割の表示】P 2021537152の分割

【原出願日】2019-09-25

(31)【優先権主張番号】19151275.5

(32)【優先日】2019-01-10

(33)【優先権主張国・地域又は機関】EP

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．３ＧＰＰ

(71)【出願人】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】110002952

【氏名又は名称】弁理士法人鷲田国際特許事務所

(72)【発明者】

【氏名】リ ホンチャオ

(72)【発明者】

【氏名】鈴木 秀俊

(72)【発明者】

【氏名】リ イーフイ

(72)【発明者】

【氏名】クゥァン クゥァン

(72)【発明者】

【氏名】バムリ アンキット

(57)【要約】      （修正有）

【解決手段】基地局に送信される支援情報を決定する処理回路を有するユーザ装置（ＵＥ）は、動作中にサービング基地局に送信する支援情報を決定する処理回路と、動作中に決定した支援情報を含む支援レポートをＵＥのサービング基地局に送信する送信機と、を有し、前記支援情報は、情報ビットを前記サービング基地局に送信するために使用するトランスポートブロックのトランスポートブロックサイズを含む。
【効果】ＵＥ支援情報をＵＥからそれのサービング基地局に送信するための改善された手順を提供することを容易にする。
【選択図】図７

【特許請求の範囲】

【請求項1】

ユーザ装置（ＵＥ）であって、
動作中に前記ＵＥのサービング基地局に送信される支援情報を決定する処理回路と、
動作中に前記決定した支援情報を含む支援レポートを前記ＵＥのサービング基地局に送信する送信機と、
を有し、
前記支援情報は、情報ビットを前記サービング基地局に送信するため前記ＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズを含む、
ユーザ装置。

【請求項2】

動作中にアップリンク送信を実行するため前記ＵＥによって使用可能な無線リソース割当てを前記サービング基地局から受信する受信機を更に有する、
請求項１に記載のユーザ装置。

【請求項3】

前記支援情報は、
・前記情報ビットの数、
・前記情報ビットを前記サービング基地局に送信するため前記ＵＥによって使用される最
小電力を示す電力レベル、
・間欠受信（ＤＲＸ）機構を動作させるため前記ＵＥによって使用される１つ以上のＤＲ
Ｘ設定パラメータ、
の支援情報タイプの１つ以上を含む、
請求項１に記載のユーザ装置。

【請求項4】

前記情報ビットの数は、
・前記ＵＥによって前記サービング基地局に送信されるアップリンクトラフィックの典型的なパケットサイズＵ、
・前記アップリンクトラフィックの典型的な到着時間Ｔ、
・前記アップリンクトラフィックに対して充足されるべき遅延要求Ｌ、
の少なくとも１つなどの１つ以上のトラフィック特性に基づいて前記ＵＥによって決定される、
請求項１に記載のユーザ装置。

【請求項5】

前記情報ビットの数Ｉは、
Ｉ＝Ｕ＊ｃｅｉｌｉｎｇ（Ｌ／Ｔ）
の式に基づいて決定される、
請求項３に記載のユーザ装置。

【請求項6】

前記処理回路は、動作中に、
・情報ビットの数Ｉ、
・符号化レートＣ、
・変調次数Ｍ、
の少なくとも１つに基づいてトランスポートブロックのトランスポートブロックサイズを決定し、
前記トランスポートブロックサイズ（ＴＢＳ）は、
ＴＢＳ＝Ｉ＊Ｃ／Ｍ
の式に基づいて決定され、
前記処理回路は、動作中に前のアップリンク無線リソース割当てにおいて、又はリファレンス変調符号化方式（ＭＣＳ）レベルにおいて前記サービング基地局によって前記ＵＥに割り当てられるＭＣＳレベルから前記符号化レートと前記変調次数とを決定する、
請求項１に記載のユーザ装置。

【請求項7】

前記処理回路は、動作中に、
・情報ビットの数Ｉ、
・前記ＵＥから前記サービング基地局に前記情報ビットを送信するため必要とされる周波数帯域幅ＢＷ、
・前記ＵＥと前記サービング基地局との間のパスのパスロス測定値ＰＬ、
の１つ以上に基づいて前記電力レベルを決定し、
前記電力レベルＰは、
Ｐ＝１０＊ｌｇ（ＢＷ）＋ＰＯ＋ａｌｐｈａ＊ＰＬ
の式に基づいて決定され、ＰＯ及びａｌｐｈａは、ＲＲＣメッセージにおいて上位レイヤによって設定される、
請求項３に記載のユーザ装置。

【請求項8】

前記処理回路は、動作中にトラフィックのタイプ毎及び／又は論理チャネルグループ毎に前記支援情報を決定する、
請求項１に記載のユーザ装置。

【請求項9】

前記支援情報は、各支援情報タイプについて個別の値を含み、
前記個別の値は、異なる個別の値と前記支援情報タイプとの間の関連付けに基づいて、前記処理回路によって決定され、
前記支援情報は、前記支援情報タイプの２つ以上の組み合わせに対して１つの結合値を含み、
前記結合値は、支援情報タイプの異なる組み合わせと異なる結合値との間の関連付けに基づいて、前記処理回路によって決定され、
前記関連付けは、前記サービング基地局から受信するＲＲＣメッセージに基づいて前記ＵＥによって設定される、
請求項１に記載のユーザ装置。

【請求項10】

ユーザ装置（ＵＥ）によって実行される、
前記ＵＥのサービング基地局に送信される支援情報を決定するステップと、
前記決定された支援情報を含む支援レポートを前記ＵＥの前記サービング基地局に送信するステップと、
を有し、
前記支援情報は、前記ＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズを含む、
方法。

【請求項11】

基地局であって、
動作中に前記基地局によってサービス提供されるユーザ装置（ＵＥ）から、支援情報を含む支援レポートを受信し、前記受信した支援情報に基づいて、アップリンク送信を実行するため前記ＵＥに割り当てられる無線リソースを決定する処理回路と、
動作中に前記決定された無線リソースを示す無線リソース割当てを前記ＵＥに送信する送信機と、
を有し、
前記支援情報は、情報ビットを前記基地局に送信するため前記ＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズを含む、
基地局。

【請求項12】

基地局によって実行される、
前記基地局によってサービス提供されるユーザ装置（ＵＥ）から、支援情報を含む支援レポートを受信するステップと、
前記受信した支援情報に基づいて、アップリンク送信を実行するため前記ＵＥに割り当てられる無線リソースを決定するステップと、
前記決定された無線リソースを示す無線リソース割当てを前記ＵＥに送信するステップと、
を有し、
前記支援情報は、情報ビットを前記基地局に送信するため前記ＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズを含む、
方法。

【請求項13】

ユーザ装置（ＵＥ）の処理を制御する集積回路であって、前記処理は、
前記ＵＥのサービング基地局に送信される支援情報を決定する処理と、
前記決定された支援情報を含む支援レポートを前記ＵＥの前記サービング基地局に送信する処理と、
を有し、
前記支援情報は、情報ビットを前記サービング基地局に送信するため前記ＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズを含む、
集積回路。

【請求項14】

基地局の処理を制御する集積回路であって、前記処理は、
前記基地局によってサービス提供されるユーザ装置（ＵＥ）から、支援情報を含む支援レポートを受信する処理と、
前記受信した支援情報に基づいて、アップリンク送信を実行するため前記ＵＥに割り当てられる無線リソースを決定する処理と、
前記決定された無線リソースを示す無線リソース割当てを前記ＵＥに送信する処理と、
を有し、
前記支援情報は、情報ビットを前記基地局に送信するため前記ＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズを含む、
集積回路。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、３ＧＰＰ通信システムなどの通信システムにおける方法、装置及び物に関する。

【背景技術】

【0002】

現在、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）は、第５世代（５Ｇ）とも呼ばれる次世代セルラ技術のための技術仕様書において作業している。

【0003】

１つの課題は、少なくともｅｎｈａｎｃｅｄ ｍｏｂｉｌｅ ｂｒｏａｄｂａｎｄ（ｅＭＢＢ）、ｕｌｔｒａ－ｒｅｌｉａｂｌｅ ｌｏｗ－ｌａｔｅｎｃｙ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＵＲＬＬＣ）、ｍａｓｓｉｖｅ ｍａｃｈｉｎｅ ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ（ｍＭＴＣ）を含む、全ての利用シナリオ、要件及び配備シナリオ（例えば、参照によってここに援用されるＴＲ ３８．９１３ ｖｅｒｓｉｏｎ １５．０．０のｓｅｃｔｉｏｎ ６などを参照されたい）に対処する単一の技術的枠組みを提供することである。例えば、ｅＭＢＢ配備シナリオは、屋内ホットスポット、密集した都市、農村、都市の大規模及び高速を含んでもよく、ＵＲＬＬＣ配備シナリオは、産業制御システム、移動ヘルスケア（遠隔モニタリング、診断及び治療）、車両のリアルタイム制御、スマートグリッドのための広域モニタリング及び制御システムを含んでもよく、ｍＭＴＣ配備シナリオは、スマートウェアラブル及びセンサネットワークなどの非タイムクリティカルデータ転送による多数のデバイスを有するシナリオを含んでもよい。サービスｅＭＢＢ及びＵＲＬＬＣは、両方とも非常に広い帯域幅を要求するという点で類似しているが、ＵＲＬＬＣサービスは、好ましくは超低遅延を要求しうるという点で異なっている。

【0004】

第２の課題は、前方互換性を実現することである。ロングタームエボリューション（ＬＴＥ，ＬＴＥ－Ａ）セルラシステムに対する後方互換性は必要とされず、これは、全く新しいシステム設計及び／又は新規な特徴の導入を容易にする。

【発明の概要】

【0005】

１つの非限定的で例示的な実施例は、ＵＥ支援情報をＵＥからそれのサービング基地局に送信するための改善された手順を提供することを容易にする。

【0006】

実施例では、ここに開示される技術は、ＵＥのサービング基地局に送信される支援情報を決定する処理回路を有するユーザ装置を特徴とする。ＵＥの送信機は、決定した支援情報を含む支援レポートをＵＥのサービング基地局に送信する。支援情報は、
・ＵＥによってサービング基地局に送信される情報ビットの数、
・情報ビットをサービング基地局に送信するためＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズ、
・情報ビットをサービング基地局に送信するためＵＥによって使用される最小電力を示す電力レベル、
・間欠受信（ＤＲＸ）機構を動作させるためＵＥによって使用される１つ以上のＤＲＸ設定パラメータ、
の支援情報タイプの１つ以上を示す。

【0007】

一般的又は具体的な実施例は、システム、方法、集積回路、コンピュータプログラム、記憶媒体又はそれらの何れかの選択的な組合せとして実現されてもよいことに留意されたい。

【0008】

開示された実施例の追加的な利点及び効果は、明細書及び図面から明らかになるであろう。利点及び／又は効果は、明細書及び図面の各種実施例及び特徴によって個別に取得されてもよく、これらの全てが、そのような利点及び／又は効果のうちの１つ以上を取得するため提供される必要はない。

【図面の簡単な説明】

【0009】

以下において、例示的な実施例が、添付した図面を参照してより詳細に説明される。

【図1】３ＧＰＰ ＮＲシステムのための一例となるアーキテクチャを示す。

【図2】ＬＴＥ ｅＮＢ、ｇＮＢ及びＵＥのための一例となるユーザ及び制御プレーンアーキテクチャを示す。

【図3】アップリンクデータ送信シナリオ及び対応する最適なスケジューリングを示す。

【図4】アップリンクデータ送信シナリオ及び対応する最適なスケジューリングを示す。

【図5】ＵＥ及びｇＮＢの例示的で簡略化された構成を示す。

【図6】第１実施例の一例となる実現形態によるＵＥの構成を示す。

【図7】第１実施例の一例となる実現形態によるＵＥの動作のためのフロー図である。

【図8】第１実施例の一例となる実現形態によるＵＥの動作のためのフロー図である。

【図9】ＤＲＸ機構及びアクティブ時間の処理のための問題のシナリオを示す。

【図10】ＤＲＸ機構及びアクティブ時間の処理のための問題のシナリオを示す。

【図11】第２実施例の一例となる実現形態によるＵＥの構成を示す。

【図12】第２実施例の一例となる実現形態によるＵＥの動作のためのフロー図である。

【図13】第２実施例の一例となる実現形態によるデータのＵＥ送信とのアクティブ時間拡張のインタラクションを示す。

【図14】第２実施例の一例となる実現形態によるＵＥの動作のためのフロー図である。

【図15】第２実施例の他の例となる実現形態によるデータのＵＥ送信とのアクティブ時間延長のインタラクションを示す。

【図16】第２実施例の他の例となる実現形態によるＵＥの動作のためのフロー図である。

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

【0010】

５Ｇ ＮＲシステムアーキテクチャ及びプロトコルスタック
３ＧＰＰは、１００ＧＨｚまでの範囲の周波数において動作する新しい無線アクセス技術（ＮＲ）の開発を含む、単に５Ｇと呼ばれる第５世代セルラ技術のための次のリソースに取り組んでいる。３ＧＰＰは、緊急のマーケットニーズ及び更なる長期の要求の双方を適時的に充足するＮＲシステムの標準化を成功させるのに必要とされる技術コンポーネントを特定及び開発する必要がある。これを実現するため、無線インタフェースと共に無線ネットワークアーキテクチャの進化が、スタディーアイテム“Ｎｅｗ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ”において検討される。結果及び合意は、参照によってその全体がここに援用される、Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＴＲ ３８．８０４ ｖ１４．０．０に集められる。

【0011】

とりわけ、全体的なシステムアーキテクチャは、ＵＥに対するＮＧ無線アクセスユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）及び制御プレーン（ＲＲＣ）プロトコルターミネーションを提供するｇＮＢを含むＮＧ－ＲＡＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ－Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）を想定する。ｇＮＢは、Ｘｎインタフェースによって互いに相互接続される。ｇＮＢはまた、Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ（ＮＧ）インタフェースによって、ＮＧＣ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｒｅ）、より詳細には、ＮＧ－ＣインタフェースによってＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ）（例えば、ＡＭＦを実行する特定のコアエンティティ）と、ＮＧ－ＵインタフェースによってＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ）（例えば、ＵＰＦを実行する特定のコアエンティティ）に接続される。ＮＧ－ＲＡＮアーキテクチャは、図１に示される（例えば、参照によってここに援用される３ＧＰＰ ＴＳ ３８．３００ ｖ１５．２．０，ｓｅｃｔｉｏｎ ４を参照されたい）。

【0012】

様々な異なる展開シナリオがサポート可能である（例えば、参照によってここに援用される３ＧＰＰ ＴＲ ３８．８０１ ｖ１４．０．０を参照されたい）。例えば、非集中配備シナリオ（例えば、ＴＲ ３８．８０１のｓｅｃｔｉｏｎ ５．２を参照されたく、集中配備はｓｅｃｔｉｏｎ ５．４に示される）がそこに提示され、そこでは、５Ｇ ＮＲをサポートする基地局が配備可能である。図２は、例示的な非集中配備シナリオ（例えば、ＴＲ ３８．８０１の図５．２．－１を参照されたい）を示し、一方で、ＬＴＥ ｅＮＢとｇＮＢとの双方に接続されるユーザ装置（ＵＥ）と共に、ＬＴＥ ｅＮＢをさらに示す。ＮＲ ５Ｇのための新しいｅＮＢは、例示的にｇＮＢと呼ばれうる。ｅＬＴＥ ｅＮＢは、ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）及びＮＧＣ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｃｏｒｅ）との接続性をサポートするｅＮＢの進化型である。

【0013】

ＮＲのためのユーザプレーンプロトコルスタック（例えば、参照によってここに援用される３ＧＰＰ ＴＳ ３８．３００ ｖ１５．２．０のｓｅｃｔｉｏｎ ４．４．１を参照されたい）は、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ、ＴＳ ３８．３００のｓｅｃｔｉｏｎ ６．４を参照されたい）、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ、ＴＳ ３８．３００のｓｅｃｔｉｏｎ ６．３を参照されたい）及びＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ、ＴＳ ３８．３００のｓｅｃｔｉｏｎ ６．２を参照されたい）サブレイヤを含み、これらは、ネットワークサイド上のｇＮＢにおいて終端される。さらに、新しいアクセス層（ＡＳ）サブレイヤ（ＳＤＡＰ、Ｓｅｒｖｉｃｅ Ｄａｔａ Ａｄａｐｔａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）が、ＰＤＣＰの上位に導入される（例えば、参照によってここに援用される３ＧＰＰ ＴＳ ３８．３００ ｖｅｒｓｉｏｎ １５．２．０のｓｕｂ－ｃｌａｕｓｅ ６．５を参照されたい）。制御プレーンプロトコルスタックはまた、ＮＲについて定義される（例えば、ＴＳ ３８．３００のｓｅｃｔｉｏｎ ４．４．２を参照されたい）。レイヤ２機能の概略は、ＴＳ ３８．３００のｓｕｂ－ｃｌａｕｓｅ ６に与えられる。ＰＤＣＰ、ＲＬＣ及びＭＡＣサブレイヤの機能は、ＴＳ ３８．３００のｓｅｃｔｉｏｎ ６．４、６．３及び６．２にそれぞれリストされている。ＲＲＣレイヤの機能は、ＴＳ ３８．３００のｓｕｂ－ｃｌａｕｓｅ ７にリストされている。ＴＳ ３８．３００の上記のセクションは、参照によりここに援用される。

【0014】

例えば、媒体アクセス制御レイヤは、異なるニューメロロジーの処理を含む、論理チャネル多重化、スケジューリング及びスケジューリング関連機能を扱う。

【0015】

物理レイヤについて、ＭＡＣレイヤは、トランスポートチャネルの形式でサービスを使用する。トランスポートチャネルは、無線インタフェースを介してどのように、また、どのような特性で情報が送信されるかによって定義することができる。Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ（ＲＡＣＨ）はまた、トランスポートブロックを搬送しないが、ＭＡＣによって処理されるトランスポートチャネルとして定義される。ＭＡＣレイヤによってサポートされる手順の１つは、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｒｏｃｅｄｕｒｅである。

【0016】

物理レイヤ（ＰＨＹ）は、例えば、符号化、ＰＨＹ ＨＡＲＱ処理、変調、マルチアンテナ処理及び適切な物理的時間－周波数リソースへの信号のマッピングを担当する。それはまた、トランスポートチャネルの物理チャネルへのマッピングを処理する。物理レイヤは、トランスポートチャネルの形式でＭＡＣレイヤにサービスを提供する。物理チャネルは、特定のトランスポートチャネルの送信に使用される時間－周波数リソースのセットに対応し、各トランスポートチャネルは対応する物理チャネルにマッピングされる。１つの物理チャネルは、ランダムアクセスに使用されるＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）である。

【0017】

ＮＲのためのユースケース／展開シナリオは、ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ（ｅＭＢＢ）、ｕｌｔｒａ－ｒｅｌｉａｂｌｅ ｌｏｗ－ｌａｔｅｎｃｙ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＵＲＬＬＣ）、ｍａｓｓｉｖｅ ｍａｃｈｉｎｅ ｔｙｐｅ ｃｏｍｍｕｎｉｃａｔｉｏｎ（ｍＭＴＣ）を含むことができ、これらは、データレート、レイテンシ及びカバレッジに関して様々な要件を有する。例えば、ｅＭＢＢは、ＩＭＴ－Ａｄｖａｎｃｅｄによって提供されるものの３倍のオーダで、ピークデータレート（ダウンリンクでは２０Ｇｂｐｓ、アップリンクでは１０Ｇｂｐｓ）及びユーザ体感データレートをサポートすることが期待される。他方、ＵＲＬＬＣのケースでは、超低遅延（ユーザプレーンレイテンシについてＵＬ及びＤＬのそれぞれに対して、０．５ｍｓ）と高信頼性（１ｍｓ以内に１～１０^－５）とのよりタイトな要件が課される。最後に、ｍＭＴＣは、好ましくは、高接続密度（都市環境では、１，０００，０００デバイス／ｋｍ^２）、過酷な環境での大きなカバレッジ及び低コストデバイスのための極めて長寿命（１５年）のバッテリを必要としうる。

【0018】

従って、１つのユースケースに適したＯＦＤＭニューメロロジー（例えば、サブキャリア間隔、ＯＦＤＭシンボル持続時間、サイクリックプリフィックス（ＣＰ）持続時間、スケジューリング間隔毎のシンボル数）は、別のユースケースに対して良好には動作しないかもしれない。例えば、低遅延サービスは、好ましくは、ｍＭＴＣサービスよりも短いシンボル持続時間（及びより大きなサブキャリア間隔）及び／又はスケジューリング間隔毎のより少ないシンボル（別名、ＴＴＩ）を必要としうる。さらに、大きなチャネル遅延スプレッドを有する配備シナリオは、好ましくは、短い遅延スプレッドを有するシナリオよりも長いＣＰ持続時間を必要としうる。同様のＣＰオーバヘッドを維持するため、サブキャリア間隔はそれに応じて最適化されるべきである。ＮＲは、サブキャリア間隔の複数の値をサポートしてもよい。これに対応して、１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ、・・・のサブキャリア間隔が現在検討されている。シンボル持続時間Ｔ_ｕとサブキャリア間隔Δｆとは、式（Δｆ＝１／Ｔ_ｕ）を介し直接的に関係する。ＬＴＥシステムと同様にして、「リソースエレメント」という用語は、１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対して１つのサブキャリアから構成される最小のリソース単位を示すのに利用できる。

【0019】

新しい無線システム５Ｇ－ＮＲでは、各ニューメロロジーと各キャリアについて、サブキャリアとＯＦＤＭシンボルとのリソースグリッドが、アップリンクとダウンリンクとに対してそれぞれ定義される。リソースグリッドにおける各エレメントは、リソースエレメントと呼ばれ、周波数領域における周波数インデックス及び時間領域におけるシンボル位置に基づいて識別される。（参照によってここに援用される３ＧＰＰ ＴＳ ３８．２１１ ｖ１５．２．０を参照されたい）。

【0020】

ＵＥ支援情報
１つの目的は、より少ないＵＥ電力消費を達成することである。この点に関する１つの選択肢は、ＵＥのスリープ機会を増大させるため、アップリンク送信の期間を最小限に抑えることである。これは、例えば、データ送信のために充足されるべき遅延要求を考慮して、各送信において可能な限り多くのデータ送信を集約することによって行うことができる。ｇＮＢは、それに応じてデータ送信をスケジューリングすべきである。

【0021】

図３及び図４は、２つのアップリンク送信シナリオを示す。図３において、ＵＥが１０ｍｓの例示的な遅延供給によって、５ｍｓ周期で到着するｘビットのパケットを有するトラフィックを有する。この特定のシナリオでは、最も省電力な処理は、ＵＥが残りの時間にスリープすることを可能にするため、２Ｘビットの推定トランスポートブロックサイズ（ＴＢＳ）によって、少なくとも１０ミリ秒毎にＵＥをスケジューリングすることである。

【0022】

図４において、ＵＥは、２５ｍｓの例示的な遅延要求によって１０ｍｓ周期で到着するｘビットのパケットを有するトラフィックを有することが例示的に仮定される。このシナリオでは、図３のシナリオとは別のスケジューリングが最適である。すなわち、ＵＥは、５Ｘビットの推定ＴＢＳで少なくとも２５ｍｓ毎にスケジューリングされる。

【0023】

双方のケースにおいて、継続するスリープ機会は、アップリンクにおけるデータトラフィックに対する遅延要求に依然として従いながら最大化される。

【0024】

例えば、ｇＮＢは、パケット遅延要求及びトラフィックタイプに依存しうる、より良好な電力節約のために利用可能なＵＥ電力も考慮して、適したタイミング及び情報ビット数／ＴＢＳによってＵＥをスケジューリングする必要がある。

【0025】

しかしながら、本発明者らは、（少なくともアップリンクについて）ｇＮＢが最適なスケジューリング戦略を決定するのに充分な情報を有していないことを認識していた。従って、ｇＮＢによってＵＥに提供されるスケジューリングパラメータ及び機会は、最適ではないかもしれない。

【0026】

アップリンクトラフィックについて、ＵＥは、パケットサイズ、到着／配信間隔、遅延などの予想されるＵＬ向けのトラフィック特性をより良く知っている。対応する上位レイヤ（例えば、アプリケーションレイヤ）は、例えば、下位レイヤ（例えば、ＲＲＣ及び／又はＭＡＣ）に（例えば、長期の）トラフィック特性の情報をわたすことができる。

【0027】

この問題に対処するため、ＵＥは、ｇＮＢが、電力節約を最適化するためにＵＥのアップリンクトラフィックをいつ、また、どのようにスケジューリングするかを知ることができることを実現するため、ｇＮＢに支援情報を提供する。

【0028】

この結果、発明者らは、以下の解決策に従ってＵＥ支援情報の送信を実現する可能性を特定した。

【0029】

以下において、ＵＥ、基地局及びこれらの必要性を満たすための手順が、５Ｇ移動通信システムのために想定されるが、ＬＴＥ移動通信システムにおいても利用されてもよい新しい無線アクセス技術について説明される。異なる実現形態及び変形がまた説明される。以下の開示は、上述されるような議論及び発見によって容易にされ、例えば、その少なくとも一部に基づくものであってもよい。

【0030】

一般に、本開示の基礎となる原理を明確かつ理解可能な方法で説明することができるように、ここでは多くの仮定がなされていることに留意されるべきである。しかしながら、これらの仮定は、本開示の範囲を限定すべきではない、例示目的のためにここで行われる単なる例として理解されるべきである。当業者は、以下の開示及び請求項において提供される原理が、ここには明示的に記載されていない様々なシナリオ及び方法に適用されうることを認識するであろう。

【0031】

さらに、以下で使用される手順、エンティティ、レイヤなどの用語のいくつかは、ＬＴＥ／ＬＴＥ－Ａシステム、又は、現在の３ＧＰＰ ５Ｇ標準化で使用される用語に密接に関連しているが、次の３ＧＰＰ ５Ｇ通信システムのための新しい無線アクセス技術の文脈で使用される具体的な用語は、まだ完全には決定されていない。従って、用語は、実施例の機能に影響を及ぼすことなく、将来変更することができる。従って、当業者は、実施例及びそれらの保護範囲が、より新しいか、又は最終的に合意された用語を欠くためにここで例示的に使用される特定の用語に限定されるべきではなく、本開示の機能及び原理の基礎をなす機能及び概念に関してより広く理解されるべきであることを認識する。

【0032】

例えば、移動局、移動ノード、ユーザ端末又はユーザ装置（ＵＥ）は、通信ネットワーク内の物理エンティティ（物理ノード）である。１つのノードは、複数の機能エンティティを有してもよい。機能エンティティは、同一若しくは他のノード又はネットワークの他の機能エンティティに所定の機能セットを実現及び／又は提供するソフトウェア又はハードウェアモジュールを表す。ノードは、ノードが通信可能な通信施設又は媒体にノードをアタッチする１つ以上のインタフェースを有してもよい。同様に、ネットワークエンティティは、他の機能エンティティ又は対応するノードと通信しうる通信施設又は媒体に機能エンティティをアタッチする論理インタフェースを有してもよい。

【0033】

ここで、「基地局」又は「無線基地局」とは、通信ネットワーク内の物理エンティティを表す。移動局と同様に、基地局はいくつかの機能エンティティを有してもよい。機能エンティティは、同一若しくは別のノード又はネットワークの他の機能エンティティに所定の機能セットを実現及び／又は提供するソフトウェア又はハードウェアモジュールを表す。物理エンティティは、スケジューリング及びコンフィギュレーションの１つ以上を含む、通信デバイスに関するいくつかの制御タスクを実行する。基地局機能及び通信デバイス機能はまた、単一のデバイス内に統合されてもよいことに留意されたい。例えば、移動端末は、他の端末のための基地局の機能もまた実現してもよい。ＬＴＥで使用される用語は、ｅＮＢ(又はｅＮｏｄｅＢ）であり、一方、５Ｇ ＮＲのために現在使用されている用語は、ｇＮＢである。

【0034】

図５は、ユーザ装置（通信デバイスとも呼ばれる）及びスケジューリングデバイス（ここでは、例示的に、基地局、例えば、ｅＬＴＥ ｅＮＢ(あるいは、ｎｇ－ｅＮＢと呼ばれる）又は５Ｇ ＮＲ５におけるｇＮＢに配置されると仮定される）の概略的で簡略化された例示的なブロック図を示す。ＵＥ及びｅＮＢ／ｇＮＢは、それぞれ送受信機を使用した（無線）物理チャネルを介して互いに通信している。

【0035】

通信デバイスは、送受信機及び処理回路を含んでもよい。次に、送受信機は、受信機及び送信機を含んでもよい、及び／又は、それらとして機能してもよい。処理回路は、１つ以上のプロセッサ又は何れかのＬＳＩなどの１つ以上のハードウェアであってもよい。送受信機と処理回路との間には、動作時に処理回路が送受信機を制御可能であり、すなわち、受信機及び／又は送信機を制御し、受信／送信データをやりとり可能な入出力ポイント（又はノード）があってもよい。送受信機は、送信機及び受信機として、１つ以上のアンテナ、増幅器、ＲＦ変調器／復調器などを含むＲＦ（無線周波数）フロントを含んでもよい。処理回路は、処理回路によって提供されるユーザデータ及び制御データを送信し、及び／又は処理回路によって更に処理されるユーザデータ及び制御データを受信するように送受信機を制御することなどの制御タスクを実現してもよい。処理回路はまた、決定、判定、計算、測定などの他の処理を実行するためのものであってもよい。送信機は、送信する処理及びそれに関連する他の処理を実行するためのものであってもよい。受信機は、受信する処理及びそれに関連する他の処理、例えば、チャネルの監視などを実行するものであってもよい。

【0036】

（実施例１）
第1の実施例は、図6～８に関して以下で説明される。

【0037】

図６は、本解決策による簡略化された例示的なＵＥ構成を示し、図５に関連して上述された一般的なＵＥ構造に基づいて実現可能である。図示されるＵＥの様々な構造的要素は、例えば、制御及びユーザデータ並びに他の信号をやりとりするため、例えば、対応する入力／出力ノード（図示せず）を用いて互いに相互接続できる。例示のために示されないが、ＵＥは、さらなる構造的要素を含んでもよい。

【0038】

そこから明らかなように、ＵＥは、以下に説明されるように、ＵＥ支援情報を送信するための改良された手順に参加するため、支援情報判定回路と支援レポート送信機とを含んでもよい。

【0039】

本ケースでは、以下の開示から明らかなように、従って、処理回路は、支援情報（例えば、それの異なるタイプ）を決定するステップと、支援情報を導出するため異なる中間パラメータを決定するステップの１つ以上を少なくとも部分的に実行するよう例示的に構成可能である。

【0040】

次に、送信機は、例えば、支援レポート内で支援情報を送信するステップと、アップリンクデータを送信するステップとの１つ以上を少なくとも部分的に実行できるように構成可能である。

【0041】

図７は、改良された支援情報送信手順によるＵＥ動作のためのシーケンス図である。

【0042】

例示的に、ＵＥは、それのサービング基地局（例えば、ｇＮＢ）とデータ、例えば、特定のアプリケーションからのアップリンクデータトラフィックを交換していると仮定される。ＵＥは、アップリンクデータトラフィックを送信するために無線リソースをＵＥに割り当てるための最適なアップリンクスケジューリングをｇＮＢが決定するのを支援するように構成される。

【0043】

このため、ＵＥは、支援情報を決定し、例えば、支援レポートの一部として、当該支援情報をサービング基地局に送信してもよい。

【0044】

最適なアップリンクスケジューリングを決定するためサービング基地局に役立つ様々なタイプの支援情報が存在可能である。すなわち、支援情報は、以下の１つ以上を示すものであってもよい。
・各スケジューリングについて、ＵＥによってサービング基地局に送信される情報ビットの数
・各スケジューリングについて、情報ビットを提供基地局に送信するためＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズ
・情報ビットをサービング基地局に送信するためＵＥによって使用される最小電力を示す電力レベル
・ＤＲＸ機構を動作させるためにＵＥによって使用される１つ以上の間欠受信、ＤＲＸ、設定パラメータ

【0045】

これらの異なるタイプの情報のより詳細な例示的な実現形態が、以下でさらに提示される。

【0046】

一般に、支援情報は、ＵＥによって近い将来に発生すると予想されるアップリンクトラフィックに関するものであり、従って、ｇＮＢによって実行されるアップリンクスケジューリングをこれらの将来のデータトラフィックに適応／最適化するのに適した情報をｇＮＢに提供する。例えば、ｇＮＢに支援情報を提供することは、ｇＮＢがＵＥの省電力化に関してアップリンクスケジューリングを最適化することを容易にしうる。

【0047】

これに対応して、ＵＥは、アップリンク割当てメッセージ（例えば、ＤＣＩ）をｇＮＢから受信して、データの対応するアップリンク送信を実行する。

【0048】

しかしながら、上記の支援情報の主な用途は、ｇＮＢにおけるアップリンクスケジューリングを支援することであるが、ｇＮＢによる支援情報の利用は、これに限定されない。支援情報は、更に、又は、代わりに、ダウンリンクスケジューリング、ロードバランシング、ハンドオーバ判定などの別の用途に使用することもできる。

【0049】

上述したように、支援情報としてｇＮＢ側に送信することができるいくつかの異なるタイプの情報がある。以下において、アップリンクスケジューリングを決定するためｇＮＢによって使用される際にそこから導出可能な利点を含めて、各タイプが説明される。

【0050】

支援情報は、ＵＥによってｇＮＢに送信される情報ビットの数を示してもよい（すなわち、ＵＥの各スケジューリングについて示唆される）。より詳細には、ＵＥは、例えば、上位レイヤで利用可能なトラフィック特性から、アップリンクにおける将来のデータトラフィックを予測することを試みてもよい。１つの例示的な解決策では、情報ビットの数は、アップリンクトラフィックの典型的なパケットサイズ、アップリンクトラフィックの典型的な到着時間、及び／又はアップリンクトラフィックのために充足されるべき遅延要求からＵＥによって決定することができる。

【0051】

より詳細には、典型的なパケットサイズは、例えば、アプリケーションレイヤによって生成される、又は上位レイヤによって分割／連結される、１つ以上のトラフィック／サービスによって起動される特定のレイヤからのパケットのサイズであると決定されうる。

【0052】

１つの例示的な解決策では、情報ビットの数は、以下の式に基づいて決定することができる。
Ｉ＝Ｕ＊ｃｅｉｌｉｎｇ（Ｌ／Ｔ）
ここで、Ｉは情報ビットの数であり、Ｌは充足されるべき遅延要求であり、Ｔはアップリンクトラフィックの典型的な到着時間であり、“ｃｅｉｌｉｎｇ（）”はシーリング関数である。

【0053】

アップリンクにおいて送信される情報ビットの数に関する当該情報は、適切なトランスポートブロックサイズ（ＴＢＳ）を決定するためｇＮＢによって利用可能である（例えば、３ＧＰＰ ＴＳ ３８．２１４及び３ＧＰＰ ３６．２１３を参照されたい）。さらに、ｇＮＢは、ＵＥによって使用される適切な帯域幅部分を推定及び決定することができ、この新しい帯域幅部分のために必要とされる帯域幅の切り替え及び設定を実行することができる。これは、送信持続時間を最小化し、最適なアップリンクスケジューリングによって遅延要求を充足させることを可能にし、これはまた、ＵＥによる異なる送信のトラフィックの集約を実現することができる。

【0054】

支援情報は更に、トランスポートブロックサイズを通知することができる。情報ビットの数と同様に、ＵＥは、アップリンクにおける将来のトラフィックを予測しようとし、これに基づいて、これに関して最適に必要とされる予想されるトランスポートブロックサイズを予測してもよい。例えば、トランスポートブロックサイズは、情報ビットの数、符号化率及び変調次数の１つ以上から決定されてもよい。

【0055】

１つの例示的な解決策では、トランスポートブロックサイズは、以下の式に基づいて決定することができる。
ＴＢＳ＝Ｉ＊Ｃ／Ｍ
ここで、ＴＢＳは、決定されるべきトランスポートブロックサイズであり、Ｉは情報ビットの数であり、Ｃは符号化率であり、Ｍは変調次数である。

【0056】

符号化率及び変調次数は、アップリンクデータをｇＮＢに送信するためＵＥによって使用される変調方式から次に決定されてもよい。ＵＥで利用可能でない変調方式に関するケース情報では、ＵＥはまた、例えば、主に支援情報を決定するために使用されるリファレンス変調方式などを使用してもよいし、又は、（例えば、以前のアップリンク無線位置から）アップリンクデータを送信するためＵＥによってこれまで使用された変調方式を使用してもよい。

【0057】

ｇＮＢは、そのような予想されるトランスポートブロックサイズを受信すると、アップリンクスケジューリングのために同じものを直接的に使用することができ、すなわち、提案されたＴＢＳを用いてＵＥをスケジューリングすることができる。さらに、基地局は、情報ビットの数について既に上述したのと同様の方法で、ＵＥによって使用されるべき適切な帯域幅部分を推定及び決定することができる。これに対応して、ｇＮＢはまた、この新しい帯域幅部分のための要求帯域幅部分の切り替え及び設定を実行することができる。これは、ｇＮＢが送信持続時間を最小化し、遅延要求を充足することを可能にする。

【0058】

支援情報は更に、アップリンクでデータを送信するためＵＥによって使用される（最小）電力レベルを通知ことができる。例えば、電力レベルは、情報ビットの数、アップリンクで情報ビットを送信するために必要とされる周波数帯域幅及びＵＥとｇＮＢとの間の通信チャネルのパスロス測定値（例えば、最後のもの）の１つ以上に基づいて決定されてもよい。

【0059】

一例となる解決策では、電力レベルは以下の式に基づいて決定できる。
Ｐ＝１０＊ｌｇ（ＢＷ）＋Ｐ_Ｏ＋ａｌｐｈａ＊ＰＬ
ここで、Ｐは電力レベルであり、ＢＷは周波数帯域幅であり、パラメータＰ_Ｏ及びａｌｐｈａはＲＲＣメッセージにおいて上位レイヤによって設定される。これら２つの電力制御パラメータは、例えば、ＲＲＣによって設定される（例えば、３ＧＰＰ ＴＳ ３８．１２３，ＴＳ ３６．２１３，ＴＳ ３８．３３１及びＴＳ ３６．３３１などを参照されたい）。例えば、Ｐ_Ｏは目標電力であり、ａｌｐｈａは電力補償係数である。そして、周波数帯域幅ＢＷは、推定された情報ビット及びＭＣＳレベルからＵＥによって決定可能である。

【0060】

この電力レベル情報から、ｇＮＢは、例えば、アップリンクにおいて特定の帯域幅部分を割り当てるのに十分な電力がＵＥにあるかを決定することができる。さらに、基地局はまた、異なるトラフィックを集約するための無線リソースをスケジューリングするのに十分な電力がＵＥにあるか推定することができる。これにより、ｇＮＢは、ＵＥの電力消費を減少させるため、スケジューリング機会に対する適切なビット数及び帯域幅を判断することが可能とされうる。

【0061】

支援情報は更に、ＵＥによって使用されるＤＲＸ機構に関連する１つ以上のパラメータを通知してもよい。特に、ＵＥ及びｇＮＢがＵＥのための間欠受信（ＤＲＸ）機構を設定したと例示的に仮定される。５Ｇについての一例となる実現形態では、５Ｇについて現在規定されているようなＤＲＸ機構が利用可能である（例えば、３ＧＰＰ ＴＳ G３８．３３１ ｓｅｃｔｉｏｎ ４．４及び６．３．２とともに、ＴＳ ３８．３２１を参照されたい）。これに対応して、ＤＲＸ機構は、上述した３ＧＰＰ Ｔｅｃｈｎｉｃａｌ Ｓｔａｎｄａｒｄに記載されているもの、例えば、ｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒ，ｄｒｘ－ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒ，ｄｒｘ－ＬｏｎｇＣｙｃｌｅ，ｄｒｘ－ＳｈｏｒｔＣｙｃｌｅなど、いくつかのＤＲＸパラメータに従って動作する。

【0062】

ＵＥは、支援情報内にＤＲＸパラメータの１つ以上のための値の示唆を含んでもよく、示唆されたＤＲＸパラメータ値は、ＤＲＸ機構を動作させるためにＵＥによって現在使用されているそれぞれのＤＲＸパラメータの値とは異なる。ＵＥは、トラフィック到着間隔の推定及び遅延要求に基づいて、好ましいスケジューリング間隔及びアクティブ持続時間を選択してもよいため、ＵＥは、１つ以上のＤＲＸパラメータを変更することを決定してもよい。従って、提案されるＤＲＸサイクルは、ＵＥによって示唆されたスケジューリング間隔と合わされるか、又は近接されることができる。任意選択的に、所望されるアクティブ持続時間は、ＵＥによって示唆されたｄｒｘ－ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒと合わされるか、又は近接させることができる。あるいは、ＵＥは、ｇＮＢによって設定された複数のＤＲＸ設定から１つのＤＲＸ設定インデックスを直接示唆する。

【0063】

ｇＮＢは、そのようなＤＲＸパラメータの示唆を受信すると、例えば、ＵＥのための電力節約の可能性を改善するため、ＤＲＸ機構を適応させるか否か、又はどのように適応させるかを決定することができる。例えば、ｇＮＢは、提案されたＤＲＸ設定によってＵＥをスケジューリングすることができる。任意選択的に、ｇＮＢは、提案されるように、ＵＥによって使用されるＤＲＸ設定のパラメータのいくつかを変更することができる。

【0064】

上記の議論では、ｇＮＢに送信される支援情報を編集するため、異なるタイプの支援情報が議論されてきた。これまで、異なる支援情報のタイプは完全なＵＥ動作を表すと例示的に仮定されてきた。さらに、又は代わりに、異なる支援情報のタイプはまた、例えば、トラフィックのタイプ毎、論理チャネルグループ毎、又は（上位レイヤ）アプリケーション毎など、ＵＥ動作の一部に対して決定できる。例えば、支援情報は、高優先度トラフィック、低遅延トラフィック等のみに制限されてもよい。

【0065】

例えば、支援レポートは、特定タイプのトラフィック又は論理チャネルグループ若しくはアプリケーションに関連付けられた形式にすることができる。支援レポートには、複数のパラメータセットを含めることができ、それぞれのパラメータセットは、特定タイプのトラフィック又は論理チャネルグループ若しくはアプリケーションのインデックスを有し、リンクされている。

【0066】

例えば、ＵＥは、低遅延要求を有するトラフィックのための第1のものと、比較的高い遅延耐性トラフィックのための第２のものなど、２つの異なるトラフィックタイプを有すると例示的に仮定されてもよい。これに対応して、一実現形態では、支援情報の一部又は全ては、２つの利用可能なトラフィックタイプについて別々に生成され、その後、ｇＮＢに一緒に又は別々に送信することができる。より詳細には、情報ビットの数、トランスポートブロックサイズ、電力レベル及びＤＲＸ設定（又はそのパラメータ）は、特定のトラフィックタイプに固有とすることができる。

【0067】

そのような例示的なシナリオでは、支援情報は、例えば、当該支援情報が関連する特定のトラフィックタイプをさらに通知してもよい。これは、ｇＮＢが、このトラフィックタイプに固有の支援情報に基づいて、適したスケジューリングパラメータを決定することによって、ＵＥの電力消費を節約するための最適化されたスケジューリング戦略を決定することができるため、効果的である。

【0068】

同様に、ＵＥは２つの異なる論理チャネルグループに従って送信されるべきデータを有すると例示的に仮定されてもよい。論理チャネルグループは、バッファステータスレポートのコンテクストにおいて典型的及び例示的に使用され（例えば、３ＧＰＰ ＴＳ ３８．３２１ ｖ１５．０．０ ｓｅｃｔｉｏｎ ５．４．５を参照されたい）、ここで、同様のスケジューリング要求を有する論理チャネルは、バッファステータスレポートのために１つの論理チャネルグループに一緒にグループ化することができる。このコンセプトは、これまでに議論された支援情報報告手順を改善するため、すなわち、論理チャネルグループ毎に支援情報を編集することによって、再利用することができる。

【0069】

より詳細には、情報ビットの数、トランスポートブロックサイズ、電力レベル及びＤＲＸ設定は、特定の論理チャネルグループに固有のものとすることができる。

【0070】

そのような例示的なシナリオでは、システム情報は、例えば、支援情報が関連する特定の論理チャネルグループをさらに通知してもよい。これは、ｇＮＢが、この論理チャネルグループに固有の支援情報に基づいて、適したスケジューリングパラメータを決定することによって、ＵＥの電力消費を節約するための最適化されたスケジューリング戦略を決定することができるため、効果的である。

【0071】

上述した解決策では、異なる支援情報タイプは情報のタイプを表す絶対値を直接通知することが例示的に仮定された。例えば、ビット数情報は、例えば、５０００ビットを示し、ビット数を直接示す値を示す。

【0072】

しかしながら、あるいは、他の例示的な解決策は、支援情報パラメータを示すために絶対値ではなく差分値を使用することができる。例えば、絶対値（５０００ビットなど）を示す代わりに、支援情報は、＋１０００ビットなどの差分値を示すことができ、これは、対応する基準値（ここでは、例えば、４０００ビット）と一緒に、支援情報を適切に示す絶対値をもたらす。例えば、ＵＥは、支援情報を決定するとき、最初にその絶対値を決定し、次いで、特定の基準値に基づいて差分値を決定し、当該差分値は、ｇＮＢに送信される支援情報に符号化される。対応する決定は、特定の支援情報タイプパラメータの絶対値を最終的に取得するため、対応する基準値（同じものがＵＥによって使用される）とともに、報告された支援情報の差分値を使用してｇＮＢ側で実行される。

【0073】

差分値を取得するために基準値をどのように規定するかについては、異なる選択肢がある。例えば、基準値は、支援情報の以前の報告又は以前の無線リソース割当て（例えば、ＴＢＳ又は電力レベル）から取得できる。

【0074】

絶対値ではなく差分値の使用は、支援情報タイプ毎により少数の異なる値が必要とされるため、支援情報のビット数を低減することができる。

【0075】

さらに、絶対値及び／又は差分値がまた、値自体としてではなく、値自体に関連するインデックスとして符号化されてもよい。例えば、各支援情報タイプについて、複数の異なるインデックス（例えば、３ビットを使用して、合計で８つ）を有するテーブルが存在可能であり、各インデックスは、支援情報タイプの異なる絶対値又は差分値に関連付けられる。例示の目的でＴＢＳを使用する際、８つの異なるＴＢＳ値が３ビットインデックスで符号化することができる。支援情報の値（例えば、ＴＢＳ値）を直接符号化することと比較して、より多くのビットが必要とされ、これは、支援情報のビット数をさらに低減することができる。

【0076】

上述された解決策では、支援情報は、支援情報タイプ毎に（少なくとも）１つの別の値を提供することによって報告されると仮定された。例えば、支援情報レポートがＴＢＳ、電力レベル及びＤＲＸ設定のための支援情報を含むと仮定すると、支援情報レポートは、ＴＢＳを示す１つの値と、電力レベルを示す１つの値と、少なくとも１つのＤＲＸの示唆された設定パラメータを示す少なくとも１つの値とを含む。一方、さらに、又は代わりに、２つ以上の支援情報タイプの組み合わせを示すために、ジョイントインデックスが利用可能である。

【0077】

以下において、１つのインデックスが２つの異なる支援情報タイプの組み合わせ、特に電力レベルとＴＢＳとの組み合わせを示す、ジョイントインデックスの例示的な実現形態が示される。ＴＢＳはビット数として符号化されず、それのサイズが高、中、低、又は０に分類されるとさらに例示的に仮定される。

【表1】

【0078】

対応して、支援情報レポートは、２３ｄＢの電力レベルと高トランスポートブロックサイズを結合的に示すため、ジョイントインデックス１（例えば、3ビット値として０００）を通知できる。

【0079】

異なるインデックスと異なる支援情報パラメータ（又はパラメータの組み合わせ）との間の上述した関連付けは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージなどのＲＲＣメッセージを利用して、ＵＥとｇＮＢとの間で設定できる。

【0080】

支援情報、それぞれ支援レポートがＵＥによってｇＮＢにどのように送信できるかについて異なる方法がある。１つの例示的な解決策では、支援レポートは、物理レイヤのアップリンク制御情報として送信できる（３ＧＰＰ ＴＳ ３８．２１２又はＴＳ ３８．２１を参照されたい）。

【0081】

さらに、又は代わりに、支援レポートは、Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣプロトコル） Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ（３ＧＰＰ ＴＳ ３８．３２１を参照されたい）として送信可能である。

【0082】

さらに、又は代わりに、支援レポートは、Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌプロトコル（３ＧＰＰ ＴＳ ３８．３３１を参照されたい）のメッセージ（例えば、情報エレメント）として送信可能である。ＲＲＣの新しい情報エレメントがこれに関して利用可能であり、あるいは、“ＵＥＡｓｓｉｓｔａｎｃｅＩｎｆｏｒｍａｔｉｏｎ”ＩＥなどの既存のものが、上述されるように（３ＧＰＰ ＴＳ ３６．３３１ ｖ１５．３．０ ｓｅｃｔｉｏｎ ６．２．２ ｐａｇｅｓ ３７１－３７４を参照されたい）、この新たなＵＥ支援情報を搬送するため拡張可能である。

【0083】

任意選択的な実現形態では、レポートは、示唆されたスケジューリング間隔を表す設定されたＤＲＸ設定の１つに関連付け可能である。レポートがＤＲＸ設定に関連付けされていない場合、レポートは、ＵＥのバッファが特定の値より大きくなると、そこに報告される少なくとも対応する支援情報（例えば、情報ビットサイズ又はＴＢＳ）によってＵＥをスケジューリングするようｇＮＢによって解釈できる。

【0084】

上記の例示的な解決策では、支援情報はアップリンクスケジューリングを支援するため送信されると仮定した。しかしながら、上述した解決策及び実現形態は、単にアップリンク支援情報を提供することに限定されない。さらに、又は代わりに、ＵＥは、ダウンリンクスケジューリングを支援するため、ｇＮＢに支援情報を提供することができる。アップリンクについて上述した各種解決策、変形例及び実現形態は、ダウンリンク支援のために等しく利用可能であり、従って、上記説明の繰り返しは回避される。例えば、異なる支援情報タイプは、サービング基地局からＵＥに送信される情報ビットの数、情報ビットをＵＥに送信するためサービング基地局によって使用されるトランスポートブロックのトランスポートブロックサイズ及び／又はＤＲＸ機構を動作させるためにＵＥによって使用される１つ以上のＤＲＸ設定パラメータなど、ダウンリンクスケジューリングにおいてｇＮＢを支援するのに役立ちうる。この情報の一部又は全ては、どの程度のデータがダウンロードされるかを知っている上位レイヤ、例えば、アプリケーションレイヤから取得できる。

【0085】

ダウンリンク支援情報は、アップリンク支援情報と一緒に又は別に、ｇＮＢに送信することができる。

【0086】

上述した例示的な解決策では、対応する支援情報レポートでｇＮＢに送信することができる異なる支援情報タイプが説明された。１つの例示的な実現形態では、ＵＥは自ら、どの情報がｇＮＢに送信されるべきか、例えば、どのタイプの支援情報がＵＥのためのアップリンクスケジューリングを最適化する際にｇＮＢを支援するためｇＮＢに送信する価値があるかを決定することができる。一方、ｇＮＢに報告される支援情報タイプの選択は、例えば、ＲＲＣメッセージを用いて、ｇＮＢによって事前に設定されてもよい。

【0087】

以下の実施例は、ＵＥが２つの異なる論理チャネルグループＬＣＧ＃１及びＬＣＧ＃２に対して情報ビットを送信すると想定される実際のシナリオを用いて説明する。特に、ＵＥは１０ｍｓの周期を有するＤＲＸ設定（例えば、１０ｍｓの周期のＤＲＸ設定が適しているように、パケット配信遅延は１０ｍｓである）に関連するＬＣＧ＃１に対して５０００ビットのＴＢＳを推定すると例示的に仮定される。一方、ＵＥは、２０ｍｓの周期を有するＤＲＸ設定に関連するＬＣＧ＃２のための１００００ビットのＴＢＳを推定する。

【0088】

以前（例えば、最近）のアップリンクグラントで使用された変調符号化方式に基づいて（あるいは、異なる設定されたリファレンスＭＣＳ値において）、ＵＥはその後に必要とされる周波数帯域幅（例えば、ＰＲＢ（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）の数）を推定し、必要とされる電力レベル（例えば、ＬＣＧ＃１について、１０ｄＢｍと、ＬＣＧ＃２について、１３ｄＢｍ）をさらに推定する。そして、ＵＥは、電力レベル及びＴＢＳに関する支援情報を対応する支援情報レポートに編集し、これをｇＮＢに送信する。ｇＮＢに対するＴＢＳ及び電力レベル情報（例えば、帯域幅部分情報を直接提供するのでなく）を利用することによって、ｇＮＢには、良好なトラフィック適応化による双方のＬＣＧに対して最も電力効率的なアップリンクスケジューリング戦略を決定するため、より正確な情報が提供されてもよい。

【0089】

そして、ｇＮＢは、当該レポートに基づくとともに、それの無線セルに在圏する他のＵＥを考慮して、レポートが受信されたＵＥをスケジューリングするのに使用される適切なアップリンク帯域幅部分及びスケジューリングスロットを決定してもよい。受信したＵＥ支援情報レポートは複数のＬＣＧに関するものであるため、ｇＮＢはまた、可能である場合、異なるＬＣＧにわたってトラフィックアグリゲーションを検討することを試みてもよい。全てを考慮して、ｇＮＢは、アップリンクスケジューリングを実行し、例えば、適したアップリンク帯域幅部分を割り当ててもよく、ここで、ＵＥは、１０ｍｓ毎にスケジューリングされ、残りの９ｍｓではスリープに維持される。スロット＃２ｎ＊１０（２０，４０，６０，８０，．．．）では、より大きな帯域幅部分が利用され、ＵＥに利用可能な１４．７ｄＢｍ（１０ｄＢｍ＋１３ｄＢｍ）の電力が同時に双方のトラフィックに対して十分であるため、１５０００ビットのトランスポートブロックサイズである。２つの異なる論理チャネルグループのパケットをアグリゲートすることは、スケジューリング持続期間を最小化することを可能にし、従って、ＵＥが電力を節約することを可能にする。

【0090】

他方、スロット＃（２ｎ＋１）＊１０（１０，３０，５０，７０，．．．）では、ＵＥは、より小さい帯域幅によってスケジューリングされ、ＬＣＧ＃１に関して５０００ビットのみのトランスポートサイズによってスケジューリングされてもよい。

【0091】

実現形態の対応する例示的な変形では、関連するＤＲＸ設定が支援情報内で報告されない場合、ｇＮＢは、累積したバッファがレポートに示唆されたＴＢＳを超過すると、ＵＥをスケジューリングする。

【0092】

図８は、上記の解決策のより詳細で例示的な実現形態によるＵＥ動作のためのシーケンス図である。特に、図７のより基本的なフロー図と比較して、ＵＥはまず、ｇＮＢに支援情報を提供するように設定されているか判定し、肯定的な場合にのみ進む。その後、ＵＥは、新しいデータトラフィックの到着をトリガとして使用して、支援情報を決定し、ｇＮＢに報告してもよい。上述したように、ｇＮＢは、受信した支援情報に基づいて、ＵＥのための最適なスケジューリングを決定し、ＵＥに対応するアップリンクグラントを提供してもよい。これに対応して、ＵＥは、以前に報告された支援情報に基づいてスケジューリングされたアップリンクグラントを受信する。次に、ＵＥは、受信したアップリンクグラントに基づいてアップリンク送信（例えば、ＰＵＳＣＨ）を実行してもよい。

【0093】

（実施例２）
第２の実施例が図９～１６に関して以下で説明される。第２の実施例は、ＵＥにおけるアクティブ時間の利用の改良に関する。より詳細には、発明者は、ＵＬデータトラフィックがやや動的なものであるとすることができ、ＤＲＸ機構のＵＥアクティブ期間のちょうど終わりに到着しうるという問題を認識していた。この場合、ＵＥは、ＤＲＸ機構のＤＲＸオフ期間に入る前に、新たなデータ到着に適切に反応することができないかもしれない。さらに、これは、電力を消費するＲＦユニットとおそらく他のハードウェアパーツとのランピングダウン及びランピングアップを伴う、スリープ期間への不要なＵＥ遷移を生じさせうる。

【0094】

これらの問題のあるシナリオは、図９及び図１０に概略的かつ例示的に示される。そこから明らかなように、新しいデータ到着はアクティブ期間の終わりに近い。図９の例示的なシナリオでは、ＵＥは、ＢＳＲリソースが利用可能でない場合、ＢＳＲ(新しいデータを示すバッファステータスレポート）又はスケジューリングリクエスト（ＳＲ）をｇＮＢ（ＢＳ、図示の基地局）に送信する時間さえない。これに対応して、ＵＥは、電力を節約するためにＤＲＸ機構のＤＲＸオフ期間に入り、ＤＲＸオフ期間から出ると、ランピングダウンし、最終的にランピングアップする。次のアクティブ時間の間、ＵＥは、ＢＳＲをｇＮＢに送信する機会を取得する。ｇＮＢは、ＵＥはアクティブ時間中に受信できる（アクティブ時間中、ＵＥは、ＰＤＣＣＨを監視する）アップリンクグラント（ＰＤＣＣＨ）で応答することが例示的に仮定される。次に、ＵＥは、以前に到着したデータをアップリンクにおいてｇＮＢに送信できる。このような状況は、ｇＮＢにデータを送信する際の遅延とともに、関係するランピングダウン及びランピングアップのためにより高い電力消費を生じさせる。

【0095】

他方、図１０に示されるように、ＵＥは、ＢＳＲをｇＮＢに送信するのに十分な時間を有するかもしれないが、ＵＥがアクティブ時間から出る（従って、ＰＤＣＣＨの監視を停止する）前に、ｇＮＢがＢＳＲを処理し（例えば、ＭＡＣ ＣＥ内で受信され）、ＰＤＣＣＨをＵＥに送信する時間はない。アップリンク送信のために端末をスケジューリングすることは、通常のＤＲＸ機構の次のアクティブ期間においてのみ可能である。

【0096】

第２実施例は、以下に説明されるように、アクティブ時間を延長するための機構を実現することによって、この問題に対する解決策を提供する。

【0097】

ＵＥは、典型的なＤＲＸ機構により設定されることが例示的に仮定され、これによると、アクティブ時間の期間（ＰＤＣＣＨの監視を含む通常の通信が可能である）がＵＥのためのスリープ期間（電力節約の機会を可能にするＤＲＸオフ）と交互になる。

【0098】

図１１は、本解決策による簡略化された例示的なＵＥ構造を示し、上記の図５に関連して上述された一般的なＵＥ構造に基づいて実現可能である。図示されたＵＥの様々な構造的要素は、例えば、制御及びユーザデータと他の信号とをやり取りするため、例えば、対応する入力／出力ノード（図示せず）によって互いの間で相互接続可能である。例示目的のため示されていないが、ＵＥは、さらなる構造的要素を含んでもよい。

【0099】

そこから明らかなように、ＵＥは、以下で説明するように、アクティブ時間の延長を実行するための改善された手順に参加するため、延長要求送信機、アクティブ時間延長判定回路及び延長アクティブ時間処理回路を含んでもよい。従って、本例では、処理回路は、例示的に、延長要求を送信すると、アクティブ時間を延長することを自律的に決定するステップを少なくとも部分的に実行するよう構成することができる。従って、送信機は、拡張要求を送信するステップを少なくとも部分的に実行するよう例示的に設定することができる。

【0100】

図１２は、ＵＥによるアクティブ時間の延長に関する改良されたアクティブ時間処理手順に従うＵＥ動作のシーケンス図である。

【0101】

進行中のアクティブ時間を延長するため、ＵＥは、それのサービング基地局（ｇＮＢ）に延長要求を送信してもよく、その後に、アクティブ時間を延長することを自律的に決定してもよい。例えば、ＵＥは、延長要求を送信した後、ｇＮＢからの応答を待たずに、自らアクティブ時間を延長する。それによって、ＵＥは、ＤＲＸオフ時間に入るために通常のＤＲＸ処理に従うのではなく、延長されたアクティブ時間に留まるため、「通常の」ＤＲＸ処理は一時的に中断される。ＵＥは、それに対応して、延長されたアクティブ時間に従って動作するように進む。

【0102】

それによって、スリープへのＵＥの不必要な遷移は、関連するランピングダウン及びランピングアップ電力オーバヘッドとともに、回避されうる。

【0103】

一例によると、延長されたアクティブ時間中のＵＥ動作は、ＤＲＸ機構の通常のアクティブ時間中と同様であるか、又は全く同じであってもよい。例えば、ＵＥ動作は、ＰＤＣＣＨ監視、ＰＤＳＣＨ受信及びＰＵＳＣＨ送信などを含んでもよい。

【0104】

延長されたアクティブ時間に従って動作し続けることは、ＵＥが、最初にアクティブ時間を延長するようにＵＥを初期的にトリガしたプロセスを完了することを容易にする。

【0105】

ここに説明される解決策及び変形の何れか１つに従ってアクティブ時間を延長することは、新しいデータの到着（図９および図１０に関連して言及される）、パワーヘッドルームレポート（ＰＨＲ）を送信する必要性、又は新しいデータが送信のためにすぐに利用可能でないにもかかわらず、新しいデータが近い将来に来ることをＵＥがすでに認識していることなど、様々な理由によってトリガされてもよい。

【0106】

新しいデータの到着がアクティブ時間の延長をトリガしたと例示的に仮定すると、ＵＥは、延長されたアクティブ時間の間に、ＢＳＲ（Ｂｕｆｆｅｒ Ｓｔａｔｕｓ Ｒｅｐｏｒｔ）をｇＮＢに送信し、その後、新しいデータのアップリンク送信を実行できるように、アップリンク無線リソースに従ってスケジューリングされる。これは、図１３に例示されており、延長されたアクティブ期間中に、ＢＳＲがＵＥによってｇＮＢに送信され、ＰＤＣＣＨがｇＮＢからＵＥに送信され、アップリンク送信がＵＥによって実行されることを示す。

【0107】

延長されたアクティブ時間がどのように終了できるかについては、いくつかのオプションがある。１つの例示的なオプションは、決定された時間についてアクティブ時間を延長することである。この延長されたアクティブ時間の長さは、例えば、ＲＲＣを利用して、例えば、ＵＥとｇＮＢとの間で事前に設定できる。異なるオプションによると、延長されたアクティブ時間の長さは、例えば、アクティブ時間を延長するためのトリガイベントに基づいて、ＵＥによって一方的に決定できる。任意選択的には、延長されたアクティブ時間の決定された長さに関する情報は、例えば、延長要求とともに、ｇＮＢに送信することができる。さらに別のオプションは、通常のＤＲＸ機構（図示せず）の次のアクティブ時間までアクティブ時間を延長することである。

【0108】

図１４は、延長されたアクティブ時間が経過しているか否かに関する一般的な決定を提供することによって、図１２に示されたＵＥ動作を延長する、解決策の１つによるＵＥ動作のための例示的なシーケンス図である。延長されたアクティブ時間が過ぎていない場合、ＵＥは、延長されたアクティブ時間に従って動作し続ける。逆に、延長されたアクティブ時間が終了した場合（例えば、数ｍｓ後）、ＵＥは、延長されたアクティブ時間から出て、通常のＤＲＸ機構に従って動作し続ける。例えば、図１３のシナリオは、延長されたアクティブ時間を終了する際の通常のＤＲＸ処理が依然としてＤＲＸオフ時間であると仮定する。

【0109】

さらに異なる選択肢によると、延長されたアクティブ時間を終了することは、以下に説明されるように、スリープ要求を利用してｇＮＢからＵＥによって要求される。図１５及び図１６はこの解決策を示す。図１６は、延長されたアクティブ時間が終了されることをＵＥが決定する際、スリープ要求をｇＮＢに送信するためｇＮＢ（図における基地局ＢＳ）に提供することによって、図１２に示されるＵＥ動作を延長する本解決策によるＵＥ動作のための一例となるシーケンス図である。ＵＥはさらに、スリープ指示がｇＮＢから受信されるか（スリープ要求に応答してｇＮＢによって送信されるか）チェックする。このようなスリープ指示が受信されないとき、ＵＥは、延長されたアクティブ時間に従って動作し続ける。ｇＮＢからこのようなスリープ指示を受信すると、ＵＥは、延長されたアクティブ時間から出て、通常のＤＲＸ機構に従って動作し続けてもよい。

【0110】

スリープ要求を利用することによって取得可能な１つの利点は、延長されたアクティブ時間の長さがＵＥにおけるトラフィック状態にフレキシブルに適応可能であることである。例えば、アクティブの延長を要求する際、データのアップリンク送信がより早期に終了可能であり、従ってスリープ要求がより早期に送信可能となるように、ＵＥは、その後により高いＴＢＳ及び電力によってスケジューリングされてもよい。他方、ＵＥがより低いＴＢＳ及び電力によってスケジューリングされると、ＵＥは、アップリンクでデータを送信するのにより長くかかり、スリープ要求は以降に送信される。しかしながら、何れの場合でも、延長されたアクティブ時間の長さはＵＥによって実際に必要とされる時間に一致し、従って、早期のデータ送信を依然として可能にしながら、最適な省電力化を提供する。

【0111】

延長されたアクティブ時間から出るため、上記のスリープ要求がＵＥによって送信されるが、スリープ要求の使用は、ＤＲＸ機構の通常のアクティブ時間から出るため延長可能である。このような場合、例示的には、ＵＥは、例えば、トラフィックが予想されず、スリープして電力を節約するためのさらなる機会があると判定すると、通常のアクティブ時間中にスリープ要求を送信してもよい。上述したものと同じく、又は同様に、ＵＥは、スリープ要求をｇＮＢに送信し、対応するスリープ指示を受信すると、ＤＲＸ機構のアクティブ時間の次の機会までＤＲＸオフ期間に入る。

【0112】

上述したように、アクティブ時間の延長は異なる理由の組み合わせのためＵＥによって決定可能である。さらに、ＵＥによって送信される延長要求は、アクティブ時間要求がＵＥによってなぜ送信されたかに関する情報をｇＮＢに提供するのに適した通知によって延長可能である。対応して、ＵＥは、サービング基地局に送信される新たなデータ、サービング基地局にＵＥによって送信される新たなバッファステータスレポート、又はサービング基地局にＵＥによって送信される新たなパワーヘッドルームレポートの１つ以上に関する通知と一緒に、延長要求を送信してもよい。

【0113】

１つの例示的な解決策によると、更なる情報は、以下の１つ以上を示してもよい。
・新たに到着したＢＳＲ
・すぐに送信すべきデータはないが、ｄｒｘ－Ｉｎａｃｔｉｖｉｔｙ Ｔｉｍｅｒを満了にしない
・５ｍｓである示唆されたＤＲＸ＿Ｏｎ延長期間
・最近のＰＨＲ
・送信すべきｘ情報ビット／ＴＢＳを依然として少なくとも有し、ＤＲＸ＿ＯＮを延長する
・新たに到着したデータについて推定される必要な電力レベル

【0114】

さらに、アクティブ時間延長要求がどのようにｇＮＢに正確に送信可能であるかに関していくつかの可能性がある。一般に、ＵＥはＰＵＣＣＨリソースまたはＰＵＳＣＨリソースを利用してもよい。例えば、ＵＥは、ＤＲＸ＿ＯＮ（アクティブ時間）の終了まで利用可能なＰＵＣＣＨリソースを利用してもよい。特に、延長要求は、例えば、５ｍｓ毎の周期的なリソースなど、アクティブ時間の終了までの期間内で設定されたリソースの何れかにおいて送信可能である。１つの可能な例示的設定は、延長要求が設定された期間内で最後の機会／時点において送信されることである。例示的には、ＵＥは、スケジューリング要求を送信するため設定された無線リソースを再利用し、及び／又はアクティブ時間延長要求を搬送するため現在のスケジューリング要求通知を延長することが可能である。

【0115】

他の解決策では、ＵＥは、適したＰＵＳＣＨリソースが利用可能であるという仮定の下、ＰＵＳＣＨリソース上でアップリンク制御情報（ＵＣＩ）又はＭＡＣ制御エレメントとして延長要求を送信可能である。再び、ＵＥは、アクティブ時間の満了前に最後の可能なリソースであるＰＵＳＣＨリソースを利用してもよい。

【0116】

１つの更なる例示的な解決策では、ＵＥがアクティブ時間のまさに終了時のもの以外のリソースを利用してもよいか否かは、延長要求と一緒に送信される情報及び／又はアクティブ時間を延長するための理由に依存しうる。例えば、その理由がパワーヘッドルームレポートの送信又は近い将来における新たなデータ（新たなＢＳＲ）到着若しくは新たなデータの到着であるとき、アクティブ時間延長要求は、アクティブ時間における最後の機会でのみ送信されてもよい。

【0117】

さらに、ここに説明される第２の実施例はまた、上述した第１の実施例と組み合わされてもよい。例えば、アクティブ時間の延長に対する要求は、支援情報と一緒にｇＮＢに送信可能である。一例となる解決策では、アクティブ時間が延長されるケースにおいてｇＮＢに送信される支援情報は、
・サービング基地局にＵＥによって送信されると予想されるビット数
・サービング基地局にＵＥによって送信される新たなデータを送信するのに必要な電力レベル
の１つ以上とすることが可能である。これにより、第１及び第２の実施例の効果が組み合わせ可能である。

【0118】

（更なる態様）
第１の態様によると、動作中にＵＥのサービング基地局に送信される支援情報を決定する処理回路を有するＵＥが提供される。ＵＥの送信機は、決定した支援情報を含む支援レポートをＵＥのサービング基地局に送信する。支援情報は、以下の支援情報タイプ、
・ＵＥによってサービング基地局に送信される情報ビットの数、
・情報ビットをサービング基地局に送信するためＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズ、
・情報ビットをサービング基地局に送信するためＵＥによって使用される最小電力を示す電力レベル、
・間欠受信（ＤＲＸ）機構を動作させるためＵＥによって使用される１つ以上のＤＲＸ設定パラメータ、の１つ以上を示す。

【0119】

第１の態様に加えて提供される第２の態様によると、ＵＥは、動作中にアップリンク送信を実行するためＵＥによって使用可能な無線リソース割当てをサービング基地局から受信する受信機を更に有する。

【0120】

第１又は第２の態様に加えて提供される第３の態様によると、支援レポートは、任意選択的には、」ＲＲＣプロトコルメッセージの情報要素において、物理レイヤのＵｐｌｉｎｋ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ（ＵＣＩ）、Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ（ＭＡＣ） Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ、又はＲａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ（ＲＲＣ）プロトコルのメッセージとして送信される。

【0121】

第１から第３の態様の何れかに加えて提供される第４の態様によると、情報ビットの数は、
・ＵＥによってサービング基地局に送信されるアップリンクトラフィックの典型的なパケットサイズＵ、
・アップリンクトラフィックの典型的な到着時間Ｔ、
・アップリンクトラフィックに対して充足されるべき遅延要求Ｌ、
の少なくとも１つなどの１つ以上のトラフィック特性に基づいてＵＥによって決定され、
任意選択的には、情報ビットの数Ｉは、
Ｉ＝Ｕ＊ｃｅｉｌｉｎｇ（Ｌ／Ｔ）
の式に基づいて決定される。

【0122】

第１から第４の態様の何れかに加えて提供される第５の態様によると、処理回路は、動作中に、
・情報ビットの数Ｉ、
・符号化レートＣ、
・変調次数Ｍ、
の少なくとも１つに基づいてトランスポートブロックのトランスポートブロックサイズを決定し、
任意選択的には、トランスポートブロックサイズ（ＴＢＳ）は、
ＴＢＳ＝Ｉ＊Ｃ／Ｍ
の式に基づいて決定され、
任意選択的には、処理回路は、動作中に前のアップリンク無線リソース割当てにおいて、又はリファレンス変調符号化方式（ＭＣＳ）レベルにおいてサービング基地局によってＵＥに割り当てられるＭＣＳレベルから符号化レートと変調次数とを決定する。

【0123】

第１から第５の態様の何れかに加えて提供される第６の態様によると、処理回路は、動作中に、
・情報ビットの数Ｉ、
・ＵＥからサービング基地局に情報ビットの数を送信するため必要とされる周波数帯域幅ＢＷ、
・ＵＥとサービング基地局との間のパスのパスロス測定値ＰＬ、
の１つ以上に基づいて電力レベルを決定し、
任意選択的には、電力レベルＰＣは、
ＰＣ＝１０＊ｌｇ（ＢＷ）＋Ｐ_Ｏ＋ａｌｐｈａ＊ＰＬ
の式に基づいて決定され、Ｐ_Ｏ及びａｌｐｈａは、ＲＲＣメッセージにおいて上位レイヤによって設定される。

【0124】

第１から第６の態様の何れかに加えて提供される第７の態様によると、支援情報は、ＤＲＸ設定に関連付けされる。任意選択的には、支援情報は、ＤＲＸ機構を動作させるため、ユーザ装置によって現在使用される各ＤＲＸ設定パラメータと異なる１つ以上のＤＲＸ設定パラメータを示す。

【0125】

第１から第７の態様の何れかに加えて提供される第８の態様によると、処理回路は、動作中にトラフィックのタイプ毎及び／又は論理チャネルグループ毎に支援情報を決定する。

【0126】

第１から第８の態様の何れかに加えて提供される第９の態様によると、支援情報は、各支援情報タイプについて個別の値を含み、任意選択的には、個別の値は、異なる個別の値と支援情報タイプとの間の関連付けに基づいて、処理回路によって決定される。支援情報は、支援情報タイプの２つ以上の組み合わせに対して１つの結合値を含み、任意選択的には、結合値は、支援情報タイプの異なる組み合わせと異なる結合値との間の関連付けに基づいて、処理回路によって決定される。任意選択的には、関連付けは、サービング基地局から受信するＲＲＣメッセージに基づいてＵＥによって設定される。

【0127】

第１から第９の態様の何れかに加えて提供される第１０の態様によると、支援情報タイプは、絶対値を利用して符号化される。あるいは、支援情報タイプは、基準値に関する差分である差分値を利用して符号化され、各支援情報タイプの絶対値は、差分値と基準値とに基づいて決定され、任意選択的には、基準値は、サービング基地局から受信した前の無線リソース割当てに基づいて移動端末によって決定される。

【0128】

第１から第１０の態様の何れかに加えて提供される第１１の態様によると、支援情報は更に、
・サービング基地局からＵＥに送信される情報ビットの数、
・ＵＥから情報ビットを送信するためサービング基地局によって使用されるトランスポートブロックのトランスポートブロックサイズ、
・間欠受信（ＤＲＸ）機構を動作させるためＵＥによって使用される１つ以上のＤＲＸ設定パラメータ、
の支援情報タイプの１つ以上を示す。

【0129】

第１２の態様によると、ユーザ装置（ＵＥ）によって実行される、
ＵＥのサービング基地局に送信される支援情報を決定するステップと、
決定された支援情報を含む支援レポートをＵＥのサービング基地局に送信するステップと、
を有し、
支援情報は、
・ＵＥによってサービング基地局に送信される情報ビットの数、
・情報ビットをサービング基地局に送信するためＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズ、
・情報ビットをサービング基地局に送信するためＵＥによって使用される最小電力を示す電力レベル、
・間欠受信（ＤＲＸ）機構を動作させるためＵＥによって使用される１つ以上のＤＲＸ設定パラメータ、
の支援情報タイプの１つ以上を示す、方法が提供される。

【0130】

第１３の態様によると、動作中に基地局によってサービス提供されるユーザ装置（ＵＥ）から支援レポートを受信する処理回路を有する基地局が提供される。支援レポートは、支援情報を含む。処理回路は、動作中に受信した支援情報に基づいて、アップリンク送信を実行するためＵＥに割り当てられる無線リソースを決定する。送信機は、動作中に決定された無線リソースを示す無線リソース割当てをＵＥに送信する。支援情報は、
・ＵＥによってサービング基地局に送信される情報ビットの数、
・情報ビットをサービング基地局に送信するためＵＥによって使用されるトランスポートブロックのトランスポートブロックサイズ、
・情報ビットをサービング基地局に送信するためＵＥによって使用される最小電力を示す電力レベル、
・間欠受信（ＤＲＸ）機構を動作させるためＵＥによって使用される１つ以上のＤＲＸ設定パラメータ、
の支援情報タイプの１つ以上を示す。

【0131】

第１４の態様によると、動作中にＵＥのサービング基地局に、間欠受信（ＤＲＸ）機構のアクティブ時間を延長するための延長要求を送信する送信機を有するユーザ装置が提供される。延長要求はアクティブ時間の間に送信される。ＵＥは、動作中に延長要求を送信すると、アクティブ時間を延長することを自律的に決定する処理回路を有する。ＵＥは、延長されたアクティブ時間に従って動作する。

【0132】

第１４の態様に加えて提供される第１５の態様によると、送信機は、動作中に、
・ＵＥによってサービング基地局に送信される新たなバッファステータスレポート、又はＵＥによってサービング基地局に送信される新たなパワーヘッドルームレポートなど、延長要求を送信するためのトリガに関する情報、
・ＵＥによってサービング基地局に送信されると予想されるビットの数、
・ＵＥによってサービング基地局に送信される新たなデータを送信するのに必要とされる電力レベル、
・アクティブ時間が延長される期間、
の１つ以上と一緒に、延長要求を送信する。

【0133】

第１４又は第１５の態様に加えて提供される第１６の態様によると、送信機は、動作中に、
・アップリンク制御チャネルの無線リソース、任意選択的には、アクティブ時間が満了する前のアップリンク制御チャネルの最後の無線リソース、
・アップリンク共有チャネルの無線リソース、任意選択的には、アクティブ時間が満了する前のアップリンク共有チャネルの最後の無線リソース、
のアップリンク無線リソースの１つを使用して延長要求を送信する。

【0134】

第１４～第１６の態様に加えて提供される第１７の態様によると、送信機は、動作中にサービング基地局に、延長されたアクティブ時間から出て、ＤＲＸ機構のスリープ期間に入るスリープ要求を送信する。受信機は、動作中にサービング基地局からスリープ指示を受信する。処理回路は、動作中にスリープ指示にもとづいて、アクティブ時間から出て、ＤＲＸ機構のスリープ期間に入ることを決定する。

【0135】

第１４～第１６の態様の何れかに加えて提供される第１８の態様によると、延長されたアクティブ時間の間、
・送信機は、動作中にバッファステータスレポート、パワーヘッドルームレポート及びアップリンクデータの１つ以上をサービング基地局に送信し、
・受信機は、動作中にダウンリンク制御チャネルを監視し、サービング基地局から制御情報を受信する。

【0136】

第１９の態様によると、
ユーザ装置（ＵＥ）によって実行される、
ＵＥのサービング基地局に、間欠受信（ＤＲＸ）機構のアクティブ時間を延長するための延長要求を送信するステップであって、延長要求はアクティブ時間の間に送信される、ステップと、
延長要求を送信すると、アクティブ時間を延長することを自律的に決定するステップと、
延長されたアクティブ時間に従ってＵＥを動作させるステップと、
を有する方法が提供される。

【0137】

第２０の態様によると、動作中にＵＥから間欠受信（ＤＲＸ）機構のアクティブ時間を延長するための延長要求を受信する受信機を有する基地局が提供される。延長要求はアクティブ時間の間に送信される。基地局は更に、動作中に延長要求を送信すると、ＵＥがアクティブ時間を自律的に延長し、延長されたアクティブ時間に従って動作することを決定する処理回路を有する。基地局は、延長されたアクティブ時間に従って動作する。

【0138】

本開示のハードウェア及びソフトウェア実現形態
本開示は、ソフトウェア、ハードウェア又はハードウェアと連携したソフトウェアによって実現できる。上述される各実施例の説明に用いられる各機能ブロックは、集積回路などのＬＳＩによって部分的又は全体的に実現可能であり、各実施例において説明される各処理は、同一のＬＳＩ又はＬＳＩの組み合わせによって部分的又は全体的に制御されてもよい。ＬＳＩは、チップとして個別に形成されてもよいし、あるいは、機能ブロックの一部又は全てを含むように、１つのチップが形成されてもよい。ＬＳＩは、それに結合されるデータ入力及び出力を含んでもよい。ここでのＬＳＩは、集積度の差に応じてＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、システムＬＳＩ、スーパＬＳＩ又はウルトラＬＳＩとして参照されてもよい。しかしながら、集積回路を実現する技術は、ＬＳＩに限定されず、専用回路、汎用プロセッサ又は特定用途向けプロセッサを利用することによって実現されてもよい。さらに、ＬＳＩの製造後にプログラム可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）又はＬＳＩ内に配置された回路セルの接続及び設定が再構成可能であるリコンフィギュラブルプロセッサが利用されてもよい。本開示は、デジタル処理又はアナログ処理として実現できる。将来の集積回路技術が半導体技術又は他の派生技術の進歩の結果としてＬＳＩに取って代わる場合、機能ブロックは、将来の集積回路技術を利用して集積可能である。バイオテクノロジがまた適用可能である。

【0139】

本開示は、通信装置として参照される通信機能を有する何れかのタイプの装置、デバイス又はシステムによって実現することができる。

【0140】

このような通信装置のいくつかの非限定的な例は、電話機（例えば、携帯（セル）電話、スマートフォン）、タブレット、パーソナルコンピュータ（ＰＣ）(例えば、ラップトップ、デスクトップ、ネットブック）、カメラ（例えば、デジタルスチル／ビデオカメラ）、デジタルプレーヤ（デジタルオーディオ／ビデオプレーヤ）、ウェアラブルデバイス（例えば、ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、デジタルブックリーダ、遠隔ヘルス／遠隔医療（リモートヘルス及び医療）デバイス、及び通信機能を提供する車両（例えば、自動車、飛行機、船舶）、並びにこれらの各種組み合わせを含む。

【0141】

通信装置は、携帯型又は可動型であることに限定されず、スマートホームデバイス（例えば、家電、ライティング、スマートメータ、コントロールパネル）、自動販売機、及び「Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）」のネットワーク内の他の何れかの「物」など、非携帯型又は固定型な何れかのタイプの装置、デバイス又はシステムを含んでもよい。

【0142】

通信は、例えば、セルラシステム、無線ＬＡＮシステム、衛星システムなど、及びこれらの各種組合せを介してデータを交換することを含んでもよい。

【0143】

通信装置は、本開示に記載された通信機能を実行する通信デバイスに結合されたコントローラ又はセンサなどのデバイスを有してもよい。例えば、通信装置は、制御信号又はデータ信号を生成するコントローラ又はセンサを有してもよく、これらは、通信装置の通信機能を実行する通信デバイスによって使用される。

【0144】

通信装置はまた、基地局、アクセスポイントなどのインフラストラクチャ施設と、上記の非限定的な例におけるものなどの装置と通信又は制御する他の何れかの装置、デバイス又はシステムとを含んでもよい。

【0145】

さらに、各種実施例は、プロセッサ又はハードウェアで直接的に実行されるソフトウェアモジュールによって実現されてもよい。また、ソフトウェアモジュールとハードウェア実装との組み合わせが可能であってもよい。ソフトウェアモジュールは、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ，レジスタ，ハードディスク、ＣＤ－ＲＯＭ、ＤＶＤ等の何れかのタイプのコンピュータ可読記憶媒体に記憶されてもよい。さらに、異なる実施例の個々の特徴は個別に又は任意の組合せで他の実施例の主題であってもよいことに留意されたい。

【0146】

多数の変形及び／又は改良が、具体的な実施例に示されるような本開示に対して行われうることは、当業者によって理解されるであろう。従って、本実施例は、すべての点で例示であり、限定ではないと考えられるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】