特表-17135026IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ソニー株式会社の特許一覧
再表2017-135026無線通信装置、通信方法、コンピュータプログラム及び無線通信システム
(19)【発行国】日本国特許庁(JP)
【公報種別】再公表特許(A1)
(11)【国際公開番号】WO/0
(43)【国際公開日】2017年8月10日
【発行日】2018年11月29日
(54)【発明の名称】無線通信装置、通信方法、コンピュータプログラム及び無線通信システム
(51)【国際特許分類】
   H04W 72/04 20090101AFI20181102BHJP
   H04W 28/06 20090101ALI20181102BHJP
   H04W 72/12 20090101ALI20181102BHJP
【FI】
   H04W72/04 131
   H04W28/06 110
   H04W72/12 130
【審査請求】未請求
【予備審査請求】未請求
【全頁数】55
【出願番号】特願2017-565459(P2017-565459)
(21)【国際出願番号】PCT/0/0
(22)【国際出願日】2017年1月17日
(31)【優先権主張番号】特願2016-19199(P2016-19199)
(32)【優先日】2016年2月3日
(33)【優先権主張国】JP
(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,ST,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,KM,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DJ,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IR,IS,JP,KE,KG,KH,KN,KP,KR,KW,KZ,LA,LC,LK,LR,LS,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SA,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ
(71)【出願人】
【識別番号】000002185
【氏名又は名称】ソニー株式会社
(74)【代理人】
【識別番号】100095957
【弁理士】
【氏名又は名称】亀谷 美明
(74)【代理人】
【識別番号】100096389
【弁理士】
【氏名又は名称】金本 哲男
(74)【代理人】
【識別番号】100101557
【弁理士】
【氏名又は名称】萩原 康司
(74)【代理人】
【識別番号】100128587
【弁理士】
【氏名又は名称】松本 一騎
(72)【発明者】
【氏名】高野 裕昭
【テーマコード(参考)】
5K067
【Fターム(参考)】
5K067AA13
5K067DD11
5K067EE02
5K067EE10
5K067EE71
(57)【要約】
【課題】既存の送信時間間隔でのデータの送受信と、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信とを効率よく混在させることが可能な無線通信装置を提供する。
【解決手段】サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知するとともに、サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知する通知部を備える、無線通信装置が提供される。
【選択図】図1
【特許請求の範囲】
【請求項1】
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知するとともに、サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知する通知部を備える、無線通信装置。
【請求項2】
前記通知部は、前記短送信時間領域が1サブフレーム内において複数存在することを通知する、請求項1に記載の無線通信装置。
【請求項3】
前記通知部は、前記制御領域において、前記短送信時間領域における前記短送信時間間隔のデータの有無を通知する、請求項1に記載の無線通信装置。
【請求項4】
前記通知部は、前記短送信時間領域の通知は準静的に通知し、通知前記短送信時間間隔のデータの有無は動的に通知する、請求項3に記載の無線通信装置。
【請求項5】
前記通知部は、前記制御領域において、他の通信装置に向けて前記短送信時間領域における前記短送信時間間隔のデータの場所を通知する、請求項1に記載の無線通信装置。
【請求項6】
前記通知部は、前記制御領域において、後続の別のサブフレームにおける前記短送信時間間隔についての情報を通知する、請求項1に記載の無線通信装置。
【請求項7】
前記通知部は、前記制御領域において、同一のサブフレームにおける前記短送信時間間隔についての情報を通知する、請求項1に記載の無線通信装置。
【請求項8】
前記制御領域は、PDCCH(Physical Downlink Control Channel)である、請求項1に記載の無線通信装置。
【請求項9】
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を受信するとともに、サブフレーム単位で送られる制御領域において、他の通信装置から前記短送信時間間隔についての情報を受信する受信部を備える、無線通信装置。
【請求項10】
前記受信部は、前記制御領域において、前記短送信時間領域における前記短送信時間間隔のデータの有無を受信する、請求項9に記載の無線通信装置。
【請求項11】
前記制御領域は、PDCCH(Physical Downlink Control Channel)である、請求項9に記載の無線通信装置。
【請求項12】
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知することと、
サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知することと、
を含む、無線通信方法。
【請求項13】
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を受信することと、
サブフレーム単位で送られる制御領域において、他の通信装置から前記短送信時間間隔についての情報を受信することと、
を含む、無線通信方法。
【請求項14】
コンピュータに、
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知することと、
サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知することと、
を実行させる、コンピュータプログラム。
【請求項15】
コンピュータに、
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を受信することと、
サブフレーム単位で送られる制御領域において、他の通信装置から前記短送信時間間隔についての情報を受信することと、
を実行させる、コンピュータプログラム。
【請求項16】
第1の通信装置及び第2の通信装置を備え、
前記第1の通信装置は、サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知するとともに、サブフレーム単位で送られる制御領域において、前記第2の通信装置向けの前記短送信時間間隔についての情報を通知する通知部を備え、
前記第2の通信装置は、前記短送信時間間隔でデータを送信する短送信時間領域を受信するとともに、サブフレーム単位で送られる制御領域において、前記第1の通信装置から前記短送信時間間隔についての情報を受信する受信部を備える、無線通信システム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、無線通信装置、通信方法、コンピュータプログラム及び無線通信システムに関する。
【背景技術】
【0002】
LTE(Long Term Evolution)においては、高データレート化を実現するために、TTI(Transmission Time Interval:送信時間間隔)が1msとなっている。TTIを短くすることで、再送制御に要するRTT(Round Trip Time:往復遅延時間)が短縮され、システムの遅延が低減される(例えば特許文献1参照)。
【0003】
TTIが1msの場合、端末装置がデータをデコードするのに必要な時間は4msである。このTTIがより短くなると、端末装置でのデコード時間も短くなる。端末装置でのデコード時間も短くなると、リアルタイム性が強く要求される場合に大きな効果が期待できる。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2009−212597号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
既存の送信時間間隔より短い短送信時間間隔(Short TTI)でのデータの送受信に全て置き換えると既存の送信時間間隔でのデータの送受信しか出来ない端末装置に影響が出る。また既存の方法では、PDCCHを使って、個別のリソースエレメントへのスケジューリングを行っていた。Short TTIの導入により、端末装置に割り当てるべきリソースの数が増えると、既存のPDCCHの領域が足りなくなってしまう。一方、短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを基地局から通知することで、端末装置での効率的な受信処理が期待出来る。
【0006】
そこで、本開示では、既存の送信時間間隔でのデータの送受信と、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信とを効率よく混在させることが可能な、新規かつ改良された無線通信装置、通信方法、コンピュータプログラム及び無線通信システムを提案する。
【課題を解決するための手段】
【0007】
本開示によれば、サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知するとともに、サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知する通知部を備える、無線通信装置が提供される。
【0008】
また本開示によれば、サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を受信するとともに、サブフレーム単位で送られる制御領域において、他の通信装置から前記短送信時間間隔についての情報を受信する受信部を備える、無線通信装置が提供される。
【0009】
また本開示によれば、サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知することと、サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知することと、を含む、無線通信方法が提供される。
【0010】
また本開示によれば、サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を受信することと、サブフレーム単位で送られる制御領域において、他の通信装置から前記短送信時間間隔についての情報を受信することと、を含む、無線通信方法が提供される。
【0011】
また本開示によれば、コンピュータに、サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知することと、サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知することと、を実行させる、コンピュータプログラムが提供される。
【0012】
また本開示によれば、コンピュータに、サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を受信することと、サブフレーム単位で送られる制御領域において、他の通信装置から前記短送信時間間隔についての情報を受信することと、を実行させる、コンピュータプログラムが提供される。
【0013】
また本開示によれば、第1の通信装置及び第2の通信装置を備え、前記第1の通信装置は、サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知するとともに、サブフレーム単位で送られる制御領域において、前記第2の通信装置向けの前記短送信時間間隔についての情報を通知する通知部を備え、前記第2の通信装置は、前記短送信時間間隔でデータを送信する短送信時間領域を受信するとともに、サブフレーム単位で送られる制御領域において、前記第1の通信装置から前記短送信時間間隔についての情報を受信する受信部を備える、無線通信システムが提供される、
【発明の効果】
【0014】
以上説明したように本開示によれば、既存の送信時間間隔でのデータの送受信と、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信とを効率よく混在させることが可能な、新規かつ改良された無線通信装置及び通信方法を提供することが出来る。
【0015】
なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
【図面の簡単な説明】
【0016】
図1】LTEのフレームフォーマットを示す説明図である。
図2】LTEのダウンリンクのフォーマットを示す説明図である。
図3】LTEのアップリンクのスケジューリングの概要を示す説明図である。
図4】本開示の実施の形態に係るシステムの構成例を示す説明図である。
図5】同実施形態に係る基地局100の構成の一例を示すブロック図である。
図6】同実施形態に係る端末装置200の構成の一例を示すブロック図である。
図7】Short TTI領域の例を示す説明図である。
図8】Short TTI領域の例を示す説明図である。
図9】Short TTI領域の例を示す説明図である。
図10】Short TTI領域の例を示す説明図である。
図11】同実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。
図12】基地局100が、特定の端末装置向けの情報がShort TTI領域に有るか無いかを通知する方法について説明する説明図である。
図13】基地局100が、特定の端末装置向けの情報がShort TTI領域に有るか無いかを通知する方法について説明する説明図である。
図14】基地局100がPDCCHの端末装置200固有なサーチスペースの中にあるDCIを使用して特定の端末装置向けの情報がShort TTI領域に有るか無いかを通知する例を示す説明図である。
図15】基地局100が、Short TTI領域におけるShort TTIのデータの場所をDCIで通知する様子を示す説明図である。
図16】基地局100が、Short TTI領域におけるShort TTIのデータの場所をDCIで通知する様子を示す説明図である。
図17】同実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。
図18】1OFDMシンボルで構成されるShort TTIを示す説明図である。
図19】2OFDMシンボルで構成されるShort TTIを示す説明図である。
図20】同実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。
図21】一つのサブフレームにおけるShort TTI領域の例を示す説明図である。
図22】4OFDMシンボルで構成されるShort TTIを示す説明図である。
図23】1フレームにおける、4OFDMシンボルで構成されるShort TTIを示す説明図である。
図24】同実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。
図25】1つのサブフレームに複数のレベルのShort TTIが混在している例を示す説明図である。
図26】Short TTIの別の配置例を示す説明図である。
図27】Short TTIの配置例を示す説明図である。
図28】Short TTIの配置例を示す説明図である。
図29】Short TTIの配置例を示す説明図である。
図30】Short TTIの配置例を示す説明図である。
図31】同実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。
図32】Short TTIの配置例を示す説明図である。
図33】Short TTIの配置例を示す説明図である。
図34】Short TTIの配置例を示す説明図である。
図35】ネットワークゲームを実行する各ユーザの端末装置200に表示される地図の例を示す説明図である。
図36】1つのサブフレームに1スロット目のRBGと2スロット目のRBGがあることを示す説明図である。
図37】Short TTIの端末装置200への割り当て例を示す説明図である。
図38】1台の端末装置200に通常のTTIとShort TTIとをスケジューリングした様子を示す説明図である
図39】同実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。
図40】11OFDMシンボルのうち、先頭の2つのOFDMシンボルにのみShort TTIのデータが入っていることを示す説明図である。
図41】3台の端末装置200がそれぞれShort TTIのデータをデコードする場合の例を示す説明図である。
図42】端末装置200が11個のShort TTI全てをデコードすることを説明する説明図である。
図43】Short TTIの宛先と、ある端末装置200でのCRCチェックの結果の例を示す説明図である。
図44】基地局100が、端末装置200に向けて送信する情報について示す説明図である。
図45】実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。
図46】同実施形態に係る端末装置200の構成の一例を示すブロック図である。
図47】Short TTI領域の例を示す説明図である。
図48】Short TTI領域の例を示す説明図である。
図49】Short TTI領域の例を示す説明図である。
【発明を実施するための形態】
【0017】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0018】
なお、説明は以下の順序で行うものとする。
1.本開示の実施の形態
1.1.概要
1.2.システム構成例
1.3.機能構成例
1.4.動作例
1.4.1.第1の動作例
1.4.2.第2の動作例
1.4.3.第3の動作例
1.4.4.動作例のまとめ
2.応用例
2.1.基地局に関する応用例
2.2.端末装置に関する応用例
4.まとめ
【0019】
<1.本開示の実施の形態>
[1.1.概要]
本開示の実施の形態について詳細に説明するにあたり、まずは本開示の実施の形態の概要について説明する。本開示の実施の形態の概要について説明した後に、本開示の実施の形態について詳細に説明する。
【0020】
図1は、LTEのフレームフォーマットを示す説明図である。図1に示したように、LTEの1 radio frameは10個のサブフレーム(Sub Frame)で構成されている。1つのサブフレームの長さは1msである。また、1つのサブフレームは14個のOFDM(orthogonal frequency−division multiplexing;直交周波数分割多重方式)シンボルで構成されている。バンド幅は、例えば20MHzである。
【0021】
LTEでは、基地局(eNodeB)から送信されたデータは、1サブフレームで1つのトランスポートブロックを構成している。またトランスポートブロックの最後にはCRC(Cyclic Redundancy Check)が付加されている。つまり、基地局から送信されたデータを受信する端末装置(UE;User Equipment)は、1サブフレームのデータを受信することによりデータのデコードが可能になる。言い換えれば、UEは、トランスポートブロックの受信の成否を、CRCの実施により判別することが出来る。従って、UEは、Hybrid ARQ(Auto Repeat Request)といわれる、再送を要求するためのACKまたはNACKを、1サブフレーム内のデータに対して実施する。ACKは、データの受信に成功した場合にUEからeNodeBに返信するものであり、NACKは、データの受信に成功した場合にUEからeNodeBに返信するものである。
【0022】
図2は、LTEのダウンリンクのフォーマットを示す説明図である。LTEでは、1サブフレームの中に複数のリソースブロックが存在する。eNodeBは、リソースブロック単位で各UEに対してデータを割り当てることが出来る。eNodeBは、リソースブロック単位で各UEに対してデータを割り当てるための制御情報を、PDCCH(Physical Downlink Control Channel)という、サブフレームの先頭部分に配置される制御領域に格納している。PDCCHは、1つのサブフレームに1つだけ存在する。
【0023】
LTEにおいては、高データレート化を実現するために、TTIが1msとなっている。すなわち、TTIは1サブフレームの時間と同じである。UEが1サブフレーム内のトランスポートブロックをデコードする際の処理遅延は4サブフレーム程度掛かる。従って、UEは、受信したサブフレームの4サブフレーム後に、ACKまたはNACKをeNodeBに返信することが可能である。図3は、LTEのアップリンクのスケジューリングの概要を示す説明図である。UEが受信したサブフレームのPDCCHには、アップリンクのスケジューリング情報が含まれているが、このスケジューリング情報は受信したサブフレームの4サブフレーム後のスケジューリングが可能となっている。このように受信したサブフレームの4サブフレーム後のスケジューリングが可能となっているのは、UEでの処理遅延を考慮したためである。
【0024】
従って、TTIが短くなれば、UEにおけるデコードのための遅延や、アップリンクを使用したeNodeBへのフィードバックまでの時間の短縮が期待できる。より具体的には、TTIが短くなれば、以下のようなメリットが期待される。
【0025】
TTIが短くなれば、第一に、UEで動作するアプリケーションの低遅延での制御が可能になる。TTIが短くなれば、UEでのデコード時間も短くなるので、UEは、短いTTI(Short TTI、短送信時間間隔)でeNodeBから送信されるデータに基づいた意志決定に要する時間が短く出来る。なお、以下の説明では、Short TTIと区別するために、既存のTTIのことをNormal TTIと称することもある。従って、TTIが短くなれば、UEは何らかの制御を低遅延で行うことが可能になる。例えば、UEにおいて、リアルタイム性が強く求められる等の理由で遅延に厳しい何らかのアプリケーションを動かす場合には、デコード時間が短くなることは非常に大きなメリットとなる。UEが例えば自動車やドローン(自律飛行する飛行体)のような物体の場合にも、リアルタイム性が強く求められるため、TTIが短くなることは非常に大きなメリットとなる。
【0026】
TTIが短くなれば、第二に、Hybrid ARQのRTTの低減が可能になる。すなわち、UEは、デコード時間が短くなれば、データの受信の成否をより早く判別できるようになる。UEは、データの受信の成否をより早く判別できると、eNodeBへのACKまたはNACKの返信を素早く行える。よって、TTIが短くなれば、eNodeBは、UEにデータを送信してから、UEで受信できなかったデータの再送までの時間を短縮でき、スループットの向上にも繋がる。LTEのHybrid ARQでは、UEがデータの受信に成功しないと次のデータを送れないので、ACKをUEからeNodeBへ早く送ることも、スループットの向上に寄与する。
【0027】
TTIが短くなれば、第三に、CQI(Channel Quality Indicator)のフィードバックの遅延の低減が可能になる。UEは、eNodeBから提供されるReference Signalに基づいてダウンリンクチャネルの品質を測定し、品質の測定結果をeNodeBへ報告している。そしてeNodeBは、UEから報告されたダウンリンクチャネルの品質を考慮して、UEに対するダウンリンクデータの変調方式を決定している。UEからのフィードバックの遅延が大きいと、eNodeBは、本来のダウンリンクの品質と異なった品質に対応する変調方式でデータをUEに送ってしまう。従って、ダウンリンクチャネルの品質の測定の遅延と、測定結果の報告の遅延を低減できれば、eNodeBは、適切な変調方式をUEのために選択するまでの時間を低減できる。適切な変調方式を選択するまでの時間を低減できれば、ダウンリンクのスループットの向上が見込める。
【0028】
既存の送信時間間隔より短い短送信時間間隔でデータを送信することで、上述したような効果が見込める。しかし、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信に全て置き換えると既存の送信時間間隔でのデータの送受信しか出来ない端末装置に影響が出る。そのため、既存の送信時間間隔でのデータの送受信と短送信時間間隔でのデータの送受信とを混在させる必要がある。
【0029】
ここで、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な受信処理を可能にするための技術が必要になる。
【0030】
Short TTIを導入すると、受信側のデコードに必要な回路の使い回しができなくなる。あるデータを受信してデコードしてから、次のデータを受信してデコードするまでに時間の余裕があれば、一つの乗算器を使って計算できるが、時間の余裕が無ければ、乗算器が一つでは足りず、乗算器を複数用意しなければならない。従ってShort TTIを実現するために、受信機の計算コストがアップして、ハード規模が大きくなる場合がある。eNodeBに繋がるUEは、様々なメーカーから提供されうる。メーカーによっては、ハード規模を小さく抑えたいところもあるし、ハード規模を小さくする技術に長けているところもある。全てのUEが同じShort TTIの長さに対応できるかは分からない。なお、以下の説明では、Short TTIの長さの違いを意味する用語として「レベル」という言葉を使用しうる。従って、eNodeB側が様々なレベルのShort TTIを用意しておくことが、Short TTIに対応した端末の普及につながる。
【0031】
また、UEがShort TTIに対応したとしても、そもそも、全てのUEが同じように低遅延を求めているかはわからない。要求される遅延時間は、UEに搭載される上位のアプリケーションに依存する。従って、それほど低遅延を求めていないUEに1OFDMシンボルで構成されるShort TTIを提供することは、無駄なリソースの占有につながる。
【0032】
そこで、本件開示者は、上述の点に鑑み、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、短送信時間間隔でのデータの送受信に対応した端末装置での効率的な受信処理が期待出来る技術について鋭意検討を行った。その結果、本件開示者は、以下で説明するように、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを基地局から通知することで、端末装置での効率的な受信処理が可能な技術を考案するに至った。
【0033】
以上、本開示の実施の形態の概要について説明した。続いて、本開示の実施の形態について詳細に説明する。
【0034】
[1.2.システム構成例]
図4は、本開示の実施の形態に係るシステムの構成例を示す説明図である。以下、図4を用いて本開示の実施の形態に係るシステムの構成例について説明する。
【0035】
図4を参照すると、システム1は、基地局100及び端末装置200を含む。ここでは、基地局100はeNodeBとも呼ばれる。またここでは、端末装置200は、ユーザとも呼ばれる。当該ユーザは、ユーザ機器(UE)とも呼ばれ得る。ここでのUEは、LTE又はLTE−Aにおいて定義されているUEであってもよく、より一般的に通信機器を意味してもよい。
【0036】
(1)基地局100
基地局100は、セルラーシステム(又は移動体通信システム)の基地局である。基地局100は、基地局100のセル10内に位置する端末装置(例えば、端末装置200)との無線通信を行う。例えば、基地局100は、端末装置へのダウンリンク信号を送信し、端末装置からのアップリンク信号を受信する。
【0037】
(2)端末装置200
端末装置200は、セルラーシステム(又は移動体通信システム)において通信可能である。端末装置200は、セルラーシステムの基地局(例えば、基地局100)との無線通信を行う。例えば、端末装置200は、基地局からのダウンリンク信号を受信し、基地局へのアップリンク信号を送信する。図4には、4つの端末装置200A〜200Dを図示している。なお以下の説明では、特に区別する必要が無ければ端末装置200
【0038】
[1.3.機能構成例]
続いて、図5及び図6を参照して、本開示の実施形態に係る基地局100及び端末装置200の機能構成例を説明する。
【0039】
まず、図5を参照して、本開示の実施形態に係る基地局100の構成の一例を説明する。図5は、本開示の実施形態に係る基地局100の構成の一例を示すブロック図である。図5を参照すると、基地局100は、アンテナ部110、無線通信部120、ネットワーク通信部130、記憶部140及び処理部150を備える。
【0040】
(1)アンテナ部110
アンテナ部110は、無線通信部120により出力される信号を電波として空間に放射する。また、アンテナ部110は、空間の電波を信号に変換し、当該信号を無線通信部120へ出力する。
【0041】
(2)無線通信部120
無線通信部120は、信号を送受信する。例えば、無線通信部120は、端末装置へのダウンリンク信号を送信し、端末装置からのアップリンク信号を受信する。
【0042】
(3)ネットワーク通信部130
ネットワーク通信部130は、情報を送受信する。例えば、ネットワーク通信部130は、他のノードへの情報を送信し、他のノードからの情報を受信する。例えば、上記他のノードは、他の基地局及びコアネットワークノードを含む。
【0043】
(4)記憶部140
記憶部140は、基地局100の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
【0044】
(5)処理部150
処理部150は、基地局100の様々な機能を提供する。処理部150は、送信処理部151及び通知部153を含む。なお、処理部150は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部150は、これらの構成要素の動作以外の動作も行い得る。
【0045】
送信処理部151は、端末装置200へ向けたデータの送信に関する処理を実行する。例えば、送信処理部151は、複数のサブフレームからなるフレームを生成し、生成したフレームを端末装置200に送信する処理を実行する。また通知部153は、端末装置200に対する情報の通知に関する処理を実行する。なお、送信処理部151及び通知部153の具体的な動作は、後に詳細に説明する。
【0046】
次に、図6を参照して、本開示の実施形態に係る端末装置200の構成の一例を説明する。図6は、本開示の実施形態に係る端末装置200の構成の一例を示すブロック図である。図6を参照すると、端末装置200は、アンテナ部210、無線通信部220、記憶部230及び処理部240を備える。
【0047】
(1)アンテナ部210
アンテナ部210は、無線通信部220により出力される信号を電波として空間に放射する。また、アンテナ部210は、空間の電波を信号に変換し、当該信号を無線通信部220へ出力する。
【0048】
(2)無線通信部220
無線通信部220は、信号を送受信する。例えば、無線通信部220は、基地局からのダウンリンク信号を受信し、基地局へのアップリンク信号を送信する。
【0049】
(3)記憶部230
記憶部230は、端末装置200の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
【0050】
(4)処理部240
処理部240は、端末装置200の様々な機能を提供する。処理部240は、取得部241、受信処理部243及び通知部245を含む。なお、処理部240は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部240は、これらの構成要素の動作以外の動作も行い得る。
【0051】
取得部241は、基地局100から送信されたデータの取得に関する処理を実行する。受信処理部243は、取得部241が取得したデータの受信に関する処理を実行する。通知部245は、基地局100に対する情報の通知に関する処理を実行する。なお、取得部241、受信処理部243及び通知部245の動作は、後に詳細に説明する。
【0052】
以上、図5及び図6を参照して、本開示の実施形態に係る基地局100及び端末装置200の機能構成例を説明した。続いて、本開示の実施形態に係る基地局100及び端末装置200の動作例を説明する。
【0053】
[1.4.動作例]
(1.4.1.第1の動作例)
まず、本開示の実施形態に係る基地局100及び端末装置200の第1の動作例を説明する。上述したように、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な処理を可能にするための技術が必要になる。第1の動作例では、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な処理を可能にするための動作例を説明する。
【0054】
既存のTTIでのデータの送受信にShort TTIでのデータの送受信を混在させる場合、基地局100は、Short TTIでのデータの送受信で使用するリソースがどこにあるかを端末装置200に知らせる必要がある。Short TTIでのデータの送受信で使用するリソースの場所は、準静的に知らせる方法と、動的に知らせる方法とが考えられる。準静的に、それぞれの端末装置200に対するリソースを通知する方法は、1台の端末装置200のためのダウンリンクリソースを準静的に固定的に割り当てるため、Short TTIでのデータの送受信を使用しない場合にはダウンリンクリソースが無駄になってしまう。一方、動的に、それぞれの端末装置200に対するリソースを通知する方法は、端末装置200が観測すべき制御情報が増えるとともに、セル10内に位置する端末装置200が増加すると制御領域(PDCCH)が足りなくなってしまう。
【0055】
そこで、基地局100は、Short TTIのリソースを割り当てる際に、(1)Short TTIでのデータの送受信を行う領域(Short TTI領域)がどこにあるかを通知する方法、(2)Short TTI領域にある、特定の端末装置向けの情報が有るか無いかを通知する方法、(3)端末装置ごとにShort TTIのリソースを通知する方法、の3つの方法をとりうる。なお、この3つの方法は、基地局100にとって全てが必須であるとは限らない。以下において、この3つの方法の詳細について説明する。
【0056】
(1)Short TTI領域がどこにあるかを通知する方法
まず、Short TTI領域がどこにあるかを通知する方法を説明する。基地局100は、例えば、ブロードキャストを用いたシステム情報、または、端末装置200ごとのdedicated signalを用いて、準静的に1つのサブフレームにおけるShort TTI領域を端末装置200に通知する。ここで「準静的(Semi−Static)に」とは、基地局100がShort TTI領域を再指定するまでShort TTI領域は変化しないが、Short TTI領域は変更可能(changeable)であることを意味する。なお、1つのサブフレームにおけるShort TTI領域は複数存在していても良い。
【0057】
基地局100は、準静的に1つのサブフレームにおけるShort TTI領域を端末装置200に通知するが、この時点ではそのShort TTI領域をそれぞれの端末装置200がどのように使用するかまでは通知しない。
【0058】
図7は、Short TTI領域の例を示す説明図である。図7の符号301は、1つのサブフレームの、PDSCH(Physical Downlink Shared Channel)において指定されたShort TTI領域を指している。図7に示したのは、20MHzのバンド幅の一部の周波数の領域におけるTTIを1OFDMシンボルと同じ長さとする例である。
【0059】
上述したように、1つのサブフレームにおけるShort TTI領域は複数存在していても良い。図8は、Short TTI領域の例を示す説明図である。図8に示したのは、1つのサブフレームにおいてShort TTI領域が2つ存在している例である。符号301、302は、1つのサブフレームの、PDSCHにおいて指定されたShort TTI領域を指している。符号301で示したShort TTI領域はPDSCHの全体に渡っており、符号302で示したShort TTI領域は後半の7OFDMシンボル分のPDSCHに渡っている。また図8に示したのは、符号302で示したShort TTI領域のリソースが、符号301で示したShort TTI領域のリソースより多くなっている例である。
【0060】
また、全てのサブフレームに渡ってShort TTI領域が存在しても良く、1フレーム中の特定のサブフレームにおいてShort TTI領域が存在しても良い。全てのサブフレームに渡ってShort TTI領域を必要とするアプリケーションもあれば、1フレーム中の特定のサブフレームにおいてShort TTI領域が存在していれば足りるアプリケーションもあるからである。
【0061】
例えば、基地局100が、1フレーム中の特定の場所で制御信号を端末装置200に送信するが、その制御信号を端末装置200が短い時間でデコードしてくれることを期待するようなユースケースが考えられる。このユースケースは、基地局100が、Short TTI領域を、端末装置200の制御信号を送るための領域として使用するようなユースケースである。基地局100がShort TTI領域で送信する端末装置200の制御信号は、アプリケーションの制御のための信号であってもよく、無線信号の受信のための制御信号であってもよい。
【0062】
上述したように、全てのサブフレームに渡ってShort TTI領域が存在しても良いが、1フレーム中の特定のサブフレームにおいてShort TTI領域が存在しても良い。また基地局100は、サブフレーム毎にShort TTI領域を変化させても良い。基地局100は、サブフレーム毎にShort TTI領域を変化させることで設定の自由度を高めることが出来る。
【0063】
図9は、Short TTI領域の例を示す説明図である。図9に示したのは、符号302で示したShort TTI領域を基地局100が予め設定しておき、その領域に実際にShort TTIのデータが入るかどうかは、基地局100が、符号303で示したPDCCHの中のDCI(Downlink Control Information)で動的に設定する場合の例である。
【0064】
基地局100が、符号303で示したPDCCHの中のDCIで、Short TTI領域にデータが存在するかどうかを設定することで、Short TTI領域が常に固定で配置されることによるリソースの無駄遣いを防ぐことが出来る。すなわち、基地局100は、Short TTI領域を設定しても、Short TTI領域で常にShort TTIのデータを入れて送信するとは限らないので、PDCCHの中のDCIで、Short TTI領域にデータが存在するかどうかを設定してリソースの無駄遣いを防ぐことを可能にする。
【0065】
図10は、Short TTI領域の例を示す説明図である。図10に示したのは、図9と同様に、符号302で示したShort TTI領域を基地局100が予め設定しておき、その領域に実際にShort TTIのデータが入るかどうかは、基地局100が、符号303で示したPDCCHの中のDCIで動的に設定する場合の例である。
【0066】
図10に示した例が図9に示した例と異なるのは、符号303で示したPDCCHの中のDCIで設定しているのが、同一のサブフレームではなく、後続の別のサブフレームのShort TTI領域におけるデータの有無である点である。図9に示した例では、PDCCHの中のDCIで設定しているのが、同一のサブフレームのShort TTI領域におけるデータの有無であることから、端末装置200は、PDCCHをデコードして、同一のサブフレームのShort TTI領域におけるデータの有無を即座に判断しなければならない。図10に示した例では、PDCCHの中のDCIで設定しているのが、後続の別のサブフレームのShort TTI領域におけるデータの有無であることから、端末装置200は、後続の別のサブフレームのShort TTI領域が到来した時点では既にその領域にShort TTIのデータがあるかどうかが分かっている。従って、図10に示した例では、端末装置200は、後続の別のサブフレームのShort TTI領域が到来した時点で、Short TTIのデータがあればすぐにデコードを開始することが出来る。
【0067】
図11は、本開示の実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。図11に示したのは、基地局100がShort TTIとして使用される可能性のある領域を端末装置200へ通知すると共に、通知した領域がShort TTIとして使用されることを端末装置200へ通知する際の基地局100の動作例である。以下、図11を用いて本開示の実施の形態に係る基地局100及び端末装置200の動作例を説明する。
【0068】
基地局100は、サブフレームにおけるShort TTI領域(Short TTIになる可能性のある領域)を端末装置200へ通知する(ステップS101)。ステップS101の処理は、例えば通知部153が実行する。基地局100は、ブロードキャストを用いたシステム情報、または、端末装置200ごとのdedicated signalを用いて、準静的に1つのサブフレームにおけるShort TTIとして使用される可能性のある領域を通知する。
【0069】
基地局100は、Short TTIになる可能性のある領域を端末装置200へ通知すると、続いて、サブフレームごとに、Short TTIになる可能性のある領域が実際にShort TTIとして使用されることを動的に通知する(ステップS102)。ステップS102の処理は、例えば通知部153が実行する。基地局100は、例えば、上述したようにPDCCHの中のDCIにおいて、Short TTIとして使用される可能性のある領域が実際にShort TTIとして使用されるかどうかを指定する。
【0070】
基地局100が、このように動作することで、基地局100は、リソースを効率的に使用することができ、端末装置200は、Short TTIになる可能性のある領域が実際にShort TTIとして使用される場合にShort TTI用の動作を実行すれば良いので受信処理が効率化できる。
【0071】
(2)Short TTI領域にある、特定の端末装置向けの情報が有るか無いかを通知する方法
次に、Short TTI領域にある、特定の端末装置向けの情報が、そのShort TTI領域に有るか無いかを通知する方法を説明する。例えば、基地局100は、端末装置200ごとに、準静的な方法で通知したShort TTI領域内にその端末装置200に宛てた情報があるかどうかを動的に通知する。基地局100は、例えば、dedicated signalingを使用して準静的に、またはPDCCHを使用して動的に、Short TTI領域内にその端末装置200に宛てた情報があるかどうかを通知する。基地局100は、dedicated signalingを使用して準静的に通知すれば、既存のDCIに変更を加えずに、Short TTI領域内にその端末装置200に宛てた情報があるかどうかを通知することが出来る。また基地局100は、PDCCHを使用して動的に通知すれば、Short TTIのデータを送信する場合にだけShort TTI領域にShort TTIのデータを入れれば良いので、リソースを効率的に使用することが出来る。
【0072】
その際、基地局100は、Short TTI領域内にその端末装置200に宛てた情報があるかどうかだけを通知する。Short TTI領域に、それぞれの端末装置200にとって関係するデータがあるかどうかは、端末装置200が少ない手間で判別できるようにすることが望ましい。Short TTI領域内にデータが無い端末装置200は、Short TTIのデータをデコードする必要が無いので、消費電力を低減することが出来るからである。
【0073】
図12は、基地局100が、特定の端末装置向けの情報がShort TTI領域に有るか無いかを通知する方法について説明する説明図である。図12に示したのは、サブフレームのPDCCHにおいて、特定の端末装置向けの情報が同じサブフレーム内のShort TTI領域に有るか無いかを通知する様子である。
【0074】
図13は、基地局100が、特定の端末装置向けの情報がShort TTI領域に有るか無いかを通知する方法について説明する説明図である。図13に示したのは、基地局100が、サブフレームのPDCCHにおいて、特定の端末装置向けの情報が後続のサブフレーム内のShort TTI領域に有るか無いかを通知する様子である。
【0075】
図13に示した方法は、図12に示した方法と同じような方法ではあるが、基地局100が、サブフレームのPDCCHにおいて、特定の端末装置向けの情報が後続のサブフレーム内のShort TTI領域に有るか無いかを通知することで、端末装置200でのShort TTIのデータのデコードの開始タイミングを早めることが可能になる。
【0076】
基地局100は、特定の端末装置向けの情報がShort TTI領域に有るか無いかを通知する際に、PDCCH(またはePDCCH)の端末装置200固有なサーチスペースの中にあるDCIを使用して指定しても良い。図14は、基地局100がPDCCHの端末装置200固有なサーチスペースの中にあるDCIを使用して特定の端末装置向けの情報がShort TTI領域に有るか無いかを通知する例を示す説明図である。
【0077】
基地局100は、PDCCHを使用して動的に通知すれば、Short TTIのデータを送信する場合にだけShort TTI領域にShort TTIのデータを入れれば良いので、リソースを効率的に使用することが出来る。また端末装置200は、Short TTI領域に、それぞれの端末装置200にとって関係するデータがあるかどうかを、少ない手間で判別することができる。また、Short TTI領域内にデータが無い端末装置200は、Short TTIのデータをデコードする必要が無いので、消費電力を低減することが出来るからである。
【0078】
(3)端末装置ごとにShort TTIのリソースを通知する方法
基地局100は、Short TTI領域にShort TTIのデータがあるかどうかをDCIで通知してもよいが、その通知の際に、そのShort TTI領域のどのリソースが、対象の端末装置200が受信してデコードすべきShort TTIのデータであるかも通知しても良い。
【0079】
図15は、基地局100が、Short TTI領域におけるShort TTIのデータの場所をDCIで通知する様子を示す説明図である。図15に示した例では、同一のサブフレームにおける符号305で示した場所が、対象の端末装置200が受信してデコードすべきShort TTIのデータがある場所であるとする。基地局100は、符号305で示した場所にデコードすべきShort TTIのデータがあることを、対象の端末装置200にDCIで通知する。このように通知することで、DCIを受信した端末装置200は、その場所だけを参照してデコードすることができる。
【0080】
図16は、基地局100が、Short TTI領域におけるShort TTIのデータの場所をDCIで通知する様子を示す説明図である。図16に示した例では、後続のサブフレームにおける符号305で示した場所が、対象の端末装置200が受信してデコードすべきShort TTIのデータがある場所であるとする。基地局100は、符号305で示した場所にデコードすべきShort TTIのデータがあることを、対象の端末装置200にDCIで通知する。このように通知することで、DCIを受信した端末装置200は、その場所だけを参照してデコードすることができる。
【0081】
なお、基地局100は、PDCCHではなく、PDSCHの部分に制御信号が入っているePDCCHで、Short TTIに関する情報を通知しても良い。ePDCCHで通知する場合、基地局100は、同一のサブフレームにおけるShort TTIに関する情報を通知してもよく、後続のサブフレームにおけるShort TTIに関する情報を通知してもよい。
【0082】
図17は、本開示の実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。図17に示したのは、基地局100がShort TTIとして使用される可能性のある領域を端末装置200へ通知してから、端末装置200が受信データに対してACKまたはNACKを返すまでの、基地局100及び端末装置200の動作例である。以下、図17を用いて本開示の実施の形態に係る基地局100及び端末装置200の動作例を説明する。
【0083】
基地局100は、サブフレームにおけるShort TTI領域(Short TTIになる可能性のある領域)を端末装置200へ通知する(ステップS101)。ステップS101の処理は、例えば通知部153が実行する。基地局100は、ブロードキャストを用いたシステム情報、または、端末装置200ごとのdedicated signalを用いて、準静的に1つのサブフレームにおけるShort TTIとして使用される可能性のある領域を通知する。
【0084】
基地局100は、Short TTIになる可能性のある領域を端末装置200へ通知すると、続いて、サブフレームごとに、Short TTIになる可能性のある領域が実際にShort TTIとして使用されることを動的に通知する(ステップS102)。ステップS102の処理は、例えば通知部153が実行する。基地局100は、例えば、上述したようにPDCCHの中のDCIにおいて、Short TTIとして使用される可能性のある領域が実際にShort TTIとして使用されるかどうかを指定する。
【0085】
続いて基地局100は、Short TTIの中にある、特定の端末装置200のためのリソースの有無を端末装置200へ通知する(ステップS103)。ステップS103の処理は、例えば通知部153が実行する。
【0086】
続いて基地局100は、Short TTIの中にある、特定の端末装置200が受信すべきリソースの場所を端末装置200へ通知する(ステップS104)。ステップS104の処理は、例えば通知部153が実行する。
【0087】
続いて基地局100は、上記ステップS104で通知したリソースの場所にShort TTIのデータを入れて端末装置200へ送信する(ステップS105)。ステップS105の処理は、例えば送信処理部151が、無線通信部120からアンテナ部110を通じてデータを送信させることにより実行する。
【0088】
端末装置200は、上記ステップS101〜S104において基地局100から通知される情報に基づいて、上記ステップS105で基地局100から送信されたShort TTIのデータをデコードする(ステップS106)。ステップS106の処理は、例えば受信処理部243が実行する。
【0089】
端末装置200は、ステップS106でShort TTIのデータをデコードすると、基地局100に対し、デコードに成功すればACKを、失敗すればNACKを、それぞれ通知する(ステップS107)。ステップS107の処理は、例えば通知部245が実行する。
【0090】
従来のeNodeBは、PDCCHの中のDCIにおいて各UEに対するリソースを個々に指定していた。しかしShort TTIのリソースは、従来のTTIのリソースとは異なり、特殊である。その特殊なShort TTIが常に存在するとは限らないため、Short TTI領域は、ある程度可変にすることが望ましい。しかし、Short TTI領域と通常のTTI領域とが確定しないと、PDCCHから直接リソースの指定ができないことから、PDCCHからShort TTIのリソースを直接指定することは困難である。
【0091】
従って本実施形態の第1の動作例では、基地局100は、準静的にShort TTI領域を指定するとともに、そのShort TTI領域が存在するかどうかを動的に指定する。基地局100は、端末装置200に対して、その端末装置200のShort TTIのデータがあるかどうかを、PDCCHを使った動的な方法や、dedicated signalingを用いた準静的な方法で通知する。このように通知することにより、従来のPDCCHで全てリソースを直接指定した方法に比べて、通常TTIのリソース、Short TTIのリソースともに従来に比べて効率的な運用が可能になる。
【0092】
本実施形態の第1の動作例は、準静的にShort TTI領域を指定するとともに、そのShort TTI領域が存在するかどうかを動的に指定することで、端末装置200に搭載されているアプリケーションを基地局100が低遅延で、かつレスポンス良く制御することが可能になる。また本実施形態の第1の動作例は、端末装置200がACKまたはNACKを早く返すことが可能なので、スループットの向上が見込まれる。そして、本実施形態の第1の動作例は、効率的にShort TTIのリソースを既存のTTIのリソースと混在することができるので、リソースの無駄が生じず、かつスループットの向上が大いに期待できる。
【0093】
(1.4.2.第2の動作例)
続いて、本開示の実施形態に係る基地局100及び端末装置200の第2の動作例を説明する。上述したように、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、基地局側が様々なレベルのShort TTIを用意しておくことが、Short TTIに対応した端末装置の普及に繋がる。第2の動作例では、様々なレベルのShort TTIを用意した際の基地局100及び端末装置200の動作例を説明する。
【0094】
図18は、1OFDMシンボルで構成されるShort TTIを示す説明図である。1OFDMシンボルで構成されるShort TTIをレベル1のShort TTIとも称する。また図19は、2OFDMシンボルで構成されるShort TTIを示す説明図である。2OFDMシンボルで構成されるShort TTIをレベル2のShort TTIとも称する。
【0095】
Short TTIのレベルが1の場合には、LTEのリソースが無駄に占有されて全体のスループットが低下する。その理由としては、Short TTIに対応した全ての端末装置200が同じようなShort TTIのレベルを必要としない場合があるからである。また、Short TTIに対応した全ての端末装置200が、同じようにShort TTIのレベルを実現できるとは限らない。従って、通信事業者が複数のShort TTIのレベルを用意しておくことにより、様々なベンダー(メーカー)が製造するShort TTIに対応する端末装置200が、複数のShort TTIのレベルを用意するLTEネットワークに接続することが可能になる。
【0096】
基地局100は、複数のShort TTIのレベルを用意する。Short TTIのレベルの設定はセル毎に異なっていてもよい。基地局100は、その基地局100が提供する複数のShort TTIのレベルを、ブロードキャストで、例えばシステムインフォメーションで端末装置200に通知しておく。
【0097】
端末装置200は、処理能力(例えばハードウェア的な能力や、実行するアプリケーションのカテゴリや、自装置のケイパビリティ)を基地局100に通知する。また端末装置200は、実行するアプリケーション毎に要求する遅延レベルを設定してもよい。端末装置200に低遅延で処理できる能力があっても、その端末装置200が実行するアプリケーションによっては低遅延を求めない場合もあるからである。
【0098】
端末装置200は、同じサブフレームの中で複数のレベルのShort TTIが混在して状態であっても、その複数のレベルのShort TTIのデータを処理してもよい。また、端末装置200は、通常のTTIのデータとShort TTIのデータとを並行して処理しても良い。
【0099】
図20は、本開示の実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。以下、図20を用いて本開示の実施の形態に係る基地局100及び端末装置200の動作例について説明する。
【0100】
基地局100は、提供可能なShort TTIのレベルを、セル内に位置する端末装置200に向けてブロードキャストで提供する(ステップS201)。ステップS201の処理は、例えば通知部153が実行する。
【0101】
基地局100が提供可能なShort TTIのレベルを基地局100から受信した端末装置200は、Short TTIを処理できるケイパビリティを基地局100に通知する(ステップS202)。ステップS202の処理は、例えば通知部245が実行する。このステップS202で、端末装置200は、ハードウェア的な処理能力の情報を基地局100に通知してもよい。
【0102】
また端末装置200は、搭載しているアプリケーションの用途に従って、Short TTIのレベルを基地局100に要求する(ステップS203)。ステップS203の処理は、例えば通知部245が実行する。
【0103】
基地局100は、端末装置200からShort TTIを処理できるケイパビリティ及びShort TTIのレベルの要求を受信すると、受信した内容に基づいて、Short TTIのレベルを選択し、端末装置200に対して、Short TTIのリソースを使用して、選択したレベルに応じたShort TTIのデータを送信する(ステップS204)。ステップS204の処理は、例えば送信処理部151が、無線通信部120からアンテナ部110を通じてデータを送信させることにより実行する。
【0104】
本開示の実施の形態に係る基地局100は、このように動作することで、端末装置200の能力や要求に応じたShort TTIのレベルを選択することが出来る。また本開示の実施の形態に係る端末装置200は、このように通知することで、自装置の能力や、実行するアプリケーションの要求に応じたレベルでShort TTIのデータを受信することが出来る。
【0105】
端末装置200の中には、小さいShort TTIのレベルでデータを受信しても、遅延時間がそのレベルより長くても許容できるものがあることも考えられる。図21は、一つのサブフレームにおけるShort TTI領域の例を示す説明図である。例えば、ある端末装置200は、Short TTIレベル1でデータを受信しても、2OFDMシンボルの遅延が許容できるとする。その場合、基地局100は、その端末装置200に、図21に示したように1OFDMシンボルおきにShort TTIとして使用させる。符号311で示したOFDMシンボルがその端末装置200にShort TTIとして使用させるOFDMシンボルである。このように基地局100は、Short TTI領域を1OFDMシンボルおきに端末装置200に使用させることで、2OFDMシンボルの遅延が許容できる端末装置200へのリソースを効率的に提供すること出来る。
【0106】
図21に示したShort TTI領域は、図19に示した2OFDMシンボルで構成されるShort TTIとは異なり、1OFDMシンボルで構成されるShort TTIのリソースが間引かれている。基地局100は、間引いたリソース(符号312で示したOFDMシンボル)を他の端末装置200に使用させることができる。すなわち、基地局100は、1OFDMシンボルで構成されるShort TTIのリソースを1OFDMシンボルおきに間引くことで遅延制御のレベルを下げていることになる。なお、1OFDMシンボルの遅延を要求する端末装置200は、図21の符号311、312のいずれのOFDMシンボルのリソースで基地局100からShort TTIのデータを受信しても良い。
【0107】
図19に示したような2OFDMシンボルで構成されるShort TTIは、1つのサブフレームで完結させることができる。しかし、例えば4OFDMシンボルで構成されるShort TTIは、1つのサブフレームで完結させることができない。図22は、4OFDMシンボルで構成されるShort TTIを示す説明図である。Short TTIを4OFDMシンボルで構成するレベル4のShort TTIは、1つのサブフレームで完結させることができないので、図22に示したように、2つのフレームにまたがる箇所が生じる。この場合、基地局100は、Short TTIのデータが2つのフレームにまたがっているのかどうかを端末装置200に通知する。
【0108】
システムフレーム番号(System Frame Number;SFN)は0から1023までの整数が繰り返される。またサブフレームは1つのフレームに10個存在する。図23は、1フレームにおける、4OFDMシンボルで構成されるShort TTIを示す説明図である。4OFDMシンボルでShort TTIが構成される場合、図23に示したように、1番目のサブフレームと2番目のサブフレームにまたがって4OFDMシンボルで構成されるShort TTIが配置されている。すなわち、奇数番目のサブフレームと偶数番目のサブフレームとにまたがって4OFDMシンボルで構成されるShort TTIが配置されている。従って、システムフレーム番号及びサブフレーム番号と、Short TTIのフェーズとの関係を基地局100から端末装置200に通知できれば、端末装置200は、4OFDMシンボルのShort TTIを正常に受信できる。
【0109】
SFNは、基地局100から端末装置200へ、MIB(Master Information Block)というブロードキャスト信号で送信されている。従って、基地局100は、システムフレーム番号及びサブフレーム番号と、Short TTIのフェーズとの関係を予め固定しておくか、システムフレーム番号及びサブフレーム番号と、Short TTIのフェーズとの関係をシグナリングで端末装置200に別途通知する。
【0110】
図24は、本開示の実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。図24に示したのは、Short TTIが1つのサブフレームで完結させることができない場合の基地局100及び端末装置200の動作例である。以下、図24を用いて本開示の実施の形態に係る基地局100及び端末装置200の動作例について説明する。
【0111】
基地局100は、MIB等、ブロードキャストでシステムフレーム番号を端末装置200に提供する(ステップS211)。ステップS211の処理は例えば通知部153が実行する。
【0112】
続いて基地局100は、提供可能なShort TTIのレベルを、セル内に位置する端末装置200に向けてブロードキャストで提供する(ステップS212)。ステップS212の処理は、例えば通知部153が実行する。
【0113】
続いて基地局100は、各レベルのShort TTIと、システムフレーム番号及びサブフレーム番号との対応関係を、端末装置200に向けてブロードキャストまたはdedicated signalingで提供する(ステップS213)。ステップS213の処理は、例えば通知部153が実行する。なお、各レベルのShort TTIと、システムフレーム番号及びサブフレーム番号との対応関係は、予めスペックで固定でも構わない。
【0114】
基地局100が提供可能なShort TTIのレベルを基地局100から受信した端末装置200は、Short TTIを処理できるケイパビリティを基地局100に通知する(ステップS214)。ステップS214の処理は、例えば通知部245が実行する。
【0115】
また端末装置200は、搭載しているアプリケーションの用途に従って、Short TTIのレベルを基地局100に要求する(ステップS215)。ステップS215の処理は、例えば通知部245が実行する。
【0116】
基地局100は、端末装置200からShort TTIを処理できるケイパビリティ及びShort TTIのレベルの要求を受信すると、受信した内容に基づいて、Short TTIのレベルを選択し、端末装置200に対して、Short TTIのリソースを使用して、選択したレベルに応じたShort TTIのデータを送信する(ステップS216)。ステップS216の処理は、例えば送信処理部151が、無線通信部120からアンテナ部110を通じてデータを送信させることにより実行する。
【0117】
端末装置200は、基地局100からShort TTIのデータを受信すると、ステップS213で基地局100から受信した対応関係に基づいてShort TTIのデータをデコードする。
【0118】
本開示の実施の形態に係る基地局100は、このように動作することで、端末装置200の能力や要求に応じたShort TTIのレベルを選択することが出来るとともに、端末装置200に正常にShort TTIのデータをデコードさせることが出来る。また本開示の実施の形態に係る端末装置200は、このように通知することで、自装置の能力や、実行するアプリケーションの要求に応じたレベルでShort TTIのデータを受信するとともに、正常にShort TTIのデータをデコードすることが出来る。
【0119】
1つのサブフレームには複数のレベルのShort TTIが混在していても良い。図25は、1つのサブフレームに複数のレベルのShort TTIが混在している例を示す説明図である。
【0120】
図25には、1つのサブフレームに、4OFDMシンボルからなるレベル4のShort TTIと、2OFDMシンボルからなるレベル2のShort TTIと、が混在している例が示されている。図25の例では、最初のサブフレームにはレベル4のShort TTIが3つ続いて配置された後にレベル2のShort TTIが1つ配置され、次のサブフレームには最初にレベル2のShort TTIが1つ配置された後にレベル4のShort TTIが3つ続いて配置されている。もちろん、配置パターンは係る例に限定されるものでは無い。全てのサブフレームにおいて異なるレベルのShort TTIが同じパターンで混在して配置されてもよい。例えば、全てのサブフレームにおいて、レベル4のShort TTIが3つ続いて配置された後にレベル2のShort TTIが1つ配置されてもよい。また例えば、全てのサブフレームにおいて、最初にレベル2のShort TTIが1つ配置された後にレベル4のShort TTIが3つ続いて配置されてもよい。
【0121】
図26は、Short TTIの別の配置例を示す説明図である。サブフレームには、通常、先頭部分に制御信号が格納されうるPDCCHが配置され、PDCCHの後にユーザデータが格納されうるPDSCHが配置されている。例えば、図26に示したように3OFDMシンボルをPDSCHで使用し、後続のPDSCHの部分だけをShort TTIとすることを考える。この場合、レベル2のShort TTIだけで使用しようとすると、サブフレームの最後の1OFDMシンボル分はレベル2のShort TTIとして使用できない。そこで、図26に示したように、サブフレームの最後の1OFDMシンボル分をレベル1のShort TTIとして使用してもよい。なお、図26に示したように、基地局100は、あるOFDMシンボルをレベル1のShort TTIとレベル2のShort TTIとでリソースを分けて使用しても良い。
【0122】
図27は、Short TTIの配置例を示す説明図である。図27に示したShort TTIの配置例が、図26に示したShort TTIの配置例と異なるのは、サブフレームの最後の1OFDMシンボル分において、レベル2のShort TTIが配置されているリソースにはShort TTIが配置されていない点である。
【0123】
図26図27に示したように、基地局100は、あるOFDMシンボルをレベル1のShort TTIとレベル2のShort TTIとでリソースを分けて使用しても良いが、それぞれのShort TTIに割り当てるリソースの量を変化させても良い。図26図27には、レベル2のShort TTIに割り当てるリソースの量がレベル1のShort TTIに割り当てるリソースの量と比べて多い例が示されている。基地局100は、それぞれのレベルのShort TTIに割り当てるリソースの量を、例えば端末装置200からの需要に応じて変化させても良い。
【0124】
図26図27に示したように、PDCCHの部分にはShort TTIを配置せず、PDSCHの部分にのみShort TTIを配置する場合、PDCCHの長さは1OFDMシンボルから3OFDMシンボルまで可変である。基地局100は、PDCCHの長さの情報(OFDMシンボル数の情報)を、PDCCHの中にあるPCFICH(Physical Control Format Indicator Channel)で端末装置200に通知することが出来る。PDCCHの長さは1OFDMシンボルから3OFDMシンボルまで可変であるので、PDSCHの長さは11OFDMシンボルから13OFDMシンボルまで可変である。従って、PDSCHの部分にのみShort TTIを配置する場合、この可変であるPDSCHとShort TTIの配置パターンとの関係を端末装置200に知らせておくことが望ましい。
【0125】
図28は、Short TTIの配置例を示す説明図である。図28に示したのは、PDCCHの長さが3OFDMシンボル、すなわちPDSCHの長さが11OFDMシンボルの場合におけるShort TTIの配置例である。図28に示した例では、1つのOFDMシンボルをレベル1のShort TTIとレベル2のShort TTIとでリソースを分けて使用している。
【0126】
図29は、Short TTIの配置例を示す説明図である。図29に示したのは、PDCCHの長さが2OFDMシンボル、すなわちPDSCHの長さが12OFDMシンボルの場合におけるShort TTIの配置例である。図29に示した例でも、1つのOFDMシンボルをレベル1のShort TTIとレベル2のShort TTIとでリソースを分けて使用している。
【0127】
図30は、Short TTIの配置例を示す説明図である。図30に示したのは、PDCCHの長さが1OFDMシンボル、すなわちPDSCHの長さが13OFDMシンボルの場合におけるShort TTIの配置例である。図30に示した例でも、1つのOFDMシンボルをレベル1のShort TTIとレベル2のShort TTIとでリソースを分けて使用している。
【0128】
このようにPDCCHの長さ(すなわちPDSCHの長さ)に応じてShort TTIの配置パターンが変化する場合、基地局100は、予め端末装置200にPDSCHとShort TTIの配置パターンとの関係を通知しておく。そして基地局100は、PCFICHでPDCCHの長さの情報を端末装置200に通知する。端末装置200は、PDCCHの長さの情報を知ることにより、Short TTIがどの配置パターンとなるかを知ることが出来る。
【0129】
図31は、本開示の実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。以下、図31を用いて本開示の実施の形態に係る基地局100及び端末装置200の動作例について説明する。
【0130】
基地局100は、まずPCFICHに対応した、Short TTIの配置パターンを端末装置200に通知する(ステップS221)。ステップS221の通知は、例えば通知部153が実行する。PCFICHに対応した、Short TTIの配置パターンは、予めスペックで固定されていてもよい。
【0131】
続いて基地局100は、PCFICHでPDCCHの長さの情報を端末装置200に通知する(ステップS222)。ステップS222の通知は、例えば通知部153が実行する。
【0132】
続いて基地局100は、PCFICHに対応した、Short TTIを提供する(ステップS223)。ステップS223の処理は、例えば送信処理部151が、無線通信部120からアンテナ部110を通じてデータを送信させることにより実行する。例えば、PDCCHの長さが3OFDMシンボルの場合のShort TTIの配置パターンが図28に示したようなパターンである場合は、基地局100は、図28に示したようなShort TTIの配置パターンでShort TTIを提供する。
【0133】
端末装置200は、PCFICHに対応した、Short TTIの配置パターンを知り、PCFICHでPDCCHの長さの情報の通知を受けると、PCFICHに対応してShort TTIの配置を判別し、Short TTIのデータのデコード処理を実行する(ステップS224)。ステップS224の処理は、例えば受信処理部243が実行する。
【0134】
端末装置200は、上述した動作を実行することで、PDCCHの長さの情報を知ることにより、Short TTIがどの配置パターンとなるかを知ることが出来る。そして端末装置200は、Short TTIの配置パターンを予め知ることで、Short TTIのデータの適切なデコード処理を実行することができる。
【0135】
Short TTIのレベルを、例えば図21を用いて説明したようにOFDMシンボルごとに間引いて、間欠的に配置することで実現する場合、同様にPDCCHの長さに応じてShort TTIの配置パターンも変化する。
【0136】
図32は、Short TTIの配置例を示す説明図である。図32に示したのは、PDCCHの長さが3OFDMシンボル、すなわちPDSCHの長さが11OFDMシンボルの場合におけるShort TTIの配置例である。図32に示した例では、レベル1のShort TTIを、OFDMシンボルごとに間引いて、間欠的に配置することで実現している。
【0137】
図33は、Short TTIの配置例を示す説明図である。図33に示したのは、PDCCHの長さが2OFDMシンボル、すなわちPDSCHの長さが12OFDMシンボルの場合におけるShort TTIの配置例である。図33に示した例でも、レベル1のShort TTIを、OFDMシンボルごとに間引いて、間欠的に配置することで実現している。
【0138】
図34は、Short TTIの配置例を示す説明図である。図34に示したのは、PDCCHの長さが1OFDMシンボル、すなわちPDSCHの長さが13OFDMシンボルの場合におけるShort TTIの配置例である。図34に示した例でも、レベル1のShort TTIを、OFDMシンボルごとに間引いて、間欠的に配置することで実現している。
【0139】
このようにShort TTIのレベルを、例えば図21を用いて説明したようにOFDMシンボルごとに間引いて、間欠的に配置することで実現する場合であっても、図31に示した動作例と同様に、基地局100から予めShort TTIの配置パターン及びPCFICHによるPDCCHの長さの情報を端末装置200に通知する。端末装置200は、Short TTIのレベルをOFDMシンボルごとに間引くことで実現する場合であっても、PDCCHの長さの情報を知ることにより、Short TTIがどの配置パターンとなるかを知ることが出来る。そして端末装置200は、Short TTIの配置パターンを予め知ることで、Short TTIのデータの適切なデコード処理を実行することができる。
【0140】
(1.4.3.第3の動作例)
続いて、本開示の実施形態に係る基地局100及び端末装置200の第3の動作例を説明する。上述したように、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な処理を可能にするための技術が必要になる。第3の動作例では、第1の動作例とは別の観点から、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な処理を可能にするための動作例を説明する。
【0141】
Short TTIは、基地局100や基地局100の奥のネットワークから端末装置200に搭載されるアプリケーションを低遅延で制御するような用途が想定されている。従って、データがS−GWや基地局100にキャッシュされていて、そのキャッシュ(バッファリング)されていたものを提供する方法とは異なり、Short TTIでは、ネットワークの奥のP−GWに繋がるインターネット等から、少量の制御データが必要となる時間にその都度到来してくる。その少量の制御データが、いつ基地局100から端末装置200に送信できるかは、その少量の制御データが基地局100に到来してみないと基地局100はわからないという状況である。端末装置200に搭載されるアプリケーションとしては、ドローンを制御するアプリケーションソフトや、車を制御するアプリケーションソフト等がありうる。このように、Short TTIでは、少量のデータであるが、低遅延でデータを基地局100から端末装置200に届ける必要があるというユースケースが想定されうる。第3の実施形態では、低遅延でデータを基地局100から端末装置200に届けるために必要なスケジューリング技術を説明する。ここで、スケジューリングとは、端末装置200が使用すべきダウンリンクリソースの場所を基地局100が端末装置200に通知することを指す。
【0142】
ドローンを制御するアプリケーションソフトや、車を制御するアプリケーションソフト以外のユースケースとしては、例えばゲームの同期が挙げられる。ネットワークゲームには、複数のユーザが、ネットワークを介して、地図上の位置を同期する必要があるゲームが多く見受けられる。図35は、ネットワークゲームを実行する各ユーザの端末装置200に表示される地図の例を示す説明図である。図35には、2人のユーザの位置が表示される地図の例が示されている。図35に示したように、複数のユーザが共通の町の地図の中で、お互いを攻撃するようなゲームは、それぞれのユーザの地図上での位置が同期している必要がある。同期していないと、あるユーザの端末装置では目の前に相手がいると思ってそのユーザが相手を攻撃しても、実際にはその相手は離れたところに移動している場合があるからである。このような地図上でのユーザの位置の同期が必要となるアプリケーションは、低遅延で、お互いの位置が同期して更新される必要がある。
【0143】
まず、既存のLTEのダウンリンクのスケジューリングについて説明する。1つのリソースブロックは12個のサブキャリアで構成されている。サブキャリアの間隔は15kHzである。従ってリソースブロックの周波数方向の幅は180kHzである。20MHzのバンド幅の場合、その20MHzの中に100個のリソースブロックを配置することができる。ただし、その100個のリソースブロックをそのまま扱うと、スケジューリングに必要なビット数が100ビットとなってしまう。そこで、4リソースブロックを1つのグループにまとめたリソースブロックグループ(RBG)という概念を導入している。4リソースブロックを1つのRBGとして、RBG単位でスケジューリングすると、スケジューリングに必要なビット数を25ビットまで少なくできる。すなわち、eNodeBは、25RBGの内、あるUEがどのRBGを使うかを、25ビットのビットマップで構成されるスケジューリング情報をUEに通知している。1サブフレーム内に1スロット目のRBGと2スロット目のRBGがあるが、通常は、両方とも同じスケジューリングが行われる。図36は、1つのサブフレームに1スロット目のRBGと2スロット目のRBGがあることを示す説明図である。#0のサブフレームのPDCCHの中にあるDCIの中に、25ビットのスケジューリング情報が含まれる。25ビットのスケジューリング情報がが、#0のサブフレームの中のRBGを指定している。スケジューリング情報は、1つのUEのためのものであり、25ビット全てが1の場合には、#0のサブフレームの全てのリソースブロックを1台のUEが使用することになる。他にも、例えば、“0001000000000010000000000”とスケジューリング情報をeNodeBが指定することで、離れた周波数のリソースを1台のUEが使用することも可能である。
【0144】
Short TTIのリソースブロック(Short PRB:Short PHY resource Block)が導入されると、時間方向の分解能が細かくなる。従来のスケジューリング方法には時間方向の分解能が無かった。従来は、上述したように周波数方向にリソースブロックをグループ化して、RBGとしてスケジューリング情報のビットマップを圧縮することはできたが、Short TTIのように時間方向の分解能が細かくなった場合には対応できない。
【0145】
もし、時間方向の14OFDMシンボルの内、先頭の3OFDMシンボルがPDCCHで使用された場合には、Short TTIを1OFDMシンボルにした場合には、Short TTIは、サブフレーム内に時間方向に11個配置することができる。周波数方向に25ビットで25個のRBGに対してリソースを指定して、かつ時間方向に11ビットでリソースを指定したとすると、Short TTIの最小リソースは、25×11=275ビット、すなわち、従来の25ビットの11倍のビットが必要になってしまう。1台のUEのShort TTIのリソースを指定するために、通常のTTIに25ビット、Short TTIの275ビットの、合計300bitをPDCCHの中のDCIに含ませることは、PDCCHの領域が限られているために不可能である。
【0146】
そこで、時間方向のレゾルーションを無視することでShort TTIのスケジューリングを行う方法を説明する。基地局100は、周波数方向のスケジューリングについては、従来と同じようにビットマップを使ってRBGを指定する。1OFDMシンボルをTTIとするレベル1のShort TTIの場合には、PDCCHが3OFDMシンボルを占めたとすると、PDSCHは11OFDMシンボルなので、最大11個のShort TTIが1サブフレーム内に配置される。ここで、1サブフレーム内に配置される11個のShort TTIは、全て同じ端末装置200に割り当てるとする。図37は、Short TTIの端末装置200への割り当て例を示す説明図であり、1サブフレーム内に配置される11個のShort TTIを全て同じ端末装置200に割り当てる様子を示す説明図である。時間方向のレゾルーションを無視する方法を用いることにより、Short TTIを導入する際のスケジューリング情報の増加を最小限にすることができる。
【0147】
Short TTI用に追加するスケジューリング情報は、そのスケジューリング情報のビットマップがShort TTI用なのかどうかを区別する必要がある。従って、従来のTTI用のビットマップに加えて、新たにShort TTI用のビットマップを用意する必要がある。
【0148】
バンド幅が20MHzで、RBGが25個ある場合には、通常のTTI用のスケジューリング情報のビットマップは25ビットであり、Short TTI用のスケジューリング情報のビットマップも25ビットである。すなわち、通常のTTI用とShort TTI用とで合わせて50ビットのビットマップを用意する。図38は、1台の端末装置200に通常のTTIとShort TTIとをスケジューリングした様子を示す説明図である。また表1は、図38のようにスケジューリングする場合の、通常のTTI用とShort TTI用とのスケジューリング情報のビットマップの例を示す説明図である。このビットマップでは、0は通常のTTIまたはShort TTIで使用しないRBGであり、1は通常のTTIまたはShort TTIで使用するRBGであることを意味する。
【0149】
【表1】
【0150】
このように、Short TTIのリソースブロックを導入すると時間方向に11ビットでリソースを指定すると、スケジューリング情報が合計で300ビット必要であったところ、時間方向のレゾルーションを無視することで時間方向のレゾルーションを無視することでスケジューリング情報を合計で50ビットまで減らすことができた。
【0151】
図39は、本開示の実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。図39に示したのは、基地局100がShort TTI用のスケジューリング情報を通知する際の基地局100及び端末装置200の動作例である。以下、図39を用いて本開示の実施の形態に係る基地局100及び端末装置200の動作例を説明する。
【0152】
基地局100は、端末装置200に向けて、25個のRBGの内、Short TTI用のRBGであることをビットマップで準静的に通知する(ステップS301)。ステップS301の処理は、例えば通知部153が実行する。基地局100は、ビットマップで準静的に通知する際には、システム情報やdedicated signalingを用いる。
【0153】
続いて基地局100は、PDCCHでRBGのスケジューリングを行う(ステップS302)。ステップS302の処理は、例えば通知部153が実行する。
【0154】
端末装置200は、スケジューリングされたRBGがShort TTIなのか、通常のTTIなのかを知った上で、基地局100から送信されたデータをデコードする(ステップS303)。ステップS303の処理は、例えば受信処理部243が実行する。
【0155】
続いて、Short TTIのスケジューリング情報をさらに減少させる方法を説明する。例えば、基地局100は、1つのサブフレームにおける25個のRBGのうち、どれがShort TTIであるかを、事前にRRCシグナリングを用いて端末装置200ごとに通知してもよい。また例えば、基地局100は、端末装置200ごとではなく、そのRBGは常にShort TTIであることを端末装置200へのブロードキャストを用いたシステム情報の中で指定してもよい。このように、事前にShort TTIであるRBGが指定されていれば、Short TTIであることを指し示すための追加の25ビットのスケジューリング情報は必要無くなり、制御ビットによるオーバーヘッドを減らすことが可能になる。
【0156】
上述した方法では、RBG単位でのスケジューリング、すなわち、周波数方向のスケジューリングは動的に、つまりサブフレーム単位で行うことが出来る。一方で、1つのサブフレームにおけるShort TTIレベルでのスケジューリングは行っていない。従って、PDCCHが3OFDMシンボルを占めたとすると、PDSCHは11OFDMシンボルなので、11OFDMシンボルを全て、同じ端末装置200が使用する場合に向いた方法であると言える。
【0157】
その一方で、例えば、11OFDMシンボルのうち、先頭のOFDMシンボルにのみデータが存在し、残りのOFDMシンボルにはデータが存在しない(ヌルデータが入っている)としても、端末装置200は全てのOFDMシンボルについてShort TTIのデコードを試みることになる。
【0158】
Short TTIが1つのサブフレーム内で時間方向に11個ある場合に、最初の2個のShort TTIにその端末装置200のためのデータが入っていて、残りの9個が空の場合に、端末装置200が11個全てのShort TTIのデータをデコードすることは無駄であり、端末装置200の電力消費量が無駄に増加する。
【0159】
そこで、基地局100は、例えば、あるOFDMシンボルより後はShort TTIのデータをデコードする必要がないことが確定している場合には、そのOFDMシンボルのShort TTIのデータの中に、このサブフレームではこのデータで終了であることを示す情報を入れておく。図40は、11OFDMシンボルのうち、先頭の2つのOFDMシンボルにのみShort TTIのデータが入っていることを示す説明図である。基地局100は、2つ目のOFDMシンボルのShort TTIのデータの中に、このサブフレームではこのデータで終了であることを示す情報を入れておく。このようにすることにより、端末装置200は、先頭の2個のShort TTIのデータだけをデコードすれば良く、電力消費を、Short TTIのデータのデコードに必要な分の消費にとどめることができる。
【0160】
図40に示したように、11OFDMシンボルのうち、先頭の2つのOFDMシンボルにのみShort TTIのデータが入っている場合に、残りの9つのOFDMシンボルを有効に活用するための方法を説明する。
【0161】
図41は、3台の端末装置200がそれぞれShort TTIのデータをデコードする場合の例を示す説明図である。図41は、UE Aとして示した端末装置200が1番目と2番目のOFDMシンボルにおけるShort TTIのデータを、UE Bとして示した端末装置200が3番目から7番目のOFDMシンボルにおけるShort TTIのデータを、UE Bとして示した端末装置200が8番目から11番目のOFDMシンボルにおけるShort TTIのデータを、それぞれデコードする場合の例が示されている。
【0162】
このように、1つのサブフレームで複数の端末装置200がそれぞれShort TTIのデータをデコードする場合、基地局100は、それぞれの端末装置200に対して開始位置を指定するデータを含めて送信しても良い。UE Aは、自身宛のデータが1番目のOFDMシンボルから始まることを、基地局100からの送信データにより知ることが出来る。一方、UE BとUE Cは、1番目のOFDMシンボルのデータは自身宛のデータでは無いことを、基地局100からの送信データにより知ることが出来るので、デコードを行わないようにすることが出来る。
【0163】
同様に、UE Bは、自身宛のデータが3番目のOFDMシンボルから始まることを、基地局100からの送信データにより知ることが出来、UE Cは、自身宛のデータが8番目のOFDMシンボルから始まることを、基地局100からの送信データにより知ることが出来る。基地局100は、終了位置の情報を、図40を用いて説明した方法と同様に、それぞれの端末装置200に向けたものとして通知する。
【0164】
図41に示した例では、3台の端末装置200のリソースが重なることなく、一つのRBGの中で多重されている。図41に示したように3台の端末装置200に向けてデータを送信することで、リソースの無駄は完全に無くなっている。そして、1台の端末装置200には開始位置と終了位置との間の連続したリソースのみ割り当てることになっている。
【0165】
PDCCHの中のDCIで必要となるスケジューリング情報は、通常のTTIのRBGを指定するスケジューリングに必要な25ビットに加え、Short TTIのRBGのスケジューリングに25ビット、時間方向の11個のShort TTIの先頭位置を示すために4ビットが必要になるため、25個のRBG全体では25×4=100ビットが必要になる。従って、スケジューリング情報は合計で25ビット+25ビット+100ビット=150ビットとなる。
【0166】
このスケジューリング情報を圧縮する方法を説明する。基地局100は、先頭位置と終了位置をRBG毎に指定することにより、リソースの無駄を無くすとともに、端末装置200での無駄なデコードも減らすことができた。しかし、そのためにDCIに100ビットのスケジューリング情報を追加することになる。スケジューリング情報の増加は、スケジューリング情報に起因するオーバーヘッドの増加にも繋がるため、スケジューリング情報は少ない方が好ましい。
【0167】
例えば、仕様によって、1台の端末装置200で1つのサブフレームあたり、許可するShort TTIを最大で3つに制限する。この制限は、可変でも良いし、システムとして固定でも良い。このようにShort TTIの数を制限することにより、Short TTI用のスケジューリング情報の25ビットの中に、0ではなく1となるのは最大で3つだけであると、端末装置200は仮定することができる。そして、その3つに対応するRBGの11個のShort TTIを指定するために、4ビット×3=12ビットを追加すれば良いので、スケジューリング情報は合計で25ビット+25ビット+12ビット=62ビットとなる。この62ビットのスケジューリング情報が、DCIの中の1台の端末装置200に宛てたスケジューリングの割り当てのために必要となる。これにより、上述の150ビットから大幅にビット数を減らすことが出来るので、端末装置200でのオーバーヘッドの削減に寄与する効果が期待できる。
【0168】
Short TTIのデータは少量であり、間欠的に端末装置200が受信するものである。それにも関わらず、上で述べたように、1サブフレーム内にShort TTIのリソースを1台の端末装置200のために全て割り当ててしまうとリソースの無駄が大きくなる。従って、1サブフレーム内での異なるShort TTIは異なる端末装置200に使用させることが望ましい。
【0169】
そこで、基地局100が上述のように11個のShort TTIがあるRBGを指定した後に、端末装置200は、その11個のShort TTIの中で、どれが自分宛か分からない状態で、その11個のShort TTI全てをデコードする。図42は、端末装置200が11個のShort TTI全てをデコードすることを説明する説明図である。このようなデコード方法は、ブラインドデコーディング(Blind Decoding)と呼ばれている。通常はUEがPDCCHのDCIをデコードする時にブラインドデコーディングを行っている。本動作例では、端末装置200がShort TTIをデコードする場合にも、このブラインドデコーディングを適用する。
【0170】
図43は、Short TTIの宛先と、ある端末装置200でのCRCチェックの結果の例を示す説明図である。図43に示した例では、ある端末装置200は、11個のShort TTIの内、自分宛のShort TTIのデータが4つあるので、そのデータについてはCRCチェックの結果がOKとなり、他のUE宛のShort TTIのデータが7つあるので、そのデータについてはCRCチェックの結果がNGとなる。
【0171】
図43に示したように、1つのサブフレームにおけるShort TTIのデータの中には、自分宛のデータと、他のUE宛てのデータと混在しうる(もちろん、自分宛のデータが全く存在しない可能性もありうる)。基地局100は、端末装置200に固有のID(C−RNTI等)でデータをCRCする。従って、端末装置200は、自分宛のデータをデコードした時以外は、CRCの結果がOKにならない。端末装置200は、他のユーザ(他の端末装置200)のためのデータもデコードするので、CRCがエラーになる部分とエラーにならない部分がある。しかし端末装置200は、CRCがエラーになったからと言って、データ失敗のNACKを基地局100に返信しない。なぜなら、そのデータは他のユーザ(他の端末装置200)のデータであったかもしれないからである。端末装置200は、CRCがエラーになった場合、NACKの返し方を以下の3つの方法の中からとりうる。
【0172】
(1)第1の方法
第1の方法は、NACKは一切返さない方法である。端末装置200は、CRCがエラーになっても、NACKを一切返さない。この方法では、基地局100は、端末装置200が本当にデータを受信できたかどうかを知り得ない。
【0173】
(2)第2の方法
第2の方法は、指定されたShort TTI領域の中のリソースで1つでもCRCの結果がOKのものがあればNACKを返さず、CRCの結果が全てNGの場合にNACKを返す方法である。この方法は、端末装置200は、Short TTI毎にACKまたはNACKを返すわけでは無い。しかしこの方法は、最初の方法に比べれば、基地局100は、データを正しく送信できたかどうかを部分的にではあるが知ることが出来る。
【0174】
(3)第3の方法
第3の方法は、例えばShort TTIが11個ある場合、その11個のShort TTIのデータの内、自身宛のデータが何個あるかを基地局100から取得して、指定された個数とCRCチェックの結果がOKの個数が同じであればACKを、違っていればNACKを返す方法である。端末装置200が、11個のShort TTIのデータの内、自身宛のデータが何個あるかを、予め基地局100から取得できない場合にはこの方法は使えない。しかし、端末装置200が、次のサブフレームにおけるDCIフォーマットの中で、前のサブフレームに自身宛のデータが何個あるかを基地局100から取得することが出来れば、端末装置200は、その基地局100から取得した個数の情報に基づいてACKまたはNACKを返すことが出来る。
【0175】
また、基地局100が、サブフレーム内で、ある端末装置200に向けたデータはここで最後であるという情報、および、当該サブフレームでその端末装置200宛に送信したデータの個数の情報を入れておくことで、端末装置200は、そのサブフレームには自身宛のデータがいくつあったかを知ることが出来る。図44は、基地局100が、端末装置200に向けて送信する情報について示す説明図である。図44は、基地局100が、サブフレーム内で、ある端末装置200に向けたデータはここで最後であるという情報、および、当該サブフレームでその端末装置200宛に送信したデータの個数の情報を入れている例を示す説明図である。図44に示した例では、ある端末装置200に向けたデータは、先頭から9番目のShort TTIのデータで最後である旨の情報を、基地局100がその頭から9番目のShort TTIのデータに入れる。この際、基地局100は、その端末装置200には3個のShort TTIのデータを送信したことをそのShort TTIのデータに入れる。端末装置200は、これらの情報を確認することで、このサブフレームには自身宛のデータが3つあったことを知ることが出来る。従って端末装置200は、そのサブフレームでCRCチェックの結果がOKの個数が3つであればACKを、3つ以外であればNACKを、それぞれ基地局100に返信する。
【0176】
図45は、本開示の実施の形態に係る基地局100及び端末装置200の動作例を示す流れ図である。図45に示したのは、上述した第3の方法に対応する基地局100及び端末装置200の動作例である。以下、図45を用いて本開示の実施の形態に係る基地局100及び端末装置200の動作例を説明する。
【0177】
基地局100は、各サブフレームのPDCCHにおいて、Short TTIのデータが入っているリソースを指定する(ステップS311)。ステップS311の処理は、例えば通知部153が実行する。
【0178】
続いて基地局100は、Short TTIでそれぞれの端末装置200宛のデータを送信する。そして、各サブフレームにおいて、ある端末装置200に向けた最後のShort TTIのデータの中に、そのサブフレームでのShort TTIのデータはここで最後であるという情報、および、当該サブフレームでその端末装置200宛に送信したデータの個数の情報を通知する(ステップS312)。ステップS312の処理は、例えば通知部153が実行する。
【0179】
端末装置200は、スケジューリングされたRBGが、Short TTIなのか通常のTTIなのかを知った上でデータのデコードを行う。そして端末装置200は、スケジューリングされたRBGがShort TTIであればShort TTIのデータを先頭から順番にデコードする(ステップS313)。ステップS313の処理は、例えば受信処理部243が実行する。
【0180】
そして、端末装置200は、上記ステップS312で基地局100から送信された情報に基づき、基地局100に向けてACKまたはNACKを返信する(ステップS314)。ステップS314の処理は、例えば通知部245が実行する。端末装置200は、上記ステップS312で基地局100から送信された情報に基づき、サブフレーム内に存在した自身宛のShort TTIのデータの個数と、CRCチェックの結果がOKの個数が等しければACKを、異なっていればNACKを、それぞれ基地局100に返信する。
【0181】
この第3の方法は、基地局100は、周波数方向にも時間方向にも、連続的にも飛び飛びにもリソースを指定出来ることから、スケジューリングの自由度は非常に高い。また、HARQのACK/NACKの返信を考慮しなければ、スケジューリングの割り当てに必要なビット数も少なく済む。
【0182】
また、上述の第2の方法や第3の方法のように、想定する有効なデータの数と、受信に成功したデータの数とを比較する方法の場合、基地局100が、有効なデータの数を指定するためには1つのRBGあたり4ビット必要になる。25個のRBGをShort TTIが占有する場合を想定すると、基地局100が、有効なデータの数を指定するためには100ビットもの情報が必要になる。しかし、上述したように、1つのサブフレームあたり、Short TTIで使用できるRBGの数を制限することで有効なデータの数を指定するためのビット数を小さくすることが出来る。例えば、1つのサブフレームあたり、Short TTIで使用できるRBGの数を3個に制限することで有効なデータの数を指定するためのビット数を12ビットに抑えることが出来る。
【0183】
上述したように、従来のLTEでは、eNodeBは、バンド幅が20MHzの場合、スケジューリング情報に25ビットが割り当てられていた。従って、周波数的に離れたリソースを、1台のUEに割り当てることが可能であった。上述した3つのACKまたはNACKの返信方法においても、同様に、基地局100は周波数方向に配置された25個のリソースを自由にそれぞれの端末装置200に割り当てることができる。
【0184】
(1.4.4.動作例のまとめ)
以上、本開示の実施の形態に係る基地局100及び端末装置200の動作例を3つ挙げた。なお、本開示の実施の形態に係る基地局100及び端末装置200は、上述した3つの動作例を独立して動作するものではなく、複数の動作例を組み合わせて動作しても良い。また、本開示の実施の形態に係る基地局100及び端末装置200は、複数の動作例を組み合わせる際に、各動作例で説明した動作の一部のみを組み合わせてもよい。
【0185】
例えば、本開示の実施の形態に係る基地局100及び端末装置200は、第1の動作例で示したShort TTIでのデータの送受信で使用するリソースを通知する動作と、様々なレベルのShort TTIを用意した際の動作とを組み合わせてもよい。
【0186】
<2.応用例>
本開示に係る技術は、様々な製品へ応用可能である。例えば、基地局100は、マクロeNB又はスモールeNBなどのいずれかの種類のeNB(evolved Node B)として実現されてもよい。スモールeNBは、ピコeNB、マイクロeNB又はホーム(フェムト)eNBなどの、マクロセルよりも小さいセルをカバーするeNBであってよい。その代わりに、基地局100は、NodeB又はBTS(Base Transceiver Station)などの他の種類の基地局として実現されてもよい。基地局100は、無線通信を制御する本体(基地局装置ともいう)と、本体とは別の場所に配置される1つ以上のRRH(Remote Radio Head)とを含んでもよい。また、後述する様々な種類の端末が一時的に又は半永続的に基地局機能を実行することにより、基地局100として動作してもよい。
【0187】
また、例えば、端末装置200は、スマートフォン、タブレットPC(Personal Computer)、ノートPC、携帯型ゲーム端末、携帯型/ドングル型のモバイルルータ若しくはデジタルカメラなどのモバイル端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、端末装置200は、M2M(Machine To Machine)通信を行う端末(MTC(Machine Type Communication)端末ともいう)として実現されてもよい。さらに、端末装置200は、これら端末に搭載される無線通信モジュール(例えば、1つのダイで構成される集積回路モジュール)であってもよい。
【0188】
<2.1.基地局に関する応用例>
(第1の応用例)
図46は、本開示に係る技術が適用され得るeNBの概略的な構成の第1の例を示すブロック図である。eNB800は、1つ以上のアンテナ810、及び基地局装置820を有する。各アンテナ810及び基地局装置820は、RFケーブルを介して互いに接続され得る。
【0189】
アンテナ810の各々は、単一の又は複数のアンテナ素子(例えば、MIMOアンテナを構成する複数のアンテナ素子)を有し、基地局装置820による無線信号の送受信のために使用される。eNB800は、図46に示したように複数のアンテナ810を有し、複数のアンテナ810は、例えばeNB800が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図46にはeNB800が複数のアンテナ810を有する例を示したが、eNB800は単一のアンテナ810を有してもよい。
【0190】
基地局装置820は、コントローラ821、メモリ822、ネットワークインタフェース823及び無線通信インタフェース825を備える。
【0191】
コントローラ821は、例えばCPU又はDSPであってよく、基地局装置820の上位レイヤの様々な機能を動作させる。例えば、コントローラ821は、無線通信インタフェース825により処理された信号内のデータからデータパケットを生成し、生成したパケットをネットワークインタフェース823を介して転送する。コントローラ821は、複数のベースバンドプロセッサからのデータをバンドリングすることによりバンドルドパケットを生成し、生成したバンドルドパケットを転送してもよい。また、コントローラ821は、無線リソース管理(Radio Resource Control)、無線ベアラ制御(Radio Bearer Control)、移動性管理(Mobility Management)、流入制御(Admission Control)又はスケジューリング(Scheduling)などの制御を実行する論理的な機能を有してもよい。また、当該制御は、周辺のeNB又はコアネットワークノードと連携して実行されてもよい。メモリ822は、RAM及びROMを含み、コントローラ821により実行されるプログラム、及び様々な制御データ(例えば、端末リスト、送信電力データ及びスケジューリングデータなど)を記憶する。
【0192】
ネットワークインタフェース823は、基地局装置820をコアネットワーク824に接続するための通信インタフェースである。コントローラ821は、ネットワークインタフェース823を介して、コアネットワークノード又は他のeNBと通信してもよい。その場合に、eNB800と、コアネットワークノード又は他のeNBとは、論理的なインタフェース(例えば、S1インタフェース又はX2インタフェース)により互いに接続されてもよい。ネットワークインタフェース823は、有線通信インタフェースであってもよく、又は無線バックホールのための無線通信インタフェースであってもよい。ネットワークインタフェース823が無線通信インタフェースである場合、ネットワークインタフェース823は、無線通信インタフェース825により使用される周波数帯域よりもより高い周波数帯域を無線通信に使用してもよい。
【0193】
無線通信インタフェース825は、LTE(Long Term Evolution)又はLTE−Advancedなどのいずれかのセルラー通信方式をサポートし、アンテナ810を介して、eNB800のセル内に位置する端末に無線接続を提供する。無線通信インタフェース825は、典型的には、ベースバンド(BB)プロセッサ826及びRF回路827などを含み得る。BBプロセッサ826は、例えば、符号化/復号、変調/復調及び多重化/逆多重化などを行なってよく、各レイヤ(例えば、L1、MAC(Medium Access Control)、RLC(Radio Link Control)及びPDCP(Packet Data Convergence Protocol))の様々な信号処理を実行する。BBプロセッサ826は、コントローラ821の代わりに、上述した論理的な機能の一部又は全部を有してもよい。BBプロセッサ826は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を含むモジュールであってもよく、BBプロセッサ826の機能は、上記プログラムのアップデートにより変更可能であってもよい。また、上記モジュールは、基地局装置820のスロットに挿入されるカード若しくはブレードであってもよく、又は上記カード若しくは上記ブレードに搭載されるチップであってもよい。一方、RF回路827は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ810を介して無線信号を送受信する。
【0194】
無線通信インタフェース825は、図46に示したように複数のBBプロセッサ826を含み、複数のBBプロセッサ826は、例えばeNB800が使用する複数の周波数帯域にそれぞれ対応してもよい。また、無線通信インタフェース825は、図46に示したように複数のRF回路827を含み、複数のRF回路827は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図46には無線通信インタフェース825が複数のBBプロセッサ826及び複数のRF回路827を含む例を示したが、無線通信インタフェース825は単一のBBプロセッサ826又は単一のRF回路827を含んでもよい。
【0195】
図46に示したeNB800において、図5を参照して説明した処理部150に含まれる1つ以上の構成要素(送信処理部151及び/又は通知部153)は、無線通信インタフェース825において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、コントローラ821において実装されてもよい。一例として、eNB800は、無線通信インタフェース825の一部(例えば、BBプロセッサ826)若しくは全部、及び/又はコントローラ821を含むモジュールを搭載し、当該モジュールにおいて上記1つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記1つ以上の構成要素として機能させるためのプログラム(換言すると、プロセッサに上記1つ以上の構成要素の動作を実行させるためのプログラム)を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記1つ以上の構成要素として機能させるためのプログラムがeNB800にインストールされ、無線通信インタフェース825(例えば、BBプロセッサ826)及び/又はコントローラ821が当該プログラムを実行してもよい。以上のように、上記1つ以上の構成要素を備える装置としてeNB800、基地局装置820又は上記モジュールが提供されてもよく、プロセッサを上記1つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
【0196】
また、図46に示したeNB800において、図5を参照して説明した無線通信部120は、無線通信インタフェース825(例えば、RF回路827)において実装されてもよい。また、アンテナ部110は、アンテナ810において実装されてもよい。また、ネットワーク通信部130は、コントローラ821及び/又はネットワークインタフェース823において実装されてもよい。また、記憶部140は、メモリ822において実装されてもよい。
【0197】
(第2の応用例)
図47は、本開示に係る技術が適用され得るeNBの概略的な構成の第2の例を示すブロック図である。eNB830は、1つ以上のアンテナ840、基地局装置850、及びRRH860を有する。各アンテナ840及びRRH860は、RFケーブルを介して互いに接続され得る。また、基地局装置850及びRRH860は、光ファイバケーブルなどの高速回線で互いに接続され得る。
【0198】
アンテナ840の各々は、単一の又は複数のアンテナ素子(例えば、MIMOアンテナを構成する複数のアンテナ素子)を有し、RRH860による無線信号の送受信のために使用される。eNB830は、図47に示したように複数のアンテナ840を有し、複数のアンテナ840は、例えばeNB830が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図47にはeNB830が複数のアンテナ840を有する例を示したが、eNB830は単一のアンテナ840を有してもよい。
【0199】
基地局装置850は、コントローラ851、メモリ852、ネットワークインタフェース853、無線通信インタフェース855及び接続インタフェース857を備える。コントローラ851、メモリ852及びネットワークインタフェース853は、図46を参照して説明したコントローラ821、メモリ822及びネットワークインタフェース823と同様のものである。
【0200】
無線通信インタフェース855は、LTE又はLTE−Advancedなどのいずれかのセルラー通信方式をサポートし、RRH860及びアンテナ840を介して、RRH860に対応するセクタ内に位置する端末に無線接続を提供する。無線通信インタフェース855は、典型的には、BBプロセッサ856などを含み得る。BBプロセッサ856は、接続インタフェース857を介してRRH860のRF回路864と接続されることを除き、図46を参照して説明したBBプロセッサ826と同様のものである。無線通信インタフェース855は、図47に示したように複数のBBプロセッサ856を含み、複数のBBプロセッサ856は、例えばeNB830が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図47には無線通信インタフェース855が複数のBBプロセッサ856を含む例を示したが、無線通信インタフェース855は単一のBBプロセッサ856を含んでもよい。
【0201】
接続インタフェース857は、基地局装置850(無線通信インタフェース855)をRRH860と接続するためのインタフェースである。接続インタフェース857は、基地局装置850(無線通信インタフェース855)とRRH860とを接続する上記高速回線での通信のための通信モジュールであってもよい。
【0202】
また、RRH860は、接続インタフェース861及び無線通信インタフェース863を備える。
【0203】
接続インタフェース861は、RRH860(無線通信インタフェース863)を基地局装置850と接続するためのインタフェースである。接続インタフェース861は、上記高速回線での通信のための通信モジュールであってもよい。
【0204】
無線通信インタフェース863は、アンテナ840を介して無線信号を送受信する。無線通信インタフェース863は、典型的には、RF回路864などを含み得る。RF回路864は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ840を介して無線信号を送受信する。無線通信インタフェース863は、図47に示したように複数のRF回路864を含み、複数のRF回路864は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図47には無線通信インタフェース863が複数のRF回路864を含む例を示したが、無線通信インタフェース863は単一のRF回路864を含んでもよい。
【0205】
図47に示したeNB830において、図5を参照して説明した処理部150に含まれる1つ以上の構成要素(送信処理部151及び/又は通知部153)は、無線通信インタフェース855及び/又は無線通信インタフェース863において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、コントローラ851において実装されてもよい。一例として、eNB830は、無線通信インタフェース855の一部(例えば、BBプロセッサ856)若しくは全部、及び/又はコントローラ851を含むモジュールを搭載し、当該モジュールにおいて上記1つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記1つ以上の構成要素として機能させるためのプログラム(換言すると、プロセッサに上記1つ以上の構成要素の動作を実行させるためのプログラム)を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記1つ以上の構成要素として機能させるためのプログラムがeNB830にインストールされ、無線通信インタフェース855(例えば、BBプロセッサ856)及び/又はコントローラ851が当該プログラムを実行してもよい。以上のように、上記1つ以上の構成要素を備える装置としてeNB830、基地局装置850又は上記モジュールが提供されてもよく、プロセッサを上記1つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
【0206】
また、図47に示したeNB830において、例えば、図5を参照して説明した無線通信部120は、無線通信インタフェース863(例えば、RF回路864)において実装されてもよい。また、アンテナ部110は、アンテナ840において実装されてもよい。また、ネットワーク通信部130は、コントローラ851及び/又はネットワークインタフェース853において実装されてもよい。また、記憶部140は、メモリ852において実装されてもよい。
【0207】
<2−2.端末装置に関する応用例>
(第1の応用例)
図48は、本開示に係る技術が適用され得るスマートフォン900の概略的な構成の一例を示すブロック図である。スマートフォン900は、プロセッサ901、メモリ902、ストレージ903、外部接続インタフェース904、カメラ906、センサ907、マイクロフォン908、入力デバイス909、表示デバイス910、スピーカ911、無線通信インタフェース912、1つ以上のアンテナスイッチ915、1つ以上のアンテナ916、バス917、バッテリー918及び補助コントローラ919を備える。
【0208】
プロセッサ901は、例えばCPU又はSoC(System on Chip)であってよく、スマートフォン900のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ902は、RAM及びROMを含み、プロセッサ901により実行されるプログラム及びデータを記憶する。ストレージ903は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース904は、メモリーカード又はUSB(Universal Serial Bus)デバイスなどの外付けデバイスをスマートフォン900へ接続するためのインタフェースである。
【0209】
カメラ906は、例えば、CCD(Charge Coupled Device)又はCMOS(Complementary Metal Oxide Semiconductor)などの撮像素子を有し、撮像画像を生成する。センサ907は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン908は、スマートフォン900へ入力される音声を音声信号へ変換する。入力デバイス909は、例えば、表示デバイス910の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス910は、液晶ディスプレイ(LCD)又は有機発光ダイオード(OLED)ディスプレイなどの画面を有し、スマートフォン900の出力画像を表示する。スピーカ911は、スマートフォン900から出力される音声信号を音声に変換する。
【0210】
無線通信インタフェース912は、LTE又はLTE−Advancedなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース912は、典型的には、BBプロセッサ913及びRF回路914などを含み得る。BBプロセッサ913は、例えば、符号化/復号、変調/復調及び多重化/逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、RF回路914は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ916を介して無線信号を送受信する。無線通信インタフェース912は、BBプロセッサ913及びRF回路914を集積したワンチップのモジュールであってもよい。無線通信インタフェース912は、図48に示したように複数のBBプロセッサ913及び複数のRF回路914を含んでもよい。なお、図48には無線通信インタフェース912が複数のBBプロセッサ913及び複数のRF回路914を含む例を示したが、無線通信インタフェース912は単一のBBプロセッサ913又は単一のRF回路914を含んでもよい。
【0211】
さらに、無線通信インタフェース912は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線LAN(Local Area Network)方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのBBプロセッサ913及びRF回路914を含んでもよい。
【0212】
アンテナスイッチ915の各々は、無線通信インタフェース912に含まれる複数の回路(例えば、異なる無線通信方式のための回路)の間でアンテナ916の接続先を切り替える。
【0213】
アンテナ916の各々は、単一の又は複数のアンテナ素子(例えば、MIMOアンテナを構成する複数のアンテナ素子)を有し、無線通信インタフェース912による無線信号の送受信のために使用される。スマートフォン900は、図48に示したように複数のアンテナ916を有してもよい。なお、図48にはスマートフォン900が複数のアンテナ916を有する例を示したが、スマートフォン900は単一のアンテナ916を有してもよい。
【0214】
さらに、スマートフォン900は、無線通信方式ごとにアンテナ916を備えてもよい。その場合に、アンテナスイッチ915は、スマートフォン900の構成から省略されてもよい。
【0215】
バス917は、プロセッサ901、メモリ902、ストレージ903、外部接続インタフェース904、カメラ906、センサ907、マイクロフォン908、入力デバイス909、表示デバイス910、スピーカ911、無線通信インタフェース912及び補助コントローラ919を互いに接続する。バッテリー918は、図中に破線で部分的に示した給電ラインを介して、図48に示したスマートフォン900の各ブロックへ電力を供給する。補助コントローラ919は、例えば、スリープモードにおいて、スマートフォン900の必要最低限の機能を動作させる。
【0216】
図48に示したスマートフォン900において、図6を参照して説明した処理部240に含まれる1つ以上の構成要素(取得部241及び/又は受信処理部243)は、無線通信インタフェース912において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ901又は補助コントローラ919において実装されてもよい。一例として、スマートフォン900は、無線通信インタフェース912の一部(例えば、BBプロセッサ913)若しくは全部、プロセッサ901、及び/又は補助コントローラ919を含むモジュールを搭載し、当該モジュールにおいて上記1つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記1つ以上の構成要素として機能させるためのプログラム(換言すると、プロセッサに上記1つ以上の構成要素の動作を実行させるためのプログラム)を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記1つ以上の構成要素として機能させるためのプログラムがスマートフォン900にインストールされ、無線通信インタフェース912(例えば、BBプロセッサ913)、プロセッサ901、及び/又は補助コントローラ919が当該プログラムを実行してもよい。以上のように、上記1つ以上の構成要素を備える装置としてスマートフォン900又は上記モジュールが提供されてもよく、プロセッサを上記1つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
【0217】
また、図48に示したスマートフォン900において、例えば、図6を参照して説明した無線通信部220は、無線通信インタフェース912(例えば、RF回路914)において実装されてもよい。また、アンテナ部210は、アンテナ916において実装されてもよい。また、記憶部230は、メモリ902において実装されてもよい。
【0218】
(第2の応用例)
図49は、本開示に係る技術が適用され得るカーナビゲーション装置920の概略的な構成の一例を示すブロック図である。カーナビゲーション装置920は、プロセッサ921、メモリ922、GPS(Global Positioning System)モジュール924、センサ925、データインタフェース926、コンテンツプレーヤ927、記憶媒体インタフェース928、入力デバイス929、表示デバイス930、スピーカ931、無線通信インタフェース933、1つ以上のアンテナスイッチ936、1つ以上のアンテナ937及びバッテリー938を備える。
【0219】
プロセッサ921は、例えばCPU又はSoCであってよく、カーナビゲーション装置920のナビゲーション機能及びその他の機能を制御する。メモリ922は、RAM及びROMを含み、プロセッサ921により実行されるプログラム及びデータを記憶する。
【0220】
GPSモジュール924は、GPS衛星から受信されるGPS信号を用いて、カーナビゲーション装置920の位置(例えば、緯度、経度及び高度)を測定する。センサ925は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース926は、例えば、図示しない端子を介して車載ネットワーク941に接続され、車速データなどの車両側で生成されるデータを取得する。
【0221】
コンテンツプレーヤ927は、記憶媒体インタフェース928に挿入される記憶媒体(例えば、CD又はDVD)に記憶されているコンテンツを再生する。入力デバイス929は、例えば、表示デバイス930の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス930は、LCD又はOLEDディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ931は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。
【0222】
無線通信インタフェース933は、LTE又はLTE−Advancedなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース933は、典型的には、BBプロセッサ934及びRF回路935などを含み得る。BBプロセッサ934は、例えば、符号化/復号、変調/復調及び多重化/逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、RF回路935は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ937を介して無線信号を送受信する。無線通信インタフェース933は、BBプロセッサ934及びRF回路935を集積したワンチップのモジュールであってもよい。無線通信インタフェース933は、図49に示したように複数のBBプロセッサ934及び複数のRF回路935を含んでもよい。なお、図49には無線通信インタフェース933が複数のBBプロセッサ934及び複数のRF回路935を含む例を示したが、無線通信インタフェース933は単一のBBプロセッサ934又は単一のRF回路935を含んでもよい。
【0223】
さらに、無線通信インタフェース933は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線LAN方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのBBプロセッサ934及びRF回路935を含んでもよい。
【0224】
アンテナスイッチ936の各々は、無線通信インタフェース933に含まれる複数の回路(例えば、異なる無線通信方式のための回路)の間でアンテナ937の接続先を切り替える。
【0225】
アンテナ937の各々は、単一の又は複数のアンテナ素子(例えば、MIMOアンテナを構成する複数のアンテナ素子)を有し、無線通信インタフェース933による無線信号の送受信のために使用される。カーナビゲーション装置920は、図49に示したように複数のアンテナ937を有してもよい。なお、図49にはカーナビゲーション装置920が複数のアンテナ937を有する例を示したが、カーナビゲーション装置920は単一のアンテナ937を有してもよい。
【0226】
さらに、カーナビゲーション装置920は、無線通信方式ごとにアンテナ937を備えてもよい。その場合に、アンテナスイッチ936は、カーナビゲーション装置920の構成から省略されてもよい。
【0227】
バッテリー938は、図中に破線で部分的に示した給電ラインを介して、図49に示したカーナビゲーション装置920の各ブロックへ電力を供給する。また、バッテリー938は、車両側から給電される電力を蓄積する。
【0228】
図49に示したカーナビゲーション装置920において、図6を参照して説明した処理部240に含まれる1つ以上の構成要素(取得部241及び/又は受信処理部243)は、無線通信インタフェース933において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ921において実装されてもよい。一例として、カーナビゲーション装置920は、無線通信インタフェース933の一部(例えば、BBプロセッサ934)若しくは全部及び/又はプロセッサ921を含むモジュールを搭載し、当該モジュールにおいて上記1つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記1つ以上の構成要素として機能させるためのプログラム(換言すると、プロセッサに上記1つ以上の構成要素の動作を実行させるためのプログラム)を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記1つ以上の構成要素として機能させるためのプログラムがカーナビゲーション装置920にインストールされ、無線通信インタフェース933(例えば、BBプロセッサ934)及び/又はプロセッサ921が当該プログラムを実行してもよい。以上のように、上記1つ以上の構成要素を備える装置としてカーナビゲーション装置920又は上記モジュールが提供されてもよく、プロセッサを上記1つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
【0229】
また、図49に示したカーナビゲーション装置920において、例えば、図6を参照して説明した無線通信部220は、無線通信インタフェース933(例えば、RF回路935)において実装されてもよい。また、アンテナ部210は、アンテナ937において実装されてもよい。また、記憶部230は、メモリ922において実装されてもよい。
【0230】
また、本開示に係る技術は、上述したカーナビゲーション装置920の1つ以上のブロックと、車載ネットワーク941と、車両側モジュール942とを含む車載システム(又は車両)940として実現されてもよい。即ち、取得部241及び/又は受信処理部243を備える装置として車載システム(又は車両)940が提供されてもよい。車両側モジュール942は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク941へ出力する。
【0231】
<3.まとめ>
以上説明したように本開示の実施の形態によれば、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを端末装置へ通知する、基地局100が提供される。
【0232】
また本開示の実施の形態によれば、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを基地局100から通知される、端末装置200が提供される。
【0233】
本開示の実施の形態に係る基地局100は、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを端末装置200へ通知することで、端末装置200での効率的な受信処理を可能にさせる。また、本開示の実施の形態に係る端末装置200は、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを基地局100から通知されることで、効率的な受信処理が可能になる。
【0234】
本開示の実施の形態によれば、リソースのどこに短送信時間間隔でのデータが存在するかを端末装置200へ通知することで、基地局100は、端末装置200に搭載しているアプリケーションを、低遅延で、かつレスポンス良く制御することが可能となる。また本開示の実施の形態によれば、基地局100から短送信時間間隔でのデータの場所を通知されることで、端末装置200はACKまたはNACKを基地局100に早く返すことが可能となる。従って本開示の実施の形態によれば、スループットの向上が見込める。特に本開示の実施の形態によれば、基地局100は、短送信時間間隔のリソースと、既存の送信時間間隔のリソースとを効率的に混在させることができるので、無駄が生じず、スループットを向上させることが出来る。
【0235】
また本開示の実施の形態によれば、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信の際に、複数の短送信時間間隔の長さの中から端末装置にとって最適な短送信時間間隔の長さによるデータの送受信を可能とさせる基地局100が提供される。
【0236】
また本開示の実施の形態によれば、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信の際に、複数の短送信時間間隔の長さの中から最適な短送信時間間隔の長さによるデータの送受信を可能とする端末装置200が提供される。
【0237】
本明細書の各装置が実行する処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、各装置が実行する処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。
【0238】
また、各装置に内蔵されるCPU、ROMおよびRAMなどのハードウェアを、上述した各装置の構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供されることが可能である。また、機能ブロック図で示したそれぞれの機能ブロックをハードウェアまたはハードウェア回路で構成することで、一連の処理をハードウェアまたはハードウェア回路で実現することもできる。
【0239】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【0240】
また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
【0241】
なお、以下のような構成も本開示の技術的範囲に属する。
(1)
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知するとともに、サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知する通知部を備える、無線通信装置。
(2)
前記通知部は、前記短送信時間領域が1サブフレーム内において複数存在することを通知する、前記(1)に記載の無線通信装置。
(3)
前記通知部は、前記制御領域において、前記短送信時間領域における前記短送信時間間隔のデータの有無を通知する、前記(1)または(2)に記載の無線通信装置。
(4)
前記通知部は、前記短送信時間領域の通知は準静的に通知し、通知前記短送信時間間隔のデータの有無は動的に通知する、前記(3)に記載の無線通信装置。
(5)
前記通知部は、前記制御領域において、他の通信装置に向けて前記短送信時間領域における前記短送信時間間隔のデータの場所を通知する、前記(1)〜(4)のいずれかに記載の無線通信装置。
(6)
前記通知部は、前記制御領域において、後続の別のサブフレームにおける前記短送信時間間隔についての情報を通知する、前記(1)〜(5)のいずれかに記載の無線通信装置。
(7)
前記通知部は、前記制御領域において、同一のサブフレームにおける前記短送信時間間隔についての情報を通知する、前記(1)〜(5)のいずれかに記載の無線通信装置。
(8)
前記制御領域は、PDCCH(Physical Downlink Control Channel)である、前記(1)〜(7)のいずれかに記載の無線通信装置。
(9)
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を受信するとともに、サブフレーム単位で送られる制御領域において、他の通信装置から前記短送信時間間隔についての情報を受信する受信部を備える、無線通信装置。
(10)
前記受信部は、前記制御領域において、前記短送信時間領域における前記短送信時間間隔のデータの有無を受信する、前記(9)に記載の無線通信装置。
(11)
前記制御領域は、PDCCH(Physical Downlink Control Channel)である、前記(9)に記載の無線通信装置。
(12)
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知することと、
サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知することと、
を含む、無線通信方法。
(13)
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を受信することと、
サブフレーム単位で送られる制御領域において、他の通信装置から前記短送信時間間隔についての情報を受信することと、
を含む、無線通信方法。
(14)
コンピュータに、
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知することと、
サブフレーム単位で送られる制御領域において、他の通信装置向けの前記短送信時間間隔についての情報を通知することと、
を実行させる、コンピュータプログラム。
(15)
コンピュータに、
サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を受信することと、
サブフレーム単位で送られる制御領域において、他の通信装置から前記短送信時間間隔についての情報を受信することと、
を実行させる、コンピュータプログラム。
(16)
第1の通信装置及び第2の通信装置を備え、
前記第1の通信装置は、サブフレーム内における、1サブフレーム期間より短い送信時間間隔である短送信時間間隔でデータを送信する短送信時間領域を通知するとともに、サブフレーム単位で送られる制御領域において、前記第2の通信装置向けの前記短送信時間間隔についての情報を通知する通知部を備え、
前記第2の通信装置は、前記短送信時間間隔でデータを送信する短送信時間領域を受信するとともに、サブフレーム単位で送られる制御領域において、前記第1の通信装置から前記短送信時間間隔についての情報を受信する受信部を備える、無線通信システム。
【符号の説明】
【0242】
1 システム
100 基地局
200 端末装置
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32
図33
図34
図35
図36
図37
図38
図39
図40
図41
図42
図43
図44
図45
図46
図47
図48
図49
【国際調査報告】