(57)【要約】  新たなライセンスのない無線帯域（ＮＲ−Ｕ）環境において確認応答を効率的かつ堅牢に処理するためのシステム、方法、および装置である。無線送信受信ユニット（ＷＴＲＵ）は、第１の間隔（すなわち、トランスポートブロックまたはチャネル占有時間）においてｇＮＢから制御情報およびデータ送信を受信することができ、制御情報は、アップリンクリソースのインジケーションを含むことができる。データ送信は、ある種の確認応答（すなわち、ＨＡＲＱフィードバック）を必要とする場合がある。ＷＴＲＵは、示されたアップリンクリソースにおいて確認応答を送信しようとすることができるが、ｇＮＢは、確認応答を受信しないことがある。ＷＴＲＵは、以前に失敗した確認応答送信を集約するためのインジケーションを含む、第２の間隔においてｇＮＢからの制御情報およびデータ送信を受信することができる。ＷＴＲＵは、以前の失敗した確認応答および現在の間隔からの任意の追加の確認応答を含む集約された確認応答を送信することができる。場合によっては、ルックビフォアトーク手順が使用され得る。【選択図】図８
2021534623.tif 000002
【特許請求の範囲】
【請求項１】
無線送信受信ユニット（ＷＴＲＵ）によって実行される方法であって、
第１のチャネル占有時間（ＣＯＴ）において１つ以上の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）を受信することと、
制御情報とともに第２のＣＯＴにおいて物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を受信することと、
前記第２のＣＯＴにおいて１つ以上のＰＤＳＣＨを受信することと、
前記制御情報に基づいて、前記第１のＣＯＴの前記１つ以上のＰＤＳＣＨおよび前記第２のＣＯＴの前記１つ以上のＰＤＳＣＨのＨＡＲＱフィードバックを集約することと、
前記制御情報に示されているリソースに基づいて、前記第２のＣＯＴの物理アップリンク制御チャネル（ＰＵＣＣＨ）において、前記集約されたＨＡＲＱフィードバックを送信することと、
を備える、方法。
【請求項２】
前記第２のＣＯＴの前記ＰＵＣＣＨにおいて前記集約されたＨＡＲＱフィードバックを送信する前に、リッスンビフォアトーク（ＬＢＴ）を実行することを更に備える、請求項１に記載の方法。
【請求項３】
前記第１のＣＯＴの前記１つ以上のＰＤＳＣＨおよび前記第２のＣＯＴの前記１つ以上のＰＤＳＣＨを復号し、各ＣＯＴの各ＰＤＳＣＨについてのＨＡＲＱフィードバックを判定することを更に備える、請求項２に記載の方法。
【請求項４】
前記制御情報が、ＨＡＲＱフィードバックを集約するためのグループまたは時間を示す拡張ダウンリンク割り当てインジケータ（ＥＤＡＩ）を含む、請求項３に記載の方法。
【請求項５】
前記ＥＤＡＩに基づいて前記第１のＰＤＳＣＨおよび前記第２のＰＤＳＣＨを集約することを判定することを更に備える、請求項４に記載の方法。
【請求項６】
前記示されたリソースが排他的または非排他的である、請求項１に記載の方法。
【請求項７】
前記示されたリソースが優先度パラメータを含む、請求項１に記載の方法。
【請求項８】
無線送信受信ユニット（ＷＴＲＵ）であって、
プロセッサに結合されたトランシーバであって、前記トランシーバおよび前記プロセッサが、第１のチャネル占有時間（ＣＯＴ）において１つ以上の物理ダウンリンク共有チャネル（ＰＤＳＣＨ）を受信するように構成されたトランシーバを備え、
前記トランシーバおよびプロセッサが、さらに、第２のＣＯＴにおいて１つ以上のＰＤＳＣＨを受信し、前記第２のＣＯＴにおいて制御情報とともに物理ダウンリンク制御チャネル（ＰＤＣＣＨ）を受信するように構成されており、
前記トランシーバおよびプロセッサが、前記制御情報に基づいて、前記第１のＣＯＴの前記１つ以上のＰＤＳＣＨおよび前記第２のＣＯＴの前記１つ以上のＰＤＳＣＨについてのＨＡＲＱフィードバックを集約し、前記集約されたＨＡＲＱフィードバックを、前記制御情報に示されているリソースに基づいて、前記第２のＣＯＴの物理アップリンク制御チャネル（ＰＵＣＣＨ）に送信するように構成されている、ＷＴＲＵ。
【請求項９】
前記トランシーバおよびプロセッサが、さらに、前記第２のＣＯＴの前記ＰＵＣＣＨにおいて前記集約されたＨＡＲＱフィードバックを送信する前に、リッスンビフォアトーク（ＬＢＴ）を実行するように構成されている、請求項８に記載のＷＴＲＵ。
【請求項１０】
前記トランシーバおよびプロセッサが、さらに、前記第１のＣＯＴの前記１つ以上のＰＤＳＣＨおよび前記第２のＣＯＴの前記１つ以上のＰＤＳＣＨを復号し、各ＣＯＴの各ＰＤＳＣＨに必要なＨＡＲＱフィードバックを判定するように構成されている、請求項９に記載のＷＴＲＵ。
【請求項１１】
前記制御情報が、ＨＡＲＱフィードバックを集約するためのグループまたは時間を示す拡張ダウンリンク割り当てインジケータ（ＥＤＡＩ）を含む、請求項１０に記載のＷＴＲＵ。
【請求項１２】
前記トランシーバおよびプロセッサが、さらに、前記ＥＤＡＩに基づいて前記第１のＰＤＳＣＨおよび前記第２のＰＤＳＣＨを集約することを判定するように構成されている、請求項１１に記載のＷＴＲＵ。
【請求項１３】
前記示されたリソースが排他的または非排他的である、請求項８に記載のＷＴＲＵ。
【請求項１４】
前記示されたリソースが、優先度パラメータを含む、請求項８に記載のＷＴＲＵ。
【発明の詳細な説明】
【背景技術】
【０００１】
優先権の主張
この特許出願は、２０１８年８月８日に出願された米国仮特許出願第６２／７１６，２１１号および２０１８年１０月３１日に出願された米国仮特許出願第６２／７５３，４５７号の利益を主張し、その内容は、参照により本明細書に組み込まれる。
【０００２】
無線通信の分野では、Ｎｅｗ  Ｒａｄｉｏなどの次世代エアインターフェースは、ライセンス付き、ライセンスなし／共有など、様々なスペクトル使用モデルによる幅広いユースケースをサポートすることができる。共有スペクトルで動作するためには、ライセンスのない帯域において効率的で堅牢な無線通信を実現するシステム、方法、および装置が必要になる場合がある。
【発明の概要】
【０００３】
新たなライセンスのない無線帯域（ＮＲ−Ｕ）環境において確認応答を効率的かつ堅牢に処理するためのシステム、方法、および装置である。無線送信受信ユニット（ＷＴＲＵ）は、第１の間隔（すなわち、トランスポートブロックまたはチャネル占有時間）においてｇＮＢから制御情報およびデータ送信を受信することができ、制御情報は、アップリンクリソースのインジケーションを含むことができる。データ送信は、ある種の確認応答（すなわち、ＨＡＲＱフィードバック）を必要とする場合がある。ＷＴＲＵは、示されたアップリンクリソースにおいて確認応答を送信しようとすることができるが、ｇＮＢは、確認応答を受信しないことがある。ＷＴＲＵは、以前に失敗した確認応答送信を集約するためのインジケーションを含む、第２の間隔においてｇＮＢからの制御情報およびデータ送信を受信することができる。ＷＴＲＵは、以前の失敗した確認応答および現在の間隔からの任意の追加の確認応答を含む集約された確認応答を送信することができる。場合によっては、ルックビフォアトーク手順が使用され得る。
【０００４】
より詳細な理解は、添付の図面と併せて例として与えられた以下の説明から得ることができ、図中の同様の参照符号は同様の要素を示す。
【図面の簡単な説明】
【０００５】
【図１Ａ】図１Ａは、１つ以上の開示された実施形態が実装されることができる例示的な通信システムを示すシステム図である。
【図１Ｂ】図１Ｂは、実施形態にかかる、図１Ａに示す通信システム内で使用されることができる無線送受信ユニット（ＷＴＲＵ）の例を示すシステム図である。
【図１Ｃ】図１Ｃは、実施形態にかかる、図１Ａに示す通信システム内で使用されることができる例示的な無線アクセスネットワーク（ＲＡＮ）および例示的なコアネットワーク（ＣＮ）を示すシステム図である。
【図１Ｄ】図１Ｄは、実施形態にかかる、図１Ａに示す通信システム内で使用されることができる、さらなる例示的なＲＡＮおよびさらなる例示的なＣＮを示すシステム図である。
【図２】図２は、ＷＴＲＵがＬＢＴ手順に失敗する例示的な送信図である。
【図３】図３は、ＷＴＲＵがＬＢＴ手順に失敗する例示的な送信図である。
【図４】図４は、ＷＴＲＵが非排他的ＰＵＣＣＨの優先順位を有することができる例示的な送信図である。
【図５】図５は、ＷＴＲＵがＬＢＴを正常に完了したが、ｇＮＢがＰＵＣＣＨを検出することができなかった例示的な送信図である。
【図６】図６は、ＷＴＲＵが少なくともＤＡＩおよび／またはＥＤＡＩにしたがってＨＡＲＱコードブックを準備する例示的な送信図である。
【図７】図７は、ＷＴＲＵが少なくともＤＡＩおよび／またはＥＤＡＩにしたがってＨＡＲＱコードブックを準備する例示的な送信図である。
【図８】図８は、ＷＴＲＵが１つ以上のＣＯＴのＥＤＡＩに基づいてＨＡＲＱコードブックを集約する例示的な送信図である。
【図９】図９は、ＰＵＣＣＨリソース割り当てがＣＯＴの外側にあり、後のＣＯＴからのＰＵＣＣＨが使用される例示的な送信図である。
【図１０】図１０は、ＷＴＲＵがスケジュールされたＰＵＣＣＨの属性を検査してギャップなしの送信を決定する例示的な送信図である。
【図１１】図１１は、競合ウィンドウ調整の例示的な手順である。
【図１２】図１２は、基本的なＣＯＴ共有の例示的な送信図である。
【図１３】図１３は、隠れノードの効果を制限するＣＯＴ共有の例示的な送信図である。
【発明を実施するための形態】
【０００６】
図１Ａは、１つ以上の開示された実施形態が実装されることができる例示的な通信システム１００を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数の無線ユーザに提供するマルチアクセスシステムとすることができる。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じてそのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）、ゼロテールユニークワードＤＦＴ−スプレッドＯＦＤＭ（ＺＴ  ＵＷ  ＤＴＳ−ｓ  ＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ−ＯＦＤＭ）、リソースブロックフィルタリングＯＦＤＭ、フィルタバンクマルチキャリア（ＦＢＭＣ）などの１つ以上のチャネルアクセス方式を採用してもよい。
【０００７】
図１Ａに示すように、通信システム１００は、無線送信受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、ＲＡＮ１０４／１１３、ＣＮ１０６／１１５、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、および他のネットワーク１１２を含むことができるが、開示された実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を想定することが理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、無線環境で動作および／または通信するように構成された任意の種類のデバイスとすることができる。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ（これらのいずれも「ステーション」および／または「ＳＴＡ」と称されることができる）は、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、モバイルステーション、固定もしくはモバイルサブスクライバーユニット、サブスクリプションベースのユニット、ページャー、携帯電話、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピューター、無線センサ、ホットスポットもしくはＭｉ−Ｆｉデバイス、モノのインターネット（ＩｏＴ）デバイス、時計もしくはその他のウェアラブル、ヘッドマウントディスプレイ（ＨＭＤ）、車両、ドローン、医療機器およびアプリケーション（例えば、遠隔手術）、産業用デバイスおよびアプリケーション（例えば、産業用および／または自動処理チェーンのコンテキストで動作するロボットおよび／または他の無線デバイス）、家庭用電化製品デバイス、商用および／または産業用無線で動作するデバイスネットワークなどを含むことができる。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、および１０２ｄのいずれも、交換可能にＷＴＲＵ／ＵＥと称されることができる。
【０００８】
通信システム１００はまた、基地局１１４ａおよび／または基地局１１４ｂを含むことができる。基地局１１４ａ、１１４ｂのそれぞれは、ＣＮ１０６／１１５、インターネット１１０、および／または他のネットワーク１１２などの、１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線インターフェースするように構成された任意の種類のデバイスとすることができる。例として、基地局１１４ａ、１１４ｂは、基地トランシーバ局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅ−Ｂ、ホームＮｏｄｅ−Ｂ、ホームｅＮｏｄｅ−Ｂ、ｇＮＢ、ＮＲ  Ｎｏｄｅ−Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどとすることができる。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含むことができることが理解されよう。
【０００９】
基地局１１４ａは、ＲＡＮ１０４／１１３の一部であってもよく、これはまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、リレーノードなどの他の基地局および／またはネットワーク要素（図示せず）を含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示せず）と称されることができる１つ以上のキャリア周波数で無線信号を送信および／または受信するように構成されてもよい。これらの周波数は、ライセンススペクトル、非ライセンススペクトル、またはライセンススペクトルと非ライセンススペクトルの組み合わせであってもよい。セルは、比較的固定されているか、時間の経過とともに変化する可能性がある特定の地理的領域に無線サービスのカバレッジを提供することができる。セルは、さらにセルセクタに分割することができる。例えば、基地局１１４ａに関連するセルは、３つのセクタに分割することができる。したがって、一実施形態では、基地局１１４ａは、３つのトランシーバ、すなわち、セルの各セクタに１つを含むことができる。実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用することができ、セルの各セクタに対して複数のトランシーバを利用することができる。例えば、ビームフォーミングを使用して、所望の空間方向に信号を送信および／または受信することができる。
【００１０】
基地局１１４ａ、１１４ｂは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、センチメートル波、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができるエアインターフェース１１６を介して、１つ以上のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと通信することができる。エアインターフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されることができる。
【００１１】
より具体的には、上記のように、通信システム１００は、多元接続システムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどのような１つ以上のチャネルアクセス方式を採用してもよい。例えば、ＲＡＮ１０４／１１３の基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサルモバイルテレコミュニケーションシステム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実装することができ、これは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用して、エアインターフェース１１５／１１６／１１７を確立することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または発展型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンク（ＤＬ）パケットアクセス（ＨＳＤＰＡ）および／または高速ＵＬパケットアクセス（ＨＳＵＰＡ）を含んでもよい。
【００１２】
実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、発展型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装することができ、これは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥ−アドバンスト（ＬＴＥ−Ａ）および／またはＬＴＥ−アドバンストプロ（ＬＴＥ−Ａ  Ｐｒｏ）を使用してエアインターフェース１１６を確立することができる。
【００１３】
実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、新たな無線（ＮＲ）アクセスなどの無線技術を実装することができ、これは、ＮＲを使用してエアインターフェース１１６を確立することができる。
【００１４】
実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実装することができる。例えば、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、例えば、二重接続（ＤＣ）原理を使用して、ＬＴＥ無線アクセスおよびＮＲ無線アクセスを一緒に実装することができる。したがって、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインターフェースは、複数の種類の基地局（例えば、ｅＮＢおよびｇＮＢ）との間で送受信される複数の種類の無線アクセス技術および／または送信によって特徴付けられることができる。
【００１５】
他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（すなわち、無線フィデリティ（Ｗｉ−Ｆｉ）、ＩＥＥＥ８０２．１６（すなわち、マイクロ波アクセスのための世界的相互運用性（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００ＥＶ−ＤＯ、暫定規格２０００（ＩＳ−２０００）、暫定規格９５（ＩＳ−９５）、暫定規格８５６（ＩＳ−８５６）、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ）、ＧＳＭエボリューションの拡張データレート（ＥＤＧＥ）、ＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。
【００１６】
図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅ−Ｂ、ホームｅＮｏｄｅ−Ｂ、またはアクセスポイントであってもよく、事業所、家庭、車両、キャンパス、産業施設、（例えば、ドローンが使用するための）空中回廊、道路などなどの局所領域における無線接続を容易にするために任意の適切なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立するために、ＩＥＥＥ８０２．１１などの無線技術を実装することができる。実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立するために、ＩＥＥＥ８０２．１５などの無線技術を実装することができる。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラーベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａ、ＬＴＥ−Ａ  Ｐｒｏ、ＮＲなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０に直接接続することができる。したがって、基地局１１４ｂは、ＣＮ１０６／１１５を介してインターネット１１０にアクセスする必要がない場合がある。
【００１７】
ＲＡＮ１０４／１１３は、ＣＮ１０６／１１５と通信することができ、ＣＮ１０６／１１５は、１つ以上のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄに音声、データ、アプリケーション、および／またはボイスオーバーインターネットプロトコル（ＶｏＩＰ）サービスを提供するように構成された任意の種類のネットワークとすることができる。データは、異なるスループット要件、遅延要件、エラー許容要件、信頼性要件、データスループット要件、モビリティ要件など、様々なサービス品質（ＱｏＳ）要件を有することができる。ＣＮ１０６／１１５は、呼制御、課金サービス、モバイル位置ベースのサービス、プリペイド通話、インターネット接続、ビデオ配信などを提供し、および／またはユーザ認証などの高レベルのセキュリティ機能を実行することができる。図１Ａには示されていないが、ＲＡＮ１０４／１１３および／またはＣＮ１０６／１１５は、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを使用する他のＲＡＮと直接または間接的に通信することができることが理解されよう。例えば、ＮＲ無線技術を利用することができるＲＡＮ１０４／１１３に接続されることに加えて、ＣＮ１０６／１１５はまた、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ−ＵＴＲＡ、またはＷｉ−Ｆｉ無線技術を使用する別のＲＡＮ（図示せず）と通信してもよい。
【００１８】
ＣＮ１０６／１１５はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとして機能することができる。ＰＳＴＮ１０８は、一般電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含むことができる。インターネット１１０は、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、および／またはＴＣＰ／ＩＰインターネットプロトコルスイートのインターネットプロトコル（ＩＰ）などの共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含むことができる。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運用される有線および／または無線通信ネットワークを含むことができる。例えば、ネットワーク１１２は、１つ以上のＲＡＮに接続された別のＣＮを含んでもよく、これは、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを使用してもよい。
【００１９】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全ては、マルチモード機能を含むことができる（例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含むことができる）。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラーベースの無線技術を採用することができる基地局１１４ａと、およびＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂと通信するように構成されてもよい。
【００２０】
図１Ｂは、例示的なＷＴＲＵ１０２を示すシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、とりわけプロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、グローバルポジショニングシステム（ＧＰＳ）チップセット１３６、および／または他の周辺機器１３８を含むことができる。ＷＴＲＵ１０２は、実施形態と一致性を保ちながら、前述の要素の任意のサブコンビネーションを含むことができることが理解されよう。
【００２１】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、その他の種類の集積回路（ＩＣ）、ステートマシンなどとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境で動作することを可能にする他の任意の機能を実行することができる。プロセッサ１１８は、トランシーバ１２０に結合され得、トランシーバ１２０は、送信／受信要素１２２に結合されることができる。図１Ｂは、プロセッサ１１８およびトランシーバ１２０を別個のコンポーネントとして示しているが、プロセッサ１１８およびトランシーバ１２０は、電子パッケージまたはチップに一体に集積されることができることが理解されよう。
【００２２】
送信／受信要素１２２は、エアインターフェース１１６を介して基地局（例えば、基地局１１４ａ）に信号を送信するか、または基地局から信号を受信するように構成されることができる。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／検出器であってもよい。さらに別の実施形態では、送信／受信要素１２２は、ＲＦ信号および光信号の両方を送信および／または受信するように構成されてもよい。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されることができることが理解されよう。
【００２３】
送信／受信要素１２２は、単一の要素として図１Ｂに示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用することができる。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６を介して無線信号を送受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含んでもよい。
【００２４】
トランシーバ１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信される信号を復調するように構成されることができる。上記のように、ＷＴＲＵ１０２はマルチモード機能を有することができる。したがって、トランシーバ１２０は、ＷＴＲＵ１０２が、例えば、ＮＲおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための複数のトランシーバを含んでもよい。
【００２５】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合され得、そしてそれらからユーザ入力データを受信することができる。プロセッサ１１８はまた、ユーザデータをスピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８に出力することができる。さらに、プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２などの任意の種類の適切なメモリからの情報にアクセスし、データを記憶することができる。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他の種類のメモリ記憶装置を含むことができる。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含むことができる。他の実施形態では、プロセッサ１１８は、サーバーまたはホームコンピュータ（図示せず）など、ＷＴＲＵ１０２上に物理的に配置されていないメモリから情報にアクセスし、メモリにデータを記憶してもよい。
【００２６】
プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２内の他のコンポーネントに電力を分配および／または制御するように構成されることができる。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１つ以上の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン）など）、太陽電池、燃料電池などを含んでもよい。
【００２７】
プロセッサ１１８はまた、ＧＰＳチップセット１３６に結合されることができ、これは、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成されることができる。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６を介して位置情報を受信してもよく、および／または２つ以上の近くの基地局から受信される信号のタイミングに基づいてその位置を判定してもよい。ＷＴＲＵ１０２は、実施形態と一致性を保ちながら、任意の適切な位置決定方法によって位置情報を取得することができることが理解されよう。
【００２８】
プロセッサ１１８は、追加の特徴、機能、および／または有線または無線接続を提供する１つ以上のソフトウェアおよび／またはハードウェアモジュールを含むことができる他の周辺機器１３８にさらに結合されることができる。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星トランシーバ、デジタルカメラ（写真および／またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動装置、テレビトランシーバ、ハンズフリーヘッドセット、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実および／または拡張現実（ＶＲ／ＡＲ）デバイス、アクティビティトラッカなどを含むことができる。周辺機器１３８は、１つ以上のセンサを含むことができ、センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、方向センサ、近接センサ、温度センサ、時間センサ、地理位置情報センサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、生体認証センサ、および／または湿度センサのうちの１つ以上とすることができる。
【００２９】
ＷＴＲＵ１０２は、ＵＬ（例えば、送信用）およびダウンリンク（例えば、受信用）の双方の信号の一部または全て（例えば、特定のサブフレームに関連付けられる）の送信および受信が並列および／または同時に行われ得る全二重無線を含むことができる。全二重無線は、ハードウェア（例えば、チョーク）またはプロセッサ（例えば、別個のプロセッサ（図示せず）またはプロセッサ１１８を介した信号処理）のいずれかを介した自己干渉を低減および／または実質的に排除するための干渉管理ユニット１３９を含むことができる。実施形態では、ＷＲＴＵ１０２は、信号の一部または全ての送信および受信（例えば、ＵＬ（例えば、送信用）またはダウンリンク（例えば、受信用）のいずれかの特定のサブフレームに関連付けられる）のための半二重無線を含むことができる。
【００３０】
図１Ｃは、実施形態にかかるＲＡＮ１０４およびＣＮ１０６を示すシステム図である。上記のように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を使用して、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０４はまた、ＣＮ１０６と通信することもできる。
【００３１】
ＲＡＮ１０４は、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃを含むことができるが、ＲＡＮ１０４は、実施形態と一致性を保ちながら、任意の数のｅＮｏｄｅ−Ｂを含むことができることが理解されるであろう。ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つ以上のトランシーバを含むことができる。一実施形態では、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装することができる。したがって、ｅＮｏｄｅ−Ｂ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および／またはＷＴＲＵ１０２ａから無線信号を受信することができる。
【００３２】
ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれは、特定のセル（図示せず）に関連付けられることができ、無線リソース管理決定、ハンドオーバー決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリングなどを処理するように構成されることができる。図１Ｃに示されるように、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェースを介して互いに通信することができる。
【００３３】
図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２、サービングゲートウェイ（ＳＧＷ）１６４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ（またはＰＧＷ）１６６を含むことができる。前述の要素のそれぞれは、ＣＮ１０６の一部として示されているが、これらの要素のいずれも、ＣＮオペレータ以外のエンティティによって所有および／または操作されることができることが理解されよう。
【００３４】
ＭＭＥ１６２は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６２ａ、１６２ｂ、１６２ｃのそれぞれに接続されてもよく、制御ノードとして機能してもよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃなどの最初の接続中に特定のサービングゲートウェイを選択することを担当することができる。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭおよび／またはＷＣＤＭＡなどの他の無線技術を使用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供することができる。
【００３５】
ＳＧＷ１６４は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続されることができる。ＳＧＷ１６４は、一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でユーザデータパケットをルーティングおよび転送することができる。ＳＧＷ１６４は、ｅＮｏｄｅ−Ｂ間ハンドオーバー中にユーザプレーンを固定する、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能であるときにページングをトリガーする、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃなどのコンテキストを管理および記憶するなどの、他の機能を実行することができる。
【００３６】
ＳＧＷ１６４は、ＰＧＷ１６６に接続されることができ、これは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０などのパケット交換ネットワークへのアクセスを提供することができる。
【００３７】
ＣＮ１０６は、他のネットワークとの通信を容易にすることができる。例えば、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバー）を含んでもよく、またはそれと通信してもよい。さらに、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有および／または運用される他の有線および／または無線ネットワークを含むことができる他のネットワーク１１２へのアクセスを提供することができる。
【００３８】
ＷＴＲＵは、無線端末として図１Ａ〜図１Ｄに記載されているが、特定の代表的な実施形態では、そのような端末が、通信ネットワークとの有線通信インターフェースを（例えば、一時的または恒久的に）使用することができることが想定される。
【００３９】
代表的な実施形態では、他のネットワーク１１２は、ＷＬＡＮとすることができる。
【００４０】
インフラストラクチャ基本サービスセット（ＢＳＳ）モードのＷＬＡＮは、ＢＳＳ用のアクセスポイント（ＡＰ）と、ＡＰに関連付けられた１つ以上のステーション（ＳＴＡ）とを有することができる。ＡＰは、ＢＳＳの中へ、かつ／またはＢＳＳの外へトラフィックを伝送する、ディストリビューションシステム（ＤＳ）または別の種類の有線／無線ネットワークへのアクセスまたはインターフェースを有することができる。ＢＳＳの外部から発信されたＳＴＡへのトラフィックは、ＡＰを介して到着してもよく、ＳＴＡに配信されてもよい。ＳＴＡからＢＳＳの外部の宛先に発信されるトラフィックは、ＡＰに送信され、それぞれの宛先に配信されてもよい。ＢＳＳ内のＳＴＡ間のトラフィックは、ＡＰを介して送信できる。例えば、送信元ＳＴＡがＡＰにトラフィックを送信してもよく、ＡＰが宛先ＳＴＡにトラフィックを配信してもよい。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックと見なされ、かつ／または参照されてもよい。ピアツーピアトラフィックは、ダイレクトリンクセットアップ（ＤＬＳ）を使用して、送信元ＳＴＡと宛先ＳＴＡとの間に（例えば、直接）送信することができる。特定の代表的な実施形態では、ＤＬＳは、８０２．１１ｅ  ＤＬＳまたは８０２．１１ｚトンネルＤＬＳ（ＴＤＬＳ）を使用することができる。独立ＢＳＳ（ＩＢＳＳ）モードを使用するＷＬＡＮにはＡＰがない場合があり、ＩＢＳＳ内またはＩＢＳＳを使用するＳＴＡ（例えば、全てのＳＴＡ）は相互に直接通信する場合がある。ＩＢＳＳ通信モードは、本明細書では「アドホック」通信モードと称される場合がある。
【００４１】
８０２．１１ａｃインフラストラクチャモードの動作または同様の動作モードを使用する場合、ＡＰはプライマリチャネルなどの固定チャネルでビーコンを送信することができる。プライマリチャネルは、固定幅（例えば、２０ＭＨｚの広い帯域幅）またはシグナリングを介して動的に設定された幅とすることができる。プライマリチャネルは、ＢＳＳの動作チャネルであってもよく、ＡＰとの接続を確立するためにＳＴＡによって使用されてもよい。特定の代表的な実施形態では、衝突回避方式搬送波検知多重アクセス（ＣＳＭＡ／ＣＡ）は、例えば８０２．１１システムにおいて実装されてもよい。ＣＳＭＡ／ＣＡの場合、ＡＰを含むＳＴＡ（例えば、全てのＳＴＡ）がプライマリチャネルを検知することができる。プライマリチャネルが特定のＳＴＡによって検出／検出および／またはビジーであると判定された場合、特定のＳＴＡはバックオフする可能性がある。１つのＳＴＡ（例えば、１つのステーションのみ）は、特定のＢＳＳでいつでも送信することができる。
【００４２】
高いスループット（ＨＴ）ＳＴＡは、例えば、一次２０ＭＨｚチャネルと隣接または非隣接の２０ＭＨｚチャネルとの組み合わせを介して、４０ＭＨｚ幅チャネルを形成するために、通信のために４０ＭＨｚ幅チャネルを使用することができる。
【００４３】
非常に高いスループット（ＶＨＴ）ＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、および／または１６０ＭＨｚ幅のチャネルをサポートすることができる。４０ＭＨｚ、および／または８０ＭＨｚのチャネルは、連続する２０ＭＨｚチャネルを組み合わせることによって形成されることができる。１６０ＭＨｚチャネルは、８つの連続する２０ＭＨｚチャネルを組み合わせることによって、または２つの非連続の８０ＭＨｚチャネルを組み合わせることによって形成されることができ、これは、８０＋８０構成と称されることができる。８０＋８０構成の場合、チャネルエンコード後、データはセグメントパーサを通過してデータを２つのストリームに分割することができる。逆高速フーリエ変換（ＩＦＦＴ）処理、および時間領域処理は、各ストリームで個別に実行することができる。ストリームは、２つの８０ＭＨｚチャネルにマッピングされてもよく、データは送信ＳＴＡによって送信されてもよい。受信側ＳＴＡの受信機では、８０＋８０構成についての上記の動作を逆にすることができ、組み合わされたデータを媒体アクセス制御（ＭＡＣ）に送信することができる。
【００４４】
サブ１ＧＨｚの動作モードは、８０２．１１ａｆおよび８０２．１１ａｈでサポートされている。チャネルの動作帯域幅とキャリアは、８０２．１１ｎと８０２．１１ａｃで使用されているものと比較して８０２．１１ａｆと８０２．１１ａｈで減少している。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトルで５ＭＨｚ、１０ＭＨｚ、および２０ＭＨｚの帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、および１６ＭＨｚの帯域幅をサポートする。代表的な実施形態によれば、８０２．１１ａｈは、マクロカバレッジエリア内のＭＴＣデバイスなどのメーター型制御／マシン型通信をサポートすることができる。ＭＴＣデバイスは、特定の機能、例えば、特定の帯域幅および／または制限された帯域幅のサポート（例えば、サポートのみ）を含む制限された機能を有していてもよい。ＭＴＣデバイスは、（例えば、非常に長いバッテリ寿命を維持するために）閾値を超えるバッテリ寿命を有するバッテリを含むことができる。
【００４５】
複数のチャネルをサポートすることができるＷＬＡＮシステム、および８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、８０２．１１ａｈなどのチャネル帯域幅は、プライマリチャネルとして指定されることができるチャネルを含む。プライマリチャネルは、ＢＳＳ内の全てのＳＴＡでサポートされている最大の共通動作帯域幅に等しい帯域幅を有する場合がある。プライマリチャネルの帯域幅は、最小帯域幅の動作モードをサポートするＢＳＳで動作している全てのＳＴＡの中から、ＳＴＡによって設定および／または制限される場合がある。８０２．１１ａｈの例では、ＡＰおよびＢＳＳ内の他のＳＴＡが２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、および／またはその他のチャネル帯域幅の動作モードをサポートしている場合でも、１ＭＨｚモードをサポートする（例えば、サポートするだけの）ＳＴＡ（ＭＴＣ型のデバイスなど）のプライマリチャネルは１ＭＨｚ幅であってもよい。キャリア検知および／またはネットワーク割り当てベクトル（ＮＡＶ）設定は、プライマリチャネルのステータスに依存する場合がある。例えば、ＳＴＡ（１ＭＨｚの動作モードのみをサポート）がＡＰに送信しているために、プライマリチャネルがビジーである場合、周波数帯域の大部分がアイドル状態のままで利用可能とすることができたとしても、利用可能な周波数帯域全体がビジーであると見なされる場合がある。
【００４６】
米国では、８０２．１１ａｈで使用されることができる利用可能な周波数帯域は、９０２ＭＨｚ〜９２８ＭＨｚである。韓国では、利用可能な周波数帯域は９１７．５ＭＨｚ〜９２３．５ＭＨｚである。日本では、利用可能な周波数帯域は９１６．５ＭＨｚ〜９２７．５ＭＨｚである。８０２．１１ａｈで利用可能な合計帯域幅は、国コードに応じて６ＭＨｚ〜２６ＭＨｚである。
【００４７】
図１Ｄは、実施形態にかかるＲＡＮ１１３およびＣＮ１１５を示すシステム図である。上記のように、ＲＡＮ１１３は、ＮＲ無線技術を使用して、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１１３はまた、ＣＮ１１５と通信することもできる。
【００４８】
ＲＡＮ１１３は、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含むことができるが、ＲＡＮ１１３は、実施形態と一致性を保ちながら、任意の数のｇＮＢを含むことができることが理解されるであろう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃはそれぞれ、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つ以上のトランシーバを含むことができる。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装することができる。例えば、ｇＮＢ１８０ａ、１８０ｂは、ビームフォーミングを利用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに信号を送信し、および／またはｇＮＢ１８０ａ、ｇＮＢ１８０ｂ、１８０ｃから信号を受信することができる。したがって、ｇＮＢ１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および／またはＷＴＲＵ１０２ａから無線信号を受信することができる。実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、キャリアアグリゲーション技術を実装することができる。例えば、ｇＮＢ１８０ａは、複数のコンポーネントのキャリアをＷＴＲＵ１０２ａ（図示せず）に送信することができる。これらのコンポーネントキャリアのサブセットは、非ライセンススペクトル上にあってもよく、残りのコンポーネントキャリアは、ライセンススペクトル上にあってもよい。実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、協調マルチポイント（ＣｏＭＰ）技術を実装することができる。例えば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａおよびｇＮＢ１８０ｂ（および／またはｇＮＢ１８０ｃ）から協調送信を受信することができる。
【００４９】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルなヌメロロジに関連する送信を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。例えば、ＯＦＤＭシンボル間隔および／またはＯＦＤＭサブキャリア間隔は、異なる送信、異なるセル、および／または無線送信スペクトルの異なる部分に対して変化してもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔（ＴＴＩ）を使用して（例えば、様々な数のＯＦＤＭシンボルを含み、および／または持続する様々な長さの絶対時間）、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。
【００５０】
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成および／または非スタンドアロン構成でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成されることができる。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、他のＲＡＮ（例えば、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃなど）にもアクセスすることなく、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、１つ以上のｇＮＢ１８０ａ、１８０ｂ、１８０ｃをモビリティアンカーポイントとして利用することができる。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ライセンスのない帯域の信号を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信することができる。非スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮと通信／接続しながら、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信／接続することができる。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、１つ以上のｇＮＢ１８０ａ、１８０ｂ、１８０ｃおよび１つ以上のｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信するためのＤＣ原理を実装することができる。非スタンドアロン構成では、ｅＮｏｄｅ−Ｂ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティアンカーとして機能してもよく、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにサービスを提供するための追加のカバレッジおよび／またはスループットを提供してもよい。
【００５１】
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃのそれぞれは、特定のセル（図示せず）に関連付けられてもよく、無線リソース管理決定、ハンドオーバー決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアル接続、ＮＲとＥ−ＵＴＲＡ間のインターワーキング、ユーザプレーンデータのユーザプレーン機能（ＵＰＦ）１８４ａ、１８４ｂへのルーティング、コントロールプレーン情報のアクセスおよびモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂへのルーティングなどを処理するように構成されてもよい。図１Ｄに示されるように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインターフェースを介して互いに通信することができる。
【００５２】
図１Ｄに示されるＣＮ１１５は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂ、少なくとも１つのＵＰＦ１８４ａ、１８４ｂ、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂ、および場合によってはデータネットワーク（ＤＮ）１８５ａ、１８５ｂを含んでもよい。前述の要素のそれぞれは、ＣＮ１１５の一部として示されているが、これらの要素のいずれも、ＣＮオペレータ以外のエンティティによって所有および／または操作されることができることが理解されよう。
【００５３】
ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インターフェースを介してＲＡＮ１１３内の１つ以上のｇＮＢ１８０ａ、１８０ｂ、１８０ｃに接続されてもよく、制御ノードとして機能してもよい。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ネットワークスライシングのサポート（例えば、異なる要件を有する異なるＰＤＵセッションの処理）、特定のＳＭＦ１８３ａ、１８３ｂの選択、登録エリア、ＮＡＳシグナリングの終了、モビリティ管理などを担当してもよい。ネットワークスライシングは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃで利用されているサービスの種類に基づいて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用されることができる。例えば、超高信頼性の低遅延（ＵＲＬＬＣ）アクセスに依存するサービス、拡張された大規模モバイルブロードバンド（ｅＭＢＢ）アクセスに依存するサービス、マシン型通信（ＭＴＣ）アクセスのサービスなど、様々なユースケースに対して様々なネットワークスライスを確立することができる。ＡＭＦ１６２は、ＲＡＮ１１３と、ＬＴＥ、ＬＴＥ−Ａ、ＬＴＥ−Ａ  Ｐｒｏ、および／またはＷｉ−Ｆｉのような非３ＧＰＰアクセス技術などの他の無線技術を使用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供することができる。
【００５４】
ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介してＣＮ１１５内のＡＭＦ１８２ａ、１８２ｂに接続されることができる。ＳＭＦ１８３ａ、１８３ｂはまた、Ｎ４インターフェースを介してＣＮ１１５内のＵＰＦ１８４ａ、１８４ｂに接続されることができる。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択および制御し、ＵＰＦ１８４ａ、１８４ｂを通るトラフィックのルーティングを構成することができる。ＳＭＦ１８３ａ、１８３ｂは、ＷＴＲＵ  ＩＰアドレスの管理および割り当て、ＰＤＵセッションの管理、ポリシー実施およびＱｏＳの制御、ダウンリンクデータ通知の提供などの他の機能を実行することができる。ＰＤＵセッション型は、ＩＰベース、非ＩＰベース、イーサネットベースなどとすることができる。
【００５５】
ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インターフェースを介してＲＡＮ１１３内の１つ以上のｇＮＢ１８０ａ、１８０ｂ、１８０ｃに接続されることができ、これは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供することができる。ＵＰＦ１８４、１８４ｂは、パケットのルーティングおよび転送、ユーザプレーンポリシーの実施、マルチホームＰＤＵセッションのサポート、ユーザプレーンＱｏＳの処理、ダウンリンクパケットのバッファリング、モビリティアンカーの提供などの他の機能を実行することができる。
【００５６】
ＣＮ１１５は、他のネットワークとの通信を容易にすることができる。例えば、ＣＮ１１５は、ＣＮ１１５とＰＳＴＮ１０８との間のインターフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバー）を含んでもよく、またはそれと通信してもよい。さらに、ＣＮ１１５は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに、他のサービスプロバイダによって所有および／または運用される他の有線および／または無線ネットワークを含むことができる他のネットワーク１１２へのアクセスを提供することができる。一実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インターフェースおよびＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インターフェースを介して、ＵＰＦ１８４ａ、１８４ｂを介してローカルデータネットワーク（ＤＮ）１８５ａ、１８５ｂに接続されることができる。
【００５７】
図１Ａ〜図１Ｄおよび図１Ａ〜図１Ｄの対応する説明を考慮して、ＷＴＲＵ１０２ａ〜ｄ、基地局１１４ａ〜ｂ、ｅＮｏｄｅ−Ｂ１６０ａ〜ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ〜ｃ、ＡＭＦ１８２ａ〜ａｂ、ＵＰＦ１８４ａ〜ｂ、ＳＭＦ１８３ａ〜ｂ、ＤＮ１８５ａ〜ｂ、および／または本明細書に記載された任意の他のデバイス（複数可）のうちの１つ以上に関して、本明細書に記載された機能のうちの１つ以上の、または全ての機能は、１つ以上のエミュレーションデバイス（図示せず）によって実行することができる。エミュレーションデバイスは、本明細書に記載の機能の１つ以上、または全てをエミュレートするように構成された１つ以上のデバイスであってもよい。例えば、エミュレーションデバイスは、他のデバイスをテストするために、および／またはネットワークおよび／またはＷＴＲＵ機能をシミュレートするために使用されてもよい。
【００５８】
エミュレーションデバイスは、ラボ環境および／またはオペレータネットワーク環境で他のデバイスの１つ以上のテストを実装するように設計されることができる。例えば、１つ以上のエミュレーションデバイスは、通信ネットワーク内の他のデバイスをテストするために、有線および／または無線通信ネットワークの一部として完全にまたは部分的に実装および／または展開されながら、１つ以上または全ての機能を実行することができる。１つ以上のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として一時的に実装／展開されている間に、１つ以上、または全ての機能を実行することができる。エミュレーションデバイスは、テストの目的で別のデバイスに直接結合することができ、および／または無線経由（ｏｖｅｒ−ｔｈｅ−ａｉｒ）無線通信を使用してテストを実行することができる。
【００５９】
１つ以上のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として実装／展開されていない間に、全てを含む１つ以上の機能を実行することができる。例えば、エミュレーションデバイスは、１つ以上のコンポーネントのテストを実装するために、テストラボでのテストシナリオおよび／または展開されていない（例えば、テスト）有線および／または無線通信ネットワークで利用されてもよい。１つ以上のエミュレーションデバイスは、テスト機器であってもよい。ＲＦ回路（例えば、１つ以上のアンテナを含むことができる）を介した直接ＲＦ結合および／または無線通信は、データを送信および／または受信するためにエミュレーションデバイスによって使用されることができる。
【００６０】
本明細書に記載の図１Ａ〜図１Ｄに関連するものなどの無線システムでは、中央ノード（例えば、ｇＮＢ）は、ＷＴＲＵのセット、および中央ノードによって管理されることができるＷＴＲＵから中央ノードにトランスポートブロック（ＴＢ）を送信する機会にサービスを提供することができる。例えば、ｇＮＢは、個別の時間周波数リソースを各ＷＴＲＵに割り当て、各リソースを１つのＷＴＲＵに付与することにより、個々のＷＴＲＵアップリンク（ＵＬ）送信をスケジュールすることができる。ＵＬ送信のそのような配置は、許可ベースのＵＬ送信と称されることもある。あるいは、ｇＮＢは、１つ以上の時間周波数リソースの存在をアナウンスし、ＷＴＲＵのセットが各リソースを使用されることができるようにし、それにより、特定のＵＬ許可なしでアクセスすることを可能にする。
【００６１】
場合によっては、公平なチャネルアクセスを確保するために基地局（ｇＮＢなど）またはＷＴＲＵがライセンスのない無線チャネルにアクセスする前にリッスンビフォアトーク（ＬＢＴ）手順を実行する必要がある無線システムにおいて、ライセンスのない帯域が排他的または部分的に使用されることができる。ライセンスのないチャネルの規制要件に応じて、ＬＢＴの詳細は異なる場合がある。一般に、ＬＢＴ手順は、無線ノード（例えば、ｇＮＢまたはＷＴＲＵ）がメディアをリッスンし、メディアから検出されたエネルギレベルが閾値（規制当局によって指定された）を超える場合、固定および／またはランダムな持続時間間隔からなることができ、ｇＮＢまたはＷＴＲＵは、いかなる無線信号の送信も控え、そうでなければ、無線ノードは、持続時間（すなわち、ＬＢＴ手順の完了）の後にその所望の信号を送信することができる。ＬＢＴ持続時間間隔は、送信前に検出／検知に費やされた時間であり、これは、ＬＢＴ持続時間間隔が長いほど、送信を待機する時間が長くなることを意味する。
【００６２】
一般に、ＮＲ技術は、超信頼性の低遅延通信（ＵＲＬＬＣ）、大規模マシンタイプ通信（ｍＭＴＣもしくはＭＭＴＣ）、または拡張モバイルブロードバンド（ｅＭＢＢまたはＥＭＢＢ）通信などの多くのユースケースに適切とすることができる。ＭＭＴＣは、スマートメータリング、ロジスティクス、フィールドセンサやボディセンサなどのアプリケーションをサポートすることを目的とした、低コストで大量のバッテリ駆動のデバイス間の通信を可能にすることができる。ＵＲＬＬＣは、車両通信、産業用制御、ファクトリオートメーション、遠隔手術、スマートグリッドおよび公共安全アプリケーションなどのアプリケーションについて、デバイスおよびマシンが超信頼性、非常に低い遅延、高利用可能性で通信することを可能にすることができる。ＥＭＢＢは、データレート、遅延、モバイルブロードバンドアクセスのカバレッジなど、様々なパラメータの拡張に対処することができる。これらのユースケースの性能要件を満たすために、ＮＲは、特定のパラメータおよび機能を有することができる。
【００６３】
ＮＲは、１５ＫＨｚから２４０ＫＨｚの範囲のサブキャリア間隔で様々なヌメロロジを指定することができる。ベースサブキャリア間隔は、１５ＫＨｚとすることができ、他のヌメロロジは、表１にリスト化されているように、２の累乗のベースサブキャリア間隔でサブキャリア間隔の増加を有することができる。
【表１】
2021534623.tif 000003
【００６４】
ＮＲの物理ダウンリンク制御チャネル（ＰＤＣＣＨ）は、１つ以上の制御チャネル要素（ＣＣＥ）、集約レベルに応じて最大１６のＣＣＥから構成されることができる。制御リソースセット（ＣＯＲＥＳＥＴ）は、上位層パラメータＣＯＲＥＳＥＴ−ｆｒｅｑ−ｄｏｍによって与えられる周波数領域の
【数１】
2021534623.tif 000004
リソースブロック、および上位層パラメータＣＯＲＥＳＥＴ−ｔｉｍｅ−ｄｕｒによって与えられる時間領域の
【数２】
2021534623.tif 000005
シンボルからなることができる。ＰＤＣＣＨに関連するいくつかのパラメータは、以下のとおりとすることができる：グループ共通（ＧＣ）ＰＤＣＣＨ、ＲＲＣ構成、共通ＰＤＣＣＨ、全てのＷＴＲＵについてのシステム情報およびページング、ＰＢＣＨによって構成された残りのシステム情報（ＲＭＳＩ）、ＰＢＣＨによって構成された他のシステム情報（ＯＳＩ）。
【００６５】
ＮＲの物理アップリンク制御チャネル（ＰＵＣＣＨ）は、表２に示すように複数のフォーマットをサポートすることができる。
【表２】
2021534623.tif 000006
【００６６】
ＮＲフレームでは、スロット内のＯＦＤＭシンボルは、「ダウンリンク」（「Ｄ」と表示）、「フレキシブル」（「Ｘ」と表示）、または「アップリンク」（「Ｕ」と表示）に分類されることができる。この構造が表３に示されている。
【表３】
2021534623.tif 000007
【００６７】
いくつかの規制制度では、ライセンスのないチャネルの使用にはリッスンビフォアトーク（ＬＢＴ）手順が必須である場合があり、その結果、ライセンスあり支援アクセス（ＬＡＡ）、拡張ＬＡＡ（ｅＬＡＡ）、さらなるｅＬＡＡ（ｅＬＡＡ）などのプロトコルにＬＢＴカテゴリが存在する場合がある。ＬＡＡ／ｅＬＡＡにおいて採用されているＬＢＴカテゴリ４（ＣＡＴ  ４）スキームは、いくつかのユースケースについての好ましいスキームとすることができる。ＬＢＴ  ＣＡＴ  ４の手順は、ｅＮＢまたはｇＮＢ、場合によってはＷＴＲＵが、ライセンスのないチャネルで制御またはデータを送信したいときに開始される。次に、デバイスは、初期クリアチャネル評価（ＣＣＡ）を実行することができ、そこでは、チャネルが一定期間（すなわち、固定期間および疑似ランダム期間の合計である）アイドル状態であることがチェックされる。次に、チャネルの利用可能性は、ライセンスされていないチャネルの帯域幅全体で検出されたエネルギ（ＥＤ）のレベルを、規制当局によって決定されたエネルギ閾値と比較することによって判定されることができる。
【００６８】
チャネルが空いていると判定された場合、送信を続行することができる。そうでない場合、デバイスは、スロット付きランダムバックオフ手順を実行し、競合ウィンドウと称される指定された間隔から乱数が選択されることができる。バックオフカウントダウンが取得されることができ、チャネルがアイドル状態であることが確認され、バックオフカウンタがゼロになったときに送信が開始されることができる。ｅＮＢまたはｇＮＢがチャネルへのアクセスを取得した後、チャネル占有時間（ＣＯＴ）と称される期間だけ送信を許可することができるが、最大チャネル占有時間（ＭＣＯＴ）と称される限られた期間のみである。ランダムなバックオフと可変の競合ウィンドウサイズを使用するＣＡＴ４  ＬＢＴ手順は、Ｗｉ−Ｆｉや他のＬＡＡネットワークなどの他の無線アクセス技術（ＲＡＴ）との公平なチャネルアクセスおよび良好な共存を可能にすることができる。ＬＢＴカテゴリの例を以下に示す：カテゴリ１リッスン間隔なし；カテゴリ２固定期間のリッスン間隔（例えば、２５μ秒）；カテゴリ３固定競合ウィンドウによるランダムな持続時間のリッスン間隔；およびカテゴリ４競合ウィンドウの増加に伴うランダムな持続時間のリッスン間隔。
【００６９】
カテゴリ３のＬＢＴでは、送信機は、競合ウィンドウ内で乱数Ｎを引き出すことができる。競合ウィンドウのサイズは、Ｎの最小値および最大値によって指定されることができる。競合ウィンドウのサイズは固定とすることができる。乱数Ｎは、送信エンティティがチャネル上で送信する前に、チャネルがアイドル状態であると検知される期間を判定するために、ＬＢＴ手順において使用されることができる。
【００７０】
カテゴリ４のＬＢＴでは、送信機は、競合ウィンドウ内で乱数Ｎを引き出すことができる。競合ウィンドウのサイズは、Ｎの最小値および最大値によって指定されることができる。送信エンティティは、乱数Ｎを引き出すときに競合ウィンドウのサイズを変更することができる。乱数Ｎは、送信エンティティがチャネル上で送信する前に、チャネルがアイドル状態であると検知されることができる持続時間を判定するためにＬＢＴ手順において使用されることができる。
【００７１】
本明細書で論じられるように、キャリア帯域幅部分（ＢＷＰ）は、所与のキャリア上の所与のヌメロロジの共通リソースブロックの連続サブセットから選択される、物理リソースブロックの連続セットとすることができる。
【００７２】
ＷＴＲＵは、単一のダウンリンクキャリアＢＷＰが所与の時間にアクティブである状態で、ダウンリンク内に最大４つのキャリアＢＷＰで構成されることができる。ＷＴＲＵは、アクティブＢＷＰの外部でＰＤＳＣＨ、ＰＤＣＣＨ、ＣＳＩ−ＲＳ、またはＴＲＳを受信することを予想されない場合がある。ＷＴＲＵは、単一のアップリンクキャリアＢＷＰが所与の時間にアクティブである状態で、アップリンク内に最大４つのキャリアＢＷＰで構成されることができる。ＷＴＲＵが補助アップリンクによって構成されている場合、ＷＴＲＵは、単一の補助アップリンクキャリアＢＷＰが所与の時間にアクティブである状態で、補助アップリンクにおいて最大４つのキャリアＢＷＰによってさらに構成されることができる。ＷＴＲＵは、アクティブＢＷＰの外部にＰＵＳＣＨまたはＰＵＣＣＨを送信することはできない。
【００７３】
ＮＲでのＨＡＲＱ動作の場合、３ビットのＰＤＳＣＨ−ｔｏ−ＨＡＲＱタイミングインジケータフィールドによって示される柔軟なＨＡＲＱフィードバックタイミングが存在することができる。ＰＤＳＣＨとＰＵＣＣＨ／ＵＣＩの対応するフィードバックとの間には１対１のマッピングが存在することができる。Ｋ１と称されるＰＤＳＣＨとＰＵＣＣＨとの間のスロットタイミングは、ＤＣＩの３ビットフィールドで示されることができ、８つのＲＲＣ構成値にインデックスを付ける。ＤＣＩフォーマット１−１では、これらの８つの値は、ＲＲＣで構成された遅延値にマッピングされることができる（すなわち、マッピングは、｛０００、・・・、１１１｝−＞ＲＲＣで定義された値である）。ＤＣＩフォーマット１−０では、これらの８つの値は、遅延｛１、２、・・・、８｝のセットにマッピングされる。
【００７４】
ＮＲは、小さな処理遅延をサポートすることができるが、同じスロット内でフィードバックを提供するほど小さくはない（例えば、機能１  ＷＴＲＵの場合）。例えば、サブキャリア間隔が３０ＫＨｚの場合、ＰＤＳＣＨの終了からＰＵＣＣＨの開始までのＬ１処理遅延は、最低１０個のＯＦＤＭシンボルとすることができる。Ｎ１は、ＰＤＳＣＨの終了からＰＵＣＣＨの開始までのＯＦＤＭシンボルの数とすることができる。フロントロードされたＤＭＲＳは、ＳＣＳ＝３０ｋＨｚおよび６０ｋＨｚの場合にのみ１０および１７シンボルとすることができ、フロントロード＋追加のＤＭＲＳは、ＳＣＳ＝３０ｋＨｚおよび６０ｋＨｚの場合に１３および２０シンボルとすることができる。Ｎ２は、ＰＤＣＣＨの終了（すなわち、ＵＬ許可）からＰＵＳＣＨの開始までのＯＦＤＭシンボルの数とすることができる。周波数ファーストのＲＥマッピングは、ＳＣＳ＝３０ｋＨｚおよび６０ｋＨｚの場合に１２および２３シンボルとすることができる。
【００７５】
ＮＲは、ＰＵＣＣＨリソースおよび時間の動的なインジケーションをサポートすることができ、複数のＰＤＳＣＨのＨＡＲＱフィードバックは、単一のＨＡＲＱコードブックを使用して送信されることができる。動的にスケジュールされた送信の場合、ＰＵＣＣＨリソースおよび時間は、スケジューリングＤＣＩに示されることができる。ＰＤＳＣＨとＰＵＣＣＨとの間の関連付けは、スケジューリングＤＣＩに示されているＰＵＣＣＨリソースおよび時間に基づくことができ、スケジューリングＤＣＩが同じＰＵＣＣＨリソースおよび時間を示している全てのＰＤＳＣＨのＨＡＲＱフィードバックは、ともに報告されることができる。含めることができる最新のＰＤＳＣＨフィードバックは、ＷＴＲＵがＨＡＲＱフィードバックを準備するために必要な処理時間によって制限されることができる。
【００７６】
ＮＲは、半静的または動的コードブックを使用して、１つのＰＵＣＣＨに複数のＨＡＲＱプロセスのフィードバックを集約することができる。
【００７７】
半静的ＮＲフィードバックアグリゲーションの場合、ＡＣＫコードブックのサイズは、セル全体のＴＢの最大数と、同じスロットにＡＣＫを有するように構成されることができるＰＤＣＣＨモニタリングの機会とに基づいて決定されることができる。このモードは、動的モードよりもＤＣＩの検出漏れや誤検出に対して堅牢とすることができるが、ＡＣＫフィードバックのビット数が増えるという犠牲を払う可能性がある。例えば、８つのＣＢＧと１６のＨＡＲＱプロセスでは、セルあたり１２８ビットが送信され、単一ＴＢの場合でもＨＡＲＱフィードバックを通知する。
【００７８】
動的ＮＲフィードバックアグリゲーションの場合、ＨＡＲＱプロセスのセットは、フィードバックを報告する必要がある各ＨＡＲＱプロセスに対して動的に決定されることができる。一般に、ＨＡＲＱコードブックのサイズは、連続して受信された多数のＤＣＩの内容に基づいて決定されることができ、これに基づいて、ｇＮＢは、コードブック属性をＷＴＲＵに効率的に伝達する。ダウンリンク割り当てインジケータ（ＤＡＩ、２ビット）は、報告する必要のあるＨＡＲＱプロセスの数を示すことができ、ＤＡＩは、欠落した／誤ったＤＣＩに対して堅牢にすることができる。ＨＡＲＱコードブックにインデックスを付けるために、各スケジューリング割り当てのＤＣＩは、ＨＡＲＱコードブックに含まれている可能性のある現在の割り当てを含む以前の全てのＤＬ割り当てをカウントするＤＡＩを含むことができる。最新のＤＬ割り当てのＤＣＩに含まれるＤＡＩは、ＨＡＲＱコードブックのサイズを決定することができる。ＷＴＲＵが一部のＤＬ割り当てを欠落した場合であっても、ＤＡＩがラップアラウンドしない限り、ＨＡＲＱコードブックをなおも正しくアドレス指定することができる。ＤＬスケジューリングＤＣＩのＤＡＩは、直前のＤＬスケジューリングＤＣＩと比較して１つによるステップとすることができ、差が１よりも大きい場合、ＰＤＣＣＨが欠落していることを示すことができる。
【００７９】
ＮＲでの許可なしのＵＬ送信の１つ以上のＨＡＲＱ手順が存在することができる。構成済み許可とも称される許可なし（ＧＦ）ＵＬ送信、および関連するＨＡＲＱ手順は、ＮＲにいくつかのタイプおよび属性を有することができる。タイプＩは、ＷＴＲＵがＧＦリソースにアクセスするように構成されているＲＲＣ構成を介してのみとすることができる。タイプＩＩは、ＲＲＣ構成およびＤＣＩシグナリングによるものとすることができ、ＷＴＲＵは、ＧＦリソースにアクセスするように構成され、ＧＦリソースへのアクセスは、ＤＣＩシグナリングによってアクティブ化、非アクティブ化、または再アクティブ化される。ＧＦ  ＵＬ送信は、スロットベースまたはミニスロットベースとして実行されるように構成されることができる。
【００８０】
ＨＡＲＱ手順の１つの属性は、確認応答、ＨＡＲＱフィードバック、および再送信が以下のように行われる場合とすることができる：ＧＦ送信の失敗後のＴＢの許可ベースの再送信；および、ＷＴＲＵによって暗黙的な確認応答インジケーションが受信された場合は早期に終了する、連続するＧＦリソース全体で、最大Ｋ＝８回の繰り返しによるＴＢの許可なし送信。
【００８１】
暗黙的なＨＡＲＱ属性は、明示的なＨＡＲＱ−ＡＣＫフィードバックがないこと、およびＵＬ  ＨＡＲＱプロセスＩＤを明示的に示すＤＣＩ形式のＮＤＩフィールドを使用して暗黙的とすることができることとすることができる。また、暗黙的なＨＡＲＱ属性は、ＨＡＲＱ  ＩＤが選択されたリソースからのものである場合、ＨＡＲＱプロセスＩＤがフロア（Ｘ／ＵＬ−ＴＷＧ−周期性）ｍｏｄ  ＵＬ−ＴＷＧ−ｎｕｍｂＨＡＲＱｐｒｏｃに等しい場合とすることができ、ここで、Ｘ＝（ＳＦＮ＊ＳｌｏｔＰｅｒＦｒａｍｅ＊ＳｙｍｂｏｌＰｅｒＳｌｏｔ＋Ｓｌｏｔ＿ｉｎｄｅｘ＿Ｉｎ＿ＳＦ＊ＳｙｍｂｏｌＰｅｒＳｌｏｔ＋Ｓｙｍｂｏｌ＿Ｉｎｄｅｘ＿Ｉｎ＿Ｓｌｏｔ）であり、Ｘは、繰り返しバンドルの開始のシンボルインデックスである。また、暗黙的なＨＡＲＱ属性は、ＲＲＣ構成（ＲＶサイクリングおよびＲＶ０反復を含む）によって決定されるＨＡＲＱ  ＲＶシーケンスとすることができる。
【００８２】
ＨＡＲＱはまた、定期的とすることができ、各期間で複数のＴＸ機会が繰り返される。さらに、ＨＡＲＱ  ＴＸの機会は、サポートされることができる｛０，２，３，１｝、｛０，３，０，３｝、および｛０，０，０，０｝などの特定のＲＶ順序に関連付けられることができる。繰り返しの初期ＴＸは、ＲＶ０で始まることができるが、それ以外の場合は、タイミングは柔軟とすることができる。
【００８３】
ライセンスのないＮＲ（ＮＲ−Ｕ）環境では、ＮＲ−Ｕデバイスがライセンスのないチャネルにアクセスしようとすると、チャネルアクセスについてＲＡＴ間デバイスおよびＲＡＴ内デバイスと競合する可能性がある。ＲＡＴ間デバイスのタイプと密度は、ライセンスのないチャネルに依存することができ、ＲＡＴは、Ｗｉ−Ｆｉ、ＬＴＥ  ＬＡＡ、ブルートゥースなどとすることができる。ＲＡＴ内デバイスは、他のＮＲ−Ｕデバイス（例えば、ＷＴＲＵまたはｇＮＢ）とすることができる。例えば、ＮＲ−Ｕ  ＷＴＲＵの場合、ＲＡＴ内デバイスは、同じｇＮＢに接続されている他のＮＲ−Ｕ  ＷＴＲＵとすることができるか、または同じｇＮＢに関連付けられていないＮＲ−Ｕ  ｇＮＢまたはＷＴＲＵとすることができる。ライセンスのないチャネルにアクセスしようとすると、ＮＲ−Ｕ  ＷＴＲＵまたはｇＮＢは、ＲＡＴ間およびＲＡＴ内デバイスとの公正な競争と共存が必要になる場合がある。
【００８４】
公正な競争と共存を確保するために、一部の規制ドメインでは、無線ノードがライセンスのないチャネルにアクセスしたい場合、ノードは、最初に一定期間リッスンビフォアトーク（ＬＢＴ）手順を実行する必要がある場合があり、閾値を超えるエネルギが検出されない場合、無線ノードは、最大期間まで無線チャネルに送信することが可能にされることができることが必要とされる場合がある（すなわち、規則）。したがって、ＮＲ−Ｕノードの場合、同様のＬＢＴ手順が予想されることができる。
【００８５】
図２は、ＷＴＲＵがＬＢＴを正常に完了することができない場合の例示的な送信図である。本明細書で論じられるように、任意の送信図について、時間２０１は、いくつかの時間単位（例えば、スロット）を有する送信によって、横軸に示されることができる。スロットは、時間的にスロットｎに関連してラベル付けされることができる。この例では、２１０において、ＷＴＲＵは、スロットｎ−２およびスロットｎ−１においてＰＤＣＣＨのＤＬを受信することができ、これは、スロットｎ＋２におけるＰＵＣＣＨのＵＬリソースを示すことができる。２１１において、ＷＴＲＵは、スロットｎ＋２においてスケジュールされたＰＵＣＣＨのＬＢＴを正常に完了することができない場合があるため、スロットｎ−２およびｎ−１において伝送されるＴＢについて準備されたＨＡＲＱコードブックの送信を控える必要がある場合がある。したがって、この場合のＷＴＲＵは、送信が受信エンティティに影響を与える可能性のあるタイミング依存性を有する場合であっても、送信を控える必要がある場合がある。例えば、ＷＴＲＵがＨＡＲＱコードブックから構成されるＰＵＣＣＨを送信することになっており、ＬＢＴに障害が発生した場合、ＷＴＲＵは、それを送信するのを控える必要がある場合がある。２１２において、ＮＲ  ｇＮＢは、ＷＴＲＵが送信するＨＡＲＱコードブックを準備した先行ＰＤＳＣＨにおける関連ＴＢがＷＴＲＵによって正しく受信されなかったと想定する場合があり、ｇＮＢは、次の送信においてそれらを再送信する必要がある場合がある（例えば、次のスロットｎ−２およびｎ−１）。
【００８６】
図２は、ＷＴＲＵがスケジュールされたＰＵＣＣＨリソースのＬＢＴプロセスに失敗したために、ＮＲ−Ｕ  ｇＮＢがＨＡＲＱコードブックを受信しない場合があることを示している。この問題への１つのアプローチは、ＰＵＣＣＨ送信の複数の機会を許可することとすることができる（例えば、ＤＣＩでアナウンスされる）。
【００８７】
図３は、ＷＴＲＵがＰＵＣＣＨに対して複数の機会を有することができる例示的な送信図である。時間３０１は、スロットなどのいくつかの時間単位によって横軸に示されている。スロットには、時間内のスロットｎを基準にしてラベルが付けられる。この例では、３１０において、ＷＴＲＵは、ＰＤＣＣＨのＤＬを受信することができ（すなわち、スロットｎ−２およびスロットｎ−１において）、これは、スロットｎ＋２およびスロットｎ＋４におけるＰＵＣＣＨを示すことができる。３１１において、ＷＴＲＵは、スロットｎ＋２の最初に示された機会で送信を試みることができるが、ＬＢＴに失敗するため、次の機会（すなわち、スロットｎ＋４）まで待機する必要がある。３１３において、ＷＴＲＵは、再試行し、スロットｎ＋４のＬＢＴを正常に完了し、ＰＵＣＣＨで送信する。
【００８８】
一般に、リソースの複数の機会は、時間的に分散されて、複数のスロットにまたがってスケジュールされることができるか、またはそれらは、同じ１つまたは２つの連続するスロットであるがそれぞれが異なる２０ＭＨｚ  ＢＷＰ内でスケジュールされることができる（すなわち、それぞれが異なる２０ＭＨｚのライセンスなしチャネル内にある）。したがって、ＮＲにおいてスカラーであるＰＤＳＣＨ−ｔｏ−ＨＡＲＱ−タイミングインジケータフィールドは、複数の値を伝送することができる。ＬＢＴが成功した場合、ＷＴＲＵは、第１のスロットを選択することができ、それ以外の場合は、次の機会などに進む。図３の例では、ＷＴＲＵは、スロットｎ＋２において最初にスケジュールされたＰＵＣＣＨについてＬＢＴを正常に完了することができず、スロットｎ＋４において２番目にスケジュールされたＰＵＣＣＨを待機し、そこでＬＢＴを正常に完了し、スロットｎ−２およびｎ−１において伝送されるＴＢ（すなわち、ＰＤＳＣＨ）について準備されたＨＡＲＱコードブックを送信する。スケジュールされたＰＵＣＣＨのセットは、ＰＤＳＣＨ−ｔｏ−ＨＡＲＱタイミングインジケータのセットで示されることができる。
【００８９】
しかしながら、複数の機会のアプローチは、欠点を有する場合がある。ＬＢＴが最初の機会（例えば、図３のスロットｎ＋２）において失敗したときの次の機会（例えば、図３のスロットｎ＋４）におけるＬＢＴ成功の可能性は、チャネル占有コヒーレンス時間（ＣＯＣＴ）と称されることができ、ライセンスのないチャネルで動作するＲＡＴ間およびＲＡＴ内のデバイスの数と、それぞれが参加するトラフィックのタイプとに依存することができる。例えば、帯域内のアクティブなライセンスのないデバイスのトラフィックのほとんどがビデオトラフィックである場合、ＣＯＣＴは大きくなる可能性があり、ＬＢＴが失敗した後にＬＢＴが成功する可能性は、２番目のＬＢＴ観測が最初の観測よりも長い場合にのみ大きくなる可能性がある。ＣＯＣＴが大きい場合、同じＣＯＴ内で複数のＰＵＣＣＨリソースをスケジュールすることは効果的でない場合があり、ＣＯＴが確立されているカテゴリに応じて、５ミリ秒または１０ミリ秒未満の期間を有する場合がある。ｇＮＢは、複数のＰＵＣＣＨリソースを割り当てる必要があるため、各ＷＴＲＵに複数のＰＵＣＣＨ機会を割り当てることは無駄になる可能性がある（すなわち、ＰＵＣＣＨに使用されるリソースの数が２倍または３倍になる可能性がある）。
【００９０】
さらに、ＷＴＲＵが機会のウィンドウ内でＰＵＣＣＨの送信に失敗した場合、ＬＢＴが複数のＰＵＣＣＨリソースで失敗した場合でも、ｇＮＢは、後にフィードバックを要求する柔軟性をなおも有しない場合がある。ＮＲ−ＵのＨＡＲＱでは、最初にＮＲ手順に固執することができ、この手順では、各ＰＤＣＣＨにＰＵＣＣＨ送信用のスロットが１つのみ示される。しかしながら、ｇＮＢが予想されるＰＵＣＣＨを受信しない場合、ｇＮＢは、ＷＴＲＵが以前に送信されなかったＨＡＲＱフィードバックを、場合によっては追加のＨＡＲＱフィードバックとともに送信する別の機会を有するように（すなわち、ＰＵＣＣＨ送信用の複数のスロットが示されることができる）、ＰＵＣＣＨに補足の送信機会、または複数の機会を提供することができる。さらに、ＷＴＲＵがＬＢＴを完了してＨＡＲＱフィードバックを送信した場合であっても、干渉または衝突のためにｇＮＢが正しく検出しなかった可能性があり、これは、ｇＮＢとＷＴＲＵとの間の不整合につながる可能性がある。
【００９１】
ＮＲ−Ｕ状況でのＰＵＣＣＨ送信の効率的なリソーススケジューリングは、これらの問題に対処することができる。ＷＴＲＵには、オーバーヘッドを削減するために、各ＷＴＲＵに割り当てられる排他的リソースと複数のＷＴＲＵ間で共有される非排他的リソースとを割り当てることができる。非排他的リソースは、ＷＴＲＵ間の衝突の可能性を減らす方法で割り当てることができる。これを実装するために、いくつかの排他的なＰＤＳＣＨ−ｔｏ−ＨＡＲＱタイミングインジケータを各ＷＴＲＵに割り当てることができ、複数のＷＴＲＵ間で共有される１つ以上の非排他的ＰＤＳＣＨ−ｔｏ−ＨＡＲＱタイミングインジケータを割り当てることができる。ｇＮＢは、非排他的ＰＤＳＣＨ−ｔｏ−ＨＡＲＱタイミングインジケータを使用するＷＴＲＵを優先することができる。
【００９２】
非排他的リソースを管理するためのいくつかのＷＴＲＵの優先順位付けを実装するために、ＰＤＳＣＨ−ｔｏ−ＨＡＲＱタイミングインジケータは、優先度パラメータ（例えば、ＷＴＲＵがそのＨＡＲＱフィードバックを送信するためにメディアにアクセスする優先度を決定するチャネルアクセス優先度クラス）を含むことができる。ｇＮＢは、特定の非排他的リソースのＷＴＲＵに優先度パラメータを明示的に割り当てることができる。これは、静的に（すなわち、ＲＲＣ構成によって）、半静的に（すなわち、ＲＲＣ構成とＤＣＩとの組み合わせによって）、または動的に（すなわち、ＤＣＩによって）割り当てられることができる。
【００９３】
別のアプローチでは、ＷＴＲＵは、特定の非排他的リソースに対してそのアクセス優先度クラスを自律的に選択することができる。例えば、ＷＴＲＵは、発生した可能性のある非排他的リソース障害の数に基づいて優先度パラメータを選択することができる。あるいは、ＷＴＲＵは、割り当てられている排他的および非排他的リソースの数に基づいて優先度パラメータを選択することができる。このため、Ｎ＝Ｎ１＋Ｎ２  ＨＡＲＱリソースを有するＷＴＲＵを想定することができ、ここで、Ｎ１は、排他的リソースを表し、Ｎ２は、非排他的リソースを表す。一例では、Ｎ２のアクセス優先度クラスは固定され、ＷＴＲＵまたはトラフィックタイプに依存することができる。別の例では、アクセス優先度クラスは、Ｎ２の増加に伴って変化してもよい（例えば、Ｎ２，１＞＝Ｎ２，１＞＝Ｎ２，３であり、Ｎ２、ｘは、ｘ番目のＮ２リソースである）。別の例では、アクセス優先度クラスは、Ｎ１＝３およびＮ２＝１を有するＷＴＲＵがＮ１＝１およびＮ３＝３を有するＷＴＲＵよりも低い優先度を有することができる場合など、Ｎ１およびＮ２の値に依存することができる。
【００９４】
図４は、ＷＴＲＵが非排他的ＰＵＣＣＨの優先順位を有することができる送信図の例である。時間４０１は、横軸に示され、いくつかのｎ増分に対して時間増分（例えば、スロット）に分割されることができる。本明細書で論じられる図のいずれにおいても、「スペース」は、純粋にデモンストレーションの目的で図の切れ目を指すことができ、欠落したまたは非連続的な時間増分を示すことを意図せず、単に図示の例のスペースを節約することを意図している。さらに、スペースは、特に明記しない限り、スペースの前後のスロットと同じまたは類似することができる。
【００９５】
図４の例では、４１０において、ＷＴＲＵ１は、スロットｎ＋２における排他的ＰＵＣＣＨリソースのインジケーションを伴うスロットｎ−２におけるＰＤＣＣＨ、および優先度パラメータが１を有するスロットｎ＋４における非排他的ＰＵＣＣＨスロットのインジケーションを受信することができる。ＷＴＲＵ１は、スロットｎ−２においてＰＤＳＣＨを受信し、それを復号することができ、それに対して、ＨＡＲＱフィードバックを送信する必要がある場合がある。４１１において、ＷＴＲＵ２は、優先度パラメータ２により、スロットｎ−１においてＰＤＣＣＨ、スロットｎ＋３において排他的ＰＵＣＣＨリソースのインジケーション、およびスロットｎ＋４において非排他的ＰＵＣＣＨスロットのインジケーションを受信することができる。この例では、ＷＴＲＵ２は、ＷＴＲＵ１よりも低い優先度を有することができる。ＷＴＲＵ２は、スロットｎ−１においてＰＤＳＣＨを受信し、それを復号することができ、そのために、ＨＡＲＱフィードバックを送信する必要がある場合がある。
【００９６】
この例の目的のために、ｇＮＢは、割り当てられたＰＵＣＣＨ（すなわち、それぞれスロットｎ＋２またはｎ＋３）においてＷＴＲＵ１またはＷＴＲＵ２からの送信を受信しなかったと想定されることができる。例えば、スロットｎ＋２において、ＷＴＲＵ１は、失敗したＰＵＣＣＨにおいて送信するためにＬＢＴを実行した可能性があるため、ＷＴＲＵ１は、ＰＵＣＣＨにおいて送信を送信することができず、スロットｎ＋４まで待機する必要がある。同様に、スロットｎ＋３において、ＷＴＲＵ２は、失敗したＬＢＴを実行した可能性があり、ＷＴＲＵ２は、スロットｎ＋４まで待機する必要がある。
【００９７】
双方のＷＴＲＵの最初のＰＵＣＣＨ試行が失敗した結果、４１２において、ＷＴＲＵ１およびＷＴＲＵ２は、スロットｎ＋４におけるＰＵＣＣＨリソースをめぐって競合する可能性があり、ＷＴＲＵ２のＬＢＴ期間は、ＷＴＲＵ１のものよりも統計的に長い値に設定され、それにより、ＬＢＴ手順にしたがって送信するまでの待機時間が短いため、ＷＴＲＵ１が送信用のリソースを取得する可能性が高くなる（すなわち、ＷＴＲＵ１は、より高い優先度を有する）。ＷＴＲＵ１が優先されるため、ＨＡＲＱフィードバックを正常に送信することができる場合がある。
【００９８】
場合によっては、ｇＮＢ側での衝突／干渉により、ｇＮＢは、ＷＴＲＵから送信されたＨＡＲＱフィードバックを検出することができない場合がある。ＬＢＴの失敗や欠落したＵＣＩ送信など、ｇＮＢが送信を受信することができない理由は、ｇＮＢ側では区別することができない場合がある。ＰＤＳＣＨと対応するフィードバックとの間の時間関連のために、ｇＮＢが事前定義された時間位置においてフィードバックを検出することができない場合、ｇＮＢは、その後、対応する全てのＰＤＳＣＨを再送信することができる。これは、ライセンスチャネルのＮＲ動作で発生する可能性があるが、ＮＲ−Ｕでは、干渉が大きく変動し、隠れノードなどによるｇＮＢ側での衝突の可能性があるために発生する可能性が高くなる（例えば、ＷＴＲＵ側では検出することができない）。これは、先行するＰＤＳＣＨのＨＡＲＱコードブックがｇＮＢによって正常に受信されたという点で、ｇＮＢとＷＴＲＵとの間に不整合を発生させ、ＷＴＲＵがＨＡＲＱコードブックを早期にフラッシュするリスクが生じる可能性がある。
【００９９】
図５は、ＷＴＲＵがＬＢＴを正常に完了したが、ｇＮＢがＰＵＣＣＨを検出することができなかった例示的な送信図である。時間は、スロットの増分において横軸５０１に示されることができる。５１０において、ＷＴＲＵは、スロットｎ＋２におけるＰＵＣＣＨについてスロットｎ−２およびｎ−１においてインジケーションを受信することができ、各スロットにおいてＰＤＳＣＨを受信して復号することもできる。５１１において、ＷＴＲＵは、スロットｎ＋２においてスケジュールされたＰＵＣＣＨのＬＢＴを正常に完了し、ＨＡＲＱフィードバックを送信することができるが、ｇＮＢは、受信側での干渉またはエラーのために送信を検出することができないことがある。５１２において、ｇＮＢは、スロットｎ＋６においてスケジュールされたＰＵＣＣＨが補足ＰＵＣＣＨであることを示すＷＴＲＵへの次のＰＤＣＣＨをスロットｎ＋４において送信することができ、これは、スロットｎ＋４のＰＤＳＣＨに関連付けられているコードブックに加えて、スロットｎ＋２において受信されるはずだった以前にスケジュールされたＰＵＣＣＨのＨＡＲＱコードブックを、スロットｎ＋６におけるＰＵＣＣＨにおいて送信するようにＷＴＲＵへのインジケーションを含むことができる。５１３において、ＷＴＲＵは、ＬＢＴを正常に完了し、全てのＨＡＲＱコードブックとともにスロットｎ＋６の補足割り当てリソースにおいてＰＵＣＣＨを送信することができる。
【０１００】
図５の例とは異なり、予想されるＰＵＣＣＨを受信しないｇＮＢのこの問題は、単一のチャネル占有時間（ＣＯＴ）または２つのＣＯＴなどにわたって、連続した試行で発生する可能性がある。例えば、ｇＮＢは、ＰＤＳＣＨリソースの第１のセットに関してＨＡＲＱコードブックを伝送する予想されるＰＵＣＣＨを受信していない可能性があり、ｇＮＢは、ＨＡＲＱコードブック送信用の第１の補足ＰＵＣＣＨリソースを与えることができるが、補足リソースの時間まで、ｇＮＢは、ＷＴＲＵに対してより多くのＰＤＳＣＨ（すなわち、ＰＤＳＣＨリソースの第２のセット）をスケジュールし続けることができ、したがって、以前のＨＡＲＱコードブックに加えて、追加のＨＡＲＱフィードバックまたは追加のＨＡＲＱコードブックが存在することができる。ＷＴＲＵおよびｇＮＢは、ＷＴＲＵによって送信される必要のあるＨＡＲＱコードブックの数と種類について同じ理解を有する必要があり、そのような共通の理解は、ＤＣＩを短く保つ少なくとも所定量の制御情報によって達成される必要がある。第１の補足ＰＵＣＣＨリソースの間でさえも、ＷＴＲＵは、集約されたＨＡＲＱフィードバックを送信することができないか（例えば、ＬＢＴ障害のため）、またはｇＮＢは、コードブックを正常に検出することができず、その後、ｇＮＢは、第２の補足ＰＵＣＣＨリソースを割り当てることによってＷＴＲＵに別の機会を与えることができるが、補足リソースのときまで、ｇＮＢは、ＷＴＲＵのために別のＰＤＳＣＨリソースのセット（すなわち、ＰＤＳＣＨリソースの第３のセット）をスケジュールすることができる。ＷＴＲＵは、ＰＤＳＣＨリソースの３つのセット全てにわたってＨＡＲＱフィードバックを集約し、第２の補足ＰＵＣＣＨリソース中にそれらを送信することがここで予想される場合がある。この状況は、同じＣＯＴ中に集約されたＨＡＲＱコードブックをスケジュールする機会がなくなるまで続くことができ、これは、それらが次のＣＯＴに延期されることができることを意味する。また、ｇＮＢが補足送信の機会を送信する状況では、ｇＮＢによって送信される予想コードブックサイズとＷＴＲＵによって送信される実際のコードブックサイズとの間に不整合が生じる可能性がある。
【０１０１】
これを解決するために、ＤＣＩの追加フィールドは、次のＰＵＣＣＨが「補足送信」であることをＷＴＲＵに示すことができ、ＷＴＲＵが前のＰＵＣＣＨ送信において行ったようにコードブックサイズを計算することを可能にする。拡張ダウンリンク割り当てインジケータ（ＥＤＡＩ）は、本明細書において説明するＮＲ−Ｕ状況の追加フィールドとすることができる。ＤＣＩのこのフィールドは、スケジュールされたＰＵＣＣＨの属性を伝送することができる。このフィールドは、連続するダウンリンク割り当てインジケータ（ＤＡＩ）を有するＰＤＳＣＨリソースのセットまたはグループを処理し、それらをグループとしてラベル付けすることができる。ＷＴＲＵがＰＤＳＣＨリソースの現在のセットまたはグループ内のＴＢのＨＡＲＱコードブックを形成すると予想される場合、ＥＤＡＩフィールドは、０の値を有することができる。ＷＴＲＵがＰＤＳＣＨリソースの現在のセットまたはグループ内のＴＢ、および直前のセットまたはＰＤＳＣＨリソースのグループ内のＴＢのＨＡＲＱコードブックを形成すると予想される場合、ＥＤＡＩフィールドは、１の値を有することができる。ＷＴＲＵがＰＤＳＣＨリソースの現在のセットまたはグループ内のＴＢ、および直前の２つのセットまたはＰＤＳＣＨリソースのグループ内のＴＢのＨＡＲＱコードブックを形成すると予想される場合、ＥＤＡＩフィールドは、２の値を有することができる。ＷＴＲＵがＰＤＳＣＨリソースの現在のセットまたはグループ内のＴＢ、および直前の３つのＰＤＳＣＨリソースのセットまたはグループ内のＴＢのＨＡＲＱコードブックを形成すると予想される場合、ＥＤＡＩフィールドは、３の値を有することができる。したがって、ＷＴＲＵがＰＤＳＣＨリソースの現在のセットまたはグループ内のＴＢ、およびＰＤＳＣＨリソースの直前のセットまたはグループ内のＹ内のＴＢのＨＡＲＱコードブックを形成すると予想される場合、ＥＤＡＩフィールドは、値Ｙを有することができる。本明細書で説明するように、この一般規則は、ＥＤＡＩフィールドの値が現在の時間／グループのセットおよび以前の時間／グループのセットに関連することができるように、いくつかの他の時間単位またはグループがＴＢの代わりに使用される他の状況に適用可能とすることができる（例えば、送信、ＣＯＴなど）。このメカニズムでは、単一のＤＣＩは、同じＰＵＣＣＨ内の１つ以上のＰＤＳＣＨグループにおいて送信されることができる全てのＰＤＳＣＨに対してＨＡＲＱ  ＡＣＫフィードバックを要求することができる。
【０１０２】
ＥＤＡＩがゼロ以外であり、ＷＴＲＵが２つ以上の以前に準備されたＨＡＲＱコードブックを現在のコードブックと集約しようとすると、ＷＴＲＵは、ｇＮＢがコードブックを区別および解析することができるように、１つのコードブックのビットストリームと次のコードブックのビットストリームとの間にフィールドを挿入することができ、このフィールドは、指定されたビット幅（例えば、２または４）を有するＨＡＲＱコードブックデリミタとして示されることができる。複数のＨＡＲＱコードブックを集約する場合、ＷＴＲＵは、各ＨＡＲＱコードブックの後にＨＡＲＱコードブックデリミタを挿入することができる。一例では、ＷＴＲＵが、連続する値を有しないＥＤＡＩ属性を有する連続するＰＤＣＣＨを受信した場合、ＷＴＲＵは、連続しないＥＤＡＩ値につながる１つ以上のＰＤＣＣＨのセットを検出しなかったと推測することができる。そのような場合、ＷＴＲＵは、欠落しているＥＤＡＩ値ごとに１つのＨＡＲＱコードブックデリミタを挿入することができる。例えば、ＷＴＲＵが値ＥＤＡＩ＝０のＰＤＣＣＨのセットを受信した後、次のスロットのセットまたは次のＣＯＴでさえも、ＷＴＲＵは、値ＥＤＡＩ＝２のＰＤＣＣＨのセットを受信する。これは、ＷＴＲＵがＥＤＡＩ＝１の１つ以上のＰＤＣＣＨを欠落したことを示すことができ、したがって、ＷＴＲＵは、ＥＤＡＩ＝１のＰＤＣＣＨ中に送信されたＴＢの数を認識していない可能性がある。したがって、ＷＴＲＵが、ＥＤＡＩ＝０を有する第１の受信されたＰＤＣＣＨのセットのコードブックと、ＥＤＡＩ＝２を有する第２の受信されたＰＤＣＣＨのセットのコードブックとを集約するとき、ＷＴＲＵは、ＥＤＡＩ＝１を有する欠落しているＰＤＣＣＨのセットのための追加のＨＡＲＱコードブックデリミタを挿入することができる。これをさらに実証するために、ＷＴＲＵは、以下のようにＨＡＲＱコードブックを集約することができる：ＨＡＲＱコードブック−ＥＤＡＩ０、ＨＡＲＱコードブックデリミタ、ＨＡＲＱコードブックデリミタ、ＨＡＲＱコードブック−ＥＤＡＩ２。この例では、ＰＤＳＣＨグループ（例えば、ＣＯＴ内のＰＤＳＣＨ）には、各ＥＤＡＩインデックスによって動的にラベル付けされる。この例では、グループに関連付けられたＥＤＡＩによってインデックス付けされた各グループのＨＡＲＱコードブックは、各ＰＤＳＣＨグループ内に蓄積されることができる。あるいは、グループに関連付けられたＥＤＡＩによってインデックス付けされた各ＰＤＳＣＨグループのＨＡＲＱコードブックは、全てのグループにわたって蓄積されることもできる。
【０１０３】
図６は、ＷＴＲＵが、ＤＡＩにしたがって（すなわち、ｇＮＢが予想するように、ＰＤＳＣＨの予想されるセットのコードブックを計算するために）およびＥＤＡＩにしたがって（すなわち、同様に含める必要があるＨＡＲＱコードブックの直前のセットの数を決定するために）ＨＡＲＱコードブックを準備する例示的な送信図である。６１０において、ＷＴＲＵは、スロットｎ−２において、ＤＡＩ＝１およびＥＤＡＩ＝０であるスロットｎ＋２のＰＵＣＣＨについてのインジケーションを受信することができる。６１１において、コードブックは、これまでに受信した２つのＰＤＳＣＨのセットに基づいており、ＥＤＡＩ＝０であるため、ＷＴＲＵは、スロットｎ−１において、ＤＡＩ＝２であるスロットｎ＋２のＰＵＣＣＨについてのインジケーションを受信することができる。６１２において、ＷＴＲＵは、スロットｎ＋２においてスケジュールされたＬＢＴを実行し、この例では、ＬＢＴが失敗したかまたはＬＢＴが成功したが受信側で干渉があったため、ｇＮＢはＰＵＣＣＨを受信しない。６１３において、ＷＴＲＵは、通常のリソース割り当て（例えば、ｎ＋６のＰＵＣＣＨ、およびこれが第３のＰＤＳＣＨであるためＤＡＩ＝３）を受信するが、ｇＮＢがスロットｎ＋２のＰＵＣＣＨを受信しなかったため、ＥＤＡＩ＝１であることを示し、それにより、同様に直前のＨＡＲＱコードブックのセットも含める必要があることを示す。６１４において、６１２の状況と同様に、ｇＮＢは、説明のためにＰＵＣＣＨを受信しない。結果として、６１５における次のリソース割り当てにおいて、ＷＴＲＵは、スロットｎ＋９のＰＵＣＣＨのインジケーションを受信することができ、ここで、コードブックの２つの直接セットがここで含まれている必要があるため、ＤＡＩ＝３およびＥＤＡＩ＝２である。６１６において、ｇＮＢは、示されたスロットｎ＋９においてＷＴＲＵによるＬＢＴが成功した後、最終的にＰＵＣＣＨを受信することができる。
【０１０４】
図７は、ＷＴＲＵが、ＤＡＩにしたがって（すなわち、予想されるＰＤＳＣＨのセットのコードブックを計算するために）、およびＥＤＡＩの最後の値にしたがって（すなわち、同様に含める必要がある直前のＨＡＲＱコードブックのセットの数を決定するために）ＨＡＲＱコードブックを準備する例示的な送信図である。ＥＤＡＩの値は、ＰＤＣＣＨリソースのセット中に異なる場合がある。例えば、７１２および７１４における連続したＤＡＩ値を有する２つの連続したＰＤＣＣＨリソース（例えば、スロットｎ＋２およびｎ＋４）が、ＷＴＲＵが関連するＰＤＳＣＨリソースのＨＡＲＱコードブックを報告すると予想される次のＰＵＣＣＨ（例えば、スロットｎ＋６）を示すことを考える。さらに、７１０および７１１（例えば、スロットｎ−２およびｎ−１）におけるＰＤＳＣＨリソースの前のセットのＰＵＣＣＨは、これらの２つのＰＤＣＣＨリソース（例えば、スロットｎ＋３）の間でスケジュールされることができる。７１２において、ＥＤＡＩの値は、０とすることができる（例えば、スロットｎ＋２のＰＤＣＣＨにおいて）が、ｇＮＢが７１３において前のＰＤＳＣＨのセットの予想されるコードブックを受信しないとき、次に、次のＰＤＣＣＨにおいて（例えば、スロットｎ＋４において）、ｇＮＢは、７１４においてＥＤＡＩを１に変更し、同様にＰＵＣＣＨのサイズも大きくすることができる（すなわち、より大きなＰＵＣＣＨに対応するためにＰＵＣＣＨリソースを後のスロットに再配置することもできる）。次に、７１５において、ＷＴＲＵは、以前のＨＡＲＱコードブック（例えば、スロットｎ−２およびｎ−１についてｇＮＢが受信していないもの）と新たなＨＡＲＱコードブック（例えば、スロットｎ＋２およびｎ＋４における２つのＰＤＳＣＨリソース用）を含む集約コードブックを準備することができる。
【０１０５】
ＷＴＲＵは、ＤＡＩ値を参照して、動的コードブックのサイズを計算することができる。ＤＡＩのサイズが２ビットであるため、４回のＰＤＣＣＨ／ＰＤＳＣＨ送信の後にフィールドがラップアラウンドする可能性があり、それらの全てが次のＰＵＣＣＨを参照する。例えば、５つの連続するＰＤＣＣＨ／ＰＤＳＣＨ送信が全て次のＰＵＣＣＨを参照する場合、ＰＤＣＣＨにおけるＤＡＩ値は、それぞれ、「ｍｏｄ（ｄａｉ，４）、ｍｏｄ（ｄａｉ＋１，４）、ｍｏｄ（ｄａｉ＋２，４）、ｍｏｄ（ｄａｉ＋３，４）、ｍｏｄ（ｄａｉ４）、ｍｏｄ（ｄａｉ＋１，４）」とすることができ、これは、ラップアラウンド効果を示す。しかしながら、４つ未満の連続するＰＤＣＣＨが欠落している場合、ラップアラウンドは、いかなるエラーも生成しない可能性がある（すなわち、ＰＤＣＣＨおよびＰＤＳＣＨの双方が欠落しているため、ＷＴＲＵは、単に欠落したＰＤＣＣＨリソースのＮＡＣＫを報告するだけである）。さらに、ＷＴＲＵが４つ以上の連続するＰＤＣＣＨ送信を欠落した場合、ＷＴＲＵは、欠落したＰＤＣＣＨリソースの実際の数を把握することができない可能性があり、これは、コードブックサイズを正しく計算する方法がないため、不整合をもたらす可能性がある。ライセンスを取得した通信事業者において４つ以上の連続したＰＤＳＣＨが欠落している可能性は低いが、ＷＴＲＵ側での衝突／干渉により、ＮＲ−Ｕにおいて発生する可能性が高くなる。これは、ＤＡＩが各グループ内に個別に蓄積される場合、８または１６の連続するＰＤＣＣＨを欠落する可能性が低減するように（すなわち、４つを超えるＰＤＣＣＨを欠落する可能性に対応する）、ＤＡＩサイズを２ビットよりも大きくする（例えば、３または４ビット）ことによって対処されることができる。ＤＡＩがＥＤＡＩによってインデックス付けされた複数のＰＤＳＣＨグループにわたって蓄積される場合、動的コードブックサイズは、グループ（Ｎ）あたりのＰＤＣＣＨ／ＰＤＳＣＨ送信の数の倍数（すなわち、Ｎ×（３または４ビット））とすることができる。
【０１０６】
図８は、ＷＴＲＵが１つ以上のＣＯＴのＥＤＡＩに基づいてＨＡＲＱコードブックを集約する例示的な送信図である。ここで、ＷＴＲＵは、ＥＤＡＩフィールドがそうすることを示している場合（すなわち、ＥＤＡＩ＝ＴＢＤ１）、以前のＣＯＴ（すなわち、この例では直前のＣＯＴ）からのＨＡＲＱコードブックを集約することができる。示されているように、２つのＣＯＴ８１０および８２０が存在することができる。ＣＯＴ８１０は、ｎに対するスロットの増分とすることができ、ＣＯＴ８２０は、ｊに対するスロットの増分とすることができる（例えば、ｎ＝ｊ）。一般に、３つ以上のＣＯＴが存在することができるが、示されているように、ＣＯＴ８２０は、ＣＯＴ８２０の後に続く。８１１（すなわち、スロットｎ−２）において、ＷＴＲＵは、ＤＡＩ＝１およびＥＤＡＩ＝０についてのスロットｎ＋２のＰＵＣＣＨのインジケーションを受信する。８１２（すなわち、スロットｎ−１）において、ＷＴＲＵは、ＤＡＩ＝２およびＥＤＡＩ＝０のスロットｎ＋２におけるＰＵＣＣＨを示すことができる。
【０１０７】
８１３において、ＷＴＲＵは、ＣＯＴ８１０（すなわち、スロットｎ＋２）の終わりに、示されたＰＵＣＣＨリソースにＨＡＲＱ  ＡＣＫを送信することが予想されることができるが、ＬＢＴは失敗する場合があり（例えば、失敗したＬＢＴまたはｇＮＢが受信を失敗した）、ＣＯＴ８１０は、ＷＴＲＵを送信せずに終了する。ｇＮＢおよびＷＴＲＵは、ＰＵＣＣＨ送信の次の機会がいつになるか把握することができない場合がある。これに対処するために、８２１（すなわち、スロットｊ）において、ｇＮＢは、以前のＣＯＴ８１０の最後のＰＵＣＣＨ機会中に送信されなかったＨＡＲＱコードブック、または集約されたＨＡＲＱコードブックとともに、スロットｊ＋ｋにおいてＷＴＲＵにＰＵＣＣＨを送信することを示すＥＤＡＩ＝ＴＢＤ１のインジケーション（例えば、ＤＣＩまたはＲＲＣにおける）とともに、次のＣＯＴ８２０においてＰＤＣＣＨをＷＴＲＵに送信することができる。ＥＤＡＩは、前のＣＯＴにおいてＰＵＣＣＨを送信することができなかったＰＤＳＣＨのグループなど、特定のＰＤＳＣＨグループまたは特定のＣＯＴを示すことができる。８２２において、ＷＴＲＵは、ＰＵＣＣＨのＬＢＴを正常に完了し（例えば、構成されたＤＣＩまたはＲＲＣによって示される）、前および現在のＣＯＴからのＨＡＲＱ  ＡＣＫを集約してｇＮＢに送信することができる。この例では、２つのＣＯＴについてのみ説明しているが、同じ技術を１つ以上のＣＯＴに使用することができる。
【０１０８】
一般に、ＷＴＲＵがＬＢＴに失敗し、ＰＵＣＣＨの送信を控えた場合、ＷＴＲＵは、次のＣＯＴまでＨＡＲＱコードブックを保持し、ＷＴＲＵがＥＤＡＩ＝ＴＢＤ１のＰＤＣＣＨを受信した場合、ＷＴＲＵは、以下のうちのいずれかを実行することができる：１）ＤＣＩが、いかなるＰＤＳＣＨもなしで、次のＰＵＣＣＨのみを示す場合、ＷＴＲＵは、示された次のＰＵＣＣＨリソースにおけるコードブックを送信することができる；または、２）ＤＣＩがＰＤＳＣＨリソースとともに次のＰＵＣＣＨを示す場合、ＷＴＲＵは、以前のコードブックを新たなＨＡＲＱコードブックとともに集約し、示された次のＰＵＣＣＨリソースにおいて集約された結果を送信することができる。ＷＴＲＵがＬＢＴ手順を正常に完了し、ＰＵＣＣＨを送信した場合であっても、ＷＴＲＵは、次のＣＯＴまで、および／またはＷＴＲＵがＥＤＡＩ＝ＴＢＤ１未満の値（ＥＤＡＩ＝０など）のＰＤＣＣＨを受信するまで、ＨＡＲＱコードブックを保持することができ、その後、ＷＴＲＵは、以前のＨＡＲＱコードブックを破棄することができる。
【０１０９】
ＴＢＤ１値は、例えば、ＥＤＡＩが２のビット幅を有する場合には３とすることができ、ＥＤＡＩが３のビット幅を有する場合、ＴＢＤ１値は７とすることができる。または、ＴＢＤ１は、１とすることができ、新たなＣＯＴのＷＴＲＵへの最初のユニキャストＰＤＣＣＨのそのような値は、上記と同じ解釈を有する。本明細書で論じられるように、図８の例に関して示されて使用されるＥＤＡＩ値は、次のアップリンク機会までいくつかのグループ／時間（例えば、ＴＢ、ＣＯＴなど）について保留中の全てのＨＡＲＱコードブックを集約するためのＷＴＲＵへのインジケーションとして機能する値を表し、値は、この意味を伝えることができる１つ以上の数字、文字、および／または記号とすることができる。
【０１１０】
１つのシナリオでは、ｇＮＢがＴＢをＷＴＲＵに送信し、スケジュールされたＰＵＣＣＨ機会中にＷＴＲＵがＬＢＴに失敗したかまたはｇＮＢがＰＵＣＣＨを正しく検出することができなかった、２つの連続したＣＯＴが存在することができ、これは、ＷＴＲＵ側における２つのセットの保留中のＨＡＲＱコードブックをもたらすことができる。さらに、受信したＤＣＩ内でフィールドＥＤＡＩがＴＢＤ２の値を有する場合、必要に応じて、ＷＴＲＵが現在のＣＯＴのＨＡＲＱコードブックを、ＥＤＡＩ＝ＴＢＤ２を有する同じＤＣＩに示されているスケジュールされたＰＵＣＣＨリソース内の保留中のＨＡＲＱコードブック（例えば、それぞれが２つの直前のＣＯＴ中に準備されたもの）と集約する必要があることを示すことができる。他のシナリオでは、ＴＢＤ＃の任意のＥＤＡＩ値について、＃は、ＣＯＴの数に関連付けられた数値を示すことができる（例えば、数値に到達するために現在および／または以前のＣＯＴをカウントする）。ＴＢＤ＃のＥＤＡＩ値は、特定のＣＯＴに関連付けられた数値を示すことができる。
【０１１１】
状況によっては、ＷＴＲＵがスケジュールされたＰＵＣＣＨにおいてＨＡＲＱコードブックを送信するとき、次にスケジュールされたＰＵＣＣＨの属性がＥＤＡＩ＝０でない限り、ＷＴＲＵは、ＨＡＲＱコードブックを破棄しない場合がある。これは、ｇＮＢが以前に送信されたＰＵＣＣＨを正しく復号し、ＨＡＲＱコードブックを再送信する必要がないことをＷＴＲＵが確認するのに役立つことができる。
【０１１２】
図９は、ＰＵＣＣＨリソース割り当てが現在のＣＯＴの外側にあり、後のＣＯＴからのＰＵＣＣＨが使用される例示的な送信図である。この例では、２つのＣＯＴ９１０および９２０が存在することができる。９０１において、ｇＮＢは、現在のＣＯＴ９１０の外側とすることができる理論上のスロットｎ＋３においてＰＵＣＣＨをスケジュールすることができる。ＷＴＲＵは、ＰＤＣＣＨ内のＰＤＳＣＨ−ｔｏ−ＨＡＲＱタイミングインジケータフィールドが、現在のＣＯＴの決定された終了時間外のタイミングインスタンスを示す場合、スケジュールされたＰＵＣＣＨが現在のＣＯＴ９１０の外側にあると推測することができる。９０２において、ＷＴＲＵが、スケジュールされたＰＵＣＣＨが現在のＣＯＴの終了後に含まれると判定した場合、ＷＴＲＵは、ＰＵＣＣＨ送信を続行せず、次の送信のために保留中のＨＡＲＱコードブックを保持することができる。ｇＮＢによって確立された後続のＣＯＴ９２０において、ＷＴＲＵがＣＯＴ９２０のスロットｊ＋２のスケジュールされたＰＵＣＣＨの属性を有するＥＤＡＩ（例えば、ＤＣＩまたはＲＲＣにおいて示される）を有する新たなＰＤＣＣＨを受信したときである。９０４において、ＷＴＲＵは、保留中のＨＡＲＱコードブックを、新たにスケジュールされたＰＵＣＣＨ内の新たなコードブック（すなわち、集約されたＨＡＲＱ  ＡＣＫ）とともに送信することができる。新たなＣＯＴの最初のＰＤＣＣＨ／ＤＣＩ内で、ｇＮＢは、保留中のＨＡＲＱコードブックが、新たに形成されたＨＡＲＱコードブックとともに送信されることが予想されることをＷＴＲＵに示すために、図８の場合の例と同様に、ＥＤＡＩ＝ＴＢＤ１を設定することができる。矢印は、各ＰＤＳＣＨのＨＡＲＱ  ＡＣＫがスロットｊ＋２において送信されていることを示していることに留意されたい。示されていないが、ＷＴＲＵが、現在のＣＯＴにおける対応するＰＤＳＣＨ受信のために後続のＣＯＴにおいて新たなＰＤＣＣＨを受信しない場合、ＷＴＲＵは、上位層によって提供されるＰＵＣＣＨリソースにおいて関連するＨＡＲＱコードブックを送信することができる。
【０１１３】
場合によっては、ＷＴＲＵが現在のＣＯＴにおいてＰＤＣＣＨを検出したが、ＤＣＩがＰＤＳＣＨ−ｔｏ−ＨＡＲＱタイミングインジケータフィールドを含まない場合、ＷＴＲＵは、ｇＮＢが現在のＣＯＴにおける対応するＰＤＳＣＨ受信のためにＰＵＣＣＨリソースをＷＴＲＵに割り当てていないと見なすことができる。したがって、ＷＴＲＵは、図８および図９の例と同様に、後続のＣＯＴにおいて、ＰＵＣＣＨリソース上で保留中のＨＡＲＱコードブックを送信することができる。この場合、ＷＴＲＵが現在のＣＯＴ内のスロットｎにおいてＰＤＳＣＨを受信すると仮定すると、ＷＴＲＵは、後続のＣＯＴ内のスロットｎ＋ｋ内のＰＵＣＣＨリソースを判定することができ、ここで、ｋは、上位層または後続のＣＯＴにおいて受信したＤＣＩのＰＤＳＣＨ−ｔｏ−ＨＡＲＱタイミングインジケータフィールドによって提供されるスロットの数である。
【０１１４】
場合によっては、スケジュールされたＰＵＣＣＨが現在のＣＯＴの終了後に含まれることをＷＴＲＵが検出すると、ＷＴＲＵは、適切なＬＢＴプロセスを実行した後、ＣＯＴが終了した後にＰＵＣＣＨを送信することができる。ＣＯＴ期間が満了した場合であっても、ＷＴＲＵは、ライセンスのないチャネル内のデバイスと同じように（例えば、ＣＯＴに監視されない）ＰＵＣＣＨをなおも送信することができるが、ＷＴＲＵは、カテゴリが、スケジュールされたＰＵＣＣＨがＣＯＴの終了後である期間に依存するＬＢＴプロセスを実行する必要がある。スケジュールされたＰＵＣＣＨがＣＯＴの終わりから１６μ秒以内にある場合、ＷＴＲＵは、ＬＢＴなしと同様と見なすことができるＣａｔ−１  ＬＢＴを使用してＰＵＣＣＨを送信することができる。スケジュールされたＰＵＣＣＨがＣＯＴの終わりから２５μ秒以内にある場合、ＷＴＲＵは、ワンショットＬＢＴと称されることができるＣａｔ−２ＬＢＴを使用してＰＵＣＣＨを送信することができる。スケジュールされたＰＵＣＣＨがＣＯＴの終わりの２５μ秒後の場合、ＷＴＲＵは、Ｃａｔ−３ＬＢＴを使用してＰＵＣＣＨを送信することができ、ＷＴＲＵは、最も優先度の高いクラスを使用してリッスン間隔を計算することができる。スケジュールされたＰＵＣＣＨがＣＯＴの終わりの２５μ秒後であり、ＷＴＲＵがＰＵＣＣＨ送信後に構成された許可リソース内でＴＢを送信する予定の場合、ＷＴＲＵは、Ｃａｔ−４ＬＢＴを使用してＰＵＣＣＨを送信することができる。上記の場合、ｇＮＢは、ＷＴＲＵにＨＡＲＱコードブックの再送信を要求することができるため（すなわち、ＥＤＡＩ＝ＴＢＤ１を設定することにより）、ＷＴＲＵは、ｇＮＢによって次に確立されたＣＯＴまでＨＡＲＱコードブックを保持することができる。
【０１１５】
本明細書で論じられるように、ＮＲ−Ｕ  ＬＢＴ手順における成功した動作のために、ＬＢＴは、ＲＡＴ間およびＲＡＴ内の共存のための効果的なアプローチとすることができる。しかしながら、ＬＢＴのリッスン間隔は、帯域幅リソースを浪費する可能性があり、ＬＢＴ手順が頻繁に呼び出されると、チャネルアクセスの効率が低下する可能性がある。したがって、ＬＢＴ手順を１回呼び出すことができるように、ＣＯＴにおいてＤＬからＵＬへの切り替え時間を１回有することが有益な場合がある。ｇＮＢは、ギャップがないか非常に小さいギャップがある単一のスイッチポイントを有するＣＯＴにおいてＷＴＲＵのＤＬ／ＵＬをスケジュールすることができる。ギャップが１６μ秒未満のＬＢＴ規則があり、ＬＢＴカテゴリ１においてキャプチャされることができる場合、規則はこれに役立つことができ、この場合、ギャップが１６μ秒未満である場合に応答デバイス（例えば、ＷＴＲＵ）がリッスン間隔を実行する必要がない。例えば、一部の８０２．１１技術は、これを利用することができ、応答ステーションは、１６μ秒の持続時間でフレームに確認応答を送信することができる。したがって、ＮＲ−Ｕフレーム構造は、ｇＮＢがＣＯＴ内の複数のＷＴＲＵをアドレス指定する可能性がある、ＣＯＴにおいてＬＢＴがないこれらの効率的な共存状況に適合させることができる。
【０１１６】
参考として、スイッチングギャップ（ＤＬからＵＬへ）は、ＳＦＩ内で以下のようにスケジュールされて示されることができる。「ＤＬ（ＷＴＲＵ１）、ＤＬ（ＷＴＲＵ２）、ＬＢＴ、ＵＬ（ＷＴＲＵ１）、ＤＬ（ＷＴＲＵ３）、ＬＢＴ、ＵＬ（ＷＴＲＵ２）、ＤＬ（ＷＴＲＵ１）、・・・」。ここで、スイッチングギャップは、１つのＯＦＤＭシンボルとすることができ、ギャップの持続時間は、ヌメロロジに応じて１６μ秒よりも長くすることができる。そのような場合、ＷＴＲＵは、Ｃａｔ−１ＬＢＴ以外の処理を行う必要がある場合がある（例えば、持続期間が２５μ秒未満の場合、ＷＴＲＵは、Ｃａｔ−２ＬＢＴを実行することができる）。しかしながら、ＬＢＴを実行することは、ＷＴＲＵが受信モードにされる必要があるが、ベースバンドユニットの限られた部分が使用されることを意味することができ、ＷＴＲＵがＬＢＴを正常に完了するまでに、ＷＴＲＵが送信モードに切り替わるために、ある程度のスイッチング時間を必要となる場合があることを意味する。
【０１１７】
１つのシナリオでは、ｇＮＢは、ＤＬ／ＵＬスイッチングギャップを必要としない方法で複数のＷＴＲＵをスケジュールすることができる。これは、ＤＬシンボルが第１のＷＴＲＵにアドレス指定され、次のＵＬシンボルが第２のＷＴＲＵにアドレス指定されるように、ｇＮＢのスケジューリングの問題とすることができる。例えば、スケジューリングは、ＤＬ（ＷＴＲＵ１）、ＤＬ（ＷＴＲＵ２）、ＵＬ（ＷＴＲＵ１）、ＤＬ（ＷＴＲＵ３）、ＵＬ（ＷＴＲＵ２）、ＤＬ（ＷＴＲＵ１）、・・・とすることができる。この例では、ＷＴＲＵ１は、次のＵＬ送信について通知され、また、ギャップのないＵＬ送信の準備をするように通知される。
【０１１８】
一般に、スイッチングＵＬ／ＤＬに関連するこれらの例では、スロット境界は、意図的に無視されることができるが、ＵＬシンボルは、スロットの最後の数個のシンボルに位置することができることが理解されることができる。また、ＤＬ部分およびＵＬ部分は、異なるサイズとすることができる。さらに、表記ＤＬ（ＷＴＲＵ１）は、ＰＤＣＣＨおよび／またはＰＤＳＣＨリソースを伝送することができる第１のＷＴＲＵ（すなわち、ＷＴＲＵ１）のスロットの先頭などにおいて、１つ以上のＤＬシンボルを示すことができる。
【０１１９】
図１０は、ＷＴＲＵがスケジュールされたＰＵＣＣＨリソースの属性を検査し、ｎｏ−ＬＢＴ−ＰＵＣＣＨが真の値を有する場合、ＷＴＲＵは、ＰＵＣＣＨの直前にリッスン間隔を実行しない（すなわち、ギャップがない）例示的な送信図である。１０１１において、ＷＴＲＵは、一致するＲＮＴＩを有するＰＤＣＣＨ内のＤＣＩ内のスケジュールされたＰＵＣＣＨリソースの属性を検査することができ、ここで、ｇＮＢは、スロットｎ＋３、ＤＡＩ＝０、およびｎｏ−ＬＢＴ−ＰＵＣＣＨ＝真におけるＰＵＣＣＨをＷＴＲＵに示すことができる。１０１２において、ｇＮＢは、ＷＴＲＵにスロットｎ＋３、ＤＡＩ＝１、およびｎｏ−ＬＢＴ−ＰＵＣＣＨ＝真におけるＰＵＣＣＨを示すことができる。ｎｏ−ＬＢＴ−ＰＵＣＣＨが真値を有する場合、ＷＴＲＵは、関連する時間および周波数属性を使用して、次のＰＵＣＣＨ（すなわち、スロットｎ＋３）について、ＰＵＣＣＨ  ＵＬ送信の直前にギャップがない可能性があると推測することができ、したがって、ＷＴＲＵは、１０１３に示すように、ＰＵＣＣＨの直前にリッスン間隔を実行する必要がない場合がある。ｇＮＢは、ＤＬチャネルがＷＴＲＵにアドレス指定されないように、ＰＵＣＣＨリソースの前にＤＬシンボルをスケジュールすることができる。
【０１２０】
また、１０１３において、ＷＴＲＵが、一致するＲＮＴＩを有するＰＤＣＣＨ内のＤＣＩにおいてスケジュールされたＰＵＣＣＨリソースを検出し、ｎｏ−ＬＢＴ−ＰＵＣＣＨサブフィールドが真値を有する場合、ＷＴＲＵは、最新のＳＦＩの値を一時的に上書きすることができ（例えば、ＰＵＣＣＨが配置されているスロットのみについて）、スケジュールされたＰＵＣＣＨの前に１つ以上のＯＦＤＭシンボルを「Ｘ」シンボルとして選択し、この間、ＷＴＲＵは、ダウンリンク受信からＵＬ送信に移行する。ＷＴＲＵは、ｇＮＢがＣａｔ−１ＬＢＴを利用する（例えば、または１６μ秒の期間中にＬＢＴがない）ＷＴＲＵのＰＵＣＣＨリソースをスケジュールするための動的な動作に従事することができるように、「Ｘ」シンボルを判定する際に最新のＳＦＩ値を上書きすることができる。
【０１２１】
別のシナリオでは、ｇＮＢは、ＷＴＲＵが２５μ秒のＬＢＴ手順（例えば、ワンショットＬＢＴ）を実行し、ＤＬシンボルからＵＬシンボルに切り替えるのに十分なギャップ間隔を提供することができる。スケジューリングは、「ＤＬ（ＷＴＲＵ１）、ＤＬ（ＷＴＲＵ１）、ＤＬ（ＷＴＲＵ１）、ＤＬ（ＷＴＲＵ１）、ＬＢＴ、ＵＬ（ＷＴＲＵ１）、・・・」とすることができ、ＬＢＴ期間は、ヌメロロジに応じて、１つまたは２つのＯＦＤＭシンボルを超える。ＷＴＲＵは、一致するＲＮＴＩを有するＰＤＣＣＨ内のＤＣＩ内のスケジュールされたＰＵＣＣＨリソースの属性を検査することができる。ワンショットＬＢＴ−ＰＵＣＣＨがＴＢＤ３値を有する場合、ＷＴＲＵは、次のＰＵＣＣＨ（すなわち、関連する時間および周波数属性）について、ＰＵＣＣＨ  ＵＬ送信の直前に１つ以上のシンボルのギャップが存在する可能性があると推測することができ、したがって、ＷＴＲＵは、ＰＵＣＣＨの直前と、ＬＢＴが成功した場合に切り替える準備を行うことができる直後に２５μ秒のリッスン間隔を実行する必要がある場合がある。ＷＴＲＵが、ｎｏ−ＬＢＴ−ＰＵＣＣＨサブフィールドが値ＴＢＤ３を有するＲＮＴＩと一致するＰＤＣＣＨのＤＣＩにおいてスケジュールされたＰＵＣＣＨリソースを検出した場合、ＷＴＲＵは、最新のＳＦＩの値を一時的に上書きすることができ（例えば、ＰＵＣＣＨが位置するスロットのみについて）、スケジュールされたＰＵＣＣＨの前に１つ以上のＯＦＤＭシンボルを「Ｘ」シンボルとして選択し（例えば、Ｄ／Ｘ／Ｕシンボルについて表３を参照）、その間に、ＷＴＲＵは、ダウンリンク受信からＵＬ送信に移行することができる。しかしながら、移行は、移行の直前の２５μ秒間隔でのワンショットＬＢＴの成功を条件とすることができる。
【０１２２】
構成された許可（ＣＧ）または許可なしのＮＲにおける送信では、ＷＴＲＵは、一連の（すなわち、ＲＲＣ構成の）許可なしリソースにおいて最大Ｋ＝（１，２，４，８）回の繰り返しによってＴＢを送信するように構成されることができる。ＮＲ−Ｕにも同様または同じ許可なしの手順が存在することができ、チャネルアクセスおよび関連するＬＢＴ手順に関するいくつかのＷＴＲＵの動作が適合される必要がある。ｇＮＢがいくつかの許可なしのリソースによってＣＯＴを確立した場合、ＷＴＲＵは、ｇＮＢが確立したＣＯＴ内で許可なしの送信を開始することができる。ＣＯＴ内の許可なしのリソースの場合、ＷＴＲＵは、リソースにアクセスするためにＬＢＴ手順を実行することができる。
【０１２３】
一例では、ＷＴＲＵは、例えば、ＷＴＲＵがアクセスを試みる最初の許可なしリソースの直前に、ＬＢＴ手順（例えば、ＬＢＴ  Ｃａｔ−２、３または４）を１回実行することができ、そして次に、ＬＢＴ手順が成功した場合、ＷＴＲＵは、ＬＢＴなし（すなわちＬＢＴ  Ｃａｔ−１）またはワンショットＬＢＴ（ＬＢＴ  Ｃａｔ−２）、またはＬＢＴ  Ｃａｔ−３のいずれかを使用して、ＣＯＴ内の残りの許可なしリソースにアクセスすることができる。Ｋの値によっては、ＷＴＲＵは、ＴＢのＫ回の繰り返しを完了せずにＣＯＴの終わりに到達することができる（すなわち、Ｋ回の繰り返し許可なしのＵＬ送信において指定されたように）。
【０１２４】
一例では、ＷＴＲＵは、ＣＯＴの外側の最初の許可なしのリソースにアクセスする前に、より堅牢なＬＢＴ  Ｃａｔ−４を実行することができ、ＣＯＴの外側の後続の許可なしのリソースにアクセスするために、ＷＴＲＵは、ｎｏ−ＬＢＴまたはＣａｔ−１を実行することができる。
【０１２５】
一例では、ＷＴＲＵは、ＣＯＴの外側の最初の許可なしのリソースにアクセスする前にＬＢＴ  Ｃａｔ−３を実行することができ、ＣＯＴの外側の後続の許可なしのリソースにアクセスするために、ＷＴＲＵは、ｎｏ−ＬＢＴまたはワンショットＬＢＴを実行することができる。
【０１２６】
一例では、ＷＴＲＵは、ＣＯＴの外側の最初のおよび後続の各許可なしリソースにアクセスする前にワンショットＬＢＴ手順（Ｃａｔ−１）を実行するように構成されることができるか、またはｇＮＢによって示されることができる。
【０１２７】
一例では、ＷＴＲＵは、ＣＯＴの外側のリソースにおける送信を控えることができる。
【０１２８】
本明細書で論じられるように、ＷＴＲＵが元のＣＯＴの外側に送信する必要があり、複数のＣＯＴが必要となる可能性があるＮＲ−Ｕ送信の状況が存在することができる。複数のＣＯＴがある場合、ＷＴＲＵは、別のＣＯＴにおいて確認応答を送信し、競合ウィンドウを調整する必要がある場合がある。
【０１２９】
確認応答の送信は、例えば、データ送信がＣＯＴ１で行われ、確認応答の送信がＣＯＴ２で行われる場合があるため、別のＣＯＴに遅延される場合がある。この場合、確認応答の送信は、ＬＢＴの成功に続くことができる。一例では、ＨＡＲＱコードブックの受信は、ＷＴＲＵがＬＢＴを実行し、ＵＬスロットにおいてＵＬ確認応答を送信する場合など、確認応答も必要とする場合がある。ｇＮＢは、次のＤＬタイムスロットにおいて確認応答の受信を確認する必要がある場合がある。このようにして、ＷＴＲＵは、送信が成功したかどうかを知ることができ、したがって、ＷＴＲＵは、それに応じて、次のＬＢＴのためにその競合ウィンドウを調整することができる。
【０１３０】
別のＣＯＴにＡＣＫを有する例では、ＷＴＲＵからのＵＬ確認応答送信は、ポーリングベースとすることができる。効率を改善するために、グループポーリングメカニズムを使用することができる。
【０１３１】
別のＣＯＴにＡＣＫを有する例では、ｇＮＢは、チャネルを取得するためにＬＢＴを実行することができ、次に、ｇＮＢは、確認応答ポーリングのためにグループ共通ＤＣＩを１つ以上のＷＴＲＵに送信することができる。周波数／時間リソースのセットは、複数のＷＴＲＵからの確認応答送信に割り当てることができる。ＷＴＲＵは、グループ共通ＤＣＩを受信し、送信するＵＬ確認応答を有し、割り当てられた周波数／時間リソースを使用して確認応答を送信することができる。ＷＴＲＵは、ＵＬ送信の前に固定期間でＬＢＴを実行することができるか、または、ＷＴＲＵは、ＬＢＴを実行する必要がなく、割り当てられたリソースにおいて単に送信することができる。一例では、ＷＴＲＵは、送信する１つ以上のリソースをランダムに選択することができる。
【０１３２】
ＡＣＫを別のＣＯＴに有する例では、ｇＮＢは、ＬＢＴを実行してチャネルを取得することができ、次にｇＮＢは、ＤＣＩのグループをＷＴＲＵのグループに送信して確認応答ポーリングを行うことができる。周波数／時間リソースのセットは、複数のＷＴＲＵからの確認応答送信に割り当てることができる。ＷＴＲＵは、グループ共通ＤＣＩを受信し、送信するためにＵＬ確認応答を有することができ、割り当てられた周波数／時間リソースを使用して確認応答を送信することができる。一例では、ＷＴＲＵは、送信する１つ以上のリソースをランダムに選択することができる。
【０１３３】
図１１は、送信される確認応答の累積数による競合ウィンドウ調整の例示的な手順である。
【０１３４】
一般に、ＮＲ−Ｕでの確認応答の送信は、ＬＢＴの性能を必要とする場合がある。ＬＢＴの障害が原因でデバイスが送信することができない場合や、デバイスが確認応答を送信しても、衝突が原因で送信が失敗する場合がある。そのような場合、デバイスは、メディア／チャネルが再び利用可能になるのを待機して、ＬＢＴを実行する場合がある。送信に失敗した場合、デバイスは、より大きなランダムバックオフ値を引き出すことができるように、競合ウィンドウサイズを増やす必要がある場合がある。しかしながら、遅延した確認応答送信は、遅延したデータ送信をもたらし、混雑したチャネルを形成する可能性がある。これに対処するために、デバイスは、確認応答が蓄積されている場合、競合ウィンドウのサイズを縮小するか、または残りのバックオフ期間を短縮することができる。この場合、デバイスは、確認応答送信用の個別のランダムバックオフ手順を有することができる。
【０１３５】
図１１に示されるように、１１０２において、ＷＴＲＵは、競合ウィンドウサイズＣＷｐを判定することができ、ここで、ＣＷｍｉｎ≦ＣＷｐ≦ＣＷｍａｘであり、ＣＷｍｉｎおよびＣＷｍａｘは、事前定義／事前決定または通知されることができる。１１０４において、ＷＴＲＵは、確認応答送信のためにランダムなバックオフ番号Ｒ∈［０、ＣＷｐ］を引き出すことができる。１１０６において、ＷＴＲＵは、信号エネルギレベルが一定の期間内に事前定義された閾値を下回っていることを検出することができ、ＷＴＲＵは、保留中のＡＣＫ／ＮＡＣＫを有することができる。１１０８において、ＷＴＲＵは、Ｒ＞０であるかどうかをチェックすることができる。
【０１３６】
Ｒがゼロよりも大きい場合、１１１０において、ＷＴＲＵは、Ｔタイムスロットについてチャネル／メディアを監視し続けることができる。タイムスロット中にチャネルが空いている場合、１１１４において、ＷＴＲＵは、Ｒ＝Ｒ−１を設定することができる。そうでない場合、１１１２において、ＷＴＲＵは、送信される累積確認応答の数Ｎａｃｋをチェックすることができ、ＷＴＲＵは、Ｒ＝ｆ（Ｒ、Ｎａｃｋ）を設定することができる。関数ｆは、事前定義または事前決定されることができる。一例では、
【数３】
2021534623.tif 000008
である。ＷＴＲＵは、更新されたＲ値を保持し、チャネルの監視を続行することができる。
【０１３７】
Ｒがゼロよりも大きくない場合（すなわち、Ｒが０に到達する場合）、１１１６において、ＷＴＲＵは、ＡＣＫ／ＮＡＣＫをｇＮＢに送信することができる。１１１８において、ＷＴＲＵは、送信されたＡＣＫ／ＮＡＣＫが成功したかどうかを認識／判定することができる。それが成功した場合、１０２０において、ＷＴＲＵは、ＣＷｐ＝ＣＷｍｉｎを設定することができ、１１０４において、次のＡＣＫ／ＮＡＫ送信のために新たなランダムバックオフ番号を引き出すことができる。ＡＣＫ／ＮＡＣＫの送信が成功しなかった場合、１１１２において、ＷＴＲＵは、残りのランダムバックオフ値Ｒを調整することができる。ＷＴＲＵは、Ｒ＝ｆ（Ｒ、Ｎａｃｋ）を設定することができる。
【０１３８】
図１１の例示的な手順では、ＷＴＲＵは、累積数の確認応答のために保存されたＮａｃｋを有することができる。ＷＴＲＵ側においてＮａｃｋを維持する方法は、実装に関連することができる。例えば、ＷＴＲＵがＷＴＲＵへのＰＤＳＣＨ送信に対応する有効なＤＣＩを受信すると、ＷＴＲＵは、１だけＮａｃｋの数を増加することができる。ＷＴＲＵが前の確認応答の送信が成功したことに気付くと、ＷＴＲＵは、値Ｎａｃｋをリセットすることができる。例えば、ＷＴＲＵは、
【数４】
2021534623.tif 000009
を設定することができ、ここで、
【数５】
2021534623.tif 000010
は、以前に正常に送信された確認応答の数とすることができる。
【０１３９】
本明細書で論じられるように、ＮＲ−Ｕ送信において、ＷＴＲＵまたはｇＮＢは、成功したＬＢＴ手順が実行された後、最大期間、ライセンスされていないチャネルにおいて送信し続けることができる。場合によっては、ＣＯＴを共有する必要がある場合がある。ＷＴＲＵまたはｇＮＢなどのデバイスがライセンスのないチャネルにおいてＣＯＴを開始すると、第２のデバイスがＣＯＴ中に送信する、それぞれｇＮＢまたはＷＴＲＵなどの別のデバイスとＣＯＴを共有することもできる。例えば、ｇＮＢがＣＯＴを開始して「所有」する場合（すなわち、ｇＮＢ所有ＣＯＴ）、それを１つ以上のＷＴＲＵと共有することができるか、またはＷＴＲＵが開始してＣＯＴを「所有する」場合（すなわち、ＷＴＲＵ所有ＣＯＴ）、それをそのｇＮＢと共有することができる。ＣＯＴ共有は、ライセンスのないチャネルにおけるより効率的な送受信だけでなく、より良い共存のためにいくつかの規則に制限されることができる。ＮＲ−ＵにおいてＣＯＴ共有を使用すると、ライセンスのないチャネルにおけるより良い共存とより効率的な送受信とを可能にすることができる。
【０１４０】
構成された許可（ＣＧ）または許可なしの送信では、ＷＴＲＵは、ＬＢＴ手順（例えば、ＬＢＴ  ＣＡＴ−３またはＣＡＴ−４）を実行し、ＬＢＴ手順が優先クラスに関連付けられているＣＯＴを確立することができる。ＷＴＲＵは、ＣＧ送信規則を使用して保留中のＴＢをｇＮＢに送信することができる。次に、ＷＴＲＵは、そのＣＯＴ、すなわちＷＴＲＵ所有ＣＯＴをｇＮＢと共有することができる。ｇＮＢは、いくつかの目的で共有ＣＯＴを使用することができる。例えば、ｇＮＢは、直前のＴＢ送信、またはＣＯＴを確立する前のＴＢ送信のためのＨＡＲＱフィードバックを伝送するＷＴＲＵにＣＧ−ＤＦＩを送信することができる。ｇＮＢはまた、ＴＢを同じＷＴＲＵまたは他のＷＴＲＵに送信することができる。
【０１４１】
より効率的なＣＯＴ共有のために、ＷＴＲＵは、ｇＮＢにＣＯＴの属性を示すことができる。これらの属性は、おそらくＣＧ−ＵＣＩにおいて伝送される、最後の、または最後の数回のＣＧ  ＰＵＣＣＨ送信においてＷＴＲＵによってｇＮＢに送信されることができる。ＣＧ−ＵＣＩにおいて伝送されるＣＯＴ属性は、以下のものを含むことができる：ＣＯＴの期間（例えば、合計期間、ＣＯＴを所有するＷＴＲＵによって使用されると予想される期間などの期間の内訳、および／またはＣＯＴの残りの部分）；ＣＯＴが確立されているアクセスカテゴリ（ＡＣ）またはアクセス優先度クラス；ｇＮＢが他のＷＴＲＵへのＤＬ送信にＣＯＴを使用することが許可されるかどうか；および／または、ｇＮＢがＣＯＴを使用して他のＷＴＲＵのＵＬ送信をスケジュールすることが許可されるかどうか。
【０１４２】
ｇＮＢがＷＴＲＵ共有ＣＯＴにおいて送信を開始すると、ｇＮＢは、ＣＯＴ属性を他のＷＴＲＵにアナウンスすることができる。（ＷＴＲＵ共有）ＣＯＴ属性は、ｇＮＢがＣＯＴの開始時に送信する、および／またはＣＯＴの後続のスロットの開始時に再送信するＣＯＴ属性の一部とすることができる。ｇＮＢは、ＣＯＴの開始時または共有送信の開始時にこれを送信することができる。
【０１４３】
ＣＯＴ共有は、２つ以上のＷＴＲＵ間で実行されることができる（例えば、２つのＷＴＲＵがそれらのｇＮＢへのＣＧ送信に従事する場合）。例えば、ＷＴＲＵ１は、ＣＯＴを開始し、その保留中のＴＢをＣＧ  ＰＵＳＣＨにおいて送信することができる。次に、ＷＴＲＵ２は、同じＣＯＴを使用して独自のＣＧ  ＰＵＳＣＨを送信することができる。しかしながら、ＷＴＲＵ２は、ＷＴＲＵ１所有ＣＯＴについて通知する必要がある場合がある。１つのアプローチでは、ＷＴＲＵ１は、他のＷＴＲＵが残りのＣＯＴを使用されることができることを示すそのＣＯＴ属性をｇＮＢに送信することができる。次に、ｇＮＢは、グループ共通（ＧＣ）ＰＤＣＣＨ内の他のＷＴＲＵによってそのようなＣＯＴ属性をアナウンスする。
【０１４４】
ＷＴＲＵによって確立されるＣＯＴは、ＣＧまたは自律アップリンク（ＡＵＬ）送信用とすることができる。このＣＯＴがｇＮＢと共有される場合、共有されたＣＯＴは、ＣＧ（またはＡＵＬ）とスケジュールされたまたは許可ベースのＵＬ送信との間で使用されることができる。例えば、ｇＮＢは、ＷＴＲＵ１が所有する共有ＣＯＴを使用して、ＷＴＲＵ２の許可ベース（またはスケジュールされたＵＬ）をスケジュールすることができる。しかしながら、これが発生するためには、ｇＮＢは、ＷＴＲＵ２が送信のために保留中のＴＢを有するという事実を認識する必要がある場合がある。場合によっては、ｇＮＢは、前または直前のＣＯＴにおいてＷＴＲＵのスケジューリング要求（ＳＲ）を受信した可能性があるか、および／またはそのＣＯＴにおいてＷＴＲＵのＵＬ送信をスケジュールする時間またはスケジュールされたリソースを有しなかった可能性がある。あるいは、ｇＮＢが共有ＣＯＴの使用を開始した後、ｇＮＢは、最初または最初の数スロットの全てのＷＴＲＵに対してＳＲリソースをスケジュールすることができ、ＳＲリソースは、それらが保留中のＴＢを有することをｇＮＢに示すために使用されることができる。ＷＴＲＵからＳＲを受信した後、ｇＮＢは、共有ＷＴＲＵ１が所有する共有ＣＯＴの残りの部分においてＵＬをスケジュールすることができる。
【０１４５】
ＷＴＲＵがその所有ＣＯＴをｇＮＢと共有することを意図する場合、ＷＴＲＵは、ｇＮＢが規制規則によって制限されるギャップ内でダウンリンク送信を開始することができるようにするために１つ以上のアクションを実行することができる（例えば、ギャップが２５μ秒の持続時間とすることができる場合）。ｇＮＢがこのギャップ内で送信を開始した場合、ＣＯＴ共有は、規制規則内で実行されることができる。そうでない場合、ｇＮＢがギャップの期間内に送信を開始することができない場合、ｇＮＢは、送信することができるようになる前に完全なＬＢＴ手順（ＣＡＴ３またはＣＡＴ４）を実行する必要がある場合がある。ｇＮＢがＷＴＲＵ所有の共有ＣＯＴを首尾よく使用する可能性を高めるために、ＷＴＲＵは、これらの１つ以上のアクションを実行することができる。
【０１４６】
そのようなアクションの１つは、次のスロットの開始前にまたはｇＮＢがミニスロットを開始することができる次の機会の開始前に、２５μ秒などの規制期間内にその送信の終了を調整するために、ＷＴＲＵが１つまたはいくつかの最後のシンボルのサイクリックプレフィックス（ＣＰ）を拡張する場合とすることができる。ＣＰ拡張は、ＣＧ−ＵＣＩのように、ＷＴＲＵによって事前にｇＮＢに示される場合があることに留意されたい。
【０１４７】
そのようなアクションの１つは、ＷＴＲＵが、次のスロットの開始前またはｇＮＢがミニスロットを開始することができる次の機会の開始前に、２５μ秒などの規制期間内にスロットの最後の１つまたはいくつかのシンボルにおいてサウンディングリファレンス信号（ＳＲＳ）を送信する場合とすることができる。
【０１４８】
ＣＯＴ属性では、ＣＯＴを取得したＷＴＲＵからのいくつかの測定値も報告されることができる（例えば、ＲＳＳＩ、基準信号受信電力（ＲＳＲＰ）など）。ＣＯＴ共有は、ＷＴＲＵとｇＮＢのセットとの間で優先される場合があり、それらの中で１つのデバイスがプライマリ（またはマスタ）ノードとして機能し、他のデバイスがセカンダリ（またはスレーブ）ノードとして機能する。
【０１４９】
図１２は、基本的なＣＯＴ共有の例示的な送信図である。一般に、基本的なＣＯＴ共有は、ＷＴＲＵが低いトラフィック負荷を有するシナリオ、または隠れノード問題があまり目立たない密度の低い状況で使用されることができる。図１２および図１２では、各ボックスは、１つ以上のスロットを表すことができる。ＣＯＴ期間１２２０は、ＷＴＲＵ１  ＣＯＴ１２２２およびＣＯＴ共有部分１２２４を含むことができる。最初に１２０１において、ＷＴＲＵは、ＬＢＴを実行することによって（例えば、事前構成されたＣＧ／許可なしリソースにおいて送信するために）ＣＯＴを取得することができる。取得後の最初の送信において、ＷＴＲＵは、１２０２においてＷＴＲＵ  ＣＧ送信に関連するｇＮＢおよび他の属性にＣＯＴ属性を送信することができる。これらの属性は、ＰＵＳＣＨにおいて多重化されたＵＣＩで実行されることができる。ＰＵＳＣＨ送信が完了すると、１２０３において、ｇＮＢは、ＣＯＴを引き継ぐ（すなわち、共有する）ことができ、この場合、以下の１つ以上が発生する可能性がある：ｇＮＢは、同じく１２０３において、ＧＣ−ＰＤＣＣＨにおいてＣＯＴ属性をアナウンスする；ｇＮＢは、１２０４においてＷＴＲＵ割り当てを使用してＰＤＣＣＨを送信する；ｇＮＢ／ＷＴＲＵは、１２０５において、ＰＤＣＣＨ割り当てに基づいてＰＤＳＣＨ／ＰＵＳＣＨを送信する；および／またはｇＮＢ／ＷＴＲＵは、１２０６において、受信したＰＤＳＣＨ／ＰＵＳＣＨに基づいてＰＵＣＣＨ／ＰＤＳＣＨを送信する（すなわち、ＡＣＫの場合）。
【０１５０】
あるいは、ＣＯＴ共有手順は、隠れノードの影響を制限するための追加の手順を含むことができる。図１３は、隠れノードの効果を制限するＣＯＴ共有の例示的な送信図である。ＣＯＴ期間１３２０は、ＷＴＲＵ１  ＣＯＴ１３２２およびＣＯＴ共有部分１３２４を含むことができる。最初に、ＷＴＲＵは、１３０１において、ＬＢＴに基づいて（例えば、事前構成されたＣＧ／許可なしリソースにおいて送信するために）ＣＯＴを取得することができる。取得後の最初の送信で、１３０２において、ＷＴＲＵは、ＣＯＴ属性をｇＮＢに送信することができる。これらのＣＯＴ属性は、ＰＵＳＣＨにおいて多重化されたＵＣＩを有効にするショートトランスポートブロック、ショートＰＵＣＣＨ、またはＰＵＣＣＨにおいてＵＣＩを使用した変更ＳＲによって伝送されることができる。ｇＮＢにおいてＷＴＲＵ  ＣＯＴ属性を受信すると、ｇＮＢは、１３０３において共有ＣＯＴ属性を送信することができ、これらは、ＷＴＲＵによって要求される正確なＣＯＴ属性とすることができるか、またはＷＴＲＵの予約済み属性および追加の共有ＣＯＴ属性を含むＷＴＲＵによって要求されるＣＯＴ属性の変更されたセットとすることができる。次に、１３０４において、ＷＴＲＵは、その所望のデータをＰＵＳＣＨにおいてｇＮＢに送信することができる。ＰＵＳＣＨ送信の完了時に、ｇＮＢは、ＣＯＴを引き継ぐことができ、ここで、ｇＮＢは、ＷＴＲＵ割り当て１３０５によってＰＤＣＣＨを送信することができ、ｇＮＢ／ＷＴＲＵは、ＰＤＣＣＨ割り当て１３０６に基づいてＰＤＳＣＨ／ＰＵＳＣＨを送信することができ、および／またはｇＮＢ／ＷＴＲＵは、受信したＰＤＳＣＨ／ＰＵＳＣＨ１２０７に基づいてＰＵＣＣＨ／ＰＤＳＣＨ（ＡＣＫの場合）を送信する。
【０１５１】
特徴および要素が特定の組み合わせで上記に説明されているが、当業者は、各特徴または要素が単独で、または他の特徴および要素と任意の組み合わせで使用されることができることを理解するであろう。さらに、本明細書に記載の方法は、コンピュータまたはプロセッサによって実行するために、コンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアに実装することができる。コンピュータ可読媒体の例は、電子信号（有線接続または無線接続を介して送信される）およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクやリムーバブルディスクなどの磁気媒体、磁気光学媒体、ＣＤ−ＲＯＭディスクなどの光学媒体、デジタル多用途ディスク（ＤＶＤ）などを含むが、これらに限定されるものではない。ソフトウェアに関連するプロセッサを使用して、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータで使用するための無線周波数トランシーバを実装することができる。
【図１Ａ】
2021534623.tif 000011
【図１Ｂ】
2021534623.tif 000012
【図１Ｃ】
2021534623.tif 000013
【図１Ｄ】
2021534623.tif 000014
【図２】
2021534623.tif 000015
【図３】
2021534623.tif 000016
【図４】
2021534623.tif 000017
【図５】
2021534623.tif 000018
【図６】
2021534623.tif 000019
【図７】
2021534623.tif 000020
【図８】
2021534623.tif 000021
【図９】
2021534623.tif 000022
【図１０】
2021534623.tif 000023
【図１１】
2021534623.tif 000024
【図１２】
2021534623.tif 000025
【図１３】
2021534623.tif 000026
【国際調査報告】
2021534623.tif 000027
2021534623.tif 000028