特開 2025-13421 超高信頼送信の拡張制御シグナリングのための方法、装置およびシステム

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

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

(11)【公開番号】P2025013421

(43)【公開日】2025-01-24

(54)【発明の名称】超高信頼送信の拡張制御シグナリングのための方法、装置およびシステム

(51)【国際特許分類】

   H04W 28/04 20090101AFI20250117BHJP

   H04W 72/566 20230101ALI20250117BHJP

   H04W 72/21 20230101ALI20250117BHJP

   H04W 72/232 20230101ALI20250117BHJP

【ＦＩ】

H04W28/04 110

H04W72/566

H04W72/21

H04W72/232

【審査請求】有

【請求項の数】20

【出願形態】ＯＬ

(21)【出願番号】P 2024191881

(22)【出願日】2024-10-31

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

【原出願日】2020-01-06

(31)【優先権主張番号】62/790,428

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

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

(31)【優先権主張番号】62/875,227

(32)【優先日】2019-07-17

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

(31)【優先権主張番号】62/886,035

(32)【優先日】2019-08-13

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

(31)【優先権主張番号】62/931,389

(32)【優先日】2019-11-06

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

(71)【出願人】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】エル ハマス、アータ

(72)【発明者】

【氏名】アルファルファン、ファリス

(72)【発明者】

【氏名】マリニエール、ポール

(72)【発明者】

【氏名】オテリ、オゲネコム

(72)【発明者】

【氏名】プレテイエ、ジスレン

(57)【要約】

【課題】ワイヤレス送信受信ユニット（ＷＴＲＵ）において実施される方法が開示される。
【解決手段】ＷＴＲＵが、第１及び第２のスロットまたはミニスロット中で第１及び第２のサービスタイプまたは優先度レベルに関連付けられた第１及び第２の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）を受信し、第１及び第２のＨＡＲＱ－ＡＣＫ情報のための第１及び第２の物理アップリンク制御チャネル（ＰＵＣＣＨ）を決定し、第１及び第２のＨＡＲＱ－ＡＣＫ情報の優先度を決定し、第１及び第２のＰＵＣＣＨリソースが時間において重複すること且つ第１及び第２のＨＡＲＱ情報の優先度が異なることを条件に、より低い優先度のＨＡＲＱ情報がより高い優先度のＨＡＲＱ情報と多重されることが許されると決定し、多重されることが許されることを条件に、第１及び第２のＨＡＲＱ情報を多重し、単一のＰＵＣＣＨ送信内で送る。
【選択図】図６

【特許請求の範囲】

【請求項1】

ワイヤレス送信受信ユニット（ＷＴＲＵ）であって、
受信機および送信機、並びにプロセッサを備え、
前記受信機は、
第１の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）送信を受信し、
第２のＰＤＳＣＨ送信を受信する、
ように構成され、
前記プロセッサは、
前記第１のＰＤＳＣＨ送信と関連付けられた第１のハイブリッド自動再送要求（ＨＡＲＱ）情報の送信のための第１の物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを決定し、
前記第２のＰＤＳＣＨ送信と関連付けられた第２のＨＡＲＱ情報の送信のための第２のＰＵＣＣＨリソースを決定し、
前記第１のＨＡＲＱ情報および前記第２のＨＡＲＱ情報の各々の優先度を決定し、
前記第１のＰＵＣＣＨリソースが前記第２のＰＵＣＣＨリソースと時間において重複することを条件に、かつ前記第１のＨＡＲＱ情報の前記優先度が前記第２のＨＡＲＱ情報の前記優先度と異なることを条件に、より低い優先度のＨＡＲＱ情報がより高い優先度のＨＡＲＱ情報と多重されることが許されると決定する、
ように構成され、
前記送信機は、前記第１のＨＡＲＱ情報および前記第２のＨＡＲＱ情報を多重し、該多重された第１のＨＡＲＱ情報および第２のＨＡＲＱ情報を単一のＰＵＣＣＨ送信内で送るように、構成され、当該多重は、前記より低い優先度のＨＡＲＱ情報が前記より高い優先度のＨＡＲＱ情報と多重されることが許されることを条件とする、
ＷＴＲＵ。

【請求項2】

前記受信機は、ＨＡＲＱ情報の送信のために用いられる複数のＰＵＣＣＨリソースセットを示す構成情報を受信するように構成され、前記複数のＰＵＣＣＨリソースセットの各々が複数のＰＵＣＣＨリソースを含む、請求項１に記載のＷＴＲＵ。

【請求項3】

前記受信機は、第１のダウンリンク制御情報（ＤＣＩ）において、（１）第１のＰＵＣＣＨセットインジケーションおよび（２）第１のリソースインジケータを含む情報を受信するように構成され、前記第１のＰＵＣＣＨセットインジケーションおよび前記第１のリソースインジケータは前記第１のＤＣＩ内の分離されたフィールドである、請求項１に記載のＷＴＲＵ。

【請求項4】

前記受信機は、第２のＤＣＩにおいて、（１）第２のＰＵＣＣＨセットインジケーションおよび（２）第２のリソースインジケータを含む情報を受信するように構成され、前記第２のＰＵＣＣＨセットインジケーションおよび前記第２のリソースインジケータは前記第２のＤＣＩ内の分離されたフィールドである、請求項１に記載のＷＴＲＵ。

【請求項5】

前記受信機は、第１のダウンリンク制御情報（ＤＣＩ）において、（１）第１のＰＵＣＣＨセットインジケーションおよび（２）第１のリソースインジケータを含む情報を受信するように構成され、前記プロセッサは、前記第１のＰＵＣＣＨセットインジケーションに少なくとも基づいて、前記複数のＰＵＣＣＨリソースセットのうちの第１のＰＵＣＣＨリソースセットを選択するように構成されている、請求項２に記載のＷＴＲＵ。

【請求項6】

前記第１のＨＡＲＱ情報の送信のための第１のＰＵＣＣＨリソースを決定するように構成されたプロセッサは、前記第１のリソースインジケータに少なくとも基づいて、前記選択された第１のＰＵＣＣＨリソースセットの前記複数のＰＵＣＣＨリソースのうちの第１のＰＵＣＣＨリソースを選択するように構成されたプロセッサを含む、請求項５に記載のＷＴＲＵ。

【請求項7】

前記受信機は、第２のＤＣＩにおいて、（１）第２のＰＵＣＣＨセットインジケーションおよび（２）第２のリソースインジケータを含む情報を受信するように構成され、前記プロセッサは、前記第２のＰＵＣＣＨセットインジケーションに少なくとも基づいて、前記複数のＰＵＣＣＨリソースセットのうちの第２のＰＵＣＣＨリソースセットを選択するように構成されている、請求項２に記載のＷＴＲＵ。

【請求項8】

前記第２のＨＡＲＱ情報の送信のための第２のＰＵＣＣＨリソースを決定するように構成されたプロセッサは、前記第２のリソースインジケータに少なくとも基づいて、前記選択された第２のＰＵＣＣＨリソースセットの前記複数のＰＵＣＣＨリソースのうちの第２のＰＵＣＣＨリソースを選択するように構成されたプロセッサを含む、請求項７に記載のＷＴＲＵ。

【請求項9】

前記より低い優先度のＨＡＲＱ情報が前記より高い優先度のＨＡＲＱ情報と多重されることが許されないことを条件に、前記単一のＰＵＣＣＨ送信は、前記より高い優先度のＨＡＲＱ情報を含み、前記より低い優先度のＨＡＲＱ情報を含まない、請求項１に記載のＷＴＲＵ。

【請求項10】

前記より低い優先度のＨＡＲＱ情報および前記より高い優先度のＨＡＲＱ情報は、前記多重の前に別々に符号化される、請求項１に記載のＷＴＲＵ。

【請求項11】

ワイヤレス送信受信ユニット（ＷＴＲＵ）において実施される方法であって、
第１の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）送信を受信することと、
前記第１のＰＤＳＣＨ送信と関連付けられた第１のハイブリッド自動再送要求（ＨＡＲＱ）情報の送信のための第１の物理アップリンク制御チャネル（ＰＵＣＣＨ）リソースを決定することと、
第２のＰＤＳＣＨ送信を受信することと、
前記第２のＰＤＳＣＨ送信と関連付けられた第２のＨＡＲＱ情報の送信のための第２のＰＵＣＣＨリソースを決定することと、
前記第１のＨＡＲＱ情報および前記第２のＨＡＲＱ情報の各々の優先度を決定することと、
前記第１のＰＵＣＣＨリソースが前記第２のＰＵＣＣＨリソースと時間において重複することを条件に、かつ前記第１のＨＡＲＱ情報の前記優先度が前記第２のＨＡＲＱ情報の前記優先度と異なることを条件に、より低い優先度のＨＡＲＱ情報がより高い優先度のＨＡＲＱ情報と多重されることが許されると決定することと、
前記より低い優先度のＨＡＲＱ情報が前記より高い優先度のＨＡＲＱ情報と多重されることが許されることを条件に、前記第１のＨＡＲＱ情報および前記第２のＨＡＲＱ情報を多重し、該多重された第１のＨＡＲＱ情報および第２のＨＡＲＱ情報を単一のＰＵＣＣＨ送信内で送ることと、
を含む方法。

【請求項12】

ＨＡＲＱ情報の送信のために用いられる複数のＰＵＣＣＨリソースセットを示す構成情報を受信することをさらに含み、前記複数のＰＵＣＣＨリソースセットの各々が複数のＰＵＣＣＨリソースを含む、請求項１１に記載の方法。

【請求項13】

第１のダウンリンク制御情報（ＤＣＩ）において、（１）第１のＰＵＣＣＨセットインジケーションおよび（２）第１のリソースインジケータを含む情報を受信することをさらに含み、前記第１のＰＵＣＣＨセットインジケーションおよび前記第１のリソースインジケータは前記第１のＤＣＩ内の分離されたフィールドである、請求項１１に記載の方法。

【請求項14】

第２のＤＣＩにおいて、（１）第２のＰＵＣＣＨセットインジケーションおよび（２）第２のリソースインジケータを含む情報を受信することをさらに含み、前記第２のＰＵＣＣＨセットインジケーションおよび前記第２のリソースインジケータは前記第２のＤＣＩ内の分離されたフィールドである、請求項１１に記載の方法。

【請求項15】

第１のダウンリンク制御情報（ＤＣＩ）において、（１）第１のＰＵＣＣＨセットインジケーションおよび（２）第１のリソースインジケータを含む情報を受信することと、
前記第１のＰＵＣＣＨセットインジケーションに少なくとも基づいて、前記複数のＰＵＣＣＨリソースセットのうちの第１のＰＵＣＣＨリソースセットを選択することと、
をさらに含む、請求項１２に記載の方法。

【請求項16】

前記第１のＨＡＲＱ情報の送信のための第１のＰＵＣＣＨリソースを決定ことは、前記第１のリソースインジケータに少なくとも基づいて、前記選択された第１のＰＵＣＣＨリソースセットの前記複数のＰＵＣＣＨリソースのうちの第１のＰＵＣＣＨリソースを選択することを含む、請求項１５に記載の方法。

【請求項17】

第２のＤＣＩにおいて、（１）第２のＰＵＣＣＨセットインジケーションおよび（２）第２のリソースインジケータを含む情報を受信することと、
前記第２のＰＵＣＣＨセットインジケーションに少なくとも基づいて、前記複数のＰＵＣＣＨリソースセットのうちの第２のＰＵＣＣＨリソースセットを選択することと、
をさらに含む、請求項１２に記載の方法。

【請求項18】

前記第２のＨＡＲＱ情報の送信のための第２のＰＵＣＣＨリソースを決定することは、前記第２のリソースインジケータに少なくとも基づいて、前記選択された第２のＰＵＣＣＨリソースセットの前記複数のＰＵＣＣＨリソースのうちの第２のＰＵＣＣＨリソースを選択することを含む、請求項１７に記載の方法。

【請求項19】

前記より低い優先度のＨＡＲＱ情報が前記より高い優先度のＨＡＲＱ情報と多重されることが許されないことを条件に、前記単一のＰＵＣＣＨ送信は、前記より高い優先度のＨＡＲＱ情報を含み、前記より低い優先度のＨＡＲＱ情報を含まない、請求項１１に記載の方法。

【請求項20】

前記より低い優先度のＨＡＲＱ情報および前記より高い優先度のＨＡＲＱ情報は、前記多重の前に別々に符号化される、請求項１１に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書で開示される実施形態は、一般にワイヤレス通信に関し、たとえば、たとえばサービスタイプに基づく、（たとえば、超高信頼送信の）拡張制御シグナリングのための方法、装置およびシステムに関する。

【背景技術】

【0002】

関連出願の相互参照
本出願は、２０１９年１月９日に出願された米国特許出願第６２／７９０，４２８号明細書、２０１９年７月１７日に出願された米国特許出願第６２／８７５，２２７号明細書、２０１９年８月１３日に出願された米国特許出願第６２／８８６，０３５号明細書および２０１９年１１月６日に出願された米国特許出願第６２／９３１，３８９号明細書の優先権の利益を主張し、各々の内容は、本明細書に完全に記載されているかのように参照により組み込まれる。

【0003】

あるネットワークは、超高信頼送信を可能にし得る、ネットワークスライシング原理を用いて実装されることが可能である。

【発明の概要】

【0004】

ネットワーク中のワイヤレス送受信ユニット（ＷＴＲＵ）による動作のための方法および装置が提供される。一実施形態では、方法は、ＷＴＲＵが、第１のスロットまたは第１のミニスロット中で第１のサービスタイプまたは第１の優先度レベルに関連付けられた第１の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）、および第２のスロットまたは第２のミニスロット中で第２のサービスタイプまたは第２の優先度レベルに関連付けられた第２のＰＤＳＣＨを受信することと、第１のＰＤＳＣＨのプロパティまたは第１のＰＤＳＣＨに関連付けられた制御情報に基づいて第１のＨＡＲＱコードブック肯定応答インデックス（ＨＣＡＩ）を、および第２のＰＤＳＣＨのプロパティまたは第２のＰＤＳＣＨに関連付けられた制御情報に基づいて第２のＨＣＡＩを決定することとを含み得る。本方法は、後続のスロットまたは後続のミニスロットのために、第１のＨＣＡＩに従って第１のＨＡＲＱ－ＡＣＫ情報を含む第１の物理アップリンク制御チャネル（ＰＵＣＣＨ）を生成し、第２のＨＣＡＩに従って第２のＨＡＲＱ－ＡＣＫ情報を含む第２のＰＵＣＣＨを生成することと、第１および第２のＰＵＣＣＨを送信することとをさらに含み得る。

【図面の簡単な説明】

【0005】

より詳細な理解は、本明細書に添付された図面とともに例として与えられる、以下の詳細な説明から有されよう。説明における図は、例である。したがって、図および詳細な説明は、限定的であると考えられるべきではなく、他の等しく有効な例が可能であり可能性がある。さらに、図における同じ参照番号は、同じ要素を示す。

【図1A】１つまたは複数の開示される実施形態が実装され得る例示的な通信システムを示すシステム図である。

【図1B】実施形態による図１Ａに示されている通信システム内で使用され得る例示的なワイヤレス送受信ユニット（ＷＴＲＵ）を示すシステム図である。

【図1C】実施形態による図１Ａに示されている通信システム内で使用され得る例示的な無線アクセスネットワーク（ＲＡＮ）および例示的なコアネットワーク（ＣＮ）を示すシステム図である。

【図1D】実施形態による図１Ａに示されている通信システム内で使用され得るさらなる例示的なＲＡＮおよびさらなる例示的なＣＮを示すシステム図である。

【図2】超高信頼低レイテンシ通信（ＵＲＬＳ）／拡張ＵＲＬＬＣ（ｅＵＲＬＬＣ）サービスおよび拡張モバイルブロードバンド（ｅＭＢＢ）サービスのための制御シグナリングを搬送するために使用される時間周波数リソースを示す図である。

【図3】ｅＭＢＢサービスまたはＵＲＬＬＣ／ｅＵＲＬＬＣサービスのために使用されるビットフィールドの代表的なセットを示す図である。

【図4】ｅＭＢＢサービスまたはＵＲＬＬＣ／ｅＵＲＬＬＣサービスのために使用されるビットフィールドの他の代表的なセットを示す図である。

【図5】様々なＨＡＲＱフィードバックタイミングを示す図である。

【図6】フィードバック情報（たとえば、ＨＡＲＱコードブック肯定応答インデックス（ＨＣＡＩ））を使用する代表的な手順を示す図である。

【図7】衝突決定の後の代表的な送信手順を示す図である。

【図8】代表的なＷＴＲＵ内優先度付け処理を示す図である。

【図9】オーバーフローリソースを使用する代表的な手順を示す図である。

【図10】フィードバック情報（たとえば、ＨＣＡＩ）を使用する代表的な手順を示すフローチャートである。

【図11】フィードバック情報（たとえば、ＨＣＡＩ）を使用する別の代表的な手順を示すフローチャートである。

【図12】（たとえば、ｅＭＢＢおよびＵＲＬＬＣまたは拡張ＵＲＬＬＣ情報／制御シグナリングの）時間領域重複のための代表的な手順を示すフローチャートである。

【図13】非優先の情報／制御シグナリング（たとえば、ＨＡＲＱ肯定応答（ＨＡＲＱ－ＡＣＫ））のためのオーバーフローリソースを使用する代表的な手順を示すフローチャートである。

【図14】（たとえば、サービスタイプに基づく）ビットフィールド解釈を使用する代表的な手順を示すフローチャートである。

【図15】（たとえば、サービスタイプに基づく）ＨＡＲＱフィードバックのための代表的な手順を示すフローチャートである。

【図16】代表的な上書き手順を示すフローチャートである。

【図17】予期される衝突を回避するための代表的な手順を示すフローチャートである。

【図18】代表的な多重化手順を示すフローチャートである。

【図19】（たとえば、アップリンク制御情報（ＵＣＩ）の送信のための）代表的な手順を示すフローチャートである。

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

【0006】

実施形態の実装のための例示的なネットワーク
図１Ａは、１つまたは複数の開示される実施形態が実装され得る例示的な通信システム１００を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに提供する多元接続システムであり得る。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含むシステムリソースの共有を通してそのようなコンテンツにアクセスすることを可能にし得る。たとえば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）、ゼロテールユニークワードＤＦＴ拡散ＯＦＤＭ（ＺＴ ＵＷ ＤＴＳ－ｓ ＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ－ＯＦＤＭ）、リソースブロックフィルタードＯＦＤＭ、フィルタバンクマルチキャリア（ＦＢＭＣ）など、１つまたは複数のチャネルアクセス方法を採用し得る。

【0007】

図１Ａに示されているように、通信システム１００は、ワイヤレス送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、ＲＡＮ１０４／１１３、ＣＮ１０６／１１５、公衆交換電話ネットワーク（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含み得るが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することが諒解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、ワイヤレス環境において動作および／または通信するように構成された任意のタイプのデバイスであり得る。例として、「局」および／または「ＳＴＡ」といずれも呼ばれることがある、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されることがあり、ユーザ機器（ＵＥ）、移動局、固定またはモバイル加入者ユニット、サブスクリプションベースのユニット、ページャ、セルラー電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサー、ホットスポットまたはＭｉ－Ｆｉデバイス、モノのインターネット（ＩｏＴ）デバイス、ウォッチまたは他のウェアラブル、ヘッドマウントディスプレイ（ＨＭＤ）、車両、ドローン、医療デバイスおよびアプリケーション（たとえば、遠隔手術）、工業デバイスおよびアプリケーション（たとえば、産業および／または自動処理チェーンコンテキストにおいて動作するロボットおよび／または他のワイヤレスデバイス）、コンシューマーエレクトロニクスデバイス、商用および／または産業ワイヤレスネットワーク上で動作するデバイスなどを含み得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのいずれも、互換的にＵＥと呼ばれることがある。

【0008】

通信システム１００はまた、基地局１１４ａおよび／または基地局１１４ｂを含み得る。基地局１１４ａ、１１４ｂの各々は、ＣＮ１０６／１１５、インターネット１１０、および／または他のネットワーク１１２など、１つまたは複数の通信ネットワークへのアクセスを促進するためにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインターフェースするように構成された任意のタイプのデバイスであり得る。例として、基地局１１４ａ、１１４ｂは、基地トランシーバ局（ＢＴＳ）、ノードＢ、ｅノードＢ（ｅＮＢ）、ホームノードＢ（ＨＮＢ）、ホームｅノードＢ（ＨｅＮＢ）、ｇＮＢ、ＮＲノードＢ、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどであり得る。基地局１１４ａ、１１４ｂは単一の要素としてそれぞれ図示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含み得ることが諒解されよう。

【0009】

基地局１１４ａは、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノードなど、他の基地局および／またはネットワーク要素（図示されず）をも含み得る、ＲＡＮ１０４／１１３の一部であり得る。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示されず）と呼ばれることがある１つまたは複数のキャリア周波数上でワイヤレス信号を送信および／または受信するように構成され得る。これらの周波数は、認可スペクトル、無認可スペクトル、または認可スペクトルと無認可スペクトルの組合せの中にあり得る。セルは、比較的固定であり得るかまたは時間とともに変化し得る特定の地理的エリアにワイヤレスサービスのカバレージを提供し得る。セルは、セルセクタにさらに分割され得る。たとえば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割され得る。したがって、一実施形態では、基地局１１４ａは、３つのトランシーバを含むことがあり、すなわち、セルのセクタごとに１つを含むことがある。実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用することがあり、セルのセクタごとに複数のトランシーバを利用することがある。たとえば、所望の空間方向に信号を送信および／または受信するためにビームフォーミングが使用され得る。

【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】

ＳＧＷ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４中のｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続され得る。ＳＧＷ１６４は、概して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／からユーザデータパケットをルーティングおよびフォワーディングし得る。ＳＧＷ１６４は、ｅノードＢ間ハンドオーバ中にユーザプレーンをアンカリングすること、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのために利用可能であるときページングをトリガリングすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理し記憶することなど、他の機能を実施し得る。

【0037】

ＳＧＷ１６４はＰＧＷ１６６に接続されることがあり、ＰＧＷ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進するために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。

【0038】

ＣＮ１０６は、他のネットワークと通信を促進し得る。たとえば、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来のランドライン通信デバイスとの間の通信を促進するために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。たとえば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとして働くＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、またはそれと通信し得る。加えて、ＣＮ１０６は、他のサービスプロバイダによって所有および／または動作される他のワイヤードおよび／またはワイヤレスネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。

【0039】

ＷＴＲＵは図１Ａ～図１Ｄではワイヤレス端末として記載されているが、いくつかの代表的な実施形態では、そのような端末は、通信ネットワークとのワイヤード通信インターフェースを（たとえば、一時的または永続的に）使用し得ることが企図される。

【0040】

代表的な実施形態では、他のネットワーク１１２はＷＬＡＮであり得る。

【0041】

インフラストラクチャ基本サービスセット（ＢＳＳ）モードにおけるＷＬＡＮは、ＢＳＳのためのアクセスポイント（ＡＰ）と、ＡＰに関連付けられた１つまたは複数の局（ＳＴＡ）とを有し得る。ＡＰは、ＢＳＳ中におよび／またはそれからトラフィックを搬送する配信システム（ＤＳ）または別のタイプのワイヤード／ワイヤレスネットワークへのアクセスまたはインターフェースを有し得る。ＢＳＳの外部から発信した、ＳＴＡへのトラフィックは、ＡＰを介して到着することがあり、ＳＴＡに配信され得る。ＳＴＡから発信した、ＢＳＳ外の宛先へのトラフィックは、それぞれの宛先に配信されるべきＡＰに送られ得る。ＢＳＳ内のＳＴＡ間のトラフィックはＡＰを介して送られることがあり、たとえば、ソースＳＴＡがＡＰにトラフィックを送ることがあり、ＡＰが宛先ＳＴＡにトラフィックを配信することがある。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックと見なされるおよび／または呼ばれることがある。ピアツーピアトラフィックは、直接リンクセットアップ（ＤＬＳ）を用いてソースＳＴＡと宛先ＳＴＡとの間で（たとえば、それらの間で直接）送られ得る。いくつかの代表的な実施形態では、ＤＬＳは、８０２．１１ｅ ＤＬＳまたは８０２．１１ｚトンネルドＤＬＳ（ＴＤＬＳ）を使用し得る。独立ＢＳＳ（ＩＢＳＳ）モードを使用しているＷＬＡＮはＡＰを有しないことがあり、ＩＢＳＳ内にあるかまたはＩＢＳＳを使用しているＳＴＡ（たとえば、ＳＴＡのすべて）は互いに直接通信することがある。ＩＢＳＳ通信モードは、本明細書では「アドホック」通信モードと時々呼ばれることがある。

【0042】

８０２．１１ａｃインフラストラクチャ動作モードまたは同様の動作モードを使用しているとき、ＡＰは、１次チャネルなどの固定チャネル上でビーコンを送信し得る。１次チャネルは、固定幅（たとえば、２０ＭＨｚ幅の帯域幅）であるか、またはシグナリングを介した動的に設定される幅であり得る。１次チャネルは、ＢＳＳの動作チャネルであることがあり、ＡＰとの接続を確立するためにＳＴＡによって使用され得る。いくつかの代表的な実施形態では、たとえば８０２．１１システムでは、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）が実装され得る。ＣＳＭＡ／ＣＡのために、ＡＰを含むＳＴＡ（たとえば、あらゆるＳＴＡ）は、１次チャネルを検知し得る。特定のＳＴＡによって１次チャネルが検知／検出されおよび／またはビジーであると決定された場合、その特定のＳＴＡはバックオフし得る。所与のＢＳＳにおいて任意の所与の時間に１つのＳＴＡ（たとえば、ただ１つの局）が送信し得る。

【0043】

高スループット（ＨＴ）ＳＴＡは、たとえば、１次２０ＭＨｚチャネルを隣接するかまたは隣接しない２０ＭＨｚチャネルと組み合わせて４０ＭＨｚ幅チャネルを形成することを介して、通信のために４０ＭＨｚ幅チャネルを使用することがある。

【0044】

超高スループット（ＶＨＴ）ＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、および／または１６０ＭＨｚ幅チャネルをサポートし得る。４０ＭＨｚおよび／または８０ＭＨｚチャネルは、連続する２０ＭＨｚチャネルを組み合わせることによって形成され得る。１６０ＭＨｚチャネルは、８つの連続する２０ＭＨｚチャネルを組み合わせることによって、または２つの不連続の８０ＭＨｚチャネルを組み合わせることによって形成されることがあり、これは８０＋８０構成と呼ばれることがある。８０＋８０構成では、チャネル符号化の後のデータは、セグメントパーサを通過されることがあり、セグメントパーサはデータを２つのストリームに分割し得る。逆高速フーリエ変換（ＩＦＦＴ）処理、および時間領域処理が、各ストリーム上で別々に行われ得る。ストリームは、２つの８０ＭＨｚチャネル上にマッピングされることがあり、データは送信側ＳＴＡによって送信され得る。受信側ＳＴＡの受信機では、８０＋８０構成についての上記で説明された動作は反転されてよく、組み合わされたデータはメディアアクセス制御（ＭＡＣ）に送られ得る。

【0045】

８０２．１１ａｆおよび８０２．１１ａｈによってサブ１ＧＨｚ動作モードがサポートされる。チャネル動作帯域幅、およびキャリアは、８０２．１１ａｆおよび８０２．１１ａｈでは、８０２．１１ｎおよび８０２．１１ａｃにおいて使用されるものに対して低減される。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトルにおいて５ＭＨｚ、１０ＭＨｚおよび２０ＭＨｚ帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、および１６ＭＨｚ帯域幅をサポートする。代表的な実施形態によれば、８０２．１１ａｈは、マクロカバレージエリアにおけるＭＴＣデバイスなど、メータータイプ制御／マシンタイプ通信をサポートし得る。ＭＴＣデバイスは、いくつかの能力、たとえば、いくつかのおよび／または限られた帯域幅のサポート（たとえば、それのサポートのみ）を含む限られた能力を有することがある。ＭＴＣデバイスは、（たとえば、極めて長いバッテリー寿命を維持するために）しきい値を上回るバッテリー寿命をもつバッテリーを含むことがある。

【0046】

８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、および８０２．１１ａｈなど、複数のチャネル、およびチャネル帯域幅をサポートし得るＷＬＡＮシステムは、１次チャネルと称されることがあるチャネルを含む。１次チャネルは、ＢＳＳ中のすべてのＳＴＡによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有することがある。１次チャネルの帯域幅は、ＢＳＳ中で動作しているすべてのＳＴＡのうち、最小の帯域幅動作モードをサポートするＳＴＡによって設定および／または限定され得る。８０２．１１ａｈの例では、ＢＳＳ中のＡＰおよび他のＳＴＡが、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、および／または他のチャネル帯域幅動作モードをサポートする場合でも、１次チャネルは、１ＭＨｚモードをサポートする（たとえば、それのみをサポートする）ＳＴＡ（たとえば、ＭＴＣタイプデバイス）のために１ＭＨｚ幅であり得る。キャリア検知および／またはネットワーク割振りベクトル（ＮＡＶ）設定は、１次チャネルのステータスに依存することがある。たとえば、ＡＰに送信している（１ＭＨｚ動作モードのみをサポートする）ＳＴＡにより、１次チャネルがビジーである場合、利用可能な周波数帯域全体は、周波数帯域の大部分がアイドルなままで利用可能であり得ても、ビジーであると見なされることがある。

【0047】

米国では、８０２．１１ａｈによって使用され得る利用可能な周波数帯域は、９０２ＭＨｚから９２８ＭＨｚである。韓国では、利用可能な周波数帯域は９１７．５ＭＨｚから９２３．５ＭＨｚである。日本では、利用可能な周波数帯域は９１６．５ＭＨｚから９２７．５ＭＨｚである。８０２．１１ａｈのために利用可能な総帯域幅は、国コードに応じて６ＭＨｚから２６ＭＨｚである。

【0048】

図１Ｄは、実施形態によるＲＡＮ１１３およびＣＮ１１５を示すシステム図である。上述されたように、ＲＡＮ１１３は、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＮＲ無線技術を採用し得る。ＲＡＮ１１３はＣＮ１１５と通信していることもある。

【0049】

ＲＡＮ１１３はｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含み得るが、ＲＡＮ１１３は、実施形態に合致したままでありながら、任意の数のｇＮＢを含み得ることが諒解されよう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは各々、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバを含み得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃはＭＩＭＯ技術を実装し得る。たとえば、ｇＮＢ１８０ａ、１０８ｂは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに信号を送信しおよび／またはそれらから信号を受信するためにビームフォーミングを利用し得る。このようにして、たとえば、ｇＮＢ１８０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａにワイヤレス信号を送信し、および／またはそれからワイヤレス信号を受信し得る。実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃはキャリアアグリゲーション技術を実装し得る。たとえば、ｇＮＢ１８０ａは、ＷＴＲＵ１０２ａに複数のコンポーネントキャリアを送信し得る（図示されず）。これらのコンポーネントキャリアのサブセットは無認可スペクトル上にあり得るが、残りのコンポーネントキャリアは認可スペクトル上にあり得る。実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは協調マルチポイント（ＣｏＭＰ）技術を実装し得る。たとえば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａおよびｇＮＢ１８０ｂ（および／またはｇＮＢ１８０ｃ）から協調送信を受信し得る。

【0050】

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルな数秘学に関連付けられた送信を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。たとえば、ＯＦＤＭシンボル離間および／またはＯＦＤＭサブキャリア離間は、異なる送信、異なるセル、および／またはワイヤレス送信スペクトルの異なる部分について変動し得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（たとえば、変動する数のＯＦＤＭシンボルを含んでおりおよび／または変動する長さの絶対時間持続する）様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔（ＴＴＩ）を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。

【0051】

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成および／または非スタンドアロン構成でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成され得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（たとえばｅノードＢ１６０ａ、１６０ｂ、１６０ｃなどの）他のＲＡＮにアクセスすることもなしにｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、モビリティアンカーポイントとしてｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数を利用し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、無認可帯域中の信号を使用してｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。非スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮと通信／に接続しながらも、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信／に接続し得る。たとえば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＤＣ原理を実装して、１つまたは複数のｇＮＢ１８０ａ、１８０ｂ、１８０ｃおよび１つまたは複数のｅノードＢ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信し得る。非スタンドアロン構成では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのモビリティアンカーとして働くことがあり、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃをサービスするために追加のカバレージおよび／またはスループットを提供し得る。

【0052】

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示されず）に関連付けられることがあり、無線リソース管理判定、ハンドオーバ判定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアル接続性、ＮＲとＥ－ＵＴＲＡとの間のインターワーキング、ユーザプレーン機能（ＵＰＦ）１８４ａ、１８４ｂのほうへのユーザプレーンデータのルーティング、アクセスおよびモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂのほうへの制御プレーン情報のルーティングなどをハンドリングするように構成され得る。図１Ｄに示されているように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインターフェースを介して互いに通信し得る。

【0053】

図１Ｄに示されているＣＮ１１５は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂ、少なくとも１つのＵＰＦ１８４ａ、１８４ｂ、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂ、および場合によってはデータネットワーク（ＤＮ）１８５ａ、１８５ｂを含み得る。上記の要素の各々はＣＮ１１５の一部として示されているが、これらの要素のいずれも、ＣＮ事業者以外のエンティティによって所有および／または動作され得ることが諒解されよう。
ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インターフェースを介してＲＡＮ１１３中のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されることがあり、制御ノードとして働き得る。たとえば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ネットワークスライシングのサポート（たとえば、異なる要件をもつ異なるプロトコルデータユニット（ＰＤＵ）セッションのハンドリング）、特定のＳＭＦ１８３ａ、１８３ｂを選択すること、登録エリアの管理、非アクセス層（ＮＡＳ）シグナリングの終了、モビリティ管理などを担当し得る。ネットワークスライシングは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによりサービスのタイプが利用されていることに基づいてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用され得る。たとえば、超高信頼低レイテンシ通信（ＵＲＬＬＣ）アクセスに依拠するサービス、拡張モバイル（たとえば、大容量モバイル）ブロードバンド（ｅＭＢＢ）アクセスに依拠するサービス、マシンタイプ通信（ＭＴＣ）アクセスのためのサービスなど、異なる使用事例のために異なるネットワークスライスが確立され得る。ＡＭＦ１６２は、ＲＡＮ１１３と、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａプロ、および／またはＷｉＦｉなどの非３ＧＰＰアクセス技術などの他の無線技術を採用する他のＲＡＮ（図示されず）との間で切り替わるための制御プレーン機能を提供し得る。

【0054】

ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介してＣＮ１１５中のＡＭＦ１８２ａ、１８２ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂはまた、Ｎ４インターフェースを介してＣＮ１１５中のＵＰＦ１８４ａ、１８４ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択し、制御し、ＵＰＦ１８４ａ、１８４ｂを通してトラフィックのルーティングを構成し得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＥ／ＷＴＲＵ ＩＰアドレスを管理し割り振ること、ＰＤＵセッションを管理すること、ポリシー執行およびＱｏＳを制御すること、ダウンリンクデータ通知を提供することなど、他の機能を実施し得る。ＰＤＵセッションタイプは、ＩＰベース、非ＩＰベース、イーサネットベースなどであり得る。

【0055】

ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インターフェースを介してＲＡＮ１１３中のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されることがあり、それらは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を促進するために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。ＵＰＦ１８４ａ、１８４ｂは、パケットをルーティングしフォワーディングすること、ユーザプレーンポリシーを執行すること、マルチホームドＰＤＵセッションをサポートすること、ユーザプレーンＱｏＳをハンドリングすること、ダウンリンクパケットをバッファすること、モビリティアンカリングを提供することなど、他の機能を実施し得る。

【0056】

ＣＮ１１５は、他のネットワークと通信を促進し得る。たとえば、ＣＮ１１５は、ＣＮ１１５とＰＳＴＮ１０８との間のインターフェースとして働くＩＰゲートウェイ（たとえば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、またはそれと通信し得る。加えて、ＣＮ１１５は、他のサービスプロバイダによって所有および／または動作される他のワイヤードおよび／またはワイヤレスネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。一実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インターフェース、およびＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インターフェースを介して、ＵＰＦ１８４ａ、１８４ｂを通してローカルデータネットワーク（ＤＮ）１８５ａ、１８５ｂに接続され得る。

【0057】

図１Ａ～図１Ｄ、および図１Ａ～図１Ｄの対応する説明に鑑みて、ＷＴＲＵ１０２ａ～ｄ、基地局１１４ａ～ｂ、ｅノードＢ１６０ａ～ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ～ｃ、ＡＭＦ１８２ａ～ｂ、ＵＰＦ１８４ａ～ｂ、ＳＭＦ１８３ａ～ｂ、ＤＮ１８５ａ～ｂ、および／または本明細書で説明される任意の他のデバイスのうちの１つまたは複数に関して本明細書で説明される機能の１つもしくは複数、またはすべては、１つまたは複数のエミュレーションデバイス（図示されず）によって実施され得る。エミュレーションデバイスは、本明細書で説明される機能の１つもしくは複数、またはすべてをエミュレートするように構成された１つまたは複数のデバイスであり得る。たとえば、エミュレーションデバイスは、他のデバイスをテストするためにならびに／またはネットワークおよび／もしくはＷＴＲＵ機能をシミュレートするために使用され得る。

【0058】

エミュレーションデバイスは、実験室環境においておよび／または事業者ネットワーク環境において他のデバイスの１つまたは複数のテストを実装するように設計され得る。たとえば、１つまたは複数のエミュレーションデバイスは、ワイヤードおよび／またはワイヤレス通信ネットワーク内で他のデバイスをテストするためにその通信ネットワークの一部として完全にまたは部分的に実装および／または展開されながら、１つもしくは複数の、またはすべての機能を実施し得る。１つまたは複数のエミュレーションデバイスは、ワイヤードおよび／またはワイヤレス通信ネットワークの一部として一時的に実装／展開されながら、１つもしくは複数の、またはすべての機能を実施し得る。エミュレーションデバイスは、テストの目的で別のデバイスに直接結合されることがあり、および／またはオーバージエアワイヤレス通信を使用してテストを実施することがある。

【0059】

１つまたは複数のエミュレーションデバイスは、ワイヤードおよび／またはワイヤレス通信ネットワークの一部として実装／展開されないままで、すべてを含む１つまたは複数の機能を実施し得る。たとえば、エミュレーションデバイスは、１つまたは複数のコンポーネントのテストを実装するために、テスト実験室ならびに／または展開されない（たとえば、テスト用）ワイヤードおよび／もしくはワイヤレス通信ネットワークにおけるテストシナリオにおいて利用され得る。１つまたは複数のエミュレーションデバイスはテスト機器であり得る。（たとえば、１つまたは複数のアンテナを含み得る）ＲＦ回路を介した直接ＲＦ結合および／またはワイヤレス通信が、データを送信および／または受信するためにエミュレーションデバイスによって使用され得る。

【0060】

新無線（ＮＲ）システムは、２０２０年に展開されることが予想され、ｅＭＢＢサービスタイプとＵＲＬＬＣサービスタイプの両方を含むことになっている。これらのシステムは、１０^-5のＢＬＥＲターゲットおよび１．０ｍｓのレイテンシをもつＵＲＬＬＣ使用事例をサポートするはずである。３ＧＰＰ（登録商標）は、最高１０^-6のＢＬＥＲターゲットおよび０．５ｍｓのレイテンシをもつｅＵＲＬＬＣを研究し始めている。

【0061】

データ送信（最高１０^-6のＢＬＥＲ）および／または短いレイテンシ（０．５ｍｓ程度）に対する要件は、ダウンリンクおよび／またはアップリンクの両方における制御シグナリングの信頼性要件に影響を及ぼすことができる。信頼性が低いアップリンク制御情報メッセージを有することは、ダウンリンクおよび／またはアップリンクデータ送信の信頼性に影響を及ぼし得る。たとえば、信頼できないＨＡＲＱ－ＡＣＫフィードバックは、ＮＡＣＫ対ＡＣＫまたはＮＡＣＫ／ＡＣＫ消失検出の高い確率を生じ得る。ＮＲ Ｒｅｌ－１５制御シグナリングは、ｅＭＢＢトラフィックタイプとＵＲＬＬＣトラフィックタイプの両方をサポートするために設計された。ＷＴＲＵ１０２は、同じ制御メッセージ中の内で、異なるレイテンシおよび信頼性要件を有する異なるサービス（たとえば、特にｅＵＲＬＬＣ、ＵＲＬＬＣ、ｅＭＢＢおよび／または大容量マシンタイプ通信（ｍＭＴＣ）などのサービス）の制御シグナリングを多重化し得、このことは、送信（たとえば、ｅＵＲＬＬＣ送信）のレイテンシおよび／または信頼性に影響を及ぼし得る。たとえばロングフォーマットＰＵＣＣＨにおいて、たとえば、ＵＲＬＬＣのＨＡＲＱフィードバックをｅＭＢＢ ＨＡＲＱフィードバックと多重化することは、レイテンシの増加を生じることがあり（たとえば、２つのシンボルにわたってＰＵＣＣＨ中で低レイテンシ関係のＨＡＲＱフィードバックを送る代わりに、それは、シンボルのより大きいセット（たとえば、１４個のシンボル）にわたってＰＵＣＣＨ上で送られ得）、このことは、０．５ｍｓレイテンシ要件を満たすことを困難にし得る。

【0062】

いくつかの代表的な実施形態では、装置、方法、手順および／または動作は、異なるサービスタイプをサポートするＷＴＲＵ１０２に、サービスタイプごとに制御シグナリングを分離すべきことおよび／またはどのように分離すべきかを示すように実装され得る。サービスタイプは、たとえば、特に、レイテンシ、信頼性、および／または優先度を含む、所与の送信の要件を概して指す。

【0063】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、サービスタイプに基づいて制御シグナリングを解釈し得る。

【0064】

いくつかの代表的な実施形態では、装置、方法、手順および／または動作は、いつおよびどのように制御シグナリングを解釈すべきかをＷＴＲＵ１０２によって決定するように実装され得る。たとえば、ＷＴＲＵ１０２は、制御チャネル構成に基づいてダウンリンク制御情報ビットフィールドを解釈するように構成され得る。制御チャネル構成は、特に、（１）（たとえば、スロット内の）探索空間監視パターン、（２）探索空間周期性、および／または（３）探索空間持続時間を含み得る。

【0065】

制御チャネル構成の使用に加えてまたはその代わりに、ＷＴＲＵ１０２は、ＤＣＩビットフィールドの別のセットまたは他のセットの１つまたは複数の値に基づいて、ダウンリンク制御情報（ＤＣＩ）ビットフィールドのセットを解釈するように構成され得る。

【0066】

図２は、ＵＲＬＬＣ／ｅＵＲＬＬＣサービスおよびｅＭＢＢサービスのための制御シグナリングを搬送するために使用される時間周波数リソースを示す図である。図２を参照すると、複数の時間周波数リソース２００－１、２００－２…２００－Ｎは、複数のサービスのための制御シグナリング（たとえば、特に、ｅＭＢＢのための制御ＤＣＩスケジューリング２１０、ＵＲＬＬＣサービス／ｅＵＲＬＬＣサービスのためのＤＣＩスケジューリング２２０、ｅＭＢＢのためのＰＤＳＣＨ２３０、ＵＲＬＬＣサービス／ｅＵＲＬＬＣサービスのためのＰＤＳＣＨ２４０およびＨＡＲＱ－ＡＣＫフィードバックを搬送するＰＵＣＣＨ２５０）を搬送し得る。時間周波数リソース２００は、ｅＭＢＢサービスのためのＤＣＩスケジューリング２１０とｅＵＲＬＬＣサービスのためのＤＣＩスケジューリング２２０とを別々に搬送し得、ｅＭＢＢサービスのためのＰＤＳＣＨ２３０とＵＲＬＬＣ／ｅＵＲＬＬＣサービスのためのＰＤＳＣＨ２４０とを別々に搬送し得る。ｅＭＢＢサービスのためのおよびＵＲＬＬＣ／ｅＵＲＬＬＣサービスのためのＨＡＲＱ－ＡＣＫフィードバック２５０は、一緒に多重化され、ＰＵＣＣＨを介して搬送され得る。いくつかの代表的な実施形態では、ｅＭＢＢサービスおよびｅＵＲＬＬＣサービスのためのＨＡＲＱ－ＡＣＫフィードバックは、ＰＵＣＣＨを介して別々に搬送され得る。

【0067】

図３および図４は、ｅＭＢＢサービスまたはＵＲＬＬＣ／ｅＵＲＬＬＣサービスのために使用されるビットフィールドの代表的なセット（たとえば、４つのビットフィールド）を示す図である。図３では、第１のサービスタイプ（たとえば、ＵＲＬＬＣ／ｅＵＲＬＬＣサービス）に関連付けられたビットフィールド（たとえば、ビットフィールド１～４）は、第２のサービスタイプ（たとえば、ｅＭＢＢサービス）に関連付けられた対応するビットフィールド（たとえば、ビットフィールド１～４）と同じサイズである。図４では、第１のサービスタイプ（たとえば、ＵＲＬＬＣ／ｅＵＲＬＬＣサービス）に関連付けられたビットフィールド（たとえば、ビットフィールド１～４）は、第２のサービスタイプ（たとえば、ｅＭＢＢサービス）に関連付けられた対応するビットフィールド（たとえば、ビットフィールド１～４）と同じサイズでない。

【0068】

図３および図４を参照すると、第１のサービスタイプ（たとえば、ＵＲＬＬＣ／ｅＵＲＬＬＣサービスタイプ）がＷＴＲＵ１０２によって決定されたとき、ビットフィールド１は第１の様式で解釈され得、第２のサービスタイプ（たとえば、ｅＭＢＢサービスタイプ）がＷＴＲＵ１０２によって決定されたとき、ビットフィールド１は第２の様式で解釈され得る。ビットフィールド２～４は、第１のサービスタイプと第２のサービスタイプの両方について同じ様式で解釈され得る。たとえば、ＷＴＲＵ１０２は、スケジュールされているサービスタイプに応じて別様に制御情報ビットフィールドを解釈するように構成され得る。別様にＤＣＩビットフィールドを解釈することは、ビットフィールドの同じ値について、ＷＴＲＵ１０２が別様に制御情報を解釈し得ることを意味し得る。たとえば、ＨＡＲＱタイミングビットフィールドの「０００」値は、第１のサービスタイプのための（たとえば、ＵＲＬＬＣ／ｅＵＲＬＬＣサービスタイプ）のための第１の時間値ｔ１を示し、第２のサービスタイプ（たとえば、ｅＭＢＢサービスタイプ）のための第２の時間値ｔ２を示し得る。ＷＴＲＵ１０２は、ＤＣＩ内の１つのビットフィールド、ビットフィールドのサブセット（たとえば、たとえば図３および図４のビットフィールド１によって示されているビットフィールドのサブセットのみ）、またはビットフィールドのすべてを別様に解釈するように構成され得る。図３および図４に示されているように、ビットフィールド１（たとえば、ビットフィールド１のみ）は、別様に解釈されることになっている。たとえば、いつおよび／またはどのようにＷＴＲＵ１０２がサービスタイプに基づいて制御シグナリングを解釈し得るかが、本明細書で開示される。

【0069】

図３および図４では、ビットフィールド１のみが、異なるサービスタイプのために別様に解釈されるものとして示されているが、任意の数のビットフィールドが、異なるサービスタイプのために別様に解釈され得る。

【0070】

ビットフィールド１が、異なるサービスタイプのために別様に解釈されるものとして示されているが、任意のビットフィールド（ビットフィールド１または任意の他のビットフィールド）が、異なるサービスタイプのために別様に解釈され得る。

【0071】

制御シグナリングフィールドの異なる解釈のための代表的なトリガ
いくつかの代表的な実施形態では、ダウンリンクおよび／またはアップリンク制御解釈は、制御チャネル構成に基づき得る。

【0072】

いくつかの実施形態では、ＷＴＲＵ１０２は、異なるサービスタイプについてダウンリンク制御シグナリングを監視するために１つのＤＣＩサイズを用いて構成され得る（たとえば、ＷＴＲＵ１０２は、ＤＣＩが受信された制御チャネル構成に基づいてＤＣＩフィールドを決定／解釈するように構成され得る）。たとえば、図３および図４に示されているように、ＷＴＲＵ１０２は、様々なサービス（たとえば、２つのサービスｅＭＢＢおよびＵＲＬＬＣ）を監視するために１つのＤＣＩサイズを用いて構成されてよく、これらのサービス（たとえば、各サービス）は、異なるビットフィールド構成を有し得る。たとえば、ＷＴＲＵ１０２は、ＤＣＩが受信された制御チャネル構成に基づいてＤＣＩフィールドを解釈するように構成され得る。ＷＴＲＵ１０２は、別様に解釈されるべきフィールドのサブセットを用いて（たとえば、ネットワークシグナリングおよび／またはＲＲＣシグナリングを介して）半静的に事前構成／構成され得る。たとえば、ＷＴＲＵ１０２は、別様にＨＡＲＱ－ＡＣＫフィードバックタイミングフィールド（たとえば、ビットフィールド）を解釈する（たとえば、それのみを解釈する）ように事前構成されてよく、残りのフィールドは、どの制御チャネル構成が使用されているかにかかわらず、同じ解釈を有し得る。制御チャネル構成は、特に、以下のいずれかを含み得る。
（１）特に、以下のいずれかを含む、探索空間構成：
（ｉ）たとえばＷＴＲＵ１０２が、ＤＣＩ中のビットフィールドが別様に解釈されることが可能な周期性および／もしくはオフセットしきい値を用いて構成され得るような、監視周期性および／もしくはオフセット（たとえば、ＷＴＲＵ１０２が、しきい値以上の監視周期性をもつ探索空間を用いて構成された場合、ＷＴＲＵ１０２は、第１の様式でその探索空間内で受信されたＤＣＩフィールドを解釈し得るか、もしくはＷＴＲＵ１０２が、しきい値未満の監視周期性をもつ探索空間を用いて構成された場合、ＷＴＲＵ１０２は、第２の異なる様式でその探索空間内で受信されたＤＣＩフィールドを解釈し得る）、
（ｉｉ）たとえば、Ｋ個のスロットよりも短い持続時間をもつ探索空間内でＷＴＲＵ１０２によって受信されたＤＣＩが、Ｋ個のスロットよりも長い持続時間をもつ探索空間内で受信されたＤＣＩとは別様に解釈され得るような、探索空間持続時間、
（ｉｉｉ）たとえば、あらゆるシンボルのパターンを用いて構成された探索空間内でＷＴＲＵ１０２によって受信されたＤＣＩが、別様に解釈され得るような、スロット内の監視パターン（たとえば、ＷＴＲＵ１０２は、パターンのセットを用いて構成されることがあり、それらのパターンの１つもしくはセットを用いて構成された探索空間内で受信されたＤＣＩは、それらのパターンの１つもしくはセットを用いて構成されない探索空間内で受信されたＤＣＩとは別様に解釈され得る）、
（ｉｖ）探索空間インデックス（たとえば、ＷＴＲＵ１０２は、探索空間インデックスを用いて構成されることがあり、この探索空間インデックスに対応するこの探索空間上でＷＴＲＵ１０２によって受信された１つもしくは複数のＤＣＩは、別様に解釈され得る）、および／または
（ｖ）２つ以上の探索空間に属するＰＤＣＣＨ候補が正常に復号された場合、ＷＴＲＵ１０２は、探索空間（たとえば、各探索空間）のために上位レイヤによって構成された優先度インデックスに基づいて探索空間を決定し得るか、および／または１つもしくは複数の探索空間（たとえば、最も低い周期性をもつ探索空間）に関連する別のパラメータに基づいて決定され得る、
（２）特に、以下のいずれかを含む、ＣＯＲＥＳＥＴ構成：
（ｉ）ＣＯＲＥＳＥＴの持続時間（たとえば、ＣＯＲＥＳＥＴのシンボル（たとえば、連続するシンボル）の数）、および／または
（ｉｉ）制御リソースセットインデックス、
（３）サイクリック冗長検査（ＣＲＣ）をスクランブルするために使用されるＲＮＴＩ、
（４）ＣＲＣ長さ、たとえば構成は、たとえば場合によってはｅＭＢＢサービスタイプのために１６ビットＣＲＣを含むか、もしくは場合によってはＵＲＬＬＣサービスタイプのために２４ビットＣＲＣを含み得る、ならびに／または
（５）帯域幅パート（ＢＷＰ）構成。

【0073】

いくつかのＤＣＩ値に基づくダウンリンク／アップリンク制御解釈のための代表的な手順
いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、ＤＣＩフィールドのセットを、１つまたは複数の他のＤＣＩフィールドの値に応じて別様に解釈するように構成され得る。たとえば、ＷＴＲＵ１０２は、１つまたは複数の他のＤＣＩフィールド（たとえば、特定のＤＣＩフィールド中の１つまたは複数のビット値）に基づいて、別様に解釈されるべきＤＣＩの１つのフィールド（たとえば、ビットフィールド）、ＤＣＩのフィールドのサブセット、またはＤＣＩのすべてのフィールドを用いて構成され得る。ＷＴＲＵ１０２は、所与のビットフィールド値（たとえば、ＰＤＳＣＨ時間領域割振り）を用いて構成されることが可能であり、この値を復号すると、ＷＴＲＵ１０２は、別様にビットフィールドのセットを解釈するようにトリガされる。たとえば、しきい値を下回るかまたは値の範囲内にあるＰＤＳＣＨ時間領域値は、特定のサービスタイプを示すものとしてＷＴＲＵ１０２によって解釈され得、および／または特定の様式で（たとえば特定のサービスタイプに関連付けられた様式で）１つもしくは複数の他のＤＣＩフィールドを解釈するためのインジケーションとして使用され得る。

【0074】

ＤＣＩにおける代表的な送信プロファイル（ＴＰ）
いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、１つまたは複数のＴＰを用いて構成され得る。たとえば、第１のＴＰ値は、第１の（たとえば、ｅＭＢＢ）サービスタイプを示すことがあり、第２のＴＰ値は、第２の（たとえば、ＵＲＬＬＣ）サービスタイプを示すことがある。そのような場合、ＷＴＲＵ１０２は、ＤＣＩを受信し得、ＤＣＩのための対応するＴＰを決定し得る。ＷＴＲＵ１０２は、ＤＣＩのためのＴＰの決定された値に従って（たとえば、第１の特定のＴＰ値のための第１の値または値のセット、および第２の特定のＴＰ値のための第２の値または値のセットを使用して）ＤＣＩの１つまたは複数のフィールドを解釈し得る。

【0075】

（たとえば、ｅＮＢブラインド復号を必要としおよび／または使用し得る）ＤＣＩに対応するトランスポートブロック（ＴＢ）のための代表的な論理チャネル優先度付け（ＬＣＰ）
いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、１つまたは複数の論理チャネル（ＬＣＨ）を用いて構成され得る。たとえば、第１のＬＣＨは、第１の（たとえば、ｅＭＢＢ）サービスタイプに対応するデータに関連することがあり、および／または第２のＬＣＨは、第２の（たとえば、ＵＲＬＬＣ）サービスタイプを示すことがある。ＷＴＲＵ１０２は、対応する送信中に含めるべきデータに応じてＤＣＩのコンテンツの少なくともいくつかをどのように解釈すべきかを決定し得る。たとえば、ＷＴＲＵ１０２は、ＤＣＩに関連付けられた送信のためのトランスポートブロック（ＴＢ）サイズ（ＴＢＳ）を決定し得る。ＷＴＲＵ１０２は、（たとえば、論理チャネル優先度付け（ＬＣＰ）機能に基づいて）ＴＢのために何のＬＣＨをサービスすべきかを決定し得る。ＷＴＲＵ１０２は、関心があるＬＣＨに関連付けられたサービスタイプを決定し得る。ＷＴＲＵ１０２は、関心があるＬＣＨに関連付けられた決定されたサービスタイプに従って（たとえば、第１のサービスタイプのために構成された第１の特定のＬＣＨのための第１の値もしくは値のセットを使用して、または第２のサービスタイプのために構成された第２の特定のＬＣＨのための第２の値もしくは値のセットを使用して）、ＤＣＩの１つまたは複数のフィールドを解釈し得る。

【0076】

当業者であれば、ＬＣＨに関して本明細書で開示される手順／動作が、ＬＣＨの代わりにまたはＬＣＨに加えて、論理チャネルグループ（ＬＣＧ）に適用され得ることを理解する。同様の手順／動作は、ＬＣＰのために、マッピング制限またはＴＰの異なるセットを使用して適用され得る。そのような場合、ＷＴＲＵ１０２は、ＤＣＩが、新規の送信をスケジュールすると決定し得、たとえば、ＤＣＩが、新規データインジケータフィールド（ＮＤＩ）をトグルすると決定し得る。ＷＴＲＵ１０２は、ＨＡＲＱ ＰＩＤの解釈が、第１のＬＣＨのための第１のＰＩＤ空間に、または第２のＬＣＨのための第２のＰＩＤ空間に対応すると決定し得る（たとえば、ＨＡＲＱ処理の異なるセットが、ＤＣＩの解釈に応じて示され得る）。そのような送信の適切な受信は、ネットワークノード（たとえば、特に、ｅＮＢ、またはｇＮＢ）においてブラインド復号を必要としおよび／または使用し得る。

【0077】

ＤＣＩにおける代表的なＨＡＲＱ処理識別情報（ＰＩＤ）
いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、１つまたは複数のＨＡＲＱ処理識別情報（ＰＩＤ）空間を用いて構成され得る。たとえば、第１のＰＩＤ値は、第１の（たとえば、ｅＭＢＢ）サービスタイプを示すことがあり、および／または第２のＰＩＤ値は、第２の（たとえば、ＵＲＬＬＣ）サービスタイプを示すことがある。そのような場合、ＷＴＲＵ１０２は、ＨＡＲＱ送信のためのＤＣＩを受信し得、ＤＣＩの対応するＨＡＲＱ ＰＩＤを決定し得る。ＷＴＲＵ１０２は、ＨＡＲＱ ＰＩＤの決定された値に従って（たとえば、第１の特定のＨＡＲＱ ＰＩＤ値（および／または対応する第１の値範囲）のための第１の値または値のセット、ならびに第２の特定のＨＡＲＱ ＰＩＤ値（および／または対応する第２の値範囲）のための第２の値または値のセットを使用して）、ＤＣＩの１つまたは複数のフィールドを解釈し得る。

【0078】

ＤＣＩ中の明示的インジケーションに基づくダウンリンク／アップリンク制御解釈のための代表的な手順
いくつかの実施形態では、ＷＴＲＵ１０２は、ＤＣＩ中のビットの値に応じて別様にＤＣＩフィールドのセットを解釈するように構成され得る。たとえば、ＷＴＲＵ１０２は、ＤＣＩ中の「セット」インジケーションを使用して、ＰＵＣＣＨリソースセットからのＨＡＲＱ Ａ／ＮフィードバックのためのＰＵＣＣＨリソースを決定するように構成されることが可能である。一例では、ＷＴＲＵ１０２は、ｅＭＢＢおよびＵＲＬＬＣ／ｅＵＲＬＬＣデータ送信を同時に受信するように構成され得る。ＷＴＲＵ１０２は、サービスタイプ（たとえば、ＵＲＬＬＣ／ｅＵＲＬＬＣ、ｅＭＢＢおよび／またはｍＭＴＣ）にそれぞれ対応する少なくとも２つのＰＵＣＣＨリソースセットを用いて構成され得る。ＷＴＲＵ１０２は、セットインジケーションに基づいて、肯定応答（たとえば、ＰＵＣＣＨ）リソースインジケータ（ＡＲＩ）ビットフィールドがそれを指しているＰＵＣＣＨリソースセットを決定し得る。

【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】

複数のＰＵＳＣＨ送信を使用するリソース選択のための代表的な手順
ＷＴＲＵ１０２は、スロット（たとえば、同じスロット）中でおよび／または時間領域において重複して２つ以上のＰＵＳＣＨ送信を送信するように構成されてよく、ＰＵＳＣＨ送信は、異なるサービングセルおよび／または異なるキャリア上にあってよい（たとえば、各ＰＵＳＣＨ送信が、異なるサービングセルおよび／または異なるキャリア上にあってよい）。ＰＵＳＣＨ送信は、異なるサービス関係の優先度を有し得る（たとえば、各ＰＵＳＣＨ送信が、異なるサービス関係の優先度を有し得る）。たとえば、ＷＴＲＵ１０２は、キャリア（たとえば、１つのキャリア）上で低優先度のＰＵＳＣＨを送信していることがある。新しいより高優先度のＳＲまたはＵＣＩがトリガされ得る一方で、たとえばＷＴＲＵ１０２がキャリア上で低優先度ＰＵＳＣＨを送信していることがある。キャリアは、時間領域において重複し得る異なるキャリア上のＰＵＣＣＨリソースにマッピングし得る。いくつかの例では、ＷＴＲＵ１０２が、１つのキャリア上で低優先度ＵＣＩおよび／またはＳＲを送信していることがある一方で、異なるキャリア上で送信されるように構成および／またはスケジュールされ得る新しい高優先度データが到着し得る。ＷＴＲＵ１０２は、異なる優先度のデータトラフィックを潜在的に搬送し得る、異なるキャリア上のＰＵＳＣＨリソースを用いて構成および／またはスケジュールされ得る。

【0147】

ＷＴＲＵ１０２は、以下の基準のいずれかに基づいて、ＵＣＩを多重化するための少なくとも１つのＰＵＳＣＨを選択し得る。
（１）ＰＵＳＣＨ送信がＵＣＩおよびデータの組合せの送信のために好適であるかどうか、
（２）ＰＵＳＣＨおよびＵＣＩに関連付けられた１つもしくは複数のサービスレベル優先度、ならびに／または
（３）既存のシステム（たとえば、たとえばセクション９を含むＴＳ ３８．２１３ ｖ１５．６．０に指定されている、ＮＲリリース１５）において使用されるＰＵＳＣＨ送信の選択のために使用される何らかの基準、たとえば、特に、ＰＵＳＣＨがＤＣＩによってスケジュールされるかどうか、非周期的ＣＳＩがＰＵＳＣＨにおいて多重化されるべきかどうか、ＰＵＳＣＨのサービングセルインデックス、および／もしくは処理時間に関係するタイムライン条件が満たされるかどうか）。

【0148】

ＷＴＲＵ１０２は、ＰＵＳＣＨ送信のサブセットを、所与のタイプおよび／または優先度のＵＣＩを多重化するための候補ＰＵＳＣＨ送信として決定し得る。ＷＴＲＵ１０２は、次いで、候補ＰＵＳＣＨ送信のサブセットを決定し得る。候補ＰＵＳＣＨ送信のサブセットは、ＵＣＩおよびデータの組合せの送信のために好適であるとＷＴＲＵ１０２によって決定される。この決定は、本明細書で開示される１つまたは複数の例に基づいて実施されてよい。ＷＴＲＵ１０２は、たとえば既存のシステムのために指定された、１つまたは複数のルールに基づいて、サブセットの中からＰＵＳＣＨを選択し得る。たとえば、ＷＴＲＵ１０２は、サブセット内の最も小さいサービングセルインデックスをもつＰＵＳＣＨを選択し得る。候補ＰＵＳＣＨ送信内に好適なＰＵＳＣＨ送信がない場合、ＷＴＲＵ１０２は、（たとえば、本明細書で開示される例のうちの１つまたは複数に従って）優先リソースを決定し得る。たとえば、優先リソースがＰＵＣＣＨ送信および／または同時ＰＵＣＣＨであり、ＰＵＳＣＨ送信がサービングセル内でまたはセルグループ内で可能にされない場合、ＷＴＲＵ１０２は、同じサービングセル中のまたはセルグループのすべてのサービングセル中の１つまたは複数のＰＵＳＣＨ送信をドロップし得る。

【0149】

所与のタイプおよび／または優先度のＵＣＩのための候補ＰＵＳＣＨ送信のサブセットは、特に以下のいずれかを含むか、それからなるか、またはそれから決定され得る。（１）ＷＴＲＵ１０２がその上で送信するように構成されたＰＵＳＣＨ送信のセット（たとえば、全セット）、（２）ＵＣＩと同じサービス関係の優先度のＰＵＳＣＨ送信のサブセット、およびたとえば周期的ＣＳＩの場合、サービス関係の優先度は、最も低い優先度など、特定の優先度に対応するように構成もしくは定義され得る、（３）ＰＵＳＣＨ送信のセット（たとえば、全セット）の中の最も高いサービス関係の優先度のＰＵＳＣＨ送信のサブセット、（４）半永続的ＰＵＳＣＨについてのおよび／もしくは非周期的ＣＳＩがそれについて要求された、動的許可、構成された許可によってスケジュールされたＰＵＳＣＨ送信のサブセット、ならびに／または（５）既存のシステム（リリース１５）においてＰＵＳＣＨの選択のために使用されるルールに従って決定されたＰＵＳＣＨ送信（たとえば、ＰＵＳＣＨ送信のみ）。

【0150】

２つ以上のタイプおよび／または優先度のＵＣＩについて衝突が発生する場合、候補ＰＵＳＣＨ送信のサブセットは、ＵＣＩごとに異なってよく、および／または各ＵＣＩは、異なるＰＵＳＣＨ上で多重化され得る。たとえば、ＷＴＲＵ１０２は、第１の優先度のＰＵＳＣＨにおいて第１の優先度のＨＡＲＱ－ＡＣＫを多重化してよく、第２の優先度のＰＵＳＣＨにおいて第２の優先度のＨＡＲＱ－ＡＣＫを多重化してよい。いくつかの代表的な実施形態では、ＵＣＩの多重化は、単一のＰＵＳＣＨにおいてのみ可能にされ得る。この場合、任意のＵＣＩについて、候補ＰＵＳＣＨのサブセットは、最も優先度の高いＵＣＩに適用可能なものとして決定され得る。

【0151】

たとえば、シナリオにおいて、ＷＴＲＵ１０２は、所与のスロット中で、第１のサービングセル中の（たとえば、ＵＲＬＬＣサービスに関連付けられた）第１の優先度の第１のＰＵＳＣＨ、第２のサービングセル中の（たとえばｅＭＢＢサービスに関連付けられた）第２の優先度の第２のＰＵＳＣＨ、および第３のサービングセル中の（たとえば、ｅＭＢＢサービスに関連付けられた）第２の優先度の第３のＰＵＳＣＨを送信し得る。ＷＴＲＵ１０２が、同じスロット中のＰＵＣＣＨにおいて（たとえば、ｅＭＢＢサービスに関連付けられた）第２の優先度のＨＡＲＱ－ＡＣＫを送信しているであろうかまたは送信しているべきである場合、ＷＴＲＵ１０２は、第２のＰＵＳＣＨにおいて第２の優先度のＨＡＲＱ－ＡＣＫを多重化し得る。ＷＴＲＵ１０２が、さらに、同じスロット中のＰＵＣＣＨにおいて第１の優先度のＨＡＲＱ－ＡＣＫを送信しているであろうかまたは送信しているべきである場合、ＷＴＲＵ１０２は、第１のＰＵＳＣＨにおいて第１の優先度のＨＡＲＱ－ＡＣＫを多重化し得る。上記のシナリオでは、ＷＴＲＵ１０２は、同じスロット中で異なるＰＵＳＣＨ送信における異なる優先度のＵＣＩを多重化し得る。

【0152】

所与のタイプおよび／または優先度のＵＣＩのための候補ＰＵＳＣＨ送信のサブセットが、基準の１つのセットに従って空である場合、ＷＴＲＵ１０２は、基準の第２の（たとえば、あまり制限的でない）セットにフォールバックし得る。たとえば、所与のサービス関係の優先度のＵＣＩについて、候補ＰＵＳＣＨ送信のサブセットは、同じサービス関係の優先度のＰＵＳＣＨ送信が少なくとも１つある場合、そのようなＰＵＳＣＨ送信に対応し得、そうでない場合、ＰＵＳＣＨ送信のセット（たとえば、全セット）に対応し得る。

【0153】

いくつかのシナリオでは、ＷＴＲＵ１０２は、ＰＵＳＣＨとＰＵＣＣＨを同時に送信することが可能でないことがあるか、またはＷＴＲＵ１０２は、より高優先度の送信のための信頼性要件を満たしながら、（１）ＰＵＳＣＨとＰＵＣＣＨを同時に、（２）ＰＵＳＣＨとＰＵＳＣＨを同時に、もしくは（３）ＰＵＣＣＨとＰＵＣＣＨを同時に送信することが可能でないことがある。ＷＴＲＵ１０２は、低優先度の送信をドロップし得、高優先度の送信を送信し得る。ＷＴＲＵ１０２は、より高優先度の送信と時間的に重複している部分上で、低優先度の送信をパンクチャし得る。ＷＴＲＵ１０２は、高優先度の送信について信頼性および／またはレイテンシメトリックが満たされる場合、ＰＵＳＣＨ送信上でＳＲまたはＵＣＩを多重化し得る。別の例では、重複する送信が開始していない場合、ＷＴＲＵ１０２は、異なる送信電力および／または電力制御パラメータを適用し得る。いくつかの例では、ＷＴＲＵ１０２は、最初に、より高優先度の送信に電力を割り振り、それの後に、低優先度の重複する送信に（ＷＴＲＵ１０２の電力ヘッドルームに従っておよび／または基づいて考慮して）何らかの電力を割り振り得る。他の例では、ＷＴＲＵ１０２は、電力制御パラメータの２つのセットを用いて上位レイヤによって構成されてよく、ＷＴＲＵ１０２は、ＰＵＣＣＨ送信またはＰＵＳＣＨ送信が別のＰＵＳＣＨ送信または別のＰＵＣＣＨ送信と重複するとき（たとえば、そのときのみ）、ＰＵＣＣＨ送信またはＰＵＳＣＨ送信のために電力制御パラメータの特定のセットを選択し得る。

【0154】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、所与のキャリア上の送信のために生成されたトランスポートブロック（ＴＢ）が、異なるキャリア上のより高優先度の送信と重複する場合、ＴＢをドロップし得る。ＷＴＲＵ１０２は、たとえばリソースのサブセットが、異なるキャリア上のより高優先度のデータの送信に適用可能な別のリソースと重複する場合、リソースのサブセットを非アクティブとして決定、設定、および／もしくは考慮し、ならびに／またはそのようなリソースに適用可能なＰＤＵを生成しないことがある。いくつかの例では、ＷＴＲＵ１０２は、時間領域において重複し得る異なるキャリア上で、２つ以上の構成された許可を用いて構成され得る。たとえば、第１の構成された許可ＣＧ１は、すべての優先度のデータを搬送することがあり、第２の構成された許可ＣＧ２は、より低優先度からのデータ（たとえば、データのみ）を搬送することがある。ＷＴＲＵ１０２が高優先度および低優先度のデータをバッファしたとき、たとえば第２の構成された許可ＣＧ２が、第１の構成された許可ＣＧ１に関連付けられたＣＧオケージョンと時間領域において重複する場合、ＷＴＲＵ１０２は、第１の構成された許可ＣＧ１（たとえば、第１の構成された許可ＣＧ１のみ）上で低優先度ＬＣＨおよび高優先度ＬＣＨからのデータを多重化することがあり、第２の構成された許可ＣＧ２のためのＴＢを生成しないことがある。

【0155】

非優先リソースのハンドリングのための代表的な手順
少なくとも１つの衝突するリソースについて、ＷＴＲＵ１０２は、重複が時間領域（たとえば、時間領域のみ）中にあるかまたは時間領域と周波数領域の両方中にあり得るように、優先リソースと重複していない少なくとも１つの部分を介して送信し得る。たとえば、第１のリソースは、１４個のシンボルの持続時間をもつＰＵＳＣＨ送信リソースであり得、第２の（たとえば、優先）リソースは、第１のリソースの第３および第４のシンボルと重複する、２つのシンボルの持続時間をもつＰＵＣＣＨ送信であり得る。ＷＴＲＵ１０２は、第１のリソースの２つの第１のシンボルを送信し、第１のリソースの第３および第４のシンボルをスキップして、第２のリソースを送信し、次いで、第５のシンボルからの第１のリソースを送信し得る。

【0156】

第１のリソースの少なくとも１つの部分が、第２の（たとえば、優先）リソースと重複するとき、ＷＴＲＵ１０２は、以下の条件のいずれかに基づいて、少なくとも残りの非重複部分上で、第１のリソース上で送信すべきかどうかを決定し得る。（１）コードブロックグループベースのＨＡＲＱが送信のために（たとえば、少なくともＰＵＳＣＨ送信のために）構成された場合、（２）１つもしくは複数のコードブロックおよび／または１つもしくは複数のコードブロックグループの少なくともある数（たとえば、１つ）が、非重複部分上にマッピングされた場合、（３）１つもしくは複数のコードブロックおよび／または１つもしくは複数のコードブロックグループの、多くともある数が、１つもしくは複数のスキップされた部分にわたってマッピングされた場合、（３）１つもしくは複数の非重複部分が、リソースのある小部分を上回る場合、（４）基準信号（たとえば、ＤＭ－ＲＳ）が非重複部分中に存在する場合、ならびに／または（５）第２の送信が、第１の送信上で多重化されることが可能である場合。

【0157】

多重化のための代表的な手順
いくつかの例では、ＷＴＲＵ１０２は、異なるサービスベースの優先度レベルに関連し得るＵＣＩおよび／またはデータを単一のリソースへと多重化し得る。たとえば、ＷＴＲＵ１０２は、異なるサービスベースの優先度レベルに関連するＨＡＲＱ－ＡＣＫおよび／またはＳＲおよび／またはデータを単一のＰＵＣＣＨまたは単一のＰＵＳＣＨへと多重化し得る。

【0158】

ＰＵＳＣＨ上でＵＣＩを多重化するとき、ＵＣＩのために利用可能なリソース要素のセットは、ＵＣＩに関連するサービスベースの優先度レベルに依存し得る。たとえば、ＨＡＲＱ－ＡＣＫおよび／またはＳＲのために利用可能なリソース要素の数は、いくつかの優先度レベルに関するＮ個の最後の時間シンボルでは、０であり得る。Ｎの値は、優先度レベルに適用可能なレイテンシ要件に依存し得る。たとえば、Ｎは、最後のＮ個のシンボルが、衝突がない場合にＨＡＲＱ－ＡＣＫおよび／またはＳＲを搬送し得るＰＵＣＣＨリソースと重複し得ないかまたは重複しないことになるようなものであり得る。

【0159】

ＷＴＲＵ１０２は、ＰＵＳＣＨまたはＰＵＣＣＨ上で、異なるサービスベースの優先度レベルに関連するＵＣＩおよび／またはデータを多重化し得る。いくつかの例では、ＷＴＲＵ１０２は、ＰＵＳＣＨまたはＰＵＣＣＨ上で多重化するより前に、異なる優先度レベルに関連するＵＣＩ（たとえば、ＨＡＲＱ－ＡＣＫおよび／またはＳＲ）を符号化（たとえば、ジョイント符号化）し得る。ＰＵＳＣＨの場合、ＷＴＲＵ１０２は、ジョイント符号化されるＵＣＩの中で最も高い優先度レベルのために構成されたパラメータ（α、β）のセットを使用することによって、ジョイント符号化されるＵＣＩのためのレイヤ（Ｑ’）ごとに、いくつかのコード化変調シンボルを決定し得る。

【0160】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、ＰＵＣＣＨまたはＰＵＳＣＨ上で多重化するより前に、異なる優先度レベルに関連するＵＣＩ（たとえば、ＨＡＲＱ－ＡＣＫ／ＳＲ）を符号化（たとえば、別々に符号化）し得る。ＰＵＳＣＨの場合、ＷＴＲＵ１０２は、優先度レベル（たとえば、各優先度レベル）に固有のパラメータ（α、β）を使用することによって、各優先度レベルのレイヤ（Ｑ’）ごとに、いくつかのコード化変調シンボルを決定し得る。ＷＴＲＵ１０２は、コード化変調シンボルを、ＰＵＳＣＨのリソース要素の異なるセットにマッピングし得る。

【0161】

異なる優先度レベルに関連するＵＣＩをＰＵＳＣＨ上のデータと多重化するとき、ＷＴＲＵ１０２は、利用可能なリソース要素の第１のセットを仮定すると、最初に、ＵＣＩおよびデータの第１のサブセットを符号化し、ＰＵＳＣＨ上で多重化してよく、ＵＣＩの第２のサブセットを符号化し、値を交換してよい（たとえば、ＵＣＩおよび／またはデータの第１のサブセットのために前に決定されたコード化ビットまたは被変調シンボルのサブセットをパンクチャまたは上書きしてよい）。代替として、多重化は「レートマッチング」によって実施されることが可能であり、ＷＴＲＵ１０２は、利用可能なリソース要素の第１のセットが、第２のサブセットの変調シンボルをマッピングするために必要とされるリソース要素の第２のセットによって低減されると仮定すると、第１のサブセットを符号化してよく、ここで、第２のサブセットのコード化ビットは、変調され、利用可能なリソース要素の第２のセット上にマッピングされ、第１のサブセットのコード化ビットを上書きしない。

【0162】

ジョイント符号化が採用されるか個別符号化が採用されるか、および／またはＵＣＩのサブセットの多重化がパンクチャリングによって実施されるかどうかは、（１）異なるＵＣＩに関連する優先度レベル、（２）異なるＵＣＩのビット数、（３）たとえばＰＤＣＣＨ送信またはＰＤＳＣＨ送信と、（たとえばＨＡＲＱ－ＡＣＫの場合に）ＨＡＲＱ－ＡＣＫが報告される対応するリソースとの間の時間差によって決定されるような利用可能な処理時間に依存し得る。

【0163】

たとえば、異なる優先度レベルのＨＡＲＱ－ＡＣＫは、ＨＡＲＱ－ＡＣＫビットの総数がしきい値を下回る場合、または少なくとも１つの優先度レベルのためのＨＡＲＱ－ＡＣＫビットの数がしきい値を下回る場合、ジョイント符号化され得る。

【0164】

たとえば、より高い優先度レベルに関連するＵＣＩ（たとえば、ＨＡＲＱ－ＡＣＫおよび／またはＳＲ）は、より低い優先度レベルに関連するＵＣＩおよび／またはデータをパンクチャすることによって多重化され得る。

【0165】

たとえば、ＰＵＳＣＨリソースの開始のＸ個未満のシンボル前に終了するＰＤＳＣＨ送信に関連するＨＡＲＱ－ＡＣＫは、より以前のＰＤＣＣＨ送信またはより以前のＰＤＳＣＨ送信に関連し得るＵＣＩおよび／またはデータをパンクチャすることによって多重化され得る。

【0166】

いくつかの例では、複数の優先度レベルに関連するＨＡＲＱ－ＡＣＫが、同じＰＵＣＣＨリソースまたは同じＰＵＳＣＨリソース上で多重化され得るとき、ＷＴＲＵ１０２は、対応する優先度レベルのためのＰＤＳＣＨ割当てが受信されなかった場合でも、少なくとも１つの優先度レベルのために最小でＭ個のＨＡＲＱ－ＡＣＫビットを符号化し得る。Ｍは、任意の正の整数に、たとえば２に設定され得る。この例は、最も高い優先度レベルに関連するＨＡＲＱ－ＡＣＫの復号が、より低優先度の送信のための単一または複数のＰＤＳＣＨ割当てを検出することの失敗のせいで失敗しないことを保証し得る。この例は、ＰＵＣＣＨリソースまたはＰＵＳＣＨリソースが、より低い優先度レベルに関連するＨＡＲＱ－ＡＣＫを搬送することを可能にされる場合に（たとえば、その場合にのみ）使用され得る。たとえば、ＰＵＳＣＨ送信が、より高い優先度レベルのＨＡＲＱ－ＡＣＫおよびより低い優先度レベルのＨＡＲＱ－ＡＣＫを多重化する（たとえば、潜在的に多重化する）ための条件を満たし、ＷＴＲＵ１０２が、より高い優先度レベルのためにはＮ１個のＨＡＲＱ－ＡＣＫビットが多重化されるべきであるかまたは多重化される必要があると決定したが、より低い優先度レベルのためにはＨＡＲＱ－ＡＣＫが多重化されるべきでないかまたは多重化される必要がないと決定した場合、ＷＴＲＵ１０２は、さらに、より低い優先度レベルのために０に設定されたＭ個のＨＡＲＱ－ＡＣＫビットを多重化し得る。

【0167】

いくつかの例では、ＳＲは、ＰＵＣＣＨまたはＰＵＳＣＨ上で他のＵＣＩおよび／またはデータと多重化され得る。ＳＲは、たとえばそれが同じ優先度レベルに関連する場合（たとえば、その場合のみ）、ＨＡＲＱ－ＡＣＫとジョイント符号化され得るか、または別のＵＣＩとは別々に符号化され得る。後者の場合、ＰＵＳＣＨ上で多重化されるとき、ＷＴＲＵ１０２は、ＳＲのために別々に構成されたパラメータ（α、β）を使用することによって、所与の優先度レベルにおいてＳＲのためにレイヤ（Ｑ’）ごとに、いくつかのコード化変調シンボルを決定し得る。いくつかの代表的な実施形態では、同じ優先度レベルにおけるＨＡＲＱ－ＡＣＫに関する同じパラメータが再利用され得る。

【0168】

ＳＲのビット数は、スケジューリング要求の数Ｋに基づいて決定されてよく、その対応するＰＵＣＣＨリソースは、多重化のために使用されるＰＵＣＣＨまたはＰＵＳＣＨと重複し得るかまたは重複することになる。たとえば、ＳＲがＰＵＳＣＨ上で多重化される場合、ＰＵＳＣＨよりも高い優先度レベルに関連するスケジューリング要求の数（たとえば、単に数）Ｋ’が含まれ得る。たとえば、ｌｏｇ２（ｋ＋１）またはｌｏｇ２（Ｋ’＋１）よりも大きい最小の整数に対応するビット数が含まれ得る。

【0169】

オーバーフローリソースの決定のための代表的な手順
図９は、オーバーフローリソースを使用する代表的な手順を示す図である。

【0170】

図９を参照すると、オーバーフローリソース手順９００は、ブロック９１０において、ＷＴＲＵ１０２が混合トラフィック可能として識別されることを含み得る。ブロック９２０において、ＷＴＲＵ１０２は、１次およびオーバーフローＵＣＩのための構成を受信し得る。ブロック９３０において、ＷＴＲＵ１０２は、ＵＣＩ衝突が識別される（たとえば、発生することになる）かどうかを決定し得る。ＵＣＩ衝突が発生することになる場合、ブロック９４０において、ＷＴＲＵ１０２は、１次ＰＵＣＣＨ上で高優先度（たとえば、第１の優先度または多重化された）トラフィックを送信し得る。ブロック９５０において、ＷＴＲＵ１０２は、オーバーフローＰＵＣＣＨ利用シグナリングを送信し得る。ブロック９６０において、ＷＴＲＵ１０２は、オーバーフローＰＵＣＣＨ上で低優先度ＵＣＩ（たとえば、第２の優先度、より低い優先度、および／または残りのＵＣＩ）を送信し得る。ＵＣＩ衝突が識別されない（たとえば、発生しないことになる）場合、ブロック９７０において、ＷＴＲＵ１０２は、５Ｇ ＮＲスタンドアロンおよび／または非スタンドアロンＰＵＣＣＨ（たとえば、３ＧＰＰリリース１５以降のＰＵＣＣＨ）上で送信し得る。

【0171】

たとえば、ＷＴＲＵ１０２は、２つ以上のＰＵＣＣＨリソースセット、たとえば１次リソースおよび１つまたは複数のオーバーフローまたは２次リソースを用いて構成され得る。ＷＴＲＵ１０２が選択するリソースセットの数は、ＷＴＲＵ１０２が送信する必要がある異なるサービスベースの優先度レベルをもつ数ＵＣＩに関連付けられ得る。レイテンシに基づくサービスベースの優先度では、１次リソースは、２次リソースよりも早く開始し、より短くなり得ることが企図される。

【0172】

一例では、１次リソースおよびオーバーフローリソースは、時間または周波数のいずれにおいても重複のない、別個の時間および周波数リソースにあり得る。

【0173】

一例では、１次リソースおよびオーバーフローリソースは、時間（たとえば、時間のみ）においてまたは周波数（周波数のみ）において別個であり得る（たとえば、１次リソースおよびオーバーフローリソースは、時間において別個であるが周波数においては別個でないか、または周波数において別個であるが時間においては別個でないことがある）。

【0174】

一例では、ＷＴＲＵ１０２は、１つまたは複数の専用オーバーフローリソースを用いて、静的、半静的および／または動的に構成され得る。いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、１つまたは複数の共通オーバーフローリソースを用いて、静的、半静的および／または動的に構成され得る（たとえば、複数のＷＴＲＵ１０２が、同じ１つまたは複数のオーバーフローリソースを用いて構成され得る）。いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、専用オーバーフローリソースおよび共通オーバーフローリソースの混合を用いて、静的、半静的および／または動的に構成され得る。

【0175】

一例では、ＷＴＲＵ１０２は、１次リソースのリソース割振りから、オーバーフローリソースのタイミングおよび／またはリソース割振りを決定し得る。ＷＴＲＵ１０２は、条件付きで、１次リソースが、ＷＴＲＵ内またはＷＴＲＵ間優先度付けによりドロップ、中断および／または非優先化されたときにオーバーフローリソースを使用し得る。たとえば、ＷＴＲＵ１０２は、（たとえば、ＷＴＲＵ内優先度付けにより）ＨＡＲＱ－ＡＣＫの送信をドロップすることがあり、オーバーフローリソースを使用して非優先のＨＡＲＱ－ＡＣＫを送信し得る。ＷＴＲＵ１０２は、オーバーフローＰＵＣＣＨリソースを決定するために、以前（または初期）に示されたＰＵＣＣＨリソースおよびＨＡＲＱ－ＡＣＫタイミングを使用し得る。たとえば、ＷＴＲＵ１０２は、（たとえば、概してＰＤＳＣＨと対応するＰＵＣＣＨとの間の遅延である）以前にシグナリングされたＫ１と、ＰＵＣＣＨリソースに関連付けられたＰＲＩ（たとえば、これはＰＵＣＣＨリソースインジケータとして定義され得る。）とを使用して、ＨＡＲＱ－ＡＣＫ送信を非優先化した後にＫ１個の（または以前にシグナリングされたＫ１に応じた）スロットを開始する別のＰＵＣＣＨオーバーフローリソースを決定し得る。

【0176】

１つまたは複数の１次リソースおよびオーバーフローリソースは、異なる優先度のトラフィックのためのＵＣＩを送信するために使用され得る。この場合、より高い優先度レベルトラフィックは、トラフィック優先度レベル（たとえばレイテンシ）を満たすために１次リソースにおいて送信され得、およびまたは一方で、オーバーフローリソースは、より低い優先度トラフィックを送信するために使用され得る。いくつかの代表的な実施形態では、１次リソースは、多重化されたより高い優先度ＵＣＩおよびより低い優先度ＵＣＩを送信するために使用され、オーバーフローリソースは、より低い優先度ＵＣＩ（たとえば、より低い優先度ＵＣＩのみ）を送信するために使用され得る。

【0177】

そのリソース中で送信されるトラフィック（たとえば、特定のトラフィック）を示すために、ＷＴＲＵからネットワークエンティティ（たとえば、ｇＮＢまたは他のアクセスポイント）への明示的または暗黙的シグナリングが必要とされ得る。一例では、ＷＴＲＵ１０２は、別個のＵＣＩとしておよび／または１次ＰＵＣＣＨリソース上のＵＣＩの一部として、（たとえば、オーバーフロー利用シグナリングの送信において）オーバーフローリソースのＷＴＲＵの使用を示すために、オーバーフロー利用シグナリングをネットワークエンティティおよび／またはｇＮＢに送信し得る。オーバーフロー利用シグナリングは、オーバーフローリソースの使用を示すフラグもしくはインジケータ（たとえば、シングルビットインジケータもしくはマルチビットインジケータ）であり得、および／または特定のＰＵＣＣＨリソースもしくは使用されるリソースに関する情報を含み得る。一例では、ＷＴＲＵ１０２は、１次リソース上の予期しないより高優先度のＵＣＩの送信により、ネットワークエンティティまたはｇＮＢがオーバーフローリソースの使用を暗黙的に識別し得ると仮定または決定し得る。

【0178】

ＷＴＲＵ１０２が非専用オーバーフローリソースを用いて構成された場合は、複数のＷＴＲＵ１０２がオーバーフローリソースを同時に使用する場合、ＷＴＲＵ１０２間またはそれらのうちの衝突が起こり得る。ネットワークエンティティまたはｇＮＢは、非専用オーバーフローリソースにおける情報の受信に明示的に肯定応答し得る。起こり得る衝突の影響を緩和するために、一実施形態では、ＷＴＲＵ１０２は、（たとえば、非直交多元接続（ＮＯＭＡ）波形を使用して、）非専用リソースにおいて非直交様式で情報を送信して、複数のＷＴＲＵ１０２がリソースにアクセスすることを可能にするように構成され得る。送信された情報が、より低い優先度トラフィックからである可能性が最も高いとき、これは許容でき得る。一例では、ＷＴＲＵ１０２は、ＮＲ－Ｕなどにおけるリッスンビフォアトーク機構を使用して、またはＷＴＲＵ１０２が非専用リソースのサブセットをランダムに選択し得る（たとえば、コード、周波数、および／もしくは時間を選択する）ランダムアクセス機構を使用して、オーバーフローリソースにアクセスするように構成され得る。いくつかの代表的な実施形態では、オーバーフローリソースは、たとえば、（たとえば、シーケンスベースのＰＵＣＣＨを使用することによって）同じ時間周波数リソース内の複数のＷＴＲＵ１０２からのデータの多重化を可能にし得る、ＰＵＣＣＨフォーマットに制限され得る。

【0179】

一例では、異なる優先度レベルをもつトラフィック間のＵＣＩ衝突を識別すると、ＷＴＲＵ１０２は、１次およびオーバーフローＵＣＩ送信構成に自律的に切り替わり得る。

【0180】

衝突シナリオおよび可能な例示的な解決策のいくつかの例について本明細書で説明される。以下で、たとえばＵＲＬＬＣがｅＭＢＢよりも高い優先度を有し得るように、「ｅＭＢＢ」は、第１のサービスベースの優先度レベルを指し得、「ＵＲＬＬＣ」は、第２のサービスベースの優先度レベルを指し得る。

【0181】

ｅＭＢＢのＨＡＲＱ－ＡＣＫとＵＲＬＬＣのＨＡＲＱ－ＡＣＫとの間の衝突のための代表的な手順。
ＨＡＲＱ－ＡＣＫの優先度は、スケジューリングＤＣＩ（および／またはＤＬ ＳＰＳのためのアクティブ化ＤＣＩコマンド）において示され得る。

【0182】

ＷＴＲＵ１０２は、ＵＲＬＬＣに適用可能な最大コードレートを超えない場合、ＵＲＬＬＣのために示されるＰＵＣＣＨリソース上でｅＭＢＢおよびＵＲＬＬＣのＨＡＲＱ－ＡＣＫを多重化し得、そうでない場合、ＷＴＲＵ１０２は、ｅＭＢＢのＨＡＲＱ－ＡＣＫをドロップし得る。ｅＭＢＢのＵＣＩ（たとえば、ｅＭＢＢ ＵＣＩのみ）が多重化されるとき、最大コードレートは別々に構成され得る。ＵＲＬＬＣのＨＡＲＱ－ＡＣＫに適用可能な電力制御パラメータが使用され得る。

【0183】

ｅＭＢＢ ＨＡＲＱ－ＡＣＫとＵＲＬＬＣ ＰＵＳＣＨとの間の衝突のための代表的な手順
ＰＵＳＣＨの優先度は、ＤＣＩによって示され、および／またはＲＲＣシグナリングによって構成された許可タイプ１のために示され得る。ＨＡＲＱ－ＡＣＫの優先度は、スケジューリングＤＣＩ（および／またはＤＬ ＳＰＳのためのアクティブ化ＤＣＩコマンド）において示され得る。

【0184】

ＵＲＬＬＣ ＰＵＳＣＨへと多重化されるｅＭＢＢ ＨＡＲＱ－ＡＣＫのための代表的な手順。
ＷＴＲＵ１０２は、高優先度ＰＵＳＣＨへと多重化される低優先度ＨＡＲＱ－ＡＣＫの場合のために構成されたパラメータの追加セット（たとえば、αおよびβ^PUSCH _offset）を使用して、たとえば、あまりに多くのリソースが、必要とされる信頼性のためにｅＭＢＢのＨＡＲＱ－ＡＣＫに使用されることを回避し、十分なリソースがＵＲＬＬＣのＰＵＳＣＨのために保持されることを保証し得る。

【0185】

ｅＭＢＢ ＰＵＳＣＨとＵＲＬＬＣ ＳＲとの間の衝突のための代表的な手順
ＰＵＳＣＨの優先度は、ＤＣＩによって示され、および／またはＲＲＣシグナリングによって構成された許可タイプ１のために示され得る。ＳＲの優先度は、対応するＳＲ構成のためにＲＲＣシグナリングによって示され得る。

【0186】

ＷＴＲＵ１０２は、条件が満たされた場合、ＰＵＳＣＨ上でＳＲを多重化し得、そうでない場合、たとえばＳＲが正であるとき、少なくとも重複部分についてＰＵＳＣＨをドロップし得る。たとえば、条件は、特に、（１）時間領域におけるＰＵＳＣＨリソースが、（たとえば、レイテンシ要件が満たされることを保証するために）ＳＲのためのＰＵＣＣＨリソース内にある、および／または（２）レイヤＱ’_SRごとのコード化変調シンボルの数が、（たとえば信頼性要件が満たされることを保証するために）しきい値よりも少ない、のいずれかを含み得る。

【0187】

ｅＭＢＢのＰＵＳＣＨ上でＵＲＬＬＣ ＳＲのＳＲを多重化するとき、ＷＴＲＵ１０２は、少なくともＨＡＲＱ－ＡＣＫビットの数が２よりも大きい場合、（たとえば、存在する場合）ＵＲＬＬＣのＨＡＲＱ－ＡＣＫを用いてジョイント符号化し得る。ＷＴＲＵ１０２は、低優先度ＰＵＳＣＨへと多重化される高優先度ＨＡＲＱ－ＡＣＫの場合のために構成されたパラメータの追加セット（たとえば、αおよびβ^PUSCH _offset）を使用し得る。

【0188】

ｅＭＢＢ ＰＵＳＣＨとＵＲＬＬＣ ＨＡＲＱ－ＡＣＫとの間の衝突のための代表的な手順
ＰＵＳＣＨの優先度は、ＤＣＩによって示され、および／またはＲＲＣシグナリングによって構成された許可タイプ１のために示され得る。ＨＡＲＱ－ＡＣＫの優先度は、スケジューリングＤＣＩ（および／またはＤＬ ＳＰＳのためのアクティブ化ＤＣＩコマンド）において示され得る。

【0189】

ＷＴＲＵ１０２は、条件が満たされた場合、ｅＭＢＢのＰＵＳＣＨ上でＵＲＬＬＣのＨＡＲＱ－ＡＣＫを多重化し得、そうでない場合、ＷＴＲＵ１０２は、少なくとも重複部分についてＰＵＳＣＨをドロップし得る。条件は、（１）時間領域におけるＰＵＳＣＨリソースが、たとえばレイテンシ要件が満たされることを保証するために、ＵＲＬＬＣのＨＡＲＱ－ＡＣＫが報告されるサブスロット内にある、および／または（２）レイヤＱ’_ACKごとのコード化変調シンボルの数が、たとえば信頼性要件が満たされることを保証するためにしきい値よりも少ない、を含み得る。

【0190】

低優先度ＰＵＳＣＨへと多重化される高優先度ＨＡＲＱ－ＡＣＫの場合のために、パラメータの追加セット（たとえば、αおよびβ^PUSCH _offset）が構成および使用され得る。

【0191】

いくつかの代表的な実施形態では、コードブックインデックスは、サブスロット、ミニスロット、または開始シンボルなど、スロット内のリソースを示し得る。

【0192】

送信電力低減のための優先度付けのための代表的な手順
送信オケージョンにおける周波数範囲内のサービングセル上の総ＷＴＲＵ送信電力がしきい値（たとえば、Ｐｃｍａｘ）を超えることになるかまたは超えるであろう場合、ＷＴＲＵ１０２は、優先順序に従って電力を割り振り得る。いくつかの例では、優先順序は、送信（たとえば、各送信）に関連するサービス関係の優先度に依存し得る。たとえば、いくつかの実施形態では、送信のサービス関係の優先度は、ＰＵＣＣＨおよび／またはＰＵＳＣＨなど、少なくとも送信のいくつかのタイプについて、送信によって搬送される情報のタイプ（たとえば、送信がＨＡＲＱ－ＡＣＫ、ＳＲ、ＣＳＩおよび／またはデータのみを搬送するかどうか）から導出された優先度よりも優先され得る。優先度付けは、たとえば以下のように式１に記載される、両方のタイプの優先度から決定された複合優先度インデックスＰｏｖｅｒａｌｌによって設定および／または定義され得る。
Ｐｏｖｅｒａｌｌ＝Ｐｓｅｒｖ×Ｎｔｔｙｐｅ＋Ｐｔｔｙｐｅ （１）
式中、Ｐｓｅｒｖは、（たとえば、０で開始し、より高い値がより低い優先度を表す）サービス関係の優先度インデックスであり得、Ｐｔｔｙｐｅは、情報のタイプから導出された優先度インデックスであり得、Ｎｔｔｙｐｅは、情報のタイプのための優先度レベルの数であり得る。たとえば、Ｎｔｔｙｐｅの値は、３つの優先度レベルを有し得る（たとえば、Ｐｔｔｙｐｅの２の値は、ＵＣＩなしのＰＵＳＣＨ送信に関連し、Ｐｔｔｙｐｅの１の値は、ＣＳＩをもつＰＵＣＣＨ送信および／またはＰＵＳＣＨ送信に関連し、Ｐｔｔｙｐｅの０の値は、ＳＲおよび／またはＨＡＲＱ＿ＡＣＫをもつＰＵＣＣＨ送信またはＰＵＳＣＨ送信に関連する）。いくつかの実施形態では、ＣＳＩをもつＰＵＣＣＨ送信は、最も高いＰｓｅｒｖ値に関連付けられ得る（たとえば、常に関連付けられ得る）。

【0193】

たとえば、優先順序は、降順で、以下の通りであり得る：（１）ＰＣｅｌｌ上のＰＲＡＣＨ送信、（２）優先度がＰｏｖｅｒａｌｌによって決定され得るＰＵＣＣＨ送信および／またはＰＵＳＣＨ送信、（３）非周期的ＳＲＳ、ならびに（４）ＳＣｅｌｌ上の半永続的および／または周期的ＳＲＳおよび／またはＰＲＡＣＨ送信。

【0194】

図１０は、フィードバック情報（たとえば、ＨＣＡＩ）を使用する代表的な手順を示すフローチャートである。

【0195】

図１０を参照すると、代表的な手順１０００は、ブロック１０１０において、ＷＴＲＵ１０２が、第１のスロットまたは第１のミニスロット中で第１のサービスタイプ、第１の優先度レベルまたは第１の優先度に関連付けられた第１の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）を受信し、第２のスロットまたは第２のミニスロット中で第２のサービスタイプ／優先度レベル／優先度に関連付けられた第２のＰＤＳＣＨを受信することを含み得る。ブロック１０２０において、ＷＴＲＵ１０２は、第１のＰＤＳＣＨのプロパティまたは第１のＰＤＳＣＨに関連付けられた制御情報に基づいて第１のＨＡＲＱコードブック肯定応答インデックス（ＨＣＡＩ）を決定し、第２のＰＤＳＣＨのプロパティまたは第２のＰＤＳＣＨに関連付けられた制御情報に基づいて第２のＨＣＡＩを決定し得る。ブロック１０３０において、ＷＴＲＵ１０２は、第２のスロット、第２のミニスロット、後続のスロットまたは後続のミニスロットのいずれかについて、第１のＨＣＡＩに従って第１のＨＡＲＱ肯定応答（ＨＡＲＱ－ＡＣＫ）情報を含む第１の物理アップリンク制御チャネル（ＰＵＣＣＨ）を生成し、第２のＨＣＡＩに従って第２のＨＡＲＱ－ＡＣＫ情報を含む第２のＰＵＣＣＨを生成し得る。ブロック１０４０において、ＷＴＲＵ１０２は、第１および第２のＰＵＣＣＨをネットワークエンティティに送信し得る。たとえば、第１のＰＤＳＣＨおよび第２のＰＤＳＣＨのプロパティは、探索空間、送信プロファイル、および／または一時識別子のいずれかであり得る。

【0196】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、別個のＰＵＣＣＨリソースにおいて、第１のＨＡＲＱ－ＡＣＫ情報として、ＨＡＲＱ－ＡＣＫビットの第１のセットを多重化し、第２のＨＡＲＱ－ＡＣＫ情報として、ＨＡＲＱ－ＡＣＫビットの第２のセットを多重化し得る。

【0197】

いくつかの代表的な実施形態では、第１のサービスタイプは、超高信頼低レイテンシ通信（ＵＲＬＬＣ）サービスまたは拡張ＵＲＬＬＣサービスであり得、第２のサービスタイプは、別のサービスタイプであり得、および／または第２のサービスタイプは、拡張モバイルブロードバンド（ｅＭＢＢ）サービスもしくは大容量マシンタイプ通信（ｍＭＴＣ）サービスであり得る。

【0198】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、ＰＤＳＣＨに関連付けられた示されたＨＣＡＩからＰＤＳＣＨの優先度レベルを決定し得る。

【0199】

たとえば、ＤＣＩ（たとえば、制御シグナリング）は、様々なサービス／優先度レベルに関連付けられた１つまたは複数の遅延期間を示し得る。それぞれの遅延期間は、（１）それぞれのＰＤＳＣＨの送信とそれぞれのＰＵＣＣＨ送信の送信との間の時間、（２）それぞれのＰＤＳＣＨの送信とそれぞれのＰＵＣＣＨ送信の送信との間のスロットの数、および／または（３）それぞれのＰＤＳＣＨの送信とそれぞれのＰＵＣＣＨの送信との間のミニスロットの数のうちの１つを示し得る。

【0200】

図１１は、フィードバック情報（たとえば、ＨＣＡＩ）を使用する別の代表的な手順を示すフローチャートである。

【0201】

図１１を参照すると、代表的な手順１１００は、ブロック１１１０において、ＷＴＲＵ１０２が、複数のスロットまたはミニスロット中で、異なるサービスタイプ、優先度レベル、または優先度に関連付けられた複数の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）を受信することを含み得る。ブロック１１２０において、ＷＴＲＵ１０２は、ＨＡＲＱコードブック肯定応答インデックス（ＨＣＡＩ）と、（１）受信された複数のＰＤＳＣＨの各々のためのサービスタイプ、（２）受信された複数のＰＤＳＣＨの各々のための優先度レベル、および／または（３）受信された複数のＰＤＳＣＨの各々のための優先度のいずれかとを決定し得る。ブロック１１３０において、ＷＴＲＵ１０２は、決定されたＨＣＡＩおよび決定されたサービスタイプ／優先度レベル／優先度に基づいて、それぞれのスロットまたはそれぞれのミニスロットのために送信されるべきいくつかのＰＵＣＣＨを決定し得る。ブロック１１４０において、ＷＴＲＵ１０２は、それぞれのスロットまたはそれぞれのミニスロットのそれぞれ異なるＰＵＣＣＨリソースにおいて、いくつかのＰＵＣＣＨを多重化し得る。ブロック１１５０において、ＷＴＲＵ１０２は、それぞれのスロットまたはそれぞれのミニスロットにおいて、決定されたいくつかのＰＵＣＣＨを送信し得る。たとえば、ＰＤＳＣＨに関連付けられた、決定された（１）サービスタイプ、（２）優先度レベルおよび／または（３）優先度は、探索空間、送信プロファイル、および／または一時識別子のいずれかを含むＰＤＳＣＨの１つまたは複数のプロパティによって示され得る。

【0202】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、（たとえば、各ＨＡＲＱコードブックが、ＨＡＲＱコードブックインデックスおよび／または優先度レベルに関連付けられた１つまたは複数のＰＤＳＣＨのためのＨＡＲＱ－ＡＣＫを含むという条件で）共通スロットの別個のＰＵＣＣＨリソースにおいて、第１のＨＣＡＩに従って第１のＨＡＲＱ－ＡＣＫ情報として、ＨＡＲＱ－ＡＣＫビットの第１のセットを多重化し、第２のＨＣＡＩに従って第２のＨＡＲＱ－ＡＣＫ情報として、ＨＡＲＱ－ＡＣＫビットの第２のセットを多重化し得る。

【0203】

いくつかの代表的な実施形態では、共通スロット中の別個のＰＵＣＣＨリソースのための条件は、第１のサービスタイプ、第１の優先度レベル、および／または第１の優先度が、第１のＨＣＡＩに関連付けられたことを示されることと、異なるサービスタイプ、異なる優先度レベル、および／または異なる優先度が、第２のＨＣＡＩに関連付けられたことを示されることとを含み得る。

【0204】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、（たとえば、各ＨＡＲＱコードブックが、ＨＡＲＱコードブックインデックスおよび／または優先度レベルに関連付けられた１つまたは複数のＰＤＳＣＨのためのＨＡＲＱ－ＡＣＫを含むという条件で）異なるスロットの別個のＰＵＣＣＨリソースにおいて、第１のＨＣＡＩに関連付けられた第１のＨＡＲＱ－ＡＣＫ情報として、ＨＡＲＱ－ＡＣＫビットの第１のセットを多重化し、第２のＨＣＡＩに関連付けられた第２のＨＡＲＱ－ＡＣＫ情報として、ＨＡＲＱ－ＡＣＫビットの第２のセットを多重化し得る。

【0205】

いくつかの代表的な実施形態では、異なるスロット中の別個のＰＵＣＣＨリソースのための条件は、第１のサービスタイプ、優先度レベル、および／または優先度が、第１のＨＣＡＩに関連付けられたことを示されることと、異なるサービスタイプ、異なる優先度レベル、および／または異なる優先度が、第２のＨＣＡＩに関連付けられたことを示されることとを含み得る。

【0206】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、ＰＤＳＣＨの第１および第２のセットに関連付けられた優先度、優先度レベルおよび／またはサービスタイプ、に関連付けられた多重化ルールに基づいて、共通スロットの共通ＰＵＣＣＨリソース中で、ＰＤＳＣＨの第１のセットに関連付けられたＨＡＲＱ－ＡＣＫビットの第１のセット、およびＰＤＳＣＨの第２のセットに関連付けられたＨＡＲＱ－ＡＣＫビットの第２のセットを多重化し得る。

【0207】

いくつかの代表的な実施形態では、第１のサービスタイプは、超高信頼低レイテンシ通信（ＵＲＬＬＣ）サービスまたは拡張ＵＲＬＬＣサービスであり得、第２のサービスタイプは、別のサービスタイプであり得、および／または、たとえば、第２のサービスタイプは、拡張モバイルブロードバンド（ｅＭＢＢ）サービスもしくは大容量マシンタイプ通信（ｍＭＴＣ）サービスであり得る。

【0208】

いくつかの代表的な実施形態では、優先度レベルは、たとえば最も重要な制御シグナリングおよび／またはデータに関連付けられた、最も高い優先度レベルと、たとえばあまり重要でない制御シグナリングおよび／またはデータに関連付けられた、１つまたは複数のより低い優先度レベルとであり得る。

【0209】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、少なくとも１つのＰＵＣＣＨをドロップすること（またはドロップするかどうか）を決定し得る。たとえば、１つまたは複数のＰＵＣＣＨのドロップは、（１）少なくとも１つのＰＵＣＣＨのプロパティ、（２）少なくとも１つのＰＵＣＣＨのＰＵＣＣＨフォーマット、（３）ＨＣＡＩ、（４）送信プロファイル、（５）少なくとも１つのＰＵＣＣＨに関連するＰＤＳＣＨ送信のプロパティ、および／または（６）対応する物理ダウンリンク制御チャネル（ＰＤＣＣＨ）のプロパティのいずれかに基づき得る。

【0210】

いくつかの代表的な実施形態では、１つまたは複数のサービスタイプは、（１）超高信頼低レイテンシ通信（ＵＲＬＬＣ）サービス、（２）拡張ＵＲＬＬＣサービス、（３）拡張モバイルブロードバンド（ｅＭＢＢ）サービス、および／または（４）大容量マシンタイプ通信（ｍＭＴＣ）サービスのいずれかを含み得る。

【0211】

いくつかの代表的な実施形態では、ＨＣＡＩの各制御信号は、ＰＤＳＣＨ送信とＰＵＣＣＨ送信との間の（１）時間、（２）スロットの数または（３）ミニスロットの数のいずれかに関連付けられた遅延期間を示し得る。

【0212】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、少なくとも１つのＰＵＣＣＨまたはＰＵＳＣＨをドロップすることを決定し得る。たとえば、ＷＴＲＵ１０２は、（１）少なくとも１つのＰＵＣＣＨのプロパティ、（２）少なくとも１つのＰＵＣＣＨのＰＵＣＣＨフォーマット、（３）ＨＡＲＱコードブックインデックス、（４）送信プロファイル、（５）少なくとも１つのＰＵＣＣＨに関連するＰＤＳＣＨ送信のプロパティ、（６）優先度レベル、（７）相対的優先度レベル、および／または（８）対応する物理ダウンリンク制御チャネル（ＰＤＣＣＨ）のプロパティのいずれかに基づいて少なくとも１つのＰＵＣＣＨまたはＰＵＳＣＨをドロップすることを決定し得る。

【0213】

図１２は、（たとえば、ｅＭＢＢおよびＵＲＬＬＣ情報／制御シグナリングの）時間領域重複のための代表的な手順を示すフローチャートである。

【0214】

図１２を参照すると、代表的な手順１２００は、ブロック１２１０において、ＷＴＲＵ１０２が、ある優先度レベル、たとえば拡張モバイルブロードバンド（ｅＭＢＢ）サービスに関連付けられたスケジューリング要求（ＳＲ）またはＨＡＲＱ情報が、より高い優先度レベル、たとえば超高信頼低レイテンシ通信（ＵＲＬＬＣ）サービスまたは拡張ＵＲＬＬＣ（ｅＵＲＬＬＣ）サービスに関連付けられた物理アップリンク共有チャネル（ＰＵＳＣＨ）と時間領域において重複することになると決定することを含み得る。ブロック１２２０において、より低い優先度レベルに関連付けられたＳＲまたはＨＡＲＱ情報が、より高い優先度レベルに関連付けられたＰＵＳＣＨと時間領域において重複することになるという条件で、ＷＴＲＵ１０２は、より高い優先度レベル、たとえばＵＲＬＬＣまたはｅＵＲＬＬＣサービスに関連付けられたＰＵＳＣＨ上で、より低い優先度レベル、たとえばｅＭＢＢサービスに関連付けられたＳＲまたはＨＡＲＱ情報を多重化し得る。ブロック１２３０において、ＷＴＲＵ１０２は、ＰＵＳＣＨを送信し得る。

【0215】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、（たとえばｅＭＢＢサービスに関連連れられた）ＳＲまたはＨＡＲＱ情報のための第１の優先度レベル、および（たとえばＵＲＬＬＣサービスまたはｅＵＲＬＬＣサービスに関連付けられた）ＰＵＳＣＨのための第２の優先度レベルを決定し得る。

【0216】

いくつかの代表的な実施形態では、ＰＵＳＣＨ上でのＳＲまたはＨＡＲＱ情報の多重化は、第１および第２の優先度レベルに関連付けられたあらかじめ決定されたルールをさらに条件とし得る。

【0217】

図１３は、非優先の情報／制御シグナリング（たとえば、ＨＡＲＱ肯定応答（ＨＡＲＱ－ＡＣＫ））のためのオーバーフローリソースを使用する代表的な手順を示すフローチャートである。

【0218】

図１３を参照すると、代表的な手順１３００は、ブロック１３１０において、ＷＴＲＵ１０２が、１次アップリンクリソースおよび少なくとも１つのアップリンクオーバーフローリソースを構成することを含み得る。ブロック１３２０において、ＷＴＲＵ１０２は、情報または制御シグナリングを受信し得る。ブロック１３３０において、ＷＴＲＵ１０２は、情報または制御シグナリングのＨＡＲＱ肯定応答（ＨＡＲＱ－ＡＣＫ）が非優先化されるかどうかを決定し得る。ブロック１３４０において、ＨＡＲＱ－ＡＣＫが非優先化されるという条件で、ＷＴＲＵ１０２は、アップリンクオーバーフローリソース上でＨＡＲＱ－ＡＣＫを送信し得る。ブロック１３５０において、ＷＴＲＵ１０２は、ＨＡＲＱ－ＡＣＫが非優先化されないという条件で、１次アップリンクリソース上でＨＡＲＱ－ＡＣＫを送信し得る。たとえば、ＷＴＲＵ１０２は、ＨＡＲＱ－ＡＣＫと、他の情報または他の制御シグナリングのいずれかとの間の衝突が発生することになるかどうかを決定し得、ＨＡＲＱ－ＡＣＫの優先度レベルが他の情報または他の制御シグナリングの優先度レベルを超えるかどうかを決定し得、ＨＡＲＱ－ＡＣＫの優先度レベルが他の情報または他の制御シグナリングの優先度レベルを超えないという条件で、ＷＴＲＵ１０２は、ＨＡＲＱ－ＡＣＫを非優先化し得る。

【0219】

１次リソースおよびオーバーフローリソースは、時間もしくは周波数のいずれかにおいて重複があるかまたはそれらのいずれにも重複がない、別個の時間および周波数リソースにあり得る。

【0220】

図１４は、（たとえば、サービスタイプに基づく）ビットフィールド解釈を使用する代表的な手順を示すフローチャートである。

【0221】

図１４を参照すると、代表的な手順１４００は、ブロック１４１０において、ＷＴＲＵ１０２が、ＷＴＲＵによって、ダウンリンク制御情報（ＤＣＩ）を含む情報を受信することを含み得る。ブロック１４２０において、ＷＴＲＵ１０２は、ＷＴＲＵにプロビジョニングされるサービスタイプ／優先度レベル／優先度を決定するか、または受信された情報から取得し得る。ブロック１４３０において、ＷＴＲＵ１０２は、決定されたサービスタイプ、決定された優先度レベルおよび／または決定された優先度に基づいて、受信されたＤＣＩ中のビットフィールドのセットの解釈を実施し得る。ブロック１４４０において、ＷＴＲＵ１０２は、ビットフィールドのセットの解釈に従ってＷＴＲＵを構成し得る。たとえば、ビットフィールドのセット中のビットフィールドのうちの少なくとも１つの解釈は、第１のサービスタイプ、優先度レベルおよび／または優先度について、第２のサービスタイプ、優先度レベルおよび／または優先度に対して異なり得る。

【0222】

いくつかの代表的な実施形態では、ビットフィールドのセット中のビットフィールドのうちの少なくとも１つの解釈は、（１）第１のサービスタイプ／優先度レベル／優先度のための第１のユニットタイプ、および（２）第２のサービスタイプ／優先度レベル／優先度のための第２のユニットタイプに関連付けられ得る。たとえば、第１のユニットタイプは、（１）シンボル、（２）シンボルのグループ、（３）ミニスロット、（４）スロット、もしくは（５）サブフレームであり、および／または第２のユニットタイプは、（１）シンボル、（２）シンボルのグループ、（３）ミニスロット、（４）スロット、もしくは（５）サブフレームのうちの異なるものである。別の例として、第１のユニットタイプは、超高信頼低レイテンシ通信（ＵＲＬＬＣ）サービスまたは拡張ＵＲＬＬＣサービスのためのＨＡＲＱフィードバックタイミングに関連して使用されるシンボルであり得、第２のユニットタイプは、拡張モバイルブロードバンド（ｅＭＢＢ）サービスのためのＨＡＲＱフィードバックタイミングに関連して使用されるスロットであり得る。

【0223】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、（１）ＤＣＩ、（２）無線リソース制御（ＲＲＣ）シグナリング、および／または（３）１つもしくは複数のシステム情報ブロック（ＳＩＢ）のいずれかから、ＷＴＲＵにプロビジョニングされる１つまたは複数のサービスタイプ／優先度レベル／優先度を決定または取得し得る。

【0224】

いくつかの代表的な実施形態では、サービスタイプは、超高信頼低レイテンシ通信（ＵＲＬＬＣ）タイプサービス、拡張ＵＲＬＬＣ、拡張モバイルブロードバンド（ｅＭＢＢ）タイプサービス、または大容量マシンタイプ通信（ｍＭＴＣ）タイプサービスのいずれかであり得る。

【0225】

いくつかの代表的な実施形態では、受信された情報は、制御チャネル構成情報および／またはＰＤＳＣＨ時間領域値のいずれかを含み得る。たとえば、ＷＴＲＵ１０２は、含まれる制御チャネル構成情報または含まれるＰＤＳＣＨ時間領域値から、プロビジョニングされるサービスタイプ、優先度レベルおよび／または優先度を決定し得る。

【0226】

いくつかの代表的な実施形態では、制御チャネル構成情報は、（１）探索空間監視パターン、（２）探索空間監視周期性、（３）探索空間持続時間、（４）ＣＯＲＥＳＥＴ構成、（５）サイクリック冗長検査（ＣＲＣ）をスクランブルするために使用されるＲＮＴＩ、および／または（６）帯域幅パート構成のいずれかを含み得る。

【0227】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２によって受信されたＤＣＩが、探索空間監視パターンを用いて構成された探索空間内にあるという条件で、ＷＴＲＵ１０２は、ＷＴＲＵにプロビジョニングされるサービスタイプ、優先度レベルまたは優先度が、第１のサービスタイプ、第１の優先度レベルまたは第１の優先度であると決定し得、ＷＴＲＵによって受信されたＤＣＩが、探索空間監視パターンを用いて構成された探索空間内にないという条件で、ＷＴＲＵ１０２は、ＷＴＲＵにプロビジョニングされるサービスタイプが、第２のサービスタイプ、第２の優先度レベルまたは第２の優先度であると決定し得る。

【0228】

いくつかの代表的な実施形態では、監視周期性が周期性しきい値を超えるという条件で、ＷＴＲＵ１０２は、ＷＴＲＵにプロビジョニングされるサービスタイプ、優先度レベルまたは優先度が、第１のサービスタイプ、第１の優先度レベルまたは第１の優先度であると決定し得、監視周期性が周期性しきい値を超えないという条件で、ＷＴＲＵ１０２は、ＷＴＲＵにプロビジョニングされるサービスタイプ、優先度レベルまたは優先度が、第２のサービスタイプ、第２の優先度レベルまたは第２の優先度であると決定し得る。

【0229】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２によって受信されたＤＣＩが、Ｋ個のスロットよりも短い持続時間をもつ探索空間内にあり、Ｋが整数であるという条件で、ＷＴＲＵ１０２は、ＷＴＲＵにプロビジョニングされるサービスタイプ、優先度レベルまたは優先度が、第１のサービスタイプ、第１の優先度レベルまたは第１の優先度であると決定し得、持続時間がＫ個のスロット以上であるという条件で、ＷＴＲＵ１０２は、ＷＴＲＵにプロビジョニングされるサービスタイプ、優先度レベルまたは優先度が、第２のサービスタイプ、第２の優先度レベルまたは第２の優先度であると決定し得る。

【0230】

いくつかの代表的な実施形態では、ＰＤＳＣＨ時間領域値が、しきい値を下回るかまたはしきい値間の範囲内にあるという条件で、ＷＴＲＵ１０２は、ＷＴＲＵにプロビジョニングされるサービスタイプ、優先度レベルまたは優先度が、第１のサービスタイプ、第１の優先度レベルまたは第１の優先度であると決定し得、ＰＤＳＣＨ時間領域値が、しきい値を下回るかまたはしきい値間の範囲内にある、のではないという条件で、ＷＴＲＵ１０２は、ＷＴＲＵにプロビジョニングされるサービスタイプ、優先度レベルまたは優先度が、第２のサービスタイプ、第２の優先度レベルまたは第２の優先度であると決定し得る。

【0231】

いくつかの代表的な実施形態では、受信されたＤＣＩ中のビットフィールドのセットは、ＨＡＲＱタイミングインジケーションビットフィールド中にＨＡＲＱタイミングインジケーション値を含み得る。たとえば、ＨＡＲＱタイミングインジケーションビットフィールド中のＨＡＲＱタイミングインジケーション値の解釈は、（１）１つもしくは複数の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）時間領域割振り値、（２）ＤＭＲＳマッピングタイプ、（３）ＰＤＳＣＨの開始シンボル、（４）ＰＤＳＣＨ送信の長さ、（５）ＰＤＣＣＨの受信とＰＤＳＣＨの開始シンボルとの間のオフセットもしくは遅延、および／または（６）１つもしくは複数のＨＡＲＱ処理ＩＤ値のいずれかに基づき得る。

【0232】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、ＰＤＳＣＨ持続時間がしきい値を下回る場合、ＰＤＳＣＨ送信が、第１のサービスタイプ、第１の優先度レベルまたは第１の優先度に関連付けられたＰＤＳＣＨ送信の第１のセットに属すると決定し、そうでない場合、ＰＤＳＣＨ送信が、第２のサービスタイプ、第２の優先度レベルまたは第２の優先度に関連付けられたＰＤＳＣＨ送信の第２のセットに属すると決定し得る。

【0233】

図１５は、（たとえば、サービスタイプに基づく）ＨＡＲＱフィードバックのための代表的な手順を示すフローチャートである。

【0234】

図１５を参照すると、代表的な手順１５００は、ブロック１５１０において、ＷＴＲＵ１０２が、ＷＴＲＵによって、情報を受信することを含み得る。ブロック１５２０において、ＷＴＲＵ１０２は、受信された情報から、ＷＴＲＵが第１のサービスタイプ／優先度レベル／優先度についてプロビジョニングされると決定し得る。ブロック１５３０において、ＷＴＲＵ１０２は、第１のサービスタイプ／優先度レベル／優先度に関連付けられた送信のためのコード化ビットを生成し得る。ブロック１５４０において、ＷＴＲＵ１０２は、上書きされるコード化ビットとして、生成されたコード化ビットのサブセットを、第２のサービスタイプ／優先度レベル／優先度に関連付けられたコード化ビットで上書きして、第１および第２のサービス／優先度レベル／優先度に関連付けられたコード化ビットのシーケンスを生成し得、第２のサービスタイプ／優先度レベル／優先度は、第１のサービスタイプ／優先度レベル／優先度の優先度レベルよりも高い優先度レベルを有する。ブロック１５５０において、ＷＴＲＵ１０２は、第１および第２のサービス／優先度レベル／優先度に関連付けられたコード化ビットのシーケンスを使用して、送信用の信号を生成し得る。ブロック１５５０において、ＷＴＲＵ１０２は、信号をネットワークエンティティに送信し得る。

【0235】

いくつかの代表的な実施形態では、送信される信号のコード化ビットは、第１のサービスタイプ／優先度レベル／優先度の制御機能またはデータに関連付けられたコード化ビットのセット、および第２のサービスタイプ／優先度レベル／優先度の制御機能に関連付けられたコード化ビットのセットを含み得る。

【0236】

いくつかの代表的な実施形態では、第１のサービスタイプは、拡張モバイルブロードバンド（ｅＭＢＢ）サービスであり得、第２のサービスタイプは、超高信頼低レイテンシ通信（ＵＲＬＬＣ）または拡張ＵＲＬＬＣであり得る。

【0237】

いくつかの代表的な実施形態では、第１のサービスタイプ／優先度レベル／優先度の制御機能もしくはデータは、第１のサービスタイプ／優先度レベル／優先度の（１）スケジューリング要求（ＳＲ）、（２）ＨＡＲＱ－ＡＣＫ、（３）ＣＳＩもしくは（４）データのいずれかであり得、および／または第２のサービスタイプ／優先度レベル／優先度の制御機能は、第２のサービスタイプ／優先度レベル／優先度の（１）ＳＲ、（２）ＨＡＲＱ－ＡＣＫもしくは（３）ＣＳＩのいずれかであり得る。

【0238】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、上書きされるべき第１のサービスタイプ／優先度レベル／優先度のいくつかのコード化ビットが、上書きされるコード化ビットと置換されるべきいくつかのビットとの対応を有するかどうかを決定し得る。たとえば、上書きされるべき第１のサービスタイプ、第１の優先度レベルまたは第１の優先度のいくつかのビットが、上書きされるコード化ビットと置換されるべきいくつかのコード化ビットとの対応を有するという条件で、ＷＴＲＵ１０２は、第１のサービスタイプ、第１の優先度レベルまたは第１の優先度のいくつかのコード化ビットを上書きし得る。別の例として、上書きされるべき第１のサービスタイプ、第１の優先度レベルまたは第１の優先度のいくつかのコード化ビットが、上書きされるべきコード化ビットと置換されるべきいくつかのコード化ビットとの対応を有しないという条件で、ＷＴＲＵ１０２は、上書きすることなしに、第１のサービスタイプ、第１の優先度レベルまたは第１の優先度のコード化ビットの一部をドロップし、ドロップされたビットを、第２のサービスタイプ、第２の優先度レベルまたは第２の優先度に関連付けられたコード化ビットのセットと置換し得る。

【0239】

第１のサービスタイプ、第１の優先度レベルまたは第１の優先度に関連付けられたコード化ビットのサブセットの上書きは、ＷＴＲＵが、第１のサービスタイプ、第１の優先度レベルもしくは第１の優先度に関連付けられたコード化ビットの第１のシーケンスを決定すること、第２のサービスタイプ、第２の優先度レベルもしくは第２の優先度に関連付けられたコード化ビットと置換されるべき、第１のサービスタイプ、第１の優先度レベルもしくは第１の優先度に関連付けられたコード化ビットの第１のシーケンス中の位置を決定し、決定された位置における第１のシーケンスのコード化ビットにおいて削除すること、および／または決定された位置において、第２のサービスタイプに関連付けられたコード化ビットを挿入することを含み得る。

【0240】

図１５は、（たとえば、サービスタイプに基づく）ＨＡＲＱフィードバックのための代表的な手順を示すフローチャートである。

【0241】

図１５を参照すると、代表的な手順１５００は、ブロック１５１０において、ＷＴＲＵ１０２が、情報を受信することを含み得る。ブロック１５２０において、ＷＴＲＵ１０２は、受信された情報から、ＷＴＲＵが、第１のサービスタイプまたは第１の優先度レベルおよび第２のサービスタイプまたは第２の優先度レベルについてプロビジョニングされると決定し得る。ブロック１５３０において、ＷＴＲＵ１０２は、第１のサービスタイプまたは第１の優先度レベルに関連付けられた第１のＨＡＲＱフィードバック、および第２のサービスタイプまたは第２の優先度レベルに関連付けられた第２のＨＡＲＱフィードバックの送信のために、ＷＴＲＵを構成し得る。

【0242】

いくつかの代表的な実施形態では、第１のサービスタイプまたは第１の優先度レベルに関連付けられた第１のＨＡＲＱフィードバック、および第２のサービスタイプまたは第２の優先度レベルに関連付けられた第２のＨＡＲＱフィードバックの送信のためのＷＴＲＵの構成は、第１のＨＡＲＱフィードバックを搬送するための時間周波数リソースの第１の部分、および第２のＨＡＲＱフィードバックを搬送するための時間周波数リソースの第２の別個の部分の設定を含み得る。

【0243】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、第１のデータの受信と第１のＨＡＲＱフィードバックの送信との間の第１の遅延時間が、第２のデータの受信と第２のＨＡＲＱフィードバックの送信との間の第２の遅延時間よりも小さくなり得るように、第１のサービスタイプまたは第１の優先度レベルに関連付けられた第１のデータ、および第２のサービスタイプまたは第２の優先度レベルに関連付けられた第２のデータを受信し得る。たとえば、第１のサービスタイプまたは第１の優先度レベルは、超高信頼低レイテンシ通信（ＵＲＬＬＣ）サービスまたは拡張ＵＲＬＬＣ（ｅＵＲＬＬＣ）サービスであり得るかまたはそれらに対応し得、第２のサービスタイプまたは第２の優先度レベルは、拡張モバイルブロードバンド（ｅＭＢＢ）サービスであり得るかまたはそれに対応し得る。たとえば、第１の優先度レベルは、ＵＲＬＬＣまたはｅＵＲＬＬＣサービスに関連付けられた優先度であり得、第２の優先度は、ｅＭＢＢに関連付けられた優先度レベルであり得る。

【0244】

いくつかの代表的な実施形態では、第２のＨＡＲＱフィードバックは、ロングフォーマット物理アップリンク制御チャネル（ＰＵＣＣＨ）中で送られ得、および／または第１のＨＡＲＱフィードバックは、第２のＨＡＲＱフィードバックよりも短いレイテンシを伴うフォーマットで送られ得る。

【0245】

図１６は、代表的な上書き手順を示すフローチャートである。

【0246】

図１６を参照すると、代表的な手順１６００は、ブロック１６１０において、ＷＴＲＵ１０２が、情報を受信することを含み得る。ブロック１６２０において、ＷＴＲＵ１０２は、受信された情報から、ＷＴＲＵ１０２が第１のサービスタイプまたは第１の優先度レベルについてプロビジョニングされると決定し得る。ブロック１６３０において、ＷＴＲＵ１０２は、第１のサービスタイプ／優先度レベルに関連付けられた送信のためのコード化ビットを生成し得る。ブロック１６４０において、ＷＴＲＵ１０２は、上書きされるコード化ビットとして、生成されたコード化ビットのサブセットを、第２のサービスタイプまたは第２の優先度レベルに関連付けられたコード化ビットで上書きして、第１および第２のサービス／優先度レベルに関連付けられたコード化ビットのシーケンスを生成し得る。いくつかの実施形態では、第２のサービスタイプは、第１のサービスタイプの優先度レベルよりも高い優先度レベルを有し得る。ブロック１６５０において、ＷＴＲＵ１０２は、第１および第２のサービス／優先度レベルに関連付けられたコード化ビットのシーケンスを使用して、送信用の信号を生成し得る。ブロック１６６０において、ＷＴＲＵ１０２は、生成された信号をネットワークエンティティに送信し得る。

【0247】

いくつかの代表的な実施形態では、送信される信号のコード化ビットは、第１のサービスタイプ／優先度レベルの制御機能またはデータに関連付けられたコード化ビットのセット、および第２のサービスタイプ／優先度レベルの制御機能に関連付けられたコード化ビットのセットを含み得る。たとえば、第１のサービスタイプ／優先度レベルは、ｅＭＢＢサービスであり得るかまたはそれに対応し得、第２のサービスタイプは、ＵＲＬＬＣサービスまたはｅＵＲＬＬＣサービスであり得る。

【0248】

第１のサービスタイプ／優先度レベルの制御機能もしくはデータは、たとえば、第１のサービスタイプ／優先度レベルの（１）スケジューリング要求（ＳＲ）、（２）ＨＡＲＱ－ＡＣＫ、（３）ＣＳＩおよび／もしくは（４）データのいずれかであり得、ならびに／または第２のサービスタイプ／優先度レベルの制御機能は、第２のサービスタイプ／優先度レベルの（１）ＳＲ、（２）ＨＡＲＱ－ＡＣＫおよび／もしくは（３）ＣＳＩのいずれかであり得る。

【0249】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、上書きされるべき第１のサービスタイプ／優先度レベルのいくつかのコード化ビットが、上書きされるコード化ビットと置換されるべきいくつかのビットとの対応を有するかどうかを決定し得、上書きされるべき第１のサービスタイプ／優先度レベルのいくつかのビットが、上書きされるコード化ビットと置換されるべきいくつかのコード化ビットとの対応を有するという条件で、ＷＴＲＵ１０２は、第１のサービスタイプ／優先度レベルのいくつかのコード化ビットを上書きし得る。

【0250】

いくつかの代表的な実施形態では、上書きされるべき第１のサービスタイプ／優先度レベルのいくつかのコード化ビットが、上書きされるべきコード化ビットと置換されるべきいくつかのコード化ビットとの対応を有しないという条件で、ＷＴＲＵ１０２は、第１のサービスタイプ／優先度レベルのコード化ビットの一部をドロップし、ドロップされたビットを、第２のサービスタイプ／優先度レベルに関連付けられたコード化ビットのセットと置換し得る。たとえば、第１のサービスタイプ／優先度レベルに関連付けられたコード化ビットのサブセットの上書きは、ＷＴＲＵ１０２が、第１のサービスタイプ／優先度レベルに関連付けられたコード化ビットの第１のシーケンスを決定すること、第２のサービスタイプ／優先度レベルに関連付けられたコード化ビットと置換されるべき第１のサービスタイプ／優先度レベルに関連付けられたコード化ビットの第１のシーケンス中の位置を決定すること、決定された位置における第１のシーケンスのコード化ビットにおいて削除すること、および／または決定された位置において、第２のサービスタイプ／優先度レベルに関連付けられたコード化ビットを挿入することを含み得る。

【0251】

図１７は、予期される衝突を回避するための代表的な手順を示すフローチャートである。

【0252】

図１７を参照すると、代表的な手順１７００は、ブロック１７１０において、ＷＴＲＵ１０２が、（１）第１のサービスタイプ／優先度レベルのコード化ビットを第２のサービスタイプ／優先度レベルのコード化ビットで多重化するための多重化動作、（２）第１のサービスタイプ／優先度レベルのコード化ビットを第２のサービスタイプ／優先度レベルのコード化ビットで上書きするための上書き動作、および／または（３）第１のサービスタイプ／優先度レベルのコード化ビットをドロップし、好適性基準に基づいて、ドロップされたコード化ビットの位置に第２のサービスタイプ／優先度レベルのコード化ビットを挿入するためのドロップ／挿入動作のいずれかを選択することを含み得る。ブロック１７２０において、ＷＴＲＵ１０２は、選択された動作を使用して、第１および第２のサービスに関連付けられたコード化ビットのシーケンスを生成し得る。ブロック１７３０において、ＷＴＲＵ１０２は、コード化ビットのシーケンスを使用して、送信用の信号を生成し得る。ブロック１７４０において、ＷＴＲＵ１０２は、信号をネットワークエンティティに送信し得る。

【0253】

いくつかの代表的な実施形態では、好適性基準は、（１）サービスベースの優先度レベル、（２）第２のサービスタイプ／優先度レベルのレイテンシ要件、（３）衝突するリソースの持続時間、（４）衝突するリソースの終了時間、（５）上位レイヤによって構成された最大時間遅延および／もしくはオフセット、（６）衝突するリソースの周期性、（７）第２のサービスタイプ／優先度レベルの信頼性要件、（８）第１のしきい値を下回っているレイヤごとのコード化変調シンボルの数、（９）上書きの最大量、（１０）第２のしきい値よりも小さい、衝突するリソースに関連付けられたコーディングレート、ならびに／または（１１）衝突するリソースのために構成された最大ペイロードよりも小さい、第１のもしくは第２のサービスタイプ／優先度レベルに関連付けられたコード化ビットの総数のいずれかに基づき得る。

【0254】

図１８は、代表的な多重化手順を示すフローチャートである。

【0255】

図１８を参照すると、代表的な手順１８００は、ブロック１８１０において、ＷＴＲＵ１０２が、複数の送信の間またはそれらのうちの１つまたは複数の衝突が予期されるかどうかを決定することを含み得る。ブロック１８２０において、ＷＴＲＵ１０２は、予期される衝突のタイミングまたはステータスを決定し得る。ブロック１８３０において、少なくとも１つの衝突が予期されるという条件で、ＷＴＲＵ１０２は、予期される衝突のタイミングまたはステータスに基づいて、第１のレイヤにおいてまたは第２のレイヤにおいて、少なくとも１つの衝突を緩和するための行為を開始すべき（たとえば、いくつかの予期される後続の行為をドロップすべきおよび／または開始しないべき）かどうかを決定し得る。ブロック１８４０において、ＷＴＲＵ１０２は、決定されたレイヤにおいて、少なくとも１つの衝突を緩和するための行為を開始し得る。たとえば、予期される衝突は、（１）物理アップリンク共有チャネル（ＰＵＳＣＨ）およびスケジューリング要求（ＳＲ）、（２）ＰＵＳＣＨおよびアップリンク制御情報（ＵＣＩ）、ならびに／または（３）より高優先度のアップリンク制御情報およびより低優先度のアップリンク制御情報のいずれの間にあり得る。

【0256】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、第１の送信において送信されるべきスケジューリング要求（ＳＲ）もしくはアップリンク制御情報（ＵＣＩ）が、第１のレイヤとして、物理レイヤにすでにシグナリングされたかどうか、またはＰＵＳＣＨの構築が物理レイヤにおいて開始したかどうかを決定し得る。

【0257】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、（１）ＳＲもしくはＵＣＩが物理レイヤにすでにシグナリングされた、またはＰＵＳＣＨの構築が物理レイヤにおいて開始したという条件で、物理レイヤにおいて行為を開始することを決定するか、または（２）ＳＲもしくはＵＣＩが物理レイヤにシグナリングされない、またはＰＵＳＣＨの構築が物理レイヤにおいて開始していないという条件で、ＭＡＣレイヤにおいて行為を開始することを決定し得る。たとえば、ＷＴＲＵ１０２が、ＰＵＳＣＨと重複する、より高優先度のＳＲをシグナリングした場合、ＷＴＲＵ１０２はＭＡＣ ＰＤＵを構築しないことがある。

【0258】

たとえば、決定されたレイヤにおける行為の開始は、（１）ＳＲもしくはＵＣＩがシグナリングされた後に物理レイヤにおいてＳＲもしくはＵＣＩをドロップすること、（２）ＭＡＣレイヤにおいてＳＲもしくはＵＣＩのシグナリングを停止すること、（３）物理レイヤにおいてＰＵＳＣＨをドロップもしくは中断すること、および／または（４）ＭＡＣレイヤにおいてＰＵＳＣＨのシグナリングを停止することのいずれかを含み得る。

【0259】

図１９は、（たとえば、アップリンク制御情報（ＵＣＩ）の送信のための）代表的な手順を示すフローチャートである。

【0260】

図１９を参照すると、代表的な手順１９００は、ブロック１９１０において、ＷＴＲＵ１０２が、スロット中でおよび／または時間領域において重複して複数のＰＵＳＣＨ送信を送信するようにＷＴＲＵを構成することを含み得る。ブロック１９２０において、ＷＴＲＵ１０２は、ＰＵＳＣＨ送信の各々に関連付けられた１つまたは複数のサービスレベル優先度を含む１つまたは複数の基準に基づいて、アップリンク制御情報（ＵＣＩ）を多重化するための少なくとも１つのＰＵＳＣＨを選択し得る。ブロック１９３０において、ＷＴＲＵ１０２は、選択されたＰＵＳＣＨ上でＵＣＩを多重化し得る。ブロック１９４０において、ＷＴＲＵ１０２は、多重化されたＵＣＩを搬送するＰＵＳＣＨを送信し得る。たとえば、１つまたは複数の基準は、ＰＵＳＣＨ送信がＵＣＩおよびデータの組合せの送信のために好適であるかどうかを含み得る。

【0261】

いくつかの代表的な実施形態では、スロット中のまたは重複しているＰＵＳＣＨ送信は、異なるサービングセルおよび／もしくは異なるキャリア上にあり得、ならびに／または各ＰＵＳＣＨ送信は、異なるサービス関係の優先度を有し得る。

【0262】

いくつかの代表的な実施形態では、ＷＴＲＵ１０２は、ＰＵＳＣＨのサービスレベル優先度および／またはＵＣＩのサービスレベル優先度に基づいてＵＣＩを多重化するためのＰＵＳＣＨを選択し得る。

【0263】

代表的な実施形態に従ってデータを処理するためのシステムおよび方法は、メモリデバイスに含まれている命令のシーケンスを実行する１つまたは複数のプロセッサによって実施され得る。そのような命令は、２次データ記憶デバイスなどの他のコンピュータ可読媒体からメモリデバイスに読み取られ得る。メモリデバイスに含まれている命令のシーケンスの実行は、たとえば、上記で説明されたように、プロセッサを動作させる。代替実施形態では、本発明を実装するために、ソフトウェア命令の代わりにまたはそれと組み合わせて、配線接続回路が使用されてよい。そのようなソフトウェアは、ロボット支援／装置（ＲＡＡ）内に格納されたプロセッサ上で、および／またはリモートで別のモバイルデバイス上で実行され得る。後者の場合、データは、センサーを含んでいるＲＡＡまたは他のモバイルデバイスと、上記で説明されたスケール推定および補償を実施するソフトウェアを実行するプロセッサを含んでいるリモートデバイスとの間で、ワイヤラインを介してまたはワイヤレスに転送され得る。他の代表的な実施形態によれば、位置特定に関して上記で説明された処理のいくつかは、センサー／カメラを含んでいるデバイスにおいて実施され得るが、処理の残りは、センサー／カメラを含んでいるデバイスからの部分的に処理されたデータの受信後に第２のデバイスにおいて実施され得る。

【0264】

特徴および要素について、上記では特定の組合せにおいて説明されたが、各特徴または要素は、単独でまたは他の特徴および要素との任意の組合せにおいて使用されることが可能であることを当業者は諒解されよう。加えて、本明細書において説明される方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェア中に実装されてよい。非一時的コンピュータ可読記憶媒体の例は、限定はされないが、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスク、磁気光学媒体などの磁気媒体、ならびにＣＤ－ＲＯＭディスク、およびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために、ソフトウェアに関連するプロセッサが使用され得る。

【0265】

その上、上記で説明された実施形態では、プロセッサを含んでいる処理プラットフォーム、コンピューティングシステム、コントローラ、および他のデバイスが留意される。これらのデバイスは、少なくとも１つの中央処理ユニット（「ＣＰＵ」）およびメモリを含んでいることがある。コンピュータプログラミングの当業者の実践に従って、動作または命令の行為および記号表現への参照が、様々なＣＰＵおよびメモリによって実施され得る。そのような行為および動作または命令は、「実行される」、「コンピュータ実行される」または「ＣＰＵ実行される」と呼ばれることがある。

【0266】

当業者は、行為および記号的に表された動作または命令が、ＣＰＵによる電気信号の操作を含むことを諒解されよう。電気システムは、電気信号の結果として生じる変換または低減と、メモリシステム中のメモリロケーションにおけるデータビットの維持とを引き起こし、それにより、ＣＰＵの動作、ならびに信号の他の処理を再構成するかまたは別様に変えることができる、データビットを表す。データビットが維持されるメモリロケーションは、データビットに対応するかまたはそれを表す特定の電気的、磁気的、光学的、または有機的プロパティを有する物理的ロケーションである。代表的な実施形態は上述のプラットフォームまたはＣＰＵに限定されず、他のプラットフォームおよびＣＰＵが所与の方法をサポートし得ることを理解されたい。

【0267】

データビットはまた、ＣＰＵによって可読な磁気ディスク、光ディスク、および任意の他の揮発性（たとえば、ランダムアクセスメモリ（「ＲＡＭ」））または不揮発性（たとえば、読取り専用メモリ（「ＲＯＭ」））大容量記憶システムを含むコンピュータ可読媒体上に維持され得る。コンピュータ可読媒体は、もっぱら処理システム上に存在するか、または処理システムに対してローカルもしくはリモートであり得る複数の相互接続された処理システム間で分散された、協働するかまたは相互接続されたコンピュータ可読媒体を含み得る。代表的な実施形態は上述のメモリに限定されず、他のプラットフォームおよびメモリが、説明される方法をサポートし得ることを理解されたい。代表的な実施形態は上述のプラットフォームまたはＣＰＵに限定されず、他のプラットフォームおよびＣＰＵが所与の方法をサポートし得ることを理解されたい。

【0268】

例示的な実施形態では、本明細書で説明される動作、処理などのいずれも、コンピュータ可読媒体に記憶されたコンピュータ可読命令として実装され得る。コンピュータ可読命令は、モバイルユニット、ネットワーク要素、および／または任意の他のコンピューティングデバイスのプロセッサによって実行され得る。

【0269】

システムの態様のハードウェア実装とソフトウェア実装との間に残される差異はほとんどない。ハードウェアまたはソフトウェアの使用は、概して、コスト対効率のトレードオフを表す設計選択である（が、いくつかのコンテキストでは、ハードウェアとソフトウェアとの間の選択が有意になり得るという点で、常にそうであるとは限らない）。本明細書で説明される処理および／またはシステムおよび／または他の技術が影響を受け得る様々な車両（たとえば、ハードウェア、ソフトウェア、および／またはファームウェア）があり得、好ましい車両は、処理および／またはシステムおよび／または他の技術が展開されるコンテキストとともに変化し得る。たとえば、実装者が、速度および精度が最上であると決定した場合、実装者は、主にハードウェアおよび／またはファームウェア車両を選択し得る。フレキシビリティが最上である場合、実装者は、主にソフトウェア実装を選択し得る。代替として、実装者は、ハードウェア、ソフトウェア、および／またはファームウェアの何らかの組合せを選択し得る。

【0270】

上記の詳細な説明は、ブロック図、フローチャート、および／または例の使用によってデバイスおよび／または処理の様々な実施形態を記載している。そのようなブロック図、フローチャート、および／または例が、１つまたは複数の機能および／または動作を含んでいる限り、そのようなブロック図、フローチャート、または例の内の各機能および／または動作は、広範囲のハードウェア、ソフトウェア、ファームウェア、またはそれらのほぼ任意の組合せによって、個々におよび／またはまとめて実装され得ることが、当業者によって理解されよう。好適なプロセッサは、例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、特定用途向け標準製品（ＡＳＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、および／または状態機械を含む。

【0271】

本開示は、様々な態様の例示として意図されている、本出願で説明される特定の実施形態に関して限定されるべきではない。多数の修正および変更が、当業者に明らかになるように、それの趣旨および範囲から逸脱することなく行われ得る。本出願の説明において使用される要素、行為、または命令は、明示的にそのようなものとして提供されない限り、本発明にとって重要なまたは本質的であるとして解釈されるべきではない。本明細書で列挙されたものに加えて、本開示の範囲内の機能的に等価な方法および装置は、上記の説明から当業者に明らかになろう。そのような修正および変形は、添付の特許請求の範囲内に入ることが意図されている。本開示は、添付の特許請求の範囲がそれに権利を付与される均等物の全範囲とともに、そのような特許請求の範囲の用語によってのみ限定されるものである。本開示は、特定の方法またはシステムに限定されないことを理解されたい。

【0272】

また、本明細書で使用される用語は、特定の実施形態について説明する目的のためにすぎず、限定的であることを意図されていないことを理解されたい。本明細書で使用されるとき、本明細書で参照されるとき、「局」という用語および「ＳＴＡ」というそれの略語、「ユーザ機器」および「ＵＥ」というそれの略語は、（ｉ）以下で説明されるような、ワイヤレス送信および／もしくは受信ユニット（ＷＴＲＵ）、（ｉｉ）以下で説明されるような、ＷＴＲＵのいくつかの実施形態のいずれか、（ｉｉｉ）とりわけ、以下で説明されるような、ＷＴＲＵの一部もしくは全部の構造および機能を用いて構成されたワイヤレス対応および／もしくはワイヤード対応（たとえば、テザー可能）デバイス、（ｉｉｉ）以下で説明されるような、ＷＴＲＵのすべての構造および機能に満たないものを用いて構成されたワイヤレス対応および／もしくはワイヤード対応デバイス、または（ｉｖ）同様のものを意味し得る。本明細書で具陳されるいずれかのＵＥを表し得る、例示的なＷＴＲＵの詳細は、図１Ａ～図１Ｄに関して以下で提供される。

【0273】

いくつかの代表的な実施形態では、本明細書で説明される主題のいくつかの部分は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、および／または他の集積フォーマットを介して実装され得る。しかしながら、本明細書で開示される実施形態のいくつかの態様は、全部的にまたは部分的に、１つもしくは複数のコンピュータ上で実行される１つもしくは複数のコンピュータプログラムとして（たとえば、１つもしくは複数のコンピュータシステム上で実行される１つもしくは複数のプログラムとして）、１つもしくは複数のプロセッサ上で実行される１つもしくは複数のプログラムとして（たとえば、１つもしくは複数のマイクロプロセッサ上で実行される１つもしくは複数のプログラムとして）、ファームウェアとして、またはそれらのほぼ任意の組合せとして、集積回路において等価的に実装され得ること、ならびにソフトウェアおよびまたはファームウェアのための回路を設計することおよび／またはコードを書くことは、本開示に照らして当業者の技能内に十分にあり得ることを、当業者は認識されよう。加えて、本明細書で説明される主題の機構は、様々な形態のプログラム製品として配布され得ること、および本明細書で説明される主題の例示的な実施形態は、配布を実際に行うために使用される信号担持媒体の特定のタイプに関係なく適用されることを、当業者は諒解されよう。信号担持媒体の例は、限定はされないが、フロッピーディスク、ハードディスクドライブ、ＣＤ、ＤＶＤ、デジタルテープ、コンピュータメモリなどの記録可能型媒体、ならびにデジタルおよび／またはアナログ通信媒体などの送信型媒体（たとえば、光ファイバーケーブル、導波路、ワイヤード通信リンク、ワイヤレス通信リンクなど）を含む。

【0274】

本明細書で説明される主題は、異なる他の構成要素内に含まれているかまたはそれに接続された、異なる構成要素を時々示している。そのような図示されたアーキテクチャは例にすぎず、実際には、同じ機能を達成する多くの他のアーキテクチャが実装され得ることを理解されたい。概念的な意味において、同じ機能を達成するための構成要素のどんな配置も、所望の機能が達成され得るように、効果的に「関連付けられる」。したがって、特定の機能を達成するために本明細書で組み合わされたどんな２つの構成要素も、アーキテクチャまたは中間構成要素とは無関係に、所望の機能が達成されるように、互いに「関連付けられる」ように見られてよい。同様に、そのように関連付けられるどんな２つの構成要素も、所望の機能を達成するために互いに、「動作可能に接続される」または「動作可能に結合される」ものとして見られてもよく、そのように関連付けられることが可能などんな２つの構成要素も、所望の機能を達成するために互いに「動作可能に結合可能な」ものとして見られてもよい。動作可能に結合可能の特定の例は、限定はされないが、物理的に嵌合可能なおよび／もしくは物理的に相互作用する構成要素、ならびに／またはワイヤレスに相互作用可能なおよび／もしくはワイヤレスに相互作用する構成要素、ならびに／または論理的に相互作用するおよび／もしくは論理的に相互作用可能な構成要素を含む。

【0275】

本明細書における実質的に任意の複数形および／または単数形の用語の使用に関して、当業者は、コンテキストおよび／または適用例に適切であるとき、複数形から単数形におよび／または単数形から複数形に変換することができる。様々な単数形／複数形の置換は、明快のために本明細書に明確に記載され得る。

【0276】

概して、本明細書において、特に添付の特許請求の範囲（たとえば、添付の特許請求の範囲の本文）において使用される用語は、「オープン」な用語として概して意図されていることが、当業者によって理解されよう（たとえば、「含んでいる」という用語は、「含んでいるが、限定はされない」として解釈されるべきであり、「有する」という用語は、「少なくとも有する」として解釈されるべきであり、「含む」という用語は、「含むが、限定はされない」として解釈されるべきである、など）。さらに、導入される請求項具陳の特定の数が意図されている場合、そのような意図は、請求項に明示的に具陳されることになり、そのような具陳がない場合、そのような意図は存在しないことが、当業者によって理解されよう。たとえば、ただ１つの項目が意図されている場合、「単一の」という用語または同様の文言が使用され得る。理解の補助として、以下の添付の特許請求の範囲および／または本明細書の説明は、請求項具陳を導入するために、「少なくとも１つの」および「１つまたは複数の」という導入句の使用を含んでいることがある。しかしながら、そのような句の使用は、不定冠詞「ａ」または「ａｎ」による請求項具陳の導入が、そのような導入された請求項具陳を含んでいる何らかの特定の請求項を、ただ１つのそのような具陳を含んでいる実施形態に限定することを暗示すると解釈されるべきではなく、これは、同じ請求項が、「１つまたは複数の」または「少なくとも１つの」という導入句、および「ａ」または「ａｎ」などの不定冠詞を含むときでもそうである（たとえば、「ａ」および／または「ａｎ」は、「少なくとも１つの」または「１つまたは複数の」を意味すると解釈されるべきである）。同じことは、請求項具陳を導入するために使用される定冠詞の使用に当てはまる。加えて、導入される請求項具陳の特定の数が明示的に具陳された場合でも、そのような具陳は、少なくとも具陳された数を意味するように解釈されるべきであることを、当業者は認識されよう（たとえば、他の修正子をもたない、「２つの具陳」という裸の具陳は、少なくとも２つの具陳、または２つ以上の具陳を意味する）。さらに、「Ａ、Ｂ、およびＣなどのうちの少なくとも１つ」に類似の記法が使用される事例では、概して、そのような構文は、当業者が記法を理解するであろう意味において意図されている（たとえば、「Ａ、Ｂ、およびＣのうちの少なくとも１つを有するシステム」は、限定はされないが、Ａのみを有するシステム、Ｂのみを有するシステム、Ｃのみを有するシステム、ＡおよびＢを一緒に有するシステム、ＡおよびＣを一緒に有するシステム、ＢおよびＣを一緒に有するシステム、ならびに／またはＡ、Ｂ、およびＣを一緒に有するシステムなどを含むであろう）。「Ａ、Ｂ、またはＣなどのうちの少なくとも１つ」に類似の記法が使用される事例では、概して、そのような構文は、当業者が記法を理解するであろう意味において意図されている（たとえば、「Ａ、Ｂ、またはＣのうちの少なくとも１つを有するシステム」は、限定はされないが、Ａのみを有するシステム、Ｂのみを有するシステム、Ｃのみを有するシステム、ＡおよびＢを一緒に有するシステム、ＡおよびＣを一緒に有するシステム、ＢおよびＣを一緒に有するシステム、ならびに／またはＡ、Ｂ、およびＣを一緒に有するシステムなどを含むであろう）。さらに、２つ以上の代替的用語を提示するほぼいかなる選言的単語および／または句も、明細書、特許請求の範囲、または図面のいずれの中にあるかとは無関係に、用語のうちの１つ、用語のいずれか、または両方の用語を含んでいる可能性を企図するように理解されるべきであることが、当業者によって理解されよう。たとえば、「ＡまたはＢ」という句は、「Ａ」または「Ｂ」または「ＡおよびＢ」の可能性を含むことが理解されよう。さらに、本明細書で使用される「のいずれか（any of）」という用語と、それに係る複数の項目および／または複数の項目カテゴリーのリスティングは、個々に、または他の項目および／もしくは他の項目カテゴリーと関連して、項目および／または項目カテゴリー「のいずれか」、「の任意の組合せ」、「の任意の複数」、および／または「の複数の任意の組合せ」を含むことが意図されている。その上、本明細書で使用されるとき、「セット」または「グループ」という用語は、０を含む、任意の数の項目を含むことが意図されている。さらに、本明細書で使用されるとき、「数」という用語は、０を含む、任意の数を含むことが意図されている。

【0277】

加えて、本開示の特徴または態様についてマーカッシュグループに関して説明される場合、本開示はまた、それにより、マーカッシュグループの任意の個々のメンバーまたはメンバーのサブグループに関して説明されることを、当業者は認識されよう。

【0278】

当業者によって理解されるように、明細書を提供することに関してなど、ありとあらゆる目的のために、本明細書で開示されるすべての範囲は、ありとあらゆる可能な部分範囲、ならびにそれの部分範囲の組合せをも包含する。任意のリストされた範囲は、同じ範囲が、少なくとも等しい１／２、１／３、１／４、１／５、１／１０などに細分化されることについて十分に説明し、それを可能にするものとして、容易に認識されることが可能である。非限定的な例として、本明細書で論じられる各範囲は、下方の１／３、中央の１／３および上方の１／３などに容易に細分化され得る。当業者によって同じく理解されるように、「までの」、「少なくとも」、「よりも大きい」、「よりも小さい」などのすべての文言は、具陳された数を含み、上記で論じられたように後で部分範囲に細分化されることが可能な範囲を指す。最後に、当業者によって理解されるように、範囲は、各個々のメンバーを含む。したがって、たとえば、１～３個のセルを有するグループは、１個、２個、または３個のセルを有するグループを指す。同様に、１～５個のセルを有するグループは、１個、２個、３個、４個、または５個のセルを有するグループを指す、など。

【0279】

その上、特許請求の範囲は、その趣意の記載がない限り、提供された順序または要素に限定されるものと読み取られるべきではない。加えて、任意の請求項における「のための手段」という用語の使用は、米国特許法第１１２条第６段落またはミーンズプラスファンクションクレームフォーマットを発動することを意図されており、「のための手段」という用語がないすべての請求項は、そのように意図されていない。

【0280】

ソフトウェアに関連するプロセッサは、ワイヤレス送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、端末、基地局、モビリティ管理エンティティ（ＭＭＥ）もしくは発展型パケットコア（ＥＰＣ）、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために使用されてよい。ＷＴＲＵは、ソフトウェア定義無線（ＳＤＲ）を含むハードウェアおよび／またはソフトウェアにおいて実装されたモジュール、ならびにカメラ、ビデオカメラモジュール、ビデオフォン、スピーカーフォン、振動デバイス、スピーカー、マイクロフォン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、ニアフィールド通信（ＮＦＣ）モジュール、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、および／または任意のワイヤレスローカルエリアネットワーク（ＷＬＡＮ）もしくは超広帯域（ＵＷＢ）モジュールなどの他の構成要素と併せて使用されてよい。

【0281】

本開示全体にわたって、当業者であれば、いくつかの代表的な実施形態が、代替形態でまたは他の代表的な実施形態と組み合わせて使用され得ることを理解する。

【0282】

加えて、本明細書で説明される方法は、上記の行為を実施するためにコンピュータまたはプロセッサが実行するための命令としてコンピュータ可読記憶媒体に組み込まれた、コンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてよい。非一時的コンピュータ可読記憶媒体の例は、限定はされないが、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスク、磁気光学媒体などの磁気媒体、ならびにＣＤ－ＲＯＭディスク、およびデジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装するために、ソフトウェアに関連するプロセッサが使用されてよい。

【図1A】

【図1B】

【図1C】

【図1D】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】