JP2005182484A - 通信装置およびプログラム更新方法 - Google Patents

Abstract

【課題】 容易かつ高い信頼性でプログラムの更新が可能なプログラム更新方法および通信装置を提供する。
【解決手段】 プログラム管理部１０は、制御部２０の制御プログラムを更新するとき、汎用プロトコルを用いて、更新用の制御プログラムをネットワーク４０を介して制御部２０に送る。制御部２０は、制御プログラムを、ネットワーク４０を介して受信して格納用メモリ２２に格納する。そして、制御部２０は、格納用メモリ２２から動作用メモリ２３に制御プログラムを展開して実行する。プログラム管理部１０と制御部２０の間で汎用プロトコルで定期的に通信を行うことにより、プログラム管理部１０は制御部２０の正常性を確認し、制御部２０は、プログラム管理部１０のＩＰアドレス解決およびプログラム管理部１０との間のコネクション確立を行う。
【選択図】 図１

Description

本発明は、移動通信システムに用いられる基地局装置に関し、特に、基地局装置における制御プログラムの更新に関する。

移動通信システムにおける基地局装置は、通常、ソフトウェアまたはファームウェアによって動作する。そのために制御部にはプログラムが格納されたＲＯＭが実装されている。ＲＯＭとしては、電源が供給されていない状態でもデータを保持することのできる不揮発性のフラッシュメモリが用いられるのが一般的である。基地局装置は、このプログラムを更新することにより機能を向上し、また改善することができる。

従来の基地局装置におけるプログラム更新方法として、制御部のＲＯＭを新たなプログラムを格納したものに交換する方法がある。しかし、この方法では、保守者がシステム全体を一旦停止し、手作業でＲＯＭを交換しなければならず、作業が煩雑で時間のかかるものであった。

また、従来の他のプログラム更新方法として、予め更新用のプログラムを記録しておいた端末装置から基地局装置にロードする方法があった。しかし、基地局装置の架内において制御部が現用予備の冗長構成を有する場合、端末装置から予備系制御部のメモリおよび現用系制御部のメモリに制御プログラムを書き込む必要があった。

現用系制御部と予備系制御部のそれぞれに専用の信号線から直接にデータを書き込むこととすると、通常、現用系と予備系の切り替えを行って予備系の制御部にプログラムを書き込むこととなるので、系を切り替えるためのスイッチ等のツールが必要となり構成が複雑になるという問題点があった。

それに対して従来のさらに他のプログラム更新方法として、基地局装置に、制御部とは別にプログラム管理部を設けておき、プログラム管理部から制御部にプログラムをダウンロードする方法があった（例えば、特許文献１参照）。この方法によれば、プログラム管理部に更新用プログラムを入力するだけで各制御部のプログラムを更新することができる。
特開２００２−１２３３９８号公報

プログラム管理部から制御部にプログラムをダウンロードする従来の方法では、現用系制御部および予備系制御部のどちらにもプログラムを書き込める必要がある。そのために、現用系制御部と予備系制御部を相互に接続し、通常の処理に用いられる架内共通バスを用いるのが好ましいが、そうすると架内共通バスに高負荷がかかってしまい、通常の処理に遅延が生じるというような問題点があった。

また、通常の処理とは別個の伝送路を制御部とプログラム管理部の間に設け、それを用いることも考えられるが、その場合、開発コストや機器コストを考慮すれば、一般的には比較的簡易なプロトコルでプログラムのダウンロードを行うこととなるので、データ転送の信頼性は高くなく、エラーが発生する可能性があった。

本発明の目的は、容易かつ高い信頼性でプログラムの更新が可能なプログラム更新方法および通信装置を提供することである。

上記目的を達成するために、本発明の通信装置は、制御プログラムで動作することにより所望の機能を実現する通信装置であって、
汎用プロトコルにより通信可能にネットワークに接続されており、前記制御プログラムを、前記ネットワークを介して更新可能に格納用メモリに格納しており、前記格納用メモリから動作用メモリに前記制御プログラムを展開して実行する制御部と、
前記ネットワークに接続されており、前記制御部の前記制御プログラムを更新するとき、前記汎用プロトコルを用いて、更新用の制御プログラムを前記ネットワークを介して前記制御部に送るプログラム管理部とを有している。

本発明によれば、装置内での信号の送受信には通常用いられることのない汎用プロトコルを用いて、プログラム管理部から制御部へ制御プログラムを送るので、信頼性の高い通信手段を容易に得ることができる。

また、前記ネットワークはＩＰネットワークであり、前記プログラム管理部と前記制御部の間で前記汎用プロトコルの１つであるＵＤＰで定期的に通信を行うことにより、
前記プログラム管理部は前記制御部の正常性を確認し、
前記制御部は、前記プログラム管理部のＩＰアドレス解決および前記プログラム管理部との間のコネクション確立を行うこととしてもよい。

したがって、一般にはＦＴＰのような汎用プロトコルでサーバからクライアントにファイルを転送する場合、クライアントがファイルを正常に受信できる状態か否かサーバは知ることができず、またＩＰアドレス解決もできないので、制御プログラムの更新のように確実なファイルの送達を要する部分に適用することができなかったが、本発明によれば、プログラム管理部から制御部へのＵＤＰによる定期的なヘルスチェックにより、制御部の正常性確認、およびＩＰアドレス解決を行なうことができるので、確実なファイルの送達が可能である。また、何らかの要因でネットワークに障害が発生してコネクションが一旦切断されても、ネットワークが復旧すれば、ＵＤＰによる定期的な通信により、コネクションを早期に再確立することができる。

また、前記プログラム管理部は、前記制御部との間のコネクションが確立されると、前記制御部との間で前記汎用プロトコルの１つであるＴＣＰで通信を行なうことにより、前記制御部で運用されている制御プログラムのバージョンの情報を取得し、該バージョンが、自身の管理している、前記制御部で運用されるべき制御プログラムのバージョンと一致しなければ、自身の管理しているバージョンの制御プログラムを、前記汎用的なプロトコルの１つであるＦＴＰを用いて前記制御部に送ることとしてもよい。

また、前記制御部は、前記プログラム管理部から受けた前記制御プログラムを前記格納用メモリに格納した後に、自身をリセットすることにより、前記プログラム管理部から受けた新たな前記制御プログラムで起動し直すこととしてもよい。

また、前記制御部は現用系と予備系の少なくとも２つがあり、
前記プログラム管理部は、現用系の前記制御部の前記制御プログラムを更新するとき、前記制御部に系切り替えを指示し、現用系の前記制御部が予備系となった後にリセットを指示することとしてもよい。

したがって、現用系の制御部と予備系の制御部からなる冗長構成の場合において、プログラム管理部は、現用系の制御部の制御プログラムを更新するとき、系切り替えにより現用系を予備系にしてからリセットするので、システムの運用を継続しながら制御プログラムの更新をすることができる。

また、前記プログラム管理部および前記制御部は、前記汎用プロトコルで所定の相手とのみ通信を行なうために、予め定められたポートだけを開いて相互に通信することとしてもよい。

したがって、プログラム管理部と制御部間に汎用プロトコルを用いているが、各部は相互の通信に必要なポートだけを開き、他のポートを開かないので、悪意者による侵入などの攻撃を防止することができる。

また、移動通信システムにおいて基地局装置として機能することとしてもよい。

本発明のプログラム更新方法は、制御部で用いられる制御プログラムをプログラム管理部で管理する通信装置において、前記制御部で用いられる前記制御プログラムを更新するためのプログラム更新方法であって、
前記プログラム管理部が、ネットワークを介して通信可能に接続された前記制御部に対して、汎用プロトコルで更新用の制御プログラムを送るステップと、
前記制御部が、前記プログラム管理部から前記ネットワークを介して受信した前記更新用の制御プログラムを格納用メモリに格納するステップと、
前記制御部が、前記格納用メモリから動作用メモリに前記制御プログラムを展開して実行するステップとを有している。

本発明によれば、通常、装置間の信号の送受信に用いられ、装置内での信号の送受信には用いられることのない汎用プロトコルを用いて、プログラム管理部から制御部へ制御プログラムを送るので、信頼性の高い通信手段を容易に得ることができ、また通常の処理に与える影響を低減することができる。

また、一般にはＦＴＰでサーバからクライアントにファイルを転送する場合、クライアントがファイルを正常に受信できる状態か否かサーバは知ることができず、またＩＰアドレス解決もできないので、制御プログラムの更新のように確実なファイルの送達を要する部分に適用することができなかったが、本発明によれば、プログラム管理部から制御部へのＵＤＰによる定期的なヘルスチェックにより、制御部の正常性確認、およびＩＰアドレス解決を行なうことができるので、確実なファイルの送達が可能である。また、何らかの要因でネットワークに障害が発生してコネクションが一旦切断されても、ネットワークが復旧すれば、ＵＤＰによる定期的な通信により、コネクションを早期に再確立することができる。

また、現用系の制御部と予備系の制御部からなる冗長構成の場合において、プログラム管理部は、現用系の制御部の制御プログラムを更新するとき、系切り替えにより現用系を予備系にしてからリセットするので、システムの運用を継続しながら制御プログラムの更新をすることができる。

また、プログラム管理部と制御部間に汎用プロトコルを用いているが、各部は相互の通信に必要なポートだけを開き、他のポートを開かないので、悪意者による侵入などの攻撃を防止することができる。

本発明の一実施形態について図面を参照して詳細に説明する。

図１は、本発明の一実施形態による基地局装置の構成を示すブロック図である。図１を参照すると、基地局装置１は、プログラム管理部１０および制御部２０₁〜２０_nを有している。プログラム管理部１０および制御部２０₁〜２０_nは全てスイッチングハブ３０によるネットワーク４０で接続されている。

プログラム管理部１０は制御部２０₁〜２０_nで用いられるプログラム（以下、制御プログラムと称す）を管理しており、必要に応じて新たな制御プログラムを各制御部２０₁〜２０_nにダウンロードし、更新する。プログラム管理部１０は冗長構成をとってもよいが、図１には冗長のない構成が例示されている。

制御部２０₁〜２０_nは、制御プログラムを実行することにより、基地局装置の様々な機能を実現する。制御部２０₁〜２０_nもまた冗長構成をとってもよく、全現用、現用／予備、Ｎ＋１など様々な冗長構成をとることができる。どのような冗長構成を採用するかは、システム規模、各部の故障率、装置に要求される信頼性などから決定すればよい。

ここで、全現用構成とは、全ての制御部２０₁〜２０_nが現用系として負荷分散して動作する構成である。現用／予備構成とは、制御部が１対１の対をなし、常にいずれか一方の制御部（現用系）が正常に運用されており、他方はその予備（予備系）として確保される構成である。現用系の制御部が正常な運用を続けられなくなると、予備系がそれに代わって動作する。Ｎ＋１構成とは、負荷分散して正常運用するＮ個の制御部に対して１つの制御部が予備として備えられており、Ｎ個の制御部のうちいずれかが正常運用できなくなると、予備の制御部がそれに代わって動作する構成である。

また、制御部２０₁〜２０_nは、基地局装置の有する各機能を分担することにより、全体として基地局装置の機能を実現することとしてもよい。

スイッチングハブ３０は、ＭＡＣアドレスによるスイッチング機能を有する一般的なスイッチングハブである。スイッチングハブ３０は、各ポートに接続された機器（ここでは、プログラム管理部１０および制御部２０₁〜２０_n）の物理アドレス（ HYPERLINK "http://yougo.ascii24.com/gh/06/000651.html" ＭＡＣアドレス）を学習し、通信に必要なポート同士をスイッチング機能により直結してデータをやり取りできるようにする。これにより伝送路の帯域を有効に活用し、スループットを上げることができる。

ネットワーク４０は、ＩＰｖ４またはＩＰｖ６を前提としたＩＰネットワークであり、グローバルネットワークまたはプライベートネットワークのいずれであってもよい。

プログラム管理部１０および制御部２０₁〜２０_nの各々は相互に通信するために、ネットワーク４０内でユニークにＩＰアドレスを付与されている。例えば、プライベートネットワークの場合、ＩＰアドレスは“１９２．１６８．ｘ．ｘ”（ｘは０〜２５５の任意の数）のようになる。

このＩＰアドレスは、基地局装置１におけるプログラム管理部１０および制御部２０₁〜２０_nの実装位置で固定的に決まるように基地局装置１を構成してもよい。あるいは、プログラム管理部１０および制御部２０₁〜２０_nにＤＩＰスイッチを備えておき、その切り替えにより各部のＩＰアドレスを設定する構成としてもよい。ただし、ＤＩＰスイッチでＩＰアドレスを設定する構成を採用する場合、各部のＩＰアドレスがネットワーク４０上でユニークになるように保守者が管理する必要がある。

ネットワーク４０において、プログラム管理部１０がサーバ、制御部２０₁〜２０_nがクライアントとして機能し、ＵＤＰ（ユーザデータグラムプロトコル：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）、ＴＣＰ（トランスミッションコントロールプロトコル：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）、ＦＴＰ（ファイルトランスファープロトコル：Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）などの汎用プロトコルで相互に通信可能である。

プログラム管理部１０は、ＣＰＵ１１、ＦＲＯＭ１２、プログラム動作用メモリ１３、ワークエリア１４、およびマスタプログラム格納メモリ１５を有している。

ＣＰＵ１１は、ＦＲＯＭ１２に格納されているプログラム管理部１０用のプログラム（以下、管理プログラムと称す）をプログラム動作用メモリ１３に展開し、それをワークエリア１４を利用して実行することにより、プログラム管理部１０の機能を実現する。例えば、ＣＰＵ１１は、マスタプログラム格納メモリ１５に格納されている制御プログラムを各制御部２１₁〜２１_nにダウンロードすることができる。

ＦＲＯＭ１２は、管理プログラム格納用のＲＯＭであり、一例として不揮発性のフラッシュメモリである。

プログラム動作用メモリ１３は、管理プログラムを展開するための、高速での読み書きが可能なメモリであり、一例としてＳＤＲＡＭ（Ｓｙｎｃｈｒｏｎｏｕｓ ＤＲＡＭ）である。

ワークエリア１４は、ＣＰＵ１１が管理プログラムを実行するときに演算やデータ処理などに一時的に使用する領域であり、高速での読み書きが可能なメモリで構成されている。ワークエリア１４には、管理プログラムを一時的に記録するプログラムエリアと、ＣＰＵ１１が動作するときに必要な管理情報を一時的に記録する管理エリアとがある。

マスタプログラム格納メモリ１５は、管理プログラムおよび制御プログラムのマスタを格納しておく外部記憶メモリであり、例えばＣｏｍｐａｃｔ Ｆｌａｓｈ（以下、ＣＦと称す）やＰＣカード（ＰＣＭＣＩＡカード）などである。この制御プログラムは、ＣＰＵ１１により取り出され、制御部２０₁〜２０_nにダウンロードされる。マスタプログラム格納メモリ１５に格納されているプログラムは、ネットワーク４０を介して不図示のＰｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ（ＰＣ）から書き換え可能である。

制御部２０₁〜２０_nは全て同じ構成であり、ＣＰＵ２１₁〜２１_n、ＦＲＯＭ２２₁〜２２_n、プログラム動作用メモリ２３₁〜２３_n、およびワークメモリ２４₁〜２４_nをそれぞれ有している。

ＣＰＵ２１₁は、ＦＲＯＭ２２₁に格納されている制御プログラムをプログラム動作用メモリ２３₁に展開し、それをワークエリア２４₁を利用して実行することにより、制御部２０₁の機能を実現する。例えば、ＣＰＵ２１₁は、プログラム管理部１０からのダウンロードにより取得した制御プログラムをＦＲＯＭ２２₁に格納することができる。なお、ＣＰＵ２１₂〜２１_nはＣＰＵ２１₁と同じ構成である。

ＦＲＯＭ２２₁は、制御プログラム格納するためのＲＯＭであり、一例としてフラッシュメモリである。プログラム管理部１０からダウンロードされた制御プログラムは、このＦＲＯＭ２２₁に格納される。なお、ＦＲＯＭ２２₂〜２２_nはＦＲＯＭ２２₁と同じ構成である。

プログラム動作用メモリ２３₁は、制御プログラムを展開するための、高速での読み書きが可能なメモリであり、一例としてＳＤＲＡＭである。なお、プログラム動作用メモリ２３₂〜２３_nはプログラム動作用メモリ２３₁と同じ構成である。

ワークエリア２４₁は、ＣＰＵ２１₁が制御プログラムを実行するときの演算やデータ処理などに一時的に使用する領域であり、高速での読み書きが可能なメモリで構成されている。ワークエリア２４₁には、制御プログラムを一時的に記録するプログラムエリアと、ＣＰＵ２１₁が動作するときに必要な管理情報を一時的に記録する管理エリアとがある。なお、ワークエリア２４₂〜２４_nはワークエリア２４₁と同じ構成である。

図２は、制御部のソフトウェア構成を示す図である。図２には制御部２０のソフトウェア構成を示しているが、プログラム管理部１０のソフトウェア構成もこれと同様である。図２を参照すると、ハードウェア５０の上にデバイスドライバ５１およびＩＰＬ５２が示され、その上にＲＴＯＳ５３、さらにその上に制御プログラム５４が示されている。

ＩＰＬ（Ｉｎｉｔｉａｌ Ｐｒｏｇｒａｍ Ｌｏａｄｅｒ）５２は、制御部２０に対するリセットまたは電源投入後、最初に動作するプログラムであり、ＦＲＯＭ２２内に格納されている。ＩＰＬ５２は、ハードウェア５０を初期化し、各メモリの正常性を確認した後、ＦＲＯＭ２２に格納されたＲＴＯＳ５３および制御プログラム５４をプログラム動作用メモリ２３に展開する処理を有している。

デバイスドライバ５１は、ＲＴＯＳ５３からのアクセスに従って、ネットワークデバイス、シリアルポート、ファイルシステム等のデバイス（ハードウェア５０）を制御するプログラムである。ＲＴＯＳ（Ｒｅａｌ Ｔｉｍｅ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）５３は、タスク制御、タスク間通信、ネットワーク機能、ファイルシステム機能等を提供するオペレーションシステムである。制御プログラム５４は、ＲＴＯＳ５３上で動作する複数のアプリケーションプログラムからなり、それらプログラムが独立かつ／または協働することにより、制御部２０の各機能を実現する。各プログラムの処理を実行することによりＣＰＵ２１の行う仕事の単位がタスクと呼ばれる。複数のプログラムが同時に動作し、複数のタスクが同時に存在することをマルチタスクと呼ぶ。

図３は、制御プログラムが動作を開始するまでの各ソフトウェアの動作を示すフローチャートである。なお、ここでは、制御部２０は１つのカードで構成されているものとする。プログラム管理部も図３に示す動作と同様の初期動作を行う。

図３に示すように、制御部２０に対してカードリセットが行なわれた、または制御部２０に電源が投入されたとする（ステップ１０１）。リセットまたは電源投入後、まず、ＣＰＵ２１はＩＰＬ５２を起動する（ステップ１０２）。ＩＰＬ５２はＦＲＯＭ２２上で動作する。

ＩＰＬ５２を実行することにより、ＣＰＵ２１は、ハードウェアを初期化し、各メモリの正常性を確認し、ＲＴＯＳ５３および制御プログラム５４をＦＲＯＭ２２から取り出す（ステップ１０３）。ハードウェア初期化処理としては、ＣＰＵ２１および周辺デバイス（不図示）を初期化し、ＩＰアドレスを設定する。

次に、ＩＰＬ５２の処理によりＣＰＵ２１は、ＲＴＯＳ５３および制御プログラム５４を、高速での読み書きが可能なＳＤＲＡＭからなるプログラム動作用メモリ２３上に展開する（ステップ１０４）。そして、ＩＰＬ５２の最後の処理によりＣＰＵ２１はＲＴＯＳ５３にジャンプし、通常の動作に移行する（ステップ１０５）。ＲＴＯＳ５３上では制御プログラム５４が動作する（ステップ１０６）。

以上のようにして、プログラム管理部１０の管理プログラム、制御部２０₁〜２０_nの制御プログラムが動作を開始する。動作を開始した管理プログラムおよび制御プログラムは、例えばマルチタスクで様々な処理を行う。例えば複数の制御部２０₁〜２０_nが負荷分散して動作するものとすれば、どのタスクの処理をどの制御部が受け持つかは、各制御部の負荷の状況に応じて決まる。図４は、基地局装置がマルチタスクで動作する様子を例示した図である。図４の例では、アイドルタスク６１、ヘルスチェックタスク６２、バージョン情報タスク６３、ダウンロードタスク６４、機能タスク６５〜６７が存在している。アイドルタスク６１は、最も優先度の低いタスクであり、優先度の高い他のタスクが動作中で無いときに動作する。

ヘルスチェックタスク６２、バージョン情報タスク６３、ダウンロードタスク６４は、本発明に特有の動作を行なうタスク群である。

ヘルスチェックタスク６２は、定期的なヘルスチェック動作として、プログラム管理部１０から各制御部２０₁〜２０_nのＣＰＵ２１₁〜２１_nの正常性確認、各制御部２０₁〜２０_nからプログラム管理部１０のＩＰアドレス解決、および制御部２０₁〜２０_nとプログラム管理部１０の間のコネクション確立を行う。

バージョン情報タスク６３は、ヘルスチェックタスク６２によるコネクション確立が発生すると、各制御部２０₁〜２０_nで用いられている制御プログラムのバージョン情報を確認する。

ダウンロードタスク６４は、プログラム管理部１０にてマスタとして管理されている制御プログラムのバージョンと、各制御部２０₁〜２０_nで運用されている制御プログラムのバージョンとを比較し、不一致であれば、プログラム管理部１０から制御プログラムをダウンロードする。

機能タスク６５〜６７は、無線基地局としての機能を実現するタスクであり、システムの規模に応じて複数存在する。

図５は、プログラム管理部におけるヘルスチェックタスクによる動作を示すフローチャートである。図５を参照すると、プログラム管理部１０のＣＰＵ１１は、まず、各制御部２０₁〜２０_nからヘルスチェック応答を受信するためのポートを開く（ステップ２０１）。次に、コネクションレス型プロトコルであるＵＤＰによりヘルスチェック要求メッセージＭ１を各制御部２０₁〜２０_nに送る（ステッップ２０２）。その送り先は、各制御部２０₁〜２０_nがヘルスチェック要求メッセージの受信用に開いているポートである。

制御部２０₁〜２０_nは、正常に動作していれば、ヘルスチェック要求メッセージＭ１に対してヘルスチェック応答メッセージＭ２を返送するので、プログラム管理部１０は、そのヘルスチェック応答メッセージＭ２を受ける（ステップ２０３）。一定時間内にヘルスチェック応答メッセージＭ２が返送されてくれば、その制御部２０は正常に動作していると判断できる。

そして、次に、プログラム管理部１０は、ヘルスチェック応答メッセージＭ２に示された内容で各種情報を更新し（ステップ２０４）、ステップ２０１に戻る。プログラム管理部１０は、以上の動作を例えば１秒周期で繰り返すことにより、各制御部２０₁〜２０_nの正常性を確認する。

図６は、制御部におけるヘルスチェックタスクによる動作を示すフローチャートである。図６を参照すると、制御部２０のＣＰＵ２１は、まず、プログラム管理部１０からのヘルスチェック要求メッセージＭ１を受信するためのポートを開く（ステップ３０１）。次に、制御部２０は、プログラム管理部１０からヘルスチェック要求メッセージＭ１を受信する（ステップ３０２）と、それに従って各種情報を更新する（ステップ３０３）。

次に、制御部２０は、プログラム管理部１０との間でコネクションが確立されているか否か判定する（ステップ３０４）。基地局装置１が継続して正常に動作していれば、通常、コネクションは確立されている状態である。これに対して、基地局装置１を再開した直後や、制御部２０を後実装したとき、ネットワーク４０の異常によりコネクションが切断されたときには、コネクションが確立されていないことが考えられる。ここで、後実装とは、基地局装置１の運用中に、カード交換により制御部２０が実装されたときや、単体の制御部２０にリセットがされたときの状態を指す。

コネクションが確立されていなければ、制御部２０は、プログラム管理部１０との間でコネクションを確立する（ステップ３０５）。コネクションを確立するには、制御部２０がプログラム管理部１０のＩＰアドレスを取得する、すなわちＩＰアドレス解決をする必要があるが、例えば、プログラム管理部１０から受信したヘルスチェック要求メッセージＭ１に含まれていた送信元ＩＰアドレスを用いればよい。あるいは、ヘルスチェック要求メッセージＭ１で通知される各種情報にプログラム管理部１０のＩＰアドレスを含めることとし、それを用いてもよい。コネクションが確立されれば、コネクション型プロトコルであるＴＣＰおよびＦＴＰによる通信が可能となる。

ステップ３０４の判定でコネクションが確立されていたとき、またはステップ３０５の処理によりコネクションが確立されたとき、制御部２０は、プログラム管理部１０にヘルスチェック応答メッセージＭ２を送り（ステップ３０６）、ステップ３０２の処理に戻る。

ヘルスチェック用のポート番号は、プログラム管理部１０に共通で、ヘルスチェック応答メッセージＭ２受信用に１つ定義し、制御部２０₁〜２０_nに、ヘルスチェック要求メッセージＭ１受信用に１つ定義すればよい。これより、プログラム管理部１０は、自身の送信したヘルスチェック要求メッセージＭ１を受信することが無い。また、制御部２０は、自身が送信したヘルスチェック応答メッセージＭ２、および他の制御部２０が送信したヘルスチェック応答メッセージＭ２を受信することが無い。

これに対して、コネクション型のＴＣＰやＦＴＰで通信を行う場合、プログラム管理部１０および各制御部２０₁〜２０_nが、自身にユニークに割り当てられたポートを開くことにより、各部が自身宛てのメッセージだけを確実に受信し、他宛てのメッセージを受信しないようにする。このように、ネットワーク４０内において、定義された特定番号のポートだけを開き、その他の番号のポートを閉じておくことは、他ネットワークから侵入を試みる者の攻撃に対する防衛策の１つとなり、基地局装置１の各機能部が正常に動作することを確保できる。

図７は、プログラム管理部におけるバージョン情報タスクによる動作を示すフローチャートである。図７を参照すると、プログラム管理部１０のＣＰＵ１１は、まずコネクション型プロトコルによる通信を行なうためのポートを開く（ステップ４０１）。ここで開くポートは、自身宛てのメッセージを受信するためのものである。

次に、いずれかの制御部２０との間でコネクションの確立が起こると（ステップ４０２）、プログラム管理部１０は、その制御部２０を確認する（ステップ４０３）。コネクションの確立は、図６に示したヘルスチェックタスクのステップ３０５によって起こる。

次に、プログラム管理部１０は、コネクション確立が起こった制御部２０に対して、ＴＣＰによりバージョン情報取得要求メッセージＭ３を送る（ステップ４０４）。このとき宛先として指定するポート番号は、制御部２０がコネクション型プロトコルによる通信のために開いているポートの番号である。制御部２０は、コネクション型プロトコルによる通信のためのポートを開いているので、プログラム管理部１０は、そのポート番号に宛ててＴＣＰによりバージョン情報取得要求メッセージＭ３送る。

バージョン情報取得要求メッセージＭ３を受信した制御部２０はバージョン情報取得応答メッセージＭ４を返送するので、プログラム管理部１０は、ステップ４０１にて開いておいたポートで、ＴＣＰによるバージョン情報取得応答メッセージＭ４を受信する（ステップ４０５）。バージョン情報取得応答メッセージＭ４には、その制御部２０で運用されている制御プログラムのバージョン情報が含まれている。プログラム管理部１０は、制御部２０からのバージュン情報取得応答メッセージＭ４に含まれているバージョン情報を取得する（ステップ４０６）。

次に、プログラム管理部１０は、マスタプログラム格納メモリ１５に格納されている、その制御部２０用のマスタの制御プログラムのバージョン情報を取得する（ステップ４０７）。そして、プログラム管理部１０は、ステップ４０６で取得したバージョン情報と、ステップ４０７で取得したバージョン情報とが一致しているか否か判定する（ステップ４０８）。

バージョンが一致していれば、プログラム管理部１０は、ステップ４０２に戻り、次にコネクション確立が発生するのを待つ。バージョンが一致していなければ、プログラム管理部１０は、その制御部２０に対するマスタの制御プログラムのダウンロードを実施する（ステップ４０９）。なお、実際のダウンロードの処理はダウンロードタスクにより行われる。

図８は、制御部におけるバージョン情報タスクによる動作を示すフローチャートである。図８を参照すると、制御部２０のＣＰＵ２１は、まずコネクション型プロトコルによる通信を行なうためのポートを開く（ステップ５０１）。ここで開くポートは、自身宛てのメッセージを受信するためのものである。

ここではプログラム管理部１０との間でコネクションが確立していないので、制御部２０は、図６に示したヘルスチェックタスクのステップ３０５によりコネクションを確立し、コネクション型プロトコルであるＴＣＰ、ＦＴＰのメッセージが受信されるのを待つ（ステップ５０２）。次に、制御部２０は、プログラム管理部１０からＴＣＰによるバージョン情報取得要求メッセージＭ３を受信するので（ステップ５０３）、自身で運用されている制御プログラムのバージョン情報を取得する（ステップ５０４）。

次に、制御部２０は、自身で運用されている制御プログラムのバージョン情報を含むバージョン情報取得応答メッセージＭ４をＴＣＰによりプログラム管理部１０に送る（ステップ５０５）
図９は、プログラム管理部におけるダウンロードタスクによる動作を示すフローチャートである。図９を参照すると、プログラム管理部１０のＣＰＵ１１は、まず、コネクション型プロトコルによる通信を行なうためのポートを開く（ステップ６０１）。ここで開くのは自身宛てのメッセージを受信するためのものである。

次に、図７のステップ４０９の処理によりダウンロードが発生したことを検出すると（ステップ６０２）、ダウンロードタスクが起動し、プログラム管理部１０は、ダウンロード情報転送メッセージＭ５をＴＣＰによりダウンロード対象の制御部２０に送信する（ステップ６０３）。ダウンロード情報転送メッセージＭ５には、ダウンロードする制御プログラムのファイル名、バージョン情報、マスタプログラム格納メモリ１５上での制御プログラムのディレクトリ構成などを含んでいる。

その制御部２０からダウンロード開始報告メッセージＭ６を受信すると（ステップ６０４）、プログラム管理部１０はＦＴＰで制御プログラムのダウンロードを実施する（ステップ６０５）。このとき、制御部２０は、ダウンロードした制御プログラムをワークエリア２４に一時的に格納する。

ダウンロードが終了し、制御プログラムを取得した制御部２０からダウンロード終了報告メッセージＭ７を受信すると（ステップ６０６）、制御部２０に、新たにダウンロードしたバージョンの制御プログラムへの更新を要求するための更新要求メッセージＭ８を送る（ステップ６０７）。

ダウンロードした制御プログラムをワークエリア２４からＦＲＯＭ２２に書き換えた制御部２０から更新応答メッセージＭ９を受信すると（ステップ６０８）、プログラム管理部１０は、その制御部２０を新たな制御プログラムで動作させるための処理を行う。

制御部２０が上述した現用／予備またはＮ＋１のような冗長構成を有し、かつシステムが運用中の状態では、システムの運用を継続しながら新たな制御プログラムによる動作に切り替えるために、リセットは予備系の制御部２０に対して行うことが好ましい。以下に示すステップ６０９〜６１１はそのための処理であり、全現用構成の制御部２０の場合、または運用開始前の基地局装置１の制御部２０の場合、即座にリセットを行なうのでステップ６０９〜６１１の処理は不要である。

プログラム管理部１０は、制御プログラムの運用を切り替えようとする制御部２０に系切り替えが必要か否か判定する（ステップ６０９）。対象の制御部２０が現用系であれば系切り替えが必要であり、予備系であれば不要である。

系切り替えの必要があれば、プログラム管理部１０は制御部２０に系切替要求メッセージＭ１０を送る（ステップ６１０）。系切り替えを行なった制御部２０から系切替応答メッセージＭ１１を受信すると、プログラム管理部１０は、リセット要求メッセージＭ１２を制御部２０に送る（ステップ６１２）。制御部２０からリセット応答メッセージＭ１３を受信すると、プログラム管理部１０は一連の処理を完了し、ステップ６０２に移行し（ステップ６１３）、ダウンロードの発生を待つ。

図１０は、制御部におけるダウンロードタスクによる動作を示すフローチャートである。図１０を参照すると、制御部２０のＣＰＵ２１は、まず、コネクション型プロトコルによる通信を行なうためのポートを開く（７０１）ここで開くのは自身宛てのメッセージを受信するためのものである。

次に、制御部２０は、ダウンロード情報転送メッセージＭ５をプログラム管理部１０から受信すると（ステップ７０２）、そのメッセージからダウンロードする制御プログラムに関する各種情報を取得する（ステップ７０３）。この各種情報には、ダウンロード対象の制御プログラムのファイル名、バージョン情報、マスタプログラム格納メモリ１５にある制御プログラムのディレクトリ構成などが含まれている。

そして、制御部２０は、ダウンロード開始報告メッセージＭ６をプログラム管理部１０に送り（ステップ７０４）、ＦＴＰでダウンロードを開始する（ステップ７０５）。ダウンロードされた制御プログラムは、一時的にワークエリア２４に格納される。ダウンロードが終了すると、制御部２０は、ダウンロード終了報告メッセージＭ７をプログラム管理部１０に送る（ステップ７０６）。

次に、制御部２０は、プログラム管理部１０から更新要求メッセージＭ８を受信すると（ステップ７０７）、ワークエリア２４の制御プログラムをＦＲＯＭ２２に書き換え（ステップ７０８）、更新応答メッセージＭ９をプログラム管理部１０に送る（ステップ７０９）。

システムが運用中で、制御部２０が冗長構成を有しており、かつ自身が現用系であれば、制御部２０は、プログラム管理部１０から系切替要求メッセージＭ１０を受信することとなるので（ステップ７１０）、系切り替えを行って予備系となり（ステップ７１１）、系切替応答メッセージＭ１１をプログラム管理部１０に送る（ステップ７１２）。

次に、制御部２０は、プログラム管理部１０からリセット要求メッセージＭ１２を受信するので（ステップ７１３）、リセット応答メッセージＭ１３を送信した後に自身をリセットし（ステップ７１５）、新たな制御プログラムで再起動する。

以上説明した本実施形態の基地局装置１によれば、通常では装置間の信号の送受信に用いられ、装置内の信号の送受信に通常用いられることのないＵＤＰ、ＴＣＰ、ＦＴＰのような汎用プロトコルを用いて、プログラム管理部１０から制御部２０へ制御プログラムを送るので、信頼性の高い通信手段を容易に得ることができ、また通常の処理に与える影響を低減することができる。

また、一般にはＦＴＰでサーバからクライアントにファイルを転送する場合、クライアントがファイルを正常に受信できる状態か否かサーバは知ることができず、またＩＰアドレス解決もできないので、基地局装置の制御プログラムの更新のように確実なファイルの送達を要する部分に適用することができなかったが、本実施形態によれば、プログラム管理部１０から制御部２０へのＵＤＰによる定期的なヘルスチェックにより、制御部２０の正常性確認およびＩＰアドレス解決を行なうことができるので、確実なファイルの送達が可能である。

また、何らかの要因でネットワーク４０に障害が発生してコネクションが一旦切断されても、ネットワーク４０が復旧すれば、ＵＤＰによる定期的な通信により、コネクションを早期に再確立することができる。

また、基地局装置１が現用系の制御部２０と予備系の制御部２０からなる冗長構成をとる場合において、プログラム管理部１０は、現用系の制御部２０の制御プログラムを更新するとき、系切り替えにより現用系を予備系にしてからリセットするので、システムの運用を継続しながら制御プログラムの更新をすることができる。

また、プログラム管理部１０と制御部２０間に汎用的なＵＤＰ、ＴＣＰ、ＦＴＰを用いているが、各部は相互の通信に必要なポートだけを開き、他のポートを開かないので、悪意者による侵入などの攻撃を防止することができる。

なお、本実施形態では、移動通信システムの基地局装置を例示したが、本発明はそれに限定されるものではなく、更新可能な制御プログラムで動作する制御部を有する装置であれば広く適用可能である。

本発明の一実施形態による基地局装置の構成を示すブロック図である。 制御部のソフトウェア構成を示す図である。 制御プログラムが動作を開始するまでの各ソフトウェアの動作を示すフローチャートである。 基地局装置がマルチタスクで動作する様子を例示した図である。 プログラム管理部におけるヘルスチェックタスクによる動作を示すフローチャートである。 制御部におけるヘルスチェックタスクによる動作を示すフローチャートである。 プログラム管理部におけるバージョン情報タスクによる動作を示すフローチャートである。 制御部におけるバージョン情報タスクによる動作を示すフローチャートである。 プログラム管理部におけるダウンロードタスクによる動作を示すフローチャートである。 制御部におけるダウンロードタスクによる動作を示すフローチャートである。

符号の説明

１ 基地局装置
１０ プログラム管理部
１１ ＣＰＵ
１２ ＦＲＯＭ
１３ プログラム動作用メモリ
１４ ワークエリア
１５ マスタプログラム格納メモリ
２０₁〜２０_n 制御部
２１₁〜２１_n ＣＰＵ
２２₁〜２２_n ＦＲＯＭ
２３₁〜２３_n プログラム動作用メモリ
２４₁〜２４_n ワークメモリ
３０ スイッチングハブ
４０ ネットワーク
５０ ハードウェア
５１ デバイスドライバ
５２ ＩＰＬ
５３ ＲＴＯＳ
５４ 制御プログラム
６１ アイドルタスク
６２ ヘルスチェックタスク
６３ バージョン情報タスク
６４ ダウンロードタスク
６５〜６７ 機能タスク
１０１〜１０６、２０１〜２０４、３０１〜３０６、４０１〜４０９、５０１〜５０５、６０１〜６１３、７０１〜７１５ ステップ
Ｍ１〜Ｍ１３ メッセージ

Claims (8)

1. 制御プログラムで動作することにより所望の機能を実現する通信装置であって、
   汎用プロトコルにより通信可能にネットワークに接続されており、前記制御プログラムを、前記ネットワークを介して更新可能に格納用メモリに格納しており、前記格納用メモリから動作用メモリに前記制御プログラムを展開して実行する制御部と、
   前記ネットワークに接続されており、前記制御部の前記制御プログラムを更新するとき、前記汎用プロトコルを用いて、更新用の制御プログラムを前記ネットワークを介して前記制御部に送るプログラム管理部とを有する通信装置。
2. 前記ネットワークはＩＰネットワークであり、前記プログラム管理部と前記制御部の間で前記汎用プロトコルの１つであるＵＤＰで定期的に通信を行うことにより、
   前記プログラム管理部は前記制御部の正常性を確認し、
   前記制御部は、前記プログラム管理部のＩＰアドレス解決および前記プログラム管理部との間のコネクション確立を行う、請求項１記載の通信装置。
3. 前記プログラム管理部は、前記制御部との間のコネクションが確立されると、前記制御部との間で前記汎用プロトコルの１つであるＴＣＰで通信を行なうことにより、前記制御部で運用されている制御プログラムのバージョンの情報を取得し、該バージョンが、自身の管理している、前記制御部で運用されるべき制御プログラムのバージョンと一致しなければ、自身の管理しているバージョンの制御プログラムを、前記汎用的なプロトコルの１つであるＦＴＰを用いて前記制御部に送る、請求項１または２記載の通信装置。
4. 前記制御部は、前記プログラム管理部から受けた前記制御プログラムを前記格納用メモリに格納した後に、自身をリセットすることにより、前記プログラム管理部から受けた新たな前記制御プログラムで起動し直す、請求項１〜３のいずれか１項に記載の通信装置。
5. 前記制御部は現用系と予備系の少なくとも２つがあり、
   前記プログラム管理部は、現用系の前記制御部の前記制御プログラムを更新するとき、前記制御部に系切り替えを指示し、現用系の前記制御部が予備系となった後にリセットを指示する、請求項１〜４のいずれか１項に記載の通信装置。
6. 前記プログラム管理部および前記制御部は、前記汎用プロトコルで所定の相手とのみ通信を行なうために、予め定められたポートだけを開いて相互に通信する、請求項１〜５のいずれか１項に記載の通信装置。
7. 移動通信システムにおいて基地局装置として機能する、請求項１〜６のいずれか１項に記載の通信装置。
8. 制御部で用いられる制御プログラムをプログラム管理部で管理する通信装置において、前記制御部で用いられる前記制御プログラムを更新するためのプログラム更新方法であって、
   前記プログラム管理部が、ネットワークを介して通信可能に接続された前記制御部に対して、汎用プロトコルで更新用の制御プログラムを送るステップと、
   前記制御部が、前記プログラム管理部から前記ネットワークを介して受信した前記更新用の制御プログラムを格納用メモリに格納するステップと、
   前記制御部が、前記格納用メモリから動作用メモリに前記制御プログラムを展開して実行するステップとを有するプログラム更新方法。

Images