(57)【要約】  送信機と受信機とを含む無線通信システムにおいて送信機として機能する無線通信装置は、第１の送信方式で送信される第１のデータを生成する第１データ生成部と、第２の送信方式で送信される第２のデータを生成する第２データ生成部と、前記第１のデータの第１の送信パラメータと、前記第２のデータの第２の送信パラメータとを決定する送信パラメータ決定部と、前記第１のデータの送信中に前記第２のデータが生成された場合、前記第１のデータの送信に割り当てられたリソースの一部をパンクチャし、パンクチャされていない部分において前記第１の送信パラメータを用いて前記第１のデータを送信し、パンクチャされた部分において前記第２の送信パラメータを用いて前記第２のデータを送信する送信部とを有する。
2017195702.tif 000002
【特許請求の範囲】
【請求項１】
送信機と受信機とを含む無線通信システムにおいて送信機として機能する無線通信装置であって、
第１の送信方式で送信される第１のデータを生成する第１データ生成部と、
第２の送信方式で送信される第２のデータを生成する第２データ生成部と、
前記第１のデータの第１の送信パラメータと、前記第２のデータの第２の送信パラメータとを決定する送信パラメータ決定部と、
前記第１のデータの送信中に前記第２のデータが生成された場合、前記第１のデータの送信に割り当てられたリソースの一部をパンクチャし、パンクチャされていない部分において前記第１の送信パラメータを用いて前記第１のデータを送信し、パンクチャされた部分において前記第２の送信パラメータを用いて前記第２のデータを送信する送信部と、
を有する無線通信装置。
【請求項２】
前記送信パラメータ決定部は、前記第１のデータの送信に割り当てられた帯域の範囲内で、或いは前記第１のデータの送信に割り当てられた帯域の範囲内及び範囲外で、前記第２のデータの帯域幅及び送信位置を決定し、前記第１のデータの送信電力に基づいて前記第２のデータの送信電力を決定する、請求項１に記載の無線通信装置。
【請求項３】
前記送信パラメータ決定部は、前記第２のデータに送信電力を優先的に割り当てる、請求項１又は２に記載の無線通信装置。
【請求項４】
前記送信パラメータ決定部は、前記第１のデータの変調符号化方式と前記第２のデータの変調符号化方式との対応関係を参照して、前記第１のデータの変調符号化方式に基づいて前記第２のデータの変調符号化方式を選択する、請求項１乃至３のうちいずれか１項に記載の無線通信装置。
【請求項５】
前記送信パラメータ決定部は、前記第２のデータに適用する変調方式を、所定の変調方式に限定する、請求項１乃至４のうちいずれか１項に記載の無線通信装置。
【請求項６】
前記送信パラメータ決定部は、前記第２のデータの変調方式を決定し、
前記送信部は、前記第２のデータの変調方式と、前記第２のデータと参照信号との送信電力差を示す情報とを、前記受信機に送信する、請求項１乃至４のうちいずれか１項に記載の無線通信装置。
【請求項７】
送信機と受信機とを含む無線通信システムにおいて受信機として機能する無線通信装置であって、
第１の送信方式で送信される第１のデータの送信に割り当てられたリソースの一部がパンクチャされ、パンクチャされた部分において、第２の送信方式で送信される第２のデータが送信されることを検出する検出部と、
前記第１のデータの第１の送信パラメータと、前記第２のデータの第２の送信パラメータとを決定する送信パラメータ決定部と、
パンクチャされていない部分において前記第１の送信パラメータを用いて前記第１のデータを受信し、パンクチャされた部分において前記第２の送信パラメータを用いて前記第２のデータを受信する受信部と、
を有する無線通信装置。
【請求項８】
送信機と受信機とを含む無線通信システムにおいて送信機として機能する無線通信装置における無線通信方法であって、
第１の送信方式で送信される第１のデータを生成するステップと、
前記第１のデータの第１の送信パラメータを決定するステップと、
前記第１のデータを送信するステップと、
第２の送信方式で送信される第２のデータを生成するステップと、
前記第２のデータの第２の送信パラメータを決定するステップと、
前記第１のデータの送信中に前記第２のデータが生成された場合、前記第１のデータの送信に割り当てられたリソースの一部をパンクチャし、パンクチャされた部分において前記第２の送信パラメータを用いて前記第２のデータを送信するステップと、
を有する無線通信方法。
【請求項９】
送信機と受信機とを含む無線通信システムにおいて受信機として機能する無線通信装置における無線通信方法であって、
第１の送信方式で送信される第１のデータの送信に割り当てられたリソースの一部がパンクチャされ、パンクチャされた部分において、第２の送信方式で送信される第２のデータが送信されることを検出するステップと、
前記第１のデータの第１の送信パラメータと、前記第２のデータの第２の送信パラメータとを決定するステップと、
パンクチャされていない部分において前記第１の送信パラメータを用いて前記第１のデータを受信し、パンクチャされた部分において前記第２の送信パラメータを用いて前記第２のデータを受信するステップと、
を有する無線通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムにおける無線通信装置及び無線通信方法に関する。
【背景技術】
【０００２】
現在、３ＧＰＰ（3rd Generation Partnership Project）において、第４世代の無線通信システムの一つであるＬＴＥ（Long Term Evolution）−Ａｄｖａｎｃｅｄの後継にあたる５Ｇと呼ばれる次世代のシステムの検討が進んでいる。５Ｇでは、主にｅＭＢＢ（extended Mobile Broadband）、ｍＭＴＣ(massive Machine Type Communication）、ＵＲＬＬＣ（Ultra Reliability and Low Latency Communication）の３つのユースケースが想定されている（非特許文献１参照）。【０００３】
ＵＲＬＬＣは、低遅延及び高信頼性による無線通信を実現することを目的としている。ＵＲＬＬＣにおいて低遅延を実現するための具体策として、Ｓｈｏｒｔ  ＴＴＩ長（サブフレーム長、サブフレーム間隔とも呼ばれる）の導入、パケット生成からデータ送信までの制御遅延の短縮化などが検討されている。更に、ＵＲＬＬＣにおいて高信頼性を実現するための具体策として、低ビット誤り率を実現するための低符号化率の符号化方式及び変調方式の導入、ダイバーシチの活用などが検討されている。【０００４】
このようなＵＲＬＬＣのユースケースとして、遠隔医療、事故防止を目的とした車の挙動制御などの、ミッションクリティカルなＭＴＣ（Machine Type Communication）が主に想定される。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】NTT DOCOMO, "3GPPTM Work Item Description", 3GPP TSG RAN Meeting #71, RP-160671, 7-10 March, 2016
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ＵＲＬＬＣでは、緊急度の高いデータが突然発生する可能性があり、突然発生したデータを低遅延かつ高信頼度で送信する必要がある。なお、ＵＲＬＬＣに限らず、ｍＭＴＣ、ＬＴＥ、ＬＡＡ（License-Assisted Access）、及び／又はｅＭＢＢのような他の通信サービスの送信方式においても、緊急度の高いデータが突然発生する可能性がある。【０００７】
このような緊急度の高いデータは、他のデータの送信中に発生することも考えられる。例えば、ｅＭＢＢデータの送信中に、ＵＲＬＬＣデータのパケットが発生する場合が想定される。この場合、他のデータ（例えば、ｅＭＢＢ）の送信が完了してから緊急度の高いデータ（例えば、ＵＲＬＬＣ）の送信を開始すると、遅延が発生し、低遅延に対する要求条件を満たすことができない可能性がある。【０００８】
しかし、緊急度の高いデータを他のデータの送信中に送信すると、これらのデータの信号が互いに干渉し、受信側においてデータを適切に検出できない可能性がある。これらのデータの信号の干渉を低減するため、他のデータのリソースをパンクチャして緊急度の高いデータを送信するという手法が考えられるが、緊急度の高いデータの送信パラメータを適切に決定しなければ高信頼性、低遅延等の要求条件を満たすことができなくなる。【０００９】
本発明は、緊急度の高いデータと、他のデータとの干渉を低減しつつ、緊急度の高いデータを低遅延で送信することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一形態に係る無線通信装置は、送信機と受信機とを含む無線通信システムにおいて送信機として機能する無線通信装置であって、
第１の送信方式で送信される第１のデータを生成する第１データ生成部と、
第２の送信方式で送信される第２のデータを生成する第２データ生成部と、
前記第１のデータの第１の送信パラメータと、前記第２のデータの第２の送信パラメータとを決定する送信パラメータ決定部と、
前記第１のデータの送信中に前記第２のデータが生成された場合、前記第１のデータの送信に割り当てられたリソースの一部をパンクチャし、パンクチャされていない部分において前記第１の送信パラメータを用いて前記第１のデータを送信し、パンクチャされた部分において前記第２の送信パラメータを用いて前記第２のデータを送信する送信部と、
を有することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、緊急度の高いデータと、他のデータとの干渉を低減しつつ、緊急度の高いデータを低遅延で送信することが可能になる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施例に係る無線通信システムを示す概略図
【図２】ｅＭＢＢデータの送信中にＵＲＬＬＣデータを送信する一例を示す概略図
【図３】本発明の実施例に係る無線通信システムにおける無線通信方法のシーケンス図
【図４】ｅＭＢＢデータの帯域内でＵＲＬＬＣデータを送信する一例を示す図
【図５Ａ】ｅＭＢＢデータの帯域内でＵＲＬＬＣデータを送信する場合を示す図
【図５Ｂ】ｅＭＢＢデータの帯域内及び帯域外でＵＲＬＬＣデータを送信する場合を示す図
【図６】ＵＲＬＬＣデータの送信電力制御の一例を示す図
【図７】ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係の一例を示す図
【図８】本発明の実施例に係る送信機の機能構成を示すブロック図
【図９】本発明の実施例に係る受信機の機能構成を示すブロック図
【図１０】本発明の実施例に係る送信機及び受信機のハードウェア構成の一例を示す図
【発明を実施するための形態】
【００１３】
以下、図面を参照して本発明の実施例を説明する。
【００１４】
以下の実施例では、送信機と受信機とを含む無線通信システムにおいて送信機又は受信機として機能する無線通信装置について説明する。送信機である無線通信装置は、第１の送信方式（例えば、ｅＭＢＢ）で送信される第１のデータの送信中に、第２の送信方式（例えば、ＵＲＬＬＣ）で送信される第２のデータが生成された場合、第１のデータの送信に割り当てられたリソースの一部をパンクチャし、パンクチャされていない部分において第１のデータを送信し、パンクチャされた部分において第２のデータを送信する。この場合、無線通信装置は、第１のデータの第１の送信パラメータと、第２のデータの第２の送信パラメータとを決定し、それぞれ第１の送信パラメータ及び第２の送信パラメータを用いて第１のデータ及び第２のデータを送信する。受信機である無線通信装置は、パンクチャされた部分において、第２の送信方式で送信される第２のデータが送信されることを検出し、パンクチャされていない部分において第１の送信パラメータを用いて第１のデータを受信し、パンクチャされた部分において第２の送信パラメータを用いて第２のデータを受信する。このようにすることで、無線通信装置は、第２のデータを低遅延で送信することが可能になる。以下の実施例では、第１の送信方式及び第２の送信方式として、それぞれｅＭＢＢ及びＵＲＬＬＣを例に挙げて説明するが、第１の送信方式及び第２の送信方式として、ｅＭＢＢ、ＵＲＬＬＣ、ｍＭＴＣ、ＬＴＥ、ＬＡＡ、ｅＭＢＢ、及び／又は他の通信サービスの送信方式の如何なる組み合わせが用いられてもよい。また、ＬＴＥは、３ＧＰＰのリリース８、又は９に対応する通信方式のみならず、３ＧＰＰのリリース１０、１１、１２、１３、又はリリース１４以降に対応する第５世代の通信方式も含む広い意味で使用する。なお、以下の実施例では、ｅＭＢＢで送信されるデータをｅＭＢＢデータと呼び、ＵＲＬＬＣで送信されるデータをＵＲＬＬＣデータと呼ぶ。
【００１５】
＜システム構成＞
図１は、本発明の実施例に係る無線通信システムの構成例を示す概略図である。図１に示すように、本発明の実施例に係る無線通信システムは、基地局ｅＮＢと移動局ＵＥとを有する。図１の例では、基地局ｅＮＢ及び移動局ＵＥが１つずつ図示されているが、複数の基地局ｅＮＢを有していてもよいし、複数の移動局ＵＥを有していてもよい。
【００１６】
基地局ｅＮＢは、１つまたは複数（例えば、３つ）の（セクタとも呼ばれる）セルを収容することができる。基地局ｅＮＢが複数のセルを収容する場合、基地局ｅＮＢのカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局ＲＲＨ：Remote Radio Head）によって通信サービスを提供することもできる。「セル」または「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局、および／または基地局サブシステムのカバレッジエリアの一部または全体を指す。さらに、「基地局」「ｅＮＢ」、「セル」、および「セクタ」という用語は、本明細書では互換的に使用され得る。基地局ｅＮＢは、固定局（fixed station）、ＮｏｄｅＢ、ｅＮｏｄｅＢ（ｅＮＢ）、アクセスポイント（access point）、フェムトセル、スモールセルなどの用語で呼ばれる場合もある。
【００１７】
移動局ＵＥは、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。
【００１８】
基地局ｅＮＢ及び移動局ＵＥは、所定の帯域を用いて下り（ＤＬ：Downlink）及び上り（ＵＬ：Uplink）の通信を行う。所定の帯域は、ＬＴＥのシステム帯域（例えば、２０ＭＨｚ）であってもよく、ＬＴＥのシステム帯域に比べて狭い帯域（例えば、１．４ＭＨｚ、１８０ｋＨｚ）であってもよい。
【００１９】
まず、下りの通信に用いられる信号について説明する。
【００２０】
移動局ＵＥは、所定の帯域に配置される下り制御チャネルを用いて下り制御情報（ＤＣＩ：Downlink Control Information）を受信するが、当該下り制御チャネルは、ＰＤＣＣＨ（Physical Downlink Control Channel）又はｅＰＤＣＣＨ（enhanced Physical Downlink Control Channel）と呼ばれてもよい。
【００２１】
また、移動局ＵＥは、所定の帯域に配置される下り共有チャネル（下りデータチャネル）を用いて下りデータを受信するが、当該下り共有チャネルは、ＰＤＳＣＨ（Physical Downlink Shared Channel）と呼ばれてもよい。
【００２２】
また、データ信号を復調するための伝搬路推定、シンボルタイミング同期、受信品質測定などのために、データ復調用参照信号が用いられる。参照信号は、ＲＳ（Reference Signal）と略称することもでき、適用される標準によってパイロット（Pilot）と呼ばれてもよい。データ復調用参照信号には、ＤＭＲＳ（Demodulation Reference Signal）と、ＣＲＳ（Cell-specific Reference Signal）とが含まれる。
【００２３】
また、品質測定用の参照信号として、ＣＳＩ−ＲＳ（Channel State Information Reference Signal）が用いられる。
【００２４】
次に、上りの通信に用いられる信号について説明する。
【００２５】
移動局ＵＥは、所定の帯域に配置される上り共有チャネル（上りデータチャネル）を用いて上りデータを送信するが、当該上り共有チャネルは、ＰＵＳＣＨ（Physical Uplink Shared Channel）と呼ばれてもよい。
【００２６】
また、データ信号を復調するための伝搬路推定、シンボルタイミング同期、受信品質測定などのために、データ復調用参照信号が用いられる。データ復調用参照信号は、ＤＭＲＳ（Demodulation Reference Signal）と呼ばれてもよい。
【００２７】
また、品質測定用の参照信号として、ＳＲＳ（Sounding Reference Signal）が用いられる。
【００２８】
上記のチャネル及び信号は、ＬＴＥにおける例であり、上記の名称とは異なる名称が用いられてもよい。
【００２９】
上記のチャネル及び信号は、例えば、時間領域及び周波数領域で構成されるリソースの所定の部分で送信される。無線フレームは時間領域において１つまたは複数のフレームで構成されてもよい。時間領域において１つまたは複数の各フレームはサブフレームと呼ばれてもよい。サブフレームは更に時間領域において１つまたは複数のスロットで構成されてもよい。スロットはさらに時間領域において１つまたは複数のシンボル（ＯＦＤＭシンボル、ＳＣ-ＦＤＭＡシンボル等）で構成されてもよい。無線フレーム、サブフレーム、スロット、およびシンボルは、いずれも信号を伝送する際の時間単位を表す。無線フレーム、サブフレーム、スロット、およびシンボルは、それぞれに対応する別の呼び方であってもよい。例えば、ＬＴＥシステムでは、基地局が各移動局に無線リソース（各移動局において使用することが可能な周波数帯域幅や送信電力等）を割り当てるスケジューリングを行う。スケジューリングの最小時間単位をＴＴＩ（Transmission Time Interval）と呼んでもよい。例えば、１サブフレームをＴＴＩと呼んでもよいし、複数の連続したサブフレームをＴＴＩと呼んでもよいし、１スロットをＴＴＩと呼んでもよい。
【００３０】
リソースブロック（ＲＢ）は、時間領域および周波数領域のリソース割当単位であり、周波数領域では１つまたは複数個の連続した副搬送波（subcarrier）を含んでもよい。また、リソースブロックの時間領域では、１つまたは複数個のシンボルを含んでもよく、１スロット、１サブフレーム、または１ＴＴＩの長さであってもよい。１ＴＴＩ、１サブフレームは、それぞれ１つまたは複数のリソースブロックで構成されてもよい。上述した無線フレームの構造は例示に過ぎず、無線フレームに含まれるサブフレームの数、サブフレームに含まれるスロットの数、スロットに含まれるシンボルおよびリソースブロックの数、および、リソースブロックに含まれるサブキャリアの数は様々に変更することができる。
【００３１】
本発明の実施例では、移動局ＵＥ又は基地局ｅＮＢがｅＭＢＢデータの送信中に緊急度の高いＵＲＬＬＣデータが発生した場合を想定する。この場合、ｅＭＢＢの送信に割り当てられたリソースの一部がパンクチャされ、パンクチャされた部分においてＵＲＬＬＣデータが送信される。
【００３２】
図２は、ｅＭＢＢデータの送信中にＵＲＬＬＣデータを送信する一例を示す概略図である。図２は、２０シンボルの送信期間に相当するｅＭＢＢデータの送信中に、２シンボルの送信期間に相当するＵＲＬＬＣデータが発生した場合を示している。このとき、ｅＭＢＢに割り当てられた２シンボルの送信期間に相当するリソースがパンクチャされ、パンクチャされた部分において、ＵＲＬＬＣデータが送信される。
【００３３】
パンクチャとは、信号の送信に割り当てられたリソースの一部において信号を送信しないことを示す。例えば、パンクチャとは、図２に示すように、ｅＭＢＢのシンボルの全て又は一部を送信しないことでもよい。この場合、送信されないｅＭＢＢのシンボルの全て又は一部の代わりに、ＵＲＬＬＣのシンボルが送信される。以下の説明では、シンボルの全て又は一部が送信されない例について説明するが、他の手法によってパンクチャを実現することも可能である。例えば、パンクチャは、ｅＭＢＢの情報ビットをＵＲＬＬＣの情報ビットでオーバーライドすることによって実現されてもよい。この場合、ｅＭＢＢデータを符号化する前のセグメントの一部がＵＲＬＬＣのために利用される。他の例として、パンクチャは、ｅＭＢＢデータの変調次数を変更することによって実現されてもよい。例えば、ｅＭＢＢデータの変調方式をＱＰＳＫ（２ビット）から１６ＱＡＭ（４ビット）に変更し、余剰の２ビットにＵＲＬＬＣの信号が埋め込まれてもよい。他の例として、ｅＭＢＢデータの変調次数は変更せず、ビットの一部がｅＭＢＢデータとＵＲＬＬＣデータで共有されてもよい。例えば、変調方式がＱＰＳＫの場合、送信可能な２ビットのうち前半の１ビットをｅＭＢＢに用い、後半の１ビットをＵＲＬＬＣに用いてもよい。この場合、ＵＲＬＬＣに割り込みされたｅＭＢＢのビットはパンクチャされていることになる。
【００３４】
ＵＲＬＬＣデータを送信する場合、ＵＲＬＬＣデータの送信パラメータ（例えば、送信電力、帯域幅、送信位置、変調符号化方式（ＭＣＳ：Modulation and Coding Scheme）など）を適切に制御する必要がある。
【００３５】
帯域幅及び送信位置については、ｅＭＢＢデータに割り当てられた帯域外にＵＲＬＬＣデータをマッピングする場合、他ユーザ又は他チャネルに対する干渉となる可能性があるため、ＵＲＬＬＣデータの帯域幅及び送信位置は、ｅＭＢＢデータに割り当てられた帯域の範囲内に限定されてもよい。一方、ｅＭＢＢデータに割り当てられた帯域内に限定した結果、ＵＲＬＬＣデータの送信期間が長くなる場合には、遅延の観点から、ｅＭＢＢデータに割り当てられた帯域の範囲外におけるＵＲＬＬＣデータの送信も許容してもよい。
【００３６】
送信電力については、特に上りリンクにおいて、突発的に発生するＵＲＬＬＣデータに対する長周期の送信電力制御（ＴＰＣ：Transmission Power Control）は困難である。しかし、高信頼性を担保するために、最適な送信電力制御が行われる必要がある。例えば、ＵＲＬＬＣデータの送信電力は、基地局ｅＮＢと移動局ＵＥとの間の閉ループによる送信電力制御ではなく、ｅＭＢＢデータの送信電力に基づいて決定されてもよい。また、ＵＲＬＬＣデータの受信品質向上のため、ＵＲＬＬＣデータに送信電力を優先的に割り当ててもよい。
【００３７】
ＭＣＳについては、突発的に発生するＵＲＬＬＣデータに対するＡＭＣ（Adaptive Modulation and channel Coding）のような閉ループ型の制御は困難である。一方、ｅＭＢＢデータは、例えば１０−１程度のパケット誤り率が要求されるのに対し、ＵＲＬＬＣデータは、例えば１０−５程度の初回パケット要求率が要求される。ＵＲＬＬＣデータに対しては、高信頼性を担保するために、要求されるパケット誤り率を達成できるＭＣＳが選択される必要がある。例えば、ＵＲＬＬＣデータのＭＣＳは、事前に基地局ｅＮＢから移動局ＵＥに通知されてもよく、移動局ＵＥが自律的に決定してもよく、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係を定義しておき、この対応関係を参照してｅＭＢＢデータのＭＣＳに基づいて決定されてもよい。また、送信電力制御との関係を考慮して、下りにおけるＵＲＬＬＣデータのＭＣＳは、所定のＭＣＳに限定されてもよい。また、下りにおけるＵＲＬＬＣデータのＭＣＳは、基地局ｅＮＢにおいて決定され、参照信号との送信電力差を示す情報と共に移動局ＵＥに通知されてもよい。
【００３８】
＜処理手順＞
図３は、本発明の実施例に係る無線通信システムにおける無線通信方法のシーケンス図である。
【００３９】
まず、基地局ｅＮＢは、ＵＲＬＬＣデータの送信パラメータの決定方法を移動局ＵＥに通知（例えば、ブロードキャスト）してもよい（Ｓ１０１）。例えば、帯域幅及び送信位置の決定方法には、ｅＭＢＢデータに割り当てられた帯域の範囲内にＵＲＬＬＣデータの帯域幅及び送信位置を限定するか、ｅＭＢＢデータに割り当てられた帯域の範囲外におけるＵＲＬＬＣデータの送信も許容するかが存在する。基地局ｅＮＢは、これらの帯域幅及び送信位置の決定方法のうちどちらを使用するかを移動局ＵＥに通知してもよい。例えば、ＵＲＬＬＣデータの送信電力の決定方法には、基地局ｅＮＢにおけるＰＳＤ（Power Spectral Density）がｅＭＢＢデータと同程度となるように制御するか、移動局ＵＥの総送信電力がｅＭＢＢデータと同程度となるように制御するかが存在する。基地局ｅＮＢは、これらの送信電力の決定方法のうちどちらを使用するかを移動局ＵＥに通知してもよい。例えば、ＵＲＬＬＣデータのＭＣＳの決定方法には、事前に基地局ｅＮＢが決定したＭＣＳを移動局ＵＥに通知するか、移動局ＵＥが自律的に決定するか、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係を参照してｅＭＢＢデータのＭＣＳに基づいて決定するかが存在する。基地局ｅＮＢは、これらのＭＣＳの決定方法のうちどれを使用するかを移動局ＵＥに通知してもよい。また、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係が用いられる場合、基地局ｅＮＢは、この対応関係を移動局ＵＥに通知してもよい。なお、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係は、移動局ＵＥから基地局ｅＮＢに通知することも可能である。
【００４０】
移動局ＵＥは、送信すべきｅＭＢＢデータが発生した場合、基地局ｅＮＢに対してＳＲを送信し、リソースの割り当てを基地局ｅＮＢに要求してもよい。基地局ｅＮＢは、リソースの割り当てを移動局ＵＥに通知し、移動局ＵＥは、基地局ｅＮＢの制御（スケジューリング、送信電力制御、ＡＭＣなど）により、ｅＭＢＢデータの送信パラメータ（送信電力、帯域幅、送信位置、ＭＣＳなど）を決定する（Ｓ１０３）。
【００４１】
移動局ＵＥは、ｅＭＢＢデータの送信パラメータを用いて、複数のシンボルに渡ってｅＭＢＢデータを送信してもよい（Ｓ１０５、Ｓ１０５'、...）。
【００４２】
ｅＭＢＢデータの送信中にＵＲＬＬＣデータが発生した場合、移動局ＵＥは、ｅＭＢＢデータの送信に割り当てられたリソースの一部をパンクチャする（Ｓ１０７）。移動局ＵＥは、基地局ｅＮＢからＵＲＬＬＣデータの送信パラメータの決定方法が通知されている場合には、通知された決定方法に従ってＵＲＬＬＣデータの送信パラメータを決定する。或いは、移動局ＵＥは、自律的にＵＲＬＬＣデータの送信パラメータを決定してもよい。
【００４３】
まず、ＵＲＬＬＣデータの送信パラメータのうち帯域幅及び送信位置について説明する。
【００４４】
図４は、ｅＭＢＢデータの帯域内でＵＲＬＬＣデータを送信する一例を示す図である。図３に示すような上りにおけるＵＲＬＬＣデータの送信の場合、ｅＭＢＢデータに割り当てられた帯域外にＵＲＬＬＣデータをマッピングする場合、他ユーザ又は他チャネルに対する干渉となる可能性があるため、ＵＲＬＬＣデータの帯域幅及び送信位置は、ｅＭＢＢデータに割り当てられた帯域の範囲内に限定されてもよい。図４は、ｅＭＢＢデータに割り当てられた帯域幅の一部でＵＲＬＬＣデータを送信する例を示しているが、ｅＭＢＢデータに割り当てられた帯域幅の全部でＵＲＬＬＣデータを送信してもよい。
【００４５】
なお、下りにおけるＵＲＬＬＣデータの送信の場合、基地局ｅＮＢは全ての移動局ＵＥのリソース割り当てを制御できるため、下りのＵＲＬＬＣデータの帯域幅及び送信位置は、ｅＭＢＢデータに割り当てられた帯域の範囲内に限定されなくてもよい。
【００４６】
一方、ｅＭＢＢデータに割り当てられた帯域内に限定した結果、ＵＲＬＬＣの送信期間が長くなる場合には、遅延の観点から、ｅＭＢＢデータに割り当てられた帯域の範囲外におけるＵＲＬＬＣデータの送信も許容してもよい。図５Ａは、ｅＭＢＢデータの帯域内でＵＲＬＬＣデータを送信する場合を示す図であり、図５Ｂは、ｅＭＢＢデータの帯域内及び帯域外でＵＲＬＬＣデータを送信する場合を示す図である。例えば、ｅＭＢＢデータの割り当て帯域幅が狭く、ＵＲＬＬＣデータのデータ量が多い場合、図５Ａに示すように、ＭＢＢデータに割り当てられた帯域幅の全部でＵＲＬＬＣデータを送信したとしても、ＵＲＬＬＣデータの送信に要する時間が長くなり、低遅延に対する要求条件を満たすことができない可能性がある。このような場合、図５Ｂに示すように、ｅＭＢＢデータに割り当てられた帯域の範囲外におけるＵＲＬＬＣデータの送信を許容してもよい。
【００４７】
このように、移動局ＵＥは、基地局ｅＮＢから通知されたＵＲＬＬＣデータの送信パラメータの決定方法に従って、或いは自律的に、ｅＭＢＢデータに割り当てられた帯域の範囲内にＵＲＬＬＣデータの帯域幅及び送信位置を限定するか、ｅＭＢＢデータに割り当てられた帯域の範囲外におけるＵＲＬＬＣデータの送信も許容するかを決定してもよい。例えば、ｅＭＢＢデータに割り当てられた帯域の範囲内にＵＲＬＬＣデータの帯域幅及び送信位置を限定するか、ｅＭＢＢデータに割り当てられた帯域の範囲外におけるＵＲＬＬＣデータの送信も許容するかは、ｅＭＢＢデータに割り当てられた帯域幅及び／又はＵＲＬＬＣデータのデータ量に基づいて決定されてもよい。
【００４８】
次に、ＵＲＬＬＣデータの送信パラメータのうち送信電力について説明する。図３に示すような上りにおけるＵＲＬＬＣデータの送信の場合、ＵＲＬＬＣデータの送信電力は、ｅＭＢＢデータの送信電力に基づいて決定されてもよい。例えば、ＵＲＬＬＣデータの送信電力は、基地局ｅＮＢにおけるＰＳＤ（Power Spectral Density）がｅＭＢＢデータと同程度となるように制御されてもよく（パターン１と呼ぶ）、移動局ＵＥの総送信電力がｅＭＢＢデータと同程度となるように制御されてもよい（パターン２と呼ぶ）。
【００４９】
図６は、ＵＲＬＬＣデータの送信電力制御の一例を示す図である。図６では、基地局ｅＮＢにおけるＰＳＤが一定となるように送信電力が制御されている（パターン１に相当する）。このときの送信電力の具体的な算出方法の例について説明する。ｅＭＢＢデータ及びＵＲＬＬＣデータのＯＦＤＭシンボル毎の総送信電力を、それぞれPeMBB及びPURLLCとする。PeMBBの算出方法は既知とし、例えば、PeMBBは以下の式に従ってシンボル毎に算出されてもよい。
【００５０】
PeMBB=10log10(MPUSCH)+PO_PUSCH+α・PL+ΔTF(TF(i))+f(i)      （１）
ここで、MPUSCHは、送信リソースブロック数（送信帯域幅）であり、PO_PUSCHは、目標受信レベルであり、αは、セル固有の送信電力制御用パラメータであり、PLは、下りのパスロスであり、ΔTF(TF(i))は、送信フォーマットに依存した電力オフセットであり、f(i)は送信電力制御コマンドの累積値である。ただし、PeMBB≦PCMAX（移動局ＵＥの最大送信電力）であり、f(i)の加算により移動局ＵＥの最大送信電力を超える場合には、PCMAXが用いられる。
【００５１】
パターン１の場合、ＵＲＬＬＣデータの送信電力PURLLCは、以下の式に従って算出されてもよい。
【００５２】
PURLLC=PeMBB×(BWURLLC／BWeMBB)      （２）
ここで、BWURLLCはＵＲＬＬＣデータの送信帯域幅であり、BWeMBBはｅＭＢＢデータの送信帯域幅である。
【００５３】
また、パターン２の場合の送信電力の具体的な算出方法については、上記のように、ｅＭＢＢデータ及びＵＲＬＬＣデータのＯＦＤＭシンボル毎の総送信電力を、それぞれPeMBB及びPURLLCとし、PeMBBの算出方法を既知とした場合、ＵＲＬＬＣデータの送信電力PURLLCは、以下の式に従って算出されてもよい。
【００５４】
PURLLC=PeMBB×(BWeMBB／BWURLLC)      （３）
ここで、図４に示すようにｅＭＢＢデータに割り当てられた帯域幅の一部でＵＲＬＬＣデータを送信する場合、すなわち、BWeMBB＞BWURLLCの場合、ＵＲＬＬＣデータと同じシンボルで送信されるｅＭＢＢデータの送信電力は、PeMBB−PURLLCと算出される。
【００５５】
上記のように、ＵＲＬＬＣデータの送信電力PURLLCをｅＭＢＢデータの送信電力PeMBBに基づいて算出することができるが、ＵＲＬＬＣデータは緊急度の高いデータであるため、総送信電力の範囲内で、他のデータよりも送信電力を優先的に割り当ててもよい。例えば、BWeMBB＞BWURLLCの場合、ＵＲＬＬＣデータが埋め込まれたシンボルにおけるｅＭＢＢデータの送信電力はゼロに設定されてもよい。このように、ＵＲＬＬＣデータに送信電力を優先的に割り当てることで、ＵＲＬＬＣデータの受信品質を向上させることが可能になる。
【００５６】
或いは、ＵＲＬＬＣデータの受信品質の向上のため、ＵＲＬＬＣデータの送信電力をオフセットしてもよい。例えば、上記の式（２）及び（３）はそれぞれ以下のように表現されてもよい。
【００５７】
PURLLC=PeMBB×(BWURLLC／BWeMBB)+δ      （２'）
PURLLC=PeMBB×(BWeMBB／BWURLLC)+δ      （３'）
ここで、δはオフセット値である。
【００５８】
上記のＵＲＬＬＣデータの送信電力の算出方法は単なる例であり、ＵＲＬＬＣデータの送信電力は他の方式で算出されてもよい。例えば、ｅＭＢＢデータの送信電力を算出する上記の式（１）を利用して、ＵＲＬＬＣデータの送信電力は、MPUSCHにＵＲＬＬＣデータの帯域幅を使用しつつ、MPUSCH以外のパラメータを同様に使用することにより求められてもよい。
【００５９】
なお、下りにおけるＵＲＬＬＣデータの送信の場合、移動局ＵＥは、データ信号と参照信号（ＲＳ）との送信電力差を示す情報を基地局ｅＮＢから受信し、データ信号を復調する。ＵＲＬＬＣデータに対して、高次変調（例えば、１６ＱＡＭなど）を用いる場合、移動局ＵＥは、上記の送信電力差を知らなければ復調精度が劣化する可能性がある。このため、ＵＲＬＬＣに適用する変調方式を、低次変調のような所定の変調方式に限定してもよい。低次変調とは、移動局ＵＥが参照信号との送信電力差を知らなくてもデータ信号を復調することができる変調方式であり、例えば、ＱＰＳＫ、ＢＰＳＫなどが含まれてもよい。なお、低次変調に限定していることは、例えば、Ｌ１／Ｌ２制御情報又はブロードキャスト情報により、基地局ｅＮＢから移動局ＵＥに通知してもよい。また、オーバーヘッドの低減のため、ＵＲＬＬＣデータの変調方式を１つ（例えば、ＱＰＳＫ）に限定してもよい。
【００６０】
或いは、基地局ｅＮＢは、例えば、Ｌ１／Ｌ２制御情報又はブロードキャスト情報により、ＵＲＬＬＣデータの変調方式と、参照信号との送信電力差を示す情報とを移動局ＵＥに通知してもよい。ＵＲＬＬＣデータの変調方式と、参照信号との送信電力差を示す情報とは、異なる周期で通知されてもよく、同じ周期で通知されてもよい。例えば、変調方式は、下りＬ１／Ｌ２制御情報によりサブフレーム毎に通知されてもよく、送信電力差を示す情報は、ＲＲＣシグナリング又はブロードキャスト情報により通知されてもよい。また、ＵＲＬＬＣデータがｅＭＢＢデータと同一の参照信号を使うことを前提として、ｅＭＢＢデータの送信電力の差分が通知されてもよい。また、ＵＲＬＬＣデータの送信電力と、ｅＭＢＢデータの送信電力との比又は差が予め設定されてもよい（例えば、ＵＲＬＬＣデータの送信電力は、ｅＭＢＢデータの送信電力の２倍に設定されてもよい）。
【００６１】
このように、移動局ＵＥは、基地局ｅＮＢから通知されたＵＲＬＬＣデータの送信パラメータの決定方法に従って、或いは自律的に、ＵＲＬＬＣデータの送信電力を決定してもよい。
【００６２】
次に、ＵＲＬＬＣデータの送信パラメータのうちＭＣＳについて説明する。
【００６３】
ＵＲＬＬＣデータにとって最適なＭＣＳが選択されるように、ＵＲＬＬＣデータのＭＣＳは、事前に基地局ｅＮＢから移動局ＵＥに通知されてもよい。
【００６４】
或いは、オーバーヘッドの低減のため、移動局ＵＥは、ＭＣＳを自律的に決定してもよい。移動局ＵＥがＭＣＳを自律的に決定した場合、決定したＭＣＳは、ＵＲＬＬＣデータの送信パケットの一部に制御情報として含めて基地局ｅＮＢに通知されてもよい。また、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係を定義しておき、移動局ＵＥは、この対応関係を参照して、ｅＭＢＢデータのＭＣＳに基づいてＵＲＬＬＣデータのＭＣＳを決定してもよい。図７は、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係の一例を示す図である。図７に示す対応関係は、基地局ｅＮＢ及び移動局ＵＥに予め設定されてもよく、基地局ｅＮＢから移動局ＵＥにブロードキャストされてもよく、又は、移動局ＵＥから基地局ｅＮＢへ或いは基地局ｅＮＢから移動局ＵＥへ予め通知されてもよい。
【００６５】
また、ＵＲＬＬＣデータの送信に用いるＭＣＳの変調方式及び符号化率は、ｅＭＢＢデータの送信に用いるＭＣＳの変調方式及び符号化率と同一でもよいし、要求条件に応じてｅＭＢＢデータの送信に用いるＭＣＳの変調方式及び符号化率とは別に定義されてもよい。別々に定義される場合、基地局ｅＮＢ及び移動局ＵＥは、ｅＭＢＢデータとＵＲＬＬＣデータで同一のＭＣＳ番号を用いることを想定してもよい。
【００６６】
なお、下りにおけるＵＲＬＬＣデータの送信の場合も同様に、基地局ｅＮＢは事前に移動局ＵＥに通知したＭＣＳを選択してもよく、ＭＣＳを自律的に決定してもよく、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係に基づいてＭＣＳを決定してもよい。
【００６７】
なお、送信電力の制御において説明した通り、下りにおけるＵＲＬＬＣデータのＭＣＳは、所定のＭＣＳに限定されてもよい。
【００６８】
このように、移動局ＵＥは、基地局ｅＮＢから通知されたＵＲＬＬＣデータの送信パラメータの決定方法に従って、或いは自律的に、ＵＲＬＬＣデータのＭＣＳを決定してもよい。
【００６９】
移動局ＵＥは、パンクチャされた部分において、ＵＲＬＬＣデータの送信パラメータを用いてＵＲＬＬＣデータを送信する（Ｓ１０９）。移動局ＵＥは、複数のシンボルに渡ってＵＲＬＬＣデータを送信してもよい（Ｓ１０９、Ｓ１０９'、...）。なお、移動局ＵＥは、ＵＲＬＬＣデータを送信するためのリソースを基地局ｅＮＢに要求し、基地局ｅＮＢによって割り当てられたリソースでＵＲＬＬＣデータを送信してもよく、ＵＲＬＬＣデータを送信するためのリソースを基地局ｅＮＢに要求せずにＵＲＬＬＣデータを送信してもよい。
【００７０】
基地局ｅＮＢがＵＲＬＬＣデータのリソースを割り当てている場合には、基地局ｅＮＢは、割り当てたリソースにおいてＵＲＬＬＣデータを受信することができる。一方、基地局ｅＮＢがＵＲＬＬＣデータのリソースを割り当てていない場合には、基地局ｅＮＢは、ｅＭＢＢデータの送信中にＵＲＬＬＣデータが埋め込まれて送信されることを検出する必要がある。例えば、ＵＲＬＬＣデータが埋め込まれる候補を事前に定義しておき、基地局ｅＮＢが候補内でブラインド推定を行って検出してもよい。この場合、ＵＲＬＬＣのＣＲＣ（Cyclic Redundancy Check）を用いて検出が行われてもよく、より容易な検出のためのプリアンブルをＵＲＬＬＣデータに付加することにより検出が行われてもよい。
【００７１】
移動局ＵＥがＵＲＬＬＣデータの送信を終えると、移動局ＵＥは、ｅＭＢＢデータの送信を再開してもよい（Ｓ１１１、Ｓ１１１'、...）。
【００７２】
図３では、移動局ＵＥから基地局ｅＮＢへの上りの通信が示されているが、本発明は、上りの通信に限定されず、基地局ｅＮＢから移動局ＵＥへの下りの通信にも適用可能である。下りの通信の場合には、移動局ＵＥがｅＭＢＢデータ及び／又はＵＲＬＬＣデータを送信するためのリソースを基地局ｅＮＢに要求する代わりに、基地局ｅＮＢがスケジューリングによって割り当てたリソースでｅＭＢＢデータ及び／又はＵＲＬＬＣデータが送信される。下りの通信の場合のＵＲＬＬＣデータの送信パラメータ（例えば、送信電力、帯域幅、送信位置、ＭＣＳ）については、前述の通り決定される。
【００７３】
＜機能構成＞
上記のように、本発明は、上りの通信に限定されず、下りの通信にも適用可能であるため、ｅＭＢＢデータ及びＵＲＬＬＣデータを送信する装置である送信機と、ｅＭＢＢデータ及びＵＲＬＬＣデータを受信する装置である受信機とについて説明する。
【００７４】
図８は、本発明の実施例に係る送信機１０の構成図である。
【００７５】
送信機１０は、ｅＭＢＢデータ生成部１０１と、ＵＲＬＬＣデータ生成部１０３と、送信パラメータ決定部１０５と、送信部１０７とを有する。下りの通信の場合、送信機１０は基地局ｅＮＢに対応し、この場合、送信機１０は、ＵＲＬＬＣデータの送信パラメータの決定方法を移動局ＵＥに通知するための送信パラメータ決定方法通知部１０９を更に有してもよい。
【００７６】
ｅＭＢＢデータ生成部１０１は、ｅＭＢＢで送信されるデータ（ｅＭＢＢデータ）を生成する。送信機１０が移動局ＵＥに含まれる場合、ｅＭＢＢデータは、移動局ＵＥからのＳＲに応じて基地局ｅＮＢによって割り当てられたリソースを用いて送信されてもよい。送信機１０が基地局ｅＮＢに含まれる場合、ｅＭＢＢデータは、基地局ｅＮＢ内のスケジューリングで割り当てたリソースを用いて送信されてもよい。
【００７７】
ＵＲＬＬＣデータ生成部１０３は、ＵＲＬＬＣで送信されるデータ（ＵＲＬＬＣデータ）を生成する。送信機１０が移動局ＵＥに含まれる場合、ＵＲＬＬＣデータは、移動局ＵＥからのＳＲに応じて基地局ｅＮＢによって割り当てられたリソースを用いて送信されてもよく、移動局ＵＥからのＳＲなしに事前に定義されたリソースの候補の中で送信されてもよい。送信機１０が基地局ｅＮＢに含まれる場合、ｅＭＢＢデータは、基地局ｅＮＢ内のスケジューリングで割り当てたリソースを用いて送信されてもよく、基地局ｅＮＢ内のスケジューリングなしに事前に定義されたリソースの候補の中で送信されてもよい。
【００７８】
送信パラメータ決定部１０５は、ｅＭＢＢデータの送信パラメータと、ＵＲＬＬＣデータの送信パラメータとを決定する。例えば、送信パラメータ決定部１０５は、基地局ｅＮＢの制御（スケジューリング、送信電力制御、ＡＭＣなど）により、ｅＭＢＢデータの送信電力、帯域幅、送信位置、変調符号化方式などの送信パラメータを決定する。また、送信パラメータ決定部１０５は、ｅＭＢＢデータの送信に割り当てられた帯域の範囲内で、ＵＲＬＬＣデータの帯域幅及び送信位置を決定してもよく、ｅＭＢＢデータの送信に割り当てられた帯域の範囲内だけでなく範囲外も含めて、ＵＲＬＬＣデータの帯域幅及び送信位置を決定してもよい。また、送信パラメータ決定部１０５は、ｅＭＢＢデータの送信電力に基づいてＵＲＬＬＣデータの送信電力を決定してもよく、ＵＲＬＬＣデータの受信品質の向上のため、ＵＲＬＬＣデータに送信電力を優先的に割り当ててもよい。また、送信パラメータ決定部１０５は、基地局ｅＮＢにより事前に決定したＭＣＳを選択してもよく、自律的にＭＣＳを決定してもよく、例えば、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係を参照して、ｅＭＢＢデータのＭＣＳに基づいてＵＲＬＬＣデータのＭＣＳを決定してもよい。
【００７９】
送信部１０７は、ｅＭＢＢデータの送信中にＵＲＬＬＣデータが生成された場合、ｅＭＢＢの送信に割り当てられたリソースの一部をパンクチャし、パンクチャされていない部分においてｅＭＢＢデータを送信し、パンクチャされた部分においてＵＲＬＬデータを送信する。
【００８０】
図９は、本発明の実施例に係る受信機２０の構成図である。
【００８１】
受信機２０は、検出部２０１と、送信パラメータ決定部２０３と、受信部２０５とを有する。上りの通信の場合、受信機２０は基地局ｅＮＢに対応し、この場合、受信機２０は、ＵＲＬＬＣデータの送信パラメータの決定方法を移動局ＵＥに通知するための送信パラメータ決定方法通知部２０７を更に有してもよい。
【００８２】
検出部２０１は、ｅＭＢＢデータの送信に割り当てられたリソースの一部がパンクチャされ、パンクチャされた部分において、ＵＲＬＬＣデータが送信されることを検出する。基地局ｅＮＢがリソースを割り当てている場合には、検出部２０１は、そのリソースの割り当てに基づいてＵＲＬＬＣデータの送信を検出してもよい。また、検出部２０１は、ＵＲＬＬＣデータが埋め込まれる候補内でブラインド推定を行うことにより、ＵＲＬＬデータの送信を検出してもよい。
【００８３】
送信パラメータ決定部２０３は、ｅＭＢＢデータの送信パラメータと、ＵＲＬＬＣデータの送信パラメータとを決定する。例えば、送信パラメータ決定部１０５は、基地局ｅＮＢの制御（スケジューリング、送信電力制御、ＡＭＣなど）により、ｅＭＢＢデータの送信電力、帯域幅、送信位置、変調符号化方式などの送信パラメータを決定する。また、送信パラメータ決定部１０５は、ＵＲＬＬＣデータの送信パラメータの決定方法に従って、ＵＲＬＬＣデータの帯域幅及び送信位置を決定してもよい。また、送信パラメータ決定部１０５は、参照信号との送信電力差を示す情報に基づいて、下りのＵＲＬＬＣデータの送信電力を決定してもよい。また、送信パラメータ決定部１０５は、基地局ｅＮＢにより事前に決定したＭＣＳを選択してもよく、移動局ＵＥが自律的に決定して通知したＭＣＳを選択してもよく、例えば、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係を参照して、ｅＭＢＢデータのＭＣＳに基づいてＵＲＬＬＣデータのＭＣＳを決定してもよい。
【００８４】
受信部２０５は、パンクチャされていない部分においてｅＭＢＢデータの送信パラメータを用いてｅＭＢＢデータを受信し、パンクチャされた部分においてＵＲＬＬＣデータの送信パラメータを用いてＵＲＬＬＣデータを受信する。
【００８５】
＜ハードウェア構成＞
なお、上記実施例の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。
【００８６】
例えば、本発明の一実施例における送信機、受信機などは、本発明の無線通信方法の処理を行うコンピュータとして機能してもよい。図１０は、本発明の実施例に係る送信機及び受信機のハードウェア構成の一例を示す図である。上述の送信機１０及び受信機２０は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
【００８７】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。送信機１０及び受信機２０のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【００８８】
送信機１０及び受信機２０における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信や、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。
【００８９】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。例えば、上述のｅＭＢＢデータ生成部１０１、ＵＲＬＬＣデータ生成部１０３、送信パラメータ決定部１０５、送信パラメータ決定方法通知部１０９、検出部２０１、送信パラメータ決定部２０３、送信パラメータ決定方法通知部２０７などは、プロセッサ１００１で実現されてもよい。
【００９０】
また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュールやデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施例で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、送信機１０のｅＭＢＢデータ生成部１０１は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。
【００９１】
メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施例に係る無線通信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。
【００９２】
ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact Disc ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク)、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。
【００９３】
通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、上述の送信部１０７、受信部２０５などは、通信装置１００４で実現されてもよい。
【００９４】
入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。
【００９５】
また、プロセッサ１００１やメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。
【００９６】
また、送信機１０及び受信機２０は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。
【００９７】
＜本発明の実施例の効果＞
本発明の実施例によれば、緊急度の高いデータと、他のデータとの干渉を低減しつつ、緊急度の高いデータを低遅延で送信することが可能になる。例えば、ｅＭＢＢデータの送信中に、緊急度の高いＵＲＬＬＣデータのパケットが発生した場合、ｅＭＢＢデータにＵＲＬＬＣデータを埋め込ませて送信することができ、ＵＲＬＬＣデータを低遅延で送信することが可能になる。
【００９８】
また、ＵＲＬＬＣデータの送信パラメータを適切に決定することにより、ＵＲＬＬＣデータの高信頼性を担保することが可能になる。例えば、ＵＲＬＬＣデータの送信電力をｅＭＢＢデータの送信電力に基づいて決定することにより、ＵＲＬＬＣデータの送信電力を基地局ｅＮＢと移動局ＵＥとの間の閉ループによる制御を必要とせず、迅速な送信電力制御が可能になる。例えば、ｅＭＢＢデータのＭＣＳとＵＲＬＬＣデータのＭＣＳとの対応関係を定義しておき、この対応関係に基づいてＵＲＬＬＣデータのＭＣＳを決定することにより、迅速なＭＣＳの決定が可能になる。一方、ＵＲＬＬＣデータのＭＣＳは、基地局ｅＮＢにより決定されてもよく、これにより、最適なＭＣＳが選択可能になる。
【００９９】
帯域幅及び送信位置については、ｅＭＢＢデータに割り当てられた帯域の範囲内に限定することで、他ユーザ又は他チャネルに対する干渉を低減することが可能になる。一方、ｅＭＢＢデータに割り当てられた帯域の範囲外におけるＵＲＬＬＣデータの送信も許容することにより、ＵＲＬＬＣデータの遅延を低減することが可能になる。
【０１００】
なお、受信機では、検出用のプリアンブルなどを定義しておくことにより、ｅＭＢＢデータの送信中にＵＲＬＬＣデータが送信されていることをブラインド検出することが可能になる。
【０１０１】
パンクチャは、ｅＭＢＢの情報ビットをＵＲＬＬＣの情報ビットでオーバーライドすることで実現されてもよく、この場合、受信機は、ｅＭＢＢデータの送信中にＵＲＬＬＣデータが送信されていることをブラインド検出する必要はなくなる。また、パンクチャは、ｅＭＢＢデータの変調次数を変更することによってｅＭＢＢデータの信号の一部を送信しないことで実現されてもよく、この場合、ｅＭＢＢデータが受信できなくなる可能性があるが、パンクチャによるｅＭＢＢデータのロスを無くすことができる。また、パンクチャは、ｅＭＢＢデータの変調次数は変更せず、ビットの一部がｅＭＢＢデータとＵＲＬＬＣデータで共有されることで実現されてもよく、この場合、ｅＭＢＢデータの検出精度を確保することができる。
【０１０２】
＜補足＞
本明細書で説明した各態様／実施例は、ＬＴＥ（Long Term Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future Radio Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra Mobile Broadband）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【０１０３】
本明細書で使用する「システム」および「ネットワーク」という用語は、互換的に使用される。
【０１０４】
本明細書において基地局によって行われるとした特定動作は、場合によってはその上位ノード（upper node）によって行われることもある。基地局を有する１つまたは複数のネットワークノード（network nodes）からなるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局および／または基地局以外の他のネットワークノード（例えば、ＭＭＥまたはＳ−ＧＷなどが考えられるが、これらに限られない）によって行われ得ることは明らかである。上記において基地局以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ（例えば、ＭＭＥおよびＳ−ＧＷ）であってもよい。
【０１０５】
情報等は、上位レイヤ（または下位レイヤ）から下位レイヤ（または上位レイヤ）へ出力され得る。複数のネットワークノードを介して入出力されてもよい。
【０１０６】
入出力された情報等は特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【０１０７】
情報の通知は、本明細書で説明した態様／実施例に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink Control Information）、ＵＣＩ（Uplink Control Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio Resource Control）シグナリング、ＭＡＣ（Medium Access Control）シグナリング、ブロードキャスト情報（ＭＩＢ（Master Information Block）、ＳＩＢ（System Information Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。
【０１０８】
判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。
【０１０９】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。
【０１１０】
また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）などの有線技術及び／又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。
【０１１１】
本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【０１１２】
なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及び／又はシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ）は、キャリア周波数、セルなどと呼ばれてもよい。
【０１１３】
また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。
【０１１４】
上述したパラメータに使用する名称はいかなる点においても限定的なものではない。さらに、これらのパラメータを使用する数式等は、本明細書で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素（例えば、ＴＰＣなど）は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的なものではない。
【０１１５】
本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【０１１６】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【０１１７】
本明細書で使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量または順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１および第２の要素への参照は、２つの要素のみがそこで採用され得ること、または何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。
【０１１８】
「含む（including）」、「含んでいる（comprising）」、およびそれらの変形が、本明細書あるいは請求の範囲で使用されている限り、これら用語は、用語「備える」と同様に、包括的であることが意図される。さらに、本明細書あるいは請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。
【０１１９】
本明細書で説明した各態様／実施例の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０１２０】
本明細書で説明した各態様／実施例は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【０１２１】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施例に限定されるものではないということは明らかである。本発明は、請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【０１２２】
本国際出願は２０１６年５月１０日に出願した日本国特許出願２０１６−０９４９４０号に基づく優先権を主張するものであり、２０１６−０９４９４０号の全内容を本国際出願に援用する。
【符号の説明】
【０１２３】
ｅＮＢ    基地局
ＵＥ      移動局
１０      送信機
１０１    ｅＭＢＢデータ生成部
１０３    ＵＲＬＬＣデータ生成部
１０５    送信パラメータ決定部
１０７    送信部
１０９    送信パラメータ決定方法通知部
２０      受信機
２０１    検出部
２０３    送信パラメータ決定部
２０５    受信部
２０７    送信パラメータ決定方法通知部
１００１  プロセッサ
１００２  メモリ
１００３  ストレージ
１００４  通信装置
１００５  入力装置
１００６  出力装置
１００７  バス
【図１】
2017195702.tif 000003
【図２】
2017195702.tif 000004
【図３】
2017195702.tif 000005
【図４】
2017195702.tif 000006
【図５Ａ】
2017195702.tif 000007
【図５Ｂ】
2017195702.tif 000008
【図６】
2017195702.tif 000009
【図７】
2017195702.tif 000010
【図８】
2017195702.tif 000011
【図９】
2017195702.tif 000012
【図１０】
2017195702.tif 000013
【国際調査報告】
2017195702.tif 000014
2017195702.tif 000015
2017195702.tif 000016