JP4205371B2

JP4205371B2 - 移動無線システムの処理リソースを管理する方法

Info

Publication number: JP4205371B2
Application number: JP2002187539A
Authority: JP
Inventors: パスカル・アジン
Original assignee: エボリウム・エス・アー・エス
Priority date: 2001-06-29
Filing date: 2002-06-27
Publication date: 2009-01-07
Anticipated expiration: 2022-06-27
Also published as: JP2003060619A; EP1271980A1; FR2826808A1; KR20030003118A; FR2826808B1; US20030008658A1; CN1406010A; US7489933B2

Description

【０００１】
【発明の属する技術分野】
本発明は、一般に、移動無線システムに関し、より詳細には符号分割多元アクセス（ＣＤＭＡ）技術を使用するシステムに関する。
【０００２】
【従来の技術】
ＣＤＭＡ技術は、ＵＭＴＳ（ＵｎｉｖｅｒｓａｌＭｏｂｉｌｅＴｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎＳｙｓｔｅｍ）など、第３世代のシステムにおいて使用される。
【０００３】
通例、移動無線ネットワークは、１組の基地局および基地局コントローラを含む（図１参照）。ＵＭＴＳでは、このネットワークをＵＴＲＡＮ（ＵＭＴＳＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）と呼び、基地局をノードＢと呼び、基地局コントローラを無線ネットワークコントローラ（ＲＮＣ）と呼ぶ。
【０００４】
ＵＴＲＡＮは、Ｕｕインタフェースを介して移動局（ユーザ機器（ＵＥ）とも呼ぶ）と通信し、ｌｕインタフェースを介してコアネットワーク（ＣＮ）と通信する。
【０００５】
図１に示すように、無線ネットワークコントローラは
−ｌｕｂインタフェースを介してノードＢに
−ｌｕｒインタフェースを介して相互に
−ｌｕインタフェースを介してコアネットワークＣＮに接続される。
【０００６】
所与のノードＢを制御する無線ネットワークコントローラを、そのノードＢの制御無線ネットワークコントローラ（ＣＲＮＣ）と呼び、ｌｕｂインタフェースを介してノードＢに接続される。ＣＲＮＣの機能は、制御する各ノードＢの負荷制御と、無線リソースの制御および割付である。
【０００７】
所与のユーザ機器ＵＥに関わる所与の呼のためのサービス無線ネットワークコントローラ（ＳＲＮＣ）は、ｌｕインタフェースを介してコアネットワークＣＮに接続される。ＳＲＮＣは、無線リンクの追加または取消を行う機能（マクロダイバーシティ伝送技術用）、および、ビットレート、電力、拡散率など、通話中に変化する可能性があるパラメータを監視する機能を含む、当該呼に対する制御機能を有する。
【０００８】
ＣＤＭＡシステムでは、無線インタフェースの容量制限が、時分割多重アクセス（ＴｉｍｅＤｉｖｉｓｉｏｎＭｕｌｔｉｐｌｅＡｃｃｅｓｓ、ＴＤＭＡ）技術などの他の多重アクセス技術を使用するシステムの容量制限とは基本的に異なる。ＴＤＭＡ技術は、移動通信のためのグローバルシステム（ＧｌｏｂａｌＳｙｓｔｅｍｆｏｒＭｏｂｉｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ、ＧＳＭ）など、第２世代のシステムにおいて使用される。ＣＤＭＡシステムでは、すべてのユーザが常に同じ周波数リソースを共用する。ソフトにより制限されるシステムとして知られるこれらシステムの容量は、したがって干渉により制限を受ける。
【０００９】
ＣＤＭＡシステムは、品質が低下するのを防ぐために過負荷の防止、検出、および適当な場合には補正を行う負荷制御アルゴリズムや、所与の時間に使用されていないセルの容量が新規コールをそのセルに受け入れるのに十分であるかどうかを（通話に必要なサービスなど、様々なパラメータに応じて）判断するために呼許可制御アルゴリズムなどのアルゴリズムを使用する。ここでは、以下、これらアルゴリズムを総称して負荷制御アルゴリズムと呼ぶ。
【００１０】
一般に、負荷制御アルゴリズムは無線基準のみを適用し、制御対象とするいかなるノードＢの処理容量に関する情報も持っていないＣＲＮＣ中に実装される。そのため、新規の呼が、ＣＲＮＣには受け付けられても、ノードＢの処理リソースの欠如のために最終的には拒絶されるという事態が生じ得る。その結果、ＣＲＮＣにおける不必要な追加処理、およびＣＲＮＣとノードＢ間の追加信号交換が発生する。
【００１１】
このような問題の回避は、容量が最大の状況（きわめて低レベルの干渉にも対応する）を含めた、あらゆる状況をカバーするのに十分な処理リソースを備えたノードＢを提供することによって当然可能である。しかし、そうすることによって基地局のコストが高くなり、ほとんどの場合、必要とされる以上の仕様を有することになる。また、これらのシステムが提供するサービスを漸進的に導入する場合、システムが業務を開始したときには基地局の処理容量が限定され、その後次第に増加させることになる。
【００１２】
したがって、任意のこのようなシステムで負荷を制御する際は、基地局（ノードＢ）の処理容量を考慮することが望ましい。
【００１３】
図２および３は、それぞれ、ＵＭＴＳノードＢなどの基地局で採用されている主な送受信処理を示す。この処理は、当業者にはよく知られているので、本明細書で詳説する必要はない。
【００１４】
図２は、以下を含む送信機１を示す。
−チャネル符号器手段２
−拡散器手段３
−無線周波数送信器手段４
チャネル符号化は、伝送エラーを防ぐために、誤り訂正器符号化およびインターリーブなどの技術を使用する。これは当技術分野で知られている。
【００１５】
符号化（例えば誤り訂正器符号化）は、伝送される情報に冗長性を導入する。符号化率は、伝送しなければならない情報ビット数の、実際に伝送または符号化されるビット数に対する割合として定義される。異なるタイプの誤り訂正器符号を使用して、異なるレベルのサービス品質を得ることができる。例えば、ＵＭＴＳでは、第１のタイプの誤り訂正器符号（ターボ符号）を第１のタイプのトラフィック（高ビットレートデータなど）に使用し、第２のタイプの誤り訂正器符号（畳込み符号）を第２のタイプのトラフィック（より低いビットレートのデータまたは音声など）に使用する。
【００１６】
チャネル符号化は、通常、伝送されるビットレートを伝送に利用可能なビットレートに適合させるためのビットレート適合化をも含む。ビットレート適合化は、繰返しおよび／またはパンクチャリングなどの技術を含むことができ、したがってビットレート適合化率は繰返し率および／またはパンクチャリング率として定義される。
【００１７】
粗ビットレートは、無線インタフェースで実際に伝送されるビットレートとして定義される。純ビットレートは、粗ビットレートからユーザにとって役に立たないものすべて、特に符号化によって導入された冗長性を差し引いた後に得られるビットレートである。
【００１８】
拡散は、当業者に知られているスペクトラム拡散技術を使用する。使用される拡散符号の長さは、拡散率と呼ばれる。
【００１９】
ＵＭＴＳなどのシステムでは、純ビットレート（以下、単にビットレートという）は、同じ通話中に変化することが可能であり、拡散率は、伝送されるビットレートに応じて可変である。
【００２０】
図３は以下をのものを含む受信機５を示す。
−無線周波数受信器手段６
−拡散解除器手段８およびチャネル復号器手段９を含む受信データ評価器手段７
対応する処理も当業者にはよく知られているので、本明細書で詳説する必要はない。
【００２１】
図３は、拡散解除器手段８において実行される処理の例を示す。この場合、処理は、特に環境の特徴から多重反射によって生じるマルチパス現象、すなわち、同じソース信号の複数経路による伝搬、を利用することによって受信データの評価の品質を改善するために、レイク受信機において実行される処理に対応する。ＣＤＭＡシステムでは、ＴＤＭＡシステムとは異なり、受信データの評価の品質を改善するためにマルチパス伝搬を利用することができる。
【００２２】
レイク受信機は、１組のＬフィンガ１０_１から１０_Ｌと、様々なフィンガからの信号を結合する結合器手段１１とを有する。各フィンガは、伝送チャネルのインパルス応答を評価する評価器手段１２が決定する経路の１つを介して受信した信号を拡散解除する。受信データの評価の品質を最適化するために、結合器手段１１は、様々な経路に対応する拡散解除信号を結合する。
【００２３】
レイク受信機を使った受信技術は、マクロダイバーシティ伝送技術と関連させて使用することもでき、同じソース信号が複数の基地局によって同じ移動局に同時に伝送される。マクロダイバーシティ伝送技術は、レイク受信機を使うことによって受信性能を改善するだけでなく、ハンドオーバ中に呼が失われるリスクを最小限に抑える。この技術は、移動局が任意の所与の時間に１つの基地局のみに接続されるハードハンドオーバ技術に対し、ソフトハンドオーバとして知られる。
【００２４】
受信データの評価器手段は、干渉を低減するために様々な技術、例えばマルチユーザ検出技術を使用することもできる。
【００２５】
複数の受信アンテナを使用することも可能である。この場合、受信データの評価器手段は、受信データの評価の品質を最適化するために、様々な受信アンテナを介して得られる信号を結合する結合器手段をさらに含む。
【００２６】
チャネル復号化は、インターリーブ解除および誤り訂正器復号化などの機能を含む。誤り訂正復号器化は、一般に、誤り訂正器符号化よりもはるかに複雑で、例えば最尤復号化などの技術を使用する場合がある。ビタビアルゴリズムは、例えば畳込み符号に使用することができる。
【００２７】
何人かのユーザを同時に処理することができるように、基地局またはノードＢは、前述の送信機および受信機のような１組の送信機および受信機を含む。したがって、基地局またはノードＢは、受信データを評価するために、特に受信側において高処理容量を必要とする。
【００２８】
したがって、前述のように、例えばＵＭＴＳのようなシステムで負荷制御を実行するためには基地局の処理容量を考慮することが望ましい。
【００２９】
ＵＭＴＳの場合、３ＧＰＰ（３^ｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）発行の文献３ＧＴＳ２５．４３３は、ノードＢが、システムにおいて利用可能な拡散率（ＳＦ）の各値について、物理チャネルを割り付けるのに必要なグローバル処理容量（容量クレジット）と容量クレジットの量（割付コスト）を、ＣＲＮＣに通知することを要求している。拡散率の利用可能な諸値に対する１組の割付コストを容量消費法則（ｃａｐａｃｉｔｙｃｏｎｓｕｍｐｔｉｏｎｌａｗ）と呼ぶ。容量クレジットと消費法則の組合せをリソースモデルと呼ぶ。この種の情報は、ノードＢの処理容量が変わる度に、リソースステータス表示メッセージ（ＲｅｓｏｕｒｃｅＳｔａｔｕｓＩｎｄｉｃａｔｉｏｎＭｅｓｓａｇｅ）を使って、またはＣＲＮＣからの要請に応答して監査応答メッセージ（ＡｕｄｉｔＲｅｓｐｏｎｓｅｍｅｓｓａｇｅ）を使って、ノードＢがＣＲＮＣに通知する。
【００３０】
第１の従来技術の特許出願（２０００年８月１０日に本出願人が出願したフランス特許出願第００／１０５３５８号）は、特に次の理由により、この種のソリューションがノードＢの処理容量における制限を考慮するには適さないと指摘している。
−チャネル復号化処理は、粗ビットレートまたは拡散率よりも純ビットレートに左右される。例えば、純ビットレートは、符号化率およびビットレート適合化率に応じて異なる値をとることができ、一般的に、拡散率１２８で５ｋｂｐｓから１５ｋｂｐｓまで可変である（したがって粗ビットレートは３０ｋｂｐｓ）。その結果、固定された拡散率については、ノードＢにおける処理量がかなり変動する（例えば３：１を超える割合で）。これは前述の従来技術のソリューションでは考慮されていない。
−伝送チャネルまたはデータの評価に必要なレイク受信機のフィンガの数は、無線リンクの数に非常に左右される。従来技術のソリューションでは、負荷制御または呼許可制御アルゴリズムなどのノードＢのアルゴリズムは、この種の制限は拡散率に関連しないため、レイク受信機のフィンガの最大数を考慮することはできない。
−ノードＢがＣＲＮＣに通知する処理容量は、ノードＢの処理容量に対する可能な制限を考慮することができないグローバル処理容量である。
【００３１】
前述の第１の従来技術の特許出願では、異なるアプローチを提案している。このアプローチでは、ノードＢの処理容量における可能な制限を考慮するために、ノードＢが、おそらくは各伝送方向および／または使用できる各チャネルタイプについて、設定可能な無線リンクの最大数、設定された無線リンクの最大純ビットレートなど、１つまたは複数のパラメータをＣＲＮＣに通知する。
【００３２】
第２の従来技術の特許出願（２００１年１月１２日に本出願人が出願したフランス特許出願第０１／００４４０号）は、異なるアプローチを提案している。このアプローチでは、グローバル処理容量（容量クレジット）のコンセプトは保持しているが、割付コストは、拡散率の利用可能な各値についてではなく、代わりに、利用可能なビットレートの諸値について通知される（すでに上述したように、ビットレートの方が拡散率よりもむしろノードＢの処理容量をより良く表すことを本出願人は見出した）。
【００３３】
したがって、第２の従来技術の特許出願は、第１のエンティティが、無線リソースと、別の第２のエンティティに提供される対応する処理リソースとを管理する、移動無線システムの処理リソースを管理する方法を開示している。この方法では、
−第２のエンティティが、様々なビットレート値について無線リソースを割り付けるために必要なグローバル処理容量（容量クレジット）とグローバル処理容量の量（割付コスト）を第１のエンティティに対して通知し、
−第１のエンティティが、無線リソースの割付ごとに、容量クレジットを対応するビットレートに応じて更新する。
【００３４】
「無線リソースの割付」という表現には、システムの無線リソースの割付けを修正する可能性があるすべてのオペレーションが含まれ、割付オペレーション自体だけでなく、割付解除および再構成オペレーションも含まれる。
【００３５】
ＵＭＴＳでは、これらのオペレーションは以下に対応する。
−専用トランスポートチャネルの場合は、３ＧＰＰの文献３ＧＴＳ２５．４３３で定義されている、無線リンク設定、無線リンク追加、無線リンク削除、および無線リンク再構成プロシージャ
−共通トランスポートチャネルの場合は、３ＧＰＰの文献３ＧＴＳ２５．４３３で定義されている、共通トランスポートチャネル設定、共通トランスポートチャネル削除、共通トランスポートチャネル再構成プロシージャ
【００３６】
「容量クレジットを更新する」という表現には、新規の無線リソースが必要とされる場合に容量クレジットを差し引くオペレーションだけでなく、新規の無線リソースが必要でなくなり、そのため戻される場合に容量クレジットに追加するオペレーションも含まれるものとする。
【００３７】
したがって、
−容量クレジットは、無線リンク設定、無線リンク追加、および共通トランスポートチャネル設定プロシージャの場合は差し引かれ、
−容量クレジットは、無線リンク削除および共通トランスポートチャネル削除プロシージャの場合は追加され、
−容量クレジットは、無線リンク再構成および共通トランスポートチャネル再構成プロシージャの場合は、新旧ビットレートの割付コストの差が負であるか正であるかによって、差し引かれるか、または追加される。
【００３８】
第２の従来技術の特許出願はまた、次の問題に対するソリューションを提案している。
【００３９】
第１の問題は、利用可能な拡散率の数は有限（例えばＵＭＴＳでは、４、８、１６、３２、６４、１２８、２５６、５１２の８つの拡散率の値が利用可能）であるが、ビットレートはいかなる正の数もとり得ることである。明らかに、ノードＢがあらゆるビットレート値についての割付コストをＣＲＮＣに通知することは実際または現実的には不可能である。
【００４０】
第２の問題は、ＣＲＮＣが、少なくとも現在のバージョンの標準では、リソースの割付ごとに容量クレジットを対応するビットレートに応じて更新するために利用可能なビットレートを有していないことである。これに対して、前述の第１の従来技術のソリューションでは、新規の無線リンクが追加、削除、または再構成されるとＳＲＮＣが拡散率をＣＲＮＣに通知するので、ＣＲＮＣが拡散率を知る。
【００４１】
第３の問題は、ビットレートが固定されるのではなく可変であることである。しかし、拡散率は、少なくともダウンリンク方向の場合は固定される（前述のように、拡散率も通知される）。アップリンク方向の拡散率も可変である。しかし、本出願人は、拡散率を使う前述の従来技術のソリューションでは、問題のこの側面は考慮されていないことを見出した。
【００４２】
第１の問題を解決するために、第２の従来技術の特許出願は、本明細書では以下、参照ビットレートという、ビットレートの２、３の代表的な値だけのコストを通知することを提案し、さらに、参照ビットレートについて通知されたコストから任意のビットレート値のコストを決めるソリューションを提案している。例えば、コストが常に正になるようにしながら、最も単純なソリューションである線形内挿を使用することができる（すなわち、内挿の結果が負であれば、結果としてのコストはゼロになる）。
【００４３】
例えば、ビットレートＲが参照ビットレートではないと、ビットレートＲに最も近い参照ビットレートＲ_ｉｎｆおよびＲ_ｓｕｐ（Ｒ_ｉｎｆ＜Ｒ_ｓｕｐ）に対応するコストＣ_ｉｎｆおよびＣ_ｓｕｐの関数として、Ｃｏｎｓｕｍｐｔｉｏｎ＿ｃｏｓｔが、次式を用いて算出される。
【数１】

【００４４】
その結果が負であれば、割付コストはゼロに設定することができる。すなわち、
Ｃｏｎｓｕｍｐｔｉｏｎ＿ｃｏｓｔ＝０
となる。
【００４５】
他の内挿技法ももちろん使用することができる。
【００４６】
参照ビットレートの例としては、４．７５ｋｂｐｓ、１２．２ｋｂｐｓ、６４ｋｂｐｓ、１４４ｋｂｐｓ、３８４ｋｂｐｓ、および２０４８ｋｂｐｓが挙げられる。
【００４７】
ＵＭＴＳにおける第２および第３の問題を解決するために、例えば、第２の従来技術の特許出願は、ビットレートをトランスポートフォーマットコンビネーションセット（ＴｒａｎｓｐｏｒｔＦｏｒｍａｔＣｏｍｂｉｎａｔｉｏｎＳｅｔ、ＴＦＣＳ）パラメータの関数として導出することを提案している。
【００４８】
ＵＭＴＳの特徴は、同じ接続でいくつかのサービスを移送する、すなわち同じ物理チャネル上にいくつかのトランスポートチャネル（ＴｒＣＨ）を有する機能である。トランスポートチャネルは、チャネル符号化スキーム（図２を参照して説明するように、誤り検出器符号化、誤り訂正器符号化、ビットレート適合化、およびインターリーブを含む）に従って別々に処理された後、時分割多重化され、１つまたは複数の物理チャネル上に伝送される符号化複合トランスポートチャネル（ｃｏｄｅｄｃｏｍｐｏｓｉｔｅｔｒａｎｓｐｏｒｔｃｈａｎｎｅｌ、ＣＣＴｒＣＨ）を形成する。ＵＭＴＳのこれらの側面に関するさらなる情報は、３ＧＰＰの文献３ＧＴＳ２５２１２Ｖ３．０．０に見出すことができる。
【００４９】
ＵＭＴＳの別な特徴は、通話中に、ユーザに対し可変ビットレートを許可することである。トランスポートチャネルによって移送されるデータは伝送時間間隔（ＴＴＩ）と呼ばれる周期で受信されるトランスポートブロックと呼ばれるデータユニットに編成される。所与のトランスポートチャネルに受信されるトランスポートブロックの数およびサイズは、ビットレートに応じて変化する。トランスポートフォーマットは、所与のトランスポートチャネルについて既知のトランスポートブロック数およびサイズ（したがって瞬間的ビットレート）として定義される。トランスポートフォーマットコンビネーション（ＴＦＣ）は、同じコード化複合トランスポートチャネル上に多重化される様々なトランスポートチャネルに許可される、トランスポートフォーマットの組合せとして定義される。最後に、トランスポートフォーマットコンビネーションセット（ＴＦＣＳ）は、トランスポートフォーマットの利用可能な組合せのセットとして定義される。ＵＭＴＳのこれらの側面に関するさらなる情報については、３ＧＰＰの文献ＴＳ２５．３０２Ｖ．３．７．０を参照されたい。
【００５０】
したがって、ＴＦＣＳの各ＴＦＣのビットレートは、次式から算出することができる。
【数２】

【００５１】
式中、ｂｒ_ｊは、ＴＦＣのｊ番目のＴＦＣのビットレートであり、ｎは、ＣＣＴｒＣＨのトランスポートチャネルの数であり、Ｎ_ｋ ^（ｊ）およびＬ_ｋ ^（ｊ）は、それぞれ、ｊ番目のＴＦＣのｋ番目のトランスポートチャネルのトランスポートブロック数およびトランスポートブロックサイズ（単位はビット）であり、また、ＴＴＩ_Ｋは、ｋ番目のトランスポートチャネルの伝送時間間隔（ＴＴＩ）（単位は秒）である。
【００５２】
もちろん他の式も、処理するデータのビットレートがどのように定義されるかに応じて使用することができる。
【００５３】
また、ビットレートが固定されず、可変であり（すなわち、通話中に、ＴＦＣＳの任意のＴＦＣを使用することができる）、この変動をノードＢまたはＵＥが事前に知らない（知ることができない）ことも問題である。最も単純なソリューションは、最大ビットレート、またはＴＦＣＳのすべてのＴＦＣの割付コストを最大限にするビットレートのみを考慮することである（後者のビットレートは、通常、最大ビットレートに等しいが、いつもそうではない）。新規の無線リンクが受け付けられると、ノードＢが、新規無線リンクに対し許可された最大ビットレートまでのビットレートを処理するのに十分なリソースを有しているかどうかを確認する必要がある。
【００５４】
Ｍａｘｉｍｕｍ＿ｂｉｔ＿ｒａｔｅが次式によって定義されるビットレートであるならば、
Ｍａｘｉｍｕｍ＿ｂｉｔ＿ｒａｔｅ＝Ｍａｘ_ｊｂｒ_ｊ（３）
式（１）は、次のようになる。
【数３】

【００５５】
したがって、第２の従来技術の出願に記載の処理リソース管理は下記のパラメータに基づく。これらのパラメータは、専用トランスポートチャネル（ユーザに個別に割り付けられた無線リソースに対応）および共通トランスポートチャネル（何人かのユーザ間で共有される無線リソースに対応）のためにノードＢがＣＲＮＣに対して通知しなければならない。
−ノードＢの処理リソースを定義する総容量（総クレジット）
−代表的参照ビットレートの割付コストを提供し、すべての利用可能なビットレートについて割付コストの決定を可能にする（内挿技法を使用して）消費法則
【００５６】
【発明が解決しようとする課題】
したがって、前述のように、ビットレートに基づくリソースモデルを使用する方が、拡散率に基づくリソースモデルを使用するよりも有利である。しかし、拡散率に基づくリソースモデルを使用するすべての現行の機器が、必ずしもビットレートに基づくリソースモデルを使用するように修正することが可能なわけではない。さらに、将来の機器においては、結局、ビットレートに基づくリソースモデルに加えて拡散率に基づくリソースモデルを使用することもサポートされる可能性がある。その場合、種類が異なる機器の間で、使用するリソースモデルタイプに応じて後方互換性の問題が生じ得る。
【００５７】
本発明の目的は、この新しい問題に対するソリューションを提供することである。
【００５８】
【課題を解決するための手段】
したがって、本発明は、第１のエンティティが別の第２のエンティティに提供された処理リソースを管理する、移動無線システムの処理リソースを管理する方法を提供する。この方法では、
−第２のエンティティが、その処理容量を表すリソースモデルを第１のエンティティに通知し、
−異なるタイプの第１および／または第２のエンティティが提供され、前記処理容量の異なる表示に対応する異なるタイプのリソースモデルをサポートすることが可能であり、第１および第２のエンティティが同じタイプのリソースモデルを使用することを可能にする追加プロトコルが提供される。
【００５９】
本発明の別の特徴によれば、
−新旧のリソースモデルが提供され、
−新旧のエンティティが提供され、新しい第１のエンティティは旧モデルおよび新モデルをサポートし、新しい第２のエンティティは新モデル、または新モデルと旧モデルをサポートし、古い第１または第２のエンティティは旧モデルのみをサポートする。
【００６０】
本発明の別の特徴によれば、前記プロトコルが次のステップを含む。
−新しい第２のエンティティが、モデル自体に加えて使用するモデルタイプを通知し、
−新しい第１のエンティティが、使用するモデルタイプに関する通知を受け取ると、そのモデルタイプを使用する。
【００６１】
本発明の別の特徴によれば、前記追加プロトコルは、さらに、旧モデルおよび新モデルをサポートする新しい第２のエンティティが、これらの２種類のモデルタイプのうち１つをその処理容量を最も良く表すものとして選定する予備ステップをさらに含む。
【００６２】
本発明の別の特徴によれば、前記プロトコルは、さらに、次の予備ステップを含む。
−古い第２のエンティティが、モデル自体に加えて使用するモデルタイプを通知せず、
−使用するモデルタイプに関する信号を受け取らない新しい第１のエンティティが、これを、モデルが古い第２のエンティティによって通知され、したがって通知されたモデルが旧モデルであると解釈する。
【００６３】
本発明の別の特徴によれば、前記追加プロトコルが次のステップを含む。
−古い第１のエンティティが、新モデルをサポートしないことを第２のエンティティに通知し、
−新モデルおよび旧モデルをサポートし、このような通知を受け取る新しい第２のエンティティが、前記古い第１のエンティティに通知するために旧モデルを選定する。
【００６４】
本発明の別の特徴によれば、
−前記旧リソースモデルが拡散率に基づき、
−前記新リソースモデルがビットレートに基づく。
【００６５】
本発明の別の特徴によれば、
−前記第１のエンティティが基地局コントローラであり、
−前記第２のエンティティが基地局である。
【００６６】
本発明は以下のものも提供する。
−基地局（ＵＭＴＳノードＢなど）
−基地局コントローラ（ＵＭＴＳ無線ネットワークコントローラ（ＲＮＣ）など）
−移動無線ネットワーク
−移動無線システム
上記はすべて、本発明による方法を実装する手段を含む。
【００６７】
本発明による他の目的および特徴は、添付の図面を参照しながら説明する以下の本発明の実施形態の説明を読むことにより明らかになろう。
【００６８】
【発明の実施の形態】
したがって、本発明の基本的な目的は、前述のように、異種機器間の後方互換性の問題を解決することである。したがって、本発明は、ＣＲＮＣが、２タイプのリソースモデル、１つが拡散率に基づくモデルでもう１つがビットレートに基づくモデルをサポートするノードＢと共に動作することを可能にし、また、ビットレートに基づくリソースモデルをサポートするＣＲＮＣが、拡散率に基づくリソースモデルをサポートするノードＢと共に動作するすることを可能にする。
【００６９】
したがって、本発明は、第１のエンティティが別の第２のエンティティに提供された処理リソースを管理する、移動無線システムの処理リソースを管理する方法を提供する。この方法では、
−第２のエンティティが、処理容量を表すリソースモデルを第１のエンティティに通知し、
−異なるタイプの第１および／または第２のエンティティが提供され、前記処理容量の異なる表示に対応する異なるタイプのリソースモデルをサポートすることが可能であり、第１および第２のエンティティが同じタイプのリソースモデルを使用することを可能にする追加プロトコルが提供される。
【００７０】
２タイプのリソースモデルが存在することが可能であり、例えばそれぞれを旧モデルおよび新モデルと呼ぶ。
【００７１】
新モデルは、ビットレートに基づくモデルであることが可能で（例えば、前述のフランス特許出願第０１／００４４０号に記載のタイプ）、旧モデルは、拡散率に基づくモデルであることが可能である（例えば、前述の３ＧＰＰの文献３Ｇ
ＴＳ２５．４３３に記載のタイプ）。
【００７２】
以下の説明において、「第１のエンティティ」という表現はＣＲＮＣを指し、「第２のエンティティ」という表現はノードＢを指す。「新しい第１のエンティティ」（新ＣＲＮＣ）という表現は、旧モデルおよび新モデルをサポートするエンティティ（ＣＲＮＣ）を指し、「新しい第２のエンティティ」（新ノードＢ）という表現は、新モデル、または新モデルと旧モデルをサポートするエンティティ（ノードＢ）を指す。「古いエンティティ」（旧ＣＲＮＣまたは旧ノードＢ）という表現は旧モデルのみをサポートするエンティティ（ＣＲＮＣまたはノードＢ）を指す。
【００７３】
追加プロトコルは、例えば、新ノードＢが、モデル自体に追加して使用するモデルタイプを通知することを指定することができる。
【００７４】
したがって、新ＣＲＮＣは、ノードＢが使用するモデルタイプに関する通知を受け取ると、ノードＢと同じモデルタイプを使用することができる。
【００７５】
新モデルと旧モデルをサポートする新ノードＢの場合、使用するモデルタイプは、ノードＢが処理容量をよりよく表すものとしてサポートする２つのモデルタイプのいずれから選定したモデルであっても良い。
【００７６】
新モデルのみをサポートする新ノードＢの場合、使用するモデルタイプは新モデルである。
【００７７】
ノードＢが使用するモデルタイプに関するこの種の信号は、ノードＢからＣＲＮＣに送信される任意のメッセージを使用することができ、好ましくはノードＢアプリケーションパート（ＮＢＡＰ）プロトコルを使用し、さらに好ましくは、ノードＢのリソースモデルに関する情報をすでに移送したメッセージを使用する（例えば、前述のリソースステータス表示または監査応答メッセージ）。
【００７８】
２つの値をとることができる新規フィールドが１つあれば十分なので、比較的わずかな追加信号しか必要とされず、他の修正は必要ではない。これが可能なのは、ここで考えている例では、使用するモデルタイプに関係なく、モデル自体に関する情報が同じ方法で通知される、すなわち、複数のコストがノードＢによってＣＲＮＣに通知され、これらのコストがモデルタイプに応じて参照ビットレートまたは拡散率に（前に指摘したように）リンクされるためである。換言すれば、リソースモデルに関する信号構造は、モデルタイプに関係なく同じであり、好ましくは参照ビットレートの数が拡散率の数と等しくなるように選択されている場合には、ノードＢ／ＣＲＮＣによるリソースモデルの解釈のみがモデルタイプに応じて異なる。
【００７９】
しかし、拡散率よりも数が少ない参照ビットレート有することも可能である。この場合、ビットレートに基づくリソースモデルが選択されるならば、ビットレートに基づくリソースモデルのコストは無視される（この場合、参照ビットレートよりもコストが多くなるため）。拡散率よりも多数の参照ビットレートを有することも可能である。しかし、この場合は、消費法則についての通知を修正しなければならない（新たな通知に追加コストが必要になるため）。
【００８０】
生じ得る様々な状況について前記追加プロトコルの例を以下に記載する。
【００８１】
・新ＣＲＮＣ＋新ノードＢ
この場合は、前の指摘のように、ノードＢは使用中のモデルタイプを通知する。このようにして通知された情報に基づき、ＣＲＮＣは同じモデルタイプを使用することができる（ノードＢが使用するモデルタイプに関連する信号を新ＣＲＮＣがサポートすることがわかっているので）。
【００８２】
・旧ＣＲＮＣ＋旧ノードＢ
この場合は、旧モデルが使用され、追加通知は不必要である。
【００８３】
・新ＣＲＮＣ＋旧ノードＢ
この場合は、ノードＢが旧モデルを使用し、ノードＢが使用するモデルタイプに関する通知は提供されない（この信号を旧ノードＢがサポートしないことがわかっているので）。したがって、新ＣＲＮＣは、このノードＢがこの信号をサポートせず、このノードＢが旧モデルを使用していることを知らせることが出来る（ノードＢが使用するモデルタイプに関する信号を、新ＣＲＮＣがサポートすることがわかっているので）。
【００８４】
・旧ＣＲＮＣ＋新ノードＢ
この場合は、ノードＢがモデルタイプをＣＲＮＣに通知しても、ＣＲＮＣはこの情報を読むことができないので無視し（ノードＢが使用するモデルタイプに関する信号を、旧ＣＲＮＣがサポートしないことがわかっているので）、ノードＢが旧モデルを使用しているかのように動作する。その場合に生じる後方互換性の問題に対する解決策は、ＣＲＮＣがサポートするモデルタイプをノードＢに通知することを、ＣＲＮＣに許可することである（好ましくはＮＢＡＰ信号、例えば呼設定要求メッセージで）。それによって、新ノードＢは旧ＣＲＮＣに新モデルを通知しない（ＣＲＮＣがサポートするモデルタイプに関するこの-を新ノードＢがサポートすることがわかっているので）。
【００８５】
換言すれば、前記追加プロトコルは次のステップを含むことができる。
−図４のステップ１に示すように、新しい第２のエンティティ（新ノードＢ）は、モデル自体に加えて、使用するモデルタイプを通知する。
−図４のステップ２に示すように、新しい第１のエンティティ（新ＣＲＮＣ）は、使用するモデルタイプに関する通知を受け取ると、そのモデルタイプを使用する。
【００８６】
図４のステップ１’に示すように、前記追加プロトコルは、旧モデルおよび新モデルをサポートする新しい第２のエンティティが、これらの２つのモデルタイプうち１つを処理容量を最も良く表すものとして選定する予備ステップをさらに含むことができる。
【００８７】
前記追加プロトコルは、さらに次のステップを含む。
−図５のステップ３に示すように、古い第２のエンティティ（旧ノードＢ）がモデル自体に加えて使用するモデルタイプを通知せず、
−図５のステップ４に示すように、使用するモデルタイプに関する通知を受け取らない新しい第１のエンティティ（新ＣＲＮＣ）が、これをモデルが古い第２のエンティティ（旧ノードＢ）によって通知され、したがって通知されたモデルが旧モデルであると解釈する。
【００８８】
前記追加プロトコルは、さらに次のステップを含む
−図６のステップ５に示すように、古い第１のエンティティ（旧ＣＲＮＣ）が、新モデルをサポートしないことを第２のエンティティに通知し、
−図６のステップ６に示すように、新モデルおよび旧モデルをサポートし、この通知を受け取る新しい第２のエンティティ（新ノードＢ）が、前記古い第１のエンティティ（旧ＣＲＮＣ）に通知するために旧モデルを選定する。
【００８９】
本発明の範囲に逸脱しない他の実施形態も、当然、実施可能である。
【００９０】
さらに、新ノードＢがモデルおよび使用するモデルタイプを通知する実施形態は、より詳細には、モデルタイプに関係なく、モデルに関する信号構造が同じである状況に適用される。これに対する代替（通知に関してはよりコストがかかる）は、両モデルタイプをサポートする新ノードＢがこの２つのモデルを通知することである。旧ＣＲＮＣは、当然、新モデルを無視し、ノードＢが新モデルを使用していることを通知する場合にのみ、新ＣＲＮＣが新モデルを使用する。このソリューションは、それでも、２つのモデルタイプについて同一の通知を行い、従って互いにモデル構造が著しく相異する可能性があるという制約を取り除く。
【００９１】
本発明はまた、以下のものも提供する。
−基地局（ＵＭＴＳノードＢなど）および基地局コントローラ（ＵＭＴＳ無線ネットワークコントローラ（ＲＮＣ）など）
−移動無線通信ネットワーク
−移動無線通信システム
上記はすべて、本発明による方法を実装する手段を含む。
【００９２】
このような手段は前述の方法に従って動作することができ、また、それらの特定の実装は当業者にとっては困難を呈するものではないため、それらの機能を記載する以上に本明細書でさらに詳細に述べる必要はない。
【図面の簡単な説明】
【図１】ＵＭＴＳなどの移動無線システムの一般的なアーキテクチャの略図である。
【図２】ＵＭＴＳノードＢなどの基地局で使用される主な送信処理の略図である。
【図３】ＵＭＴＳノードＢなどの基地局で使用される主な受信処理の略図である。
【図４】本発明による方法の実施形態を説明する図である。
【図５】本発明による方法の実施形態を説明する図である。
【図６】本発明による方法の実施形態を説明する図である。
【符号の説明】
１送信機
２チャネル符号器手段
３拡散器手段
４無線周波数送信器手段
５受信機
６無線周波数受信器手段
７受信データ評価器手段
８拡散解除器手段
９チャネル復号器手段
１０_１、１０_ＬＬフィンガ
１１結合器手段
１２インパルス応答評価器手段

Claims

第１のエンティティが別の第２のエンティティに提供される処理リソースを管理する、移動無線システムの処理リソースを管理する方法であって、
前記第２のエンティティが、その処理容量を表すリソースモデルを前記第１のエンティティに通知し、
異なるタイプの第１および／または第２のエンティティが提供され、前記処理容量の異なる表示に対応する異なるタイプのリソースモデルをサポートすることができ、前記第１および第２のエンティティが同じタイプのリソースモデルを使用することを可能にする追加プロトコルが提供され、
前記異なるタイプのリソースモデルは、新旧のリソースモデルであり、
前記異なるタイプの第１および／または第２のエンティティは、新旧のエンティティであり、
新しい第１のエンティティが前記旧モデルおよび前記新モデルをサポートし、新しい第２のエンティティが前記新モデル、または前記新モデルおよび前記旧モデルをサポートし、古い第１または第２のエンティティが前記旧モデルのみをサポートし、
前記旧リソースモデルが拡散率に基づき、
前記新リソースモデルがビットレートに基づく、方法。
前記追加プロトコルが、
新しい第２のエンティティが、モデル自体に加えて使用するモデルタイプを通知するステップと、
新しい第１のエンティティが、前記使用するモデルタイプに関する通知を受け取ると、そのモデルタイプを使用するステップとを含む請求項１に記載の方法。
前記追加プロトコルが、前記旧モデルおよび前記新モデルをサポートする新しい第２のエンティティが、これらの２種類のモデルタイプのうち１つを選定する予備ステップをさらに含む請求項２に記載の方法。
前記追加プロトコルが、
古い第２のエンティティが、モデル自体に加えて使用するモデルタイプを通知せず、
前記使用するモデルタイプに関する通知を受け取らない新しい第１のエンティティが、これを、前記モデルが古い第２のエンティティによって通知されたものであり、したがって通知された前記モデルが旧モデルであると解釈する予備ステップをさらに含む請求項１に記載の方法。
前記追加プロトコルが、
古い第１のエンティティが、前記新モデルをサポートしないことを第２のエンティティに通知するステップと、
前記新モデルおよび前記旧モデルをサポートし、このような通知を受け取る新しい第２のエンティティが、前記古い第１のエンティティに通知するために旧モデルを選定するステップとを含む請求項１に記載の方法。
前記第１のエンティティが基地局コントローラであり、
前記第２のエンティティが基地局である請求項１に記載の方法。
請求項６に記載の方法で使用する移動無線システムのための基地局コントローラであって、
前記基地局の処理容量を表す前記リソースモデルを前記基地局から受信する手段と、
前記基地局で使用されるのと同じタイプのリソースモデルを使用することを可能にする前記追加プロトコルを実行する手段とを有する、基地局コントローラ。
請求項６に記載の方法で使用する移動無線システムのための基地局であって、
その処理容量を表す前記リソースモデルを前記基地局コントローラに通知する手段と、
前記基地局コントローラで使用されるのと同じタイプのリソースモデルを使用することを可能にする前記追加プロトコルを実行する手段とを有する、基地局。