JP4298716B2 - 通信制御システム - Google Patents

Description

この発明は、受動光分岐素子を用いて１つの親局インタフェースに対し複数の子局を収容するEPON(Ethernet(登録商標) Passive Optical Network)型等の通信制御システムに関する。

ＰＯＮ（Passive Optical Network）は、光分岐素子によって１つの親局に複数の子局を接続し、光ファイバを共有する伝送システムであり、インターネット接続サービスに代表される広域のアクセスネットワーク構築手段として適用されている。このため、システムは広い地域に展開され、子局の導入数は極めて大量となる。また、子局は宅内一般機器と同様にユーザによって電源投入されるため、常時親局と接続されている訳ではない。係る状況の中で、子局には通信サービスを実現するソフトウェア、ＦＰＧＡ（Field Programmable Gate Array）などの要更新ファイルが搭載されているために、遠隔からのバージョンアップによる改修や機能追加の要求がある。

このような要求に対する基本的な技術として、親局−子局間の通信パスを使用し、親局制御のもとで子局へファイル転送によるダウンロードを実施する方法があるが、このままではダウンロードを実施する際に子局が接続されていることが前提となり、接続されていない子局にはダウンロードされない問題を運用操作で回避する必要がある。

この問題を解決する手段として、例えば特許文献１に示されるように、遠隔装置の起動による通信路確立後にダウンロード要否を判定し実行する方法があるが、この方法をＰＯＮシステムに当てはめた際には親局上に子局の要更新ファイルを更新するためのダウンロード用ファイルを保持する必要が生じる。

特開平８-６７７０号公報

しかしながら、大量設置されるアクセスシステムの親局上に子局へのダウンロード用ファイルの保持を行うとシステム全体が高コスト構造となるため、子局の機種、メーカなどが複数化し扱うファイル数が増えるほど対応困難となる。加えて、親局が子局のバージョンを検出しダウンロード要否を判断するために、子局内のファイル構成等を予めシステムで取り決めておく必要があり、将来のサービス拡充に向けた子局の機能多様化に制限を生じさせる可能性がある。

なお、一般に行われている別の例として、ユーザにファイルサーバの所在を公開し、ユーザ自身の操作によってアクセスさせ、ダウンロード用ファイルのダウンロードと宅内装置への書き込み操作を実施させる方法がある。この方法は装置の機種多様化に対応できる利点があるが、ダウンロードの実施がユーザ任せであり徹底される保証がない。このため、子局装置が保守責任範囲に含まれる有線通信事業者の多くにとって、運用上適切な方法でなく、また主信号が送受信される転送網上にファイルサーバを設置する必要があることからセキュリティ確保や一斉アクセス時の負荷軽減対策などに運用コストがかかる問題があった。

この発明は上記問題点を解決するためになされたもので、子局のユーザに負担をかけることなく、子局に必要なソフトウェアモジュールのバージョンアップ等の要構成ファイルの更新処理を確実に行える通信制御システムを比較的安価に得ることを目的とする。

この発明に係る請求項１記載の通信制御システムは、親局と、親局と相互接続される複数の子局とを備え、前記複数の子局はそれぞれ通信サービスを実現するソフトウェアであって更新する必要のある要更新ファイルを有し、前記親局に接続され、前記複数の子局それぞれの前記要更新ファイルの更新の必要性に関する情報を規定した構成定義ファイルと、前記要更新ファイルを更新するためのダウンロード用ファイルとを保存するファイルサーバをさらに備え、前記複数の子局はそれぞれ、前記親局を、前記子局，前記ファイルサーバ間のゲートウェイとして機能させて、前記構成定義ファイルをダウンロードし、当該構成定義ファイルの内容に従い、更新の必要性の有無に応じて前記ダウンロード用ファイルをダウンロードするダウンロード処理を、起動時に自動的に行い、前記複数の子局と親局は光分岐素子を用いてＰＯＮ（Passive Optical Network）型通信され、前記親局，前記子局間における前記ダウンロード処理は保守用の論理チャネルを利用して実行され、前記ファイルサーバは、主信号網から分離された監視網上において前記親局と接続される。

この発明のおける請求項１記載の通信制御システムは、複数の子局はそれぞれ上記したダウンロード処理を起動時に自動的に行うため、複数の子局それぞれのユーザに負担をかけることなく、確実にダウンロード用ファイルのダウンロードを行うことができる効果を奏する。

さらに、ファイルサーバが複数の子局全てについての構成定義ファイル及びダウンロード用ファイルを格納しているため、親局はこれらのファイルを完全に保持する必要がなくなる分、システム全体として比較的安価に実現できる効果を奏する。

＜実施の形態＞
（概要）
図１はこの発明の実施の形態である通信制御システムの構成を示すブロック図である。
同図に示すように、実施の形態は、主信号の送受信を行う転送網２０（バックボーン３０に接続される）と分離された監視網（監視専用網）１０に接続してファイルサーバ１００を設置し、親局２００を、ファイルサーバ１００と子局３００（３００Ａ〜３００Ｃ）間のゲートウェイとして機能させることによって、ファイルサーバ１００，子局３００間に安全な通信パス（図中、破線で示す）を形成する。そして、子局３００は、起動し親局２００と接続されると自らダウンロード要否の判定と、ファイルサーバ１００からのダウンロードを行うように構成したものである。

子局３００と親局２００との間は標準化された保守用の論理チャネルを利用してダウンロード手順を実行するが、その際、保守チャネル上にインターネットで使用される標準化されたファイル転送プロトコルをカプセル化する方式とし、親局２００は保守チャネル上のプロトコルをインタネットプロトコルへ乗せかえる簡易な機能によりゲートウェイを実現する。

また、子局３００によるダウンロード要否判定に先立ち、まず構成定義ファイル１２０をサーバからダウンロードするようにし、対象となる子局３００の機種情報や必要ファイル数を当該構成定義ファイル１２０に記述するようにしている。したがって、子局３００が構成定義ファイル１２０の記述内容に従って必要に応じてダウンロードを実行することによって、将来新規投入する子局３００を対象とする場合でも、運用システムの変更なしにダウンロードが可能となる。

運用席１５０は監視網１０を介してファイルサーバ１００及び親局２００に接続されており、ファイルサーバ１００に必要とするファイルを格納したり、子局を開通させるために親局へ子局の認証情報を登録したり、パラメータ設定を行う等の親局の設定処理を行ったりする。また、運用席１５０から、子局３００のダウンロードの進行状態を読み出して確認する等の処理が行える。

なお、図１では説明の都合上、１つの親局２００のみ示しているが、実際の通信制御システムにおいては、複数の親局２００に対して１つのファイルサーバ１００が対応している。

（ゲートウェイ機能）
図２は親局２００のゲートウェイ機能による保守信号のインタネットプロトコルへの乗せ替え内容を模式的に示す説明図である。同図に示すように、子局３００からファイルサーバ１００にデータ送信を行う場合、子局３００は保守信号Ｓ３００を親局２００に送信する。保守信号Ｓ３００はヘッダー部Ｓ３００ｈ、データパケット部Ｓ３００ｐ及びトレイラ部Ｓ３００ｔより構成される。

図３は、親局２００，子局３００間で送受信される保守信号Ｓ３００の内部構造の詳細を示す説明図である。同図に示すように、ヘッダー部Ｓ３００ｈとしてアドレス部ｄ１１、フレーム種別部ｄ１２、拡張識別子部ｄ１３、長さ部ｄ１４及びプロトコル種別部ｄ１５が記述され、データパケット部Ｓ３００ｐとしてプロトコルデータ部ｄ１６が記述され、トレイラ部Ｓ３００ｔとしてＣＲＣ−３２部ｄ１７が記述される。

ヘッダー部Ｓ３００ｈにおいて、アドレス部ｄ１１は宛先及び送信元のアドレスが規定され、フレーム種別部ｄ１２には保守信号を示す情報を規定され、拡張識別子部ｄ１３には非標準データを示す情報が規定される。また、長さ部ｄ１４にはプロトコル種別部ｄ１５及びプロトコルデータ部ｄ１６におけるビット長Ｌ１５が規定され、プロトコル種別部部ｄ１５にはＳＮＭＰ（Simple Network Management Protocol），ＴＦＴＰ（Trivial File Transfer Protocol）等のプロトコル種別を示す識別子が規定される。なお、長さ部ｄ１４及びプロトコル種別部部ｄ１５は標準で規定されたヘッダーではなく独自のものであり、パケット全体をカプセル化するために、その中身と長さを前に付与している。

データパケット部Ｓ３００ｐにおいて、プロトコルデータ部ｄ１６にはＳＮＭＰ，ＴＦＴＰ等のパケットデータが格納される。また、トレイラ部Ｓ３００ｔのＣＲＣ−３２部ｄ１７はエラーチェック用の情報が規定される。

親局２００は、保守信号Ｓ３００を受け、保守信号Ｓ３００内のデータパケット部Ｓ３００ｐのみを取り出し、取り出したデータパケット部Ｓ３００ｐをそのままデータパケット部Ｓ２００ｐとし、ＩＰアドレス等のヘッダー情報を規定したヘッダー部Ｓ２００ｈとトレイラ部Ｓ２００ｔとをそれぞれ付加して得られるインタネットプロトコルパケットＳ２００を得る。そして、親局２００は、インタネットプロトコルパケットＳ２００を監視網１０を介してファイルサーバ１００に送信する。

なお、図２及び図３では子局３００からファイルサーバ１００方向のデータ送信を示したが、同様にして、ファイルサーバ１００から子局３００への送信時においても、ファイルサーバ１００から送信されるインタネットプロトコルパケットＳ２００は、親局２００によって、インタネットプロトコルパケットＳ２００内のデータパケット部Ｓ２００ｐをそのままデータパケット部Ｓ３００ｐとし、保守信号用のアドレス情報等のヘッダー部Ｓ３００ｈ及びトレイラ部Ｓ３００ｔがそれぞれ付加された保守信号Ｓ３００にカプセル化された後、子局３００に送信される。

このように、子局３００から送信される保守信号Ｓ３００内のデータパケット部Ｓ３００ｐがそのままの形でインタネットプロトコルパケットＳ２００内のデータパケット部Ｓ２００ｐとしてにカプセル化され、ファイルサーバ１００から送信されるインタネットプロトコルパケットＳ２００内のデータパケット部Ｓ２００ｐがそのままデータパケット部Ｓ３００ｐとして保守信号Ｓ３００内にカプセル化されることにより、親局２００をゲートウェイとしたファイルサーバ１００，子局３００間のデータ送受信が可能となる。なお、上述したカプセル化は親局２００内のゲートウェイ制御部２１２によって行われる。

（詳細構成）
以下、実施の形態の通信制御システムについての詳細構成について説明する。図１に示すように、ファイルサーバ１００は、子局３００へのダウンロード用の種々のプログラムファイル１１０,１１１,１１２を格納している。プログラムファイル１１０〜１１２は、例えば子局３００上で実行されるべき更新すべきソフトウェアモジュールが記述されたダウンロード用ファイルであり、構成定義ファイル１２０とともにファイルサーバ１００上に格納されている。通信制御システム上で最適なサービスを受けるには子局３００は使用機種に合致した最新のソフトウェアモジュールで動作させる必要がある。

子局３００は、光分岐素子５０を介して親局２００と接続された際に保守チャネルを使用して、ファイルサーバ１００からまず構成定義ファイル１２０をダウンロードすることができる。子局３００は構成定義ファイル１２０を特定する情報として例えばファイル名を予め知っており、ファイル名を特定することによってファイルサーバ１００に存在する構成定義ファイル１２０の転送を要求することができる。

図４は構成定義ファイル１２０の内容の一例を示す説明図である。同図に示すように、構成定義ファイル１２０はファイルサーバ１００のホームディクレクトリ上においてファイル名"kokyoku.inf"として格納されている。構成定義ファイル１２０には、子局を特定するための機種コード情報、子局３００側で可動するソフトウェアモジュールのバージョンを示すバージョン情報、ダウンロード用ファイル（更新用ソフトウェアモジュール等）の所在を示すファイル情報が格納されている。さらに、機種によっては子局３００で必要とする各種パラメータのバージョンを規定したパラメータ（バージョン）情報、パラメータ更新用のダウンロード用ファイル（Ｐファイル）の所在を示すＰファイル情報等が格納されている。

子局３００は構成定義ファイル１２０の内容に従ってファイルサーバ１００上に存在するファイルの種類、バージョンを認識し、対象ファイルを特定する情報(例えばファイル名)も取り出し、必要に応じてプログラムファイル１１０〜１１２を選択してダウンロードする。例えば、子局３００Ａの機種種別が"kokyoku1"で特定されている場合、構成定義ファイル１２０中で規定されたバージョン情報"F/W.099"と、自身の現在のソフトウェアモジュールの稼働（保存）バージョンとを比較することにより、プログラムファイルのダウンロードの必要性の有無を判断することができる。

このように、子局３００は構成定義ファイル１２０内容を検証することにより、自身の稼働中のソフトウェアモジュールの更新の必要性の有無を認識することができる。すなわち、構成定義ファイル１２０は各子局３００におけるソフトウェアモジュールの更新の必要性に関する情報を規定している。

なお、構成定義ファイル１２０で記述されている用語は、子局３００側で解釈できる用語であれば何でも良く（いわゆる予約語）、図４で示された例に限らない。子局３００と、構成定義ファイル１２０を規定する側との間で取り決められていればよいので、番号などでも構わない。

そして、子局３００は、ダウンロードの必要性が生じたときは、構成定義ファイル１２０から得た"kokyoku1"のファイル情報である"m/mod/software99.bin"に基づき、ホームディクレクトリ下のサブディレクトリ"m"下のサブディレクトリ"mod"下に存在するプログラムファイル１１１("software99.bin")を選択してダウンロードすることができる。

図５は子局と親局の詳細構成例を示すブロック図である。同図に示すように、親局２００は、子局３００から光分岐素子５０を介して回線インタフェース部２０１にて受信した信号のうち、標準化された回線制御信号を終端し、保守信号Ｓ３００を保守信号終端部２０３へ送り、それ以外を主信号として転送網インタフェース部２０２へ送る構成を呈している。なお、本明細書中において、「終端」とは、当該信号（上記例では、回線制御信号）をこの部分で取り出して処理し、他へは転送しないことを意味する。

監視制御部２１０は、インタネットプロトコルパケットＳ２００を受ける監視網インタフェース部２１１を介して監視網１０側のファイルサーバ１００とインタネットプロトコルを用いて接続される。

ゲートウェイ制御部２１２は、監視網インタフェース部２１１と保守信号終端部２０３との間を中継し、保守信号Ｓ３００及びインタネットプロトコルＳ２００それぞれ内に格納されたファイル転送プロトコル等のデータパケット部（Ｓ３００ｐ，Ｓ２００ｐ）に対し上述したカプセル化処理を施して、互いのインタフェース部２１１，２０１に転送する。さらに、ゲートウェイ制御部２１２は、監視網インタフェース部２１１，保守信号終端部２０３間の中継と同時にデータパケット部Ｓ２００ｐ内のファイル転送プロトコルからファイルデータをコピーし、キャッシュ部２２０へ格納する機能も備えている。

したがって、ゲートウェイ制御部２１２は、子局３００からダウンロード要求されたファイルが既にキャッシュ部２２０内に存在する場合は、中継先を監視網インタフェース部２１１でなくファイル転送プロトコル終端部２１３とし、子局３００によるファイル転送プロトコル終端部２１３を介したキャッシュ部２２０からのダウンロードを実施可能にする。

子局３００は、回線インタフェース部３０１を介して受信した信号のうち、標準化された回線制御信号を終端し、保守信号Ｓ３００を保守信号終端部３０３へ送り、それ以外を主信号としてユーザインタフェース部３０２へ送ることができる。なお、ユーザインタフェース部３０２は宅内機器６０に接続される。

制御部３１０は、構成定義ファイル保持部３１１、ファイル転送プロトコル終端部３１５、ＳＮＭＰエージエント３３０、保存ファイル情報３３１及び稼働情報３３２を内部に有している。

制御部３１０は、親局２００を経由してダウンロード開始指示を受信した後に、ファイル転送プロトコル終端部３１５を介して、親局２００またはファイルサーバ１００から構成定義ファイル１２０をダウンロードし、構成定義ファイル保持部３１１に構成定義ファイル１２０の内容を格納する。

次に、制御部３１０は、保持した構成定義ファイル１２０内に記述されているファイルの機種情報、バージョン情報を精査し、ファイル保存部３２０に格納されている保存ファイル３２１,あるいは３２２（ここでは、「保存ファイル３２１」に格納されているとする。）のバージョン情報を保存ファイル情報３３１から認識することができる。

さらに、制御部３１０は、保存ファイル３２１に保存されているファイルのバージョン情報に加えて、現在稼働中のバージョンを稼働情報３３２として管理している。したがって、制御部３１０は、例えばダウンロードが実施された直後において、ファイル保存部３２０に保存されたファイルのバージョンと稼動バージョンとが異なった状態になっていることも判定することができる。

図６は制御部３１０の制御下で実行するダウンロード要否判断及び実行処理のアルゴリズムを示すフローチャートである。以下、同図を参照して、その実施内容を説明する。なお、図６で示す処理は、構成定義ファイル保持部３１１内に構成定義ファイル１２０内容が保持された状態後の処理を意味する。

まず、ステップＳ１において、構成定義ファイル１２０内に自身の機種コードと一致する記述の有無をチェックし、存在した場合（Yes）にステップＳ２に移行する。一方、ステップＳ１で存在しない場合（No）はダウンロード用ファイルのダウンロードの必要なしと判断して処理を終了する。

ステップＳ２において、構成定義ファイル１２０内で規定されたバージョン情報と稼働情報３３２で規定される現在稼働状態の稼働バージョン情報とを比較し、一致しない（No）場合はステップＳ３に移行する。一方、ステップＳ２で一致する場合（Yes）はダウンロードの必要なしと判断して処理を終了する。

ステップＳ３において、構成定義ファイル１２０内で規定されたバージョン情報と保存ファイル情報３３１で規定されるファイル保存部３２０内に保存されているファイルのバージョン情報（保存バージョン情報）とを比較し、一致しない（No）場合はダウンロードの必要性があるとしてステップＳ４に移行する。一方、ステップＳ３で一致する場合（Yes）はすでにファイル保存部３２０内にソフトウェアモジュールを更新するためのダウンロード用ファイルが保持されていると判断し、ステップＳ６で再起動してダウンロード用ファイルに記述された最新のソフトウェアモジュールを実行させて、ソフトウェアモジュールの更新処理を終了する。

一方、ステップＳ３でＮｏと判定された場合に実行されるステップＳ４において、ファイルサーバ１００より、親局２００を介して対象となるプログラムファイル１１０〜１１２のいずれか（以降、プログラムファイル１１０と仮定）をダウンロードする。この際、プログラムファイル１１０が親局２００のキャッシュ部２２０に既に存在する場合は、ファイルサーバ１００に代わって親局２００のキャッシュ部２２０よりプログラムファイル１１０がダウンロードされる。

ステップＳ５において、ダウンロードされたプログラムファイル１１０をファイル保存部３２０内の保存ファイル３２１あるいは３２２内に不揮発記憶させる。

その後、ステップＳ６で再起動して、ファイル保存部３２０に保持されたプログラムファイル１１０（ダウンロード用ファイル）を実行させることにより、更新処理を終了する。

このように、子局３００で動作するソフトウェアモジュールの稼働バージョン及び保存バージョンそれぞれの比較結果に基づき、構成定義ファイル１２０内で記述された機種が一致し、かつ保存バージョンが異なる場合に、制御部３１０は必要するプログラムファイル１１０を親局２００またはファイルサーバ１００からダウンロードし、ファイル保存部３２０内に不揮発記憶する。

なお、子局３００の制御部３１０はＳＮＭＰエージエント３３０を有し、ＳＮＭＰエージエント３３０から子局３００内に搭載されているソフトウェアモジュールのバージョン情報、およびダウンロードの進行状況や結果を認識して、ファイル保存部３２０に保存したファイルのバージョン情報を保存ファイル情報３３１とし、現在稼働中のソフトウェアモジュールのバージョン情報を稼働情報３３２としてそれぞれ保持することができる。

また、親局２００のＳＮＭＰマネージャ２３０はＳＮＭＰプロトコルを用いて、ＳＮＭＰエージェント３３０から上記バージョン情報の収集をし、収集された情報は監視制御部２１０で管理される。

上記収集された情報は、親局２００のダウンロード制御に用いるとともに、監視制御部２１０に集積する。したがって、運用席１５０は監視制御部２１０から上記収集された情報（ダウンロードの進行状況と子局３００バージョン情報等）を認識することができる。

なお、上述した親局２００のＳＮＭＰマネージャ２３０と子局３００のＳＮＭＰエージエント３３０とのデータ送受信は、図３で示した保守信号Ｓ３００において、データパケット部Ｓ３００ｐ中のプロトコルデータ部ｄ１６に記述されたデータによって行われる。

図７は親局２００をゲートウェイとしたファイルサーバ１００，子局３００間のダウンロード状況を示す説明図である。以下、同図を参照して、子局３００によるダウンロード処理を説明する。

まず、ステップＳＴ１において、電源投入等の起動処理を実行することにより、子局３００が光分岐素子５０を介して親局２００に接続される回線接続処理が行われる。以降、子局３００，親局２００間のデータ送受信は子局３００の回線インタフェース部３０１と親局２００の回線インタフェース部２０１との間で光分岐素子５０を介して行われる。一方、親局２００とファイルサーバ１００との間の送受信は親局２００の監視制御部２１０とファイルサーバ１００との間で監視網１０を介して行われる。

次に、ステップＳＴ２において、ダウンロード事前確認処理が行われる。図７に示すように、運用席１５０から親局２００の監視制御部２１０及び回線インタフェース部２０１にダウンロード有効を指示する情報が予め伝達されている場合、親局２００の回線インタフェース部２０１から子局３００にダウンロード開始指示が与えられる。この開始指示を子局３００が受けると、受信した旨を示す応答を親局２００に返信することにより、ダウンロード事前確認処理が完了する。なお、上記ダウンロード開始指示には、ダウンロード後に子局３００の再起動を許可するか否かなどの付帯指示が含まれる。また、ダウンロード有効の指示は、運用席１５０によって予め行われるため、運用席１５０側で計画的にダウンロード期間を設定することができる。

その後、ステップＳＴ３において、構成定義ファイル取得処理が実行される。まず、子局３００が構成定義ファイル１２０の受信要求を親局２００に送信すると、通常、親局２００はファイルサーバ１００に対して構成定義ファイル１２０の受信要求を行い、ファイルサーバ１００より構成定義ファイル１２０を受信し、受信した構成定義ファイル１２０を子局３００にデータ送信するとともに、キャッシュ部２２０内に一時的に保存する。なお、既にキャッシュ部２２０内に構成定義ファイル１２０が保持されている場合はファイルサーバ１００にアクセスすることなく、親局２００のキャッシュ部２２０から直接、構成定義ファイル１２０が子局３００にデータ送信される。そして、子局３００より、データ受信した旨を示す応答を親局２００に返信することにより、構成定義ファイル取得処理が完了する。

次に、ステップＳＴ４において、ダウンロード要否判定処理を実行する。すなわち、子局３００は構成定義ファイル１２０の内容を認識して、ソフトウェアモジュールを更新（バージョンアップ）すべく新たにダウンロード用ファイル（プログラムファイル１１０等）をダウンロードする必要性があるか否かを判定する。その詳細は、図６で示したフローチャートのステップＳ１〜Ｓ３の処理に相当する。ダウンロード要否判定処理においてダウンロード必要性有りと判断した場合は、図７に示すように、ステップＳＴ５に移行する。

ステップＳＴ５において、ダウンロード実行処理が行われる。まず、子局３００が対象となるプログラムファイル（仮にプログラムファイル１１０とする）の受信要求を親局２００に送信すると、通常、親局２００はファイルサーバ１００に対しプログラムファイル１１０の受信要求を行い、ファイルサーバ１００よりプログラムファイル１１０を受信し、受信したプログラムファイル１１０を子局３００にデータ送信するとともに、キャッシュ部２２０内に一時的に保存する。なお、既にキャッシュ部２２０内にプログラムファイル１１０が保持されている場合はファイルサーバ１００にアクセスすることなく、親局２００のキャッシュ部２２０から直接、プログラムファイル１１０が子局３００にデータ送信される。そして、子局３００より、データ受信した旨を示す応答を親局２００に返信することにより、ダウンロード実行処理が完了する。

次に、ステップＳＴ６において、ファイル保存処理（図６のステップＳ５の処理に相当）が行われた後、ステップＳＴ７において、再起動処理（図６のステップＳ６の処理に相当）が行われることにより、子局３００はファイル保存部３２０に保存した最新のプログラムファイル１１０が稼働されることにより更新（バージョンアップ）処理が完了する。なお、ステップＳＴ３及びＳＴ５で、ファイルサーバ１００，監視制御部２１０間あるいは回線インタフェース部２０１，子局３００間での送受信が繰り返されているのは、データを複数回に分けて送受信していることを意味する。

上述したように、本実施の形態の通信制御システムは、子局３００がダウンロード処理を起動時に自動的に行うため、子局３００のユーザに負担をかけることなく、確実に構成定義ファイル１２０及びプログラムファイル１１０〜１１２のダウンロード処理を行うことができる効果を奏する。

さらに、ファイルサーバ１００が複数の子局３００全てについての構成定義ファイル１２０及びプログラムファイル１１０〜１１２を格納しているため、親局２００はこれらのファイルを完全に保持する必要がなくなる分、システム全体として比較的安価に実現できる効果を奏する。

また、上記ステップＳＴ３の構成定義ファイル取得処理及びステップＳＴ５のダウンロード実行処理は、前述したように、親局２００，子局３００間においては、保守用の論理チャネルを利用した保守信号Ｓ３００によって行われ、親局２００，ファイルサーバ１００間においては、主信号が送受信される転送網２０から隔離された監視網１０を介したインタネットプロトコルパケットＳ２００によって行われるため、運用における秘匿性・安全性を確保することができる効果を奏する。

さらに、親局２００はキャッシュ部２２０を有してるため、上記ステップＳＴ３の構成定義ファイル取得処理及びステップＳＴ５のダウンロード実行処理において、キャッシュ部２２０にダウンロード用ファイル（構成定義ファイル１２０あるいはプログラムファイル１１０〜１１２）が既に存在する場合は、ファイルサーバ１００にアクセスすることなくキャッシュ部２２０からダウンロード用ファイルを子局３００に送信することができる。その結果、大量に設置された子局の一斉ダウンロード処理に伴うファイルサーバ１００，親局２００間の監視網１０の負荷を分散することができるため、広域に設ける関係上比較的帯域の狭い（伝送速度が遅い）監視網１０を用いても、監視網１０上でのダウンロードが支障無く可能となる効果を奏する。

なお、上記ダウンロード処理は、運用の中で計画的に実行すべく、シーケンスの開始に先立ち運用席１５０からダウンロード有効を指示するように構成した例である。この指示が子局３００まで届いてから子局３００の制御が開始されるため、例えばダウンロード後に子局３００の再起動を許可するか否かなどの付帯指示をステップＳＴ２のダウンロード開始指示の際等に付け加えることができる。

また、本実施の形態では、要更新ファイルをソフトウェアモジュールとし、ダウンロード用ファイルを上記ソフトウェアモジュールを更新用のプログラムファイルを例に挙げて示したが、図４で示したパラメータやＦＰＧＡコード等、子局３００が更新を必要とするファイルであれば要更新ファイルに該当する。例えば、ＦＰＧＡコードを要更新ファイルとした場合、ダウンロード用ファイルは新たなＦＰＧＡコードとなる。

この発明の実施の形態である通信制御システムの構成を示すブロック図である。 親局のゲートウェイ機能による保守信号のインタネットプロトコルへの乗せ替え内容を模式的に示す説明図である。 親局，子局間で送受信される保守信号の内部構造の詳細を説明する説明図である。 構成定義ファイルの内容の一例を示す説明図である。 子局と親局の詳細構成例を示すブロック図である。 子局の制御部の制御下で実行するダウンロード要否判断及び実行処理のアルゴリズムを示すフローチャートである。 親局をゲートウェイとしたファイルサーバ，子局間のダウンロード状況を示す説明図である。

符号の説明

１０ 監視網、２０ 転送網、５０ 光分岐素子、１００ ファイルサーバ、１１０〜１１２ プログラムファイル、１２０ 構成定義ファイル、２００ 親局、２０１，３０１ 回線インタフェース部、２０３，３０３ 保守信号終端部、２１１ 監視網インタフェース部、２１２ ゲートウェイ制御部、３００，３００Ａ〜３００Ｃ 子局、３１０ 制御部、３１１ 構成定義ファイル保持部、３２０ ファイル保存部、３２１，３２２ 保存ファイル、３３１ 保存ファイル情報、３３２ 稼働情報。

Claims (3)

1. 親局と、
   親局と相互接続される複数の子局とを備え、前記複数の子局はそれぞれ通信サービスを実現するソフトウェアであって更新する必要のある要更新ファイルを有し、
   前記親局に接続され、前記複数の子局それぞれの前記要更新ファイルの更新の必要性に関する情報を規定した構成定義ファイルと、前記要更新ファイルを更新するためのダウンロード用ファイルとを保存するファイルサーバをさらに備え、
   前記複数の子局はそれぞれ、前記親局を、前記子局，前記ファイルサーバ間のゲートウェイとして機能させて、前記構成定義ファイルをダウンロードし、当該構成定義ファイルの内容に従い、更新の必要性の有無に応じて前記ダウンロード用ファイルをダウンロードするダウンロード処理を、起動時に自動的に行い、
   前記複数の子局と親局は光分岐素子を用いてＰＯＮ（Passive Optical Network）型通信され、前記親局，前記子局間における前記ダウンロード処理は保守用の論理チャネルを利用して実行され、
   前記ファイルサーバは、主信号網から分離された監視網上において前記親局と接続される、
   通信制御システム。
2. 請求項１記載の通信制御システムであって、
   前記親局は前記ダウンロード処理時に、前記ファイルサーバより受信した前記構成定義ファイル及び前記ダウンロード用ファイルを一時的に保存するキャッシュ部を有し、前記キャッシュ部に前記子局のダウンロード対象のファイルが存在する場合は、前記ファイルサーバに代わって前記キャッシュ部から前記ダウンロード対象のファイルを前記子局に送信する、
   通信制御システム。
3. 請求項１あるいは請求項２記載の通信制御システムであって、
   前記要更新ファイルは、前記子局上で実行されるソフトウェアモジュールを含み、
   前記ダウンロード用ファイルは、前記プログラムの更新用のプログラムファイルを含む、
   通信制御システム。

Images