JP2015537458A - Ｒａｔ相互間のモビリティ設定を協調するための方法 - Google Patents

Abstract

ハンドオーバを協調するためのシステム、方法、および装置が提示されている。第１のＲＡＮセルと関連する第１のコントローラ（１０５）が、第１のＲＡＮセルから異なるＲＡＴを有する第２のＲＡＮセルへのハンドオーバを生じさせるべきかどうかを判断するときに用いられるための第１のハンドオーバパラメータ値を決定する（７０２）。第１のコントローラ（１０５）は、第２のＲＡＮセルと関連する第２のコントローラ（１１２）へ、第１のハンドオーバパラメータ値に関する情報を送信する（７０２）。第１のコントローラは、更に第２のコントローラへ、情報と関連するＱｏＳパラメータまたはＵＥ性能パラメータの値を通知する（７０４）。第１のコントローラは、第２のコントローラから、第２のコントローラが、送信された情報に基づいて第２のハンドオーバパラメータ値を調節したかどうかに関する指標を受信する（７０４）。ここで、第２のハンドオーバパラメータ値は、第２のＲＡＮセルから第１のＲＡＮセルへのハンドオーバを生じさせるべきかどうかを判断するときに用いるためのものである。【選択図】図１

Description

関連出願の相互参照
本出願は、２０１２年１１月２日に出願され「Ｅｎｈａｎｃｅｍｅｎｔｓ ｏｎ Ｉｎｔｅｒ−ＲＡＴ Ｍｏｂｉｌｉｔｙ Ｓｅｔｔｉｎｇ Ｃｏｏｒｄｉｎａｔｉｏｎ」と題される米国特許仮出願第６１／７２１，５８６号の優先権を主張する。

本開示は、ＲＡＴ相互間でのモビリティ設定を協調するためのシステム、方法、装置、およびコンピュータプログラム製品に関する。

異なる無線アクセス技術（ＲＡＴ）の間でのユーザ機器（ＵＥ）のモビリティは、あるＲＡＴを用いるセル（例えば、ＵＴＲＡＮ）から別のＲＡＴを用いるセル（例えば、ｅ−ＵＴＲＡＮ）への、ＲＡＴ相互間におけるハンドオーバによって達成され得る。ハンドオーバは、ＵＥの現在のセルにおける参照信号またはターゲットセルにおける参照信号の品質が一定の条件を満たすイベントのようなモビリティイベントによって、トリガすることが可能である。

ｅ−ＵＴＲＡＮの場合には、信号品質は、参照信号受信電力（ＲＳＲＰ）、参照信号受信品質（ＲＳＲＱ）、およびいずれかの他の信号品質パラメータの中の１つまたは複数によって示され得る。ＵＴＲＡＮの場合には、信号品質は、受信信号コード電力（ＲＳＣＰ）、受信信号強度インジケータ（ＲＳＳＩ）、ＥｃＮｏ（すなわち、ＲＳＣＰ／ＲＳＳＩ）およびいずれかの他の信号品質パラメータの中の１つまたは複数によって示され得る。

ｅ−ＵＴＲＡＮセルからＵＴＲＡＮセルへのハンドオーバは、Ｂ２と称されるモビリティイベントが生じるときに、トリガされ得る。イベントＢ２は、信号品質が２つの条件Ｂ２−１およびＢ２−２を満たすときに生じる。すなわち、
条件Ｂ２−１は、Ｍｐ＋Ｈｙｓ＜Ｔｈｒｅｓｈ１＝Ｂ２＿１であるときに、満たされる。
条件Ｂ２−２は、Ｍｎ＋Ｏｆｎ−Ｈｙｓ＞Ｔｈｒｅｓｈ２＝Ｂ２＿２であるときに、満たされる。

Ｍ_ｐは、サービングセル（すなわち、ｅ−ＵＴＲＡＮセル）からの信号（例えば、参照信号）の測定値を指しており、ＲＳＲＰの場合にはｄＢｍ単位で、ＲＳＲＱの場合にはｄＢ単位で表現され得る。Ｍ_ｎは、ターゲットセル（すなわち、ＵＴＲＡＮセル）からの信号（例えば、参照信号）の測定値を指す。Ｈｙｓは、ヒステリシスパラメータを指す。Ｏｆｎは、隣接セルの周波数の周波数固有オフセットである。

これらの条件は、ｅ−ＵＴＲＡＮからＵＴＲＡＮへのハンドオーバは、ｅ−ＵＴＲＡＮセルにおける信号品質が閾値Ｂ２＿１よりも悪くなり、かつ、ＵＴＲＡＮセルにおける信号品質が閾値Ｂ２＿２よりもよくなるとトリガされる、ということを示す。イベントＢ２は、ＴＳ ３６．３３１において、より詳細に論じられている。ｅ−ＵＴＲＡＮからＵＴＲＡＮへのハンドオーバは、「Ｂ１」と名付けられたイベントによってもトリガされ得るのであるが、Ｂ１は、Ｂ１−ｂが満たされるときに、生じる。すなわち、
条件Ｂ１−ｂは、Ｍｎ＋Ｏｆｎ−Ｈｙｓ＞Ｔｈｒｅｓｈ＝Ｂ１＿ｂであるときに、満たされる。

ＵＴＲＡＮからｅ−ＵＴＲＡＮへという他方の方向のハンドオーバは、「３Ａ」と称されるモビリティイベントまたは「３Ｃ」と称されるモビリティイベントによって、トリガされ得る。イベント３Ａは、２つの条件３Ａ−１および３Ａ−２が満たされるときに生じる。すなわち、
条件３Ａ−１は、Ｑ_Ｕｓｅｄ＋Ｈ３ａ／２＜Ｔ_Ｕｓｅｄ＝３Ａ＿ａであるときに、満たされる。
条件３Ａ−２は、Ｍ_{ＯｔｈｅｒＲＡＴ}＋ＣＩＯ_{ＯｔｈｅｒＲＡＴ}−Ｈ３ａ／２＞Ｔ_{ＯｔｈｅｒＲＡＴ}＝３Ａ＿ｂであるときに、満たされる。

これらのパラメータは、ＴＳ ２５．３３１において、より詳細に論じられている。閾値３Ａ＿ａは３Ａ＿１とも称され、閾値３Ａ＿ｂは３Ａ＿２とも称され得る。イベント３Ｃは、Ｍ_{ＯｔｈｅｒＲＡＴ}＋ＣＩＯ_{ＯｔｈｅｒＲＡＴ}≧Ｔ_{ＯｔｈｅｒＲＡＴ}＋Ｈ_３ｃ／２という単一の条件が満たされるときに、生じる。イベント３Ａおよび３Ｃは、ＵＴＲＡＮセルにおける信号品質が閾値３Ａ＿１よりも悪くなり、かつ、ｅ−ＵＴＲＡＮセルにおける信号品質が閾値３Ａ＿２よりもよくなる状況を一般的に表している。

本開示では、閾値をトリガするものとしてイベントＢ１およびＢ２に言及しているが、より一般的には、これらのイベントは、ハンドオーバを生じさせるべきかどうかを決定するときに用いられるためのものである。すなわち、それぞれのイベントは、ＵＥからそのＵＥのサービングセルの基地局への、信号測定の報告をトリガし得る。サービングセルのコントローラ（例えば、ｅＮＢ、ＮＢ、またはＲＮＣ）は、サービングセルから別のセルへのハンドオーバを生じさせるべきかどうかを決定するために、この測定を用いることができる。

異なる無線アクセス技術（ＲＡＴ）の間でのハンドオーバのためなど、ハンドオーバの最適化を協調するための、システム、方法、および装置が提供される。ある実施形態では、第１の無線アクセスネットワーク（ＲＡＮ）のコントローラ（「第１のコントローラ」）が、第１のＲＡＮセルから第１のＲＡＮセルとは異なる無線アクセス技術（ＲＡＴ）を有する第２のＲＡＮセルへのハンドオーバを生じさせるべきかどうかを決定するときに用いるための第１のハンドオーバパラメータ値を決定する。

第１のコントローラは、第２のＲＡＮセルのコントローラ（「第２のコントローラ」）に、第１のハンドオーバパラメータ値に関する情報を通知する。

第１のコントローラは、更に、第２のコントローラへ、第１のハンドオーバパラメータ値に関する情報と関連するサービス品質（ＱｏＳ）パラメータまたはユーザ機器（ＵＥ）性能パラメータの値を通知する。ＱｏＳパラメータとは、第１のＲＡＮセルまたは第２のＲＡＮセルによってサービスを受けているユーザ機器（ＵＥ）に提供されるか提供されると予想されるサービスのレベルを示す。ＵＥ性能パラメータとは、ＵＥ性能を示す。ある実施形態では、第１のハンドオーバパラメータ値に関する情報とＱｏＳパラメータまたはＵＥ性能パラメータの値とが、ＲＡＮ情報管理（ＲＩＭ）メッセージの一部として送られる。

第１のコントローラは、通知された情報に基づいて第２のコントローラが第２のハンドオーバパラメータ値を調節したかどうかに関する指標を、第２のコントローラから受信する。第２のハンドオーバパラメータ値は、第２のＲＡＮセルから第１のＲＡＮセルへのハンドオーバを生じさせるべきかどうかを決定するときに用いるためのものである。

ある実施形態では、第１のハンドオーバパラメータ値は、ハンドオーバ条件が満たされたかどうかを判断するために用いられる第１のハンドオーバ閾値であり、第２のハンドオーバパラメータ値は、ハンドオーバ条件が満たされたかどうかを判断するために用いられる第２のハンドオーバ閾値である。

ある実施形態では、第１のコントローラは、第１のハンドオーバ閾値に基づき、第２のハンドオーバ閾値の調節値を決定する。この実施形態では、通知された情報は、第２のハンドオーバ閾値の調節値を含み、受信された指標は、第２のコントローラが第２のハンドオーバ閾値の調節値を受け入れるかどうかに関する指標を含む。

ある実施形態では、通知された情報は、第１のハンドオーバ閾値を含み、受信された指標は、第１のハンドオーバ閾値に基づき第２のコントローラが第２のハンドオーバ閾値の調節を行ったかどうかに関する指標を含む。

ハンドオーバを協調するためのシステムにおける複数のノードの図解である。 ハンドオーバ閾値に関する信号ダイアグラムの図解である。 ハンドオーバ閾値に関する信号ダイアグラムの図解である。 ハンドオーバ閾値に関する信号ダイアグラムの図解である。 ハンドオーバ閾値に関する信号ダイアグラムの図解である。 ハンドオーバ閾値に関する信号ダイアグラムの図解である。 ＵＥデータを搬送するための様々な信号ベアラの図解である。 ハンドオーバ閾値に関する信号ダイアグラムの図解である。 ハンドオーバ閾値に関する信号ダイアグラムの図解である。 本開示の実施形態による流れ図の図解である。 本開示の実施形態による流れ図の図解である。 本開示の実施形態による流れ図の図解である。 本開示の実施形態による流れ図の図解である。 本開示の実施形態による流れ図の図解である。 本開示の実施形態による信号ダイアグラムの図解である。 本開示の実施形態による信号ダイアグラムの図解である。 本開示の実施形態による信号ダイアグラムの図解である。 本開示の実施形態による信号ダイアグラムの図解である。 本開示の実施形態による信号ダイアグラムの図解である。 本開示の実施形態による信号ダイアグラムの図解である。 本開示の実施形態による無線アクセスネットワーク（ＲＡＮ）コントローラの図解である。 本開示の実施形態による無線アクセスネットワーク（ＲＡＮ）コントローラの図解である。 本開示の実施形態によるＵＥの図解である。

本開示は、異なる無線アクセス技術（ＲＡＴ）を有する無線アクセスネットワーク（ＲＡＮ）の間における過剰な回数の双方向のハンドオーバを回避しながら、ハンドオーバを用いて無線リンク障害（ＲＬＦ）を減少させることにより、モビリティのロバスト性を向上させることに関する。より詳しくは、本開示は、異なるＲＡＴを有する２つ以上のＲＡＮの間で、モビリティ設定（例えば、ハンドオーバパラメータ）の調節を協調することを含む。より特定の例では、本開示は、モビリティ負荷バランスシナリオにおける「ピンポン」回避を向上させることを扱う。

図１は、基地局１０４によって提供されるセルと基地局１０６によって提供される別のセルとの間でのＵＥ１０２のハンドオーバを協調するための例示的なシステム１００を図解している。ある実施形態では、基地局１０４と基地局１０６とは、異なるＲＡＴを用いる。例えば、基地局１０４は、ＬＴＥのためにｅ−ＵＴＲＡＮセルを提供するｅＮＢであり、他方で、基地局１０６は、ＵＭＴＳのためにＵＴＲＡＮセルを提供するＮＢ、または、ＧＳＭのためにＧＥＲＡＮセルを実装する基地局である。ハンドオーバは、基地局１０４のＲＡＮセルからの信号１１４（例えば、ｅ−ＵＴＲＡＮ参照信号）に関して、および／または、基地局１０６のＲＡＮセルからの信号１１６（例えば、ＵＴＲＡＮ参照信号）に関して、ＵＥ１０２が行う測定に基づき得る。例えば、１つまたは複数の測定値が、一定の閾値を満たすなど、一定の条件を満たすときには、ハンドオーバイベントがトリガされ得る。ハンドオーバイベントは、ＵＥに、そのサービングセル（ｓｅｒｖｉｎｇ ｃｅｌｌ）の基地局に測定を報告させる。その後、サービングセルのコントローラは、そのＵＥはサービング側のＲＡＮセルからターゲット側のＲＡＮセルにハンドオーバされるべきであると決めることができる。

サービング側のＲＡＮセルからターゲット側のＲＡＮセルへのモビリティイベント（ハンドオーバイベント）をトリガする条件は、サービング側のＲＡＮセルによって設定され得る。例えば、コントローラ１０５は、基地局１０４によって提供されるＲＡＮセルから別のセルへのハンドオーバをトリガする条件を定義するハンドオーバパラメータ値（例えば、ハンドオーバ閾値）を設定し得る（すなわち、ハンドオーバパラメータは、そのようなハンドオーバが生じるべきかどうかを判断するのに用いられる）。より一般的にいえば、ＵＥは、計算された値（例えば、Ｍ_ｐ＋Ｈｙｓ）を周期的に生成し得るのであって、計算された値がハンドオーバ閾値を超える（例えば、Ｂ２＿１を下回る）場合には、ＵＥは、信号測定値（例えば、Ｍ_ｐ）をコントローラ１０５に報告する。そして、コントローラ１０５は、報告を用いて、別のセルへのＵＥのハンドオーバを生じさせるべきかどうかを判断する。ハンドオーバを生じさせるべきかどうかを判断するときには、コントローラ１０５は、例えば、ハンドオーバ閾値、モビリティ負荷バランス関数、またはそれらのいずれかの組合せとの関係で、信号測定値を考察し得る。

同様に、コントローラ１１２は、ハンドオーバを生じさせるべきかどうかを判断するときに用いるためのハンドオーバパラメータ値（例えば、ハンドオーバ閾値）を設定し得る。なお、ハンドオーバパラメータ値とは、基地局１０６によって提供されるＲＡＮセルから別のセルへのハンドオーバをトリガする条件を定義する値などである。それぞれのコントローラは、閾値をＵＥに送信し得る。ＵＥは、それらの閾値を用いてハンドオーバイベントを検出する。より一般的にいえば、ＵＥは、計算された値（例えば、Ｍ_{ＯｔｈｅｒＲＡＴ}＋ＣＩＯ_{ＯｔｈｅｒＲＡＴ}−Ｈ_３ａ／２）を周期的に生成し得るのであって、計算された値がハンドオーバ閾値を超える（例えば、３Ａ＿２を上回る）場合には、ＵＥは、信号測定値（例えば、Ｍ_{ＯｔｈｅｒＲＡＴ}）をコントローラ１１２に報告する。そして、コントローラ１１２は、報告を用いて、別のセルへのＵＥのハンドオーバを生じさせるべきかどうかを判断する。ハンドオーバを生じさせるべきかどうかを判断するときには、コントローラ１１２は、例えば、ハンドオーバ閾値、モビリティ負荷バランス関数、またはそれらのいずれかの組合せとの関係で、信号測定値を考察し得る。いくつかの場合において、基地局１０６がＮＢである場合には、コントローラ１１２は無線ネットワークコントローラ（ＲＮＣ）である。ある実施形態では、基地局１０４のコントローラは、基地局１０４の一部（例えば、ｅＮＢの一部）であり得るし、および／または、ネットワークノード（例えば、ＭＭＥノード）であり得る。

コントローラ１０５、１１２は、それらのコアネットワーク１０８、１１０を通じて情報を通信することにより、モビリティ設定の調節などのハンドオーバ情報を協調し得る。モビリティ設定は、１つまたは複数のハンドオーバ閾値など、ハンドオーバイベントが生じたかどうかを示すための１つまたは複数のパラメータ（すなわち、１つまたは複数のハンドオーバパラメータ）を含み得る。ある実施形態では、協調は、閾値Ｂ２＿１または３Ａ＿２など、１つまたは複数のハンドオーバ閾値の通信を含む。そのような閾値の通信は、後でより詳細に論じられる。

ハンドオーバ閾値は、ハンドオーバをトリガするためには、サービング側のＲＡＮセルにおける信号品質がどれだけ劣化しなければならないのか、および／または、ターゲット側のＲＡＮセルにおける信号品質がどれだけよくなければならないのか、を制御し得る。ＵＥがセルの基地局から更に離れる方向に移動することによって生じるものなど、ＵＥのサービングセルにおける信号品質の劣化は、ＵＥがターゲットセルにハンドオーバされない場合には、結果的に無線リンク障害（ＲＬＦ）に至り得る。

ハンドオーバ閾値などのモビリティ設定を調節することで、ＲＬＦの発生を削減し得る。図２Ａは、ハンドオーバ閾値Ｂ２＿１が調節された場合を、図解している。閾値は、ｅ−ＵＴＲＡＮセルにおける信号品質を反映し、ｅ−ＵＴＲＡＮセルからＵＴＲＡＮセルへのハンドオーバをトリガするのに用いられる。そのようなハンドオーバイベントは閾値Ｂ２＿２にも依存し、閾値Ｂ２＿２はターゲットＵＴＲＡＮセルにおける信号品質と関連するのであるが、この実施形態では、ＵＴＲＡＮがカバーする範囲は十分に広いために、一般的にはその信号品質はハンドオーバをサポートすると想定される。よって、この実施形態は、ｅ−ＵＴＲＡＮセルにおける信号品質と閾値Ｂ２＿１とだけを扱う。他の実施形態は、さらにＵＴＲＡＮの信号品質を考慮することもあり得る。

図２Ａは、ユーザケース１と称される場合を図解している。この場合、ＵＥがｅ−ＵＴＲＡＮセルによってサービスを提供されている間に、または、ｅ−ＵＴＲＡＮセルからＵＴＲＡＮセルへのハンドオーバの間に、ＲＬＦが生じる。例えば、ハンドオーバが開始された直後にＲＬＦ条件が生じる場合には、障害はハンドオーバの間に生じ得る。この例では、ハンドオーバは、成功裏のうちに完了しないことがあり得る。

ユーザケース１におけるＲＬＦの発生を削減させるひとつの方法は、ｅ−ＵＴＲＡＮセルからＵＴＲＡＮセルへのハンドオーバをトリガするハンドオーバ閾値を緩和することである。例えば、図２Ａは、閾値Ｂ２＿１が低いときにＲＬＦが生じがちであることを示している。ハンドオーバのための閾値を緩和することによって（より詳しくはＢ２＿１を上昇させることによって）、ＲＬＦのおそれを低下させることができる。閾値を上昇させると、ｅ−ＵＴＲＡＮセルにおける信号品質がＲＬＦの段階まで劣化する前に、ＵＥがＵＴＲＡＮセルによりハンドオーバされやすくなる。

ＲＬＦの発生を削減させるために、ｅ−ＵＴＲＡＮセルのコントローラがＢ２＿１を上昇させ得るが、過剰な回数のハンドオーバを回避するために、Ｂ２＿１を低下させてもよい。すなわち、Ｂ２＿１のようなハンドオーバ閾値（または、いずれかの他のハンドオーバパラメータ）を緩和させることの副作用は、緩和された閾値が不必要なハンドオーバの蓋然性を上昇させ得るということである。例えば、図２Ｂは、図２Ａの場合より優れた信号品質をＵＥが経験していることを示しており、この場合にはハンドオーバが不要である。ＵＥは、図２Ａの場合と比較して、より優れた信号品質を経験することができるが、その理由は、ＵＥが異なる位置にあるから、異なる時間（例えば、別の日）において信号品質を経験しているから、または何らかの他の理由による。図２Ｂに示されているように、Ｂ２＿１閾値が上昇すると、不必要なハンドオーバがトリガされる。

よって、ハンドオーバ閾値は、ＲＬＦのおそれを低下させることと、不必要なハンドオーバのおそれを低下させることとの間のトレードオフを均衡させるように、調節され得る。ＲＡＮコントローラにおけるＲＡＴ相互間のモビリティのロバスト性最適化（ＩＲＡＴ ＭＲＯ）機能は、このトレードオフを考慮してハンドオーバ閾値を調節し得る。ＴＳ４８．０１７、ＴＳ４８．０１８、ＴＳ３６．４１３、およびＴＳ２５．４１３で規定されているように、ＲＬＦ報告は、遅すぎる時点で生じたハンドオーバについての、または、不必要なハンドオーバについての統計を収集するために、生成され得る。この統計は、ハンドオーバ閾値を調節するために、用いることができる。

トレードオフは、また、ＵＴＲＡＮからｅ−ＵＴＲＡＮへのハンドオーバの場合について、図３Ａおよび図３Ｂに図解されている。これらの図には、閾値３Ａ＿２の調節が示されており、この閾値３Ａ＿２は、ターゲットｅ−ＵＴＲＡＮセルにおける信号品質を示す。ハンドオーバイベント３Ａもまた、閾値３Ａ＿１に依存し、この閾値３Ａ＿１は、サービング側のＵＴＲＡＮセルにおける信号品質を示す。しかしながら、この実施形態では、ＵＴＲＡＮがカバーする範囲は十分に広いために、ハンドオーバが生じるのは、ＵＴＲＡＮの信号品質が劣るという理由ではなく、ｅ−ＵＴＲＡＮの方がＵＴＲＡＮよりも好ましい場合であってｅ−ＵＴＲＡＮセルにおける信号品質がハンドオーバをサポートすることを理由とすることが想定されている。他の実施形態では、ＵＴＲＡＮの信号品質も考慮することがあり得る。

図３Ａは、ユーザケース２と称される場合におけるＲＬＦを図解している。この図は、ターゲットｅ−ＵＴＲＡＮセルにおける信号品質はハンドオーバをサポートしないところまで劣化するということを示している。しかし、閾値３Ａ＿２の設定が低すぎるために、信号品質の若干の改善があると、サービング側のＵＴＲＡＮセルからｅ−ＵＴＲＡＮセルへのハンドオーバがトリガされる。ハンドオーバの後では、ｅ−ＵＴＲＡＮセルにおける信号品質はその劣化が再び生じて、ＲＬＦに至る。ユーザケース２におけるＲＬＦは、閾値３Ａ＿２を上昇させるなど、ハンドオーバ閾値（または、いずれかの他のハンドオーバパラメータ）をより厳格にすることによって、対抗することが可能である。図２Ａに更に示されているように、閾値３Ａ＿２を上昇させることで、ＵＥがＵＴＲＡＮに留まり、よって、ＲＬＦのおそれが低下することが保証される。

しかし、ハンドオーバパラメータをより厳格にすると、ＵＴＲＡＮからｅ−ＵＴＲＡＮへのハンドオーバのための機会も失われる。図３Ｂに示されているように、ｅ−ＵＴＲＡＮセルにおける信号品質がハンドオーバをサポートするのに十分である場合には、３Ａ＿２という閾値を上昇させても、依然として、ハンドオーバが回避される。これによって、ＵＥがＵＴＲＡＮに存在する時間が不必要に長くなり、ＬＴＥがカバーする範囲が縮小する。

ＵＴＲＡＮセルのコントローラは、ＩＲＡＴ ＭＲＯ機能を実装してもよく、この場合には、ＲＬＦのおそれを低下させることとハンドオーバの機会喪失を回避することとトレードオフを均衡させるように、３Ａ＿２閾値を調節することができる。

しかし、単一の閾値Ｂ２＿１または３Ａ＿２（または、いずれかの他のハンドオーバ閾値）のみの調節をＲＡＮセルに適用するのは最適ではないかもしれない。その理由は、上で論じられたトレードオフは、ＵＥが異なるか、１つのＵＥ上で動作しているアプリケーションが異なると、異なる態様で均衡し得るからである。例えば、アプリケーションが異なると、ＲＬＦまたは過剰なハンドオーバの発生率が異なりうる。リアルタイムのサービス（例えば、ビデオチャットアプリケーション）を提供するＵＥアプリケーションは、リアルタイムではないサービス（例えば、ファイル転送アプリケーション）を提供するＵＥアプリケーションよりも、ＲＬＦに対して敏感であることが多い。よって、リアルタイムのＵＥアプリケーションは、ＲＬＦに対する寛容度がより低いが、過剰なハンドオーバまたはＵＴＲＡＮにおける長い滞在時間については、より寛容である。他方で、リアルタイムではないＵＥアプリケーションは、ＲＬＦについてはより寛容であり得るが、過剰なハンドオーバまたはＵＴＲＡＮにおける長い滞在時間については、寛容度が低い。後者の状況はスループットを低下させるから、というのがその理由である。

ある実施形態では、リアルタイムのＵＥアプリケーションとリアルタイムではないＵＥアプリケーションとは、様々な基準に基づき、区別され得る。区別基準には、それぞれのアプリケーションに関連づけられるサービスの品質（ＱｏＳ）またはＵＥの性能が含まれ得る。よって、ある実施形態では、異なるハンドオーバパラメータ値（例えば、異なるハンドオーバ閾値）が、特定の（ＱｏＳ）パラメータの特定の値に、および／または、特定のＵＥ性能パラメータの特定の値に、適用され得る。

ＱｏＳパラメータは、ＵＥ上で動作しているアプリケーションのためのデータを搬送している信号ベアラと関連し得る。例えば、ＱｏＳパラメータは、ＱｏＳクラスインジケータ（ＱＣＩ）を含み、ＵＥのためのデータを搬送している特定の信号ベアラにどのようなＱＣＩ値が割り当てられるのかに基づいて、異なるハンドオーバ閾値が適用され得る。図４は、２つの異なるＱＣＩ値に基づくハンドオーバ閾値Ｂ２＿１への２つの異なる調節を図解している。この例では、２つの異なる調節が、同じＵＥに対して適用され得る。例えば、ＵＥで動作しているリアルタイムのアプリケーションは、ＱＣＩが４である信号ベアラを用いてデータを転送し、他方で、ＵＥで動作しているリアルタイムではないアプリケーションは、ＱＣＩが２である信号ベアラを用いてデータを転送し得る。

２というＱＣＩ値と関連するアプリケーションは、ＲＬＦに関して寛容度がより低いが、過剰なハンドオーバに関しては、より寛容であり得る。よって、ハンドオーバ閾値Ｂ２＿１を上昇させて、ＲＬＦのおそれを低下し得る。このＵＥアプリケーションが、信号４０２Ｂによって表されているような信号品質の劣化を後で経験する場合には、Ｂ２＿１の閾値を上昇させると、ハンドオーバがトリガされ、ＲＬＦを回避し得る。

４というＱＣＩ値と関連するアプリケーションは、ＲＬＦに関してはより寛容であり得るが、過剰なハンドオーバに関しては寛容度がより低いことがあり得る。例えば、ｅ−ＵＴＲＡＮセルでＲＬＦを経験するファイル転送アプリケーションは、ｅ−ＵＴＲＡＮセルとの無線接続を簡単に再確立して、ファイル転送を再開し得る。しかし、過剰なハンドオーバは、アプリケーションに対するファイル転送速度を低下させ得る。よって、図４に図解されているように、ハンドオーバ閾値Ｂ２＿１は、ＱＣＩが４である信号ベアラを用いるアプリケーションに対しては、より低くして、ハンドオーバのおそれを低下させる。

ＵＥ性能パラメータは、例えば、ＵＥカテゴリ、ＵＥ無線リソース管理（ＲＲＭ）コンフィギュレーション（例えば、ＤＲＸコンフィギュレーション）、ＵＥの加入タイプ、ＵＥの端末モデル、およびＵＥの速度（例えば、低速なのか、高速なのか）の中の１つまたは複数を含み得る。

図５は、ＱＣＩなどのＱｏＳパラメータが関連する様々な信号ベアラを図解している。ＵＥは、異なるＱｏＳ要件をそれぞれが有するが同時に動作する複数のアプリケーション（例えば、ＶｏＩＰ、ブラウジング、ファイルダウンロード）を有することができる。これらの異なる要件をサポートするために、異なる信号ベアラが設定され、あるＱｏＳパラメータ値とそれぞれが関連している。１つのＥＰＳベアラ／Ｅ−ＲＡＢ（無線アクセスベアラ）は、ＥＰＣ／ｅ−ＵＴＲＡＮにおけるベアラレベルのＱｏＳ制御のための精度（ｇｒａｎｕｌａｒｉｔｙ）のレベルを有する。すなわち、同じＥＰＳベアラにマップされたサービスデータフロー（ＳＤＦ）は、同じベアラレベルのパケット転送処理（例えば、スケジューリングポリシ、キュー管理ポリシ、レート形成ポリシ、ＲＬＣコンフィギュレーションなど）を受ける。

ＥＰＳベアラ／Ｅ−ＲＡＢと関連する保証ビットレート（ＧＲＢ）値に関する専用ネットワークリソースが、ベアラ確立／修正の時点で、（例えば、ｅＮＢにおけるアドミッション制御機能によって）恒久的に割り当てられる場合には、ＥＰＳベアラ／Ｅ−ＲＡＢは、ＧＢＲベアラと称される。そうでない場合には、ＥＰＳベアラ／Ｅ−ＲＡＢは、非ＧＢＲベアラと称される。専用のベアラは、ＧＢＲまたは非ＧＢＲのいずれかのベアラであり、デフォルトのベアラは非ＧＢＲベアラでなければならない。

図５に示されているように、ＥＰＳベアラのパケットは、ＵＥとｅＮＢとの間で、無線ベアラを介して、移送される。Ｓ１ベアラは、ｅＮＢとＳ−ＧＷとの間で、ＥＰＳベアラのパケットを移送する。Ｅ−ＲＡＢは、実際にはこれら２つのベアラ（つまり無線ベアラとＳ１ベアラ）の連結（ｃｏｎｃａｔｅｎａｔｉｏｎ）であり、これら２つのベアラは１対１の態様で、マップされる。Ｓ５／Ｓ８ベアラは、サービングゲートウェイ（Ｓ−ＧＷ）とパケットデータネットワークゲートウェイ（Ｐ−ＧＷ）との間で、ＥＰＳベアラのパケットを移送して、ＥＰＳベアラを完成させる。

上述されたように、ベアラのためのＱｏＳパラメータは、ベアラサービスのＱＣＩ、ＡＲＰ、ＧＢＲ、ＡＭＢＲ、およびいずれかの他の指標（例えば、ベアラがリアルタイムのサービスに対するのか、または、非リアルタイムのサービスに対するものであるのか）の中の１つまたは複数を含む。
・ＱｏＳクラス識別子（ＱＣＩ）：ベアラレベルのパケット転送処理（例えば、スケジューリングウェイト、アドミッション閾値、キュー管理閾値、リンク層プロトコルコンフィギュレーションなど）を制御し、ｅＮｏｄｅＢを所有するオペレータによって予めコンフィギュレーションされたノード固有パラメータにアクセスするための基準として用いられるスカラ値である。ある実施形態では、９つのＱＣＩ値が標準化されており、これらのクラスの詳細な要件は３ＧＰＰ ＴＳ ２３．２０３で入手可能である。
・割り当ておよび保持優先順位（ＡＲＰ）：ＡＲＰの主たる目的は、リソースが限定されている場合に、ベアラ確立／修正要求が受け入れ可能か拒絶されるべきかを決めることである。更に、ＡＲＰは、例外的にリソースが限定されている間に（例えば、ハンドオーバにおいて）、どの（１つまたは複数の）ベアラを排除すべきかを決めるために、ｅＮｏｄｅＢによって用いられることがある。
・保証ビットレート（ＧＢＲ）（ＧＢＲベアラと関連する）：ＧＢＲベアラによって提供されると予想可能なビットレートである。
・最大ビットレート（ＭＢＲ）（ＧＢＲベアラと関連する）：ＧＢＲベアラによって提供されと予想可能な最大ビットレートである。ＭＢＲは、ＧＢＲより大きくても等しくてもよい。

ある実施形態では、ＵＥによるそれぞれのＡＰＮアクセスに対して、ＡＰＮ当たりの総合最大ビットレート（ＡＰＮ−ＡＭＢＲ）が関連づけられる。ＡＰＮ−ＡＭＢＲは、すべての非ＧＢＲベアラに亘り、および、同じＡＰＮのすべてのＰＤＮ接続に亘り、提供されると予想可能な総合ビットレートの限度を設定する。

ある実施形態では、ＥＭＭ−ＲＥＧＩＳＴＥＲＥＤ状態にあるそれぞれのＵＥには、ＵＥ当たりの総合最大ビットレート（ＵＥ−ＡＭＢＲ）として知られている、ベアラ総合レベルのＱｏＳパラメータが関連している。ＵＥ−ＡＭＢＲは、あるＵＥのすべての非ＧＢＲベアラに亘り提供されると予想可能な総合ビットレートを制限する。

ＱｏＳパラメータとＵＥ性能パラメータとに関し以上で論じられてきたが、上記の区別基準には、ＲＬＦ、過剰なハンドオーバ、および／またはより好ましくないＲＡＮにおける長い滞在時間に対する敏感性のレベルを区別する、いずれかの他のパラメータが含まれ得る。

以上で論じられたように、ハンドオーバ条件（例えば、ハンドオーバ閾値）の調節は、ソースＲＡＮセルとターゲットＲＡＮセルとの間での協調が可能である。この協調は、過剰な回数のハンドオーバが生じる「ピンポン」効果を回避するために、そして、カバーされる範囲（例えば、ＬＴＥでのカバーされる範囲）の縮小を回避するために、用いられ得るのであって、ＵＥでは、ソースＲＡＮセルにおいて（例えば、ＵＴＲＡＮセルにおいて）長い滞在時間を費やす。

図６Ａおよび図６Ｂは、「ピンポン」および縮小状況をそれぞれ図解している。両方の図面において、ｅ−ＵＴＲＡＮセルのコントローラは、ｅ−ＵＴＲＡＮセルからＵＴＲＡＮセルへのハンドオーバをトリガする閾値（例えば、Ｂ２＿１）を調節する。しかし、ｅ−ＵＴＲＡＮセルのコントローラは、逆の方向のハンドオーバをトリガし得る閾値（例えば、３Ａ＿２）に関しては、ＵＴＲＡＮセルのコントローラとの間で協調を行わない。結果的に、閾値Ｂ２＿１と３Ａ＿２との間のギャップは、縮小される。このようにギャップが縮小されることにより、ＵＴＲＡＮへのハンドオーバとｅ−ＵＴＲＡＮへハンドオーバされ返すこととの間でＵＥが「ピンポン」するおそれが増加する。例えば、図６Ａは、時間ｔ_１において、信号品質がＵＴＲＡＮセルからｅ−ＵＴＲＡＮセルへのハンドオーバをトリガする状態に近く、時間ｔ_２においては、信号品質がｅ−ＵＴＲＡＮセルからＵＴＲＡＮセルへのハンドオーバをトリガする状態に近い、ということを図解している。

図６Ｂは、ｅ−ＵＴＲＡＮセルのコントローラがＵＴＲＡＮへのハンドオーバをトリガするのに用いられる閾値Ｂ２＿１を低下させるが、ＵＴＲＡＮセルのコントローラが、ｅ−ＵＴＲＡＮに戻るハンドオーバをトリガするための閾値３Ａ＿２を同じレベルで用い続けることを示す。この場合には、Ｂ２＿１と３Ａ＿２との間のギャップが増加する。図面が示しているように、３Ａ＿２の高い値は、信号がＵＴＲＡＮセルに存在する時間を延長させ得る。

次の表１は、他のＲＡＮセルにおける対応する調節を行うことなく、あるＲＡＮセルに対するハンドオーバ条件を調節（ｅ−ＵＴＲＡＮセルに対するＢ２＿１閾値だけ、または、ＵＴＲＡＮセルに対する３Ａ＿２だけの調節など）することの効果の概要を示している。

よって、ある実施形態において、ｅ−ＵＴＲＡＮセルのコントローラ（「ｅ−ＵＴＲＡＮコントローラ」）は、閾値Ｂ２＿１に対して調節を行うか、これから調節を行うであろう場合、ＵＴＲＡＮセルのコントローラ（「ＵＴＲＡＮコントローラ」）との間で協調を試みることができ、それにより、ＵＴＲＡＮコントローラは、閾値３Ａ＿１に対して対応する調節を行うことが可能である。例えば、ｅ−ＵＴＲＡＮコントローラがＢ２＿１を上昇させる場合には、協調により、ＵＴＲＡＮコントローラに３Ａ＿１を上昇させて、２つの閾値の間のギャップを維持することにより、「ピンポン」または縮小効果を減少させてもよい。一方のＲＡＮセルに、Ｂ２＿１閾値または３Ａ＿２閾値を他方のＲＡＮセルに送信させることによって、協調を達成してもよい。例えば、ｅ−ＵＴＲＡＮコントローラは、ＩＲＡＴ ＭＲＯ機能を動作させることにより、ＲＬＦ特性に基づいて閾値Ｂ２＿１を調節してもよい。近隣ＵＴＲＡＮコントローラとの間でこの調節を協調するために、ＵＴＲＡＮコントローラは、３Ａ＿２閾値への対応する調節を計算して、調節された値である３Ａ＿２を近隣ＵＴＲＡＮコントローラへの推奨として通知することができる。ＵＴＲＡＮコントローラは、この調節された３Ａ＿２の値を採用して、Ｂ２＿１と３Ａ＿２との間のギャップを所望の量の範囲内に維持してもよい。あるコントローラから別のコントローラへ単一の閾値を通信することに関する更なる詳細は、２０１３年４月１６日に出願された「モビリティ設定のＲＡＴ相互間での協調（Ｉｎｔｅｒ−ＲＡＴ Ｃｏｏｒｄｉｎａｔｉｏｎ ｏｆ Ｍｏｂｉｌｉｔｙ Ｓｅｔｔｉｎｇｓ）と題するＰＣＴ出願である第ＰＣＴ／ＳＥ２０１３／０５０２４７号において入手可能である。

ある実施形態では、協調は、ＩＲＡＴモビリティ負荷バランス（ＭＬＢ）機能によってトリガされ得る。ＲＡＮセルが最大収容能力に近づいている場合、ＲＡＮセルは、ＵＥがセルの外部へハンドオーバされることを可能にする条件を緩和することと、ＵＥがセルの内部にハンドオーバされることを可能にする条件をより厳格にすることの少なくともいずれかによって、負荷の均衡を実行しようとしてもよい。ある実施形態では、第１のＲＡＮセルのコントローラ（第１のコントローラ）が、第１のハンドオーバパラメータ値（第１のＲＡＮセルから第２のＲＡＮセルへのハンドオーバを生じさせるべきかどうかを判断するのに用いられる）を計算する場合には、第１のコントローラは、関連するＱｏＳパラメータ値またはＵＥ性能パラメータ値と共に、第１のハンドオーバパラメータ値に関する情報を、第２のＲＡＮセルのコントローラ（第２のコントローラ）に通知してもよい。ある場合には、この情報は、第１のハンドオーバパラメータ値に基づく第２のハンドオーバパラメータ値（これは、第２のＲＡＮセルから第１のＲＡＮセルへのハンドオーバを生じさせるべきかどうかを判断するのに用いられる）への計算された調節値を含み得る。計算された調節値は、更に、ＩＲＡＴ ＭＬＢ機能に基づいてもよい。ある場合には、情報は、第１のハンドオーバパラメータ値を含み得る。第２のコントローラは、第１のパラメータ値を受信し、第１のハンドオーバパラメータ値に基づいて、第２のハンドオーバパラメータ値への調節値を計算してもよい。計算された調節値は、更に、ＩＲＡＴ ＭＬＢ機能に基づいてもよい。

ある実施形態では、上で論じられた協調は、ＲＡＮ情報管理（ＲＡＮ ｉｎｆｏｒｍａｔｉｏｎ ｍａｎａｇｅｍｅｎｔ、ＲＩＭ）メッセージを通じて達成されてもよく、このＲＩＭメッセージには、推奨されたハンドオーバ閾値のためのフィールドが含まれる。しかし、そのようなメッセージは、ＲＡＮコントローラは複数のＱｏＳパラメータまたはＵＥ性能パラメータの異なる値に対して複数のハンドオーバ閾値を用い得る、ということを考慮しない。よって、ターゲットセルのコントローラは、ハンドオーバ閾値を受信する場合に、どのＱｏＳパラメータ値またはＵＥ性能パラメータ値をハンドオーバ閾値が適用するのかに関して、曖昧であり得る。従って、ＩＲＡＴ協調のためのメッセージのコンテンツは、どのＱｏＳパラメータ値またはＵＥ性能パラメータ値をハンドオーバ閾値（または、他のハンドオーバ条件）が適用するのかに関する情報が通知可能であるように、更新されることが必要である。

図７は、ハンドオーバ閾値などのハンドオーバパラメータを、第２のＲＡＮセル（例えば、ＵＴＲＡＮセル）と関連する第２のコントローラとの間で協調するために、第１のＲＡＮセル（例えば、ｅ−ＵＴＲＡＮセル）と関連する第１のコントローラによって実行されるプロセス７００を図解する流れ図である。ある実施形態では、第１のコントローラ（例えば、ｅＮＢ）が第１のＲＡＮセルを制御し、第２のコントローラ（例えば、ＲＮＣ）が第２のＲＡＮセルを制御する。プロセス７００によると、第１のコントローラは、ハンドオーバ閾値に関する情報を第２のコントローラへ送配（ｃｏｎｖｅｙ）するだけではなくて、その情報が適用可能な状況を第２のコントローラへ送配することも、可能になる。ある実施形態では、プロセス７００はステップ７０１において開始し、このステップ７０１では、第１のコントローラが、第１のＲＡＮセルから第２のＲＡＮセルへのハンドオーバを生じさせるべきかどうかを決定するときに用いるための第１のハンドオーバパラメータ値を、決定する。ある実施形態では、第１のハンドオーバパラメータ値は、満たされると、ＵＥに信号測定を第１のコントローラに報告させることになる条件を定義する。そして、第１のコントローラは、この報告を用いて、ハンドオーバを生じさせるかべきかどうかを決定する。ある実施形態では、第１のハンドオーバパラメータ値は、第１のＲＡＮセルから第２のＲＡＮセルへのハンドオーバをトリガする条件を定義する。ある例では、第１のＲＡＮセルがｅ−ＵＴＲＡＮセルであり、第２のＲＡＮセルがＵＴＲＡＮセルである場合には、第１のハンドオーバパラメータ値は、閾値Ｂ２＿１、ヒステリシス値、トリガ時間（ｔｉｍｅ−ｔｏ−ｔｒｉｇｇｅｒ）（ＴＴＴ）値、およびＢ２ハンドオーバイベントの条件が満たされるかどうかを判断するのに用いられるいずれかの他の値の中の少なくとも１つを含み得る。第１のハンドオーバパラメータ値の決定は、例えば、ｅＮＢによって実行されているＩＲＡＴ ＭＲＯ機能に基づいてもよい。ある実施形態では、ｅＮＢは、対応する調節を既に行ったことを第２のコントローラがステップ７０６において示さない限り、第１のパラメータ値の使用を開始しない。

ステップ７０２では、第１のコントローラは、第１のハンドオーバパラメータ値に関する情報を、第２のコントローラに通知する。後で更に詳細に論じられるが、ハンドオーバ協調が分散されている（ｄｉｓｔｒｉｂｕｔｅｄ）モードでは、通知された情報は、第１のハンドオーバパラメータ値を含む。第２のコントローラは、次に、第１のハンドオーバパラメータ値に基づき、それ自体のハンドオーバパラメータ値（第２のハンドオーバパラメータ値）を調節する。ハンドオーバ協調が第１のコントローラに集中化されているモードでは、第１のコントローラが、第２のハンドオーバパラメータ値への調節値を計算し、第２のハンドオーバパラメータ値への調節値は通知された情報に含まれる。ある例として、第１のＲＡＮセルがｅ−ＵＴＲＡＮセルであり、第２のＲＡＮセルがＵＴＲＡＮセルである場合には、ｅ−ＵＴＲＡＮのｅＮＢが、Ｂ２＿１閾値を第１のハンドオーバパラメータ値として決定する。協調が分散されている場合には、ステップ７０２で通知されるハンドオーバ情報は、決定されたＢ２＿１値を含むか、決定されたＢ２＿１値によって構成される。協調が集中化されている場合には、ステップ７０２で通知されるハンドオーバ情報は、決定されたＢ２＿１値に基づいて計算される３Ａ＿２を含むか、決定されたＢ２＿１値に基づいて計算される３Ａ＿２によって構成される。

ある実施形態では、通知されるハンドオーバ情報は、調節量（例えば、ｘｄＢで示されたハンドオーバ閾値の上昇または下降値）または絶対値（例えば、ｙｄＢで示された調節されて上昇した閾値または下降した閾値）を示してよい。

ステップ７０４では、第１のコントローラは、第２のコントローラへ、ＱｏＳパラメータの値またはＵＥ性能パラメータの値など、そのハンドオーバ情報と関連する１つまたは複数の区別基準の１つまたは複数の値を通知する。

ＱｏＳパラメータは、第１のＲＡＮセルまたは第２のＲＡＮセルによってサービスを供給されているユーザ機器（ＵＥ）に提供されるか提供されると予想されるサービスのレベルに影響するパラメータを含み得る。ある実施形態では、ＱｏＳパラメータは、ＵＥによって用いられている信号ベアラ（例えば、ＥＰＳベアラ）のＱＣＩと、信号ベアラのＡＲＰと、信号ベアラがＧＢＲベアラかどうかに関する指標と、信号ベアラがリアルタイムデータを搬送しているかどうかに関する指標との中の１つまたは複数を含む。ＵＥ性能パラメータは、ＵＥ性能を示し得る。ＵＥ性能パラメータは、例えば、ＵＥのカテゴリと、ＵＥのＲＲＭコンフィギュレーション（例えば、ＤＲＸコンフィギュレーション）と、ＵＥの加入タイプと、ＵＥの速度（例えば、高速または低速）の中の１つまたは複数を含み得る。

例えば、ｅＮＢは、ＮＢに、閾値３Ａ＿２と、ＱＣＩおよびＵＥカテゴリのようなＱｏＳパラメータおよびＵＥ性能パラメータと、これらのパラメータに対する値（インスタンスとも称される）の組とを通信し得る。ＱＣＩについての値の組は、例えば、２および４を含み得る。他方で、ＵＥカテゴリについての値の組は、例えば、カテゴリ１およびカテゴリ２を含み得る。これによると、調節された閾値３Ａ＿２が適用されるＱｏＳパラメータ値の下記の４（２ｘ２）通りの組合せ（すなわち、モード）が生じる。
モード１：ＱＣＩ＝２およびＵＥカテゴリ＝１
モード２：ＱＣＩ＝２およびＵＥカテゴリ＝２
モード３：ＱＣＩ＝４およびＵＥカテゴリ＝１
モード４：ＱＣＩ＝４およびＵＥカテゴリ＝２

この実施形態では、第２のＲＡＮセルにおけるあるＵＥがカテゴリ３というＵＥカテゴリ値を有する場合には、第２のコントローラは、調節された３Ａ＿２の値をそのＵＥに中継するのを控えてよい。第２のＲＡＮセルにおける別のＵＥが、カテゴリ２というＵＥカテゴリを有し、調節された３Ａ＿２の値を受け取ることがあり得る。しかし、その別のＵＥは、２または４というＱＣＩ値を有するベアラを現時点で用いている場合にだけ、その調節された閾値を用い得る。

ある実施形態では、２つの閾値パラメータが、区別基準の異なる組または区別基準の異なる値と関連する場合があり得る。例えば、３Ａ＿２の閾値がＱＣＩおよびＵＥカテゴリ値と関連し、Ｂ２＿１の閾値がＵＥカテゴリおよびＵＥ加入タイプ値と関連するということがあり得る。

ステップ７０６では、第１のコントローラが、第２のコントローラから、第２のコントローラが第１のハンドオーバパラメータ値に基づき第２のハンドオーバパラメータ値を調節したかどうかに関する指標を受け取る。なお、この場合に、第２のハンドオーバパラメータ値は、第２のＲＡＮセルから第１のＲＡＮセルへのハンドオーバを生じさせるべきかどうかを決定するときに用いられるためのものである。ある実施形態では、第２のハンドオーバパラメータ値は、満たされると、ＵＥに信号測定を第２のコントローラに報告させることになる条件を定義する。そして、第２のコントローラは、この報告を用いて、ハンドオーバを生じさせるかべきかどうかを決定する。ある実施形態では、第２のハンドオーバパラメータ値は、第２のＲＡＮセルから第１のＲＡＮセルへのハンドオーバをトリガする条件を定義する。ある例では、ｅＮＢが、Ｂ２＿１の値に基づく推奨された３Ａ＿２の値をＲＮＣに通知した場合には、この指標は、ＲＮＣが調節された３Ａ＿２の値を受け入れるか拒絶することを示してもよい。ｅＮＢがＢ２＿１の値をＲＮＣに通知する場合には、この指標は、ｉ）ＲＮＣが通知されたＢ２＿１の値に基づいてその３Ａ＿２の値を調節したこと、または、ｉｉ）ＲＮＣがその３Ａ＿２の値を調節していないことを、示し得る。

図８は、集中化されたハンドオーバの協調の例を図解している。より詳しくは、２つのＲＡＮセルの間のハンドオーバの協調を、第１のコントローラにおいて集中化してもよい。ステップ８０２は、協調が第１のコントローラに集中化されているシナリオの一部である。ステップ８０２では、第１のコントローラが、第１のハンドオーバパラメータ値（例えば、Ｂ２＿１）に基づいて、第２のハンドオーバパラメータ値（例えば、３Ａ＿２）への調節値を決定する。

ステップ８０４では、第１のコントローラが、第２のハンドオーバパラメータ値の調節値を、第２のコントローラに通知する。例えば、ｅＮＢは、３Ａ＿２への対応する調節値を計算した後で、その対応する調節値を、ＵＴＲＡＮセルのＲＮＣへの推奨として、調節量（例えば、２０ｄＢｍの増加）として、または調節された値（例えば、調節された３Ａ＿２の値はｙｄＢｍ）として、通知する。

ステップ８０５では、第１のコントローラが、ステップ８０４で通知される推奨された調節値とステップ７０４で通知されるパラメータ値とに応答して第２のコントローラによって通知されるメッセージを受信する。なお、このメッセージは、第２のコントローラが調節値を受け入れたかどうかを示す情報を含む。ステップ８０６では、第２のコントローラが第２のハンドオーバパラメータ値の調節値を受け入れたかどうかを、第１のコントローラが、このメッセージに含まれている情報に基づいて判定する。例えば、ｅ−ＵＴＲＡＮのコントローラが、３Ａ＿２閾値への対応する調節値を、ＵＴＲＡＮセルのコントローラに通知する場合には、ＵＴＲＡＮセルのコントローラは、調節値を承認することを選択することができるし、調節された３Ａ＿２閾値を拒絶することも選択し得る。ある実施形態では、ＵＴＲＡＮセルのコントローラは、第１のコントローラに送るメッセージにおいて、拒絶の理由を示す情報を提供してもよい。この理由には、例えば、ＵＴＲＡＮセルが、３Ａ＿２値と関連する特定のＱｏＳパラメータもしくはＵＥ性能パラメータ、またはＱｏＳパラメータもしくはＵＥ性能パラメータの特定の値をサポートしていないこと、３Ａ＿２値がサポートされる範囲の外に外れていること、または、いずれかの他の理由が含まれ得る。調節された３Ａ＿２値が、ＵＴＲＡＮセルのコントローラによってサポートされる閾値の範囲から外れる場合には、そのＵＴＲＡＮセルのコントローラは、メッセージの中に、閾値のサポートされる範囲を示す情報を含めてもよい。

ステップ８０８では、第２のコントローラが対応する調節値を受け入れないとの判断に応答して、第１のコントローラは、第１のハンドオーバパラメータのために、別の値（例えば、別のＢ２＿１値）を決定し得る。例えば、ｅＮＢが、当初に、Ｂ２＿１閾値への増加を決定し、３Ａ＿２値への対応する増加を決定し得るが、ＲＮＣは、３Ａ＿２値への対応する増加を拒絶し得る。それに応答して、ｅＮＢは、元のＢ２＿１閾値を増加させないこと、または、それを僅かな量だけ増加させることを選択し得る。ある実施形態では、第２のコントローラが、サポートされている閾値の範囲（例えば、複数の３Ａ＿２値を示す）とともに応答した場合には、第１のコントローラは、その範囲に基づき、再計算を実行し得る。

ステップ８１０では、第２のコントローラが対応する調節値を受け入れるという判断に応答して、第１のコントローラが、第１のＲＡＮセルから第２のＲＡＮセルへのハンドオーバイベントを示すための第１のハンドオーバパラメータ値（例えば、Ｂ２＿１値）の使用を開始するか、使用し続け得る。

ある実施形態では、ステップ７０２および７０４での通知は、ＲＡＮ情報管理（ＲＩＭ）メッセージの一部である。表２は、本明細書ではフォーマット１と称される、ハンドオーバ協調がｅ−ＵＴＲＡＮセルのあるｅＮＢに集中化されているシナリオにおいて用いられるＲＩＭ要求転送メッセージ（ＲＩＭ Ｒｅｑｕｅｓｔ Ｔｒａｎｓｆｅｒ ｍｅｓｓａｇｅ）の例示的なフォーマットを図解している。このフォーマットにより、ｅ−ＵＴＲＡＮが、３Ａ＿２閾値の推奨される対応する調節値をＵＴＲＡＮセルに通知することが可能になる。

上の表が図解しているように、第１のコントローラは、ある実施形態では、第１のＲＡＮセルのセルＩＤと第２のＲＡＮセルのセルＩＤとの少なくとも一方を、更に通知し得る。ある実施形態では、セルＩＤは、推奨される３Ａ＿２値が向けられるセルのグループを示し得る。

ある実施形態では、ステップ７０６において受信される指標は、ＲＩＭ応答メッセージの一部として受信され得る。あるｅＮＢにハンドオーバ協調が集中化されているシナリオでは、応答メッセージは、３Ａ＿２への推奨される対応する調節値が受け入れられたのか拒絶されたのかを示し得る。次の表３および表４は、ＲＩＭ応答メッセージを図解している。

図９は、第１のコントローラと第２のコントローラとの間で協調が分散されている例を図解している。ステップ９０２では、第１のコントローラは、第２のコントローラに、第１のハンドオーバパラメータ値（例えば、Ｂ２＿１）を通知する。換言すると、この実施形態では、通知されるハンドオーバ情報は、ステップ７０１で決定された調節値を含むか、ステップ７０１で決定された調節値から構成される。分散型の協調シナリオでは、第１のコントローラ（例えば、ｅＮＢ）は、他方の方向へのハンドオーバのために用いられる閾値（例えば、ＵＴＲＡＮからｅ−ＵＴＲＡＮへのハンドオーバのための３Ａ＿２値）への対応する調節値を計算する責任を有していない。代わりに、例えば、ｅＮＢは、Ｂ２＿１閾値の調節値をＵＴＲＡＮのＲＮＣに送信し、その３Ａ＿２値への対応する調節値の決定をＵＴＲＡＮに任せる。

ステップ９０５では、第１のコントローラが、ステップ９０４で通知される調節値とステップ７０４で通知されるパラメータ値とに応答して、第２のコントローラによって送信されたメッセージを受信する。なお、このメッセージは、第２のコントローラが、第１のハンドオーバパラメータ値に基づいて第２のハンドオーバパラメータ値へ調節を行ったかどうかを示す情報を含む。

ステップ９０６では、第１のコントローラが、このメッセージに含まれる情報に基づき、対応する調節を第２のコントローラが行ったかどうかを判断し得る。例えば、あるｅＮＢがＢ２＿１への増加を決定し、その増加をＲＮＣに通知した場合には、そのｅＮＢは、その応答として、ＲＮＣがその３Ａ＿２値への対応する増加を行ったかどうかを示すメッセージを受信し得る。

ステップ９０８では、ステップ８０８におけるように、第２のコントローラは第２のハンドオーバパラメータ値（例えば、３Ａ＿２）への対応する調節を行っていないという判断に応答して、第１のコントローラが、第１のハンドオーバパラメータのために別の値（例えば、別のＢ２＿１値）を決定し得る。

ステップ９１０では、ステップ８１０におけるように、第２のコントローラは第２のハンドオーバパラメータ値（例えば、３Ａ＿２）への対応する調節を行ったという判断に応答して、第１のコントローラが、第１のＲＡＮセルから第２のＲＡＮセルへのハンドオーバをトリガするための第２のハンドオーバパラメータ値（例えば、Ｂ２＿１）を使用し始めるか、その使用を継続し得る。

ある実施形態では、ステップ９０２および７０４における通知は、ＲＡＮ情報管理（ＲＩＭ）メッセージの一部である。表５Ａおよび表５Ｂは、ハンドオーバ協調がｅ−ＵＴＲＡＮセルのｅＮＢとＵＴＲＡＮセルのＲＮＣとに分散されているシナリオで用いられるＲＩＭ要求転送メッセージの例示的なフォーマットをそれぞれ図解しており、これらは、本明細書ではフォーマット５Ａおよび５Ｂと称される。フォーマット５Ａにより、ｅ−ＵＴＲＡＮセルがそのＢ２＿１値をＵＴＲＡＮセルに送信することが可能になり、フォーマット５Ｂにより、ＵＴＲＡＮセルがその３Ａ＿２値をｅ−ＵＴＲＡＮセルに送信することが可能になる。

図１０は、ある実施形態を図解している。この実施形態では、あるコントローラが別のコントローラに、どちらの区別基準（例えば、ＱｏＳパラメータおよび／もしくはＵＥ性能パラメータ）が、または、より詳しくは、区別基準のどの例（例えば、ＱｏＳパラメータおよび／もしくはＵＥ性能パラメータのどちらの値）がハンドオーバを判断するために他方のコントローラによってサポートされているのかを判断するように問い合わせ得る。より詳しくは、ステップ１００２では、第１のコントローラが、第２のコントローラに、第２のＲＡＮセルにおけるハンドオーバを判断するために用いられる１つもしくは複数のＱｏＳパラメータ値または１つもしくは複数のＵＥ性能パラメータ値を求める要求を、送信する。例としては、ｅ−ＵＴＲＡＮのｅＮＢは、ＵＴＲＡＮセルのＲＮＣから、どちらの区別基準（例えば、ＱＣＩ、ＵＥカテゴリ）がＲＮＣによってサポートされているのかを示し、これらのパラメータのどの値（例えば、２および４というＱＣＩ値、カテゴリ１およびカテゴリ２というＵＥカテゴリ値）がサポートされているのかを更に示す情報を要求し得る。

この情報は、ステップ１００４において受信され、この受信された情報により第１のコントローラがハンドオーバ協調を調整することが可能になり、結果的に、第１のコントローラは、（例えば、ＱｏＳパラメータおよび／またはＵＥ性能パラメータ値などの）区別基準値のサポートされる組に対応するハンドオーバパラメータ調節値だけを通知する。例えば、ステップ１００６では、第１のコントローラは、受信されたＱｏＳパラメータ値またはＵＥ性能パラメータ値に基づいて、第２のハンドオーバパラメータ値の調節値を決定し得る。例としては、あるコントローラが、あるＵＴＲＡＮセルから、２および４というＱＣＩ値がハンドオーバの判断に用いられるという指標を受信する場合には、このコントローラは、ＱＣＩ＝２である状況に対する３Ａ＿２値の調節値を決定し得る。

ステップ１００８では、第１のコントローラは、１つもしくは複数の受信されたＱｏＳパラメータ値またはＵＥ性能パラメータ値の中の１つを通知し得る。この１つまたは複数のパラメータ値は第２のコントローラから受信されたので、第１のコントローラは、従って、それらのパラメータ値は第２のＲＡＮセルによってサポートされるということを、知り得る。

図１１は、コントローラが、相互に、それらの区別基準を分散型協調シナリオの一部として告知するプロセスを図解している。ステップ１１０２では、第１のコントローラは、第２のコントローラに、ハンドオーバを判断するために第１のＲＡＮで用いられる１つもしくは複数のＱｏＳパラメータ値またはＵＥ性能パラメータ値を、通知する。例としては、ｅＮＢは、ＱｏＳパラメータおよびＵＥ性能パラメータの以下の値と関連し得る。すなわち、（ＱＣＩ＝２、ＵＥカテゴリ＝カテゴリ１）、（ＱＣＩ＝４、ＵＥカテゴリ＝カテゴリ１）、（ＱＣＩ＝２、ＵＥカテゴリ＝カテゴリ２）、（ＱＣＩ＝４、ＵＥカテゴリ＝カテゴリ２）である。この例では、ｅＮＢは、組合せを示す情報を、ＵＴＲＡＮセルのＲＮＣに送信し得る。

ステップ１１０４では、第１のコントローラは、第２のコントローラから、ハンドオーバを判断するために第２のＲＡＮセルで用いられる１つもしくは複数のＱｏＳパラメータ値またはＵＥ性能パラメータ値を受信する。ステップ１１０２および１１０４により、２つのＲＡＮセルは、他方のＲＡＮによって用いられる区別基準および／または区別基準値を知ることが可能になる。そのようにして知ることにより、ハンドオーバパラメータ値の調節値の計算を最適化することができる。

ステップ１１０６では、第１のコントローラは、ハンドオーバを判断するために第１のＲＡＮセルにおいて用いられる１つもしくは複数のＱｏＳパラメータ値またはＵＥ性能パラメータ値を変更し得る。

例えば、ハンドオーバを判断するために、ｅＮＢが当初（ＱＣＩ＝２、ＵＥカテゴリ＝カテゴリ１）、（ＱＣＩ＝４、ＵＥカテゴリ＝カテゴリ１）、（ＱＣＩ＝２、ＵＥカテゴリ＝カテゴリ２）、（ＱＣＩ＝４、ＵＥカテゴリ＝カテゴリ２）を用いる場合、ｅＮＢは、ＱＣＩパラメータに対するサポートを排除し、カテゴリ１というＵＥカテゴリ値に対するサポートを排除することにより、（ＵＥカテゴリ＝カテゴリ２）という組合せだけがハンドオーバの判断のために用いられるようになる。

ステップ１１０８では、第１のコントローラは、この変更を、第２のコントローラに通知し得る。

図１２Ａ〜図１２Ｂ、図１３Ａ〜図１３Ｂ、ならびに図１４は、ｅ−ＵＴＲＡＮセルのためのコントローラ（例えば、ｅＮＢ）およびＵＴＲＡＮセルのためのコントローラ（例えば、ＲＮＣ）との関連で、上述されたハンドオーバ協調を図解している。図１２Ａおよび図１２Ｂは、協調が区別基準値（例えば、ＱｏＳパラメータ値およびＵＥ性能パラメータ値）の送信を要しない実施形態を図解している。図１３Ａ〜図１３Ｂおよび図１４では、協調が区別基準値の送信を要し、それによってハンドオーバ情報が特定の状況に適合されることが可能になるような実施形態を図解している。よって、例えば、ハンドオーバ閾値を、異なるＱｏＳ要件のための異なる値に調節することが可能である。次に、信号測定を実行するＵＥが、そのアクティブなベアラのＱｏＳパラメータ値に基づいて、複数のハンドオーバ閾値から選択することができる。

図１２Ａでは、ｅＮＢが、Ｂ２＿１および３Ａ＿２のための新たな値など、新たなハンドオーバ閾値を計算することができる。ある実施形態では、計算を、ＩＲＡＴ ＭＲＯ機能から実行することができ、１つまたは複数のＲＬＦ障害統計から導くことができる。新たなハンドオーバ閾値３Ａ＿２が、ｅ−ＵＴＲＡＮセルからＵＴＲＡＮセルへ通知され得る。通知されたハンドオーバ閾値は、ＲＡＮ情報管理（ＲＩＭ）要求転送メッセージの中で通知され得る。図１２Ａの図解はｅＮＢに集中化されている協調に対応するので、ＲＩＭメッセージは、上で示した報告フォーマット１を有する。

新たな３Ａ＿２値を受け取ると、ＵＴＲＡＮセルは、この新たな３Ａ＿２値を（図１２Ａに示されているように）受け入れてもよいし、この新たな３Ａ＿２値を（図１２Ｂに示されているように）拒絶してもよい。ｅＮＢは、ＵＴＲＡＮセルが新たな３Ａ＿２値を受け入れると知らされる場合、ｅＮＢは次に、ｅ−ＵＴＲＡＮセルのためのＢ２＿１値を、（まだ変更されていないと仮定して）この新たな値に変更しうる。そうではなくて、ＵＴＲＡＮが新たな３Ａ＿２値を拒絶する場合には、ｅＮＢは、Ｂ２＿１という閾値を新たな値に変更せずに、その代わりに、別のＢ２＿１を計算し得る。別のＢ２＿１値の計算は、３Ａ＿２がその以前の値から変更することがまったく不可能であるか、または、特定の範囲の外には変更不可能である、という制約に基づくことがあり得る。ある実施形態では、この制約は、ＵＴＲＡＮからのＲＩＭ応答メッセージにおいて、新たな３Ａ＿２値が拒絶された理由として、提供され得る。例えば、ＵＴＲＡＮセルは、３Ａ＿２値が最大値もしくは最小値を超えている、または、３Ａ＿２値を変更することはまったく不可能であるということを示してもよい。新たな３Ａ＿２値がインクリメントまたはデクリメントとして通信された場合には、拒絶された理由は、インクリメントまたはデクリメントが最大量を超えていることを示してもよい。

ある実施形態では、ＵＴＲＡＮセルからのＲＩＭ応答メッセージを待機するとき、ｅ−ＵＴＲＡＮは、タイマを維持してもよい。タイマが終了し応答が受信されない場合には、ｅ−ＵＴＲＡＮは、ＲＩＭ転送要求メッセージを、一定の回数、再送信してもよい。ｅ−ＵＴＲＡＮは、依然として応答を受信しない場合には、ＵＴＲＡＮセルがＲＩＭ転送要求メッセージにおけるハンドオーバ閾値を拒絶したと想定してもよい。

図１２Ａ〜図１２Ｂのように、図１３Ａ〜図１３Ｂは、ｅＮＢが新たな３Ａ＿２値をターゲットＵＴＲＡＮセルに通知する集中化されたハンドオーバ協調を示す信号ダイアグラムを提供している。ターゲットＵＴＲＡＮセルは、新たな３Ａ＿２値の受け入れまたは新たな３Ａ＿２の拒絶をもって応答し得る。図１３Ａ〜図１３Ｂの実施形態は、新たな３Ａ＿２値と、対応する新たな３Ａ＿２値とを、１つまたは複数の特定のＱｏＳパラメータ（または、いずれかの他の区別基準）の中の１つまたは複数の特定の値（特定のインスタンスとも称される）に、更に適用する。よって、ｅＮＢは、新たな３Ａ＿２の値を用いて、１つまたは複数の特定の区別基準の１つまたは複数の特定の値を通知し得る。

ある実施形態では、新たな３Ａ＿２の値を受信すると、ＵＴＲＡＮセルが、その１つまたは複数の特定の区別基準が適用される状況に対して３Ａ＿２の値を受け入れると決めることがあり得るし（図１３Ａ）、３Ａ＿２の値を拒絶することもあり得る（図１３Ｂ）。ＵＴＲＡＮは、新たな３Ａ＿２の値を拒絶するときには、ＲＩＭ応答メッセージにおいて理由を提供することがあり得る。図１１Ｂにおけるように、この理由は、高すぎるまたは低すぎる３Ａ＿２の値を含み得る。図１３Ｂでは、この理由は、１つまたは複数の特定の区別基準の１つまたは複数の特定の値に対するサポートが欠けていることや、または、区別基準それ自体に対するサポートが欠けていることも、更に含んでよい。例えば、ＲＡＮセルがＡＲＰパラメータをサポートしない、または、ＡＲＰパラメータの特定の値をサポートしないということを、ＲＡＮセルが示してもよい。

ある実施形態では、ＲＩＭ応答メッセージを受け取ると、ｅＮＢは、３Ａ＿２は特定の範囲の外には変更不可能である、修正がまったく不可能である、および／または特定の区別基準の特定の値に対してだけ変更可能であるという制約に基づいて、新たなＢ２＿１を計算してもよい。

図１４は、ＵＴＲＡＮセルとｅ−ＵＴＲＡＮセルとがそれらの区別基準値を共有し得る分散型協調方式の特定の実施形態を図解している。よって、ｅ−ＵＴＲＡＮセルのｅＮＢは、ハンドオーバを判断するときには２および４というＱＣＩ値を用いることを示す報告を作成して、その報告をＵＴＲＡＮセルに送信し得る。この報告により、ＵＴＲＡＮセルは、ｅ−ＵＴＲＡＮセルによって用いられるＱＣＩ値によりよく対応するように、その３Ａ＿２値への調節を行うことが可能になり得る。同様に、ＵＴＲＡＮセルは、例えば、ハンドオーバを判断するときには２、３、４というＱＣＩ値とカテゴリ１および２というＵＥカテゴリ値とを用いることを示す報告を作成し得る。ＵＴＲＡＮからのこの報告は、ｅ−ＵＴＲＡＮが将来の時点で３Ａ＿２値をＵＴＲＡＮセルに推奨する集中型協調方式において用いられ得る。ｅ−ＵＴＲＡＮセルは、ＵＴＲＡＮセルによって用いられている区別基準値を知っているため、その区別基準によりよく対応する推奨を提供し得る。

上述された方法は、２つの無線アクセスネットワーク（ＲＡＮ）に限定されることはない。図１５は、基地局１０４によって提供されるＲＡＮと、ブースタデバイス１１８によって提供されるピコセルとを含む例示的なシステム１５００を図解している。ある実施形態では、ＲＡＮは、マクロレベルのカバー範囲を提供し、ピコセルは、ブースタリンクとして性能の強化を提供するだけである。両方の接続がアクティブであるときには、アンカリンク（ａｎｃｈｏｒ ｌｉｎｋ）を、制御シグナリングのために用いることが可能であり、ブースタリンクはデータのために用いられる。しかし、いくつかの例では、アンカリンクは、アンカリンクを経由してデータを送るために用いられることもあり得る。この場合には、システム情報が、マクロレベルのカバー対象範囲またはピコセルを経由して送られることがあり得る。

無線エリアネットワークの例示的なコントローラ

図１６は、いくつかの実施形態によるコントローラ１０４のブロック図を図解している。図１６に示されているように、コントローラ１０４は、１つもしくは複数のプロセッサ（例えば、マイクロプロセッサ）、および／もしくは、特定用途向け集積回路（ＡＳＩＣ）やフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの１つもしくは複数の回路を含み得るデータ処理システム１６０２、他の装置からのメッセージを受信し他の装置へメッセージを送信するためのトランシーバ１６０５、非一時的なデータ記憶装置（例えば、ハードドライブ、フラッシュメモリ、光ディスクおよびその他）などの１つもしくは複数のコンピュータ可読なデータ記憶媒体および／または、揮発性の記憶装置（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ））を含み得るデータ記憶システム１６０６を含み得る。データ処理システム１６０２がプロセッサ（例えば、マイクロプロセッサ）を含む実施形態では、コンピュータプログラム製品１６３３が提供され得る。このコンピュータプログラム製品は、コンピュータプログラムを実装し、データ記憶システム１６０６のコンピュータ可読媒体１６４２上に記憶されているコンピュータ可読なプログラムコード１６４３（例えば、命令）を含む。データ記憶システム１６０６の例としては、限定列挙ではないが、磁気媒体（例えば、ハードディスク）、光媒体（例えば、ＤＶＤ）、メモリデバイス（例えば、ランダムアクセスメモリ）などがある。いくつかの実施形態では、コンピュータ可読なプログラムコード１６４３は、データ処理システム１６０２によって実行されると、コード１６４３が、データ処理システム１６０２に本明細書において説明されているステップを実行させるように、コンフィギュレーションされている。いくつかの実施形態では、コントローラ１０４は、コード１６４３を必要とすることなく上述されたステップを実行するように、コンフィギュレーションされ得る。例えば、データ処理システム１６０２は、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）などの、特定のハードウェアだけで構成されることもあり得る。従って、上述された本発明の特徴は、ハードウェアおよび／またはソフトウェアにおいて実装されることがあり得る。

図１７は、いくつかの実施形態によるコントローラ１１２のブロック図を図解している。図１７に示されているように、コントローラ１１２は、１つもしくは複数のプロセッサ（例えば、マイクロプロセッサ）、および／もしくは、特定用途向け集積回路（ＡＳＩＣ）やフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの１つもしくは複数の回路を含み得るデータ処理システム１７０２、他の装置からのメッセージを受信し他の装置へメッセージを送信するための基地局インターフェース１７０５、非一時的なデータ記憶装置（例えば、ハードドライブ、フラッシュメモリ、光ディスクおよびその他）などの１つもしくは複数のコンピュータ可読なデータ記憶媒体および／または、揮発性の記憶装置（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ））を含み得るデータ記憶システム１７０６を含み得る。データ処理システム１７０２がプロセッサ（例えば、マイクロプロセッサ）を含む実施形態では、コンピュータプログラム製品１７３３が提供され得る。このコンピュータプログラム製品は、コンピュータプログラムを実装し、データ記憶システム１７０６のコンピュータ可読媒体１７４２上に記憶されているコンピュータ可読なプログラムコード１７４３（例えば、命令）を含む。データ記憶システム１７０６の例としては、限定列挙ではないが、磁気媒体（例えば、ハードディスク）、光媒体（例えば、ＤＶＤ）、メモリデバイス（例えば、ランダムアクセスメモリ）などがある。いくつかの実施形態では、コンピュータ可読なプログラムコード１７４３は、データ処理システム１７０２によって実行されると、コード１７４３が、データ処理システム１７０２に本明細書において説明されているステップを実行させるように、コンフィギュレーションされている。いくつかの実施形態では、コントローラ１１２は、コード１７４３を必要とすることなく上述されたステップを実行するように、コンフィギュレーションされ得る。例えば、データ処理システム１７０２は、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）などの、特定のハードウェアだけで構成されることもあり得る。従って、上述された本発明の特徴は、ハードウェアおよび／またはソフトウェアにおいて実装されることがあり得る。

例示的なＵＥ

図１８は、実例ＵＥ１０２のブロック図を図解している。図１８に示されているように、ＵＥ１０２は、１つもしくは複数のプロセッサ（Ｐ）１８５５（例えば、マイクロプロセッサ）、および／もしくは、特定用途向け集積回路（ＡＳＩＣ）やフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの１つまたは複数の回路を含み得るデータ処理システム（ＤＰＳ）１８０２、アンテナ１８２２に接続されており、様々なアクセスポイントからのメッセージを受信し、様々なアクセスポイントにメッセージを送信するためのトランシーバ１８０５、非一時的メモリユニット（例えば、ハードドライブ、フラッシュメモリ、光ディスクなど）のような１つもしくは複数のコンピュータ可読なデータ記憶媒体および／または、揮発性記憶装置（例えば、ダイナミックランダムアクセスメモリ（ＤＲＡＭ））を含み得るデータ記憶システム１８０６を含む。

データ処理システム１８０２がプロセッサ１８５５（例えば、マイクロプロセッサ）を含む実施形態では、コンピュータプログラム製品１８３３が提供され得るが、このコンピュータプログラム製品は、コンピュータ可読なプログラムコード１８４３（例えば、命令）を含む。そして、このコンピュータ可読なプログラムコード１８４３が、限定列挙ではないが、磁気媒体（例えば、ハードディスク）、光媒体（例えば、ＤＶＤ）、メモリデバイス（例えば、ランダムアクセスメモリ）など、データ記憶システム１８０６のコンピュータ可読媒体１８４２上に記憶されているコンピュータプログラムを実装する。いくつかの実施形態では、コンピュータ可読なプログラムコード１８４３は、データ処理システム１８０２によって実行されると、本明細書において説明されているステップを、データ処理システム１８０２に実行させるようコンフィギュレーションされている。

いくつかの実施形態では、ＵＥ１０２は、コード１８４３を必要とすることなく、上述されたステップを実行するようにコンフィギュレーションされる。例えば、データ処理システム１８０２は、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）など、特別なハードウェアだけで構成されることもあり得る。よって、上述された本発明の特徴は、ハードウェアおよび／またはソフトウェアにおいて、実装され得る。例えば、いくつかの実施形態では、上述されたＵＥ１０２の機能コンポーネントは、プログラムコード１８４３を実行するデータ処理システム１８０２によって、どのようなコンピュータプログラムコード１８４３とも独立に動作するデータ処理システム１８０２によって、またはハードウェアおよび／もしくはソフトウェアの任意の適切な組合せによって、実装され得る。

第２の実施形態では、ＵＥ１０２は、更に、１）データ処理システム１８０２に接続されており、データ処理システム１８０２が情報をＵＥ１３０のユーザに表示することを可能にするディスプレイスクリーン１８２３と、２）データ処理システム１８０２に接続されており、データ処理システム１８０２が音声をＵＥ１３０のユーザに出力することを可能にするスピーカ１８２４と、３）データ処理システム１８０２に接続されており、データ処理システム１８０２がユーザからの音声を受け取ることを可能にするマイクロホン１８２５と、を含む。

以上では本開示の様々な態様および実施形態が説明されてきたが、それらの態様および実施形態は、限定ではなく、単なる例示として提供されてきたということが理解されるべきである。よって、本開示の拡がりおよび範囲は、上述された例示的な実施形態のいずれによっても限定されるべきでない。更に、本開示において説明されている要素を可能性のあるすべての多様性において組み合わせたとしても、本明細書に含まれないとの記載がない限り、または、文脈と明らかに矛盾しない限り、いずれの組合せも本開示に含まれる。

更に、本発明のプロセスは、一連のステップとして本明細書で説明され図面において図解されているが、これは、単に例証の目的でそのようにしたのであった。従って、いくつかのステップが追加され得ること、いくつかのステップが削除され得ること、ステップの順序が並び換えられ得ること、およびいくつかのステップが並行的に実行され得ることが、考えられる。

Claims (28)

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. 前記１つまたは複数の処理ユニットは、更に、
    前記第１のコントローラ（１０５）において、ハンドオーバを決定するときに前記第１のコントローラ（１０５）がＱｏＳパラメータまたはＵＥ性能パラメータのどちらを用いるかを変更し（１１０６）、
    前記変更を前記第２のコントローラ（１１２）に通知する（１１０８）ように構成されている、請求項２６に記載のコントローラ（１０５）。

Images