図面 (/)

技術 無線ネットワーク制御装置、無線ネットワーク制御方法及び無線ネットワーク制御システム

出願人 富士通株式会社
発明者 東紘一郎畠山伸也杉崎秀行伊藤幹朗高島健岩佐賢
出願日 2010年3月17日 (9年8ヶ月経過) 出願番号 2010-061450
公開日 2011年10月6日 (8年1ヶ月経過) 公開番号 2011-199406
状態 特許登録済
技術分野 移動無線通信システム
主要キーワード 実施要求 コントロールパケット ネットワーク制御システム 最大転送速度 最大送信レート 各通信システム 送信元サーバ 過渡期
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2011年10月6日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (16)

課題

送信レート最大値が小さい通信ステムへのハンドオーバーにより発生する自装置の処理能力を超えるデータの送信を抑制する。

解決手段

バッファ11は、所定の蓄積容量を有し、外部装置から受信したデータを蓄積する。送信部12は、バッファ11からデータを読み出し移動端末へ送信する。送信レート決定部13は、バッファ11の空き容量を基に前記外部装置から自装置へのデータの送信レートを決定する。ウィンドウサイズ通知部14は、決定された送信レートに応じたウィンドウサイズを移動端末に通知する。

概要

背景

近年、無線通信における通話やデータ通信を行う移動通信システムとして、3G(3rd Generation)システム(第3世代移動通信システム)が用いられている。3Gシステムにおける下り送信レート最大値は14Mbpsである。ここで、下りの送信レートとは、送信元サーバなどのデータの送信元から移動端末へ向けたデータの送信レートを指す。

これに対し、無線通信における新たな移動通信システムとして、LTE(Long Term Evolution)システムの商用サービスが検討されている。LTEシステムにおける下りのデータの送信レートの最大値は100Mbpsである。LTEシステムでは、3Gシステムと比較して高い送信レートによるデータ転送が実現可能となる。

しかし、現在の移動通信システムを全てLTEシステムに変更するにはある程度の期間を必要とする。そのため、LTEシステムが全国規模に至るまでの過渡期として、図14に示すように、LTEシステム930と3Gシステム910とが共存する状態が発生することになる。図14は、共存する移動通信システムの模式図である。ここで、図14に示すように、3Gシステム910では、IPサービス網から送出されたデータは、xGSN(serving/gateway General packet radio service Support Node)912を介してRNC(Radio Network Controller)911に転送される。さらに、RNC911からBTS(Base Transceiver Station)913を介して移動端末であるUE(User Equipment)920に転送される。ここで、RNC911は無線ネットワーク制御装置である。以降、移動局をUEと呼ぶこともある。また、LTEシステム930では、IPサービス網から送出されたデータは、S‐GW(Serving - Gateway)931及びeNB(evolution Node B)932を介して、UE920に転送される。

図15は、LTEシステムから3Gシステムへの従来のハンドオーバーを説明するための概略構成図である。図15に示す送信元サーバ940は、UE920へのデータの送信元である。

図15に示す各通信システムにおいて、UE920は、RNC911との間のネットワークの状態などからウィンドウサイズを決定する。そして、UE920は、決定したウィンドウサイズを送信元サーバ940に通知する。UE920によるウィンドウサイズの通知を受けて、送信元サーバ940は、UE920が指定したウィンドウサイズに応じた送信レートで、RNC911へのデータの送信を行う。

ここで、図15のように、LTEシステム930と3Gシステム910とが共存する場合に、UE920がLTEシステム930の内から3Gシステム910の圏内に移動したとする。このとき、送信レートの最大値が100MbpsであるLTEシステム930から送信レートの最大値が14Mbpsである3Gシステム920へのハンドオーバーが発生することになる。

LTEシステム930から3Gシステム910へのハンドオーバーが発生した場合、S‐GW931によって、送信元サーバ940とUE920との間のデータの送信経路切り替えられる。そして、eNB932からUE920に送信中のパケット(Forwarding Data)がRNC911に転送される。また、LTEシステム930から3Gシステムへ910へのハンドオーバーが発生した後、送信元サーバ940からのパケット(Direct Data)がRNC911に送信されるようになる。このとき、送信元サーバ940は、送信レートが低い移動通信システムへのハンドオーバーが発生したことを認識することができない。そのため、LTEシステム930から3Gシステム910へのハンドオーバーが発生すると、RNC911は自己疎通能力以上のパケットを受信してしまうおそれがある。

ここで、RNC911はデータを溜めておくバッファを有している。RNC911は送信元サーバ940から受信したデータをバッファに一時的に蓄積する。そして、RNC911は、バッファに蓄積したデータをUE920へ送信する。RNC911がデータをUE920に送信することで、バッファに蓄積しているデータが減少する。すなわち、送信元サーバ940からのデータの受信及びUE920へのデータの送信により、バッファの空き容量が増減する。

そして、RNC911は、自己のバッファの空き容量が大きい場合には、UE920との間のデータの送信レートを低いレートとする。また、RNC911は、自己のバッファの空き容量が小さい場合には、UE920との間のデータの送信レートを高いレートとする。RNC911は、自己のバッファの中に蓄積しているデータを完全に無くさないようにするため、このようなUE920への送信レートの決定を行う。

ここで、LTEシステム930から3Gシステム910へのハンドオーバーが発生した時点で自己のバッファの空き容量が大きい状態にあると、RNC911はUE920との間の送信レートを低くする。UE920は、低い送信レートでRNC911からデータを受信することによりネットワークの負荷が高いと判定し、低い送信レートに応じたウィンドウサイズを送信元サーバ940へ送信する。そのため、RNC911は、バッファの空き容量が大きい状態にもかかわらず送信元サーバ940から低い送信レートでデータを受信することになる。これに対し、LTEシステム930から3Gシステム910へのハンドオーバーが発生した時点で自己のバッファの空き容量が小さい状態にあると、RNC911はUE920との間の送信レートを高くする。UE920は、高い送信レートでRNC911からデータを受信することによりネットワークの負荷が低いと判定し、高い送信レートに応じたウィンドウサイズを送信元サーバ940へ送信する。そのため、RNC911は、バッファの空き容量が小さい状態にもかかわらず送信元サーバ940から高い送信レートでデータを受信することになる。このように、従来の方法では、RNC911のバッファの空き容量と送信元サーバ940からRNC911へのデータの送信レートに齟齬が生じてしまう。

特にバッファの空き容量が小さい場合に、RNC911は送信元サーバ940から高い送信レートで送られてきたデータを受信することになる。加えて、RNC911は、eNB932からも転送パケットを受信することもある。これでは、RNC911においてデータのオーバーフローが発生するおそれがある。また、RNC911の内部で回線輻輳が発生したり、パケットの欠落が発生したりするおそれがある。

このように、RNC911においてデータのオーバーフローや回線輻輳などが生じると、ハンドオーバーを行ったUE920のスループットだけでなく、他のUE920のスループットも低下してしまう。そこで、ハンドオーバー後に送信元サーバ940からRNC911への転送レートを低下させることが望ましい。

従来、ハンドオーバー発生後に、送信元から送信される1つのデータに含まれる情報量を減少させることにより、ハンドオーバーによるデータ伝送遅延を回避する技術が提案されている。また、サーバクライアントの間のスループットを計測し、その計測結果に基づいてサーバからのデータの送信レートを制御する技術が提案されている。

概要

送信レートの最大値が小さい通信システムへのハンドオーバーにより発生する自装置の処理能力を超えるデータの送信を抑制する。バッファ11は、所定の蓄積容量を有し、外部装置から受信したデータを蓄積する。送信部12は、バッファ11からデータを読み出し移動端末へ送信する。送信レート決定部13は、バッファ11の空き容量を基に前記外部装置から自装置へのデータの送信レートを決定する。ウィンドウサイズ通知部14は、決定された送信レートに応じたウィンドウサイズを移動端末に通知する。

目的

開示の技術は、上記に鑑みてなされたものであって、自装置の処理能力を超えるデータの送信を抑制し、データの破棄などによるデータ送信完了の遅延を短縮する無線ネットワーク制御装置、無線ネットワーク制御方法及び無線ネットワーク制御システムを提供する

効果

実績

技術文献被引用数
0件
牽制数
2件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

所定の蓄積容量を有し、外部装置から受信したデータを蓄積するバッファと、前記バッファからデータを読み出し移動端末へ送信する送信部と、前記バッファの空き容量を基に前記外部装置から自装置へのデータの送信レートを決定する送信レート決定部と、前記送信レート決定部により決定された前記送信レートに応じたウィンドウサイズを前記移動端末に通知するウィンドウサイズ通知部とを備えたことを特徴とする無線ネットワーク制御装置

請求項2

第1の通信ステムから該第1の通信システムに比べて前記外部装置から前記移動端末へのデータの送信レートの最大値が小さい第2の通信システムへのハンドオーバーが発生したことを検知するハンドオーバー検知部と、前記送信レート決定部は、前記ハンドオーバー検知部がハンドオーバー発生を検知した場合に、送信レートの決定を行うことを特徴とする請求項1に記載の無線ネットワーク制御装置。

請求項3

前記送信レート決定部は、前記バッファの空き容量と前記送信レートとの対応関係を記憶しておき、前記バッファの現在の空き容量を取得し、前記対応関係を基に現在の空き容量に対応する前記送信レートを、前記外部装置から自装置へのデータの送信レートとして決定することを特徴とする請求項1又は請求項2に記載の無線ネットワーク制御装置。

請求項4

前記第1の通信システムがLTEシステムであり、前記第2の通信システムが3Gシステムであることを特徴とした請求項2又は請求項3に記載の無線ネットワーク制御装置。

請求項5

前記ウィンドウサイズ通知部は、コントロールパケットを用いて前記移動端末に前記ウィンドウサイズを通知することを特徴とする請求項1乃至4のいずれか一つに記載の無線ネットワーク制御装置。

請求項6

所定の容量を有するバッファに外部装置から受信したデータを蓄積するデータ蓄積テップと、前記バッファが蓄積しているデータを移動端末へ送信する送信ステップと、前記バッファの空き容量を基に前記外部装置から自装置へのデータの送信レートを決定する疎通レート決定ステップと、前記疎通レート決定ステップで決定した前記送信レートに応じたウィンドウサイズを前記移動端末に通知するウィンドウサイズ通知ステップとを備えたことを特徴とする無線ネットワーク制御方法

請求項7

無線ネットワーク制御装置、移動端末、及び送信元装置を含む無線ネットワーク制御システムであって、前記無線ネットワーク制御装置は、所定の蓄積容量を有し、前記送信元装置から受信したデータを蓄積するバッファと、前記バッファに蓄積されたデータを前記移動端末へ送信する送信部と、前記バッファの空き容量を基に前記外部装置から自装置へのデータの送信レートを決定する送信レート決定部と、前記送信レート決定部により決定された前記送信レートに応じたウィンドウサイズを前記移動端末に通知するウィンドウサイズ通知部と前記移動端末は、前記ウィンドウサイズの通知を前記ウィンドウサイズ通知部から受けて、該ウィンドウサイズを前記送信元装置へ通知する通知部を備え、前記送信元装置は、前記通知部から通知された前記ウィンドウサイズに基づく送信レートで前記無線ネットワーク制御装置へデータを送信するデータ送信部を備えることを特徴とする無線ネットワーク制御システム。

技術分野

背景技術

0002

近年、無線通信における通話やデータ通信を行う移動通信システムとして、3G(3rd Generation)システム(第3世代移動通信システム)が用いられている。3Gシステムにおける下り送信レート最大値は14Mbpsである。ここで、下りの送信レートとは、送信元サーバなどのデータの送信元から移動端末へ向けたデータの送信レートを指す。

0003

これに対し、無線通信における新たな移動通信システムとして、LTE(Long Term Evolution)システムの商用サービスが検討されている。LTEシステムにおける下りのデータの送信レートの最大値は100Mbpsである。LTEシステムでは、3Gシステムと比較して高い送信レートによるデータ転送が実現可能となる。

0004

しかし、現在の移動通信システムを全てLTEシステムに変更するにはある程度の期間を必要とする。そのため、LTEシステムが全国規模に至るまでの過渡期として、図14に示すように、LTEシステム930と3Gシステム910とが共存する状態が発生することになる。図14は、共存する移動通信システムの模式図である。ここで、図14に示すように、3Gシステム910では、IPサービス網から送出されたデータは、xGSN(serving/gateway General packet radio service Support Node)912を介してRNC(Radio Network Controller)911に転送される。さらに、RNC911からBTS(Base Transceiver Station)913を介して移動端末であるUE(User Equipment)920に転送される。ここで、RNC911は無線ネットワーク制御装置である。以降、移動局をUEと呼ぶこともある。また、LTEシステム930では、IPサービス網から送出されたデータは、S‐GW(Serving - Gateway)931及びeNB(evolution Node B)932を介して、UE920に転送される。

0005

図15は、LTEシステムから3Gシステムへの従来のハンドオーバーを説明するための概略構成図である。図15に示す送信元サーバ940は、UE920へのデータの送信元である。

0006

図15に示す各通信システムにおいて、UE920は、RNC911との間のネットワークの状態などからウィンドウサイズを決定する。そして、UE920は、決定したウィンドウサイズを送信元サーバ940に通知する。UE920によるウィンドウサイズの通知を受けて、送信元サーバ940は、UE920が指定したウィンドウサイズに応じた送信レートで、RNC911へのデータの送信を行う。

0007

ここで、図15のように、LTEシステム930と3Gシステム910とが共存する場合に、UE920がLTEシステム930の内から3Gシステム910の圏内に移動したとする。このとき、送信レートの最大値が100MbpsであるLTEシステム930から送信レートの最大値が14Mbpsである3Gシステム920へのハンドオーバーが発生することになる。

0008

LTEシステム930から3Gシステム910へのハンドオーバーが発生した場合、S‐GW931によって、送信元サーバ940とUE920との間のデータの送信経路切り替えられる。そして、eNB932からUE920に送信中のパケット(Forwarding Data)がRNC911に転送される。また、LTEシステム930から3Gシステムへ910へのハンドオーバーが発生した後、送信元サーバ940からのパケット(Direct Data)がRNC911に送信されるようになる。このとき、送信元サーバ940は、送信レートが低い移動通信システムへのハンドオーバーが発生したことを認識することができない。そのため、LTEシステム930から3Gシステム910へのハンドオーバーが発生すると、RNC911は自己疎通能力以上のパケットを受信してしまうおそれがある。

0009

ここで、RNC911はデータを溜めておくバッファを有している。RNC911は送信元サーバ940から受信したデータをバッファに一時的に蓄積する。そして、RNC911は、バッファに蓄積したデータをUE920へ送信する。RNC911がデータをUE920に送信することで、バッファに蓄積しているデータが減少する。すなわち、送信元サーバ940からのデータの受信及びUE920へのデータの送信により、バッファの空き容量が増減する。

0010

そして、RNC911は、自己のバッファの空き容量が大きい場合には、UE920との間のデータの送信レートを低いレートとする。また、RNC911は、自己のバッファの空き容量が小さい場合には、UE920との間のデータの送信レートを高いレートとする。RNC911は、自己のバッファの中に蓄積しているデータを完全に無くさないようにするため、このようなUE920への送信レートの決定を行う。

0011

ここで、LTEシステム930から3Gシステム910へのハンドオーバーが発生した時点で自己のバッファの空き容量が大きい状態にあると、RNC911はUE920との間の送信レートを低くする。UE920は、低い送信レートでRNC911からデータを受信することによりネットワークの負荷が高いと判定し、低い送信レートに応じたウィンドウサイズを送信元サーバ940へ送信する。そのため、RNC911は、バッファの空き容量が大きい状態にもかかわらず送信元サーバ940から低い送信レートでデータを受信することになる。これに対し、LTEシステム930から3Gシステム910へのハンドオーバーが発生した時点で自己のバッファの空き容量が小さい状態にあると、RNC911はUE920との間の送信レートを高くする。UE920は、高い送信レートでRNC911からデータを受信することによりネットワークの負荷が低いと判定し、高い送信レートに応じたウィンドウサイズを送信元サーバ940へ送信する。そのため、RNC911は、バッファの空き容量が小さい状態にもかかわらず送信元サーバ940から高い送信レートでデータを受信することになる。このように、従来の方法では、RNC911のバッファの空き容量と送信元サーバ940からRNC911へのデータの送信レートに齟齬が生じてしまう。

0012

特にバッファの空き容量が小さい場合に、RNC911は送信元サーバ940から高い送信レートで送られてきたデータを受信することになる。加えて、RNC911は、eNB932からも転送パケットを受信することもある。これでは、RNC911においてデータのオーバーフローが発生するおそれがある。また、RNC911の内部で回線輻輳が発生したり、パケットの欠落が発生したりするおそれがある。

0013

このように、RNC911においてデータのオーバーフローや回線輻輳などが生じると、ハンドオーバーを行ったUE920のスループットだけでなく、他のUE920のスループットも低下してしまう。そこで、ハンドオーバー後に送信元サーバ940からRNC911への転送レートを低下させることが望ましい。

0014

従来、ハンドオーバー発生後に、送信元から送信される1つのデータに含まれる情報量を減少させることにより、ハンドオーバーによるデータ伝送遅延を回避する技術が提案されている。また、サーバクライアントの間のスループットを計測し、その計測結果に基づいてサーバからのデータの送信レートを制御する技術が提案されている。

先行技術

0015

特開2004−153618号公報
特開2009−89416号公報

発明が解決しようとする課題

0016

しかし、データに含まれる情報量を減少させる従来技術は、実際のパケットの送信レートの変更は行わない。したがって、この従来技術を用いても、ハンドオーバー後に送信元から実際に送られてくるデータの送信レートはRNCの疎通能力を超えたままであり、RNCのオーバーフローを抑制することは困難である。

0017

また、ハンドオーバー後にRNCとUEとの間のスループットを計測し、その計測結果に基づいて送信元からのデータの送信レートを制御する従来技術を用いても、スループット計測に時間がかかるので、その間にRNCがオーバーフローするおそれがある。

0018

開示の技術は、上記に鑑みてなされたものであって、自装置の処理能力を超えるデータの送信を抑制し、データの破棄などによるデータ送信完了の遅延を短縮する無線ネットワーク制御装置、無線ネットワーク制御方法及び無線ネットワーク制御システムを提供することを目的とする。

課題を解決するための手段

0019

本願の開示する無線ネットワーク制御装置は、一つの態様において、バッファは、所定の蓄積容量を有し、外部装置から受信したデータを蓄積する。また、送信部は、前記バッファに蓄積されたデータを外部の移動端末へ送信する。送信レート決定部は、前記バッファの空き容量を基に前記外部装置から自装置へのデータの送信レートを決定する。そして、ウィンドウサイズ通知部は、前記送信レート決定部により決定された前記送信レートに応じたウィンドウサイズを前記移動端末に通知する。

発明の効果

0020

本願の開示する無線ネットワーク制御装置、無線ネットワーク制御方法及び無線ネットワーク制御システムの一つの態様によれば、自己のバッファの空き容量に応じた送信レートによる送信元装置からのデータの送信を確立できる。したがって、本願の開示する技術によれば、自装置の処理能力を超えるデータの送信を抑制でき、データの破棄などによるデータ送信完了の遅延を短縮できる。これにより、データの送信元と移動端末との間のスループットの低下を軽減することができるという効果を奏する。

図面の簡単な説明

0021

図1は、実施例1に係る無線ネットワーク制御装置のブロック図である。
図2は、実施例2に係る無線ネットワーク制御システムの概略構成図である。
図3は、実施例2に係る無線ネットワーク制御システムのブロック図である。
図4は、STATUSPDUフォーマットの一例の図である。
図5は、SUFIに格納されるデータの詳細を示す図である。
図6は、RNCの送信レート通知の処理のフローチャートである。
図7は、UEの送信レート通知の処理のフローチャートである。
図8は、ハンドオーバー発生時の各装置の処理のシーケンス図である。
図9は、RNCからUEへのデータの送信レートの変更を説明するためのシーケンス図である。
図10は、バッファの空き容量に応じた送信レートの変更を行わずにハンドオーバーの発生を契機に送信レートを下げた場合の送信レート変化を説明するためのシーケンス図である。
図11は、実施例2における送信元サーバとUEとの間のスループットの変化を従来の場合と比較するためのグラフである。
図12は、実施例2におけるハンドオーバー発生による回線帯域に対するパケット量と従来の場合との違いを説明するための図である。
図13は、ハンドオーバー発生を契機として送信レートを下げた場合と輻輳状態が発生してから送信レートを下げる場合とを比較するためのグラフである。
図14は、共存する移動通信システムの模式図である。
図15は、LTEシステムから3Gシステムへの従来のハンドオーバーを説明するための概略構成図である。

0022

以下に、本願の開示する無線ネットワーク制御装置、無線ネットワーク制御方法、及び無線ネットワーク制御システムの実施例を図面に基づいて詳細に説明する。なお、この実施例により本願の無線ネットワーク制御装置、無線ネットワーク制御方法、及び無線ネットワーク制御システムが限定されるものではない。

0023

図1は、実施例1に係る無線ネットワーク制御装置1のブロック図である。無線ネットワーク制御装置1は、バッファ11、送信部12、送信レート決定部13及びウィンドウサイズ通知部14を有している。

0024

バッファ11は、メモリなどの記憶装置である。そして、バッファ11は、データを記憶するための記憶容量として所定の容量を有する。バッファ11は、外部装置より受信した移動端末に送信するためのデータを記憶する。そして、バッファ11は、記憶したデータを蓄積していく。また、バッファ11が蓄積しているデータは、後述する送信部12によりデータが読み出されることで減少していく。

0025

送信部12は、バッファ11に蓄積されているデータを読み出し、外部の移動端末へ送信する。

0026

送信レート決定部13は、バッファ11の空き容量をバッファ11から取得する。そして、送信レート決定部13は、バッファ11の空き容量を用いて、外部装置から自装置へのデータの送信レートを決定する。以下では、送信レート決定部13が決定した外部装置から自装置へのデータの送信レートを「送信元送信レート」ともいう。送信レート決定部13は、送信元送信レートをウィンドウサイズ通知部14へ出力する。

0027

ウィンドウサイズ通知部14は、送信レート決定部13から送信元送信レートの入力を受ける。そして、ウィンドウサイズ通知部14は、送信元送信レートに応じたウィンドウサイズを求める。そして、ウィンドウサイズ通知部14は、送信元送信レートに応じたウィンドウサイズの情報を移動端末に通知する。

0028

上述したように、本実施例1に係る無線ネットワーク制御装置は、バッファの空き容量に応じた送信レートを外部装置からのデータの送信レートとして決定する。そして、無線ネットワーク制御装置は、決定した送信レートに応じたウィンドウサイズを移動端末に通知する。そして、外部装置は、移動端末からウィンドウサイズの通知を受けることで、無線ネットワーク制御装置が決定した送信レートで無線ネットワーク制御装置へデータの送信を行える。これにより、無線ネットワーク制御装置の処理能力を超えるデータの送信を抑制でき、データの破棄及び再送などによるデータ送信完了の遅延を短縮できる。

0029

また、バッファの空き容量に応じて外部装置からの送信レートを決定するため、短時間でバッファにデータを蓄積でき、バッファの空き容量を短時間で小さくすることができる。そのため、本実施例1に係る無線ネットワーク制御装置は、ハンドオーバー後に短時間で送信元装置から受信するデータの量に対してバランスの取れた送信レートでの移動端末へのデータの送信を確立できる。そして、データの送信元と移動端末との間のスループットの低下を軽減することができる。

0030

図2は、実施例2に係る無線ネットワーク制御システムの概略構成図である。まず、図2を参照して、本実施例2に係る無線ネットワーク制御システムのシステム構成及び動作の概要を説明する。

0031

図2に示すように、本実施例2に係る無線ネットワーク制御システムには、RNC100、UE2、送信元サーバ3、S‐GW4、xGSN5、eNB6及びBTS7が配置されている。そして、送信元サーバ3とS‐GW4とはIPサービス網8を介して接続されている。そして、S‐GW4及びeNB6がLTEシステムを構成し、RNC100、xGSN5及びBTS7が3Gシステムを構成している。ここで、LTEシステムは、下りの送信レートの最大値が100Mbpsである。また、3Gシステムは、下りの送信レートの最大値が14Mbpsである。LTEシステムが第1の通信システムの一例である。また、3Gシステムが第2の通信システムの一例である。

0032

まず、UE2がLTEシステムの通信領域に存在する場合のデータの流れを説明する。ここでは、UE2が初めからLTEシステムの通信領域に存在している場合、言い換えれば3GシステムからLTEシステムへのハンドオーバーが発生していない場合で説明する。

0033

送信元サーバ3は、UE2からウィンドウサイズの通知を受け取る。ここで、UE2は、100Mbpsの送信レートを最大値とするウィンドウサイズの指定を行う。そして、送信元サーバ3は、UE2から指定されたウィンドウサイズに応じた送信レートで、データをS‐GW4に送信する。具体的には、送信元サーバ3は、RNC100へデータを送信する際のウィンドウサイズをUE2から指定されたウィンドウサイズに設定することで送信レートを変更する。このとき、送信元サーバ3からの送信レートは、100Mbpsを最大値とする送信レートとなる。そして、S‐GW4は、IPサービス網8を介して送信元サーバ3から送信されたデータを受信する。そして、S‐GW4は、送信元サーバ3から受信したデータを、eNB6を介してUE2へ送信する。UE2は、送信元サーバ3が出力したデータをeNB6から受信する。

0034

次に、UE2が3Gシステムの通信領域に存在する場合のデータの流れを説明する。ここでは、UE2が初めからLTEシステムの通信領域に存在している場合、言い換えればLTEシステムから3Gシステムへのハンドオーバーが発生していない場合で説明する。

0035

送信元サーバ3は、UE2からウィンドウサイズの通知を受ける。ここで、UE2は、14Mbpsの送信レートを最大値とするウィンドウサイズの指定を行う。そして、送信元サーバ3は、UE2から指定されたウィンドウサイズに応じた送信レートで、データをS‐GW4に送信する。このとき、送信元サーバ3からの送信レートは、14Mbpsを最大値とする送信レートとなる。S‐GW4は、IPサービス網8を介して送信元サーバ3から送信されたデータを受信する。そして、S‐GW4は、送信元サーバ3から受信したデータをxGSN5へ送信する。xGSN5は、S‐GW4から受信したデータをRNC100へ送信する。RNC100は、xGSN5から受信したデータを、BTS7を介してUE2へ送信する。そして、RNC100は、自己が決定した送信レートでUE2に対してデータの送信を行う。UE2は、送信元サーバ3が出力したデータをBTS6から受信する。

0036

次に、UE2がLTEシステムの通信領域から3Gシステムの通信領域に移動し、LTEシステムから3Gシステムへのハンドオーバーが発生した場合を説明する。この場合、S‐GW4は、eNB6に向けてデータを送信する経路から、xGSN5に向けてデータを送信する経路に切り替える。ここで、ハンドオーバー発生時にeNB6がUE2へ送っているデータ、ハンドオーバー発生以前に送信元サーバ3がUE2に向けて送信したデータ、ハンドオーバー発生後に送信元サーバから送信されたデータの3種類のデータがある。この3種類のデータ毎に、ネットワーク制御システムの動作が異なるので、以下では3種類のデータ毎にネットワーク制御システムの動作を説明する。

0037

まず、ハンドオーバー発生時にeNB6がUE2へ送っているデータについて説明する。S‐GW4は、ハンドオーバーが発生したタイミングでeNB6がUE2に送っていたデータをxGSN5へ送信する。ここで、ハンドオーバーのタイミングでeNB6がUE2へ送っているデータの送信元サーバ3による送信レートは、LTEシステムの通信領域にUE2が存在したときのレートである。すなわち、この場合、送信レートがRNC100の疎通能力を超える送信レートである可能性がある。xGSN5は、S‐GW4から受信したデータをRNC100へ送信する。そして、RNC100は、xGSN5から受信したデータを、BTS7を介してUE2へ送信する。UE2は、送信元サーバ3が出力したデータをBTS7から受信する。

0038

次に、ハンドオーバー発生以前に送信元サーバ3がUE2に向けて送信したデータについて説明する。S‐GW4は、ハンドオーバー発生以前に送信元サーバ3がUE2に向けて送信したデータがある場合、IPサービス網8を介して送信元サーバ3から該データを受信する。ハンドオーバー発生以前に送信元サーバ3が送信したデータの送信レートは、LTEシステムの通信領域にUE2が存在したときのレートである。すなわち、この場合、送信レートは、RNC100の疎通能力を超える送信レートである可能性がある。そして、S‐GW4は、ハンドオーバー発生以前に送信元サーバ3がUE2に向けて送信したデータをxGSN5へ送信する。xGSN5は、S‐GW4から受信したデータをRNC100へ送信する。そして、RNC100は、xGSN5から受信したデータを、BTS7を介してUE2へ送信する。UE2は、送信元サーバ3が出力したデータをBTS7から受信する。

0039

最後に、ハンドオーバー発生後に送信元サーバ3から送信されたデータについて説明する。ハンドオーバー発生後、RNC100は、xGSN5を介してS‐GW4からハンドオーバー発生の通知を受ける。そして、RNC100は、自己のバッファの空き容量に対応した送信レートを決定し、決定した送信レートに応じたウィンドウサイズをUE2に通知する。この通信レートの決定は後に詳細を説明する。そして、UE2は、RNC100から指定されたウィンドウサイズを送信元サーバ3へ通知する。送信元サーバ3は、UE2から指定されたウィンドウサイズに応じた送信レートを求め、その求めた送信レートでS‐GW4へデータを送信する。この送信レートは、RNC100が決定した送信レートであり、RNC100の疎通能力を超えることはない。S‐GW4は、xGSN5に送信元サーバ3から受信したデータをxGSN5へ送信する。xGSN5は、S‐GW4から受信したデータをRNC100へ送信する。そして、RNC100は、xGSN5から受信したデータを、BTS7を介してUE2へ送信する。UE2は、送信元サーバ3が出力したデータをBTS7から受信する。

0040

次に、RNC100によるハンドオーバーの発生を契機としたウィンドウサイズの通知並びにその後のUE2及び送信元サーバ3の動作の詳細について説明する。図3は、実施例2に係る無線ネットワーク制御システムのブロック図である。ここで、実際には、図2に示すように、RNC100とUE2との間にはBTS7が存在する。ただし、図3では説明の都合上、BTS7を省略して記載している。以下の説明では、RNC100とUE2との間におけるデータの送受信は、BTS7を介して行われているものとする。

0041

データ送信部31は、UE2からのウィンドウサイズの通知をS‐GW4から受信する。具体的には、データ送信部31は、RNC100が指定したウィンドウサイズをヘッダに含むTCPパケットを受信し、そのTCPパケットからウィンドウサイズを取得する。そして、データ送信部31は、RNC100へデータを送信する際のウィンドウサイズをRNC100に指定されたウィンドウサイズに設定することで送信レートを変更する。そして、データ送信部31は、S‐GW4へ求めた送信レートでデータを送信する。

0042

S‐GW4は、xGSN5に送信元サーバ3から受信したデータを送信する。また、S‐GW4は、UE2においてLTEシステムから3Gシステムへのハンドオーバーが発生すると、LTEシステムから3Gシステムへのハンドオーバー発生の情報をxGSN5へ送信する。

0043

xGSN5は、S‐GW4から受信したデータをRNC100へ送信する。ここで、本実施例2では、xGSN5は、RNC100以外にも他のRNCと接続している。そして、UE2において他のRNCの通信領域からRNC100の通信領域へのハンドオーバーが発生した場合に、xGSN5は、そのハンドオーバーの実施要求をRNC100へ送信する。また、xGSN5は、LTEシステムから3Gシステムへのハンドオーバーの情報をS‐GW4から受信すると、LTEシステムから3Gシステムへのハンドオーバーの実施要求をRNC100へ送信する。

0044

本実施例2に係るRNC100は、図3に示すようにデータ転送部110、ハンドオーバー検知部103、送信レート決定部104及びウィンドウサイズ通知部105を有している。そして、データ転送部110は、バッファ101及び送信部102を有している。

0045

データ転送部110は、xGSN5からデータを受信する。そして、データ転送部110は、後述する送信部102を用いてUE2にデータを送信する。また、データ転送部110は、UE2からデータを受信する。そして、データ転送部110は、xGSN5へデータを送信する。また、データ転送部110は、通知部211からウィンドウサイズの通知を受ける。

0046

バッファ101は、メモリなどの記憶装置である。そして、バッファ101は、データを記憶するための記憶容量として所定の容量を有する。この記憶容量は、メモリサイズなどによって決まる。そして、バッファ101は、xGSN5から受信したデータを記憶する。バッファ101は、xGSN5から送られてくるデータを順次記憶していくことで蓄積していく。また、後述する送信部102によりデータが読み出されると、バッファ101が蓄積しているデータの量が減少する。バッファ101の記憶容量から蓄積しているデータの量を減算したものがバッファ101の空き容量である。すなわち、蓄積しているデータが多ければバッファ101の空き容量は小さくなり、蓄積しているデータが少なければバッファ101の空き容量は大きくなる。

0047

送信部102は、バッファ101からデータを読み出す。また、送信部102は、RNC100とUE2との間の回線の状態やバッファ101の空き容量などを用いて送信レートを決定する。例えば、送信部102は、バッファ101の空き容量が小さい場合に送信レートを上げ、バッファ101の空き容量が大きい場合に送信レートを下げるなどして、送信レートを決定する。そして、送信部102は、バッファ101から読み出したデータをUE2へ送信する。このとき、送信部102は、自己が決定した送信レートで送信を行う。

0048

ハンドオーバー検知部103は、ハンドオーバーの実施要求をxGSN5から受信する。そして、ハンドオーバー検知部103は、xGSN5から受信したハンドオーバーの実施要求がLTEシステムから3Gシステムへのハンドオーバーか否かを判定する。そして、ハンドオーバー検知部103は、ハンドオーバーの実施要求がLTEシステムから3Gシステムへのハンドオーバーであった場合、LTEシステムから3Gシステムへのハンドオーバーの発生を検知する。そして、ハンドオーバー検知部103は、LTEシステムから3Gシステムへのハンドオーバーの発生の情報を送信レート決定部104へ出力する。

0049

送信レート決定部104は、メモリやハードディスクなどの記憶媒体を有している。そして、送信レート決定部104は、バッファ101の空き容量と送信レートとの対応関係を記憶している。ここで、本実施例2では、送信レート決定部104は、以下のような対応関係が記載されたテーブルを記憶している。例えば、バッファ101の空き容量が全体の20%未満の場合はウィンドウサイズが10となる送信レートである。ここで、ウィンドウサイズが10となる送信レートとは、3Gシステムにおける送信レートの最大値と比較して十分低い送信レートである。また、バッファ101の空き容量が全体の20%以上80%未満の場合はウィンドウサイズが50となる送信レートである。ここで、ウィンドウサイズが50となる送信レートとは、3Gシステムにおける送信レートの最大値と比較しておよそ半分の送信レートである。また、バッファ101の空き容量が全体の80%以上の場合はウィンドウサイズが100となる送信レートである。ここで、ウィンドウサイズが100となる送信レートとは、3Gシステムにおける送信レートの最大値と比較して最大値に近い送信レートである。

0050

ここで、本実施例2では、送信レートの決定を容易にするため、送信レート決定部104は、バッファ101と送信レートとの対応関係としてバッファ101の空き容量の割合と送信レートとを対応させたテーブルを記憶している。しかし、バッファ101と送信レートとの対応関係は、バッファ101の空き容量から送信レートが求められるものであれば特に制限はない。例えば、バッファ101と送信レートとの対応関係としては、バッファ101の空き容量に送信レートを比例させた計算式などでも良い。

0051

送信レート決定部104は、LTEシステムから3Gシステムへのハンドオーバーの発生の情報を受信すると、バッファ101から現在のバッファ101の空き容量を取得する。送信レート決定部104は、バッファ101に現在蓄積されているデータの量を取得し、バッファ101の記憶容量から減算して現在のバッファ101の空き容量を求めても良い。

0052

そして、送信レート決定部104は、自己が記憶しているバッファ101の空き容量と送信レートとの対応関係のテーブルから現在のバッファ101の空き容量に対応する送信レートを取得する。そして、送信レート決定部104は、現在のバッファ101の空き容量に対応する送信レートを送信元サーバ3によるデータの送信レートとして決定する。例えば、現在のバッファ101の空き容量が10%であった場合、送信レート決定部104は、対応関係のテーブルからウィンドウサイズが10となる送信レートを取得する。そして、送信レート決定部104は、ウィンドウサイズが10となる送信レートを送信元サーバ3によるデータの送信レートとして決定する。以下では、送信レート決定部104が送信元サーバ3によるデータの送信レートとして決定した送信レートを「送信元送信レート」ともいう。

0053

送信レート決定部104は、送信元送信レートをウィンドウサイズ通知部105へ出力する。ここで、ウィンドウサイズと送信レートとは一対一の関係にあるので、送信レート決定部104は、送信元送信レートとしてウィンドウサイズをウィンドウサイズ通知部105へ出力しても良い。

0054

ウィンドウサイズ通知部105は、送信元送信レートの入力を送信レート決定部104から受ける。そして、ウィンドウサイズ通知部105は、送信元送信レートに応じたウィンドウサイズを求める。例えば、ウィンドウサイズ通知部105が、送信元送信レートとしてウィンドウサイズが10となる送信レートを送信レート決定部104から受信したとする。この場合、ウィンドウサイズ通知部105は、送信元送信レートに対応するウィンドウサイズとして10を取得する。ここで、ウィンドウサイズ通知部105によるウィンドウサイズの求め方は他の方法を用いても良い。例えば、ウィンドウサイズ通知部105に記憶媒体を配置し、ウィンドウサイズ通知部105に、送信レートからウィンドウサイズを求める計算式を記憶させておく。そして、ウィンドウサイズ通知部105は、送信元送信レートを記憶している計算式にあてはめることで送信元送信レートに応じたウィンドウサイズを算出しても良い。

0055

ウィンドウサイズ通知部105は、送信元送信レートに応じたウィンドウサイズをUE2のTCPWindowサイズ通知部221に通知する。ここで、ウィンドウサイズ通知部105によるTCPWindowサイズ通知部221へのウィンドウサイズの通知の一例を説明する。

0056

まず、ウィンドウサイズ通知部105は、メモリなどの記憶媒体を有する。そして、ウィンドウサイズ通知部105は、ウィンドウサイズを通知するためのTCPパケットのフォーマットを予め記憶している。以下では、ウィンドウサイズを通知するためのTCPパケットを「TCPWindowサイズパケット」ともいう。そして、ウィンドウサイズ通知部105は、記憶しているTCPWindowサイズパケットのフォーマットを用いて、送信元送信レートに応じたウィンドウサイズを含むTCPWindowサイズパケットを生成する。

0057

ここで、ウィンドウサイズ通知部105が生成するTCPWindowサイズパケットの一例を説明する。ここでは、ウィンドウサイズ通知部105がTCPWindowサイズパケットとしてSTATUSPDU(Protocol Data Unit)を生成した場合を説明する。STATUS PDUとは、TCP/IPにおいて送達確認やウィンドウサイズなどのプロトコル情報送受するために使用されるデータである。そして、STATUS PDUは、RNC100とUE2との間の無線リンクの制御を行うRLC(Radio Link Control)パケットの一つである。図4は、STATUS PDUのフォーマットの一例の図である。図4に示すように、フォーマット200は、PDUの種別などを表す情報としてD/C及びPDU Typeを有する。また、フォーマット200は、SUFI(Super-Field)1〜k(kは1以上の自然数)で表されるパラメータを有する。SUFIは4の整数倍で示すことができるデータである。図5は、SUFIに格納されるデータの詳細を示す図である。例えば、図5に示すAcknowledgement(ACK)301が送達確認のデータである。SUFI1〜kのそれぞれに、図5に示す各データが格納される。そして、SUFIは、格納するデータの量に応じて追加されていく。例えば、図5のACK301のデータだけを格納する場合には、SUFI1だけが用いられる。また、ACK301の他にReserved302などといったデータを格納する場合には、格納するデータの量に合わせてSUFI2、SUFI3とSUFIが順次追加されていく。

0058

ウィンドウサイズ通知部105は、図4に示すSTATUSPDUのフォーマット200を記憶している。そして、ウィンドウサイズ通知部105は、STATUS PDUのフォーマット200を用いて送信元送信レートに応じたウィンドウサイズをヘッダに含むSTATUS PDUを生成する。具体的には、ウィンドウサイズ通知部105は、図5のReserved302の先頭4bitでTCP_WINDOWを表し、その後に続く16bitで送信元送信レートに応じたウィンドウサイズを表す情報をSUFIに格納させ、そのSUFIを含むSTATUS PDUを生成する。ウィンドウサイズ通知部105は、生成したSTATUS PDUを送信元サーバ3へ送信することで、送信元送信レートに応じたウィンドウサイズを通知することができる。

0059

UE2は、送信部21及び受信部22を有している。そして、送信部21は、通知部211及びTCPパケット生成部212を有している。また、受信部22は、TCPWindowサイズ通知部221を有している。

0060

受信部22は、送信元サーバ3や他の移動端末から出力されたデータをデータ転送部110から受信する。受信部22が受信するデータには、RLCパケットなどが含まれている。

0061

TCPWindowサイズ通知部221は、ウィンドウサイズ通知部105から送信元送信レートに応じたウィンドウサイズの通知を受ける。本実施例2では、TCPWindowサイズ通知部221は、受信部22がRLCパケットを受信した場合、そのRLCパケットがTCPWindowサイズパケットか否かを判定する。そして、RLCパケットがTCPWindowサイズパケットの場合、TCPWindowサイズ通知部221は、そのTCPWindowサイズパケットからウィンドウサイズを取得する。本実施例ではこのようにして、TCPWindowサイズ通知部221がウィンドウサイズ通知部105から送信元送信レートに応じたウィンドウサイズの通知を受ける。そして、TCPWindowサイズ通知部221は、送信元送信レートに応じたウィンドウサイズを通知部211のTCPパケット生成部212へ出力する。

0062

送信部21は、送信元サーバ3や他の移動端末へのデータをRNC100のデータ転送部110へ送信する。

0063

TCPパケット生成部212は、送信元送信レートに応じたウィンドウサイズの入力をTCPWindowサイズ通知部221から受ける。そして、TCPパケット生成部212は、送信元送信レートに応じたウィンドウサイズをヘッダに含むTCPパケットを生成する。

0064

通知部211は、TCPパケット生成部212が生成した送信元送信レートに応じたウィンドウサイズをヘッダに含むTCPパケットをRNC100のデータ転送部110へ送信する。通知部211から送信されたTCPパケットは、RNC100、xGSN5及びS‐GW4を介して送信元サーバ3へ送信される。これにより、通知部211は、送信元送信レートに応じたウィンドウサイズを送信元サーバ3に通知することができる。

0065

次に、図6を参照して、ハンドオーバー発生時のRNC100による送信元サーバ3の送信レート通知の処理の流れを説明する。ここで、図6は、ハンドオーバー発生時のRNC100による送信元サーバ3の送信レート通知の処理を表すフローチャートである。

0066

ハンドオーバー検知部103は、xGSN5からのハンドオーバーの実施要求があるまで待機する(ステップS101否定)。

0067

xGSN5からハンドオーバーの実施要求があると(ステップS101肯定)、ハンドオーバー検知部103は、xGSN5から通知されたハンドオーバーがLTEシステムからのハンドオーバーか判定する(ステップS102)。

0068

xGSN5から通知されたハンドオーバーが3Gシステム内でのハンドオーバーの場合(ステップS102否定)、RNC100は、送信元サーバ3の送信レート設定の処理を終了する。

0069

これに対し、xGSN5から通知されたハンドオーバーがLTEシステムからのハンドオーバーの場合(ステップS102肯定)、送信レート決定部104は、バッファ101から現在のバッファ101の空き容量を取得する(ステップS103)。

0070

そして、送信レート決定部104は、バッファ101と送信レートの対応関係から、現在のバッファ101の空き容量に対応する送信元サーバの送信レート(送信元送信レート)を決定する(ステップS104)。

0071

ウィンドウサイズ通知部105は、送信レート決定部104が決定した送信元送信レートの入力を受けて、送信元送信レートに応じたウィンドウサイズの情報を含むTCPWindowサイズパケットを生成する(ステップS105)。

0072

そして、ウィンドウサイズ通知部105は、送信元送信レートに応じたウィンドウサイズの情報を含むTCPWindowサイズパケットをUE2のTCPWindowサイズ通知部221へ送信する(ステップS106)。

0073

次に、図7を参照して、ハンドオーバー発生時のUE2による送信元サーバ3の送信レート通知の処理の流れを説明する。ここで、図7は、ハンドオーバー発生時のUE2による送信元サーバ3の送信レート通知の処理を表すフローチャートである。

0074

受信部22は、送信部102又はウィンドウサイズ通知部105から、RLCパケットを受信する(ステップS201)。

0075

TCPWindowサイズ通知部221は、受信部22が受信したRLCパケットがTCPWindowサイズパケットか否かを判定する(ステップS202)。ここで、受信部22が受信したRLCパケットがTCPWindowサイズパケットでない場合(ステップS202否定)、UE2は、送信元サーバ3の送信レート通知の処理を終了する。

0076

これに対し、受信部22が受信したRLCパケットがTCPWindowサイズパケットの場合(ステップS202肯定)、TCPWindowサイズ通知部221は、TCPWindowサイズパケットから送信元送信レートに対応するウィンドウサイズを取得する。そして、TCPWindowサイズ通知部221は、送信元送信レートに対応するウィンドウサイズをTCPパケット生成部212に送信する。

0077

TCPパケット生成部212は、RNC100により送信元送信レートに対応するウィンドウサイズとして指定されたウィンドウサイズをTCPヘッダに設定し(ステップS203)、TCPパケットを生成する。

0078

通知部211は、TCPパケット生成部212が生成した送信元送信レートに対応するウィンドウサイズをヘッダに含むTCPパケットを送信元サーバ3に向けて送信する(ステップS204)。

0079

次に、図8を参照して、LTEシステムから3Gシステムへのハンドオーバー発生時の各装置の動作の流れを説明する。図8は、ハンドオーバー発生時の各装置の処理のシーケンス図である。図8縦軸は下に向かって時間の経過を表している。そして、各縦軸は上部に記載された各装置における動作を表している。

0080

まず、LTEシステムの通信範囲にUE2が存在する場合には、送信元サーバ3からUE2へは最大100Mbpsの送信レートでデータの送信が行われている(ステップS301)。

0081

ここで、LTEシステムから3Gシステムへのハンドオーバーが発生する(ステップS302)。具体的には、UE2の基地局がeNB6からRNC100へ変更させる。

0082

ハンドオーバー検知部103は、LTEシステムから3Gシステムへのハンドオーバーの発生を検知すると、送信レート決定部104へそのハンドオーバー発生の情報を送信する(ステップS303)。

0083

送信レート決定部104は、バッファ101の空き容量に応じて送信元送信レートを決定する(ステップS304)。そして、送信レート決定部104は、ウィンドウサイズ通知部105に決定した送信元送信レートを出力する(ステップS305)。

0084

ウィンドウサイズ通知部105は、送信元送信レートに応じたウィンドウサイズを求め、そのウィンドウサイズを含むTCPWindowサイズパケットをUE2へ送信する(ステップS306)。

0085

TCPWindowサイズ通知部221は、RNC100から受信したRLCパケットがTCPWindowサイズパケットの場合、そのTCPWindowサイズパケットからウィンドウサイズを取得し、そのウィンドウサイズをTCPパケット生成部212に出力する(ステップS307)。

0086

TCPパケット生成部212は、RNC100から指定されたウィンドウサイズをヘッダに含むTCPパケットを生成する(ステップS308)。

0087

そして、通知部211は、TCPパケット生成部212が生成したTCPパケットをRNC100を介して送信元サーバ3へ送信する(ステップS309)。

0088

送信元サーバ3は、通知部211から受信したTCPパケットからウィンドウサイズを取得し、RNC100へデータを送信する際のウィンドウサイズを取得したウィンドウサイズに設定することで送信レートを変更する(ステップS310)。

0089

この後、送信元サーバ3からUE2へは最大値14Mbpsの送信レートでデータの送信が行われる(ステップS311)。

0090

次に、図9を参照して、LTEシステムから3Gシステムへのハンドオーバー発生後のRNC100からUE2へのデータの送信レートの変化について説明する。図9は、RNC100からUE2へのデータの送信レートの変化について説明するためのシーケンス図である。また、図9に示す直方体はRNC100のバッファ101を示している。そして、バッファ101の2分割された上部はバッファ101の空き容量を示し、バッファ101の2分割された下部はバッファ101のデータの蓄積量を示している。

0091

まず、LTEシステムから3Gシステムへのハンドオーバーが発生する。すると、RNC100はバッファ101の空き容量に応じた送信元送信レートを決定し、その送信元送信レートに応じたウィンドウサイズをUE2に通知する(ステップS401)。ここで、ハンドオーバー時にRNC100のバッファ101は図9に示すような状態にあるとする。すなわち、バッファ101の記憶容量に対して少ない量の蓄積データ112が蓄積されている。この場合、バッファ101の空き容量111は大きい状態である。このため、RNC100は、送信元送信レートを3Gシステムの送信レートのうちの高い送信レートに決定することになる。

0092

UE2は、RNC100に指定されたウィンドウサイズを送信元サーバ3へ通知する(ステップS402)。

0093

送信元サーバ3は、UE2から通知されたウィンドウサイズに応じた送信レートを求め、その送信レートでRNC100へデータの送信を行う(ステップS403)。ここで、ステップS301で送信元送信レートが高い送信レートとして決定されているので、送信元サーバは単位時間当たり多くのデータをRNC100に送信することになる。

0094

RNC100は、空き容量111のようにバッファの空き容量が大きい状態では、UE2に対し低い送信レートでデータの送信を行う(ステップS404)。

0095

このとき、RNC100は送信元サーバ3から高い送信レートでデータを受信するので、バッファ101には、短時間で蓄積データ114のようにデータが蓄積していく。この場合、バッファ101の空き容量113は小さくなる。空き容量113のように空き容量が小さくなると、RNC100は、UE2へのデータの送信レートを上昇させる(ステップS405)。

0096

さらに、バッファ101の空き容量は空き容量115のように小さくなる。これを受けて、RNC100は、UE2へのデータの送信レートを上昇させる(ステップS406)。

0097

そして、UE2へのデータの送信レートの上昇を繰り返すことで、RNC100は、短時間で送信元サーバ3からのデータの受信とバランスの取れたUE2へのデータの送信レートを確立することができる(ステップS407)。このバランスの取れた送信レートを図9では「最適レート」と記載している。

0098

このように、本実施例2ではLTEシステムから3Gシステムへのハンドオーバーが発生したときに、バッファ101の空き容量が大きい場合、送信元サーバ3からのデータの送信レートが高くなる。そのため、図9点線400で囲われた部分で示すように、バッファ101には短時間でデータが蓄積していき、空き容量が小さくなる。これに対応して、点線401で囲われた部分で示すように、RNC100からUE2への送信レートが短時間で上昇する。これにより、RNC100は、短時間で送信元サーバ3からのデータの受信とバランスの取れたUE2へのデータの送信レートを確立することができる。

0099

ここで、バッファ101の空き容量に応じた送信レートの設定を行わずに、送信元サーバ3からの送信レートの決定は従来のままで、ハンドオーバーの発生を契機に送信レートを所定値まで単に下げた場合について図10を参照して説明する。図10は、バッファの空き容量に応じた送信レートの決定を行わずにハンドオーバーの発生を契機に送信レートを所定値まで下げた場合の送信レート変化を説明するためのシーケンス図である。図10の縦軸は下に向かって時間の経過を表す。そして、各縦軸はそれぞれの上部に記載されたRNC810、UE820又は送信元サーバ830の各装置の経時的な動作を表している。そして、各縦軸間を結ぶ矢印はデータの各装置間のデータの流れを表しており、矢印の太さがデータの送信レートを表している。

0100

まず、ハンドオーバーが発生すると、RNC810はUE820に対しハンドオーバー制御を行う。すなわち、RNC810は、送信元サーバ830のデータの送信レートを予め決められた所定の送信レートにするよう、UE820に対し所定の送信レートに応じたウィンドウサイズを通知する(ステップS801)。ここで、所定の送信レートは、RNC810と送信元サーバ830との間のデータの送信レートの最大値に比べて十分に低い送信レートである。以下の説明での「最大送信レート」とは送信元サーバ830からRNC810への間のデータの送信レートの最大値を指すものとする。

0101

UE820は、所定の送信レートに応じたウィンドウサイズを送信元サーバ830に通知する(ステップS802)。

0102

送信元サーバ830は、指定されたウィンドウサイズに従って所定の送信レートでRNC810に対してデータを送信する(ステップS803)。以下では、RNC810が送信元サーバ830からデータを受信した時点で、図10に示すようにRNC810のバッファ811の空き容量812が大きい場合で説明する。この場合、バッファ811のデータの蓄積データ813は少ない状態である。

0103

RNC810は、所定の送信レートでUE820に対しデータを送信するとともに、空き容量812が大きいので、UE820との間のデータの送信レートを維持する(ステップS804)。そして、送信元サーバ830からのデータの送信レートが低い状態であるので、バッファ811の空き容量は大きい状態が継続する。そのため、RNC810は、最大転送速度に比べて低い送信レートでUE820に対しデータを送信する(ステップS805)。

0104

そして、RNC810は、蓄積データ815のようにデータの蓄積量が増え、バッファ811の空き容量814が小さくなってくると、UE820に対する送信レートを上げる。UE820は、RNC810からの受信状況に応じてウィンドウサイズを決定し、送信元サーバ830にRNC810を介してウィンドウサイズを送信する。そして、送信元サーバ830は、UE820から受信したウィンドウサイズに応じた送信レートを用いてRNC810に対しデータの送信を行う(ステップS806)。

0105

RNC810は、空き容量816の様に空き容量が小さくなると、より高い送信レートでUE820に対してデータを送信する(ステップS807)。また、RNC810は、送信元サーバ830からの送信レートも上昇させる。これにより、送信元サーバ830は、上昇させた送信レートでRNC810に対してデータの送信を行う(ステップS808)。

0106

これを繰り返し、最終的にRNC810は、送信元サーバ830から受信するデータの量に対してバランスの取れた送信レート(最適レート)でUE820に対してデータの送信を行う(ステップS809)。

0107

このように、送信レートを下げてから徐々に上げていく場合で、バッファ811の空き容量を考慮せずに送信元サーバ830からの送信レートを決定すると、バッファ811の空き容量が大きい場合にはRNC810からUE820への送信レートが低く抑えられてしまう。そのため、図10の点線851で囲われた部分で示されるように、バッファ811にデータが十分に貯まるまでに時間がかかってしまう。そのため、点線852で囲われた部分で示されるように、RNC810とUE820との間のデータの送信レートを送信元サーバ830から受信するデータの量に対してバランスの取れた送信レート(最適レート)に上げるまでに時間がかかってしまう。

0108

したがって、実施例2のように、ハンドオーバーの発生を契機に送信レートを下げる場合には、バッファ101の空き容量を考慮して送信元サーバ3からの送信レートを決定することが好ましい。これにより、RNC100は、UE2との間の送信レートを、送信元サーバ3から受信するデータの量に対してバランスの取れた送信レートに短時間で確立することができる。

0109

次に、図11を参照して、実施例2における送信元サーバ3とUE2との間のスループットの変化と、従来技術を用いた場合の送信元サーバ3とUE2との間のスループットの変化とを比較する。図11は、実施例2における送信元サーバとUEとの間のスループットの変化を従来の場合と比較するためのグラフである。図11のグラフは、横軸時間経過とし、縦軸を送信元サーバ3とUE2との間のスループットの値としている。

0110

図11実線で表されるグラフ500が実施例2における送信元サーバ3とUE2との間のスループットの変化を表すグラフである。また、図11の点線で表されるグラフ501が従来方式による送信元サーバ3とUE2との間のスループットの変化を表すグラフである。そして、一点鎖線502がLTEシステムから3Gシステムへのハンドオーバー発生のタイミングを表している。そして、以下の説明では、図11でハンドオーバーが発生したタイミングにおいて、バッファの空き容量が大きい場合で説明する。

0111

点503で示すタイミングで送信元からの送信レートが変更される。従来方式では、バッファの空き容量が大きいとRNC100とUE2の間の送信レートがなかなか上昇しない。そのため、RNC100とUE2とを含む送信元サーバ3とUE2との間のスループットもグラフ501のように徐々にしか上昇しない。これに対し、実施例2の方法によれば、短時間でバッファに多くのデータを蓄積させることができるため、RNC100とUE2との間のスループットの短時間で上昇させることができる。これにより、実施例2に係る無線ネットワーク制御システムでは、点504で表されるように、送信元サーバ3とUE2との間の送信レートを従来方式に比べて短時間で上昇させることができる。

0112

さらに、図12を参照して、実施例2におけるLTEシステムから3Gシステムへのハンドオーバー発生後の回線帯域に対するパケット量を、従来技術を用いた場合と比較する。図12は、実施例2におけるハンドオーバー発生による回線帯域に対するパケット量と従来の場合との違いを説明するための図である。図12紙面に向かって上側が従来技術を用いた場合のLTEシステムから3Gシステムへのハンドオーバー発生後の回線帯域に対するパケット量を表す図である。また、図12の紙面に向かって下側が実施例2の方法を用いた場合のLTEシステムから3Gシステムへのハンドオーバー発生後の回線帯域に対するパケット量を表す図である。そして、帯域601と帯域603が3Gシステムにおける回線帯域を表している。そして、ユーザA、ユーザB、ユーザCはそれぞれ、各ユーザが自分のUE2で受信するパケットの量を表している。

0113

従来の方法及び実施例2の方法のいずれの場合も、ハンドオーバー発生時にユーザA及びユーザBが回線帯域をすでに図12に示す量だけ使用しているものとする。そして、ユーザCのUE2においてLTEシステムから3Gシステムへのハンドオーバーが発生したものとする。

0114

従来技術ではハンドオーバー発生を契機に送信レートの変更は行われないため、ユーザCのUE2は送信元サーバ3から処理能力以上のパケットを受信してしまう。そのため、パケット量602のように、RNC100は、帯域601を超えるパケット量を受信することになる。これにより、ユーザA及びユーザBのUE2に対してもパケットの欠落などの影響が発生するおそれがある。

0115

これに対し、実施例2に係る無線ネットワーク制御システムでは、ハンドオーバーの発生を契機に送信レートの変更を行うため、ユーザCが使用するUE2は処理能力に応じたパケットを受信することになる。そのため、RNC100は、最大でもパケット量604のように帯域603の範囲に収まるパケットを受信することになる。これにより、ユーザAやユーザBのUE2に対しての影響を軽減することができる。

0116

次に、実施例2における機能の一部であるハンドオーバーの発生を契機とした送信レートの変更に注目して、その効果について説明を行う。そこで、図13を参照して、LTEシステムから3Gシステムへのハンドオーバー発生を契機として送信レートを下げた場合の送信元サーバとUEとの間の送信レートの変化と、輻輳状態が発生してから送信元サーバの送信レートを変更する場合とを比較する。図13は、ハンドオーバー発生を契機として送信レートを下げた場合と輻輳状態が発生してから送信レートを下げる場合とを比較するためのグラフである。図13のグラフは横軸を時間経過とし、縦軸をRNC100とUE2との間の送信レートの値としたものである。ただし、図13において、ハンドオーバーの発生を契機に送信レートを低下させることによる効果を示すため、実施例2におけるバッファの空き容量に応じてウィンドウサイズを決定することで送信元の送信レートを低下させる機能は考慮しないものとする。以下の説明におけるハンドオーバーとは、LTEシステムから3Gシステムへのハンドオーバーを指すものとする。

0117

点線で表されるグラフが、輻輳状態が発生してから送信元サーバの送信レートを変更する場合における、ハンドオーバー発生後のRNCとUEとの間の送信レートの変化を表すグラフである。実線で表されるグラフが、LTEシステムから3Gシステムへのハンドオーバー発生を契機として送信レートを下げた場合の、ハンドオーバー発生後のRNCとUEとの間の送信レートの変化を表すグラフである。

0118

ハンドオーバー発生を契機として送信レートを下げる場合では、RNC100はハンドオーバーの発生を契機に、送信元サーバ3の送信レートを低下させ送信レート700に変更する。そして、RNC100は、バッファ101の空き容量に応じて送信レートを上昇させるために一定期間送信レートを維持する。そのため、期間701のように、送信元サーバ3とUE2との間の送信レートは上昇しない。そして、RNC100は、短時間でRNC100からUE2への送信レートを、送信元サーバ3から受信するデータの量に対してバランスの取れた送信レートになるまで上昇させていく。図13ではこの送信レートを「最適レート」と記載している。これにより、送信元サーバ3とUE2との間の送信レートが上昇する。そして、送信元サーバ3とUE2との間の送信レートを短時間で上昇させることができるため、時刻702でUE2へのパケットの送信を完了させることができる。

0119

これに対し、輻輳状態が発生してから送信元サーバの送信レートを変更する場合では、ハンドオーバーの発生時点では送信元の送信レートを変更しない。そのため、期間703では、RNCへのパケット量がRNCの疎通能力を超えている状態となり、パケットの破棄が発生する。これにより、送信元サーバとUEとの間で再送処理が行われる。そして、時刻704で送信元サーバが輻輳状態と認識し、急激に送信レートを低下させる。そして、RNCはバッファの空き容量に応じて送信レートを上昇させるため、一定期間送信レートを維持する。そのため、期間705のように、送信元サーバとUEとの間の送信レートは上昇しない。その後、徐々に送信元サーバとUEとの間の送信レートが回復していく。このように、再送処理や急激な送信レートの低下が発生するため、パケットの送信の完了が遅れ、時刻706でパケットの送信が完了する。

0120

このように、ハンドオーバー発生を契機とした場合と、輻輳状態が発生を契機とする場合とを比較すると、ハンドオーバー発生を契機とした場合のほうが、パケットの送信の完了までに要する時間を図13に示す時間707で表される分だけ短くすることができる。

0121

以上に説明したように、実施例2に係るRNCは、LTEシステムから送信レートの最大値が小さい3Gシステムへのハンドオーバーの発生を契機に、バッファの空き容量に応じた送信レートを送信元サーバからのデータの送信レートとして設定する。これにより、ハンドオーバーにより発生する無線ネットワーク制御装置の処理能力を超えるデータの送信を抑制でき、データの破棄などによる無線ネットワーク制御装置におけるデータ送信完了の遅延を短縮できる。

0122

また、バッファの空き容量に応じて送信元サーバからの送信レートを決定するため、バッファにデータが短時間で蓄積され、バッファの空き容量を短時間で小さくすることができる。そのため、本実施例2に係るRNCは、ハンドオーバー後に短時間で送信元サーバからのデータの受信とバランスの取れた送信レートでのUEへのデータの送信を確立できる。そして、データの送信元サーバとUEとの間のスループットの低下を軽減することができる。

0123

さらに、実施例2に係るRNCは、ハンドオーバーの発生を契機に送信レートを低下させるため、ハンドオーバー発生によるRNCの疎通能力を超えたパケットの受信を回避できる。これにより、再送処理や急激な送信レートの低下を回避でき、パケット送信の完了の遅延を回避することができる。

0124

また、以上に説明した実施例2では、特に送信レートの最大値が小さい通信システムへのハンドオーバーの場合にオーバーフローが発生しやすいため、ハンドオーバー検知部103でのハンドオーバーの検知を契機に送信元サーバの送信レートの決定を行っている。しかし、送信レートの最大値が小さい通信システムへのハンドオーバーが発生したときにオーバーフローを回避できれば、送信元の送信レートを決定するタイミングは他のタイミングでもよい。例えば、無線ネットワーク制御装置は、送信元サーバからデータが送信されている間ずっと、自己のバッファの空き容量に応じた送信レートを決定し、その送信レートに応じたウィンドウサイズの通知を行っても良い。このようにすることで、いつ送信レートの最大値が小さい通信システムへのハンドオーバーが発生しても、それによるオーバーフローを回避することができる。この場合には、無線ネットワーク制御装置にハンドオーバー検知部を設けなくて良い。

0125

以上の各実施例を含む実施形態に関し、さらに以下の付記を開示する。

0126

(付記1)所定の蓄積容量を有し、外部装置から受信したデータを蓄積するバッファと、
前記バッファからデータを読み出し移動端末へ送信する送信部と、
前記バッファの空き容量を基に前記外部装置から自装置へのデータの送信レートを決定する送信レート決定部と、
前記送信レート決定部により決定された前記送信レートに応じたウィンドウサイズを前記移動端末に通知するウィンドウサイズ通知部と
を備えたことを特徴とする無線ネットワーク制御装置。

0127

(付記2)第1の通信システムから該第1の通信システムに比べて前記外部装置から前記移動端末へのデータの送信レートの最大値が小さい第2の通信システムへのハンドオーバーが発生したことを検知するハンドオーバー検知部と、
前記送信レート決定部は、前記ハンドオーバー検知部がハンドオーバー発生を検知した場合に、送信レートの決定を行う
ことを特徴とする付記1に記載の無線ネットワーク制御装置。

0128

(付記3)前記送信レート決定部は、前記バッファの空き容量と前記送信レートとの対応関係を記憶しておき、前記バッファの現在の空き容量を取得し、前記対応関係を基に現在の空き容量に対応する前記送信レートを、前記外部装置から自装置へのデータの送信レートとして決定することを特徴とする付記1又は付記2に記載の無線ネットワーク制御装置。

0129

(付記4)前記対応関係は、前記バッファの空き容量に比例して前記送信レートが低くなっていくことを特徴とする付記1乃至3のいずれか一つに記載の無線ネットワーク制御装置。

0130

(付記5)前記第1の通信システムがLTEシステムであり、前記第2の通信システムが3Gシステムであることを特徴とした付記2乃至4のいずれか一つに記載の無線ネットワーク制御装置。

0131

(付記6)前記ウィンドウサイズ通知部は、コントロールパケットを用いて前記移動端末に前記ウィンドウサイズを通知することを特徴とする付記1乃至5のいずれか一つに記載の無線ネットワーク制御装置。

0132

(付記7)所定の容量を有するバッファに外部装置から受信したデータを蓄積するデータ蓄積ステップと、
前記バッファが蓄積しているデータを移動端末へ送信する送信ステップと、
第1の通信システムから該第1の通信システムに比べて前記外部装置から前記移動端末へのデータの送信レートの最大値が小さい第2の通信システムへのハンドオーバーが発生したことを検知するハンドオーバー検知ステップと、
ハンドオーバー発生の検知を受けて、前記バッファの空き容量を基に前記外部装置から自装置へのデータの送信レートを決定する疎通レート決定ステップと、
前記疎通レート決定ステップで決定した前記送信レートに応じたウィンドウサイズを前記移動端末に通知するウィンドウサイズ通知ステップ
を備えたことを特徴とする無線ネットワーク制御方法。

0133

(付記8)無線ネットワーク制御装置、移動端末、及び送信元装置を含む無線ネットワーク制御システムであって、
前記無線ネットワーク制御装置は、
所定の蓄積容量を有し、前記送信元装置から受信したデータを蓄積するバッファと、
前記バッファに蓄積されたデータを前記移動端末へ送信する送信部と、
第1の通信システムから該第1の通信システムに比べて前記送信元装置から前記移動端末へのデータの送信レートの最大値が小さい第2の通信システムへのハンドオーバーが発生したことを検知するハンドオーバー検知部と、
前記ハンドオーバー検知部によるハンドオーバー発生の検知を受けて、前記バッファの空き容量を基に前記外部装置から自装置へのデータの送信レートを決定する送信レート決定部と、
前記送信レート決定部により決定された前記送信レートに応じたウィンドウサイズを前記移動端末に通知するウィンドウサイズ通知部と
前記移動端末は、
前記ウィンドウサイズの通知を前記ウィンドウサイズ通知部から受けて、該ウィンドウサイズを前記送信元装置へ通知する通知部を備え、
前記送信元装置は、
前記通知部から通知された前記ウィンドウサイズに基づく送信レートで前記無線ネットワーク制御装置へデータを送信するデータ送信部を備える
ことを特徴とする無線ネットワーク制御システム。

実施例

0134

1無線ネットワーク制御装置
2 UE
3送信元サーバ
4 S‐GW
5 xGSN
6 eNB
7BTS
8IPサービス網
11バッファ
12 送信部
13送信レート決定部
14ウィンドウサイズ通知部
21 送信部
22 受信部
31データ送信部
100 RNC
101 バッファ
102 送信部
103ハンドオーバー検知部
104 送信レート決定部
105 ウィンドウサイズ通知部
211 通知部
212TCPパケット生成部
221 TCPWindowサイズ通知部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • シャープ株式会社の「 端末装置、基地局装置、通信方法、および、集積回路」が 公開されました。( 2019/09/12)

    【課題】上りリンクにおける送信を効率的に実行する。【解決手段】端末装置であって、パラメータ(skipUplinkTxSPS)が含まれるRRCメッセージを受信し、セミパーシステントスケジューリングの活性... 詳細

  • 株式会社東芝の「 通信装置、通信方法およびプログラム」が 公開されました。( 2019/09/12)

    【課題】相互に異なる複数の制御方式による通信が混在する通信システムを効率的に構築可能な通信装置、通信方法およびプログラムを提供する。【解決手段】通信装置は、複数の通信制御部と、選択部と、を備える。複数... 詳細

  • 株式会社東芝の「 通信装置、通信方法およびプログラム」が 公開されました。( 2019/09/12)

    【課題】通信効率の低下を抑制できる通信装置、通信方法およびプログラムを提供する。【解決手段】実施形態の通信装置は、選択部と、通信制御部と、を備える。選択部は、時分割多重方式の通信に用いる、データの処理... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ