(57)【要約】  本発明は、異機種ネットワークにおいて、セル・レンジ拡張（ＣＲＥ）についてのバイアス調整パラメータ（ＢＡＰ）をユーザ機器（ＵＥ）に提供する為の方法、装置、及びシステムを提供する。現在のｅＮＢは、ハンドオーバ（ＨＯ）されるべき１以上のＵＥの属性情報に基づき、ターゲットｅＮＢに対応する１つ以上のＵＥのＣＲＥについてのＢＡＰを決定し、１つ以上のＵＥにＢＡＰを送信し、１つ以上のＵＥは、ＢＡＰに基づき、現在のｅＮＢ及びターゲットｅＮＢについての測定レポートのレポート・トリガ条件を調整し、レポート・トリガ条件が満たされるとき、現在のｅＮＢに対し現在のｅＮＢ及びターゲットｅＮＢについての測定レポートを報告し、現在のｅＮＢは、測定レポートに基づき、対応するＵＥについてのＨＯ決定を行う。本発明は、ＣＲＥ負荷バランシングの為のより柔軟なＨＯ設定を実現し、ネットワーク効率及びユーザＱｏＳを強化する。
2016521032.tif 000002
【特許請求の範囲】
【請求項１】
異機種ネットワークにおいて、バイアス調整パラメータをユーザ機器に提供するためのｅＮＢであって、
ハンドオーバされるべき１つまたは複数のユーザ機器の属性情報に基づいて、それらのターゲットｅＮＢに対応する前記１つまたは複数のユーザ機器のセル・レンジ拡張についてのバイアス調整パラメータを決定するように構成された、バイアス調整決定モジュールと、
前記対応するユーザ機器が、前記現在のｅＮＢ及び前記ターゲットｅＮＢについての測定レポートのレポート・トリガ条件を調整するように、前記１つまたは複数のユーザ機器に対して、前記バイアス調整パラメータを送信するように構成された、第１の調整送信モジュールと、
前記１つまたは複数のユーザ機器から前記測定レポートを受信し、また前記１つまたは複数のユーザ機器についてのハンドオーバ決定を行うように構成された、ハンドオーバ決定モジュールと、
を備える、ｅＮＢ。
【請求項２】
前記第１の調整送信モジュールは、さらに、
−  前記対応するユーザ機器が前記ターゲットｅＮＢのセル・レンジ拡張についての前記現在のｅＮＢの共通のバイアス・パラメータを考慮して前記レポート・トリガ条件を調整するように、前記１つまたは複数のユーザ機器に対して前記バイアス調整パラメータを送信する
ように構成されている、請求項１に記載のｅＮＢ。
【請求項３】
前記ｅＮＢは、
前記ターゲットｅＮＢが、前記セル・レンジ拡張に対応するそのハンドオーバ・パラメータを調整するように、前記ターゲットｅＮＢに対して前記バイアス調整パラメータを送信するように構成された、第２の調整送信モジュール
をさらに備える、請求項１または２に記載のｅＮＢ。
【請求項４】
前記バイアス調整決定モジュールは、
−  対応する１つまたは複数のユーザ機器グループを取得するように、ハンドオーバされるべき前記１つまたは複数のユーザ機器をグループ分けし、
−  前記１つまたは複数のユーザ機器グループの属性情報に基づいて、前記１つまたは複数のユーザ機器グループのうちのそれらのターゲットｅＮＢに対応するセル・レンジ拡張についてのバイアス調整パラメータを決定する
ように構成されている、請求項１乃至３のいずれか１項に記載のｅＮＢ。
【請求項５】
前記属性情報は、
−  サポートされるＬＴＥリリース・バージョンと、
−  モビリティ速度状態と、
のうちの少なくとも１つの項目を含む、請求項１乃至４のいずれか１項に記載のｅＮＢ。
【請求項６】
異機種ネットワークにおいて、現在のｅＮＢからセル・レンジ拡張についてのバイアス調整パラメータを取得するためのユーザ機器であって、
前記現在のｅＮＢから、ターゲットｅＮＢに対応するセル・レンジ拡張についての前記バイアス調整パラメータを受信するように構成された第１の調整受信モジュールと、
前記バイアス調整パラメータに基づいて、前記現在のｅＮＢ及び前記ターゲットｅＮＢについての測定レポートのレポート・トリガ条件を調整するように構成されたバイアス調整モジュールと、
前記現在のｅＮＢがハンドオーバ決定を行えるようにするために、前記レポート・トリガ条件が満たされるときに、前記現在のｅＮＢに対して前記測定レポートを報告するように構成された測定レポート報告モジュールと、
を備える、ユーザ機器。
【請求項７】
前記バイアス調整モジュールは、さらに、
−  前記ターゲットｅＮＢのセル・レンジ拡張についての前記現在のｅＮＢの共通のバイアス・パラメータを考慮して、前記バイアス調整パラメータに基づいて、前記レポート・トリガ条件を調整する
ように構成されている、請求項６に記載のユーザ機器。
【請求項８】
前記ユーザ機器は、
前記ユーザ機器の属性情報に基づいて、前記バイアス調整パラメータのうちから対応する好ましいバイアス調整パラメータを選択するように構成されたバイアス選択モジュール
をさらに備え、
前記バイアス調整モジュールは、
−  前記好ましいバイアス調整パラメータに基づいて、前記測定レポートの前記レポート・トリガ条件を調整する
ように構成されている、請求項６または７に記載のユーザ機器。
【請求項９】
現在のｅＮＢが異機種ネットワークにおいてバイアス調整パラメータをユーザ機器に提供することを容易にするためのターゲットｅＮＢであって、
前記現在のｅＮＢから、前記ユーザ機器のために決定されるセル・レンジ拡張についての前記バイアス調整パラメータを受信するように構成された第２の調整受信モジュールと、
前記バイアス調整パラメータに基づいて、前記現在のｅＮＢに対応する前記セル・レンジ拡張についてのハンドオーバ・パラメータを調整するように構成されたハンドオーバ・パラメータ調整モジュールと、
を備える、ターゲットｅＮＢ。
【請求項１０】
異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをユーザ機器に提供するためのシステムであって、請求項１、２、４、５のいずれか１項に記載のｅＮＢと、請求項６乃至８のいずれか１項に記載のユーザ機器と、
を備える、システム。
【請求項１１】
異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをユーザ機器に提供するためのシステムであって、請求項１、３、４、５のいずれか１項に記載のｅＮＢと、請求項６、８のいずれか１項に記載のユーザ機器と、請求項９に記載のターゲットｅＮＢと、
を備える、システム。
【請求項１２】
異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをユーザ機器に提供するための方法であって、
Ａ．ハンドオーバされるべき１つまたは複数のユーザ機器の属性情報に基づいて、それらのターゲットｅＮＢに対応する前記１つまたは複数のユーザ機器のセル・レンジ拡張についてのバイアス調整パラメータを、現在のｅＮＢが決定するステップと、
Ｂ．前記１つまたは複数のユーザ機器に対して、前記バイアス調整パラメータを、前記現在のｅＮＢが送信するステップと、
Ｃ．前記バイアス調整パラメータに基づいて、前記現在のｅＮＢ及び前記ターゲットｅＮＢについての測定レポートのそのレポート・トリガ条件を、前記１つまたは複数のユーザ機器が調整するステップと、
Ｄ．前記レポート・トリガ条件が満たされるときに、前記現在のｅＮＢに対して、前記現在のｅＮＢ及び前記ターゲットｅＮＢについての前記測定レポートを、前記１つまたは複数のユーザ機器が報告するステップと、
Ｅ．前記測定レポートに基づいて、対応するユーザ機器についてのハンドオーバ決定を、前記現在のｅＮＢが行うステップと、
を含む、方法。
【請求項１３】
前記ステップＣは、
−  前記ターゲットｅＮＢのセル・レンジ拡張についての前記現在のｅＮＢの共通のバイアス・パラメータを考慮して、前記バイアス調整パラメータに基づいて、前記レポート・トリガ条件を、前記１つまたは複数のユーザ機器が調整するステップ
を含む、請求項１２に記載の方法。
【請求項１４】
−  前記ターゲットｅＮＢに対して、前記バイアス調整パラメータを、前記現在のｅＮＢが送信するステップと、
−  前記バイアス調整パラメータに基づいて、前記現在のｅＮＢに対応するセル・レンジ拡張についてのハンドオーバ・パラメータを調整するステップと、
をさらに含む、請求項１２または１３に記載の方法。
【請求項１５】
前記属性情報は、
−  サポートされるＬＴＥリリース・バージョンと、
−  モビリティ速度状態と、
のうちの少なくとも１つの項目を含む、請求項１２乃至１４のいずれか１項に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワイヤレス通信技術の分野に関し、より詳細には、異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをユーザ機器（ＵＥ：ｕｓｅｒ  ｅｑｕｉｐｍｅｎｔ）に提供する技法に関する。
【背景技術】
【０００２】
ＬＴＥ  ＨｅｔＮｅｔ（異機種ネットワーク）においては、従来のマクロ・セルの他に、ピコ・セルと、フェムト・セルと、中継セルとを含めて、異なる種類の低電力セルが存在している。マクロｅＮＢの送信電力レベルと、スモールｅＮＢの送信電力レベルの間の大きな差異に起因して、スモールｅＮＢのダウンリンク・レンジは、マクロｅＮＢのダウンリンク・レンジよりも遙かに小さい。セル選択が、主としてダウンリンク信号強度に基づいている場合、スモールｅＮＢの有用性は、非常に減少するであろう。
【０００３】
高電力ｅＮＢのより大きなレンジは、これらのユーザ機器を効率的にサービスできるほど十分なマクロｅＮＢリソースを有することなしに信号強度に基づいてほとんどのユーザ機器をマクロｅＮＢに引き付けることにより、セル分割の利点を制限するが、一方で、低電力ｅＮＢは、どのようなユーザ機器にもサービスしないことがある。すべての低電力ｅＮＢが、使用可能なスペクトルを使用して、少なくとも１つのユーザ機器にサービスすることができるとしても、異なるｅＮＢの負荷の間の差によって、ネットワークにおけるユーザ機器の間でデータ・レートの分配が不公平になり、ユーザ経験が不均一になる可能性がある。
【０００４】
それゆえに、ネットワーク容量の観点から、スモールｅＮＢのカバレッジを拡張することにより、マクロｅＮＢと、スモールｅＮＢとの間の負荷をバランスさせ、またその後にセル分割利得を増大させることが、望ましい。図１に示されるように、そこでは、ピコ・セルのレンジが、拡張され、この概念は、ＨｅｔＮｅｔにおける負荷バランシングのための効果的なやり方であるＣＲＥ（セル・レンジ拡張（ｃｅｌｌ  ｒａｎｇｅ  ｅｘｐａｎｓｉｏｎ））と称される。
【０００５】
ＣＲＥは、それぞれアイドル状態のＵＥ及び接続されたＵＥのためのセル再選択パラメータとハンドオーバ・パラメータとを調整することにより、実現されることもある。アイドル状態のＵＥでは、マクロ・セルにおいて、セル再選択パラメータＱオフセット（Ｑｏｆｆｓｅｔ）を調整することにより、それは、隣接するスモール・セルを再選択することができ、スモール・セルにおけるＱヒステリシス（Ｑｈｙｓｔ）を調整することにより、それは、スモール・セルの中に滞留し続ける。それに応じて、接続されたＵＥでは、隣接するスモール・セルのＣＩＯ（セル個別オフセット（Ｃｅｌｌ  Ｉｎｄｉｖｉｄｕａｌ  Ｏｆｆｓｅｔ））を増大させることにより、それは、マクロ・セルからスモール・セルへと早期にハンドオーバすることができ、隣接するマクロ・セルのＣＩＯを低減させることにより、それは、後でスモール・セルから、ハンドオーバすることができる。１つの隣接するセルのＣＩＯを調整することが、関与していない他のセルへのハンドオーバ・メトリクスに影響を与えることがないことに、注意すべきである。
【０００６】
明白であるが、接続されたモードにおいては、セル境界を仮想的にシフトさせるＣＲＥは、セル対の概念であり、またそのようにしてセル対に基づいて調整されるべきである。ひとたびマクロ・ユーザが、スモール・セル領域拡張のためにハンドオーバされた後に、ＣＩＯなどのハンドオーバ・パラメータを修正することが必要である可能性があり、その結果、ユーザは、信号の理由に起因して、マクロ・セルにハンドオーバされて戻されることはないであろう。修正は、両方のセルにおいて実行される必要があり、その結果、２つのセルの間のＣＩＯは、整合したままである。言い換えれば、負荷バランシングの場合には、ＣＩＯなどのハンドオーバ・パラメータの変更は、通常、対称的であり、すなわち、マクロ・セルが、その隣接するスモール・セルのＣＩＯを、例えば、２ｄＢだけ増大させる場合、それは、マクロ・セルのセル境界が、−２ｄＢだけ移動させられることを意味しており、その一方で、スモール・セルは、その隣接するマクロ・セルのＣＩＯを２ｄＢだけ低減させて、それ自体のセル境界を＋２ｄＢだけ拡張させるべきである。ここで、２ｄＢは、スモール・セルに向かうＣＲＥバイアスとして知られている。
【０００７】
しかしながら、ＬＴＥに関連した仕様における現在の定義、例えば、２０１２年６月に公開されたリリース１１における定義、すなわち、ＴＳ  ３６．３３１  ｖ１１．０．０、「Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ（ＲＲＣ）；Ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎ（Ｒｅｌｅａｓｅ  １１）」によれば、ＣＩＯなどのハンドオーバ・パラメータが、すべてのユーザ機器のために適用される。
【０００８】
ハンドオーバ・パラメータ設定
接続されたモードにおいては、ＣＲＥバイアスは、新しいターゲット・セルに対するハンドオーバに関連して、ＵＥのために適用される。これは、測定イベントＡ３によって実行される。隣接するセルのＲＳＲＰ（基準信号受信電力（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｉｎｇ  Ｐｏｗｅｒ））またはＲＳＲＱ（基準信号受信品質（Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｉｎｇ  Ｑｕａｌｉｔｙ））が、ＴＴＴ（トリガ時間（Ｔｉｍｅ−ｔｏ−Ｔｒｉｇｇｅｒ））の少なくとも持続時間にわたって、現在のサービング・セルよりもよい所与のＨＯＭ（ハンドオーバ・マージン（Ｈａｎｄｏｖｅｒ  Ｍａｒｇｉｎ））であるときに、それをサービング・セルからターゲット・セルへとハンドオーバするハンドオーバ決定が、ＵＥに対して行われる。
【０００９】
例示のＡ３トリガ条件は、
Ｍｎ＋Ｏｆｎ＋Ｏｃｎ−Ｈｙｓ＞Ｍｐ＋Ｏｆｐ＋Ｏｃｐ＋Ｏｆｆ    （１）
として定義されることができ、式中で、Ｍｐと、Ｍｎとは、サービング・セルと、ターゲット・セルとのＲＳＲＰレベルまたはＲＳＲＱレベルである。Ｏｆｐと、Ｏｆｎとは、サービング・セルと、ターゲット・セルとの周波数特有のオフセットである。Ｏｃｐと、Ｏｃｎとは、サービング・セルと、ターゲット・セルとのセル特有のオフセット、すなわち、ＣＩＯである。Ｈｙｓは、すべての測定イベントについて共通のヒステリシス・パラメータであり、Ｏｆｆは、隣接するセルに関係のないイベントＡ３についてのオフセット・パラメータである。
【００１０】
条件（１）は、以下のように、すなわち、
Ｍｎ＞Ｍｐ＋ＨＯＭ（ｐ，ｎ）    （２）
のように簡略化されることができ、式中で、ＨＯＭ（ｎ，ｐ）＝Ｏｆｐ＋Ｏｃｐ＋Ｏｆｆ−Ｏｆｎ−Ｏｃｎ＋Ｈｙｓは、通常、ハンドオーバ・マージン（ＨＯＭ）と呼ばれる。ＨＯＭ（ｐ，ｎ）が、正の値であることは、ハンドオーバが、後で起こるように提案されることを示している。明白であるが、ＨＯＭは、セル境界を仮想的にシフトさせるセル対特有のオフセットである。また上記で述べられるように、ＨＯＭは、セル対に基づいて調整されるべきである。
【００１１】
これらのハンドオーバ・パラメータは、セル特有、またはイベント特有のいずれかであるが、技術的には、ｅＮＢは、専用のＲＲＣシグナリングを介して、ＵＥ特有の値を異なるＵＥにシグナリングすることができる。また、次いで、ハンドオーバは、マクロ・セルからピコ・セルへと、またピコ・セルからマクロ・セルへとを含めて、同じポイントで実行されるべきであり、すなわち、隣接するセルは、個別の値を知っているべきである。現在では、これは、Ｘ２インターフェースを介して可能ではなく、このＸ２インターフェースは、一般的に、セル全体、またはネットワークさえも全体を通して、同じハンドオーバ・パラメータをＵＥに対して適用する。
【００１２】
モビリティ設定変更
上記で述べられるように、ひとたびマクロ・セル・ユーザが、スモール・セルのレンジ拡張のためにハンドオーバされると、ＣＩＯなどのハンドオーバ・パラメータを修正することが必要である場合があり、その結果、ユーザは、信号の理由に起因してマクロ・セルに対してハンドオーバして戻されることはないであろう。修正は、両方のセルにおいて実行される必要があり、その結果、２つのセルの間のハンドオーバ設定は整合した（ｃｏｈｅｒｅｎｔ）ままである。この目的のために、モビリティ設定変更のＸ２プロシージャは、ＬＴＥに関連した仕様、例えば、ＴＳ  ３６．４２３  ｖ１１．０．０、「Ｘ２  ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ（Ｘ２ＡＰ）（Ｒｅｌｅａｓｅ  １１）」２０１２年３月に公開の中で規定される。変更を検出するｅノードＢ（ｅＮｏｄｅＢ）は、ユーザの迅速な戻りを回避するために、どれだけ多くのセル境界がシフトされる必要があることになるかを推定する必要がある。セル境界のシフトは、図２に示されるように、ｄＢで表され、またモビリティ変更要求Ｘ２ＡＰメッセージ（ＭＯＢＩＬＩＴＹ  ＣＨＡＮＧＥ  ＲＥＱＵＥＳＴ  Ｘ２ＡＰ  ｍｅｓｓａｇｅ）の形で、対応する他のセルに対して通知される。負荷バランシングの場合には、変更は、通常対称的であり、すなわち、マクロ・セルが、例えば、−２ｄＢだけそのハンドオーバ境界をシフトさせる場合、スモール・セルは、それ自体を＋２ｄＢだけ拡張させるべきである。
【００１３】
しかしながら、ただ１つの信号ＨＯＭが、モビリティ設定変更プロシージャを介して変更される可能性がある。それは、モビリティ変更要求メッセージ（ＭＯＢＩＬＩＴＹ  ＣＨＡＮＧＥ  ＲＥＱＵＥＳＴ  ｍｅｓｓａｇｅ）の内部にモビリティ・パラメータ情報ＩＥ（情報要素（Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｌｅｍｅｎｔ））を含めることにより実施されることもある。
【００１４】
図２を参照すると、モビリティ変更要求メッセージは、ｅＮＢ１からｅＮＢ２へと送信されて、モビリティ・パラメータの適応を開始する。以下の表１は、例示のモビリティ変更要求メッセージを示すものである。
【００１５】
【表１】
2016521032.tif 000003
【００１６】
モビリティ・パラメータ情報ＩＥは、その現在の値に関してのハンドオーバ・トリガの変更を含んでいる。ハンドオーバ・トリガは、あるセルが、特定の隣接セルへのハンドオーバ準備プロシージャを開始するしきい値に対応する。この変更が正の値であることは、ハンドオーバが、後で起こるように提案されることを示している。以下の表２は、例示のモビリティ・パラメータ情報ＩＥを示すものである。
【００１７】
【表２】
2016521032.tif 000004
【００１８】
上記説明に基づいて、固定された開始ポイントの仮定の下では、モビリティ設定変更プロシージャを経由した情報交換は、各セル対セルの関係についてＨＯＭの共通の組についてのみ機能する可能性がある。これはＵＥ特有のＨＯＭ交換、またはＵＥグループ特有のＨＯＭ交換をサポートすることができず、すなわち、それは、ＵＥ能力に対応するＣＲＥバイアス値を設定することができず、それによって、より柔軟なＣＲＥ負荷バランシングを実現することができない。
【００１９】
ＣＩＯなどのハンドオーバ・パラメータについてのＬＴＥの定義は、ＵＥのレシーバ能力を考慮してはいない。明らかに異なるＵＥは、特に制御チャネルの上のＣＲＥ領域において、厳しい干渉を取り扱う異なる能力を有することができる（ＡＢＳ（ほぼブランクのサブフレーム）が、ｅＩＣＩＣ（強化されたセル間干渉調整）のために使用されるときでさえ、ＣＲＳなどのシステム信号が、依然として送信される）。例えば、リリース８／９／１０をサポートするＵＥは、せいぜい６ｄＢのバイアスを受け入れることができるが、干渉キャンセル・レシーバを有する、リリース１１をサポートするＵＥは、９ｄＢなどのより大きなバイアスの下で機能することができ、またリリース１２をサポートするＵＥは、いくつかのネットワーク支援シグナリングと一緒に、進化したレシーバを用いて、より大きなＣＲＥバイアスの下で機能することが期待される。加えて、Ｒｅｌ−８／９のＵＥは、ＲＲＭ（無線リソース管理（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｍａｎａｇｅｍｅｎｔ））と、ＣＳＩ（チャネル状態情報（Ｃｈａｎｎｅｌ  Ｓｔａｔｅ  Ｉｎｆｏｒｍａｔｉｏｎ））とについての２つの制限された測定サブセットを使用することができず、その結果ＡＢＳ保護を用いてさえ、ＣＲＥ領域の中でよく機能しない可能性がある。別の例においては、ＤＬ信号強度の他に、ＣＲＥは、ＤＬ経路損失やネットワーク・ユーティリティなど、他のメトリクスに基づいて、実施される可能性もある。ＤＬ経路損失またはネットワーク・ユーティリティに基づいたＣＲＥを実施するために、ＣＩＯなどのハンドオーバ・パラメータは、ＤＬ信号強度を関連するＵＥに対してマッピングするためにＵＥに基づいて強化される必要がある。
【００２０】
接続されたノードにおける高速ＵＥでは、バイアスを使用して、ハンドオーバ・レートを低減させることができ、それによってハンドオーバの失敗を低減させる。この場合に、バイアス（負）を使用して、ＵＥが、スモール・セルに対してハンドオーバされないようにしている。それは、さらに、ＵＥ速度特有のバイアスを必要とする。
【００２１】
それゆえに、セル特有のハンドオーバ・パラメータは、ＣＲＥ負荷バランシングのために十分に柔軟ではないがＵＥ特有のＣＲＥまたはＵＥグループ特有のＣＲＥに対しては有利であり、すなわち、ＵＥの能力または速度の差別化を伴ってＣＲＥを実行して、ネットワーク効率と、ユーザＱｏＳとを改善する。
【００２２】
さらに、先行技術はまた、自己組織化ネットワークのためのサービス・クラスに依存した負荷バランシングを提案しており、このサービス・クラスに依存した負荷バランシングは、はっきりと異なるサービス・クラスをサポートし、またそれに応じて隣接するセルの間の、各々のはっきりと異なるサービス・クラスのための個別のハンドオーバ・パラメータ設定の協調を強化するように、単一のハンドオーバ・パラメータ設定を拡張する必要がある。明白であるが、上記のサービス・クラスに基づいた負荷バランシングは、ＣＲＥのシナリオを含んではいない。さらに、ＵＥに適用されたＣＲＥバイアスは、そのサービス・クラスに依存することはないが、レシーバ能力やモビリティ速度などのその属性情報に依存している。
【先行技術文献】
【非特許文献】
【００２３】
【非特許文献１】２０１２年６月に公開されたリリース１１における定義、すなわち、ＴＳ  ３６．３３１  ｖ１１．０．０、「Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ（ＲＲＣ）；Ｐｒｏｔｏｃｏｌ  ｓｐｅｃｉｆｉｃａｔｉｏｎ（Ｒｅｌｅａｓｅ  １１）」
【非特許文献２】ＴＳ  ３６．４２３  ｖ１１．０．０、「Ｘ２  ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ（Ｘ２ＡＰ）（Ｒｅｌｅａｓｅ  １１）」２０１２年３月に公開
【非特許文献３】リリース８／９／１０
【非特許文献４】リリース１２
【非特許文献５】ＴＳ  ３６．４２３のセクション９．２．４８および９．２．４９
【発明の概要】
【発明が解決しようとする課題】
【００２４】
本発明は、異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをＵＥに提供するための方法と、装置と、システムとを提供することを目指している。
【課題を解決するための手段】
【００２５】
本発明の一態様によれば、異機種ネットワークにおいて、バイアス調整パラメータをユーザ機器に提供するためのｅＮＢが提供され、そこでは、ｅＮＢは、
ハンドオーバされるべき１つまたは複数のユーザ機器の属性情報に基づいて、それらのターゲットｅＮＢに対応する１つまたは複数のユーザ機器のセル・レンジ拡張についてのバイアス調整パラメータを決定するように構成されたバイアス調整決定モジュールと、
対応するユーザ機器が、現在のｅＮＢと、ターゲットｅＮＢとについての測定レポートのレポート・トリガ条件を調整するように、１つまたは複数のユーザ機器に対して、バイアス調整パラメータを送信するように構成された第１の調整送信モジュールと、
１つまたは複数のユーザ機器から測定レポートを受信し、また１つまたは複数のユーザ機器についてのハンドオーバ決定を行うように構成されたハンドオーバ決定モジュールと、
を備える。
【００２６】
本発明の一態様によれば、異機種ネットワークにおいて、現在のｅＮＢからセル・レンジ拡張についてのバイアス調整パラメータを取得するためのユーザ機器が提供され、そこでは、ユーザ機器は、
現在のｅＮＢから、ターゲットｅＮＢに対応するセル・レンジ拡張についてのバイアス調整パラメータを受信するように構成された第１の調整受信モジュールと、
バイアス調整パラメータに基づいて、現在のｅＮＢと、ターゲットｅＮＢとについての測定レポートのレポート・トリガ条件を調整するように構成されたバイアス調整モジュールと、
現在のｅＮＢがハンドオーバ決定を行えるようにするために、レポート・トリガ条件が満たされるときに、現在のｅＮＢに対して、測定レポートを報告するように構成された測定レポート報告モジュールと
を備える。
【００２７】
本発明の一態様によれば、現在のｅＮＢが異機種ネットワークにおいてバイアス調整パラメータをユーザ機器に提供することを容易にするためのターゲットｅＮＢが提供され、そこでは、ターゲットｅＮＢは、
現在のｅＮＢから、ユーザ機器のために決定されるセル・レンジ拡張についてのバイアス調整パラメータを受信するように構成された第２の調整受信モジュールと、
バイアス調整パラメータに基づいて、現在のｅＮＢに対応するセル・レンジ拡張についてのハンドオーバ・パラメータを調整するように構成されたハンドオーバ・パラメータ調整モジュールと、
を備える。
【００２８】
本発明の一態様によれば、異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをユーザ機器に提供するためのシステムが提供され、そこでは、本システムは、異機種ネットワークにおいて、バイアス調整パラメータをユーザ機器に提供するための前記ｅＮＢと、異機種ネットワークにおいて、現在のｅＮＢからセル・レンジ拡張についてのバイアス調整パラメータを取得するための前記ユーザ機器とを備える。
【００２９】
本発明の一態様によれば、異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをユーザ機器に提供するためのシステムが提供され、そこでは、本システムは、異機種ネットワークにおいて、バイアス調整パラメータをユーザ機器に提供するための前記ｅＮＢと、異機種ネットワークにおいて、現在のｅＮＢからセル・レンジ拡張についてのバイアス調整パラメータを取得するための前記ユーザ機器と、現在のｅＮＢが、異機種ネットワークにおいて、バイアス調整パラメータをユーザ機器に提供することを容易にするための前記ターゲットｅＮＢと、を備える。
【００３０】
本発明の一態様によれば、異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをユーザ機器に提供するための方法が提供され、そこでは、本方法は、
Ａ．ハンドオーバされるべき１つまたは複数のユーザ機器の属性情報に基づいて、それらのターゲットｅＮＢに対応する１つまたは複数のユーザ機器のセル・レンジ拡張についてのバイアス調整パラメータを、現在のｅＮＢが決定するステップと、
Ｂ．１つまたは複数のユーザ機器に対して、バイアス調整パラメータを、現在のｅＮＢが送信するステップと、
Ｃ．バイアス調整パラメータに基づいて、現在のｅＮＢと、ターゲットｅＮＢとについての測定レポートのそのレポート・トリガ条件を、１つまたは複数のユーザ機器が調整するステップと、
Ｄ．レポート・トリガ条件が満たされるときに、現在のｅＮＢに対して、現在のｅＮＢと、ターゲットｅＮＢとについての測定レポートを、１つまたは複数のユーザ機器が報告するステップと、
Ｅ．測定レポートに基づいて、対応するユーザ機器についてのハンドオーバ決定を、現在のｅＮＢが行うステップと
を含む。
【００３１】
先行技術に比べて、本発明は、ＵＥの属性情報に基づいて、セル・レンジ拡張についてのＵＥ特有のバイアス調整パラメータまたはＵＥグループ特有のバイアス調整パラメータを提供しており、これは、ＣＲＥ負荷バランシングについてのより柔軟なハンドオーバ設定を実現し、またネットワーク効率と、ユーザＱｏＳとを強化する。
【００３２】
添付図面を参照して非限定的な実施形態についての以下の詳細な図を読むことを通して、本発明の他の特徴と、目的と、利点とは、より明確になるであろう。
【図面の簡単な説明】
【００３３】
【図１】セル・レンジ拡張の概念についての図である。
【図２】先行技術における隣接するｅＮＢの間のモビリティ設定変更プロシージャのメッセージ・フロー・チャートを示す図である。
【図３】本発明の一実施形態による、異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをＵＥに提供するための方法のフロー・チャートを示す図である。
【図４】本発明の修正された一例による、隣接するマクロ・セルと、ピコ・セルとの間の強化されたモビリティ設定変更プロシージャのメッセージ・フロー・チャートを示す図である。
【図５】本発明によるアプリケーション実施形態の概略図である。
【図６】本発明による別のアプリケーション実施形態の概略図である。
【図７】本発明の別の実施形態による、異機種ネットワークにおいて、セル・レンジ拡張についてのバイアス調整パラメータをＵＥに提供するための装置の図である。
【発明を実施するための形態】
【００３４】
添付図面の中の同じ参照数字、または同様な参照数字は、同じコンポーネント、または対応するコンポーネントを示している。
【００３５】
以下では、本発明は、さらに、添付図面を参照して、詳細に説明されるであろう。
【００３６】
例証の便宜のために、本発明は、大部分は一例を提示しており、また以下のシナリオにおいて例証を行っており、すなわち、異機種ネットワークにおいて、ピコ・セルは、マクロ・セルのカバレッジの内部に位置しており、ユーザ機器は、現在ではマクロ・セルに接続されており、ピコ・セルのセル・レンジ拡張を通して、ユーザ機器は、ピコ・セルに対してハンドオーバされることになっており、すなわち、マクロ・セルは、ユーザ機器の現在のセルであり、またピコ・セルは、ユーザ機器のターゲット・セルである。さらに、上記で説明されるように、セル・レンジ拡張は、セル対に基づいている。このシナリオにおいては、マクロ・セルと、ピコ・セルとは、セル対を形成し、このセル対は、互いに協力して、ピコ・セルについてのセル・レンジ拡張を実現する。
【００３７】
当業者なら、上記シナリオは、本発明を例証するための例示的なものにすぎず、このことは、本発明に対するどのような限定とも理解されるべきではないことを理解すべきである。例えば、ピコ・セルからマクロ・セルへとユーザ機器を手渡す、他の既存のシナリオ、または将来のシナリオは、それが、本発明に適用される可能性がある限り、本発明の保護範囲内に含まれるべきである。
【００３８】
本発明の一実施形態によれば、図３に示されるように、ステップＳ１において、現在のマクロｅＮＢ１０は、ハンドオーバされるべき１つまたは複数のＵＥ３０の属性情報に基づいて、それらのピコｅＮＢ２０に対応する１つまたは複数のＵＥ３０のセル・レンジ拡張についてのバイアス調整パラメータを決定する。
【００３９】
ここで、ＵＥの属性情報は、ＵＥによってサポートされるＬＴＥリリース・バージョンやＵＥのモビリティ速度状態など、ＵＥのバイアス調整パラメータを決定するための本発明に適用可能な任意の属性を含んでいる。バイアス調整パラメータは、現在のセルと、ターゲット・セルとの測定イベントに影響を与え、またそれに応じて個別のＣＩＯやＣＲＥバイアスの調整のスケーリング・ファクタなど、対応する測定レポートのレポート・トリガ条件を調整するための本発明に適用可能な任意のパラメータを含んでいる。
【００４０】
ステップＳ２において、現在のマクロｅＮＢ１０は、対応するＵＥ３０が、現在のマクロｅＮＢ１０と、ターゲット・ピコｅＮＢ２０とについての測定レポートのそのレポート・トリガ条件を調整するように、ステップＳ１において決定されるＵＥ特有のバイアス調整パラメータをこれらのＵＥ３０に対して送信する。
【００４１】
ここで、マクロｅＮＢ１０は、対応するＵＥ３０に対してＵＥ特有のバイアス調整パラメータを送信することができ、好ましい一実施形態においては、マクロ基地局１０は、各々のハンドオーバされるべきＵＥ３０についての対応するバイアス調整パラメータを決定することができ、また対応するＵＥ３０に対して、バイアス調整パラメータを送信し、別の好ましい実施形態においては、マクロｅＮＢ１０は、ハンドオーバされるべきＵＥ３０をグループ分けし、またそのグループ分けから得られる１つまたは複数のＵＥグループの属性情報に基づいて、それぞれのバイアス調整パラメータを決定し、また次いで対応するＵＥ３０に対して、その決定されたバイアス調整パラメータを送信することができる。
【００４２】
代わりに、マクロｅＮＢ１０は、すべてのＵＥ３０に対して、決定されたバイアス調整パラメータを送信することができ、各ＵＥ３０は、それ自体、どのバイアス調整パラメータがその属性情報に基づいて採用されるかを決定し、すなわち、マクロｅＮＢ１０から送信されるバイアス調整パラメータのうちの適切なバイアス調整パラメータを選択している。例えば、マクロｅＮＢ１０は、ＵＥのモビリティ速度状態に基づいて、それぞれ、高速度ＵＥ及び低速度ＵＥのための対応するバイアス調整パラメータを決定し、またすべてのＵＥに対して、２つのバイアス調整パラメータを送信し、次いで、各ＵＥは、そのモビリティ速度状態に基づいて、対応するバイアス調整パラメータを選択する。
【００４３】
それに応じて、ＵＥ３０は、現在のマクロｅＮＢ１０から、ターゲット・ピコｅＮＢ２０に対応するセル・レンジ拡張についてのそのバイアス調整パラメータを受信する。
【００４４】
ステップＳ３において、ＵＥ３０は、バイアス調整パラメータに基づいて、現在のマクロｅＮＢ１０及びターゲット・ピコｅＮＢ２０についての測定レポートのレポート・トリガ条件を調整する。
【００４５】
好ましい一実施形態においては、ＵＥ３０は、ターゲット・ピコｅＮＢ１０のセル・レンジ拡張についての現在のマクロｅＮＢ１０の共通のＣＲＥバイアス・パラメータを考慮して、バイアス調整パラメータに基づいて、現在のマクロｅＮＢ１０と、ターゲット・ピコｅＮＢ２０とについての測定レポートのレポート・トリガ条件を調整する。例えば、ＵＥ３０は、バイアス調整パラメータ及びマクロｅＮＢ１０によって送信される共通のＣＲＥバイアス・パラメータに基づいて、マクロｅＮＢ１０とターゲット・ピコｅＮＢ２０とについての測定レポートを報告することが必要であるかどうかを評価する。
【００４６】
例えば、ＬＴＥにおいては、ＵＥが高モビリティ状態または中間モビリティ状態にある場合に、ＵＥは、速度に依存したスケーリング・ファクタを適用して、アイドル・モードにおけるセル再選択パラメータと接続されたモードにおけるトリガ時間値とを調整するべきであり、それによってＵＥ特有のＣＲＥバイアスを実現している。
【００４７】
マクロｅＮＢは、ＣＩＯなどのＨＯＭパラメータについて、ある種の速度に依存したスケーリング・ファクタを信号で伝えることができる。モビリティ状態検出がサポートされているので、ＵＥは、ＨＯＭパラメータに応じて、スケーリング・ファクタに従って、それに応じてそのイベントＡ３条件を修正し、また判断することができ、すなわち、ＵＥは、それに応じて現在のマクロｅＮＢと、ターゲット・ピコｅＮＢとについての測定レポートのレポート・トリガ条件を調整することができる。
【００４８】
モビリティ速度状態の他に、スケーリング・ファクタは、ＵＥによってサポートされるＬＴＥリリース・バージョンなど、他の情報に関連している可能性があり、またこの情報は、現在のｅＮＢにおいて知られている。異なるＬＴＥリリース・バージョンの下で実現されるＵＥが、異なるレシーバ能力および／またはシグナリング・サポート、前者はＣＲＳ  ＩＣなど、後者は制限されたＲＲＭ／ＣＳＩ測定などを有するので、最大の受け入れ可能なＣＲＥバイアス値は異なっている。そのときには、現在のｅＮＢは、ＵＥに対してＨＯＭパラメータについてのバージョンに依存したスケーリング・ファクタを示すことができる。
【００４９】
さらに、異なるベンダーによって生成されるＵＥが、同じＬＴＥリリース・バージョンの下でさえ異なるレシーバ能力を有することができるなど、より詳細なＵＥ能力に関連した情報が、現在のｅＮＢによって取得される可能性がある場合に、現在のｅＮＢは、個別のＵＥに対して、共通のＨＯＭパラメータについてのＵＥ特有のスケーリング・ファクタを信号で伝えることができる。
【００５０】
スケーリング・ファクタなどのバイアス調整パラメータが、ＲＲＣシグナリングを介して送信され、またすべてのＵＥのために適用可能なＣＲＥバイアスなど、先行技術における共通のＨＯＭパラメータに影響を及ぼさないＵＥ側で実行され、またその結果、現在のモビリティ設定変更プロシージャを強化する必要がないことに、注意すべきである。
【００５１】
別の好ましい実施形態においては、マクロｅＮＢ１０は、ＵＥ３０に対して、バイアス調整パラメータを送信する必要があるだけでなく、ターゲット・ピコｅＮＢ２０に対して、対応するＵＥ３０のバイアス調整パラメータを送信する必要もあり、またターゲット・ピコｅＮＢ２０は、それに応じてセル・レンジ拡張に対応するそのハンドオーバ・パラメータを調整する。
【００５２】
例えば、マクロｅＮＢ１０は、専用のＲＲＣシグナリングを介してハンドオーバされるべきＵＥまたはＵＥグループに対して、個別のＣＩＯなど、ＵＥまたはＵＥグループに特有のバイアス調整パラメータを直接に信号で伝えることができる。また上記で述べられているように、ハンドオーバは、同じポイントで実行されるべきであるので、隣接するターゲット・ピコｅＮＢ２０は、ＵＥまたはＵＥグループに特有の個別のＣＩＯ値について知るべきである。そのときには、モビリティ設定変更についての現在のＸ２プロシージャは、拡張される必要がある。また、一般的な負荷バランシングに対してＣＲＥを差別化するために、明示的な原因が、モビリティ変更要求メッセージの中に含まれる可能性がある。
【００５３】
図４を参照すると、その図は、モビリティ設定変更プロシージャの強化についての一例を示している。図２に関連して図４に示される強化の例においては、現在のマクロｅＮＢなどのｅＮＢ１は、ターゲット・ピコ・セル２０などのｅＮＢ２に対して、ＵＥまたはＵＥグループに特有のＨＯＭパラメータを搬送するアクションの原因を含む強化されたモビリティ変更要求メッセージを送信し、それに応じて、ｅＮＢ２は、ｅＮＢ１に対して、モビリティ変更肯定応答／失敗メッセージ（ＭＯＢＩＬＩＴＹ  ＣＨＡＮＧＥ  ＡＣＫＮＯＷＬＥＤＧＥ／ＦＡＩＬＵＲＥ  ｍｅｓｓａｇｅ）を戻し、そこでは、モビリティ変更失敗メッセージ（ＭＯＢＩＬＩＴＹ  ＣＨＡＮＧＥ  ＦＡＩＬＵＲＥ  ｍｅｓｓａｇｅ）は、各ＨＯＭについての許可されたバイアス調整レンジを搬送する。
【００５４】
モビリティ設定変更プロシージャにおける２つの強化されたＸ２信号が、以下のように例証されている。
【００５５】
第１の例においては、ＴＳ  ３６．４２３のセクション９．２．４８と、９．２．４９とにおいてそれぞれ規定されるように、モビリティ・パラメータ情報ＩＥと、モビリティ・パラメータ修正レンジＩＥとの使用を拡張することである。ここでは、モビリティ・パラメータ情報ＩＥは、その現在の値と比べて、ハンドオーバ・トリガの変更を含んでいる。ハンドオーバ・トリガは、あるセルが、特定の隣接するセルへのハンドオーバ準備プロシージャを開始するしきい値に対応する。変更の正の値は、ハンドオーバが後で起こるように提案されることを意味している。以下の表３は、例示の拡張されたモビリティ・パラメータ情報ＩＥを示しており、ここで、ＵＥ特有の変更が含まれる場合、ハンドオーバ・トリガ変更は、その特定のＵＥまたはＵＥグループについて有効ではない。
【００５６】
【表３】
2016521032.tif 000005
【００５７】
モビリティ変更失敗メッセージが送信されるときに、モビリティ・パラメータ修正レンジＩＥにはｅＮＢ２によって許可されるハンドオーバ・トリガ変更値のレンジが含まれている。以下の表４は、例示の拡張されたモビリティ・パラメータ修正レンジＩＥを示しており、ここではＵＥ特有の下限または上限が含められる場合、ハンドオーバ・トリガ変更の下限または上限は、その特有のＵＥまたはＵＥグループについて有効ではない。
【００５８】
【表４】
2016521032.tif 000006
【００５９】
第２の例においては、特有のＵＥまたはＵＥグループに関する新しいＵＥ特有のモビリティ・パラメータ情報ＩＥと、新しいＵＥ特有のモビリティ・パラメータ修正レンジＩＥとが規定される。ＵＥ特有のモビリティ・パラメータ情報ＩＥは、その現在の値と比べて、ハンドオーバ・トリガの変更を含んでいる。ハンドオーバ・トリガは、あるセルが、特定の隣接セルへのハンドオーバ準備プロシージャを開始するしきい値に対応する。変更の正の値は、ハンドオーバが、後で起こるように提案されることを意味している。以下の表５は、例示の新しいＵＥ特有のモビリティ・パラメータ情報ＩＥを示しており、ここで、ハンドオーバ・トリガ変更は、その特定のＵＥまたはＵＥグループについてのみ有効である。
【００６０】
【表５】
2016521032.tif 000007
【００６１】
モビリティ変更失敗メッセージが送信されるときに、ＵＥ特有のモビリティ・パラメータ修正レンジＩＥには、ｅＮＢ２によって許可されるハンドオーバ・トリガ変更値のレンジが含まれている。以下の表６は、例示の新しいＵＥ特有のモビリティ・パラメータ修正レンジＩＥを示しており、ここでは、ハンドオーバ・トリガ変更の下限および上限は、特定のＵＥまたはＵＥグループについて有効であるだけである。
【００６２】
【表６】
2016521032.tif 000008
【００６３】
明白であるが、Ｘ２サポートがここで必要とされるので、別の好ましい実施形態は、制限された過負荷を導入するだけのＵＥグループ特有のＣＲＥのために、より適している。ＵＥは、ＵＥモビリティ速度状態、サポートされるＬＴＥリリース・バージョン、または他の能力に基づいて、グループ分けされる可能性がある。
【００６４】
ステップｓ４において、レポート・トリガ条件が満たされるときに、ＵＥ３０は、現在のマクロｅＮＢ１０がハンドオーバ決定を行えるようにするために、現在のマクロｅＮＢ１０に対して、現在のマクロｅＮＢ１０及びターゲット・ピコｅＮＢ２０についての測定レポートを報告する。それに応じて、現在のマクロｅＮＢ１０は、ＵＥ３０からその報告された測定レポートを受信し、またステップＳ５において、ＵＥ３０についてのハンドオーバ決定を行う。
【００６５】
図５を参照すると、本発明の１つのアプリケーション実施形態によれば、そこでは、ピコ・セル２０は、マクロ・セル１０のカバレッジの内部に位置しており、またそれらの間には、Ｔｘ電力に大きな差が存在しており、例えば、その差は、２０ｄＢまでのこともある。マクロ・セル１０の中には、１０個のＵＥが存在しているが、それらのうちのただ１つのＵＥだけが、最大ＲＳＲＰセル関連付けに基づいて、ピコ・セル２０に接続される。すべてのＵＥは、すべてのＵＥが、例えば、ラウンド・ロビン・スケジューリングまたは比例公平スケジューリングの下で、リソース割付けにおいて等しく取り扱われるべきであるように、同じトラフィック要件、例えば、フル・バッファと、同じサービス・クラスとを有する。しかしながら、ピコ・セル２０の中の１つのＵＥだけが、１００％のリソースの占有に起因してより高いデータ・レートを有しているが、マクロ・セル１０の中の９個のＵＥは、平均して、リソースのうちの１／９を使用することができるだけであり、これは、ネットワークにおいて、不公平なユーザ経験をもたらす。それゆえに、ピコ・セル２０のセル・レンジ拡張は、ＵＥが、マクロ・セル１０からピコ・セル２０へとハンドオーバされるようにする可能性がある。
【００６６】
共通のＣＲＥバイアスの下で、ピコ・セル２０には、ハンドオーバされる、新しいＬＴＥバージョンをサポートするＵＥと一緒に、古いＬＴＥバージョンをサポートするいくつかのＵＥが、常に存在している。例えば、マクロ・セル１０は、共通のＣＲＥバイアスが６ｄＢであり、すなわち、ピコ・セル２０のＣＩＯが６ｄＢだけ増大させられ、また３つのＵＥが、それらのイベントＡ３メトリックを再評価した後にピコ・セル２０に再接続されることになることを設定する。３つのマクロＵＥでは、相対的なＲＳＲＰの差は、それぞれ、２ｄＢと、４ｄＢと、５ｄＢとであり、またサポートされるＬＴＥリリース・バージョンは、それぞれ、８と、１０と、８であり、またそれらは、それぞれ、Ｒ−８  ＵＥ３１と、Ｒ−１０  ＵＥ３２と、Ｒ−８  ＵＥ３３としてマーク付けされる。明らかに、５ｄＢのＲＳＲＰの差を有するＲｅｌ−８  ＵＥ３３は、ピコ・セル２０に対してハンドオーバされた後に、せいぜい−５ｄＢのＳＩＮＲ（信号対干渉プラス雑音比（Ｓｉｇｎａｌ  ｔｏ  Ｉｎｔｅｒｆｅｒｅｎｃｅ  ｐｌｕｓ  Ｎｏｉｓｅ  Ｒａｔｉｏ））を有することになる。Ｒｅｌ−８  ＵＥと、Ｒｅｌ−１０  ＵＥとでは、最大の許容可能バイアス値（これらは、ｍａｘ＿ｂｉａｓ＿Ｒ８と、ｍａｘ＿ｂｉａｓ＿Ｒ１０としてマーク付けされることもある）は、制御チャネル性能を考慮して、それぞれ、例えば、３ｄＢと、６ｄＢとになる可能性がある。そのときには、Ｒ−８  ＵＥ３３は、−６ｄＢのバイアスの下では十分機能することができず、Ｒ−８  ＵＥ３３がハンドオーバされるべきでなく、また依然としてマクロ・セル１０によってサービスされるべきである。これは、それらのＬＴＥリリース・バージョンに応じて対応するＵＥを別々に取り扱うことにより、すなわち、異なるＵＥについて異なるバイアス値を設定することにより、達成される可能性がある。
【００６７】
一例においては、マクロ・セル１０は、スケーリング・ファクタをＵＥに対して送信することにより、共通のＣＲＥバイアスを調整する。ここで、当業者なら、スケーリング・ファクタがその文字通りの意味から狭く理解されるべきではなく、スケーリング・ファクタは、それだけには限定されないが、共通のＣＲＥバイアスを比例的に調整すること、共通のＣＲＥバイアスを増大させること、または共通のＣＲＥバイアスを低減させることなどを含めて、より広い観点から理解されるべきであることを理解すべきである。
【００６８】
例えば、ピコ・セル２０に対応する共通のＣＩＯを６ｄＢだけ増大させることの他に、マクロ・セル１０はまた、ＳＦ＿ＣＩＯ＿Ｒ８＝共通のＣＲＥバイアス−ｍａｘ＿ｂｉａｓ＿Ｒ８＝６ｄＢ−３ｄＢ＝３ｄＢとなるように、ＳＦ＿ＣＩＯ＿Ｒ８としてマーク付けされ得るＬＴＥリリース・バージョン８をサポートするＵＥのために、ＣＩＯの１つのスケーリング・ファクタを信号で伝える。それに応じて、各Ｒ−８  ＵＥは、Ｒ−８  ＵＥの公称ＣＲＥバイアスが６ｄＢであるが、その実際に使用されたＣＲＥバイアスが３ｄＢであるように、スケーリング・ファクタＳＦ＿ＣＩＯ＿Ｒ８だけ、その受信された共通のＣＲＥバイアスを低減させることにより、ＬＴＥリリース・バージョンに依存したＵＥ特有のＣＩＯを取得することになる。
【００６９】
このやり方は、２ｄＢのＲＳＲＰの差を有するＲｅｌ−８  ＵＥ３１の動作に影響を及ぼさないことになり、すなわち、Ｒｅｌ−８  ＵＥについての動作バイアスが３ｄＢであるので、ｍａｘ＿ｂｉａｓ＿Ｒ８よりも低いＲＳＲＰの差を有するＲｅｌ−８  ＵＥは、依然として、ピコ・セル２０に対してハンドオーバされることになることに注意すべきである。
【００７０】
ピコ・セル２０は、ピンポン（ｐｉｎｇ−ｐｏｎｇ）を回避するために、６ｄＢだけマクロ・セル１０に向かってその共通のＣＩＯをそれに応じて低減させるべきであり、すなわち、再び、イベントＡ３をトリガすることなく、ハンドオーバされたマクロＵＥをピコ・セル２０の中に留まらせることに注意すべきである。この調整は、モビリティ設定変更プロシージャによって実現されている。
【００７１】
別の例においては、マクロ・セル１０は、ハンドオーバ・パラメータを調整するために、ＵＥ及びピコ・セル２０に対して、個別のＣＩＯを直接に送信する。例えば、マクロ・セル１０は、ＬＴＥリリース・バージョン８と１０とをサポートするＵＥに対して、ピコ・セル２０に対応する２つの個別のＣＩＯを信号で伝え、これらは、それぞれＣＩＯ＿Ｐｉｃｏ＿Ｒ８及びＣＩＯ＿Ｐｉｃｏ＿Ｒ１０としてマーク付けされ、またそれぞれ３ｄＢと６ｄＢとである。それらのＵＥは、受信された個別のＣＩＯに従って、個別のイベントＡ３メトリックを評価し評価する。しかしながら、ＣＲＥの目的のために、２つの隣接するｅＮＢ、例えば、マクロ・セル１０とピコ・セル２０とは、ハンドオーバ・パラメータ設定を調整し、またピンポン効果を回避するために、調整されたやり方で、隣接セルの間で通信され、ネゴシエートされ、またオペレーションへと設定される。それゆえに、ＵＥまたはＵＥグループに特有のハンドオーバ設定パラメータは、交換される必要があり、これは、現在のモビリティ設定変更プロシージャを変更することを必要とする。
【００７２】
図６を参照すると、本発明の１つのアプリケーション実施形態によれば、高速度マクロ・セルＵＥ３０は、ピコ・セル２０に向かって移動し、ＵＥ３０はまた、隣接するピコ・セル２０の共通のＣＩＯ、例えば、６ｄＢを受信する。現在の測定設定の下で、ＵＥがＵＥの速度に応じてトリガ時間の値を調整すべきであるので、このＵＥ３０は、同じ無線状態を有する静的ＵＥよりも早期にピコ・セル２０に対してハンドオーバされることになる。また、速度に依存したスケーリング・ファクタが１．０以下であるので、高速度ＵＥのトリガ時間は、静的ＵＥよりも短い。
【００７３】
しかしながら、スモール・セルのセル半径は、低い送信電力に起因して、通常小さく、例えば５０ｍ以下である。中間速度、または高速度、例えば、６０ｋｍ／ｈを有するＵＥでは、ＵＥが５０ｍのセルの直径を有するスモール・セルを通過したときの滞留時間は２．５秒未満である。それゆえに、この場合には、マクロ・セルの中にＵＥを滞留させることはより簡単になる。
【００７４】
これは、高速度ＵＥのトリガ時間を増大させること、または高速度ＵＥについてピコのＣＩＯを低下させることのいずれかにより、実現される可能性がある。明白であるが、このトリガ時間が、すべてのイベントについて、またすべての測定された隣接するセルについて使用され、また特に高速度ＵＥのためにより短いトリガ時間を設定することは、マクロ・セルの間のハンドオーバのために適切であるので、トリガ時間を増大させることは、適用されない。
【００７５】
それゆえに、高速度ＵＥに対して、ピコ・セルに対応するより少ないＣＩＯを信号で伝えることは、適切なやり方であり、これは、マクロ・ツー・マクロ測定など、他の測定シナリオに対してあまり影響を及ぼさないであろう。
【００７６】
一例においては、マクロ・セル１０は、例えば、−１０ｄＢの値を有するＳＦ＿Ｈｉｇｈ＿ＣＩＯとしてマーク付けされる、隣接するピコ・セルのＣＩＯに対応する速度に依存したスケーリング・ファクタを、高速度ＵＥ３０に対して信号で伝える。そのときには、高速度ＵＥにおけるピコ・セル２０の使用されたＣＩＯ＝共通のＣＲＥバイアス＋ＳＦ＿Ｈｉｇｈ＿ＣＩＯ＝６ｄＢ−１０ｄＢ＝−４ｄＢである。負のピコ・セルのＣＩＯは、ピコに対してハンドオーバされる高速度ＵＥをずっと後にするであろう。
【００７７】
別の例においては、マクロ・セル１０は、特定のＵＥに対して、隣接するピコ・セル２０の異なるＣＩＯを信号で伝え、例えば、静的ＵＥに対して６ｄＢのＣＩＯを、また高速度ＵＥに対して−４ｄＢのＣＩＯ（例えば、ＣＩＯ＿Ｐｉｃｏ＿Ｈｉｇｈとしてマーク付けされる）を信号で伝える。代わりに、マクロ・セル１０は、各ＵＥがそれ自体のモビリティ推定に基づいてどのＣＩＯを使用すべきかを決定するように、各ＵＥに対して、２つのＣＩＯを信号で伝えることもできる。そのときには、ピコ・セル２０のＲＳＲＰが、マクロ・セル１０のＲＳＲＰよりも４ｄＢ大きくない限り、静的ＵＥは、期待されるようにＣＲＥ（セル・レンジ拡張）されることになり、また高速度ＵＥは、マクロ１０の中に保持されることになる。ここで、高速度ＵＥがピコ・セルにハンドオーバされる必要がないので、ピコ・セルは、ピンポン効果を回避するために、高速度特有のＣＩＯを知る必要はない。
【００７８】
本発明の別の実施形態によれば、図７に示されるように、現在のｅＮＢ１０は、バイアス調整決定モジュール１０１と、第１の調整送信モジュール１０２と、ハンドオーバ決定モジュール１０３とを含み、ＵＥ３０は、第１の調整受信モジュール３０１と、バイアス調整モジュール３０２と、測定レポート報告モジュール３０３とを含む。
【００７９】
具体的には、バイアス調整決定モジュール１０１は、ハンドオーバされるべき１つまたは複数のＵＥ３０の属性情報に基づいて、それらのターゲットｅＮＢに対応する１つまたは複数のＵＥ３０のセル・レンジ拡張についてのバイアス調整パラメータを決定する。
【００８０】
ここで、ＵＥの属性情報は、ＵＥによってサポートされるＬＴＥリリース・バージョンやＵＥのモビリティ速度状態など、ＵＥのバイアス調整パラメータを決定するための本発明に適用可能な任意の属性を含んでいる。バイアス調整パラメータは、現在のセル及びターゲット・セルの測定イベントに影響を与え、またそれに応じて個別のＣＩＯやＣＲＥバイアスの調整のスケーリング・ファクタなど、対応する測定レポートのレポート・トリガ条件を調整するための本発明に適用可能な任意のパラメータを含んでいる。
【００８１】
そのときには、現在のマクロｅＮＢ１０の第１の調整送信モジュール１０２は、対応するＵＥ３０が、現在のマクロｅＮＢ１０及びターゲット・ピコｅＮＢ２０についての測定レポートのレポート・トリガ条件を調整するように、これらのＵＥ３０に対して、バイアス調整決定モジュール１０１によって決定されるバイアス調整パラメータを送信する。
【００８２】
ここで、第１の調整送信モジュール１０２は、対応するＵＥ３０に対して、ＵＥ特有のバイアス調整パラメータを送信することができ、好ましい一実施形態においては、バイアス調整決定モジュール１０１は、各々のハンドオーバされるべきＵＥ３０についての対応するバイアス調整パラメータを決定することができ、また第１の調整送信モジュール１０２は、対応するＵＥ３０に対して、バイアス調整パラメータを送信することができ、別の好ましい実施形態においては、バイアス調整決定モジュール１０１は、ハンドオーバされるべきＵＥ３０をグループ分けし、またそのグループ分けから取得される１つまたは複数のＵＥグループの属性情報に基づいて、それぞれのバイアス調整パラメータを決定することができ、また次いで、第１の調整送信モジュール１０２は、対応するＵＥ３０に対して、その決定されたバイアス調整パラメータを送信することができる。
【００８３】
代わりに、第１の調整送信モジュール１０２は、すべてのＵＥ３０に対して、決定されたバイアス調整パラメータを送信することもでき、各ＵＥ３０は、それ自体、どのバイアス調整パラメータが、その属性情報に基づいて、採用されるかを決定し、すなわち、第１の調整送信モジュール１０２から送信されるバイアス調整パラメータのうちから適切なバイアス調整パラメータを選択している。例えば、バイアス調整決定モジュール１０１は、ＵＥのモビリティ速度状態に基づいて、それぞれ、高速度ＵＥ及び低速度ＵＥについての対応するバイアス調整パラメータを決定し、また第１の調整送信モジュール１０２は、すべてのＵＥに対して、２つのバイアス調整パラメータを送信し、次いで、各ＵＥは、そのモビリティ速度状態に基づいて、対応するバイアス調整パラメータを選択する。
【００８４】
それに応じて、ＵＥ３０の第１の調整受信モジュール３０１は、現在のマクロｅＮＢ１０から、ターゲット・ピコｅＮＢ２０に対応するセル・レンジ拡張についてのそのバイアス調整パラメータを受信する。
【００８５】
ＵＥ３０のバイアス調整モジュール３０２は、バイアス調整パラメータに基づいて、現在のマクロｅＮＢ１０と、ターゲット・ピコｅＮＢ２０とについての測定レポートのレポート・トリガ条件を調整する。
【００８６】
好ましい一実施形態においては、バイアス調整モジュール３０２は、ターゲット・ピコｅＮＢ１０のセル・レンジ拡張についての現在のマクロｅＮＢ１０の共通のＣＲＥバイアス・パラメータを考慮して、バイアス調整パラメータに基づいて、現在のマクロｅＮＢ１０及びターゲット・ピコｅＮＢ２０についての測定レポートのレポート・トリガ条件を調整する。例えば、バイアス調整モジュール３０２は、バイアス調整パラメータと、マクロｅＮＢ１０によって送信される共通のＣＲＥバイアス・パラメータとに基づいて、マクロｅＮＢ１０及びターゲット・ピコｅＮＢ２０についての測定レポートを報告することが必要であるかどうかを評価する。
【００８７】
別の好ましい実施形態においては、マクロｅＮＢ１０は、ターゲット・ピコｅＮＢ２０に対して、対応するＵＥ３０のバイアス調整パラメータを送信する第２の調整送信モジュール（図示されず）をさらに含む。それに応じて、ターゲット・ピコｅＮＢは、第２の調整受信モジュール（図示されず）と、ハンドオーバ・パラメータ調整モジュール（図示されず）とをさらに含み、本明細書においては、第２の調整受信モジュールは、マクロｅＮＢ１０から送信されるバイアス調整パラメータを受信し、またハンドオーバ・パラメータ調整モジュールは、それに応じてターゲット・ピコｅＮＢ２０のセル・レンジ拡張についてのハンドオーバ・パラメータを調整する。
【００８８】
ＵＥ３０の測定レポート報告モジュール３０３は、現在のマクロｅＮＢ１０がハンドオーバ決定を行えるようにするために、レポート・トリガ条件が満たされるときに、現在のマクロｅＮＢ１０に対して、現在のマクロｅＮＢ１０及びターゲット・ピコｅＮＢ２０についての測定レポートを報告する。それに応じて、現在のマクロｅＮＢ１０のハンドオーバ決定モジュール１０３は、ＵＥ３０についてのハンドオーバ決定を行うために、ＵＥ３０から、報告された測定レポートを受信する。
【００８９】
本発明は、ソフトウェア、またはソフトウェアとハードウェアとの組合せの形で実装されることもあり、例えば、本発明は、ＡＳＩＣ（特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ））、汎用コンピュータ、または他の類似した任意のハードウェア・デバイスによって実装されることもあることに注意すべきである。
【００９０】
本発明のソフトウェア・プログラムは、プロセッサによって実行されて、上記のステップまたは機能を実装することができる。同様に、本発明のソフトウェア・プログラム（関連のあるデータ構造を含む）は、コンピュータ読取り可能記録媒体、例えば、ＲＡＭメモリ、磁気ドライバもしくは光ドライバ、またはフロッピィ・ディスク、および他の類似したデバイスに記憶されることもある。それに加えて、本発明のいくつかのステップまたは機能は、ハードウェアにより、例えば、様々な機能またはステップを実行するようにプロセッサと協調する回路により、実装されることもある。
【００９１】
加えて、本発明の一部分は、コンピュータ・プログラム製品、例えば、コンピュータ・プログラム命令として、適用されることもあり、このコンピュータ・プログラム命令は、コンピュータによって実行されるときに、コンピュータのオペレーションを通して、本発明による方法および／または技術的問題解決手法を呼び出し、または提供することができる。さらに、本発明の方法を呼び出すプログラム命令は、固定された記録媒体またはモバイル記録媒体に記憶され、かつ／または他の信号ベアラ媒体におけるブロードキャストまたはデータ・フローを通して送信され、かつ／またはプログラム命令に基づいて動作するコンピュータ・デバイスのワーキング・メモリに記憶されることもある。ここで、本発明による一実施形態は、コンピュータ・プログラム命令を記憶するためのメモリと、プログラム命令を実行するためのプロセッサとを備える装置を備えており、そこでは、コンピュータ・プログラム命令が、プロセッサによって実行されるときに、本装置は、本発明の複数の実施形態による方法および／または技術的問題解決手法を実行するようにトリガされる。
【００９２】
当業者にとっては、本発明が、上記の例示の実施形態についての詳細だけには限定されず、また本発明は、本発明の精神または基本的な特徴を逸脱することなく、他の実施形態を用いて実装され得ることが、明らかである。したがって、いずれにしても、それらの実施形態は、例示的であり、非限定的であると見なされるべきであり、本発明の範囲は、上記説明の代わりに添付の特許請求の範囲によって限定され、また特許請求の範囲の同等な要素の意味および範囲に含まれることを意図しているすべての変形形態は、本発明の内部に対象として含まれるべきである。特許請求の範囲の中の参照符号は、関与する特許請求の範囲についての限定するものとして見なされるべきではない。それに加えて、用語「備える／含む（ｃｏｍｐｒｉｓｅ）」は、他のユニットまたはステップを除外するものではなく、また単数形は、複数形を除外していないことは明らかである。システム請求項において述べられる複数のユニットまたはモジュールはまた、ソフトウェアまたはハードウェアを通して単一のユニットまたはモジュールによって実装される可能性もある。第１の（ｔｈｅ  ｆｉｒｓｔ）や第２の（ｔｈｅ  ｓｅｃｏｎｄ）などの用語は、名前を示すために使用されるが、どのような特定のシーケンスも示してはいない。
【図２】
2016521032.tif 000009
【図３】
2016521032.tif 000010
【図４】
2016521032.tif 000011
【図１】
2016521032.tif 000012
【図５】
2016521032.tif 000013
【図６】
2016521032.tif 000014
【図７】
2016521032.tif 000015
【国際調査報告】
2016521032.tif 000016
2016521032.tif 000017
2016521032.tif 000018