JP2005100428A - 無線端末装置及び該装置へのソフトウェア供給装置 - Google Patents

Abstract

【目的】 簡単な構成及び制御で制御ソフトウェアの更新を効率良く安全に行えることを課題とする。
【構成】 無線端末装置は、ディジタル信号を送受信可能な無線通信部と、無線通信制御を含む装置の運用に係る制御ソフトウェア及び該制御ソフトウェアの更新処理を行う更新ソフトウェアを格納する主メモリと、前記主メモリの各ソフトウェアに従って動作するＣＰＵと、更新用ソフトウェアを一時的に格納するバッファメモリとを備え、ＣＰＵは、現用の制御ソフトウェアの制御下で無線を介してダウンロードされた更新用ソフトウェアをバッファメモリに蓄積して後、前記更新ソフトウェアの制御下で現用の制御ソフトウェアの対応部分を前記バッファメモリに蓄積した更新用ソフトウェアで更新し、しかる後制御を更新後の制御ソフトウェアに戻す。
【選択図】 図１

Description

本発明は無線端末装置及び該装置へのソフトウェア供給装置に関し、更に詳しくは、基地局と複数の無線端末装置とが無線回線を介して相互に接続する移動通信システムにおける無線端末装置及び該装置に更新用ソフトウェアを供給するソフトウェア供給装置に関する。今日、移動通信システムにおける通信サービスは急成長を続けており、サービス機能の追加やそれに伴なうソフトウェア障害修正等の頻度が高くなっている。これらに要する保守費用の低減等を図るため、携帯電話機等の移動局装置においても制御ソフトウェアの更新を効率的に行うことが求められている。

従来は、制御ソフトウェアを格納しているＲＯＭ等を交換し、又はプログラマブルＲＯＭに外部機器を接続して内容を直接に書き換える方法に代えて、無線回線を介して更改用ソフトウェアをプログラマブルＲＯＭにダウンロードすることが知られている。

図１４は従来技術を説明する図で、図１４（Ａ）は従来の無線電話機ソフトウェア変更方式の構成を示している（特許文献１）。図において、ＲＯＭ７８は新ソフトデータを取り込むのに必要なソフトウェアを記憶し、ＲＯＭ７９は記憶した新ソフトウェアが正しいか否かを検索するソフトウェアを記憶している。動作を概説すると、ソフトウェアを変更する際には、ＣＰＵ７６はＲＯＭ７８，７９によるソフトウェア制御の下で、ソフトウェア供給装置（不図示）の側から無線送信される新ソフトウェアをモデム７４で復調してメモリ７７に記憶し、これを改めて主記憶データとする。

しかし、このＲＯＭ７８は無線通信制御（呼制御，送受信制御等）に係る比較的大きなソフトウェアを主メモリ７７と重複して記憶しているため、メモリの無駄使いであるばかりか、ＲＯＭ７８のサイズも大きくなり、装置の小型化、低価格化が困難となる。また通信サービスの改訂により、装置の無線通信制御に係るソフトウェアが改訂されると、ＲＯＭ７８を交換しなくてはならない。

図１４（Ｂ）は従来の無線通信装置の構成を示している（特許文献２）。動作を概説すると、ＥＥＰＲＯＭ８８に格納されている運用中の制御用プログラムの機能向上を計る場合には、基地局（不図示）から無線送信される更改プログラムを、変復調器８６のルートで、かつプロセッサ８９及びＲＡＭ９０によるデータ処理作用を介してＥＥＰＲＯＭ８８に収納する。

しかし、上記ＥＥＰＲＯＭ８８で運用中の現用のプログラムに更改プログラムを上書きする方式であると、ダウンロード（更新）の途中で運用中のプログラムが壊れてしまう場合があり、ソフトウェアの更新を安全に行えない。
特開昭６１−２２０５３５ 特開昭６２−３８６２４

上記の如く従来のソフトウェア更新方式は、従前のＲＯＭ等を交換する方法に代え、無線回線を介して更改用ソフトウェアをダウンロードすることを示すものに過ぎない。しかも、特許文献１では主メモリ７７の他に大きなＲＯＭ７８，７９を必要としており、また
特許文献２ではソフトウェアの更新を安全に行えない。

本発明は上記従来技術に鑑みなされたもので、その目的とする所は、簡単な構成及び制御で制御ソフトウェアの更新を効率良く安全に行える無線端末装置及び該装置へのソフトウェア供給装置を提供することにある。

上記の課題は例えば図１の構成により解決される。即ち、本発明（１）の無線端末装置は、ディジタル信号を送受信可能な無線通信部と、無線通信制御を含む装置の運用に係る制御ソフトウェア及び該制御ソフトウェアの更新処理を行う更新ソフトウェアを格納する主メモリと、前記主メモリの各ソフトウェアに従って動作するＣＰＵと、更新用ソフトウェアを一時的に格納するバッファメモリとを備え、ＣＰＵは、現用の制御ソフトウェアの制御下で無線を介してダウンロードされた更新用ソフトウェアをバッファメモリに蓄積して後、前記更新ソフトウェアの制御下で現用の制御ソフトウェアの対応部分を前記バッファメモリに蓄積した更新用ソフトウェアで更新し、しかる後制御を更新後の制御ソフトウェアに戻すものである。

本発明（１）においては、ＣＰＵは現用の制御ソフトウェアの制御下で更新用ソフトウェアを別途バッファメモリにダウンロードする構成により、現用の制御ソフトウェアをフルに活用して、また稼働中の制御ソフトウェアを書き換えることも無く、更新用ソフトウェアを効率良く安全にバッファメモリにダウンロードできる。またダウンロード後は、更新ソフトウェアの制御下で現用の制御ソフトウェア（停止中）の対応部分を前記バッファメモリの内容で更新する構成により、現用の制御ソフトウェアを安全に更新できる。

また本発明（２）においては、上記本発明（１）において、バッファメモリのサイズは制御ソフトウェアのサイズよりも小さく、かつ更新用ソフトウェアのサイズよりも大きい。

本発明（２）においては、バッファメモリのサイズは更新が必要な部分のソフトウェアを記憶できれば十分である。この更新は制御ソフトウェアの部品化されたモジュール毎に行っても良いし、最小１バイト又は１ビットを書き換える様なパッチでも良い。但し、バッファメモリが制御ソフトウェアと同一サイズになると、メモリの節約とはならない。本発明（２）によれば、係る状況の下で、更新（更新用ソフトウェアのサイズ）の柔軟性と、装置の大きさや価格及びダウンロード時間とのトレードオフが可能となる。因みに、更新の柔軟性が低い（バッファサイズが小さい）ほど、装置は小さく安価になり、かつダウンロード時間も短くなる。

本発明（３）においては、上記本発明（２）において、制御ソフトウェアは各単独で更新可能な複数のモジュールに分割されていると共に、ＣＰＵは各モジュールに対するダウンロードと更新の処理を順次繰り返すことにより複数のモジュールを更新する。

本発明（３）においては、モジュール毎のダウンロードと更新の処理を繰り返す構成により、少ないバッファメモリを使用して大きな制御ソフトウェアの全体を効率良く更新できる。

本発明（４）においては、上記本発明（２）又は（３）において、更新用ソフトウェアは所定サイズのブロックに分割されていると共に、ＣＰＵはブロック単位でダウンロードを要求し、所要サイズ分の更新用ソフトウェアを順次バッファメモリに蓄積する。

本発明（４）においては、ＣＰＵはブロック単位でダウンロードを行う構成により、１
ブロック分のダウンロードに拘束される時間が短い。またＣＰＵはブロック単位でダウンロードを要求する構成により、ブロック転送の主導権はＣＰＵの側に存在し、このためにＣＰＵは次のブロック転送を要求するまでの間に様々な処理を実行できる。例えば装置の運用に係る通常の通信サービスを実行することが可能であり、この間に、待ち受け状態となって着信を受け付けることも、また発信をすることも可能となる。従って、無線端末装置の本来の機能は損なわれず、その利便性を維持できる。

本発明（５）においては、上記本発明（４）において、ＣＰＵはブロックデータの転送順を管理すると共に、ブロックデータのダウンロード中に所定のイベントが発生した場合はダウンロード処理を中断する。

本発明（５）においては、所定のイベントが発生した場合はダウンロード処理を中断する構成により、ダウンロードとダウンロードとの間のみならず、ダウンロード中であってもその処理を開放して必要なイベント処理を速やかに実行できる。所定のイベントとは、例えば発信操作である。またブロックデータの転送順を管理する構成により、ダウンロードがどの時点で中断されても、当該中断されたブロックの始めからダウンロードを再開でき、効率が良い。

本発明（６）においては、上記本発明（１）において、主メモリの制御ソフトウェアを記憶する部分と、バッファメモリとがフラッシュＲＯＭにより構成されている。

従って、安価なメモリにより、更新用ソフトウェアのダウンロード及びそれによる制御ソフトウェアの更新を安全に行える。

本発明（７）のソフトウェア供給装置は、無線端末装置と通信を行う通信手段と、該無線端末装置が、記憶している通信機能に関する第２の制御ソフトウェアの制御に基づいてダウンロードを行うソフトウェアであって、該第２の制御ソフトウェアの少なくとも一部とおきかえられる、該無線端末装置の無線通信機能に関する第１の制御ソフトウェアを記憶する記憶手段と、を備えたものである。

本発明（８）のソフトウェア供給装置は、無線端末装置と通信を行う通信手段と、該無線端末装置によってダウンロードされる制御ソフトウェアを記憶するメモリと、を備え、前記通信手段は、記憶した該制御ソフトウェアの送信の前に、記憶した該制御ソフトウェアを送信するための分割ブロック数を該無線端末装置に通知すること、を特徴とするものである。

本発明（９）の無線端末装置は、ソフトウェア供給装置と通信を行う無線通信手段と、現用の制御ソフトウェアと、該現用の制御ソフトウェアの更新を開始する更新ソフトウェアとを記憶する記憶手段と、該ソフトウェア供給装置から制御ソフトウェアをダウンロードして、該メモリに記憶した制御ソフトウェアを該ダウンロードした制御ソフトウェアにより更新するが、その際、更新ソフトウェアは更新しないようにする制御手段と、を備えたものである。

本発明（１０）においては、上記本発明（９）において、前記更新ソフトウェアは、現用の制御ソフトウェアとは別個に前記記憶手段に記憶したものである。

本発明（１１）の無線端末装置は、ソフトウェア供給装置と通信を行う無線通信手段と、現用の制御ソフトウェアを記憶する記憶手段と、自装置の電源状態に基づいて、該制御ソフトウェアの更新のために前記ソフトウェア供給装置と通信を行うことを抑制する制御手段と、を備えたものである。

本発明（１２）の無線端末装置は、ソフトウェア供給装置と通信を行う無線通信手段と、現用の制御ソフトウェアを記憶する記憶手段と、待受け状態において前記ソフトウェア供給装置と通信するように制御する制御手段と、を備えたものである。

本発明（１３）の無線端末装置は、ソフトウェア供給装置と通信を行う無線通信手段と、現用の制御ソフトウェアを記憶する記憶手段と、着信に対する応答操作を検出した場合に、該ソフトウェア供給装置からの制御ソフトウェアのダウンロードを中断する制御手段と、を備えたものである。

本発明（１４）の無線端末装置は、制御ソフトウェアを送信する際に、分割ブロック数Ｎを通知するソフトウェア供給装置から該制御ソフトウェアを無線回線を介してダウンロードする無線端末装置において、現用の制御ソフトウェアを記憶する記憶手段と、記憶した該制御ソフトウェアを更新する際に、前記無線回線を介して分割された複数の制御ソフトウェアを受信するために、前記ソフトウェア供給装置に対して通知されたＮ回にわたり要求を行う制御手段と、を備えたものである。

本発明（１５）の無線端末装置は、ソフトウェア供給装置と通信を行う無線通信手段と、現用の制御ソフトウェアを記憶する記憶手段と、記憶した該制御ソフトウェアの更新のために、分割された制御ソフトウェアブロックのダウンロードを開始する前に、分割数に関する情報を前記ソフトウェア供給装置から受信する受信手段と、を備えたものである。

本発明（１６）の無線端末装置は、ソフトウェア供給装置と通信を行う無線通信手段と、現用の制御ソフトウェアを記憶する記憶手段と、該ソフトウェア供給装置から制御ソフトウェアをダウンロードし、記憶した前記制御ソフトウェアの対応部分を消去してから、該ダウンロードした制御ソフトウェアを前記記憶手段に記憶するように制御する制御手段と、を備えたものである。

本発明（１７）の無線端末装置は、ソフトウェア供給装置と通信を行う無線通信手段と、現用の制御ソフトウェアを記憶する記憶手段と、該ソフトウェア供給装置から制御ソフトウェアをダウンロードし、記憶した前記制御ソフトウェアを該ダウンロードした制御ソフトウェアで更新する間の自端末装置に対する操作を受けつけないように制御する制御手段と、を備えたものである。

以上述べた如く本発明によれば、既存の移動通信システムに殆ど変更を加えることなく、ソフトウェア供給装置と、それに対応した移動局装置を導入することで、制御ソフトウェアの自動更新が容易に可能となる。また少ないメモリで大きな制御ソフトウェアの更新を効率良く安全に行え、装置の小型化，低価格化を容易にする。

以下、添付図面に従って本発明に好適なる実施の形態を詳細に説明する。なお、全図を通して同一符号は同一又は相当部分を示すものとする。

図２は実施の形態による移動通信システムの構成を示す図で、図において、１００は公衆網（ＰＳＴＮ）、１０１は移動体交換局（ＭＳＣ）、１０２は基地局制御装置（ＢＳＣ）、１０３は基地局（ＢＴＳ）、５０はソフトウェア供給装置、６０は保守端末、１０は移動局装置（無線端末装置，携帯電話機等）である。

ソフトウェア供給装置５０において、５１はソフトウェア供給装置５０の主制御（呼制
御，各種バージョンの制御ソフトウェアの蓄積管理並びにダウンロードの判定及びダウンロード制御等）を行うＣＰＵ、５２はＣＰＵ５１が実行する各種アプリケーションプログラムやデータを記憶する主メモリ（ＭＥＭ）、５３は各種バージョンの制御ソフトウェア及びそのバージョン情報等を蓄積格納しているディスク装置（ＤＳＫ）、５４は通信制御部（ＣＩＦ）、５５は保守端末６０に接続するシリアルインタフェース部（ＳＩＦ）、５６はＣＰＵ５１の共通バスである。

移動局装置１０において、１１はＴＤＭＡ方式等による通信制御部、１２は送信部、１３は送／受分波スイッチ（Ｔ／Ｒ）、１４はアンテナ、１５は受信部、１６は周波数シンセサイザ（ＳＹＮ）、１７は音声の符号データとＰＣＭデータ間の符号変換を行うコーデック（ＣＤＣ）、１８はＰＣＭデータと音声信号間の変換を行うベースバンド処理部（ＢＢＰ）、１９はマイク（ＭＩＣ）、２０はレシーバ（ＲＣＶ）、２１はブザー（ＢＺ）等の発音体、２２は移動局装置１０の主制御（呼制御，キー操作制御、制御ソフトウェアのダウンロード／更新制御等）を行うＣＰＵ、２３はＣＰＵ２２が実行する各種アプリケーションプログラムやデータを記憶するＲＡＭ，マスクＲＯＭ，フラッシュＲＯＭ等からなる主メモリ（ＭＥＭ）、２４は液晶表示部やダイヤルキー等を備えるコンソール部（ＣＳＬ），２５は電源である充電可能なバッテリー部（ＢＴ）、２６はその充電用端子、２７はＣＰＵ２２の共通バスである。

ソフトウェア供給装置５０は、網側に接続され（又は移動体交換局１０１等に組み込まれ）、移動局装置１０についての各種バージョンの制御（運用）ソフトウェアを蓄積・管理すると共に、移動局装置１０からのバージョン比較要求に応じて更新の必要性有／無を判定し、更新が必要な場合は基地局１０３を介して対応する制御ソフトウェア（更新用ソフトウェア）を移動局装置１０にダウンロードする。なお、ソフトウェア供給装置５０に対する新たな制御ソフトウェアの供給は保守端末６０等から行うことができる。

移動局装置１０に電源投入すると、ＣＰＵ２２は通信制御部１１を介して最寄りの基地局１０３に位置登録し、待ち受け状態となる。この状態で、もし着信があると、ＣＰＵ２２はＢＢＰ１８に呼出音（リンギング）のサウンドデータＳＤを送出し、これによりブザー２１が鳴動する。またユーザはこの待ち受け状態から発呼することが可能であり、ユーザがダイヤル発信操作をすると、ＣＰＵ２２は所定の発呼処理に従って基地局１０３に発信し、通話相手に接続される。なお、この様なＣＰＵ２２の呼制御（及び後述のソフトウェアダウンロード制御）はＣＰＵ２２が通信制御部１１との間で制御データＣＤをやり取りすることにより行われる。

更に、通話中におけるマイク１９からの音声信号はＢＢＰ１８，ＣＤＣ１７，通信制御部１１を介して送話データＴＤに変換（フォーマット）され、更に送信部１２，アンテナ１４を介して基地局１０３に送信される。また基地局１０３からの受信信号は受信部１５で受話データＲＤに変換され、更に通信制御部１１、ＣＤＣ１７，ＢＢＰ１８を介して音声信号に変換され、レシーバ２０より出力される。

また、ＣＰＵ２２はこの待ち受け状態を利用して自らソフトウェア供給装置５０に発呼し、自己の制御ソフトウェアが最新バージョンか否かを問い合わせることが可能であり、最新バージョンでない場合は、ソフトウェア供給装置５０より最新バージョンにステップアップするための制御ソフトウェア（更新用ソフトウェア）がダウンロードされ、こうして自己の制御ソフトウェアを常に最新バージョンに維持できる。以下、詳細に説明する。

図３〜図５は実施の形態による移動局装置のメモリマップを説明する図（１）〜（３）で、図３（Ａ）は主メモリ２３の一部構成（メモリ空間）を示している。このメモリ空間はマスクＲＯＭ３２と、フラッシュＲＯＭ（ＥＥＰＲＯＭでも良い）３３と、バッテリバ
ックアップＲＡＭ３４とから構成され、ここに各メモリの性質に応じたソフトウェアやデータが格納される。

ところで、一般にソフトウェアの格納アドレスはＣＰＵ２２の構造やＯＳの制約により予め決まっており、これに従って各ソフトウェアモジュールの先頭アドレスは固定となっている。携帯電話機を始めとする現状の小型装置にはこの様な制限を持つものが多く、図３（Ａ）もその例に従っている。なお、このＣＰＵ２２はアドレスを３２ビットで表現するものとする。

更新ソフトウェア４１は、図８の更新処理と図９の更新判定処理とからなり、この部分は更新（変更）する必要が無いのでマスクＲＯＭ３２に格納される。更新ソフトウェア４１は後述の制御ソフトウェア４３を上書きして更新する機能を備え、制御ソフトウェア４３が停止している時にのみ動作する。

バージョン管理領域４２は、制御ソフトウェアのバージョン管理情報を書き換え可能で、かつ移動局装置１０の電源断時にも内容を保持する必要があるため、フラッシュＲＯＭ３３上に設けられる。ところで、この様なフラッシュＲＯＭ３３の内容を書き換える場合には、書き込みに先立って消去を行う必要がある。データの書き込みはバイト単位で行えるが、消去はセクタ単位となる。従って、バージョン管理領域４２や後述の制御ソフトウェアの書き換えは、物理的にはセクタ単位で行うことになる。この例のフラッシュＲＯＭ３３では、消去したセクタは全ビット＝１になり、書き込みの際は対象ビットを１から０に変更する。

また、フラッシュＲＯＭ３３では、データの書き換えを簡単に行うために、できるだけセクタの先頭となるアドレスにバージョン管理領域４２や後述の制御ソフトウェアの各モジュールを配置する。本実施の形態では１セクタが６４ＫＢのフラッシュＲＯＭ３３を使用しており、各セクタの先頭アドレスは１０００００Ｈ（Ｈはヘキサデシマル表示を表す）から１００００Ｈ（６４ＫＢ）の間隔となっている。

移動局装置１０の制御（運用）ソフトウェア４３は、更新可能でかつ不揮発性の要求から同じくフラッシュＲＯＭ３３に格納される。移動局装置１０の大きさや価格を抑えるためには、フラッシュＲＯＭ３３のメモリ容量は小さいことが望ましい。そこで、本実施の形態ではフラッシュＲＯＭ３３の格納領域を上書き（セクタ毎の消去、再書込）する方法によって制御ソフトウェア４３の記憶領域の再利用を行い、ソフトウェア更新に伴なうフラッシュＲＯＭ容量の増加を最小限に抑えている。

一例の制御ソフトウェア４３はソフトウェアモジュール（部品）Ａ〜Ｄにより構成されている。モジュールＡは例えば通信サービスとは関係無い様な固定的な処理からなり、更新の対象外となっている。モジュールＢは主に装置の通信制御処理（呼処理等）に係り、通信サービスの変更／追加／改善等に関係があるため、更新対象となっている。またモジュールＣ，Ｄは主にキー操作処理やその他のサービス機能に係り、これも更新対象となっている。なお、この様な制御ソフトウェアを更新する場合には、一般にプログラムサイズが変動するため、各モジュールＡ〜Ｄの先頭アドレスは、それを見込んだ空き領域を含めて、予め制御ソフトウェアの設計時に決定されている。

新しい制御ソフトウェアのダウンロードは現行の制御ソフトウェアの実行下で行われる。そのために必要な無線通信機能等の実現には、実際上相互に関連して動作する上記いずれのモジュールＡ〜Ｄも欠かすことができない。この様な状況の下で、制御ソフトウェア４３の更新は、基本的にはモジュール単位で行われる。更にはダウンロードに伴う通信トラヒックの低減を図るため、モジュール内の部分的な更新も可能となっている。なお、制
御ソフトウェアをモジュール単位で更新する場合の一般的な留意事項であるが、新しいモジュールＢは、モジュールＡ及び新旧いずれのモジュールＣ，Ｄと組み合わせた場合においても、正しく動作するように作成される。

ダウンロードバッファ４４は、ソフトウェア供給装置５０よりダウンロードされた新しい制御ソフトウェア（更新用ソフトウェア）を一時的に格納する。ダウンロードバッファ４４の内容により現行の制御ソフトウェア４３を上書きしている途中で、万一、ダウンロードバッファ４４の内容が失われると、現行の制御ソフトウェアは二度と動作できなくなる。また現行の制御ソフトウェア４３が動作できなくなると、その機能を利用して行われるダウンロードのし直しも不可能となってしまう。そこで、ダウンロードバッファ４４にもフラッシュＲＯＭ３３を使用する。

ダウンロードバッファ４４のサイズは、装置のメモリ容量を増大させないために制御ソフトウェア４３のサイズよりもできるだけ小さくなるように選択される。但し、本実施の形態では最大のモジュールＢがフルに書き換えられる場合を考慮してモジュールＢよりも大きいサイズに選ばれる。その結果、図示の例ではダウンロードバッファ４４のサイズは１ＭＢ（制御ソフトウェアの１／２）であるが、モジュール数を増やし、各モジュールのサイズを小さくすると、ダウンロードバッファ４４のサイズも更に小さくできる。従って、ソフトウェア更新の実現に伴なうフラッシュＲＯＭ３３の容量増加を抑えることが可能であり、移動局装置１０の小型低価格化を図ることができる。

最新のバージョン管理情報がバージョン管理領域４２のどのアドレスに記録されているかの情報は、アクセスの利便性から、これをバッテリバックアップＲＡＭ３４のワークエリア４５に記憶しておく。なお、バックアップ電池の残量が不足して記憶が失われた場合は、後述の処理によりバージョン管理領域４２から最新のバージョン管理情報を直接に探すことが可能である。

図３（Ｂ）はモジュールＢの記憶態様を示している。モジュールＢの記憶エリア０．９ＭＢは、モジュールＢの本体（プログラム部分）０．８ＭＢと空きエリア０．１ＭＢとからなっている。なお、更新後のモジュールＢの本体が記憶エリアの最大サイズ０．９ＭＢを超える様な場合は、後続のモジュールＣ等を同時に更新して調整可能である。

図４はバージョン管理領域４２の記憶フォーマットを示している。フラッシュＲＯＭ３３上でバージョン管理情報を能率良く管理するために、セクタを２つ設けている。バージョン管理情報は１つ当たり１６バイトを使用し、更新の度に新たなバージョン管理情報を後の領域（１６バイト）に追記していく。こうして一方のセクタを使い切った時は、他方のセクタの先頭から使い始める。この時、他方のセクタが過去に使われたことがある場合は、当該セクタへのデータ書き込みに先立って、当該セクタを消去する。

バージョン番号は３２ビットの整数で管理し、数値の大きい方が新しいものとする。但し、本実施の形態ではフラッシュＲＯＭ３３を消去すると全ビット＝１になることから、これと区別するためにバージョン番号＝０ＦＦＦＦＦＦＦＦＨは無効とする。３２ビットからなるバージョン番号は４０億回以上の更新を識別可能であり、フラッシュＲＯＭ３３の書き換え可能回数（１０万回程度）を含む移動局装置１０の寿命を考えた場合には、無限とみなせる。

バージョン番号は、モジュールの組み合わせにより生じる不具合を防ぐため、モジュールではなく、基本的には制御ソフトウェア全体のバージョンを表す。但し、後述の如くある制御ソフトウェアがモジュール毎に段階的に更新される場合があり、この場合は各モジュールの更新毎に制御ソフトウェア全体としてのバージョン番号が更新される。

上記バージョン番号の他にも、セクタ内の部分的な更新が失敗した様な場合にやり直しができるように、更新対象である制御ソフトウェア格納領域４３内のセクタアドレスと、セクタ内の部分的な更新用ソフトウェアを保存している後述のセクタバッファ４４ａのアドレスとを記録する。なお、セクタ内の部分的な更新を行わない場合は、セクタアドレスとセクタバッファアドレスとを同じ値にする。セクタ内の部分的な更新を行う場合は、これらが同じ値になることはない。

更に、「バージョン書込完了フラグ」は上記バージョン管理情報のバージョン管理領域４２への書き込みが完了したか否かを表し、また「セクタバッファ書込完了フラグ」は後述セクタバッファ４４ａへの部分的な更新用ソフトウェアの書き込みが完了したか否かを表し、そして、「更新完了フラグ」は制御ソフトウェアにおける更新対象部分の更新（書き換え）が完了したか否かを表す。なお、これらの詳細は後述の説明により一層明らかとなる。

図５はダウンロードバッファ４４の記憶フォーマットを示している。図において、「モジュール数」は更新するモジュール数を表し、例えば単一のモジュールＢを更新する場合は「１」、複数のモジュールＣ，Ｄを同時に更新する場合は「２」となる。「モジュール本体」には更新用ソフトウェアのモジュール本体が格納され、少なくとも最大モジュールＢに対応する更新用ソフトウェアを格納できる大きさを備える。「アドレス」はモジュール本体の制御ソフトウェア格納領域４３における格納先アドレス、「サイズ」はモジュール本体のサイズを夫々表す。「チェックサム」には先頭のモジュール数からチェックサム領域の直前までの各データを１バイトずつ順に加算した結果を格納する。但し、桁あふれは無視する。上記「モジュール本体」以外の各情報はダウンロード時における転送ブロックのフォーマット時に付加されている。転送ブロックのデータフォーマットについては図１０に従って後述する。

なお、ダウンロードバッファ４４には単一のモジュールにつき複数の更新用ソフトウェア（各更新単位）をパッキングすることが可能である。この場合の各更新用ソフトウェアは「アドレス１」，「サイズ１」，「更新ソフトウェア本体１」，「アドレス２」，「サイズ２」，「更新ソフトウェア本体２」，…の如く順にパッキングされる。この場合のＣＰＵ２２は「アドレス１」，「アドレス２」等の情報に基づき、制御ソフトウェア格納領域４３内の飛び飛びの領域に散在するソフトウェアを個々に更新する。これにより広範囲にわたる更新を少ない情報量で能率良く行える。

「セクタバッファ」４４ａは、１セクタ（６４ＫＢ）分のバッファ領域からなり、制御ソフトウェア（モジュール）内のごく一部を更新する場合等において、セクタ内の部分的な更新を安全に行うために使用される。こうして、一例のダウンロードバッファ４４のサイズは、モジュール本体（８９６ＫＢ）＋管理領域（１０Ｂ）＋セクタバッファ（６４ＫＢ）からなっており、これをセクタ単位の６４ＫＢで切り上げて１ＭＢとしている。

図６，図７は実施の形態によるダウンロード処理のフローチャート（１），（２）である。図６において、制御ソフトウェア４３の更新が必要か否かの判定は移動局装置１０がソフトウェア供給装置５０に現用の制御ソフトウェアのバージョン番号を知らせたことを契機としてソフトウェア供給装置５０により行われる。この場合に、制御ソフトウェア４３の更新は移動局装置１０の電源状態が良好で、かつ装置１０が使用されていない（待ち受け状態）時に行うのが望ましい。そこで、本実施の形態では移動局装置１０が外部の充電装置（不図示）に接続され、かつ所定時間（例えば１時間）以上使用されていなかった時に問い合わせを開始する。なお、移動局装置１０が充電装置に接続されていることはバッテリー部２５により検出され、ＣＰＵ２２はこれをバス２７を介して検知できる。また
移動局装置１０が所定時間以上使用されていないことは、この区間に着信の受付操作等を含むいかなるキー操作も行われていないことによって検出される。

上記条件を満足すると、図示しないが、ＣＰＵ２２は、制御ソフトウェア４３に従いまずソフトウェア供給装置５０に自動的に発呼する。この発呼は網側が提供する通信サービスに対する特番発呼でも良いし、又はソフトウェア供給装置５０を着信先とする様な通常の発呼でも良い。そして、呼が接続されるとステップＳ４１の処理に入力する。ステップＳ４１ではＣＰＵ２２は「処理種別＝１：バージョン比較要求」，「バージョン番号」をソフトウェア供給装置５０に送信する。「バージョン番号」は自己の現用の制御ソフトウェア４３のバージョン番号である。

ソフトウェア供給装置５０は、バージョン比較要求を受け付けたことにより、ステップＪ１では受信したバージョン番号が当該移動局装置１０について移動通信システムが管理するところの最新バージョンか否かを判別する。最新でない場合は、ステップＪ２で最新バージョン又は最新バージョンにステップアップするための適切な更新用ソフトウェア（モジュール）を選択する。ステップＪ３では当該更新用ソフトウェアの転送ブロック数を取得する。また上記ステップＪ１の判別で最新バージョンの場合はステップＪ４で転送ブロック数＝０を取得する。ステップＪ５では転送ブロック数＝Ｎ（但し、Ｎ≠０の場合は新たな制御ソフトウェアのバージョン番号を含む）を移動局装置１０に返信する。

ＣＰＵ２２は、転送ブロック数を受信したことにより、ステップＳ４２では転送ブロック数＞０か否かを判別する。転送ブロック数＝０の場合は、移動局装置１０が最新バージョンで運用中であることを表すため、ソフトウェア供給装置５０との間の呼を切断してステップＳ４３に進み、移動局装置１０としての通常の運用処理を実行する。また転送ブロック数＞０の場合は、図７のステップＳ４５に進み、以下のダウンロード処理を開始する。

図７において、ダウンロード処理は、移動局装置１０が転送ブロックを要求し、ソフトウェア供給装置５０がその応答として転送ブロックを送信するという手順で行われる。即ち、ステップＳ４５ではＣＰＵ２２は「処理種別＝２：転送要求」，「バージョン番号」，「転送ブロック番号」を送信する。この転送要求には、特定の転送ブロックを簡単かつ一意に特定できるように、転送要求に係る制御ソフトウェアのバージョン番号と転送ブロック番号とが含まれる。転送ブロックには１ずつ増加する一連の番号が付与されており、これを転送ブロック番号と呼ぶ。各バージョン（モジュール）における先頭の転送ブロックの転送ブロック番号を１とする。

ソフトウェア供給装置５０は、転送要求を受け付けたことにより、ステップＪ７で対応する転送ブロックを移動局装置１０に返送する。その際には、ソフトウェア供給装置５０は転送要求に含まれるバージョン番号及び転送ブロック番号の情報をキーとして、管理テーブルから対応する転送ブロックを読み出す等の単純な処理により、速やかに転送ブロックを選択できる。

図１０に実施の形態による転送ブロックのイメージ図を示す。例えばモジュールＢを更新する場合は、ソフトウェア供給装置５０は予め更新対象の必要な１又は２以上の更新用ソフトウェアを収集して「モジュール情報」の欄に展開する。この展開は上記ダウンロードバッファ４４で述べた各フォーマット情報に対応して、更新用ソフトウェア毎に「アドレス」，「サイズ」，「更新用ソフトウェア本体」の各情報をパッキングする。更に、その先頭には「モジュール数＝１」の情報を付加し、またその最後尾には「モジュール数」と「モジュール情報」とについて求めた「チェックサム」の情報を付加する。そして、これらを各所要サイズの転送ブロックにブロック分割し、これらを転送ブロック番号との対
応にメモリ（ＤＳＫ５３等）に格納しておく。転送ブロックのサイズは、無線通信速度が９６００ｂｐｓの場合は、１ブロックの転送時間が３０秒以下となる様に３２ＫＢ以下に選択される。

なお、ダウンロードバッファ４４に対して複数のモジュールＣ，Ｄ等を一挙に転送することが可能であり、この場合は「モジュール数＝２等」とし、かつ「モジュール情報」の欄にはモジュールＣ，Ｄについての各更新用ソフトウェア毎に「アドレス」，「サイズ」，「更新用ソフトウェア本体」の各情報をパッキングする。

図７に戻り、ＣＰＵ２２は、転送ブロックを受信したことにより、ステップＳ４６では該転送ブロックをダウンロードバッファ４４に蓄積する。ステップＳ４７では転送ブロック番号に＋１する。ステップＳ４８では転送ブロック番号＞Ｎか否かを判別し、ＮＯの場合はステップＳ４９でタイマ（例えば３分）をスタートさせる。ステップＳ５０では該タイマによる割り込みを許可とし、ステップＳ５１では現用の制御ソフトウェア４３内の通常の運用処理に制御を移す。その際には、ソフトウェア供給装置５０との間の呼は一旦切断（又は保留に）され、移動局装置１０は待ち受け状態に戻る。この間に、移動局装置１０は通常の発／着信を行う事が可能であり、もし発／着信が行われた場合には、通話終了までタイマの進行は停止される。

やがて、待ち受け状態のままで３分を経過すると、上記タイマがタイムアウトし、そのタイマ割込処理により制御はステップＳ５２に移る。ステップＳ５２ではタイマ割込を不許可にし、かつ前記呼を切断（又は留保）していたソフトウェア供給装置５０に呼を接続して上記ステップＳ４５に戻る。以下同様にして進み、やがて、ステップＳ４８の判別で転送ブロック番号＞Ｎになると、ダウンロードバッファ４４へのダウンロード終了である。処理はステップＳ５３に進み、ソフトウェア供給装置５０との間の呼を切断すると共に運用中の制御ソフトウェア４３を停止し、図８の更新処理（更新ソフトウェア４１）に制御を移す。

図８は実施の形態による更新処理のフローチャートである。ステップＳ２１では新たなバージョン管理情報の書込先領域（１６バイト分）の内容が０Ｆ…ＦＨか否かを判別する。なお、最新のバージョン管理情報の所在に関する情報はバッテリバックアップＲＡＭ３４のワークエリア４５に記憶されており、通常はここに記録が残っているので、その次の書込先領域を選択すれば、その内容は０Ｆ…ＦＨとなり、処理はステップＳ２５に進む。但し、バックアップ電池の残量が不足して記録が失われた様な場合、又は既に使用されたセクタを新たに使用する様な場合には、この判別はＮＯとなる場合がある。ＮＯの場合はこの書込先領域が既に使用されているため、更にステップＳ２２においてこの書込先領域はセクタの先頭か否かを判別する。先頭でない場合はステップＳ２４で次の書込先領域を選択してステップＳ２１に戻る。また先頭の場合はステップＳ２３でこの書込先領域を含むセクタを消去し、消去後にステップＳ２１に戻る。

上記ステップＳ２１の判別で新たな書込先領域が検出されると、ステップＳ２５では「バージョン番号」の欄にダウンロードされた制御ソフトウェアのバージョン番号を書き込む。ステップＳ２６では「セクタアドレス」の欄に更新対象となる制御ソフトエウェア記憶領域４３のセクタアドレスを書き込む。また、もしセクタ内の部分的な更新をする場合には、「セクタバッファアドレス」の欄に部分的な更新ソフトウェアを格納しているセクタバッファ４４ａのアドレスを書き込む。なお、部分的な更新をしない場合は「セクタバッファアドレス」の欄に「セクタアドレス」の欄と同じ内容を書き込む。ステップＳ２７ではバージョン書込完了フラグに０（完了）を書き込む。

ステップＳ２８ではセクタ内の部分的な更新を行うか否かを判別する。部分的な更新を
行わない場合は、ステップＳ３２で更新対象の連続する又は飛び飛びの複数のセクタをダウンロードバッファ４４に格納されている各モジュール本体の内容で書き換える。書き換えは、更新対象領域の各セクタを消去し、その上に更新用ソフトウェアを書き込む。そして、ステップＳ３３に進む。

また上記ステップＳ２８の判別でセクタ内の部分的な更新を行う場合は、ステップＳ２９でセクタバッファ４４ａに更新内容（１セクタ分）を取得する。具体的に言うと、更新対象のセクタから更新前の制御ソフトウェアデータを読み出すと共に、その一部分をダウンロードバッファ４４に格納された部分的な更新データによって書き換え、これをセクタバッファ４４ａに書き込む。好ましくは、この様なデータ書き換え処理の途中で発生する様な装置の電源断にも有効に対処するため、データの転送処理はバッテリバックアップされたワークエリア４５を介して行われる。ステップＳ３０ではセクタバッファ書込完了フラグに０（完了）を書き込む。ステップＳ３１では更新対象の１セクタ分の内容をセクタバッファ４４ａの内容で書き換える。書き換えは、更新対象の１セクタを消去し、その上にセクタバッファ４４ａの内容を書き込む。ステップＳ３３では更新完了フラグに０（完了）を書き込む。そして、ステップＳ３４では更新された制御ソフトウェア４３を起動する。

この様に更新処理の各段階が完了する毎に対応する完了フラグの記録を取るのは、更新ソフトウェア（モジュール等）が制御ソフトウェアの格納領域４３とダウンロードバッファ４４のいずれに存在していたかを後になって各段階毎に正確に把握できるようにするためである。

なお、図示しないが、これらの一連の更新処理の途中で、万一、フラッシュＲＯＭ３３への書き込みや消去動作においてエラー（ハードウェア的に検出可能）が発生した場合には、コンソール部２４に移動局装置１０の修理が必要である旨を表示して処理を停止する。

また、上記ダウンロードが完了した時点と更新が完了した時点の双方にて、データ誤り（チェックサム）の検出を行い、問題があれば再試行することにより、更新時の事故を最低限に抑えることができる。

以上はダウンロードバッファ４４に格納可能な１回分のダウンロード処理及びその更新処理を述べたが、ダウンロードバッファ４４のサイズに制限があるため、１回の更新では必ずしも制御ソフトウェア４３の全体が最新バージョンになるとは限らない。即ち、あるバージョンの移動局装置１０が最新バージョンとなるためには数回にわたるモジュールの更新を要する場合がある。この場合は、移動局装置１０は上記のダウンロード及び更新の処理を繰り返すことでダウンロードバッファ４４のサイズを越える様な制御ソフトウェア全体の更新が可能となる。

例えば移動局装置１０は、ある制御ソフトウェアの更新完了後に再びステップＳ４１のバージョン比較要求処理へ移行することにより、上記複数回の更新が必要であったり、又はある制御ソフトウェアのダウンロード中に該制御ソフトウェアの最新版が更新されていた様な場合であっても、これを速やかに再更新することが可能である。この場合の制御ソフトウェア４３は、更新を行った直後の場合には、まずバージョン比較要求処理を行うように作り込まれる。更新直後であるか否かの状態はバッテリバックアップＲＡＭ３４に記録しておく。もしその内容が失われた場合は、バージョン比較要求を行わずに通常の運用処理を開始する。この場合は更新が遅れることになるが、移動局装置１０の動作に支障はない。

図９は実施の形態による更新判定処理のフローチャートである。本実施の形態では、上記制御ソフトウェア４３の更新処理中は移動局装置１０に対する一切の操作を受け付けないようにするが、電池残量の不足や電池の取り外しによって更新処理が中断してしまうことは避けられない。このため移動局装置１０が起動（電源投入等）した時には、制御ソフトウェア４３を起動する前に、それが正しく動作可能であるか否か、即ち、更新処理の途中でなかったか否かを判定するために、まずはこの更新判定処理を行う。

ステップＳ１１では最新のバージョン管理情報が既知か否かを判別する。最新のバージョン管理情報の所在については、バッテリバックアップＲＡＭ３４のワークエリア４５に記憶されており、通常は記録が残っているので、この判別は既知となる。しかし、バックアップ電池の残量が不足して記録が失われた様な場合にはステップＳ１２で最新のバージョン管理情報を探す。

最新のバージョン管理情報を見つけるには、まずバージョン管理情報を格納している２つのセクタの先頭領域（バージョン番号欄）を調べる。いずれかのセクタが０ＦＦＦＦＦＦＦＦＨ（消去状態）であれば、そうでない方のセクタに最新のバージョン管理情報が存在する。また双方共に０ＦＦＦＦＦＦＦＦＨでない時は、バージョン番号の値の大きい方に存在する。こうして、一方のセクタを特定した後は、先頭から順にバージョン番号を調べていくことにより最新のバージョン管理情報を見つけることができる。この時、セクタの末尾に到達すれば、それが最新のバージョン管理情報であるし、また途中で０ＦＦＦＦＦＦＦＦＨが見つかれば、その手前に最新のバージョン管理情報が存在する。

ステップＳ１３では最新のバージョン管理情報の更新完了フラグ＝０（完了）か否かを判別する。更新完了の場合は図８のステップＳ３４に進み、制御ソフトウェア４３を起動する。また更新完了でない場合は更にステップＳ１４でバージョン書込完了フラグ＝０（完了）か否かを判別する。バージョン書込完了でない場合は図８の更新処理（ステップＳ２１）に制御を移す。なお、上記最新のバージョン管理領域は既知であるから、上記ステップＳ２１に制御を移す代わりに、ステップＳ２５に制御を移しても良い。またバージョン書込完了の場合は更にステップＳ１５でセクタ内の部分的な更新か否かを判別する。既にバージョン書込完了となっているので、この判別は「セクタアドレス」欄と「セクタバッファアドレス」欄の情報を調べることで行える。部分的な更新でない場合は図８のステップＳ３２に進み、更新対象の複数のセクタを書き換える。また部分的な更新の場合は、更にステップＳ１６でセクタバッファ書込完了フラグ＝０（完了）か否かを判別する。セクタバッファ書込完了でない場合は図８のステップＳ２９に進み、セクタバッファ４４ａに更新内容を取得する。またセクタバッファ書込完了の場合は図８のステップＳ３１に進み、更新対象の１セクタを書き換える。

図１１〜図１３は実施の形態によるダウンロード／更新処理のイメージ図（１）〜（３）で、図１１はモジュールＢ，Ｃ，Ｄが更新対象となった場合のタイミングチャートを示している。ダウンロードバッファ４４の大きさによる制限があるため、全モジュールを同時に更新することはできない。ここではモジュールＢを更新した後にモジュールＣ，Ｄを更新する。更新を２段階に分けて行うため、制御ソフトウェア４３のバージョン番号も２回更新されている。

ダウンロードに要する時間は更新対象のサイズに比例する。特に更新対象が大きい場合には、長時間にわたって移動局装置１０が使用できなくなることは避けなければならない。この移動局装置１０は通信経路（チャネル）を１系統しか持たないため、通信中は着信を受け付けることができなくなる。通信中の本装置１０に対して発信すると、話中となってしまう。ダウンロード時も例外ではない。着信を全く妨げないようにすることは不可能であるが、長時間連続して着信不可能とならないようにすることは可能である。ここでは
、転送ブロックの転送毎に通常運用を行う時間（例えば３分以上）を設けることにより、着信が入り込む隙間を空けておく。この間に着信があった場合は、続くダウンロードを中断（延期）する。なお、ユーザはこの間に発信することも可能である。

一例の時間配分を具体的に述べると、この移動局装置１０の無線通信速度は例えば９６００ｂｐｓである。この場合の転送ブロックのサイズは例えば３２ＫＢ以下として、３０秒以内で転送できるようにする。１ブロック転送完了後の休止時間は例えば３分以上とする。もし、このようなブロック分割と休止とを行わない場合は、１ＭＢのダウンロードでは約１５分間にわたって着信が不可能となる。これを３０秒の転送と３分の休止の繰り返しとすると、ダウンロード完了までには約１１２分かかってしまうが、一般にこの様なソフトウェア更新の遅れは問題とはならない。むしろ、多くの場合に、加入者は最初に話中であった時には１〜３分程度待って発信し直すことを考慮すると、３分以上の休止時間を設けることで装置運用上の悪影響は少ないと言える。

また、ユーザの発／着信操作を妨げないようにするためには、ダウンロード中（ブロック転送中）であってもキー入力等を受け付けるようにして、キー入力操作された時には速やかにダウンロードを中断することが好ましい。

また、ダウンロードによる通信中は、待ち受け状態であっても大幅に消費電力が上昇する。ダウンロードによって装置１０の公称の待ち受け時間が短くなることは好ましくないため、ダウンロードによって電池を消費しないように、好ましくは移動局装置１０が充電装置から外された時にはダウンロードを中断する。

上記様々な理由でダウンロードが中断された場合には、その続きから再開できるようにすると無駄が少ない。これを簡単に実現するため、ダウンロード対象を小さな転送ブロックに分割して転送している。中断されたダウンロードの再開は転送ブロックの単位で行う。再開する転送ブロックを決めるための進行状況はバッテリバックアップＲＡＭ３４において記録・管理する。その内容が失われた場合には、始めからやり直す。なお、ダウンロードの中断と再開によって転送ブロックの抜けが発生した様な場合は、ダウンロードバッファ４４におけるチェックサムの検査により誤りを検出できる。

図１２は１段階目のモジュールＢの更新処理のイメージを示している。なお、図では稼働中のソフトウェアに網点を付記してある。旧モジュールＢを含む現行の制御ソフトウェア４３によって新しいモジュールＢをダウンロードした後、現行の制御ソフトウェア４３を一旦停止し、この間に更新ソフトウェア４１がモジュールＢを更新する。モジュールＢの更新が完了した時点で制御ソフトウェア４３のバージョン番号を更新し、制御をモジュールＢが更新された新しい制御ソフトウェア４３に戻す。

図１３は２段階目のモジュールＣ，Ｄの更新処理のイメージを示している。モジュールＣ，Ｄはダウンロードバッファ４４に収まる大きさであるため、同時に更新できる。旧モジュールＣ，Ｄを含む現行の制御ソフトウェア４３によって新しいモジュールＣ，Ｄをダウンロードした後、現行の制御ソフトウェア４３を一旦停止し、この間に更新ソフトウェア４１がモジュールＣ，Ｄを更新する。モジュールＣ，Ｄの更新が完了した時点で制御ソフトウェア４３のバージョン番号を更新し、制御をモジュールＣ，Ｄが更新された新しい制御ソフトウェア４３に戻す。なお、上記複数のモジュールＣ，Ｄを同時に更新できる機能を利用して、該複数のモジュールＣ，Ｄにまたがる様な大規模なソフトウェア変更を制御ソフトウェア４３に加えることも可能となる。

本実施の形態によれば、ソフトウェア供給装置５０は各移動局装置１０からのブロック転送要求に応じて対応する転送ブロックを送信するだで良く、各移動局装置１０における
更新の進行状況等は各々の移動局装置１０が自分自身で管理する。従って、ソフトウェア供給装置５０の処理負荷を大幅に抑えることができる。また移動局装置１０からソフトウェア供給装置５０に対して要求を出し、それに対する応答によって更新対象を受け取る方法は、網側に一斉通知の仕組みを必要としないため、通信システム全体に関わるような変更を加える必要はなく、移動局装置１０及び対応するソフトウェア供給装置５０をシステムに追加するだけで、スムーズな導入が期待できる。

なお、上記実施の形態ではＴＤＭＡ方式による移動通信システムへの適用例を述べたが、本発明は他の様々な通信方式（ＣＤＭＡ等）の移動通信システムにも適用できる。また、この様な大規模な移動通信システムのみならず、本部局と複数の無線端末局とが無線接続可能な他の一般の無線システム（業務用無線通信システム等）にも適用できる。

また、上記本発明に好適なる実施の形態を述べたが、本発明思想を逸脱しない範囲内で各部の構成、制御、及びこれらの組合せの様々な変更が行えることは言うまでも無い。

本発明の原理を説明する図である。 実施の形態による移動通信システムの構成を示す図である。 実施の形態による移動局装置のメモリマップを説明する図（１）である。 実施の形態による移動局装置のメモリマップを説明する図（２）である。 実施の形態による移動局装置のメモリマップを説明する図（３）である。 実施の形態によるダウンロード処理のフローチャート（１）である。 実施の形態によるダウンロード処理のフローチャート（２）である。 実施の形態による更新処理のフローチャートである。 実施の形態による更新判定処理のフローチャートである。 実施の形態による転送ブロックのイメージ図である。 実施の形態によるダウンロード／更新処理のイメージ図（１）である。 実施の形態によるダウンロード／更新処理のイメージ図（２）である。 実施の形態によるダウンロード／更新処理のイメージ図（３）である。 従来技術を説明する図である。

符号の説明

１０ 移動局装置
１１ 通信制御部
１２ 送信部
１３ 送／受分波スイッチ（Ｔ／Ｒ）
１４ アンテナ
１５ 受信部
１６ 周波数シンセサイザ（ＳＹＮ）
１７ コーデック（ＣＤＣ）
１８ ベースバンド処理部（ＢＢＰ）
１９ マイク（ＭＩＣ）
２０ レシーバ（ＲＣＶ）
２１ 発音体
２２ ＣＰＵ
２３ 主メモリ（ＭＥＭ）
２４ コンソール部（ＣＳＬ）
２５ バッテリー部
２６ 充電用端子
２７ 共通バス
３２ マスクＲＯＭ
３３ フラッシュＲＯＭ
３４ バッテリバックアップＲＡＭ
４１ 更新ソフトウェア
４２ バージョン管理領域
４３ 制御ソフトウェア
４４ ダウンロードバッファ
４５ ワークエリア
５０ ソフトウェア供給装置
５１ ＣＰＵ
５２ 主メモリ（ＭＥＭ）
５３ ディスク装置（ＤＳＫ）
５４ 通信制御部（ＣＩＦ）
５５ シリアルインタフェース部（ＳＩＦ）
５６ 共通バス
６０ 保守端末
１００ 公衆網（ＰＳＴＮ）
１０１ 移動体交換局（ＭＳＣ）
１０２ 基地局制御装置（ＢＳＣ）
１０３ 基地局（ＢＴＳ）

Claims (17)

1. ディジタル信号を送受信可能な無線通信部と、
   無線通信制御を含む装置の運用に係る制御ソフトウェア及び該制御ソフトウェアの更新処理を行う更新ソフトウェアを格納する主メモリと、
   前記主メモリの各ソフトウェアに従って動作するＣＰＵと、
   更新用ソフトウェアを一時的に格納するバッファメモリとを備え、
   ＣＰＵは、現用の制御ソフトウェアの制御下で無線を介してダウンロードされた更新用ソフトウェアをバッファメモリに蓄積して後、前記更新ソフトウェアの制御下で現用の制御ソフトウェアの対応部分を前記バッファメモリに蓄積した更新用ソフトウェアで更新し、しかる後制御を更新後の制御ソフトウェアに戻すことを特徴とする無線端末装置。
2. バッファメモリのサイズは制御ソフトウェアのサイズよりも小さく、かつ更新用ソフトウェアのサイズよりも大きいことを特徴とする請求項１に記載の無線端末装置。
3. 制御ソフトウェアは各単独で更新可能な複数のモジュールに分割されていると共に、ＣＰＵは各モジュールに対するダウンロードと更新の処理を順次繰り返すことにより複数のモジュールを更新することを特徴とする請求項２に記載の無線端末装置。
4. 更新用ソフトウェアは所定サイズのブロックに分割されていると共に、ＣＰＵはブロック単位でダウンロードを要求し、所要サイズ分の更新用ソフトウェアを順次バッファメモリに蓄積することを特徴とする請求項２又は３に記載の無線端末装置。
5. ＣＰＵはブロックデータの転送履歴を管理すると共に、ブロックデータのダウンロード中に所定のイベントが発生した場合はブロックデータのダウンロード処理を中断することを特徴とする請求項４に記載の無線端末装置。
6. 主メモリの制御ソフトウェアを記憶する部分と、バッファメモリとがフラッシュＲＯＭにより構成されていることを特徴とする請求項１に記載の無線端末装置。
7. 無線端末装置と通信を行う通信手段と、
   該無線端末装置が、記憶している通信機能に関する第２の制御ソフトウェアの制御に基づいてダウンロードを行うソフトウェアであって、該第２の制御ソフトウェアの少なくとも一部とおきかえられる、該無線端末装置の無線通信機能に関する第１の制御ソフトウェアを記憶する記憶手段と、を備えたことを特徴とするソフトウェア供給装置。
8. 無線端末装置と通信を行う通信手段と、
   該無線端末装置によってダウンロードされる制御ソフトウェアを記憶するメモリと、を備え、
   前記通信手段は、記憶した該制御ソフトウェアの送信の前に、記憶した該制御ソフトウェアを送信するための分割ブロック数を該無線端末装置に通知すること、を特徴とするソフトウェア供給装置。
9. ソフトウェア供給装置と通信を行う無線通信手段と、
   現用の制御ソフトウェアと、該現用の制御ソフトウェアの更新を開始する更新ソフトウェアとを記憶する記憶手段と、
   該ソフトウェア供給装置から制御ソフトウェアをダウンロードして、該メモリに記憶した制御ソフトウェアを該ダウンロードした制御ソフトウェアにより更新するが、その際、更新ソフトウェアは更新しないようにする制御手段と、を備えたことを特徴とする無線端末装置。
10. 前記更新ソフトウェアは、現用の制御ソフトウェアとは別個に前記記憶手段に記憶したことを特徴とする請求項９記載の無線端末装置。
11. ソフトウェア供給装置と通信を行う無線通信手段と、
    現用の制御ソフトウェアを記憶する記憶手段と、
    自装置の電源状態に基づいて、該制御ソフトウェアの更新のために前記ソフトウェア供給装置と通信を行うことを抑制する制御手段と、を備えたことを特徴とする無線端末装置。
12. ソフトウェア供給装置と通信を行う無線通信手段と、
    現用の制御ソフトウェアを記憶する記憶手段と、
    待受け状態において前記ソフトウェア供給装置と通信するように制御する制御手段と、を備えたことを特徴とする無線端末装置。
13. ソフトウェア供給装置と通信を行う無線通信手段と、
    現用の制御ソフトウェアを記憶する記憶手段と、
    着信に対する応答操作を検出した場合に、該ソフトウェア供給装置からの制御ソフトウェアのダウンロードを中断する制御手段と、を備えたことを特徴とする無線端末装置。
14. 制御ソフトウェアを送信する際に、分割ブロック数Ｎを通知するソフトウェア供給装置から該制御ソフトウェアを無線回線を介してダウンロードする無線端末装置において、
    現用の制御ソフトウェアを記憶する記憶手段と、
    記憶した該制御ソフトウェアを更新する際に、前記無線回線を介して分割された複数の制御ソフトウェアを受信するために、前記ソフトウェア供給装置に対して通知されたＮ回にわたり要求を行う制御手段と、を備えたことを特徴とする無線端末装置。
15. ソフトウェア供給装置と通信を行う無線通信手段と、
    現用の制御ソフトウェアを記憶する記憶手段と、
    記憶した該制御ソフトウェアの更新のために、分割された制御ソフトウェアブロックのダウンロードを開始する前に、分割数に関する情報を前記ソフトウェア供給装置から受信する受信手段と、を備えたことを特徴とする無線端末装置。
16. ソフトウェア供給装置と通信を行う無線通信手段と、
    現用の制御ソフトウェアを記憶する記憶手段と、
    該ソフトウェア供給装置から制御ソフトウェアをダウンロードし、記憶した前記制御ソフトウェアの対応部分を消去してから、該ダウンロードした制御ソフトウェアを前記記憶手段に記憶するように制御する制御手段と、を備えたことを特徴とする無線端末装置。
17. ソフトウェア供給装置と通信を行う無線通信手段と、
    現用の制御ソフトウェアを記憶する記憶手段と、
    該ソフトウェア供給装置から制御ソフトウェアをダウンロードし、記憶した前記制御ソフトウェアを該ダウンロードした制御ソフトウェアで更新する間の自端末装置に対する操作を受けつけないように制御する制御手段と、を備えたことを特徴とする無線端末装置。

Images