基地局及び通信制御方法
【課題】下り無線リンクの品質が良好の場合でも移動局が備えるレイヤ２バッファのオーバーフローを確実に防止し得る基地局及び通信制御方法を提供する。
【解決手段】基地局100は、移動局200Aに送信済みであるが送達確認を受信していない下りリンクデータ、及び基地局100が移動局200Aに送信した上りリンクデータの送達確認後に移動局200Aが基地局100に送信したと推定される上りリンクデータの和に基づいて、移動局200Aに備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファ滞留データ量を推定する。基地局100は、推定した滞留データ量が所定の閾値を超える場合、移動局200Aに送信される下りリンクデータ及び移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止する。
【解決手段】基地局100は、移動局200Aに送信済みであるが送達確認を受信していない下りリンクデータ、及び基地局100が移動局200Aに送信した上りリンクデータの送達確認後に移動局200Aが基地局100に送信したと推定される上りリンクデータの和に基づいて、移動局200Aに備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファ滞留データ量を推定する。基地局100は、推定した滞留データ量が所定の閾値を超える場合、移動局200Aに送信される下りリンクデータ及び移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動局に送信されるデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファを備える基地局及び通信制御方法に関する。
【背景技術】
【０００２】
3rd Generation Partnership Project（3GPP）において標準化されているLong Term Evolution（LTE）では、移動局（UE）に送信されるデータ（IPパケット）を一時的に蓄えるレイヤ２レベル（RLC/PDCP）のバッファ（以下、レイヤ２バッファ）が基地局（eNB）に設けられている。レイヤ２バッファに蓄えられたデータは、移動局に送信され、移動局が当該データを正常に受信したことをRLCレイヤにおけるACKにより確認した後、破棄される。
【０００３】
レイヤ２バッファは、基地局が形成するセルに在圏する複数の移動局で共有される。また、移動局にも、基地局から送信された下りリンク（DL）データ及び基地局に送信する上りリンク（UL）データを一時的に蓄える1つまたは複数の無線アクセスベアラで共通のレイヤ２バッファが設けられている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】3GPP TS 36.300 V10.3.0, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 10)、２０１１年３月
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した従来のレイヤ２バッファの制御方法には、次のような問題があった。すなわち、基地局と移動局との上りリンク及び下りリンクの品質が良好の場合には、実効的な通信速度が上昇するため、短時間に大量のデータが移動局に到達（或いは大量の上り送信データが滞留）し、移動局が備えるレイヤ２バッファのオーバーフローが発生し易くなる。
【０００６】
そこで、本発明は、このような状況に鑑みてなされたものであり、上りリンク及び下りリンクの品質が良好の場合でも移動局が備えるレイヤ２バッファのオーバーフローを確実に防止し得る基地局及び通信制御方法の提供を目的とする。
【課題を解決するための手段】
【０００７】
本発明の第１の特徴は、移動局（移動局200A, 200B）に送信される下りリンクデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファ（レイヤ２バッファ101）を備える基地局（基地局100）であって、前記レイヤ２バッファに蓄えられたデータを下り方向における無線リソースにスケジューリングするスケジューリング処理部（スケジューリング処理部107）と、前記移動局に備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファ（レイヤ２バッファ210）に滞留する滞留データ量を推定するバッファ滞留量推定部（UEバッファ滞留量推定部105）とを備え、前記バッファ滞留量推定部は、前記移動局に送信済みであるが送達確認を受信していない下りリンクデータ、及び前記基地局が前記移動局に送信した上りリンクデータの送達確認後に前記移動局が前記基地局に送信したと推定される上りリンクデータの和に基づいて、前記滞留データ量を推定し、前記スケジューリング処理部は、前記バッファ滞留量推定部によって推定された前記滞留データ量が所定の閾値を超える場合、前記移動局に送信される下りリンクデータ及び前記移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止することを要旨とする。
【０００８】
本発明の第２の特徴は、移動局に送信されるデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファを備える通信装置を用いた通信制御方法であって、 前記レイヤ２バッファに蓄えられたデータを下り方向における無線リソースにスケジューリングするステップと、前記移動局に備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファに滞留する滞留データ量を推定するステップとを有し、前記滞留データ量を推定するステップでは、前記移動局に送信済みであるが送達確認を受信していない下りリンクデータ、及び前記基地局が前記移動局に送信した上りリンクデータの送達確認後に前記移動局が前記基地局に送信したと推定される上りリンクデータの和に基づいて、前記滞留データ量を推定し、前記スケジューリングするステップでは、前記バッファ滞留量推定部によって推定された前記滞留データ量が所定の閾値を超える場合、前記移動局に送信される下りリンクデータ及び前記移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止することを要旨とする。
【発明の効果】
【０００９】
本発明の特徴によれば、下りリンクの品質が良好の場合でも移動局が備えるレイヤ２バッファのオーバーフローを確実に防止し得る基地局及び通信制御方法を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態に係る無線通信システムの全体概略構成図である。
【図２】本発明の実施形態に係る基地局100の機能ブロック構成図である。
【図３】本発明の実施形態に係る基地局100と移動局200Aとによる送信ウィンドウ制御及びTx Window Stallingの説明図である。
【図４】本発明の実施形態に係るレイヤ２バッファ210にデータが格納される様子を示す図である。
【図５】本発明の実施形態に係る移動局200Aと送受信されるデータの基地局100によるスケジューリング動作フローを示す図である。
【発明を実施するための形態】
【００１１】
次に、本発明の実施形態について説明する。なお、以下の図面の記載において、同一または類似の部分には、同一または類似の符号を付している。ただし、図面は模式的なものであり、各寸法の比率などは現実のものとは異なることに留意すべきである。
【００１２】
したがって、具体的な寸法などは以下の説明を参酌して判断すべきものである。また、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることは勿論である。
【００１３】
（１）無線通信システムの全体概略構成
図１は、本実施形態に係る無線通信システムの全体概略構成図である。図１に示すように、本実施形態に係る無線通信システムは、Long Term Evolution（LTE）方式を採用しており、コアネットワーク50、基地局100（eNB）及び移動局200A, 200B（UE）を含む。
【００１４】
基地局100は、コアネットワーク50に接続されている。基地局100は、セルC1を形成し、移動局200A及び200BとLTE方式に従った無線通信を実行する。特に、本実施形態では、基地局100は、移動局（及び移動局200B、以下同）に送信される下りリンクデータを一時的に蓄えるレイヤ２バッファ101を備える。
【００１５】
また、移動局200Aは、基地局100から送信された下りリンクデータ、及び移動局200Aから基地局100に送信される上りリンクデータを一時的に蓄えるレイヤ２バッファ210を備える。本実施形態において、レイヤ２バッファ210は、移動局バッファを備える。
【００１６】
（２）無線通信システムの機能ブロック構成
次に、本実施形態に係る無線通信システムの機能ブロック構成について説明する。具体的には、基地局100の機能ブロック構成について説明する。図２は、基地局100の機能ブロック構成図である。
【００１７】
図２に示すように、基地局100は、レイヤ２バッファ101、UEバッファ滞留量推定部105、スケジューリング処理部107及び無線通信部109を備える。
【００１８】
レイヤ２バッファ101は、基地局100を介して移動局200A, 200Bに送信されるデータを一時的に蓄える。レイヤ２バッファ101は、複数の移動局で共有される第２層レベルのバッファである。
【００１９】
具体的には、レイヤ２バッファ101は、RLC/PDCP SDU（Service Data Unit）を一時的に蓄える。レイヤ２バッファ101（RLC/PDCPバッファ）は、複数の移動局（ユーザ）及び無線アクセスベアラによって共有される。レイヤ２バッファ101は、基地局100が形成するセル毎に用意される。
【００２０】
UEバッファ滞留量推定部105は、移動局200Aに備えられるレイヤ２バッファ210に滞留する滞留データ量を推定する。具体的には、UEバッファ滞留量推定部105は、移動局200Aに送信済みであるが送達確認（ACK）を受信していない下りリンクデータ、及び基地局100が移動局200Aに送信した上りリンクデータの送達確認後に移動局200Aが基地局100に送信したと推定される上りリンクデータの和に基づいて、滞留データ量を推定する。
【００２１】
以下、UEバッファ滞留量推定部105によるレイヤ２バッファ210の滞留データ量の推定方法について、さらに詳細に説明する。UEバッファ滞留量推定部105は、以下のデータの加算値に基づいて、レイヤ２バッファ210の滞留データ量（Estimated_UE_L2_buffered_data）を推定する。なお、レイヤ２バッファ101内に蓄えられている（滞留している）下りリンクデータの移動局（ユーザ）の識別は、SDUに付与されている送達先識別子であるTEID（Tunnel Endpoint Identifier）を確認することによって可能である（3GPP TS29.060参照）。
【００２２】
・基地局100が移動局200Aに送信済み、かつ移動局200AからのRLC ACKを確認できていない下りリンクデータ（DLデータ）
・最後に基地局100がRLC ACKを送信した時点以降、移動局200Aが送信したと想定される上りリンクデータ（ULデータ）
UEバッファ滞留量推定部105は、｛Estimated_UE_L2_buffered_data≧レイヤ２バッファ210のサイズ（Total L2 buffer size）｝を満たす場合、移動局200Aと設定される全論理チャネルに関して新規データがないと見なす。このような動作によって、レイヤ２バッファ210のオーバーフローが発生した、またはオーバーフローが発生すると予測される場合、移動局200Aに対する下りリンクデータ及び上りリンクデータの少なくとも何れかの新規のスケジューリングが停止される。
【００２３】
UEバッファ滞留量推定部105は、RLC-AM（Acknowledged Mode）が適用される無線アクセスベアラを介して送信された下り方向のPDUの平均サイズと、送信したPDUの数とに基づいて、下りリンクデータ量を推定する。同様に、UEバッファ滞留量推定部105は、RLC-AMが適用される無線アクセスベアラを介して移動局から送信された上り方向のPDUの平均サイズと、受信したPDUの数とに基づいて、上りリンクデータ量を推定する。
【００２４】
具体的には、UEバッファ滞留量推定部105は、基地局100が送信済み、かつ移動局200AからのRLC ACKを確認できていない下りリンクデータのうち、RLC-AMが適用されるベアラを介して送信される下りリンクデータを、次の数式を用いて算出する。
【数１】
【００２５】
ここで、SizeDL_PDU_averageは、平均のDL RLC PDUサイズであり、送信した全てのDL RLC PDUサイズの平均値、及び移動局200AからのRLC ACKを確認できていないDL RLC PDUにおける平均RLC PDUサイズから求めることができる。NDL_PDUは、移動局200AからのRLC ACKを確認できていないDL RLC PDUの数である。
【００２６】
また、最後に基地局100がRLC ACKを送信した時点以降、移動局200Aが送信したと想定される上りリンクデータのうち、RLC-AMが適用されるベアラを介して送信される上りリンクデータを、次の数式を用いて算出する。
【数２】
【００２７】
ここで、SizeUL_PDU_averageは、平均のUL RLC PDUサイズであり、基地局100が受信した全てのUL RLC PDUサイズの平均値、及び最後に基地局100がRLC ACKを送信した時点以降、移動局200Aが送信したと想定されるUL RLC PDUの平均RLC PDUサイズから求めることができる。NUL_PDUは、最後に基地局100がRLC ACKを送信した時点以降、移動局200Aが送信したと想定されるUL RLC PDUの数である。
【００２８】
また、UEバッファ滞留量推定部105は、RLC-UM（Unacknowledged Mode）が適用される無線アクセスベアラを介して送信された下りリンクデータ量（追加下りリンクデータ量）を、上述した数式により算出したRLC-AMが適用される無線アクセスベアラを介して送信される下りリンクデータ量に加算してもよい。同様に、UEバッファ滞留量推定部105は、RLC-UMが適用される無線アクセスベアラを介して移動局200Aから受信した上りリンクデータ量（追加上りリンクデータ量）を上述した数式により算出したRLC-AMが適用される無線アクセスベアラを介して受信した上りリンクデータ量に加算してもよい。
【００２９】
なお、移動局200AのRLC-AMが適用される無線アクセスベアラを介して受信した上りリンクデータ量を推定する場合、UEバッファ滞留量推定部105は、ある時点で移動局200Aが実際にどれくらいの上りリンクデータを送信しているのか（どれくらいの上りリンクデータが移動局200AにおいてACK確認待ちとなっているか）を正確に把握することはできない。そこで、UEバッファ滞留量推定部105は、推定する時点において基地局100が受信済みであるRLC PDUのシーケンスナンバー（SN）から推定する。RLCレイヤの受信側では、受信状況を状態変数にて管理しているため、UEバッファ滞留量推定部105Ｊは、当該状態変数のうち、所定の変数を用いて、移動局200Aが送信済み（ACK確認待ち）の上りリンクデータ量を推定する。
【００３０】
具体的には、UEバッファ滞留量推定部105は、以下の数式により、上りリンクにおける滞留データ量を推定する。
【００３１】
UL滞留データ量＝SizeUL_PDU_average×（VR(H)−Last_ACKed）
ここで、Last_ACKedは、最後にACKを報告したRLC PDUのSNである。VR(H)は、受信したRLC PDUのSNのうち、最大値に+1を加算したものである。また、NUL_PDU=VR(H)−Last_Ackedと表すことができるため、SizeUL_PDU_averageは、次の数式によって求めることができる。
【数３】
【００３２】
また、UEバッファ滞留量推定部105は、Last_ACKedを、以下ように更新することできる。
【００３３】
・無線アクセスベアラの確立時：０（零）に設定
・Status report送信時
・・Status reportにNACKが含まれない場合：報告したACK_SNに設定
・・Status reportにNACKが含まれる場合：最初のNACK_SNに設定
ここで、Status reportにおいて受信できていないRLC PDUのSNをNACK_SNとして報告する場合には、古い（値が小さい）SNから設定することが好ましい。
【００３４】
また、UEバッファ滞留量推定部105は、SizeUL_PDU_total（受信した上りリンクデータ量）を、以下のように更新することができる。
【００３５】
・無線アクセスベアラの確立時：０（零）に設定
・UL AMD PDUの受信時：
SizeUL_PDU_total＝SizeUL_PDU_total＋（受信したAMD PDUのサイズ）
・Last_Acked更新時：
【数４】
【００３６】
また、UEバッファ滞留量推定部105は、RLC-UMが適用される無線アクセスベアラを介して移動局200Aから受信した上りリンクデータ量（追加上りリンクデータ量）、例えば、音声パケット）に関しては、RLCレイヤにおける受信側からのStatus report（送達確認）が送信されないため、所定のデータ量が常に滞留していると見なして、滞留データ量を推定する。
【００３７】
例えば、UEバッファ滞留量推定部105は、RLC-UMが適用される全ての無線アクセスベアラに対して、次のデータ量が一律に各移動局（UE）のレイヤ２バッファ210に滞留していると見なす。
【００３８】
第１に、UEにおいて送信中のRLC-PDUの総データサイズ（UM_transmit_buffer_size）である。UM_transmit_buffer_sizeは、各移動局が並行して送信することのできる音声パケット数と音声パケットサイズとの積によって求められる。第２に、各移動局において順序制御待ちのRLC-PDUの総データサイズ（UM_reordering_buffer_size）である。UM_reordering_buffer_sizeは、各移動局が並行して受信すると想定される音声パケット数と音声パケットサイズとの積によって求められる。
【００３９】
スケジューリング処理部107は、レイヤ２バッファ101に蓄えられた下りリンクデータを下り方向における無線リソースにスケジューリングする。具体的には、スケジューリング処理部107は、UEバッファ滞留量推定部105によって推定された移動局200Aのレイヤ２バッファ210に滞留する滞留データ量が所定の閾値を超える場合、移動局200Aに送信される下りリンクデータのスケジューリングを停止する。また、スケジューリング処理部107は、当該滞留データ量が所定の閾値を超える場合、移動局200Aから送信される上りリンクデータのスケジューリングを停止することもできる。
【００４０】
また、スケジューリング処理部107は、スケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、ハイブリッドARQに従った再送データである場合、当該下りリンクデータまたは当該上りリンクデータを無線リソースにスケジューリングすることができる。
【００４１】
或いは、スケジューリング処理部107は、スケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、RLCレイヤにおける再送データである場合、同様に、当該下りリンクデータまたは当該上りリンクデータを無線リソースにスケジューリングする。つまり、スケジューリング処理部107は、ハブリッドARQによる再送、またはRLCレイヤにおける再送データに関しては、無線リソースへのスケジューリングを停止しなくてもよい。
【００４２】
無線通信部109は、移動局200AとLTE方式に従った無線通信を実行する。特に、本実施形態では、無線通信部109は、レイヤ２バッファ101から出力された下りリンクデータ（PDU）を、スケジューリング処理部107によって指定された無線リソースを用いて移動局200Aに向けて送信する。
【００４３】
また、無線通信部109は、移動局200Aから送信された無線信号を受信し、復調やデコードの処理を実行することによって、上りリンクデータ（PDU）を出力する。
【００４４】
（３）無線通信システムの動作
次に、本実施形態に係る無線通信システムの動作について説明する。具体的には、移動局200Aと送受信されるデータの基地局100によるスケジューリング動作について説明する。
【００４５】
（３．１）送信ウィンドウ制御
まず、本実施形態において前提となる送信側（例えば、基地局100）と受信側（例えば、移動局200A）とにおける送信ウィンドウ制御及びTx Window Stallingについて説明する。
【００４６】
図３は、基地局100と移動局200Aとによる送信ウィンドウ制御及びTx Window Stallingの説明図である。図３に示すように、本実施形態では、受信側の移動局200Aが基地局100にStatus reportを送信することによって、ACKが確認されていないPDUを再送したり、重複して受信したPDUを破棄したりしながら、順次Tx Window 310をスライドさせる。同様に、Rx Window 320もPDUの受信に応じて順次スライドされる。
【００４７】
ここで、図３に示すように、移動局200AからのStatus reportが基地局100で受信できず、Tx Window 310を更新できないと、基地局100は、移動局200Aに新規のPDUを送信することができなくなり、スループットが低下する。Tx Window Stallingを回避するためには、Status reportを適正な頻度で基地局100にフィードバックする必要がある。
【００４８】
基地局100のRLCレイヤは、Tx Window 310を管理し、Tx Window Stallingが発生した場合には、当該無線アクセスベアラを介した新たな下りリンクデータのスケジューリングを停止している。
【００４９】
本実施形態では、移動局200Aのレイヤ２バッファ210（RLC/PDCPバッファ）のオーバーフローが発生した際に、Tx Window Stallingが発生していると見なし、下りリンクデータ及び上りリンクデータの新規スケジューリングを停止する。なお、上りリンクデータの新規スケジューリングは、必ずしも停止しなくても構わない。
【００５０】
ここで、図４は、レイヤ２バッファ210にデータが格納される様子を示す図である。図４に示すように、レイヤ２バッファ210の容量は有限であり、オーバーフローが発生すると、オーバーフローが発生した以降に到来したデータ（PDU）は破棄される。レイヤ２バッファ210に蓄えられるデータは、次の２種類である。
【００５１】
・順序制御（reordering）待ちの下りリンクデータ（DLデータ）
・基地局100からのRLC ACKを確認していない上りリンクデータ（ULデータ）
特に、平均のトランスポートブロックサイズ（1TTIで送信するビット数）が大きい場合に、このようなオーバーフローが発生し易い。
【００５２】
本実施形態に係る基地局100は、上述したようにレイヤ２バッファ210に滞留する滞留データ量を推定し、滞留データ量が所定の閾値を超える場合、Tx Window Stallingが発生していると見なし、下りリンクデータ及び上りリンクデータの新規スケジューリングを停止する。
【００５３】
（３．２）基地局100の動作フロー
図５は、移動局200Aと送受信されるデータの基地局100によるスケジューリング動作フローを示す。
【００５４】
図５に示すように、基地局100は、下りリンクデータの送信、または上りリンクデータの受信に伴う処理を実行（S10）し、移動局200A（UE）のレイヤ２バッファ210に滞留すると推定されるデータ量（滞留データ量）を算出する（S20）。
【００５５】
次いで、基地局100は、算出した滞留データ量に基づいて、レイヤ２バッファ210のオーバーフローが発生するか否かを推定する（S30）。具体的には、基地局100は、レイヤ２バッファ210のオーバーフローが発生すると推定されたことに伴うTx Window Stalling（L2 buffer based Tx Window Stallingという）が発生したか否かを判定する。
【００５６】
L2 buffer based Tx Window Stallingが発生した場合、基地局100は、新規の上りリンクデータの割り当てを停止する（S40）。また、L2 buffer based Tx Window Stallingが発生した場合、基地局100は、新規の下りリンクデータの送信も停止する（S60）。
【００５７】
一方、L2 buffer based Tx Window Stallingが発生していない場合、基地局100は、通常のTx Window Stalling（Window based Tx Window Stallingという）が発生したか否かを判定する（S50）。なお、Window based Tx Window Stallingとは、上述したように、移動局200AからのStatus reportを基地局100で受信できないため、Tx Window 310が更新できない状態（図３参照）である。Window based Tx Window Stallingが発生した場合、基地局100は、新規の下りリンクデータの送信を停止する（S60）。
【００５８】
なお、図５に示したフローにおいて、L2 buffer based Tx Window Stallingの判定（S30）と、Window based Tx Window Stallingの判定（S50）とは、前後してもよい。
【００５９】
（４）作用・効果
基地局100によれば、移動局200Aに送信済みであるが送達確認を受信していない下りリンクデータ、及び基地局100が移動局200Aに送信した上りリンクデータの送達確認後に移動局200Aが基地局100に送信したと推定される上りリンクデータの和に基づいて滞留データ量を推定する。さらに、推定した滞留データ量が所定の閾値を超える場合、基地局100は、移動局200Aに送信される下りリンクデータ及び移動局200Aから送信される上りリンクデータのスケジューリングを停止する。
【００６０】
このため、移動局200Aのレイヤ２バッファ210のオーバーフローが発生すると予測される場合でも、当該下りリンクデータ及び当該上りリンクデータのスケジューリングが停止されるため、レイヤ２バッファ210のオーバーフローを確実に防止し得る。特に、基地局100と移動局200Aとの上りリンク及び下りリンクの品質が良好の場合において、実効的な通信速度の上昇によって短時間に大量のデータが移動局200Aに到達するような場合でも、レイヤ２バッファ210のオーバーフローを確実に防止し得る。
【００６１】
本実施形態では、RLC-AMが適用される無線アクセスベアラを介して送信されたデータに基づいて下りリンクデータ量及び上りリンクデータ量を推定しているが、RLC-UMが適用される無線アクセスベアラを介して送信されたデータを当該下りリンクデータ量及び当該上りリンクデータ量に加算することもできる。このため、より正確にレイヤ２バッファ210における滞留データ量を推定できる。
【００６２】
本実施形態では、スケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、ハイブリッドARQに従った再送データである場合、或いはスケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、RLCレイヤにおける再送データである場合、当該下りリンクデータまたは当該上りリンクデータを無線リソースにスケジューリングする、つまり、スケジューリングの停止の対象から除外される。このため、スケジューリングの停止による影響が大きいデータは速やかに送信されるため、スループットの低下などを効果的に抑制し得る。
【００６３】
（５）その他の実施形態
上述したように、本発明の一実施形態を通じて本発明の内容を開示したが、この開示の一部をなす論述及び図面は、本発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態が明らかとなろう。
【００６４】
例えば、上述した実施形態では、既存のTx Window Stalling発生時におけるデータのスケジューリング停止の機能を活用することによって、レイヤ２バッファ210のオーバーフローが発生すると推定された場合に、下りリンクデータまたは上りリンクデータの割り当てや送信を停止していたが、必ずしもこのようなTx Window Stalling発生時におけるデータのスケジューリング停止の機能を活用する必要はなく、別個独立の機能として、データのスケジューリング停止を実行するようにしてもよい。
【００６５】
このように、本発明は、ここでは記載していない様々な実施の形態などを含むことは勿論である。したがって、本発明の技術的範囲は、上述の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【符号の説明】
【００６６】
50…コアネットワーク
100…基地局
101…レイヤ２バッファ
105…UEバッファ滞留量推定部
107…スケジューリング処理部
109…無線通信部
200A, 200B…移動局
210…レイヤ２バッファ
310…Tx Window
320…Rx Window
C1…セル
【技術分野】
【０００１】
本発明は、移動局に送信されるデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファを備える基地局及び通信制御方法に関する。
【背景技術】
【０００２】
3rd Generation Partnership Project（3GPP）において標準化されているLong Term Evolution（LTE）では、移動局（UE）に送信されるデータ（IPパケット）を一時的に蓄えるレイヤ２レベル（RLC/PDCP）のバッファ（以下、レイヤ２バッファ）が基地局（eNB）に設けられている。レイヤ２バッファに蓄えられたデータは、移動局に送信され、移動局が当該データを正常に受信したことをRLCレイヤにおけるACKにより確認した後、破棄される。
【０００３】
レイヤ２バッファは、基地局が形成するセルに在圏する複数の移動局で共有される。また、移動局にも、基地局から送信された下りリンク（DL）データ及び基地局に送信する上りリンク（UL）データを一時的に蓄える1つまたは複数の無線アクセスベアラで共通のレイヤ２バッファが設けられている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】3GPP TS 36.300 V10.3.0, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 10)、２０１１年３月
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した従来のレイヤ２バッファの制御方法には、次のような問題があった。すなわち、基地局と移動局との上りリンク及び下りリンクの品質が良好の場合には、実効的な通信速度が上昇するため、短時間に大量のデータが移動局に到達（或いは大量の上り送信データが滞留）し、移動局が備えるレイヤ２バッファのオーバーフローが発生し易くなる。
【０００６】
そこで、本発明は、このような状況に鑑みてなされたものであり、上りリンク及び下りリンクの品質が良好の場合でも移動局が備えるレイヤ２バッファのオーバーフローを確実に防止し得る基地局及び通信制御方法の提供を目的とする。
【課題を解決するための手段】
【０００７】
本発明の第１の特徴は、移動局（移動局200A, 200B）に送信される下りリンクデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファ（レイヤ２バッファ101）を備える基地局（基地局100）であって、前記レイヤ２バッファに蓄えられたデータを下り方向における無線リソースにスケジューリングするスケジューリング処理部（スケジューリング処理部107）と、前記移動局に備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファ（レイヤ２バッファ210）に滞留する滞留データ量を推定するバッファ滞留量推定部（UEバッファ滞留量推定部105）とを備え、前記バッファ滞留量推定部は、前記移動局に送信済みであるが送達確認を受信していない下りリンクデータ、及び前記基地局が前記移動局に送信した上りリンクデータの送達確認後に前記移動局が前記基地局に送信したと推定される上りリンクデータの和に基づいて、前記滞留データ量を推定し、前記スケジューリング処理部は、前記バッファ滞留量推定部によって推定された前記滞留データ量が所定の閾値を超える場合、前記移動局に送信される下りリンクデータ及び前記移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止することを要旨とする。
【０００８】
本発明の第２の特徴は、移動局に送信されるデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファを備える通信装置を用いた通信制御方法であって、 前記レイヤ２バッファに蓄えられたデータを下り方向における無線リソースにスケジューリングするステップと、前記移動局に備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファに滞留する滞留データ量を推定するステップとを有し、前記滞留データ量を推定するステップでは、前記移動局に送信済みであるが送達確認を受信していない下りリンクデータ、及び前記基地局が前記移動局に送信した上りリンクデータの送達確認後に前記移動局が前記基地局に送信したと推定される上りリンクデータの和に基づいて、前記滞留データ量を推定し、前記スケジューリングするステップでは、前記バッファ滞留量推定部によって推定された前記滞留データ量が所定の閾値を超える場合、前記移動局に送信される下りリンクデータ及び前記移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止することを要旨とする。
【発明の効果】
【０００９】
本発明の特徴によれば、下りリンクの品質が良好の場合でも移動局が備えるレイヤ２バッファのオーバーフローを確実に防止し得る基地局及び通信制御方法を提供することができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態に係る無線通信システムの全体概略構成図である。
【図２】本発明の実施形態に係る基地局100の機能ブロック構成図である。
【図３】本発明の実施形態に係る基地局100と移動局200Aとによる送信ウィンドウ制御及びTx Window Stallingの説明図である。
【図４】本発明の実施形態に係るレイヤ２バッファ210にデータが格納される様子を示す図である。
【図５】本発明の実施形態に係る移動局200Aと送受信されるデータの基地局100によるスケジューリング動作フローを示す図である。
【発明を実施するための形態】
【００１１】
次に、本発明の実施形態について説明する。なお、以下の図面の記載において、同一または類似の部分には、同一または類似の符号を付している。ただし、図面は模式的なものであり、各寸法の比率などは現実のものとは異なることに留意すべきである。
【００１２】
したがって、具体的な寸法などは以下の説明を参酌して判断すべきものである。また、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることは勿論である。
【００１３】
（１）無線通信システムの全体概略構成
図１は、本実施形態に係る無線通信システムの全体概略構成図である。図１に示すように、本実施形態に係る無線通信システムは、Long Term Evolution（LTE）方式を採用しており、コアネットワーク50、基地局100（eNB）及び移動局200A, 200B（UE）を含む。
【００１４】
基地局100は、コアネットワーク50に接続されている。基地局100は、セルC1を形成し、移動局200A及び200BとLTE方式に従った無線通信を実行する。特に、本実施形態では、基地局100は、移動局（及び移動局200B、以下同）に送信される下りリンクデータを一時的に蓄えるレイヤ２バッファ101を備える。
【００１５】
また、移動局200Aは、基地局100から送信された下りリンクデータ、及び移動局200Aから基地局100に送信される上りリンクデータを一時的に蓄えるレイヤ２バッファ210を備える。本実施形態において、レイヤ２バッファ210は、移動局バッファを備える。
【００１６】
（２）無線通信システムの機能ブロック構成
次に、本実施形態に係る無線通信システムの機能ブロック構成について説明する。具体的には、基地局100の機能ブロック構成について説明する。図２は、基地局100の機能ブロック構成図である。
【００１７】
図２に示すように、基地局100は、レイヤ２バッファ101、UEバッファ滞留量推定部105、スケジューリング処理部107及び無線通信部109を備える。
【００１８】
レイヤ２バッファ101は、基地局100を介して移動局200A, 200Bに送信されるデータを一時的に蓄える。レイヤ２バッファ101は、複数の移動局で共有される第２層レベルのバッファである。
【００１９】
具体的には、レイヤ２バッファ101は、RLC/PDCP SDU（Service Data Unit）を一時的に蓄える。レイヤ２バッファ101（RLC/PDCPバッファ）は、複数の移動局（ユーザ）及び無線アクセスベアラによって共有される。レイヤ２バッファ101は、基地局100が形成するセル毎に用意される。
【００２０】
UEバッファ滞留量推定部105は、移動局200Aに備えられるレイヤ２バッファ210に滞留する滞留データ量を推定する。具体的には、UEバッファ滞留量推定部105は、移動局200Aに送信済みであるが送達確認（ACK）を受信していない下りリンクデータ、及び基地局100が移動局200Aに送信した上りリンクデータの送達確認後に移動局200Aが基地局100に送信したと推定される上りリンクデータの和に基づいて、滞留データ量を推定する。
【００２１】
以下、UEバッファ滞留量推定部105によるレイヤ２バッファ210の滞留データ量の推定方法について、さらに詳細に説明する。UEバッファ滞留量推定部105は、以下のデータの加算値に基づいて、レイヤ２バッファ210の滞留データ量（Estimated_UE_L2_buffered_data）を推定する。なお、レイヤ２バッファ101内に蓄えられている（滞留している）下りリンクデータの移動局（ユーザ）の識別は、SDUに付与されている送達先識別子であるTEID（Tunnel Endpoint Identifier）を確認することによって可能である（3GPP TS29.060参照）。
【００２２】
・基地局100が移動局200Aに送信済み、かつ移動局200AからのRLC ACKを確認できていない下りリンクデータ（DLデータ）
・最後に基地局100がRLC ACKを送信した時点以降、移動局200Aが送信したと想定される上りリンクデータ（ULデータ）
UEバッファ滞留量推定部105は、｛Estimated_UE_L2_buffered_data≧レイヤ２バッファ210のサイズ（Total L2 buffer size）｝を満たす場合、移動局200Aと設定される全論理チャネルに関して新規データがないと見なす。このような動作によって、レイヤ２バッファ210のオーバーフローが発生した、またはオーバーフローが発生すると予測される場合、移動局200Aに対する下りリンクデータ及び上りリンクデータの少なくとも何れかの新規のスケジューリングが停止される。
【００２３】
UEバッファ滞留量推定部105は、RLC-AM（Acknowledged Mode）が適用される無線アクセスベアラを介して送信された下り方向のPDUの平均サイズと、送信したPDUの数とに基づいて、下りリンクデータ量を推定する。同様に、UEバッファ滞留量推定部105は、RLC-AMが適用される無線アクセスベアラを介して移動局から送信された上り方向のPDUの平均サイズと、受信したPDUの数とに基づいて、上りリンクデータ量を推定する。
【００２４】
具体的には、UEバッファ滞留量推定部105は、基地局100が送信済み、かつ移動局200AからのRLC ACKを確認できていない下りリンクデータのうち、RLC-AMが適用されるベアラを介して送信される下りリンクデータを、次の数式を用いて算出する。
【数１】
【００２５】
ここで、SizeDL_PDU_averageは、平均のDL RLC PDUサイズであり、送信した全てのDL RLC PDUサイズの平均値、及び移動局200AからのRLC ACKを確認できていないDL RLC PDUにおける平均RLC PDUサイズから求めることができる。NDL_PDUは、移動局200AからのRLC ACKを確認できていないDL RLC PDUの数である。
【００２６】
また、最後に基地局100がRLC ACKを送信した時点以降、移動局200Aが送信したと想定される上りリンクデータのうち、RLC-AMが適用されるベアラを介して送信される上りリンクデータを、次の数式を用いて算出する。
【数２】
【００２７】
ここで、SizeUL_PDU_averageは、平均のUL RLC PDUサイズであり、基地局100が受信した全てのUL RLC PDUサイズの平均値、及び最後に基地局100がRLC ACKを送信した時点以降、移動局200Aが送信したと想定されるUL RLC PDUの平均RLC PDUサイズから求めることができる。NUL_PDUは、最後に基地局100がRLC ACKを送信した時点以降、移動局200Aが送信したと想定されるUL RLC PDUの数である。
【００２８】
また、UEバッファ滞留量推定部105は、RLC-UM（Unacknowledged Mode）が適用される無線アクセスベアラを介して送信された下りリンクデータ量（追加下りリンクデータ量）を、上述した数式により算出したRLC-AMが適用される無線アクセスベアラを介して送信される下りリンクデータ量に加算してもよい。同様に、UEバッファ滞留量推定部105は、RLC-UMが適用される無線アクセスベアラを介して移動局200Aから受信した上りリンクデータ量（追加上りリンクデータ量）を上述した数式により算出したRLC-AMが適用される無線アクセスベアラを介して受信した上りリンクデータ量に加算してもよい。
【００２９】
なお、移動局200AのRLC-AMが適用される無線アクセスベアラを介して受信した上りリンクデータ量を推定する場合、UEバッファ滞留量推定部105は、ある時点で移動局200Aが実際にどれくらいの上りリンクデータを送信しているのか（どれくらいの上りリンクデータが移動局200AにおいてACK確認待ちとなっているか）を正確に把握することはできない。そこで、UEバッファ滞留量推定部105は、推定する時点において基地局100が受信済みであるRLC PDUのシーケンスナンバー（SN）から推定する。RLCレイヤの受信側では、受信状況を状態変数にて管理しているため、UEバッファ滞留量推定部105Ｊは、当該状態変数のうち、所定の変数を用いて、移動局200Aが送信済み（ACK確認待ち）の上りリンクデータ量を推定する。
【００３０】
具体的には、UEバッファ滞留量推定部105は、以下の数式により、上りリンクにおける滞留データ量を推定する。
【００３１】
UL滞留データ量＝SizeUL_PDU_average×（VR(H)−Last_ACKed）
ここで、Last_ACKedは、最後にACKを報告したRLC PDUのSNである。VR(H)は、受信したRLC PDUのSNのうち、最大値に+1を加算したものである。また、NUL_PDU=VR(H)−Last_Ackedと表すことができるため、SizeUL_PDU_averageは、次の数式によって求めることができる。
【数３】
【００３２】
また、UEバッファ滞留量推定部105は、Last_ACKedを、以下ように更新することできる。
【００３３】
・無線アクセスベアラの確立時：０（零）に設定
・Status report送信時
・・Status reportにNACKが含まれない場合：報告したACK_SNに設定
・・Status reportにNACKが含まれる場合：最初のNACK_SNに設定
ここで、Status reportにおいて受信できていないRLC PDUのSNをNACK_SNとして報告する場合には、古い（値が小さい）SNから設定することが好ましい。
【００３４】
また、UEバッファ滞留量推定部105は、SizeUL_PDU_total（受信した上りリンクデータ量）を、以下のように更新することができる。
【００３５】
・無線アクセスベアラの確立時：０（零）に設定
・UL AMD PDUの受信時：
SizeUL_PDU_total＝SizeUL_PDU_total＋（受信したAMD PDUのサイズ）
・Last_Acked更新時：
【数４】
【００３６】
また、UEバッファ滞留量推定部105は、RLC-UMが適用される無線アクセスベアラを介して移動局200Aから受信した上りリンクデータ量（追加上りリンクデータ量）、例えば、音声パケット）に関しては、RLCレイヤにおける受信側からのStatus report（送達確認）が送信されないため、所定のデータ量が常に滞留していると見なして、滞留データ量を推定する。
【００３７】
例えば、UEバッファ滞留量推定部105は、RLC-UMが適用される全ての無線アクセスベアラに対して、次のデータ量が一律に各移動局（UE）のレイヤ２バッファ210に滞留していると見なす。
【００３８】
第１に、UEにおいて送信中のRLC-PDUの総データサイズ（UM_transmit_buffer_size）である。UM_transmit_buffer_sizeは、各移動局が並行して送信することのできる音声パケット数と音声パケットサイズとの積によって求められる。第２に、各移動局において順序制御待ちのRLC-PDUの総データサイズ（UM_reordering_buffer_size）である。UM_reordering_buffer_sizeは、各移動局が並行して受信すると想定される音声パケット数と音声パケットサイズとの積によって求められる。
【００３９】
スケジューリング処理部107は、レイヤ２バッファ101に蓄えられた下りリンクデータを下り方向における無線リソースにスケジューリングする。具体的には、スケジューリング処理部107は、UEバッファ滞留量推定部105によって推定された移動局200Aのレイヤ２バッファ210に滞留する滞留データ量が所定の閾値を超える場合、移動局200Aに送信される下りリンクデータのスケジューリングを停止する。また、スケジューリング処理部107は、当該滞留データ量が所定の閾値を超える場合、移動局200Aから送信される上りリンクデータのスケジューリングを停止することもできる。
【００４０】
また、スケジューリング処理部107は、スケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、ハイブリッドARQに従った再送データである場合、当該下りリンクデータまたは当該上りリンクデータを無線リソースにスケジューリングすることができる。
【００４１】
或いは、スケジューリング処理部107は、スケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、RLCレイヤにおける再送データである場合、同様に、当該下りリンクデータまたは当該上りリンクデータを無線リソースにスケジューリングする。つまり、スケジューリング処理部107は、ハブリッドARQによる再送、またはRLCレイヤにおける再送データに関しては、無線リソースへのスケジューリングを停止しなくてもよい。
【００４２】
無線通信部109は、移動局200AとLTE方式に従った無線通信を実行する。特に、本実施形態では、無線通信部109は、レイヤ２バッファ101から出力された下りリンクデータ（PDU）を、スケジューリング処理部107によって指定された無線リソースを用いて移動局200Aに向けて送信する。
【００４３】
また、無線通信部109は、移動局200Aから送信された無線信号を受信し、復調やデコードの処理を実行することによって、上りリンクデータ（PDU）を出力する。
【００４４】
（３）無線通信システムの動作
次に、本実施形態に係る無線通信システムの動作について説明する。具体的には、移動局200Aと送受信されるデータの基地局100によるスケジューリング動作について説明する。
【００４５】
（３．１）送信ウィンドウ制御
まず、本実施形態において前提となる送信側（例えば、基地局100）と受信側（例えば、移動局200A）とにおける送信ウィンドウ制御及びTx Window Stallingについて説明する。
【００４６】
図３は、基地局100と移動局200Aとによる送信ウィンドウ制御及びTx Window Stallingの説明図である。図３に示すように、本実施形態では、受信側の移動局200Aが基地局100にStatus reportを送信することによって、ACKが確認されていないPDUを再送したり、重複して受信したPDUを破棄したりしながら、順次Tx Window 310をスライドさせる。同様に、Rx Window 320もPDUの受信に応じて順次スライドされる。
【００４７】
ここで、図３に示すように、移動局200AからのStatus reportが基地局100で受信できず、Tx Window 310を更新できないと、基地局100は、移動局200Aに新規のPDUを送信することができなくなり、スループットが低下する。Tx Window Stallingを回避するためには、Status reportを適正な頻度で基地局100にフィードバックする必要がある。
【００４８】
基地局100のRLCレイヤは、Tx Window 310を管理し、Tx Window Stallingが発生した場合には、当該無線アクセスベアラを介した新たな下りリンクデータのスケジューリングを停止している。
【００４９】
本実施形態では、移動局200Aのレイヤ２バッファ210（RLC/PDCPバッファ）のオーバーフローが発生した際に、Tx Window Stallingが発生していると見なし、下りリンクデータ及び上りリンクデータの新規スケジューリングを停止する。なお、上りリンクデータの新規スケジューリングは、必ずしも停止しなくても構わない。
【００５０】
ここで、図４は、レイヤ２バッファ210にデータが格納される様子を示す図である。図４に示すように、レイヤ２バッファ210の容量は有限であり、オーバーフローが発生すると、オーバーフローが発生した以降に到来したデータ（PDU）は破棄される。レイヤ２バッファ210に蓄えられるデータは、次の２種類である。
【００５１】
・順序制御（reordering）待ちの下りリンクデータ（DLデータ）
・基地局100からのRLC ACKを確認していない上りリンクデータ（ULデータ）
特に、平均のトランスポートブロックサイズ（1TTIで送信するビット数）が大きい場合に、このようなオーバーフローが発生し易い。
【００５２】
本実施形態に係る基地局100は、上述したようにレイヤ２バッファ210に滞留する滞留データ量を推定し、滞留データ量が所定の閾値を超える場合、Tx Window Stallingが発生していると見なし、下りリンクデータ及び上りリンクデータの新規スケジューリングを停止する。
【００５３】
（３．２）基地局100の動作フロー
図５は、移動局200Aと送受信されるデータの基地局100によるスケジューリング動作フローを示す。
【００５４】
図５に示すように、基地局100は、下りリンクデータの送信、または上りリンクデータの受信に伴う処理を実行（S10）し、移動局200A（UE）のレイヤ２バッファ210に滞留すると推定されるデータ量（滞留データ量）を算出する（S20）。
【００５５】
次いで、基地局100は、算出した滞留データ量に基づいて、レイヤ２バッファ210のオーバーフローが発生するか否かを推定する（S30）。具体的には、基地局100は、レイヤ２バッファ210のオーバーフローが発生すると推定されたことに伴うTx Window Stalling（L2 buffer based Tx Window Stallingという）が発生したか否かを判定する。
【００５６】
L2 buffer based Tx Window Stallingが発生した場合、基地局100は、新規の上りリンクデータの割り当てを停止する（S40）。また、L2 buffer based Tx Window Stallingが発生した場合、基地局100は、新規の下りリンクデータの送信も停止する（S60）。
【００５７】
一方、L2 buffer based Tx Window Stallingが発生していない場合、基地局100は、通常のTx Window Stalling（Window based Tx Window Stallingという）が発生したか否かを判定する（S50）。なお、Window based Tx Window Stallingとは、上述したように、移動局200AからのStatus reportを基地局100で受信できないため、Tx Window 310が更新できない状態（図３参照）である。Window based Tx Window Stallingが発生した場合、基地局100は、新規の下りリンクデータの送信を停止する（S60）。
【００５８】
なお、図５に示したフローにおいて、L2 buffer based Tx Window Stallingの判定（S30）と、Window based Tx Window Stallingの判定（S50）とは、前後してもよい。
【００５９】
（４）作用・効果
基地局100によれば、移動局200Aに送信済みであるが送達確認を受信していない下りリンクデータ、及び基地局100が移動局200Aに送信した上りリンクデータの送達確認後に移動局200Aが基地局100に送信したと推定される上りリンクデータの和に基づいて滞留データ量を推定する。さらに、推定した滞留データ量が所定の閾値を超える場合、基地局100は、移動局200Aに送信される下りリンクデータ及び移動局200Aから送信される上りリンクデータのスケジューリングを停止する。
【００６０】
このため、移動局200Aのレイヤ２バッファ210のオーバーフローが発生すると予測される場合でも、当該下りリンクデータ及び当該上りリンクデータのスケジューリングが停止されるため、レイヤ２バッファ210のオーバーフローを確実に防止し得る。特に、基地局100と移動局200Aとの上りリンク及び下りリンクの品質が良好の場合において、実効的な通信速度の上昇によって短時間に大量のデータが移動局200Aに到達するような場合でも、レイヤ２バッファ210のオーバーフローを確実に防止し得る。
【００６１】
本実施形態では、RLC-AMが適用される無線アクセスベアラを介して送信されたデータに基づいて下りリンクデータ量及び上りリンクデータ量を推定しているが、RLC-UMが適用される無線アクセスベアラを介して送信されたデータを当該下りリンクデータ量及び当該上りリンクデータ量に加算することもできる。このため、より正確にレイヤ２バッファ210における滞留データ量を推定できる。
【００６２】
本実施形態では、スケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、ハイブリッドARQに従った再送データである場合、或いはスケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、RLCレイヤにおける再送データである場合、当該下りリンクデータまたは当該上りリンクデータを無線リソースにスケジューリングする、つまり、スケジューリングの停止の対象から除外される。このため、スケジューリングの停止による影響が大きいデータは速やかに送信されるため、スループットの低下などを効果的に抑制し得る。
【００６３】
（５）その他の実施形態
上述したように、本発明の一実施形態を通じて本発明の内容を開示したが、この開示の一部をなす論述及び図面は、本発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態が明らかとなろう。
【００６４】
例えば、上述した実施形態では、既存のTx Window Stalling発生時におけるデータのスケジューリング停止の機能を活用することによって、レイヤ２バッファ210のオーバーフローが発生すると推定された場合に、下りリンクデータまたは上りリンクデータの割り当てや送信を停止していたが、必ずしもこのようなTx Window Stalling発生時におけるデータのスケジューリング停止の機能を活用する必要はなく、別個独立の機能として、データのスケジューリング停止を実行するようにしてもよい。
【００６５】
このように、本発明は、ここでは記載していない様々な実施の形態などを含むことは勿論である。したがって、本発明の技術的範囲は、上述の説明から妥当な特許請求の範囲に係る発明特定事項によってのみ定められるものである。
【符号の説明】
【００６６】
50…コアネットワーク
100…基地局
101…レイヤ２バッファ
105…UEバッファ滞留量推定部
107…スケジューリング処理部
109…無線通信部
200A, 200B…移動局
210…レイヤ２バッファ
310…Tx Window
320…Rx Window
C1…セル
【特許請求の範囲】
【請求項１】
移動局に送信される下りリンクデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファを備える基地局であって、
前記レイヤ２バッファに蓄えられたデータを下り方向における無線リソースにスケジューリングするスケジューリング処理部と、
前記移動局に備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファに滞留する滞留データ量を推定するバッファ滞留量推定部と
を備え、
前記バッファ滞留量推定部は、前記移動局に送信済みであるが送達確認を受信していない下りリンクデータ、及び前記基地局が前記移動局に送信した上りリンクデータの送達確認後に前記移動局が前記基地局に送信したと推定される上りリンクデータの和に基づいて、前記滞留データ量を推定し、
前記スケジューリング処理部は、前記バッファ滞留量推定部によって推定された前記滞留データ量が所定の閾値を超える場合、前記移動局に送信される下りリンクデータ及び前記移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止する基地局。
【請求項２】
前記バッファ滞留量推定部は、
RLC-AMが適用される無線アクセスベアラを介して送信された下り方向のPDUの平均サイズと、送信したPDUの数とに基づいて、下りリンクデータ量を推定し、
RLC-AMが適用される無線アクセスベアラを介して移動局から送信された上り方向のPDUの平均サイズと、受信したPDUの数とに基づいて、上りリンクデータ量を推定する請求項１に記載の基地局。
【請求項３】
前記バッファ滞留量推定部は、
RLC-UMが適用される無線アクセスベアラを介して送信された追加下りリンクデータ量を前記下りリンクデータ量に加算し、
RLC-UMが適用される無線アクセスベアラを介して受信した追加上りリンクデータ量を前記上りリンクデータ量に加算する請求項２に記載の基地局。
【請求項４】
前記スケジューリング処理部は、スケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、ハイブリッドARQに従った再送データである場合、或いはスケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、RLCレイヤにおける再送データである場合、前記下りリンクデータまたは前記上りリンクデータを無線リソースにスケジューリングする請求項１に記載の基地局。
【請求項５】
移動局に送信されるデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファを備える通信装置を用いた通信制御方法であって、
前記レイヤ２バッファに蓄えられたデータを下り方向における無線リソースにスケジューリングするステップと、
前記移動局に備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファに滞留する滞留データ量を推定するステップと
を有し、
前記滞留データ量を推定するステップでは、前記移動局に送信済みであるが送達確認を受信していない下りリンクデータ、及び前記基地局が前記移動局に送信した上りリンクデータの送達確認後に前記移動局が前記基地局に送信したと推定される上りリンクデータの和に基づいて、前記滞留データ量を推定し、
前記スケジューリングするステップでは、前記バッファ滞留量推定部によって推定された前記滞留データ量が所定の閾値を超える場合、前記移動局に送信される下りリンクデータ及び前記移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止する通信制御方法。
【請求項１】
移動局に送信される下りリンクデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファを備える基地局であって、
前記レイヤ２バッファに蓄えられたデータを下り方向における無線リソースにスケジューリングするスケジューリング処理部と、
前記移動局に備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファに滞留する滞留データ量を推定するバッファ滞留量推定部と
を備え、
前記バッファ滞留量推定部は、前記移動局に送信済みであるが送達確認を受信していない下りリンクデータ、及び前記基地局が前記移動局に送信した上りリンクデータの送達確認後に前記移動局が前記基地局に送信したと推定される上りリンクデータの和に基づいて、前記滞留データ量を推定し、
前記スケジューリング処理部は、前記バッファ滞留量推定部によって推定された前記滞留データ量が所定の閾値を超える場合、前記移動局に送信される下りリンクデータ及び前記移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止する基地局。
【請求項２】
前記バッファ滞留量推定部は、
RLC-AMが適用される無線アクセスベアラを介して送信された下り方向のPDUの平均サイズと、送信したPDUの数とに基づいて、下りリンクデータ量を推定し、
RLC-AMが適用される無線アクセスベアラを介して移動局から送信された上り方向のPDUの平均サイズと、受信したPDUの数とに基づいて、上りリンクデータ量を推定する請求項１に記載の基地局。
【請求項３】
前記バッファ滞留量推定部は、
RLC-UMが適用される無線アクセスベアラを介して送信された追加下りリンクデータ量を前記下りリンクデータ量に加算し、
RLC-UMが適用される無線アクセスベアラを介して受信した追加上りリンクデータ量を前記上りリンクデータ量に加算する請求項２に記載の基地局。
【請求項４】
前記スケジューリング処理部は、スケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、ハイブリッドARQに従った再送データである場合、或いはスケジューリングの停止の対象となる下りリンクデータまたは上りリンクデータが、RLCレイヤにおける再送データである場合、前記下りリンクデータまたは前記上りリンクデータを無線リソースにスケジューリングする請求項１に記載の基地局。
【請求項５】
移動局に送信されるデータを一時的に蓄える第２層レベルのバッファであるレイヤ２バッファを備える通信装置を用いた通信制御方法であって、
前記レイヤ２バッファに蓄えられたデータを下り方向における無線リソースにスケジューリングするステップと、
前記移動局に備えられ、下りリンクデータ及び上りリンクデータを一時的に蓄える移動局バッファに滞留する滞留データ量を推定するステップと
を有し、
前記滞留データ量を推定するステップでは、前記移動局に送信済みであるが送達確認を受信していない下りリンクデータ、及び前記基地局が前記移動局に送信した上りリンクデータの送達確認後に前記移動局が前記基地局に送信したと推定される上りリンクデータの和に基づいて、前記滞留データ量を推定し、
前記スケジューリングするステップでは、前記バッファ滞留量推定部によって推定された前記滞留データ量が所定の閾値を超える場合、前記移動局に送信される下りリンクデータ及び前記移動局から送信される上りリンクデータの少なくとも何れかのスケジューリングを停止する通信制御方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１３−８５０３３（Ｐ２０１３−８５０３３Ａ）
【公開日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願番号】特願２０１１−２２２０３４（Ｐ２０１１−２２２０３４）
【出願日】平成２３年１０月６日（２０１１．１０．６）
【特許番号】特許第５１４７９８３号（Ｐ５１４７９８３）
【特許公報発行日】平成２５年２月２０日（２０１３．２．２０）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
【公開日】平成２５年５月９日（２０１３．５．９）
【国際特許分類】
【出願日】平成２３年１０月６日（２０１１．１０．６）
【特許番号】特許第５１４７９８３号（Ｐ５１４７９８３）
【特許公報発行日】平成２５年２月２０日（２０１３．２．２０）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【Ｆターム（参考）】
[ Back to top ]