少なくとも1個のプロトコル層RR、GMMを含む通信システムに従い動作する通信ネットワークであって、-前記通信システムを用いて前記通信ネットワーク内での情報交換を管理すべく設定された少なくとも1個の再設定可能な無線端末UE/MSと、-前記再設定可能な無線端末UE/MSとの情報交換を管理すべく設定された少なくとも1個のノードBSC、RNC、SGSNとを含む通信ネットワークであって、-前記少なくとも1個のノードが、前記通信ネットワークの前記プロトコル層RR、GMMを用いるべく設定されたサーバエンティティOTAサーバを含み、且つ前記無線端末MSを設定するのに適した少なくとも一組のプロトコルスタックの要素を実装すべく設定された一組の基本ソフトウェアモジュールを含み、-前記無線端末UE/MSが、前記サーバエンティティの前記プロトコル層RR、GMMに対応する各々のプロトコル層を用いるべく設定されたクライアントエンティティOTAクライアントを含み、-前記サーバおよび前記クライアントには、前記無線端末UE/MSを少なくとも部分的に設定する前記基本ソフトウエアモジュールの組の少なくとも1個のモジュールをダウンロードすべく、前記プロトコル層RR、GMMを用いて前記無線端末UE/MSと前記ノードBSC、RNC、SGSNとの間の地上波接続を管理することが可能な地上波ソフトウエアモジュールが各々提供されていることを特徴とする通信ネットワーク。-前記サーバエンティティOTAサーバが、前記プロトコル層RR、GMMの少なくとも一組の変更されたメッセージを含み、-前記クライアントエンティティOTAクライアントが、前記標準化されたプロトコル層RR、GMMの更に少なくとも一組の変更されたメッセージを含み、且つ前記サーバエンティティOTAサーバおよび前記クライアントエンティティOTAクライアントに各々関連付けられた前記変更メッセージの組が、前記地上波接続を管理すべく設定されていることを特徴とする、請求項1に記載のネットワーク。-無線アクセスネットワークGERANUTRANおよびコアネットワークを含み、且つ-前記プロトコル層GMMが前記コアネットワークのプロトコル層であることを特徴とする、請求項1に記載のネットワーク。-無線アクセスネットワークGERANUTRANおよびコアネットワークを含み、且つ-前記プロトコル層RRが前記無線アクセスネットワークGERANUTRANのプロトコル層であることを特徴とする、請求項1に記載のネットワーク。-前記無線アクセスネットワークGERANUTRANが無線コントローラBSC、RNCを含み、-前記プロトコル層が前記無線コントローラBSC、RNCのプロトコル層であることを特徴とする、請求項4に記載のネットワーク。前記無線アクセスネットワークが、第二世代ネットワークGERANに従って動作する、請求項3に記載のネットワーク。前記無線アクセスネットワークが、第三世代ネットワークUTRANに従って動作する、請求項3に記載のネットワーク。前記地上波接続が、前記通信ネットワークの汎用チャネルを介して確立されることを特徴とする、請求項1に記載のネットワーク。前記地上波接続が、前記通信ネットワークの無線チャネルを介して確立されることを特徴とする、請求項1に記載のネットワーク。前記通信システムが、音声通話、データ送信、および前記基本ソフトウェアモジュールの前記少なくとも1個のモジュールのダウンロードの間での優先順位を管理すべく設定されていることを特徴とする、請求項1に記載のネットワーク。前記地上波ソフトウェアモジュールが、音声通話の間に、前記基本ソフトウェアモジュールの前記少なくとも1個のモジュールをダウンロードすべく設定されていることを特徴とする、請求項1に記載のネットワーク。前記基本ソフトウェアモジュールの組が、更なる通信システムにより前記無線端末MSを少なくとも部分的に設定するのに適していることを特徴とする、請求項1に記載のネットワーク。-前記無線端末MSが、前記更なる通信システムに対して少なくとも測定を実行すべくプロトコルスタック層を含んでいることを特徴とする、請求項12に記載のネットワーク。少なくとも1個のプロトコル層RR、GMMを含む通信システムに従い動作する通信ネットワークに属する少なくとも1個の再設定可能な無線端末UE/MSを設定する方法であって、前記無線端末が、前記通信システムを用いて、前記通信ネットワークの少なくとも1個のノードと情報を交換すべく設定されていて、-前記通信ネットワークの前記少なくとも1個のノードに、前記プロトコル層RR、GMMを用いるべく設定されたサーバエンティティOTAサーバを関連付けて、前記無線端末MSを設定するのに適した少なくとも一組のプロトコルスタックの要素により前記無線端末UE/MSを設定するための一組の基本ソフトウェアモジュールを含めるステップと、-前記無線端末MSに、前記サーバエンティティOTAサーバの前記プロトコル層RR、GMMに対応する各々のプロトコル層を用いるべく設定されたクライアントエンティティOTAクライアントを関連付けるステップと、-前記プロトコル層を用いて前記無線端末UE/MSと前記サーバOTAサーバとの間に地上波接続を確立するステップと、-前記無線端末UE/MSを少なくとも部分的に設定すべく前記サーバOTAサーバから前記無線端末UE/MSへ前記基本ソフトウエアモジュールの組の少なくとも1個のモジュールをダウンロードするステップとを含む方法。前記地上波接続の確立が、前記プロトコル層の変更されたプロトコルメッセージを交換する前記プロトコルステップの各々を含む一組のプロトコルステップを含むことを特徴とする、請求項14に記載の方法。前記変更されたプロトコルメッセージの交換が、-以下のフィールドの組、すなわち-メッセージの種類を識別する第一のフィールドメッセージ種別と、-メッセージが示す無線端末MSを識別する第二のフィールドOTAクライアントIDと、-データ情報を含む第三のフィールドとを各々含むメッセージの交換を含むことを特徴とする、請求項15に記載の方法。前記プロトコルステップの組が以下のステップ、すなわち、a前記少なくとも1個の基本ソフトウェアモジュールのダウンロード要求を実行するステップと、b前記クライアントOTAクライアントおよび前記サーバOTAサーバを相互に認証するステップと、c前記サーバOTAサーバから前記少なくとも1個のダウンロード可能な基本ソフトウェアモジュールを前記無線端末UE/MSが受信する能力を調べるステップと、dダウンロードオプションに関する情報を提供するステップと、e前記少なくとも1個の基本ソフトウェアモジュールをブロックに分割するステップと、f前記ブロックを前記サーバOTAサーバから、前記少なくとも1個の無線端末UE/MSへ送信するステップと、g前記少なくとも1個のモジュールをプロトコルスタックの一組の要素により再設定すべく前記ブロックを再構築して、前記要素の組をテストするステップと、h前記要素の組を前記無線端末UE/MSにインストールするステップとを含むことを特徴とする、請求項15に記載の方法。前記プロトコルステップの組が、前記無線端末UE/MSへダウンロードされた前記ブロックの構造を監視するステップを含むことを特徴とする、請求項17に記載の方法。前記プロトコルステップの組が、地上波接続の実行に許される時間を制限する一組のタイマーT100、T200、T300、T400、T500、T101、T201、T301、T302、T401、T501を管理するステップを含むことを特徴とする、請求項17に記載の方法。前記プロトコルステップの組が、-各々のプロトコルステップに対して少なくとも一対のタイマー、すなわち前記無線端末UE/MSにより実行されるプロトコルステップを監視する第一のタイマーおよび前記サーバOTAサーバにより実行されるプロトコルステップを監視する第二のタイマーであって、前記1個のプロトコルステップが開始された時点で開始され、前記プロトコルステップが完了した時点で停止される各々のタイマーを割当てるステップを含むことを特徴とする、請求項17に記載の方法。前記相互認証ステップがチャレンジ応答方式に基づいていることを特徴とする、請求項17に記載の方法。前記少なくとも1個のモジュールをブロックに分割する前記ステップが、1~2kByteのサイズを有するブロックに分割するステップを含み、前記ブロックを送信するステップがウィンドウプロトコルを管理して、前記少なくとも1個の基本ソフトウェアモジュールが分割されたブロックのサイズにウィンドウサイズを合致させるステップを含む、請求項17に記載の方法。前記無線端末に前記要素の組をインストールする前にライセンスが要求されることを特徴とする、請求項17に記載の方法。前記少なくとも1個の基本ソフトウェアモジュールが、前記無線端末UE/MSにダウンロードされる前に、鍵により暗号化されることを特徴とする、請求項14に記載の方法。少なくとも二組の基本ソフトウェアモジュールを前記再設定可能な無線端末UE/MSに保存するステップを更に含むことを特徴とする、請求項14に記載の方法。前記少なくとも1個のモジュールの組をダウンロードする前記ステップが、-更なる通信システムにより前記無線端末MSを少なくとも部分的に設定するのに適した一組の基本ソフトウェアモジュールをダウンロードするステップを含むことを特徴とする、請求項14に記載の方法。請求項14~26のいずれかに記載の方法を実行することにより設定可能である、再設定可能な無線端末UE/MS。請求項14~26のいずれかに記載の方法を実行することにより再設定可能な無線端末UE/MS設定するサーバエンティティOTAサーバを含むネットワークノード。少なくとも1個のコンピュータのメモリにロード可能であって、請求項14~26に記載のステップのいずれかを実行するソフトウェアコード部分を含む、コンピュータプログラム生成物またはコンピュータプログラム生成物のコンピュータプログラムの組。要約すれば、出願人は公知の従来技術について以下の点に注目する。-例えば新規のノードやインターフェースの追加、および標準により定義されたデータのシグナリングおよび転送プロトコルの変更等、無線リソースの非効率的な利用につながるネットワークノードに対する大幅な変更なしにはソフトウェアをダウンロードする課題が解決されない。-システム間ハンドオーバーの管理のために再設定可能な端末を利用することができない。従って、ネットワークノードおよび関連プロトコルを大幅に変更することなく無線端末を設定する基本ソフトウェアをダウンロードする方法および通信ネットワークを提供することが本発明の目的である。更に、設定可能な端末を用いてシステム間ハンドオーバー手続きを可能にする方法および通信ネットワークを提供することも本発明の更なる目的である。上述の目的は、添付の請求項に記載されている方法および通信ネットワークにより達成される。更に、本発明の目的は、コンピュータプログラム生成物またはコンピュータプログラム生成物の組により達成され、当該生成物は少なくとも1個のコンピュータのメモリにロード可能であって、請求項に従い当該生成物がコンピュータ上で実行された場合に本発明の方法のステップを実行するソフトウェアコード部分を含んでいる。以下で用いるように、そのようなコンピュータプログラム生成物への参照は、本発明の方法の実行を調整すべくコンピュータシステムを制御する命令を含むコンピュータ可読媒体への参照と等価である。少なくとも1個のコンピュータとの表現は明らかに、本発明の方法が分散モジュール方式で実装される可能性を強調することを意図している。好適な実施形態において、無線端末を再設定する基本ソフトウェアのダウンロードは、標準に関して、端末内および、例えばネットワークのBSC基地局コントローラまたはRNC無線ネットワークコントローラの無線コントローラ等、ネットワーク内の少なくとも1個のノード内の無線プロトコルスタックの単一の層だけを変更することにより実現される。本発明によれば、変更された層のプロトコルは、SDR-Forumから提供される推奨事項と整合している。本発明の好適な実施形態によれば、そこから基本ソフトウェアをダウンロードが可能であるサーバは、ネットワークの無線コントローラ、例えばBSCまたはRNC等に常駐している。本発明がもたらす利点には以下のものがある。-ソフトウェアのダウンロードサービスは透過的であり、他の任意のシグナリングおよびトラフィックデータフローとしてネットワークから見える。-既存且つ将来の標準の全ての特徴を完全に利用することにより、無線リソースの効果的且つ柔軟な利用が可能である。-呼を中断することなく基本ソフトウェアをダウンロードするために、例えば回線呼の最中にパケット接続を確立することが可能である。-異なるデータフロー同士を区別して、それらの優先順位例:音声、データおよびソフトウェアのダウンロードを管理することが可能である。例えば、音声通話の優先順位がソフトウェアのダウンロードの優先順位より高い場合、ソフトウェアのダウンロード自体を一時的に中断して、逐次前記ダウンロードを再開することができる。更に、本発明は、再設定可能端末を利用してシステム間ハンドオーバーの管理を可能にする。実際に、本発明の好適な実施形態によれば、サポート対象システム上で測定を実行するための最小限の機能だけが端末の物理層に実装されていれば十分である。例えば、GSM/GPRSシステムにより動作すべく設定されていて、UMTSシステムへのシステムハンドオーバーを管理する準備が整っている端末を想定する。本発明によれば、GSM/GPRSシステムの無線インターフェースの全体的なプロトコルスタックにより設定されている端末は、UMTSシステムの能力測定を実行するための最小限の物理層機能だけを備えている。システム間ハンドオーバーは、GSM/GPRS無線チャネルを介してUMTS基本ソフトウェア全体を端末内にダウンロードし、UMTSシステムに従い端末を再設定して、GSM/GPRSシステム上で能力測定を実行するための最小限の物理層機能を提供することにより管理される。本発明を、その好適な、ただし限定的ではない実施形態の添付図面を参照しながら以下に開示する。全ての図を通じて、同等であるか、または実質的に等価な機能を実装する構成要素を示すために同一参照番号を用いている。図2を参照するに、再設定可能な端末または移動局MS、基地送受信局BTSすなわちBTSノード、および基地局コントローラBSCすなわちBSCノードを含むGSM/GPRSシステムのネットワークアーキテクチャを示す。ネットワークは更に、例えば、図2に示していない移動スイッチングセンターMSCおよび/またはサービングGPRSサポートノードSGSNおよび/またはゲートウェイGPRSサポートノードGGSN等のコアネットワークノードを含んでいる。端末MSは、BSCノードに接続されているBTSノードに、無線インターフェースを介して接続されている。本発明の好適な実施形態によれば、端末MSは、OTAクライアントと呼ばれる第一のエンティティと、無線リソースプロトコルRRと呼ばれる公知の種類の第二のエンティティとを含んでいる。OTAクライアントは、無線リソースプロトコルRRと同一プロトコルレベルまたは層にあってこれと協働する。RRエンティティは、例えば、GSM/GPRS標準ETSI04.18に従い動作し、以下に開示するように、基地局コントローラBSC内でOTAクライアントおよびRR対応エンティティと通信するための機能を含んでいる。OTAクライアントは、基本ソフトウェアの全体または一部を、OTAサーバと呼ばれる基地局コントローラBSC内のOTA対応エンティティからダウンロードする手続きを完全に管理することが可能なソフトウェアモジュールを含んでいる。BSCは、OTAサーバと呼ばれる第一のエンティティ、および無線リソースプロトコルRRと呼ばれる公知の種類の第二のエンティティを含んでいる。OTAサーバは、同一プロトコルレベルにあって、無線リソースプロトコルRRと協働する。RRエンティティは、例えば、GSM/GPRS標準ETSI04.18に従い動作し、以下に開示するように、移動端末MS内でOTAサーバおよびRR対応エンティティと通信するための機能を含んでいる。OTAサーバは、基本ソフトウェアの全体または一部をOTAクライアントへダウンロードする手続きを完全に管理することが可能なソフトウェアモジュールを含んでいる。OTAサーバは更に、基本ソフトウェアを含んでいるか、または、これを修復することが可能である。OTAサーバのアーキテクチャは、以下に開示するように、アクティブなダウンロードセッションを有する各OTAクライアントに対してクライアントコンテキストと呼ばれるコンテキストを提供する。図3に、本発明に従い設定された端末MSを示す。端末MSは、GSM/GPRSプロトコルの上位層および下位層を含んでいる。下位層はRAT無線アクセス技術GSM/GPRSと呼ばれ、GSM/GPRS標準に従いOTAクライアント、無線リソースRR、物理L1およびDLデータリンクL2の各エンティティを含んでいる。端末MSは、更なる標準、例えばUMTS標準に従い物理層L1Uを含み、少なくとも当該更なる標準に準拠して層1の測定を実行する機能を更に含んでいる。開示した端末MSは、以下に開示するように更なる標準の基本ソフトウェアをダウンロードすることにより再設定可能である。本発明の好適な実施形態で想定されているように、基本ソフトウェアは一組の基本ソフトウェアモジュール、好適には所定の通信システムに従い端末MSを設定する複数のソフトウェアモジュールを含んでいる。本発明は、例えば更に所定の通信システムに従って無線端末MSを設定するために用いるプロトコルスタックを構成する全ての基本ソフトウェアモジュールのダウンロードを可能にする。当業者には理解されるように、本発明の更なる実施形態によれば、使用中の通信システムまたは別の通信システムに対応するプロトコルスタックの一部だけで構成されたソフトウェアモジュールをダウンロードすることも可能である。そのような更なる実施形態は、例えば、端末MSに新規機能、更新版またはバグ修正を加える目的に有用であろう。図4を参照するに、端末MSにおけるOTAクライアントの状態遷移図を示す。状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。本発明の好適な実施形態によれば、OTAクライアントの状態およびその間の遷移は以下の通りである。-アイドル状態:アクティブなソフトウェアダウンロード手続きが存在しない場合、OTAクライアントはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、OTAクライアントはこの状態に戻る。-ダウンロード開始状態:ネットワークが基本ソフトウェアのダウンロード手続きの開始を要求した場合、OTAクライアントはこの状態に入ってタイマーT100を起動する。状態遷移が生じた場合にはタイマーT100は停止される。状態遷移の前にタイマーT100の時刻に過ぎた場合、OTAクライアントはアイドル状態に戻る。-相互認証状態:この状態で、OTAクライアントはOTAサーバとの相互認証を実行する。OTAサーバから認証要求が来たならば、OTAクライアントはこの状態に入る。OTAクライアントはタイマーT200を起動する。タイマーT200は状態遷移が生じた場合に停止される。状態遷移の前にタイマーT200の設定期限が過ぎたか、または認証が失敗した場合、OTAクライアントはアイドル状態に戻る。-能力要求状態:この状態で、OTAクライアントはOTAサーバに自身の能力を提示する。OTAクライアントは、OTAサーバが自身の能力を要求した場合にこの状態に入る。OTAクライアントがタイマーT300を起動する。タイマーT300は、状態遷移が生じた場合に停止される。状態遷移の前にタイマーT300設定期限が過ぎた場合、OTAクライアントはアイドル状態に戻る。-ダウンロード受理状態:この状態で、OTAクライアントは、OTAサーバが受信した情報に従いダウンロードを続けるか否かを決定する。OTAクライアントは、OTAサーバから実行すべきダウンロードプロファイルを受信したならばこの状態に入る。受信したプロファイルが拒否された場合、OTAクライアントはアイドル状態に戻る。-ソフトウェアダウンロード状態:この状態で、OTAクライアントは、ソフトウェアのダウンロードを実行する。ダウンロードプロファイルが受理されたならば、OTAクライアントはこの状態に入る。OTAクライアントはタイマーT400を起動する。タイマーT400は、OTAサーバから受信された各ソフトウェアブロックでリセットされて再開される。タイマーT400は、状態遷移が生じたならば停止される。状態遷移の前にタイマーT400の設定期限が過ぎたか、またはダウンロードが失敗した、あるいはダウンロードされたソフトウェアが能力に準拠していない場合、OTAクライアントはアイドル状態に戻る。-インストール状態:この状態で、OTAクライアントは、OTAサーバに対しライセンス要求を送信して基本ソフトウェアをインストールする。OTAクライアントは、ダウンロード終了時点でこの状態に入る。OTAクライアントは、タイマーT500を起動する。状態変更が生じた場合、タイマーT500は停止される。状態変更の前にタイマーT500の設定期限が過ぎたか、またはライセンスが受理されなかった場合、OTAクライアントはアイドル状態に戻る。-現場テスト状態:この状態で、OTAクライアントは、OTAサーバが受信したいくつかのテストベクトルを用いて、ダウンロードされたソフトウェアに対していくつかのテストを実行する。基本ソフトウェアがインストールされたならば、OTAクライアントはこの状態に入る。一旦テストが終了したならば、OTAクライアントはアイドル状態に戻る。図5を参照するに、OTAサーバが管理するクライアントコンテキストの状態遷移図を示す。先に述べたように、状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。クライアントコンテキストの状態および相対遷移は以下の通りである。-アイドル状態:アクティブなソフトウェアダウンロード手続きが存在しない場合、OTAサーバが管理するOTAクライアントコンテキストはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、OTAクライアントコンテキストはこの状態に戻る。-ダウンロード開始状態:この状態で、OTAクライアントコンテキストはOTAクライアントにダウンロードを実行するよう指示する。基本ソフトウェアのダウンロードを実行することが必要な場合、OTAクライアントコンテキストはこの状態に入ってタイマーT100を起動する。状態遷移の前にタイマーT100は停止される。状態遷移の前にタイマーT100の時刻に過ぎた場合、OTAクライアントコンテキストはアイドル状態に戻る。-相互認証状態:この状態で、OTAクライアントコンテキストは自身を認証し、OTAクライアントに対して自身を認証するよう要求する。OTAクライアントからダウンロード確認を受信したならば、OTAクライアントコンテキストはこの状態に入る。OTAクライアントコンテキストはタイマーT201を起動する。タイマーT201は状態遷移が生じた場合に停止される。状態遷移の前にタイマーT201の設定期限が過ぎたか、または認証が失敗した場合、OTAクライアントコンテキストはアイドル状態に戻る。-能力要求状態:この状態で、OTAクライアントコンテキストはOTAクライアントに対しその能力の提示を要求する。認証が完了したならばOTAクライアントコンテキストはこの状態に入る。OTAクライアントコンテキストがタイマーT301を起動する。タイマーT301は、状態遷移が生じた場合に停止される。状態遷移の前にタイマーT301の設定期限が過ぎたか、または能力に起因してダウンロードが不可能な場合、OTAクライアントはアイドル状態に戻る。-ダウンロード受理状態:この状態で、OTAクライアントコンテキストは、ダウンロードプロファイルをOTAクライアントに通知する。OTAクライアントコンテキストは、端末能力を受信して、当該能力が受理されたならばこの状態に入る。OTAクライアントコンテキストがタイマーT302を起動する。タイマーT302は、状態遷移が生じた場合に停止される。状態遷移の前にタイマーT302の設定期限が過ぎたか、または提案されたダウンロードをOTAクライアントが拒否した場合、OTAクライアントコンテキストはアイドル状態に戻る。-ソフトウェアダウンロード状態:この状態で、OTAクライアントコンテキストは、OTAクライアントへのソフトウェアのダウンロードを実行する。ダウンロードプロファイルがOTAクライアントにより受理された場合、OTAクライアントコンテキストはこの状態に入る。OTAクライアントコンテキストは、タイマーT401を開始する。タイマーT401はリセットされて、クライアントから受信された各々の確認応答信号Ackで再開される。状態遷移が生じた場合、タイマーT401は停止される。状態遷移の前にタイマーT401の設定期限が過ぎたか、またはダウンロードが失敗した場合、OTAクライアントコンテキストはアイドル状態に戻る。-インストール状態:この状態で、OTAクライアントコンテキストは、OTAクライアントがダウンロードされたソフトウェアのインストールおよびテストを実行するまで、ライセンス条件をOTAクライアントへ通知して待機する。ダウンロードが終了したならば、OTAクライアントコンテキストはこの状態に入る。OTAクライアントコンテキストがタイマーT501を起動する。状態遷移が生じたならばタイマーT501は停止される。状態遷移の前にタイマーT501の設定期限が過ぎたか、またはライセンスがOTAクライアントにより受理されなかった場合、OTAクライアントコンテキストはアイドル状態に戻る。OTAクライアントコンテキストは、OTAクライアントによるインストールの成功に関する確認応答信号を受信したならば、アイドル状態に戻る。GSM/GPRSの場合、本発明の好適な実施形態において、RRプロトコルは、以下に図6~17を参照しながら詳述するように、新規プロトコルメッセージを導入することにより変更され、関連するフィールドをOTAサーバとOTAクライアントの間で交換される。異なるシステムの場合、当業者には理解されるように、例えばUMTSシステムにおけるRRC無線リソース制御等の無線リソースプロトコルが同様の方法で変更される。以下に、メッセージおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。図6を参照するに、パケットダウンロード要求メッセージの構造を記述している。このメッセージは、基地局コントローラBSC側にある無線リソースRRから端末MS側の無線リソースRRへ送信される。OTAサーバはこのメッセージを用いて、OTAクライアントに対しダウンロードセッションを開始するよう指示する。提供されるフィールドは、GSM/GPRSの場合、少なくとも以下のうち1組である。-メッセージ種別:送信されたメッセージの種別パケットダウンロード要求を識別する。-OTAクライアントID:要求を実行する対象であるOTAクライアントを識別する。-PDCHパケットデータチャネル:ソフトウェアのダウンロードが実行されるネットワークにより割当てられたチャネルを指定する。-RRBP相対予約ブロック期間:標準GPRSで既に定義されている通り、端末MS側の無線リソースRRが応答する無線ブロックを指定する。-要求されたダウンロード:この要素は、ネットワークによる要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。図7を参照するに、パケットダウンロードAckメッセージの構造を記述している。このメッセージはOTAクライアントからOTAサーバへ送信される。OTAクライアントは、このメッセージを用いて、ダウンロードセッションの開始の確認をOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、少なくとも以下のうち1組である。-メッセージ種別:送信されたメッセージの種別パケットダウンロードAckを識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。-OTAクライアントチャレンジ番号:相互認証の第一ステップを実行すべく、OTAサーバが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズム高度暗号化標準を以って暗号化する乱数である。図8を参照するに、パケットダウンロードNackメッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバにダウンロードセッションを開始することができない旨を通知する。提供されるフィールドは、GSM/GPRSの場合、少なくとも以下のうち1組である。-メッセージ種別:送信されたメッセージの種別パケットダウンロードNackを識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。図9を参照するに、パケット認証要求メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、自身の証明をOTAクライアントに通知し、OTAクライアントにそれを確認することが要求する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケット認証要求を識別する。-OTAクライアントID:メッセージを送信するOTAクライアントを識別する。-OTAサーバ応答番号:相互認証の第一のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAサーバにより暗号化される番号である。-OTAサーバチャレンジ番号:相互認証の第二ステップを実行すべく、OTAクライアントが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。-RRBP:標準GPRSで既に定義されているように、端末MS側の無線リソースRRが応答する無線ブロックを指定する。図10を参照するに、パケット認証応答メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、既にOTAサーバを認証した状態で、OTAクライアントは自身の証明をOTAサーバに通知する。GSM/GPRSの場合に提供されるフィールドは、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケット認証応答を識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。-OTAクライアント応答番号:相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAクライアントにより暗号化される番号を識別する。図11を参照するに、パケット能力要求メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、OTAクライアントに対しその再設定可能性オプションを要求する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケット能力要求を識別する。-OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。-RRBP:標準GPRSに既に定義されている通り、端末MS側の無線リソースRRが応答する無線ブロックを指定する。図12を参照するに、パケット能力応答メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントは、自身の再設定可能性オプションをOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケット能力応答を識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。-OTAクライアント能力:端末の再設定可能性オプションを記述する。図13を参照するに、パケットダウンロード記述メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、ダウンロードに関するデータをOTAクライアントに報告する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットダウンロード記述を識別する。-OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。-ダウンロードリスト:各ダウンロードにつきOTAクライアントにより選択された1個の要素を含む。当該フィールドは以下のフィールドを含んでいる。-ダウンロードブロック番号:OTAクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。-支払請求基準:起こり得るダウンロード支払請求に関する基準である。-インストール基準:ソフトウェアのインストールに関する基準である。-RRBP:標準GPRSに既に定義されている通り、端末MS側の無線リソースRRが応答する無線ブロックを指定する。再び図8を参照するに、パケットダウンロード受理メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントがダウンロードを確認する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットダウンロード受理を識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。再び図8を参照するに、パケットダウンロード拒否メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはダウンロードを拒否する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットダウンロード拒否を識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。再び図8を参照するに、パケットライセンス要求メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバに対し、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵を要求する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットライセンス要求を識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。図14を参照するに、パケットライセンス応答メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵をOTAクライアントに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットライセンス応答を識別する。-OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。-復号化鍵:基本ソフトウェアを復号化するために用いられる鍵である。再び図8を参照するに、パケットライセンス受理メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントは、ダウンロードされた基本ソフトウェアが正しく復号化された旨をOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットライセンス受理を識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。再び図8を参照するに、パケットライセンス失敗メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントは、ダウンロードされた基本ソフトウェアが正しく復号化されなかった旨をOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットライセンス失敗を識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。図15を参照するに、パケットテスト記述メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバはOTAクライアントに対し、ダウンロードされた基本ソフトウェアを開始する前に実行すべきテストを指示する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットテスト記述を識別する。-OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。-テストリスト:実行すべき各々のテストについて1個の要素を含み、これは更に以下のフィールドを含んでいる。-テストベクトル:テストの記述を含んでいる。再び図8を参照するに、パケットインストール成功メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功した旨を通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットインストール成功を識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。再び図8を参照するに、パケットインストール失敗メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功しなかった旨を通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別パケットインストール失敗を識別する。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。基本ソフトウェアは、好適な実施形態において、例えば、以下に述べるBlockおよびAckと呼ばれる2種類の基本プロトコルデータユニットすなわちPDUに基づいて公知の種類のウィンドウプロトコルを使用することにより、OTAサーバからOTAクライアントへ送信される。図16を参照するに、基本ソフトウェアが分割される無線ブロックBlockの構造を記述している。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:ブロック種別を識別する。-ブロック番号:無線ブロックのシーケンス番号を識別する。OTAクライアントがこのシーケンス番号を用いて、基本ソフトウェア全体を再構成する。-データ:基本ソフトウェア全体のいくつかの部分を含むフィールドである。図17を参照するに、端末の受信状態を示すために用いるメッセージAckの構造を記述している。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-メッセージ種別:送信されたメッセージの種別Ackを識別する。-Ackビットマップ:基本ソフトウェアが分割された無線ブロックの総数に等しいサイズを有するビットマスクである。各々の無線ブロックについて、当該ブロックが首尾よく受信された場合は1にセットされ、ブロックが受信されたものの損傷しているかまたは全く受信されなかった場合は0にセットされる。本発明の好適な実施形態が想定するRRプロトコルに対する変更は、OTAクライアントと端末MS側の無線リソースRRとの間にプリミティブを導入し、またOTAサーバと基地局コントローラBSC側の無線リソースRRとの間にプリミティブを導入することに基づいている。プリミティブおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。最初に、OTAクライアントと端末MS側の無線リソースRRとの間のプリミティブを記述する。プリミティブダウンロード要求Indは、端末MS側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:要求の実行対象であるOTAクライアントを識別する。-要求されたダウンロード:この要素は、ネットワークにより要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。プリミティブダウンロードAckIndは、OTAクライアントにより端末MS側の無線リソースRRへ送信される。このプリミティブで提供されるフィールドには、以下のものがある。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-OTAクライアントチャレンジ番号:相互認証の第一ステップを実行すべく、OTAサーバが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。プリミティブダウンロードNackIndは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブ認証Reqは、端末MS側の無線リソースRRからOTAクライアントへ送信される。このプリミティブで提供されるフィールドには以下のものがある。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-OTAサーバ応答番号:相互認証の第一のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAサーバにより暗号化される番号である。-OTAサーバチャレンジ番号:相互認証の第二ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。プリミティブ認証Rspは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-OTAクライアント応答番号:相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAクライアントにより暗号化される番号を識別する。プリミティブ能力Reqは、MS側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブ能力Rspは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。-OTAクライアント能力:端末の再設定可能性オプションを記述する。プリミティブダウンロード記述Reqは、端末MS側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-ダウンロードリスト:各ダウンロードにつきOTAクライアントにより選択された1個の要素を含む。当該フィールドは以下のフィールドを含んでいる。-ダウンロードブロック番号:OTAクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。-支払請求基準:起こり得るダウンロード支払請求に関する基準である。-インストール基準:ソフトウェアのインストールに関する基準である。プリミティブダウンロード受理Cnfは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブダウンロード受理Rejは、OTA端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブライセンスReqは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブライセンスRspは、端末MS側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-復号化鍵:基本ソフトウェアを復号化するために用いられる鍵である。プリミティブライセンスCnfは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブライセンスRejは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブテスト記述Reqは、端末MS側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-テストリスト:実行すべき各々のテストについて1個の要素を含み、これは更に以下のフィールドを含んでいる。-テストベクトル:テストの記述を含んでいる。プリミティブインストールCnfは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブインストールRejは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブデータIndは、端末MS側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-基本ソフトウェアが分割された無線ブロックのうちの1個。プリミティブデータReqは、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-Ackの無線ブロック。OTAサーバと基地局コントローラBSC側の無線リソースRRとの間で交換されるプリミティブについて以下に記述する。プリミティブダウンロード開始Indは、OTAクライアントから基地局コントローラ機構BSC側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:要求の実行対象であるOTAクライアントを識別する。-要求されたダウンロード:この要素は、ネットワークにより要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。プリミティブダウンロードAckIndは、基地局コントローラ機構BSC側の無線リソースRRによりOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-OTAクライアントチャレンジ番号:相互認証の第一ステップを実行すべく、OTAサーバが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。プリミティブダウンロードNackIndは、基地局コントローラ機構BSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブ認証Reqは、OTAクライアントから基地局コントローラ機構BSC側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-OTAサーバ応答番号:相互認証の第一のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAサーバにより暗号化される番号である。-OTAサーバチャレンジ番号:相互認証の第二ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。プリミティブ認証Rspは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-OTAクライアント応答番号:相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAクライアントにより暗号化される番号を識別する。プリミティブ能力Reqは、OTAクライアントから基地局コントローラBSC側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブ能力Rspは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。-OTAクライアント能力:端末の再設定可能性オプションを記述する。プリミティブダウンロード記述Reqは、OTAクライアントから基地局コントローラBSC側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-ダウンロードリスト:各ダウンロードにつきOTAクライアントにより選択された1個の要素を含む。当該フィールドは以下のフィールドを含んでいる。-ダウンロードブロック番号:OTAクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。-支払請求基準:起こり得るダウンロード支払請求に関する基準である。-インストール基準:ソフトウェアのインストールに関する基準である。プリミティブダウンロード受理Cnfは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブダウンロード受理Rejは、基地局コントローラ機構BSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブライセンスReqは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブライセンスRspは、OTAクライアントにより基地局コントローラBSC側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-復号化鍵:基本ソフトウェアを復号化するために使用する鍵である。プリミティブライセンスCnfは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブライセンスRejは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブテスト記述Reqは、OTAサーバから基地局コントローラBSC側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-テストリスト:実行すべき各々のテストについて1個の要素を含み、これは更に以下のフィールドを含んでいる。-テストベクトル:テストの記述を含んでいる。プリミティブインストールCnfは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブインストールRejは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。プリミティブデータReqは、OTAサーバから基地局コントローラBSC側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-基本ソフトウェアが分割された無線ブロックのうちの1個。プリミティブデータIndは、基地局コントローラBSC側の無線リソースRRからOTAサーバへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。-OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。-Ackの無線ブロック。図4、5を参照するに、OTAクライアントとOTAサーバとの間での手続き型の対話を、各々のRRが受信した各プリミティブについて、OTAクライアントまたはクライアントコンテキストの状態に従う相対的な挙動を示すことにより記述している。OTAクライアントおよびOTAサーバの挙動はシステムから独立している。OTAクライアントまたはOTAサーバと、各々のRRとの間で交換されたプリミティブはシステムに依存しており、本例によればGSM/GPRSシステムを参照している。以下の記述において、タイマーの開始/停止動作は記述されていない。その理由は、先に述べたように、これらはエンティティの状態と関連付けられているためである。ここで図4を参照するに、OTAクライアントの挙動を記載している。一般に、OTAクライアントIDフィールドがプリミティブを受信しているOTAクライアントの識別子と合致しない場合、当該プリミティブは無視される。OTAクライアントがプリミティブダウンロード要求Indを受信した場合、-アイドル状態であれば、OTAクライアントはダウンロード開始へ進む。-ダウンロード開始状態でなければプリミティブは無視され、手続きは継続されない。-端末がダウンロードを実行することが可能ならば、-乱数RNUMが抽出されて保存される。-OTAクライアントチャレンジ番号フィールド内に抽出された数RNUMの値を含むプリミティブダウンロードAckIndが送信される。-端末がダウンロードを実行することが可能でなければ、プリミティブダウンロードNackIndが送信され、OTAクライアントはアイドル状態に戻る。OTAクライアントがプリミティブ認証Reqを受信した場合、-ダウンロード開始状態でなければプリミティブは無視され、手続きは継続されない。-保存された乱数RNUMが有効でなければ手続きは継続されない。-OTAクライアントは状態相互認証へ進む。-保存された乱数RNUMの値は、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵CIKにより暗号化される。-前段階で暗号化された値がOTAサーバ応答番号フィールドの値と合致しない場合、OTAクライアントはアイドル状態に進み、手続きは継続されない。-OTAサーバチャレンジ番号フィールドの値は、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵CIKクライアント識別鍵により暗号化される。-プリミティブ認証Rspは、OTAクライアント応答番号フィールド内の前段階で暗号化された値と共に送信される。OTAクライアントがプリミティブ能力Reqを受信した場合、-相互認証状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントは能力要求状態に進む。-プリミティブ能力応答が送信される。OTAクライアントがプリミティブダウンロード記述Reqを受信した場合、-能力要求状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントはダウンロード受理状態に進む。-端末がソフトウェアをインストールすることが可能ならば、-プリミティブダウンロード受理Cnfが送信される。-端末がソフトウェアをインストールすることが可能でなければ、-プリミティブダウンロード受理Rejが送信される。-OTAクライアントはアイドル状態に進む。OTAクライアントがプリミティブライセンスRspを受信した場合、-インストール状態でなければプリミティブは無視され、手続きは継続されない。-ダウンロードされたソフトウェアは、復号化鍵フィールドに示された鍵を用いて復号化される。-復号化が成功した場合、-プリミティブライセンスCnfが送信される。-ダウンロードされた基本ソフトウェアが保存される。-復号化が成功しなかった場合、-プリミティブライセンスRejが送信される。-手続きはアイドル状態に進む。OTAクライアントがプリミティブテスト記述Reqを受信した場合、-インストール状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントは現場テスト状態に進む。-受信されたテストは、先に保存された基本ソフトウェアに対して実行される。-全てのテストが成功した場合、-プリミティブインストールCnfが送信される。-新規の基本ソフトウェアがインストールされて開始される。-少なくとも1個のテストが成功しなかった場合、-インストールRejプリミティブが送信される。-ダウンロードされた基本ソフトウェアがメモリから削除される。-OTAクライアントはアイドル状態に進む。再び図5を参照するに、ここでOTAサーバの応答を記載している。一般に、受信されたプリミティブの各々についてOTAクライアントIDフィールドが分析され、前記識別子に関するOTAクライアントコンテキストであると見なされる。受信された識別子に対するOTAクライアントコンテキストが存在しない場合、当該プリミティブは無視される。OTAサーバがプリミティブダウンロードAckIndを受信した場合、-OTAクライアントコンテキストがダウンロード開始状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントコンテキストは相互認証状態に進む。-乱数が抽出されて保存される。-OTAクライアントチャレンジ番号フィールドの値が、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵SIKサーバ識別鍵により暗号化される。-プリミティブ認証Reqが、前段階でOTAサーバ応答番号フィールド内の暗号化される値と共に、且つOTAサーバチャレンジ番号フィールド内の抽出された番号の値と共にOTAクライアントへ送信される。OTAクライアントコンテキストがプリミティブダウンロードNackIndを受信した場合、-OTAクライアントコンテキストがダウンロード開始状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントコンテキストはアイドル状態に進む。OTAクライアントコンテキストがプリミティブ認証Rspを受信した場合、-OTAクライアントコンテキストが相互認証状態でなければプリミティブは無視され、手続きは継続されない。-保存された乱数の値が、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵SIKにより暗号化される。-前段階で暗号化された値がOTAクライアント応答番号フィールドの値と合致しない場合、OTAクライアントコンテキストはアイドル状態に進み、継続されない。-OTAサーバは能力要求状態に進む。-プリミティブ能力Reqが送信される。OTAクライアントコンテキストがプリミティブ能力Rspを受信した場合、-OTAクライアントコンテキストが能力要求状態でなければプリミティブは無視され、手続きは継続されない。-プリミティブに含まれる能力が、ダウンロードされるソフトウェアと互換性を有していない場合、OTAクライアントコンテキストはアイドル状態に進む。-プリミティブに含まれる能力がダウンロードされるソフトウェアと互換性を有する場合、OTAクライアントコンテキストはダウンロード受理状態に進み、プリミティブダウンロード記述Reqが送信される。OTAクライアントコンテキストがプリミティブダウンロード受理Cnfを受信した場合、-OTAクライアントコンテキストがダウンロード受理状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントコンテキストはソフトウェアダウンロード状態に進む。-ソフトウェアのダウンロードが開始される。OTAクライアントコンテキストがプリミティブダウンロード受理Rejを受信した場合、-OTAクライアントコンテキストがダウンロード受理状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントコンテキストはアイドル状態に進む。OTAクライアントコンテキストがプリミティブライセンスReqを受信した場合、-OTAクライアントコンテキストがソフトウェアダウンロード状態でなければプリミティブは無視され、手続きは継続されない。-手続きはインストール状態に進む。-復号化鍵を含む、プロトコルプリミティブライセンスRspが送信される。OTAクライアントコンテキストがプリミティブライセンスCnfを受信した場合、-OTAクライアントコンテキストがインストール状態でなければプリミティブは無視され、手続きは継続されない。-プリミティブテスト記述Reqが送信される。OTAクライアントコンテキストがプリミティブライセンスRejを受信した場合、-OTAクライアントコンテキストがインストール状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントコンテキストはアイドル状態に進む。OTAクライアントコンテキストがプリミティブインストールCnfを受信した場合、-OTAクライアントコンテキストがインストール状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントコンテキストはアイドル状態に進む。OTAクライアントコンテキストがプリミティブインストールRejを受信した場合、-OTAクライアントコンテキストがインストール状態でなければプリミティブは無視され、手続きは継続されない。-OTAクライアントコンテキストはアイドル状態に進む。データがOTAサーバからOTAクライアントへ転送されるウィンドウプロトコルの動作について以下に記述する。OTAサーバの観点から、ソフトウェアのダウンロードが開始された際に、基本ソフトウェアは、例えば、暗号化鍵および例えばAESアルゴリズム等、公知の種類の暗号化アルゴリズムにより暗号化される。暗号化された基本ソフトウェアは、例えば、1~2kBytes等の限られたサイズを有するブロックに分割される。基本ソフトウェアが分割された無線ブロックの個数に等しい個数のビットを有するビットマスクBITMASKが割当てられて、各々のビットに値0が設定される。マスクの各ビットは、無線ブロックに対応しており、その番号はビット位置に等しい。すなわち、第一ビットは第一無線ブロックに、第二ビットは第二無線ブロックに対応しており、以下同様である。基本ソフトウェアを構成する先頭のN個の無線ブロックBLOCKが送信される。タイマーT401が始動される。各メッセージAckを受信したならば以下が行なわれる。-タイマーT401が再開される。-メッセージAckのビットマップに存在する各々の値1に対して、対応する位置に割当てられたマスクBITMASKの値が1に設定される。-未送信ブロックを最初に考慮して、マスクBITMASK内で値0に対応する高々先頭のN無線ブロックブロックが送信される。-マスクBITMASKの全てのビットが1に等しい値になった時点でダウンロードが終了する。OTAクライアントの観点から、ソフトウェアのダウンロードが開始された際に、当該ソフトウェアが分割された無線ブロックの個数に等しいビットマスクBITMASKが割当てられて、各々のビットに値0が設定される。マスクの各ビットは、無線ブロックに対応しており、その数はビット位置に等しい。すなわち、第一ビットは第一無線ブロックに、第二ビットは第二無線ブロックに対応しており、以下同様である。次いで、タイマーT400が始動される。各無線ブロックBLOCKを受信したならば以下が行なわれる。-タイマーT400が再開される。-受信した無線ブロックのブロック番号に対応するマスクBITMASKのビットが1に設定される。-マスクBITMASKに対応するビットマップと共にメッセージAckが送信される。-マスクBITMASKの全てのビットが1に等しい値になった時点でダウンロードが終了する。要約するに、上例によれば、OTAクライアントおよびOTAサーバの機能的な挙動は以下の通りである。-ダウンロード手続きは、例えば、MSC移動スイッチングセンターにより基地局コントローラBSCへ送信されたプロトコルメッセージハンドオーバーコマンドを受信した時点で開始される。-OTAクライアントとOTAサーバとの間の相互認証は、例えば、チャレンジ応答方式に従い生起する。-ダウンロードされる基本ソフトウェアは、トラフィックチャネル、例えばGPRトラフィックチャネルへ送信される。-ダウンロードされる基本ソフトウェアは、OTAサーバにより小さいサイズ例:1または2キロバイトのブロックに分割される。-基本ソフトウェアの転送は簡単なウィンドウプロトコルにより管理され、その際にサイズウィンドは基本ソフトウェアが分割されたブロックの個数と合致する。-ダウンロードされた基本ソフトウェアは暗号化することができ、その場合、復号化およびインストールのために鍵が必要とされる。-基本ソフトウェアを開始する前に、OTAクライアントは、例えばOTAサーバにより提案された適切なテストによりこれを検証する。図18を参照するに、標準に定義されている通り、回線呼に対するGSMからのUMTSへのシステム間ハンドオーバー手続きの適用可能な例を示しており、この中で端末MSを再設定可能な基本ソフトウェアのダウンロード手続きが導かれている。図19を参照するに、ネットワーク内に存在する異なるエンティティ間の相互作用を指し示しつつ、前記ソフトウェアダウンロード手続きが動作する様子を説明している。1.OTAクライアント、および想定されるOTAクライアントに関し、且つOTAサーバに存在するOTAクライアントコンテキストはアイドル状態である。2.移動スイッチングセンターMSCからプロトコルメッセージハンドオーバーコマンドを受信した場合、OTAクライアントコンテキストはアイドル状態からダウンロード開始状態に遷移し、タイマーT101を始動して、要求されたダウンロードを示すと共に、プリミティブダウンロード開始Indを無線リソースRRへ送信する。3.無線リソースRRは、プリミティブダウンロード開始Indを受信する。無線リソースRRは無線リソース管理RRMに対し、ソフトウェアのダウンロードを実行可能にするために必要なダウンリンクリソースを要求する。a.リソースが利用できる場合、無線リソースRRは制御チャネルFACCH高速付随制御チャネルを介して端末MSの無線リソースRRへプロトコルメッセージパケットダウンロード要求を送信して、端末がダウンロードを実行するチャネルPDCH、相対予約ブロック期間RRBP、および要求されたダウンロードを指示する。b.リソースが利用できない場合、無線リソースRRはプリミティブダウンロードNackIndをOTAクライアントコンテキストへ送信する。4.端末MSの無線リソースRRは、プロトコルメッセージパケットダウンロード要求を受信してチャネルPDCHを設定し、プリミティブダウンロード要求Indを送信する。5.OTAクライアントは、プリミティブダウンロード要求Indを受信する。ダウンロードの実行に端末が利用できる場合、OTAクライアントはアイドル状態からダウンロード開始状態に遷移し、タイマーT100を始動して、プリミティブダウンロードAckIndを送信し、無線リソースRRに対し自身の識別子を指定する。無線リソースRRは、OTAクライアントの識別子をローカルに保存する。6.無線リソースRRはプリミティブダウンロードAckIndを受信して、相対予約ブロック期間RRBPにより指定された時点でPACCHパケット付随制御チャネルを介して基地局コントローラBSCの無線リソースRRへプロトコルメッセージパケットダウンロードAckを送信して、OTAクライアントの識別子を指示する。7.基地局コントローラBSCの無線リソースRRは、プロトコルメッセージパケットダウンロードAckを受信して、プリミティブダウンロードAckIndをOTAクライアントコンテキストへ送信して、OTAクライアントの識別子を指定する。8.OTAクライアントコンテキストは、プリミティブダウンロードAckIndを受信する。OTAクライアントコンテキストはタイマーT101を停止して、ダウンロード開始状態から相互認証状態に遷移する一方、タイマーT201を始動させる。プリミティブ認証Reqが無線リソースRRへ送信される。9.無線リソースRRは、プリミティブ認証Reqを受信して、制御チャネルPACCHを介して、プロトコルメッセージパケット認証要求を端末MSの無線リソースRRを送信して、RRBPを指示する。10.端末MSの無線リソースRRは、プロトコルメッセージパケット認証要求を受信して、プリミティブ認証ReqをOTAクライアントへ送信する。11.OTAクライアントはプリミティブ認証Reqを受信し、タイマーT100を停止して、タイマーT200を始動すると共に、相互認証状態に進む。この段階でOTAサーバの認証が実行される。a.OTAサーバが認証されなかった場合、OTAクライアントはタイマーT200を停止して、アイドル状態に戻る。b.OTAサーバが認証された場合、OTAクライアントはプリミティブ認証Rspを無線リソースRRへ送信する。12.無線リソースRRは、プリミティブ認証Rspを受信して、相対予約ブロック期間RRBPにより指定された時点で、PACCHを介して基地局コントローラBSCの無線リソースRRへプロトコルメッセージパケット認証応答を送信する。13.基地局コントローラBSCの無線リソースRRは、プロトコルメッセージパケット認証応答を受信して、プリミティブ認証RspをOTAクライアントコンテキストへ送信する。14.OTAクライアントコンテキストは、プリミティブ認証Rspを受信して、OTAクライアントの認証を確認する。a.OTAクライアントが認証されなかった場合、タイマーT201が中断され、OTAクライアントコンテキストはアイドル状態に戻る。b.OTAクライアントが認証された場合、タイマーT201が中断され、OTAクライアントコンテキストはタイマーT301を始動すると共に、能力要求状態に進む。OTAクライアントコンテキストは、プリミティブ能力Reqを無線リソースRRへ送信する。15.無線リソースRRは、プリミティブ能力Reqを受信し、制御チャネルPACCHを介して、端末MSの無線リソースRRへ、RRBPが指定されているプロトコルメッセージパケット能力Reqを送信する.16.端末MSの無線リソースRRは、プロトコルメッセージパケット能力Reqを受信して、プリミティブ能力ReqをOTAクライアントへ送信する。17.OTAクライアントはプリミティブ能力rReqを受信し、タイマーT200を停止して、タイマーT300を始動すると共に、能力要求状態に進む、OTAクライアントは、プリミティブ能力Rspを無線リソースRRへ送信する。18.無線リソースRRは、プリミティブ能力Rspを受信し、RRBPにより指定された時点で、PACCHを介して基地局コントローラBSCの無線リソースRRへプロトコルメッセージパケット能力応答を送信する。19.基地局コントローラBSCの無線リソースRRは、プロトコルメッセージパケット能力応答を受信して、OTAクライアントコンテキストへプリミティブ能力Rspを送信する。20.OTAクライアントコンテキストは、プリミティブ能力Rspを受信して、端末能力を検証する。a.当該能力がソフトウェアのダウンロードと互換性を有していない場合、タイマーT301が中断され、OTAクライアントコンテキストはアイドル状態に戻る。b.当該能力がソフトウェアのダウンロードと互換性を有している場合、タイマーT301が中断され、OTAクライアントコンテキストは、タイマーT302を始動すると共にダウンロード動作に関する情報ダウンロードする無線ブロックの個数、支払請求、インストール等が指示されているプリミティブダウンロード記述Reqを無線リソースRRへ送信すると共に、ダウンロード受理状態へ進む。21.無線リソースRRは、プリミティブダウンロード記述Reqを受信して、制御チャネルPACCHを介して、RRBPが指定されているプロトコルメッセージパケットダウンロード記述を端末MSの無線リソースRRへ送信する.22.端末MSの無線リソースRRは、プロトコルメッセージパケットダウンロード記述を受信して、プリミティブダウンロード記述ReqをOTAクライアントへ送信する。23.OTAクライアントは、プリミティブダウンロード記述Reqを受信し、タイマーT300を停止して、ダウンロード受理状態へ進む。OTAクライアントは受信された情報を検証する。a.ダウンロードが受理されなかった場合、OTAクライアントはプリミティブダウンロード受理Rejを無線リソースRRへ送信して、アイドル状態に戻る。b.ダウンロードが受理された場合、OTAクライアントはタイマーT400を始動すると共に、プリミティブダウンロード受理Cnfを無線リソースRRへ送信して、ソフトウェアダウンロード状態へ進む。24.無線リソースRRは、プリミティブダウンロード受理Cnfを受信して、RRBPにより指定された時点で、PACCHを介して基地局コントローラBSCの無線リソースRRへプロトコルメッセージパケットダウンロード受理を送信する。25.基地局コントローラBSCの無線リソースRRは、プロトコルメッセージパケットダウンロード受理を受信して、プリミティブダウンロード受理CnfをOTAクライアントコンテキストへ送信する。26.OTAクライアントコンテキストは、プリミティブダウンロード受理Cnfを受信し、タイマーT302を停止して、OTAクライアントコンテキストは、タイマーT400を始動すると共に、ソフトウェアダウンロード状態に進む。OTAクライアント-コンテキストはダウンロードを開始して、無線リソースRRへプリミティブデータReqを送信することにより、ダウンロードされるソフトウェアの各種のブロックの送信を開始する。無線ブロックの転送は、従来方式のウィンドウプロトコルにより生起する。無線ブロックは、チャネルPDTCHパケットデータ転送チャネルを介して送信される。27.OTAクライアントは、無線リソースRRからのプリミティブデータIndの受信を通じて各々の無線ブロックを受信する。各々の受信ブロックで、タイマーT400が再開される。OTAクライアントは、プリミティブデータReqを周期的に無線リソースRRへ送信することにより、確認応答信号AckをOTAクライアントコンテキストへ送信する。無線リソースRRは、関連付けられた制御チャネルPACCHを介してAckを送信する。OTAクライアントが、ダウンロードされる最後の無線ブロックに関するAckを送信する際に、タイマーT400を停止して、タイマーT500を始動すると共にインストール状態に進む。プリミティブライセンスReqが無線リソースRRへ送信される。28.OTAクライアントコンテキストは、無線リソースRRからのプリミティブデータIndの受信を通じて各種のメッセージAckを受信する。受信された各々のAckにおいてタイマーT401が再開される。OTAクライアントコンテキストが最後の無線ブロックに関するAckを受信する際に、タイマーT401を停止して、タイマーT501を始動すると共にインストール状態へ進む。29.無線リソースRRはプリミティブライセンスReqを受信して、関連付けられた制御チャネルPACCHを介して、プロトコルメッセージパケットライセンス要求を基地局コントローラBSCの無線リソースRRへ送信する。30.基地局コントローラBSCの無線リソースRRは、プロトコルメッセージパケットライセンス要求を受信して、OTAクライアントコンテキストに、プリミティブライセンスReqを送信する。31.OTAクライアントコンテキストは、プリミティブライセンスReqを受信して、ソフトウェア復号化を実行するための鍵を示すプリミティブライセンスRspを無線リソースRRへ送信する。32.無線リソースRRはプリミティブライセンスRspを受信して、関連付けられた制御チャネルPACCHを介して、プロトコルメッセージパケットライセンス応答を端末MSの無線リソースRRへ送信する。33.端末MSの無線リソースRRは、プロトコルメッセージパケットライセンス応答を受信して、プリミティブライセンスRspをOTAクライアントへ送信する。34.OTAクライアントは、プリミティブライセンスRspを受信して、受信した鍵を用いてソフトウェアを復号化する。a.復号化動作が成功した場合、OTAクライアントはプリミティブライセンスCnfを無線リソースRRへ送信する。b.復号化動作が不成功であった場合、OTAクライアントはプリミティブライセンスRejを無線リソースRRへ送信して、タイマーT500を停止して、アイドル状態に戻る。35.無線リソースRRはプリミティブライセンスCnfを受信して、関連付けられた制御チャネルPACCHを介して、プロトコルメッセージパケットライセンス受理を基地局コントローラBSCの無線リソースRRへ送信する。36.基地局コントローラBSCの無線リソースRRは、プロトコルメッセージパケットライセンス受理を受信して、OTAクライアントコンテキストに、プリミティブライセンスCnfを送信する。37.OTAクライアントコンテキストは、プリミティブライセンスCnfを受信して、実行されるテストに関する情報を示すプリミティブテスト記述Reqを無線リソースRRへ送信する。38.無線リソースRRはプリミティブテスト記述Reqを受信して、関連付けられた制御チャネルPACCHを介してプロトコルメッセージパケットテスト記述を端末MSの無線リソースRRへ送信する。39.端末MSの無線リソースRRは、プロトコルメッセージパケットテスト記述を受信して、プリミティブテスト記述ReqをOTAクライアントへ送信する。40.OTAクライアントは、プリミティブテスト記述Reqを受信し、タイマーT500を停止して、現場テスト状態に進む。OTAクライアントは、OTAクライアントコンテキストにより指示された通り、ダウンロードされたソフトウェアに対してテストを実行する。a.テストが不成功であった場合、OTAクライアントはプリミティブインストールRejを無線リソースRRへ送信して、アイドル状態に戻る。b.テストが成功した場合、OTAクライアントはプリミティブインストールCnfを無線リソースRRへ送信し、新規ソフトウェアを起動して、アイドル状態に戻る。41.無線リソースRRはプリミティブインストールCnfを受信して、関連付けられた制御チャネルPACCHを介して、プロトコルメッセージパケットインストール受理を基地局コントローラBSCの無線リソースRRへ送信して、端末MSの無線インターフェースを再設定する。42.基地局コントローラBSCの無線リソースRRは、プロトコルメッセージパケットインストール受理を受信し、OTAクライアントコンテキストへプリミティブインストールCnfを送信して、標準に定義されたリソースを解放する手続きを開始し、当該手続きが終了したならば、標準に定義されたハンドオーバー手続きを継続する。43.OTAクライアントコンテキストは、プリミティブインストールCnfを受信して、アイドル状態に戻る。図19に開示した手続きは、基本ソフトウェアのダウンロード手続きを示すものである。本手続きは、当業者には理解されるように、標準に定義された回線呼用のGSMからUMTSへのシステム間ハンドオーバー手続きに組込まれていてよい。特に、組込みは、MSCから基地局サブシステムアプリケーション部BSSAPプロトコルのハンドオーバーコマンドメッセージを受信してから、MSへRRプロトコルのシステム間からUTRANへのハンドオーバーコマンドメッセージを送信する間に、RR層において行なうことができる。本発明は、現在の基準により定義されている全ての可能なシステム間ハンドオーバー手続きに一般化することができる。例えば、当業者には理解されるように、本手続きは、標準に定義の通り、回線呼用のUMTSからGSMへのシステム間ハンドオーバー手続きに組込むことができる。特に、組込みは、MSCから無線アクセスネットワークアプリケーション部RANAPプロトコルの再配置コマンドメッセージを受信してから、ユーザー設備UEへ無線リソース制御RRCプロトコルのUTRANからのハンドオーバーコマンドメッセージを送信するまでの間に、無線リソース制御RRC層で行なうことができる。本発明はまた、未だ標準化されていないシステム間ハンドオーバー手続き、例えば、国際移動通信2000IMT2000およびWLANまたはIEEE802.16あるいはIEEE802.20システム間のシステム間ハンドオーバー手続きとして一般化することができる。当業者には明らかなように、本発明は、音声通話の場合、特に回線方式呼において、呼を中断することなく基本ソフトウェアのダウンロードの実行を可能にする。これは、例えば、1個以上のパケットチャネル、例えばPDTCHGPRSチャネルを割当てることにより、回線通信に利用される回線方式チャネル、例えばTCHトラフィックチャネルGSMチャネルと並行して、GSM/GPRSの場合に可能である。この特徴により、音声、データ、およびソフトウェアのダウンロードの間での優先順位付けを管理することができる。本発明は、GSM/GPRSシステムを参照するに、上述のシステムの無線チャネルを用いることにより開示されているが、当業者には理解されるように、本発明は例えば汎用チャネルを用いて適用されてもよい。汎用チャネルを用いることができる例として、文献に記載の通り、OTAサーバからOTAクライアントへの基本ソフトウェアのダウンロード手続きへの汎用チャネルの使用が挙げられる。システム間ハンドオーバーの場合、汎用チャネルを使用する実装方式により、例えば図18に開示した手続きを採用して、OTAサーバからOTAクライアントへの基本ソフトウェアのダウンロード手続きを上述の汎用チャネルを介して同時に利用しながら、例えばGSM/GPRSシステム等のアクティブなシステムの無線チャネルを介したアクティブな接続を維持することが予見できる。汎用チャネルは、基本ソフトウェアのダウンロード手続きの全体または一部、例えばOTAサーバからOTAクライアントへの基本ソフトウェアの送信、だけに利用することができる。汎用チャネルを部分的に利用する場合、基本ソフトウェアのダウンロード手続きの残りの部分は、アクティブなシステムの無線チャネルを用いて実装することができる。汎用チャネルを採用することにより、アクティブなシステムに関連付けられた無線リソースをより効率的にロードして、他のユーザーが利用できるようにして、基本ソフトウェアのダウンロード手続きをはるかに高速に実行することが可能になる。これは、汎用チャネルがこの種の動作専用のチャネルであるためである。本発明の更なる実施形態として、当業者には公知のように、例えば、端末がアイドル状態である場合に、GSM/GPRSからUMTSへ等、2種のシステム間でセル再選択手続きをも管理可能にすることである。先に述べたように、プリミティブおよび関連フィールドに名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。この拡張は、OTAクライアントと端末MS側の無線リソースRRとの間に以下のプリミティブを導入するものである。-ダウンロード開始Req:このメッセージは、OTAクライアントから端末MS側の無線リソースRRへ送信される。GSM/GPRSの場合、このプリミティブに提供されるフィールドは少なくとも、OTAクライアントID:要求を実行しているOTAクライアントを識別するおよび、OTAサーバと基地局コントローラBSC側の無線リソースRRとの間の以下のプリミティブの組の一つである。-要求ダウンロード開始Ind:このメッセージは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。GSM/GPRSの場合、プリミティブに提供されるフィールドは、以下のうち少なくとも一組である。OTAクライアントID:要求を実行しているOTAクライアントを識別する。以下に、プリミティブ要求ダウンロード開始Indを受信した際のOTAクライアントコンテキストの端末MSに関するコンテキストの応答を示す。-OTAクライアントコンテキストがアイドル状態ではない場合、プリミティブは無視され、手続きは継続されない。-OTAクライアントコンテキストはダウンロード開始状態へ進む。-プリミティブダウンロード開始Indは、各種の可能なダウンロードを示すと共に、OTAクライアントへ送信される。図19を参照するに、ネットワークに存在する異なるエンティティ間の相互作用を指摘しつつ、セル再選択の場合における基本ソフトウェアのダウンロード手続きの動作を示す。手続き自体の残りの部分が図18の記述と同一であるため、以下に、手続きの第一フェーズの動作を詳述する。I.OTAクライアントおよび考慮しているOTAクライアントに関するOTAクライアントコンテキストはアイドル状態である。II.物理層から到着したセル再選択命令を受信したならば、OTAクライアントは、アイドル状態からダウンロード開始状態に進み、タイマーT100を始動して、自身の識別子を指定するプリミティブダウンロード開始Reqを無線リソースRRへ送信する。無線リソースRRは、OTAクライアントの識別子をローカルに保存する。III.無線リソースRRは、プリミティブダウンロード開始Reqを受信する。無線リソースRRは、パケットランダムアクセスチャネルPRACHを介して、標準により定義されたプロトコルメッセージパケットチャネル要求を送信して、ユーザーによる基本ソフトウェアのダウンロード要求およびOTAチャネルの識別子を指定する。オペレータによりインストールされたGPRS設定が、パケットブロードキャスト制御チャネルPBCCHおよびパケット共通制御チャネルPCCCHにより構成されたマスターチャネルを提供しない場合、上述の手続きは、手続き自体の先頭の2個のメッセージを、上述のパケットランダムアクセスチャネルPRACHおよびパケットアクセス許可チャネルPAGCHではなく、GSMのランダムアクセスチャネルRACHおよびアクセス許可チャネルAGCHにマッピングすることにより引き続き有効である。IV.基地局コントローラBSCの無線リソースRRは、プロトコルメッセージパケットチャネル要求を受信する。これはソフトウェアのダウンロード要求とみなさられるため、受信メッセージにより読まれるOTAクライアントの識別子を指定するプリミティブ要求ダウンロード開始IndをOTAクライアントコンテキストへ送信する。V.OTAサーバがプリミティブ要求ダウンロード開始Indを受信して検証し、その状態で指示されたOTAクライアントに関するOTAクライアントコンテキストは、以下のように振舞う。a.状態がアイドルである場合、OTAクライアントコンテキストはダウンロード開始状態へ進み、タイマーT101を始動して、要求されたダウンロードを示すと共に、プリミティブダウンロード開始Indを無線リソースRRへ送信する。b.状態がアイドルでない場合、メッセージは無視される。VI.無線リソースRRは、プリミティブダウンロード開始Indを受信する。無線リソースRRは、無線リソース管理RRMに対し、当該ソフトウェアのダウンロードを可能にするために必要なダウンリンクリソースを要求する。a.リソースが利用可能である場合、無線リソースRRは制御チャネルPAGCHを介して、プロトコルメッセージパケットダウンロード要求を端末MSの無線リソースRRへ送信し、端末がダウンロードを実行するチャネルPDCH、RRBP、および要求されたダウンロードを示す。b.リソースが利用できない場合、無線リソースRRはプリミティブダウンロードNackIndをOTAクライアントコンテキストへ送信する。VII.端末MSの無線リソースRRは、プロトコルメッセージパケットダウンロード要求を受信し、チャネルPDCHを設定して、プリミティブダウンロード要求Indを送信する。VIII.OTAクライアントは、プリミティブダウンロード要求Indを受信する。端末がダウンロードを実行可能である場合、OTAクライアントは、自身の識別子を指定するプリミティブダウンロードAckIndを送信する。無線リソースRRは、OTAクライアントの識別子をローカルに保存する。本手続きは、図18に関して述べる手続きの第6番以降の段階を実行することにより継続される。GSM/GPRSシステムのアクセスネットワークを参照しつつ、本発明に従い記述されたアーキテクチャおよび方法を開示してきた。本発明はまた、UMTS、UTRANUMTS地上波無線アクセスネットワークその他の任意のアクセスネットワーク、例えばWLAN、IEEE802.16、IEEE802.20等のアクセスネットワークにも適用することができる。例えば、UTRANの場合、本発明はOTAクライアントとOTAサーバおよび関連手続き、プリミティブ並びにプロトコルメッセージをUMTSシステムのRRC層に組込んで実装することができる。本発明を、アクセスネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を用いて開示してきた。本発明はまた、コアネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を用いて実装することもできる。この場合、例えばGSM/GPRSおよびUMTSシステムのパケットスイッチコアネットワークを考慮すれば、本発明は、OTAクライアントとOTAサーバおよび関連手続き、プリミティブ並びにプロトコルメッセージをコアネットワークの端末およびサービス提供GPRSサポートノードSGSNノードの各々のGPRS移動管理GMM層に組込むことにより実装することができる。より具体的には、GSM/GPRSの場合、GPRS移動管理GMM層は、新規のプロトコルメッセージを導入して関連フィールドをOTAサーバとOTAクライアントの間で交換することにより変更される。同じ方式をUMTSシステムに適用することもできる。本発明を、システム間ハンドオーバー手続きの実行中における1個の基本ソフトウェアのダウンロードおよび起動を考慮することにより開示してきた。当業者には明らかなように、当該基本ソフトウェアはインストールして直ちに動作させるのではなく、端末にダウンロードして保存してもよい。この更なる実施形態によれば、ネットワークまたはユーザーからの要求があれば、基本ソフトウェアをインストールして引き続き実行させることが可能である。無線端末UE/MSが十分なメモリおよび処理能力を有していれば、ダウンロードされた基本ソフトウェアを、現在動作中の既存システムと並行して保存およびインストールすることができる。このオプションは、端末UE/MSのマルチモード動作を可能にするために有用である。すなわち、このオプションにより、基本ソフトウェアをダウンロードする必要なしに、端末をある動作モードから別の動作モードへ切り替えることが可能になる。要約すれば、本発明により、少なくとも以下の利点が得られる。-ノードまたは物理的なインターフェースが既存のものに一切追加されないため、第二および第三世代ネットワークに存在しているプロトコルおよびノードに対する影響が最小限に抑えられる。-手続きのシグナリングフェーズが標準で定義されたものと同一のシグナリングチャネルを使用する一方、ソフトウェアのダウンロード手続き用途にのみデータチャネルが割当てられるため、無線リソースの占有が最小限に抑えられる。-本発明は既存の第二および第三世代ネットワークを利用するため、従来技術で言及されているように将来的なIP利用UMTSのリリースを待たなくてもよい。特に、アクセスネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を使用する場合、RR無線リソースプロトコルが、新規の基本ソフトウェアを端末がダウンロードできるようにする若干の変更と一体化されているため、ネットワークはソフトウェアのダウンロード手続きおよび関連する無線リソースを完全に制御することができ、これにより、例えば、GSM/GPRS、IS95、PDCデジタルセルラー電話、あるいは例えばファミリIMT2000に属する第三世代セルラー方式等の第二世代のセルラー方式を実装することができる。