(58)【調査した分野】(Int.Cl.,DB名)
【背景技術】
【0001】
ロング・ターム・エボリューション(LTE:long term evolution)ワイヤレス通信ネットワークにおいては、モバイル電話や他の無線対応デバイスなどのユーザ機器(UE:user equipment)が、進化型ノードB(eノードB(eNodeB:evolved Node B))とユーザ・データを断続的に交換する。データは、ボイス・オーバーIP(VOIP:voice over IP)コンテンツ、マルチメディア・コンテンツ、インターネット・トラフィック・コンテンツ、または他のコンテンツを含むことができ、またアップリンク(UL)データとしてネットワークに向かって送信され、あるいはダウンリンク(DL)データとしてネットワークから受信されることもある。
【0002】
管理の観点から、UEは、3つの状態、すなわち、切り離された状態、アイドル状態、または接続された状態のうちの1つにある。UEが最初にオンにされると、UEは切り離された状態にあり、またデータ交換のために使用可能な指定されたネットワーク・リソースを有してはいない。ネットワークに登録するとすぐに、UEは、接続された状態に入り、またデータ転送を可能にするeノードBとの無線リソース制御(RRC:radio resource control)接続を有する。ユーザ・データが交換されない非アクティビティ期間の後に、UEは、アイドル状態に入って、ネットワーク・リソースを節約し、またUEのバッテリの寿命を長持ちさせることができる。UEは、新しいデータ転送が差し迫っているときに、アイドル状態から接続された状態に再び入ることができる。
【0003】
eノードBによってサポートされ得るUEの最大の数は、有限である。その限界に到達しようとするときに、いくつかのUEは、無線リソース制御(RRC)の接続解放を経由して、アイドル状態へと遷移されて、新しいコールと、着信するハンドオーバ(HO)要求とについての余地を与えることができる。RRC解放のために選択されるUEは、「休眠状態」にあり、またある時間にわたってULベアラ・サービスと、DLベアラ・サービスとを使用していなかったUEとすることができる。解放されたUEは、ネットワークにアタッチされたままであり、またベアラ・トラフィックが開始されるときに、新しいRRC接続要求をトリガすることができる。
【0004】
収益を生むわけではないが、接続された状態からアイドル状態へのこれらの遷移は、様々なネットワーク要素によって処理されるべき信号負荷に寄与する。接続された状態からアイドル状態へのUE状態の頻繁な遷移(RRC解放およびS1解放(S1Release))と、アイドル状態から逆に接続された状態へのUE状態の頻繁な遷移(サービス要求)とは、eノードBと、進化型パケット・コア(EPC:evolved packet core)との容量および性能に、かなり影響を及ぼす可能性がある。さらに、ひとたびUEがアイドル状態になれば、ネットワークによって開始されるサービス要求は、信号トラフィックを増大させることになるページングを必要とし、無線周波数(RF:radio frequency)リソースの使用を増大させ、またより長いページング・サイクル(2.5秒までの)で構成されたUEが、ページング・チャネルを監視するための遅延を長くする。
【0005】
新しいアプリケーションと、デバイスとの導入とともに、各ネットワーク要素(eノードB/EPC)がサポートする必要がある信号トラフィック負荷の量を予測することは、非常に難しい可能性がある。新しいデバイスまたはアプリケーションの展開が、ネットワークにおいて渋滞状態と過負荷状態とを引き起こす可能性があるので、これは、オペレータのための課題を提示する。これは、ネットワークのリエンジニアリングと、追加のノードの展開とを必要とする可能性がある(これには、数ヶ月かかる可能性がある)。
【発明を実施するための形態】
【0012】
ユーザ機器(UE)と、進化型ノードB(eノードB)とにおける媒体アクセス制御不連続受信(MAC−DRX:Medium Access Control Discontinuous Reception)サポートは、規格(3GPP TS 36.321およびTS 36.331)によって導入され、これらの規格は、信号負荷の問題のいくつかに対処する助けを行う。eノードBによってMAC−DRXを用いて構成されたUEは、ULデータまたはDLデータの最後のスケジューリングの後に、MAC−DRXサイクルに入ることになる。MAC−DRX非アクティビティ・タイマーは、DRXサイクルに入るべきかどうか、また休眠状態になるべきかどうかを決定するカウントダウン・タイマーとしての機能を果たす。これらの休眠状態にあるMAC−DRX UEに割り付けられるeノードBのリソースは、次いで、ULベアラ・トラフィックまたはDLベアラ・トラフィックを用いて、他のUEに、または新しく接続されたUEと次に来るべきハンドオーバのUEとに再割り付けされる可能性がある。たとえULベアラ・サービスまたはDLベアラ・サービスを使用したUEの数が、ほぼ同じままに留まる可能性があるとしても、これは、eノードBによってサポートされる接続されたUEの最大数の増大、例えば、eノードB当たりに500個からeノードB当たりに2,000個への、増大を可能にする。
【0013】
MAC−DRXサイクルを使用するUEは、より長い接続持続時間を有することになり、この接続持続時間は、UE当たりのハンドオーバ(HO)イベントの頻度を増大させることになる。これらの追加のHOイベントは、eノードBと、UEとの両方の上の処理リソースの使用を増大させる。例えば、UE上の余分の処理は、より多くのバッテリ電力を消費することになり、またeノードB上の余分の処理は、アップリンク(UL)トラフィックまたはダウンリンク(DL)トラフィック、ならびに収益を生成している新しいコールとともに、接続されたUEのハンドオーバに影響を及ぼす可能性がある。
【0014】
現在の3GPP規格のプロシージャは、eノードBが、通常の状態の下におけるユーザの非アクティビティに基づいて、無線リソース制御(RRC)とS1解放とを通して、RRC接続されたUEの解放をトリガすることを必要とする。ユーザの非アクティビティは、eノードBにおけるあらかじめ構成された「解放非アクティビティ・タイマー」に基づいている。MAC−DRXが、イネーブルにされない場合、解放非アクティビティ・タイマーは、UEバッテリ寿命を長持ちさせるために、比較的低い値に設定される(例えば、約10秒)。低い解放非アクティビティ・タイマーを用いて、UEタイプに応じて、約10〜50のアイドル状態から接続状態への遷移が、高いネットワーク・トラフィックの「混雑時(Busy Hour)」期間中にトリガされることが、観察されている。これは、ネットワーク上のかなりのシグナリング負荷をもたらす。
【0015】
MAC−DRXがイネーブルにされた場合、増大された解放非アクティビティ・タイマーは、UEのバッテリ寿命により小さな影響を及ぼす。解放非アクティビティ・タイマーをより大きくすると、接続の試み(例えば、アイドル状態から接続された状態への遷移)の数を低減させるが、また休眠状態にあるUEに関連するハンドオーバ・イベントの数を増大させることもある。UEバッテリに対する、またeノードB負荷に対する影響を最小限にするために、休眠状態にあるUEによってトリガされるこれらの余分のハンドオーバ・イベントを管理することは有益である。また、単一の解放非アクティビティ・タイマーは、異なるタイプのUEと、関連するトラフィックとについて適切に「調整」されない可能性がある(例えば、スマートフォン/タブレットは、マシン・ツー・マシン・デバイスに比べて異なるアプリケーションを動作させる)。1つの目標は、UEのバッテリ寿命に対して最小限の影響で、ネットワークの上の全体的な信号負荷を低減させることである。
【0016】
アイドルからRRCへの接続の遷移を妨げてしまうことを低減させるため、及び、進化型パケット・コア(EPC)及びeノードB上で制御プレーン信号イベントを低減させるため、並びに、アイドル状態からRRC接続された状態への遷移に固有のレイテンシを低減させるため、eノードBにおけるサポートの強化が提案されている。MAC−DRXがサポートされる一実装形態においては、UEは、解放非アクティビティ・タイマーを増大させることにより、より長い期間にわたってRRC接続された状態に保持されることになる。タイマーは、実質的に10秒を超える長さに増大されてもよい。
【0017】
第1の例においては、単一の「静的」解放非アクティビティ・タイマー値が、すべてのUEについてサービス・プロバイダによって提供される。解放非アクティビティ・タイマー値についての値は、それだけには限定されないが、2秒と100秒との間の値を含んでいる。第2の例においては、解放非アクティビティ・タイマー値は、デバイス・タイプ、ネットワーク負荷、ユーザの優先順位など1つまたは複数のファクタに基づいて動的に設定される可能性がある。追加のファクタが、当業者には明らかになるであろう。例えば、異なる解放非アクティビティ・タイマー値は、スマートフォンと、マシン・ツー・マシン・デバイスとのために使用されることもある。後者では、追加の強化が、モビリティ管理エンティティ(MME)において実行され、その結果、解放非アクティビティ・タイマーは、アタッチ・プロシージャ中に個別のUEごとに指定される可能性がある。
【0018】
休眠状態にあるUEの発信HOイベントなどの信号を低減させるために、MAC−DRXモードにおけるUEからのHO測定報告が、本明細書において説明されるように、eノードBによって破棄される、または無視される可能性がある。イベントA2測定がeノードBによって(例えば、外部ネットワーク104から離れている非境界セルにおいて)UEを用いてセットアップされており、またソース・セルが過負荷状態にある場合には、UEからのハンドオーバ測定報告は、RRC接続解放を用いてeノードBによって取り扱われることもある。一例においては、ソースeノードB負荷が、負荷しきい値より上にある場合、またはターゲット・セル負荷が、負荷しきい値より上にある場合に、報告は無視される。有利には、これは、ネットワーク(eノードBおよびEPC)において信号負荷を低減させ、また収益を生まないイベントを処理するための過負荷状況を悪化させることを回避する。
【0019】
休眠状態にあるUEについての、報告など、ある種のHOアクティビティを抑制することは、いくつかのファクタに起因して、全体のサービス性能にあまり影響を及ぼすこと無く行われ得る。第1のファクタは、周波数内HO測定トリガが、一般的に、ターゲット・セルの信号品質がオフセットだけソース・セルよりもよいことを示すイベントA3報告を使用することである。LTEカバレッジが実質的に重複する都市エリアの展開においては、UEからのイベントA3測定報告は、必ずしも、HOについてのUE報告が破棄される場合に、差し迫った無線リンク故障(RLF)が起きることになることを意味するとは限らない。
【0020】
第2のファクタとして、eノードBは、UEを用いてイベントA2を構成することもでき、ここでは、ソース・セルの信号品質がしきい値よりも下にあるときに、RLFがまさに起ころうとしているかどうかを監視するために、UE報告がトリガされる。イベントA3報告を送信した後に、またイベントA2報告を送信することに先立って、いくつかのUEは、それらが良好なカバレッジ・エリアへと戻りつつあるので、信号品質の改善を見ることができる。代わりに、いくつかのUEは、さらなるRFの悪化を経験しないこともある。イベントA3報告を破棄することは、これらのUEに影響を及ぼさない。
【0021】
第3のファクタは、悪化したRF信号を有するUEが、多くの場合に、ソース・セルから離れていることである。ハンドオーバのないときには、UEは、UEのRRC解放とS1解放とをトリガするために使用されることになるイベントA2報告を送信することになる。これは、UEをアイドル状態に置き、またそのUEに対して以前に割り付けられたネットワーク・リソースを解放する。
【0022】
さらに、eノードBは、RRC接続された状態にUEを保持するためにいくつかのファクタを考慮に入れることができる。一例においては、eノードBは、接続されたUE(RRC_CONNECTED)が最大サポート限度に到達するときに、UEを解放して他のUEの接続を可能にすることができる。eノードBは、休眠状態において最長時間が費やされたUE、過剰なHOレート、UEのタイプ、優先順位(もし使用可能なら)など、ある種の判断基準に基づいてどのUE上で解放すべきかについての決定を行うことができる。
【0023】
別の例においては、eノードBが所定の状態に到達したときに、eノードBは、UEを解放することができる。例えば、プロセッサ、メモリ、または他のリソースが1つまたは複数のしきい値に到達しているときに、eノードBは、UEを解放するように構成されていることもある。eノードBは、UEの最近のハンドオーバ・レート、またはどれだけ長くUEが休眠状態にあったかを示す休眠タイマーに基づいて、UEを解放するように決定することもできる。ハンドオーバ・レートと、休眠タイマーとは、構成可能なしきい値に基づいたものとすることができる。
【0024】
一実装形態においては、eノードBは、UEが休眠状態にある間に、「ローカル」セルと、隣接セルとの間でトリガされる、UEについてのハンドオーバのレート(または履歴)についての変数またはパラメータを保持するように構成されている。eノードBは、例えば、ハンドオーバ要求の内部に含まれる別のeノードBに対するハンドオーバを実行するときに、X2インターフェース上でパラメータを送信するように構成されている。これにより、eノードBは、UEが休眠状態にある間に行うハンドオーバの数を追跡することができるようになる。
【0025】
図1を参照すると、一実装形態におけるシステム100は、少なくとも1つのユーザ機器(UE)106に対してワイヤレス通信サービスを提供するように構成されたロング・ターム・エボリューション(LTE)通信ネットワーク102を備えている。一例における通信ネットワーク102は、少なくとも1つのeノードB108および110と、サービング・ゲートウェイ(S−GW:serving gateway)112と、パケット・データ・ネットワーク・ゲートウェイ(P−GW:packet data network gateway)114と、モバイル管理エンティティ(MME)116とを備える。一例におけるeノードB108および110は、本明細書において説明されるように、例として記録可能なデータ・ストレージ媒体118を備える。一例におけるeノードB108および110は、進化型ユニバーサル地上波無線アクセス・ネットワーク(E−UTRAN:Evolved Universal Terrestrial Radio Access Network)を形成する。一例におけるS−GW112と、P−GW114と、MME116とは、当業者には理解されるように、進化型パケット・コア(EPC)を形成する。
【0026】
一例におけるeノードB108および110は、基地局、またはLTE通信ネットワーク102に対するアクセス・ポイントとしての機能を果たして、無線インターフェースの上でUE106との通信リンクを提供する。eノードB108および110によって提供される特徴および機能は、無線インターフェース上の送信および受信のための物理レイヤ・プロシージャ(例えば、変調/復調、チャネル符号化/復号化)と、無線リソース制御(RRC、無線インターフェース上の伝送のためのリソースの割付け、修正、および解放に関連している)と、無線モビリティ管理(ハンドオーバ決定のための測定および処理)とを含む。各eノードBは、当業者には理解されるように、1つまたは複数のセルにサービスする。
【0027】
一例におけるS−GW112は、UE106とのパケット通信のためのローカル・モビリティ・アンカーとしての機能を果たす。S−GW112は、E−UTRANに対して終端ポイントを提供し、UE106が、eノードB108と110との間でハンドオフされることを可能にする。一例におけるP−GW114は、外部のパケット・データ・ネットワーク(PDN:packet data networks)に対するアンカー・ポイントとしての機能を果たす。MME116は、加入者管理と、セッション管理とを提供する。eノードB108および110と、S−GW112と、P−GWと、MME116との追加の特徴および機能は、当業者にとって明らかであろう。
【0028】
別の実装形態においては、システム100は、1つまたは複数の外部ネットワーク104をさらに備えている。一例における外部ネットワーク104は、符号分割多元接続(CDMA:Code Division Multiple Access)、ユニバーサル・モバイル・テレコミュニケーション・システム(UMTS:Universal Mobile Telecommunications System)、移動通信用グローバル・システム(GSM:Global System for Mobile Communications)など、代替的なアクセス技術を有するワイヤレス通信ネットワークを備える。別の例においては、外部ネットワーク104は、インターネットなどのパケット・データ・ネットワーク(PDN)を備えている。
【0029】
UE106は、LTE通信ネットワーク102によって提供されるサービス・カバレッジ・エリア(例えば、eノードBによってサービスされるセル)を動き回るので、UE106は、信号品質についての様々な測定を行い、または実行する。それらの測定は、1つまたは複数の周波数内測定と、周波数間測定と、無線アクセス技術間(RAT間(inter−RAT:inter−radio access technology))測定とを含むことができる。ハンドオーバに関連する信号品質における変化など、所定の条件が満たされているときに、UEは、そのUEが現在接続されているセルを管理するソースeノードBに対して測定報告を送信する。測定報告の例は、3GPP TS 36.331において説明されるように、イベントA1と、A2と、A3と、A4と、A5と、B1と、B2とを含む。
【0030】
測定報告の受信のすぐ後に、ソースeノードBは、ターゲット・セルとのハンドオーバを実行すべきかどうかを決定することができる。ターゲット・セルは、同じ周波数(周波数内ハンドオーバ)、異なる周波数(周波数間ハンドオーバ)、または異なる無線アクセス技術(RAT、RAT間ハンドオーバ)を使用することができる。ターゲット・セルは、外部ネットワーク104の内部のソースeノードB、別のターゲットeノードB、または基地局(例えば、ワイヤレス・ローカル・エリア・ネットワーク・アクセス・ポイント、GPRS基地局、UMTS基地局など)によってサービスされる可能性がある。
【0031】
図2を参照すると、論理フロー200は、ソースeノードB、例えば、eノードB110によって実行されるステップを示しており、ここで、測定報告は、イベントA3報告などの周波数内ハンドオーバ測定報告である。報告の受信(ステップ202)のすぐ後に、eノードB110は、UE106が休眠状態にあるかどうかを判定する(ステップ204)。一例において、eノードB110は、UE106が、非アクティビティ時間など、所定の長さの時間内にユーザ・データを転送していない場合に、UE106が休眠状態にあると考える。一例における非アクティビティ時間は、ユーザ・プレーン・データを送信するとすぐに、または受信するとすぐに、リセットされる。一例におけるユーザ・プレーン・データは、トラフィック無線ベアラ(TRB:traffic radio bearers)上で搬送されるユーザ・プレーン・トラフィックであり、このユーザ・プレーン・トラフィックは、信号無線ベアラ(SRB:signaling radio bearer)上で搬送される信号トラフィック(例えば、測定報告)とは異なる。ユーザ・プレーン・データは、アップリンク(UL)ユーザ・プレーン・トラフィック、またはダウンリンク(DL)ユーザ・プレーン・トラフィックを含んでいる。ユーザ・アクティビティの存在と、非アクティビティ・タイマーをリセットすべきかどうかとを決定するための他の判断基準は、当業者には明らかであろう。
【0032】
UE106が休眠状態にない場合、eノードB110は、例えば、ハンドオーバ要求をeノードB108に対して送信することにより、ハンドオーバをトリガする(ステップ206)。UE106が現在休眠状態にある場合、eノードB110は、UE106(またはそれを使用する加入者)が、「優先ユーザ」であるかどうかについての判定(ステップ205)を行う。優先ユーザの例は、緊急サービスまたはネットワーク・オペレータ(3GPP TS 22.011 セクション4に説明されるような)や高いサービス品質(QoS)レベルを有する加入者など、特定のアクセス・クラスを有するこれらのユーザを含む。優先ユーザを決定するための追加の例またはファクタは、当業者には明らかであろう。UE106が優先ユーザである場合、eノードB110は、ハンドオーバ(ステップ206)をトリガする。
【0033】
UE106が、優先ユーザでない場合、eノードB110は、その負荷レベルを所定の負荷しきい値、または容量しきい値と比較する(ステップ208)。負荷レベルは、当業者には理解されるように、プロセッサ利用、メモリ使用、無線リソース割付け、他など、1つまたは複数のファクタに基づいたものとすることができる。しきい値についての値は、当業者には理解されように、その定格容量、または何らかの他の動作ポイントの近くにeノードBを保持するために、サービス・プロバイダによって提供されることもある。
【0034】
eノードB110の負荷が負荷しきい値より上にある(例えば、過負荷であり、または容量いっぱいである)場合、第1の例におけるeノードB110は、報告を無視する(ステップ210)または破棄する。別の例においては、eノードB110は、ステップ210においてUE106を解放する。上記で説明されるように、UE106は、良好なカバレッジ・エリアへと戻る動きのために、信号品質における改善を見ることができる。一例におけるeノードB110は、最終的にUE106を解放する前に、所定の数の報告(例えば、3つの報告)を無視するように構成されている。所定の数の報告は、ネットワーク状態または他のファクタに基づいて、サービス・プロバイダによって供給される、または動的に判定される可能性がある。
【0035】
ソースeノードB110が過負荷にされていない場合、eノードB110は、オプションとして、ターゲット・セルが過負荷にされているかどうかについての判定(ステップ212)を行うことができる。ステップ212は、ターゲット・セル情報が使用可能でない可能性があり、ここでは、ターゲット・セルは、異なるベンダーによって製造されるeノードBによってサービスされ、異なる規格に準拠するか、または異なるサービス・プロバイダによって動作させられるので、オプションである。ターゲット・セルが、eノードB108によって管理される場合の一例においては、eノードB108および110は、X2インターフェース上で通信して、ターゲット・セル負荷を提供する。別の例においては、eノードB110は、当業者には理解されるように、eノードB108についての過負荷フラグまたは変数をチェックして、その負荷ステータスを決定する。ターゲットeノードB108が過負荷である場合、eノードB110は、上記で説明されるようにステップ210へと進むことができる。ソース・セルと、ターゲット・セルとは、判定のために、同じ負荷しきい値と比較される、または別個のしきい値と比較されることもある。eノードB110はまた、最初のターゲットが過負荷状態にある場合に、いくつかの可能性のあるターゲット・セルを監視し、また代替案を選択することができる。一例においては、第1のeノードBが過負荷である、またはハンドオーバを拒絶する場合に、ステップ212において、UE106からの測定報告は、eノードB110によるハンドオーバ考察のための追加のターゲット・セルを含んでいる。
【0036】
ソース・セルとターゲット・セルとが休眠状態にあるUE106に対して十分な容量を有する場合、そのときにはeノードB110は、1つまたは複数の解放ファクタを評価して(ステップ214)、ハンドオーバをトリガすべきかどうかを決定する(ステップ216)、またはUE106を解放する(ステップ218)。解放ファクタの例は、UE106についてのハンドオーバ・レートと、非アクティビティ時間とを含む。例えば、UE106が休眠状態にある間にかなりの数のハンドオーバを実行しており、かつ/または所定の非アクティビティ時間(例えば、3秒、10秒など)内にどのようなデータも送信していないか、または受信していない場合に、eノードB110は、UE106を解放することができる(ステップ218)。追加の解放ファクタと、それらのそれぞれのしきい値とは、サービス・プロバイダによって供給され、またeノードB110によって考慮されることもある。さらなる一例においては、しきい値は、ネットワーク状態、ユーザ・プロファイル、UEのタイプ(例えば、タブレットもしくは電話)、または他のファクタに基づいて、動的に決定されることもある。ハンドオーバが実行されるときに、eノードB110は、ハンドオーバ・メッセージをターゲットeノードBに対して送信し、またUE106のハンドオーバ周波数または履歴についてのパラメータまたは変数を含んでいる。
【0037】
LTE内ハンドオーバ中に、ソース・セルは、ターゲット・セルに対するハンドオーバ・メッセージの中にUE情報を含める。既に3GPP規格は、UE情報が、ソース・セルによって測定されるUEの非アクティビティ時間を含むことを可能にしている。ソース・セルは、ターゲット・セルが過負荷状態にあるかどうかを範囲亭することができない場合に、ハンドオーバを試みることができる。ターゲット・セルが過負荷状態にある場合、ターゲット・セルは、ソース・セルからのUEの非アクティビティ時間情報を使用して、着信HO要求が取り扱われるべきか、または拒絶されるべきかを決定することができる。例えば、UEが、最後の3秒以上にわたってソース・セルにおいて休眠状態、またはアイドル状態にあった場合に、ターゲット・セルは、ターゲット・セルが既に過負荷状態にある場合に、着信HO要求を拒絶することを決定することができる。これは、ハンドオーバについての代替的なターゲット・セルを選択するように、ソース・セルをトリガする助けを行う。UEの休眠状態またはアイドル状態が3秒よりも短い場合に、ターゲット・セルは、着信HOを受け入れることができる。
【0038】
図3を参照すると、論理フロー300は、周波数間ハンドオーバ測定報告の受信のすぐ後に、eノードB110によって実行されるステップを示すものである。一例においては、eノードB110は、UE106からイベントA2「カバレッジ・アラーム」報告を受信し、このイベントA2「カバレッジ・アラーム」報告は、絶対しきい値よりも悪いが、依然として許容限度内にある信号品質を示すように構成されている。別の例においては、eノードB110は、UE106からイベントA2「フロア」報告を受信し、このイベントA2「フロア」報告は、絶対しきい値(すなわち、信号フロア)よりも悪く、もはやサービスのために十分でない信号品質を示すように構成されている。報告の受信(ステップ302)のすぐ後に、eノードB110は、UE106が休眠状態にあるかどうかを判定する(ステップ304)。UE106が休眠状態にない場合に、eノードB110は、イベントA3報告および/またはイベントA5報告など、1つまたは複数の追加の報告について、UE106を構成する(ステップ306)。
【0039】
UE106が休眠状態にある場合、eノードB110は、
図2のステップ208と同様に、ソース・セルの負荷がしきい値より上にあるかどうかを判定する(ステップ308)。ソース・セルが十分な負荷容量を有している場合、eノードB110は、UE106についての追加のイベントまたはメッセージを構成する(ステップ306)。ソース・セルが過負荷にある場合、eノードB110は、
図2のステップ210と同様に、「カバレッジ・アラーム」報告を無視し(ステップ310)、また「フロア」報告のためにUE106を解放する。しかしながら、この例においては、eノードB110が解放を実行する場合、eノードB110は、当業者には理解されるように、ターゲット・セルに向かうリダイレクションとともに解放を実行する。
【0040】
図4を参照すると、また
図2および3を参照すると、論理フロー400は、周波数間測定報告の、例えば、ステップ306において構成されるイベントA3報告および/またはイベントA5報告の受信のすぐ後に、eノードB110によって実行されるステップを示している。ステップ402において、eノードB110は、A3報告またはA5報告を受信する。ステップ404と、405と、406と、408と、412と、414と、416とは、
図2におけるそれらそれぞれの対応するステップに類似している。ステップ410と、418とは、310と、318とに類似しているが、eノードB110が解放を実行する場合、eノードB110は、当業者には理解されるように、ターゲット・セルに向かうリダイレクションとともに解放を実行する。
【0041】
図5を参照すると、また
図3を参照すると、論理フロー500は、RAT間測定報告の受信のすぐ後に、eノードB110によって実行されるステップを示している。RAT間測定報告は、UE106が外部ネットワーク104のカバレッジ範囲内に来るときに受信されることもあり、またしたがって、LTEからCDMA、LTEからUMTS、LTEからGSM、またはLTEから別のワイヤレス・ネットワークへのハンドオーバが起こる可能性がある。一般に、RAT間ハンドオーバが、2Gワイヤレス・ネットワーク、または3Gワイヤレス・ネットワークに隣接したLTE通信ネットワーク102の境界領域の近くで起こることになる。
【0042】
一例においては、eノードB110は、UE106からイベントA2「カバレッジ・アラーム」報告を受信する(ステップ502)。ステップ504と、508と、510とは、
図3におけるそれらそれぞれの対応するステップに類似している。ステップ506は、ステップ306に類似しているが、eノードB110は、当業者には理解されるように、イベントA3またはA5の代わりに、イベントB2を構成する。
【0043】
図6を参照すると、論理フロー600は、ステップ506において構成されるイベントB2報告の受信のすぐ後に、eノードB110によって実行されるステップを示している。ステップ604と、605と、606と、608と、610と、616とは、
図4におけるそれらそれぞれの対応するステップに類似している。この例においては、eノードB110は、外部ネットワーク104の中にあるので、ターゲット負荷についての情報を有しておらず、したがって、ターゲット・セル負荷の決定は省略される。
【0044】
図7を参照すると、論理フロー700は、eノードB110からのハンドオーバのためのターゲットeノードB、例えば、eノードB108によって実行されるステップを示している。ステップ702において、eノードB108は、ソースeノードB110からハンドオーバ要求を受信する。eノードB108は、ステップ205において上記で説明されるように、UE106が優先ユーザであるかどうかを判定する(ステップ705)。UE106が優先ユーザである場合、eノードB108は、ハンドオーバ要求を処理する(ステップ706)。
【0045】
次いで、eノードB108は、所定の負荷しきい値とそれ自体の負荷レベルを比較する(ステップ708)。負荷レベルは、ステップ208を参照して、上記で説明される1つまたは複数のファクタに基づいたものとすることができる。過負荷でない場合、eノードB108は、ハンドオーバを処理する(ステップ706)。eノードB108が過負荷状態にある場合には、eノードB108は、例えば、3秒から10秒の間の所定の非アクティビティしきい値とUE106の非アクティビティ時間を比較する(ステップ710)。非アクティビティ時間は、当業者には理解されるように、ハンドオーバ要求とともに受信される。所定のしきい値は、E−UTRANについては一般に、または各eノードBに特有に、サービス・プロバイダによって供給されることもある。さらに、所定のしきい値は、負荷状態に基づいて動的に決定されることもある。UE106の非アクティビティ時間がしきい値よりも長い場合、eノードB108は、ハンドオーバを拒絶する(ステップ712)。非アクティビティ時間がしきい値よりも短い場合に、eノードB108は、ハンドオーバを処理する(ステップ706)。
【0046】
図8を参照すると、一例におけるソースeノードBは、論理フロー800を実行して、所定の非アクティビティ時間の後に、UEをアイドル状態に置く代わりに、接続されたUEを接続された状態に保持する。上記で説明されるように、これは、アイドル状態と、接続された状態との間でUEを遷移する信号オーバーヘッドを低減させることができる。一例における論理フロー800は、UEからの接続要求を受信するとすぐに、ソースeノードBによって実行される。例えば、UE106は、切り離された状態にある間に、eノードB110に対してRRC要求を送信して、データ伝送のためのリソースを取得する。代わりに、eノードBは、タイマーの時間切れ、または過負荷イベントの発生など、別のトリガのすぐ後に、論理フロー800を実行することもできる。
【0047】
トリガ(ステップ802)のすぐ後に、一例におけるeノードB110は、上記で説明されるように、所定のしきい値とその現在の負荷を比較する(ステップ804)。eノードB110が、過負荷状態にある場合、eノードB110は、1つまたは複数の休眠状態にあるUEを解放する(ステップ806)。eノードBは、それらeノードBの優先順位ステータス、非アクティビティ時間、または他のファクタに基づいて解放のためのUEを選択することができる。例えば、一例におけるeノードB110は、優先ユーザを解放することはなく、また30秒以上にわたって非アクティブであったこれらのUEだけを解放する。
【0048】
eノードB110が過負荷状態にない場合、eノードB110は、所定の接続されたユーザしきい値(RRC_CONNECTED)と現在接続されているUEの数を比較する(ステップ808)。接続されたユーザしきい値が、例えば、接続されたUEの最大数に到達している場合、eノードB110は、休眠状態にあるUEを解放することができる(ステップ806)。最大数に到達していない場合、一例におけるeノードB110は、1つまたは複数の接続されたUEの非アクティビティ時間を増大させる(ステップ810)。
【0049】
一例におけるeノードB110は、UEのデバイス・タイプ、UEについてのユーザ優先順位、UEのRF信号強度、ハンドオーバ周波数/履歴などのファクタに基づいて、増大された非アクティビティ時間を受信することになるUEを選択する。追加のファクタが、当業者にとっては明らかであろう。例えば、eノードB110は、十分に高いRF信号と、しきい値よりも低い最近のハンドオーバの数とを有するこれらのUEだけを選択することができる。
【0050】
増大された非アクティビティ・タイマーを受信するこれらの選択されたUEでは、一例におけるeノードB110は、増大された非アクティビティ時間を選択する。例えば、デフォルトの非アクティビティ時間が10秒である場合、この10秒の後に、UEは、通常、アイドル状態へと遷移されることになり、eノードB110は、30秒、数分、またはより長い値へと非アクティビティ時間を増大させることができる。さらにある一例においては、eノードB110は、上記で説明されるように、デバイス・タイプ、ネットワーク負荷、ユーザ優先順位など、1つまたは複数のファクタに基づいて、新しい非アクティビティ時間を動的に選択する。非アクティビティ時間は、個々のUE、若しくはUEのグループのために選択され、又は、カバレッジ・エリアにおけるすべてのUEに適用されることもある。
【0051】
フィールドの観察(3Gおよび4G)に基づいて、ハンドオーバ・イベントの大部分は、約10%のユーザによってトリガされる。これらのユーザは、一般的に、セル・カバレッジ・エリアの境界にあり、それゆえに重要なことは、これらのハンドオーバ・イベントを適切に管理することである。接続されたユーザの約85%が、最小限の信号トラフィック(例えば、1〜2のSR/S1解放、1〜2のHOおよび定期的TAU)を生成することになることが、推定される。接続されたユーザの残りの15%だけが、アイドル状態から接続された状態への遷移についての現在の平均信号負荷を生成し、またHO低減のための提案された方法を用いて、現在の(またはより低い)平均レート(例えば、時間当たりのアタッチUEに対して、15よりも少ないハンドオーバ)へとHOレートを低減させることになる。
【0052】
一例における装置100は、1つまたは複数の電子コンポーネント、ハードウェア・コンポーネント、コンピュータ・ソフトウェア・コンポーネントなど、複数のコンポーネントを備える。いくつかのそのようなコンポーネントは、装置100において、結合され、または分割される可能性がある。本装置100の例示のコンポーネントは、当業者には理解されるように、いくつかのプログラミング言語のうちのどれかを用いて書かれる、あるいは実施されるコンピュータ命令の組および/またはシリーズを使用し、かつ/または含んでいる。
【0053】
一例における装置100は、1つまたは複数のコンピュータ読取り可能非一時的媒体を使用する。コンピュータ読取り可能非一時的媒体は、本発明の1つまたは複数の実装形態の1つまたは複数の部分を実行するためのソフトウェア、ファームウェア、および/またはアセンブリ言語を記憶する。本装置100についてのコンピュータ読取り可能非一時的媒体の例は、eノードB108および110の記録可能データ・ストレージ媒体118を備える。一例における本装置100についてのコンピュータ読取り可能非一時的媒体は、1つまたは複数の磁気的データ・ストレージ媒体と、電気的データ・ストレージ媒体と、光学的データ・ストレージ媒体と、生物学的データ・ストレージ媒体と、アトミック・データ・ストレージ媒体とを備える。例えば、コンピュータ読取り可能非一時的媒体は、フロッピー・ディスクと、磁気テープと、CD−ROMと、DVD−ROMと、ハード・ディスク・ドライブと、電子的メモリとを備える。
【0054】
本明細書において説明されるステップまたはオペレーションは、ただ例のためにすぎない。本発明の精神を逸脱することなく、これらのステップまたはオペレーションに対する多数の変形形態が存在する可能性がある。例えば、それらのステップは、異なる順序で実行されることもあり、あるいはステップが、追加され、削除され、または修正されてもよい。
【0055】
本発明の例示の実装形態は、本明細書において詳細に示され、また説明されてきているが、当業者にとっては、様々な修正形態と、追加形態と、置換形態などとが、本発明の精神を逸脱することなく作ることができ、またこれらは、それゆえに、添付の特許請求の範囲において規定されるように、本発明の範囲内にあるように考えられることが、明らかであろう。