(57)【要約】  送信許可を受けることなく送信されるデータを低遅延且つ高信頼度で送信するための技術を提供することである。本発明の一態様は、所定のタイプの情報の送信イベントが発生したことに応答して、第１のタイプのリソースが割り当てられているか判定するリソース判定部と、前記第１のタイプのリソースが割り当てられている場合、送信許可を受けることなく、前記第１のタイプのリソースを用いて前記所定のタイプの情報を受信機に送信する送信部とを有する送信機に関する。
2017195763.tif 000002
【特許請求の範囲】
【請求項１】
所定のタイプの情報の送信イベントが発生したことに応答して、第１のタイプのリソースが割り当てられているか判定するリソース判定部と、
前記第１のタイプのリソースが割り当てられている場合、送信許可を受けることなく、前記第１のタイプのリソースを用いて前記所定のタイプの情報を受信機に送信する送信部と、
を有する送信機。
【請求項２】
前記第１のタイプのリソースが割り当てられていない場合、又は前記受信機が前記第１のタイプのリソースから前記所定のタイプの情報を検出できないと予想される場合、前記送信部は、前記所定のタイプの情報を送信するため設定されている第２のタイプのリソースを用いて前記所定のタイプの情報を前記受信機に送信する、請求項１記載の送信機。
【請求項３】
前記送信部は、前記受信機が前記第１のタイプのリソースから前記所定のタイプの情報を検出するための付加情報と共に前記所定のタイプの情報を前記受信機に送信する、請求項１又は２記載の送信機。
【請求項４】
前記送信部は、前記第１のタイプのリソース内に設定された候補リソースを用いて前記所定のタイプの情報を前記受信機に送信する、請求項１乃至３何れか一項記載の送信機。
【請求項５】
前記送信イベントの発生タイミングに応じて、前記送信部は、前記第１のタイプのリソースと前記所定のタイプの情報を送信するため設定されている第２のタイプのリソースとの双方を用いて前記所定のタイプの情報を前記受信機に送信する、請求項１乃至４何れか一項記載の送信機。
【請求項６】
第１のタイプのリソースを送信機に割り当てるリソース割当て部と、
前記送信機から第１のタイプのリソースを受信する受信部と、
前記送信機から受信した前記第１のタイプのリソースから、送信許可することなく送信された所定のタイプの情報を検出する検出部と、
を有する受信機。
【請求項７】
前記リソース割当て部は、前記第１のタイプのリソース内に前記所定のタイプの情報を送信するための候補リソースを設定する、請求項６記載の受信機。
【請求項８】
前記リソース割当て部は、前記第１のタイプのリソースの時間方向に関する終了部分に前記候補リソースを密に割り当てる、請求項７記載の受信機。
【請求項９】
前記検出部は、前記第１のタイプのリソースから前記所定のタイプの情報を検出するための付加情報に基づき、前記所定のタイプの情報を検出する、請求項６乃至８何れか一項記載の受信機。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムに関する。
【背景技術】
【０００２】
現在、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｉｃｔ）において、第４世代の無線通信システムの一つであるＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）−Ａｄｖａｎｃｅｄの後継にあたる５Ｇと呼ばれる次世代のシステムの検討が進んでいる。５Ｇでは、主にｅＭＢＢ（ｅｘｔｅｎｄｅｄ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）、ｍＭＴＣ(ｍａｓｓｉｖｅ  Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＵＲＬＬＣ（Ｕｌｔｒａ  Ｒｅｌｉａｂｉｌｉｔｙ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の３つのユースケースが想定されている（非特許文献１参照）。【０００３】
ＵＲＬＬＣでは、低遅延及び高信頼性の要求条件が求められている。低遅延伝送を実現するため、短いＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｔｉｍｅ  Ｉｎｔｅｒｖａｌ）長（サブフレーム長、サブフレーム間隔として参照されてもよい）の導入が検討されている。例えば、サブフレーム当たりのシンボル数が減少されたり、あるいは、サブキャリア間隔を大きくすることによってシンボル長が減少されてもよい。また、パケット生成からデータ送信までの制御遅延を短縮することが図られてもよい。一方、高信頼性を実現するためには、低ビット誤り率を実現する低符号化率の符号化又は変調方式の導入が検討されている。あるいは、ダイバーシチを活用するアプローチもある。【０００４】
ＵＲＬＬＣでは、緊急度の高い送信データが突然発生する可能性があり、このような突然発生したデータを低遅延且つ高信頼度で送信する必要がある。【０００５】
ユーザ装置において送信すべきデータが発生した場合、例えばＬＴＥのアップリンク通信では、はじめに基地局に対してＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）を送信し、リソースの割り当てを基地局に要求する。基地局は、アップリンク送信許可として、リソースの割り当てをユーザ装置に通知し、ユーザ装置は、基地局から指定されたリソースにおいてデータを送信する。しかしながら、ＵＲＬＬＣでは、上記の通り送信すべきデータが突然発生する可能性があり、上記のようなプロセスにてデータ送信を行う場合、低遅延の要求条件を満たせなくなる可能性がある。上記のため、ＵＲＬＬＣでは、基地局によるアップリンク送信許可を受けることなく、ユーザ装置から自律的にデータ送信されることが想定されている。この場合、アップリンク送信許可を受けることなく送信されるＵＲＬＬＣデータは、基地局によって送信リソースの制御がなされていないため、他のユーザ装置から送信されるデータと衝突する可能性がある。【０００６】
このような衝突型ＵＲＬＬＣでは、ユーザ装置は自律的に送信リソースを選択できるが、他のユーザ装置との干渉を低減するため、送信に利用可能なリソースがある程度限定されることが想定される。１つのアプローチとして、図１に示されるように、衝突型パケットのみを送信することが許可された衝突型リソースが定義され、ユーザ装置は、当該衝突型リソースを用いてＵＲＬＬＣパケットを送信することが想定される。なお、衝突型リソースのリソース位置は、例えば、ブロードキャスト信号などによってセミスタティックに通知されてもよい。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】ＲＰ−１６０６７１
【発明の概要】
【発明が解決しようとする課題】
【０００８】
衝突型リソースによりＵＲＬＬＣパケットが送信される場合、他のユーザ装置も衝突型パケット（例えば、ＵＲＬＬＣパケット）を送信する可能性がある。このため、衝突が発生した場合、互いの干渉によってＵＲＬＬＣパケットの高信頼性の要求条件を満たせない可能性がある。【０００９】
一方、他のアプローチとして、ＵＲＬＬＣパケット発生時に、ＵＲＬＬＣパケットとは異なる他のチャネルのためにアップリンク送信リソースが割り当てられている場合、当該チャネルの一部にＵＲＬＬＣパケットを埋め込み送信することが想定される。このようなチャネルとして、例えば、モバイルブロードバンドサービスに利用されるｅＭＢＢが考えられる。ＵＲＬＬＣパケットがｅＭＢＢに割り当てられたリソースにより送信される場合、少なくとも同一セル内では他のユーザ装置からの送信との大きな干渉は発生しないと考えられる。これは、ｅＭＢＢでは、端末間及びチャネル間の送信リソースが直交多重されていることが想定されるか、あるいは、複数の端末もしくはチャネルが同一の送信リソースにおいて非直交多重されているとしても、少なくともｅＭＢＢが検出できる程度に干渉量が制御されることが想定されるためである。従って、ＵＲＬＬＣデータの発生時、ｅＭＢＢリソースが割り当てられている場合、ユーザ装置は、高信頼性の要求条件を充足するため、衝突型リソースよりもｅＭＭＢリソースを用いてＵＲＬＬＣパケットを送信することが好ましい。【００１０】
上述した問題点を鑑み、本発明の課題は、送信許可を受けることなく送信されるデータを低遅延且つ高信頼度で送信するための技術を提供することである。
【課題を解決するための手段】
【００１１】
上記課題を解決するため、本発明の一態様は、所定のタイプの情報の送信イベントが発生したことに応答して、第１のタイプのリソースが割り当てられているか判定するリソース判定部と、前記第１のタイプのリソースが割り当てられている場合、送信許可を受けることなく、前記第１のタイプのリソースを用いて前記所定のタイプの情報を受信機に送信する送信部とを有する送信機に関する。【００１２】
本発明の他の態様は、第１のタイプのリソースを送信機に割り当てるリソース割当て部と、前記送信機から第１のタイプのリソースを受信する受信部と、前記送信機から受信した前記第１のタイプのリソースから、送信許可することなく送信された所定のタイプの情報を検出する検出部とを有する受信機に関する。
【発明の効果】
【００１３】
本発明によると、送信許可を受けることなく送信されるデータを低遅延且つ高信頼度で送信することができる。
【図面の簡単な説明】
【００１４】
【図１】図１は、ＵＲＬＬＣパケットの送信方式を示す概略図である。
【図２】図２は、本発明の一実施例による無線通信システムを示す概略図である。
【図３】図３は、本発明の一実施例による送信機の機能構成を示すブロック図である。
【図４】図４は、本発明の一実施例によるＵＲＬＬＣパケットの送信リソースを示す概略図である。
【図５】図５は、本発明の他の実施例によるＵＲＬＬＣパケットの送信リソースを示す概略図である。
【図６】図６は、本発明の一実施例によるＵＲＬＬＣパケットのＦＤＭによる送信リソースを示す概略図である。
【図７】図７は、本発明の一実施例によるＵＲＬＬＣパケットのＴＤＭによる送信リソースを示す概略図である。
【図８】図８は、本発明の一実施例による時間方向に密に配置されたＵＲＬＬＣパケットの候補リソースを示す概略図である。
【図９】図９は、本発明の一実施例による周波数方向に密に配置されたＵＲＬＬＣパケットの候補リソースを示す概略図である。
【図１０】図１０は、本発明の他の実施例によるＵＲＬＬＣパケットの候補リソースを示す概略図である。
【図１１】図１１は、本発明の他の実施例によるＵＲＬＬＣパケットの候補リソースを示す概略図である。
【図１２】図１２は、本発明の一実施例による受信機の機能構成を示すブロック図である。
【図１３】図１３は、本発明の一実施例による送信機及び受信機のハードウェア構成を示すブロック図である。
【発明を実施するための形態】
【００１５】
以下、図面に基づいて本発明の実施の形態を説明する。
【００１６】
以下の実施例では、ＵＲＬＬＣデータなどの低遅延且つ高信頼性が要求されるデータを送受信するための送信機及び受信機が開示される。後述される実施例を概略すると、送信機は、送信許可を受けることなくデータを送信するとき、受信機からすでに割り当てられているリソースを用いて当該データを送信する。これにより、送信許可を受けることなく送信可能な衝突型データを送信するため、他の送信機と共用される衝突型リソースを利用する従来方式と比較して、送信機は、受信機により割り当てられた他の送信機からの送信と干渉しないリソースを用いて、低遅延及び高信頼性が要求されるＵＲＬＬＣデータなどのデータを確実に送信することができる。
【００１７】
まず、図２を参照して、本発明の一実施例による無線通信システムを説明する。図２は、本発明の一実施例による無線通信システムを示す概略図である。
【００１８】
図２に示されるように、無線通信システム１０は、送信機１００及び受信機２００を有する。以下の実施例では、図示されるように、送信機１００はユーザ装置（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ：ＵＥ）であり、受信機２００は基地局（ｅｖｏｌｖｅｄ  ＮｏｄｅＢ：ｅＮＢ）であると想定される。しかしながら、本発明はこれに限定されず、送信機１００は基地局又は他の無線通信装置であり、受信機２００はユーザ装置又は他の無線通信装置であってもよい。また、送信機１００及び受信機２００の双方がユーザ装置であってもよく、この場合、これらユーザ装置間でデータが無線送受信されることになる。
【００１９】
以下の実施例では、ＵＲＬＬＣデータなどの低遅延且つ高信頼性が要求されるデータについて、送信機１００は、送信許可を受けることなく当該タイプのデータを送信することができる。例えば、送信機１００は、予め設定されている衝突型リソースを用いて、あるいは、受信機２００によって送信機１００にすでに割り当てられているｅＭＢＢなどのリソースを用いて、当該タイプのデータを送信可能である。
【００２０】
ここで、衝突型リソースとは、送信許可を受けることなく送信可能な衝突型パケットのみを送信することが許可されたリソースであり、例えば、図１に示されるようなリソース配置により設定されてもよい。典型的には、衝突型リソースは、基地局などの受信機２００によって設定され、ブロードキャスト情報において通知される。また、ｅＭＢＢなどの他の送信機との干渉のないリソースは、モバイルブロードバンドサービスなど当該タイプのデータの送信とは異なる用途向けに設定されたリソースであり、基地局などの受信機２００によって送信機１００に対して割り当てられる。上述したように、衝突型リソースは、送信機１００以外の送信機も利用可能であり、他の送信機による送信により干渉を受ける可能性がある。他方、ｅＭＢＢなどのリソースは、他の送信機からの送信による干渉を受けないように受信機２００によって割り当てられており、送信機１００は、このような他の送信機からの送信による干渉のないリソースを用いることによって、衝突型リソースよりも高い信頼度でデータを送信することができる。
【００２１】
なお、以下の実施例では、衝突型リソースとｅＭＢＢなどの干渉のない割当て済みのリソースとの一方又は双方を用いたＵＲＬＬＣデータの送信を説明するが、本発明はこれら２つのタイプのリソースに限定されるものでなく、他のタイプのリソースが利用されてもよい。例えば、ｅＭＢＢの代わりに、ｍＭＴＣ、ＬＴＥ、ＬＴＥ−Ａｄｖａｎｃｅｄ、ＬＡＡ（Ｌｉｃｅｎｓｅ  Ａｓｓｉｓｔｅｄ  Ａｃｃｅｓｓ）などの他のサービスのためのリソースが、割当て済みリソースとして使用されてもよい。また、送信許可を受けることなく送信可能なデータは、ＵＲＬＬＣに限定されず、他のタイプのデータであってもよい。
【００２２】
次に、図３を参照して、本発明の一実施例による送信機を説明する。図３は、本発明の一実施例による送信機の機能構成を示すブロック図である。
【００２３】
図３に示されるように、送信機１００は、リソース判定部１１０及び送信部１２０を有する。
【００２４】
リソース判定部１１０は、所定のタイプの情報の送信イベントが発生したことに応答して、第１のタイプのリソースが割り当てられているか判定する。具体的には、低遅延且つ高信頼性が要求されるＵＲＬＬＣデータの送信が必要になると、リソース判定部１１０は、ｅＭＢＢなどの他の送信機との干渉のないリソースが受信機２００によって割り当て済みであり、受信機２００への送信に利用可能であるか判定する。
【００２５】
送信部１２０は、第１のタイプのリソースが割り当てられている場合、送信許可を受けることなく、第１のタイプのリソースを用いて所定のタイプの情報を受信機２００に送信する。具体的には、干渉のないリソースが割り当てられている場合、図４に示されるように、送信部１２０は、ＵＲＬＬＣデータの送信に対する送信許可を受けることなく、当該干渉のないリソースにＵＲＬＬＣパケットを埋め込むことによって、干渉のないリソースにおいてＵＲＬＬＣデータを受信機２００に送信する。
【００２６】
上述したように、ｅＭＢＢなどの他の送信機からの送信と干渉のないリソースは、衝突型リソースより高い信頼度でデータを受信機２００に送信できる。このため、送信機１００においてＵＲＬＬＣデータの送信が必要になると、リソース判定部１１０は、ｅＭＢＢなどの干渉のないリソースが送信機１００に割当て済みであるか判断し、干渉のないリソースがすでに割当てられている場合、送信部１２０は、衝突型リソースよりも優先的に割り当てられている干渉のないリソースを利用してＵＲＬＬＣデータを送信する。これにより、送信機１００は、ＵＲＬＬＣデータを低遅延且つ高信頼度で送信することができる。
【００２７】
ここで、ｅＭＢＢを用いてＵＲＬＬＣパケットを送信する場合、送信部１２０は、例えば、ｅＭＢＢの送信シンボルの全て又は一部をパンクチャ（無送信）し、パンクチャされた部分にＵＲＬＬＣパケットを埋め込むことによって、ＵＲＬＬＣデータを送信できる。この場合、ｅＭＢＢにとって重要度の高い信号（例えば、Ｌ１／Ｌ２制御信号、ブロードキャスト情報、同期信号、データ復調用参照信号、送達確認、データ復調用参照信号、スケジューリングリクエスト）はパンクチャされるべきでなく、送信部１２０は、例えば、データ信号、品質測定用参照信号、チャネル状態情報、品質測定用参照信号などの相対的に優先度の低い信号をパンクチャし、パンクチャされた部分にＵＲＬＬＣを埋め込むことが好ましい。
【００２８】
あるいは、ｅＭＢＢの送信シンボルをパンクチャする代わりに、送信部１２０は、ｅＭＢＢの情報ビットをＵＲＬＬＣの情報ビットで上書きしてもよい。例えば、送信部１２０は、ｅＭＢＢの一部の符号セグメントをＵＲＬＬＣの情報ビットのために利用してもよい。また、送信部１２０は、ｅＭＢＢの変調次数を変更することによってＵＲＬＬＣの情報ビットを埋め込んでもよい。例えば、送信部１２０は、ｅＭＢＢの変調方式をＱＰＳＫ（２ビット）から１６ＱＡＭ（４ビット）に変更し、余剰となる２ビットにＵＲＬＬＣの情報ビットを埋め込んでもよい。また、送信部１２０は、ｅＭＢＢの変調次数を変更することなく、ビットの一部をｅＭＢＢデータとＵＲＬＬＣデータとで共有してもよい。例えば、ＱＰＳＫの場合、送信部１２０は、送信用の２ビットの内で前半の１ビットをｅＭＭＢデータに使用し、後半の１ビットをＵＲＬＬＣデータに使用してもよい。
【００２９】
送信部１２０は、ｅＭＢＢリソースに埋め込まれたＵＲＬＬＣの送信パワー、送信帯域幅、送信位置、変調符号化方式（ＭＣＳ）などの各種送信パラメータを決定し、当該送信パラメータに従ってＵＲＬＬＣデータを受信機２００に送信する。具体的には、送信パワーについては、ＵＲＬＬＣデータは突発的に発生するため、長周期の送信パワー制御（ＴＰＣ）は困難である。しかしながら、高信頼性を担保するため、最適なＴＰＣが利用されることが望ましい。また、送信帯域幅及び送信位置については、ｅＭＢＢに対して割り当てられたリソースの外部にＵＲＬＬＣデータがマッピングされると、他の送信機に対する干渉となる可能性がある。このため、送信帯域幅及び送信位置は、ｅＭＢＢに対して割り当てられた帯域内に限定されることが望ましい。一方、後述されるように、ｅＭＢＢリソースの帯域外であっても送信を行うことが遅延の観点でメリットがある場合もある。ＭＣＳについては、ＵＲＬＬＣデータは突発的に発生するため、ＡＭＣ（Ａｄａｐｔｉｖｅ  Ｍｏｄｕｌａｔｉｏｎ  ａｎｄ  Ｃｈａｎｎｅｌ  Ｃｏｄｉｎｇ）のような閉ループ型の制御は困難であるが、要求されるパケット誤り率（例えば、パケット誤り率＝１０−５）を実現する必要がある。
【００３０】
他方、第１のタイプのリソースが割り当てられていない場合、又は受信機２００が第１のタイプのリソースから所定のタイプの情報を検出できないと予想される場合、送信部１２０は、所定のタイプの情報を送信するため設定されている第２のタイプのリソースを用いて所定のタイプの情報を受信機２００に送信してもよい。すなわち、送信機１００に対してｅＭＢＢリソースが割り当てられていない場合、図５に示されるように、送信部１２０は、ＵＲＬＬＣパケットなどの衝突型パケットを送信するため設定されている衝突型リソースを用いてＵＲＬＬＣデータを受信機２００に送信してもよい。また、送信機１００に対してｅＭＢＢリソースが割り当てられているが、受信機２００がｅＭＢＢリソースに埋め込まれたＵＲＬＬＣパケットを検出することが困難であると予想される場合、例えば、ｅＭＢＢに割りあてられたリソースが少なく、ＵＲＬＬＣの符号化率が所定の値（例えば０．９３１）を超える場合、送信部１２０は、同様に衝突型リソースを用いてＵＲＬＬＣデータを受信機２００に送信してもよい。あるいは、ｅＭＢＢリソースにＵＲＬＬＣパケットを埋め込んだことにより、受信機２００がｅＭＢＢパケットを検出することが困難であることが想定される場合、例えばｅＭＢＢの符号化率が所定の値（例えば０．９３１）を超える場合、送信部１２０は、同様に衝突型リソースを用いてＵＲＬＬＣデータを受信機２００に送信してもよい。
【００３１】
一実施例では、送信部１２０は、受信機２００が第１のタイプのリソースから所定のタイプの情報を検出するための付加情報と共に所定のタイプの情報を受信機２００に送信してもよい。具体的には、送信部１２０は、受信機２００がｅＭＢＢリソースから埋め込まれているＵＲＬＬＣパケットを容易に検出できるように、プリアンブル又はＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）コードをＵＲＬＬＣパケットと共に送信してもよい。この場合、プリアンブルは事前に定義された系列の中から送信部１２０がランダムに選んでも良いし、受信機２００によって予めシグナリングされても良い。また、ＣＲＣは送信部１２０に割り当てられた端末番号（例えばＣ−ＲＮＴＩ）と同一の系列によってマスキングされてもよいし、事前に受信機２００からシグナリングされた別の端末番号を用いてもよい。受信機２００は、埋め込まれたＵＲＬＬＣパケットを検出するため、受信したｅＭＢＢリソースに対してブラインド検出を実行する必要があるが、当該付加情報を利用することによって、より容易にｅＭＢＢリソースからＵＲＬＬＣパケットを検出することが可能になる。また、送信部１２０は、ＵＲＬＬＣパケットの制御情報（例えば、ＭＣＳ、割当てリソース）を含む制御チャネルをｅＭＢＢリソースに更に埋め込んでもよい。この場合、受信機２００は、埋め込まれた制御情報に基づきＵＲＬＬＣパケットを迅速に検出及び復号化することができる。あるいは、ｅＭＢＢのアップリンクの制御情報に対して、ＵＲＬＬＣが埋め込まれていること、及び／又はその制御情報（ＭＣＳ，割当てリソース）を追加して送信してもよい。
【００３２】
一実施例では、送信部１２０は、当該付加情報を周波数分割多重（ＦＤＭ）方式、時分割多重（ＴＤＭ）方式又は符号分割多重（ＣＤＭ）方式によりｅＭＢＢリソースに埋め込んでもよい。また、送信部１２０は、リソースの節約のため、非直交多重方式を利用してもよい。例えば、ＦＤＭ方式によりＵＲＬＬＣパケットと共に、上述した付加情報を埋め込む場合、送信部１２０は、図６に示されるようなリソース配置によりＵＲＬＬＣパケット及び付加情報をｅＭＢＢリソースに埋め込んでもよい。一方、ＴＤＭ方式によりＵＲＬＬＣパケットと共に付加情報を埋め込む場合、送信部１２０は、図７に示されるようなリソース配置によりＵＲＬＬＣパケット及び付加情報をｅＭＢＢリソースに埋め込んでもよい。検出用の付加情報は、ＵＲＬＬＣパケットより前に配置されることが好ましい。
【００３３】
また、一実施例では、送信部１２０は、プリアンブル系列の種類によってＵＲＬＬＣパケットの制御情報を非明示的に通知してもよい。例えば、各プリアンブル系列に特定のＭＣＳが予め割り当てられ、送信部１２０は、埋め込まれたＵＲＬＬＣパケットに適用されたＭＣＳに対応するプリアンブル系列を付加情報としてｅＭＢＢリソースに埋め込んでもよい。これにより、制御情報を埋め込むためにｅＭＢＢデータの一部をパンクチャすることなく、送信部１２０は、ＵＲＬＬＣパケットの制御情報を受信機２００に通知できる。
【００３４】
一実施例では、送信部１２０は、第１のタイプのリソース内に設定された候補リソースを用いて所定のタイプの情報を受信機２００に送信してもよい。上述したように、受信機２００は、受信したｅＭＢＢリソースに対してブラインド検出を実行し、埋め込まれているＵＲＬＬＣパケットを検出する。そこで、ブラインド検出の複雑さを低下させるため、受信機２００は、ｅＭＢＢリソース内においてＵＲＬＬＣパケットを埋め込み可能な複数の候補リソースを事前に定義し、送信部１２０は、これらの候補リソースの何れかにおいてＵＲＬＬＣパケットを送信するようにしてもよい。例えば、低遅延の観点からは、受信機２００は、図８に示されるように、時間方向に密に候補リソースを配置してもよい。このような配置によると、ＵＲＬＬＣデータの送信が必要になったとき、送信部１２０は、大きな遅延なくＵＲＬＬＣパケットをｅＭＢＢリソース内の候補リソースを用いて受信機２００に送信することが可能になる。一方、ブラインド検出の複雑さ軽減の観点からは、受信機２００は、図９に示されるように、許容可能な遅延の範囲内で時間方向に疎に候補リソースを配置してもよい。なお、候補リソースは、事前に固定的に定義されてもよいし、あるいは、受信機２００によって送信機１００に通知又はブロードキャストされてもよい。また、当該通知又はブロードキャストに係るシグナリングオーバヘッドを低減するため、候補リソースの配置に関するいくつかの候補パターンが定義され、受信機２００は、選択した候補パターンに対応するインデックスを送信機１００に通知又はブロードキャストしてもよい。
【００３５】
一実施例では、送信イベントの発生タイミングに応じて、送信部１２０は、第１のタイプのリソースと第２のタイプのリソースとの双方を用いて所定のタイプの情報を受信機２００に送信してもよい。具体的には、割り当てられているｅＭＢＢリソースの終盤にＵＲＬＬＣデータの送信が必要になった場合、送信部１２０は、ｅＭＢＢリソースのみではＵＲＬＬＣデータの送信を完了させることができない可能性がある。この場合、図１０に示されるように、送信部１２０は、ｅＭＢＢリソースと共に衝突型リソースを用いてＵＲＬＬＣパケットを送信してもよい。あるいは、送信部１２０は、最後のｅＭＭＢリソースのまでｅＭＢＢリソースを用いてＵＲＬＬＣパケットを送信した後に、残りのＵＲＬＬＣパケットを衝突型リソースを用いて送信してもよい。
【００３６】
また、このようなｅＭＢＢリソースの終盤におけるＵＲＬＬＣデータを送信するための候補リソースの枯渇を防止するため、図１１に示されるように、受信機２００は、ｅＭＢＢリソースの時間方向に関して終了部分に候補リソースを密に割り当ててもよい。これにより、割り当てられているｅＭＢＢリソースの終盤にＵＲＬＬＣデータの送信が必要になった場合でも、送信部１２０は、ｅＭＢＢリソースを用いてＵＲＬＬＣパケットの送信を完了させることができるようになる。
【００３７】
なお、例外的に、ｅＭＢＢリソースの終了部分では、送信部１２０は、ｅＭＢＢリソースに加えて、割り当てられたｅＭＢＢリソース以外の領域においてもＵＲＬＬＣパケットを送信してもよい。例えば、送信部１２０は、ｅＭＢＢリソースの終了部分において、割り当てられたｅＭＢＢリソースの送信帯域外の領域でＵＲＬＬＣパケットを送信してもよい。あるいは、送信部１２０は、ｅＭＢＢリソースの終了後、ｅＭＢＢリソースの送信帯域を引き続き用いてＵＲＬＬＣパケットを送信してもよい。このような例外的な送信は、例えば、受信機２００からの当該例外的送信を許容するシグナリングに従って可能とされてもよい。
【００３８】
次に、図１２を参照して、本発明の一実施例による受信機を説明する。図１２は、本発明の一実施例による受信機の機能構成を示すブロック図である。
【００３９】
図１２に示されるように、受信機２００は、リソース割当て部２１０、受信部２２０及び検出部２３０を有する。
【００４０】
リソース割当て部２１０は、第１のタイプのリソースを送信機１００に割り当てる。具体的には、リソース割当て部２１０は、ｅＭＢＢリソースを含む各種リソースを送信機１００に割り当てる。上述したように、送信機１００は、ＵＲＬＬＣデータの送信が必要になると、割当て済みのｅＭＢＢリソースを用いてＵＲＬＬＣデータを送信する。また、リソース割当て部２１０は、送信許可を受けることなく送信機１００がデータを送信可能な衝突型リソースを設定し、当該衝突型リソースを送信機１００に通知又はブロードキャストする。
【００４１】
受信部２２０は、送信機１００から第１のタイプのリソースを受信する。具体的には、受信部２２０は、ＵＲＬＬＣパケットが埋め込まれたｅＭＢＢリソースを受信する。
【００４２】
検出部２３０は、送信機１００から受信した第１のタイプのリソースから、送信許可することなく送信された所定のタイプの情報を検出する。具体的には、検出部２３０は、送信機１００から受信したｅＭＢＢリソースに対してブラインド検出を実行し、ｅＭＢＢリソースに埋め込まれたＵＲＬＬＣパケットを検出する。
【００４３】
一実施例では、リソース割当て部２１０は、第１のタイプのリソース内に所定のタイプの情報を送信するための候補リソースを設定してもよい。具体的には、リソース割当て部２１０は、図８〜９に示されるように、送信許可を付与することなく送信機１００から送信されるＵＲＬＬＣデータの送信用に複数の候補リソースをｅＭＢＢリソース内に設定する。上述したように、検出部２３０は、受信したｅＭＢＢリソースに対してブラインド検出を実行し、ＵＲＬＬＣパケットを検出する。そこで、ブラインド検出の複雑さを低下させるため、リソース割当て部２１０は、ｅＭＢＢリソース内においてＵＲＬＬＣパケットを埋め込み可能な複数の候補リソースを事前に定義し、送信機１００に当該候補リソースの何れかを用いてＵＲＬＬＣパケットを送信させてもよい。例えば、低遅延の観点からは、リソース割当て部２１０は、図８に示されるように、時間方向に密に候補リソースを配置してもよい。このような配置によると、ＵＲＬＬＣデータの送信が必要になったとき、送信機１００は、大きな遅延なくｅＭＢＢリソース内の候補リソースを用いてＵＲＬＬＣパケットを受信部２２０に送信することが可能になる。一方、ブラインド検出の複雑さの軽減の観点からは、リソース割当て部２１０は、図９に示されるように、許容可能な遅延の範囲内で時間方向に疎に候補リソースを配置してもよい。なお、候補リソースは、事前に固定的に定義されてもよいし、あるいは、送信機１００に通知又はブロードキャストされてもよい。また、当該通知又はブロードキャストに係るシグナリングオーバヘッドを低減するため、候補リソースの配置に関するいくつかの候補パターンが定義され、リソース割当て部２１０は、選択した候補パターンに対応するインデックスを送信機１００に通知又はブロードキャストしてもよい。
【００４４】
一実施例では、リソース割当て部２１０は、第１のタイプのリソースの時間方向に関する終了部分に候補リソースを密に割り当ててもよい。具体的には、リソース割当て部２１０は、図１１に示されるように、ｅＭＭＢリソースの終盤に相対的に多くの候補リソースを割り当ててもよい。これにより、ｅＭＢＢリソースの終盤にＵＲＬＬＣデータの送信が必要になった場合でも、送信機１００は、ｅＭＢＢリソースを用いてＵＲＬＬＣパケットの送信を完了させることができるようになる。
【００４５】
なお、例外的に、ｅＭＢＢリソースの終了部分では、送信機１００は、ｅＭＢＢリソースに加えて、割り当てられたｅＭＢＢリソース以外の領域においてもＵＲＬＬＣパケットを送信してもよい。例えば、送信機１００は、ｅＭＢＢリソースの終了部分において、割り当てられたｅＭＢＢリソースの送信帯域外の領域でＵＲＬＬＣパケットを送信してもよい。あるいは、送信機１００は、ｅＭＢＢリソースの終了後、ｅＭＢＢリソースの送信帯域を引き続き用いてＵＲＬＬＣパケットを送信してもよい。このような例外的な送信は、例えば、リソース割当て部２１０からの当該例外的送信を許容するシグナリングに従って可能とされてもよい。
【００４６】
一実施例では、検出部２３０は、第１のタイプのリソースから所定のタイプの情報を検出するための付加情報に基づき、所定のタイプの情報を検出してもよい。具体的には、送信機１００は、検出部２３０がｅＭＢＢリソースから埋め込まれているＵＲＬＬＣパケットを容易に検出できるように、プリアンブル又はＣＲＣコードをＵＲＬＬＣパケットと共に送信可能である。検出部２３０は、埋め込まれたＵＲＬＬＣパケットを検出するためｅＭＢＢリソースに対してブラインド検出を実行する必要があるが、当該付加情報を利用することによって、より容易に埋め込まれたＵＲＬＬＣパケットを検出することが可能になる。また、送信機１００は、ＵＲＬＬＣパケットの制御情報（例えば、ＭＣＳ、割当てリソース）を含む制御チャネルをｅＭＢＢリソースに更に埋め込み可能である。このとき、検出部２３０は、埋め込まれた制御情報に基づきＵＲＬＬＣパケットを迅速に検出及び復号化することができる。
【００４７】
なお、上記実施の形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に(例えば、有線及び／又は無線)で接続し、これら複数の装置により実現されてもよい。
【００４８】
例えば、本発明の一実施の形態における送信機及び受信機は、本発明の無線通信方法の処理を行うコンピュータとして機能してもよい。図１３は、本発明の一実施例による送信機及び受信機のハードウェア構成を示すブロック図である。上述の送信機１００及び受信機２００は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
【００４９】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。送信機１００及び受信機２００のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【００５０】
送信機１００及び受信機２００における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信や、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。
【００５１】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：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）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。
【００５９】
情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink  Control  Information）、ＵＣＩ（Uplink  Control  Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio  Resource  Control）シグナリング、ＭＡＣ（Medium  Access  Control）シグナリング、報知情報（ＭＩＢ（Master  Information  Block）、ＳＩＢ（System  Information  Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。
【００６０】
本明細書で説明した各態様／実施例は、ＬＴＥ（Long  Term  Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future  Radio  Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra  Mobile  Broadband）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【００６１】
本明細書で説明した各態様／実施例の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【００６２】
本明細書において受信機２００（基地局）によって行われるとした特定動作は、場合によってはその上位ノード（upper node）によって行われることもある。基地局を有する１つまたは複数のネットワークノード（network nodes）からなるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局および／または基地局以外の他のネットワークノード(例えば、MMEまたはS-GWなどが考えられるが、これらに限られない)によって行われ得ることは明らかである。上記において基地局以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ(例えば、MMEおよびS-GW)であってもよい。
【００６３】
情報等は、上位レイヤ(または下位レイヤ)から下位レイヤ(または上位レイヤ)へ出力され得る。複数のネットワークノードを介して入出力されてもよい。
【００６４】
入出力された情報等は特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
【００６５】
判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。
【００６６】
本明細書で説明した各態様／実施例は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。
【００６７】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【００６８】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。
【００６９】
また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）などの有線技術及び／又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。
【００７０】
本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。
【００７１】
なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及び／又はシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ）は、キャリア周波数、セルなどと呼ばれてもよい。
【００７２】
本明細書で使用する「システム」および「ネットワーク」という用語は、互換的に使用される。
【００７３】
また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。
【００７４】
上述したパラメータに使用する名称はいかなる点においても限定的なものではない。さらに、これらのパラメータを使用する数式等は、本明細書で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素（例えば、ＴＰＣなど）は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的なものではない。
【００７５】
基地局は、１つまたは複数（例えば、３つ）の（セクタとも呼ばれる）セルを収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局ＲＲＨ：Ｒｅｍｏｔｅ  Ｒａｄｉｏ  Ｈｅａｄ）によって通信サービスを提供することもできる。「セル」または「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局、および／または基地局サブシステムのカバレッジエリアの一部または全体を指す。さらに、「基地局」、「ｅＮＢ」、「セル」、および「セクタ」という用語は、本明細書では互換的に使用され得る。基地局は、固定局（fixed station）、ＮｏｄｅＢ、ｅＮｏｄｅＢ（ｅＮＢ）、アクセスポイント（access point）、フェムトセル、スモールセルなどの用語で呼ばれる場合もある。
【００７６】
移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。
【００７７】
本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【００７８】
「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。本明細書で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及び／又はプリント電気接続を使用することにより、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどの電磁エネルギーを使用することにより、互いに「接続」又は「結合」されると考えることができる。
【００７９】
参照信号は、ＲＳ（Reference Signal）と略称することもでき、適用される標準によってパイロット（Pilot）と呼ばれてもよい。
【００８０】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【００８１】
本明細書で使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量または順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１および第２の要素への参照は、２つの要素のみがそこで採用され得ること、または何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。
【００８２】
上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。
【００８３】
「含む(ｉｎｃｌｕｄｉｎｇ)」、「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。
【００８４】
無線フレームは時間領域において１つまたは複数のフレームで構成されてもよい。時間領域において１つまたは複数の各フレームはサブフレームと呼ばれてもよい。サブフレームは更に時間領域において１つまたは複数のスロットで構成されてもよい。スロットはさらに時間領域において１つまたは複数のシンボル（ＯＦＤＭシンボル、ＳＣ-ＦＤＭＡシンボル等）で構成されてもよい。無線フレーム、サブフレーム、スロット、およびシンボルは、いずれも信号を伝送する際の時間単位を表す。無線フレーム、サブフレーム、スロット、およびシンボルは、それぞれに対応する別の呼び方であってもよい。例えば、ＬＴＥシステムでは、基地局が各移動局に無線リソース（各移動局において使用することが可能な周波数帯域幅や送信電力等）を割り当てるスケジューリングを行う。スケジューリングの最小時間単位をＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｔｉｍｅ  Ｉｎｔｅｒｖａｌ）と呼んでもよい。例えば、1サブフレームをＴＴＩと呼んでもよいし、複数の連続したサブフレームをＴＴＩと呼んでもよいし、１スロットをＴＴＩと呼んでもよい。リソースブロック（ＲＢ）は、時間領域および周波数領域のリソース割当単位であり、周波数領域では１つまたは複数個の連続した副搬送波（ｓｕｂｃａｒｒｉｅｒ）を含んでもよい。また、リソースブロックの時間領域では、１つまたは複数個のシンボルを含んでもよく、１スロット、１サブフレーム、または１ＴＴＩの長さであってもよい。１ＴＴＩ、１サブフレームは、それぞれ１つまたは複数のリソースブロックで構成されてもよい。上述した無線フレームの構造は例示に過ぎず、無線フレームに含まれるサブフレームの数、サブフレームに含まれるスロットの数、スロットに含まれるシンボルおよびリソースブロックの数、および、リソースブロックに含まれるサブキャリアの数は様々に変更することができる。
【００８５】
以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【００８６】
本出願は、２０１６年５月１２日に出願した日本国特許出願２０１６−０９６５２２号の優先権の利益に基づき、これを主張するものであり、２０１６−０９６５２２号の全内容を本出願に援用する。
【符号の説明】
【００８７】
１０  無線通信システム
１００  送信機
１１０  リソース判定部
１２０  送信部
２００  受信機
２１０  リソース割当て部
２２０  受信部
２３０  検出部
【図１】
2017195763.tif 000003
【図２】
2017195763.tif 000004
【図３】
2017195763.tif 000005
【図４】
2017195763.tif 000006
【図５】
2017195763.tif 000007
【図６】
2017195763.tif 000008
【図７】
2017195763.tif 000009
【図８】
2017195763.tif 000010
【図９】
2017195763.tif 000011
【図１０】
2017195763.tif 000012
【図１１】
2017195763.tif 000013
【図１２】
2017195763.tif 000014
【図１３】
2017195763.tif 000015
【国際調査報告】
2017195763.tif 000016
2017195763.tif 000017
2017195763.tif 000018
2017195763.tif 000019