(57)【要約】【課題】データ送信許可を受信することなくデータを送信することができるリソースの設定が行われる無線通信システムにおいて、ユーザ装置が、再送制御を行う場合でも、当該リソースを用いたデータ送信を迅速に実行する。【解決手段】無線通信システムにおけるユーザ装置において、前記ユーザ装置とは異なる通信装置からデータ送信許可を受信することなくデータを送信することが可能な複数の区分リソースに関する設定情報を保持する設定情報管理部と、前記複数の区分リソースのそれぞれは、再送制御プロセスに対応付けられており、当該複数の区分リソースから、再送制御用バッファが空きである再送制御プロセスに対応する区分リソースを選択し、当該区分リソースを用いて、データを送信する送信部とを備える。【選択図】図７
2020036051.tif 000002
【特許請求の範囲】
【請求項１】
無線通信システムにおけるユーザ装置であって、
前記ユーザ装置とは異なる通信装置からデータ送信許可を受信することなくデータを送信することが可能な複数の区分リソースに関する設定情報を保持する設定情報管理部と、
前記複数の区分リソースのそれぞれは、再送制御プロセスに対応付けられており、当該複数の区分リソースから、再送制御用バッファが空きである再送制御プロセスに対応する区分リソースを選択し、当該区分リソースを用いて、データを送信する送信部と
を備えることを特徴とするユーザ装置。
【請求項２】
前記設定情報は、前記複数の区分リソースを示す情報に加えて、区分リソースと再送制御プロセスの識別子との間のマッピング情報を含む
ことを特徴とする請求項１に記載のユーザ装置。
【請求項３】
前記複数の区分リソースにおけるそれぞれの区分リソースに、１種類又は複数種類の参照信号が対応付けられており、更に、各種類の参照信号に、再送制御プロセスが対応付けられており、
前記送信部は、ある再送制御プロセスを使用してデータを送信する場合に、当該再送制御プロセスに対応する参照信号を用いて前記データを送信する
ことを特徴とする請求項１又は２に記載のユーザ装置。
【請求項４】
前記送信部は、時間を計測するカウンタを備えており、ある再送制御プロセスにおける再送制御用バッファにデータが格納された状態のまま、前記カウンタにより、所定時間の経過が検出された場合に、当該再送制御用バッファをクリアする
ことを特徴とする請求項１ないし３のうちいずれか１項に記載のユーザ装置。
【請求項５】
前記送信部において使用される複数の再送制御プロセスに優先順位が設定されており、当該送信部は、当該優先順位に従って、再送制御用バッファが空きである再送制御プロセスを選択し、当該再送制御プロセスに対応する区分リソースを選択する
ことを特徴とする請求項１ないし４のうちいずれか１項に記載のユーザ装置。
【請求項６】
無線通信システムにおけるユーザ装置が実行するデータ送信方法であって、
前記ユーザ装置とは異なる通信装置からデータ送信許可を受信することなくデータを送信することが可能な複数の区分リソースに関する設定情報を設定情報管理部に保持するステップと、
前記複数の区分リソースのそれぞれは、再送制御プロセスに対応付けられており、当該複数の区分リソースから、再送制御用バッファが空きである再送制御プロセスに対応する区分リソースを選択し、当該区分リソースを用いて、データを送信するステップ
を備えることを特徴とするデータ送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、無線通信システムにおけるユーザ装置に関連するものである。
【背景技術】
【０００２】
現在、３ＧＰＰ（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）において、第４世代の無線通信システムの一つであるＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）−Ａｄｖａｎｃｅｄの後継にあたる５Ｇと呼ばれる次世代のシステムの検討が進んでいる。５Ｇでは、主にｅＭＢＢ（ｅｘｔｅｎｄｅｄ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）、ｍＭＴＣ（ｍａｓｓｉｖｅ  Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、ＵＲＬＬＣ（Ｕｌｔｒａ  Ｒｅｌｉａｂｉｌｉｔｙ  ａｎｄ  Ｌｏｗ  Ｌａｔｅｎｃｙ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）の３つのユースケースが想定されている。
【０００３】
ＵＲＬＬＣは、低遅延及び高信頼性による無線通信を実現することを目的としている。ＵＲＬＬＣにおいて低遅延を実現するための具体策として、Ｓｈｏｒｔ  ＴＴＩ長（サブフレーム長、サブフレーム間隔とも呼ばれる）の導入、パケット生成からデータ送信までの制御遅延の短縮化等が検討されている。更に、ＵＲＬＬＣにおいて高信頼性を実現するための具体策として、低ビット誤り率を実現するための低符号化率の符号化方式及び変調方式の導入、ダイバーシチの活用等が検討されている。
【０００４】
ＵＲＬＬＣでは、緊急度の高い送信データが突然発生する可能性があり、このような突然発生したデータを低遅延且つ高信頼度で送信する必要がある。
【０００５】
ユーザ装置において送信すべきデータが発生した場合、例えばＬＴＥのＵＬ（アップリンク）通信では、はじめに基地局に対してＳＲ（Ｓｃｈｅｄｕｌｉｎｇ  Ｒｅｑｕｅｓｔ）を送信し、リソースの割り当てを基地局に要求する。基地局は、ＵＬ  ｇｒａｎｔ（ＵＬ送信許可）として、リソースの割り当てをユーザ装置に通知し、ユーザ装置は、基地局から指定されたリソースにおいてデータを送信する。
【０００６】
しかしながら、ＵＲＬＬＣでは、上記の通り送信すべきデータが突然発生する可能性があり、上記のようにＵＬ  ｇｒａｎｔに基づくデータ送信を行う場合、低遅延の要求条件を満たせなくなる可能性がある。
【０００７】
そこで、予め上位レイヤシグナリングで複数のユーザ装置に重複した（あるいは直交した）ＵＬリソースを割り当てることにより、ユーザ装置がＵＬ  ｇｒａｎｔを受信することなくＵＬデータ送信を可能とするＧｒａｎｔ  ｆｒｅｅ  ＵＬマルチアクセス（Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ  ｍｕｌｔｉｐｌｅ  ａｃｃｅｓｓ）が検討されている。そこでは、基地局が、複数のユーザ装置から受信するデータを識別・分離することを可能ならしめるために、ユーザ装置個別の符号拡散を用いる方式、及びインターリーブを用いる方式等、様々な方式が検討されている。ＵＬデータ送信の低遅延化の観点ではＧｒａｎｔ  ｆｒｅｅ  ＵＬマルチアクセスは有効な手段の一つである。ここで、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬマルチアクセスとは、あるタイミングで送信する一つまたは複数のＴｒａｎｓｐｏｒｔ  ｂｌｏｃｋに対するリソース割り当てを逐次基地局から指示しないＵＬ送信の方法である。Ｇｒａｎｔ  ｆｒｅｅ  ＵＬマルチアクセスは、予め定めたり、予め設定したリソース候補からユーザ装置がリソースを選択して行うＵＬ送信でもよいし、あるいは基地局から端末に設定したＳＰＳ（Ｓｅｍｉ−ｐｅｒｓｉｓｔｅｎｔ  ｓｃｈｅｄｕｌｉｎｇ）に基づくＵＬ送信であってもよく、リソースの有効化・無効化や更新のために下りＬ１／Ｌ２制御信号を併用する形態も含まれる。
【０００８】
ここで、５Ｇにおいても、ＬＴＥと同様に、無線区間で生じたパケット誤りを短い制御遅延時間で効率的に保証するＨＡＲＱ（Ｈｙｂｒｉｄ  ＡＲＱ）（非特許文献１）と呼ばれる再送制御を行うことが想定される。
【０００９】
ＬＴＥにおけるユーザ装置及び基地局では、ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤのＨＡＲＱエンティティにおいてＨＡＲＱ制御が行われる。特に、ユーザ装置でのＵＬ（上り）データに対するＨＡＲＱ制御では、ユーザ装置は、データをＨＡＲＱバッファに保持し、基本的には、ＵＬ  ｇｒａｎｔに基づき送信を行う。また、再送は、ＵＬ  ｇｒａｎｔに基づく再送（Ａｄａｐｔｉｖｅ制御）と、ＵＬ  ｇｒａｎｔなしにＮＡＣＫに基づく再送（Ｎｏｎ‐Ａｄａｐｔｉｖｅ制御）がある。
【００１０】
また、１つのトランスポートブロックに対するＨＡＲＱ制御をＨＡＲＱプロセスと呼ぶ。ＨＡＲＱ制御は、複数のトランスポートブロックに対する並列動作が可能である。例えば、８つのトランスポートブロックに対するＨＡＲＱ並列動作を行う場合、ＨＡＲＱプロセス＃１〜ＨＡＲＱプロセス＃８の８つのＨＡＲＱプロセスが動作することになる。ＵＬに関し、ユーザ装置は、ＨＡＲＱプロセス毎にＨＡＲＱバッファを有する。
【００１１】
ＨＡＲＱプロセス毎にＨＡＲＱプロセスＩＤが対応付けられる。また、ＨＡＲＱには、基地局からユーザ装置に対してＨＡＲＱプロセスＩＤを指定する非同期型ＨＡＲＱと、基地局からＨＡＲＱプロセスＩＤを指定せずに、サブフレーム番号等からＨＡＲＱプロセスＩＤが定まる同期型ＨＡＲＱがある。ＬＴＥでは、ＤＬにおいて非同期型ＨＡＲＱが行われ、ＵＬにおいて同期型ＨＡＲＱが行われる。
【先行技術文献】
【非特許文献】
【００１２】
【非特許文献１】3GPP TS 36.321 V14.0.0 (2016-09)
【発明の概要】
【発明が解決しようとする課題】
【００１３】
Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信においても上述したようなＨＡＲＱ制御がなされることが想定される。ＨＡＲＱバッファは、当該ＨＡＲＱプロセスにおいて、ＡＣＫを受信する、再送回数上限到達、等により、再送を行う必要がなくなったときにクリア（フラッシュ）される。あるＨＡＲＱプロセスにおけるＵＬ送信は、当該ＨＡＲＱプロセスにおけるＨＡＲＱバッファに空きがない場合には行うことができない。従って、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信において、ユーザ装置にＵＬデータが発生し、あるＨＡＲＱプロセスを用いてＵＬ送信を行おうとしても、ＡＣＫ／ＮＡＣＫ待ち等によりＨＡＲＱバッファに空きがなく、ＵＬデータ送信を行うことができない場合があることが考えられる。
【００１４】
すなわち、ＨＡＲＱ制御等の再送制御を行う場合に、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信を迅速に行うことができない場合があるという課題がある。
【００１５】
本発明は上記の点に鑑みてなされたものであり、データ送信許可を受信することなくデータを送信することができるリソースの設定が行われる無線通信システムにおいて、ユーザ装置が、再送制御を行う場合でも、当該リソースを用いたデータ送信を迅速に実行することを可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【００１６】
開示の技術によれば、無線通信システムにおけるユーザ装置であって、
前記ユーザ装置とは異なる通信装置からデータ送信許可を受信することなくデータを送信することが可能な複数の区分リソースに関する設定情報を保持する設定情報管理部と、
前記複数の区分リソースのそれぞれは、再送制御プロセスに対応付けられており、当該複数の区分リソースから、再送制御用バッファが空きである再送制御プロセスに対応する区分リソースを選択し、当該区分リソースを用いて、データを送信する送信部と
を備えることを特徴とするユーザ装置が提供される。
【発明の効果】
【００１７】
開示の技術によれば、データ送信許可を受信することなくデータを送信することができるリソースの設定が行われる無線通信システムにおいて、ユーザ装置が、再送制御を行う場合でも、当該リソースを用いたデータ送信を迅速に実行することを可能とする技術が提供される。
【図面の簡単な説明】
【００１８】
【図１】本発明の実施の形態に係る無線通信システムの構成図である。
【図２】本発明の実施の形態に係る無線通信システムの構成図である。
【図３】Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースの例を説明するための図である。
【図４】Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信における動作例を説明するための図である。
【図５】Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信における動作例を説明するための図である。
【図６】実施例１における動作例を説明するための図である。
【図７】サブチャネルの設定例を示す図である。
【図８】サブチャネルの割り当て例、及び選択候補の例を説明するための図である。
【図９】ＨＡＲＱ  ｐｒｏｃｅｓｓ  ＩＤのマッピングの例を説明するための図である。
【図１０】バッファクリアの例を説明するための図である。
【図１１】Ｄｙｎａｍｉｃ  ＴＤＤにおける動作例を説明するための図である。
【図１２】Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースのＨＡＲＱ  ｐｒｏｃｅｓｓ  ＩＤを変更する場合の例を示す図である。
【図１３】実施例２における動作例を説明するための図である。
【図１４】実施例３における動作例を説明するための図である。
【図１５】ユーザ装置１０の機能構成の一例を示す図である。
【図１６】基地局２０の機能構成の一例を示す図である。
【図１７】ユーザ装置１０及び基地局２０のハードウェア構成の一例を示す図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。
【００２０】
本実施の形態の無線通信システムが動作するにあたっては、適宜、ＬＴＥで規定された既存技術を使用できる。ただし、当該既存技術はＬＴＥに限られない。また、本明細書で使用する「ＬＴＥ」は、特に断らない限り、ＬＴＥ−Ａｄｖａｎｃｅｄ、及び、ＬＴＥ−Ａｄｖａｎｃｅｄ以降の方式（例：５Ｇ）を含む広い意味を有するものとする。また、本発明は、ＬＴＥ以外の通信方式にも適用可能である。
【００２１】
また、以下で説明する実施の形態では、ＬＴＥで規定されているＨＡＲＱ制御に基づくＨＡＲＱ制御を行うことを想定しているが、本発明を適用できるＨＡＲＱ制御はこれに限られない。様々な再送制御方式で本発明を適用できる。なお、ＨＡＲＱプロセスを再送制御プロセスと称してもよい。
【００２２】
また、以下で説明する実施の形態では、既存のＬＴＥで使用されているＴＴＩ、ＨＡＲＱ、サブキャリア、シンボル、その他の用語を使用しているが、これは記載の便宜上のためであり、これらと同様の信号、機能等が他の名称で呼ばれてもよい。
【００２３】
また、以下で説明する実施の形態では、ユーザ装置１０から基地局２０へのＵＬ通信に対して本発明に係る技術を適用する例を説明しているが、本発明に係る技術は、ＵＬ通信のみならず、ＤＬ通信、ＳＬ（サイドリンク）通信にも適用可能である。
【００２４】
例えば、ＤＬ通信に関しては、基地局が、以下で説明するユーザ装置の機能を備え、ユーザ装置が、以下で説明する基地局の機能を備えることで、本発明に係る技術の適用を実現できる。また、ＳＬ（サイドリンク）通信に関しては、一方のユーザ装置が、以下で説明する基地局が送受信する信号と同様の信号を送受信する機能を備え、他方のユーザ装置が、以下で説明するユーザ装置と同様の機能を備えることで、本発明に係る技術の適用を実現できる。本発明に係る技術が適用される装置を総称して通信装置と呼んでもよい。
【００２５】
（システム全体構成）
図１に本実施の形態に係る無線通信システムの構成図を示す。本実施の形態に係る無線通信システムは、図１に示すように、ユーザ装置１０、及び基地局２０を含む。図１には、ユーザ装置１０、及び基地局２０が１つずつ示されているが、これは例であり、それぞれ複数であってもよい。
【００２６】
ユーザ装置１０は、スマートフォン、携帯電話機、タブレット、ウェアラブル端末、Ｍ２Ｍ（Ｍａｃｈｉｎｅ−ｔｏ−Ｍａｃｈｉｎｅ）用通信モジュール等の無線通信機能を備えた通信装置であり、基地局２０に無線接続し、無線通信システムにより提供される各種通信サービスを利用する。基地局２０は、１つ以上のセルを提供し、ユーザ装置１０と無線通信する通信装置である。なお、ユーザ装置をＵＥ（Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）と称してもよい。
【００２７】
本実施の形態においては、ＵＬデータをユーザ装置１０が送信する際のＨＡＲＱ制御を対象としている。ただし、既に説明したように、本発明の適用先は、図１に示すようなユーザ装置１０と基地局２０との間の通信に限られるわけではない。本発明は、図２に示すような、ユーザ装置間の通信、すなわち、サイドリンクにも適用可能である。サイドリンクに本発明を適用する際に、各ユーザ装置は基地局２０のカバレッジ内にあってもよいし、カバレッジ外であってもよい。また、各ユーザ装置は、基地局２０のカバレッジ内にあるときに設定情報を受信して保持しておき、それをカバレッジ外でも使用することとしてもよいし、カバレッジ外用のデフォルトの設定情報が各ユーザ装置に予め設定されていて、それを使用することとしてもよい。
【００２８】
本実施の形態において、１ＴＴＩ長の無線フレームをサブフレームと呼んでもよい。また、１ＴＴＩの時間長は、例えば１ｍｓであってもよいし、０．５ｍｓであってもよいし、１ｍｓと０．５ｍｓ以外の長さであってもよい。なお、本明細書及び特許請求の範囲で使用する「無線フレーム」の用語は、現在のＬＴＥで定義されている「無線フレーム」（１０ｍｓｅｃ）を意味しているわけではなく、より一般的な時間の単位を意味する。
【００２９】
本実施の形態における複信方式は、ＴＤＤ（Ｔｉｍｅ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）でもよいし、ＦＤＤ（Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｄｕｐｌｅｘ）でもよい。ただし、主にＴＤＤを使用することを想定している。また、ＴＤＤにおいて、１ＴＴＩ内でＵＬとＤＬを柔軟に切り替えることが可能な構成であってもよい。
【００３０】
本実施の形態の無線通信システムは、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬマルチアクセスをサポートしている。図３（ａ）は、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域が設定された場合における無線フレーム構成例を示す。図３（ａ）に示すように、この例において、下り制御チャネルであるＤＬ  ＣＣＨ（ｄｏｗｎｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）＃１と、上り制御チャネルであるＵＬ  ＣＣＨ（ｕｐｌｉｎｋ  ｃｏｎｔｒｏｌ  ｃｈａｎｎｅｌ）が設定され、これらの間にＧｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域が設定（ｃｏｎｆｉｇｕｒｅ）されている（図３（ａ）おいてＧｒａｎｔ  ｆｒｅｅ  ＵＬ  ｄａｔａ  ｒｅｓｏｕｒｃｅと記載された四角）。図３（ａ）には、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域が複数ユーザに割り当てられていることが示されているが、必ずしも複数ユーザへの重複リソース割り当てを前提にするものではなく、直交リソース割り当てを行なってもよい。
【００３１】
ユーザ装置１０に設定されるＧｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域は、例えば、リソースプールである。この場合、当該リソースプールを設定されたユーザ装置１０は、当該リソースプールから、データ送信のためのＧｒａｎｔ  ｆｒｅｅ  ＵＬデータリソースを選択してデータ送信を行うことができる。また、ユーザ装置１０は、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域全体をＧｒａｎｔ  ｆｒｅｅ  ＵＬデータリソースとして使用することもできる。また、ユーザ装置１０に対し、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域の中の特定のＧｒａｎｔ  ｆｒｅｅ  ＵＬデータリソースが基地局２０から割り当てられてもよい。この場合、ユーザ装置１０は、当該リソースを使用して、ＵＬデータ送信を行うことができる。
【００３２】
Ｇｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域がリソースプールで構成され得る点から想起されるように、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域はＳｉｄｅｌｉｎｋリソースプールであってもよく、この場合、ユーザ装置１０は、当該リソースを使用して、Ｓｉｄｌｅｉｎｋ送信を行うことができる。
【００３３】
ＤＬ  ＣＣＨ＃１、ＵＬ  ＣＣＨ、及びＧｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域は、例えば、上位レイヤシグナリングあるいはブロードキャスト信号（システム情報）により、基地局２０からユーザ装置１０に設定される。
【００３４】
なお、図３（ａ）に示す構成は一例であり、例えば、ＤＬ  ＣＣＨ＃１が存在せずにＧｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域とＵＬ  ＣＣＨとを有する構成を用いることも可能であるし、ＵＬ  ＣＣＨが存在せずにＤＬ  ＣＣＨ＃１とＧｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域とを有する構成を用いることも可能であるし、ＤＬ  ＣＣＨ＃１とＵＬ  ＣＣＨが存在せずにＧｒａｎｔ  ｆｒｅｅ  ＵＬデータリソース領域のみを有する構成を用いることも可能である。
【００３５】
ところで、ＬＴＥのＳＰＳ（Ｓｅｍｉ  Ｐｅｒｓｉｓｔｅｎｔ  Ｓｃｈｅｄｕｌｉｎｇ）において、あるＴＴＩ（サブフレーム）のＨＡＲＱプロセスＩＤは、ＳＦＮとサブフレーム番号とから決定される（非特許文献１）。例えば、ＨＡＲＱプロセスＩＤとして１、２、３を使用する場合に、ＴＴＩ毎のＨＡＲＱプロセスＩＤが、１、２、３、１、２、３．．、のように周期的に決定される。また、ＵＬのＳＰＳでは、図３（ｂ）に示すように、ユーザ装置１０における送信バッファにデータがない場合、ＳＰＳリソースで無送信としてもよい（非特許文献１）。
【００３６】
上記のようなＳＰＳのＵＬリソースも、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースの一例であると考えることができる。
【００３７】
なお、図３（ａ）、（ｂ）は、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースの一例を示すに過ぎず、本実施の形態におけるＧｒａｎｔ  ｆｒｅｅ  ＵＬリソースは、図３（ａ）、（ｂ）に示すものに限られるわけではない。
【００３８】
（Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信における動作例）
本実施の形態における処理内容の理解を助けるために、まずは、従来のＵＬ  ＳＰＳのように、サブフレーム番号に基づいて、ＴＴＩ毎にＨＡＲＱプロセスＩＤが周期的に決定される場合におけるＧｒａｎｔ  ｆｒｅｅ  ＵＬ送信の動作例を説明する。ここでの説明は、本実施の形態における技術を適用しない場合の説明であり、前述した課題の詳細説明に相当する。
【００３９】
図４（ａ）は、ＨＡＲＱプロセス数＝２、Ｇｒａｎｔ  ｆｒｅｅリソース周期＝１の場合におけるユーザ装置１０のＵＬ送信動作例を示している。１つの箱が１ＴＴＩを示し、箱内の番号がＨＡＲＱプロセスＩＤを示す。他の図でも同様である。また、以下では、図中のＴＴＩの箱に示されるＡ等の記号を用いて、ＴＴＩを示すためにＴＴＩ（Ａ）のように表記する。
【００４０】
図４（ａ）に示すように、ユーザ装置１０は、最初のＨＡＲＱプロセスＩＤ＝１のＴＴＩ（Ａ）において初回送信を行い、ＴＴＩ（Ｂ）で、ＡＣＫ／ＮＡＣＫ（Ａ／Ｎと表記）又はＵＬ  ｇｒａｎｔを受信する。従って、ＨＡＲＱプロセスＩＤ＝１となるＴＴＩ（Ｃ）においては、ＨＡＲＱバッファがクリアされていないため、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信を行うことができない。
【００４１】
図４（ｂ）は、ＨＡＲＱプロセス数＝４、Ｇｒａｎｔ  ｆｒｅｅリソース周期＝１の場合におけるユーザ装置１０のＵＬ送信動作例を示している。また、この例では、送信処理（Ｔｘ  ｐｒｏｃｅｓｓｉｎｇ）に３ＴＴＩを要することを想定している。
【００４２】
図４（ｂ）に示すように、ユーザ装置１０は、ＴＴＩ（Ａ）で初回送信を行い、ＴＴＩ（Ｂ）において、ＮＡＣＫを受信する。このＮＡＣＫでは、ＨＡＲＱプロセスＩＤ＝１が明示的に指示されてもよいし、ＮＡＣＫの時間位置で、ＨＡＲＱプロセスＩＤ＝１に対するＮＡＣＫであることが識別されてもよい。
【００４３】
ユーザ装置１０は、次にＨＡＲＱプロセスＩＤ＝１となるＴＴＩ（Ｃ）で、ＴＴＩ（Ａ）での送信に対する再送を行いたいが、ＮＡＣＫを受信してから３ＴＴＩが経過していないために、再送を行うことができない。また、新規送信も行うことができない。
【００４４】
図５は、ＵＬ  ｇｒａｎｔに基づく再送において、ＴＴＩ毎に確定的に決定されるＨＡＲＱプロセスＩＤとは異なるＨＡＲＱプロセスＩＤに対する再送がユーザ装置１０に指示される場合の例を示す。また、本例は、ＨＡＲＱプロセスＩＤを下りＬ１／Ｌ２制御チャネルで通知する非同期ＨＡＲＱの場合を示している。
【００４５】
図５に示すとおり、ユーザ装置１０は、ＴＴＩ（Ａ）において初回送信を行い、ＴＴＩ（Ｂ）においてＨＡＲＱプロセスＩＤ＝１の再送を指定したＵＬ  ｇｒａｎｔを受信する。ユーザ装置１０は、ＵＬ送信が可能になるＴＴＩ（Ｃ）において、ＨＡＲＱプロセスＩＤ＝１のＨＡＲＱプロセスでの再送を実行する。その後、ＨＡＲＱプロセスＩＤ＝１となるＴＴＩ（Ｄ）の時点では、ＨＡＲＱプロセスＩＤ＝１のＨＡＲＱバッファがクリアされていないため、ユーザ装置１０は、ＴＴＩ（Ｄ）において、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信を行うことはできない。
【００４６】
上記のように、既存のＨＡＲＱに基づく方式では、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースを使用した送信に制限が生じ、迅速に送信を行うことができない場合が生じるという課題がある。以下、当該課題を解決する手法を実施例を用いて詳細に説明する。なお、以下で説明する実施例１〜３は、適宜組み合わせて実施することが可能である。
【００４７】
（実施例１）
＜全体の動作例＞
上記のように、従来のＨＡＲＱ制御に基づくＧｒａｎｔ  ｆｒｅｅ  ＵＬ送信においては、ユーザ装置１０においてＵＬデータが発生した場合でも、直ぐにＵＬ送信を行うことができない場合が頻繁に発生し得る。
【００４８】
そこで、本実施の形態では、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースにおいて、同一のＴＴＩに複数のサブチャネルが設定される。各サブチャネルには、ＨＡＲＱプロセスＩＤが対応付けられる。ユーザ装置１０は、ＵＬデータが発生したときに、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースにおけるいずれかのサブチャネルを選択してＵＬデータ送信を行うことができる。なお、サブチャネルを「リソース」と称してもよい。サブチャネルは各ユーザ装置個別に設定されるものであってもよい。例えば各ユーザ装置で期待される送信データ量及び／又は頻度に応じて異なるサブチャネルサイズを設定することが考えられる。
【００４９】
図６は、実施例１におけるユーザ装置１０と基地局２０との間の動作例を説明するためのシーケンス図である。
【００５０】
ステップＳ１０１において、基地局２０は、サブチャネルに関する設定情報をユーザ装置１０に送信する。ユーザ装置１０は、当該設定情報を受信し、当該設定情報をメモリ等の記憶部（設定情報管理部と称してもよい）に格納する。設定情報が送信されるチャネルは、上位レイヤシグナリングチャネルでもよいし、ブロードキャストチャネルでもよいし、物理レイヤチャネルでもよいし、レイヤ２チャネルでもよいし、その他のチャネルでもよい。各サブチャネルへのＨＡＲＱプロセスＩＤの対応付けは本設定情報で明示的に通知しても良いし、予めサブチャネルの論理インデックスに対応するＨＡＲＱプロセスＩＤの算出方法を定めておき、ユーザ装置１０の最大ＨＡＲＱプロセス数に基づき基地局２０、ユーザ装置１０がそれぞれ対応するＨＡＲＱプロセスＩＤを算出してもよい。例えば、サブチャネルの「論理インデックス  ｍｏｄ  最大ＨＡＲＱプロセス数」で算出することが考えられる。この場合、例えば、サブチャネルの論理インデックスが４で最大ＨＡＲＱプロセス数が３であれば、ＨＡＲＱプロセスＩＤは１になる。複数ＴＴＩの中から送信リソースを選択する場合には、サブチャネル単位でのリソースインデックス（サブチャネルに対応する時間・周波数リソースのインデックス）を用いてＨＡＲＱプロセスＩＤを算出してもよい。
【００５１】
また、ユーザ装置間でリソースインデックスのインデックス値をランダム化するためにユーザ装置個別にリソースインデックスにオフセット値を加えてもよい。このオフセット値を時間インデックス（例えばフレーム番号など）に基づいて変化させてもよい。このような方法は、特に、同期型ＨＡＲＱを用いる場合において、リソース衝突を回避するために有効な方法である。
【００５２】
なお、基地局２０は、ユーザ装置１０に設定した設定情報と同じ設定情報を保持しており、当該設定情報と、ＵＬデータ受信に基づいて、ユーザ装置１０におけるＨＡＲＱバッファの状態を確認することができる。
【００５３】
ユーザ装置１０には、ＨＡＲＱプロセス数分のＨＡＲＱバッファが備えられている。例えば、ＨＡＲＱプロセス数が３であれば、３つのＨＡＲＱバッファが備えられる。ＨＡＲＱプロセス数は、予め定められていてもよいし、基地局２０からユーザ装置１０に設定されることとしてもよい。
【００５４】
ステップＳ１０２では、ユーザ装置１０において新規のＵＬデータが発生すると、ユーザ装置１０は、ＨＡＲＱバッファが空でないＨＡＲＱプロセスに対応するサブチャネルを除いたサブチャネルからサブチャネルを選択する。すなわち、ユーザ装置１０は、ＨＡＲＱバッファが空であるＨＡＲＱプロセスに対応するサブチャネルを選択する。サブチャネルの選択は、現在のＴＴＩ内で行ってもよいし、複数ＴＴＩの範囲から行うこととしてもよい。例えば、サブチャネルの選択範囲には前記のＵＬ  Ｇｒａｎｔ  Ｆｒｅｅ  リソース候補を用いる形態が考えられる。ＵＬデータは、選択したサブチャネルに対応するＨＡＲＱプロセスのＨＡＲＱバッファに保持される。
【００５５】
このように、異なるＨＡＲＱプロセスＩＤのサブチャネルが選択領域内（例：現在のＴＴＩ内）にあれば、ＡＣＫ／ＮＡＣＫ待ちなどによる送信不可ＴＴＩが発生する確率を減らすことができる。
【００５６】
ステップＳ１０３において、ユーザ装置１０は、ステップＳ１０２で選択したサブチャネルを使用してＵＬデータを送信する。ＵＬデータは、サブチャネルに対応するＨＡＲＱプロセスのＨＡＲＱバッファに保持されたままであり、例えば、その後、ＡＣＫを受信したときに当該ＨＡＲＱバッファがクリアされる。また、後述するように、ＡＣＫ／ＮＡＣＫ、ＵＬ  ｇｒａｎｔによる再送指示等を受信しないまま、所定のタイマ（カウンタ）が満了したときに、ＨＡＲＱバッファがクリアされることとしてもよい。
【００５７】
＜サブチャネルの詳細＞
図７は、サブチャネルの設定例を示す図である。図７において、横軸が時間であり、縦軸は周波数である。図７に示す例では、Ａで示す幅の周波数リソースが、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースの周波数リソースとしてユーザ装置１０に割り当てられるとともに、ユーザ装置１０は、所定の周期で（例：ＴＴＩ毎に）、ＴＴＩの時間長（あるいは制御チャネルを除いた時間長）分、当該周波数リソースを使用できる。このようなＧｒａｎｔ  ｆｒｅｅ  ＵＬリソースの設定は、図６のステップＳ１０１において、サブチャネルの設定といっしょに行ってもよいし、サブチャネルの設定とは別のシグナリングで行ってもよい。また、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースの設定が予めなされている（ｐｒｅｃｏｎｆｉｇｕｒｅｄ）こととしてもよい。
【００５８】
図７は、ユーザ装置１０が、ＴＴＩ毎にＧｒａｎｔ  ｆｒｅｅ  ＵＬリソースを使用できる例を示している。図７に示すサブチャネルの設定例では、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースが周波数方向に、サブチャネル１、２、３、４として４分割されている。各サブチャネルの周波数幅は、サブチャネル間で同じでもよいし、異なっていてもよい。また、図７の例では、ＨＡＲＱプロセス数＝２である。ＴＴＩ１において、サブチャネル１、３にＨＡＲＱプロセスＩＤ＝１が割り当てられ、サブチャネル２、４にＨＡＲＱプロセスＩＤ＝２が割り当てられる。そして、各サブチャネルにおいて、ＴＴＩが１増えると、増える前のＴＴＩのＨＡＲＱプロセスＩＤの次のＩＤが割り当てられる（２の場合は１になる）。
【００５９】
図６のステップＳ１０１の設定情報には、例えば、サブチャネル毎の時間・周波数リソースインデックス（周波数リソースインデックスのみでもよい）が含まれる。また、当該設定情報が、ユーザ装置１０に割り当てられるＧｒａｎｔ  ｆｒｅｅ  ＵＬリソースの周波数方向の分割数であってもよい。この場合、図７の例では、設定情報により４分割が指定される。
【００６０】
サブチャネルに対応付けられるＨＡＲＱプロセス番号については、例えば、ステップＳ１０１の設定情報により、サブチャネル１＝｛１，２，１，２｝（ＴＴＩ１、２、３、４にそれぞれ、ＩＤ＝１、２、１、２が割り当てられることを示す）、サブチャネル２＝｛２，１，２，１｝、サブチャネル３＝｛１，２，１，２｝、サブチャネル４＝｛２，１，２，１｝のように明示的に指示される。また、明示的な指示に変えて、サブチャネルの時間及び／又は周波数のリソースインデックス（番号）と、ＨＡＲＱプロセスＩＤとの間の対応関係を予め定めておき（ユーザ装置１０と基地局２０が同じ対応関係を保持する）、当該対応関係に従って、ユーザ装置１０は、あるＴＴＩで使用するあるサブチャネルに対応するＨＡＲＱプロセスＩＤを決定する。基地局２０は、当該ＴＴＩで当該サブチャネルによりＵＬデータを受信した場合に、当該対応関係に基づいて、ユーザ装置１０の認識するＨＡＲＱプロセスＩＤと同じＨＡＲＱプロセスＩＤを決定できる。
【００６１】
一例として、ＨＡＲＱプロセスＩＤが、ＨＡＲＱプロセスＩＤ＝ｆ（サブチャネル番号，サブフレーム番号）として、サブチャネル番号とサブフレーム番号（＝ＴＴＩ番号と称してもよい）の関数で表わされてもよい。
【００６２】
また、ルールの一例として、Ｓ１０１の設定情報により、あるＴＴＩのサブチャネル毎のＨＡＲＱプロセスＩＤを基地局２０からユーザ装置１０に指定し、ユーザ装置１０（及び基地局２０）は、サブチャネル毎に、当該ＴＴＩから、ＴＴＩ毎に、ＨＡＲＱプロセスＩＤがサイクリックに変化するものと認識してもよい。例えば、ＨＡＲＱプロセス数＝３として、ＴＴＩ１において、サブチャネル１、２、３、４に対してそれぞれ、ＨＡＲＱプロセスＩＤ＝１、２、３、１が割り当てられた場合、ユーザ装置１０（及び基地局２０）は、例えば、サブチャネル３のＴＴＩ１、２，３、４におけるＨＡＲＱプロセスＩＤは、３、１、２、３であると決定することができる。
【００６３】
上記のように、ＨＡＲＱプロセスＩＤを明示的に指定せずに、ルールを定めておくことで、シグナリングオーバーヘッドを削減できる。
【００６４】
＜選択候補について＞
図６のステップＳ１０２で説明したように、ユーザ装置１０は、ＨＡＲＱバッファが空きであるＨＡＲＱプロセスに対応するサブチャネルを選択してＵＬデータの送信を行う。
【００６５】
前述したように、ユーザ装置１０は、サブチャネルの選択を、１ＴＴＩ内（例：ＵＬデータが発生したＴＴＩ）で行なってもよいし、サブチャネルの選択を、複数ＴＴＩから行なってもよい。図８（ａ）、（ｂ）は、選択候補の例を示す図である。図８（ａ）の例は、ＴＴＩ１〜４の時間領域のリソース（サブチャネル）が選択候補である例を示す、図８（ｂ）の例は、ＴＴＩ１の領域が選択候補である例を示している。図８（ａ）の例では、ＴＴＩ３のサブチャネル１が選択されており、図８（ｂ）の例では、サブチャネル１が選択されている。
【００６６】
図８（ａ）の例において、例えば、ＵＬデータ送信のためのサブチャネルを選択する時点がＴＴＩ１である場合において、将来の時刻（ＴＴＩ２〜４）においてＨＡＲＱバッファが空きかどうかに関して、ユーザ装置１０は、例えば、現在のＴＴＩ１におけるＨＡＲＱバッファの空塞状態を将来の時刻（ＴＴＩ２〜４）での空塞状態を見なすことができる。また、後述するカウンタの満了時刻、もしくは、基地局２０から受信する制御信号（Ａ／Ｎ、ＵＬ  ｇｒａｎｔ）に基づいて、現在は空きではないＨＡＲＱバッファであるが、将来空きになることが予測できるＨＡＲＱバッファについては、選択の対象としてよい。
【００６７】
図８（ａ）に示した場合のように、複数ＴＴＩを用いることで、選択候補のリソースを増加させることができるとともに、ユーザ装置間でリソース候補（Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースのリソースプール）を共有している場合に衝突確率を減少させることができる。
【００６８】
また、選択候補とする時間ウィンドウ（ＴＴＩ数等で指定）については、予めユーザ装置１０と基地局２０において同じ大きさのウィンドウが決められていてもよいし、基地局２０からユーザ装置１０に対してユーザ装置個別に（ＵＥ  ｓｐｅｃｉｆｉｃに）設定することとしてもよい。また、選択候補の開始時間位置及び時間長（ウィンドウ幅）をユーザ装置１０が選択することとしてもよいし、基地局２０からユーザ装置１０に設定してもよい。なお、時間長については、ユーザ装置１０（又は基地局２０）は、遅延要求条件に基づき決定してもよい。
【００６９】
＜衝突確率の減少について＞
各ユーザ装置に対して、異なる選択候補（１ＴＴＩにおける複数サブチャネル、或いは、複数ＴＴＩにおける複数サブチャネル）から、ＵＬデータの送信リソースを選択することを許容する場合、オーバーヘッドが増加する。そのため、同じ選択候補のリソースを複数のユーザ装置に割り当ててオーバーヘッドを削減することが望ましい。
【００７０】
この場合、ユーザ装置間で衝突（Ｃｏｎｔｅｎｔｉｏｎ）が発生する可能性がある。送信リソース選択の任意性が高いほどあるリソースを共有するユーザ装置数が増加し得るため、基地局２０におけるＣｏｎｔｅｎｔｉｏｎの検出、送信ユーザ装置の識別（検出）がより困難になる可能性がある。
【００７１】
上記のような衝突の確率を減少させるために、実施例１において、サブチャネルとＨＡＲＱプロセスＩＤとのマッピングをＵＥ  ｓｐｅｃｉｆｉｃとしてよい。すなわち、サブチャネルとＨＡＲＱプロセスＩＤとのマッピングをユーザ装置間で異なるものとしてよい。
【００７２】
図９（ａ）、（ｂ）は、ＵＥ＃１とＵＥ＃２間で、サブチャネルの設定は同じであり（同じリソースを同じサブチャネルで使用）、サブチャネルに対するＨＡＲＱプロセスＩＤのマッピングが異なる場合の例を示している。
【００７３】
図９（ａ）、（ｂ）の例は、ともにＨＡＲＱプロセス数＝４であり、サブチャネル１、２、３、４が設定されている。図９（ａ）に示すＵＥ＃１は、ＴＴＩ１のサブチャネル３を使用して、ＨＡＲＱプロセスＩＤ＝３における初回のＵＬデータ送信を行う。ここでは、再送を実行するサブフレーム間隔（ＴＴＩ間隔）が予め定められている同期型ＨＡＲＱの再送を行うものとし、ＵＥ＃１は、ＨＡＲＱプロセスＩＤ＝３における再送を、ＴＴＩ３で行う。この再送は、基地局２０からの指示（ＵＬ  ｇｒａｎｔ、ＮＡＣＫ等）で行われてもよいし、ＵＥ＃１が自律的に行ってもよい。図９（ａ）に示すように、このマッピングでは、サブチャネル３により再送がなされる。
【００７４】
図９（ｂ）に示すマッピングがなされているＵＥ＃２は、初回のＵＬデータ送信（ＨＡＲＱプロセスＩＤ＝３）を、ＵＥ＃１と同じリソース（ＴＴＩ１、サブチャネル３）で行う。一方、ＨＡＲＱプロセスＩＤとサブチャネルとのマッピングがＵＥ＃１と異なるので、再送は、ＵＥ＃１とは異なるリソース（サブチャネル１）で行われる。
【００７５】
上記のように、特に同期型のＨＡＲＱ再送を用いる場合において、ＨＡＲＱプロセスＩＤとサブチャネルとのマッピングをユーザ装置間で異なるものとすることで、ユーザ装置間のＵＬデータ送信の衝突確率を減少させることができる。
【００７６】
＜再送のためのＨＡＲＱプロセスＩＤの通知について＞
本実施例の技術は、ＵＬ  ｇｒａｎｔを使用するＡｄａｐｔｉｖｅ型の再送と、ＵＬ  ｇｒａｎｔを使用しないＮｏｎ−Ａｆａｐｔｉｖｅ型の再送のどちらでも適用可能である。
【００７７】
ここで、ＵＬ  ｇｒａｎｔを使用する再送を適用する場合において、基地局２０は、ユーザ装置１０に対して、再送のためのＵＬ  ｇｒａｎｔにより、再送の対象となるＨＡＲＱプロセスＩＤを指定してもよいし、指定しなくてもよい。
【００７８】
ＨＡＲＱプロセスＩＤを指定しない場合、ユーザ装置１０は、ＵＬ  ｇｒａｎｔで割り当てられた再送のためのリソースに基づいて（例えば、再送のために割り当てられた時間・周波数リソースのうちの先頭の周波数リソース位置に基づいて）、ＨＡＲＱプロセスＩＤを認識することができる。すなわち、ユーザ装置１０は、例えば図７に示すようにして設定された時間・周波数リソースとＨＡＲＱプロセスＩＤとのマッピングに基づいて、再送のためのリソースに対応するＨＡＲＱプロセスＩＤを、再送を指示されたＨＡＲＱプロセスＩＤであると認識することができる。
【００７９】
より具体的には、例えば、ユーザ装置１０が、図７に示すＴＴＩ２の先頭にある制御チャネルで再送指示のＵＬ  ｇｒａｎｔを受信し、当該ＵＬ  ｇｒａｎｔにより、再送のためのリソースとして、サブチャネル２が指定されていたとすると、ユーザ装置１０は、ＨＡＲＱプロセスＩＤ＝１に対する再送指示であることを認識し、例えば、ＴＴＩ２のサブチャネル２を使用して再送を実施する。
【００８０】
上記のように、ＨＡＲＱプロセスＩＤを指定しないことで、下り制御情報のオーバヘッドが削減され、下り制御情報の信頼性も向上する。
【００８１】
基地局２０が、再送のためのＵＬ  ｇｒａｎｔにより、再送の対象となるＨＡＲＱプロセスＩＤを指定する場合、ユーザ装置１０は、例えば、ＵＬ  ｇｒａｎｔで通知された再送のための時間・周波数リソースに紐付けられたＨＡＲＱプロセスＩＤを用いずに、ＵＬ  ｇｒａｎｔで通知されたＨＡＲＱプロセスＩＤを用いる。なお、基地局２０が、再送のためのＵＬ  ｇｒａｎｔにより、再送の対象となるＨＡＲＱプロセスＩＤを指定する場合、基地局２０は、再送を指示するＨＡＲＱプロセスＩＤに紐付られた時間・周波数リソースを、再送のためのリソースとして指示してもよい。
【００８２】
＜参照信号とＨＡＲＱプロセスＩＤとの紐付について＞
ＨＡＲＱプロセスＩＤは参照信号（例えばＤＭＲＳ）の設定に紐付いて設定されてもよい。例えば、図６のステップＳ１０１において、基地局２０がユーザ装置１０に対し、サブチャネル毎に、サブチャネルのリソース情報と、それに対応する参照信号の設定情報（例えば、時間・周波数リソース位置、系列、サイクリックシフト、ＯＣＣのうちのいずれか１つ又は複数）とを通知する。同一リソース（同一サブチャネル）に異なる複数の参照信号が対応付けられていてもよい。
【００８３】
そして、リソース毎（サブチャネル毎、あるいは、サブチャネルとＴＴＩの組毎）に、参照信号とＨＡＲＱプロセスＩＤとの間には、例えば、｛参照信号Ａ，ＨＡＲＱプロセスＩＤ＝Ｎ１｝、｛参照信号Ｂ，ＨＡＲＱプロセスＩＤ＝Ｎ２｝...のように、対応関係が定められている。この対応関係は、ユーザ装置１０と基地局２０において予め設定されていてもよいし、基地局２０からユーザ装置１０に対して当該対応関係を設定してもよい。
【００８４】
そして、ユーザ装置１０が、ある空きのバッファをもつＨＡＲＱプロセスＩＤを使用してＵＬデータ送信を行う際に、ユーザ装置１０は、当該ＨＡＲＱプロセスＩＤに対応するサブチャネルと参照信号の組（１つの場合をそれを選択）から、１つのサブチャネルと参照信号の組を選択し、選択したサブチャネルと参照信号を使用してＵＬデータを送信する。基地局２０は、ＵＬデータの受信に使用したサブチャネルと参照信号とからＨＡＲＱプロセスＩＤを識別できる。
【００８５】
上記のような紐付けを行うことで、より多くのＨＡＲＱプロセスＩＤを用いることができる。
【００８６】
＜Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースの通知について＞
基地局２０は、ユーザ装置１０に対し、例えばＴＴＩ毎に、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信に利用可能な（あるいはＧｒａｎｔ  ｆｒｅｅ  ＵＬ送信に利用不可能な）リソース（例：時間・周波数リソース）のインデックスを通知してもよい。一例として、図７で示す例において、ＴＴＩ１でサブチャネル１とサブチャネル２が利用可能である場合、基地局２０はユーザ装置１０に対し、ＴＴＩ１ではサブチャネル１とサブチャネル２が利用可能であることを示す情報を通知する。この通知は、ＴＴＩ１の前に行っても良いし、ＴＴＩ１（例えば、ＴＴＩ１の先頭）で行ってもよい。また、例えば、ＴＴＩ毎に、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信に利用可能な（あるいはＧｒａｎｔ  ｆｒｅｅ  ＵＬ送信に利用不可能な）リソースに紐付られたＨＡＲＱプロセスＩＤを通知してもよい。一例として、図９（ａ）で示す例において、ＴＴＩ１でサブチャネル１とサブチャネル２が利用可能である場合、基地局２０はユーザ装置１０に対し、ＴＴＩ１において、ＨＡＲＱプロセスＩＤ＝１、２が利用可能であることを示す情報を通知する。
【００８７】
上記のような通知を行うことで、あるユーザ装置において、再送などで送信に用いられることが判明しているリソースを他のユーザ装置による送信に用いられないよう保護することができる。
【００８８】
＜ＨＡＲＱバッファをクリアするカウンタについて＞
ユーザ装置１０において、バッファをクリアするためのカウンタ（タイマと称してもよい）を、各ＨＡＲＱプロセス毎に備えてもよい。
【００８９】
カウンタには、初期値が設定される。当該初期値は、例えば、ＴＴＩ数である。初期値が、時間であってもよい。なお、ＴＴＩ数は時間であると解釈することができる。初期値は、例えば、基地局２０からユーザ装置１０への上位レイヤシグナリング（例：ＲＲＣ信号）により設定される。また、当該初期値が、ユーザ装置１０と基地局２０に予め設定されていることとしてもよい。
【００９０】
各ＨＡＲＱプロセスで同様の処理が行われる。あるＨＡＲＱプロセスにおける初回のＵＬデータ送信時にカウンタは初期値にリセットされ、当該カウンタはＴＴＩ毎にカウントされる。つまり、カウンタの値がＴＴＩの経過に応じて、経過したＴＴＩ数だけ減算されていく。そして、カウンタが０になるまでに（つまり、カウンタが満了するまでに）、当該ＨＡＲＱプロセスのＨＡＲＱバッファがクリアされていなければ、カウンタが０になった時点（つまり、カウンタが満了した時点）で、当該ＨＡＲＱバッファがクリアされる。
【００９１】
図１０に例を示す。図１０（ａ）では、ユーザ装置１０によるＵＬデータ送信後、カウンタの満了前にＡＣＫを受信することで、該当ＨＡＲＱバッファがクリアされる。図１０（ｂ）では、ユーザ装置１０によるＵＬデータ送信後、ＡＣＫ／ＮＡＣＫ等を受信することなくカウンタが満了し、ＨＡＲＱバッファがクリアされる。図示するように、ユーザ装置１０は、カウンタ満了によりＨＡＲＱバッファをクリアした場合、データ（パケット）を破棄したことを通知する情報（例：破棄したデータのＨＡＲＱプロセスＩＤを含む）を基地局２０に送信してもよい。
【００９２】
また、カウンタのカウントについては、上記のようにＴＴＩ毎に行うことの他、該当ＨＡＲＱプロセスにおけるＵＬデータ送信毎、もしくは、Ａ／Ｎフィードバック受信毎に行うこととしてもよい。
【００９３】
例えば、ユーザ装置１０によりＵＬデータが送信されてから、もしくは、基地局２０からＮＡＣＫがフィードバックされてから、カウンタでカウントされる一定時間以内にＵＬ  ｇｒａｎｔで再送指示が行われない場合、ユーザ装置１０は、該当するＨＡＲＱバッファをクリアする。あるいは、ユーザ装置１０は、一定回数のＮｏｎ−ａｄａｐｔｉｖｅ再送後にＨＡＲＱバッファをクリアすることとしてもよい。
【００９４】
ＵＬデータの破棄は、ユーザ装置１０において、下位レイヤから（例：ＭＡＣレイヤ）から上位レイヤ（例：ＲＲＣレイヤ）に通知される。そして、例えば、図１０（ｂ）に示したように、ＵＬデータの破棄を行ったことを示す情報が基地局２０に送信される。
【００９５】
上記のように、時間を計測するカウンタ（タイマ）を使用したＨＡＲＱバッファのクリア制御を行うことにより、許容遅延を超過したデータを再送し続けることによる新規データの送信機会の損失を回避することができる。
【００９６】
＜複数のＨＡＲＱプロセスでのデータ送信について＞
あるＴＴＩにおいて、異なるＨＡＲＱプロセスＩＤに紐付けられた複数のリソース（サブチャネル）が存在する場合において、ユーザ装置１０は、複数の（例えば２つの）ＨＡＲＱプロセスでデータを同時に送信してもよい。
【００９７】
一例として、図７におけるＴＴＩ１（選択候補のＴＴＩ）において、ＨＡＲＱプロセスＩＤ＝１、２の両方のバッファが空きであり、基地局２０からサブチャネル２と３が利用可能であることを通知された場合において、ユーザ装置１０は、サブチャネル２を使用してＨＡＲＱプロセスＩＤ＝２でＵＬデータ送信を行うことと同時に、サブチャネル３を使用して、ＨＡＲＱプロセスＩＤ＝１でＵＬデータ送信を行う。
【００９８】
Ｇｒａｎｔ  ｆｒｅｅ  ＵＬ送信のために設定されたリソースサイズはｓｅｍｉ−ｓｔａｔｉｃに定められ、ユーザ装置１０のバッファ（例：ＨＡＲＱバッファよりも上位のバッファであり、例えば、ＩＰデータバッファ、ＰＤＣＰバッファ、もしくはＲＬＣバッファ）に格納されたデータに対して十分なリソースが確保できない場合が考えられる。そこで、上記の同時送信を行うことで、ユーザ装置１０が、バッファ内のデータを複数パケットに分割して送信することが可能になり、ある所定のＭＣＳを仮定した場合に送信可能なデータ量を増やすことができる。
【００９９】
＜Ｄｙｎａｍｉｃ  ＴＤＤにおける動作例＞
５Ｇでは、サブフレーム（ＴＴＩ）におけるＵＬとＤＬを動的に切り替えるＤｙｎａｍｉｃ  ＴＤＤが導入されることが想定される。本実施例で説明した技術を使用することで、Ｄｙｎａｍｉｃ  ＴＤＤによりＵＬ送信ができないＴＴＩが生じた場合でも、サブチャネル毎のＨＡＲＱプロセスＩＤ設定により、同期型ＨＡＲＱの動作を実行することが可能である。
【０１００】
例えば、図１１（ａ）に示すフレームにおいて、ＴＴＩ（Ａ）が、もともと、ＨＡＲＱプロセスＩＤ＝１が割り当てられるＵＬのサブフレームであり、Ｄｙｎａｍｉｃ  ＴＤＤにより、ＤＬに変わったものとする。この場合、ＴＴＩ（Ｂ）（ＨＡＲＱプロセスＩＤ＝１）で初回のＵＬデータ送信を行ったユーザ装置１０は、ＴＴＩ（Ａ）でＵＬ送信を行うことができず、同期型ＨＡＲＱにおける再送を行うことができない、あるいは、大きな遅延が発生する。
【０１０１】
一方、図１１（ｂ）に示す例では、これまでに説明したように、ＵＬリソースにサブチャネルが設定されている。この場合、ユーザ装置１０は、ＴＴＩ（Ｂ）（ＨＡＲＱプロセスＩＤ＝１）で初回のＵＬデータ送信を行った後に、ＴＴＩ（Ｃ）のＨＡＲＱプロセスＩＤ＝１に対応するサブチャネルで再送を行うことができる。
【０１０２】
＜ＨＡＲＱプロセスＩＤの変更について＞
ＵＬ  ｇｒａｎｔ等の基地局２０からユーザ装置１０へのＬ１／Ｌ２制御情報により、以降のＧｒａｎｔ  ｆｒｅｅ  ＵＬリソースのＨＡＲＱプロセスＩＤを変更してもよい。ここでの説明は、サブチャネルの設定を前提としてもよいし、サブチャネルの設定を前提としなくてもよい。サブチャネルの設定を前提とする場合、以下で説明する図１２（ａ），（ｂ）は、１つのサブチャネルに関するものと考えてよい。また、以下で説明する図１２（ａ），（ｂ）の例では、これまでの例と同様に、基本的に、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースにＨＡＲＱプロセスＩＤが対応付られている。
【０１０３】
例えば、図１２（ａ）に示す例において、ユーザ装置１０が、ＴＴＩ（Ａ）において初回のＵＬデータ送信（ＨＡＲＱプロセスＩＤ＝１）を行う。そして、ユーザ装置１０は、ＴＴＩ（Ｂ）で、ＨＡＲＱプロセスＩＤ＝１を指定したＵＬ  ｇｒａｎｔにより、再送指示を受信する。そして、ユーザ装置１０は、次のＴＴＩ（Ｃ）でＨＡＲＱプロセスＩＤ＝１のＨＡＲＱプロセスにより再送ＵＬデータを送信する。
【０１０４】
もともとのＴＴＩ（Ｃ）におけるＨＡＲＱプロセスＩＤは４であるが、ＵＬ  ｇｒａｎｔによるＨＡＲＱプロセスＩＤ＝１の指示により、ＴＴＩ（つまり、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソース）と、ＨＡＲＱプロセスＩＤのマッピングが変更される。図１２（ａ）の例では、ＨＡＲＱプロセスＩＤのＴＴＩへのマッピングが１つ左にずれる形になっている。仮に、ＴＴＩ（Ｃ）以降において、元のマッピングを維持する場合、ＴＴＩ（Ｄ）のＨＡＲＱプロセスＩＤは１になる。しかし、ＨＡＲＱプロセスＩＤ＝１のバッファは、使用中であり、ＴＴＩ（Ｄ）においてＨＡＲＱプロセスＩＤ＝１での送信を行うことができない。他方、本例のように、マッピングを更新することで、例えば、ＴＴＩ（Ｄ）（ＨＡＲＱプロセスＩＤ＝２）においてＨＡＲＱバッファが空きである可能性があり、空きであればＴＴＩ（Ｄ）においてＵＬ送信を行うことができる。
【０１０５】
図１２（ｂ）に示す例では、ユーザ装置１０が、ＴＴＩ（Ａ）において初回のＵＬデータ送信（ＨＡＲＱプロセスＩＤ＝１）を行う。そして、ユーザ装置１０は、ＴＴＩ（Ｂ）で、ＨＡＲＱプロセスＩＤ＝１を指定したＵＬ  ｇｒａｎｔにより、再送指示を受信し、次のＴＴＩ（Ｃ）でＨＡＲＱプロセスＩＤ＝１のＨＡＲＱプロセスにより、再送ＵＬデータを送信する。図１２（ｂ）の例では、ＴＴＩ（Ｄ）におけるＨＡＲＱプロセスＩＤを、ＴＴＩ（Ｃ）におけるもともとのＨＡＲＱプロセスＩＤである４に更新している。この場合も、図１２（ａ）の場合と同様に、ＴＴＩ（Ｄ）においてＨＡＲＱプロセスＩＤ＝１での送信を行うことができないが、マッピングを更新することで、ＴＴＩ（Ｄ）（ＨＡＲＱプロセスＩＤ＝４）においてＨＡＲＱバッファが空きである可能性があり、空きであればＴＴＩ（Ｄ）においてＵＬ送信を行うことができる。
【０１０６】
上記の処理により、ＨＡＲＱバッファが空でないＴＴＩの出現率を減らすことができ、低遅延のＧｒａｎｔ  ｆｒｅｅ  ＵＬ送信を実現できる。
【０１０７】
（実施例２）
次に、実施例２を説明する。実施例２は実施例１を前提としている。実施例２では、ユーザ装置１０がＵＬデータ送信のために選択可能な複数のサブチャネル（リソース）が存在し、各サブチャネルに異なるＨＡＲＱプロセスＩＤが設定されている場合において、ユーザ装置１０は、ＨＡＲＱプロセスＩＤの優先順位に基づいてサブチャネルを選択する。
【０１０８】
例えば、図１３に示すサブチャネルとＨＡＲＱプロセスＩＤとのマッピングが、ＵＥ１とＵＥ＃２（及び基地局２０）に設定されているとする。また、ＵＥ＃１にはＨＡＲＱプロセスＩＤの優先順位として［１，２，３，４］が設定され、ＵＥ＃２にはＨＡＲＱプロセスＩＤの優先順位として［３，４，１，２］が設定されている。なお、［１，２，３，４］は、ＨＡＲＱプロセスＩＤが優先度の降順で並べられたリストである。つまり、この場合、ＨＡＲＱプロセスＩＤ＝１の優先度が最も高い。［３，４，１，２］の場合、ＨＡＲＱプロセスＩＤ＝３の優先度が最も高い。
【０１０９】
このような設定の下、ＵＥ＃１は、ＨＡＲＱプロセスＩＤ＝１のＨＡＲＱプロセスが利用可能であれば（つまりＨＡＲＱバッファが空きであれば）、このＩＤに紐付けられたリソース（ＴＴＩとサブチャネルの組）から任意のリソースを選択（例えばランダム選択）してＧｒａｎｔ  ｆｒｅｅ  ＵＬ送信を行う。ＨＡＲＱプロセスＩＤ＝１のＨＡＲＱプロセスが利用可能でない場合、ＨＡＲＱプロセスＩＤ＝２のＨＡＲＱプロセスが利用可能であればそれを使用する。このように、優先順位に従ってＨＡＲＱプロセスの選択が行われる。ＵＥ＃２も同様に、優先順位に従ってＨＡＲＱプロセスの選択を実行する。
【０１１０】
上記の例では、ＨＡＲＱプロセスＩＤを、ＵＬデータ送信のためのリソース候補の優先度付けに使用しているが、これは一例であり、ＨＡＲＱプロセスＩＤ以外の情報をＵＬデータ送信のためのリソース候補の優先度付けに使用しても良い。例えば、リソースインデックス（例：サブチャネル番号、時間・周波数リソースのインデックス、ＴＴＩとサブチャネルとの組を示すインデックス）を、リソース候補の優先度付けに使用してもよいし、これら以外の識別子をリソース候補の優先度付けに使用してもよい。
【０１１１】
基地局２０は、ユーザ装置１０が利用可能なＨＡＲＱプロセスＩＤを把握している。そのため、上記のような優先度制御が実行されることで、基地局２０は、あるユーザ装置がＵＬデータ送信のために選択する可能性のあるリソースを、利用可能ＨＡＲＱプロセスＩＤと優先順位に基づいて絞り込むことができ、ユーザ装置の検出が容易になる。
【０１１２】
（実施例３）
実施例３では、例えば、図１４（ａ）に示されるように、Ｇｒａｎｔ  ｆｒｅｅ  ＵＬリソースを区切る設定（サブチャネルの設定）は行われるが、これまでに説明したような、サブチャネルとＨＡＲＱプロセスＩＤとのマッピングの設定がなされない。そこで、ユーザ装置１０は、ＵＬデータの送信時に、ＨＡＲＱプロセスＩＤを基地局２０に通知する。
【０１１３】
一例として、ユーザ装置１０が、ＴＴＩ１においてサブチャネル２で、ＨＡＲＱプロセスＩＤ＝１のＨＡＲＱプロセスでＵＬデータを送信すると想定する。この場合、図１４（ｂ）に示すように、ユーザ装置１０は、ＵＬデータの送信リソースのうちの一部のリソースを使用して、ＨＡＲＱプロセスＩＤ＝１の情報を有するＵＬ制御情報（又はプリアンブル）を基地局２０に送信する。基地局２０は、受信するＵＬデータのＨＡＲＱプロセスＩＤを、当該ＵＬ制御情報から取得できる。当該ＵＬ制御情報は、初回送信のみならず、再送時にも送信される情報である。
【０１１４】
例えば、ＵＬ制御情報は、ＵＬデータと時間・周波数又は符号で多重され、予め定められたＭＣＳで符号化され、予め定められたリソース位置及び／又はリソースサイズを使用して、予め定めたデータサイズで送信されるものであってもよい。これにより、基地局２０は、ＵＬ制御情報をブラインドで容易に検出することが可能となる。
【０１１５】
実施例３の処理により、Ｓｅｍｉ−ｓｔａｔｉｃなＨＡＲＱプロセスＩＤの設定が不要になり、ユーザ装置１０は、ＨＡＲＱバッファの状態に応じて、利用可能な任意のＨＡＲＱプロセスＩＤでＵＬデータを送信することが可能となる。
【０１１６】
（サイドリンクへの適用について）
これまでに説明した例は、図１に示したように、ユーザ装置１０から基地局２０へのＵＬデータ送信に関するものであるが、本発明に係る技術は、図２に示すように、ユーザ装置間の通信（Ｄ２Ｄ、サイドリンク）にも適用できる。その場合、例えば、図２の例において、ユーザ装置１０からユーザ装置３０へのデータ送信に着目する場合、これまでの説明におけるユーザ装置１０の動作をユーザ装置１０が実行し、基地局２０の動作をユーザ装置３０が実行する。ただし、この場合、ユーザ装置１０は、基地局２０からデータ送信のための、サブチャネルとＨＡＲＱプロセスＩＤとのマッピング情報の設定を受け、ユーザ装置３０は、データ受信のためのサブチャネルとＨＡＲＱプロセスＩＤとのマッピング情報の設定を受ける。基地局２０からの設定を行うことに代えて、これらの情報が予めユーザ装置１０とユーザ装置３０に設定された情報であってもよい。
【０１１７】
（装置構成）
次に、これまでに説明した実施の形態の動作を実行するユーザ装置１０及び基地局２０の機能構成例を説明する。ユーザ装置１０及び基地局２０はそれぞれ、本実施の形態で説明した全ての機能（実施例１〜３を含む）を備える。ただし、ユーザ装置１０及び基地局２０はそれぞれ、本実施の形態で説明した全ての機能の中の一部の機能のみを備えることとしてもよい。
【０１１８】
＜ユーザ装置＞
図１５は、実施の形態に係るユーザ装置１０の機能構成の一例を示す図である。図１５に示すように、ユーザ装置１０は、信号送信部１０１と、信号受信部１０２と、設定情報管理部１０３と、再送制御部１０４とを有する。図１５に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。
【０１１９】
信号送信部１０１は、送信データから送信信号を作成し、当該送信信号を無線で送信する。信号受信部１０２は、各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する。
【０１２０】
設定情報管理部１０３は、信号受信部１０２により基地局２０から受信した各種の設定情報を格納する。設定情報の内容はこれまでに説明したとおりである。また、設定情報管理部１０３は、ユーザ装置１０に予め設定される（ｐｒｅｃｏｎｆｉｇｕｒｅｄ）設定情報も格納する。
【０１２１】
再送制御部１０４は、ＨＡＲＱプロセス毎のＨＡＲＱバッファ、ＨＡＲＱプロセス毎の処理機能部を含む。あるＨＡＲＱプロセスの処理機能部は、例えば、ＵＬデータ送信に対する基地局２０からのフィードバックに基づいて、再送を行うかどうかを判定する機能を含む。また、再送制御部１０４は、設定情報に基づいて、本実施の形態で説明したＨＡＲＱプロセスＩＤを決定を行う機能、サブチャネルを選択する機能も含む。
【０１２２】
なお、再送制御部１０４の機能が信号送信部１０１に含まれることとしてもよく、その場合の信号送信部１０１を、送信部と称してもよい。
【０１２３】
設定情報管理部１０３は、前記ユーザ装置１０とは異なる通信装置（例:基地局２０、ユーザ装置３０）からデータ送信許可を受信することなくデータを送信することが可能な複数の区分リソースに関する設定情報を保持するように構成されてもよい。
【０１２４】
前記複数の区分リソースのそれぞれは、再送制御プロセスに対応付けられており、前記送信部は、当該複数の区分リソースから、再送制御用バッファが空きである再送制御プロセスに対応する区分リソースを選択し、当該区分リソースを用いて、データを送信するように構成されてもよい。
【０１２５】
前記設定情報は、例えば、前記複数の区分リソースを示す情報に加えて、区分リソースと再送制御プロセスの識別子との間のマッピング情報を含む。前記複数の区分リソースにおけるそれぞれの区分リソースに、１種類又は複数種類の参照信号が対応付けられており、更に、各種類の参照信号に、再送制御プロセスが対応付けられており、前記送信部は、ある再送制御プロセスを使用してデータを送信する場合に、当該再送制御プロセスに対応する参照信号を用いて前記データを送信するように構成されてもよい。
【０１２６】
前記送信部は、時間を計測するカウンタを備えており、ある再送制御プロセスにおける再送制御用バッファにデータが格納された状態のまま、前記カウンタにより、所定時間の経過が検出された場合に、当該再送制御用バッファをクリアするように構成されてもよい。前記送信部において使用される複数の再送制御プロセスに優先順位が設定されており、当該送信部は、当該優先順位に従って、再送制御用バッファが空きである再送制御プロセスを選択し、当該再送制御プロセスに対応する区分リソースを選択するように構成されてもよい。
【０１２７】
また、送信部は、実施例３で説明したように、ＨＡＲＱプロセスＩＤを含むＵＬ制御情報を多重したＵＬデータを送信するように構成されている。
【０１２８】
＜基地局２０＞
図１６は、本実施の形態に係る基地局２０の機能構成の一例を示す図である。図１６に示すように、基地局２０は、信号送信部２０１と、信号受信部２０２と、設定情報管理部２０３と、再送制御部２０４とを有する。図１６に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。
【０１２９】
信号送信部２０１は、ユーザ装置１０側に送信する信号を生成し、当該信号を無線で送信する機能を含む。信号受信部２０２は、ユーザ装置１０から送信された各種の信号を受信し、受信した信号から、例えばより上位のレイヤの情報を取得する機能を含む。
【０１３０】
設定情報管理部２０３は、ユーザ装置１０に送信する各種の設定情報を格納する。設定情報の内容はこれまでに説明したとおりである。また、設定情報管理部２０３は、基地局２０に予め設定される（ｐｒｅｃｏｎｆｉｇｕｒｅｄ）設定情報も格納する。
【０１３１】
再送制御部２０４は、ＨＡＲＱプロセス毎のＨＡＲＱバッファ、ＨＡＲＱプロセス毎の処理機能部を含む。あるＨＡＲＱプロセスの処理機能部は、例えば、ＵＬデータを受信し、ＨＡＲＱプロセスＩＤを識別し、復号処理等を行って、ＡＣＫ／ＮＡＣＫ等を返す機能を含む。なお、信号受信部２０２と再送制御部２０４は、実施例３で説明したように、ＨＡＲＱプロセスＩＤを含むＵＬ制御情報を多重したＵＬデータを送信した場合に、ＵＬ制御情報からＨＡＲＱプロセスＩＤを取得して、ＵＬデータのＨＡＲＱプロセスＩＤを識別する機能を含む。
【０１３２】
＜ハードウェア構成＞
上記実施の形態の説明に用いたブロック図（図１５〜図１６）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に複数要素が結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。
【０１３３】
また、例えば、本発明の一実施の形態におけるユーザ装置１０と基地局２０はいずれも、本実施の形態に係る処理を行うコンピュータとして機能してもよい。図１７は、本実施の形態に係るユーザ装置１０と基地局２０のハードウェア構成の一例を示す図である。上述のユーザ装置１０と基地局２０はそれぞれ、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。
【０１３４】
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。ユーザ装置１０と基地局２０のハードウェア構成は、図に示した１００１〜１００６で示される各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
【０１３５】
ユーザ装置１０と基地局２０における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。
【０１３６】
プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）で構成されてもよい。
【０１３７】
また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール又はデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、図１５に示したユーザ装置１０の信号送信部１０１、信号受信部１０２、設定情報管理部１０３、再送制御部１０４は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。また、例えば、図１６に示した基地局２０の信号送信部２０１と、信号受信部２０２と、設定情報管理部２０３、再送制御部２０４は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。
【０１３８】
メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ  Ｅｒａｓａｂｌｅ  Ｐｒｏｇｒａｍｍａｂｌｅ  ＲＯＭ）、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施の形態に係る処理を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。
【０１３９】
ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ  ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。
【０１４０】
通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、ユーザ装置１０の信号送信部１０１及び信号受信部１０２は、通信装置１００４で実現されてもよい。また、基地局２０の信号送信部２０１及び信号受信部２０２は、通信装置１００４で実現されてもよい。
【０１４１】
入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。
【０１４２】
また、プロセッサ１００１及びメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。
【０１４３】
また、ユーザ装置１０と基地局２０はそれぞれ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｒｏｃｅｓｓｏｒ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）、ＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ  Ｌｏｇｉｃ  Ｄｅｖｉｃｅ）、ＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。
【０１４４】
（実施の形態のまとめ）
以上、説明したように、本実施の形態によれば、無線通信システムにおけるユーザ装置であって、前記ユーザ装置とは異なる通信装置からデータ送信許可を受信することなくデータを送信することが可能な複数の区分リソースに関する設定情報を保持する設定情報管理部と、前記複数の区分リソースのそれぞれは、再送制御プロセスに対応付けられており、当該複数の区分リソースから、再送制御用バッファが空きである再送制御プロセスに対応する区分リソースを選択し、当該区分リソースを用いて、データを送信する送信部とを備えることを特徴とするユーザ装置が提供される。
【０１４５】
上記の構成により、データ送信許可を受信することなくデータを送信することができるリソースの設定が行われる無線通信システムにおいて、ユーザ装置が、再送制御を行う場合でも、当該リソースを用いたデータ送信を迅速に実行することを可能とする技術が提供される。
【０１４６】
前記設定情報は、前記複数の区分リソースを示す情報に加えて、区分リソースと再送制御プロセスの識別子との間のマッピング情報を含むこととしてもよい。この構成により、区分リソースと再送制御プロセスの識別子との間のマッピングを明確に識別することができる。
【０１４７】
前記複数の区分リソースにおけるそれぞれの区分リソースに、１種類又は複数種類の参照信号が対応付けられており、更に、各種類の参照信号に、再送制御プロセスが対応付けられており、前記送信部は、ある再送制御プロセスを使用してデータを送信する場合に、当該再送制御プロセスに対応する参照信号を用いて前記データを送信することとしてもよい。この構成により、使用できる再送制御プロセスを増加させることができる。
【０１４８】
前記送信部は、時間を計測するカウンタを備えており、ある再送制御プロセスにおける再送制御用バッファにデータが格納された状態のまま、前記カウンタにより、所定時間の経過が検出された場合に、当該再送制御用バッファをクリアすることとしてもよい。この構成により、許容遅延を超過したデータを再送し続けることによる新規データの送信機会の損失を回避することができる。
【０１４９】
前記送信部において使用される複数の再送制御プロセスに優先順位が設定されており、当該送信部は、当該優先順位に従って、再送制御用バッファが空きである再送制御プロセスを選択し、当該再送制御プロセスに対応する区分リソースを選択することとしてもよい。この構成により、基地局は、ユーザ装置がＵＬデータ送信のために選択する可能性のあるリソースを、利用可能ＨＡＲＱプロセスＩＤと優先順位に基づいて絞り込むことができる。
【０１５０】
（実施形態の補足）
以上、本発明の実施の形態を説明してきたが、開示される発明はそのような実施形態に限定されず、当業者は様々な変形例、修正例、代替例、置換例等を理解するであろう。発明の理解を促すため具体的な数値例を用いて説明がなされたが、特に断りのない限り、それらの数値は単なる一例に過ぎず適切な如何なる値が使用されてもよい。上記の説明における項目の区分けは本発明に本質的ではなく、２以上の項目に記載された事項が必要に応じて組み合わせて使用されてよいし、ある項目に記載された事項が、別の項目に記載された事項に（矛盾しない限り）適用されてよい。機能ブロック図における機能部又は処理部の境界は必ずしも物理的な部品の境界に対応するとは限らない。複数の機能部の動作が物理的には１つの部品で行われてもよいし、あるいは１つの機能部の動作が物理的には複数の部品により行われてもよい。実施の形態で述べた処理手順については、矛盾の無い限り処理の順序を入れ替えてもよい。処理説明の便宜上、ユーザ装置１０と基地局２０は機能的なブロック図を用いて説明されたが、そのような装置はハードウェアで、ソフトウェアで又はそれらの組み合わせで実現されてもよい。本発明の実施の形態に従ってユーザ装置１０が有するプロセッサにより動作するソフトウェア及び本発明の実施の形態に従って基地局２０が有するプロセッサにより動作するソフトウェアはそれぞれ、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、読み取り専用メモリ（ＲＯＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、レジスタ、ハードディスク（ＨＤＤ）、リムーバブルディスク、ＣＤ−ＲＯＭ、データベース、サーバその他の適切な如何なる記憶媒体に保存されてもよい。
【０１５１】
また、情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Ｄｏｗｎｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）、ＵＣＩ（Ｕｐｌｉｎｋ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ））、上位レイヤシグナリング（例えば、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）シグナリング、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）シグナリング、ブロードキャスト情報（ＭＩＢ（Ｍａｓｔｅｒ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）、ＳＩＢ（Ｓｙｓｔｅｍ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂｌｏｃｋ）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣシグナリングは、ＲＲＣメッセージと呼ばれてもよく、例えば、ＲＲＣ接続セットアップ（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｓｅｔｕｐ）メッセージ、ＲＲＣ接続再構成（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ）メッセージなどであってもよい。
【０１５２】
本明細書で説明した各態様／実施形態は、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）、ＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）、ＳＵＰＥＲ  ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Ｆｕｔｕｒｅ  Ｒａｄｉｏ  Ａｃｃｅｓｓ）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ｕｌｔｒａ  Ｍｏｂｉｌｅ  Ｂｒｏａｄｂａｎｄ）、ＩＥＥＥ  ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ  ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ  ８０２．２０、ＵＷＢ（Ｕｌｔｒａ−ＷｉｄｅＢａｎｄ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。
【０１５３】
本明細書で説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。
【０１５４】
本明細書において基地局２０によって行われるとした特定動作は、場合によってはその上位ノード（ｕｐｐｅｒ  ｎｏｄｅ）によって行われることもある。基地局２０を有する１つまたは複数のネットワークノード（ｎｅｔｗｏｒｋ  ｎｏｄｅｓ）からなるネットワークにおいて、ユーザ装置１０との通信のために行われる様々な動作は、基地局２０および／または基地局２０以外の他のネットワークノード（例えば、ＭＭＥまたはＳ−ＧＷなどが考えられるが、これらに限られない）によって行われ得ることは明らかである。上記において基地局２０以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ（例えば、ＭＭＥおよびＳ−ＧＷ）であってもよい。
【０１５５】
本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。
【０１５６】
ユーザ装置１０は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。
【０１５７】
基地局２０は、当業者によって、ＮＢ（ＮｏｄｅＢ）、ｅＮＢ（ｅｎｈａｎｃｅｄ  ＮｏｄｅＢ）、ベースステーション（Ｂａｓｅ  Ｓｔａｔｉｏｎ）、またはいくつかの他の適切な用語で呼ばれる場合もある。
【０１５８】
本明細書で使用する「判断（ｄｅｔｅｒｍｉｎｉｎｇ）」、「決定（ｄｅｔｅｒｍｉｎｉｎｇ）」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定（ｊｕｄｇｉｎｇ）、計算（ｃａｌｃｕｌａｔｉｎｇ）、算出（ｃｏｍｐｕｔｉｎｇ）、処理（ｐｒｏｃｅｓｓｉｎｇ）、導出（ｄｅｒｉｖｉｎｇ）、調査（ｉｎｖｅｓｔｉｇａｔｉｎｇ）、探索（ｌｏｏｋｉｎｇ  ｕｐ）（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認（ａｓｃｅｒｔａｉｎｉｎｇ）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信（ｒｅｃｅｉｖｉｎｇ）（例えば、情報を受信すること）、送信（ｔｒａｎｓｍｉｔｔｉｎｇ）（例えば、情報を送信すること）、入力（ｉｎｐｕｔ）、出力（ｏｕｔｐｕｔ）、アクセス（ａｃｃｅｓｓｉｎｇ）（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決（ｒｅｓｏｌｖｉｎｇ）、選択（ｓｅｌｅｃｔｉｎｇ）、選定（ｃｈｏｏｓｉｎｇ）、確立（ｅｓｔａｂｌｉｓｈｉｎｇ）、比較（ｃｏｍｐａｒｉｎｇ）などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。
【０１５９】
本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。
【０１６０】
「含む（ｉｎｃｌｕｄｅ）」、「含んでいる（ｉｎｃｌｕｄｉｎｇ）」、およびそれらの変形が、本明細書あるいは特許請求の範囲で使用されている限り、これら用語は、用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」と同様に、包括的であることが意図される。さらに、本明細書あるいは特許請求の範囲において使用されている用語「または（ｏｒ）」は、排他的論理和ではないことが意図される。
【０１６１】
本開示の全体において、例えば、英語でのａ，ａｎ，及びｔｈｅのように、翻訳により冠詞が追加された場合、これらの冠詞は、文脈から明らかにそうではないことが示されていなければ、複数のものを含み得る。
【０１６２】
以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。
【符号の説明】
【０１６３】
１０  ユーザ装置
１０１  信号送信部
１０２  信号受信部
１０３  設定情報管理部
１０４  再送制御部
２０  基地局
２０１  信号送信部
２０２  信号受信部
２０３  設定情報管理部
２０４  再送制御部
１００１  プロセッサ
１００２  メモリ
１００３  ストレージ
１００４  通信装置
１００５  入力装置
１００６  出力装置
【図１】
2020036051.tif 000003
【図２】
2020036051.tif 000004
【図３】
2020036051.tif 000005
【図４】
2020036051.tif 000006
【図５】
2020036051.tif 000007
【図６】
2020036051.tif 000008
【図７】
2020036051.tif 000009
【図８】
2020036051.tif 000010
【図９】
2020036051.tif 000011
【図１０】
2020036051.tif 000012
【図１１】
2020036051.tif 000013
【図１２】
2020036051.tif 000014
【図１３】
2020036051.tif 000015
【図１４】
2020036051.tif 000016
【図１５】
2020036051.tif 000017
【図１６】
2020036051.tif 000018
【図１７】
2020036051.tif 000019