(57)【要約】無線送信／受信ユニット（ＷＴＲＵ）は、各々が優先度と関連付けられてもよい第１の部分および第２の優先度と関連付けられた第２の部分を含むグラントフリー送信を送ってもよい。第１の部分の優先度は、第２の部分の優先度よりも高くてもよい。ＷＴＲＵは、バックオフ値の第１の範囲から第１のバックオフ値を選択してもよい。ＷＴＲＵは、グラントフリー送信が成功したかどうかを判定してもよい。グラントフリー送信が成功しなかった場合、ＷＴＲＵは、グラントフリー送信の再送信を送ってもよく、グラントフリー送信の再送信は、第１の部分を含んでもよく、第２の部分を含まなくてもよい。再送信は、バックオフ値の第１の範囲よりも大きくてもよい、バックオフ値の第２の範囲から第２のバックオフ値を選択してもよい。第２のバックオフ値は、再送信を送る前にスキップするグラントフリーリソースの数を示してもよい。
2021508422.tif 000002
【特許請求の範囲】
【請求項１】
第１の優先度と関連付けられた第１の部分および第２の優先度と関連付けられた第２の部分を含む第１の送信を送り、前記第１の送信は、第１のグラントフリー送信であり、前記第１の優先度は、前記第２の優先度よりも高い優先度であり、前記第１の送信は、バックオフ値の第１の範囲から選択された第１のバックオフ値を使用し、
前記第１の送信が成功するかどうかを判定し、
前記第１の送信が成功したと判定することを条件に、前記第１の送信の再送信から前記第２の部分をドロップすると判定し、
前記再送信を送り、前記再送信は、前記第１の部分を含み、前記第２の部分を含まず、前記再送信は、第２のグラントフリー送信であり、前記再送信は、バックオフ値の第２の範囲から選択された第２のバックオフ値を使用し、バックオフ値の前記第２の範囲は、バックオフ値の前記第１の範囲よりも大きい、
ように少なくとも構成されたプロセッサを備えたことを特徴とする無線送信／受信ユニット（ＷＴＲＵ）。
【請求項２】
前記第２のバックオフ値は、前記再送信を送る前にスキップするグラントフリーリソースの数を示し、前記プロセッサは、
前記第１の送信が成功しないと判定した後、前記第２のバックオフ値によって示された数のグラントフリーリソースをスキップする
ように更に構成されていることを特徴とする請求項１に記載のＷＴＲＵ。
【請求項３】
前記第１の送信は、第１の冗長バージョンを使用して第１のトランスポートブロック上で多重化され、前記再送信は、第２の冗長バージョンを使用して第２のトランスポートブロック上で多重化され、前記第２の冗長バージョンは、前記第１の冗長バージョンよりも高い冗長性と関連付けられていることを特徴とする請求項１に記載のＷＴＲＵ。
【請求項４】
前記第１の送信および前記再送信は、アップリンク制御情報（ＵＣＩ）と関連付けられ、前記第１の送信および前記再送信は、物理アップリンク共有チャネル（ＰＵＳＣＨ）上で送られることを特徴とする請求項１に記載のＷＴＲＵ。
【請求項５】
前記プロセッサは、バックオフ値の前記第１の範囲のインジケーションを受信するように更に構成されていることを特徴とする請求項１に記載のＷＴＲＵ。
【請求項６】
前記プロセッサは、バックオフ値の前記第１の範囲のサイズに基づいて、バックオフ値の前記第２の範囲を判定するように更に構成されていることを特徴とする請求項１に記載のＷＴＲＵ。
【請求項７】
前記プロセッサは、
多重化優先度情報を受信し、
前記多重化優先度情報に基づいて、前記第１の部分と関連付けられた前記第１の優先度を判定し、
前記多重化優先度情報に基づいて、前記第２の部分と関連付けられた前記第２の優先度を判定する、
ように更に構成されていることを特徴とする請求項１に記載のＷＴＲＵ。
【請求項８】
前記第１の部分は、確認応答情報と関連付けられ、前記第２の部分は、チャネル品質情報（ＣＱＩ）と関連付けられている、ことを特徴とする請求項１に記載のＷＴＲＵ。
【請求項９】
第１の優先度と関連付けられた第１の部分および第２の優先度と関連付けられた第２の部分を含む第１の送信を送るステップであって、前記第１の送信は、第１のグラントフリー送信であり、前記第１の優先度は、前記第２の優先度よりも高い優先度であり、前記第１の送信は、バックオフ値の第１の範囲から選択された第１のバックオフ値を使用する、ステップと、
前記第１の送信が成功するかどうかを判定するステップと、
前記第１の送信が成功したと判定することを条件に、前記第１の送信の再送信から前記第２の部分をドロップすると判定するステップと、
前記再送信を送るステップであって、前記再送信は、前記第１の部分を含み、前記第２の部分を含まず、前記再送信は、第２のグラントフリー送信であり、前記再送信は、バックオフ値の第２の範囲から選択された第２のバックオフ値を使用し、バックオフ値の前記第２の範囲は、バックオフ値の前記第１の範囲よりも大きい、ステップと、
を備えたことを特徴とする方法。
【請求項１０】
前記第２のバックオフ値は、前記再送信を送る前にスキップするグラントフリーリソースの数を示し、前記方法は、
前記第１の送信が成功しないと判定した後、前記第２のバックオフ値によって示された数のグラントフリーリソースをスキップするステップを更に備えた
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１の送信は、第１の冗長バージョンを使用して第１のトランスポートブロック上で多重化され、前記再送信は、第２の冗長バージョンを使用して第２のトランスポートブロック上で多重化され、前記第２の冗長バージョンは、前記第１の冗長バージョンよりも高い冗長性と関連付けられていることを特徴とする請求項９に記載の方法。
【請求項１２】
前記第１の送信および前記再送信は、アップリンク制御情報（ＵＣＩ）と関連付けられ、前記第１の送信および前記再送信は、物理アップリンク共有チャネル（ＰＵＳＣＨ）上で送られることを特徴とする請求項９に記載の方法。
【請求項１３】
バックオフ値の前記第１の範囲のインジケーションを受信するステップを更に備えたことを特徴とする請求項９に記載の方法。
【請求項１４】
バックオフ値の前記第１の範囲のサイズに基づいて、バックオフ値の前記第２の範囲を判定するステップを更に備えたことを特徴とする請求項９に記載の方法。
【請求項１５】
多重化優先度情報を受信するステップと、
前記多重化優先度情報に基づいて、前記第１の部分と関連付けられた前記第１の優先度を判定するステップと、
前記多重化優先度情報に基づいて、前記第２の部分と関連付けられた前記第２の優先度を判定するステップと、
を更に備えたことを特徴とする請求項９に記載の方法。
【請求項１６】
前記第１の部分は、確認応答情報と関連付けられ、前記第２の部分は、チャネル品質情報（ＣＱＩ）と関連付けられている、ことを特徴とする請求項９に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、参照によってその全体が本明細書に組み込まれる、２０１７年１１月１５日に出願された米国仮特許出願第６２／５８６，４７３号からの優先権を主張する。
【背景技術】
【０００２】
無線通信システムでは、中央ノードは、１つまたは複数の無線送信／受信ユニット（ＷＴＲＵ）にサービス提供することができる。中央ノードが１つまたは複数のＷＴＲＵにサービスを提供するとき、中央ノードにトランスポートブロック（ＴＢ）を送信する機会は、中央ノードによって管理されることがある。例えば、中央ノードは、ＷＴＲＵアップリンク（ＵＬ）送信をスケジュールすることがある。
【発明の概要】
【０００３】
無線送信／受信ユニット（ＷＴＲＵ）は、グラントフリーリソース上でグラントフリー送信を送ってもよい。ＷＴＲＵは、第１の部分および第２の部分を含むグラントフリー送信を送ってもよい。第１の部分および第２の部分は各々、優先度と関連付けられてもよい。第１の部分と関連付けられた優先度は、第２の部分と関連付けられた優先度よりも高い優先度であってもよい。例えば、第１の部分は、確認応答情報（例えば、ハイブリッド自動再送要求（ＨＡＲＱ））を含んでもよく、第２の部分は、チャネル品質情報（ＣＱＩ）を含んでもよい。ＷＴＲＵは、バックオフ値の第１の範囲から第１のグラントフリー送信に対する第１のバックオフ値を選択してもよい。ＷＴＲＵは、第１のグラントフリー送信が成功したかどうかを判定してもよい。第１のグラントフリー送信が成功しなかった場合、ＷＴＲＵは、第１のグラントフリー送信の再送信を送ってもよい。再送信は、第１の部分を含んでもよく、第２の部分を含まなくてもよい。ＷＴＲＵは、バックオフ値の第２の範囲から再送信に対する第２のバックオフ値を選択してもよい。バックオフ値の第２の範囲は、バックオフ値の第１の範囲よりも大きくてもよい。バックオフ値の第２の範囲は、再送信を送る前にスキップするグラントフリーリソースの数を示してもよい。
【０００４】
多重化は、第１のグラントフリー送信および／または第１のグラントフリー送信の再送信に対して使用されてもよい。第１のグラントフリー送信は、第１の冗長バージョンを使用して、トランスポートブロック上で多重化されてもよい。再送信は、第２の冗長バージョンを使用して、別のトランスポートブロック上で多重化されてもよい。第２の冗長バージョンは、第１の冗長バージョンよりも高い冗長性と関連付けられてもよい。
【０００５】
添付図面と共に実施例を考慮して、以下の説明からより詳細な理解を得ることができる。
【図面の簡単な説明】
【０００６】
【図１Ａ】１つまたは複数の開示される実施形態を実装することができる例示的な通信システムを例示するシステム図である。
【図１Ｂ】実施形態に従った、図１Ａに例示された通信システム内で使用することができる例示的な無線送信／受信ユニット（ＷＴＲＵ）を例示するシステム図である。
【図１Ｃ】実施形態に従った、図１Ａに例示された通信システム内で使用することができる例示的な無線アクセスネットワーク（ＲＡＮ）および例示的なコアネットワーク（ＣＮ）を例示するシステム図である。
【図１Ｄ】実施形態に従った、図１Ａに例示された通信システム内で使用することができる更なる例示的なＲＡＮおよび更なる例示的なＣＮを例示するシステム図である。
【図２】スロットの間のスケジュールされたグラントフリー（ＧＦ：ｇｒａｎｔ−ｆｒｅｅ）リソースの例を示す。
【図３】スロット内でスケジュールされた（例えば、ｇＮｏｄｅＢ（ｇＮＢ）によってスロット内でスケジュールされた）例示的なグラントフリーリソースを示す。
【図４】スロット内でスケジュールされた（例えば、ｇＮＢによってスロット内でスケジュールされた）例示的なグラントフリーリソースおよび無線送信／受信ユニット（ＷＴＲＵ）の保留（ｐｅｎｄｉｎｇ）トランスポートブロック（ＴＢ）についてのリソースを使用することを試みている３つのＷＴＲＵを示す。
【図５】スロット内でスケジュールされた（例えば、ｇＮＢによってスロット内でスケジュールされた）例示的なグラントフリーリソースおよびＷＴＲＵの保留ＴＢについてのリソースを使用することを試みている３つのＷＴＲＵを示す。
【発明を実施するための形態】
【０００７】
例示的な実施形態を含むことができる詳細な説明は、様々な図面を参照してここで説明される。この詳細な説明は、取り得る実装態様の詳細な実施例を提供することができるが、詳細は例示的であることを意図しており、本出願の範囲を限定することを意図していないことに留意されるべきである。
【０００８】
図１Ａは、１つまたは複数の開示される実施形態を実装することができる、例示的な通信システム１００を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムであってもよい。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通じて、そのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）、ゼロテールユニークワードＤＦＴ拡散ＯＦＤＭ（ＺＴ  ＵＷ  ＤＴＳ−ｓ  ＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ−ＯＦＤＭ）、リソースブロックフィルタードＯＦＤＭ、およびフィルタバンクマルチキャリア（ＦＢＭＣ）など、１つまたは複数のチャネルアクセス方法を利用してもよい。
【０００９】
図１Ａに示されるように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、ＲＡＮ１０４／１１３と、ＣＮ１０６／１１５と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含んでもよいが、開示される実施形態は、いずれかの数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を考慮していることが認識されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成されたいずれかのタイプのデバイスであってもよい。例として、そのいずれかが、「局」および／または「ＳＴＡ」と称されてもよい、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、サブスクリクションベースのユニット、ページャ、セルラ電話、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポットまたはＭｉ−Ｆｉデバイス、モノノインターネット（ＩｏＴ）デバイス、ウォッチまたは他のウェアラブル、ヘッドマウントディスプレイ（ＨＭＤ）、車両、ドローン、医療用デバイスおよびアプリケーション（例えば、遠隔手術）、工業用デバイスおよびアプリケーション（例えば、工業用および／または自動化された処理チェーン状況において動作するロボットおよび／または他の無線デバイス）、家電デバイス、ならびに商業用および／または工業用無線ネットワーク上において動作するデバイスなどを含んでもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいずれも、交換可能にＵＥと称されてもよい。
【００１０】
通信システム１００はまた、基地局１１４ａおよび／または基地局１１４ｂを含んでもよい。基地局１１４ａ、１１４ｂの各々は、ＣＮ１０６／１１５、インターネット１１０、および／または他のネットワーク１１２など、１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインタフェースをとるように構成されたいずれかのタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、基地送受信機局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、ｇＮＢ、ＮＲ  ＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどであってもよい。基地局１１４ａ、１１４ｂは、各々が、単一の要素として表されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが理解されよう。
【００１１】
基地局１１４ａは、ＲＡＮ１０４／１１３の一部であってもよく、ＲＡＮ１０４／１１３は、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示されず）も含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示されず）と称されてもよい、１つまたは複数のキャリア周波数上において、無線信号を送信および／または受信するように構成されてもよい。これらの周波数は、認可スペクトル、非認可スペクトル、または認可スペクトルと非認可スペクトルとの組み合わせの中にあってもよい。セルは、相対的に固定であってもよくまたは時間とともに変化してもよい特定の地理的エリアに、無線サービス用のカバレージを提供してもよい。セルは、更に、セルセクタに分割されてもよい。例えば、基地局１１４ａと関連付けられたセルは、３つのセクタに分割されてもよい。したがって、一実施形態では、基地局１１４ａは、送受信機を３つ、すなわち、セルの各セクタに対して１つずつ含んでよい。実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を利用してもよく、セルの各セクタに対して複数の送受信機を利用してもよい。例えば、所望の空間方向において信号を送信および／または受信するために、ビームフォーミングが使用されてもよい。
【００１２】
基地局１１４ａ、１１４ｂは、エアインタフェース１１６上において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信してもよく、エアインタフェース１１６は、いずれかの適切な無線通信リンク（例えば、無線周波（ＲＦ）、マイクロ波、センチメートル波、マイクロメートル波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であってもよい。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。
【００１３】
より具体的には、上述されたように、通信システム１００は、多元接続システムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ−ＦＤＭＡなど、１つまたは複数のチャネルアクセス方式を採用してもよい。例えば、ＲＡＮ１０４／１１３内の基地局１１４ａと、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用して、エアインタフェース１１５／１１６／１１７を確立してもよい、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実装してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでよい。ＨＳＰＡは、高速ダウンリンク（ＤＬ）パケットアクセス（ＨＳＤＰＡ）、および／または高速アップリンク（ＵＬ）パケットアクセス（ＨＳＵＰＡ）を含んでもよい。
【００１４】
基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）、および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）、および／またはＬＴＥアドバンストプロ（ＬＴＥ−Ａ  Ｐｒｏ）を使用して、エアインタフェース１１６を確立してもよい、進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装してもよい。
【００１５】
実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ニューラジオ（ＮＲ）を使用して、エアインタフェース１１６を確立してもよい、ＮＲ無線アクセスなどの無線技術を実装してもよい。
【００１６】
実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実装してもよい。例えば、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、例えば、デュアルコネクティビティ（ＤＣ）原理を使用して、ＬＴＥ無線アクセスおよびＮＲ無線アクセスを共に実装してもよい。したがって、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインタフェースは、複数のタイプの無線アクセス技術、ならびに／または複数のタイプの基地局（例えば、ｅＮＢおよびｇＮＢ）に送信される／そこから送信される送信によって特徴付けられてもよい。
【００１７】
他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（すなわち、ワイヤレスフィデリティ（ＷｉＦｉ））、ＩＥＥＥ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ  Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００  ＥＶ−ＤＯ、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、移動体通信用グローバルシステム（ＧＳＭ）、ＧＳＭエボリューション用高速データレート（ＥＤＧＥ）、およびＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。
【００１８】
図１Ａにおける基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってもよく、事業所、自宅、車両、キャンパス、産業用施設、（例えば、ドローンによって使用される）エアコリド、および車道など、局所化されたエリアにおける無線接続性を容易にするために、任意の適切なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｂと、ＷＴＲＵ１０２ｃ、１０２ｄとは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。実施形態では、基地局１１４ｂと、ＷＴＲＵ１０２ｃ、１０２ｄとは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。また別の実施形態では、基地局１１４ｂと、ＷＴＲＵ１０２ｃ、１０２ｄとは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａ、ＬＴＥ−Ａ  Ｐｒｏ、ＮＲなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接的な接続を有してもよい。したがって、基地局１１４ｂは、ＣＮ１０６／１１５を介してインターネット１１０にアクセスする必要がないことがある。
【００１９】
ＲＡＮ１０４／１１３は、ＣＮ１０６／１１５と通信してもよく、ＣＮ１０６／１１５は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成された任意のタイプのネットワークであってもよい。データは、異なるスループット要件、遅延要件、エラー耐性要件、信頼性要件、データスループット要件、およびモビリティ要件など、様々なサービス品質（ＱｏＳ）要件を有してもよい。ＣＮ１０６／１１５は、呼制御、ビリングサービス、モバイルロケーションベースのサービス、プリペイド発呼、インターネット接続性、ビデオ配信などを提供してもよく、および／またはユーザ認証など、高レベルセキュリティ機能を実行してもよい。図１Ａには示されていないが、ＲＡＮ１０４／１１３および／またはＣＮ１０６／１１５は、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的通信を行ってもよいことが理解されよう。例えば、ＮＲ無線技術を利用していることがあるＲＡＮ１０４／１１３に接続されていることに加えて、ＣＮ１０６／１１５は、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ−ＵＴＲＡ、またはＷｉＦｉ無線技術を利用する別のＲＡＮ（図示されず）とも通信してもよい。
【００２０】
ＣＮ１０６／１１５は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄが、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとしての役割も果たしてもよい。ＰＳＴＮ１０８は、基本電話サービスを提供する、回線交換電話網を含んでよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の送信制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、および／またはインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスからなる地球規模のシステムを含んでよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される、有線および／または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを利用してもよい１つまたは複数のＲＡＮに接続された、別のＣＮを含んでもよい。
【００２１】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちのいくつかまたは全ては、マルチモード機能を含んでよい（例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンク上において、異なる無線ネットワークと通信するための、複数の送受信機を含んでよい）。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用してもよい基地局１１４ａと通信するように、またＩＥＥＥ８０２無線技術を利用してもよい基地局１１４ｂと通信するように構成されてもよい。
【００２２】
図１Ｂは、例示的なＷＴＲＵ１０２を示すシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、とりわけ、プロセッサ１１８、送受信機１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および／または他の周辺機器１３８を含んでよい。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、上記の要素の任意のサブコンビネーションを含んでよいことが理解されよう。
【００２３】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および状態機械などであってもよい。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境において動作することを可能にする他の任意の機能性を実行してもよい。プロセッサ１１８は、送受信機１２０に結合されてもよく、送受信機１２０は、送信／受信要素１２２に結合されてもよい。図１Ｂは、プロセッサ１１８と送受信機１２０を別個の構成要素として表しているが、プロセッサ１１８と送受信機１２０は、電子パッケージまたはチップ内に一緒に統合されてもよいことが理解されよう。
【００２４】
送信／受信要素１２２は、エアインタフェース１１６上において、基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成されてもよい。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器であってもよい。また別の実施形態では、送信／受信要素１２２は、ＲＦ信号および光信号の両方を送信および／または受信するように構成されてもよい。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されてもよいことが理解されよう。
【００２５】
図１Ｂにおいては、送信／受信要素１２２は、単一の要素として表されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含んでよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を利用してもよい。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６上において無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含んでよい。
【００２６】
送受信機１２０は、送信／受信要素１２２によって送信されることになる信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成されてもよい。上で言及されたように、ＷＴＲＵ１０２は、マルチモード機能を有してもよい。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えば、ＮＲおよびＩＥＥＥ８０２．１１など、複数のＲＡＴを介して通信することを可能にするための、複数の送受信機を含んでよい。
【００２７】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶表示（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、それらからユーザ入力データを受信してもよい。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力してもよい。加えて、プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２など、任意のタイプの適切なメモリから情報を入手してもよく、それらにデータを記憶してもよい。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含んでよい。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含んでよい。他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示されず）上などに配置された、ＷＴＲＵ１０２上に物理的に配置されていないメモリから情報を入手してもよく、それらにデータを記憶してもよい。
【００２８】
プロセッサ１１８は、電源１３４から電力を受け取ってもよく、ＷＴＲＵ１０２内の他の構成要素に電力を分配するように、および／またはそれらへの電力を制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に給電するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケル−カドミウム（ＮｉＣｄ）、ニッケル−亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウム−イオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含んでよい。
【００２９】
プロセッサ１１８は、ＧＰＳチップセット１３６にも結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在のロケーションに関するロケーション情報（例えば、経度および緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれの代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインタフェース１１６上においてロケーション情報を受信してもよく、および／または２つ以上の近くの基地局から受信されている信号のタイミングに基づいて、自らのロケーションを決定してもよい。ＷＴＲＵ１０２は、実施形態との整合性を保ちながら、任意の適切なロケーション決定方法を用いて、ロケーション情報を取得してもよいことが理解されよう。
【００３０】
プロセッサ１１８は、更に他の周辺機器１３８に結合されてもよく、他の周辺機器１３８は、追加の特徴、機能性、および／または有線もしくは無線接続性を提供する、１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含んでよい。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星送受信機、（写真および／またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実および／または拡張現実（ＶＲ／ＡＲ）デバイス、ならびにアクティビティトラッカなどを含んでよい。周辺機器１３８は、１つまたは複数のセンサを含んでよく、センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、方位センサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、バイオメトリックセンサ、および／または湿度センサのうちの１つまたは複数であってもよい。
【００３１】
ＷＴＲＵ１０２は、（例えば、（例えば、送信用の）ＵＬと（例えば、受信用の））ダウンリンクの両方のための特定のサブフレームと関連付けられた信号のいくつかまたは全ての送信および受信が、並列および／または同時であってもよい、全二重無線を含んでよい。全二重無線は、ハードウェア（例えば、チョーク）を介して、またはプロセッサ（例えば、別個のプロセッサ（図示されず）もしくはプロセッサ１１８）を介する信号処理を介して、自己干渉を低減させ、および／または実質的に除去するために、干渉管理ユニット１３９を含んでよい。実施形態では、ＷＴＲＵ１０２は、（例えば、（例えば、送信用の）ＵＬまたは（例えば、受信用の）ダウンリンクのどちらかのための特定のサブフレームと関連付けられた）信号のいくつかまたは全ての送信および受信のための、半二重無線を含んでよい。
【００３２】
図１Ｃは、実施形態に従った、ＲＡＮ１０４およびＣＮ１０６を例示するシステム図である。上述されたように、ＲＡＮ１０４は、エアインタフェース１１６を通じてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線技術を採用してもよい。ＲＡＮ１０４は、ＣＮ１０６とも通信してもよい。
【００３３】
ＲＡＮ１０４は、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃを含んでよいが、ＲＡＮ１０４は、実施形態との整合性を維持しながら、任意の数のｅＮｏｄｅＢを含んでよいことが理解されよう。ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、各々が、エアインタフェース１１６上においてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための、１つまたは複数の送受信機を含んでよい。一実施形態では、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、ｅＮｏｄｅＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および／またはＷＴＲＵ１０２ａから無線信号を受信してもよい。
【００３４】
ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示されず）と関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、ならびにＵＬおよび／またはＤＬにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図１Ｃに示されるように、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インタフェース上において、相互に通信してもよい。
【００３５】
図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２と、サービングゲートウェイ（ＳＧＷ）１６４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（またはＰＧＷ）１６６とを含んでよい。上記の要素の各々は、ＣＮ１０６の部分として描かれているが、これらの要素のうちのいずれも、ＣＮオペレータとは異なるエンティティによって所有および／または運営されてもよいことが理解されよう。
【００３６】
ＭＭＥ１６２は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてもよく、制御ノードとしての役割を果たしてもよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチ中に特定のサービングゲートウェイを選択することなどを担ってもよい。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭおよび／またはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示されず）との間における交換のためのコントロールプレーン機能を提供してもよい。
【００３７】
ＳＧＷ１６４は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてもよい。ＳＧＷ１６４は、一般に、ユーザデータパケットを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃからルーティングおよび転送してもよい。ＳＧＷ１６４は、ｅＮｏｄｅＢ間ハンドオーバ中にユーザプレーンをアンカリングすること、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときにページングをトリガすること、ならびにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなど、他の機能を実行してもよい。
【００３８】
ＳＧＷ１６４は、ＰＧＷ１６６に接続されてもよく、ＰＧＷ１６６は、インターネット１１０など、パケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。
【００３９】
ＣＮ１０６は、他のネットワークとの通信を容易にすることができる。例えば、ＣＮ１０６は、ＰＳＴＮ１０８など、回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話回線通信デバイスとの間の通信を容易にしてもよい。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインタフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでよく、またはそれと通信してもよい。加えて、ＣＮ１０６は、他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよく、他のネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線および／または無線ネットワークを含んでもよい。
【００４０】
図１Ａ乃至図１Ｄにおいては、ＷＴＲＵは、無線端末として説明されるが、ある代表的な実施形態では、そのような端末は、通信ネットワークとの有線通信インタフェースを（例えば、一時的または永続的に）使用することができることが企図されている。
【００４１】
代表的な実施形態では、他のネットワーク１１２は、ＷＬＡＮであってもよい。
【００４２】
インフラストラクチャ基本サービスセット（ＢＳＳ）モードにあるＷＬＡＮは、ＢＳＳのためのアクセスポイント（ＡＰ）と、ＡＰと関連付けられた１つまたは複数の局（ＳＴＡ）とを有してもよい。ＡＰは、トラフィックをＢＳＳ内および／またはＢＳＳ外に搬送する、ディストリビューションシステム（ＤＳ）または別のタイプの有線／無線ネットワークへのアクセスまたはインタフェースを有してもよい。ＢＳＳ外部から発信されたＳＴＡへのトラフィックは、ＡＰを通じて到着してもよく、ＳＴＡに配送されてもよい。ＳＴＡからＢＳＳ外部の送信先に発信されたトラフィックは、それぞれの送信先に配送するために、ＡＰに送信されてもよい。ＢＳＳ内のＳＴＡ間のトラフィックは、ＡＰを通じて送信されてもよく、例えば、送信元ＳＴＡは、トラフィックをＡＰに送信してもよく、ＡＰは、トラフィックを送信先ＳＴＡに配送してもよい。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックと見なされてもよく、および／またはピアツーピアトラフィックと呼ばれてもよい。ピアツーピアトラフィックは、直接リンクセットアップ（ＤＬＳ）を用いて、送信元ＳＴＡと送信先ＳＴＡとの間で（例えば、直接的に）送信されてもよい。ある代表的な実施形態では、ＤＬＳは、８０２．１１ｅ  ＤＬＳまたは８０２．１１ｚトンネルＤＬＳ（ＴＤＬＳ）を使用してもよい。独立ＢＳＳ（ＩＢＳＳ）モードを使用するＷＬＡＮは、ＡＰを有さなくてもよく、ＩＢＳＳ内の、またはＩＢＳＳを使用するＳＴＡ（例えば、ＳＴＡの全て）は、相互に直接的に通信してもよい。ＩＢＳＳモードの通信は、本明細書においては、ときに「アドホック」モードの通信と称されてもよい。
【００４３】
８０２．１１ａｃインフラストラクチャモードの動作または類似したモードの動作を使用するとき、ＡＰは、プライマリチャネルなどの固定されたチャネル上において、ビーコンを送信してもよい。プライマリチャネルは、固定された幅（例えば、２０ＭＨｚ幅帯域幅）、またはシグナリングを介して動的に設定された幅であってもよい。プライマリチャネルは、ＢＳＳの動作チャネルであってもよく、ＡＰとの接続を確立するために、ＳＴＡによって使用されてもよい。ある代表的な実施形態では、例えば、８０２．１１システムにおいては、キャリアセンス多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）が、実装されてもよい。ＣＳＭＡ／ＣＡの場合、ＡＰを含むＳＴＡ（例えば、あらゆるＳＴＡ）は、プライマリチャネルをセンスしてもよい。プライマリチャネルが、センス／検出され、および／または特定のＳＴＡによってビジーであると決定された場合、特定のＳＴＡは、バックオフしてもよい。与えられたＢＳＳ内においては、任意の与えられた時間に、１つのＳＴＡ（例えば、ただ１つの局）が、送信してもよい。
【００４４】
高スループット（ＨＴ）ＳＴＡは、例えば、プライマリ２０ＭＨｚチャネルを隣接または非隣接２０ＭＨｚチャネルと組み合わせて、４０ＭＨｚ幅のチャネルを形成することを介して、通信のために４０ＭＨｚ幅チャネルを使用してもよい。
【００４５】
超高スループット（ＶＨＴ）ＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、および／または１６０ＭＨｚ幅のチャネルをサポートすることができる。４０ＭＨｚおよび／または８０ＭＨｚチャネルは、連続する２０ＭＨｚチャネルを組み合わせることによって形成されてもよい。１６０ＭＨｚチャネルは、８つの連続する２０ＭＨｚチャネルを組み合わせることによって形成されてもよく、または２つの非連続な８０ＭＨｚチャネルを組み合わせることによって形成されてもよく、これは、８０＋８０構成と呼ばれてもよい。８０＋８０構成の場合、データは、チャネルエンコーディングの後、データを２つのストリームに分割し得るセグメントパーサを通過させられてもよい。各ストリームに対して別々に、逆高速フーリエ変換（ＩＦＦＴ）処理、および時間領域処理が、行われてもよい。ストリームは、２つの８０ＭＨｚチャネル上にマッピングされてもよく、データは、送信ＳＴＡによって送信されてもよい。受信ＳＴＡの受信機においては、８０＋８０構成のための上で説明された動作が、逆転されてもよく、組み合わされたデータは、媒体アクセス制御（ＭＡＣ）に送信されてもよい。
【００４６】
１ＧＨｚ未満モードの動作は、８０２．１１ａｆおよび８０２．１１ａｈによってサポートされる。チャネル動作帯域幅およびキャリアは、８０２．１１ｎおよび８０２．１１ａｃにおいて使用されるそれらと比べて、８０２．１１ａｆおよび８０２．１１ａｈにおいては低減させられる。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトルにおいて、５ＭＨｚ、１０ＭＨｚ、および２０ＭＨｚ帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して、１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、および１６ＭＨｚ帯域幅をサポートする。代表的な実施形態に従うと、８０２．１１ａｈは、マクロカバレージエリアにおけるＭＴＣデバイスなど、メータタイプ制御／マシンタイプコミュニケーションをサポートしてもよい。ＭＴＣデバイスは、一定の機能を、例えば、一定の帯域幅および／または限られた帯域幅のサポート（例えば、それらのサポートだけ）を含む限られた機能を有してもよい。ＭＴＣデバイスは、（例えば、非常に長いバッテリ寿命を維持するために）閾値を上回るバッテリ寿命を有するバッテリを含んでよい。
【００４７】
８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、および８０２．１１ａｈなど、複数のチャネルおよびチャネル帯域幅をサポートすることができるＷＬＡＮシステムは、プライマリチャネルとして指定されてもよいチャネルを含む。プライマリチャネルは、ＢＳＳ内の全てのＳＴＡによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有してもよい。プライマリチャネルの帯域幅は、ＢＳＳ内において動作する全てのＳＴＡの中の、最小帯域幅動作モードをサポートするＳＴＡによって設定および／または制限されてもよい。８０２．１１ａｈの例においては、ＢＳＳ内のＡＰおよび他のＳＴＡが、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、および／または他のチャネル帯域幅動作モードをサポートする場合であっても、１ＭＨｚモードをサポートする（例えば、それだけをサポートする）ＳＴＡ（例えば、ＭＴＣタイプデバイス）のために、プライマリチャネルは、１ＭＨｚ幅であってもよい。キャリアセンシングおよび／またはネットワークアロケーションベクトル（ＮＡＶ）設定は、プライマリチャネルのステータスに依存してもよい。例えば、（１ＭＨｚ動作モードだけをサポートする）ＳＴＡが、ＡＰに送信しているせいで、プライマリチャネルが、ビジーである場合、周波数バンドの大部分が、アイドルのままであり、利用可能であり得るとしても、利用可能な周波数バンド全体が、ビジーと見なされてもよい。
【００４８】
米国では、８０２．１１ａｈによって使用されてもよい利用可能な周波数バンドは、９０２ＭＨｚから９２８ＭＨｚである。韓国においては、利用可能な周波数バンドは、９１７．５ＭＨｚから９２３．５ＭＨｚである。日本においては、利用可能な周波数バンドは、９１６．５ＭＨｚから９２７．５ＭＨｚである。８０２．１１ａｈのために利用可能な合計帯域幅は、国の規則に応じて、６ＭＨｚから２６ＭＨｚである。
【００４９】
図１Ｄは、実施形態に従った、ＲＡＮ１１３およびＣＮ１１５を例示するシステム図である。上述されたように、ＲＡＮ１１３は、ＮＲ無線技術を利用して、エアインタフェース１１６上において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信してもよい。ＲＡＮ１１３は、ＣＮ１１５とも通信してもよい。
【００５０】
ＲＡＮ１１３は、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含んでよいが、ＲＡＮ１１３は、実施形態との整合性を維持しながら、任意の数のｇＮＢを含んでよいことが理解されよう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、各々が、エアインタフェース１１６上においてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための、１つまたは複数の送受信機を含んでよい。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装してもよい。例えば、ｇＮＢ１８０ａ、１０８ｂは、ビームフォーミングを利用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに信号を送信し、および／またはｇＮＢ１８０ａ、１８０ｂ、１８０ｃから信号を受信してもよい。したがって、ｇＮＢ１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および／またはＷＴＲＵ１０２ａから無線信号を受信してもよい。実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、キャリアアグリゲーション技術を実装してもよい。例えば、ｇＮＢ１８０ａは、ＷＴＲＵ１０２ａに複数のコンポーネントキャリアを送信してもよい（図示されず）。これらのコンポーネントキャリアのサブセットは、免許不要スペクトル上にあってもよいが、残りのコンポーネントキャリアは、免許要スペクトル上にあってもよい。実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、多地点協調（ＣｏＭＰ）技術を実装してもよい。例えば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａとｇＮＢ１８０ｂ（および／またはｇＮＢ１８０ｃ）とから調整された送信を受信してもよい。
【００５１】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルなヌメロロジ（ｎｕｍｅｒｏｌｏｇｙ）と関連付けられた送信を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。例えば、ＯＦＤＭシンボル間隔、および／またはＯＦＤＭサブキャリア間隔は、異なる送信、異なるセル、および／または無線送信スペクトルの異なる部分ごとに様々であってもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（例えば、様々な数のＯＦＤＭシンボルを含む、および／または様々な長さの絶対時間だけ持続する）様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔（ＴＴＩ）を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。
【００５２】
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成および／または非スタンドアロン構成で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成されてもよい。スタンドアロン構成においては、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（例えば、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃなどの）他のＲＡＮにアクセスすることもなしに、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。スタンドアロン構成においては、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数を、モビリティアンカポイントとして利用してもよい。スタンドアロン構成においては、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、免許不要バンド内において信号を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。非スタンドアロン構成においては、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮとも通信し／別のＲＡＮにも接続しながら、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し／ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに接続してもよい。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＤＣ原理を実装して、１つまたは複数のｇＮＢ１８０ａ、１８０ｂ、１８０ｃ、および１つまたは複数のｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信してもよい。非スタンドアロン構成においては、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのモビリティアンカとしての役割を果たしてもよく、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにサービスするための追加のカバレージおよび／またはスループットを提供することができる。
【００５３】
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示されず）と関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアルコネクティビティ、ＮＲとＥ−ＵＴＲＡとの間のインターワーキング、ユーザプレーンデータのユーザプレーン機能（ＵＰＦ）１８４ａ、１８４ｂへのルーティング、ならびにコントロールプレーン情報のアクセスおよびモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂへのルーティングなどを処理するように構成されてもよい。図１Ｄに示されるように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインタフェース上において、互いに通信してもよい。
【００５４】
図１Ｄに示されるＣＮ１１５は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂと、少なくとも１つのＵＰＦ１８４ａ、１８４ｂと、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂと、おそらくは、データネットワーク（ＤＮ）１８５ａ、１８５ｂとを含んでよい。上記の要素の各々は、ＣＮ１１５の部分として描かれているが、これらの要素のうちのいずれも、ＣＮオペレータとは異なるエンティティによって所有および／または運営されてもよいことが理解されよう。
【００５５】
ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インタフェースを介して、ＲＡＮ１１３内のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されてもよく、制御ノードとしての役割を果たしてもよい。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ネットワークスライシングのサポート（例えば、異なる要件を有する異なるＰＤＵセッションの処理）、特定のＳＭＦ１８３ａ、１８３ｂを選択すること、レジストレーションエリアの管理、ＮＡＳシグナリングの終了、およびモビリティ管理などを担ってもよい。ネットワークスライシングは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるサービスのタイプに基づいて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに対するＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用されてもよい。例えば、超高信頼低遅延（ＵＲＬＬＣ）アクセスに依存するサービス、高速大容量モバイルブロードバンド（ｅＭＢＢ）アクセスに依存するサービス、および／またはマシンタイプコミュニケーション（ＭＴＣ）アクセスのためのサービスなど、異なる使用事例のために、異なるネットワークスライスが、確立されてもよい。ＡＭＦ１６２は、ＲＡＮ１１３と、ＬＴＥ、ＬＴＥ−Ａ、ＬＴＥ−Ａ  Ｐｒｏ、および／またはＷｉＦｉなどの非３ＧＰＰアクセス技術など、他の無線技術を利用する他のＲＡＮ（図示されず）との間の交換のためのコントロールプレーン機能を提供してもよい。
【００５６】
ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インタフェースを介して、ＣＮ１１５内のＡＭＦ１８２ａ、１８２ｂに接続されてもよい。ＳＭＦ１８３ａ、１８３ｂは、Ｎ４インタフェースを介して、ＣＮ１１５内のＵＰＦ１８４ａ、１８４ｂにも接続されてもよい。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択および制御し、ＵＰＦ１８４ａ、１８４ｂを通じたトラフィックのルーティングを構成してもよい。ＳＭＦ１８３ａ、１８３ｂは、ＵＥ  ＩＰアドレスの管理および割り当てを行うこと、ＰＤＵセッションを管理すること、ポリシ実施およびＱｏＳを制御すること、ならびにダウンリンクデータ通知を提供することなど、他の機能を実行してもよい。ＰＤＵセッションタイプは、ＩＰベース、非ＩＰベース、およびイーサネットベースなどであってもよい。
【００５７】
ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インタフェースを介して、ＲＡＮ１１３内のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されてもよく、それらは、インターネット１１０など、パケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。ＵＰＦ１８４ａ、１８４ｂは、パケットをルーティングおよび転送すること、ユーザプレーンポリシを実施すること、マルチホーミングＰＤＵセッションをサポートすること、ユーザプレーンＱｏＳを処理すること、ダウンリンクパケットをバッファすること、ならびにモビリティアンカリングを提供することなど、他の機能を実行してもよい。
【００５８】
ＣＮ１１５は、他のネットワークとの通信を容易にすることができる。例えば、ＣＮ１１５は、ＣＮ１１５とＰＳＴＮ１０８との間のインタフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでよく、またはそれと通信してもよい。加えて、ＣＮ１１５は、他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよく、他のネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線および／または無線ネットワークを含んでよい。一実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インタフェース、およびＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インタフェースを介して、ＵＰＦ１８４ａ、１８４ｂを通じて、ローカルデータネットワーク（ＤＮ）１８５ａ、１８５ｂに接続されてもよい。
【００５９】
図１Ａ乃至図１Ｄ、および図１Ａ乃至図１ＤＤについての対応する説明に鑑みて、ＷＴＲＵ１０２ａ乃至ｄ、基地局１１４ａ乃至ｂ、ｅＮｏｄｅＢ１６０ａ乃至ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ乃至ｃ、ＡＭＦ１８２ａ乃至ｂ、ＵＰＦ１８４ａ乃至ｂ、ＳＭＦ１８３ａ乃至ｂ、ＤＮ１８５ａ乃至ｂ、および／または本明細書において説明される他の任意のデバイスのうちの１つまたは複数に関する、本明細書において説明される機能の１つもしくは複数または全ては、１つまたは複数のエミュレーションデバイス（図示されず）によって実行されてもよい。エミュレーションデバイスは、本明細書において説明される機能の１つもしくは複数または全てをエミュレートするように構成された、１つまたは複数のデバイスであってもよい。例えば、エミュレーションデバイスは、他のデバイスをテストするために、ならびに／またはネットワークおよび／もしくはＷＴＲＵ機能をシミュレートするために、使用されてもよい。
【００６０】
エミュレーションデバイスは、実験室環境において、および／またはオペレータネットワーク環境において、他のデバイスの１つまたは複数のテストを実施するように設計されてもよい。例えば、１つまたは複数のエミュレーションデバイスは、通信ネットワーク内の他のデバイスをテストするために、有線および／または無線通信ネットワークの一部として、完全または部分的に実施および／または展開されながら、１つもしくは複数または全ての機能を実行してもよい。１つまたは複数のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として、一時的に実施／展開されながら、１つもしくは複数または全ての機能を実行してもよい。エミュレーションデバイスは、テストの目的で、別のデバイスに直接的に結合されてもよく、および／またはオーバザエア無線通信を使用して、テストを実行してもよい。
【００６１】
１つまたは複数のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として実施／展開されずに、全ての機能を含む、１つまたは複数の機能を実行してもよい。例えば、エミュレーションデバイスは、１つまたは複数の構成要素のテストを実施するために、テスト実験室、ならびに／または展開されていない（例えば、テスト）有線および／もしくは無線通信ネットワークにおける、テストシナリオにおいて利用されてもよい。１つまたは複数のエミュレーションデバイスは、テスト機器であってもよい。データを送信および／または受信するために、直接ＲＦ結合、および／または（例えば、１つもしくは複数のアンテナを含んでよい）ＲＦ回路を介した無線通信が、エミュレーションデバイスによって使用されてもよい。
【００６２】
本明細書で説明される特徴および要素は、ＬＴＥ、ＬＴＥ−Ａ、Ｎｅｗ  Ｒａｄｉｏ（ＮＲ）、および／または５Ｇ特有プロトコルを考慮するが、本明細書で説明される特徴および要素は、ＬＴＥ、ＬＴＥ−Ａ、Ｎｅｗ  Ｒａｄｉｏ（ＮＲ）、および／または５Ｇ特有プロトコルに限定されず、他の無線システムに適用可能であってもよいことを理解されるべきである。
【００６３】
無線通信システムでは、中央ノード（例えば、ｇＮｏｄｅＢ）は、１つまたは複数のＷＴＲＵにサービス提供することができる。中央ノードが１つまたは複数のＷＴＲＵにサービス提供するとき、中央ノードにトランスポートブロック（ＴＢ）を送信する機会は、中央ノードによって管理されてもよい。例えば、ｇＮｏｄｅＢ（ｇＮＢ）は、１つもしくは複数のＷＴＲＵ（例えば、各々のＷＴＲＵ）に時間−周波数リソース（例えば、別個の時間−周波数リソース）を割り当て、及び／またはＷＴＲＵに１つもしくは複数のリソース（例えば、各々のリソース）を許可する（ｇｒａｎｔ）ことによって、ＷＴＲＵアップリンク（ＵＬ）送信をスケジュールしてもよい。ＵＬ送信に対するそのような取り決め（ａｒｒａｎｇｅｍｅｎｔ）は、グラントベースＵＬ送信（ｇｒａｎｔ−ｂａｓｅｄ  ＵＬ  ｔｒａｎｓｍｉｓｓｉｏｎ）と称されてもよい。
【００６４】
ｇＮＢは、１つもしくは複数の時間−周波数リソースの存在をブロードキャストしてもよく、１つもしくは複数のＷＴＲＵ（例えば、ＷＴＲＵのセット）がリソース（例えば、各々のリソース）を競合することを可能にすることができ、および／またはＵＬグラント（例えば、特定のＵＬグラント）なしにリソースにアクセスすることを可能にすることができる。ＵＬ送信に対するそのような取り決め（例えば、Ｎｅｗ  Ｒａｄｉｏ（ＮＲ）における）は、グラントフリー（ＧＦ）ＵＬ送信、またはグラントなしＵＬ送信と称されてもよい。ＧＦ  ＵＬ送信の用途は、超高信頼低遅延通信（ＵＲＬＬＣ：ｕｌｔｒａ−ｒｅｌｉａｂｌｅ  ｌｏｗ−ｌａｔｅｎｃｙ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）、大容量マシンタイプ通信（ｍＭＴＣもしくはＭＭＴＣ：ｍａｓｓｉｖｅ  ｍａｃｈｉｎｅ−ｔｙｐｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎ）、および／または高度化モバイルブロードバンド（ｅＭＢＢもしくはＥＭＢＢ：ｅｎｈａｎｃｅｄ  ｍｏｂｉｌｅ  ｂｒｏａｄｂａｎｄ）通信にあってもよい。ＭＭＴＣは、用途（例えば、スマート計量、物流、ならびに／またはフィールドおよびボディセンサ）をサポートすることが意図された多数の低コストおよび電力制約（例えば、バッテリ駆動）デバイスの間の通信を可能にすることができる。ＵＲＬＬＣは、デバイスおよび／またはマシンが非常に低い待ち時間および／または高い可用性により信頼して通信する（例えば、超信頼して）ことを可能にすることができる。デバイスおよび／またはマシンが超信頼性、非常に低い待ち時間、および／または高い可用性により通信することを可能にすることは、ＵＲＬＬＣが、車両通信、産業制御、工場自動化、リモート手術、スマートグリッド、および／または公共安全性の用途を提供することを可能にすることができる。ＥＭＢＢは、モバイルブロードバンドアクセスの１つまたは複数の（例えば、多様な）パラメータ（例えば、データレート、遅延、およびカバレッジ）への拡張をもたらすことができる。
【００６５】
ＧＦ  ＵＬ送信が実行されてもよい。以下のうちの１つまたは複数が適用されてもよい。ｇＮＢは、ＧＦリソースを指定してもよい（例えば、無線リソース制御（ＲＲＣ）シグナリングを介して）。ＧＦリソースは、ＷＴＲＵ特有であってもよく、またはＷＴＲＵ依存であってもよい。ＷＴＲＵは、ＧＦリソースを選択してもよく、および／またはＧＦリソース上でＴＢを送信してもよい。ＷＴＲＵがハイブリッド自動再送要求確認応答（ＨＡＲＱ−ＡＣＫ）（例えば、ＴＢに対する対応するＨＡＲＱ−ＡＣＫ）を受信しない場合（例えば、或る時間期間の後）、ＷＴＲＵは、ＴＢを再送信してもよい（例えば、ＴＢを再送信する計画をしてもよい）。ＷＴＲＵは、別のＧＦリソースおよび／または許可されたリソース（例えば、ｇＮＢがリソースを許可した場合）上でＴＢを再送信してもよい。ＷＴＲＵは、例えば、最大リトライ数に到達するまで、ＧＦリソースを使用して再送信してもよい。
【００６６】
ＧＦ  ＵＬ送信では、連続したリソース（例えば、Ｋ個の連続したＧＦリソース）にわたってＴＢが送信されてもよい（例えば、Ｋ回送信される）。そのような送信は、Ｋ回の繰り返しを伴うＧＦ送信と称されてもよい。ＧＦ  ＵＬ送信（例えば、Ｋ回の繰り返しを伴うＴＢ送信）について、繰り返しは、ＷＴＲＵ特有ＲＲＣシグナリングによって構成することができる冗長バージョン（ＲＶ：ｒｅｄｕｎｄａｎｃｙ−ｖｅｒｓｉｏｎ）シーケンスに続いてもよい（例えば、前の既知のシーケンスになるように）。ＲＶシーケンスは、ＷＴＲＵによって使用される冗長バージョン値のシーケンスを含んでもよい。実施例では、ＲＶシーケンスは、１つまたは複数の繰り返される冗長バージョン（例えば、［０，０，０，０］など、０の冗長バージョンの４回の繰り返し）のシーケンスを含んでもよい。実施例では、ＲＶシーケンスは、第１の冗長バージョン値および第３の冗長バージョン値が０であり、第２の冗長バージョン値および第４の冗長バージョン値が３である（例えば、［０，３，０，３］、１つまたは複数の冗長バージョンのシーケンスを含んでもよい。
【００６７】
例えば、ＧＦ  ＵＬ送信（例えば、各々の）において非効率であることがある。非効率性は、ＧＦ送信の性質に起因することがあり、および／または（例えば、各々の）ＧＦリソースを使用することを試みているＷＴＲＵの数に依存することがある。
【００６８】
ＧＦ動作が使用される用途（例えば、ＵＲＬＬＣまたはｍＭＴＣ）に応じて、ＧＦリソースにアクセスすることを試みているＷＴＲＵの間での衝突の可能性（例えば、低い可能性または高い可能性）が存在することがある。試みているＷＴＲＵの数が多いと、衝突の可能性は高く、および／または全体の効率性は低い。試みているＷＴＲＵの間での衝突の可能性を低くすることができる。
【００６９】
ＷＴＲＵは、アップリンク制御情報（ＵＣＩ）をＴＢ（例えば、ＷＴＲＵがＧＦリソースを使用して送信することを試みるＴＢ）と多重化してもよい。例えば、ＧＦ動作を実行した後のＷＴＲＵの振る舞いは、ｇＮＢがＵＣＩを受信したかどうか（例えば、受信に成功したかどうか）を判定するために使用されてもよい。
【００７０】
１つまたは複数のタイプのＧＦ送信（例えば、ＮＲにおける）が実行されてもよい。ｇＮＢは、以下のうちの１つまたは複数を使用してＧＦリソースを指定してもよい。ｇＮＢは、Ｌ１シグナリングなしの無線リソース制御（ＲＲＣ）構成（例えば、再構成）（例えば、タイプ１）を介してＧＦリソースを指定してもよい。ｇＮＢは、Ｌ１シグナリングによるＲＲＣ構成（例えば、タイプ２）を介してＧＦリソースを指定してもよい。ｇＮＢは、Ｌ１シグナリングによるＲＲＣ構成（例えば、１つまたは複数のＲＲＣ構成パラメータを修正することができる）（例えば、タイプ３）を介してＧＦリソースを指定してもよい。
【００７１】
グラントフリー（ＧＦ）リソースは、１つまたは複数のＷＴＲＵによって選択されてもよい。例えば、１つまたは複数のＧＦリソース（例えば、そのセット）からＧＦリソースを選択しているＷＴＲＵは、ＵＬ  ＧＦ送信を実行してもよい。以下のうちの１つまたは複数が適用されてもよい。ＷＴＲＵは、ＧＦ動作を介して送信された（例えば、前に送信された）ＴＢに対するＨＡＲＱ−ＮＡＣＫを受信してもよい。ＷＴＲＵは、送信されたＴＢ送信に対するＨＡＲＱ−ＡＣＫまたはＨＡＲＱ−ＮＡＣＫを受信しなくてもよい。ＷＴＲＵは、同一のＴＢを送信し（例えば、同一のＴＢを再送信し）、あるいは別のＴＢを送信する（例えば、ＷＴＲＵがＨＡＲＱ−ＮＡＣＫを受信し、またはＷＴＲＵがＨＡＲＱ−ＮＡＣＫもしくはＨＡＲＱ−ＡＣＫを受信しない場合）ことを試みてもよい。ＷＴＲＵは、ＵＬ  ＧＦ送信に対する次のリソースを選択してもよい。ＷＴＲＵは、ｍＭＴＣ用途などにおいて、他のＷＴＲＵも送信することを試みているＧＦリソース上でＵＬ  ＧＦ送信を送信することを試みてもよく、それは、ＷＴＲＵの間での衝突の可能性を増大させることがある。
【００７２】
ＷＴＲＵは、ＧＦリソース（例えば、次の即時に利用可能なＧＦリソース）上で保留ＴＢを再送信してもよい。例えば、ＷＴＲＵは、次の即時に利用可能なＧＦリソース上で保留ＴＢを再送信してもよい（例えば、それを行うことが潜在的な遅延を低下させることができることを理由に）。前のＧＦリソースの間に衝突した２つ以上のＷＴＲＵ（例えば、全てのＷＴＲＵ）（例えば、ＨＡＲＱ−ＮＡＣＫまたはＤＲＸにつながることがある）が、次の（例えば、次の即時の）ＧＦリソース（複数可）上でそれらの保留ＴＢを再送信する場合、別の衝突の可能性が増大することがある。
【００７３】
ＧＦ再送信に対する日和見的なリソース選択が実行されてもよい。ＧＦ再送信に対する日和見的なリソース選択の例が図２に示される。例えば、図２に示されるように、ＷＴＲＵによるＧＦ送信が成功しない場合、ＷＴＲＵは、その保留ＴＢを再送信するために、今度の（ｕｐｃｏｍｉｎｇ）ＧＦリソースを選択してもよい。１つまたは複数の（例えば、２つの）ＷＴＲＵは、図２におけるＧＦリソース１上でそれらの保留ＴＢを送信することを試みてもよい。例えば、衝突に起因して、ｇＮＢは、ＴＢ（例えば、ＴＢのいずれか）の復号に失敗することがある。ｇＮＢは、どのＷＴＲＵがＧＦリソース１を使用したかを識別することが可能でないことがある。ｇＮＢは、ＷＴＲＵにＨＡＲＱフィードバックを送信することが可能でないことがある。ＷＴＲＵは、それを行うことが遅延（例えば、潜在的な遅延）を低下させることを理由に、次の利用可能な（例えば、次の即時に利用可能な）ＧＦリソース（例えば、ＧＦリソース２）上で保留ＴＢを再送信すると判定してもよい。ＷＴＲＵが次の利用可能な（例えば、次の即時に利用可能な）ＧＦリソース上で保留ＴＢを再送信すると判定する場合、衝突の可能性は低いことがある（例えば、可能性がない）。前のＧＦリソース１の間に衝突した２つ以上の（例えば、全ての）ＷＴＲＵが同一のリソース上でそれらの保留ＴＢを再送信する場合、衝突の可能性が増大することがある。
【００７４】
ＷＴＲＵは、１つもしくは複数の後続のＧＦリソース（例えば、１つもしくは複数の直後のＧＦリソース）上で再送信しなくてもよく、および／または日和見的な方式において（例えば、衝突の可能性を低下させるための）保留ＴＢを再送信してもよい。ＷＴＲＵは、例えば、再送信を開始する前に乱数のＧＦリソース（バックオフ値）をスキップすることによって、再送信からバックオフ（ｂａｃｋ  ｏｆｆ）してもよい。例えば、乱数が予め定義された範囲（バックオフ値の範囲）から選択されることがあり、および／または２つ以上のＷＴＲＵが同一の乱数（同一のバックオフ値）を導出する（例えば、引き出す）可能性が最小になるような確率（例えば、非決定論的に）に従って乱数が導出されることがあることを理由に、乱数のＧＦリソースに対するバックオフは、より長い期間にわたって試みているＷＴＲＵを分散させることにつながることがある。例えば、バックオフカウンタ（例えば、バックオフ値）は、予め定義された範囲（例えば、０〜Ｔ1）から一様に導出されてもよい（例えば、引き出される）。Ｔ1が大きくなると（例えば、バックオフ範囲が大きくなると）、例えば、競合するＷＴＲＵの間での衝突（例えば、別の衝突）の可能性が低下することがある。例えば、Ｔ1＝３である場合、２つのＷＴＲＵ（例えば、所与のＧＦリソースの間に送信する前の試みにおいて衝突した２つのＷＴＲＵ）は、或る範囲（例えば、０、１、２、３を含むバックオフ値の範囲）から異なるバックオフ値を導出する（例えば、引き出す）可能性が高くなることがあり（例えば、Ｔ1＝１である場合よりも高い）、および／または別個のＧＦリソース上で送信する可能性が高くなることがある。２つのＷＴＲＵは、或る範囲（例えば、０、１、２、３を含むバックオフ値の範囲）から同一の数（例えば、バックオフ値）を導出する（例えば、引き出す）ことがある。導出された（例えば、引き出された）数が同一である場合（例えば、バックオフ値が同一である）、２つのＷＴＲＵは、同一のＧＦリソース上で送信（例えば、再送信）することがあり、それは、（例えば、別の）衝突につながることがある。送信（例えば、再送信）が失敗する場合（例えば、失敗もする）、送信に対する次のＧＦリソースが選択されることがある（例えば、再度選択される）。送信に対する次のＧＦリソースは、前の範囲よりも広い（例えば、大きい）ことができる（例えば、Ｔ2が２×Ｔ1＋１であってもよい）範囲（例えば、０〜Ｔ2）からランダムに選択されてもよい。例えば、Ｔ1＝３である場合、Ｔ2＝７であり、前のＧＦ  ＵＬ送信において衝突した２つ以上のＷＴＲＵのうちのＷＴＲＵ（例えば、各々のＷＴＲＵ）は、或る範囲（例えば、０、１、２、３、４、５、６、７を含むバックオフ値の範囲）から一様分布によりランダムにバックオフ値を導出（例えば、引き出す）することがある。バックオフ値の範囲が増大することがある。バックオフ値の範囲が増大すると、競合しているＷＴＲＵによって異なるバックオフカウンタが導出される（例えば、引き出される）確率、および／または送信を送信するために（例えば、次に送信を送信する）競合しているＷＴＲＵによって別個のＧＦリソースが使用される確率が増大することがある。本明細書で説明されるように、バックオフ範囲は、コンテンションウインドウサイズ（ＣＷＳ）と称されてもよい。
【００７５】
ＷＴＲＵは、例えば、バックオフ値の範囲（例えば、Ｔ0〜Ｔi）からバックオフ値（例えば、ｔにより表される）を導出し（例えば、引き出し）、リソースをスキップし（例えば、次のｔ−１のＧＦリソースをスキップする）、および／またはリソース（例えば、ｔ番目のＧＦリソース）上で送信／再送信することによって、ＧＦ送信または再送信を開始してもよい。Ｔ0は０に等しくてもよく（例えば、第１の送信はゼロのバックオフカウンタを有してもよく）、Ｔ1は３に等しくてもよく、Ｔiは２×Ｔi-1＋１に等しくてもよい（例えば、Ｔ2＝７、Ｔ3＝１５などにつながる、などである）。例えば、第１の送信のために、Ｔ0に対して非ゼロのバックオフカウンタが使用されてもよい（例えば、Ｔ0＝３、Ｔ1＝７、Ｔ2＝１５などにつながることがあるＴ0＝３、およびＴi＝２×Ｔi-1＋１）。例は、バックオフ値範囲を２倍にすることができる（例えば、衝突の後）係数を含んでもよい。例えば、Ｔi＝３×（Ｔi-1＋１）−１）となるように、異なる係数（例えば、バックオフ値範囲を３倍にすることができる３）により増大が実行されてもよい。バックオフ値範囲は、２つ以上の競合しているＷＴＲＵの間での別の衝突の可能性を低下させるよう増大してもよい。Ｔi値のシーケンスは、ＷＴＲＵ（例えば、いくつかもしくは全てのＷＴＲＵ）に対して予め定義されてもよく、またはＲＲＣシグナリングを介して通信されてもよい、などである。ＷＴＲＵ（例えば、各々のＷＴＲＵ）は、第１の時間の間に送信しているかどうか、第１の時間の間に再送信しているかどうか、第２の時間の間に再送信しているかどうか、などに従ってＴi値を選択してもよい（例えば、ランダムに選択してもよい）（例えば、バックオフ範囲が第１の送信、第１の再送信、第２の再送信などに対して異なることができるように）。Ｔi値のシーケンスは、ＷＴＲＵ特有ＲＲＣシグナリングを介して各々のＷＴＲＵに提供されてもよく、１つのＷＴＲＵのシーケンスは、例えば、各々のＷＴＲＵに与えられた優先度に応じて別のＷＴＲＵとは異なってもよい（例えば、低待ち時間用途で稼働しているＷＴＲＵは、ＭＭＴＣ用途で稼働しているＷＴＲＵよりも優先付けられてもよい）。
【００７６】
Ｔ0、Ｔ1、Ｔ2などの値、および／または値が導出される（例えば、引き出される）確率は、予め定義されてもよく（例えば、仕様において予め定義される）、および／またはシグナリングされてもよい（例えば、ＲＲＣによってシグナリングされる）。ｇＮＢは、例えば、配置および／または用途に従って、パラメータ（例えば、Ｔ0、Ｔ1、Ｔ2などの値、および／または値が導出される確率を示すパラメータ）をカスタマイズしてもよい。
【００７７】
ＷＴＲＵ（例えば、各々のＷＴＲＵ）は、ＷＴＲＵ（例えば、各々のＷＴＲＵ）に対して一意であることができる送信に対して利用可能なグラントフリーリソースのランダムなサブセットを演繹的に（ｐｒｉｏｒｉ）選択してもよい（例えば、または許可されてもよい）。グラントフリーリソースは、ＷＴＲＵによって送信に対して選択されてもよい。ＷＴＲＵは、ｇＮＢから一意なグラントおよび／または明確なグラントを受信することなく、グラントフリーリソースを選択してもよい。例えば、ｇＮＢがＷＴＲＵ（例えば、全てのグラントフリーＷＴＲＵ）にリソースのセットを割り当てるのではなく、ＷＴＲＵ（例えば、各々のＷＴＲＵ）は、送信に対して利用可能なグラントフリーリソースのランダムなサブセットを演繹的に選択してもよい（例えば、または許可されてもよい）。グラントフリーリソースのサブセットは、ＷＴＲＵ（例えば、各々のＷＴＲＵ）に対して一意であってもよい。初期の送信が失敗すると、ＷＴＲＵは、リソース（例えば、グラントフリーリソースのサブセットからの次の一意に利用可能なグラントフリーリソース）上で再送信を送信してもよい。ＷＴＲＵ特有グラントフリーリソース（例えば、ＷＴＲＵに対して一意なグラントフリーリソースのサブセット）のランダム化は、送信しているＷＴＲＵの後続の送信の間で衝突が発生する確率を減少させることができる。
【００７８】
ＧＦ送信が成功または失敗するかどうかが判定されてもよい。ＷＴＲＵがｇＮＢ（例えば、ＷＴＲＵのｇＮＢ）にＴＢを送信するとき、ＷＴＲＵは、例えば、送信の後（例えば、送信に応答して）ＨＡＲＱ−ＡＣＫまたはＨＡＲＱ−ＮＡＣＫを受信してもよい。ＵＬ送信と対応するＨＡＲＱフィードバック（例えば、ｇＮＢによってＷＴＲＵに送信されることが予測される）との間のタイミングは、ＤＣＩにおける１つもしくは複数のフィールドから取得することができ、またはＲＲＣパラメータによって構成することができるパラメータによって表されてもよい。
【００７９】
ＧＦ  ＵＬ送信では、ＷＴＲＵａは、ＨＡＲＱ−ＡＣＫまたはＨＡＲＱ−ＮＡＣＫを受信または検出しないことがある（ＷＴＲＵが同一のＧＦリソース上で送信することによる２つ以上の送信の衝突に起因して）。特定の期間の後（例えば、確認応答時間）、ＷＴＲＵは、前に送信されたＴＢがｇＮＢによって受信されなかったと判定してもよく、および／またはＧＦリソース（例えば、次の利用可能なＧＦリソース）を使用して、ＴＢを送信することを試みてもよい。ＧＦ  ＵＬ送信について、ＧＦ  ＵＬ送信と予測されたＨＡＲＱフィードバックとの間のタイミングは、ＤＣＩにおける１つもしくは複数のフィールドにおいて搬送することができ、またはＲＲＣによって指定することができるパラメータ（例えば、確認応答時間）によって表されてもよい。
【００８０】
１つまたは複数のＷＴＲＵは、１つまたは複数の（例えば、数個の）連続したスロットにおけるＧＦリソース（例えば、利用可能なＧＦリソース）を使用することを試みてもよい。ＷＴＲＵ（例えば、全てのＷＴＲＵ）が前のＧＦ送信が失敗したと判定する前の同一の時間期間を待機する場合、ＷＴＲＵ（例えば、全てのＷＴＲＵ）は、例えば、再送信を実行するために、送信に対する同一のＧＦリソース（例えば、次の即時に利用可能なＧＦリソース）をターゲットとしてもよい。ＷＴＲＵ（例えば、全てのＷＴＲＵ）が前のＧＦ送信が失敗したかどうかを判定する固定期間は、送信のために使用される次のＧＦリソースに対する衝突の可能性を高めることがある。ＷＴＲＵは、別のＷＴＲＵとは異なる対応する期間（例えば、待ち時間）を使用してもよい。そのような可変の待ち時間は、例えば、２つ以上の（例えば、数個の）ＧＦリソースの範囲にわたって、および／または２つ以上の（例えば、数個の）スロットにわたって、ＷＴＲＵによる再送信の試みを分散させることができる。ＧＦ  ＵＬ送信では、ＧＦ  ＵＬ送信と対応するＨＡＲＱフィードバックが受信されることになる（例えば、受信されると予測される）時間（例えば、最大時間）との間のタイミングは、パラメータ（例えば、ＤＣＩにおける１つもしくは複数のフィールドにおいて搬送することができ、および／またはＷＴＲＵ特有ＲＲＣによって指定することができる）によって表されてもよい。そのような時間間隔は、ＷＴＲＵおよび別のＷＴＲＵとは異なってもよい。ｇＮＢは、時間間隔を定義してもよい。例えば、ｇＮＢは、１つまたは複数のＷＴＲＵ（例えば、各々のＷＴＲＵ）に時間期間を割り当ててもよい。これは、ｇＮＢにより指示された方法（ｇＮＢ  ｄｉｒｅｃｔｅｄ  ｍｅｔｈｏｄ）であってもよい。ｇＮＢは、時間の範囲を指定してもよく、その時間の範囲から、ＷＴＲＵは、値を選択することができ（例えば、ランダムに選択することができる）、および／またはＧＦ  ＵＬ送信と対応するＨＡＲＱフィードバックが受信されることになる（例えば、受信されると予測される）最大時間との間のタイミングになる値を選択することができる。時間の範囲を指定し、および／または値を選択しているｇＮＢは、ＷＴＲＵの自律的なもの（ＷＴＲＵ  ａｕｔｏｎｏｍｏｕｓ（例えば、よりＷＴＲＵの自律的なもの）であってもよい。ＷＴＲＵは、ｇＮＢに値のフィードバックを提供してもよい（例えば、値のフィードバックを提供する必要があることがある）。ｇＮＢに値をフィードバックすることは、例えば、ｇＮＢがＷＴＲＵを識別することが可能であるときのグラントフリーブラインド復号（ｂｌｉｎｄ  ｄｅｃｏｄｉｎｇ）の量を削減することができ、ペイロードを復号しなくてもよい。
【００８１】
時間間隔の範囲は、パラメータ（例えば、トラフィッククラス）によって判定されてもよい。例えば、低待ち時間トラフィックは、より小さい範囲を有してもよく、および／または待ち時間許容可能トラフィック（ｌａｔｅｎｃｙ  ｔｏｌｅｒａｎｔ  ｔｒａｆｆｉｃ）は、より大きな範囲を有してもよい。ＷＴＲＵは、ＷＴＲＵの用途タイプに基づいて判定することができる範囲（例えば、単一の範囲）を有してもよい。（例えば、ＵＲＬＬＣ用途タイプについての範囲＜ｅＭＢＢ用途タイプについての範囲＜ｍＭＴＣ用途タイプについての範囲）。ＷＴＲＵは、送信されることになるトラフィックのタイプに基づいて選択することができる２つ以上の範囲（例えば、複数の）を有してもよい。
【００８２】
例えば、衝突を減少させるために、１つまたは複数のＧＦリソースが検知されてもよい。ＧＦ  ＵＬ送信では、１つまたは複数のＷＴＲＵは、同一のＧＦリソース上でそれらの保留ＴＢを送信することを試みてもよい。例えば、１つまたは複数のＷＴＲＵは、ＧＦ  ＵＬ送信を実行するように構成された１つまたは複数のＷＴＲＵ（例えば、いずれかのＷＴＲＵ）によってＧＦリソースが競合の対象となっている（ｕｐ  ｆｏｒ  ｇｒａｂｓ）ことがあることを理由に、同一のＧＦリソース上でそれらの保留ＴＢを送信することを試みてもよい。同一のＧＦリソースを使用する複数のＷＴＲＵによる試みによって、例えば、ＷＴＲＵの間で衝突が発生することがあり（例えば、送信に失敗する）、それは、ＷＴＲＵのＴＢが復号されないことにつながることがある（例えば、復号に失敗する）。ＷＴＲＵは、例えば、同一のＧＦリソースの間にそれらの保留ＴＢを送信することを試みる前に、例えば、別のＷＴＲＵがリソースを使用しているかどうかを発見するようリソース（例えば、ＧＦリソース）を検知することによって、そのような衝突を回避することができる。
【００８３】
１つまたは複数の時間領域ＧＦリソースが検知されてもよい。ＧＦリソースを使用することを試みるＷＴＲＵ（例えば、各々のＷＴＲＵ）は、リソース検知を実行する、例えば、リソースの可用性を発見するようリソースの先頭部分（ｂｅｇｉｎｎｉｎｇ  ｐｏｒｔｉｏｎ）を選択してもよい。リソースの使用が検出されない場合（例えば、他のＷＴＲＵがリソースを使用していないとＷＴＲＵが判定する場合）、ＷＴＲＵは、ＧＦリソースの残りの部分上でその保留ＴＢを送信すると決定してもよい（例えば、処理の後）。媒体を検知することは、例えば、その部分を検知している間にエネルギー検出（ＥＤ）を実行することを含んでもよい。図３は、試みているＷＴＲＵがＧＦリソースの第１のシンボル（例えば、ＧＦリソースの最初の３つのシンボル）を検知する例を示す。そのような振る舞いから利点を得るために、試みているＷＴＲＵ（例えば、各々の試みているＷＴＲＵ）は、別の試みているＷＴＲＵの検知間隔とは異なってもよい検知間隔を選択してもよい。例えば、ＷＴＲＵは、ＷＴＲＵの最初の数個のＯＦＤＭシンボルの間（例えば、図３にあるような最初の３つのシンボル）、および／またはグラントフリーリソースの帯域幅の全体を通じて、グラントフリーリソースの可用性を検知すると判定してもよい。他のＷＴＲＵがリソースを使用していないと検知される場合（例えば、エネルギー検出を使用して）、ＷＴＲＵは、例えば、処理の後に、ＧＦリソースの残りの部分上でＷＴＲＵの保留ＴＢを送信すると判定してもよい。
【００８４】
ＷＴＲＵ（例えば、各々のＷＴＲＵ）は、例えば、演繹的に既知な確率分布を使用して導出する（例えば、引き出す）ことができるシンボルの数（例えば、乱数）を選択してもよい。例えば、ＷＴＲＵ（例えば、全ての試みているＷＴＲＵ）は、範囲（例えば、０、１、２、３、４）から一様に数（例えば、乱数）を導出（例えば、引き出す）してもよく、ならびに／または導出された数のシンボルの間、および／もしくはＧＦリソースの帯域幅の全体を通じて、リソース検知を実行してもよい。図４は、３つのＷＴＲＵがグラントフリーリソースを使用することを試み、ＷＴＲＵ（例えば、各々のＷＴＲＵ）が演繹的に既知な範囲（例えば、０、１、２、３、４）から値（例えば、単一の値）を一様に導出（例えば、引き出す）する例を示す。図４を参照して、以下のうちの１つまたは複数が適用されてもよい。ＷＴＲＵ１に対する検知間隔は、４個のシンボルであってもよく、ＷＴＲＵ２に対する検知間隔は、３個のシンボルであってもよく、および／またはＷＴＲＵ３に対する検知間隔は、１個のシンボルであってもよい。３つのＷＴＲＵは、演繹的に既知な範囲（例えば、０、１、２、３、４）から数ｎを疑似的にランダムに（例えば、分布に従って）導出（例えば、引き出す）してもよく、ならびに／または最初のｎ個のシンボルの間、およびグラントフリーリソースの帯域幅の全体を通じてリソースの可用性を検知してもよい。ＷＴＲＵ１は、ＧＦリソースの最初の４個のＯＦＤＭシンボルの間に媒体を検知してもよい。ＷＴＲＵ２は、ＧＦリソースの最初の３個のＯＦＤＭシンボルの間に媒体を検知してもよい。ＷＴＲＵ３は、ＧＦリソースの１個のＯＦＤＭシンボルの間に媒体を検知してもよい。ＷＴＲＵ３は、媒体が利用可能であることを発見する最初のＷＴＲＵであってもよく、および／またはＷＴＲＵの保留ＴＢを、例えば、ＧＦリソースの残りの部分上で送信することを試みてもよい（例えば、処理の後）。ＷＴＲＵ１およびＷＴＲＵ２は（例えば、予測される期間の間に媒体を検知した後）、ＧＦリソースが使用中であると判定してもよく、および／またはＧＦリソースを使用することを控えてもよい。２つ以上のＷＴＲＵは、同一の数を導出（例えば、引き出す）してもよく、および／または同一の期間の間にリソースを検知してもよく、それは、ＷＴＲＵの間の衝突につながることがある。そのような結果についての可能性は、リソース検知範囲が増大するにつれて減少する。
【００８５】
２つ以上のＷＴＲＵは、ＧＦリソース（例えば、同一のＧＦリソース）を使用することを試みてもよい。ＷＴＲＵ３は、ＧＦリソースを使用することを試みなくてもよい（例えば、リソース検知を実行しなくてもよい）。ＷＴＲＵ２およびＷＴＲＵ１は、媒体を検知してもよい。例えば、ＷＴＲＵ２は、媒体が利用可能であると判定する最初のＷＴＲＵであってもよく、および／またはリソースの残りの部分においてＷＴＲＵの保留ＴＢを送信してもよい（送信することを試みる）（例えば、処理の後）。ＷＴＲＵ１は（例えば、期間（例えば、予測された期間）の間に媒体を検知した後）、ＧＦリソースが使用中であると判定してもよく、および／またはＧＦリソースを使用することを控えてもよい。ＷＴＲＵ３もＷＴＲＵ２もＧＦリソースを使用することを試みていない場合（例えば、リソース検知を実行しない）、ＷＴＲＵ１は（例えば、その検知期間が満了した後）、ＧＦリソースが使用中でないと判定してもよく、および／またはその保留ＴＢを送信してもよい。
【００８６】
ＷＴＲＵ（例えば、各々のＷＴＲＵ）によって実行された検知（例えば、エネルギー検出）および／または実行された検知の精度に応じて、ＷＴＲＵは、ＧＦリソースが使用中であると早く判定してもよく（例えば、その検知間隔の終了よりも早く）、および／またはリソースを検知することを停止してもよい。例えば、ＷＴＲＵによって実行された検知および／または検知の精度に応じて、ＷＴＲＵは、媒体が使用中であることを検知することを失敗することがあり、および／またはリソースを使用することを試みることがあり、それは、衝突を生じさせることがある。
【００８７】
１つまたは複数の周波数領域ＧＦリソースが検知されてもよい。ＷＴＲＵは、同一の数のＯＦＤＭシンボル（例えば、１個のＯＦＤＭシンボルおよび／もしくは演繹的に既知な数個のＯＦＤＭシンボル）の間、ならびに／または可変数のリソースブロック（ＲＢ）の間にリソース検知を実行してもよい（例えば、一貫して実行してもよい）。図５は、３つのＷＴＲＵが所与のグラントフリーリソースを使用することを試み、および／またはＷＴＲＵ（例えば、各々のＷＴＲＵ）が演繹的に既知な範囲から値（例えば、単一の値）を導出（例えば、引き出す）する例を示す。図５に例示されるように、ＷＴＲＵ１、ＷＴＲＵ２、およびＷＴＲＵ３は、同一の数のＯＦＤＭシンボルであるが、異なる数のＲＢに対してリソース検知を実行してもよい。図５を参照して、以下のうちの１つまたは複数が適用されてもよい。ＷＴＲＵ１に対する検知間隔は、９個のＲＢであってもよい（例えば、ＧＦ送信の前の）。ＷＴＲＵ２に対する検知間隔は、７個のＲＢであってもよい（例えば、ＧＦ送信の前の）。ＷＴＲＵ３に対する検知間隔は、４個のＲＢであってもよい（例えば、ＧＦ送信の前の）。３つのＷＴＲＵは、演繹的に既知な範囲から数ｎを疑似的にランダムに導出（例えば、引き出す）してもよく（例えば、分布ごとに）、および／または第１のＯＦＤＭシンボルの最上のｎ個のＲＢ（もしくは、例えば、演繹的に既知な最初の数個のＯＦＤＭシンボル）の間にリソースの可用性を検知してもよい。ＷＴＲＵ１は、ＧＦリソースの最上の９個のＲＢの間に媒体を検知してもよい。ＷＴＲＵ２は、ＧＦリソースの最上の７個のＲＢの間に媒体を検知してもよい。ＷＴＲＵ３は、ＧＦリソースの最上の４個のＲＢの間に媒体を検知してもよい。ＷＴＲＵ３は、媒体が利用可能であることを発見する最初のＷＴＲＵであってもよく、および／または、例えば、処理の後、リソースの残りの部分上でＷＴＲＵの保留ＴＢを送信することを試みてもよい。ＷＴＲＵ１およびＷＴＲＵ２は（例えば、それぞれの予測された期間の間に媒体を検知した後）、ＧＦリソースが使用中であると判定してもよく、および／またはＧＦリソースを使用することを控えてもよい。ＷＴＲＵ（例えば、各々のＷＴＲＵ）がＷＴＲＵの検知期間を導出（例えば、引き出す）する範囲は、演繹的に既知であってもよい（例えば、ＲＲＣまたはＤＣＩによってパラメータを介して通信される）。範囲は、ＧＦリソースの帯域幅の関数としてＷＴＲＵ（例えば、各々のＷＴＲＵ）によって取得されてもよい（例えば、暗黙的に取得されてもよい）。例えば、範囲は、ＧＦリソースと関連付けられたＲＢの数によって表されるＧＦリソースの帯域幅であってもよい。図５は、範囲が（０、１、２、３、４、５、６、７、８、９、１１）を含む例を示す。範囲は、１１個のＲＢであるＧＦリソースの帯域幅から暗黙的に取得されてもよい。
【００８８】
２つ以上のＷＴＲＵは、ＧＦリソース（例えば、同一のＧＦリソース）を使用することを試みてもよい。ＷＴＲＵ３は、ＧＦリソースを使用することを試みなくてもよい（例えば、リソース検知を実行しなくてもよい）。ＷＴＲＵ２およびＷＴＲＵ１は、媒体を検知してもよい。例えば、ＷＴＲＵ２は、媒体が利用可能であると判定する最初のＷＴＲＵであってもよく、および／またはリソースの残りの部分においてＷＴＲＵの保留ＴＢを送信してもよい（送信することを試みてもよい）（例えば、処理の後）。ＷＴＲＵ１は（例えば、或る期間（例えば、予測された期間）の間に媒体を検知した後）、ＧＦリソースが使用中であると判定してもよく、および／またはＧＦリソースを使用することを控えてもよい。ＷＴＲＵ３もＷＴＲＵ２もＧＦリソースを使用することを試みない場合（例えば、リソース検知を実行しない）、ＷＴＲＵ１は（例えば、その検知期間の満了後）、ＧＦリソースが使用中でないと判定してもよく、および／またはその保留ＴＢを送信してもよい。
【００８９】
二次元時間−周波数ＧＦリソースが検知されてもよい。ＷＴＲＵは、ＧＦリソースの可変数の（例えば、演繹的に既知な時間間隔から擬似的にランダムに導出された）ＯＦＤＭシンボル（例えば、第１のＯＦＤＭシンボル）および／または可変数の（演繹的に既知なＲＢ間隔から擬似的にランダムに導出された）最上のリソースブロックに対してリソース検知を実行してもよい。例えば、時間間隔は、（０、１、２）であってもよく、および／またはＲＢ間隔は、（０、１、２、３、４）であってもよい。ＷＴＲＵは、或る時間間隔から擬似的にランダムな数を導出（例えば、引き出す）してもよく、時間間隔は、検知間隔の時間期間であってもよい。ＷＴＲＵは、ＲＢ間隔から擬似的にランダムに数を導出（例えば、引き出す）してもよく、ＲＢ間隔は、検知間隔の周波数帯域幅であってもよい。検知間隔の間にリソースが使用中であるとＷＴＲＵが判定する場合（例えば、エネルギー検出を使用して）、ＷＴＲＵは、例えば、処理の後にＧＦリソースの残りの部分においてＷＴＲＵの保留ＴＢを送信してもよい。リソース検知領域なセットは、１つもしくは複数のＷＴＲＵ（複数可）（例えば、全てのＷＴＲＵ）によって演繹的に既知であってもよく、および／またはＷＴＲＵは、リソース検知を実行する領域を擬似的にランダムに選択してもよい。リソース検知領域は、（ｔ，ｆ）など、矩形な時間および周波数間隔を含んでもよく、ｔは、ＯＦＤＭシンボルの単位にあってもよく、および／またはｆは、ＲＢの単位にあってもよい。
【００９０】
図３におけるリソース検知領域は、以下のうちの１つまたは複数を含んでもよい。ｔは、演繹的な分布からＷＴＲＵによって擬似的にランダムに導出されてもよい（例えば、引き出される）。ｔは、２つ以上のＷＴＲＵに対して異なってもよい。例えば、ＧＦリソースを使用することを試みているＷＴＲＵは、別のＷＴＲＵとは異なってもよいｔを有してもよい。ｆは、ＧＦリソースを使用することを試みている１つまたは複数の（例えば、全ての）ＷＴＲＵに対して固定されてもよい（例えば、ｆは、ＧＦリソースの帯域幅、例えば、ＧＦリソースの全てのＲＢに等しくてもよい）。
【００９１】
図４におけるリソース検知領域は、以下のうちの１つまたは複数を含んでもよい。ｆは、演繹的な分布からＷＴＲＵによって擬似的にランダムに導出されてもよく（例えば、引き出される）、および／またはｆは、１つもしくは複数のＲＢであってもよい。ｆは、２つ以上のＷＴＲＵに対して異なってもよい。例えば、ＧＦリソースを使用することを試みているＷＴＲＵは、別のＷＴＲＵにおけるｆとは異なってもよいｆを有してもよい。ｔは、ＧＦリソースを使用することを試みているＷＴＲＵ（例えば、全てのＷＴＲＵ）に対して固定されてもよい（例えば、ｔは、１つまたは複数のＯＦＤＭシンボルに等しくてもよい）。
【００９２】
検知領域は、例えば、２Ｄ時間−周波数領域であってもよく、ＷＴＲＵに対する検知領域は、時間および／または周波数領域において別のＷＴＲＵとは異なってもよい。検知領域のセットは、１つまたは複数のＷＴＲＵ（複数可）によって演繹的に既知であってもよい（例えば、１つまたは複数の（例えば、全ての）検知領域に対する（例えば、（ｔi，ｆi）全てのＷＴＲＵは、ｇＮＢによって演繹的に識別され、および／または１つもしくは複数の（例えば、全ての）ＷＴＲＵ）に既知である）。ＷＴＲＵは、セットから検知領域を選択してもよい。検知領域のセットは、設計されてもよく、および／または入れ子にされてもよい（ｎｅｓｔｅｄ）。最小検知領域は、１つまたは複数の検知領域のサブセット（例えば、全ての他の検知領域）であってもよい。２番目に最小の最小検知領域は、１つまたは複数の他の検知領域のサブセット（例えば、最小検知領域に加えた全ての他の検知領域）であってもよい、などである。検知領域の構造（例えば、入れ子構造）は、リソースが使用中であるかどうかの判定を可能にすることができる（例えば、明白な推定）。ビットマップのフォーマットにある検知領域を搬送する固定されたペイロードサイズは、ＧＦリソース内の検知領域を示すために使用されてもよい。二次元ビットマップは、ＧＦリソース内の１つまたは複数の周波数−時間領域／区画を示すことができる。
【００９３】
リソース検知は、例えば、演繹的に既知な分布から擬似的にランダムに導出（例えば、引き出す）することができる、検知間隔に従って、時間領域および／またはＲＢ領域において実行されてもよい。１つまたは複数のＷＴＲＵは、最小検知間隔を使用するよう優先付けられてもい（例えば、リソース検知を実行しない）。例えば、低待ち時間用途に対して構成されたＷＴＲＵは、検知を実行しない（例えば、ＷＴＲＵの検知間隔がゼロである）ようにＲＲＣによって構成されてもよく、および／またはＷＴＲＵは、検知することなくＧＦリソースを使用することを試みてもよい。ＷＴＲＵ（例えば、ｍＭＴＣなど、待ち時間許容可能用途を実行するＷＴＲＵ）は、リソース検知を実行するように構成されてもよい。特定の用途（例えば、低待ち時間用途）を伴うＷＴＲＵは、例えば、他のＷＴＲＵと比較して、高い優先度を取得してもよい。ＷＴＲＵが数を導出する（例えば、引き出す）（例えば、擬似的にランダムに数を導出する）演繹的な範囲は、例えば、高優先度のＷＴＲＵを優先付けるよう、非ゼロの数から開始してもよい。優先付けは、１つまたは複数の基準に基づいて実行されてもよい。実施例では、優先付けは、ＷＴＲＵによって実行される用途（例えば、低待ち時間用途ｍＭＴＣ用途）に基づいてもよい。
【００９４】
リソース検知について、ＷＴＲＵがＴＢの送信のために使用するＧＦリソースからのリソース要素（ＲＥ）の数は、可変であってもよく、および／または事前に知られなくてもよい（例えば、検知間隔に起因して）。検知間隔は、擬似的にランダムに導出された数であってもよい。以下のうちの１つまたは複数が適用されてもよい（例えば、知識の欠如に対処することができる）。
【００９５】
ＷＴＲＵは、例えば、リソース検知がされなかったようにＴＢを作成してもよい。ＧＦリソースが使用中でないとＷＴＲＵが判定する場合（例えば、リソース検知を実行した後）、ＷＴＲＵは、作成されたＴＢをレートマッチングしてもよく、および／またはレートマッチングされたＴＢを送信してもよい。
【００９６】
検知間隔の結果が数個のシンボルである場合（例えば、数個の媒体検知間隔につながる検知間隔）、ＷＴＲＵは、様々なレートマッチング推定（ｒａｔｅ−ｍａｔｃｈｉｎｇ  ａｓｓｕｍｐｔｉｏｎ）により保留ＴＢを作成してもよい。ＴＢの様々なレートマッチング推定は、結果に基づいてもよい。例えば、送信範囲は、（０、２、４）であってもよく、ＷＴＲＵは、０、２、または４を擬似的にランダムに導出（例えば、引き出す）してもよい。ＧＦリソースを使用する前に、ＷＴＲＵは、例えば、起こり得る検知間隔結果に対してＷＴＲＵの保留ＴＢをレートマッチングしてもよい。以下のうちの１つまたは複数が適用されてもよい。ＷＴＲＵは、検知がされなかったようにレートマッチングされたＴＢを作成してもよい（例えば、検知間隔に対して導出された０の結果に対応する）。ＷＴＲＵは、検知間隔が２であるように残りのＲＥによりレートマッチングされたＴＢを作成してもよい。ＷＴＲＵは、検知間隔が４であるように残りのＲＥによりレートマッチングされたＴＢを作成してもよい。ＷＴＲＵがＧＦリソースに達し、および／または範囲（０、２、４）から擬似的にランダムに導出（例えば、引き出す）するとき、ＷＴＲＵは、準備された結果（ｏｕｔｃｏｍｅ  ｒｅａｄｙ）に対してレートマッチングされたＴＢを有してもよい。
【００９７】
例えば、ｇＮＢが、ＧＦリソースのどの部分が使用されていない（例えば、どの部分がリソース検知のためにＷＴＲＵによって使用されていない）ことを知らないことがあることを理由に、ｇＮＢは、レートマッチング値を判定してもよい（例えば、一意に判定する）。ｇＮＢは、リソース検知領域のサイズ（例えば、ＧＦリソースの全帯域幅に対するＯＦＤＭシンボルの数、ＯＦＤＭシンボルの数（例えば、固定数）に対するＲＢの数、ならびに／またはＯＦＤＭシンボルの数およびＲＢの数）を取得してもよい（例えば、暗示的に取得し、または判定する）。ｇＮＢは、ＷＴＲＵのＴＢの送信のために使用されたリソースの部分を取得してもよく（例えば、後続で取得し、もしくは判定する）、および／または関連するレートマッチング比率を取得してもよい（例えば、後続で取得し、もしくは判定する）。
【００９８】
ＷＴＲＵは、ＲＲＣシグナリングによってオフセット値のうちの１つまたは複数により構成されてもよく、（例えば、各々の）オフセット値は、対応する検知範囲に対してＲＥの量を計算するためにＷＴＲＵによって使用されてもよい。ＷＴＲＵは、例えば、オフセット値を判定するために、ＵＬ波形（例えば、ＯＦＤＭ対ＤＦＴ−ｓ−ＯＦＤＭ）およびに／または異なるＵＣＩ多重化機構を考慮してもよい。
【００９９】
ＷＴＲＵは、例えば、スロットの最初の数個のシンボル、例えば、最初のＯＦＤＭシンボルまたは最初の２つのＯＦＤＭシンボルに対してリソース検知を実行するように構成されてもよい。ＷＴＲＵがスロットの最初の数個のシンボルに対してリソース検知を実行するように構成される場合、ＷＴＲＵは、ＵＬ  ＧＦ送信に対して利用可能なスロット内の最初のＯＦＤＭシンボル（例えば、ＷＴＲＵによるＧＦリソース−ＰＵＳＣＨの残りの部分）を判定してもよい（例えば、暗黙的に判定する）。例えば、ＷＴＲＵが最初のＭ個のＯＦＤＭシンボルの間にリソース検知を実行している場合、ＷＴＲＵは、ＧＦ  ＰＵＳＣＨが次のＫ個のシンボル（Ｍ＋１，Ｍ＋２，…，Ｍ＋Ｋ）のＯＦＤＭシンボルにおいて送信されてもよいと判定してもよい。ｋは、例えば、ＷＴＲＵの能力、例えば、高い能力Ｋ＝１（例えば、ＷＴＲＵが、リソース検知を実行した後にかなり次のＯＦＤＭシンボルにおいてＵＬ  ＧＦ  ＰＵＳＣＨを送信することができることを示すことができる）を有するＷＴＲＵに対するＷＴＲＵの能力に依存することがある、ＯＦＤＭシンボル（複数可）の数に関するパラメータであってもよい。ＷＴＲＵは、スロットの残りのシンボルに対してスロットフォーマットインジケータ（ＳＦＩ）において示されたスロットフォーマット構成に従ってもよい。
【０１００】
ＵＣＩ多重化は、ＧＦ送信の間に実行されてもよい。ＷＴＲＵは、グラントベースリソースを利用してもよく、ならびに／または、例えば、チャネル状態情報（ＣＳＩ）、チャネル品質インジケータ（ＣＱＩ）、ランクインジケータ（ＲＩ）、および／もしくはＴＢに従ったＨＡＲＱ  ＡＣＫ／ＮＡＣＫ情報を含む、ＵＣＩを多重化してもよい。ＷＴＲＵの振る舞いは、例えば、ＷＴＲＵがＰＵＳＣＨ上でＵＣＩ情報を多重化することを試みているとき、ＧＦ送信の間に変更してもよい。
【０１０１】
適応的符号化レート（ａｄａｐｔｉｖｅ  ｃｏｄｉｎｇ  ｒａｔｅ）がＵＣＩ多重化のために実行されてもよい。ＵＣＩ多重化の間にＷＴＲＵによって実行される処理（例えば、ＷＴＲＵによって実行されることが必要とされる）は、ＵＬ送信がグラントベースまたはグラントフリーであるかどうかの不可知論的（ａｇｎｏｓｔｉｃ）であってもよい。ＵＣＩ多重化のために使用される処理は、ＧＦ  ＵＬ送信の間に使用されてもよい。ＧＦ送信について、ＧＦリソースは、干渉および／または衝突の影響を受けることがある。ＧＦ  ＵＬ送信の間のより高い干渉に対処するために、例えば、多重化されたＵＣＩをより低いレート符号化により符号化することができるように、冗長バージョン（ＲＶ）が調節されてもよく、および／またはＴＢがレートマッチングされてもよい。Ｋ回の繰り返しを伴うＧＦ  ＵＬ送信（例えば、ＵＣＩがＴＢと多重化される）では、ＵＣＩ情報は、より低いレート符号（例えば、一連のＫ回の送信における前の送信と比較して）を使用して多重化されてもよい。より低いレート符号は、より高い量の冗長性と関連付けられてもよい。Ｋ回の繰り返しを伴うＧＦ送信では、ＵＣＩは、例えば、１回目繰り返しと比較して、２回目の繰り返しにおいてより低いレート符号により符号化されてもよい。ＵＣＩは、例えば、２回目の繰り返しと比較して、３回目の繰り返しにおいてより低いレート符号により符号化されてもよい、などである。ｇＮＢがＷＴＲＵによって使用される符号化レートを認識することを保証するために、例えば、予め定義されたレートマッチング／符号化レートパラメータのセットが指定されてもよく、ＷＴＲＵは、Ｋ回の繰り返しを伴うＴＢ（再）送信の間に予め定義されたレートマッチング／符号化レートパラメータのセットを順番に使用してもよい。例えば、ＷＴＲＵは、{１／２、１／３、１／４}であるとしてＷＴＲＵ特有ＲＲＣシグナリングによって構成されてもよい、符号化レートシーケンスに従ってもよい。ＷＴＲＵは、例えば、ＧＦ  ＵＬ（再）送信の間に多重化されることになる（例えば、各々の）それぞれのＵＣＩに対してＲＥの量を計算するよう、（再）送信（例えば、各々の、（再）送信）に対して異なるベータオフセット値（ｂｅｔａ−ｏｆｆｓｅｔ  ｖａｌｕｅ）を使用してもよい。例えば、ＷＴＲＵは、
【０１０２】
【数１】
2021508422.tif 000003
【０１０３】
であるＷＴＲＵ特有ＲＲＣシグナリングによって構成されてもよい、ベータオフセットシーケンスに従ってもよい。第１の送信に対するベータオフセットは、第２の送信に対するベータオフセットよりも小さくてもよい、などである。
【０１０４】
ＷＴＲＵは、ＷＴＲＵのＧＦ  ＵＬ送信のＨＡＲＱフィードバックを待機してもよい（例えば、待機時間の間）。ＷＴＲＵがそのＧＦ  ＵＬ送信のＨＡＲＱフィードバックを待機している間、ＰＵＣＣＨリソースがＷＴＲＵに割り当てられる場合、ＷＴＲＵは、ＵＣＩを再送信してもよい（例えば、前のＧＦ  ＵＬ送信が成功したかどうかに関わらず）。ＴＢのＧＦ送信の間に多重化されたＵＣＩとの衝突が発生する場合、ＷＴＲＵは、ＨＡＲＱ−ＮＡＣＫを受信してもよく、またはＨＡＲＱフィードバックを受信しなくてもよい。多重化されたＵＣＩは、ｇＮＢによって受信されなくてもよく、および／または再送信されてもよい（例えば、もしあれば、グラントベースＰＵＳＣＨリソースによって多重化され、および／または別のＧＦ送信において再送信される場合の、到来するＰＵＣＣＨ機会において）。
【０１０５】
ＵＣＩ多重化に基づく優先付けが実行されてもよい。ＷＴＲＵによるＵＣＩの送信（例えば、ＨＡＲＱ  ＡＣＫ）がＧＦ送信（例えば、所与のスロットに対する）よりも高い優先度を有する場合、ＷＴＲＵは、ＰＵＳＣＨ上のＧＦ送信（例えば、ＣＳＩもしくはＣＱＩ）をドロップしてもよく、および／またはＰＵＣＣＨにおいてＨＡＲＱ−ＡＣＫ（例えば、ＨＡＲＱ−ＡＣＫのみ）を送信してもよい。ＷＴＲＵは、後続のスロットにおいてＰＵＳＣＨ上のグラントフリーリソース上でＧＦ送信を開始してもよい（例えば、即時に開始する）。ＷＴＲＵによるＵＣＩの送信（例えば、定期的／半永続的ＣＳＩ報告）がＧＦデータ送信（例えば、所与のスロットに対する）よりも低い優先度を有する場合、ＷＴＲＵは、定期的／半永続的ＣＳＩ報告をドロップしてもよく、ＰＵＳＣＨ上でのデータのＧＦ送信を続行してもよく、および／または定期的／半永続的ＣＳＩ報告をデータと多重化してもよく、ＰＵＳＣＨ上のＧＦリソース上で送信してもよい。ＷＴＲＵがＵＣＩをドロップした場合、ＷＴＲＵは、次の割り当てられたＰＵＣＣＨリソースにおいて定期的／半永続的ＣＳＩ報告の送信を継続してもよい。ｇＮＢは、例えば、ＰＵＣＣＨおよび／またはＧＦ  ＰＵＳＣＨリソースを検出することによって（例えば、同時に検出する）、ＷＴＲＵの振る舞いを判定してもよい（例えば、盲目的に判定する）。ｇＮＢがＰＵＳＣＨを検出する場合（例えば、ＰＵＣＣＨ上でのＷＴＲＵによるＵＣＩ送信を予測している間）、ｇＮＢは、ＷＴＲＵがＵＣＩをデータと多重化しており、ならびに／またはＰＵＳＣＨ上のＧＦリソース上でＵＣＩおよびデータを送信していると判定してもよい。
【０１０６】
ＵＣＩ送信の優先度は、ＲＲＣによって構成されてもよい。例えば、ＷＴＲＵは、上位層によって提供される予め定義されたパラメータ（例えば、ｓｉｍｕｌｔａｎｅｏｕｓＣＳＩＡｎｄＤａｔａ）がＴＲＵＥに設定される場合、ＷＴＲＵが、例えば、ＧＦリソース上でＨＡＲＱ−ＡＣＫとデータを多重化することになり（例えば、多重化する必要がある）、および／またはＨＡＲＱ−ＡＣＫをドロップしないことになると判定してもよい。ＷＴＲＵは、例えば、上位層によって提供される予め定義されたパラメータ（例えば、ｓｉｍｕｌｔａｎｅｏｕｓＣＳＩＡｎｄＤａｔａ）がＴＲＵＥに設定されない場合、ＷＴＲＵが、定期的／半永続的ＣＳＩ報告（複数可）をドロップすることになり（例えば、ドロップする必要がある）、および／またはＧＦリソース上でＣＳＩ報告（複数可）をデータと多重化しないことになると判定してもよい。
【０１０７】
ＵＣＩ多重化は、ＨＡＲＱフィードバックを条件としてもよい。初期の送信に対し、ＷＴＲＵがＵＣＩをデータと多重化しており、ＧＦ  ＵＬリソース上で送信しており、および／またはｇＮＢからＮＡＣＫを受信する場合、ＷＴＲＵは、良好なカバレッジを有しないことがあり、および／またはＵＣＩもＴＢもｇＮＢにおいて検出に成功しないことがある。ＷＴＲＵは、例えば、ＵＣＩコンテンツの優先度に従って、ＧＦ再送信／繰り返しに対し、ＵＣＩおよび／またはデータをドロップすると判定してもよい（例えば、自律的に判定する）。ＷＴＲＵがＵＣＩをドロップする場合、例えば、ＧＦ  ＴＢ再送信に対する符号レートが低下されてもよく、それは、ｇＮＢにおけるＴＢの検出が成功する機会をより高くすることができる。ＷＴＲＵがデータをドロップする場合、例えば、ＷＴＲＵによるＵＣＩ送信は、ＰＵＣＣＨ上であってもよく、それは、ｇＮＢにおける検出の可能性をより高くすることができる。
【０１０８】
初期の送信に対し、ＷＴＲＵがＵＣＩをデータと多重化しており、ＧＦ  ＵＬリソース上で送信しており、および／またはｇＮＢからＡＣＫを受信する場合、ＷＴＲＵは、良好なカバレッジを有することがあり、ＵＣＩおよび／またはＴＢがｇＮＢにおいて検出されていることがある（例えば、検出に成功する）。ＷＴＲＵは、例えば、ＧＦ再送信／繰り返しに対してＵＣＩをデータと多重化すると判定してもよい（例えば、自律的に判定する）（例えば、ＵＣＩコンテンツの優先度に関わらず）。ＷＴＲＵは、ＵＣＩをドロップしなくてもよく、および／または後続のＧＦ再送信／繰り返しにおいてＵＣＩをデータと多重化してもよい（例えば、常に多重化する）。
【０１０９】
特徴および要素が特定の組み合わせで上記説明されたが、当業者は、各々の特徴または要素が単独で、または他の特徴および要素とのいずれかの組み合わせで使用されてもよいことを認識するであろう。加えて、本明細書で説明される方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてもよい。コンピュータ可読媒体の例は、電子信号（有線または無線接続を通じて送信される）およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、磁気光学媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含むが、それらに限定されない。ソフトウェアと関連してプロセッサは、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、またはいずれかのホストコンピュータにおける使用のために無線周波数送受信機を実装するために使用されてもよい。
【図１Ａ】
2021508422.tif 000004
【図１Ｂ】
2021508422.tif 000005
【図１Ｃ】
2021508422.tif 000006
【図１Ｄ】
2021508422.tif 000007
【図２】
2021508422.tif 000008
【図３】
2021508422.tif 000009
【図４】
2021508422.tif 000010
【図５】
2021508422.tif 000011
【手続補正書】
【提出日】令和2年7月14日(2020.7.14)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
アップリンク制御情報（ＵＣＩ）を送信する方法であって、
無線送信／受信ユニット（ＷＴＲＵ）が、ＵＣＩの送信が物理アップリンク共有チャネル（ＰＵＳＣＨ）上でグラントフリー（ＧＦ）送信と重なると判定するステップと、
前記ＷＴＲＵが、前記ＰＵＳＣＨ上で前記ＧＦ送信を送信しないと判定するステップと、
前記ＷＴＲＵが、物理アップリンク制御チャネル（ＰＵＣＣＨ）上で前記ＵＣＩを送信すると判定するステップと、
前記ＷＴＲＵが、前記ＰＵＣＣＨ上で前記ＵＣＩを送信するステップと、
を備えたことを特徴とする方法。
【請求項２】
前記ＵＣＩは、ＨＡＲＱ／ＡＣＫ情報を含むことを特徴とする請求項１に記載の方法。
【請求項３】
ＵＣＩの前記送信が前記ＰＵＳＣＨ上で前記ＧＦ送信と重なると判定するステップは、前記ＵＣＩの前記送信がスロットにおいて前記ＧＦ送信と重なると判定することを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記ＰＵＳＣＨ上で前記ＧＦ送信を送信するステップを更に備え、
前記ＵＣＩは、前記ＰＵＳＣＨ上で前記ＧＦ送信を送信する前に前記ＰＵＣＣＨ上で送信される、
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記ＵＣＩを送信するステップは、第１のスロットにおいて前記ＵＣＩを送信することを含み、
前記ＧＦ送信を送信するステップは、第２のスロットにおいて前記ＧＦ送信を送信することを含み、前記第２のスロットは、前記第１のスロットの直後に続く、
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記ＷＴＲＵが、構成情報を受信するステップを更に備え、
前記ＧＦ送信を送信しないと判定するステップは、前記構成情報に基づいて、前記ＧＦ送信を送信しないと判定することを含む、
ことを特徴とする請求項１に記載の方法。
【請求項７】
構成情報を受信するステップは、無線リソース制御（ＲＲＣ）構成情報を受信することを含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記ＧＦ送信を送信しないと判定するステップは、構成情報がないことに基づいて、前記ＧＦ送信を送信しないと判定することを含むことを特徴とする請求項１に記載の方法。
【請求項９】
前記ＷＴＲＵが、第２のＵＣＩの送信が物理アップリンク共有チャネル（ＰＵＳＣＨ）上で第２のグラントフリー（ＧＦ）送信と重なると判定するステップと、
前記ＷＴＲＵが、前記ＰＵＳＣＨ上で前記第２のＵＣＩおよび前記第２のＧＦ送信を多重化すると判定するステップと、
前記ＷＴＲＵが、前記ＰＵＳＣＨ上で前記第２のＵＣＩおよび前記第２のＧＦ送信を多重化するステップと、
前記ＷＴＲＵが、前記ＰＵＳＣＨ上で前記第２のＵＣＩおよび第２のＧＦ送信を送信するステップと、
を更に備えたことを特徴とする請求項１に記載の方法。
【請求項１０】
前記ＷＴＲＵが、構成情報を受信するステップを更に備え、
前記ＰＵＳＣＨ上で前記第２のＵＣＩおよび前記第２のＧＦ送信を多重化すると判定するステップは、前記構成情報に基づいて、前記ＰＵＳＣＨ上で前記第２のＵＣＩおよび前記第２のＧＦ送信を多重化すると判定することを含む、
ことを特徴とする請求項９に記載の方法。
【請求項１１】
ＵＣＩの送信が物理アップリンク共有チャネル（ＰＵＳＣＨ）上でグラントフリー（ＧＦ）送信と重なると判定し、
前記ＰＵＳＣＨ上で前記ＧＦ送信を送信しないと判定し、
物理アップリンク制御チャネル（ＰＵＣＣＨ）上で前記ＵＣＩを送信すると判定し、
前記ＰＵＣＣＨ上で前記ＵＣＩを送信する、
ように少なくとも構成されたプロセッサを備えたことを特徴とする無線送信／受信ユニット（ＷＴＲＵ）。
【請求項１２】
前記ＵＣＩは、ＨＡＲＱ／ＡＣＫ情報を含むことを特徴とする請求項１１に記載のＷＴＲＵ。
【請求項１３】
前記プロセッサは、前記ＵＣＩの前記送信がスロットにおいて前記ＧＦ送信と重なると判定するように更に構成されていることを特徴とする請求項１１に記載のＷＴＲＵ。
【請求項１４】
前記プロセッサは、前記ＰＵＳＣＨ上で前記ＧＦ送信を送信するように更に構成され、
前記ＵＣＩは、前記ＰＵＳＣＨ上で前記ＧＦ送信を送信する前に前記ＰＵＣＣＨ上で送信される、
ことを特徴とする請求項１１に記載のＷＴＲＵ。
【請求項１５】
前記ＵＣＩは、第１のスロットにおいて送信され、
前記プロセッサは、第２のスロットにおいて前記ＧＦ送信を送信するように更に構成され、前記第２のスロットは、前記第１のスロットの直後に続く、
ことを特徴とする請求項１４に記載のＷＴＲＵ。
【請求項１６】
前記プロセッサは、
構成情報を受信し、
前記構成情報に基づいて、前記ＧＦ送信を送信しないと判定する、
ように更に構成されていることを特徴とする請求項１１に記載のＷＴＲＵ。
【請求項１７】
前記構成情報は、無線リソース制御（ＲＲＣ）構成情報を含むことを特徴とする請求項１６に記載のＷＴＲＵ。
【請求項１８】
前記プロセッサは、構成情報を受信しなかったことに基づいて、前記ＧＦ送信を送信しないと判定するように更に構成されていることを特徴とする請求項１１に記載のＷＴＲＵ。
【請求項１９】
前記プロセッサは、
第２のＵＣＩの送信が物理アップリンク共有チャネル（ＰＵＳＣＨ）上で第２のグラントフリー（ＧＦ）送信と重なると判定し、
前記ＰＵＳＣＨ上で前記第２のＵＣＩおよび前記第２のＧＦ送信を多重化すると判定し、
前記ＰＵＳＣＨ上で前記第２のＵＣＩおよび前記第２のＧＦ送信を多重化し、
前記ＰＵＳＣＨ上で前記第２のＵＣＩおよび第２のＧＦ送信を送信する、
ように更に構成されていることを特徴とする請求項１１に記載のＷＴＲＵ。
【請求項２０】
前記プロセッサは、
構成情報を受信し、
前記構成情報に基づいて、前記ＰＵＳＣＨ上で前記第２のＵＣＩおよび前記第２のＧＦ送信を多重化すると判定する、
ように更に構成されていることを特徴とする請求項１９に記載のＷＴＲＵ。
【国際調査報告】
2021508422.tif 000012
2021508422.tif 000013