JP5061827B2 - 無線ネットワーク制御装置、リソース管理方法及びプログラム - Google Patents

Description

本発明は、MBMS（Multimedia Broadcast Multicast Service）を提供する移動通信システムにおける無線リソースを管理する無線ネットワーク制御装置、リソース管理方法及びプログラムに関する。

一般的な移動通信システムにおいては、無線基地局と移動体である移動端末との間にて通信を行うには、そのための無線リソースを確保する必要がある。通信を行うために必要な無線リソースを確保する際に、当該無線基地局が有する全体の無線リソースに余裕がある場合は、その中の空いているリソースの中から当該通信を行うために必要な無線リソースを確保する。しかし、無線基地局が有する全体の無線リソースに余裕がない場合は、当該通信を行うために必要な無線リソースを確保することができない。そこで、空きのリソースを作るために、現在使用している無線リソースのうち優先順位の低いチャネルを解放する。これにより作られた空きのリソースの中から当該通信を行うために必要な無線リソースを確保する。

ここで、優先順位を決定するための情報として、CN（Core Network）から無線ネットワーク制御装置であるRNC（Radio Network Controller）へのサービスの実施要求時に通知される各チャネルのPriority Level、RNCが無線基地局であるNodeBへ設定する下り方向の物理チャネルの拡散率、上り方向のMin UL Channelisation Code Lengthの情報を使用するものが一般的である。

上記のようにリソース不足や輻輳の発生により、既存のチャネルの解放を行った場合、個別チャネルを使用した環境である限り、あるチャネルを解放することによってデータ通信が途絶えるという影響を受けるのは、解放されたチャネルを使用している１つの移動端末のみである。

一方、近年PtM（Point to Multipoint）方式を用いたMBMS（Multimedia Broadcast Multicast Service）が導入されてきている。このMBMSは3GPP Release6にて提案されているサービスであり、１つのネットワークリソース（無線リソースを含む）を、複数の移動端末で共有して、RNCから複数の移動端末へ同時にマルチメディアデータを送信する技術である。このMBMSをPtM方式で使用することにより、ネットワークのリソースを効率よく使用することが可能となる。その結果として、携帯電話サービスを提供しているキャリアは、少ない設備投資で収益を増やすことが可能となる。また、MBMSは共通チャネルであるS-CCPCHのチャネルを用いて実現される。

図１１は、一般的な移動通信システムの一例を示す図である。

図１１に示した移動通信システムは、CN１１００と、RNC１１０１と、NodeB１２０１とから構成されている。また、NodeB１２０１がサービスを提供するカバーエリアであるセル１２０２内に、UE群１３０１と、UE１３０２，１３０３と、Idle UE群１３０４とが存在している。

CN１１００は、光ケーブル等の有線回線でRNC１１０１と接続されたRNC１１０１の上位ネットワークである。RNC１１０１は、一般的な無線ネットワーク制御装置（Radio Network Controller）である。NodeB１２０１は、一般的な無線基地局であり、UE群１３０１、UE１３０２，１３０３との間にて無線通信を行っている。ここで、UE群１３０１はNodeB１２０１からのMBMSを受信するためにS-CCPCH（Secondary Common Control Physical Channel）を受信している移動端末群である。UE１３０２，１３０３は個別のサービス（音声やパケット通信）を受信する為にDPCH（Dedicated Physical Channel）を受信している移動端末である。UE群１３０１、UE１３０２，１３０３は通信を行っている状態であり、connected modeである。これに対して、Idle UE群１３０４は通信を行っていないIdle modeの移動端末群である。

以下に、MBMS Countingの手順について説明する。MBMS Countingは、MBMSを開始する際に、開始しようとしているサービスの受信をどの程度のユーザが希望しているのか調査する手順である。すなわち、マルチメディアデータの視聴率を調査するものである。これは、例えば、特許文献１に記載された、RNCが当該RNC配下の移動端末に係る情報を得る技術における当該情報の１つとなる。

図１２は、MBMS Countingの手順を示す図である。

図１２に示すように、図１１に示したRNC１１０１とNodeB１２０１とを含めた無線アクセスネットワークであるUTRAN１４００と、移動端末であるUE１４０１との間にて信号の送受信が行われる。

まずは、UTRAN１４００からUE１４０１へMBMS ACCESS INFORMATIONが送信される。このMBMS ACCESS INFORMATIONは、MBMSを開始する旨をUTRAN１４００がUE１４０１へ知らせる信号である。

その後、MBMS ACCESS INFORMATIONを受信したUE１４０１がIdle mode UEであり、かつ、MBMS ACCESS INFORMATIONにて通知されたサービスをUE１４０１が受信希望し、かつ、MBMS Countingの応答条件に合致する場合、UE１４０１から接続要求信号であるRRC connection requestがUTRAN１４００へ送信される。また、MBMS ACCESS INFORMATIONを受信したUE１４０１がconnected mode UEであり、かつ、MBMS ACCESS INFORMATIONにて通知されたサービスをUE１４０１が受信希望し、かつ、MBMS Countingの応答条件に合致する場合、UE１４０１からセル更新信号であるCell updateがUTRAN１４００へ送信される。

UTRAN１４００は、UE１４０１から送信された上記の応答信号によって、そのMBMSの視聴率を測定することが可能である。

なお、上述したMBMS ACCESS INFORMATIONへのUEの応答条件は、3GPP Release6 TS25.331にて定義されている内容であるので、ここでの詳細な説明は割愛する。
特開２００５−６５２６０号公報

しかしながら、MBMSで使用しているS-CCPCHに対して、一般的に使用されるPriority Level、拡散率、Min UL Channelisation Code Length等の情報に基づいてリソース制御を行うと、当該S-CCPCHを解放した際にMBMSを受けている多くのユーザに影響を与えてしまう虞がある。例えば、拡散率が大きく（つまり、無線リソースの使用量が少ない）、Priority Levelが低いS-CCPCHにおいてMBMSが提供されている場合、無線リソース不足により当該リソースがリソース制御の結果解放されてしまうと、そのMBMSを受信していた移動端末全てが、MBMSを受信することができなってしまうという問題点がある。それは、MBMSをPtP（Point to Point）方式ではなくPtM方式で提供するため、多くの移動端末がカバーエリアであるセル内でそのMBMS受信を希望しているという結果があり、その結果UTRANがPtM方式のリソース設定を行うからである。

また、PtM方式で使用しているS-CCPCHをリソース制御の対象としないという制御方法も考えられる。MBMSは共通チャネルを用いて、セル内に存在する全移動端末にMBMSデータを送信するために、他の個別チャネルよりも大きな送信電力で送信される。つまり、そのS-CCPCHは無線環境に大きな影響を与える可能性が高い。このことより、輻輳状態発生等により、リソース制御が必要となった際には、MBMSを提供しているS-CCPCHもその制御対象とすべきである。

本発明は、上述したような従来の技術が有する問題点に鑑みてなされたものであって、MBMSで使用されている共通チャネルのリソースを適当に制御することができる無線ネットワーク制御装置、リソース管理方法及びプログラムを提供することを目的とする。

上記目的を達成するために本発明は、
共通チャネルを用いてマルチメディアデータを複数の移動端末へ同時に送信する無線ネットワーク制御装置であって、
前記マルチメディアデータの視聴率をチャネル毎に算出する視聴率算出部と、
前記チャネルを所定の優先順位に従って解放する場合、前記視聴率が所定の閾値よりも小さなチャネルを解放するリソース管理部とを有する。

以上説明したように本発明においては、共通チャネルを用いて複数の移動端末へ同時に送信されたマルチメディアデータの視聴率をチャネル毎に算出し、チャネルを所定の優先順位に従って解放する場合、視聴率が所定の閾値よりも小さなチャネルを解放する構成としたため、MBMSで使用されている共通チャネルのリソースを適当に制御することができる。

以下に、本発明の実施の形態について図面を参照して説明する。

図１は、本発明の無線ネットワーク制御装置の実施の一形態を示す図である。

本形態は図１に示すように、CN１００と、RNC１０１と、NodeB２０１とから構成されている。また、NodeB２０１がサービスを提供するカバーエリアであるセル２０２内に、UE群３０１と、UE３０２，３０３と、Idle UE群３０４とが存在している。

CN１００は、光ケーブル等の有線回線でRNC１０１と接続されたRNC１０１の上位ネットワークである。

RNC１０１は、無線ネットワーク制御装置（Radio Network Controller）であり、CN１００及びNodeB２０１との間にて通信を行う。主にCN１００から送信されてきた信号に基づいてNodeB２０１を制御する。また、NodeB２０１とNodeB２０１配下の移動端末であるUE（User Equipment）との間の無線区間における無線リソースを管理・制御する。

NodeB２０１は、一般的な無線基地局であり、UE群３０１、UE３０２，３０３との間にて無線通信を行っている。ここで、UE群３０１はNodeB２０１からのMBMS（Multimedia Broadcast Multicast Service）を受信するためにS-CCPCH（Secondary Common Control Physical Channel）を受信している移動端末群である。UE３０２，３０３は個別のサービス（音声やパケット通信）を受信する為にDPCH（Dedicated Physical Channel）を受信している移動端末である。UE群３０１、UE３０２，３０３は通信を行っている状態であり、connected modeである。これに対して、Idle UE群３０４は通信を行っていないIdle modeの移動端末群である。

図２は、図１に示したRNC１０１の一構成例を示す図である。

図１に示したRNC１０１には図２に示すように、チャネル制御部１１０と、MBMS設定部１１１と、視聴率算出部１１２と、リソース管理部１１３と、リソース管理テーブル１１４とが設けられている。

チャネル制御部１１０は、CN１００から送信されてきた信号に基づいて、配下の移動端末との通信に用いるチャネルを制御・設定する。また、リソース管理部１１３にて制御されたリソースを当該チャネルに割り当てる。

MBMS設定部１１１は、チャネル制御部１１０にて設定されたチャネル情報に基づいてMBMSを提供する移動端末を設定する。また、MBMSを提供する場合、NodeB２０１を介して移動端末へMBMS ACCESS INFORMATIONを送信する。

視聴率算出部１１２は、MBMS設定部１１１から送信されたMBMS ACCESS INFORMATIONに対して移動端末から送信されてきたRRC connection requestまたはCell Updateに基づいて、視聴率を算出する。つまり、MBMS countingの結果得られる情報から視聴率を算出する。

リソース管理部１１３は、チャネル制御部１１０にてチャネルが制御・設定された結果と、リソース管理テーブル１１４に格納されているリソース管理情報とに基づいて、無線区間のリソースを制御する。また、リソース管理テーブル１１４に格納されているリソース管理情報を、各チャネルの情報と視聴率算出部１１２にて算出された視聴率とに基づいて並べ替える。そして、リソース管理テーブル１１４に格納されているリソース管理情報を管理する。

リソース管理テーブル１１４は、無線区間のリソース管理情報を格納する。

なお、図２には、本発明に関わる構成要素のみを示した。

図３は、図２に示したリソース管理テーブル１１４の構造の一例を示す図である。

図２に示したリソース管理テーブル１１４には図３に示すように、各チャネルのPriority Level、拡散率、Min UL Channelisation Code Length及び視聴率情報から構成されるリソース管理情報が格納されている。これにより、各チャネルの無線リソースを読み取ることができる。視聴率情報をリソース制御・管理に使用するというのは本発明の特徴のひとつである。

各Priority Levelは、CN１００から通知されるものをRNC１０１内部で処理した結果得られたPriority Levelである。０〜１５の整数が設定可能であり、０はSpare、１５はNo priorityであり、１が最も高く、１４が最も低いpriorityである（3GPP Release6 TS25.413参照）。Priority Levelの設定方法は一般的な方法を用いるため詳細についてはここでは言及しない。

拡散率は、Downlinkでの通信に使用する物理チャネルの拡散率である。この値が小さいほど、多くの無線リソースを使用する。

Min UL Channelisation Code Lengthは、Uplinkでの通信に使用する物理チャネルの拡散に使用するChannelisation Codeの長さを表したものである。この値が小さいほど、多くの無線リソースを使用する。

視聴率情報は、MBMS countingの結果得られる情報であり、PtM（Point to Multipoint）のMBMSのデータ転送に使用しているS-CCPCHにのみ付加される情報である。

なお、リソース管理テーブル１１４において、セル運用に必須な共通チャネルはリソース制御時に解放する対象とはなりえないので含んでいない。また、個別チャネルにおいて視聴率は定義できないため、未定義"-"とする。また、S-CCPCHはDownlinkのみのチャネルであるため、Uplinkで定義されるMin UL Channelisation Code Lengthを未定義"-"とする。これらの情報に基づいて、リソース管理部１１３は、リソース不足や輻輳等により、リソース制御が必要になった際の動作（既存リソースの解放、変更）を行う。

また、リソース管理部１１３は、リソース制御に用いる閾値Thr_ARを保有している。

図４は、図２に示したリソース管理部１１３が保有する閾値Thr_ARの一例を示す図である。

図４に示すような閾値Thr_ARがリソース管理部１１３に保有されており、この閾値Thr_ARは、オペレータが設定する任意の値である。また、閾値Thr_ARは、リソース制御の際に用いられる。

図５は、PtM方式とPtP（Point to Point）方式とにおけるチャネルのマッピングを示す図である。

PtM方式において、ユーザデータ転送のために使用されるチャネルは図５の上部に示すように、論理チャネルのMTCH４３１（MBMS point-to-multipoint Traffic Channel）がトランスポートチャネルのFACH４３２（Forward Access Channel）へマッピングされる。また、FACH４３２が物理チャネルのS-CCPCH４３３へマッピングされるチャネル構成となっている。S-CCPCHは共通チャネルであり、同時に複数のユーザに対して、同じデータを送信可能である。

また、PtP方式において、ユーザデータ転送のために使用されるチャネルは図５の下部に示すように、既存の個別チャネルユーザと同様に、論理チャネルのDTCH４３５（Dedicated Traffic Channel）がトランスポートチャネルのDCH４３６（Dedicated Channel）へマッピングされる。また、DCH４３６が物理チャネルのDPCH ４３７（Dedicated Physical Channel）へとマッピングされるチャネル構成となっている。

PtM方式においては共通チャネルであるS-CCPCHを使用しているため、１つのチャネルで複数のユーザに同時に同じ情報を転送することが可能である。それに対して、PtP方式においては、ユーザ毎に個別チャネルであるDPCHを設定する必要があるために、多くの無線リソースを必要とすることがわかる。一方、DPCHを使用するときには、ユーザ毎に電力制御を行うことができるために、セル全体としての送信電力を低く保つことが可能となる。このため、PtM方式とPtP方式とのどちらの転送方式を使用する必要があるのかの判断はRNC内部の制御方法やオペレータの設定方法に依存する（参考：3GPP Release6）。

以下に、図１に示したRNC１０１におけるリソース管理方法について説明する。

図６は、図１に示したRNC１０１におけるリソース管理方法を説明するためのフローチャートである。ここでは、通常運用中にDownlinkの無線区間において輻輳状態が検出された際のリソース管理方法について説明する。また、輻輳状態とは、無線区間において、UplinkとDownlinkとの少なくとも一方において送信電力が大きくなりすぎ、セル内での無線通信が干渉により正常に行えなくなる虞がある、もしくは正常に行えなくなった状態である。

無線ネットワークに輻輳状態が発生した場合、UTRANは無線リソースの制御を実施する。この輻輳状態が解消されるまで、解放を行っても影響が少ない移動端末との間の無線リソースを順に解放もしくは無線リソース使用量を減らすように設定変更する制御を行う必要がある。解放を行っても影響が少ない移動端末は、リソース管理テーブル１１４に格納されている各チャネルの優先順位に基づいて決定されるものである。本実施例においては簡略化のために、輻輳発生時に既存リソースの解放のみを行うものとする。

まず、輻輳状態が発生したことがUTRANにて検出されると（ステップＳ１）、現在MBMSがPtM方式で提供されているかどうかが判断される（ステップＳ２）。具体的に、ステップＳ１の処理は、チャネル制御部１１０とリソース管理部１１３とによって行われる。また、ステップＳ２の処理は、MBMS設定部１１１にて行われる。

ステップＳ２にて現在MBMSがPtM方式で提供されていると判断された場合、視聴率算出部１１２にて視聴率が算出される（ステップＳ３）。これは、上述したように、MBMS Countingを用いることにより行われる。

その後、リソース管理テーブル１１４に格納されているリソース管理情報と算出された視聴率の情報とに基づいてリソース管理部１１３にてリソース制御が行われる（ステップＳ４）。

ステップＳ４のリソース制御が行われた結果、輻輳状態が解除されたかどうかが、チャネル制御部１１０とリソース管理部１１３とによって判断される（ステップＳ５）。

ステップＳ５にて輻輳状態が解除されていないと判断された場合、ステップＳ２の処理が再び行われる。ステップＳ５にて輻輳状態が解除されたと判断されるまで、ステップＳ２〜Ｓ４の処理が行われる。

一方、ステップＳ２にて現在MBMSがPtM方式で提供されていないと判断された場合、リソース管理部１１３にて通常のリソース制御が行われる（ステップＳ６）。通常のリソース制御とは、個別チャネルのみを対象とした一般的なリソース制御である。

ステップＳ６のリソース制御が行われた結果、輻輳状態が解除されたかどうかが、チャネル制御部１１０とリソース管理部１１３とによって判断される（ステップＳ７）。

ステップＳ７にて輻輳状態が解除されたと判断されるまで、ステップＳ６の処理が行われる。

図７は、図６に示したステップＳ６の通常のリソース制御の処理の詳細を説明するためのフローチャートである。

まず、リソース管理部１１３にてリソース管理テーブル１１４に格納されているリソース管理情報のPriority Levelの低いものから順番に並べ替えが実施される（ステップＳ１０）。

続いて、リソース管理部１１３にてリソース管理テーブル１１４に格納されているリソース管理情報の拡散率の小さなものから順番に並べ替えが実施される（ステップＳ１１）。

さらに、リソース管理部１１３にてリソース管理テーブル１１４に格納されているリソース管理情報のMin UL Channelisation Code Lengthの小さなものから順番に並べ替えが実施される（ステップＳ１２）。

その後、リソース管理テーブル１１４のList No = １のチャネル、すなわち、リソース管理テーブル１１４の一番上に存在するチャネルがリソース管理部１１３によって解放される（ステップＳ１３）。

そして、リソース管理部１１３によってリソース管理テーブル１１４が更新される（ステップＳ１４）。ここでは、List No = １のチャネルが削除されることとなる。

なお、図３に示したリソース管理テーブル１１４においては、PtM方式で使用しているS-CCPCHが存在するため、ステップＳ６の通常のリソース制御処理は実施されない。また、本処理においてはリソース管理テーブル１１４中の視聴率情報を用いることはない。

図８は、図６に示したステップＳ４の視聴率を考慮したリソース制御の処理の詳細を説明するためのフローチャートである。

まず、リソース管理部１１３にてリソース管理テーブル１１４に格納されているリソース管理情報のPriority Levelの低いものから順番に並べ替えが実施される（ステップＳ２０）。

続いて、リソース管理部１１３にてリソース管理テーブル１１４に格納されているリソース管理情報の拡散率の小さなものから順番に並べ替えが実施される（ステップＳ２１）。

さらに、リソース管理部１１３にてリソース管理テーブル１１４に格納されているリソース管理情報のMin UL Channelisation Code Lengthの小さなものから順番に並べ替えが実施される（ステップＳ２２）。

図９は、ステップＳ２０〜Ｓ２２にてリソース管理部１１３によって並び替えられたリソース管理テーブル１１４に格納されているリソース管理情報である。

図９に示すように、リソース管理テーブル１１４には、使用されているチャネルのリソース管理情報が、Priority Levelの低いものから順番に、さらに、拡散率の小さなものから順番に、さらに、Min UL Channelisation Code Lengthの小さなものから順番に並んでいる。

その後、変数User NumberにList Noの最大値が代入される（ステップＳ２３）。User Numberはリソース管理テーブル１１４に格納されているチャネルの数を表す。これにより、リソース管理テーブル１１４に格納されているチャネルすべてを以下の処理で参照することになる。

続いて、変数iが初期値である「０」に設定され（ステップＳ２４）、変数iに「１」が加算される（ステップＳ２５）。

そして、リソース管理テーブル１１４のList Noがi番目のチャネルの視聴率とThr_ARとが比較され、当該視聴率がThr_AR以上かどうかが判断される（ステップＳ２６）。または、当該視聴率が未定義かどうかが判断される。

ステップＳ２６にて当該視聴率がThr_AR以上であると判断された場合、または、当該視聴率が未定義であると判断された場合、現在の変数iの値とUser Numberとが等しいかどうかが判断される（ステップＳ２７）。

ステップＳ２７にて現在の変数iの値とUser Numberとが等しくはないと判断された場合、ステップＳ２５の処理が再び行われる。

一方、ステップＳ２６にて当該視聴率がThr_AR以上ではないと判断された場合は、List Noがi番目のチャネルが解放される（ステップＳ２８）。そして、リソース管理テーブル１１４が更新される（ステップＳ２９）。その後、処理は終了する。

また、ステップＳ２７にて現在の変数iの値とUser Numberとが等しいと判断された場合は、処理は終了する。

以上説明したようにステップＳ２６の分岐をリソース制御中に含めることにより、視聴率が事前に決められた値（Thr_AR）よりも大きな場合に、そのチャネルが解放されることを防ぐことが可能となる。

なお、以上のステップＳ２３〜Ｓ２９の処理は、リソース管理部１１３にて行われる。

以下に、本発明における他の実施例を説明する。

前述の実施例においてThr_ARは事前に決定された静的な値であったが、この値を動的に変更し、より最適な動作を行うものであっても良い。Thr_ARが大きな値になればなるほど、MBMSで使用しているS-CCPCHが解放されやすくなる。また、Thr_ARが小さな値になればなるほど、MBMSで使用しているS-CCPCHは解放されにくくなる。

図１０は、User Numberに応じてThr_ARを動的に変化させたときの様子を示す図である。

図１０に示すように、User NumberにThr_N１及びThr_N２を定義する。それらはセル中に存在するユーザ数（User Number）に対する閾値であり、User Numberに応じてThr_ARを以下のように変更する。

０≦User Number＜Thr_N１である場合、Thr_AR＝Thr_AR１
Thr_N１≦User Number＜Thr_N２である場合、Thr_AR＝Thr_AR２
Thr_N２≦User Numberである場合、Thr_AR＝Thr_AR３
なお、上述した処理は、目的に応じて作製された論理回路で行うようにしても良い。また、処理内容を記述したプログラムをRNC１０１にて読取可能な記録媒体に記録し、この記録媒体に記録されたプログラムをRNC１０１に読み込ませ、実行するものであっても良い。RNC１０１にて読取可能な記録媒体とは、フロッピーディスク（登録商標）、光磁気ディスク、ＤＶＤ、ＣＤなどの移設可能な記録媒体の他、RNC１０１に内蔵されたＨＤＤ等を指す。この記録媒体に記録されたプログラムは、RNC１０１内のＣＰＵ（不図示）にて読み込まれ、ＣＰＵの制御によって、上述したものと同様の処理が行われる。ここで、ＣＰＵは、プログラムが記録された記録媒体から読み込まれたプログラムを実行するコンピュータとして動作するものである。

以上説明したように本発明においては、視聴率を使用したリソース制御を実施しているため、リソース制御時に視聴率の高いMBMSを解放することを回避することができる。

本発明の無線ネットワーク制御装置の実施の一形態を示す図である。 図１に示したRNCの一構成例を示す図である。 図２に示したリソース管理テーブルの構造の一例を示す図である。 図２に示したリソース管理部が保有する閾値Thr_ARの一例を示す図である。 PtM方式とPtP（Point to Point）方式とにおけるチャネルのマッピングを示す図である。 図１に示したRNCにおけるリソース管理方法を説明するためのフローチャートである。 図６に示したステップＳ６の通常のリソース制御の処理の詳細を説明するためのフローチャートである。 図６に示したステップＳ４の視聴率を考慮したリソース制御の処理の詳細を説明するためのフローチャートである。 ステップＳ２０〜Ｓ２２にてリソース管理部によって並び替えられたリソース管理テーブルに格納されているリソース管理情報である。 User Numberに応じてThr_ARを動的に変化させたときの様子を示す図である。 一般的な移動通信システムの一例を示す図である。 MBMS Countingの手順を示す図である。

符号の説明

１００ CN
１０１ RNC
１１０ チャネル制御部
１１１ MBMS設定部
１１２ 視聴率算出部
１１３ リソース管理部
１１４ リソース管理テーブル
２０１ NodeB
２０２ セル
３０１ UE群
３０２，３０３ UE
３０４ Idle UE群
４３１ MTCH
４３２ FACH
４３３ S-CCPCH
４３５ DTCH
４３６ DCH
４３７ DPCH

Claims (9)

1. 共通チャネルを用いてマルチメディアデータを複数の移動端末へ同時に送信する無線ネットワーク制御装置であって、
   前記マルチメディアデータの視聴率をチャネル毎に算出する視聴率算出部と、
   前記チャネルを、上位ネットワークからの通知に基づいた優先順位に従って解放する場合、前記視聴率が所定の閾値よりも小さなチャネルを、該チャネルの拡散率の小さなものから順に解放するリソース管理部とを有する無線ネットワーク制御装置。
2. 請求項１に記載の無線ネットワーク制御装置において、
   前記チャネルの無線リソースを示すリソース管理情報を格納するリソース管理テーブルを有し、
   前記リソース管理部は、前記リソース管理テーブルに格納された前記リソース管理情報を前記優先順位および前記拡散率に従って並べ替えることを特徴とする無線ネットワーク制御装置。
3. 請求項１に記載の無線ネットワーク制御装置において、
   前記リソース管理部は、前記マルチメディアデータを受信する移動端末の数に基づいて前記閾値を変更することを特徴とする無線ネットワーク制御装置。
4. 共通チャネルを用いてマルチメディアデータを複数の移動端末へ同時に送信する無線ネットワーク制御装置におけるリソース管理方法であって、
   前記マルチメディアデータの視聴率をチャネル毎に算出する処理と、
   前記チャネルを、上位ネットワークからの通知に基づいた優先順位に従って解放する場合、前記視聴率が所定の閾値よりも小さなチャネルを、該チャネルの拡散率の小さなものから順に解放する処理とを有するリソース管理方法。
5. 請求項４に記載のリソース管理方法において、
   前記無線ネットワーク制御装置に設けられたリソース管理テーブルに格納された前記チャネルの無線リソースを示すリソース管理情報を前記優先順位および前記拡散率に従って並べ替える処理を有することを特徴とするリソース管理方法。
6. 請求項４に記載のリソース管理方法において、
   前記マルチメディアデータを受信する移動端末の数に基づいて前記閾値を変更する処理を有することを特徴とするリソース管理方法。
7. 共通チャネルを用いてマルチメディアデータを複数の移動端末へ同時に送信する無線ネットワーク制御装置に、
   前記マルチメディアデータの視聴率をチャネル毎に算出する手順と、
   前記チャネルを、上位ネットワークからの通知に基づいた優先順位に従って解放する場合、前記視聴率が所定の閾値よりも小さなチャネルを、該チャネルの拡散率の小さなものから順に解放する手順とを実行させるプログラム。
8. 請求項７に記載のプログラムにおいて、
   前記無線ネットワーク制御装置に設けられたリソース管理テーブルに格納された前記チャネルの無線リソースを示すリソース管理情報を前記優先順位および前記拡散率に従って並べ替える手順をさらに実行させることを特徴とするプログラム。
9. 請求項７に記載のプログラムにおいて、
   前記マルチメディアデータを受信する移動端末の数に基づいて前記閾値を変更する手順をさらに実行させることを特徴とするプログラム。

Images