JP7264230B2 - 通信システム - Google Patents

Description

本発明は、移動通信デバイス及びネットワークに関する。特に、本発明は、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）規格、又はこれと同等若しくは派生の規格に従って動作する移動通信デバイス及びネットワークに関するが、これに限定されない。特に、本発明は、いわゆる「５Ｇ」（又は「次世代」）システムにおける多重データトラフィックに関するが、これに限定されない。

３ＧＰＰ規格の最新動向は、「ＥＰＣ（Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）ネットワーク及びＥ－ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ：進化型ＵＭＴＳ地上無線アクセスネットワーク）のＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）」と呼ばれ、一般に「４Ｇ」とも呼ばれる。更に、「５Ｇ」及び「ＮＲ（Ｎｅｗ Ｒａｄｉｏ）」といった語は、ＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：マシン型通信）、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ：モノのインターネット）通信、車両通信、自律走行車、高解像度ビデオストリーミング、スマートシティサービスなどの様々なアプリケーション及びサービスをサポートすることが期待される進化型の通信技術を指す。したがって、５Ｇ技術は、バーティカル市場へのネットワークアクセスを可能にし、サードパーティにネットワークサービスを提供し、新しいビジネスチャンスを創出するためのネットワーク（ＲＡＮ）共有をサポートすることが期待されている。３ＧＰＰは、いわゆる３ＧＰＰ ＮｅｘｔＧｅｎ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ）ＲＡＮ及び３ＧＰＰ ＮＧＣ（ＮｅｘｔＧｅｎ Ｃｏｒｅ：次世代コア）ネットワークによって５Ｇをサポートすることを計画している。５Ｇネットワーク及びネットワークスライシングの種々の詳細は、例えば、ＮＧＭＮ（Ｎｅｘｔ Ｇｅｎｅｒａｔｉｏｎ Ｍｏｂｉｌｅ Ｎｅｔｗｏｒｋｓ）アライアンスによるＮＧＭＮ ５Ｇ Ｗｈｉｔｅ Ｐａｐｅｒ Ｖ１．０に説明されており、当該文書は、ｈｔｔｐｓ：／／ｗｗｗ．ｎｇｍｎ．ｏｒｇ／５ｇ－ｗｈｉｔｅ－ｐａｐｅｒ．ｈｔｍｌから入手可能である。

次世代のモバイル通信ネットワークは、ＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ：国際電気通信連合）によって以下の３カテゴリに分類される多様なサービス要件をサポートする必要がある：ｅＭＢＢ（ｅｎｈａｎｃｅｄ Ｍｏｂｉｌｅ ＢｒｏａｄＢａｎｄ）、ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ－Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、及びｍＭＴＣ（ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）。ｅＭＢＢは、ＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ：高解像度）ビデオ、ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ：仮想現実）、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ：拡張現実）など、広い保証帯域幅を必要とするサービスにフォーカスしたＭＢＢに対する拡張サポートを提供することを目的とする。ＵＲＬＬＣは、自動運転やファクトリーオートメーションなど、非常に短い時間内でアクセスを保証する必要のある重要なアプリケーションの要件である。ｍＭＴＣは、スマートメータリングや環境モニタリングなど、接続された多数のデバイスをサポートする必要があるが、通常は一定のアクセス遅延を許容することができる。これらのアプリケーションのうちのいくつかは、比較的緩いＱｏＳ／ＱｏＥ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ／Ｑｕａｌｉｔｙ ｏｆ Ｅｘｐｅｒｉｅｎｃｅ）要件を有してもよい。一方で、一部のアプリケーションは、比較的厳しいＱｏＳ／ＱｏＥ要件（例えば、高帯域幅や低遅延など）を有してもよい。

現在、３ＧＰＰでは、ＮＲネットワークで様々な種類のＵＲＬＬＣ通信をサポートし、アップリンク（ＵＬ：ＵｐＬｉｎｋ）で異なるＵＥからのｅＭＢＢ及びＵＲＬＬＣサービスを含むｅＭＢＢ及びＵＲＬＬＣサービス間における動的リソース共有をサポートするための物理レイヤの拡張を検討中である。しかしながら、異なるＵＥが関与する場合にそのような動的リソース共有を実装する方法については、まだ決定がされていない。

提案のあった１つのオプションでは、ｅＭＢＢ ＵＥは、（ネットワークからの）指示を検出した場合、そのＵＬ送信をキャンセルする。別提案のオプションでは、ＵＬ電力制御を使用する。すなわち、ＵＲＬＬＣ ＵＥが、ｅＭＢＢ ＵＥ送信と同一のリソースで、ＵＲＬＬＣ ＵＬの送信電力をブーストした及び／又はｅＭＢＢＵＬの送信電力を削減した送信電力によって、送信を行う。更に、（異なるＵＥからの）ｅＭＢＢ及びＵＲＬＬＣサービスを多重化する場合、これらの異なるｅＭＢＢ／ＵＲＬＬＣサービスに対応するレイテンシ及び信頼性要件が大幅に異なることも考慮に入れる必要がある。

本発明は、上記の問題に対処する、又は少なくとも軽減する方法及び関連する装置を提供するものである。

当業者の理解の効率化のために、本発明は３ＧＰＰシステム（５Ｇネットワーク）のコンテキストを想定して詳細に説明するが、本発明の原理はスライススケジューリングを行う他のシステムにも適用することができる。

本発明の例示的な態様によれば、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）により実行される方法であって、前記ＵＥに割り当てられた通信リソースのセット内の少なくとも１つの通信リソースであって、プリエンプト可能な前記少なくとも１つの通信リソースを識別する情報を受信することと、前記少なくとも１つの通信リソースの少なくとも一部が、ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ－Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性及び低遅延通信）通信用にプリエンプトされることを示す制御データを受信することと、前記受信した制御データに基づいて、前記識別された少なくとも１つの通信リソースをプリエンプトすることと、を備える方法、が提供される。

本発明の例示的な態様によれば、ネットワーク装置により実行される方法であって、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）に割り当てられた通信リソースのセット内の少なくとも１つの通信リソースであって、プリエンプト可能な前記少なくとも１つの通信リソースを識別する情報を前記ＵＥに送信することと、前記少なくとも１つの通信リソースの少なくとも一部が、ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ－Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性及び低遅延通信）通信用にプリエンプトされることを示す制御データを前記ＵＥに送信することと、を備える方法、が提供される。

本発明の例示的な態様によれば、ネットワーク装置により実行される方法であって、隣接するネットワーク装置から、前記隣接するネットワーク装置のセル内におけるＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ－Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性及び低遅延通信）通信の設定を識別する情報を取得することと、前記取得した情報に基づいて、前記ネットワーク装置のセル内におけるＵＲＬＬＣ通信用の通信リソースの割り当てを決定することと、を備える方法、が提供される。

本発明の例示的な態様によれば、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）により実行される方法であって、ＵＲＬＬＣ（Ｕｌｔｒａ－Ｒｅｌｉａｂｌｅ ａｎｄ Ｌｏｗ－Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ：超信頼性及び低遅延通信）データの要求を、前記ＵＥにサーブするネットワーク装置に送信することと、異なるＵＥに割り当てられて通信リソースのセットの内の少なくとも１つの通信リソースの割り当てを受信することと、
前記少なくとも１つの通信リソースが前記異なるＵＥによってプリエンプトされる一方で、前記ＵＲＬＬＣデータの少なくとも一部を前記少なくとも１つの通信リソースの割り当てを使用して送信することと、と備える方法、が提供される。

本発明の例示的な態様は、対応するシステムと、装置と、プログラム可能なプロセッサをプログラミングして上記例示的な態様に記載の方法及び特許請求の範囲に記載の可能性を実施させる、及び／又は好適に適合したコンピュータをプログラミングして任意の請求項に記載の装置を提供させるように動作可能な命令を格納する、コンピュータ読取可能な記憶媒体などのコンピュータプログラム製品と、に及ぶ。

本明細書（特許請求の範囲を含む）に開示する及び／又は図面に示す各特徴は、開示する及び／又は図示する他の特徴とは独立して（又は組み合わせて）本発明に組み込んでもよい。特に、特定の独立請求項に従属する請求項に記載の特徴は、任意に組み合わせて又は個別に当該独立請求項に導入することができるが、これは限定的ではない。

ここで、添付図面を参照して、本発明の例示的な実施形態の例を説明する。
図１は、本発明の例示的な実施形態を適用可能なモバイル（セルラ又は無線）通信システムを概略的に示す図である。 図２は、図１に示すシステムの一部を形成するモバイルデバイスの概略ブロック図である。 図３は、図１に示すシステムの一部を形成するアクセスネットワークノード（例えば、基地局）の概略ブロック図である。 図４は、図１に示すシステムの一部を形成するコアネットワークノードの概略ブロック図である。 図５は、本発明の例示的な実施形態に係る２つの例示的な手順を概略的に示す図である。 図６は、本発明の例示的な実施形態に係る２つの例示的な手順を概略的に示す図である。

（概要）
３ＧＰＰ規格では、ＮｏｄｅＢ（又はＬＴＥにおける「ｅＮＢ」、５Ｇにおける「ｇＮＢ」など）は、通信デバイス（ユーザ装置又は「ＵＥ」）がコアネットワークに接続し、他の通信デバイス又はリモートサーバと通信を行うための基地局である。通信デバイスには、例えば、モバイル電話、スマートフォン、スマートウォッチ、パーソナルデジタルアシスタント、ラップトップ／タブレットコンピュータ、ウェブブラウザ、電子書籍リーダなどのモバイル通信デバイスが含まれる。通常、このようなモバイル（又は一般的に固定の）デバイスはユーザによって操作される（したがって、これらのデバイスは総称的にユーザ装置「ＵＥ」と呼ばれることが多い）が、ＩｏＴデバイスや同様のＭＴＣデバイスをネットワークに接続することも可能である。説明の簡略化のため、本願では、基地局という語はそのような任意の基地局を指し、モバイルデバイス又はＵＥという語はそのような任意の通信デバイスを指すものとする。

図１は、本発明の例示的な実施形態を適用可能なモバイル（セルラ又は無線）通信システム１を概略的に示す図である。

このネットワークにおいて、各モバイルデバイス３（ＵＥ）のユーザは、例えばＥ－ＵＴＲＡ及び／又は５Ｇ ＲＡＴなどの適切な３ＧＰＰ ＲＡＴ（Ｒａｄｉｏ Ａｃｃｅｓｓ Ｔｅｃｈｎｏｌｏｇｙ：無線アクセス技術）を使用して、それぞれ基地局５及び／又はコアネットワーク７を介して、相互に及び他のユーザと通信を行うことができる。複数の基地局５が（無線）アクセスネットワーク又は（Ｒ）ＡＮを形成してもよいものとする。当業者には明らかではあるが、図１が２つのモバイルデバイス３Ａおよび３Ｂと１つの基地局５とを例示目的で示す一方で、システムの実装時には、通常、他の基地局及びモバイルデバイス（ＵＥ）も含まれる。

各基地局５は（直接、又はホーム基地局、リレー、リモートラジオヘッド、分散ユニットなどの他のノードを介して）、１つ以上の関連セルを制御する。Ｅ－ＵＴＲＡ／４Ｇプロトコルをサポートする基地局５は「ｅＮＢ」と呼ばれてもよく、次世代／５Ｇプロトコルをサポートする基地局５は「ｇＮＢ」と呼ばれてもよい。いくつかの基地局５は、４Ｇ及び５Ｇプロトコルの両方、及び／又は他の任意の３ＧＰＰ又は非３ＧＰＰ通信プロトコルをサポートするように構成してもよい。

モバイルデバイス３及びそのサービング基地局５は、適切なエアインターフェース（例えば、いわゆる「Ｕｕ」インターフェースなど）を介して接続される。隣接する基地局５同士は、適切な基地局間インターフェース（いわゆる「Ｘ２」インターフェース、「Ｘｎ」インターフェースなど）を介して相互に接続されている。基地局５は、適切なインターフェース（いわゆる「Ｓ１」、「Ｎ１」、「Ｎ２」、「Ｎ３」インターフェースなど）を介して、コアネットワークノードに接続される。

コアネットワーク７（例えば、ＬＴＥの場合にはＥＰＣで、ＮＲ／５Ｇの場合にはＮＧＣ）は、通常、通信システム１において通信をサポートするため、及び加入者管理、モビリティ管理、課金、セキュリティ、及び呼セッション管理（など）のための論理ノード（又は「機能」）を含む。例えば、「次世代」／５Ｇシステムのコアネットワーク７は、ユーザプレーンエンティティと制御プレーンエンティティとを含む。この例では、コアネットワーク７は、少なくとも１つのＣＰＦ（Ｃｏｎｔｒｏｌ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ：制御プレーン機能）１０と、少なくとも１つのＵＰＦ（Ｕｓｅｒ Ｐｌａｎｅ Ｆｕｎｃｔｉｏｎ：ユーザプレーン機能）１１とを含む。また、コアネットワーク７は、ＡＭＦ（Ａｃｃｅｓｓ ａｎｄ Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ：アクセス／モビリティ管理機能）、ＳＭＦ（Ｓｅｓｓｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｆｕｎｃｔｉｏｎ：セッション管理機能）、ＰＣＦ（Ｐｏｌｉｃｙ Ｃｏｎｔｒｏｌ Ｆｕｎｃｔｉｏｎ：ポリシー制御機能）、ＡＦ（Ａｐｐｌｉｃａｔｉｏｎ Ｆｕｎｃｔｉｏｎ：アプリケーション機能）、ＡＵＳＦ（ＡＵｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ Ｆｕｎｃｔｉｏｎ：認証サーバー機能）、ＵＤＭ（Ｕｎｉｆｉｅｄ Ｄａｔａ Ｍａｎａｇｅｍｅｎｔ：統合データ管理）エンティティ１７などのうちの１つ以上を含むものとする。また、コアネットワーク７は、インターネット又は同様のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ：インターネットプロトコル）ベースのネットワーク（図１に「外部ネットワーク」として図示）などのＤＮ（Ｄａｔａ Ｎｅｔｗｏｒｋ：データネットワーク）２０に（ＵＰＦ１１を介して）結合されている。

このネットワークで、モバイルデバイス３は、動的に割り当てられた通信リソース（関連するダウンリンク制御データ（ＤＣＩ）に基づく）を使用して、又は、いわゆる「グラントフリー」通信リソース（「設定済みグラント」とも呼ばれる）を使用して、アップリンクデータを通信することができる。

グラントフリー送信には以下の２種類がある：
設定済みグラントタイプ１：ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ：無線リソース制御）シグナリングによってアップリンクグラントが提供され、設定済みアップリンクグラントとして保存される；及び
設定済みグラントタイプ２：物理ダウンリンク制御チャネル（ＰＤＣＣＨ）によってアップリンクグラントが提供され、設定済みグラントのアクティブ化又は非アクティブ化を指示するＬ１シグナリングに応じて、設定済みアップリンクグラントとして保存又はクリアされる。

ＵＲＬＬＣのレイテンシ要件を満たすために、グラントフリー送信用のリソースは、ＵＲＬＬＣ ＵＥ（ＵＲＬＬＣサービスに関与するモバイルデバイス３）に事前に割り当て、ＵＲＬＬＣパケットが到着する際に常に対応のレイテンシを保証するのに十分な密度である必要がある。

各モバイルデバイス３は、上で定義したカテゴリ（ＵＲＬＬＣ／ｅＭＢＢ／ｍＭＴＣ）の１つに各々分類される１つ以上のサービスをサポートすることができる。各サービスには、通常、対応する要件（例えば、レイテンシ／データレート／パケット損失などの要件）があり、これらはサービスごとに異なることもある。

この例では、第１のモバイルデバイス３ＡはｅＭＢＢサービスに関与し、第２のモバイルデバイス３ＢはＵＲＬＬＣサービスに関与する（適切であれば、各モバイルデバイスは他のサービスにも関与することがある）。したがって、第１のモバイルデバイス３Ａは、「ｅＭＢＢ ＵＥ」と呼ぶこともでき、第２のモバイルデバイス３Ｂは、「ＵＲＬＬＣ ＵＥ」と呼んでもよい。ｅＭＢＢサービスのデータパケットは、動的スケジューリング及び／又は事前に割り当てられた通信リソース（例えば、セミパーシステントスケジューリング／設定済みグラント）を使用して送信してもよい。

このシステムでは、第１の（ｅＭＢＢデータを送信している）モバイルデバイス３Ａは、（各スロットの）１つ又は２つの４シンボルのミニスロットでプリエンプト可能（ｐｒｅ－ｅｍｐｔａｂｌｅ）なリソースのセットを事前に設定されている。この例では、プリエンプト可能なリソースのセットは、ミニスロットごとに４シンボルを含む（他の例では、異なる数のプリエンプト可能なリソースを使用することもあり、例えば、少なくとも１つのプリエンプト可能なリソースを使用する）。

第１のシナリオでは、基地局５（アクセスネットワークノード）は、ｅＭＢＢデータを送信するモバイルデバイス３Ａに（例えば、ＵＥ固有のスケジューリングＤＣＩを介して）適切なプリエンプション指示（ｐｒｅ－ｅｍｐｔｉｏｎ ｉｎｄｉｃａｔｉｏｎ）を送信して、第１のモバイルデバイス３Ａ（ｅＭＢＢ ＵＥ）に過去に割り当てられた通信リソースに別のモバイルデバイス３ＢによるＵＲＬＬＣデータを多重することを可能にするように、構成される。当該指示は、例えば、「ＵＬ ＵＲＬＬＣプリエンプション指示」である。

第１のモバイルデバイス３Ａ（ｅＭＢＢ ＵＥ）は、基地局５からの指示を受信すると、当該指示を受信したプリエンプト可能なリソース（少なくとも現在のスロットにおける「期間１」、「期間２」、又はその両方）での送信を中断する。有益なことに、モバイルデバイス３Ａは、別のモバイルデバイス３Ｂ（ＵＲＬＬＣ ＵＥ）用にプリエンプトされた（ｐｒｅ－ｅｍｐｔｅｄ）リソース周辺におけるモバイルデバイス３Ａのアップリンク送信をレートマッチングするように構成される。第１のモバイルデバイス３ＡによるｅＭＢＢ送信は（プリエンプトされていない通信リソースを使用して）継続され、ＵＲＬＬＣリソースの比率はｅＭＢＢの広帯域送信と比較して小さい（例えば、１つのリソースブロックのみ又は少数のリソースブロックである）ため、ｅＭＢＢ送信に関連するパラメータ（例えば、符号化レートとＭＣＳ／ＴＢＳ）を変更する必要はない（ｅＭＢＢ通信の再構成が他のＵＥのプリエンプションに有益であると基地局５が判断しない限り必要ない）。

有益なことに、ＵＬプリエンプション指示のペイロードサイズは小さく保つことができるため、事前に設定されたプリエンプト可能なリソースのプリエンプションを、１ビット又は２ビットの指示を使用してアクティブ化することができる。

別のシナリオでは、基地局５は、適切なプリエンプション指示を（例えば、ＵＥ固有のスケジューリングＤＣＩを介して）モバイルデバイス３Ａに送信するように構成される。当該指示には、１つ以上の事前に設定されたプリエンプト可能なリソースを識別する情報と、（オプションで）当該プリエンプションに必要な期間（例えば、ミリ秒／スロット数で定義される期間）を識別する情報と、が含まれる。

更に別のシナリオでは、隣接する基地局５同士は、当該基地局５がサーブするモバイルデバイス３用にそれぞれ設定されたプリエンプト可能なリソースに関する情報を相互に交換するように構成することもできる。これにより、基地局５は、他のセルで（プリエンプトされるリソースと同時に）送信を行うＵＥによって引き起こされる干渉を低減することができる。当該情報（ＵＲＬＬＣ送信に影響を与える発生中の干渉の情報を含む）は、Ｘ２（又はＸｎ）インターフェースを使用して基地局５間で交換することができる。

（ＵＥ（ユーザ装置））
図２は、図１に示すモバイルデバイス（ＵＥ）３の主要構成要素を示すブロック図である。図示のように、ＵＥ３は、１つ以上のアンテナ３３を介して接続ノードと信号の送受信を行うように動作可能なトランシーバ回路３１を含む。図２には示されていないが、ＵＥ３が通常のモバイルデバイスの標準的な機能（ユーザインターフェース３５など）をすべて備えることは明らかである。これは、ハードウェア、ソフトウェア及びファームウェアの何れか１つ又はこれらの任意の組み合わせによって適宜実現可能である。コントローラ３７は、メモリ３９に記憶されたソフトウェアに従ってＵＥ３の動作を制御する。ソフトウェアは、メモリ３９に事前にインストールしてもよいし、例えば、通信ネットワーク１を介して、又はＲＭＤ（Ｒｅｍｏｖａｂｌｅ Ｄａｔａ Ｓｔｏｒａｇｅ Ｄｅｖｉｃｅ：リムーバブルデータ格納デバイス）からダウンロードしてもよい。ソフトウェアは、特に、オペレーティングシステム４１、通信制御モジュール４３、及びプリエンプションモジュール４５を含む。

通信制御モジュール４３は、ＵＥ３と、（Ｒ）ＡＮノード５、コアネットワークノードなどの他のノードとの間におけるシグナリングメッセージ及びアップリンク／ダウンリンクデータパケットのハンドリング（生成／送信／受信）を担う。当該シグナリングは、上述のＤＲＢマッピングに関するシグナリングを含んでもよい。

プリエンプションモジュール４５は、上述のプリエンプション指示手順を実行することを担う（例えば、ネットワークから適切なプリエンプション指示を受信／検出する、及び／又はプリエンプション指示に関連付けられた通信リソースを使用して、モバイルデバイス３によるアップリンク送信（例えば、ＵＲＬＬＣ／ｅＭＢＢ）を制御する）。

（アクセスネットワークノード（基地局））
図３は、図１に示す基地局５（又は同様のアクセスネットワークノード）の主要構成要素を示すブロック図である。図示のように、基地局５は、１つ以上のアンテナ５３を介して接続ＵＥ３と信号の送受信を行い、ネットワークインターフェース５５を介して他のネットワークノードと（直接的又は間接的に）信号の送受信を行うように動作可能なトランシーバ回路５１を含む。ネットワークインターフェース５５は、通常、適切な基地局間インターフェース（Ｘ２／Ｘｎなど）及び適切な基地局－コアネットワーク間インターフェース（Ｓ１／Ｎ１／Ｎ２／Ｎ３など）を含む。コントローラ５７は、メモリ５９に記憶されたソフトウェアに従って基地局５の動作を制御する。上記ソフトウェアは、メモリ５９に事前にインストールしてもよいし、例えば、通信ネットワーク１を介して、又はＲＭＤから、ダウンロードしてもよい。ソフトウェアは、特に、オペレーティングシステム６１、通信制御モジュール６３、及びプリエンプションモジュール６５を含む。

通信制御モジュール６３は、基地局５と、ＵＥ３やコアネットワークノードなど他のノードとの間におけるシグナリングのハンドリング（生成／送信／受信）を担う。

プリエンプションモジュール６５は、上記のプリエンプション指示手順を実行することを担う（例えば、プリエンプション指示に応じてモバイルデバイス３によるアップリンク送信を制御するために、適切なプリエンプション指示を適切なモバイルデバイス３に提供／送信する）。

（コアネットワーク機能）
図４は、図１に示すＵＰＦ１１やＡＭＦ１２などの一般的なコアネットワーク機能の主要構成要素を示すブロック図である。図示のように、コアネットワークノード機能は、ネットワークインターフェース７５を介して他のノード（ＵＥ３、基地局５及び他のコアネットワークノードを含む）と信号の送受信を行うように動作可能なトランシーバ回路７１を含む。コントローラ７７は、メモリ７９に記憶されたソフトウェアに従ってコアネットワーク機能の動作を制御する。当該ソフトウェアは、メモリ７９に事前にインストールしてもよいし、例えば、通信ネットワーク１を介して、又はＲＭＤから、ダウンロードしてもよい。当該ソフトウェアは、特に、オペレーティングシステム８１、通信制御モジュール８３、及びＱｏＳモジュール８５を含む。

通信制御モジュール８３は、コアネットワーク機能と、ＵＥ３、基地局５、他のコアネットワークノードなどの他のノードとの間におけるシグナリングのハンドリング（生成／送信／受信）を担う。当該シグナリングは、上述のＤＲＢマッピングに関するシグナリングを含んでもよい。

（詳細な説明）
図５及び６を参照して、いくつかの例示的な実施形態をより詳細に説明する。

（ＵＬプリエンプション指示（第１の例示的な実施形態））
ＵＲＬＬＣは、通常、１ミリ秒のレイテンシと、ＵＲＬＬＣトラフィックの非常に高い信頼性要件とのために、（ｅＭＢＢなどよりも）高い送信優先度（３ＧＰＰによる現在の設計目標）を有する。本発明者らは、ＵＲＬＬＣトラフィックを（異なるＵＥの）ｅＭＢＢトラフィックと多重化することで、散発的に発生又は定期的に発生するＵＲＬＬＣトラフィックの両方に対して、より優れたスペクトルリソース利用率及び容量増加を実現できることを見出した。

図５は、異なるＵＥからのＵＲＬＬＣ及びｅＭＢＢデータを多重化するためにプリエンプションを実現する方法の例を示す。

グラントベースのＵＲＬＬＣの場合、モバイルデバイス３（例えば、図１のＵＥ３Ｂ）は、ＵＲＬＬＣ送信のスケジューリング要求を基地局５（図示せず）に送信する。そのＵＲＬＬＣサービスに必要なリソースが別のモバイルデバイス３のｅＭＢＢ送信に使用されている場合、基地局５は、適切なＵＬプリエンプション指示を（プリエンプションモジュール６５を使用して）干渉ＵＥ（この例では、ＵＥ３Ａ）に送信する。本明細書で用いる「干渉ＵＥ」という語は、以下の適切なプリエンプト可能なリソースが（ＵＲＬＬＣ送信のスケジューリング要求の受信前に）基地局５によって割り当てられたＵＥを指す。（プリエンプションモジュール４５を使用する）ｅＭＢＢ ＵＥ３Ａは、ｅＭＢＢ送信を（現在のスロット内で）キャンセルするか、又は元のグラントを変更して、ＵＲＬＬＣ ＵＥ３Ｂに割り当てられたリソースの周辺でパンクチャリング又はレートマッチングを行うことができるように構成してもよい。

プリエンプション指示の目的（ｅＭＢＢ ＵＥ３Ａで事前に設定したプリエンプト可能なリソースのプリエンプションをアクティブ化する目的）には、１ビット又は２ビットで足りる。更に、ＵＲＬＬＣは高い（ｅＭＢＢよりも高い）信頼性を必要とするため、ｅＭＢＢ ＵＥ３Ａの上記のプリエンプション指示は、ＵＲＬＬＣ通信と同一の（又は少なくとも同等の）信頼性レベルを有する可能性がある。しかし、別の例では、ＵＲＬＬＣ ＵＥ３Ｂの正確なリソース割り当てを（ＵＬプリエンプション指示とともに）ｅＭＢＢ ＵＥ３Ａに送信することができ、その結果、１ビット又は２ビットのプリエンプション指示よりも比較的高い制御シグナリングオーバーヘッドが発生する。しかしながら、正確なリソース割り当てを実現することは、そのようなＵＬグラント変更指示で得ることのできる信頼性に影響を与える可能性がある。

グループ共通又はＵＥ固有のダウンリンク（ＤＬ）制御メッセージのいずれかをＵＬプリエンプション指示に使用することができる。ＵＬプリエンプション指示の信頼性を向上させるために、ｅＭＢＢ ＵＥ３Ａのプリエンプト可能なリソースを（例えば、上位レイヤ／ＲＲＣを介して）事前に設定してから、１ビット（又は２ビット）の指示でアクティブ化することができる。これにより、指示を送信するＤＣＩペイロードサイズを有利に減少／最小化することができる。

ＵＬプリエンプション指示を受信すると、ｅＭＢＢ ＵＥ３Ａは、当該指示を受信したプリエンプト可能なリソース上でのみその送信をミュートするように、有利に構成されている。これにより、プリエンプトされていないリソースを使用することで遅延を長引かせることなく、緊急かつ動的に設定されたタイプのアップリンク制御情報（ＵＣＩ）（例えば、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ）を、ｅＭＢＢ ＵＥ３Ａが（プリエンプトされたリソースの周波数外の周波数位置を使用している場合、プリエンプトされたリソースと同時に）送信することができる。

基地局５は、プリエンプト可能なリソースに関する情報（例えば、時間／周波数割り当て、オフセット、ミニスロット／シンボルの周期など）を、例えば、ＲＲＣシグナリングを介してセミスタティックに、及び／又はｅＭＢＢ ＰＵＳＣＨ（Ｐｈｙｓｉｃａｌ Ｕｐｌｉｎｋ Ｓｈａｒｅｄ ＣＨａｎｎｅｌ：物理アップリンク共有チャネル）送信のＵＬグラントと多重化して、ｅＭＢＢ ＵＥ３Ａに（プリエンプションモジュール６５を使用して）送信するように構成してもよい。

図５に示す例では、ＵＬ送信ｅＭＢＢ ＵＥ３は、すべてのスロット内の２つの４シンボルのミニスロット（期間）で、プリエンプト可能なリソースが事前に設定されている。具体的には、プリエンプト可能なリソースは、所定のスロットのシンボル＃３～６（ここでは「期間１」と呼ぶ）及び／又はシンボル＃９～１１、１３（ここでは「期間２」と呼ぶ）に割り当てられる（シンボル＃１２でｅＭＢＢ ＵＥ３Ａに関連付けられた復調参照信号（ＤＭＲＳ）はスキップする）。

ｅＭＢＢ ＵＥ１は、ＵＥ固有のスケジューリングＤＣＩを介したＵＬプリエンプション指示に従って、指示されたプリエンプト可能なリソースでの送信を中断する。この例では、ＵＲＬＬＣ ＵＥ３Ｂは、期間１又は期間２（又は適切であれば両方）を使用して制御とＤＭＲＳを含むｅＭＢＢスロットのシンボルを回避するように構成されている。

設定可能な期間（例えば、１ミリ秒から数ミリ秒の端数）の指示は、ＵＬプリエンプション指示によっても示すことができる。そのような設定可能な期間がＵＬプリエンプション指示で示された場合、設定されたプリエンプト可能なリソースで送信を再開することができることをｅＭＢＢ ＵＥ３Ａに通知するための追加のシグナリングは必要ない。

また、基地局５は、別個の電力設定を使用して、プリエンプト可能なリソースでｅＭＢＢサービス用のＵＥのＵＬ送信（Ｔｘ）電力を制限するように構成してもよい。例えば、プリエンプト可能なリソースに、いわゆる「ｂｅｔａ＿ｏｆｆｓｅｔ」を定義することができる。これは、他のリソースのエネルギーを変更することなく、当該プリエンプト可能なリソースについて異なるＥＰＲＥ（Ｅｎｅｒｇｙ Ｐｅｒ Ｒｅｓｏｕｒｃｅ Ｅｌｅｍｅｎｔ：リソース要素あたりのエネルギー）を有効にするためのものである。これにより、プリエンプト可能なリソース上においてｅＭＢＢ送信からＵＲＬＬＣ ＵＥへの潜在的な干渉を減らすことができる。このようなプリエンプト可能なリソース固有の電力設定は、干渉ＵＥがそのｅＭＢＢ送信をキャンセル／変更する前に初回のＵＲＬＬＣ送信が発生する場合にも有用である。

優れた処理能力とＵＬプリエンプションサポートとを備えたｅＭＢＢ ＵＥを選択して、設定されたＵＲＬＬＣリソースにスケジューリングすることが好ましい。プリエンプトされたスロットに対してｅＭＢＢ ＵＥが新しいＭＣＳ／ＴＢＳを必要とする場合、当該新しいＭＣＳ／ＴＢＳをＵＬプリエンプション指示によってシグナリングしてもよいし、シグナリングなしで暗黙的にＭＣＳ／ＴＢＳを更新するデルタ値を規定してもよい。

要約すると、ＵＲＬＬＣ ＵＥのＵＲＬＬＣトラフィックが到来するよりも前に、ｅＭＢＢ ＵＥのプリエンプト可能なリソースを設定することができる。ＵＥ間ＵＲＬＬＣリソースでｅＭＢＢ送信をキャンセル／変更するメカニズムについて説明する。更に、プリエンプト可能なリソースを介したｅＭＢＢＵＬ送信用に個別の電力設定を設定して、（他のリソースのＥＰＲＥを変更することなく）別のＥＰＲＥを有効にすることができる。

（ＵＬプリエンプション指示（第２の例示的な実施形態））
図６に、ＵＲＬＬＣサービスをサポートするためにプリエンプションを実現する別の例示的な方法を示す。この例では、ＵＬ送信ｅＭＢＢ ＵＥ３Ａは、各スロットの（単一の）４シンボルのミニスロットでプリエンプト可能なリソースを設定されている。この例では、プリエンプト可能なリソースは、各スロットのシンボル＃３～６に割り当てられている（ただし、他の例では、異なるプリエンプト可能なリソースを使用することもある）。

ｅＭＢＢ ＵＥ３Ａは、適切なＵＬ ＵＲＬＬＣプリエンプション指示を（この例では、グループ共通スケジューリングＤＣＩを介して）受信すると、シンボル＃３～６でのすべての送信を中断する。このＵＥ３Ａについては、対応の符号化レートが（プリエンプションのために）１よりも大きくなる可能性がある。したがって、当該ＵＥ３Ａは、ＰＵＳＣＨの再送を待つ必要がある可能性もある。その場合、基地局５が新しいＭＣＳ／ＴＢＳ（変調及び符号化方式／トランスポートブロックサイズ）をＵＥ３Ａにシグナリングしなければならない可能性もある。これは、例えばＵＬプリエンプション指示と一緒に（又はその一部として）実現することができる。

或いは、ＭＣＳ／ＴＢＳは、例えば、追加のシグナリングなしで、適切なデルタ値によって更新することもできる。不連続送信（ＤＴＸ）と同様に、プリエンプトされたリソースをパンクチャリングすることも可能である。

ｅＭＢＢ ＵＥ３Ａに新しい／更新されたＭＣＳ／ＴＢＳが提供された場合、ｅＭＢＢ送信における最初のシンボルの前に新しいＴＢＳでＰＵＳＣＨの符号化を実行する必要がある（すなわち、プリエンプト可能なリソースがＵＲＬＬＣ ＵＥ３Ｂに再度割り当てられた、スロットの最初のシンボル）。したがって、ＵＥ３ＡがＰＵＳＣＨ符号化の適切な処理を実行できるようにするために、ＵＬ ＵＲＬＬＣプリエンプション指示が、ＵＥ３Ａが当該処理を新しいＭＣＳ／ＴＢＳで実行するのに十分な時間を有するようにして、ｅＭＢＢ ＵＥ３Ａに送信される。図６に示す例では、ＵＬ ＵＲＬＬＣプリエンプション指示は、関連するスロットの開始に先行する８番目のシンボルで送信される。言い換えると、新しいＭＣＳ／ＴＢＳがＵＥ３Ａによって適用されるまでの遅延を定義するパラメータ「Ｎ２」の値は８である。

第１の例示的な実施形態と同様に、ＵＥＬＬＣはｅＭＢＢよりも高い信頼性を要するため、ｅＭＢＢ ＵＥ３Ａのプリエンプション指示はＵＬＬＣ通信と同一の（又は少なくとも同等の）信頼性レベルを有してもよい。

有益なことに、ｅＭＢＢ ＵＥ３Ａは、プリエンプトされたリソースと同時であるが、ＵＲＬＬＣトラフィック用に予約されていない周波数位置を使用するインスタンス／シンボルでも、遅延を長引かせることなく、緊急かつ動的に設定されたＵＣＩタイプ（例えば、ＨＡＲＱ ＡＣＫ／ＮＡＣＫ）を送信することができる。

ペイロードサイズを低下させ、信頼性を向上させるために、ｅＭＢＢ ＵＥ３Ａには、プリエンプト可能である、事前に設定したリソースのセットを与えることができる。プリエンプト可能なリソースに関する情報は、ＲＲＣシグナリングを介してセミスタティックに（すなわち、この場合、ＲＲＣは、ｅＭＢＢのプリエンプト可能なリソースのＵＥ固有の「時間／周波数割り当て、オフセット、ミニスロット／シンボルの周期」などを設定する）、及び／又は、ｅＭＢＢ ＵＥのＰＵＳＣＨのＵＬグラントと多重化して、ｅＭＢＢ ＵＥ３Ａに送信することができる。

有益なことに、（他のＵＥからの）ＵＲＬＬＣトラフィックを受信する前に、ｅＭＢＢ ＵＥ３Ａ用のＵＥ固有ＵＬ ＤＣＩを使用して、プリエンプト可能なリソースの周波数割り当てなどを動的に設定することができる。したがって、この場合、ＵＬ ＤＣＩを使用して、特定のＵＥ３ＡのＲＲＣ構成をオーバーライドすることができる。

基地局５は、ＤＬ制御メッセージング（「ＵＬプリエンプション指示」及び／又は同様の内容の別の指示など）を使用して、過去にｅＭＢＢ ＵＥ３Ａに割り当てられた、事前に設定されたプリエンプト可能なリソースのプリエンプションをアクティブ化する。例えば、基地局５は、リソースブロック＃５から＃７と、ミニスロット＃０及び＃１とを、特定のｅＭＢＢ ＵＥ（又はＵＥのグループ）用のプリエンプト可能なリソースとして（ＲＲＣを介して）構成することができる。この場合、「プリエンプションリソースインデックス＝１」は、ミニスロット＃０（期間１）を指すのに用いることができる。「プリエンプションリソースインデックス＝２」は、ミニスロット＃１（期間２）を指すのに用いることができる。「プリエンプションリソースインデックス＝３」は、ミニスロット＃０及び＃１（期間１と期間２の両方）を指すのに用いることができる。ｅＭＢＢ ＵＥ３Ａは、ＵＬプリエンプション指示を受信すると、指示されたリソースの対応部分での送信を中断（又は停止）するように構成される。

このアプローチは、ｅＭＢＢサービスが基地局５によって再スケジューリングされるアプローチと比較して、制御オーバーヘッドが低く、スペクトル効率が高いという利点がある。上記ｅＭＢＢサービスが基地局５によって再スケジューリングされるアプローチでは、通常、基地局５とＵＥ３Ａの間で複数のミニスロットベースの制御シグナリングが必要となり、高い制御シグナリングオーバーヘッドを引き起こす可能性がある。更に、上記のアプローチは、ｅＭＢＢサービスの中断を有益に減らす可能性がある。

（ＵＬプリエンプション指示の更なる詳細）
ＵＬ ＵＲＬＬＣプリエンプション指示には、以下のフィールド（少なくとも１つのフィールド）が存在する。
フィールド１：（ＵＥ固有の）プリエンプト可能なリソースのインデックスを含む１ビット又は２ビットの指示。
フィールド２：プリエンプションの期間（例えば、１ミリ秒から数ミリ秒の端数）を設定するための２ビットの指示（オプションで存在し、ＲＲＣを介して設定可能な長さ）。

例えば、プリエンプト可能なリソースの指示が「１」である場合、ｅＭＢＢ ＵＥ３Ａは、（対応する）設定されたプリエンプト可能なリソース上でＵＬ送信をプリエンプトするように構成してもよい。プリエンプト可能なリソースの指示が「０」である場合、ｅＭＢＢ ＵＥ３Ａは、特定される期間のすべてのＰＲＢでＵＬ送信を中断するように構成してもよい。

「フィールド２」が存在するが、設定可能な期間の値が「０」である場合、ＵＥは、単純に、ＵＬ ＵＲＬＬＣプリエンプション指示を受信した際にＵＬ送信をキャンセルするのみである。この場合、新しいＵＬグラントを使用してｅＭＢＢ送信を再開することができる。設定された期間が０．５ｅＭＢＢスロットに等しい場合、ミニスロット＃０（期間１）のみがプリエンプトされる。設定された期間が２ｅＭＢＢスロットに等しい場合、ミニスロット＃０（期間１）とミニスロット＃１（期間２）の両方を２つのｅＭＢＢスロット用にプリエンプトすることができる。他のプリエンプション期間も同様の方法で設定することができるものとする。

ＵＬ ＵＲＬＬＣプリエンプション指示に関連付けられた期間を示すことで、プリエンプトされたリソースで（ｅＭＢＢ）送信を（すなわち、指示された期間が経過した後に）再開することができることをＵＥ３Ａに通知するための追加のシグナリングの必要性を回避することが可能である。有益なことに、これにより、ＣＯＲＳＥＴ（制御リソースセット）の使用とＵＥ３ＡでのＤＬ制御モニタリングの回数が大幅に削減される。

ｅＭＢＢ ＵＥ３Ａの時間／周波数リソースのプリエンプトされた領域は、動的にスケジューリングされたＵＲＬＬＣ ＵＥ３Ｂの領域以上である可能性がある。これは、適切であれば、他のＵＥの設定済みのグラントフリーＵＲＬＬＣリソースの領域もカバーする場合がある。

（ＵＲＬＬＣのセル間干渉の回避）
上述のｅＭＢＢ及びＵＲＬＬＣトラフィックの多重化は、セル固有である可能性が高い。しかしながら、セルエッジハイパワーＵＥによるｅＭＢＢ送信は、隣接セルのＵＲＬＬＣサービスに対するＵＬ干渉又はクロスリンクＵＥ間干渉を引き起こす可能性もある。以下は、ＵＲＬＬＣサービスにおけるセル間干渉を減らすための例示的なメカニズムの説明である。

隣接する基地局５同士は、それぞれのセルエッジＵＥのプリエンプト可能なｅＭＢＢリソースの設定を、例えば、細粒度の時間／周波数割り当て及びプリエンプトｅＭＢＢリソースの周期（ＳＣＳ、スロット、ミニスロットなど）に関する情報を交換することで、調整してもよい。例えば、時間領域のリソース割り当てを識別する情報は２ビットを使用して交換することができ、周波数領域のリソース割り当てを識別する情報は５ビットを使用して交換することができる。ＵＲＬＬＣ ＵＥのオフセット、ミニスロット／シンボル周期などを識別する更なる情報も、隣接基地局間で交換することができる。他に送信することのできる情報には、例えば、ＵＲＬＬＣ（被干渉）ＵＥのトラフィック優先度が含まれる。

また、セル（すなわち、基地局）は、例えば、ＵＥ間参照信号（ＲＳ）測定などに基づいて、ＵＥ間干渉の大きいセルエッジＵＥのリストを識別及び保持するように構成することもできる。少なくともセルエッジのｅＭＢＢ ＵＥは、そのサービング基地局によって、ＵＲＬＬＣ ＵＥによって使用される可能性のあるプリエンプト可能なリソースについて、協調ＵＬ ＵＥ間干渉を（例えば、ＳＲＳ－ＲＳＲＰを使用して）測定するように構成することができる。測定結果は、Ｘ２インターフェースを介して基地局間で交換することができる。

基地局は、ＵＬ ＵＥ間干渉又はクロスリンクＵＥ間干渉の高いセルエッジＵＥのリストを測定結果に基づいて更新し、干渉グループ内のＵＥ間で送信を多重化するのを回避するように構成することもできる。

また、基地局は、ＵＲＬＬＣ送信において高い（例えば、所定のしきい値よりも高い）ＵＬ ＵＥ間干渉が検出された場合に隣接基地局に通知をするように構成することもできる。基地局は、ＵＲＬＬＣ送信に影響を与えるＵＥ間干渉の存在を示す適切なフラグを含むＸ２ ＵＬ ＨＩＩ（Ｈｉｇｈ Ｉｎｔｅｒｆｅｒｅｎｃｅ Ｉｎｄｉｃａｔｉｏｎ：高干渉情報）（又は同様の情報）を送信することで、これを行ってもよい。

このように、サービングセル（基地局）は、優先度の高いＵＲＬＬＣサービスについてプリエンプション要求又は高干渉に関する情報を隣接セルから受信すると、特定される期間及び／又は周期について、指示された／（事前に）設定された時間／周波数領域リソースでｅＭＢＢサービスのプリエンプションをアクティブ化するように構成することもできる。

（変形例及び代替案）
以上、例示的な実施形態を詳細に説明した。上記例示的な実施形態については複数の変形例及び代替案が可能であり、そのようにして具現化された発明であっても同様の利を得ることができることは当業者には明らかである。説明のため、これらの変形例及び代替案を一部のみ説明する。

上記の例示的な実施形態は、５Ｇ Ｎｅｗ Ｒａｄｉｏシステム及びＬＴＥシステム（Ｅ－ＵＴＲＡＮ）の双方に適用してもよいものとする。

上の説明では、理解を容易にするため、ＵＥ、アクセスネットワークノード（基地局）及びコアネットワークノードは、個別のモジュール（通信制御モジュールなど）を複数有するものとして説明した。これらのモジュールは、例えば、本発明を実施するために既存のシステムに変更を加えた特定のアプリケーションについては上述のような方法で提供することができるが、例えば、最初から本発明の特徴を念頭に置いて設計されたシステムなどの他のアプリケーションについては、これらのモジュールをオペレーティングシステム又はコード全体に組み込んでもよく、この場合、これらのモジュールを個別のエンティティとして認識する必要はない。これらのモジュールは、ソフトウェア、ハードウェア、ファームウェア、又はこれらの組み合わせで実現してもよい。

各コントローラは任意の形態の処理回路を適宜含んでもよく、例えば、以下が含まれる（限定的ではない）。ハードウェアに実装された１つ以上のコンピュータプロセッサ；マイクロプロセッサ；ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔｓ：中央処理装置）；ＡＬＵ（Ａｒｉｔｈｍｅｔｉｃ Ｌｏｇｉｃ Ｕｎｉｔｓ：算術論理ユニット）；ＩＯ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ：入出力）回路；内部メモリ／キャッシュ（プログラム及び／又はデータ）；処理レジスタ；通信バス（例えば、制御、データ及び／又はアドレスバス）；ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ：ダイレクトメモリアクセス）機能；及びハードウェア又はソフトウェア実装されたカウンタ、ポインタ、タイマなど。

上述の例示的な実施形態では、複数のソフトウェアモジュールを説明した。
当業者が理解するように、ソフトウェアモジュールは、コンパイルされた形式又はコンパイルされていない形式で提供してもよいし、コンピュータネットワークを介した信号として、又は記録媒体上で、ＵＥ、アクセスネットワークノード（基地局）、及びコアネットワークノードに供給してもよい。更に、このソフトウェアの一部又はすべてによって実行される機能は、１つ以上の専用ハードウェア回路を使用して実行してもよい。ただし、ソフトウェアモジュールは、ＵＥ、アクセスネットワークノード、及びコアネットワークノードの機能性向上のための更新をファシリテートするため、使用することが望ましい。

ＣＰ－ＵＰ（制御プレーン－ユーザプレーン）分割を採用する場合、基地局を別個の制御プレーンとユーザプレーンエンティティとに分割することができ、当該エンティティは各々関連のトランシーバ回路、アンテナ、ネットワークインターフェース、コントローラ、メモリ、オペレーティングシステム、通信制御モジュール（など）を含んでもよい。基地局が分散型基地局を備える場合、ネットワークインターフェース（図３における参照番号５５）は、当該分散型基地局のそれぞれの機能間で信号を通信するためのＥ１インターフェース及びＦ１インターフェース（制御プレーン用のＦ１－Ｃ及びユーザプレーン用のＦ１－Ｕ）も含む。この場合、通信制御モジュールは、基地局の制御プレーン部分とユーザプレーン部分との間の通信（シグナリングメッセージの生成、送信、及び受信）も担う。分散型基地局を使用する場合、上の例示的な実施形態で説明したように、通信リソースのプリエンプションのために制御プレーン及びユーザプレーン部分の両方を含む必要はない。プリエンプションは、制御プレーン部分を介さずに、基地局のユーザプレーン部分でハンドリングしてもよいものとする（その反対も可）。

上記の例示的な実施形態は、「非モバイル」又は一般に固定のユーザ装置にも適用可能である。上述のモバイルデバイスは、ＭＴＣ／ＩｏＴデバイスなどを含んでもよい。

制御データは、少なくとも１つの通信リソースをプリエンプトするための期間（例えば、１ミリ秒から数ミリ秒の端数）を識別する情報を含んでもよく、
プリエンプトは、上記受信した制御データが識別する期間において識別された少なくとも１つの通信リソースをプリエンプトすることを含んでもよい。

上記少なくとも１つの通信リソースを識別する情報は、少なくとも１つの通信リソースの複数のセットを識別する情報を含んでもよく、上記制御データは、上記少なくとも１つの通信リソースの複数のセットのうちの少なくとも１つを識別する情報を含んでもよく、上記プリエンプトは、上記少なくとも１つの通信リソースの複数のセットうちの上記識別された１つ又は複数のセットをプリエンプトすることを含んでもよい。

上記情報を上記ＵＥで受信することは、上記少なくとも１つの通信リソースを識別する情報（例えば、ＵＥ固有の時間／周波数割り当て、オフセット、周期など）を含むＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ：無線リソース制御）メッセージと、上記少なくとも１つの通信リソースを識別する情報を含む制御情報（例えばアップリンクＤＣＩ）と、のうちの少なくとも１つを受信することを含んでもよい。

上記プリエンプトは、上記識別された少なくとも１つの通信リソースをグラントフリーＵＲＬＬＣ通信用にプリエンプトすることを含んでもよい。

上記制御データは、プリエンプトされる上記少なくとも１つの通信リソースに関連付けられたインデックスを識別するフィールド（例えば、１ビット又は２ビット）と、上記少なくとも１つの通信リソースをプリエンプトする期間を識別するフィールド（例えば、２ビット）と、のうちの少なくとも１つを含んでもよい。

上記ＵＥによって実行される方法は、ＭＣＳ／ＴＢＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ／Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ Ｓｉｚｅ：変調及び符号化方式／トランスポートブロックサイズ）を識別する情報を取得することを更に含んでもよい。上記ＭＣＳ／ＴＢＳを識別する情報は、上記少なくとも１つの通信リソースの少なくとも一部がＵＲＬＬＣ通信用にプリエンプトされることを示す上記制御データに含まれてもよい、又は上記制御データとともに受信されてもよい。上記ＭＣＳ／ＴＢＳを識別する情報は、上記少なくとも１つの通信リソースの少なくとも一部がＵＲＬＬＣ通信用にプリエンプトされることを示す上記制御データを受信する前に上記ＵＥが適用するＭＣＳ／ＴＢＳを更新するためのデルタ値を含んでもよい。

上記ＵＥによって実行される方法は、上記少なくとも１つのプリエンプト可能な通信リソースに関連付けられたＴｘ（ｔｒａｎｓｍｉｓｓｉｏｎ：送信）電力レベル（例えば、ＥＰＲＥ（Ｅｎｅｒｇｙ Ｐｅｒ Ｒｅｓｏｕｒｃｅ Ｅｌｅｍｅｎｔ：リソース要素あたりのエネルギー）を識別する更なる制御データ（例えば、「ベータオフセット」、振幅スケーリング係数など）を受信することを更に含んでもよい。上記プリエンプトは、上記識別された少なくとも１つの通信リソースで、上記ＵＥによる送信に上記識別されたＴｘ電力レベルを適用することを含んでもよい。

ネットワーク装置によって実行される方法は、上記送信した制御データが示す上記少なくとも１つの通信リソースでＵＲＬＬＣデータを受信することを更に含んでもよく、上記ＵＲＬＬＣデータは、上記ＵＥに割り当てられた上記通信リソースのセットで上記ＵＥからの更なるデータと多重化される。

上記ネットワーク装置によって実行される方法は、上記ＵＲＬＬＣデータを送信するために（例えば、異なるＵＥからのスケジューリング要求に応じて）、上記少なくとも１つの通信リソースの一部を異なるＵＥに割り当てることを更に含んでもよい。

ＵＲＬＬＣ通信の設定は、少なくとも１つのプリエンプト可能な通信リソースの設定（例えば、時間／周波数割り当て、周期など）を含んでもよい。

上記ネットワーク装置によって実行される方法は、隣接するネットワーク装置から高干渉に関する情報を受信することと、少なくとも１つの通信リソースがＵＲＬＬＣ通信用にプリエンプトされることを示す制御データを、少なくとも１つのＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）に送信することと、を更に含んでもよい。

上記ネットワーク装置によって実行される方法は、上記ネットワーク装置によりサーブされるＵＥが、上記ＵＥによるＵＲＬＬＣ通信において高い（例えば、所定の閾値よりも高い）アップリンクＵＥ間干渉を受けていると判断することと、隣接する基地局に、ＵＲＬＬＣ送信に影響を与えるＵＥ間干渉の存在を示す情報（例えば、Ｘ２ ＵＬ ＨＩＩ（Ｈｉｇｈ Ｉｎｔｅｒｆｅｒｅｎｃｅ Ｉｎｄｉｃａｔｉｏｎ：高干渉情報）など）を送信することと、を更に含んでもよい。

上記ネットワーク装置によって実行される方法は、上記ネットワーク装置のセルのエッジ又はその近隣に位置し、比較的高い干渉を受けている少なくとも１つのＵＥを識別する情報（例えば、１以上のＵＥのリスト）を保持することを更に含んでもよい。

上記ネットワーク装置によって実行される方法は、ＵＥ間ＲＳ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ：参照信号）測定に基づいて、特定のＵＥが高い干渉を受けているか否かを判断することを更に含んでもよい。

上記ネットワーク装置によって実行される方法は、少なくとも１つのＵＥから、（例えばＳＲＳ－ＲＳＲＰを使用する）セル間協調アップリンクＵＥ間干渉測定の結果を取得することと、上記測定結果を隣接する基地局と交換することと、を更に含んでもよい。

種々の他の変更は、当業者にとって明らかであるため、ここでは更に詳細な説明を省略する。

本出願は、２０１８年８月１０日出願の英国特許出願番号１８１３１３２．６に基づく優先権の利益を主張する。この開示の内容は、全てここに含めておく。

Claims (9)

1. ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）により実行される方法であって、
   キャンセル可能な少なくとも１つの通信リソースを識別する情報を含むＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ：無線リソース制御）メッセージを受信することと、
   前記少なくとも１つの通信リソースの少なくとも一部を用いたアップリンク送信がキャンセルされることを示す情報、および、キャンセルされる期間を示す情報を含むＤＣＩ（ダウンリンク制御情報）を受信することと、
   前記ＲＲＣメッセージおよび前記ＤＣＩに基づいて、前記少なくとも１つの通信リソースの少なくとも一部を用いた前記アップリンク送信を前記期間でキャンセルすることと、を備える方法。
2. 前記ＤＣＩは、キャンセルされる前記アップリンク送信で用いられる前記少なくとも１つの通信リソースの少なくとも一部に対応するインデックスを含むフィールドと、キャンセルする前記期間を含むフィールドと、を含む、請求項１記載の方法。
3. ＭＣＳ／ＴＢＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ／Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋ Ｓｉｚｅ：変調及び符号化方式／トランスポートブロックサイズ）を示す情報を取得することを更に備える、請求項１または２記載の方法。
4. 前記ＭＣＳ／ＴＢＳを示す情報は、前記ＤＣＩとともに受信される、請求項３記載の方法。
5. 前記ＭＣＳ／ＴＢＳを示す情報は、前記ＤＣＩを受信する前に前記ＵＥが適用するＭＣＳ／ＴＢＳを更新するためのデルタ値を含む、請求項３又は４記載の方法。
6. キャンセル可能な前記少なくとも１つの通信リソースに関連付けられたＴｘ（ｔｒａｎｓｍｉｓｓｉｏｎ：送信）電力レベルを示す制御データを受信することと、
   前記少なくとも１つの通信リソースの少なくとも一部で、前記ＵＥによるアップリンク送信に前記Ｔｘ電力レベルを適用することと、を備える、請求項１乃至５のうち何れか１項記載の方法。
7. ネットワーク装置により実行される方法であって、
   キャンセル可能な少なくとも１つの通信リソースを識別する情報を含むＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ：無線リソース制御）メッセージをＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）に送信することと、
   前記少なくとも１つの通信リソースの少なくとも一部を用いた前記ＵＥによるアップリンク送信がキャンセルされることを示す情報、および、キャンセルされる期間を示す情報を含むＤＣＩ（ダウンリンク制御情報）を前記ＵＥに送信することと、を備える方法。
8. ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）であって、
   キャンセル可能な少なくとも１つの通信リソースを識別する情報を含むＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ：無線リソース制御）メッセージを受信する手段と、
   前記少なくとも１つの通信リソースの少なくとも一部を用いたアップリンク送信がキャンセルされることを示す情報、および、キャンセルされる期間を示す情報を含むＤＣＩ（ダウンリンク制御情報）を受信する手段と、
   前記ＲＲＣメッセージおよび前記ＤＣＩに基づいて、前記少なくとも１つの通信リソースの少なくとも一部を用いた前記アップリンク送信を前記期間でキャンセルする手段と、を備えるＵＥ。
9. ネットワーク装置であって、
   キャンセル可能な少なくとも１つの通信リソースを識別する情報を含むＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ：無線リソース制御）メッセージをＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ユーザ装置）に送信する手段と、
   前記少なくとも１つの通信リソースの少なくとも一部を用いた前記ＵＥによるアップリンク送信がキャンセルされることを示す情報、および、キャンセルされる期間を示す情報を含むＤＣＩ（ダウンリンク制御情報）を前記ＵＥに送信する手段と、を備えるネットワーク装置。
   

Images