JP6919371B2 - 情報処理装置及びリソース割当方法 - Google Patents

Description

本発明は、情報処理装置及びリソース割当方法に関する。

近年、例えば、ＳＤＮ(Software Defined Network)やＮＦＶ(Network Function Virtualization)が広く知られている。そして、ＳＤＮやＮＦＶでは、例えば、コアネットワーク機器だけでなく、無線システム内の移動局と無線接続する基地局の機能への導入、特に基地局のレイヤ１機能への導入も検討されている。

サーバは、複数のＣＰＵ（Central Processing Unit）を有し、更に、各ＣＰＵは複数のコアを有するマルチコアＣＰＵである。そして、基地局の最大データ転送量を考慮して、ＣＰＵ内の各コアに各基地局の機能を固定的に割当てる。移動局のユーザは、例えば、動画サイトを移動局で視聴するＤＬ(Downlink)のサービス形態を使用する機会が多く、移動局から大量のデータを基地局に送信するＵＬ(Uplink)のサービス形態を使用する機会が少ないのが一般的である。しかも、例えば、復号化及び復調等のＤＬ処理は、符号化や変調等のＵＬ処理の約１／３の処理負荷である。従って、ＵＬ処理とＤＬ処理とでは、その処理負荷が大きく異なる。

特開２０１５−１４９５７８号公報 特開２０１３−２３９９１３号公報 国際公開第２０１６／０９２８５１号

サーバ等の情報処理装置では、ＣＰＵのリソースに基地局の機能を固定的に割当てることになる。しかしながら、基地局の機能は、通信状況に応じて負荷量が変動するため、例えば、負荷量が少ない場合、基地局の機能に固定的に割り当てられたＣＰＵのリソースが無駄となる。また、例えば、基地局の機能の負荷量がＣＰＵ内の割当リソース量を大きく上回る場合に基地局の機能が処理し切れなくなる。つまり、基地局の通信状況に応じてＣＰＵのリソースを効率良く活用できていない。しかも、ＣＰＵは、高価であり、消費電力も大きいため、そのＣＰＵリソースの効率的な割当が求められているのが実情である。

一つの側面では、無線装置の機能に対してリソースの効率的な割当を実現できる情報処理装置等を提供することを目的とする。

一つの案では、移動局と無線接続する無線装置の機能を有する情報処理装置である。情報処理装置は、取得部と、算出部と、割当部とを有する。取得部は、前記無線装置の無線通信に関わるスケジュール情報を取得する。算出部は、前記無線装置のスケジュール情報に基づき、前記無線装置の機能で使用するリソース量を算出する。割当部は、前記算出部で算出した前記リソース量に基づき、前記無線装置の機能で使用可能なリソースを割当てる。

一つの側面では、無線装置の機能に対してリソースの効率的な割当を実現できる。

図１は、本実施例の無線システムの一例を示すブロック図である。 図２は、ＣＰＵ内の機能構成の一例を示す説明図である。 図３は、ｅＮＢ内の機能構成の一例を示すブロック図である。 図４は、ＣＰＵの稼働状況の一例を示す説明図である。 図５は、ＳＣＤ及びリソースコントローラの一例を示す説明図である。 図６は、共有メモリのテーブル構成の一例を示す説明図である。 図７は、サブフレーム単位のＳＣＤ、リソースコントローラ及びＣＰＵの処理状況の一例を示す説明図である。 図８は、第１の設定処理に関わるリソースコントローラの処理動作の一例を示すフローチャートである。 図９は、第１の設定処理実行時に関わるリソースコントローラ、ｅＮＢ、ＣＰＵの処理動作の一例を示すシーケンス図である。 図１０は、サブフレーム単位毎の各ｅＮＢのビットレート量の一例を示す説明図である。 図１１Ａは、サブフレームｍ受信時に関わるＳＣＤ、リソースコントローラ及びＣＰＵの動作状況の一例を示す説明図である。 図１１Ｂは、サブフレームｍ＋１受信時に関わるＳＣＤ、リソースコントローラ及びＣＰＵの動作状況の一例を示す説明図である。 図１１Ｃは、サブフレームｍ＋２受信時に関わるＳＣＤ、リソースコントローラ及びＣＰＵの動作状況の一例を示す説明図である。 図１２は、第２の設定処理に関わるリソースコントローラの処理動作の一例を示すフローチャートである。 図１３は、第２の設定処理実行時に関わるリソースコントローラ、ｅＮＢ及びＣＰＵの処理動作の一例を示すシーケンス図である。 図１４は、リソース割当プログラムを実行する情報処理装置の一例を示すブロック図である。

以下、図面に基づいて、本願の開示する情報処理装置及びリソース割当方法の実施例を詳細に説明する。尚、本実施例により、開示技術が限定されるものではない。また、以下に示す各実施例は、矛盾を起こさない範囲で適宜組み合わせても良い。

図１は、本実施例の無線システム１の一例を示すブロック図である。図１に示す無線システム１は、複数のＵＥ(User Equipment)２と、各セル内のＵＥ２と無線接続するアンテナ３と、サーバ４と、ＥＰＣ(Evolved Packet Core)装置５と、例えば、インターネット等のコアネットワーク６とを有する。ＵＥ２は、例えば、ＬＴＥ(Long Term Evolution)方式の移動局である。

サーバ４は、ＣＰＵ（Central Processing Unit）１１と、メモリ１２とを有する。図２は、ＣＰＵ１１内の機能構成の一例を示す説明図である。ＣＰＵ１１は、例えば、第１のＣＰＵ１１Ａ及び第２のＣＰＵ１１Ｂ等を有する。第１のＣＰＵ１１Ａは、例えば、コア＃１、コア＃２、コア＃３及びコア＃４を有するマルチコアＣＰＵである。第２のＣＰＵ１１Ｂは、例えば、コア＃５、コア＃６、コア＃７及びコア＃８を有するマルチコアＣＰＵである。ＣＰＵ１１は、例えば、第１のＣＰＵ１１Ａや第２のＣＰＵ１１Ｂと異なるリソース上にリソースコントローラ２２の処理機能を実行している。尚、説明の便宜上、リソースコントローラ２２は、第１のＣＰＵ１１Ａや第２のＣＰＵ１１Ｂと異なるリソースで実行するようにしたが、第１のＣＰＵ１１Ａや第２のＣＰＵ１１Ｂのリソース上で実行するようにしても良い。サーバ４は、ＣＰＵ１１内のリソースを使用し、例えば、ＳＤＮ（Software Defined Network）やＮＦＶ(Network Function Virtualization)を実現する。サーバ４は、ＣＰＵ１１のリソースに基地局(ｅＮＢ:Evolved Node B)２１及びリソースコントローラ２２の処理機能を割当てる。ｅＮＢ２１は、アンテナ３と接続し、アンテナ３と無線接続するＵＥ２の基地局としての処理機能を実行するリソース上の無線装置である。リソースコントローラ２２は、ｅＮＢ２１毎のリソース量に基づき、サブフレーム単位で各ｅＮＢ２１の割当コアを決定する処理機能を実行するリソース上のコントローラである。ＥＰＣ装置５は、サーバ４と、ＬＴＥ方式のアクセス網を収容するコアネットワーク６との間を接続するゲートウェイ装置である。

リソースコントローラ２２は、ＣＰＵ１１のリソース上で各ｅＮＢ２１を動的に割当てる割当機能を有する。ｅＮＢ２１は、Ｌ１(Layer1)処理部２１Ａと、Ｌ２（Layer2）／Ｌ３（Layer3）処理部２１Ｂとを有する。Ｌ１処理部２１Ａは、Ｌ１の処理を実行する処理機能である。Ｌ２／Ｌ３処理部２１Ｂは、Ｌ２／Ｌ３の処理を実行する処理機能である。

図３は、ｅＮＢ２１内の機能構成の一例を示すブロック図である。図３に示すｅＮＢ２１内のＬ１処理部２１Ａは、ＦＦＴ(Fast Fourier Transform)３１と、等化部３２と、ＣＨ(Channel)推定部３３と、復調部３４と、復号化部３５と、符号化部３６と、変調部３７とを有する。更に、Ｌ１処理部２１Ａは、ＩＦＦＴ(Invers Fast Fourier Transform)３８と、コントローラ３９とを有する。ＦＦＴ３１は、上りの無線信号に対してＦＦＴ処理を実行し、上りの無線信号を時間領域から周波数領域に変換する。ＣＨ推定部３３は、ＦＦＴ処理後の上りの無線信号のパイロット信号からチャネルを推定する。等化部３２は、チャネル推定結果に基づき、ＦＦＴ処理後の上りの無線信号を等化処理する。復調部３４は、等化処理後の上りの無線信号を復調する。復号化部３５は、復調後の上りの無線信号を復号化する。復号化部３５は、復号化後のデータをＭＡＣ(Medium Access Control)４１に出力する。符号化部３６は、ＭＡＣ４１から得たデータを符号化する。変調部３７は、符号化されたデータを変調する。ＩＦＦＴ３８は、変調後のデータを周波数領域から時間領域の下りの無線信号に変換する。コントローラ３９は、Ｌ１処理部２１Ａを制御する。

ｅＮＢ２１内のＬ２／Ｌ３処理部２１Ｂは、ＭＡＣ４１と、ＲＬＣ(Radio Link Control)４２と、ＰＤＣＰ(Packet Data Convergence Protocol)４３と、ＲＲＣ(Radio Resource Control)４４とを有する。ＭＡＣ４１は、復号化部３５からのＬ１のデータをＬ２のデータに変換してＲＬＣ４２に出力すると共に、ＲＬＣ４２からのＬ２のデータをＬ１のデータに変換して符号化部３６に出力するＭＡＣ処理を実行する。ＲＬＣ４２は、Ｌ２の無線リンクを制御するＲＬＣ処理を実行する。ＲＲＣ４４は、無線回線を制御するＲＲＣ処理を実行する。ＰＤＣＰ４３は、ＥＰＣ装置５とＲＬＣ４２との間に配置し、データをＩＰプロトコルに変換するＰＤＣＰ処理を実行する。ＭＡＣ４１は、ＳＣＤ(Scheduler)４５を有する。ＳＣＤ４５は、ＲＬＣ４２やＰＤＣＰ４３内の図示せぬバッファのデータ滞留量や、ＵＥ２から報告されたデータ送信量に基づき、ｅＮＢ２１の無線通信に関わるＭＡＣスケジュール情報（ＳＣＤ情報）をサブフレーム毎に生成する。更に、ＳＣＤ４５は、ＳＣＤ情報をリソースコントローラ２２に通知する。尚、Ｌ１処理部２１Ａは、１ｍ秒のサブフレーム単位でＵＥ２との間でデータ通信の処理量が大きくなる部位である。尚、ＬＴＥ方式のサブフレームは１ｍ秒間隔である。

例えば、ＣＰＵ１１内のコア＃１はｅＮＢ＃１のＳＣＤ４５、コア＃５はｅＮＢ＃２のＳＣＤ４５を実行する。各ＳＣＤ４５は、ＲＬＣ４２内の図示せぬバッファにあるデータ滞留量やＵＥ２から報告されたデータ送信量の情報から、どのようにデータを送受信すべきか、サブフレーム単位のデータ送信量を決定するＳＣＤ情報を生成する。リソースコントローラ２２は、各ＳＣＤ４５からのＳＣＤ情報から各ｅＮＢが使用するリソース量を算出する。そして、リソースコントローラ２２は、ｅＮＢ毎のリソース量に基づき、ＣＰＵ１１内の複数のコアの内、サブフレーム単位で各ｅＮＢの割当コアを決定する。

図４は、ＣＰＵ１１の稼働状況の一例を示す説明図である。例えば、サブフレームｍ１のタイミングの場合、図４に示すようにコア＃１、＃２及び＃５が稼働状態にある。リソースコントローラ２２は、コア＃１及び＃２にｅＮＢ＃１のＬ１処理、コア＃５にｅＮＢ＃２のＬ１処理を割当てる。また、サブフレームｍ２のタイミングの場合、コア＃１、＃２、＃３及び＃５が稼働状態にある。リソースコントローラ２２は、例えば、コア＃１及び＃２にｅＮＢ＃１のＬ１処理、コア＃３及び＃５にｅＮＢ＃２のＬ１処理を割当てる。また、サブフレームｍ６のタイミングの場合、コア＃１〜＃５が稼働状態にある。リソースコントローラ２２は、コア＃１〜＃３にｅＮＢ＃１のＬ１処理、コア＃４及び＃５にｅＮＢ＃２のＬ１処理を割当てる。つまり、サブフレーム毎にコア＃１〜＃８の稼働状態が変動している。

図５は、ＳＣＤ４５及びリソースコントローラ２２の一例を示す説明図である。図５に示すリソースコントローラ２２は、取得部５１と、解析部５２と、算出部５３と、比較部５４と、割当部５５と、要求部５６とを有する。取得部５１は、ｅＮＢ２１内のＳＣＤ４５から無線通信に関わるＳＣＤ情報を取得する。解析部５２は、ＳＣＤ情報を解析する。算出部５３は、ＳＣＤ情報の解析結果に基づき、ｅＮＢ２１がＣＰＵリソース上で使用する使用可能なリソース量を算出する。尚、リソース量は、例えば、ｅＮＢ２１の機能が使用するＣＰＵリソース量である。比較部５４は、ｅＮＢ２１の算出リソース量と、ＣＰＵリソースの許容リソース量とを比較する。尚、許容リソース量は、ＣＰＵ１１が割当可能なＣＰＵリソース量である。割当部５５は、ｅＮＢ２１の算出リソース量が許容リソース量以下の場合、すなわち、リソースを確保した場合、ｅＮＢ２１に使用する算出リソース量に基づき、当該ｅＮＢ２１をＣＰＵリソース上に割当てる。要求部５６は、ｅＮＢ２１の算出リソース量が許容リソース量を超えた場合、すなわち、リソースを確保できなかった場合、後述する優先順位に基づき、再ＳＣＤ対象のｅＮＢ２１を選択する。そして、要求部５６は、選択したｅＮＢ２１内のＳＣＤ４５に対してＳＣＤ情報の見直しを要求する。ＳＣＤ４５は、リソースコントローラ２２からのＳＣＤ情報の見直し要求に応じて調整済みのＳＣＤ情報や使用可能な最大データレートを考慮してＳＣＤ情報を見直す。

図６は、共有メモリ１３のテーブル構成の一例を示す説明図である。尚、共有メモリ１３は、メモリ１２内にある。共有メモリ１３は、コア番号１３Ａと、リソース量１３Ｂと、処理内容１３Ｃとを有する。コア番号１３Ａは、コアを識別する番号である。リソース量１３Ｂは、コアが使用中のリソース量である。処理内容１３Ｃは、コアが実行する処理内容である。尚、リソースコントローラ２２は、共有メモリ１３内のコア毎のリソース量を参照し、各コアの最大リソース量と現在リソース量とを比較して許容リソース量を認識しているものとする。尚、最大リソース量はコアで使用可能な最大のＣＰＵリソース量、現在リソース量はコアで現在使用中のＣＰＵリソース量である。

次に実施例１の無線システム１の動作について説明する。図７は、サブフレーム単位のＳＣＤ４５、リソースコントローラ２２及びＣＰＵ１１の処理状況の一例を示す説明図である。尚、サブフレームは、例えば、ｎ、ｎ＋１、ｎ＋２、ｎ＋３…の順である。サブフレームｎのタイミングでは、サブフレームｎ＋２のＵＬのスケジューリングを実行する。サブフレームｎ＋１のタイミングで受信した信号は、サブフレームｎ＋２のタイミングで復調処理及び復号化処理を実行する。また、サブフレームｎ＋１のタイミングでは、サブフレームｎ＋３で送信する送信信号のＤＬのスケジューリングを実行する。サブフレームｎ＋２のタイミングでは、サブフレームｎ＋３で送信する送信信号の生成処理を実行する。サブフレームｎ＋２で競合するＵＬ／ＤＬリソースは、ＭＡＣスケジューリングされる時間が異なる。

リソースコントローラ２２は、ｅＮＢ＃１及び＃２のサブフレームｎ＋２のＵＬのＳＣＤ情報に基づき、ＵＬ処理に使用するリソース量を算出する。更に、リソースコントローラ２２は、ｅＮＢ＃１及び＃２のＤＬのＳＣＤ情報に基づき、ＤＬ処理に使用するリソース量を算出する。リソースコントローラ２２は、ｅＮＢ＃１及び＃２のＵＬ及びＤＬのリソース量に基づき、ｅＮＢ＃１及び＃２に割当てるＣＰＵリソースを確保できたか否かを判定する。リソースコントローラ２２は、ｅＮＢ＃１及び＃２に割当てるＣＰＵリソースを確保できた場合、ｅＮＢ＃１及び＃２を各コアに割当てるリソース情報を含むＳＣＤ結果をｅＮＢ＃１及び＃２に通知する。ｅＮＢ＃１及び＃２は、ＳＣＤ結果を共有メモリ１３に設定する。その結果、ＳＣＤ結果に対応した各コアは、共有メモリ１３内のＳＣＤ結果に基づき、各ｅＮＢ＃１及び＃２のＬ１処理を実行するスレッドを起動する。各スレッドは、ｅＮＢ毎のＳＣＤ結果に基づき、実際の無線信号処理を実行するＬ１処理を実行する。また、リソースコントローラ２２は、ｅＮＢ＃１及び＃２に割当てるＣＰＵリソースを確保できなかった場合、ｅＮＢ＃１及び＃２内のＳＣＤ４５に対してＳＣＤ情報の見直しを要求する。

ｅＮＢ＃１のＳＣＤ４５がＵＬのＳＣＤ情報をリソースコントローラ２２、ｅＮＢ＃２のＳＣＤ４５がＵＬのＳＣＤ情報をリソースコントローラ２２に通知する。そして、リソースコントローラ２２は、ＵＬのＳＣＤ情報に対応するリソース量と、各コアの許容リソース量とに基づき、ｅＮＢ＃１及び＃２のリソース情報を含むＳＣＤ結果を共有メモリ１３に設定する。サブフレームｎ＋１のタイミングでは、各コアは、共有メモリ１３のリソース情報を含むＳＣＤ結果に基づき、受信信号を復調及び復号化する。サブフレームｎ＋２のタイミングでは、ｅＮＢ＃１のＳＣＤ４５がＤＬのＳＣＤ情報をリソースコントローラ２２、ｅＮＢ＃２のＳＣＤ４５がＤＬのＳＣＤ情報をリソースコントローラ２２に通知する。そして、リソースコントローラ２２は、ＤＬのＳＣＤ情報に対応するリソース量と、コアの許容リソース量とに基づき、ｅＮＢ＃１及び＃２のリソース情報を含むＳＣＤ結果を共有メモリ１３に設定する。サブフレームｎ＋３のタイミングでは、各コアは、共有メモリ１３のリソース情報を含むＳＣＤ結果に基づき、送信信号を符号化して変調する。

図８は、第１の設定処理に関わるリソースコントローラ２２の処理動作の一例を示すフローチャートである。リソースコントローラ２２は、各ＳＣＤ４５からｅＮＢ２１毎のＳＣＤ情報を受信したか否かを判定する（ステップＳ２１）。リソースコントローラ２２は、ｅＮＢ２１毎のＳＣＤ情報を受信した場合（ステップＳ２１肯定）、ｅＮＢ２１毎のＳＣＤ情報を解析する（ステップＳ２２）。

リソースコントローラ２２は、各ＳＣＤ情報からｅＮＢ２１毎のリソース量を算出する（ステップＳ２３）。リソースコントローラ２２は、ｅＮＢ２１毎のリソース量を算出した後、ｅＮＢ２１単位にリソース量と許容リソース量とを比較する（ステップＳ２４）。リソースコントローラ２２は、比較結果に基づき、各ｅＮＢ２１のリソース量をコア上で確保できたか否かを判定する（ステップＳ２５）。リソースコントローラ２２は、各ｅＮＢ２１のリソース量がコア上で確保できた場合（ステップＳ２５肯定）、リソース情報を生成する（ステップＳ２６）。尚、リソース情報は、例えば、ｅＮＢ２１の機能に割当てるコア等のリソース量を含む情報である。リソースコントローラ２２は、生成したリソース情報を更新し（ステップＳ２７）、ｅＮＢ２１毎のリソース情報を含むＳＣＤ結果を各ＳＣＤ４５に通知し（ステップＳ２８）、図８に示す処理動作を終了する。

リソースコントローラ２２は、各ｅＮＢ２１のリソース量がコア上に確保できなかった場合（ステップＳ２５否定）、優先順位に基づき、再ＳＣＤ対象のｅＮＢ２１を選択する（ステップＳ２９）。リソースコントローラ２２は、選択した再ＳＣＤ対象のｅＮＢ２１のＳＣＤ４５に対して利用可能な最大データレートを通知する（ステップＳ３０）。更に、リソースコントローラ２２は、再ＳＣＤ対象のｅＮＢ２１のＳＣＤ４５に対してＳＣＤ情報の見直しを要求し（ステップＳ３１）、ｅＮＢ２１毎のＳＣＤ情報を受信したか否かを判定すべく、ステップＳ２１に移行する。リソースコントローラ２２は、ｅＮＢ２１毎のＳＣＤ情報を受信しなかった場合（ステップＳ２１否定）、図８に示す処理動作を終了する。

リソースコントローラ２２は、各ｅＮＢ２１内のＳＣＤ４５からのＳＣＤ情報に基づき、ｅＮＢ２１毎のリソース量を算出する。リソースコントローラ２２は、算出リソース量と許容リソース量とを比較し、ｅＮＢ２１のリソースを確保したか否かを判定する。リソースコントローラ２２は、ｅＮＢ２１のリソースを確保した場合、リソース情報を生成し、ｅＮＢ２１毎のリソース情報を含むＳＣＤ結果を各ＳＣＤ４５に通知する。その結果、リソースコントローラ２２は、ｅＮＢ２１のＳＣＤ情報に応じてｅＮＢ２１に割当てるコアを含むリソース情報をＳＣＤ４５に通知できる。

リソースコントローラ２２は、ｅＮＢ２１のリソースを確保できなかった場合、優先順位に基づき、再ＳＣＤ対象のｅＮＢ２１を選択し、選択したｅＮＢ２１に対して利用可能な最大データレートを通知してＳＣＤ情報の見直しを要求する。その結果、リソースコントローラ２２は、再ＳＣＤ対象のｅＮＢ２１内のＳＣＤ４５から見直したＳＣＤ情報を取得できる。

図９は、第１の設定処理実行時に関わるリソースコントローラ２２、ｅＮＢ２１、ＣＰＵ１１の処理動作の一例を示すシーケンス図である。ｅＮＢ＃１は、サブフレームの先頭を検出したか否かを判定する（ステップＳ４１Ａ）。また、ｅＮＢ＃２も、サブフレームの先頭を検出したか否かを判定する（ステップＳ４１Ｂ）。ｅＮＢ＃１は、サブフレームの先頭を検出した場合（ステップＳ４１Ａ肯定）、処理結果を受信する（ステップＳ４２Ａ）。ｅＮＢ＃１は、処理結果に基づき、ＳＣＤ情報を生成する（ステップＳ４３Ａ）。ｅＮＢ＃１は、生成したＳＣＤ情報をリソースコントローラ２２に通知する（ステップＳ４４）。

ｅＮＢ＃２も、サブフレームの先頭を検出した場合（ステップＳ４１Ｂ肯定）、処理結果を受信する（ステップＳ４２Ｂ）。ｅＮＢ＃２は、処理結果に基づき、ＳＣＤ情報を生成する（ステップＳ４３Ｂ）。ｅＮＢ＃２は、生成したＳＣＤ情報をリソースコントローラ２２に通知する（ステップＳ４４）。

リソースコントローラ２２は、各ｅＮＢ２１からのＳＣＤ情報を受信した場合、第１の設定処理を実行する（ステップＳ４５）。リソースコントローラ２２は、ｅＮＢ＃１及び＃２のリソースを確保したか否かを判定する（ステップＳ４６）。リソースコントローラ２２は、リソースを確保した場合（ステップＳ４６肯定）、リソース情報を含むＳＣＤ結果をｅＮＢ＃１及び＃２に通知する（ステップＳ４７）。ｅＮＢ＃１は、ＳＣＤ結果を受信し、受信したＳＣＤ結果を設定し（ステップＳ４８Ａ）、ＳＣＤ結果を共有メモリ１３に設定する（ステップＳ４９Ａ）。また、ｅＮＢ＃２も、ＳＣＤ結果を受信した場合、受信したＳＣＤ結果を設定し（ステップＳ４８Ｂ）、ＳＣＤ結果を共有メモリ１３に設定する（ステップＳ４９Ｂ）。

次に、リソースコントローラ２２は、次のサブフレームの先頭を検出したか否かを判定する（ステップＳ５０）。リソースコントローラ２２は、サブフレームの先頭を検出した場合（ステップＳ５０肯定）、共有メモリ１３のＳＣＤ結果に基づき、例えば、コア＃１〜＃４上でスレッドを起動する（ステップＳ５１）。例えば、コア＃１及び＃３は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃１のＬ１処理を実行する（ステップＳ５２Ａ）。更に、コア＃２及び＃４は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃２のＬ１処理を実行する（ステップＳ５２Ｂ）。そして、コア＃１及び＃３は、ｅＮＢ＃１のＬ１処理実行後、起動中のスレッドを停止する（ステップＳ５３Ａ）。更に、コア＃２及び＃４は、ｅＮＢ＃２のＬ１処理実行後、起動中のスレッドを停止する（ステップＳ５３Ｂ）。

コア＃１〜＃４は、Ｌ１処理実行後に処理結果を共有メモリ１３に設定する（ステップＳ５４）。そして、ｅＮＢ＃１及び＃２は、次のサブフレームの先頭を検出したか否かを判定する（ステップＳ５５Ａ及びＳ５５Ｂ）。ｅＮＢ＃１及び＃２は、サブフレームの先頭を検出した場合（ステップＳ５５Ａ肯定及びＳ５５Ｂ肯定）、処理結果を受信する（ステップＳ５６Ａ及びＳ５６Ｂ）。ｅＮＢ＃１及び＃２は、処理結果に基づき、ＳＣＤ情報を生成する（ステップＳ５７Ａ及びＳ５７Ｂ）。ｅＮＢ＃１及び＃２は、ＳＣＤ情報をリソースコントローラ２２に通知し、ステップＳ４５以降の処理動作を実行することになる。

また、リソースコントローラ２２は、リソースを確保できなかった場合（ステップＳ４６否定）、ＳＣＤ情報の見直しをｅＮＢ＃１及び＃２のＳＣＤ４５に要求する（ステップＳ５８）。そして、ｅＮＢ＃１及び＃２内のＳＣＤ４５は、見直し要求に応じてＳＣＤ情報を見直し（ステップＳ５９Ａ及びＳ５９Ｂ）、見直し後のＳＣＤ情報をリソースコントローラ２２に通知する（ステップＳ５９Ｃ）。そして、リソースコントローラ２２は、ステップＳ５９ＣにてＳＣＤ情報を受信した場合に、第１の設定処理を実行すべく、ステップＳ４５に移行する。リソースコントローラ２２は、次のサブフレームの先頭を検出したのでない場合（ステップＳ５０否定）、サブフレームの先頭を検出したか否かを判定すべく、ステップＳ５０に移行する。

本実施例のリソースコントローラ２２は、各ｅＮＢ２１内のＳＣＤ４５からＳＣＤ情報を取得し、ＳＣＤ情報からｅＮＢ２１のリソース量を算出し、リソース量に基づき、ＣＰＵ１１内の複数のコアの内、任意のコアにｅＮＢ２１を動的に割り当てる。その結果、ｅＮＢ２１に対してＣＰＵリソースの効率的な割当を実現できる。しかも、ＣＰＵリソースの効率的な割当を実現することで、複数のｅＮＢ２１全体で使用する消費電力を個別に制御する場合に比較して消費電力を削減できる。しかも、同一パフォーマンスを得るために必要なリソースを削減してＣＰＵコストを削減できる。

リソースコントローラ２２は、ｅＮＢ２１の算出リソース量が許容リソース量を超えた場合に優先順位で選択したｅＮＢ２１のＳＣＤ４５にＳＣＤ情報の見直しを要求する。その結果、見直し後のＳＣＤ情報に基づき、リソース量を見直し、見直し後のリソース量に基づき、複数のコアの内、任意のコアに当該ｅＮＢ２１を割当てる。

リソースコントローラ２２は、ｅＮＢ２１毎に最大転送量を優先的に割り当てる優先順位に基づき、複数のコアの内、ｅＮＢ２１を任意のコアに割当てる。その結果、優先順位に基づき、複数のコアの内、任意のコアに当該ｅＮＢ２１を割当てる。

リソースコントローラ２２は、ｅＮＢ２１毎の転送データを保持するバッファ内のデータ滞留量に応じて当該データ滞留量が最大のｅＮＢ２１の優先度が高くなるように優先順位を設定する。その結果、データ滞留量が大きいｅＮＢ２１から優先的にコアを割当てることができる。

尚、ＬＴＥ方式では、１ｍ秒のサブフレーム毎に負荷が大きく変動するため、通常のサーバ４のＯＳ(Operating System)で使用するＣＰＵ負荷を用いた事後制御では、システムが正常に動作できない。これに対して、本実施例では、各ｅＮＢ２１内のＳＣＤ４５からＳＣＤ情報を取得し、ＳＣＤ情報からｅＮＢ２１のリソース量を算出し、リソース量と、ＣＰＵ１１内の許容リソース量とを比較してｅＮＢ２１を任意のコアに割当てることができる。つまり、サブフレーム毎に負荷が大きく変動した場合でも、各ｅＮＢ２１を効率良く任意のコアに割当てるため、システムが正常に動作できる。しかも、例えば、昼や夜等の時間帯毎にＣＰＵリソースの割当を変更することも考えられるが、本実施例の場合には、サブフレーム単位で各ｅＮＢ２１に対するＣＰＵリソースの割当を瞬時に変更できる。

尚、上記実施例１では、サブフレーム毎に各ｅＮＢ＃１〜＃３のＳＣＤ情報に対応したリソース量に応じて、複数のコアの内、任意のコアにｅＮＢ＃１〜＃３を割当てたが、本実施例の形態に限定されるものではなく、適宜変更可能である。そこで、例えば、ｅＮＢ＃１〜＃３に割り当てたコアを集約する際の実施の形態につき、実施例２として以下に説明する。

図１０は、サブフレーム単位毎の各ｅＮＢ２１のビットレート量の一例を示す説明図である。図１０に示すサブフレームｍのタイミングでは、ｅＮＢ＃１〜＃３のビットレート量が所定量Ｘよりも大きい状態にある。また、サブフレームｍ＋１のタイミングでは、ｅＮＢ＃３のビットレート量が所定量Ｘよりも大きく、ｅＮＢ＃１及び＃２のビットレート量が所定量Ｘ以下の状態にある。また、サブフレームｍ＋２のタイミングでは、ｅＮＢ＃１〜＃３のビットレート量が所定量Ｘ以下の状態にある。

図１１Ａは、サブフレームｍ受信時に関わるＳＣＤ４５、リソースコントローラ２２及びＣＰＵ１１の動作状況の一例を示す説明図である。リソースコントローラ２２は、サブフレームｍのタイミング時に、例えば、コア＃１にｅＮＢ＃３のＬ１処理を割当てる。更に、リソースコントローラ２２は、コア＃２にｅＮＢ＃１のＬ１処理を割当てる。更に、リソースコントローラ２２は、コア＃３にｅＮＢ＃２のＬ１処理を割当てる。

図１１Ｂは、サブフレームｍ＋１受信時に関わるＳＣＤ４５、リソースコントローラ２２及びＣＰＵ１１の動作状況の一例を示す説明図である。リソースコントローラ２２は、サブフレームｍ＋１のタイミング時に、コア＃１にｅＮＢ＃３のＬ１処理を割当てる。更に、リソースコントローラ２２は、コア＃３にｅＮＢ＃１及び＃２のＬ１処理を割当てる。

図１１Ｃは、サブフレームｍ＋２受信時に関わるＳＣＤ４５、リソースコントローラ２２及びＣＰＵ１１の動作状況の一例を示す説明図である。リソースコントローラ２２は、サブフレームｍ＋２のタイミング時に、コア＃３にｅＮＢ＃１〜＃３のＬ１処理を割当てる。

図１２は、第２の設定処理に関わるリソースコントローラ２２の処理動作の一例を示すフローチャートである。リソースコントローラ２２は、各ＳＣＤ４５からｅＮＢ２１毎のＳＣＤ情報を受信したか否かを判定する（ステップＳ６１）。リソースコントローラ２２は、ＳＣＤ情報を受信した場合（ステップＳ６１肯定）、ｅＮＢ２１毎のＳＣＤ情報を解析する（ステップＳ６２）。リソースコントローラ２２は、各ＳＣＤ情報からｅＮＢ２１毎のリソース量を算出し（ステップＳ６３）、ｅＮＢ２１単位にリソース量とコアの許容リソース量とを比較する（ステップＳ６４）。

リソースコントローラ２２は、比較結果に基づき、ｅＮＢ２１のリソースを確保したか否かを判定する（ステップＳ６５）。リソースコントローラ２２は、ｅＮＢ２１のリソースを確保した場合（ステップＳ６５肯定）、ｅＮＢ２１を指定する（ステップＳ６６）。リソースコントローラ２２は、指定したｅＮＢ２１のビットレート量が所定量Ｘ以下であるか否かを判定する（ステップＳ６７）。

リソースコントローラ２２は、指定したｅＮＢ２１のビットレート量が所定量Ｘ以下の場合（ステップＳ６７肯定）、未指定のｅＮＢ２１があるか否かを判定する（ステップＳ６８）。リソースコントローラ２２は、未指定のｅＮＢ２１がなしの場合（ステップＳ６８否定）、所定量Ｘ以下のｅＮＢ２１が集約可能であるか否かを判定する（ステップＳ６９）。

リソースコントローラ２２は、所定量Ｘ以下のｅＮＢ２１が集約可能である場合（ステップＳ６９肯定）、所定量Ｘ以下のｅＮＢ２１の処理を実行するコアを集約する（ステップＳ７０）。そして、リソースコントローラ２２は、所定量Ｘ以下のｅＮＢ２１の処理を実行するコアを集約後、リソース情報を生成する（ステップＳ７１）。リソースコントローラ２２は、生成したリソース情報を更新し（ステップＳ７２）、リソース情報を含むＳＣＤ結果を各ｅＮＢ２１のＳＣＤ４５に通知し（ステップＳ７３）、図１２に示す処理動作を終了する。

リソースコントローラ２２は、リソースを確保できなかった場合（ステップＳ６５否定）、優先順位に基づき、再ＳＣＤ対象のｅＮＢ２１を選択する（ステップＳ７４）。リソースコントローラ２２は、選択したｅＮＢ２１に利用可能な最大データレートを通知する（ステップＳ７５）。リソースコントローラ２２は、再ＳＣＤ対象のｅＮＢ２１のＳＣＤ４５に対してＳＣＤ情報の見直しを要求し（ステップＳ７６）、ｅＮＢ２１毎のＳＣＤ情報を受信したか否かを判定すべく、ステップＳ６１に移行する。リソースコントローラ２２は、指定したｅＮＢ２１のビットレート量が所定量Ｘ以下でない場合（ステップＳ６７否定）、未指定のｅＮＢ２１があるか否かを判定すべく、ステップＳ６８に移行する。リソースコントローラ２２は、未指定のｅＮＢ２１がある場合（ステップＳ６８肯定）、未指定のｅＮＢ２１を指定すべく、ステップＳ６６に移行する。リソースコントローラ２２は、所定量Ｘ以下のｅＮＢ２１が集約可能でない場合（ステップＳ６９否定）、リソース情報を生成すべく、ステップＳ７１に移行する。リソースコントローラ２２は、ＳＣＤ情報を受信しなかった場合（ステップＳ６１否定）、図１２に示す処理動作を終了する。

リソースコントローラ２２は、各ｅＮＢ２１内のＳＣＤ４５からのＳＣＤ情報に基づき、ｅＮＢ２１毎のリソース量を算出する。リソースコントローラ２２は、算出リソース量と許容リソース量とを比較し、ｅＮＢ２１のリソースを確保したか否かを判定する。リソースコントローラ２２は、ｅＮＢ２１のリソースを確保し、リソース量が所定量Ｘ以下のｅＮＢ２１がある場合、所定量Ｘ以下のｅＮＢ２１をコアに集約して割当てる。

図１３は、第２の設定処理実行時に関わるリソースコントローラ２２、ｅＮＢ２１及びＣＰＵ１１の処理動作の一例を示すシーケンス図である。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、サブフレームの先頭を受信したか否かを判定する（ステップＳ８１）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、サブフレームの先頭を受信した場合（ステップＳ８１肯定）、処理結果を受信する（ステップＳ８２）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、受信した処理結果に基づき、ＳＣＤ情報を生成する（ステップＳ８３）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、生成したＳＣＤ情報をリソースコントローラ２２に通知する（ステップＳ８４）。

リソースコントローラ２２は、受信したｅＮＢ＃１〜＃３のＳＣＤ情報に基づき、第２の設定処理を実行する（ステップＳ８５）。リソースコントローラ２２は、ｅＮＢ＃１〜＃３のリソースを確保したか否かを判定する（ステップＳ８６）。

リソースコントローラ２２は、ｅＮＢ＃１〜＃３のリソースを確保した場合（ステップＳ８６肯定）、リソース情報を含むＳＣＤ結果を各ＳＣＤ４５に通知する（ステップＳ８７）。リソースコントローラ２２は、ｅＮＢ２１毎のＳＣＤ結果を各ＳＣＤ４５に設定する（ステップＳ８８）。各ＳＣＤ４５は、ｅＮＢ２１毎のＳＣＤ結果を共有メモリ１３に設定する（ステップＳ８９）。コア＃１〜＃３は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃１〜＃３毎のスレッドを起動する（ステップＳ９０）。コア＃１は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃１のＬ１処理を実行する（ステップＳ９１Ａ）。更に、コア＃１は、ｅＮＢ＃１のＬ１処理を実行した後、スレッドを停止する（ステップＳ９２Ａ）。また、コア＃２は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃２のＬ１処理を実行する（ステップＳ９１Ｂ）。更に、コア＃２は、ｅＮＢ＃２のＬ１処理を実行した後、スレッドを停止する（ステップＳ９２Ａ）。また、コア＃３は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃３のＬ１処理を実行する（ステップＳ９１Ｃ）。更に、コア＃３は、ｅＮＢ＃３のＬ１処理を実行した後、スレッドを停止する（ステップＳ９２Ｃ）。

リソースコントローラ２２は、リソースが確保できなかった場合（ステップＳ８６否定）、ＳＣＤ情報の見直しを各ｅＮＢ＃１〜＃３のＳＣＤ４５に要求する（ステップＳ９３）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、見直し要求に応じてＳＣＤ情報を見直しし（ステップＳ９４）、見直し後のＳＣＤ情報をリソースコントローラ２２に通知する（ステップＳ９５）。そして、リソースコントローラ２２は、ＳＣＤ情報に基づき、第２の設定処理を実行すべく、ステップＳ８５に移行する。

また、各ｅＮＢ２１は、サブフレームの先頭を検出したか否かを判定する（ステップＳ９６）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、サブフレームの先頭を受信した場合（ステップＳ９６肯定）、処理結果を受信する（ステップＳ９７）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、受信した処理結果に基づき、ＳＣＤ情報を生成する（ステップＳ９８）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、生成したＳＣＤ情報をリソースコントローラ２２に通知する（ステップＳ９９）。

リソースコントローラ２２は、受信したｅＮＢ＃１〜＃３のＳＣＤ情報に基づき、第２の設定処理を実行する（ステップＳ１００）。リソースコントローラ２２は、ｅＮＢ＃１〜＃３のリソースを確保したか否かを判定する（ステップＳ１０１）。

リソースコントローラ２２は、ｅＮＢ＃１〜＃３のリソースを確保した場合（ステップＳ１０１肯定）、リソース情報を含むＳＣＤ結果を各ＳＣＤ４５に通知する（ステップＳ１０２）。リソースコントローラ２２は、ｅＮＢ毎のＳＣＤ結果を各ＳＣＤ４５に設定する（ステップＳ１０３）。各ＳＣＤは、ｅＮＢ毎のＳＣＤ結果を共有メモリ１３に設定する（ステップＳ１０４）。コア＃１は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃１及び＃２のスレッドを起動する（ステップＳ１０５Ａ）。コア＃１は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃１及び＃２のＬ１処理を実行する（ステップＳ１０６Ａ）。更に、コア＃１は、ｅＮＢ＃１のＬ１処理を実行した後、スレッドを停止する（ステップＳ１０７Ａ）。また、コア＃３は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃３のスレッドを起動する（ステップＳ１０５Ｂ）。コア＃３は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃３のＬ１処理を実行する（ステップＳ１０６Ｂ）。更に、コア＃３は、ｅＮＢ＃３のＬ１処理を実行した後、スレッドを停止する（ステップＳ１０７Ｂ）。

リソースコントローラ２２は、リソースが確保できなかった場合（ステップＳ１０１否定）、ＳＣＤ情報の見直しを各ｅＮＢ＃１〜＃３のＳＣＤ４５に要求する（ステップＳ１０８）。ｅＮＢ＃１〜＃３内の各ＳＣＤ４５は、見直し要求に応じてＳＣＤ情報を見直す（ステップＳ１０９）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、見直し後のＳＣＤ情報をリソースコントローラ２２に通知する（ステップＳ１１０）。リソースコントローラ２２は、受信したｅＮＢ＃１〜＃３のＳＣＤ情報に基づき、第２の設定処理を実行すべく、ステップＳ１００に移行する。

また、各ｅＮＢ＃１〜＃３は、サブフレームの先頭を検出したか否かを判定する（ステップＳ１１１）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、サブフレームの先頭を受信した場合（ステップＳ１１１）、処理結果を受信する（ステップＳ１１２）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、受信した処理結果に基づき、ＳＣＤ情報を生成する（ステップＳ１１３）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、生成したＳＣＤ情報をリソースコントローラ２２に通知する（ステップＳ１１４）。

リソースコントローラ２２は、受信したｅＮＢ＃１〜＃３のＳＣＤ情報に基づき、第２の設定処理を実行する（ステップＳ１１５）。リソースコントローラ２２は、ｅＮＢ＃１〜＃３のリソースを確保したか否かを判定する（ステップＳ１１６）。

リソースコントローラ２２は、ｅＮＢ＃１〜＃３のリソースを確保した場合（ステップＳ１１６肯定）、リソース情報を含むＳＣＤ結果を各ＳＣＤ４５に通知する（ステップＳ１１７）。リソースコントローラ２２は、ｅＮＢ毎のＳＣＤ結果を各ＳＣＤ４５に設定する（ステップＳ１１８）。各ＳＣＤ４５は、ｅＮＢ毎のＳＣＤ結果を共有メモリ１３に設定する（ステップＳ１１９）。コア＃１は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃１〜＃３のスレッドを起動する（ステップＳ１２０）。コア＃１は、共有メモリ１３内のＳＣＤ結果に基づき、ｅＮＢ＃１〜＃３のＬ１処理を実行する（ステップＳ１２１）。更に、コア＃１は、ｅＮＢ＃１のＬ１処理を実行した後、スレッドを停止する（ステップＳ１２２）。

リソースコントローラ２２は、リソースが確保できなかった場合（ステップＳ１１６否定）、ＳＣＤ情報の見直しを各ｅＮＢ＃１〜＃３のＳＣＤ４５に要求する（ステップＳ１２３）。ｅＮＢ＃１〜＃３内の各ＳＣＤ４５は、見直し要求に応じてＳＣＤ情報を見直す（ステップＳ１２４）。ｅＮＢ＃１〜＃３内のＳＣＤ４５は、見直し後のＳＣＤ情報をリソースコントローラ２２に通知する（ステップＳ１２５）。リソースコントローラ２２は、受信したｅＮＢ＃１〜＃３のＳＣＤ情報に基づき、第２の設定処理を実行すべく、ステップＳ１１５に移行する。

リソースコントローラ２２は、図１０に示すサブフレームｍを受信した場合、図１１Ａに示すように、ｅＮＢ＃３のＬ１処理をコア＃１に、ｅＮＢ＃１のＬ１処理をコア＃２に、ｅＮＢ＃２のＬ１処理をコア＃３に割当てる。

リソースコントローラ２２は、図１０に示すサブフレームｍ＋１を受信した場合、図１１Ｂに示すように、ｅＮＢ＃３のＬ１処理をコア＃１に、ｅＮＢ＃２及びｅＮＢ＃１のＬ１処理をコア＃３に割当てる。つまり、ｅＮＢ＃２及びｅＮＢ＃１のビットレート量が所定量Ｘ以下のため、ｅＮＢ＃２及びｅＮＢ＃１のＬ１処理をコア＃３に集約する。

リソースコントローラ２２は、図１０に示すサブフレームｍ＋２を受信した場合、図１１Ｃに示すように、ｅＮＢ＃１、ｅＮＢ＃２及びｅＮＢ＃３のＬ１処理をコア＃３に割当てる。つまり、ｅＮＢ＃１〜ｅＮＢ＃３のビットレート量が所定量Ｘ以下のため、ｅＮＢ＃１〜＃３のＬ１処理をコア＃３に集約する。

実施例２では、ｅＮＢ２１のビットレート量が所定量Ｘ以下の場合、当該ｅＮＢ２１のＬ１処理を任意のコアに集約する。その結果、コアの無駄な稼働を抑制することで、消費電力の削減を図ると共に、ｅＮＢ２１に対してリソースの効率的な割当を実現できる。

尚、上記実施例では、ＣＰＵ１１内のコア単位でｅＮＢ２１等の処理機能を分散して割当てるようにしたが、ＣＰＵ１１単位で割当てても良い。また、ＣＰＵ１１内のリソースやコア内のリソースを複数の処理機能に分散して割当てても良く、適宜設定変更可能である。

上記実施例では、ＬＴＥ方式のｅＮＢ２１をコアのリソース上に実行した場合を例示したが、ＵＥ２を無線接続するｅＮＢ２１に限定されるものではなく、例えば、アクセスポイント等の無線中継装置の機能に適用しても良く、適宜変更可能である。また、ＬＴＥ方式に限定されるものではなく、例えば、５Ｇ等のｅＮＢにも適用可能である。

上記実施例では、優先順位として、例えば、データ滞留量が多い順で説明した。しかしながら、これに限定されるものではなく、ユーザ数、例えば、ＲＲＣ接続ユーザ数の多いセルのｅＮＢ２１の順や、データレート実績、例えば、過去の所定フレーム数に対するデータレートが多いセルのｅＮＢ２１の順を優先順位としても良く、適宜変更可能である。

また、図示した各部の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各部の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況等に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

更に、各装置で行われる各種処理機能は、ＣＰＵ（又はＭＰＵ（Micro Processing Unit）、ＭＣＵ（Micro Controller Unit）等のマイクロ・コンピュータ）上で、その全部又は任意の一部を実行するようにしても良い。また、各種処理機能は、ＣＰＵ（又はＭＰＵ、ＭＣＵ等のマイクロ・コンピュータ）で解析実行するプログラム上、又はワイヤードロジックによるハードウェア上で、その全部又は任意の一部を実行するようにしても良いことは言うまでもない。

ところで、本実施例で説明した各種の処理は、予め用意されたプログラムを情報処理装置内のＣＰＵ等のプロセッサで実行させることによって実現できる。そこで、以下では、上記実施例と同様の機能を有するプログラムを実行する情報処理装置の一例を説明する。図１４は、リソース割当プログラムを実行する情報処理装置の一例を示すブロック図である。

図１４に示すリソース割当プログラムを実行する情報処理装置１００は、通信ＩＦ１１０と、ＲＯＭ１２０と、ＲＡＭ１３０と、ＣＰＵ１４０とを有する。更に、通信ＩＦ１１０、ＲＯＭ１２０、ＲＡＭ１３０及びＣＰＵ１４０は、バス１５０を介して接続される。

そして、ＲＯＭ１２０には、上記実施例と同様の機能を発揮するリソース割当プログラムが予め記憶されている。ＲＯＭ１２０には、リソース割当プログラムとして取得プログラム１２０Ａ、算出プログラム１２０Ｂ及び割当プログラム１２０Ｃが記憶されている。尚、ＲＯＭ１２０ではなく、図示せぬドライブでコンピュータ読取可能な記録媒体に情報処理プログラムが記録されていても良い。また、記録媒体としては、例えば、ＣＤ−ＲＯＭ、ＤＶＤディスク、ＵＳＢメモリ等の可搬型記録媒体、フラッシュメモリ等の半導体メモリ等でも良い。

そして、ＣＰＵ１４０は、取得プログラム１２０ＡをＲＯＭ１２０から読み出して取得プロセス１４０Ａとして機能する。ＣＰＵ１４０は、算出プログラム１２０ＢをＲＯＭ１２０から読み出して算出プロセス１４０Ｂとして機能する。ＣＰＵ１４０は、割当プログラム１２０ＣをＲＯＭ１２０から読み出して割当プロセス１４０Ｃとして機能する。

ＣＰＵ１４０は、移動局と無線接続する無線装置の機能で使用可能なリソースを割当てる。ＣＰＵ１４０は、無線装置の無線通信に関わるスケジュール情報を取得する。ＣＰＵ１４０は、無線装置のスケジュール情報に基づき、前記無線装置の機能で使用するリソース量を算出する。ＣＰＵ１４０は、算出したリソース量に基づき、当該無線装置の機能で使用可能なリソースを割当てる。その結果、無線装置の機能に対してリソースの効率的な割当を実現できる。

２ ＵＥ
４ サーバ
１１ ＣＰＵ
２１ ｅＮＢ
２２ リソースコントローラ
５１ 取得部
５３ 算出部
５５ 割当部
５６ 要求部

Claims (7)

1. 移動局と無線接続する無線装置の機能で使用するプロセッサを有する情報処理装置であって、
   前記無線装置の無線通信に関わるスケジュール情報を取得する取得部と、
   前記無線装置のスケジュール情報に基づき、前記無線装置の機能で使用する前記プロセッサのリソース量を算出する算出部と、
   前記算出部で算出した前記プロセッサのリソース量に基づき、前記無線装置の機能で使用可能な前記プロセッサのリソースを割当てる割当部と
   を有することを特徴とする情報処理装置。
2. 前記取得部は、
   前記無線装置の無線通信処理に関わるＭＡＣ（Medium Access Control）スケジュール情報を前記スケジュール情報として取得することを特徴とする請求項１に記載の情報処理装置。
3. 前記情報処理装置は、
   前記リソースを提供するプロセッサを有し、
   前記算出部は、
   前記無線装置の機能で使用する前記プロセッサのリソース量を前記リソース量として算出することを特徴とする請求項１に記載の情報処理装置。
4. 前記算出部にて算出した前記無線装置の機能で使用する前記プロセッサのリソース量が許容リソース量を超えた場合に、当該無線装置の機能が使用する前記スケジュール情報の見直しを要求する要求部を有することを特徴とする請求項１に記載の情報処理装置。
5. 前記割当部は、
   前記無線装置の機能毎に最大転送量を優先的に割り当てる優先順位に基づき、前記無線装置の機能で使用可能な前記プロセッサのリソースを割当てることを特徴とする請求項１〜４の何れか一つに記載の情報処理装置。
6. 前記割当部は、
   前記無線装置の機能毎の転送データを保持するバッファ内のデータ滞留量に応じた前記優先順位に基づき、前記無線装置の機能で使用可能な前記プロセッサのリソースを割当てることを特徴とする請求項５に記載の情報処理装置。
7. 移動局と無線接続する無線装置の機能で使用するプロセッサを有し、使用可能な前記プロセッサのリソースを割当てる情報処理装置が、
   前記無線装置の無線通信に関わるスケジュール情報を取得し、
   前記無線装置のスケジュール情報に基づき、前記無線装置の機能で使用する前記プロセッサのリソース量を算出し、
   算出した前記プロセッサのリソース量に基づき、当該無線装置の機能で使用可能な前記リソースを割当てる
   処理を実行することを特徴とするリソース割当方法。

Images