(57)【要約】【課題】無線基地局装置及びリソース割り当て方法に関し、実際のリソース使用量に残余があっても、呼処理制御部で呼設定要求を拒否してしまうケースの発生を抑制し、可能な限り多くの呼設定要求を収容する。【解決手段】呼処理制御部７−３は、移動機の呼設定時にリソース収容状況に従い、呼設定要求情報をベースバンド部７−２に通知し、呼設定処理を実施する。該移動機にリソースを割り当てるベースバンド部７−２は、リソース管理部１−２及びスケジューラ部１−３により、呼処理制御部７−３から通知される呼設定要求情報から最少プロセス状態の最小リソース量を算出し、該最小リソース量を含む呼設定応答情報を呼処理制御部７−３に通知する。呼処理制御部７−３は、ベースバンド部７−２から通知される呼設定応答情報に含まれる最小リソース量を管理し、該最小リソース量を基に移動機の呼設定要求に対するリソース割り当ての可否を判断する。【選択図】図１
2011082739.tif 000002
【特許請求の範囲】
【請求項１】
移動機の呼設定時にリソース収容状況に従い、呼設定要求情報をベースバンド部に通知する呼処理制御部と、
該移動機にリソースを割り当てるベースバンド部とを備え、
前記ベースバンド部は、前記呼処理制御部から通知される呼設定要求情報から最少プロセス状態の最小リソース量を算出し、該最小リソース量を含む呼設定応答情報を前記呼処理制御部に通知し、
前記呼処理制御部は、前記ベースバンド部から通知された前記呼設定応答情報に含まれる最小リソース量を基に移動機の呼設定要求に対するリソース割り当ての可否を判断することを特徴とする無線基地局装置。
【請求項２】
前記ベースバンド部は、前記移動機の呼設定時に前記呼処理制御部から通知されたリソース量と既設定呼の現在以降の割り当てリソース量とを比較し、既設定呼の現在以降の割り当てリソース量を減少させたときに、前記移動機へのリソースの割り当てが可能か否かを判定し、該移動機へのリソースの割り当てが可能な場合、既設定呼の現在以降の割り当てリソース量を減少させることを特徴とする請求項１に記載の無線基地局装置。
【請求項３】
移動機の呼設定時にリソース収容状況に従い、呼設定要求情報をベースバンド部に通知する呼処理制御部と、該移動機にリソースを割り当てるベースバンド部とを備えた無線基地局装置におけるリソース割り当て方法において、
前記ベースバンド部で、前記呼処理制御部から通知される呼設定要求情報から最少プロセス状態の最小リソース量を算出し、該最小リソース量を含む呼設定応答情報を前記呼処理制御部に通知し、
前記呼処理制御部で、前記ベースバンド部から通知された前記呼設定応答情報に含まれる最小リソース量を基に移動機の呼設定要求に対するリソース割り当ての可否を判断することを特徴とする無線基地局装置におけるリソース割り当て方法。
【請求項４】
前記ベースバンド部で、前記移動機の呼設定時に前記呼処理制御部から通知されたリソース量と既設定呼の現在以降の割り当てリソース量とを比較し、既設定呼の現在以降の割り当てリソース量を減少させたときに、前記移動機へのリソースの割り当てが可能か否かを判定し、該移動機へのリソースの割り当てが可能な場合、既設定呼の現在以降の割り当てリソース量を減少させることを特徴とする請求項３に記載の無線基地局装置におけるリソース割り当て方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、移動無線通信システムにおける無線基地局装置及びリソース割り当て方法に関する。本発明は、例えばＨＳＵＰＡ（High Speed Uplink Packet Access）に対応した無線基地局装置及びそのベースバンドリソース割り当て等に適用することができる。
【背景技術】
【０００２】
ＨＳＵＰＡ無線基地局装置の構成例を図７に示す。ＨＳＵＰＡ無線基地局装置は、無線部７−１、ベースバンド部７−２、呼処理制御部７−３、伝送路インタフェース部７−４を備える。呼処理制御部７−３は、移動機ＵＥの呼設定時に、当該無線基地局のリソース収容状況に従い、該移動機ＵＥの呼をベースバンド部７−２のベースバンドカードへ割り当てる処理を行う。この処理により、移動機ＵＥは、無線部７−１、ベースバンド部７−２、伝送路インタフェース部７−４を介して上位の無線ネットワーク制御装置ＲＮＣと接続され、上り信号を送信する。
【０００３】
ベースバンド部７−２内にはスケジューラ部を備え、スケジューラ部は、呼処理制御部７−３からの要求を基に、無線基地局の収容能力及び移動機ＵＥの収容状況に従い、現タイミング以降におけるリソース（電力リソースや符号リソースやハードウエアリソース等）の割り当てを、所定の時間間隔ＴＴＩ（Transmission Time Interval）毎に実施する。
【０００４】
スケジューラ部は、移動機ＵＥの上り信号の干渉量、電力値、ユーザプライオリティ等に基づいて、移動機ＵＥへのリソースの割り当て処理を実施する。これらの技術については、３ＧＰＰ（Third Generation Partnership Project）において、上りリンクの高品質化や高速化等のために、ＨＳＵＰＡ（High Speed Uplink Packet Access）方式として提案され、スケジューラ部の機能の概要は、例えば下記の特許文献１等にも記載されている。
【０００５】
従来の３ＧＰＰシステムでは、呼処理制御部７−３で移動機ＵＥからの呼設定要求を終端（ＲＲＣレイヤ処理）し、該移動機ＵＥから要求されたリソースの割り当てをベースバンド部７−２で実施していた。このため、移動機ＵＥからの要求により一様にリソース量の割り当てが決定されていた。
【０００６】
ＨＳＵＰＡシステムにおいては、ＭＡＣ−ｅレイヤ処理を実施するために、所定の時間間隔ＴＴＩ毎にリソース割り当て制御を実施する。そのため、ベースバンド部７−２にＭＡＣ−ｅレイヤ処理機能及び所定の時間間隔ＴＴＩ毎のリソース管理機能を実装して、３ＧＰＰシステムのエンハンスメント機能を実現している。
【０００７】
呼処理制御部７−３は、呼設定時に移動機ＵＥから要求されたパラメータを基にリソース使用量の割り当ての可不可を判定して呼処理制御を実施する。しかし、実際にベースバンド部７−２のスケジューラ部で所定の時間間隔ＴＴＩ毎に管理／制御し、呼処理制御部７−３では、ベースバンド部７−２で実際に割り当てる短期間で変動するリソース使用量を認識することができない。このため、新規移動機ＵＥの呼設定要求に対するリソース割り当ての判定が呼処理機能部で制限されてしまうことがある。
【０００８】
このような例の第１のケースについて図８を参照して説明する。図８の（ａ）に示すように、移動機ＵＥ＃１がリソース最大使用量２の呼設定要求を行い、続いて移動機ＵＥ＃２がリソース最大使用量４の呼設定要求を行ったとする。このとき、既に移動機ＵＥ＃０に対してリソース使用量４の呼設定が行われていたとする。
【０００９】
ベースバンド部のスケジューラ部では、図８の（ｂ）に示すように、移動機ＵＥ＃１が呼設定要求を行ったタイミング（ｔ＝０）の後、移動機ＵＥ＃０のリソース使用量が２に変動し、移動機ＵＥ＃１にリソース使用量２を割り当てたとする。この場合、残りの使用可能なリソース量が４であり、以降のタイミングでも使用可能なリソース量が４であるので、移動機ＵＥ＃２へのリソース使用量４の割り当ては可能である。
【００１０】
しかし、呼処理制御部では、移動機ＵＥから呼設定持に要求され割り当てたリソース使用量を、その後のタイミングでも使用されるリソース量として認識している。そのため、図８の（ｃ）に示すように、移動機ＵＥ＃０のリソース使用量４、移動機ＵＥ＃１のリソース使用量２、残りの使用可能なリソース量は２と認識している。従って、移動機ＵＥ＃２の呼設定時の要求リソース使用量４は、使用可能なリソース量２を超過していると判断し、該呼設定要求を拒否してしまう。
【００１１】
第２のケースについて図９を参照して説明する。図９の（ａ）に示すように、移動機ＵＥ＃１がリソース最大使用量２の呼設定要求を行い、その後、移動機ＵＥ＃２がリソース最大使用量４の呼設定要求を行ったとする。このとき、既に移動機ＵＥ＃０にリソース使用量４の呼設定が行われていたとする。
【００１２】
スケジューラ部では、受信された上り信号の電力や干渉量等の測定結果に従ってリソース割り当て制御を実施している。この場合、スケジューラ部では、図９の（ｂ）に示すように、移動機ＵＥ＃１が呼設定要求を行ったタイミング（ｔ＝０）後に、移動機ＵＥ＃０のリソース使用量が６に変動したとすると、次のタイミングで移動機ＵＥ＃１にリソース使用量２を割り当て、残りの使用可能なリソース量は０となっている。但し、移動機ＵＥ＃０のリソース使用量を２に減少させれば、移動機ＵＥ＃２へのリソース使用量４の割り当ては可能である。
【００１３】
このように、既に収容した移動機ＵＥに対するその後のリソース割り当てを減少させる制御を行えば、新規移動機ＵＥへのリソース割り当てが可能な場合でも、呼処理機能部では図９の（ｃ）に示すように、移動機ＵＥ＃０のリソース使用量４、移動機ＵＥ＃１のリソース使用量２、残りの使用可能なリソース量は２と認識している。従って、移動機ＵＥ＃２の呼設定時の要求リソース使用量４は、使用可能なリソース量２を超過していると判断し、該呼設定要求を拒否してしまう。
【００１４】
ベースバンド部のリソース管理において、ベースバンドカードでリソース割り当てを行うと共にリソース使用状況を呼処理制御部に通知し、呼処理制御の指示によりリソース割り当てを行う技術等は、例えば下記の特許文献２等によって知られている。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開２００７−１２４０４８号公報
【特許文献２】特開２００３−０８７８５４号公報
【発明の概要】
【発明が解決しようとする課題】
【００１６】
前述の第１及び第２のケースの何れの場合でも、呼処理制御部で管理しているリソース使用量とベースバンド部で管理しているリソース使用量とに差分が生じ、ベースバンド部における実際のリソース使用量に残余があっても、呼処理制御部ではリソース割当量に残余が無いと判定し、移動機の呼設定要求を拒否してしまう場合がある。無線基地局におけるリソース管理において、リアルタイムに可能な限り、多くの移動機を収容することが望ましい。
【００１７】
また、新規呼やプライオリティの高い呼や個別制御チャネル（ＤＣＣＨ：Dedicated Control Channel）等の制御信号に対してリソースを優先的に割り当てることが望ましい。本発明は、可能な限り多くの移動機の呼設定要求を収容することを目的とする。
【課題を解決するための手段】
【００１８】
上記課題を解決する無線基地局装置は、移動機の呼設定時にリソース収容状況に従い、呼設定要求情報をベースバンド部に通知する呼処理制御部と、該移動機にリソースを割り当てるベースバンド部とを備え、前記ベースバンド部は、前記呼処理制御部から通知される呼設定要求情報から最少プロセス状態の最小リソース量を算出し、該最小リソース量を含む呼設定応答情報を前記呼処理制御部に通知し、前記呼処理制御部は、前記ベースバンド部から通知された前記呼設定応答情報に含まれる最小リソース量を基に移動機の呼設定要求に対するリソース割り当ての可否を判断することを特徴とする。
【発明の効果】
【００１９】
呼処理制御部とベースバンド部とのリソース使用量の認識に整合性を保つことができ、従来のように実際のリソース使用量に残余があるにも拘らず、呼処理制御部で新規呼設定要求の受付制限してしまうことを回避することが可能となる。
【図面の簡単な説明】
【００２０】
【図１】無線基地局装置の機能ブロック構成例を示す図である。
【図２】ＳＧ→リソース量変換テーブル及びＵＥリソース管理テーブルの一例を示す図である。
【図３】仮積み上げ及び実積み上げのリソース量管理の処理シーケンスを示す図である。
【図４】最小スケジュールグラント用リソース量の積み上げの例を示す図である。
【図５】最小スケジュールグラント用リソース量積み上げの平坦化の例を示す図である。
【図６】呼処理制御部におけるベースバンド部の収容リソース量の管理の例を示す図である。
【図７】ＨＳＵＰＡ無線基地局装置の構成例を示す図である。
【図８】従来のリソース割り当て可否判断の第１のケースを示す図である。
【図９】従来のリソース割り当て可否判断の第２のケースを示す図である。
【発明を実施するための形態】
【００２１】
図１に開示の無線基地局装置の機能ブロック構成例を示す。該無線基地局装置には、無線部７−１、ベースバンド部７−２、呼処理制御部７−３を備える。ベースバンド部７−２には、呼制御信号受信部１−１、リソース管理部１−２、スケジューラ部１−３、上り信号受信／測定部１−４、及び下り信号送信部１−５を備える。
【００２２】
スケジューラ部１−３は、移動機の呼設定時に、呼処理制御部７−３から通知される呼設定要求のパラメータから最少プロセス状態（割り当てタイミング）の最小リソース量を算出する。そして、呼処理制御部７−３への応答として、算出した最少プロセス状態／最小リソース量、及び、移動機に割り当て可能と判断したベースバンド部７−２の全リソース量を返答する。
【００２３】
呼処理制御部７−３は、スケジューラ部１−３により算出された最小リソース量を管理し、新規移動機の呼設定要求に対するリソース割り当ての可否を判断する。スケジューラ部１−３は、既設定呼に割り当てたリソースの削減制御により使用される最小のリソース量を、呼処理制御部７−３に認識させる。こうすることにより、新規移動機の呼を収容することができるにも拘わらず、呼処理制御部７−３で受付を制限してしまうことを回避することができる。
【００２４】
スケジューラ部１−３では、既設定呼の現在の割り当てリソース量及び現在以降の割り当てリソース量を管理する。そして、新規移動機の呼設定要求時に呼処理制御部７−３から要求されたリソース量と、現在以降の既設定呼の割り当てリソース量とを比較し、現在以降の既設定呼の割り当てリソース量を減少させた場合、新規移動機の収容が可能か否かをチェックする。
【００２５】
上記チェックの結果、新規移動機の呼の収容が可能と判断された場合、現在以降の割り当てリソース量を段階的に減少させる制御をリソース管理部１−２に対して促す。既設定呼に対する現在の割り当てリソース量を、現在以降の割り当てのリソース量として管理することにより、既設定呼の現在以降の割り当てリソース量を段階的に減少させ、新規移動機の呼設定要求に対するリソースの割り当てを優先させる。
【００２６】
上記無線基地局装置におけるリソース管理の動作の流れについて説明する。
（１）呼処理制御部７−３から移動機の呼設定要求情報が呼制御信号受信部１−１を経由してリソース管理部１−２に通知される。該呼設定要求情報には、初期スケジューリンググラント、最小スケジューリンググラント、プライオリティ情報、ＨＡＲＱプロセスアロケーションが含まれる。なお、スケジューリンググラントは、以降「ＳＧ」と記載することもある。
【００２７】
（２）リソース管理部１−２では、通知された呼設定要求情報から必要なリソース量を算出し、該リソース量を仮積みリソース量として積み上げ、該呼にリソース割り当てが可能か否かを判定する。
【００２８】
（３）リソース管理部１−２は、呼処理制御部７−３に呼設定応答情報を送信する。該呼設定応答情報には、該呼へのリソース割り当ての可否、最小スケジューリンググラントリソース量、最小スケジューリンググラント割り当てプロセス番号、ベースバンドリソース情況が含まれている。
【００２９】
（４）リソース管理部１−２は、スケジューラ部１−３にリソース制御情報を通知する。該リソース制御情報には、最大受信可能トランスポートブロックサイズ（ＴＢＳ）、リソース量の不足の有無、新規呼情報等が含まれる。また、リソース管理部１−２は、アクティブ／非アクティブプロセス情報をスケジューラ部１−３に通知する。
【００３０】
（５）スケジューラ部１−３は、上りデータ受信／測定部１−４で測定される上り受信データの測定結果に従い、スケジューリンググラントを決定する。決定したスケジューリンググラントを、リソース管理部１−２及び下り信号送信部１−５に通知する。
【００３１】
（６）リソース管理部１−２は、スケジューラ部１−３から通知されるスケジューリンググラントを基に、割り当てるリソース量を算出し、該リソース量を積み上げる。該リソース量に基づくリソース制御情報をスケジューラ部１−３に通知し、上述の（４）〜（６）の処理を、呼が解放されるまで繰り返す。
【００３２】
以下、上述のリソース管理について以下に詳述する。
［１］リソース量の算出について
呼処理制御部７−３から移動機の呼設定要求を受信し、移動機の呼設定情報内パラメータである初期スケジューリンググラント及び最小スケジューリンググラントから必要なリソース量を算出する手法、及びスケジューラ部１−３で決定されたスケジューリンググラントインデックスからリソース量を算出する手法について説明する。
【００３３】
スケジューリンググラントには、移動機の識別情報、データサイズ、変調方式、上り信号の送信電力情報等の情報が含まれている（例．特開２００９−１７７６２７等参照）。リソース管理部１−２は、スケジューリンググラントインデックスを索引キーとするＳＧ→リソース量変換テーブルを用い、割り当てるリソース量を算出する。ＳＧ→リソース量変換テーブルの一例を図２の（ａ）に示す。該ＳＧ→リソース量変換テーブルは、無線基地局装置のベースバンドカードの立ち上がり時に生成する構成とすることができる。
【００３４】
ＳＧ→リソース量変換テーブルの生成方法は、以下のとおりである。なお、スケジューリンググラントからスケジューリンググラントインデックスを算出する方法は、３ＧＰＰの規格ＴＳ２５．２１２  ４．１０．１Ａ  Ｅ−ＡＧＣＨ  Ｉｎｆｏｒｍａｔｉｏｎ  ｆｉｅｌｄ  ｍａｐｐｉｎｇに記述され、スケジューリンググラントの値からスケジューリンググラントインデックス変換テーブルにより変換することができる。無線基地局装置におけるスケジューリンググラントの取り扱い（受け渡し等）は、全てスケジューリンググラントインデックスにより取り扱うこととすることができる。
【００３５】
リソース量は、トランスポートブロックサイズ（ＴＢＳ）及び拡散率（ＳＦ：Spreading Factor）によりに固定的に決定される。即ち、トランスポートブロックサイズ（ＴＢＳ）からＥ−ＴＦＣ（ＩE-DCH - Transport Format Combination Identifier）への変換を行い（ＴＳ２５．３２１  ＡｎｎｅｘＢ参照）、Ｅ−ＴＦＣＩ→リソース変換テーブル（Ａ）によりリソース量を決定することができる。また、ＳＦ→リソース変換テーブル（Ｂ）により、拡散率（ＳＦ）からリソース量を決定することができる。
【００３６】
このため、スケジューリンググラントの最大受信可能トランスポートブロックサイズ（ＴＢＳ）と最小拡散率（ＳＦ）とを算出し、最大受信可能トランスポートブロックサイズ（ＴＢＳ）のリソース量と最小拡散率（ＳＦ）のリソース量との中でより多い方をリソース量として扱う。
【００３７】
最大受信可能トランスポートブロックサイズ（ＴＢＳ）と最小拡散率（ＳＦ）の算出方法については、３ＧＰＰの規格ＴＳ２５．３２１に記述されているが、概要を以下に示す。
（１）スケジューリンググラントの最大受信可能トランスポートブロックサイズ（ＴＢＳ）数（≒ＭＡＸ  Ｅ−ＴＦＣＩ）を算出する（算出式はＴＳ２５．３２１  １１．８．１．４、ＴＳ２５．３２１  ＡｎｎｅｘＢ参照）。この算出は、ベースバンドカード立ち上がり時に実施し、ＳＧ→ＭＡＸ  Ｅ−ＴＦＣＩ変換テーブル（Ｃ）を作成する。
【００３８】
（２）上述の（１）で算出した最大受信可能トランスポートブロックサイズ（ＴＢＳ）から処理可能最大Ｅ−ＴＦＣＩを算出し、Ｅ−ＴＦＣＩに対応する最小拡散率（ＳＦ）を算出する（算出式はＴＳ２５．２１２  ４．８．４．１参照）。この算出は、ベースバンドカード立ち上がり時に実施し、Ｅ−ＴＦＣＩ→最小拡散率（ＳＦ）変換テーブル（Ｄ）を作成する。
【００３９】
上述のＥ−ＴＦＣＩ→リソース変換テーブル（Ａ）、ＳＦ→リソース変換テーブル（Ｂ）、ＳＧ→ＭＡＸ  Ｅ−ＴＦＣＩ変換テーブル（Ｃ）、及びＥ−ＴＦＣＩ→最小拡散率（ＳＦ）変換テーブル（Ｄ）から、ＳＧ→ＢＢリソース量変換テーブルを生成することができる。
【００４０】
最小スケジューリンググラントは、呼処理制御部７−３から移動機の呼設定要求時に指定されるＥ−ＤＣＨ  ｍｉｎｎｕｍ  ｓｅｔ  Ｅ−ＴＦＣＩから算出することができる。初期スケジューリンググラントは、呼処理制御部７−３からベースバンド部７−２へそのまま通知される。
【００４１】
［２］リソース量及びＨＡＲＱプロセス状態の管理について
移動機毎に算出したリソース量及びＨＡＲＱプロセス状態を管理する方法について以下に説明する。移動機番号を索引キーとするＵＥリソース管理テーブルにより、算出したリソース量とプロセス状態とを管理する。
【００４２】
ＵＥリソース管理テーブルは、図２の（ｂ）に示すように、各移動機ＵＥ番号対応に、リソース量及びプロセス状態の情報を格納する。プロセス状態は、通信に使用されるＴＴＩ単位のＨＡＲＱプロセスの番号（図の例では０〜７）毎にアクティブ状態か非アクティブ状態かを示すフラグ（１又は０）を格納して管理する。
【００４３】
［３］移動機毎のリソース量をＨＡＲＱプロセス毎に積み上げる管理について
移動機毎に算出したリソースをベースバンド部７−２の収容リソースとしてＨＡＲＱプロセス毎に積み上げ管理する手法について以下に説明する。移動機の呼設定要求の受付時から実際に移動機からの上りデータ送信が行われるタイミングまでは、移動機毎のリソース量をＨＡＲＱプロセス毎に仮積み上げリソース量として積み上げる。そして、実際に移動機からの上りデータが送信され、スケジューラ部１−３の算定結果が反映された後は、実積み上げリソース量として管理する。
【００４４】
上記管理を行うために、ＨＡＲＱプロセス番号を索引キーとしたリソース管理テーブルによりベースバンド部７−２の収容リソースを管理する。リソース管理テーブルは、図３の（ａ）に示す仮積み上げ用リソース管理テーブルと、図３の（ｂ）に示す実積み上げ用リソース管理テーブルとを用いる。
【００４５】
仮積み上げリソース量の管理と実積み上げリソース量の管理の処理シーケンスを図３の（ｃ）に示す。呼処理制御部７−３からベースバンド部７−２に移動機ＵＥの呼設定要求の情報が送出されると、ベースバンド部７−２の呼制御信号受信部１−１で該移動機ＵＥの呼設定要求の情報を受信し、ベースバンド部７−２のリソース管理部１−２は、ＨＡＲＱプロセスを選択し、ＨＡＲＱプロセス毎に仮積み上げリソース量を積み上げる（３−１）。
【００４６】
リソース管理部１−２は、仮積み上げリソース量及びプロセス情報をスケジューラ部１−３に通知し、スケジューラ部１−３は、スケジュールグラント（ＳＧ）をリソース管理部１−２に通知する。リソース管理部１−２は、該スケジュールグラント（ＳＧ）に従ってＨＡＲＱプロセスを選択し、ＨＡＲＱプロセス毎に仮積み上げリソース量を積み上げる（３−２）。リソース管理部１−２は、該仮積み上げリソース量及びプロセス情報をスケジューラ部１−３に通知し、スケジューラ部１−３は、スケジュールグラント（ＳＧ）をリソース管理部１−２に通知する。
【００４７】
その後、移動機ＵＥから実際に上りデータが送信されると、該上りデータ送信タイミングで、リソース管理部１−２は、仮積み上げリソース量の値を実積み上げリソース量の値にコピーする（３−３）。そして、該リソース量及びプロセス情報をスケジューラ部１−３に通知し、スケジューラ部１−３はスケジュールグラント（ＳＧ）をリソース管理部に通知する。リソース管理部１−２は、該スケジュールグラント（ＳＧ）に従ってプロセスを選択し、実積み上げ用にリソースを積み上げる（３−４）。
【００４８】
［４］最小リソース量及び最小リソース積み上げプロセスの管理について
ベースバンド部７−２では、呼処理制御部７−３とのリソース量の不整合の回避を図るために、呼処理制御部７−３からの呼設定要求情報受信時に、最小リソース量及び最小リソース量積み上げプロセスを算出して管理する。その手法について以下に説明する。
【００４９】
ＨＡＲＱプロセス番号を索引キーとする最小スケジュールグラント用リソース管理テーブルを設け、該最小スケジュールグラント用リソース管理テーブルにより、ベースバンド部７−２収容の最小リソース量を管理する。最小スケジュールグラント用リソース管理テーブル（以下、「最小ＳＧ用リソース管理テーブル」とも記す。）の例を図４の（ａ）に示す。最小ＳＧ用リソース管理テーブルは、プロセス番号毎に最小リソース量を積み上げたリソース量を格納する。
【００５０】
移動機の呼設定要求時における、リソース量算出及びプロセス毎のリソース積み上げ管理の手順を、図４を参照して説明する。図４の（ｂ）は該手順のフローを示し、図４の（ｃ）は、プロセスへのリソース積み上げの例を示している。
【００５１】
まず、最小スケジュールグラントを索引キーとして、ＳＧ→リソース量変換テーブルから最小スケジューリンググラントリソース量を算出する（４−１）。次にＨＡＲＱプロセスアロケーションにおけるアクティブプロセスであって、かつ、最小ＳＧ用リソース管理テーブルで最小リソース量の積み上げ量の最も少ないプロセス番号を選択する（４−２）。
【００５２】
上述の手順（４−２）で選択したプロセス番号を索引キーとして、上述の手順（４−１）により算出した最小スケジューリンググラントリソース量を、最小ＳＧ用リソース管理テーブルに積み上げる（４−３）。こうすることにより、例えば図４の（ｃ）に示すように、アクティブプロセスであって、最小リソース量の積み上げ量の最も少ないプロセス番号５が選択され、プロセス番号５に最小リソース量が積み上げられる。従って、プロセス間での最小リソースの積み上げ量に偏りが生じるのを防ぐことができる。
【００５３】
［５］呼設定と呼解放の繰り返しによる積み上げ対象プロセスの偏りの回避について
移動機の呼解放時に、該当移動機の最小リソース量及びアクティブプロセスを解放するとともに、各プロセスの最小リソース量の積み上げの偏りを平坦化（平準化）する。
【００５４】
最小リソースの積み上げ対象プロセスが偏るのを回避する手順について、図５を参照して説明する。図５の（ａ）は該手順のフローを示し、図５の（ｂ）は、プロセスへの最小リソース積み上げの例を示している。
【００５５】
まず、最小スケジューリンググラントリソース量を、最小ＳＧ用リソース管理テーブルから全プロセスについて求め、その平均リソース量を算出する（５−１）。次に、該平均リソース量を基準としてプロセス間の平坦化（移動機の最小リソース量の移動）を実施する（５−２）。
【００５６】
プロセス間の平坦化の処理として、プロセス毎に平均リソース量に対して積み上げリソース量が超過か不足かを判定し、該判定結果に応じて以下の処理を行う（５−３）。平均リソース量に対して超過しているプロセスは、超過した移動機のリソース量を超過対象プロセスリストに登録する。また、平均リソース量に対して不足しているプロセスについては許容リソース量を獲得する。
【００５７】
リソース量不足のプロセスに、超過対象プロセスリストに登録された移動機リソースを移動する。但し、リソース量不足のプロセスの許容リソース量より、該プロセスの積み上げリソース量に超過対象プロセスリスト内の移動機リソース量を加えた値が小さい場合に、リソースを移動する（５−４）。
【００５８】
こうすることにより、例えば図５の（ｂ）に示すように、プロセス番号２，４，７が平均リソース量を超過して最小リソース量を積み上げている場合、平均リソース量に満たないプロセス番号１，５，６に、超過リソース量を移動させ、積み上げ量を平均化することができる。
【００５９】
図５（ｂ）の例では、プロセス番号２における移動機ＵＥ＃１の超過リソースをプロセス番号１に移動し、プロセス番号４における移動機ＵＥ＃２の超過リソースをプロセス番号５に移動し、プロセス番号７における移動機ＵＥ＃３の超過リソースをプロセス番号５に移動し、プロセス番号７における移動機ＵＥ＃４の超過リソースをプロセス番号６に移動する例を示している。
【００６０】
［６］最小リソース量を積み上げたプロセスに対するアクティブ制御について
移動機の呼設定要求に対して、リソース管理部１−２でリソース割り当て可能と判断し、上述の［４］及び［５］で説明したように、その最小リソース量を割り当てて積み上げたプロセスに対して、スケジューラ部１−３では非アクティブとすることなく、アクティブプロセスとなるよう制御する。こうすることにより、該移動機は最小リソース量での通信が可能となる。
【００６１】
［７］移動機の呼設定要求に対するリソース割り当ての可不可判断について
移動機の呼設定要求に対してリソース割り当ての可不可を判断する手法について、及び呼処理制御部にベースバンド部の割り当てリソース量を認識させる手法について以下に説明する。また、移動機の呼解放時に、ベースバンド部の収容リソース状況を呼処理制御部に認識させる手法について説明する。
【００６２】
移動機の呼設定時には、リソース管理部１−２で最小ＳＧ用リソース管理テーブルから該呼の収容の可不可をチェックする。リソースの割り当て方法は、前述の［４］で説明したように、呼設定要求情報受信時に最小リソース量及び最小リソース量積み上げプロセスを算出して割り当てを行い、割り当て可不可のチェックを行う。
【００６３】
次に、呼処理制御部７−３に対し、移動機の呼設定応答として以下（１）〜（５）の情報を設定して送信する。（１）移動機ＵＥ番号、（２）チェック結果（ＯＫ又はＮＧ）、（３）移動機に割り当てる最小スケジューリンググラント用リソース量、（４）移動機に割り当てるプロセス番号、（５）ベースバンド部の収容リソース状況（最小ＳＧ用リソース管理テーブルのリソース積み上げ量）
【００６４】
移動機の呼解放時にも同様に、前述の［５］で説明したように、呼解放要求情報受信時に最小リソース量及び最小リソース量積み上げプロセスを解放し、呼処理制御部７−３に対して、移動機の呼解放応答として以下（１）〜（５）の情報を設定して送信する。（１）移動機ＵＥ番号、（２）チェック結果（ＯＫ）、（３）移動機ＵＥに割り当てた最小スケジューリンググラント用リソース量、（４）移動機に割り当てたプロセス番号、（５）ベースバンド部の収容リソース状況（最小ＳＧ用リソース管理テーブルのリソース積み上げ量）
【００６５】
［８］呼処理制御部におけるベースバンド部の収容リソース量の管理について
呼処理制御部７−３は、ベースバンド部７−２から通知されるリソース情報を、ベースバンドリソース管理テーブルに反映させ、ベースバンド部７−２の収容リソース量を管理する。図６の（ａ）にベースバンドリソース管理テーブルの例を示す。ベースバンドリソース管理テーブルには、ベースバンドカード毎にプロセス番号毎のリソース積み上げ量を格納する。
【００６６】
図６の（ｂ）に呼処理制御部７−３及びベースバンド部７−２の処理シーケンス例を示す。新規移動機ＵＥの呼設定要求時に、呼処理制御部７−３は、ベースバンドリソース管理テーブルを参照し、該移動機ＵＥの呼設定の収容可不可を判断し（６−１）、ベースバンド部７−２に移動機ＵＥの呼設定を要求する。また、ベースバンド部７−２からの呼設定応答又は呼解放応答の受信時に、該ベースバンド部７−２からの応答結果を該ベースバンドリソース管理テーブルに反映する（６−２）。
【００６７】
［９］リソース算出、プロセスのアクティブ制御及びリソース積み上げについて
［９−１］リソース量算出について
リソース管理部１−２では、スケジューラ部１−３で算出されたスケジューリンググラントから、ＳＧ→リソース量変換テーブルによりリソース量を算出する（詳細は［１］参照）。なお、呼設定時には、呼処理制御部７−３から通知される初期スケジューリンググラントからリソース量を算出する。
【００６８】
［９−２］ＨＡＲＱプロセスのアクティブ／非アクティブの決定について
非アクティブなプロセスの中で、最もリソース使用量が少ないプロセスをアクティブ対象プロセスとするよう決定する。また、現スケジューリンググラント（スケジューラ部１−３で決定したＳＧ）が最小スケジューリンググラントと等しい移動機について、アクティブのプロセスが複数存在する場合、アクティブのプロセスの中で最もリソース使用量が多いプロセスを非アクティブ対象プロセスとするよう決定する。こうすることにより、使用可能なリソースをより多く確保することができる。なお、初期呼設定時には、呼処理制御部７−３から通知されるＨＡＲＱプロセスアロケーションに従い、アクティブプロセスを決定する。
【００６９】
［９−３］リソース積み上げについて
プロセス毎にリソース量をリソース管理テーブルに積み上げる（詳細は［３］参照）。移動機の呼設定要求時から移動機の上りデータ送信開始タイミングまでの間は、仮積み用リソース管理テーブルに積み上げる。移動機の上りデータ送信開始タイミング後は、実積み用リソース管理テーブルに積み上げる。
【００７０】
リソースの積み上げの結果、使用可能なリソース量を超過したプロセスが生じた場合、スケジューラ部１−３に対し、リソース量超過状況により「新規呼設定動作」又は「リソース削減動作」を指示する。
【００７１】
「新規呼設定動作」では、スケジューラ部１−３により、指定移動機のリソース使用量を最小スケジューリンググラントのリソース使用量まで減少させ、リソースの空きを確保する動作を実施する。
【００７２】
「リソース削減動作」では、既にリソースが割り当てられている移動機に対して、リソース使用量を最小スケジューリンググラントのリソース使用量まで減少させ、かつ、アクティブプロセスの削減（アクティブ対象プロセスの非アクティブ化）を実施し、リソースの空きを確保する。
【００７３】
［９−３ａ］新規呼の仮積み上げの結果、使用可能なリソース量を超過したプロセスが生じた場合、全ての既設定呼を最小スケジューリンググラントまで落としたと仮定して、超過したプロセスのリソースの再積み上げを行う。その結果、新規呼のリソースを確保することができると判断された場合、上述の「新規呼設定動作」を行う。この場合、超過したプロセスがアクティブのプロセスであって、かつスケジューリンググラントが最小スケジューリンググラントでないプロセスである場合、該プロセスに割り当てられた全移動機に対して前述の「新規呼設定動作」を行う。
【００７４】
［９−３ｂ］新規呼の仮積み上げでリソース量の超過が発生した場合、全ての既設定呼を最小スケジューリンググラントまで落としたと仮定して、リソースの仮積み上げを行う。その結果でも、リソース量の超過が発生する場合、前述の「新規呼設定動作」のみでは新規呼のリソースを確保することができないため、上述の「リソース削減動作」を行い、プロセスの非アクティブ化を行う。この場合、リソース量超過が発生したプロセスでアクティブな状態のプロセスに割り当てられた既設定呼全てを「リソース削減動作」の対象として設定する。
【００７５】
更に、リソース量が超過したプロセスであってアクティブな状態のプロセスに割り当てられ、かつ、現スケジューリンググラントが最小スケジューリンググラントと等しい呼のプロセスを全て非アクティブ対象プロセスとすることができる。
【００７６】
［９−３ｃ］上述の［９−３ｂ］によってもリソース量の超過が発生する場合、仮積み上げの新規呼のリソースを個別制御チャネル（ＤＣＣＨ：Dedicated Control Channel）分のみとし、再々度、リソースの仮積み上げを行う。その結果でも、リソース量超過が発生すると判断された場合、新規呼の個別制御チャネル（ＤＣＣＨ）用リソース確保を優先させるために、新規呼についても上述の「リソース削減動作」の対象とする。新規呼についても既設定呼と同様に非アクティブ対象プロセス設定を行う。
【００７７】
［９−４］呼処理制御部７−３への通知について
ベースバンド部７−２のリソース管理部１−２は、最小スケジューリンググラントを基にリソース量を算出し、かつ、アクティブプロセスを１プロセスのみに設定したリソース量の積み上げを実施し、該リソース量を呼処理制御部７−３に通知する。呼処理制御部７−３は、該リソース量の情報を基に、新規移動機の呼設定要求に対するリソース割り当ての可不可を判断する。
【００７８】
以上説明したように、スケジューラ部１−３で制御可能な最小のリソース量を呼処理制御部７−３に認識させることにより、呼処理制御部７−３とベースバンド部７−２とのリソース使用量の認識の整合性を保つことができる。そのため、従来のように新規移動機の呼を収容可能であるにも拘わらず、呼処理制御部７−３で呼設定要求の受付を制限してしまうことを回避することができる。
【００７９】
また、現在の使用リソース量を現在以降の使用リソース量として管理し、他の移動機のリソース量を段階的に減少させ、新規呼へのリソース割り当てを優先させることにより、既設定呼に対してリソース量減少制御を実施し、より多くの新規呼の収容が可能となる。
【符号の説明】
【００８０】
１−１  呼制御信号受信部
１−２  リソース管理部
１−３  スケジューラ部
１−４  上り信号受信／測定部
１−５  下り信号送信部
７−１  無線部
７−２  ベースバンド部
７−３  呼処理制御部
【図１】
2011082739.tif 000003
【図２】
2011082739.tif 000004
【図３】
2011082739.tif 000005
【図４】
2011082739.tif 000006
【図５】
2011082739.tif 000007
【図６】
2011082739.tif 000008
【図７】
2011082739.tif 000009
【図８】
2011082739.tif 000010
【図９】
2011082739.tif 000011