(57)【特許請求の範囲】
【請求項１】
複数のサブフレームからなるフレームを生成するフレーム生成部と、
前記生成されたフレームを他の通信装置に送信する送信部と、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を通知する通知部と、
を備える、無線通信装置。
【請求項２】
前記複数の長さの情報に基づいて前記他の通信装置から送信された該他の通信装置の能力に関する情報に基づいて前記複数の長さから１つの長さを選択する処理部をさらに備える、請求項１に記載の無線通信装置。
【請求項３】
前記処理部は、短送信時間間隔でデータを送信する短送信時間間隔領域における一部のリソースを使用して短送信時間間隔のデータを送信する、請求項２に記載の無線通信装置。
【請求項４】
前記通知部は、短送信時間間隔のそれぞれの長さと、フレーム番号及びサブフレーム番号との対応関係を通知する、請求項１〜３のいずれかに記載の無線通信装置。
【請求項５】
前記処理部は、１つのサブフレームに複数の長さの短送信時間間隔のデータを含める、請求項２に記載の無線通信装置。
【請求項６】
前記処理部は、１つのサブフレームに複数の他の通信装置宛の短送信時間間隔のデータを含める、請求項２に記載の無線通信装置。
【請求項７】
前記処理部は、１つのサブフレームに短送信時間間隔のデータを間欠的に配置する、請求項２に記載の無線通信装置。
【請求項８】
前記処理部は、サブフレーム内の制御領域の長さに応じて短送信時間間隔でデータを送信する短送信時間間隔領域の長さを変化させる、請求項２に記載の無線通信装置。
【請求項９】
前記通知部は、前記短送信時間間隔が２つのサブフレームに跨がる場合に前記短送信時間間隔とサブフレーム番号との対応関係を通知する、請求項１〜８のいずれかに記載の無線通信装置。
【請求項１０】
前記短送信時間間隔の複数の長さの設定はセル毎に異なる、請求項１〜９のいずれかに記載の無線通信装置。
【請求項１１】
複数のサブフレームからなるフレームを受信すると共に、前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を他の通信装置から取得する取得部を備える、無線通信装置。
【請求項１２】
前記取得部が取得した前記複数の長さの情報に基づいて自装置の能力に関する情報を前記他の通信装置に通知する通知部をさらに備える、請求項１１に記載の無線通信装置。
【請求項１３】
前記通知部は、前記自装置の能力としてソフトウェア的な能力に関する情報を通知する、請求項１２に記載の無線通信装置。
【請求項１４】
前記通知部は、前記自装置の能力としてハードウェア的な能力に関する情報を通知する、請求項１２に記載の無線通信装置。
【請求項１５】
前記取得部は、前記他の通信装置で選択された長さの、前記短送信時間間隔のデータを前記他の通信装置から取得する、請求項１１〜１４のいずれかに記載の無線通信装置。
【請求項１６】
複数のサブフレームからなるフレームを生成することと、
前記生成されたフレームを他の通信装置に送信することと、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を通知することと、
を含む、無線通信方法。
【請求項１７】
複数のサブフレームからなるフレームを受信することと、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を基地局から取得することと、
を含む、無線通信方法。
【請求項１８】
コンピュータに、
複数のサブフレームからなるフレームを生成することと、
前記生成されたフレームを他の通信装置に送信することと、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を通知することと、
を実行させる、コンピュータプログラム。
【請求項１９】
コンピュータに、
複数のサブフレームからなるフレームを受信することと、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を基地局から取得することと、
を実行させる、コンピュータプログラム。
【請求項２０】
第１の通信装置及び第２の通信装置を備え、
前記第１の通信装置は、
複数のサブフレームからなるフレームを生成するフレーム生成部と、
前記生成されたフレームを前記第２の通信装置に送信する送信部と、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を前記第２の通信装置に通知する通知部と、
を備え、
前記第２の通信装置は、前記フレームを受信すると共に、前記サブフレーム内における前記短送信時間間隔の、複数の長さの情報を前記第１の通信装置から取得する取得部を備える、無線通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、無線通信装置、通信方法、コンピュータプログラム及び無線通信システムに関する。
【背景技術】
【０００２】
ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）においては、高データレート化を実現するために、ＴＴＩ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｔｉｍｅ  Ｉｎｔｅｒｖａｌ：送信時間間隔）が１ｍｓとなっている。ＴＴＩを短くすることで、再送制御に要するＲＴＴ（Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ：往復遅延時間）が短縮され、システムの遅延が低減される。
【０００３】
ＴＴＩが１ｍｓの場合、端末装置がデータをデコードするのに必要な時間は４ｍｓである。このＴＴＩがより短くなると、端末装置でのデコード時間も短くなる。端末装置でのデコード時間も短くなると、リアルタイム性が強く要求される場合に大きな効果が期待できる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−２１２５９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
既存の送信時間間隔より短い短送信時間間隔（ｓｈｏｒｔ  ＴＴＩ）でデータの送受信を行う場合、短送信時間間隔の長さ（レベル）を複数用意することで、端末装置は最適な長さの短送信時間間隔を選択できる。
【０００６】
そこで、本開示では、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信の際に、複数の短送信時間間隔の長さの中から端末装置にとって最適な短送信時間間隔の長さによるデータの送受信が可能な、新規かつ改良された無線通信装置、通信方法、コンピュータプログラム及び無線通信システムを提案する。
【課題を解決するための手段】
【０００７】
本開示によれば、複数のサブフレームからなるフレームを生成するフレーム生成部と、前記生成されたフレームを他の通信装置に送信する送信部と、前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を通知する通知部と、を備える、無線通信装置が提供される。
【０００８】
また本開示によれば、複数のサブフレームからなるフレームを受信すると共に、前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を他の通信装置から取得する取得部を備える、無線通信装置が提供される。
【０００９】
また本開示によれば、複数のサブフレームからなるフレームを生成することと、前記生成されたフレームを他の通信装置に送信することと、前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を通知することと、を含む、無線通信方法が提供される。
【００１０】
また本開示によれば、複数のサブフレームからなるフレームを受信することと、前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を基地局から取得することと、を含む、無線通信方法が提供される。
【００１１】
また本開示によれば、コンピュータに、複数のサブフレームからなるフレームを生成することと、前記生成されたフレームを他の通信装置に送信することと、前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を通知することと、を実行させる、コンピュータプログラムが提供される。
【００１２】
また本開示によれば、コンピュータに、複数のサブフレームからなるフレームを受信することと、前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を基地局から取得することと、を実行させる、コンピュータプログラムが提供される。
【００１３】
また本開示によれば、第１の通信装置及び第２の通信装置を備え、前記第１の通信装置は、複数のサブフレームからなるフレームを生成するフレーム生成部と、前記生成されたフレームを前記第２の通信装置に送信する送信部と、前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を前記第２の通信装置に通知する通知部と、を備え、前記第２の通信装置は、前記フレームを受信すると共に、前記サブフレーム内における前記短送信時間間隔の、複数の長さの情報を前記第１の通信装置から取得する取得部を備える、無線通信システムが提供される。
【発明の効果】
【００１４】
以上説明したように本開示によれば、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信の際に、複数の短送信時間間隔の長さの中から端末装置にとって最適な短送信時間間隔の長さによるデータの送受信が可能な、新規かつ改良された無線通信装置、通信方法、コンピュータプログラム及び無線通信システムを提供することが出来る。
【００１５】
なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。
【図面の簡単な説明】
【００１６】
【図１】ＬＴＥのフレームフォーマットを示す説明図である。
【図２】ＬＴＥのダウンリンクのフォーマットを示す説明図である。
【図３】ＬＴＥのアップリンクのスケジューリングの概要を示す説明図である。
【図４】本開示の実施の形態に係るシステムの構成例を示す説明図である。
【図５】同実施形態に係る基地局１００の構成の一例を示すブロック図である。
【図６】同実施形態に係る端末装置２００の構成の一例を示すブロック図である。
【図７】Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。
【図８】Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。
【図９】Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。
【図１０】Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。
【図１１】同実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。
【図１２】基地局１００が、特定の端末装置向けの情報がＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する方法について説明する説明図である。
【図１３】基地局１００が、特定の端末装置向けの情報がＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する方法について説明する説明図である。
【図１４】基地局１００がＰＤＣＣＨの端末装置２００固有なサーチスペースの中にあるＤＣＩを使用して特定の端末装置向けの情報がＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する例を示す説明図である。
【図１５】基地局１００が、Ｓｈｏｒｔ  ＴＴＩ領域におけるＳｈｏｒｔ  ＴＴＩのデータの場所をＤＣＩで通知する様子を示す説明図である。
【図１６】基地局１００が、Ｓｈｏｒｔ  ＴＴＩ領域におけるＳｈｏｒｔ  ＴＴＩのデータの場所をＤＣＩで通知する様子を示す説明図である。
【図１７】同実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。
【図１８】１ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩを示す説明図である。
【図１９】２ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩを示す説明図である。
【図２０】同実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。
【図２１】一つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。
【図２２】４ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩを示す説明図である。
【図２３】１フレームにおける、４ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩを示す説明図である。
【図２４】同実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。
【図２５】１つのサブフレームに複数のレベルのＳｈｏｒｔ  ＴＴＩが混在している例を示す説明図である。
【図２６】Ｓｈｏｒｔ  ＴＴＩの別の配置例を示す説明図である。
【図２７】Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。
【図２８】Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。
【図２９】Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。
【図３０】Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。
【図３１】同実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。
【図３２】Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。
【図３３】Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。
【図３４】Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。
【図３５】ネットワークゲームを実行する各ユーザの端末装置２００に表示される地図の例を示す説明図である。
【図３６】１つのサブフレームに１スロット目のＲＢＧと２スロット目のＲＢＧがあることを示す説明図である。
【図３７】Ｓｈｏｒｔ  ＴＴＩの端末装置２００への割り当て例を示す説明図である。
【図３８】１台の端末装置２００に通常のＴＴＩとＳｈｏｒｔ  ＴＴＩとをスケジューリングした様子を示す説明図である
【図３９】同実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。
【図４０】１１ＯＦＤＭシンボルのうち、先頭の２つのＯＦＤＭシンボルにのみＳｈｏｒｔ  ＴＴＩのデータが入っていることを示す説明図である。
【図４１】３台の端末装置２００がそれぞれＳｈｏｒｔ  ＴＴＩのデータをデコードする場合の例を示す説明図である。
【図４２】端末装置２００が１１個のＳｈｏｒｔ  ＴＴＩ全てをデコードすることを説明する説明図である。
【図４３】Ｓｈｏｒｔ  ＴＴＩの宛先と、ある端末装置２００でのＣＲＣチェックの結果の例を示す説明図である。
【図４４】基地局１００が、端末装置２００に向けて送信する情報について示す説明図である。
【図４５】実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。
【図４６】同実施形態に係る端末装置２００の構成の一例を示すブロック図である。
【図４７】Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。
【図４８】Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。
【図４９】Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。
【発明を実施するための形態】
【００１７】
以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１８】
なお、説明は以下の順序で行うものとする。
１．本開示の実施の形態
１．１．概要
１．２．システム構成例
１．３．機能構成例
１．４．動作例
１．４．１．第１の動作例
１．４．２．第２の動作例
１．４．３．第３の動作例
１．４．４．動作例のまとめ
２．応用例
２．１．基地局に関する応用例
２．２．端末装置に関する応用例
４．まとめ
【００１９】
＜１．本開示の実施の形態＞
［１．１．概要］
本開示の実施の形態について詳細に説明するにあたり、まずは本開示の実施の形態の概要について説明する。本開示の実施の形態の概要について説明した後に、本開示の実施の形態について詳細に説明する。
【００２０】
図１は、ＬＴＥのフレームフォーマットを示す説明図である。図１に示したように、ＬＴＥの１  ｒａｄｉｏ  ｆｒａｍｅは１０個のサブフレーム（Ｓｕｂ  Ｆｒａｍｅ）で構成されている。１つのサブフレームの長さは１ｍｓである。また、１つのサブフレームは１４個のＯＦＤＭ（ｏｒｔｈｏｇｏｎａｌ  ｆｒｅｑｕｅｎｃｙ−ｄｉｖｉｓｉｏｎ  ｍｕｌｔｉｐｌｅｘｉｎｇ；直交周波数分割多重方式）シンボルで構成されている。バンド幅は、例えば２０ＭＨｚである。
【００２１】
ＬＴＥでは、基地局（ｅＮｏｄｅＢ）から送信されたデータは、１サブフレームで１つのトランスポートブロックを構成している。またトランスポートブロックの最後にはＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）が付加されている。つまり、基地局から送信されたデータを受信する端末装置（ＵＥ；Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）は、１サブフレームのデータを受信することによりデータのデコードが可能になる。言い換えれば、ＵＥは、トランスポートブロックの受信の成否を、ＣＲＣの実施により判別することが出来る。従って、ＵＥは、Ｈｙｂｒｉｄ  ＡＲＱ（Ａｕｔｏ  Ｒｅｐｅａｔ  Ｒｅｑｕｅｓｔ）といわれる、再送を要求するためのＡＣＫまたはＮＡＣＫを、１サブフレーム内のデータに対して実施する。ＡＣＫは、データの受信に成功した場合にＵＥからｅＮｏｄｅＢに返信するものであり、ＮＡＣＫは、データの受信に成功した場合にＵＥからｅＮｏｄｅＢに返信するものである。
【００２２】
図２は、ＬＴＥのダウンリンクのフォーマットを示す説明図である。ＬＴＥでは、１サブフレームの中に複数のリソースブロックが存在する。ｅＮｏｄｅＢは、リソースブロック単位で各ＵＥに対してデータを割り当てることが出来る。ｅＮｏｄｅＢは、リソースブロック単位で各ＵＥに対してデータを割り当てるための制御情報を、ＰＤＣＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）という、サブフレームの先頭部分に配置される制御領域に格納している。ＰＤＣＣＨは、１つのサブフレームに１つだけ存在する。
【００２３】
ＬＴＥにおいては、高データレート化を実現するために、ＴＴＩが１ｍｓとなっている。すなわち、ＴＴＩは１サブフレームの時間と同じである。ＵＥが１サブフレーム内のトランスポートブロックをデコードする際の処理遅延は４サブフレーム程度掛かる。従って、ＵＥは、受信したサブフレームの４サブフレーム後に、ＡＣＫまたはＮＡＣＫをｅＮｏｄｅＢに返信することが可能である。図３は、ＬＴＥのアップリンクのスケジューリングの概要を示す説明図である。ＵＥが受信したサブフレームのＰＤＣＣＨには、アップリンクのスケジューリング情報が含まれているが、このスケジューリング情報は受信したサブフレームの４サブフレーム後のスケジューリングが可能となっている。このように受信したサブフレームの４サブフレーム後のスケジューリングが可能となっているのは、ＵＥでの処理遅延を考慮したためである。
【００２４】
従って、ＴＴＩが短くなれば、ＵＥにおけるデコードのための遅延や、アップリンクを使用したｅＮｏｄｅＢへのフィードバックまでの時間の短縮が期待できる。より具体的には、ＴＴＩが短くなれば、以下のようなメリットが期待される。
【００２５】
ＴＴＩが短くなれば、第一に、ＵＥで動作するアプリケーションの低遅延での制御が可能になる。ＴＴＩが短くなれば、ＵＥでのデコード時間も短くなるので、ＵＥは、短いＴＴＩ（Ｓｈｏｒｔ  ＴＴＩ、短送信時間間隔）でｅＮｏｄｅＢから送信されるデータに基づいた意志決定に要する時間が短く出来る。なお、以下の説明では、Ｓｈｏｒｔ  ＴＴＩと区別するために、既存のＴＴＩのことをＮｏｒｍａｌ  ＴＴＩと称することもある。従って、ＴＴＩが短くなれば、ＵＥは何らかの制御を低遅延で行うことが可能になる。例えば、ＵＥにおいて、リアルタイム性が強く求められる等の理由で遅延に厳しい何らかのアプリケーションを動かす場合には、デコード時間が短くなることは非常に大きなメリットとなる。ＵＥが例えば自動車やドローン（自律飛行する飛行体）のような物体の場合にも、リアルタイム性が強く求められるため、ＴＴＩが短くなることは非常に大きなメリットとなる。
【００２６】
ＴＴＩが短くなれば、第二に、Ｈｙｂｒｉｄ  ＡＲＱのＲＴＴの低減が可能になる。すなわち、ＵＥは、デコード時間が短くなれば、データの受信の成否をより早く判別できるようになる。ＵＥは、データの受信の成否をより早く判別できると、ｅＮｏｄｅＢへのＡＣＫまたはＮＡＣＫの返信を素早く行える。よって、ＴＴＩが短くなれば、ｅＮｏｄｅＢは、ＵＥにデータを送信してから、ＵＥで受信できなかったデータの再送までの時間を短縮でき、スループットの向上にも繋がる。ＬＴＥのＨｙｂｒｉｄ  ＡＲＱでは、ＵＥがデータの受信に成功しないと次のデータを送れないので、ＡＣＫをＵＥからｅＮｏｄｅＢへ早く送ることも、スループットの向上に寄与する。
【００２７】
ＴＴＩが短くなれば、第三に、ＣＱＩ（Channel Quality Indicator）のフィードバックの遅延の低減が可能になる。ＵＥは、ｅＮｏｄｅＢから提供されるＲｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌに基づいてダウンリンクチャネルの品質を測定し、品質の測定結果をｅＮｏｄｅＢへ報告している。そしてｅＮｏｄｅＢは、ＵＥから報告されたダウンリンクチャネルの品質を考慮して、ＵＥに対するダウンリンクデータの変調方式を決定している。ＵＥからのフィードバックの遅延が大きいと、ｅＮｏｄｅＢは、本来のダウンリンクの品質と異なった品質に対応する変調方式でデータをＵＥに送ってしまう。従って、ダウンリンクチャネルの品質の測定の遅延と、測定結果の報告の遅延を低減できれば、ｅＮｏｄｅＢは、適切な変調方式をＵＥのために選択するまでの時間を低減できる。適切な変調方式を選択するまでの時間を低減できれば、ダウンリンクのスループットの向上が見込める。
【００２８】
既存の送信時間間隔より短い短送信時間間隔でデータを送信することで、上述したような効果が見込める。しかし、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信に全て置き換えると既存の送信時間間隔でのデータの送受信しか出来ない端末装置に影響が出る。そのため、既存の送信時間間隔でのデータの送受信と短送信時間間隔でのデータの送受信とを混在させる必要がある。
【００２９】
ここで、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な受信処理を可能にするための技術が必要になる。
【００３０】
Ｓｈｏｒｔ  ＴＴＩを導入すると、受信側のデコードに必要な回路の使い回しができなくなる。あるデータを受信してデコードしてから、次のデータを受信してデコードするまでに時間の余裕があれば、一つの乗算器を使って計算できるが、時間の余裕が無ければ、乗算器が一つでは足りず、乗算器を複数用意しなければならない。従ってＳｈｏｒｔ  ＴＴＩを実現するために、受信機の計算コストがアップして、ハード規模が大きくなる場合がある。ｅＮｏｄｅＢに繋がるＵＥは、様々なメーカーから提供されうる。メーカーによっては、ハード規模を小さく抑えたいところもあるし、ハード規模を小さくする技術に長けているところもある。全てのＵＥが同じＳｈｏｒｔ  ＴＴＩの長さに対応できるかは分からない。なお、以下の説明では、Ｓｈｏｒｔ  ＴＴＩの長さの違いを意味する用語として「レベル」という言葉を使用しうる。従って、ｅＮｏｄｅＢ側が様々なレベルのＳｈｏｒｔ  ＴＴＩを用意しておくことが、Ｓｈｏｒｔ  ＴＴＩに対応した端末の普及につながる。
【００３１】
また、ＵＥがＳｈｏｒｔ  ＴＴＩに対応したとしても、そもそも、全てのＵＥが同じように低遅延を求めているかはわからない。要求される遅延時間は、ＵＥに搭載される上位のアプリケーションに依存する。従って、それほど低遅延を求めていないＵＥに１ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩを提供することは、無駄なリソースの占有につながる。
【００３２】
そこで、本件開示者は、上述の点に鑑み、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、短送信時間間隔でのデータの送受信に対応した端末装置での効率的な受信処理が期待出来る技術について鋭意検討を行った。その結果、本件開示者は、以下で説明するように、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを基地局から通知することで、端末装置での効率的な受信処理が可能な技術を考案するに至った。
【００３３】
以上、本開示の実施の形態の概要について説明した。続いて、本開示の実施の形態について詳細に説明する。
【００３４】
［１．２．システム構成例］
図４は、本開示の実施の形態に係るシステムの構成例を示す説明図である。以下、図４を用いて本開示の実施の形態に係るシステムの構成例について説明する。
【００３５】
図４を参照すると、システム１は、基地局１００及び端末装置２００を含む。ここでは、基地局１００はｅＮｏｄｅＢとも呼ばれる。またここでは、端末装置２００は、ユーザとも呼ばれる。当該ユーザは、ユーザ機器（ＵＥ）とも呼ばれ得る。ここでのＵＥは、ＬＴＥ又はＬＴＥ−Ａにおいて定義されているＵＥであってもよく、より一般的に通信機器を意味してもよい。
【００３６】
（１）基地局１００
基地局１００は、セルラーシステム（又は移動体通信システム）の基地局である。基地局１００は、基地局１００のセル１０内に位置する端末装置（例えば、端末装置２００）との無線通信を行う。例えば、基地局１００は、端末装置へのダウンリンク信号を送信し、端末装置からのアップリンク信号を受信する。
【００３７】
（２）端末装置２００
端末装置２００は、セルラーシステム（又は移動体通信システム）において通信可能である。端末装置２００は、セルラーシステムの基地局（例えば、基地局１００）との無線通信を行う。例えば、端末装置２００は、基地局からのダウンリンク信号を受信し、基地局へのアップリンク信号を送信する。図４には、４つの端末装置２００Ａ〜２００Ｄを図示している。なお以下の説明では、特に区別する必要が無ければ端末装置２００
【００３８】
［１．３．機能構成例］
続いて、図５及び図６を参照して、本開示の実施形態に係る基地局１００及び端末装置２００の機能構成例を説明する。
【００３９】
まず、図５を参照して、本開示の実施形態に係る基地局１００の構成の一例を説明する。図５は、本開示の実施形態に係る基地局１００の構成の一例を示すブロック図である。図５を参照すると、基地局１００は、アンテナ部１１０、無線通信部１２０、ネットワーク通信部１３０、記憶部１４０及び処理部１５０を備える。
【００４０】
（１）アンテナ部１１０
アンテナ部１１０は、無線通信部１２０により出力される信号を電波として空間に放射する。また、アンテナ部１１０は、空間の電波を信号に変換し、当該信号を無線通信部１２０へ出力する。
【００４１】
（２）無線通信部１２０
無線通信部１２０は、信号を送受信する。例えば、無線通信部１２０は、端末装置へのダウンリンク信号を送信し、端末装置からのアップリンク信号を受信する。
【００４２】
（３）ネットワーク通信部１３０
ネットワーク通信部１３０は、情報を送受信する。例えば、ネットワーク通信部１３０は、他のノードへの情報を送信し、他のノードからの情報を受信する。例えば、上記他のノードは、他の基地局及びコアネットワークノードを含む。
【００４３】
（４）記憶部１４０
記憶部１４０は、基地局１００の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
【００４４】
（５）処理部１５０
処理部１５０は、基地局１００の様々な機能を提供する。処理部１５０は、送信処理部１５１及び通知部１５３を含む。なお、処理部１５０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部１５０は、これらの構成要素の動作以外の動作も行い得る。
【００４５】
送信処理部１５１は、端末装置２００へ向けたデータの送信に関する処理を実行する。例えば、送信処理部１５１は、複数のサブフレームからなるフレームを生成し、生成したフレームを端末装置２００に送信する処理を実行する。また通知部１５３は、端末装置２００に対する情報の通知に関する処理を実行する。なお、送信処理部１５１及び通知部１５３の具体的な動作は、後に詳細に説明する。
【００４６】
次に、図６を参照して、本開示の実施形態に係る端末装置２００の構成の一例を説明する。図６は、本開示の実施形態に係る端末装置２００の構成の一例を示すブロック図である。図６を参照すると、端末装置２００は、アンテナ部２１０、無線通信部２２０、記憶部２３０及び処理部２４０を備える。
【００４７】
（１）アンテナ部２１０
アンテナ部２１０は、無線通信部２２０により出力される信号を電波として空間に放射する。また、アンテナ部２１０は、空間の電波を信号に変換し、当該信号を無線通信部２２０へ出力する。
【００４８】
（２）無線通信部２２０
無線通信部２２０は、信号を送受信する。例えば、無線通信部２２０は、基地局からのダウンリンク信号を受信し、基地局へのアップリンク信号を送信する。
【００４９】
（３）記憶部２３０
記憶部２３０は、端末装置２００の動作のためのプログラム及び様々なデータを一時的に又は恒久的に記憶する。
【００５０】
（４）処理部２４０
処理部２４０は、端末装置２００の様々な機能を提供する。処理部２４０は、取得部２４１、受信処理部２４３及び通知部２４５を含む。なお、処理部２４０は、これらの構成要素以外の他の構成要素をさらに含み得る。即ち、処理部２４０は、これらの構成要素の動作以外の動作も行い得る。
【００５１】
取得部２４１は、基地局１００から送信されたデータの取得に関する処理を実行する。受信処理部２４３は、取得部２４１が取得したデータの受信に関する処理を実行する。通知部２４５は、基地局１００に対する情報の通知に関する処理を実行する。なお、取得部２４１、受信処理部２４３及び通知部２４５の動作は、後に詳細に説明する。
【００５２】
以上、図５及び図６を参照して、本開示の実施形態に係る基地局１００及び端末装置２００の機能構成例を説明した。続いて、本開示の実施形態に係る基地局１００及び端末装置２００の動作例を説明する。
【００５３】
［１．４．動作例］
（１．４．１．第１の動作例）
まず、本開示の実施形態に係る基地局１００及び端末装置２００の第１の動作例を説明する。上述したように、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な処理を可能にするための技術が必要になる。第１の動作例では、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な処理を可能にするための動作例を説明する。
【００５４】
既存のＴＴＩでのデータの送受信にＳｈｏｒｔ  ＴＴＩでのデータの送受信を混在させる場合、基地局１００は、Ｓｈｏｒｔ  ＴＴＩでのデータの送受信で使用するリソースがどこにあるかを端末装置２００に知らせる必要がある。Ｓｈｏｒｔ  ＴＴＩでのデータの送受信で使用するリソースの場所は、準静的に知らせる方法と、動的に知らせる方法とが考えられる。準静的に、それぞれの端末装置２００に対するリソースを通知する方法は、１台の端末装置２００のためのダウンリンクリソースを準静的に固定的に割り当てるため、Ｓｈｏｒｔ  ＴＴＩでのデータの送受信を使用しない場合にはダウンリンクリソースが無駄になってしまう。一方、動的に、それぞれの端末装置２００に対するリソースを通知する方法は、端末装置２００が観測すべき制御情報が増えるとともに、セル１０内に位置する端末装置２００が増加すると制御領域（ＰＤＣＣＨ）が足りなくなってしまう。
【００５５】
そこで、基地局１００は、Ｓｈｏｒｔ  ＴＴＩのリソースを割り当てる際に、（１）Ｓｈｏｒｔ  ＴＴＩでのデータの送受信を行う領域（Ｓｈｏｒｔ  ＴＴＩ領域）がどこにあるかを通知する方法、（２）Ｓｈｏｒｔ  ＴＴＩ領域にある、特定の端末装置向けの情報が有るか無いかを通知する方法、（３）端末装置ごとにＳｈｏｒｔ  ＴＴＩのリソースを通知する方法、の３つの方法をとりうる。なお、この３つの方法は、基地局１００にとって全てが必須であるとは限らない。以下において、この３つの方法の詳細について説明する。
【００５６】
（１）Ｓｈｏｒｔ  ＴＴＩ領域がどこにあるかを通知する方法
まず、Ｓｈｏｒｔ  ＴＴＩ領域がどこにあるかを通知する方法を説明する。基地局１００は、例えば、ブロードキャストを用いたシステム情報、または、端末装置２００ごとのdedicated signalを用いて、準静的に１つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩ領域を端末装置２００に通知する。ここで「準静的（Ｓｅｍｉ−Ｓｔａｔｉｃ）に」とは、基地局１００がＳｈｏｒｔ  ＴＴＩ領域を再指定するまでＳｈｏｒｔ  ＴＴＩ領域は変化しないが、Ｓｈｏｒｔ  ＴＴＩ領域は変更可能（ｃｈａｎｇｅａｂｌｅ）であることを意味する。なお、１つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩ領域は複数存在していても良い。
【００５７】
基地局１００は、準静的に１つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩ領域を端末装置２００に通知するが、この時点ではそのＳｈｏｒｔ  ＴＴＩ領域をそれぞれの端末装置２００がどのように使用するかまでは通知しない。
【００５８】
図７は、Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。図７の符号３０１は、１つのサブフレームの、ＰＤＳＣＨ（Physical Downlink Shared Channel）において指定されたＳｈｏｒｔ  ＴＴＩ領域を指している。図７に示したのは、２０ＭＨｚのバンド幅の一部の周波数の領域におけるＴＴＩを１ＯＦＤＭシンボルと同じ長さとする例である。
【００５９】
上述したように、１つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩ領域は複数存在していても良い。図８は、Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。図８に示したのは、１つのサブフレームにおいてＳｈｏｒｔ  ＴＴＩ領域が２つ存在している例である。符号３０１、３０２は、１つのサブフレームの、ＰＤＳＣＨにおいて指定されたＳｈｏｒｔ  ＴＴＩ領域を指している。符号３０１で示したＳｈｏｒｔ  ＴＴＩ領域はＰＤＳＣＨの全体に渡っており、符号３０２で示したＳｈｏｒｔ  ＴＴＩ領域は後半の７ＯＦＤＭシンボル分のＰＤＳＣＨに渡っている。また図８に示したのは、符号３０２で示したＳｈｏｒｔ  ＴＴＩ領域のリソースが、符号３０１で示したＳｈｏｒｔ  ＴＴＩ領域のリソースより多くなっている例である。
【００６０】
また、全てのサブフレームに渡ってＳｈｏｒｔ  ＴＴＩ領域が存在しても良く、１フレーム中の特定のサブフレームにおいてＳｈｏｒｔ  ＴＴＩ領域が存在しても良い。全てのサブフレームに渡ってＳｈｏｒｔ  ＴＴＩ領域を必要とするアプリケーションもあれば、１フレーム中の特定のサブフレームにおいてＳｈｏｒｔ  ＴＴＩ領域が存在していれば足りるアプリケーションもあるからである。
【００６１】
例えば、基地局１００が、１フレーム中の特定の場所で制御信号を端末装置２００に送信するが、その制御信号を端末装置２００が短い時間でデコードしてくれることを期待するようなユースケースが考えられる。このユースケースは、基地局１００が、Ｓｈｏｒｔ  ＴＴＩ領域を、端末装置２００の制御信号を送るための領域として使用するようなユースケースである。基地局１００がＳｈｏｒｔ  ＴＴＩ領域で送信する端末装置２００の制御信号は、アプリケーションの制御のための信号であってもよく、無線信号の受信のための制御信号であってもよい。
【００６２】
上述したように、全てのサブフレームに渡ってＳｈｏｒｔ  ＴＴＩ領域が存在しても良いが、１フレーム中の特定のサブフレームにおいてＳｈｏｒｔ  ＴＴＩ領域が存在しても良い。また基地局１００は、サブフレーム毎にＳｈｏｒｔ  ＴＴＩ領域を変化させても良い。基地局１００は、サブフレーム毎にＳｈｏｒｔ  ＴＴＩ領域を変化させることで設定の自由度を高めることが出来る。
【００６３】
図９は、Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。図９に示したのは、符号３０２で示したＳｈｏｒｔ  ＴＴＩ領域を基地局１００が予め設定しておき、その領域に実際にＳｈｏｒｔ  ＴＴＩのデータが入るかどうかは、基地局１００が、符号３０３で示したＰＤＣＣＨの中のＤＣＩ（Downlink Control Information）で動的に設定する場合の例である。
【００６４】
基地局１００が、符号３０３で示したＰＤＣＣＨの中のＤＣＩで、Ｓｈｏｒｔ  ＴＴＩ領域にデータが存在するかどうかを設定することで、Ｓｈｏｒｔ  ＴＴＩ領域が常に固定で配置されることによるリソースの無駄遣いを防ぐことが出来る。すなわち、基地局１００は、Ｓｈｏｒｔ  ＴＴＩ領域を設定しても、Ｓｈｏｒｔ  ＴＴＩ領域で常にＳｈｏｒｔ  ＴＴＩのデータを入れて送信するとは限らないので、ＰＤＣＣＨの中のＤＣＩで、Ｓｈｏｒｔ  ＴＴＩ領域にデータが存在するかどうかを設定してリソースの無駄遣いを防ぐことを可能にする。
【００６５】
図１０は、Ｓｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。図１０に示したのは、図９と同様に、符号３０２で示したＳｈｏｒｔ  ＴＴＩ領域を基地局１００が予め設定しておき、その領域に実際にＳｈｏｒｔ  ＴＴＩのデータが入るかどうかは、基地局１００が、符号３０３で示したＰＤＣＣＨの中のＤＣＩで動的に設定する場合の例である。
【００６６】
図１０に示した例が図９に示した例と異なるのは、符号３０３で示したＰＤＣＣＨの中のＤＣＩで設定しているのが、同一のサブフレームではなく、後続の別のサブフレームのＳｈｏｒｔ  ＴＴＩ領域におけるデータの有無である点である。図９に示した例では、ＰＤＣＣＨの中のＤＣＩで設定しているのが、同一のサブフレームのＳｈｏｒｔ  ＴＴＩ領域におけるデータの有無であることから、端末装置２００は、ＰＤＣＣＨをデコードして、同一のサブフレームのＳｈｏｒｔ  ＴＴＩ領域におけるデータの有無を即座に判断しなければならない。図１０に示した例では、ＰＤＣＣＨの中のＤＣＩで設定しているのが、後続の別のサブフレームのＳｈｏｒｔ  ＴＴＩ領域におけるデータの有無であることから、端末装置２００は、後続の別のサブフレームのＳｈｏｒｔ  ＴＴＩ領域が到来した時点では既にその領域にＳｈｏｒｔ  ＴＴＩのデータがあるかどうかが分かっている。従って、図１０に示した例では、端末装置２００は、後続の別のサブフレームのＳｈｏｒｔ  ＴＴＩ領域が到来した時点で、Ｓｈｏｒｔ  ＴＴＩのデータがあればすぐにデコードを開始することが出来る。
【００６７】
図１１は、本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。図１１に示したのは、基地局１００がＳｈｏｒｔ  ＴＴＩとして使用される可能性のある領域を端末装置２００へ通知すると共に、通知した領域がＳｈｏｒｔ  ＴＴＩとして使用されることを端末装置２００へ通知する際の基地局１００の動作例である。以下、図１１を用いて本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を説明する。
【００６８】
基地局１００は、サブフレームにおけるＳｈｏｒｔ  ＴＴＩ領域（Ｓｈｏｒｔ  ＴＴＩになる可能性のある領域）を端末装置２００へ通知する（ステップＳ１０１）。ステップＳ１０１の処理は、例えば通知部１５３が実行する。基地局１００は、ブロードキャストを用いたシステム情報、または、端末装置２００ごとのdedicated signalを用いて、準静的に１つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩとして使用される可能性のある領域を通知する。
【００６９】
基地局１００は、Ｓｈｏｒｔ  ＴＴＩになる可能性のある領域を端末装置２００へ通知すると、続いて、サブフレームごとに、Ｓｈｏｒｔ  ＴＴＩになる可能性のある領域が実際にＳｈｏｒｔ  ＴＴＩとして使用されることを動的に通知する（ステップＳ１０２）。ステップＳ１０２の処理は、例えば通知部１５３が実行する。基地局１００は、例えば、上述したようにＰＤＣＣＨの中のＤＣＩにおいて、Ｓｈｏｒｔ  ＴＴＩとして使用される可能性のある領域が実際にＳｈｏｒｔ  ＴＴＩとして使用されるかどうかを指定する。
【００７０】
基地局１００が、このように動作することで、基地局１００は、リソースを効率的に使用することができ、端末装置２００は、Ｓｈｏｒｔ  ＴＴＩになる可能性のある領域が実際にＳｈｏｒｔ  ＴＴＩとして使用される場合にＳｈｏｒｔ  ＴＴＩ用の動作を実行すれば良いので受信処理が効率化できる。
【００７１】
（２）Ｓｈｏｒｔ  ＴＴＩ領域にある、特定の端末装置向けの情報が有るか無いかを通知する方法
次に、Ｓｈｏｒｔ  ＴＴＩ領域にある、特定の端末装置向けの情報が、そのＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する方法を説明する。例えば、基地局１００は、端末装置２００ごとに、準静的な方法で通知したＳｈｏｒｔ  ＴＴＩ領域内にその端末装置２００に宛てた情報があるかどうかを動的に通知する。基地局１００は、例えば、dedicated signalingを使用して準静的に、またはＰＤＣＣＨを使用して動的に、Ｓｈｏｒｔ  ＴＴＩ領域内にその端末装置２００に宛てた情報があるかどうかを通知する。基地局１００は、dedicated signalingを使用して準静的に通知すれば、既存のＤＣＩに変更を加えずに、Ｓｈｏｒｔ  ＴＴＩ領域内にその端末装置２００に宛てた情報があるかどうかを通知することが出来る。また基地局１００は、ＰＤＣＣＨを使用して動的に通知すれば、Ｓｈｏｒｔ  ＴＴＩのデータを送信する場合にだけＳｈｏｒｔ  ＴＴＩ領域にＳｈｏｒｔ  ＴＴＩのデータを入れれば良いので、リソースを効率的に使用することが出来る。
【００７２】
その際、基地局１００は、Ｓｈｏｒｔ  ＴＴＩ領域内にその端末装置２００に宛てた情報があるかどうかだけを通知する。Ｓｈｏｒｔ  ＴＴＩ領域に、それぞれの端末装置２００にとって関係するデータがあるかどうかは、端末装置２００が少ない手間で判別できるようにすることが望ましい。Ｓｈｏｒｔ  ＴＴＩ領域内にデータが無い端末装置２００は、Ｓｈｏｒｔ  ＴＴＩのデータをデコードする必要が無いので、消費電力を低減することが出来るからである。
【００７３】
図１２は、基地局１００が、特定の端末装置向けの情報がＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する方法について説明する説明図である。図１２に示したのは、サブフレームのＰＤＣＣＨにおいて、特定の端末装置向けの情報が同じサブフレーム内のＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する様子である。
【００７４】
図１３は、基地局１００が、特定の端末装置向けの情報がＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する方法について説明する説明図である。図１３に示したのは、基地局１００が、サブフレームのＰＤＣＣＨにおいて、特定の端末装置向けの情報が後続のサブフレーム内のＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する様子である。
【００７５】
図１３に示した方法は、図１２に示した方法と同じような方法ではあるが、基地局１００が、サブフレームのＰＤＣＣＨにおいて、特定の端末装置向けの情報が後続のサブフレーム内のＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知することで、端末装置２００でのＳｈｏｒｔ  ＴＴＩのデータのデコードの開始タイミングを早めることが可能になる。
【００７６】
基地局１００は、特定の端末装置向けの情報がＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する際に、ＰＤＣＣＨ（またはｅＰＤＣＣＨ）の端末装置２００固有なサーチスペースの中にあるＤＣＩを使用して指定しても良い。図１４は、基地局１００がＰＤＣＣＨの端末装置２００固有なサーチスペースの中にあるＤＣＩを使用して特定の端末装置向けの情報がＳｈｏｒｔ  ＴＴＩ領域に有るか無いかを通知する例を示す説明図である。
【００７７】
基地局１００は、ＰＤＣＣＨを使用して動的に通知すれば、Ｓｈｏｒｔ  ＴＴＩのデータを送信する場合にだけＳｈｏｒｔ  ＴＴＩ領域にＳｈｏｒｔ  ＴＴＩのデータを入れれば良いので、リソースを効率的に使用することが出来る。また端末装置２００は、Ｓｈｏｒｔ  ＴＴＩ領域に、それぞれの端末装置２００にとって関係するデータがあるかどうかを、少ない手間で判別することができる。また、Ｓｈｏｒｔ  ＴＴＩ領域内にデータが無い端末装置２００は、Ｓｈｏｒｔ  ＴＴＩのデータをデコードする必要が無いので、消費電力を低減することが出来るからである。
【００７８】
（３）端末装置ごとにＳｈｏｒｔ  ＴＴＩのリソースを通知する方法
基地局１００は、Ｓｈｏｒｔ  ＴＴＩ領域にＳｈｏｒｔ  ＴＴＩのデータがあるかどうかをＤＣＩで通知してもよいが、その通知の際に、そのＳｈｏｒｔ  ＴＴＩ領域のどのリソースが、対象の端末装置２００が受信してデコードすべきＳｈｏｒｔ  ＴＴＩのデータであるかも通知しても良い。
【００７９】
図１５は、基地局１００が、Ｓｈｏｒｔ  ＴＴＩ領域におけるＳｈｏｒｔ  ＴＴＩのデータの場所をＤＣＩで通知する様子を示す説明図である。図１５に示した例では、同一のサブフレームにおける符号３０５で示した場所が、対象の端末装置２００が受信してデコードすべきＳｈｏｒｔ  ＴＴＩのデータがある場所であるとする。基地局１００は、符号３０５で示した場所にデコードすべきＳｈｏｒｔ  ＴＴＩのデータがあることを、対象の端末装置２００にＤＣＩで通知する。このように通知することで、ＤＣＩを受信した端末装置２００は、その場所だけを参照してデコードすることができる。
【００８０】
図１６は、基地局１００が、Ｓｈｏｒｔ  ＴＴＩ領域におけるＳｈｏｒｔ  ＴＴＩのデータの場所をＤＣＩで通知する様子を示す説明図である。図１６に示した例では、後続のサブフレームにおける符号３０５で示した場所が、対象の端末装置２００が受信してデコードすべきＳｈｏｒｔ  ＴＴＩのデータがある場所であるとする。基地局１００は、符号３０５で示した場所にデコードすべきＳｈｏｒｔ  ＴＴＩのデータがあることを、対象の端末装置２００にＤＣＩで通知する。このように通知することで、ＤＣＩを受信した端末装置２００は、その場所だけを参照してデコードすることができる。
【００８１】
なお、基地局１００は、ＰＤＣＣＨではなく、ＰＤＳＣＨの部分に制御信号が入っているｅＰＤＣＣＨで、Ｓｈｏｒｔ  ＴＴＩに関する情報を通知しても良い。ｅＰＤＣＣＨで通知する場合、基地局１００は、同一のサブフレームにおけるＳｈｏｒｔ  ＴＴＩに関する情報を通知してもよく、後続のサブフレームにおけるＳｈｏｒｔ  ＴＴＩに関する情報を通知してもよい。
【００８２】
図１７は、本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。図１７に示したのは、基地局１００がＳｈｏｒｔ  ＴＴＩとして使用される可能性のある領域を端末装置２００へ通知してから、端末装置２００が受信データに対してＡＣＫまたはＮＡＣＫを返すまでの、基地局１００及び端末装置２００の動作例である。以下、図１７を用いて本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を説明する。
【００８３】
基地局１００は、サブフレームにおけるＳｈｏｒｔ  ＴＴＩ領域（Ｓｈｏｒｔ  ＴＴＩになる可能性のある領域）を端末装置２００へ通知する（ステップＳ１０１）。ステップＳ１０１の処理は、例えば通知部１５３が実行する。基地局１００は、ブロードキャストを用いたシステム情報、または、端末装置２００ごとのdedicated signalを用いて、準静的に１つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩとして使用される可能性のある領域を通知する。
【００８４】
基地局１００は、Ｓｈｏｒｔ  ＴＴＩになる可能性のある領域を端末装置２００へ通知すると、続いて、サブフレームごとに、Ｓｈｏｒｔ  ＴＴＩになる可能性のある領域が実際にＳｈｏｒｔ  ＴＴＩとして使用されることを動的に通知する（ステップＳ１０２）。ステップＳ１０２の処理は、例えば通知部１５３が実行する。基地局１００は、例えば、上述したようにＰＤＣＣＨの中のＤＣＩにおいて、Ｓｈｏｒｔ  ＴＴＩとして使用される可能性のある領域が実際にＳｈｏｒｔ  ＴＴＩとして使用されるかどうかを指定する。
【００８５】
続いて基地局１００は、Ｓｈｏｒｔ  ＴＴＩの中にある、特定の端末装置２００のためのリソースの有無を端末装置２００へ通知する（ステップＳ１０３）。ステップＳ１０３の処理は、例えば通知部１５３が実行する。
【００８６】
続いて基地局１００は、Ｓｈｏｒｔ  ＴＴＩの中にある、特定の端末装置２００が受信すべきリソースの場所を端末装置２００へ通知する（ステップＳ１０４）。ステップＳ１０４の処理は、例えば通知部１５３が実行する。
【００８７】
続いて基地局１００は、上記ステップＳ１０４で通知したリソースの場所にＳｈｏｒｔ  ＴＴＩのデータを入れて端末装置２００へ送信する（ステップＳ１０５）。ステップＳ１０５の処理は、例えば送信処理部１５１が、無線通信部１２０からアンテナ部１１０を通じてデータを送信させることにより実行する。
【００８８】
端末装置２００は、上記ステップＳ１０１〜Ｓ１０４において基地局１００から通知される情報に基づいて、上記ステップＳ１０５で基地局１００から送信されたＳｈｏｒｔ  ＴＴＩのデータをデコードする（ステップＳ１０６）。ステップＳ１０６の処理は、例えば受信処理部２４３が実行する。
【００８９】
端末装置２００は、ステップＳ１０６でＳｈｏｒｔ  ＴＴＩのデータをデコードすると、基地局１００に対し、デコードに成功すればＡＣＫを、失敗すればＮＡＣＫを、それぞれ通知する（ステップＳ１０７）。ステップＳ１０７の処理は、例えば通知部２４５が実行する。
【００９０】
従来のｅＮｏｄｅＢは、ＰＤＣＣＨの中のＤＣＩにおいて各ＵＥに対するリソースを個々に指定していた。しかしＳｈｏｒｔ  ＴＴＩのリソースは、従来のＴＴＩのリソースとは異なり、特殊である。その特殊なＳｈｏｒｔ  ＴＴＩが常に存在するとは限らないため、Ｓｈｏｒｔ  ＴＴＩ領域は、ある程度可変にすることが望ましい。しかし、Ｓｈｏｒｔ  ＴＴＩ領域と通常のＴＴＩ領域とが確定しないと、ＰＤＣＣＨから直接リソースの指定ができないことから、ＰＤＣＣＨからＳｈｏｒｔ  ＴＴＩのリソースを直接指定することは困難である。
【００９１】
従って本実施形態の第１の動作例では、基地局１００は、準静的にＳｈｏｒｔ  ＴＴＩ領域を指定するとともに、そのＳｈｏｒｔ  ＴＴＩ領域が存在するかどうかを動的に指定する。基地局１００は、端末装置２００に対して、その端末装置２００のＳｈｏｒｔ  ＴＴＩのデータがあるかどうかを、ＰＤＣＣＨを使った動的な方法や、dedicated signalingを用いた準静的な方法で通知する。このように通知することにより、従来のＰＤＣＣＨで全てリソースを直接指定した方法に比べて、通常ＴＴＩのリソース、Ｓｈｏｒｔ  ＴＴＩのリソースともに従来に比べて効率的な運用が可能になる。
【００９２】
本実施形態の第１の動作例は、準静的にＳｈｏｒｔ  ＴＴＩ領域を指定するとともに、そのＳｈｏｒｔ  ＴＴＩ領域が存在するかどうかを動的に指定することで、端末装置２００に搭載されているアプリケーションを基地局１００が低遅延で、かつレスポンス良く制御することが可能になる。また本実施形態の第１の動作例は、端末装置２００がＡＣＫまたはＮＡＣＫを早く返すことが可能なので、スループットの向上が見込まれる。そして、本実施形態の第１の動作例は、効率的にＳｈｏｒｔ  ＴＴＩのリソースを既存のＴＴＩのリソースと混在することができるので、リソースの無駄が生じず、かつスループットの向上が大いに期待できる。
【００９３】
（１．４．２．第２の動作例）
続いて、本開示の実施形態に係る基地局１００及び端末装置２００の第２の動作例を説明する。上述したように、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、基地局側が様々なレベルのＳｈｏｒｔ  ＴＴＩを用意しておくことが、Ｓｈｏｒｔ  ＴＴＩに対応した端末装置の普及に繋がる。第２の動作例では、様々なレベルのＳｈｏｒｔ  ＴＴＩを用意した際の基地局１００及び端末装置２００の動作例を説明する。
【００９４】
図１８は、１ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩを示す説明図である。１ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩをレベル１のＳｈｏｒｔ  ＴＴＩとも称する。また図１９は、２ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩを示す説明図である。２ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩをレベル２のＳｈｏｒｔ  ＴＴＩとも称する。
【００９５】
Ｓｈｏｒｔ  ＴＴＩのレベルが１の場合には、ＬＴＥのリソースが無駄に占有されて全体のスループットが低下する。その理由としては、Ｓｈｏｒｔ  ＴＴＩに対応した全ての端末装置２００が同じようなＳｈｏｒｔ  ＴＴＩのレベルを必要としない場合があるからである。また、Ｓｈｏｒｔ  ＴＴＩに対応した全ての端末装置２００が、同じようにＳｈｏｒｔ  ＴＴＩのレベルを実現できるとは限らない。従って、通信事業者が複数のＳｈｏｒｔ  ＴＴＩのレベルを用意しておくことにより、様々なベンダー（メーカー）が製造するＳｈｏｒｔ  ＴＴＩに対応する端末装置２００が、複数のＳｈｏｒｔ  ＴＴＩのレベルを用意するＬＴＥネットワークに接続することが可能になる。
【００９６】
基地局１００は、複数のＳｈｏｒｔ  ＴＴＩのレベルを用意する。Ｓｈｏｒｔ  ＴＴＩのレベルの設定はセル毎に異なっていてもよい。基地局１００は、その基地局１００が提供する複数のＳｈｏｒｔ  ＴＴＩのレベルを、ブロードキャストで、例えばシステムインフォメーションで端末装置２００に通知しておく。
【００９７】
端末装置２００は、処理能力（例えばハードウェア的な能力や、実行するアプリケーションのカテゴリや、自装置のケイパビリティ）を基地局１００に通知する。また端末装置２００は、実行するアプリケーション毎に要求する遅延レベルを設定してもよい。端末装置２００に低遅延で処理できる能力があっても、その端末装置２００が実行するアプリケーションによっては低遅延を求めない場合もあるからである。
【００９８】
端末装置２００は、同じサブフレームの中で複数のレベルのＳｈｏｒｔ  ＴＴＩが混在して状態であっても、その複数のレベルのＳｈｏｒｔ  ＴＴＩのデータを処理してもよい。また、端末装置２００は、通常のＴＴＩのデータとＳｈｏｒｔ  ＴＴＩのデータとを並行して処理しても良い。
【００９９】
図２０は、本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。以下、図２０を用いて本開示の実施の形態に係る基地局１００及び端末装置２００の動作例について説明する。
【０１００】
基地局１００は、提供可能なＳｈｏｒｔ  ＴＴＩのレベルを、セル内に位置する端末装置２００に向けてブロードキャストで提供する（ステップＳ２０１）。ステップＳ２０１の処理は、例えば通知部１５３が実行する。
【０１０１】
基地局１００が提供可能なＳｈｏｒｔ  ＴＴＩのレベルを基地局１００から受信した端末装置２００は、Ｓｈｏｒｔ  ＴＴＩを処理できるケイパビリティを基地局１００に通知する（ステップＳ２０２）。ステップＳ２０２の処理は、例えば通知部２４５が実行する。このステップＳ２０２で、端末装置２００は、ハードウェア的な処理能力の情報を基地局１００に通知してもよい。
【０１０２】
また端末装置２００は、搭載しているアプリケーションの用途に従って、Ｓｈｏｒｔ  ＴＴＩのレベルを基地局１００に要求する（ステップＳ２０３）。ステップＳ２０３の処理は、例えば通知部２４５が実行する。
【０１０３】
基地局１００は、端末装置２００からＳｈｏｒｔ  ＴＴＩを処理できるケイパビリティ及びＳｈｏｒｔ  ＴＴＩのレベルの要求を受信すると、受信した内容に基づいて、Ｓｈｏｒｔ  ＴＴＩのレベルを選択し、端末装置２００に対して、Ｓｈｏｒｔ  ＴＴＩのリソースを使用して、選択したレベルに応じたＳｈｏｒｔ  ＴＴＩのデータを送信する（ステップＳ２０４）。ステップＳ２０４の処理は、例えば送信処理部１５１が、無線通信部１２０からアンテナ部１１０を通じてデータを送信させることにより実行する。
【０１０４】
本開示の実施の形態に係る基地局１００は、このように動作することで、端末装置２００の能力や要求に応じたＳｈｏｒｔ  ＴＴＩのレベルを選択することが出来る。また本開示の実施の形態に係る端末装置２００は、このように通知することで、自装置の能力や、実行するアプリケーションの要求に応じたレベルでＳｈｏｒｔ  ＴＴＩのデータを受信することが出来る。
【０１０５】
端末装置２００の中には、小さいＳｈｏｒｔ  ＴＴＩのレベルでデータを受信しても、遅延時間がそのレベルより長くても許容できるものがあることも考えられる。図２１は、一つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩ領域の例を示す説明図である。例えば、ある端末装置２００は、Ｓｈｏｒｔ  ＴＴＩレベル１でデータを受信しても、２ＯＦＤＭシンボルの遅延が許容できるとする。その場合、基地局１００は、その端末装置２００に、図２１に示したように１ＯＦＤＭシンボルおきにＳｈｏｒｔ  ＴＴＩとして使用させる。符号３１１で示したＯＦＤＭシンボルがその端末装置２００にＳｈｏｒｔ  ＴＴＩとして使用させるＯＦＤＭシンボルである。このように基地局１００は、Ｓｈｏｒｔ  ＴＴＩ領域を１ＯＦＤＭシンボルおきに端末装置２００に使用させることで、２ＯＦＤＭシンボルの遅延が許容できる端末装置２００へのリソースを効率的に提供すること出来る。
【０１０６】
図２１に示したＳｈｏｒｔ  ＴＴＩ領域は、図１９に示した２ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩとは異なり、１ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩのリソースが間引かれている。基地局１００は、間引いたリソース（符号３１２で示したＯＦＤＭシンボル）を他の端末装置２００に使用させることができる。すなわち、基地局１００は、１ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩのリソースを１ＯＦＤＭシンボルおきに間引くことで遅延制御のレベルを下げていることになる。なお、１ＯＦＤＭシンボルの遅延を要求する端末装置２００は、図２１の符号３１１、３１２のいずれのＯＦＤＭシンボルのリソースで基地局１００からＳｈｏｒｔ  ＴＴＩのデータを受信しても良い。
【０１０７】
図１９に示したような２ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩは、１つのサブフレームで完結させることができる。しかし、例えば４ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩは、１つのサブフレームで完結させることができない。図２２は、４ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩを示す説明図である。Ｓｈｏｒｔ  ＴＴＩを４ＯＦＤＭシンボルで構成するレベル４のＳｈｏｒｔ  ＴＴＩは、１つのサブフレームで完結させることができないので、図２２に示したように、２つのフレームにまたがる箇所が生じる。この場合、基地局１００は、Ｓｈｏｒｔ  ＴＴＩのデータが２つのフレームにまたがっているのかどうかを端末装置２００に通知する。
【０１０８】
システムフレーム番号（Ｓｙｓｔｅｍ  Ｆｒａｍｅ  Ｎｕｍｂｅｒ；ＳＦＮ）は０から１０２３までの整数が繰り返される。またサブフレームは１つのフレームに１０個存在する。図２３は、１フレームにおける、４ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩを示す説明図である。４ＯＦＤＭシンボルでＳｈｏｒｔ  ＴＴＩが構成される場合、図２３に示したように、１番目のサブフレームと２番目のサブフレームにまたがって４ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩが配置されている。すなわち、奇数番目のサブフレームと偶数番目のサブフレームとにまたがって４ＯＦＤＭシンボルで構成されるＳｈｏｒｔ  ＴＴＩが配置されている。従って、システムフレーム番号及びサブフレーム番号と、Ｓｈｏｒｔ  ＴＴＩのフェーズとの関係を基地局１００から端末装置２００に通知できれば、端末装置２００は、４ＯＦＤＭシンボルのＳｈｏｒｔ  ＴＴＩを正常に受信できる。
【０１０９】
ＳＦＮは、基地局１００から端末装置２００へ、ＭＩＢ（Ｍａｓｔｅｒ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）というブロードキャスト信号で送信されている。従って、基地局１００は、システムフレーム番号及びサブフレーム番号と、Ｓｈｏｒｔ  ＴＴＩのフェーズとの関係を予め固定しておくか、システムフレーム番号及びサブフレーム番号と、Ｓｈｏｒｔ  ＴＴＩのフェーズとの関係をシグナリングで端末装置２００に別途通知する。基地局１００は、４ＯＦＤＭシンボルのＳｈｏｒｔ  ＴＴＩのような、１つのサブフレームで完結させることができない場合に限り、システムフレーム番号及びサブフレーム番号と、Ｓｈｏｒｔ  ＴＴＩのフェーズとの関係を通知しても良い。
【０１１０】
図２４は、本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。図２４に示したのは、Ｓｈｏｒｔ  ＴＴＩが１つのサブフレームで完結させることができない場合の基地局１００及び端末装置２００の動作例である。以下、図２４を用いて本開示の実施の形態に係る基地局１００及び端末装置２００の動作例について説明する。
【０１１１】
基地局１００は、ＭＩＢ等、ブロードキャストでシステムフレーム番号を端末装置２００に提供する（ステップＳ２１１）。ステップＳ２１１の処理は例えば通知部１５３が実行する。
【０１１２】
続いて基地局１００は、提供可能なＳｈｏｒｔ  ＴＴＩのレベルを、セル内に位置する端末装置２００に向けてブロードキャストで提供する（ステップＳ２１２）。ステップＳ２１２の処理は、例えば通知部１５３が実行する。
【０１１３】
続いて基地局１００は、各レベルのＳｈｏｒｔ  ＴＴＩと、システムフレーム番号及びサブフレーム番号との対応関係を、端末装置２００に向けてブロードキャストまたはdedicated signalingで提供する（ステップＳ２１３）。ステップＳ２１３の処理は、例えば通知部１５３が実行する。なお、各レベルのＳｈｏｒｔ  ＴＴＩと、システムフレーム番号及びサブフレーム番号との対応関係は、予めスペックで固定でも構わない。
【０１１４】
基地局１００が提供可能なＳｈｏｒｔ  ＴＴＩのレベルを基地局１００から受信した端末装置２００は、Ｓｈｏｒｔ  ＴＴＩを処理できるケイパビリティを基地局１００に通知する（ステップＳ２１４）。ステップＳ２１４の処理は、例えば通知部２４５が実行する。
【０１１５】
また端末装置２００は、搭載しているアプリケーションの用途に従って、Ｓｈｏｒｔ  ＴＴＩのレベルを基地局１００に要求する（ステップＳ２１５）。ステップＳ２１５の処理は、例えば通知部２４５が実行する。
【０１１６】
基地局１００は、端末装置２００からＳｈｏｒｔ  ＴＴＩを処理できるケイパビリティ及びＳｈｏｒｔ  ＴＴＩのレベルの要求を受信すると、受信した内容に基づいて、Ｓｈｏｒｔ  ＴＴＩのレベルを選択し、端末装置２００に対して、Ｓｈｏｒｔ  ＴＴＩのリソースを使用して、選択したレベルに応じたＳｈｏｒｔ  ＴＴＩのデータを送信する（ステップＳ２１６）。ステップＳ２１６の処理は、例えば送信処理部１５１が、無線通信部１２０からアンテナ部１１０を通じてデータを送信させることにより実行する。
【０１１７】
端末装置２００は、基地局１００からＳｈｏｒｔ  ＴＴＩのデータを受信すると、ステップＳ２１３で基地局１００から受信した対応関係に基づいてＳｈｏｒｔ  ＴＴＩのデータをデコードする。
【０１１８】
本開示の実施の形態に係る基地局１００は、このように動作することで、端末装置２００の能力や要求に応じたＳｈｏｒｔ  ＴＴＩのレベルを選択することが出来るとともに、端末装置２００に正常にＳｈｏｒｔ  ＴＴＩのデータをデコードさせることが出来る。また本開示の実施の形態に係る端末装置２００は、このように通知することで、自装置の能力や、実行するアプリケーションの要求に応じたレベルでＳｈｏｒｔ  ＴＴＩのデータを受信するとともに、正常にＳｈｏｒｔ  ＴＴＩのデータをデコードすることが出来る。
【０１１９】
１つのサブフレームには複数のレベルのＳｈｏｒｔ  ＴＴＩが混在していても良い。図２５は、１つのサブフレームに複数のレベルのＳｈｏｒｔ  ＴＴＩが混在している例を示す説明図である。
【０１２０】
図２５には、１つのサブフレームに、４ＯＦＤＭシンボルからなるレベル４のＳｈｏｒｔ  ＴＴＩと、２ＯＦＤＭシンボルからなるレベル２のＳｈｏｒｔ  ＴＴＩと、が混在している例が示されている。図２５の例では、最初のサブフレームにはレベル４のＳｈｏｒｔ  ＴＴＩが３つ続いて配置された後にレベル２のＳｈｏｒｔ  ＴＴＩが１つ配置され、次のサブフレームには最初にレベル２のＳｈｏｒｔ  ＴＴＩが１つ配置された後にレベル４のＳｈｏｒｔ  ＴＴＩが３つ続いて配置されている。もちろん、配置パターンは係る例に限定されるものでは無い。全てのサブフレームにおいて異なるレベルのＳｈｏｒｔ  ＴＴＩが同じパターンで混在して配置されてもよい。例えば、全てのサブフレームにおいて、レベル４のＳｈｏｒｔ  ＴＴＩが３つ続いて配置された後にレベル２のＳｈｏｒｔ  ＴＴＩが１つ配置されてもよい。また例えば、全てのサブフレームにおいて、最初にレベル２のＳｈｏｒｔ  ＴＴＩが１つ配置された後にレベル４のＳｈｏｒｔ  ＴＴＩが３つ続いて配置されてもよい。
【０１２１】
図２６は、Ｓｈｏｒｔ  ＴＴＩの別の配置例を示す説明図である。サブフレームには、通常、先頭部分に制御信号が格納されうるＰＤＣＣＨが配置され、ＰＤＣＣＨの後にユーザデータが格納されうるＰＤＳＣＨが配置されている。例えば、図２６に示したように３ＯＦＤＭシンボルをＰＤＳＣＨで使用し、後続のＰＤＳＣＨの部分だけをＳｈｏｒｔ  ＴＴＩとすることを考える。この場合、レベル２のＳｈｏｒｔ  ＴＴＩだけで使用しようとすると、サブフレームの最後の１ＯＦＤＭシンボル分はレベル２のＳｈｏｒｔ  ＴＴＩとして使用できない。そこで、図２６に示したように、サブフレームの最後の１ＯＦＤＭシンボル分をレベル１のＳｈｏｒｔ  ＴＴＩとして使用してもよい。なお、図２６に示したように、基地局１００は、あるＯＦＤＭシンボルをレベル１のＳｈｏｒｔ  ＴＴＩとレベル２のＳｈｏｒｔ  ＴＴＩとでリソースを分けて使用しても良い。
【０１２２】
図２７は、Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。図２７に示したＳｈｏｒｔ  ＴＴＩの配置例が、図２６に示したＳｈｏｒｔ  ＴＴＩの配置例と異なるのは、サブフレームの最後の１ＯＦＤＭシンボル分において、レベル２のＳｈｏｒｔ  ＴＴＩが配置されているリソースにはＳｈｏｒｔ  ＴＴＩが配置されていない点である。
【０１２３】
図２６や図２７に示したように、基地局１００は、あるＯＦＤＭシンボルをレベル１のＳｈｏｒｔ  ＴＴＩとレベル２のＳｈｏｒｔ  ＴＴＩとでリソースを分けて使用しても良いが、それぞれのＳｈｏｒｔ  ＴＴＩに割り当てるリソースの量を変化させても良い。図２６や図２７には、レベル２のＳｈｏｒｔ  ＴＴＩに割り当てるリソースの量がレベル１のＳｈｏｒｔ  ＴＴＩに割り当てるリソースの量と比べて多い例が示されている。基地局１００は、それぞれのレベルのＳｈｏｒｔ  ＴＴＩに割り当てるリソースの量を、例えば端末装置２００からの需要に応じて変化させても良い。
【０１２４】
図２６や図２７に示したように、ＰＤＣＣＨの部分にはＳｈｏｒｔ  ＴＴＩを配置せず、ＰＤＳＣＨの部分にのみＳｈｏｒｔ  ＴＴＩを配置する場合、ＰＤＣＣＨの長さは１ＯＦＤＭシンボルから３ＯＦＤＭシンボルまで可変である。基地局１００は、ＰＤＣＣＨの長さの情報（ＯＦＤＭシンボル数の情報）を、ＰＤＣＣＨの中にあるＰＣＦＩＣＨ（Physical Control Format Indicator Channel）で端末装置２００に通知することが出来る。ＰＤＣＣＨの長さは１ＯＦＤＭシンボルから３ＯＦＤＭシンボルまで可変であるので、ＰＤＳＣＨの長さは１１ＯＦＤＭシンボルから１３ＯＦＤＭシンボルまで可変である。従って、ＰＤＳＣＨの部分にのみＳｈｏｒｔ  ＴＴＩを配置する場合、この可変であるＰＤＳＣＨとＳｈｏｒｔ  ＴＴＩの配置パターンとの関係を端末装置２００に知らせておくことが望ましい。
【０１２５】
図２８は、Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。図２８に示したのは、ＰＤＣＣＨの長さが３ＯＦＤＭシンボル、すなわちＰＤＳＣＨの長さが１１ＯＦＤＭシンボルの場合におけるＳｈｏｒｔ  ＴＴＩの配置例である。図２８に示した例では、１つのＯＦＤＭシンボルをレベル１のＳｈｏｒｔ  ＴＴＩとレベル２のＳｈｏｒｔ  ＴＴＩとでリソースを分けて使用している。
【０１２６】
図２９は、Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。図２９に示したのは、ＰＤＣＣＨの長さが２ＯＦＤＭシンボル、すなわちＰＤＳＣＨの長さが１２ＯＦＤＭシンボルの場合におけるＳｈｏｒｔ  ＴＴＩの配置例である。図２９に示した例でも、１つのＯＦＤＭシンボルをレベル１のＳｈｏｒｔ  ＴＴＩとレベル２のＳｈｏｒｔ  ＴＴＩとでリソースを分けて使用している。
【０１２７】
図３０は、Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。図３０に示したのは、ＰＤＣＣＨの長さが１ＯＦＤＭシンボル、すなわちＰＤＳＣＨの長さが１３ＯＦＤＭシンボルの場合におけるＳｈｏｒｔ  ＴＴＩの配置例である。図３０に示した例でも、１つのＯＦＤＭシンボルをレベル１のＳｈｏｒｔ  ＴＴＩとレベル２のＳｈｏｒｔ  ＴＴＩとでリソースを分けて使用している。
【０１２８】
このようにＰＤＣＣＨの長さ（すなわちＰＤＳＣＨの長さ）に応じてＳｈｏｒｔ  ＴＴＩの配置パターンが変化する場合、基地局１００は、予め端末装置２００にＰＤＳＣＨとＳｈｏｒｔ  ＴＴＩの配置パターンとの関係を通知しておく。そして基地局１００は、ＰＣＦＩＣＨでＰＤＣＣＨの長さの情報を端末装置２００に通知する。端末装置２００は、ＰＤＣＣＨの長さの情報を知ることにより、Ｓｈｏｒｔ  ＴＴＩがどの配置パターンとなるかを知ることが出来る。
【０１２９】
図３１は、本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。以下、図３１を用いて本開示の実施の形態に係る基地局１００及び端末装置２００の動作例について説明する。
【０１３０】
基地局１００は、まずＰＣＦＩＣＨに対応した、Ｓｈｏｒｔ  ＴＴＩの配置パターンを端末装置２００に通知する（ステップＳ２２１）。ステップＳ２２１の通知は、例えば通知部１５３が実行する。ＰＣＦＩＣＨに対応した、Ｓｈｏｒｔ  ＴＴＩの配置パターンは、予めスペックで固定されていてもよい。
【０１３１】
続いて基地局１００は、ＰＣＦＩＣＨでＰＤＣＣＨの長さの情報を端末装置２００に通知する（ステップＳ２２２）。ステップＳ２２２の通知は、例えば通知部１５３が実行する。
【０１３２】
続いて基地局１００は、ＰＣＦＩＣＨに対応した、Ｓｈｏｒｔ  ＴＴＩを提供する（ステップＳ２２３）。ステップＳ２２３の処理は、例えば送信処理部１５１が、無線通信部１２０からアンテナ部１１０を通じてデータを送信させることにより実行する。例えば、ＰＤＣＣＨの長さが３ＯＦＤＭシンボルの場合のＳｈｏｒｔ  ＴＴＩの配置パターンが図２８に示したようなパターンである場合は、基地局１００は、図２８に示したようなＳｈｏｒｔ  ＴＴＩの配置パターンでＳｈｏｒｔ  ＴＴＩを提供する。
【０１３３】
端末装置２００は、ＰＣＦＩＣＨに対応した、Ｓｈｏｒｔ  ＴＴＩの配置パターンを知り、ＰＣＦＩＣＨでＰＤＣＣＨの長さの情報の通知を受けると、ＰＣＦＩＣＨに対応してＳｈｏｒｔ  ＴＴＩの配置を判別し、Ｓｈｏｒｔ  ＴＴＩのデータのデコード処理を実行する（ステップＳ２２４）。ステップＳ２２４の処理は、例えば受信処理部２４３が実行する。
【０１３４】
端末装置２００は、上述した動作を実行することで、ＰＤＣＣＨの長さの情報を知ることにより、Ｓｈｏｒｔ  ＴＴＩがどの配置パターンとなるかを知ることが出来る。そして端末装置２００は、Ｓｈｏｒｔ  ＴＴＩの配置パターンを予め知ることで、Ｓｈｏｒｔ  ＴＴＩのデータの適切なデコード処理を実行することができる。
【０１３５】
Ｓｈｏｒｔ  ＴＴＩのレベルを、例えば図２１を用いて説明したようにＯＦＤＭシンボルごとに間引いて、間欠的に配置することで実現する場合、同様にＰＤＣＣＨの長さに応じてＳｈｏｒｔ  ＴＴＩの配置パターンも変化する。
【０１３６】
図３２は、Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。図３２に示したのは、ＰＤＣＣＨの長さが３ＯＦＤＭシンボル、すなわちＰＤＳＣＨの長さが１１ＯＦＤＭシンボルの場合におけるＳｈｏｒｔ  ＴＴＩの配置例である。図３２に示した例では、レベル１のＳｈｏｒｔ  ＴＴＩを、ＯＦＤＭシンボルごとに間引いて、間欠的に配置することで実現している。
【０１３７】
図３３は、Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。図３３に示したのは、ＰＤＣＣＨの長さが２ＯＦＤＭシンボル、すなわちＰＤＳＣＨの長さが１２ＯＦＤＭシンボルの場合におけるＳｈｏｒｔ  ＴＴＩの配置例である。図３３に示した例でも、レベル１のＳｈｏｒｔ  ＴＴＩを、ＯＦＤＭシンボルごとに間引いて、間欠的に配置することで実現している。
【０１３８】
図３４は、Ｓｈｏｒｔ  ＴＴＩの配置例を示す説明図である。図３４に示したのは、ＰＤＣＣＨの長さが１ＯＦＤＭシンボル、すなわちＰＤＳＣＨの長さが１３ＯＦＤＭシンボルの場合におけるＳｈｏｒｔ  ＴＴＩの配置例である。図３４に示した例でも、レベル１のＳｈｏｒｔ  ＴＴＩを、ＯＦＤＭシンボルごとに間引いて、間欠的に配置することで実現している。
【０１３９】
このようにＳｈｏｒｔ  ＴＴＩのレベルを、例えば図２１を用いて説明したようにＯＦＤＭシンボルごとに間引いて、間欠的に配置することで実現する場合であっても、図３１に示した動作例と同様に、基地局１００から予めＳｈｏｒｔ  ＴＴＩの配置パターン及びＰＣＦＩＣＨによるＰＤＣＣＨの長さの情報を端末装置２００に通知する。端末装置２００は、Ｓｈｏｒｔ  ＴＴＩのレベルをＯＦＤＭシンボルごとに間引くことで実現する場合であっても、ＰＤＣＣＨの長さの情報を知ることにより、Ｓｈｏｒｔ  ＴＴＩがどの配置パターンとなるかを知ることが出来る。そして端末装置２００は、Ｓｈｏｒｔ  ＴＴＩの配置パターンを予め知ることで、Ｓｈｏｒｔ  ＴＴＩのデータの適切なデコード処理を実行することができる。
【０１４０】
（１．４．３．第３の動作例）
続いて、本開示の実施形態に係る基地局１００及び端末装置２００の第３の動作例を説明する。上述したように、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な処理を可能にするための技術が必要になる。第３の動作例では、第１の動作例とは別の観点から、短送信時間間隔でのデータの送受信に対応した端末装置が効率的な処理を可能にするための動作例を説明する。
【０１４１】
Ｓｈｏｒｔ  ＴＴＩは、基地局１００や基地局１００の奥のネットワークから端末装置２００に搭載されるアプリケーションを低遅延で制御するような用途が想定されている。従って、データがＳ−ＧＷや基地局１００にキャッシュされていて、そのキャッシュ（バッファリング）されていたものを提供する方法とは異なり、Ｓｈｏｒｔ  ＴＴＩでは、ネットワークの奥のＰ−ＧＷに繋がるインターネット等から、少量の制御データが必要となる時間にその都度到来してくる。その少量の制御データが、いつ基地局１００から端末装置２００に送信できるかは、その少量の制御データが基地局１００に到来してみないと基地局１００はわからないという状況である。端末装置２００に搭載されるアプリケーションとしては、ドローンを制御するアプリケーションソフトや、車を制御するアプリケーションソフト等がありうる。このように、Ｓｈｏｒｔ  ＴＴＩでは、少量のデータであるが、低遅延でデータを基地局１００から端末装置２００に届ける必要があるというユースケースが想定されうる。第３の実施形態では、低遅延でデータを基地局１００から端末装置２００に届けるために必要なスケジューリング技術を説明する。ここで、スケジューリングとは、端末装置２００が使用すべきダウンリンクリソースの場所を基地局１００が端末装置２００に通知することを指す。
【０１４２】
ドローンを制御するアプリケーションソフトや、車を制御するアプリケーションソフト以外のユースケースとしては、例えばゲームの同期が挙げられる。ネットワークゲームには、複数のユーザが、ネットワークを介して、地図上の位置を同期する必要があるゲームが多く見受けられる。図３５は、ネットワークゲームを実行する各ユーザの端末装置２００に表示される地図の例を示す説明図である。図３５には、２人のユーザの位置が表示される地図の例が示されている。図３５に示したように、複数のユーザが共通の町の地図の中で、お互いを攻撃するようなゲームは、それぞれのユーザの地図上での位置が同期している必要がある。同期していないと、あるユーザの端末装置では目の前に相手がいると思ってそのユーザが相手を攻撃しても、実際にはその相手は離れたところに移動している場合があるからである。このような地図上でのユーザの位置の同期が必要となるアプリケーションは、低遅延で、お互いの位置が同期して更新される必要がある。
【０１４３】
まず、既存のＬＴＥのダウンリンクのスケジューリングについて説明する。１つのリソースブロックは１２個のサブキャリアで構成されている。サブキャリアの間隔は１５ｋＨｚである。従ってリソースブロックの周波数方向の幅は１８０ｋＨｚである。２０ＭＨｚのバンド幅の場合、その２０ＭＨｚの中に１００個のリソースブロックを配置することができる。ただし、その１００個のリソースブロックをそのまま扱うと、スケジューリングに必要なビット数が１００ビットとなってしまう。そこで、４リソースブロックを１つのグループにまとめたリソースブロックグループ（ＲＢＧ）という概念を導入している。４リソースブロックを１つのＲＢＧとして、ＲＢＧ単位でスケジューリングすると、スケジューリングに必要なビット数を２５ビットまで少なくできる。すなわち、ｅＮｏｄｅＢは、２５ＲＢＧの内、あるＵＥがどのＲＢＧを使うかを、２５ビットのビットマップで構成されるスケジューリング情報をＵＥに通知している。１サブフレーム内に１スロット目のＲＢＧと２スロット目のＲＢＧがあるが、通常は、両方とも同じスケジューリングが行われる。図３６は、１つのサブフレームに１スロット目のＲＢＧと２スロット目のＲＢＧがあることを示す説明図である。＃０のサブフレームのＰＤＣＣＨの中にあるＤＣＩの中に、２５ビットのスケジューリング情報が含まれる。２５ビットのスケジューリング情報がが、＃０のサブフレームの中のＲＢＧを指定している。スケジューリング情報は、１つのＵＥのためのものであり、２５ビット全てが１の場合には、＃０のサブフレームの全てのリソースブロックを１台のＵＥが使用することになる。他にも、例えば、“０００１００００００００００１００００００００００”とスケジューリング情報をｅＮｏｄｅＢが指定することで、離れた周波数のリソースを１台のＵＥが使用することも可能である。
【０１４４】
Ｓｈｏｒｔ  ＴＴＩのリソースブロック（Ｓｈｏｒｔ  ＰＲＢ：Ｓｈｏｒｔ  ＰＨＹ  ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）が導入されると、時間方向の分解能が細かくなる。従来のスケジューリング方法には時間方向の分解能が無かった。従来は、上述したように周波数方向にリソースブロックをグループ化して、ＲＢＧとしてスケジューリング情報のビットマップを圧縮することはできたが、Ｓｈｏｒｔ  ＴＴＩのように時間方向の分解能が細かくなった場合には対応できない。
【０１４５】
もし、時間方向の１４ＯＦＤＭシンボルの内、先頭の３ＯＦＤＭシンボルがＰＤＣＣＨで使用された場合には、Ｓｈｏｒｔ  ＴＴＩを１ＯＦＤＭシンボルにした場合には、Ｓｈｏｒｔ  ＴＴＩは、サブフレーム内に時間方向に１１個配置することができる。周波数方向に２５ビットで２５個のＲＢＧに対してリソースを指定して、かつ時間方向に１１ビットでリソースを指定したとすると、Ｓｈｏｒｔ  ＴＴＩの最小リソースは、２５×１１＝２７５ビット、すなわち、従来の２５ビットの１１倍のビットが必要になってしまう。１台のＵＥのＳｈｏｒｔ  ＴＴＩのリソースを指定するために、通常のＴＴＩに２５ビット、Ｓｈｏｒｔ  ＴＴＩの２７５ビットの、合計３００ｂｉｔをＰＤＣＣＨの中のＤＣＩに含ませることは、ＰＤＣＣＨの領域が限られているために不可能である。
【０１４６】
そこで、時間方向のレゾルーションを無視することでＳｈｏｒｔ  ＴＴＩのスケジューリングを行う方法を説明する。基地局１００は、周波数方向のスケジューリングについては、従来と同じようにビットマップを使ってＲＢＧを指定する。１ＯＦＤＭシンボルをＴＴＩとするレベル１のＳｈｏｒｔ  ＴＴＩの場合には、ＰＤＣＣＨが３ＯＦＤＭシンボルを占めたとすると、ＰＤＳＣＨは１１ＯＦＤＭシンボルなので、最大１１個のＳｈｏｒｔ  ＴＴＩが１サブフレーム内に配置される。ここで、１サブフレーム内に配置される１１個のＳｈｏｒｔ  ＴＴＩは、全て同じ端末装置２００に割り当てるとする。図３７は、Ｓｈｏｒｔ  ＴＴＩの端末装置２００への割り当て例を示す説明図であり、１サブフレーム内に配置される１１個のＳｈｏｒｔ  ＴＴＩを全て同じ端末装置２００に割り当てる様子を示す説明図である。時間方向のレゾルーションを無視する方法を用いることにより、Ｓｈｏｒｔ  ＴＴＩを導入する際のスケジューリング情報の増加を最小限にすることができる。
【０１４７】
Ｓｈｏｒｔ  ＴＴＩ用に追加するスケジューリング情報は、そのスケジューリング情報のビットマップがＳｈｏｒｔ  ＴＴＩ用なのかどうかを区別する必要がある。従って、従来のＴＴＩ用のビットマップに加えて、新たにＳｈｏｒｔ  ＴＴＩ用のビットマップを用意する必要がある。
【０１４８】
バンド幅が２０ＭＨｚで、ＲＢＧが２５個ある場合には、通常のＴＴＩ用のスケジューリング情報のビットマップは２５ビットであり、Ｓｈｏｒｔ  ＴＴＩ用のスケジューリング情報のビットマップも２５ビットである。すなわち、通常のＴＴＩ用とＳｈｏｒｔ  ＴＴＩ用とで合わせて５０ビットのビットマップを用意する。図３８は、１台の端末装置２００に通常のＴＴＩとＳｈｏｒｔ  ＴＴＩとをスケジューリングした様子を示す説明図である。また表１は、図３８のようにスケジューリングする場合の、通常のＴＴＩ用とＳｈｏｒｔ  ＴＴＩ用とのスケジューリング情報のビットマップの例を示す説明図である。このビットマップでは、０は通常のＴＴＩまたはＳｈｏｒｔ  ＴＴＩで使用しないＲＢＧであり、１は通常のＴＴＩまたはＳｈｏｒｔ  ＴＴＩで使用するＲＢＧであることを意味する。
【０１４９】
【表１】
0006642057.tif 000002
【０１５０】
このように、Ｓｈｏｒｔ  ＴＴＩのリソースブロックを導入すると時間方向に１１ビットでリソースを指定すると、スケジューリング情報が合計で３００ビット必要であったところ、時間方向のレゾルーションを無視することで時間方向のレゾルーションを無視することでスケジューリング情報を合計で５０ビットまで減らすことができた。
【０１５１】
図３９は、本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。図３９に示したのは、基地局１００がＳｈｏｒｔ  ＴＴＩ用のスケジューリング情報を通知する際の基地局１００及び端末装置２００の動作例である。以下、図３９を用いて本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を説明する。
【０１５２】
基地局１００は、端末装置２００に向けて、２５個のＲＢＧの内、Ｓｈｏｒｔ  ＴＴＩ用のＲＢＧであることをビットマップで準静的に通知する（ステップＳ３０１）。ステップＳ３０１の処理は、例えば通知部１５３が実行する。基地局１００は、ビットマップで準静的に通知する際には、システム情報やdedicated signalingを用いる。
【０１５３】
続いて基地局１００は、ＰＤＣＣＨでＲＢＧのスケジューリングを行う（ステップＳ３０２）。ステップＳ３０２の処理は、例えば通知部１５３が実行する。
【０１５４】
端末装置２００は、スケジューリングされたＲＢＧがＳｈｏｒｔ  ＴＴＩなのか、通常のＴＴＩなのかを知った上で、基地局１００から送信されたデータをデコードする（ステップＳ３０３）。ステップＳ３０３の処理は、例えば受信処理部２４３が実行する。
【０１５５】
続いて、Ｓｈｏｒｔ  ＴＴＩのスケジューリング情報をさらに減少させる方法を説明する。例えば、基地局１００は、１つのサブフレームにおける２５個のＲＢＧのうち、どれがＳｈｏｒｔ  ＴＴＩであるかを、事前にＲＲＣシグナリングを用いて端末装置２００ごとに通知してもよい。また例えば、基地局１００は、端末装置２００ごとではなく、そのＲＢＧは常にＳｈｏｒｔ  ＴＴＩであることを端末装置２００へのブロードキャストを用いたシステム情報の中で指定してもよい。このように、事前にＳｈｏｒｔ  ＴＴＩであるＲＢＧが指定されていれば、Ｓｈｏｒｔ  ＴＴＩであることを指し示すための追加の２５ビットのスケジューリング情報は必要無くなり、制御ビットによるオーバーヘッドを減らすことが可能になる。
【０１５６】
上述した方法では、ＲＢＧ単位でのスケジューリング、すなわち、周波数方向のスケジューリングは動的に、つまりサブフレーム単位で行うことが出来る。一方で、１つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩレベルでのスケジューリングは行っていない。従って、ＰＤＣＣＨが３ＯＦＤＭシンボルを占めたとすると、ＰＤＳＣＨは１１ＯＦＤＭシンボルなので、１１ＯＦＤＭシンボルを全て、同じ端末装置２００が使用する場合に向いた方法であると言える。
【０１５７】
その一方で、例えば、１１ＯＦＤＭシンボルのうち、先頭のＯＦＤＭシンボルにのみデータが存在し、残りのＯＦＤＭシンボルにはデータが存在しない（ヌルデータが入っている）としても、端末装置２００は全てのＯＦＤＭシンボルについてＳｈｏｒｔ  ＴＴＩのデコードを試みることになる。
【０１５８】
Ｓｈｏｒｔ  ＴＴＩが１つのサブフレーム内で時間方向に１１個ある場合に、最初の２個のＳｈｏｒｔ  ＴＴＩにその端末装置２００のためのデータが入っていて、残りの９個が空の場合に、端末装置２００が１１個全てのＳｈｏｒｔ  ＴＴＩのデータをデコードすることは無駄であり、端末装置２００の電力消費量が無駄に増加する。
【０１５９】
そこで、基地局１００は、例えば、あるＯＦＤＭシンボルより後はＳｈｏｒｔ  ＴＴＩのデータをデコードする必要がないことが確定している場合には、そのＯＦＤＭシンボルのＳｈｏｒｔ  ＴＴＩのデータの中に、このサブフレームではこのデータで終了であることを示す情報を入れておく。図４０は、１１ＯＦＤＭシンボルのうち、先頭の２つのＯＦＤＭシンボルにのみＳｈｏｒｔ  ＴＴＩのデータが入っていることを示す説明図である。基地局１００は、２つ目のＯＦＤＭシンボルのＳｈｏｒｔ  ＴＴＩのデータの中に、このサブフレームではこのデータで終了であることを示す情報を入れておく。このようにすることにより、端末装置２００は、先頭の２個のＳｈｏｒｔ  ＴＴＩのデータだけをデコードすれば良く、電力消費を、Ｓｈｏｒｔ  ＴＴＩのデータのデコードに必要な分の消費にとどめることができる。
【０１６０】
図４０に示したように、１１ＯＦＤＭシンボルのうち、先頭の２つのＯＦＤＭシンボルにのみＳｈｏｒｔ  ＴＴＩのデータが入っている場合に、残りの９つのＯＦＤＭシンボルを有効に活用するための方法を説明する。
【０１６１】
図４１は、３台の端末装置２００がそれぞれＳｈｏｒｔ  ＴＴＩのデータをデコードする場合の例を示す説明図である。図４１は、ＵＥ  Ａとして示した端末装置２００が１番目と２番目のＯＦＤＭシンボルにおけるＳｈｏｒｔ  ＴＴＩのデータを、ＵＥ  Ｂとして示した端末装置２００が３番目から７番目のＯＦＤＭシンボルにおけるＳｈｏｒｔ  ＴＴＩのデータを、ＵＥ  Ｂとして示した端末装置２００が８番目から１１番目のＯＦＤＭシンボルにおけるＳｈｏｒｔ  ＴＴＩのデータを、それぞれデコードする場合の例が示されている。
【０１６２】
このように、１つのサブフレームで複数の端末装置２００がそれぞれＳｈｏｒｔ  ＴＴＩのデータをデコードする場合、基地局１００は、それぞれの端末装置２００に対して開始位置を指定するデータを含めて送信しても良い。ＵＥ  Ａは、自身宛のデータが１番目のＯＦＤＭシンボルから始まることを、基地局１００からの送信データにより知ることが出来る。一方、ＵＥ  ＢとＵＥ  Ｃは、１番目のＯＦＤＭシンボルのデータは自身宛のデータでは無いことを、基地局１００からの送信データにより知ることが出来るので、デコードを行わないようにすることが出来る。
【０１６３】
同様に、ＵＥ  Ｂは、自身宛のデータが３番目のＯＦＤＭシンボルから始まることを、基地局１００からの送信データにより知ることが出来、ＵＥ  Ｃは、自身宛のデータが８番目のＯＦＤＭシンボルから始まることを、基地局１００からの送信データにより知ることが出来る。基地局１００は、終了位置の情報を、図４０を用いて説明した方法と同様に、それぞれの端末装置２００に向けたものとして通知する。
【０１６４】
図４１に示した例では、３台の端末装置２００のリソースが重なることなく、一つのＲＢＧの中で多重されている。図４１に示したように３台の端末装置２００に向けてデータを送信することで、リソースの無駄は完全に無くなっている。そして、１台の端末装置２００には開始位置と終了位置との間の連続したリソースのみ割り当てることになっている。
【０１６５】
ＰＤＣＣＨの中のＤＣＩで必要となるスケジューリング情報は、通常のＴＴＩのＲＢＧを指定するスケジューリングに必要な２５ビットに加え、Ｓｈｏｒｔ  ＴＴＩのＲＢＧのスケジューリングに２５ビット、時間方向の１１個のＳｈｏｒｔ  ＴＴＩの先頭位置を示すために４ビットが必要になるため、２５個のＲＢＧ全体では２５×４＝１００ビットが必要になる。従って、スケジューリング情報は合計で２５ビット＋２５ビット＋１００ビット＝１５０ビットとなる。
【０１６６】
このスケジューリング情報を圧縮する方法を説明する。基地局１００は、先頭位置と終了位置をＲＢＧ毎に指定することにより、リソースの無駄を無くすとともに、端末装置２００での無駄なデコードも減らすことができた。しかし、そのためにＤＣＩに１００ビットのスケジューリング情報を追加することになる。スケジューリング情報の増加は、スケジューリング情報に起因するオーバーヘッドの増加にも繋がるため、スケジューリング情報は少ない方が好ましい。
【０１６７】
例えば、仕様によって、１台の端末装置２００で１つのサブフレームあたり、許可するＳｈｏｒｔ  ＴＴＩを最大で３つに制限する。この制限は、可変でも良いし、システムとして固定でも良い。このようにＳｈｏｒｔ  ＴＴＩの数を制限することにより、Ｓｈｏｒｔ  ＴＴＩ用のスケジューリング情報の２５ビットの中に、０ではなく１となるのは最大で３つだけであると、端末装置２００は仮定することができる。そして、その３つに対応するＲＢＧの１１個のＳｈｏｒｔ  ＴＴＩを指定するために、４ビット×３＝１２ビットを追加すれば良いので、スケジューリング情報は合計で２５ビット＋２５ビット＋１２ビット＝６２ビットとなる。この６２ビットのスケジューリング情報が、ＤＣＩの中の１台の端末装置２００に宛てたスケジューリングの割り当てのために必要となる。これにより、上述の１５０ビットから大幅にビット数を減らすことが出来るので、端末装置２００でのオーバーヘッドの削減に寄与する効果が期待できる。
【０１６８】
Ｓｈｏｒｔ  ＴＴＩのデータは少量であり、間欠的に端末装置２００が受信するものである。それにも関わらず、上で述べたように、１サブフレーム内にＳｈｏｒｔ  ＴＴＩのリソースを１台の端末装置２００のために全て割り当ててしまうとリソースの無駄が大きくなる。従って、１サブフレーム内での異なるＳｈｏｒｔ  ＴＴＩは異なる端末装置２００に使用させることが望ましい。
【０１６９】
そこで、基地局１００が上述のように１１個のＳｈｏｒｔ  ＴＴＩがあるＲＢＧを指定した後に、端末装置２００は、その１１個のＳｈｏｒｔ  ＴＴＩの中で、どれが自分宛か分からない状態で、その１１個のＳｈｏｒｔ  ＴＴＩ全てをデコードする。図４２は、端末装置２００が１１個のＳｈｏｒｔ  ＴＴＩ全てをデコードすることを説明する説明図である。このようなデコード方法は、ブラインドデコーディング（Ｂｌｉｎｄ  Ｄｅｃｏｄｉｎｇ）と呼ばれている。通常はＵＥがＰＤＣＣＨのＤＣＩをデコードする時にブラインドデコーディングを行っている。本動作例では、端末装置２００がＳｈｏｒｔ  ＴＴＩをデコードする場合にも、このブラインドデコーディングを適用する。
【０１７０】
図４３は、Ｓｈｏｒｔ  ＴＴＩの宛先と、ある端末装置２００でのＣＲＣチェックの結果の例を示す説明図である。図４３に示した例では、ある端末装置２００は、１１個のＳｈｏｒｔ  ＴＴＩの内、自分宛のＳｈｏｒｔ  ＴＴＩのデータが４つあるので、そのデータについてはＣＲＣチェックの結果がＯＫとなり、他のＵＥ宛のＳｈｏｒｔ  ＴＴＩのデータが７つあるので、そのデータについてはＣＲＣチェックの結果がＮＧとなる。
【０１７１】
図４３に示したように、１つのサブフレームにおけるＳｈｏｒｔ  ＴＴＩのデータの中には、自分宛のデータと、他のＵＥ宛てのデータと混在しうる（もちろん、自分宛のデータが全く存在しない可能性もありうる）。基地局１００は、端末装置２００に固有のＩＤ（Ｃ−ＲＮＴＩ等）でデータをＣＲＣする。従って、端末装置２００は、自分宛のデータをデコードした時以外は、ＣＲＣの結果がＯＫにならない。端末装置２００は、他のユーザ（他の端末装置２００）のためのデータもデコードするので、ＣＲＣがエラーになる部分とエラーにならない部分がある。しかし端末装置２００は、ＣＲＣがエラーになったからと言って、データ失敗のＮＡＣＫを基地局１００に返信しない。なぜなら、そのデータは他のユーザ（他の端末装置２００）のデータであったかもしれないからである。端末装置２００は、ＣＲＣがエラーになった場合、ＮＡＣＫの返し方を以下の３つの方法の中からとりうる。
【０１７２】
（１）第１の方法
第１の方法は、ＮＡＣＫは一切返さない方法である。端末装置２００は、ＣＲＣがエラーになっても、ＮＡＣＫを一切返さない。この方法では、基地局１００は、端末装置２００が本当にデータを受信できたかどうかを知り得ない。
【０１７３】
（２）第２の方法
第２の方法は、指定されたＳｈｏｒｔ  ＴＴＩ領域の中のリソースで１つでもＣＲＣの結果がＯＫのものがあればＮＡＣＫを返さず、ＣＲＣの結果が全てＮＧの場合にＮＡＣＫを返す方法である。この方法は、端末装置２００は、Ｓｈｏｒｔ  ＴＴＩ毎にＡＣＫまたはＮＡＣＫを返すわけでは無い。しかしこの方法は、最初の方法に比べれば、基地局１００は、データを正しく送信できたかどうかを部分的にではあるが知ることが出来る。
【０１７４】
（３）第３の方法
第３の方法は、例えばＳｈｏｒｔ  ＴＴＩが１１個ある場合、その１１個のＳｈｏｒｔ  ＴＴＩのデータの内、自身宛のデータが何個あるかを基地局１００から取得して、指定された個数とＣＲＣチェックの結果がＯＫの個数が同じであればＡＣＫを、違っていればＮＡＣＫを返す方法である。端末装置２００が、１１個のＳｈｏｒｔ  ＴＴＩのデータの内、自身宛のデータが何個あるかを、予め基地局１００から取得できない場合にはこの方法は使えない。しかし、端末装置２００が、次のサブフレームにおけるＤＣＩフォーマットの中で、前のサブフレームに自身宛のデータが何個あるかを基地局１００から取得することが出来れば、端末装置２００は、その基地局１００から取得した個数の情報に基づいてＡＣＫまたはＮＡＣＫを返すことが出来る。
【０１７５】
また、基地局１００が、サブフレーム内で、ある端末装置２００に向けたデータはここで最後であるという情報、および、当該サブフレームでその端末装置２００宛に送信したデータの個数の情報を入れておくことで、端末装置２００は、そのサブフレームには自身宛のデータがいくつあったかを知ることが出来る。図４４は、基地局１００が、端末装置２００に向けて送信する情報について示す説明図である。図４４は、基地局１００が、サブフレーム内で、ある端末装置２００に向けたデータはここで最後であるという情報、および、当該サブフレームでその端末装置２００宛に送信したデータの個数の情報を入れている例を示す説明図である。図４４に示した例では、ある端末装置２００に向けたデータは、先頭から９番目のＳｈｏｒｔ  ＴＴＩのデータで最後である旨の情報を、基地局１００がその頭から９番目のＳｈｏｒｔ  ＴＴＩのデータに入れる。この際、基地局１００は、その端末装置２００には３個のＳｈｏｒｔ  ＴＴＩのデータを送信したことをそのＳｈｏｒｔ  ＴＴＩのデータに入れる。端末装置２００は、これらの情報を確認することで、このサブフレームには自身宛のデータが３つあったことを知ることが出来る。従って端末装置２００は、そのサブフレームでＣＲＣチェックの結果がＯＫの個数が３つであればＡＣＫを、３つ以外であればＮＡＣＫを、それぞれ基地局１００に返信する。
【０１７６】
図４５は、本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を示す流れ図である。図４５に示したのは、上述した第３の方法に対応する基地局１００及び端末装置２００の動作例である。以下、図４５を用いて本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を説明する。
【０１７７】
基地局１００は、各サブフレームのＰＤＣＣＨにおいて、Ｓｈｏｒｔ  ＴＴＩのデータが入っているリソースを指定する（ステップＳ３１１）。ステップＳ３１１の処理は、例えば通知部１５３が実行する。
【０１７８】
続いて基地局１００は、Ｓｈｏｒｔ  ＴＴＩでそれぞれの端末装置２００宛のデータを送信する。そして、各サブフレームにおいて、ある端末装置２００に向けた最後のＳｈｏｒｔ  ＴＴＩのデータの中に、そのサブフレームでのＳｈｏｒｔ  ＴＴＩのデータはここで最後であるという情報、および、当該サブフレームでその端末装置２００宛に送信したデータの個数の情報を通知する（ステップＳ３１２）。ステップＳ３１２の処理は、例えば通知部１５３が実行する。
【０１７９】
端末装置２００は、スケジューリングされたＲＢＧが、Ｓｈｏｒｔ  ＴＴＩなのか通常のＴＴＩなのかを知った上でデータのデコードを行う。そして端末装置２００は、スケジューリングされたＲＢＧがＳｈｏｒｔ  ＴＴＩであればＳｈｏｒｔ  ＴＴＩのデータを先頭から順番にデコードする（ステップＳ３１３）。ステップＳ３１３の処理は、例えば受信処理部２４３が実行する。
【０１８０】
そして、端末装置２００は、上記ステップＳ３１２で基地局１００から送信された情報に基づき、基地局１００に向けてＡＣＫまたはＮＡＣＫを返信する（ステップＳ３１４）。ステップＳ３１４の処理は、例えば通知部２４５が実行する。端末装置２００は、上記ステップＳ３１２で基地局１００から送信された情報に基づき、サブフレーム内に存在した自身宛のＳｈｏｒｔ  ＴＴＩのデータの個数と、ＣＲＣチェックの結果がＯＫの個数が等しければＡＣＫを、異なっていればＮＡＣＫを、それぞれ基地局１００に返信する。
【０１８１】
この第３の方法は、基地局１００は、周波数方向にも時間方向にも、連続的にも飛び飛びにもリソースを指定出来ることから、スケジューリングの自由度は非常に高い。また、ＨＡＲＱのＡＣＫ／ＮＡＣＫの返信を考慮しなければ、スケジューリングの割り当てに必要なビット数も少なく済む。
【０１８２】
また、上述の第２の方法や第３の方法のように、想定する有効なデータの数と、受信に成功したデータの数とを比較する方法の場合、基地局１００が、有効なデータの数を指定するためには１つのＲＢＧあたり４ビット必要になる。２５個のＲＢＧをＳｈｏｒｔ  ＴＴＩが占有する場合を想定すると、基地局１００が、有効なデータの数を指定するためには１００ビットもの情報が必要になる。しかし、上述したように、１つのサブフレームあたり、Ｓｈｏｒｔ  ＴＴＩで使用できるＲＢＧの数を制限することで有効なデータの数を指定するためのビット数を小さくすることが出来る。例えば、１つのサブフレームあたり、Ｓｈｏｒｔ  ＴＴＩで使用できるＲＢＧの数を３個に制限することで有効なデータの数を指定するためのビット数を１２ビットに抑えることが出来る。
【０１８３】
上述したように、従来のＬＴＥでは、ｅＮｏｄｅＢは、バンド幅が２０ＭＨｚの場合、スケジューリング情報に２５ビットが割り当てられていた。従って、周波数的に離れたリソースを、１台のＵＥに割り当てることが可能であった。上述した３つのＡＣＫまたはＮＡＣＫの返信方法においても、同様に、基地局１００は周波数方向に配置された２５個のリソースを自由にそれぞれの端末装置２００に割り当てることができる。
【０１８４】
（１．４．４．動作例のまとめ）
以上、本開示の実施の形態に係る基地局１００及び端末装置２００の動作例を３つ挙げた。なお、本開示の実施の形態に係る基地局１００及び端末装置２００は、上述した３つの動作例を独立して動作するものではなく、複数の動作例を組み合わせて動作しても良い。また、本開示の実施の形態に係る基地局１００及び端末装置２００は、複数の動作例を組み合わせる際に、各動作例で説明した動作の一部のみを組み合わせてもよい。
【０１８５】
例えば、本開示の実施の形態に係る基地局１００及び端末装置２００は、第１の動作例で示したＳｈｏｒｔ  ＴＴＩでのデータの送受信で使用するリソースを通知する動作と、様々なレベルのＳｈｏｒｔ  ＴＴＩを用意した際の動作とを組み合わせてもよい。
【０１８６】
＜２．応用例＞
本開示に係る技術は、様々な製品へ応用可能である。例えば、基地局１００は、マクロｅＮＢ又はスモールｅＮＢなどのいずれかの種類のｅＮＢ（evolved  Node  B）として実現されてもよい。スモールｅＮＢは、ピコｅＮＢ、マイクロｅＮＢ又はホーム（フェムト）ｅＮＢなどの、マクロセルよりも小さいセルをカバーするｅＮＢであってよい。その代わりに、基地局１００は、ＮｏｄｅＢ又はＢＴＳ（Base  Transceiver  Station）などの他の種類の基地局として実現されてもよい。基地局１００は、無線通信を制御する本体（基地局装置ともいう）と、本体とは別の場所に配置される１つ以上のＲＲＨ（Remote  Radio  Head）とを含んでもよい。また、後述する様々な種類の端末が一時的に又は半永続的に基地局機能を実行することにより、基地局１００として動作してもよい。
【０１８７】
また、例えば、端末装置２００は、スマートフォン、タブレットＰＣ（Personal  Computer）、ノートＰＣ、携帯型ゲーム端末、携帯型／ドングル型のモバイルルータ若しくはデジタルカメラなどのモバイル端末、又はカーナビゲーション装置などの車載端末として実現されてもよい。また、端末装置２００は、Ｍ２Ｍ（Machine  To  Machine）通信を行う端末（ＭＴＣ（Machine  Type  Communication）端末ともいう）として実現されてもよい。さらに、端末装置２００は、これら端末に搭載される無線通信モジュール（例えば、１つのダイで構成される集積回路モジュール）であってもよい。
【０１８８】
＜２．１．基地局に関する応用例＞
（第１の応用例）
図４６は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第１の例を示すブロック図である。ｅＮＢ８００は、１つ以上のアンテナ８１０、及び基地局装置８２０を有する。各アンテナ８１０及び基地局装置８２０は、ＲＦケーブルを介して互いに接続され得る。
【０１８９】
アンテナ８１０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、基地局装置８２０による無線信号の送受信のために使用される。ｅＮＢ８００は、図４６に示したように複数のアンテナ８１０を有し、複数のアンテナ８１０は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図４６にはｅＮＢ８００が複数のアンテナ８１０を有する例を示したが、ｅＮＢ８００は単一のアンテナ８１０を有してもよい。
【０１９０】
基地局装置８２０は、コントローラ８２１、メモリ８２２、ネットワークインタフェース８２３及び無線通信インタフェース８２５を備える。
【０１９１】
コントローラ８２１は、例えばＣＰＵ又はＤＳＰであってよく、基地局装置８２０の上位レイヤの様々な機能を動作させる。例えば、コントローラ８２１は、無線通信インタフェース８２５により処理された信号内のデータからデータパケットを生成し、生成したパケットをネットワークインタフェース８２３を介して転送する。コントローラ８２１は、複数のベースバンドプロセッサからのデータをバンドリングすることによりバンドルドパケットを生成し、生成したバンドルドパケットを転送してもよい。また、コントローラ８２１は、無線リソース管理（Radio  Resource  Control）、無線ベアラ制御（Radio  Bearer  Control）、移動性管理（Mobility  Management）、流入制御（Admission  Control）又はスケジューリング（Scheduling）などの制御を実行する論理的な機能を有してもよい。また、当該制御は、周辺のｅＮＢ又はコアネットワークノードと連携して実行されてもよい。メモリ８２２は、ＲＡＭ及びＲＯＭを含み、コントローラ８２１により実行されるプログラム、及び様々な制御データ（例えば、端末リスト、送信電力データ及びスケジューリングデータなど）を記憶する。
【０１９２】
ネットワークインタフェース８２３は、基地局装置８２０をコアネットワーク８２４に接続するための通信インタフェースである。コントローラ８２１は、ネットワークインタフェース８２３を介して、コアネットワークノード又は他のｅＮＢと通信してもよい。その場合に、ｅＮＢ８００と、コアネットワークノード又は他のｅＮＢとは、論理的なインタフェース（例えば、Ｓ１インタフェース又はＸ２インタフェース）により互いに接続されてもよい。ネットワークインタフェース８２３は、有線通信インタフェースであってもよく、又は無線バックホールのための無線通信インタフェースであってもよい。ネットワークインタフェース８２３が無線通信インタフェースである場合、ネットワークインタフェース８２３は、無線通信インタフェース８２５により使用される周波数帯域よりもより高い周波数帯域を無線通信に使用してもよい。
【０１９３】
無線通信インタフェース８２５は、ＬＴＥ（Long  Term  Evolution）又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、アンテナ８１０を介して、ｅＮＢ８００のセル内に位置する端末に無線接続を提供する。無線通信インタフェース８２５は、典型的には、ベースバンド（ＢＢ）プロセッサ８２６及びＲＦ回路８２７などを含み得る。ＢＢプロセッサ８２６は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、各レイヤ（例えば、Ｌ１、ＭＡＣ（Medium  Access  Control）、ＲＬＣ（Radio  Link  Control）及びＰＤＣＰ（Packet  Data  Convergence  Protocol））の様々な信号処理を実行する。ＢＢプロセッサ８２６は、コントローラ８２１の代わりに、上述した論理的な機能の一部又は全部を有してもよい。ＢＢプロセッサ８２６は、通信制御プログラムを記憶するメモリ、当該プログラムを実行するプロセッサ及び関連する回路を含むモジュールであってもよく、ＢＢプロセッサ８２６の機能は、上記プログラムのアップデートにより変更可能であってもよい。また、上記モジュールは、基地局装置８２０のスロットに挿入されるカード若しくはブレードであってもよく、又は上記カード若しくは上記ブレードに搭載されるチップであってもよい。一方、ＲＦ回路８２７は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８１０を介して無線信号を送受信する。
【０１９４】
無線通信インタフェース８２５は、図４６に示したように複数のＢＢプロセッサ８２６を含み、複数のＢＢプロセッサ８２６は、例えばｅＮＢ８００が使用する複数の周波数帯域にそれぞれ対応してもよい。また、無線通信インタフェース８２５は、図４６に示したように複数のＲＦ回路８２７を含み、複数のＲＦ回路８２７は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図４６には無線通信インタフェース８２５が複数のＢＢプロセッサ８２６及び複数のＲＦ回路８２７を含む例を示したが、無線通信インタフェース８２５は単一のＢＢプロセッサ８２６又は単一のＲＦ回路８２７を含んでもよい。
【０１９５】
図４６に示したｅＮＢ８００において、図５を参照して説明した処理部１５０に含まれる１つ以上の構成要素（送信処理部１５１及び／又は通知部１５３）は、無線通信インタフェース８２５において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、コントローラ８２１において実装されてもよい。一例として、ｅＮＢ８００は、無線通信インタフェース８２５の一部（例えば、ＢＢプロセッサ８２６）若しくは全部、及び／又はコントローラ８２１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがｅＮＢ８００にインストールされ、無線通信インタフェース８２５（例えば、ＢＢプロセッサ８２６）及び／又はコントローラ８２１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてｅＮＢ８００、基地局装置８２０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
【０１９６】
また、図４６に示したｅＮＢ８００において、図５を参照して説明した無線通信部１２０は、無線通信インタフェース８２５（例えば、ＲＦ回路８２７）において実装されてもよい。また、アンテナ部１１０は、アンテナ８１０において実装されてもよい。また、ネットワーク通信部１３０は、コントローラ８２１及び／又はネットワークインタフェース８２３において実装されてもよい。また、記憶部１４０は、メモリ８２２において実装されてもよい。
【０１９７】
（第２の応用例）
図４７は、本開示に係る技術が適用され得るｅＮＢの概略的な構成の第２の例を示すブロック図である。ｅＮＢ８３０は、１つ以上のアンテナ８４０、基地局装置８５０、及びＲＲＨ８６０を有する。各アンテナ８４０及びＲＲＨ８６０は、ＲＦケーブルを介して互いに接続され得る。また、基地局装置８５０及びＲＲＨ８６０は、光ファイバケーブルなどの高速回線で互いに接続され得る。
【０１９８】
アンテナ８４０の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、ＲＲＨ８６０による無線信号の送受信のために使用される。ｅＮＢ８３０は、図４７に示したように複数のアンテナ８４０を有し、複数のアンテナ８４０は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図４７にはｅＮＢ８３０が複数のアンテナ８４０を有する例を示したが、ｅＮＢ８３０は単一のアンテナ８４０を有してもよい。
【０１９９】
基地局装置８５０は、コントローラ８５１、メモリ８５２、ネットワークインタフェース８５３、無線通信インタフェース８５５及び接続インタフェース８５７を備える。コントローラ８５１、メモリ８５２及びネットワークインタフェース８５３は、図４６を参照して説明したコントローラ８２１、メモリ８２２及びネットワークインタフェース８２３と同様のものである。
【０２００】
無線通信インタフェース８５５は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、ＲＲＨ８６０及びアンテナ８４０を介して、ＲＲＨ８６０に対応するセクタ内に位置する端末に無線接続を提供する。無線通信インタフェース８５５は、典型的には、ＢＢプロセッサ８５６などを含み得る。ＢＢプロセッサ８５６は、接続インタフェース８５７を介してＲＲＨ８６０のＲＦ回路８６４と接続されることを除き、図４６を参照して説明したＢＢプロセッサ８２６と同様のものである。無線通信インタフェース８５５は、図４７に示したように複数のＢＢプロセッサ８５６を含み、複数のＢＢプロセッサ８５６は、例えばｅＮＢ８３０が使用する複数の周波数帯域にそれぞれ対応してもよい。なお、図４７には無線通信インタフェース８５５が複数のＢＢプロセッサ８５６を含む例を示したが、無線通信インタフェース８５５は単一のＢＢプロセッサ８５６を含んでもよい。
【０２０１】
接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）をＲＲＨ８６０と接続するためのインタフェースである。接続インタフェース８５７は、基地局装置８５０（無線通信インタフェース８５５）とＲＲＨ８６０とを接続する上記高速回線での通信のための通信モジュールであってもよい。
【０２０２】
また、ＲＲＨ８６０は、接続インタフェース８６１及び無線通信インタフェース８６３を備える。
【０２０３】
接続インタフェース８６１は、ＲＲＨ８６０（無線通信インタフェース８６３）を基地局装置８５０と接続するためのインタフェースである。接続インタフェース８６１は、上記高速回線での通信のための通信モジュールであってもよい。
【０２０４】
無線通信インタフェース８６３は、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、典型的には、ＲＦ回路８６４などを含み得る。ＲＦ回路８６４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ８４０を介して無線信号を送受信する。無線通信インタフェース８６３は、図４７に示したように複数のＲＦ回路８６４を含み、複数のＲＦ回路８６４は、例えば複数のアンテナ素子にそれぞれ対応してもよい。なお、図４７には無線通信インタフェース８６３が複数のＲＦ回路８６４を含む例を示したが、無線通信インタフェース８６３は単一のＲＦ回路８６４を含んでもよい。
【０２０５】
図４７に示したｅＮＢ８３０において、図５を参照して説明した処理部１５０に含まれる１つ以上の構成要素（送信処理部１５１及び／又は通知部１５３）は、無線通信インタフェース８５５及び／又は無線通信インタフェース８６３において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、コントローラ８５１において実装されてもよい。一例として、ｅＮＢ８３０は、無線通信インタフェース８５５の一部（例えば、ＢＢプロセッサ８５６）若しくは全部、及び／又はコントローラ８５１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがｅＮＢ８３０にインストールされ、無線通信インタフェース８５５（例えば、ＢＢプロセッサ８５６）及び／又はコントローラ８５１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてｅＮＢ８３０、基地局装置８５０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
【０２０６】
また、図４７に示したｅＮＢ８３０において、例えば、図５を参照して説明した無線通信部１２０は、無線通信インタフェース８６３（例えば、ＲＦ回路８６４）において実装されてもよい。また、アンテナ部１１０は、アンテナ８４０において実装されてもよい。また、ネットワーク通信部１３０は、コントローラ８５１及び／又はネットワークインタフェース８５３において実装されてもよい。また、記憶部１４０は、メモリ８５２において実装されてもよい。
【０２０７】
＜２−２．端末装置に関する応用例＞
（第１の応用例）
図４８は、本開示に係る技術が適用され得るスマートフォン９００の概略的な構成の一例を示すブロック図である。スマートフォン９００は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２、１つ以上のアンテナスイッチ９１５、１つ以上のアンテナ９１６、バス９１７、バッテリー９１８及び補助コントローラ９１９を備える。
【０２０８】
プロセッサ９０１は、例えばＣＰＵ又はＳｏＣ（System  on  Chip）であってよく、スマートフォン９００のアプリケーションレイヤ及びその他のレイヤの機能を制御する。メモリ９０２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９０１により実行されるプログラム及びデータを記憶する。ストレージ９０３は、半導体メモリ又はハードディスクなどの記憶媒体を含み得る。外部接続インタフェース９０４は、メモリーカード又はＵＳＢ（Universal  Serial  Bus）デバイスなどの外付けデバイスをスマートフォン９００へ接続するためのインタフェースである。
【０２０９】
カメラ９０６は、例えば、ＣＣＤ（Charge  Coupled  Device）又はＣＭＯＳ（Complementary  Metal  Oxide  Semiconductor）などの撮像素子を有し、撮像画像を生成する。センサ９０７は、例えば、測位センサ、ジャイロセンサ、地磁気センサ及び加速度センサなどのセンサ群を含み得る。マイクロフォン９０８は、スマートフォン９００へ入力される音声を音声信号へ変換する。入力デバイス９０９は、例えば、表示デバイス９１０の画面上へのタッチを検出するタッチセンサ、キーパッド、キーボード、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９１０は、液晶ディスプレイ（ＬＣＤ）又は有機発光ダイオード（ＯＬＥＤ）ディスプレイなどの画面を有し、スマートフォン９００の出力画像を表示する。スピーカ９１１は、スマートフォン９００から出力される音声信号を音声に変換する。
【０２１０】
無線通信インタフェース９１２は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９１２は、典型的には、ＢＢプロセッサ９１３及びＲＦ回路９１４などを含み得る。ＢＢプロセッサ９１３は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９１４は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９１６を介して無線信号を送受信する。無線通信インタフェース９１２は、ＢＢプロセッサ９１３及びＲＦ回路９１４を集積したワンチップのモジュールであってもよい。無線通信インタフェース９１２は、図４８に示したように複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含んでもよい。なお、図４８には無線通信インタフェース９１２が複数のＢＢプロセッサ９１３及び複数のＲＦ回路９１４を含む例を示したが、無線通信インタフェース９１２は単一のＢＢプロセッサ９１３又は単一のＲＦ回路９１４を含んでもよい。
【０２１１】
さらに、無線通信インタフェース９１２は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ（Local  Area  Network）方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９１３及びＲＦ回路９１４を含んでもよい。
【０２１２】
アンテナスイッチ９１５の各々は、無線通信インタフェース９１２に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９１６の接続先を切り替える。
【０２１３】
アンテナ９１６の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９１２による無線信号の送受信のために使用される。スマートフォン９００は、図４８に示したように複数のアンテナ９１６を有してもよい。なお、図４８にはスマートフォン９００が複数のアンテナ９１６を有する例を示したが、スマートフォン９００は単一のアンテナ９１６を有してもよい。
【０２１４】
さらに、スマートフォン９００は、無線通信方式ごとにアンテナ９１６を備えてもよい。その場合に、アンテナスイッチ９１５は、スマートフォン９００の構成から省略されてもよい。
【０２１５】
バス９１７は、プロセッサ９０１、メモリ９０２、ストレージ９０３、外部接続インタフェース９０４、カメラ９０６、センサ９０７、マイクロフォン９０８、入力デバイス９０９、表示デバイス９１０、スピーカ９１１、無線通信インタフェース９１２及び補助コントローラ９１９を互いに接続する。バッテリー９１８は、図中に破線で部分的に示した給電ラインを介して、図４８に示したスマートフォン９００の各ブロックへ電力を供給する。補助コントローラ９１９は、例えば、スリープモードにおいて、スマートフォン９００の必要最低限の機能を動作させる。
【０２１６】
図４８に示したスマートフォン９００において、図６を参照して説明した処理部２４０に含まれる１つ以上の構成要素（取得部２４１及び／又は受信処理部２４３）は、無線通信インタフェース９１２において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ９０１又は補助コントローラ９１９において実装されてもよい。一例として、スマートフォン９００は、無線通信インタフェース９１２の一部（例えば、ＢＢプロセッサ９１３）若しくは全部、プロセッサ９０１、及び／又は補助コントローラ９１９を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがスマートフォン９００にインストールされ、無線通信インタフェース９１２（例えば、ＢＢプロセッサ９１３）、プロセッサ９０１、及び／又は補助コントローラ９１９が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてスマートフォン９００又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
【０２１７】
また、図４８に示したスマートフォン９００において、例えば、図６を参照して説明した無線通信部２２０は、無線通信インタフェース９１２（例えば、ＲＦ回路９１４）において実装されてもよい。また、アンテナ部２１０は、アンテナ９１６において実装されてもよい。また、記憶部２３０は、メモリ９０２において実装されてもよい。
【０２１８】
（第２の応用例）
図４９は、本開示に係る技術が適用され得るカーナビゲーション装置９２０の概略的な構成の一例を示すブロック図である。カーナビゲーション装置９２０は、プロセッサ９２１、メモリ９２２、ＧＰＳ（Global  Positioning  System）モジュール９２４、センサ９２５、データインタフェース９２６、コンテンツプレーヤ９２７、記憶媒体インタフェース９２８、入力デバイス９２９、表示デバイス９３０、スピーカ９３１、無線通信インタフェース９３３、１つ以上のアンテナスイッチ９３６、１つ以上のアンテナ９３７及びバッテリー９３８を備える。
【０２１９】
プロセッサ９２１は、例えばＣＰＵ又はＳｏＣであってよく、カーナビゲーション装置９２０のナビゲーション機能及びその他の機能を制御する。メモリ９２２は、ＲＡＭ及びＲＯＭを含み、プロセッサ９２１により実行されるプログラム及びデータを記憶する。
【０２２０】
ＧＰＳモジュール９２４は、ＧＰＳ衛星から受信されるＧＰＳ信号を用いて、カーナビゲーション装置９２０の位置（例えば、緯度、経度及び高度）を測定する。センサ９２５は、例えば、ジャイロセンサ、地磁気センサ及び気圧センサなどのセンサ群を含み得る。データインタフェース９２６は、例えば、図示しない端子を介して車載ネットワーク９４１に接続され、車速データなどの車両側で生成されるデータを取得する。
【０２２１】
コンテンツプレーヤ９２７は、記憶媒体インタフェース９２８に挿入される記憶媒体（例えば、ＣＤ又はＤＶＤ）に記憶されているコンテンツを再生する。入力デバイス９２９は、例えば、表示デバイス９３０の画面上へのタッチを検出するタッチセンサ、ボタン又はスイッチなどを含み、ユーザからの操作又は情報入力を受け付ける。表示デバイス９３０は、ＬＣＤ又はＯＬＥＤディスプレイなどの画面を有し、ナビゲーション機能又は再生されるコンテンツの画像を表示する。スピーカ９３１は、ナビゲーション機能又は再生されるコンテンツの音声を出力する。
【０２２２】
無線通信インタフェース９３３は、ＬＴＥ又はＬＴＥ−Ａｄｖａｎｃｅｄなどのいずれかのセルラー通信方式をサポートし、無線通信を実行する。無線通信インタフェース９３３は、典型的には、ＢＢプロセッサ９３４及びＲＦ回路９３５などを含み得る。ＢＢプロセッサ９３４は、例えば、符号化／復号、変調／復調及び多重化／逆多重化などを行なってよく、無線通信のための様々な信号処理を実行する。一方、ＲＦ回路９３５は、ミキサ、フィルタ及びアンプなどを含んでもよく、アンテナ９３７を介して無線信号を送受信する。無線通信インタフェース９３３は、ＢＢプロセッサ９３４及びＲＦ回路９３５を集積したワンチップのモジュールであってもよい。無線通信インタフェース９３３は、図４９に示したように複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含んでもよい。なお、図４９には無線通信インタフェース９３３が複数のＢＢプロセッサ９３４及び複数のＲＦ回路９３５を含む例を示したが、無線通信インタフェース９３３は単一のＢＢプロセッサ９３４又は単一のＲＦ回路９３５を含んでもよい。
【０２２３】
さらに、無線通信インタフェース９３３は、セルラー通信方式に加えて、近距離無線通信方式、近接無線通信方式又は無線ＬＡＮ方式などの他の種類の無線通信方式をサポートしてもよく、その場合に、無線通信方式ごとのＢＢプロセッサ９３４及びＲＦ回路９３５を含んでもよい。
【０２２４】
アンテナスイッチ９３６の各々は、無線通信インタフェース９３３に含まれる複数の回路（例えば、異なる無線通信方式のための回路）の間でアンテナ９３７の接続先を切り替える。
【０２２５】
アンテナ９３７の各々は、単一の又は複数のアンテナ素子（例えば、ＭＩＭＯアンテナを構成する複数のアンテナ素子）を有し、無線通信インタフェース９３３による無線信号の送受信のために使用される。カーナビゲーション装置９２０は、図４９に示したように複数のアンテナ９３７を有してもよい。なお、図４９にはカーナビゲーション装置９２０が複数のアンテナ９３７を有する例を示したが、カーナビゲーション装置９２０は単一のアンテナ９３７を有してもよい。
【０２２６】
さらに、カーナビゲーション装置９２０は、無線通信方式ごとにアンテナ９３７を備えてもよい。その場合に、アンテナスイッチ９３６は、カーナビゲーション装置９２０の構成から省略されてもよい。
【０２２７】
バッテリー９３８は、図中に破線で部分的に示した給電ラインを介して、図４９に示したカーナビゲーション装置９２０の各ブロックへ電力を供給する。また、バッテリー９３８は、車両側から給電される電力を蓄積する。
【０２２８】
図４９に示したカーナビゲーション装置９２０において、図６を参照して説明した処理部２４０に含まれる１つ以上の構成要素（取得部２４１及び／又は受信処理部２４３）は、無線通信インタフェース９３３において実装されてもよい。あるいは、これらの構成要素の少なくとも一部は、プロセッサ９２１において実装されてもよい。一例として、カーナビゲーション装置９２０は、無線通信インタフェース９３３の一部（例えば、ＢＢプロセッサ９３４）若しくは全部及び／又はプロセッサ９２１を含むモジュールを搭載し、当該モジュールにおいて上記１つ以上の構成要素が実装されてもよい。この場合に、上記モジュールは、プロセッサを上記１つ以上の構成要素として機能させるためのプログラム（換言すると、プロセッサに上記１つ以上の構成要素の動作を実行させるためのプログラム）を記憶し、当該プログラムを実行してもよい。別の例として、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムがカーナビゲーション装置９２０にインストールされ、無線通信インタフェース９３３（例えば、ＢＢプロセッサ９３４）及び／又はプロセッサ９２１が当該プログラムを実行してもよい。以上のように、上記１つ以上の構成要素を備える装置としてカーナビゲーション装置９２０又は上記モジュールが提供されてもよく、プロセッサを上記１つ以上の構成要素として機能させるためのプログラムが提供されてもよい。また、上記プログラムを記録した読み取り可能な記録媒体が提供されてもよい。
【０２２９】
また、図４９に示したカーナビゲーション装置９２０において、例えば、図６を参照して説明した無線通信部２２０は、無線通信インタフェース９３３（例えば、ＲＦ回路９３５）において実装されてもよい。また、アンテナ部２１０は、アンテナ９３７において実装されてもよい。また、記憶部２３０は、メモリ９２２において実装されてもよい。
【０２３０】
また、本開示に係る技術は、上述したカーナビゲーション装置９２０の１つ以上のブロックと、車載ネットワーク９４１と、車両側モジュール９４２とを含む車載システム（又は車両）９４０として実現されてもよい。即ち、取得部２４１及び／又は受信処理部２４３を備える装置として車載システム（又は車両）９４０が提供されてもよい。車両側モジュール９４２は、車速、エンジン回転数又は故障情報などの車両側データを生成し、生成したデータを車載ネットワーク９４１へ出力する。
【０２３１】
＜３．まとめ＞
以上説明したように本開示の実施の形態によれば、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを端末装置へ通知する、基地局１００が提供される。
【０２３２】
また本開示の実施の形態によれば、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを基地局１００から通知される、端末装置２００が提供される。
【０２３３】
本開示の実施の形態に係る基地局１００は、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを端末装置２００へ通知することで、端末装置２００での効率的な受信処理を可能にさせる。また、本開示の実施の形態に係る端末装置２００は、既存の送信時間間隔でのデータの送受信に短送信時間間隔でのデータの送受信を混在させる場合に、リソースのどこに短送信時間間隔でのデータが存在するかを基地局１００から通知されることで、効率的な受信処理が可能になる。
【０２３４】
本開示の実施の形態によれば、リソースのどこに短送信時間間隔でのデータが存在するかを端末装置２００へ通知することで、基地局１００は、端末装置２００に搭載しているアプリケーションを、低遅延で、かつレスポンス良く制御することが可能となる。また本開示の実施の形態によれば、基地局１００から短送信時間間隔でのデータの場所を通知されることで、端末装置２００はＡＣＫまたはＮＡＣＫを基地局１００に早く返すことが可能となる。従って本開示の実施の形態によれば、スループットの向上が見込める。特に本開示の実施の形態によれば、基地局１００は、短送信時間間隔のリソースと、既存の送信時間間隔のリソースとを効率的に混在させることができるので、無駄が生じず、スループットを向上させることが出来る。
【０２３５】
また本開示の実施の形態によれば、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信の際に、複数の短送信時間間隔の長さの中から端末装置にとって最適な短送信時間間隔の長さによるデータの送受信を可能とさせる基地局１００が提供される。
【０２３６】
また本開示の実施の形態によれば、既存の送信時間間隔より短い短送信時間間隔でのデータの送受信の際に、複数の短送信時間間隔の長さの中から最適な短送信時間間隔の長さによるデータの送受信を可能とする端末装置２００が提供される。
【０２３７】
本明細書の各装置が実行する処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、各装置が実行する処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。
【０２３８】
また、各装置に内蔵されるＣＰＵ、ＲＯＭおよびＲＡＭなどのハードウェアを、上述した各装置の構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供されることが可能である。また、機能ブロック図で示したそれぞれの機能ブロックをハードウェアまたはハードウェア回路で構成することで、一連の処理をハードウェアまたはハードウェア回路で実現することもできる。
【０２３９】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０２４０】
また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
【０２４１】
なお、以下のような構成も本開示の技術的範囲に属する。
（１）
複数のサブフレームからなるフレームを生成するフレーム生成部と、
前記生成されたフレームを他の通信装置に送信する送信部と、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を通知する通知部と、
を備える、無線通信装置。
（２）
前記複数の長さの情報に基づいて前記他の通信装置から送信された該他の通信装置の能力に関する情報に基づいて前記複数の長さから１つの長さを選択する処理部をさらに備える、前記（１）に記載の無線通信装置。
（３）
前記処理部は、短送信時間間隔でデータを送信する短送信時間間隔領域における一部のリソースを使用して短送信時間間隔のデータを送信する、前記（２）に記載の無線通信装置。
（４）
前記通知部は、短送信時間間隔のそれぞれの長さと、フレーム番号及びサブフレーム番号との対応関係を通知する、前記（１）〜（３）のいずれかに記載の無線通信装置。
（５）
前記処理部は、１つのサブフレームに複数の長さの短送信時間間隔のデータを含める、前記（２）に記載の無線通信装置。
（６）
前記処理部は、１つのサブフレームに複数の他の通信装置宛の短送信時間間隔のデータを含める、前記（２）に記載の無線通信装置。
（７）
前記処理部は、１つのサブフレームに短送信時間間隔のデータを間欠的に配置する、前記（２）に記載の無線通信装置。
（８）
前記処理部は、サブフレーム内の制御領域の長さに応じて短送信時間間隔でデータを送信する短送信時間間隔領域の長さを変化させる、前記（２）に記載の無線通信装置。
（９）
前記通知部は、前記短送信時間間隔が２つのサブフレームに跨がる場合に前記短送信時間間隔とサブフレーム番号との対応関係を通知する、前記（１）〜（８）のいずれかに記載の無線通信装置。
（１０）
前記短送信時間間隔の複数の長さの設定はセル毎に異なる、前記（１）〜（９）のいずれかに記載の無線通信装置。
（１１）
複数のサブフレームからなるフレームを受信すると共に、前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を他の通信装置から取得する取得部を備える、無線通信装置。
（１２）
前記取得部が取得した前記複数の長さの情報に基づいて自装置の能力に関する情報を前記他の通信装置に通知する通知部をさらに備える、前記（１１）に記載の無線通信装置。
（１３）
前記通知部は、前記自装置の能力としてソフトウェア的な能力に関する情報を通知する、前記（１２）に記載の無線通信装置。
（１４）
前記通知部は、前記自装置の能力としてハードウェア的な能力に関する情報を通知する、前記（１２）または（１３）に記載の無線通信装置。
（１５）
前記取得部は、前記基地局で選択された長さの、前記短送信時間間隔のデータを前記基地局から取得する、前記（１１）〜（１４）のいずれかに記載の無線通信装置。
（１６）
複数のサブフレームからなるフレームを生成することと、
前記生成されたフレームを他の通信装置に送信することと、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を通知することと、
を含む、無線通信方法。
（１７）
複数のサブフレームからなるフレームを受信することと、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を基地局から取得することと、
を含む、無線通信方法。
（１８）
コンピュータに、
複数のサブフレームからなるフレームを生成することと、
前記生成されたフレームを他の通信装置に送信することと、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を通知することと、
を実行させる、コンピュータプログラム。
（１９）
コンピュータに、
複数のサブフレームからなるフレームを受信することと、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を基地局から取得することと、
を実行させる、コンピュータプログラム。
（２０）
第１の通信装置及び第２の通信装置を備え、
前記第１の通信装置は、
複数のサブフレームからなるフレームを生成するフレーム生成部と、
前記生成されたフレームを前記第２の通信装置に送信する送信部と、
前記サブフレーム内における、１サブフレーム期間より短い送信時間間隔である短送信時間間隔の、複数の長さの情報を前記第２の通信装置に通知する通知部と、
を備え、
前記第２の通信装置は、前記フレームを受信すると共に、前記サブフレーム内における前記短送信時間間隔の、複数の長さの情報を前記第１の通信装置から取得する取得部を備える、無線通信システム。
【符号の説明】
【０２４２】
１    システム
１００    基地局
２００    端末装置
【図１】
0006642057.tif 000003
【図２】
0006642057.tif 000004
【図３】
0006642057.tif 000005
【図４】
0006642057.tif 000006
【図５】
0006642057.tif 000007
【図６】
0006642057.tif 000008
【図７】
0006642057.tif 000009
【図８】
0006642057.tif 000010
【図９】
0006642057.tif 000011
【図１０】
0006642057.tif 000012
【図１１】
0006642057.tif 000013
【図１２】
0006642057.tif 000014
【図１３】
0006642057.tif 000015
【図１４】
0006642057.tif 000016
【図１５】
0006642057.tif 000017
【図１６】
0006642057.tif 000018
【図１７】
0006642057.tif 000019
【図１８】
0006642057.tif 000020
【図１９】
0006642057.tif 000021
【図２０】
0006642057.tif 000022
【図２１】
0006642057.tif 000023
【図２２】
0006642057.tif 000024
【図２３】
0006642057.tif 000025
【図２４】
0006642057.tif 000026
【図２５】
0006642057.tif 000027
【図２６】
0006642057.tif 000028
【図２７】
0006642057.tif 000029
【図２８】
0006642057.tif 000030
【図２９】
0006642057.tif 000031
【図３０】
0006642057.tif 000032
【図３１】
0006642057.tif 000033
【図３２】
0006642057.tif 000034
【図３３】
0006642057.tif 000035
【図３４】
0006642057.tif 000036
【図３５】
0006642057.tif 000037
【図３６】
0006642057.tif 000038
【図３７】
0006642057.tif 000039
【図３８】
0006642057.tif 000040
【図３９】
0006642057.tif 000041
【図４０】
0006642057.tif 000042
【図４１】
0006642057.tif 000043
【図４２】
0006642057.tif 000044
【図４３】
0006642057.tif 000045
【図４４】
0006642057.tif 000046
【図４５】
0006642057.tif 000047
【図４６】
0006642057.tif 000048
【図４７】
0006642057.tif 000049
【図４８】
0006642057.tif 000050
【図４９】
0006642057.tif 000051