特許 5722410 輻輳制御のためのＩｕｒでのＲＲＭ最適化

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5722410

(24)【登録日】2015年4月3日

(45)【発行日】2015年5月20日

(54)【発明の名称】輻輳制御のためのＩｕｒでのＲＲＭ最適化

(51)【国際特許分類】

   H04W 28/12 20090101AFI20150430BHJP

   H04W 28/08 20090101ALI20150430BHJP

   H04W 92/22 20090101ALI20150430BHJP

【ＦＩ】

   H04W28/12

   H04W28/08

   H04W92/22

【請求項の数】2

【全頁数】8

(21)【出願番号】特願2013-220410(P2013-220410)

(22)【出願日】2013年10月23日

(62)【分割の表示】特願2011-13(P2011-13)の分割

【原出願日】2002年4月19日

(65)【公開番号】特開2014-60740(P2014-60740A)

(43)【公開日】2014年4月3日

【審査請求日】2013年11月18日

(31)【優先権主張番号】09/859,671

(32)【優先日】2001年5月17日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】512242963

【氏名又は名称】コア ワイヤレス ライセンシング エス．アー．エール．エル．

(74)【代理人】

【識別番号】100199277

【弁理士】

【氏名又は名称】西守 有人

(74)【代理人】

【識別番号】100153811

【弁理士】

【氏名又は名称】青山 高弘

(72)【発明者】

【氏名】ホワン、ウォーンヘー

(72)【発明者】

【氏名】ワールクヴィスト、マティアス

【審査官】 田部井 和彦

(56)【参考文献】

【文献】 国際公開第００／００８８８４（ＷＯ，Ａ１）

【文献】 国際公開第９９／０４５７３５（ＷＯ，Ａ１）

【文献】 国際公開第０１／０２０９３７（ＷＯ，Ａ１）

【文献】 特開平１０−１９１４３９（ＪＰ，Ａ）

【文献】 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iur Interface RNSAP Signalling (Release 4)，3GPP TS 25.423 ，２００１年 ３月，V4.0.0 (2001-03)，8.5.3 Common Measurement Reporting, 9.2.1.33A Load Value

【文献】 Ericsson-Motorola，Introduction of Rate Control on DCHs，3GPP TSG-RAN WG3 Meeting #19，２００１年 ２月２６日，R3-011063，p.31

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４− ７／２６

Ｈ０４Ｗ ４／００−９９／００

(57)【特許請求の範囲】

【請求項1】

第１の標準インターフェースによって無線アクセスネットワークに接続され、第２の標準インターフェースによって第２の無線ネットワークコントローラに接続される第１の無線ネットワークコントローラであって、
前記第１の無線ネットワークコントローラが、
過負荷状態の存在を判断する手段と、
前記第２の無線ネットワークコントローラに、前記第２の標準インターフェースを通じて、負荷値と前記過負荷状態を緩和するための動作案と無線ベアラの許可限界を示すプライオリティとを使用して、前記過負荷状態が存在することをシグナリングする手段とを備えており、
前記動作案がデータの流れを制限するためのものである、
第１の無線ネットワークコントローラ。

【請求項2】

無線アクセスネットワークの第１の無線ネットワークコントローラに過負荷状態が存在することを前記第１の無線ネットワークコントローラで判断すること、
前記第１の無線ネットワークコントローラで、前記無線アクセスネットワークの第２の無線ネットワークコントローラに、負荷値と前記過負荷状態を緩和するための動作案と無線ベアラの許可限界を示すプライオリティとを使用して、前記過負荷状態が存在することをシグナリングすることを含み、
前記動作案がデータの流れを制限するためのものである方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、第１の無線ネットワークコントローラ及び第１の無線ネットワークコントローラ内で行なわれた測定の、第２の無線ネットワークコントローラへのシグナリングにかかわり、より詳細には、該シグナリングの解釈に関する問題にかかわる。

【背景技術】

【0002】

ユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）のリリース４（第４版）の提案（２００１年２月２３日−３月２日にウェールズのカーディフで開催された３ＧＰＰ ＴＳＧ−ＲＡＮ第１９回ミーティングのＣｈａｎｇｅ Ｒｅｑｕｅｓｔ ＣＲ３２３ 〜 ２５．４２３バージョン３．４．０を参照）として、ソースコントローラは、Ｉｕｒで共通測定報告とともに負荷情報を報告できる（ＣＲ３２３、８．５．ｘ．章、“共通測定報告（Common Measurement Reporting）”、６０−６１ページを参照）。該負荷情報は、アップリンクおよびダウンリンクに関してジェネリック値（０...９）を有する（ＣＲ３２３、１２３ページの表９．２．１．ｘ．を参照）。この値は、たとえば、１＝負荷１０％、４＝負荷４０％を意味する。提案された仕様変更要請では、このジェネリック負荷値は定義されておらず、また受信側が受信した値に関して取るべき特定の動作についても定義されていない。該ジェネリック値を受信するコントローラは、メーカーごとに様々な方法でこの情報を解釈することができる。たとえば、４０％という値は、あるコントローラにとっては輻輳を意味するものであっても、接続されている他のベンダーのコントローラにとっては輻輳とはみなされないこともある。さらに、ジェネリック値は発生している輻輳の種類を報告することはできない。輻輳が、妨害なのか、トランスポートの過負荷なのか、または処理の過負荷なのかがわかれば、受信側のコントローラはこの輻輳状態を解決するために何をすべきか、より適切に判断することができ、有益であろう。しかし、複数のベンダーが存在する環境では、ベンダーは各々異なる方法で値を定義することができ、各コントローラは異なる方法で値を分析することができる。これは、同一のベンダーが製造したコントローラ間で通信を行なう場合には問題ないが、複数のベンダーが存在する環境においては適切に機能しない。

【発明の概要】

【発明が解決しようとする課題】

【0003】

以上のことから、前述した従来技術においては、コントローラ間で転送されるジェネリック負荷値があることが理解されるであろう。ベンダーに関わらず、受信側がこの値をどう解釈すべきかについての一般的な解決策はない。

【課題を解決するための手段】

【0004】

本発明の目的は、輻輳状態にある第１の無線ネットワークコントローラからの報告を、第２のコントローラが解釈できるシグナリングを行う第１の無線ネットワークコントローラを提供し、それにより第２の無線ネットワークコントローラが輻輳を緩和する立場に立てるようにすることである。

【0005】

本発明の第１および第２の態様によれば、過負荷状態が存在する旨を判断し、過負荷状態が存在する旨と該過負荷状態を緩和するための動作案とを第２のコントローラにシグナリングするための第１の無線ネットワークコントローラおよび方法が提供される。シグナリングは、同一のメッセージで行なっても、別のメッセージで行なってもよい。前記動作案としては、データの流れの制限、周波数間ハンドオーバの実行、システム間ハンドオーバの実行、１つまたは複数の無線ベアラの解放などがあるが、本発明ではデータの流れの制限としている。

【0006】

さらに、本発明によれば、第２のコントローラは第１のコントローラからのシグナリングを受信し、過負荷状態を緩和するための動作案を実行することができる。該過負荷の緩和は、前述した、データの流れの制限、周波数間もしくはシステム間でのハンドオーバ、または１つもしくは複数の無線ベアラの解放など、様々な方法で実行することができるが、本発明ではデータの流れの制限である。

【0007】

本発明では、ジェネリック「負荷」値（現行の解決策）に加えて、第１のコントローラ（測定を行なうコントローラ）が第２のコントローラ（動作案を受信するコントローラ）に所望の反応を提案するための、追加のパラメータが加えられる。第２のコントローラは動作案を受信することにより、とくに複数のベンダーが存在する環境において、第１のコントローラ内の輻輳状態を解決するための適切な応答動作を取ることができる。

【0008】

本発明は、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）のユニバーサル地上無線アクセスネットワーク（ＵＴＲＡＮ）において用いることができる。さらに、たとえば３ＧＰＰ無線ネットワークコントローラ間（ＲＮＣ−ＲＮＣ）インタフェース（Ｉｕｒインタフェースと称される）などのコントローラ間インタフェースを有するあらゆる通信システムに適用することも可能である。これ以外には、輻輳状態を解決するために一方のコントローラが他方のコントローラに動作案を提供することができる、基地局（base station）コントローラ間（ＢＳＣ−ＢＳＣ）インタフェース、基地局（base transceiver station）間（ＢＴＳ−ＢＴＳ）インタフェースなどがある。

【0009】

本発明における、これらのおよび他の目的、特徴および利点は、添付の図面を参照して以下に述べる最良の実施の形態の詳細な説明によって、さらに明確になるであろう。

【発明の効果】

【0010】

本発明によれば、第１のコントローラ内における輻輳状態に関する該第１の無線ネットワークコントローラからの報告を、第２のコントローラが解釈するための方法を提供し、それにより第２の無線ネットワークコントローラが輻輳を緩和できる。

【図面の簡単な説明】

【0011】

【図1】知られている３ＧＰＰアーキテクチャを示す図である。

【図2】図１のＵＴＲＡＮの詳細を示す図である。

【図3】従来技術の提案による、ＲＮＣ間の測定報告またはジェネリック負荷測定を示す図である。

【図4】従来技術の提案による、Ｉｕｒインタフェースで報告されるジェネリック負荷測定を示す図である。

【図5】複数のベンダーが存在する環境では図３および図４の従来技術の提案が困難であることを示す図である。

【図6】ベンダーＸの第１のＲＮＣからベンダーＹの第２のＲＮＣへのジェネリック負荷報告に加えて輻輳を緩和するための動作案を提案する、本発明のプロシージャの例を示す図である。

【図7】本発明にかかわる、複数のベンダーが存在する環境で第１のコントローラから第２のコントローラへ報告される是正動作案の第２の例を示す図である。

【図8】本発明を実行する手段の例の詳細を示す図である。

【発明を実施するための形態】

【0012】

図１は、コアネットワーク（ＣＮ）１２がＩｕインタフェースを介してＵＴＲＡＮ１４に接続された、知られている３ＧＰＰアーキテクチャ１０を示す。ＵＴＲＡＮ１４は、無線インタフェースであるＵｕインタフェースを介してユーザ装置（ＵＥ）１６に接続される。図２は、ＣＮ１２に接続された、１組の無線ネットワークサーバ（ＲＮＳ）１８、２０を備えたＵＴＲＡＮの詳細を示す。各ＲＮＳ内には、無線ネットワークコントローラ（ＲＮＣ）２２、２４がある。各ＲＮＣは、複数のノードＢ２６、２８、３０、３２に、対応するＩｕｂインタフェースを介して接続される。ノードＢは、移動体通信のためのグローバルシステム（global system for mobile communications − ＧＳＭ（登録商標））の基地局（base transceiver station）に相当する。ＧＳＭ（登録商標）とは異なり、ＵＴＲＡＮのＲＮＣ間はＩｕｒを介して接続されるという利点がある。これは、新たなＵＭＴＳ内には、データが複数のノードＢを介してＵＥへ送信されるマクロダイバーシティ機能（macrodiversity function）が導入されているからである。信号は、同一ＵＥと幾つかのＲＮＣとのあいだで複数の無線インタフェースを介して送信されるため、フェージング効果による悪影響が少なく、また使用される電力レベルも低くてすむ。３ＧＰＰ仕様書のリリース９９には、ＲＮＣによる負荷情報の共有（つまりセル間）に関して定められたサポートがなかった。しかし、大半のメーカーは、許可／輻輳制御に「ワンセル」アプローチを取っていたと思われるため、これは問題は生じなかった。

【0013】

図３に示されるように、３ＧＰＰのリリース４の作業項目「ＩｕｒでのＲＲＭ最適化（RRM Optimization on Iur）」は、この問題の解決に着手した。前述の技術仕様書ＴＳ ２５．４２３ ｖ ３．４．０に対する変更要請（change request）第３２３では、第１のＲＮＣが隣接する第２のＲＮＣに対して、Ｉｕｒを介して共通測定を報告するよう要求できる、共通の測定プロシージャが提案された。提案された共通測定プロシージャでは、（１）「負荷」、（２）「送信されたキャリアパワー」、（３）「受信された総広帯域パワー」、および（４）「ＵＬタイムスロットＩＳＣＰ」の４つの共通測定タイプが定義されている（「共通測定タイプ（Common Measurement Type）」と称される、ＣＲ３２３、１２２ページの表９．２．１．ｘを参照）。本発明は、タイプ（１）の共通測定、つまり「負荷」タイプを改善するものである。現行では、「負荷」タイプの測定報告プロシージャとしては（「負荷値（Load Value）」と称される、ＣＲ３２３、１２３ページの表９．２．１．ｘを参照）、図４に示されるように、アップリンクおよびダウンリンクの各々についてジェネリック値（０，１，...，９）が用いられている。双方向の矢印は、いずれのＲＮＣもこのプロセスを開始することができ、また開始された際には、シグナリングの双方向交換が可能であることを示している。技術仕様書ＴＳ２５．４２３ ｖ． ３．３．０（２０００−０９）の無線ネットワークサブシステム・アプリケーション・パート（ＲＮＳＡＰ）に関する「基本プロシージャ（Elementary Procedures）」の定義を参照されたい。ジェネリック値は、たとえば、１＝負荷１０％、４＝負荷４０％、などを意味することができる。しかし、図５に示されるように、ジェネリック値はその中でまたはそれ自体で、その輻輳が、たとえば、妨害なのか、トランスポートの過負荷なのか、または処理の過負荷なのかを正確に報告することができないため、隣接する第２のＲＮＣは該輻輳状態を解決するために何をすべきかを決定することができない。その意味を理解するための１つの方法として、既定のベンダーに内部的に意味を決定してもらい、各値を特定のタイプにマップするためのマッピング・ルールを定めてもらう方法がある。しかし、複数のベンダーが存在する環境では、ベンダーごとに異なる方法で値を定義できるため、各ＲＮＣは異なる方法で値を分析することができる。これは、複数のベンダーが存在する環境では、この提案が機能しないことを意味する。たとえば、図５に示されるように、ベンダーＸのＲＮＣによって負荷４０％と報告されても、受信側であるベンダーＹのＲＮＣは、これをどのように解釈すればよいのかわからず、したがって何をすればよいのかわからない。４０パーセントという値は、ベンダーＸのＲＮＣにとっては高負荷を意味するかもしれないが、同時に、ベンダーＹのＲＮＣにとっては正常負荷を意味するかもしれない。この場合、受信側であるベンダーＹのＲＮＣは、ベンダーＸのＲＮＣからシグナリングされた輻輳の「過負荷」問題を緩和するための動作を行なわないであろう。なぜなら、これはジェネリック値として報告されたものであり、誰もが、各々の値が各自の目的において何を意味するのかを自由に定義できるからである。仕様書では、何が輻輳を緩和するための適切な動作かについては述べられていない。このジェネリック負荷パラメータに何らかの意味をもたせることにおいて、問題となるのは、既に提案されているパラメータの変更が困難である点である。

【0014】

本発明によれば、第１のＲＮＣソースが受信側である第２のＲＮＣのための可能な応答を提案できる追加情報エレメント（ＩＥ）が提供される。該ＩＥは、ジェネリック負荷パラメータと並行して、意味をシグナリングするフラッグとして用いることができる。ＩＥは、たとえばつぎのような値を取ることができる。

【0015】

・無負荷
・負荷はあるが問題ない
・過負荷、ＲＡＢの許可限界はプライオリティ＜Ｘ
・過負荷、ＲＡＢの許可限界はプライオリティ＜Ｘ、かつ
提案する輻輳対応策は
・データの流れの制限
・周波数間ハンドオーバ
・システム間ハンドオーバ
・無線ベアラの解放、など。

【0016】

受信側である第２のＲＮＣは、輻輳状態を緩和するためにこの情報を検討することができる。受信側のＲＮＣが第１の（ソース）ＲＮＣに返信するようにしてもよい。これは当然、可能性のすべてではなく、さらに多くの緩和策を加えてもよい。動作案の実行に時間的要素を加えてもよい。

【0017】

図６は、ベンダーＸのＲＮＣがベンダーＹのＲＮＣに高負荷状態のシグナリングを行ない、プライオリティが４より高い新たな無線ベアラは許可しない例を示している。ここで、プライオリティは数字が小さいほど高く、つまり１が最もプライオリティが高い。どのような行動を取るかは受信側のＲＮＣに委ねられている。

【0018】

図７は、ベンダーＸのＲＮＣが、非常に負荷の高い状態のシグナリングを輻輳対策の提案と併せて行なう、もう１つの例を示している。ＸのＲＮＣはＹのＲＮＣに対してプライオリティが２より高い新たな無線ベアラは認めない旨をシグナリングする。また、ＸのＲＮＣはＹのＲＮＣに、無線ベアラＡおよびＢをハンドオーバするよう提案する。

【0019】

図８は、本発明にかかわる改善されたシグナリングを実行する手段を含む、第１のＲＮＣの例を示している。第１の（ソース）ＲＮＣ２２ａは、高負荷状態の存在を判断し、該高負荷状態の存在をライン８２でシグナリングするための手段８０を備える。また、Ｉｕｒインタフェースのライン８６で、第２の（受信側）ＲＮＣ２４ａに該負荷を従来技術によるジェネリック負荷値ＩＥでシグナリングするための、手段８４を備える。本発明によれば、手段８４はまた、ライン８８で手段９０にシグナリングする。手段９０は、動作案を決定し、新たなＩＥ内のライン９２でこれを第２のＲＮＣ２４ａにシグナリングする。前述したように、このようなＩＥには、（１）データの流れの制限、（２）周波数間ハンドオーバ、（３）システム間ハンドオーバ、または（４）無線ベアラの解放の輻輳対策案を含むことができる。また、手段８０は、負荷の性質を判断し該情報をライン８２、８８で手段９０に伝送する手段を含むことができる。一方、この情報は、ライン９２で第２のＲＮＣに提供することもできる。なお、信号は、ライン８６、９２で個別に伝送される代わりに、同一のメッセージとして同一のシグナリング・ラインＩｕｒで伝送されてもよい。同様に、手段８４、９０は、双方の機能を実行する単一の手段に合成されてもよい。

【0020】

第２の（受信側）ＲＮＣ２４ａは、Ｉｕｒインタフェースでシグナリングを受信し、ライン８６で受信するジェネリック値およびライン９２で受信する対策案を伴う情報エレメントの双方を解釈するための、手段９４を備える。評価ののち、ライン９６で指示信号が手段９８に提供され、手段９８は、第２のＲＮＣが対策案の実行を決定した場合は第１のＲＮＣからＩＥ信号によって提案された動作を実行し、そうでない場合は、他の動作を実行する。図８には示されていないが、本発明にしたがって採用される基本プロシージャ（ＥＰ）が応答（成功または失敗）を伴うクラス１タイプのものである場合は通常、第２のＲＮＣから第１のＲＮＣへ応答が返信されるであろう。

【0021】

本発明は、最良の実施形態について示され、説明されたが、本発明の精神および範囲を逸脱することなく前記のおよび他の多様な変更、省略および追加を行なうことが可能であることは、当業者には理解されるであろう。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】