JP2021508422A - グラントフリーアップリンク送信 - Google Patents

グラントフリーアップリンク送信 Download PDF

Info

Publication number
JP2021508422A
JP2021508422A JP2020526408A JP2020526408A JP2021508422A JP 2021508422 A JP2021508422 A JP 2021508422A JP 2020526408 A JP2020526408 A JP 2020526408A JP 2020526408 A JP2020526408 A JP 2020526408A JP 2021508422 A JP2021508422 A JP 2021508422A
Authority
JP
Japan
Prior art keywords
wtru
transmission
resource
retransmission
priority
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2020526408A
Other languages
English (en)
Other versions
JP2021508422A5 (ja
JP7277456B2 (ja
Inventor
アハマド・レザ・ヘダーヤト
シャーロック・ナイェビ・ナザル
オーヘンコーム・オテリ
Original Assignee
アイディーエーシー ホールディングス インコーポレイテッド
アイディーエーシー ホールディングス インコーポレイテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by アイディーエーシー ホールディングス インコーポレイテッド, アイディーエーシー ホールディングス インコーポレイテッド filed Critical アイディーエーシー ホールディングス インコーポレイテッド
Publication of JP2021508422A publication Critical patent/JP2021508422A/ja
Publication of JP2021508422A5 publication Critical patent/JP2021508422A5/ja
Priority to JP2023076723A priority Critical patent/JP2023106450A/ja
Application granted granted Critical
Publication of JP7277456B2 publication Critical patent/JP7277456B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1887Scheduling and prioritising arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1664Details of the supervisory signal the supervisory signal being transmitted together with payload signals; piggybacking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1812Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • H04L1/1819Hybrid protocols; Hybrid automatic repeat request [HARQ] with retransmission of additional or different redundancy
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867Arrangements specially adapted for the transmitter end
    • H04L1/1896ARQ related signaling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/08Non-scheduled access, e.g. ALOHA
    • H04W74/0808Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W74/00Wireless channel access
    • H04W74/08Non-scheduled access, e.g. ALOHA
    • H04W74/0808Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA]
    • H04W74/0816Non-scheduled access, e.g. ALOHA using carrier sensing, e.g. carrier sense multiple access [CSMA] with collision avoidance

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

無線送信/受信ユニット(WTRU)は、各々が優先度と関連付けられてもよい第1の部分および第2の優先度と関連付けられた第2の部分を含むグラントフリー送信を送ってもよい。第1の部分の優先度は、第2の部分の優先度よりも高くてもよい。WTRUは、バックオフ値の第1の範囲から第1のバックオフ値を選択してもよい。WTRUは、グラントフリー送信が成功したかどうかを判定してもよい。グラントフリー送信が成功しなかった場合、WTRUは、グラントフリー送信の再送信を送ってもよく、グラントフリー送信の再送信は、第1の部分を含んでもよく、第2の部分を含まなくてもよい。再送信は、バックオフ値の第1の範囲よりも大きくてもよい、バックオフ値の第2の範囲から第2のバックオフ値を選択してもよい。第2のバックオフ値は、再送信を送る前にスキップするグラントフリーリソースの数を示してもよい。

Description

本出願は、参照によってその全体が本明細書に組み込まれる、2017年11月15日に出願された米国仮特許出願第62/586,473号からの優先権を主張する。
無線通信システムでは、中央ノードは、1つまたは複数の無線送信/受信ユニット(WTRU)にサービス提供することができる。中央ノードが1つまたは複数のWTRUにサービスを提供するとき、中央ノードにトランスポートブロック(TB)を送信する機会は、中央ノードによって管理されることがある。例えば、中央ノードは、WTRUアップリンク(UL)送信をスケジュールすることがある。
無線送信/受信ユニット(WTRU)は、グラントフリーリソース上でグラントフリー送信を送ってもよい。WTRUは、第1の部分および第2の部分を含むグラントフリー送信を送ってもよい。第1の部分および第2の部分は各々、優先度と関連付けられてもよい。第1の部分と関連付けられた優先度は、第2の部分と関連付けられた優先度よりも高い優先度であってもよい。例えば、第1の部分は、確認応答情報(例えば、ハイブリッド自動再送要求(HARQ))を含んでもよく、第2の部分は、チャネル品質情報(CQI)を含んでもよい。WTRUは、バックオフ値の第1の範囲から第1のグラントフリー送信に対する第1のバックオフ値を選択してもよい。WTRUは、第1のグラントフリー送信が成功したかどうかを判定してもよい。第1のグラントフリー送信が成功しなかった場合、WTRUは、第1のグラントフリー送信の再送信を送ってもよい。再送信は、第1の部分を含んでもよく、第2の部分を含まなくてもよい。WTRUは、バックオフ値の第2の範囲から再送信に対する第2のバックオフ値を選択してもよい。バックオフ値の第2の範囲は、バックオフ値の第1の範囲よりも大きくてもよい。バックオフ値の第2の範囲は、再送信を送る前にスキップするグラントフリーリソースの数を示してもよい。
多重化は、第1のグラントフリー送信および/または第1のグラントフリー送信の再送信に対して使用されてもよい。第1のグラントフリー送信は、第1の冗長バージョンを使用して、トランスポートブロック上で多重化されてもよい。再送信は、第2の冗長バージョンを使用して、別のトランスポートブロック上で多重化されてもよい。第2の冗長バージョンは、第1の冗長バージョンよりも高い冗長性と関連付けられてもよい。
添付図面と共に実施例を考慮して、以下の説明からより詳細な理解を得ることができる。
1つまたは複数の開示される実施形態を実装することができる例示的な通信システムを例示するシステム図である。 実施形態に従った、図1Aに例示された通信システム内で使用することができる例示的な無線送信/受信ユニット(WTRU)を例示するシステム図である。 実施形態に従った、図1Aに例示された通信システム内で使用することができる例示的な無線アクセスネットワーク(RAN)および例示的なコアネットワーク(CN)を例示するシステム図である。 実施形態に従った、図1Aに例示された通信システム内で使用することができる更なる例示的なRANおよび更なる例示的なCNを例示するシステム図である。 スロットの間のスケジュールされたグラントフリー(GF:grant−free)リソースの例を示す。 スロット内でスケジュールされた(例えば、gNodeB(gNB)によってスロット内でスケジュールされた)例示的なグラントフリーリソースを示す。 スロット内でスケジュールされた(例えば、gNBによってスロット内でスケジュールされた)例示的なグラントフリーリソースおよび無線送信/受信ユニット(WTRU)の保留(pending)トランスポートブロック(TB)についてのリソースを使用することを試みている3つのWTRUを示す。 スロット内でスケジュールされた(例えば、gNBによってスロット内でスケジュールされた)例示的なグラントフリーリソースおよびWTRUの保留TBについてのリソースを使用することを試みている3つのWTRUを示す。
例示的な実施形態を含むことができる詳細な説明は、様々な図面を参照してここで説明される。この詳細な説明は、取り得る実装態様の詳細な実施例を提供することができるが、詳細は例示的であることを意図しており、本出願の範囲を限定することを意図していないことに留意されるべきである。
図1Aは、1つまたは複数の開示される実施形態を実装することができる、例示的な通信システム100を示す図である。通信システム100は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムであってもよい。通信システム100は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通じて、そのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム100は、符号分割多元接続(CDMA)、時分割多元接続(TDMA)、周波数分割多元接続(FDMA)、直交FDMA(OFDMA)、シングルキャリアFDMA(SC−FDMA)、ゼロテールユニークワードDFT拡散OFDM(ZT UW DTS−s OFDM)、ユニークワードOFDM(UW−OFDM)、リソースブロックフィルタードOFDM、およびフィルタバンクマルチキャリア(FBMC)など、1つまたは複数のチャネルアクセス方法を利用してもよい。
図1Aに示されるように、通信システム100は、無線送信/受信ユニット(WTRU)102a、102b、102c、102dと、RAN104/113と、CN106/115と、公衆交換電話網(PSTN)108と、インターネット110と、他のネットワーク112とを含んでもよいが、開示される実施形態は、いずれかの数のWTRU、基地局、ネットワーク、および/またはネットワーク要素を考慮していることが認識されよう。WTRU102a、102b、102c、102dの各々は、無線環境において動作および/または通信するように構成されたいずれかのタイプのデバイスであってもよい。例として、そのいずれかが、「局」および/または「STA」と称されてもよい、WTRU102a、102b、102c、102dは、無線信号を送信および/または受信するように構成されてもよく、ユーザ機器(UE)、移動局、固定または移動加入者ユニット、サブスクリクションベースのユニット、ページャ、セルラ電話、パーソナルデジタルアシスタント(PDA)、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポットまたはMi−Fiデバイス、モノノインターネット(IoT)デバイス、ウォッチまたは他のウェアラブル、ヘッドマウントディスプレイ(HMD)、車両、ドローン、医療用デバイスおよびアプリケーション(例えば、遠隔手術)、工業用デバイスおよびアプリケーション(例えば、工業用および/または自動化された処理チェーン状況において動作するロボットおよび/または他の無線デバイス)、家電デバイス、ならびに商業用および/または工業用無線ネットワーク上において動作するデバイスなどを含んでもよい。WTRU102a、102b、102c、102dのいずれも、交換可能にUEと称されてもよい。
通信システム100はまた、基地局114aおよび/または基地局114bを含んでもよい。基地局114a、114bの各々は、CN106/115、インターネット110、および/または他のネットワーク112など、1つまたは複数の通信ネットワークへのアクセスを容易にするために、WTRU102a、102b、102c、102dのうちの少なくとも1つと無線でインタフェースをとるように構成されたいずれかのタイプのデバイスであってもよい。例として、基地局114a、114bは、基地送受信機局(BTS)、NodeB、eNodeB、ホームNodeB、ホームeNodeB、gNB、NR NodeB、サイトコントローラ、アクセスポイント(AP)、および無線ルータなどであってもよい。基地局114a、114bは、各々が、単一の要素として表されているが、基地局114a、114bは、任意の数の相互接続された基地局および/またはネットワーク要素を含んでもよいことが理解されよう。
基地局114aは、RAN104/113の一部であってもよく、RAN104/113は、他の基地局、および/または基地局コントローラ(BSC)、無線ネットワークコントローラ(RNC)、中継ノードなどのネットワーク要素(図示されず)も含んでもよい。基地局114aおよび/または基地局114bは、セル(図示されず)と称されてもよい、1つまたは複数のキャリア周波数上において、無線信号を送信および/または受信するように構成されてもよい。これらの周波数は、認可スペクトル、非認可スペクトル、または認可スペクトルと非認可スペクトルとの組み合わせの中にあってもよい。セルは、相対的に固定であってもよくまたは時間とともに変化してもよい特定の地理的エリアに、無線サービス用のカバレージを提供してもよい。セルは、更に、セルセクタに分割されてもよい。例えば、基地局114aと関連付けられたセルは、3つのセクタに分割されてもよい。したがって、一実施形態では、基地局114aは、送受信機を3つ、すなわち、セルの各セクタに対して1つずつ含んでよい。実施形態では、基地局114aは、多入力多出力(MIMO)技術を利用してもよく、セルの各セクタに対して複数の送受信機を利用してもよい。例えば、所望の空間方向において信号を送信および/または受信するために、ビームフォーミングが使用されてもよい。
基地局114a、114bは、エアインタフェース116上において、WTRU102a、102b、102c、102dのうちの1つまたは複数と通信してもよく、エアインタフェース116は、いずれかの適切な無線通信リンク(例えば、無線周波(RF)、マイクロ波、センチメートル波、マイクロメートル波、赤外線(IR)、紫外線(UV)、可視光など)であってもよい。エアインタフェース116は、任意の適切な無線アクセス技術(RAT)を使用して確立されてもよい。
より具体的には、上述されたように、通信システム100は、多元接続システムであってもよく、CDMA、TDMA、FDMA、OFDMA、およびSC−FDMAなど、1つまたは複数のチャネルアクセス方式を採用してもよい。例えば、RAN104/113内の基地局114aと、WTRU102a、102b、102cとは、広帯域CDMA(WCDMA)を使用して、エアインタフェース115/116/117を確立してもよい、ユニバーサル移動体通信システム(UMTS)地上無線アクセス(UTRA)などの無線技術を実装してもよい。WCDMAは、高速パケットアクセス(HSPA)および/または進化型HSPA(HSPA+)などの通信プロトコルを含んでよい。HSPAは、高速ダウンリンク(DL)パケットアクセス(HSDPA)、および/または高速アップリンク(UL)パケットアクセス(HSUPA)を含んでもよい。
基地局114a、およびWTRU102a、102b、102cは、ロングタームエボリューション(LTE)、および/またはLTEアドバンスト(LTE−A)、および/またはLTEアドバンストプロ(LTE−A Pro)を使用して、エアインタフェース116を確立してもよい、進化型UMTS地上無線アクセス(E−UTRA)などの無線技術を実装してもよい。
実施形態では、基地局114a、およびWTRU102a、102b、102cは、ニューラジオ(NR)を使用して、エアインタフェース116を確立してもよい、NR無線アクセスなどの無線技術を実装してもよい。
実施形態では、基地局114a、およびWTRU102a、102b、102cは、複数の無線アクセス技術を実装してもよい。例えば、基地局114a、およびWTRU102a、102b、102cは、例えば、デュアルコネクティビティ(DC)原理を使用して、LTE無線アクセスおよびNR無線アクセスを共に実装してもよい。したがって、WTRU102a、102b、102cによって利用されるエアインタフェースは、複数のタイプの無線アクセス技術、ならびに/または複数のタイプの基地局(例えば、eNBおよびgNB)に送信される/そこから送信される送信によって特徴付けられてもよい。
他の実施形態では、基地局114a、およびWTRU102a、102b、102cは、IEEE802.11(すなわち、ワイヤレスフィデリティ(WiFi))、IEEE802.16(すなわち、Worldwide Interoperability for Microwave Access(WiMAX))、CDMA2000、CDMA2000 1X、CDMA2000 EV−DO、暫定標準2000(IS−2000)、暫定標準95(IS−95)、暫定標準856(IS−856)、移動体通信用グローバルシステム(GSM)、GSMエボリューション用高速データレート(EDGE)、およびGSM EDGE(GERAN)などの無線技術を実装してもよい。
図1Aにおける基地局114bは、例えば、無線ルータ、ホームNodeB、ホームeNodeB、またはアクセスポイントであってもよく、事業所、自宅、車両、キャンパス、産業用施設、(例えば、ドローンによって使用される)エアコリド、および車道など、局所化されたエリアにおける無線接続性を容易にするために、任意の適切なRATを利用してもよい。一実施形態では、基地局114bと、WTRU102c、102dとは、IEEE802.11などの無線技術を実装して、無線ローカルエリアネットワーク(WLAN)を確立してもよい。実施形態では、基地局114bと、WTRU102c、102dとは、IEEE802.15などの無線技術を実装して、無線パーソナルエリアネットワーク(WPAN)を確立してもよい。また別の実施形態では、基地局114bと、WTRU102c、102dとは、セルラベースのRAT(例えば、WCDMA、CDMA2000、GSM、LTE、LTE−A、LTE−A Pro、NRなど)を利用して、ピコセルまたはフェムトセルを確立してもよい。図1Aに示されるように、基地局114bは、インターネット110への直接的な接続を有してもよい。したがって、基地局114bは、CN106/115を介してインターネット110にアクセスする必要がないことがある。
RAN104/113は、CN106/115と通信してもよく、CN106/115は、音声、データ、アプリケーション、および/またはボイスオーバインターネットプロトコル(VoIP)サービスを、WTRU102a、102b、102c、102dのうちの1つまたは複数に提供するように構成された任意のタイプのネットワークであってもよい。データは、異なるスループット要件、遅延要件、エラー耐性要件、信頼性要件、データスループット要件、およびモビリティ要件など、様々なサービス品質(QoS)要件を有してもよい。CN106/115は、呼制御、ビリングサービス、モバイルロケーションベースのサービス、プリペイド発呼、インターネット接続性、ビデオ配信などを提供してもよく、および/またはユーザ認証など、高レベルセキュリティ機能を実行してもよい。図1Aには示されていないが、RAN104/113および/またはCN106/115は、RAN104/113と同じRATまたは異なるRATを利用する他のRANと直接的または間接的通信を行ってもよいことが理解されよう。例えば、NR無線技術を利用していることがあるRAN104/113に接続されていることに加えて、CN106/115は、GSM、UMTS、CDMA2000、WiMAX、E−UTRA、またはWiFi無線技術を利用する別のRAN(図示されず)とも通信してもよい。
CN106/115は、WTRU102a、102b、102c、102dが、PSTN108、インターネット110、および/または他のネットワーク112にアクセスするためのゲートウェイとしての役割も果たしてもよい。PSTN108は、基本電話サービスを提供する、回線交換電話網を含んでよい。インターネット110は、TCP/IPインターネットプロトコルスイート内の送信制御プロトコル(TCP)、ユーザデータグラムプロトコル(UDP)、および/またはインターネットプロトコル(IP)など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスからなる地球規模のシステムを含んでよい。ネットワーク112は、他のサービスプロバイダによって所有および/または運営される、有線および/または無線通信ネットワークを含んでもよい。例えば、ネットワーク112は、RAN104/113と同じRATまたは異なるRATを利用してもよい1つまたは複数のRANに接続された、別のCNを含んでもよい。
通信システム100内のWTRU102a、102b、102c、102dのうちのいくつかまたは全ては、マルチモード機能を含んでよい(例えば、WTRU102a、102b、102c、102dは、異なる無線リンク上において、異なる無線ネットワークと通信するための、複数の送受信機を含んでよい)。例えば、図1Aに示されるWTRU102cは、セルラベースの無線技術を採用してもよい基地局114aと通信するように、またIEEE802無線技術を利用してもよい基地局114bと通信するように構成されてもよい。
図1Bは、例示的なWTRU102を示すシステム図である。図1Bに示されるように、WTRU102は、とりわけ、プロセッサ118、送受信機120、送信/受信要素122、スピーカ/マイクロフォン124、キーパッド126、ディスプレイ/タッチパッド128、非リムーバブルメモリ130、リムーバブルメモリ132、電源134、全地球測位システム(GPS)チップセット136、および/または他の周辺機器138を含んでよい。WTRU102は、実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含んでよいことが理解されよう。
プロセッサ118は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアと連携する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、他の任意のタイプの集積回路(IC)、および状態機械などであってもよい。プロセッサ118は、信号コーディング、データ処理、電力制御、入力/出力処理、および/またはWTRU102が無線環境において動作することを可能にする他の任意の機能性を実行してもよい。プロセッサ118は、送受信機120に結合されてもよく、送受信機120は、送信/受信要素122に結合されてもよい。図1Bは、プロセッサ118と送受信機120を別個の構成要素として表しているが、プロセッサ118と送受信機120は、電子パッケージまたはチップ内に一緒に統合されてもよいことが理解されよう。
送信/受信要素122は、エアインタフェース116上において、基地局(例えば、基地局114a)に信号を送信し、または基地局から信号を受信するように構成されてもよい。例えば、一実施形態では、送信/受信要素122は、RF信号を送信および/または受信するように構成されたアンテナであってもよい。実施形態では、送信/受信要素122は、例えば、IR、UV、または可視光信号を送信および/または受信するように構成された放射器/検出器であってもよい。また別の実施形態では、送信/受信要素122は、RF信号および光信号の両方を送信および/または受信するように構成されてもよい。送信/受信要素122は、無線信号の任意の組み合わせを送信および/または受信するように構成されてもよいことが理解されよう。
図1Bにおいては、送信/受信要素122は、単一の要素として表されているが、WTRU102は、任意の数の送信/受信要素122を含んでよい。より具体的には、WTRU102は、MIMO技術を利用してもよい。したがって、一実施形態では、WTRU102は、エアインタフェース116上において無線信号を送信および受信するための2つ以上の送信/受信要素122(例えば、複数のアンテナ)を含んでよい。
送受信機120は、送信/受信要素122によって送信されることになる信号を変調し、送信/受信要素122によって受信された信号を復調するように構成されてもよい。上で言及されたように、WTRU102は、マルチモード機能を有してもよい。したがって、送受信機120は、WTRU102が、例えば、NRおよびIEEE802.11など、複数のRATを介して通信することを可能にするための、複数の送受信機を含んでよい。
WTRU102のプロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128(例えば、液晶表示(LCD)ディスプレイユニットもしくは有機発光ダイオード(OLED)ディスプレイユニット)に結合されてもよく、それらからユーザ入力データを受信してもよい。プロセッサ118は、スピーカ/マイクロフォン124、キーパッド126、および/またはディスプレイ/タッチパッド128にユーザデータを出力してもよい。加えて、プロセッサ118は、非リムーバブルメモリ130および/またはリムーバブルメモリ132など、任意のタイプの適切なメモリから情報を入手してもよく、それらにデータを記憶してもよい。非リムーバブルメモリ130は、ランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含んでよい。リムーバブルメモリ132は、加入者識別モジュール(SIM)カード、メモリスティック、およびセキュアデジタル(SD)メモリカードなどを含んでよい。他の実施形態では、プロセッサ118は、サーバまたはホームコンピュータ(図示されず)上などに配置された、WTRU102上に物理的に配置されていないメモリから情報を入手してもよく、それらにデータを記憶してもよい。
プロセッサ118は、電源134から電力を受け取ってもよく、WTRU102内の他の構成要素に電力を分配するように、および/またはそれらへの電力を制御するように構成されてもよい。電源134は、WTRU102に給電するための任意の適切なデバイスであってもよい。例えば、電源134は、1つまたは複数の乾電池(例えば、ニッケル−カドミウム(NiCd)、ニッケル−亜鉛(NiZn)、ニッケル水素(NiMH)、リチウム−イオン(Li−ion)など)、太陽電池、および燃料電池などを含んでよい。
プロセッサ118は、GPSチップセット136にも結合されてもよく、GPSチップセット136は、WTRU102の現在のロケーションに関するロケーション情報(例えば、経度および緯度)を提供するように構成されてもよい。GPSチップセット136からの情報に加えて、またはそれの代わりに、WTRU102は、基地局(例えば、基地局114a、114b)からエアインタフェース116上においてロケーション情報を受信してもよく、および/または2つ以上の近くの基地局から受信されている信号のタイミングに基づいて、自らのロケーションを決定してもよい。WTRU102は、実施形態との整合性を保ちながら、任意の適切なロケーション決定方法を用いて、ロケーション情報を取得してもよいことが理解されよう。
プロセッサ118は、更に他の周辺機器138に結合されてもよく、他の周辺機器138は、追加の特徴、機能性、および/または有線もしくは無線接続性を提供する、1つまたは複数のソフトウェアモジュールおよび/またはハードウェアモジュールを含んでよい。例えば、周辺機器138は、加速度計、eコンパス、衛星送受信機、(写真および/またはビデオ用の)デジタルカメラ、ユニバーサルシリアルバス(USB)ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Bluetooth(登録商標)モジュール、周波数変調(FM)ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実および/または拡張現実(VR/AR)デバイス、ならびにアクティビティトラッカなどを含んでよい。周辺機器138は、1つまたは複数のセンサを含んでよく、センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、方位センサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、バイオメトリックセンサ、および/または湿度センサのうちの1つまたは複数であってもよい。
WTRU102は、(例えば、(例えば、送信用の)ULと(例えば、受信用の))ダウンリンクの両方のための特定のサブフレームと関連付けられた信号のいくつかまたは全ての送信および受信が、並列および/または同時であってもよい、全二重無線を含んでよい。全二重無線は、ハードウェア(例えば、チョーク)を介して、またはプロセッサ(例えば、別個のプロセッサ(図示されず)もしくはプロセッサ118)を介する信号処理を介して、自己干渉を低減させ、および/または実質的に除去するために、干渉管理ユニット139を含んでよい。実施形態では、WTRU102は、(例えば、(例えば、送信用の)ULまたは(例えば、受信用の)ダウンリンクのどちらかのための特定のサブフレームと関連付けられた)信号のいくつかまたは全ての送信および受信のための、半二重無線を含んでよい。
図1Cは、実施形態に従った、RAN104およびCN106を例示するシステム図である。上述されたように、RAN104は、エアインタフェース116を通じてWTRU102a、102b、102cと通信するためにE−UTRA無線技術を採用してもよい。RAN104は、CN106とも通信してもよい。
RAN104は、eNodeB160a、160b、160cを含んでよいが、RAN104は、実施形態との整合性を維持しながら、任意の数のeNodeBを含んでよいことが理解されよう。eNodeB160a、160b、160cは、各々が、エアインタフェース116上においてWTRU102a、102b、102cと通信するための、1つまたは複数の送受信機を含んでよい。一実施形態では、eNodeB160a、160b、160cは、MIMO技術を実装してもよい。したがって、eNodeB160aは、例えば、複数のアンテナを使用して、WTRU102aに無線信号を送信し、および/またはWTRU102aから無線信号を受信してもよい。
eNodeB160a、160b、160cの各々は、特定のセル(図示されず)と関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、ならびにULおよび/またはDLにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図1Cに示されるように、eNodeB160a、160b、160cは、X2インタフェース上において、相互に通信してもよい。
図1Cに示されるCN106は、モビリティ管理エンティティ(MME)162と、サービングゲートウェイ(SGW)164と、パケットデータネットワーク(PDN)ゲートウェイ(またはPGW)166とを含んでよい。上記の要素の各々は、CN106の部分として描かれているが、これらの要素のうちのいずれも、CNオペレータとは異なるエンティティによって所有および/または運営されてもよいことが理解されよう。
MME162は、S1インタフェースを介して、RAN104内のeNodeB160a、160b、160cの各々に接続されてもよく、制御ノードとしての役割を果たしてもよい。例えば、MME162は、WTRU102a、102b、102cのユーザを認証すること、ベアラアクティブ化/非アクティブ化、およびWTRU102a、102b、102cの初期アタッチ中に特定のサービングゲートウェイを選択することなどを担ってもよい。MME162は、RAN104と、GSMおよび/またはWCDMAなどの他の無線技術を利用する他のRAN(図示されず)との間における交換のためのコントロールプレーン機能を提供してもよい。
SGW164は、S1インタフェースを介して、RAN104内のeNodeB160a、160b、160cの各々に接続されてもよい。SGW164は、一般に、ユーザデータパケットを、WTRU102a、102b、102cに/WTRU102a、102b、102cからルーティングおよび転送してもよい。SGW164は、eNodeB間ハンドオーバ中にユーザプレーンをアンカリングすること、DLデータがWTRU102a、102b、102cに利用可能なときにページングをトリガすること、ならびにWTRU102a、102b、102cのコンテキストを管理および記憶することなど、他の機能を実行してもよい。
SGW164は、PGW166に接続されてもよく、PGW166は、インターネット110など、パケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にしてもよい。
CN106は、他のネットワークとの通信を容易にすることができる。例えば、CN106は、PSTN108など、回線交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cと従来の固定電話回線通信デバイスとの間の通信を容易にしてもよい。例えば、CN106は、CN106とPSTN108との間のインタフェースとしての役割を果たすIPゲートウェイ(例えば、IPマルチメディアサブシステム(IMS)サーバ)を含んでよく、またはそれと通信してもよい。加えて、CN106は、他のネットワーク112へのアクセスをWTRU102a、102b、102cに提供してもよく、他のネットワーク112は、他のサービスプロバイダによって所有および/または運営される他の有線および/または無線ネットワークを含んでもよい。
図1A乃至図1Dにおいては、WTRUは、無線端末として説明されるが、ある代表的な実施形態では、そのような端末は、通信ネットワークとの有線通信インタフェースを(例えば、一時的または永続的に)使用することができることが企図されている。
代表的な実施形態では、他のネットワーク112は、WLANであってもよい。
インフラストラクチャ基本サービスセット(BSS)モードにあるWLANは、BSSのためのアクセスポイント(AP)と、APと関連付けられた1つまたは複数の局(STA)とを有してもよい。APは、トラフィックをBSS内および/またはBSS外に搬送する、ディストリビューションシステム(DS)または別のタイプの有線/無線ネットワークへのアクセスまたはインタフェースを有してもよい。BSS外部から発信されたSTAへのトラフィックは、APを通じて到着してもよく、STAに配送されてもよい。STAからBSS外部の送信先に発信されたトラフィックは、それぞれの送信先に配送するために、APに送信されてもよい。BSS内のSTA間のトラフィックは、APを通じて送信されてもよく、例えば、送信元STAは、トラフィックをAPに送信してもよく、APは、トラフィックを送信先STAに配送してもよい。BSS内のSTA間のトラフィックは、ピアツーピアトラフィックと見なされてもよく、および/またはピアツーピアトラフィックと呼ばれてもよい。ピアツーピアトラフィックは、直接リンクセットアップ(DLS)を用いて、送信元STAと送信先STAとの間で(例えば、直接的に)送信されてもよい。ある代表的な実施形態では、DLSは、802.11e DLSまたは802.11zトンネルDLS(TDLS)を使用してもよい。独立BSS(IBSS)モードを使用するWLANは、APを有さなくてもよく、IBSS内の、またはIBSSを使用するSTA(例えば、STAの全て)は、相互に直接的に通信してもよい。IBSSモードの通信は、本明細書においては、ときに「アドホック」モードの通信と称されてもよい。
802.11acインフラストラクチャモードの動作または類似したモードの動作を使用するとき、APは、プライマリチャネルなどの固定されたチャネル上において、ビーコンを送信してもよい。プライマリチャネルは、固定された幅(例えば、20MHz幅帯域幅)、またはシグナリングを介して動的に設定された幅であってもよい。プライマリチャネルは、BSSの動作チャネルであってもよく、APとの接続を確立するために、STAによって使用されてもよい。ある代表的な実施形態では、例えば、802.11システムにおいては、キャリアセンス多重アクセス/衝突回避(CSMA/CA)が、実装されてもよい。CSMA/CAの場合、APを含むSTA(例えば、あらゆるSTA)は、プライマリチャネルをセンスしてもよい。プライマリチャネルが、センス/検出され、および/または特定のSTAによってビジーであると決定された場合、特定のSTAは、バックオフしてもよい。与えられたBSS内においては、任意の与えられた時間に、1つのSTA(例えば、ただ1つの局)が、送信してもよい。
高スループット(HT)STAは、例えば、プライマリ20MHzチャネルを隣接または非隣接20MHzチャネルと組み合わせて、40MHz幅のチャネルを形成することを介して、通信のために40MHz幅チャネルを使用してもよい。
超高スループット(VHT)STAは、20MHz、40MHz、80MHz、および/または160MHz幅のチャネルをサポートすることができる。40MHzおよび/または80MHzチャネルは、連続する20MHzチャネルを組み合わせることによって形成されてもよい。160MHzチャネルは、8つの連続する20MHzチャネルを組み合わせることによって形成されてもよく、または2つの非連続な80MHzチャネルを組み合わせることによって形成されてもよく、これは、80+80構成と呼ばれてもよい。80+80構成の場合、データは、チャネルエンコーディングの後、データを2つのストリームに分割し得るセグメントパーサを通過させられてもよい。各ストリームに対して別々に、逆高速フーリエ変換(IFFT)処理、および時間領域処理が、行われてもよい。ストリームは、2つの80MHzチャネル上にマッピングされてもよく、データは、送信STAによって送信されてもよい。受信STAの受信機においては、80+80構成のための上で説明された動作が、逆転されてもよく、組み合わされたデータは、媒体アクセス制御(MAC)に送信されてもよい。
1GHz未満モードの動作は、802.11afおよび802.11ahによってサポートされる。チャネル動作帯域幅およびキャリアは、802.11nおよび802.11acにおいて使用されるそれらと比べて、802.11afおよび802.11ahにおいては低減させられる。802.11afは、TVホワイトスペース(TVWS)スペクトルにおいて、5MHz、10MHz、および20MHz帯域幅をサポートし、802.11ahは、非TVWSスペクトルを使用して、1MHz、2MHz、4MHz、8MHz、および16MHz帯域幅をサポートする。代表的な実施形態に従うと、802.11ahは、マクロカバレージエリアにおけるMTCデバイスなど、メータタイプ制御/マシンタイプコミュニケーションをサポートしてもよい。MTCデバイスは、一定の機能を、例えば、一定の帯域幅および/または限られた帯域幅のサポート(例えば、それらのサポートだけ)を含む限られた機能を有してもよい。MTCデバイスは、(例えば、非常に長いバッテリ寿命を維持するために)閾値を上回るバッテリ寿命を有するバッテリを含んでよい。
802.11n、802.11ac、802.11af、および802.11ahなど、複数のチャネルおよびチャネル帯域幅をサポートすることができるWLANシステムは、プライマリチャネルとして指定されてもよいチャネルを含む。プライマリチャネルは、BSS内の全てのSTAによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有してもよい。プライマリチャネルの帯域幅は、BSS内において動作する全てのSTAの中の、最小帯域幅動作モードをサポートするSTAによって設定および/または制限されてもよい。802.11ahの例においては、BSS内のAPおよび他のSTAが、2MHz、4MHz、8MHz、16MHz、および/または他のチャネル帯域幅動作モードをサポートする場合であっても、1MHzモードをサポートする(例えば、それだけをサポートする)STA(例えば、MTCタイプデバイス)のために、プライマリチャネルは、1MHz幅であってもよい。キャリアセンシングおよび/またはネットワークアロケーションベクトル(NAV)設定は、プライマリチャネルのステータスに依存してもよい。例えば、(1MHz動作モードだけをサポートする)STAが、APに送信しているせいで、プライマリチャネルが、ビジーである場合、周波数バンドの大部分が、アイドルのままであり、利用可能であり得るとしても、利用可能な周波数バンド全体が、ビジーと見なされてもよい。
米国では、802.11ahによって使用されてもよい利用可能な周波数バンドは、902MHzから928MHzである。韓国においては、利用可能な周波数バンドは、917.5MHzから923.5MHzである。日本においては、利用可能な周波数バンドは、916.5MHzから927.5MHzである。802.11ahのために利用可能な合計帯域幅は、国の規則に応じて、6MHzから26MHzである。
図1Dは、実施形態に従った、RAN113およびCN115を例示するシステム図である。上述されたように、RAN113は、NR無線技術を利用して、エアインタフェース116上において、WTRU102a、102b、102cと通信してもよい。RAN113は、CN115とも通信してもよい。
RAN113は、gNB180a、180b、180cを含んでよいが、RAN113は、実施形態との整合性を維持しながら、任意の数のgNBを含んでよいことが理解されよう。gNB180a、180b、180cは、各々が、エアインタフェース116上においてWTRU102a、102b、102cと通信するための、1つまたは複数の送受信機を含んでよい。一実施形態では、gNB180a、180b、180cは、MIMO技術を実装してもよい。例えば、gNB180a、108bは、ビームフォーミングを利用して、gNB180a、180b、180cに信号を送信し、および/またはgNB180a、180b、180cから信号を受信してもよい。したがって、gNB180aは、例えば、複数のアンテナを使用して、WTRU102aに無線信号を送信し、および/またはWTRU102aから無線信号を受信してもよい。実施形態では、gNB180a、180b、180cは、キャリアアグリゲーション技術を実装してもよい。例えば、gNB180aは、WTRU102aに複数のコンポーネントキャリアを送信してもよい(図示されず)。これらのコンポーネントキャリアのサブセットは、免許不要スペクトル上にあってもよいが、残りのコンポーネントキャリアは、免許要スペクトル上にあってもよい。実施形態では、gNB180a、180b、180cは、多地点協調(CoMP)技術を実装してもよい。例えば、WTRU102aは、gNB180aとgNB180b(および/またはgNB180c)とから調整された送信を受信してもよい。
WTRU102a、102b、102cは、スケーラブルなヌメロロジ(numerology)と関連付けられた送信を使用して、gNB180a、180b、180cと通信してもよい。例えば、OFDMシンボル間隔、および/またはOFDMサブキャリア間隔は、異なる送信、異なるセル、および/または無線送信スペクトルの異なる部分ごとに様々であってもよい。WTRU102a、102b、102cは、(例えば、様々な数のOFDMシンボルを含む、および/または様々な長さの絶対時間だけ持続する)様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔(TTI)を使用して、gNB180a、180b、180cと通信してもよい。
gNB180a、180b、180cは、スタンドアロン構成および/または非スタンドアロン構成で、WTRU102a、102b、102cと通信するように構成されてもよい。スタンドアロン構成においては、WTRU102a、102b、102cは、(例えば、eNodeB160a、160b、160cなどの)他のRANにアクセスすることもなしに、gNB180a、180b、180cと通信してもよい。スタンドアロン構成においては、WTRU102a、102b、102cは、gNB180a、180b、180cのうちの1つまたは複数を、モビリティアンカポイントとして利用してもよい。スタンドアロン構成においては、WTRU102a、102b、102cは、免許不要バンド内において信号を使用して、gNB180a、180b、180cと通信してもよい。非スタンドアロン構成においては、WTRU102a、102b、102cは、eNodeB160a、160b、160cなどの別のRANとも通信し/別のRANにも接続しながら、gNB180a、180b、180cと通信し/gNB180a、180b、180cに接続してもよい。例えば、WTRU102a、102b、102cは、DC原理を実装して、1つまたは複数のgNB180a、180b、180c、および1つまたは複数のeNodeB160a、160b、160cと実質的に同時に通信してもよい。非スタンドアロン構成においては、eNodeB160a、160b、160cは、WTRU102a、102b、102cのためのモビリティアンカとしての役割を果たしてもよく、gNB180a、180b、180cは、WTRU102a、102b、102cにサービスするための追加のカバレージおよび/またはスループットを提供することができる。
gNB180a、180b、180cの各々は、特定のセル(図示されず)と関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、ULおよび/またはDLにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアルコネクティビティ、NRとE−UTRAとの間のインターワーキング、ユーザプレーンデータのユーザプレーン機能(UPF)184a、184bへのルーティング、ならびにコントロールプレーン情報のアクセスおよびモビリティ管理機能(AMF)182a、182bへのルーティングなどを処理するように構成されてもよい。図1Dに示されるように、gNB180a、180b、180cは、Xnインタフェース上において、互いに通信してもよい。
図1Dに示されるCN115は、少なくとも1つのAMF182a、182bと、少なくとも1つのUPF184a、184bと、少なくとも1つのセッション管理機能(SMF)183a、183bと、おそらくは、データネットワーク(DN)185a、185bとを含んでよい。上記の要素の各々は、CN115の部分として描かれているが、これらの要素のうちのいずれも、CNオペレータとは異なるエンティティによって所有および/または運営されてもよいことが理解されよう。
AMF182a、182bは、N2インタフェースを介して、RAN113内のgNB180a、180b、180cのうちの1つまたは複数に接続されてもよく、制御ノードとしての役割を果たしてもよい。例えば、AMF182a、182bは、WTRU102a、102b、102cのユーザを認証すること、ネットワークスライシングのサポート(例えば、異なる要件を有する異なるPDUセッションの処理)、特定のSMF183a、183bを選択すること、レジストレーションエリアの管理、NASシグナリングの終了、およびモビリティ管理などを担ってもよい。ネットワークスライシングは、WTRU102a、102b、102cによって利用されるサービスのタイプに基づいて、WTRU102a、102b、102cに対するCNサポートをカスタマイズするために、AMF182a、182bによって使用されてもよい。例えば、超高信頼低遅延(URLLC)アクセスに依存するサービス、高速大容量モバイルブロードバンド(eMBB)アクセスに依存するサービス、および/またはマシンタイプコミュニケーション(MTC)アクセスのためのサービスなど、異なる使用事例のために、異なるネットワークスライスが、確立されてもよい。AMF162は、RAN113と、LTE、LTE−A、LTE−A Pro、および/またはWiFiなどの非3GPPアクセス技術など、他の無線技術を利用する他のRAN(図示されず)との間の交換のためのコントロールプレーン機能を提供してもよい。
SMF183a、183bは、N11インタフェースを介して、CN115内のAMF182a、182bに接続されてもよい。SMF183a、183bは、N4インタフェースを介して、CN115内のUPF184a、184bにも接続されてもよい。SMF183a、183bは、UPF184a、184bを選択および制御し、UPF184a、184bを通じたトラフィックのルーティングを構成してもよい。SMF183a、183bは、UE IPアドレスの管理および割り当てを行うこと、PDUセッションを管理すること、ポリシ実施およびQoSを制御すること、ならびにダウンリンクデータ通知を提供することなど、他の機能を実行してもよい。PDUセッションタイプは、IPベース、非IPベース、およびイーサネットベースなどであってもよい。
UPF184a、184bは、N3インタフェースを介して、RAN113内のgNB180a、180b、180cのうちの1つまたは複数に接続されてもよく、それらは、インターネット110など、パケット交換ネットワークへのアクセスをWTRU102a、102b、102cに提供して、WTRU102a、102b、102cとIP対応デバイスとの間の通信を容易にしてもよい。UPF184a、184bは、パケットをルーティングおよび転送すること、ユーザプレーンポリシを実施すること、マルチホーミングPDUセッションをサポートすること、ユーザプレーンQoSを処理すること、ダウンリンクパケットをバッファすること、ならびにモビリティアンカリングを提供することなど、他の機能を実行してもよい。
CN115は、他のネットワークとの通信を容易にすることができる。例えば、CN115は、CN115とPSTN108との間のインタフェースとしての役割を果たすIPゲートウェイ(例えば、IPマルチメディアサブシステム(IMS)サーバ)を含んでよく、またはそれと通信してもよい。加えて、CN115は、他のネットワーク112へのアクセスをWTRU102a、102b、102cに提供してもよく、他のネットワーク112は、他のサービスプロバイダによって所有および/または運営される他の有線および/または無線ネットワークを含んでよい。一実施形態では、WTRU102a、102b、102cは、UPF184a、184bへのN3インタフェース、およびUPF184a、184bとDN185a、185bとの間のN6インタフェースを介して、UPF184a、184bを通じて、ローカルデータネットワーク(DN)185a、185bに接続されてもよい。
図1A乃至図1D、および図1A乃至図1DDについての対応する説明に鑑みて、WTRU102a乃至d、基地局114a乃至b、eNodeB160a乃至c、MME162、SGW164、PGW166、gNB180a乃至c、AMF182a乃至b、UPF184a乃至b、SMF183a乃至b、DN185a乃至b、および/または本明細書において説明される他の任意のデバイスのうちの1つまたは複数に関する、本明細書において説明される機能の1つもしくは複数または全ては、1つまたは複数のエミュレーションデバイス(図示されず)によって実行されてもよい。エミュレーションデバイスは、本明細書において説明される機能の1つもしくは複数または全てをエミュレートするように構成された、1つまたは複数のデバイスであってもよい。例えば、エミュレーションデバイスは、他のデバイスをテストするために、ならびに/またはネットワークおよび/もしくはWTRU機能をシミュレートするために、使用されてもよい。
エミュレーションデバイスは、実験室環境において、および/またはオペレータネットワーク環境において、他のデバイスの1つまたは複数のテストを実施するように設計されてもよい。例えば、1つまたは複数のエミュレーションデバイスは、通信ネットワーク内の他のデバイスをテストするために、有線および/または無線通信ネットワークの一部として、完全または部分的に実施および/または展開されながら、1つもしくは複数または全ての機能を実行してもよい。1つまたは複数のエミュレーションデバイスは、有線および/または無線通信ネットワークの一部として、一時的に実施/展開されながら、1つもしくは複数または全ての機能を実行してもよい。エミュレーションデバイスは、テストの目的で、別のデバイスに直接的に結合されてもよく、および/またはオーバザエア無線通信を使用して、テストを実行してもよい。
1つまたは複数のエミュレーションデバイスは、有線および/または無線通信ネットワークの一部として実施/展開されずに、全ての機能を含む、1つまたは複数の機能を実行してもよい。例えば、エミュレーションデバイスは、1つまたは複数の構成要素のテストを実施するために、テスト実験室、ならびに/または展開されていない(例えば、テスト)有線および/もしくは無線通信ネットワークにおける、テストシナリオにおいて利用されてもよい。1つまたは複数のエミュレーションデバイスは、テスト機器であってもよい。データを送信および/または受信するために、直接RF結合、および/または(例えば、1つもしくは複数のアンテナを含んでよい)RF回路を介した無線通信が、エミュレーションデバイスによって使用されてもよい。
本明細書で説明される特徴および要素は、LTE、LTE−A、New Radio(NR)、および/または5G特有プロトコルを考慮するが、本明細書で説明される特徴および要素は、LTE、LTE−A、New Radio(NR)、および/または5G特有プロトコルに限定されず、他の無線システムに適用可能であってもよいことを理解されるべきである。
無線通信システムでは、中央ノード(例えば、gNodeB)は、1つまたは複数のWTRUにサービス提供することができる。中央ノードが1つまたは複数のWTRUにサービス提供するとき、中央ノードにトランスポートブロック(TB)を送信する機会は、中央ノードによって管理されてもよい。例えば、gNodeB(gNB)は、1つもしくは複数のWTRU(例えば、各々のWTRU)に時間−周波数リソース(例えば、別個の時間−周波数リソース)を割り当て、及び/またはWTRUに1つもしくは複数のリソース(例えば、各々のリソース)を許可する(grant)ことによって、WTRUアップリンク(UL)送信をスケジュールしてもよい。UL送信に対するそのような取り決め(arrangement)は、グラントベースUL送信(grant−based UL transmission)と称されてもよい。
gNBは、1つもしくは複数の時間−周波数リソースの存在をブロードキャストしてもよく、1つもしくは複数のWTRU(例えば、WTRUのセット)がリソース(例えば、各々のリソース)を競合することを可能にすることができ、および/またはULグラント(例えば、特定のULグラント)なしにリソースにアクセスすることを可能にすることができる。UL送信に対するそのような取り決め(例えば、New Radio(NR)における)は、グラントフリー(GF)UL送信、またはグラントなしUL送信と称されてもよい。GF UL送信の用途は、超高信頼低遅延通信(URLLC:ultra−reliable low−latency communication)、大容量マシンタイプ通信(mMTCもしくはMMTC:massive machine−type communication)、および/または高度化モバイルブロードバンド(eMBBもしくはEMBB:enhanced mobile broadband)通信にあってもよい。MMTCは、用途(例えば、スマート計量、物流、ならびに/またはフィールドおよびボディセンサ)をサポートすることが意図された多数の低コストおよび電力制約(例えば、バッテリ駆動)デバイスの間の通信を可能にすることができる。URLLCは、デバイスおよび/またはマシンが非常に低い待ち時間および/または高い可用性により信頼して通信する(例えば、超信頼して)ことを可能にすることができる。デバイスおよび/またはマシンが超信頼性、非常に低い待ち時間、および/または高い可用性により通信することを可能にすることは、URLLCが、車両通信、産業制御、工場自動化、リモート手術、スマートグリッド、および/または公共安全性の用途を提供することを可能にすることができる。EMBBは、モバイルブロードバンドアクセスの1つまたは複数の(例えば、多様な)パラメータ(例えば、データレート、遅延、およびカバレッジ)への拡張をもたらすことができる。
GF UL送信が実行されてもよい。以下のうちの1つまたは複数が適用されてもよい。gNBは、GFリソースを指定してもよい(例えば、無線リソース制御(RRC)シグナリングを介して)。GFリソースは、WTRU特有であってもよく、またはWTRU依存であってもよい。WTRUは、GFリソースを選択してもよく、および/またはGFリソース上でTBを送信してもよい。WTRUがハイブリッド自動再送要求確認応答(HARQ−ACK)(例えば、TBに対する対応するHARQ−ACK)を受信しない場合(例えば、或る時間期間の後)、WTRUは、TBを再送信してもよい(例えば、TBを再送信する計画をしてもよい)。WTRUは、別のGFリソースおよび/または許可されたリソース(例えば、gNBがリソースを許可した場合)上でTBを再送信してもよい。WTRUは、例えば、最大リトライ数に到達するまで、GFリソースを使用して再送信してもよい。
GF UL送信では、連続したリソース(例えば、K個の連続したGFリソース)にわたってTBが送信されてもよい(例えば、K回送信される)。そのような送信は、K回の繰り返しを伴うGF送信と称されてもよい。GF UL送信(例えば、K回の繰り返しを伴うTB送信)について、繰り返しは、WTRU特有RRCシグナリングによって構成することができる冗長バージョン(RV:redundancy−version)シーケンスに続いてもよい(例えば、前の既知のシーケンスになるように)。RVシーケンスは、WTRUによって使用される冗長バージョン値のシーケンスを含んでもよい。実施例では、RVシーケンスは、1つまたは複数の繰り返される冗長バージョン(例えば、[0,0,0,0]など、0の冗長バージョンの4回の繰り返し)のシーケンスを含んでもよい。実施例では、RVシーケンスは、第1の冗長バージョン値および第3の冗長バージョン値が0であり、第2の冗長バージョン値および第4の冗長バージョン値が3である(例えば、[0,3,0,3]、1つまたは複数の冗長バージョンのシーケンスを含んでもよい。
例えば、GF UL送信(例えば、各々の)において非効率であることがある。非効率性は、GF送信の性質に起因することがあり、および/または(例えば、各々の)GFリソースを使用することを試みているWTRUの数に依存することがある。
GF動作が使用される用途(例えば、URLLCまたはmMTC)に応じて、GFリソースにアクセスすることを試みているWTRUの間での衝突の可能性(例えば、低い可能性または高い可能性)が存在することがある。試みているWTRUの数が多いと、衝突の可能性は高く、および/または全体の効率性は低い。試みているWTRUの間での衝突の可能性を低くすることができる。
WTRUは、アップリンク制御情報(UCI)をTB(例えば、WTRUがGFリソースを使用して送信することを試みるTB)と多重化してもよい。例えば、GF動作を実行した後のWTRUの振る舞いは、gNBがUCIを受信したかどうか(例えば、受信に成功したかどうか)を判定するために使用されてもよい。
1つまたは複数のタイプのGF送信(例えば、NRにおける)が実行されてもよい。gNBは、以下のうちの1つまたは複数を使用してGFリソースを指定してもよい。gNBは、L1シグナリングなしの無線リソース制御(RRC)構成(例えば、再構成)(例えば、タイプ1)を介してGFリソースを指定してもよい。gNBは、L1シグナリングによるRRC構成(例えば、タイプ2)を介してGFリソースを指定してもよい。gNBは、L1シグナリングによるRRC構成(例えば、1つまたは複数のRRC構成パラメータを修正することができる)(例えば、タイプ3)を介してGFリソースを指定してもよい。
グラントフリー(GF)リソースは、1つまたは複数のWTRUによって選択されてもよい。例えば、1つまたは複数のGFリソース(例えば、そのセット)からGFリソースを選択しているWTRUは、UL GF送信を実行してもよい。以下のうちの1つまたは複数が適用されてもよい。WTRUは、GF動作を介して送信された(例えば、前に送信された)TBに対するHARQ−NACKを受信してもよい。WTRUは、送信されたTB送信に対するHARQ−ACKまたはHARQ−NACKを受信しなくてもよい。WTRUは、同一のTBを送信し(例えば、同一のTBを再送信し)、あるいは別のTBを送信する(例えば、WTRUがHARQ−NACKを受信し、またはWTRUがHARQ−NACKもしくはHARQ−ACKを受信しない場合)ことを試みてもよい。WTRUは、UL GF送信に対する次のリソースを選択してもよい。WTRUは、mMTC用途などにおいて、他のWTRUも送信することを試みているGFリソース上でUL GF送信を送信することを試みてもよく、それは、WTRUの間での衝突の可能性を増大させることがある。
WTRUは、GFリソース(例えば、次の即時に利用可能なGFリソース)上で保留TBを再送信してもよい。例えば、WTRUは、次の即時に利用可能なGFリソース上で保留TBを再送信してもよい(例えば、それを行うことが潜在的な遅延を低下させることができることを理由に)。前のGFリソースの間に衝突した2つ以上のWTRU(例えば、全てのWTRU)(例えば、HARQ−NACKまたはDRXにつながることがある)が、次の(例えば、次の即時の)GFリソース(複数可)上でそれらの保留TBを再送信する場合、別の衝突の可能性が増大することがある。
GF再送信に対する日和見的なリソース選択が実行されてもよい。GF再送信に対する日和見的なリソース選択の例が図2に示される。例えば、図2に示されるように、WTRUによるGF送信が成功しない場合、WTRUは、その保留TBを再送信するために、今度の(upcoming)GFリソースを選択してもよい。1つまたは複数の(例えば、2つの)WTRUは、図2におけるGFリソース1上でそれらの保留TBを送信することを試みてもよい。例えば、衝突に起因して、gNBは、TB(例えば、TBのいずれか)の復号に失敗することがある。gNBは、どのWTRUがGFリソース1を使用したかを識別することが可能でないことがある。gNBは、WTRUにHARQフィードバックを送信することが可能でないことがある。WTRUは、それを行うことが遅延(例えば、潜在的な遅延)を低下させることを理由に、次の利用可能な(例えば、次の即時に利用可能な)GFリソース(例えば、GFリソース2)上で保留TBを再送信すると判定してもよい。WTRUが次の利用可能な(例えば、次の即時に利用可能な)GFリソース上で保留TBを再送信すると判定する場合、衝突の可能性は低いことがある(例えば、可能性がない)。前のGFリソース1の間に衝突した2つ以上の(例えば、全ての)WTRUが同一のリソース上でそれらの保留TBを再送信する場合、衝突の可能性が増大することがある。
WTRUは、1つもしくは複数の後続のGFリソース(例えば、1つもしくは複数の直後のGFリソース)上で再送信しなくてもよく、および/または日和見的な方式において(例えば、衝突の可能性を低下させるための)保留TBを再送信してもよい。WTRUは、例えば、再送信を開始する前に乱数のGFリソース(バックオフ値)をスキップすることによって、再送信からバックオフ(back off)してもよい。例えば、乱数が予め定義された範囲(バックオフ値の範囲)から選択されることがあり、および/または2つ以上のWTRUが同一の乱数(同一のバックオフ値)を導出する(例えば、引き出す)可能性が最小になるような確率(例えば、非決定論的に)に従って乱数が導出されることがあることを理由に、乱数のGFリソースに対するバックオフは、より長い期間にわたって試みているWTRUを分散させることにつながることがある。例えば、バックオフカウンタ(例えば、バックオフ値)は、予め定義された範囲(例えば、0〜T1)から一様に導出されてもよい(例えば、引き出される)。T1が大きくなると(例えば、バックオフ範囲が大きくなると)、例えば、競合するWTRUの間での衝突(例えば、別の衝突)の可能性が低下することがある。例えば、T1=3である場合、2つのWTRU(例えば、所与のGFリソースの間に送信する前の試みにおいて衝突した2つのWTRU)は、或る範囲(例えば、0、1、2、3を含むバックオフ値の範囲)から異なるバックオフ値を導出する(例えば、引き出す)可能性が高くなることがあり(例えば、T1=1である場合よりも高い)、および/または別個のGFリソース上で送信する可能性が高くなることがある。2つのWTRUは、或る範囲(例えば、0、1、2、3を含むバックオフ値の範囲)から同一の数(例えば、バックオフ値)を導出する(例えば、引き出す)ことがある。導出された(例えば、引き出された)数が同一である場合(例えば、バックオフ値が同一である)、2つのWTRUは、同一のGFリソース上で送信(例えば、再送信)することがあり、それは、(例えば、別の)衝突につながることがある。送信(例えば、再送信)が失敗する場合(例えば、失敗もする)、送信に対する次のGFリソースが選択されることがある(例えば、再度選択される)。送信に対する次のGFリソースは、前の範囲よりも広い(例えば、大きい)ことができる(例えば、T2が2×T1+1であってもよい)範囲(例えば、0〜T2)からランダムに選択されてもよい。例えば、T1=3である場合、T2=7であり、前のGF UL送信において衝突した2つ以上のWTRUのうちのWTRU(例えば、各々のWTRU)は、或る範囲(例えば、0、1、2、3、4、5、6、7を含むバックオフ値の範囲)から一様分布によりランダムにバックオフ値を導出(例えば、引き出す)することがある。バックオフ値の範囲が増大することがある。バックオフ値の範囲が増大すると、競合しているWTRUによって異なるバックオフカウンタが導出される(例えば、引き出される)確率、および/または送信を送信するために(例えば、次に送信を送信する)競合しているWTRUによって別個のGFリソースが使用される確率が増大することがある。本明細書で説明されるように、バックオフ範囲は、コンテンションウインドウサイズ(CWS)と称されてもよい。
WTRUは、例えば、バックオフ値の範囲(例えば、T0〜Ti)からバックオフ値(例えば、tにより表される)を導出し(例えば、引き出し)、リソースをスキップし(例えば、次のt−1のGFリソースをスキップする)、および/またはリソース(例えば、t番目のGFリソース)上で送信/再送信することによって、GF送信または再送信を開始してもよい。T0は0に等しくてもよく(例えば、第1の送信はゼロのバックオフカウンタを有してもよく)、T1は3に等しくてもよく、Tiは2×Ti-1+1に等しくてもよい(例えば、T2=7、T3=15などにつながる、などである)。例えば、第1の送信のために、T0に対して非ゼロのバックオフカウンタが使用されてもよい(例えば、T0=3、T1=7、T2=15などにつながることがあるT0=3、およびTi=2×Ti-1+1)。例は、バックオフ値範囲を2倍にすることができる(例えば、衝突の後)係数を含んでもよい。例えば、Ti=3×(Ti-1+1)−1)となるように、異なる係数(例えば、バックオフ値範囲を3倍にすることができる3)により増大が実行されてもよい。バックオフ値範囲は、2つ以上の競合しているWTRUの間での別の衝突の可能性を低下させるよう増大してもよい。Ti値のシーケンスは、WTRU(例えば、いくつかもしくは全てのWTRU)に対して予め定義されてもよく、またはRRCシグナリングを介して通信されてもよい、などである。WTRU(例えば、各々のWTRU)は、第1の時間の間に送信しているかどうか、第1の時間の間に再送信しているかどうか、第2の時間の間に再送信しているかどうか、などに従ってTi値を選択してもよい(例えば、ランダムに選択してもよい)(例えば、バックオフ範囲が第1の送信、第1の再送信、第2の再送信などに対して異なることができるように)。Ti値のシーケンスは、WTRU特有RRCシグナリングを介して各々のWTRUに提供されてもよく、1つのWTRUのシーケンスは、例えば、各々のWTRUに与えられた優先度に応じて別のWTRUとは異なってもよい(例えば、低待ち時間用途で稼働しているWTRUは、MMTC用途で稼働しているWTRUよりも優先付けられてもよい)。
0、T1、T2などの値、および/または値が導出される(例えば、引き出される)確率は、予め定義されてもよく(例えば、仕様において予め定義される)、および/またはシグナリングされてもよい(例えば、RRCによってシグナリングされる)。gNBは、例えば、配置および/または用途に従って、パラメータ(例えば、T0、T1、T2などの値、および/または値が導出される確率を示すパラメータ)をカスタマイズしてもよい。
WTRU(例えば、各々のWTRU)は、WTRU(例えば、各々のWTRU)に対して一意であることができる送信に対して利用可能なグラントフリーリソースのランダムなサブセットを演繹的に(priori)選択してもよい(例えば、または許可されてもよい)。グラントフリーリソースは、WTRUによって送信に対して選択されてもよい。WTRUは、gNBから一意なグラントおよび/または明確なグラントを受信することなく、グラントフリーリソースを選択してもよい。例えば、gNBがWTRU(例えば、全てのグラントフリーWTRU)にリソースのセットを割り当てるのではなく、WTRU(例えば、各々のWTRU)は、送信に対して利用可能なグラントフリーリソースのランダムなサブセットを演繹的に選択してもよい(例えば、または許可されてもよい)。グラントフリーリソースのサブセットは、WTRU(例えば、各々のWTRU)に対して一意であってもよい。初期の送信が失敗すると、WTRUは、リソース(例えば、グラントフリーリソースのサブセットからの次の一意に利用可能なグラントフリーリソース)上で再送信を送信してもよい。WTRU特有グラントフリーリソース(例えば、WTRUに対して一意なグラントフリーリソースのサブセット)のランダム化は、送信しているWTRUの後続の送信の間で衝突が発生する確率を減少させることができる。
GF送信が成功または失敗するかどうかが判定されてもよい。WTRUがgNB(例えば、WTRUのgNB)にTBを送信するとき、WTRUは、例えば、送信の後(例えば、送信に応答して)HARQ−ACKまたはHARQ−NACKを受信してもよい。UL送信と対応するHARQフィードバック(例えば、gNBによってWTRUに送信されることが予測される)との間のタイミングは、DCIにおける1つもしくは複数のフィールドから取得することができ、またはRRCパラメータによって構成することができるパラメータによって表されてもよい。
GF UL送信では、WTRUaは、HARQ−ACKまたはHARQ−NACKを受信または検出しないことがある(WTRUが同一のGFリソース上で送信することによる2つ以上の送信の衝突に起因して)。特定の期間の後(例えば、確認応答時間)、WTRUは、前に送信されたTBがgNBによって受信されなかったと判定してもよく、および/またはGFリソース(例えば、次の利用可能なGFリソース)を使用して、TBを送信することを試みてもよい。GF UL送信について、GF UL送信と予測されたHARQフィードバックとの間のタイミングは、DCIにおける1つもしくは複数のフィールドにおいて搬送することができ、またはRRCによって指定することができるパラメータ(例えば、確認応答時間)によって表されてもよい。
1つまたは複数のWTRUは、1つまたは複数の(例えば、数個の)連続したスロットにおけるGFリソース(例えば、利用可能なGFリソース)を使用することを試みてもよい。WTRU(例えば、全てのWTRU)が前のGF送信が失敗したと判定する前の同一の時間期間を待機する場合、WTRU(例えば、全てのWTRU)は、例えば、再送信を実行するために、送信に対する同一のGFリソース(例えば、次の即時に利用可能なGFリソース)をターゲットとしてもよい。WTRU(例えば、全てのWTRU)が前のGF送信が失敗したかどうかを判定する固定期間は、送信のために使用される次のGFリソースに対する衝突の可能性を高めることがある。WTRUは、別のWTRUとは異なる対応する期間(例えば、待ち時間)を使用してもよい。そのような可変の待ち時間は、例えば、2つ以上の(例えば、数個の)GFリソースの範囲にわたって、および/または2つ以上の(例えば、数個の)スロットにわたって、WTRUによる再送信の試みを分散させることができる。GF UL送信では、GF UL送信と対応するHARQフィードバックが受信されることになる(例えば、受信されると予測される)時間(例えば、最大時間)との間のタイミングは、パラメータ(例えば、DCIにおける1つもしくは複数のフィールドにおいて搬送することができ、および/またはWTRU特有RRCによって指定することができる)によって表されてもよい。そのような時間間隔は、WTRUおよび別のWTRUとは異なってもよい。gNBは、時間間隔を定義してもよい。例えば、gNBは、1つまたは複数のWTRU(例えば、各々のWTRU)に時間期間を割り当ててもよい。これは、gNBにより指示された方法(gNB directed method)であってもよい。gNBは、時間の範囲を指定してもよく、その時間の範囲から、WTRUは、値を選択することができ(例えば、ランダムに選択することができる)、および/またはGF UL送信と対応するHARQフィードバックが受信されることになる(例えば、受信されると予測される)最大時間との間のタイミングになる値を選択することができる。時間の範囲を指定し、および/または値を選択しているgNBは、WTRUの自律的なもの(WTRU autonomous(例えば、よりWTRUの自律的なもの)であってもよい。WTRUは、gNBに値のフィードバックを提供してもよい(例えば、値のフィードバックを提供する必要があることがある)。gNBに値をフィードバックすることは、例えば、gNBがWTRUを識別することが可能であるときのグラントフリーブラインド復号(blind decoding)の量を削減することができ、ペイロードを復号しなくてもよい。
時間間隔の範囲は、パラメータ(例えば、トラフィッククラス)によって判定されてもよい。例えば、低待ち時間トラフィックは、より小さい範囲を有してもよく、および/または待ち時間許容可能トラフィック(latency tolerant traffic)は、より大きな範囲を有してもよい。WTRUは、WTRUの用途タイプに基づいて判定することができる範囲(例えば、単一の範囲)を有してもよい。(例えば、URLLC用途タイプについての範囲<eMBB用途タイプについての範囲<mMTC用途タイプについての範囲)。WTRUは、送信されることになるトラフィックのタイプに基づいて選択することができる2つ以上の範囲(例えば、複数の)を有してもよい。
例えば、衝突を減少させるために、1つまたは複数のGFリソースが検知されてもよい。GF UL送信では、1つまたは複数のWTRUは、同一のGFリソース上でそれらの保留TBを送信することを試みてもよい。例えば、1つまたは複数のWTRUは、GF UL送信を実行するように構成された1つまたは複数のWTRU(例えば、いずれかのWTRU)によってGFリソースが競合の対象となっている(up for grabs)ことがあることを理由に、同一のGFリソース上でそれらの保留TBを送信することを試みてもよい。同一のGFリソースを使用する複数のWTRUによる試みによって、例えば、WTRUの間で衝突が発生することがあり(例えば、送信に失敗する)、それは、WTRUのTBが復号されないことにつながることがある(例えば、復号に失敗する)。WTRUは、例えば、同一のGFリソースの間にそれらの保留TBを送信することを試みる前に、例えば、別のWTRUがリソースを使用しているかどうかを発見するようリソース(例えば、GFリソース)を検知することによって、そのような衝突を回避することができる。
1つまたは複数の時間領域GFリソースが検知されてもよい。GFリソースを使用することを試みるWTRU(例えば、各々のWTRU)は、リソース検知を実行する、例えば、リソースの可用性を発見するようリソースの先頭部分(beginning portion)を選択してもよい。リソースの使用が検出されない場合(例えば、他のWTRUがリソースを使用していないとWTRUが判定する場合)、WTRUは、GFリソースの残りの部分上でその保留TBを送信すると決定してもよい(例えば、処理の後)。媒体を検知することは、例えば、その部分を検知している間にエネルギー検出(ED)を実行することを含んでもよい。図3は、試みているWTRUがGFリソースの第1のシンボル(例えば、GFリソースの最初の3つのシンボル)を検知する例を示す。そのような振る舞いから利点を得るために、試みているWTRU(例えば、各々の試みているWTRU)は、別の試みているWTRUの検知間隔とは異なってもよい検知間隔を選択してもよい。例えば、WTRUは、WTRUの最初の数個のOFDMシンボルの間(例えば、図3にあるような最初の3つのシンボル)、および/またはグラントフリーリソースの帯域幅の全体を通じて、グラントフリーリソースの可用性を検知すると判定してもよい。他のWTRUがリソースを使用していないと検知される場合(例えば、エネルギー検出を使用して)、WTRUは、例えば、処理の後に、GFリソースの残りの部分上でWTRUの保留TBを送信すると判定してもよい。
WTRU(例えば、各々のWTRU)は、例えば、演繹的に既知な確率分布を使用して導出する(例えば、引き出す)ことができるシンボルの数(例えば、乱数)を選択してもよい。例えば、WTRU(例えば、全ての試みているWTRU)は、範囲(例えば、0、1、2、3、4)から一様に数(例えば、乱数)を導出(例えば、引き出す)してもよく、ならびに/または導出された数のシンボルの間、および/もしくはGFリソースの帯域幅の全体を通じて、リソース検知を実行してもよい。図4は、3つのWTRUがグラントフリーリソースを使用することを試み、WTRU(例えば、各々のWTRU)が演繹的に既知な範囲(例えば、0、1、2、3、4)から値(例えば、単一の値)を一様に導出(例えば、引き出す)する例を示す。図4を参照して、以下のうちの1つまたは複数が適用されてもよい。WTRU1に対する検知間隔は、4個のシンボルであってもよく、WTRU2に対する検知間隔は、3個のシンボルであってもよく、および/またはWTRU3に対する検知間隔は、1個のシンボルであってもよい。3つのWTRUは、演繹的に既知な範囲(例えば、0、1、2、3、4)から数nを疑似的にランダムに(例えば、分布に従って)導出(例えば、引き出す)してもよく、ならびに/または最初のn個のシンボルの間、およびグラントフリーリソースの帯域幅の全体を通じてリソースの可用性を検知してもよい。WTRU1は、GFリソースの最初の4個のOFDMシンボルの間に媒体を検知してもよい。WTRU2は、GFリソースの最初の3個のOFDMシンボルの間に媒体を検知してもよい。WTRU3は、GFリソースの1個のOFDMシンボルの間に媒体を検知してもよい。WTRU3は、媒体が利用可能であることを発見する最初のWTRUであってもよく、および/またはWTRUの保留TBを、例えば、GFリソースの残りの部分上で送信することを試みてもよい(例えば、処理の後)。WTRU1およびWTRU2は(例えば、予測される期間の間に媒体を検知した後)、GFリソースが使用中であると判定してもよく、および/またはGFリソースを使用することを控えてもよい。2つ以上のWTRUは、同一の数を導出(例えば、引き出す)してもよく、および/または同一の期間の間にリソースを検知してもよく、それは、WTRUの間の衝突につながることがある。そのような結果についての可能性は、リソース検知範囲が増大するにつれて減少する。
2つ以上のWTRUは、GFリソース(例えば、同一のGFリソース)を使用することを試みてもよい。WTRU3は、GFリソースを使用することを試みなくてもよい(例えば、リソース検知を実行しなくてもよい)。WTRU2およびWTRU1は、媒体を検知してもよい。例えば、WTRU2は、媒体が利用可能であると判定する最初のWTRUであってもよく、および/またはリソースの残りの部分においてWTRUの保留TBを送信してもよい(送信することを試みる)(例えば、処理の後)。WTRU1は(例えば、期間(例えば、予測された期間)の間に媒体を検知した後)、GFリソースが使用中であると判定してもよく、および/またはGFリソースを使用することを控えてもよい。WTRU3もWTRU2もGFリソースを使用することを試みていない場合(例えば、リソース検知を実行しない)、WTRU1は(例えば、その検知期間が満了した後)、GFリソースが使用中でないと判定してもよく、および/またはその保留TBを送信してもよい。
WTRU(例えば、各々のWTRU)によって実行された検知(例えば、エネルギー検出)および/または実行された検知の精度に応じて、WTRUは、GFリソースが使用中であると早く判定してもよく(例えば、その検知間隔の終了よりも早く)、および/またはリソースを検知することを停止してもよい。例えば、WTRUによって実行された検知および/または検知の精度に応じて、WTRUは、媒体が使用中であることを検知することを失敗することがあり、および/またはリソースを使用することを試みることがあり、それは、衝突を生じさせることがある。
1つまたは複数の周波数領域GFリソースが検知されてもよい。WTRUは、同一の数のOFDMシンボル(例えば、1個のOFDMシンボルおよび/もしくは演繹的に既知な数個のOFDMシンボル)の間、ならびに/または可変数のリソースブロック(RB)の間にリソース検知を実行してもよい(例えば、一貫して実行してもよい)。図5は、3つのWTRUが所与のグラントフリーリソースを使用することを試み、および/またはWTRU(例えば、各々のWTRU)が演繹的に既知な範囲から値(例えば、単一の値)を導出(例えば、引き出す)する例を示す。図5に例示されるように、WTRU1、WTRU2、およびWTRU3は、同一の数のOFDMシンボルであるが、異なる数のRBに対してリソース検知を実行してもよい。図5を参照して、以下のうちの1つまたは複数が適用されてもよい。WTRU1に対する検知間隔は、9個のRBであってもよい(例えば、GF送信の前の)。WTRU2に対する検知間隔は、7個のRBであってもよい(例えば、GF送信の前の)。WTRU3に対する検知間隔は、4個のRBであってもよい(例えば、GF送信の前の)。3つのWTRUは、演繹的に既知な範囲から数nを疑似的にランダムに導出(例えば、引き出す)してもよく(例えば、分布ごとに)、および/または第1のOFDMシンボルの最上のn個のRB(もしくは、例えば、演繹的に既知な最初の数個のOFDMシンボル)の間にリソースの可用性を検知してもよい。WTRU1は、GFリソースの最上の9個のRBの間に媒体を検知してもよい。WTRU2は、GFリソースの最上の7個のRBの間に媒体を検知してもよい。WTRU3は、GFリソースの最上の4個のRBの間に媒体を検知してもよい。WTRU3は、媒体が利用可能であることを発見する最初のWTRUであってもよく、および/または、例えば、処理の後、リソースの残りの部分上でWTRUの保留TBを送信することを試みてもよい。WTRU1およびWTRU2は(例えば、それぞれの予測された期間の間に媒体を検知した後)、GFリソースが使用中であると判定してもよく、および/またはGFリソースを使用することを控えてもよい。WTRU(例えば、各々のWTRU)がWTRUの検知期間を導出(例えば、引き出す)する範囲は、演繹的に既知であってもよい(例えば、RRCまたはDCIによってパラメータを介して通信される)。範囲は、GFリソースの帯域幅の関数としてWTRU(例えば、各々のWTRU)によって取得されてもよい(例えば、暗黙的に取得されてもよい)。例えば、範囲は、GFリソースと関連付けられたRBの数によって表されるGFリソースの帯域幅であってもよい。図5は、範囲が(0、1、2、3、4、5、6、7、8、9、11)を含む例を示す。範囲は、11個のRBであるGFリソースの帯域幅から暗黙的に取得されてもよい。
2つ以上のWTRUは、GFリソース(例えば、同一のGFリソース)を使用することを試みてもよい。WTRU3は、GFリソースを使用することを試みなくてもよい(例えば、リソース検知を実行しなくてもよい)。WTRU2およびWTRU1は、媒体を検知してもよい。例えば、WTRU2は、媒体が利用可能であると判定する最初のWTRUであってもよく、および/またはリソースの残りの部分においてWTRUの保留TBを送信してもよい(送信することを試みてもよい)(例えば、処理の後)。WTRU1は(例えば、或る期間(例えば、予測された期間)の間に媒体を検知した後)、GFリソースが使用中であると判定してもよく、および/またはGFリソースを使用することを控えてもよい。WTRU3もWTRU2もGFリソースを使用することを試みない場合(例えば、リソース検知を実行しない)、WTRU1は(例えば、その検知期間の満了後)、GFリソースが使用中でないと判定してもよく、および/またはその保留TBを送信してもよい。
二次元時間−周波数GFリソースが検知されてもよい。WTRUは、GFリソースの可変数の(例えば、演繹的に既知な時間間隔から擬似的にランダムに導出された)OFDMシンボル(例えば、第1のOFDMシンボル)および/または可変数の(演繹的に既知なRB間隔から擬似的にランダムに導出された)最上のリソースブロックに対してリソース検知を実行してもよい。例えば、時間間隔は、(0、1、2)であってもよく、および/またはRB間隔は、(0、1、2、3、4)であってもよい。WTRUは、或る時間間隔から擬似的にランダムな数を導出(例えば、引き出す)してもよく、時間間隔は、検知間隔の時間期間であってもよい。WTRUは、RB間隔から擬似的にランダムに数を導出(例えば、引き出す)してもよく、RB間隔は、検知間隔の周波数帯域幅であってもよい。検知間隔の間にリソースが使用中であるとWTRUが判定する場合(例えば、エネルギー検出を使用して)、WTRUは、例えば、処理の後にGFリソースの残りの部分においてWTRUの保留TBを送信してもよい。リソース検知領域なセットは、1つもしくは複数のWTRU(複数可)(例えば、全てのWTRU)によって演繹的に既知であってもよく、および/またはWTRUは、リソース検知を実行する領域を擬似的にランダムに選択してもよい。リソース検知領域は、(t,f)など、矩形な時間および周波数間隔を含んでもよく、tは、OFDMシンボルの単位にあってもよく、および/またはfは、RBの単位にあってもよい。
図3におけるリソース検知領域は、以下のうちの1つまたは複数を含んでもよい。tは、演繹的な分布からWTRUによって擬似的にランダムに導出されてもよい(例えば、引き出される)。tは、2つ以上のWTRUに対して異なってもよい。例えば、GFリソースを使用することを試みているWTRUは、別のWTRUとは異なってもよいtを有してもよい。fは、GFリソースを使用することを試みている1つまたは複数の(例えば、全ての)WTRUに対して固定されてもよい(例えば、fは、GFリソースの帯域幅、例えば、GFリソースの全てのRBに等しくてもよい)。
図4におけるリソース検知領域は、以下のうちの1つまたは複数を含んでもよい。fは、演繹的な分布からWTRUによって擬似的にランダムに導出されてもよく(例えば、引き出される)、および/またはfは、1つもしくは複数のRBであってもよい。fは、2つ以上のWTRUに対して異なってもよい。例えば、GFリソースを使用することを試みているWTRUは、別のWTRUにおけるfとは異なってもよいfを有してもよい。tは、GFリソースを使用することを試みているWTRU(例えば、全てのWTRU)に対して固定されてもよい(例えば、tは、1つまたは複数のOFDMシンボルに等しくてもよい)。
検知領域は、例えば、2D時間−周波数領域であってもよく、WTRUに対する検知領域は、時間および/または周波数領域において別のWTRUとは異なってもよい。検知領域のセットは、1つまたは複数のWTRU(複数可)によって演繹的に既知であってもよい(例えば、1つまたは複数の(例えば、全ての)検知領域に対する(例えば、(ti,fi)全てのWTRUは、gNBによって演繹的に識別され、および/または1つもしくは複数の(例えば、全ての)WTRU)に既知である)。WTRUは、セットから検知領域を選択してもよい。検知領域のセットは、設計されてもよく、および/または入れ子にされてもよい(nested)。最小検知領域は、1つまたは複数の検知領域のサブセット(例えば、全ての他の検知領域)であってもよい。2番目に最小の最小検知領域は、1つまたは複数の他の検知領域のサブセット(例えば、最小検知領域に加えた全ての他の検知領域)であってもよい、などである。検知領域の構造(例えば、入れ子構造)は、リソースが使用中であるかどうかの判定を可能にすることができる(例えば、明白な推定)。ビットマップのフォーマットにある検知領域を搬送する固定されたペイロードサイズは、GFリソース内の検知領域を示すために使用されてもよい。二次元ビットマップは、GFリソース内の1つまたは複数の周波数−時間領域/区画を示すことができる。
リソース検知は、例えば、演繹的に既知な分布から擬似的にランダムに導出(例えば、引き出す)することができる、検知間隔に従って、時間領域および/またはRB領域において実行されてもよい。1つまたは複数のWTRUは、最小検知間隔を使用するよう優先付けられてもい(例えば、リソース検知を実行しない)。例えば、低待ち時間用途に対して構成されたWTRUは、検知を実行しない(例えば、WTRUの検知間隔がゼロである)ようにRRCによって構成されてもよく、および/またはWTRUは、検知することなくGFリソースを使用することを試みてもよい。WTRU(例えば、mMTCなど、待ち時間許容可能用途を実行するWTRU)は、リソース検知を実行するように構成されてもよい。特定の用途(例えば、低待ち時間用途)を伴うWTRUは、例えば、他のWTRUと比較して、高い優先度を取得してもよい。WTRUが数を導出する(例えば、引き出す)(例えば、擬似的にランダムに数を導出する)演繹的な範囲は、例えば、高優先度のWTRUを優先付けるよう、非ゼロの数から開始してもよい。優先付けは、1つまたは複数の基準に基づいて実行されてもよい。実施例では、優先付けは、WTRUによって実行される用途(例えば、低待ち時間用途mMTC用途)に基づいてもよい。
リソース検知について、WTRUがTBの送信のために使用するGFリソースからのリソース要素(RE)の数は、可変であってもよく、および/または事前に知られなくてもよい(例えば、検知間隔に起因して)。検知間隔は、擬似的にランダムに導出された数であってもよい。以下のうちの1つまたは複数が適用されてもよい(例えば、知識の欠如に対処することができる)。
WTRUは、例えば、リソース検知がされなかったようにTBを作成してもよい。GFリソースが使用中でないとWTRUが判定する場合(例えば、リソース検知を実行した後)、WTRUは、作成されたTBをレートマッチングしてもよく、および/またはレートマッチングされたTBを送信してもよい。
検知間隔の結果が数個のシンボルである場合(例えば、数個の媒体検知間隔につながる検知間隔)、WTRUは、様々なレートマッチング推定(rate−matching assumption)により保留TBを作成してもよい。TBの様々なレートマッチング推定は、結果に基づいてもよい。例えば、送信範囲は、(0、2、4)であってもよく、WTRUは、0、2、または4を擬似的にランダムに導出(例えば、引き出す)してもよい。GFリソースを使用する前に、WTRUは、例えば、起こり得る検知間隔結果に対してWTRUの保留TBをレートマッチングしてもよい。以下のうちの1つまたは複数が適用されてもよい。WTRUは、検知がされなかったようにレートマッチングされたTBを作成してもよい(例えば、検知間隔に対して導出された0の結果に対応する)。WTRUは、検知間隔が2であるように残りのREによりレートマッチングされたTBを作成してもよい。WTRUは、検知間隔が4であるように残りのREによりレートマッチングされたTBを作成してもよい。WTRUがGFリソースに達し、および/または範囲(0、2、4)から擬似的にランダムに導出(例えば、引き出す)するとき、WTRUは、準備された結果(outcome ready)に対してレートマッチングされたTBを有してもよい。
例えば、gNBが、GFリソースのどの部分が使用されていない(例えば、どの部分がリソース検知のためにWTRUによって使用されていない)ことを知らないことがあることを理由に、gNBは、レートマッチング値を判定してもよい(例えば、一意に判定する)。gNBは、リソース検知領域のサイズ(例えば、GFリソースの全帯域幅に対するOFDMシンボルの数、OFDMシンボルの数(例えば、固定数)に対するRBの数、ならびに/またはOFDMシンボルの数およびRBの数)を取得してもよい(例えば、暗示的に取得し、または判定する)。gNBは、WTRUのTBの送信のために使用されたリソースの部分を取得してもよく(例えば、後続で取得し、もしくは判定する)、および/または関連するレートマッチング比率を取得してもよい(例えば、後続で取得し、もしくは判定する)。
WTRUは、RRCシグナリングによってオフセット値のうちの1つまたは複数により構成されてもよく、(例えば、各々の)オフセット値は、対応する検知範囲に対してREの量を計算するためにWTRUによって使用されてもよい。WTRUは、例えば、オフセット値を判定するために、UL波形(例えば、OFDM対DFT−s−OFDM)およびに/または異なるUCI多重化機構を考慮してもよい。
WTRUは、例えば、スロットの最初の数個のシンボル、例えば、最初のOFDMシンボルまたは最初の2つのOFDMシンボルに対してリソース検知を実行するように構成されてもよい。WTRUがスロットの最初の数個のシンボルに対してリソース検知を実行するように構成される場合、WTRUは、UL GF送信に対して利用可能なスロット内の最初のOFDMシンボル(例えば、WTRUによるGFリソース−PUSCHの残りの部分)を判定してもよい(例えば、暗黙的に判定する)。例えば、WTRUが最初のM個のOFDMシンボルの間にリソース検知を実行している場合、WTRUは、GF PUSCHが次のK個のシンボル(M+1,M+2,…,M+K)のOFDMシンボルにおいて送信されてもよいと判定してもよい。kは、例えば、WTRUの能力、例えば、高い能力K=1(例えば、WTRUが、リソース検知を実行した後にかなり次のOFDMシンボルにおいてUL GF PUSCHを送信することができることを示すことができる)を有するWTRUに対するWTRUの能力に依存することがある、OFDMシンボル(複数可)の数に関するパラメータであってもよい。WTRUは、スロットの残りのシンボルに対してスロットフォーマットインジケータ(SFI)において示されたスロットフォーマット構成に従ってもよい。
UCI多重化は、GF送信の間に実行されてもよい。WTRUは、グラントベースリソースを利用してもよく、ならびに/または、例えば、チャネル状態情報(CSI)、チャネル品質インジケータ(CQI)、ランクインジケータ(RI)、および/もしくはTBに従ったHARQ ACK/NACK情報を含む、UCIを多重化してもよい。WTRUの振る舞いは、例えば、WTRUがPUSCH上でUCI情報を多重化することを試みているとき、GF送信の間に変更してもよい。
適応的符号化レート(adaptive coding rate)がUCI多重化のために実行されてもよい。UCI多重化の間にWTRUによって実行される処理(例えば、WTRUによって実行されることが必要とされる)は、UL送信がグラントベースまたはグラントフリーであるかどうかの不可知論的(agnostic)であってもよい。UCI多重化のために使用される処理は、GF UL送信の間に使用されてもよい。GF送信について、GFリソースは、干渉および/または衝突の影響を受けることがある。GF UL送信の間のより高い干渉に対処するために、例えば、多重化されたUCIをより低いレート符号化により符号化することができるように、冗長バージョン(RV)が調節されてもよく、および/またはTBがレートマッチングされてもよい。K回の繰り返しを伴うGF UL送信(例えば、UCIがTBと多重化される)では、UCI情報は、より低いレート符号(例えば、一連のK回の送信における前の送信と比較して)を使用して多重化されてもよい。より低いレート符号は、より高い量の冗長性と関連付けられてもよい。K回の繰り返しを伴うGF送信では、UCIは、例えば、1回目繰り返しと比較して、2回目の繰り返しにおいてより低いレート符号により符号化されてもよい。UCIは、例えば、2回目の繰り返しと比較して、3回目の繰り返しにおいてより低いレート符号により符号化されてもよい、などである。gNBがWTRUによって使用される符号化レートを認識することを保証するために、例えば、予め定義されたレートマッチング/符号化レートパラメータのセットが指定されてもよく、WTRUは、K回の繰り返しを伴うTB(再)送信の間に予め定義されたレートマッチング/符号化レートパラメータのセットを順番に使用してもよい。例えば、WTRUは、{1/2、1/3、1/4}であるとしてWTRU特有RRCシグナリングによって構成されてもよい、符号化レートシーケンスに従ってもよい。WTRUは、例えば、GF UL(再)送信の間に多重化されることになる(例えば、各々の)それぞれのUCIに対してREの量を計算するよう、(再)送信(例えば、各々の、(再)送信)に対して異なるベータオフセット値(beta−offset value)を使用してもよい。例えば、WTRUは、
Figure 2021508422
であるWTRU特有RRCシグナリングによって構成されてもよい、ベータオフセットシーケンスに従ってもよい。第1の送信に対するベータオフセットは、第2の送信に対するベータオフセットよりも小さくてもよい、などである。
WTRUは、WTRUのGF UL送信のHARQフィードバックを待機してもよい(例えば、待機時間の間)。WTRUがそのGF UL送信のHARQフィードバックを待機している間、PUCCHリソースがWTRUに割り当てられる場合、WTRUは、UCIを再送信してもよい(例えば、前のGF UL送信が成功したかどうかに関わらず)。TBのGF送信の間に多重化されたUCIとの衝突が発生する場合、WTRUは、HARQ−NACKを受信してもよく、またはHARQフィードバックを受信しなくてもよい。多重化されたUCIは、gNBによって受信されなくてもよく、および/または再送信されてもよい(例えば、もしあれば、グラントベースPUSCHリソースによって多重化され、および/または別のGF送信において再送信される場合の、到来するPUCCH機会において)。
UCI多重化に基づく優先付けが実行されてもよい。WTRUによるUCIの送信(例えば、HARQ ACK)がGF送信(例えば、所与のスロットに対する)よりも高い優先度を有する場合、WTRUは、PUSCH上のGF送信(例えば、CSIもしくはCQI)をドロップしてもよく、および/またはPUCCHにおいてHARQ−ACK(例えば、HARQ−ACKのみ)を送信してもよい。WTRUは、後続のスロットにおいてPUSCH上のグラントフリーリソース上でGF送信を開始してもよい(例えば、即時に開始する)。WTRUによるUCIの送信(例えば、定期的/半永続的CSI報告)がGFデータ送信(例えば、所与のスロットに対する)よりも低い優先度を有する場合、WTRUは、定期的/半永続的CSI報告をドロップしてもよく、PUSCH上でのデータのGF送信を続行してもよく、および/または定期的/半永続的CSI報告をデータと多重化してもよく、PUSCH上のGFリソース上で送信してもよい。WTRUがUCIをドロップした場合、WTRUは、次の割り当てられたPUCCHリソースにおいて定期的/半永続的CSI報告の送信を継続してもよい。gNBは、例えば、PUCCHおよび/またはGF PUSCHリソースを検出することによって(例えば、同時に検出する)、WTRUの振る舞いを判定してもよい(例えば、盲目的に判定する)。gNBがPUSCHを検出する場合(例えば、PUCCH上でのWTRUによるUCI送信を予測している間)、gNBは、WTRUがUCIをデータと多重化しており、ならびに/またはPUSCH上のGFリソース上でUCIおよびデータを送信していると判定してもよい。
UCI送信の優先度は、RRCによって構成されてもよい。例えば、WTRUは、上位層によって提供される予め定義されたパラメータ(例えば、simultaneousCSIAndData)がTRUEに設定される場合、WTRUが、例えば、GFリソース上でHARQ−ACKとデータを多重化することになり(例えば、多重化する必要がある)、および/またはHARQ−ACKをドロップしないことになると判定してもよい。WTRUは、例えば、上位層によって提供される予め定義されたパラメータ(例えば、simultaneousCSIAndData)がTRUEに設定されない場合、WTRUが、定期的/半永続的CSI報告(複数可)をドロップすることになり(例えば、ドロップする必要がある)、および/またはGFリソース上でCSI報告(複数可)をデータと多重化しないことになると判定してもよい。
UCI多重化は、HARQフィードバックを条件としてもよい。初期の送信に対し、WTRUがUCIをデータと多重化しており、GF ULリソース上で送信しており、および/またはgNBからNACKを受信する場合、WTRUは、良好なカバレッジを有しないことがあり、および/またはUCIもTBもgNBにおいて検出に成功しないことがある。WTRUは、例えば、UCIコンテンツの優先度に従って、GF再送信/繰り返しに対し、UCIおよび/またはデータをドロップすると判定してもよい(例えば、自律的に判定する)。WTRUがUCIをドロップする場合、例えば、GF TB再送信に対する符号レートが低下されてもよく、それは、gNBにおけるTBの検出が成功する機会をより高くすることができる。WTRUがデータをドロップする場合、例えば、WTRUによるUCI送信は、PUCCH上であってもよく、それは、gNBにおける検出の可能性をより高くすることができる。
初期の送信に対し、WTRUがUCIをデータと多重化しており、GF ULリソース上で送信しており、および/またはgNBからACKを受信する場合、WTRUは、良好なカバレッジを有することがあり、UCIおよび/またはTBがgNBにおいて検出されていることがある(例えば、検出に成功する)。WTRUは、例えば、GF再送信/繰り返しに対してUCIをデータと多重化すると判定してもよい(例えば、自律的に判定する)(例えば、UCIコンテンツの優先度に関わらず)。WTRUは、UCIをドロップしなくてもよく、および/または後続のGF再送信/繰り返しにおいてUCIをデータと多重化してもよい(例えば、常に多重化する)。
特徴および要素が特定の組み合わせで上記説明されたが、当業者は、各々の特徴または要素が単独で、または他の特徴および要素とのいずれかの組み合わせで使用されてもよいことを認識するであろう。加えて、本明細書で説明される方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてもよい。コンピュータ可読媒体の例は、電子信号(有線または無線接続を通じて送信される)およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、磁気光学媒体、ならびにCD−ROMディスクおよびデジタル多用途ディスク(DVD)などの光学媒体を含むが、それらに限定されない。ソフトウェアと関連してプロセッサは、WTRU、UE、端末、基地局、RNC、またはいずれかのホストコンピュータにおける使用のために無線周波数送受信機を実装するために使用されてもよい。

Claims (16)

  1. 第1の優先度と関連付けられた第1の部分および第2の優先度と関連付けられた第2の部分を含む第1の送信を送り、前記第1の送信は、第1のグラントフリー送信であり、前記第1の優先度は、前記第2の優先度よりも高い優先度であり、前記第1の送信は、バックオフ値の第1の範囲から選択された第1のバックオフ値を使用し、
    前記第1の送信が成功するかどうかを判定し、
    前記第1の送信が成功したと判定することを条件に、前記第1の送信の再送信から前記第2の部分をドロップすると判定し、
    前記再送信を送り、前記再送信は、前記第1の部分を含み、前記第2の部分を含まず、前記再送信は、第2のグラントフリー送信であり、前記再送信は、バックオフ値の第2の範囲から選択された第2のバックオフ値を使用し、バックオフ値の前記第2の範囲は、バックオフ値の前記第1の範囲よりも大きい、
    ように少なくとも構成されたプロセッサを備えたことを特徴とする無線送信/受信ユニット(WTRU)。
  2. 前記第2のバックオフ値は、前記再送信を送る前にスキップするグラントフリーリソースの数を示し、前記プロセッサは、
    前記第1の送信が成功しないと判定した後、前記第2のバックオフ値によって示された数のグラントフリーリソースをスキップする
    ように更に構成されていることを特徴とする請求項1に記載のWTRU。
  3. 前記第1の送信は、第1の冗長バージョンを使用して第1のトランスポートブロック上で多重化され、前記再送信は、第2の冗長バージョンを使用して第2のトランスポートブロック上で多重化され、前記第2の冗長バージョンは、前記第1の冗長バージョンよりも高い冗長性と関連付けられていることを特徴とする請求項1に記載のWTRU。
  4. 前記第1の送信および前記再送信は、アップリンク制御情報(UCI)と関連付けられ、前記第1の送信および前記再送信は、物理アップリンク共有チャネル(PUSCH)上で送られることを特徴とする請求項1に記載のWTRU。
  5. 前記プロセッサは、バックオフ値の前記第1の範囲のインジケーションを受信するように更に構成されていることを特徴とする請求項1に記載のWTRU。
  6. 前記プロセッサは、バックオフ値の前記第1の範囲のサイズに基づいて、バックオフ値の前記第2の範囲を判定するように更に構成されていることを特徴とする請求項1に記載のWTRU。
  7. 前記プロセッサは、
    多重化優先度情報を受信し、
    前記多重化優先度情報に基づいて、前記第1の部分と関連付けられた前記第1の優先度を判定し、
    前記多重化優先度情報に基づいて、前記第2の部分と関連付けられた前記第2の優先度を判定する、
    ように更に構成されていることを特徴とする請求項1に記載のWTRU。
  8. 前記第1の部分は、確認応答情報と関連付けられ、前記第2の部分は、チャネル品質情報(CQI)と関連付けられている、ことを特徴とする請求項1に記載のWTRU。
  9. 第1の優先度と関連付けられた第1の部分および第2の優先度と関連付けられた第2の部分を含む第1の送信を送るステップであって、前記第1の送信は、第1のグラントフリー送信であり、前記第1の優先度は、前記第2の優先度よりも高い優先度であり、前記第1の送信は、バックオフ値の第1の範囲から選択された第1のバックオフ値を使用する、ステップと、
    前記第1の送信が成功するかどうかを判定するステップと、
    前記第1の送信が成功したと判定することを条件に、前記第1の送信の再送信から前記第2の部分をドロップすると判定するステップと、
    前記再送信を送るステップであって、前記再送信は、前記第1の部分を含み、前記第2の部分を含まず、前記再送信は、第2のグラントフリー送信であり、前記再送信は、バックオフ値の第2の範囲から選択された第2のバックオフ値を使用し、バックオフ値の前記第2の範囲は、バックオフ値の前記第1の範囲よりも大きい、ステップと、
    を備えたことを特徴とする方法。
  10. 前記第2のバックオフ値は、前記再送信を送る前にスキップするグラントフリーリソースの数を示し、前記方法は、
    前記第1の送信が成功しないと判定した後、前記第2のバックオフ値によって示された数のグラントフリーリソースをスキップするステップを更に備えた
    ことを特徴とする請求項9に記載の方法。
  11. 前記第1の送信は、第1の冗長バージョンを使用して第1のトランスポートブロック上で多重化され、前記再送信は、第2の冗長バージョンを使用して第2のトランスポートブロック上で多重化され、前記第2の冗長バージョンは、前記第1の冗長バージョンよりも高い冗長性と関連付けられていることを特徴とする請求項9に記載の方法。
  12. 前記第1の送信および前記再送信は、アップリンク制御情報(UCI)と関連付けられ、前記第1の送信および前記再送信は、物理アップリンク共有チャネル(PUSCH)上で送られることを特徴とする請求項9に記載の方法。
  13. バックオフ値の前記第1の範囲のインジケーションを受信するステップを更に備えたことを特徴とする請求項9に記載の方法。
  14. バックオフ値の前記第1の範囲のサイズに基づいて、バックオフ値の前記第2の範囲を判定するステップを更に備えたことを特徴とする請求項9に記載の方法。
  15. 多重化優先度情報を受信するステップと、
    前記多重化優先度情報に基づいて、前記第1の部分と関連付けられた前記第1の優先度を判定するステップと、
    前記多重化優先度情報に基づいて、前記第2の部分と関連付けられた前記第2の優先度を判定するステップと、
    を更に備えたことを特徴とする請求項9に記載の方法。
  16. 前記第1の部分は、確認応答情報と関連付けられ、前記第2の部分は、チャネル品質情報(CQI)と関連付けられている、ことを特徴とする請求項9に記載の方法。
JP2020526408A 2017-11-15 2018-11-15 グラントフリーアップリンク送信 Active JP7277456B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023076723A JP2023106450A (ja) 2017-11-15 2023-05-08 グラントフリーアップリンク送信

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201762586473P 2017-11-15 2017-11-15
US62/586,473 2017-11-15
PCT/US2018/061228 WO2019099631A1 (en) 2017-11-15 2018-11-15 Grant-free uplink transmissions

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023076723A Division JP2023106450A (ja) 2017-11-15 2023-05-08 グラントフリーアップリンク送信

Publications (3)

Publication Number Publication Date
JP2021508422A true JP2021508422A (ja) 2021-03-04
JP2021508422A5 JP2021508422A5 (ja) 2022-01-04
JP7277456B2 JP7277456B2 (ja) 2023-05-19

Family

ID=64664432

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2020526408A Active JP7277456B2 (ja) 2017-11-15 2018-11-15 グラントフリーアップリンク送信
JP2023076723A Pending JP2023106450A (ja) 2017-11-15 2023-05-08 グラントフリーアップリンク送信

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023076723A Pending JP2023106450A (ja) 2017-11-15 2023-05-08 グラントフリーアップリンク送信

Country Status (10)

Country Link
US (2) US11533137B2 (ja)
EP (2) EP3711225B1 (ja)
JP (2) JP7277456B2 (ja)
KR (1) KR20200099521A (ja)
CN (3) CN111615803B (ja)
CA (1) CA3082780A1 (ja)
ES (1) ES2962358T3 (ja)
SG (1) SG11202004511UA (ja)
WO (1) WO2019099631A1 (ja)
ZA (2) ZA202002856B (ja)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108633083B (zh) * 2017-03-17 2021-01-26 上海朗帛通信技术有限公司 一种被用于无线通信的用户、基站中的方法和装置
US11533137B2 (en) * 2017-11-15 2022-12-20 Idac Holdings, Inc. Grant-free uplink transmissions
MX2020008999A (es) * 2018-03-02 2020-11-25 Interdigital Patent Holdings Inc Protocolos para difusión de enlace descendente asistido por enlace lateral.
US11202225B2 (en) * 2018-04-23 2021-12-14 Endeavour Technology Limited IoT QoS monitoring system and method
US11309999B2 (en) * 2018-07-31 2022-04-19 Qualcomm Incorporated Repetition techniques for autonomous uplink transmissions
EP4316121A1 (en) * 2021-03-30 2024-02-07 Nokia Technologies Oy Harq process selection

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AR073833A1 (es) * 2008-10-20 2010-12-01 Interdigital Patent Holdings Metodos para el control ascendente de transmision de informacion para agregar ona portadora
KR20100083440A (ko) * 2009-01-13 2010-07-22 삼성전자주식회사 다중 반송파 전송 방식을 사용하는 무선 통신 시스템에서의상향링크 제어 정보 송신 장치 및 방법
WO2010105667A1 (en) * 2009-03-17 2010-09-23 Nokia Siemens Networks Oy Configuring the transmission of periodic feedback information on a physical uplink shared channel (pusch)
RU2557164C2 (ru) * 2009-10-01 2015-07-20 Интердиджитал Пэйтент Холдингз, Инк. Передача управляющих данных восходящей линии связи
US9337984B2 (en) * 2011-08-19 2016-05-10 Lg Electronics Inc. Method for transmitting uplink control information, user equipment, method for receiving uplink control information, and base station
CN114095121A (zh) * 2013-01-11 2022-02-25 交互数字专利控股公司 用于适应性调制的系统和方法
US20150208404A1 (en) * 2014-01-23 2015-07-23 Humax Holdings Co., Ltd. System and method for priority data transmission on lte dual connectivity
US20150327243A1 (en) * 2014-05-08 2015-11-12 Sharp Laboratories Of America, Inc. Systems and methods for dual-connectivity operation
WO2017192009A1 (ko) * 2016-05-03 2017-11-09 엘지전자 주식회사 무선 통신 시스템에서 ack/nack 메시지 전송 방법 및 상기 방법을 이용하는 단말
US10080226B2 (en) * 2016-07-12 2018-09-18 Cisco Technology, Inc. Timeslot shifting for lower-priority packet in a time slotted network
US10869333B2 (en) * 2016-12-16 2020-12-15 Huawei Technologies Co., Ltd. Systems and methods for mixed grant-free and grant-based uplink transmissions
EP3582563B1 (en) * 2017-02-05 2022-08-10 LG Electronics Inc. Method and device for transmitting/receiving signal associated with grant-free resource in wireless communication system
EP3637933A4 (en) * 2017-06-08 2020-12-16 NTT DoCoMo, Inc. USER TERMINAL AND WIRELESS COMMUNICATIONS PROCESS
US10721025B2 (en) * 2017-06-15 2020-07-21 Ofinno, Llc Grant-free failure reporting
US10986631B2 (en) * 2017-06-27 2021-04-20 Apple Inc. Uplink control information (UCI) transmission and hybrid automatic repeat request (HARQ) process identification for grant-free physical uplink shared channel (PUSCH)
US10813118B2 (en) * 2017-07-10 2020-10-20 Lg Electronics Inc. Method for transmitting and receiving uplink control information and devices supporting the same
US11533137B2 (en) * 2017-11-15 2022-12-20 Idac Holdings, Inc. Grant-free uplink transmissions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HUAWEI, HISILICON: "Discussion on UCI feedback for URLLC[online]", 3GPP TSG RAN WG1 #90B R1-1717094, JPN6023012119, 2 October 2017 (2017-10-02), ISSN: 0005027819 *

Also Published As

Publication number Publication date
CN111615803B (zh) 2023-07-04
CA3082780A1 (en) 2019-05-23
ZA202002856B (en) 2023-12-20
WO2019099631A8 (en) 2020-06-11
US20230061275A1 (en) 2023-03-02
EP4236579A3 (en) 2023-09-27
ES2962358T3 (es) 2024-03-18
JP7277456B2 (ja) 2023-05-19
CN116744469A (zh) 2023-09-12
JP2023106450A (ja) 2023-08-01
EP3711225A1 (en) 2020-09-23
WO2019099631A1 (en) 2019-05-23
EP4236579A2 (en) 2023-08-30
US20200389264A1 (en) 2020-12-10
KR20200099521A (ko) 2020-08-24
ZA202105707B (en) 2023-12-20
EP3711225B1 (en) 2023-09-20
US11533137B2 (en) 2022-12-20
CN116743325A (zh) 2023-09-12
SG11202004511UA (en) 2020-06-29
CN111615803A (zh) 2020-09-01

Similar Documents

Publication Publication Date Title
TWI757622B (zh) 無線傳輸/接收單元及由其執行的方法
US20230232456A1 (en) Channel access methods and listen-before-talk solutions for new radio operation in unlicensed bands
JP7122327B2 (ja) 送信適合およびグラントフリーアクセス
US11916680B2 (en) Sidelink resource sensing using feedback channels
US11902032B2 (en) Methods and apparatus for HARQ enhancement
US20210377912A1 (en) Methods, devices, and systems for supporting harq on v2x
JP2021519000A (ja) アンライセンススペクトルと関連付けられたデータ送信およびharq−ack
JP2022520590A (ja) 2ステップrachにおけるmsg-bのための方法
JP7277456B2 (ja) グラントフリーアップリンク送信
CN113767586A (zh) 用于在所配置的许可上的增强型上行链路数据传输的方法、装置和系统
JP2020507239A (ja) 無線システムにおける受信機フィードバック
US11838938B2 (en) Collision mitigation procedures for grant-less uplink multiple access
US20220225412A1 (en) Shared channel occupancy time operation
WO2023212022A1 (en) Methods for efficient sidelink scheduling in unlicensed spectrum

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200714

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20200603

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20200526

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211115

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211115

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220920

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20221220

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230303

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230404

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230508

R150 Certificate of patent or registration of utility model

Ref document number: 7277456

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350