JP5813247B2 - 信号トラフィックの低減 - Google Patents

Description

ロング・ターム・エボリューション（ＬＴＥ：ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）ワイヤレス通信ネットワークにおいては、モバイル電話や他の無線対応デバイスなどのユーザ機器（ＵＥ：ｕｓｅｒ ｅｑｕｉｐｍｅｎｔ）が、進化型ノードＢ（ｅノードＢ（ｅＮｏｄｅＢ：ｅｖｏｌｖｅｄ Ｎｏｄｅ Ｂ））とユーザ・データを断続的に交換する。データは、ボイス・オーバーＩＰ（ＶＯＩＰ：ｖｏｉｃｅ ｏｖｅｒ ＩＰ）コンテンツ、マルチメディア・コンテンツ、インターネット・トラフィック・コンテンツ、または他のコンテンツを含むことができ、またアップリンク（ＵＬ）データとしてネットワークに向かって送信され、あるいはダウンリンク（ＤＬ）データとしてネットワークから受信されることもある。

管理の観点から、ＵＥは、３つの状態、すなわち、切り離された状態、アイドル状態、または接続された状態のうちの１つにある。ＵＥが最初にオンにされると、ＵＥは切り離された状態にあり、またデータ交換のために使用可能な指定されたネットワーク・リソースを有してはいない。ネットワークに登録するとすぐに、ＵＥは、接続された状態に入り、またデータ転送を可能にするｅノードＢとの無線リソース制御（ＲＲＣ：ｒａｄｉｏ ｒｅｓｏｕｒｃｅ ｃｏｎｔｒｏｌ）接続を有する。ユーザ・データが交換されない非アクティビティ期間の後に、ＵＥは、アイドル状態に入って、ネットワーク・リソースを節約し、またＵＥのバッテリの寿命を長持ちさせることができる。ＵＥは、新しいデータ転送が差し迫っているときに、アイドル状態から接続された状態に再び入ることができる。

ｅノードＢによってサポートされ得るＵＥの最大の数は、有限である。その限界に到達しようとするときに、いくつかのＵＥは、無線リソース制御（ＲＲＣ）の接続解放を経由して、アイドル状態へと遷移されて、新しいコールと、着信するハンドオーバ（ＨＯ）要求とについての余地を与えることができる。ＲＲＣ解放のために選択されるＵＥは、「休眠状態」にあり、またある時間にわたってＵＬベアラ・サービスと、ＤＬベアラ・サービスとを使用していなかったＵＥとすることができる。解放されたＵＥは、ネットワークにアタッチされたままであり、またベアラ・トラフィックが開始されるときに、新しいＲＲＣ接続要求をトリガすることができる。

収益を生むわけではないが、接続された状態からアイドル状態へのこれらの遷移は、様々なネットワーク要素によって処理されるべき信号負荷に寄与する。接続された状態からアイドル状態へのＵＥ状態の頻繁な遷移（ＲＲＣ解放およびＳ１解放（Ｓ１Ｒｅｌｅａｓｅ））と、アイドル状態から逆に接続された状態へのＵＥ状態の頻繁な遷移（サービス要求）とは、ｅノードＢと、進化型パケット・コア（ＥＰＣ：ｅｖｏｌｖｅｄ ｐａｃｋｅｔ ｃｏｒｅ）との容量および性能に、かなり影響を及ぼす可能性がある。さらに、ひとたびＵＥがアイドル状態になれば、ネットワークによって開始されるサービス要求は、信号トラフィックを増大させることになるページングを必要とし、無線周波数（ＲＦ：ｒａｄｉｏ ｆｒｅｑｕｅｎｃｙ）リソースの使用を増大させ、またより長いページング・サイクル（２．５秒までの）で構成されたＵＥが、ページング・チャネルを監視するための遅延を長くする。

新しいアプリケーションと、デバイスとの導入とともに、各ネットワーク要素（ｅノードＢ／ＥＰＣ）がサポートする必要がある信号トラフィック負荷の量を予測することは、非常に難しい可能性がある。新しいデバイスまたはアプリケーションの展開が、ネットワークにおいて渋滞状態と過負荷状態とを引き起こす可能性があるので、これは、オペレータのための課題を提示する。これは、ネットワークのリエンジニアリングと、追加のノードの展開とを必要とする可能性がある（これには、数ヶ月かかる可能性がある）。

３ＧＰＰ ＴＳ ３６．３２１ ３ＧＰＰ ＴＳ ３６．３３１ ３ＧＰＰ ＴＳ ２２．０１１、セクション４

本発明は、一実装形態において、一つの方法を包含している。ハンドオーバについての測定報告は、ソースｅノードＢによってサービスされるユーザ機器（ＵＥ）からロング・ターム・エボリューション（ＬＴＥ）通信ネットワークのソース進化型ノードＢ（ｅノードＢ）において受信される。ＵＥが、休眠状態にあるかどうかの判定が行われる。ハンドオーバについての現在の負荷レベルが、しきい値より上にあるかどうかの判定が行われる。現在の負荷レベルがしきい値より上にあり、ＵＥが休眠状態にある場合に、測定報告は破棄される。現在の負荷レベルがしきい値より上になく、ＵＥが休眠状態にない場合に、ハンドオーバは、測定報告に基づいてトリガされる。

本発明の別の実装形態は、別の方法を包含している。ＵＥのハンドオーバについての要求は、ＬＴＥ通信ネットワークのソースｅノードＢから受信される。ハンドオーバについての現在の負荷レベルが、負荷しきい値より上にあるかどうかの判定が行われる。現在の負荷レベルが負荷しきい値より上にない場合、この要求は受け入れられる。ＵＥについての非アクティビティ時間が、所定の非アクティビティしきい値よりも上にあるかどうかの判定が行われる。非アクティビティ時間が所定の非アクティビティしきい値よりも上にある場合に、ハンドオーバは拒絶される。

本発明のさらなる一実装形態は、ある装置を包含している。本装置は、ロング・ターム・エボリューション（ＬＴＥ）通信ネットワークの進化型ノードＢ（ｅノードＢ）を備えている。ｅノードＢの現在の負荷レベルが負荷しきい値より上にある場合に、ｅノードＢは、ｅノードＢによってサービスされる少なくとも１つのＵＥを解放するように構成されている。ｅノードＢが、接続されたユーザしきい値に到達している場合に、ｅノードＢは、さらに、ｅノードＢによってサービスされる少なくとも１つのＵＥを解放するように構成されている。現在の負荷レベルが負荷しきい値より上になく、またｅノードＢが接続されたユーザしきい値に到達していない場合に、ｅノードＢは、少なくとも１つのＵＥについての解放非アクティビティ・タイマーを増大させるように構成されている。

本発明の例示の実装形態の特徴は、説明と、特許請求の範囲と、添付の図面とから、明らかになるであろう。

少なくとも１つの進化型ノードＢ（ｅノードＢ）と、モビリティ管理エンティティ（ＭＭＥ：ｍｏｂｉｌｉｔｙ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）と、ゲートウェイと、ユーザ機器とを有する、外部ネットワークおよびロング・ターム・エボリューション（ＬＴＥ）ネットワークを備えるシステムの一実装形態を示す図である。 図１のシステムにおける、周波数内ハンドオーバについてのユーザ機器（ＵＥ）報告の受信を示すソースｅノードＢについての論理フローを示す図である。 図１のシステムにおける、周波数内ハンドオーバについてのカバレッジ・アラーム報告の受信を示すソースｅノードＢについての論理フローを示す図である。 図３の論理フローの後のＡ３報告またはＡ５報告の受信についての論理フローを示す図である。 図１のシステムにおけるＲＡＴ間ハンドオーバについてのカバレッジ・アラーム報告の受信を示すソースｅノードＢについての論理フローを示す図である。 図５の論理フローの後のＢ２報告の受信を示すソースｅノードＢについての論理フローを示す図である。 図１のシステムにおける周波数内ハンドオーバについてのハンドオーバ要求の受信を示すターゲットｅノードＢについての別の論理フローを示す図である。 アイドル状態、または休眠状態にあるＵＥの数を保持するプロセスを示すソースｅノードＢについての論理フローを示す図である。

ユーザ機器（ＵＥ）と、進化型ノードＢ（ｅノードＢ）とにおける媒体アクセス制御不連続受信（ＭＡＣ−ＤＲＸ：Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ）サポートは、規格（３ＧＰＰ ＴＳ ３６．３２１およびＴＳ ３６．３３１）によって導入され、これらの規格は、信号負荷の問題のいくつかに対処する助けを行う。ｅノードＢによってＭＡＣ−ＤＲＸを用いて構成されたＵＥは、ＵＬデータまたはＤＬデータの最後のスケジューリングの後に、ＭＡＣ−ＤＲＸサイクルに入ることになる。ＭＡＣ−ＤＲＸ非アクティビティ・タイマーは、ＤＲＸサイクルに入るべきかどうか、また休眠状態になるべきかどうかを決定するカウントダウン・タイマーとしての機能を果たす。これらの休眠状態にあるＭＡＣ−ＤＲＸ ＵＥに割り付けられるｅノードＢのリソースは、次いで、ＵＬベアラ・トラフィックまたはＤＬベアラ・トラフィックを用いて、他のＵＥに、または新しく接続されたＵＥと次に来るべきハンドオーバのＵＥとに再割り付けされる可能性がある。たとえＵＬベアラ・サービスまたはＤＬベアラ・サービスを使用したＵＥの数が、ほぼ同じままに留まる可能性があるとしても、これは、ｅノードＢによってサポートされる接続されたＵＥの最大数の増大、例えば、ｅノードＢ当たりに５００個からｅノードＢ当たりに２，０００個への、増大を可能にする。

ＭＡＣ−ＤＲＸサイクルを使用するＵＥは、より長い接続持続時間を有することになり、この接続持続時間は、ＵＥ当たりのハンドオーバ（ＨＯ）イベントの頻度を増大させることになる。これらの追加のＨＯイベントは、ｅノードＢと、ＵＥとの両方の上の処理リソースの使用を増大させる。例えば、ＵＥ上の余分の処理は、より多くのバッテリ電力を消費することになり、またｅノードＢ上の余分の処理は、アップリンク（ＵＬ）トラフィックまたはダウンリンク（ＤＬ）トラフィック、ならびに収益を生成している新しいコールとともに、接続されたＵＥのハンドオーバに影響を及ぼす可能性がある。

現在の３ＧＰＰ規格のプロシージャは、ｅノードＢが、通常の状態の下におけるユーザの非アクティビティに基づいて、無線リソース制御（ＲＲＣ）とＳ１解放とを通して、ＲＲＣ接続されたＵＥの解放をトリガすることを必要とする。ユーザの非アクティビティは、ｅノードＢにおけるあらかじめ構成された「解放非アクティビティ・タイマー」に基づいている。ＭＡＣ−ＤＲＸが、イネーブルにされない場合、解放非アクティビティ・タイマーは、ＵＥバッテリ寿命を長持ちさせるために、比較的低い値に設定される（例えば、約１０秒）。低い解放非アクティビティ・タイマーを用いて、ＵＥタイプに応じて、約１０〜５０のアイドル状態から接続状態への遷移が、高いネットワーク・トラフィックの「混雑時（Ｂｕｓｙ Ｈｏｕｒ）」期間中にトリガされることが、観察されている。これは、ネットワーク上のかなりのシグナリング負荷をもたらす。

ＭＡＣ−ＤＲＸがイネーブルにされた場合、増大された解放非アクティビティ・タイマーは、ＵＥのバッテリ寿命により小さな影響を及ぼす。解放非アクティビティ・タイマーをより大きくすると、接続の試み（例えば、アイドル状態から接続された状態への遷移）の数を低減させるが、また休眠状態にあるＵＥに関連するハンドオーバ・イベントの数を増大させることもある。ＵＥバッテリに対する、またｅノードＢ負荷に対する影響を最小限にするために、休眠状態にあるＵＥによってトリガされるこれらの余分のハンドオーバ・イベントを管理することは有益である。また、単一の解放非アクティビティ・タイマーは、異なるタイプのＵＥと、関連するトラフィックとについて適切に「調整」されない可能性がある（例えば、スマートフォン／タブレットは、マシン・ツー・マシン・デバイスに比べて異なるアプリケーションを動作させる）。１つの目標は、ＵＥのバッテリ寿命に対して最小限の影響で、ネットワークの上の全体的な信号負荷を低減させることである。

アイドルからＲＲＣへの接続の遷移を妨げてしまうことを低減させるため、及び、進化型パケット・コア（ＥＰＣ）及びｅノードＢ上で制御プレーン信号イベントを低減させるため、並びに、アイドル状態からＲＲＣ接続された状態への遷移に固有のレイテンシを低減させるため、ｅノードＢにおけるサポートの強化が提案されている。ＭＡＣ−ＤＲＸがサポートされる一実装形態においては、ＵＥは、解放非アクティビティ・タイマーを増大させることにより、より長い期間にわたってＲＲＣ接続された状態に保持されることになる。タイマーは、実質的に１０秒を超える長さに増大されてもよい。

第１の例においては、単一の「静的」解放非アクティビティ・タイマー値が、すべてのＵＥについてサービス・プロバイダによって提供される。解放非アクティビティ・タイマー値についての値は、それだけには限定されないが、２秒と１００秒との間の値を含んでいる。第２の例においては、解放非アクティビティ・タイマー値は、デバイス・タイプ、ネットワーク負荷、ユーザの優先順位など１つまたは複数のファクタに基づいて動的に設定される可能性がある。追加のファクタが、当業者には明らかになるであろう。例えば、異なる解放非アクティビティ・タイマー値は、スマートフォンと、マシン・ツー・マシン・デバイスとのために使用されることもある。後者では、追加の強化が、モビリティ管理エンティティ（ＭＭＥ）において実行され、その結果、解放非アクティビティ・タイマーは、アタッチ・プロシージャ中に個別のＵＥごとに指定される可能性がある。

休眠状態にあるＵＥの発信ＨＯイベントなどの信号を低減させるために、ＭＡＣ−ＤＲＸモードにおけるＵＥからのＨＯ測定報告が、本明細書において説明されるように、ｅノードＢによって破棄される、または無視される可能性がある。イベントＡ２測定がｅノードＢによって（例えば、外部ネットワーク１０４から離れている非境界セルにおいて）ＵＥを用いてセットアップされており、またソース・セルが過負荷状態にある場合には、ＵＥからのハンドオーバ測定報告は、ＲＲＣ接続解放を用いてｅノードＢによって取り扱われることもある。一例においては、ソースｅノードＢ負荷が、負荷しきい値より上にある場合、またはターゲット・セル負荷が、負荷しきい値より上にある場合に、報告は無視される。有利には、これは、ネットワーク（ｅノードＢおよびＥＰＣ）において信号負荷を低減させ、また収益を生まないイベントを処理するための過負荷状況を悪化させることを回避する。

休眠状態にあるＵＥについての、報告など、ある種のＨＯアクティビティを抑制することは、いくつかのファクタに起因して、全体のサービス性能にあまり影響を及ぼすこと無く行われ得る。第１のファクタは、周波数内ＨＯ測定トリガが、一般的に、ターゲット・セルの信号品質がオフセットだけソース・セルよりもよいことを示すイベントＡ３報告を使用することである。ＬＴＥカバレッジが実質的に重複する都市エリアの展開においては、ＵＥからのイベントＡ３測定報告は、必ずしも、ＨＯについてのＵＥ報告が破棄される場合に、差し迫った無線リンク故障（ＲＬＦ）が起きることになることを意味するとは限らない。

第２のファクタとして、ｅノードＢは、ＵＥを用いてイベントＡ２を構成することもでき、ここでは、ソース・セルの信号品質がしきい値よりも下にあるときに、ＲＬＦがまさに起ころうとしているかどうかを監視するために、ＵＥ報告がトリガされる。イベントＡ３報告を送信した後に、またイベントＡ２報告を送信することに先立って、いくつかのＵＥは、それらが良好なカバレッジ・エリアへと戻りつつあるので、信号品質の改善を見ることができる。代わりに、いくつかのＵＥは、さらなるＲＦの悪化を経験しないこともある。イベントＡ３報告を破棄することは、これらのＵＥに影響を及ぼさない。

第３のファクタは、悪化したＲＦ信号を有するＵＥが、多くの場合に、ソース・セルから離れていることである。ハンドオーバのないときには、ＵＥは、ＵＥのＲＲＣ解放とＳ１解放とをトリガするために使用されることになるイベントＡ２報告を送信することになる。これは、ＵＥをアイドル状態に置き、またそのＵＥに対して以前に割り付けられたネットワーク・リソースを解放する。

さらに、ｅノードＢは、ＲＲＣ接続された状態にＵＥを保持するためにいくつかのファクタを考慮に入れることができる。一例においては、ｅノードＢは、接続されたＵＥ（ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ）が最大サポート限度に到達するときに、ＵＥを解放して他のＵＥの接続を可能にすることができる。ｅノードＢは、休眠状態において最長時間が費やされたＵＥ、過剰なＨＯレート、ＵＥのタイプ、優先順位（もし使用可能なら）など、ある種の判断基準に基づいてどのＵＥ上で解放すべきかについての決定を行うことができる。

別の例においては、ｅノードＢが所定の状態に到達したときに、ｅノードＢは、ＵＥを解放することができる。例えば、プロセッサ、メモリ、または他のリソースが１つまたは複数のしきい値に到達しているときに、ｅノードＢは、ＵＥを解放するように構成されていることもある。ｅノードＢは、ＵＥの最近のハンドオーバ・レート、またはどれだけ長くＵＥが休眠状態にあったかを示す休眠タイマーに基づいて、ＵＥを解放するように決定することもできる。ハンドオーバ・レートと、休眠タイマーとは、構成可能なしきい値に基づいたものとすることができる。

一実装形態においては、ｅノードＢは、ＵＥが休眠状態にある間に、「ローカル」セルと、隣接セルとの間でトリガされる、ＵＥについてのハンドオーバのレート（または履歴）についての変数またはパラメータを保持するように構成されている。ｅノードＢは、例えば、ハンドオーバ要求の内部に含まれる別のｅノードＢに対するハンドオーバを実行するときに、Ｘ２インターフェース上でパラメータを送信するように構成されている。これにより、ｅノードＢは、ＵＥが休眠状態にある間に行うハンドオーバの数を追跡することができるようになる。

図１を参照すると、一実装形態におけるシステム１００は、少なくとも１つのユーザ機器（ＵＥ）１０６に対してワイヤレス通信サービスを提供するように構成されたロング・ターム・エボリューション（ＬＴＥ）通信ネットワーク１０２を備えている。一例における通信ネットワーク１０２は、少なくとも１つのｅノードＢ１０８および１１０と、サービング・ゲートウェイ（Ｓ−ＧＷ：ｓｅｒｖｉｎｇ ｇａｔｅｗａｙ）１１２と、パケット・データ・ネットワーク・ゲートウェイ（Ｐ−ＧＷ：ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋ ｇａｔｅｗａｙ）１１４と、モバイル管理エンティティ（ＭＭＥ）１１６とを備える。一例におけるｅノードＢ１０８および１１０は、本明細書において説明されるように、例として記録可能なデータ・ストレージ媒体１１８を備える。一例におけるｅノードＢ１０８および１１０は、進化型ユニバーサル地上波無線アクセス・ネットワーク（Ｅ−ＵＴＲＡＮ：Ｅｖｏｌｖｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）を形成する。一例におけるＳ−ＧＷ１１２と、Ｐ−ＧＷ１１４と、ＭＭＥ１１６とは、当業者には理解されるように、進化型パケット・コア（ＥＰＣ）を形成する。

一例におけるｅノードＢ１０８および１１０は、基地局、またはＬＴＥ通信ネットワーク１０２に対するアクセス・ポイントとしての機能を果たして、無線インターフェースの上でＵＥ１０６との通信リンクを提供する。ｅノードＢ１０８および１１０によって提供される特徴および機能は、無線インターフェース上の送信および受信のための物理レイヤ・プロシージャ（例えば、変調／復調、チャネル符号化／復号化）と、無線リソース制御（ＲＲＣ、無線インターフェース上の伝送のためのリソースの割付け、修正、および解放に関連している）と、無線モビリティ管理（ハンドオーバ決定のための測定および処理）とを含む。各ｅノードＢは、当業者には理解されるように、１つまたは複数のセルにサービスする。

一例におけるＳ−ＧＷ１１２は、ＵＥ１０６とのパケット通信のためのローカル・モビリティ・アンカーとしての機能を果たす。Ｓ−ＧＷ１１２は、Ｅ−ＵＴＲＡＮに対して終端ポイントを提供し、ＵＥ１０６が、ｅノードＢ１０８と１１０との間でハンドオフされることを可能にする。一例におけるＰ−ＧＷ１１４は、外部のパケット・データ・ネットワーク（ＰＤＮ：ｐａｃｋｅｔ ｄａｔａ ｎｅｔｗｏｒｋｓ）に対するアンカー・ポイントとしての機能を果たす。ＭＭＥ１１６は、加入者管理と、セッション管理とを提供する。ｅノードＢ１０８および１１０と、Ｓ−ＧＷ１１２と、Ｐ−ＧＷと、ＭＭＥ１１６との追加の特徴および機能は、当業者にとって明らかであろう。

別の実装形態においては、システム１００は、１つまたは複数の外部ネットワーク１０４をさらに備えている。一例における外部ネットワーク１０４は、符号分割多元接続（ＣＤＭＡ：Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、ユニバーサル・モバイル・テレコミュニケーション・システム（ＵＭＴＳ：Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）、移動通信用グローバル・システム（ＧＳＭ：Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）など、代替的なアクセス技術を有するワイヤレス通信ネットワークを備える。別の例においては、外部ネットワーク１０４は、インターネットなどのパケット・データ・ネットワーク（ＰＤＮ）を備えている。

ＵＥ１０６は、ＬＴＥ通信ネットワーク１０２によって提供されるサービス・カバレッジ・エリア（例えば、ｅノードＢによってサービスされるセル）を動き回るので、ＵＥ１０６は、信号品質についての様々な測定を行い、または実行する。それらの測定は、１つまたは複数の周波数内測定と、周波数間測定と、無線アクセス技術間（ＲＡＴ間（ｉｎｔｅｒ−ＲＡＴ：ｉｎｔｅｒ−ｒａｄｉｏ ａｃｃｅｓｓ ｔｅｃｈｎｏｌｏｇｙ））測定とを含むことができる。ハンドオーバに関連する信号品質における変化など、所定の条件が満たされているときに、ＵＥは、そのＵＥが現在接続されているセルを管理するソースｅノードＢに対して測定報告を送信する。測定報告の例は、３ＧＰＰ ＴＳ ３６．３３１において説明されるように、イベントＡ１と、Ａ２と、Ａ３と、Ａ４と、Ａ５と、Ｂ１と、Ｂ２とを含む。

測定報告の受信のすぐ後に、ソースｅノードＢは、ターゲット・セルとのハンドオーバを実行すべきかどうかを決定することができる。ターゲット・セルは、同じ周波数（周波数内ハンドオーバ）、異なる周波数（周波数間ハンドオーバ）、または異なる無線アクセス技術（ＲＡＴ、ＲＡＴ間ハンドオーバ）を使用することができる。ターゲット・セルは、外部ネットワーク１０４の内部のソースｅノードＢ、別のターゲットｅノードＢ、または基地局（例えば、ワイヤレス・ローカル・エリア・ネットワーク・アクセス・ポイント、ＧＰＲＳ基地局、ＵＭＴＳ基地局など）によってサービスされる可能性がある。

図２を参照すると、論理フロー２００は、ソースｅノードＢ、例えば、ｅノードＢ１１０によって実行されるステップを示しており、ここで、測定報告は、イベントＡ３報告などの周波数内ハンドオーバ測定報告である。報告の受信（ステップ２０２）のすぐ後に、ｅノードＢ１１０は、ＵＥ１０６が休眠状態にあるかどうかを判定する（ステップ２０４）。一例において、ｅノードＢ１１０は、ＵＥ１０６が、非アクティビティ時間など、所定の長さの時間内にユーザ・データを転送していない場合に、ＵＥ１０６が休眠状態にあると考える。一例における非アクティビティ時間は、ユーザ・プレーン・データを送信するとすぐに、または受信するとすぐに、リセットされる。一例におけるユーザ・プレーン・データは、トラフィック無線ベアラ（ＴＲＢ：ｔｒａｆｆｉｃ ｒａｄｉｏ ｂｅａｒｅｒｓ）上で搬送されるユーザ・プレーン・トラフィックであり、このユーザ・プレーン・トラフィックは、信号無線ベアラ（ＳＲＢ：ｓｉｇｎａｌｉｎｇ ｒａｄｉｏ ｂｅａｒｅｒ）上で搬送される信号トラフィック（例えば、測定報告）とは異なる。ユーザ・プレーン・データは、アップリンク（ＵＬ）ユーザ・プレーン・トラフィック、またはダウンリンク（ＤＬ）ユーザ・プレーン・トラフィックを含んでいる。ユーザ・アクティビティの存在と、非アクティビティ・タイマーをリセットすべきかどうかとを決定するための他の判断基準は、当業者には明らかであろう。

ＵＥ１０６が休眠状態にない場合、ｅノードＢ１１０は、例えば、ハンドオーバ要求をｅノードＢ１０８に対して送信することにより、ハンドオーバをトリガする（ステップ２０６）。ＵＥ１０６が現在休眠状態にある場合、ｅノードＢ１１０は、ＵＥ１０６（またはそれを使用する加入者）が、「優先ユーザ」であるかどうかについての判定（ステップ２０５）を行う。優先ユーザの例は、緊急サービスまたはネットワーク・オペレータ（３ＧＰＰ ＴＳ ２２．０１１ セクション４に説明されるような）や高いサービス品質（ＱｏＳ）レベルを有する加入者など、特定のアクセス・クラスを有するこれらのユーザを含む。優先ユーザを決定するための追加の例またはファクタは、当業者には明らかであろう。ＵＥ１０６が優先ユーザである場合、ｅノードＢ１１０は、ハンドオーバ（ステップ２０６）をトリガする。

ＵＥ１０６が、優先ユーザでない場合、ｅノードＢ１１０は、その負荷レベルを所定の負荷しきい値、または容量しきい値と比較する（ステップ２０８）。負荷レベルは、当業者には理解されるように、プロセッサ利用、メモリ使用、無線リソース割付け、他など、１つまたは複数のファクタに基づいたものとすることができる。しきい値についての値は、当業者には理解されように、その定格容量、または何らかの他の動作ポイントの近くにｅノードＢを保持するために、サービス・プロバイダによって提供されることもある。

ｅノードＢ１１０の負荷が負荷しきい値より上にある（例えば、過負荷であり、または容量いっぱいである）場合、第１の例におけるｅノードＢ１１０は、報告を無視する（ステップ２１０）または破棄する。別の例においては、ｅノードＢ１１０は、ステップ２１０においてＵＥ１０６を解放する。上記で説明されるように、ＵＥ１０６は、良好なカバレッジ・エリアへと戻る動きのために、信号品質における改善を見ることができる。一例におけるｅノードＢ１１０は、最終的にＵＥ１０６を解放する前に、所定の数の報告（例えば、３つの報告）を無視するように構成されている。所定の数の報告は、ネットワーク状態または他のファクタに基づいて、サービス・プロバイダによって供給される、または動的に判定される可能性がある。

ソースｅノードＢ１１０が過負荷にされていない場合、ｅノードＢ１１０は、オプションとして、ターゲット・セルが過負荷にされているかどうかについての判定（ステップ２１２）を行うことができる。ステップ２１２は、ターゲット・セル情報が使用可能でない可能性があり、ここでは、ターゲット・セルは、異なるベンダーによって製造されるｅノードＢによってサービスされ、異なる規格に準拠するか、または異なるサービス・プロバイダによって動作させられるので、オプションである。ターゲット・セルが、ｅノードＢ１０８によって管理される場合の一例においては、ｅノードＢ１０８および１１０は、Ｘ２インターフェース上で通信して、ターゲット・セル負荷を提供する。別の例においては、ｅノードＢ１１０は、当業者には理解されるように、ｅノードＢ１０８についての過負荷フラグまたは変数をチェックして、その負荷ステータスを決定する。ターゲットｅノードＢ１０８が過負荷である場合、ｅノードＢ１１０は、上記で説明されるようにステップ２１０へと進むことができる。ソース・セルと、ターゲット・セルとは、判定のために、同じ負荷しきい値と比較される、または別個のしきい値と比較されることもある。ｅノードＢ１１０はまた、最初のターゲットが過負荷状態にある場合に、いくつかの可能性のあるターゲット・セルを監視し、また代替案を選択することができる。一例においては、第１のｅノードＢが過負荷である、またはハンドオーバを拒絶する場合に、ステップ２１２において、ＵＥ１０６からの測定報告は、ｅノードＢ１１０によるハンドオーバ考察のための追加のターゲット・セルを含んでいる。

ソース・セルとターゲット・セルとが休眠状態にあるＵＥ１０６に対して十分な容量を有する場合、そのときにはｅノードＢ１１０は、１つまたは複数の解放ファクタを評価して（ステップ２１４）、ハンドオーバをトリガすべきかどうかを決定する（ステップ２１６）、またはＵＥ１０６を解放する（ステップ２１８）。解放ファクタの例は、ＵＥ１０６についてのハンドオーバ・レートと、非アクティビティ時間とを含む。例えば、ＵＥ１０６が休眠状態にある間にかなりの数のハンドオーバを実行しており、かつ／または所定の非アクティビティ時間（例えば、３秒、１０秒など）内にどのようなデータも送信していないか、または受信していない場合に、ｅノードＢ１１０は、ＵＥ１０６を解放することができる（ステップ２１８）。追加の解放ファクタと、それらのそれぞれのしきい値とは、サービス・プロバイダによって供給され、またｅノードＢ１１０によって考慮されることもある。さらなる一例においては、しきい値は、ネットワーク状態、ユーザ・プロファイル、ＵＥのタイプ（例えば、タブレットもしくは電話）、または他のファクタに基づいて、動的に決定されることもある。ハンドオーバが実行されるときに、ｅノードＢ１１０は、ハンドオーバ・メッセージをターゲットｅノードＢに対して送信し、またＵＥ１０６のハンドオーバ周波数または履歴についてのパラメータまたは変数を含んでいる。

ＬＴＥ内ハンドオーバ中に、ソース・セルは、ターゲット・セルに対するハンドオーバ・メッセージの中にＵＥ情報を含める。既に３ＧＰＰ規格は、ＵＥ情報が、ソース・セルによって測定されるＵＥの非アクティビティ時間を含むことを可能にしている。ソース・セルは、ターゲット・セルが過負荷状態にあるかどうかを範囲亭することができない場合に、ハンドオーバを試みることができる。ターゲット・セルが過負荷状態にある場合、ターゲット・セルは、ソース・セルからのＵＥの非アクティビティ時間情報を使用して、着信ＨＯ要求が取り扱われるべきか、または拒絶されるべきかを決定することができる。例えば、ＵＥが、最後の３秒以上にわたってソース・セルにおいて休眠状態、またはアイドル状態にあった場合に、ターゲット・セルは、ターゲット・セルが既に過負荷状態にある場合に、着信ＨＯ要求を拒絶することを決定することができる。これは、ハンドオーバについての代替的なターゲット・セルを選択するように、ソース・セルをトリガする助けを行う。ＵＥの休眠状態またはアイドル状態が３秒よりも短い場合に、ターゲット・セルは、着信ＨＯを受け入れることができる。

図３を参照すると、論理フロー３００は、周波数間ハンドオーバ測定報告の受信のすぐ後に、ｅノードＢ１１０によって実行されるステップを示すものである。一例においては、ｅノードＢ１１０は、ＵＥ１０６からイベントＡ２「カバレッジ・アラーム」報告を受信し、このイベントＡ２「カバレッジ・アラーム」報告は、絶対しきい値よりも悪いが、依然として許容限度内にある信号品質を示すように構成されている。別の例においては、ｅノードＢ１１０は、ＵＥ１０６からイベントＡ２「フロア」報告を受信し、このイベントＡ２「フロア」報告は、絶対しきい値（すなわち、信号フロア）よりも悪く、もはやサービスのために十分でない信号品質を示すように構成されている。報告の受信（ステップ３０２）のすぐ後に、ｅノードＢ１１０は、ＵＥ１０６が休眠状態にあるかどうかを判定する（ステップ３０４）。ＵＥ１０６が休眠状態にない場合に、ｅノードＢ１１０は、イベントＡ３報告および／またはイベントＡ５報告など、１つまたは複数の追加の報告について、ＵＥ１０６を構成する（ステップ３０６）。

ＵＥ１０６が休眠状態にある場合、ｅノードＢ１１０は、図２のステップ２０８と同様に、ソース・セルの負荷がしきい値より上にあるかどうかを判定する（ステップ３０８）。ソース・セルが十分な負荷容量を有している場合、ｅノードＢ１１０は、ＵＥ１０６についての追加のイベントまたはメッセージを構成する（ステップ３０６）。ソース・セルが過負荷にある場合、ｅノードＢ１１０は、図２のステップ２１０と同様に、「カバレッジ・アラーム」報告を無視し（ステップ３１０）、また「フロア」報告のためにＵＥ１０６を解放する。しかしながら、この例においては、ｅノードＢ１１０が解放を実行する場合、ｅノードＢ１１０は、当業者には理解されるように、ターゲット・セルに向かうリダイレクションとともに解放を実行する。

図４を参照すると、また図２および３を参照すると、論理フロー４００は、周波数間測定報告の、例えば、ステップ３０６において構成されるイベントＡ３報告および／またはイベントＡ５報告の受信のすぐ後に、ｅノードＢ１１０によって実行されるステップを示している。ステップ４０２において、ｅノードＢ１１０は、Ａ３報告またはＡ５報告を受信する。ステップ４０４と、４０５と、４０６と、４０８と、４１２と、４１４と、４１６とは、図２におけるそれらそれぞれの対応するステップに類似している。ステップ４１０と、４１８とは、３１０と、３１８とに類似しているが、ｅノードＢ１１０が解放を実行する場合、ｅノードＢ１１０は、当業者には理解されるように、ターゲット・セルに向かうリダイレクションとともに解放を実行する。

図５を参照すると、また図３を参照すると、論理フロー５００は、ＲＡＴ間測定報告の受信のすぐ後に、ｅノードＢ１１０によって実行されるステップを示している。ＲＡＴ間測定報告は、ＵＥ１０６が外部ネットワーク１０４のカバレッジ範囲内に来るときに受信されることもあり、またしたがって、ＬＴＥからＣＤＭＡ、ＬＴＥからＵＭＴＳ、ＬＴＥからＧＳＭ、またはＬＴＥから別のワイヤレス・ネットワークへのハンドオーバが起こる可能性がある。一般に、ＲＡＴ間ハンドオーバが、２Ｇワイヤレス・ネットワーク、または３Ｇワイヤレス・ネットワークに隣接したＬＴＥ通信ネットワーク１０２の境界領域の近くで起こることになる。

一例においては、ｅノードＢ１１０は、ＵＥ１０６からイベントＡ２「カバレッジ・アラーム」報告を受信する（ステップ５０２）。ステップ５０４と、５０８と、５１０とは、図３におけるそれらそれぞれの対応するステップに類似している。ステップ５０６は、ステップ３０６に類似しているが、ｅノードＢ１１０は、当業者には理解されるように、イベントＡ３またはＡ５の代わりに、イベントＢ２を構成する。

図６を参照すると、論理フロー６００は、ステップ５０６において構成されるイベントＢ２報告の受信のすぐ後に、ｅノードＢ１１０によって実行されるステップを示している。ステップ６０４と、６０５と、６０６と、６０８と、６１０と、６１６とは、図４におけるそれらそれぞれの対応するステップに類似している。この例においては、ｅノードＢ１１０は、外部ネットワーク１０４の中にあるので、ターゲット負荷についての情報を有しておらず、したがって、ターゲット・セル負荷の決定は省略される。

図７を参照すると、論理フロー７００は、ｅノードＢ１１０からのハンドオーバのためのターゲットｅノードＢ、例えば、ｅノードＢ１０８によって実行されるステップを示している。ステップ７０２において、ｅノードＢ１０８は、ソースｅノードＢ１１０からハンドオーバ要求を受信する。ｅノードＢ１０８は、ステップ２０５において上記で説明されるように、ＵＥ１０６が優先ユーザであるかどうかを判定する（ステップ７０５）。ＵＥ１０６が優先ユーザである場合、ｅノードＢ１０８は、ハンドオーバ要求を処理する（ステップ７０６）。

次いで、ｅノードＢ１０８は、所定の負荷しきい値とそれ自体の負荷レベルを比較する（ステップ７０８）。負荷レベルは、ステップ２０８を参照して、上記で説明される１つまたは複数のファクタに基づいたものとすることができる。過負荷でない場合、ｅノードＢ１０８は、ハンドオーバを処理する（ステップ７０６）。ｅノードＢ１０８が過負荷状態にある場合には、ｅノードＢ１０８は、例えば、３秒から１０秒の間の所定の非アクティビティしきい値とＵＥ１０６の非アクティビティ時間を比較する（ステップ７１０）。非アクティビティ時間は、当業者には理解されるように、ハンドオーバ要求とともに受信される。所定のしきい値は、Ｅ−ＵＴＲＡＮについては一般に、または各ｅノードＢに特有に、サービス・プロバイダによって供給されることもある。さらに、所定のしきい値は、負荷状態に基づいて動的に決定されることもある。ＵＥ１０６の非アクティビティ時間がしきい値よりも長い場合、ｅノードＢ１０８は、ハンドオーバを拒絶する（ステップ７１２）。非アクティビティ時間がしきい値よりも短い場合に、ｅノードＢ１０８は、ハンドオーバを処理する（ステップ７０６）。

図８を参照すると、一例におけるソースｅノードＢは、論理フロー８００を実行して、所定の非アクティビティ時間の後に、ＵＥをアイドル状態に置く代わりに、接続されたＵＥを接続された状態に保持する。上記で説明されるように、これは、アイドル状態と、接続された状態との間でＵＥを遷移する信号オーバーヘッドを低減させることができる。一例における論理フロー８００は、ＵＥからの接続要求を受信するとすぐに、ソースｅノードＢによって実行される。例えば、ＵＥ１０６は、切り離された状態にある間に、ｅノードＢ１１０に対してＲＲＣ要求を送信して、データ伝送のためのリソースを取得する。代わりに、ｅノードＢは、タイマーの時間切れ、または過負荷イベントの発生など、別のトリガのすぐ後に、論理フロー８００を実行することもできる。

トリガ（ステップ８０２）のすぐ後に、一例におけるｅノードＢ１１０は、上記で説明されるように、所定のしきい値とその現在の負荷を比較する（ステップ８０４）。ｅノードＢ１１０が、過負荷状態にある場合、ｅノードＢ１１０は、１つまたは複数の休眠状態にあるＵＥを解放する（ステップ８０６）。ｅノードＢは、それらｅノードＢの優先順位ステータス、非アクティビティ時間、または他のファクタに基づいて解放のためのＵＥを選択することができる。例えば、一例におけるｅノードＢ１１０は、優先ユーザを解放することはなく、また３０秒以上にわたって非アクティブであったこれらのＵＥだけを解放する。

ｅノードＢ１１０が過負荷状態にない場合、ｅノードＢ１１０は、所定の接続されたユーザしきい値（ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ）と現在接続されているＵＥの数を比較する（ステップ８０８）。接続されたユーザしきい値が、例えば、接続されたＵＥの最大数に到達している場合、ｅノードＢ１１０は、休眠状態にあるＵＥを解放することができる（ステップ８０６）。最大数に到達していない場合、一例におけるｅノードＢ１１０は、１つまたは複数の接続されたＵＥの非アクティビティ時間を増大させる（ステップ８１０）。

一例におけるｅノードＢ１１０は、ＵＥのデバイス・タイプ、ＵＥについてのユーザ優先順位、ＵＥのＲＦ信号強度、ハンドオーバ周波数／履歴などのファクタに基づいて、増大された非アクティビティ時間を受信することになるＵＥを選択する。追加のファクタが、当業者にとっては明らかであろう。例えば、ｅノードＢ１１０は、十分に高いＲＦ信号と、しきい値よりも低い最近のハンドオーバの数とを有するこれらのＵＥだけを選択することができる。

増大された非アクティビティ・タイマーを受信するこれらの選択されたＵＥでは、一例におけるｅノードＢ１１０は、増大された非アクティビティ時間を選択する。例えば、デフォルトの非アクティビティ時間が１０秒である場合、この１０秒の後に、ＵＥは、通常、アイドル状態へと遷移されることになり、ｅノードＢ１１０は、３０秒、数分、またはより長い値へと非アクティビティ時間を増大させることができる。さらにある一例においては、ｅノードＢ１１０は、上記で説明されるように、デバイス・タイプ、ネットワーク負荷、ユーザ優先順位など、１つまたは複数のファクタに基づいて、新しい非アクティビティ時間を動的に選択する。非アクティビティ時間は、個々のＵＥ、若しくはＵＥのグループのために選択され、又は、カバレッジ・エリアにおけるすべてのＵＥに適用されることもある。

フィールドの観察（３Ｇおよび４Ｇ）に基づいて、ハンドオーバ・イベントの大部分は、約１０％のユーザによってトリガされる。これらのユーザは、一般的に、セル・カバレッジ・エリアの境界にあり、それゆえに重要なことは、これらのハンドオーバ・イベントを適切に管理することである。接続されたユーザの約８５％が、最小限の信号トラフィック（例えば、１〜２のＳＲ／Ｓ１解放、１〜２のＨＯおよび定期的ＴＡＵ）を生成することになることが、推定される。接続されたユーザの残りの１５％だけが、アイドル状態から接続された状態への遷移についての現在の平均信号負荷を生成し、またＨＯ低減のための提案された方法を用いて、現在の（またはより低い）平均レート（例えば、時間当たりのアタッチＵＥに対して、１５よりも少ないハンドオーバ）へとＨＯレートを低減させることになる。

一例における装置１００は、１つまたは複数の電子コンポーネント、ハードウェア・コンポーネント、コンピュータ・ソフトウェア・コンポーネントなど、複数のコンポーネントを備える。いくつかのそのようなコンポーネントは、装置１００において、結合され、または分割される可能性がある。本装置１００の例示のコンポーネントは、当業者には理解されるように、いくつかのプログラミング言語のうちのどれかを用いて書かれる、あるいは実施されるコンピュータ命令の組および／またはシリーズを使用し、かつ／または含んでいる。

一例における装置１００は、１つまたは複数のコンピュータ読取り可能非一時的媒体を使用する。コンピュータ読取り可能非一時的媒体は、本発明の１つまたは複数の実装形態の１つまたは複数の部分を実行するためのソフトウェア、ファームウェア、および／またはアセンブリ言語を記憶する。本装置１００についてのコンピュータ読取り可能非一時的媒体の例は、ｅノードＢ１０８および１１０の記録可能データ・ストレージ媒体１１８を備える。一例における本装置１００についてのコンピュータ読取り可能非一時的媒体は、１つまたは複数の磁気的データ・ストレージ媒体と、電気的データ・ストレージ媒体と、光学的データ・ストレージ媒体と、生物学的データ・ストレージ媒体と、アトミック・データ・ストレージ媒体とを備える。例えば、コンピュータ読取り可能非一時的媒体は、フロッピー・ディスクと、磁気テープと、ＣＤ−ＲＯＭと、ＤＶＤ−ＲＯＭと、ハード・ディスク・ドライブと、電子的メモリとを備える。

本明細書において説明されるステップまたはオペレーションは、ただ例のためにすぎない。本発明の精神を逸脱することなく、これらのステップまたはオペレーションに対する多数の変形形態が存在する可能性がある。例えば、それらのステップは、異なる順序で実行されることもあり、あるいはステップが、追加され、削除され、または修正されてもよい。

本発明の例示の実装形態は、本明細書において詳細に示され、また説明されてきているが、当業者にとっては、様々な修正形態と、追加形態と、置換形態などとが、本発明の精神を逸脱することなく作ることができ、またこれらは、それゆえに、添付の特許請求の範囲において規定されるように、本発明の範囲内にあるように考えられることが、明らかであろう。

Claims (8)

1. ロング・ターム・エボリューション（ＬＴＥ）通信ネットワークのソース進化型ノードＢ（ｅノードＢ）において、前記ソースｅノードＢによってサービスされるユーザ機器（ＵＥ）からハンドオーバについての測定報告を受信するステップと、
   前記ＵＥが休眠状態にあるかどうかを判定するステップと、
   前記ハンドオーバについての現在の負荷レベルが、しきい値より上にあるかどうかを判定するステップと、
   前記現在の負荷レベルが前記しきい値よりも上にあり、また前記ＵＥが休眠状態にある場合に、前記測定報告を破棄するステップと、
   前記現在の負荷レベルが前記しきい値よりも上にない場合、または前記ＵＥが休眠状態にない場合に、前記測定報告に基づいて前記ハンドオーバをトリガするステップと、
   を含む、方法。
2. 前記ＵＥが所定の非アクティビティ時間内にアップリンク（ＵＬ）ユーザ・データまたはダウンリンク（ＤＬ）ユーザ・データを転送していない場合に、前記ＵＥは休眠状態にある、請求項１に記載の方法。
3. 前記ＵＥについての解放非アクティビティ・タイマーを増大させるステップ、
   をさらに含み、前記ＵＥが前記解放非アクティビティ・タイマーの持続時間にわたってＵＬユーザ・データまたはＤＬユーザ・データを転送しない場合に、前記ソースｅノードＢは、前記ＵＥを解放するように構成されている、請求項１に記載の方法。
4. 前記解放非アクティビティ・タイマーを増大させる前記ステップは、
   前記現在の負荷レベルに基づいて前記解放非アクティビティ・タイマーを動的に調整するステップ、
   を含む、請求項３に記載の方法。
5. 前記ハンドオーバについての前記現在の負荷レベルが、前記しきい値よりも上にあるかどうかを判定する前記ステップは、
   前記ソースｅノードＢの負荷レベル、またはターゲットｅノードＢの負荷レベルが、ソースしきい値の上にあるかどうかを判定するステップ、
   を含む、請求項１に記載の方法。
6. 前記測定報告を破棄する前記ステップは、
   所定の数の以前に受信された測定報告が破棄された後に、前記ＵＥを解放するステップ、
   を含む、請求項１に記載の方法。
7. 前記ＵＥを解放する前記ステップは、
   周波数間測定報告、または無線アクセス技術間（ＲＡＴ間）測定報告についてのリダイレクションとともに前記ＵＥを解放するステップ、
   を含む、請求項６に記載の方法。
8. 前記測定報告を受信する前記ステップは、
   周波数間ハンドオーバまたはＲＡＴ間ハンドオーバについてのイベントＡ２測定報告を受信するステップと、
   前記イベントＡ２測定報告がカバレッジ・アラームを示す場合に、前記イベントＡ２測定報告を破棄するステップと、
   前記イベントＡ２測定報告が信号フロアを示す場合に、リダイレクションとともに前記ＵＥを解放するステップと、
   を含む、請求項１に記載の方法。

Images