JP2004525550A - 移動無線通信システムにおける処理リソースの管理方法 - Google Patents

Abstract

移動無線通信システムにおける処理リソースの管理方法であって、第一のエンティティと呼ばれるエンティティが、無線リソースおよび対応する処理リソースを管理し、前記処理リソースが、第二のエンティティと呼ばれる異なるエンティティに設けられ、第二のエンティティが、その全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、第一のエンティティに知らせ、第一のエンティティが、対応するビットレートに応じて無線リソースの各割り当てに関する容量クレジットを更新する。

Description

【技術分野】
【０００１】
本発明は、一般に、移動無線通信システムに関し、特に、ＣＤＭＡ（「Ｃｏｄｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ」符号分割多重接続）技術を用いたシステムに関する。
【背景技術】
【０００２】
ＣＤＭＡ技術は、特にＵＭＴＳシステム（「Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｙｓｔｅｍ」）等の、いわゆる第三世代のシステムで用いられている。
【０００３】
一般に、移動無線通信ネットワークは、図１に示したように、基地局と基地局コントローラとの集合を含む。ＵＭＴＳでは、このネットワークが、ＵＴＲＡＮ（「ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ」）とも呼ばれる。基地局はノードＢとも呼ばれ、基地局コントローラは、ＲＮＣ（「Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ」）とも呼ばれる。
【０００４】
ＵＴＲＡＮは、「Ｕｕ」インターフェースと呼ばれるインターフェースによって、移動局（ユーザ装置または「Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ：ＵＥ」とも呼ばれる）に接続される一方、「ｌｕ」インターフェースと呼ばれるインターフェースによって、ネットワークコアまたはＣＮ（「Ｃｏｒｅ Ｎｅｔｗｏｒｋ」）に接続される。
【０００５】
図１に示したように、ＲＮＣは、「ｌｕｂ」インターフェースと呼ばれるインターフェースによってノードＢに接続され、「ｌｕｒ」インターフェースと呼ばれるインターフェースによって相互接続され、「ｌｕ」インターフェースと呼ばれるインターフェースによってネットワークコアＣＮに接続される。
【０００６】
所定のノードＢに対して、これを制御するＲＮＣは、ＣＲＮＣ（「Ｃｏｎｔｒｏｌｌｉｎｇ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ」）とも呼ばれ、従って、「ｌｕｂ」インターフェースを介してこのノードＢに接続される。ＣＲＮＣは、制御するノードＢに対してロード制御と、無線リソースの制御および割り当てとを行う役割を果たす。
【０００７】
所定のユーザ装置ＵＥに関する所定の通信に対し、ＳＲＮＣ（「Ｓｅｒｖｉｎｇ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｃｏｎｔｒｏｌｌｅｒ」）と呼ばれるＲＮＣが存在し、ＳＲＮＣは、「ｌｕ」インターフェースを介してネットワークコアＣＮに接続される。ＳＲＮＣは、（マクロダイバーシチ伝送技術による）無線リンクの追加機能および取り消し機能を含めた、考慮された通信に対する制御と、ビットレート、パワー、拡散係数など、通信中に変更される可能性のあるパラメータの制御とを行う。
【０００８】
ＣＤＭＡシステムでは、無線インターフェースの容量制限が、特にＴＤＭＡ（「Ｔｉｍｅ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ」時分割多重接続）等の他の多重接続技術を用いたシステムとは根本的に異なる。ＴＤＭＡ技術は、特に、ＧＳＭ（「Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ」）等のいわゆる第二世代のシステムで使用されている。ＣＤＭＡシステムでは、全てのユーザが、絶えず同じ周波数リソースを共有している。従って、これらのシステムの容量は干渉により制限される。そのため、これらのシステムは「ｓｏｆｔ ｌｉｍｉｔｅｄ ｓｙｓｔｅｍｓ」とも呼ばれる。
【０００９】
従って、ＣＤＭＡシステムでは、オーバーロードを未然に防いでこれを検出し、場合によっては修正して品質の劣化を回避する、いわゆるロード制御（「ｌｏａｄ ｃｏｎｔｒｏｌ」）アルゴリズムや、所定の瞬間に使用されていないセルの容量が、（呼に必要なサービス等の各種パラメータに応じて）このセルで新しい呼を受信するのに十分であるかどうか判断する、いわゆる呼許可制御アルゴリズムといったアルゴリズムを規定している。以下、これらの様々なアルゴリズムを、ロード制御という一般表現でまとめて表す。
【００１０】
上記アルゴリズムは、通常、無線基準だけを使用し、一般に、制御するノードＢの処理容量についての情報を持たないＣＲＮＣで使用されている。こうした状況で、たとえばＣＲＮＣが新しい呼を受信し、次いでノードＢの処理リソース不足のために最終的に拒否するような事態になると、ＣＲＮＣでの余分な処理や、ＣＲＮＣとノードＢとの間の余分な信号交換が不必要に発生する。
【００１１】
もちろん、（干渉が非常に低レベルであるケースに対応する）最大容量のケースを含めて、すべてのケースをカバーするのに十分な処理リソースをノードＢに備えることにより、これらの不都合を回避することもできる。しかし、そうすると基地局のコストが上がり、たいていは必要以上の大きさを与えることになってしまう。さらに、これらのシステムが提供するサービスを徐々に導入していく場合、基地局の処理容量がシステムの運転開始時に制限され、その後は徐々に増加していくことがある。
【００１２】
従って、このようなシステムにおけるロード制御のために、基地局（またはノードＢ）の処理容量を考慮することが望ましい。
【００１３】
図２および３は、特にＵＭＴＳシステム用のノードＢなどの基地局でそれぞれ送信および受信時に使用される処理原理を示している。
【００１４】
図２では、送信機１がチャンネル符号化手段２と、拡散手段３と、無線周波数送信手段４とを含む。
【００１５】
このような様々な処理は当業者にとってよく知られているので、ここでは詳しい説明を省く。
【００１６】
知られているように、チャンネル符号化手段は、伝送エラーに対する保護を可能にするエラー修正符号化およびインターリーブ等の技術を使用する。
【００１７】
符号化（エラー修正符号化等）は、伝送情報に冗長性を導入するように構成されている。符号化率は、伝送情報ビット数と、伝送ビット数または符号化ビット数との比として定義される。様々なタイプのエラー修正符号を用いることにより、様々なサービス品質レベルが得られる。たとえばＵＭＴＳでは、（高ビットレートデータ等の）第一のタイプのトラフィックに対し、ターボ符号からなる第一のタイプのエラー修正符号を用い、（もっと低ビットレートのデータまたは音声データ等の）第二のタイプのトラフィックに対し、畳み込み符号からなる第二のタイプのエラー修正符号を用いる。
【００１８】
チャンネル符号化は、また、伝送用に提供されるビットレートに伝送ビットレートを適合させるビットレートマッチングを一般に含む。ビットレートマッチングは、反復技術およびまたはパンクチュアリング技術を含むことが可能であり、その場合、ビットレートマッチング率は、反復率およびまたはパンクチュアリング率として定義される。
【００１９】
未処理のビットレートは、無線インターフェースで実際に伝送されるビットレートとして定義される。ネットビットレートは、特に符号化により導入される冗長性のような、ユーザにとって不要なもの全てを未処理のビットレートから引いた後に得られる。
【００２０】
拡散は、スペクトル拡散の知られている原理を用いる。使用される拡散符号の長さは、拡散係数とも呼ばれる。
【００２１】
特にＵＭＴＳ等のシステムでは、同一通信中にネットビットレート（以下、単に「ビットレート」とする）が変化することがあり、さらに、拡散係数が伝送ビットレートに応じて変化することがある。
【００２２】
図３で示された受信機５は、無線周波数受信手段６と、それ自体が特に逆拡散手段８およびチャンネル復号化手段９を含む受信データ推定手段７とを含む。
【００２３】
こうした様々な処理もまた、当業者にとって知られているので、ここでは詳しい説明を省く。
【００２４】
図３は、逆拡散手段８で使用可能な処理例を示している。この処理は、この場合、Ｒａｋｅタイプの受信機で使用される処理に対応し、環境の様々な要素に対する多数の反射から特に得られるマルチパス現象、すなわち、同一ソース信号がマルチパスに沿って伝播する現象を用いて、受信データの推定品質を改善することができる。ＣＤＭＡシステムでは、特にＴＤＭＡシステムとは異なり、実際にはこれらのマルチパスを用いて、受信データの推定品質を改善することができる。
【００２５】
Ｒａｋｅ受信機は、Ｌ個のフィンガ（「ｆｉｎｇｅｒｓ」）１０_１から１０_Ｌを持つアセンブリと、これらの各フィンガから送られる信号の組み合わせ手段１１とを含む。各フィンガは、考慮された各パスの一つに沿って受信信号を逆拡散可能であり、考慮される各パスは、伝送チャンネルのパルス応答推定手段１２により決定される。手段１１は、受信データの推定品質を最適化する処理に従って、考慮された各パスに対応する逆拡散信号を組み合わせることができる。
【００２６】
Ｒａｋｅ受信機による受信技術は、また、同一のソース信号を複数の基地局から同一の移動局に同時に伝送するマクロダイバーシチ伝送技術と結合しても用いられる。マクロダイバーシチ伝送技術は、Ｒａｋｅ受信機による受信性能を改善するだけでなく、セル間転送時（「ｈａｎｄｏｖｅｒｓ」）の呼損失の恐れを最小化することができる。そのため、この技術は、また、移動局が絶えず一つの基地局に接続される「ｈａｒｄ ｈａｎｄｏｖｅｒ」技術に対して、「ｓｏｆｔ ｈａｎｄｏｖｅｒ」とも呼ばれる。
【００２７】
受信データ推定手段は、さらに、たとえば、いわゆるマルチユーザ検出技術（「ｍｕｌｔｉ−ｕｓｅｒ ｄｅｔｅｃｔｉｏｎ」）等の、様々な干渉低減技術を使用可能である。
【００２８】
また、複数の受信アンテナを使用してもよい。その場合、受信データ推定手段は、受信データの推定品質を同様に最適化するように、こうした様々な受信アンテナで得られる信号の組み合わせ手段をさらに含む。
【００２９】
チャンネル復号化は、逆インターリーブおよびエラー修正復号化等の機能を含む。エラー修正復号化は、一般に、エラー修正符号化よりもはるかに複雑であり、たとえば最大尤度による復号化等の技術を使用可能である。たとえば、畳み込み符号の場合、いわゆるＶｉｔｅｒｂｉアルゴリズムを使用できる。
【００３０】
複数のユーザを同時処理可能にするには、基地局またはノードＢが、送信機および上記受信機等の、送信機と受信機とのアセンブリを含む。かくして、受信データの推定には、基地局またはノードＢで、特に受信時に大容量の処理が必要になる。
【００３１】
従って、先に述べたように、たとえばＵＭＴＳシステム等のシステムでロード制御するには、基地局の処理容量を考慮することが望ましい。
【００３２】
そのため、ＵＭＴＳシステムの場合、３ＧＰＰ（「３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ」）が発表した文献３ＧＴＳ２５．４３３では、ノードＢが、その全体処理容量（「ｃａｐａｃｉｔｙ ｃｒｅｄｉｔ」とも呼ばれる）と、このシステムで可能な拡散係数（「ｓｐｒｅａｄｉｎｇ ｆａｃｔｏｒ：ＳＦ」）の各値に対して物理チャンネルを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、ＣＲＮＣに知らせることが規定されている。
【００３３】
拡散係数の考えられる様々な値に対する割り当てコスト全体は、容量消費則（「ｃａｐａｃｉｔｙ ｃｏｎｓｕｍｐｔｉｏｎ ｌａｗ」）とも呼ばれる。このような情報は、ノードＢの処理容量が変わるたびに、「Ｒｅｓｏｕｒｃｅ Ｓｔａｔｕｓ Ｉｎｄｉｃａｔｉｏｎ」と呼ばれるメッセージを用いて、あるいはＣＲＮＣの要求への応答として「Ａｕｄｉｔ Ｒｅｓｐｏｎｓｅ」と呼ばれるメッセージを用いて、ノードＢがＣＲＮＣに知らせる。
【００３４】
２０００年８月１０日付で本出願人が出願したフランス特許出願第００１０５３８号明細書では、このような解決方法は、ノードＢの処理容量における制限を考慮するのにあまり適していないことが指摘された。これは特に以下の理由による。
【００３５】
チャンネル復号化で行われる処理が、未処理のビットレートよりもむしろネットビットレートに依存し、あるいはまた拡散係数に依存する。たとえば、拡散係数が１２８であるとすると（従って未処理のビットレート３０ｋｂｐｓ）、ネットビットレートは、符号化率とビットレートマッチング率とに応じて様々な値をとることができ、一般に純ビットレートは、５から１５ｋｂｐｓと変化する。その結果、拡散係数が決まっている場合、ノードＢにおける処理量が（たとえば３倍以上に）著しく変化しうる。ところで、この従来の解決方法では、これが考慮されていない。
【００３６】
伝送チャンネルの推定およびデータの推定に必要なＲａｋｅ受信機のフィンガ数は、無線リンク数への依存度が高い。しかし、従来の解決方法では、ノードＢにおけるＲａｋｅ受信機のフィンガの最大数を、ロード制御アルゴリズムまたは呼許可アルゴリズムといったアルゴリズムで考慮していない。何故なら、このタイプの制限が拡散係数に関係しないからである。
【００３７】
ノードＢからＣＲＮＣに知らされる処理容量は、全体の処理容量であり、このノードＢの処理容量で可能な様々な制限を考慮することができない。
【００３８】
従来技術によるこの特許出願では、ノードＢの処理容量で可能な様々な制限を考慮するために、ノードＢが、場合によっては各伝送方向および／または使用されうる各タイプのチャンネル符号化に対して、特に、設定される可能性のある無線リンクの最大数や、設定される無線リンクに対する最大のネットビットレートといった、一つまたは複数のパラメータをＣＲＮＣに知らせる別のアプローチが提案されている。
【発明の開示】
【発明が解決しようとする課題】
【００３９】
本発明は、全体処理容量（すなわち「ｃａｐａｃｉｔｙ ｃｒｅｄｉｔ」）の概念を保持する一方で、拡散係数で可能な各値に対してではなくビットレートで可能な各値に対して割り当てコストを知らせる、新しいアプローチを目的とする（本出願人が指摘し、また既に述べたように、実際には、ビットレートは、拡散係数よりもはるかにノードＢの処理容量を示す）。
【００４０】
しかしながら、このような新しいアプローチは、新たな問題を解決することを前提としている。
【００４１】
第一の問題は、可能な拡散係数の数が有限であるのに（たとえばＵＭＴＳシステムでは、８個の拡散係数の値：４、８、１６、３２、６４、１２８、２５６、５１２が可能である）、ビットレートは、どんな正の値もとりうることにある。ところで、実際には、ノードＢが、全てのビットレート値に対する割り当てコストをＣＲＮＣに知らせるのは不可能であるか、またはあり得ないことが分かっている。
【００４２】
第二の問題は、対応するビットレートに応じた各リソース割り当てにおける容量クレジットの更新のために、少なくとも現状の規格ではＣＲＮＣがビットレートを使用しないことにある。反対に、上記の従来技術による解決方法では、新しい無線リンクを、付加するか、削除するか、あるいは再構成するとき、ＳＲＮＣがＣＲＮＣに拡散係数を知らせるので、ＣＲＮＣは拡散係数を知っている。
【００４３】
第三の問題は、ビットレートが一定ではなく変化する可能性があることにある。反対に、少なくとも下り方向では拡散係数が一定である（前述のように知らせを受ける）。拡散係数は、上り方向では同様に可変であるが、本出願人が指摘しているように、問題のこうした側面は、拡散係数を用いる上記の従来技術による解決方法では考慮されていない。
【００４４】
本発明は、さらに、こうした様々な問題を解決可能にする。
【課題を解決するための手段】
【００４５】
かくして、本発明の目的の一つは、移動無線通信システムにおける処理リソースの管理方法にあり、第一のエンティティと呼ばれるエンティティが、無線リソースおよび対応する処理リソースを管理し、処理リソースが、第二のエンティティと呼ばれる異なるエンティティに設けられ、第二のエンティティが、その全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、第一のエンティティに知らせ、第一のエンティティが、対応するビットレートに応じて無線リソースの各割り当てに関する容量クレジットを更新する。
【００４６】
「無線リソースの割り当て」という表現は、このシステムの内部で無線リソースの割り当てを修正しうるあらゆる操作を包括し、これらの操作は、厳密な意味での割り当て操作を含むだけでなく、逆割り当て操作あるいは再構成操作を含む。
【００４７】
かくして、ＵＭＴＳシステムでは、これらの様々な操作が、専用伝送チャンネルの場合、３ＧＰＰが発行する文献３ＧＴＳ２５．４３３に規定されているように、無線リンクの設定手順、付加手順、削除手順、または再構成手順（「ｒａｄｉｏ ｌｉｎｋ ｓｅｔ−ｕｐ」、「ｒａｄｉｏ ｌｉｎｋ ａｄｄｉｔｉｏｎ」、「ｒａｄｉｏ ｌｉｎｋ ｄｅｌｅｔｉｏｎ」、「ｒａｄｉｏ ｌｉｎｋ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」）に対応し、共通伝送チャンネルの場合、３ＧＰＰが発行する文献３ＧＴＳ２５．４３３に規定されているように、共通チャンネルの設定手順、削除手順、または再構成手順（「ｃｏｍｍｏｎ ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ ｓｅｔ−ｕｐ」、「ｃｏｍｍｏｎ ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ ｄｅｌｅｔｉｏｎ」、「ｃｏｍｍｏｎ ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」）に対応する。
【００４８】
また、容量クレジットの「更新」という表現は、新しい無線リソースが必要となる場合に、この容量クレジットから引き落とす操作と、新しい無線リソースがもはや不要になったので再構成する場合に、容量クレジットに預け入れる操作とを包括する。
【００４９】
従って、「ｒａｄｉｏ ｌｉｎｋ ｓｅｔ−ｕｐ」、「ｒａｄｉｏ ｌｉｎｋ ａｄｄｉｔｉｏｎ」、および「ｃｏｍｍｏｎ ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ ｓｅｔ−ｕｐ」手順では、容量クレジットが引き落とされ、「ｒａｄｉｏ ｌｉｎｋ ｄｅｌｅｔｉｏｎ」および「ｃｏｍｍｏｎ ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ ｄｅｌｅｔｉｏｎ」手順では、容量クレジットを預け入れ、「ｒａｄｉｏ ｌｉｎｋ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」および「ｃｏｍｍｏｎ ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」手順の場合、新しいビットレートおよび元のビットレートに対する割り当てコストの差がマイナスであるかプラスであるかに応じて、容量クレジットを引き落とすか、預け入れる。
【００５０】
別の特徴によれば、前記様々なビットレート値が、基準ビットレートと呼ばれる所定のビットレート値に対応する。
【００５１】
別の特徴によれば、前記対応するビットレートの割り当てコストが、基準ビットレートの割り当てコストから得られる。
【００５２】
別の特徴によれば、前記対応するビットレートの割り当てコストが、基準ビットレートの割り当てコストから補間により得られる。
【００５３】
別の特徴によれば、ビットレートＲが基準ビットレートでない場合、割り当てコスト「Ｃｏｎｓｕｍｐｔｉｏｎ＿ｃｏｓｔ」が、ビットレートＲに最も近い基準ビットレートＲ_ｉｎｆおよびＲ_ｓｕｐ（Ｒ_ｉｎｆ＜Ｒ_ｓｕｐ）に対応する割り当てコストＣ_ｉｎｆおよびＣ_ｓｕｐに応じて、以下の式に従って計算される。
【数１】

【００５４】
別の特徴によれば、補間の成果がなかった場合、割り当てコストをゼロに等しく決定する。
【００５５】
別の特徴によれば、前記対応するビットレートが最大ビットレートに相当する。
【００５６】
別の特徴によれば、前記最大ビットレートが、以下の式によって得られ、
【数２】

このとき、
【数３】

ここで、ｂｒ_ｊは、ＴＦＣＳまたは伝送フォーマットの組み合わせセットにおける、ｊ番目のＴＦＣのビットレート、またはｊ番目の伝送フォーマットの組み合わせであり、ｎは、符号化された同一の複合伝送チャンネルにおける多重化伝送チャンネル数であり、Ｎ_ｋ ^（ｊ）およびＬ_ｋ ^（ｊ）は、それぞれｊ番目のＴＦＣにおけるｋ番目の伝送チャンネルの伝送ブロックの数および伝送ブロックのサイズ（ビット数）であり、ＴＴＩ_ｋは、ｋ番目の伝送チャンネルの伝送時間間隔ＴＴＩ（秒）である。
【００５７】
別の特徴によれば、前記対応するビットレートが有効ビットレートに相当する。
【００５８】
別の特徴によれば、様々な伝送チャンネルまたは様々なタイプの伝送チャンネルに対して、異なる割り当てコストを知らせる。
【００５９】
別の特徴によれば、上りおよび下りの伝送方向に対して、異なる割り当てコストおよび異なる容量クレジットを知らせる。
【００６０】
別の特徴によれば、第一の無線リンクの場合と付加的な無線リンクの場合で、異なる割り当てコストを知らせる。
【００６１】
別の特徴によれば、様々なタイプの処理、特に様々なタイプのチャンネル符号化に対して、異なる割り当てコストを知らせる。
【００６２】
別の特徴によれば、符号化された同一の複合伝送チャンネル内部の様々な多重化伝送チャンネルに対して、異なる割り当てコストを知らせる。
【００６３】
別の特徴によれば、前記システムがＣＤＭＡタイプのシステムである。
【００６４】
別の特徴によれば、前記第一のエンティティが基地局コントローラである。
【００６５】
別の特徴によれば、前記第二のエンティティが基地局である。
【００６６】
本発明の別の目的は、このような方法を実施するための移動無線通信システムにあり、第一のエンティティと呼ばれるエンティティが、無線リソースおよび対応する処理リソースを管理し、前記処理リソースが、第二のエンティティと呼ばれる異なるエンティティに設けられ、このシステムは、主に、第二のエンティティが、第二のエンティティの全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、第一のエンティティに知らせる手段を含み、第一のエンティティが、対応するビットレートに応じて無線リソースの各割り当てに関する容量クレジットを更新する手段を含む。
【００６７】
本発明の別の目的は、このような方法を実施するための移動無線通信システム用の基地局にあり、この基地局は、主に、基地局の全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを基地局コントローラに知らせる手段を含む。
【００６８】
本発明の別の目的は、このような方法を実施するための移動無線通信システム用の基地局コントローラにあり、この基地局コントローラが、主に、基地局の全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを基地局から受信する手段と、対応するビットレートに応じて、無線リソースの各割り当てに関する容量クレジットを更新する手段とを含む。
【００６９】
本発明の他の目的および特徴は、添付図面に関してなされた実施形態の以下の説明を読めば明らかになるであろう。
【発明を実施するための最良の形態】
【００７０】
かくして、本発明の目的の一つは、移動無線通信システムにおける処理リソースの管理方法にあり、第一のエンティティと呼ばれるエンティティ（特にＵＭＴＳシステム等のシステムにおける基地局コントローラまたはＣＲＮＣ）が、無線リソースおよび対応する処理リソースを管理し、処理リソースが、第二のエンティティと呼ばれる異なるエンティティ（特にＵＭＴＳシステム等のシステムにおける基地局またはノードＢ）に設けられ、第二のエンティティが、その全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを第一のエンティティに知らせ、第一のエンティティが、対応するビットレートに応じて無線リソースの各割り当てに関する容量クレジットを更新する。
【００７１】
言い換えると、本発明によれば、全体処理容量（すなわち「ｃａｐａｃｉｔｙ ｃｒｅｄｉｔ」）の概念を保持する一方で、拡散係数で可能な各値に対してではなくビットレートで可能な各値に対して割り当てコストを知らせる（本出願人が指摘し、また既に述べてもいるように、実際には、ビットレートは拡散係数よりもはるかにノードＢの処理容量を示す）。
【００７２】
さらに、上記の第一の問題を解決するために、以下、基準ビットレートと呼ぶ幾つかの代表的なビットレート値に対してのみ、コストを知らせることを提案し、基準ビットレートに対して知らされたコストから、全てのビットレート値のコストを決定する解決方法をさらに提案する。たとえば、コストが常にプラスになるようにしながら（すなわち補間の成果がなくても結果として得られるコストが常にゼロに等しくなるようにする）、線形補間を用いることができる（これは、最も簡単な解決方法である）。
【００７３】
たとえば、ビットレートＲが基準ビットレートでない場合、割り当てコスト「Ｃｏｎｓｕｍｐｔｉｏｎ＿ｃｏｓｔ」が、ビットレートＲに最も近い基準ビットレートＲ_ｉｎｆおよびＲ_ｓｕｐ（Ｒ_ｉｎｆ＜Ｒ_ｓｕｐ）に対応する割り当てコストＣ_ｉｎｆおよびＣ_ｓｕｐに応じて、以下の式に従って計算される。
【数４】

【００７４】
成果がない場合、割り当てコストをゼロに決定することができ、すなわち、Ｃｏｎｓｕｍｐｔｉｏｎ＿ｃｏｓｔ＝０である。
【００７５】
もちろん、他の補間技術を使用してもよい。
【００７６】
さらに、基準ビットレートの例としては、たとえば４．７５ｋｂｐｓ、１２．２ｋｂｐｓ、６４ｋｂｐｓ、１４４ｋｂｐｓ、３８４ｋｂｐｓ、２０４８ｋｂｐｓの値を挙げられる。
【００７７】
その上、たとえばＵＭＴＳシステム等のシステムで上記の第二、第三の問題を解決するために、一つの解決方法は、ＴＦＣＳ（「Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ Ｃｏｍｂｉｎａｔｉｏｎ Ｓｅｔ」）と呼ばれるパラメータに応じてビットレートを導き出すことである。
【００７８】
ＵＭＴＳ等のシステムの一つの特徴が、同一の接続で複数のサービスを伝送し、すなわち、同一の物理チャンネルで複数の伝送チャンネルを伝送する可能性であることに改めて言及する。このような伝送チャンネル（またはＴｒＣＨ「Ｔｒａｎｓｐｏｒｔ Ｃｈａｎｎｅｌｓ」）は、（図２に関して説明したように、エラー検出符号化、エラー修正符号化、ビットレートマッチング、およびインターリーブを含む）チャンネル符号化構成に従って別々に処理されてから、時間分割多重化され、一つまたは複数の物理チャンネルで伝送される符号化複合伝送チャンネル（またはＣＣＴｒＣＨ「Ｃｏｄｅｄ Ｃｏｍｐｏｓｉｔｅ Ｔｒａｎｓｐｏｒｔ Ｃｈａｎｎｅｌ」）を形成する。ＵＭＴＳのこうした側面に関するさらに詳しい情報については、３ＧＰＰが発行した文献３ＧＴＳ２５２１２Ｖ３．０．０を参照することができる。
【００７９】
また、ＵＭＴＳ等のシステムの別の特徴は、通信中、ユーザのために可変ビットレートを可能にすることにある。伝送チャンネルにより伝送されるデータは、伝送ブロック（「Ｔｒａｎｓｐｏｒｔ Ｂｌｏｃｋｓ」）と呼ばれるデータユニットとして組織され、伝送時間間隔（またはＴＴＩ「Ｔｒａｎｓｍｉｓｓｉｏｎ Ｔｉｍｅ Ｉｎｔｅｒｖａｌ」）と呼ばれる周期性を伴って受信される。所定の伝送チャンネルに対して受信する伝送ブロックの数およびサイズは、ビットレートに応じて変化するので、所定の伝送チャンネルの場合、これらの伝送ブロックの数およびサイズを認識したもの（従って瞬間ビットレート）として、伝送フォーマットの概念を定義する。また、伝送フォーマットの組み合わせ（またはＴＦＣ「Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ Ｃｏｍｂｉｎａｔｉｏｎ」）の概念を、同一の符号化複合伝送チャンネルに従って多重化されるように構成された、様々な伝送チャンネルに許可される伝送フォーマットの組み合わせとして定義する。さらに、伝送フォーマットの組み合わせセット（またはＴＦＣＳ「Ｔｒａｎｓｐｏｒｔ Ｆｏｒｍａｔ Ｃｏｍｂｉｎａｔｉｏｎ Ｓｅｔ」）の概念を、伝送フォーマットで可能なこうした組み合わせのセットとして定義する。ＵＭＴＳのこれらの特徴に関する詳しい情報については、３ＧＰＰが発行する文献ＴＳ２５．３０２Ｖ３．７．０を参照することができる。
【００８０】
その場合、ＴＦＣＳ内部の各ＴＦＣのビットレートは、以下の式によって計算され、
【数５】

ここで、ｂｒ_ｊは、ＴＦＣＳにおけるｊ番目のＴＦＣのビットレートであり、ｎは、ＣＣＴｒＣｈにおける伝送チャンネル数であり、Ｎ_ｋ ^（ｊ）およびＬ_ｋ ^（ｊ）は、それぞれｊ番目のＴＦＣにおけるｋ番目の伝送チャンネルの伝送ブロックの数および伝送ブロックのサイズ（ビット数）であり、ＴＴＩ_ｋは、ｋ番目の伝送チャンネルの伝送時間間隔またはＴＴＩ（秒）である。
【００８１】
もちろん、処理データのビットレートを定義する方法に応じて、他の式を使用することもできる。
【００８２】
さらに、問題は、ビットレートが一定ではなく可変であることにあり（すなわち、通信中、ＴＦＣＳの内部でどのＴＦＣも使用可能である）、この変化は、ノードＢまたはＵＥからは基本的に分からず、予め知ることができない。最も簡単な解決方法は、ＴＦＣＳ内部にある全てのＴＦＣの中で、最大ビットレートまたは、割り当てコストを最大にするビットレート（このビットレートは、一般に最大ビットレートに等しいが常にそうであるというわけではない）だけを考慮することにある。実際、新しい無線リンクを受け入れる場合、この新しい無線リンクに許可された最大ビットレートまで処理を行うのに十分なリソースを、ノードＢが持っているかどうか検証することが必要である。
【００８３】
ビットレートを「Ｍａｘｉｍｕｍ＿ｂｉｔ＿ｒａｔｅ」と記して以下の式により定義する。
【数６】

【００８４】
その場合、式（１）は、次のようになる。
【数７】

【００８５】
従って、このような処理リソースの管理は、（無線リソースがユーザに個々に割り当てられるケースに対応する）専用伝送チャンネルの場合も、（無線リソースが複数のユーザ間で共有されるケースに対応する）共通伝送チャンネルの場合も、以下のパラメータに基づいており、ノードＢは、これらのパラメータをＣＲＮＣに知らせる必要がある。
【００８６】
ノードＢの処理リソースを定義する全体容量（または全体クレジット）。
【００８７】
代表的な基準ビットレートに対して割り当てコストを与え、可能な全てのビットレートに対して（補間技術により）割り当てコストを見つけることができる消費則。
【００８８】
このため、規格に規定された２個の信号メッセージを特に用いることができる。このメッセージは、ノードＢの処理リソースが代わるたびにノードＢからＣＲＮＣに送られる、「Ｒｅｓｓｏｕｒｃｅ Ｓｔａｔｕｓ Ｉｎｄｉｃａｔｉｏｎ」と呼ばれるか、またはＲＮＣの要求に対する応答としてＣＲＮＣから送られる「ａｕｄｉｔ ｒｅｓｐｏｎｓｅ」と呼ばれる。
【００８９】
その場合、ＣＲＮＣは、リソース割り当てのたびに残りのクレジットを更新し、すなわちＵＭＴＳシステムでは、専用伝送チャンネルの場合、３ＧＰＰが発行する文献３ＧＴＳ２５．４３３に規定されているように、無線リンクの設定手順、付加手順、削除手順、または再構成手順（「ｒａｄｉｏ ｌｉｎｋ ｓｅｔ−ｕｐ」、「ｒａｄｉｏ ｌｉｎｋ ａｄｄｉｔｉｏｎ」、「ｒａｄｉｏ ｌｉｎｋ ｄｅｌｅｔｉｏｎ」、「ｒａｄｉｏ ｌｉｎｋ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」）の際に、共通伝送チャンネルの場合、３ＧＰＰが発行する文献３ＧＴＳ２５．４３３に規定されているように、共通チャンネルの設定手順、削除手順、または再構成手順（「ｃｏｍｍｏｎ ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ ｓｅｔ−ｕｐ」、「ｃｏｍｍｏｎ ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ ｄｅｌｅｔｉｏｎ」、「ｃｏｍｍｏｎ ｔｒａｎｓｐｏｒｔ ｃｈａｎｎｅｌ ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ」）の際に更新を行う。
【００９０】
規格３ＧＴＳ２５．４３３では、一つが専用チャンネル用で一つが共通チャンネル用の、異なる二つの消費則が定義されている。そのため、ＵＭＴＳシステムでは、専用チャンネルのための消費則が、ＤＣＨ（「Ｄｅｄｉｃａｔｅｄ ＣＨａｎｎｅｌ」）およびＤＳＣＨ（「Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ ＣＨａｎｎｅｌ」）に適用され、共通チャンネルのための消費則が、特にＲＡＣＨ（「Ｒａｎｄｏｍ Ａｃｃｅｓｓ ＣＨａｎｎｅｌ」）、ＦＡＣＨ（「Ｆｏｒｗａｒｄ Ａｃｃｅｓｓ ＣＨａｎｎｅｌ」）、ＣＰＣＨ（「Ｃｏｍｍｏｎ Ｐａｃｋｅｔ ＣＨａｎｎｅｌ」）、ＳＣＣＰＣＨ（「Ｓｅｃｏｎｄａｒｙ Ｃｏｍｍｏｎ Ｃｏｎｔｒｏｌ Ｐｈｙｓｉｃａｌ ＣＨａｎｎｅｌ」）等のチャンネルに適用される。
【００９１】
専用チャンネルのための消費則は、また、ＤＳＣＨチャンネルにも適用される。何故なら、このチャンネルは、実際には共通チャンネルであるものの常にＤＣＨチャンネルに結合され、ＤＳＣＨチャンネルに関与する設定手順、削除手順、または再構成手順が、同時にＤＣＨチャンネルに関与するからである。たとえば、「ｒａｄｉｏ ｌｉｎｋ ｓｅｔｕｐ」操作の場合、ＤＳＣＨチャンネルがＤＣＨチャンネルに結合されているときは、ＤＣＨチャンネルに対して一つと、場合によってはＤＳＣＨチャンネルに対して一つの、一つまたは二つの操作を実施可能である。
【００９２】
さらに、この方法は、（上りおよび下りの）二つの伝送方向に対して全体として実施してもよいし、あるいは伝送方向ごとに実施してもよい（上り方向および下り方向を別々に処理する）。この場合、全体クレジットは各方向に対して与えられ、割り当てコストは、各基準ビットレートおよび各方向に対して与えられる。
【００９３】
しかも、専用チャンネルの場合、考慮された無線リンクが第一のリンクであるかないかに応じて、異なる割り当てコストを特定できる（第一のリンクでない場合は、ＵＥが同じノードＢに１個以上の無線リンクを持つ状況に対応し、すなわちＵＥは、このノードＢといわゆる「ｓｏｆｔｅｒ−ｈａｎｄｏｖｅｒ」状況にある）。その場合、対応する割り当てコストを、「第一の無線リンクのためのコスト」および「付加的な無線リンクのためのコスト」と呼ぶことができる。
【００９４】
しかしながら、「ｓｏｆｔ−ｈａｎｄｏｖｅｒ」または「ｓｏｆｔｅｒ−ｈａｎｄｏｖｅｒ」技術は、ＤＳＣＨチャンネルでは使用不能であるので、「第一の無線リンクのためのコスト」が、常にＤＳＣＨチャンネルのケースに適用される（ＤＣＨチャンネルの場合、第一の無線リンクのためのコストまたは付加的な無線リンクのためのコストが適用できる）。もう一つ別の可能性は（有効性は劣るが）、ＤＣＨチャンネルのために考慮された無線リンクが第一のリンクではないとき、ＤＣＨチャンネルおよびＤＳＣＨチャンネルに「付加的な無線リンクのためのコスト」を適用することである（そうでない場合は、二つのチャンネルに対して「第一の無線リンクのためのコスト」を適用する）。
【００９５】
一定の物理チャンネルまたは伝送チャンネルの場合、（たとえＴＦＣＳが存在する場合でも）ビットレートまたは拡散係数に依存せず、場合によってはゼロであるが、たとえば（上りおよび下り）伝送方向などの別のパラメータに依存しうる、一定コストを持つようにすることも可能である。
【００９６】
たとえば、ＡＩＣＨ（「Ａｃｑｕｉｓｉｔｉｏｎ Ｉｎｄｉｃａｔｉｏｎ Ｃｈａｎｎｅｌ」）、またはＡＰ−ＡＩＣＨ、またはＣＤ／ＣＡ−ＩＣＨ（「Ｃｏｌｌｉｓｉｏｎ Ｄｅｔｅｃｔｉｏｎ／Ｃｈａｎｎｅｌ Ａｓｓｉｇｎｍｅｎｔ Ｉｎｄｉｃａｔｏｒ Ｃｈａｎｎｅｌ」）、あるいはまたＣＳＩＣＨ（「ＣＰＣＨ Ｓｔａｔｕｓ Ｉｎｄｉｃａｔｉｏｎ Ｃｈａｎｎｅｌ」）等の物理チャンネルのための特別なコストを知らせることができる。
【００９７】
他の弁別手段を付加してもよい。たとえば、処理タイプ、特にチャンネル符号タイプに応じて（たとえばＵＭＴＳシステムでは、畳み込み符号を用いるかターボ符号を用いるかに応じて）、異なる割り当てコストを特定できる。
【００９８】
さらに、上記の解決方法の例は、最大ビットレートだけを考慮することからなり、簡単ではあるが、最大ビットレートに対応する処理リソースが毎回割り当てられるので、このようにノードＢに確保された処理リソースがおそらくは過大に推定されるという不都合がある。その場合、クレジットは空なのに、幾つかの処理リソースがまだ利用可能であるといったことが発生しうる。すると、十分な処理リソースがノードＢで利用できるのに、新しい無線リンクまたは共通伝送チャンネルの要求が拒絶されることがある。
【００９９】
こうした不都合を回避する一つの解決方法は、ＣＲＮＣが、最大ビットレートを基にしてではなく、有効ビットレートを基にして残りのクレジットを計算することにある。有効ビットレートは、上記のように現行のＴＦＣから分かる。この場合、常に同じ情報がノードＢからＣＲＮＣに知らされ、ＣＲＮＣにインプリメントされる残りのクレジットの更新アルゴリズムだけが変わる。その場合には、このクレジットの更新が、頻繁に（ＴＦＣが変わるたびに）必要になる。
【０１００】
専用チャンネル（ＤＣＨ）の場合、このような解決方法の実施に際しての問題は、呼許可制御が、（規格の現状では）瞬間的にＴＦＣからは分からないＣＲＮＣにインプリメントされることにある（ＣＲＮＣはＴＦＣＳだけから分かり、ＴＦＣはＵＥ、ノードＢ、およびＳＲＮＣから分かる）。しかしながら、適切な信号により、またはこの情報を知っているエンティティに、呼許可制御がインプリメントされれば、こうした解決方法を適用できる。
【０１０１】
共通伝送チャンネル（ＤＳＣＨを含む）の場合、（共通チャンネルおよび共用チャンネルに対してＴＦＣを選択する）ＭＡＣ−ｃ／ｓｈ関数が、ＣＲＮＣにインプリメントされるので、こうした解決方法を（上り方向でも下り方向でも）規格の現状に適用できるように思われる。
【０１０２】
さらに、上記の解決方法の例の別の不都合は、複数の伝送チャンネルが、一つの物理チャンネルで多重化されて同じ処理リソースを必要としない場合（たとえば一方は畳み込み符号を用い、他方はターボ符号を用いる）、２個の伝送チャンネルが異なる処理リソースを必要としていることを考慮せずに、全体のビットレートに応じてコストが選択されることにある。
【０１０３】
この不都合を回避するため、一つの解決方法は、ビットレートごと、および伝送チャンネルごとに割り当てコストを知らせ、全ての伝送チャンネルの全体コストを、伝送チャンネルのタイプに応じてＣＲＮＣが計算するというものである。このような解決方法は、様々な伝送チャンネルを区別可能にするので、異なる特性を持つ伝送チャンネルに対して様々な割り当てコストをもつようにすることができる。前述のように、割り当てコストは、考慮される伝送チャンネルの最大ビットレート（ＴＦＣＳによって与えられる）か、または有効ビットレート（現行のＴＦＣによって与えられる）に基づくことができる。
【０１０４】
図４は、本発明による方法を実施するために、基地局（またはＵＭＴＳシステム等のシステムにおけるノードＢ）と、基地局コントローラ（またはＵＭＴＳシステム等のシステム用のＲＮＣ）とに、本発明により設けられる手段の一例を示す図である。
【０１０５】
かくして、ノードＢと記された基地局は、（従来の手段とすることも可能な他の手段に加えて）、全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、基地局コントローラに知らせる手段１３を含む。
【０１０６】
そのため、基地局コントローラＲＮＣは、（従来の手段とすることも可能な他の手段に加えて）、全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、基地局から受信する手段１４と、対応するビットレートに応じて、各無線リソース割り当てに関する容量クレジットを更新する手段１５とを含む。
【０１０７】
こうした様々な手段は、上記の方法に従って操作可能である。それらを個々に実施することは当業者にとって特別に難しいものではなく、このような手段についてはその機能以外の詳しい説明を省く。
【図面の簡単な説明】
【０１０８】
【図１】特にＵＭＴＳシステム等の移動無線通信システムの全体のアーキテクチャを示す図である。
【図２】ＵＭＴＳシステムのノードＢ等の基地局で送信時に用いられる主要処理を示す図である。
【図３】ＵＭＴＳシステムのノードＢ等の基地局で受信時に用いられる主要処理を示す図である。
【図４】本発明による方法の実施の例を示す図である。

Claims (20)

1. 移動無線通信システムにおける処理リソースの管理方法であって、第一のエンティティと呼ばれるエンティティが、無線リソースおよび対応する処理リソースを管理し、前記処理リソースが、第二のエンティティと呼ばれる異なるエンティティに設けられ、
   第二のエンティティが、第二のエンティティの全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、第一のエンティティに知らせ、
   第一のエンティティが、対応するビットレートに応じて無線リソースの各割り当てに関する容量クレジットを更新する、方法。
2. 前記様々なビットレート値が、基準ビットレートと呼ばれる所定のビットレート値に対応する、請求項１に記載の方法。
3. 前記対応するビットレートの割り当てコストが、基準ビットレートの割り当てコストから得られる、請求項２に記載の方法。
4. 前記対応するビットレートの割り当てコストが、基準ビットレートの割り当てコストから補間により得られる、請求項３に記載の方法。
5. ビットレートＲが基準ビットレートでない場合、割り当てコスト「Ｃｏｎｓｕｍｐｔｉｏｎ＿ｃｏｓｔ」が、ビットレートＲに最も近い基準ビットレートＲ_ｉｎｆおよびＲ_ｓｕｐ（Ｒ_ｉｎｆ＜Ｒ_ｓｕｐ）に対応する割り当てコストＣ_ｉｎｆおよびＣ_ｓｕｐに応じて、以下の式に従って計算される、請求項４に記載の方法。
   

   
6. 補間の成果が得られない場合、割り当てコストをゼロに決定する、請求項４または５に記載の方法。
7. 前記対応するビットレートが最大ビットレートに相当する、請求項１から６のいずれか一項に記載の方法。
8. 前記最大ビットレートが、以下の式によって得られ、
   

   

   このとき、
   

   

   ここで、ｂｒ_ｊは、ＴＦＣＳまたは伝送フォーマットの組み合わせセットにおける、ｊ番目のＴＦＣのビットレート、または伝送フォーマットのｊ番目の組み合わせであり、ｎは、符号化された同一の複合伝送チャンネルにおける多重化伝送チャンネルの数であり、Ｎ_ｋ ^（ｊ）およびＬ_ｋ ^（ｊ）は、それぞれｊ番目のＴＦＣにおけるｋ番目の伝送チャンネルの伝送ブロックの数および伝送ブロックのサイズ（ビット数）であり、ＴＴＩ_ｋは、ｋ番目の伝送チャンネルの伝送時間間隔またはＴＴＩ（秒）である、請求項７に記載の方法。
9. 前記対応するビットレートが有効ビットレートに相当する、請求項１から８のいずれか一項に記載の方法。
10. 様々な伝送チャンネルまたは様々なタイプの伝送チャンネルに対して、異なる割り当てコストを知らせる、請求項１から９のいずれか一項に記載の方法。
11. 上りおよび下りの伝送方向に対して、異なる割り当てコストおよび異なる容量クレジットを知らせる、請求項１から１０のいずれか一項に記載の方法。
12. 第一の無線リンクの場合と付加的な無線リンクの場合とで、異なる割り当てコストを知らせる、請求項１から１１のいずれか一項に記載の方法。
13. 様々なタイプの処理、特に様々なタイプのチャンネル符号化に対して、異なる割り当てコストを知らせる、請求項１から１２のいずれか一項に記載の方法。
14. 符号化された同一の複合伝送チャンネル内の様々な多重化伝送チャンネルに対して、異なる割り当てコストを知らせる、請求項１から１３のいずれか一項に記載の方法。
15. 前記システムがＣＤＭＡタイプである、請求項１から１４のいずれか一項に記載の方法。
16. 前記第一のエンティティが基地局コントローラである、請求項１から１５のいずれか一項に記載の方法。
17. 前記第二のエンティティが基地局である、請求項１から１６のいずれか一項に記載の方法。
18. 第一のエンティティと呼ばれるエンティティが、無線リソースおよび対応する処理リソースを管理し、前記処理リソースが、第二のエンティティと呼ばれる異なるエンティティに設けられ、
    前記第二のエンティティが、第二のエンティティの全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、第一のエンティティに知らせる手段を含み、
    前記第一のエンティティが、対応するビットレートに応じて無線リソースの各割り当てに関する容量クレジットを更新する手段を含む、請求項１から１７のいずれか一項に記載の方法を実施するための移動無線通信システム。
19. 基地局が、
    基地局の全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、基地局コントローラに知らせる手段を含む、請求項１から１７のいずれか一項に記載の方法を実施するための移動無線通信システムの基地局。
20. 基地局コントローラが、
    基地局の全体処理容量、すなわち容量クレジットと、様々なビットレート値に対して無線リソースを割り当てるのに必要な全体処理容量の量、すなわち割り当てコストとを、基地局から受信する手段と、
    対応するビットレートに応じて無線リソースの各割り当てに関する容量クレジットを更新する手段とを含む、請求項１から１７のいずれか一項に記載の方法を実施するための移動無線通信システムの基地局コントローラ。

Images