図面 (/)

技術 端末装置、通信方法、および、集積回路

出願人 シャープ株式会社
発明者 林貴志鈴木翔一相羽立志大内渉吉村友樹劉麗清
出願日 2016年5月12日 (3年11ヶ月経過) 出願番号 2016-096127
公開日 2019年7月25日 (9ヶ月経過) 公開番号 2019-125815
状態 未査定
技術分野 移動無線通信システム
主要キーワード 洗濯機器 キッチン機器 生活機器 測定ギャップ システムインフォメーション 物理信号 装置グループ 最大送信回数
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年7月25日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (17)

課題

効率的に上りリンク制御情報伝送することができる

解決手段

端末装置は、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソース割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。

概要

背景

セルラー移動通信無線アクセス方式および無線ネットワーク(以下、「Long Term Evolution (LTE)」、または、「Evolved Universal Terrestrial Radio Access : EUTRA
」と称する。)が、第三世代パートナーシッププロジェクト(3rd Generation Partnership Project: 3GPP)において検討されている。LTEでは、基地局装置をeNodeB(evolved NodeB)、端末装置をUE(User Equipment)とも称する。LTEは、基地局装
置がカバーするエリアセル状に複数配置するセルラー通信システムである。単一の基地局装置は複数のセルを管理してもよい。

LTEリリース13において、PUSCHおよびPUCCHが上りリンク制御情報伝送することが仕様化されている(非特許文献1、2、3、4)。非特許文献5において、TTI(Transmission Time Interval)の短縮、および、処理時間の削減について検討されている。非特許文献6において、sPUCCH、および、sPUSCHがチャネル状態情報およびHARQACK(Hybrid Automatic Repeat reQuest-ACKnowledgement)を
伝送することが検討されている。

概要

効率的に上りリンク制御情報を伝送することができる端末装置は、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソース割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。

目的

本発明は、効率的に上りリンク制御情報を送信することができる端末装置、該端末装置に用いられる通信方法、該端末装置に実装される集積回路、効率的に上りリンク制御情報を受信することができる基地局装置、該基地局装置に用いられる通信方法、および、該基地局装置に実装される集積回路を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

スケジューリングリクエストを送信する送信部と、ランダムアクセスプロシージャを開始する上位層処理部を備え、前記送信部は、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソース割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記上位層処理部は、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する、端末装置

請求項2

前記第1のスケジューリングリクエストの最大送信回数と前記第2のスケジューリングリクエストの最大送信回数は、基地局装置から独立に設定される、請求項1記載の端末装置。

請求項3

前記第1スケジューリングリクエストと前記第2のスケジューリングリクエストは異なるTTI長で送信される、請求項1記載の端末装置。

請求項4

前記第1のリソースはsPUCCHのリソースであり、前記第2のリソースはPUCCHのリソースである、請求項1記載の端末装置。

請求項5

端末装置における通信方法であって、スケジューリングリクエストを送信する第1のステップと、ランダムアクセスプロシージャを開始する第2のステップを備え、前記第1のステップは、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記第2のステップは、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する通信方法。

請求項6

前記第1のスケジューリングリクエストの最大送信回数と前記第2のスケジューリングリクエストの最大送信回数は、基地局装置から独立に設定される、請求項5記載の通信方法。

請求項7

前記第1スケジューリングリクエストと前記第2のスケジューリングリクエストは異なるTTI長で送信される、請求項5記載の通信方法。

請求項8

前記第1のリソースはsPUCCHのリソースであり、前記第2のリソースはPUCCHのリソースである、請求項5記載の通信方法。

請求項9

端末装置に実装される集積回路であって、スケジューリングリクエストを送信する送信回路と、ランダムアクセスプロシージャを開始する上位層処理回路を備え、前記送信回路は、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記上位層処理回路は、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する、集積回路。

技術分野

0001

本発明は、端末装置通信方法、および、集積回路に関する。

背景技術

0002

セルラー移動通信無線アクセス方式および無線ネットワーク(以下、「Long Term Evolution (LTE)」、または、「Evolved Universal Terrestrial Radio Access : EUTRA
」と称する。)が、第三世代パートナーシッププロジェクト(3rd Generation Partnership Project: 3GPP)において検討されている。LTEでは、基地局装置をeNodeB(evolved NodeB)、端末装置をUE(User Equipment)とも称する。LTEは、基地局装
置がカバーするエリアセル状に複数配置するセルラー通信システムである。単一の基地局装置は複数のセルを管理してもよい。

0003

LTEリリース13において、PUSCHおよびPUCCHが上りリンク制御情報伝送することが仕様化されている(非特許文献1、2、3、4)。非特許文献5において、TTI(Transmission Time Interval)の短縮、および、処理時間の削減について検討されている。非特許文献6において、sPUCCH、および、sPUSCHがチャネル状態情報およびHARQACK(Hybrid Automatic Repeat reQuest-ACKnowledgement)を
伝送することが検討されている。

先行技術

0004

"3GPP TS 36.211 V13.1.0 (2016-03)", 29th March, 2016.
"3GPP TS 36.212 V13.1.0 (2016-03)", 29th March, 2016.
"3GPP TS 36.213 V13.1.1 (2016-03)", 31th March, 2016.
"3GPP TS 36.300 V13.2.0 (2015-12)", 13th January, 2015.
"New SI proposal: Study on Latency reduction techniques forLTE", RP-150465, Ericsson, Huawei, 3GPP TSG RAN Meeting#67, Shanghai, China, 9th - 12th March 2015.
" Physical layer aspects for PUSCH for short TTI", R1-163320, Ericsson, 3GPP TSG RAN WG1 Meeting#84 bis, Busan, 11th - 15th April 2016.

発明が解決しようとする課題

0005

本発明は、効率的に上りリンク制御情報を送信することができる端末装置、該端末装置に用いられる通信方法、該端末装置に実装される集積回路、効率的に上りリンク制御情報を受信することができる基地局装置、該基地局装置に用いられる通信方法、および、該基地局装置に実装される集積回路を提供する。

課題を解決するための手段

0006

(1)本発明の態様は、以下のような手段を講じた。すなわち、本発明の第1の態様は、端末装置であって、スケジューリングリクエストを送信する送信部と、ランダムアクセスプロシージャを開始する上位層処理部を備え、前記送信部は、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソース割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記上位層処理部は、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなか
った場合、ランダムアクセスプロシージャを開始する。

0007

(2)本発明の第2の態様は、端末装置に用いられる通信方法であって、スケジューリングリクエストを送信する第1のステップと、ランダムアクセスプロシージャを開始する第2のステップを備え、前記第1のステップは、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記第2のステップは、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。

0008

(3)本発明の第5の態様は、端末装置に実装される集積回路であって、スケジューリングリクエストを送信する送信回路と、ランダムアクセスプロシージャを開始する上位層処理回路を備え、前記送信回路は、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記上位層処理回路は、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。

発明の効果

0009

この発明によれば、端末装置は効率的に上りリンク制御情報を送信することができる。また、基地局装置は効率的に上りリンク制御情報を受信することができる。

図面の簡単な説明

0010

本実施形態の無線通信システム概念図である。
本実施形態の無線フレーム概略構成を示す図である。
本実施形態における上りリンクスロットの概略構成を示す図である。
本実施形態におけるTTIおよびsTTIの一例を示す図である。
本実施形態の下りリンクにおける物理チャネルの割り当ての一例を示す図である。
本実施形態の上りリンクにおける物理チャネルの割り当ての一例を示す図である。
本発明における端末装置1の構成を示す概略ブロック図である。
本発明における符号化部1071の構成を示す概略ブロック図である。
本実施形態における符号化変調シンボルインタリーブの方法の一例を示す図で第ある。
本発明における基地局装置3の構成を示す概略ブロック図である。
本実施形態におけるスケジューリングリクエスト送信の一例を示す図である。
本実施形態におけるスケジューリングリクエスト送信の一例を示す図である。
本実施形態におけるスケジューリングリクエスト送信フローの一例を示す図である。
本実施形態におけるスケジューリングリクエスト送信フローの一例を示す図である。
本実施形態におけるスケジューリングリクエスト送信に関連する擬似コードの一例を示す図である。
本実施形態におけるスケジューリングリクエスト送信に関連する擬似コードの一例を示す図である。

実施例

0011

以下、本発明の実施形態について説明する。

0012

図1は、本実施形態の無線通信システムの概念図である。図1において、無線通信システムは、端末装置1A〜1C、および基地局装置3を具備する。以下、端末装置1A〜1Cを端末装置1という。

0013

以下、キャリアアグリゲーションについて説明する。

0014

本実施形態では、端末装置1は、複数のサービングセルが設定される。端末装置1が複数のサービングセルを介して通信する技術をセルアグリゲーション、またはキャリアアグリゲーションと称する。端末装置1に対して設定される複数のサービングセルのそれぞれにおいて、本発明が適用されてもよい。また、設定された複数のサービングセルの一部において、本発明が適用されてもよい。また、設定された複数のサービングセルのグループのそれぞれにおいて、本発明が適用されてもよい。また、設定された複数のサービングセルのグループの一部において、本発明が適用されてもよい。

0015

複数のサービングセルは、少なくとも1つのプライマリセルを含む。複数のサービングセルは、1つ、または、複数のセカンダリセルを含んでもよい。プライマリセルは、初期コネクション確立(initial connection establishment)手順が行なわれたサービングセル、コネクション確立(connection re-establishment)手順を開始したサービング
ル、または、ハンドオーバ手順においてプライマリセルと指示されたセルである。RRC(Radio Resource Control)コネクションが確立された時点、または、後に、セカンダリセルが設定されてもよい。

0016

下りリンクにおいて、サービングセルに対応するキャリア下りリンクコンポーネントキャリアと称する。上りリンクにおいて、サービングセルに対応するキャリアを上りリンクコンポーネントキャリアと称する。下りリンクコンポーネントキャリア、および、上りリンクコンポーネントキャリアを総称して、コンポーネントキャリアと称する。

0017

端末装置1は、複数のサービングセル(コンポーネントキャリア)において同時に複数の物理チャネルでの送信、および/または受信を行うことができる。1つの物理チャネルは、複数のサービングセル(コンポーネントキャリア)のうち1つのサービングセル(コンポーネントキャリア)において送信される。

0018

本実施形態の物理チャネルおよび物理信号について説明する。

0019

図1において、端末装置1から基地局装置3への上りリンクの無線通信では、以下の上りリンク物理チャネルが用いられる。上りリンク物理チャネルは、上位層から出力された情報を送信するために使用される。
・PUCCH(Physical Uplink Control Channel)
・sPUCCH(shortened Physical Uplink Control Channel)
・PUSCH(Physical Uplink Shared Channel)
・sPUSCH(shortened Physical Uplink Shared Channel)
PUCCH、および、sPUCCHは、上りリンク制御情報(Uplink Control Information: UCI)を送信するために用いられる。本実施形態において、端末装置1は、プライ
マリセルのみにおいてPUCCHの送信を行ってもよい。上りリンク制御情報は、下り
ンクのチャネル状態情報(Channel State Information: CSI)、PUSCHリソースの要求を示すスケジューリング要求(Scheduling Request: SR)、下りリンクデータ(Transport block, Medium Access Control Protocol Data Unit: MACPDU, Downlink-Shared Channel: DL-SCH, Physical Downlink Shared Channel:PDSCH)に対するHARQ−ACK(Hybrid Automatic Repeat request ACKnowledgement)を含む。HARQ−ACKは、
ACK(acknowledgement)またはNACK(negative-acknowledgement)を示す。HA
RQ−ACKを、ACK/NACK、HARQフィードバック、HARQ−ACKフィードバック、HARQ応答、HARQ−ACK応答HARQ情報、HARQ−ACK情報、HARQ制御情報、および、HARQ−ACK制御情報とも称する。

0020

PUSCH、および、sPUSCHは、上りリンクデータ(Transport block, Medium Access Control Protocol Data Unit: MACPDU, Uplink-Shared Channel: UL-SCH)を送
信するために用いられてもよい。PUSCHは、上りリンクデータと共にHARQ−ACKおよび/またはチャネル状態情報を送信するために用いられてもよい。また、PUSCHはチャネル状態情報のみ、または、HARQ−ACKおよびチャネル状態情報のみを送信するために用いられてもよい。

0021

非周期的なチャネル状態情報報告は、PUSCH/sPUSCH送信に対応する上りリンクグラントに含まれるフィールドによってトリガされる。周期的なチャネル状態情報報告は、RRCシグナリング(上位層のパラメータ)によってトリガされる。非周期的なチャネル状態情報報告のために、PUSCHが用いられる。周期的なチャネル状態情報報告のために、PUSCHまたはPUCCHが用いられる。

0022

図1において、基地局装置3から端末装置1への下りリンクの無線通信では、以下の下りリンク物理チャネルが用いられる。下りリンク物理チャネルは、上位層から出力された情報を送信するために使用される。
・PDCCH(Physical Downlink Control Channel)
・EPDCCH(Enhanced Physical Downlink Control Channel)
・sPDCCH(shortened Physical Downlink Control Channel)
・PDSCH(Physical Downlink Shared Channel)
・sPDSCH(shortened Physical Downlink Shared Channel)
PDCCH、EPDCCH、および、sPDCCHは、下りリンク制御情報(Downlink
Control Information: DCI)を送信するために用いられる。下りリンク制御情報を、D
CIフォーマットとも称する。下りリンク制御情報は、下りリンクグラント(downlink grant)および上りリンクグラント(uplink grant)を含む。下りリンクグラントは、下りリンクアサインメント(downlink assignment)または下りリンク割り当て(downlink allocation)とも称する。

0023

1つの下りリンクグラントは、1つのセル内の1つのPDSCHのスケジューリングに用いられてもよい。下りリンクグラントは、該下りリンクグラントが送信されたサブフレームと同じサブフレーム内のPDSCHのスケジューリングに用いられてもよい。1つの下りリンクグラントは、1つのセル内の1つのsPDSCHのスケジューリングに用いられてもよい。下りリンクグラントは、該下りリンクグラントが送信されたsTTI(shortened Transmission Time Interval)と同じsTTI内のsPDSCHのスケジューリングに用いられてもよい。

0024

1つの上りリンクグラントは、1つのセル内の1つのPUSCHのスケジューリングに用いられてもよい。上りリンクグラントは、該上りリンクグラントが送信されたサブフレームより4つ以上後のサブフレーム内の1つのPUSCHのスケジューリングに用いられてもよい。1つの上りリンクグラントは、1つのセル内の1つのsPUSCHのスケジュ
リングに用いられてもよい。上りリンクグラントは、該上りリンクグラントが送信されたsTTIより後のsTTI内の1つのsPUSCHのスケジューリングに用いられてもよい。

0025

PDSCH、および、sPDSCHは、下りリンクデータ(Downlink Shared Channel:
DL-SCH)を送信するために用いられる。

0026

UL−SCHおよびDL−SCHは、トランスポートチャネルである。媒体アクセス制御(Medium Access Control: MAC)層で用いられるチャネルをトランスポートチャネルと称する。MAC層で用いられるトランスポートチャネルの単位を、トランスポートブロック(transport block: TB)またはMACPDU(Protocol Data Unit)とも称する。
MAC層においてトランスポートブロック毎にHARQ(Hybrid Automatic Repeat reQuest)の制御が行なわれる。トランスポートブロックは、MAC層が物理層に渡す(deliver)データの単位である。物理層において、トランスポートブロックはコードワードマップされ、コードワード毎に変調処理、および、符号化処理が行なわれる。1つのコードワードは、1つ、または、複数のレイヤにマップされる。

0027

以下、本実施形態の無線フレーム(radio frame)の構成の一例について説明する。図
2は、本実施形態の無線フレームの概略構成を示す図である。無線フレームのそれぞれは、10ms長である。図2において、横軸時間軸である。また、無線フレームのそれぞれは10のサブフレームから構成される。サブフレームのそれぞれは、1ms長であり、2つの連続するスロットによって定義される。スロットのそれぞれは、0.5ms長である。つまり、10ms間隔のそれぞれにおいて、10個のサブフレームが利用できる。サブフレームをTTI(Transmission Time Intervalとも称する。)
以下、本実施形態のスロットの構成の一例について説明する。図3は、本実施形態における上りリンクスロットの概略構成を示す図である。図3において、1つのセルにおける上りリンクスロットの構成を示す。図3において、横軸は時間軸であり、縦軸周波数軸である。図3において、lはSC−FDMAシンボル番号/インデックスであり、kはサブキャリア番号/インデックスである。

0028

スロットのそれぞれにおいて送信される物理シグナルまたは物理チャネルは、リソースグリッドによって表現される。上りリンクにおいて、リソースグリッドは複数のサブキャリアと複数のSC−FDMAシンボルによって定義される。リソースグリッド内のエレメントのそれぞれをリソースエレメントと称する。リソースエレメントは、サブキャリア番号/インデックスk、および、SC−FDMAシンボル番号/インデックスlによって表される。

0029

上りリンクスロットは、時間領域において、複数のSC−FDMAシンボルl(l=0,1,…,NULsymb)を含む。NULsymbは、1つの上りリンクスロットに含まれるSC−FDMA
シンボルの数を示す。上りリンクにおけるノーマルCP(normal Cyclic Prefix)に対して、NULsymbは7である。上りリンクにおける拡張CP(extended CP)に対して、NULsymbは6である。

0030

端末装置1は、上りリンクにおけるCP長を示すパラメータUL-CyclicPrefixLengthを
基地局装置3から受信する。基地局装置3は、セルに対応する該パラメータUL-CyclicPrefixLengthを含むシステムインフォメーションを、該セルにおいて報知してもよい。

0031

上りリンクスロットは、周波数領域において、複数のサブキャリアk(k=0,1,…,NULRB×NRBsc)を含む。NULRBは、NRBscの倍数によって表現される、サービングセルに対する上りリンク帯域幅設定である。NRBscは、サブキャリアの数によって表現される、周波数領
域における(物理)リソースブロックサイズである。サブキャリア間隔Δfは15kHz
であり、NRBscは12であってもよい。すなわち、NRBscは、180kHzであってもよい。サブキャリア間隔Δfはチャネル毎、および/または、TTI/sTTI毎に異なって
もよい。

0032

リソースブロックは、物理チャネルのリソースエレメントへのマッピングを表すために用いられる。リソースブロックは、仮想リソースブロック物理リソースブロックが定義される。物理チャネルは、まず仮想リソースブロックにマップされる。その後、仮想リソースブロックは、物理リソースブロックにマップされる。1つの物理リソースブロックは、時間領域においてNULsymbの連続するSC−FDMAシンボルと周波数領域においてNRBscの連続するサブキャリアとから定義される。ゆえに、1つの物理リソースブロックは(NULsymb×NRBsc)のリソースエレメントから構成される。1つの物理リソースブロックは、時間領域において1つのスロットに対応する。物理リソースブロックは周波数領域において、周波数の低いほうから順に番号(0,1,…, NULRB-1)が付けられる。

0033

本実施形態における下りリンクのスロットは、複数のOFDMシンボルを含む。本実施形態における下りリンクのスロットの構成は、リソースグリッドが複数のサブキャリアと複数のOFDMシンボルによって定義される
点を除いて基本的に同じであるため、下りリンクのスロットの構成の説明は省略する。

0034

図4は、本実施形態におけるTTIおよびsTTIの一例を示す図である。TTIは、2×NULsymbのSC−FDMAシンボルから構成されてもよい。sTTIを構成するSC
−FDMAシンボルの数は、{2、3、4、7}の何れかである。XのSC−FDMAシンボルから構成されるTTI/sTTIをXシンボルTTIとも称する。下りリンクにおいて、TTI、および、sTTIは、複数のOFDMシンボルから構成されてもよい。

0035

図5は、本実施形態の下りリンクにおける物理チャネルの割り当ての一例を示す図である。

0036

sPUCCHの長さ、および、sPUSCHの長さは個別に制御されてもよい。sPUCCHで伝送される情報に基づいて、sPUCCHの長さが決定されてもよい。sPUSCHで伝送される情報に基づいて、sPUCSHの長さが決定されてもよい。

0037

図6は、本実施形態の上りリンクにおける物理チャネルの割り当ての一例を示す図である。PUCCH600、601、および、sPUCCH602−605に対して、周波数ホッピングが適用される。サブフレーム/TTIにおいて、PUSCH、および、PUCCHは、2×NULsymbのSC−FDMAシンボルにマップされてもよい。4シンボルTT
Iにおいて、sPUSCHは4つのSC−FDMAシンボルにマップされてもよい。3シンボルTTIにおいて、sPUSCHは3つのSC−FDMAシンボルにマップされてもよい。7シンボルTTIにおいて、sPUCCHは7つのSC−FDMAシンボルにマップされてもよい。XシンボルTTIにおけるXのSC−FDMAシンボルにマップされるsPUSCHを、XシンボルsPUSCHとも称する。XシンボルTTIにおけるXのSC−FDMAシンボルにマップされるsPUCCHを、XシンボルsPUCCHとも称する。

0038

以下、本発明の端末装置1の装置構成について説明する。

0039

図7は、本発明における端末装置1の構成を示す概略ブロック図である。図示するように、端末装置1は、上位層処理部101、制御部103、受信部105、送信部107および、送受信アンテナ109を含んで構成される。上位層処理部101は、無線リソース
制御部1011、スケジューリング部1013を含んで構成される。受信部105は、復号化部1051、復調部1053、多重分離部1055、無線受信部1057とチャネル測定部1059を含んで構成される。送信部107は、符号化部1071、PUSCH生成部1073、PUCCH生成部1075、多重部1077、無線送信部1079と上りリンク参照信号生成部10711を含んで構成される。

0040

上位層処理部101は、ユーザの操作等により生成された上りリンクデータを、送信部107に出力する。また、上位層処理部101は、媒体アクセス制御(MAC: Medium Access Control)層、パケットデータ統合プロトコル(Packet Data Convergence Protocol: PDCP)層、無線リンク制御(Radio Link Control: RLC)層、無線リソース制御(Radio Resource Control:RRC)層の処理を行なう。また、上位層処理部101はPDCCHで受信された下りリンク制御情報などに基づき、受信部105、および送信部107の制御を行なうために制御情報を生成し、制御部103に出力する。

0041

上位層処理部101が備える無線リソース制御部1011は、自装置の各種設定情報の管理を行なう。例えば、無線リソース制御部1011は、設定されたサービングセルの管理を行なう。また、無線リソース制御部1011は、上りリンクの各チャネルに配置される情報を生成し、送信部107に出力する。無線リソース制御部1011は、受信した下りリンクデータの復号成功した場合には、ACKを生成し送信部107にACKを出力し、受信した下りリンクデータの復号に失敗した場合には、NACKを生成し、送信部107にNACKを出力する。

0042

上位層処理部101が備えるスケジューリング部1013は、受信部105を介して受信した下りリンク制御情報を記憶する。スケジューリング部1013は、上りリンクグラントを受信したサブフレームから4つ後のサブフレームにおいて、受信された上りリンクグラントに従ってPUSCHを送信するよう、制御部103を介して送信部107を制御する。スケジューリング部1013は、下りリンクグラントを受信したサブフレームにおいて、受信された下りリンクグラントに従ってPDSCHを受信するよう、制御部103を介して受信部105を制御する。

0043

制御部103は、上位層処理部101からの制御情報に基づいて、受信部105、および送信部107の制御を行なう制御信号を生成する。制御部103は、生成した制御信号を受信部105、および送信部107に出力して受信部105、および送信部107の制御を行なう。

0044

受信部105は、制御部103から入力された制御信号に従って、送受信アンテナ109を介して基地局装置3から受信した受信信号を、分離、復調、復号し、復号した情報を上位層処理部101に出力する。

0045

無線受信部1057は、送受信アンテナ109を介して受信した下りリンクの信号を直交復調し、直交復調されたアナログ信号ディジタル信号に変換する。無線受信部1057は、ディジタル信号に対して高速フーリエ変換(Fast Fourier Transform:FFT)を行
い、周波数領域の信号を抽出する。

0046

多重分離部1055は、抽出した信号をPDCCH、PDSCH、および下りリンク参照信号に、それぞれ分離する。多重分離部1055は、分離した下りリンク参照信号をチャネル測定部1059に出力する。

0047

復調部1053は、PDCCH、および、PDSCHに対して、QPSK、16QAM(Quadrature Amplitude Modulation)、64QAM等の変調方式に対する復調を行ない
、復号化部1051へ出力する。

0048

復号化部1051は、下りリンクデータの復号を行い、復号した下りリンクデータを上位層処理部101へ出力する。チャネル測定部1059は、下りリンク参照信号から下りリンクの伝搬路推定値を算出し、多重分離部1055へ出力する。チャネル測定部1059は、チャネル状態情報を算出し、尚且つ、チャネル状態情報を上位層処理部101へ出力する
送信部107は、制御部103から入力された制御信号に従って、上りリンク参照信号を生成し、上位層処理部101から入力された上りリンクデータや上りリンク制御情報を符号化および変調し、PUCCH、PUSCH、および生成した上りリンク参照信号を多重し、送受信アンテナ109を介して基地局装置3に送信する。

0049

符号化部1071は、上位層処理部101から入力された上りリンク制御情報と上りリンクデータを符号化し、符号化ビットをPUSCH生成部および/またはPUCCH生成部に出力する。

0050

図8は、本発明における符号化部1071の構成を示す概略ブロック図である。符号化部1071は、データ符号化部1071a、チャネル状態情報符号化部1071b、HARQ−ACK符号化部1071c、および、多重・インタリーブ部1071dを含む。

0051

データ符号化部1071aは、上位層101から入力された上りリンクデータaiに上りリンクデータから生成されたCRCパリティビットを付加し、当該CRCパリティビットが付加された上りリンクデータに誤り訂正符号化を適用し、上りリンクデータの符号化ビットfiを多重・インタリーブ部1071dへ出力する。Aは上りリンクデータのペイロードサイズビット数)である。Fは上りリンクデータの符号化ビット数である。

0052

チャネル状態情報符号化部1071bは、チャネル状態情報oiを符号化する。チャネル状態情報がPUSCHを用いて送信される場合、チャネル状態情報符号化部1071bは、チャネル状態情報の符号化ビットqiを多重・インタリーブ部1071dへ出力する
。チャネル状態情報がPUCCHを用いて送信される場合、チャネル状態情報符号化部1071bは、チャネル状態情報の符号化ビットqiをPUCCH生成部1075へ出力す
る。Oはチャネル状態情報のビット数である。Qはチャネル状態情報の符号化ビット数である。

0053

HARQ−ACK符号化部1071cは、HARQ−ACKbiを符号化する。HARQ−ACKがPUSCHを用いて送信される場合、HARQ−ACK符号化部1071cは、HARQ−ACKの符号化ビットgiを多重・インタリーブ部1071dへ出力する
。HARQ−ACKがPUCCHを用いて送信される場合、HARQ−ACK符号化部1071cは、HARQ−ACKの符号化ビットgiをPUCCH生成部1075へ出力す
る。BはHARQ−ACKのビット数である。GはHARQ−ACKの符号化ビット数である。

0054

符号化部1071は、SRをPUCCH生成部1075へ出力する。

0055

多重・インタリーブ部1071dは、上りリンクデータの符号化ビットfi、チャネル
状態情報の符号化ビットqi、および/または、HARQ−ACKの符号化ビットgiを多重およびインタリーブし、連結された符号化ビットhiをPUSCH生成部1073へ出
力する。

0056

図9は、本実施形態における符号化変調シンボルのインタリーブの方法の一例を示す図
である。符号化変調シンボルは、符号化ビットのグループである。1つの符号化シンボルが変調されることによって1つの変調シンボルが生成される。1つの符号化変調シンボルは、上りリンクデータに対する変調方式の変調次数Qmと同じ数の符号化ビットを含む。

0057

図9において、PUSCH/sPUSCHがマップされるSC−FDMAシンボルの数と同じ数の列がある。ただし、4番目のSC−FDMAシンボルは上りリンク参照信号の送信のために用いられるため、4列目に符号化変調シンボルは配置されない。図9において、上りリンクグラントによって割り当てを示されたPUSCH/sPUSCHのサブキャリアの数と同じ数の行がある。

0058

PUSCH信号生成部1073において、図9の同一の列に配置される符号化変調シンボルに対応する複数の変調シンボルは、ともに離散フーリエ変換(Transform Precoding
)され、DFTされた信号は上りリンクグラントによって無線リソースの割り当てを示されたPUSCH/sPUSCHのリソースエレメントに配置される。i列目の符号化シンボルから生成されたDFTされた信号はi番目のSC−FDMAシンボルに対応するリソースエレメントに配置される。

0059

PUSCH生成部1073は、符号化部1071から入力された符号化ビットhiを変
調して変調シンボルを生成し、変調シンボルをDFTすることによってPUSCH/sPUSCHの信号を生成し、尚且つ、DFTされたPUSCH/sPUSCHの信号を多重部1077へ出力する。

0060

PUCCH生成部1075は、符号化部1071から入力された符号化ビットqi/gi、および/または、SRに基づいて、PUCCH/sPUCCHの信号を生成し、生成したPUCCH/sPUCCHの信号を多重部1077へ出力する。

0061

上りリンク参照信号生成部10711は上りリンク参照信号を生成し、生成した上りリンク参照信号を多重部1077へ出力する。

0062

多重部1075は、制御部103から入力された制御信号に従って、PUSCH生成部1073から入力された信号および/またはPUCCH生成部か1075ら入力された信号、および/または、上りリンク参照信号生成部10711から入力された上りリンク参照信号を、送信アンテナポート毎に上りリンクのリソースエレメントに多重する。

0063

無線送信部1077は、多重された信号を逆高速フーリエ変換(Inverse Fast Fourier
Transform:IFFT)して、SC−FDMA方式の変調を行い、ベースバンドのディジタル信号を生成し、ベースバンドのディジタル信号をアナログ信号に変換し、アナログ信号から中間周波数同相成分および直交成分を生成し、中間周波数帯域に対する余分な周波数成分を除去し、中間周波数の信号を高周波数の信号に変換(アップコンバート: up convert)し、余分な周波数成分を除去し、電力増幅し、送受信アンテナ109に出力して送信する。

0064

以下、本発明の基地局装置3の装置構成について説明する。

0065

図10は、本発明における基地局装置3の構成を示す概略ブロック図である。図示するように、基地局装置3は、上位層処理部301、制御部303、受信部305、送信部307、および、送受信アンテナ309、を含んで構成される。また、上位層処理部301は、無線リソース制御部3011とスケジューリング部3013を含んで構成される。また、受信部305は、データ復調/復号部3051、制御情報復調/復号部3053、多重分離部3055、無線受信部3057とチャネル測定部3059を含んで構成される。
また、送信部307は、符号化部3071、変調部3073、多重部3075、無線送信部3077と下りリンク参照信号生成部3079を含んで構成される。

0066

上位層処理部301は、媒体アクセス制御(MAC: Medium Access Control)層、パケットデータ統合プロトコル(Packet Data Convergence Protocol: PDCP)層、無線リンク制御(Radio Link Control: RLC)層、無線リソース制御(Radio Resource Control:RRC)層の処理を行なう。また、上位層処理部301は、受信部305、および送信部307の制御を行なうために制御情報を生成し、制御部303に出力する。

0067

上位層処理部301が備える無線リソース制御部3011は、下りリンクのPDSCHに配置される下りリンクデータ、RRCシグナル、MAC CE(Control Element)を
生成し、又は上位ノードから取得し、HARQ制御部3013に出力する。また、無線リソース制御部3011は、移動局装置1各々の各種設定情報の管理をする。例えば、無線リソース制御部3011は、移動局装置1に設定したサービングセルの管理などを行なう。

0068

上位層処理部301が備えるスケジューリング部3013は、移動局装置1に割り当てるPUSCHやPUCCHの無線リソースの管理をしている。スケジューリング部3013は、移動局装置1にPUSCHの無線リソースを割り当てた場合には、PUSCHの無線リソースの割り当てを示す上りリンクグラントを生成し、生成した上りリンクグラントを送信部307へ出力する。

0069

制御部303は、上位層処理部301からの制御情報に基づいて、受信部305、および送信部307の制御を行なう制御信号を生成する。制御部303は、生成した制御信号を受信部305、および送信部307に出力して受信部305、および送信部307の制御を行なう。

0070

受信部305は、制御部303から入力された制御信号に従って、送受信アンテナ309を介して移動局装置1から受信した受信信号を分離、復調、復号し、復号した情報を上位層処理部301に出力する。

0071

無線受信部3057は、送受信アンテナ309を介して受信された上りリンクの信号を直交復調し、直交復調されたアナログ信号をディジタル信号に変換する。無線受信部3057は、ディジタル信号に対して高速フーリエ変換(Fast Fourier Transform:FFT)を
行い、周波数領域の信号を抽出し多重分離部3055に出力する。

0072

多重分離部1055は、無線受信部3057から入力された信号をPUCCH、PUSCH、上りリンク参照信号などの信号に分離する。尚、この分離は、予め基地局装置3が無線リソース制御部3011で決定し、各移動局装置1に通知した上りリンクグラントに含まれる無線リソースの割り当て情報に基づいて行なわれる。多重分離部3055は、チャネル測定部3059から入力された伝搬路の推定値から、PUCCHとPUSCHの伝搬路の補償を行なう。また、多重分離部3055は、分離した上りリンク参照信号をチャネル測定部3059に出力する。

0073

多重分離部3055は、分離したPUCCHとPUSCHの信号から、上りリンクデータの変調シンボルと上りリンク制御情報(HARQ−ACK)の変調シンボルを取得する。多重分離部3055は、PUSCHの信号から取得した上りリンクデータの変調シンボルをデータ復調/復号部3051へ出力する。多重分離部3055は、PUCCHの信号またはPUSCHの信号から取得した上りリンク制御情報(HARQ−ACK)の変調シンボルを制御情報復調/復号部3053へ出力する。

0074

チャネル測定部3059は、多重分離部3055から入力された上りリンク参照信号から伝搬路の推定値、チャネルの品質などを測定し、多重分離部3055および上位層処理部301に出力する。

0075

データ復調/復号部3051は、多重分離部3055から入力された上りリンクデータの変調シンボルから上りリンクデータを復号する。データ復調/復号部3051は、復号された上りリンクデータを上位層処理部301へ出力する。

0076

制御情報復調/復号部3053は、多重分離部3055から入力されたHARQ−ACKの変調シンボルからHARQ−ACKを復号する。制御情報復調/復号部3053は、復号したHARQ−ACKを上位層処理部301へ出力する。

0077

送信部307は、制御部303から入力された制御信号に従って、下りリンク参照信号を生成し、上位層処理部301から入力された下りリンク制御情報、下りリンクデータを符号化、および変調し、PDCCH、PDSCH、および下りリンク参照信号を多重して、送受信アンテナ309を介して移動局装置1に信号を送信する。

0078

符号化部3071は、上位層処理部301から入力された下りリンク制御情報、および、下りリンクデータの符号化を行なう。変調部3073は、符号化部3071から入力された符号化ビットをBPSK、QPSK、16QAM、64QAM等の変調方式で変調する。

0079

下りリンク参照信号生成部3079は下りリンク参照信号として生成する。多重部3075は、各チャネルの変調シンボルと下りリンク参照信号を多重する。

0080

無線送信部3077は、多重された変調シンボルなどを逆高速フーリエ変換(Inverse Fast Fourier Transform:IFFT)して、OFDM方式の変調を行い、ベースバンドのディジタル信号を生成し、ベースバンドのディジタル信号をアナログ信号に変換し、アナログ信号から中間周波数の同相成分および直交成分を生成し、中間周波数帯域に対する余分な周波数成分を除去し、中間周波数の信号を高周波数の信号に変換(アップコンバート: up
convert)し、余分な周波数成分を除去し、電力増幅し、送受信アンテナ309に出力して送信する。

0081

端末装置1、および、基地局装置3に含まれる部のそれぞれは、回路として構成されてもよい。

0082

スケジューリングリクエストは、正のスケジューリングリクエスト(positive scheduling request)、または、負のスケジューリングリクエスト(negative scheduling request)を含む。正のスケジューリングリクエストは、初期送信のためのUL−SCHリソースを要求することを示す。負のスケジューリングリクエストは、初期送信のためのUL−SCHリソースを要求しないことを示す。

0083

PUCCHフォーマット1は、正のスケジューリングリクエストを送信するために用いられる。PUCCHフォーマット1aは、1ビットのHARQ−ACKを送信するために用いられる。PUCCHフォーマット1bは、2ビットのHARQ−ACKを送信するために用いられる。チャネル選択をともなうPUCCHフォーマット1bは、端末装置に1つより多いサービングセルを設定される場合に4ビットまでのHARQ−ACKを送信するために用いられる。PUCCHフォーマット3は、HARQ−ACKのみを送信するために用いられてもよい。PUCCHフォーマット3は、HARQ−ACKおよびスケジュ
ーリングリクエスト(正のスケジューリングリクエスト、または、負のスケジューリングリクエスト)を送信するために用いられてもよい。

0084

図11は本実施形態におけるスケジューリングリクエスト(SR)送信の一例を示す図である。

0085

図11におけるa102からa106は、スケジューリングリクエストのために有効なリソースである。換言すると、a102からa106は、スケジューリングリクエストを送信するために有効なリソースである。ここで、該リソースはPUCCHのリソースまたはsPUCCHのリソースであることが好ましい。なお、図11においては説明のためa102からa106を図示しているが、スケジューリングリクエストのために有効なリソースはa102からa106以外に存在してもよい。

0086

なお、スケジューリングリクエストのために有効なリソースは、周期的に存在することが好ましい。ここで、「周期的に存在する」とは、時間領域において所定の周期で存在することであってもよいし、時間領域において所定の時間間隔で存在することであってもよい。すなわち、スケジューリングリクエストのために有効なリソースは、端末装置において周期(Periodicity)を用いて特定されることが好ましい。

0087

なお、スケジューリングリクエストのために有効なリソースは、周期およびオフセットで特定されてもよい。ここで、オフセットは、時間領域におけるオフセットであってもよく、周期に対するオフセットであってもよい。なお、周期は、基地局装置から上位層の信号を用いて端末装置に通知されてもよい。

0088

なお、オフセットは、基地局装置から上位層の信号を用いて端末装置に通知されてもよい。なお、周期は、時間で定義されてもよいし、無線フレーム数(無線フレーム単位)で定義されてもよいし、サブフレーム数サブフレーム単位)で定義されてもよいし、スロット数スロット単位)で定義されてもよいし、シンボル数シンボル単位)で定義されてもよい。なお、オフセットは、時間で定義されてもよいし、無線フレーム数(無線フレーム単位)で定義されてもよいし、サブフレーム数(サブフレーム単位)で定義されてもよいし、スロット数(スロット単位)で定義されてもよいし、シンボル数(シンボル単位)で定義されてもよい。

0089

図11におけるdsr-TransMaxは、スケジューリングリクエストの最大送信回数に関連するパラメータであってもよい。ここで、dsr-TransMaxは、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。換言すると、スケジューリングリクエストの最大送信回数は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。

0090

図11におけるSR_COUNTERは、スケジューリングリクエストの送信回数に関連するパラメータであってもよい。ここで、SR_COUNTERは、初期値が0であってスケジューリングリクエストを送信する毎にインクリメントされてもよい。なお、インクリメントするとは、SR_COUNTERの値に1を足すことであってもよい。なお、SR_COUNTERは、インクリメントされてdsr-TransMaxに等しくなった場合、0にリセットされてもよい。なお、スケジューリングリクエストがトリガされた場合、SR_COUNTERは0にリセットされてもよい。なお、SR_COUNTERは、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられた場合に0にリセットされてもよい。なお、SR_COUNTERの初期値は0でなくてもよい。例えば、SR_COUNTERの初期値は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。

0091

図11におけるa101は、sr_ProhibitTimerがランニングしている時間である。ここで、sr_ProhibitTimerがランニングしている時間は、スケジューリングリクエストの送信を禁止する時間であってもよい。換言すると、sr_ProhibitTimerがランニングしている時間においてスケジューリングリクエストのために有効なリソースが存在した場合、該リソースを用いてスケジューリングリクエストを送信することは禁止される。換言すると、sr_ProhibitTimerがランニングしていない時間においては、スケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。また、sr_ProhibitTimerが満了した場合、スケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。なお、sr_ProhibitTimerはスケジューリングリクエストを送信した後にランニングされてもよい。なお、sr_ProhibitTimerは、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。なお、sr_ProhibitTimerは、時間で定義されてもよいし、無線フレーム数(無線フレーム単位)で定義されてもよいし、サブフレーム数(サブフレーム単位)で定義されてもよいし、スロット数(スロット単位)で定義されてもよいし、シンボル数(シンボル単位)で定義されてもよい。

0092

以下、図11の詳細について説明する。ここでは、スケジューリングリクエストの最大送信回数に関連するパラメータであるdsr-TransMaxが2に設定された場合を例に説明する。

0093

端末装置は、スケジューリングリクエストがトリガされた場合、スケジューリングリクエストのために有効なリソースを用いてスケジューリングを送信する。端末装置は、sr_ProhibitTimerがランニングしていない時間に存在するリソースa102を用いて1回目のスケジューリングリクエストを送信する。そして、SR_COUNTERを0から1へインクリメントし、sr_ProhibitTimerを開始する(sr_ProhibitTimerをランニングさせる)。1回目のスケジューリングリクエストの送信後、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられなかった場合、端末装置はSR_COUNTERの値とdsr-TransMaxを比較する。そして、ここでは、SR_COUNTERの値がdsr-TransMaxより小さいため、リソースa104を用いて2回目のスケジューリングリクエストを送信する。そして、SR_COUNTERを1から2へインクリメントし、sr_ProhibitTimerを開始する。なお、リソースa103もスケジューリングリクエストのために有効なリソースであるが、sr_ProhibitTimerがランニングしている時間のため、端末装置はリソースa103を用いてスケジューリングリクエストを送信しない。2回目のスケジューリングリクエストの送信後、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられなかった場合、端末装置はSR_COUNTERの値とdsr-TransMaxを比較する。そして、ここでは、SR_COUNTERの値がdsr-TransMaxと等しいため(換言すると、SR_COUNTERの値がdsr-TransMaxより小さくないため)、ランダムアクセスプロシージャを開始する。なお、該ランダムアクセスプロシージャは、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)のスケジューリングを要求するために開始される。すなわち、リソースa106を用いて3回目のスケジューリングリクエストを送信しない。なお、ランダムアクセスプロシージャを開始した場合、SR_COUNTERは0へリセットされてもよい。なお、リソースa105もスケジューリングリクエストのために有効なリソースであるが、sr_ProhibitTimerがランニングしている時間のため、端末装置はリソースa105を用いてスケジューリングリクエストを送信しない。

0094

図12は本実施形態におけるスケジューリングリクエスト(SR)送信の一例を示す図である。

0095

図12におけるa203からa217は、スケジューリングリクエストのために有効な第1のリソースである。図12におけるa218からa225は、スケジューリングリク
エストのために有効な第2のリソースである。換言すると、a203からa217は、スケジューリングリクエストを送信するために有効な第1のリソースである。換言すると、a218からa225は、スケジューリングリクエストを送信するために有効な第2のリソースである。ここで、該第1のリソースはsPUCCHのリソースであることが好ましく、該第2のリソースはPUCCHのリソースであることが好ましい。なお、該第1のリソースは第1のsPUCCHのリソースであってもよく、該第2のリソースは第2のsPUCCHのリソースであってもよい。なお、図12においては説明のためa203からa217とa218からa225を図示しているが、スケジューリングリクエストのために有効なリソースはa203からa217とa218からa225以外に存在してもよい。なお、図12においては説明のためa203からa217とa218からa225を異なる時間軸上に示している。しかし、実際は、a203からa217とa218からa225が同じ時間軸上に存在することが好ましい。

0096

なお、スケジューリングリクエストのために有効な第1のリソースおよびスケジューリングリクエストのために有効な第2のリソースは、周期的に存在することが好ましい。ここで、「周期的に存在する」とは、時間領域において所定の周期で存在することであってもよいし、時間領域において所定の時間間隔で存在することであってもよい。すなわち、スケジューリングリクエストのために有効な第1のリソースは、端末装置において第1の周期(Periodicity)を用いて特定されることが好ましい。さらに、スケジューリングリ
クエストのために有効な第2のリソースは、端末装置において第2の周期(Periodicity
)を用いて特定されることが好ましい。

0097

なお、スケジューリングリクエストのために有効な第1のリソースは、第1の周期および/または第1のオフセットで特定されてもよい。更に、スケジューリングリクエストのために有効な第2のリソースは、第2の周期および/または第2のオフセットで特定されてもよい。ここで、第1のオフセットは、時間領域におけるオフセットであってもよく、第2の周期に対する時間的なずれを示すオフセットであってもよい。ここで、第2のオフセットは、時間領域におけるオフセットであってもよく、第1の周期に対する時間的なずれを示すオフセットであってもよい。

0098

なお、スケジューリングリクエストのために有効な第2のリソースは、第2の周期および/または第2のオフセットで特定され、スケジューリングリクエストのために有効な第1のリソースは、第1のオフセットのみで特定されてもよい。すなわち、第1のオフセットは、第2のリソースに対する第1のリソースの時間的なずれを示すオフセットであってもよい。

0099

なお、第1の周期および/または第2の周期は、基地局装置から上位層の信号を用いて端末装置に通知されてもよい。なお、第1のオフセットおよび/または第2のオフセットは、基地局装置から上位層の信号を用いて端末装置に通知されてもよい。なお、第1の周期および/または第2の周期は、時間で定義されてもよいし、無線フレーム数(無線フレーム単位)で定義されてもよいし、サブフレーム数(サブフレーム単位)で定義されてもよいし、スロット数(スロット単位)で定義されてもよいし、シンボル数(シンボル単位)で定義されてもよい。なお、オフセットは、時間で定義されてもよいし、無線フレーム数(無線フレーム単位)で定義されてもよいし、サブフレーム数(サブフレーム単位)で定義されてもよいし、スロット数(スロット単位)で定義されてもよいし、シンボル数(シンボル単位)で定義されてもよい。

0100

なお、第1の周期と第2の周期は、独立に設定されてもよい。換言すると、第1の周期と第2の周期は、独立に基地局装置から通知されてもよい。なお、第1のオフセットと第2のオフセットは、独立に設定されてもよい。換言すると、第1のオフセットと第2のオ
フセットは、独立に基地局装置から通知されてもよい。

0101

図12におけるdsr-TransMax-rel14は、第1のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータであってもよい。ここで、dsr-TransMax-rel14は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。換言すると、第1のリソースを用いたスケジューリングリクエストの最大送信回数は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。

0102

図12におけるdsr-TransMaxは、第2のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータであってもよい。ここで、dsr-TransMaxは、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。換言すると、第2のリソースを用いたスケジューリングリクエストの最大送信回数は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。

0103

なお、図12においては説明のため、dsr-TransMax-rel14とdsr-TransMaxを異なるパラメータとして示しているが、dsr-TransMax-rel14とdsr-TransMaxは同じであってもよい。すなわち、第1のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータと第2のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータは、共通であってもよい。換言すると、第1のリソースを用いたスケジューリングリクエストの最大送信回数と第2のリソースを用いたスケジューリングリクエストの最大送信回数は、同じであってもよい。例えば、第1のリソースを用いたスケジューリングリクエストの最大送信回数と第2のリソースを用いたスケジューリングリクエストの最大送信回数は、共にdsr-TransMaxで設定されてもよい。例えば、第1のリソースを用いたスケジューリングリクエストの最大送信回数と第2のリソースを用いたスケジューリングリクエストの最大送信回数の合計回数がdsr-TransMaxで設定されてもよい。

0104

図12におけるSR_COUNTER-rel14は、第1のリソースを用いたスケジューリングリクエストの送信回数に関連するパラメータであってもよい。ここで、SR_COUNTER-rel14は、初期値が0であって第1のリソースを用いてスケジューリングリクエストを送信する毎にインクリメントされてもよい。なお、インクリメントするとは、SR_COUNTER-rel14の値に1を足すことであってもよい。なお、SR_COUNTER-rel14は、インクリメントされてdsr-TransMax-rel14に等しくなった場合、0にリセットされてもよい。なお、第1のリソースを用いたスケジューリングリクエストがトリガされた場合、SR_COUNTER-rel14は0にリセットされてもよい。なお、SR_COUNTER-rel14は、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられた場合に0にリセットされてもよい。なお、SR_COUNTER-rel14の初期値は0でなくてもよい。例えば、SR_COUNTER-rel14の初期値は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。

0105

図12におけるSR_COUNTERは、第2のリソースを用いたスケジューリングリクエストの送信回数に関連するパラメータであってもよい。ここで、SR_COUNTERは、初期値が0であって第2のリソースを用いてスケジューリングリクエストを送信する毎にインクリメントされてもよい。なお、インクリメントするとは、SR_COUNTERの値に1を足すことであってもよい。なお、SR_COUNTERは、インクリメントされてdsr-TransMaxに等しくなった場合、0にリセットされてもよい。なお、第2のリソースを用いたスケジューリングリクエストがトリガされた場合、SR_COUNTERは0にリセットされてもよい。なお、SR_COUNTERは、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられた場合に0にリセットされてもよい。なお、SR_COUNTERの初期値は0でなくても
よい。例えば、SR_COUNTERの初期値は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。

0106

なお、図12においては説明のため、SR_COUNTER-rel14とSR_COUNTERを異なるパラメータとして示しているが、SR_COUNTER-rel14とSR_COUNTERは同じであってもよい。すなわち、第1のリソースを用いたスケジューリングリクエストの送信回数に関連するパラメータと第2のリソースを用いたスケジューリングリクエストの送信回数に関連するパラメータは、共通であってもよい。換言すると、第1のリソースを用いたスケジューリングリクエストの送信回数と第2のリソースを用いたスケジューリングリクエストの送信回数は1つのSR_COUNTERを用いてカウントされてもよい。例えば、SR_COUNTERを用いて第1のリソースを用いたスケジューリングリクエストの送信回数と第2のリソースを用いたスケジューリングリクエストの送信回数の合計回数がカウントされてもよい。例えば、SR_COUNTERを用いて第2のリソースを用いたスケジューリングリクエストの送信回数をカウントした後、該SR_COUNTERを0にリセットし、リセットされたSR_COUNTERを用いて第1のリソースを用いたスケジューリングリクエストの送信回数をカウントしてもよい。

0107

図12におけるa201は、sr_ProhibitTimer-rel14がランニングしている時間である。ここで、sr_ProhibitTimer-rel14がランニングしている時間は、第1のリソースを用いたスケジューリングリクエストの送信を禁止する時間であってもよい。換言すると、sr_ProhibitTimer-rel14がランニングしている時間において第1のリソースを用いたスケジューリングリクエストのために有効なリソースが存在した場合、該リソースを用いてスケジューリングリクエストを送信することは禁止される。換言すると、sr_ProhibitTimer-rel14がランニングしていない時間においては、第1のリソースを用いたスケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。また、sr_ProhibitTimer-rel14が満了した場合、第1のリソースを用いたスケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。なお、sr_ProhibitTimer-rel14は第1のリソースを用いたスケジューリングリクエストを送信した後にランニングされてもよい。なお、sr_ProhibitTimer-rel14は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。なお、sr_ProhibitTimer-rel14は、時間で定義されてもよいし、無線フレーム数(無線フレーム単位)で定義されてもよいし、サブフレーム数(サブフレーム単位)で定義されてもよいし、スロット数(スロット単位)で定義されてもよいし、シンボル数(シンボル単位)で定義されてもよい。

0108

図12におけるa202は、sr_ProhibitTimerがランニングしている時間である。ここで、sr_ProhibitTimerがランニングしている時間は、第2のリソースを用いたスケジューリングリクエストの送信を禁止する時間であってもよい。換言すると、sr_ProhibitTimerがランニングしている時間において第2のリソースを用いたスケジューリングリクエストのために有効なリソースが存在した場合、該リソースを用いてスケジューリングリクエストを送信することは禁止される。換言すると、sr_ProhibitTimerがランニングしていない時間においては、第2のリソースを用いたスケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。また、sr_ProhibitTimerが満了した場合、第2のリソースを用いたスケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。なお、sr_ProhibitTimerは第2のリソースを用いたスケジューリングリクエストを送信した後にランニングされてもよい。なお、sr_ProhibitTimerは、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。なお、sr_ProhibitTimerは、時間で定義されてもよいし、無線フレーム数(無線フレーム単位)で定義されてもよいし、サブフレーム数(サブフレーム単位)で定義されてもよいし、スロット数(スロット単位)で定義されてもよいし、シンボル数(シンボル単位)で定義されて
もよい。

0109

なお、図12においては説明のため、sr_ProhibitTimer -rel14とsr_ProhibitTimerを
異なるパラメータとして示しているが、sr_ProhibitTimer-rel14とsr_ProhibitTimerは同じであってもよい。すなわち、第1のリソースを用いたスケジューリングリクエストの送信を禁止する時間と第2のリソースを用いたスケジューリングリクエストの送信を禁止する時間は、共通であってもよい。換言すると、第1のリソースを用いたスケジューリングリクエストの送信を禁止する時間と第2のリソースを用いたスケジューリングリクエストの送信を禁止する時間は、同じであってもよい。例えば、第1のリソースを用いたスケジューリングリクエストの送信を禁止する時間と第2のリソースを用いたスケジューリングリクエストの送信を禁止する時間は、共にsr_ProhibitTimerで設定されてもよい。

0110

以下、図12の詳細について説明する。ここでは、第1のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータであるdsr-TransMax-rel14が2、第2のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータであるdsr-TransMaxが2に設定された場合を例に説明する。

0111

端末装置は、スケジューリングリクエストがトリガされた場合、スケジューリングリクエストのために有効な第1のリソースを用いてスケジューリングを送信する。端末装置は、sr_ProhibitTimer-rel14がランニングしていない時間に存在するリソースa203を用いて1回目のスケジューリングリクエストを送信する。そして、SR_COUNTER-rel14を0から1へインクリメントし、sr_ProhibitTimer-rel14を開始する(sr_ProhibitTimer-rel14をランニングさせる)。スケジューリングリクエストのために有効な第1のリソースを用いた1回目のスケジューリングリクエストの送信後、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられなかった場合、端末装置はSR_COUNTER-rel14の値とdsr-TransMax-rel14を比較する。そして、ここでは、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さいため、リソースa205を用いて2回目のスケジューリングリクエストを送信する。そして、SR_COUNTER-rel14を1から2へインクリメントし、sr_ProhibitTimer-rel14を開始する。なお、リソースa204もスケジューリングリクエストのために有効な第1のリソースであるが、sr_ProhibitTimer-rel14がランニングしている時間のため、端末装置はリソースa204を用いてスケジューリングリクエストを送信しない。スケジューリングリクエストのために有効な第1のリソースを用いた2回目のスケジューリングリクエストの送信後、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられなかった場合、端末装置はSR_COUNTER-rel14の値とdsr-TransMax-rel14を比較する。そして、ここでは、SR_COUNTER-rel14の値がdsr-TransMax-rel14と等しいため(換言すると、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さくないため)、第1のリソースを用いたスケジューリングリクエストの送信を終了する。すなわち、リソースa207を用いて3回目のスケジューリングリクエストを送信しない。なお、リソースa206もスケジューリングリクエストのために有効な第1のリソースであるが、sr_ProhibitTimer-rel14がランニングしている時間のため、端末装置はリソースa206を用いてスケジューリングリクエストを送信しない。そして、端末装置は、第2のリソースを用いたスケジューリングリクエストの送信を開始する。端末装置は、sr_ProhibitTimerがランニングしていない時間に存在するリソースa221を用いて1回目のスケジューリングリクエストを送信する。そして、SR_COUNTERを0から1へインクリメントし、sr_ProhibitTimerを開始する(sr_ProhibitTimerをランニングさせる)。スケジューリングリクエストのために有効な第2のリソースを用いた1回目のスケジューリングリクエストの送信後、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられなかった場合、端末装置はSR_COUNTERの値とdsr-TransMaxを比較する。そして、ここでは、SR_COUNTERの値がdsr-TransMaxより小さいため、リソースa223を用いて2回目のスケジューリングリクエストを
送信する。そして、SR_COUNTERを1から2へインクリメントし、sr_ProhibitTimerを開始する。なお、リソースa222もスケジューリングリクエストのために有効なリソースであるが、sr_ProhibitTimerがランニングしている時間のため、端末装置はリソースa222を用いてスケジューリングリクエストを送信しない。スケジューリングリクエストのために有効な第2のリソースを用いた2回目のスケジューリングリクエストの送信後、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられなかった場合、端末装置はSR_COUNTERの値とdsr-TransMaxを比較する。そして、ここでは、SR_COUNTERの値がdsr-TransMaxと等しいため(換言すると、SR_COUNTERの値がdsr-TransMaxより小さくないため)、ランダムアクセスプロシージャを開始する。なお、該ランダムアクセスプロシージャは、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)のスケジューリングを要求するために開始される。すなわち、リソースa225を用いて3回目のスケジューリングリクエストを送信しない。なお、ランダムアクセスプロシージャを開始した場合、SR_COUNTERは0へリセットされてもよい。なお、リソースa224もスケジューリングリクエストのために有効なリソースであるが、sr_ProhibitTimerがランニングしている時間のため、端末装置はリソースa224を用いてスケジューリングリクエストを送信しない。

0112

すなわち、端末装置は、スケジューリングリクエストのために有効な第1のリソースを用いて所定の回数スケジューリングリクエストを送信する。そして、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられなかった場合、端末装置は、スケジューリングリクエストのために有効な第2のリソースを用いて所定の回数スケジューリングリクエストを送信する。そして、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)が割り当てられなかった場合、端末装置は、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)のスケジューリングを要求するためのランダムアクセスプロシージャを開始する。

0113

図13は本実施形態におけるスケジューリングリクエスト送信フローの一例を示す図である。

0114

図13図11に対応するフローの一例である。すなわち、図13は、図11のスケジューリングリクエスト送信の一例に対応するスケジューリングリクエスト送信フローの一例である。

0115

図13は、本実施形態における、サブフレーム(TTI)のそれぞれに対して実行されるスケジューリングリクエストに関する処理の一例を示す図である。図13の処理はMAC層において実行される。端末装置1は、少なくとも1つのスケジューリングリクエストがペンディングしている間、送信のために利用可能なUL−SCHがないサブフレームのそれぞれに対して図13における処理を実行する。尚、具体的な処理は、図13の処理に限られるものではなく、この発明の要旨を逸脱しない範囲でステップの入れ替え/追加/除去等によって変更された処理も含まれる。また、図13の処理は、請求項に示した範囲で種々の変更が可能であり、開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

0116

なお、図13においては、説明のため「PUCCHリソース」と称している。しかし、該PUCCHリソースは、第1のリソース、sPUCCHリソース、などに換言することができる。

0117

以下、図13の詳細について説明する。

0118

S301において、フローは開始される。

0119

S302において、スケジューリングリクエストがトリガされているか否か判断する。S302において、スケジューリングリクエストがトリガされていると判断した場合、S303へ進む。

0120

なお、スケジューリングリクエストがトリガされる場合には、該スケジューリングリクエストがキャンセルされるまで、該スケジューリングリクエストはペンディングであるとみなされる。スケジューリングリクエストがトリガされ、ペンディングしている他のスケジューリングリクエストがない場合には、端末装置1はカウンターSR_COUNTERを0にセットする。

0121

S303において、ペンディングしている他のスケジューリングリクエストがないか否かを判断する。S303において、ペンディングしている他のスケジューリングリクエストがないと判断した場合、S304へ進む。

0122

S304において、SR_COUNTERは0に設定される。すなわち、S304において、SR_COUNTERは0にリセットされる。S304において、SR_COUNTERが0に設定された後、S305へ進む。

0123

S305において、送信のために利用可能なUL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)があるか否かを判断する。S305において、送信のために利用可能なUL−SCHリソースがないと判断された場合、S306へ進む。S305において、送信のために利用可能なUL−SCHリソースがあると判断された場合、S312へ進む。すなわち、S305において、送信のために利用可能なUL−SCHリソースがあると判断された場合、フローを終了する。

0124

S306において、スケジューリングリクエストのための有効なPUCCHリソースが設定されているか否かを判断する。S306において、スケジューリングリクエストのための有効なPUCCHリソースが設定されていると判断した場合、S307へ進む。S306において、スケジューリングリクエストのための有効なPUCCHリソースが設定されていないと判断した場合、S309へ進む。

0125

S307において、該サブフレーム(TTI)が測定ギャップの一部か否かを判断し、更に、sr-ProhibitTimerがランニングしているか否か判断する。S307において、該サブフレーム(TTI)が測定ギャップの一部ではない、かつ、sr-ProhibitTimerがランニングしていないと判断した場合、S308へ進む。

0126

S308において、SR_COUNTERの値がdsr-TransMaxより小さいか否か判断する。S308において、SR_COUNTERの値がdsr-TransMaxより小さいと判断された場合、S310へ進む。S308において、SR_COUNTERの値がdsr-TransMaxより小さくないと判断された場合、S311へ進む。すなわち、S308において、SR_COUNTERの値がdsr-TransMaxと等しいと判断された場合、S311へ進む。すなわち、S308において、SR_COUNTERの値がdsr-TransMaxより大きいと判断された場合、S311へ進む。

0127

S309において、ランダムアクセスプロシージャを開始(initiate)する。S309において、ランダムアクセスプロシージャを開始した後、S312へ進む。すなわち、S309において、ランダムアクセスプロシージャを開始した後、フローを終了する。ここで、なお、該ランダムアクセスプロシージャは、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)のスケジューリングを要求するために開始さ
れる。

0128

S310において、下記3つの処理を行う。その後、S305へ進む。
・(処理S310−1):SR_COUNTERの値をインクリメントする
・(処理S310−2):PUCCHリソースを用いてスケジューリングリクエストをシグナルするよう物理レイヤへ指示する
・(処理S310−3):sr-ProhibitTimerの開始
S311において、下記3つの処理を行う。その後、S312へ進む。
・(処理S311−1):全てのサービングセルに対するPUCCH/SRSリリースするようRRCに通知
・(処理S311−2): 設定された下りリンクアサインメントおよび設定された上り
リンクアサインメントクリア
・(処理S311−3):ランダムアクセスプロシージャを開始する
なお、処理S311−3における該ランダムアクセスプロシージャは、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)のスケジューリングを要求するために開始される。

0129

S312において、フローは終了される。

0130

図14は本実施形態におけるスケジューリングリクエスト送信フローの一例を示す図である。

0131

図14図12に対応するフローの一例である。すなわち、図14は、図12のスケジューリングリクエスト送信の一例に対応するスケジューリングリクエスト送信フローの一例である。

0132

図14は、本実施形態における、サブフレーム(TTI)のそれぞれに対して実行されるスケジューリングリクエストに関する処理の一例を示す図である。図14の処理はMAC層において実行される。端末装置1は、少なくとも1つのスケジューリングリクエストがペンディングしている間、送信のために利用可能なUL−SCHがないサブフレームのそれぞれに対して図14における処理を実行する。尚、具体的な処理は、図14の処理に限られるものではなく、この発明の要旨を逸脱しない範囲でステップの入れ替え/追加/除去等によって変更された処理も含まれる。また、図14の処理は、請求項に示した範囲で種々の変更が可能であり、開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

0133

なお、図14においては、説明のため「第1のリソース」と称している。しかし、該第1のリソースは、第1のsPUCCHリソース、sPUCCHリソース、などに換言することができる。なお、図14においては、説明のため「第2のリソース」と称している。しかし、該第2のリソースは、第2のsPUCCHリソース、PUCCHリソース、などに換言することができる。

0134

以下、図14の詳細について説明する。

0135

S401において、フローは開始される。

0136

S402において、スケジューリングリクエストがトリガされているか否か判断する。S402において、スケジューリングリクエストがトリガされていると判断した場合、S403へ進む。

0137

なお、スケジューリングリクエストがトリガされる場合には、該スケジューリングリクエストがキャンセルされるまで、該スケジューリングリクエストはペンディングであるとみなされる。スケジューリングリクエストがトリガされ、ペンディングしている他のスケジューリングリクエストがない場合には、端末装置1はカウンターSR_COUNTER-rel14を0にセットする。

0138

S403において、ペンディングしている他のスケジューリングリクエストがないか否かを判断する。S403において、ペンディングしている他のスケジューリングリクエストがないと判断した場合、S404へ進む。

0139

S404において、SR_COUNTERは0に設定され、更に、SR_COUNTER-rel14は0に設定される。すなわち、S404において、SR_COUNTER及びSR_COUNTER-rel14は0にリセットされる。S404において、SR_COUNTER及びSR_COUNTER-rel14が0に設定された後、S405へ進む。

0140

S405において、送信のために利用可能なUL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)があるか否かを判断する。S405において、送信のために利用可能なUL−SCHリソースがないと判断された場合、S406へ進む。S405において、送信のために利用可能なUL−SCHリソースがあると判断された場合、S416へ進む。すなわち、S405において、送信のために利用可能なUL−SCHリソースがあると判断された場合、フローを終了する。

0141

S406において、スケジューリングリクエストのための有効な第1のリソースが設定されているか否かを判断する。S406において、スケジューリングリクエストのための有効な第1のリソースが設定されていると判断した場合、S407へ進む。S406において、スケジューリングリクエストのための有効な第1のリソースが設定されていないと判断した場合、S410へ進む。

0142

S407において、該サブフレーム(TTI)が測定ギャップの一部か否かを判断し、更に、sr-ProhibitTimer-rel14がランニングしているか否か判断する。S407において、該サブフレーム(TTI)が測定ギャップの一部ではない、かつ、sr-ProhibitTimer-rel14がランニングしていないと判断した場合、S408へ進む。

0143

S408において、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さいか否か判断する。S408において、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さいと判断された場合、S409へ進む。S408において、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さくないと判断された場合、S410へ進む。すなわち、S408において、SR_COUNTER-rel14の値がdsr-TransMax-rel14と等しいと判断された場合、S410へ進む。すなわち、S408において、SR_COUNTER-rel14の値がdsr-TransMax-rel14より大きいと判断された場合、S410へ進む。

0144

S409において、下記3つの処理を行う。その後、S405へ進む。
・(処理S409−1):SR_COUNTER-rel14の値をインクリメントする
・(処理S409−2):第1のリソースを用いてスケジューリングリクエスト(第1のスケジューリングリクエスト)をシグナルするよう物理レイヤへ指示する
・(処理S409−3):sr-ProhibitTimer-rel14の開始
S410において、スケジューリングリクエストのための有効な第2のリソースが設定されているか否かを判断する。S410において、スケジューリングリクエストのための有効な第2のリソースが設定されていると判断した場合、S411へ進む。S410において、スケジューリングリクエストのための有効な第2のリソースが設定されていないと
判断した場合、S413へ進む。

0145

S411において、該サブフレーム(TTI)が測定ギャップの一部か否かを判断し、更に、sr-ProhibitTimerがランニングしているか否か判断する。S407において、該サブフレーム(TTI)が測定ギャップの一部ではない、かつ、sr-ProhibitTimerがランニングしていないと判断した場合、S412へ進む。なお、S411において、該サブフレーム(TTI)が測定ギャップの一部か否かは判断されなくてもよい。その理由は、S407において、該サブフレーム(TTI)が測定ギャップの一部でないと判断しているためである。

0146

S412において、SR_COUNTERの値がdsr-TransMaxより小さいか否か判断する。S412において、SR_COUNTERの値がdsr-TransMaxより小さいと判断された場合、S414へ進む。S412において、SR_COUNTERの値がdsr-TransMaxより小さくないと判断された場合、S415へ進む。すなわち、S412において、SR_COUNTERの値がdsr-TransMaxと等しいと判断された場合、S415へ進む。すなわち、S412において、SR_COUNTERの値がdsr-TransMaxより大きいと判断された場合、S415へ進む。

0147

S413において、ランダムアクセスプロシージャを開始(initiate)する。S413において、ランダムアクセスプロシージャを開始した後、S416へ進む。すなわち、S413において、ランダムアクセスプロシージャを開始した後、フローを終了する。ここで、なお、該ランダムアクセスプロシージャは、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)のスケジューリングを要求するために開始される。

0148

S414において、下記3つの処理を行う。その後、S405へ進む。
・(処理S414−1):SR_COUNTERの値をインクリメントする
・(処理S414−2):第2のリソースを用いてスケジューリングリクエスト(第2のスケジューリングリクエスト)をシグナルするよう物理レイヤへ指示する
・(処理S414−3):sr-ProhibitTimerの開始
S415において、下記3つの処理を行う。その後、S416へ進む。
・(処理S415−1):全てのサービングセルに対するPUCCH(および/またはsPUCCH)/SRSをリリースするようRRCに通知
・(処理S415−2): 設定された下りリンクアサインメントおよび設定された上り
リンクアサインメントをクリア
・(処理S415−3):ランダムアクセスプロシージャを開始する
なお、処理S415−3における該ランダムアクセスプロシージャは、UL−SCHリソース(例えば、PUSCHのリソース、sPUSCHのリソース)のスケジューリングを要求するために開始される。

0149

S416において、フローは終了される。

0150

図15は本実施形態におけるスケジューリングリクエスト送信に関連する擬似コードの一例を示す図である。

0151

図15図12に対応する擬似コードの一例である。すなわち、図15は、図12のスケジューリングリクエスト送信の一例に対応するスケジューリングリクエスト送信に関連する擬似コードの一例である。

0152

図16は本実施形態におけるスケジューリングリクエスト送信に関連する擬似コードの一例を示す図である。

0153

図16図12に対応する擬似コードの一例である。すなわち、図16は、図12のスケジューリングリクエスト送信の一例に対応するスケジューリングリクエスト送信に関連する擬似コードの一例である。

0154

なお、本実施形態において、PUCCHとsPUCCHのTTI長は異なってもよい。また、なお、本実施形態において、PUCCHとsPUCCHのシンボルは異なってもよい。すなわち、本実施形態において、PUCCHの送信に用いられるサブキャリア間隔とsPUCCHの送信に用いられるサブキャリア間隔は異なってもよい。

0155

本実施形態の端末装置1は、PUCCHおよびPUSCH同時送信が設定されていない。PUCCHおよびPUSCH同時送信が設定されている場合、本実施形態とは異なる処理が適用されてもよい。

0156

以下、本実施形態における、端末装置1および基地局装置3の種々の態様について説明する。

0157

(1)本実施形態の第1の態様は、端末装置1であって、スケジューリングリクエストを送信する送信部と、ランダムアクセスプロシージャを開始する上位層処理部を備え、前記送信部は、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記上位層処理部は、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。

0158

(2)本実施形態の第1の態様において、前記第1のスケジューリングリクエストの最大送信回数と前記第2のスケジューリングリクエストの最大送信回数は、基地局装置から独立に設定される。

0159

(3)本実施形態の第1の態様において、前記第1スケジューリングリクエストと前記第2のスケジューリングリクエストは異なるTTI長で送信される。

0160

(4)前記第1のリソースはsPUCCHのリソースであり、前記第2のリソースはPUCCHのリソースである。

0161

(5)本実施形態の第2の態様は、端末装置1における通信方法であって、スケジューリングリクエストを送信する第1のステップと、ランダムアクセスプロシージャを開始する第2のステップを備え、前記第1のステップは、スケジューリングリクエストのための有効な第1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記第2のステップは、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。

0162

(6)本実施形態の第3の態様は、端末装置1に実装される集積回路であって、スケジューリングリクエストを送信する送信回路と、ランダムアクセスプロシージャを開始する上位層処理回路を備え、前記送信回路は、スケジューリングリクエストのための有効な第
1のリソースを用いて、第1のスケジューリングリクエストを送信し、前記第1のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第2のリソースを用いて、第2のスケジューリングリクエストを送信し、前記上位層処理回路は、前記第2のスケジューリングリクエストの送信に基づいてUL−SCHリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。

0163

これにより、端末装置は効率的に上りリンク制御情報を送信することができる。また、基地局装置は効率的に上りリンク制御情報を受信することができる。

0164

本発明に関わる基地局装置3、および端末装置1で動作するプログラムは、本発明に関わる上記実施形態の機能を実現するように、CPU(Central Processing Unit)等を制
御するプログラム(コンピュータを機能させるプログラム)であっても良い。そして、これら装置で取り扱われる情報は、その処理時に一時的にRAM(Random Access Memory)に蓄積され、その後、Flash ROM(Read Only Memory)などの各種ROMやHD
D(Hard Disk Drive)に格納され、必要に応じてCPUによって読み出し修正・書き
込みが行われる。

0165

尚、上述した実施形態における端末装置1、基地局装置3の一部、をコンピュータで実現するようにしても良い。その場合、この制御機能を実現するためのプログラムをコンピュータが読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現しても良い。

0166

尚、ここでいう「コンピュータシステム」とは、端末装置1、又は基地局装置3に内蔵されたコンピュータシステムであって、OSや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク光磁気ディスク、ROM、CD−ROM等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。

0167

さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワーク電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

0168

また、上述した実施形態における基地局装置3は、複数の装置から構成される集合体(装置グループ)として実現することもできる。装置グループを構成する装置の各々は、上述した実施形態に関わる基地局装置3の各機能または各機能ブロックの一部、または、全部を備えてもよい。装置グループとして、基地局装置3の一通りの各機能または各機能ブロックを有していればよい。また、上述した実施形態に関わる端末装置1は、集合体としての基地局装置と通信することも可能である。

0169

また、上述した実施形態における基地局装置3は、EUTRAN(Evolved Universal Terrestrial Radio Access Network)であってもよい。また、上述した実施形態における基地局装置3は、eNodeBに対する上位ノードの機能の一部または全部を有してもよい。

0170

また、上述した実施形態における端末装置1、基地局装置3の一部、又は全部を典型的
には集積回路であるLSIとして実現してもよいし、チップセットとして実現してもよい。端末装置1、基地局装置3の各機能ブロックは個別にチップ化してもよいし、一部、又は全部を集積してチップ化してもよい。また、集積回路化の手法はLSIに限らず専用回路、又は汎用プロセッサで実現しても良い。また、半導体技術の進歩によりLSIに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いることも可能である。

0171

また、上述した実施形態では、通信装置の一例として端末装置を記載したが、本願発明は、これに限定されるものではなく、屋内外に設置される据え置き型、または非可動型電子機器、たとえば、AV機器キッチン機器掃除洗濯機器空調機器オフィス機器自動販売機、その他生活機器などの端末装置もしくは通信装置にも適用出来る。

0172

以上、この発明の実施形態に関して図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。また、本発明は、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。また、上記各実施形態に記載された要素であり、同様の効果を奏する要素同士を置換した構成も含まれる。

0173

1(1A、1B、1C)端末装置
3基地局装置
101 上位層処理部
103 制御部
105 受信部
107 送信部
301 上位層処理部
303 制御部
305 受信部
307 送信部
1011無線リソース制御部
1013スケジューリング部
3011 無線リソース制御部
3013 スケジューリング部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ