以下、添付図面に従って本発明の実施の形態を詳細に説明する。なお、全図を通して同一符号は同一又は相当部分を示すものとする。
図2は実施の形態による移動通信システムの構成を示す図で、図において、100は公衆網(PSTN)、101は移動体交換局(MSC)、102は基地局制御装置(BSC)、103は基地局(BTS)、50はソフトウェア供給装置、60は保守端末、10は移動局装置(無線端末装置,携帯電話機等)である。
ソフトウェア供給装置50において、51はソフトウェア供給装置50の主制御(呼制御,各種バージョンの制御ソフトウェアの蓄積管理並びにダウンロードの判定及びダウンロード制御等)を行うCPU、52はCPU51が実行する各種アプリケーションプログラムやデータを記憶する主メモリ(MEM)、53は各種バージョンの制御ソフトウェア及びそのバージョン情報等を蓄積格納しているディスク装置(DSK)、54は通信制御部(CIF)、55は保守端末60に接続するシリアルインタフェース部(SIF)、56はCPU51の共通バスである。
移動局装置10において、11はTDMA方式等による通信制御部、12は送信部、13は送/受分波スイッチ(T/R)、14はアンテナ、15は受信部、16は周波数シンセサイザ(SYN)、17は音声の符号データとPCMデータ間の符号変換を行うコーデック(CDC)、18はPCMデータと音声信号間の変換を行うベースバンド処理部(BBP)、19はマイク(MIC)、20はレシーバ(RCV)、21はブザー(BZ)等の発音体、22は移動局装置10の主制御(呼制御,キー操作制御、制御ソフトウェアのダウンロード/更新制御等)を行うCPU、23はCPU22が実行する各種アプリケーションプログラムやデータを記憶するRAM,マスクROM,フラッシュROM等からなる主メモリ(MEM)、24は液晶表示部やダイヤルキー等を備えるコンソール部(CSL),25は電源である充電可能なバッテリー部(BT)、26はその充電用端子、27はCPU22の共通バスである。
ソフトウェア供給装置50は、網側に接続され(又は移動体交換局101等に組み込まれ)、移動局装置10についての各種バージョンの制御(運用)ソフトウェアを蓄積・管理すると共に、移動局装置10からのバージョン比較要求に応じて更新の必要性有/無を判定し、更新が必要な場合は基地局103を介して対応する制御ソフトウェア(更新用ソフトウェア)を移動局装置10にダウンロードする。なお、ソフトウェア供給装置50に対する新たな制御ソフトウェアの供給は保守端末60等から行うことができる。
移動局装置10に電源投入すると、CPU22は通信制御部11を介して最寄りの基地局103に位置登録し、待ち受け状態となる。この状態で、もし着信があると、CPU22はBBP18に呼出音(リンギング)のサウンドデータSDを送出し、これによりブザー21が鳴動する。またユーザはこの待ち受け状態から発呼することが可能であり、ユーザがダイヤル発信操作をすると、CPU22は所定の発呼処理に従って基地局103に発信し、通話相手に接続される。なお、この様なCPU22の呼制御(及び後述のソフトウェアダウンロード制御)はCPU22が通信制御部11との間で制御データCDをやり取りすることにより行われる。
更に、通話中におけるマイク19からの音声信号はBBP18,CDC17,通信制御部11を介して送話データTDに変換(フォーマット)され、更に送信部12,アンテナ14を介して基地局103に送信される。また基地局103からの受信信号は受信部15で受話データRDに変換され、更に通信制御部11、CDC17,BBP18を介して音声信号に変換され、レシーバ20より出力される。
また、CPU22はこの待ち受け状態を利用して自らソフトウェア供給装置50に発呼し、自己の制御ソフトウェアが最新バージョンか否かを問い合わせることが可能であり、最新バージョンでない場合は、ソフトウェア供給装置50より最新バージョンにステップアップするための制御ソフトウェア(更新用ソフトウェア)がダウンロードされ、こうして自己の制御ソフトウェアを常に最新バージョンに維持できる。以下、詳細に説明する。
図3〜図5は実施の形態による移動局装置のメモリマップを説明する図(1)〜(3)で、図3(A)は主メモリ23の一部構成(メモリ空間)を示している。このメモリ空間はマスクROM32と、フラッシュROM(EEPROMでも良い)33と、バッテリバックアップRAM34とから構成され、ここに各メモリの性質に応じたソフトウェアやデータが格納される。
ところで、一般にソフトウェアの格納アドレスはCPU22の構造やOSの制約により予め決まっており、これに従って各ソフトウェアモジュールの先頭アドレスは固定となっている。携帯電話機を始めとする現状の小型装置にはこの様な制限を持つものが多く、図3(A)もその例に従っている。なお、このCPU22はアドレスを32ビットで表現するものとする。
更新ソフトウェア41は、図8の更新処理と図9の更新判定処理とからなり、この部分は更新(変更)する必要が無いのでマスクROM32に格納される。更新ソフトウェア41は後述の制御ソフトウェア43を上書きして更新する機能を備え、制御ソフトウェア43が停止している時にのみ動作する。
バージョン管理領域42は、制御ソフトウェアのバージョン管理情報を書き換え可能で、かつ移動局装置10の電源断時にも内容を保持する必要があるため、フラッシュROM33上に設けられる。ところで、この様なフラッシュROM33の内容を書き換える場合には、書き込みに先立って消去を行う必要がある。データの書き込みはバイト単位で行えるが、消去はセクタ単位となる。従って、バージョン管理領域42や後述の制御ソフトウェアの書き換えは、物理的にはセクタ単位で行うことになる。この例のフラッシュROM33では、消去したセクタは全ビット=1になり、書き込みの際は対象ビットを1から0に変更する。
また、フラッシュROM33では、データの書き換えを簡単に行うために、できるだけセクタの先頭となるアドレスにバージョン管理領域42や後述の制御ソフトウェアの各モジュールを配置する。本実施の形態では1セクタが64KBのフラッシュROM33を使用しており、各セクタの先頭アドレスは100000H(Hはヘキサデシマル表示を表す)から10000H(64KB)の間隔となっている。
移動局装置10の制御(運用)ソフトウェア43は、更新可能でかつ不揮発性の要求から同じくフラッシュROM33に格納される。移動局装置10の大きさや価格を抑えるためには、フラッシュROM33のメモリ容量は小さいことが望ましい。そこで、本実施の形態ではフラッシュROM33の格納領域を上書き(セクタ毎の消去、再書込)する方法によって制御ソフトウェア43の記憶領域の再利用を行い、ソフトウェア更新に伴なうフ
ラッシュROM容量の増加を最小限に抑えている。
一例の制御ソフトウェア43はソフトウェアモジュール(部品)A〜Dにより構成されている。モジュールAは例えば通信サービスとは関係無い様な固定的な処理からなり、更新の対象外となっている。モジュールBは主に装置の通信制御処理(呼処理等)に係り、通信サービスの変更/追加/改善等に関係があるため、更新対象となっている。またモジュールC,Dは主にキー操作処理やその他のサービス機能に係り、これも更新対象となっている。なお、この様な制御ソフトウェアを更新する場合には、一般にプログラムサイズが変動するため、各モジュールA〜Dの先頭アドレスは、それを見込んだ空き領域を含めて、予め制御ソフトウェアの設計時に決定されている。
新しい制御ソフトウェアのダウンロードは現行の制御ソフトウェアの実行下で行われる。そのために必要な無線通信機能等の実現には、実際上相互に関連して動作する上記いずれのモジュールA〜Dも欠かすことができない。この様な状況の下で、制御ソフトウェア43の更新は、基本的にはモジュール単位で行われる。更にはダウンロードに伴う通信トラヒックの低減を図るため、モジュール内の部分的な更新も可能となっている。なお、制御ソフトウェアをモジュール単位で更新する場合の一般的な留意事項であるが、新しいモジュールBは、モジュールA及び新旧いずれのモジュールC,Dと組み合わせた場合においても、正しく動作するように作成される。
ダウンロードバッファ44は、ソフトウェア供給装置50よりダウンロードされた新しい制御ソフトウェア(更新用ソフトウェア)を一時的に格納する。ダウンロードバッファ44の内容により現行の制御ソフトウェア43を上書きしている途中で、万一、ダウンロードバッファ44の内容が失われると、現行の制御ソフトウェアは二度と動作できなくなる。また現行の制御ソフトウェア43が動作できなくなると、その機能を利用して行われるダウンロードのし直しも不可能となってしまう。そこで、ダウンロードバッファ44にもフラッシュROM33を使用する。
ダウンロードバッファ44のサイズは、装置のメモリ容量を増大させないために制御ソフトウェア43のサイズよりもできるだけ小さくなるように選択される。但し、本実施の形態では最大のモジュールBがフルに書き換えられる場合を考慮してモジュールBよりも大きいサイズに選ばれる。その結果、図示の例ではダウンロードバッファ44のサイズは1MB(制御ソフトウェアの1/2)であるが、モジュール数を増やし、各モジュールのサイズを小さくすると、ダウンロードバッファ44のサイズも更に小さくできる。従って、ソフトウェア更新の実現に伴なうフラッシュROM33の容量増加を抑えることが可能であり、移動局装置10の小型低価格化を図ることができる。
最新のバージョン管理情報がバージョン管理領域42のどのアドレスに記録されているかの情報は、アクセスの利便性から、これをバッテリバックアップRAM34のワークエリア45に記憶しておく。なお、バックアップ電池の残量が不足して記憶が失われた場合は、後述の処理によりバージョン管理領域42から最新のバージョン管理情報を直接に探すことが可能である。
図3(B)はモジュールBの記憶態様を示している。モジュールBの記憶エリア0.9MBは、モジュールBの本体(プログラム部分)0.8MBと空きエリア0.1MBとからなっている。なお、更新後のモジュールBの本体が記憶エリアの最大サイズ0.9MBを超える様な場合は、後続のモジュールC等を同時に更新して調整可能である。
図4はバージョン管理領域42の記憶フォーマットを示している。フラッシュROM33上でバージョン管理情報を能率良く管理するために、セクタを2つ設けている。バージ
ョン管理情報は1つ当たり16バイトを使用し、更新の度に新たなバージョン管理情報を後の領域(16バイト)に追記していく。こうして一方のセクタを使い切った時は、他方のセクタの先頭から使い始める。この時、他方のセクタが過去に使われたことがある場合は、当該セクタへのデータ書き込みに先立って、当該セクタを消去する。
バージョン番号は32ビットの整数で管理し、数値の大きい方が新しいものとする。但し、本実施の形態ではフラッシュROM33を消去すると全ビット=1になることから、これと区別するためにバージョン番号=0FFFFFFFFHは無効とする。32ビットからなるバージョン番号は40億回以上の更新を識別可能であり、フラッシュROM33の書き換え可能回数(10万回程度)を含む移動局装置10の寿命を考えた場合には、無限とみなせる。
バージョン番号は、モジュールの組み合わせにより生じる不具合を防ぐため、モジュールではなく、基本的には制御ソフトウェア全体のバージョンを表す。但し、後述の如くある制御ソフトウェアがモジュール毎に段階的に更新される場合があり、この場合は各モジュールの更新毎に制御ソフトウェア全体としてのバージョン番号が更新される。
上記バージョン番号の他にも、セクタ内の部分的な更新が失敗した様な場合にやり直しができるように、更新対象である制御ソフトウェア格納領域43内のセクタアドレスと、セクタ内の部分的な更新用ソフトウェアを保存している後述のセクタバッファ44aのアドレスとを記録する。なお、セクタ内の部分的な更新を行わない場合は、セクタアドレスとセクタバッファアドレスとを同じ値にする。セクタ内の部分的な更新を行う場合は、これらが同じ値になることはない。
更に、「バージョン書込完了フラグ」は上記バージョン管理情報のバージョン管理領域42への書き込みが完了したか否かを表し、また「セクタバッファ書込完了フラグ」は後述セクタバッファ44aへの部分的な更新用ソフトウェアの書き込みが完了したか否かを表し、そして、「更新完了フラグ」は制御ソフトウェアにおける更新対象部分の更新(書き換え)が完了したか否かを表す。なお、これらの詳細は後述の説明により一層明らかとなる。
図5はダウンロードバッファ44の記憶フォーマットを示している。図において、「モジュール数」は更新するモジュール数を表し、例えば単一のモジュールBを更新する場合は「1」、複数のモジュールC,Dを同時に更新する場合は「2」となる。「モジュール本体」には更新用ソフトウェアのモジュール本体が格納され、少なくとも最大モジュールBに対応する更新用ソフトウェアを格納できる大きさを備える。「アドレス」はモジュール本体の制御ソフトウェア格納領域43における格納先アドレス、「サイズ」はモジュール本体のサイズを夫々表す。「チェックサム」には先頭のモジュール数からチェックサム領域の直前までの各データを1バイトずつ順に加算した結果を格納する。但し、桁あふれは無視する。上記「モジュール本体」以外の各情報はダウンロード時における転送ブロックのフォーマット時に付加されている。転送ブロックのデータフォーマットについては図10に従って後述する。
なお、ダウンロードバッファ44には単一のモジュールにつき複数の更新用ソフトウェア(各更新単位)をパッキングすることが可能である。この場合の各更新用ソフトウェアは「アドレス1」,「サイズ1」,「更新ソフトウェア本体1」,「アドレス2」,「サイズ2」,「更新ソフトウェア本体2」,…の如く順にパッキングされる。この場合のCPU22は「アドレス1」,「アドレス2」等の情報に基づき、制御ソフトウェア格納領域43内の飛び飛びの領域に散在するソフトウェアを個々に更新する。これにより広範囲にわたる更新を少ない情報量で能率良く行える。
「セクタバッファ」44aは、1セクタ(64KB)分のバッファ領域からなり、制御ソフトウェア(モジュール)内のごく一部を更新する場合等において、セクタ内の部分的な更新を安全に行うために使用される。こうして、一例のダウンロードバッファ44のサイズは、モジュール本体(896KB)+管理領域(10B)+セクタバッファ(64KB)からなっており、これをセクタ単位の64KBで切り上げて1MBとしている。
図6,図7は実施の形態によるダウンロード処理のフローチャート(1),(2)である。図6において、制御ソフトウェア43の更新が必要か否かの判定は移動局装置10がソフトウェア供給装置50に現用の制御ソフトウェアのバージョン番号を知らせたことを契機としてソフトウェア供給装置50により行われる。この場合に、制御ソフトウェア43の更新は移動局装置10の電源状態が良好で、かつ装置10が使用されていない(待ち受け状態)時に行うのが望ましい。そこで、本実施の形態では移動局装置10が外部の充電装置(不図示)に接続され、かつ所定時間(例えば1時間)以上使用されていなかった時に問い合わせを開始する。なお、移動局装置10が充電装置に接続されていることはバッテリー部25により検出され、CPU22はこれをバス27を介して検知できる。また移動局装置10が所定時間以上使用されていないことは、この区間に着信の受付操作等を含むいかなるキー操作も行われていないことによって検出される。
上記条件を満足すると、図示しないが、CPU22は、制御ソフトウェア43に従いまずソフトウェア供給装置50に自動的に発呼する。この発呼は網側が提供する通信サービスに対する特番発呼でも良いし、又はソフトウェア供給装置50を着信先とする様な通常の発呼でも良い。そして、呼が接続されるとステップS41の処理に入力する。ステップS41ではCPU22は「処理種別=1:バージョン比較要求」,「バージョン番号」をソフトウェア供給装置50に送信する。「バージョン番号」は自己の現用の制御ソフトウェア43のバージョン番号である。
ソフトウェア供給装置50は、バージョン比較要求を受け付けたことにより、ステップJ1では受信したバージョン番号が当該移動局装置10について移動通信システムが管理するところの最新バージョンか否かを判別する。最新でない場合は、ステップJ2で最新バージョン又は最新バージョンにステップアップするための適切な更新用ソフトウェア(モジュール)を選択する。ステップJ3では当該更新用ソフトウェアの転送ブロック数を取得する。また上記ステップJ1の判別で最新バージョンの場合はステップJ4で転送ブロック数=0を取得する。ステップJ5では転送ブロック数=N(但し、N≠0の場合は新たな制御ソフトウェアのバージョン番号を含む)を移動局装置10に返信する。
CPU22は、転送ブロック数を受信したことにより、ステップS42では転送ブロック数>0か否かを判別する。転送ブロック数=0の場合は、移動局装置10が最新バージョンで運用中であることを表すため、ソフトウェア供給装置50との間の呼を切断してステップS43に進み、移動局装置10としての通常の運用処理を実行する。また転送ブロック数>0の場合は、図7のステップS45に進み、以下のダウンロード処理を開始する。
図7において、ダウンロード処理は、移動局装置10が転送ブロックを要求し、ソフトウェア供給装置50がその応答として転送ブロックを送信するという手順で行われる。即ち、ステップS45ではCPU22は「処理種別=2:転送要求」,「バージョン番号」,「転送ブロック番号」を送信する。この転送要求には、特定の転送ブロックを簡単かつ一意に特定できるように、転送要求に係る制御ソフトウェアのバージョン番号と転送ブロック番号とが含まれる。転送ブロックには1ずつ増加する一連の番号が付与されており、これを転送ブロック番号と呼ぶ。各バージョン(モジュール)における先頭の転送ブロッ
クの転送ブロック番号を1とする。
ソフトウェア供給装置50は、転送要求を受け付けたことにより、ステップJ7で対応する転送ブロックを移動局装置10に返送する。その際には、ソフトウェア供給装置50は転送要求に含まれるバージョン番号及び転送ブロック番号の情報をキーとして、管理テーブルから対応する転送ブロックを読み出す等の単純な処理により、速やかに転送ブロックを選択できる。
図10に実施の形態による転送ブロックのイメージ図を示す。例えばモジュールBを更新する場合は、ソフトウェア供給装置50は予め更新対象の必要な1又は2以上の更新用ソフトウェアを収集して「モジュール情報」の欄に展開する。この展開は上記ダウンロードバッファ44で述べた各フォーマット情報に対応して、更新用ソフトウェア毎に「アドレス」,「サイズ」,「更新用ソフトウェア本体」の各情報をパッキングする。更に、その先頭には「モジュール数=1」の情報を付加し、またその最後尾には「モジュール数」と「モジュール情報」とについて求めた「チェックサム」の情報を付加する。そして、これらを各所要サイズの転送ブロックにブロック分割し、これらを転送ブロック番号との対応にメモリ(DSK53等)に格納しておく。転送ブロックのサイズは、無線通信速度が9600bpsの場合は、1ブロックの転送時間が30秒以下となる様に32KB以下に選択される。
なお、ダウンロードバッファ44に対して複数のモジュールC,D等を一挙に転送することが可能であり、この場合は「モジュール数=2等」とし、かつ「モジュール情報」の欄にはモジュールC,Dについての各更新用ソフトウェア毎に「アドレス」,「サイズ」,「更新用ソフトウェア本体」の各情報をパッキングする。
図7に戻り、CPU22は、転送ブロックを受信したことにより、ステップS46では該転送ブロックをダウンロードバッファ44に蓄積する。ステップS47では転送ブロック番号に+1する。ステップS48では転送ブロック番号>Nか否かを判別し、NOの場合はステップS49でタイマ(例えば3分)をスタートさせる。ステップS50では該タイマによる割り込みを許可とし、ステップS51では現用の制御ソフトウェア43内の通常の運用処理に制御を移す。その際には、ソフトウェア供給装置50との間の呼は一旦切断(又は保留に)され、移動局装置10は待ち受け状態に戻る。この間に、移動局装置10は通常の発/着信を行う事が可能であり、もし発/着信が行われた場合には、通話終了までタイマの進行は停止される。
やがて、待ち受け状態のままで3分を経過すると、上記タイマがタイムアウトし、そのタイマ割込処理により制御はステップS52に移る。ステップS52ではタイマ割込を不許可にし、かつ前記呼を切断(又は留保)していたソフトウェア供給装置50に呼を接続して上記ステップS45に戻る。以下同様にして進み、やがて、ステップS48の判別で転送ブロック番号>Nになると、ダウンロードバッファ44へのダウンロード終了である。処理はステップS53に進み、ソフトウェア供給装置50との間の呼を切断すると共に運用中の制御ソフトウェア43を停止し、図8の更新処理(更新ソフトウェア41)に制御を移す。
図8は実施の形態による更新処理のフローチャートである。ステップS21では新たなバージョン管理情報の書込先領域(16バイト分)の内容が0F…FHか否かを判別する。なお、最新のバージョン管理情報の所在に関する情報はバッテリバックアップRAM34のワークエリア45に記憶されており、通常はここに記録が残っているので、その次の書込先領域を選択すれば、その内容は0F…FHとなり、処理はステップS25に進む。但し、バックアップ電池の残量が不足して記録が失われた様な場合、又は既に使用された
セクタを新たに使用する様な場合には、この判別はNOとなる場合がある。NOの場合はこの書込先領域が既に使用されているため、更にステップS22においてこの書込先領域はセクタの先頭か否かを判別する。先頭でない場合はステップS24で次の書込先領域を選択してステップS21に戻る。また先頭の場合はステップS23でこの書込先領域を含むセクタを消去し、消去後にステップS21に戻る。
上記ステップS21の判別で新たな書込先領域が検出されると、ステップS25では「バージョン番号」の欄にダウンロードされた制御ソフトウェアのバージョン番号を書き込む。ステップS26では「セクタアドレス」の欄に更新対象となる制御ソフトエウェア記憶領域43のセクタアドレスを書き込む。また、もしセクタ内の部分的な更新をする場合には、「セクタバッファアドレス」の欄に部分的な更新ソフトウェアを格納しているセクタバッファ44aのアドレスを書き込む。なお、部分的な更新をしない場合は「セクタバッファアドレス」の欄に「セクタアドレス」の欄と同じ内容を書き込む。ステップS27ではバージョン書込完了フラグに0(完了)を書き込む。
ステップS28ではセクタ内の部分的な更新を行うか否かを判別する。部分的な更新を行わない場合は、ステップS32で更新対象の連続する又は飛び飛びの複数のセクタをダウンロードバッファ44に格納されている各モジュール本体の内容で書き換える。書き換えは、更新対象領域の各セクタを消去し、その上に更新用ソフトウェアを書き込む。そして、ステップS33に進む。
また上記ステップS28の判別でセクタ内の部分的な更新を行う場合は、ステップS29でセクタバッファ44aに更新内容(1セクタ分)を取得する。具体的に言うと、更新対象のセクタから更新前の制御ソフトウェアデータを読み出すと共に、その一部分をダウンロードバッファ44に格納された部分的な更新データによって書き換え、これをセクタバッファ44aに書き込む。好ましくは、この様なデータ書き換え処理の途中で発生する様な装置の電源断にも有効に対処するため、データの転送処理はバッテリバックアップされたワークエリア45を介して行われる。ステップS30ではセクタバッファ書込完了フラグに0(完了)を書き込む。ステップS31では更新対象の1セクタ分の内容をセクタバッファ44aの内容で書き換える。書き換えは、更新対象の1セクタを消去し、その上にセクタバッファ44aの内容を書き込む。ステップS33では更新完了フラグに0(完了)を書き込む。そして、ステップS34では更新された制御ソフトウェア43を起動する。
この様に更新処理の各段階が完了する毎に対応する完了フラグの記録を取るのは、更新ソフトウェア(モジュール等)が制御ソフトウェアの格納領域43とダウンロードバッファ44のいずれに存在していたかを後になって各段階毎に正確に把握できるようにするためである。
なお、図示しないが、これらの一連の更新処理の途中で、万一、フラッシュROM33への書き込みや消去動作においてエラー(ハードウェア的に検出可能)が発生した場合には、コンソール部24に移動局装置10の修理が必要である旨を表示して処理を停止する。
また、上記ダウンロードが完了した時点と更新が完了した時点の双方にて、データ誤り(チェックサム)の検出を行い、問題があれば再試行することにより、更新時の事故を最低限に抑えることができる。
以上はダウンロードバッファ44に格納可能な1回分のダウンロード処理及びその更新処理を述べたが、ダウンロードバッファ44のサイズに制限があるため、1回の更新では
必ずしも制御ソフトウェア43の全体が最新バージョンになるとは限らない。即ち、あるバージョンの移動局装置10が最新バージョンとなるためには数回にわたるモジュールの更新を要する場合がある。この場合は、移動局装置10は上記のダウンロード及び更新の処理を繰り返すことでダウンロードバッファ44のサイズを越える様な制御ソフトウェア全体の更新が可能となる。
例えば移動局装置10は、ある制御ソフトウェアの更新完了後に再びステップS41のバージョン比較要求処理へ移行することにより、上記複数回の更新が必要であったり、又はある制御ソフトウェアのダウンロード中に該制御ソフトウェアの最新版が更新されていた様な場合であっても、これを速やかに再更新することが可能である。この場合の制御ソフトウェア43は、更新を行った直後の場合には、まずバージョン比較要求処理を行うように作り込まれる。更新直後であるか否かの状態はバッテリバックアップRAM34に記録しておく。もしその内容が失われた場合は、バージョン比較要求を行わずに通常の運用処理を開始する。この場合は更新が遅れることになるが、移動局装置10の動作に支障はない。
図9は実施の形態による更新判定処理のフローチャートである。本実施の形態では、上記制御ソフトウェア43の更新処理中は移動局装置10に対する一切の操作を受け付けないようにするが、電池残量の不足や電池の取り外しによって更新処理が中断してしまうことは避けられない。このため移動局装置10が起動(電源投入等)した時には、制御ソフトウェア43を起動する前に、それが正しく動作可能であるか否か、即ち、更新処理の途中でなかったか否かを判定するために、まずはこの更新判定処理を行う。
ステップS11では最新のバージョン管理情報が既知か否かを判別する。最新のバージョン管理情報の所在については、バッテリバックアップRAM34のワークエリア45に記憶されており、通常は記録が残っているので、この判別は既知となる。しかし、バックアップ電池の残量が不足して記録が失われた様な場合にはステップS12で最新のバージョン管理情報を探す。
最新のバージョン管理情報を見つけるには、まずバージョン管理情報を格納している2つのセクタの先頭領域(バージョン番号欄)を調べる。いずれかのセクタが0FFFFFFFFH(消去状態)であれば、そうでない方のセクタに最新のバージョン管理情報が存在する。また双方共に0FFFFFFFFHでない時は、バージョン番号の値の大きい方に存在する。こうして、一方のセクタを特定した後は、先頭から順にバージョン番号を調べていくことにより最新のバージョン管理情報を見つけることができる。この時、セクタの末尾に到達すれば、それが最新のバージョン管理情報であるし、また途中で0FFFFFFFFHが見つかれば、その手前に最新のバージョン管理情報が存在する。
ステップS13では最新のバージョン管理情報の更新完了フラグ=0(完了)か否かを判別する。更新完了の場合は図8のステップS34に進み、制御ソフトウェア43を起動する。また更新完了でない場合は更にステップS14でバージョン書込完了フラグ=0(完了)か否かを判別する。バージョン書込完了でない場合は図8の更新処理(ステップS21)に制御を移す。なお、上記最新のバージョン管理領域は既知であるから、上記ステップS21に制御を移す代わりに、ステップS25に制御を移しても良い。またバージョン書込完了の場合は更にステップS15でセクタ内の部分的な更新か否かを判別する。既にバージョン書込完了となっているので、この判別は「セクタアドレス」欄と「セクタバッファアドレス」欄の情報を調べることで行える。部分的な更新でない場合は図8のステップS32に進み、更新対象の複数のセクタを書き換える。また部分的な更新の場合は、更にステップS16でセクタバッファ書込完了フラグ=0(完了)か否かを判別する。セクタバッファ書込完了でない場合は図8のステップS29に進み、セクタバッファ44a
に更新内容を取得する。またセクタバッファ書込完了の場合は図8のステップS31に進み、更新対象の1セクタを書き換える。
図11〜図13は実施の形態によるダウンロード/更新処理のイメージ図(1)〜(3)で、図11はモジュールB,C,Dが更新対象となった場合のタイミングチャートを示している。ダウンロードバッファ44の大きさによる制限があるため、全モジュールを同時に更新することはできない。ここではモジュールBを更新した後にモジュールC,Dを更新する。更新を2段階に分けて行うため、制御ソフトウェア43のバージョン番号も2回更新されている。
ダウンロードに要する時間は更新対象のサイズに比例する。特に更新対象が大きい場合には、長時間にわたって移動局装置10が使用できなくなることは避けなければならない。この移動局装置10は通信経路(チャネル)を1系統しか持たないため、通信中は着信を受け付けることができなくなる。通信中の本装置10に対して発信すると、話中となってしまう。ダウンロード時も例外ではない。着信を全く妨げないようにすることは不可能であるが、長時間連続して着信不可能とならないようにすることは可能である。ここでは、転送ブロックの転送毎に通常運用を行う時間(例えば3分以上)を設けることにより、着信が入り込む隙間を空けておく。この間に着信があった場合は、続くダウンロードを中断(延期)する。なお、ユーザはこの間に発信することも可能である。
一例の時間配分を具体的に述べると、この移動局装置10の無線通信速度は例えば9600bpsである。この場合の転送ブロックのサイズは例えば32KB以下として、30秒以内で転送できるようにする。1ブロック転送完了後の休止時間は例えば3分以上とする。もし、このようなブロック分割と休止とを行わない場合は、1MBのダウンロードでは約15分間にわたって着信が不可能となる。これを30秒の転送と3分の休止の繰り返しとすると、ダウンロード完了までには約112分かかってしまうが、一般にこの様なソフトウェア更新の遅れは問題とはならない。むしろ、多くの場合に、加入者は最初に話中であった時には1〜3分程度待って発信し直すことを考慮すると、3分以上の休止時間を設けることで装置運用上の悪影響は少ないと言える。
また、ユーザの発/着信操作を妨げないようにするためには、ダウンロード中(ブロック転送中)であってもキー入力等を受け付けるようにして、キー入力操作された時には速やかにダウンロードを中断することが好ましい。
また、ダウンロードによる通信中は、待ち受け状態であっても大幅に消費電力が上昇する。ダウンロードによって装置10の公称の待ち受け時間が短くなることは好ましくないため、ダウンロードによって電池を消費しないように、好ましくは移動局装置10が充電装置から外された時にはダウンロードを中断する。
上記様々な理由でダウンロードが中断された場合には、その続きから再開できるようにすると無駄が少ない。これを簡単に実現するため、ダウンロード対象を小さな転送ブロックに分割して転送している。中断されたダウンロードの再開は転送ブロックの単位で行う。再開する転送ブロックを決めるための進行状況はバッテリバックアップRAM34において記録・管理する。その内容が失われた場合には、始めからやり直す。なお、ダウンロードの中断と再開によって転送ブロックの抜けが発生した様な場合は、ダウンロードバッファ44におけるチェックサムの検査により誤りを検出できる。
図12は1段階目のモジュールBの更新処理のイメージを示している。なお、図では稼働中のソフトウェアに網点を付記してある。旧モジュールBを含む現行の制御ソフトウェア43によって新しいモジュールBをダウンロードした後、現行の制御ソフトウェア43
を一旦停止し、この間に更新ソフトウェア41がモジュールBを更新する。モジュールBの更新が完了した時点で制御ソフトウェア43のバージョン番号を更新し、制御をモジュールBが更新された新しい制御ソフトウェア43に戻す。
図13は2段階目のモジュールC,Dの更新処理のイメージを示している。モジュールC,Dはダウンロードバッファ44に収まる大きさであるため、同時に更新できる。旧モジュールC,Dを含む現行の制御ソフトウェア43によって新しいモジュールC,Dをダウンロードした後、現行の制御ソフトウェア43を一旦停止し、この間に更新ソフトウェア41がモジュールC,Dを更新する。モジュールC,Dの更新が完了した時点で制御ソフトウェア43のバージョン番号を更新し、制御をモジュールC,Dが更新された新しい制御ソフトウェア43に戻す。なお、上記複数のモジュールC,Dを同時に更新できる機能を利用して、該複数のモジュールC,Dにまたがる様な大規模なソフトウェア変更を制御ソフトウェア43に加えることも可能となる。
本実施の形態によれば、ソフトウェア供給装置50は各移動局装置10からのブロック転送要求に応じて対応する転送ブロックを送信するだで良く、各移動局装置10における更新の進行状況等は各々の移動局装置10が自分自身で管理する。従って、ソフトウェア供給装置50の処理負荷を大幅に抑えることができる。また移動局装置10からソフトウェア供給装置50に対して要求を出し、それに対する応答によって更新対象を受け取る方法は、網側に一斉通知の仕組みを必要としないため、通信システム全体に関わるような変更を加える必要はなく、移動局装置10及び対応するソフトウェア供給装置50をシステムに追加するだけで、スムーズな導入が期待できる。
なお、上記実施の形態ではTDMA方式による移動通信システムへの適用例を述べたが、本発明は他の様々な通信方式(CDMA等)の移動通信システムにも適用できる。また、この様な大規模な移動通信システムのみならず、本部局と複数の無線端末局とが無線接続可能な他の一般の無線システム(業務用無線通信システム等)にも適用できる。
また、上記本発明に好適なる実施の形態を述べたが、本発明思想を逸脱しない範囲内で各部の構成、制御、及びこれらの組合せの様々な変更が行えることは言うまでも無い。