JP2019169750A

JP2019169750A - ユーザ装置、及び再送制御方法

Info

Publication number: JP2019169750A
Application number: JP2016158263A
Authority: JP
Inventors: 真平安川; Shimpei Yasukawa; 聡永田; Satoshi Nagata; 一樹武田; Kazuki Takeda
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2016-08-10
Filing date: 2016-08-10
Publication date: 2019-10-03
Also published as: US20190181990A1; CN109565378A; WO2018030487A1; US10778380B2

Abstract

【課題】複数種類の通信の処理を行うユーザ装置において、再送制御に用いるソフトバッファ領域の不足を回避する。【解決手段】基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置において、前記基地局から受信する下りデータの再送制御に使用されるソフトバッファ領域を有する記憶部と、前記ソフトバッファ領域のうちの一部の領域を複数のサブバッファ領域に分割し、当該複数のサブバッファ領域のうちの１つ又は複数のサブバッファ領域を使用して、前記基地局から受信する下りデータの再送制御を行う再送制御部とを備える。【選択図】図２

Description

本発明は、無線通信システムにおけるユーザ装置に関連するものである。

現在、３ＧＰＰ（3rd Generation Partnership Project）において、第４世代の無線通信システムの一つであるＬＴＥ（Long Term Evolution）−Ａｄｖａｎｃｅｄの後継にあたる５Ｇと呼ばれる次世代のシステムの検討が進んでいる。５Ｇでは、主にｅＭＢＢ（extended Mobile Broadband）、ｍＭＴＣ(massive Machine Type Communication）、ＵＲＬＬＣ（Ultra Reliability and Low Latency Communication）の３つのユースケースが想定されている。

ＵＲＬＬＣは、低遅延及び高信頼性による無線通信を実現することを目的としている。ＵＲＬＬＣにおいて低遅延を実現するための具体策として、ＳｈｏｒｔＴＴＩ（Transmission Time Interval）長（サブフレーム長、サブフレーム間隔、送信時間間隔とも呼ばれる）の導入、パケット生成からデータ送信までの制御遅延の短縮化等が検討されている。更に、ＵＲＬＬＣにおいて高信頼性を実現するための具体策として、低ビット誤り率を実現するための低符号化率の符号化方式及び変調方式の導入、ダイバーシチの活用等が検討されている。

また、ＵＲＬＬＣにおいて、例えば１ｍｓのＵ−ｐｌａｎｅ遅延、及び、例えば１０＾−５のパケット誤り率を実現することが検討されている。低遅延を実現するために、ＴＴＩ長を通常のパケット（例えばｅＭＢＢトラフィックのパケット）よりも短くすることが検討されている。

５Ｇにおいては、ｅＭＢＢトラフィックとＵＲＬＬＣトラフィックがユーザ装置内で混在することが考えられる。その場合、ＵＲＬＬＣのほうがｅＭＢＢに比べてＴＴＩ長が短いため、ＵＲＬＬＣ用データはｅＭＢＢに比較して高頻度で送信され得る。

ここで、５Ｇにおいても、ＬＴＥと同様に、無線区間で生じたパケット誤りを短い制御遅延時間で効率的に保証するＨＡＲＱ（ＨｙｂｒｉｄＡＲＱ）（非特許文献１）と呼ばれる再送制御を行うことが想定される。

3GPP TS 36.321 V13.2.0 (2016-06)

ＨＡＲＱ制御に関して、例えば、ｅＭＢＢとＵＲＬＬＣとのＴＴＩ長の比が４：１であるとすると、ｅＭＢＢに１ＨＡＲＱプロセスを割り当てる間に、ＵＲＬＬＣには４ＨＡＲＱプロセスが割り当てられ得る。各ＨＡＲＱプロセスに対してソフトバッファが用いられるが、ユーザ装置において、ソフトバッファ領域には限りがある。よって、ｅＭＢＢデータとＵＲＬＬＣデータがユーザ装置内で混在する場合、ソフトバッファ領域が不足することで、ｅＭＢＢに対して利用できるＨＡＲＱプロセス数が限定されてしまう可能性があるという課題がある。

なお、上記の課題は、ｅＭＢＢとＵＲＬＬＣに限らない複数種類の通信がユーザ装置内に混在する場合に生じ得る課題である。

本発明は上記の点に鑑みてなされたものであり、複数種類の通信の処理を行うユーザ装置において、再送制御に用いるソフトバッファ領域の不足を回避することを可能とする技術を提供することを目的とする。

開示の技術によれば、基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置であって、
前記基地局から受信する下りデータの再送制御に使用されるソフトバッファ領域を有する記憶部と、
前記ソフトバッファ領域のうちの一部の領域を複数のサブバッファ領域に分割し、当該複数のサブバッファ領域のうちの１つ又は複数のサブバッファ領域を使用して、前記基地局から受信する下りデータの再送制御を行う再送制御部と
を備えることを特徴とするユーザ装置が提供される。

開示の技術によれば、複数種類の通信の処理を行うユーザ装置において、再送制御に用いるソフトバッファ領域の不足を回避することを可能とする技術が提供される。

本発明の実施の形態に係る無線通信システムの構成図である。ソフトバッファの例を示す図である。無線通信システムの基本的な動作例を説明するための図である。共用バッファを説明するための図である。バッファ共用動作を説明するための図である。マスタソフトバッファにおけるＨＡＲＱプロセス数を変更しない場合の例を説明するための図である。下り制御情報により利用ソフトバッファ領域を通知する場合のシーケンスを示す図である。ソフトバッファ領域の指定の例を示す図である。ソフトバッファ領域の指定の例を示す図である。付随する課題を説明するための図である。選択的バッファ破棄を行うシーケンスを示す図である。バッファの状態を説明するための図である。バッファの状態を説明するための図である。ユーザ装置１０の機能構成の一例を示す図である。基地局２０の機能構成の一例を示す図である。ユーザ装置１０及び基地局２０のハードウェア構成の一例を示す図である。

以下、図面を参照して本発明の実施の形態（本実施の形態）を説明する。なお、以下で説明する実施の形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施の形態に限られるわけではない。

本実施の形態の無線通信システムは、少なくともＬＴＥの通信方式をサポートしていることを想定している。よって、無線通信システムが動作するにあたっては、適宜、ＬＴＥで規定された既存技術を使用できる。ただし、当該既存技術はＬＴＥに限られない。また、本明細書で使用する「ＬＴＥ」は、特に断らない限り、ＬＴＥ−Ａｄｖａｎｃｅｄ、及び、ＬＴＥ−Ａｄｖａｎｃｅｄ以降の方式（例：５Ｇ）を含む広い意味を有するものとする。また、本発明は、ＬＴＥ以外の通信方式にも適用可能である。

また、以下で説明する実施の形態では、ＴＴＩ長の異なる複数種類の通信としてｅＭＢＢの通信とＵＲＬＬＣの通信を取り上げているが、これらは例に過ぎず、本発明は、ｅＭＢＢの通信とＵＲＬＬＣの通信以外の通信にも適用可能である。また、混在する通信の種類の数は２つに限られない。混在する通信の種類の数が３つ以上であってもよい。

（システム全体構成）
図１に本実施の形態に係る無線通信システムの構成図を示す。本実施の形態に係る無線通信システムは、図１に示すように、ユーザ装置１０、及び基地局２０を含む。図１には、ユーザ装置１０、及び基地局２０が１つずつ示されているが、これは例であり、それぞれ複数であってもよい。

本実施の形態においては、下り方向のデータをユーザ装置１０が受信する際のＨＡＲＱ制御を対象としている。

本実施の形態で説明するＨＡＲＱ制御は、基本的にＬＴＥにおけるＨＡＲＱ制御と同様であることから、まず、ＬＴＥにおけるＨＡＲＱ制御の概要を説明しておく。

ＬＴＥにおけるユーザ装置及び基地局では、ＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）レイヤのＨＡＲＱエンティティにおいてＨＡＲＱ（ＨｙｂｒｉｄＡＲＱ）制御が行われる（非特許文献１）。ユーザ装置での下りデータに対するＨＡＲＱ制御では、下りデータ（ＴＢ：トランスポートブロック）のデコード（復号）に成功した場合にＡＣＫを基地局に返し、デコードに失敗した場合はＮＡＣＫを基地局に返す。このように、ＨＡＲＱでは、ＡＣＫ／ＮＡＣＫを送信することで再送制御を行う。ＨＡＲＱにおいて、ユーザ装置は、受信したデータのデコード（復号）に失敗した場合（データが誤っていた場合）に、当該データを保持しておき、基地局から再送されてきたデータと当該保持したデータとを合成（ソフトコンバイニング）し、合成したデータをデコードする。これにより、誤りに強い耐性を持たせることとしている。上記のデータを保持する記憶部（メモリ領域）をソフトバッファと呼ぶ。

また、１つのトランスポートブロックに対するＨＡＲＱ制御をＨＡＲＱプロセスと呼ぶ。ＨＡＲＱ制御は、複数のトランスポートブロックに対する並列動作が可能である。例えば、８つのトランスポートブロックに対するＨＡＲＱ並列動作を行う場合、ＨＡＲＱプロセス＃１〜ＨＡＲＱプロセス＃８の８つのＨＡＲＱプロセスが動作することになる。ユーザ装置は、各ＨＡＲＱプロセス用にソフトバッファを有する。

（基本的な動作例）
本実施の形態では、ＴＴＩ長の長いｅＭＢＢ用の全ＨＡＲＱプロセスのソフトバッファをマスタソフトバッファと呼び、マスタソフトバッファにおける一部のＨＡＲＱプロセスのソフトバッファをＵＲＬＬＣ用のソフトバッファとして使用することとしている。ＵＲＬＬＣ用に使用するソフトバッファをスレーブソフトバッファと呼ぶ。スレーブソフトバッファは、例えば、ＵＲＬＬＣ用のＨＡＲＱプロセス数だけ分割して使用される。なお、"マスタ"と"スレーブ"は、説明の便宜上用いているものであり、ｅＭＢＢとＵＲＬＬＣが親子関係にあることを示しているわけではない。

図２に、ユーザ装置１０が備えるソフトバッファの例を示す。図２（ａ）は、マスタソフトバッファを示す。本実施の形態では、ユーザ装置１０は、ｅＭＢＢ用に４つのＨＡＲＱプロセスを使用できるので、図２（ａ）に示すように、ＨＡＲＱプロセス＃１〜＃４用にそれぞれのソフトバッファが備えられる。

図２（ｂ）は、マスタソフトバッファのうちのＨＡＲＱプロセス＃４のソフトバッファをスレーブソフトバッファとして使用する場合のソフトバファの状態を示す。ここでは、ＵＲＬＬＣ用に４つのＨＡＲＱプロセスを使用するので、スレーブソフトバッファは４つに分割される。

マスタソフトバッファのうちの一部のソフトバッファをスレーブソフトバッファとして使用することの設定は、例えば、基地局２０からユーザ装置１０に対する上位レイヤシグナリングにより行われる。図３は、このような上位レイヤシグナリングを含む基本的なシステムの動作例を示す。

図３のステップＳ１０１において、基地局２０からユーザ装置１０に対して、上位レイヤシグナリングにより、マスタソフトバッファのうちの特定のＨＡＲＱプロセスのソフトバッファ内を分割して、当該ソフトバッファをスレーブソフトバッファとして使用することを指示する設定情報が通知される。

この設定情報には、例えば、スレーブソフトバッファとして使用するマスタソフトバッファにおけるソフトバッファの番号（＝ＨＡＲＱプロセス番号）と、スレーブソフトバッファの分割数（＝ＵＲＬＬＣのＨＡＲＱプロセス数）が通知される。なお、スレーブソフトバッファとして使用するマスタソフトバッファにおけるソフトバッファの番号が予め定められている場合には、当該番号の指定を含まなくてもよい。また、スレーブソフトバッファの分割数（＝ＵＲＬＬＣのＨＡＲＱプロセス数）に代えて、又は、これに加えて、スレーブソフトバッファにおけるＵＲＬＬＣの１ＨＡＲＱプロセス当たりのバッファサイズ（＝１トランスポートブロックサイズ）が指定されてもよい。また、スレーブソフトバッファとして使用するマスタソフトバッファにおけるソフトバッファの番号（＝ＨＡＲＱプロセス番号）に代えて、スレーブソフトバッファとして使用するマスタソフトバッファにおけるバッファサイズ及び／又は領域を指定する情報（例：メモリのアドレス範囲）が指定されてもよい。

ユーザ装置１０は、上記の設定情報に基づき、スレーブソフトバッファのパーティショニング設定を行う。パーティショニング設定とは、例えば、スレーブソフトバッファに使用するメモリ領域を確保するとともに、分割数を記憶部（所定のメモリ領域）に保持することである。これにより、ＵＲＬＬＣの下りデータが実際に発生したときに、当該分割数に基づくスレーブソフトバッファの分割を行って、分割された各ソフトバッファを各ＨＡＲＱプロセスに使用することができる。なお、分割された各ソフトバッファをサブバッファと呼んでもよい。なお、パーティショニング設定の時点で、スレーブソフトバッファの分割処理を行ってもよい。分割処理には、例えば、スレーブソフトバッファのメモリ領域を分割数に分けるとともに、分割された領域毎に、ＨＡＲＱプロセス番号を割り当てることを含む。

図３のステップＳ１０２では、基地局２０からユーザ装置１０に対して、ＵＲＬＬＣの下りデータのリソース割り当てを含む下り制御情報が送信される。

ユーザ装置１０は、当該下り制御情報に基づき、ＵＲＬＬＣの下りデータの発生を把握すると、スレーブソフトバッファの分割を行って、分割された各ソフトバッファにＨＡＲＱプロセス番号（インデックス）を割り当てて、各ソフトバッファの使用を開始する（ステップＳ１０３）。その後、当該分割された各ソフトバッファを使用した、ＵＲＬＬＣの下りデータに対するＨＡＲＱ制御が実行される。ＨＡＲＱ制御（再送制御）においては、上述したように、ユーザ装置１０は、例えば、下りデータに誤りを検出したら当該下りデータを該当ソフトバッファに保持するとともにＮＡＣＫを基地局２０に返し、基地局２０から受信する再送データと、ソフトバッファに保持した下りデータとを合成し、合成したデータをデコードする、といった処理を行う。

ここでは、ユーザ装置１０は、スレーブソフトバッファの設定がなされた後、スレーブソフトバッファをＵＲＬＬＣ用に排他的に使用する。ユーザ装置１０がＵＲＬＬＣの通信を行う間に、並行して、ｅＭＢＢの通信も行われ得るが、その場合、ｅＭＢＢの通信に対しては、マスタソフトバッファからスレーブソフトバッファを除いた領域が使用される（図２（ｂ）の例では、ＨＡＲＱプロセス＃１〜＃３の領域）。

なお、上記の例では、マスタソフトバッファの１ＨＡＲＱプロセス分のバッファを分割してスレーブソフトバッファとして利用する形態を示しているが、これは一例であり、マスタソフトバッファの複数ＨＡＲＱプロセス分のバッファを分割してスレーブソフトバッファとして利用してもよい。

また、ユーザ装置１０においてスレーブソフトバッファの設定がされていない場合には、下りデータの種別によらずに、共通のソフトバッファが共用される。例えば、図２（ａ）に示したソフトバッファが、ｅＭＢＢとＵＲＬＬＣに共通に使用される。従って、例えば、ＵＲＬＬＣのデータにより、図２（ａ）に示したＨＡＲＱプロセス＃１〜＃４の各ソフトバッファが断片的に使用されてしまい、ｅＭＢＢ用のソフトバッファが不足することが発生し得る。

よって、ｅＭＢＢとＵＲＬＬＣの両方が発生し得るセルの基地局２０は、上位レイヤシグナリングあるいはブロードキャスト信号により、ｅＭＢＢとＵＲＬＬＣの両方を扱う能力のあるユーザ装置１０に対してスレーブソフトバッファの設定を行うことが望ましい。

また、ユーザ装置１０が基地局２０に、ＵＲＬＬＣで利用するソフトバッファサイズ及び／又はＵＲＬＬＣで利用する最大ＨＡＲＱプロセス数の能力を報告することで、基地局２０が適切な分割数を設定できるようにしてもよい。

上述した構成により、ｅＭＢＢ／ＵＲＬＬＣ混在時のソフトバッファの断片化及びソフトバッファ不足を回避可能となる。

（バッファ共用について）
上述した例では、スレーブソフトバッファが設定された場合には、ユーザ装置１０は、それをＵＲＬＬＣ用に排他的に使用するため、ｅＭＢＢ用のバッファサイズが減少する。これを回避するために、スレーブソフトバッファをｅＭＢＢ（マスタ側）と共用することとしてもよい。共用される領域を共用バッファと呼ぶ。以下では、当該共用に関する動作例を説明する。

図４に、共用バッファのイメージを示す。図４の例では、マスタソフトバッファにおけるＨＡＲＱプロセス＃４のソフトバッファの領域が、共用バッファとして使用される。

例えば、図３に示すＳ１０１における設定情報において、分割数等を指定するとともに、共用／排他を指示することができる。また、共用／排他の指示がなく、常に共用としてもよい。また、共用／排他の指示がなく、常に排他としてもよい。

ユーザ装置１０に共用バッファ（例：図４）が設定されている場合におけるユーザ装置１０の動作例を図５を参照して説明する。

図５の例において、Ａの時点でｅＭＢＢの下りデータ送信が開始されると、それ以降（Ｂの時点まで）、ユーザ装置１０は、マスタソフトバッファにおけるＨＡＲＱプロセス＃１〜＃４のソフトバッファを利用してｅＭＢＢの下りデータについてのＨＡＲＱ制御を行う。

Ｂの時点で、ユーザ装置１０は、ＵＲＬＬＣの下りデータが発生したことを下り制御情報により把握する。すると、ユーザ装置１０は、マスタソフトバッファにおけるＨＡＲＱプロセス＃４のソフトバッファ（スレーブソフトバッファ）をクリアして、当該バッファを分割してＵＲＬＬＣのＨＡＲＱプロセス＃１〜＃４に使用する。その間、ｅＭＢＢの下りデータが継続していてもよい。その場合、マスタソフトバッファにおけるＨＡＲＱプロセス＃１〜＃３のソフトバッファがｅＭＢＢ用に使用されることになる。ただし、この間に、マスタソフトバッファにおけるＨＡＲＱプロセス＃４の使用も要するｅＭＢＢ下りデータが発生する場合には、例えば、共用バッファ（スレーブソフトバッファ）はクリアされ、共用バッファはｅＭＢＢのＨＡＲＱプロセス＃４のバッファとして使用される。これは、ｅＭＢＢのバッファの優先度が高い場合の動作である。ＵＲＬＬＣのバッファの優先度を高くして、ＵＲＬＬＣの下りデータが終了するまでは、共用バッファ（スレーブソフトバッファ）をｅＭＢＢ用に使用できないこととしてもよい。

また、所定時間、ＵＲＬＬＣ用のバッファの優先度を高くするために、共用バッファのＵＲＬＬＣ用の利用に有効時間（有効時間カウンタ）を設けてもよい。この場合、例えば、ユーザ装置１０は、図５のＢの時点で、共用バッファをＵＲＬＬＣ用のバッファとして使用開始するとともに、有効時間カウンタを起動して、所定時間の計時を開始する。所定時間が経過するまで（有効時間カウンタがタイムアウトするまで）は、共用バッファをｅＭＢＢのバッファとして使用することができない。そして、有効時間カウンタがタイムアウトした後、もしも、マスタソフトバッファにおけるＨＡＲＱプロセス＃４の使用を要するｅＭＢＢ下りデータが発生した場合には、ＵＲＬＬＣ用のバッファはクリアされ、ｅＭＢＢ用に使用される。ただし、マスタソフトバッファにおけるＨＡＲＱプロセス＃４の使用を要するｅＭＢＢ下りデータが発生しない場合には、ＵＲＬＬＣ用のバッファの使用を継続できる。

図５において、Ｃの時点までＵＲＬＬＣ用のバッファを使用できたものとして、Ｃの時点でＵＲＬＬＣの下りデータが終了したとすると、Ｃの時点から、マスタソフトバッファを利用したｅＭＢＢの下りデータ通信が行われる。

上記のように、共用バッファを備えることで、ｅＭＢＢ側のスループット低下を最小限にしてＵＲＬＬＣ側のデータ通信を行うことができる。なお、共用バッファの設定は、ｅＭＢＢ側のスループットを、ＵＲＬＬＣ側よりも優先させたい場合にのみ設定することとしてもよい。

（トランスポートブロックサイズについて）
スレーブソフトバッファのパーティショニングの設定において、基地局２０が、ＵＲＬＬＣ下りデータのＴＴＩあたりの最大トランスポートブロックサイズを上位レイヤシグナリングでユーザ装置１０に通知することとしてもよい。

例えば、図３のステップＳ１０１における設定情報に当該最大トランスポートブロックサイズを含めて通知する。最大トランスポートブロックサイズを受信したユーザ装置１０は、スレーブソフトバッファにおけるパーティショニングの設定（分割数等）を当該最大トランスポートブロックサイズに基づき決定することができる。

また、ユーザ装置１０は、スレーブソフトバッファのサイズに応じて、ＵＲＬＬＣのトランスポートブロックサイズを自律的に算出してもよい。

例えば、スレーブソフトバッファが占有するマスタソフトバッファにおけるバッファ数（例：ｅＭＢＢのＨＡＲＱプロセス＃３、＃４のバッファを使用する場合は２）、ユーザ装置１０がサポートするｅＭＢＢのＴＴＩあたりのトランスポートブロックサイズをＳ、ＵＲＬＬＣのＨＡＲＱプロセス数をＮとすると、「Ｓ×Ｍ／Ｎ」を計算することで、スレーブソフトバッファに対応する下りデータ送信（つまり、ＵＲＬＬＣ下りデータ送信）におけるＴＴＩあたりのトランスポートブロックサイズが得られる。

前述したように、これまでの例においては、スレーブソフトバッファが使用される場合には、マスタソフトバッファを使用するＨＡＲＱプロセス数が減少する。そこで、例えば、基地局２０からユーザ装置１０に対して、マスタソフトバッファを使用するＨＡＲＱプロセスあたりの最大トランスポートブロックサイズ（元のサイズよりも小さいサイズ）を上位レイヤシグナリングで通知（変更）することで、マスタソフトバッファを使用するＨＡＲＱプロセス数に変更が生じないようにする。この通知は、例えば、図３のステップＳ１０１におけるスレーブソフトバッファの設定時の制御情報に含めて行ってもよい。

一例として、ユーザ装置１０が利用可能なバッファサイズ（例：図６の（ａ）に示すマスタソフトバッファのサイズ）をＢとし、マスタソフトバッファを使用するＨＡＲＱプロセス数をＰとし、スレーブソフトバッファに使用するバッファサイズをＫとすると、上記の変更に係る最大トランスポートブロックサイズ（＝変更後のマスタソフトバッファの１バッファサイズ）は、（Ｂ−Ｋ）／Ｐとして算出できる。例えば、基地局２０はこのようにして算出した最大トランスポートブロックサイズをユーザ装置１０に通知する。あるいは、このような通知を行わずに、ユーザ装置１０が上記の計算を行って、マスタソフトバッファの１バッファサイズ（＝マスタのトランスポートブロックサイズ）を算出してもよい。

図６（ｂ）は、上記のようにして算出したバッファサイズを有するマスタソフトバッファと、スレーブソフトバッファを有するバッファを示している。図６（ｂ）に示すように、スレーブソフトバッファが設定される場合でも、マスタソフトバッファを使用するＨＡＲＱプロセス数には変更がない。

上記の動作により、ＨＡＲＱプロセス数不足による、マスタソフトバッファを利用するデータチャネルの遅延増加を回避することができる。

（利用ソフトバッファの切り替えについて）
図３を参照して説明したとおり、ユーザ装置１０は、ＵＲＬＬＣの下りデータのリソース割り当てを示す下り制御情報（図３のステップＳ１０２）を受信すると、スレーブソフトバッファの使用を開始する。このように、本実施の形態では、ユーザ装置１０は、下り制御情報に基づいて、マスタソフトバッファとスレーブソフトバッファのうちのどちらを使用するかを判断することができる。この処理のシーケンス例は図７に示すとおりである。すなわち、ユーザ装置１０は、基地局２０から、ソフトバッファ領域を指定した下り制御情報を受信する（Ｓ２０１）ことで、指定されたソフトバッファ領域を判断できる（ステップＳ２０２）。

上記の判断は、例えば、下り制御情報に明示的に「マスタソフトバッファを使用」又は「スレーブソフトバッファを使用」を示す識別情報を付与することで実現できる。

また、明示的に識別情報を付与することに代えて（又はそれに加えて）、下り制御情報フォーマット、下り制御情報に付与される識別子、及び、下り制御情報が送信されるリソースの時間・周波数インデックス、のうちのいずれか１つ又はいずれか複数と、「マスタソフトバッファを使用」／「スレーブソフトバッファを使用」とを予め対応付けておくこととしてもよい。この場合、基地局２０とユーザ装置１０の双方で対応関係を予め認識している。あるいは、基地局２０が対応関係をユーザ装置１０にブロードキャスト信号（システム情報）等で通知してもよい。

そして、基地局２０は、スケジューリングの内容（ＵＲＬＬＣ又はｅＭＢＢ）に基づいて、「マスタソフトバッファを使用」又は「スレーブソフトバッファを使用」に対応する下り制御情報フォーマット等を使用して下り制御情報をユーザ装置１０に送信する。ユーザ装置１０は、上記の対応関係に基づいて決定されるバッファ領域を使用して下りデータ受信を実行する。

上記の方式により、明示的に識別情報を付与する場合に比べてシグナリングオーバーヘッドを削減できる。

上記の例では、基地局２０はユーザ装置１０に対して、下り制御情報により、利用するソフトバッファ領域（マスタかスレーブか）を指定しているが、下り制御情報により、スケジューリング毎に、ＨＡＲＱプロセス毎のソフトバッファを通知してもよい。これにより、より柔軟なソフトバッファ共用を実現できる。

このとき、スレーブソフトバッファを使用する下りデータについては、マスタ側のあるＨＡＲＱプロセス番号（インデックス）に対応するソフトバッファ（スレーブソフトバッファ）を分割して利用することになる。当該分割されたバッファを「サブバッファ」と呼ぶことにすると、ユーザ装置１０がスレーブソフトバッファを利用する場合において、サブバッファのインデックスを基地局２０からユーザ装置１０に対して明示的に通知してもよいし、ユーザ装置１０が、下り制御情報から得られる下りデータの時間・周波数リソースによって暗黙的にサブバッファのインデックスを認識してもよい。

具体例を図８、図９を参照して説明する。図８、図９は、マスタソフトバッファが４つのＨＡＲＱプロセス分のソフトバッファを持ち、そのうちのＨＡＲＱプロセス＃４に対応するソフトバッファが、共用バッファとしてのスレーブソフトバッファとして使用される例を示している。また、図８、図９は、ユーザ装置１０が、スレーブソフトバッファにおけるＨＡＲＱプロセス＃２に対応するソフトバッファ（例：サブバッファ＃１）を利用する場合の例を示している。

明示的に通知を行う場合の例を図８に示す。図８に示すとおり、基地局２０はユーザ装置１０に対して、「ＨＡＲＱプロセス＃４、サブバッファ＃１」を含む下り制御情報を送信する。ユーザ装置１０は、当該下り制御情報に従って、マスタソフトバッファにおけるＨＡＲＱプロセス＃４のソフトバッファの中の分割されたサブバッファのうちのサブバッファ＃１を使用する。

ユーザ装置１０が、下りデータの時間・周波数リソースに基づいて、使用するサブバッファを決定する場合の例を図９に示す。図９の例では、マスタ側の１ＴＴＩ（図９の時間軸での４目盛分）がスレーブ側の４ＴＴＩに相当するものとする。この場合、ユーザ装置１０は、Ａに示す時間・周波数リソースの割り当てを受けた場合、リソースの時間幅が４であることと、フレーム（図９のＣで示す四角）の中の最初に位置するリソースであることとから、マスタソフトバッファにおけるＨＡＲＱプロセス＃１のソフトバッファを使用すると判断する。

また、ユーザ装置１０が、Ｂに示す時間・周波数リソースの割り当てを受けた場合、リソースの時間幅が１であることからスレーブソフトバッファ（マスタソフトバッファにおけるＨＡＲＱプロセス＃４のソフトバッファ）を使用すると判断するとともに、当該リソースは、時間方向で「２」番のリソースであることから、スレーブソフトバッファにおけるＨＡＲＱプロセス＃２のソフトバッファ（＝サブバッファ＃１）を使用すると判断する。

なお、これまでに説明した例では、ユーザ装置１０は、ソフトバッファ領域をマスタ／スレーブの２つの領域に分割しているが、これは一例に過ぎない。ユーザ装置１０は、ソフトバッファ領域を３つ以上の領域（例：マスタ、スレーブ１、スレーブ２の３つ）に分割してもよい。また、一例として、分割したバッファ（例：スレーブ２）を、サイドリンク（Ｄ２Ｄと呼んでもよい）の受信に割り当ててもよい。この場合、ユーザ装置１０は、モニタするチャネル（例えば下りデータチャネルかサイドリンクデータチャネルか）に応じて自律的にバッファを切り替えてもよい。

（選択的バッファ破棄について）
本実施の形態のように、異なるＴＴＩ長の下りデータのスケジューリングが許可されている場合において、特にＵＲＬＬＣのように短いＴＴＩを使用した低遅延送信を行う場合には、長いＴＴＩで送信されるトランスポートブロックに対するリソース割り当て後に、短いＴＴＩで送信されるトランスポートブロックに対して、長いＴＴＩの一部のリソースを割り当てることが考えられる。この場合、例えば、長いＴＴＩのリソースの一部はパンクチャされる。この場合の状況を図１０に示す。

上記のようなパンクチャを行う場合、長いＴＴＩのトランスポートブロックの一部がシンボル単位でパンクチャされることもあり、ユーザ装置１０は、一つ又は複数のコードブロックが受信できない可能性がある。なお、トランスポートブロックの送信側（本例では基地局２０）では、トランスポートブロック長が所定値以上の場合に、トランスポートブロックを複数のコードブロックに分割して送信を行う。分割されない場合はトランスポートブロックは１つのコードブロックとして送信される。

上記のように、割り当てられたリソースの一部がパンクチャされた場合、ソフトバッファにはパンクチャされたリソースに対応する軟判定情報が格納される。しかしながら、パンクチャされたリソースに対応する軟判定情報には有意な情報が含まれないことから、当該軟判定情報を用いて再送されたパケットの合成を行う場合、合成利得が得られず再送回数が増加する可能がある。

そこで、本実施の形態では、基地局２０からユーザ装置１０に通知される再送シグナリングにおいて、前回送信時の軟判定情報の部分的破棄を指示する。図１１に処理シーケンス例を示す。

ステップＳ３０１において、パンクチャされたリソースを含むデータ（例：コードブロック）が基地局２０からユーザ装置１０に送信される。基地局２０は、どのリソース（データのどの部分）がパンクチャされたかを把握している。

当該データを受信したユーザ装置１０は、ＮＡＣＫを基地局１０に返す（ステップＳ３０２）。基地局２０は、再送データのリソース割り当てを含む下り制御情報を下り制御チャネルでユーザ装置１０に送信する（ステップＳ３０３）。

当該下り制御情報には、例えば、破棄対象を指示する情報として、シンボルインデックス、時間・周波数リソースインデックス、又は、コードブロックインデックスが含まれる。破棄対象を指示する情報として、これら以外の情報が含まれていてもよい。

上記の下り制御情報を受信したユーザ装置１０は、破棄対象の情報をソフトバッファから削除する。ステップＳ３０４にて、基地局２０からユーザ装置１０に再送データが送信され、ユーザ装置１０は当該再送データの復号を行う。

上記のステップＳ３０３における下り制御情報に加えて、基地局２０はユーザ装置１０に、破棄対象となるデータのＲＶ（前回スケジュール時のＲＶ）を通知してもよい。これにより、スケジューリング情報（下り制御情報）の検出ミスが生じた際に、誤ったバッファ領域の情報を破棄することを回避することができる。なお、ＲＶはredundancy versionの略であり、送信側におけるサーキュラバッファから送信用のコードビットを取り出す際のサーキュラバッファの先頭位置を示す。

コードブロック単位で破棄を行う場合、基地局２０は、破棄対象のコードブロックとそれ以外のコードブロックとで異なるＲＶを適用してもよい。動作例を図１２、図１３を参照して説明する。図１２は、図１３との比較のために、パンクチャのないコードブロックの再送を示す図である。図１２は、基地局２０からＲＶ＃Ｘのコードブロックが送信され、その再送として、ＲＶ＃Ｙのコードブロックが送信されることを示している。

図１３の例では、初回送信（ユーザ装置１０の初回受信）に係るＲＶ＃Ｘのコードブロックにはパンクチャがなされており、低品質である（もしくは有意な情報がない）。ユーザ装置１０は初回受信により、ＲＶ＃Ｘのコードブロックの軟判定情報をソフトバッファに保持している。

図１３に示す再送のＡＬＴ．１では、既に説明した破棄の指示により、ユーザ装置１０は、ソフトバッファからＲＶ＃Ｘのコードブロックの領域を削除し、再送されたコードブロックをＲＶ＃Ｙに対応するソフトバッファの領域に保持する。この場合、図１１で示したステップＳ３０３の下り制御情報には、削除対象のＲＶ（ＲＶ＃Ｘ）と、再送データのＲＶ（ＲＶ＃Ｙ）とが含まれるので、ユーザ装置１０はＲＶ＃ＸとＲＶ＃Ｙを識別できる。これにより、初回送信時の誤り率がＲＶによって異なるような符号化の場合に最適なＲＶでの再送が可能になる。

図１３に示す再送のＡＬＴ．２では、破棄の指示により、ユーザ装置１０は、ソフトバッファからＲＶ＃Ｘのコードブロックの領域を削除するとともに、再送されたコードブロックについては、前のスケジューリングで通知されたＲＶ（ここではＲＶ＃Ｘ）を適用し、ＲＶ＃Ｘに対応するソフトバッファの領域に再送されたコードブロックを保持する。

なお、上記の例では、サーキュラバッファに関する領域についての削除及び格納を行うこととしているが、これは一例に過ぎない。サーキュラバッファに関係なく、ソフトバッファにおける特定のデータの領域(例:削除指示されたコードブロックの領域)の情報を削除して、別の領域に再送データを格納することとしてもよい（上記のＡＬＴ．１に相当）。また、ソフトバッファにおける特定のデータの領域(例:削除指示されたコードブロックの領域)の情報を削除して、その領域に再送データを格納することとしてもよい（上記のＡＬＴ．２に相当）。

（装置構成）
以上説明した実施の形態の動作を実行するユーザ装置１０及び基地局２０の機能構成例を説明する。

＜ユーザ装置＞
図１４は、実施の形態に係るユーザ装置１０の機能構成の一例を示す図である。図１１に示すように、ユーザ装置１０は、信号送信部１０１と、信号受信部１０２と、設定情報管理部１０３と、再送制御部１０４とを有する。図１４に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。

信号送信部１０１は、送信信号を作成し、当該信号を無線で送信する。また、信号送信部１０１は、再送制御部１０４からの指示に基づきＨＡＲＱフィードバックの送信等も行う。信号受信部１０２は、各種の信号を無線受信し、受信した物理レイヤの信号からより上位のレイヤの信号を取得する機能を含む。また、信号受信部１０２はソフトバッファ領域を格納する記憶部を含む。また、信号受信部１０２は、下り制御情報の受信、上位レイヤシグナリングの受信、ブロードキャスト信号の受信、ＤＬデータの受信等を行う。

設定情報管理部１０３は、信号受信部１０２により基地局２０から受信した各種の設定情報及び制御情報を格納する。例えば、当該設定情報にはパーティショニング設定の情報が含まれ、再送制御部１０４は当該情報を参照することでスレーブソフトバッファの分割を行うことができる。

再送制御部１０４は、ソフトバッファ領域のうちの一部の領域を複数のサブバッファ領域に分割し、当該複数のサブバッファ領域のうちの１つ又は複数のサブバッファ領域を使用して、基地局から受信する下りデータの再送制御を行う。再送制御においては、再送制御部１０４は、例えば、下りデータに誤りを検出したら、当該下りデータをソフトバッファ（例：サブバッファ）に保持し、ＮＡＣＫを信号送信部１０１を介して基地局に返し、基地局から受信した再送データと、ソフトバッファに保持したデータとの合成を行う。

＜基地局２０＞
図１５は、本実施の形態に係る基地局２０の機能構成の一例を示す図である。図１５に示すように、基地局２０は、信号送信部２０１と、信号受信部２０２と、リソース割り当て部２０３と、再送制御部２０４とを有する。図１５に示す機能構成は一例に過ぎない。本実施の形態に係る動作を実行できるのであれば、機能区分及び機能部の名称はどのようなものでもよい。

信号送信部２０１は、ユーザ装置１０側に送信する信号を生成し、当該信号を無線で送信する機能を含む。信号受信部２０２は、ユーザ装置１０から送信された各種の信号を受信し、受信した信号から、例えばより上位のレイヤの情報を取得する機能を含む。また、信号受信部２０２は、ユーザ装置１０から送信されるＨＡＲＱフィードバックを受信し、再送制御部２０４からの指示に基づき、必要に応じてデータの再送を行う。

リソース割り当て部２０３は、下りデータに対するリソース割り当て等を行って、下り制御チャネルで送信する下り制御情報の作成等を行う。作成された情報は信号送信部２０１から送信される。再送制御部２０４は、基地局２０側の再送制御の処理を行う。

＜ハードウェア構成＞
上記実施の形態の説明に用いたブロック図（図１４及び図１５）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及び／又はソフトウェアの任意の組み合わせによって実現される。また、各機能ブロックの実現手段は特に限定されない。すなわち、各機能ブロックは、物理的及び／又は論理的に複数要素が結合した１つの装置により実現されてもよいし、物理的及び／又は論理的に分離した２つ以上の装置を直接的及び／又は間接的に（例えば、有線及び／又は無線）で接続し、これら複数の装置により実現されてもよい。

例えば、本発明の一実施の形態におけるユーザ装置１０と基地局２０はいずれも、本実施の形態に係る処理を行うコンピュータとして機能してもよい。図１６は、本実施の形態に係るユーザ装置１０及び基地局２０のハードウェア構成の一例を示す図である。上述のユーザ装置１０及び基地局２０はそれぞれ、物理的には、プロセッサ１００１、メモリ１００２、ストレージ１００３、通信装置１００４、入力装置１００５、出力装置１００６、バス１００７などを含むコンピュータ装置として構成されてもよい。

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。ユーザ装置１０及び基地局２０のハードウェア構成は、図に示した１００１〜１００６で示される各装置を１つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

ユーザ装置１０及び基地局２０における各機能は、プロセッサ１００１、メモリ１００２などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることで、プロセッサ１００１が演算を行い、通信装置１００４による通信、メモリ１００２及びストレージ１００３におけるデータの読み出し及び／又は書き込みを制御することで実現される。

プロセッサ１００１は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ１００１は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（ＣＰＵ：Central Processing Unit）で構成されてもよい。

また、プロセッサ１００１は、プログラム（プログラムコード）、ソフトウェアモジュール又はデータを、ストレージ１００３及び／又は通信装置１００４からメモリ１００２に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態で説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、ユーザ装置１０の信号送信部１０１、信号受信部１０２、設定情報管理部１０３、再送制御部１０４は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。また、基地局２０の信号送信部２０１、信号受信部２０２、リソース割り当て部２０３、再送制御部２０４は、メモリ１００２に格納され、プロセッサ１００１で動作する制御プログラムによって実現されてもよい。上述の各種処理は、１つのプロセッサ１００１で実行される旨を説明してきたが、２以上のプロセッサ１００１により同時又は逐次に実行されてもよい。プロセッサ１００１は、１以上のチップで実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。

メモリ１００２は、コンピュータ読み取り可能な記録媒体であり、例えば、ＲＯＭ（Read Only Memory）、ＥＰＲＯＭ（Erasable Programmable ＲＯＭ）、ＥＥＰＲＯＭ（Electrically Erasable Programmable ＲＯＭ）、ＲＡＭ（Random Access Memory）などの少なくとも１つで構成されてもよい。メモリ１００２は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ１００２は、本発明の一実施の形態に係る処理を実施するために実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

ストレージ１００３は、コンピュータ読み取り可能な記録媒体であり、例えば、ＣＤ−ＲＯＭ（Compact Disc ＲＯＭ）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Ｂｌｕ−ｒａｙ（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つで構成されてもよい。ストレージ１００３は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ１００２及び／又はストレージ１００３を含むデータベース、サーバその他の適切な媒体であってもよい。

通信装置１００４は、有線及び／又は無線ネットワークを介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。例えば、ユーザ装置１０の信号送信部１０１及び信号受信部１０２は、通信装置１００４で実現されてもよい。また、基地局２０の信号送信部２０１及び信号受信部２０２は、通信装置１００４で実現されてもよい。

入力装置１００５は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置１００６は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置１００５及び出力装置１００６は、一体となった構成（例えば、タッチパネル）であってもよい。

また、プロセッサ１００１及びメモリ１００２などの各装置は、情報を通信するためのバス１００７で接続される。バス１００７は、単一のバスで構成されてもよいし、装置間で異なるバスで構成されてもよい。

また、ユーザ装置１０及び基地局２０はそれぞれ、マイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＰＬＤ（Programmable Logic Device）、ＦＰＧＡ（Field Programmable Gate Array）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ１００１は、これらのハードウェアの少なくとも１つで実装されてもよい。

（実施の形態のまとめ）
以上、説明したように、本実施の形態によれば、基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置であって、前記基地局から受信する下りデータの再送制御に使用されるソフトバッファ領域を有する記憶部と、前記ソフトバッファ領域のうちの一部の領域を複数のサブバッファ領域に分割し、当該複数のサブバッファ領域のうちの１つ又は複数のサブバッファ領域を使用して、前記基地局から受信する下りデータの再送制御を行う再送制御部とを備えることを特徴とするユーザ装置が提供される。

上記の構成により、複数種類の通信の処理を行うユーザ装置において、再送制御に用いるソフトバッファ領域の不足を回避することができる。

前記ユーザ装置は、下りデータのリソースの割り当てを含む下り制御情報を前記基地局から受信する受信部を更に備え、前記再送制御部は、前記下り制御情報に基づいて、前記リソースで送信される前記下りデータの再送制御に使用する、前記ソフトバッファ領域の中の領域を決定することとしてもよい。この構成により、ユーザ装置は、下りデータに適合した領域を迅速に決定できる。

前記再送制御部は、前記ソフトバッファ領域から前記一部の領域を除いたバッファ領域を使用して、第１の下りデータの再送制御を行い、前記１つ又は複数のサブバッファ領域を使用して、前記第１の下りデータよりも送信時間間隔の短い第２の下りデータの再送制御を行うこととしてもよい。この構成により、第１の下りデータに係る通信と第２の下りデータに係る通信の処理を行うユーザ装置において、再送制御に用いるソフトバッファ領域の不足を回避することができる。

前記再送制御部は、前記基地局からの指示に基づいて、前記バッファ領域に格納されている第１のデータを削除し、前記基地局から再送された第１のデータを前記バッファ領域に格納することとしてもよい。この構成により、例えば、初回の第１のデータのリソースにパンクチャがされていた場合でも、第１のデータの復号を迅速に実行できる。

（実施形態の補足）
情報の通知は、本明細書で説明した態様／実施形態に限られず、他の方法で行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、ＤＣＩ（Downlink Control Information）、ＵＣＩ（Uplink Control Information））、上位レイヤシグナリング（例えば、ＲＲＣシグナリング、ＭＡＣシグナリング、ブロードキャスト情報（ＭＩＢ（Master Information Block）、ＳＩＢ（System Information Block）））、その他の信号又はこれらの組み合わせによって実施されてもよい。また、ＲＲＣメッセージは、ＲＲＣシグナリングと呼ばれてもよい。また、ＲＲＣメッセージは、例えば、ＲＲＣ接続セットアップ（RRC Connection Setup）メッセージ、ＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。

本明細書で説明した各態様／実施形態は、ＬＴＥ（Long Term Evolution）、ＬＴＥ−Ａ（LTE-Advanced）、ＳＵＰＥＲ３Ｇ、ＩＭＴ−Ａｄｖａｎｃｅｄ、４Ｇ、５Ｇ、ＦＲＡ（Future Radio Access）、Ｗ−ＣＤＭＡ（登録商標）、ＧＳＭ（登録商標）、ＣＤＭＡ２０００、ＵＭＢ（Ultra Mobile Broadband）、ＩＥＥＥ８０２．１１（Ｗｉ−Ｆｉ）、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ）、ＩＥＥＥ８０２．２０、ＵＷＢ（Ultra-WideBand）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、その他の適切なシステムを利用するシステム及び／又はこれらに基づいて拡張された次世代システムに適用されてもよい。

入出力された情報等は特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルで管理してもよい。入出力される情報等は、上書き、更新、または追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。

判定又は判断は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

本明細書で説明した情報、信号などは、様々な異なる技術のいずれかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、情報、信号、ビット、シンボルなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、又はこれらの任意の組み合わせによって表されてもよい。

なお、本明細書で説明した用語及び／又は本明細書の理解に必要な用語については、同一の又は類似する意味を有する用語と置き換えてもよい。例えば、チャネル及び／又はシンボルは信号（シグナル）であってもよい。また、信号はメッセージであってもよい。

ユーザ装置は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。

本明細書で説明した各態様／実施形態の処理手順、シーケンスなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本明細書で説明した方法については、例示的な順序で様々なステップの要素を提示しており、提示した特定の順序に限定されない。

本明細書で説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

本明細書で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up)（例えば、テーブル、データベースまたは別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。

本明細書で使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

以上、本発明について詳細に説明したが、当業者にとっては、本発明が本明細書中に説明した実施形態に限定されるものではないということは明らかである。本発明は、特許請求の範囲の記載により定まる本発明の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本明細書の記載は、例示説明を目的とするものであり、本発明に対して何ら制限的な意味を有するものではない。

ＵＥユーザ装置
ｅＮＢ基地局
１０１信号送信部
１０２信号受信部
１０３設定情報管理部
１０４再送制御部
２０１信号送信部
２０２信号受信部
２０３リソース割り当て部
２０４再送制御部
１００１プロセッサ
１００２メモリ
１００３ストレージ
１００４通信装置
１００５入力装置
１００６出力装置

Claims

基地局とユーザ装置とを有する無線通信システムにおける前記ユーザ装置であって、
前記基地局から受信する下りデータの再送制御に使用されるソフトバッファ領域を有する記憶部と、
前記ソフトバッファ領域のうちの一部の領域を複数のサブバッファ領域に分割し、当該複数のサブバッファ領域のうちの１つ又は複数のサブバッファ領域を使用して、前記基地局から受信する下りデータの再送制御を行う再送制御部と
を備えることを特徴とするユーザ装置。
下りデータのリソースの割り当てを含む下り制御情報を前記基地局から受信する受信部を更に備え、
前記再送制御部は、前記下り制御情報に基づいて、前記リソースで送信される前記下りデータの再送制御に使用する、前記ソフトバッファ領域の中の領域を決定する
ことを特徴とする請求項１に記載のユーザ装置。
前記再送制御部は、前記ソフトバッファ領域から前記一部の領域を除いたバッファ領域を使用して、第１の下りデータの再送制御を行い、前記１つ又は複数のサブバッファ領域を使用して、前記第１の下りデータよりも送信時間間隔の短い第２の下りデータの再送制御を行う
ことを特徴とする請求項１又は２に記載のユーザ装置。
前記再送制御部は、前記基地局からの指示に基づいて、前記バッファ領域に格納されている第１のデータを削除し、前記基地局から再送された第１のデータを前記バッファ領域に格納する
ことを特徴とする請求項３に記載のユーザ装置。
基地局と、下りデータの再送制御に使用されるソフトバッファ領域を有する記憶部を備えるユーザ装置と、を有する無線通信システムにおける前記ユーザ装置が実行する再送制御方法であって、
前記ソフトバッファ領域のうちの一部の領域を複数のサブバッファ領域に分割し、当該複数のサブバッファ領域のうちの１つ又は複数のサブバッファ領域を使用して、前記基地局から受信する下りデータの再送制御を行う
ことを特徴とする再送制御方法。