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