JP2021514159A - 複数送信のスケジューリング - Google Patents

Abstract

【解決手段】方法は、複数のリソースブロック（６００〜６４９）上の送信（５９９１、５９９２）のためのスケジューリング情報（４００１）を受信することを含む。方法は、複数のリソースブロック（６００〜６４９）に含まれる少なくとも１つの禁止リソースブロック（６８０）に関する制御情報に基づいて、少なくとも１つの禁止リソースブロック（６８０）上の送信（５９９１、５９９２）を阻止することをさらに含む。

Description

本発明の様々な例は、一般に、送信のスケジューリングに関する。具体的には、本発明の様々な例は、送信をパンクチャリングすること、および少なくとも１つの禁止リソースブロック上での送信を阻止することに関する。

モノのインターネット（Internet of Things：ＩｏＴ）上のトラフィックに対応するために、第３世代パートナーシッププロジェクト（Third Generation Partnership Project：３ＧＰＰ）における様々な作業項目が定義されている。例として、さらに拡張されたマシンタイプコミュニケーション（Further Enhanced Machine Type Communications：ｆｅＭＴＣ）（３ＧＰＰ ＲＰ−１６１４６４参照）、拡張された狭帯域モノのインターネット（Enhanced Narrowband IoT：ｅＮＢ−ＩｏＴ）（３ＧＰＰ ＲＰ−１６１９０１参照）、より一層拡張されたマシンタイプコミュニケーション（Even Further Enhanced Machine Type Communication：ｅｆｅＭＴＣ）（３ＧＰＰ ＲＰ−１７０７３２参照）、さらに拡張された狭帯域モノのインターネット（Further Enhanced Narrowband IoT：ｆｅＮＢ−ＩｏＴ）（３ＧＰＰ ＲＰ−１７０８５２参照）などがある。

多くの場合、ＩｏＴトラフィックに関するこのような概念は、ＩｏＴ端末（ユーザー装置（User Equipment：ＵＥ））に対するキャリアのサブバンド（狭帯域とも称されることがある）上での送信に依存している。非ＩｏＴ ＵＥは、非ＩｏＴトラフィックの全帯域幅で送信する。したがって、複数のリソースブロック（物理リソースブロック（Physical Resource Block：ＰＲＢ）と呼ばれることが多い）（各ＰＲＢは時間周波数リソースグリッドの複数の時間周波数リソースエレメント（物理リソースエレメント（Physical Resource Element：ＰＲＥ）と呼ばれることが多い）を含む）は、サブバンドに関連付けられ、したがって、ＩｏＴトラフィックに割り当てられる。

ＩｏＴ ＵＥの無線周波数フロントアンドの複雑性を低減するために、サブバンドの帯域幅は、キャリアの全帯域幅と比べて狭くされる。例えば、サブバンドの標準的な帯域幅は１〜２ＭＨｚの範囲内であるが、キャリアの帯域幅は１〜２０ＭＨｚ、またはそれを超える範囲にわたる。

さらに、サブバンド上のＩｏＴトラフィックの第１の送信のスケジューリングとサブバンド外の非ＩｏＴトラフィックの第２の送信のスケジューリングとでは、通常、異なる戦略が採用される。例えば、第１の送信をスケジューリングするためと、第２の送信をスケジューリングするためとでは、異なるフォーマットのスケジューリング情報を使用することができる。例えば、サブバンド上での送信をスケジューリングするには、３ＧＰＰ技術仕様書（Technical Specification：ＴＳ）３６．２１２、バージョン１５．０．０（２０１７年１２月）、第５．３．３．１．１３節に従って、ダウンリンク制御情報（Downlink Control Information：ＤＣＩ）のフォーマット６−１Ｂを使用することができる。それとは違って、サブバンド外の送信をスケジューリングするには、３ＧＰＰ ＴＳ ３６．２１２、バージョン１５．０．０（２０１７年１２月）、第５．３．３．１．１節に従って、ＤＣＩフォーマット０を使用することができる。

サブバンド上での送信のスケジューリングとサブバンド外での送信のスケジューリングとでは、異なるフォーマットのスケジューリング情報が使用されるために、あいまいさが生じる可能性があることが確認されている。これによってシステムの信頼性やスペクトル効率が低下する可能性がある。
さらに、一般的なレベルでは、例えば、連続チャネルへのアクセスなどの観点から、ＩｏＴトラフィックと非ＩｏＴトラフィックの要件が異なるため、スケジューリングの柔軟性が制限される可能性があることが確認されている。これによってレイテンシが増加する可能性がある。

さらにより一般的なレベルでは、共通のキャリア上に、例えば、スケジューリング情報のフォーマット、期間、帯域幅などの観点から、異なる要件の送信が共存することによって、これらの送信のスケジューリングが複雑化する可能性があることが確認されている。

そのため、高度なスケジューリング技術が必要とされる。特に、上記の制限および短所の少なくとも一部を克服もしくは軽減する高度なスケジューリング技術の必要性がある。

この必要性は独立請求項の特徴によって満足される。従属請求項の特徴は実施形態を規定する。

１つの方法は、複数のリソースブロック上での送信のためのスケジューリング情報を受信することを含む。この方法は、また、その複数のリソースブロックに含まれる少なくとも１つの禁止リソースブロックに関する制御情報に基づいて、少なくとも１つの禁止リソースブロック上での送信を阻止することを含む。

１つのコンピュータプログラム製品またはコンピュータプログラムはプログラムコードを含む。このプログラムコードは、少なくとも１つのプロセッサによって実行可能である。このプログラムコードを実行すると、その少なくとも１つのプロセッサが１つの方法を実行する。この方法は、複数のリソースブロック上での送信のためのスケジューリング情報を受信することを含む。この方法は、また、その複数のリソースブロックに含まれる少なくとも１つの禁止リソースブロックに関する制御情報に基づいて、その少なくとも１つの禁止リソースブロック上での送信を阻止することを含む。

端末は、複数のリソースブロック上での送信のためのスケジューリング情報を受信して、その複数のリソースブロックに含まれる少なくとも１つの禁止リソースブロックに関する制御情報に基づいて、その少なくとも１つの禁止リソースブロック上での送信を阻止するように構成された制御回路を含む。

１つの方法は、複数のリソースブロック上での送信のためのスケジューリング情報を送信することを含む。送信は、その複数のリソースブロックに含まれる少なくとも１つの禁止リソースブロック上で阻止される。

１つのコンピュータプログラム製品またはコンピュータプログラムはプログラムコードを含む。このプログラムコードは、少なくとも１つのプロセッサによって実行可能である。このプログラムコードを実行すると、その少なくとも１つのプロセッサが１つの方法を実行する。この方法は、複数のリソースブロック上での送信のためのスケジューリング情報を送信することを含む。送信は、その複数のリソースブロックに含まれる少なくとも１つの禁止リソースブロック上で阻止される。

１つのアクセスノードは、複数のリソースブロック上での送信のためのスケジューリング情報を送信するように構成された制御回路を含む。送信は、その複数のリソースブロックに含まれる少なくとも１つの禁止リソースブロック上で阻止される。

１つの方法は、アクセスノードと第１の端末の間の第１の送信をスケジューリングすることを含む。この方法は、少なくとも１つの禁止リソースブロック上で第１の送信をパンクチャリングすることをさらに含む。この方法は、その少なくとも１つの禁止リソースブロック上でそのアクセスノードと第２の端末との間の第２の送信をスケジューリングすることをさらに含む。

１つのコンピュータプログラム製品またはコンピュータプログラムはプログラムコードを含む。このプログラムコードは、少なくとも１つのプロセッサによって実行可能である。このプログラムコードを実行すると、その少なくとも１つのプロセッサが１つの方法を実行する。この方法は、アクセスノードと第１の端末との間の第１の送信をスケジューリングすることを含む。この方法は、少なくとも１つの禁止リソースブロック上で第１の送信をパンクチャリングすることをさらに含む。この方法は、その少なくとも１つの禁止リソースブロック上でそのアクセスノードと第２の端末との間の第２の送信をスケジューリングすることをさらに含む。

１つのアクセスノードは、アクセスノードと第１の端末との間の第１の送信をスケジューリングし、少なくとも１つの禁止リソースブロック上で第１の送信をパンクチャリングし、その少なくとも１つの禁止リソースブロック上で、そのアクセスノードと第２の端末との間の第２の送信をスケジューリングするように構成された制御回路を含む。
例えば、第１の送信は、第１の帯域幅を割り当てることができる。第２の送信は、第２の帯域幅を割り当てることができる。第２の帯域幅は、例えば、少なくとも２倍または少なくとも５倍、第１の帯域幅よりも広くてもよい。

例えば、第１の送信はＩｏＴトラフィック用であってもよく、第２の送信は、非ＩｏＴトラフィック用であってもよい。例えば、第１のＵＥは、ＩｏＴ ＵＥであってもよく、第２のＵＥは、非ＩｏＴ ＵＥであってもよい。

例えば、第１の送信には、第１の送信期間を有してもよい。例えば、第２の送信には、第２の送信期間を有してもよい。第１の送信期間は、例えば、少なくとも２倍または少なくとも５倍、第２の送信期間よりも長くてもよい。

例えば、第１の送信の上記スケジューリングのためのスケジューリング情報のフォーマットは、第２の送信の上記スケジューリングのためのスケジューリング情報のフォーマットと異なってもよい。例えば、異なるグループのＰＲＢがスケジューリングに使用されてもよく、それらは整列されていなくてもよい。

パンクチャリングは、時間領域と周波数領域の少なくともどちらか一方に存在し得る。したがって、時間領域と周波数領域の少なくともどちらか一方で第１の送信を中断することができる。

上記および以下に説明する特徴は、示されたそれぞれの組み合わせだけでなく、本発明の範囲から逸脱しない限り、他の組み合わせにおいて、または単独で使用されてもよいことを理解されたい。

図１は、様々な例による、基地局（Base Station：ＢＳ）とＵＥの間の無線リンクを含むネットワークを模式的に示す。 図２は、様々な例による、ＢＳとＩｏＴ ＵＥ、および非ＩｏＴ ＵＥの間の無線リンクを含むネットワークを模式的に示す。 図３は、様々な例による、ＢＳおよびＵＥをさらに詳細に模式的に示す。 図４は、様々な例による、複数のＰＲＢ上でのダウンリンク（Downlink：ＤＬ）送信のためのスケジューリング情報の通信のシグナリング図である。 図５は、様々な例による、複数のＰＲＢ上でのアップリンク（Uplink：ＵＬ）送信のためのスケジューリング情報の通信のシグナリング図であり、ＵＬ送信は、カバレッジ拡張（Coverage Enhancement：ＣＥ）技術に従ったデータの複数の繰り返しを含む。 図６は、様々な例による、ＰＲＥ、ＰＲＢ、およびサブバンドを含む時間−周波数リソースグリッドを模式的に示す。 図７は、様々な例による、ＰＲＥ、ＰＲＢ、およびサブバンドを含む時間−周波数リソースグリッドを模式的に示す。 図８は、様々な例による、少なくとも１つの禁止ＰＲＢ上での送信の阻止を模式的に示す。 図９は、様々な例による、少なくとも１つの禁止ＰＲＢ上での送信の阻止を模式的に示す。 図１０は、様々な例による、少なくとも１つの禁止ＰＲＢ上での送信の阻止を模式的に示す。 図１１は、様々な例による、少なくとも１つの禁止ＰＲＢ上での送信の阻止を模式的に示す。 図１２は、様々な例による、少なくとも１つの禁止ＰＲＢ上での送信の阻止を模式的に示す。 図１３は、様々な例による、少なくとも１つの禁止ＰＲＢ上での送信の阻止を模式的に示す。 図１４は、様々な例による、少なくとも１つの禁止ＰＲＢ上での送信の阻止を模式的に示す。 図１５は、第１の送信をパンクチャリングし、そのパンクチャリングに従い、かつ様々な例に従って、第２の送信をスケジューリングする処理を模式的に示す。 図１６は、第１の送信をパンクチャリングし、そのパンクチャリングに従い、かつ様々な例に従って、第２の送信をスケジューリングする処理を模式的に示す。 図１７は、第１の送信をパンクチャリングし、そのパンクチャリングに従い、かつ様々な例に従って、第２の送信をスケジューリングする処理を模式的に示す。 図１８は、第１の送信をパンクチャリングし、そのパンクチャリングに従い、かつ様々な例に従って、第２の送信をスケジューリングする処理を模式的に示す。 図１９は、様々な例による方法のフローチャートである。 図２０は、様々な例による方法のフローチャートである。 図２１は、様々な例による、基地局と、ＩｏＴ ＵＥ、および非ＩｏＴ ＵＥの間の通信のシグナリング図である。 図２２は、第１の送信をパンクチャリングし、そのパンクチャリングに従い、かつ様々な例に従って、第２の送信をスケジューリングする処理を模式的に示す。

以下、本発明の実施形態について、添付図面を参照して詳細に説明する。以下の実施形態の説明は、制限な意味で解釈されるべきではないことを理解されたい。本発明の範囲は、以下に説明する実施形態または図面によって限定されることを意図するものではなく、それらは単なる例示ととらえられる。

図面は、略図であると見なされるべきであり、図面に示される要素は、必ずしも一定の縮尺で示されているわけではない。むしろ、各種の要素は、それらの機能および一般的な目的が当業者に明らかになるように表されている。図面に示されるか本明細書で説明される機能ブロック、装置、構成要素、または他の物理的または機能的ユニット間の任意の接続や結合も、間接的な接続または結合によって実現され得る。構成要素間の結合は、無線接続上で確立することもできる。機能ブロックは、ハードウェア、ファームウェア、ソフトウェア、またはそれらの組み合わせによって実現することができる。様々な図面における同じ参照符号は、類似または同一の構成要素、機能、または動作を表す。

無線通信の技術について以下に説明する。無線リンク上でデータを伝送することができる。データの伝送には、データの送信とデータの受信の少なくとも一方が含まれる。例えば、アップリンク（ＵＬ）データは、ＵＥから基地局（ＢＳ）などのアクセスノードに通信され得る。代替的あるいは追加的に、ダウンリンク（ＤＬ）データは、例えばＢＳのようなアクセスノードからＵＥに通信され得る。

例えば、アプリケーションデータを通信することができる。アプリケーションデータは、ペイロードデータやユーザーデータと呼ばれることも多い。アプリケーションデータは、オープンシステムインターフェース（Open Systems Interface：ＯＳＩ）伝送プロトコルスタックの第７層で定義できる。より高位層の制御データ、例えば、第２層または第３層の制御データや、無線リソース制御（Radio Resource Control：ＲＲＣ）の制御データを通信することもできるであろう。

無線通信は、セルラーネットワークのＢＳによってサポートされ得る。以下では、単純化のために、主としてセルラーネットワークおよびＢＳについて説明するが、同様の技術を、他の種類や型式のネットワークの他の種類や型式のアクセスノードに簡単に適用することができる。

本明細書で説明する様々な例では、ＩｏＴトラフィックおよび非ＩｏＴトラフィックを説明する。ＩｏＴトラフィックはＢＳとＩｏＴ ＵＥの間のトラフィックである。非ＩｏＴトラフィックはＢＳと非ＩｏＴ ＵＥの間のトラフィックである。通常、非ＩｏＴトラフィックには、キャリアの全帯域幅に広がる伝送アロケーションＰＲＢが含まれる。キャリアは、複数のサブキャリアを含み得る。これらのサブキャリアの一部は、キャリアのサブバンドに関連付けられていてもよい。ＩｏＴトラフィックの送信は、通常、サブバンドに割り当てられる。

多くの場合、非ＩｏＴトラフィックの送信と比べると、ＩｏＴトラフィックの送信の帯域幅は狭いが、送信期間は長い。

特にＩｏＴトラフィックの送信に関して、比較的広いカバレッジが実現される特徴のセットは、カバレッジ拡張（ＣＥ）と呼ばれる。ＣＥは、マシンタイプコミュニケーション（Machine Type Communication：ＭＴＣ）および狭帯域モノのインターネット（Narrowband IoT：ＮＢ−ＩｏＴ）に適用されることが想定される。ＣＥの主要な特徴は信号の送信の複数の繰り返しを実行することであり、それにより、符号化されたデータを複数繰り返すことが容易になる。これにより、通常、送信期間が延長される。各繰り返しには、データの同一冗長バージョンが含まれ得る。繰り返しは「ブラインド」であってもよい。すなわち、ハイブリッド確認応答再送要求（Hybrid Acknowledgment Repeat Request：ＨＡＲＱ）プロトコルについて定義することができるそれぞれの再送信要求に応じたものでなくてもよい。むしろ、ＣＥによる繰り返しは先手を打ったものであってもよい。３ＧＰＰ技術報告（ＴＲ）４５．８２０、バージョン１３．０．０（２０１５年８月）、第６．２．１．３節に、例が提供されている。適切なＣＥポリシーを採用することにより、対応する無線リンク上での通信の条件が悪いシナリオにおいても、送信の成功の可能性を高めることができる。チャネルフェーディングに対するロバスト性が向上する。それによって、ＩｏＴ領域で想定される低い送信電力に対しても、ネットワークのカバレッジを大幅に向上させることができる。

様々な例によれば、ＣＥポリシーは、ＵＥとネットワークとの間の送信のために採用される。ＣＥポリシーによって繰り返しレベルを定義することができる。符号化されたデータの所定の冗長バージョンを含むメッセージまたは信号は、繰り返しレベルに従って繰り返し通信される。例によれば、メッセージは、複数の繰り返しによって冗長に通信される。メッセージは、同一の冗長バージョンに従って符号化されたデータを含むことができる。したがって、様々な例によれば、同一の符号化されたデータを何回も冗長に通信することができる。通常、異なった冗長バージョンは、長さの異なるチェックサムに対応する。他の例では、異なった冗長バージョンに対して同じ長さのチェックサムを採用するが、異なった符号化方式に従って符号化することもできるであろう。代替的あるいは追加的に、異なった冗長バージョンに対して異なったインターリービング方式を採用することができる。複数の繰り返しの各繰り返しには、例えば冗長バージョン０や冗長バージョン１などの、同一の冗長バージョンに従って符号化されたデータを含むことができる。その後、受信側で符号化されたデータの複数の繰り返しを組み合わせることができる。すなわち、メッセージの複数の受信インスタンスを組み合わせることができる。このような組み合わせは、アナログまたはデジタル領域、例えばベースバンドで実行されてもよい。組み合わせによって、結合信号が生じる。その後、結合信号に基づいて符号化されたデータを復号することができる。このように、複数の繰り返しにわたって受信した情報を集約することにより、符号化された信号の復号に成功する確率が向上する。これによってＣＥが容易になる。繰り返し回数は、繰り返しレベルまたはＣＥレベルと呼ばれることもある。そのようなＣＥの技術は、例えば３ＧＰＰ ＭＴＣまたはＮＢ−ＩｏＴに従って、ＩｏＴ技術の枠組みの中に特定の用途を見出すことができる。ここで、通常、送信をするＵＥは、比較的低い送信電力を適用する。それにもかかわらず、メッセージの複数の繰り返しにより、メッセージの受信に成功する十分に高い可能性がもたらされる。ＣＥの繰り返しには、周波数ホッピングパターンを採用することができる。これによって、ダイバーシティが促進される。

本明細書で説明する技術は、一般に、送信のスケジューリングに関する。送信のスケジューリングは、スケジューラによって実行することができる。通常、スケジューラはＢＳで実行される機能である。スケジューリングには、他の送信とのコリジョンを避けるように、所定の送信のための１つ以上の時間周波数リソースエレメントを予約することを含むことができる。これは、１つ以上のＰＲＥを所定のＵＥに割り当てることに相当する。

多くの場合、ＰＲＥはＰＲＢの各グループに割り当てられる。ＰＲＢのグループは、リソースブロックグループ（Resource Block Group：ＲＢＧ）と呼ばれる。通常、ＰＲＢには複数のＰＲＥが含まれる。各々のＰＲＥの定義は、例えば直交周波数分割多重（Orthogonal Frequency Division Multiplex：ＯＦＤＭ）変調方式に従った、キャリアのサブキャリアによる定義、および特定の期間のシンボルという観点からの定義のうち、少なくとも一方であってよい。

例によれば、ＩｏＴトラフィックと非ＩｏＴトラフィックに関連する送信は、同じＢＳによってスケジューリングされる。通常、レイテンシ、連続チャネルへのアクセスなどの観点からの要求は、ＩｏＴトラフィックと非ＩｏＴトラフィックでは異なる。また、ＩｏＴトラフィックの送信と非ＩｏＴトラフィックの送信に使用されるスケジューリング情報のフォーマットは異なる可能性がある。以下、このような、ＩｏＴトラフィックと非ＩｏＴトラフィックに関連する送信の異なるニーズのバランスをとるのに役立つ技術について説明する。

様々な例によれば、スケジューリング情報が通信される。スケジューリング情報は、複数のＰＲＢ上での送信のためのものである。その後、複数のＰＲＢに含まれる少なくとも１つの禁止ＰＲＢ上で送信が阻止される。これは、それぞれの制御情報に基づいている。具体的には、送信は、例えばＩｏＴ ＵＥのようなＵＥによって阻止され得る。

その少なくとも１つの禁止ＰＲＢは、複数のＰＲＢのサブセットであり得る。したがって、送信が部分的に阻止され得る。いくつかの例では、禁止ＰＲＢが送信に割り当てられた全帯域幅にわたっている場合、送信が特定の期間中完全に阻止される可能性さえあるであろう。

その少なくとも１つの禁止ＰＲＢ上で送信を阻止することによって、スケジューリング情報の異なるフォーマットによるあいまいさを解消できる。具体的には、サブバンド上とサブバンド外での送信に使用されるスケジューリング情報の粒度の違いによるオーバーラップを解消できる。これによって、伝送エラーの回避が促進される。その上、潜在的なあいまいさに対応するためのヘッドルームを最小化または完全に回避できるため、スペクトル利用率を向上することができる。さらに、関連する阻止期間中において、ＢＳは別の送信をスケジューリングすることができる。このため、例えば、ＩｏＴトラフィックおよび非ＩｏＴトラフィックの送信をスケジューリングする際、ＢＳに柔軟性が与えられる。

詳細には、ＵＥにおける送信を阻止すると、ＢＳにおける送信をパンクチャリングすることが容易になる。言い換えれば、ＵＥが１つ以上の禁止ＰＲＢ上での送信を阻止する場合、それによって、送信をパンクチャリングすることによるさらなる送信の挿入が容易になる。例えば、パンクチャリングによって、ＩｏＴトラフィックの第１の送信と非ＩｏＴトラフィックの第２の送信とのインターリービングを容易化することができる。第２の送信は、送信期間を短くすることができるため、パンクチャリングするときに阻止時間内に挿入することができる。

例によれば、第１の送信は、ＢＳと第１のＵＥとの間でスケジューリングされる。その後、第１の送信は、少なくとも１つの禁止ＰＲＢ上でパンクチャリングされる。第２の送信は、ＢＳと第２のＵＥ（第１のＵＥと異なっていてもよい）との間で、少なくとも１つの禁止ＰＲＢ上でスケジューリングされる。

図１は、本明細書に開示される技術の恩恵を受けることができる無線通信ネットワーク１００を模式的に示す。ネットワークは、第３世代（Third Generation：３Ｇ）、第４世代ロングタームエボリューション（Fourth Generation Long-Term Evolution：４Ｇ−ＬＴＥ）、または来るべき第５世代新無線（Fifth Generation New Radio：５Ｇ−ＮＲ）などの、３ＧＰＰ標準化されたセルラーネットワークであり得る。他の例として、８０２．１１ｘ Ｗｉ−Ｆｉプロトコル、あるいはブルートゥース（登録商標）（Bluetooth）プロトコルなどの米国電気電子技術者協会（Institute of Electrical and Electronics Engineers：ＩＥＥＥ）指定のネットワークなどの、ポイント・ツー・ポイントネットワークがある。ネットワーク１００は、３ＧＰＰのＮＢ−ＩｏＴ、あるいはｅＭＴ、ｆｅＭＴＣ、ｅｆｅＭＴＣなどを含むＩｏＴ機能を提供し得る。

ネットワーク１００は、ＢＳ１１２およびＵＥ１０１を含む。ＢＳ１１２とＵＥ１０１との間には無線リンク１１４が確立されている。無線リンク１１４は、ＢＳ１１２からＵＥ１０１へのＤＬリンクを含み、さらに、ＵＥ１０１からＢＳ１１２へのＵＬリンクを含む。ＵＬとＤＬの間の干渉を緩和するために、時分割複信（Time Division Duplexing：ＴＤＤ）、周波数分割複信（Frequency Division Duplexing：ＦＤＤ）、空間分割複信（Space Division Duplexing：ＳＤＤ）、および符号分割複信（Code Division Duplexing：ＣＤＤ）のうち少なくとも１つを採用してもよい。同様に、ＴＤＤ、ＦＤＤ、ＳＤＤ、およびＯＤＤのうち少なくとも１つを、無線リンク１１４上で通信する複数のＵＥ（図１には示されていない）の間の干渉を緩和するために採用してもよい。このために、ＢＳ１１２は、スケジューリング機能を実装する。

ＵＥ１０１は、以下のうちの１つであり得る。スマートフォン、携帯電話、テーブル、ノートパソコン、コンピュータ、スマートテレビ、ＭＴＣデバイス、ｅＭＴＣデバイス、ＩｏＴデバイス、ＮＢ−ＩｏＴデバイス、センサー、アクチュエータ、非ＩｏＴ ＵＥ、ＩｏＴ ＵＥなど。

図２は、無線通信ネットワーク１００に関する態様を模式的に示す。ここで、タイプの異なるＵＥ１０１から１０４が、ＢＳ１１２に接続される。例えば、非ＩｏＴ ＵＥ１０１、１０２が、ＢＳ１１２に接続される。 また、ＩｏＴ ＵＥ１０３、１０４がＢＳ１１２に接続される。

通常、ＩｏＴ ＵＥ１０３、１０４の受信機帯域幅は、非ＩｏＴ ＵＥ１０１、１０２の受信機帯域幅よりも小さい。したがって、ＩｏＴ ＵＥ１０３、１０４は、ＢＳ１１２によってサポートされるキャリアのサブバンド上で通信し、一方、非ＩｏＴ ＵＥ１０１、１０２は、ＢＳ１１２によってサポートされるキャリアの全帯域幅にわたって通信することができる。

通常、ＩｏＴ ＵＥ１０３、１０４と、非ＩｏＴ ＵＥ１０１、１０２は、フォーマットの異なるスケジューリング情報を使用してスケジューリングされる。例えば、ＩｏＴ ＵＥ１０３、１０４と、非ＩｏＴ ＵＥ１０１、１０２に対して、ＰＲＢからＲＢＧへの異なるグループ化が採用されてもよい。

図３は、ＢＳ１１２およびＵＥ１０１をより詳細に模式的に示す。

ＢＳ１１２は、プロセッサ（中央処理装置（Central Processing Unit：ＣＰＵ））１１２１と、フロントエンドと呼ばれることもあるインターフェース（Interface：ＩＦ）１１２２を含む。ＩＦ１１１２は受信機および送信機を含む。ＢＳ１１２はさらに、例えば不揮発性メモリなどの、メモリ（Memory：ＭＥＭ）１１２５を含む。メモリは、プロセッサ１１２１によって実行され得るプログラムコードを格納することができる。このように、プロセッサ１１２１およびメモリ１１２５は、制御回路を形成する。プログラムコードを実行することにより、プロセッサ１１２１は、無線リンク１１４上の複数のＵＥ１０１から１０４のスケジューリング、サブバンド上でのキャリアの送信の実行、キャリア上での送信の実行、および送信のパンクチャリングなどにかかわる技術を実行することができる。

ＵＥ１０１は、ＣＰＵ１０１１と、フロントエンドと呼ばれることもあるＩＦ１０１２を含む。ＩＦ１０１２は受信機および送信機を含む。ＵＥ１０１はさらに、例えば不揮発性メモリなどの、ＭＥＭ１０１５を含む。メモリ１０１５は、プロセッサ１０１１によって実行され得るプログラムコードを格納することができる。このように、プロセッサ１０１１およびメモリ１０１５は、制御回路を形成する。プログラムコードを実行することにより、プロセッサ１０１１は、無線リンク１１４上での送信のためのスケジューリング情報の受信、キャリアのサブバンド上での送信の実行、キャリア上での送信の実行、および送信の阻止などにかかわる技術を実行することができる。

図３は、ＵＥ１０１を例示のために示すものであるが、ＵＥ１０２から１０４が同様の構成を備えていてもよい。例えば、ＵＥ１０３、１０４のインターフェース１０１２の能力は、ＵＥ１０１、１０２のインターフェース１０１２の能力と比べて、例えば、送信帯域幅などの点で制限されてもよい。

図４は、スケジューリング情報４００１の通信に関する態様を模式的に示す。スケジューリング情報４００１は、５００１で、ＢＳ１１２によって送信され、ＵＥ１０３によって受信される。スケジューリング情報４００１は、複数のＰＲＢ上の送信５９９１のためのものである。よって、スケジューリング情報４００１は、スケジューリング情報４００１に含まれる、例えばスケジューリングビットマップのような、１つ以上の指標を複数のＰＲＢにマッピングする所定のフォーマットに従ったものであり得る。例えば、ＤＣＩを使用することができる。

図４のシナリオにおけるスケジューリング情報４００１は、例えばアプリケーションデータや上位層制御データなどの、データ４００２の５００２におけるＤＬ送信５９９１のためのものである。

例えば、ＤＬ送信５９９１は、物理ダウンリンク共有チャネル（Physical DL Shared Channel：ＰＤＳＣＨ）上であり得る。

ＤＬ送信５９９１は、データの複数の繰り返しを含むことができる。すなわち、ＣＥ技術に従ったものであり得る（図４には図示せず）。

スケジューリング情報４００１は、データのＵＬ送信のためのものでもあり得る（図５参照）。

図５は、スケジューリング情報４００１の通信に関する態様を模式的に示す。スケジューリング情報４００１は、５０１１で、ＢＳ１１２によって送信され、ＵＥ１０３によって受信される。スケジューリング情報４００１は、複数のＰＲＢ上の送信５０９２のためのものである。よって、スケジューリング情報４００１は、スケジューリング情報４００１に含まれる、例えばスケジューリングビットマップのような、１つ以上の指標を複数のＰＲＢにマッピングする所定のフォーマットに従ったものであり得る。

例えば、スケジューリング情報４００１は、物理ＤＬ制御チャネル（Physical DL Control Channel：ＰＤＣＣＨ）上で送信され得る。

図５のシナリオにおけるスケジューリング情報４００１は、例えばアプリケーションデータや上位層制御データなどの、データ４００２の、５０１２での、ＵＬ送信５９９２のためのものである。

例えば、ＵＬ送信５９９２は、物理アップリンク共有チャネル（Physical UL Shared Channel：ＰＵＳＣＨ）上であり得る。

例えば、ＵＬ送信５９９２は、データの複数の繰り返しを含むことができる。すなわち、ＣＥ技術に従ったものであり得る（図５の複数の矢印によって示される）。繰り返し回数は、ＣＥレベルに基づいて決定することができる。ＣＥレベルによって、ベースラインカウントを定義することができる。ＣＥレベルは、ＵＬ送信５９９２を完了するために必要な期間６８１とも関連している。

図５の図示から理解されるように、高いＣＥレベルに依存するＩｏＴトラフィックの送信は、大幅な送信期間６８１の間、無線リンク１１４を占有する可能性がある。これは、他のタイプのトラフィックの送信にも言えることであり、それには、拡張モバイルブロードバンド（Enhanced Mobile Broadband：ｅＭＢＢ）および超高信頼性低遅延通信（Ultra-Reliable and Low Latency Communications：ＵＲＬＬＣ）が含まれるが、それらに限定されるものではない。３ＧＰＰ技術報告（ＴＲ）３８．９１２、バージョン１４．１．０、およびＴＲ３８．９１３、バージョン１４．１．０を参照されたい。ＵＲＬＬＣは、ＣＥ技術と同様に、カバレッジを向上するために信号の複数繰り返しに依存し得る。

以下、ＩｏＴトラフィックに関連する送信（通常、送信期間６８１に関連する長いチャネル占有を伴う）および非ＩｏＴトラフィックに関連する送信の両方に関して、無線リンク１１４への偏りのないアクセスを容易化する戦略について説明する。

図６は、時間周波数リソースグリッド６９８に関する態様を模式的に示す。時間周波数リソースグリッド６９８は、キャリア５００の帯域幅にわたって定義される。キャリアは、例えば、ＯＦＤＭ変調に従って、複数のサブキャリアを含む。シンボルは時間領域で定義される。シンボルとサブキャリアは、データを符号化可能なアトミック単位としてＰＲＥ６９９を定義する。

複数のＰＲＥ６９９がＰＲＢ６００から６１６にまとめられる。したがって、ＰＲＢ６００から６１６のそれぞれは、複数のリソースエレメント（Resource Element：ＲＥ）６９９を含む（図６の非限定的な例では、ＰＲＢごとに２×６＝１２個のＲＥがある）。例えば、３ＧＰＰ ＬＴＥの場合、ＰＲＢは、周波数領域では１２個のサブキャリアで構成され、時間領域では７個のＯＦＤＭシンボルで構成される。

通常、時間周波数リソースグリッド６９８は、送信フレームおよびサブフレームに構造化される。各サブフレームは、例えば１ｍｓのような特定の期間を有している。各サブフレームは、特定の数のＰＲＢ６００から６１６を含む（図６では、簡略化のため、ＰＲＢ６００から６１６の単一インスタンスのみが時間領域で図示されている）。

低オーバーヘッドのスケジューリングを容易化するために、スケジューリング情報４００１のフォーマットに応じて、複数のＰＲＢ６００から６１６がＲＢＧにまとめられる。すると、ＲＢＧは個別にスケジューリング可能なアトミック単位となる。

例によれば、複数のＰＲＢが送信５９９１、５９９２のためにスケジューリングされる。したがって、複数のＰＲＢ上の送信５９９１、５９９２のためのスケジューリング情報４００１が通信される。例えば、スケジューリング情報４００１は、１つ以上のＲＢＧを示し得る。

例えば、図６のシナリオでは、ＩｏＴ ＵＥ１０３、１０４のための狭帯域５１１内のＰＲＢ６０１から６０７上での送信のためのスケジューリング情報が通信され得る。例えば、ＭＴＣ ＣＥモードＢでは、狭帯域５１１に関して、４つのＰＲＢまたは６つのＰＲＢがまとめてスケジューリングされ得る。その後、制御情報に基づいて、スケジューリング情報が狭帯域５１１のＰＲＢ６０１から６０７をカバーしているにもかかわらず、１つ以上の禁止ＰＲＢ６８０（図６の破線（図６では、ＰＲＢ６０６が禁止ＰＲＢ６８０である））について、送信が阻止され得る。

禁止ＰＲＢ６８０に依存することで、（Ｉ）ＩｏＴ ＵＥ１０３、１０４と非ＩｏＴ ＵＥ１０１、１０２に対する粒度の異なるＲＢＧへのクラスター化に依存する可能性があるスケジューリング情報のフォーマット、および（ＩＩ）キャリア５００上の非ＩｏＴ ＵＥ１０１、１０２とＩｏＴ ＵＥ１０３、１０４のリソース効率のよい共存に対して、柔軟性を提供しやすくなる。

具体的には、１つ以上の禁止ＰＲＢ６８０によって、ＢＳ１１２におけるそれぞれの送信５９９１、５９９２のパンクチャリングが容易化され得る。詳細には、ＩｏＴ ＵＥ１０３、１０４に対してスケジューリングされた送信５９９１、５９９２が、禁止ＰＲＢ６８０でパンクチャリングされ、その後、ＢＳ１１２とＵＥ１０１、１０２との間のさらなる送信５９９１、５９９２に、禁止ＰＲＢ６８０を使用することができるであろう。

これらの知見について、いくつかの実施例に関して、以下により詳細に説明する。

例えば、ＩｏＴ ＵＥ１０３、１０４などに使用されるｅＭＴＣは、６つのＰＲＢ（７２×１５ｋＨｚサブキャリアまたは１．４ＭＨｚ）の狭い帯域幅で動作する。ここで、フィルタリングや信号ロールオフなどのために、７２×１５＝１．０８ＭＨｚおよびいくらかの追加帯域幅が必要とされ、信号の全帯域幅は１．４ＭＨｚとなる。６つのＰＲＢは、ｅＭＴＣ用のサブバンド（狭帯域とも呼ばれる）を形成する。例えば、図６はサブバンド５１１および５１２を示す。サブバンド５１１、５１２は、ＬＴＥ非ＩｏＴキャリア５００の２０ＭＨｚ帯域幅と比較した場合、より狭い帯域幅を有する。このより狭い帯域幅によって、ＵＥ１０３、１０４の無線周波数（Radio Frequency：ＲＦ）フロンドエンドの複雑さが低減され、したがって、そのコストが低減される。

したがって、ＬＴＥキャリア５００は、ｅＭＴＣ動作のために、オーバーラップしない複数のサブバンド５１１、５１２に分割される。キャリア５００のＬＴＥシステム帯域幅は、１．４ＭＨｚ、３ＭＨｚ、５ＭＨｚ、１０ＭＨｚ、１５ＭＨｚ、２０ＭＨｚであり、それぞれ、６、１５、２５、５０、７５、１００個のＰＲＢを周波数領域に含む。

１．４ＭＨｚの場合を除いて、システム帯域幅内のＰＲＢの総数は、６つのＰＲＢで構成されるサブバンドに均等に分割できないことが多い。余ったＰＲＢは、キャリア５００のシステム帯域幅の上部と下部が等しい数のＰＲＢを含むように分配され、余ったＰＲＢが奇数の場合、１つのＰＲＢがシステム帯域幅の中央に配置される。例えば、図６に示すように、３つのＰＲＢ６００、６０８、６１６を未使用のままにして、１５個のＰＲＢシステム帯域幅（３ＭＨｚ）を、２つのサブバンド全体に納めることができる。これらの余ったＰＲＢ６００、６０８、６１６については、１つの未使用のＰＲＢ６００、６１６がシステム帯域幅の両端に置かれ、残ったＰＲＢ６０８がシステム帯域幅の中央に挿入される。ＰＲＢ６０１から６０７は、サブバンド５１１に割り当てられ、ＰＲＢ６０９から６１５は、サブバンド５１２に割り当てられる。

ＬＴＥにおいては、ＤＬ送信のためのスケジューリング情報はリソース割り当てフォーマット０を使用することが多い。ここで、キャリア５００のシステム帯域幅は複数のＲＢＧに分割され、各ＲＢＧはＮ_ＲＢ個のＰＲＢから構成される。ＲＢＧは、ＰＤＳＣＨ／ＰＵＳＣＨに対するリソース割り当ての粒度である。すなわち、ＤＬ／ＵＬリソースは、ＵＥのためのＲＢＧの数で割り当てられる。値Ｎ_ＲＢはシステム帯域幅に依存し、表１に要約されている。

図７は、５０個のＰＲＢ６００から６４９を含む１０ＭＨｚキャリア５００の一例を示す。ここで、５０個のＰＲＢ６００から６４９は１７個のＲＢＧ５５０から５６６に分割される。そのうち、１６個のＲＢＧ５５０から５６５は３ＰＲＢ分の幅を持ち、例えば、ＲＢＧ５５６はＰＲＢ６１８、６１９、６２０で構成される。最後のＲＢＧ５６６は２ＰＲＢ分の幅を持ち、ＰＲＢ６４８、６４９で構成される。

３ＧＰＰ Ｒ１−１７２０５４１には、キャリア５００とｅＭＴＣのサブバンド５１０から５１７にまたがって定義されたＬＴＥバンド内のＲＢＧが整列していないことが述べられている。例えば、図７において、サブバンド５１０から５１７は、キャリア５００の両端に配置された２つの未使用のＰＲＢ６００、６４９に対して中心に位置するようにキャリア５００の帯域幅内に配置される。ＲＢＧ５５０から５６６およびサブバンド５１０から５１７がＰＲＢに対して整列してない、すなわち、同じＰＲＢ６００から６４９からスタートしていないということが確認できる。

ＲＢＧ５５０から５６６とサブバンド５１０から５１７の間のこの不整合の結果、ＬＴＥとｅＭＴＣの両方をサポートするシステムにおいて、または、一般に、例えば、異なるフォーマットのスケジューリング情報を使用して異なるスケジューリングをしたＩｏＴトラフィックおよび非ＩｏＴトラフィックの送信において、使用されたサブバンド５１０から５１７とオーバーラップするＲＢＧ５５０から５５６は、非ＩｏＴ ＵＥ１０１、１０２に対してスケジューリングすることはできない。

これは図７に示されている。ここでは、サブバンド５１３がスケジューリングされ、ＰＲＢ６１９から６２４に割り当てられる。前述のように、ＲＢＧは、非ＩｏＴ ＵＥ１０１、１０２のＰＤＳＣＨスケジューリングの最小粒度であり、ＰＲＢ６１９、６２０は、ＩｏＴ ＵＥ１０３、１０４をスケジューリングするためにサブバンド５１３用に使用されるため、ＲＢＧ５５６（これらのＰＲＢ６１９、６２０を含む）を非ＩｏＴ ＵＥ１０１、１０２のスケジューリングのために使用することができない、したがって、非ＩｏＴ ＵＥ１０１、１０２はＰＲＢ６１８を使用することができないということが確認できる。同様に、ＲＢＧ５５８のＰＲＢであるＰＲＢ６２５と６２６の大部分がサブバンド５１３の外にあるにも関わらず、ＰＲＢ６２４は、ＲＢＧ５５８の使用を防止しているサブバンド５１３に占有されている。この結果、ＬＴＥシステムのセルスループット／スペクトル効率が低下する。

３ＧＰＰ ＬＴＥ ＭＴＣ、リリース１５の適用範囲が更新され、少なくとも１．４ＭＨｚの最大ＭＴＣチャネル帯域幅で構成されたＣＥモードＡ／Ｂで動作するＵＥに対して、接続モードでのＰＤＳＣＨ／ＰＵＳＣＨリソース割り当てのためのより柔軟な開始ＰＲＢに対するサポートが含まれるようになった。３ＧＰＰ ＲＰ−１７２８１１を参照されたい。

以下、特に上記構成において、未使用のＰＲＢの削減を容易化する技術について説明する。そのように本明細書で説明する技術を採用すると、スペクトル利用を向上させることができる。

例示のため、ＩｏＴ ＵＥ１０３はサブバンド５１２を使用するように割り当てられると仮定する。拡張カバレッジ動作の必要性のために、ＩｏＴ ＵＥ１０３は、また、Ｎ回の繰り返しによって、すなわち、ＣＥレベルＮのＣＥ技術で送信するように割り当てられている。ＰＲＢが、例えばＲＢＧ５５４、５５５、５５６を含むＲＢＧの単位で割り当てられるならば、ＰＲＢ６００から６４９の任意のＰＲＢを使用することができる同じＢＳ１１２によってスケジューリングされたセルには他の非ＩｏＴ ＵＥ１０１、１０２も存在する。

従来のシナリオでは、非ＩｏＴ ＵＥ１０１、１０２は、サブバンド５１２とオーバーラップする部分のあるＲＢＧ５５４、５５６の一部であるため、ＰＲＢ６１２、６１９、６２０を使用できないであろう。例えば、ＰＲＢ６１８から６２０のすべては集合的ＲＢＧ５５６の一部であるため、ＰＲＢ６１９、６２０は、ＰＲＢ６１８なしでは、個別にアドレス指定できない。したがって、ＲＢＧ５５６の割り当てを示すスケジューリング情報を使用する非ＩｏＴ ＵＥ１０１、１０２のいかなるスケジューリングも、ＰＲＢ６１８上のＩｏＴ ＵＥ１０３との衝突を招く可能性があるであろう。

これを回避するために、禁止ＰＲＢ６８０に関する制御情報が使用される。サブバンド５１２上でスケジューリングされたＩｏＴ ＵＥ１０３は、禁止ＰＲＢ６８０上での送信を阻止する。図７の例では、禁止ＰＲＢ６８０はＰＲＢ６１３、６１４、６１８である。

ＩｏＴ ＵＥ１０３は禁止ＰＲＢ６８０上の送信を阻止するので、非ＩｏＴ ＵＥ１０１、１０２のいずれをスケジューリングするためにも、ＲＢＧ５５４、５５６を安全に使用することができる。したがって、ＢＳ１１２とＩｏＴ ＵＥ１０３の間の送信は、禁止ＰＲＢ６８０を用いてパンクチャリングされ、禁止ＰＲＢ６８０は、ＢＳ１１２と１つ以上の非ＩｏＴ ＵＥ１０１、１０２の間のさらなる送信をスケジューリングするために用いられる。

原則として、任意の禁止ＰＲＢ６８０上での送信を阻止するために使用できる様々なオプションがある。１つの例では、例えば、１つ以上の禁止ＰＲＢ６８０を含むＲＢＧのような複数のＰＲＢをスケジューリングするスケジューリング情報が受信されたとしても、ＵＥ１０３、１０４のそれぞれは、そのような禁止ＰＲＢ６８０の使用を控えることができる。例えば、それぞれのデータを非禁止ＰＲＢに再配布することもできる（そうしない場合、禁止ＰＲＢに割り当てられる）。これには、時間領域と周波数領域の少なくとも一方における送信の拡張を含んでもよい。１つの例では、任意の禁止ＰＲＢ６８０に従って送信を一時停止することを、阻止することに含めることができる。阻止するときに、任意の禁止ＰＲＢ６８０の送信と受信の少なくとも一方を一時停止することができる。例えば、送信バッファ（例えば、ＨＡＲＱバッファ）は、保存および維持されてもよく、消去されなくてもよい。すると、阻止が非アクティブ化されると、送信を再開できる。スケジューリング情報４００１は、１つ以上の禁止ＰＲＢを含む複数のＰＲＢに関するものである。例えば、スケジューリング情報４００１は、複数のＰＲＢをＵＥ１０３、１０４のそれぞれにまとめて割り当てることができる。その後、制御情報を用いて、１つ以上の禁止ＰＲＢ６８０への割り当てを、上記阻止の一部としてオーバーライドすることができる。

原則として、制御情報は、送信バッファを維持することを含め、送信を一時停止して再開することによって阻止を実行するか、または送信をやり直すことによって阻止を実行するかどうかを指定できる。送信のやり直しには、送信の終了を含んでもよく、これには、送信バッファの消去や、例えばＨＡＲＱプロトコルなどのカウンターやタイマーの再初期化を含んでもよい。例えば、関連するトラフィックのレイテンシに基づいて、（Ｉ）一時停止して再開するか、（ＩＩ）送信をやり直すかを選択してもよい。低レイテンシトラフィックに対しては送信のやり直しを選択する傾向を有してもよい。例えば、ネットワークがＤＬ制御シグナリングを提供して、（Ｉ）一時停止して再開するか、（ＩＩ）送信をやり直すかの選択を指示してもよい。他のシナリオでは、ＵＥがこの選択を行うことができる。ＵＥとネットワークの間でこの選択に関するネゴシエーションを行うこともできる。

いくつかの例では、１つ以上の禁止ＰＲＢ６８０は、ＵＥ１０３、１０４のそれぞれにおいて固定的に構成され得る。さらなる例では、ＢＳは、１つ以上の禁止ＰＲＢ６８０をＵＥ１０３、１０４に示す。ＵＥ１０３、１０４のそれぞれは、１つ以上の禁止ＰＲＢ６８０に関する制御情報を示すＤＬ構成制御メッセージを受信することができる。ＤＬ構成制御メッセージは、それぞれのＢＳ１１２スケジューリングによって送信することができる。ＤＬ構成制御メッセージによって、ＢＳ１１２はそれぞれの送信をパンクチャリングすることができ、それによって、さらなる送信に対応することができる。したがって、ＤＬ制御情報は、プリエンプション指示と呼ばれることがある。ＤＬ構成制御メッセージは、ＢＳにおける送信のパンクチャリングの整合化に役立つ。

例えば、ＤＬ構成制御メッセージは、ＲＲＣ制御メッセージであり得る。ＤＬ構成制御メッセージは、スケジューリング情報とは別に通信され得る。制御情報のそのような指示は、明示的であっても、暗黙的であってもよい。例えば、ＵＥ１０３、１０４のそれぞれは、阻止機能が適用されることを知らされる可能性があり、すると、ＵＥ１０３、１０４は、サブバンド５１０から５１７と部分的にオーバーラップするＲＢＧ５１０から５１７の部分である、サブバンド５５０から５６６内のＰＲＢ６００から６４９のいずれもが無効であることを知る。例えば、ＩｏＴ ＵＥ１０３がサブバンド５１２上に割り当てられている場合、ＵＥ１０３は、ＰＲＢ６１３、６１４、６１８が禁止ＰＲＢ６８０であると決定することができる。

したがって、送信がキャリア５００のサブバンド５１０から５１７上である場合、１つ以上の禁止ＰＲＢ６８０を、サブバンド５１０から５１７の外側にあるキャリア５００の一部とオーバーラップするＲＢＧ５５０から５５６に関連付けることができる（図７は、サブバンド５１２に関連するＲＢＧ５５４、５５６に対するオーバーラップ６９０を示している）。したがって、オーバーラップ６９０は、キャリア５００の全域にわたるさらなる送信に影響を与える。

ここで、キャリア５００上でのスケジューリングに使用されるスケジューリング情報によって使用されるものと同じＲＢＧ５５０から５５６にも依存するフォーマットを有するサブバンド５１０から５１７上でのスケジューリングに、スケジューリング情報を使用することは必須ではない。

原則として、ＰＲＢを実装すべきオーバーラップ６９０から、禁止ＰＲＢ６８０であると結論づけるために、様々な基準を適用できる。例えば、ＲＢＧ５５０から５５６に対するオーバーラップ６９０が存在する場合、それぞれのＲＢＧ５５０から５５６の任意のＰＲＢ６００から６４９が阻止され得る。

いくつかの例では、オーバーラップ６９０が所定のしきい値より大きい場合、送信を全面的または部分的に阻止することができる。例えば、しきい値は５０％であってもよい。図７の例では、ＲＢＧ５５４のオーバーラップ６９０は、１／３＝３３％であり、したがって、しきい値未満である。そこで、ＲＢＧ５５４のＰＲＢ６１３、６１４は阻止されなくてもよい。一方、ＲＢＧ５５６のオーバーラップ６９０は２／３＝６６％であり、したがって、しきい値を超えている。そこで、ＲＢＧ５５６のＰＲＢ６１８は阻止されてもよい。しきい値の比較に依存することによって、ＩｏＴトラフィックの送信と非ＩｏＴトラフィックの送信の適正なバランスを実現できる。

しきい値は、ＤＬ制御シグナリングで示されるか、固定的に設定される。

ＢＳ１１２は、任意の禁止ＰＲＢ６８０を補償するために追加的リソースを示すこともできる。図８はそれを示している。

図８は、送信５９９１、５９９２のために割り当てられたリソースを時間の関数として模式的に示す。図８は、禁止ＰＲＢ６８０が定義されていることを示している。このように、禁止ＰＲＢ６８０のために不足しているリソースを補償するために、リソースがスケジューリングされるベースライン期間６８５は、延長期間６８６だけ延長される。例えば、ベースライン期間６８５は、従来のシナリオにおける送信期間６８１に対応することができる。延長期間６８６は、ＢＳ１１２におけるスケジューラによって考慮され得る。延長期間６８６は、送信５９９１、５９９２の期間を延長する。

延長期間６８６は、スケジューリング情報４００１に明示的または暗黙的に示されてもよい。いくつかの例では、延長期間６８６をスケジューリング情報４００１によって示さず、ＢＳ１１２およびスケジューリングされたＵＥ１０１から１０４が、１つ以上の禁止ＰＲＢ６８０の決定に使用される制御情報から導出することも可能であろう。例えば、禁止ＰＲＢ６８０の数に基づいて延長期間６８６を決定することができる。その後、延長期間６８６によって、スケジューリング情報４００１によって定義されたベースライン期間６８５を延長することができる。

例えば、ＣＥフレームワークにおいて、延長期間６８６を使用して、信号の追加的繰り返しに対応することができる。追加的繰り返しによって、禁止ＰＲＢ６８０によって減少した帯域幅を補償することができる。

例えば、ＣＥ技術が採用された場合、禁止ＰＲＢ６８０の数に応じて、データの複数の繰り返し数を決定することができる。次に、複数の繰り返しの繰り返し率に基づいて、延長期間６８６について結論づけることができる。

禁止ＰＲＢ６８０の数が多いほど、ＣＥ技術の繰り返し数が増える傾向を有してもよい。例えば、対応するＤＬ制御シグナリングにおいて、それぞれのマッピングを示してもよい。マッピングは、禁止ＰＲＢ６８０の数と繰り返し数の間のものであってもよい。すると、マッピングを使用して繰り返し数を決定することができる。

詳細には、いわゆる「追加的繰り返し」ファクターを定義することができる。追加的繰り返しファクターによって、延長期間６８６に関連付けられた繰り返しの拡張数を決定してもよい（繰り返しの拡張数は、ベースライン期間６８５に関連付けられた繰り返しのベースラインカウントを超えて定義される）。通常、繰り返しのベースラインカウントは、例えば、受信信号強度、ビット誤り率などの送信の信号品質に基づいて決定される。

原則として、ＩｏＴ ＵＥ１０３、１０４が追加的繰り返しファクターをどのように決定できるかについては、様々な手法が利用可能である。

１つの例では、追加的繰り返しファクター数は事前に定義されており、例えば、ルールセットに従ってハードコーディングされている。すると、ＩｏＴ ＵＥ１０３、１０４は、以下のうち少なくとも一方に基づいて、どの追加的繰り返しファクターを適用するかを決定することができる。（Ｉ）禁止ＰＲＢ６８０の数と追加的繰り返しファクターとの間がマッピングされている。（ＩＩ）ＩｏＴ ＵＥ１０３、１０４は、例えば、禁止ＰＲＢ６８０に苦しめられているサブバンド５１０から５１７を用いてＩｏＴ ＵＥ１０３、１０４をスケジューリングするＤＣＩにおいて、適用すべき追加的繰り返しファクターのインデックスをシグナリングされている。ＩｏＴ ＵＥ１０３、１０４は、禁止ＰＲＢ７８０のパーセンテージを考慮することにより、これらの追加的繰り返しを決定することができる。例えば、ＩｏＴ ＵＥ１０３、１０４には、６つのＰＲＢおよび３２回の繰り返し（ベースラインカウント）が割り当てられる。ＢＳ１１２は、６つのＰＲＢのうちの１つのＰＲＢが禁止ＰＲＢ６８０であることを、例えば、ＲＲＣ ＤＬ制御シグナリングまたはＤＣＩから、シグナリングする。すると、ＩｏＴ ＵＥ１０３、１０４は、追加的繰り返しファクターを［１／６×３２］＝６として決定することができる。すなわち、ＩｏＴ ＵＥ１０３、１０４は、拡張数６を用いて繰り返しを３２（ベースラインカウント）から３８に拡張することによって、禁止ＰＲＢ６８０によって失われたリソースを補償する。

上記の情報を、ＤＣＩまたは高位層制御シグナリング、例えば、ＲＲＣを介して、ＩｏＴ ＵＥ１０３、１０４にシグナリングすることができる。

図８では、延長期間６８６における追加的リソースは、元のリソースに直接隣接している。図９では、ベースライン期間６８５と延長期間６８６との間にはギャップ６８７がある。例えば、データのレガシーのＮ回繰り返しと延長繰り返しは、ギャップ６８７によって分離されている。本明細書で説明する様々な例では、そのようなギャップ６８７を採用してもしなくてもよい。

図８および図９の例では、阻止６８０は、送信５９９１、５９９２の間中アクティブ化される。原則として、阻止を静的にアクティブ化することができる。あるいは、阻止を動的にアクティブ化および非アクティブ化することもできる。

１つの例では、少なくとも１つのＤＬアクティブ化制御メッセージが通信されうる。すなわち、ＢＳ１１２によって送信されたり、ＵＥ１０１から１０４のそれぞれによって受信されたりし得る。少なくとも１つのＤＬアクティブ化制御メッセージに応じて、阻止をアクティブ化や非アクティブ化することができる。

１つの例では、ＤＬアクティブ化制御メッセージは、上記阻止がアクティブ化や非アクティブ化される期間を示し得る。したがって、ＢＳ１１２における送信５９９１、５９９２のパンクチャリングは、ＤＬアクティブ化制御メッセージに従うことができる。

ＤＬアクティブ化制御メッセージは、一般に、部分的に阻止され、パンクチャリングされる送信５９９１、５９９２を開始する前または後に通信され得る。例えば、送信５９９１、５９９２を開始し、その後、開始後に、ＤＬアクティブ化制御メッセージを通信することができる。

１つの例では、ＢＳ１１２は、ＣＥ繰り返しのどの部分を阻止すべきかを示すことができ、例えば、ＣＥ繰り返しに関連付けられたシーケンス番号を、阻止がアクティブ化されるＣＥ繰り返しの間、示すことができる。例えば、無線リンク１１４上で使用される送信プロトコルのサブフレームのシーケンス番号を示してもよい。すると、これらのサブフレームによってホストされるすべてのＣＥ繰り返しが阻止され得る。

例えば、図１０において、ＩｏＴ ＵＥ１０３、１０４は、ＰＵＳＣＨ上でアプリケーションデータをＮ回繰り返す（ＣＥレベル）ように構成される。ＤＬアクティブ化制御メッセージ４０２１は、禁止ＰＲＢ６８０上で阻止がアクティブ化される阻止期間６８９に関連付けられたＭ個のサブフレームを示す。阻止期間６８９は、送信ギャップに対応する。例えば、それぞれの送信プロトコルの各サブフレームは、ＣＥ技術の１回以上の繰り返しを含み得る。

ＩｏＴ ＵＥ１０３、１０４は、阻止期間６８９中のこれらのＭサブフレームの期間中に、そのＰＵＳＣＨ送信を一時停止する。そして、ＩｏＴ ＵＥ１０３、１０３は、中断された繰り返しを補償するために、延長時間６８２の間、その繰り返しを延長する。図１０では、１つ以上の禁止ＰＲＢ６８０は、送信５９９１、５９９２に割り当てられた帯域幅全体にわたっていない。例えば、送信５９９１、５９９２に割り当てられた帯域幅は、ＩｏＴシナリオにおけるサブバンド５１０から５１７のそれぞれによって定義され得る。図１０では、送信５９９１、５９９２は、それぞれのＵＥによって部分的に阻止される。

図１１は、送信全体が中断される、より大量の禁止ＰＲＢ６８０に関するシナリオを示す。ここで、禁止ＰＲＢ６８０は、送信５９９１、５９９２の全帯域幅をカバーする。したがって、図１１では、送信５９９１、５９９２は全面的に阻止されている。原則として、本明細書で説明する様々な例においては、送信５９９１、５９９２は全面的または部分的に阻止され得る。

図１２の例では、２つのＤＬアクティブ化制御メッセージ４０２２、４０２３がＢＳ１１２からＩｏＴ ＵＥ１０３、１０４に通信される。最初のＤＬアクティブ化制御メッセージ４０２２は、阻止のアクティブ化を示す。続くＤＬアクティブ化制御メッセージ４０２３は、阻止の非アクティブ化を示す。したがって、このＤＬアクティブ化制御メッセージ４０２３は、ＩｏＴ ＵＥ１０３、１０４の前回のＰＵＳＣＨ送信を再開するように機能する。

原則として、本明細書で説明する様々な例では、前回の送信の再開は必須ではない。むしろ、（Ｉ）送信を再開するか、（ＩＩ）送信をやり直すかを選択することができる。この選択は、ＵＥとネットワークの少なくとも一方が実行することができる。例えば、ネットワークがこの選択を指示してもよいし、ＵＥとネットワークの間でネゴシエートしてもよい。いくつかの例では、１つ以上のＤＬアクティブ化制御メッセージ（例えば、図１２では、ＤＬアクティブ化制御メッセージ４０２２とＤＬアクティブ化制御メッセージ４０２３のうち少なくとも一方、または図１０および１１では、ＤＬアクティブ化制御メッセージ４０２１、など）、および１つ以上のＤＬ構成制御メッセージのうち少なくとも一方を使用して、阻止期間６８９の後に以前の送信を再開するかどうか、または阻止期間６８９の後に以前の送信を再開せずやり直すかどうかを示すことができる。そのようなやり直しには、送信の終了が含まれ得る。終了には、バッファの消去、ＨＡＲＱプロトコルの再初期化、１つ以上のカウンターやタイマーの再初期化などが含まれ得る。

図１３の例では、ＤＬアクティブ化制御メッセージ４０２４は、上記阻止の上記アクティブ化および非アクティブ化の繰り返しスケジュールを示している。これによって、不連続送信（Discontinuous Transmission：ＤＴＸ）スケジュールを実現できる。単一のＤＬアクティブ化制御メッセージ４０２４を使用して、阻止を複数回アクティブ化および非アクティブ化できる。そのようにして、複数の阻止期間６８９が定義される。これにより、非ＩｏＴ ＵＥ１０１、１０２のデータをスケジューリングする柔軟性がＢＳ１１２に与えられる。ＤＴＸスケジュールを使用すると、ＢＳ１１２で送信５９９１、５９９２を複数回パンクチャリングするのに役立つ。

原則として、ＤＴＸスケジュールは周期的であっても非周期的であってもよい。ＤＴＸスケジュールは、オン期間とオフ期間の繰り返しを含むことができる。これらの繰り返しは、可変周期性を持つなどして、周期的または非周期的に配置できる。

本明細書で用いられるように、ＤＴＸスケジュールを、ＵＬ送信やＤＬ送信をパンクチャリングするために適用することができる。ＤＴＸスケジュールは、受信や送信に影響を与える可能性がある。受信に関連するＤＴＸは、不連続受信（Discontinuous Reception：ＤＲＸ）と呼ばれることがあり、これは、本明細書で説明するＤＴＸの特別な形式である。

図９から１３の例では、阻止期間６８９中に上記阻止をアクティブ化にしている間、ＩｏＴ ＵＥ１０３、１０４は送信を終了することができるが、ＨＡＲＱバッファを消去することはできない。これにより、ＩｏＴ ＵＥ１０３、１０４は、例えば、阻止期間６８９が経過した後や、ＤＬアクティブ化制御メッセージ４０２３を受信した際には、上記阻止を非アクティブ化するときに送信を再開することができる。一般的に言えば、例えば、阻止の非アクティブ化に伴って、送信を開始することができる。上記阻止をアクティブ化すると、任意の禁止ＰＲＢ６８０上での送信が一時停止される。上記阻止を非アクティブ化すると、１つまたは複数の禁止ＰＲＢ６８０上での送信が再開される。送信バッファは、上記一時停止と上記再開の間、維持されてもよい。それにより、任意の禁止ＰＲＢ６８０上での送信のためにスケジューリングされたデータを、送信バッファに保持することができる。これによって、低レイテンシ送信が容易化される。

このことを、図１４に関連して説明する。例えば、ＩｏＴ ＵＥ１０３は、ベースライン期間６８５に相当するＮ回の繰り返しでＰＵＳＣＨを送信するＵＬ許可を与えられる。この送信の間、ＢＳ１１２は、例えばＤＣＩを用いて実装されたＤＬアクティブ化制御メッセージ４０２２を使用して、ＩｏＴ ＵＥ１０３は送信を一時停止すべきであるが、Ｋ回の繰り返しの後でＨＡＲＱバッファを消去すべきではないということを示す。その後、ＢＳ１１２は、Ｍ個の最大送信期間について、他の非ＩｏＴ ＵＥ１０１、１０２をスケジューリングすることができる。少し時間が経過した後、ＭＴＣ ＵＥは、Ｌ回の繰り返しを使用して以前のＰＵＳＣＨ送信を再開するようＩｏＴ ＵＥ１０３に伝えるＤＬアクティブ化制御メッセージ４０２３を受信する。値ＬはＮないしＫにすることができるが、ＣＥにおける繰り返し数は、通常、２の累乗［２、４、８、１６、３２、６４など］で割り当てられるため、必ずしもその必要はない。ＢＳ１１２は、以前の送信を再開する代わりに新規のＰＵＳＣＨ送信のためのＤＣＩを送信することもでき、それによって、以前のＰＵＳＣＨ ＨＡＲＱバッファを消去することをＵＥに暗黙的に指示することもできるということも理解されたい。

図１４の例から理解されるように、一般に、送信５９９１、５９９２が複数の繰り返しを含む場合、１つ以上の禁止ＰＲＢ６８０を使用する阻止は、複数の繰り返しの間に発生し得る。

図１５および１６は、ＤＴＸスケジュールに従った、第１の送信５９９１、５９９２のスケジューリングおよび第２の送信５９９５（図１５および１６の塗りつぶされた領域）のスケジューリングの詳細を示す。第１の送信は、阻止時間間隔６８９を定義するＤＴＸスケジュールを使ってパンクチャリングされる。

例えば、送信５９９１、５９９２は、ＰＤＳＣＨまたはＰＵＳＣＨ上でＮ回繰り返され得る。ｋ番目のギャップのために、長さＭ_ｋのギャップが、ＰＤＳＣＨ／ＰＵＳＣＨ送信５９９１、５９９２をパンクチャリングするために使用される。ここで、ＵＥ１０３、１０４に送信されるそれぞれのスケジューリング情報を使用して、目標繰り返し数Ｎがスケジューリングされ、ＵＥ１０３、１０４は、ＤＬ構成制御メッセージ４０２４によって示される制御情報に従ってスケジューリング情報をオーバーライドすることにより、ＤＴＸスケジュールを使って送信５９９１、５９９２を繰り返し阻止する。この結果、延長期間６８２がもたらされる。延長期間６８２は、阻止期間６８９の合計よりも長くなり得る。

これにより、ＢＳ１１２は、阻止期間６８９内にもう１つの送信５９９５をスケジューリングすることによって、送信５９９１、５９９２をパンクチャリングすることができる。

このような技術は、特定の種類や型式の送信５９９１、５９９２、５９９５に限定されない。例えば、ＣＥを使用するｅＭＴＣは、送信５９９１、５９９２に使用できるが、一般に、期間の異なる２つ以上の送信５９９１、５９９２、５９９５がそれらのリソースを部分的または全面的に共有することを必要とする様々なユースケースが考えられる。そのような送信の一例が、ＮＲにおいて見られ、そこでは、いかなるレイテンシも許容しない、信頼性の非常に高い通信が要求されるＵＲＬＬＣなどのより短期の送信が、ｅＭＢＢなどの長い送信よりも優先される。阻止期間６８９の間に、ＢＳ１１２は、レガシーＬＴＥリソースブロック（Resource Block：ＲＢ）をスケジューリングすることができ、あるいは、ＮＲシナリオでは、次世代ノードＢ（Next-generation Node B：ｇＮＢ）が、ｅＭＢＢ送信のギャップの間にＵＲＬＬＣをスケジューリングすることができる。

ＤＬ構成制御メッセージを使用して、ＤＴＸスケジュールをＲＲＣ構成することができる。ＤＴＸスケジュールに従った、ＵＥ１０１から１０４のそれぞれにおける阻止は、例えばＤＣＩを用いて実装されたＤＬアクティブ化制御メッセージに従って、アクティブ化および非アクティブ化され得る。したがって、ＵＥ１０３、１０４のそれぞれは最初にＤＴＸスケジュールによってＲＲＣ構成することができるが、ＵＥ１０３、１０４のそれぞれは、ＤＬアクティブ化制御メッセージ４０２４によって示されない限り、このＤＴＸスケジュールを送信を阻止するために使用しない。図１５に示すように、このＤＬアクティブ化制御メッセージ４０２４は、例えばＵＬ／ＤＬ許可の形で、送信５９９１、５９９２の前に発生することができる。あるいは、図１６に示すように、ＤＬアクティブ化制御メッセージは、プリエンプション指示の形で、送信５９９１、５９９２中に発生することができる。

ＤＴＸスケジュールは、周波数および時間リソースのサブセット、または一般にＰＲＢに対してのみ構成できる。すなわち、ＵＥ１０３、１０４は、ＤＴＸの時間的有効性が切れるまで、特定の期間、ＤＴＸスケジュールに従って送信５９９１、５９９２の阻止をアクティブ化するだけである。これは、例えば、時間的有効範囲内にある対応するリソースのサブセットがＵＬ許可を要しない送信に使用される場合に、有益である。例えば、送信５９９５は、ＵＬ許可を要しない送信であり得る。３ＧＰＰ ＮＲでは、通常、ＵＲＬＬＣにはＵＬ許可を要しない送信が用いられる、ここでは、ＵＥ１０１、１０２は、ＢＳ１１２からＵＲＬＬＣがＵＬリソースを要求することなく到着したときは、いつでもＵＲＬＬＣを送信することができる。したがって、ＩｏＴ ＵＥ１０３、１０４のｅＭＢＢ送信５９９１、５９９２がこれらの許可を要しないリソースと部分的または全面的にオーバーラップする場合、ＩｏＴ ＵＥ１０３、１０４は、ＤＴＸスケジュールに従って送信を阻止することで、ＵＬ許可を要しない送信５９９５の共同スケジューリングを容易化することができる。

ＤＬ構成制御メッセージを使用して、複数のＤＴＸスケジュールを構成することができる。ＤＬ構成制御メッセージによって複数の候補ＤＴＸスケジュールに関する制御情報を示すことができる。各候補ＤＴＸスケジュールによって、異なる禁止ＰＲＢ６８０を定義することができる。そこで、複数の候補ＤＴＸスケジュールのうちの選択された１つをアクティブ化するために、ＤＬアクティブ化制御メッセージを送信することができる。ＤＬアクティブ化制御メッセージによって、候補ＤＴＸスケジュールのうちの選択された１つを示すことができ、選択された候補ＤＴＸスケジュールによって定義された１つ以上の禁止ＰＲＢ６８０上での送信の阻止をアクティブ化することができる。このアクティブ化は、送信の開始前または開始後に行うことができる。

原則として、ＤＴＸスケジュールは、図１５および１６に示す不規則なパターンではなく、均一にすることができる。阻止期間６８９は同じ長さにしてもよい。一定の周期性を採用してもよい。一例を図１７に示す。図中、阻止期間６８９はすべて同じサイズであり、固定周期性が採用されている。均一なＤＴＸパターンは、ＬＴＥ ＲＢやＵＲＬＬＣを既存の送信のギャップ内でスケジューリングするのに有益であり得る。

ＤＴＸスケジュールによって、全面的または部分的な阻止を定義することができる。したがって、図１８の例に示すように、送信５９９１、５９９２のすべてのＰＲＢが阻止期間６８０の間阻止され得るわけではない。ここで、禁止ＰＲＢ６８０は、ＤＴＸスケジュールの期間ごとに変化し得る。これは、ＰＤＳＣＨ／ＰＵＳＣＨ送信がＬＴＥのＲＢＧの一部とオーバーラップする場合、または、ｅＭＢＢのケースでは、許可を要しないリソース領域と部分的にオーバーラップする場合に有益である。

図１９は様々な例による方法のフローチャートである。例えば、図１９による方法は、ＢＳ１１２の制御回路１１２１、１１２５によって実行され得る。

ブロック７００１で、ＢＳと第１のＵＥとの間で第１の送信がスケジューリングされる。例えば、第１の送信をＩｏＴトラフィックに関連付けることができる。例えば、第１の送信は、ｅＭＢＢプロトコル、ＵＲＬＬＣプロトコルに従って実行されるか、複数の繰り返しを用いてＣＥを採用するか、またはそれら両方を行うことができる。

第１の送信のスケジューリングには、第１の送信のスケジューリング情報を送信することが含まれ得る。スケジューリング情報は、第１の送信に割り当てられた複数のＰＲＢを示すことができる。スケジューリング情報の通信、および、例えばＲＢＧを使用した、ＰＲＢの割り当てに関する詳細については、図４から６に関連して説明した。

例えば、スケジューリング情報によって、第１の送信にＰＲＢを割り当てるベースライン期間を定義することができる。スケジューリング情報によって、ＣＥを使用した送信の繰り返しのベースラインカウントを定義することができる。

次に、ブロック７００２で、第１の送信がパンクチャリングされる。上記パンクチャリングを実行するために利用可能な様々なオプションがある。１つの例では、第１の送信は、少なくとも１つの禁止ＰＲＢ上でパンクチャリングされる。その少なくとも１つの禁止ＰＲＢは、ブロック７００１で第１の送信をスケジューリングする際に第１の送信に割り当てられた複数のＰＲＢに含まれる。例えば、少なくとも１つのＰＲＢは、時間領域および周波数領域の少なくとも一方において、第１の送信に割り当てられた非禁止ＰＲＢに囲まれ得る。その少なくとも１つのＰＲＢによって、ＵＥが第１の送信を少なくとも部分的に阻止する阻止期間を定義することができる。したがって、その少なくとも１つの禁止ＰＲＢに対して、別の使い方をすることができる。その少なくとも１つの禁止ＰＲＢに依存することにより、その禁止ＰＲＢを含むスケジューリング情報をオーバーライドすることができる。

具体的には、ブロック７００３で、ＢＳと第２の端末の間の第２の送信が、その少なくとも１つの禁止ＰＲＢ上でスケジューリングされる。それにより、第２の送信は、時間領域および周波数領域の少なくとも一方において、第１の送信によって囲まれることができる。第１および第２の送信を、時間領域で交互に配置することができる。

少なくとも１つの禁止ＰＲＢを定義するために使用できる様々なオプションがある。例えば、パンクチャリングは、少なくとも１つの禁止ＰＲＢを定義するＤＴＸスケジュールに従うことができる。そのようなシナリオについては、図１３、１５から１８、２２に関連して説明した。制御情報に従って、少なくとも１つの禁止ＰＲＢを設定することができる。制御情報は、ＰＲＢグループと、キャリアのサブバンドおよびサブバンドの外側にあるキャリアの一部の両方とのオーバーラップに基づいて決定され得る。このようなシナリオでは、制御情報を示すＤＬ構成制御メッセージを明示的にシグナリングする必要はないかもしれない。他のシナリオでは、ＤＬ構成制御メッセージをシグナリングして、少なくとも１つの禁止ＰＲＢをＢＳとＵＥとの間で同期させることができるであろう。

パンクチャリングは、少なくとも１つの禁止ＰＲＢ上での送信の阻止のアクティブ化および阻止の非アクティブ化を含み得る。このために、ＤＬアクティブ化制御メッセージは、ＢＳによって送信されることができ、ＵＥによって受信されることができる。それにより、上記パンクチャリングは時間的制約を受ける可能性がある。ＤＬアクティブ化制御メッセージは、ＵＥにおける送信の阻止をアクティブ化および非アクティブ化することができる。

いくつかの例では、第１の送信と第２の送信とのオーバーラップを検出したことに応じて第１の送信のパンクチャリングがされてもよい。オーバーラップは、第１の送信と第２の送信の両方に割り当てられる少なくとも１つのＰＲＢまたはＰＲＥに対応したものかもしれない。これは、第１の送信の上記スケジューリングおよび第２の送信の上記スケジューリングの少なくとも一方に基づいて判断することできる。

図２０は様々な例による方法のフローチャートである。例えば、図２０の方法は、ＵＥ１０１から１０４の制御回路１０１１、１０１５によって実行され得る。

ブロック７０１１で、スケジューリング情報が受信される。よって、ブロック７０１１は、ブロック７００１と相互に関連している可能性がある。

スケジューリング情報は、複数のＰＲＢ上での送信のためのものであり得る。例えば、スケジューリング情報は、１つ以上のＲＢＧを使用することによって複数のＰＲＢを示すことができる。

ブロック７０１２では、スケジューリング情報に関連する複数のＰＲＢに含まれる少なくとも１つの禁止ＰＲＢ上で送信が阻止される。これは制御情報に基づいている。よって、ブロック７０１２は、ブロック７００２と相互に関連している可能性がある。

阻止されたＰＲＢを補償するために、ブロック７０１１で受信されるスケジューリング情報の対象となる複数のＰＲＢを超えて送信を拡張することができる。したがって、ベースライン期間を超えて、拡張期間を実装することができる。延長期間は、例えば、少なくとも１つの禁止ＰＲＢの数に基づいて決定することができる。

図２１は、ＢＳ１１２、ＩｏＴ ＵＥ１０３、および非ＩｏＴ ＵＥ１０１の間の通信を示すシグナリング図である。

５０５１で、ＤＬ構成制御メッセージ４０５１が、ＢＳ１１２によって送信され、ＵＥ１０３によって受信される。ＤＬ構成制御メッセージ４０５１は、少なくとも１つの禁止ＰＲＢ６８０に関する制御情報を示す。例えば、ＤＬ構成制御情報は少なくとも１つの禁止ＰＲＢを定義する１つ以上のＤＴＸスケジュールを示すことができる。例えば、ＤＬ構成制御メッセージ４０５１は、第３層のＲＲＣ制御メッセージであり得る。

ＤＬ構成制御メッセージ４０５１は、一般的にはオプションである。他のシナリオでは、少なくとも１つの禁止ＰＲＢ６８０は、ＩｏＴ ＵＥ１０３およびＢＳ１１２により、例えば、スケジューリング用のサブバンドおよびＲＢＧを含むセル構成から自律的に導出されてもよい（図７参照）。

次に、ブロック５０５２で、スケジューリング情報４００１がＢＳ１１２からＵＥ１０３に通信される。ＢＳ１１２は５０５２でスケジューリング情報４００１を送信し、ＵＥ１０３は５０５２でスケジューリング情報４００１を受信する。スケジューリング情報４００１は、ＩｏＴ ＵＥ１０３とＢＳ１１２の間のＵＬ送信５９９２のためのものである。よって、スケジューリング情報４００１は、例えば、１つ以上のＰＲＢグループを用いて、複数のＰＲＢを示す。複数のＰＲＢは、ＵＬ送信５９９２に割り当てられる。

５０５３で、ＤＬアクティブ化制御メッセージ５０５２がＢＳ１１２からＩｏＴ ＵＥ１０３に通信される。ＤＬアクティブ化制御メッセージ５０５２によって、少なくとも１つの禁止ＰＲＢ６８０におけるＵＬ送信５９９２の阻止がアクティブ化される。ＤＬ構成制御メッセージ４０５１が複数の候補ＤＴＸスケジュールを示すいくつかの例では、ＤＬアクティブ化制御メッセージ４０５２は、複数の候補ＤＴＸスケジュールのうちの選択された１つを示し得るであろう。

図２１のシナリオでは、ＤＬアクティブ化制御メッセージ５０５２は、５０５３で、すなわち、５０５５でＵＬ送信５９９２を開始する前に通信される。他のシナリオでは、ＤＬアクティブ化制御メッセージ５０５２が、ＵＬ送信５９９２が５０５５で開始された後に通信されることも可能であろう。

次に、５０５４で、スケジューリング情報４００１が、ＢＳ１１２から非ＩｏＴ ＵＥ１０１に通信される。スケジューリング情報４００１は、ＢＳ１１２からＵＥ１０１への送信５９９５のためのものである。

送信５９９２は、阻止期間６８９の間にＢＳ１１２でパンクチャリングされる。ＵＬ送信５９９２をパンクチャリングするとき、ＢＳ１１２は、それぞれの禁止ＰＲＢ６８０を使用して、５０５６および５０５８でデータ４００２を送信することにより、ＤＬ送信５９９５を実行できる。これにより、図２１に示すように、送信５９９２および送信５９９５は、時間領域で交互配置される。

阻止期間６８９内に、ＵＥ１０３は、禁止ＰＲＢ６８０上でＵＬ送信５９９２を阻止する（図２１の例では、簡略化のため、ＵＬ送信５９９２の完全な阻止が示されているが、一般に、例えば、図７に示すように、ＵＬ送信５９９２を部分的に阻止することは可能であろう）。

図２１に示すように、ＵＬ送信５９９２は、データ４００２の複数の繰り返しを含む。複数の繰り返しは、それぞれ、５０５５、５０５７、５０５９、および５０６１で通信される。例えば、データ４００２の各繰り返しは、同じ冗長バージョンに従って符号化されたデータに対応し得る。そこで、ＢＳ １１２は、ＣＥを達成するために、受信したそれぞれの繰り返しをアナログ領域で組み合わせることができる。したがって、ＢＳ１１２の受信バッファは、送信５９９２が完了するまで維持されなければならない。図２１に示すように、いくつかの繰り返しは、阻止期間６８９の前に配置され、他の繰り返しは、阻止期間６８９の後に配置される。

原則として、すべてのシナリオにおいて、パンクチャリングおよび阻止された送信は、複数の繰り返しを含む必要はない。ｅＭＢＢやＵＲＬＬＣなどの、他の長期の送信も、このような手法の恩恵を受けることができる。

５０６０で、阻止のアクティブ化をもたらすさらなるＤＬアクティブ化制御メッセージが、ＢＳ１１２からＩｏＴ ＵＥ１０３に通信される。５０６０でＤＬアクティブ化制御メッセージ４０５２を受信したことに応じて、ＵＥ１０３は、ＵＬ送信５９９２の阻止を停止する。

阻止期間６８９の間の阻止を補償するために、ＵＬ送信５９９２の拡張数だけの繰り返しが、延長期間６８６の間に実行される。例えば、阻止期間６８９中の禁止ＰＲＢ６８０の数に基づいて、繰り返しの拡張数を、例えば、通常、ＩｏＴ ＵＥ１０３とＢＳ１１２の間の通信の信号品質の考慮の下でＣＥポリシーのＣＥレベルによって定義された繰り返しのベースラインカウントを超えて、決定することができる。

図２２は、少なくとも１つの禁止リソースブロック上で第１の送信５９９１、５９９２をパンクチャリングすること、およびそのパンクチャリングに従って第２の送信５９９５をスケジューリングすることに関する態様を模式的に示す。送信５９９１、５９９２は、ＵＬ送信またはＤＬ送信であり得る。送信５９９５は、ＵＬまたはＤＬ送信であり得る。図２２のシナリオでは、簡略化のため、送信５９９５はＵＬ送信であると想定している。

図２２は、送信５９９５が、ＵＬ許可を要しないリソースを使用して送信されるＵＲＬＬＣを含む実施例である。例えば、それぞれのスケジューリング情報４００１は、ＢＳ１１２から１つ以上のＵＥ１０１、１０２に通信される。スケジューリング情報４００１は、送信５９９５に割り当てられる既知のＰＲＥのブロックを示すことができる。

ＵＬ送信５９９５のこれらのＰＲＥは、単一のＵＥにだけ割り当てられるものではないかもしれない。すなわち、これらのＰＲＥは専用リソースではないかもしれない。むしろ、複数のＵＥがＰＲＥにアクセスして、スペクトルの利用を向上させることができる。個々のＵＥを明示的に許可する必要はない。これによって、ＵＥ１０１、１０２は、特定のスケジューリング要求なしに、許可を要しないリソース上でＵＬデータを送信することができ、レイテンシが短縮される。

送信５９９１、５９９２にはｅＭＢＢが含まれる。このような送信は、通常、許可に基づくものである。すなわち、ネットワークによって個々にスケジューリングされる。

送信５９９１、５９９２が送信５９９５の許可を要しないリソース（図２２参照）の一部とオーバーラップする場合、ＵＲＬＬＣデータが送信５９９５の許可を要しないリソース中で送信されるなら、送信５９９１、５９９２のｅＭＢＢデータの干渉を受ける可能性がある（図２２に点線を用いてオーバーラップ５９９９を示す）。

ＵＲＬＬＣデータがいつ送信５９９５の許可を要しないＰＲＥ中で送信されるかについて、ＢＳ１１２は、事前に知っていないかもしれない。そこで、ＤＴＸスケジュールを用いてｅＭＢＢ送信５９９１、５９９２を実行することによって（図２２参照）、通常、信頼性のために繰り返される送信５９９５のＵＲＬＬＣデータの少なくとも一部は、ＤＴＸギャップ、すなわち、阻止期間６８９および１つ以上の禁止ＰＲＢ６８０と重なるときに、干渉を受けないであろう。ＤＴＸスケジュールのオン期間と重なる送信５９９５のＵＲＬＬＣデータの場合、送信５９９１、５９９２のｅＭＢＢデータとの衝突が発生する可能性がある。平均して、このような送信５９９１、５９９２のパンクチャリングによって、許可を要しない送信５９９５におけるＵＲＬＬＣデータの干渉が低減する。

図２２において、送信５９９１、５９９２は、時刻ｔ０にスケジューリング情報を使用してスケジューリングされる。例えば、送信５９９１、５９９２は、ＵＥ１０１とＢＳ１１２の間であり得る。

送信５９９１、５９９２は、送信５９９５のＵＬ許可を要しないリソースのセットと部分的にオーバーラップする（割り当てられたリソースを破線を用いて示す）。

送信５９９５のＵＬ許可を要しないリソースは、時間間隔ｔ１からｔ４において割り当てられるが、時刻ｔ３でのみ、ＵＥ１０３は、これらの許可を要しないリソースを使用してＵＲＬＬＣデータ（図２２の黒く塗りつぶされた領域）を送信することを決定する。ＵＲＬＬＣデータの複数の繰り返しが時刻ｔ５まで実行される。

ＤＬアクティブ化制御メッセージ４０２４は、送信５９９１、５９９２のためのＤＴＸスケジュールを、例えば、ＤＣＩにおいて、アクティブ化する。ＤＬアクティブ化制御メッセージ４０２４はオプションである。一般に、ＵＥ１０１は、ＤＴＸスケジュールによって静的に構成され得る。

いくつかの例では、１つ以上の禁止ＰＲＢのそれぞれは、それぞれの制御情報を提供することによって、ＵＥ１０１において固定的に構成され得る。

ＤＴＸスケジュールによって、ＵＲＬＬＣデータのすべての繰り返しが送信５９９１、５９９２によって干渉されることはなくなる。いくつかの実施形態では、送信５９９５と送信５９９１、５９９２の間のオーバーラップ５９９９が検出された場合のみ、ＤＴＸスケジュールがアクティブ化される。

要約すると、１つ以上の禁止された／無効なＰＲＢを示す、例えば、ＤＬ制御シグナリングを使用して示される制御情報に依存する技術を説明してきた。例えば、ＭＴＣ送信は、それによって、１つ以上の禁止ＰＲＢに従って、少なくとも部分的に阻止され得る。すると、ＬＴＥ、または、一般に、非ＩｏＴ ＵＥが、１つ以上の禁止ＰＲＢ上でスケジューリングされ得る。１つ以上の禁止ＰＲＢを示すためにＲＢＧを使用することができる。

いくつかの態様によれば、１つ以上の禁止ＰＲＢの補償は、ＭＴＣ送信のためのＣＥ技術の追加的繰り返しを定義することによって達成することができる。これらの追加的繰り返しは、ベースライン繰り返し数に追加され得る。そのような追加的繰り返しの拡張数は、ＤＬ制御シグナリングを用いて、例えば、本明細書の様々なシナリオに関連して説明されたようなＤＬ構成制御メッセージまたはＤＬアクティブ化制御メッセージを使用して、ＵＥにシグナリングされ得る。

いくつかの態様によれば、阻止の対象となる送信に対する終了および再開指示が説明される。送信ギャップが生じ、１つ以上のさらなるＵＥをスケジューリングするために使用され得る。

本発明を特定の好適な実施形態に関して示しかつ説明してきたが、本明細書を読んで理解すれば、当業者には等価物および修正が想起されるであろう。本発明は、そのような等価物および修正のすべてを含み、添付された特許請求の範囲によってのみ制限される。

例示のために、上記の様々な例を、ＣＥ技術を使用するｅＭＴＣにおけるＰＵＳＣＨ上のデータの複数の繰り返しに関して説明してきたが、これは、ＰＤＳＣＨにも適用可能である。一般に、ＵＬについて説明した様々な例はＤＬにも適用可能であり、その逆も可能である。

また、このような技術は、期間の異なる２つ以上の送信がリソースを部分的または全面的に共有する必要がある任意の他のシステムにおいても、簡単に適用できる。例えばＮＲの場合、いかなるレイテンシも許容しない信頼性の非常に高い通信が要求される超高信頼性低遅延通信（ＵＲＬＬＣ）などの短い送信が、２０Ｇｂｐｓのスループットが期待される拡張モバイルブロードバンド（ｅＭＢＢ）などの長い送信よりも優先される。

さらなる例示のために、上記では、ＩｏＴ ＵＥが１つ以上の禁止ＰＲＢ上での送信の阻止を採用するシナリオに関して様々な例を説明してきた。一方、そのような技術は、１つ以上の禁止ＰＲＢの送信を阻止するように構成することもできる非ＩｏＴ ＵＥに簡単に適用可能である。

Claims (32)

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. 前記制御回路（１１２１、１１２５）は、請求項２０〜３０のいずれか１項に記載の方法を実行するようにさらに構成された、請求項３０に記載のアクセスノード（１１２）。

Images