(57)【要約】【課題】基地局装置が自身の状態変化の情報を収集および分析することにより、サービス継続を図る。【解決手段】基地局装置１００は、機能別にブロック化されたハードウェアからなる複数の機能ブロック１０５，１０７，１０９と、機能ブロック１０５，１０７，１０９が実行する制御信号およびユーザデータの入出力状態と、データの処理状態とに基づいて、機能ブロック１０５，１０７，１０９の増減または交換を判断し、判断結果を外部出力するＣＰＵ１０９とを有する。【選択図】図１−１
2014187670.tif 000002
【特許請求の範囲】
【請求項１】
機能別にブロック化されたハードウェアからなる複数の機能ブロックと、
前記機能ブロックが実行する制御信号およびユーザデータの入出力状態と、データの処理状態とに基づいて、前記機能ブロックの増減または交換を判断し、判断結果を外部出力する制御部と、
を有することを特徴とする基地局装置。
【請求項２】
前記機能ブロックは、呼処理に関連する機能部であり、
前記制御部は、呼処理のリソース情報と、前記呼処理に関連する機能部当たりの処理状況とに基づき、前記呼処理に関連する機能部の増減または交換を判断することを特徴とする請求項１に記載の基地局装置。
【請求項３】
前記機能ブロックは、呼処理に関連する機能部であり、
前記制御部は、呼処理のリソース情報と、当該制御部のハードウェアリソース使用状況とに基づき、呼処理関連の機能部あるいは当該制御部の増減または交換を判断することを特徴とする請求項１に記載の基地局装置。
【請求項４】
前記制御部は、前記機能ブロックが有する各部品毎の耐久性を閾値を用いて判定し、当該閾値に達した部品について、故障可能性があると判断することを特徴とする請求項１〜３のいずれか一つに記載の基地局装置。
【請求項５】
機能別にブロック化されたハードウェアからなる複数の機能ブロックを有する基地局装置の制御方法において、
複数の前記機能ブロックが実行する制御信号およびユーザデータの入出力状態と、データの処理状態とに基づいて、前記機能ブロックの増減または交換を判断し、判断結果を外部出力する制御工程を含むことを特徴とする基地局制御方法。
【請求項６】
基地局装置と、保守端末とを有する基地局制御システムにおいて、
前記基地局装置は、
機能別にブロック化されたハードウェアからなる複数の機能ブロックと、
前記機能ブロックが実行する制御信号およびユーザデータの入出力状態と、データの処理状態とに基づいて、前記機能ブロックの増減または交換を判断し、判断結果を前記保守端末に出力する制御部と、を有し、
前記保守端末は、前記基地局装置から出力された判断結果に基づいて、前記基地局装置に対する保守制御の実施の有無を判断し、判断結果に対応した保守制御を実施することを特徴とする基地局制御システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、自身が有する機能ブロックの増減および交換を判断する基地局装置、基地局制御方法および基地局制御システムに関する。
【背景技術】
【０００２】
基地局装置間の通信について、例えば、次世代無線移動通信システム（ＬＴＥ）では、Ｓ１  ＩｎｔｅｒｆａｃｅやＸ２  Ｉｎｔｅｒｆａｃｅと呼ばれる装置間インタフェースを確立して通信をおこなう。無線通信システムを構成する基地局装置（ｅＮＢ）は、上位装置であるＭＭＥ／Ｓｅｒｖｉｎｇ−ＧＷ装置とＩＰプロトコルを用いて接続する。また、基地局装置に対し保守制御をおこなう保守端末（以下ＯＰＥ：ＯＰｅｒａｔｉｏｎ  Ｅｑｕｉｐｍｅｎｔ）は、Ｓ１  Ｉｎｔｅｒｆａｃｅを経由して接続をおこなう。
【０００３】
基地局装置において、トラヒック量の増減等により、システムリソースが不足した場合、基地局装置はＯＰＥに対し、リソースが不足していることを通知する。しかしこの通知は、リソースが枯渇した後の通知であるため、リソース不足が発生している間は期待している呼設定ができないなど、キャリア（通信事業者）の通信業務に深刻な影響を与える。また、基地局装置において故障が発生した場合も、故障に伴い呼設定等ができなくなり、必要とされるサービスが継続できずに停止するため、キャリアの通信業務に深刻な影響を与える。
【０００４】
このため、基地局装置は、自身の持つ監視機能により、システムリソースの不足や故障発生の有無を一定の周期で監視する。そして、トラヒック情報やデータ量、装置のアラームやエラーの発生状況などをこの一定周期ごとにＯＰＥに報告して、サービス停止の問題の低減を図っている。
【０００５】
例えば、基地局装置が有する複数の無線通信モデムについて、無線通信時の受信フレームの異常フレーム数から無線通信モデム毎の障害発生を判断し、障害無線通信モデムが所定数以上になった場合に交換のメッセージを制御局を介して保守者に通知する技術が提案されている（例えば、下記特許文献１参照。）。また、故障等によりサービス継続不可のセルが発生したときに無線制御装置に対してセル設定不可を通知し、無線制御装置から基地局装置に対してサービス継続不可のセルへの呼設定をおこなわないようにする技術が提案されている（例えば、下記特許文献２参照。）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−３４７９９８号公報
【特許文献２】特開２０１０−５６９９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来技術では、上記監視機能を用いても以下（１）、（２）等の問題が生じている。
（１）基地局装置が、一定周期でＯＰＥに報告する情報は、ＡＣＫ，ＮＡＣＫ数等の簡単な情報であり、移動局（ＵＥ）の登録状況や、ＵＥのサービス状態（通話、メール等）などは報告していない。そのため、ＡＣＫ，ＮＡＣＫ数に対応する各時期別のＵＥ状態や、割り当てているサービス状況を関連付けて分析することはおこなわれていない。また、問題発生時に、報告された情報の値の過不足から問題要因を判定しようとしても、直接的な原因を判定するのみで、基地局装置に対して真に必要な制御を選択することはできない。例えば、基地局装置のＣＰＵ使用率を収集しても、ＣＰＵ使用率から高負荷であることはわかるが、高負荷が何を要因として引き起こされているのかまではわからない。
【０００８】
（２）基地局装置の故障については、故障が起こってから報告するため、報告時点ではサービスが停止している場合がある。ＯＰＥが事前予測をする場合、複数あるサービス停止要因を短い周期で監視する必要が生じる。しかし、このためには、大量のユーザ情報（ユーザ数×データ量）をネットワークに展開（伝送）することになるため、ネットワーク負荷およびＯＰＥの処理負荷を増加させ、個人情報の流出の危険性を含むため、システム全体への悪影響が懸念される。
【０００９】
一つの側面では、本発明は、基地局装置が自身の状態変化の情報を収集および分析することにより、サービス継続を図ることを目的とする。
【課題を解決するための手段】
【００１０】
一つの案では、基地局装置は、機能別にブロック化されたハードウェアからなる複数の機能ブロックと、前記機能ブロックが実行する制御信号およびユーザデータの入出力、およびデータの処理状態に基づいて、前記機能ブロックの増減または交換を判断し、判断結果を外部出力する制御部と、を有する。
【発明の効果】
【００１１】
一つの実施形態によれば、基地局装置が自身の状態変化の情報を収集および分析することにより、サービス継続を図ることができる。
【図面の簡単な説明】
【００１２】
【図１−１】図１−１は、実施の形態にかかる基地局装置の内部構成を示す図である。
【図１−２】図１−２は、基地局装置を含むシステムの全体構成を示す図である。
【図２】図２は、ベースバンド処理部の内部構成例を示す図である。
【図３】図３は、ハイウェイインタフェース部の内部構成例を示す図である。
【図４】図４は、ＣＰＵの内部構成例を示す図である。
【図５】図５は、ＯＰＥの内部構成例を示す図である。
【図６】図６は、ＯＰＥに設けられるＣＰＵの内部構成例を示す図である。
【図７】図７は、基地局装置の保守監視制御の処理例を示すシーケンス図である。
【図８】図８は、呼処理リソースを示す図表である。
【図９】図９は、セルリソースの設定情報を示す図表である。
【図１０】図１０は、ＨＷＩＦリソースを示す図表である。
【図１１】図１１は、事前の故障予測が可能な項目を示す図表である。
【図１２】図１２は、ＣＰＵがおこなう通知の制御内容の一例を示すフローチャートである。
【図１３】図１３は、ＣＰＵがおこなう通知の制御内容の他の例を示すフローチャートである。
【図１４】図１４は、基地局装置からＯＰＥに対する通知の判定処理を示すフローチャートである。
【図１５】図１５は、ＯＰＥがおこなう制御の処理内容を示すフローチャートである。
【発明を実施するための形態】
【００１３】
（実施の形態）
以下に添付図面を参照して、開示技術の好適な実施の形態を詳細に説明する。実施の形態の基地局装置は、異常状態の有無を判定し、ＯＰＥに対し判定結果を通知する。異常状態の判定には、従来ＯＰＥに通知しているアラーム等の情報の他に、基地局装置が受信したＣ−Ｐｌａｎｅによる制御情報など、通常ＯＰＥに報告しない基地局装置でのみ持つ内容をもとに判定する。また、基地局装置は、異常状態の事前予測をおこなう。
【００１４】
事前予測をおこなうには、複数のサービス停止要因を短い周期で監視する必要がある。従来機能のようにＯＰＥに情報を都度通知すると、ネットワーク負荷によりシステム全体へ悪影響を及ぼすため、基地局装置にて監視・判断する。また、基地局装置内で保持される複数のパラメータを組み合わせて、状態変化を複数の観点から判定する機能により、保守者が発生した問題等に適切に対処できる情報を通知する。そして、基地局装置は、基本的に機能部単位もしくは関係性の強い機能部のグループ毎に独立したハードウェア構成（以下、機能ブロックと称す）を有する。機能ブロックを増減設することで、機能の追加・削減が実現可能となる。また、故障時においては機能ブロックの交換により機能の復旧を可能とする。
【００１５】
（基地局装置の構成例）
図１−１は、実施の形態にかかる基地局装置の内部構成を示す図である。基地局装置１００は、アンテナ１０１、前置増幅器（ＭＨＡ：Ｍａｓｔ  Ｈｅａｄ  Ａｍｐｌｉｆｉｅｒ）１０２、電力増幅器（ＴＰＡ：Ｔｒａｎｓｍｉｔ  Ｐｏｗｅｒ  Ａｍｐｌｉｆｉｅｒ）１０３を含む。また、送受信部（ＴＲＸ：Ｔｒａｎｓｍｉｔｔｅｒ  Ｒｅｃｅｉｖｅｒ）１０４、ベースバンド処理部（ＢＢ：Ｂａｓｅ  Ｂａｎｄ  Ｕｎｉｔ）１０５を含む。また、スイッチ（ＳＷ）１０６、ハイウェイインタフェース部（ＨＷＩＦ：Ｈｉｇｈ  Ｗａｙ  Ｉｎｔｅｒｆａｃｅ）１０７、共通メモリ（ＣＭ：Ｃｏｍｍｏｎ  Ｍｅｍｏｒｙ）１０８、呼制御プロセッサ（ＣＰＵ：Ｃａｌｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０９、データベース（ＤＢ；Ｄａｔａ  Ｂａｓｅ  Ｕｎｉｔ）１１０を含む。
【００１６】
基地局装置１００は、アンテナ１０１により、移動局（ＵＥ）との間でデータの送受信をおこなう。アンテナ１０１と前置増幅器１０２と電力増幅器１０３と送受信部１０４とを含む構成は、送信機能と受信機能とを有する。また、ハイウェイインタフェース部１０７により、上位のアクセスゲートウェイとの間でデータの送受信および論理パスによるデータの送受信をおこなう。
【００１７】
呼制御プロセッサ１０９は、基地局装置１００の各部を制御する制御部として機能する。上位のアクセスゲートウェイから移動局に対して送信するデータは、ハイウェイインタフェース部１０７からベースバンド処理部１０５に転送される。そして、送受信部１０４、電力増幅器１０３、前置増幅器１０２を介してアンテナ１０１から移動局に送信される。また、移動局からのデータは、これと逆の経路でアクセスゲートウェイに送信される。
【００１８】
基地局装置１００において、ベースバンド処理部１０５とハイウェイインタフェース部１０７間では、Ｕ−Ｐｌａｎｅデータの転送をおこなう。ＣＰＵ１０９は、無線状態を判断し、ベースバンド処理部１０５に対し最適な無線状態を確保できるように指示をおこなう。また、ＣＰＵ１０９は、ハイウェイインタフェース部１０７に対し有線回線設定をおこなう。基地局装置１００は、ＣＰＵ１０９、ハイウェイインタフェース部１０７、ベースバンド処理部１０５の単位がそれぞれの機能ブロックを構成している。そして、基地局装置１００の性能向上や故障からの復旧を図る場合は、これら機能ブロック（ＣＰＵ１０９、ハイウェイインタフェース部１０７、ベースバンド処理部１０５等）の増減設や交換をおこなう。
【００１９】
そして、この実施の形態では、基地局装置１００は、ベースバンド処理部１０５により、無線側に関する情報を取得する。また、ハイウェイインタフェース部１０７では、有線側に関する情報を取得する。これらベースバンド処理部１０５とハイウェイインタフェース部１０７は、取得した情報をＣＰＵ１０９に送信する。
【００２０】
ＣＰＵ１０９は、ベースバンド処理部１０５とハイウェイインタフェース部１０７から受け取った情報を確認する。また、ＣＰＵ１０９は、自身に関しての増設・交換につながる状態が発生していないかの情報を収集可能とする。ＣＰＵ１０９は、各時点での装置状態を考慮して機能ブロックの増減設、あるいは交換の必要性を判定する。ＣＰＵ１０９は、ハイウェイインタフェース部１０７を通じて、判定結果をＯＰＥに送信する機能を持つ。
【００２１】
（システムの全体構成）
図１−２は、基地局装置を含むシステムの全体構成を示す図である。次世代無線移動通信システム（ＬＴＥ）を例に説明する。基地局装置１００は、セル内に位置する移動局（ＵＥ）１２０と無線通信をおこなう。基地局装置１００間は、Ｓ１  Ｉｎｔｅｒｆａｃｅ、Ｘ２  Ｉｎｔｅｒｆａｃｅと呼ばれる装置間インタフェースを確立して通信をおこなう。基地局装置（ｅＮＢ）１００は、上位装置であるＭＭＥ／Ｓｅｒｖｉｎｇ−ＧＷ１２１とＩＰプロトコルを用いて接続する。また、基地局装置１００に対し保守制御をおこなう保守端末（ＯＰＥ）１２２は、Ｓ１  Ｉｎｔｅｒｆａｃｅを経由して接続をおこなう。
【００２２】
図２は、ベースバンド処理部の内部構成例を示す図である。ベースバンド処理部１０５は、変復調処理部２０１、ＲＬＣ処理部２０２、ＰＤＣＰ処理部２０３、測定部２０４、保守・監視機能部２０５を含む。
【００２３】
変復調処理部２０１は、無線側の移動局（ＵＥ）１２０との間において扱うデータの変調・復調をおこなう。ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）処理部２０２は、移動局１２０との間において扱うＲＬＣメッセージの処理をおこなう。ＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）処理部２０３は、移動局１２０との間において扱うＰＤＣＰメッセージの処理をおこなう。測定部２０４は、移動局１２０との間の通信の無線状態を測定する。保守・監視機能部２０５は、ベースバンド処理部１０５内の保守・監視をおこなう。また、ＣＰＵ１０９や共通メモリ１０８の使用率の監視や、機能ブロック（例えば各ベースバンド処理部１０５）当たりの処理状況を監視する。
【００２４】
図３は、ハイウェイインタフェース部の内部構成例を示す図である。ハイウェイインタフェース部１０７は、ＩＰｓｅｃ処理部３０１、ＳＣＴＰ処理部３０２、ＰＰＰ処理部３０３、ＧＴＰ−Ｃ処理部３０４、ＧＴＰ−Ｕ処理部３０５、保守・監視機能部３０６、ＳＷ３０７を含む。
【００２５】
ＩＰレベルの暗号化機能であるＩＰｓｅｃ処理部３０１は、ＩＰｓｅｃ（ｓｅｃｕｒｉｔｙ）により、外線向けの送受信信号の暗号化・復号化をおこなう。ＳＣＴＰ（Ｓｔｒｅａｍ  Ｃｏｎｔｒｏｌ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｐｒｏｔｏｃｏｌ）処理部３０２は、外線Ｎｏｄｅ（ＭＭＥ／Ｓｅｒｖｉｎｇ−ＧＷ１２１、ｅＮＢ１００）との間で確立するＳＣＴＰプロトコルを管理する。ＰＰＰ（Ｐｏｉｎｔ  ｔｏ  Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ）処理部３０３は、ＰＰＰｏＥ（ＰＰＰ  ｏｖｅｒ  Ｅｔｈｅｒｎｅｔ（登録商標））サーバとの間で確立するＰＰＰ接続を管理する。ＰＰＰを用いて、認証管理をおこなう。ＧＴＰ−Ｃ（ＧＰＲＳ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｃｏｎｔｒｏｌ  Ｐｌａｎｅ）処理部３０４は、外線Ｎｏｄｅ（ＭＭＥ／Ｓｅｒｖｉｎｇ−ＧＷ１２１、ｅＮＢ１００）との間で確立するＧＴＰ−Ｃプロトコル（制御信号転送用）を管理する。ＧＴＰ−Ｕ（ＧＰＲＳ  Ｔｕｎｎｅｌｉｎｇ  Ｐｒｏｔｏｃｏｌ  ｆｏｒ  Ｕｓｅｒ  Ｐｌａｎｅ）処理部３０５は、外線Ｎｏｄｅ（ＭＭＥ／Ｓｅｒｖｉｎｇ−ＧＷ１２１、ｅＮＢ１００）との間で確立するＧＴＰ−Ｕプロトコル（ユーザデータ転送用）を管理する。ＳＷ３０７は、ＩＰパケットをルーティングするためのスイッチである。保守・監視機能部３０６は、ハイウェイインタフェース部１０７内の保守・監視をおこなう。また、ＣＰＵ１０９や共通メモリ１０８の使用率を監視する。
【００２６】
図４は、ＣＰＵの内部構成例を示す図である。ＣＰＵ１０９は、呼処理機能部４０１、保守・監視機能部４０２を含む。呼処理機能部４０１は、呼処理をおこなう機能部であり、セルリソースや共通チャネルリソースなどを管理し、ユーザへリソースの割り当て等をおこなう。保守・監視機能部４０２は、基地局装置１００内の保守・監視をおこなう。また、ＣＰＵ１０９や共通メモリ１０８の使用率を監視する。
【００２７】
図５は、ＯＰＥの内部構成例を示す図である。ＯＰＥ１２２は、基地局装置１００との間の通信をおこなうＨＷＩＦ５０２と、基地局装置１００を監視する監視制御部（Ｏｐｅｒａｔｉｏｎ＆Ｍａｉｎｔｅｎａｎｃｅ）５０３とを含む。監視制御部５０３は、ＣＰＵ５０４の実行処理によって機能処理する。
【００２８】
図６は、ＯＰＥに設けられるＣＰＵの内部構成例を示す図である。ＯＰＥ１２２に設けられるＣＰＵ５０４は、保守・監視機能部６０１、ｅＮＢ制御機能部６０２を含む。保守・監視機能部６０１は、基地局装置（ｅＮＢ）１００の保守・監視をおこなう。ｅＮＢ制御機能部６０２は、保守・監視機能部６０１が取得した基地局装置（ｅＮＢ）１００の状態をもとに、基地局装置１００に対してリセット等の制御を実施する。このＣＰＵ５０４は、基地局装置１００から受信したメッセージを解析し、基地局装置１００の機能ブロックに対する増減設・交換の有無を保守者へ通知する制御をおこなう。
【００２９】
（保守監視制御の処理例）
図７は、基地局装置の保守監視制御の処理例を示すシーケンス図である。以上説明した各構成による基地局装置の保守監視制御の処理例について説明する。図７中、実線はノード間のメッセージ送受、点線は保守者による基地局装置の操作（機能ブロックの増減設・交換）を示す。
【００３０】
保守監視制御の概要を説明する。基地局装置１００は、移動局（ＵＥ）１２０、ＭＭＥ−Ｓｅｒｖｉｎｇ  ＧＷ１２１との間で入出力する制御信号・ユーザデータと、自装置（基地局装置）１００の状態を確認し、機能ブロックの増減設・交換が必要か判定する（ステップＳ７００）。ＯＰＥ１２２は、基地局装置１００から受信した、基地局装置１００における機能ブロックの追加・交換の必要情報をもとに、保守者７０３に対し、作業依頼をおこなう。保守者７０３は、基地局装置１００の機能ブロック（カード状に挿抜可能なＣＰＵ１０９、ハイウェイインタフェース部１０７、ベースバンド処理部１０５）の増減設・交換を実施する（ステップＳ７１０）。この後、基地局装置１００は、ＵＥ１２０、ＭＭＥ−Ｓｅｒｖｉｎｇ  ＧＷ１２１との間で入出力する制御信号・ユーザデータと、自装置（基地局装置）１００の状態を確認し、機能ブロックの増減設・交換が不要になったことを報告する（ステップＳ７２０）。
【００３１】
以下、図７を用いて保守監視制御を詳細に説明する。
（１．基地局装置１００内の情報収集）
基地局装置１００は、機能ブロックの増設・交換が必要な状況であるか予測するために情報収集をおこなう。ベースバンド処理部１０５は、ＵＥ１２０−基地局装置１００間において送受信する、制御信号とユーザデータを解析しＣＰＵ１０９へ報告する（ステップＳ７０１）。また、ハイウェイインタフェース部１０７は、基地局装置１００−ＭＭＥ−Ｓｅｒｖｉｎｇ  ＧＷ１２１間において送受信する、制御信号とユーザデータを解析しＣＰＵ１０９へ報告する（ステップＳ７０２）。この際、以下（１）〜（２）の情報を集計する。
【００３２】
（１）呼処理において管理する無線・有線のリソース情報
呼処理をおこなう機能ブロックにおいては、無線・有線のリソース情報を管理するために、図８に示す各情報を管理する。図８は、呼処理リソースを示す図表である。各リソース情報は、１．セルリソース、２．共通チャネルリソース、３．個別チャネルリソース、４．ロジカルチャネルリソース、５．ＢＢ測定リソース、６．ＨＷＩＦリソース等がある。これらの情報は、ＵＥ７０１−基地局装置１００間ならびに基地局装置１００−ＭＭＥ−Ｓｅｒｖｉｎｇ  ＧＷ１２１間で送受信する制御信号とユーザデータから算出される。図８に示す各情報は、呼処理時に基地局装置１００の処理能力を測るために必要な情報である。基地局装置１００において上記リソースの不足が起きた場合は、呼設定ができず、サービスができない状態になる。
【００３３】
また、これら情報は、基地局装置１００において、システム帯域幅を意識して管理される。図９は、セルリソースの設定情報を示す図表である。例えば、１．セルリソースとは、具体的には、セル当たりに収容可能なＲＲＣ  Ｃｏｎｎｅｃｅｔｅｄ  ＵＥ数を表す。システム帯域幅毎に収容可能な移動局（ＵＥ）１２０の数が決まっており、セルに収容されるＵＥ数が上限以上を収容しようとした場合に、リソース不足を応答する。
【００３４】
セルリソースに関しては、セル単位での扱いを基本とするが、ＯＰＥ１２２が規定するリソースプール（ＣＰＵ管理）を導入した基地局装置１００においては、リソースプール単位での管理としてもよい。従来の基地局装置１００において、セル当たりの接続ＵＥ数は決まっているが、リソースプールの考え方を導入すると、リソースプール内で扱うことが可能な接続ＵＥ数まで、セル内に接続するＵＥ数を引き上げることができる。リソースプールの考え方を導入した基地局装置１００においては、上記パラメータに関し、リソースプール内でどれだけのリソースが使用されているのか、という情報もあわせて取得する。
【００３５】
図８の２．共通チャネルリソース、３．個別チャネルリソース、４．ロジカルチャネルリソースも同様にシステム帯域幅毎／セル毎に収容可能なリソース数が決まっており、上限以上を収容しようとした場合にリソース不足を応答する。また、図８の５．ＢＢ測定リソースは、測定項目当たりの測定可能数が決まっており、上限以上を測定しようとした場合にリソース不足を応答する。
【００３６】
図８の６．ＨＷＩＦリソースは、プロトコル当たりの接続可能数を管理する。図１０は、ＨＷＩＦリソースを示す図表である。図１０に示す各プロトコル毎にアソシエーション数・同時接続数・ＴＥ−ＩＤ数を管理し、これらの上限を超える場合にリソース不足を応答する。
【００３７】
（２）ベースバンド処理部における機能ブロック当たりの処理状況
通常、基地局装置１００において、呼処理をおこなう機能ブロックには、（１）のリソースの有無の他に、機能ブロック当たりの処理上限が存在する。ベースバンド処理部１０５においては、この処理上限に達していないか情報を収集する。例えば、無線信号を構成するサブフレーム（ｓｕｂｆｒａｍｅ）において、このｓｕｂｆｒａｍｅを持つセルにおける１ｓｕｂｆｒａｍｅに割り当てられるＵＥの多重数は、ＢＢを構成するハードウェア性能に依存し、多重数に上限を持つ。この処理上限を超えて呼設定する場合は、当該呼が破棄されるなど、サービスに影響を与える。このため基地局装置１００は、１ｓｕｂｆｒａｍｅに割り当てられるＵＥの多重数が上限を超えないように運用しなければならない。
【００３８】
また、呼処理以外の状況判定のために、以下の情報を取得する。
（３）ＣＰＵ使用率・メモリ使用率等のハードウェアリソース使用状況
ベースバンド処理部１０５、およびハイウェイインタフェース部１０７にそれぞれ設けられるＣＰＵやメモリの使用率を収集する。各機能ブロックにおいては、呼処理の他に装置監視のような制御を目的として動作しているものもある。呼処理がそれほど動いていない場合、上記の（１）によって収集した内容では十分なリソースがあると判断できるが、監視制御機能が頻繁に動いている状況の場合には、呼処理は追加・設定できない状況にあるといえる。このとき、機能ブロックの使用状況を測るためにＣＰＵ使用率やメモリ使用率を指標として用いて判断する。
【００３９】
（４）要求装置構成と実際の装置構成の不一致有無
基地局装置１００の運用時、および装置起動時に事前に設定されるプロビジョニングデータにより、運用セル数・運用帯域が規定される。プロビジョニングデータによる要求装置構成と実際の装置構成が一致していない場合、装置は要求機能を満たせない。プロビジョニングデータ上の要求に応えられない機能ブロック構成の場合は、装置に必要な機能ブロックを追加実装することで、装置性能を満たすことが可能となる。
【００４０】
（５）部品劣化等による故障可能性の判定
基地局装置１００においては、部品の劣化等による故障可能性を判定可能とするために、ベースバンド処理部１０５、ハイウェイインタフェース部１０７、ＣＰＵ１０９において、基地局装置１００の装置内温度・湿度などハードウェア故障につながる情報を収集する。機能ブロック交換の要因である、機能ブロック故障について、事前の予測が可能な場合がある。一つは部品の劣化を直接観測可能な場合であり、一つは環境面の変化を観測し、機能ブロックへの影響を間接的に観測する場合である。
【００４１】
図１１は、事前の故障予測が可能な項目を示す図表である。１．メモリカード交換については、ＤＢ１１０として用いるデータ保存用メモリカードにおける１ブロックの最大書き込み回数を監視する。２．自走周波数安定度調節については、基準クロック（ＯＣＸＯ）の経年変化を監視する。３．温度感知については、装置内蔵の温度センサーの報告値から故障可能性を監視する。４．ＥＣＣエラー感知については、ベースバンド処理部１０５に設けられるＤＳＰやＣＰＵの内部メモリのＥＣＣ機能のエラーカウントから部品劣化を監視する。
【００４２】
図７に戻り説明すると、以上（１）〜（５）のうちベースバンド処理部１０５、ハイウェイインタフェース部１０７により収集した情報はＣＰＵ１０９に報告され、ＣＰＵ１０９は装置の状態を収集する（ステップＳ７０３）。
【００４３】
（２．機能ブロックの増減設・交換の判定とＯＰＥへの通知）
次に、基地局装置１００のＣＰＵ１０９は、上記１．により収集した情報に基づいて、機能ブロックの増減設・交換が必要／不要のいずれであるかを判定し、対応方法とともにＯＰＥ１２２に通知する（ステップＳ７０４）。
【００４４】
ＣＰＵ１０９は、上記１．により収集した情報と、その組み合わせで、機能ブロックを増減設・交換するケースを判定する。実施例の制御では、上記（１），（２），（３）を組み合わせて判定する方法と、上記（４），（５）において閾値と比較し、閾値を超えた値を検出したか否かの判定により、最適な保守制御内容をＯＰＥ１２２へ通知する制御例を説明する。
【００４５】
図１２は、ＣＰＵがおこなう通知の制御内容の一例を示すフローチャートである。（１），（２），（３）の組み合わせを見る場合は、各パラメータに対応した閾値を持ち、閾値を超えるか否かを基準として判定する。以下に（１），（２），（３）の組み合わせ判定パターンを示す。
【００４６】
［パターン１］
（１）呼処理において管理する無線・有線のリソース情報と、（２）ＢＢにおける機能ブロック当たりの処理状況の組み合わせによる判定
【００４７】
Ｃａｓｅ１：ベースバンド処理部１０５における機能ブロック当たりの処理がリソース不足判定閾値を超え（ステップＳ１２０１：Ｙｅｓ）、かつ、呼処理リソースの使用割合がリソース不足判定閾値を超える場合（ステップＳ１２０２：Ｙｅｓ）。この場合、基地局装置１００においては、呼処理を要因とした高負荷現象が発生しつつあると判断する。そして、ＣＰＵ１０９は、呼処理関連の機能ブロック（ベースバンド処理部１０５の増設が必須）を増設するようにＯＰＥ１２２へ通知する（ステップＳ１２０３）。
【００４８】
Ｃａｓｅ２：ベースバンド処理部１０５における機能ブロック当たりの処理がリソース不足判定閾値を超えるが（ステップＳ１２０１：Ｙｅｓ）、呼処理リソースの使用割合がリソース不足判定閾値を超えない場合（ステップＳ１２０２：Ｎｏ）。この場合、ベースバンド処理部１０５は、輻輳状態を示すが、呼処理リソースとしては使用領域に余裕がある状態のため、ベースバンド処理部１０５が管理するセルにおいて、一時的な輻輳状態（イベントの開催や交通渋滞などにより一か所にＵＥが集中した）が発生しつつあると判断する。そして、ＣＰＵ１０９は、呼処理関連の機能ブロック（ベースバンド処理部１０５）を増設するのではなく、規制制御や各セルの周波数帯域を拡張し、収容可能ユーザ数を増加するようにＯＰＥ１２２へ通知する（ステップＳ１２０４）。
【００４９】
Ｃａｓｅ３：ベースバンド処理部１０５における機能ブロック当たりの処理がリソース不足判定閾値を超えないが（ステップＳ１２０１：Ｎｏ）、呼処理リソースの使用割合がリソース不足判定閾値を超える場合（ステップＳ１２０５：Ｙｅｓ）。この場合、基地局装置１００においては、登録ユーザ数が増加しつつあると判断する。そして、呼処理関連の機能ブロック（ベースバンド処理部１０５）を増設するか、規制制御や各セルの周波数帯域を拡張し、収容可能ユーザ数を増加させるようにＯＰＥ１２２へ通知する（ステップＳ１２０６）。
【００５０】
このほか、ベースバンド処理部１０５における機能ブロック当たりの処理がリソース不足判定閾値を超えず（ステップＳ１２０１：Ｎｏ）、また、呼処理リソースの使用割合がリソース不足判定閾値を超えない場合（ステップＳ１２０５：Ｎｏ）、ＯＰＥ１２２への通知をおこなわずに処理を終了する。
【００５１】
図１３は、ＣＰＵがおこなう通知の制御内容の他の例を示すフローチャートである。
［パターン２］
（１）呼処理において管理する無線・有線のリソース情報と、（３）ＣＰＵ使用率・メモリ使用率等のハードウェアリソース使用状況の組み合わせによる判定
【００５２】
Ｃａｓｅ１：基地局装置１００において、呼処理リソースの使用割合がリソース不足判定閾値を超え（ステップＳ１３０１：Ｙｅｓ）、かつ、ＣＰＵ１０９の使用率がリソース不足判定閾値を超える場合（ステップＳ１３０２：Ｙｅｓ）。この場合、基地局装置１００においては、呼処理を要因とした高負荷現象が発生しつつあると判断する。そして、呼処理関連の機能ブロック（ベースバンド処理部１０５）を増設するようにＯＰＥ１２２へ通知する（ステップＳ１３０３）。
【００５３】
Ｃａｓｅ２：基地局装置１００において、呼処理リソースの使用割合がリソース不足判定閾値を超えるが（ステップＳ１３０１：Ｙｅｓ）、ＣＰＵ１０９の使用率がリソース不足判定閾値を超えない場合（ステップＳ１３０２：Ｎｏ）。この場合、基地局装置１００において、登録ユーザ数は増加しつつあるが、動画情報の転送など大容量のサービスはおこなわれていない状況であり、セルリソースの追加（収容ユーザ数の追加）のみをおこなえば対応可能と判断する。そして、ＣＰＵ１０９は、呼処理関連の機能ブロック（ベースバンド処理部１０５）を増設、もしくは各セルの周波数帯域を拡張して収容可能ユーザ数を増加するようにＯＰＥ１２２へ通知する（ステップＳ１３０４）。
【００５４】
Ｃａｓｅ３：基地局装置１００において、呼処理リソースの使用割合がリソース不足判定閾値を超えないが（ステップＳ１３０１：Ｎｏ）、ＣＰＵ１０９の使用率がリソース不足判定閾値を超える場合（ステップＳ１３０５：Ｙｅｓ）。この場合、基地局装置１００においては、呼処理以外の保守・監視機能（例えば監視のためのファイル作成等）において、高負荷が発生しつつあると判断する。そして、ＣＰＵ１０９は、保守・監視機能をおこなう機能ブロック（ＣＰＵ１０９等）を増設するようにＯＰＥ１２２へ通知する（ステップＳ１３０６）。
【００５５】
このほか、呼処理リソースの使用割合がリソース不足判定閾値を超えず（ステップＳ１３０１：Ｎｏ）、また、ＣＰＵ使用率がリソース不足判定閾値を超えない場合（ステップＳ１３０５：Ｎｏ）、ＯＰＥ１２２への通知をおこなわずに処理を終了する。
【００５６】
上述したパターン１およびパターン２において使用するパラメータにおいて、呼処理リソースの使用割合やＣＰＵ使用率を判定する場合は、基地局装置１００内で持つ閾値と比較して、割合・使用率の高低を決める。ここで、機能ブロックの増減設や交換を、サービス（通信）を止めずにおこなう必要があるため、閾値は、基地局装置１００においてサービスが止まる値よりも十分低い値として決めておく。例えば、ＣＰＵ使用率の閾値については、１００％では、それ以上の処理の追加は不可能な状態であり、サービス停止を引き起こす状態であるため、閾値を５０％に設定するなど、処理に余裕のある状態の値を設定する。これら閾値の値は、実施の形態の技術を使用するキャリアのポリシーによって自由に設定可能である。
【００５７】
なお、基地局装置１００において、所定の期間、上記パターンに一度も該当しない場合は、基地局装置は処理カード増設をおこなう必要がなく、処理能力に余裕があると判断してもよい。この状態において、基地局装置１００に機能ブロックが冗長して実装されている場合は、この情報から機能ブロックを削減することが可能であると判断できる。
【００５８】
次に、上記の（４），（５）については、ＣＰＵ１０９は、閾値を用いて判定をおこない、機能ブロックの増減設・交換を判定する。
【００５９】
（４）要求装置構成と実際の装置構成が一致していない場合
ＣＰＵ１０９は、プロビジョニングデータによる要求装置構成をもとに、実際の基地局装置１００の構成が一致しているかどうかを判定する。プロビジョニングデータ上の要求に応えられない機能ブロック構成の場合は、基地局装置１００に必要な機能ブロックを増設することで、装置性能を満たすことが可能となる。そして、ＣＰＵ１０９は、ＯＰＥ１２２に対しては、必要機能ブロックを増設するように通知をおこなう。
【００６０】
（５）部品劣化により機能ブロックの交換が必要な場合
ＣＰＵ１０９は、故障可能性を判定するための閾値を持ち、図１１に示した故障可能性の各項目について、それぞれ所定の閾値を用いて判定する。ＣＰＵ１０９は、各項について閾値を超える状態となると、耐久性が劣化し、故障可能性があると判定し、ＯＰＥ１２２に対して、対象機能ブロックを交換するように通知をおこなう。
【００６１】
閾値を用いた判定内容は、具体的には、１．メモリカード交換については、データ保存用メモリカード（ＤＢ１１０）の１ブロックの最大書き込み回数が、装置の持つ閾値の回数を超えたか判定する。２．自走周波数安定度調節については、ＯＣＸＯに対し周波数安定度の調節をおこなってから、装置の持つ閾値の時間が経過したか判定する。３．温度感知については、一定の期間、基地局装置１００内の温度を監視し、装置内で閾値として指定した温度を、装置内で指定した回数分記録した場合に、故障が発生する恐れがあると判定する。４．ＥＣＣエラー感知については、ＤＳＰ、ＣＰＵの内部メモリにおける単位時間当たりのＥＣＣ訂正回数が一定値を超える状態が続く場合、部品が劣化すると判定する。
【００６２】
上記の（４），（５）においては、ＣＰＵ１０９は上限の閾値の他に下限の閾値を持ってもよい。収集した値が下限の閾値を下回ると判断される場合、該当する機能ブロックは要求される処理能力よりも、能力が上回っているといえる。機能ブロックが冗長して実装されている場合は、この情報に基づいて機能ブロックを削減することが可能である。
【００６３】
図１４は、基地局装置からＯＰＥに対する通知の判定処理を示すフローチャートである。上述した基地局装置１００のＣＰＵ１０９がおこなうＯＰＥ１２２に対する通知の処理内容を示している。はじめに、基地局装置１００では、ＣＰＵ１０９は、機能ブロックの状態を監視している（ステップＳ１４０１）。次に、ＣＰＵ１０９は、保守者・ＯＰＥ１２２に状態を通知する必要があるか判断する（ステップＳ１４０２）。
【００６４】
保守者・ＯＰＥ１２２に状態を通知する必要がある場合（ステップＳ１４０２：Ｙｅｓ）、ＣＰＵ１０９は、通知要因が（１）呼設定関連、（２）装置構成関連、（３）部品劣化、のいずれに基づくものであるか判断する（ステップＳ１４０３）。（１）呼設定関連である場合（ステップＳ１４０３：（１））、図１２，図１３の処理にてパラメータの組み合わせを判定し、判定結果より機能ブロックの増設が必要と判定し（ステップＳ１４０４）、ステップＳ１４０７に移行する。保守者・ＯＰＥ１２２に状態を通知する必要がない場合（ステップＳ１４０２：Ｎｏ）、処理を終了する。
【００６５】
また、（２）装置構成関連である場合（ステップＳ１４０３：（２））、要求装置構成に必要な機能ブロックの追加実装が必要と判定し（ステップＳ１４０５）、ステップＳ１４０７に移行する。また、（３）部品劣化により機能ブロック交換が必要な場合（ステップＳ１４０３：（３））、故障可能性のある機能ブロックの交換が必要と判定し（ステップＳ１４０６）、ステップＳ１４０７に移行する。
【００６６】
ステップＳ１４０７では、基地局装置１００にて機能ブロックの増減設・交換をＯＰＥ１２２へ通知し（ステップＳ１４０７）、処理を終了する。
【００６７】
（３．ＯＰＥの処理）
図７に戻り、基地局装置１００から情報を取得したＯＰＥ１２２は、基地局装置１００からの機能ブロック増減設・交換の必要の有無を確認する（ステップＳ７０５）。機能ブロック増減設・交換の必要がある場合は、保守者７０３にその旨を依頼する（ステップＳ７０６）。
【００６８】
図１５は、ＯＰＥがおこなう制御の処理内容を示すフローチャートである。はじめに、ＯＰＥ１２２は、基地局装置１００から基地局装置１００の状態を取得する（ステップＳ１５０１）。次に、ＯＰＥ１２２は、所得した基地局装置１００の状態に基づいて、基地局装置１００に対して保守制御を実施する必要があるか判断する（ステップＳ１５０２）。基地局装置１００に対して保守制御を実施する必要がある場合には（ステップＳ１５０２：Ｙｅｓ）、制御の内容を決定する（ステップＳ１５０３）。一方、基地局装置１００に対して保守制御を実施する必要がなければ（ステップＳ１５０２：Ｎｏ）、処理を終了する。
【００６９】
ステップＳ１５０３では、制御の内容を（１）リセット、（２）閉塞、（３）アラーム（ＡＬＭ）から選択する（ステップＳ１５０３）。（１）リセット（ステップＳ１５０３：（１））の場合は、基地局装置１００からの通知内容が異常値である場合等に、対象の機能ブロックをリセットし初期化する（ステップＳ１５０４）。（２）閉塞（ステップＳ１５０３：（２））の場合は、基地局装置１００からの通知内容に基づき対象の機能ブロックを閉塞状態にして、機能を一時停止させる（ステップＳ１５０５）。この後、該当する機能ブロックの増設や交換等をおこなう。（３）アラーム（ステップＳ１５０３：（３））の場合は、基地局装置１００からの通知内容に基づき対象の機能ブロックをアラーム（ＡＬＭ）と判断し、故障扱いとする（ステップＳ１５０６）。この後、該当する機能ブロックの交換等をおこなう。
【００７０】
（４．保守者による機能ブロックの増減設・交換作業）
図７に戻り、保守者７０３は、ＯＰＥ１２２からの通知内容をもとに基地局装置１００における機能ブロックの増減設・交換をおこなう（ステップＳ７０７）。
【００７１】
（５．機能ブロックの増減設・交換後の監視）
基地局装置１００は、再度機能ブロックの増設・交換が必要な状況でないか判断するためにステップＳ７００同様の情報収集をおこなう（ステップＳ７２０）。保守者により増減設・交換された機能ブロックは、ＣＰＵ１０９が持つ閾値を超えずに動作する。これにより、機能ブロックが増減設・交換された後の所定の期間、基地局装置１００は、ＯＰＥ１２２に対し、機能ブロックの増減設・交換が不要であることを通知する。この後、所定の期間が経過し基地局装置１００の状態が変化し、機能ブロックの増設・交換が必要な状況になれば、基地局装置１００は、再度ＯＰＥ１２２に対し、機能ブロックの増減設・交換を通知する。
【００７２】
以上説明した実施の形態によれば、基地局装置は、入出力する制御信号やユーザデータと自身の状態を監視し、機能ブロックの増減設・交換が必要か否かを判断し、機能ブロックの増減設・交換の必要性をＯＰＥや保守者に通知する。これにより、リソース不足や装置故障発生前に、機能ブロックの増減設・交換が可能になる。したがって、基地局装置の運用停止を防ぐことができるようになる。
【００７３】
また、基地局装置は、入出力する制御信号やユーザデータと自身の状態を監視し、機能ブロックの増減設・交換が必要か否かを自身が判断するため、ＯＰＥ−基地局装置間のネットワークに対するデータ送出に伴うネットワーク負荷を与えることがない。また、所定の項目について、事前の故障予測をおこなうことにより、故障を事前回避でき、サービスへの影響を抑制できるようになる。
【００７４】
なお、本実施の形態で説明した基地局制御にかかるプログラムは、あらかじめ用意されたプログラムをコンピュータで実行することにより実現することができる。また、このプログラムは、半導体メモリ、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、このプログラムは、インターネット等のネットワークを介して配布してもよい。
【００７５】
上述した各実施の形態に関し、さらに以下の付記を開示する。
【００７６】
（付記１）機能別にブロック化されたハードウェアからなる複数の機能ブロックと、
前記機能ブロックが実行する制御信号およびユーザデータの入出力状態と、データの処理状態とに基づいて、前記機能ブロックの増減または交換を判断し、判断結果を外部出力する制御部と、
を有することを特徴とする基地局装置。
【００７７】
（付記２）前記機能ブロックは、呼処理に関連する機能部であり、
前記制御部は、呼処理のリソース情報と、前記呼処理に関連する機能部当たりの処理状況とに基づき、前記呼処理に関連する機能部の増減または交換を判断することを特徴とする付記１に記載の基地局装置。
【００７８】
（付記３）前記機能ブロックは、呼処理に関連する機能部であり、
前記制御部は、呼処理のリソース情報と、当該制御部のハードウェアリソース使用状況とに基づき、呼処理関連の機能部あるいは当該制御部の増減または交換を判断することを特徴とする付記１に記載の基地局装置。
【００７９】
（付記４）前記制御部は、前記機能ブロックが有する各部品毎の耐久性を閾値を用いて判定し、当該閾値に達した部品について、故障可能性があると判断することを特徴とする付記１〜３のいずれか一つに記載の基地局装置。
【００８０】
（付記５）前記制御部は、前記呼処理のリソース情報として、セルリソース、共通チャネルリソース、個別チャネルリソース、ロジカルチャネルリソース、ベースバンド測定リソース、ハイウェイインタフェースリソースの一つあるいは複数の組合せを取得することを特徴とする付記２または３に記載の基地局装置。
【００８１】
（付記６）機能別にブロック化されたハードウェアからなる複数の機能ブロックを有する基地局装置の制御方法において、
複数の前記機能ブロックが実行する制御信号およびユーザデータの入出力状態と、データの処理状態とに基づいて、前記機能ブロックの増減または交換を判断し、判断結果を外部出力する制御工程を含むことを特徴とする基地局制御方法。
【００８２】
（付記７）基地局装置と、保守端末とを有する基地局制御システムにおいて、
前記基地局装置は、
機能別にブロック化されたハードウェアからなる複数の機能ブロックと、
前記機能ブロックが実行する制御信号およびユーザデータの入出力状態と、データの処理状態とに基づいて、前記機能ブロックの増減または交換を判断し、判断結果を前記保守端末に出力する制御部と、を有し、
前記保守端末は、前記基地局装置から出力された判断結果に基づいて、前記基地局装置に対する保守制御の実施の有無を判断し、判断結果に対応した保守制御を実施することを特徴とする基地局制御システム。
【００８３】
（付記８）前記保守端末は、
前記基地局装置から出力された判断結果に基づいて、前記基地局装置の該当する機能ブロックに対するリセット、閉塞、あるいは故障アラーム、のいずれかの保守制御を実施することを特徴とする付記７に記載の基地局制御システム。
【符号の説明】
【００８４】
１００  基地局装置
１０１  アンテナ
１０２  前置増幅器
１０３  電力増幅器
１０４  送受信部
１０５  ベースバンド処理部
１０７  ハイウェイインタフェース部
１０８  共通メモリ
１０９  呼制御プロセッサ
１１０  データベース
１２０  移動局
【図１−１】
2014187670.tif 000003
【図１−２】
2014187670.tif 000004
【図２】
2014187670.tif 000005
【図３】
2014187670.tif 000006
【図４】
2014187670.tif 000007
【図５】
2014187670.tif 000008
【図６】
2014187670.tif 000009
【図７】
2014187670.tif 000010
【図８】
2014187670.tif 000011
【図９】
2014187670.tif 000012
【図１０】
2014187670.tif 000013
【図１１】
2014187670.tif 000014
【図１２】
2014187670.tif 000015
【図１３】
2014187670.tif 000016
【図１４】
2014187670.tif 000017
【図１５】
2014187670.tif 000018