JP2017526294A - キャリア間の負荷調整方法、装置及びシステム - Google Patents

Abstract

本発明はキャリア間の負荷調整方法、装置とシステムを開示し、該方法は、各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定することと、各アクティブ状態になったコンポーネントキャリアの残りリソース情報を確定し、前記残りリソース情報に基づいてターゲットキャリアを確定することと、さらにソースキャリアとターゲットキャリアに基づいて調整対象端末を確定し、調整対象端末の各ベアラのリソース情報に基づいて負荷調整しようとするベアラを確定することと、選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うことと、を含む。

Description

本発明は、ＬＴＥ−Ａ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ−Ａｄｖａｎｃｅｄ）システムにおけるキャリアアグリゲーション（Ｃａｒｒｉｅｒ Ａｇｇｒｅｇａｔｉｏｎ、ＣＡと略称）技術分野に関し、特に、キャリア間の負荷調整に関する。

ＬＴＥ−Ａは、３ＧＰＰがＩＴＵ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｕｎｉｏｎ）が提出したＩＭＴ−Ａ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ａｄｖａｎｃｅｄ）の需要を満たすために出したＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）後続の進化型技術標準で、ＬＴＥ−Ａは最大で１００ＭＨｚのシステム帯域幅を支援可能で、ダウンリンクのピーク速度は１Ｇｂｐｓを超えていて、アップリンクのピーク速度は５００Ｍｂｐｓに達する。ＬＴＥ−Ａシステムの設計は性能要求を満たすと共に、通信事業者によるシステムグレードアップのコストを低下させるようにＬＴＥに対する良好な上位互換性も考慮しなければならない。

ピーク速度の要求を満たすため、ＬＴＥ−Ａが現在最大で１００ＭＨｚ帯域幅を支援しているが、既存の利用可能な周波数スペクトルリソースからはこのように大きい帯域幅を探すことができない。また大きい帯域幅は基地局と端末とのハードウェア設計に大きい困難をもたらすことになる。そして、複数の周波数帯に分散された周波数スペクトルリソースについて、充分に利用できる技術が望まれている。上述したことに鑑み、ＬＴＥ−Ａはキャリアアグリゲーションという核心技術を導入した。

キャリアアグリゲーションの基本方法は、一区間の連続周波数スペクトル又は幾つかの離散周波数スペクトルを複数のコンポーネントキャリア（Ｃｏｍｐｏｎｅｎｔ Ｃａｒｒｉｅｒ、ＣＣと略称）に分割することである。キャリアアグリゲーションを支援するＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）は、複数のコンポーネントキャリアを集約することができ、且つ集約した全てのコンポーネントキャリア上のＰＲＢ（Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）リソースを同時に使用することができる。

現在利用している無線負荷バランシング（Ｒａｄｉｏ Ｌｏａｄ Ｂａｌａｎｃｉｎｇ、ＲＬＢと略称）技術は、サービスの構築又は切り替え等の非安定状態で、現在アクセス又は切り替えするターゲットキャリアの負荷が高すぎてシステムの性能又はシステムの安定性に影響を与えることになると、無線ネットワーク中のキャリア間の位置関係を利用して、対応するサービスを負荷の低いキャリアにアクセス又は切り替えして、できる限りキャリア間でリソースを均一に負担させ、よって、システムリソースを有効に利用してシステムの性能を向上させ、システム容量を増加する。

しかし、現在利用している無線負荷バランシング技術は、切り替えに失敗してしまうリスクがあって、ユーザの通話が切断されてユーザの体験に影響を与える可能性がある一方、システムのシグナル交換を増やし、システムの負荷を増加する。

本発明の実施例は、少なくとも既存の無線負荷バランシング技術に存在する上述した問題を解決できるキャリアアグリゲーションでのキャリア間の負荷調整方法、装置とシステムを提供する。

上記目的を実現するため、本発明の一態様によると、各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定することと、各アクティブ状態になったコンポーネントキャリアの残りリソース情報を確定し、前記残りリソース情報に基づいてターゲットキャリアを確定することと、さらにソースキャリアとターゲットキャリアに基づいて調整対象端末を確定し、調整対象端末の各ベアラのリソース情報に基づいて負荷調整しようとするベアラを確定することと、選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うことと、を含むキャリアアグリゲーションでのキャリア間の負荷調整方法を提供する。

そして、本発明は、各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定するように構成されるソースキャリア確定モジュールと、各アクティブ状態になったコンポーネントキャリアの残りリソース情報を確定し、前記残りリソース情報に基づいてターゲットキャリアを確定するように構成されるターゲットキャリア確定モジュールと、ソースキャリアとターゲットキャリアンに基づいて調整対象端末を確定し、調整対象端末の各ベアラのリソース情報に基づいて負荷調整しようとするベアラを確定するように構成される調整対象ベアラ確定モジュールと、選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うように構成される調整モジュールと、を含むキャリア間の負荷調整装置を提供する。

本発明で提供するキャリアアグリゲーションでのキャリア間の負荷調整方法、装置とシステムによると、メインキャリア及びサブキャリア間の負荷のバランスがとれておらず且つ負荷バランシング周期になっていない場合、サービスを負荷の低いキャリアに調整することで、ネットワーク負荷のアンバランスを改善し、ＲＬＢ機能によってトリガーされる切り替え回数を減少し、通話切断リスクを低減し、システムのシグナル交換負担を低減する。

本発明で開示するキャリア間の負荷調整方法を示すフローチャートである。 本発明で開示する他のキャリア間の負荷調整方法を示すフローチャートである。 本発明の実施例１又は実施例５に示すキャリア間で負荷バランシングを実現する方法を示すフローチャートである。 本発明の実施例２、実施例３又は実施例４に示すキャリア間で負荷バランシングを実現する方法を示すフローチャートである。 本発明で開示するキャリア間の負荷バランシング装置の構造を示す図である。

本技術案は、キャリアのリソース情報を周期的にモニターすることでキャリア間の負荷調整を行う必要があるか否かを判断し、適切なターゲットベアラ（Ｂｅａｒｅｒ）を選択して負荷を低負荷のキャリアに調整することで、キャリア間の負荷が基本的なバランスをとる目的を実現し、できる限りサブキャリアのアクティブ化を減少して端末の省電の目的を実現する。

ここで、前記負荷調整は、戻し、移動又は分割であることができる：
戻しとは、ＵＥのある一つのベアラがＰｃｅｌｌ（Ｐｒｉｍａｒｙ ｃｅｌｌ）とＳｃｅｌｌ（Ｓｅｃｏｎｄａｒｙ ｃｅｌｌ）上で同時にリソーススケジューリングがあった場合、該ベアラのＳｃｅｌｌ上のスケジューリングされたリソースをＰｃｅｌｌに戻してスケジューリングを行うことを指す。

移動とは、ＵＥのＰｃｅｌｌ上でスケジューリングされたある一つのベアラリソースを完全に一つのＳｃｅｌｌに置いてスケジューリングを行うことを指す。

分割とは、ＵＥのＰｃｅｌｌ上でスケジューリングされたある一つのベアラリソースを多数に分割して複数のＳｃｅｌｌ又は複数のＳｃｅｌｌとＰｃｅｌｌに置いてスケジューリングを行うことを指す。

本技術案で開示するキャリア間の負荷調整方法は、図１に示すように、以下のステップを含む：
Ｓ１０１：基地局が、各コンポーネントキャリア（ネットワークにてＣＡを支援するキャリア）の利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定する。

Ｓ１０２：基地局が、各アクティブ状態になったコンポーネントキャリアの残りリソース情報を確定し、前記残りリソース情報に基づいてターゲットキャリアを確定する。

Ｓ１０３：基地局が、ソースキャリアとターゲットキャリアに基づいて調整対象端末を確定し、調整対象端末の各ベアラのリソース情報に基づいて負荷調整しようとするベアラを確定する。

Ｓ１０４：基地局が、選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行う。

本技術案で開示するキャリアアグリゲーションでのキャリア間の負荷調整装置は、図５に示すように、以下のモジュールを含む：
各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定するように構成されるソースキャリア確定モジュールと、
各アクティブ状態になったコンポーネントキャリアの残りリソース情報を確定し、前記残りリソース情報に基づいてターゲットキャリアを確定するように構成されるターゲットキャリア確定モジュールと、
ソースキャリアとターゲットキャリアに基づいて調整対象端末を確定し、調整対象端末の各ベアラのリソース情報に基づいて負荷調整を行う必要のあるベアラを確定するように構成される調整対象ベアラ確定モジュールと、
選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うように構成される調整モジュールと、を含む。

以下、図面を結合して、具体的な実施例によって本発明の技術案及び実現できる技術効果を詳しく説明する。

第１の実施例は、図３に示すように、具体的に以下のステップを含む。

ステップ１０１：基地局が、各コンポーネントキャリア（ネットワークにてＣＡを支援するキャリア）のＰＲＢ使用率について周期的な測定を行って、時間帯（該時間帯はＲＬＢ実行周期より短い）内の測定結果を濾過して濾過値を得て、前記濾過とは一区間の時間の例えば算術平均値等の平滑値を得ることを指す。ある一つのキャリアのＰＲＢ使用率が負荷調整トリガー閾値を超えると、該キャリアのシステム負荷が高いと認定し、基地局は該キャリアが負荷調整を行う必要のあるソースキャリアであると確定する。ここでの負荷調整トリガー閾値は、ＲＬＢ実行閾値より低く、つまり、ＲＬＢをトリガーする前に負荷調整機能をトリガーすることで、ＲＬＢ周期に達する前、キャリア負荷をＲＬＢ閾値以下に低下させて、ＲＬＢによってトリガーされる切り替え回数を減少する。例えば、ＲＬＢ閾値が７０％であると、負荷調整トリガー閾値は５０％に設定することができる。

ステップ１０２：基地局が、各アクティブ状態になったコンポーネントキャリア上の残りリソース情報を確定し、該リソース情報はＰＲＢ、速度等の情報であることができ、確定方式は、セルの総リソースにピンポン防止閾値をかけ算してから該キャリアの使用済みのリソースを引く。ピンポン防止閾値を設定することは、主に、負荷をターゲットキャリアに調整した後にターゲットキャリアの負荷が高くなってしまい、ターゲットキャリアがさらに負荷調整をトリガーして、調整を繰り返すことを防止するためです。ピンポン防止閾値を負荷調整トリガー閾値と同じ値に設定することができるが、ピンポン防止閾値がステップ１０１中の負荷調整トリガー閾値値を超えてはいけない。一定の原則に従って、アクティブ状態になった各コンポーネントキャリアの順位をつけ、該原則は唯一の排列結果を保証するためのものであって、例えば残りリソースを大きい順で排列し、又はランダム等の方式で排列する。該排列からステップ１０１にて選別したソースキャリアよりも負荷が一定差異閾値低く且つ残りリソースが最も多いキャリアを選択してターゲットキャリアとする。該差異閾値により負荷調整するターゲットキャリアがソースキャリアより低負荷であることを保証し、つまり、高い方から低い方へ調整し、該差異閾値は例えば１０％、１５％又は２０％であることができる。

ステップ１０３：基地局が、ソースキャリアがＳｃｅｌｌで且つターゲットキャリアがＰｃｅｌｌであるこのようなＵＥにおいて、一定の原則に従ってターゲットＵＥを選択し（例えば、ソースキャリアでＰＲＢ使用率が最も高いＵＥを選択する）、該ターゲットＵＥのある一つのベアラを戻し対象ベアラとし（例えば、該ユーザのソースキャリアで占めるＰＲＢ／速度リソースが最も大きいベアラを選択する）、ステップ１０４に移行し、戻し対象ベアラを選択できないと、ステップ１０５に移行する。

ステップ１０４：基地局が、戻し対象ベアラがソースキャリアで占めるリソースがターゲットキャリアの残りリソース以下であると判断すると、戻し操作を実行してフローを終了し、そうでなければ、ステップ１０５に移行する。

ステップ１０５：基地局が、ソースキャリアがＰｃｅｌｌで且つターゲットキャリアがＳｃｅｌｌであるＵＥにおいて、一定の原則に従ってターゲットＵＥを選択し（例えば、ソースキャリアでのＰＲＢ使用率が最も大きいＵＥを選択する）、該ターゲットＵＥのある一つのベアラを移動分割対象ベアラとして選択し（例えば、該ユーザのソースキャリアにて占めるＰＲＢ／速度リソースが最も大きいベアラを選択する）、ステップ１０６に移行する。

ステップ１０６：基地局が、移動分割対象ベアラが占めるリソースがターゲットキャリアの残りリソース以下であると判断すると、移動操作を実行してフローを終了し、そうでなければ、ステップ１０７に移行する。

ステップ１０７：基地局が、ステップ１０５にて選択したターゲットＵＥが位置する全てのアクティブ状態になったＳｃｅｌｌにて、移動分割対象ベアラについて分割操作を行う（例えば、残りリソースの大きい順に従って、各Ｓｃｅｌｌにリソース分割を行う）。分割に失敗すると、該ターゲットＵＥのアクティブ状態になっていないＳｃｅｌｌから一つ又は複数のキャリアをアクティブ状態にし、アクティブ状態にしてから分割を行い、成功した後、フローを終了する。該ＵＥの全てのアクティブ状態になっていないＳｃｅｌｌに対して行った後も成功していないと、Ｐｃｅｌｌを追加して分割を行ってフローを終了する。

上記ステップは、戻し→移動→分割の順で説明していて、これが最適な処理方式であるが、調整方式は上述した順に限定されず、例えば戻しのみを行うか、直接に分割を行う等の他の方式で行うこともできる。ここでの調整方式の選択はスイッチによって制御することができ、アレイの方式で行うこともできる。好適な戻し方式は、できる限り少ないＳｃｅｌｌをアクティブ状態にすることで、ＵＥの省電目的を実現することができる。まず移動を行うと、リソーススケジューリングの欠片を減少し、できる限り同一のベアラのリソースを同一のキャリアにスケジューリングすることができ、リソースが移動するに不足である場合に分割を行う。

第２の実施例は具体的に以下を含む：
ＣＡでのキャリア間の負荷調整周期は１０ｓで、負荷調整トリガー閾値は６０％である。無線負荷バランシング（ＲＬＢ）周期は２０ｓで、負荷バランシングトリガー閾値は７０％で、キャリア間差異閾値は２０％で、ピンポン防止閾値は６０％で、三つのコンポーネントキャリアｃｅｌｌ１、ｃｅｌｌ２、ｃｅｌｌ３の帯域幅はいずれも２０Ｍである。セルの周波数スペクトル効率は変化しないとする。

ステップ２０１：測定時間帯（第１０ｓ）になると、基地局は、ｃｅｌｌ１のＰＲＢ使用率が６５％で、ｃｅｌｌ２のＰＲＢ使用率が４０％で、ｃｅｌｌ３のＰＲＢ使用率が４５％であると統計する。ｃｅｌｌ１のＰＲＢ使用率が負荷調整トリガー閾値を超えていて且つ無線負荷バランシング（ＲＬＢ）実行周期には達していないので、ｃｅｌｌ１をソースキャリアと確定し、負荷調整機能をトリガーしなければならない。

ステップ２０２：基地局が統計したｃｅｌｌ２とｃｅｌｌ３の残りＰＲＢリソース数量は、ｃｅｌｌ２ｒｅｓｔ＝１００＊６０％−１００＊４０％＝２０、ｃｅｌｌ３ｒｅｓｔ＝１００＊６０％−１００＊４５％＝１５である。ｃｅｌｌ２とｃｅｌｌ３のＰＲＢ使用率がいずれもｃｅｌｌ１より差異閾値（２０％）低いが、ｃｅｌｌ２の残りリソースがｃｅｌｌ３より大きいので、ｃｅｌｌ２をターゲットキャリアと確定する。

ステップ２０３：三つの端末ＵＥ１、ＵＥ２、ＵＥ３がいずれもＣＡを支援するＲ１０端末であって、ここで、ＵＥ１のＲＲＣはｃｅｌｌ１に接続され、他のキャリアを集約しておらず、ＵＥ２のＲＲＣはｃｅｌｌ２に接続され、集約したキャリアはｃｅｌｌ１、ｃｅｌｌ２、ｃｅｌｌ３であって、ＵＥ３のＲＲＣはｃｅｌｌ３に接続され、他のキャリアを集約していない。各ＵＥのリソース占用状況は、
ＵＥ１のｂｅａｒｅｒ１がｃｅｌｌ１上で５０ＲＢを占用し；
ＵＥ２のｂｅａｒｅｒ１がｃｅｌｌ１上で１５ＲＢを、ｃｅｌｌ２で４０ＲＢを占用し；
ＵＥ３のｂｅａｒｅｒ１がｃｅｌｌ３上で４５個のＲＢを占用する。

ソースキャリアｃｅｌｌ１をＳｃｅｌｌとし、ターゲットキャリアｃｅｌｌ２をＰｃｅｌｌとするＵＥがＵＥ２のみであるので、ＵＥ２のｂｅａｒｅｒ１を戻し対象ベアラと確定する。

ステップ２０４：基地局が、戻しベアラがソースキャリアｃｅｌｌ１で占用したリソースとターゲットキャリアｃｅｌｌ２の残りリソースとの関係を判断する。１５ＲＢ＜２０ＲＢであるので、戻しを行うことができる。戻しを実行した後、ｃｅｌｌ１上のＰＲＢ使用率は５０％で、ｃｅｌｌ２上のＰＲＢ使用率は５５％で、ｃｅｌｌ３上のＰＲＢ使用率は４５％で、基本的にバランスをとっている。また、ＵＥ２がｃｅｌｌ１でリソースのスケジューリングがないので、戻しした後にｃｅｌｌ１を非アクティブにすることで、ＵＥ２の省電目的を実現することができる。

そして、無線負荷バランシング（ＲＬＢ）実行周期に達する（第２０ｓ）前、ＵＥがｃｅｌｌ１にアクセスしてサービスを行って８ＲＢリソースを占用したと仮設すると、キャリア間の負荷調整を行っていないと、ＲＬＢ実行周期時点で、ｃｅｌｌ１セルの負荷が６５％＋８％＝７３％に達してしまい、ＲＬＢ実行閾値７０％を超え、ＲＬＢに基づく切り替えを行うことになる。予めキャリア間の負荷調整を行っていると、ＲＬＢ実行周期時点で、ｃｅｌｌ１セルの負荷は５０％＋８％＝５８％で、ＲＬＢ実行閾値７０％未満で、ＲＬＢに基づく切り替えを行うことがなく、ＲＬＢ切り替え回数を減少し、通話切断リスクを低減する。

第３の実施例は具体的に以下を含む：
ＣＡでのキャリア間の負荷調整周期は１０ｓで、負荷調整トリガー閾値は６０％で、無線負荷バランシング（ＲＬＢ）周期は２０ｓで、負荷バランシングトリガー閾値は７０％で、キャリア間差異閾値は２０％で、ピンポン防止閾値は６０％で、三つのコンポーネントキャリアｃｅｌｌ１、ｃｅｌｌ２、ｃｅｌｌ３の帯域幅はいずれも２０Ｍである。各セルの周波数スペクトル効率は同一であって変化しないとする。

ステップ３０１：測定時間帯（第１０ｓ）になると、基地局はｃｅｌｌ１のＰＲＢ使用率が６５％で、ｃｅｌｌ２のＰＲＢ使用率が４０％で、ｃｅｌｌ３のＰＲＢ使用率が４５％であると統計する。ｃｅｌｌ１のＰＲＢ使用率が負荷調整トリガー閾値を超えているが無線負荷バランシング（ＲＬＢ）実行周期になっていないので、ｃｅｌｌ１が負荷調整機能をトリガーする。

ステップ３０２：基地局が統計したｃｅｌｌ２とｃｅｌｌ３の残りＰＲＢリソース数量はｃｅｌｌ２ｒｅｓｔ＝１００＊６０％−１００＊４０％＝２０、ｃｅｌｌ３ｒｅｓｔ＝１００＊６０％−１００＊４５％＝１５である。ｃｅｌｌ２とｃｅｌｌ３のＰＲＢ使用率がいずれもｃｅｌｌ１より差異閾値（２０％）低いが、ｃｅｌｌ２の残りリソースがｃｅｌｌ３より大きいので、ｃｅｌｌ２をターゲットキャリアと選択する。

ステップ３０３：四つの端末中のＵＥ１、ＵＥ２、ＵＥ３はいずれもＣＡを支援するＲ１０端末で、ＵＥ４はＲ８端末であって、ここで、ＵＥ１のＲＲＣはｃｅｌｌ１に接続され、アグリゲーションキャリアはｃｅｌｌ１、ｃｅｌｌ２、ｃｅｌｌ３であって、ＵＥ２のＲＲＣはｃｅｌｌ２に接続され、他のキャリアを集約しておらず、ＵＥ３のＲＲＣはｃｅｌｌ３に接続され、他のキャリアを集約しておらず、ＵＥ４はｃｅｌｌ１にアクセスする。各ＵＥのリソース占用状況は、
ＵＥ１のｂｅａｒｅｒ１がｃｅｌｌ１上で１５ＲＢを占用し；
ＵＥ１のｂｅａｒｅｒ２がｃｅｌｌ１上で１０ＲＢを占用し；
ＵＥ２のｂｅａｒｅｒ１がｃｅｌｌ２上で４０ＲＢを占用し；
ＵＥ３のｂｅａｒｅｒ１がｃｅｌｌ３上で４５ＲＢを占用し；
ＵＥ４のｂｅａｒｅｒ１がｃｅｌｌ１上で４０ＲＢを占用する。

ソースキャリアｃｅｌｌ１がＰｃｅｌｌで、且つターゲットキャリアｃｅｌｌ２がＳｃｅｌｌであるＵＥがＵＥ１のみであって、ＵＥ１のｂｅａｒｅｒ１がｃｅｌｌ１上で占用したリソース１５ＲＢがｂｅａｒｅｒ２がｃｅｌｌ１上で占用したリソース１０ＲＢより多いので、ＵＥ１のｂｅａｒｅｒ１を移動分割対象ベアラと選択する。

ステップ３０４：移動分割対象ベアラがｃｅｌｌ１上で占用したリソースとｃｅｌｌ２の残りリソースとの関係を判断し、１５ＲＢ＜２０ＲＢであるので、直接に移動を行う。移動した後のｃｅｌｌ１上のＰＲＢ使用率は５０％で、ｃｅｌｌ２上のＰＲＢ使用率は５５％で、ｃｅｌｌ３上ＰＲＢ使用率は４５％で、基本的にバランスをとっている。

そして、無線負荷バランシング（ＲＬＢ）実行周期に達する（第２０ｓ）前、ＵＥがｃｅｌｌ１にアクセスしてサービスを行って８ＲＢリソースを占用したと仮設すると、キャリア間の負荷調整を行っていないと、ＲＬＢ実行周期時点で、ｃｅｌｌ１セルの負荷が６５％＋８％＝７３％に達し、ＲＬＢ実行閾値７０％を超えて、ＲＬＢに基づく切り替えを行うことになる。予めキャリア間の負荷調整を行っていると、ＲＬＢ実行周期時点で、ｃｅｌｌ１セルの負荷は５０％＋８％＝５８％で、ＲＬＢ実行閾値７０％より低いので、ＲＬＢに基づく切り替えを行うことがなく、ＲＬＢ切り替え回数を減少し、通話切断リスクを低減する。

第４の実施例は具体的に以下を含む：
ＣＡでのキャリア間の負荷調整周期が１０ｓで、負荷調整トリガー閾値が６０％で、無線負荷バランシング（ＲＬＢ）周期が２０ｓで、負荷バランシングトリガー閾値が７０％で、キャリア間負荷差異閾値が２０％で、ピンポン防止閾値が６０％で、三つのコンポーネントキャリアｃｅｌｌ１、ｃｅｌｌ２、ｃｅｌｌ３の帯域幅がいずれも２０Ｍであるとする。各セル周波数スペクトル効率が同一であって変化しないと仮設する。

ステップ４０１：測定時間帯（第１０ｓ）になると、基地局がｃｅｌｌ１のＰＲＢ使用率は６５％で、ｃｅｌｌ２のＰＲＢ使用率は４０％で、ｃｅｌｌ３のＰＲＢ使用率は４５％であると統計する。ｃｅｌｌ１のＰＲＢ使用率が負荷調整トリガー閾値を超えているが無線負荷バランシング（ＲＬＢ）実行周期にはなっていないので、ｃｅｌｌ１は負荷調整機能をトリガーする。

ステップ４０２：基地局が統計したｃｅｌｌ２とｃｅｌｌ３の残りＰＲＢリソース数量は、ｃｅｌｌ２ｒｅｓｔ＝１００＊６０％−１００＊４０％＝２０、ｃｅｌｌ３ｒｅｓｔ＝１００＊６０％−１００＊４５％＝１５である。ｃｅｌｌ２とｃｅｌｌ３のＰＲＢ使用率がいずれもｃｅｌｌ１より負荷差異閾値（２０％）低いが、ｃｅｌｌ２の残りリソースがｃｅｌｌ３より大きいので、ｃｅｌｌ２をターゲットキャリアとして選択する。

ステップ４０３：四つの端末ＵＥ１、ＵＥ２、ＵＥ３、ＵＥ４はいずれもＣＡを支援するＲ１０端末であって、ここで、ＵＥ１のＲＲＣはｃｅｌｌ１に接続され、アグリゲーションキャリアはｃｅｌｌ１、ｃｅｌｌ２、ｃｅｌｌ３であって、ＵＥ２のＲＲＣはｃｅｌｌ２に接続され、他のキャリアを集約しておらず、ＵＥ３のＲＲＣはｃｅｌｌ３に接続され、他のキャリアを集約しておらず、ＵＥ４のＲＲＣはｃｅｌｌ１に接続され、他のキャリアを集約していない。各ＵＥのリソース占用状況は、
ＵＥ１のｂｅａｒｅｒ１がｃｅｌｌ１上で２２ＲＢを占用し；
ＵＥ１のｂｅａｒｅｒ２がｃｅｌｌ１上で３ＲＢを占用し；
ＵＥ２のｂｅａｒｅｒ１がｃｅｌｌ２上で４０ＲＢを占用し；
ＵＥ３のｂｅａｒｅｒ１がｃｅｌｌ３上で４５ＲＢを占用し；
ＵＥ４のｂｅａｒｅｒ１がｃｅｌｌ１上で４０ＲＢを占用する。

ソースキャリアｃｅｌｌ１がＰｃｅｌｌで、且つターゲットキャリアｃｅｌｌ２がＳｃｅｌｌであるＵＥがＵＥ１のみであって、ＵＥ１のｂｅａｒｅｒ１がｃｅｌｌ１上で占用したリソース２２ＲＢがｂｅａｒｅｒ２がｃｅｌｌ１上で占用したリソース３ＲＢより大きいので、ＵＥ１のｂｅａｒｅｒ１を移動分割対象ベアラと選択する。

ステップ４０４：該移動分割対象ベアラがｃｅｌｌ１上で占用したリソースとｃｅｌｌ２の残りリソースとの関係を判断し、２２ＲＢ＞２０ＲＢであるので、移動を行うことができず、分割しなければならない。

ここで、分割ベアラがｃｅｌｌ２上に分割したリソースは２０ＲＢで、残りリソース２ＲＢはＵＥ１が集約した他のキャリアに分割し、ステップ４０２に基づいてｃｅｌｌ２以外の残りリソースが最大なキャリアｃｅｌｌ３を二回目分割キャリアとして選択し、分割対象リソースとｃｅｌｌ３の残りリソースとの関係を比較すると、２ＲＢ＜１５ＲＢであるので、分割を行うことができる。分割した後、ｃｅｌｌ１上のＰＲＢ使用率は４３％で、ｃｅｌｌ２上のＰＲＢ使用率は６０％で、ｃｅｌｌ３上ＰＲＢ使用率は４７％、基本的にバランスをとっている。

そして、無線負荷バランシング（ＲＬＢ）実行周期になる（第２０ｓ）前、ＵＥがｃｅｌｌ１にアクセスしてサービスを行って８ＲＢリソースを占用したと仮設すると、キャリア間の負荷調整を行っていないと、ＲＬＢ実行周期時点で、ｃｅｌｌ１セルの負荷が６５％＋８％＝７３％に達し、ＲＬＢ実行閾値７０％を超えて、ＲＬＢに基づく切り替えを行うことになって、切り替えに失敗したり通話が切断するリスクがある。予めキャリア間の負荷調整を行っていると、ＲＬＢ実行周期時点で、ｃｅｌｌ１セルの負荷が４３％＋８％＝５１％で、ＲＬＢ実行閾値７０％より低いので、ＲＬＢに基づく切り替えを行うことがなく、ＲＬＢ切り替え回数を減少し、通話切断リスクを低減する。

第５の実施例は具体的に以下を含む：
ＣＡでのキャリア間の負荷調整周期が１０ｓで、負荷調整トリガー閾値が６０％で、無線負荷バランシング（ＲＬＢ）周期が２０ｓで、負荷バランシングトリガー閾値が７０％で、キャリア間負荷差異閾値が２０％で、ピンポン防止閾値が６０％で、三つのコンポーネントキャリアｃｅｌｌ１、ｃｅｌｌ２、ｃｅｌｌ３の帯域幅がいずれも２０Ｍであるとする。各セルの周波数スペクトル効率が同一であって変化しないと仮設する。

ステップ５０１：測定時間帯（第１０ｓ）になると、基地局がｃｅｌｌ１のＰＲＢ使用率は６５％で、ｃｅｌｌ２のＰＲＢ使用率は４０％で、ｃｅｌｌ３のＰＲＢ使用率は４５％であると統計する。ｃｅｌｌ１のＰＲＢ使用率が負荷調整トリガー閾値を超えているが無線負荷バランシング（ＲＬＢ）実行周期にはなっていないので、ｃｅｌｌ１が負荷調整機能をトリガーし、ソースキャリアと確定する。

ステップ５０２：基地局が統計したｃｅｌｌ２とｃｅｌｌ３の残りＰＲＢリソース数量は、ｃｅｌｌ２ｒｅｓｔ＝１００＊６０％−１００＊４０％＝２０、ｃｅｌｌ３ｒｅｓｔ＝１００＊６０％−１００＊４５％＝１５である。ｃｅｌｌ２とｃｅｌｌ３のＰＲＢ使用率がいずれもｃｅｌｌ１より負荷差異閾値（２０％）低いが、ｃｅｌｌ２の残りリソースがｃｅｌｌ３より多いので、ｃｅｌｌ２をターゲットキャリアと選択する。

ステップ５０３：四つの端末ＵＥ１、ＵＥ２、ＵＥ３、ＵＥ４はいずれもＣＡを支援するＲ１０端末であって、ここで、ＵＥ１のＲＲＣはｃｅｌｌ１に接続され、アグリゲーションキャリアはｃｅｌｌ１、ｃｅｌｌ２、ｃｅｌｌ３であって、ＵＥ２のＲＲＣはｃｅｌｌ２に接続され、アグリゲーションキャリアはｃｅｌｌ１、ｃｅｌｌ２、ｃｅｌｌ３であって、ＵＥ３のＲＲＣはｃｅｌｌ３に接続され、他のキャリアを集約しておらず、ＵＥ４のＲＲＣはｃｅｌｌ１に接続され、他のキャリアを集約していない。各ＵＥのリソース占用状況は、
ＵＥ１のｂｅａｒｅｒ１がｃｅｌｌ１上で２２ＲＢを占用し；
ＵＥ１のｂｅａｒｅｒ２がｃｅｌｌ１上で３ＲＢを占用し；
ＵＥ２のｂｅａｒｅｒ１がｃｅｌｌ１上で２５ＲＢを占用し；
ＵＥ２のｂｅａｒｅｒ２がｃｅｌｌ２上で４０ＲＢを占用し；
ＵＥ３のｂｅａｒｅｒ１がｃｅｌｌ３上で４５ＲＢを占用し；
ＵＥ４のｂｅａｒｅｒ１がｃｅｌｌ１上で１５ＲＢを占用する。

ソースキャリアｃｅｌｌ１がＳｃｅｌｌで、ターゲットキャリアｃｅｌｌ２がＰｃｅｌｌであるＵＥがＵＥ２のみであるので、ＵＥ２のｂｅａｒｅｒ１が戻しベアラとして選択される。

ステップ５０４：戻しベアラがソースキャリアｃｅｌｌ１上で占用したリソースとターゲットキャリアｃｅｌｌ２の残りリソースとの関係を判断し、２５ＲＢ＞２０ＲＢであるので、戻しを行うことができず、ステップ５０５に移行する。

ステップ５０５：ソースキャリアｃｅｌｌ１がＰｃｅｌｌで、且つターゲットキャリアｃｅｌｌ２がＳｃｅｌｌであるＵＥがＵＥ１のみであって、ＵＥ１のｂｅａｒｅｒ１がｃｅｌｌ１上で占用したリソース２２ＲＢがｂｅａｒｅｒ２がｃｅｌｌ１上で占用したリソース３ＲＢより大きいので、ＵＥ１のｂｅａｒｅｒ１が移動分割対象ベアラとして選択され、ステップ５０６に移行する。

ステップ５０６：該移動分割対象ベアラがｃｅｌｌ１上で占用したリソースとｃｅｌｌ２の残りリソースとの関係を判断し、２２ＲＢ＞２０ＲＢであるので、移動を行うことができず、該ベアラについて分割を行わなければならず、ステップ５０７に移行する。

ステップ５０７：ここで、分割ベアラがｃｅｌｌ２上に分割したリソースはｃｅｌｌ２の残りリソース２０ＲＢで、その他の２ＲＢはＵＥ１が集約した他のキャリアに分割し、ステップ２に従ってｃｅｌｌ２以外の残りリソースが最大なキャリアｃｅｌｌ３を二回目分割キャリアとして選択し、分割した後の残りリソースとｃｅｌｌ３の残りリソースとの関係を比較し、２ＲＢ＜１５ＲＢであるので、分割に成功した。分割した後のｃｅｌｌ１上のＰＲＢ使用率は４３％で、ｃｅｌｌ２上のＰＲＢ使用率は６０％で、ｃｅｌｌ３上のＰＲＢ使用率は４７％で、基本的にバランスをとっている。

そして、無線負荷バランシング（ＲＬＢ）実行周期になる（第２０ｓ）前、ＵＥがｃｅｌｌ１にアクセスしてサービスを行って８ＲＢリソースを占用したと仮設すると、キャリア間の負荷調整を行っていないと、ＲＬＢ実行周期時点で、ｃｅｌｌ１セルの負荷が６５％＋８％＝７３％に達し、ＲＬＢ実行閾値７０％を超えて、ＲＬＢに基づく切り替えを行うことになって、切り替えに失敗し通話が切断するリスクがある。予めキャリア間の負荷調整を行っていると、ＲＬＢ実行周期時点で、ｃｅｌｌ１セルの負荷が４３％＋８％＝５１％で、ＲＬＢ実行閾値７０％より低いので、ＲＬＢに基づく切り替えを行うことがなく、ＲＬＢ切り替え回数を減少し、通話切断リスクを低減する。

第６の実施例は、図２に示すように、具体的に以下を含む：
キャリア間の負荷調整方法は、
各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定することと、
前記ソースキャリアを集約した端末において各ベアラのリソース情報に基づいて負荷調整しようとするベアラを確定することと、
前記負荷調整しようとするベアラに対応するキャリアにおいてリソース情報に基づいてターゲットキャリアを確定することと、
選別したソースキャリアとターゲットキャリアに基づいて負荷調整を行う必要のあるベアラについて負荷調整を行うことと、を含む。

実施例７は、キャリアアグリゲーションでのキャリア間の負荷調整装置で、前記装置は、
各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定するように構成されるソースキャリア確定モジュールと、
各アクティブ状態になったコンポーネントキャリアの残りリソース情報を確定し、前記残りリソース情報に基づいてターゲットキャリアを確定するように構成されるターゲットキャリア確定モジュールと、
ソースキャリアとターゲットキャリアに基づいて調整対象端末を確定し、調整対象端末の各ベアラのリソース情報に基づいて負荷調整を行う必要のあるベアラを確定するように構成される調整対象ベアラ確定モジュールと、
選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うように構成される調整モジュールと、を含む。

実施例８は、キャリアアグリゲーションでのキャリア間の負荷調整システムであって、該システムは、前記負荷調整装置を含む。

具体的な実施形態に対する説明によって、本発明が所定の目的を実現するために用いた技術モジュール及びその効果を一層深くて具体的に理解したはずであるが、図面は説明する際に参照するためのものであって、本発明を限定するものではない。そして、矛盾しない限り、実施例と実施例中の特徴を組み合せすることができる。

当業者であれば、本発明の実施例を方法又はコンピュータプログラム製品として提供することも可能であることを理解できる。従って、本発明は、ハードウェア実施例、ソフトウェア実施例又はソフトウェアとハードウェアを結合した実施例の形態であることができる。さらに、本発明は、一つ又は複数のコンピュータ利用可能なプログラムコードを含むコンピュータ利用可能な記憶媒体（磁気ディスク記憶装置と光学記憶装置等を含むがこれらに限定されることはない）にて実施されるコンピュータプログラム製品の形態であることもできる。

本発明を本発明の実施例に係わる方法とコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して説明した。ここで、コンピュータプログラム命令によってフローチャート及び／又はブロック図中の各フロー及び／又はモジュール、及びフローチャート及び／又はブロック図中のフロー及び／又はモジュールの結合を実現することができることは理解できることである。このようなコンピュータプログラム命令を汎用コンピュータ、専用コンピュータ、内蔵式処理装置又は他のプログラミング可能なデータ処理機器のプロセッサに提供して一つの機器を発生して、コンピュータ又は他のプログラミング可能なデータ処理機器のプロセッサが実行した命令によって、フローチャート中の一つ又は複数のフロー及び／又はブロック図中の一つ又は複数のモジュールにより指定された機能を実現できる装置を発生する。

これらのコンピュータプログラム命令を、コンピュータ又は他のプログラミング可能なデータ処理機器を特定の方式で動作するようにガイドできるコンピュータ読取可能な記憶装置に記憶して、該コンピュータ読取可能な記憶装置に記憶された命令が命令装置を含む製造品を発生し、該命令装置によってフローチャート中の一つ又は複数のフロー及び／又はブロック図中の一つ又は複数のモジュールに指定された機能を実現することができる。

これらのコンピュータプログラム命令をコンピュータ又は他のプログラミング可能なデータ処理機器にインストールして、コンピュータ又は他のプログラミング可能な機器で一連の操作ステップを実行することでコンピュータで実現する処理を発生して、コンピュータ又は他のプログラミング可能な機器で実行した命令によって、フローチャート中の一つ又は複数のフロー及び／又はブロック図中の一つ又は複数のモジュールに指定された機能を実現するためのステップを提供することができる。

以上は、本発明の好適な実施例であって、本発明の保護範囲を限定するものではない。

上述のように、本発明の実施例で提供するキャリアアグリゲーションでのキャリア間の負荷調整方法、装置とシステムによると、メインーサブキャリア間の負荷がアンバランスであって負荷バランシング周期になっていない場合、サービスを負荷の低いキャリアに調整することで、ネットワークの負荷アンバランスを改善し、ＲＬＢ機能によりトリガーされる切り替え回数を減少し、通話切断リスクを低減し、システムのシグナル交換負担を低減できる。

Claims (33)

1. 各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定することと、
   各アクティブ状態になったコンポーネントキャリアの残りリソース情報を確定し、前記残りリソース情報に基づいてターゲットキャリアを確定することと、
   さらにソースキャリアとターゲットキャリアに基づいて調整対象端末を確定し、調整対象端末の各ベアラのリソース情報に基づいて負荷調整しようとするベアラを確定することと、
   選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うことと、を含むキャリア間の負荷調整方法。
2. 前記リソース情報がコンポーネントキャリアのＰＲＢ使用率又は速度である請求項１に記載の方法。
3. 前記各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定することが、
   各コンポーネントキャリアの利用済みリソース情報を周期的に測定して測定結果を得ることと、
   測定結果について濾過を行って濾過値を得ることと、
   濾過値と負荷調整トリガー閾値とを比較することと、
   濾過値が負荷調整トリガー閾値を超えると、該キャリアを負荷調整を行う必要のあるソースキャリアと確定することと、を含む請求項１に記載の方法。
4. 各コンポーネントキャリアの利用済みリソース情報を周期的に測定する測定周期が無線負荷バランシング周期より短い請求項３に記載の方法。
5. 前記濾過が平滑値又は平均値をとることである請求項３に記載の方法。
6. 前記負荷調整トリガー閾値が無線負荷バランシング実行閾値未満である請求項３に記載の方法。
7. 各アクティブ状態になったコンポーネントキャリアの残りリソース情報を確定することは、該キャリアの利用可能なリソースにピンポン防止閾値をかけ算してから利用済みのリソースを減ることである請求項１に記載の方法。
8. 前記残りリソース情報に基づいてターゲットキャリアを確定することが具体的に、前記残りリソース情報に基づいて、各アクティブ状態になったコンポーネントキャリアの順位をつけ、該排列からターゲットキャリアを選択することである請求項１に記載の方法。
9. 前記ピンポン防止閾値が負荷調整トリガー閾値以下である請求項７に記載の方法。
10. 前記残りリソース情報に基づいて各アクティブ状態になったコンポーネントキャリアの順位をつけることが、残りリソース情報の大きい順又はランダムの方式で順位をつけることである請求項８に記載の方法。
11. 前記排列からターゲットキャリアを選択することが具体的に、前記ソースキャリアよりも負荷が一定の差異閾値低く、残りリソースが最も多いキャリアをターゲットキャリアとして選択することである請求項８に記載の方法。
12. 前記差異閾値が１０％〜２０％である請求項１１に記載の方法。
13. 前記ソースキャリアとターゲットキャリアに基づいて調整対象端末を確定することが具体的に、ソースキャリアをＳｃｅｌｌとしターゲットキャリアをＰｃｅｌｌとする端末を戻し対象端末と確定し、ソースキャリアをＰｃｅｌｌとしターゲットキャリアをＳｃｅｌｌとする端末を移動分割対象端末とすることである請求項１に記載の方法。
14. 前記調整対象端末の各ベアラのリソース情報に基づいて負荷調整しようとするベアラを確定することが具体的に、戻し対象端末、移動分割対象端末と確定された端末からソースキャリア上で占用したリソースが最大なベアラを負荷調整しようとするベアラとして選択することである請求項１３に記載の方法。
15. 前記選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラに負荷調整を行うことが具体的に、負荷調整しようとするベアラが戻し対象ベアラのみである場合、該戻し対象ベアラに戻しを行うことである請求項１４に記載の方法。
16. 前記選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うことが具体的に、負荷調整しようとするベアラが移動分割対象ベアラのみである場合、該移動分割しようとするベアラについてまず移動を行って、移動に成功しないと分割を行うことである請求項１４に記載の方法。
17. 前記選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うことが具体的に、負荷調整しようとするベアラが移動分割対象ベアラのみである場合、該移動分割しようとするベアラに分割を行うことである請求項１４に記載の方法。
18. 前記選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラに負荷調整を行うことが具体的に、負荷調整しようとするベアラに戻し対象ベアラと移動分割対象ベアラが同時に存在する場合、まず戻し対象ベアラについて戻しを行い、戻しに失敗した後に移動分割を行うことである請求項１４に記載の方法。
19. 該戻し対象ベアラについて戻しを行う前に、該戻し対象ベアラのソースキャリア上の利用済みのリソースとターゲットキャリアの残りリソースとを比較し、ソースキャリアの利用済みのリソースがターゲットキャリアの残りリソース以下であると、戻しを行い、そうでなければ、戻しを行わない請求項１５に記載の方法。
20. 該戻し対象ベアラについて戻しを行った後、該ベアラが集約したソースキャリアとしてのＳｃｅｌｌについて非アクティブ化処理を行う請求項１５に記載の方法。
21. 前記戻しは、該ベアラがＳｃｅｌｌ上でスケジューリングしたリソースをＰｃｅｌｌに戻してスケジューリングすることである請求項１５に記載の方法。
22. 前記選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラに負荷調整を行うことが具体的に、負荷調整しようとするベアラが移動分割対象ベアラのみである場合、該移動分割しようとするベアラにまず移動を行い、移動に成功しないと分割を行うことである請求項１４に記載の方法。
23. 前記移動を行う前、移動分割対象ベアラのソースキャリアの利用済みのリソースとターゲットキャリアの残りリソースを比較し、比較結果に基づいて移動又は分割を確定する請求項２０に記載の方法。
24. 前記比較結果に基づいて移動又は分割を確定することが具体的に、移動分割しようとするベアラのソースキャリアの利用済みのリソースがターゲットキャリアの残りリソース以下であると、移動を行い、そうでなければ、分割を行うことである請求項２０に記載の方法。
25. 前記移動は、該ベアラがＰｃｅｌｌ上でスケジューリングしたリソースをＳｃｅｌｌに移動してスケジューリングすることである請求項１９乃至２１の中のいずれかに記載の方法。
26. 前記分割は、該ベアラがＰｃｅｌｌ上でスケジューリングしたリソースをアクティブ状態になったＳｃｅｌｌに分割してスケジューリングを行うことである請求項２２に記載の方法。
27. 前記分割は、全てのアクティブ状態になったＳｃｅｌｌの残りリソースの合計がＰｃｅｌｌの利用済みのリソース未満である場合、Ｓｃｅｌｌをアクティブ状態にし、該ベアラがＰｃｅｌｌ上でスケジューリングしたリソースをアクティブ前とアクティブ後のＳｃｅｌｌ上で分割を行うことである請求項２２に記載の方法。
28. 前記分割は、該ベアラが集約した全てのＳｃｅｌｌをアクティブ状態にした後、全てのＳｃｅｌｌの残りリソースの合計が該ベアラが集約したＰｃｅｌｌの利用済みのリソース未満である場合、Ｓｃｅｌｌ上でスケジューリングできないリソースをＰｃｅｌｌ上でスケジューリングすることである請求項２２に記載の方法。
29. 前記選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うことが具体的に、負荷調整を行う必要のあるベアラが移動分割対象ベアラのみである場合、該移動分割を行う必要のあるベアラについて分割を行うことである請求項１４に記載の方法。
30. 前記選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラについて負荷調整を行うことが具体的に、負荷調整しようとするベアラに戻し対象ベアラと移動分割対象ベアラが同時に存在する場合、まず戻し対象ベアラについて戻しを行い、戻しに失敗した後に移動分割を行うことである請求項１４に記載の方法。
31. 各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定することと、
    前記ソースキャリアを集約した端末において各ベアラのリソース情報に基づいて負荷調整しようとするベアラを確定することと、
    前記負荷調整しようとするベアラに対応するキャリアにおいてリソース情報に基づいてターゲットキャリアを確定することと、
    選別したソースキャリアとターゲットキャリアに基づいて負荷調整を行う必要のあるベアラについて負荷調整を行うことと、を含むキャリア間の負荷調整方法。
32. 各コンポーネントキャリアの利用済みリソース情報を取得し、前記利用済みリソース情報に基づいて負荷調整を行う必要のあるソースキャリアを確定するように構成されるソースキャリア確定モジュールと、
    各アクティブ状態になったコンポーネントキャリアの残りリソース情報を確定し、前記残りリソース情報に基づいてターゲットキャリアを確定するように構成されるターゲットキャリア確定モジュールと、
    ソースキャリアとターゲットキャリアに基づいて調整対象端末を確定し、調整対象端末の各ベアラのリソース情報に基づいて負荷調整しようとするベアラを確定するように構成される調整対象ベアラ確定モジュールと、
    選別したソースキャリアとターゲットキャリアに基づいて負荷調整しようとするベアラに負荷調整を行うように構成される調整モジュールと、を含むキャリア間の負荷調整装置。
33. 請求項２９に記載の装置を含むキャリア間の負荷調整システム。
    

Images