JP6261886B2 - 無線基地局装置およびバッファ制御方法 - Google Patents

Description

本発明は、無線通信技術の分野に関し、特に、帯域遅延積に基づくバッファ制御の手法と構成に関する。

３ＧＰＰ（3rd Generation Partnership Project）の標準規格であるＬＴＥ（Long Term Evolution）では、無線基地局において、リソースの分割損を低減するため、基地局に接続しているユーザ装置間、及び設定されている論理チャネル間で下りリンク（ＤＬ：Down Link）バッファを共有する制御が採用される。

そのようなＤＬバッファは有限なリソースであるため、上位ノードから到来する下りリンクデータが大量にある場合は、バッファからデータがあふれ出る可能性がある。データのオーバーフロー時には、バッファに収容できないでデータを破棄する必要があるが、その簡単な制御方法として、バッファ内の最古のデータから破棄する制御が考えられる。

しかし、一律に最も古いデータから破棄した場合、適切なユーザにバッファを割り当てることができず、バッファの実質的な利用効率が低下する。

バッファデータのオーバーフロー時に、バッファされているデータの種別に応じて、所定の種別のデータだけを破棄する方法が提案されている（たとえば、特許文献１参照）。

特開２０１３−８５０３１号公報

図１は、最古のデータから破棄する場合の問題点を説明する図である。図１（Ａ）のように、ＤＬバッファ１０７に各ユーザのデータが順次蓄積される。ここで、ユーザ１は、無線品質が悪いにもかかわらず上位ノードから大量のＤＬデータが流入しているユーザである。このようなユーザがいると、ＤＬバッファ１０７に下りリンクデータが滞留する。図１（Ｂ）に示すように、ユーザ１へのＤＬデータがさらに流入した場合、データの破棄が必要になる。一般には古いデータから順に破棄されるが、一律に古いデータから破棄されると、図１（Ｃ）のように、他のユーザのデータがスケジューリングされる前に不当に破棄されてしまう。

このように、無線レートの良くないユーザ１のデータばかりがＤＬバッファ１０７内に滞留すると、バッファの実質的な利用効率が低下する。

そこで、無線基地局のバッファでデータのオーバーフローが生じる場合に、破棄すべきデータを適切に制御してバッファ利用効率を向上することを課題とする。

上記課題を解決するために、実施形態では、各ユーザの帯域遅延積に基づいてデータの破棄制御を行う。帯域遅延積は、特定期間において特定のユーザが送信できるデータ量を表わす。バッファのオーバーフロー時に帯域遅延積の小さいユーザのデータから優先的に破棄することによって、無線レートの小さいユーザのデータが多量にバッファに滞留することを回避する。

具体的には、本発明の第１の態様として、無線基地局装置を提供する。無線基地局装置は、
複数のユーザで共有されるバッファと、
前記バッファ内に蓄積される総データ量または空き容量を監視し、前記総データ量または前記空き容量が所定の条件を満たさなくなったときにデータ破棄制御を開始するバッファ管理部と、
前記データ破棄制御の開始に応じて、前記ユーザごとに、当該ユーザの帯域遅延積に基づいて破棄すべきデータ量を表すメトリックを算出するメトリック算出部と、
を有し、前記バッファ管理部は、前記算出されたメトリックに基づいて、前記バッファ内
のデータを前記所定の条件が満たされるまで破棄する
ことを特徴とする。

本発明の第２の態様として、複数のユーザで共有されるバッファを有する無線基地局で行われるバッファ制御方法を提供する。バッファ制御方法は、
前記無線基地局にて、前記バッファに蓄積される総データ量または空き容量を監視し、
前記総データ量または前記空き容量が所定の条件を満たさなくなったときにデータ破棄制御を開始し、
前記データ破棄制御の開始に応じて、前記ユーザごとに、当該ユーザの帯域遅延積に基づき破棄すべきデータ量を表すメトリックを算出し、
前記算出されたメトリックに基づいて、前記バッファ内のデータを前記所定の条件が満たされるまで破棄する
ことを特徴とする。

上記手法と構成により、無線基地局のバッファのオーバーフロー時に、破棄すべきデータを適切に制御してバッファの利用効率を向上することができる。

下りリンクバッファにおけるデータオーバーフローの問題を説明するための図である。 本発明が適用される移動通信システムの概略図である。 図２の移動通信システムで用いられる無線基地局装置１０の概略構成図である。 無線基地局装置で実行される制御フロー図である。

図２は、実施形態の手法が適用される移動通信システム１の概略構成図である。移動通信システム１は、無線基地局装置（ｅＮＢ：evolved Node B）１０と、複数の移動局あるいはユーザ装置（ＵＥ：User Equipment）２０−１〜２０−ｎを含む。無線基地局装置１０はコアネットワーク２に接続される。ＵＥ２０−１〜２０−ｎ（適宜、「ＵＥ２０」と総称する。）は、無線基地局装置１０およびコアネットワーク２を介して、インターネット等の外部ネットワーク（不図示）とパケットデータの送受信が可能である。

無線基地局装置１０は、自局が管轄するセル３内の多数のＵＥ２０−１〜２０−ｎと接続し、各ＵＥ２０−１〜２０−ｎのデータをバッファし、管理する。

図３は、無線基地局装置１０の概略構成図である。無線基地局装置１０は、無線通信部１１、ＭＡＣ（Medium Access Control）管理部１４、ＲＬＣ／ＰＤＣＰ（Radio Link Control/Packet Data Convergence Protocol）管理部１５、及び通信部１９を有する。無線通信部１１は、下りリンク（ＤＬ）信号送信部１２と、上りリンク（ＵＬ）信号受信部１３を含む。ＭＡＣ管理部１４は、ハイブリッド自動再送制御（ＨＡＲＱ：Hybrid Automatic Repeat Request）、スケジューリング、信号の多重及び分離、ランダムアクセス制御など、ＭＡＣ層の信号の送受信を制御する。

ＲＬＣ／ＰＤＣＰ管理部１５は、バッファ１７を管理するバッファ管理部１６と、メトリック算出部１８を含む。バッファ１７は、たとえば複数のＵＥ２０−１〜２０−ｎの間で共有されるレイヤ２のＲＬＣ／ＰＤＣＰバッファであり、ＵＥ２０−１１〜２０−ｎに送信されるデータを一時的に蓄える。バッファ１６は、複数ユーザ間で共有される任意のバッファであり、ＲＬＣ機能とＰＤＣＰ機能で別々にユーザデータを一時格納するバッファであってもよい。

バッファ管理部１６は、バッファ１７の空き容量が閾値よりも小さくなった時点で、バッファデータ破棄制御を行うことを決定し、メトリック算出部１８に、ＵＥ２０−１〜２０−ｎの各々についてメトリックを算出するように指示する。

メトリックとは、個別のＵＥ２０について、実際にそのＵＥ２０に送信可能なデータ量（帯域遅延積）に対してどれだけ不当にバッファが占有されているかを示す値である。メトリックが大きいほど、バッファ１７を不当に占有していることになる。バッファ管理部１６は、帯域遅延積から計算されるメトリックに基づいて、どのＵＥ２０のデータから破棄すべきかを決定し、バッファ１７に所定の空き容量が確保されるようにバッファ１７内に滞留するデータを破棄する。

ＲＬＣ／ＰＤＣＰ管理部１５の動作について、より詳細に説明する。ＲＬＣ／ＰＤＣＰ管理部１５の動作は、以下のステップを含む。

ステップ１：各ＵＥ２０に対して、あらかじめ平均バッファ滞留量と、平均ＲＬＣ流出レートを算出しておく。

ステップ２：バッファ空き容量が閾値よりも小さくなったことを検出し、バッファデータ破棄制御の開始を決定する。

ステップ３：バッファデータ破棄制御の開始に応じて、各ＵＥ２０のメトリックを算出する。

ステップ４：メトリックの大きいユーザから、バッファの空き容量が閾値以上になるまでバッファ１７に滞留データを破棄する。

各ステップについて説明する。
＜ステップ１＞平均バッファ滞留量と平均ＲＬＣ流出レートの算出
メトリック算出部１８は、各ＵＥ２０に対して、平均バッファ滞留量と平均ＲＬＣ流出量を算出しておく。平均バッファ滞留量と平均ＲＬＣ流出量は、メトリックの算出に用いられるパラメータである。

第ｎ番目のユーザ装置（ＵＥ＃ｎ）の時点ｉにおける平均バッファ滞留量Buffer_ave,n[i]はたとえば、式（１）で計算される。

ここで、Buffer_n[i]は、ＵＥ＃ｎの時点ｉにおけるバッファ滞留量であり、初期値は０である。δ_bufferは忘却係数であり、固定値を用いる。式（１）による計算以外に、時間平均をとるなど、任意の平均計算を用いてもよい。なお、ＲＬＣ層での送信処理が始まっているＰＤＣＰ ＳＤＵ（Service Data Unit）、すなわちＰＤＣＰ ＳＤＵの一部でもトランスポートブロックにマッピングされているデータは、平均バッファ滞留量の計算から除くこととする（或いは、トランスポートブロックにマッピング済みのbyte segmentのみを除いても良い）。

平均バッファ滞留量は、バッファ１７内にデータが滞留しているか否かにかかわらず更新してもよい。あるいは計算処理量を低減するために、バッファ１７内に所定の閾値を超えて滞留するデータがゼロの区間は更新せずに、滞留データが発生した時点で、滞留データがゼロであった区間を考慮して（忘却係数δを調整するなどして）更新を行なってもよい。

ＲＬＣ再送ＰＤＵ（Protocol Data Unit）やＨＡＲＱ再送ＰＤＵなどの再送データや、下りリンクＲＬＣ／ＰＤＣＰ制御ＰＤＵは、平均バッファ滞留量の計算に加味されなくてもよい。

第ｎ番目のＵＥ＃ｎの時点ｉにおける平均ＲＬＣ流出レートＲ_ric,n[i]は、たとえば式（２）で計算される。

ここで、Ｎは平均流出レートの更新回数、Ｒ_initialは平均流出レートの初期値、ｒ_ric,n[i]はＵＥ＃ｎの時点ｉにおいてＲＬＣレイヤからＭＡＣレイヤへ送出された下りリンクＲＬＣ／ＰＤＣＰ ＳＤＵの総量［Byte］である。式（２）による計算以外に、時間平均をとるなど任意の平均計算を用いてもよい。

いったんＲＬＣ ＰＤＵ化を行ったがＰＤＣＣＨ（Physical Downlink Control Channel：物理下りリンク制御チャネル）リソース不足等で無線へ送出できない場合であって、ＲＬＣ ＳＤＵから再度ＲＬＣ ＰＤＵを構築するサブフレームが更新タイミングの場合には、再構築対象のＳＤＵは上記の送出データ量に含めなくてもよい。

また、ＲＬＣ再送ＰＤＵやＤＬ ＲＬＣ／ＰＤＣＰ制御ＰＤＵ、ＨＡＲＱ再送ＰＤＵは上記送出データ量に加味されなくてもよい。

δ_RLC,nは忘却係数であり、式（３）で算出される。

すなわち、１−１／Ｎ_RLC,nとδ'_RLCのいずれか小さいほうを忘却係数として用いる。

平均ＲＬＣ流出レートは、ＭＡＣレイヤに通知を行ったＤＬ ＲＬＣ／ＰＤＣＰ ＳＤＵの総和から、ＭＡＣレイヤに対して送出済みのＤＬ ＲＬＣ／ＰＤＣＰ ＳＤＵの総和を差し引いた値が０（ゼロ）より大きいサブフレームで更新される。

いったんＲＬＣ ＰＤＵ化が行なわれたが、ＰＤＣＣＨリソース不足等で無線へ送出できなかったＲＬＣ ＳＤＵについては、ＭＡＣ層に送出済みのＤＬ ＲＬＣ／ＰＤＣＰ ＳＤＵとみなすこととする。

平均バッファ滞留量と平均ＲＬＣ流出レートの計算は、ベストエフォートベアラなど、特定のＬＣＰ（Logical Channel Priority）にマッピングされているＬＣＨ（論理チャネル）に対してのみ行なってもよい。
＜ステップ２＞バッファ空き容量の管理
バッファ管理部１６は、バッファ１７の容量と、バッファ１７に滞留しているデータの合計量との差分を、空き容量として管理する。滞留データの合計量とは、バッファ１７に設定されているすべてのセル、すべてのＵＥ２０のすべてのＳＲＢ／ＤＲＢ（Signaling Radio Bearer/Data Radio Bearer）に関してバッファしているデータの合計量である。

バッファ１７の空き容量の管理は、無線基地局装置１０単位で行なってもよいし、セル単位、ベースバンドカード単位、ＲＬＣ／ＰＤＣＰを管理する機能エンティティ単位などで行なってもよい。

バッファ管理部１６は、バッファ容量と滞留データ量との上記差分が閾値を下回ったときに、滞留データの破棄が必要であると判断する。差分が閾値を下回るか否かの判断はＴＴＩ（Transmission Time Interval）などの単位時間ごとに行なわれてもよいし、任意の周期で行なわれてもよい。用いる閾値は、無線基地局装置１０に接続されるＵＥ２０の数や、設定している論理チャネル（ＬＣＨ），非間欠受信（non-DRX）の比率、機能部単位にバッファ管理を行う場合は機能部で担っているセル数、無線基地局装置１０の処理能力等により、動的に変更されてもよい。
＜ステップ３＞メトリックの算出
差分が閾値を下回ったとき、あるいは適切なタイミングで、バッファ管理部１６はメトリック算出部１８にメトリックＭ_discardの算出を指示する。メトリックＭ_discardは、式（４）で計算される。

ここで、Ｒ_RLC,minは平均ＲＬＣ流出レートの最小値、Ｔ_discardは遅延パラメータである。

式（４）の右辺の第２項の

は、第ｎ番目のユーザ装置（ＵＥ＃ｎ）の帯域遅延積に相当する。すなわち、時間Ｔ_discardの期間にこのＵＥ＃ｎへ送信可能な下りリンクデータ量を表す。この値は、無線基地局１０の処理能力に従って設定されてもよい。尚、時間Ｔ_discardは基地局の処理能力によって決定されてもよい。

メトリックＭ_discardは、ＵＥ＃ｎの平均バッファ滞留量から、帯域遅延積を引き算した値であり、実際にＵＥ＃ｎに送信可能なデータ量（帯域遅延積）に対して、どれだけ不当にバッファデータが滞留しているかを表わす。メトリックが大きいほど、すなわち帯域遅延積が小さいほど、バッファ１６を不当に占有していることを示す。

メトリックは、ステップ２でバッファ破棄が必要と判定されるか否かにかかわらずに算出されてもよい。処理量削減のために、ＵＥ２０を複数のグループに分割し、優先度の高いグループから順にメトリックを算出してもよい。
＜ステップ４＞滞留データの破棄
バッファ管理部１６は、ステップ３で算出したメトリックが大きい順に、バッファ１７の空き容量が閾値以上となるまでデータを破棄する。バッファデータの破棄では、以下の少なくとも１つを考慮する。
(a) 各ＵＥ２０に対しては、平均バッファ滞留量がバッファ帯域遅延積すなわちｍａｘ（Ｒ_RLC,n[i]，Ｒ_RLC,min）・Ｔ_discardになるまで滞留データを破棄する。すなわち、Ｔ_discardの期間で送信可能なデータ量になるまでデータを破棄し、不当に占有していたバッファ領域を開放させる。
(b) 破棄は、ベストエフォートベアラなど、特定のＬＣＰ（Logical Channel Priority）にマッピングされている論理チャネルに対してのみ行ってもよい。
(c) ＲＬＣ／ＰＤＣＰ ＳＤＵは、ＲＬＣの送信処理が開始されていないもの、すなわちＰＤＣＰ ＳＤＵの一部でもまだトランスポートブロックにマッピングされていないもののみ破棄する。
(d) ＲＬＣ／ＰＤＣＰ ＳＤＵは、最も古いものから破棄する。
(e) ＲＬＣ／ＰＤＣＰ ＳＤＵをＲＬＣ機能部とＰＤＣＰ機能部で二重にバッファする構成を採用する場合、両方のバッファからＲＬＣ／ＰＤＣＰ ＳＤＵを破棄する。
(f) バッファされたデータの全てのＵＥについて破棄を行っても、未だバッファ１７の空き容量が閾値以上にならない場合には、さらにデータを破棄する。その際は、メトリックや帯域遅延積を考慮しなくてもよい。

上述した構成により、破棄すべきでないデータが不当に破棄される事態や、無線レートの小さいユーザのデータばかりがバッファ内に滞留する事態を回避することができる。

図４は、ＰＬＣ／ＰＤＣＰ管理部１５が行う制御フローを示す図である。まず、今回のタイミングで、ユーザ番号を初期値（ｎ＝１）に設定する（Ｓ１０１）。次に、バッファ１７の空き容量を算出する（Ｓ１０２）。バッファの空き容量は、上記ステップ２で説明した方法で計算される。

算出された空き容量が所定の閾値を下回るか否かを判断する（Ｓ１０３）。バッファ１７の空き容量が閾値を下回る場合（Ｓ１０３でＹｅｓ）は、ＵＥ２０ごとにメトリックを計算する（Ｓ１０４）。メトリックは、あらかじめ計算してあった各ユーザの平均バッファ滞留量と平均ＲＬＣ流出レートを用いて、式（４）により算出される。

メトリックの大きい順から、ユーザ装置２０（ＵＥ＃ｋ）のデータ滞留量がそのユーザ装置の帯域遅延積になるまで、滞留データを破棄する（Ｓ１０５）。２番目にメトリックの大きいユーザを選択して、そのユーザ装置２０のデータ滞留量が帯域遅延積になるまで滞留データを破棄する（Ｓ１０６）。ｎが最大ユーザ数を超えない範囲内で（Ｓ１０７）、バッファ１７の空き容量が閾値以上に回復するまで（Ｓ１０３でＮｏ）、滞留データの破棄を続ける。

バッファ１７の空き容量が閾値以上になった場合は、バッファデータ破棄制御を終了する。バッファ１７内にデータが滞留する全てのユーザについてバッファデータ破棄が行われた場合（Ｓ１０７でＹｅｓ）は、その時点でバッファ１７の空き容量がまだ閾値を下回っているか否かを判断する（Ｓ１０８）。空き容量が閾値以上であれば（Ｓ１０８でＮｏ）バッファデータ破棄制御を終了する。空き容量が閾値を下回っている場合は（Ｓ１０８でＹｅｓ）、各ＵＥ２０のメトリックに関係なく、空き容量が閾値以上になるまで滞留するデータを破棄する（Ｓ１０９）。この場合の破棄は、たとえば古いデータから順に破棄してもよい。その後、今回のタイミングでのデータ破棄制御を終了し、次の制御タイミングで同じフローを繰り返す。

この方法により、無線レート（帯域遅延積）の小さいユーザから順に滞留データが破棄されるので、破棄すべきでないユーザのデータが不当に破棄される事態を回避することができる。

上述した実施例では、バッファ１７の空き容量が所定の閾値を下回るか否かで、データの過剰な滞留を検出したが、バッファ１７に格納されているデータの総量が所定の閾値を超えるか否かによってデータの過剰な滞留を検出してもよい。バッファ１７内に滞留するデータ量がバッファ１７の許容量を満たすか否かが判断できればよいので、任意の基準を設定することができる。

また、上記の実施例では、各ＵＥの帯域遅延積を反映する値としてメトリック（そのＵＥの帯域遅延積を超える不当なバッファ占有量）を、平均バッファ滞留量と帯域遅延積の差分として算出したが、各ＵＥの現在のバッファ占有率とそのＵＥの帯域遅延積とからメトリックを計算してもよい。メトリックは、各ＵＥの帯域遅延積との関係で破棄すべきデータ量がわかる値であれば、任意の値を用いることができる。

１ 無線通信システム
１０ 無線基地局装置
１１ 無線通信部
１４ ＭＡＣ管理部
１５ ＲＬＣ／ＰＤＣＰ管理部
１６ バファ管理部
１７ バッファ
１８ メトリック算出部

Claims (8)

1. 複数のユーザで共有されるバッファと、
   前記バッファ内に蓄積される総データ量または空き容量を監視し、前記総データ量または前記空き容量が所定の条件を満たさなくなったときにデータ破棄制御を開始するバッファ管理部と、
   前記データ破棄制御の開始に応じて、前記ユーザごとに、当該ユーザの帯域遅延積に基づいて破棄すべきデータ量を表すメトリックを算出するメトリック算出部と、
   を有し、
   前記メトリック算出部は、各ユーザの平均バッファ滞留量を計算し、前記平均バッファ滞留量と前記帯域遅延積との差分を前記メトリックとして算出し、
   前記バッファ管理部は、前記算出されたメトリックに基づいて、前記バッファ内のデータを前記所定の条件が満たされるまで破棄する
   を前記所定の条件が満たされるまで破棄することを特徴とする無線基地局装置。
2. 前記バッファ管理部は、前記メトリックが大きいユーザから順に、前記バッファ内にある当該ユーザのデータが前記帯域遅延積になるまで破棄することを特徴とする請求項１に記載の無線基地局装置。
3. 前記バッファ管理部は、前記複数のユーザを優先度に応じたグループに分割し、前記優先度の高いグループから順に前記メトリックを算出することを特徴とする請求項１に記載の無線基地局装置。
4. 前記バッファ管理部は、前記バッファを共有する前記複数のユーザのすべてに対して前記データ破棄制御を実施しても前記所定の条件が満たされない場合に、前記メトリックとかかわりなく前記所定の条件が満たされるまで追加のデータ破棄を実施することを特徴とする請求項１に記載の無線基地局装置。
5. 複数のユーザで共有されるバッファを有する無線基地局で行われるバッファ制御方法であって、
   前記無線基地局にて、前記バッファに蓄積される総データ量または空き容量を監視し、
   前記総データ量または前記空き容量が所定の条件を満たさなくなったときにデータ破棄制御を開始し、
   前記データ破棄制御の開始に応じて、前記ユーザごとに、当該ユーザの帯域遅延積に基づき破棄すべきデータ量を表すメトリックを算出し、
   前記算出されたメトリックに基づいて、前記バッファ内のデータを前記所定の条件が満たされるまで破棄し、
   前記メトリックの算出は、前記各ユーザの平均バッファ滞留量を計算し、前記平均バッファ滞留量と前記帯域遅延積との差分を前記メトリックとして算出することを特徴とする
   バッファ制御方法。
6. 前記データの破棄は、前記メトリックが大きいユーザから順に、当該ユーザのデータが当該ユーザの前記帯域遅延積になるまで破棄することを特徴とする請求項５に記載のバッファ制御方法。
7. 前記メトリックの算出は、前記複数のユーザを優先度に応じたグループに分割し、前記優先度の高いグループから順に前記メトリックを算出することを特徴とする請求項５に記載のバッファ制御方法。
8. 前記バッファを共有する前記複数のユーザのすべてに対して前記データ破棄制御を実施しても前記所定の条件が満たされない場合は、前記メトリックにかかわりなく前記所定の条件が満たされるまで追加のデータ破棄を行う工程をさらに含むことを特徴とする請求項５に記載のバッファ制御方法。

Images