"第1の標準インターフェースによって無線ネットワークに接続され、第2の標準インターフェースによって第2の無線ネットワークコントローラに接続される第1の無線ネットワークコントローラであって、前記第1の無線ネットワークコントローラが、過負荷状態の存在を判断する手段と、前記第2の無線ネットワークコントローラに、前記第2の標準インターフェースによって負荷値を使用して前記過負荷状態が存在することと過負荷状態を緩和するための動作案とを前記無線アクセスネットワークの第2の無線ネットワークコントローラにシグナリングする手段とを備えており、前記動作案がデータの流れの制限である、第1の無線ネットワークコントローラ。無線アクセスネットワークの第1の無線ネットワークコントローラに過負荷状態が存在することを判断すること、前記無線アクセスネットワークの第2の無線ネットワークコントローラに、負荷値を使用して過負荷状態が存在することと過負荷状態を緩和する動作案をシグナリングすることを含み、前記動作案がデータの流れの制限である方法。以上のことから、前述した従来技術においては、コントローラ間で転送されるジェネリック負荷値があることが理解されるであろう。ベンダーに関わらず、受信側がこの値をどう解釈すべきかについての一般的な解決策はない。本発明の目的は、輻輳状態にある第1の無線ネットワークコントローラからの報告を、第2のコントローラが解釈できるシグナリングを行う第1の無線ネットワークコントローラを提供し、それにより第2の無線ネットワークコントローラが輻輳を緩和する立場に立てるようにすることである。本発明の第1および第2の態様によれば、過負荷状態が存在する旨を判断し、過負荷状態が存在する旨と該過負荷状態を緩和するための動作案とを第2のコントローラにシグナリングするための第1の無線ネットワークコントローラおよび方法が提供される。シグナリングは、同一のメッセージで行なっても、別のメッセージで行なってもよい。前記動作案としては、データの流れの制限、周波数間ハンドオーバの実行、システム間ハンドオーバの実行、1つまたは複数の無線ベアラの解放などがあるが、本発明ではデータの流れの制限としている。さらに、本発明によれば、第2のコントローラは第1のコントローラからのシグナリングを受信し、過負荷状態を緩和するための動作案を実行することができる。該過負荷の緩和は、前述した、データの流れの制限、周波数間もしくはシステム間でのハンドオーバ、または1つもしくは複数の無線ベアラの解放など、様々な方法で実行することができるが、本発明ではデータの流れの制限である。本発明では、ジェネリック負荷値現行の解決策に加えて、第1のコントローラ測定を行なうコントローラが第2のコントローラ動作案を受信するコントローラに所望の反応を提案するための、追加のパラメータが加えられる。第2のコントローラは動作案を受信することにより、とくに複数のベンダーが存在する環境において、第1のコントローラ内の輻輳状態を解決するための適切な応答動作を取ることができる。本発明は、第3世代パートナーシッププロジェクト3GPPのユニバーサル地上無線アクセスネットワークUTRANにおいて用いることができる。さらに、たとえば3GPP無線ネットワークコントローラ間RNC-RNCインタフェースIurインタフェースと称されるなどのコントローラ間インタフェースを有するあらゆる通信システムに適用することも可能である。これ以外には、輻輳状態を解決するために一方のコントローラが他方のコントローラに動作案を提供することができる、基地局basestationコントローラ間BSC-BSCインタフェース、基地局basetransceiverstation間BTS-BTSインタフェースなどがある。本発明における、これらのおよび他の目的、特徴および利点は、添付の図面を参照して以下に述べる最良の実施の形態の詳細な説明によって、さらに明確になるであろう。本発明によれば、第1のコントローラ内における輻輳状態に関する該第1の無線ネットワークコントローラからの報告を、第2のコントローラが解釈するための方法を提供し、それにより第2の無線ネットワークコントローラが輻輳を緩和できる。図1は、コアネットワークCN12がIuインタフェースを介してUTRAN14に接続された、知られている3GPPアーキテクチャ10を示す。UTRAN14は、無線インタフェースであるUuインタフェースを介してユーザ装置UE16に接続される。図2は、CN12に接続された、1組の無線ネットワークサーバRNS18、20を備えたUTRANの詳細を示す。各RNS内には、無線ネットワークコントローラRNC22、24がある。各RNCは、複数のノードB26、28、30、32に、対応するIubインタフェースを介して接続される。ノードBは、移動体通信のためのグローバルシステムglobalsystemformobilecommunications-GSMの基地局basetransceiverstationに相当する。GSMとは異なり、UTRANのRNC間はIurを介して接続されるという利点がある。これは、新たなUMTS内には、データが複数のノードBを介してUEへ送信されるマクロダイバーシティ機能macrodiversityfunctionが導入されているからである。信号は、同一UEと幾つかのRNCとのあいだで複数の無線インタフェースを介して送信されるため、フェージング効果による悪影響が少なく、また使用される電力レベルも低くてすむ。3GPP仕様書のリリース99には、RNCによる負荷情報の共有つまりセル間に関して定められたサポートがなかった。しかし、大半のメーカーは、許可/輻輳制御にワンセルアプローチを取っていたと思われるため、これは問題は生じなかった。図3に示されるように、3GPPのリリース4の作業項目IurでのRRM最適化RRMOptimizationonIurは、この問題の解決に着手した。前述の技術仕様書TS25.423v3.4.0に対する変更要請changerequest第323では、第1のRNCが隣接する第2のRNCに対して、Iurを介して共通測定を報告するよう要求できる、共通の測定プロシージャが提案された。提案された共通測定プロシージャでは、1負荷、2送信されたキャリアパワー、3受信された総広帯域パワー、および4ULタイムスロットISCPの4つの共通測定タイプが定義されている共通測定タイプCommonMeasurementTypeと称される、CR323、122ページの表9.2.1.xを参照。本発明は、タイプ1の共通測定、つまり負荷タイプを改善するものである。現行では、負荷タイプの測定報告プロシージャとしては負荷値LoadValueと称される、CR323、123ページの表9.2.1.xを参照、図4に示されるように、アップリンクおよびダウンリンクの各々についてジェネリック値0,1,,9が用いられている。双方向の矢印は、いずれのRNCもこのプロセスを開始することができ、また開始された際には、シグナリングの双方向交換が可能であることを示している。技術仕様書TS25.423v.3.3.02000-09の無線ネットワークサブシステムアプリケーションパートRNSAPに関する基本プロシージャElementaryProceduresの定義を参照されたい。ジェネリック値は、たとえば、1=負荷10、4=負荷40、などを意味することができる。しかし、図5に示されるように、ジェネリック値はその中でまたはそれ自体で、その輻輳が、たとえば、妨害なのか、トランスポートの過負荷なのか、または処理の過負荷なのかを正確に報告することができないため、隣接する第2のRNCは該輻輳状態を解決するために何をすべきかを決定することができない。その意味を理解するための1つの方法として、既定のベンダーに内部的に意味を決定してもらい、各値を特定のタイプにマップするためのマッピングルールを定めてもらう方法がある。しかし、複数のベンダーが存在する環境では、ベンダーごとに異なる方法で値を定義できるため、各RNCは異なる方法で値を分析することができる。これは、複数のベンダーが存在する環境では、この提案が機能しないことを意味する。たとえば、図5に示されるように、ベンダーXのRNCによって負荷40と報告されても、受信側であるベンダーYのRNCは、これをどのように解釈すればよいのかわからず、したがって何をすればよいのかわからない。40パーセントという値は、ベンダーXのRNCにとっては高負荷を意味するかもしれないが、同時に、ベンダーYのRNCにとっては正常負荷を意味するかもしれない。この場合、受信側であるベンダーYのRNCは、ベンダーXのRNCからシグナリングされた輻輳の過負荷問題を緩和するための動作を行なわないであろう。なぜなら、これはジェネリック値として報告されたものであり、誰もが、各々の値が各自の目的において何を意味するのかを自由に定義できるからである。仕様書では、何が輻輳を緩和するための適切な動作かについては述べられていない。このジェネリック負荷パラメータに何らかの意味をもたせることにおいて、問題となるのは、既に提案されているパラメータの変更が困難である点である。本発明によれば、第1のRNCソースが受信側である第2のRNCのための可能な応答を提案できる追加情報エレメントIEが提供される。該IEは、ジェネリック負荷パラメータと並行して、意味をシグナリングするフラッグとして用いることができる。IEは、たとえばつぎのような値を取ることができる。無負荷負荷はあるが問題ない過負荷、RABの許可限界はプライオリティ<X過負荷、RABの許可限界はプライオリティ<X、かつ提案する輻輳対応策はデータの流れの制限周波数間ハンドオーバシステム間ハンドオーバ無線ベアラの解放、など。受信側である第2のRNCは、輻輳状態を緩和するためにこの情報を検討することができる。受信側のRNCが第1のソースRNCに返信するようにしてもよい。これは当然、可能性のすべてではなく、さらに多くの緩和策を加えてもよい。動作案の実行に時間的要素を加えてもよい。図6は、ベンダーXのRNCがベンダーYのRNCに高負荷状態のシグナリングを行ない、プライオリティが4より高い新たな無線ベアラは許可しない例を示している。ここで、プライオリティは数字が小さいほど高く、つまり1が最もプライオリティが高い。どのような行動を取るかは受信側のRNCに委ねられている。図7は、ベンダーXのRNCが、非常に負荷の高い状態のシグナリングを輻輳対策の提案と併せて行なう、もう1つの例を示している。XのRNCはYのRNCに対してプライオリティが2より高い新たな無線ベアラは認めない旨をシグナリングする。また、XのRNCはYのRNCに、無線ベアラAおよびBをハンドオーバするよう提案する。図8は、本発明にかかわる改善されたシグナリングを実行する手段を含む、第1のRNCの例を示している。第1のソースRNC22aは、高負荷状態の存在を判断し、該高負荷状態の存在をライン82でシグナリングするための手段80を備える。また、Iurインタフェースのライン86で、第2の受信側RNC24aに該負荷を従来技術によるジェネリック負荷値IEでシグナリングするための、手段84を備える。本発明によれば、手段84はまた、ライン88で手段90にシグナリングする。手段90は、動作案を決定し、新たなIE内のライン92でこれを第2のRNC24aにシグナリングする。前述したように、このようなIEには、1データの流れの制限、2周波数間ハンドオーバ、3システム間ハンドオーバ、または4無線ベアラの解放の輻輳対策案を含むことができる。また、手段80は、負荷の性質を判断し該情報をライン82、88で手段90に伝送する手段を含むことができる。一方、この情報は、ライン92で第2のRNCに提供することもできる。なお、信号は、ライン86、92で個別に伝送される代わりに、同一のメッセージとして同一のシグナリングラインIurで伝送されてもよい。同様に、手段84、90は、双方の機能を実行する単一の手段に合成されてもよい。第2の受信側RNC24aは、Iurインタフェースでシグナリングを受信し、ライン86で受信するジェネリック値およびライン92で受信する対策案を伴う情報エレメントの双方を解釈するための、手段94を備える。評価ののち、ライン96で指示信号が手段98に提供され、手段98は、第2のRNCが対策案の実行を決定した場合は第1のRNCからIE信号によって提案された動作を実行し、そうでない場合は、他の動作を実行する。図8には示されていないが、本発明にしたがって採用される基本プロシージャEPが応答成功または失敗を伴うクラス1タイプのものである場合は通常、第2のRNCから第1のRNCへ応答が返信されるであろう。本発明は、最良の実施形態について示され、説明されたが、本発明の精神および範囲を逸脱することなく前記のおよび他の多様な変更、省略および追加を行なうことが可能であることは、当業者には理解されるであろう。"