ホーム > 特許ランキング > 株式会社ＮＴＴドコモ
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6891168
(24)【登録日】2021年5月28日
(45)【発行日】2021年6月18日
(54)【発明の名称】送信機及び受信機
(51)【国際特許分類】
H04W 74/02 20090101AFI20210607BHJP
H04W 72/04 20090101ALI20210607BHJP
【ＦＩ】
H04W74/02
H04W72/04 150
【請求項の数】7
【全頁数】19
(21)【出願番号】特願2018-517026(P2018-517026)
(86)(22)【出願日】2017年5月9日
(86)【国際出願番号】JP2017017490
(87)【国際公開番号】WO2017195763
(87)【国際公開日】20171116
【審査請求日】2020年3月11日
(31)【優先権主張番号】特願2016-96522(P2016-96522)
(32)【優先日】2016年5月12日
(33)【優先権主張国】JP
(73)【特許権者】
【識別番号】392026693
【氏名又は名称】株式会社ＮＴＴドコモ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100124844
【弁理士】
【氏名又は名称】石原 隆治
(72)【発明者】
【氏名】佐野 洋介
(72)【発明者】
【氏名】武田 和晃
(72)【発明者】
【氏名】武田 一樹
(72)【発明者】
【氏名】永田 聡
【審査官】
三枝 保裕
(56)【参考文献】
【文献】
国際公開第２０１６／０６９３７８（ＷＯ，Ａ１）
【文献】
Qualcomm Incorporated，Frame structure requirements[online]，3GPP TSG-RAN WG1#84b R1-162206，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ra，２０１６年 ４月 ２日，全文
【文献】
Intel Corporation，Considerations on waveform selection for new radio interface[online]，3GPP TSG-RAN WG1#84b R1-162384，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ra，２０１６年 ４月 ２日，全文
【文献】
Samsung，Ultra-reliability with low-latency support in 5G new radio interface[online]，3GPP TSG-RAN WG1#84b R1-162189，インターネット＜URL:http://www.3gpp.org/ftp/tsg_ra，２０１６年 ４月 １日，全文
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｈ０４Ｂ ７／２４− ７／２６
Ｈ０４Ｗ ４／００−９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４
ＳＡ ＷＧ１−４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
所定のタイプの情報の送信イベントが発生したことに応答して、第１のタイプのリソースが割り当てられているか判定するリソース判定部と、
前記第１のタイプのリソースが割り当てられている場合、送信許可を受けることなく、前記第１のタイプのリソースを用いて前記所定のタイプの情報を受信機に送信する送信部と、
を有し、
前記送信部は、前記第１のタイプのリソース内に設定された候補リソースを用いて前記所定のタイプの情報を前記受信機に送信し、
前記候補リソースは、前記第１のタイプのリソースの時間方向に関する終了部分に密に割り当てられる、
送信機。
前記第１のタイプのリソースが割り当てられている場合、送信許可を受けることなく、前記第１のタイプのリソースを用いて前記所定のタイプの情報を受信機に送信する送信部と、
を有し、
前記送信部は、前記第１のタイプのリソース内に設定された候補リソースを用いて前記所定のタイプの情報を前記受信機に送信し、
前記候補リソースは、前記第１のタイプのリソースの時間方向に関する終了部分に密に割り当てられる、
送信機。
【請求項2】
前記第１のタイプのリソースが割り当てられていない場合、又は前記受信機が前記第１のタイプのリソースから前記所定のタイプの情報を検出できないと予想される場合、前記送信部は、前記所定のタイプの情報を送信するため設定されている第２のタイプのリソースを用いて前記所定のタイプの情報を前記受信機に送信する、請求項１記載の送信機。
【請求項3】
前記送信部は、前記受信機が前記第１のタイプのリソースから前記所定のタイプの情報を検出するための付加情報と共に前記所定のタイプの情報を前記受信機に送信する、請求項１又は２記載の送信機。
【請求項4】
前記送信部は、前記第１のタイプのリソース内に設定された候補リソースを用いて前記所定のタイプの情報を前記受信機に送信する、請求項１乃至３何れか一項記載の送信機。
【請求項5】
前記送信イベントの発生タイミングに応じて、前記送信部は、前記第１のタイプのリソースと前記所定のタイプの情報を送信するため設定されている第２のタイプのリソースとの双方を用いて前記所定のタイプの情報を前記受信機に送信する、請求項１乃至４何れか一項記載の送信機。
【請求項6】
第１のタイプのリソースを送信機に割り当てるリソース割当て部と、
前記送信機から第１のタイプのリソースを受信する受信部と、
前記送信機から受信した前記第１のタイプのリソースから、送信許可することなく送信された所定のタイプの情報を検出する検出部と、
を有し、
前記リソース割当て部は、前記第１のタイプのリソース内に前記所定のタイプの情報を送信するための候補リソースを設定し、
前記リソース割当て部は、前記第１のタイプのリソースの時間方向に関する終了部分に前記候補リソースを密に割り当てる、
受信機。
前記送信機から第１のタイプのリソースを受信する受信部と、
前記送信機から受信した前記第１のタイプのリソースから、送信許可することなく送信された所定のタイプの情報を検出する検出部と、
を有し、
前記リソース割当て部は、前記第１のタイプのリソース内に前記所定のタイプの情報を送信するための候補リソースを設定し、
前記リソース割当て部は、前記第１のタイプのリソースの時間方向に関する終了部分に前記候補リソースを密に割り当てる、
受信機。
【請求項7】
前記検出部は、前記第１のタイプのリソースから前記所定のタイプの情報を検出するための付加情報に基づき、前記所定のタイプの情報を検出する、請求項６記載の受信機。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、無線通信システムに関する。【背景技術】
【0002】
現在、３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｉｃｔ）において、第４世代の無線通信システムの一つであるＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）−Ａｄｖａｎｃｅｄの後継にあたる５Ｇと呼ばれる次世代のシステムの検討が進んでいる。５Ｇでは、主にｅＭＢＢ（ｅｘｔｅｎｄｅｄ Ｍｏｂｉｌｅ Ｂｒｏａｄｂａｎｄ）、ｍＭＴＣ(ｍａｓｓｉｖｅ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＵＲＬＬＣ（Ｕｌｔｒａ Ｒｅｌｉａｂｉｌｉｔｙ ａｎｄ Ｌｏｗ Ｌａｔｅｎｃｙ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の３つのユースケースが想定されている（非特許文献１参照）。【0003】
ＵＲＬＬＣでは、低遅延及び高信頼性の要求条件が求められている。低遅延伝送を実現するため、短いＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）長（サブフレーム長、サブフレーム間隔として参照されてもよい）の導入が検討されている。例えば、サブフレーム当たりのシンボル数が減少されたり、あるいは、サブキャリア間隔を大きくすることによってシンボル長が減少されてもよい。また、パケット生成からデータ送信までの制御遅延を短縮することが図られてもよい。一方、高信頼性を実現するためには、低ビット誤り率を実現する低符号化率の符号化又は変調方式の導入が検討されている。あるいは、ダイバーシチを活用するアプローチもある。【0004】
ＵＲＬＬＣでは、緊急度の高い送信データが突然発生する可能性があり、このような突然発生したデータを低遅延且つ高信頼度で送信する必要がある。【0005】
ユーザ装置において送信すべきデータが発生した場合、例えばＬＴＥのアップリンク通信では、はじめに基地局に対してＳＲ（Ｓｃｈｅｄｕｌｉｎｇ Ｒｅｑｕｅｓｔ）を送信し、リソースの割り当てを基地局に要求する。基地局は、アップリンク送信許可として、リソースの割り当てをユーザ装置に通知し、ユーザ装置は、基地局から指定されたリソースにおいてデータを送信する。しかしながら、ＵＲＬＬＣでは、上記の通り送信すべきデータが突然発生する可能性があり、上記のようなプロセスにてデータ送信を行う場合、低遅延の要求条件を満たせなくなる可能性がある。上記のため、ＵＲＬＬＣでは、基地局によるアップリンク送信許可を受けることなく、ユーザ装置から自律的にデータ送信されることが想定されている。この場合、アップリンク送信許可を受けることなく送信されるＵＲＬＬＣデータは、基地局によって送信リソースの制御がなされていないため、他のユーザ装置から送信されるデータと衝突する可能性がある。【0006】
このような衝突型ＵＲＬＬＣでは、ユーザ装置は自律的に送信リソースを選択できるが、他のユーザ装置との干渉を低減するため、送信に利用可能なリソースがある程度限定されることが想定される。１つのアプローチとして、図１に示されるように、衝突型パケットのみを送信することが許可された衝突型リソースが定義され、ユーザ装置は、当該衝突型リソースを用いてＵＲＬＬＣパケットを送信することが想定される。なお、衝突型リソースのリソース位置は、例えば、ブロードキャスト信号などによってセミスタティックに通知されてもよい。【先行技術文献】
【非特許文献】
【0007】
【非特許文献1】ＲＰ−１６０６７１
【発明の概要】
【発明が解決しようとする課題】
【0008】
衝突型リソースによりＵＲＬＬＣパケットが送信される場合、他のユーザ装置も衝突型パケット（例えば、ＵＲＬＬＣパケット）を送信する可能性がある。このため、衝突が発生した場合、互いの干渉によってＵＲＬＬＣパケットの高信頼性の要求条件を満たせない可能性がある。【0009】
一方、他のアプローチとして、ＵＲＬＬＣパケット発生時に、ＵＲＬＬＣパケットとは異なる他のチャネルのためにアップリンク送信リソースが割り当てられている場合、当該チャネルの一部にＵＲＬＬＣパケットを埋め込み送信することが想定される。このようなチャネルとして、例えば、モバイルブロードバンドサービスに利用されるｅＭＢＢが考えられる。ＵＲＬＬＣパケットがｅＭＢＢに割り当てられたリソースにより送信される場合、少なくとも同一セル内では他のユーザ装置からの送信との大きな干渉は発生しないと考えられる。これは、ｅＭＢＢでは、端末間及びチャネル間の送信リソースが直交多重されていることが想定されるか、あるいは、複数の端末もしくはチャネルが同一の送信リソースにおいて非直交多重されているとしても、少なくともｅＭＢＢが検出できる程度に干渉量が制御されることが想定されるためである。従って、ＵＲＬＬＣデータの発生時、ｅＭＢＢリソースが割り当てられている場合、ユーザ装置は、高信頼性の要求条件を充足するため、衝突型リソースよりもｅＭＭＢリソースを用いてＵＲＬＬＣパケットを送信することが好ましい。【0010】
上述した問題点を鑑み、本発明の課題は、送信許可を受けることなく送信されるデータを低遅延且つ高信頼度で送信するための技術を提供することである。【課題を解決するための手段】
【0011】
上記課題を解決するため、本発明の一態様は、所定のタイプの情報の送信イベントが発生したことに応答して、第１のタイプのリソースが割り当てられているか判定するリソース判定部と、前記第１のタイプのリソースが割り当てられている場合、送信許可を受けることなく、前記第１のタイプのリソースを用いて前記所定のタイプの情報を受信機に送信する送信部とを有し、前記送信部は、前記第１のタイプのリソース内に設定された候補リソースを用いて前記所定のタイプの情報を前記受信機に送信し、前記候補リソースは、前記第１のタイプのリソースの時間方向に関する終了部分に密に割り当てられる、送信機に関する。
【0012】
本発明の他の態様は、第１のタイプのリソースを送信機に割り当てるリソース割当て部と、前記送信機から第１のタイプのリソースを受信する受信部と、前記送信機から受信した前記第１のタイプのリソースから、送信許可することなく送信された所定のタイプの情報を検出する検出部とを有し、前記リソース割当て部は、前記第１のタイプのリソース内に前記所定のタイプの情報を送信するための候補リソースを設定し、前記リソース割当て部は、前記第１のタイプのリソースの時間方向に関する終了部分に前記候補リソースを密に割り当てる、受信機に関する。
【発明の効果】
【0013】
本発明によると、送信許可を受けることなく送信されるデータを低遅延且つ高信頼度で送信することができる。【図面の簡単な説明】
【0014】
【発明を実施するための形態】
【0015】
以下、図面に基づいて本発明の実施の形態を説明する。【0016】
以下の実施例では、ＵＲＬＬＣデータなどの低遅延且つ高信頼性が要求されるデータを送受信するための送信機及び受信機が開示される。後述される実施例を概略すると、送信機は、送信許可を受けることなくデータを送信するとき、受信機からすでに割り当てられているリソースを用いて当該データを送信する。これにより、送信許可を受けることなく送信可能な衝突型データを送信するため、他の送信機と共用される衝突型リソースを利用する従来方式と比較して、送信機は、受信機により割り当てられた他の送信機からの送信と干渉しないリソースを用いて、低遅延及び高信頼性が要求されるＵＲＬＬＣデータなどのデータを確実に送信することができる。【0018】
図２に示されるように、無線通信システム１０は、送信機１００及び受信機２００を有する。以下の実施例では、図示されるように、送信機１００はユーザ装置（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ＵＥ）であり、受信機２００は基地局（ｅｖｏｌｖｅｄ ＮｏｄｅＢ：ｅＮＢ）であると想定される。しかしながら、本発明はこれに限定されず、送信機１００は基地局又は他の無線通信装置であり、受信機２００はユーザ装置又は他の無線通信装置であってもよい。また、送信機１００及び受信機２００の双方がユーザ装置であってもよく、この場合、これらユーザ装置間でデータが無線送受信されることになる。【0019】
以下の実施例では、ＵＲＬＬＣデータなどの低遅延且つ高信頼性が要求されるデータについて、送信機１００は、送信許可を受けることなく当該タイプのデータを送信することができる。例えば、送信機１００は、予め設定されている衝突型リソースを用いて、あるいは、受信機２００によって送信機１００にすでに割り当てられているｅＭＢＢなどのリソースを用いて、当該タイプのデータを送信可能である。【0020】
ここで、衝突型リソースとは、送信許可を受けることなく送信可能な衝突型パケットのみを送信することが許可されたリソースであり、例えば、図１に示されるようなリソース配置により設定されてもよい。典型的には、衝突型リソースは、基地局などの受信機２００によって設定され、ブロードキャスト情報において通知される。また、ｅＭＢＢなどの他の送信機との干渉のないリソースは、モバイルブロードバンドサービスなど当該タイプのデータの送信とは異なる用途向けに設定されたリソースであり、基地局などの受信機２００によって送信機１００に対して割り当てられる。上述したように、衝突型リソースは、送信機１００以外の送信機も利用可能であり、他の送信機による送信により干渉を受ける可能性がある。他方、ｅＭＢＢなどのリソースは、他の送信機からの送信による干渉を受けないように受信機２００によって割り当てられており、送信機１００は、このような他の送信機からの送信による干渉のないリソースを用いることによって、衝突型リソースよりも高い信頼度でデータを送信することができる。【0021】
なお、以下の実施例では、衝突型リソースとｅＭＢＢなどの干渉のない割当て済みのリソースとの一方又は双方を用いたＵＲＬＬＣデータの送信を説明するが、本発明はこれら２つのタイプのリソースに限定されるものでなく、他のタイプのリソースが利用されてもよい。例えば、ｅＭＢＢの代わりに、ｍＭＴＣ、ＬＴＥ、ＬＴＥ−Ａｄｖａｎｃｅｄ、ＬＡＡ（Ｌｉｃｅｎｓｅ Ａｓｓｉｓｔｅｄ Ａｃｃｅｓｓ）などの他のサービスのためのリソースが、割当て済みリソースとして使用されてもよい。また、送信許可を受けることなく送信可能なデータは、ＵＲＬＬＣに限定されず、他のタイプのデータであってもよい。【0023】
図３に示されるように、送信機１００は、リソース判定部１１０及び送信部１２０を有する。【0024】
リソース判定部１１０は、所定のタイプの情報の送信イベントが発生したことに応答して、第１のタイプのリソースが割り当てられているか判定する。具体的には、低遅延且つ高信頼性が要求されるＵＲＬＬＣデータの送信が必要になると、リソース判定部１１０は、ｅＭＢＢなどの他の送信機との干渉のないリソースが受信機２００によって割り当て済みであり、受信機２００への送信に利用可能であるか判定する。【0025】
送信部１２０は、第１のタイプのリソースが割り当てられている場合、送信許可を受けることなく、第１のタイプのリソースを用いて所定のタイプの情報を受信機２００に送信する。具体的には、干渉のないリソースが割り当てられている場合、図４に示されるように、送信部１２０は、ＵＲＬＬＣデータの送信に対する送信許可を受けることなく、当該干渉のないリソースにＵＲＬＬＣパケットを埋め込むことによって、干渉のないリソースにおいてＵＲＬＬＣデータを受信機２００に送信する。【0026】
上述したように、ｅＭＢＢなどの他の送信機からの送信と干渉のないリソースは、衝突型リソースより高い信頼度でデータを受信機２００に送信できる。このため、送信機１００においてＵＲＬＬＣデータの送信が必要になると、リソース判定部１１０は、ｅＭＢＢなどの干渉のないリソースが送信機１００に割当て済みであるか判断し、干渉のないリソースがすでに割当てられている場合、送信部１２０は、衝突型リソースよりも優先的に割り当てられている干渉のないリソースを利用してＵＲＬＬＣデータを送信する。これにより、送信機１００は、ＵＲＬＬＣデータを低遅延且つ高信頼度で送信することができる。【0027】
ここで、ｅＭＢＢを用いてＵＲＬＬＣパケットを送信する場合、送信部１２０は、例えば、ｅＭＢＢの送信シンボルの全て又は一部をパンクチャ（無送信）し、パンクチャされた部分にＵＲＬＬＣパケットを埋め込むことによって、ＵＲＬＬＣデータを送信できる。この場合、ｅＭＢＢにとって重要度の高い信号（例えば、Ｌ１／Ｌ２制御信号、ブロードキャスト情報、同期信号、データ復調用参照信号、送達確認、データ復調用参照信号、スケジューリングリクエスト）はパンクチャされるべきでなく、送信部１２０は、例えば、データ信号、品質測定用参照信号、チャネル状態情報、品質測定用参照信号などの相対的に優先度の低い信号をパンクチャし、パンクチャされた部分にＵＲＬＬＣを埋め込むことが好ましい。【0028】
あるいは、ｅＭＢＢの送信シンボルをパンクチャする代わりに、送信部１２０は、ｅＭＢＢの情報ビットをＵＲＬＬＣの情報ビットで上書きしてもよい。例えば、送信部１２０は、ｅＭＢＢの一部の符号セグメントをＵＲＬＬＣの情報ビットのために利用してもよい。また、送信部１２０は、ｅＭＢＢの変調次数を変更することによってＵＲＬＬＣの情報ビットを埋め込んでもよい。例えば、送信部１２０は、ｅＭＢＢの変調方式をＱＰＳＫ（２ビット）から１６ＱＡＭ（４ビット）に変更し、余剰となる２ビットにＵＲＬＬＣの情報ビットを埋め込んでもよい。また、送信部１２０は、ｅＭＢＢの変調次数を変更することなく、ビットの一部をｅＭＢＢデータとＵＲＬＬＣデータとで共有してもよい。例えば、ＱＰＳＫの場合、送信部１２０は、送信用の２ビットの内で前半の１ビットをｅＭＭＢデータに使用し、後半の１ビットをＵＲＬＬＣデータに使用してもよい。【0029】
送信部１２０は、ｅＭＢＢリソースに埋め込まれたＵＲＬＬＣの送信パワー、送信帯域幅、送信位置、変調符号化方式（ＭＣＳ）などの各種送信パラメータを決定し、当該送信パラメータに従ってＵＲＬＬＣデータを受信機２００に送信する。具体的には、送信パワーについては、ＵＲＬＬＣデータは突発的に発生するため、長周期の送信パワー制御（ＴＰＣ）は困難である。しかしながら、高信頼性を担保するため、最適なＴＰＣが利用されることが望ましい。また、送信帯域幅及び送信位置については、ｅＭＢＢに対して割り当てられたリソースの外部にＵＲＬＬＣデータがマッピングされると、他の送信機に対する干渉となる可能性がある。このため、送信帯域幅及び送信位置は、ｅＭＢＢに対して割り当てられた帯域内に限定されることが望ましい。一方、後述されるように、ｅＭＢＢリソースの帯域外であっても送信を行うことが遅延の観点でメリットがある場合もある。ＭＣＳについては、ＵＲＬＬＣデータは突発的に発生するため、ＡＭＣ（Ａｄａｐｔｉｖｅ Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｈａｎｎｅｌ Ｃｏｄｉｎｇ）のような閉ループ型の制御は困難であるが、要求されるパケット誤り率（例えば、パケット誤り率＝１０−５）を実現する必要がある。【0030】
他方、第１のタイプのリソースが割り当てられていない場合、又は受信機２００が第１のタイプのリソースから所定のタイプの情報を検出できないと予想される場合、送信部１２０は、所定のタイプの情報を送信するため設定されている第２のタイプのリソースを用いて所定のタイプの情報を受信機２００に送信してもよい。すなわち、送信機１００に対してｅＭＢＢリソースが割り当てられていない場合、図５に示されるように、送信部１２０は、ＵＲＬＬＣパケットなどの衝突型パケットを送信するため設定されている衝突型リソースを用いてＵＲＬＬＣデータを受信機２００に送信してもよい。また、送信機１００に対してｅＭＢＢリソースが割り当てられているが、受信機２００がｅＭＢＢリソースに埋め込まれたＵＲＬＬＣパケットを検出することが困難であると予想される場合、例えば、ｅＭＢＢに割りあてられたリソースが少なく、ＵＲＬＬＣの符号化率が所定の値（例えば０．９３１）を超える場合、送信部１２０は、同様に衝突型リソースを用いてＵＲＬＬＣデータを受信機２００に送信してもよい。あるいは、ｅＭＢＢリソースにＵＲＬＬＣパケットを埋め込んだことにより、受信機２００がｅＭＢＢパケットを検出することが困難であることが想定される場合、例えばｅＭＢＢの符号化率が所定の値（例えば０．９３１）を超える場合、送信部１２０は、同様に衝突型リソースを用いてＵＲＬＬＣデータを受信機２００に送信してもよい。【0031】
一実施例では、送信部１２０は、受信機２００が第１のタイプのリソースから所定のタイプの情報を検出するための付加情報と共に所定のタイプの情報を受信機２００に送信してもよい。具体的には、送信部１２０は、受信機２００がｅＭＢＢリソースから埋め込まれているＵＲＬＬＣパケットを容易に検出できるように、プリアンブル又はＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）コードをＵＲＬＬＣパケットと共に送信してもよい。この場合、プリアンブルは事前に定義された系列の中から送信部１２０がランダムに選んでも良いし、受信機２００によって予めシグナリングされても良い。また、ＣＲＣは送信部１２０に割り当てられた端末番号（例えばＣ−ＲＮＴＩ）と同一の系列によってマスキングされてもよいし、事前に受信機２００からシグナリングされた別の端末番号を用いてもよい。受信機２００は、埋め込まれたＵＲＬＬＣパケットを検出するため、受信したｅＭＢＢリソースに対してブラインド検出を実行する必要があるが、当該付加情報を利用することによって、より容易にｅＭＢＢリソースからＵＲＬＬＣパケットを検出することが可能になる。また、送信部１２０は、ＵＲＬＬＣパケットの制御情報（例えば、ＭＣＳ、割当てリソース）を含む制御チャネルをｅＭＢＢリソースに更に埋め込んでもよい。この場合、受信機２００は、埋め込まれた制御情報に基づきＵＲＬＬＣパケットを迅速に検出及び復号化することができる。あるいは、ｅＭＢＢのアップリンクの制御情報に対して、ＵＲＬＬＣが埋め込まれていること、及び／又はその制御情報（ＭＣＳ，割当てリソース）を追加して送信してもよい。【0032】
一実施例では、送信部１２０は、当該付加情報を周波数分割多重（ＦＤＭ）方式、時分割多重（ＴＤＭ）方式又は符号分割多重（ＣＤＭ）方式によりｅＭＢＢリソースに埋め込んでもよい。また、送信部１２０は、リソースの節約のため、非直交多重方式を利用してもよい。例えば、ＦＤＭ方式によりＵＲＬＬＣパケットと共に、上述した付加情報を埋め込む場合、送信部１２０は、図６に示されるようなリソース配置によりＵＲＬＬＣパケット及び付加情報をｅＭＢＢリソースに埋め込んでもよい。一方、ＴＤＭ方式によりＵＲＬＬＣパケットと共に付加情報を埋め込む場合、送信部１２０は、図７に示されるようなリソース配置によりＵＲＬＬＣパケット及び付加情報をｅＭＢＢリソースに埋め込んでもよい。検出用の付加情報は、ＵＲＬＬＣパケットより前に配置されることが好ましい。【0033】
また、一実施例では、送信部１２０は、プリアンブル系列の種類によってＵＲＬＬＣパケットの制御情報を非明示的に通知してもよい。例えば、各プリアンブル系列に特定のＭＣＳが予め割り当てられ、送信部１２０は、埋め込まれたＵＲＬＬＣパケットに適用されたＭＣＳに対応するプリアンブル系列を付加情報としてｅＭＢＢリソースに埋め込んでもよい。これにより、制御情報を埋め込むためにｅＭＢＢデータの一部をパンクチャすることなく、送信部１２０は、ＵＲＬＬＣパケットの制御情報を受信機２００に通知できる。【0034】
一実施例では、送信部１２０は、第１のタイプのリソース内に設定された候補リソースを用いて所定のタイプの情報を受信機２００に送信してもよい。上述したように、受信機２００は、受信したｅＭＢＢリソースに対してブラインド検出を実行し、埋め込まれているＵＲＬＬＣパケットを検出する。そこで、ブラインド検出の複雑さを低下させるため、受信機２００は、ｅＭＢＢリソース内においてＵＲＬＬＣパケットを埋め込み可能な複数の候補リソースを事前に定義し、送信部１２０は、これらの候補リソースの何れかにおいてＵＲＬＬＣパケットを送信するようにしてもよい。例えば、低遅延の観点からは、受信機２００は、図８に示されるように、時間方向に密に候補リソースを配置してもよい。このような配置によると、ＵＲＬＬＣデータの送信が必要になったとき、送信部１２０は、大きな遅延なくＵＲＬＬＣパケットをｅＭＢＢリソース内の候補リソースを用いて受信機２００に送信することが可能になる。一方、ブラインド検出の複雑さ軽減の観点からは、受信機２００は、図９に示されるように、許容可能な遅延の範囲内で時間方向に疎に候補リソースを配置してもよい。なお、候補リソースは、事前に固定的に定義されてもよいし、あるいは、受信機２００によって送信機１００に通知又はブロードキャストされてもよい。また、当該通知又はブロードキャストに係るシグナリングオーバヘッドを低減するため、候補リソースの配置に関するいくつかの候補パターンが定義され、受信機２００は、選択した候補パターンに対応するインデックスを送信機１００に通知又はブロードキャストしてもよい。【0035】
一実施例では、送信イベントの発生タイミングに応じて、送信部１２０は、第１のタイプのリソースと第２のタイプのリソースとの双方を用いて所定のタイプの情報を受信機２００に送信してもよい。具体的には、割り当てられているｅＭＢＢリソースの終盤にＵＲＬＬＣデータの送信が必要になった場合、送信部１２０は、ｅＭＢＢリソースのみではＵＲＬＬＣデータの送信を完了させることができない可能性がある。この場合、図１０に示されるように、送信部１２０は、ｅＭＢＢリソースと共に衝突型リソースを用いてＵＲＬＬＣパケットを送信してもよい。あるいは、送信部１２０は、最後のｅＭＭＢリソースのまでｅＭＢＢリソースを用いてＵＲＬＬＣパケットを送信した後に、残りのＵＲＬＬＣパケットを衝突型リソースを用いて送信してもよい。【0036】
また、このようなｅＭＢＢリソースの終盤におけるＵＲＬＬＣデータを送信するための候補リソースの枯渇を防止するため、図１１に示されるように、受信機２００は、ｅＭＢＢリソースの時間方向に関して終了部分に候補リソースを密に割り当ててもよい。これにより、割り当てられているｅＭＢＢリソースの終盤にＵＲＬＬＣデータの送信が必要になった場合でも、送信部１２０は、ｅＭＢＢリソースを用いてＵＲＬＬＣパケットの送信を完了させることができるようになる。【0037】
なお、例外的に、ｅＭＢＢリソースの終了部分では、送信部１２０は、ｅＭＢＢリソースに加えて、割り当てられたｅＭＢＢリソース以外の領域においてもＵＲＬＬＣパケットを送信してもよい。例えば、送信部１２０は、ｅＭＢＢリソースの終了部分において、割り当てられたｅＭＢＢリソースの送信帯域外の領域でＵＲＬＬＣパケットを送信してもよい。あるいは、送信部１２０は、ｅＭＢＢリソースの終了後、ｅＭＢＢリソースの送信帯域を引き続き用いてＵＲＬＬＣパケットを送信してもよい。このような例外的な送信は、例えば、受信機２００からの当該例外的送信を許容するシグナリングに従って可能とされてもよい。【0039】
図１２に示されるように、受信機２００は、リソース割当て部２１０、受信部２２０及び検出部２３０を有する。【0040】
リソース割当て部２１０は、第１のタイプのリソースを送信機１００に割り当てる。具体的には、リソース割当て部２１０は、ｅＭＢＢリソースを含む各種リソースを送信機１００に割り当てる。上述したように、送信機１００は、ＵＲＬＬＣデータの送信が必要になると、割当て済みのｅＭＢＢリソースを用いてＵＲＬＬＣデータを送信する。また、リソース割当て部２１０は、送信許可を受けることなく送信機１００がデータを送信可能な衝突型リソースを設定し、当該衝突型リソースを送信機１００に通知又はブロードキャストする。【0041】
受信部２２０は、送信機１００から第１のタイプのリソースを受信する。具体的には、受信部２２０は、ＵＲＬＬＣパケットが埋め込まれたｅＭＢＢリソースを受信する。【0042】
検出部２３０は、送信機１００から受信した第１のタイプのリソースから、送信許可することなく送信された所定のタイプの情報を検出する。具体的には、検出部２３０は、送信機１００から受信したｅＭＢＢリソースに対してブラインド検出を実行し、ｅＭＢＢリソースに埋め込まれたＵＲＬＬＣパケットを検出する。【0043】
一実施例では、リソース割当て部２１０は、第１のタイプのリソース内に所定のタイプの情報を送信するための候補リソースを設定してもよい。具体的には、リソース割当て部２１０は、図８〜９に示されるように、送信許可を付与することなく送信機１００から送信されるＵＲＬＬＣデータの送信用に複数の候補リソースをｅＭＢＢリソース内に設定する。上述したように、検出部２３０は、受信したｅＭＢＢリソースに対してブラインド検出を実行し、ＵＲＬＬＣパケットを検出する。そこで、ブラインド検出の複雑さを低下させるため、リソース割当て部２１０は、ｅＭＢＢリソース内においてＵＲＬＬＣパケットを埋め込み可能な複数の候補リソースを事前に定義し、送信機１００に当該候補リソースの何れかを用いてＵＲＬＬＣパケットを送信させてもよい。例えば、低遅延の観点からは、リソース割当て部２１０は、図８に示されるように、時間方向に密に候補リソースを配置してもよい。このような配置によると、ＵＲＬＬＣデータの送信が必要になったとき、送信機１００は、大きな遅延なくｅＭＢＢリソース内の候補リソースを用いてＵＲＬＬＣパケットを受信部２２０に送信することが可能になる。一方、ブラインド検出の複雑さの軽減の観点からは、リソース割当て部２１０は、図９に示されるように、許容可能な遅延の範囲内で時間方向に疎に候補リソースを配置してもよい。なお、候補リソースは、事前に固定的に定義されてもよいし、あるいは、送信機１００に通知又はブロードキャストされてもよい。また、当該通知又はブロードキャストに係るシグナリングオーバヘッドを低減するため、候補リソースの配置に関するいくつかの候補パターンが定義され、リソース割当て部２１０は、選択した候補パターンに対応するインデックスを送信機１００に通知又はブロードキャストしてもよい。【0044】
一実施例では、リソース割当て部２１０は、第１のタイプのリソースの時間方向に関する終了部分に候補リソースを密に割り当ててもよい。具体的には、リソース割当て部２１０は、図１１に示されるように、ｅＭＭＢリソースの終盤に相対的に多くの候補リソースを割り当ててもよい。これにより、ｅＭＢＢリソースの終盤にＵＲＬＬＣデータの送信が必要になった場合でも、送信機１００は、ｅＭＢＢリソースを用いてＵＲＬＬＣパケットの送信を完了させることができるようになる。【0045】
なお、例外的に、ｅＭＢＢリソースの終了部分では、送信機１００は、ｅＭＢＢリソースに加えて、割り当てられたｅＭＢＢリソース以外の領域においてもＵＲＬＬＣパケットを送信してもよい。例えば、送信機１００は、ｅＭＢＢリソースの終了部分において、割り当てられたｅＭＢＢリソースの送信帯域外の領域でＵＲＬＬＣパケットを送信してもよい。あるいは、送信機１００は、ｅＭＢＢリソースの終了後、ｅＭＢＢリソースの送信帯域を引き続き用いてＵＲＬＬＣパケットを送信してもよい。このような例外的な送信は、例えば、リソース割当て部２１０からの当該例外的送信を許容するシグナリングに従って可能とされてもよい。【0046】
一実施例では、検出部２３０は、第１のタイプのリソースから所定のタイプの情報を検出するための付加情報に基づき、所定のタイプの情報を検出してもよい。具体的には、送信機１００は、検出部２３０がｅＭＢＢリソースから埋め込まれているＵＲＬＬＣパケットを容易に検出できるように、プリアンブル又はＣＲＣコードをＵＲＬＬＣパケットと共に送信可能である。検出部２３０は、埋め込まれたＵＲＬＬＣパケットを検出するためｅＭＢＢリソースに対してブラインド検出を実行する必要があるが、当該付加情報を利用することによって、より容易に埋め込まれたＵＲＬＬＣパケットを検出することが可能になる。また、送信機１００は、ＵＲＬＬＣパケットの制御情報（例えば、ＭＣＳ、割当てリソース）を含む制御チャネルをｅＭＢＢリソースに更に埋め込み可能である。このとき、検出部２３０は、埋め込まれた制御情報に基づきＵＲＬＬＣパケットを迅速に検出及び復号化することができる。【0047】
なお、上記実施の形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に(例えば、有線及び／又は無線)で接続し、これら複数の装置により実現されてもよい。【0048】
例えば、本発明の一実施の形態における送信機及び受信機は、本発明の無線通信方法の処理を行うコンピュータとして機能してもよい。図１３は、本発明の一実施例による送信機及び受信機のハードウェア構成を示すブロック図である。上述の送信機１００及び受信機２００は、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。【0049】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。送信機１００及び受信機２００のハードウェア構成は、図に示した各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。【0050】
送信機１００及び受信機２００における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信や、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。【0051】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。例えば、上述の各構成要素は、プロセッサ１００１で実現されてもよい。【0052】
また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュールやデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、送信機１００及び受信機２００の各構成要素による処理は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよく、他の機能ブロックについても同様に実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。【0053】
メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施の形態に係る無線通信方法を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。【0054】
ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact Disc ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。【0055】
通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、上述の送信部１２０及び受信部２２０は、通信装置１００４で実現されてもよい。【0056】
入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。【0057】
また、プロセッサ１００１やメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。【0058】
また、送信機１００及び受信機２００は、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。【0059】
情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink Control Information）、ＵＣＩ（Uplink Control Information））、上位レイヤシグナリング（例えば、ＲＲＣ（Radio Resource Control）シグナリング、ＭＡＣ（Medium Access Control）シグナリング、報知情報（ＭＩＢ（Master Information Block）、ＳＩＢ（System Information Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。【0060】
本明細書で説明した各態様／実施例は、ＬＴＥ（Long Term Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future Radio Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra Mobile Broadband）、ＩＥＥＥ ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。【0061】
本明細書で説明した各態様／実施例の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。【0062】
本明細書において受信機２００（基地局）によって行われるとした特定動作は、場合によってはその上位ノード（upper node）によって行われることもある。基地局を有する１つまたは複数のネットワークノード（network nodes）からなるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局および／または基地局以外の他のネットワークノード(例えば、MMEまたはS-GWなどが考えられるが、これらに限られない)によって行われ得ることは明らかである。上記において基地局以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ(例えば、MMEおよびS-GW)であってもよい。【0063】
情報等は、上位レイヤ(または下位レイヤ)から下位レイヤ(または上位レイヤ)へ出力され得る。複数のネットワークノードを介して入出力されてもよい。【0064】
入出力された情報等は特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。【0065】
判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。【0066】
本明細書で説明した各態様／実施例は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。【0067】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。【0068】
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。【0069】
また、ソフトウェア、命令などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、同軸ケーブル、光ファイバケーブル、ツイストペア及びデジタル加入者回線（ＤＳＬ）などの有線技術及び／又は赤外線、無線及びマイクロ波などの無線技術を使用してウェブサイト、サーバ、又は他のリモートソースから送信される場合、これらの有線技術及び／又は無線技術は、伝送媒体の定義内に含まれる。【0070】
本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。【0071】
なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及び／又はシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（ＣＣ）は、キャリア周波数、セルなどと呼ばれてもよい。【0072】
本明細書で使用する「システム」および「ネットワーク」という用語は、互換的に使用される。【0073】
また、本明細書で説明した情報、パラメータなどは、絶対値で表されてもよいし、所定の値からの相対値で表されてもよいし、対応する別の情報で表されてもよい。例えば、無線リソースはインデックスで指示されるものであってもよい。【0074】
上述したパラメータに使用する名称はいかなる点においても限定的なものではない。さらに、これらのパラメータを使用する数式等は、本明細書で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、ＰＵＣＣＨ、ＰＤＣＣＨなど）及び情報要素（例えば、ＴＰＣなど）は、あらゆる好適な名称によって識別できるので、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的なものではない。【0075】
基地局は、１つまたは複数（例えば、３つ）の（セクタとも呼ばれる）セルを収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局ＲＲＨ：Ｒｅｍｏｔｅ Ｒａｄｉｏ Ｈｅａｄ）によって通信サービスを提供することもできる。「セル」または「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局、および／または基地局サブシステムのカバレッジエリアの一部または全体を指す。さらに、「基地局」、「ｅＮＢ」、「セル」、および「セクタ」という用語は、本明細書では互換的に使用され得る。基地局は、固定局（fixed station）、ＮｏｄｅＢ、ｅＮｏｄｅＢ（ｅＮＢ）、アクセスポイント（access point）、フェムトセル、スモールセルなどの用語で呼ばれる場合もある。【0076】
移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。【0077】
本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。【0078】
「接続された(connected)」、「結合された(coupled)」という用語、又はこれらのあらゆる変形は、２又はそれ以上の要素間の直接的又は間接的なあらゆる接続又は結合を意味し、互いに「接続」又は「結合」された２つの要素間に１又はそれ以上の中間要素が存在することを含むことができる。要素間の結合又は接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。本明細書で使用する場合、２つの要素は、１又はそれ以上の電線、ケーブル及び／又はプリント電気接続を使用することにより、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどの電磁エネルギーを使用することにより、互いに「接続」又は「結合」されると考えることができる。【0079】
参照信号は、ＲＳ（Reference Signal）と略称することもでき、適用される標準によってパイロット（Pilot）と呼ばれてもよい。【0080】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。【0081】
本明細書で使用する「第１の」、「第２の」などの呼称を使用した要素へのいかなる参照も、それらの要素の量または順序を全般的に限定するものではない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本明細書で使用され得る。したがって、第１および第２の要素への参照は、２つの要素のみがそこで採用され得ること、または何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。【0082】
上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。【0083】
「含む(ｉｎｃｌｕｄｉｎｇ)」、「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。【0084】
無線フレームは時間領域において１つまたは複数のフレームで構成されてもよい。時間領域において１つまたは複数の各フレームはサブフレームと呼ばれてもよい。サブフレームは更に時間領域において１つまたは複数のスロットで構成されてもよい。スロットはさらに時間領域において１つまたは複数のシンボル（ＯＦＤＭシンボル、ＳＣ-ＦＤＭＡシンボル等）で構成されてもよい。無線フレーム、サブフレーム、スロット、およびシンボルは、いずれも信号を伝送する際の時間単位を表す。無線フレーム、サブフレーム、スロット、およびシンボルは、それぞれに対応する別の呼び方であってもよい。例えば、ＬＴＥシステムでは、基地局が各移動局に無線リソース（各移動局において使用することが可能な周波数帯域幅や送信電力等）を割り当てるスケジューリングを行う。スケジューリングの最小時間単位をＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ）と呼んでもよい。例えば、1サブフレームをＴＴＩと呼んでもよいし、複数の連続したサブフレームをＴＴＩと呼んでもよいし、１スロットをＴＴＩと呼んでもよい。リソースブロック（ＲＢ）は、時間領域および周波数領域のリソース割当単位であり、周波数領域では１つまたは複数個の連続した副搬送波（ｓｕｂｃａｒｒｉｅｒ）を含んでもよい。また、リソースブロックの時間領域では、１つまたは複数個のシンボルを含んでもよく、１スロット、１サブフレーム、または１ＴＴＩの長さであってもよい。１ＴＴＩ、１サブフレームは、それぞれ１つまたは複数のリソースブロックで構成されてもよい。上述した無線フレームの構造は例示に過ぎず、無線フレームに含まれるサブフレームの数、サブフレームに含まれるスロットの数、スロットに含まれるシンボルおよびリソースブロックの数、および、リソースブロックに含まれるサブキャリアの数は様々に変更することができる。【0085】
以上、本発明の実施例について詳述したが、本発明は上述した特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。【0086】
（第１項）所定のタイプの情報の送信イベントが発生したことに応答して、第１のタイプのリソースが割り当てられているか判定するリソース判定部と、
前記第１のタイプのリソースが割り当てられている場合、送信許可を受けることなく、前記第１のタイプのリソースを用いて前記所定のタイプの情報を受信機に送信する送信部と、
を有する送信機。
（第２項）
前記第１のタイプのリソースが割り当てられていない場合、又は前記受信機が前記第１のタイプのリソースから前記所定のタイプの情報を検出できないと予想される場合、前記送信部は、前記所定のタイプの情報を送信するため設定されている第２のタイプのリソースを用いて前記所定のタイプの情報を前記受信機に送信する、第１項記載の送信機。
（第３項）
前記送信部は、前記受信機が前記第１のタイプのリソースから前記所定のタイプの情報を検出するための付加情報と共に前記所定のタイプの情報を前記受信機に送信する、第１項又は第２項記載の送信機。
（第４項）
前記送信部は、前記第１のタイプのリソース内に設定された候補リソースを用いて前記所定のタイプの情報を前記受信機に送信する、第１項乃至第３項何れか一項記載の送信機。
（第５項）
前記送信イベントの発生タイミングに応じて、前記送信部は、前記第１のタイプのリソースと前記所定のタイプの情報を送信するため設定されている第２のタイプのリソースとの双方を用いて前記所定のタイプの情報を前記受信機に送信する、第１項乃至第４項何れか一項記載の送信機。
（第６項）
第１のタイプのリソースを送信機に割り当てるリソース割当て部と、
前記送信機から第１のタイプのリソースを受信する受信部と、
前記送信機から受信した前記第１のタイプのリソースから、送信許可することなく送信された所定のタイプの情報を検出する検出部と、
を有する受信機。
（第７項）
前記リソース割当て部は、前記第１のタイプのリソース内に前記所定のタイプの情報を送信するための候補リソースを設定する、第６項記載の受信機。
（第８項）
前記リソース割当て部は、前記第１のタイプのリソースの時間方向に関する終了部分に前記候補リソースを密に割り当てる、第７項記載の受信機。
（第９項）
前記検出部は、前記第１のタイプのリソースから前記所定のタイプの情報を検出するための付加情報に基づき、前記所定のタイプの情報を検出する、第６項乃至第８項何れか一項記載の受信機。
本出願は、２０１６年５月１２日に出願した日本国特許出願２０１６−０９６５２２号の優先権の利益に基づき、これを主張するものであり、２０１６−０９６５２２号の全内容を本出願に援用する。
【符号の説明】
【0087】
１０ 無線通信システム１００ 送信機
１１０ リソース判定部
１２０ 送信部
２００ 受信機
２１０ リソース割当て部
２２０ 受信部
２３０ 検出部