JP7304412B2 - Ｎｒ－ｕにおける広帯域キャリア動作のためのレートマッチング - Google Patents

Description

開示される主題は、一般に通信に関し、より詳細には、次世代モバイル無線通信システムの未ライセンススペクトルチャネルにおけるデータ送信を適応させることに関する。

モバイルブロードバンドは、無線アクセスネットワークにおける大きい全体的なトラフィック容量と巨大な達成可能なエンドユーザデータレートとに対する需要を高め続けるであろう。将来におけるいくつかのシナリオが、ローカルエリアにおいて最高１０Ｇｂｐｓのデータレートを必要とすることになる。極めて高いシステム容量と極めて高いエンドユーザデータレートとに対するこれらの需要は、屋内展開での数メートルから屋外展開でのほぼ５０ｍまでにわたるアクセスノード間の距離をもつ、すなわち、今日の最も密なネットワークよりもかなり高いインフラストラクチャ密度をもつ、ネットワークによって満たされ得る。以下では、今３ＧＰＰにおいて現在開発されているＮＲシステムのようなネットワークを参照する。旧来のライセンス済み専用帯域のほかに、ＮＲシステムは、特に企業ソリューションのために未ライセンス帯域上でも動作していることが予想される。これは、現在、３ＧＰＰにおけるＮＲ－Ｕ研究アイテム内で論じられている。

背景のために、ＬＴＥの重要な側面のうちのいくつかが、このセクションで説明される。特に関連するものは、ＬＴＥおよびＬＴＥ－ｅＬＡＡにおけるトランスポートブロック処理および未ライセンス帯域幅の使用である。また、未ライセンススペクトルとともに使用するための送信方式が、ＮＲ－Ｕのために設計されており、本出願の主題である。

ｇノードＢおよびＵＥなど、ここで使用される専門用語は、非限定的であると見なされるべきであり、その２つの間のある階層関係を特に暗示せず、概して、「ＵＥ」は第１のノードと見なされ得、「ｇノードＢ」は第２のノードと見なされ得、これらの２つのノードまたはデバイスは何らかの無線チャネルを介して互いと通信することに留意されたい。本明細書では、ダウンリンクにおける無線送信にも焦点を当てるが、本発明は、アップリンクにおいて等しく適用可能である。

ＮＲのためのヌメロロジーおよび帯域幅の考慮事項
複数のヌメロロジーが、ＮＲにおいてサポートされる。ヌメロロジーは、サブキャリア間隔およびＣＰオーバーヘッドによって規定される。複数のサブキャリア間隔は、整数２＾ｎによって基本サブキャリア間隔をスケーリングすることによって導出され得る。使用されるヌメロロジーは、周波数帯域とは無関係に選択され得るが、極めて高いキャリア周波数において極めて小さいサブキャリア間隔を使用しないことが仮定される。フレキシブルなネットワークおよびＵＥチャネル帯域幅がサポートされる。

無線レイヤ１ワーキンググループ（ＲＡＮ１）仕様観点から、ＮＲキャリアごとの最大チャネル帯域幅は、Ｒｅｌ－１５において４００ＭＨｚである。ＮＲキャリアごとの少なくとも１００ＭＨｚまでのチャネル帯域幅のためのすべての詳細が、Ｒｅｌ－１５において指定されるべきであることに留意されたい。少なくとも単一のヌメロロジーの場合、ＮＲキャリアごとのサブキャリアの最大数の候補は、ＲＡＮ１仕様観点からＲｅｌ－１５において３３００または６６００である。ＮＲチャネル設計は、後のリリースにおいてこれらのパラメータの潜在的な将来の拡張を考慮し、Ｒｅｌ－１５ ＵＥが後のリリースにおいて同じ周波数帯域上でＮＲネットワークへのアクセスを有することを可能にするべきである。

サブフレーム持続時間は１ｍｓに固定され、フレーム長は１０ｍｓである。スケーラブルヌメロロジーは、少なくとも１５ｋＨｚから４８０ｋＨｚまでのサブキャリア間隔を可能にするべきである。１５ｋＨｚおよびより大きいサブキャリア間隔をもつすべてのヌメロロジーは、ＣＰオーバーヘッドにかかわらず、ＮＲキャリアにおいて１ｍｓごとにシンボル境界上で整合する。より詳細には、ノーマルＣＰファミリーの場合、以下が採用される。
－ １５ｋＨｚ＊２^ｎ（ｎは非負整数である）のサブキャリア間隔の場合、
－ １５ｋＨｚサブキャリア間隔の（ＣＰを含む）各シンボル長は、スケーリングされたサブキャリア間隔の対応する２^ｎ個のシンボルの和に等しい。
－ ０．５ｍｓごとにおける第１のＯＦＤＭシンボル以外、０．５ｍｓ内のすべてのＯＦＤＭシンボルは、同じサイズを有する
－ ０．５ｍｓにおける第１のＯＦＤＭシンボルは、他のＯＦＤＭシンボルと比較して、１６Ｔ_ｓ（１５ｋＨｚおよび２０４８のＦＦＴサイズを仮定する）だけ長い。
－ １６Ｔ_ｓは、第１のシンボルのためのＣＰのために使用される。
－ １５ｋＨｚ＊２^ｎ（ｎは負の整数である）のサブキャリア間隔の場合
－ サブキャリア間隔の（ＣＰを含む）各シンボル長は、１５ｋＨｚの対応する２^ｎシンボルの和に等しい。

トランスポートブロック、コードブロックおよびコードブロックグループ
ＬＴＥおよびＮＲでは、トランスポートブロックは、トランスポートブロックがあるサイズを超える場合、複数のコードブロックにセグメント化される。エラー検出について、各コードブロックならびにトランスポートブロックは、それ自体のＣＲＣを有する。ＬＴＥでは、ＨＡＲＱフィードバックは、トランスポートブロックの復号ステータスに基づき、すなわち、単一のＨＡＲＱフィードバックビットが、トランスポートブロックごとに生成される。

ＮＲは、この動作モードをサポートする。さらに、ＮＲは、コードブロックグループ（ＣＢＧ）ベースＨＡＲＱフィードバックをもサポートする。ＮＲコードブロックグループ動作が、図６に示されている。ここでは、１つまたは複数のコードブロックがＣＢＧにグループ化され、各ＣＢＧについて１つのＨＡＲＱフィードバックビットが生成される。これは、１つまたは少数のＣＢＧのみにエラーがある場合、トランスポートブロックの一部分のみが再送信される必要があるので、有用である。

ＣＢＧベースフィードバックは、１つまたは少数のコードブロックのみにエラーがある場合、完全なトランスポートブロックの再送信が、大きいオーバーヘッドにつながることになる、極めて大きいトランスポートブロックのために特に有用であり得る。ＣＢＧベースフィードバックの場合、エラーがあるコードブロックグループのみが再送信され得る。ＣＢＧベースフィードバックの別の適用例は、低レイテンシ送信のほうを優先して進行中の送信が中断される、プリエンプションである。送信をプリエンプトすることが、短い持続時間のものであるにすぎない場合、ほんの少数のコードブロックが破棄され得、個々のコードブロックの選択的送信を再び優先する。

ＮＲにおける無線リソースへのデータマッピング
データがＭＩＭＯ送信のために符号化された後に、変調シンボルが、符号化されたデータから生成され、変調シンボルは、割り当てられた無線リソースにさらにマッピングされる。ＮＲでは、変調シンボルから無線リソースへのマッピングは、レイヤ－＞周波数－＞時間の順序に従う。ライセンス済み帯域においてＮＲのために使用されるデータマッピングルールの場合と同様に、ＮＲ－Ｕのための広帯域キャリアが複数のＬＢＴ帯域幅ピース（ｂａｎｄｗｉｄｔｈ ｐｉｅｃｅ）にわたる場合について、データマッピングが図７に示されている（ＬＢＴ帯域幅ピースの説明について以下の「ＮＲ広帯域動作」と題するサブセクションを参照されたい）。

レートマッチングのためのＮＲにおける予約済みリソース
Ｒｅｌ－１５ ＮＲでは、ｇＮＢが、いくつかの時間および周波数リソースを予約し、これらのリソースがＰＤＳＣＨ（ダウンリンクデータ）受信のために周りでレートマッチングされるべきであるか否かをＤＣＩメッセージにおいて動的に指示することが可能である。詳細には、セルまたは帯域幅パート（ｂａｎｄｗｉｄｔｈ ｐａｒｔ）について、最高４つのレートマッチングパターンが、上位レイヤシグナリング（無線リソース制御またはＲＲＣシグナリング）を介して設定され得る。最高２つのレートマッチンググループが設定され得、各グループは、レートマッチングパターンのセットを含んでいる。レートマッチンググループ内のリソースセットについてのＲＢとシンボルレベルリソースとのユニオンが、ＤＣＩメッセージを介して、ＰＤＳＣＨ受信のために利用可能であるかまたは利用可能でないことをシグナリングされ得る。ＤＣＩメッセージにおけるこのレートマッチングインジケータの存在およびＤＣＩ中のビット数（０～２）は、帯域幅パートまたはセルのために規定されたレートマッチンググループの数に依存する。

ｅＬＡＡ（ＬＴＥ）のためのマルチチャネルＵＬ送信
ＬＡＡ ＵＬマルチキャリア動作のためのベースラインは、シングルキャリア動作の拡張である。各キャリア上のＬＢＴタイプは、対応するＵＬグラントを介してＵＥにシグナリングされる。その上、すべてのキャリア上のサブフレームにおいて同じ開始点をもつＣａｔ４ ＬＢＴでスケジュールされたキャリアのセット上でＵＬグラントを受信したＵＥは、Ｃａｔ４ ＬＢＴが、セット中の指定されたキャリア上で成功裡に完了した場合、セット中のキャリア上での送信の直前に、２５μｓ ＬＢＴに切り替えることができる。ＵＥは、セット中のキャリアのうちのいずれかの上でＣａｔ４ ＬＢＴプロシージャを開始することより前に、指定されたキャリアとしてＣａｔ４ ＬＢＴでスケジュールされたキャリアのうちの１つのキャリアを一様にランダムに選択しなければならない。

ＬＢＴが上述のルールに従って複数のチャネルにおいて成功したとき、異なるトランスポートブロック（ＴＢ）が、図８に示されているように、各キャリアおよびサブフレームについて生成されることに留意されたい。各キャリアは、２０ＭＨｚの帯域幅を有する。

Ｗｉ－ＦｉのためのマルチチャネルＵＬ送信
ｅＬＡＡとは異なり、Ｗｉ－Ｆｉ（すなわち、８０２．１１ｎ、８０２．１１ａｃなど）は、２０ＭＨｚ以外の新しいより広いチャネルを規定する。図９に示されているように、４０ＭＨｚは、２つの２０ＭＨｚの単純なアグリゲーションよりも多くの使用可能なサブキャリアをもたらすことができる。利益は２つの側面から得られ、すなわち、一方は、ガード帯域減少であり、他方は、パイロットサブキャリアオーバーヘッド節約である。したがって、より広いチャネルは、より高いスペクトル効率をもたらすことができる。

４０ＭＨｚフレームを送信する前に、局は、４０ＭＨｚチャネル全体がクリアであることを確実にすることを担当する。クリアチャネルアセスメントが、８０２．１１チャネル上での送信のための十分に理解されたルールに従って、１次チャネル上で実施される。デバイスが４０ＭＨｚフレームを送信しようとする場合でも、スロット境界およびタイミングは、１次チャネルへのアクセスにのみ基づく。２次チャネルは、２次チャネルが４０ＭＨｚ送信の一部として使用され得る前に、優先フレーム間スペース中にアイドルでなければならない。Ｗｉ－Ｆｉでは、ＵＥは、ＬＢＴ成果、すなわち、２０ＭＨｚおよび４０ＭＨｚ送信に基づいて、ＵＬデータ自体をいつおよびどのように送信すべきかを判定する。

ＮＲ広帯域動作
ＮＲと同様に、ＮＲ－Ｕが、広帯域幅、たとえば、最高数百ＭＨｚ帯域幅をもつ送信をサポートすることが予想される。しかしながら、同じスペクトルを同時に共有する、異なるデバイスの能力を伴う、異なる無線技術、たとえば、ＷｉＦｉがあり得る。特に高い負荷において、デバイスが広帯域幅全体にわたってチャネルフリーを検知する可能性は低い。したがって、サポートされる帯域幅のどの（１つまたは複数の）パートを使用すべきかを、そのリッスンビフォアトーク（ＬＢＴ）の結果に基づいてデバイスが判定することができる、動的帯域幅をもつ送信をＮＲ－Ｕがサポートすることは有益である。

デバイスが広帯域送信において使用すべき２つの手法は、以下の通りである。
・ モード１：ＬＴＥ－ｅＬＡＡに類似するキャリアアグリゲーション（ＣＡ）ベース広帯域動作
・ モード２：単一のアクティブ帯域幅パート（ＢＷＰ）に基づく単一の広帯域キャリア動作

図１０は、８０ＭＨｚの動作帯域幅のためのこれらの２つのモードの一例を示す。モード１の場合、ＵＥは、受信／送信より前にアクティブにされる、合計８０ＭＨｚになる４つの２０ＭＨｚコンポーネントキャリア（ＣＣ）で設定される。モード２の場合、ＵＥは、受信／送信より前にアクティブにされると仮定される、単一の８０ＭＨｚ帯域幅パート（ＢＷＰ）で設定される。帯域幅パートの概念はＮＲにとって新しく、ＬＴＥはＢＷＰを含まなかった。モード２についての図に示されているように、広帯域キャリア（ＣＣ）は、８０ＭＨｚよりも大きいことがあり、ＢＷＰは、単に、ＵＥがＤＬおよびＵＬ送信／受信のために設定される、この広帯域キャリアの一部である。

今３ＧＰＰにおいて論じられているように、ＬＢＴは、少なくともモード１について、２０ＭＨｚの単位で実施される。言い換えれば、ＬＢＴは、ＣＣ（コンポーネントキャリア）ごとに実施される。次いで、送信が、フリーとして検知された、すなわち、リッスンビフォアトーク（ＬＢＴ）プロシージャによって決定されたように別のノード（同じまたは異なるＲＡＴ）からの送信によって占有されていない、各ＣＣ上で行われる。

モード２の場合、ここでは、ＬＢＴが、同じく、２０ＭＨｚの単位で実施されると仮定し、図１０に示されているように各ユニットを「ＬＢＴ帯域幅ピース」と呼ぶ。ＬＢＴ帯域幅ピースは、ＬＢＴ帯域幅、ＬＢＴサブ帯域、サブ帯域、または物理リソースブロック（ＰＲＢ）範囲と呼ばれることもある。ＬＢＴ結果に基づいて、デバイスは、単一のＢＷＰ内の各フリーＬＢＴ帯域幅ピースからのリソースを、ＵＬまたはＤＬのいずれかにおける単一の物理共有チャネル（ＳＣＨ）にアグリゲートする。図１１は、４つのＣＣ／帯域幅ピースのうちの２つ上でＬＢＴが失敗した（媒体が「ビジー」として検知された）、ＬＢＴの結果の一例を示す。もちろん、他のＬＢＴ結果、たとえば、ＣＣ／帯域幅ピースのうちの１つまたは３つ上でのＬＢＴ失敗が考えられる。

いずれのモードでも、使用されるＣＣ／帯域幅ピース上での送信から、隣接２０ＭＨｚチャネルへの漏洩がある。ＬＴＥ－ＬＡＡにおけるＣＡベース動作（モード１）の場合、無線性能およびプロトコル態様ワーキンググループ（ＲＡＮ４）が、ＣＣごとに規定された累積隣接チャネル漏洩比（ＣＡＣＬＲ：ｃｕｍｕｌａｔｉｖｅ ａｄｊａｃｅｎｔ ｃｈａｎｎｅｌ ｌｅａｋａｇｅ ｒａｔｉｏ）に関する要件を規定した［１、セクション６．６．２．２］。
サブブロックギャップまたはＲＦ帯域幅間（Ｉｎｔｅｒ ＲＦ Ｂａｎｄｗｉｄｔｈ）ギャップにおける累積隣接チャネル漏洩電力比（ＣＡＣＬＲ：Ｃｕｍｕｌａｔｉｖｅ Ａｄｊａｃｅｎｔ Ｃｈａｎｎｅｌ Ｌｅａｋａｇｅ ｐｏｗｅｒ Ｒａｔｉｏ）は、以下の比である。
ａ） サブブロックギャップまたはＲＦ帯域幅間ギャップの各側に隣接する２つのキャリアのための割り振られたチャネル周波数を中心とするフィルタ処理された平均電力の和、および
ｂ） それぞれのサブブロックエッジまたは基地局ＲＦ帯域幅エッジのうちの１つに隣接する周波数チャネルを中心とするフィルタ処理された平均電力。

この仕様は、送信ギャップの両側のキャリアからの漏洩、たとえば、図１１に示されているように、ＣＣ１およびＣＣ３からＣＣ２への漏洩を考慮する最大値をＣＡＣＬＲにセットする。実装観点から、デバイスは、隣接ＣＣへの漏洩を制限するために、各ＣＣ上の送信の適切なＲＦフィルタ処理によって、この要件に準拠する。

ただし、モード２の場合、ＢＷＰのＬＢＴ帯域幅ピース間のそのような漏洩要件は、ＲＡＮ４によってまだ規定されていない。しかしながら、チャネル内（ＢＷＰ内（ｉｎｔｒａ－ＢＷＰ））漏洩についてのそのような要件が、この動作モードのために必要とされることは明らかである。一般に、隣接チャネル漏洩要件に準拠するために、実際のフィルタが有限ロールオフ帯域幅を有するということを考慮するために、ガード帯域が送信のエッジにおいて導入される。モード２の場合、そのようなＢＷＰ内ガード帯域が、図１２において、すべての４つのＬＢＴ帯域幅ピースの両側に示されている。

前のセクションにおいて説明されたように、ＮＲとＬＴＥの両方では、ＰＤＳＣＨまたはＰＵＳＣＨ送信が物理チャネル上で行われ得る前に、一連のトランスポートブロック（ＴＢ）処理ステップが必要とされる。そのステップは、トランスポートブロックサイズ（ＴＢＳ）決定と、その後に続く、１つまたは複数のコードブロックまたはコードブロックグループへのＴＢの可能なセグメント化、データエンコーディング、ＣＲＣアタッチメント、変調、レイヤマッピング、およびプリコーディングとを含む。これらのステップは、時間を要し、したがって、ＰＤＳＣＨ／ＰＵＳＣＨ送信のためにスケジュールされたスロットに先立って実施されなければならない。その上、ＬＢＴプロシージャが、スケジュールされたスロットにちょうど先立って実施されるので、ＴＢ処理ステップの一部または全部が、同様にＬＢＴプロシージャに先立って実施されなければならない。したがって、モード２動作のためのＴＢ処理中に、送信デバイス（ｇＮＢまたはＵＥ）は、１つまたは複数のＬＢＴ帯域幅ピースがＬＢＴ失敗により利用不可能であることを考慮するためのＴＢ再処理のための時間がほとんどまたはまったくないので、一般に、すべてのＬＢＴ帯域幅ピースが送信のために利用可能であると仮定する。これは、別個のＴＢ処理がＣＣごとに実施され、１つまたは複数のＣＣが送信のために利用不可能である場合、それらの（１つまたは複数の）ＣＣに対応する（１つまたは複数の）ＴＢが、送信より前に単にドロップされる、モード１動作とは対照的である。

３ＧＰＰでは、モード２の場合、ＴＢを完全に再処理することなしに１つまたは複数のＬＢＴ帯域幅ピース上でＬＢＴ失敗をハンドリングする１つのやり方は、ＬＢＴ失敗により利用不可能であるＬＢＴ帯域幅ピースの周りでパンクチャまたはレートマッチングすることであることが論じられた。しかしながら、ＬＢＴ成功により利用可能であるＬＢＴ帯域幅ピースの両側の潜在的なＢＷＰ内ガード帯域（図５参照）をどのようにハンドリングすべきかに関するソリューションは論じられていない。

上記で説明されたように、ＮＲとＬＴＥの両方では、ＰＤＳＣＨまたはＰＵＳＣＨ送信が物理チャネル上で行われ得る前に、一連のトランスポートブロック（ＴＢ）処理ステップが必要とされる。そのステップは、トランスポートブロックサイズ（ＴＢＳ）決定と、その後に続く、１つまたは複数のコードブロックまたはコードブロックグループへのＴＢの可能なセグメント化、データエンコーディング、ＣＲＣアタッチメント、変調、レイヤマッピング、およびプリコーディングとを含む。これらのステップは、時間を要し、したがって、ＰＤＳＣＨ／ＰＵＳＣＨ送信のためにスケジュールされたスロットに先立って実施されなければならない。その上、ＬＢＴプロシージャが、スケジュールされたスロットにちょうど先立って実施されるので、ＴＢ処理ステップの一部または全部が、同様にＬＢＴプロシージャに先立って実施されなければならない。したがって、モード２動作のためのＴＢ処理中に、送信デバイス（ｇＮＢまたはＵＥ）は、１つまたは複数のＬＢＴ帯域幅ピースがＬＢＴ失敗により利用不可能であることを考慮するためのＴＢ再処理のための時間がほとんどまたはまったくないので、一般に、すべてのＬＢＴ帯域幅ピースが送信のために利用可能であると仮定する。これは、別個のＴＢ処理がＣＣごとに実施され、１つまたは複数のＣＣが送信のために利用不可能である場合、それらの（１つまたは複数の）ＣＣに対応する（１つまたは複数の）ＴＢが、送信より前に単にドロップされる、モード１動作とは対照的である。

３ＧＰＰでは、モード２の場合、ＴＢを完全に再処理することなしに１つまたは複数のＬＢＴ帯域幅ピース上でＬＢＴ失敗をハンドリングする１つのやり方は、ＬＢＴ失敗により利用不可能であるＬＢＴ帯域幅ピースの周りでパンクチャまたはレートマッチングすることであることが論じられた。しかしながら、ＬＢＴ成功により利用可能であるＬＢＴ帯域幅ピースの両側の潜在的なＢＷＰ内ガード帯域（図１２参照）をどのようにハンドリングすべきかに関するソリューションは論じられていない。

一実施形態によれば、共有チャネル（たとえば、ＤＬにおけるＰＤＳＣＨ、またはＵＬにおけるＰＵＳＣＨ）上の広帯域データ送信は、チャネルがフリーとして検知された（１つまたは複数の）ＬＢＴ帯域幅ピースのガード帯域のうちの１つまたは複数の周りで、パンクチャされるかまたはレートマッチングされるかのいずれかである。ＬＢＴ帯域幅ピースは、未ライセンススペクトルにある帯域幅パート（ＢＷＰ）にわたる。

本開示のいくつかの実施形態は、１つまたは複数の技術的利点を提供し得る。たとえば、ＬＢＴ帯域幅ピースのガード帯域を維持するためにパンクチャリングまたはレートマッチングが実施される、いくつかの実施形態は、単一の広帯域未ライセンスキャリアの帯域幅パート（ＢＷＰ）、たとえば、８０ＭＨｚが、複数のＬＢＴ帯域幅ピース（たとえば、２０ＭＨｚ帯域幅）にわたるとき、広帯域未ライセンスキャリア上での効率的なデータ送信および／または再送信を有利に促進しながら、同時に、隣接２０ＭＨｚチャネルへの隣接チャネル漏洩を最小限に抑える。

別の実施形態によれば、トランスポートブロック（ＴＢ）は、１つのＬＢＴ帯域幅ピースのみが第１の数のＯＦＤＭシンボルのために利用可能であると仮定して、送信のために準備され得る。次いで、いくつのＬＢＴ帯域幅ピースがＬＢＴ結果に基づいて利用可能であると決定されたかに応じて、ＴＢは、第２の（より少ない）数のＯＦＤＭシンボルにわたって複数の利用可能なＬＢＴ帯域幅ピース上で送信される。有利には、利用可能な無線リソースの数が、すべての考えられるＬＢＴ結果について同じであり、したがって、利用不可能な帯域幅ピースの周りでパンクチャまたはレートマッチングすることが実装される実施形態と比較して、ＴＢが正しく受信される可能性が高くなる。

他の利点が、当業者に容易に明らかになり得る。いくつかの実施形態は、具陳された利点のいずれをも有しないか、いくつかを有するか、またはすべてを有し得る。

本明細書で説明される様々な実施形態に関する追加情報が、付録Ａにおいて提供される。

開示される実施形態ならびにそれらの特徴および利点のより完全な理解のために、次に、添付の図面とともに、以下の説明が参照される。

ＬＴＥネットワークを示す図である。 無線通信デバイスを示す図である。 無線アクセスノードを示す図である。 第１のノードを動作させる方法を示すフローチャートである。 第１のノードを動作させる別の方法を示すフローチャートである。 ＮＲコードブロックグループ動作を示す図である。 ＮＲ－Ｕのために使用されるデータマッピングルールを示す図である。 ＬＴＥ－ｅＬＡＡのためのマルチチャネルＵＬ送信を示す図である。 Ｗｉ－ＦｉのためのマルチチャネルＵＬ送信を示す図である。 ＮＲ広帯域動作の２つのモードを示す図である。 ＬＢＴがＮＲ広帯域動作の２つのモードにおいて失敗するＬＢＴの結果の一例を示す図である。 複数のＬＢＴ帯域幅ピースの各々の両側のＢＷＰ内ガード帯域を示す図である。 第２のノードを動作させる方法を示すフローチャートである。 第２のノードを動作させる別の方法を示すフローチャートである。 仮想ネットワークノードまたは無線デバイス装置の図式図である。 本発明の実施形態が動作し得る例示的な仮想化環境の図式図である。 いくつかの実施形態による、中間ネットワークを介してホストコンピュータに接続された通信ネットワークの図式図である。 いくつかの実施形態による、部分的無線接続上で基地局を介してユーザ機器と通信するホストコンピュータの図式図である。 いくつかの実施形態による、ホストコンピュータと、基地局と、ユーザ機器とを含む通信システムにおいて実装される方法を示すフローチャートである。 いくつかの実施形態による、ホストコンピュータと、基地局と、ユーザ機器とを含む通信システムにおいて実装される別の方法を示すフローチャートである。

本開示では本発明を例示するために３ＧＰＰ ＮＲからの専門用語が使用されたが、これは、本発明の範囲を上述のシステムのみに限定するものでないことに留意されたい。他の無線システムも、本開示内でカバーされるアイデアを活用することから恩恵を受け得る。

基地局／ｇノードＢおよびＵＥなどの専門用語は、非限定的であると見なされるべきであり、その２つの間のある階層関係を特に暗示せず、概して、「ｇノードＢ」はデバイス１と見なされ得、「ＵＥ」はデバイス２と見なされ得、これらの２つのデバイスは何らかの無線チャネルを介して互いと通信することに留意されたい。また、以下では、送信機または受信機は、ｇＮＢまたはＵＥのいずれかであり得る。

以下の説明は、開示される主題の様々な実施形態を提示する。これらの実施形態は、教示例として提示され、開示される主題の範囲を限定するものと解釈されるべきではない。たとえば、説明される実施形態のいくらかの詳細は、説明される主題の範囲から逸脱することなく、修正、省略、または拡大され得る。

無線ノード： 本明細書で使用される「無線ノード」は、無線アクセスノードまたは無線デバイスのいずれかである。

制御ノード： 本明細書で使用される「制御ノード」は、別のノードを管理、制御または設定するために使用される無線アクセスノードまたは無線デバイスのいずれかである。

無線アクセスノード： 本明細書で使用される「無線アクセスノード」は、信号を無線で送信および／または受信するように動作する、セルラ通信ネットワークの無線アクセスネットワークにおける任意のノードである。無線アクセスノードのいくつかの例は、限定はしないが、基地局（たとえば、第３世代パートナーシッププロジェクト（３ＧＰＰ）Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）ネットワークにおける拡張またはエボルブドノードＢ（ｅＮＢ））と、高電力またはマクロ基地局と、低電力基地局（たとえば、マイクロ基地局、ピコ基地局、ホームｅＮＢなど）と、リレーノードとを含む。

コアネットワークノード： 本明細書で使用される「コアネットワークノード」は、コアネットワーク（ＣＮ）における任意のタイプのノードである。コアネットワークノードのいくつかの例は、たとえば、モビリティ管理エンティティ（ＭＭＥ）、エボルブドサービングモバイルロケーションセンタ（Ｅ－ＳＭＬＣ）、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（Ｐ－ＧＷ）、サービス能力公開機能（ＳＣＥＦ）などを含む。

無線デバイス： 本明細書で使用される「無線デバイス」は、セルラ通信ネットワークへのアクセスを取得する（すなわち、セルラ通信ネットワークによってサーブされる）ために、セルラ通信ネットワークにおいて、別の無線デバイスに／から、またはネットワークノードに／から、信号を無線で送信および／または受信することが可能である任意のタイプのデバイスである。無線デバイスのいくつかの例は、限定はしないが、３ＧＰＰネットワークにおけるユーザ機器（ＵＥ）、マシン型通信（ＭＴＣ）デバイス、ＮＢ－ＩｏＴデバイス、ＦｅＭＴＣデバイスなどを含む。

ネットワークノード： 本明細書で使用される「ネットワークノード」は、セルラ通信ネットワーク／システムの無線アクセスネットワークまたはＣＮのいずれかの一部である任意のノード、あるいはテスト機器ノードである。

シグナリング： 本明細書で使用される「シグナリング」は、（たとえば、無線リソース制御（ＲＲＣ）などを介した）上位レイヤシグナリング、（たとえば、物理制御チャネルまたはブロードキャストチャネルを介した）下位レイヤシグナリング、またはそれらの組合せのいずれかを含む。シグナリングは暗黙的または明示的であり得る。シグナリングは、さらに、ユニキャスト、マルチキャストまたはブロードキャストであり得る。シグナリングはまた、別のノードに直接であるか、または第３のノードを介し得る。

別段に記載されていない限り、以下の実施形態は、上記で説明されたすべての動作モードに適用される。

例示的な実施形態１ － すべてのガード帯域におけるパンクチャリング／レートマッチング
ＬＢＴをパスするすべてのＬＢＴ帯域幅ピースのすべてのガード帯域中のＰＲＢ（またはＰＲＢの部分）について、パンクチャリング／レートマッチングが実施される。すなわち、コード化ビットは、ガード帯域中に位置する無線リソースにマッピングされない。

例示的な実施形態２ － 連続するフリーＬＢＴ帯域幅ピースを考慮するパンクチャリング／レートマッチング
ＬＢＴをパスする２つまたはそれ以上のＬＢＴ帯域幅ピースが連続する場合を除いて実施形態＃１と同じであり、連続するＬＢＴ帯域幅ピースのためのパンクチャリング／レートマッチングは、連続するブロックのエッジにおけるガード帯域についてのみ実施される。

これは、以下のように、ＤＬおよびＵＬにおいて可能にされ得る。ＵＥ／ｇＮＢは、ＰＤＣＣＨ／ＤＭＲＳを監視することと、どの（１つまたは複数の）ＬＢＴ帯域幅ピースが利用可能であり、ｇＮＢ／ＵＥによって使用されたかを認識することとによって、ガード帯域のどの部分がパンクチャされるかを決定することができる。ＵＥ／ｇＮＢは、どのＬＢＴ ＢＷＰが使用されたかを知ると、ＵＥ／ｇＮＢは、どのガード帯域がパンクチャされたかを正確に知ることができる（すなわち、連続していない使用されたＬＢＴ ＢＷＰの間のガード帯域）。

例示的な実施形態３ － ＣＯＴの複数のスロットにおけるスケジューリング
パンクチャリング／レートマッチングは、チャネル占有時間（ＣＯＴ：ｃｈａｎｎｅｌ ｏｃｃｕｐａｎｃｙ ｔｉｍｅ）の最初のＮ個のスロットについて、実施形態＃１の場合のように実施され、残りのスロットについて、パンクチャリング／レートマッチングは、実施形態＃２の場合のように実施される。

サブ実施形態では、Ｎは、仕様によって固定される。

代替サブ実施形態では、ＤＬの場合、Ｎは、物理レイヤ制御シグナリング（たとえば、ＤＣＩ）、あるいは、上位レイヤシグナリング、たとえば、ＭＡＣ－ＣＥまたはＲＲＣにおけるメッセージのいずれかを通して、受信デバイスに指示される。

代替的に、ＤＬの場合、パンクチャリング／レートマッチングは、送信バーストの最初のＮ個のスロットについて、実施形態＃１または＃２の場合のように実施され、残りのスロットについて、パンクチャリング／レートマッチングは無効にされる。バーストにおける残りの送信について、ｇＮＢは、ＬＢＴに失敗した帯域幅ピース内にあるＰＲＢをスケジュールせず、ＬＢＴに成功した連続するブロックのエッジにあるガード帯域上のＰＲＢをもスケジュールしない。ガード帯域がスケジュールされないとすれば、ガード帯域のための特殊なハンドリングはＵＥ側に必要とされない。

例示的な実施形態４ － パンクチャリング／レートマッチングの指示
ＤＬの場合、送信デバイスは、所与のスロットについて、受信デバイスが１つまたは複数のＬＢＴ帯域幅ピースについてどんなパンクチャリング／レートマッチング仮定を行うものとするかを指示する。たとえば、指示は、ＰＤＳＣＨをスケジュールする同じＤＣＩ中のビットフィールドを通したものであり得る。各指示された帯域幅ピースについて、指示は、パンクチャリング／レートマッチングがそのＬＢＴ帯域幅ピースに関連するガード帯域のうちの０個、１つ、または２つにおいて実施されることであり得る。

この実施形態の場合、動作モード２の２つのさらなるサブモードをも規定する。
モード２ａ： ＵＥは、ＬＢＴが成功したすべての帯域幅ピースにわたる単一のＰＤＳＣＨでスケジュールされる。
モード２ｂ： ＵＥは、同じ帯域幅ピースにおけるＣＯＲＥＳＥＴにおいて送られるＰＤＣＣＨからの各帯域幅ピースにおける別個のＰＤＳＣＨでスケジュールされる。この実施形態の一部として、ＵＥが、複数の帯域幅パートで動作するか、または単一の帯域幅パート内で複数のＰＤＣＣＨおよびＰＤＳＣＨを受信することが可能であるかのいずれかであり得ると仮定される。

例示的な実施形態では、ＬＢＴ帯域幅ピースの各々についてのガード帯域は、レートマッチングパターンとしてＲＲＣを介して設定される。次いで、ＰＤＳＣＨがこれらのガード帯域の周りでレートマッチングされるかどうかが、ＰＤＳＣＨをスケジュールするＤＣＩメッセージにおいて指示される。この実施形態の一部として、レートマッチングパターンの一部であるようにシグナリングされ得るＰＲＢのスパンが、ガード帯域にわたる任意のＰＲＢを含むように拡張される。

モード１で動作するとき、ＵＥは、２つのレートマッチンググループで設定され、一方は、キャリアの一方の側のガード帯域にマッピングするリソースセットをもち、他方は、キャリアの反対側のガード帯域にマッピングするリソースセットをもつ。次いで、ＤＣＩメッセージは、２ビット、すなわち、各レートマッチンググループについて１ビットを含むように設定される。次いで、ＰＤＳＣＨのために利用不可能なリソースが、ＤＣＩビットがセットされるレートマッチンググループに対応するリソースセットのユニオンとして決定される。

モード２ｂで動作するとき、ＵＥ設定は、ガード帯域がコンポーネントキャリアの代わりにＬＢＴ帯域幅ピースに対応する、モード１のＵＥ設定と同様であり得る。ＵＥが複数の帯域幅パートで動作している場合、既存のＮＲ能力が、この実施形態の一部として教示される設定で使用され得る。ＵＥが、帯域幅パート内の複数のＰＤＣＣＨ／ＰＤＳＣＨで動作している場合、この実施形態の一部として、レートマッチングリソース規定は、現在の仕様において帯域幅パートごとにおよびセルごとに規定されることに加えて、受信されたＤＣＩメッセージごとに規定される。

図３および図４に示されているように、４つのＬＢＴ帯域幅ピースをもつモード２ａで動作するとき、周りでレートマッチングされ得る８つのガード帯域がある。ここで、図５を考慮すると、ガード帯域は、１から８まで上から下へ順に番号を付けられる。図５に示されているように、隣接キャリアの間にあるガード帯域も隣接し、たとえば、ガード帯域２とガード帯域３とは隣接する、ガード帯域４とガード帯域５とは隣接する、などである。次いで、すべての関連するレートマッチングシナリオが、ＤＣＩメッセージを介して動的に指示され得るレートマッチンググループの数を３に拡大することと、以下のように各レートマッチンググループを規定することとによって、対処され得る。
・ レートマッチンググループ１は、ガード帯域２および３を含む
・ レートマッチンググループ２は、ガード帯域４および５を含む
・ レートマッチンググループ３は、ガード帯域６および７を含む

次いで、各レートマッチンググループについてのＤＣＩ中の１ビットを用いて、すべての必要なレートマッチングパターンは、各グループにおけるレートマッチングパターンのユニオンが、ＰＤＳＣＨ受信のために利用不可能であるリソースのセットを形成するように、レートマッチンググループについての関連するビットを１にセットすることによって指示され得る。

ＤＣＩサイズが、２ビットの現在のサイズを超えて増加されるべきでないことが望まれる場合、この実施形態の一例では、以下のリソースセットが、レートマッチンググループの各々についてＵＥに設定される。ガード帯域２、３、４および５が、あるレートマッチンググループ中に含まれ、ガード帯域２、３、６および７が、別のレートマッチンググループ中に含まれる。これはまた、レートマッチング情報が提供されないガード帯域が、周りでレートマッチングされるべきであるか否かを決定するために、前の実施形態の場合のように暗黙的ルールと組み合わせられ得る。

動的シグナリングを使用することの利点は、ｇＮＢが、動的にガード帯域がチャネル占有中にいつ使用されるべきであるかを判定することができることである。また、レートマッチングパターンを規定するための既存の機構の使用が、ガード帯域の幅を制御することにおけるフレキシビリティをも可能にする。

例示的な実施形態５ － 持続時間における適応
以下の実施形態は、８０ＭＨｚのチャネル帯域幅と、個々の２０ＭＨｚピース上でＬＢＴを実施することとに関して説明される。ただし、その教示は、他のチャネル帯域幅およびＬＢＴ帯域幅サイズについて実践され得る。

モード２ａで動作するとき、８０ＭＨｚにわたってチャネルを取得する前に、送信機は、１つの２０ＭＨｚ上で送信するのに好適なトランスポートブロックを準備する。送信機は、いくつかの異なるＰＤＣＣＨをさらに準備する。
・ １つのＰＤＣＣＨタイプは、全８０ＭＨｚが利用可能であり、ＤＣＩが、４つのＯＦＤＭシンボル長のみの時間ドメイン割り当てを含んでいる場合を対象とする。
・ １つのＰＤＣＣＨタイプは、４０ＭＨｚのみが利用可能であり、ＤＣＩが、７つのＯＦＤＭシンボル長のみの時間ドメイン割り当てを含んでいる場合を対象とする。
・ １つのＰＤＣＣＨタイプは、２０ＭＨｚのみが利用可能であり、ＤＣＩが、１４個のＯＦＤＭシンボル長の時間ドメイン割り当てを含んでいる場合を対象とする。

ＬＢＴの結果に基づいて、上記の生成されたＰＤＣＣＨからの少なくとも１つのＰＤＣＣＨが、スロットの最初に送信される。ＰＤＣＣＨに続いて、送信機は、１４個、７つまたは４つのＯＦＤＭシンボルの対応する持続時間をもつ、２０、４０または８０ＭＨｚのうちの１つ上で、トランスポートブロックのためのコード化信号を送る。

上記のＰＤＣＣＨに加えて、送信機は、不連続なブロックの送信が必要とされる様式でＬＢＴ失敗が起こるときにチャネル上で送信することが可能であるために、他の組合せをも準備し得、たとえば、以下の通りである。
・ ７つのシンボルの時間ドメイン割り当てをもつ、ＬＢＴが成功した２つの不連続な２０ＭＨｚ帯域幅ピースがある場合を対象としたＰＤＣＣＨ、
・ ＬＢＴが成功した２つの不連続な帯域幅ピース、２０ＭＨｚ幅である帯域幅ピースと４０ＭＨｚ幅である帯域幅ピースとがある場合を対象としたＰＤＣＣＨ。この場合についての時間ドメイン割り当ては、１０個のシンボルであり得る。

説明される実施形態は、任意の好適な通信規格をサポートし、任意の好適な構成要素を使用する任意の適切なタイプの通信システムにおいて実装され得る。一例として、いくつかの実施形態は、図１に示されているものなど、ＮＲネットワークにおいて実装され得る。

図１を参照すると、通信ネットワーク１００が、複数の無線通信デバイス１０５（たとえば、従来のＵＥ、マシン型通信［ＭＴＣ］／マシンツーマシン［Ｍ２Ｍ］ＵＥ）と、複数の無線アクセスノード１１０（たとえば、ｇノードＢまたは他の基地局）とを備える。通信ネットワーク１００は、対応する無線アクセスノード１１０を介してコアネットワーク１２０に接続されるセル１１５に編成される。無線アクセスノード１１０は、無線通信デバイス間の、または無線通信デバイスと（固定電話などの）別の通信デバイスとの間の通信をサポートすることに適した追加のエレメントとともに、無線通信デバイス１０５と通信することが可能である。

無線通信デバイス１０５は、ハードウェアおよび／またはソフトウェアの任意の好適な組合せを含む通信デバイスを表し得るが、これらの無線通信デバイスは、いくつかの実施形態では、図２によってより詳細に示されている例示的な無線通信デバイスなど、デバイスを表し得る。同様に、示されている無線アクセスノードは、ハードウェアおよび／またはソフトウェアの任意の好適な組合せを含むネットワークノードを表し得るが、これらのノードは、特定の実施形態では、図３によってより詳細に示されている例示的な無線アクセスノードなど、デバイスを表し得る。

図２を参照すると、無線通信デバイス２００が、プロセッサ２０５と、メモリと、トランシーバ２１５と、アンテナ２２０とを備える。いくつかの実施形態では、ＵＥ、ＭＴＣまたはＭ２Ｍデバイス、および／あるいは他のタイプの無線通信デバイスによって提供されるものとして説明される機能の一部または全部は、図２に示されているメモリなど、コンピュータ可読媒体に記憶された命令を実行するデバイスプロセッサによって提供され得る。代替実施形態は、本明細書で、ならびに、特に、図４、図５、図１３、および図１４で説明される機能のいずれかを含む、デバイスの機能のいくつかの態様を提供することを担当し得る、図２に示されている構成要素以外の追加の構成要素を含み得る。デバイスプロセッサ２０５は、１つまたは複数のマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサなどを備え得、これらの１つまたは複数の処理エレメントは、トランシーバ２１５を制御し、本明細書で説明される機能の全部または一部を実行するために、メモリ２１０に記憶されたプログラムコードを実行するように設定され、デバイスプロセッサ２０５は、いくつかの実施形態では、たとえば、図４、図５、図１３、および図１４に示されているプロセスステップを含む、本明細書で説明される機能の全部または一部を行うハードコード化デジタル論理を含み得ることが諒解されよう。「処理回路」という用語は、処理エレメントのこれらの組合せのうちのいずれか１つを指すために本明細書で使用される。

図３を参照すると、無線アクセスノード３００が、ノードプロセッサ３０５と、メモリ３１０と、ネットワークインターフェース３１５と、トランシーバ３２０と、アンテナ３２５とを備える。同じく、ノードプロセッサ３０５は、１つまたは複数のマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサなどを備え得、これらの１つまたは複数の処理エレメントは、トランシーバ３２０およびネットワーク３１５を制御し、本明細書で説明される機能の全部または一部を実行するために、メモリ３１０に記憶されたプログラムコードを実行するように設定され、ノードプロセッサ３０５は、いくつかの実施形態では、本明細書で説明される機能の全部または一部を行うハードコード化デジタル論理を含み得ることが諒解されよう。この機能は、たとえば、図４、図５、図１３、および図１４のフローチャートに示されている動作を含む。「処理回路」という用語は、処理エレメントのこれらの組合せのうちのいずれか１つを指すために本明細書で使用される。

したがって、いくつかの実施形態では、基地局、ノードＢ、ｅノードＢ、および／または他のタイプのネットワークノードによって提供されるものとして説明される機能の一部または全部は、図３に示されているメモリ３１０など、コンピュータ可読媒体に記憶された命令を実行するノードプロセッサ３０５によって提供され得る。同じく、この機能は、たとえば、図４、図５、図１３、および図１４のフローチャートに示されている動作を含む。無線アクセスノード３００の代替実施形態は、本明細書で説明される機能および／または関係するサポート機能など、追加の機能を提供するための追加の構成要素を備え得る。

図４は、第２のノード（たとえば、無線アクセスノード１１０）からデータ送信を受信するために第１のノード（たとえば、無線デバイス１０５）を動作させる、例示的な方法４００を示すフローチャートである。方法４００は、少なくとも１つのデータチャネルにおいて使用するために帯域幅パートにおいて複数の無線リソース（たとえば、物理リソースブロックまたはそれらの部分）を割り当てる制御メッセージが第２のノードから受信される、ステップＳ４０５を含む。データチャネルは、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）または物理アップリンク共有チャネル（ＰＵＳＣＨ）であり得る。帯域幅パートは、複数の帯域幅ピースに分割される。ＬＢＴプロシージャが、複数の帯域幅ピースの各々上で、帯域幅ピースが第１のノードへの／からのデータ送信の送信のために利用可能であるかどうかを決定するために実施され得る。方法は、データ送信が、複数の帯域幅ピースのうちの少なくとも１つに対応する無線リソースを使用して、第２のノードから受信されるかまたは第２のノードに送信される、ステップＳ４１５をさらに含む。特に、データ送信を受信または送信するために使用される無線リソースは、帯域幅ピースのうちの２つの間に位置する少なくとも１つのガード帯域の少なくとも一部分にマッピングする１つまたは複数の無線リソースを除外する。１つまたは複数の無線リソースの除外は、たとえば、上記でさらに詳細に説明されたように、データ送信をパンクチャするかまたはレートマッチングすることによって達成され得る。

方法４００は、ステップＳ４０８とステップＳ４０９とを含む、追加の随意のステップをさらに含み得る。ステップＳ４０８において、第１のノードは、１つまたは複数の帯域幅ピースの周波数連続（ｆｒｅｑｕｅｎｃｙ－ｃｏｎｔｉｇｕｏｕｓ）ブロックがデータ送信の受信または送信のために使用されるべきであると決定する。ステップＳ４０９において、第１のノードは、周波数連続ブロックにマッピングする無線リソースのうち、周波数連続ブロックのエッジにおけるガード帯域にマッピングする１つまたは複数の無線リソースのみが、データ送信を受信または送信するために使用されることから除外されると決定する。いくつかの実施形態では、ステップＳ４０５において参照される制御メッセージ（または、代替的に、別の制御メッセージ）は、１つまたは複数の帯域幅ピースの周波数連続ブロックがデータ送信の受信または送信のために使用されるべきであるという指示を含み、ステップＳ４０８において決定することは、その指示に少なくとも部分的に基づく。

その上、いくつかの実施形態では、ステップＳ４０９において、周波数連続ブロックのエッジにおけるガード帯域にマッピングする１つまたは複数の無線リソースのみが、データ送信を受信または送信するために使用されることから除外されると決定することは、関連する通信規格におけるルールなど、あらかじめ決定されたまたはあらかじめプログラムされたルールに少なくとも部分的に基づく。代替的に、ステップＳ４０９において決定することは、第１のノードが第２のノードからデータ送信を受信しているとき、第２のノードからの暗黙的指示に少なくとも部分的に基づく（データ送信が第１のノードから第２のノードに送信されるとき、第１のノードは第２のノードに暗黙的指示を送る）。暗黙的指示は、２つまたはそれ以上の周波数連続帯域幅ピースにおける復調用参照信号（ＤＭＲＳ）の成功した検出を含み得る。代わりに、または追加として、暗黙的指示は、１つまたは複数の周波数連続帯域幅ピースの合間のガード帯域にマッピングする１つまたは複数の無線リソースにおけるＤＭＲＳの成功した検出を含み得る。ＤＭＲＳの成功した検出は、対応するガード帯域が割り当てられたことをデータ送信受信ノードに暗黙的に指示する。図４では、ステップＳ４０８およびＳ４０９は、ステップＳ４１５におけるデータ送信の受信または送信に先行して示されているが、代わりに、ステップＳ４０８およびＳ４０９は、ステップＳ４１５におけるデータ送信の受信または送信の後に、あるいはその一部として実施され得る。

方法は、いくつかの実施形態では、ステップＳ４１５におけるデータ送信の受信／送信に先行する随意のステップＳ４１０をまたさらに含み得る。ステップＳ４１０において、データ送信のための使用から除外される１つまたは複数の無線リソースに対応する少なくとも１つのガード帯域またはそれの部分を第１のノードに指示する制御メッセージが受信される。制御メッセージは、１つまたは複数のビットを含み得、１つまたは複数のビットの各々は、帯域幅ピースの間に位置する複数のガード帯域のうちの少なくとも１つに対応し、対応する少なくとも１つのガード帯域にマッピングする少なくとも１つまたは複数の無線リソースがデータ送信のための使用から除外されるかどうかを第１のノードに指示する。制御メッセージ中のビットは、複数のガード帯域（たとえば、周波数連続であるガード帯域）のうちの複数のガード帯域に対応し得る。いくつかの実施形態では、少なくとも１つのガード帯域またはそれの部分を指示する制御メッセージは、帯域幅パートにおいて複数の無線リソースを割り当てる、ステップＳ４０５において参照される制御メッセージの一部として含まれる。

図５は、別のフローチャートを示し、このフローチャートは、第１のノード（たとえば、無線デバイス１０５）を動作させる別の例示的な方法５００を示す。ステップＳ５０５において見られるように、示されている方法は、第２のノード（たとえば、無線アクセスノード１１０）から、少なくとも１つのデータチャネル（たとえば、ＰＤＳＣＨまたはＰＵＳＣＨ）において使用するために帯域幅パートにおいて複数の無線リソースを割り当てる制御メッセージを受信することを含む。帯域幅パートは複数の帯域幅ピースに分割され、制御メッセージは、帯域幅ピースの各々上で実施されるＬＢＴプロシージャの結果を指示する、複数のあらかじめ決定された制御メッセージタイプ（たとえば、ＰＤＣＣＨタイプ）のうちの１つである。

ステップＳ５１０において見られるように、方法は、制御メッセージタイプに少なくとも部分的に基づいてデータ送信のための時間ドメイン割り当てを決定することをさらに含む。ステップＳ５１５において見られるように、方法は、第２のノードからまたは第２のノードに、決定された時間ドメイン割り当てに少なくとも部分的に基づいて、データ送信を受信または送信することをさらに含む。

いくつかの実施形態では、異なる時間ドメイン割り当てが、複数のあらかじめ決定された制御メッセージタイプの各々に関連し、異なる時間ドメイン割り当ては、データ送信によって占有される帯域幅に反比例して変動する。その上、いくつかの実施形態では、データ送信によって占有される帯域幅は、帯域幅ピースの各々上で実施されるＬＢＴプロシージャの結果に依存する。さらに、方法５００のいくつかの実施形態では、データ送信が第１の帯域幅を占有するとき、第１の数のＯＦＤＭシンボルの時間ドメイン割り当てが使用され、データ送信が第２の帯域幅を占有するとき、第２の数のＯＦＤＭシンボルの時間ドメイン割り当てが使用され、ＯＦＤＭシンボルの第２の数はＯＦＤＭシンボルの第１の数よりも大きく、第２の帯域幅は第１の帯域幅よりも小さい。

図１３は、第１のノード（たとえば、無線デバイス１０５）に（または第１のノードから）データ送信を送信する（または受信する）第２のノード（たとえば、無線アクセスノード１１０）を動作させる、例示的な方法１３００を示すフローチャートである。方法１３００は、少なくとも１つのデータチャネルにおいて使用するために帯域幅パートにおいて複数の無線リソース（たとえば、物理リソースブロックまたはそれらの部分）を割り当てる制御メッセージが第１のノードに送信される、ステップＳ１３０５を含む。データチャネルは、物理ダウンリンク共有チャネル（ＰＤＳＣＨ）または物理アップリンク共有チャネル（ＰＵＳＣＨ）であり得る。帯域幅パートは、複数の帯域幅ピースに分割される。ＬＢＴプロシージャが、複数の帯域幅ピースの各々上で、帯域幅ピースが第１のノードへの／からのデータ送信の送信のために利用可能であるかどうかを決定するために実施され得る。方法は、データ送信が、複数の帯域幅ピースのうちの少なくとも１つに対応する無線リソースを使用して、第１のノードに対して送信または受信される、ステップＳ１３２０をさらに含む。特に、データ送信を送信または受信するために使用される無線リソースは、帯域幅ピースのうちの２つの間に位置する少なくとも１つのガード帯域の少なくとも一部分にマッピングする１つまたは複数の無線リソースを除外する。１つまたは複数の無線リソースの除外は、たとえば、データ送信をパンクチャするかまたはレートマッチングすることによって達成され得る。

方法１３００は、ステップＳ１３１０とステップＳ１３１５とを含む、追加の随意のステップをさらに含み得る。ステップＳ１３１０において、第２のノードは、１つまたは複数の帯域幅ピースの周波数連続ブロックがデータ送信の送信のために使用されるべきであると決定する。（他のいかなる帯域幅ピースとも周波数連続でないが、使用されると決定される他の帯域幅ピースもあり得る。）周波数連続ブロックにマッピングする無線リソースの中から、データ送信の送信における使用から第２のネットワークノードによって除外される１つまたは複数の無線リソースは、周波数連続ブロックのエッジにおけるガード帯域にマッピングする１つまたは複数の無線リソースのみを含む。

ステップＳ１３１５において、第２のノードは、第１のノードに制御メッセージを送信し、制御メッセージは、データ送信における使用から除外される１つまたは複数の無線リソースに対応する少なくとも１つのガード帯域を第１のノードに指示する。

図１４は、別のフローチャートを示し、このフローチャートは、第２のノード（たとえば、無線アクセスノード１１０）を動作させる別の例示的な方法１４００を示す。ステップＳ１４０５において見られるように、示されている方法は、帯域幅パート中に含まれる複数の帯域幅ピースの各々上でＬＢＴプロシージャを実施することを含む。ステップＳ１４１０において見られるように、方法は、ＬＢＴプロシージャの結果に少なくとも部分的に基づいて複数の制御メッセージタイプのうちの１つを選択することをさらに含む。ステップＳ１４１５において見られるように、方法は、第１のノード（たとえば、無線デバイス１０５）に、制御メッセージタイプの制御メッセージを送信することをさらに含む。制御メッセージは、少なくとも１つのデータチャネルにおいて使用するために帯域幅パートにおいて複数の無線リソースを割り当て、制御メッセージタイプは、データ送信のための時間ドメイン割り当てを第１のノードに指示する。最後に、ステップＳ１４２０において見られるように、方法は、第１のノードに、指示された複数の帯域幅ピースを使用してデータ送信を送信することを含む。

図１５は、無線ネットワーク（たとえば、図１に示されている無線ネットワーク）における装置１５００の概略ブロック図を示す。装置は、無線デバイス（たとえば、それぞれ、図１および図２において示されている無線デバイス１０５または２００）において、またはネットワークノード（たとえば、それぞれ、図１および図３において示されている無線アクセスノード１１０または３００）において実装され得る。装置１５００の例示的な実施形態は、図４、図５、図１３、および図１４を参照しながら説明された例示的な方法、ならびに、場合によっては、本明細書で開示される任意の他のプロセスまたは方法のうちのいずれか１つを行うように動作可能である。また、図４、図５、図１３、および図１４の方法は、必ずしも装置１５００のみによって行われるとは限らないことを理解されたい。その方法の少なくともいくつかの動作は、１つまたは複数の他のエンティティによって実施され得る。

仮想装置１５００は、１つまたは複数のマイクロプロセッサまたはマイクロコントローラを含み得る、処理回路、ならびに、デジタル信号プロセッサ（ＤＳＰ）、専用デジタル論理などを含み得る、他のデジタルハードウェアを備え得る。処理回路は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ、キャッシュメモリ、フラッシュメモリデバイス、光記憶デバイスなど、１つまたはいくつかのタイプのメモリを含み得る、メモリに記憶されたプログラムコードを実行するように設定され得る。メモリに記憶されたプログラムコードは、いくつかの実施形態では、１つまたは複数の通信および／またはデータ通信プロトコルを実行するためのプログラム命令、ならびに本明細書で説明される技法のうちの１つまたは複数を行うための命令を含む。いくつかの実装形態では、処理回路は、本開示の１つまたは複数の実施形態による対応する機能を実施するために必要とされる、受信および送信ユニットならびに任意の他の好適なユニットの機能を実施するために使用され得る。

ユニットという用語は、エレクトロニクス、電気デバイス、および／または電子デバイスの分野での通常の意味を有し得、たとえば、本明細書で説明されるものなど、それぞれのタスク、プロシージャ、算出、出力、および／または表示機能を行うための、電気および／または電子回路、デバイス、モジュール、プロセッサ、メモリ、論理固体および／または個別デバイス、コンピュータプログラムまたは命令などを含み得る。

仮想化環境における動作
図１６は、いくつかの実施形態によって実装される機能が仮想化され得る、仮想化環境１６００を示す概略ブロック図である。本コンテキストでは、仮想化することは、ハードウェアプラットフォーム、記憶デバイスおよびネットワーキングリソースを仮想化することを含み得る、装置またはデバイスの仮想バージョンを作成することを意味する。本明細書で使用される仮想化は、ノード（たとえば、仮想化された基地局または仮想化された無線アクセスノード）に、あるいはデバイス（たとえば、ＵＥ、無線デバイスまたは任意の他のタイプの通信デバイス）またはそのデバイスの構成要素に適用され得、機能の少なくとも一部分が、（たとえば、１つまたは複数のネットワークにおいて１つまたは複数の物理処理ノード上で実行する、１つまたは複数のアプリケーション、構成要素、機能、仮想マシンまたはコンテナを介して）１つまたは複数の仮想構成要素として実装される、実装形態に関する。

いくつかの実施形態では、本明細書で説明される機能の一部または全部は、ハードウェアノード１６３０のうちの１つまたは複数によってホストされる１つまたは複数の仮想環境１６００において実装される１つまたは複数の仮想マシンによって実行される、仮想構成要素として実装され得る。さらに、仮想ノードが、無線アクセスノードではないか、または無線コネクティビティ（たとえば、コアネットワークノード）を必要としない実施形態では、ネットワークノードは完全に仮想化され得る。

機能は、本明細書で開示される実施形態のうちのいくつかの特徴、機能、および／または利益のうちのいくつかを実装するように動作可能な、（代替的に、ソフトウェアインスタンス、仮想アプライアンス、ネットワーク機能、仮想ノード、仮想ネットワーク機能などと呼ばれることがある）１つまたは複数のアプリケーション１６２０によって実装され得る。アプリケーション１６２０は、処理回路１６６０とメモリ１６９０とを備えるハードウェア１６３０を提供する、仮想化環境１６００において稼働される。メモリ１６９０は、処理回路１６６０によって実行可能な命令１６９５を含んでおり、それにより、アプリケーション１６２０は、本明細書で開示される特徴、利益、および／または機能のうちの１つまたは複数を提供するように動作可能である。

仮想化環境１６００は、１つまたは複数のプロセッサのセットまたは処理回路１６６０を備える、汎用または専用のネットワークハードウェアデバイス１６３０を備え、１つまたは複数のプロセッサのセットまたは処理回路１６６０は、商用オフザシェルフ（ＣＯＴＳ）プロセッサ、専用の特定用途向け集積回路（ＡＳＩＣ）、あるいは、デジタルもしくはアナログハードウェア構成要素または専用プロセッサを含む任意の他のタイプの処理回路であり得る。各ハードウェアデバイスはメモリ１６９０－１を備え得、メモリ１６９０－１は、処理回路１６６０によって実行される命令１６９５またはソフトウェアを一時的に記憶するための非永続的メモリであり得る。各ハードウェアデバイスは、ネットワークインターフェースカードとしても知られる、１つまたは複数のネットワークインターフェースコントローラ（ＮＩＣ）１６７０を備え得、ネットワークインターフェースコントローラ（ＮＩＣ）１６７０は物理ネットワークインターフェース１６８０を含む。各ハードウェアデバイスは、処理回路１６６０によって実行可能なソフトウェア１６９５および／または命令を記憶した、非一時的、永続的、機械可読記憶媒体１６９０－２をも含み得る。ソフトウェア１６９５は、１つまたは複数の（ハイパーバイザとも呼ばれる）仮想化レイヤ１６５０をインスタンス化するためのソフトウェア、仮想マシン１６４０を実行するためのソフトウェア、ならびに、それが、本明細書で説明されるいくつかの実施形態との関係において説明される機能、特徴および／または利益を実行することを可能にする、ソフトウェアを含む、任意のタイプのソフトウェアを含み得る。

仮想マシン１６４０は、仮想処理、仮想メモリ、仮想ネットワーキングまたはインターフェース、および仮想ストレージを備え、対応する仮想化レイヤ１６５０またはハイパーバイザによって稼働され得る。仮想アプライアンス１６２０の事例の異なる実施形態が、仮想マシン１６４０のうちの１つまたは複数上で実装され得、実装は異なるやり方で行われ得る。

動作中に、処理回路１６６０は、ソフトウェア１６９５を実行してハイパーバイザまたは仮想化レイヤ１６５０をインスタンス化し、ハイパーバイザまたは仮想化レイヤ１６５０は、時々、仮想マシンモニタ（ＶＭＭ）と呼ばれることがある。仮想化レイヤ１６５０は、仮想マシン１６４０に、ネットワーキングハードウェアのように見える仮想動作プラットフォームを提示し得る。

図１６に示されているように、ハードウェア１６３０は、一般的なまたは特定の構成要素をもつスタンドアロンネットワークノードであり得る。ハードウェア１６３０は、アンテナ１６２２５を備え得、仮想化を介していくつかの機能を実装し得る。代替的に、ハードウェア１６３０は、多くのハードウェアノードが協働し、特に、アプリケーション１６２０のライフサイクル管理を監督する、管理およびオーケストレーション（ＭＡＮＯ）１６１００を介して管理される、（たとえば、データセンタまたは顧客構内機器（ＣＰＥ）の場合のような）ハードウェアのより大きいクラスタの一部であり得る。

ハードウェアの仮想化は、いくつかのコンテキストにおいて、ネットワーク機能仮想化（ＮＦＶ）と呼ばれる。ＮＦＶは、多くのネットワーク機器タイプを、データセンタおよび顧客構内機器中に位置し得る、業界標準高ボリュームサーバハードウェア、物理スイッチ、および物理ストレージ上にコンソリデートするために使用され得る。

ＮＦＶのコンテキストでは、仮想マシン１６４０は、プログラムを、それらのプログラムが、物理的な仮想化されていないマシン上で実行しているかのように稼働する、物理マシンのソフトウェア実装形態であり得る。仮想マシン１６４０の各々と、その仮想マシンに専用のハードウェアであろうと、および／またはその仮想マシンによって仮想マシン１６４０のうちの他の仮想マシンと共有されるハードウェアであろうと、その仮想マシンを実行するハードウェア１６３０のその一部とは、別個の仮想ネットワークエレメント（ＶＮＥ）を形成する。

さらにＮＦＶのコンテキストでは、仮想ネットワーク機能（ＶＮＦ）は、ハードウェアネットワーキングインフラストラクチャ１６３０の上の１つまたは複数の仮想マシン１６４０において稼働する特定のネットワーク機能をハンドリングすることを担当し、図１６中のアプリケーション１６２０に対応する。

いくつかの実施形態では、各々、１つまたは複数の送信機１６２２０と１つまたは複数の受信機１６２１０とを含む、１つまたは複数の無線ユニット１６２００は、１つまたは複数のアンテナ１６２２５に結合され得る。無線ユニット１６２００は、１つまたは複数の適切なネットワークインターフェースを介してハードウェアノード１６３０と直接通信し得、無線アクセスノードまたは基地局など、無線能力をもつ仮想ノードを提供するために仮想構成要素と組み合わせて使用され得る。

いくつかの実施形態では、何らかのシグナリングが、ハードウェアノード１６３０と無線ユニット１６２００との間の通信のために代替的に使用され得る制御システム１６２３０を使用して、実現され得る。

リモートホストコンピュータとの動作
図１７を参照すると、一実施形態によれば、通信システムが、無線アクセスネットワークなどのアクセスネットワーク１７１１とコアネットワーク１７１４とを備える、３ＧＰＰタイプセルラネットワークなどの通信ネットワーク１７１０を含む。アクセスネットワーク１７１１は、ＮＢ、ｅＮＢ、ｇＮＢまたは他のタイプの無線アクセスポイントなど、複数の基地局１７１２ａ、１７１２ｂ、１７１２ｃを備え、各々が、対応するカバレッジエリア１７１３ａ、１７１３ｂ、１７１３ｃを規定する。各基地局１７１２ａ、１７１２ｂ、１７１２ｃは、有線接続または無線接続１７１５上でコアネットワーク１７１４に接続可能である。カバレッジエリア１７１３ｃ中に位置する第１のＵＥ１７９１が、対応する基地局１７１２ｃに無線で接続するか、または対応する基地局１７１２Ｃによってページングされるように設定される。カバレッジエリア１７１３ａ中の第２のＵＥ１７９２が、対応する基地局１７１２ａに無線で接続可能である。この例では複数のＵＥ１７９１、１７９２が示されているが、開示される実施形態は、唯一のＵＥがカバレッジエリア中にある状況、または唯一のＵＥが、対応する基地局１７１２に接続している状況に等しく適用可能である。

通信ネットワーク１７１０は、それ自体、ホストコンピュータ１７３０に接続され、ホストコンピュータ１７３０は、スタンドアロンサーバ、クラウド実装サーバ、分散サーバのハードウェアおよび／またはソフトウェアにおいて、あるいはサーバファーム中の処理リソースとして具現され得る。ホストコンピュータ１７３０は、サービスプロバイダの所有または制御下にあり得、あるいはサービスプロバイダによってまたはサービスプロバイダに代わって動作され得る。通信ネットワーク１７１０とホストコンピュータ１７３０との間の接続１７２１および１７２２は、コアネットワーク１７１４からホストコンピュータ１７３０に直接延び得るか、または随意の中間ネットワーク１７２０を介して進み得る。中間ネットワーク１７２０は、パブリックネットワーク、プライベートネットワーク、またはホストされたネットワークのうちの１つ、またはそれらのうちの２つ以上の組合せであり得、中間ネットワーク１７２０は、もしあれば、バックボーンネットワークまたはインターネットであり得、特に、中間ネットワーク１７２０は、２つまたはそれ以上のサブネットワーク（図示せず）を備え得る。

図１７の通信システムは全体として、接続されたＵＥ１７９１、１７９２とホストコンピュータ１７３０との間のコネクティビティを可能にする。コネクティビティは、オーバーザトップ（ＯＴＴ）接続１７５０として説明され得る。ホストコンピュータ１７３０および接続されたＵＥ１７９１、１７９２は、アクセスネットワーク１７１１、コアネットワーク１７１４、任意の中間ネットワーク１７２０、および考えられるさらなるインフラストラクチャ（図示せず）を媒介として使用して、ＯＴＴ接続１７５０を介して、データおよび／またはシグナリングを通信するように設定される。ＯＴＴ接続１７５０は、ＯＴＴ接続１７５０が通過する、参加する通信デバイスが、アップリンクおよびダウンリンク通信のルーティングに気づいていないという意味で、透過的であり得る。たとえば、基地局１７１２は、接続されたＵＥ１７９１にフォワーディング（たとえば、ハンドオーバ）されるべき、ホストコンピュータ１７３０から発生したデータを伴う着信ダウンリンク通信の過去のルーティングについて、知らされないことがあるかまたは知らされる必要がない。同様に、基地局１７１２は、ＵＥ１７９１から発生してホストコンピュータ１７３０に向かう発信アップリンク通信の将来のルーティングに気づいている必要がない。

次に、一実施形態による、前の段落において説明されたＵＥ、基地局およびホストコンピュータの例示的な実装形態が、図１８を参照しながら説明される。通信システム１８００では、ホストコンピュータ１８１０が、通信システム１８００の異なる通信デバイスのインターフェースとの有線接続または無線接続をセットアップおよび維持するように設定された通信インターフェース１８１６を含む、ハードウェア１８１５を備える。ホストコンピュータ１８１０は、記憶能力および／または処理能力を有し得る、処理回路１８１８をさらに備える。特に、処理回路１８１８は、１つまたは複数のプログラマブルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、または、命令を実行するように適応されたこれらの組合せ（図示せず）を備え得る。ホストコンピュータ１８１０は、ホストコンピュータ１８１０に記憶されるかまたはホストコンピュータ１８１０によってアクセス可能であり、処理回路１８１８によって実行可能である、ソフトウェア１８１１をさらに備える。ソフトウェア１８１１は、ホストアプリケーション１８１２を含む。ホストアプリケーション１８１２は、ＵＥ１８３０およびホストコンピュータ１８１０において終端するＯＴＴ接続１８５０を介して接続するＵＥ１８３０など、リモートユーザにサービスを提供するように動作可能であり得る。リモートユーザにサービスを提供する際に、ホストアプリケーション１８１２は、ＯＴＴ接続１８５０を使用して送信されるユーザデータを提供し得る。

通信システム１８００は、通信システム中に提供される基地局１８２０をさらに含み、基地局１８２０は、基地局１８２０がホストコンピュータ１８１０およびＵＥ１８３０と通信することを可能にするハードウェア１８２５を備える。ハードウェア１８２５は、通信システム１８００の異なる通信デバイスのインターフェースとの有線接続または無線接続をセットアップおよび維持するための通信インターフェース１８２６、ならびに基地局１８２０によってサーブされるカバレッジエリア（図１８に図示せず）中に位置するＵＥ１８３０との少なくとも無線接続１８７０をセットアップおよび維持するための無線インターフェース１８２７を含み得る。通信インターフェース１８２６は、ホストコンピュータ１８１０への接続１８６０を容易にするように設定され得る。接続１８６０は直接であり得るか、あるいは、接続１８６０は、通信システムのコアネットワーク（図１８に図示せず）を、および／または通信システムの外部の１つまたは複数の中間ネットワークを通過し得る。図示の実施形態では、基地局１８２０のハードウェア１８２５は、処理回路１８２８をさらに含み、処理回路１８２８は、１つまたは複数のプログラマブルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、または、命令を実行するように適応されたこれらの組合せ（図示せず）を備え得る。基地局１８２０は、内部的に記憶されるかまたは外部接続を介してアクセス可能なソフトウェア１８２１をさらに有する。

通信システム１８００は、すでに言及されたＵＥ１８３０をさらに含む。ＵＥ１８３０のハードウェア１８３５は、ＵＥ１８３０が現在位置するカバレッジエリアをサーブする基地局との無線接続１８７０をセットアップおよび維持するように設定された、無線インターフェース１８３７を含み得る。ＵＥ１８３０のハードウェア１８３５は、処理回路１８３８をさらに含み、処理回路１８３８は、１つまたは複数のプログラマブルプロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイ、または、命令を実行するように適応されたこれらの組合せ（図示せず）を備え得る。ＵＥ１８３０は、ＵＥ１８３０に記憶されるかまたはＵＥ１８３０によってアクセス可能であり、処理回路１８３８によって実行可能である、ソフトウェア１８３１をさらに備える。ソフトウェア１８３１はクライアントアプリケーション１８３２を含む。クライアントアプリケーション１８３２は、ホストコンピュータ１８１０のサポートのもとに、ＵＥ１８３０を介して人間のまたは人間でないユーザにサービスを提供するように動作可能であり得る。ホストコンピュータ１８１０では、実行しているホストアプリケーション１８１２は、ＵＥ１８３０およびホストコンピュータ１８１０において終端するＯＴＴ接続１８５０を介して、実行しているクライアントアプリケーション１８３２と通信し得る。ユーザにサービスを提供する際に、クライアントアプリケーション１８３２は、ホストアプリケーション１８１２から要求データを受信し、要求データに応答してユーザデータを提供し得る。ＯＴＴ接続１８５０は、要求データとユーザデータの両方を転送し得る。クライアントアプリケーション１８３２は、クライアントアプリケーション１８３２が提供するユーザデータを生成するためにユーザと対話し得る。

図１８に示されているホストコンピュータ１８１０、基地局１８２０およびＵＥ１８３０は、それぞれ、図２７のホストコンピュータ２７３０、基地局２７１２ａ、２７１２ｂ、２７１２ｃのうちの１つ、およびＵＥ２７９１、２７９２のうちの１つと同様または同等であり得ることに留意されたい。つまり、これらのエンティティの内部の働きは、図１８に示されているようなものであり得、別個に、周囲のネットワークトポロジーは、図２７のものであり得る。

図１８では、ＯＴＴ接続１８５０は、仲介デバイスとこれらのデバイスを介したメッセージの正確なルーティングとへの明示的言及なしに、基地局１８２０を介したホストコンピュータ１８１０とＵＥ１８３０との間の通信を示すために抽象的に描かれている。ネットワークインフラストラクチャが、ルーティングを決定し得、ネットワークインフラストラクチャは、ＵＥ１８３０からまたはホストコンピュータ１８１０を動作させるサービスプロバイダから、またはその両方からルーティングを隠すように設定され得る。ＯＴＴ接続１８５０がアクティブである間、ネットワークインフラストラクチャは、さらに、ネットワークインフラストラクチャが（たとえば、ネットワークの負荷分散考慮または再設定に基づいて）ルーティングを動的に変更する判定を行い得る。

ＵＥ１８３０と基地局１８２０との間の無線接続１８７０は、本開示全体にわたって説明される実施形態の教示に従う。様々な実施形態のうちの１つまたは複数は、無線接続１８７０が最後のセグメントを形成するＯＴＴ接続１８５０を使用して、ＵＥ１８３０に提供されるＯＴＴサービスの性能を改善する。より正確には、これらの実施形態の教示は、特に、データレートを改善し、それにより、ファイルサイズ／分解能に対する緩和された制限、およびより良い応答性などの利益を提供し得る。

１つまたは複数の実施形態が改善する、データレート、レイテンシおよび他のファクタを監視する目的での、測定プロシージャが提供され得る。測定結果の変動に応答して、ホストコンピュータ１８１０とＵＥ１８３０との間のＯＴＴ接続１８５０を再設定するための随意のネットワーク機能がさらにあり得る。測定プロシージャおよび／またはＯＴＴ接続１８５０を再設定するためのネットワーク機能は、ホストコンピュータ１８１０のソフトウェア１８１１およびハードウェア１８１５でまたはＵＥ１８３０のソフトウェア１８３１およびハードウェア１８３５で、またはその両方で実装され得る。実施形態では、ＯＴＴ接続１８５０が通過する通信デバイスにおいてまたはそれに関連して、センサー（図示せず）が展開され得、センサーは、上記で例示された監視された量の値を供給すること、またはソフトウェア１８１１、１８３１が監視された量を算出または推定し得る他の物理量の値を供給することによって、測定プロシージャに参加し得る。ＯＴＴ接続１８５０の再設定は、メッセージフォーマット、再送信セッティング、好ましいルーティングなどを含み得、再設定は、基地局１８２０に影響を及ぼす必要がなく、再設定は、基地局１８２０に知られていないかまたは知覚不可能であり得る。そのようなプロシージャおよび機能は、当技術分野において知られ、実践され得る。いくつかの実施形態では、測定は、スループット、伝搬時間、レイテンシなどのホストコンピュータ１８１０の測定を容易にするプロプライエタリＵＥシグナリングを伴い得る。測定は、ソフトウェア１８１１および１８３１が、ソフトウェア１８１１および１８３１が伝搬時間、エラーなどを監視する間にＯＴＴ接続１８５０を使用して、メッセージ、特に空のまたは「ダミー」メッセージが送信されることを引き起こすことにおいて、実装され得る。

図１９は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図１７および図１８を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示の簡単のために、図１９への図面参照のみがこのセクションに含まれる。ステップ１９１０において、ホストコンピュータはユーザデータを提供する。ステップ１９１０の（随意であり得る）サブステップ１９１１において、ホストコンピュータは、ホストアプリケーションを実行することによって、ユーザデータを提供する。ステップ１９２０において、ホストコンピュータは、ＵＥにユーザデータを搬送する送信を始動する。（随意であり得る）ステップ１９３０において、基地局は、本開示全体にわたって説明される実施形態の教示に従って、ホストコンピュータが始動した送信において搬送されたユーザデータをＵＥに送信する。（また、随意であり得る）ステップ１９４０において、ＵＥは、ホストコンピュータによって実行されるホストアプリケーションに関連するクライアントアプリケーションを実行する。

図２０は、一実施形態による、通信システムにおいて実装される方法を示すフローチャートである。通信システムは、図１７および図１８を参照しながら説明されたものであり得る、ホストコンピュータと基地局とＵＥとを含む。本開示の簡単のために、図２０への図面参照のみがこのセクションに含まれる。方法のステップ２０１０において、ホストコンピュータはユーザデータを提供する。随意のサブステップ（図示せず）において、ホストコンピュータは、ホストアプリケーションを実行することによって、ユーザデータを提供する。ステップ２０２０において、ホストコンピュータは、ＵＥにユーザデータを搬送する送信を始動する。送信は、本開示全体にわたって説明される実施形態の教示に従って、基地局を介して進み得る。（随意であり得る）ステップ２０３０において、ＵＥは、送信において搬送されたユーザデータを受信する。

上記で説明されたように、例示的な実施形態は、方法と、方法のステップを実施するための機能を提供する様々なモジュールからなる対応する装置との両方を提供する。モジュールは、ハードウェアとして実装され（特定用途向け集積回路などの集積回路を含む１つまたは複数のチップにおいて具現され）得るか、あるいはプロセッサによる実行のためのソフトウェアまたはファームウェアとして実装され得る。特に、ファームウェアまたはソフトウェアの場合、例示的な実施形態は、コンピュータプロセッサによる実行のためのコンピュータプログラムコード（すなわち、ソフトウェアまたはファームウェア）をその上に具現するコンピュータ可読記憶媒体を含むコンピュータプログラム製品として提供され得る。コンピュータ可読記憶媒体は、非一時的（たとえば、磁気ディスク、光ディスク、読取り専用メモリ、フラッシュメモリデバイス、相変化メモリ）、または一時的（たとえば、搬送波、赤外線信号、デジタル信号など、電気、光、音響、または他の形態の伝搬信号）であり得る。プロセッサと他の構成要素との結合は、一般に、１つまたは複数のバスまたは（バスコントローラとも呼ばれる）ブリッジを通したものである。記憶デバイスおよびデジタルトラフィックを搬送する信号は、それぞれ、１つまたは複数の非一時的コンピュータ可読記憶媒体または一時的コンピュータ可読記憶媒体を表す。したがって、所与の電子デバイスの記憶デバイスは、一般に、コントローラなど、その電子デバイスの１つまたは複数のプロセッサのセット上での実行のためのコードおよび／またはデータを記憶する。

実施形態およびその利点が詳細に説明されたが、添付の特許請求の範囲によって規定される、それらの趣旨および範囲から逸脱することなく、様々な変更、置換、および改変が本明細書において行われ得ることを理解されたい。たとえば、上記で説明された特徴および機能の多くは、ソフトウェア、ハードウェア、またはファームウェア、あるいはそれらの組合せにおいて実装され得る。また、特徴、機能、およびそれらを動作させるステップの多くは、並べ替え、省略、追加、などが行われ得、依然として様々な実施形態の広い範囲内に入る。

前述の説明において使用された略語は、以下を含む。
ＡＣＬＲ 隣接チャネル漏洩比
ＣＡＣＬＲ 累積隣接チャネル漏洩比
ＬＢＴ リッスンビフォアトーク
ＣＡ キャリアアグリゲーション
ＢＷＰ 帯域幅パート
ＣＣ コンポーネントキャリア
ＤＣＩ ダウンリンク制御情報
ＭＡＣ－ＣＥ 媒体アクセス制御レイヤ制御エレメント
ＲＲＣ 無線リソース制御
ＴＢ トランスポートブロック
ＴＢＳ トランスポートブロックサイズ

付録Ａ
題名： ＮＲ－Ｕのためのフレーム構造
３ＧＰＰ寄書ドキュメントの目的： 説明、決定
１ 導入
この寄書では、ＮＲ－Ｕ送信グラニュラリティ、ヌメロロジー、および広帯域動作に関係する問題を含む、ＮＲ－Ｕのためのフレーム構造に関する我々の見解を提供する。
２ ＮＲ－Ｕ送信グラニュラリティ
ＲＡＮ１＃９２ｂｉｓ中に、タイプＡおよびタイプＢ ＰｘＳＣＨマッピングに関して以下の合意がなされた。
合意：
・ ＮＲ－Ｕは、ＮＲにおいてすでにサポートされているタイプＡマッピングとタイプＢマッピングの両方をサポートする
・ ＦＦＳ： 追加の開始位置および持続時間は排除されない
このセクションでは、ＦＦＳアイテムを取り上げる。ライセンス済み動作についての３ＧＰＰ ＮＲ Ｒｅｌ－１５では、ダウンリンク制御情報（ＤＣＩ）が、物理レイヤダウンリンク制御チャネル（ＰＤＣＣＨ）上で受信される。ＰＤＣＣＨ候補は、制御リソースセット（ＣＯＲＥＳＥＴ）と呼ばれる、時間および周波数リソースのセットにマッピングされる、共通検索空間またはＵＥ固有検索空間内で検索される。ＰＤＣＣＨ候補が監視されなければならない検索空間は、無線リソース制御（ＲＲＣ）シグナリングを介してＵＥに設定される。監視周期性も、異なるＰＤＣＣＨ候補のために設定される。任意の特定のスロットにおいて、ＵＥは、１つまたは複数のＣＯＲＥＳＥＴにマッピングされ得る複数の検索空間において複数のＰＤＣＣＨ候補を監視するように設定され得る。ＰＤＣＣＨ候補は、スロットにおいて複数回、スロットごとに１回、または複数のスロットにおいて１回、監視される必要があり得る。２つの種類の送信、すなわち、タイプＡ（スロットベース）送信およびタイプＢ（ミニスロットベース）送信がある。ＤＬでは、タイプＢ送信は、２つ、４つおよび７つのシンボルの長さをもつ任意のシンボルにおいて開始され得る。ＵＬでは、タイプＢ送信は、｛２および１４｝シンボルの間の任意の長さをもつ任意のシンボルにおいて開始され得る。
所見１ － ＮＲ Ｒｅｌ１５は、任意のシンボルにおいて開始するＤＬおよびＵＬ送信をサポートする。
所見２ － 開始点の周期性は、ＣＯＲＥＳＥＴおよび検索空間ＲＲＣ設定によって制御される。監視周期性は、サポートされるタイプＢ送信持続時間から分離される。
提案１ － 追加のＤＬまたはＵＬ開始位置は、ＮＲ－Ｕのために必要とされない
３ ＮＲ－Ｕのためのヌメロロジー
ＲＡＮ１＃９２ｂｉｓ中に、ヌメロロジーに関して以下の合意がなされた。
合意：
・ サブ７ＧＨｚについて、ＮＲ－Ｕは、ＳＣＳ、１５／３０／６０ｋＨｚを研究する
・ 異なるＳＣＳ間の性能差を研究する
・ ＵＬ設計への変更が、ＰＳＤおよびＯＣＢ要件を満たすために必要とされるかどうかを研究する
・ ６０ｋＨｚ ＳＣＳに関するＳＳブロック設計／ＲＭＳＩ／ＯＳＩが必要とされるかどうかを研究する
・ ＭＩＢおよびＳＩＢ１内容に対する影響
・ ６０ｋＨｚのためのＥＣＰの使用の必要
・ 現在ＮＲの一部であるオプションに加えて、６０ＫＨｚ ＳＣＳに関するＲＡＣＨ設計
・ 他の考慮事項は排除されない。
・ 異なるＳＣＳをもつ異なるＢＷのサポートに対する影響
以降、ＲＡＮ１＃９４中に、ヌメロロジーに関して以下の追加の合意がなされた。
合意：
・ 未ライセンス帯域上のサービングセル上のキャリアについておよび少なくとも帯域内ＣＡについて、同じヌメロロジーですべてのＤＬ信号／チャネルを動作させることが可能であることは、少なくとも以下の利益を有することが特定される（少なくともスタンドアロン動作について。ＦＦＳこれが利益であるかどうかはオペレータ間測定について実現可能である）。
〇 より低い実装複雑さ（たとえば、単一のＦＦＴ、切替えギャップなし）
〇 より低い仕様影響
〇 未ライセンス帯域における設定されたサービングセルを伴う周波数上での測定についてギャップの必要なし
・ 未ライセンス帯域上のサービングセル上のキャリアについておよび少なくとも帯域内ＣＡについて、同じヌメロロジーですべてのＵＬ信号／チャネルを動作させることが可能であることは、少なくとも以下の利益を有することが特定される。
〇 より低い実装複雑さ（たとえば、単一のＦＦＴ、切替えギャップなし）
〇 より低い仕様影響
〇 共通インターレース構造
〇 未ライセンス帯域における設定されたサービングセル上でのＳＲＳの送信についてギャップの必要なし
〇 ＦＦＳ：ＰＲＡＣＨの利益
・ ＦＦＳ： 切替えギャップを考慮する、ＤＬとＵＬとについての同じヌメロロジー
このセクションでは、第２の合意の場合のように特定のリンク方向（ＤＬまたはＵＬ）におけるすべての信号／チャネルについて単一のヌメロロジーで動作させることが有益であると特定されたことを考慮に入れて、第１の合意における研究アイテムを取り上げる。単一のヌメロロジーのための魅力的な候補は、性能の観点と、このヌメロロジーがＮＲ Ｒｅｌ－１５においてすでにサポートされているという事実との両方から、３０ｋＨｚ＋ＮＣＰであると主張する。対照的に、６０ｋＨｚおよび潜在的にＥＣＰを採用することは、極めて多数の仕様変更を必要とするが、有意な性能利益を与えない。以下では、３０ｋＨｚ対６０ｋＨｚの選定によって影響を受けるいくつかの側面について説明する。
３．１ ヌメロロジーのブラインド検出
いくつかの企業は、ＮＲ－Ｕのための３０ｋＨｚ設計と６０ｋＨｚ設計の両方が、仕様においてサポートされるべきであることと、オペレータが、展開シナリオに基づいてどちらの設計を使用すべきかを選択することとを提案する。これは、スタンドアロン展開の場合、動作帯域が、候補としての両方のヌメロロジーで規定される必要があることを意味することになる。その結果、ＵＥは、どんなヌメロロジーがＳＳ／ＰＢＣＨブロックのために使用されるかに気づいていないので、ＵＥは、各ヌメロロジー候補についてＳＳ／ＰＢＣＨの存在をブラインド検出する必要がある。実際に、ヌメロロジーに対する２つの構成要素、すなわち、（１）サブキャリア間隔（３０ｋＨｚ対６０ｋＨｚ）と、ＣＰ持続時間（ＮＣＰ対ＥＣＰ）とがあることに留意する。その場合、原則として、３つの候補、すなわち、３０ｋＨｚ＋ＮＣＰ、６０ｋＨｚ＋ＮＣＰ、および６０ｋＨｚ＋ＥＣＰが存在する。この多くの候補にわたるブラインド検出は、ＵＥ複雑さ観点から魅力的でなく、この理由で、（ライセンス済み動作のための）たいていのＮＲ動作帯域は、単一のヌメロロジー候補で規定される。遅延拡散が著しくなり得る屋外シナリオを含む、ＮＲ－Ｕのための完全な展開フレキシビリティについて、我々の見解は、１つの候補のみがサブ７ＧＨｚ帯域において可能にされる場合、それは３０ｋＨｚ＋ＮＣＰであるべきであるということである。この候補は、今日仕様においてすでにサポートされている。すべての展開シナリオを考慮する唯一の他の潜在的候補は、６０ｋＨｚ＋ＥＣＰであり、これをサポートするためにかなりの仕様変更が必要とされることになる。
所見３ － スタンドアロンシナリオにおけるＵＥブラインド検出を回避するための帯域ごとの単一のヌメロロジーのサポートは、ヌメロロジー候補（３０ｋＨｚ ＳＣＳ対６０ｋＨｚ ＳＣＳ、およびＮＣＰ対ＥＣＰ）が、展開フレキシビリティを最大にするように選定される必要があることを暗示する。
３．２ 遅延拡散およびＥＣＰ
前のセクションにおいて述べたように、屋外展開における遅延拡散は、一般に、屋内シナリオにおける遅延拡散よりも著しく大きい。これは、そのような展開のために選択されるべきであるＣＰ持続時間に下限を課する。３０ｋＨｚの場合、ＮＣＰ持続時間は約２．３５μｓであり、６０ｋＨｚの場合、ＮＣＰ持続時間は１．１７μｓである。後者の場合、これは、直接経路と反射経路との間の最大遅延差が、良好な性能を維持するために、１．１７μｓよりも小さくなるべきであることを意味する。ＲＭＳ遅延拡散は、この制約が平均的な意味において満たされることを確実にするために、さらに小さくなるべきである。
ｇＮＢが低層建築物の屋上に配置され、ＵＥが、地上において９０～２００ｍの変動する距離において近くのおよび遠くの建築物から反射を受信している、５ＧＨｚ［１］における現場測定に基づくと、ＵＥロケーションに応じて、０．７μｓまでのＲＭＳ遅延拡散が観測された。そのような展開は、たとえば、屋外モールまたは都市スクエアタイプセッティングにおいて考えられる。このレベルの遅延拡散の場合、瞬時時間遅延が、６０ｋＨｚ ＳＣＳについてのＣＰ持続時間（１．１７μｓ）を容易に超えることが観測された。［１］では、この遅延拡散の場合、（雑音＋ＩＳＩによる）ＳＩＮＲが１５ｄＢ未満に低下し、これは、ピークレートをひどく制限することがあることが示されている。［１００，１０００］ｎｓの範囲内の遅延拡散を伴うシミュレートされたリンクレベル性能が、ＴＤＬ－Ａチャネルに基づいて評価された［２］。これらの結果から、５００ｎｓを上回ると、６０ｋＨｚ ＳＣＳは、チャネル分散に対するロバストネスを向上させるためにＥＣＰが採用されない限り、過剰なＩＳＩにより使用不可能になることがわかる。しかしながら、後続のセクションにおける説明に基づくと、ＥＣＰの採用は、かなりの仕様変更を必要とし、したがって、好ましい候補ではない。ここで参照された測定およびシミュレーションに基づいて、以下のことに注目する。
所見４ － ３０ｋＨｚ＋ＮＣＰは、６０ｋＨｚ＋ＮＣＰよりも大きい展開フレキシビリティを与える。
所見５ － ６０ｋＨｚ＋ＮＣＰは、チャネル分散に対するロバストネスを改善するためにＥＣＰが使用されない限り、５００ｎｓよりも大きいＲＭＳ遅延拡散に対してブレークダウンする。
３．３ チャネルアクセスグラニュラリティ
１５ｋＨｚのベースラインと比較して、３０ｋＨｚサブキャリア間隔または６０ｋＨｚサブキャリア間隔のいずれかが、ＮＲ－Ｕのために使用される場合、送信グラニュラリティが増加され得、レイテンシが低減され得る。６０ｋＨｚは、潜在的に、タイプＡ ＰＤＳＣＨ／ＰＵＳＣＨマッピングのためのより良いアクセスグラニュラリティを提供するが、これは、６０ｋＨｚ ＳＣＳを使用する２０ＭＨｚの場合のスペクトル利用が、より大きいガード帯域により３０ｋＨｚよりも低いという事実によって相殺される。その上、３０ｋＨｚのためのタイプＢ ＰＤＳＣＨ／ＰＵＳＣＨマッピング（ミニスロット）の使用が、すでに極めて高いグラニュラリティを与える。
ここで、２つのシナリオにおける１５、３０、および６０ｋＨｚの間の性能差を、両方ともＮＲ－Ｕ評価について合意された屋内評価シナリオに基づいて、評価する。
－ 単一のＮＲ－Ｕオペレータ
－ Ｗｉ－Ｆｉオペレータと共存するＮＲ－Ｕオペレータ。
単一のオペレータの場合、オペレータの１つはトラフィックをサーブしないと仮定されることに留意されたい。ＵＬの場合、自己スケジューリングが仮定され、すなわち、グラントも未ライセンスキャリア上で送られる。また、スロットベース（タイプＡ）スケジューリングのみがアップリンクのために使用されると仮定される。ＤＬの場合、任意のシンボルにおいて開始するタイプＢスケジューリングが可能にされる。この場合、異なるＳＣＳ間の最も高いＵＬ性能差が観測され得ると考える。最終的に、ＵＥ能力＃１処理遅延がモデル化される。１）単一のＮＲ－Ｕ屋内ネットワーク展開において、および２）ＮＲ－Ｕが屋内展開において別のＷｉ－Ｆｉネットワークと共存するとき、異なるＳＣＳを使用して、低い負荷、中程度の負荷および高い負荷を表す、１２、３５および５５％のバッファ占有率について、ＵＥごとの平均ＵＬ／ＤＬオブジェクトデータレートを分析した。
ＤＬの場合、１５、３０、６０ｋＨｚの間の性能の大きい差は明白でなく、これは、タイプＢ ＰＤＳＣＨマッピングがＯＦＤＭシンボルごとのＰＤＣＣＨ監視で使用されるので、予想される。実際、ＳＣＳが増加するにつれて、性能は、より大きいオーバーヘッドおよびより大きいガード帯域により、ある程度まで劣化する。一方、ＵＬの場合、両方のシナリオ（単一のＮＲ－ＵオペレータまたはＷｉ－Ｆｉとの共存）は、３０ｋＨｚと６０ｋＨｚの両方が、１５ｋＨｚサブキャリア間隔よりも良く機能することを示す。ただし、チャネルアクセスグラニュラリティとスペクトル利用との間のトレードオフにより、３０ｋＨｚサブキャリア間隔と６０ｋＨｚサブキャリア間隔との間で微小差が観測される。利得の大部分は、ＳＣＳを１５ｋＨｚから３０ｋＨｚまで増加させることから得られる。
所見６ － 最大性能利得は、ＳＣＳを１５ｋＨｚから３０ｋＨｚまで増加させることによって達成される。３０ｋＨｚから６０ｋＨｚまでさらに増加させることによって、収穫逓減（ｄｉｍｉｎｉｓｈｉｎｇ ｒｅｔｕｒｎｓ）（さらにはＤＬにおける収穫減衰（ｄｅｃｌｉｎｉｎｇ ｒｅｔｕｒｎｓ））が達成される。
３．４ 仕様影響
上記で論証されたように、６０ｋＨｚは、チャネルアクセスグラニュラリティを考慮すると、３０ｋＨｚと比較して性能における明らかな利得を与えず、ＥＣＰなしのより大きい遅延拡散シナリオにおいて性能劣化につながることがある。さらに、６０ｋＨｚは、以下の表に見られるように、３０ｋＨｚよりもかなり大きい仕様影響を有する。

提案２ － 展開フレキシビリティ、性能、および最小限に抑えられた仕様影響の考慮により、３０ｋＨｚ＋ＮＣＰが、ＮＲ－Ｕ ＰＨＹレイヤチャネル設計およびＰＨＹレイヤプロシージャ設計について優先される。
上記の合意が、仕様影響を含めて「サブ７ＧＨｚ ＮＲ－Ｕについて、ＳＣＳ １５／３０／６０ｋＨｚを研究する」と結論付けるので、ここで、仕様影響がＴＲ３８．８８９に取り込まれることが提案される。ＴＲについてのテキスト提案を［３］に含める。
提案３ － ＴＲ３８．８８９に、ＮＲ－ＵのためのＦＲ１動作のための異なるヌメロロジー候補をサポートすることの仕様影響を取り込む。ＴＰが［３］に含まれる。
４ 広帯域動作
ＲＡＮ１＃９２ｂでは、以下の合意がなされた。
合意：
・ ＨＡＲＱ動作のための可能な拡張を研究する
・ ＮＲ－Ｕにおける設定されたグラントサポートのために必要とされる変更を研究する
・ 研究のためのベースライン： ＮＲ－Ｕが動作している帯域（サブ７ＧＨｚ）においてＷｉ－Ｆｉの不在が（たとえば、規制によって）保証され得ない場合、ＮＲ－Ｕ動作帯域幅は２０ＭＨｚの整数倍である
・ 少なくとも、Ｗｉ－Ｆｉの不在が（たとえば、規制によって）保証され得ない帯域について、ＬＢＴは２０ＭＨｚの単位で実施され得る。
・ ＦＦＳ： ２０ＭＨｚよりも大きい、すなわち、２０ＭＨｚの整数倍の帯域幅をもつシングルキャリアに関して、ＬＢＴをどのように実施すべきかに関する詳細。
このセクションでは、ＣＡベース動作と単一の広帯域キャリア動作の両方について広帯域動作のためのＬＢＴをどのように実施すべきかの詳細を考慮することによって、ＦＦＳアイテムを取り上げる。後者では、キャリア帯域幅が２０ＭＨｚよりも大きいと仮定し、２つの主要なオプション、すなわち、サブ帯域ＬＢＴ（２０ＭＨｚの単位）対広帯域ＬＢＴ（完全なＢＷＰ上でのＬＢＴ）に焦点を当てる。
ライセンス済み帯域におけるＮＲに関して、ＮＲ－Ｕは、広帯域幅（＞＞２０ＭＨｚ）にわたる送信をサポートすることになることが予想される。ＮＲ Ｒｅｌ－１５では、広帯域送信をサポートするための２つの動作モードがある。
・ モード１：ＬＴＥ－ｅＬＡＡに類似するキャリアアグリゲーション（ＣＡ）ベース広帯域動作
・ モード２：単一のアクティブ帯域幅パート（ＢＷＰ）に基づく単一の広帯域キャリア動作
図１０は、８０ＭＨｚの動作帯域幅のためのこれらの２つの動作モードの一例を示す。モード１の場合、ＵＥは、受信／送信より前にアクティブにされる、合計８０ＭＨｚになる４つのコンポーネントキャリア（ＣＣ）で設定される。上記のＲＡＮ１合意通りに、ＬＢＴは、モード１について２０ＭＨｚの単位で実施され得る。したがって、ＣＣ帯域幅とＬＢＴ帯域幅とが同一であるように、２０ＭＨｚの帯域幅で個々のＣＣを設定することは道理にかなう。一方、モード２の場合、ＵＥは、受信／送信より前にアクティブにされると仮定される、単一の８０ＭＨｚ帯域幅パート（ＢＷＰ）で設定される。図に示されているように、広帯域キャリア（ＣＣ）は、８０ＭＨｚよりも大きいことがあり、ＢＷＰは、単に、ＵＥが送信／受信のために設定される、この広帯域キャリアの一部である。このモードについて、ＬＢＴをどのように実施すべきかに関しては、依然としてＦＦＳである。
モード１の１つの主張された欠点は、各ＣＣが、ＲＡＮ４によって規定されたガード帯域を有し、そのガード帯域が、送信が完全なＢＷＰにわたって行われる場合にモード２と比較してスペクトル利用効率を低減することである。しかしながら、ＲＡＮ４観点からは、２つまたはそれ以上の連続するキャリア間のガード帯域が空のままにされるという要件はない。したがって、最適化が考慮され得、それにより、送信デバイスはガードＲＥを使用し、受信デバイスは、ＰｘＳＣＨがこれらのＲＥにマッピングされると仮定する。
提案４ － ＮＲ－ＵにおけるＣＡベース広帯域動作の場合、ＰｘＳＣＨ受信（ダウンリンクの場合ｘ＝Ｄ、およびアップリンクの場合ｘ＝Ｕ）のために２つまたはそれ以上の連続するＣＣ間のガード帯域を利用することは有益である。
モード２の場合、上記の合意通りに、ＬＢＴをどのように実施すべきかに関してはＦＦＳである。ここで考慮される２つの可能な手法は、（１）ＬＢＴが２０ＭＨｚの単位で実施されるサブ帯域ＬＢＴと、（２）ＬＢＴがＢＷＰの全帯域幅にわたって実施される広帯域ＬＢＴとである。後者では、送信は、ＢＷＰ全体が占有されていないとして検知された場合にのみ、行われる。
４．１ サブ帯域ＬＢＴ
サブ帯域ＬＢＴについて、上記の合意によれば２０ＭＨｚ幅である「ＬＢＴ帯域幅ピース」という専門用語を導入する。図３に示されているように、８０ＭＨｚ ＢＷＰは、４つのＬＢＴ帯域幅ピースからなる。原則として、ＬＢＴ帯域幅ピースが占有されていないとして検知された場合、送信は、そのＬＢＴ帯域幅ピースにおいて行われ得る。しかしながら、このタイプの動作が可能にされ得る前に考慮される必要がある、いくつかの重要な側面がある。
４．１．１ ＣＯＲＥＳＥＴ設定
図３に示されているように、少なくとも１つのＬＢＴ帯域幅ピースがＰＤＳＣＨ送信のために利用可能であるとき、制御シグナリングの利用可能性を確実にするために、別個のＣＯＲＥＳＥＴおよび検索空間が、異なるＬＢＴ帯域幅ピースのために設定される必要がある。ＬＢＴ帯域幅ピースにわたって広いＣＯＲＥＳＥＴを設定することは、ＬＢＴがそれらのピースのうちの１つ上で失敗した場合、ＰＤＣＣＨがそのＬＢＴ帯域幅ピースにおいてパンクチャされる必要があることになり、制御チャネル信頼性を劣化させるので、望ましくない。したがって、モード１とモード２の両方において、必要とされるＣＯＲＥＳＥＴの総数に関して同等である。しかしながら、ＮＲ Ｒｅｌ－１５が、ＣＣごとのＣＯＲＥＳＥＴの最大数に対する制限をセットすることに留意する。したがって、モード２は、ＢＷＰの帯域幅が増加するにつれて、最終的に困難にぶつかることになる。
所見７ － 単一の広帯域キャリア動作（モード２）は、同じ帯域幅を考慮するとき、ＣＡベース動作（モード１）と同じ、ＣＯＲＥＳＥＴの総数が設定されることを必要とする。ＣＣごとのＣＯＲＥＳＥＴの数に対する制限は、モード２についてスケーリング問題を提起し得る。
４．１．２ パンクチャリング／レートマッチング
ＮＲでは、ＰｘＳＣＨ送信が物理チャネル上で行われ得る前に、一連のトランスポートブロック（ＴＢ）処理ステップが必要とされる。そのステップは、トランスポートブロックサイズ（ＴＢＳ）決定と、その後に続く、１つまたは複数のコードブロックまたはコードブロックグループへのＴＢの可能なセグメント化、データエンコーディング、ＣＲＣアタッチメント、変調、レイヤマッピング、およびプリコーディングとを含む。これらのステップは、時間を要し、したがって、ＰｘＳＣＨ送信のためにスケジュールされたスロットに先立って実施されなければならない。その上、ＬＢＴプロシージャが、スケジュールされたスロットにちょうど先立って実施されるので、ＴＢ処理ステップの一部または全部が、同様にＬＢＴプロシージャに先立って実施されなければならない。したがって、モード２動作のためのＴＢ処理中に、送信デバイス（ｇＮＢまたはＵＥ）は、１つまたは複数のＬＢＴ帯域幅ピースがＬＢＴ失敗により利用不可能であることを考慮するためのＴＢ再処理のための時間がほとんどまたはまったくないので、すべてのＬＢＴ帯域幅ピースが送信のために利用可能であると仮定する必要があるであろう。それは、ＵＬでは、スケジューリング情報がグラントを介してｇＮＢによってすでに提供され、ＵＥがスケジューリング情報を調節するためのフレキシビリティを有しないので、より複雑になる。これは、別個のＴＢ処理がＣＣごとに実施され、１つまたは複数のＣＣが送信のために利用不可能である場合、他のＣＣにおける（１つまたは複数の）ＴＢは再処理される必要がない、モード１動作とは対照的である。
モード２の場合、そのようなタイミング制約をハンドリングし、したがって、ＴＢを完全に再処理することを回避するための１つのやり方は、送信デバイスが、ＬＢＴ失敗により利用不可能であるＬＢＴ帯域幅ピースの周りでパンクチャまたはレートマッチングすることである。前者では、ＰＤＳＣＨ ＲＥは、単にそれらのＬＢＴ帯域幅ピースにおいて送信されず、ＵＥは、復号より前に、それらのＲＥに対応するコード化ビットのためのソフト値を単に０にセットし得る。後者では、十分な処理能力を仮定して、送信デバイスにおいて部分的な再処理が実施され得る。部分的な再処理は、利用不可能なＲＥを考慮して、より高いレートにおいてＴＢを再符号化することである。どちらの手法も望ましくなく、信頼性問題を引き起こし得る。
所見８ － ＬＢＴに失敗したＬＢＴ帯域幅ピースの周りのパンクチャリング／レートマッチングは、ＰｘＳＣＨ復号失敗を引き起こし得る
４．１．３ ＢＷＰ内ガード帯域
［４］においてさらに説明されるように、モード２についての「フリー」ＬＢＴ帯域幅ピースのみにおける送信は、図１１に示されているように、ＬＢＴに失敗した隣接２０ＭＨｚ ＬＢＴ帯域幅ピースへのＲＦ漏洩を引き起こすことがある。そのような漏洩は、ＣＡベース動作（モード１）の場合にも発生する。しかしながら、ＣＡベース動作では、ＬＴＥ－ＬＡＡ［５］（セクション６．６．２．２）の場合のように、ＣＣ間のギャップについての累積ＡＣＬＲを制御するために、ガード帯域がすでに規定されている。しかしながら、モード２の場合、ＬＢＴ失敗のためのＢＷＰ内ギャップのためのチャネル内ガード帯域の概念がない。我々の理解は、そのようなガード帯域を規定することが、かなりの新たなＲＡＮ４仕様労力を必要とすることになるということである。さらに、ＲＡＮ１は、ガード帯域の周りのパンクチャリング／レートマッチングを考慮する必要があることになる。
所見９ － ＬＢＴに失敗したＬＢＴ帯域幅ピースへの隣接チャネル漏洩を制御するためのＢＷＰ内ガード帯域の導入は、かなりのＲＡＮ４仕様労力を必要とし得る
この説明に基づいて、ＢＷＰ内ガード帯域が必要とされるか否かと、ＢＷＰ内ガード帯域が必要とされる場合はＢＷＰ内の隣接チャネル漏洩要件を開発することの実現可能性とを要求する、ＬＳをＲＡＮ４に送ることを提案する。ドラフトＬＳが［６］に含まれる。
提案５ － ＢＷＰが複数のＬＢＴ帯域幅ピースにわたる広帯域キャリア動作のためにＢＷＰ内ガード帯域が必要とされるか否かを要求するＬＳをＲＡＮ４に送る。ドラフトＬＳが［６］に含まれる。
４．２ 広帯域ＬＢＴ
前述のように、広帯域ＬＢＴの場合、チャネルは、ＢＷＰ全体にわたって検知される。これに基づいて、送信は、ＬＢＴが成功した場合、ＢＷＰ全体にわたって行われるか、または、ＬＢＴが失敗した場合、まったく行われない。サブ帯域ＬＢＴとは対照的に、広帯域ＬＢＴは、前の２つのセクションにおいて述べられた、パンクチャリング／レートマッチング問題およびガード帯域問題を回避し、したがって、多くのＲＡＮ１およびＲＡＮ４仕様変更を回避する。そのような仕様変更は、いずれにせよ、結局、サブ帯域ＬＢＴを伴う単一の広帯域キャリア送信を、ＣＡベース動作とまったく同様にすることになるであろうことを指摘する。わざわざ作り直す（ｒｅ－ｉｎｖｅｎｔ ｔｈｅ ｗｈｅｅｌ）ことは、完全に不要であるように思われる。これに基づいて、以下を提案する。
提案６ － ＮＲ－Ｕは、ＬＢＴ帯域幅に等しいキャリア帯域幅をもつＣＡベース広帯域キャリア動作（モード１）をサポートする。
提案７ － ＮＲ－Ｕは、サブ帯域ＬＢＴを伴わず、広帯域ＬＢＴのみを伴う、単一の広帯域キャリア動作（モード２）をサポートする。
４．３ アクティブ帯域幅パート
ＮＲ Ｒｅｌ－１５では、ＵＥは、複数のＢＷＰで事前設定され得、アクティブＢＷＰは、それらのＢＷＰの間で動的に切り替えられ得る。しかしながら、所与の時間において、ＵＥは、単一のアクティブＢＷＰのみに制限される。ＢＷＰ切替えは、いくつかの手段によって、すなわち、ダウンリンク割り振り／アップリンクグラントを指示するＤＣＩによって、ｂｗｐ非アクティビティタイマーによって、ＲＲＣシグナリングによって、またはランダムアクセスプロシージャの始動時のＭＡＣエンティティ自体によって、制御され得る。いくつかの企業は、複数のアクティブＢＷＰのサポートが、ＮＲ－Ｕについて追加されるべきであることを提案する。原則として、これは、Ｌ１シグナリングについて余分の複雑化およびオーバーヘッドを追加することを除いて、キャリアアグリゲーションとはそれほど異ならない。その意図が、ＢＷＰ帯域幅をＬＢＴ帯域幅に等しいように設定し、それにより、あるＢＷＰ上でのＬＢＴ失敗が、別のＢＷＰ上での送信の信頼性に影響を及ぼさないようにすることである場合、後者は、追加の仕様影響なしにＣＡベース動作でより容易に達成され得る。
提案８ － 複数のアクティブＢＷＰは、ＮＲ－Ｕについて考慮されない。
５ 結論
この文書では、以下の所見を得た。
所見１ － ＮＲ Ｒｅｌ１５は、任意のシンボルにおいて開始するＤＬおよびＵＬ送信をサポートする。
所見２ － 開始点の周期性は、ＣＯＲＥＳＥＴおよび検索空間ＲＲＣ設定によって制御される。監視周期性は、サポートされるタイプＢ送信持続時間から分離される。
所見３ － スタンドアロンシナリオにおけるＵＥブラインド検出を回避するための帯域ごとの単一のヌメロロジーのサポートは、ヌメロロジー候補（３０ｋＨｚ ＳＣＳ対６０ｋＨｚ ＳＣＳ、およびＮＣＰ対ＥＣＰ）が、展開フレキシビリティを最大にするように選定される必要があることを暗示する。
所見４ － ３０ｋＨｚ＋ＮＣＰは、６０ｋＨｚ＋ＮＣＰよりも大きい展開フレキシビリティを与える。
所見５ － ６０ｋＨｚ＋ＮＣＰは、チャネル分散に対するロバストネスを改善するためにＥＣＰが使用されない限り、５００ｎｓよりも大きいＲＭＳ遅延拡散に対してブレークダウンする。
所見６ － 最大性能利得は、ＳＣＳを１５ｋＨｚから３０ｋＨｚまで増加させることによって達成される。３０ｋＨｚから６０ｋＨｚまでさらに増加させることによって、収穫逓減（さらにはＤＬにおける収穫減衰）が達成される。
所見７ － 単一の広帯域キャリア動作（モード２）は、同じ帯域幅を考慮するとき、ＣＡベース動作（モード１）と同じ、ＣＯＲＥＳＥＴの総数が設定されることを必要とする。ＣＣごとのＣＯＲＥＳＥＴの数に対する制限は、モード２についてスケーリング問題を提起し得る。
所見８ － ＬＢＴに失敗したＬＢＴ帯域幅ピースの周りのパンクチャリング／レートマッチングは、ＰｘＳＣＨ復号失敗を引き起こし得る
所見９ － ＬＢＴに失敗したＬＢＴ帯域幅ピースへの隣接チャネル漏洩を制御するためのＢＷＰ内ガード帯域の導入は、かなりのＲＡＮ４仕様労力を必要とし得る
この文書における説明に基づいて、以下を提案する。
提案１ － 追加のＤＬまたはＵＬ開始位置は、ＮＲ－Ｕのために必要とされない
提案２ － 展開フレキシビリティ、性能、および最小限に抑えられた仕様影響の考慮により、３０ｋＨｚ＋ＮＣＰが、ＮＲ－Ｕ ＰＨＹレイヤチャネル設計およびＰＨＹレイヤプロシージャ設計について優先される。
提案３ － ＴＲ３８．８８９に、ＮＲ－ＵのためのＦＲ１動作のための異なるヌメロロジー候補をサポートすることの仕様影響を取り込む。ＴＰが［３］に含まれる。
提案４ － ＮＲ－ＵにおけるＣＡベース広帯域動作の場合、ＰｘＳＣＨ受信（ダウンリンクの場合ｘ＝Ｄ、およびアップリンクの場合ｘ＝Ｕ）のために２つまたはそれ以上の連続するＣＣ間のガード帯域を利用することは有益である。
提案５ － ＢＷＰが複数のＬＢＴ帯域幅ピースにわたる広帯域キャリア動作のためにＢＷＰ内ガード帯域が必要とされるか否かを要求するＬＳをＲＡＮ４に送る。ドラフトＬＳが［６］に含まれる。
提案６ － ＮＲ－Ｕは、ＬＢＴ帯域幅に等しいキャリア帯域幅をもつＣＡベース広帯域キャリア動作（モード１）をサポートする。
提案７ － ＮＲ－Ｕは、サブ帯域ＬＢＴを伴わず、広帯域ＬＢＴのみを伴う、単一の広帯域キャリア動作（モード２）をサポートする。
提案８ － 複数のアクティブＢＷＰは、ＮＲ－Ｕについて考慮されない。

参考文献
［１］ Ａ．Ｓｉｍｏｎｓｏｎ、Ｈ．Ａｓｐｌｕｎｄ、Ｊ．Ｍｅｄｂｏ、およびＫ．Ｗｅｒｎｅｒ、「Ｂｅａｍｆｏｒｍｉｎｇ ｉｍｐａｃｔ ｏｎ ｔｉｍｅ ｄｉｓｐｅｒｓｉｏｎ ａｓｓｅｓｓｅｄ ｏｎ ｍｅａｓｕｒｅｄ ｃｈａｎｎｅｌｓ」、ＩＥＥＥ Ｖｅｈｉｃｕｌａｒ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏｎｆｅｒｅｎｃｅ、ポルト、ポルトガル、２０１８年６月。
［２］ Ｒ１－１６４６２１
［３］ Ｒ１－１８１１３０９
［４］ Ｒ１－１８１１３０７
［５］ ３ＧＰＰ ＴＳ３６．１０４、「Ｂａｓｅ ｓｔａｔｉｏｎ ｒａｄｉｏ ｔｒａｎｓｍｉｓｓｉｏｎ ａｎｄ ｒｅｃｅｐｔｉｏｎ」、ｖ１５．３．０、２０１８年６月。
［６］ Ｒ１－１８１１３０８

Claims (39)

1. 無線通信ネットワークにおいて動作可能な第１のノードにおいて、リッスンビフォアトーク（ＬＢＴ）アクセス要件を有する未ライセンススペクトル上でデータ送信を受信または送信する方法（４００）であって、前記方法は、
   第２のノードから、少なくとも１つのデータチャネルにおいて使用するために帯域幅パートにおいて複数の無線リソースを割り当てる制御メッセージを受信すること（Ｓ４０５）であって、前記帯域幅パートが複数の帯域幅ピースに分割される、制御メッセージを受信すること（Ｓ４０５）と、
   １つまたは複数の帯域幅ピースの周波数連続ブロックが前記データ送信の受信または送信のために使用されるべきであると前記第１のノードによって決定すること（Ｓ４０８）と、
   前記周波数連続ブロックにマッピングする前記無線リソースのうち、前記周波数連続ブロックのエッジにおけるガード帯域にマッピングする１つまたは複数の無線リソースのみが、前記データ送信を受信または送信するために使用されることから除外されると前記第１のノードによって決定すること（Ｓ４０９）と、
   前記第２のノードからまたは前記第２のノードに、前記複数の帯域幅ピースのうちの少なくとも１つに対応する無線リソースを使用して前記データ送信を受信または送信すること（Ｓ４１５）と
   を含み、
   前記データ送信を受信または送信するために使用される前記無線リソースが、２つの帯域幅ピースの間に位置する少なくとも１つのガード帯域の少なくとも一部分にマッピングする１つまたは複数の無線リソースを除外する、
   方法（４００）。
2. 前記データ送信の受信または送信が、少なくとも１つのガード帯域の前記少なくとも一部分にマッピングする前記１つまたは複数の無線リソースの使用を除外するために、パンクチャされるかまたはレートマッチングされるのうちの１つである、請求項１に記載の方法。
3. 前記データ送信が前記第２のノードに送信されるとき、前記第１のノードは、前記複数の帯域幅ピースの各々上で、前記帯域幅ピースがデータ送信のために利用可能であるかどうかを決定するために、ＬＢＴプロシージャを実施する、請求項１または２に記載の方法。
4. 前記少なくとも１つのデータチャネルにおいて使用するために割り当てられる前記無線リソースの各々が、物理リソースブロックの少なくとも一部分である、請求項１から３のいずれか一項に記載の方法。
5. 前記データ送信を受信または送信するために使用される前記無線リソースが、連続しており、データ送信のためにＬＢＴプロシージャによって利用可能であると決定された、２つの帯域幅ピースの間に位置するガード帯域の少なくとも一部分にマッピングする１つまたは複数の無線リソースを含む、請求項１から４のいずれか一項に記載の方法。
6. 前記制御メッセージは、１つまたは複数の帯域幅ピースの前記周波数連続ブロックが、ＬＢＴプロシージャによって利用可能であると決定され、前記データ送信の受信または送信のために使用されるべきであるという指示を含み、前記周波数連続ブロックの前記エッジにおけるガード帯域にマッピングする１つまたは複数の無線リソースのみが、前記データ送信を受信または送信するために使用されることから除外されると前記第１のノードによって前記決定すること（Ｓ４０９）が、前記指示に少なくとも部分的に基づく、請求項１から５のいずれか一項に記載の方法。
7. 前記データ送信が前記第２のノードから受信されるとき、前記周波数連続ブロックの前記エッジにおけるガード帯域にマッピングする１つまたは複数の無線リソースのみが、前記データ送信を受信するために使用されることから除外されると前記第１のノードによって前記決定すること（Ｓ４０９）が、前記第２のノードからの暗黙的指示に少なくとも部分的に基づく、請求項６に記載の方法。
8. 前記暗黙的指示が、２つまたはそれ以上の周波数連続帯域幅ピースにおける復調用参照信号の成功した検出を含む、請求項７に記載の方法。
9. 前記暗黙的指示が、１つまたは複数の周波数連続帯域幅ピースの合間の前記ガード帯域にマッピングする１つまたは複数の無線リソースにおける復調用参照信号の成功した検出を含む、請求項７に記載の方法。
10. 前記周波数連続ブロックの前記エッジにおけるガード帯域にマッピングする１つまたは複数の無線リソースのみが、前記データ送信を受信または送信するために使用されることから除外されると前記第１のノードによって前記決定すること（Ｓ４０９）が、あらかじめ決定されたルールに少なくとも部分的に基づく、請求項１から５のいずれか一項に記載の方法。
11. 前記データ送信が受信または送信される時間期間の第１の部分中に、前記データ送信を受信または送信するために使用される前記無線リソースが、連続しており、データ送信のためにＬＢＴプロシージャによって利用可能であると決定された、２つの帯域幅ピースの間に位置するガード帯域の少なくとも一部分にマッピングする１つまたは複数の無線リソースを除外し、
    前記時間期間の第２の部分中に、前記データ送信を受信するために使用される前記無線リソースが、連続しており、データ送信のためにＬＢＴプロシージャによって利用可能であると決定された、２つの帯域幅ピースの間に位置する前記ガード帯域の前記少なくとも一部分にマッピングする前記１つまたは複数の無線リソースを含む、
    請求項１から８のいずれか一項に記載の方法。
12. 前記時間期間の前記第１の部分の持続時間があらかじめ決定される、請求項１１に記載の方法。
13. 前記時間期間の前記第１の部分の持続時間が、前記データ送信の受信より前に受信された制御メッセージにおいて、前記第１のノードに指示される、請求項１１に記載の方法。
14. 前記データ送信の受信または送信が、前記時間期間の前記第１の部分中に前記少なくとも１つのガード帯域の前記少なくとも一部分にマッピングする前記１つまたは複数の無線リソースの使用を除外するために、パンクチャされるかまたはレートマッチングされるのうちの１つであり、
    前記データ送信が、前記時間期間の前記第２の部分中に前記少なくとも１つのガード帯域の前記少なくとも一部分に対応する前記１つまたは複数の無線リソースの使用を除外するためにスケジュールされる、
    請求項１１に記載の方法。
15. 前記データ送信の受信または送信より前に、前記データ送信のための使用から除外される前記１つまたは複数の無線リソースに対応する前記少なくとも１つのガード帯域またはそれの部分を前記第１のノードに指示する制御メッセージを受信すること（Ｓ４１０）
    をさらに含む、請求項１から１４のいずれか一項に記載の方法。
16. 前記少なくとも１つのガード帯域またはそれの部分を指示する前記制御メッセージが、帯域幅パートにおいて複数の無線リソースを割り当てる前記制御メッセージの一部として含まれる、請求項１５に記載の方法。
17. 前記少なくとも１つのガード帯域またはそれの部分を指示する前記制御メッセージが、１つまたは複数のビットを含み、前記１つまたは複数のビットの各々は、前記帯域幅ピースの間に位置する複数のガード帯域のうちの少なくとも１つに対応し、前記対応する少なくとも１つのガード帯域にマッピングする少なくとも１つまたは複数の無線リソースが前記データ送信のための使用から除外されるかどうかを前記第１のノードに指示する、請求項１５に記載の方法。
18. 前記１つまたは複数のビットのうちの少なくとも１つが、前記複数のガード帯域のうちの複数のガード帯域に対応する、請求項１７に記載の方法。
19. 前記帯域幅パートにおいて前記複数の無線リソースを割り当てる前記制御メッセージが、複数のあらかじめ決定された制御メッセージタイプのうちの１つであり、前記制御メッセージタイプが前記ＬＢＴプロシージャの結果を指示する、請求項３に記載の方法。
20. 無線通信ネットワークにおいて、リッスンビフォアトーク（ＬＢＴ）アクセス要件を有する未ライセンススペクトル上でデータ送信を受信するための無線デバイスであって、前記無線デバイスが、請求項１から１９のいずれか一項に記載のステップを実施するように設定された処理回路を備える、無線デバイス。
21. 無線通信ネットワークにおいて、リッスンビフォアトーク（ＬＢＴ）アクセス要件を有する未ライセンススペクトル上でデータ送信を受信するためのユーザ機器（ＵＥ）であって、前記ＵＥが、
    無線信号を送り、受信するように設定されたアンテナと、
    前記アンテナおよび処理回路に接続され、前記アンテナと前記処理回路との間で通信される信号を調節するように設定された、トランシーバと
    を備え、
    前記処理回路が、請求項１から１９のいずれか一項に記載のステップを実施するように設定された、
    ユーザ機器（ＵＥ）。
22. リッスンビフォアトーク（ＬＢＴ）アクセス要件を有する未ライセンススペクトル上で無線通信ネットワークにおいてデータ送信を送信または受信する方法（１３００）であって、前記方法は、
    第２のノードから第１のノードに、少なくとも１つのデータチャネルにおいて使用するために帯域幅パートにおいて複数の無線リソースを割り当てる制御メッセージを受信すること（Ｓ１３０５）であって、前記帯域幅パートが複数の帯域幅ピースに分割される、制御メッセージを送信すること（Ｓ１３０５）と、
    １つまたは複数の帯域幅ピースの周波数連続ブロックがデータ送信のために使用されるべきであると前記第２のノードによって決定すること（Ｓ１３１０）と、
    前記第１のノードにまたは前記第１のノードから、前記複数の帯域幅ピースのうちの少なくとも１つの少なくとも一部分に対応する無線リソースを使用して前記データ送信を送信または受信すること（Ｓ１３２０）と
    を含み、
    前記データ送信を送信または受信するために使用される前記無線リソースが、２つの帯域幅ピースの間に位置する少なくとも１つのガード帯域の少なくとも一部分にマッピングする１つまたは複数の無線リソースを除外し、
    前記周波数連続ブロックにマッピングする前記無線リソースの中から、前記データ送信における使用から除外される前記１つまたは複数の無線リソースが、前記周波数連続ブロックのエッジにおけるガード帯域にマッピングする１つまたは複数の無線リソースのみを含む、
    方法（１３００）。
23. 前記第２のノードが、少なくとも１つのガード帯域の前記少なくとも一部分にマッピングする前記１つまたは複数の無線リソースの使用を除外するために、前記データ送信をパンクチャすることまたはレートマッチングすることのうちの１つを行う、請求項２２に記載の方法。
24. 前記第２のノードは、前記複数の帯域幅ピースの各々上で、前記帯域幅ピースがデータ送信のために利用可能であるかどうかを決定するために、ＬＢＴプロシージャを実施する、請求項２２または２３に記載の方法。
25. 前記少なくとも１つのデータチャネルにおいて使用するために割り当てられる前記無線リソースの各々が、物理リソースブロックの少なくとも一部分である、請求項２２から２４のいずれか一項に記載の方法。
26. 前記データ送信を送信または受信するために使用される前記無線リソースが、連続しており、前記データ送信の送信または受信のためにＬＢＴプロシージャによって利用可能であると決定された、２つの帯域幅ピースの間に位置するガード帯域の少なくとも一部分にマッピングする１つまたは複数の無線リソースを含む、請求項２２から２５のいずれか一項に記載の方法。
27. 前記制御メッセージは、１つまたは複数の帯域幅ピースの前記周波数連続ブロックが、ＬＢＴプロシージャによって利用可能であると決定され、データ送信のために使用されるべきであるという指示を含む、請求項２２から２６のいずれか一項に記載の方法。
28. 前記第２のノードは、１つまたは複数の帯域幅ピースの前記周波数連続ブロックがデータ送信のために使用されるべきであることを前記第１のノードに暗黙的に指示する、請求項２２から２６のいずれか一項に記載の方法。
29. 前記暗黙的指示が、２つまたはそれ以上の周波数連続帯域幅ピースの各々における復調用参照信号の送信を含む、請求項２８に記載の方法。
30. 前記データ送信が送信または受信される時間期間の第１の部分中に、前記データ送信を送信するために使用される前記無線リソースが、連続しており、前記データ送信の送信または受信のためにＬＢＴプロシージャによって利用可能であると決定された、２つの帯域幅ピースの間に位置するガード帯域の少なくとも一部分にマッピングする１つまたは複数の無線リソースを除外し、
    前記時間期間の第２の部分中に、前記データ送信を送信するために使用される前記無線リソースが、連続しており、前記データ送信の送信または受信のためにＬＢＴプロシージャによって利用可能であると決定された、２つの帯域幅ピースの間に位置する前記ガード帯域の前記少なくとも一部分にマッピングする前記１つまたは複数の無線リソースを含む、
    請求項２２から２９のいずれか一項に記載の方法。
31. 前記時間期間の前記第１の部分の持続時間があらかじめ決定される、請求項３０に記載の方法。
32. 前記第２のノードが、前記データ送信の送信または受信より前に送信された制御メッセージにおいて、前記時間期間の前記第１の部分の持続時間を前記第１のノードに指示する、請求項３０に記載の方法。
33. 前記第２のノードが、前記時間期間の前記第１の部分中に前記少なくとも１つのガード帯域の前記少なくとも一部分にマッピングする前記１つまたは複数の無線リソースの使用を除外するために、前記データ送信をパンクチャすることまたはレートマッチングすることのうちの１つを行い、
    前記第２のノードが、前記時間期間の前記第２の部分中に前記少なくとも１つのガード帯域の前記少なくとも一部分に対応する前記１つまたは複数の無線リソースの使用を除外するために、前記データ送信をスケジュールする、
    請求項３０に記載の方法。
34. データ送信より前に、前記データ送信の送信または受信における使用から除外される前記１つまたは複数の無線リソースに対応する前記少なくとも１つのガード帯域を前記第１のノードに指示する制御メッセージを送信すること（Ｓ１３１５）
    をさらに含む、請求項２２から３３のいずれか一項に記載の方法。
35. 前記制御メッセージが、１つまたは複数のビットを含み、前記１つまたは複数のビットの各々は、前記帯域幅ピースの間に位置する複数のガード帯域のうちの少なくとも１つに対応し、前記対応する少なくとも１つのガード帯域にマッピングする少なくとも１つまたは複数の無線リソースが前記データ送信のための使用から除外されるかどうかを前記第１のノードに指示する、請求項３４に記載の方法。
36. 前記１つまたは複数のビットのうちの少なくとも１つが、前記複数のガード帯域のうちの複数のガード帯域に対応する、請求項３５に記載の方法。
37. 前記帯域幅パートにおいて前記複数の無線リソースを割り当てる前記制御メッセージが、複数のあらかじめ決定された制御メッセージタイプのうちの選択された１つであり、前記第２のノードが、前記ＬＢＴプロシージャの結果に少なくとも部分的に基づいて前記制御メッセージタイプを選択する、請求項２４に記載の方法。
38. 無線通信ネットワークにおいて、リッスンビフォアトーク（ＬＢＴ）アクセス要件を有する未ライセンススペクトル上でデータ送信を送信するためのネットワークノードであって、前記ネットワークノードが、請求項２２から３７のいずれか一項に記載のステップを実施するように設定された処理回路を備える、ネットワークノード。
39. ホストコンピュータを含む通信システムであって、
    ユーザデータを提供するように設定された処理回路と、
    無線デバイスへの送信のために前記ユーザデータをセルラネットワークにフォワーディングするように設定された通信インターフェースと
    を備え、
    前記セルラネットワークが、
    前記ユーザデータを受信するように設定された通信インターフェースと、
    前記ユーザデータを前記無線デバイスにフォワーディングするために無線デバイスとインターフェースするように設定された無線インターフェースと、
    請求項２２から３７のいずれか一項に記載のステップを実施するように設定された処理回路と
    を有するネットワークノードを備える、
    通信システム。

Images