JP2014057216A - 無線ネットワーク制御装置、無線ネットワーク制御装置におけるリソース共有方法、及び無線通信ネットワークシステム - Google Patents

Abstract

【課題】現在のシステムや装置を変更しないで、長期運用が可能な無線ネットワーク制御装置、無線ネットワーク制御装置におけるリソース共有方法、及び無線通信ネットワークシステムを提供すること。また、運用コストを増加させないようにした無線ネットワーク制御装置、無線ネットワーク制御装置におけるリソース共有方法、及び無線通信ネットワークシステムを提供すること。
【解決手段】配下の無線基地局装置を制御する無線ネットワーク制御装置において、ユーザプレーンのデータを処理する機能を有する第１の機能部と、前記無線ネットワーク制御装置は他の無線ネットワーク制御装置のアドレス情報を保持し、前記無線ネットワーク制御装置のアドレス情報を保持する前記他の無線ネットワーク制御装置に対し、前記第１の機能部における第１のリソースと前記他の無線ネットワーク制御装置においてユーザプレーンのデータを処理する機能を有する第２の機能部における第２のリソースとを共有する制御部を備える。
【選択図】図８

Description

本発明は、無線ネットワーク制御装置、無線ネットワーク制御装置におけるリソース共有方法、及び無線通信ネットワークシステムに関する。

現在、携帯電話システムや無線ＬＡＮ（Local Area Network）などの無線通信システムが広く利用されている。また、無線通信の分野では、通信速度や通信容量を更に向上させるべく、次世代の通信技術について継続的な議論が行われている。例えば、標準化団体である３ＧＰＰ（3rd Generation Partnership Project）では、ＬＴＥ（Long Term Evolution）やＬＴＥをベースとしたＬＴＥ−Ａ（LTE-Advanced）などの通信規格の標準化が完了若しくは検討されている。

このような標準規格の中でＬＴＥに関しては、２０１０年に、日本においてその運用が開始された。現在ではＬＴＥによるサービスエリアが除々に拡大している。ＬＴＥ以前の所謂、第３世代、又は第３．５世代などの無線通信システム（以下、「３Ｇシステム」と称する場合がある）を利用するユーザは、今後、除々にＬＴＥに移行していくことが予想される。ただし、３Ｇシステム自体は、３Ｇシステムを利用するユーザなどを考慮して、今後、数十年（例えば２０年）以上存続し、稼働することとなっている。

図１７及び図１８は３Ｇシステムの構成例を表わす図である。３Ｇシステムにおいては、ＲＮＣ（Radio Network Controller：無線ネットワーク制御装置）９００−１，９００−２が備えられている。各ＲＮＣ９００−１，９００−２は、配下に１又は複数のＢＴＳ（Base Transceiver Controller：無線基地局装置）９５０−１〜９５０−６を収容し、配下のＢＴＳ９５０−１〜９５０−６を制御することができる。

例えば、ＲＮＣ９００−１は、ＭＳ（Mobile Station：端末装置）９７０で測定された通信品質に基づいて、ＭＳ９７０が接続するＢＴＳ９５０−１を他のＢＴＳ９５０−２〜９５０−６に切り替えることができる。このような切り替えは、例えば、ダイバシティハンドオーバと称される場合がある。

また、各ＲＮＣ９００−１，９００−２は、例えば、配下のＢＴＳ９５０−１〜９５０−６との間、または、配下のＢＴＳ９５０−１〜９５０−６を介しＭＳ９７０との間で、ユーザデータや制御信号などを送受信することができる。

この場合、各ＲＮＣ９００−１，９００−２は、例えば、コントロールプレーン（Ｃｏｎｔｒｏｌｌ−Ｐｌａｎｅ：C-Plane、以下、「Ｃ−Ｐｌａｎｅ」と称する場合がある）のプロトコルに従って、制御信号を送受信する。また、各ＲＮＣ９００−１，９００−２は、ユーザプレーン（Ｕｓｅｒ−Ｐｌａｎｅ：U-Plane、以下、「Ｕ−Ｐｌａｎｅ」と称する場合がある）のプロトコルに従って、ユーザデータを送受信する。各ＲＮＣ９００−１，９００−２は、Ｃ−Ｐｌａｎｅの信号とＵ−Ｐｌａｎｅのデータなどを終端させることができる。

さらに、各ＲＮＣ９００−１，９００−２は、例えば、Ｕ−Ｐｌａｎｅ上のコントロールフレームであるＨＳ−ＤＳＣＨ＿ＦＰ（High Speed Downlink Shared Channel Frame Protocol）を利用して、配下のＢＴＳ９５０−１〜９５０−６との間でフロー制御を行うこともできる。このフロー制御によって、各ＲＮＣ９００−１，９００−２はデータの送信が規制されて、ＭＳ９７０側における輻輳やバッファオーバーフローを回避させることができる。

なお、図１７に示す３Ｇシステムは、ある地域（Ａ地域）において、複数のＲＮＣ９００−１，９００−２を備える例を表わしている。また、図１８に示す３Ｇシステムは、複数の地域（Ａ地域とＢ地域）の各々において、複数のＲＮＣ９００−１〜９００−４を備える例を表わしている。

一方、ＲＮＣ装置内においては、例えば、Ｕ−ＰｌａｎｅとＣ−Ｐｌａｎｅによるデータや信号などを終端させるため、機能ブロックを備えている。このような機能ブロックは、物理的にはカード（または基板、以下、「カード」と称する場合がある）という単位でＲＮＣ装置内に存在する。上述したように、ＬＴＥによる無線通信システムへの移行によって、３Ｇシステムを利用したトラヒックは現在よりも除々に少なくなることが予想される。そのため、３Ｇシステムの数十年以上の運用において、カードの故障なども考慮すると、ＲＮＣ内には現在よりも使用頻度の低いカードが存在することが予想される。

他方、ＲＮＣに関する技術について、例えば、以下のような技術が開示されている。すなわち、無線回線制御装置（ＲＮＣ）をコントロールプレーン制御部（ＲＣＳ）とユーザプレーン制御部（ＵＰＳ）とに分離し、さらに、複数のＵＰＳ間において負荷状況に応じてＭＡＣ−ｄ／ＲＬＣリソースをシェアし合うようにした移動通信システムがある。

また、ユーザの位置別トラヒックや、ユーザの時刻別トラヒック、ユーザの契約内容などに応じて帯域を確保することで、無通信状態のパケット交換ユーザの急増に対応できるようにした無線ネットワーク制御装置がある。

特開２００５−２５２５０２号公報 国際公開番号ＷＯ２００５／０６７２２６

しかしながら、複数のＵＰＳ間においてＭＡＣ−ｄ／ＲＬＣリソースをシェアし合う技術は、無線回線制御装置（ＲＮＣ）をＲＣＳとＵＰＳの２つのブロックに分離させるようにしている。従って、Ｃ−ＰｌａｎｅとＵ−Ｐｌａｎｅの双方を１つのＲＮＣで処理する現在の３Ｇシステムにおいては、別途、２つのブロックに分離させることになり、システム構成が変更されることになる。したがって、かかる技術では、３Ｇシステムの変更によって、運用コストがこれまでよりも増加する場合がある。

また、ユーザの位置別トラヒックなどにより帯域確保を行う技術の場合、単に帯域確保を行うだけであって、ＲＮＣの長期運用を図る上で何ら対処方法を提示するものではない。

他方、ＲＮＣは、所謂ＥＯＬ（End Of Life、またはEnd Of Service Life）にて装置の保守と運用を図る場合がある。例えば、サービス期間内においては、ＲＮＣ内の部品を交換させることができ、これにより、ＲＮＣを継続して運用させることができる。

しかし、部品メーカーなどが倒産などした場合、部品交換することができず、別途新たにハードウェアを設計し直す場合がある。このような場合、新たなハードウェアの設計によって、ＲＮＣの運用コストが初期開発並みとなる場合がある。従って、ＲＮＣの数十年以上の継続運用を考慮すると、ＥＯＬにて対処することは困難である。

そこで、本発明の一目的は、現在のシステムや装置を変更しないで、長期運用が可能な無線ネットワーク制御装置、無線ネットワーク制御装置におけるリソース共有方法、及び無線通信ネットワークシステムを提供することにある。

また、本発明の一目的は、運用コストを増加させないようにした無線ネットワーク制御装置、無線ネットワーク制御装置におけるリソース共有方法、及び無線通信ネットワークシステムを提供することにある。

一態様によれば、配下の無線基地局装置を制御する無線ネットワーク制御装置において、ユーザプレーンのデータを処理する機能を有する第１の機能部と、前記無線ネットワーク制御装置は他の無線ネットワーク制御装置のアドレス情報を保持し、前記無線ネットワーク制御装置のアドレス情報を保持する前記他の無線ネットワーク制御装置に対し、前記第１の機能部における第１のリソースと前記他の無線ネットワーク制御装置においてユーザプレーンのデータを処理する機能を有する第２の機能部における第２のリソースとを共有する制御部を備える。

現在のシステムや装置を変更しないで、長期運用が可能な無線ネットワーク制御装置、無線ネットワーク制御装置におけるリソース共有方法、及び無線通信ネットワークシステムを提供することができる。また、運用コストを増加させないようにした無線ネットワーク制御装置、無線ネットワーク制御装置におけるリソース共有方法、及び無線通信ネットワークシステムを提供することができる。

図１は無線通信ネットワークシステムの構成例を表わす図である。 図２は無線通信ネットワークシステムの構成例を表わす図である。 図３はＩｕｒの範囲を説明するための図である。 図４は無線通信ネットワークシステムにおいてデータの流れを表わす図である。 図５は各機能ブロックがＵ−ＰｌａｎｅかＣ−Ｐｌａｎｅかを示す図である。 図６は無線ネットワーク制御装置の構成例を表わす図である。 図７（Ａ）及び図７（Ｂ）はプロトコルスタックの例を表わす図である。 図８はリソース共有動作を表わすシーケンス図である。 図９（Ａ）はＵ−Ｐｌａｎｅリソース共有リスト、図９（Ｂ）はリソース共有リストの例をそれぞれ表わす図である。 図１０は使用可能Ｕ−Ｐｌａｎｅリソース数変化検出時の動作例を表わすフローチャートである。 図１１はリソース共有リスト受信時の動作例を表わすフローチャートである。 図１２は対象ＲＮＣを選択する動作例を表わすフローチャートである。 図１３（Ａ）は優先度決定要素リストの例、図１３（Ｂ）はリソース予約リストの例をそれぞれ表わす図である。 図１４は必要リソース数算出処理の動作例を表わすフローチャートである。 図１５はリソース払い出し処理の動作例を表わすシーケンス図である。 図１６はリソース使用管理テーブルの例を表わす図である。 図１７は３Ｇシステムの構成例を表わす図である。 図１８は３Ｇシステムの構成例を表わす図である。

以下、本発明を実施するための形態について説明する。

［第１の実施の形態］
最初に第１の実施の形態について説明する。図１は第１の実施の形態における無線通信ネットワークシステム１０の構成例を表わす図である。無線通信ネットワークシステム１０は、第１の無線ネットワーク制御装置１００−１、第２の無線ネットワーク制御装置１００−２、及び無線基地局装置３００を備える。

第１及び第２の無線ネットワーク制御装置１００−１は、配下に１又は複数の無線基地局装置を収容し、収容する無線基地局装置を制御する。図１の例では、第１の無線ネットワーク制御装置１００−１は、無線基地局装置３００を収容している。

第１の無線ネットワーク制御装置１００−１は第２の無線ネットワーク制御装置１００−２のアドレス情報を保持し、第２の無線ネットワーク制御装置１００−２は第１の無線ネットワーク制御装置１００−１のアドレス情報を保持している。このように互いにアドレス情報を保持している関係で接続されている無線ネットワーク制御装置は、例えば、１つのＩｕｒの範囲内にある無線ネットワーク制御装置となっている。図１の例では、第１の無線ネットワーク制御装置１００−１と第２の無線ネットワーク制御装置１００−２とが、１つのＩｕｒの範囲内にある無線ネットワーク制御装置となっている。

第１の無線ネットワーク制御装置１００−１は、制御部１８０と第１の機能部１８５−１を備える。また、第２の無線ネットワーク制御装置１００−２は、第２の機能部１８５−２を備える。

第１の機能部１８５−１は、第１の無線ネットワーク制御装置１００−１においてユーザプレーンのデータを処理する機能を有する。また、第２の機能部１８５−２は、第２の無線ネットワーク制御装置１００−２においてユーザプレーンのデータを処理する機能を有する。

制御部１８０は、第１の機能部１８５−１における第１のリソースと、第２の機能部１８５−２における第２のリソースとを共有する。

このように、第１の実施の形態では、第１の無線ネットワーク制御装置１００−１において、第１のリソースと第２のリソースとが共有されている。従って、例えば、第１のリソースが不足している場合や、第１の機能部１８５−１が故障などで使用できない場合、第１の無線ネットワーク制御装置１００−１は第２の無線ネットワーク制御装置１００−２における第２のリソースを利用することができる。そして、例えば、第１の無線ネットワーク制御装置１００−１は、第２のリソースを利用して、或いは第２の機能部１８５−２を利用して、ユーザデータの送信や受信を行うことができる。

よって、第１の無線ネットワーク制御装置１００−１では、第１の機能部１８５−１の故障などにより使用することができない場合でも、新たに第１の機能部１８５−１を有するカード又は基板を設けたり、別途ケーブルを設置させることをしなくてもよい。従って、本無線通信ネットワークシステム１０では、装置やシステム全体の構成を変更せずに、２０年〜３０年などの長期運用が可能となる。また、このようなシステムや装置の変更を伴わないため、本無線通信ネットワークシステム１０では、運用コストが増加することもない。

さらに、本第１の実施の形態における適用範囲はＩｕｒの範囲としている。例えば、第１及び第２の無線ネットワーク制御装置１００−１，１００−２は、Ｉｕｒの範囲外へ通信を行う場合に、新たにケーブルなどの配線を設置させる場合がある。しかし、適用範囲をＩｕｒの範囲とすることで、このようなケーブルを設置させることもなく、既存の接続形態を利用することができる。従って、適用範囲をＩｕｒの範囲内とすることで、本無線通信ネットワークシステム１０では、その構成を変更しなくてもよく、この点からも運用コストの増加を防止することができる。

［第２の実施の形態］
次に第２の実施の形態について説明する。

＜無線通信ネットワークシステムの構成例＞
図２は第２の実施の形態における無線通信ネットワークシステム１０の構成例を表わす図である。図２に示す無線通信ネットワークシステム１０は、例えば、ＬＴＥ以前の、所謂第３世代、又は第３．５世代と呼ばれる無線通信ネットワークシステムの例を表わしている。このような無線通信ネットワークシステムを本実施の形態では「３Ｇシステム」と適宜称する場合がある。図２に示す無線通信ネットワークシステム１０は、例えば、３Ｇシステムの一例でもある。

無線通信ネットワークシステム１０は、ＲＮＣ（Radio Network Controller：無線ネットワーク制御装置、以下では「ＲＮＣ」と称する場合がある）１００−１〜１００−３、ＢＴＳ（Base Transceiver Station：無線基地局装置、以下では「ＢＴＳ」と称する場合がある）３００−１１〜３００−３１、ＭＳ（Mobile Station：端末装置、以下では「ＭＳ」と称する場合がある）５００、及びＣＮ（Core Network：コアネットワーク、以下では「ＣＮ」と称する場合がある）６００とを備える。

なお、ＲＮＣ１００−１は、例えば、第１の実施の形態における第１の無線ネットワーク制御装置１００−２に対応する。また、ＲＮＣ１００−２は、例えば、第１の実施の形態における第２の無線ネットワーク制御装置１００−２に対応する。

ＲＮＣ１００−１〜１００−３は、配下に１又は複数のＢＴＳ３００−１１〜３００−３１を収容し、収容した配下のＢＴＳ３００−１１〜３００−３１と接続される。図２の例では、ＲＮＣ１００−１は、ＢＴＳ３００−１１，３００−１２を収容して、これらのＢＴＳ３−１１，３００−１２と接続される。また、ＲＮＣ１００−２は、ＢＴＳ３００−２１，…を収用し、ＢＴＳ３００−２１，…と接続される。さらに、ＲＮＣ１００−３は、ＢＴＳ３００−３１，…を収容し、ＢＴＳ−３１，…と接続される。各ＲＮＣ１００−１〜１００−３は、配下に最大２５６台のＢＴＳ３００−１１〜３００−３１と接続させることができる。

なお、図２に示す接続形態は一例であって、ＲＮＣ１００−１は、３台以上のＢＴＳを収容して、これらのＢＴＳと接続されてもよいし、ＲＮＣ１００−２も、２台以上のＢＴＳを収容して、これらのＢＴＳと接続されてもよい。

また、ＲＮＣ１００−１〜１００−３間の接続形態についても、図２に示す例は一例であって、ＲＮＣ１００−１がＲＮＣ１００−３と直接接続され、各ＲＮＣ１００−１〜１００−３が互いに接続されてもよい。さらに、ＲＮＣ１００−１〜１００−３の数も、図２に示す例は、一例であって、１台でもよいし、２台、または４台以上であってもよい。

各ＲＮＣ１００−１〜１００−３は、配下のＢＴＳ３００−１１〜３００−３１を制御することができ、上述したダイバシティハンドオーバやフロー制御などを行うことができる。ＲＮＣ１００−１〜１００−３の構成例は後述する。

ＢＴＳ３００−１１〜３００−３１は、ＲＮＣ１００−１〜１００−３と有線接続されるとともに、各ＢＴＳ３００−１１〜３００−３１の無線通信可能範囲（例えばセル範囲）に位置するＭＳ５００と無線接続することができる。

各ＢＴＳ３００−１１〜３００−３１は、ＲＮＣ１００−１〜１００−３を介してＣＮ６００から送信されたユーザデータなどを受け取って、誤り訂正符号化処理や変調処理、周波数変換処理などを行い、無線信号に変換する。そして、各ＢＴＳ３００−１１〜３００−３１は、変換した無線信号をＭＳ５００に送信する。また、各ＢＴＳ３００−１１〜３００−３１は、ＭＳ５００から送信された無線信号を受信し、周波数変換処理、復調処理、誤り訂正復号化処理などを行い、無線信号からユーザデータなどを抽出する。そして、各ＢＴＳ３００−１１〜３００−３１は、抽出したユーザデータなどを、ＲＮＣ１００−１〜１００−３を介してＣＮ６００に送信する。

各ＢＴＳ３００−１１〜３００−３１は、このような誤り訂正符号化処理などを行うことができるよう、内部に、誤り訂正符号化処理回路、変調処理回路、周波数変換処理回路、ＡＤ変換回路、ＢＰＦ（Band Pass Filter）、誤り訂正復号化処理回路、復調回路などを備えるようにしてもよい。

なお、図２の例では、ＢＴＳ３００−１２がＭＳ５００と無線通信を行っている例を表わしている。

ＭＳ５００は、各ＢＴＳ３００−１１〜３００−３１の無線通信可能範囲内において、各ＢＴＳ３００−１１〜３００−３１から送信された無線信号を受信したり、各ＢＴＳ３００−１１〜３００−３１へ無線信号を送信することができる。

ＭＳ５００は、各ＢＴＳ３００−１１〜３００−３１から受信した無線信号に対して、周波数変換処理や復調処理、誤り訂正復号化処理などを施して、自局宛てのユーザデータを抽出する。また、ＭＳ５００は、ユーザデータに対して、誤り訂正符号化処理や変調処理、周波数変換処理などを施して、無線信号に変換し、変換した無線信号を各ＢＴＳ３００−１１〜３００−３１に送信する。

ＭＳ５００は、このような処理を行うことができるよう、内部に、誤り訂正符号化処理回路、変調処理回路、周波数変換処理回路、ＡＤ変換回路、ＢＰＦ（Band Pass Filter）、誤り訂正復号化処理回路、復調回路などを備えるようにしてもよい。

ＭＳ５００は、ＢＴＳ３００−１２などを介して、音声通信やファイルのダウンロード、画像通信など、様々なサービスの提供を受けることができる。

ＣＮ６００は、各ＲＮＣ１００−１〜１００−３と有線接続されるネットワークであるが、ＣＮ６００には、例えば、ＳＧＳＮ（Serving GPRS (General Packet Radio Service) Support Node）やＳＩＮ（Service Integration Node）などの上位ノードが接続される。例えば、ＳＧＳＮはＭＳ５００（又はユーザ）の位置管理、セキュリティ管理を行うノードであり、ＳＩＮは音声データを終端するノードである。ＣＮ６００には、例えば、ＬＴＥ用のノードであるｘＧＳＮ（serving/gateway GPRS Support Node）などが接続されてもよい。例えば、３ＧシステムがＬＴＥなどの無線通信ネットワークシステムと併存して、３Ｇシステムに対するユーザとＬＴＥを利用するユーザとの双方にサービスを提供することができる。

ここで本第２の実施の形態において適用されるＲＮＣ１００−１〜１００−３の範囲（例えば接続範囲でもあり、適用範囲でもある）について説明する。ＲＮＣ１００−１〜１００−３に関して、本実施の形態が適用される範囲は、例えば、Ｉｕｒの範囲とする。

Ｉｕｒは、例えば、各ＲＮＣ１００−１〜１００−３を接続する論理的なインターフェースであるが、各ＲＮＣ１００−１〜１００−３が他のＲＮＣのアドレス情報（例えばＩＰ（Internet Protocol）アドレス）を保持している範囲でもある。

図２の例では、ＲＮＣ１００−１は、ＲＮＣ１００−２とＲＮＣ１００−３の各ＩＰアドレスを保持し、ＲＮＣ１００−２も、ＲＮＣ１００−１とＲＮＣ１００−３のＩＰアドレスを保持する。このようにＲＮＣ１００−１〜１００−３が互いにアドレス情報を保持しているＲＮＣ１００−１〜１００−３の範囲を、例えば、Ｉｕｒの範囲とする。図２の例では、点線で示す範囲がＩｕｒの範囲となっている。

図３も無線通信ネットワークシステム１０の例を表わしており、この例では、ＲＮＣ１００−１〜１００−１５がＩｕｒの範囲を表わしている。ＲＮＣ１００−１６，１００−１７は、ＲＮＣ１００−１と物理的に接続されているものの、Ｉｕｒの範囲内にはないＲＮＣとなっている。すなわち、ＲＮＣ１００−１から見て、ＲＮＣ１００−１６，１００−１７はＩｕｒの範囲内にはないＲＮＣとなっている。

例えば、あるビルに設置された１または複数台のＲＮＣがＩｕｒの範囲とし、他のビルに設置されたＲＮＣは、当該Ｉｕｒの範囲外とすることができる。他のビルに設置されたＲＮＣに対してはタイムラグが生じ、コントロールプレーンの信号などについて処理が遅れる場合があるからである。

また、本第２の実施の形態において適用する範囲を無限に広げると、ＲＮＣ１００−１〜１００−１５の接続形態の変更や３Ｇシステムの構成の変更などが生じる場合がある。

例えば、Ｉｕｒの範囲外へ通信を行う場合、物理的に新たなケーブルを追加したり、外部インターフェースに対する新たなリソースを設けるなど、ＲＮＣ１００−１〜１００−１５内外の変更が生じる場合がある。

しかし、その適用範囲をＩｕｒの範囲とすることで、既存のＲＮＣ１００−１〜１００−１５の接続形態について変更させることがなくなり、３Ｇシステムの構成を変更しなくてもよい、という利点が生じる。

本第２の実施の形態においては、このようなＩｕｒの範囲内にある各ＲＮＣ１００−１〜１００−３（又は１００−１〜１００−１５）は、互いに他のＲＮＣ１００−１〜１００−３のリソースを共有するようにしておく。

そして、あるＲＮＣ１００−１〜１００−３について、ユーザデータなどの送信や受信に際して足りないリソースがあると、他のＲＮＣ１００−１〜１００−３のリソースを利用して、ユーザデータなどの送信や受信を行う。

これにより、例えば、あるＲＮＣ１００−１〜１００−３において、故障などにより使用できないカード（又は基板、以下「カード」と称する場合がある）がある場合でも、他のＲＮＣ１００−１〜１００−３のカードを利用して、３Ｇシステムの長期運用（例えば２０年など）が可能となる。

よって、本無線通信ネットワークシステム１０では、現在のシステムや装置を変更しないで、３Ｇシステムによる長期運用が可能となる。また、無線通信ネットワークシステム１０は、運用コストを増加させないようにすることもできる。

図４は、リソース共有後におけるユーザデータの流れの例を表わす図である。この例では、ＲＮＣ１００−１は、自局ＲＮＣ１００−１のリソースが不足しているため、Ｉｕｒ範囲内の他のＲＮＣ１００−２のリソースを利用している。そして、ＲＮＣ１００−１は、他のＲＮＣ１００−２のリソースを利用して、ユーザデータなどをＣＮ６００やＢＴＳ３００−１１に送信したり、ＣＮ６００やＢＴＳ３００−１１からユーザデータなどを受信している。

本第２の実施の形態における動作については、１）Ｉｕｒの範囲内において、ＲＮＣ１００−１〜１００−３間でリソースを共有し、２）共有したリソースを用いてユーザデータなどの送信や受信を行う、という動作を行うことになる。後述する動作例においては、これら２つの動作例を分けて説明することにする。

なお、本第２の実施の形態において、「リソース」とは、例えば、１つの物理的なカード又は基板において払い出すことのできる帯域の数、またはコネクションの数である。例えば、カードには、ある機能を実行する機能部又は処理部が設けられており、「リソース」はそのような機能部又は処理部において処理することのできる帯域の数、またはコネクションの数となる。このような機能部の詳細については後述する。

各ＲＮＣ１００−１〜１００−３は種々のリソースを有している。以下、ＲＮＣ１００−１〜１００−３内の各リソースの例について説明する。なお、ＲＮＣ１００−１〜１００−３については、とくに断らない限り、ＲＮＣ１００として以下説明する。

図５はＲＮＣ１００内のリソースの例を表わす図である。図５において、「ＦＢ」は機能ブロック（Function Block）を表わし、ＲＮＣ１００内においては全部で１２個の機能ブロックあることを表わしている。例えば、「ＤＨＯ」という機能ブロックがＲＮＣ１００に存在し、「ＤＨＯ」というリソースを有していることを表わしている。「ＤＨＯ」などの各機能ブロックの詳細は後述する。

図５に示すように、各機能ブロックについてはコントロールプレーン（Control-Plane、以下、「Ｃ−Ｐｌａｎｅ」と称する場合がある）とユーザプレーン（User-Plane、以下、「Ｕ−Ｐｌａｎｅ」）に分類することができる。ここで、Ｃ−Ｐｌａｎｅとは、例えば、無線通信ネットワークシステム１０において制御用の信号を伝送するためのプロトコルである。また、Ｕ−Ｐｌａｎｅとは、例えば、無線通信ネットワークシステム１０においてユーザデータを伝送するためのプロトコルである。

例えば、「ＭＭＵＸ」、「ＳＣＴＰ」、「ＡＴＭ−ＩＦ」、「ＩＰ−ＩＦ」の各機能ブロックは、Ｃ−Ｐｌａｎｅに関するリソースである。「ＩＰ−ＩＦ」など機能ブロックでは、制御用の信号に対する処理を行うからである。

また、「ＤＨＯ」、「ＤＣＣＨ」、「ＲＬＣ」、「ＨＳＤＰＡ」、「ＨＳＵＰＵ」などの機能ブロックは、例えば、Ｕ−Ｐｌａｎｅに関するリソースである。「ＤＨＯ」などの機能ブロックでは、ユーザデータに対する処理などを行うからである。

ここで、Ｃ−Ｐｌａｎｅのリソースについては、対向ノードとの間で制御線などの信号線又はケーブルが物理的に接続されており、例えば、対向ノードと固定的に括りつけられたリソースとなっている。Ｃ−Ｐｌａｎｅに関するリソースが共有される場合、共有化後、他のＲＮＣのＣ−Ｐｌａｎｅを利用するためには、当該他のＲＮＣとの間でＣ−Ｐｌａｎｅ用のケーブルが物理的に接続されることが必要になってくる。このような物理的なケーブルが接続されて初めて、例えば、図４に示すように他のＲＮＣにおけるＣ−Ｐｌａｎｅ用のリソースを利用して制御信号を送信したり、受信したりすることができる。

しかし、共有させるＲＮＣ間でケーブルが接続されていない場合、別途、ＲＮＣ間でケーブルを別途接続させることになり、ＲＮＣ間の接続形態が変更されることになる。このような場合、３Ｇシステムも変更され、ケーブルの接続前と比較して、３Ｇシステムの運用のためにコストが増加する場合がある。

そこで、本第２の実施の形態では、共有させるリソースについては、Ｕ−Ｐｌａｎｅのリソースとし、Ｃ−Ｐｌａｎｅのリソースについては共有化させないこととした。ＲＮＣ１００−１〜１００−３間で共有対象となるリソースは、「ＤＨＯ」や「ＤＣＣＨ」などのＵ−Ｐｌａｎｅのリソースとしている。

＜ＲＮＣの構成例＞
次にＲＮＣ１００の構成例について説明する。図６はＲＮＣ１００の構成例を表わす図である。

ＲＮＣ１００は、ＬＴ部（又はＣ−Ｐｌａｎｅ用ＦＢ（Function Block：機能ブロック）部、以下、「Ｃ−Ｐｌａｎｅ用ＦＢ部」と称する場合がある）１１０、Ｌ２ＳＷ（Layer 2 Switch）１２０、ＴＲＫ部（又はＵ−Ｐｌａｎｅ用ＦＢ部、以下、「Ｕ−Ｐｌａｎｅ用ＦＢ部」と称する場合がある）１３０、ＣＯＮＴ部（Controller：制御部、以下、「ＣＯＮＴ部」と称する場合がある）１５０、及びメモリ１７０を備える。

なお、Ｕ−Ｐｌａｎｅ用ＦＢ部１３０は、例えば、第１の実施の形態における第１の機能部１８５−１又は第２の機能部１８５−２に対応する。或いは、Ｕ−Ｐｌａｎｅ用ＦＢ部１３０に含まれる、ＤＨＯ機能部１３１、ＲＬＣ機能部１３２、ＨＳＤＰＡ機能部１３３、ＨＳＵPU機能部１３４、及びＤＣＣＨ機能部１３５は、例えば、第１の実施の形態における第１の機能部１８５−１又は第２の機能部１８５−２に対応する。また、ＣＯＮＴ部１５０は、例えば、第１の実施の形態における制御部１８０に対応する。

Ｃ−Ｐｌａｎｅ用ＦＢ部１１０は、例えば、Ｃ−Ｐｌａｎｅ用の制御信号に対する処理を行う機能ブロックである。Ｃ−Ｐｌａｎｅ用ＦＢ部１１０は、例えば、ＲＮＣ１００においては、１枚又は複数枚のカード（又は基板）として配置される。図６の例では、Ｃ−Ｐｌａｎｅ用ＦＢ部１１０は１枚のカードとして表わされているが、これが複数枚あってもよい。

また、Ｃ−Ｐｌａｎｅ用ＦＢ部１１０は、例えば、対向ノードと制御線又はケーブルを介して接続されており、ＲＮＣ１００と対向ノードとの接続形態によっては、Ｃ−Ｐｌａｎｅ用ＦＢ部１１０が接続される制御線の本数や接続のされ方なども変わってくる。

図６の例では、Ｃ−Ｐｌａｎｅ用ＦＢ部１１０は、２つのＩＰ−ＩＦ（Internet Protocol-Interface：インターネットプロトコルインターフェース）１１１，１１２、ＡＴＭ−ＩＦ（Asynchronous Transfer Mode-Interface：非同期転送モードインターフェース）１１３、及びＳＣＴＰ（Stream Control Transmission Protocol：ストリーム制御伝送プロトコル）機能部１１４を備える。

ＩＰ−ＩＦ１１１，１１２は、対向ノードから送信されたＩＰパケットを受信し、受信したＩＰパケットからＣ−Ｐｌａｎｅ用の信号とＵ−Ｐｌａｎｅ用のデータとを抽出する。ＩＰ−ＩＦ１１１，１１２は、例えば、抽出したＣ−Ｐｌａｎｅ用の信号を、Ｌ２ＳＷ１２０を介してＣＯＮＴ部１５０に出力する。また、ＩＰ−ＩＦ１１１，１１２は、抽出したＵ−Ｐｌａｎｅ用のデータをＬ２ＳＷ１２０に出力する。

また、ＩＰ−ＩＦ１１１，１１２は、Ｌ２ＳＷ１２０から出力されたデータなどに対して、Ｃ−Ｐｌｎｅ用の信号を付加するなどしてＩＰパケットを生成し、対向ノードに送信する。Ｃ−Ｐｌａｎｅ用の信号は、例えば、ＣＯＮＴ部１５０からＬ２ＳＷ１２０を介して受け取ることができる。

図６の例では、ＩＰ−ＩＦ１１１は、対向ノードとして、配下のＢＴＳ（例えばＩＰ−ＢＴＳ（Internet Protocol-BTS））、隣接するＲＮＣ、上位ノードなどと接続される。また、ＩＰ−ＩＦ１１２は、ＬＴＥネットワークのｘＧＳＮ（serving/gateway General Packet radio Service Node）、ＳＩＮ（Signaling Inter-working Node）などの上位ノードと接続される。

ＡＴＭ−ＩＦ１１３は、対向ノードとして、例えば、配下のＢＴＳ（ＡＴＭ−ＢＴＳなど）と接続され、配下のＢＴＳから送信されたＡＴＭパケットなどを受信する。ＡＴＭ−ＩＦ１１３は、受信したＡＴＭパケットからＣ−Ｐｌａｎｅ用の信号とＵ−Ｐｌａｎｅ用のデータなどを抽出し、抽出したデータや信号などをＬ２ＳＷ１２０に出力する。

また、ＡＴＭ−ＩＦ１１３は、Ｌ２ＳＷ１２０から出力されたデータなどを受け取り、Ｃ−Ｐｌａｎｅ用の信号を付加するなどして、ＡＴＭパケットを生成し、ＡＴＭ−ＢＴＳに送信する。ＡＴＭ−ＩＦ１１３は、Ｃ−Ｐｌａｎｅ用の信号を、Ｌ２ＳＷ１２０を介してＣＯＮＴ部１５０から受け取ることができる。

ＳＣＴＰ機能部１１４は、配下のＢＴＳとの間でＳＣＴＰプロトコルの信号を終端させる。ＳＣＴＰ機能部１１４は、例えば、Ｌ２ＳＷ１２０とＩＰ−ＩＦ１１１，１１２などを介して、配下のＢＴＳとの間で、ＳＣＴＰプロトコルの信号などを交換する。

Ｌ２ＳＷ１２０は、Ｃ−Ｐｌａｎｅ用ＦＢ部１１０とＵ−Ｐｌａｎｅ用ＦＢ部１３０との間でデータなどが交換できるよう、ＣＯＮＴ部１５０からの制御信号に従って経路を切り替える。例えは、Ｌ２ＳＷ１２０は、ＣＯＮＴ部１５０からの制御信号に従って、Ｃ−Ｐｌａｎｅ用ＦＢ部１１０から出力されたデータなどをＵ−Ｐｌａｎｅ用ＦＢ部１３０のいずれかの機能ブロック１３１〜１３５に出力する。また、Ｌ２ＳＷ１２０は、ＣＯＮＴ部１５０からの制御信号に従って、Ｕ−Ｐｌａｎｅ用ＦＢ部１３０から出力されたデータなどを、Ｃ−Ｐｌａｎｅ用ＦＢ部１１０のいずれかの機能ブロック１１１〜１１４に出力する。

また、Ｌ２ＳＷ１２０は、ＩＰ−ＩＦ１１１，１１２とＳＣＴＰ機能部１１４との間で信号などを交換できるよう、ＣＯＮＴ部１５０からの制御信号に従って、経路を切り替えることができる。更に、Ｌ２ＳＷ１２０は、Ｕ−Ｐｌａｎｅ用ＦＢ部１３０の各機能ブロック１３１〜１３５間でデータなどを交換できるよう、ＣＯＮＴ部１５０からの制御信号に従って、経路を切り替えることができる。

Ｕ−Ｐｌａｎｅ用ＦＢ部１３０は、例えば、Ｕ−Ｐｌａｎｅ用のユーザデータなどに対する処理を行う機能ブロックである。Ｕ−Ｐｌａｎｅ用ＦＢ部１３０も、Ｃ−Ｐｌａｎｅ用ＦＢ部１１０と同様に、例えば、ＲＮＣ１００においては、１枚又は複数枚のカード（又は基板）として挿入されている。図６の例では、Ｕ−Ｐｌａｎｅ用ＦＢ部１３０は１枚のカードとして表わされているが、これが複数枚あってもよい。

Ｕ−Ｐｌａｎｅ用ＦＢ部１３０は、ＭＡＣ機能部と、ＤＨＯ（Diversity Hand Over：ダイバシティハンドオーバ）機能部１３１、ＲＬＣ（Radio Link Control：無線リンク制御）機能部１３２、ＨＳＤＰＡ（High Speed Downlink Packet Access：高速ダウンリンクパケットアクセス）機能部１３３、ＨＳＵＰＵ（High Speed Uplink Packet Access：高速アップリンクパケットアクセス）機能部１３４、ＤＣＣＨ（Dedicated Control Channel：専用制御チャネル）機能部１３５を備える。

図７（Ａ）はダウンリンク方向、図７（Ｂ）はアップリンク方向におけるプロコトルスタックの例をそれぞれ表わしている。Ｕ−Ｐｌａｎｅ用ＦＢ部１３０の各機能ブロック１３１〜１３５については適宜、これらの図を参照しながら説明する。

ＤＨＯ機能部１３１は、ダイバシティハンドオーバが行われる場合の選択合成機能や複製分配機能、無線品質の測定機能などの各機能を有する。

すなわち、ＤＨＯ機能部１３１は、例えば、ダイバシティハンドオーバにおいて、複数のＢＴＳ３００−１１，３００−１２で受信した、同一のＭＳ５００からのユーザデータを、Ｌ２ＳＷ１２０を介して受け取り、無線状態などに基づきいずれかを選択する処理を行う。また、ＤＨＯ機能部１３１は、例えば、ダイバシティハンドオーバにおいて、ＭＳ５００宛ての下りユーザデータを複製し、複製した各ユーザデータを、Ｌ２ＳＷ１２０などを介して各ＢＴＳ３００−１１，３００−１２に送信する処理なども行う。

また、ＤＨＯ機能部１３１は、例えば、ＣＳ（Circuit Switch：回線交換）呼に対する秘匿設定機能や解除機能などを有する。この場合、ＤＨＯ機能部１３１は、ＭＳ５００から送信された音声データやＭＳ５００宛ての音声データに対して暗号化などや暗号化に対する復号化などを行うことで、秘匿設定機能や解除機能を実行する。

ＲＬＣ機能部１３２は、例えば、ＭＳ間で送受信されるＲＬＣパケットを終端させる機能を有する（例えば図７（Ａ）及び図７（Ｂ）参照）。

例えば、ＲＬＣ機能部１３２は、Ｌ２ＳＷ１２０を介し、上位ノードから受信したＭＳ５００宛ての下りデータに対して、ＲＬＣパケットを生成する。そして、ＲＬＣ機能部１３２は、Ｌ２ＳＷ１２０などを介して、生成したＲＬＣパケットを配下のＢＴＳ３００に送信する。ＲＬＣパケットは、ＢＴＳ３００からＭＳ５００に送信され、ＭＳ５００において終端される。

また、ＲＬＣ機能部１３２は、例えば、ＰＳ（Packet Switch：パケット交換）呼に対する秘匿設定機能や解除機能を有する。この場合、ＲＬＣ機能部１３２は、ＲＬＣパケットに含まれるデータなどに対して暗号化したり、暗号化されたデータを復号化したりすることで、秘匿設定機能や解除機能などを実行する。

ＨＳＤＰＡ機能部１３３は、例えば、ＭＡＣ−ｄ（Media Access Control-dedicated channel）パケットを終端させる機能を有する（例えば図７（Ａ）参照）。

例えば、ＨＳＤＰＡ機能部１３３は、ＲＬＣ機能部１３２で生成したＲＬＣパケットを、Ｌ２ＳＷ１２０を介して入力し、当該ＲＬＣパケットに対して、ヘッダなどを付加するなどして、ＭＡＣ−ｄパケットのデータに変換する。ＭＡＣ−ｄパケットも、ＭＳ５００まで伝送されて、ＭＳ５００にて終端される。

また、ＨＳＤＰＡ機能部１３３は、例えば、ＨＳ−ＤＳＣＨ＿ＦＰ（High Speed-Downlink Shared Channel Frame Protocol）のパケットを終端させる機能を有する（例えば図７（Ａ）参照）。ＨＳ−ＤＳＣＨ＿ＦＰは、ＲＮＣ１００とＢＴＳ３００との間で終端されるプロコトルである。ＨＳ−ＤＳＣＨ＿ＦＰにおけるフレームの種別としては、ユーザデータを伝送するＨＳ−ＤＳＣＨデータフレームと、制御データなどを伝送するＨＳ−ＤＳＣＨ制御フレームとがある。前述のフロー制御は、ＨＳ−ＤＳＣＨ制御フレームを利用して、ＢＴＳ３００主導によって行われる。

例えば、ＨＳＤＰＡ機能部１３３は、生成したＭＡＣ−ｄパケットに対して、ヘッダなどを付加するなどして、ＨＳ−ＤＳＣＨデータフレームに変換し、変換したＨＳ−ＤＳＣＨフレームを、Ｌ２ＳＷ１２０を介して配下のＢＴＳ３００に送信する。ＨＳ−ＤＳＣＨデータフレームは、ＢＴＳ３００にて終端される。この場合、ＨＳ−ＤＳＣＨデータフレームに含まれるＲＬＣパケット（又はＭＡＣ−ｄパケット）はＢＴＳ３００にて抽出されて、ＭＳ５００に送信される（例えば、図７（Ａ）参照）。

ＨＳＵＰＵ機能部１３４は、例えば、ＥＤＣＨ＿ＦＰ（Enhanced Dedicated Channel Frame Protocol）終端機能、ＭＡＣ−ｅｓ／ＭＡＣ−ｄ変換機能などを有する。

ＥＤＣＨ＿ＦＰは、例えば、ＲＮＣ１００とＢＴＳ３００間で終端されるプロトコルである。例えば、ＨＳＵＰＵ機能部１３４は、Ｌ２ＳＷ１２０を介して、ＭＳ５００から送信されたＥ−ＤＣＨ＿ＦＰのパケットを受け取ると、当該パケットに含まれるＭＡＣ−ｅｓパケットを抽出し、Ｅ−ＤＣＨ＿ＦＰのパケットを終端させる（例えば、図７（Ｂ）参照）。

そして、ＨＳＵＰＵ機能部１３４は、例えば、ＭＡＣ−ｅｓパケットに含まれるＭＡＣ−ｄパケットを抽出することで、ＭＡＣ−ｅｓパケットをＭＡＣ−ｄパケットに変換する。ＭＡＣ−ｄパケットは、例えば、Ｌ２ＳＷ１２０を経由してＲＬＣ機能部１３２に出力され、ＲＬＣ機能部１３２においてＭＡＣ−ｄパケット及びＲＬＣパケットが終端され、これらのパケットに含まれるユーザデータなどがＬ２ＳＷ１２０などを介して、上位ノードに送信される。

ＤＣＣＨ機能部１３５は、ＵＭ（Unacknowledged Mode：非送達確認モード）及びＡＭ（Acknowledge Mode：送達確認モード）の各ＲＬＣパケットを終端させる機能やＤＣＣＨ秘匿設定及び解除機能などを有する。

ＲＬＣプロトコルでは、例えば、動作モードとしてＵＭとＡＭとがあり、ＵＭでは送達確認を行うことなくＲＬＣパケットが伝送され、ＡＭでは送達確認を行ってＲＬＣパケットが伝送される。例えば、ＤＣＣＨ機能部１３５は、上位ノードからのデータに対してＵＭ及びＡＭのＲＬＣパケットに変換して、ＨＳＤＰＡ機能部１３３などを介して、ＭＳ５００に送信する（例えば、図７（Ａ）など）。

また、ＤＣＣＨ機能部１３５は、例えば、ＨＳＵＰＵ機能部１３４などを介して、ＭＳ５００から送信されたＵＭ及びＡＭのＲＬＣパケットを終端させて、ユーザデータを抽出し、Ｌ２ＳＷ１２０などを介して上位ノードに送信する（例えば、図７（Ｂ）など）。ただし、ＲＬＣ機能部１３２においても、ＡＭのＲＬＣパケットを終端させることもできる。

ＣＯＮＴ部１５０は、Ｌ２ＳＷ１２０に入力されるデータなどを監視し、例えば、ヘッダなどからパケットの種別を判別することで、入力されたデータなどを各機能ブロック１１１〜１１４，１３１〜１３５に出力させる。この場合、ＣＯＮＴ部１５０は、各機能ブロック１１１〜１１４，１３１〜１３５にデータなどを出力させるよう制御信号をＬ２ＳＷ１２０に出力する。

また、ＣＯＮＴ部１５０は、メモリ１７０に記憶されたＵ−Ｐｌａｎｅリソース共有リスト１７１にアクセスし、必要な項目を読み出して、「リソース共有リスト」として他のＲＮＣに送信する。さらに、ＣＯＮＴ部１５０は、他のＲＮＣから送信された「リソース共有リスト」を受信したとき、当該リストに含まれる情報をメモリ１７０に記憶されたＵ−Ｐｌａｎｅリソース共有リスト１７１に適宜記憶することもできる。Ｕ−Ｐｌａｎｅリソース共有リスト１７１と「リソース共有リスト」の詳細は後述する。

ＣＯＮＴ部１５０は、トラヒック監視部１５１、アプリケーション部１５２、及びミドルウェア部１５３を備える。

トラヒック監視部１５１は、Ｌ２ＳＷ１２０に入力されるデータなどのトラヒックを監視し、例えば、ヘッダに含まれる情報に基づいて、Ｌ２ＳＷ１２０の切り替えを制御する制御信号を出力する。

アプリケーション部１５２は、例えば、ＭＳ５００との間において呼に対する処理を行う呼処理機能や、ＲＮＣ１００内の各機能ブロック１１１〜１３５に対する監視などのＯ＆Ｍ機能などを有する。また、アプリケーション部１５２は、Ｌ２ＳＷ１２０やＩＰ−ＩＦ１１１，１１２を介して上位ノードとの間で、制御メッセージなどを交換する。

ミドルウェア部１５３も、例えば、呼処理機能やＯ＆Ｍ機能などを有する。また、ミドルウェア部１５３は、Ｌ２ＳＷ１２０などを介して他のＲＮＣのミドルウェア部との間で制御メッセージを交換する。

メモリ１７０は、例えば、Ｕ−Ｐｌａｎｅリソース共有リスト１７１、優先度決定要素リスト１７２、リソース管理テーブル１７３などを記憶する。これらの各リスト１７１〜１７３の詳細は後述する。

ここで、図６に示す各機能ブロック１１１〜１１４，１３１〜１３５と、図５に示す各機能ブロックとの対応関係について説明すると、例えば、以下のようになる。

すなわち、図５に示す「ＣＯＮＴ」は、ＲＮＣ１００のＣＯＮＴ部１５０に対応し、図５に示す「ＤＨＯ」は、ＲＮＣ１００のＤＨＯ機能部１３１に対応する。また、図５の「ＤＣＣＨ」は、ＲＮＣ１００のＤＣＣＨ機能部１３５に対応し、図５の「ＲＬＣ」は、ＲＮＣ１００のＲＬＣ機能部１３２に対応する。さらに、図５の「ＨＳＤＰＡ」と「ＨＳＵＰＵ」は、ＲＮＣ１００のＨＳＤＰＡ機能部１３３とＨＳＵＰＵ機能部１３４にそれぞれ対応する。また、図５の「ＳＣＴＰ」、「ＡＴＭ−ＩＦ」、「ＩＰ−ＩＦ」は、ＲＮＣ１００のＳＣＴＰ機能部１１４、ＡＴＭ−ＩＦ１１３、ＩＰ−ＩＦ１１１，１１２にそれぞれ対応する。

以下においては、ＲＮＣ１００の各機能ブロック１１１〜１１４，１３１〜１３５について、例えば、リソースと称する場合がある。

＜動作例＞
次に動作例について説明する。本第２の実施の形態では、リソースを共有する動作と、共有後の動作について分けて説明する。例えば、図８から図１４（Ｂ）はリソース共有動作の例、図１５及び図１６はリソース共有後の動作の例をそれぞれ表わす図である。最初にリソース共有動作について説明し、次に共有後の動作について説明する。

＜リソース共有動作＞
前述したように、ＲＮＣ１００−１は、自局のＲＮＣ１００−１のＵ−Ｐｌａｎｅリソースが不足している場合、他のＲＮＣ１００−２，１００−３，…のＵ−Ｐｌａｎｅリソースが利用可能であれば、当該リソースを利用することができる。これにより、例えば、ＲＮＣ１００−１は、ＲＮＣ１００−２のリソースを利用して、ユーザデータの送信や受信などの動作を行うことができる。このようなリソースの共有動作について、図８〜図１４（Ｂ）を用いて以下説明することにする。

図８はリソース共有動作の例を表わすシーケンス図である。この例では、３つのＲＮＣ１００−１〜１００−３が１つのＩｕｒの範囲となっており、ＲＮＣ１００−１〜１００−３間でＵ−Ｐｌａｎｅのリソースを共有し合うこととする。また、ＲＮＣ１００−１の電源立ち上げ時（又は再開時）の動作例を表わしている。

ＲＮＣ１００−１は、再開時に他のＲＮＣ１００−２，１００−３に「リソース共有リスト」を送付する（Ｓ１０）。ここで、「リソース共有リスト」とＵ−Ｐｌａｎｅリソース共有リスト１７１の詳細について説明する。

図９（Ａ）はＵ−Ｐｌａｎｅリソース共有リスト１７１、図９（Ｂ）は「リソース共有リスト」の例をそれぞれ表わす図である。Ｕ−Ｐｌａｎｅリソース共有リスト１７１は、例えば、ＲＮＣ１００−１のメモリ１７０に記憶されたリストである。自ＲＮＣ１００−１のＵ−Ｐｌａｎｅリソース共有リスト１７１だけでなく、他のＲＮＣ１００−２，１００−３のＵ−Ｐｌａｎｅリソース共有リスト１７１もメモリ１７０に記憶される。

また、「リソース共有リスト」は、例えば、他のＲＮＣ１００−２，１００−３に送信されるリストであり、メモリ１７０に記憶されたＵ−Ｐｌａｎｅリソース共有リスト１７１の項目が含まれる。

最初にＵ−Ｐｌａｎｅリソース共有リスト１７１の詳細について説明する。図９（Ａ）に示すように、Ｕ−Ｐｌａｎｅリソース共有リスト１７１は、例えば、Ｕ−Ｐｌａｎｅのリソース毎に、どれくらいのリソース数が存在するかを示すリソース情報が含まれる。

Ｕ−Ｐｌａｎｅリソース共有リスト１７１に含まれるリソースの要素として、「ＤＨＯリソース」、「ＤＣＣＨリソース」、「ＲＬＣリソース」、「ＨＳＰＤＡリソース」、「ＨＳＵＰＵリソース」がある。これらのＵ−Ｐｌａｎｅリソースは、例えば、ＲＮＣ１００のＤＨＯ機能部１３１などのＵ−Ｐｌａｎｅリソースに関する機能ブロックに対応するものである。

さらに、Ｕ−Ｐｌａｎｅリソース共有リスト１７１に含まれる要素として、「収容ＢＴＳ数」、「収容セル数」、「在圏ユーザ数」がある。これらの要素は、例えば、各ＲＮＣ１００−１〜１００−３が収容する配下のＢＴＳ３００に関する要素などである。以下、各要素について説明する。

「ＲＮＣ番号」は、例えば、ＲＮＣ１００−１の物理番号であり、他のＲＮＣ１００−２，１００−３と識別可能な識別番号となっている。

「ＤＨＯリソース」は、例えば、ＲＮＣ１００−１のＤＨＯ機能部１３１に対応し、リソース情報として、「ＤＨＯリソース」に関する「リソース総数」、「提供可能リソース数」、「自ＲＮＣ予約リソース数」、「他ＲＮＣ予約リソース数」、「障害中リソース数」が含まれる。「ＤＣＣＨリソース」から「ＨＳＵＰＵリソース」までの各リソースについても、これらのリソース情報が含まれる。

「リソース総数」は、例えば、Ｕ−Ｐｌａｎｅの各リソースについて、物理的なものから計算されるリソースの総数であり、ＲＮＣ１００に挿入されるカードの数に応じた数値となっている。例えば、「ＤＨＯリソース」の「リソース総数」は、ＲＮＣ１００−１内のＤＨＯ機能部１３１が使用できるリソースの総数となる。

「提供可能リソース数」は、例えば、他のＲＮＣ１００−２，１００−３に提供可能なリソース数である。例えば、「ＤＨＯリソース」の「提供可能リソース数」は、ＲＮＣ１００−１内のＤＨＯ機能部１３１が他のＲＮＣ１００−２，１００−３に提供可能なリソース数を表わしている。

「自ＲＮＣ予約リソース数」は、例えば、自ＲＮＣ１００−１において使用することを予約したリソース数である。例えば、「ＤＨＯリソース」の「自ＲＮＣ予約リソース数」は、自ＲＮＣ１００−１のＤＨＯ機能部１３１において、自ＲＮＣ１００−１において使用することを予約したリソース数を表わしている。

「他ＲＮＣ予約リソース数」は、例えば、他のＲＮＣ１００−２，１００−３に提供することを予約したリソース数である。例えば、「ＤＨＯリソース」の「他ＲＮＣ予約リソース数」は、他のＲＮＣ１００−２，１００−３に提供することを予約したＤＨＯ機能部１３１のリソース数を表わしている。例えば、ＲＮＣ１００−１が２つのＲＮＣ１００−２，１００−３にリソースを提供することを予約したとき、ＲＮＣ１００−２に対する「他ＲＮＣ予約リソース数」と、ＲＮＣ１００−３に対する「他ＲＮＣ予約リソース数」とがこの要素に含まれる。このような場合、どのＲＮＣ１００−２，１００−３に対する「他ＲＮＣ予約リソース数」であるのかを識別するため、「他ＲＮＣ予約リソース数」には予約したＲＮＣの「ＲＮＣ番号」が含まれてもよい。

「障害中リソース数」は、例えば、Ｕ−Ｐｌａｎｅのリソースについて障害が発生しており使用できなくなったリソースの数である。例えば、「ＤＨＯリソース」の「障害中リソース数」は、ＲＮＣ１００−１のＤＨＯ機能部１３１に障害が発生したことで、ＤＨＯ機能部１３１において使用することができなくなったリソース数を表わしている。

なお、「リソース総数」、「提供可能リソース数」、「自ＲＮＣ予約リソース数」、「他ＲＮＣ予約リソース数」、「障害中リソース数」などのリソース情報は、例えば、ＭＳ５００とＲＮＣ１００との間で呼が発生したときに、ＲＮＣ１００内で捕捉されたり、演算されるものとする。例えば、これらのリソース情報は、ＣＯＮＴ部１５０のアプリケーション部１５２またはミドルウェア部１５３により捕捉または演算される。

次に「リソース共有リスト」の詳細について説明する。図９（Ｂ）は「リソース共有リスト」の例を表わしている。

「リソース共有リスト」には、例えば、リソース毎に、「提供可能リソース数」、「他ＲＮＣ予約リソース数」、「自ＲＮＣ予約リソース数」が含まれる。「提供可能リソース数」、「他ＲＮＣ予約リソース数」、「自ＲＮＣ予約リソース数」は、例えば、Ｕ−Ｐｌａｎｅリソース共有リストにそれぞれ含まれる要素である。

ただし、「リソース総数」については、例えば、「提供可能リソース数」、「他ＲＮＣ予約リソース数」、及び「自ＲＮＣ予約リソース数」を加算したリソース数であるため、「リソース総数」は「リソース共有リスト」に含まれず、送信されなくてもよい。

このような「リソース共有リスト」は、ＣＯＮＴ部１５０のアプリケーション部１５２またはミドルウェア部１５３によって、メモリ１７０に記憶されたＵ−Ｐｌａｎｅリソース共有リスト１７１から該当する要素が読み出さて、送付される。

かかる「リソース共有リスト」は、例えば、各ＲＮＣ１００−１〜１００−３のＵ−Ｐｌａｎｅリソースのリソース数に変化が生じたときに送信される。具体的には、ＲＮＣ１００−１の再開時、カードの障害が発生したり、障害から復旧したりする場合、他ＲＮＣ１００−２，１００−３から受信したリソースがこれまでと変化したとき、などの場合である。図８の例におけるＳ１０の処理は、送信契機として、ＲＮＣ１００−１の再開時に該当する。

次に、このようなリソース数変化を検出したときの「リソース共有リスト」の送付動作について説明する。この送付動作は、例えば、図８のＳ１０の詳細を表わすものでもある。

図１０は「リソース共有リスト」の送付動作の例を表わすフローチャートである。例えば、ＲＮＣ１００−１において行われるものとして説明する。

ＲＮＣ１００−１は、リソース数の変化を検出すると処理を開始する（Ｓ１００）。例えば、ＣＯＮＴ部１５０のアプリケーション部１５２またはミドルウェア部１５３は、ＲＮＣ１００−１の再開を検出したり、Ｕ−Ｐｌａｎｅ用ＦＢ部１３０に対応するカードの障害や復旧などを検出したときに処理を開始する。

次いで、ＲＮＣ１００−１は必要リソース数を算出する（Ｓ１０１）。必要リソース数は、例えば、ＲＮＣ１００−１において、ユーザデータの送信や受信などの動作に必要な全体のリソース数である。必要リソース数の算出動作の詳細については後述する。

次いで、ＲＮＣ１００−１は、隣接ＲＮＣ１００−２，１００−３へ「リソース共有リスト」を送付する（Ｓ１０２）。例えば、図８のＳ１０に対応する処理である。

次いで、ＲＮＣ１００−１は、「リソース共有リスト」をＩｕｒ範囲内にある全ＲＮＣ１００−２，１００−３に送付したか否かを確認し（Ｓ１０３）、送付していなければＩｕｒ範囲内にある全てのＲＮＣ１００−２，１００−３に送付する（Ｓ１０３でＮｏのループ）。ＲＮＣ１００−１は、「リソース共有リスト」をＩｕｒ範囲内の全ＲＮＣ１００−２，１００−３に送付すると（Ｓ１０３でＹｅｓ）、本処理を終了する（Ｓ１０４）。

以上の処理により、ＲＮＣ１００−１は、Ｉｕｒ範囲内の全ＲＮＣ１００−２，１００−３に対して、「リソース共有リスト」を送信することになる。

図８に戻り、ＲＮＣ１００−１が「リソース共有リスト」をＩｕｒ範囲内にあるＲＮＣ１００−２，１００−３に送付すると（Ｓ１１，Ｓ１２）、各ＲＮＣ１００−２，１００−３は「リソース共有リスト」の受信動作を行う（Ｓ２０〜Ｓ２３）。

次にＲＮＣ１００−２，１００−３が「リソース共有リスト」を受信したときの受信動作の詳細について説明する。

図１１は「リソース共有リスト」の受信動作の例を表わすフローチャートである。例えば、ＲＮＣ１００−２における受信動作を例にして説明する。

ＲＮＣ１００−２は、「リソース共有リスト」を受信すると処理を開始する（Ｓ２００）。

次いで、ＲＮＣ１００−２は、自装置で保持するＵ−Ｐｌａｎｅリソース共有リスト１７１と、ＲＮＣ１００−１から受信した「リソース共有リスト」とで差分があるか否かを判別する（Ｓ２０１）。

例えば、ＣＯＮＴ部１５０は、受信した「リソース共有リスト」に含まれるＲＮＣ１００−１の「ＤＨＯリソース」の「自ＲＮＣ予約リソース数」と、メモリ１７０に記憶したＲＮＣ１００−１の「ＤＨＯリソース」の「自ＲＮＣ予約リソース数」とで差分を判別する。

ＲＮＣ１００−２は、差分があれば（Ｓ２０１でＹｅｓ）、メモリ１７０に記憶したＵ−Ｐｌａｎｅリソース共有リスト１７１を更新する（Ｓ２０２）。

例えば、ＣＯＮＴ部１５０は、「自ＲＮＣ予約リソース数」について差分があれば、受信した「リソース共有リスト」に含まれる「自ＲＮＣ予約リソース」をＵ−Ｐｌａｎｅリソース共有リスト１７１に記憶することで、Ｕ−Ｐｌａｎｅリソース共有リスト１７１を更新する。

次いで、ＲＮＣ１００−２は、Ｉｕｒ範囲内の全ＲＮＣ１００−１，１００−３へ、更新した「リソース共有リスト」を送付する（Ｓ２０３）。更新した「リソース共有リスト」を送付するのは、ＲＮＣ１００−２において記憶したＵ−Ｐｌａｎｅリソース共有リスト１７１に変更が生じたためである。変更後（又は更新後）のＵ−Ｐｌａｎｅリソース共有リスト１７１の要素を含む「リソース共有リスト」がＲＮＣ１００−１，１００−３に送信されることで、変更後のＵ−Ｐｌａｎｅリソースの情報が、全ＲＮＣ１００−１〜１００−３間で共有されることになる。

例えば、ＣＯＮＴ部１５０は、ＲＮＣ１００−１についてのＵ−Ｐｌａｎｅリソース共有リスト１７１を更新すると、更新したリソース情報を含む「リソース共有リスト」を生成し、ＲＮＣ１００−１，１００−３へ送付する。

次いで、ＲＮＣ１００−２は、Ｉｕｒ範囲内にある全ＲＮＣ１００−１，１００−３に送付したか否かを確認し（Ｓ２０４）、送付していなければ送付し（Ｓ２０４でＮｏ，Ｓ２０３）、送付したときは本処理を終了する（Ｓ２０４でＹｅｓ，Ｓ２０５）。

この処理によって、図８に示すように、ＲＮＣ１００−２は、ＲＮＣ１００−１へ「リソース共有リスト」を送付することができる（Ｓ２１）。また、ＲＮＣ１００−３も、ＲＮＣ１００−１へ「リソース共有リスト」を送付する（Ｓ２３）。ただし、ＲＮＣ１００−２とＲＮＣ１００−３との間でも、「リソース共有リスト」が交換されることになるが、図８では説明を容易にするため省略されている。

次いで、ＲＮＣ１００−１は、ＲＮＣ１００−２，１００−３から送信された「リソース共有リスト」を受信する（Ｓ２４）。この受信によって、ＲＮＣ１００−１は「リソース共有リスト」の送信（Ｓ１１，Ｓ１２）に対する応答を受信することになる。

各ＲＮＣ１００−１〜１００−３は以上の動作を行うことで、Ｉｕｒ範囲内にある全ＲＮＣ１００−１〜１００−３におけるＵ−Ｐｌａｎｅリソースを共有することができる。この例では、ＲＮＣ１００−１が「リソース共有リスト」の送付契機を検出したときに送付しているが、ＲＮＣ１００−２，１００−３においても同様に実施できる。

その後、ＲＮＣ１００−１は、自ＲＮＣ１００−１におけるＵ−Ｐｌａｎｅリソースが不足していることを検出した場合、ＲＮＣ１００−２、１００−３のうち、どのＲＮＣ１００−２，１００−３のＵ−Ｐｌａｎｅリソースを用いるかを優先度決定要素に基づいて決定する（Ｓ２５）。

本処理（Ｓ２５）では、ＲＮＣ１００−１は、Ｕ−Ｐｌａｎｅのリソース不足を検出した場合、Ｕ−Ｐｌａｎｅリソース共有リスト１７１を用いて、どのＲＮＣ１００−２，１００−３に不足したＵ−Ｐｌａｎｅリソースを補う分のリソースがあるのかを選択するようにしている。

リソース不足の検出動作の詳細は後述するが、例えば、ＲＮＣ１００−１は、ユーザデータの送信や受信などの動作を行う上で必要なリソース数が、ＲＮＣ１００−１において物理的に使用可能なリソース数よりも多いことを検出できた場合に、リソース不足を検出できる。或いは、ＲＮＣ１００−１は、「自ＲＮＣ１００−１で確保したいＵ−Ｐｌａｎｅのリソース数」＜「自ＲＮＣ１００−１で確保できるＵ−Ｐｌａｎｅのリソース数」を検出できた場合、Ｕ−Ｐｌａｎｅリソースの不足を検出できる。

どのＲＮＣ１００−２，１００−３にリソースがあるのかを選択する選択動作は、例えば、Ｕ−Ｐｌａｎｅリソース共有リスト１７１と優先度決定要素リスト１７２とに基づいて行われる。以下、この選択動作の詳細について説明する。

図１２は選択動作の例を表わすフローチャートである。この動作は、例えば、ＲＮＣ１００−１のＣＯＮＴ部１５０において、メモリ１７０に記憶された優先度決定要素リスト１７２とＵ−Ｐｌａｎｅリソース共有リスト１７１とに基づいて行われる。

ＲＮＣ１００−１は、自ＲＮＣ１００−１のＵ−Ｐｌａｎｅリソースの不足を検出すると処理を開始する（Ｓ２５０）。リソース不足の検出動作の詳細は後述する。

次いで、ＲＮＣ１００−１は、自ＲＮＣ１００−１に保持するＵ−Ｐｌａｎｅリソース共有リスト１７１と優先度決定要素とにより、Ｕ−Ｐｌａｎｅのリソースを確保したい対象ＲＮＣ１００−２，１００−３を選択する（Ｓ２５１）。

図１３（Ａ）は優先度決定要素リスト１７２の例を表わす図である。優先度決定要素リスト１７２は、例えば、Ｕ−Ｐｌａｎｅリソース共有リスト１７１に記憶されたリソースのうち、どのリソースを優先するか表わすリストである。図１３（Ａ）の例では、最も優先するのは「提供可能リソース数」であり、不足するＵ−Ｐｌａｎｅリソースが「ＤＨＯリソース」の場合、「ＤＨＯリソース」の「提供可能リソース数」が最も多いＲＮＣが選択される。

この場合において、例えば、「提供可能リソース数」が最も多いＲＮＣが存在するものの、リソース不足が解消できないときなどは、２番目の優先度決定要素である「収容ＢＴＳ数」が最も少ないＲＮＣを優先して選択する、などとすることができる。順次、３番目の優先度決定要素である「収容セル数」や４番目の優先度決定要素である「在圏ユーザ数」に基づいてＲＮＣを選択する。

図１２に戻り、次いで、ＲＮＣ１００−１は選択した対象ＲＮＣ１００−２，１００−３に順番に「リソース予約リスト」を送付する（Ｓ２５２）。例えば、ＲＮＣ１００−１は、対象ＲＮＣとして、ＲＮＣ１００−２を選択した場合、ＲＮＣ１００−２に「リソース予約リスト」を送付し、ＲＮＣ１００−２，１００−３を選択した場合、ＲＮＣ１００−２とＲＮＣ１００−３に順番に送付することになる。

図１３（Ｂ）は「リソース予約リスト」の例を表わす図である。「リソース予約リスト」は、例えば、ＲＮＣ１００−１が他のＲＮＣ１００−２におけるＵ−Ｐｌａｎｅリソースの使用を予約するものである。図１３（Ｂ）に示すように、「リソース予約リスト」には、「ＲＮＣ番号」、不足しているＵ−Ｐｌａｎｅリソース、及び予約希望リソース数が含まれる。「ＤＨＯ」のリソースが不足している場合は、「リソース予約リスト」には、「ＤＨＯ」の要素に対する予約希望リソース数が含まれる。

「リソース予約リスト」に含まれる「予約希望リソース数」は、例えば、不足している不足分のリソース数とすることもできる。また、「予約希望リソース数」は、複数のＲＮＣ１００−２，１００−３に「リソース予約リスト」を送付する場合、複数のＲＮＣ１００−２，１００−３で等分したリソース数とすることもできる。

図１２に戻り、ＲＮＣ１００−１は、「リソース予約リスト」を送付すると、必要リソース数を確保できたか否かを判別する（Ｓ２５３）。

この判別は、例えば、以下のようにして行うことができる。すなわち、ＲＮＣ１００−１は、対象となるＲＮＣ１００−２に「リソース予約リスト」を送付する。ＲＮＣ１００−２では、予約希望リソース数に対して予約できたリソース数を確保し、Ｕ−Ｐｌａｎｅリソース共有リスト１７１を更新する。更新する対象は、例えば、「他ＲＮＣ予約リソース数」である。そして、ＲＮＣ１００−２は、予約できたリソース数を含む「リソース共有リスト」をＲＮＣ１００−１に送付する。従って、ＲＮＣ１００−１は、「リソース予約リスト」を送付後、ＲＮＣ１００−２から返信される「リソース共有リスト」に含まれる「他ＲＮＣ予約リソース数」が「予約希望リソース数」と一致したとき、必要リソース数を確保できたと判別する（Ｓ２５３でＹｅｓ）。一方、ＲＮＣ１００−１は、ＲＮＣ１００−２から返信される「リソース共有リスト」に含まれる「他ＲＮＣ予約リソース数」が「予約希望リソース数」よりも少ないとき、必要リソース数は確保できていないと判別する（Ｓ２５３でＮＯ）。必要リソース数が確保できない場合、再度Ｓ２５２の処理に移行して、必要リソースを確保できるまで、「リソース予約リスト」の送付を行う。

ＲＮＣ１００−１は、必要リソース数を確保したとき（Ｓ２５３でＹｅｓ）、一連の処理を終了させる（Ｓ２５４）。

以上により選択動作が行われ、例えば、ＲＮＣ１００−１は不足するＵ−Ｐｌａｎｅリソースについて、他のＲＮＣ１００−２のＵ−Ｐｌａｎｅリソースを予約することができる。

図８に戻り、上述した選択動作により、Ｓ２５〜Ｓ２９の処理が行われる。図８の例では、ＲＮＣ１００−１は、対象ＲＮＣとしてＲＮＣ１００−２を選択し、ＲＮＣ１００−２に対して「リソース予約リスト」を送付している（Ｓ２６）。

この場合、ＲＮＣ１００−１は、対象でないＲＮＣ１００−３に対しては「リソース予約リスト」を送付しないようにしている。これにより、各ＲＮＣ１００−１〜１００−３が「リソース共有リスト」を送付し合う競合動作を防止することができる。

ＲＮＣ１００−１は、「リソース共有リスト」を受け取り、自ＲＮＣ１００−１において必要なＵ−Ｐｌａｎｅリソースが確保できないと、他のＲＮＣ１００−３へ「リソース予約リスト」を送付する（Ｓ３０）。

以上により、Ｉｕｒ範囲内のＲＮＣ１００−１〜１００−３においてリソースの共有動作が行われ、共有後において、ＲＮＣ１００−１は不足しているリソースについて他のＲＮＣ１００−２，１００−３のリソースを利用できる状態にすることができる。その後、予約したリソースの払い出し動作が行われ、ユーザデータの送信や受信を行うことができるようになる。

共有化後の動作例として、このリソースの払い出し動作について説明するが、その前に、上述した必要リソース数の算出動作（図１０のＳ１０１）、及びリソース不足の検出動作（図１２のＳ２５０）について説明する。

ただし、リソース不足の検出動作は、必要リソース数の算出動作において検出することが可能であるため、リソース不足の検出動作は、必要リソース数の算出動作の中で説明する。

図１４は必要リソース数の算出動作の例を表わすフローチャートである。この動作は、例えば、ＲＮＣ１００−１のＣＯＮＴ部１５０において行われる。

ＲＮＣ１００−１は、必要リソース数の算出契機を検出すると処理を開始する（Ｓ１１１）。算出契機としては、例えば、ＲＮＣ１００−１の再開時、ＲＮＣ１００−１内のカードの障害発生時または復旧時、さらに、ＭＳ５００との間のトラヒックの変化を検出したときや、ＲＮＣ１００−１が収容するＢＴＳ３００の情報が変化したときなどがある。例えば、ＣＯＮＴ部１５０において、ＲＮＣ１００−１の再開などを検出することで処理を開始する。

次いで、ＲＮＣ１００−１は、「ＢＴＳ数」、「セル数」、「在圏者数」、「リソース使用率データ」の各情報に基づいて、自ＲＮＣ１００−１の必要リソース数を算出する（Ｓ１１２）。

例えば、「ＢＴＳ数」はＲＮＣ１００−１配下のＢＴＳ３００の数であり、「セル数」は配下のＢＴＳ３００が収容するセルの総数であり、「ＢＴＳ数」と「セル数」はＲＮＣ１００−１のメモリ１７０に保持される数値である。また、例えば、「在圏者数」はＭＳ５００との間で制御チャネル設定手順（例えばＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ）が行われた数に基づいて演算される数値である。また、「リソース使用率データ」は、例えば、１ユーザあたりのトラヒック量であり、制御チャネル設定手順によりＭＳ５００から要求されるリソース数に基づいて演算される数値である。

例えば、ＣＯＮＴ部１５０は、メモリ１７０から「ＢＴＳ数」と「セル数」とを読み出し、制御チャネル設定手順において「在圏者数」と「リソース使用率データ」とを算出する。そして、ＣＯＮＴ部１５０は、例えば、「ＢＴＳ数」、「セル数」、「在圏者数」、「リソース使用率データ」を乗算することで必要リソース数を算出する。

次いで、ＲＮＣ１００−１は、自ＲＮＣ１００−１の使用可能リソース数を算出する（Ｓ１１３）。使用可能リソース数は、例えば、自ＲＮＣ１００−１において収容されている物理的なカードの状態（例えば使用可、使用不可）に基づいて算出されるリソース数である。

前述したように、例えば、必要リソース数はユーザデータの送受信などにおいて必要なＵ−Ｐｌａｎｅのリソース数であり、使用可能なリソース数はＲＮＣ１００−１内の物理的な状態から利用可能なリソース数とすることもできる。

次いで、ＲＮＣ１００−１は、必要リソース数と使用可能リソース数とに差分があるか否かを判別する（Ｓ１１４）。例えば、ＣＯＮＴ部１５０は、Ｓ１１２で算出した必要リソース数と、Ｓ１１３で算出した使用可能リソース数とを比較して差分の有無を判別する。

そして、ＲＮＣ１００−１は、必要リソース数と使用可能リソース数とに差分があるときであって（Ｓ１１４でＹｅｓ）、必要リソース数が使用可能リソース数より多いとき、必要リソース数が足りないと判別する。つまり、ユーザデータの送信などの動作により必要なＵ−Ｐｌａｎｅリソースがあるものの、ＲＮＣ１００−１内において物理的な制約に基づくリソースでは足りない場合となり、リソース不足が検出されることとなる。

かかる場合は、ＲＮＣ１００−１はリソース予約動作（例えば、図８のＳ２５、又は図１２のＳ２５０）を行う。この場合、ＲＮＣ１００−１は、「リソース予約リスト」を送付して不足するリソースを確保することになる。

また、ＲＮＣ１００−１は、必要リソース数と使用可能リソース数とに差分があるとき（Ｓ１１４でＹｅｓ）であって、使用可能リソース数が必要リソース数より多いとき、この場合は、使用可能リソース数は確保されている状態となっている。

かかる場合、ＲＮＣ１００−１は「リソース共有リスト」の送付動作（例えば、図８のＳ１０、又は図１０のＳ１００）を行う。この場合、ＲＮＣ１００−１は、「リソース共有リスト」を送付し、Ｉｕｒ範囲内の全ＲＮＣ１００−２，１００−３との間でリソースを共有することになる。

次いで、ＲＮＣ１００−１は一連の処理を終了させる（Ｓ１１６）。

一方、ＲＮＣ１００−１は、必要リソース数と使用可能リソース数とに差分がないとき（Ｓ１１４でＮｏ）、必要リソース数と使用可能リソース数とは一致しており、とくに、他の動作へ移行することなく、一連の処理を終了させる（Ｓ１１６）。

この場合、例えば、「リソース共有リスト」の送付動作（例えば図８のＳ１０、又は図１０のＳ１００）へ移行するようにしてもよい。必要リソース数の算出契機（Ｓ１１１）は、例えば、ＲＮＣ１００−１の再開やカードの故障などにより行われ、このような契機は、リソース数の変化を検出する契機（例えば図１０のＳ１００）を含んでいるからである。

＜リソース共有後の動作例＞
次にリソース共有後の動作例について説明する。リソース共有後の動作としては、予約したＵ−Ｐｌａｎｅリソースについての払い出しを受ける動作がある。例えば、ＲＮＣ１００−１は、払い出されたＵ−Ｐｌａｎｅリソースを用いてユーザデータの送信や受信などの動作を行う。この払い出し動作について以下説明する。

図１５は払い出し動作の例を表わすシーケンス図である。この例では、ＭＳ５００とＲＮＣ１００−１との間では接続が確立され、認証及び秘匿手順なども行われたものとする。

ＲＮＣ１００−１は、ＣＮ６００に接続された上位ノード（例えばＳＧＳＮ）から、コネクションを確立するため、ＲＡＮＡＰ（Radio Access Network Access Protocol Part）プロトコルのＲＡＢ(Radio Access Bearer) ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴを受信する（Ｓ３５０）。

例えば、ＲＮＣ１００−１のアプリケーション部１５２−１は、Ｌ２ＳＷ１２０などを介して、かかるＲＥＱＵＥＳＴを受信する。このとき、アプリケーション部１５２−１は、例えば、当該ＲＥＱＵＥＳＴに含まれるＲＡＢ通信パラメータなどを抽出して、どのＵ−Ｐｌａｎｅリソースを用いるかを判別する。

ＲＮＣ１００−１のアプリケーション部１５２−１は、ＲＡＢ(Radio Access Bearer) ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＵＥＳＴを受信すると、Ｕ−Ｐｌａｎｅリソース捕捉指示を、ＲＮＣ１００−１のミドルウェア部１５３−１に通知する（Ｓ３５１）。このとき、アプリケーション部１５２−１は、例えば、判別したＵ−ＰｌａｎｅリソースをＵ−Ｐｌａｎｅリソース捕捉指示に含めて通知する。

次いで、ミドルウェア部１５３−１は、Ｕ−Ｐｌａｎｅリソース共有リスト１７１に基づいて払い出し先ＲＮＣ装置を決定する（Ｓ３５２）。

払い出し先ＲＮＣ装置の決定は、例えば、以下のようにして行う。すなわち、ミドルウェア部１５３−１は、メモリ１７０に記憶されたＵ−Ｐｌａｎｅリソース共有リスト１７１にアクセスし、他ＲＮＣ１００−２、１００−３のＵ−Ｐｌａｎｅリソース共有リスト１７１を検索する。ミドルウェア部１５３が他ＲＮＣ１００−２，１００−３のＵ−Ｐｌａｎｅリソース共有リスト１７１を検索するのは、例えば、自ＲＮＣ１００−１に対して予約したのはどのＲＮＣ１００−２、１００−３かを検索するためである。

そして、ミドルウェア部１５３−１は、他ＲＮＣ１００−２、１００−３のＵ−Ｐｌａｎｅリソース共有リスト１７１のうち、Ｕ−Ｐｌａｎｅリソース捕捉指示に含まれるリソースに対応するリソースについて、自ＲＮＣ１００−１に対して予約したリソースを検索する。例えば、ミドルウェア部１５３−１は、Ｕ−Ｐｌａｎｅリソース捕捉指示に「ＤＨＯリソース」が含まれる場合、自ＲＮＣ１００−１の「ＲＮＣ番号」を含む、「ＤＨＯリソース」に対する「他ＲＮＣ予約リソース数」を検索する。すなわち、ミドルウェア部１５３−１は、自ＲＮＣ１００−１について「ＤＨＯリソース」の予約がなされた「他ＲＮＣ予約リソース数」を保持するＵ−Ｐｌａｎｅリソース共有リスト１７１を検索する。

ミドルウェア部１５３−１は、そのような「他ＲＮＣ予約リソース数」があれば、その「他ＲＮＣ予約リソース数」を保持する他ＲＮＣ１００−２、１００−３を、払い出し先ＲＮＣ装置に決定する。図１５の例では、ミドルウェア部１５３−１は、ＲＮＣ１００−２を払い出し先ＲＮＣ装置として決定している。

なお、図１５の例では、「ＤＨＯリソース」と、さらに、「ＲＬＣリソース」についても、Ｕ−Ｐｌａｎｅリソース捕捉結果に含まれており、ミドルウェア部１５３−１は、「ＲＬＣリソース」に対する払い出し先ＲＮＣ装置（例えばＲＮＣ１００−２）も決定している。

次いで、ミドルウェア部１５３−１は、ＤＨＯリソース捕捉要求を、払い出し先ＲＮＣ装置であるＲＮＣ１００−２に送信する（Ｓ３５３，Ｓ３５４）。このとき、ミドルウェア部１５３−１は、各機能部１３１〜１３５へのメッセージを、ノード間メッセージに変換して送信する。例えば、ミドルウェア部１５３−１は、各機能部１３１〜１３５へ送信するメッセージに対して、自ＲＮＣ１００−１を送信元、ＲＮＣ１００−２を送信先とするヘッダを付加したメッセージを生成することで、ノード間メッセージに変換することができる。

ＲＮＣ１００−２のミドルウェア部１５３−２は、ＲＮＣ１００−２のＬ２ＳＷ１２０などを介して、ＤＨＯリソース捕捉要求を受信すると、当該要求を、ＲＮＣ１００−２のＤＨＯ機能部１３１−２に出力する（Ｓ３５５）。例えば、ミドルウェア部１５３−２は、ノード間メッセージとして受信したＤＨＯリソース捕捉要求から、ヘッダなどを終端させ、ペイロードに含まれるＤＨＯリソース捕捉要求を抽出して、ＤＨＯ機能部１３１−２に出力する。

次いで、ＤＨＯ機能部１３１−２は、ＤＨＯリソース捕捉要求に対するＤＨＯリソース捕捉結果をミドルウェア部１５３−２に出力する（Ｓ３５６）。これにより、例えば、ＲＮＣ１００−１に対して予約した「ＤＨＯリソース」の払い出しが行われる。

次いで、ミドルウェア部１５３−２は、ＤＨＯリソース捕捉結果を受け取ると、ＤＨＯリソース捕捉結果をＲＮＣ１００−１に送信する（Ｓ３５７）。この場合も、例えば、ミドルウェア部１５３−２は、ノード間メッセージとしてＤＨＯリソース捕捉結果を送信する。

ＲＮＣ１００−１のミドルウェア部１５３−１は、ＤＨＯリソース捕捉結果を受信すると、Ｕ−Ｐｌａｎｅリソース捕捉結果をアプリケーション部１５２−１に通知する（Ｓ３５９）。例えば、ミドルウェア部１５３−１は、ノード間メッセージのヘッダを終端し、ペイロードに含まれるＤＨＯリソース捕捉結果を、Ｕ−Ｐｌａｎｅリソース捕捉結果として通知する。

このとき、ミドルウェア部１５３−１は、メモリ１７０に記憶されたリソース管理テーブル１７３にアクセスして、「ＤＨＯ」リソースの使用中数をカウントアップする（Ｓ３５８）。

図１６はリソース管理テーブル１７３の例を表わす図である。リソース管理テーブル１７３には、リソース毎に、各ＲＮＣで使用されるリソース数（「自ＲＮＣ使用中数」、「ＲＮＣ＃Ａ使用中数」、「ＲＮＣ＃Ｂ使用中数」）と、各ＲＮＣにおいて使用可能なリソース数（「自ＲＮＣ使用可能数」、「他ＲＮＣ＃Ａ使用可能数」、「他ＲＮＣ＃Ｂ使用可能数」）が含まれる。例えば、各ＲＮＣの「使用可能数」は、「Ｕ−Ｐｌａｎｅリソース共有テーブル」の「リソース総数」、或いは、「リソース総数」から「障害中リソース数」を減算した数に対応する。

図１６の例では、ＲＮＣ１００−２の「ＤＨＯリソース」に対するリソース捕捉結果が通知されたため、「ＤＨＯ」の「ＲＮＣ＃Ａ使用中数」が「３」から「４」にカウントアップされ、「４」が当該項目に記憶される。図１６の例では、「ＲＮＣ＃Ａ」がＲＮＣ１００−２、「ＲＮＣ＃Ｂ」がＲＮＣ１００−３にそれぞれ対応する。

図１５に戻り、次いで、ＲＮＣ１００−１のアプリケーション部１５２−１は、「ＲＬＣリソース」に対しても、リソースの払い出し動作を行う（Ｓ３６０〜Ｓ３６６）。

この場合の動作も、対象とするリソースが「ＤＨＯリソース」が「ＲＬＣリソース」となっただけで、動作自体は「ＤＨＯリソース」に対する払い出し動作（Ｓ３５１〜Ｓ３５９）と同様である。ミドルウェア部１５３−１は、ＲＬＣリソース捕捉結果をＲＮＣ１００−２のミドルウェア部１５３−２から受け取ると、リソース管理テーブル１７３の「ＲＬＣリソース」の使用中数をカウントアップする（例えば図１６）。

そして、アプリケーション部１５２−１は、ＣＮ６００に接続された上位ノードに対して、ＲＡＮＡＰプロコトルのＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＳＰＯＮＳＥを送信する（Ｓ３６７）。

これにより、例えば、ＲＮＣ１００−１は上位ノードに対してＲＡＢ確立ができたことを通知し、上位ノードとＲＮＣ１００−１との間でＲＡＢ確立がなされる。その後、ＲＮＣ１００−１は上位ノードとの間でユーザデータなどを送信したり、受信することができる。

なお、ＲＮＣ１００−１は払い出したリソースを解放させる場合、リソース解放要求をＲＮＣ１００−２に送信する。例えば、ＲＮＣ１００−１のアプリケーション部１５２−１は、ＲＡＮＡＰプロトコルによる解放メッセージを受信すると、ミドルウェア部１５３−１に対して、Ｕ−Ｐｌａｎｅリソース解放指示を通知する。その後、ミドルウェア部１５３−１は、ＤＨＰリソース解放要求を、ＤＨＯリソース捕捉要求と同様にＲＮＣ１００−２に送信することで、払い出し動作を同様の動作を行うことができる。この場合、例えば、リソース解放要求によって、予約されたリソース数が変化するため、ＲＮＣ１００−２は、Ｕ−Ｐｌａｎｅリソース共有リスト１７１のＲＮＣ１００−１に対する「他ＲＮＣ予約リソース数」を更新する。そして、ＲＮＣ１００−２は、更新後の「リソース共有リスト」をＩｕｒ範囲内の全ＲＮＣ１００−１，１００−３に送信する。

＜その他の実施例＞
図６に示すＲＮＣ１００の構成例について、Ｃ−Ｐｌａｎｅ用ＦＢ部１１０のＳＣＴＰ機能部１１４と、Ｕ−Ｐｌａｎｅ用ＦＢ部１３０のＤＨＯ機能部１３１〜ＤＣＣＨ機能部１３５は、例えばＤＳＰ（Digital Signal Processor）１４０，１４１によりそれぞれ実施することができる。また、ＣＯＮＴ部１５０は、例えば、ＣＰＵ（Central Processing Unit）１５５により実施することもできる。このように、ＲＮＣ１００は、例えば、各ＩＦ１１１〜１１３、ＤＳＰ１４０，１４１、Ｌ２ＳＷ１２０、ＣＰＵ１５５、及びメモリ１７０を備え、これらの構成によって、第１及び第２の実施の形態で説明した動作を実行することもできる。

例えば、ＣＰＵ１５５がメモリ１７０に記憶されたＵ−Ｐｌａｎｅリソース共有リスト１７１にアクセスして、各リソース情報などを更新したり、「リソース共有リスト」をＬ２ＳＷ１２０を介して他のＲＮＣ１００−２，１００−３に送信することができる。また、リソースの払い出し動作（例えば図１５）においてアプリケーション部１５２−１とミドルウェア部１５３−１で行われる動作は、例えば、ＲＮＣ１００−１のＣＰＵ１５５によって実行することができる。この場合、ＲＮＣ１００−２側のアプリケーション部１５２−２とミドルウェア部１５３−２で行われる動作は、例えば、ＲＮＣ１００−２側のＣＰＵ１５５により実行できる。

以上まとめると付記のようになる。

（付記１）
配下の無線基地局装置を制御する無線ネットワーク制御装置において、
ユーザプレーンのデータを処理する機能を有する第１の機能部と、
前記無線ネットワーク制御装置は他の無線ネットワーク制御装置のアドレス情報を保持し、前記無線ネットワーク制御装置のアドレス情報を保持する前記他の無線ネットワーク制御装置に対し、前記第１の機能部における第１のリソースと前記他の無線ネットワーク制御装置においてユーザプレーンのデータを処理する機能を有する第２の機能部における第２のリソースとを共有する制御部
を備えることを特徴とする無線ネットワーク制御装置。

（付記２）
更に、前記第１及び第２のリソースに関するリソース共有情報を記憶する記憶部を備え、
前記制御部は、前記第１のリソースに変化があったとき、前記リソース共有情報を更新し、更新後の前記リソース共有情報を前記他の無線ネットワーク制御装置に送信することを特徴とする付記１記載の無線ネットワーク制御装置。

（付記３）
前記制御部は、前記他の無線ネットワーク制御装置から送信された前記リソース共有情報を受信し、受信した前記リソース共有情報と前記記憶部に記憶した前記リソース共有情報とで差分があるとき、前記記憶部に記憶した前記リソース共有情報を受信した前記リソース共有情報に更新することを特徴とする付記２記載の無線ネットワーク制御装置。

（付記４）
前記制御部は、前記第１のリソースが不足していることを検出したとき、前記リソース共有情報に基づいて、前記第２のリソースを利用することを特徴とする付記２記載の無線ネットワーク制御装置。

（付記５）
前記制御部は、前記第１の機能部においてユーザプレーンのデータを処理するために必要な必要リソース数が、前記第１の機能部を有するカード又は基板の状態に基づいて算出される使用可能リソース数よりも多いとき、前記第１のリソース数は不足していることを検出することを特徴とする付記４記載の無線ネットワーク制御装置。

（付記６）
前記制御部は、前記記憶部に記憶された前記リソース共有情報と、前記リソース共有情報にあるリソースのうちどのリソースを優先して選択するかを表わす優先度決定要素とに基づいて、前記第１のリソースのうち不足しているリソースを確保する対象となる前記他の無線ネットワーク制御装置を選択することを特徴とする付記４記載の無線ネットワーク制御装置。

（付記７）
前記制御部は、選択した前記他の無線ネットワーク制御装置に対して、前記第２のリソースの使用を予約するリソース予約リストを送信することを特徴とする付記６記載の無線ネットワーク制御装置。

（付記８）
前記リソース予約リストには、不足している前記第１のリソースのリソース数が含まれることを特徴とする付記７記載の無線ネットワーク制御装置。

（付記９）
前記制御部は、前記無線ネットワーク制御装置に接続されたノード装置から接続を確立するためのメッセージを受信したとき、前記リソース予約リストにより更新された前記リソース共有情報に基づいて、前記他の無線ネットワーク制御装置に対して、リソース捕捉要求を送信することを特徴とする付記７記載の無線ネットワーク制御装置。

（付記１０）
前記リソースは、前記第１の機能部を有するカード又は基板により払い出すことのできる帯域の数、またはコネクションの数であることを特徴とする付記１記載の無線ネットワーク制御装置。

（付記１１）
配下の無線基地局装置を制御する無線ネットワーク制御装置におけるリソース共有方法であって、
前記無線ネットワーク制御装置は他の無線ネットワーク制御装置のアドレス情報を保持し、前記無線ネットワーク制御装置のアドレス情報を保持する前記他の無線ネットワーク制御装置に対し、ユーザプレーンのデータを処理する機能を有する第１の機能部における第１のリソースと前記他の無線ネットワーク制御装置においてユーザプレーンのデータを処理する機能を有する第２の機能部における第２のリソースとを共有する、
ことを特徴とするリソース共有方法。

（付記１２）
無線基地局装置と、
配下の前記無線基地局装置を制御する第１の無線ネットワーク制御装置と、
第２の無線ネットワーク制御装置とを備え、前記第１の無線ネットワーク制御装置は前記第２の無線ネットワーク制御装置のアドレス情報を保持し、前記第２の無線ネットワーク制御装置は前記第１の無線ネットワーク制御装置のアドレス情報を保持する無線通信ネットワークシステムにおいて、
前記第２の無線ネットワーク制御装置は、ユーザプレーンのデータを処理する第２の機能部を備え、
前記第１の無線ネットワーク制御装置は、
ユーザプレーンのデータを処理する機能を有する第１の機能部と、
前記第２の無線ネットワーク制御装置に対し、前記第１の機能部における第１のリソースと前記第２の機能部における第２のリソースとを共有する制御部とを備えることを特徴とする無線通信ネットワークシステム。

１０：無線通信ネットワーククシステム
１００（１００−１〜１００−１７）：無線ネットワーク制御装置（ＲＮＣ）
１１０：Ｃ−Ｐｌａｎｅ用ＦＢ部 １１１，１１２：ＩＰ−ＩＦ
１１３：ＡＴＭ−ＩＦ １１４：ＳＣＴＰ機能部
１２０：Ｌ２ＳＷ １３０：Ｕ−Ｐｌａｎｅ用ＦＢ部
１３１（１３１−２）：ＤＨＯ機能部 １３２：ＲＬＣ機能部
１３３：ＨＳＤＰＡ機能部 １３４：ＨＳＵＰＵ機能部
１３５：ＤＣＣＨ機能部 １４０，１４１：ＤＳＰ
１５０：ＣＯＮＴ部 １５１：トラヒック監視部
１５２（１５２−１，１５２−２）：アプリケーション部
１５３（１５３−１，１５３−２）：ミドルウェア部
１５５：ＣＰＵ １７０：メモリ
１７１：Ｕ−Ｐｌａｎｅリソース共有リスト
１７２：優先度決定要素リスト １７３：リソース管理テーブル
１８０：制御部 １８５−１：第１の機能部
１８５−２：第２の機能部
３００（３００−１１〜３００−３１）：ＢＴＳ
５００：ＭＳ ６００：ＣＮ

Claims (5)

1. 配下の無線基地局装置を制御する無線ネットワーク制御装置において、
   ユーザプレーンのデータを処理する機能を有する第１の機能部と、
   前記無線ネットワーク制御装置は他の無線ネットワーク制御装置のアドレス情報を保持し、前記無線ネットワーク制御装置のアドレス情報を保持する前記他の無線ネットワーク制御装置に対し、前記第１の機能部における第１のリソースと前記他の無線ネットワーク制御装置においてユーザプレーンのデータを処理する機能を有する第２の機能部における第２のリソースとを共有する制御部
   を備えることを特徴とする無線ネットワーク制御装置。
2. 更に、前記第１及び第２のリソースに関するリソース共有情報を記憶する記憶部を備え、
   前記制御部は、前記第１のリソースに変化があったとき、前記リソース共有情報を更新し、更新後の前記リソース共有情報を前記他の無線ネットワーク制御装置に送信することを特徴とする請求項１記載の無線ネットワーク制御装置。
3. 前記制御部は、前記第１のリソースが不足していることを検出したとき、前記リソース共有情報に基づいて、前記第２のリソースを利用することを特徴とする請求項２記載の無線ネットワーク制御装置。
4. 配下の無線基地局装置を制御する無線ネットワーク制御装置におけるリソース共有方法であって、
   前記無線ネットワーク制御装置は他の無線ネットワーク制御装置のアドレス情報を保持し、前記無線ネットワーク制御装置のアドレス情報を保持する前記他の無線ネットワーク制御装置に対し、ユーザプレーンのデータを処理する機能を有する第１の機能部における第１のリソースと前記他の無線ネットワーク制御装置においてユーザプレーンのデータを処理する機能を有する第２の機能部における第２のリソースとを共有する、
   ことを特徴とするリソース共有方法。
5. 無線基地局装置と、
   配下の前記無線基地局装置を制御する第１の無線ネットワーク制御装置と、
   第２の無線ネットワーク制御装置とを備え、前記第１の無線ネットワーク制御装置は前記第２の無線ネットワーク制御装置のアドレス情報を保持し、前記第２の無線ネットワーク制御装置は前記第１の無線ネットワーク制御装置のアドレス情報を保持する無線通信ネットワークシステムにおいて、
   前記第２の無線ネットワーク制御装置は、ユーザプレーンのデータを処理する第２の機能部を備え、
   前記第１の無線ネットワーク制御装置は、
   ユーザプレーンのデータを処理する機能を有する第１の機能部と、
   前記第２の無線ネットワーク制御装置に対し、前記第１の機能部における第１のリソースと前記第２の機能部における第２のリソースとを共有する制御部とを備えることを特徴とする無線通信ネットワークシステム。