(57)【要約】      （修正有）【課題】ユーザ機器によりＣ−ＲＮＣを介して少なくとも一つの個別アップリンクデータチャネルで送信されるスケジュールデータであって保証ビットレートを有するスケジュールデータに提供されるビットレートの測定を行う方法に関するものであり、さらに、一つの保証ビットレート優先度クラスのデータに対し、輻輳制御を行う方法を提供する。【解決手段】移動体通信システム内のＣ−ＲＮＣ１１０２が、保証ビットレートを有するアップリンク送信に対して輻輳制御を実行するのを可能にするために、共通測定処理または個別測定処理を用いて、保証ビットレート優先度クラスのスケジュールデータに提供されるビットレートをＣ−ＲＮＣ１１０２に与えることを提案する。与えられるビットレートは、評価され、そして、その優先度クラスのデータに対して輻輳制御を実行する必要があるか否かを判断するための基礎に取り入れられる。【選択図】図１２
2010022019.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つの端末と、コントローリング無線ネットワーク制御装置に接続された基地局と、を有する移動通信システムであって、
前記少なくとも１つの端末は、
個別アップリンクデータチャネルで、少なくとも一つの優先度クラスに対応付けられたデータを送信する送信部を具備し、
前記基地局は、
少なくとも一つの前記端末によって個別アップリンクデータチャネルで送信され、少なくとも一つの優先度クラスに対応付けられたデータのビットレートを、前記優先度クラス毎に測定する測定部と、
前記ビットレートの測定結果を、前記コントローリング無線ネットワーク制御装置に送信する送信部と、を具備し、
前記優先度クラスは、前記個別アップリンクデータチャネルにマッピングされた論理チャネルの論理チャネル優先度であり、
前記コントローリング無線ネットワーク制御装置は、
前記基地局から前記ビットレートの測定結果を受信する受信部を具備する、
移動通信システム。
【請求項２】
前記基地局の測定部は、前記ビットレートを、セル内の各端末から送信される、すべてのデータに対して共通測定する、
請求項１に記載の移動通信システム。
【請求項３】
前記端末は、ソフトハンドオーバ中である、
請求項１又は請求項２に記載の移動通信システム。
【請求項４】
前記基地局の測定部は、前記ビットレートを、セル毎に測定する、
請求項１から請求項３のいずれかに記載の移動通信システム。
【請求項５】
前記コントローリング無線ネットワーク制御装置は、更に、前記測定を開始するための測定開始要求メッセージを前記基地局へ送信し、
前記基地局は、
前記コントローリング無線ネットワーク制御装置から、前記測定を開始するための測定
開始要求メッセージを受信する受信部を、さらに具備する、
請求項１から請求項４のいずれかに記載の移動通信システム。
【請求項６】
前記基地局は、前記測定結果を、前記優先度クラスを示す優先度表示と共に送信する、
請求項１から請求項５のいずれかに記載の移動通信システム。
【請求項７】
前記個別アップリンクデータチャネルは、ＵＭＴＳシステムのＥ−ＤＣＨ（Enhanced Dedicated Uplink Channel）であり、
前記ビットレートは、各優先度クラスについて、測定期間中に基地局のＭＡＣ−ｅによって無線インターフェース上において成功したと判断された送信のＭＡＣ−ｄ  ＰＤＵ  ビットの総数を、前記測定期間の時間で割ることによって測定される、
請求項１から請求項６のいずれかに記載の移動通信システム。
【請求項８】
少なくとも１つの端末と、コントローリング無線ネットワーク制御装置に接続された基地局と、を有する移動通信システムにおける測定報告方法であって、
前記少なくとも１つの端末が、個別アップリンクデータチャネルで、少なくとも一つの優先度クラスに対応付けられたデータを送信するステップと、
前記基地局が、少なくとも一つの前記端末によって個別アップリンクデータチャネルで送信され、少なくとも一つの優先度クラスに対応付けられたデータのビットレートを、前記優先度クラス毎に測定するステップと、
前記基地局が、前記ビットレートの測定結果を、前記コントローリング無線ネットワーク制御装置に送信するステップと、
前記コントローリング無線ネットワーク制御装置が、前記基地局から前記ビットレートの測定結果を受信するステップと、を含み、
前記優先度クラスは、前記個別アップリンクデータチャネルにマッピングされた論理チャネルの論理チャネル優先度である、
測定報告方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、保証ビットレートを持ち、そして、少なくとも一つのユーザ機器によって、移動通信システムのコントローリング無線ネットワーク制御装置を介して、少なくとも一つの個別アップリンクデータチャネル上に送信されている、スケジュールデータ（スケジュールされたデータ）に提供されている提供ビットレート (provided bit−rate)についての測定を提供する方法に関するものである。さらに、本発明は、移動通信システムにおいて、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータに対して輻輳制御を開始するための方法に関するものでもある。さらにまた、本発明は、それらの方法を実行する制御無線ネットワーク制御装置、および、サービング無線ネットワーク制御装置に関するものである。
【背景技術】
【０００２】
W−CDMA（Wideband Code Division Multiple Access：広帯域符号分割多元接続方式）は、IMT−2000（International Mobile Communication：国際移動通信）のための無線インターフェイスであって、第3世代無線移動通信システムとしての使用のために標準化された。それは、柔軟かつ効率的に、音声サービスおよびマルチメディア移動通信サービスのような多様なサービスを提供する。日本、欧州、米国、および、他の国々における標準化主体は、W−CDMAのための共通の無線インターフェイス仕様を作成するために、第3世代パートナーシッププロジェクト(3GPP)と呼ばれるプロジェクトを合同で組織している。IMT−2000の標準化された欧州バージョンは、一般に、UMTS（Universal Mobile Telecommunication System：ユニバ−サル移動通信システム）と呼ばれる。UMTSの仕様の最初のリリースは、1999年に公表されている（リリース99）。一方、その標準に対する幾つかの改良が、リリース4およびリリース5において、3GPPによって標準化されており、そして、さらなる改良への議論が、リリース6の視野の下で進行中である。ダウンリンクおよびアップリンクにおけるdedicated channel（DCH：個別チャネル)、および、downlink shared channel（DSCH：ダウンリンク共有チャネル）が、リリース99およびリリース4において定義されている。
【０００３】
その後の何年かにおいて、開発者達は、マルチメディアサービス（または、一般にデータサービス）を提供するためには、高速の非対称接続を実装しなければならないことを認識した。リリース5において、high−speed downlink packet access（HSDPA：高速ダウンリンクパケット接続）が、導入された。新しいhigh−speed downlink shared channel（HS−DSCH：高速ダウンリンク共有チャネル）が、UMTS Radio Access Network（RAN：無線接続ネットワーク）から、UMTS仕様のユーザ機器と呼ばれる通信端末まで、ユーザにダウンリンク高速接続を提供する。
【０００４】
（パケットスケジューリング）
パケットスケジューリングは、共有媒体に入ることを許されたユーザに対してTXOP（transmission opportunity：送信機会）および送信フォーマットを割り当てるために用いられるRRMアルゴリズム（radio resource management algorithm：無線リソース管理アルゴリズム）である。スケジューリングは、例えば、好適なチャネル状態でユーザにTXOPを割り当てることによって、処理能力／容量を最大にするために、適応変調符号化と組み合わせてパケットベースの移動無線ネットワークに用いてもよい。UMTSにおけるパケットデータサービスは、サービスを流すために用いてもよいが、双方向トラフィッククラスおよびバックグラウンドトラフィッククラスに適用可能である。双方向クラスおよびバックグラウンドクラスに属するトラフィックは、非実時間(NRT)トラフィックとして扱われ、パケットスケジューラによって制御される。パケットスケジューリング手法は、次のように特徴づけることができる。
【０００５】
スケジューリング期間／周波数：ユーザが、あらかじめ正しいテンポでスケジュールされる期間。
【０００６】
サービング順序：ユーザがサービングする順序、例えば、ランダムな順序（ラウンドロビン）、または、チャネル品質（C/Iまたはスループットに基づく）にしたがう順序。
【０００７】
割り当て方法：リソースを割り当てるための規範、例えば、割り当て間隔当りにキューに入れられたユーザ全てに対して同一のデータ量、または、同一のパワー／コード／時間リソース。
【０００８】
アップリンクに対するパケットスケジューラが、3GPP UMTS R99/R4/R5において、無線ネットワーク制御装置(RNC)とユーザ機器との間に分配される。アップリンクにおいては、相異なるユーザによって共有されるエアインターフェイスリソースは、ノードBにおける総受信パワーであリ、したがって、スケジューラのタスクは、ユーザ機器間にパワーを割り当てることである。現在のUMTS R99/R4/R5仕様では、RNCは、各ユーザ機器に1セットの相異なる配信フォーマット（変調方式、符号化率等）を割り当てることによって、ユーザ機器がアップリンク送信の間に送信することを許容される最大レート／パワーを制御する。
【０００９】
そのようなTFCS（transport format combination set）の確立および再構成は、サービングRNC(S−RNC)とユーザ機器との間にメッセージを送る無線リソース制御(RRC)を用いて遂行してもよい。ユーザ機器は、それ自身のステータス（例えば、利用可能なパワー）およびバッファステータスに基づいて、割り当てられた配信フォーマットの組み合わせ間を自主的に選ぶことを許容される。
【００１０】
現在のUMTS R99/R4/R5仕様では、アップリンクユーザ機器送信に課される時間には、何らの制御も存在しない。スケジューラは、例えば、送信時間間隔ベースで作動してもよい。拡張されたアップリンク個別チャネル(E−DCH)に対するUMTSリリース6では、スケジューラは、レガシーチャネル（短いTTI（例えば2ミリ秒）ベースの）に対して、より高いスケジューリング周波数で作動してもよい。これは、ノイズ上昇に基づいて、ノードBによる割当てにリソースを保持しながら、端末のあるサービング順序を課す。
【００１１】
（UMTSアーキテクチャ）
ユニバ−サル移動通信システム(UMTS)のハイレベルR99/4/5アーキテクチャが、図1に示されている（非特許文献１を参照されたい)。ネットワーク要素は、機能的に、コアネットワーク(CN)101、UMTS Terrestrial Radio Access Network（UTRAN：UMTS地上無線接続ネットワーク）102、および、ユーザ機器(UE)103にグループ化される。UTRAN 102は、全ての無線関連機能(radio−related functionality)を扱う責任能力を持ち、一方、CN 101は、外部ネットワークに対する呼およびデータ接続をルートする責任能力を持つ。これらのネットワーク要素の相互接続は、オープンインターフェイス(Iu, Uu)によって定められる。UMTSシステムは、モジュール式であり、したがって、同じタイプのいくつかのネットワーク要素を持つことが可能であることに注意されたい。
【００１２】
続いて、2つの相異なるアーキテクチャを検討する。それらは、ネットワーク要素を横断する機能の論理的な分配に関して定められる。実際のネットワーク配置においては、各アーキテクチャは、2つ以上のネットワーク要素を単一の物理ノードに組み合わせることができることを意味する相異なる物理実現を持つことができる。
【００１３】
図2は、UTRANの現在のアーキテクチャを例示している。いくつかの無線ネットワーク制御装置(RNC)201, 202が、CN 101に接続されている。各RNC 201, 202は、一つまたはいくつかの基地局（ノードB）203, 204, 205, 206を制御し、それらの基地局は、次に、ユーザ機器と通信する。いくつかの基地局を制御するRNCは、これらの基地局のためのコントローリングRNC(C−RNC)と呼ばれる。それらのC−RNCに伴われた、1セットの制御された基地局は、無線ネットワークサブシステム(RNS)207, 208と呼ばれる。ユーザ機器とUTRANとの間の各接続において、一つのRNSは、サービングRNS(S−RNS)である。それは、コアネットワーク(CN)101との、いわゆるIu接続を保持する。必要なとき、図3に示されるように、ドリフトRNS(D−RNS) 302は、無線リソースを提供することによって、サービングRNS(S−RNS) 301を維持する。それぞれのRNCは、サービングRNC(S−RNC)およびドリフトRNC(D−RNC) と呼ばれる。さらに、C−RNCとD−RNCとは、同一であり、したがって、略称のS−RNCまたはRNCを用いるということは可能であり、また、しばしば、そうである。
【００１４】
（無線移動性管理）
・リリース99/4/5 UTRANにおける無線移動性管理
移動性管理に接続するいくつかの処理を説明する前に、下記において頻繁に用いられるいくつかの用語を、最初に定義する。
【００１５】
無線リンクは、単一のUEと単一のUTRAN接続点との間の論理結合として定義することができる。その物理実現は、無線ベアラ送信を有する。
【００１６】
ハンドオーバは、UEが絶えずUTRANに接続されている（ソフトハンドオーバ）ような、UE接続への／からの無線ベアラの接続または包含／除外において瞬断を伴う、一つの無線ベアラから他の一つの無線ベアラへのUE接続の切り替え（ハードハンドオーバ）として理解することができる。ソフトハンドオーバは、符号分割多元接続(CDMA)技術を採用しているネットワークに特有のものである。ハンドオーバ実行は、一例として現在のUTRANアーキテクチャを取った場合、移動無線ネットワーク内のS−RNCによって制御することができる。
【００１７】
UEに連係するアクティブセットは、UEと無線ネットワークとの間の特定の通信サービスに同時に含まれる1セットの無線リンクを有する。アクティブセット更新処理を、例えば、ソフトハンドオーバの間に、UEとUTRANとの間の通信のアクティブセットを変更するために採用することができる。その処理は、3つの機能：無線リンク追加、無線リンク除去、および、無線リンク追加と除去との組み合わせを有することができる。同時に存在する無線リンクの最大数は、8にセットされる。ひとたび、それぞれの基地局のパイロット信号強度が、アクティブセット内の最も強いメンバのパイロット信号に比して、ある閾値を越えると、新しい無線リンクが、アクティブセットに追加される。
【００１８】
ひとたび、それぞれの基地局のパイロット信号強度が、アクティブセットの最も強いメンバに比して、ある閾値を越えると、一つの無線リンクが、アクティブセットから除去される。無線リンク追加に対する閾値は、通常、無線リンク廃棄に対する閾値よりも高くなるように選ばれる。したがって、追加と除去のイベントは、パイロット信号強度に関してヒステリシスを形成する。
【００１９】
パイロット信号測定は、RRCシグナリングを用いて、UEからネットワークに（例えば、S−RNCに）報告することができる。測定結果を送る前に、あるフィルタリングが、通常、高速フェージングを平均するために実行される。通常のフィルタリング期間は、ハンドオーバ遅延に寄与する、約200 msであってもよい。測定結果に基づいて、ネットワーク（例えば、S−RNC）は、アクティブセット更新処理の機能の一つの実行（現在のアクティブセットへの／からのノードBの追加／除去）を発動することを決定することができる。
【００２０】
・E−DCHにおける無線移動性管理
UMTSのリリース6では、E−DCH送信においてソフトハンドオーバを維持することが、現在、予測されている。しかしながら、レガシーDCH（個別チャネル）とE−DCHとに対するアクティブセットは、一般に異なる。
【００２１】
（Iubインターフェイス上の共通測定および個別測定）
共通測定処理および個別測定処理は、通常、ノードB制御ポートを用いて、C−RNCから、接続しているノードBまで共通／個別測定開始メッセージを送ることによって開始される。受信すると、ノードBは、要求に与えられているパラメータにしたがって要求された測定を開始する。アドレスされたノードBは、開始要求に応答してC−RNCに共通／個別測定レポートを送る。C−RNCによって送られた要求も、アドレスノードBによって送られたレポートも、測定要求とそれに対応するレポートとの間の連結を許容するための測定IDセットを持つ測定ID IEを有する。
【００２２】
Iubインターフェイスへの共通測定処理は、ノードB内の共通リソースへの測定のために用いられる。同じように、Iubインターフェイスへの個別測定処理は、ノードB内の個別リソースへの測定のために用いられる。両タイプの処理とも、周期的、イベント発動的、および、即時的なタイプの報告をなすように構成することができる（非特許文献２を参照されたい）。
【００２３】
（拡張されたアップリンク個別チャネル(E−DCH)）
Dedicated Transport Channel（DTCH：個別配信チャネル）のアップリンク拡張が、現在、3GPP技術仕様グループRANによって調査されている（非特許文献３を参照されたい）。IPベースのサービスの使用が、ますます重要になっているから、RANの受信可能範囲および処理能力の改善、および、アップリンク個別配信チャネルの遅延の縮小に対して増大する要望がある。ストリーミングサービス、双方向サービスおよびバックグラウンドサービスは、この拡張されたアップリンクから利益を享受するかもしれない。
【００２４】
一つの拡張は、ノードB制御スケジューリングに結合して適応変調符号化方式(AMC)を使用すること、したがって、Uuインターフェイスの拡張である。既存のR99/R4/R5システムでは、アップリンク最大データレート制御は、RNCに存在する。ノードBにおいてスケジューラを再割り当てすることによって、RNCとノードBとの間のインターフェイス上のシグナリングによって導入される待ち時間が縮小され、したがって、スケジューラは、アップリンク負荷における瞬間的な変化に、より速く応答することができる。これは、RANとのユーザ機器の通信における総体的な待ち時間を縮小する。したがって、ノードB制御スケジューリングは, アップリンク負荷が減少するときに、より高いデータレートを迅速に割り当てることによって、そして、アップリンク負荷が増加するときに、アップリンクデータレートを制限することによって、アップリンク干渉をよりよく制御することができ、また、ノイズ上昇分散をよりよく平滑化することができる。受信可能範囲およびセル処理能力は、アップリンク干渉のよりよい制御によって改善される。
【００２５】
アップリンクにおける遅延を縮小すると考えられる、他の一つの技術は、他の配信チャネルに比して、E−DCHに対して、より短いTTI（Transmission Time Interval：送信時間間隔）長を導入することである。2 msの送信時間間隔長が、現在、E−DCHへの使用のために調査されており、一方、10 msの送信時間間隔が、一般に、他のチャネルに用いられている。HSDPAにおけるキー技術の一つであったハイブリッドARQも、拡張されたアップリンク個別チャネルに向けて考えられている。ノードBとユーザ機器との間のハイブリッドARQプロトコルは、誤りを伴って受信されたデータユニットの迅速な再送を可能にし、したがって、RLC（Radio Link Control：無線リンク制御）再送数、および、それに連結する遅延を縮小する。これは、エンドユーザによって経験されるサービスの品質を改善する。
【００２６】
上述の拡張を維持するために、以下においてMAC−eと呼ばれる新しいMACサブレイヤが、導入されている。この新しいサブレイヤのエンティティ（以下のセクションにおいて、より詳細に記述される）が、ユーザ機器およびノードBに置かれる。ユーザ機器サイドでは、このMAC−eは、上位レイヤデータ（例えば、MAC−dデータ）を、新しい拡張された配信チャネルに多重化して、エンティティを送信するHARQプロトコルを操作するという新しいタスクを実行する。
【００２７】
（E−DCH MACアーキテクチャ−UEサイド）
UEのMAC−eエンティティが、図4に、より詳細に描かれている。UEからノードB.に送信される、相異なるアプリケーションからのデータパケットを運ぶ、N個の相異なるデータフロー(MAC−d)が、存在する。これらのデータフローは、相異なるQoS要求（例えば、遅延要求およびエラー要求）を持つことができ、HARQインスタンスの相異なる構成を要求してもよい。各MAC−dフローは、特定の物理チャネルの属性（例えば、利得）、および、HARQの属性（例えば、再送の最大数）を割り付けることができる論理ユニットを表わしている。
【００２８】
さらに、MAC−d多重化が、一つのE−DCHに対して維持される、即ち、異なる優先度を持ついくつかの論理チャネルを、同一のMAC−dフロー上に多重化することができる。したがって、一つのMAC−dフローからのデータを、相異なる優先度キューに送り込むことができる。E−DCH上のデータの送信に対する適切な配信フォーマットの選択は、機能エンティティを表わすTF選択エンティティにおいてなされる。配信フォーマット選択は、利用可能な送信パワー、優先度（例えば、論理チャネル優先度）、および、ノードBから受信された、連係する制御シグナリング（HARQおよびスケジューリング関連の制御シグナリング)に基づいている。HARQエンティティは、ユーザのための再送機能を扱う。一つのHARQエンティティが、複数のHARQプロセスを維持する。HARQエンティティは、要求されたHARQ関連の全ての機能を扱う。MAC−eエンティティは、図4に示されるように、レイヤ−1シグナリングを介して、ノードB（ネットワークサイド）からのスケジューリング情報を受信する。
【００２９】
（E−DCH MACアーキテクチャ−UTRANサイド）
ソフトハンドオーバ作動において、MAC−eエンティティは、UTRANサイド上のノードB (MAC−eｂ)とS−RNC (MAC−eｓ)とを横断して分配されると仮定することができる。ノードBのスケジューラは、これらのエンティティの間にアクティブユーザを選んで、命令レート(commanded rate)、提案レート(suggested rate) 、または、アクティブユーザ(UE)をTFCSのサブセットに制限するTFC閾値を通してレート制御を実行する。いずれのMAC−eエンティティも、1人のユーザ(UE)に対応する。
【００３０】
図5に、ノードBのMAC−eアーキテクチャが、より詳細に描かれている。各HARQ再送エンティティが、未解決の再送からパケットのビットを組み合わせるための、ある量のソフトバッファメモリを割り付けられていることが分かる。ひとたび、パケットが、首尾よく受信されると、それは、上位レイヤにインシーケンスデリバリ(in−sequence delivery)を提供する並べ替えバッファに転送する。
【００３１】
並べ替えバッファは、ソフトハンドオーバの間、S−RNCに存在すると想定してもよい。
【００３２】
図6に、対応するユーザ(UE)の並べ替えバッファを有する、S−RNCのMAC−eアーキテクチャが示されている。並べ替えバッファの数は、対応するUEサイドのMAC−eエンティティ内のデータフローの数に等しい。データおよび制御情報が、ソフトハンドオーバの間、アクティブセット内の全てのノードBからS−RNCに送られる。
【００３３】
必要とされるソフトバッファサイズは、用いられるHARQ方式に依存する、例えば、incremental redundancy (IR)を用いるHARQ方式は、chase combining (CC)を持つHARQ方式よりも多くのソフトバッファを必要とすることに注意されたい。
【００３４】
（並べ替え機能）
いくつかのデータフローを、UEサイドの一つのMAC−e PDUに多重化して、フレーム充填効率(frame fill efficiency)を改善してもよい。RLCプロトコルが、acknowledged mode（AM：肯定モード）で働くように構成されている場合には、RLCレベルでの損失および再送の不必要な検出を回避するために、ネットワークサイドのRLCエンティティへのRLC PDUのインシーケンスデリバリが必要である。
【００３５】
並べ替え機能の作動は、図8に例示されているように、このレポートのために、レシーバウィンドウ(Receiver Window)および並べ替え解除タイマ(Reordering Release Timer)と名付けた、2つの主なパラメータによって決定される。レシーバウィンドウは、アップリンクにおける容認可能な最大データレートのための上限をセットアップする。ウィンドウの現在の上端より大きいTSNを持つPDUが、並べ替えバッファに入ってきたときには常に、レシーバウィンドウは、より大きなTSNの方向に移動し、その範囲外に残存するPDUは、RLC受信エンティティに直ちに転送される。ウィンドウは、また、並べ替え解除タイマの終結後にも同じ方向に移動し、したがって、RLC受信エンティティによるギャップの検出を可能にする。
【００３６】
並べ替え機能の詳細は、まだ、標準化されていないが、2つの主なパラメータが、S−RNCによる半固定的な構成（レガシーアーキテクチャ）に従うことは、ほとんど確実である。
【００３７】
（E−DCH−ノードB制御スケジューリング）
ノードB制御スケジューリングは、アップリンクにおいて、より高いセル処理能力を提供し、また、受信可能範囲を増加させるために、アップリンクパワーリソースのより効率的な使用を可能にすることが予測される、E−DCHにおける技術的特色の一つである。用語「ノードB制御スケジューリング」は、ノードBが、RNCによって構成される限度内において、UEが適切な一つのTFCを選ぶことのできるTFCのセットを制御する可能性を表示している。UEが、自主的に一つのTFCを選ぶことのできるTFCのセットは、以下において、「ノードB制御TFCサブセット」と呼ばれる。
【００３８】
「ノードB制御TFCサブセット」は、図7に見られるように、RNCによって構成されるTFCSのサブセットである。UEは、Rel5 TFC選択アルゴリズムを使用して、「ノードB制御TFCサブセット」から、適切な一つのTFCを選択する。十分なパワーマージン、利用可能な十分なデータがあり、TFCはブロック状態にないという条件で、UEは、「ノードB制御TFCサブセット」内の任意のTFCを選択することができる。E−DCHにおけるUE送信をスケジュールするための、2つの基本的なアプローチが、存在する。それらのスケジューリング方式は、全て、UEにおけるTFC選択の管理として見ることができ、主に、ノードBが、どのようにこのプロセス、および、それに関連するシグナリング要求に影響を及ぼすことができるかという点で異なる。
【００３９】
（ノードB制御レートスケジューリング）
このスケジューリングアプローチの原理は、ノードBが、高速TFCS制限制御によって、ユーザ機器のTFCSを制御し、制限することを可能にすることである。ノードBは、ユーザ機器が、レイヤ1シグナリングによって、そこから適切なTFCを自主的に選ぶことのできる「ノードB制御TFCサブセット」を拡大／縮小することができる。ノードB制御レートスケジューリングにおいては、全てのアップリンク送信が、並列に、しかしながら、ノードBにおけるノイズ上昇閾値を超過しないように十分に低いレートで、起こる。したがって、相異なるユーザ機器からの送信が、調子をそろえてオーバーラップするかもしれない。レートスケジューリングを用いて、ノードBは、アップリンクTFCSを制限することしかできず、UEがE−DCH上にデータを送信している時間に対する何らの制御も持っていない。ノードBが、同時に送信しているUEの数を意識しないことによって、セルのアップリンクノイズ上昇の正確な制御は、不可能である（非特許文献３を参照されたい）。
【００４０】
ノードBとユーザ機器との間のレイヤ1シグナリングによってTFC制御を可能にするために、2つの新しいレイヤ1メッセージを導入する。アップリンクにおいて、ユーザ機器は、ノードBにRate Request（RR：レート要求）を送ることができる。RRによって、ユーザ機器は、ノードBに、1ステップずつ「ノードB制御TFCサブセット」を拡大／縮小するように要求することができる。さらに、ダウンリンクにおいて、ノードBは、ユーザ機器にRate Grant（RG：レート許諾）を送ることができる。RGを用いて、ノードBは、例えば、アップ／ダウン命令を送ることによって、「ノードB制御TFCサブセット」を変えることができる。新しい「ノードB制御TFCサブセット」は、それが更新される次回まで有効である。
【００４１】
（ノードB制御レートアンドタイムスケジューリング）
ノードB制御レートアンドタイムスケジューリングの基本原理は、ユーザ機器のサブセットが、ノードBにおける希望総ノイズ上昇を超過しないように、所定の時間に送信することを可能にする（理論上でのみ）ことである。1ステップずつ「ノードB制御TFCサブセット」を拡大／縮小するためにアップ／ダウン命令を送る代わりに、ノードBは、明示的なシグナリングを通して、例えば、TFCSインジケータ（ポインタでもよい）を送ることによって、任意の許容される値に、TFCSを更新することができる。
【００４２】
さらに、ノードBは、ユーザ機器が送信することを許容されるスタート時刻および有効期間をセットすることができる。相異なるユーザ機器に対する「ノードB制御TFCサブセット」の更新は、複数のユーザ機器からの送信が、可能な限りまで調子をそろえてオーバーラップすることを回避するために、スケジューラによって調整することができる。CDMAシステムのアップリンクにおいては、同時送信は、常に、互いに干渉し合う。したがって、E−DCH上にデータを同時に送信するユーザ機器の数を制御することによって、ノードBは、セル内のアップリンク干渉レベルの、より正確な制御を得ることができる。ノードBスケジューラは、例えば、ユーザ機器のバッファ状態、ユーザ機器のパワー状態、および、利用可能なノードBにおける干渉のRise over Thermal (RoT)マージンに基づいて、送信時間間隔(TTI)当り、どのユーザ機器が送信を許容されるかということ、および、対応するTFCSインジケータを決定することができる。
【００４３】
ノードB制御レートアンドタイムスケジューリングを維持するために、2つの新しいレイヤ1メッセージが、導入される。アップリンクにおいて、ユーザ機器は、ノードBに、Scheduling Information Update（SI：スケジューリング情報更新）を送ることができる。ユーザ機器が、ノードBにスケジューリング要求を送る必要性を見出した（例えば、新しいデータが、ユーザ機器バッファに生じた）場合、ユーザ機器は、所要のスケジューリング情報を送信することができる。このスケジューリング情報によって、ユーザ機器は、ノードBに、自分の状態（例えば、自分のバッファ占有状態および利用可能な送信パワー）についての情報を提供することができる。
【００４４】
ダウンリンクにおいて、ノードBからユーザ機器にScheduling Grant（SG：スケジューリング許諾）を送信することができる。スケジューリング要求を受信すると、ノードBは、スケジューリング情報(SI)、および、利用可能なノードBにおけるRoTマージンのようなパラメータに基づいて、ユーザ機器をスケジュールすることができる。Scheduling Grant (SG)において、ノードBは、TFCSインジケータ、および、ユーザ機器によって用いられる、その後の送信のスタート時刻および有効期間を信号で伝えることができる。
【００４５】
E−DCHが、アップリンクにおいて、そのUEおよび他のUEによる他の送信の混合と共存しなければならないため、レートスケジューリングと、レートアンドタイムスケジューリングとのいずれの使用も、もちろん、利用可能なパワーによって制限される。相異なるスケジューリングモードの共存は、相異なるトラフィックタイプを扱う際に柔軟性を与える。例えば、より低いデータレートを要求するアプリケーションは、レート制御モードでE−DCHに送ることができ、一方、より高いデータレートを要求するアプリケーションは、レートアンドタイム制御モードでE−DCHに送ることができる。
【００４６】
（サービングノードB、および、ノードB制御スケジューリングにおけるその役割）
以下のセクションにおいて、無線インターフェイスレイヤ2の観点から、スケジューリング操作を簡潔に要約する。ノードB制御スケジューリングは、アップリンクおよびダウンリンクの制御と、UEが、このシグナリングに関してどのように振る舞うかに関する1セットのルールとに基づく。ダウンリンクにおいて、UEに、そのUEが用いることができるアップリンクリソースの最大量を示すために、リソース表示（スケジューリング許諾）が必要とされる。
【００４７】
（保証ビットレートトラフィックのためのノードB制御スケジューリング）
保証ビットレートトラフィックは、非スケジュールデータ（スケジュールされていないデータ）の送信、および、スケジュールデータの送信を許容することによって維持される。
【００４８】
非スケジュールデータ送信では、MAC−dフロー、または、論理チャネルに対して保証ビットレートを維持することができる。非スケジュール送信とは、送信を許諾するノードBにおいてスケジューラなしに、自主的な送信を可能にするということを意味する。一般に、S−RNCは、トラフィックが、非スケジュールモードで送信されるか否かを決定して、その決定を、それぞれのUE、および、そのUEと通信しているノードBに報告する。それぞれのノード−Bは、非スケジュールデータ送信の統計多重利得に基づいて、十分な量のリソースを蓄えていなければならない。このメカニズムは、例えば、音声のような保証ビットレートの遅延に敏感なアプリケーションに対して、および／または、無線ベアラのシグナリングに対して、用いることができる。
【００４９】
スケジュールデータ送信では、UEに対して保証ビットレートが、維持される。それぞれの保証ビットレート値が、S−RNCによって、ノードBに提供されて、スケジューラは、この構成パラメータに従って行動する。このメカニズムは、例えば、ストリーミングのような保証ビットレートの遅延に敏感でないアプリケーションに対して用いるのが有利である。
【００５０】
（スケジューリング許諾）
スケジューリング許諾は、TTI当り、または、より遅い間隔当りに1回送ることができる。2つのタイプの許諾（絶対許諾および相対許諾）がある。絶対的許諾は、UEが用いることのできるULリソースの最大量の絶対的な限度を提供する。相対的許諾は、前に用いられた値と比較して、リソース限度を増加させる、または、減少させる。
【００５１】
E−DCHのソフトハンドオーバ(SHO)作動を考えたとき、サービングノードBおよび非サービングノードBを定義することができる。サービングノードBは、ソフトハンドオーバにおいて、UEのサービングセルを制御するノードBとして定義することができる。絶対的許諾は、サービングノードBによってしか送られず、一方、相対的許諾は、サービングノードBと非サービングノードBとのどちらによっても送られるということに注意することは、重要なことである。UEが絶対的許諾を受信するセルは、サービングセルと呼ばれる。さらに、サービングセルを制御するノードBは、サービングノードB、または、SノードBと呼ばれる。
【００５２】
上に示したように、絶対的スケジューリング許諾は、サービングセルを通して送られ、一つのUEに対して、一グループのUEに対して、または、全てのUEに対して有効である。さらに、絶対的許諾は、それに伴う有効継続期間を持つことができる。
【００５３】
相対的スケジューリング許諾（更新）は、絶対的許諾の補完物として、サービングノードBおよび非サービングノードBによって送られる。サービングノードBからの相対的許諾は、3つの値（「アップ」、「ホールド」、「ダウン」）のうちの一つをとることができる。さらに、非サービングノードBからの相対的許諾は、2つの値（「ホールド」、「ダウン」）のうちの一つをとることができる。「ダウン」命令は、「過負荷インジケータ」に対応する。
【００５４】
UEの振る舞いは、絶対的／相対的許諾が移動端末で処理される仕方によって決定される。
【００５５】
UEが受信するスケジューリング許諾の一つの典型的な作動は、以下のとおりである。
【００５６】
UEは、サービングノードBの相対的許諾によって、TTI毎に、変更されている、E−DCHサービングセルから受信された最後の絶対的許諾に対応する「サービングノードBの許諾」を保持する。この作動は、非サービングノードBから受信された相対的許諾に依存しない。少なくとも一つの非サービングノードBが、「ダウン」を示すと、UEは、あらかじめ定められたオフセットだけ、現在用いられているビットレートを低下させる。オフセットは、ビットレートに依存する。
【００５７】
あらかじめ定められるオフセットの計算は、実装依存である。例えば、そのオフセットは、サービングセル上で測定されるCPICHパワーに関して、過負荷セル上で測定されたCPICHパワーの関数であるかもしれない。
【００５８】
もはや、いずれの非サービングノードBからも、それ以上の「ダウン」が受信されなくなると、UEは、その現在のビットレートを、保持している「サービングノードBの許諾」に達するまで、別のあらかじめ定められたオフセットによって、次第に増加させる。そのオフセットは、ビットレートに依存していてもよい。ひとたび、「サービングノードBの許諾」に到達してしまい、そして、いずれの非サービングノードBからも、「ダウン」が受信されない限り、UEは、サービングノードBに従う。
【００５９】
本発明で考えられているUEの振る舞いと、他で考えられているUEの振る舞いとの共通点は、UEによるアップリンクデータレートに対する最上限が、サービングノードBによってセットされること、および、その上限を、非サービングノードBによって一時的に律則することができるということである。UMTSリリース99におけると同様に、リリース6におけるE−DCHにおいても、DPCCHからのパワーオフセットを表わす利得が、UEによって計算される、または、UTRANから、アップリンクデータ送信のために用いられる各TFC(transport format combination)に明示的に信号で伝えられる。
【００６０】
現在、いわゆる「ブーステッドモード」および「ノミナルモード」が、3GPP内で審議中である。「ブーステッドモード」は、非常に遅延に厳しいデータの送信に対して用いるべきである。送信ブースト（強補）は、アップリンクデータ送信における、ある付加的な利得（パワーオフセット）によって達成される。「ノミナル」モードにおける利得は、前述のような「ブーステッド」モードにおいて計算される、または、明示的に信号で伝えられる利得である。「ブーステッド」モードにあるUEが、ノミナルモードにあるUEよりも、rise over thermal (RoT)に、より大きく寄与することは明らかである。
【００６１】
現在の方式を考えると、保証ビットレートトラフィックに対する当該一時的制限の影響が、アクティブセット更新基準(active set Update criteria)、利得に関するUEモード（ブーステッド、ノミナル）、および、当該オフセットのセッティングに依存することは明らかである。アクティブセット更新基準は、ネットワーク実装の問題であって、UEの区別に確固として寄与するとは期待されない。他方、UE利得およびオフセットセッティング（それらは、必要とされるビットレートに依存してもよい）は、様々なUEの間で著しく異なることができ、したがって、一つのセルにおける総測定は、不十分な情報量しか伝えないことを暗に示している。したがって、いくつかのシナリオにおいて、個別測定は、通常の（総）レイヤ2測定と比較したとき、明らかに有利である。
【００６２】
（高コストUEの定義）
E−DCH上のアップリンク送信に用いられるTFの各々は、アクティブセット内のノードBにおける、ある量のノイズ上昇と関連する。したがって、各UEを、そのセル内のそのUEによって引き起こされたノイズ上昇を反映する、あるコスト要因に関連する。
【００６３】
UEのTFセット内のTF間の例示的なマッピングが、下の表に見出される。
【表１】
2010022019.tif 000003
なお、UEの利得も、同様に、UEのコストに寄与することに注意されたい。
【００６４】
（E−DCHにおける機能分割）
E−DCHを介してアップリンクデータを送信するとき、データチャネルは、通常、S−RNCで終結する。しかしながら、特に、移動端末のソフトハンドオーバシナリオにおいては、アップリンクデータは、UEから、ノードBおよびC−RNCを介して、S−RNCに提供される。この場合には、以下のようなネットワーク要素の機能分割を、備えることができる。C−RNCは、無線ネットワークサブシステム(RNS)のリソース全体に渡って所有権を持つネットワーク要素として定義することができ、一方、S−RNCは、無線接続ネットワークサイドにユーザに特定の機能（例えば、並べ替え）を終結させるネットワーク要素として定義することができる。
【表２】
2010022019.tif 000004
承認制御の目的は、新しいユーザ、新しい無線接続ベアラ、または、新しい無線リンク（例えば、ハンドオーバによる）を承認する、または、否認することである。承認制御は、過負荷状況を回避し、その判定を、干渉測定とリソース測定とに基づかせるように努めなければならない。承認制御は、例えば、最初のUEアクセス、RAB割り付け／再構成、および、ハンドオーバにおいて使用される。これらの場合には、優先度および状況に応じて、異なる応答が与えられる。
【００６５】
通常、アップリンク干渉およびダウンリンクパワーに基づいた承認制御機能が、制御RNCに置かれる。サービングRNCは、Iuインターフェイスに向けて承認制御を実行している。
【００６６】
輻輳制御のタスクは、システムが、すでに接続しているユーザのために過負荷に近い状況、または、過負荷状況に達している状況を監視し、検出し、扱うことである。
【００６７】
これは、ネットワークのある部分が、リソースを使い果たしている、または、まもなく使い果たすであろうことを意味する。したがって、輻輳制御は、できるだけ途切れなく、システムを安定状態に戻さなければならない。
【００６８】
UMTSによって提供されるスケジューリングおよび並べ替えの機能は、上で検討している。
【００６９】
（E−DCH構成）
（セルレベルE−DCH構成）
第1に、「E−DCHに利用可能な総パワー」に関して、ノードBが、セル内のUEをスケジュールするとき、測定される総E−DCHパワーが、E−DCHに対して信号で示されているトータルパワーを超過しないように、E−DCHを構成することができる。第2に、「総ULパワーの目標／限度」に関して、ノードBが、セル内のE−DCH UEをスケジュールするとき、測定される総ULパワーが、総ULパワーの信号で示されている目標を超過しないように、E−DCHを構成することができる。最後に、「E−DCHに利用可能な総パワー」に関して、「総ULパワーの目標／限度」を組み込んで、E−DCHを構成することができ、それは、前の2つの構成の仕方の組合せである。
【００７０】
これら3つのセルレベル構成の仕方の各々において、例えば、同時係属中の特許文献１に記述されているように、MAC−dフロー毎に、E−DCHを構成することができる。
【００７１】
Iur移動性のないE−DCHの例示的な配信チャネルプロトコルモデルが、図9に示されている。E−DCHフレームプロトコル(FP)が、Iur移動性の場合に、C−RNCで終結するのか、S−RNCで終結するのかは、まだ不明である。Iur移動性を担ったE−DCHの例示的な配信チャネルプロトコルモデルが、図10に示されている。Iur移動性のない（即ち、S−RNCとC−RNCとが一致する）アップリンク送信においては、提供ビットレート（ノードB当りの、または、マクロダイバーシティコンバイニング後の）は、RNCにおいて測定される。
【００７２】
しかしながら、Iur移動性（即ち、S−RNCとC−RNCとが一致しない）の場合には、E−DCH FPが、図10に例示するように、C−RNCで終結していなければ、C−RNCにおいて、E−DCH上の個々のアップリンク送信の提供ビットレートを測定することは不可能である。もし、E−DCH FPが、C−RNCで終結していれば、ノードB当りの提供ビットレートを測定することは可能であるが、マイクロダイバーシティコンバイニング後に提供されるビットレートを測定することは不可能である。
【００７３】
（QoSクラスおよび属性）
送信される情報の性質は、その情報を送信すべき仕方に強い影響を持つ。例えば、音声電話は、ブラウジングセッション（インターネット）と完全に異なる特性を持っている。一般に、アプリケーションおよびサービスは、それらを、どのように考えるかに応じて、異なるグループに分割することができる。サービスの4つの異なるクラスが、UMTSにおいて同定されており、下の表は、それらのそれぞれの特性および予測される使用事例をリストしている。
【表３】
2010022019.tif 000005
これらのトラフィッククラスの各々に対して、QoS属性のリストを、次の表に示すように定めることができる。QoS属性が、満たされれば、メッセージは、必要な品質を持って、エンドユーザに読み取られることが保証される。QoS属性は、接続のセットアップ中に、通信鎖（UE、RNC、CN要素）の相異なる要素間で折り合いをつけられ、また、要求されるサービスのタイプ、および、種々のノードの能力に依存する。QoS属性の一つが、満たされなければ、エンドユーザは、通信の劣化（例えば、音声ひずみ、接続ブランクなど）を確実に感知するであろう。
【表４】
2010022019.tif 000006
無線接続ベアラ(RAB)割り付け処理中に、RNCは、確立されるRABのパラメータ、特に、そのQoS属性を受信する。CNが、RNCに、RAB ASSIGNMENT REQUEST（RAB割り付け要求）メッセージを送ることによって、その処理を開始する。そのメッセージには、QoS属性を含むRABに対して必要な全てのパラメータを有するIE「RAB Parameters（RABパラメータ）」が含まれている。
【００７４】
RAB割り付け要求メッセージを受信して、UTRANは、要求されたRAB構成を実行する。CNは、RAB QoSの折り合いが、いくつかのRABパラメータに対して許容されること、および、いくつかの場合には、さらに、どのような代替値を、その折り合いに用いるべきかを示してもよい。
【００７５】
RAB QoS折り合いの背後にある概念は、ユーザが、指定のQoS要求を持つサービスを求めているが、いくつかの理由（例えば、リソースが利用可能でない）で、システムが、その要求を正確には満たすことができない場合に、解決法を提供することである。そのような状況において、ユーザを、サービスなしのままにしておくのではなくて、ユーザに、少なくとも、妥協したQoS属性を持つ接続を提供するために、保証ビットレート、または、最大ビットレートのような、いくつかのRABパラメータ（QoS属性）の折り合いが、CNによって許容される。RAB確立およびQoS折り合いは、C−RNCにおいて実行されるIu承認制御の型である。
【００７６】
上記のE−DCHにおける機能分割に関するセクションで述べられた承認制御は、Serving Radio Network Subsystem（サービング無線ネットワークサブシステム）に対する承認制御に言及したものである。サービング無線ネットワークサブシステムのリソースは、その結果、C−RNCによって制御される。Iu承認制御は、Radio Access Network（無線接続ネットワーク）に対する承認制御に言及したものであって、S−RNCの機能である。
【先行技術文献】
【特許文献】
【００７７】
【特許文献１】欧州特許出願第04 023 418.9号明細書
【非特許文献】
【００７８】
【非特許文献１】3GPP TR 25.401「UTRAN Overall Description」（http://www.3gpp.orgから利用可能)
【非特許文献２】3GPP TS 25.433「UTRAN Iub Interface NBAP Signaling」バージョン6.1.0
【非特許文献３】3GPP TR 25.896「Feasibility Study for Enhanced Uplink for UTRA FDD (Release 6)」（http://www.3gpp.orgから利用可能）
【発明の概要】
【発明が解決しようとする課題】
【００７９】
上で示したように、UMTS無線接続ネットワークにおいては、スケジュールデータの承認制御および輻輳制御の目的で、不十分な情報しか、C−RNCにおいて利用可能ではない。
【００８０】
C−RNCによるスケジュールデータの承認制御では、QoS要求（レイヤ2情報）の与えられた充足レベルにおけるリソース消費（レイヤ1情報）に関して、C−RNCにおいて、ノードBから、情報を集める必要がある。このレイヤ2情報は、現在、C−RNCにおいて利用不可能である。既に承認されている、保証ビットレート(GBR)のユーザが、QoSに関して満足な性能を持てば、追加のユーザを承認することができる。
【００８１】
C−RNCによるスケジュールデータの輻輳制御では、呼承認制御中にS−RNCと同調して、QoS要求（レイヤ2情報）の与えられた充足レベルにおけるリソースの現在の消費（レイヤ1情報）に関して、ノードBから、情報を集める必要がある。そうすると、それらのC−RNCが、それらの要求を受け入れるために、いくつかのアクションを実行することができる。
【００８２】
輻輳制御の一部として、C−RNCは、特定のユーザのE−DCHに割り付けられたリソース（例えば、「総パワー」）を再構成することができる、または、与えられた論理チャネル／MAC−dフロー上にトラフィックを専有して、それを、レガシー個別チャネルに切り替えようとすることができる。承認制御におけると同じく、この情報は、現在、C−RNCにおいて利用不可能である。
【００８３】
主な問題は、レイヤ2情報が、C−RNCにおいて欠落しているということである。スケジュールデータのQoS制御を、この情報なしで適切に実行することはできない。
【００８４】
しかしながら、High Speed Downlink Packet Access（HSDPA：高速ダウンリンクパケット接続）、Multimedia Broadcast Multicast Service（MBMS：マルチメディア放送／マルチキャストサービス）、および、High Speed Uplink Packet Access（HSUPA：高速アップリンクパケット接続）が、恐らく、配信ネットワーク容量に、特に、「last mile（ラストマイル）」接続（即ち、レガシーUTRANにおけるIub）に追加の要求を強いながら、無線接続ネットワークにおいて、それぞれの時間的な順序で配備される。例えば、Iubは、ポイントトゥマルチポイントMBMS無線ベアラが、非常に多数のポイントトゥポイントタイプのIub配信接続にマップされることを意味するマルチキャスト送信（少なくとも、リリース6のフレームワークにおいては）に対して最適化されないであろう。接続ネットワークに新特質を配備するとき、「ラストマイル」に対する設備投資に応じて、このインターフェイス上で、大きさの違いはあっても何らかの遅延の発生が、または、程度の差はあっても頻出する輻輳の発生が、あり得る。したがって、見込まれるIubの負荷を最小限にすることは、上で同定したような問題に対する設計制約として役立つ。
【００８５】
本発明の一つの目的は、移動通信システム内のコントローリング無線ネットワーク制御装置が、保証ビットレートを持つアップリンク送信に対して輻輳制御を実行することを可能にすることである。
【００８６】
本発明のさらなる一つの目的は、ノードBとRNCとの間のインターフェイスの負荷を縮小することである。
【００８７】
これらの目的は、独立請求項の対象によって解決される。本発明の有利な実施例が、従属請求項の対象である。
【課題を解決するための手段】
【００８８】
本発明の主な態様の一つは、前記ユーザ機器のソフトハンドオーバ作動中に、少なくとも一つのノードBから、C−RNCに、スケジュールデータに対する測定を送るための処理を決めることによって、上述の問題を克服することである。それに代えて、UEに接続された少なくとも一つのノードBの提供ビットレートを、S−RNCにおいて割り出して、それを、S−RNCからC−RNCに送ってもよい。
【００８９】
本発明の例示的な一実施例は、保証ビットレートを持つ、スケジュールデータの提供ビットレートについての測定を提供するための一方法を含んでいる。前記スケジュールデータが、一つのユーザ機器によって、前記ユーザ機器のソフトハンドオーバ中に、移動通信システムのコントローリング無線ネットワーク制御装置を介して、個別アップリンクデータチャネル上に送信される。前記ソフトハンドオーバに関与するノードBの少なくとも一つが、前記コントローリング無線ネットワーク制御装置に接続されている。さらに、前記移動通信システムの前記ユーザ機器の個々のアップリンクデータ送信が、各々、一つの優先度クラスに関連している。
【００９０】
前記コントローリング無線ネットワーク制御装置は、前記ユーザ機器によって前記個別アップリンクデータチャネル上に送信される、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータに提供されている前記提供ビットレートを指示する少なくとも一つの個別測定レポートを受信してもよい。前記少なくとも一つの個別測定レポートは、前記コントローリング無線ネットワーク制御装置に接続されている、前記ユーザ機器のアクティブセットの少なくとも一つのノードBから受信される。
【００９１】
次に、前記コントローリング無線ネットワーク制御装置は、前記少なくとも一つの優先度クラスのそれぞれ一つに提供されている、それぞれの提供ビットレートが、前記それぞれの優先度クラスの前記保証ビットレートよりも低いか否かを評価してもよい。
【００９２】
前記少なくとも一つの優先度クラスに対する、それぞれの提供ビットレートが、前記それぞれの優先度クラスに対する前記保証ビットレートよりも低い場合に、前記コントローリング無線ネットワーク制御装置は、前記それぞれの優先度クラスのデータ送信に対して輻輳制御を実行して、前記アップリンクデータチャネルを介して、少なくとも前記保証ビットレートで、前記優先度クラスの前記スケジュールデータを送信することを可能にするか、または、前記アップリンク個別配信チャネルへの、前記それぞれの優先度クラスのデータの前記送信を回避してもよい。
【００９３】
本発明のさらなる一実施例において、前記コントローリング無線ネットワーク制御装置に接続されている、前記少なくとも一つのノードBは、前記ソフトハンドオーバ中、前記ユーザ機器のサービングノードBである。前記サービングノードBは、UEのサービングセルを制御する前記ノードBとして定義される。
【００９４】
本発明の本実施例によって提案される構成は、最良のアップリンクチャネル品質を与えるから、サービングノードBが、最も高いアップリンクビットレートを提供する、ユーザ機器のアクティブセット内のノードBであると仮定できる場合に、特に、適している。
【００９５】
本実施例の一変形例において、前記少なくとも一つの測定レポートが、前記サービングノードBのみから受信され、前記少なくとも一つの受信された個別測定レポートの各々が、前記サービングノードBが一つの共通のサービングノードBである、全てのユーザ機器のそれぞれ一つによって前記個別アップリンクデータチャネル上に送信された、前記少なくとも一つの保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレートを指示する。
【００９６】
この変形例によれば、サービングノードBは、したがって、ソフトハンドオーバ状態にある個々のユーザ機器に関して報告するだけではなく、同じサービングノードBをもっぱら共有している他のユーザ機器に関しても報告するように構成することができる。
【００９７】
本実施例の他の一つの変形例において、前記少なくとも一つの測定レポートが、前記サービングノードBのみから受信され、前記受信された少なくとも一つの測定レポートの各々が、前記サービングノードBに接続された全てのユーザ機器のサブセットのそれぞれ一つによって個別アップリンクデータチャネル上に送信された、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータの提供ビットレートを指示する。
【００９８】
前記サブセットが、あらかじめ定められた閾値よりも高い、それぞれの優先度クラスに関連したスケジューリング優先度インジケータを持つ前記サービングノードBに接続されたユーザ機器を有する。
【００９９】
本発明の種々の実施例の以下の記述において、さらに詳細に説明するように、スケジューリング優先度インジケータを、それぞれの優先度クラスに直接関連させてもよい。したがって、この変形例は、サービングセルのノードBのみが、共通のサービングノードBを共有し、かつ、例えば、一つの保証ビットレート優先度クラスに関連する一つのスケジューリング優先度インジケータを用いるUEのあらかじめ定められたセットについて、報告するように構成することを可能にする。
【０１００】
本発明のさらなる一実施例は、保証ビットレートを持つスケジュールデータの提供ビットレートについての測定を提供する方法に関するものである。前記スケジュールデータは、ユーザ機器によって、前記ユーザ機器の少なくとも一つの、ソフトハンドオーバ中に、一つの移動通信システム内の一つのコントローリング無線ネットワーク制御装置を介して、個別アップリンクデータチャネル上に送信されてもよい。前記ソフトハンドオーバに関与するノードBの少なくとも一つが、前記コントローリング無線ネットワーク制御装置に接続されている。ここでも、前記移動通信システム内の前記ユーザ機器の個々のアップリンクデータ送信が、各々、一つの優先度クラスに関連している。
【０１０１】
本実施例によれば、前記コントローリング無線ネットワーク制御装置は、前記個別アップリンクデータチャネル上に送信されている、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータに提供されている、少なくとも一つの提供ビットレートを指示する少なくとも一つの共通測定レポートを受信してもよい。前記少なくとも一つの共通測定レポートが、ハンドオーバ状態にある前記少なくとも一つのユーザ機器のアクティブセットの、少なくとも一つのノードBから受信され、前記少なくとも一つのノードBは、前記コントローリング無線ネットワーク制御装置に接続されている。
【０１０２】
さらに、前記コントローリング無線ネットワーク制御装置は、前記少なくとも一つの優先度クラスのそれぞれ一つに提供されている、それぞれの提供ビットレートが、前記それぞれの優先度クラスの保証ビットレートよりも低いか否かを評価してもよい。
【０１０３】
前記少なくとも一つの優先度クラスに対する、それぞれの提供ビットレートが、前記それぞれの優先度クラスに対する前記保証ビットレートよりも低い場合に、前記コントローリング無線ネットワーク制御装置は、前記それぞれの優先度クラスのデータ送信に対して輻輳制御を実行して、前記それぞれのアップリンクデータチャネルを介して、少なくとも前記保証ビットレートで、前記優先度クラスの前記スケジュールデータを送信することを可能にするか、または、前記それぞれの優先度クラスの前記データが、前記それぞれのアップリンク個別配信チャネルに送信されるのを回避してもよい。
【０１０４】
本実施例の一変形例において、前記少なくとも一つのノードBから受信された前記少なくとも一つの共通測定レポートが、前記個別アップリンクデータチャネル上にスケジュールデータを送信するユーザ機器を識別するリストを有する。ユーザ機器のこのリストは、前記スケジュールデータの送信に対してあらかじめ定められた閾値以上の平均アップリンクリソースを用いるユーザ機器を有する。
【０１０５】
「高コスト」ユーザ機器のリストを共通測定レポートに含めることは、コントローリング無線ネットワーク制御装置が、報告しているノードBのセル内のノイズ上昇に著しく寄与している特定のユーザ機器の無線リンクを検出することを可能にする。必要であれば、コントローリング無線ネットワーク制御装置は、このリストから得られる情報を用いて、例えば、そのセル内の他のユーザ機器に対して、そのアップリンクのサービスの品質を拡張するために、特定の「高コスト」ユーザ機器のアクティブセットを再構築してもよい。
【０１０６】
本発明のさらなる一実施例において、前記少なくとも一つの個別測定レポート、または、前記少なくとも一つの共通測定レポートが、前記無線ネットワーク制御装置に接続されたノードBのサブセットから受信される。例えば、ソフトハンドオーバ状態にあるユーザ機器に対しては、このサブセットは、コントローリング無線ネットワーク制御装置によって制御されるユーザ機器のアクティブセットのノードBを有してもよい。
【０１０７】
本実施例の一変形例において、前記コントローリング無線ネットワーク制御装置は、前記少なくとも一つの優先度クラスの前記スケジュールデータの提供ビットレートを指示する少なくとも一つの個別測定レポート、または、少なくとも一つの共通測定レポートを提供することを前記選択されたノードBのサブセットに指示する個別測定要求または共通測定要求を、前記選択されたノードBのサブセットに信号で伝えてもよい。
【０１０８】
さらなる一変形例において、前記少なくとも一つの保証ビットレート優先度クラスのそれぞれ一つの、前記スケジュールデータを伝えるプロトコルデータユニットに対する再送の平均報告数が一つの閾値よりも低いノードBが、選択されて、前記ノードBのサブセットに包含される。
【０１０９】
本発明のさらなる一実施例において、前記少なくとも一つの優先度クラスのそれぞれ一つに対する再送の平均報告数が、個別アップリンク配信チャネルのフレームプロトコルのデータフレームのフィールドに提供される。
【０１１０】
上で指摘したように、フレームプロトコルは、サービング無線ネットワーク制御装置で終結してもよい。したがって、本発明の他の一実施例は、前記コントローリング無線ネットワーク制御装置が、サービング無線ネットワーク制御装置から、前記少なくとも一つの保証ビットレート優先度クラスのそれぞれ一つに対する再送の平均報告数を受信することを予見する。
【０１１１】
本発明の他の一実施例において、前記個別測定レポートまたは前記共通測定レポートが、NBAPプロトコルのDedicated Measurement Report message（個別測定レポートメッセージ）またはCommon Measurement Report message（共通測定レポートメッセージ）であり、前記Dedicated Measurement Report message（個別測定レポートメッセージ）または前記Common Measurement Report message（共通測定レポートメッセージ）が、前記スケジュールデータの前記少なくとも一つの保証ビットレート優先度クラス、および、前記少なくとも一つの保証ビットレート優先度クラスのそれぞれ一つの、前記スケジュールデータに提供されている前記それぞれの提供ビットレート、を指示する情報要素を有する。
【０１１２】
本発明のさらなる一実施例において、前記個別測定要求または前記共通測定要求が、NBAPプロトコルのDedicated Measurement Initiation Request message（個別測定開始要求メッセージ）またはCommon Measurement Initiation Request message（共通測定開始要求メッセージ）であり、前記Dedicated Measurement Initiation Request message（個別測定開始要求メッセージ）または前記Common Measurement Initiation Request message（共通測定開始要求メッセージ）は、前記メッセージを受信するノードBが報告しなければならない前記スケジュールデータの前記少なくとも一つの保証ビットレート優先度クラスを有する。
【０１１３】
他の一実施例は、測定を実行するコントローリング無線ネットワーク制御装置に関するものである。本実施例によれば、保証ビットレートを持ち、そして、一つのユーザ機器によって、一つの移動通信システム内の一つのコントローリング無線ネットワーク制御装置を介して、個別アップリンクデータチャネル上に送信されているスケジュールデータの提供ビットレートについての測定を提供する方法が、提供される。前記移動通信システム内のユーザ機器の個々のアップリンクデータ送信が、各々、一つの優先度クラスに関連している。
【０１１４】
前記コントローリング無線ネットワーク制御装置は、前記ユーザ機器によって前記個別アップリンクデータチャネル上に送信されている、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータに提供されている前記提供ビットレートを指示する少なくとも一つの個別測定レポートを受信してもよい。前記少なくとも一つの個別測定レポートが、それによって、前記ユーザ機器を制御し、かつ、前記コントローリング無線ネットワーク制御装置に接続されている、前記移動通信ネットワークのサービング無線ネットワーク制御装置から受信される。
【０１１５】
本実施例によれば、前記コントローリング無線ネットワーク制御装置は、前記少なくとも一つの優先度クラスのそれぞれ一つに提供されている、それぞれの提供ビットレートが、前記それぞれの優先度クラスの保証ビットレートよりも低いか否かを評価する。
【０１１６】
前記少なくとも一つの優先度クラスに対する、それぞれの提供ビットレートが、前記それぞれの優先度クラスに対する前記保証ビットレートよりも低い場合に、前記コントローリング無線ネットワーク制御装置は、前記それぞれの提供された優先度クラスのデータ送信に対して輻輳制御を実行して、前記個別アップリンクデータチャネルを介して、少なくとも前記保証ビットレートで、前記提供された優先度クラスの前記スケジュールデータを送信することを可能にするか、または、前記アップリンク個別配信チャネルへの、前記それぞれの優先度クラスの前記データの前記送信を回避してもよい。
【０１１７】
本実施例の一変形例において、前記サービング無線ネットワーク制御装置から受信される前記少なくとも一つの個別測定レポートが、前記アクティブセット内の前記ノードBのサブセットのそれぞれ一つによって、前記少なくとも一つの保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレートに関して報告する。それによって、前記サブセットの前記ノードBが、前記コントローリング無線ネットワーク制御装置に接続される。
【０１１８】
本実施例のさらなる一変形例において、前記コントローリング無線ネットワーク制御装置は、前記ノードBの前記サブセットのそれぞれ一つによって、前記少なくとも一つの保証ビットレート優先度クラスのそれぞれ一つの、前記スケジュールデータに提供されている前記提供ビットレートを指示する前記少なくとも一つの個別測定レポートを提供することを、前記サービング無線ネットワーク制御装置に指示する個別測定要求を、前記サービング無線ネットワーク制御装置に信号で伝えてもよい。
【０１１９】
他の一変形例において、前記移動通信システム内のノードBによって制御されるセルが、セル識別子によって識別され、そして、前記個別測定要求が、一つの情報要素内の、前記サブセットに包含される前記ノードBの前記セル識別子を伝える。
【０１２０】
本発明のさらなる一実施例において、前記コントローリング無線ネットワーク制御装置は、前記サービング無線ネットワーク制御装置に個別測定要求を送信してもよい。この個別測定要求は、前記サービング無線ネットワーク制御装置における、前記スケジュールデータのマクロダイバーシティコンバイニングの前に、前記優先度クラスに提供されている前記提供ビットレートに関して報告するのか、または、前記スケジュールデータのマクロダイバーシティコンバイニングの後に、前記少なくとも一つの優先度クラスに提供されている前記提供ビットレートに関して報告するのかの表示を有してもよい。
【０１２１】
さらに、本発明の他の一実施例は、前記個別測定要求が、RNSAPプロトコルのDedicated Measurement Initiation Request message（個別測定開始要求メッセージ）であり、前記Dedicated Measurement Initiation Request message（個別測定開始要求メッセージ）は、前記メッセージを受信する前記サービング無線ネットワーク制御装置が報告しなければならない、前記個別アップリンクデータチャネル上に送信された前記スケジュールデータの前記少なくとも一つの優先度クラスを有することを予見する。
【０１２２】
本発明のさらなる一実施例は、ユーザ機器によって、一つの移動通信システムの内の一つのコントローリング無線ネットワーク制御装置を介し、少なくとも一つのノードBを介して、個別アップリンクデータチャネル上に送信されている、少なくとも一つの優先度クラスのスケジュールデータに提供されている提供ビットレートについての測定を提供する方法に関するものである。それによって、前記移動通信システム内の前記ユーザ機器の個々のアップリンクデータ送信が、各々、一つの優先度クラスに関連している。
【０１２３】
前記コントローリング無線ネットワーク制御装置は、前記ユーザ機器を制御し、かつ、前記コントローリング無線ネットワーク制御装置に接続されている、前記移動通信ネットワークのサービング無線ネットワーク制御装置から、共通測定レポートを受信してもよく、各共通測定レポートは、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータに提供されている前記提供ビットレートを指示する。
【０１２４】
次に、前記コントローリング無線ネットワーク制御装置は、前記少なくとも一つの優先度クラスのそれぞれ一つに提供されている、それぞれの提供ビットレートが、前記それぞれの優先度クラスの保証ビットレートよりも低いか否かを評価してもよく、そして、前記少なくとも一つの優先度クラスに対する、それぞれの提供ビットレートが、前記それぞれの優先度クラスに対する前記保証ビットレートよりも低い場合に、そのコントローリング無線ネットワーク制御装置は、前記それぞれの提供された優先度クラスのデータ送信に対して輻輳制御を実行して、前記個別アップリンクデータチャネルを介して、少なくとも前記保証ビットレートで、前記優先度クラスの前記スケジュールデータを送信することを可能にするか、または、前記ユーザ機器の少なくとも一つに対する、前記アップリンク個別配信チャネルへの、前記優先度クラスの前記データの前記送信を回避してもよい。
【０１２５】
さらなる一実施例において、前記コントローリング無線ネットワーク制御装置は、さらに、前記コントローリング無線ネットワーク制御装置に接続された、前記少なくとも一つのノードBのサブセットを選択してもよく、そして、前記ノードBの前記サブセットのそれぞれ一つによって、前記少なくとも一つの保証ビットレート優先度クラスのそれぞれ一つの、スケジュールデータに提供されている前記提供ビットレートを指示する少なくとも一つの共通測定レポートを提供することを、前記サービング無線ネットワーク制御装置に指示する共通測定要求を、前記サービング無線ネットワーク制御装置に信号で伝えてもよい。前記共通測定要求が、前記共通測定レポートを提供する、前記サブセット内のノードBを設定してもよい。
【０１２６】
本実施例の一変形例において、前記移動通信システム内のノードBによって制御される前記セルが、セル識別子によって識別され、そして、前記共通測定要求が、前記サブセット内の前記ノードBを識別するための情報要素内の、前記サブセットに包含される前記ノードBの前記セル識別子を伝える。
【０１２７】
さらなる一実施例において、前記共通測定要求が、RNSAPプロトコルのCommon Measurement Initiation Request message（共通測定開始要求メッセージ）であり、前記Common Measurement Initiation Request message（共通測定開始要求メッセージ）は、前記サービング無線ネットワーク制御装置が報告しなければならない前記少なくとも一つの優先度クラスを有する。
【０１２８】
本発明の他の一実施例は、前記サービング無線ネットワーク制御装置から受信された前記少なくとも一つの共通測定レポートが、前記個別アップリンクデータチャネル上に前記スケジュールデータを送信する前記ユーザ機器を識別するリストを有することを予見する。前に説明したように、前記リストは、前記スケジュールデータの送信に対してあらかじめ定められた閾値以上の平均アップリンクリソースを用いるユーザ機器を有する。
【０１２９】
本発明の他の一実施例において、前記コントローリング無線ネットワーク制御装置は、以前に、前記優先度クラスに対する前記保証ビットレートよりも低い提供ビットレートを持っているとして報告されていたノードBに対する、その後の測定レポートにおいて、前記優先度クラスに対する、前記提供ビットレートが、少なくとも、前記ノードBにおける前記優先度クラスのアップリンクデータトラフィックに対する前記保証ビットレートに等しいということが指示されれば、前記優先度クラスのアップリンクデータ送信を提供することを要求している新規のユーザ機器に、前記ノードBに接続することを承認してもよい。
【０１３０】
以下の例示的な実施例は、輻輳制御を開始するときに、コントローリング無線ネットワーク制御装置によって実行される動作について論じている。
【０１３１】
例えば、前記保証ビットレート優先度クラスのデータを提供するためにノードBに割り当てることができる最大RoTリソースが、前記優先度クラスの前記データを、前記保証ビットレートで提供するのに十分ではない場合に、および、前記ノードBによって、前記優先度クラスの前記データ送信に提供されている前記提供ビットレートが、前記保証ビットレートよりも低いということを指示する測定レポートが、以前に提供されていた場合に、前記コントローリング無線ネットワーク制御装置は、前記コントローリング無線ネットワーク制御装置から、前記サービング無線ネットワーク制御装置に、前記ユーザ機器における、前記優先度クラスに関連したMAC−dフローの回避を要求する無線リンク回避要求を送信してもよい。
【０１３２】
他の一実施例において、前記優先度クラスのデータを提供するためにノードBに割り当てることができる最大RoTリソースが、前記優先度クラスの前記データを、前記個別アップリンクデータチャネルを介して、前記保証ビットレートで提供するのに十分である場合に、および、前記ノードBによって、前記優先度クラスの前記データ送信に提供されている前記提供ビットレートが、前記保証ビットレートよりも低いということを指示する測定レポートが、以前に提供されていた場合に、前記コントローリング無線ネットワーク制御装置は、前記サービング無線ネットワーク制御装置に、無線リンク輻輳表示メッセージを送信してもよい。前記無線リンク輻輳表示は、それによって、前記優先度クラスに提供されている前記提供ビットレートが、前記優先度クラスに対する前記保証ビットレートよりも低い前記優先度クラスに関連するMAC−dフローを指示してもよい。
【０１３３】
本発明のさらなる実施例は、サービング無線ネットワーク制御装置、および、その作動に関するものである。それらの実施例の一つによれば、一つの移動通信システムにおいて、アップリンクデータチャネル上の、一つの優先度クラスのデータ送信に提供されている一つの提供ビットレートに関する測定に反応して、前記アップリンク個別チャネル上の、前記優先度クラスのスケジュールデータ送信に対して輻輳制御を開始する方法が、提供される。前記移動通信システム中のユーザ機器のアップリンクデータ送信が、各々、一つの優先度クラスに関連している。
【０１３４】
サービング無線ネットワーク制御装置は、少なくとも一つのユーザ機器のアクティブセットの少なくとも一つのノードBから、少なくとも一つのユーザ機器によって前記アップリンク個別データチャネル上に送信されていた一つの保証ビットレート優先度クラスのスケジュールデータを受信してもよい。
【０１３５】
さらに、それは、前記少なくとも一つのノードBから、前記保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレート、または、前記サービング無線ネットワーク制御装置における、前記優先度クラスの前記スケジュールデータのマクロダイバーシティコンバイニングの実行後に前記保証ビットレート優先度クラスの前記スケジュールデータに提供された前記ビットレートを割り出してもよく、そして、コントローリング無線ネットワーク制御装置に、前記保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレートを指示する少なくとも一つの個別測定レポートを送信してもよい。
【０１３６】
前記サービング無線ネットワーク制御装置は、さらに、前記コントローリング無線ネットワーク制御装置から、前記少なくとも一つのユーザ機器によって送信された、前記提供ビットレートが保証ビットレートよりも低いスケジュールデータの保証ビットレート優先度クラスを指示する輻輳表示を受信してもよく、そして、前記指示された保証ビットレート優先度クラスに対して輻輳制御を実行してもよい。
【０１３７】
本発明の他の一実施例は、一つの移動通信システムにおいて、少なくとも一つのアップリンクデータチャネル上の、一つの優先度クラスのデータ送信に提供されている提供ビットレートに関する測定に反応して、少なくとも一つの個別アップリンクチャネル上の、ユーザ機器の前記優先度クラスのスケジュールデータ送信に対して輻輳制御を開始する方法を提供する。ここでも、前記移動通信システム中の前記ユーザ機器からのアップリンクデータ送信が、各々、一つの優先度クラスに関連している。
【０１３８】
本実施例において、前記サービング無線ネットワーク制御装置は、少なくとも一つのノードBから、前記少なくとも一つのノードBのそれぞれ一つに接続された前記ユーザ機器の少なくとも一つによって前記少なくとも一つの個別アップリンクデータチャネルのそれぞれ一つに送信されていた一つの保証ビットレート優先度クラスのスケジュールデータを受信してもよい。
【０１３９】
前記サービング無線ネットワーク制御装置は、前記少なくとも一つのノードBから、前記保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレート、または、前記サービング無線ネットワーク制御装置における、前記スケジュールデータのマクロダイバーシティコンバイニングの実行後に前記保証ビットレート優先度クラスの前記スケジュールデータに提供されたビットレートを割り出してもよく、そして、コントローリング無線ネットワーク制御装置に、前記保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレートを指示する少なくとも一つの共通測定レポートを送信してもよい。
【０１４０】
前記コントローリング無線ネットワーク制御装置から、前記提供ビットレートが保証ビットレートよりも低いスケジュールデータの保証ビットレート優先度クラスを指示する輻輳表示を受信して、前記サービング無線ネットワーク制御装置は、前記指示された保証ビットレート優先度クラスに対して輻輳制御を実行してもよい。
【０１４１】
本実施例の一変形例において、前記サービング無線ネットワーク制御装置は、前記個別アップリンクデータチャネル上に、前記保証ビットレート優先度クラスの前記スケジュールデータを送信しているユーザ機器を識別するリスト（そのリストは、前記スケジュールデータの送信に対してあらかじめ定められた閾値以上の平均アップリンクリソースを用いるユーザ機器を有する）を形成してもよく、そして、ユーザ機器の前記リストを、前記コントローリング無線ネットワーク制御装置に送信される、前記少なくとも一つの共通測定レポートに含めてもよい。
【０１４２】
本発明の他の一実施例は、前記輻輳表示が、前記保証ビットレート優先度クラスに関連するMAC−dフローの回避を要求し、前記サービング無線ネットワーク制御装置が、前記保証ビットレート優先度クラスのスケジュールデータを送信する、少なくとも一つのユーザ機器において、前記保証ビットレート優先度クラスに関連している前記MAC−dフローの前記送信のためのリソースを回避することを、前記コントローリング無線ネットワーク制御装置に指示するMAC−dフロー回避メッセージを送信することを予見する。
【０１４３】
本発明の他の一実施例において、前記サービング無線ネットワーク制御装置は、さらに、前記サービング無線ネットワーク制御装置における、前記スケジュールデータのマクロダイバーシティコンバイニングの前に、前記優先度クラスに提供された前記ビットレートに関して報告するのか、または、前記サービング無線ネットワーク制御装置における、前記スケジュールデータのマクロダイバーシティコンバイニングの後に、前記優先度クラスの前記スケジュールデータに提供されたビットレートに関して報告するのかの、前記サービング無線ネットワーク制御装置に対する表示を有する個別測定要求または共通測定要求を受信してもよい。
【０１４４】
したがって、前記コントローリング無線ネットワーク制御装置に送信された前記少なくとも一つの個別測定レポートまたは共通測定レポートは、前記個別測定要求または前記共通測定要求に備えられている前記表示に従って、マクロダイバーシティコンバイニングの後、または、マクロダイバーシティコンバイニングの前に、前記優先度クラスに提供される前記提供ビットレートを指示する。
【０１４５】
本発明の一実施例において、前記輻輳表示は、輻輳制御を実行すべき、それぞれの優先度クラスに関連するMAC−dフローを指示する無線リンク輻輳表示メッセージである。本実施例において、前記サービング無線ネットワーク制御装置は、サービング無線ネットワーク制御装置によって制御されるTFCS (transport format combination set)が、少なくとも前記保証ビットレートで、前記優先度クラスの前記スケジュールデータを提供することを可能にするほど十分に高いビットレートを提供しない場合に、少なくとも前記保証ビットレートで、前記優先度クラスの前記スケジュールデータを提供することを可能にするために、前記サービング無線ネットワーク制御装置によって制御されるTFC (transport format combination)を再構築してもよい。
【０１４６】
さらに、それは、前記指示されたノードBに、無線リンク再構築要求メッセージを送信してもよい。少なくとも前記保証ビットレートで、前記優先度クラスの前記スケジュールデータを提供することを可能にするために、前記無線リンク再構築要求メッセージは、当該指示されたノードBの、ノードBによって制御されるTFCSを再構築してもよい。
【０１４７】
本発明の他の一実施例において、ユーザ機器のアップリンクデータ送信に関連する前記優先度クラスの少なくとも一つが、前記個別アップリンクデータチャネル上の、前記ユーザ機器の、少なくとも一つの非スケジュールデータ送信に割り当てられる。
【０１４８】
本実施例の一変形例において、前記サービング無線ネットワーク制御装置は、フレームプロトコルまたはNBAPプロトコルで、当該個別アップリンクデータチャネル上に送信された非スケジュールデータに関連する前記優先度クラスの少なくとも一つに輻輳制御を実行すべきか否かについての表示を送信してもよい。
【０１４９】
本発明の他の一実施例において、前記個別アップリンクデータチャネルは、E−DCH (Enhanced Dedicated Uplink Channel)であり、前記移動通信システムは、UMTSシステムである。
【０１５０】
本発明のさらなる一実施例は、一つの保証ビットレートを持ち、そして、一つのユーザ機器によって、前記ユーザ機器のソフトハンドオーバ中に、一つのコントローリング無線ネットワーク制御装置を介して、個別アップリンクデータチャネル上に送信される、スケジュールデータに提供されている提供ビットレートについての測定を評価する、一つの移動通信システム内のコントローリング無線ネットワーク制御装置を提供する。前記ソフトハンドオーバに関与するノードBの少なくとも一つが、前記コントローリング無線ネットワーク制御装置に接続されている。さらに、前記移動通信システムの前記ユーザ機器の個々のアップリンクデータ送信が、各々、一つの優先度クラスに関連している。
【０１５１】
前記コントローリング無線ネットワーク制御装置は、前記ユーザ機器によって前記個別アップリンクデータチャネル上に送信される、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータに提供されている前記提供ビットレートを指示する少なくとも一つの個別測定レポートを受信するための通信手段を有してもよい。前記通信手段は、前記コントローリング無線ネットワーク制御装置に接続されている、前記ユーザ機器のアクティブセットの少なくとも一つのノードBからの前記少なくとも一つの個別測定レポートを受信するように適合化されていてもよい。
【０１５２】
さらに、前記コントローリング無線ネットワーク制御装置は、前記少なくとも一つの優先度クラスのそれぞれ一つに提供されている、それぞれの提供ビットレートが、前記それぞれの優先度クラスの保証ビットレートよりも低いか否かを評価するための処理手段であって、前記少なくとも一つの優先度クラスに対する、それぞれの提供ビットレートが、前記それぞれの優先度クラスに対する前記保証ビットレートよりも低い場合に、前記それぞれの優先度クラスのデータ送信に対して輻輳制御を実行して、前記アップリンクデータチャネルを介して、少なくとも前記保証ビットレートで、前記優先度クラスの前記スケジュールデータを送信することを可能にするか、または、前記アップリンク個別配信チャネルへの、前記それぞれの優先度クラスのデータの前記送信を回避するように適合化されている処理手段を有してもよい。
【０１５３】
本実施例の一変形例において、前記コントローリング無線ネットワーク制御装置は、さらに、上述の本発明の種々の実施例、および、それらの変形例の一つによる、一つの保証ビットレートを持つスケジュールデータに提供されている提供ビットレートについての測定を提供するための方法のステップを実行するように適合化された手段を有してもよい。
【０１５４】
他の一実施例は、一つの保証ビットレートを持ち、そして、ユーザ機器によって、前記ユーザ機器の少なくとも一つのソフトハンドオーバ中に、一つのコントローリング無線ネットワーク制御装置を介して、個別アップリンクデータチャネル上に送信されている、スケジュールデータに提供されている提供ビットレートについての測定を評価する、一つの移動通信システム内のコントローリング無線ネットワーク制御装置を提供する。前記ソフトハンドオーバに関与するノードBの少なくとも一つが、前記コントローリング無線ネットワーク制御装置に接続されており、前記移動通信システムの前記ユーザ機器の個々のアップリンクデータ送信が、各々、一つの優先度クラスに関連している。
【０１５５】
前記コントローリング無線ネットワーク制御装置は、前記個別アップリンクデータチャネル上に送信されている、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータに提供されている、少なくとも一つの提供ビットレートを指示する少なくとも一つの共通測定レポートを受信するための通信手段であって、前記コントローリング無線ネットワーク制御装置に接続されている、前記ユーザ機器のアクティブセットの少なくとも一つのノードBからの前記少なくとも一つの共通測定レポートを受信するように適合化されている通信手段を有してもよい。
【０１５６】
前記コントローリング無線ネットワーク制御装置は、さらに、前記少なくとも一つの優先度クラスのそれぞれ一つに提供されている、それぞれの提供ビットレートが、前記それぞれの優先度クラスの保証ビットレートよりも低いか否かを評価するための処理手段を有してもよい。前記処理手段は、前記少なくとも一つの優先度クラスに対する、それぞれの提供ビットレートが、前記それぞれの優先度クラスに対する前記保証ビットレートよりも低い場合に、前記それぞれの優先度クラスのデータ送信に対して輻輳制御を実行して、前記それぞれのアップリンクデータチャネルを介して、少なくとも前記保証ビットレートで、前記優先度クラスの前記スケジュール前記データを送信することを可能にするか、または、前記それぞれの優先度クラスのデータが、前記それぞれのアップリンク個別配信チャネル上に送信されるのを回避するように適合化されていてもよい。
【０１５７】
この例示的な実施例の一変形例において、前記コントローリング無線ネットワーク制御装置は、さらに、上述の本発明の種々の実施例、および、それらの変形例の一つによる、一つの保証ビットレートを持つスケジュールデータに提供されている提供ビットレートについての測定を提供するための方法のステップを実行するように適合化された手段を有してもよい。
【０１５８】
本実施例の一変形例において、前記コントローリング無線ネットワーク制御装置は、さらに、上述の本発明の種々の実施例、および、それらの変形例の一つによる、一つの保証ビットレートを持つスケジュールデータに提供されている提供ビットレートについての測定を提供するための方法のステップを実行するように適合化された手段を有してもよい。
【０１５９】
他の一実施例は、一つの保証ビットレートを持ち、そして、一つのユーザ機器によって、一つのコントローリング無線ネットワーク制御装置を介して、個別アップリンクデータチャネル上に送信されている、スケジュールデータに提供されている提供ビットレートについての測定を評価する、一つの移動通信システム内のコントローリング無線ネットワーク制御装置であって、前記移動通信システムのユーザ機器の個々のアップリンクデータ送信が、各々、一つの優先度クラスに関連しているコントローリング無線ネットワーク制御装置に関するものである。
【０１６０】
本発明の本実施例において、前記コントローリング無線ネットワーク制御装置は、前記ユーザ機器によって前記個別アップリンクデータチャネル上に送信されている、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータに提供されている前記提供ビットレートを指示する少なくとも一つの個別測定レポートを受信するための通信手段を有する。前記通信手段は、前記ユーザ機器を制御し、そして、前記コントローリング無線ネットワーク制御装置に接続されている、前記移動通信ネットワークのサービング無線ネットワーク制御装置からの前記少なくとも一つの個別測定レポートを受信するように適合化されていてもよい。
【０１６１】
さらに、前記コントローリング無線ネットワーク制御装置は、前記少なくとも一つの優先度クラスのそれぞれ一つに提供されている、それぞれの提供ビットレートが、前記それぞれの優先度クラスの保証ビットレートよりも低いか否かを評価するための処理手段であって、前記少なくとも一つの優先度クラスに対する、それぞれの提供ビットレートが、前記それぞれの優先度クラスに対する前記保証ビットレートよりも低い場合に、前記それぞれの提供された優先度クラスのデータ送信に対して輻輳制御を実行して、前記個別アップリンクデータチャネルを介して、少なくとも前記保証ビットレートで、前記提供された優先度クラスの前記スケジュールデータを送信することを可能にするか、または、前記アップリンク個別配信チャネルへの、前記それぞれの優先度クラスのデータの前記送信を回避するように適合化されている処理手段を有する。
【０１６２】
本実施例の一変形例において、前記コントローリング無線ネットワーク制御装置は、さらに、上述の本発明の種々の実施例、および、それらの変形例の一つによる、一つの保証ビットレートを持つスケジュールデータに提供されている提供ビットレートについての測定を提供するための方法のステップを実行するように適合化された手段を有してもよい。
【０１６３】
本発明のさらなる一実施例は、ユーザ機器によって、一つのコントローリング無線ネットワーク制御装置を介し、少なくとも一つのノードBを介して、個別アップリンクデータチャネル上に送信されている、少なくとも一つの優先度クラスのスケジュールデータに提供されている提供ビットレートについての測定を評価する、一つの移動通信システム内のコントローリング無線ネットワーク制御装置であって、前記移動通信システムの前記ユーザ機器の個々のアップリンクデータ送信が、各々、一つの優先度クラスに関連しているコントローリング無線ネットワーク制御装置に関するものである。
【０１６４】
このコントローリング無線ネットワーク制御装置は、共通測定レポートを受信するための通信手段であって、各共通測定レポートが、少なくとも一つの保証ビットレート優先度クラスのスケジュールデータに提供されている前記提供ビットレートを指示しており、前記ユーザ機器を制御し、そして、前記コントローリング無線ネットワーク制御装置に接続されている、前記移動通信ネットワークのサービング無線ネットワーク制御装置から、前記少なくとも一つの共通測定レポートを受信するように適合化されている通信手段を有してもよい。
【０１６５】
さらに、前記コントローリング無線ネットワーク制御装置は、前記少なくとも一つの優先度クラスのそれぞれ一つに提供されている、それぞれの提供ビットレートが、前記それぞれの優先度クラスに対する保証ビットレートよりも低いか否かを評価するための処理手段を有してもよい。そのために、前記処理手段は、前記少なくとも一つの優先度クラスに対する、それぞれの提供ビットレートが、前記それぞれの優先度クラスに対する前記保証ビットレートよりも低い場合に、前記それぞれの提供された優先度クラスのデータ送信に対して輻輳制御を実行して、前記個別アップリンクデータチャネルを介して、少なくとも前記保証ビットレートで、前記優先度クラスの前記スケジュールデータを送信することを可能にするか、または、前記ユーザ機器の少なくとも一つに対する前記アップリンク個別配信チャネル上への前記優先度クラスのデータの前記送信を回避するように適合化されていてもよい。
【０１６６】
本実施例の一変形例において、前記コントローリング無線ネットワーク制御装置は、さらに、上述の本発明の種々の実施例、および、それらの変形例の一つによる、一つの保証ビットレートを持つスケジュールデータに提供されている提供ビットレートについての測定を提供するための方法のステップを実行するように適合化された手段を有してもよい。
【０１６７】
本発明の他の一実施例は、一つの移動通信システムにおいて、アップリンクデータチャネル上の、一つの優先度クラスのデータ送信に提供されている提供ビットレートに関する測定に反応して、前記アップリンク個別チャネル上の、前記優先度クラスのスケジュールデータ送信に対して輻輳制御を開始するサービング無線ネットワーク制御装置に関するものである。
【０１６８】
ここでも、前記移動通信システム中のユーザ機器からのアップリンクデータ送信が、各々、一つの優先度クラスに関連している。
【０１６９】
本実施例による、前記サービング無線ネットワーク制御装置は、少なくとも一つのユーザ機器のアクティブセットの少なくとも一つのノードBから、少なくとも一つのユーザ機器によって前記アップリンク個別データチャネル上に送信されていた保証ビットレート優先度クラスのスケジュールデータを受信するための通信手段と、前記少なくとも一つのノードBから、前記保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレート、または、前記サービング無線ネットワーク制御装置における、前記優先度クラスの前記スケジュールデータのマクロダイバーシティコンバイニングの実行後に前記保証ビットレート優先度クラスの前記スケジュールデータに提供されたビットレートを割り出すための処理手段と、を有してもよい。
【０１７０】
前記通信手段は、コントローリング無線ネットワーク制御装置に、前記保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレートを指示する少なくとも一つの個別測定レポートを送信するように、また、前記コントローリング無線ネットワーク制御装置から、前記提供ビットレートが保証ビットレートよりも低い、前記少なくとも一つのユーザ機器によって送信された、スケジュールデータの保証ビットレート優先度クラスを指示する輻輳表示を受信するように、適合化されていてもよい。
【０１７１】
さらに、前記処理手段は、前記指示された保証ビットレート優先度クラスに対して輻輳制御を実行するように適合化されていてもよい。
【０１７２】
本実施例の一変形例において、前記サービング無線ネットワーク制御装置は、さらに、上述の本発明の種々の実施例、および、それらの変形例の一つによる、輻輳制御を開始するための方法のステップを実行するように適合化された手段を有してもよい。
【０１７３】
本発明の一代替実施例は、一つの移動通信システムにおいて、少なくとも一つのアップリンクデータチャネル上の、一つの優先度クラスのデータ送信に提供されている提供ビットレートに関する測定に反応して、前記少なくとも一つの個別アップリンクチャネル上のユーザ機器の、前記優先度クラスのスケジュールデータ送信に対して輻輳制御を開始するサービング無線ネットワーク制御装置であって、前記移動通信システム中のユーザ機器のアップリンクデータ送信が、各々、一つの優先度クラスに関連しているサービング無線ネットワーク制御装置を、予見する。
【０１７４】
前記サービング無線ネットワーク制御装置は、少なくとも一つのノードBから、前記少なくとも一つのノードBのそれぞれ一つに接続された前記ユーザ機器の少なくとも一つによって、前記少なくとも一つの個別アップリンクデータチャネルのそれぞれ一つに送信されていた保証ビットレート優先度クラスのスケジュールデータを受信するための通信手段と、前記少なくとも一つのノードBから、前記保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレート、または、前記サービング無線ネットワーク制御装置における、前記優先度クラスの前記スケジュールデータのマクロダイバーシティコンバイニングの実行後に前記保証ビットレート優先度クラスの前記スケジュールデータに提供されたビットレートを割り出すための処理手段と、を有してもよい。
【０１７５】
前記通信手段は、コントローリング無線ネットワーク制御装置に、前記保証ビットレート優先度クラスの前記スケジュールデータに提供されている前記提供ビットレートを指示する少なくとも一つの共通測定レポートを送信するように、また、前記コントローリング無線ネットワーク制御装置から、前記提供ビットレートが保証ビットレートよりも低いスケジュールデータの保証ビットレート優先度クラスを指示する輻輳表示を受信するように、適合化されていてもよい。
【０１７６】
さらに、前記処理手段は、前記指示された保証ビットレート優先度クラスに対して輻輳制御を実行するように適合化されていてもよい。
【０１７７】
本実施例の一変形例において、前記サービング無線ネットワーク制御装置は、さらに、上述の本発明の種々の実施例、および、それらの変形例の一つによる、輻輳制御を開始するための方法のステップを実行するように適合化された手段を有してもよい。
【図面の簡単な説明】
【０１７８】
【図１】UMTSのハイレベルアーキテクチャを示す。
【図２】UMTS R99/4/5に従うUTRANのアーキテクチャを示す。
【図３】ドリフト無線サブシステムおよびサービング無線サブシステムを示す。
【図４】ユーザ機器におけるMAC−eアーキテクチャを示す。
【図５】ノードBにおけるMAC−eｂアーキテクチャを示す。
【図６】RNCにおけるMAC−eｓアーキテクチャを示す。
【図７】RNCによって構成される例示的なTFCセットを示し、ノードB制御スケジューリングにおけるノードB制御TFCサブセットを例証する。
【図８】RNCにおける並べ替え機能の作動を示す。
【図９】Iur移動性を持たないE−DCHに対する例示的な配信チャネルプロトコルモデルを示す。
【図１０】Iur移動性を持つE−DCHに対する例示的な配信チャネルプロトコルモデルを示す。
【図１１】本発明の一実施例による、一つのユーザ機器の一つ以上の優先度クラスのスケジュールデータについての個別測定をC−RNCに提供するための第1シナリオを示す。
【図１２】本発明の例示的な一実施例による、ノードBからC−RNCに報告する個別測定のメッセージフロー図を示す。
【図１３】本発明の他の例示的な一実施例による、S−RNCからC−RNCに報告する個別測定のメッセージフロー図を示す。
【図１４】本発明の一実施例による、複数のユーザ機器によって送信された一つ以上の優先度クラスのスケジュールデータについての共通測定をC−RNCに提供するための第2シナリオを示す。
【図１５】本発明の他の例示的な一実施例による、SノードBからC−RNCに報告する共通測定のメッセージフロー図を示す。
【図１６】本発明の他の例示的な一実施例による、S−RNCからC−RNCに報告する共通測定のメッセージフロー図を示す。
【図１７】C−RNCによって実行される承認制御に対するデータフローおよびシグナリングフローを示す。
【発明を実施するための形態】
【０１７９】
以下、本発明の種々の実施例について記述する。なお、図において、同等の、または、対応する部分には、同一の参照番号を付して示す。
【０１８０】
以下の実施例は単に実施のための規範とすることを目的としたものであって、そのほとんどは、UMTS通信システムを例にとって概説されている。また、以後のセクションで用いられる用語は、主として、UMTSに関するものである。しかしながら、本発明の原理および考えは、以下の説明における術語およびUMTSアーキテクチャに関連したシステムの記述に制限されるものではない。
【０１８１】
さらに、上記の背景技術のセクションでの詳細な説明は、単に、以下において記述される、ほぼUMTSに特定した例示的な実施例をよりよく理解するためのものであって、本発明は、記述されている特定の移動通信ネットワークにおけるプロセスおよび機能の実施に制限されるものではない。
【０１８２】
以下のパラグラフにおいて、最初に、本明細書においてしばしば用いられる種々の用語について概説する。トラフィッククラスは、RANAPメッセージングにおいてS−RNCに信号で示されるQoS属性である。それは、｛双方向、バックグラウンド、ストリーミング、対話型｝のセットから、任意の値をとることができる。そのセット中の要素は、タイミング要求が厳しくなるにしたがって、順が増すように順序付けられていることに注意されたい。
【０１８３】
論理チャネルは、MACサブレイヤによって、上位（サブ）レイヤに提供されるサービスとして定義される。論理チャネルを、MAC−dフロー上に、MAC−dエンティティによって多重化することができる。そのため、MAC−dフローと論理チャネルとの関係は、「一対多数」の関係とすることができる。本記述のコンテキストでは、MAC−dフローを、データフローと呼ぶこともある。
【０１８４】
通常、論理チャネル毎の並べ替えが行われるので、本質的に、論理チャネル毎に、論理チャネル優先度(MLP)間の一対一対応が存在し、そして、優先度キュー毎に、スケジューリング優先度インジケータ(SPI)が存在する。
【０１８５】
これは、本発明による優先度クラスは、スケジューリング優先度インジケータを参照するということを意味する。スケジューリング優先度インジケータは、ノードBのスケジューリング機能に対する入力パラメータである。このスケジューリング優先度インジケータは、ノードBのスケジューリング機能によってスケジュールされるように、優先度クラスの個々の優先度を示す。したがって、後に明白になるように、本発明は、優先度クラスレベルで提供されたビットレートを測定することを可能にし、また、あらかじめ定められた優先度の優先度クラス毎に、即ち、あらかじめ定められたスケジューリング優先度インジケータまたはスケジューリング優先度クラスを持ち、保証ビットレートを持つ優先度クラス毎に、輻輳制御を実行することができる。
【０１８６】
本発明の一つの態様は、Iubリソースの利用をも最適にするように、保証ビットレートでスケジュールデータのQoS制御のための十分な情報を提供することである。この情報は、C−RNCにおける承認制御および輻輳制御に用いることができる。
【０１８７】
本発明の一実施例によれば、ソフトハンドオーバE−DCH作動中に、ノードBからC−RNCに、スケジュールデータに対する測定を送るための処理が、提供される。UEに関する測定レポートを送るノードBは、UEのアクティブセット内のノードB、または、UEのサービングノードBのサブセットである。それに代えて、個々のUEに対する各ノードBによる提供ビットレートは、S−RNCにおいて割り出されて、S−RNCからC−RNCに送られるのでもよい。
【０１８８】
他の一実施例においては、S−RNCが、マクロダイバーシティコンバイニング(MDC)後の提供ビットレートを測定して、その結果を、C−RNCに送ってもよい。
【０１８９】
本発明の種々の実施例においては、C−RNCに報告する測定に対して以下のオプションがある。ノードBからC−RNCに送信される測定は、共通NBAP処理の一部であってもよい。この場合には、それらは、集合タイプになる。これは、報告が、ある優先度クラスのあるセル内のユーザの全てのスケジュールデータ接続（例えば、MAC−dフロー）に関して行なわれることを意味する。ノードBからC−RNCに送信される測定は、また、個別NBAP処理の一部であってもよい。これは、報告が、各ユーザのスケジュールデータ接続（例えば、MAC−dフロー）に関して個別に行なわれることを意味する。ノードBからC−RNCへの測定と類似して、S−RNCからC−RNCへの測定も、以下において、より詳細に概説するように、共通の、または、個別のRNSAP処理の一部であってもよい。
【０１９０】
さらなる一実施例による本発明の他の一つの態様は、スケジュールデータを維持するためのレイヤ2測定にある。したがって、レイヤ1に対応して、測定は、さらなる詳細に立ち入ることなく、[NBAP] COMMON/DEDICATED MEASUREMENT REPORT（[NBAP]共通／個別測定レポート）メッセージグループの一部として決定されるとみなされる。それらの測定は、RoT資源利用についての十分な情報を提供する。
【０１９１】
本発明の一つの利点は、それが、Iubインターフェイスリソースを最適に用いながら、GBRトラフィックのQoS制御のための情報を、C−RNCに提供するための手段となるということである。
【０１９２】
以下において、本発明の種々の実施例を、図11〜16を参照しながら概説する。
【０１９３】
図11は、本発明の一実施例による、単一のユーザ機器の、一つ以上の優先度クラスのスケジュールデータへの個別測定を、C−RNCに提供するための第1シナリオを示している。UE 1100は、ソフトハンドオーバ状態にあり、そのアクティブセットは、サービングセルのノードB、即ち、サービングノードBであるSノードB 1103、および、ノードB 1104, 1113を有する。ノードB 1103, 1104, 1105は、無線ネットワークサブシステム(RNS)1101の一部であって、C−RNC 1102に接続している。UE 1100は、ソフトハンドオーバ中、E−DCHを介して、ノードB 1103, 1104と通信する。
【０１９４】
さらに、UE 1100は、ノードB 1113を介して、第2のRNS 1111に接続している。ノードB 1113, 1114は、共に、S−RNC 1112に接続している。さらに、S−RNC 1112とC−RNC 1102とは、互いに接続している。
【０１９５】
図12は、本発明の例示的な一実施例による、ノードB 1103, 1104からC−RNC 1102への測定報告のメッセージフロー図を示している。
【０１９６】
ノードBにおける個別リソースの測定の開始を要求するために、個別測定処理が、C−RNC 1102によって用いられる。C−RNC 1102は、それによって、ノードB 1103, 1104の各々に個別測定要求を送信する1201, 1202。この要求には、個別測定が実行されなければならない、ハンドオーバ状態にあるUE 1100の識別子が含まれる。さらに、その要求は、SノードB 1103およびノードB 1104が、報告しなければならない一つ以上の優先度クラスをも示してもよい。
【０１９７】
ハンドオーバ状態にあるUE 1100は、保証ビットレート優先度クラスのスケジュールデータ1203, 1204を、それぞれ、ノードB 1103, 1104に送信する。両ノードB 1103, 1104は、個別測定が実行される各優先度クラスの、それぞれのMAC−dフローに提供されているビットレート1205, 1206を割り出して、その測定された、提供されているビットレート1207, 1208を、個別測定レポートメッセージにおいて、C−RNC 1102に送る。
【０１９８】
これらのメッセージを受信して、C−RNCは、その測定1209を評価することができる。ノードB 1103, 1104のそれぞれ一つによって報告される、保証ビットレート優先度クラスのスケジュールデータの各送信について、C−RNC 1102は、ノードBの一つが、それぞれの優先度クラスのスケジュールデータに、そのスケジュールデータに保証されているビットレート（保証ビットレート）よりも高いビットレートを提供することができるか否かを決定する。ノードB 1103, 1104のいずれもが、スケジュールデータに、十分に高いビットレートを提供することができなければ、C−RNC 1102は、さらに以下により詳細に記述するように、S−RNC 1112に、輻輳制御を行なうように指示する（1210）ことができる。
【０１９９】
さらに、C−RNC 1102は、提供されているビットレートが不十分な速度で報告された、保証ビットレート優先度クラスに、新しいUEを承認しないことを決定することもできる。したがって、C−RNC 1102は、「輻輳した」、保証ビットレート優先度クラスのスケジュールデータをE−DCH上で配信しなければならない無線リンクに対する全ての要求をブロックすることができる。その状態は、実行された輻輳制御メカニズムが、インパクトを与えて、その後の測定レポートにおいて、その優先度クラスのスケジュールデータに対して保証ビットレートが、今や（再び）アップリンクに提供されることを、SノードB 1103および／またはノードB 1104が示すまで続く。
【０２００】
さらに、後者の観点において、ステップ1201, 1202において提供される個別測定要求が、その要求を受信したノードB 1103, 1104が、自分たちの個別測定レポートを、即時的、イベント発動的、または、周期的のいずれで提供すべきであるかを指示していれば、それは、実現可能であろう。個別測定値、即ち、測定された、提供されているビットレートは、Group of the [NBAP] Dedicated Measurement Report message（[NBAP]個別測定レポートメッセージのグループ）に含めることができる。
【０２０１】
即ち、ソフトハンドオーバ作動中の一例として、アクティブセット内のノードBの一つのサブセットしか、報告を行わなくてもよい。
【０２０２】
本発明のさらなる一実施例によれば、測定レポートを送る唯一のノードBが、サービングノードB 1103であってもよい。このネットワーク要素が、アップリンクにおいて、データレートの最上限をセットするであろうからである。
【０２０３】
本発明の一代替実施例においては、UEのアクティブセットの一つのサブセットしか、少なくとも一つの保証ビットレート優先度クラスのUE 1100のスケジュールデータの送信に提供されている提供ビットレートを報告するために選択されなくてもよい。例えば、最良のアップリンクチャネル品質を持つ、アクティブセットのノードBまたはノードBの一つのサブセットが、個別測定レポートを提供するために、C−RNC 1102によって選択されるのでもよい。この場合には、正しく受信されるMAC−e PDUを最も多く持つノードBが、C−RNCに測定レポートを送ることを確実に行わせることができる。
【０２０４】
UEのアクティブセットのノードBの一つのサブセット、または、サービングノードBの、報告のための選択は、例えば、そのサブセットのノードBまたはS−RNC 1103に、[NBAP]DEDICATED MEASUREMENT INITIATION REQUEST message（[NBAP]個別測定開始要求メッセージ）を選択的に送ることによって遂行されるのでもよい。
【０２０５】
図13は、本発明の別の例示的な一実施例による、S−RNC 1112からC−RNC 1102への測定報告のメッセージフロー図を示している。
【０２０６】
この実施例においては、UMTS標準に明記されている[RNSAP]処理が、C−RNC 1102 (DRNC)がS−RNCから個別測定報告を要求することができるという点と、S−RNCがC−RNC (DRNC)に報告することができるという点で、変更されている。
【０２０７】
このために、C−RNC 1102は、S−RNC 1112に、個別測定要求メッセージを送る（1301）。この要求は、S−RNC 1112が報告するべきUE、および、各UEの少なくとも一つの保証ビットレート優先度クラスを有する。
【０２０８】
このために、Group of the [RNSAP] DEDICATED MEASUREMENT INITIATION REQUEST message（[RNSAP]個別測定開始要求メッセージのグループ）としてのDedicated Measurement Type（個別測定タイプ）が、実行される測定の新しいタイプを定め、要求メッセージに加えられる。
【０２０９】
個別測定要求メッセージは、さらに、ノードBのセルID(C−ID)を有してもよい。それらのセルIDは、S−RNC 1112に、そのセルIDによって識別されるノードBのセルを介して受信される、スケジュールデータについて報告するように指示してもよい。そうすると、この手段によって、C−RNC 1102は、この場合にも、SノードB 1103のような、サブセットまたは個々のノードBを指定することができ、したがって、ハンドオーバ中、UEのアクティブセット内の個々に選択された無線セルに対する優先度クラスに基づいて、個別測定を選択的に要求することができる。
【０２１０】
セルIDは、例えば、[RNSAP] DEDICATED MEASUREMENT INITIATION REQUEST message（[RNSAP]個別測定開始要求メッセージ）のCHOICE Dedicated Measurement Object Type Group（選択個別測定オブジェクトタイプグループ）に加えてもよい。
【０２１１】
UE 1100は、保証ビットレート優先度クラスのスケジュールデータを、ノードB 1103および1104を介して、S−RNC 1112に提供する（1302, 1303, 1304, 1305）。S−RNC 1112は、ノードB 1103, 1104のそれぞれ一つによって、保証ビットレート優先度クラスのスケジュールデータに提供されているそれぞれのビットレートを測定して （1306, 1307）、その測定された、提供されているビットレートを、少なくとも一つの個別測定レポートメッセージにおいて、C−RNC 1102に報告する（1308）。
【０２１２】
それに代えて、S−RNC 1112は、また、保証ビットレート優先度クラスのスケジュールデータのマクロダイバーシティコンバイニングを行なうようにしてもよく、マクロダイバーシティコンバイニング(MDC)の後にスケジュールデータに提供されるビットレートを割り出してもよい。しかしながら、この場合には、無線リンク特定の、提供されているビットレートは、C−RNC 1102に対して、利用可能にならず、保証ビットレート優先度クラスのスケジュールデータに対して、E−DCH上に提供される総ビットレートの集合された測定結果しか、利用可能にならない。したがって、C−RNC 1102によって提供される(1301)個別測定要求は、さらに、表示、例えばマクロダイバーシティコンバイニングの前後のどちらの測定がC−RCN 1102によって望まれているのかを指示する、他の必須の情報要素(IE)を有してもよい。
【０２１３】
図12および図13に示されている例示的な実施例において、測定結果を提供するために、個別測定レポートメッセージの内部のDedicated Measurement Type Group（個別測定タイプグループ）の一部としてのIE「E−DCH Provided Bit−rate（E−DCHに提供されているビットレート）」またはIE「E−DCH Provided Bit−rate after MDC（MDC後にE−DCHに提供されているビットレート）」に、提供されているビットレートを含めてもよい。それらのIEの一つの存在は、例えば、S−RNC 1112によって送信される個別測定レポートメッセージにおいて必須であってもよい。例えば、IE「E−DCH Provided Bit−rate（E−DCHに提供されているビットレート）」は、マクロダイバーシティコンバイニングの前に、優先度ごと、UEごと、および、セルごとに提供されているビットレートについての測定を要求するために用いられる。同様に、IE「E−DCH Provided Bit−rate after MDC（MDC後にE−DCHに提供されているビットレート）」は、マクロダイバーシティコンバイニングの後に、優先度ごと、および、UEごとに提供されているビットレートについての測定を要求するために用いられる。
【０２１４】
スケジュールデータに対する、E−DCHに提供されているビットレート値は、測定期間の持続時間で割った、測定期間中に無線インターフェイスを通して送信された、優先度クラスごとのMAC−d PDUビットの総量として定義することができる。この値を計算するときには、肯定された（acknowledged）MAC−e PDUからのビットしか、考慮すべきではない。
【０２１５】
「E−DCH Provided Bit−rate Value Information（E−DCHに提供されているビットレート値情報）」が、E−DCHに提供されているビットレート値を伝えるGroup of the [RNSAP] DEDICATED MEASUREMENT REPORT message（[RNSAP]個別測定レポートメッセージのグループ）であってもよい。そのグループは、DCH MAC−dフローの優先度クラスを識別する、必須な存在であるべきIE「Priority Indication（優先度表示）」を有してもよく、同様に必須な存在であってもよいIE「E−DCH Provided Bit−rate value（E−DCHに提供されているビットレート値）」を有してもよい。
【０２１６】
E−DCHに提供されているビットレート値は、優先度クラスごと、ユーザごと、および、セルごとのGBRトラフィックに対して提供されている総ビットレート、または、マクロダイバーシティコンバイニングの後に、優先度ごと、および、ユーザごとに提供されている総ビットレートを含んでいてもよい。
【０２１７】
C−RNC 1102において測定結果を受信すると、C−RNC 1102は、その測定結果を評価して（1209）、図12を参照して上で概説したように、必要であれば、輻輳制御を実行（1210）することができる。
【０２１８】
図11, 12, 13を参照して上に概説した本発明の種々の実施例に、個々のUEについての個別測定が、例証されている。
【０２１９】
本発明の他の一実施例においては、SノードB 1103が、保証ビットレート優先度クラスに提供されているビットレートを報告するために、C−RNC 1102によって選ばれる。この実施例においては、SノードB 1103は、E−DCHを介して、このそれぞれの優先度クラスのスケジュールデータを送信する、そのセル内の全てのUEについて、個々に、報告してもよい。
【０２２０】
それに代えて、SノードB 1103は、また、複数の保証ビットレートクラスの一つに関連したE−DCH上に、スケジュールデータを送信し、そして、ソフトハンドオーバ中、サービングノードBとしてSノードB 1103を共有する全てのUEについて報告してもよい。上に説明したように、優先度クラスは、また、特定の優先度キューのスケジューリング優先度インジケータと呼んでもよい。したがって、言い換えれば、SノードB 1103は、あらかじめ定められた閾値よりも高い値のスケジューリング優先度インジケータに関連した、保証ビットレート優先度クラスのスケジュールデータを送信するUEのサブセットについて報告してもよい。後者の場合には、保証ビットレートを持つ全てのトラフィッククラスが、高いスケジューリング優先度インジケータに関連していると仮定してもよい。例えば、全ての保証ビットレート優先度クラスが、13よりも大きなスケジューリング優先度インジケータを持ってもよい（通常、スケジューリング優先度インジケータは、1（最低優先度）と15（最高優先度）の間の値である）。
【０２２１】
さらに、C−RNC 1102によって、ノードBまたはS−RNC 1112に送信される個別測定要求は、2つ以上のUEについて報告すべきであること、および／または、各UEに関して、2つ以上の保証ビットレート優先度クラスについて報告すべきであることを指示することも、もちろん、可能であることに注意されたい。
【０２２２】
次に、本発明のさらなる実施例について、図14, 15, 16を参照して検討する。これらの実施例は、主として、少なくとも一つのノードBまたはS−RNCによって実行される共通測定処理の使用に関するものである。これらの測定の結果は、評価のために、C−RNCに提供される。
【０２２３】
図14は、本発明の他の一実施例による、複数のUE1401, 1402, 1403, 1404によって送信された、一つ以上の優先度クラスのスケジュールデータに関する共通測定を、C−RNC 1102に提供するための第2シナリオを示している。UE 1403は、したがって、ソフトハンドオーバ状態にあり、そのアクティブセットは、サービングセルのノードB、即ち、サービングノードBであるSノードB 1103、および、ノードB 1104, 1113を有する。ノードB 1103, 1104, 1105は、無線ネットワークサブシステム(RNS)1101の一部であって、C−RNC 1102に接続している。UE 1403は、ソフトハンドオーバ中、E−DCHを介して、ノードB 1103, 1104と通信する。
【０２２４】
他のUE 1401, 1402, 1404は、E−DCHのような個別アップリンクデータチャネルを介して、ノードB 1103, 1104のそれぞれ一つに、スケジュールデータを提供する。この例示的なシナリオでは、例示的な目的であるため、UE 1401, 1402, 1403, 1404によって送信される、スケジュールアップリンクデータは、全て、同じ優先度クラスにあると仮定する。
【０２２５】
UE 1403は、さらに、ノードB 1113を介して、第2のRNS 1111に接続している。ノードB 1113, 1114は、共に、S−RNC 1112に接続している。さらに、S−RNC 1112とC−RNC 1102とは、互いに接続している。
【０２２６】
図15は、本発明の他の例示的な一実施例による、SノードB 1103からC−RNC 1102への共通測定報告のメッセージフロー図を示している。
【０２２７】
本発明のこの実施例によれば、C−RNC 1102は、SノードB 1103に共通測定要求を送る(1501)ことによって、共通測定処理を開始する。その要求は、SノードB 1103が報告することを要求される、少なくとも一つの保証ビットレート優先度クラスを指示する。上述の個別測定処理に対する概説のように、共通報告においても、即時的、イベント発動的、または、周期的に報告するように構成することができる。
【０２２８】
SノードB 1103によって実行される測定のタイプを定めるために、C−RNC 1102は、その要求の中に、いわゆるCommon Measurement Type（共通測定タイプ）を含めてもよい。Common Measurement Type（共通測定タイプ）は、実行される測定のタイプを定めるGroup of the [NBAP] COMMON MEASUREMENT INITIATION REQUEST message（[NBAP]共通測定開始要求メッセージのグループ）である。E−DCH特定の共通測定に関して、新しいIE「Total E−DCH Provided Bit−rate（E−DCHに提供される総ビットレート）を、Common Measurement Type Group（共通測定タイプグループ）の一部として定めてもよい。このIEの存在は、例えば、必須であってもよい。
【０２２９】
この例示的な実施例の場合には、SノードB 1103しか、SノードB 1103によって制御されているサービングセルの内部の、ある保証ビットレート優先度クラスに提供されているビットレートに関する共通測定を提供するように構成されていない。本発明の一代替実施例においては、2つ以上のノードB、例えば、SノードB 1103、および、ノードB 1104が、それぞれ、SノードB 1103、ノードB 1104によって制御されるセル内の、保証ビットレート優先度クラスに提供されるビットレートに関して報告することも、可能である。
【０２３０】
上述の、これら2つの実施例に関して、少なくとも一つのノードBから、C−RNC 1102への共通測定報告において、その少なくとも一つのノードBが、ソフトハンドオーバ状態にあるUE 1104のアクティブセットの内部にあるノードBであることに気づくことは重要なことである。以下において、より詳細に説明するように、図12の例示的な実施例における、少なくとも一つのノードB、例えば、SノードB 1103によって提供される共通測定レポートは、C−RNC 1102が、その少なくとも一つのノードBによって制御されているセル内の、保証ビットレート優先度クラスのスケジュールデータに提供されているビットレートを割り出すことを可能にする。この情報に基づいて、C−RNC 1102は、要求されたQoS（例えば、保証ビットレートに関する）が、UE 1403のアクティブセットの特定の無線セル（単数であれ、複数であれ）内でかなえられるか否かを決定することができる。「否」であれば、輻輳制御のような適切なアクションが、C−RNC 1102によって開始される。
【０２３１】
ここで、図15に戻ると、UE 1401, 1402, 1403は、保証ビットレート優先度クラスのスケジュールデータを、SノードB 1103に送信する（1502,1503,1504）。SノードB 1103は、共通測定処理を用いて、当該優先度クラスのデータに提供されているビットレートの総計を測定する（1505）。それによって、E−DCH Provided Bit−Rate Information（E−DCHに提供されているビットレート情報）が、SノードB 1103によって決定されて、共通測定レポートに含まれて、C−RNC 1102に送信される（1506）。
【０２３２】
既に上に示したように、スケジュールデータに対するE−DCH Provided Bit−Rate Information（E−DCHに提供されているビットレート情報）は、測定期間の持続時間で割った、測定期間中に無線インターフェイスを通して送信された、保証ビットレート優先度クラスごとのMAC−d PDUビットの総量として定義することができる。肯定された（acknowledged）MAC−e PDUからのビットしか、考慮されない。このE−DCH Provided Bit−Rate Information（E−DCHに提供されているビットレート情報）は、[NBAP] COMMON MEASUREMENT REPORT message（[NBAP]共通測定レポートメッセージ）のTotal E−DCH Provided Bit−rate Value Group（E−DCHに提供されている総ビットレート値グループ）の定義のために用いられる。この定義から明白になるように、個別測定処理は、一つの優先度クラスに提供される個々（即ち、UEごと）のビットレートについて報告し、一方、共通測定は、一つの無線セル内のそれぞれの優先度クラスの、全UEに提供されている総ビットレート、ないし、全ビットレートに関して報告する。
【０２３３】
提供されているビットレートパラメータ値に加えて、SノードB 1103は、また、そのサービングセル内で報告される、保証ビットレート優先度クラスのスケジュールデータを送信する、そのサービングセル内のノイズ上昇に著しく寄与する高コストUEのリストを決定することができる。
【０２３４】
本発明の例示的な一実施例において、この高コストUEのリストを、単一の測定期間中に用いられるTFC統計に基づいて定義することができる。例えば、E−TFC統計を用いて、TTIのN倍の測定期間中におけるUE jのコストを、次式によって定義することができる。
【数１】
2010022019.tif 000007
E−TFCiｍａｘは、最大ビット数を持つ、それぞれのUEのE−TFC (Enhanced−Transport Format Combination) に相当し、一方、Wiは、利得に対応する因子(UEの「ブースティング」モードまたは「ノミナル」モード）を表わしている。
【０２３５】
IE「E−DCH Provided Bit−rate Value（E−DCHに提供されているビットレート値）」グループの値は、レイヤ2測定処理で決定される。しかしながら、このIEを、レイヤ1測定シグナリングに含めることも可能である。
【０２３６】
高コストUEの他の一つの定義を、以下のように選ぶこともできる。「高コスト」UEは、測定間隔中に観察された、個別アップリンク送信においてあらかじめ定められているE−TFC統計が、ある閾値を越えているUEである。単純に、高コストUEは、与えられた無線セルにおけるアップリンクにおいて、ノイズ上昇に著しく寄与するUEであってもよい。
【０２３７】
図12による本発明の例示的な実施例におけるSノードB 1103の共通測定結果は、いわゆるE−DCH Provided Bit−rate Value Information（E−DCHに提供されているビットレート値情報）に含ませてもよい。このE−DCH Provided Bit−rate Value Information（E−DCHに提供されているビットレート値情報）が、Group of the [NBAP] COMMON MEASUREMENT REPORT message（[NBAP]共通測定レポートメッセージのグループ）を定義してもよい。そのグループは、報告されるE−DCH MAC−dフローの優先度クラスを識別するIE「Priority Indication（優先度表示）」、および、上に定義したIE「E−DCH Provided Bit−rate value（E−DCHに提供されているビットレート値）」を有するべきである。これら2つのIEは、例えば、必須であってもよい。
【０２３８】
さらに、そのグループは、報告しているノードBによって制御されているセル内の高コストUEをリストする、任意選択の、または、必須なIE「List of costly UEs（高コストUEのリスト）」を、さらに有してもよい。そのList of costly UEs（高コストUEのリスト）は、上述の、または、類似した式によって求められるように、アップリンク送信によって特に高いRoTを引き起こすUEを有してもよい。List of costly UEs（高コストUEのリスト）に基づいて、C−RNC 1102は、E−DCHに割り付けられているリソースの再構成を開始してもよい。C−RNC 1102に対する別の一つのオプションは、高コストUEに対するMAC−dフロー回避を実行すること、即ち、E−DCHからレガシーアップリンクDCHヘの高コストUEのトラフィックの切り替えであってもよい。高コストUEのリストは、同様に、レイヤ1測定に関連するグループの一部であってもよい。この情報が、下の表に示されている。
【表５】
2010022019.tif 000008
図16は、本発明の他の例示的な一実施例による、S−RNC 1112からC−RNC 1102への共通測定報告のメッセージフロー図を示している。
【０２３９】
共通測定は、S−RNC 1112に共通測定要求メッセージを送る(1601)ことによって、C−RNC 1102によって開始される。S−RNC 1112からの、指定された保証ビットレート優先度クラスのスケジュールデータに提供されているビットレートについての共通測定報告は、[RNSAP] Common Measurement Reporting Procedure（[RNSAP]共通測定報告処理）を用いてもよい。C−RNC 1102は、S−RNC 1112に、[RNSAP] COMMON MEASUREMENT INITIATION REQUEST message（[RNSAP]共通測定開始要求メッセージ）にしたがって、C−RNC 1102によって要求されたとおりに、測定結果を報告するように要求してもよい。
【０２４０】
その要求は、例えば、ソフトハンドオーバ中に、S−RNC 1112が報告すべき優先度クラス、および、UE 1403のアクティブセットの少なくとも一つのノードBを指示してもよい。UE 1401, 1402, 1403は全て、SノードB 1103を介して、S−RNC 1112に、この優先度クラスのスケジュールデータを送信する（ 1502, 1503, 1504, 1602, 1603, 1604）。SノードB 1103は、例えば、図10および図17に例示されているようなE−DCH FPを用いて、S−RNC 1112に、優先度クラスのスケジュールデータを提供してもよい。そうすると、C−RNC 1102からの共通測定要求によって、2つ以上のノードBが、報告するように構成されている場合には、S−RNC 1112は、それぞれのUEによって、また、それぞれのノードBによって送信されたデータを区別することができる。
【０２４１】
C−RNC 1102は、保証ビットレート優先度クラスのデータに対する共通測定レポートを提供しなければならない、UE 1403のアクティブセットの個々のノードB、または、ノードBのサブセットを選択することができる。報告のための、このアクティブセットのノードBのサブセットの選択、または、（図16の例示的な実施例におけるSノードB 1103のような）一つのUEのみの単一のノードBの選択は、[RNSAP] COMMON MEASUREMENT INITIATION REQUEST message（[RNSAP]共通測定開始要求メッセージ）において選択されているノードB（単数または複数の）のそれぞれのCell ID（C−ID：セルID）をリストすることによって行ってもよい。
【０２４２】
ここでも、S−RNC 1112によって実行される測定のタイプを、特定のCommon Measurement Type（共通測定タイプ）において定めてもよい。Common Measurement Type（共通測定タイプ）は、実行される測定のタイプを定めるGroup of the [RNSAP] COMMON MEASUREMENT INITIATION REQUEST message（[RNSAP]共通測定開始要求メッセージのグループ）である。E−DCH特定の共通測定は、Common Measurement Type Group（共通測定タイプグループ）の一部として、新しいIE「Total E−DCH Provided Bit−rate（E−DCHに提供されている総ビットレート」を定めることによって達成してもよい。このIEの存在は、例えば、必須であってもよい。IE「Total E−DCH Provided Bit−rate（E−DCHに提供されている総ビットレート」は、また、優先度クラスごと、および、セルごとのGBRトラフィックに対して提供されている総ビットレートについての測定の要求するために用いてもよい。
【０２４３】
図16に戻って、S−RNC 1112は、SノードB 1103の無線セル内の保証ビットレート優先度クラスのスケジュールデータに提供されているビットレートを割り出すための共通測定処理（1605）を実行してもよい。その測定の結果は、共通測定レポートで、C−RNC 1102に報告される（1606）。図15に示されている本発明の一実施例に関して上に示したように、やはり、この実施例の共通測定結果を、E−DCH Provided Bit−rate Value Information（E−DCHに提供されているビットレート値情報）で提供してもよい。このE−DCH Provided Bit−rate Value Information（E−DCHに提供されているビットレート値情報）が、S−RNC 1112からC−RNC 1102に送信されるGroup of the [RNSAP] COMMON MEASUREMENT REPORT message（[RNSAP]共通測定レポートメッセージのグループ）を特定してもよい。そのグループは、E−DCH MAC−dフローの優先度クラスを識別するためのIE「Priority Indication（優先度表示）」、および、IE「E−DCH Provided Bit−rate value（E−DCHに提供されているビットレート値）」を有するべきである。前に説明したように、これらのIEは、必須であってもよい。さらに、S−RNC 1112からのレポートは、図15に関して上に説明したように、付加的に、任意選択の、または、必須のIE「List of costly UEs（高コストUEのリスト）」も有してもよい。
【０２４４】
上記の実施例においては、個別／共通測定要求は、単に、単一の保証ビットレート優先度クラスだけを指示してもよいことが示されているが、その測定要求は、スケジュールされた、保証ビットレートトラフィックを持つ一連の優先度クラスを有してもよく、または、複数の保証ビットレート優先度クラスが、その要求で識別されて、それぞれを報告するネットワーク要素（単数または複数の）によって報告されてもよいことに注意されたい。さらに、S−RNC 1112がC−RNC 1102に報告する場合に関する実施例においては、報告されるUEまたはUEの一つが、ソフトハンドオーバ状態にあることは必要ではないということに注意されたい。
【０２４５】
次の表は、上に概説した種々の実施例において、C−RNC 1102によって開始される種々の測定のオプションを例示している。
【表６】
2010022019.tif 000009
前のセクションにおいて説明したように、輻輳制御に対する測定報告は、例えば、[NBAP] COMMON/DEDICATED MEASUREMENT REPORT message（[NBAP]共通／個別測定レポート メッセージ）によって行うことができる。C−RNC 1102において、QoS要求が満足に充足されないことが見出されると、C−RNC 1102は、輻輳制御を実行することを決定することができる。UEのE−DCHに割り当てられたノードBの全RoTリソースが、与えられたQoS要求（例えば、保証ビットレート）でMAC−dフローを扱うのに十分であるか否かに応じて、その輻輳制御を行ういくつかの仕方がある。
【０２４６】
ノードBがE−DCHに割り当てることのできる全RoTリソース（maxRoT）が、MAC−dフローを扱うのに不十分である場合には、C−RNC 1102は、MAC−dフロー回避を開始してもよい。これは、例えば、S−RNC 1112に、[RNSAP] RADIO LINK PREEMPTION REQUIRED INDICATION message（[RNSAP]無線リンク回避が必要な表示メッセージ）を送ることによって達成される。そのメッセージをC−RNC 1102から受信した後、S−RNC 1112は、回避されるべきMAC−dフローに関連する論理チャネルに関連する無線ベアラ上のデータの流れを止める。
【０２４７】
E−DCHに割り当てることのできるノードBの全RoTリソース(maxRoT)が、MAC−dフローを扱うのに十分である場合には、C−RNC 1102は、S−RNC 1112に、その状況について通知することができる。例えば、これは、S−RNC 1112に、[RNSAP] RADIO LINK CONGESTION INDICATION message（[RNSAP]無線リンク輻輳表示メッセージ）を送ることによって達成される。この輻輳表示メッセージは、例えば、輻輳制御が実行される、保証ビットレート優先度クラスの表示、例えば、MAC−dフローIDを有してもよい。S−RNCに制御されたE−TFCセットが、十分に高いデータレートを提供すれば、ノードBに制御されたE−DCHリソースを、S−RNC 1112によって、例えば、それぞれのノードBに送信される[NBAP] RADIO LINK RECONFIGURATION REQUEST message（[NBAP]無線リンク再構成要求メッセージ）を用いて、再構成してもよい。このメッセージは、保証ビットレートで、または、より高いビットレートでさえ、優先度クラスのスケジュールデータを提供することが可能になるように、ノードBに制御されたTFCサブセット（図7を参照されたい）を再構成する。
【０２４８】
しかしながら、S−RNCに制御されたE−TFCセットが、十分に高いデータレートを可能にさせなければ、S−RNC 1112は、例えば、[RRC] E−TFC RECONFIGURATION REQUEST message（[RRC]E−TFC再構成要求メッセージ）を送ることによって、それぞれのUEの、RNCに制御されたE−TFCセットを再構成する必要がある。ノードBに制御されたE−DCHリソースは、上で説明したように、その後、[NBAP] RADIO LINK RECONFIGURATION REQUEST message（[NBAP]無線リンク再構成要求メッセージ）によって再構成される。
【０２４９】
輻輳制御の実行に加えて、または、それに代えて、C−RNC 1102は、少なくとも一つのノードBまたはS−RNC 1112から受信された測定結果に基づいて、保証ビットレート優先度クラスのアップリンクトラフィックを伴うサービスに対する承認制御を扱ってもよい。
【０２５０】
C−RNC 1102は、測定レポートを利用して、新規のユーザを承認すべきか否かについて決定してもよい。例えば、共通測定処理において、優先度クラスごとに提供されている総ビットレートが、優先度クラスごとの、既に承認されているユーザに対して必要なビットレート（保証ビットレート）よりも小さければ、C−RNC 1102は、新規のユーザを承認してはならない。
【０２５１】
C-RNC 1102でその後に受信された測定に基づいて提供ビットレートの変化を検出したとき、新規のユーザを承認することが決定される。最新の測定報告は、必要なビットレートがそれぞれの優先度クラスのユーザに提供されてよいことを示す。
【０２５２】
[nbap]測定報告を行なう場合の、C−RNCによる承認制御におけるデータおよびシグナリングフローの一例が、図17に示されている。例えば、C−RNCが、特定の優先度クラスにおいて、新規のユーザを承認しないことを決定してしまうと、そのC−RNCは、ユーザのための新しい無線リンクのセットアップを要求しているS−RNCに、例えば、Radio Link Setup Failure message（無線リンクセットアップ失敗メッセージ）を送ってもよい。
【０２５３】
この点については、特定のE−DCHのRoTは、一定で、ノードBによって規制されることに注意されたい。個々のUEに割り付けられるパワーオフセットのためのビットレートは、例えば、UE E−TFC選択アルゴリズムによって計算することができる。したがって、本発明の一実施例において、送信が考慮されているユーザのGBR属性は、承認制御のためには用いられない。
【０２５４】
以下において、上記の実施例による、ソフトハンドオーバ中のE−DCH作動について、Iub容量の最適化の観点から考察する。報告は、アクティブセット内の特別に選択された単一のノードBによって、または、アクティブセット内のノードBの特別に選択されたサブセットによって行われると仮定する。
【０２５５】
SHO作動中、特定のUE 1100, 1403のアクティブセット内のいくつかのノードBによる測定を、C−RNC 1102が受信するのでもよい。これは、Iub利用の視点からすれば、あまり効率的ではない。したがって、SノードB 1103の命令が、スケジュールデータ送信に提供されるアップリンクビットレートの主な制限因子であることを考えれば、個別測定が、SノードB 1103のみによって実行されるように構成するのが、有利である。
【０２５６】
SノードB選択は、一般に、UEに特定のものであるから、サービングノードBごとの測定報告は、個別タイプの測定においてのみ可能である。もし、測定が、優先度クラスごと、および、同じサービングノードBを持つユーザのグループごとに構成されれば、上に概説したように、共通測定処理を用いる報告を可能にする。一般に、測定によってIub負荷を最適化しようとする場合、SHO作動中のIub負荷の縮小は、報告の精度の低下に対して、トレードオフの関係にある。
【０２５７】
前に説明したように、E−DCHを通る非常に高い優先度のアップリンク接続を持つ幾つかのUEは、非サービングノードBからスケジューリング許諾命令を受け入れることを強いられない。これは、例えば、測定に含まれるIub負荷の最適化のための、さらなるオプションを可能にする。例えば、SノードBによる報告は、報告の精度に何らの低下も伴うことなく、これらの「高優先度」のUEに対して実施することができる。
【０２５８】
さらに、ソフトハンドオーバ作動中におけるIub最適化の他の一つの可能性は、SノードB以外のノードBが、測定を報告する状況に関連する。MAC−e PDUの再送数（RSN = Retransmission Sequence Number：再送シーケンス数）を、E−DCH FPのDATA FRAME（データフレーム）内のそれぞれのMAC−e PDUとともに報告することが、可能である。
【０２５９】
本発明の例示的な一実施例において、RSNフィールド（または、「N of HARQ Retransm（HARQ再送数）」フィールド)が、アクティブセット内のノードBの各々によってS−RNCに送られるDATA FRAME（データフレーム）に含まれること、および、E−DCH FPが、C−RNC 1102で終結することが仮定される。チャネル品質が良好なときは不良なアップリンクチャネル状態のときよりもPDUの所要再送回数が少ないと仮定すると、RSNフィールドは、アクティブセットのノードBのそれぞれの無線セルにおいてソフトハンドオーバ状態にあるUEに対する、アップリンクチャネル品質の表示として解釈することができる。チャネル品質の変動に対処するために、前もって定められた測定期間において報告されたRSNの平均を計算してもよい。そうすると、アクティブセット内の最良のアップリンク品質を持つノードBを、最小の（平均の）RSNを示すノードとして選択することができる。
【０２６０】
この例示的な実施例では、最良のアップリンクチャネル品質を持つノードBを、測定結果を提供すべきノードBとして選択することができる。それに代えて、2つ以上のノードB、例えば、最良のアップリンクチャネル品質を持つ2つまたは3つのノードBを選択することもできる。しかしながら、この操作は、個別測定にしか適用可能ではない。
【０２６１】
本発明の他の一実施例においては、E−DCH FPが、C−RNC 1102で終結しないと仮定する。それは、UEのアクティブセット内の、報告を行うノードBのサブセット／UEのサービングノードが、S−RNC 1112によって決定されることを必要とする。選択されたノードB（サブセット）／選択されたノードB（サービング）に [NBAP] DEDICATED MEASUREMENT INITIATION REQUEST message（[NBAP]個別測定開始要求メッセージ）を送ることによって、測定を開始することができるC−RNC 1102に、対応する表示を送ってもよい。
【０２６２】
保証ビットレート優先度クラスの非スケジュールデータにおいては、輻輳に関する表示だけが、測定を行うノードBから、C−RNC 1102に送られる。優先度クラスの非スケジュールデータに対する輻輳に関する表示を受信して、C−RNC 1102は、E−DCHに、より多くのリソースを割り当てようと試みてもよい。
【０２６３】
サービングノードBは、スケジュールデータに対するRoTの量を内部的に圧縮して、より高い優先度を持つが、より低い遅延とより低いビットレートを要求する、非スケジュールデータに対して、より多くのリソースを解放すると仮定することができる。したがって、非スケジュールデータに対しては、提供されているビットレートの明確な報告は必要ないので、これはインターフェイス上の負荷の縮小に寄与する。
【０２６４】
上記の最後の表に記述したように、共通／個別NBAP/RNSAP測定報告を構成することができる。要求される情報に応じて、一定の構成が、多かれ少なかれ、適切である。
【０２６５】
例えば、サービングノードBの命令にしか従わない、優先度の高いUEに対しては、C−RNCに、MDC後の提供ビットレートを送ることが可能である。提供されているビットレートが、要求されたビットレート（保証ビットレート）よりも低ければ、C−RNCは、SノードBに割り付けられているE−DCHリソースを再構成してもよい。
【０２６６】
他の一例において、C−RNCは、優先度クラスとセルごとの、提供されている総ビットレートについての共通測定、または、優先度クラスとセルとUEごとの、提供されている総ビットレートについての個別測定を観察して、マクロダイバーシティ利得にあまり寄与していないUEのアクティブセット内のノードBを識別しようと試みてもよい。C−RNCは、さらに、それらのノードBに、より多くのリソースを割り付けることを、または、シグナリングによって、それらのノードBをアクティブセットから取り除くことをS−RNCに勧めることを試みてもよい。
【０２６７】
マクロダイバーシティ利得にあまり寄与していないUEのアクティブセット内のノードBを、E−DCH FPのRSNフィールドから導出することもできることに注意されたい。しかしながら、E−DCH FPが、C−RNCで終結していない場合には、RSNフィールドからの情報は、C−RNCにおいて利用可能ではない。この場合には、報告のために選択されたノードBを、S−RNCからC−RNCに信号で伝えてもよく、C−RNCは、それに従って測定を構成することができる。
【０２６８】
最後に、MDCの後の測定報告は、たとえ、E−DCH FPが、C−RNCで終結していたとしても、このネットワーク要素における測定によっては得ることができない重要な情報を、C−RNCに提供するということに注意されたい。MDC後に提供されるビットレートに基づいて、C−RNCは、ノードBにおけるE−DCHリソースを再構成することができる。例えば、提供されているビットレートが、保証ビットレートよりも低ければ、ノードBのE−DCHに割り付けられているRoTの総量を変更してもよい。
【０２６９】
本発明の他の一実施例は、ハードウェアおよびソフトウェアを用いた、上述の種々の実施例の実装に関するものである。上述の種々の論理エンティティおよびモジュールとともに、種々の上述の方法ステップが、例えば、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向けIC(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、または、他のプログラム可能な論理デバイスなどのようなコンピューティングデバイス（プロセッサ）を用いて実装でき、または、実行できることが分かる。本発明の種々の実施例も、これらのデバイスの組み合わせによって実行でき、または、実施できる。
【０２７０】
したがって、例えば、上述の本発明の種々の実施例、および、それらの変形例に記述されているC−RNCおよびS−RNCの作動が、ハードウェアおよび／またはソフトウェアで実行できること、および、それらのネットワーク要素の機能を、コンピュータ読み取り可能な媒体に記憶させておくこともできることが分かる。したがって、本発明の種々の実施例は、また、プロセッサによって、または、ハードウェアで直接に実行されるソフトウェアモジュールを用いて実行することもできる。さらに、ソフトウェアモジュールとハードウェア実装との組み合わせも、可能である。ソフトウェアモジュールは、いかなる種類のコンピュータ読み取り可能な記憶媒体、例えばRAM、EPROM、EEPROM、フラッシュメモリ、メモリカード、レジスタ、ハードディスク、CD−ROM、DVDなどに記憶させておくことができる。
【図１】
2010022019.tif 000010
【図２】
2010022019.tif 000011
【図３】
2010022019.tif 000012
【図４】
2010022019.tif 000013
【図５】
2010022019.tif 000014
【図６】
2010022019.tif 000015
【図７】
2010022019.tif 000016
【図８】
2010022019.tif 000017
【図９】
2010022019.tif 000018
【図１０】
2010022019.tif 000019
【図１１】
2010022019.tif 000020
【図１２】
2010022019.tif 000021
【図１３】
2010022019.tif 000022
【図１４】
2010022019.tif 000023
【図１５】
2010022019.tif 000024
【図１６】
2010022019.tif 000025
【図１７】
2010022019.tif 000026