JP2019125815A - 端末装置、通信方法、および、集積回路 - Google Patents

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

Info

Publication number
JP2019125815A
JP2019125815A JP2016096127A JP2016096127A JP2019125815A JP 2019125815 A JP2019125815 A JP 2019125815A JP 2016096127 A JP2016096127 A JP 2016096127A JP 2016096127 A JP2016096127 A JP 2016096127A JP 2019125815 A JP2019125815 A JP 2019125815A
Authority
JP
Japan
Prior art keywords
scheduling request
resource
transmission
unit
valid
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2016096127A
Other languages
English (en)
Inventor
林　貴志
Takashi Hayashi
貴志 林
翔一 鈴木
Shoichi Suzuki
翔一 鈴木
立志 相羽
Tateshi Aiba
立志 相羽
渉 大内
Wataru Ouchi
渉 大内
友樹 吉村
Tomoki Yoshimura
友樹 吉村
麗清 劉
Liqing Liu
麗清 劉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Original Assignee
Sharp Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sharp Corp filed Critical Sharp Corp
Priority to JP2016096127A priority Critical patent/JP2019125815A/ja
Priority to PCT/JP2017/016741 priority patent/WO2017195623A1/ja
Publication of JP2019125815A publication Critical patent/JP2019125815A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

【課題】効率的に上りリンク制御情報を伝送することができる【解決手段】端末装置は、スケジューリングリクエストのための有効な第１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。【選択図】図１２

Description

本発明は、端末装置、通信方法、および、集積回路に関する。
セルラー移動通信の無線アクセス方式および無線ネットワーク（以下、「Long Term Evolution （LTE）」、または、「Evolved Universal Terrestrial Radio Access : EUTRA
」と称する。）が、第三世代パートナーシッププロジェクト（3rd Generation Partnership Project: 3GPP）において検討されている。ＬＴＥでは、基地局装置をｅＮｏｄｅＢ（evolved NodeB）、端末装置をＵＥ（User Equipment）とも称する。ＬＴＥは、基地局装
置がカバーするエリアをセル状に複数配置するセルラー通信システムである。単一の基地局装置は複数のセルを管理してもよい。
ＬＴＥリリース１３において、ＰＵＳＣＨおよびＰＵＣＣＨが上りリンク制御情報が伝送することが仕様化されている（非特許文献１、２、３、４）。非特許文献５において、ＴＴＩ（Transmission Time Interval）の短縮、および、処理時間の削減について検討されている。非特許文献６において、ｓＰＵＣＣＨ、および、ｓＰＵＳＣＨがチャネル状態情報およびＨＡＲＱ−ＡＣＫ（Hybrid Automatic Repeat reQuest-ACKnowledgement）を
伝送することが検討されている。
"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 for LTE", 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.
本発明は、効率的に上りリンク制御情報を送信することができる端末装置、該端末装置に用いられる通信方法、該端末装置に実装される集積回路、効率的に上りリンク制御情報を受信することができる基地局装置、該基地局装置に用いられる通信方法、および、該基地局装置に実装される集積回路を提供する。
（１）本発明の態様は、以下のような手段を講じた。すなわち、本発明の第１の態様は、端末装置であって、スケジューリングリクエストを送信する送信部と、ランダムアクセスプロシージャを開始する上位層処理部を備え、前記送信部は、スケジューリングリクエストのための有効な第１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、前記上位層処理部は、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなか
った場合、ランダムアクセスプロシージャを開始する。
（２）本発明の第２の態様は、端末装置に用いられる通信方法であって、スケジューリングリクエストを送信する第１のステップと、ランダムアクセスプロシージャを開始する第２のステップを備え、前記第１のステップは、スケジューリングリクエストのための有効な第１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、前記第２のステップは、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。
（３）本発明の第５の態様は、端末装置に実装される集積回路であって、スケジューリングリクエストを送信する送信回路と、ランダムアクセスプロシージャを開始する上位層処理回路を備え、前記送信回路は、スケジューリングリクエストのための有効な第１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、前記上位層処理回路は、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。
この発明によれば、端末装置は効率的に上りリンク制御情報を送信することができる。また、基地局装置は効率的に上りリンク制御情報を受信することができる。
本実施形態の無線通信システムの概念図である。 本実施形態の無線フレームの概略構成を示す図である。 本実施形態における上りリンクスロットの概略構成を示す図である。 本実施形態におけるＴＴＩおよびｓＴＴＩの一例を示す図である。 本実施形態の下りリンクにおける物理チャネルの割り当ての一例を示す図である。 本実施形態の上りリンクにおける物理チャネルの割り当ての一例を示す図である。 本発明における端末装置１の構成を示す概略ブロック図である。 本発明における符号化部１０７１の構成を示す概略ブロック図である。 本実施形態における符号化変調シンボルのインタリーブの方法の一例を示す図で第ある。 本発明における基地局装置３の構成を示す概略ブロック図である。 本実施形態におけるスケジューリングリクエスト送信の一例を示す図である。 本実施形態におけるスケジューリングリクエスト送信の一例を示す図である。 本実施形態におけるスケジューリングリクエスト送信フローの一例を示す図である。 本実施形態におけるスケジューリングリクエスト送信フローの一例を示す図である。 本実施形態におけるスケジューリングリクエスト送信に関連する擬似コードの一例を示す図である。 本実施形態におけるスケジューリングリクエスト送信に関連する擬似コードの一例を示す図である。
以下、本発明の実施形態について説明する。
図１は、本実施形態の無線通信システムの概念図である。図１において、無線通信システムは、端末装置１Ａ〜１Ｃ、および基地局装置３を具備する。以下、端末装置１Ａ〜１Ｃを端末装置１という。
以下、キャリアアグリゲーションについて説明する。
本実施形態では、端末装置１は、複数のサービングセルが設定される。端末装置１が複数のサービングセルを介して通信する技術をセルアグリゲーション、またはキャリアアグリゲーションと称する。端末装置１に対して設定される複数のサービングセルのそれぞれにおいて、本発明が適用されてもよい。また、設定された複数のサービングセルの一部において、本発明が適用されてもよい。また、設定された複数のサービングセルのグループのそれぞれにおいて、本発明が適用されてもよい。また、設定された複数のサービングセルのグループの一部において、本発明が適用されてもよい。
複数のサービングセルは、少なくとも１つのプライマリセルを含む。複数のサービングセルは、１つ、または、複数のセカンダリセルを含んでもよい。プライマリセルは、初期コネクション確立（initial connection establishment）手順が行なわれたサービングセル、コネクション再確立（connection re-establishment）手順を開始したサービングセ
ル、または、ハンドオーバ手順においてプライマリセルと指示されたセルである。ＲＲＣ（Radio Resource Control）コネクションが確立された時点、または、後に、セカンダリセルが設定されてもよい。
下りリンクにおいて、サービングセルに対応するキャリアを下りリンクコンポーネントキャリアと称する。上りリンクにおいて、サービングセルに対応するキャリアを上りリンクコンポーネントキャリアと称する。下りリンクコンポーネントキャリア、および、上りリンクコンポーネントキャリアを総称して、コンポーネントキャリアと称する。
端末装置１は、複数のサービングセル（コンポーネントキャリア）において同時に複数の物理チャネルでの送信、および／または受信を行うことができる。１つの物理チャネルは、複数のサービングセル（コンポーネントキャリア）のうち１つのサービングセル（コンポーネントキャリア）において送信される。
本実施形態の物理チャネルおよび物理信号について説明する。
図１において、端末装置１から基地局装置３への上りリンクの無線通信では、以下の上りリンク物理チャネルが用いられる。上りリンク物理チャネルは、上位層から出力された情報を送信するために使用される。
・ＰＵＣＣＨ（Physical Uplink Control Channel）
・ｓＰＵＣＣＨ（shortened Physical Uplink Control Channel）
・ＰＵＳＣＨ（Physical Uplink Shared Channel）
・ｓＰＵＳＣＨ（shortened Physical Uplink Shared Channel）
ＰＵＣＣＨ、および、ｓＰＵＣＣＨは、上りリンク制御情報（Uplink Control Information: UCI）を送信するために用いられる。本実施形態において、端末装置１は、プライ
マリセルのみにおいてＰＵＣＣＨの送信を行ってもよい。上りリンク制御情報は、下りリ
ンクのチャネル状態情報（Channel State Information: CSI）、ＰＵＳＣＨリソースの要求を示すスケジューリング要求（Scheduling Request: SR）、下りリンクデータ（Transport block, Medium Access Control Protocol Data Unit: MAC PDU, Downlink-Shared Channel: DL-SCH, Physical Downlink Shared Channel: PDSCH）に対するＨＡＲＱ−ＡＣＫ（Hybrid Automatic Repeat request ACKnowledgement）を含む。ＨＡＲＱ−ＡＣＫは、
ＡＣＫ（acknowledgement）またはＮＡＣＫ（negative-acknowledgement）を示す。ＨＡ
ＲＱ−ＡＣＫを、ＡＣＫ／ＮＡＣＫ、ＨＡＲＱフィードバック、ＨＡＲＱ−ＡＣＫフィードバック、ＨＡＲＱ応答、ＨＡＲＱ−ＡＣＫ応答、ＨＡＲＱ情報、ＨＡＲＱ−ＡＣＫ情報、ＨＡＲＱ制御情報、および、ＨＡＲＱ−ＡＣＫ制御情報とも称する。
ＰＵＳＣＨ、および、ｓＰＵＳＣＨは、上りリンクデータ（Transport block, Medium Access Control Protocol Data Unit: MAC PDU, Uplink-Shared Channel: UL-SCH）を送
信するために用いられてもよい。ＰＵＳＣＨは、上りリンクデータと共にＨＡＲＱ−ＡＣＫおよび／またはチャネル状態情報を送信するために用いられてもよい。また、ＰＵＳＣＨはチャネル状態情報のみ、または、ＨＡＲＱ−ＡＣＫおよびチャネル状態情報のみを送信するために用いられてもよい。
非周期的なチャネル状態情報報告は、ＰＵＳＣＨ／ｓＰＵＳＣＨ送信に対応する上りリンクグラントに含まれるフィールドによってトリガされる。周期的なチャネル状態情報報告は、ＲＲＣシグナリング（上位層のパラメータ）によってトリガされる。非周期的なチャネル状態情報報告のために、ＰＵＳＣＨが用いられる。周期的なチャネル状態情報報告のために、ＰＵＳＣＨまたはＰＵＣＣＨが用いられる。
図１において、基地局装置３から端末装置１への下りリンクの無線通信では、以下の下りリンク物理チャネルが用いられる。下りリンク物理チャネルは、上位層から出力された情報を送信するために使用される。
・ＰＤＣＣＨ（Physical Downlink Control Channel）
・ＥＰＤＣＣＨ（Enhanced Physical Downlink Control Channel）
・ｓＰＤＣＣＨ（shortened Physical Downlink Control Channel）
・ＰＤＳＣＨ（Physical Downlink Shared Channel）
・ｓＰＤＳＣＨ（shortened Physical Downlink Shared Channel）
ＰＤＣＣＨ、ＥＰＤＣＣＨ、および、ｓＰＤＣＣＨは、下りリンク制御情報（Downlink
Control Information: DCI）を送信するために用いられる。下りリンク制御情報を、Ｄ
ＣＩフォーマットとも称する。下りリンク制御情報は、下りリンクグラント（downlink grant）および上りリンクグラント（uplink grant）を含む。下りリンクグラントは、下りリンクアサインメント（downlink assignment）または下りリンク割り当て（downlink allocation）とも称する。
１つの下りリンクグラントは、１つのセル内の１つのＰＤＳＣＨのスケジューリングに用いられてもよい。下りリンクグラントは、該下りリンクグラントが送信されたサブフレームと同じサブフレーム内のＰＤＳＣＨのスケジューリングに用いられてもよい。１つの下りリンクグラントは、１つのセル内の１つのｓＰＤＳＣＨのスケジューリングに用いられてもよい。下りリンクグラントは、該下りリンクグラントが送信されたｓＴＴＩ（shortened Transmission Time Interval）と同じｓＴＴＩ内のｓＰＤＳＣＨのスケジューリングに用いられてもよい。
１つの上りリンクグラントは、１つのセル内の１つのＰＵＳＣＨのスケジューリングに用いられてもよい。上りリンクグラントは、該上りリンクグラントが送信されたサブフレームより４つ以上後のサブフレーム内の１つのＰＵＳＣＨのスケジューリングに用いられてもよい。１つの上りリンクグラントは、１つのセル内の１つのｓＰＵＳＣＨのスケジュ
ーリングに用いられてもよい。上りリンクグラントは、該上りリンクグラントが送信されたｓＴＴＩより後のｓＴＴＩ内の１つのｓＰＵＳＣＨのスケジューリングに用いられてもよい。
ＰＤＳＣＨ、および、ｓＰＤＳＣＨは、下りリンクデータ（Downlink Shared Channel:
DL-SCH）を送信するために用いられる。
ＵＬ−ＳＣＨおよびＤＬ−ＳＣＨは、トランスポートチャネルである。媒体アクセス制御（Medium Access Control: MAC）層で用いられるチャネルをトランスポートチャネルと称する。ＭＡＣ層で用いられるトランスポートチャネルの単位を、トランスポートブロック（transport block: TB）またはＭＡＣ ＰＤＵ（Protocol Data Unit）とも称する。
ＭＡＣ層においてトランスポートブロック毎にＨＡＲＱ（Hybrid Automatic Repeat reQuest）の制御が行なわれる。トランスポートブロックは、ＭＡＣ層が物理層に渡す（deliver）データの単位である。物理層において、トランスポートブロックはコードワードにマップされ、コードワード毎に変調処理、および、符号化処理が行なわれる。１つのコードワードは、１つ、または、複数のレイヤにマップされる。
以下、本実施形態の無線フレーム（radio frame）の構成の一例について説明する。図
２は、本実施形態の無線フレームの概略構成を示す図である。無線フレームのそれぞれは、１０ｍｓ長である。図２において、横軸は時間軸である。また、無線フレームのそれぞれは１０のサブフレームから構成される。サブフレームのそれぞれは、１ｍｓ長であり、２つの連続するスロットによって定義される。スロットのそれぞれは、０．５ｍｓ長である。つまり、１０ｍｓ間隔のそれぞれにおいて、１０個のサブフレームが利用できる。サブフレームをＴＴＩ（Transmission Time Intervalとも称する。）
以下、本実施形態のスロットの構成の一例について説明する。図３は、本実施形態における上りリンクスロットの概略構成を示す図である。図３において、１つのセルにおける上りリンクスロットの構成を示す。図３において、横軸は時間軸であり、縦軸は周波数軸である。図３において、ｌはＳＣ−ＦＤＭＡシンボル番号／インデックスであり、ｋはサブキャリア番号／インデックスである。
スロットのそれぞれにおいて送信される物理シグナルまたは物理チャネルは、リソースグリッドによって表現される。上りリンクにおいて、リソースグリッドは複数のサブキャリアと複数のＳＣ−ＦＤＭＡシンボルによって定義される。リソースグリッド内のエレメントのそれぞれをリソースエレメントと称する。リソースエレメントは、サブキャリア番号／インデックスｋ、および、ＳＣ−ＦＤＭＡシンボル番号／インデックスｌによって表される。
上りリンクスロットは、時間領域において、複数のＳＣ−ＦＤＭＡシンボルｌ（l=0,1,…,NUL symb）を含む。NUL symbは、１つの上りリンクスロットに含まれるＳＣ−ＦＤＭＡ
シンボルの数を示す。上りリンクにおけるノーマルＣＰ（normal Cyclic Prefix）に対して、NUL symbは７である。上りリンクにおける拡張ＣＰ（extended ＣＰ）に対して、NUL symbは６である。
端末装置１は、上りリンクにおけるＣＰ長を示すパラメータUL-CyclicPrefixLengthを
基地局装置３から受信する。基地局装置３は、セルに対応する該パラメータUL-CyclicPrefixLengthを含むシステムインフォメーションを、該セルにおいて報知してもよい。
上りリンクスロットは、周波数領域において、複数のサブキャリアｋ（k=0,1,…,NUL RB×NRB sc)を含む。NUL RBは、NRB scの倍数によって表現される、サービングセルに対する上りリンク帯域幅設定である。NRB scは、サブキャリアの数によって表現される、周波数領
域における（物理）リソースブロックサイズである。サブキャリア間隔Δfは１５ｋＨｚ
であり、NRB scは１２であってもよい。すなわち、NRB scは、１８０ｋＨｚであってもよい。サブキャリア間隔Δfはチャネル毎、および／または、ＴＴＩ／ｓＴＴＩ毎に異なって
もよい。
リソースブロックは、物理チャネルのリソースエレメントへのマッピングを表すために用いられる。リソースブロックは、仮想リソースブロックと物理リソースブロックが定義される。物理チャネルは、まず仮想リソースブロックにマップされる。その後、仮想リソースブロックは、物理リソースブロックにマップされる。１つの物理リソースブロックは、時間領域においてNUL symbの連続するＳＣ−ＦＤＭＡシンボルと周波数領域においてNRB scの連続するサブキャリアとから定義される。ゆえに、１つの物理リソースブロックは（NUL symb×NRB sc）のリソースエレメントから構成される。１つの物理リソースブロックは、時間領域において１つのスロットに対応する。物理リソースブロックは周波数領域において、周波数の低いほうから順に番号（0,1,…, NUL RB-1）が付けられる。
本実施形態における下りリンクのスロットは、複数のＯＦＤＭシンボルを含む。本実施形態における下りリンクのスロットの構成は、リソースグリッドが複数のサブキャリアと複数のＯＦＤＭシンボルによって定義される
点を除いて基本的に同じであるため、下りリンクのスロットの構成の説明は省略する。
図４は、本実施形態におけるＴＴＩおよびｓＴＴＩの一例を示す図である。ＴＴＩは、２×NUL symbのＳＣ−ＦＤＭＡシンボルから構成されてもよい。ｓＴＴＩを構成するＳＣ
−ＦＤＭＡシンボルの数は、｛２、３、４、７｝の何れかである。ＸのＳＣ−ＦＤＭＡシンボルから構成されるＴＴＩ／ｓＴＴＩをＸシンボルＴＴＩとも称する。下りリンクにおいて、ＴＴＩ、および、ｓＴＴＩは、複数のＯＦＤＭシンボルから構成されてもよい。
図５は、本実施形態の下りリンクにおける物理チャネルの割り当ての一例を示す図である。
ｓＰＵＣＣＨの長さ、および、ｓＰＵＳＣＨの長さは個別に制御されてもよい。ｓＰＵＣＣＨで伝送される情報に基づいて、ｓＰＵＣＣＨの長さが決定されてもよい。ｓＰＵＳＣＨで伝送される情報に基づいて、ｓＰＵＣＳＨの長さが決定されてもよい。
図６は、本実施形態の上りリンクにおける物理チャネルの割り当ての一例を示す図である。ＰＵＣＣＨ６００、６０１、および、ｓＰＵＣＣＨ６０２−６０５に対して、周波数ホッピングが適用される。サブフレーム／ＴＴＩにおいて、ＰＵＳＣＨ、および、ＰＵＣＣＨは、２×NUL symbのＳＣ−ＦＤＭＡシンボルにマップされてもよい。４シンボルＴＴ
Ｉにおいて、ｓＰＵＳＣＨは４つのＳＣ−ＦＤＭＡシンボルにマップされてもよい。３シンボルＴＴＩにおいて、ｓＰＵＳＣＨは３つのＳＣ−ＦＤＭＡシンボルにマップされてもよい。７シンボルＴＴＩにおいて、ｓＰＵＣＣＨは７つのＳＣ−ＦＤＭＡシンボルにマップされてもよい。ＸシンボルＴＴＩにおけるＸのＳＣ−ＦＤＭＡシンボルにマップされるｓＰＵＳＣＨを、ＸシンボルｓＰＵＳＣＨとも称する。ＸシンボルＴＴＩにおけるＸのＳＣ−ＦＤＭＡシンボルにマップされるｓＰＵＣＣＨを、ＸシンボルｓＰＵＣＣＨとも称する。
以下、本発明の端末装置１の装置構成について説明する。
図７は、本発明における端末装置１の構成を示す概略ブロック図である。図示するように、端末装置１は、上位層処理部１０１、制御部１０３、受信部１０５、送信部１０７および、送受信アンテナ１０９を含んで構成される。上位層処理部１０１は、無線リソース
制御部１０１１、スケジューリング部１０１３を含んで構成される。受信部１０５は、復号化部１０５１、復調部１０５３、多重分離部１０５５、無線受信部１０５７とチャネル測定部１０５９を含んで構成される。送信部１０７は、符号化部１０７１、ＰＵＳＣＨ生成部１０７３、ＰＵＣＣＨ生成部１０７５、多重部１０７７、無線送信部１０７９と上りリンク参照信号生成部１０７１１を含んで構成される。
上位層処理部１０１は、ユーザの操作等により生成された上りリンクデータを、送信部１０７に出力する。また、上位層処理部１０１は、媒体アクセス制御（MAC: Medium Access Control）層、パケットデータ統合プロトコル（Packet Data Convergence Protocol: PDCP）層、無線リンク制御（Radio Link Control: RLC）層、無線リソース制御（Radio Resource Control: RRC）層の処理を行なう。また、上位層処理部１０１はＰＤＣＣＨで受信された下りリンク制御情報などに基づき、受信部１０５、および送信部１０７の制御を行なうために制御情報を生成し、制御部１０３に出力する。
上位層処理部１０１が備える無線リソース制御部１０１１は、自装置の各種設定情報の管理を行なう。例えば、無線リソース制御部１０１１は、設定されたサービングセルの管理を行なう。また、無線リソース制御部１０１１は、上りリンクの各チャネルに配置される情報を生成し、送信部１０７に出力する。無線リソース制御部１０１１は、受信した下りリンクデータの復号に成功した場合には、ＡＣＫを生成し送信部１０７にＡＣＫを出力し、受信した下りリンクデータの復号に失敗した場合には、ＮＡＣＫを生成し、送信部１０７にＮＡＣＫを出力する。
上位層処理部１０１が備えるスケジューリング部１０１３は、受信部１０５を介して受信した下りリンク制御情報を記憶する。スケジューリング部１０１３は、上りリンクグラントを受信したサブフレームから４つ後のサブフレームにおいて、受信された上りリンクグラントに従ってＰＵＳＣＨを送信するよう、制御部１０３を介して送信部１０７を制御する。スケジューリング部１０１３は、下りリンクグラントを受信したサブフレームにおいて、受信された下りリンクグラントに従ってＰＤＳＣＨを受信するよう、制御部１０３を介して受信部１０５を制御する。
制御部１０３は、上位層処理部１０１からの制御情報に基づいて、受信部１０５、および送信部１０７の制御を行なう制御信号を生成する。制御部１０３は、生成した制御信号を受信部１０５、および送信部１０７に出力して受信部１０５、および送信部１０７の制御を行なう。
受信部１０５は、制御部１０３から入力された制御信号に従って、送受信アンテナ１０９を介して基地局装置３から受信した受信信号を、分離、復調、復号し、復号した情報を上位層処理部１０１に出力する。
無線受信部１０５７は、送受信アンテナ１０９を介して受信した下りリンクの信号を直交復調し、直交復調されたアナログ信号をディジタル信号に変換する。無線受信部１０５７は、ディジタル信号に対して高速フーリエ変換（Fast Fourier Transform: FFT）を行
い、周波数領域の信号を抽出する。
多重分離部１０５５は、抽出した信号をＰＤＣＣＨ、ＰＤＳＣＨ、および下りリンク参照信号に、それぞれ分離する。多重分離部１０５５は、分離した下りリンク参照信号をチャネル測定部１０５９に出力する。
復調部１０５３は、ＰＤＣＣＨ、および、ＰＤＳＣＨに対して、ＱＰＳＫ、１６ＱＡＭ（Quadrature Amplitude Modulation）、６４ＱＡＭ等の変調方式に対する復調を行ない
、復号化部１０５１へ出力する。
復号化部１０５１は、下りリンクデータの復号を行い、復号した下りリンクデータを上位層処理部１０１へ出力する。チャネル測定部１０５９は、下りリンク参照信号から下りリンクの伝搬路の推定値を算出し、多重分離部１０５５へ出力する。チャネル測定部１０５９は、チャネル状態情報を算出し、尚且つ、チャネル状態情報を上位層処理部１０１へ出力する
送信部１０７は、制御部１０３から入力された制御信号に従って、上りリンク参照信号を生成し、上位層処理部１０１から入力された上りリンクデータや上りリンク制御情報を符号化および変調し、ＰＵＣＣＨ、ＰＵＳＣＨ、および生成した上りリンク参照信号を多重し、送受信アンテナ１０９を介して基地局装置３に送信する。
符号化部１０７１は、上位層処理部１０１から入力された上りリンク制御情報と上りリンクデータを符号化し、符号化ビットをＰＵＳＣＨ生成部および／またはＰＵＣＣＨ生成部に出力する。
図８は、本発明における符号化部１０７１の構成を示す概略ブロック図である。符号化部１０７１は、データ符号化部１０７１ａ、チャネル状態情報符号化部１０７１ｂ、ＨＡＲＱ−ＡＣＫ符号化部１０７１ｃ、および、多重・インタリーブ部１０７１ｄを含む。
データ符号化部１０７１ａは、上位層１０１から入力された上りリンクデータａｉに上りリンクデータから生成されたＣＲＣパリティビットを付加し、当該ＣＲＣパリティビットが付加された上りリンクデータに誤り訂正符号化を適用し、上りリンクデータの符号化ビットｆｉを多重・インタリーブ部１０７１ｄへ出力する。Ａは上りリンクデータのペイロードサイズ（ビット数）である。Ｆは上りリンクデータの符号化ビット数である。
チャネル状態情報符号化部１０７１ｂは、チャネル状態情報ｏｉを符号化する。チャネル状態情報がＰＵＳＣＨを用いて送信される場合、チャネル状態情報符号化部１０７１ｂは、チャネル状態情報の符号化ビットｑiを多重・インタリーブ部１０７１ｄへ出力する
。チャネル状態情報がＰＵＣＣＨを用いて送信される場合、チャネル状態情報符号化部１０７１ｂは、チャネル状態情報の符号化ビットｑiをＰＵＣＣＨ生成部１０７５へ出力す
る。Ｏはチャネル状態情報のビット数である。Ｑはチャネル状態情報の符号化ビット数である。
ＨＡＲＱ−ＡＣＫ符号化部１０７１ｃは、ＨＡＲＱ−ＡＣＫｂｉを符号化する。ＨＡＲＱ−ＡＣＫがＰＵＳＣＨを用いて送信される場合、ＨＡＲＱ−ＡＣＫ符号化部１０７１ｃは、ＨＡＲＱ−ＡＣＫの符号化ビットｇiを多重・インタリーブ部１０７１ｄへ出力する
。ＨＡＲＱ−ＡＣＫがＰＵＣＣＨを用いて送信される場合、ＨＡＲＱ−ＡＣＫ符号化部１０７１ｃは、ＨＡＲＱ−ＡＣＫの符号化ビットｇiをＰＵＣＣＨ生成部１０７５へ出力す
る。ＢはＨＡＲＱ−ＡＣＫのビット数である。ＧはＨＡＲＱ−ＡＣＫの符号化ビット数である。
符号化部１０７１は、ＳＲをＰＵＣＣＨ生成部１０７５へ出力する。
多重・インタリーブ部１０７１ｄは、上りリンクデータの符号化ビットｆi、チャネル
状態情報の符号化ビットｑi、および／または、ＨＡＲＱ−ＡＣＫの符号化ビットｇiを多重およびインタリーブし、連結された符号化ビットｈiをＰＵＳＣＨ生成部１０７３へ出
力する。
図９は、本実施形態における符号化変調シンボルのインタリーブの方法の一例を示す図
である。符号化変調シンボルは、符号化ビットのグループである。１つの符号化シンボルが変調されることによって１つの変調シンボルが生成される。１つの符号化変調シンボルは、上りリンクデータに対する変調方式の変調次数Ｑｍと同じ数の符号化ビットを含む。
図９において、ＰＵＳＣＨ／ｓＰＵＳＣＨがマップされるＳＣ−ＦＤＭＡシンボルの数と同じ数の列がある。ただし、４番目のＳＣ−ＦＤＭＡシンボルは上りリンク参照信号の送信のために用いられるため、４列目に符号化変調シンボルは配置されない。図９において、上りリンクグラントによって割り当てを示されたＰＵＳＣＨ／ｓＰＵＳＣＨのサブキャリアの数と同じ数の行がある。
ＰＵＳＣＨ信号生成部１０７３において、図９の同一の列に配置される符号化変調シンボルに対応する複数の変調シンボルは、ともに離散フーリエ変換（Transform Precoding
）され、ＤＦＴされた信号は上りリンクグラントによって無線リソースの割り当てを示されたＰＵＳＣＨ／ｓＰＵＳＣＨのリソースエレメントに配置される。ｉ列目の符号化シンボルから生成されたＤＦＴされた信号はｉ番目のＳＣ−ＦＤＭＡシンボルに対応するリソースエレメントに配置される。
ＰＵＳＣＨ生成部１０７３は、符号化部１０７１から入力された符号化ビットｈiを変
調して変調シンボルを生成し、変調シンボルをＤＦＴすることによってＰＵＳＣＨ／ｓＰＵＳＣＨの信号を生成し、尚且つ、ＤＦＴされたＰＵＳＣＨ／ｓＰＵＳＣＨの信号を多重部１０７７へ出力する。
ＰＵＣＣＨ生成部１０７５は、符号化部１０７１から入力された符号化ビットqi／gi、および／または、ＳＲに基づいて、ＰＵＣＣＨ／ｓＰＵＣＣＨの信号を生成し、生成したＰＵＣＣＨ／ｓＰＵＣＣＨの信号を多重部１０７７へ出力する。
上りリンク参照信号生成部１０７１１は上りリンク参照信号を生成し、生成した上りリンク参照信号を多重部１０７７へ出力する。
多重部１０７５は、制御部１０３から入力された制御信号に従って、ＰＵＳＣＨ生成部１０７３から入力された信号および／またはＰＵＣＣＨ生成部か１０７５ら入力された信号、および／または、上りリンク参照信号生成部１０７１１から入力された上りリンク参照信号を、送信アンテナポート毎に上りリンクのリソースエレメントに多重する。
無線送信部１０７７は、多重された信号を逆高速フーリエ変換（Inverse Fast Fourier
Transform: IFFT）して、ＳＣ−ＦＤＭＡ方式の変調を行い、ベースバンドのディジタル信号を生成し、ベースバンドのディジタル信号をアナログ信号に変換し、アナログ信号から中間周波数の同相成分および直交成分を生成し、中間周波数帯域に対する余分な周波数成分を除去し、中間周波数の信号を高周波数の信号に変換（アップコンバート: up convert）し、余分な周波数成分を除去し、電力増幅し、送受信アンテナ１０９に出力して送信する。
以下、本発明の基地局装置３の装置構成について説明する。
図１０は、本発明における基地局装置３の構成を示す概略ブロック図である。図示するように、基地局装置３は、上位層処理部３０１、制御部３０３、受信部３０５、送信部３０７、および、送受信アンテナ３０９、を含んで構成される。また、上位層処理部３０１は、無線リソース制御部３０１１とスケジューリング部３０１３を含んで構成される。また、受信部３０５は、データ復調／復号部３０５１、制御情報復調／復号部３０５３、多重分離部３０５５、無線受信部３０５７とチャネル測定部３０５９を含んで構成される。
また、送信部３０７は、符号化部３０７１、変調部３０７３、多重部３０７５、無線送信部３０７７と下りリンク参照信号生成部３０７９を含んで構成される。
上位層処理部３０１は、媒体アクセス制御（MAC: Medium Access Control）層、パケットデータ統合プロトコル（Packet Data Convergence Protocol: PDCP）層、無線リンク制御（Radio Link Control: RLC）層、無線リソース制御（Radio Resource Control: RRC）層の処理を行なう。また、上位層処理部３０１は、受信部３０５、および送信部３０７の制御を行なうために制御情報を生成し、制御部３０３に出力する。
上位層処理部３０１が備える無線リソース制御部３０１１は、下りリンクのＰＤＳＣＨに配置される下りリンクデータ、ＲＲＣシグナル、ＭＡＣ ＣＥ（Control Element）を
生成し、又は上位ノードから取得し、ＨＡＲＱ制御部３０１３に出力する。また、無線リソース制御部３０１１は、移動局装置１各々の各種設定情報の管理をする。例えば、無線リソース制御部３０１１は、移動局装置１に設定したサービングセルの管理などを行なう。
上位層処理部３０１が備えるスケジューリング部３０１３は、移動局装置１に割り当てるＰＵＳＣＨやＰＵＣＣＨの無線リソースの管理をしている。スケジューリング部３０１３は、移動局装置１にＰＵＳＣＨの無線リソースを割り当てた場合には、ＰＵＳＣＨの無線リソースの割り当てを示す上りリンクグラントを生成し、生成した上りリンクグラントを送信部３０７へ出力する。
制御部３０３は、上位層処理部３０１からの制御情報に基づいて、受信部３０５、および送信部３０７の制御を行なう制御信号を生成する。制御部３０３は、生成した制御信号を受信部３０５、および送信部３０７に出力して受信部３０５、および送信部３０７の制御を行なう。
受信部３０５は、制御部３０３から入力された制御信号に従って、送受信アンテナ３０９を介して移動局装置１から受信した受信信号を分離、復調、復号し、復号した情報を上位層処理部３０１に出力する。
無線受信部３０５７は、送受信アンテナ３０９を介して受信された上りリンクの信号を直交復調し、直交復調されたアナログ信号をディジタル信号に変換する。無線受信部３０５７は、ディジタル信号に対して高速フーリエ変換（Fast Fourier Transform: FFT）を
行い、周波数領域の信号を抽出し多重分離部３０５５に出力する。
多重分離部１０５５は、無線受信部３０５７から入力された信号をＰＵＣＣＨ、ＰＵＳＣＨ、上りリンク参照信号などの信号に分離する。尚、この分離は、予め基地局装置３が無線リソース制御部３０１１で決定し、各移動局装置１に通知した上りリンクグラントに含まれる無線リソースの割り当て情報に基づいて行なわれる。多重分離部３０５５は、チャネル測定部３０５９から入力された伝搬路の推定値から、ＰＵＣＣＨとＰＵＳＣＨの伝搬路の補償を行なう。また、多重分離部３０５５は、分離した上りリンク参照信号をチャネル測定部３０５９に出力する。
多重分離部３０５５は、分離したＰＵＣＣＨとＰＵＳＣＨの信号から、上りリンクデータの変調シンボルと上りリンク制御情報（ＨＡＲＱ−ＡＣＫ）の変調シンボルを取得する。多重分離部３０５５は、ＰＵＳＣＨの信号から取得した上りリンクデータの変調シンボルをデータ復調／復号部３０５１へ出力する。多重分離部３０５５は、ＰＵＣＣＨの信号またはＰＵＳＣＨの信号から取得した上りリンク制御情報（ＨＡＲＱ−ＡＣＫ）の変調シンボルを制御情報復調／復号部３０５３へ出力する。
チャネル測定部３０５９は、多重分離部３０５５から入力された上りリンク参照信号から伝搬路の推定値、チャネルの品質などを測定し、多重分離部３０５５および上位層処理部３０１に出力する。
データ復調／復号部３０５１は、多重分離部３０５５から入力された上りリンクデータの変調シンボルから上りリンクデータを復号する。データ復調／復号部３０５１は、復号された上りリンクデータを上位層処理部３０１へ出力する。
制御情報復調／復号部３０５３は、多重分離部３０５５から入力されたＨＡＲＱ−ＡＣＫの変調シンボルからＨＡＲＱ−ＡＣＫを復号する。制御情報復調／復号部３０５３は、復号したＨＡＲＱ−ＡＣＫを上位層処理部３０１へ出力する。
送信部３０７は、制御部３０３から入力された制御信号に従って、下りリンク参照信号を生成し、上位層処理部３０１から入力された下りリンク制御情報、下りリンクデータを符号化、および変調し、ＰＤＣＣＨ、ＰＤＳＣＨ、および下りリンク参照信号を多重して、送受信アンテナ３０９を介して移動局装置１に信号を送信する。
符号化部３０７１は、上位層処理部３０１から入力された下りリンク制御情報、および、下りリンクデータの符号化を行なう。変調部３０７３は、符号化部３０７１から入力された符号化ビットをＢＰＳＫ、ＱＰＳＫ、１６ＱＡＭ、６４ＱＡＭ等の変調方式で変調する。
下りリンク参照信号生成部３０７９は下りリンク参照信号として生成する。多重部３０７５は、各チャネルの変調シンボルと下りリンク参照信号を多重する。
無線送信部３０７７は、多重された変調シンボルなどを逆高速フーリエ変換（Inverse Fast Fourier Transform: IFFT）して、ＯＦＤＭ方式の変調を行い、ベースバンドのディジタル信号を生成し、ベースバンドのディジタル信号をアナログ信号に変換し、アナログ信号から中間周波数の同相成分および直交成分を生成し、中間周波数帯域に対する余分な周波数成分を除去し、中間周波数の信号を高周波数の信号に変換（アップコンバート: up
convert）し、余分な周波数成分を除去し、電力増幅し、送受信アンテナ３０９に出力して送信する。
端末装置１、および、基地局装置３に含まれる部のそれぞれは、回路として構成されてもよい。
スケジューリングリクエストは、正のスケジューリングリクエスト（positive scheduling request）、または、負のスケジューリングリクエスト（negative scheduling request）を含む。正のスケジューリングリクエストは、初期送信のためのＵＬ−ＳＣＨリソースを要求することを示す。負のスケジューリングリクエストは、初期送信のためのＵＬ−ＳＣＨリソースを要求しないことを示す。
ＰＵＣＣＨフォーマット１は、正のスケジューリングリクエストを送信するために用いられる。ＰＵＣＣＨフォーマット１ａは、１ビットのＨＡＲＱ−ＡＣＫを送信するために用いられる。ＰＵＣＣＨフォーマット１ｂは、２ビットのＨＡＲＱ−ＡＣＫを送信するために用いられる。チャネル選択をともなうＰＵＣＣＨフォーマット１ｂは、端末装置に１つより多いサービングセルを設定される場合に４ビットまでのＨＡＲＱ−ＡＣＫを送信するために用いられる。ＰＵＣＣＨフォーマット３は、ＨＡＲＱ−ＡＣＫのみを送信するために用いられてもよい。ＰＵＣＣＨフォーマット３は、ＨＡＲＱ−ＡＣＫおよびスケジュ
ーリングリクエスト（正のスケジューリングリクエスト、または、負のスケジューリングリクエスト）を送信するために用いられてもよい。
図１１は本実施形態におけるスケジューリングリクエスト（ＳＲ）送信の一例を示す図である。
図１１におけるａ１０２からａ１０６は、スケジューリングリクエストのために有効なリソースである。換言すると、ａ１０２からａ１０６は、スケジューリングリクエストを送信するために有効なリソースである。ここで、該リソースはＰＵＣＣＨのリソースまたはｓＰＵＣＣＨのリソースであることが好ましい。なお、図１１においては説明のためａ１０２からａ１０６を図示しているが、スケジューリングリクエストのために有効なリソースはａ１０２からａ１０６以外に存在してもよい。
なお、スケジューリングリクエストのために有効なリソースは、周期的に存在することが好ましい。ここで、「周期的に存在する」とは、時間領域において所定の周期で存在することであってもよいし、時間領域において所定の時間間隔で存在することであってもよい。すなわち、スケジューリングリクエストのために有効なリソースは、端末装置において周期（Periodicity）を用いて特定されることが好ましい。
なお、スケジューリングリクエストのために有効なリソースは、周期およびオフセットで特定されてもよい。ここで、オフセットは、時間領域におけるオフセットであってもよく、周期に対するオフセットであってもよい。なお、周期は、基地局装置から上位層の信号を用いて端末装置に通知されてもよい。
なお、オフセットは、基地局装置から上位層の信号を用いて端末装置に通知されてもよい。なお、周期は、時間で定義されてもよいし、無線フレーム数（無線フレーム単位）で定義されてもよいし、サブフレーム数（サブフレーム単位）で定義されてもよいし、スロット数（スロット単位）で定義されてもよいし、シンボル数（シンボル単位）で定義されてもよい。なお、オフセットは、時間で定義されてもよいし、無線フレーム数（無線フレーム単位）で定義されてもよいし、サブフレーム数（サブフレーム単位）で定義されてもよいし、スロット数（スロット単位）で定義されてもよいし、シンボル数（シンボル単位）で定義されてもよい。
図１１におけるdsr-TransMaxは、スケジューリングリクエストの最大送信回数に関連するパラメータであってもよい。ここで、dsr-TransMaxは、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。換言すると、スケジューリングリクエストの最大送信回数は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。
図１１におけるSR_COUNTERは、スケジューリングリクエストの送信回数に関連するパラメータであってもよい。ここで、SR_COUNTERは、初期値が０であってスケジューリングリクエストを送信する毎にインクリメントされてもよい。なお、インクリメントするとは、SR_COUNTERの値に１を足すことであってもよい。なお、SR_COUNTERは、インクリメントされてdsr-TransMaxに等しくなった場合、０にリセットされてもよい。なお、スケジューリングリクエストがトリガされた場合、SR_COUNTERは０にリセットされてもよい。なお、SR_COUNTERは、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられた場合に０にリセットされてもよい。なお、SR_COUNTERの初期値は０でなくてもよい。例えば、SR_COUNTERの初期値は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。
図１１におけるａ１０１は、sr_ProhibitTimerがランニングしている時間である。ここで、sr_ProhibitTimerがランニングしている時間は、スケジューリングリクエストの送信を禁止する時間であってもよい。換言すると、sr_ProhibitTimerがランニングしている時間においてスケジューリングリクエストのために有効なリソースが存在した場合、該リソースを用いてスケジューリングリクエストを送信することは禁止される。換言すると、sr_ProhibitTimerがランニングしていない時間においては、スケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。また、sr_ProhibitTimerが満了した場合、スケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。なお、sr_ProhibitTimerはスケジューリングリクエストを送信した後にランニングされてもよい。なお、sr_ProhibitTimerは、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。なお、sr_ProhibitTimerは、時間で定義されてもよいし、無線フレーム数（無線フレーム単位）で定義されてもよいし、サブフレーム数（サブフレーム単位）で定義されてもよいし、スロット数（スロット単位）で定義されてもよいし、シンボル数（シンボル単位）で定義されてもよい。
以下、図１１の詳細について説明する。ここでは、スケジューリングリクエストの最大送信回数に関連するパラメータであるdsr-TransMaxが２に設定された場合を例に説明する。
端末装置は、スケジューリングリクエストがトリガされた場合、スケジューリングリクエストのために有効なリソースを用いてスケジューリングを送信する。端末装置は、sr_ProhibitTimerがランニングしていない時間に存在するリソースａ１０２を用いて１回目のスケジューリングリクエストを送信する。そして、SR_COUNTERを０から１へインクリメントし、sr_ProhibitTimerを開始する（sr_ProhibitTimerをランニングさせる）。１回目のスケジューリングリクエストの送信後、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられなかった場合、端末装置はSR_COUNTERの値とdsr-TransMaxを比較する。そして、ここでは、SR_COUNTERの値がdsr-TransMaxより小さいため、リソースａ１０４を用いて２回目のスケジューリングリクエストを送信する。そして、SR_COUNTERを１から２へインクリメントし、sr_ProhibitTimerを開始する。なお、リソースａ１０３もスケジューリングリクエストのために有効なリソースであるが、sr_ProhibitTimerがランニングしている時間のため、端末装置はリソースａ１０３を用いてスケジューリングリクエストを送信しない。２回目のスケジューリングリクエストの送信後、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられなかった場合、端末装置はSR_COUNTERの値とdsr-TransMaxを比較する。そして、ここでは、SR_COUNTERの値がdsr-TransMaxと等しいため（換言すると、SR_COUNTERの値がdsr-TransMaxより小さくないため）、ランダムアクセスプロシージャを開始する。なお、該ランダムアクセスプロシージャは、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）のスケジューリングを要求するために開始される。すなわち、リソースａ１０６を用いて３回目のスケジューリングリクエストを送信しない。なお、ランダムアクセスプロシージャを開始した場合、SR_COUNTERは０へリセットされてもよい。なお、リソースａ１０５もスケジューリングリクエストのために有効なリソースであるが、sr_ProhibitTimerがランニングしている時間のため、端末装置はリソースａ１０５を用いてスケジューリングリクエストを送信しない。
図１２は本実施形態におけるスケジューリングリクエスト（ＳＲ）送信の一例を示す図である。
図１２におけるａ２０３からａ２１７は、スケジューリングリクエストのために有効な第１のリソースである。図１２におけるａ２１８からａ２２５は、スケジューリングリク
エストのために有効な第２のリソースである。換言すると、ａ２０３からａ２１７は、スケジューリングリクエストを送信するために有効な第１のリソースである。換言すると、ａ２１８からａ２２５は、スケジューリングリクエストを送信するために有効な第２のリソースである。ここで、該第１のリソースはｓＰＵＣＣＨのリソースであることが好ましく、該第２のリソースはＰＵＣＣＨのリソースであることが好ましい。なお、該第１のリソースは第１のｓＰＵＣＣＨのリソースであってもよく、該第２のリソースは第２のｓＰＵＣＣＨのリソースであってもよい。なお、図１２においては説明のためａ２０３からａ２１７とａ２１８からａ２２５を図示しているが、スケジューリングリクエストのために有効なリソースはａ２０３からａ２１７とａ２１８からａ２２５以外に存在してもよい。なお、図１２においては説明のためａ２０３からａ２１７とａ２１８からａ２２５を異なる時間軸上に示している。しかし、実際は、ａ２０３からａ２１７とａ２１８からａ２２５が同じ時間軸上に存在することが好ましい。
なお、スケジューリングリクエストのために有効な第１のリソースおよびスケジューリングリクエストのために有効な第２のリソースは、周期的に存在することが好ましい。ここで、「周期的に存在する」とは、時間領域において所定の周期で存在することであってもよいし、時間領域において所定の時間間隔で存在することであってもよい。すなわち、スケジューリングリクエストのために有効な第１のリソースは、端末装置において第１の周期（Periodicity）を用いて特定されることが好ましい。さらに、スケジューリングリ
クエストのために有効な第２のリソースは、端末装置において第２の周期（Periodicity
）を用いて特定されることが好ましい。
なお、スケジューリングリクエストのために有効な第１のリソースは、第１の周期および／または第１のオフセットで特定されてもよい。更に、スケジューリングリクエストのために有効な第２のリソースは、第２の周期および／または第２のオフセットで特定されてもよい。ここで、第１のオフセットは、時間領域におけるオフセットであってもよく、第２の周期に対する時間的なずれを示すオフセットであってもよい。ここで、第２のオフセットは、時間領域におけるオフセットであってもよく、第１の周期に対する時間的なずれを示すオフセットであってもよい。
なお、スケジューリングリクエストのために有効な第２のリソースは、第２の周期および／または第２のオフセットで特定され、スケジューリングリクエストのために有効な第１のリソースは、第１のオフセットのみで特定されてもよい。すなわち、第１のオフセットは、第２のリソースに対する第１のリソースの時間的なずれを示すオフセットであってもよい。
なお、第１の周期および／または第２の周期は、基地局装置から上位層の信号を用いて端末装置に通知されてもよい。なお、第１のオフセットおよび／または第２のオフセットは、基地局装置から上位層の信号を用いて端末装置に通知されてもよい。なお、第１の周期および／または第２の周期は、時間で定義されてもよいし、無線フレーム数（無線フレーム単位）で定義されてもよいし、サブフレーム数（サブフレーム単位）で定義されてもよいし、スロット数（スロット単位）で定義されてもよいし、シンボル数（シンボル単位）で定義されてもよい。なお、オフセットは、時間で定義されてもよいし、無線フレーム数（無線フレーム単位）で定義されてもよいし、サブフレーム数（サブフレーム単位）で定義されてもよいし、スロット数（スロット単位）で定義されてもよいし、シンボル数（シンボル単位）で定義されてもよい。
なお、第１の周期と第２の周期は、独立に設定されてもよい。換言すると、第１の周期と第２の周期は、独立に基地局装置から通知されてもよい。なお、第１のオフセットと第２のオフセットは、独立に設定されてもよい。換言すると、第１のオフセットと第２のオ
フセットは、独立に基地局装置から通知されてもよい。
図１２におけるdsr-TransMax-rel14は、第１のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータであってもよい。ここで、dsr-TransMax-rel14は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。換言すると、第１のリソースを用いたスケジューリングリクエストの最大送信回数は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。
図１２におけるdsr-TransMaxは、第２のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータであってもよい。ここで、dsr-TransMaxは、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。換言すると、第２のリソースを用いたスケジューリングリクエストの最大送信回数は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。
なお、図１２においては説明のため、dsr-TransMax-rel14とdsr-TransMaxを異なるパラメータとして示しているが、dsr-TransMax-rel14とdsr-TransMaxは同じであってもよい。すなわち、第１のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータと第２のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータは、共通であってもよい。換言すると、第１のリソースを用いたスケジューリングリクエストの最大送信回数と第２のリソースを用いたスケジューリングリクエストの最大送信回数は、同じであってもよい。例えば、第１のリソースを用いたスケジューリングリクエストの最大送信回数と第２のリソースを用いたスケジューリングリクエストの最大送信回数は、共にdsr-TransMaxで設定されてもよい。例えば、第１のリソースを用いたスケジューリングリクエストの最大送信回数と第２のリソースを用いたスケジューリングリクエストの最大送信回数の合計回数がdsr-TransMaxで設定されてもよい。
図１２におけるSR_COUNTER-rel14は、第１のリソースを用いたスケジューリングリクエストの送信回数に関連するパラメータであってもよい。ここで、SR_COUNTER-rel14は、初期値が０であって第１のリソースを用いてスケジューリングリクエストを送信する毎にインクリメントされてもよい。なお、インクリメントするとは、SR_COUNTER-rel14の値に１を足すことであってもよい。なお、SR_COUNTER-rel14は、インクリメントされてdsr-TransMax-rel14に等しくなった場合、０にリセットされてもよい。なお、第１のリソースを用いたスケジューリングリクエストがトリガされた場合、SR_COUNTER-rel14は０にリセットされてもよい。なお、SR_COUNTER-rel14は、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられた場合に０にリセットされてもよい。なお、SR_COUNTER-rel14の初期値は０でなくてもよい。例えば、SR_COUNTER-rel14の初期値は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。
図１２におけるSR_COUNTERは、第２のリソースを用いたスケジューリングリクエストの送信回数に関連するパラメータであってもよい。ここで、SR_COUNTERは、初期値が０であって第２のリソースを用いてスケジューリングリクエストを送信する毎にインクリメントされてもよい。なお、インクリメントするとは、SR_COUNTERの値に１を足すことであってもよい。なお、SR_COUNTERは、インクリメントされてdsr-TransMaxに等しくなった場合、０にリセットされてもよい。なお、第２のリソースを用いたスケジューリングリクエストがトリガされた場合、SR_COUNTERは０にリセットされてもよい。なお、SR_COUNTERは、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられた場合に０にリセットされてもよい。なお、SR_COUNTERの初期値は０でなくても
よい。例えば、SR_COUNTERの初期値は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。
なお、図１２においては説明のため、SR_COUNTER-rel14とSR_COUNTERを異なるパラメータとして示しているが、SR_COUNTER-rel14とSR_COUNTERは同じであってもよい。すなわち、第１のリソースを用いたスケジューリングリクエストの送信回数に関連するパラメータと第２のリソースを用いたスケジューリングリクエストの送信回数に関連するパラメータは、共通であってもよい。換言すると、第１のリソースを用いたスケジューリングリクエストの送信回数と第２のリソースを用いたスケジューリングリクエストの送信回数は１つのSR_COUNTERを用いてカウントされてもよい。例えば、SR_COUNTERを用いて第１のリソースを用いたスケジューリングリクエストの送信回数と第２のリソースを用いたスケジューリングリクエストの送信回数の合計回数がカウントされてもよい。例えば、SR_COUNTERを用いて第２のリソースを用いたスケジューリングリクエストの送信回数をカウントした後、該SR_COUNTERを０にリセットし、リセットされたSR_COUNTERを用いて第１のリソースを用いたスケジューリングリクエストの送信回数をカウントしてもよい。
図１２におけるａ２０１は、sr_ProhibitTimer-rel14がランニングしている時間である。ここで、sr_ProhibitTimer-rel14がランニングしている時間は、第１のリソースを用いたスケジューリングリクエストの送信を禁止する時間であってもよい。換言すると、sr_ProhibitTimer-rel14がランニングしている時間において第１のリソースを用いたスケジューリングリクエストのために有効なリソースが存在した場合、該リソースを用いてスケジューリングリクエストを送信することは禁止される。換言すると、sr_ProhibitTimer-rel14がランニングしていない時間においては、第１のリソースを用いたスケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。また、sr_ProhibitTimer-rel14が満了した場合、第１のリソースを用いたスケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。なお、sr_ProhibitTimer-rel14は第１のリソースを用いたスケジューリングリクエストを送信した後にランニングされてもよい。なお、sr_ProhibitTimer-rel14は、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。なお、sr_ProhibitTimer-rel14は、時間で定義されてもよいし、無線フレーム数（無線フレーム単位）で定義されてもよいし、サブフレーム数（サブフレーム単位）で定義されてもよいし、スロット数（スロット単位）で定義されてもよいし、シンボル数（シンボル単位）で定義されてもよい。
図１２におけるａ２０２は、sr_ProhibitTimerがランニングしている時間である。ここで、sr_ProhibitTimerがランニングしている時間は、第２のリソースを用いたスケジューリングリクエストの送信を禁止する時間であってもよい。換言すると、sr_ProhibitTimerがランニングしている時間において第２のリソースを用いたスケジューリングリクエストのために有効なリソースが存在した場合、該リソースを用いてスケジューリングリクエストを送信することは禁止される。換言すると、sr_ProhibitTimerがランニングしていない時間においては、第２のリソースを用いたスケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。また、sr_ProhibitTimerが満了した場合、第２のリソースを用いたスケジューリングリクエストのために有効なリソースを用いてスケジューリングリクエストを送信することができる。なお、sr_ProhibitTimerは第２のリソースを用いたスケジューリングリクエストを送信した後にランニングされてもよい。なお、sr_ProhibitTimerは、基地局装置から上位層の信号を用いて端末装置に通知されてもよいし、仕様書などによって予め定義されてもよい。なお、sr_ProhibitTimerは、時間で定義されてもよいし、無線フレーム数（無線フレーム単位）で定義されてもよいし、サブフレーム数（サブフレーム単位）で定義されてもよいし、スロット数（スロット単位）で定義されてもよいし、シンボル数（シンボル単位）で定義されて
もよい。
なお、図１２においては説明のため、sr_ProhibitTimer -rel14とsr_ProhibitTimerを
異なるパラメータとして示しているが、sr_ProhibitTimer-rel14とsr_ProhibitTimerは同じであってもよい。すなわち、第１のリソースを用いたスケジューリングリクエストの送信を禁止する時間と第２のリソースを用いたスケジューリングリクエストの送信を禁止する時間は、共通であってもよい。換言すると、第１のリソースを用いたスケジューリングリクエストの送信を禁止する時間と第２のリソースを用いたスケジューリングリクエストの送信を禁止する時間は、同じであってもよい。例えば、第１のリソースを用いたスケジューリングリクエストの送信を禁止する時間と第２のリソースを用いたスケジューリングリクエストの送信を禁止する時間は、共にsr_ProhibitTimerで設定されてもよい。
以下、図１２の詳細について説明する。ここでは、第１のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータであるdsr-TransMax-rel14が２、第２のリソースを用いたスケジューリングリクエストの最大送信回数に関連するパラメータであるdsr-TransMaxが２に設定された場合を例に説明する。
端末装置は、スケジューリングリクエストがトリガされた場合、スケジューリングリクエストのために有効な第１のリソースを用いてスケジューリングを送信する。端末装置は、sr_ProhibitTimer-rel14がランニングしていない時間に存在するリソースａ２０３を用いて１回目のスケジューリングリクエストを送信する。そして、SR_COUNTER-rel14を０から１へインクリメントし、sr_ProhibitTimer-rel14を開始する（sr_ProhibitTimer-rel14をランニングさせる）。スケジューリングリクエストのために有効な第１のリソースを用いた１回目のスケジューリングリクエストの送信後、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられなかった場合、端末装置はSR_COUNTER-rel14の値とdsr-TransMax-rel14を比較する。そして、ここでは、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さいため、リソースａ２０５を用いて２回目のスケジューリングリクエストを送信する。そして、SR_COUNTER-rel14を１から２へインクリメントし、sr_ProhibitTimer-rel14を開始する。なお、リソースａ２０４もスケジューリングリクエストのために有効な第１のリソースであるが、sr_ProhibitTimer-rel14がランニングしている時間のため、端末装置はリソースａ２０４を用いてスケジューリングリクエストを送信しない。スケジューリングリクエストのために有効な第１のリソースを用いた２回目のスケジューリングリクエストの送信後、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられなかった場合、端末装置はSR_COUNTER-rel14の値とdsr-TransMax-rel14を比較する。そして、ここでは、SR_COUNTER-rel14の値がdsr-TransMax-rel14と等しいため（換言すると、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さくないため）、第１のリソースを用いたスケジューリングリクエストの送信を終了する。すなわち、リソースａ２０７を用いて３回目のスケジューリングリクエストを送信しない。なお、リソースａ２０６もスケジューリングリクエストのために有効な第１のリソースであるが、sr_ProhibitTimer-rel14がランニングしている時間のため、端末装置はリソースａ２０６を用いてスケジューリングリクエストを送信しない。そして、端末装置は、第２のリソースを用いたスケジューリングリクエストの送信を開始する。端末装置は、sr_ProhibitTimerがランニングしていない時間に存在するリソースａ２２１を用いて１回目のスケジューリングリクエストを送信する。そして、SR_COUNTERを０から１へインクリメントし、sr_ProhibitTimerを開始する（sr_ProhibitTimerをランニングさせる）。スケジューリングリクエストのために有効な第２のリソースを用いた１回目のスケジューリングリクエストの送信後、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられなかった場合、端末装置はSR_COUNTERの値とdsr-TransMaxを比較する。そして、ここでは、SR_COUNTERの値がdsr-TransMaxより小さいため、リソースａ２２３を用いて２回目のスケジューリングリクエストを
送信する。そして、SR_COUNTERを１から２へインクリメントし、sr_ProhibitTimerを開始する。なお、リソースａ２２２もスケジューリングリクエストのために有効なリソースであるが、sr_ProhibitTimerがランニングしている時間のため、端末装置はリソースａ２２２を用いてスケジューリングリクエストを送信しない。スケジューリングリクエストのために有効な第２のリソースを用いた２回目のスケジューリングリクエストの送信後、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられなかった場合、端末装置はSR_COUNTERの値とdsr-TransMaxを比較する。そして、ここでは、SR_COUNTERの値がdsr-TransMaxと等しいため（換言すると、SR_COUNTERの値がdsr-TransMaxより小さくないため）、ランダムアクセスプロシージャを開始する。なお、該ランダムアクセスプロシージャは、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）のスケジューリングを要求するために開始される。すなわち、リソースａ２２５を用いて３回目のスケジューリングリクエストを送信しない。なお、ランダムアクセスプロシージャを開始した場合、SR_COUNTERは０へリセットされてもよい。なお、リソースａ２２４もスケジューリングリクエストのために有効なリソースであるが、sr_ProhibitTimerがランニングしている時間のため、端末装置はリソースａ２２４を用いてスケジューリングリクエストを送信しない。
すなわち、端末装置は、スケジューリングリクエストのために有効な第１のリソースを用いて所定の回数スケジューリングリクエストを送信する。そして、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられなかった場合、端末装置は、スケジューリングリクエストのために有効な第２のリソースを用いて所定の回数スケジューリングリクエストを送信する。そして、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）が割り当てられなかった場合、端末装置は、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）のスケジューリングを要求するためのランダムアクセスプロシージャを開始する。
図１３は本実施形態におけるスケジューリングリクエスト送信フローの一例を示す図である。
図１３は図１１に対応するフローの一例である。すなわち、図１３は、図１１のスケジューリングリクエスト送信の一例に対応するスケジューリングリクエスト送信フローの一例である。
図１３は、本実施形態における、サブフレーム（ＴＴＩ）のそれぞれに対して実行されるスケジューリングリクエストに関する処理の一例を示す図である。図１３の処理はＭＡＣ層において実行される。端末装置１は、少なくとも１つのスケジューリングリクエストがペンディングしている間、送信のために利用可能なＵＬ−ＳＣＨがないサブフレームのそれぞれに対して図１３における処理を実行する。尚、具体的な処理は、図１３の処理に限られるものではなく、この発明の要旨を逸脱しない範囲でステップの入れ替え／追加／除去等によって変更された処理も含まれる。また、図１３の処理は、請求項に示した範囲で種々の変更が可能であり、開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
なお、図１３においては、説明のため「ＰＵＣＣＨリソース」と称している。しかし、該ＰＵＣＣＨリソースは、第１のリソース、ｓＰＵＣＣＨリソース、などに換言することができる。
以下、図１３の詳細について説明する。
Ｓ３０１において、フローは開始される。
Ｓ３０２において、スケジューリングリクエストがトリガされているか否か判断する。Ｓ３０２において、スケジューリングリクエストがトリガされていると判断した場合、Ｓ３０３へ進む。
なお、スケジューリングリクエストがトリガされる場合には、該スケジューリングリクエストがキャンセルされるまで、該スケジューリングリクエストはペンディングであるとみなされる。スケジューリングリクエストがトリガされ、ペンディングしている他のスケジューリングリクエストがない場合には、端末装置１はカウンターSR_COUNTERを０にセットする。
Ｓ３０３において、ペンディングしている他のスケジューリングリクエストがないか否かを判断する。Ｓ３０３において、ペンディングしている他のスケジューリングリクエストがないと判断した場合、Ｓ３０４へ進む。
Ｓ３０４において、SR_COUNTERは０に設定される。すなわち、Ｓ３０４において、SR_COUNTERは０にリセットされる。Ｓ３０４において、SR_COUNTERが０に設定された後、Ｓ３０５へ進む。
Ｓ３０５において、送信のために利用可能なＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）があるか否かを判断する。Ｓ３０５において、送信のために利用可能なＵＬ−ＳＣＨリソースがないと判断された場合、Ｓ３０６へ進む。Ｓ３０５において、送信のために利用可能なＵＬ−ＳＣＨリソースがあると判断された場合、Ｓ３１２へ進む。すなわち、Ｓ３０５において、送信のために利用可能なＵＬ−ＳＣＨリソースがあると判断された場合、フローを終了する。
Ｓ３０６において、スケジューリングリクエストのための有効なＰＵＣＣＨリソースが設定されているか否かを判断する。Ｓ３０６において、スケジューリングリクエストのための有効なＰＵＣＣＨリソースが設定されていると判断した場合、Ｓ３０７へ進む。Ｓ３０６において、スケジューリングリクエストのための有効なＰＵＣＣＨリソースが設定されていないと判断した場合、Ｓ３０９へ進む。
Ｓ３０７において、該サブフレーム（ＴＴＩ）が測定ギャップの一部か否かを判断し、更に、sr-ProhibitTimerがランニングしているか否か判断する。Ｓ３０７において、該サブフレーム（ＴＴＩ）が測定ギャップの一部ではない、かつ、sr-ProhibitTimerがランニングしていないと判断した場合、Ｓ３０８へ進む。
Ｓ３０８において、SR_COUNTERの値がdsr-TransMaxより小さいか否か判断する。Ｓ３０８において、SR_COUNTERの値がdsr-TransMaxより小さいと判断された場合、Ｓ３１０へ進む。Ｓ３０８において、SR_COUNTERの値がdsr-TransMaxより小さくないと判断された場合、Ｓ３１１へ進む。すなわち、Ｓ３０８において、SR_COUNTERの値がdsr-TransMaxと等しいと判断された場合、Ｓ３１１へ進む。すなわち、Ｓ３０８において、SR_COUNTERの値がdsr-TransMaxより大きいと判断された場合、Ｓ３１１へ進む。
Ｓ３０９において、ランダムアクセスプロシージャを開始（initiate）する。Ｓ３０９において、ランダムアクセスプロシージャを開始した後、Ｓ３１２へ進む。すなわち、Ｓ３０９において、ランダムアクセスプロシージャを開始した後、フローを終了する。ここで、なお、該ランダムアクセスプロシージャは、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）のスケジューリングを要求するために開始さ
れる。
Ｓ３１０において、下記３つの処理を行う。その後、Ｓ３０５へ進む。
・（処理Ｓ３１０−１）：SR_COUNTERの値をインクリメントする
・（処理Ｓ３１０−２）：ＰＵＣＣＨリソースを用いてスケジューリングリクエストをシグナルするよう物理レイヤへ指示する
・（処理Ｓ３１０−３）：sr-ProhibitTimerの開始
Ｓ３１１において、下記３つの処理を行う。その後、Ｓ３１２へ進む。
・（処理Ｓ３１１−１）：全てのサービングセルに対するＰＵＣＣＨ／ＳＲＳをリリースするようＲＲＣに通知
・（処理Ｓ３１１−２）： 設定された下りリンクアサインメントおよび設定された上り
リンクアサインメントをクリア
・（処理Ｓ３１１−３）：ランダムアクセスプロシージャを開始する
なお、処理Ｓ３１１−３における該ランダムアクセスプロシージャは、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）のスケジューリングを要求するために開始される。
Ｓ３１２において、フローは終了される。
図１４は本実施形態におけるスケジューリングリクエスト送信フローの一例を示す図である。
図１４は図１２に対応するフローの一例である。すなわち、図１４は、図１２のスケジューリングリクエスト送信の一例に対応するスケジューリングリクエスト送信フローの一例である。
図１４は、本実施形態における、サブフレーム（ＴＴＩ）のそれぞれに対して実行されるスケジューリングリクエストに関する処理の一例を示す図である。図１４の処理はＭＡＣ層において実行される。端末装置１は、少なくとも１つのスケジューリングリクエストがペンディングしている間、送信のために利用可能なＵＬ−ＳＣＨがないサブフレームのそれぞれに対して図１４における処理を実行する。尚、具体的な処理は、図１４の処理に限られるものではなく、この発明の要旨を逸脱しない範囲でステップの入れ替え／追加／除去等によって変更された処理も含まれる。また、図１４の処理は、請求項に示した範囲で種々の変更が可能であり、開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
なお、図１４においては、説明のため「第１のリソース」と称している。しかし、該第１のリソースは、第１のｓＰＵＣＣＨリソース、ｓＰＵＣＣＨリソース、などに換言することができる。なお、図１４においては、説明のため「第２のリソース」と称している。しかし、該第２のリソースは、第２のｓＰＵＣＣＨリソース、ＰＵＣＣＨリソース、などに換言することができる。
以下、図１４の詳細について説明する。
Ｓ４０１において、フローは開始される。
Ｓ４０２において、スケジューリングリクエストがトリガされているか否か判断する。Ｓ４０２において、スケジューリングリクエストがトリガされていると判断した場合、Ｓ４０３へ進む。
なお、スケジューリングリクエストがトリガされる場合には、該スケジューリングリクエストがキャンセルされるまで、該スケジューリングリクエストはペンディングであるとみなされる。スケジューリングリクエストがトリガされ、ペンディングしている他のスケジューリングリクエストがない場合には、端末装置１はカウンターSR_COUNTER-rel14を０にセットする。
Ｓ４０３において、ペンディングしている他のスケジューリングリクエストがないか否かを判断する。Ｓ４０３において、ペンディングしている他のスケジューリングリクエストがないと判断した場合、Ｓ４０４へ進む。
Ｓ４０４において、SR_COUNTERは０に設定され、更に、SR_COUNTER-rel14は０に設定される。すなわち、Ｓ４０４において、SR_COUNTER及びSR_COUNTER-rel14は０にリセットされる。Ｓ４０４において、SR_COUNTER及びSR_COUNTER-rel14が０に設定された後、Ｓ４０５へ進む。
Ｓ４０５において、送信のために利用可能なＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）があるか否かを判断する。Ｓ４０５において、送信のために利用可能なＵＬ−ＳＣＨリソースがないと判断された場合、Ｓ４０６へ進む。Ｓ４０５において、送信のために利用可能なＵＬ−ＳＣＨリソースがあると判断された場合、Ｓ４１６へ進む。すなわち、Ｓ４０５において、送信のために利用可能なＵＬ−ＳＣＨリソースがあると判断された場合、フローを終了する。
Ｓ４０６において、スケジューリングリクエストのための有効な第１のリソースが設定されているか否かを判断する。Ｓ４０６において、スケジューリングリクエストのための有効な第１のリソースが設定されていると判断した場合、Ｓ４０７へ進む。Ｓ４０６において、スケジューリングリクエストのための有効な第１のリソースが設定されていないと判断した場合、Ｓ４１０へ進む。
Ｓ４０７において、該サブフレーム（ＴＴＩ）が測定ギャップの一部か否かを判断し、更に、sr-ProhibitTimer-rel14がランニングしているか否か判断する。Ｓ４０７において、該サブフレーム（ＴＴＩ）が測定ギャップの一部ではない、かつ、sr-ProhibitTimer-rel14がランニングしていないと判断した場合、Ｓ４０８へ進む。
Ｓ４０８において、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さいか否か判断する。Ｓ４０８において、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さいと判断された場合、Ｓ４０９へ進む。Ｓ４０８において、SR_COUNTER-rel14の値がdsr-TransMax-rel14より小さくないと判断された場合、Ｓ４１０へ進む。すなわち、Ｓ４０８において、SR_COUNTER-rel14の値がdsr-TransMax-rel14と等しいと判断された場合、Ｓ４１０へ進む。すなわち、Ｓ４０８において、SR_COUNTER-rel14の値がdsr-TransMax-rel14より大きいと判断された場合、Ｓ４１０へ進む。
Ｓ４０９において、下記３つの処理を行う。その後、Ｓ４０５へ進む。
・（処理Ｓ４０９−１）：SR_COUNTER-rel14の値をインクリメントする
・（処理Ｓ４０９−２）：第１のリソースを用いてスケジューリングリクエスト（第１のスケジューリングリクエスト）をシグナルするよう物理レイヤへ指示する
・（処理Ｓ４０９−３）：sr-ProhibitTimer-rel14の開始
Ｓ４１０において、スケジューリングリクエストのための有効な第２のリソースが設定されているか否かを判断する。Ｓ４１０において、スケジューリングリクエストのための有効な第２のリソースが設定されていると判断した場合、Ｓ４１１へ進む。Ｓ４１０において、スケジューリングリクエストのための有効な第２のリソースが設定されていないと
判断した場合、Ｓ４１３へ進む。
Ｓ４１１において、該サブフレーム（ＴＴＩ）が測定ギャップの一部か否かを判断し、更に、sr-ProhibitTimerがランニングしているか否か判断する。Ｓ４０７において、該サブフレーム（ＴＴＩ）が測定ギャップの一部ではない、かつ、sr-ProhibitTimerがランニングしていないと判断した場合、Ｓ４１２へ進む。なお、Ｓ４１１において、該サブフレーム（ＴＴＩ）が測定ギャップの一部か否かは判断されなくてもよい。その理由は、Ｓ４０７において、該サブフレーム（ＴＴＩ）が測定ギャップの一部でないと判断しているためである。
Ｓ４１２において、SR_COUNTERの値がdsr-TransMaxより小さいか否か判断する。Ｓ４１２において、SR_COUNTERの値がdsr-TransMaxより小さいと判断された場合、Ｓ４１４へ進む。Ｓ４１２において、SR_COUNTERの値がdsr-TransMaxより小さくないと判断された場合、Ｓ４１５へ進む。すなわち、Ｓ４１２において、SR_COUNTERの値がdsr-TransMaxと等しいと判断された場合、Ｓ４１５へ進む。すなわち、Ｓ４１２において、SR_COUNTERの値がdsr-TransMaxより大きいと判断された場合、Ｓ４１５へ進む。
Ｓ４１３において、ランダムアクセスプロシージャを開始（initiate）する。Ｓ４１３において、ランダムアクセスプロシージャを開始した後、Ｓ４１６へ進む。すなわち、Ｓ４１３において、ランダムアクセスプロシージャを開始した後、フローを終了する。ここで、なお、該ランダムアクセスプロシージャは、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）のスケジューリングを要求するために開始される。
Ｓ４１４において、下記３つの処理を行う。その後、Ｓ４０５へ進む。
・（処理Ｓ４１４−１）：SR_COUNTERの値をインクリメントする
・（処理Ｓ４１４−２）：第２のリソースを用いてスケジューリングリクエスト（第２のスケジューリングリクエスト）をシグナルするよう物理レイヤへ指示する
・（処理Ｓ４１４−３）：sr-ProhibitTimerの開始
Ｓ４１５において、下記３つの処理を行う。その後、Ｓ４１６へ進む。
・（処理Ｓ４１５−１）：全てのサービングセルに対するＰＵＣＣＨ（および／またはｓＰＵＣＣＨ）／ＳＲＳをリリースするようＲＲＣに通知
・（処理Ｓ４１５−２）： 設定された下りリンクアサインメントおよび設定された上り
リンクアサインメントをクリア
・（処理Ｓ４１５−３）：ランダムアクセスプロシージャを開始する
なお、処理Ｓ４１５−３における該ランダムアクセスプロシージャは、ＵＬ−ＳＣＨリソース（例えば、ＰＵＳＣＨのリソース、ｓＰＵＳＣＨのリソース）のスケジューリングを要求するために開始される。
Ｓ４１６において、フローは終了される。
図１５は本実施形態におけるスケジューリングリクエスト送信に関連する擬似コードの一例を示す図である。
図１５は図１２に対応する擬似コードの一例である。すなわち、図１５は、図１２のスケジューリングリクエスト送信の一例に対応するスケジューリングリクエスト送信に関連する擬似コードの一例である。
図１６は本実施形態におけるスケジューリングリクエスト送信に関連する擬似コードの一例を示す図である。
図１６は図１２に対応する擬似コードの一例である。すなわち、図１６は、図１２のスケジューリングリクエスト送信の一例に対応するスケジューリングリクエスト送信に関連する擬似コードの一例である。
なお、本実施形態において、ＰＵＣＣＨとｓＰＵＣＣＨのＴＴＩ長は異なってもよい。また、なお、本実施形態において、ＰＵＣＣＨとｓＰＵＣＣＨのシンボルは異なってもよい。すなわち、本実施形態において、ＰＵＣＣＨの送信に用いられるサブキャリア間隔とｓＰＵＣＣＨの送信に用いられるサブキャリア間隔は異なってもよい。
本実施形態の端末装置１は、ＰＵＣＣＨおよびＰＵＳＣＨ同時送信が設定されていない。ＰＵＣＣＨおよびＰＵＳＣＨ同時送信が設定されている場合、本実施形態とは異なる処理が適用されてもよい。
以下、本実施形態における、端末装置１および基地局装置３の種々の態様について説明する。
（１）本実施形態の第１の態様は、端末装置１であって、スケジューリングリクエストを送信する送信部と、ランダムアクセスプロシージャを開始する上位層処理部を備え、前記送信部は、スケジューリングリクエストのための有効な第１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、前記上位層処理部は、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。
（２）本実施形態の第１の態様において、前記第１のスケジューリングリクエストの最大送信回数と前記第２のスケジューリングリクエストの最大送信回数は、基地局装置から独立に設定される。
（３）本実施形態の第１の態様において、前記第１スケジューリングリクエストと前記第２のスケジューリングリクエストは異なるＴＴＩ長で送信される。
（４）前記第１のリソースはｓＰＵＣＣＨのリソースであり、前記第２のリソースはＰＵＣＣＨのリソースである。
（５）本実施形態の第２の態様は、端末装置１における通信方法であって、スケジューリングリクエストを送信する第１のステップと、ランダムアクセスプロシージャを開始する第２のステップを備え、前記第１のステップは、スケジューリングリクエストのための有効な第１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、前記第２のステップは、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。
（６）本実施形態の第３の態様は、端末装置１に実装される集積回路であって、スケジューリングリクエストを送信する送信回路と、ランダムアクセスプロシージャを開始する上位層処理回路を備え、前記送信回路は、スケジューリングリクエストのための有効な第
１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、前記上位層処理回路は、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する。
これにより、端末装置は効率的に上りリンク制御情報を送信することができる。また、基地局装置は効率的に上りリンク制御情報を受信することができる。
本発明に関わる基地局装置３、および端末装置１で動作するプログラムは、本発明に関わる上記実施形態の機能を実現するように、ＣＰＵ（Central Processing Unit）等を制
御するプログラム（コンピュータを機能させるプログラム）であっても良い。そして、これら装置で取り扱われる情報は、その処理時に一時的にＲＡＭ（Random Access Memory）に蓄積され、その後、Ｆｌａｓｈ ＲＯＭ（Read Only Memory)などの各種ＲＯＭやＨＤ
Ｄ（Hard Disk Drive）に格納され、必要に応じてＣＰＵによって読み出し、修正・書き
込みが行われる。
尚、上述した実施形態における端末装置１、基地局装置３の一部、をコンピュータで実現するようにしても良い。その場合、この制御機能を実現するためのプログラムをコンピュータが読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現しても良い。
尚、ここでいう「コンピュータシステム」とは、端末装置１、又は基地局装置３に内蔵されたコンピュータシステムであって、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。
さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでも良い。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
また、上述した実施形態における基地局装置３は、複数の装置から構成される集合体（装置グループ）として実現することもできる。装置グループを構成する装置の各々は、上述した実施形態に関わる基地局装置３の各機能または各機能ブロックの一部、または、全部を備えてもよい。装置グループとして、基地局装置３の一通りの各機能または各機能ブロックを有していればよい。また、上述した実施形態に関わる端末装置１は、集合体としての基地局装置と通信することも可能である。
また、上述した実施形態における基地局装置３は、ＥＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）であってもよい。また、上述した実施形態における基地局装置３は、ｅＮｏｄｅＢに対する上位ノードの機能の一部または全部を有してもよい。
また、上述した実施形態における端末装置１、基地局装置３の一部、又は全部を典型的
には集積回路であるＬＳＩとして実現してもよいし、チップセットとして実現してもよい。端末装置１、基地局装置３の各機能ブロックは個別にチップ化してもよいし、一部、又は全部を集積してチップ化してもよい。また、集積回路化の手法はＬＳＩに限らず専用回路、又は汎用プロセッサで実現しても良い。また、半導体技術の進歩によりＬＳＩに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いることも可能である。
また、上述した実施形態では、通信装置の一例として端末装置を記載したが、本願発明は、これに限定されるものではなく、屋内外に設置される据え置き型、または非可動型の電子機器、たとえば、ＡＶ機器、キッチン機器、掃除・洗濯機器、空調機器、オフィス機器、自動販売機、その他生活機器などの端末装置もしくは通信装置にも適用出来る。
以上、この発明の実施形態に関して図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。また、本発明は、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。また、上記各実施形態に記載された要素であり、同様の効果を奏する要素同士を置換した構成も含まれる。
１（１Ａ、１Ｂ、１Ｃ） 端末装置
３ 基地局装置
１０１ 上位層処理部
１０３ 制御部
１０５ 受信部
１０７ 送信部
３０１ 上位層処理部
３０３ 制御部
３０５ 受信部
３０７ 送信部
１０１１ 無線リソース制御部
１０１３ スケジューリング部
３０１１ 無線リソース制御部
３０１３ スケジューリング部

Claims (9)

  1. スケジューリングリクエストを送信する送信部と、
    ランダムアクセスプロシージャを開始する上位層処理部を備え、
    前記送信部は、スケジューリングリクエストのための有効な第１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、
    前記上位層処理部は、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する、
    端末装置。
  2. 前記第１のスケジューリングリクエストの最大送信回数と前記第２のスケジューリングリクエストの最大送信回数は、基地局装置から独立に設定される、
    請求項１記載の端末装置。
  3. 前記第１スケジューリングリクエストと前記第２のスケジューリングリクエストは異なるＴＴＩ長で送信される、
    請求項１記載の端末装置。
  4. 前記第１のリソースはｓＰＵＣＣＨのリソースであり、前記第２のリソースはＰＵＣＣＨのリソースである、
    請求項１記載の端末装置。
  5. 端末装置における通信方法であって、
    スケジューリングリクエストを送信する第１のステップと、
    ランダムアクセスプロシージャを開始する第２のステップを備え、
    前記第１のステップは、スケジューリングリクエストのための有効な第１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、
    前記第２のステップは、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する
    通信方法。
  6. 前記第１のスケジューリングリクエストの最大送信回数と前記第２のスケジューリングリクエストの最大送信回数は、基地局装置から独立に設定される、
    請求項５記載の通信方法。
  7. 前記第１スケジューリングリクエストと前記第２のスケジューリングリクエストは異なるＴＴＩ長で送信される、
    請求項５記載の通信方法。
  8. 前記第１のリソースはｓＰＵＣＣＨのリソースであり、前記第２のリソースはＰＵＣＣＨのリソースである、
    請求項５記載の通信方法。
  9. 端末装置に実装される集積回路であって、
    スケジューリングリクエストを送信する送信回路と、
    ランダムアクセスプロシージャを開始する上位層処理回路を備え、
    前記送信回路は、スケジューリングリクエストのための有効な第１のリソースを用いて、第１のスケジューリングリクエストを送信し、前記第１のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、スケジューリングリクエストのための有効な第２のリソースを用いて、第２のスケジューリングリクエストを送信し、
    前記上位層処理回路は、前記第２のスケジューリングリクエストの送信に基づいてＵＬ−ＳＣＨリソースが割り当てられなかった場合、ランダムアクセスプロシージャを開始する、
    集積回路。
JP2016096127A 2016-05-12 2016-05-12 端末装置、通信方法、および、集積回路 Pending JP2019125815A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2016096127A JP2019125815A (ja) 2016-05-12 2016-05-12 端末装置、通信方法、および、集積回路
PCT/JP2017/016741 WO2017195623A1 (ja) 2016-05-12 2017-04-27 端末装置、通信方法、および、集積回路

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016096127A JP2019125815A (ja) 2016-05-12 2016-05-12 端末装置、通信方法、および、集積回路

Publications (1)

Publication Number Publication Date
JP2019125815A true JP2019125815A (ja) 2019-07-25

Family

ID=60267153

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016096127A Pending JP2019125815A (ja) 2016-05-12 2016-05-12 端末装置、通信方法、および、集積回路

Country Status (2)

Country Link
JP (1) JP2019125815A (ja)
WO (1) WO2017195623A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021019736A1 (ja) * 2019-07-31 2021-02-04 株式会社Ｎｔｔドコモ 端末及び無線通信方法
WO2021029302A1 (ja) * 2019-08-09 2021-02-18 株式会社オートネットワーク技術研究所 端子付き電線

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103703860B (zh) * 2011-07-29 2019-08-16 交互数字专利控股公司 用于多无线电接入技术无线系统中的无线电资源管理的方法和设备

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021019736A1 (ja) * 2019-07-31 2021-02-04 株式会社Ｎｔｔドコモ 端末及び無線通信方法
WO2021029302A1 (ja) * 2019-08-09 2021-02-18 株式会社オートネットワーク技術研究所 端子付き電線

Also Published As

Publication number Publication date
WO2017195623A1 (ja) 2017-11-16

Similar Documents

Publication Publication Date Title
JP6368975B2 (ja) 端末装置、集積回路および無線通信方法
JP6340649B2 (ja) 端末装置、基地局装置、および通信方法
JP6422129B2 (ja) 端末装置、方法、および集積回路
JP6568066B2 (ja) 移動局装置、基地局装置、および方法
JP6388584B2 (ja) 端末装置、基地局装置、集積回路、および通信方法
JP6400023B2 (ja) 端末装置、基地局装置、および、通信方法
JP6400022B2 (ja) 端末装置、基地局装置、および、通信方法
JP6417599B2 (ja) 端末装置、無線通信方法、および集積回路
JP2019153824A (ja) 端末装置、基地局装置、通信方法、および、集積回路
CN106465373B (zh) 终端装置、集成电路以及无线通信方法
JP6507454B2 (ja) 基地局装置、端末装置、および通信方法
JP2019087799A (ja) 端末装置、基地局装置、および、通信方法
WO2017188075A1 (ja) 端末装置、基地局装置、および、通信方法
US11026256B2 (en) Terminal apparatus, base station apparatus, and communication method
JP2019096921A (ja) 端末装置、基地局装置、通信方法、および、集積回路
JP6521380B2 (ja) 端末装置、基地局装置、および無線通信方法
WO2017188107A1 (ja) 端末装置、基地局装置、通信方法、および、集積回路
WO2017195623A1 (ja) 端末装置、通信方法、および、集積回路
WO2017209164A1 (ja) 端末装置、基地局装置、通信方法、および、集積回路
JP2019106638A (ja) 端末装置、基地局装置、通信方法、および、集積回路
WO2020218415A1 (ja) 端末装置、基地局装置、および、通信方法
JP2019134198A (ja) 端末装置、基地局装置、通信方法、および、集積回路
JP6332643B2 (ja) 端末装置、集積回路、および通信方法
CN114424492A (zh) 终端装置、基站装置以及通信方法
JP2019106637A (ja) 端末装置、基地局装置、通信方法、および、集積回路

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20161104