特表2022-542852 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ パナソニック　インテレクチュアル　プロパティ　コーポレーション　オブ　アメリカの特許一覧

特表2022-542852送信動作および受信動作を実行するユーザ機器および基地局

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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

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

(11)【公表番号】

(43)【公表日】2022-10-07

(54)【発明の名称】送信動作および受信動作を実行するユーザ機器および基地局

(51)【国際特許分類】

H04W 74/08 20090101AFI20220930BHJP

H04W 16/14 20090101ALI20220930BHJP

H04W 72/04 20090101ALI20220930BHJP

【ＦＩ】

H04W74/08

H04W16/14

H04W72/04 131

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2022503874

(86)(22)【出願日】2020-07-23

(85)【翻訳文提出日】2022-01-19

(86)【国際出願番号】 EP2020070778

(87)【国際公開番号】W WO2021023518

(87)【国際公開日】2021-02-11

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

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

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

(81)【指定国・地域】

【公序良俗違反の表示】

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

１．３ＧＰＰ

(71)【出願人】

【識別番号】514136668

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

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

(74)【代理人】

【識別番号】110002952

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

(72)【発明者】

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

(72)【発明者】

【氏名】鈴木秀俊

(72)【発明者】

【氏名】リホンチャオ

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA11

5K067DD24

5K067DD43

(57)【要約】

本開示は、改良された物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に関与するユーザ機器（ＵＥ）および基地局（ＢＳ）に関する。ＵＥは、受信されたアンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間のシンボルを設定し、ＰＲＡＣＨ送信に使用されるチャネルリソースのタイミングの指示情報を受信し、チャネルリソースの示されたタイミングが、アップリンク通信用に設定されたシンボル内に含まれるか否かを判定し、判定が肯定である場合、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングの開始の前のギャップ期間を対象に、空きチャネル判定（ＣＣＡ）を実行し、成功する場合、アップリンク通信用に設定されたシンボル内で、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングにおいて、ランダムアクセス（ＲＡ）プリアンブルを送信する。
【選択図】図１２

【特許請求の範囲】

【請求項1】

ユーザ機器（ＵＥ）であって、
動作時、受信されたアンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定するプロセッサと、
動作時、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を受信する受信機と、
前記プロセッサが、動作時、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示されたタイミングが、アップリンク通信用に設定された前記少なくとも１個のシンボル内に含まれるか否かを判定し、
前記プロセッサが、動作時、前記判定が肯定である場合、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示されたタイミングの開始の前のギャップ期間を対象に、空きチャネル判定（ＣＣＡ）を実行し、
動作時、前記ＣＣＡが肯定的である場合、アップリンク通信用に設定された前記少なくとも１個のシンボル内で、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示されたタイミングにおいて、ランダムアクセス（ＲＡ）プリアンブルを送信することによって、前記ＰＲＡＣＨ送信を実行する送信機と、
を備えている、ユーザ機器（ＵＥ）。

【請求項2】

前記受信機が、動作時、前記ＰＲＡＣＨ送信を実行する前に前記空きチャネル判定（ＣＣＡ）を実行する対象の前記ギャップ期間の指示情報をさらに受信する、
請求項１に記載のＵＥ。

【請求項3】

前記受信機が動作時に前記ギャップ期間の前記指示情報を受信しない場合、前記プロセッサが、動作時、乱数Ｎを発生させ、前記乱数Ｎに基づいて変化する前記ギャップ期間を対象に前記ＣＣＡを実行する、
請求項１に記載のＵＥ。

【請求項4】

前記ギャップ期間の前記指示情報が、
－複数のギャップ期間のうちの１つのギャップ期間の指示情報、
－複数のリッスンビフォアトーク（ＬＢＴ）カテゴリのうち、１つのギャップ期間と組み合わせて使用される１つのＬＢＴカテゴリの指示情報、および、
－複数のＬＢＴカテゴリのうち一緒に使用される１つのＬＢＴカテゴリの指示情報との組合せにおける、複数のギャップ期間のうちの１つのギャップ期間の指示情報、
の１つである、
請求項１または請求項２に記載のＵＥ。

【請求項5】

前記ギャップ期間が、１６μｓおよび２５μｓの一方であり、かつ前記ＬＢＴカテゴリが、ＬＢＴカテゴリ１、ＬＢＴカテゴリ２、ＬＢＴカテゴリ３、およびＬＢＴカテゴリ４、のうちの１つである、
請求項４に記載のＵＥ。

【請求項6】

前記ギャップ期間の前記指示情報が、ＰＲＡＣＨ送信が実行されないことの指示情報である、
請求項１または請求項２のいずれか１項に記載のＵＥ。

【請求項7】

前記受信機が、動作時、
－時間インスタンスから始まり前記アンライセンスチャネルが占有されている期間にわたる前記占有時間を設定する半静的なシグナリング、および、
－前記シグナリングが受信されたときを基準とする前記占有時間の少なくとも一部を設定する動的シグナリング、
の一方の形における前記アンライセンスチャネルアクセス設定、をさらに受信する、
請求項１から請求項６のいずれか１項に記載のＵＥ。

【請求項8】

前記プロセッサが、動作時、
－チャネルリソースの開始時刻および／または持続時間の形で前記タイミングを示す半静的なシグナリング、
－少なくともいくつかの前に設定されたチャネルリソースに対する有効化／無効化情報の形で前記タイミングを示す動的シグナリング、
－少なくともいくつかのチャネルリソースの開始時刻および／または持続時間の形で前記タイミングを示す動的シグナリング、
のうちの１つから、前記チャネルリソースの前記示されたタイミングを推測する、
請求項１から請求項７のいずれか１項に記載のＵＥ。

【請求項9】

前記プロセッサが、前記示されたタイミングを半静的なシグナリングから推測する場合、前記チャネルリソースの前記示されたタイミングが、前記アンライセンスチャネルの前記占有時間を対象に事前に設定されている、
および／または
前記プロセッサが、前記示されたタイミングを動的シグナリングから推測する場合、有効化／無効化される前記少なくともいくつかの前に設定されたチャネルリソースが、前記シグナリングが受信されたときを基準とする、
および／または
前記プロセッサが、前記示されたタイミングを動的シグナリングから推測する場合、チャネルリソースの前記示されたタイミングが、前記シグナリングが受信されたときを基準とする前記アンライセンスチャネルの前記占有時間の一部を対象とする、
請求項８に記載のＵＥ。

【請求項10】

前記半静的なシグナリングが、それぞれの設定および／または指示情報を伝える情報要素を有する少なくとも１つのブロードキャストシステム情報（ＳＩ）ブロックまたはメッセージまたは専用ＲＲＣメッセージを好ましくは含む、無線リソース制御（ＲＲＣ）シグナリングである、
および／または、
前記動的シグナリングが、
－前記それぞれの設定および／または指示情報を伝える少なくとも１つのＭＡＣ制御要素（ＭＡＣＣＥ）を好ましくは含む媒体アクセス制御（ＭＡＣ）シグナリング、および、
－前記それぞれの設定および／または指示情報を伝える少なくとも１つのダウンリンク制御情報（ＤＣＩ）を好ましくは含む物理（ＰＨＹ）シグナリング、
のうちの一方である、
請求項７から請求項９のいずれか１項に記載のＵＥ。

【請求項11】

前記送信機が、動作時、前記ＣＣＡが否定的である場合、前記チャネルリソースを介して前記ＰＲＡＣＨ送信を実行しない、
請求項１から請求項１０のいずれか１項に記載のＵＥ。

【請求項12】

前記受信機が、動作時、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記タイミングの前記指示情報を、チャネル占有時間（ＣＯＴ）構造情報の形で受信する、
および／または、
前記ＣＯＴ構造情報が、前記占有時間の少なくとも１つのスロットのシンボルを、アップリンク通信またはダウンリンク通信用に前記プロセッサによってそれぞれ設定されるアップリンクシンボル、ダウンリンクシンボル、またはフレキシブルシンボルの１つとして指定する、
および／または、
前記ＣＯＴ構造情報が、前記占有時間の複数のスロットのシンボルを、アップリンクシンボル、ダウンリンクシンボル、またはフレキシブルシンボルの１つとして指定する場合、前記受信機が、動作時、アップリンク通信用の前記アンライセンスチャネルの前記占有時間に関する、部分的に重複する複数のＣＯＴ構造情報を受信する、
請求項１から請求項１１のいずれか１項に記載のＵＥ。

【請求項13】

ユーザ機器（ＵＥ）によって実行される以下のステップを含む方法であって、
受信されたアンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定するステップと、
物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を受信するステップと、
前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示されたタイミングが、アップリンク通信用に設定された前記少なくとも１個のシンボル内に含まれるか否かを判定するステップと、
前記判定が肯定である場合、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示されたタイミングの開始の前のギャップ期間を対象に、空きチャネル判定（ＣＣＡ）を実行するステップと、
前記ＣＣＡが肯定的である場合、アップリンク通信用に設定された前記少なくとも１個のシンボル内で、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示されたタイミングにおいて、ランダムアクセス（ＲＡ）プリアンブルを送信することによって、前記ＰＲＡＣＨ送信を実行するステップと、
を含む、方法。

【請求項14】

基地局（ＢＳ）であって、
動作時、アンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定するプロセッサと、
動作時、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を送信する送信機と、
前記プロセッサが、動作時、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示したタイミングが、アップリンク通信用に設定された前記少なくとも１個のシンボル内に含まれるか否かを判定し、
前記プロセッサが、動作時、前記判定が肯定である場合、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示したタイミングの開始の前にギャップ期間を有する送信ギャップが設定されているか否かを識別し、
動作時、前記送信ギャップの前記識別が肯定である場合、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示したタイミングにおいて、アップリンク通信用に設定された前記少なくとも１個のシンボル内で送信されるランダムアクセス（ＲＡ）プリアンブルの形における前記ＰＲＡＣＨ送信を受信する受信機と、
を備えている、基地局（ＢＳ）。

【請求項15】

基地局（ＢＳ）によって実行される以下のステップを含む方法であって、
アンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定するステップと、
物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を送信するステップと、
前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示したタイミングが、アップリンク通信用に設定された前記少なくとも１個のシンボル内に含まれるか否かを判定するステップと、
前記判定が肯定である場合、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示したタイミングの開始の前にギャップ期間を有する送信ギャップが設定されているか否かを識別するステップと、
前記送信ギャップの前記識別が肯定である場合、前記ＰＲＡＣＨ送信に使用されるチャネルリソースの前記示したタイミングにおいて、アップリンク通信用に設定された前記少なくとも１個のシンボル内で送信されるランダムアクセス（ＲＡ）プリアンブルの形における前記ＰＲＡＣＨ送信を受信するステップと、
を含む、方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、３ＧＰＰ通信システムなどの通信システムにおける方法、装置、および項目を対象としている。

【背景技術】

【0002】

現在、第３世代パートナーシッププロジェクト（３ＧＰＰ：3rd Generation Partnership Project）は、次世代のセルラー技術（第５世代（５Ｇ）とも呼ばれる）の技術仕様に取り組んでいる。

【0003】

１つの目的は、少なくとも拡張モバイルブロードバンド（ｅＭＢＢ：enhanced mobile broadband）、超高信頼・低遅延通信（ＵＲＬＬＣ：ultra-reliable low-latency communications）、大規模マシンタイプ通信（ｍＭＴＣ：massive machine type communication）を含む、あらゆる使用シナリオ、要件、および配置シナリオ（例えばTR 38.913version 15.0.0の６節を参照）に対処する、単一の技術的枠組みを提供することである。例えば、ｅＭＢＢの配置シナリオには、屋内のホットスポット、密集都市部、郊外、都市部、および高速が含まれうる。ＵＲＬＬＣの配置シナリオには、産業制御システム、モバイル健康管理（遠隔モニタリング、遠隔診断、および遠隔治療）、車両のリアルタイム制御、スマートグリッドの広域監視・制御システムが含まれうる。ｍＭＴＣの配置シナリオには、スマートウェアラブルやセンサネットワークなど、遅延の影響が小さいデータ伝送を行う多数の装置を使用するシナリオが含まれうる。ｅＭＢＢサービスとＵＲＬＬＣサービスは、いずれも極めて広い帯域幅が要求される点で似ているが、ＵＲＬＬＣサービスでは、極めて小さいレイテンシ（待ち時間）（latency）が好ましくは要求される点において異なる。

【0004】

第２の目的は、前方互換性を達成することである。ロングタームエボリューション（ＬＴＥ、ＬＴＥ－Ａ）セルラーシステムへの後方互換性は要求されず、これにより、まったく新しいシステムの設計および／または新しい機能の導入が容易になる。

【発明の概要】

【0005】

本発明を制限することのない例示的な一実施形態は、アンライセンスチャネルを通じてＰＲＡＣＨ送信を実行する（すなわちアンライセンスチャネルの占有時間内にＰＲＡＣＨ送信を実行する）ための改良された手順を提供することを促進する。

【0006】

一実施形態においては、本明細書に開示されている技術は、プロセッサ、受信機、および送信機を備えたユーザ機器（ＵＥ）を提供する。プロセッサは、動作時、受信されたアンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定する。受信機は、動作時、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を受信する。プロセッサは、動作時、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングが、アップリンク通信用に設定された少なくとも１個のシンボル内に含まれるか否かを判定する。プロセッサは、動作時、判定が肯定である場合、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングの開始の前のギャップ期間を対象に、空きチャネル判定（ＣＣＡ：clear channel assessment）を実行する。送信機は、動作時、ＣＣＡが肯定的である場合、アップリンク通信用に設定された少なくとも１個のシンボル内で、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングにおいて、ランダムアクセス（ＲＡ）プリアンブルを送信することによって、ＰＲＡＣＨ送信を実行する。

【0007】

なお、一般的な実施形態または具体的な実施形態は、システム、方法、集積回路、コンピュータプログラム、記憶媒体、またはこれらの任意の選択的な組合せとして、実施できることに留意されたい。

【0008】

開示されている実施形態および様々な実装形態のさらなる恩恵および利点は、本明細書および図面から明らかになるであろう。これらの恩恵および／または利点は、本明細書および図面の様々な実施形態および特徴によって個別に得ることができ、ただしこのような恩恵および／または利点の１つまたは複数を得るために、これらの特徴すべてを設ける必要はない。

【0009】

以下では、例示的な実施形態について、添付の図面を参照しながらさらに詳しく説明する。

【図面の簡単な説明】

【0010】

【図1】５Ｇコアネットワーク（５ＧＣ：5G Core network）および次世代無線アクセスネットワーク（ＮＧ－ＲＡＮ：Next Generation Radio Access Network）を含む３ＧＰＰ５Ｇシステムの例示的なアーキテクチャを示している。

【図2】ｇＮＢを含む５Ｇシステムが、ｅＮＢを含むＬＴＥシステムと一緒に配置されている例示的な非中央集中型配置シナリオを描いてある。

【図3】次世代無線アクセスネットワーク（ＮＧ－ＲＡＮ）および５Ｇコアネットワーク（５ＧＣ）によって提供される機能間の機能分割を概略的に示している。

【図4】３ＧＰＰ５Ｇシステムにおける無線リソース制御（ＲＲＣ）接続の確立／再確立手順をシーケンス図として示している。

【図5】拡張モバイルブロードバンド（ｅＭＢＢ）、大規模マシンタイプ通信（ｍＭＴＣ）、および超高信頼・低遅延通信（ＵＲＬＬＣ）の使用シナリオを概略的に描いてある。

【図6】非ローミングシナリオ向けの３ＧＰＰの５Ｇサービスベースアーキテクチャ（ＳＢＡ：service based architecture）のブロック図を例示的に示している。

【図7】ＰＲＡＣＨの例示的な設定（すなわちパラメータｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ＝２２、かつパラメータｍｓｇ１－ＦＤＭ＝２の場合の設定）を示している。

【図8】ＤＬからＵＬへの単一のスイッチングポイントを含みかつスイッチングギャップを備えた、ｇＮＢのチャネル占有時間（ＣＯＴ：channel occupancy time）の例示的なフレーム構造を描いてある。

【図9】ＵＥおよびｇＮＢの例示的な単純化した構造を示している。

【図10】それぞれ、改良されたＰＲＡＣＨ送信動作の一般的なシナリオによる、ｇＮＢおよびＵＥの例示的な単純化した構造を示している。

【図11】それぞれ、改良されたＰＲＡＣＨ送信動作の一般的なシナリオによる、ｇＮＢおよびＵＥの例示的な単純化した構造を示している。

【図12】それぞれ、改良されたＰＲＡＣＨ送信動作の一般的なシナリオによる、ＵＥおよびｇＮＢの動作の流れ図を描いてある。

【図13】それぞれ、改良されたＰＲＡＣＨ送信動作の一般的なシナリオによる、ＵＥおよびｇＮＢの動作の流れ図を描いてある。

【図14】改良されたＰＲＡＣＨ送信動作の第１の例示的な実装形態に係る、ＵＥの動作の流れ図を示している。

【図15】ＵＥが、第１の例示的な実装形態に係る改良されたＰＲＡＣＨ送信動作を実行する場合の、占有時間の例示的なチャネルリソースの設定を示している。

【図16】ＵＥが、第１の例示的な実装形態に係る改良されたＰＲＡＣＨ送信動作を実行する場合の、占有時間の別の例示的なチャネルリソースの設定を示している。

【図17】改良されたＰＲＡＣＨ送信動作の第２の例示的な実装形態に係る、ＵＥの動作の流れ図を示している。

【図18】ＵＥが、第２の例示的な実装形態に係る改良されたＰＲＡＣＨ送信動作を実行する場合の、占有時間の例示的なチャネルリソースの設定を示している。

【図19】ＵＥが、第２の例示的な実装形態に係る改良されたＰＲＡＣＨ送信動作を実行する場合の、占有時間の別の例示的なチャネルリソース設定を示している。

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

【0011】

［５ＧＮＲシステムのアーキテクチャおよびプロトコルスタック］
第３世代パートナーシッププロジェクト（３ＧＰＰ）は、最大１００ＧＨｚの周波数で動作する新しい無線アクセス技術（ＮＲ）の開発を含む第５世代セルラー技術（単に５Ｇと呼ばれる）の次のリリースに取り組んでいる。５Ｇ標準の最初のバージョンは、２０１７年の終わりに完了し、これにより、５ＧＮＲ標準に準拠したスマートフォンの試験および商用展開に進むことができる。

【0012】

特に、全体的なシステムアーキテクチャは、ｇＮＢを備えるＮＧ－ＲＡＮ（次世代－無線アクセスネットワーク：Next Generation － Radio Access Network）を想定しており、これらのｇＮＢは、ＵＥに向かうＮＧ無線アクセスユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）プロトコルおよび制御プレーン（ＲＲＣ）プロトコルを終端させる。

【0013】

ｇＮＢは、Ｘｎインタフェースによって互いに相互接続されている。さらにｇＮＢは、次世代（ＮＧ）インタフェースによってＮＧＣ（次世代コア：Next Generation Core）に接続され、より具体的には、ＮＧ－ＣインタフェースによってＡＭＦ（アクセスおよびモビリティ管理機能：Access and Mobility Management Function）（例：ＡＭＦを実行する特定のコアエンティティ）に接続され、ＮＧ－ＵインタフェースによってＵＰＦ（ユーザプレーン機能：User Plane Function）（例：ＵＰＦを実行する特定のコアエンティティ）に接続される。

【0014】

図１は、ＮＧ－ＲＡＮのアーキテクチャを示している（例えば3GPP TS 38.300 v15.6.0の４節を参照）。

【0015】

様々な異なる配置シナリオをサポートすることができる（例えば3GPP TR 38.801 v14.0.0を参照）。この文献には、例えば、非中央集中型の配置シナリオが提示されており（例えば3GPP TR 38.801 v14.0.0の５．２節を参照、中央集中型は５．４節に記載されている）、このシナリオでは、５ＧＮＲをサポートする基地局を配置することができる。

【0016】

図２は、例示的な非中央集中型の配置シナリオを示しており（3GPP TR 38.801 v14.0.0の例えば図５．２．－１を参照）、ＬＴＥｅＮＢおよびユーザ機器（ＵＥ）をさらに示しており、ユーザ機器（ＵＥ）は、ｇＮＢおよびＬＴＥｅＮＢの両方に接続されている。ＮＲ５Ｇの新しいｅＮＢは、例示的にｇＮＢと呼ぶことができる。ｅＬＴＥｅＮＢは、ｅＮＢの進化型であり、ＥＰＣ（進化型パケットコア（Evolved Packet Core））およびＮＧＣ（次世代コア）への接続性をサポートする。

【0017】

ＮＲにおけるユーザプレーンプロトコルスタック（例えば3GPP TS 38.300 v15.6.0の４．４．１節を参照）は、ＰＤＣＰ（パケットデータコンバージェンスプロトコル：Packet Data Convergence Protocol、3GPP TS 38.300 v15.6.0の６．４節を参照）サブレイヤ、ＲＬＣ（無線リンク制御：Radio Link Control、3GPP TS 38.300 v15.6.0の６．３節を参照）サブレイヤ、およびＭＡＣ（媒体アクセス制御：Medium Access Control、3GPP TS 38.300 v15.6.0の６．２節を参照）サブレイヤを含み、これらのサブレイヤは、ネットワーク側ではｇＮＢにおいて終端する。これに加えて、ＰＤＣＰの上に、アクセス層（ＡＳ）の新しいサブレイヤ（ＳＤＡＰ：サービスデータアダプテーションプロトコル：Service Data Adaptation Protocol）が導入される（例えば3GPP TS 38.300 v15.6.0の６．５節を参照）。

【0018】

ＮＲにおいても制御プレーンプロトコルスタックが定義されている（例えば3GPP TS 38.300 v15.6.0の４．４．２節を参照）。レイヤ２の機能の概要は、3GPP TS 38.300 v15.6.0の６節に記載されている。ＰＤＣＰサブレイヤ、ＲＬＣサブレイヤ、およびＭＡＣサブレイヤの機能は、それぞれ3GPP TS 38.300 v15.6.0の６．４節、６．３節、および６．２節に記載されている。ＲＲＣレイヤの機能は、3GPP TS 38.300 v15.6.0の７節に記載されている。

【0019】

媒体アクセス制御層（ＭＡＣ）は、例えば、論理チャネルの多重化と、スケジューリングおよびスケジューリング関連機能（様々なヌメロロジーの処理を含む）を扱う。

【0020】

物理層（ＰＨＹ）は、例えば、符号化、ＰＨＹＨＡＲＱ処理、変調、マルチアンテナ処理、適切な物理時間－周波数リソースへの信号のマッピングの責務を担う。さらに物理層（ＰＨＹ）は、物理チャネルへのトランスポートチャネルのマッピングを処理する。物理層（ＰＨＹ）は、トランスポートチャネルの形でＭＡＣ層にサービスを提供する。

【0021】

トランスポートチャネルの送信には、時間周波数リソースのセットに対応する物理チャネルが使用される。各トランスポートチャネルが、対応する物理チャネルにマッピングされる。１つの物理チャネルは、ランダムアクセスに使用されるＰＲＡＣＨ（物理ランダムアクセスチャネル）である。

【0022】

ＮＲのユースケース／配置シナリオには、拡張モバイルブロードバンド（ｅＭＢＢ）、超高信頼・低遅延通信（ＵＲＬＬＣ）、大規模マシンタイプ通信（ｍＭＴＣ）が含まれ、これらのサービスは、データレート、レイテンシ、およびカバレッジに関して多様な要件を有する。例えばｅＭＢＢは、ＩＭＴ－Ａｄｖａｎｃｅｄによって提供される３倍のオーダーのピークデータレート（ダウンリンクが２０Ｇｂｐｓ、アップリンクが１０Ｇｂｐｓ）およびユーザ体感データレートをサポートすることが期待される。これに対してＵＲＬＬＣの場合、より厳しい要件として、極めて低いレイテンシ（ユーザプレーンのレイテンシはアップリンクおよびダウンリンクそれぞれで０．５ｍｓ）および高い信頼性（１ｍｓ内で１～１０^－５）が課せられる。さらにｍＭＴＣでは、高い接続密度（都市環境では１ｋｍ^２あたり１，０００，０００個のデバイス）、過酷な環境における広いカバレッジ、デバイスコストを下げるための極めて長寿命のバッテリ（１５年）が好ましくは要求されうる。

【0023】

したがって、あるユースケースに適したＯＦＤＭヌメロロジー（例：サブキャリア間隔、ＯＦＤＭシンボル持続時間、サイクリックプレフィックス（ＣＰ）持続時間、スケジューリング間隔あたりのシンボル数）が、別のユースケースではうまく機能しないことがある。

【0024】

例えば、低レイテンシのサービスでは、ｍＭＴＣサービスよりも短いシンボル持続時間（したがってより大きいサブキャリア間隔）、および／または、スケジューリング間隔（ＴＴＩとも称される）あたりの少ないシンボル、が好ましくは要求されうる。さらには、チャネルの遅延スプレッドが大きい配置シナリオでは、遅延スプレッドが短いシナリオよりも長いサイクリックプレフィックス（ＣＰ）持続時間が好ましくは要求されうる。同程度のサイクリックプレフィックス（ＣＰ）オーバーヘッドを維持するため、遅延スプレッドに応じてサブキャリア間隔を最適化するべきである。ＮＲでは、サブキャリア間隔の２つ以上の値がサポートされうる。したがって現在のところ、１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ、．．．のサブキャリア間隔が検討されている。シンボル持続時間Ｔ_ｕとサブキャリア間隔Δｆは、式Δｆ＝１／Ｔ_ｕにより、直接関係している。ＬＴＥシステムの場合と同様に、１個のＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する１つのサブキャリアから構成される最小リソース単位を表すのに、用語「リソースエレメント」を使用することができる。

【0025】

新しい無線システム５ＧＮＲでは、各ヌメロロジーおよびキャリアごとに、アップリンクおよびダウンリンクそれぞれにおいて、サブキャリアとＯＦＤＭシンボルのリソースグリッドが定義される。リソースグリッド内の各要素は、リソースエレメントと呼ばれ、周波数領域における周波数インデックスと時間領域におけるシンボル位置とに基づいて識別される（3GPP TS 38.211 v15.6.0を参照）。

【0026】

［ＮＧ－ＲＡＮと５ＧＣの間の５ＧＮＲ機能の分割］
図３は、ＮＧ－ＲＡＮと５ＧＣとの間での機能の分割を示している。ＮＧ－ＲＡＮの論理ノードは、ｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣの論理ノードは、ＡＭＦ、ＵＰＦ、およびＳＭＦである。

【0027】

ｇＮＢおよびｎｇ－ｅＮＢは、特に次の主要機能を処理する。
－無線ベアラ制御（Radio Bearer Control）、無線アドミッション制御（Radio Admission Control）、接続モビリティ制御（Connection Mobility Control）、アップリンクおよびダウンリンクの両方向におけるＵＥへの動的なリソース割当て（スケジューリング）など、無線リソース管理（Radio Resource Management）の機能
－ＩＰヘッダ圧縮、暗号化、およびデータの整合性保護
－ＵＥによって提供される情報からＡＭＦへのルーティングを決定できないときのＵＥのアタッチ時のＡＭＦの選択
－ＵＰＦへのユーザプレーンデータのルーティング
－ＡＭＦへの制御プレーン情報のルーティング
－接続の確立および解放
－ページングメッセージのスケジューリングおよび送信
－（ＡＭＦまたはＯＡＭから送信される）システムブロードキャスト情報のスケジューリングおよび送信
－モビリティおよびスケジューリングのための測定および測定報告の設定
－アップリンクにおけるトランスポートレベルのパケットマーキング
－セッション管理
－ネットワークスライシングのサポート
－ＱｏＳフロー管理およびデータ無線ベアラへのマッピング
－ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート
－ＮＡＳメッセージの配信機能
－無線アクセスネットワークシェアリング
－デュアルコネクティビティ
－ＮＲとＥ－ＵＴＲＡ間の緊密なインターワーキング

【0028】

アクセスおよびモビリティ管理機能（ＡＭＦ）は、次の主要機能を処理する。
－非アクセス層（ＮＡＳ：Non-Access Stratum）シグナリングの終端
－ＮＡＳシグナリングのセキュリティ
－アクセス層（ＡＳ：Access Stratum）のセキュリティ制御
－３ＧＰＰアクセスネットワーク間のモビリティのためのコアネットワーク（ＣＮ：ＣｏｒｅＮｅｔｗｏｒｋ）ノード間シグナリング
－アイドルモードＵＥの到達可能性（ページング再送の制御および実行を含む）
－レジストレーションエリア（Registration Area）管理
－システム内モビリティおよびシステム間モビリティのサポート
－アクセス認証
－ローミング権のチェックを含むアクセス認証
－モビリティ管理制御（サブスクリプションおよびポリシー）
－ネットワークスライシングのサポート
－セッション管理機能（ＳＭＦ：Session Management Function）の選択

【0029】

さらに、ユーザプレーン機能（ＵＰＦ：User Plane Function）は、次の主要機能を処理する。
－ＲＡＴ内／ＲＡＴ間モビリティのためのアンカーポイント（適用可能時）
－データネットワークとの相互接続の外部ＰＤＵセッションポイント
－パケットのルーティングおよび転送
－パケット検査およびポリシールール施行のユーザプレーン部分
－トラフィック使用報告
－データネットワークへのトラフィックフローのルーティングをサポートするためのアップリンク分類器
－マルチホームＰＤＵセッションをサポートするためのブランチングポイント
－ユーザプレーンのＱｏＳ処理（例：パケットフィルタリング、ゲーティング、ＵＬ／ＤＬレート強制）
－アップリンクトラフィックの検証（ＳＤＦからＱｏＳフローへのマッピング）
－ダウンリンクパケットバッファリングおよびダウンリンクデータ通知トリガリング

【0030】

最後に、セッション管理機能（ＳＭＦ）は、次の主要機能を処理する。
－セッション管理
－ＵＥＩＰアドレスの割当ておよび管理
－ＵＰ機能の選択および制御
－トラフィックを正しい宛先にルーティングするためのユーザプレーン機能（ＵＰＦ）におけるトラフィックステアリングの設定
－ポリシー施行およびＱｏＳの制御部分
－ダウンリンクデータ通知

【0031】

［ＲＲＣ接続の確立および再設定手順］
図４は、ＵＥがＲＲＣ＿ＩＤＬＥからＲＲＣ＿ＣＯＮＮＥＣＴＥＤに移行するときの、ＮＡＳ部分における、ＵＥ、ｇＮＢ、ＡＭＦ（５ＧＣエンティティ）の間のインタラクションを示している（3GPP TS 38.300 v15.6.0を参照）。

【0032】

ＲＲＣは、ＵＥおよびｇＮＢの設定に使用される上位層シグナリング（プロトコル）である。特に、この移行では、ＡＭＦがＵＥコンテキストデータ（例：ＰＤＵセッションコンテキスト、セキュリティキー、ＵＥ無線能力、ＵＥセキュリティ能力などを含む）を準備し、それを初期コンテキストセットアップ要求（ＩＮＩＴＩＡＬＣＯＮＴＥＸＴＳＥＴＵＰＲＥＱＵＥＳＴ）によってｇＮＢに送る。次にｇＮＢが、ＵＥとのＡＳセキュリティをアクティブにし、これはｇＮＢがＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｍａｎｄメッセージをＵＥに送信し、ＵＥがＳｅｃｕｒｉｔｙＭｏｄｅＣｏｍｐｌｅｔｅメッセージでｇＮＢに応答することによって実行される。

【0033】

その後ｇＮＢは、シグナリング無線ベアラ２（ＳＲＢ２）およびデータ無線ベアラ（ＤＲＢ）を確立するために再設定を実行し、これは、ｇＮＢがＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＵＥに送信し、これに応答してＵＥからのＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅをｇＮＢが受信することによる。シグナリングのみの接続の場合、ＳＲＢ２およびＤＲＢが確立されないため、ＲＲＣＲｅｃｏｎｆｉｇｕｒａｔｉｏｎに関連するこれらのステップはスキップされる。最後にｇＮＢは、確立手順が完了したことを、初期コンテキストセットアップ応答（ＩＮＩＴＩＡＬＣＯＮＴＥＸＴＳＥＴＵＰＲＥＳＰＯＮＳＥ）によってＡＭＦに通知する。

【0034】

したがって本開示では、第５世代コア（５ＧＣ）のエンティティ（例えばＡＭＦ、ＳＭＦなど）が提供され、このエンティティは、ｇＮｏｄｅＢとユーザ機器（ＵＥ）との間にシグナリング無線ベアラが確立されるように、動作時にｇＮｏｄｅＢとの次世代（ＮＧ）接続を確立する制御回路と、動作時にそのＮＧ接続を介して初期コンテキストセットアップメッセージをｇＮｏｄｅＢに送信する送信機とを備えている。特に、ｇＮｏｄｅＢは、リソース割当て設定情報要素を含む無線リソース制御（ＲＲＣ）シグナリングをシグナリング無線ベアラを介してＵＥに送信する。次いでＵＥが、このリソース割当て設定に基づいてアップリンク送信またはダウンリンク受信を実行する。

【0035】

［ＩＭＴ－２０２０以降の使用シナリオ］
図５は、５ＧＮＲのユースケースのいくつかを示している。３ＧＰＰ新無線（３ＧＰＰＮＲ）では、初期のＩＭＴ－２０２０によって想定される様々なサービスおよびアプリケーションをサポートする３つのユースケースが考慮されている。拡張モバイルブロードバンド（ｅＭＢＢ）のフェーズ１の仕様は決定された。現在および今後の作業としては、ｅＭＢＢのサポートをさらに拡張することに加えて、２０２０年以降の超高信頼・低遅延通信（ＵＲＬＬＣ）および大規模マシンタイプ通信の標準化が含まれる。

【0036】

ＵＲＬＬＣのユースケースは、スループット、レイテンシ、可用性などの能力に関する厳しい要件を有し、産業製造や生産プロセスのワイヤレス制御、リモート医療手術、スマートグリッドにおける配電自動化、輸送の安全性など、将来の垂直アプリケーションを実現する手段の１つとして想定されている。ＵＲＬＬＣの超高信頼性は、TR 38.913version 15.0.0によって設定される要件を満たすための技術を特定することによってサポートされる。

【0037】

上記の厳しい要件とは、ユースケースに応じて、より高い信頼性（最大１０－６レベル）、より高い可用性、最大２５６バイトのパケットサイズ、数μｓ（値は周波数範囲に応じて１～数μｓ）のオーダーの時間同期、０．５～１ｍｓのオーダーの短いレイテンシ（特にユーザプレーンの目標レイテンシは０．５ｍｓ）である。パケットの１回の送信における一般的なＵＲＬＬＣの要件は、１ｍｓのユーザプレーンレイテンシでパケットサイズ３２バイトの場合にＢＬＥＲ（ブロック誤り率）１Ｅ－５である。

【0038】

さらに、ＮＲＵＲＬＬＣの場合、ＲＡＮ１の観点からいくつかの技術強化が認識されている。特に、コンパクトなＤＣＩ、ＰＤＣＣＨの繰り返し、ＰＤＣＣＨ監視の増大、に関連するＰＤＣＣＨ（物理ダウンリンク制御チャネル）の強化が挙げられる。さらに、ＵＣＩ（アップリンク制御情報）の強化は、ＨＡＲＱ（ハイブリッド自動再送要求）の強化およびＣＳＩフィードバックの強化に関連する。また、ミニスロットレベルのホッピングおよび再送信／繰り返しに関連するＰＵＳＣＨの強化も認識されている。用語「ミニスロット」は、スロット（１４個のシンボルを含むスロット）より少ない数のシンボルを含む送信時間間隔（ＴＴＩ：Transmission Time Interval）を意味する。

【0039】

しかしながら、（ＮＲＵＲＬＬＣの重要な要件について）ＮＲがさらに安定し、開発が進むにつれて、超高信頼性を実現するための範囲が広がりうる。リリース１５におけるＮＲＵＲＬＬＣの具体的なユースケースとしては、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅ－ヘルス、ｅ－セーフティ、ミッションクリティカルなアプリケーションが挙げられる。

【0040】

さらに、ＮＲＵＲＬＬＣが対象とする技術強化は、レイテンシの改善および信頼性の向上を目標としている。レイテンシを改善するための技術強化としては、設定可能なヌメロロジー、柔軟なマッピングを使用する非スロットベースのスケジューリング、グラントフリー（設定済みグラント（configured grant））のアップリンク、データチャネルのスロットレベルの繰り返し、およびダウンリンクのプリエンプションが挙げられる。プリエンプションとは、リソースがすでに割り当てられている送信が中止され、すでに割り当てられているリソースが、後から要求された、より小さいレイテンシ／より高い優先度要件を有する別の送信に使用されることを意味する。したがって、すでに許可された送信が、より後の送信によってプリエンプトされる。プリエンプションは、特定のサービスタイプに関係なく適用される。例えば、サービスタイプＡ（ＵＲＬＬＣ）の送信を、サービスタイプＢ（ｅＭＢＢなど）の送信によってプリエンプトすることができる。信頼性向上に関連する技術強化としては、１Ｅ－５の目標ＢＬＥＲのための専用ＣＱＩ／ＭＣＳテーブルが挙げられる。

【0041】

ｍＭＴＣ（大規模マシンタイプ通信）のユースケースは、非常に多数の接続されたデバイスが、一般には遅延の影響が小さい比較的少量のデータを送信することを特徴とする。デバイスは、低コストでありかつ極めて長いバッテリ寿命を有する必要がある。ＮＲの観点からは、非常に狭い帯域幅部分を利用することは、ＵＥの観点からの省電力を達成して長いバッテリ寿命を可能にするための１つの可能な解決策である。

【0042】

上に述べたように、ＮＲにおける信頼性の範囲が広がることが予測される。あらゆるケース、特にＵＲＬＬＣおよびｍＭＴＣの場合に必要な１つの重要な要件は、高信頼性または超高信頼性である。無線の観点およびネットワークの観点から、信頼性を向上させるためのいくつかのメカニズムを考えることができる。一般には、信頼性の向上に役立つ可能性のある重要な領域がいくつか存在する。これらの領域としては、コンパクトな制御チャネル情報、データチャネル／制御チャネルの繰り返し、周波数領域、時間領域、および／または空間領域に関連するダイバーシチが挙げられる。これらの領域は、特定の通信シナリオには関係なく、一般的に信頼性に適用可能である。

【0043】

［ＱｏＳの制御］
５ＧＱｏＳ（サービス品質）モデルは、ＱｏＳフローに基づいており、保証フロービットレートを必要とするＱｏＳフロー（ＧＢＲＱｏＳフロー）と、保証フロービットレートを必要としないＱｏＳフロー（非ＧＢＲＱｏＳフロー）の両方をサポートする。したがってＮＡＳレベルでは、ＱｏＳフローはＰＤＵセッションにおけるＱｏＳ差別化の最も細かい粒度である。ＱｏＳフローは、ＰＤＵセッション内では、ＮＧ－Ｕインタフェースを通じてカプセル化ヘッダ内で伝えられるＱｏＳフローＩＤ（ＱＦＩ）によって識別される。

【0044】

５ＧＣは、各ＵＥごとに１つまたは複数のＰＤＵセッションを確立する。ＮＧ－ＲＡＮは、各ＵＥごとに、ＰＤＵセッションと一緒に少なくとも１つのデータ無線ベアラ（ＤＲＢ）を確立し、次にそのＰＤＵセッションのＱｏＳフローのための追加のＤＲＢを、例えば図４を参照しながら上述したように設定することができる（いつ設定するかはＮＧ－ＲＡＮが決定する）。ＮＧ－ＲＡＮは、異なるＰＤＵセッションに属するパケットを異なるＤＲＢにマッピングする。ＵＥおよび５ＧＣにおけるＮＡＳレベルのパケットフィルタが、ＵＬおよびＤＬパケットをＱｏＳフローに関連付け、ＵＥおよびＮＧ－ＲＡＮにおけるＡＳレベルのマッピング規則が、ＵＬおよびＤＬのＱｏＳフローをＤＲＢに関連付ける。

【0045】

図６は、５ＧＮＲの非ローミング基準アーキテクチャ（TS 23.501 v16.1.0の４．２３節を参照）を示している。アプリケーション機能（ＡＦ：Application Function）（例えば図５に例示的に記載されている５Ｇサービスを処理する外部アプリケーションサーバ）は、サービスを提供する目的で、３ＧＰＰコアネットワークと対話する。例えば、トラフィックのルーティングに対するアプリケーションの影響をサポートしたり、ネットワーク公開機能（ＮＥＦ：Network Exposure Function）にアクセスする、またはポリシー制御（例：ＱｏＳ制御）のためのポリシーフレームワーク（ポリシー制御機能ＰＣＦを参照）と対話する。事業者の配備に基づいて、事業者によって信頼されるものとみなされるアプリケーション機能（ＡＦ）を、関連するネットワーク機能（Network Function）と直接対話できるようにすることができる。ネットワーク機能に直接アクセスすることが事業者によって許可されていないアプリケーション機能（ＡＦ）は、ＮＥＦを介して外部の公開フレームワークを使用して、関連するネットワーク機能と対話する。

【0046】

さらに、５Ｇアーキテクチャの機能ユニットとして、ネットワークスライス選択機能（ＮＳＳＦ：Network Slice Selection Function）、ネットワークリポジトリ機能（ＮＲＦ：Network Repository Function）、統一データ管理（ＵＤＭ：Unified Data Management）、認証サーバ機能（ＡＵＳＦ：Authentication Server Function）、アクセスおよびモビリティ管理機能（ＡＭＦ：Access and Mobility Management Function）、セッション管理機能（ＳＭＦ：Session Management Function）、およびデータネットワーク（ＤＮ：Data Network）（例：事業者のサービス、インターネットアクセス、またはサードパーティのサービス）を示してある。

【0047】

［ランダムアクセス手順］
５ＧＮＲでは、ＵＥがＮＧ－ＲＡＮシステムのセルへの最初のアクセスを行うことができるように、ランダムアクセスチャネル送信が考案されている。このようなランダムアクセス送信は、規定されたシーケンスで、すなわちランダムアクセス手順に従って実行される。ランダムアクセスチャネル手順は標準化されており（例えば3GPP TS38.321 v.15.6.0の５．１節を参照）、以下の説明では、個々の側面の大まかな概要のみを示す。

【0048】

ＵＥがセルを見つけると、そのセルにアクセスすることができる。これは、ランダムアクセス手順を使用して行うことができる。この手順は４つの「ステップ」から構成される。最初のステップでは、ＵＥが、物理ランダムアクセスチャネル（ＰＲＡＣＨ）でランダムアクセス（ＲＡ）プリアンブル（略してプリアンブル）をｇＮＢに送信する（ＲＡ手順のメッセージ１）。ｇＮＢは、ＲＡプリアンブルを検出すると、第２のステップにおいて、ランダムアクセス応答（ＲＡＲ：Random Access Response）メッセージ（ＲＡ手順のメッセージ２）をＰＤＳＣＨ（物理ダウンリンク共有チャネル）で送信する。ＲＡＲメッセージの前に、ＲＡＲメッセージをスケジューリングする、（ランダムアクセス）ＲＡ－ＲＮＴＩを有する制御情報がＰＤＣＣＨで送信される。

【0049】

ＲＡＲメッセージは、検出されたＲＡプリアンブルと、以降のアップリンク送信を同期するためのタイムアライメントコマンド（ＴＡコマンド）と、最初のスケジューリングされた送信用の初期アップリンクリソース割当て（ＵＬグラント）と、一時セル無線ネットワーク一時識別子（Ｔ－ＣＲＮＴＩ）の割当て、を伝える。このＴ－ＣＲＮＴＩは、ＲＡＣＨ手順が終了するまでＵＥにアドレッシングする目的でｇＮＢが使用するものであり、なぜならこの時点ではｇＮＢはＵＥの「真の」ＩＤを認識していないためである。

【0050】

第３のステップおよび第４のステップ（ＲＡ手順のメッセージ３／４）は、潜在的な衝突を解決することを目的として提供されている。このような衝突は、２基のＵＥが同じＰＲＡＣＨリソースで同じＲＡプリアンブルを送信する場合に起こる（例：衝突する場合）。この場合、ｇＮＢは、２つの送信間の干渉によりＲＡプリアンブルの受信に失敗するか、または１つのＲＡプリアンブルのみ正常に受信する。しかしながら後者の場合、ｇＮＢは２基のＵＥを区別することができない。したがってｇＮＢは、１つのＵＬグラントを含む１つのＲＡＲメッセージで応答し、このＲＡＲメッセージが２基のＵＥによって受信される。

【0051】

ＵＥは、ｇＮＢによって設定される所与の時間ウィンドウ（例：ＲＡＲ時間ウィンドウと称される）の中でＰＤＣＣＨを監視してＲＡＲメッセージを受信する。ＵＥは、示されたＵＬグラントを使用して、最初のスケジューリングされたアップリンク送信（ＲＡ手順のメッセージ３）を、割り当てられた無線リソースにおいて実行する。このスケジューリングされたアップリンク送信は、例えばＲＲＣ接続要求やＲＲＣ再開要求などの実際のＲＲＣメッセージを伝える。

【0052】

これに応答してｇＮＢは、第２の実際のＲＲＣメッセージ（ＲＡ手順のメッセージ４）をＰＤＳＣＨを介して送信し、ＲＡ手順が成功した場合、このメッセージによりＵＥがＲＲＣ接続状態に移行する。このスケジューリングされたダウンリンク送信の前に、それぞれのＲＲＣメッセージをスケジューリングするＤＬ割当てを含む制御情報がＰＤＣＣＨで送信される。このＲＲＣメッセージはＲＲＣセットアップ（RRC Setup）メッセージまたはＲＲＣ再開（RRC Resume）メッセージとすることができる。

【0053】

衝突する場合に戻る。１つのＲＡＲメッセージを受信した２基のＵＥは、そのＲＡＲメッセージからの１つのＵＬグラントを使用してＲＡ手順のメッセージ３を送信する。２基のＵＥがＲＡＲメッセージからの同じＴ－ＣＲＮＴＩを使用して動作しているため、当然ながらこの送信は失敗する。２つのアップリンク送信間の干渉のレベルに応じて、２つの送信のいずれもｇＮＢによって正常に受信されないか、または多くても一方の送信のみがｇＮＢによって受信される。この場合、タイマー有効期間メカニズム（3GPP TS38.331 v.15.6.0の７．１節を参照）など従来の公知のメカニズムによって、衝突の検出と対応する解決が可能になる。

【0054】

［物理ランダムアクセスチャネル］
物理ランダムアクセスチャネルは、時間－周波数リソースに基づいて指定され、すなわちＲＡプリアンブル（ＲＡ手順のメッセージ１）を伝えることを目的としたリソースである。このようなリソースは、ＰＲＡＣＨオケージョン（PRACH occasion）とも称される。これは、ＰＲＡＣＨのリソースが単にＲＡプリアンブルの送信のための機会であることを強調している。しかしながら、ＲＡプリアンブルの送信に実際に使用されるのは、リソースのごく一部にすぎない。

【0055】

５ＧＮＲではランダムアクセスプリアンブルは次のように規定されている、すなわちランダムアクセスプリアンブルは、表６．３．３．２－２～表６．３．３．２－４に従って上位層パラメータｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘによって与えられる時間リソースでのみ送信することができ、ＦＲ１またはＦＲ２（例えば3GPP TS 38.211 v15.6.0の６．３．３．２節を参照）と、ペア化スペクトルまたは非ペア化スペクトルの一方に対応するスペクトルタイプとに依存する（例えばTS38.104を参照）。

【0056】

ランダムアクセスプリアンブルは、上位層パラメータｍｓｇ１－ＦｒｅｑｕｅｎｃｙＳｔａｒｔによって与えられる周波数リソースでのみ送信することができる。ＰＲＡＣＨ周波数リソースｎ_ＲＡ∈｛０，１，．．．，Ｍ－１｝（Ｍは上位層パラメータｍｓｇ１－ＦＤＭに等しい）は、最初のアクセス時の初期アップリンク帯域幅部分の中で、最低周波数から昇順で番号が付けられる。それ以外の場合、ｎ_ＲＡは、アクティブなアップリンク帯域幅部分の中で最低周波数から昇順で番号が付けられる。

【0057】

表におけるスロット番号付けでは、次のサブキャリア間隔が想定される。
－ＦＲ１の場合は１５ｋＨｚ
－ＦＲ２の場合は６０ｋＨｚ
ペア化または非ペア化スペクトルでありＬ_ｍａｘ＝４を使用するターゲットセルへのハンドオーバーを目的とする場合、ＵＥは、TS 38.213の８．１節のアソシエーションパターン期間が１０ｍｓに等しくない場合、現在のセルにおける無線フレームｉとターゲットセルにおける無線フレームｉとの間の時間差の絶対値が１５３６００Ｔ_ｓ未満であると想定することができる。

【0058】

ハンドオーバー元セルがペア化または非ペア化スペクトルであり、ターゲットセルが非ペア化スペクトルでありＬ_ｍａｘ＝８を使用する異周波数ハンドオーバーを目的とする場合、ＵＥは、現在のセルにおける無線フレームｉとターゲットセルにおける無線フレームｉとの間の時間差の絶対値が７６８００Ｔ_ｓ未満であると想定することができる。

【0059】

簡潔にするため、次の例示的な表は、上に引用した3GPP TS 38.211 v15.6.0の表６．３．３．２－２の一部のみを再現しており、すなわちこの表は、０～２７および２５５のインデックスの場合のランダムアクセス設定のみを示している。

【0060】

【表1】

【0061】

図７は、ＰＲＡＣＨの例示的な設定を示しており、すなわちパラメータｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ＝２２、かつパラメータｍｓｇ１－ＦＤＭ＝２の場合の設定を示している。特に、インデックス＝２２は、ＰＲＡＣＨオケージョンがサブフレーム＃１、＃４、および＃７に位置することを指定する。また、この設定では、サブフレーム＃１、＃４、および＃７それぞれにおいて個別のＰＲＡＣＨスロットが定義される。さらに、この例では、２つのＰＲＡＣＨ周波数リソースｎ_ＲＡ∈｛０，１，．．．，Ｍ－１｝、すなわちＭ＝２である場合を想定している。

【0062】

［アンライセンススペクトルへのアクセス］
ワイヤレスブロードバンドの増え続ける需要を満たすという目的を考慮して、「アンライセンススペクトルへのＮＲベースのアクセスに関する研究（Study on NR-based Access to Unlicensed Spectrum）」が行われた（例えば3GPP TS38.889 v16.0.0を参照）。この研究では、７ＧＨｚ帯域未満（例：５ＧＨｚおよび６ＧＨｚ帯域）のアンライセンス動作における様々な規制要件が詳しく記載され、様々な配置シナリオが検討されている。さらに、設計目標、機能、および解決策が検討され、パフォーマンス評価が行われている。

【0063】

研究では、５つの可能な配置シナリオ（例えば3GPP TS38.889 v16.0.0の６節を参照）が識別され、すなわち、シナリオＡは、ライセンスバンドＮＲ（ＰＣｅｌｌ）とＮＲ－Ｕ（ＳＣｅｌｌ）の間のキャリアアグリゲーションの場合であり、ＮＲ－ＵＳＣｅｌｌはＤＬおよびＵＬの両方を有しうる、またはＤＬのみである。シナリオＢは、ライセンスバンドのＬＴＥ（ＰＣｅｌｌ）およびＮＲ－Ｕ（ＰＳＣｅｌｌ）の間のデュアルコネクティビティである。シナリオＣは、単独のＮＲ－Ｕである。シナリオＤは、アンライセンスバンドのＤＬおよびライセンスバンドのＵＬを有するＮＲセルである。シナリオＥは、ライセンスバンドのＮＲ（ＰＣｅｌｌ）およびＮＲ－Ｕ（ＰＳＣｅｌｌ）の間のデュアルコネクティビティである。

【0064】

さらに、地域および帯域によっては、規制要件を考慮しなければならない。このような要件には、動的周波数選択（ＤＦＳ）、送信電力制御（ＴＰＣ）、リッスンビフォアトーク（ＬＢＴ）、および最大送信期間（チャネル占有時間ＣＯＴとも称される）が限られる不連続送信が含まれる。様々な地域および５ＧＨｚ帯域を対象とするこれらのすべての要件に、システム設計レベルで対処しなければならず、アンライセンススペクトルにＮＲベースでアクセスするための単一のグローバルな解決策の枠組みを構築することが求められる。

【0065】

［アンライセンススペクトルにおけるリッスンビフォアトーク（ＬＢＴ）］
リッスンビフォアトーク（ＬＢＴ）手順は、デバイスがチャネルを使用する前に空きチャネル判定（ＣＣＡ）チェックを実行するためのメカニズムとして定義されている。例示的な一実装形態によれば、ＣＣＡでは、アンライセンスチャネルが占有されているか、または空いているかを判定する目的で、少なくともエネルギ検出を利用して、アンライセンスチャネル上に別の信号が存在しているか否かを判定する。例えば欧州および日本の規制では、アンライセンスバンドにおけるＬＢＴの使用が義務付けられている。規制要件以外でも、ＬＢＴによるキャリア検出は、アンライセンススペクトルを公平に共有するための１つの方法であり、したがって単一のグローバルな解決策の枠組みの中でアンライセンススペクトルを公平かつ友好的に運用するための重要な機能と考えられている。

【0066】

アンライセンススペクトルでは、チャネルの可用性を常に保証できるわけではない。これに加えて、欧州や日本などの特定の地域では、連続的な送信が禁止されており、アンライセンススペクトルにおける送信バーストの最大持続時間に関する制限が課されている（最大チャネル占有時間）。したがって最大送信期間が制限される不連続送信は、５ＧＮＲのための機能である。

【0067】

ＬＢＴに関する欧州のこの規制に従い、装置は、ＣＣＡ中に特定の最小時間（例えば欧州の場合には２０μｓ、ETSI 301 893の４．８．３節を参照）にわたりチャネルを監視しなければならない。検出されたエネルギレベルが、設定されているＣＣＡしきい値（例えば欧州では－７３ｄＢｍ／ＭＨｚ、ETSI 301 893の４．８．３節を参照）を超える場合、チャネルは占有されているとみなされ、逆に、検出された電力レベルが、設定されているＣＣＡしきい値より低い場合、チャネルは空いているとみなされる。チャネルが占有されていると判定される場合、次の一定のフレーム期間（Fixed Frame Period）の間、装置はそのチャネルで送信しない。チャネルが空いているものと分類される場合、装置はただちに送信することが許可される。同じ帯域で動作する他の装置との公平なリソース共有を促進する目的で、最大送信期間が制限される。

【0068】

空きチャネル判定（ＣＣＡ）は繰り返し実行することができ、オプションとして間にバックオフ時間をはさむ。

【0069】

さらに、装置が、与えられたキャリアの可用性を再評価する（すなわちＬＢＴ／ＣＣＡ）ことなく、そのキャリアで送信を実行する合計時間は、チャネル占有時間として定義されている（例えばETSI 301 893の４．８．３．１節を参照）。チャネル占有時間は１ｍｓ～１０ｍｓの範囲内であり、最大チャネル占有時間は、欧州において現在定義されているように例えば４ｍｓとすることができる。

【0070】

さらに、アンライセンスセルで送信した後にＵＥに送信が許可されない最小アイドル時間も存在し、最小アイドル時間は、チャネル占有時間の少なくとも５％である。ＵＥは、アイドル期間が終わる少し前に新たなＣＣＡを実行することができ、以降も同様である。さらに、別のエンティティによって信号を受信した後、共有されるチャネル占有時間（ＣＯＴ）の一部としての特定の期間の間は（例：１６μｓ以内）、ＣＣＡが必要ないことがある。例えば、共有されるｇＮＢＣＯＴの範囲内でのＤＬからＵＬへの切替え、およびＵＬからＤＬへの切替えでは、ＬＢＴを必要としない。

【0071】

ＬＢＴに関する欧州のこの規制に準拠するため、３ＧＰＰは、アンライセンススペクトルに対するＮＲベースのアクセスを以下の４つの異なるカテゴリに分類することを検討した（3GPP TS38.889 v16.0.0の８．２節を参照）。

【0072】

カテゴリ１：短いスイッチングギャップの後、ただちに送信する。これは、送信機がＣＯＴの内側でスイッチングギャップの後にただちに送信するために使用される。受信から送信へのスイッチングギャップは、送受信機のターンアラウンドタイムに対応するためのものであり、１６μｓ以下である。

【0073】

カテゴリ２：ランダムなバックオフなしのＬＢＴ。送信エンティティが送信する前にチャネルがアイドルであると検出される時間の長さは、決定論的である（deterministic）。

【0074】

カテゴリ３：固定サイズの競合ウィンドウを使用するランダムなバックオフありのＬＢＴ。ＬＢＴ手順は、そのステップの１つとして次の手順を有する。送信エンティティが、競合ウィンドウ内で乱数Ｎを発生させる。競合ウィンドウのサイズは、Ｎの最小値および最大値によって指定される。競合ウィンドウのサイズは固定である。乱数Ｎは、ＬＢＴ手順において、送信エンティティがチャネルで送信する前にチャネルがアイドル状態であると検出される時間の長さを決定するために使用される。

【0075】

カテゴリ４：可変サイズの競合ウィンドウを使用するランダムなバックオフありのＬＢＴ。ＬＢＴ手順は、そのステップの１つとして次の手順を有する。送信エンティティが、競合ウィンドウ内で乱数Ｎを発生させる。競合ウィンドウのサイズは、Ｎの最小値および最大値によって指定される。送信エンティティは、乱数Ｎを発生させるときに競合ウィンドウのサイズを変えることができる。乱数Ｎは、ＬＢＴ手順において、送信エンティティがチャネルで送信する前にチャネルがアイドル状態であると検出される時間の長さを決定するために使用される。

【0076】

ＣＯＴ内の様々な送信、および送信される様々なチャネル／信号に対して、異なるカテゴリのチャネルアクセス方式を使用することができる。

【0077】

［アンライセンススペクトルのフレーム構造］
さらに、この検討では、アンライセンススペクトルで動作するためのフレーム構造の、技術的に有利な仕様の「解決策」が記載されている（例えば3GPP TS38.889 v16.0.0の７．２．１．１節を参照）。特に、共有されるｇＮＢチャネル占有時間（ＣＯＴ）内に、ＤＬからＵＬ、およびＵＬからＤＬへの、単一または複数のスイッチングポイントを有するフレーム構造をサポートすることが有利であると認識されている。さらに、単一または複数のスイッチングポイントをサポートするためのリッスンビフォアトーク（ＬＢＴ）要件が認識されている（例えば3GPP TS38.889 v16.0.0の７．２．１．３．１節を参照）。

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

いずれの場合も、本開示は、ユーザ機器９１０が、ランダムアクセス手順のＰＲＡＣＨ送信以外のステップをさらに実行する意図または必要性なしに、ＰＲＡＣＨ送信を実行する状況もカバーするものと理解されたい。言い換えれば、ユーザ機器９１０は、例えば事前定義されるＲＡプリアンプルの送信を通じて、事前定義される情報を基地局９６０に伝える目的で、ワンショットシグナリング（one-shot signaling）メカニズムの一部としてＰＲＡＣＨ送信を実行してもよい。

【0108】

さらに、本開示は、ユーザ機器９１０がアンライセンススペクトル内でＰＲＡＣＨ送信を実行するユースケースの場合について説明されている。ＲＡＣＨ送信がライセンススペクトル内で実行されるユースケースを考慮するのではなく、ユーザ機器９１０は、示されたチャネルリソース（より正確にはチャネルリソースのタイミング指示情報）がＰＲＡＣＨ送信に使用されないかもしれないという不確実性に対処しなければならない。この場合、そのＰＲＡＣＨ送信を中止しなければならない。

【0109】

言い換えれば、アンライセンススペクトル動作ではＰＲＡＣＨ送信に不確実性が加わり、ユーザ機器９１０は、ＰＲＡＣＨ送信に（一般的に）使用されるチャネルリソースのタイミング指示情報を、アンライセンススペクトルの（特定の）占有時間においてＰＲＡＣＨ送信用に実際に使用できることを確認（肯定的に判定）しなければならない。

【0110】

説明を容易にするため、アンライセンススペクトル動作は、以下では、アンライセンスチャネルのチャネルリソースを通じて（介して）ユーザ機器９１０によって実行される送信として示してある。この点において、そのようなアンライセンスチャネルは、アップリンク通信、特にユーザ機器９１０が実行するＰＲＡＣＨ送信に使用されるアンライセンススペクトル内のチャネルリソースを指す。

【0111】

当然ながら、アンライセンススペクトル動作（またはアンライセンスチャネルを通じたアップリンク通信）は、上述した規制要件に準拠する。このことは、実際のアップリンク通信の前にユーザ機器９１０に義務付けられている空きチャネル判定（ＣＣＡ）を含むリッスンビフォアトーク（ＬＢＴ）に準拠することを含む。ＣＣＡが肯定的であるときにのみ、ユーザ機器９１０はアップリンク通信を実行することができる。

【0112】

図１２は、ユーザ機器（ＵＥ）が一般的なシナリオに従ってＰＲＡＣＨ送信を実行するシーケンス図を描いてあり、すなわちユーザ機器９１０のＰＲＡＣＨ送信がアンライセンスチャネルを通じて実行されるため、ＰＲＡＣＨ送信が実際に実行される前に、対応するギャップ期間の送信ギャップを確認しなければならない。

【0113】

ユーザ機器９１０（具体的には図９の処理回路９３０）は、アップリンク通信用のアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定する（例えば図１２のステップ０１を参照）。アップリンク設定用の少なくとも１個のシンボルを設定するこの動作は、受信されるアンライセンスチャネルアクセス設定に基づく。この設定動作は、例えば図１１に示したアップリンクシンボル設定処理回路９３０－ａによって実行することができる。

【0114】

アンライセンスチャネルアクセス設定は、（特定の）アンライセンスチャネルに関連する。言い換えれば、アンライセンスチャネルアクセス設定により、ユーザ機器９１０がそれぞれのアンライセンスチャネルのアクセス（この場合にはアップリンク設定用の少なくとも１個のシンボル）を設定することができる。少なくとも１個のシンボルは、アンライセンスチャネルのチャネルリソースである。

【0115】

本開示は、周波数リソースではなく時間リソースに焦点をあてて説明されている。この一般化は、単に簡潔さを目的として導入されているにすぎない。１個のシンボル（すなわちＯＦＤＭ／ＳＣ－ＦＤＭＡシンボル）の長さに対する１つのサブキャリアから構成されるリソースエレメントなど、時間リソースおよび周波数リソースの両方によって指定されるチャネルリソースを通じてアップリンク通信が実行される配置シナリオも、カバーされる。このようなリソースエレメントも、アンライセンスチャネルのチャネルリソースである。

【0116】

例示的な一実装形態においては、ユーザ機器９１０は、設定動作のベースとなる設定を、図９の受信機９２０を介して受信する。別の例示的な実装形態においては、ユーザ機器９１０は、処理回路９３０が設定動作を実行するための設定を一時的または永久的に格納しているメモリから、設定を受信する。

【0117】

本開示の文脈においては、受信されるアンライセンスチャネルアクセス設定は、様々な実装形態をサポートすることができる。

【0118】

例示的な一実装形態においては、この設定は、アップリンク通信用の少なくとも１個のシンボルを設定するためだけに使用される。別の例示的な実装形態においては、この設定は、アップリンク通信用の少なくとも１個のシンボルを設定するために使用されるだけではない。むしろ、同じ設定に基づいて、ダウンリンク通信用の少なくとも１個の（何らかの）別の（異なる）シンボルを設定することができる。

【0119】

さらなる例示的な実装形態においては、この設定は、それぞれのシンボルをアップリンクシンボル、ダウンリンクシンボル、またはフレキシブルシンボルとして指定する情報を含む。さらに別の例示的な実装形態においては、この設定は、ダウンリンク通信とアップリンク通信の間、またはアップリンク通信とダウンリンク通信の間で切り替えるためのスイッチング時間インスタンス（switching time instance）を指定する。ユーザ機器９１０は、このようなスイッチング時間インスタンスに基づいて、アップリンク通信用の少なくとも１個のシンボルを設定することもできる。

【0120】

別の例示的な実装形態においては、この設定は、シンボルレベルではなく、スロットレベルまたはサブフレームレベルなどのより粗い粒度で、アップリンク通信および／またはダウンリンク通信を指定する。この場合も、ユーザ機器９１０は、アップリンク通信用の少なくとも１個のシンボルのように、それぞれのスロットまたはサブフレームのすべてのシンボルを設定することができる。

【0121】

さらなる例示的な実装形態においては、この設定は、アンライセンスチャネルの占有時間の少なくとも１つの個々のスロットに（のみ）関連し、したがって（この）少なくとも１つの個々のスロットのそれぞれのシンボルの設定動作は、この設定に基づく。

【0122】

特に、設定がアンライセンスチャネルの占有時間の複数の個々のスロットに関連する場合、この設定により、アップリンクシンボルとして指定されるシンボルから完全に（または、のみで）構成される、または、ダウンリンクシンボルとして指定されるシンボルから完全に（または、のみで）構成される、複数の個々のスロットの１つを、設定することが可能になる。言い換えれば、重複が形成される。

【0123】

説明を目的として、スロットが、指定されるアップリンクシンボルのみから構成されていると想定すると、ダウンリンクシンボルが存在しないため、このスロット中には対応する設定をシグナリングすることができない。したがって、個々のスロットそれぞれに対して設定が個別にシグナリングされる場合、指定されるアップリンクシンボルのみから構成されている個々のスロットについては個別のシグナリングは可能ではない。このような状況を回避する目的で、設定は、占有時間の複数の（重複する）スロットに関連することができる。

【0124】

さらに別の例示的な実装形態においては、設定は、アンライセンスチャネルの占有時間（全体）に関連し、したがって占有時間（全体）のすべてのシンボルの設定動作が、この設定に基づく。

【0125】

さらなる例示的な実装形態においては、この設定は、少なくとも１つの個々のスロットが占有時間に含まれている（包含されている）か否かにかかわらず、少なくとも１つのスロット（またはサブフレームまたは無線フレーム）に関連する。この点において、ユーザ機器９１０は、最初に占有時間を決定し、次に、決定された占有時間に含まれる設定に基づいて、それぞれの少なくとも１つの個々のスロット（またはサブフレームまたは無線フレーム）のシンボルのみを設定する。

【0126】

別の例示的な実装形態においては、この設定は、半静的なシグナリングの形でユーザ機器９１０によって受信される。半静的なシグナリングに固有なシグナリングオーバーヘッドを考慮すると、半静的なシグナリングにより、占有時間（全体）（すなわち時間インスタンスから始まり、アンライセンスチャネルが占有されている期間にわたる）のシンボルの設定が容易になる。

【0127】

このような半静的なシグナリングは、それぞれの設定および／または指示情報を伝える情報要素を含む少なくとも１つのブロードキャストシステム情報（ＳＩ）ブロックまたはＳＩメッセージ（例：ＳＩＢ１）または専用ＲＲＣメッセージを好ましくは含むＲＲＣシグナリングメカニズム、に依存してもよい。

【0128】

さらに、半静的なシグナリングでは、少なくとも１つの個々のスロットが占有時間に含まれているか否かにかかわらず、（その）少なくとも１つのスロット（またはサブフレームまたは無線フレーム）の設定が容易になる。設定自体が占有時間に関係ない場合、この設定は、占有時間（全体）（すなわち時間インスタンスから始まり、アンライセンスチャネルが占有されている期間にわたる）を指定するために伝えられる。

【0129】

さらなる例示的な実装形態においては、この設定は、動的シグナリングの形でユーザ機器９１０によって受信される。動的シグナリングに固有な低レイテンシを考慮すると、同じ形の動的シグナリングにより、アンライセンスチャネルの占有時間の一部（例：個々のスロット、またはサブフレームまたは無線フレーム）のシンボルの設定が容易になる。したがってユーザ機器９１０は、占有時間の持続時間にわたり複数の設定を受信する。

【0130】

このような動的シグナリングは、それぞれの設定を伝える少なくとも１つのＭＡＣ制御要素（ＭＡＣＣＥ）を好ましくは含む媒体アクセス制御（ＭＡＣ）シグナリング、または、それぞれの設定を伝える少なくとも１つのダウンリンク制御情報（ＤＣＩ）（例えばＤＣＩフォーマット２－０）を好ましくは含む物理（ＰＨＹ）シグナリング、に依存することができる。

【0131】

当然ながら、上の例示的な実装形態は、相互に排他的な代替形態を説明しているのではなく、組み合わせて、機能する単一の実装形態を形成することができる。例えばこのような組合せは、ユーザ機器９１０において半静的なシグナリング（存在時）からの設定よりも動的シグナリングが優先される形で、半静的なシグナリングと動的シグナリングの両方を含むことができる。

【0132】

次にユーザ機器９１０（具体的には図９の受信機９２０）は、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を受信する（例えば図１２のステップＳ０２を参照）。この受信動作は、例えば、図１１に示したＰＲＡＣＨチャネルリソースタイミング指示情報受信機９２０－ａによって実行することができる。

【0133】

想定される配置シナリオでは、ＰＲＡＣＨとは異なる複数の異なる物理アップリンクチャネル（ＰＵＳＣＨ、ＰＵＣＣＨ、．．．など）が存在する。アンライセンスチャネルアクセス設定によって、ユーザ機器９１０は、使用する物理アップリンクチャネルとは無関係に、アップリンクリソースの少なくとも１個のシンボルを設定することができる。

【0134】

この理由のため、ユーザ機器９１０は、ＰＲＡＣＨ送信に使用されるチャネルリソースのタイミング指示情報をさらに受信する。言い換えれば、受信されるタイミング指示情報は、ＰＲＡＣＨ送信用にユーザ機器９１０によって使用されるチャネルリソースのタイミング（例えば開始時刻および／または持続時間など）を示す。

【0135】

このとき、ＰＲＡＣＨ送信用のチャネルリソースの、受信されるタイミング指示情報は、アンライセンスチャネルが実際に占有されるか否かを考慮していない。言い換えれば、タイミング指示情報は、アンライセンスチャネルアクセス設定によって、ＰＲＡＣＨ送信用のチャネルリソースの示されたタイミングにおいてアップリンク通信用の少なくとも１個のシンボルの設定が有効化されるか否かを反映していない。

【0136】

したがってユーザ機器９１０（具体的には図９の処理回路９２０）は、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングが、アップリンク通信用に設定された少なくとも１個のシンボル内に含まれているか否かを判定する（例えば図１２のステップＳ０３を参照）。言い換えれば、ユーザ機器９１０は、ＰＲＡＣＨ送信用のチャネルリソースの示されたタイミングが、アップリンク通信用に設定された少なくとも１個のシンボル内に収まるか否かを判定する。この判定動作は、例えば、図１１に示したＰＲＡＣＨチャネルリソース判定処理回路９３０－ｂによって実行することができる。

【0137】

例を目的として、ＰＲＡＣＨ送信用のチャネルリソースの示されたタイミングがユーザ機器９１０によって受信されるものと想定する。しかしながら上述したように、示されたタイミングは、占有時間自体（例えばその開始時刻または持続時間）を考慮しておらず、また、例えばアンライセンスチャネルを通じたアップリンク通信の需要の減少に一致させるための占有時間の個々のシンボルまたはスロットまたはサブフレームの再利用により生じる占有時間の（再）設定に適合するかも考慮しない。これらが考慮されていないため、ユーザ機器９１０は、ＰＲＡＣＨ送信用のチャネルリソースの示されたタイミングが占有時間の（再）設定に適合するか否かを常に判定する必要がある。

【0138】

例えば、アップリンク通信の需要が減少すると、占有時間の（再）設定が促され、ダウンリンク通信用のシンボルがアップリンク通信用のシンボルより多くなる。この場合、判定動作により、ユーザ機器９１０が、（再）設定された占有時間に基づいて設定されたアップリンク通信用の数の少ないシンボルに適合するＰＲＡＣＨ送信用のチャネルリソースの示されたタイミングのみを依然として使用することが保証される。

【0139】

上述した情報の分離は、各機能をその目的に応じて分割するという点で有利であることが判明しており、すなわち、占有時間中のアンライセンスチャネルへのアクセスを（高レベルで）指定するためのアンライセンスチャネルアクセス設定と、ＰＲＡＣＨ送信用のチャネルリソースのタイミングを（低レベルで）指定するためのタイミング指示情報とに分離される。両方の個別の情報が存在する場合のみ、アンライセンスチャネルを通じたＰＲＡＣＨ送信が促進される。

【0140】

本開示の文脈においては、ＰＲＡＣＨチャネルリソースの受信されるタイミング指示情報は、様々な実装形態をサポートすることができる。

【0141】

例示的な一実装形態においては、受信されるタイミング指示情報は、ＰＲＡＣＨ送信に使用されるチャネルリソースの開始時刻および／または持続時間の形でチャネルリソースのタイミングを指定する。言い換えれば、タイミング指示情報は、ＰＲＡＣＨチャネルリソースのタイミングを明示的に示す。ユーザ機器９１０は、このようなタイミング指示情報から、ＰＲＡＣＨ送信用のチャネルリソースの示されたタイミングを推測することができる。

【0142】

この例示的な実装形態によれば、例えば、受信されるタイミング指示情報は、ＰＲＡＣＨチャネルリソースがシンボル＃０の開始タイミングを有する、および／または１４個のシンボルの持続時間を有することを示すことができる。したがってこのようなタイミング指示情報は、個々のスロットの（すべての）シンボル＃０～＃１３が、ＰＲＡＣＨ送信に使用されるチャネルリソース（例：ＰＲＡＣＨスロット）であることを示す。ユーザ機器９１０は、このようなタイミング指示情報から、ＰＲＡＣＨ送信用のチャネルリソースの示されたタイミングを推測することができる。

【0143】

別の例示的な実装形態においては、受信されるタイミング指示情報は、事前に設定される表（上述した表１、または3GPP TS 38.211 v15.6.0の表６．３．３．２－２～表６．３．３．２－４のいずれかなど）のインデックスを示す。この場合も、タイミング指示情報は、ＰＲＡＣＨチャネルリソースのタイミングを明示的に示す。ユーザ機器９１０は、このようなタイミング指示情報から、ＰＲＡＣＨ送信用のチャネルリソースの示されたタイミングを、対応する事前に設定された表を参照して推測することができる。

【0144】

この例示的な実装形態によれば、例えば、受信されるタイミング指示情報は、事前に設定された表１のインデックス２２を示すことができ、この指示情報からユーザ機器９１０は、個々のスロット（この場合にはスロット＃１、＃４、＃７）の（すべての）シンボル＃０～＃１４が、ＰＲＡＣＨ送信に使用されるチャネルリソース（例：ＰＲＡＣＨスロット）であることを推測することができる。

【0145】

さらなる例示的な実装形態においては、受信されるタイミング指示情報は、事前に設定される表（上述した表１、または3GPP TS 38.211 v15.6.0の表６．３．３．２－２～表６．３．３．２－４のいずれかなど）の以前に送信された（事前に設定された）インデックスの有効化／無効化情報を示すことができる。このタイミング指示情報は、ＰＲＡＣＨチャネルリソースのタイミングを暗黙的に示す。この場合もユーザ機器９１０は、このようなタイミング指示情報から、ＰＲＡＣＨ送信用の有効化／無効化されるチャネルリソースの示されたタイミングを、事前に設定された表の以前に送信された対応するインデックスを参照して推測することができる。

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

【表2】

【0182】

次にユーザ機器９１０は、ＣＣＡが肯定的である場合（ケース「Ｙ」）には次の動作に進み（例えば図１２のステップＳ０７を参照）、これに対してＣＣＡが肯定的でない、すなわち否定である場合（ケース「Ｎ」）には、ユーザ機器９１０は、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングにおいてＰＲＡＣＨ送信を中止する。

【0183】

さらに、ＣＣＡ動作が肯定的である場合（ケース「Ｙ」）、ユーザ機器９１０（具体的にはその送信機９２０）は、アップリンク通信用に設定された少なくとも１個のシンボル内でランダムアクセス（ＲＡ）プリアンブルを送信することによって、チャネルリソースを介してＰＲＡＣＨ送信を実行する。送信動作は、例えばＰＲＡＣＨ送信送信機９３０－ｂによって実行される。

【0184】

上の説明は、ユーザ機器９１０の観点から行ってきた。しかしながらこのことは本開示を制限するようには理解されないものとする。基地局９６０も、本明細書に開示されている一般的なシナリオを等しく実行する。

【0185】

この場合も、本開示は、基地局９６０がＰＲＡＣＨ送信を受信するという想定下で説明されている。このＰＲＡＣＨ送信は、前述した競合ベースのランダムアクセス（ＲＡ）手順などのランダムアクセス手順の一部とする、あるいは非競合ベースのランダムアクセス手順の一部、あるいはさらに別の形のランダムアクセス手順の一部とすることができる。いずれの場合も、本開示は、任意のそのようなランダムアクセス手順に制限されるようには理解されないものとする。

【0186】

いずれの場合も、本開示は、基地局９６０が、ランダムアクセス手順のＰＲＡＣＨ送信の受信以外のステップをさらに実行することを意図することなく、または実行する必要なしに、ＰＲＡＣＨ送信を受信する状況もカバーするものと理解されたい。言い換えれば、基地局９６０は、例えば事前定義されるＲＡプリアンプルの送信を通じて、事前定義される情報をユーザ機器９１０から伝える目的で、ワンショットシグナリングメカニズムの一部としてＰＲＡＣＨ送信を受信してもよい。

【0187】

図１３は、基地局（ＢＳ）が一般的なシナリオに従ってＰＲＡＣＨ送信を受信するシーケンス図を描いてあり、すなわち基地局９６０のＰＲＡＣＨ送信の受信動作がアンライセンスチャネルを通じて実行されるため、ＰＲＡＣＨ送信が実際に実行される前に、対応するギャップ期間の送信ギャップを確認しなければならない。

【0188】

基地局９６０（具体的にはその処理回路９７０）は、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定する（例えば図１３のステップ０１を参照）。少なくとも１個のシンボルは、アンライセンスチャネルアクセス設定に基づいて設定される。この設定動作は、例えば図１０のＵＬシンボル設定処理回路９８０－ａによって実行される。

【0189】

次に基地局９６０（具体的にはその送信機９７０）は、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を送信する（例えば図１３のステップＳ０２を参照）。この送信動作は、例えばＰＲＡＣＨチャネルリソースタイミング指示情報送信機９７０－ａによって実行される。

【0190】

次いで基地局９６０（具体的にはそのプロセッサ９８０）は、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングが、アップリンク通信用に設定された少なくとも１個のシンボル内に含まれるか否かを判定する（例えば図１３のステップＳ０３を参照）。この判定動作は、例えばＰＲＡＣＨチャネルリソース判定処理回路９８０－ｂによって実行される。

【0191】

判定が否定である場合（図１３のステップＳ０４のケース「Ｎ」を参照）、基地局９６０は、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングが無効であるものと判定する（例えば図１３のステップＳ０５を参照）。

【0192】

判定が肯定である場合（例えば図１３のステップＳ０４のケース「Ｙ」を参照）、基地局９６０（具体的にはその処理回路９８０）は、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングの開始の前にギャップ期間を持つ送信ギャップが設定されているか否かを識別する（例えば図１３のステップＳ０６を参照）。この識別動作は、例えば送信ギャップ識別処理回路９８０－ｃによって実行される。

【0193】

識別が否定である場合（例えば図１３のステップＳ０７のケース「Ｎ」を参照）、基地局９６０は、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングにおいてＰＲＡＣＨ送信の受信を中止する。

【0194】

送信ギャップの識別が肯定である場合（例えば図１３のステップＳ０７のケース「Ｙ」を参照）、基地局９６０（具体的にはその受信機９７０）は、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングにおいて、アップリンク通信用に設定された少なくとも１個のシンボル内で送信されるランダムアクセス（ＲＡ）プリアンブルの形でのＰＲＡＣＨ送信を受信する。この受信動作は、例えばＰＲＡＣＨ送信受信機９７０－ｂによって実行される。

【0195】

［第１の例示的な実装形態］
第１の例示的な実装形態では、一般的なシナリオに従ってのユーザ機器９１０の動作についてさらに詳しく説明する。特に、この第１の例示的な実装形態は、ユーザ機器９１０が、物理ダウンリンク制御チャネルシグナリングを介して提供されるチャネル占有時間（ＣＯＴ）構造情報（またはパラメータ）に従って設定されるアンライセンスチャネルを通じてＰＲＡＣＨ送信を実行するシナリオに焦点をあてる。

【0196】

図１４は、第１の例示的な実装形態に係る流れ図を示している。この流れ図では、５ＧＮＲ配置シナリオを想定しており、対応する専門用語を使用する。例えば、アップリンクにおける物理ランダムアクセスチャネル（ＰＲＡＣＨ）のみならず、ダウンリンクにおける物理ダウンリンク制御チャネル（ＰＤＣＣＨ）も言及されている。この点において、ユーザ機器９１０は、アップリンク、すなわちＰＲＡＣＨの送信を実行するのみならず、ダウンリンクのＰＤＣＣＨの受信も実行する。

【0197】

この目的のため、ユーザ機器９１０は、ＰＤＣＣＨ設定を受信し（例えば図１４のステップＳ０１を参照）、ＰＤＣＣＨ設定は、物理ダウンリンク制御チャネルを通じて制御情報を受信することができるようにユーザ機器９１０を設定する。ＰＤＣＣＨ設定により、ユーザ機器９１０は、ＰＤＣＣＨを通じてダウンリンク制御情報（ＤＣＩ）を受信するように設定される。

【0198】

２つの異なる開始点を区別しなければならない。
第１の開始点によれば、ユーザ機器９１０は「ＲＲＣ接続」状態にある。この「ＲＲＣ接続」状態では、ユーザ機器９１０は、ＲＲＣ（無線リソース制御）プロトコルによって規定された専用制御メッセージを受信するように設定されている。この場合、ユーザ機器９１０は、専用ＲＲＣ制御メッセージを介してＰＤＣＣＨ設定を受信する。

【0199】

このＰＤＣＣＨ設定（専用ＲＲＣ制御メッセージを介して受信される）は、ＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋＴｙｐｅ１（略してＳＩＢ１）を介して提供されるセルに固有な様々な設定を補足する。ＳＩＢ１は、セルによってサーブされているすべてのユーザ機器９１０にブロードキャストされる。言い換えれば、ＰＤＣＣＨ設定で指定されないすべての補足設定については、ユーザ機器９１０はＳＩＢ１に従う。

【0200】

第２の開始点によれば、ユーザ機器９１０は「ＲＲＣアイドル」状態または「ＲＲＣ非アクティブ」状態にある。いずれの状態においても、ユーザ機器９１０は、ＲＲＣプロトコルによって規定された専用制御メッセージを受信するように設定されていない。しかしながらユーザ機器９１０は、ＳｙｓｔｅｍＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋＴｙｐｅ１（略してＳＩＢ１）を介して提供されるセルに固有な設定を受信するように設定される。この点においてユーザ機器９１０は、ブロードキャストされるＳＩＢ１を介してＰＤＣＣＨ設定を受信する。

【0201】

さらにユーザ機器９１０は、同じＳＩＢ１を介して（または補足ＳＩＢ１を介して）パラメータ「ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ」を受信する（例えば図１４のステップＳ０２を参照）。このパラメータは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信の、時間領域に関連する側面を指定し、例えば、ＰＲＡＣＨ送信を伝える無線フレームの（１つまたは複数の）スロット番号、シンボル数で表したＰＲＡＣＨ送信の持続時間、ＰＲＡＣＨ送信の開始シンボル、ＲＡプリアンブルとして使用されるシーケンスなどである。この点において、パラメータ「ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ」は、ＰＲＡＣＨ送信に使用されるチャネルリソースのタイミング（例：持続時間）を示す。

【0202】

第１の例示的な実装形態においては、ユーザ機器（ＵＥ）９１０は、ＰＲＡＣＨ送信の開始シンボルを除き、パラメータ「ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ」によって指定される時間領域に関連するすべての側面を利用する。言い換えればユーザ機器９１０は、ＰＲＡＣＨ送信に使用される開始シンボルについては動的な指示情報が提供されることを予期する。ユーザ機器９１０は、この動的な指示情報を、アンライセンスチャネルの占有時間の間に受信するように予期する。開始シンボルのこのような個別の（動的な）指示情報を使用することで、さらに柔軟性が高まり、すなわち動的なシグナリングでは、たとえ最後の瞬間でも、必要になった場合に別の開始シンボルを指示することができる。

【0203】

例を目的として、シグナリングされるパラメータ「ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ」が値２２を含むものと想定すると、ユーザ機器９１０は、（上述した）事前に設定される表１から、ＰＲＡＣＨ送信に使用されるチャネルリソースがスロット＃１、＃４、および＃７であることを推測する。特に、これらのすべてのチャネルリソースは、１４個のシンボルの持続時間を有する。しかしながら上述したように、ＰＲＡＣＨ送信用のチャネルリソースのこのタイミング指示情報は、アンライセンスチャネルが実際に占有されるかを考慮していない。

【0204】

この点において、ユーザ機器９１０は、アンライセンスチャネルアクセス設定をさらに受信する（例えば図１４のステップＳ０３を参照）。この第１の例示的な実装形態においては、アンライセンスチャネルアクセス設定は、チャネル占有時間構造情報（以下では「ＣＯＴ構造情報」）の形でシグナリングされる。ユーザ機器９１０は、受信した「ＣＯＴ構造情報」に基づいて、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定する。

【0205】

言い換えれば、「ＣＯＴ構造情報」は、チャネル占有時間、すなわち５ＧＮＲ動作のためにアンライセンスチャネルが占有されている時間を構造化する。例えば、アンライセンスチャネルが５ＧＮＲ動作とＷｉＦｉ動作との間で共有されていた場合、アンライセンスチャネルの占有時間は、そのチャネルが５ＧＮＲ動作用に占有されている時間、すなわちユーザ機器９１０が、ダウンリンク通信を受信することとアップリンク通信についてスケジューリングされることを正当に予期できる時間を排他的に指す。

【0206】

しかしながら、このような排他的な５ＧＮＲ動作は、ユーザ機器９１０がチャネル占有時間（ＣＯＴ）の外側でＰＲＡＣＨ送信を実行してはならないことを意味するわけではない。逆にユーザ機器９１０は、状況によっては（例えば図１９の説明を参照）、ＣＯＴの外側でＰＲＡＣＨ送信を実行するように促される。これらのＰＲＡＣＨが異なる点は、ＣＯＴの外側ではＷｉＦｉ動作との干渉が排除されないことだけである。

【0207】

より詳細には、ユーザ機器９１０は、「ＣＯＴ構造情報」を、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を介して、好ましくはダウンリンク制御情報（ＤＣＩ）フォーマットのそれぞれのフィールド内で受信する。「ＣＯＴ構造情報」は、例えばＰＤＣＣＨにおいてＤＣＩフォーマット２－０を介して送信することができる。より詳細には、ユーザ機器９１０は、「ＣＯＴ構造情報」を受信する目的で、ＰＤＣＣＨ設定に従ってＰＤＣＣＨを監視および復号する。

【0208】

受信された「ＣＯＴ構造情報」によって、ユーザ機器９１０は、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定することができる。

【0209】

言い換えれば、「ＣＯＴ構造情報」は、チャネル占有時間（ＣＯＴ）の個々のシンボルがどのように構造化されているか、すなわちダウンリンクとアップリンクの間の（またはこの逆の）スイッチングポイントがいつ発生するかについての情報を伝える。より詳細には、「ＣＯＴ構造情報」は、占有時間の複数のスロットのシンボルを、アップリンクシンボル、ダウンリンクシンボル、またはフレキシブルシンボルのいずれかとして指定し、受信機は、動作時、部分的に重複する複数の「ＣＯＴ構造情報」を受信する。

【0210】

下の表３は「ＣＯＴ構造情報」の具体的な例を示しており、すなわち「ＣＯＴ構造情報」は、１つのスロットの固定された持続時間の各シンボルについて個別に「ＣＯＴ構造」を指定する。ただしこの表３は、あらゆるＣＯＴ構造のリストを提供するものではないため、本開示の制限として理解されないものとする。

【0211】

【表3】

【0212】

この表３では、「ＣＯＴ構造情報」は、１つのスロット（１４個のシンボルのシーケンスに対応する）という固定された持続時間について、アップリンクシンボル（表３では「Ｕ」）、ダウンリンクシンボル（表３では「Ｄ」）、またはフレキシブルシンボル（表３では「Ｆ」）を指定する。

【0213】

下の表４は「ＣＯＴ構造情報」の別の具体的な例を示しており、すなわち「ＣＯＴ構造情報」は、１つまたは２つのスロットの可変持続時間の各シンボルについて個別に「ＣＯＴ構造」を指定する。ただしこの表４は、あらゆるＣＯＴ構造のリストを提供するものではないため、本開示の制限として理解されないものとする。

【0214】

【表4】

【0215】

この表４では、「ＣＯＴ構造情報」は、１つのスロット（１４個のシンボルのシーケンスに対応する）または２つのスロット（２８個のシンボルのシーケンスに対応する）の可変の持続時間について、アップリンクシンボル（表では略して「Ｕ」）、ダウンリンクシンボル（表では略して「Ｄ」）、またはフレキシブルシンボル（表では略して「Ｆ」）を指定する。

【0216】

「ＣＯＴ構造情報」が２つの（連続する）スロットの「ＣＯＴ構造」を指定する場合、２つの個別に受信される「ＣＯＴ構造情報」が１つの同じスロットの「ＣＯＴ構造」を指定するときには、シグナリングの重複が起こる。この重複は、ある程度の冗長性の形成を促進するとともに、「ＣＯＴ構造」、すなわちアップリンクシンボルのみで構成されるスロットを含むＣＯＴ構造の柔軟性の向上を促進する。

【0217】

「ＣＯＴ構造」の柔軟性の向上についてさらに詳しく説明する。
「ＣＯＴ構造」が最も柔軟に指定され、アップリンクシンボルのみで（完全に）構成されているスロットを含むケースを想定すると、このような「ＣＯＴ構造」については、少なくとも２つ以上のスロットの「ＣＯＴ構造」の組み合わされたシグナリングの形で「ＣＯＴ構造情報」をシグナリングする必要がある。

【0218】

いま、例を目的として、「ＣＯＴ構造情報」が、アップリンクシンボルのみを含むスロット（例：スロット＃Ｋ）の「ＣＯＴ構造」を指定しているものとする。この場合、この「ＣＯＴ構造情報」を同じスロット（スロット＃Ｋ）で受信することはできず、なぜならこのスロットは「ＣＯＴ構造」によってアップリンク信号のみを有することが指定されているためである。言い換えれば、アップリンク信号のみを有するスロットを指定するこの「ＣＯＴ構造」については、別のスロット、すなわち前のスロット（例：スロット＃Ｋ－１）においてそれぞれの「ＣＯＴ構造情報」をシグナリングする必要がある。

【0219】

さらにこの例において、この「ＣＯＴ構造情報」が前のスロット（例：スロット＃Ｋ－１）においてシグナリングされ、次のスロット（スロット＃Ｋ）について、アップリンクシンボルのみを含む「ＣＯＴ構造」を指定しているものと想定する。この場合にも、次のスロット（スロット＃Ｋ）ではさらなる「ＣＯＴ構造情報」をシグナリングすることはできず、なぜならこのスロット（スロット＃Ｋ）は、アップリンクシンボルのみを含む「ＣＯＴ構造」を有するように指定されているためである。

【0220】

この理由のため、「ＣＯＴ構造」が最も柔軟に定義されており、アップリンクシンボルのみで（完全に）構成されるスロットを含む場合、少なくとも２つ以上のスロットの「ＣＯＴ構造」を組み合わせたシグナリングの形でそれぞれの「ＣＯＴ構造情報」をシグナリングする必要がある。

【0221】

ある程度の冗長性の形成についてさらに詳しく説明する。
少なくとも２つ以上の（連続する）スロットの複数の「ＣＯＴ構造」のシグナリングを組み合わせた「ＣＯＴ構造情報」が存在するケースを想定する。この場合、２つ以上のスロットの各々において対応する「ＣＯＴ構造情報」をシグナリングすることは、指定される「ＣＯＴ構造」によってそのようなシグナリングが許可される限りは阻止または禁止されない。むしろ、２つ以上のスロットの各々において対応する「ＣＯＴ構造情報」をシグナリングすることにより、ある程度の冗長性が形成される。

【0222】

いま、例を目的として、１つのスロット（例：スロット＃Ｋ）において、表４に従った「ＣＯＴ構造情報」をシグナリングするものと想定する。この「ＣＯＴ構造情報」は値７を有する。表４に従うと、値７は、２つのスロットの「ＣＯＴ構造」、すなわち「ＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＤＦＵ」という「ＣＯＴ構造」を指定している。

【0223】

この例では、次の（連続する）スロット（例：スロット＃Ｋ＋１）において、表４に従った「ＣＯＴ構造情報」がさらにシグナリングされることが阻止または禁止されない。この場合、この「ＣＯＴ構造情報」は値１を有する。表４に従うと、値１は１つのスロットの「ＣＯＴ構造」、すなわち「ＤＤＤＤＤＤＤＤＤＤＤＤＦＵ」という「ＣＯＴ構造」を指定する。

【0224】

言い換えれば、「ＤＤＤＤＤＤＤＤＤＤＤＤＦＵ」という同じ「ＣＯＴ構造」が、値１を有する「ＣＯＴ構造情報」の（最初の）スロットと同じく、値７を有する「ＣＯＴ構造情報」の（２番目の）スロットにおいてシグナリングされる。この理由から、２つ以上のスロットの各々において対応する「ＣＯＴ構造情報」をこのようにシグナリングすることで、ある程度の冗長性が形成される。

【0225】

ユーザ機器９１０は、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースの持続時間の指示情報の役割を果たすパラメータ「ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ」を受信し、さらに、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルの設定の役割を果たす「ＣＯＴ構造情報」を受信した後、次の動作に進む。

【0226】

具体的には、ユーザ機器９１０は、ＰＲＡＣＨ送信に使用されるチャネルリソースの示された持続時間が、アップリンク通信用に設定された少なくとも１個のシンボル内に含まれる（または収まる）か否かを判定する（例えば図１４のステップＳ０４を参照）。この判定動作をさらに説明するため、図１５に示した例を参照する。

【0227】

図１５は、第１の例示的な実装形態に係るユーザ機器９１０の例示的な動作を示しており、すなわちユーザ機器９１０は、ＰＤＣＣＨシグナリングを介して提供される「ＣＯＴ構造情報」に従って設定されるアンライセンスチャネルを通じてＰＲＡＣＨ送信を実行する。

【0228】

この図に描かれているように、ユーザ機器９１０は、スロット＃３において、上の表４に従った「ＣＯＴ構造情報」（値７を有する）を伝えるＰＤＣＣＨを受信する。値７は、連続するスロット＃３および＃４の「ＣＯＴ構造」、すなわち「ＤＤＤＤＤＤＤＤＤＤＤＤＤＤＵＵＵＵＵＵＵＵＵＵＵＵＵＵ」という「ＣＯＴ構造」を指定する。この点において、スロット＃４は、アップリンクシンボルのみを含む「ＣＯＴ構造」を有する。

【0229】

これと同時に、表１に従った値２２を有する受信されたパラメータ「ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ」は、ＰＲＡＣＨチャネルリソースの持続時間が１４個のシンボルであることをユーザ機器に示す。なおユーザ機器は、パラメータ「ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ」を介して示される開始シンボルを無視することに留意されたい。

【0230】

次にユーザ機器９１０は、ＰＲＡＣＨ送信用のチャネルリソースとして使用される示された１４個のシンボルの持続時間が、「ＣＯＴ構造情報」に基づいて設定されるアップリンクシンボルに収まるかを判定する。言い換えれば、ユーザ機器９１０は、ＰＲＡＣＨチャネルリソースのシンボル数で表した持続時間を含むことができるように、「ＣＯＴ構造」が十分に大きな数の連続するアップリンクシンボルを有するかを判定する。

【0231】

スロット＃４は、１４個のアップリンクシンボルを含む「ＣＯＴ構造」を有するため、ユーザ機器９１０は、スロット＃４のＰＲＡＣＨチャネルリソースの示された持続時間（同じく１４個のシンボル）を、「ＣＯＴ構造」によってアップリンクシンボルとして指定されたシンボル内に含める（収める）ことができるものと判定する。

【0232】

この理由のため、描いた例では、ユーザ機器９１０はスロット＃４を、ＰＲＡＣＨ送信に使用されるアンライセンスチャネルのチャネルリソースに似ている（resemble）ものと肯定的に判定する。

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

スロット＃７では状況が異なる。
スロット＃７では、パラメータ「ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ」が、シンボル番号＃０～＃１３における合計１４個のアップリンクシンボルを指定しており、かつ、「ＣＯＴ構造」の結果として同じシンボル番号＃０～＃１３における１４個のアップリンクシンボルの設定になる。したがってユーザ機器９１０は、このＰＲＡＣＨチャネルリソースを使用できるものと判定する（例えば図１７のステップＳ０７、ケース「Ｙ」を参照）。言い換えれば、ＰＲＡＣＨ送信に使用されるチャネルリソースの（正確な）タイミングが有効化される。

【0277】

この肯定的な判定により、ユーザ機器９１０は、アンライセンスチャネルにアクセスするときの動作を規定するＬＢＴカテゴリの識別に進む（例えば図１７のステップＳ０９を参照）。本例の場合、ユーザ機器９１０は、複数のギャップ期間のうちの１つのギャップ期間の指示情報を、複数のＬＢＴカテゴリのうち一緒に使用されるＬＢＴカテゴリの指示情報との組合せにおいて受信する。

【0278】

【0279】

この例では、ユーザ機器９１０は、スロット＃６のＰＤＣＣＨでこの指示情報を受信することができ、このＰＤＣＣＨは、図１８に関連して説明したように「ＣＯＴ構造情報」が伝えられるスロット＃６のＰＤＣＣＨと同じである。これに代えて、ユーザ機器９１０は、このＰＤＣＣＨを前のスロットで受信することができる。

【0280】

いま、例を目的として、ユーザ機器９１０が、上述した表２に従って解釈されるべき値２の指示情報を受信するものと想定する。この場合にユーザ機器９１０は、ＣＣＡを実行するときに２５μｓのギャップ期間を使用しなければならないことと、ＬＢＴカテゴリ２に従って動作しなければならないことを認識する。この例の場合、ユーザ機器９１０は、有効なＬＢＴカテゴリが見つかる（例：受信する）ことを認識し（例えば図１７のステップＳ１１を参照）、ＰＲＡＣＨが必要であるか否かの判定に進む（ケース「Ｙ」）。

【0281】

いま、別の例を目的として、ユーザ機器９１０が、ギャップ期間の指示情報を受信しない（ケース「Ｎ」）ものと想定する。この場合、ユーザ機器９１０は、アンライセンスチャネルにアクセスする前にＣＣＡを実行する方法を認識しない。この理由のため、ユーザ機器９１０は、提供された「ＣＯＴ構造情報」に応答して設定されたアップリンクシンボルを通じてのＰＲＡＣＨ送信が許可されないことを推測する（例えば図１７のステップＳ１０を参照）。

【0282】

ユーザ機器が有効なＬＢＴカテゴリを見つけた場合に戻ると、ユーザ機器９１０は、ＰＲＡＣＨ送信を実行する必要があるかをチェックする（例えば図１７のステップＳ１１を参照）。ＰＲＡＣＨ送信を実行する必要がない場合（ケース「Ｎ」）、ユーザ機器９１０は、さらなる動作を行わないことを認識する（例えば図１７のステップＳ１２を参照）。

【0283】

ＰＲＡＣＨ送信を実行する必要がある場合（ケース「Ｙ」）、ユーザ機器９１０は、空きチャネル判定（ＣＣＡ）を実行する（例えば図１７のステップＳ１３を参照）。空きチャネル判定（ＣＣＡ）は、ＰＲＡＣＨ送信に使用されるチャネルリソースのタイミングの開始の前の示されたギャップ期間２５μｓに対して実行される。言い換えれば、ユーザ機器９１０は、スロット＃７の開始の前にＣＣＡを実行する。

【0284】

図１８に示したユーザ機器９１０の例示的な動作を再び参照し、ユーザ機器９１０は、スロット＃７の開始の前に、すなわち、値２２を有する「ｐｒａｃｈ－ＣｏｎｆｉｇｕｒａｔｉｏｎＩｎｄｅｘ」によってＰＲＡＣＨ用のチャネルリソースとして示され、かつ「ＣＯＴ構造」によって指定されるアップリンクシンボルを含むものと肯定的に判定されているタイミングの開始の前に、ＣＣＡを実際に実行する。なおｇＮＢは、ＣＣＡを容易にするため、例えば前のスロット（スロット＃６）の最後のシンボルの一部において信号を送信しないことによって、ギャップを形成しなければならないことに留意されたい。
さらに、ＣＣＡ動作が肯定的（成功）である場合、ユーザ機器９１０は、アップリンク通信用に設定されている少なくとも１個のシンボル（すなわちスロット＃７）内でランダムアクセス（ＲＡ）プリアンブルを送信することによって、チャネルリソースを介してＰＲＡＣＨ送信を実行する（例えば図１７のステップＳ１３を参照）。

【0285】

［さらなる態様］
第１の態様によれば、プロセッサ、受信機、および送信機を備えたユーザ機器（ＵＥ）が提供される。プロセッサは、動作時、受信されたアンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定する。受信機は、動作時、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を受信する。プロセッサは、動作時、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングが、アップリンク通信用に設定された少なくとも１個のシンボル内に含まれるか否かを判定する。プロセッサは、動作時、判定が肯定である場合、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングの開始の前のギャップ期間を対象に、空きチャネル判定（ＣＣＡ）を実行する。送信機は、動作時、ＣＣＡが肯定的である場合、アップリンク通信用に設定された少なくとも１個のシンボル内で、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングにおいて、ランダムアクセス（ＲＡ）プリアンブルを送信することによって、ＰＲＡＣＨ送信を実行する。

【0286】

第１の態様に加えて提供される第２の態様によれば、受信機は、動作時、ＰＲＡＣＨ送信を実行する前に空きチャネル判定（ＣＣＡ）を実行する対象のギャップ期間の指示情報をさらに受信する。

【0287】

第１の態様に加えて提供される第３の態様によれば、受信機が動作時にギャップ期間の指示情報を受信しない場合、プロセッサが、動作時、乱数Ｎを発生させ、乱数Ｎに基づいて変化するギャップ期間を対象にＣＣＡを実行する。

【0288】

第１の態様または第２の態様に加えて提供される第４の態様によれば、ギャップ期間の指示情報が、複数のギャップ期間のうちの１つのギャップ期間の指示情報、複数のリッスンビフォアトーク（ＬＢＴ）カテゴリのうち、１つのギャップ期間と組み合わせて使用される１つのＬＢＴカテゴリの指示情報、および、複数のＬＢＴカテゴリのうち一緒に使用される１つのＬＢＴカテゴリの指示情報との組合せにおける、複数のギャップ期間のうちの１つのギャップ期間の指示情報、のうちの１つである。

【0289】

第４の態様に加えて提供される第５の態様によれば、ギャップ期間が、１６μｓおよび２５μｓの一方であり、かつＬＢＴカテゴリが、ＬＢＴカテゴリ１、ＬＢＴカテゴリ２、ＬＢＴカテゴリ３、およびＬＢＴカテゴリ４、のうちの１つである。

【0290】

第１の態様または第２の態様に加えて提供される第６の態様によれば、ギャップ期間の指示情報が、ＰＲＡＣＨ送信が実行されないことの指示情報である。

【0291】

第１の態様から第６の態様に加えて提供される第７の態様によれば、受信機が、動作時、時間インスタンスから始まりアンライセンスチャネルが占有されている期間にわたる占有時間を設定する半静的なシグナリング、および、シグナリングが受信されたときを基準とする占有時間の少なくとも一部を設定する動的シグナリング、の一方の形におけるアンライセンスチャネルアクセス設定、をさらに受信する。

【0292】

第１の態様から第７の態様に加えて提供される第８の態様によれば、プロセッサが、動作時、チャネルリソースの開始時刻および／または持続時間の形でタイミングを示す半静的なシグナリング、少なくともいくつかの前に設定されたチャネルリソースに対する有効化／無効化情報の形でタイミングを示す動的シグナリング、少なくともいくつかのチャネルリソースの開始時刻および／または持続時間の形でタイミングを示す動的シグナリング、のうちの１つから、チャネルリソースの示されたタイミングを推測する。

【0293】

第８の態様に加えて提供される第９の態様によれば、プロセッサが、示されたタイミングを半静的なシグナリングから推測する場合、チャネルリソースの示されたタイミングが、アンライセンスチャネルの占有時間を対象に事前に設定されている。

【0294】

第８の態様に加えて提供される第１０の態様によれば、プロセッサが、示されたタイミングを動的シグナリングから推測する場合、有効化／無効化される少なくともいくつかの前に設定されたチャネルリソースが、シグナリングが受信されたときを基準とする。

【0295】

第８の態様に加えて提供される第１１の態様によれば、プロセッサが、示されたタイミングを動的シグナリングから推測する場合、チャネルリソースの示されたタイミングが、シグナリングが受信されたときを基準とするアンライセンスチャネルの占有時間の一部を対象とする。

【0296】

第７の態様から第１１の態様に加えて提供される第１２の態様によれば、半静的なシグナリングは、それぞれの設定および／または指示情報を伝える情報要素を有する少なくとも１つのブロードキャストシステム情報（ＳＩ）ブロックまたはメッセージまたは専用ＲＲＣメッセージを好ましくは含む、無線リソース制御（ＲＲＣ）シグナリングである。

【0297】

第７の態様から第１１の態様に加えて提供される第１３の態様によれば、動的シグナリングは、それぞれの設定および／または指示情報を伝える少なくとも１つのＭＡＣ制御要素（ＭＡＣＣＥ）を好ましくは含む媒体アクセス制御（ＭＡＣ）シグナリング、および、それぞれの設定および／または指示情報を伝える少なくとも１つのダウンリンク制御情報（ＤＣＩ）を好ましくは含む物理（ＰＨＹ）シグナリング、のうちの一方である。

【0298】

第１の態様から第１３の態様に加えて提供される第１４の態様によれば、送信機は、動作時、ＣＣＡが否定的である場合、チャネルリソースを介してＰＲＡＣＨ送信を実行しない。

【0299】

第１の態様から第１４の態様に加えて提供される第１５の態様によれば、受信機は、動作時、ＰＲＡＣＨ送信に使用されるチャネルリソースのタイミングの指示情報を、チャネル占有時間（ＣＯＴ）構造情報の形で受信する、および／または、ＣＯＴ構造情報が、占有時間の少なくとも１つのスロットのシンボルを、アップリンク通信またはダウンリンク通信用にプロセッサによってそれぞれ設定されるアップリンクシンボル、ダウンリンクシンボル、またはフレキシブルシンボルの１つとして指定する、および／または、ＣＯＴ構造情報が、占有時間の複数のスロットのシンボルを、アップリンクシンボル、ダウンリンクシンボル、またはフレキシブルシンボルの１つとして指定する場合、受信機が、動作時、アップリンク通信用のアンライセンスチャネルの占有時間に関する、部分的に重複する複数のＣＯＴ構造情報を受信する。

【0300】

第１６の態様によれば、ユーザ機器（ＵＥ）によって実行される以下のステップ、すなわち、受信されたアンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定するステップと、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を受信するステップと、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングが、アップリンク通信用に設定された少なくとも１個のシンボル内に含まれるか否かを判定するステップと、判定が肯定である場合、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングの開始の前のギャップ期間を対象に、空きチャネル判定（ＣＣＡ）を実行するステップと、ＣＣＡが肯定的である場合、アップリンク通信用に設定された少なくとも１個のシンボル内で、ＰＲＡＣＨ送信に使用されるチャネルリソースの示されたタイミングにおいて、ランダムアクセス（ＲＡ）プリアンブルを送信することによって、ＰＲＡＣＨ送信を実行するステップと、を含む方法、を提供する。

【0301】

第１７の態様によれば、プロセッサ、送信機、および受信機を備えた基地局（ＢＳ）を提供する。プロセッサは、動作時、アンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のそれぞれのアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定する。送信機は、動作時、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を送信する。プロセッサは、動作時、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングが、アップリンク通信用に設定された少なくとも１個のシンボル内に含まれるか否かを判定する。プロセッサは、動作時、判定が肯定である場合、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングの開始の前にギャップ期間を有する送信ギャップが設定されているか否かを識別する。受信機は、動作時、送信ギャップの識別が肯定である場合、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングにおいて、アップリンク通信用に設定された少なくとも１個のシンボル内で送信されるランダムアクセス（ＲＡ）プリアンブルの形におけるＰＲＡＣＨ送信を受信する。

【0302】

第１８の態様によれば、基地局（ＢＳ）によって実行される以下のステップ、すなわち、アンライセンスチャネルアクセス設定に基づいて、アップリンク通信用のアンライセンスチャネルの占有時間の少なくとも１個のシンボルを設定するステップと、物理ランダムアクセスチャネル（ＰＲＡＣＨ）送信に使用されるチャネルリソースのタイミングの指示情報を送信するステップと、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングが、アップリンク通信用に設定された少なくとも１個のシンボル内に含まれるか否かを判定するステップと、判定が肯定である場合、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングの開始の前にギャップ期間を有する送信ギャップが設定されているか否かを識別するステップと、送信ギャップの識別が肯定である場合、ＰＲＡＣＨ送信に使用されるチャネルリソースの示したタイミングにおいて、アップリンク通信用に設定された少なくとも１個のシンボル内で送信されるランダムアクセス（ＲＡ）プリアンブルの形におけるＰＲＡＣＨ送信を受信するステップと、を含む方法、を提供する。

【0303】

［ハードウェアおよびソフトウェアによる本開示の実施］
本開示は、ソフトウェアによって、ハードウェアによって、またはハードウェアと協働するソフトウェアによって、実施することができる。上述した各実施形態の説明において使用される各機能ブロックは、その一部または全体を、集積回路などのＬＳＩによって実施することができ、各実施形態で説明されている各プロセスは、その一部または全体を、同じＬＳＩまたはＬＳＩの組合せによって制御することができる。

【0304】

ＬＳＩは、チップとして個別に形成する、または、機能ブロックの一部またはすべてが含まれるように１個のチップを形成することができる。ＬＳＩは、自身に結合されたデータ入出力部を含むことができる。

【0305】

ＬＳＩは、集積度の違いに応じて、ＩＣ（集積回路）、システムＬＳＩ、スーパーＬＳＩ、またはウルトラＬＳＩと称される。しかしながら、集積回路を実施する技術は、ＬＳＩに限定されず、専用回路、汎用プロセッサ、または専用プロセッサを使用することによって実施することができる。さらには、ＬＳＩの製造後にプログラムすることのできるＦＰＧＡ（フィールドプログラマブルゲートアレイ）や、ＬＳＩ内部に配置されている回路セルの接続および設定を再設定できるリコンフィギャラブル・プロセッサを使用することもできる。

【0306】

本開示は、デジタル処理またはアナログ処理として実施することができる。半導体技術または別の派生技術が進歩する結果として、将来の集積回路技術がＬＳＩに置き換わる場合、その将来の集積回路技術を使用して機能ブロックを集積化することができる。バイオテクノロジを適用することもできる。

【0307】

本開示は、通信の機能を有する任意の種類の装置、デバイス、またはシステム（通信装置と呼ばれる）によって実施することができる。

【0308】

このような通信装置の非限定的ないくつかの例としては、電話（例：携帯電話、スマートフォン）、タブレット、パーソナルコンピュータ（ＰＣ）（例：ラップトップ、デスクトップ、ノートブック）、カメラ（例：デジタルスチル／ビデオカメラ）、デジタルプレイヤー（デジタルオーディオ／ビデオプレイヤー）、ウェアラブルデバイス（例：ウェアラブルカメラ、スマートウォッチ、トラッキングデバイス）、ゲームコンソール、電子書籍リーダー、遠隔医療／テレメディシン（リモート医療・医薬）装置、通信機能を提供する車両（例：自動車、飛行機、船舶）、およびこれらの様々な組合せ、が挙げられる。

【0309】

通信装置は、携帯型または可搬型に限定されず、非携帯型または据え付け型である任意の種類の装置、デバイス、またはシステム、例えば、スマートホームデバイス（例：電化製品、照明、スマートメーター、制御盤）、自動販売機、および「モノのインターネット（ＩｏＴ：ＩｎｔｅｒｎｅｔｏｆＴｈｉｎｇｓ）」のネットワーク内の任意の他の「モノ」なども含むことができる。

【0310】

通信は、例えばセルラーシステム、無線ＬＡＮシステム、衛星システム、その他、およびこれらの様々な組合せを通じて、データを交換するステップを含むことができる。

【0311】

通信装置は、本開示に説明されている通信の機能を実行する通信デバイスに結合されたコントローラやセンサなどのデバイスを備えることができる。例えば、通信装置は、通信装置の通信機能を実行する通信デバイスによって使用される制御信号またはデータ信号を生成するコントローラまたはセンサ、を備えていることができる。

【0312】

通信装置は、インフラストラクチャ設備、例えば、上の非限定的な例における装置等の装置と通信する、またはそのような装置を制御する基地局、アクセスポイント、および任意の他の装置、デバイス、またはシステムなどを、さらに含むことができる。

【0313】

さらに、様々な実施形態は、ソフトウェアモジュールによって実施してもよく、これらのソフトウェアモジュールは、プロセッサによって実行される、または、ハードウェアにおいて直接実行される。また、ソフトウェアモジュールとハードウェア実装の組合せも可能である。ソフトウェアモジュールは、任意の種類のコンピュータ可読記憶媒体、例えば、ＲＡＭやＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、レジスタ、ハードディスク、ＣＤ－ＲＯＭ、ＤＶＤなどに格納することができる。さらには、複数の異なる実施形態の個々の特徴は、個々に、または任意の組合せにおいて、別の実施形態の主題とすることができることに留意されたい。

【0314】

具体的な実施形態に示した本開示には、様々な変更および／または修正を行うことができることが、当業者には理解されるであろう。したがって、本明細書に示した実施形態は、あらゆる点において例示的であり、本発明を制限しないものとみなされる。

【図1】