以下、図面を用いて実施例を説明する。ただし、本発明は以下に示す実施の形態の記載内容に限定して解釈されるものではない。本発明の思想ないし趣旨から逸脱しない範囲で、その具体的構成を変更し得ることは当業者であれば容易に理解される。本明細書で引用した刊行物、特許および特許出願は、そのまま本明細書の説明の一部を構成する。
図1は、処理手順の実施の形態を示すフローチャートである。
図2は、上り制御信号のリソースを管理する表の例である。
図2では上り制御信号がResource indexで管理されており、1つのResource indexに1つの端末を割り当てることができる。図2では、上り制御信号が周波数、直交符号、巡回シフトによって多重されることを仮定しており、それぞれ、周波数m、符号n_oc、巡回シフトn_csの番号を持つ。1つの標準等の規定により、1つのResource indexに対して(m、n_oc、n_cs)の組が一意に決定されるものとする。図2は、それぞれのResource indexに割り当てられた端末のID(UE ID)を保持している。
図1のフローチャートの動作手順を以下に示す。
ステップ101では、上り制御信号管理表を初期化する。具体的には、図2の上り制御信号のリソース管理表で、UE IDを全てのResource indexに対してNone(割り当て無し)にする。
ステップ102では、上り制御信号の割り当てが必要な端末の中から1つを選択する。端末の選択の順番は、例えばUE IDの小さい順、ランダムな順、あるいはQoSによる優先順などが考えられる。
ステップ103では、標準等の規定に従って、ステップ102で選択された端末の上り制御信号を配置するResource indexの候補値を計算する。複数のResource indexが候補となっても良い。
ステップ104では、ステップ103で得られたResource indexの候補値から、利用可能なResource indexを検索する。Resource indexが利用可能かどうかは図2の上り制御信号管理表を用いて判断する。Resource indexの候補値を検索し、そのUE IDを読んで、そのResource indexが既に割り当て済みかどうか確認する。他のUE IDが割り当て済みであれば、そのResource indexは利用できない。
Resource indexが割り当て済みでなければ、次に、そのResource indexとmとn_csが同じでn_ocのみが異なるResource indexを検索し、そのUE IDを読む。その結果、他の端末に割り当て済みであれば、ここで対象としたResource indexの候補値は利用できない。例えば、Resource index=0はUE IDがNoneであり、またn_ocのみが異なるResource index=12、24のUE IDもNoneであるので、Resource index=0を利用することは可能である。一方、Resouece index=1はUE IDがNoneであるが、n_oc=1となるResouece index=13のUE IDがID=51の端末に割り当て済みである。従って、Resource index=1を利用するとResource index=13とn_ocのみ異なる信号が多重されて干渉するため、Resouece index=1は利用できない。
ステップ105では、ステップ104の結果から、利用可能なResource indexが存在するかどうかで分岐する。存在するならステップ106へ、存在しないならステップ108へ進む。
ステップ106では、端末が利用する上り制御信号のリソースを選択する。ステップ104で、利用可能なResource indexが1つだけみつかった場合にはそのリソースを、複数みつかった場合にはそのうちの1つを上り制御信号のリソースとする。複数の候補から1つを決定する方法には特段の決まりが無く、最初にみつかったリソースを選択する、あるいはランダムに選択するなどの方法がある。
ステップ107では、ステップ106の結果により図2の上り制御信号管理表を更新する。例えば、ステップ106でID番号60の端末に対してResource index=0のリソースが選択された場合、図2のResource index=0のUE IDをID番号である60に変更する。
ステップ108では、ステップ104で割り当て可能なリソースが見つからなかったため、当該端末への上り制御信号の割り当てをあきらめる。
ステップ109では、他に上り制御信号の割り当てが必要な端末があるかどうかを確認する。まだ上り制御信号の割り当てが必要な端末があればステップ102へ進み、無いならこのフローを終了する。
このように、図2の上り制御信号管理表でリソースの利用状況を管理し、m、n_csが同じでn_ocのみ異なる複数のリソースに上り制御信号が割り当てられないようにすることで、符号で多重された上り制御信号の分離における干渉の影響を低減できる。
上り制御信号に割り当て可能なリソースは複数準備され、順にResource indexの番号が振られる。しかし、実際には全てのResource indexが使用されるわけではない。符号分割多重を前提としてResource indexの番号を振ったとしても、本実施例の方法では、上り制御信号の多重による符号間干渉の影響を回避できる。これにより、少ない時間・周波数領域に符号多重分割の分だけ多くのResource indexを準備することができるため、データ信号のために多くの時間・周波数領域を利用することができる。
ここで、図2の上り制御信号管理表で、端末移動速度(UE speed)という状態を追加しても良い。図2の上り制御信号管理表は、符号分割多重における符号間干渉を回避するためのものである。従って、符号間干渉が発生しないと想定される場合には、上り制御信号を符号分割で多重しても構わない。例えば、端末の移動速度が低速で、ドップラー効果の影響が小さいと判定される場合には、当該端末の上り制御信号が、他の端末の上り制御信号と符号分割で多重されても良い。そこで、図1のステップ107では、ステップ106で上り制御信号にリソースを割り当てた端末の移動速度が高速である場合にはUE speedをHighとし、低速である場合にはUE speedをLowとしてもよい。また、ステップ104では、ステップ102で選択した端末の移動速度が高速である場合にはmとn_csが同じでn_ocのみが異なるResource indexのUE IDがNoneであるResource indexのみ利用可能と判定し、端末の移動速度が低速である場合にはmとn_csが同じでn_ocのみが異なるResource indexのUE IDがNoneあるいは、UE speedがLowであるResource indexを利用可能と判定することができる。
例えば、低速移動している端末に上り制御信号を割り当てる場合、ステップ103でResource indexの候補値に23があるとする。Resource index=23のUE IDはNoneである。さらにmとn_csが同じでn_ocのみが異なるResource indexは11と35であり、Resource index=11のUE IDはNone、Resource index=35のUE IDは52で割り当て済みであるが、UE speedがLowである。よって、ステップ106で当該端末の上り制御信号をResource index=23に割り当てることができる。
このように、低速移動している端末を区別することで、低速移動している端末に対して効率的にResource indexを割り当てることが可能であり、利用可能なResource indexの不足による上り制御信号の割り当て延期(ステップ108の状態)の確率を低減することができる。
また、上記の過程において、ステップ106において低速移動している端末にはmとn_csが同じでn_ocのみが異なるResource indexに別の低速端末が割り当て済みであるようなResource indexを優先的に割り当てることができる。このようなResource indexは高速移動している端末には割り当てられないResource indexであるため、このResource indexを低速移動している端末に割り当てても、高速移動している端末が利用できるResource indexの数が減少しない。このことから、高速移動している端末の上り制御信号の割り当て延期(ステップ108の状態)の確率を高めることなく低速移動している端末に上り制御信号を割り当てることができる。
端末の移動速度は、例えばドップラー効果によって上り信号に生じる周波数ずれにより推定することが可能であり、図2の上り制御信号管理表とは別に管理しても良い。
図3は、LTE基地局に本発明を適用した場合の、上り制御信号のリソースを管理する表の例である。図2との相違点を以下に説明する。
図3のmは、PUCCH regionの番号を示している。ここでは、PUCCH format 1/1a/1bのPUCCH regionがm=4から始まる場合を想定し、m=4ではn_cs=0、1、2の3通りのみを利用している。PUCCH regionの開始されるmの値、最初のPUCCH regionで利用するn_csの値は、報知情報に含まれるパラメータで決まる。deltaPUCCH-Shiftの値は1を想定している。UE IDとして基地局と端末の間で設定されるRNTI(Radio Network Temporary Identifier)が用いられている。
LTEではPUCCH format 1/1a/1bに上り制御信号の直交符号分割多重を用いる。PUCCH format 1/1a/1bで送信される上り制御情報にはSR(Scheduling Request)とHARQ-ACK(Hybrid Automatic Repeat request-ACKnowledgement)の2種類がある。
HARQ-ACKは下りデータ信号が正しく届いたかどうかを通知するための上り制御信号である。下りデータ信号の割り当て通知は下り制御信号によって通知される。下り制御信号はPDCCH(Physical Downlink Control CHannel)と呼ばれる下り制御信号チャネルに割り当てられる。PDCCHのリソースには番号が振られており、CCE index(Control Channel Element index)と呼ばれる。下り制御信号によって通知された下りデータ信号に対してHARQ-ACKが上り制御信号で送信される際、HARQ-ACKに割り当てられる上り制御信号のResource indexは、下り制御信号のCCE indexによって一意に決まる。従って、PDCCHのCCE indexとPUCCHのResource indexは同時に管理される必要があるため、図3の上り制御信号管理表にはPDCCHとPUCCHの欄がある。
HARQ-ACKは下りデータ信号の受信後に送信されるものであるから、図3で組にされているPUCCHはPDCCHよりも後のsubframeのものであり、その時間差は標準で規定される。端末のPDCCH受信特性を高めるため、連続する複数のCCE indexが1つの下り制御信号に割り当てられる場合があるが、その場合のPUCCHのResource indexは割り当てられたCCE indexのうち値が最も小さいものを基準に計算される。
図3はTDD(Time Division Duplex)を想定した表となっている。TDDでは上りのsubframe数が下りのsubframe数より少ないことがあるため、PUCCHに複数の下りsubframeに対応するHARQ-ACKを割り当てることがある。そのため、PDCCHの欄には複数のsubframeに対応するCCE indexが含まれる。この例ではTDDを想定しているが、本発明はTDDに限定されるものではなく、FDD(Frequency Division Duplex)でも同様に実施できる。
SRは端末が基地局に対して上りデータ通信のリソース割り当てを要求するために使用される。基地局は端末との接続確立時に、予めSR用の上り制御信号のリソースを割り当てて、その情報を端末に通知する。図3ではSR用に11個のResource index(0から10)を確保している。この数は報知情報に含まれるパラメータで決まる。
LTEでは、図9に示すようにPUCCHが2つのスロットに分割して配置され、スロットごとに異なるn_ocとn_csが用いられる。そのため、図3ではn_oc、n_csが2つのスロットそれぞれに対して示されている。それぞれのスロットにおけるm、n_oc、n_csはResource indexから算出されることが、標準により規定されている。
1つのResource indexが、2つのスロットでそれぞれ異なる(n_oc、 n_cs)の組を持つため、図1のステップ204での検索方法を修正する必要がある。以下に示す2通りの検索方法があるが、どちらを採用しても良い。
第1の方法は、全スロットで符号間干渉を回避する方法である。図3の上り制御信号管理表でResource indexの候補値を検索し、そのRNTIを読んで、そのResource indexが既に割り当て済みかどうか確認する。割り当てが無い場合、第1スロットに着目し、そのResource indexとmとn_csが同じでn_ocのみが異なるResource indexを検索し、そのRNTIを読む。その結果、他の端末に割り当て済みであれば、ここで対象としたResource indexの候補値は利用できない。次に第2スロットに着目し、そのResource indexとmとn_csが同じでn_ocのみが異なるResource indexを検索し、そのRNTIを読む。その結果、他の端末に割り当て済みであれば、ここで対象としたResource indexの候補値は利用できない。以上により、第1スロット、第2スロットの両方で上り制御信号に符号間干渉が発生しないResource indexを検索し、利用可能とする。
例えば、図3のResource index=11はRNTIがNoneであり、また第1スロットに着目するとn_ocのみが異なるResource index=23、35のRNTIがNoneであり、第2スロットに着目してn_ocのみが異なるResource index=15、19のRNTIもNoneであるので、Resource index=11は両方のスロットで干渉を回避して利用可能である。一方、Resource index=40はRNTIがNoneだが、第1スロットに着目するとn_ocのみが異なるResource index=16のRNTIがNoneではなく割り当て済みであるため、Resource index=40は利用可能ではない。
第2の方法は、いずれか一方のスロットで符号間干渉を回避する方法である。図3の上り制御信号管理表でResource indexの候補値を検索し、そのRNTIを読んで、そのResource indexが既に割り当て済みかどうか確認する。割り当てが無い場合、第1スロットに着目し、そのResource indexとmとn_csが同じでn_ocのみが異なるResource indexを検索し、そのRNTIを読む。その結果、他の端末に割り当てが無ければ、ここで対象としたResource indexの候補値は利用できる。次に第2スロットに着目し、そのResource indexとmとn_csが同じでn_ocのみが異なるResource indexを検索し、そのRNTIを読む。その結果、他の端末に割り当てが無ければ、ここで対象としたResource indexの候補値は利用できる。以上により、第1スロット、第2スロットの少なくとも1つのスロットで上り制御信号に符号間干渉が発生しないResource indexを利用可能とする。
この方法では、PUCCH format 1/1a/1bの受信の際、符号間干渉の発生しないスロットの受信信号でドップラー効果による周波数ずれを推定し、その結果を用いて符号間干渉の発生するスロットの受信信号の補正を実施することが可能である。例えば、図3のResource index=40はRNTIがNoneであり、第2スロットに着目してn_ocのみが異なるResource index=36、44のRNTIもNoneであるので、Resource index=40は利用可能である。第1スロットに着目するとn_ocのみが異なるResource index=16のRNTIがNoneではなく割り当て済みであるが、第2スロットで符号間干渉が回避されているので問題ない。
ただし、第2の方法では、片方のスロットで符号間干渉が有る場合、干渉する相手のResource indexが利用不能にならないように注意しなくてはならない。例えば、図3のResource index=39はRNTIがNoneであり、第2スロットに着目してn_ocのみが異なるResource index=35、 43のRNTIもNoneであるため、Resource index=39は利用可能である。第1スロットに着目してn_ocのみが異なるResource index=27のRNTIは割り当て済みであるため、第1スロットではResource index=27との符号間干渉が残る。しかし、Resource index=27は第2スロットに着目してn_ocのみが異なるResource index=31にRNTIが割当たっているため、第2スロットに符号間干渉がある。つまり、Resource index=39を使用すると、割り当て済みのResource index=27に対して、第1、2スロットの両方で符号間干渉が生じてしまうため、Resource index=27が利用不能となってしまう。従って、Resource index=31を利用不能と判定する。
第1の方法では、全てのスロットで符号間干渉が発生しないため、どちらか1つのスロットで符号間干渉が発生する可能性がある第2の方法より受信特性が良い。一方、第2の方法ではResource indexを利用可能とする条件を第1の方法より緩和しているため、第2の方法を用いれば、利用可能なResource indexの不足による上り制御信号の割り当て延期(図1のステップ108の状態)の確率を低減することができる。設計者はこのトレードオフの関係を考慮して、いずれかの方法を選択することができる。
以上の通り、上り制御信号管理表を構成することで、LTEにおいて本発明を適用することが可能になる。
図4は、SRの割り当て処理手順の実施の形態を示すフローチャートである。
ステップ201では、上り制御信号管理表を初期化する。具体的には、図3の上り制御信号のリソース管理表で、RNTIを全てのResource indexに対してNone(割り当て無し)にする。
ステップ202では、端末との新たな接続の確立、あるいは接続の確立している端末との接続解除のイベント発生を待つ。
ステップ203では、ステップ202で発生したイベントに応じて分岐する。端末との新たな接続の確立が発生した場合にはステップ204へ、接続の確立している端末との接続解除が発生した場合にはステップ209へ移る。
ステップ204では、実施例2の第1または第2の方法により、利用可能な上り制御信号のResource indexを検索する。
ステップ205では、ステップ204の結果から、利用可能なリソースが存在するかどうかで分岐する。存在するならステップ206へ、存在しないならステップ208へ進む。
ステップ206では、ステップ204で得られたResource indexを、ステップ202で発生した新たな接続先の端末が使用するSR上り制御信号のリソースとする。
ステップ207では、ステップ206の結果により図3の上り制御信号管理表を更新する。その後、ステップ202へ戻る。
ステップ208では、ステップ204で割り当て可能なリソースが見つからなかったため、当該端末への上り制御信号の割り当てをあきらめる。その後、ステップ202へ戻る。
ステップ209では、図3の上り制御信号管理表のうち、ステップ202で発生した接続解除に対応する端末の上り制御信号の割り当てを元に戻す。例えば、ステップ202で発生した接続解除の端末のRNTIが60であり、図3の上り制御信号管理表でRNTI=60の端末にScheduling Request上り制御信号のリソースとしてResource index=0が割り当てられていた場合、Resource index=0のRNTIをNoneに戻す。その後、ステップ202へ戻る。
基地局は端末との接続確立時に、予めSR用の上り制御信号のリソースを割り当てて、その情報を端末に通知する。そのため、ステップ202で端末との新たな接続の確立をとらえ、ステップ204で割り当て可能なResource indexを検索することで、同一の時間・周波数領域に複数端末のSR上り制御信号が配置されることを回避できる。
また、端末との接続が解除される場合にはSRへのリソース割り当ても不要となるため、図3の上り制御信号管理表からも割り当てを削除する必要がある。そのため、ステップ202で接続の確立している端末との接続解除をとらえ、ステップ209で上り制御信号の割り当て情報を元に戻して解放することで、以後接続する端末に対してリソースを再割り当てすることができる。
ここで、図3の上り制御信号管理表のうち、SRの割り当て管理に対応する部分(図3の例ではResource index 0から10)を複数の上りsubframeに対して予め準備する。LTEでは、SRの割り当てには周期が定められており、その周期内で端末へのSRの割り当てが管理される。例えば、80subframeの周期を設定すると、図3の上り制御信号管理表のうち、SRの割り当て管理に対応する部分を80subframeの間のPUCCHについて準備することで、全SR送信機会の上り制御信号を管理することができる。もし、SRの割り当て周期を短く、例えば5subframeに設定するのであれば、5subframeの間のPUCCHについて上り制御信号管理表を準備すれば良い。
図5は、下り制御信号の割り当て処理手順の実施の形態を示すフローチャートである。
前述の通り、LTEではPUCCHのformat 1/1a/1bでSRの他にHARQ-ACKが送信される。下り制御信号によって通知された下りデータ信号に対してHARQ-ACKが上り制御信号で送信される際、HARQ-ACKに割り当てられる上り制御信号のResource indexは、下り制御信号のCCE indexによって一意に決まる。従って、PDCCHのCCE indexの割り当て時に、PUCCHのResource index割り当てを管理する必要がある。
ステップ301では、実施例3から得られる、SRの割り当てによって生成された上り制御信号管理表で、図3の上り制御信号管理表を初期化する。SRの割り当てられていないPUCCHのResource indexに対応するRNTIは全てNone(割り当て無し)に初期化するとともに、PDCCHのRNTIも全てNone(割り当て無し)に初期化する。
ステップ302では、割り当てる下り制御信号を1つ選択する。
ステップ303では、割り当てる下り制御信号の種別に応じて分岐する。下り制御信号が、下りデータ信号割り当て通知である場合にはステップ304へ、上りデータ信号割り当て通知である場合にはステップ305へ、その他の下り制御信号の場合にはステップ306へ進む。
ステップ304〜306では、それぞれの場合に応じた下り制御信号へのCCE indexの割り当て処理を実施する。処理の詳細は後述する。
ステップ307では、他に割り当てが必要な下り制御信号があるかどうかを確認する。まだ下り制御信号の割り当てが必要であればステップ302へ進み、不要であればこのフローを終了する。
図6は、下り制御信号が、下りデータ信号割り当て通知である場合の、CCE indexの割り当て処理手順(ステップ304)の実施の形態を示すフローチャートである。
ステップ401では、当該下り制御信号を割り当て可能なCCE indexを検索する。複数のCCE indexの候補値を図3の上り制御信号管理表で参照することで、割り当て可能なCCE indexを検索する。検索結果として得られる、割り当て可能なCCE indexは複数存在し得る。
ステップ402では、割り当て可能なCCE indexが存在するかどうかで分岐する。存在する場合はステップ403へ、存在しない場合はステップ411へ進む。
ステップ403では、当該下りデータ信号割り当て通知で割り当てられる下りデータ信号に対してHARQ-ACKをPUCCH format 1a/1bで応答する必要があるかどうかで分岐する。必要な場合にはステップ405へ、不要な場合にはステップ410へ進む。
通常、下りデータ信号には必ずHARQ-ACKの応答が必要であり、PUCCH format 1a/1bの上り制御信号が割り当てられるが、その割り当てが不要となる場合がある。例えば、下りデータ信号を割り当てられる端末がHARQ-ACKを送信するsubframeにおいて同時に上りデータ信号の割り当てがある場合、HARQ-ACKが上りデータ信号に多重されて応答されるため、上り制御信号の割り当てが必要無い。また、下りデータ信号を割り当てられる端末がHARQ-ACKを送信するsubframeにおいて、CQI(Channel Quality Information)を同時に送信する場合、HARQ-ACKはPUCCH format 2a/2bで返信されるため、PUCCH format 1a/1bの上り制御信号の割り当てが必要ない。TDDで複数のsubframeに割り当てられた下りデータ信号に対するHARQ-ACKの応答を束ねて送信するbundlingモードの場合、そのうち1つのsubframeに割り当てられた下りデータ信号に対するHARQ-ACKのみが利用されるため、その他のsubframeに割り当てられた下りデータ信号にHARQ-ACK用の上り制御信号を割り当てる必要が無い。
ステップ405では、ステップ401で得られた下り制御信号の割り当てCCE indexの候補値に対して、対応するHARQ-ACK上り制御信号のResource indexを計算する。ただし、図3のように上り制御信号管理表を構成すれば、表からCCE indexに対応するResource indexを求めることができる。
ステップ406では、ステップ405で得られたResource indexの候補値から、利用可能なResource indexを検索する。Resource indexが利用可能かどうかは、実施例2の第1または第2の方法等を用い、図3の上り制御信号管理表を用いて判断する。
ここで、実施例1と同様に、端末の移動速度が低速である場合にはmとn_csが同じでn_ocのみが異なるResource indexのRNTIがNoneあるいは、UE speedがLowであるResource indexを利用可能と判定することができる。例えば、図3の上り制御信号管理表があり、低速移動している端末に上り制御信号を割り当てる場合に、Resource indexの候補値に12があるとする。Resource index=12のRNTIはNoneである。第1スロットに着目し、mとn_csが同じでn_ocのみが異なるResource index=24、36のRNTIを見る。Resource index=24のRNTIはNoneであり、Resource index=36のRNTIは割り当て済みであるが、UE speedがLowである。よって、Resource index=12を利用可能と判断できる。
ステップ407は、ステップ406の結果から、利用可能なリソースが存在するかどうかで分岐する。存在するならステップ408へ、存在しないならステップ411へ進む。
ステップ408では、端末が利用する上り制御信号のリソースを選択する。ステップ406で、利用可能なResource indexが1つだけみつかった場合にはそのリソースを、複数みつかった場合にはそのうちの1つを上り制御信号のリソースとする。複数の候補から1つを決定する方法には特段の決まりが無く、最初にみつかったリソースを選択する、あるいはランダムに選択するなどの方法がある。また、選択したResource indexに対応するCCE indexを下り制御信号に割り当てる。
ステップ409では、ステップ408の結果により図3の上り制御信号管理表を更新する。具体的には、選択したPUCCHのResource indexに対して端末のRNTIを設定し、対応するPDCCHのCCE indexに対しても端末のRNTIを設定する。
ステップ410では、ステップ401で得られたCCE indexの候補値から1つを選択し、下り制御信号に割り当てる。上り制御信号割り当ては必要ないので、図3の上り制御信号管理表による制限は無い。この割り当てにより、選択したCCE indexに対して端末のRNTIを設定することで、図3の上り制御信号管理表を更新する。
ステップ411は、ステップ401で割り当て可能なCCE indexがみつからない、あるいはステップ406で割り当て可能な上り制御信号リソースが見つからない場合の処理であり、当該端末への下りデータ信号の割り当てと対応する下り制御信号の割り当てをあきらめる。
図7は、下り制御信号が、上りデータ信号割り当て通知である場合の、CCE indexの割り当て処理手順(ステップ305)の実施の形態を示すフローチャートである。
ステップ501では、当該下り制御信号を割り当て可能なCCE indexを検索する。複数のCCE indexの候補値を図3の上り制御信号管理表で参照することで、割り当て可能なCCE indexを検索する。検索結果として得られる、割り当て可能なCCE indexは複数存在し得る。
ステップ502では、割り当て可能なCCE indexが存在するかどうかで分岐する。存在する場合はステップ503へ、存在しない場合はステップ508へ進む。
ステップ503では、ステップ501で得られたCCE indexの候補値から1つを選択し、下り制御信号に割り当てる。図3の上り制御信号管理表による制限は無い。この割り当てにより、選択したCCE indexに対して端末のRNTIを設定することで、図3の上り制御信号管理表を更新する。
ステップ504では、上りデータ信号を割り当てられる端末に下りデータ信号も割り当てられ、その下りデータ信号に対するHARQ-ACKを上りデータ信号と同じsubframeに送信するかどうかで分岐する。そのような下りデータ信号の割り当てがある場合にはステップ505へ、無い場合にはステップ506へ進む。
ステップ505では、当該端末に割り当てられているHARQ-ACK上り制御信号のResource indexを開放し、図3の上り制御信号管理表を更新する。例えば、端末に対してHARQ-ACK上り制御信号が割り当てられている場合、そのResource indexに対するRNTIをNoneに変更する。
ステップ506では、上りデータ信号を割り当てられる端末に、SR上り制御信号も同じsubframeで割り当てられているかどうかで分岐する。SR上り制御信号の割り当てがある場合にはステップ507へ、無い場合には終了する。
ステップ507では、当該端末に割り当てられているSR上り制御信号のResource indexを開放し、図3の上り制御信号管理表を更新する。例えば、端末に対してSR上り制御信号が割り当てられている場合、そのResource indexのRNTIをNoneに変更する。
ステップ508では、ステップ501で割り当て可能なCCE indexがみつからないため、当該端末への上りデータ信号の割り当てと対応する下り制御信号の割り当てをあきらめる。
図8は、下り制御信号が、上記以外の下り制御信号である場合の、CCE indexの割り当て処理手順(ステップ306)の実施の形態を示すフローチャートである。
ステップ601では、当該下り制御信号を割り当て可能なCCE indexを検索する。複数のCCE indexの候補値を図3の上り制御信号管理表で参照することで、割り当て可能なCCE indexを検索する。検索結果として得られる、割り当て可能なCCE indexは複数存在し得る。
ステップ602では、割り当て可能なCCE indexが存在するかどうかで分岐する。存在する場合はステップ603へ、存在しない場合はステップ604へ進む。
ステップ603では、ステップ601で得られたCCE indexの候補値から1つを選択し、下り制御信号に割り当てる。図3の上り制御信号管理表による制限は無い。この割り当てにより、選択したCCE indexに対して、割り当て済みであることを示す値(例えば0)をRNTIに設定することで、図3の上り制御信号管理表を更新する。
ステップ604では、ステップ601で割り当て可能なCCE indexがみつからないため、当該端末への下り制御信号の割り当てをあきらめる。
このように、図3の上り制御信号管理表でリソースの利用状況を管理し、下り制御信号のCCE indexと上り制御信号のResource indexを割り当てることで、PUCCH region、巡回シフトが同じで符号のみ異なる複数のリソースに上り制御信号が割り当てられないようにし、符号で多重された上り制御信号の分離における干渉の影響を低減できる。
図3の上り制御信号管理表で上り制御信号を管理する際に、実施例1に記載の方法と同様に、端末移動速度(UE speed)という状態を追加しても良い。これはステップ301の上り制御信号管理表の初期化でも適用し、SRのResource indexに対して端末移動速度の状態を設定できる。これによって、移動速度の遅い端末のHARQ-ACK上り制御信号と、移動速度の遅い端末のSR上り制御信号を、mとn_csの等しいResource indexを用いて符号分割多重することが可能となる。
ステップ303の分岐における、その他の下り制御信号には、例えばSystem Information(報知情報)やPaging、マルチキャストデータの下りデータ割り当て通知が含まれる。これらのデータに対して端末からHARQ-ACKが送信されることは無い。また、下りデータ送信の無い制御信号もその他の下り制御信号に含まれる。LTEのRandom Access Responseの下りデータ信号も、端末からHARQ-ACKが送信されない。ただし、Random Access Responseはデータ部に上り信号割り当て情報が含まれているため、当該上り信号が送信されるsubframeで本実施例を適用する場合には、上りデータ信号割り当て通知があるものとして処理すれば良い。また、LTEのTDD方式ではHARQ-ACKの送信方式としてBundlingモードがある。TDDで上り信号に割り当てられるsubframe数が下り信号に割り当てられるsubframe数よりも少ない場合、同一端末に連続するsubframeで下りデータ信号が割り当てられると、HARQ-ACK上り制御信号は多重して1つだけ送信される。このHARQ-ACK上り制御信号のResource indexは、最初に下りデータが送信されたsubframeの下り制御信号のCCE indexに対応するものだけとなる。従って、その他の下りデータ信号割り当ての下り制御信号に対してはHARQ-ACKの応答が不要となる。ステップ303では、これらの下り制御信号をその他の下り制御信号として分類してもよい。
ステップ410では、上り制御信号管理表を参照し、利用不能、あるいは低速端末のみが利用可能なResource indexに対応するCCE indexを優先的に選択してもよい。CCE indexの数は有限個しか用意されないため、複数の端末に下り制御信号を割り当てる必要がある場合には、CCE indexが不足してしまうことが考えられる。従って、HARQ-ACK上り制御信号を送信する必要のある端末にとって利用できないCCE indexをステップ410で優先的に割り当てることにより、HARQ-ACK上り制御信号を送信する必要のある端末が利用できるCCE indexを確保し、CCE indexが不足する可能性を低減することができる。
ステップ503では、上りデータ信号の割り当てに対応した下り制御信号のCCE indexを決定している。LTEでは上りデータ信号の割り当てがある場合にはHARQ-ACKが上りデータ信号の領域に多重され、上り制御信号が用いられないため、CCE indexを選択する際に上り制御信号管理表による制限を検討する必要はない。この割り当てによる上り制御信号管理表の更新は、PDCCHのCCE indexの割り当て情報の更新のみでよい。ここで、上り制御信号管理表を参照し、利用不能、あるいは低速端末のみが利用可能なResource indexに対応するCCE indexを優先的に選択してもよい。CCE indexの数は有限個しか用意されないため、複数の端末に下り制御信号を割り当てる必要がある場合には、CCE indexが不足してしまうことが考えられる。従って、HARQ-ACK上り制御信号を送信する必要のある端末にとって利用できないCCE indexをステップ503で優先的に割り当てることにより、HARQ-ACK上り制御信号を送信する必要のある端末が利用できるCCE indexを確保し、CCE indexが不足する可能性を低減することができる。
ステップ504では、上りデータ信号を割り当てられる端末に下りデータ信号も割り当てられ、その下りデータ信号に対するHARQ-ACKを上りデータ信号と同じsubframeに送信するかを判断している。これはLTEでは上りデータ信号の割り当てがある場合にはHARQ-ACKが上りデータ信号の領域に多重され、上り制御信号が用いられないためである。従って、ステップ505ではHARQ-ACK上り制御信号に割り当てられたResource indexのRNTIをNoneに戻してよい。CCE indexの数は有限個しか用意されないため、複数の端末に下り制御信号を割り当てる必要がある場合には、CCE indexが不足してしまうことが考えられる。従って、HARQ-ACK上り制御信号の割り当てをNoneに戻す操作によって、利用可能なCCE indexを増加させ、CCE indexが不足する可能性を低減することができる。
ステップ506では、上りデータ信号を割り当てられる端末に、SR上り制御信号も同じsubframeで割り当てられているかどうかを判断している。これはLTEでは上りデータ信号の割り当てがある場合にはSR上り制御信号が送信されないためである。従って、ステップ507ではSR上り制御信号に割り当てられたResource indexのRNTIをNoneに戻してよい。CCE indexの数は有限個しか用意されないため、複数の端末に下り制御信号を割り当てる必要がある場合には、CCE indexが不足してしまうことが考えられる。従って、SR上り制御信号の割り当てをNoneに戻す操作によって、利用可能なCCE indexを増加させ、CCE indexが不足する可能性を低減することができる。
ステップ603では、HARQ-ACK上り制御信号が伴わない下り制御信号のCCE indexを選択しているので、上り制御信号管理表による制限を検討する必要が無く、またこの割り当てによる上り制御信号管理表の更新も必要無い。この割り当てによる上り制御信号管理表の更新は、PDCCHのCCE indexの割り当て情報の更新のみでよい。ここで、上り制御信号管理表を参照し、利用不能、あるいは低速端末のみが利用可能なResource indexに対応するCCE indexを優先的に選択してもよい。CCE indexの数は有限個しか用意されないため、複数の端末に下り制御信号を割り当てる必要がある場合には、CCE indexが不足してしまうことが考えられる。従って、HARQ-ACK上り制御信号を送信する必要のある端末にとって利用できないCCE indexをステップ603で優先的に割り当てることにより、HARQ-ACK上り制御信号を送信する必要のある端末が利用できるCCE indexを確保し、CCE indexが不足する可能性を低減することができる。
LTEでは、例えば20MHz帯域幅で運用する場合には、1 subframeあたりにCCE indexが最大で88個準備される。上り制御信号は3つの符号で多重されるため、HARQ-ACK上り制御信号を伴う2つの下り制御信号に対してランダムにCCE indexを割り当てれば、2/87の確率で同一のFrequency index、Cyclic shift indexに符号分割多重されてしまう。つまり2.3%の確率であり、例えば高速移動端末との通信でドップラー効果が発生すると、2.3%の確率で上り制御信号の受信に誤りが発生する可能性がある。本実施例によれば、この確率を例えば1%以下に低減することが可能である。
図12は本発明の基地局の構成を示す図である。
700はスケジューラであり、コアネットワーク側と接続されデータの授受を行うとともに、PUCCH処理部701、ユーザデータ受信部702、ユーザデータ送信部703、PDCCH生成部704を介して端末と通信する。
スケジューラ700は、制御部710、ユーザデータスケジューラ711、上り制御信号管理表保持部712、端末移動速度保持部713、制御信号スケジューラ714から構成される。制御部710はスケジューラ700と他のブロックとの通信を制御する。ユーザデータスケジューラ711は、基地局と端末の間のユーザデータ通信についてのリソース割り当てをスケジュールする。スケジュール結果は制御信号スケジューラ714に通知される。上り制御信号管理表保持部712は、例えば図3の上り制御信号管理表を保持している。端末移動速度保持部713は、各端末の移動速度を保持している。典型的には、図3の上り制御信号管理表において、UE speedをLowとするか、Highとするかの情報を保持する。制御信号スケジューラ714は、例えば実施例3、実施例4に示すような、PDCCHのCCE indexやPUCCHのResource indexの割り当てを実施する。割り当てが必要な下り制御信号の情報は、ユーザデータスケジューラ711から通知される。また、ユーザデータとは関係ない制御情報信号等は制御部710から通知される。制御信号スケジューラ714による制御信号割り当て結果は、701から704のそれぞれに通知される。
701はPUCCH処理部であり、スケジューラ700からの指示に従って上り制御信号を受信する。PUCCH処理部701は、スロット分配部720、周波数シフト推定部721、上り制御信号復調部722、スロット結合部723、上り制御信号復号部724から構成される。
スロット分配部720は、705から受けた信号からPUCCH regionを構成し、それを2つのスロットへ分配する。周波数シフト推定部721は、スロット分配部720から受けた信号を用いて周波数シフトを推定する。ただし、スロットによっては上り制御信号が符号分割多重されていて、周波数シフトの推定が困難な場合がある。そのため、制御信号スケジューラ714は制御信号が符号分割多重されていないスロットを通知し、周波数シフト推定部721はその情報に基づいて適切なスロットの信号を用いて周波数シフトを推定する。上り制御信号復調部722は、周波数シフト推定部721で推定した周波数シフトに基づいて、受信信号に生じている周波数シフトを補償し、復調する。スロット結合部723は、上り制御信号復調部722で復調された2つのスロットの信号を合成する。ただし、スロットによっては上り制御信号が符号分割多重されているため、スロットによって復調された信号の品質が異なる。そのため、制御信号スケジューラ714は制御信号が符号分割多重されていないスロットを通知し、上り制御信号復調部722はその情報をもとにスロットごとに重みづけをして信号を合成する。上り制御信号復号部724は、スロット結合部723で得られた信号を復号し、その結果をスケジューラ700に通知する。
702はユーザデータ受信部であり、スケジューラ700からの指示に従って上りユーザデータを受信する。制御信号スケジューラ714から通知される割り当て情報をもとに、705から受けた信号から、ユーザデータを復元し、スケジューラ700に通知する。
703はユーザデータ送信部であり、スケジューラ700からの指示に従って下りユーザデータを送信する。制御信号スケジューラ714から通知される割り当て情報をもとに、スケジューラ700から受けたユーザデータを無線信号に変換し、706に通知する。
704はPDCCH生成部であり、スケジューラ700、制御信号スケジューラ714からの指示に従って下り制御信号を生成し、706に通知する。
705は受信信号分配部であり、707から受けた信号を上り制御信号や上りユーザデータに分割し、それぞれPUCCH処理部701、ユーザデータ受信部702へ渡す。
706は送信信号結合部であり、ユーザデータ送信部703、PDCCH処理部704から受けた信号を結合して無線信号を生成し、707へ渡す。
707はアナログフロントエンドであり、アンテナ708で受けたアナログ信号をデジタル信号に変換して受信信号分配部705へ渡し、また、送信信号結合部706から受けたデジタル信号をアナログ信号に変換してアンテナ708へ渡す。
以上のように基地局を構成することで、本発明の制御信号へのリソース割り当てを実施することが可能である。
以上のスケジューラの構成は、処理装置、記憶装置を備えるコンピュータを用い、処理装置上で動作するソフトウエアで構成することができる。コンピュータは、入力装置、出力装置等を備えてもよい。また、ソフトウエアで構成した機能と同等の機能は、FPGA(Field Programmable Gate Array)、ASIC(Application Specific Integrated Circuit)などのハードウエアでも実現できる。入力装置、出力装置、処理装置、記憶装置の任意の部分が、有線あるいは無線のネットワークで接続された他の装置で構成されてもよい。発明の思想としては等価であり、変わるところがない。
本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることが可能である。また、各実施例の構成の一部について、他の実施例の構成の追加・削除・置換をすることが可能である。