以下に、本願の開示する無線通信システム、移動局、基地局及び無線通信方法の実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する無線通信システム、移動局、基地局及び無線通信方法が限定されるものではない。
次に、実施例2について説明する。図3は、実施例2に係る無線通信システムの2元接続の概略図である。本実施例に係る無線通信システムは、図1における無線通信装置1としてマクロ基地局100を有する。また、図1における無線通信装置2としてスモール基地局200を有する。また、図1における無線通信装置3として移動局300を有する。
移動局300は、プライマリの基地局としてマクロ基地局100に接続する。移動局300は、実線矢印で表される制御プレーン350及び破線矢印で表されるユーザプレーン351によりマクロ基地局100と接続される。また、移動局300は、セカンダリの基地局としてスモール基地局200に接続する。移動局300は、ユーザプレーン351によりスモール基地局200と接続される。図3のユーザプレーン351は、ハンドオーバーが行われた場合の、移動局300とスモール基地局200とを接続する各ユーザプレーン351を表している。制御プレーン350が、「第1論理処理主体」の一例にあたる。また、ユーザプレーン351が、「第2論理処理主体」の一例にあたる。
図3のような無線通信システムの構成は、トラフィックのオフロードやハンドオーバー回数の低減のために採用されることが多い。
次に、図4を参照して、本実施例に係る無線通信システムの詳細を説明する。図4は、実施例2に係る無線通信システムのブロック図である。本実施例に係る無線通信システムは、図4において、図1と同じ符号を有する各部は特に説明のない限り同じ機能を有するものとする。
マクロ基地局100のセルであるマクロセルは、スモール基地局200のセルを含む複数のスモールセルを内包している。そして、本実施例に係る無線通信システムは、マクロ基地局100をプライマリの無線通信装置とし、スモール基地局200をセカンダリの無線通信装置として、移動局300との間で2元接続を行う。
また、マクロ基地局100、スモール基地局200及び移動局300は、例えば、PDCPレイヤ、RLCレイヤ、MACレイヤ、PHYレイヤなどの複数のリンクレイヤに対応するリンクレイヤプロトコルを用いて通信を行う。
そこで、ここでは、図5を参照して、リンクレイヤ毎に実行される処理を説明する。図5は、実施例2に係る無線通信システムにおいて各リンクレイヤを用いて実行されるユーザデータの送受信を表した図である。ここで、本実施例では、移動局300がマクロ基地局100及びスモール基地局200のいずれからもユーザデータを取得する場合で説明する。
マクロ基地局100の、通信部11における受信部12及び送信部13は、PDCPレイヤ、下りRLCレイヤ、MACレイヤ及びPHYレイヤを用いてデータの送受信を行う。図5では、説明の便宜上、通信部11が通信を実施するための各レイヤのうち、PDCPレイヤ101、RLCレイヤ102、RLCレイヤ103及びMACレイヤ104を記載している。RLCレイヤ102は下りのRLCレイヤであり、RLCレイヤ103は上りのRLCレイヤである。
なお、このような構成では、RLCレイヤにおいてRLC AM(Acknowledged Mode)を使用している構成である。RLC AMにおいては、下りデータに対し、上りのフィードバック(送信したデータに対する送信確認(ACKやNACK)や、通信の制御情報)を受信する必要があるため、ベアラとして双方向ベアラ(Bi-directional Bearer)が使用される(マッピングされる)。上り通信の場合も同様に、上りデータに対して下りフィードバックを受信するため、双方向ベアラが使用される(マッピングされる)。ベアラの種類を明示する場合、AM−DRBと呼ぶことがある。
RLCレイヤの別の構成としては、RLC UM(Unacknowledged Mode)を使用する構成がある。RLC UMにおいては、RLC AMと同様に双方向ベアラが使用される(マッピング)される場合と、一方向ベアラ(Uni-directional)が使用される場合がある。一方向ベアラの場合、下り通信の場合も、上り通信も、PDCPレイヤ、RLCレイヤ、およびMACレイヤはそれぞれ1つのみが使用される(マッピング)される。ベアラの種類を明示する場合、UM−DRBと呼ぶことがある。
RLCレイヤの別の構成としては、RLC TM(Transparent Mode)を使用する構成がある。この構成は、実質的にRLCレイヤを使用しない構成であり、下り通信の場合も、上り通信の場合も、PDCPレイヤのデータはMACレイヤに直接配送される。
RLC AMには、例えば、信頼性のある通信を提供するTCP(Transmission Control Protocol)を使用するアプリケーションがマッピングされる。RLC UMには、例えばリアルタイム性が求められる通信(例えばVoIP)を提供するUDP(User Datagram Protocol)を使用するアプリケーションがマッピングされる。
また、本実施例に係る無線通信システムでは、プライマリの無線通信装置であるマクロ基地局100は、PDCPレイヤ101とRLCレイヤ102との間でデータプレーンを分離する。具体的には、データプレーンは、PDCPレイヤ101とRLCレイヤ102との間で分離され、一方は、マクロ基地局100のRLCレイヤ102へ進み、他方はスモール基地局200のRLCレイヤ201へ進む。
(マクロ基地局の処理)
移動局300へのユーザデータ送信時の通信部11の処理について説明する。
通信部11は、PDCPレイヤ101のユーザデータを上位レイヤ通信装置4から受信する。そして、通信部11は、PDCPレイヤ101において、受信したユーザデータのパケットに規則的に番号を付加する(例えば昇順に連続的な番号を付加する)。この番号は、ハンドオーバーためにも用いられる。本実施例では、例えば、通信部11は、自装置のRLCレイヤ102へ送るデータに奇数番号を順番に付加していく。また、通信部11は、スモール基地局200のRLCレイヤ201に送るユーザデータのパケットに偶数番号を順次付加していく。さらに、通信部11は、PDCPレイヤ101において、ユーザデータに対して、ヘッダ圧縮、セキュリティチェック及び暗号化を行う。
そして、通信部11は、奇数番号を付加したユーザデータを、PDCPレイヤ101からRLCレイヤ102に送信する。また、通信部11は、偶数番号を付加したユーザデータを、有線リンクを経由させてスモール基地局200のRLCレイヤ201に送信する。
ここで、図6を参照して、通信部11によるユーザデータの分配を説明する。図6は、規則的に番号が付加されたユーザデータの流れを説明するための図である。図6の点線で表される四角が送られたユーザデータを表している。そして、ユーザデータ内部の番号が各ユーザデータに付与された番号を表している。例えば、#1は、1の番号が付与されたユーザデータを表している。
通信部11は、PDCPレイヤ101において1、3、5、7の番号を付与したデータを、矢印111で示すように、RLCレイヤ102へ送信する。また、通信部11は、PDCPレイヤ101において2、4、6、8の番号を付与したデータを、矢印112で示すように、スモール基地局200のRLCレイヤ201へ送信する。
さらに、通信部11によるスモール基地局200のRLCレイヤ201へのユーザデータの送信について詳細に説明する。
通信部11は、移動局300のバッファの状態(例えば、データ滞留量であり、データの受信状態)を示す情報を表すPDCP Status Reportを移動局300の通信部31から受信する。そして、通信部11は、受信したPDCP Status Reportを制御部14へ送信する。その後、通信部11は、スモール基地局200のRLCレイヤ201へのユーザデータの配送量の通知を制御部14から受信する。そして、通信部11は、制御部14から指定された配送量でユーザデータをスモール基地局200のRLCレイヤ201へ送信する。
図5に戻って説明を続ける。通信部11は、RLCレイヤ102において、PDCPレイヤからユーザデータ(PDCP PDU)を受信する。必要に応じてユーザデータであるパケットの分割や統合を行いパケットのサイズを変更することもできる。さらに、通信部11は、RLCレイヤ102において、RLCレイヤ用の番号をPDCPレイヤから受信したパケット(PDCP PDU)に順次付与していく。そして、通信部11は、RLCレイヤ102のバッファにユーザデータであるパケット(RLC PDU)を蓄積していく。
その後、通信部11は、移動局300へ送信可能なユーザデータのデータ量をMACレイヤ104から受け取る。そして、通信部11は、MACレイヤ104から受け取ったデータ量に応じたユーザデータを、RLCレイヤ102のバッファからMACレイヤ104へ送信する。
通信部11は、MACレイヤ104において、RLCレイヤ102から受信したユーザデータ(RLC PDU)を用いて送信分のデータを組み立てる(例えば、MACヘッダの付加などを行い、MAC PDUを生成する)。そして、通信部11は、MACレイヤ104において、データ送信のスケジューリングを行い、スケジュールに合わせて組み立てたデータを移動局300へ出力する。ここで、図5では、通信部11のMACレイヤ104と移動局300のMACレイヤ301とが通信をしているように記載しているが、実際には、PHYレイヤなどを経由して通信を行っている。
次に、移動局300からのユーザデータ受信時の通信部11の処理について説明する。
通信部11は、MACレイヤ104において、ユーザデータ受信のスケジューリングを行い、スケジューリングに合わせて移動局300のMACレイヤ301から受信する。次に、通信部11は、MACレイヤ104において、受信したユーザデータを再構築(リアセンブル)する(例えば、MAC PDUからMACヘッダを除去しRLC PDUを取り出す)。そして、通信部11は、MACレイヤ104からRLCレイヤ103へユーザデータ(MAC SDU)を送信(配送)する。
通信部11は、RLCレイヤ103において、受信したユーザデータ(RLC PDU)の分割や統合を行う。さらに、通信部11は、RLCレイヤ103において、パケットに付加されたRLCレイヤ用の番号を用いてパケットの順番を修正する。そして、通信部11は、RLCレイヤ103からPDCPレイヤ101へユーザデータ(RLC SDU)をシーケンス番号順に送信(配送)する。
通信部11は、PDCPレイヤ101において、ユーザデータ(PDCP PDU)に対して、復号化、セキュリティチェック及びヘッダ圧縮の解除を行う。
そして、通信部11は、PDCPレイヤ101から上位レイヤ通信装置4へユーザデータを送信する。
また、ハンドオーバーが発生した場合には、通信部11は、多元接続を解除し、シングル接続のみの通信に遷移する。そして、通信部11は、PDCPレイヤ101において、RLCレイヤなどの下層レイヤから、下層レイヤに存在するパケットを取得する。そして、通信部11は、PDCPレイヤ101において、取得したパケットを番号順に並び替え番号保障を行う。
ハンドオーバーが発生した場合、移動元の基地局は、移動先の基地局へ送信が完了していないパケットをフォワーディング(転送)する。そして、移動先の基地局は、フォワーディングにより受信したパケットを移動局300へ送信する。
次に、制御部14の動作について説明する。制御部14は、移動局300のバッファの状態(例えば、データ滞留量であり、データの受信状態)を通知するためのPDCP Status Reportのパラメータ設定を、通信部11を介して移動局300へ通知する。ここで、PDCP Status Reportのパラメータ設定には、通知周期及び通知を行うか否かの判定を行うための滞留量閾値などが含まれる。本実施例では、制御部14は、滞留量閾値を、移動局300のPDCPレイヤ307におけるバッファの10%と記憶している。また、本実施例では、制御部14は、通知周期として100msを記憶している。ただし、滞留量閾値及び通知周期は他の値を取ることもでき、運用に合わせて決定されることが好ましい。
そして、2元接続による無線通信開始後、制御部14は、移動局300のPDCP Status Reportを通信部11から受信する。図7Aは、12bitのシーケンス番号用のPDCP Status Reportの一例の図である。また、図7Bは、15bitのシーケンス番号用のPDCP Status Reportの一例の図である。図7Cは、7bitのシーケンス番号用のPDCP Status Reportの一例の図である。PDCP Status Reportは、送受信するデータによってシーケンス番号のサイズが異なる。例えば、VoIP(Voice of Internet Protocol)などでは、7bitのシーケンス番号が使用される場合がある。
各PDCP Status Report400、410及び420は、未到達のパケットのうち最も古いパケットのシーケンス番号を表すFMS(First Missing Sequence number)401、411及び421のサイズが異なる。以下では、図7Aに示す、12bitのシーケンス番号用のPDCP Status Reportを例に説明する。
図7Aに示すPDCP Status Report400のフォーマットは、移動局から基地局にPDCPシーケンス番号を通知するために用いられる。FMS401は、未到達のパケットのうち最も古いパケットのPDCPシーケンス番号が格納される。ここで、PDCP Status Report400は12bitのPDCPシーケンス番号向けなので、FMS401は、12bitを使用している。また、Bitmap1〜BitmapNはオプションとして用いられる。
FMS401には、未到達のパケットのうち最も古いパケットのシーケンス番号が格納される。言い換えれば、FMS401には、スモール基地局200から届いていないユーザデータのパケット中で、最も早くに受信するはずのパケットのシーケンス番号が格納される。以下では、未到達のパケットのうち最も古いパケットを「FMSのパケット」という場合がある。さらに、PDCP Status Report400のBitmap1〜BitmapNに、FMS401に対応するパケット以降のパケットの到達状態を表す情報が格納される。本実施例では、PDCP Status Report400のBitmap1〜BitmapNに、到達を表すbitを「1」とし、未到達を表すbitを「0」とした情報が格納される。例えば、あるパケットが未到達となり、その後の6つのパケットが順番に到達と未到達を繰り返している場合、Bitmap1〜BitmapNには、101010という情報が格納される。
また、図8は、PDU Typeに格納される情報を示す図である。表430には、PDCP Status ReportのPDU Typeの各ビットの情報と、それに対応するPDU Typeの内容が記載されている。PDU Typeの各ビットが「000」の場合、移動局300で受信したユーザデータのPDCPシーケンス番号を表すPDCP stutus reportであることを表している。また、PDU Typeの各ビットが「001」の場合、散在ROHCフィードバックパケット(interspersed ROHC feedback packet)であることを表している。散在ROHCフィードバックパケットは、受信側から伝送されたPDCP PDUに対するフィードバック情報を含む。そして、PDU Typeの各ビットが「010」〜「111」までは、予備で残されている。本実施例では、PDCP Status Report400のPDU Typeには、「001」のビット列が格納される。
ただし、バッファの状態(例えば、データ滞留量であり、データの受信状態)を示す情報の通知を表すために新たに別の値のPDU Typeを指定することもできる。例えば、各ビットとして「010」〜「111」のいずれか一つを、予め決めた値をPDU Typeのビット列に格納してもよい。
ここで、本実施例では、図7Cのように、7bitのシーケンス番号用のPDCP Status Report420を作成した。そのため、本実施例に係る無線通信システムでは、RLCのUM(Unacknowledge mode)ベアラを用いる場合にも、PDCP Status Reportを利用することができ、パケットの順番保証の信頼度を向上させることができる。
制御部14は、受信したPDCP Status Report400のFMS401からFMSのパケットの番号を取得する。さらに、制御部14は、FMSのパケット以降のパケットの受信状態をPDCP Status Report400のBitmap1〜BitmapNから取得する。そして、制御部14は、FMS401に格納されている番号を有するパケット以降のパケット量から、移動局300のバッファにおけるデータ滞留量を求める。
その後、制御部14は、求めたバッファの状態を通信部11へ通知する。
ここで、シーケンス番号が図6のようにユーザデータのパケットに付与された場合を例に説明する。例えば、図6におけるシーケンス番号が2番のパケットが、移動局300に届いていないものとする。
この場合、奇数のシーケンス番号を有するパケットはマクロ基地局100から送信されるため、シーケンス番号1,3,5,7のパケットは移動局300に届く。これに対して、偶数のシーケンス番号を有するパケットはスモール基地局200から送られるため、2番以降の偶数のパケットであるシーケンス番号4,6,8のパケットは移動局300に届かない。これは、2番のパケットがPDCPレイヤに届いていない場合、それ以降の番号のパケットは下層レイヤに滞留しPDCPレイヤには届かないからである。
ただし、ハンドオーバーの場合、2番のパケットがPDCPレイヤに届いていなくても、シーケンス番号4,6,8のパケットはPDCPレイヤに回送される。そして、PDCPレイヤにおいて、パケットに対する番号保障が実施される。
なお、最悪のケースを想定し、このハンドオーバー時の動作を2元接続(多元接続)のケースに応用できる。つまり、2番目のパケットがマクロ基地局からスモール基地局に配送されていないケース(例えば、パケットロスが生じるケースや、スモール基地局側でビットエラー等を検出するケース)の場合、シーケンス番号4、6、8のパケットはPDCPレイヤに回送されずに、デッドロックのような状態に陥る。このようなケースでは、上位レイヤであるTCPレイヤやアプリケーションレイヤで、エンドツーエンドで再送を実施しなければならない。
そこで、シーケンス番号の抜けがあっても、PDCPレイヤにパケットを回送することによって、どのパケットが届いていないのかを、PDCPレイヤで把握することができる。例えば上記の例では、シーケンス番号2のパケットがPDCPレイヤに届いていない場合、PDCPレイヤのバッファの状態は「1、3、4、5、6、7、8」となり、パケット2が届いていないことがわかる。もし、上記のようにパケット2がスモール基地局に配送されていない場合、前述のようにデッドロックの状態となる。そこで、その状態を解消するために、タイマ制御が考えられる。
具体的には、例えば、シーケンス番号2のパケットが届いていないことを検出すると、タイマを始動する。そして、設定された時間内に2番目のパケットが届かず、タイマが満了した場合、タイマ2はスモール基地局に届いていなかったものとし、全てのパケットを上位レイヤに回送するようにする。
このような制御を行うことによって、デッドロック状態を少しでも早く解消し、エンドツーエンドでの再送を高速化することができる(再送までにかかる遅延時間を短くすることができる)。
なお、タイマの設定値は、回線設定時に予め設定してもよいし、2元接続(多元接続)を実施する時に設定してもよい。また、タイマはPDCPレイヤで管理してもよいし、別のレイヤ(MACレイヤやRLCレイヤ)で管理してもよい。寛容なことは、端末にてタイマ制御を行うことである。
この場合、制御部14は、FMSにシーケンス番号2の情報が格納され、Bitmap1〜BitmapNには、「101010」という情報が格納されたPDCP Status Reportを受信する。そして、制御部14は、FMSのパケットの番号として、FMSに格納されている2番を取得する。そして、制御部14は、その後のビット列から、移動局300のバッファにシーケンス番号3,5,7のパケットが蓄積されており、スモール基地局200からシーケンス番号4,6,8のパケットが届いていないことを確認する。移動局300のバッファに蓄積されたシーケンス番号3,5,7のパケット及びスモール基地局200から届いていないシーケンス番号2,4,6,8のパケットが移動局300のバッファにおけるデータ滞留量となる。そして、制御部14は、移動局300のバッファにおけるデータ滞留量を用いて、マクロ基地局100からスモール基地局200へ送信するユーザデータの配送量を算出する。
このデータの配送量の算出は、例えば、制御部14は、データ滞留量が多くなれば配送量が少なくなり、データ滞留量が少なくなれば配送量が多くなる関数を予め記憶しておき、その関数を用いて配送量を算出してもよい。また、データを送る場合の配送量は固定にして、制御部14は、データ滞留量が予め決められた閾値よりも大きければデータの配送を停止し、その後、データ滞留量が閾値を下回った段階でデータの配送を再開してもよい。さらに、段階的にデータ滞留量と配送量との対応を記憶しておき、制御部14は、記憶している対応関係に合わせて配送量を決定してもよい。
制御部14は、マクロ基地局100及びスモール基地局200に送信した各パケットに付与したシーケンス番号を記憶しておくことで、受信したPDCP Status Reportを基に、スモール基地局側のデータ滞留量を算出することができ、データ配送量を算出することができる。
(スモール基地局の処理)
図5に戻って説明を続ける。スモール基地局200における移動局300へのユーザデータ送信時の処理について説明する。図5では、スモール基地局200のレイヤのうち説明に用いるRLCレイヤ201、RLCレイヤ202及びMACレイヤ203のみを記載している。ここで、RLCレイヤ201は下りのRLCレイヤであり、RLCレイヤ202は上りのRLCレイヤ(下りに付随するRLCレイヤ)である。
通信部21は、RLCレイヤ201において、マクロ基地局100のPDCPレイヤ101から有線リンクを経由して送られてきたユーザデータを受信する。
次に、通信部21は、RLCレイヤ201において、PDCPレイヤからユーザデータ(PDCP PDU)を受信する。必要に応じて、通信部21は、ユーザデータであるパケットの分割や統合を行いパケットのサイズを変更することもできる。さらに、通信部21は、RLCレイヤ201において、RLCレイヤ用の番号をPDCPレイヤから受信しパケット(PDCP PDU)に順次付与していく。そして、通信部21は、RLCレイヤ201のバッファにユーザデータであるパケット(RLC PDU)を蓄積していく。
その後、通信部21は、移動局300へ送信可能なユーザデータのデータ量をMACレイヤ203から受け取る。そして、通信部21は、MACレイヤ203から受け取ったデータ量に応じたユーザデータを、RLCレイヤ201のバッファからMACレイヤ203へ送信する。
通信部21は、MACレイヤ203において、RLCレイヤ201から受信したユーザデータ(RLC PDU)を用いて送信分のデータを組み立てる(例えば、MACヘッダの付加などを行いMAC PDUを生成する)。そして、通信部21は、MACレイヤ203において、データ送信のスケジューリングを行い、スケジュールに合わせて組み立てたデータ(RLC SDU)を移動局300へ出力する。
次に、スモール基地局200における移動局300からのユーザデータ受信時の処理について説明する。
通信部21は、MACレイヤ203において、ユーザデータ受信のスケジューリングを行い、スケジューリングに合わせて移動局300のMACレイヤ302から受信する。次に、通信部21は、MACレイヤ203において、受信したユーザデータを再構築(リアセンブル)する。そして、通信部21は、MACレイヤ203からRLCレイヤ202へユーザデータ(MAC SDU)を送信(配送)する。
通信部21は、RLCレイヤ202において、受信したユーザデータ(RLC PDU)の分割や統合を行う。さらに、通信部21は、RLCレイヤ202において、パケットに付加されているRLCレイヤ用の番号を基に、パケットの順序を修正する。そして、通信部21は、RLCレイヤ202からマクロ基地局100のPDCPレイヤ101へユーザデータ(RLC SDU)を、有線リンクを経由させてシーケンス番号順に送信(配送)する。
(移動局の処理)
次に、移動局300について説明する。図5では、移動局300のレイヤのうち説明に用いるMACレイヤ301、MACレイヤ302、RLCレイヤ303〜306及びPDCPレイヤ307を記載している。ここで、本実施例では、移動局300は2つの基地局から並行してユーザデータを受信する機能を有している。MACレイヤ301、RLCレイヤ303、RLCレイヤ304、PDCPレイヤ307が、マクロ基地局100との間でデータの送受信を行うための各レイヤである。RLCレイヤ303は下りのRLCレイヤであり、RLCレイヤ304は上りのRLCレイヤである。また、MACレイヤ302、RLCレイヤ305、RLCレイヤ306、PDCPレイヤ307が、スモール基地局200との間でデータの送受信を行うための各レイヤである。RLCレイヤ305は下りのRLCレイヤであり、RLCレイヤ306は上りのRLCレイヤ(下りに付随するRLCレイヤ)である。
移動局300におけるマクロ基地局100からのユーザデータ受信時の処理について説明する。
通信部31は、MACレイヤ301において、ユーザデータ受信のスケジューリングを行い、スケジューリングに合わせてマクロ基地局100のMACレイヤ104から受信する。次に、通信部31は、MACレイヤ301において、受信したユーザデータを再構築(リアセンブル)する。そして、通信部31は、MACレイヤ301からRLCレイヤ303へユーザデータ(MAC SDU)を送信する。
通信部31は、RLCレイヤ303において、受信したユーザデータ(RLC PDU)の分割や統合を行う。さらに、通信部31は、RLCレイヤ303において、パケットに付加されているRLCレイヤ用の番号を基に、パケットの順序を修正する。そして、通信部31は、RLCレイヤ303からPDCPレイヤ307へユーザデータ(RLC SDU)を送信(配送)する。
通信部31は、PDCPレイヤ307において、ユーザデータに対して、復号化、セキュリティチェック及びヘッダ圧縮の解除を行う。
そして、通信部31は、受信したユーザデータに対して、データの表示やデータを用いた演算等のデータ処理を行う。
次に、移動局300におけるマクロ基地局100へのユーザデータ送信時の処理について説明する。
通信部31は、PDCPレイヤ307において、送信するユーザデータのパケットに規則的(例えば、昇順に連続的に)に番号を付加する。さらに、通信部31は、PDCPレイヤ307において、ユーザデータに対して、ヘッダ圧縮、セキュリティチェック及び暗号化を行う。
そして、通信部31は、PDCPレイヤ307からRLCレイヤ304にユーザデータを送信する。
次に、通信部31は、RLCレイヤ304において、PDCPレイヤからユーザデータ(PDCP PDU)を受信する。通信部31は、必要に応じてユーザデータであるパケットの分割や統合を行いパケットのサイズを変更することもできる。さらに、通信部31は、RLCレイヤ304において、RLCレイヤ用の番号をPDCPレイヤから受信したパケット(PDCP PDU)に順次付与していく。そして、通信部31は、RLCレイヤ304のバッファにユーザデータであるパケット(RLC PDU)を蓄積していく。
その後、通信部31は、マクロ基地局100へ送信可能なユーザデータのデータ量をMACレイヤ301から受け取る。そして、通信部31は、MACレイヤ301から受け取ったデータ量に応じたユーザデータを、RLCレイヤ304のバッファからMACレイヤ301へ送信する。
通信部31は、MACレイヤ301において、RLCレイヤ304から受信したユーザデータ(RLC PDU)を用いて送信分のデータを組み立てる(例えば、MACヘッダの付加などを行いMAC PDUを生成する)。そして、通信部31は、MACレイヤ301において、データ送信のスケジューリングを行い、スケジュールに合わせて組み立てたデータをマクロ基地局100へ出力する。
移動局300におけるスモール基地局200からのユーザデータ受信時の処理について説明する。
通信部31は、MACレイヤ302において、ユーザデータ受信のスケジューリングを行い、スケジューリングに合わせてスモール基地局200のMACレイヤ203から受信する。次に、通信部31は、MACレイヤ302において、受信したユーザデータを再構築(リアセンプル)する。そして、通信部31は、MACレイヤ302からRLCレイヤ305へユーザデータ(MAC SDU)を送信(配送)する。
通信部31は、RLCレイヤ305において、受信したユーザデータ(RLC PDU)の分割や統合を行う。さらに、通信部31は、RLCレイヤ305において、パケットに付加されているRLCレイヤ用の番号を基に、パケットの順序を修正する。そして、通信部31は、RLCレイヤ305からPDCPレイヤ307へユーザデータ(RLC SDU)をシーケンス番号順に送信(配送)する。
通信部31は、PDCPレイヤ307において、ユーザデータ(PDCP PDU)に対して、復号化、セキュリティチェック及びヘッダ圧縮の解除を行う。
そして、通信部31は、受信したユーザデータに対して、データの表示やデータを用いた演算等のデータ処理を行う。
次に、移動局300におけるスモール基地局200へのユーザデータ送信時の処理について説明する。
通信部31は、PDCPレイヤ307において、送信するユーザデータのパケットに規則的に番号を付加する(例えば、昇順に連続的な番号を付加する)。さらに、通信部31は、PDCPレイヤ307において、ユーザデータに対して、ヘッダ圧縮、セキュリティチェック及び暗号化を行う。
そして、通信部31は、PDCPレイヤ307からRLCレイヤ306にユーザデータを送信する。
次に、通信部31は、RLCレイヤ306において、PDCPレイヤからユーザデータ(PDCP PDU)を受信する。必要に応じて、通信部31は、ユーザデータであるパケットの分割や統合を行いパケットのサイズを変更することもできる。さらに、通信部31は、RLCレイヤ306において、RLCレイヤ用の番号をPDCPレイヤから受信したパケット(PDCP PDU)に順次付与していく。そして、通信部31は、RLCレイヤ306のバッファにユーザデータであるパケット(RLC PDU)を蓄積していく。
その後、通信部31は、マクロ基地局100へ送信可能なユーザデータのデータ量をMACレイヤ302から受け取る。そして、通信部31は、MACレイヤ302から受け取ったデータ量に応じたユーザデータを、RLCレイヤ306のバッファからMACレイヤ302へ送信する。
通信部31は、MACレイヤ302において、RLCレイヤ306から受信したユーザデータ(RLC PDU)を用いて送信分のデータを組み立てる(例えば、MACヘッダの付加などを行いMAC PDUを生成する)。そして、通信部31は、MACレイヤ302において、データ送信のスケジューリングを行い、スケジュールに合わせて組み立てたデータ(RLC SDU)をスモール基地局200へ出力する。
次に、移動局300におけるマクロ基地局100へのデータの状態(例えば、データ滞留量であり、データの受信状態)を示す情報の通知について説明する。
制御部34は、通信部31を介して、PDCP Status Reportのパラメータ設定を受信する。そして、制御部34は、PDCP Status Reportのパラメータ設定を用いて、定期通知の通知周期及び滞留量閾値などのPDCP Status Reportの各種パラメータを設定する。
制御部34は、ユーザデータの受信時に、PDCPレイヤ307で受信したパケットのPDCPレイヤ307におけるバッファへの滞留量を監視している。そして、制御部34は、滞留量が滞留量閾値を超えると、スモール基地局200から届いていないユーザデータのパケットうち、FMSのパケットの番号を取得する。さらに、制御部34は、FMSのパケット以降に処理するパケットの受信状態を取得する。
そして、制御部34は、取得した情報を用いて、図7Aに示すフォーマットを有するPDCP Status Report400を生成する。
ここで、シーケンス番号が図6のようにユーザデータのパケットに付与され、シーケンス番号が2番のパケットが、移動局300に届いていない場合を例に、制御部34によるPDCP Status Reportの作成を説明する。
この場合、シーケンス番号1,3,5,7のパケットは移動局300に届くが、シーケンス番号4,6,8のパケットは移動局300に届かない。これは、2番のパケットがPDCPレイヤに届いていない場合、それ以降の番号のパケットは下層レイヤに滞留しPDCPレイヤには届かないからである。
ただし、ハンドオーバーの場合、2番のパケットがPDCPレイヤに届いていなくても、シーケンス番号4,6,8のパケットはPDCPレイヤに吸い上げられる。そして、PDCPレイヤにおいて、パケットに対する番号保障が実施される。
そこで、制御部34は、スモール基地局200から届いていないユーザデータのパケットうち、FMSのパケットの番号として2番を取得する。さらに、制御部34は、FMSのパケット以降に処理するパケットの受信状態として、シーケンス番号1,3,5,7のパケットは受信済みであり、シーケンス番号4,6,8のパケットは未受信であるという情報を取得する。ここで、制御部34は、マクロ基地局100から届いていないユーザデータのうち、FMSのパケットの番号を取得し、FMSのパケット以降に処理するパケットの受信状態を取得してもよい。
そして、制御部34は、PDCP Status ReportのFMSの領域に、シーケンス番号2のパケットであるという情報を格納する。さらに、制御部34は、Bitmap1〜BitmapNの各ビットに先頭から101010を格納する。さらに、制御部34は、PDU Typeの領域にバッファの滞留量を示す情報を通知するためのパケットであることを表すデータを格納する。
その後、制御部34は、生成したPDCP Status Reportを通信部31へ送信する。
通信部31は、制御部34から受信したPDCP Status Reportをマクロ基地局100へ送信する。
また、制御部34は、記憶している周期毎に、PDCP Status Reportを生成する。そして、通信部31は、PDCP Status Reportをマクロ基地局100へ送信する。
ここで、本実施例では、バッファの滞留量の通知タイミングとして、閾値を超えた場合及び定期的な場合の2つのタイミングを用いているが、通知タイミングはこれに限らない。例えば、制御部34は、定期的な場合のみを通知タイミングとして用いてもよい。また、制御部34は、閾値を超えた場合を通知タイミングとして用いて、その後一定期間毎に閾値を下回るまで通知を行ってもよい。
次に、図9を参照して、2元接続時のデータの配送量制御の全体的な流れを説明する。図9は、データの配送量制御の全体的な流れを説明するためのシーケンス図である。ここでは、マクロ基地局100は、移動局300のバッファにおけるデータ滞留量が閾値を超えると、スモール基地局200へのユーザデータの送信を停止し、その後、移動局300のバッファが空になるとユーザデータの送信を再開する場合で説明する。ここで、図9における状態501〜503は移動局300のバッファのデータ滞留状態を表し、状態511〜514はマクロ基地局100のバッファのデータ滞留状態を表している。さらに、状態511〜514における矢印及びデータの記載はそのときにユーザデータがマクロ基地局100のバッファからスモール基地局200へ送信されていることを表している。
マクロ基地局100は、有線リンクを介して、ユーザデータをスモール基地局200へ送信する(ステップS1)。スモール基地局200は、移動局300へユーザデータを送信する(ステップS2)。
この時、マクロ基地局100のバッファには状態511のようにデータが蓄積される。そして、マクロ基地局100のバッファからはユーザデータが送信される。また、移動局300のバッファには状態501のようにバッファの容量に対して少ない量のデータが蓄積される。
さらに、マクロ基地局100は、有線リンクを介して、ユーザデータをスモール基地局200へ送信する(ステップS3)。スモール基地局200は、移動局300へユーザデータを送信する(ステップS4)。ただし、この時、スモール基地局200から移動局300へのデータ送信に遅延が発生している。
そこで、この場合、移動局300のバッファでは、状態502のように蓄積されているデータの量が増加する。この状態で、マクロ基地局100のバッファには、状態512のように、ユーザデータが蓄積されており、且つ、マクロ基地局100のバッファからはユーザデータが送信される。
そして、移動局300のバッファのデータ蓄積量が閾値を超えると、移動局300は、バッファのデータ滞留量を示す情報をマクロ基地局100へ送信する(ステップS5)。これを受けて、マクロ基地局100は、スモール基地局200へのユーザデータの送信を停止する。
これにより、マクロ基地局100のバッファには状態513のようにデータが蓄積されているが、マクロ基地局100のバッファからはユーザデータは送信されない。そして、移動局300は、スモール基地局200から遅延していたデータを受信しデータ処理を実施していくことで、バッファのデータ滞留量は減少する。そして、状態503のように、移動局300のバッファには滞留しているデータがなくなる。
その後、移動局300は、定期的なデータ滞留量の通知のタイミングで、バッファのデータ滞留量が0であることを表す情報をマクロ基地局100へ送信する(ステップS6)。
マクロ基地局100は、移動局300のバッファにおけるデータ滞留量が0であることを確認すると、スモール基地局200へのユーザデータの送信を再会する(ステップS7)。この時、マクロ基地局100のバッファには状態514のようにデータが蓄積されており、バッファからは蓄積されているユーザデータが送信される。そして、スモール基地局200は、移動局300へユーザデータを送信する(ステップS8)。
次に、図10を参照して、本実施例に係る通信システムにおける2元接続されているマクロ基地局100からスモール基地局200へのユーザデータの配送量の制御について説明する。図10は、実施例2に係る通信システムにおけるスモール基地局へのユーザデータの配送量の制御のフローチャートである。
マクロ基地局100の制御部14は、規則的なシーケンス番号の付加によるスモール基地局200へのユーザデータの配送量の管理を通信部11に指示する(ステップS101)。
送信部13は、PDCPレイヤ101においてユーザデータのパケットに規則的にシーケンス番号を付加し、有線リンクを介してスモール基地局200へユーザデータを送信する(ステップS102)。スモール基地局200は、マクロ基地局100から受信したユーザデータを移動局300へ送信する。
送信部13は、閾値や通知周期などを含むPDCP Status Reportのパラメータ設定を移動局300へ送信する(ステップS103)。
移動局300の受信部32は、PDCP Status Reportのパラメータ設定をマクロ基地局100から受信する(ステップS104)。
制御部34は、PDCP Status Reportのパラメータ設定を受信部32から取得する。そして、制御部34は、閾値や通知周期などのPDCP Status Reportのパラメータを設定する(ステップS105)。
制御部34は、移動局300のバッファにおけるデータ滞留量が閾値を超えたか又は通知周期が到来したか否かを判定する(ステップS106)。データ滞留量の閾値の超過及び通知周期の到来のいずれも発生していない場合(ステップS106:否定)、制御部34は、データ滞留量の閾値の超過又は通知周期の到来のいずれかが発生するまで待機する。
これに対して、データ滞留量の閾値の超過又は通知周期の到来のいずれかが発生した場合(ステップS106:肯定)、制御部34は、データ滞留量を示す情報を通知するためのPDCP Status Reportを生成する。そして、送信部33は、制御部34により生成されたPDCP Status Reportをマクロ基地局100へ送信する(ステップS107)。
マクロ基地局100の受信部12は、データ滞留量を示す情報を通知するためのPDCP Status Reportを移動局300から受信する(ステップS108)。
制御部14は、PDCP Status Reportを受信部12から取得する。そして、制御部14は、PDCP Status Reportを用いて移動局300のバッファのデータ滞留量を算出する(ステップS109)。
次に、制御部14は、算出したデータ滞留量からスモール基地局200へのユーザデータの配送量を決定する(ステップS110)。
送信部13は、制御部14が決定したスモール基地局200へのユーザデータの配送量の通知を受ける。そして、送信部13は、スモール基地局200へのユーザデータの配送量を指定された配送量に変更する(ステップS111)。そして、送信部13は、変更した配送量で規則的なシーケンス番号を付加したユーザデータをスモール基地局200へ送信する。
ここで、図10のフローチャートでは、ユーザデータの配送量の変更の処理を説明するため1回の変更処理が行われる一連の流れを説明したが、実際には、マクロ基地局100及び移動局300は、図10のステップS106からステップS111の処理を繰り返す。
次に、図11A及び図11Bを参照して、本実施例に係る通信システムにおける2元接続されているマクロ基地局100からスモール基地局200へのユーザデータ送信と従来の2元接続との比較について説明する。図11Aは、従来の通信システムにおける2元接続時のユーザデータの送信を説明するための図である。また、図11Bは、実施例2に係る通信システムにおける2元接続時のユーザデータの送信を説明するための図である。
図11Aにおけるマクロ基地局110とスモール基地局210との間の接続及び図11Bにおけるマクロ基地局100とスモール基地局200との間の接続は、破線矢印で表される接続であり、有線リンクを用いて接続されているものとする。
図11Aに示すように、従来の通信システムでは、スモール基地局210のMACレイヤは、PHYレイヤによって無線品質(UCI:Uplink Channel Informationと呼ばれ、移動局によって測定された下りリンクの無線品質であるCQI:Channel Quality Informationや上りリンクの無線品質であるSRS:Sounding Reference Signalなどが該当する。)から決定されたデータサイズを取得する。そして、スモール基地局210のRLCレイヤは、MACレイヤから送信するデータサイズを取得し、そのデータサイズ分のユーザデータをMACレイヤに送信する。
そして、スモール基地局210のRLCレイヤからMACレイヤに送信されたユーザデータのサイズがマクロ基地局110に有線リンクを経由して通知される。マクロ基地局110のPDCPレイヤは、スモール基地局210のRLCレイヤから送出されたユーザデータのサイズにしたがって、スモール基地局210のRLCレイヤにユーザデータを送信する。
この場合、マクロ基地局110は、有線リンクを経由してスモール基地局210から送られてくる情報を用いてスモール基地局210のRLCレイヤに送信するユーザデータの配送量を決定する。有線リンクは、通信の品質によっては、情報の送信に遅延が発生するおそれがある。すなわち、有線リンクを経由してスモール基地局210から送られてくる情報が遅延するおそれがあり、遅延が発生した場合、マクロ基地局110は、スモール基地局210の送信状態に合わせたユーザデータの送信が適切に行えなくなるおそれがある。
これに対して、図11Bに示すように、本実施例に係る通信システムでは、スモール基地局200のMACレイヤは、PHYレイヤによって無線品質から決定されたデータサイズを取得する。そして、スモール基地局200のRLCレイヤは、MACレイヤから送信するデータサイズを取得し、そのデータサイズ分のユーザデータをMACレイヤに送信する。
また、移動局300のPDCPレイヤにおけるバッファのデータ滞留量を示す情報が、移動局300からマクロ基地局100に対して無線で送信される。そして、マクロ基地局100は、移動局300のPDCPレイヤにおけるバッファのデータ滞留量の情報から、ユーザデータの配送量を決定し、スモール基地局200のRLCレイヤにユーザデータを決定した配送量で送信する。
この場合、マクロ基地局100は、無線により移動局300から送られてくる情報を用いて、スモール基地局200のRLCレイヤに送信するユーザデータの配送量を決定する。無線は、通信品質の悪い有線リンクと比較して高速である。すなわち、本実施例に係る通信システムでは、マクロ基地局100は、スモール基地局200のRLCレイヤに送信するユーザデータの配送量を決定するための情報を、従来と比較して迅速に取得することができる。このため、本実施例に係るマクロ基地局100は、スモール基地局200の送信状態に合わせたユーザデータの送信を適切に行うことができる。
以上に説明したように、本実施例に係る無線通信システムは、2元接続において、移動局のバッファのデータ滞留量を用いて、プライマリの無線通信局からセカンダリの無線通信局に送信するユーザデータの配送量を決定する。これにより、プライマリ無線通信局は、プライマリの無線通信局からセカンダリの無線通信局へ適切な配送量でユーザデータを送信することができる。したがって、本実施例に係る無線通信システムによれば、無線通信局間の通信の効率を向上することができる。
また、既存の信号(シグナリング)であるPDCP Status Rreportを流用してバッファのデータ滞留量を通知するので、既存のシステムに対して少ない変更を加えるだけで、以上に説明した各種機能を実現することができる。すなわち、本実施例に係る無線通信システムは、容易に構築することができる。
(ハードウェア構成)
図12は、基地局のハードウェア構成図である。基地局は、例えば、図1の無線通信装置1及び2、並びに、図4に示すマクロ基地局100及びスモール基地局200などである。
基地局は、アンテナ901、制御部902、RF回路903、メモリ904、CPU905及びネットワークインタフェース906を有している。
制御部902は、例えば、図1及び図4に示す制御部14の機能を実現する。
ネットワークインタフェース906は、有線リンクによるネットワークを接続するためのインタフェースである。例えば、マクロ基地局100とスモール基地局200とは、ネットワークインタフェース906を介して有線リンクで接続される。
CPU905、メモリ904及びRF回路903は、図1及び図4に示す、受信部12及び送信部13を含む通信部11、並びに、受信部22及び送信部23を含む通信部21の機能を実現する。
例えば、メモリ904には、通信部11又は通信部21の機能を実現するためのプログラムなどの各種プログラムが格納されている。
CPU905は、メモリ904に格納されたプログラムを読み出し、RF回路903等と協働することで通信部11又は通信部21の機能を実現する。
図13は、移動局のハードウェア構成図である。移動局は、例えば、図1の無線通信装置3及び図4に示す移動局300などである。
移動局は、アンテナ911、制御部912、RF回路913、メモリ914及びCPU915を有する。
制御部912は、例えば、図1及び図4に示す制御部34の機能を実現する。
CPU915、メモリ914及びRF回路913は、図1及び図4に示す、受信部32及び送信部33を含む通信部31の機能を実現する。
例えば、メモリ914には、通信部31の機能を実現するためのプログラムなどの各種プログラムが格納されている。
CPU915は、メモリ914に格納されたプログラムを読み出し、RF回路913等と協働することで通信部31の機能を実現する。
(変形例)
以上の実施例2では、プライマリの基地局をマクロ基地局100として、セカンダリの基地局をスモール基地局200とした場合で説明した。ただし、基地局の構成はこれに限らない、例えば図14のようなシステム構成でも、本実施例に係る無線通信システムは動作できる。
図14は、実施例2の変形例に係る無線通信システムの2元接続の概略図である。本実施例に係る無線通信システムは、図1における無線通信装置1としてスモール基地局200Aを有する。また、図1における無線通信装置2としてスモール基地局200Bを有する。また、図1における無線通信装置3として移動局300を有する。
移動局300は、プライマリの基地局としてスモール基地局200Aに接続する。移動局300は、実線矢印で表される制御プレーン350及び破線矢印で表されるユーザプレーン351によりスモール基地局200Aと接続される。また、移動局300は、セカンダリの基地局としてスモール基地局200Bに接続する。移動局300は、ユーザプレーン351によりスモール基地局200Bと接続される。
図14のような無線通信システムの構成は、上り通信の特性改善のために採用されることが多い。
また、図14ではスモール基地局200はマクロ基地局100に接続しているが、スモール基地局200がマクロ基地局100の上位レイヤ通信装置に直接接続していてもよい。
次に、実施例5に係る無線通信システムについて説明する。本実施例に係る無線通信システムは、RLCフィードバック情報を用いてスモール基地局のRLCバッファのデータ滞留量を通知することが実施例2と異なる。
図17は、実施例5に係る無線通信システムにおいて各リンクレイヤを用いて実行されるユーザデータの送受信を表した図である。本実施例では、図17に示すように、マクロ基地局100において、RLCレイヤとMACレイヤとの間でデータプレーンを分離する場合を例に説明する。以下では、実施例2と同じ機能については説明を省略する。
マクロ基地局100の通信部11は、RLCレイヤ102の後で、データプレーンを分離し、スモール基地局200にユーザデータを送信する。この時、通信部11は、制御部14から指定された配送量でユーザデータを送信する。
制御部14は、2元接続開始時に、通信部11を介して、移動局300に対してRLCフィードバック情報であるRLC Status Reportの設定を通知する。
その後、制御部14は、2元接続実行中に送信したパケット数をカウンタで管理し、カウンタが一定の値になると、移動局300に送信するパケットにフラグを設定する。図18は、送信パケットのフォーマットの一例の図である。例えば、制御部14は、図18の送信パケット700のP(Pall)701のフラグを「1」に設定する。P701は、ポーリングコマンドを設定するビットである。制御部14は、フラグを設定したパケットを移動局300へ送信することで、RLC Status Reportの送信を移動局300に通知する。通常のデータでは、例えば、P701にはフラグとして「0」が設定されている。
また、制御部14は、送信したデータ量を算出し、送信したデータ量が所定値を超えると、カウンタが一定の値になった場合と同様にフラグを設定する。この場合、制御部14は、フラグを設定した後、送信したデータ量をクリアし、その後に送信したデータ量を算出することを繰り返す。
この他にも、RLC Status Reportの送信要求のタイミングは特に制限はなく、例えば、制御部14は、予め決められた一定周期でフラグを設定してもよい。
制御部14は、RLC Status Reportを通信部11から取得する。そして、制御部14は、RLC Status Reportから移動局300に受信されていない最も古いパケットのシーケンス番号を取得する。さらに、パケットの欠落が発生している場合には、制御部14は、分割されたパケットにおける欠落したパケットのシーケンス番号を取得する。
ここで、移動局300におけるバッファのデータ滞留量を示す情報を送信するためのRLC Status Reportについて説明する。図19は、RLC Status Reportのフォーマットを示す図である。RLC Status Report600は、ACK_SN601を含む。ACK_SN601は、次に未受信のRLC data PDUのシーケンス番号を示す。ただし、STATUS PDUにおいて未受信であることを通知していないRLC PDU(RLC data PDU)のシーケンス番号を表す。すなわち、一度STATUS PDUで「未受信」であることを報告してしまうと、そのシーケンス番号はACK_SN601としては設定されない。
また、RLC Status Report600は、NACK_SN602を含む。NACK_SN602は、AM RLCエンティティの受信側において喪失が検出されたAMD PDU(又はその一部)のシーケンス番号を表す。
さらに、SOstartは、AM RLCエンティティの受信側で喪失が検出されたシーケンス番号(NACK_SNであり、例えば、SOstartと関連するNACK_SN)を有するAMD PDUの一部を示す。また、SOendは、AM RLCエンティティの受信側で喪失が検出されたシーケンス番号(NACK_SNであり、例えば、SOendと関連するNACK_SN)を有するAMD PDUの一部を示す。
また、RLC Status Report600は、CPT(Carrier Packet Type)を含む。
図20は、CPTに格納される値と対応する内容を示す図である。図20に示すように、CPTの値が「001」であれば、セカンダリ接続のフィードバック情報を表す。また、CPTの値が「002」であれば、サードリ接続のフィードバック情報を表す。そして、CPTの値の「003」〜「111」は、リザーブである。本実施例では、RLC Status Report600のCPTには、「001」のビット列が格納される。
ただし、データ滞留量を示す情報の通知を表すために新たに別の値のCPTを指定することもできる。例えば、CPTとして「003」〜「111」のうちのいずれか一つを、移動局300のバッファにおけるデータ滞留量を表すものとして予め決めておき、データ滞留量を示す情報の通知の場合には、予め決めた値をCPTに格納してもよい。
制御部14は、取得したRLC Status Report600のCPTの値が予め決められた、移動局300におけるバッファのデータ滞留量を示す情報を送信するためのRLC Status Reportであることを表す値かを確認する。そして、制御部14は、ACK_SN601を確認し、移動局300に届いていない最も古いパケットのシーケンス番号を取得する。その後、制御部14は、移動局300に届いていない最も古いパケットのシーケンス番号以降のパケットを特定して、スモール基地局200のRLCバッファのデータ滞留量を求める。また、制御部14は、例えば、NACK_SN、SOstart、SOendで示される領域のバイト換算の総量を求めて、スモール基地局200のRLCバッファのデータ滞留量を求める。
図21は、データ滞留量の算出方法の一例を説明するための図である。図21において、斜線部分が、送達が確認できていないデータであるとする。RLC Status Reportを送信側が受信した場合次のように計算できる。
すなわち、RLC PDUの滞留量=(b1+h3)+(b4+h2)又は(SOend+h3)+(b4+h2)である。また、RLC SDUの滞留量=B1+B3である。また、PDCP PDUの滞留量=B1+B2である。また、PDCP SDUの滞留量=(B1−H1)+(B2−H2)である。
そして、制御部14は、スモール基地局200におけるバッファのデータ滞留量に応じたユーザデータの配送量を決定する。そして、制御部14は、決定した配送量を通信部11に通知する。なお、上記の滞留量のうち、ユーザデータの配送量の決定に用いる滞留量はどれを用いてもよい。
移動局300の制御部34は、2元接続開始時に、RLC Status Reportの設定をマクロ基地局100から受信する。そして、制御部34は、RLC Status Rportの通知を設定する。
そして、制御部34は、2元接続実行中に、RLC Status Reportの送信要求のフラグが設定されたパケットをマクロ基地局100から受信する。そして、制御部34は、受信しているパケットのシーケンス番号及び欠落が検出されたパケットのシーケンス番号を用いてRLC Status Reportを生成する。その後、制御部34は、生成したRLC Status Reportを通信部31を介してスモール基地局200へ送信してRLCフィードバックを行うとともに、RLC Status Reportをマクロ基地局100へ送信する。
次に、図22を参照して、RLC Status Reportの送信の全体的な流れを説明する。図22は、実施例3に係る無線通信装置におけるRLC Status Reportの送信の全体的な流れを説明するためのシーケンス図である。ここで、図22における状態801及び802はスモール基地局200のRLCバッファのデータ滞留状態を表している。さらに、状態801及802における矢印及びデータの記載はそのときにユーザデータがスモール基地局200のRLCバッファから出力されていることを表している。
マクロ基地局100は、RLC Status Reportの送信要求を行わないことを通知するために、フラグを「0」に設定したパケットを移動局300へ送信する(ステップS11)。さらに、マクロ基地局100は、ユーザデータをスモール基地局200へ送信する(ステップS12)。スモール基地局200は、移動局300へユーザデータを送信する(ステップS13)。
この時、スモール基地局200のRLCバッファには状態801のようにデータが蓄積される。そして、スモール基地局200のRLCバッファからはユーザデータが出力される。
その後、パケット数が一定の値を超えた場合又は送信データ量が閾値を超えた場合、マクロ基地局100は、RLC Status Reportの送信要求を通知するために、フラグを「1」に設定したパケットを移動局300へ送信する(ステップS14)。その後、マクロ基地局100は、ユーザデータのスモール基地局200への送信を継続する(ステップS15)。スモール基地局200は、移動局300へのユーザデータの送信を継続する(ステップS16)。
この時も、スモール基地局200のRLCバッファには状態802のようにデータが蓄積される。そして、スモール基地局200のRLCバッファからはユーザデータが出力される。
そして、移動局300は、フラグが「1」のパケットを受信すると、RLC Status Reportをマクロ基地局100へ送信する(ステップS17)。さらに、移動局300は、RLC Status Reportをスモール基地局200へ送信し、RLCフィードバックを行う(ステップS18)。
この後、マクロ基地局100は、受信したRLC Status Reportからスモール基地局200におけるRLCバッファのデータ滞留量を求め、求めたデータ滞留量に従いスモール基地局200へのデータの配送量を制御する。
以上に説明したように、本実施例に係るプライマリの無線通信局はRLC Status Reportを用いて通知されたセカンダリのRLCバッファのデータ滞留量に従って、セカンダリの無線通信局へのユーザデータの配送量を決定する。これにより、プライマリ無線通信局は、プライマリの無線通信局からセカンダリの無線通信局へ適切な配送量でユーザデータを送信することができる。したがって、本実施例に係る無線通信システムによれば、無線通信局間の通信の効率を向上することができる。
(変形例)
実施例5では、マクロ基地局100がフラグを設定したパケットを送信してRLC Status Reportの送信を要求した。しかし、これに限らず、例えば、スモール基地局200がフラグを設定したパケットを送信してRLC Status Reportの送信を要求してもよい。
この場合、スモール基地局200の制御部24が、実施例2のマクロ基地局100の制御部14と同様にパケット数やデータ送信量を監視して、フラグを設定するか否かを判定してもよい。
この他にも、実施例5と同様に、マクロ基地局100がフラグを設定するか否かを判定した上で、フラグを設定したパケットをスモール基地局200へ送信し、スモール基地局200がそのパケットを移動局300へ転送するようにしてもよい。
さらに、実施例5では、移動局300が無線でRLC Status Reportをマクロ基地局100へ送信したが、送信方法はこれに限らない。例えば、有線リンクを用いてRLC Status Reportをマクロ基地局100へ送信してもよい。
また、実施例5では、RLC Status Reportの送信要求のために、パケットのフォーマットとして従来から規定されているポーリングコマンドを用いたが送信要求の方法はこれに限らない。例えば、新規のポーリングコマンドを規定して送信要求を行ってもよい。
また、RLCレベルでのStatus Reportを実行させるのではなく、PDCP Status Reportingを移動局300に行わせることで、セカンダリの無線通信局のRLCバッファのデータ滞留量をマクロ基地局100に求めさせてもよい。
以上に開示した実施例は、発明の範囲を逸脱しない限り、それぞれを自由に組み合わせて実施してもよい。さらに、説明では下り通信を主としてそれに付随する上り通信についても説明してきたが、上り通信を主としそれに下り通信が付随する場合でも、同様に本実施例は実施できる。