無線通信ネットワークと関連ネットワークおよびそのコンピュータ・プログラム生成物を介して無線端末を設定する方法
【課題】通信システムに従い動作する通信ネットワークを介して再設定可能な無線端末を設定する方法を提供する。
【解決手段】無線端末(UE/MS)を設定するための一組の基本ソフトウェア・モジュールを含めるべく設定されたサーバ・エンティティ(OTAサーバ)を関連付けるステップ、無線端末(MS)に、サーバ・エンティティ(OTAサーバ)のプロトコル層(RR、GMM)に対応するプロトコル層を用いるべく設定されたクライアント・エンティティ(OTAクライアント)を関連付けるステップ、プロトコル層を用いて、無線端末(UE/MS)とサーバ(OTAサーバ)エンティティとの間に地上波接続を確立するステップ、無線端末(UE/MS)を設定すべく、基本ソフトウエア・モジュールの組の少なくとも1個のモジュールをサーバ(OTAサーバ)から無線端末(UE/MS)へダウンロードするステップとを有する。
【解決手段】無線端末(UE/MS)を設定するための一組の基本ソフトウェア・モジュールを含めるべく設定されたサーバ・エンティティ(OTAサーバ)を関連付けるステップ、無線端末(MS)に、サーバ・エンティティ(OTAサーバ)のプロトコル層(RR、GMM)に対応するプロトコル層を用いるべく設定されたクライアント・エンティティ(OTAクライアント)を関連付けるステップ、プロトコル層を用いて、無線端末(UE/MS)とサーバ(OTAサーバ)エンティティとの間に地上波接続を確立するステップ、無線端末(UE/MS)を設定すべく、基本ソフトウエア・モジュールの組の少なくとも1個のモジュールをサーバ(OTAサーバ)から無線端末(UE/MS)へダウンロードするステップとを有する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は一般に、無線通信ネットワークおよび無線通信ネットワークを用いる再設定可能な無線端末に関する。
【0002】
より具体的には、本発明は無線端末の再設定に注目し、前記再設定は、無線通信ネットワークから地上波(OTA)を介してダウンロードした基本ソフトウェアを前記無線端末にインストールすることにより実行される。
【背景技術】
【0003】
文献(J.ミトラ(Mitola)、「ソフトウェア無線アーキテクチャ」、IEEE 通信学会誌、1995年5月、およびE.ブラッチーニ(Buracchini)、「ソフトウェア無線の概念」、IEEE通信学会誌、2000年9月)により、端末、基地局、およびネットワーク・ノード等の再設定可能なシステムは、基本動作モードが再設定可能な設備であることが知られている。例えば、GSM/GPRS(移動通信用グローバルシステム/汎用パケット無線サービス)等の第二世代システム(2G)で動作できる再設定可能な無線端末は、UMTS(ユニバーサル移動電気通信システム)またはCDMA2000(符号分割多重アクセス2000)等の第三世代システム(3G)、DVB−T(デジタルビデオ地上波放送)、またはWLAN(無線ローカル・エリア・ネットワーク)システム等で動作可能にすべく再設定することが可能である。
【0004】
本開示において、用語「システム」は、例えば通信ネットワークとして動作する特定の機能を実行すべく所定の基準に従い相互に調整された、すなわちある「標準」に従い調整されている複数の要素を意図している。
【0005】
本明細書において、システムの例としてGSMシステム、GPRSシステム、UMTSシステム、WLANシステム等があり、その各々が対応する標準に準拠している。
【0006】
端末の再設定を実行するには、上述の文献によれば、再設定可能な技術により端末の動作機能が実現されることが必要である。これに注目するならば、再設定可能な端末または装置には、例えば、複数のFPGA(フィールド・プログラム可能ゲートアレイ)、DSP(デジタル信号プロセッサ)およびマイクロプロセッサで構成された再プログラム可能なハードウェアが備えられていて、装置の個々の機能は、最低水準であっても、ソフトウェア・コードにより実行される。その結果、再プログラム可能な装置を再設定するには、装置自体のハードウェアを管理している基本ソフトウェアを交換すれば十分である。用語「基本ソフトウェア」は、本明細書の記述では、ライブラリとして編成されたソフトウェアを意味し、例えばGSM/GPRS、UMTS等の考慮対象システムのプロトコル・スタックの無線インターフェース(例:L1、L2、L3)および上位層(例:L4からL7まで)を定義している。
【0007】
公知のように、電気通信分野において、機能群のグループ化を行なうために最もよく利用される方法がOSIモデル(開放型システム相互接続)である。機能群は、スタックの形式で表わされる機能平面にグループ化される。
【0008】
プロトコル・スタックの各層は、直上の層に対してサービスを提供し、ここに当該サービスは直下の層が提供するサービスの改善されたものである。
【0009】
最下位層(層1)は一般に、情報の物理的送信を目的とする。
【0010】
OSI仕様によれば、標準的な層の数は7であり、各々物理、接続、ネットワーク、トランスポート、セッション、プレゼンテーション、およびアプリケーション層である。
【0011】
例えばGSM/GPRS、UMTS等の各システムは、OSIプロトコル・スタックの必要な部分を実装している。
【0012】
無線端末を考慮する場合、再設定可能なハードウェアを使用する際の利点は多いが、一つの利点が明らか即効的である。すなわち、無線端末は、当該端末が位置する領域(動作領域)をカバーするシステムにより再設定可能である。従って、端末がGSM/GPRS等の第二世代システムがカバーする領域内で用いられた場合、前記システムを受信可能にすべく当該端末を再設定することができる。同様に、UMTS等の第三世代システムがカバーする領域内では端末を適宜設定することができる。
【0013】
文献(AA.VV.「ソフトウェア無線:再設定可能な端末の課題」、電気通信年報2002年7月/8月、GETエルメス(Hermes)、E.ブラッチーニ(Buracchini)「ソフトウェア無線の概念」)により、下記のように少なくとも3種の異なる方法でソフトウェア・コードを端末へ転送またはダウンロードできることが知られている。
−無線移動端末に組込まれたSIM(加入者識別モジュール)を用いることによりスマートカードを介する方法。
−例えば赤外線/シリアル/USB(ユニバーサル・シリアルバス)ポート経由でのパソコンとのリンクを使用する外部接続を介する方法。
−特定の無線チャネルを用いることにより無線または地上波(OTA)を介する方法。
ソフトウェアのダウンロードに関して、端末へのソフトウェアのダウンロードを管理可能にする一般的なプロトコルの基本的なステップは、www.sdrforum.orgというURLを介して入手可能なソフトウェア無線フォーラム(SDRフォーラム)のフレームワークに定義されている。
【0014】
SDRFで定義されているプロトコルは、公知のクライアント−サーバ方式のものである。
【0015】
ダウンロードのプロトコル・ステップは以下の通りである。
−ダウンロード開始:ソフトウェアのダウンロードを開始する意図を以って、ダウンロードされるソフトウェアが常駐しているサーバと端末が通信するステップ。
−相互認証:端末とサーバは互いに認証しなければならない。
−能力相互通知:サーバは、ダウンロードされるソフトウェアに関する能力情報を通知し、端末は当該ソフトウェアを端末メモリへのロード、インストールおよび実行が可能であるか否かを検証する。
−ダウンロード受理:サーバが端末との間で、ダウンロード、インストール、および支払請求オプションを通信する。端末は、サーバから提供された指示が受理可能か否かを決定する。
−ダウンロードおよび完全性テスト:ソフトウェアをダウンロードする間、受信されたコードをテストしなければならない。端末は、不正確に受信された無線ブロックの再送を要求する。
−インストール:インストールステップの間、ソフトウェアの支払請求およびライセンス条件がサーバから提供される。
−現場テスト:ソフトウェアの実行を開始する前に、端末は、ソフトウェア・コードと共にダウンロードされたテスト・ベクトルの支援を受けていくつかのテストを実施する。
−否認防止相互通知:一旦ソフトウェア・コードがインストールされて、テストされたならば、端末はサーバに対し、インストールが成功した旨を確認して支払請求手続きを開始する。
【0016】
従来技術、例えばE.ブラッチーニ(Buracchini)、「ソフトウェア無線の概念」、IEEE通信学会誌2000年9月)により、無線またはOTAを介したソフトウェアのダウンロードは無線チャネルの端末による利用を想定していることが知られている。上述した文献によれば、無線チャネルの種別に応じてソフトウェア・コードを2種の異なる方式のダウンロードすることが知られている。
−「帯域外」方式:現行システムから独立した「ユニバーサル」チャネルにより、端末がスイッチ・オンされた際に、自動的に当該チャネルに同調して、動作領域で動作しているシステムに関する基本ソフトウェアのダウンロードを実行する。
−「帯域内」方式:各々GSM/GPRSおよびUMTS等である、第二および第三世代の標準セルラー・システムの無線チャネルを用いて、これらのチャネルで既に動作している端末が、現在使用されているものとは異なるシステムに関する基本ソフトウェアを受信する。例えば、GSM/GPRS等の第二世代システムにより動作する再設定可能な端末が、自身が動作している第二世代の無線チャネルを用いて、UMTS等第三世代システムのダウンロードを実行することができる。
【0017】
「帯域外」ソフトウェアのダウンロードの例が、例えば日本特許出願第2001061186号公報に記載されている。当該文献は、ソフトウェア・コンテンツを地上波経由でダウンロードするシステムおよび方法を記述している。無線端末がスイッチ・オンされた際に、当該動作領域における現行システムが何であるかをユニバーサル・チャネルに問い合わせ、指示されたシステムに関するソフトウェアをダウンロードする。
【0018】
「帯域外」モードを考慮するに、従来技術によれば専用の無線チャネルの実装が必要であり、従って、その実施のためのネットワークにおける専用設備が必要である。
【0019】
「帯域内」ソフトウェアのダウンロードの例が、例えば米国特許出願公開第2003/0163551号に記載されている。当該文献は、サーバと端末間の交渉(能力相互通知、認証、支払請求等)ステップの間に専用チャネルを用いて、且つ利用可能な無線リソースに負荷をかけることなく極力多くのユーザーに対して同時にダウンロード・サービスを提供すべくダウンロード・手続きの間に共有共通チャネルを用いて、地上波経由でソフトウェアをダウンロードするシステムおよび方法を記述している。
【0020】
「帯域内」ダウンロード方式を考慮する際に、文献AA.VV.「再設定可能端末に対応したIP利用に基づくネットワーク要素のアーキテクチャ」、SCOUTワークショップ、2003年9月16日、およびIST−2001−34091SCOUT、D4.1.1、「セルラーおよびアドホック・ネットワークにおけるIP原理に基づくダウンロード・トラフィックに対するネットワークおよびセキュリティ・アーキテクチャ要件並びにトラフィック管理スキーム」で、ある種のプロトコルおよびある種のネットワーク・ノードを大幅に変更することを提案している。例:基本ソフトウェアのダウンロードの管理を可能にすべく、コア・ネットワークがIP(インターネット・プロトコル)に完全準拠しているUMTSのリリース5以降に基づく無線アクセス・ノードおよび/またはコア・ネットワーク・ノード。
【0021】
このような変更は、設備製造業者およびネットワーク・オペレータの相当な努力を要し、既存のセルラー・システムの標準に劇的な影響を及ぼす恐れがある。
【0022】
従って、既知の「帯域内」技術には、例えばGSM/GPRSまたはUMTS等の既存のセルラー・ネットワークに再設定可能な端末の基本ソフトウェアのダウンロード管理の追加が求められた場合に、プロトコルおよびネットワーク・ノードに対する大幅な変更が必要になるという制限を示す。
【0023】
出願人は、「帯域内」方式および「帯域外」方式の両方の場合において公知の従来技術では、ある種のプロトコルおよびある種のネットワーク・ノードに大幅な変更が施される点に注目する。
【0024】
公知の従来技術における更なる問題は、現行標準によるシステム間ハンドオーバーの管理である。
−GSM/GPRシステムからUMTSシステムへのハンドオーバー
−UMTSシステムからCDMA2000システムへのハンドオーバー
−UMTSシステムからGSM/GPRシステムへのハンドオーバー
−CDMA2000システムからUMTSシステムへのハンドオーバー
【0025】
公知の標準によれば、システム間ハンドオーバーは、多モード端末、すなわちASIC(特定用途向け集積回線)技術を用いて各々のセルラー・システムのプロトコル・スタック全体をサポートする端末を必要とする。
【0026】
例えば図1を参照するに、RAT−GSM/GPRSと呼ばれるGSM/GPRSシステムの全体的な無線プロトコル・スタック、RAT−UMTSと呼ばれるUMTSシステムの全体的な無線プロトコル・スタック、およびRAT−CDMA2000と呼ばれるCDMA2000システムの全体的な無線プロトコル・スタックを含む多モード端末を示している。
【0027】
公知の解決策には、電力消費が多い、装置サイズが大きい、および実装コストが高い等、いくつかの短所がある。
【特許文献1】日本特許出願第2001061186号公報
【特許文献2】米国特許出願公開第2003/0163551号
【非特許文献1】J.ミトラ(Mitola)、「ソフトウェア無線アーキテクチャ」、IEEE 通信学会誌、1995年5月
【非特許文献2】E.ブラッチーニ(Buracchini)、「ソフトウェア無線の概念」、IEEE通信学会誌、2000年9月
【非特許文献3】AA.VV.「ソフトウェア無線:再設定可能な端末の課題」、電気通信年報2002年7月/8月、GETエルメス(Hermes)、E.ブラッチーニ(Buracchini)「ソフトウェア無線の概念」
【発明の開示】
【発明が解決しようとする課題】
【0028】
要約すれば、出願人は公知の従来技術について以下の点に注目する。
−例えば新規のノードやインターフェースの追加、および標準により定義されたデータのシグナリングおよび転送プロトコルの変更等、無線リソースの非効率的な利用につながるネットワーク・ノードに対する大幅な変更なしにはソフトウェアをダウンロードする課題が解決されない。
−システム間ハンドオーバーの管理のために再設定可能な端末を利用することができない。
【課題を解決するための手段】
【0029】
従って、ネットワーク・ノードおよび関連プロトコルを大幅に変更することなく無線端末を設定する基本ソフトウェアをダウンロードする方法および通信ネットワークを提供することが本発明の目的である。
【0030】
更に、設定可能な端末を用いてシステム間ハンドオーバー手続きを可能にする方法および通信ネットワークを提供することも本発明の更なる目的である。
【0031】
上述の目的は、添付の請求項に記載されている方法および通信ネットワークにより達成される。
【0032】
更に、本発明の目的は、コンピュータ・プログラム生成物またはコンピュータ・プログラム生成物の組により達成され、当該生成物は少なくとも1個のコンピュータのメモリにロード可能であって、請求項に従い当該生成物がコンピュータ上で実行された場合に本発明の方法のステップを実行するソフトウェア・コード部分を含んでいる。以下で用いるように、そのようなコンピュータ・プログラム生成物への参照は、本発明の方法の実行を調整すべくコンピュータ・システムを制御する命令を含むコンピュータ可読媒体への参照と等価である。「少なくとも1個のコンピュータ」との表現は明らかに、本発明の方法が分散モジュール方式で実装される可能性を強調することを意図している。
【0033】
好適な実施形態において、無線端末を再設定する基本ソフトウェアのダウンロードは、標準に関して、端末内および、例えばネットワークのBSC(基地局コントローラ)またはRNC(無線ネットワーク・コントローラ)の無線コントローラ等、ネットワーク内の少なくとも1個のノード内の無線プロトコル・スタックの単一の層だけを変更することにより実現される。
【0034】
本発明によれば、変更された層のプロトコルは、SDR−Forumから提供される推奨事項と整合している。
【0035】
本発明の好適な実施形態によれば、そこから基本ソフトウェアをダウンロードが可能であるサーバは、ネットワークの無線コントローラ、例えばBSCまたはRNC等に常駐している。
【0036】
本発明がもたらす利点には以下のものがある。
−ソフトウェアのダウンロード・サービスは透過的であり、他の任意のシグナリングおよびトラフィック・データフローとしてネットワークから見える。
−既存且つ将来の標準の全ての特徴を完全に利用することにより、無線リソースの効果的且つ柔軟な利用が可能である。
−呼を中断することなく基本ソフトウェアをダウンロードするために、例えば回線呼の最中にパケット接続を確立することが可能である。
−異なるデータフロー同士を区別して、それらの優先順位(例:音声、データおよびソフトウェアのダウンロード)を管理することが可能である。例えば、音声通話の優先順位がソフトウェアのダウンロードの優先順位より高い場合、ソフトウェアのダウンロード自体を一時的に中断して、逐次前記ダウンロードを再開することができる。
【0037】
更に、本発明は、再設定可能端末を利用してシステム間ハンドオーバーの管理を可能にする。
【0038】
実際に、本発明の好適な実施形態によれば、サポート対象システム上で測定を実行するための最小限の機能だけが端末の物理層に実装されていれば十分である。
【0039】
例えば、GSM/GPRSシステムにより動作すべく設定されていて、UMTSシステムへのシステムハンドオーバーを管理する準備が整っている端末を想定する。本発明によれば、GSM/GPRSシステムの無線インターフェースの全体的なプロトコル・スタックにより設定されている端末は、UMTSシステムの能力測定を実行するための最小限の物理層機能だけを備えている。
【0040】
システム間ハンドオーバーは、GSM/GPRS無線チャネルを介してUMTS基本ソフトウェア全体を端末内にダウンロードし、UMTSシステムに従い端末を再設定して、GSM/GPRSシステム上で能力測定を実行するための最小限の物理層機能を提供することにより管理される。
【0041】
本発明を、その好適な、ただし限定的ではない実施形態の添付図面を参照しながら以下に開示する。
【0042】
全ての図を通じて、同等であるか、または実質的に等価な機能を実装する構成要素を示すために同一参照番号を用いている。
【発明を実施するための最良の形態】
【0043】
図2を参照するに、再設定可能な端末または移動局MS、基地送受信局BTSすなわちBTSノード、および基地局コントローラBSCすなわちBSCノードを含むGSM/GPRSシステムのネットワーク・アーキテクチャを示す。
【0044】
ネットワークは更に、例えば、図2に示していない移動スイッチング・センター(MSC)および/またはサービングGPRSサポート・ノード(SGSN)および/またはゲートウェイGPRS サポート・ノード(GGSN)等のコア・ネットワーク・ノードを含んでいる。
【0045】
端末MSは、BSCノードに接続されているBTSノードに、無線インターフェースを介して接続されている。
【0046】
本発明の好適な実施形態によれば、端末MSは、OTAクライアントと呼ばれる第一のエンティティと、無線リソース・プロトコルRRと呼ばれる公知の種類の第二のエンティティとを含んでいる。OTAクライアントは、無線リソース・プロトコルRRと同一プロトコル・レベルまたは層にあってこれと協働する。
【0047】
RRエンティティは、例えば、GSM/GPRS標準ETSI04.18に従い動作し、以下に開示するように、基地局コントローラBSC内でOTAクライアントおよびRR対応エンティティと通信するための機能を含んでいる。
【0048】
OTAクライアントは、基本ソフトウェアの全体または一部を、OTAサーバと呼ばれる基地局コントローラBSC内のOTA対応エンティティからダウンロードする手続きを完全に管理することが可能なソフトウェア・モジュールを含んでいる。
【0049】
BSCは、OTAサーバと呼ばれる第一のエンティティ、および無線リソース・プロトコルRRと呼ばれる公知の種類の第二のエンティティを含んでいる。
【0050】
OTAサーバは、同一プロトコル・レベルにあって、無線リソース・プロトコルRRと協働する。
【0051】
RRエンティティは、例えば、GSM/GPRS標準ETSI04.18に従い動作し、以下に開示するように、移動端末MS内でOTAサーバおよびRR対応エンティティと通信するための機能を含んでいる。
【0052】
OTAサーバは、基本ソフトウェアの全体または一部をOTAクライアントへダウンロードする手続きを完全に管理することが可能なソフトウェア・モジュールを含んでいる。
【0053】
OTAサーバは更に、基本ソフトウェアを含んでいるか、または、これを修復することが可能である。
【0054】
OTAサーバのアーキテクチャは、以下に開示するように、アクティブなダウンロード・セッションを有する各OTAクライアントに対してクライアント・コンテキストと呼ばれるコンテキストを提供する。
【0055】
図3に、本発明に従い設定された端末MSを示す。
【0056】
端末MSは、GSM/GPRSプロトコルの上位層および下位層を含んでいる。
【0057】
下位層はRAT(無線アクセス技術)GSM/GPRSと呼ばれ、GSM/GPRS標準に従いOTAクライアント、無線リソースRR、物理(L1)およびDL(データリンク)(L2)の各エンティティを含んでいる。
【0058】
端末MSは、更なる標準、例えばUMTS標準に従い物理層(L1U)を含み、少なくとも当該更なる標準に準拠して層1の測定を実行する機能を更に含んでいる。
【0059】
開示した端末MSは、以下に開示するように更なる標準の基本ソフトウェアをダウンロードすることにより再設定可能である。
【0060】
本発明の好適な実施形態で想定されているように、基本ソフトウェアは一組の基本ソフトウェア・モジュール、好適には所定の通信システムに従い端末MSを設定する複数のソフトウェア・モジュールを含んでいる。
【0061】
本発明は、例えば更に所定の通信システムに従って無線端末MSを設定するために用いるプロトコル・スタックを構成する全ての基本ソフトウェア・モジュールのダウンロードを可能にする。
【0062】
当業者には理解されるように、本発明の更なる実施形態によれば、使用中の通信システムまたは別の通信システムに対応するプロトコル・スタックの一部だけで構成されたソフトウェア・モジュールをダウンロードすることも可能である。
【0063】
そのような更なる実施形態は、例えば、端末MSに新規機能、更新版またはバグ修正を加える目的に有用であろう。
【0064】
図4を参照するに、端末MSにおけるOTAクライアントの状態遷移図を示す。
【0065】
状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
本発明の好適な実施形態によれば、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クライアントは「アイドル」状態に戻る。
【0066】
図5を参照するに、OTAサーバが管理するクライアント・コンテキストの状態遷移図を示す。
【0067】
先に述べたように、状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
【0068】
クライアント・コンテキストの状態および相対遷移は以下の通りである。
−「アイドル」状態:アクティブなソフトウェア・ダウンロード・手続きが存在しない場合、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クライアントによるインストールの成功に関する確認応答信号を受信したならば、「アイドル」状態に戻る。
【0069】
GSM/GPRSの場合、本発明の好適な実施形態において、RRプロトコルは、以下に図6〜17を参照しながら詳述するように、新規プロトコル・メッセージを導入することにより変更され、関連するフィールドをOTAサーバとOTAクライアントの間で交換される。
【0070】
異なるシステムの場合、当業者には理解されるように、例えばUMTSシステムにおけるRRC(無線リソース制御)等の無線リソース・プロトコルが同様の方法で変更される。
【0071】
以下に、メッセージおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。
【0072】
図6を参照するに、「パケット・ダウンロード要求」メッセージの構造を記述している。このメッセージは、基地局コントローラBSC側にある無線リソースRRから端末MS側の無線リソースRRへ送信される。
【0073】
OTAサーバはこのメッセージを用いて、OTAクライアントに対しダウンロード・セッションを開始するよう指示する。
【0074】
提供されるフィールドは、GSM/GPRSの場合、少なくとも以下のうち1組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロード要求)を識別する。
−OTAクライアントID:要求を実行する対象であるOTAクライアントを識別する。
−PDCH(パケット・データチャネル):ソフトウェアのダウンロードが実行されるネットワークにより割当てられたチャネルを指定する。
−RRBP(相対予約ブロック期間):標準GPRSで既に定義されている通り、端末MS側の無線リソースRRが応答する無線ブロックを指定する。
−要求されたダウンロード:この要素は、ネットワークによる要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。
【0075】
図7を参照するに、「パケット・ダウンロードAck」メッセージの構造を記述している。このメッセージはOTAクライアントからOTAサーバへ送信される。
【0076】
OTAクライアントは、このメッセージを用いて、ダウンロード・セッションの開始の確認をOTAサーバに通知する。
【0077】
提供されるフィールドは、GSM/GPRSの場合、少なくとも以下のうち1組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロードAck)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント・チャレンジ番号:相互認証の第一ステップを実行すべく、OTAサーバが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズム(高度暗号化標準)を以って暗号化する乱数である。
【0078】
図8を参照するに、「パケット・ダウンロードNack」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバにダウンロード・セッションを開始することができない旨を通知する。
【0079】
提供されるフィールドは、GSM/GPRSの場合、少なくとも以下のうち1組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロードNack)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0080】
図9を参照するに、「パケット認証要求」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、自身の証明をOTAクライアントに通知し、OTAクライアントにそれを確認することが要求する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット認証要求)を識別する。
−OTAクライアントID:メッセージを送信するOTAクライアントを識別する。
−OTAサーバ応答番号:相互認証の第一のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAサーバにより暗号化される番号である。
−OTAサーバ・チャレンジ番号:相互認証の第二ステップを実行すべく、OTAクライアントが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
−RRBP:標準GPRSで既に定義されているように、端末MS側の無線リソースRRが応答する無線ブロックを指定する。
【0081】
図10を参照するに、「パケット認証応答」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、既にOTAサーバを認証した状態で、OTAクライアントは自身の証明をOTAサーバに通知する。GSM/GPRSの場合に提供されるフィールドは、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット認証応答)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント応答番号:相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAクライアントにより暗号化される番号を識別する。
【0082】
図11を参照するに、「パケット能力要求」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、OTAクライアントに対しその再設定可能性オプションを要求する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット能力要求)を識別する。
−OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。
−RRBP:標準GPRSに既に定義されている通り、端末MS側の無線リソースRRが応答する無線ブロックを指定する。
【0083】
図12を参照するに、「パケット能力応答」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントは、自身の再設定可能性オプションをOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット能力応答)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント能力:端末の再設定可能性オプションを記述する。
【0084】
図13を参照するに、「パケット・ダウンロード記述」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、ダウンロードに関するデータをOTAクライアントに報告する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロード記述)を識別する。
−OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。
−ダウンロード・リスト:各ダウンロードにつきOTAクライアントにより選択された1個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
−ダウンロード・ブロック番号:OTAクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
−支払請求基準:起こり得るダウンロード支払請求に関する基準である。
−インストール基準:ソフトウェアのインストールに関する基準である。
−RRBP:標準GPRSに既に定義されている通り、端末MS側の無線リソースRRが応答する無線ブロックを指定する。
【0085】
再び図8を参照するに、「パケット・ダウンロード受理」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントがダウンロードを確認する。
【0086】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロード受理)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0087】
再び図8を参照するに、「パケット・ダウンロード拒否」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはダウンロードを拒否する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロード拒否)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0088】
再び図8を参照するに、「パケット・ライセンス要求」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバに対し、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵を要求する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ライセンス要求)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0089】
図14を参照するに、「パケット・ライセンス応答」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵をOTAクライアントに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ライセンス応答)を識別する。
−OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。
−復号化鍵:基本ソフトウェアを復号化するために用いられる鍵である。
【0090】
再び図8を参照するに、「パケット・ライセンス受理」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントは、ダウンロードされた基本ソフトウェアが正しく復号化された旨をOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ライセンス受理)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0091】
再び図8を参照するに、「パケット・ライセンス失敗」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントは、ダウンロードされた基本ソフトウェアが正しく復号化されなかった旨をOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ライセンス失敗)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0092】
図15を参照するに、「パケット・テスト記述」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバはOTAクライアントに対し、ダウンロードされた基本ソフトウェアを開始する前に実行すべきテストを指示する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・テスト記述)を識別する。
−OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。
−テスト・リスト:実行すべき各々のテストについて1個の要素を含み、これは更に以下のフィールドを含んでいる。
−テスト・ベクトル:テストの記述を含んでいる。
【0093】
再び図8を参照するに、「パケット・インストール成功」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功した旨を通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・インストール成功)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0094】
再び図8を参照するに、「パケット・インストール失敗」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功しなかった旨を通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・インストール失敗)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0095】
基本ソフトウェアは、好適な実施形態において、例えば、以下に述べるBlockおよびAckと呼ばれる2種類の基本プロトコル・データ・ユニットすなわちPDUに基づいて公知の種類のウィンドウ・プロトコルを使用することにより、OTAサーバからOTAクライアントへ送信される。
【0096】
図16を参照するに、基本ソフトウェアが分割される無線ブロックBlockの構造を記述している。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:ブロック種別を識別する。
−ブロック番号:無線ブロックのシーケンス番号を識別する。OTAクライアントがこのシーケンス番号を用いて、基本ソフトウェア全体を再構成する。
−データ:基本ソフトウェア全体のいくつかの部分を含むフィールドである。
【0097】
図17を参照するに、端末の受信状態を示すために用いるメッセージAckの構造を記述している。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(Ack)を識別する。
−Ackビットマップ:基本ソフトウェアが分割された無線ブロックの総数に等しいサイズを有するビット・マスクである。各々の無線ブロックについて、当該ブロックが首尾よく受信された場合は「1」にセットされ、ブロックが受信されたものの損傷しているかまたは全く受信されなかった場合は「0」にセットされる。
【0098】
本発明の好適な実施形態が想定するRRプロトコルに対する変更は、OTAクライアントと端末MS側の無線リソースRRとの間にプリミティブを導入し、またOTAサーバと基地局コントローラBSC側の無線リソースRRとの間にプリミティブを導入することに基づいている。
【0099】
プリミティブおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。
【0100】
最初に、OTAクライアントと端末MS側の無線リソースRRとの間のプリミティブを記述する。
【0101】
プリミティブ「ダウンロード要求Ind」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0102】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:要求の実行対象であるOTAクライアントを識別する。
−要求されたダウンロード:この要素は、ネットワークにより要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。
【0103】
プリミティブ「ダウンロードAckInd」は、OTAクライアントにより端末MS側の無線リソースRRへ送信される。このプリミティブで提供されるフィールドには、以下のものがある。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAクライアント・チャレンジ番号:相互認証の第一ステップを実行すべく、OTAサーバが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
【0104】
プリミティブ「ダウンロードNackInd」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0105】
プリミティブ「認証Req」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0106】
このプリミティブで提供されるフィールドには以下のものがある。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAサーバ応答番号:相互認証の第一のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAサーバにより暗号化される番号である。
−OTAサーバ・チャレンジ番号:相互認証の第二ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
【0107】
プリミティブ「認証Rsp」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAクライアント応答番号:相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAクライアントにより暗号化される番号を識別する。
【0108】
プリミティブ「能力Req」は、MS側の無線リソースRRからOTAクライアントへ送信される。
【0109】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0110】
プリミティブ「能力Rsp」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0111】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント能力:端末の再設定可能性オプションを記述する。
【0112】
プリミティブ「ダウンロード記述Req」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0113】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−ダウンロード・リスト:各ダウンロードにつきOTAクライアントにより選択された1個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
−ダウンロード・ブロック番号:OTAクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
−支払請求基準:起こり得るダウンロード支払請求に関する基準である。
−インストール基準:ソフトウェアのインストールに関する基準である。
【0114】
プリミティブ「ダウンロード受理Cnf」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0115】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0116】
プリミティブ「ダウンロード受理Rej」は、OTA端末MS側の無線リソースRRへ送信される。
【0117】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0118】
プリミティブ「ライセンスReq」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0119】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0120】
プリミティブ「ライセンスRsp」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0121】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−復号化鍵:基本ソフトウェアを復号化するために用いられる鍵である。
【0122】
プリミティブ「ライセンスCnf」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0123】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0124】
プリミティブ「ライセンスRej」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0125】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0126】
プリミティブ「テスト記述Req」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0127】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−テスト・リスト:実行すべき各々のテストについて1個の要素を含み、これは更に以下のフィールドを含んでいる。
−テスト・ベクトル:テストの記述を含んでいる。
【0128】
プリミティブ「インストールCnf」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0129】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
プリミティブ「インストールRej」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0130】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0131】
プリミティブ「データInd」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0132】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−基本ソフトウェアが分割された無線ブロックのうちの1個。
【0133】
プリミティブ「データReq」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0134】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−Ackの無線ブロック。
【0135】
OTAサーバと基地局コントローラBSC側の無線リソースRRとの間で交換されるプリミティブについて以下に記述する。
【0136】
プリミティブ「ダウンロード開始Ind」は、OTAクライアントから基地局コントローラ機構BSC側の無線リソースRRへ送信される。
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:要求の実行対象であるOTAクライアントを識別する。
−要求されたダウンロード:この要素は、ネットワークにより要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。
【0137】
プリミティブ「ダウンロードAckInd」は、基地局コントローラ機構BSC側の無線リソースRRによりOTAクライアントへ送信される。
【0138】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAクライアント・チャレンジ番号:相互認証の第一ステップを実行すべく、OTAサーバが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
【0139】
プリミティブ「ダウンロードNackInd」は、基地局コントローラ機構BSC側の無線リソースRRからOTAクライアントへ送信される。
【0140】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0141】
プリミティブ「認証Req」は、OTAクライアントから基地局コントローラ機構BSC側の無線リソースRRへ送信される。
【0142】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAサーバ応答番号:相互認証の第一のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAサーバにより暗号化される番号である。
−OTAサーバ・チャレンジ番号:相互認証の第二ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
【0143】
プリミティブ「認証Rsp」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0144】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAクライアント応答番号:相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAクライアントにより暗号化される番号を識別する。
【0145】
プリミティブ「能力Req」は、OTAクライアントから基地局コントローラBSC側の無線リソースRRへ送信される。
【0146】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0147】
プリミティブ「能力Rsp」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0148】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント能力:端末の再設定可能性オプションを記述する。
【0149】
プリミティブ「ダウンロード記述Req」は、OTAクライアントから基地局コントローラBSC側の無線リソースRRへ送信される。
【0150】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−ダウンロード・リスト:各ダウンロードにつきOTAクライアントにより選択された1個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
−ダウンロード・ブロック番号:OTAクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
−支払請求基準:起こり得るダウンロード支払請求に関する基準である。
−インストール基準:ソフトウェアのインストールに関する基準である。
【0151】
プリミティブ「ダウンロード受理Cnf」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0152】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0153】
プリミティブ「ダウンロード受理Rej」は、基地局コントローラ機構BSC側の無線リソースRRからOTAクライアントへ送信される。
【0154】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0155】
プリミティブ「ライセンスReq」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0156】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0157】
プリミティブ「ライセンスRsp」は、OTAクライアントにより基地局コントローラBSC側の無線リソースRRへ送信される。
【0158】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−復号化鍵:基本ソフトウェアを復号化するために使用する鍵である。
【0159】
プリミティブ「ライセンスCnf」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0160】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0161】
プリミティブ「ライセンスRej」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0162】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0163】
プリミティブ「テスト記述Req」は、OTAサーバから基地局コントローラBSC側の無線リソースRRへ送信される。
【0164】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−テスト・リスト:実行すべき各々のテストについて1個の要素を含み、これは更に以下のフィールドを含んでいる。
−テスト・ベクトル:テストの記述を含んでいる。
【0165】
プリミティブ「インストールCnf」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0166】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0167】
プリミティブ「インストールRej」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0168】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0169】
プリミティブ「データReq」は、OTAサーバから基地局コントローラBSC側の無線リソースRRへ送信される。
【0170】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−基本ソフトウェアが分割された無線ブロックのうちの1個。
【0171】
プリミティブ「データInd」は、基地局コントローラBSC側の無線リソースRRからOTAサーバへ送信される。
【0172】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−Ackの無線ブロック。
【0173】
図4、5を参照するに、OTAクライアントとOTAサーバとの間での手続き型の対話を、各々のRRが受信した各プリミティブについて、OTAクライアントまたはクライアント・コンテキストの状態に従う相対的な挙動を示すことにより記述している。
【0174】
OTAクライアントおよびOTAサーバの挙動はシステムから独立している。
【0175】
OTAクライアントまたはOTAサーバと、各々のRRとの間で交換されたプリミティブはシステムに依存しており、本例によればGSM/GPRSシステムを参照している。
【0176】
以下の記述において、タイマーの開始/停止動作は記述されていない。その理由は、先に述べたように、これらはエンティティの状態と関連付けられているためである。
【0177】
ここで図4を参照するに、OTAクライアントの挙動を記載している。
【0178】
一般に、OTAクライアントIDフィールドがプリミティブを受信しているOTAクライアントの識別子と合致しない場合、当該プリミティブは無視される。
【0179】
OTAクライアントがプリミティブ「ダウンロード要求Ind」を受信した場合、
−「アイドル」状態であれば、OTAクライアントは「ダウンロード開始」へ進む。
−「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−端末がダウンロードを実行することが可能ならば、
−乱数RNUMが抽出されて保存される。
−OTAクライアント・チャレンジ番号フィールド内に抽出された数RNUMの値を含むプリミティブ「ダウンロードAckInd」が送信される。
−端末がダウンロードを実行することが可能でなければ、プリミティブ「ダウンロードNackInd」が送信され、OTAクライアントは「アイドル」状態に戻る。
【0180】
OTAクライアントがプリミティブ「認証Req」を受信した場合、
−「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−保存された乱数RNUMが有効でなければ手続きは継続されない。
−OTAクライアントは状態「相互認証」へ進む。
−保存された乱数RNUMの値は、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵CIKにより暗号化される。
−前段階で暗号化された値がOTAサーバ応答番号フィールドの値と合致しない場合、OTAクライアントは「アイドル」状態に進み、手続きは継続されない。
−OTAサーバ・チャレンジ番号フィールドの値は、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵CIK(クライアント識別鍵)により暗号化される。
−プリミティブ「認証Rsp」は、OTAクライアント応答番号フィールド内の前段階で暗号化された値と共に送信される。
【0181】
OTAクライアントがプリミティブ「能力Req」を受信した場合、
−「相互認証」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアントは「能力要求」状態に進む。
−プリミティブ「能力応答」が送信される。
【0182】
OTAクライアントがプリミティブ「ダウンロード記述Req」を受信した場合、
−「能力要求」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアントは「ダウンロード受理」状態に進む。
−端末がソフトウェアをインストールすることが可能ならば、
−プリミティブ「ダウンロード受理Cnf」が送信される。
−端末がソフトウェアをインストールすることが可能でなければ、
−プリミティブ「ダウンロード受理Rej」が送信される。
−OTAクライアントは「アイドル」状態に進む。
【0183】
OTAクライアントがプリミティブ「ライセンスRsp」を受信した場合、
−「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−ダウンロードされたソフトウェアは、復号化鍵フィールドに示された鍵を用いて復号化される。
−復号化が成功した場合、
−プリミティブ「ライセンスCnf」が送信される。
−ダウンロードされた基本ソフトウェアが保存される。
−復号化が成功しなかった場合、
−プリミティブ「ライセンスRej」が送信される。
−手続きは「アイドル」状態に進む。
【0184】
OTAクライアントがプリミティブ「テスト記述Req」を受信した場合、
−「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアントは「現場テスト」状態に進む。
−受信されたテストは、先に保存された基本ソフトウェアに対して実行される。
−全てのテストが成功した場合、
−プリミティブ「インストールCnf」が送信される。
−新規の基本ソフトウェアがインストールされて開始される。
−少なくとも1個のテストが成功しなかった場合、
−インストールRejプリミティブが送信される。
−ダウンロードされた基本ソフトウェアがメモリから削除される。
−OTAクライアントは「アイドル」状態に進む。
【0185】
再び図5を参照するに、ここでOTAサーバの応答を記載している。
【0186】
一般に、受信されたプリミティブの各々についてOTAクライアントIDフィールドが分析され、前記識別子に関するOTAクライアント・コンテキストであると見なされる。受信された識別子に対するOTAクライアント・コンテキストが存在しない場合、当該プリミティブは無視される。
【0187】
OTAサーバがプリミティブ「ダウンロードAckInd」を受信した場合、
−OTAクライアント・コンテキストが「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「相互認証」状態に進む。
−乱数が抽出されて保存される。
−OTAクライアント・チャレンジ番号フィールドの値が、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵SIK(サーバ識別鍵)により暗号化される。
−プリミティブ「認証Req」が、前段階でOTAサーバ応答番号フィールド内の暗号化される値と共に、且つOTAサーバ・チャレンジ番号フィールド内の抽出された番号の値と共にOTAクライアントへ送信される。
【0188】
OTAクライアント・コンテキストがプリミティブ「ダウンロードNackInd」を受信した場合、
−OTAクライアント・コンテキストが「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0189】
OTAクライアント・コンテキストがプリミティブ「認証Rsp」を受信した場合、
−OTAクライアント・コンテキストが「相互認証」状態でなければプリミティブは無視され、手続きは継続されない。
−保存された乱数の値が、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵SIKにより暗号化される。
−前段階で暗号化された値がOTAクライアント応答番号フィールドの値と合致しない場合、OTAクライアント・コンテキストは「アイドル」状態に進み、継続されない。
−OTAサーバは「能力要求」状態に進む。
−プリミティブ「能力Req」が送信される。
【0190】
OTAクライアント・コンテキストがプリミティブ「能力Rsp」を受信した場合、
−OTAクライアント・コンテキストが「能力要求」状態でなければプリミティブは無視され、手続きは継続されない。
−プリミティブに含まれる能力が、ダウンロードされるソフトウェアと互換性を有していない場合、OTAクライアント・コンテキストは「アイドル」状態に進む。
−プリミティブに含まれる能力がダウンロードされるソフトウェアと互換性を有する場合、OTAクライアント・コンテキストは「ダウンロード受理」状態に進み、プリミティブ「ダウンロード記述Req」が送信される。
【0191】
OTAクライアント・コンテキストがプリミティブ「ダウンロード受理Cnf」を受信した場合、
−OTAクライアント・コンテキストが「ダウンロード受理」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「ソフトウェア・ダウンロード」状態に進む。
−ソフトウェアのダウンロードが開始される。
【0192】
OTAクライアント・コンテキストがプリミティブ「ダウンロード受理Rej」を受信した場合、
−OTAクライアント・コンテキストが「ダウンロード受理」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0193】
OTAクライアント・コンテキストがプリミティブ「ライセンスReq」を受信した場合、
−OTAクライアント・コンテキストが「ソフトウェア・ダウンロード」状態でなければプリミティブは無視され、手続きは継続されない。
−手続きは「インストール」状態に進む。
−復号化鍵を含む、プロトコル・プリミティブ「ライセンスRsp」が送信される。
【0194】
OTAクライアント・コンテキストがプリミティブ「ライセンスCnf」を受信した場合、
−OTAクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−プリミティブ「テスト記述Req」が送信される。
【0195】
OTAクライアント・コンテキストがプリミティブ「ライセンスRej」を受信した場合、
−OTAクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0196】
OTAクライアント・コンテキストがプリミティブ「インストールCnf」を受信した場合、
−OTAクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0197】
OTAクライアント・コンテキストがプリミティブ「インストールRej」を受信した場合、
−OTAクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0198】
データがOTAサーバからOTAクライアントへ転送されるウィンドウ・プロトコルの動作について以下に記述する。
【0199】
OTAサーバの観点から、ソフトウェアのダウンロードが開始された際に、基本ソフトウェアは、例えば、暗号化鍵および例えばAESアルゴリズム等、公知の種類の暗号化アルゴリズムにより暗号化される。
【0200】
暗号化された基本ソフトウェアは、例えば、1〜2kBytes等の限られたサイズを有するブロックに分割される。基本ソフトウェアが分割された無線ブロックの個数に等しい個数のビットを有するビット・マスクBITMASKが割当てられて、各々のビットに値「0」が設定される。マスクの各ビットは、無線ブロックに対応しており、その番号はビット位置に等しい。すなわち、第一ビットは第一無線ブロックに、第二ビットは第二無線ブロックに対応しており、以下同様である。基本ソフトウェアを構成する先頭のN個の無線ブロックBLOCKが送信される。タイマーT401が始動される。各メッセージAckを受信したならば以下が行なわれる。
−タイマーT401が再開される。
−メッセージAckのビットマップに存在する各々の値「1」に対して、対応する位置に割当てられたマスクBITMASKの値が「1」に設定される。
−未送信ブロックを最初に考慮して、マスクBITMASK内で値「0」に対応する高々先頭のN無線ブロック・ブロックが送信される。
−マスクBITMASKの全てのビットが「1」に等しい値になった時点でダウンロードが終了する。
【0201】
OTAクライアントの観点から、ソフトウェアのダウンロードが開始された際に、当該ソフトウェアが分割された無線ブロックの個数に等しいビット・マスクBITMASKが割当てられて、各々のビットに値「0」が設定される。マスクの各ビットは、無線ブロックに対応しており、その数はビット位置に等しい。すなわち、第一ビットは第一無線ブロックに、第二ビットは第二無線ブロックに対応しており、以下同様である。次いで、タイマーT400が始動される。各無線ブロックBLOCKを受信したならば以下が行なわれる。
−タイマーT400が再開される。
−受信した無線ブロックのブロック番号に対応するマスクBITMASKのビットが「1」に設定される。
−マスクBITMASKに対応するビットマップと共にメッセージAckが送信される。
−マスクBITMASKの全てのビットが「1」に等しい値になった時点でダウンロードが終了する。
【0202】
要約するに、上例によれば、OTAクライアントおよびOTAサーバの機能的な挙動は以下の通りである。
−ダウンロード・手続きは、例えば、MSC(移動スイッチングセンター)により基地局コントローラBSCへ送信されたプロトコル・メッセージ「ハンドオーバー・コマンド」を受信した時点で開始される。
−OTAクライアントとOTAサーバとの間の相互認証は、例えば、「チャレンジ応答」方式に従い生起する。
−ダウンロードされる基本ソフトウェアは、トラフィック・チャネル、例えばGPRトラフィック・チャネルへ送信される。
−ダウンロードされる基本ソフトウェアは、OTAサーバにより小さいサイズ(例:1または2キロバイト)のブロックに分割される。
−基本ソフトウェアの転送は簡単なウィンドウ・プロトコルにより管理され、その際にサイズ・ウィンドは基本ソフトウェアが分割されたブロックの個数と合致する。
−ダウンロードされた基本ソフトウェアは暗号化することができ、その場合、復号化およびインストールのために鍵が必要とされる。
−基本ソフトウェアを開始する前に、OTAクライアントは、例えばOTAサーバにより提案された適切なテストによりこれを検証する。
【0203】
図18を参照するに、標準に定義されている通り、回線呼に対するGSMからのUMTSへのシステム間ハンドオーバー手続きの適用可能な例を示しており、この中で端末MSを再設定可能な基本ソフトウェアのダウンロード・手続きが導かれている。
【0204】
図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」を受信して、「アイドル」状態に戻る。
【0205】
図19に開示した手続きは、基本ソフトウェアのダウンロード・手続きを示すものである。
【0206】
本手続きは、当業者には理解されるように、標準に定義された回線呼用のGSMからUMTSへのシステム間ハンドオーバー手続きに組込まれていてよい。
【0207】
特に、組込みは、MSCから基地局サブシステム・アプリケーション部(BSSAP)プロトコルの「ハンドオーバー・コマンド」メッセージを受信してから、MSへRRプロトコルの「システム間からUTRANへのハンドオーバー・コマンド」メッセージを送信する間に、RR層において行なうことができる。
【0208】
本発明は、現在の基準により定義されている全ての可能なシステム間ハンドオーバー手続きに一般化することができる。
【0209】
例えば、当業者には理解されるように、本手続きは、標準に定義の通り、回線呼用のUMTSからGSMへのシステム間ハンドオーバー手続きに組込むことができる。特に、組込みは、MSCから無線アクセス・ネットワーク・アプリケーション部(RANAP)プロトコルの「再配置コマンド」メッセージを受信してから、ユーザー設備(UE)へ無線リソース制御(RRC)プロトコルの「UTRANからのハンドオーバー・コマンド」メッセージを送信するまでの間に、無線リソース制御(RRC)層で行なうことができる。
【0210】
本発明はまた、未だ標準化されていないシステム間ハンドオーバー手続き、例えば、国際移動通信2000(IMT2000)およびWLANまたはIEEE802.16あるいはIEEE802.20システム間のシステム間ハンドオーバー手続きとして一般化することができる。
【0211】
当業者には明らかなように、本発明は、音声通話の場合、特に回線方式呼において、呼を中断することなく基本ソフトウェアのダウンロードの実行を可能にする。これは、例えば、1個以上のパケット・チャネル、例えばPDTCH GPRSチャネルを割当てることにより、回線通信に利用される回線方式チャネル、例えばTCH(トラフィック・チャネル)GSMチャネルと並行して、GSM/GPRSの場合に可能である。
【0212】
この特徴により、音声、データ、およびソフトウェアのダウンロードの間での優先順位付けを管理することができる。
【0213】
本発明は、GSM/GPRSシステムを参照するに、上述のシステムの無線チャネルを用いることにより開示されているが、当業者には理解されるように、本発明は例えば「汎用」チャネルを用いて適用されてもよい。
【0214】
「汎用」チャネルを用いることができる例として、文献に記載の通り、OTAサーバからOTAクライアントへの基本ソフトウェアのダウンロード手続きへの「汎用」チャネルの使用が挙げられる。
【0215】
システム間ハンドオーバーの場合、「汎用」チャネルを使用する実装方式により、例えば図18に開示した手続きを採用して、OTAサーバからOTAクライアントへの基本ソフトウェアのダウンロード手続きを上述の「汎用」チャネルを介して同時に利用しながら、例えばGSM/GPRSシステム等のアクティブなシステムの無線チャネルを介したアクティブな接続を維持することが予見できる。
【0216】
「汎用」チャネルは、基本ソフトウェアのダウンロード手続きの全体または一部、例えばOTAサーバからOTAクライアントへの基本ソフトウェアの送信、だけに利用することができる。
【0217】
「汎用」チャネルを部分的に利用する場合、基本ソフトウェアのダウンロード手続きの残りの部分は、アクティブなシステムの無線チャネルを用いて実装することができる。
【0218】
「汎用」チャネルを採用することにより、アクティブなシステムに関連付けられた無線リソースをより効率的にロードして、他のユーザーが利用できるようにして、基本ソフトウェアのダウンロード手続きをはるかに高速に実行することが可能になる。これは、「汎用」チャネルがこの種の動作専用のチャネルであるためである。
【0219】
本発明の更なる実施形態として、当業者には公知のように、例えば、端末が「アイドル」状態である場合に、GSM/GPRSからUMTSへ等、2種のシステム間でセル再選択手続きをも管理可能にすることである。
【0220】
先に述べたように、プリミティブおよび関連フィールドに名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。
【0221】
この拡張は、OTAクライアントと端末MS側の無線リソースRRとの間に以下のプリミティブを導入するものである。
−ダウンロード開始Req:このメッセージは、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0222】
GSM/GPRSの場合、このプリミティブに提供されるフィールドは少なくとも、
OTAクライアントID:要求を実行しているOTAクライアントを識別する
および、OTAサーバと基地局コントローラBSC側の無線リソースRRとの間の以下のプリミティブの組の一つである。
−要求ダウンロード開始Ind:このメッセージは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0223】
GSM/GPRSの場合、プリミティブに提供されるフィールドは、以下のうち少なくとも一組である。
OTAクライアントID:要求を実行しているOTAクライアントを識別する。
【0224】
以下に、プリミティブ「要求ダウンロード開始Ind」を受信した際のOTAクライアント・コンテキストの端末MSに関するコンテキストの応答を示す。
−OTAクライアント・コンテキストが「アイドル」状態ではない場合、プリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「ダウンロード開始」状態へ進む。
−プリミティブ「ダウンロード開始Ind」は、各種の可能なダウンロードを示すと共に、OTAクライアントへ送信される。
【0225】
図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クライアントの識別子をローカルに保存する。
【0226】
本手続きは、図18に関して述べる手続きの第6番以降の段階を実行することにより継続される。
【0227】
GSM/GPRSシステムのアクセス・ネットワークを参照しつつ、本発明に従い記述されたアーキテクチャおよび方法を開示してきた。
【0228】
本発明はまた、UMTS、UTRAN(UMTS地上波無線アクセス・ネットワーク)その他の任意のアクセス・ネットワーク、例えばWLAN、IEEE802.16、IEEE802.20等のアクセス・ネットワークにも適用することができる。
【0229】
例えば、UTRANの場合、本発明はOTAクライアントとOTAサーバおよび関連手続き、プリミティブ並びにプロトコル・メッセージをUMTSシステムのRRC層に組込んで実装することができる。
【0230】
本発明を、アクセス・ネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を用いて開示してきた。本発明はまた、コア・ネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を用いて実装することもできる。この場合、例えばGSM/GPRSおよびUMTSシステムのパケット・スイッチ・コア・ネットワークを考慮すれば、本発明は、OTAクライアントとOTAサーバおよび関連手続き、プリミティブ並びにプロトコル・メッセージをコア・ネットワークの端末およびサービス提供GPRSサポート・ノード(SGSN)ノードの各々のGPRS移動管理(GMM)層に組込むことにより実装することができる。
【0231】
より具体的には、GSM/GPRSの場合、GPRS移動管理(GMM)層は、新規のプロトコル・メッセージを導入して関連フィールドをOTAサーバとOTAクライアントの間で交換することにより変更される。同じ方式をUMTSシステムに適用することもできる。
【0232】
本発明を、システム間ハンドオーバー手続きの実行中における1個の基本ソフトウェアのダウンロードおよび起動を考慮することにより開示してきた。
【0233】
当業者には明らかなように、当該基本ソフトウェアはインストールして直ちに動作させるのではなく、端末にダウンロードして保存してもよい。
【0234】
この更なる実施形態によれば、ネットワークまたはユーザーからの要求があれば、基本ソフトウェアをインストールして引き続き実行させることが可能である。無線端末UE/MSが十分なメモリおよび処理能力を有していれば、ダウンロードされた基本ソフトウェアを、現在動作中の既存システムと並行して保存およびインストールすることができる。
【0235】
このオプションは、端末UE/MSのマルチ・モード動作を可能にするために有用である。すなわち、このオプションにより、基本ソフトウェアをダウンロードする必要なしに、端末をある動作モードから別の動作モードへ切り替えることが可能になる。
【0236】
要約すれば、本発明により、少なくとも以下の利点が得られる。
−ノードまたは物理的なインターフェースが既存のものに一切追加されないため、第二および第三世代ネットワークに存在しているプロトコルおよびノードに対する影響が最小限に抑えられる。
−手続きのシグナリング・フェーズが標準で定義されたものと同一のシグナリング・チャネルを使用する一方、ソフトウェアのダウンロード手続き用途にのみデータ・チャネルが割当てられるため、無線リソースの占有が最小限に抑えられる。
−本発明は既存の第二および第三世代ネットワークを利用するため、従来技術で言及されているように将来的なIP利用UMTSのリリースを待たなくてもよい。
【0237】
特に、アクセス・ネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を使用する場合、RR(無線リソース)プロトコルが、新規の基本ソフトウェアを端末がダウンロードできるようにする若干の変更と一体化されているため、ネットワークはソフトウェアのダウンロード手続きおよび関連する無線リソースを完全に制御することができ、これにより、例えば、GSM/GPRS、IS95、PDC(デジタル・セルラー電話)、あるいは例えばファミリIMT2000に属する第三世代セルラー方式等の第二世代のセルラー方式を実装することができる。
【図面の簡単な説明】
【0238】
【図1】従来技術による多モード端末を表わす図である。
【図2】本発明の一実施形態によるGSM/GPRシステムのネットワーク・アーキテクチャを示す図である。
【図3】図1のアークテクチャの再設定可能な端末を表わす図である。
【図4】無線端末側でクライアントにより実行されるプロトコル・ステップの状態遷移図である。
【図5】基地局コントローラ側でサーバにより実行されるプロトコル・ステップの状態遷移図である;
【図6】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図7】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図8】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図9】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図10】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図11】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図12】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図13】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図14】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図15】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図16】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図17】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図18】回線呼に対するGSMからUMTSへのシステム間ハンドオーバー手続きを示す図である。
【図19】無線端末を再設定するソフトウェアのダウンロード手続きの詳細を示す図である。
【図20】セル再選択の場合における基本ソフトウェアのダウンロード手続きを示す図である。
【技術分野】
【0001】
本発明は一般に、無線通信ネットワークおよび無線通信ネットワークを用いる再設定可能な無線端末に関する。
【0002】
より具体的には、本発明は無線端末の再設定に注目し、前記再設定は、無線通信ネットワークから地上波(OTA)を介してダウンロードした基本ソフトウェアを前記無線端末にインストールすることにより実行される。
【背景技術】
【0003】
文献(J.ミトラ(Mitola)、「ソフトウェア無線アーキテクチャ」、IEEE 通信学会誌、1995年5月、およびE.ブラッチーニ(Buracchini)、「ソフトウェア無線の概念」、IEEE通信学会誌、2000年9月)により、端末、基地局、およびネットワーク・ノード等の再設定可能なシステムは、基本動作モードが再設定可能な設備であることが知られている。例えば、GSM/GPRS(移動通信用グローバルシステム/汎用パケット無線サービス)等の第二世代システム(2G)で動作できる再設定可能な無線端末は、UMTS(ユニバーサル移動電気通信システム)またはCDMA2000(符号分割多重アクセス2000)等の第三世代システム(3G)、DVB−T(デジタルビデオ地上波放送)、またはWLAN(無線ローカル・エリア・ネットワーク)システム等で動作可能にすべく再設定することが可能である。
【0004】
本開示において、用語「システム」は、例えば通信ネットワークとして動作する特定の機能を実行すべく所定の基準に従い相互に調整された、すなわちある「標準」に従い調整されている複数の要素を意図している。
【0005】
本明細書において、システムの例としてGSMシステム、GPRSシステム、UMTSシステム、WLANシステム等があり、その各々が対応する標準に準拠している。
【0006】
端末の再設定を実行するには、上述の文献によれば、再設定可能な技術により端末の動作機能が実現されることが必要である。これに注目するならば、再設定可能な端末または装置には、例えば、複数のFPGA(フィールド・プログラム可能ゲートアレイ)、DSP(デジタル信号プロセッサ)およびマイクロプロセッサで構成された再プログラム可能なハードウェアが備えられていて、装置の個々の機能は、最低水準であっても、ソフトウェア・コードにより実行される。その結果、再プログラム可能な装置を再設定するには、装置自体のハードウェアを管理している基本ソフトウェアを交換すれば十分である。用語「基本ソフトウェア」は、本明細書の記述では、ライブラリとして編成されたソフトウェアを意味し、例えばGSM/GPRS、UMTS等の考慮対象システムのプロトコル・スタックの無線インターフェース(例:L1、L2、L3)および上位層(例:L4からL7まで)を定義している。
【0007】
公知のように、電気通信分野において、機能群のグループ化を行なうために最もよく利用される方法がOSIモデル(開放型システム相互接続)である。機能群は、スタックの形式で表わされる機能平面にグループ化される。
【0008】
プロトコル・スタックの各層は、直上の層に対してサービスを提供し、ここに当該サービスは直下の層が提供するサービスの改善されたものである。
【0009】
最下位層(層1)は一般に、情報の物理的送信を目的とする。
【0010】
OSI仕様によれば、標準的な層の数は7であり、各々物理、接続、ネットワーク、トランスポート、セッション、プレゼンテーション、およびアプリケーション層である。
【0011】
例えばGSM/GPRS、UMTS等の各システムは、OSIプロトコル・スタックの必要な部分を実装している。
【0012】
無線端末を考慮する場合、再設定可能なハードウェアを使用する際の利点は多いが、一つの利点が明らか即効的である。すなわち、無線端末は、当該端末が位置する領域(動作領域)をカバーするシステムにより再設定可能である。従って、端末がGSM/GPRS等の第二世代システムがカバーする領域内で用いられた場合、前記システムを受信可能にすべく当該端末を再設定することができる。同様に、UMTS等の第三世代システムがカバーする領域内では端末を適宜設定することができる。
【0013】
文献(AA.VV.「ソフトウェア無線:再設定可能な端末の課題」、電気通信年報2002年7月/8月、GETエルメス(Hermes)、E.ブラッチーニ(Buracchini)「ソフトウェア無線の概念」)により、下記のように少なくとも3種の異なる方法でソフトウェア・コードを端末へ転送またはダウンロードできることが知られている。
−無線移動端末に組込まれたSIM(加入者識別モジュール)を用いることによりスマートカードを介する方法。
−例えば赤外線/シリアル/USB(ユニバーサル・シリアルバス)ポート経由でのパソコンとのリンクを使用する外部接続を介する方法。
−特定の無線チャネルを用いることにより無線または地上波(OTA)を介する方法。
ソフトウェアのダウンロードに関して、端末へのソフトウェアのダウンロードを管理可能にする一般的なプロトコルの基本的なステップは、www.sdrforum.orgというURLを介して入手可能なソフトウェア無線フォーラム(SDRフォーラム)のフレームワークに定義されている。
【0014】
SDRFで定義されているプロトコルは、公知のクライアント−サーバ方式のものである。
【0015】
ダウンロードのプロトコル・ステップは以下の通りである。
−ダウンロード開始:ソフトウェアのダウンロードを開始する意図を以って、ダウンロードされるソフトウェアが常駐しているサーバと端末が通信するステップ。
−相互認証:端末とサーバは互いに認証しなければならない。
−能力相互通知:サーバは、ダウンロードされるソフトウェアに関する能力情報を通知し、端末は当該ソフトウェアを端末メモリへのロード、インストールおよび実行が可能であるか否かを検証する。
−ダウンロード受理:サーバが端末との間で、ダウンロード、インストール、および支払請求オプションを通信する。端末は、サーバから提供された指示が受理可能か否かを決定する。
−ダウンロードおよび完全性テスト:ソフトウェアをダウンロードする間、受信されたコードをテストしなければならない。端末は、不正確に受信された無線ブロックの再送を要求する。
−インストール:インストールステップの間、ソフトウェアの支払請求およびライセンス条件がサーバから提供される。
−現場テスト:ソフトウェアの実行を開始する前に、端末は、ソフトウェア・コードと共にダウンロードされたテスト・ベクトルの支援を受けていくつかのテストを実施する。
−否認防止相互通知:一旦ソフトウェア・コードがインストールされて、テストされたならば、端末はサーバに対し、インストールが成功した旨を確認して支払請求手続きを開始する。
【0016】
従来技術、例えばE.ブラッチーニ(Buracchini)、「ソフトウェア無線の概念」、IEEE通信学会誌2000年9月)により、無線またはOTAを介したソフトウェアのダウンロードは無線チャネルの端末による利用を想定していることが知られている。上述した文献によれば、無線チャネルの種別に応じてソフトウェア・コードを2種の異なる方式のダウンロードすることが知られている。
−「帯域外」方式:現行システムから独立した「ユニバーサル」チャネルにより、端末がスイッチ・オンされた際に、自動的に当該チャネルに同調して、動作領域で動作しているシステムに関する基本ソフトウェアのダウンロードを実行する。
−「帯域内」方式:各々GSM/GPRSおよびUMTS等である、第二および第三世代の標準セルラー・システムの無線チャネルを用いて、これらのチャネルで既に動作している端末が、現在使用されているものとは異なるシステムに関する基本ソフトウェアを受信する。例えば、GSM/GPRS等の第二世代システムにより動作する再設定可能な端末が、自身が動作している第二世代の無線チャネルを用いて、UMTS等第三世代システムのダウンロードを実行することができる。
【0017】
「帯域外」ソフトウェアのダウンロードの例が、例えば日本特許出願第2001061186号公報に記載されている。当該文献は、ソフトウェア・コンテンツを地上波経由でダウンロードするシステムおよび方法を記述している。無線端末がスイッチ・オンされた際に、当該動作領域における現行システムが何であるかをユニバーサル・チャネルに問い合わせ、指示されたシステムに関するソフトウェアをダウンロードする。
【0018】
「帯域外」モードを考慮するに、従来技術によれば専用の無線チャネルの実装が必要であり、従って、その実施のためのネットワークにおける専用設備が必要である。
【0019】
「帯域内」ソフトウェアのダウンロードの例が、例えば米国特許出願公開第2003/0163551号に記載されている。当該文献は、サーバと端末間の交渉(能力相互通知、認証、支払請求等)ステップの間に専用チャネルを用いて、且つ利用可能な無線リソースに負荷をかけることなく極力多くのユーザーに対して同時にダウンロード・サービスを提供すべくダウンロード・手続きの間に共有共通チャネルを用いて、地上波経由でソフトウェアをダウンロードするシステムおよび方法を記述している。
【0020】
「帯域内」ダウンロード方式を考慮する際に、文献AA.VV.「再設定可能端末に対応したIP利用に基づくネットワーク要素のアーキテクチャ」、SCOUTワークショップ、2003年9月16日、およびIST−2001−34091SCOUT、D4.1.1、「セルラーおよびアドホック・ネットワークにおけるIP原理に基づくダウンロード・トラフィックに対するネットワークおよびセキュリティ・アーキテクチャ要件並びにトラフィック管理スキーム」で、ある種のプロトコルおよびある種のネットワーク・ノードを大幅に変更することを提案している。例:基本ソフトウェアのダウンロードの管理を可能にすべく、コア・ネットワークがIP(インターネット・プロトコル)に完全準拠しているUMTSのリリース5以降に基づく無線アクセス・ノードおよび/またはコア・ネットワーク・ノード。
【0021】
このような変更は、設備製造業者およびネットワーク・オペレータの相当な努力を要し、既存のセルラー・システムの標準に劇的な影響を及ぼす恐れがある。
【0022】
従って、既知の「帯域内」技術には、例えばGSM/GPRSまたはUMTS等の既存のセルラー・ネットワークに再設定可能な端末の基本ソフトウェアのダウンロード管理の追加が求められた場合に、プロトコルおよびネットワーク・ノードに対する大幅な変更が必要になるという制限を示す。
【0023】
出願人は、「帯域内」方式および「帯域外」方式の両方の場合において公知の従来技術では、ある種のプロトコルおよびある種のネットワーク・ノードに大幅な変更が施される点に注目する。
【0024】
公知の従来技術における更なる問題は、現行標準によるシステム間ハンドオーバーの管理である。
−GSM/GPRシステムからUMTSシステムへのハンドオーバー
−UMTSシステムからCDMA2000システムへのハンドオーバー
−UMTSシステムからGSM/GPRシステムへのハンドオーバー
−CDMA2000システムからUMTSシステムへのハンドオーバー
【0025】
公知の標準によれば、システム間ハンドオーバーは、多モード端末、すなわちASIC(特定用途向け集積回線)技術を用いて各々のセルラー・システムのプロトコル・スタック全体をサポートする端末を必要とする。
【0026】
例えば図1を参照するに、RAT−GSM/GPRSと呼ばれるGSM/GPRSシステムの全体的な無線プロトコル・スタック、RAT−UMTSと呼ばれるUMTSシステムの全体的な無線プロトコル・スタック、およびRAT−CDMA2000と呼ばれるCDMA2000システムの全体的な無線プロトコル・スタックを含む多モード端末を示している。
【0027】
公知の解決策には、電力消費が多い、装置サイズが大きい、および実装コストが高い等、いくつかの短所がある。
【特許文献1】日本特許出願第2001061186号公報
【特許文献2】米国特許出願公開第2003/0163551号
【非特許文献1】J.ミトラ(Mitola)、「ソフトウェア無線アーキテクチャ」、IEEE 通信学会誌、1995年5月
【非特許文献2】E.ブラッチーニ(Buracchini)、「ソフトウェア無線の概念」、IEEE通信学会誌、2000年9月
【非特許文献3】AA.VV.「ソフトウェア無線:再設定可能な端末の課題」、電気通信年報2002年7月/8月、GETエルメス(Hermes)、E.ブラッチーニ(Buracchini)「ソフトウェア無線の概念」
【発明の開示】
【発明が解決しようとする課題】
【0028】
要約すれば、出願人は公知の従来技術について以下の点に注目する。
−例えば新規のノードやインターフェースの追加、および標準により定義されたデータのシグナリングおよび転送プロトコルの変更等、無線リソースの非効率的な利用につながるネットワーク・ノードに対する大幅な変更なしにはソフトウェアをダウンロードする課題が解決されない。
−システム間ハンドオーバーの管理のために再設定可能な端末を利用することができない。
【課題を解決するための手段】
【0029】
従って、ネットワーク・ノードおよび関連プロトコルを大幅に変更することなく無線端末を設定する基本ソフトウェアをダウンロードする方法および通信ネットワークを提供することが本発明の目的である。
【0030】
更に、設定可能な端末を用いてシステム間ハンドオーバー手続きを可能にする方法および通信ネットワークを提供することも本発明の更なる目的である。
【0031】
上述の目的は、添付の請求項に記載されている方法および通信ネットワークにより達成される。
【0032】
更に、本発明の目的は、コンピュータ・プログラム生成物またはコンピュータ・プログラム生成物の組により達成され、当該生成物は少なくとも1個のコンピュータのメモリにロード可能であって、請求項に従い当該生成物がコンピュータ上で実行された場合に本発明の方法のステップを実行するソフトウェア・コード部分を含んでいる。以下で用いるように、そのようなコンピュータ・プログラム生成物への参照は、本発明の方法の実行を調整すべくコンピュータ・システムを制御する命令を含むコンピュータ可読媒体への参照と等価である。「少なくとも1個のコンピュータ」との表現は明らかに、本発明の方法が分散モジュール方式で実装される可能性を強調することを意図している。
【0033】
好適な実施形態において、無線端末を再設定する基本ソフトウェアのダウンロードは、標準に関して、端末内および、例えばネットワークのBSC(基地局コントローラ)またはRNC(無線ネットワーク・コントローラ)の無線コントローラ等、ネットワーク内の少なくとも1個のノード内の無線プロトコル・スタックの単一の層だけを変更することにより実現される。
【0034】
本発明によれば、変更された層のプロトコルは、SDR−Forumから提供される推奨事項と整合している。
【0035】
本発明の好適な実施形態によれば、そこから基本ソフトウェアをダウンロードが可能であるサーバは、ネットワークの無線コントローラ、例えばBSCまたはRNC等に常駐している。
【0036】
本発明がもたらす利点には以下のものがある。
−ソフトウェアのダウンロード・サービスは透過的であり、他の任意のシグナリングおよびトラフィック・データフローとしてネットワークから見える。
−既存且つ将来の標準の全ての特徴を完全に利用することにより、無線リソースの効果的且つ柔軟な利用が可能である。
−呼を中断することなく基本ソフトウェアをダウンロードするために、例えば回線呼の最中にパケット接続を確立することが可能である。
−異なるデータフロー同士を区別して、それらの優先順位(例:音声、データおよびソフトウェアのダウンロード)を管理することが可能である。例えば、音声通話の優先順位がソフトウェアのダウンロードの優先順位より高い場合、ソフトウェアのダウンロード自体を一時的に中断して、逐次前記ダウンロードを再開することができる。
【0037】
更に、本発明は、再設定可能端末を利用してシステム間ハンドオーバーの管理を可能にする。
【0038】
実際に、本発明の好適な実施形態によれば、サポート対象システム上で測定を実行するための最小限の機能だけが端末の物理層に実装されていれば十分である。
【0039】
例えば、GSM/GPRSシステムにより動作すべく設定されていて、UMTSシステムへのシステムハンドオーバーを管理する準備が整っている端末を想定する。本発明によれば、GSM/GPRSシステムの無線インターフェースの全体的なプロトコル・スタックにより設定されている端末は、UMTSシステムの能力測定を実行するための最小限の物理層機能だけを備えている。
【0040】
システム間ハンドオーバーは、GSM/GPRS無線チャネルを介してUMTS基本ソフトウェア全体を端末内にダウンロードし、UMTSシステムに従い端末を再設定して、GSM/GPRSシステム上で能力測定を実行するための最小限の物理層機能を提供することにより管理される。
【0041】
本発明を、その好適な、ただし限定的ではない実施形態の添付図面を参照しながら以下に開示する。
【0042】
全ての図を通じて、同等であるか、または実質的に等価な機能を実装する構成要素を示すために同一参照番号を用いている。
【発明を実施するための最良の形態】
【0043】
図2を参照するに、再設定可能な端末または移動局MS、基地送受信局BTSすなわちBTSノード、および基地局コントローラBSCすなわちBSCノードを含むGSM/GPRSシステムのネットワーク・アーキテクチャを示す。
【0044】
ネットワークは更に、例えば、図2に示していない移動スイッチング・センター(MSC)および/またはサービングGPRSサポート・ノード(SGSN)および/またはゲートウェイGPRS サポート・ノード(GGSN)等のコア・ネットワーク・ノードを含んでいる。
【0045】
端末MSは、BSCノードに接続されているBTSノードに、無線インターフェースを介して接続されている。
【0046】
本発明の好適な実施形態によれば、端末MSは、OTAクライアントと呼ばれる第一のエンティティと、無線リソース・プロトコルRRと呼ばれる公知の種類の第二のエンティティとを含んでいる。OTAクライアントは、無線リソース・プロトコルRRと同一プロトコル・レベルまたは層にあってこれと協働する。
【0047】
RRエンティティは、例えば、GSM/GPRS標準ETSI04.18に従い動作し、以下に開示するように、基地局コントローラBSC内でOTAクライアントおよびRR対応エンティティと通信するための機能を含んでいる。
【0048】
OTAクライアントは、基本ソフトウェアの全体または一部を、OTAサーバと呼ばれる基地局コントローラBSC内のOTA対応エンティティからダウンロードする手続きを完全に管理することが可能なソフトウェア・モジュールを含んでいる。
【0049】
BSCは、OTAサーバと呼ばれる第一のエンティティ、および無線リソース・プロトコルRRと呼ばれる公知の種類の第二のエンティティを含んでいる。
【0050】
OTAサーバは、同一プロトコル・レベルにあって、無線リソース・プロトコルRRと協働する。
【0051】
RRエンティティは、例えば、GSM/GPRS標準ETSI04.18に従い動作し、以下に開示するように、移動端末MS内でOTAサーバおよびRR対応エンティティと通信するための機能を含んでいる。
【0052】
OTAサーバは、基本ソフトウェアの全体または一部をOTAクライアントへダウンロードする手続きを完全に管理することが可能なソフトウェア・モジュールを含んでいる。
【0053】
OTAサーバは更に、基本ソフトウェアを含んでいるか、または、これを修復することが可能である。
【0054】
OTAサーバのアーキテクチャは、以下に開示するように、アクティブなダウンロード・セッションを有する各OTAクライアントに対してクライアント・コンテキストと呼ばれるコンテキストを提供する。
【0055】
図3に、本発明に従い設定された端末MSを示す。
【0056】
端末MSは、GSM/GPRSプロトコルの上位層および下位層を含んでいる。
【0057】
下位層はRAT(無線アクセス技術)GSM/GPRSと呼ばれ、GSM/GPRS標準に従いOTAクライアント、無線リソースRR、物理(L1)およびDL(データリンク)(L2)の各エンティティを含んでいる。
【0058】
端末MSは、更なる標準、例えばUMTS標準に従い物理層(L1U)を含み、少なくとも当該更なる標準に準拠して層1の測定を実行する機能を更に含んでいる。
【0059】
開示した端末MSは、以下に開示するように更なる標準の基本ソフトウェアをダウンロードすることにより再設定可能である。
【0060】
本発明の好適な実施形態で想定されているように、基本ソフトウェアは一組の基本ソフトウェア・モジュール、好適には所定の通信システムに従い端末MSを設定する複数のソフトウェア・モジュールを含んでいる。
【0061】
本発明は、例えば更に所定の通信システムに従って無線端末MSを設定するために用いるプロトコル・スタックを構成する全ての基本ソフトウェア・モジュールのダウンロードを可能にする。
【0062】
当業者には理解されるように、本発明の更なる実施形態によれば、使用中の通信システムまたは別の通信システムに対応するプロトコル・スタックの一部だけで構成されたソフトウェア・モジュールをダウンロードすることも可能である。
【0063】
そのような更なる実施形態は、例えば、端末MSに新規機能、更新版またはバグ修正を加える目的に有用であろう。
【0064】
図4を参照するに、端末MSにおけるOTAクライアントの状態遷移図を示す。
【0065】
状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
本発明の好適な実施形態によれば、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クライアントは「アイドル」状態に戻る。
【0066】
図5を参照するに、OTAサーバが管理するクライアント・コンテキストの状態遷移図を示す。
【0067】
先に述べたように、状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
【0068】
クライアント・コンテキストの状態および相対遷移は以下の通りである。
−「アイドル」状態:アクティブなソフトウェア・ダウンロード・手続きが存在しない場合、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クライアントによるインストールの成功に関する確認応答信号を受信したならば、「アイドル」状態に戻る。
【0069】
GSM/GPRSの場合、本発明の好適な実施形態において、RRプロトコルは、以下に図6〜17を参照しながら詳述するように、新規プロトコル・メッセージを導入することにより変更され、関連するフィールドをOTAサーバとOTAクライアントの間で交換される。
【0070】
異なるシステムの場合、当業者には理解されるように、例えばUMTSシステムにおけるRRC(無線リソース制御)等の無線リソース・プロトコルが同様の方法で変更される。
【0071】
以下に、メッセージおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。
【0072】
図6を参照するに、「パケット・ダウンロード要求」メッセージの構造を記述している。このメッセージは、基地局コントローラBSC側にある無線リソースRRから端末MS側の無線リソースRRへ送信される。
【0073】
OTAサーバはこのメッセージを用いて、OTAクライアントに対しダウンロード・セッションを開始するよう指示する。
【0074】
提供されるフィールドは、GSM/GPRSの場合、少なくとも以下のうち1組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロード要求)を識別する。
−OTAクライアントID:要求を実行する対象であるOTAクライアントを識別する。
−PDCH(パケット・データチャネル):ソフトウェアのダウンロードが実行されるネットワークにより割当てられたチャネルを指定する。
−RRBP(相対予約ブロック期間):標準GPRSで既に定義されている通り、端末MS側の無線リソースRRが応答する無線ブロックを指定する。
−要求されたダウンロード:この要素は、ネットワークによる要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。
【0075】
図7を参照するに、「パケット・ダウンロードAck」メッセージの構造を記述している。このメッセージはOTAクライアントからOTAサーバへ送信される。
【0076】
OTAクライアントは、このメッセージを用いて、ダウンロード・セッションの開始の確認をOTAサーバに通知する。
【0077】
提供されるフィールドは、GSM/GPRSの場合、少なくとも以下のうち1組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロードAck)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント・チャレンジ番号:相互認証の第一ステップを実行すべく、OTAサーバが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズム(高度暗号化標準)を以って暗号化する乱数である。
【0078】
図8を参照するに、「パケット・ダウンロードNack」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバにダウンロード・セッションを開始することができない旨を通知する。
【0079】
提供されるフィールドは、GSM/GPRSの場合、少なくとも以下のうち1組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロードNack)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0080】
図9を参照するに、「パケット認証要求」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、自身の証明をOTAクライアントに通知し、OTAクライアントにそれを確認することが要求する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット認証要求)を識別する。
−OTAクライアントID:メッセージを送信するOTAクライアントを識別する。
−OTAサーバ応答番号:相互認証の第一のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAサーバにより暗号化される番号である。
−OTAサーバ・チャレンジ番号:相互認証の第二ステップを実行すべく、OTAクライアントが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
−RRBP:標準GPRSで既に定義されているように、端末MS側の無線リソースRRが応答する無線ブロックを指定する。
【0081】
図10を参照するに、「パケット認証応答」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、既にOTAサーバを認証した状態で、OTAクライアントは自身の証明をOTAサーバに通知する。GSM/GPRSの場合に提供されるフィールドは、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット認証応答)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント応答番号:相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAクライアントにより暗号化される番号を識別する。
【0082】
図11を参照するに、「パケット能力要求」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、OTAクライアントに対しその再設定可能性オプションを要求する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット能力要求)を識別する。
−OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。
−RRBP:標準GPRSに既に定義されている通り、端末MS側の無線リソースRRが応答する無線ブロックを指定する。
【0083】
図12を参照するに、「パケット能力応答」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントは、自身の再設定可能性オプションをOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット能力応答)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント能力:端末の再設定可能性オプションを記述する。
【0084】
図13を参照するに、「パケット・ダウンロード記述」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、ダウンロードに関するデータをOTAクライアントに報告する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロード記述)を識別する。
−OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。
−ダウンロード・リスト:各ダウンロードにつきOTAクライアントにより選択された1個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
−ダウンロード・ブロック番号:OTAクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
−支払請求基準:起こり得るダウンロード支払請求に関する基準である。
−インストール基準:ソフトウェアのインストールに関する基準である。
−RRBP:標準GPRSに既に定義されている通り、端末MS側の無線リソースRRが応答する無線ブロックを指定する。
【0085】
再び図8を参照するに、「パケット・ダウンロード受理」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントがダウンロードを確認する。
【0086】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロード受理)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0087】
再び図8を参照するに、「パケット・ダウンロード拒否」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはダウンロードを拒否する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ダウンロード拒否)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0088】
再び図8を参照するに、「パケット・ライセンス要求」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバに対し、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵を要求する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ライセンス要求)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0089】
図14を参照するに、「パケット・ライセンス応答」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバは、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵をOTAクライアントに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ライセンス応答)を識別する。
−OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。
−復号化鍵:基本ソフトウェアを復号化するために用いられる鍵である。
【0090】
再び図8を参照するに、「パケット・ライセンス受理」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントは、ダウンロードされた基本ソフトウェアが正しく復号化された旨をOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ライセンス受理)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0091】
再び図8を参照するに、「パケット・ライセンス失敗」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントは、ダウンロードされた基本ソフトウェアが正しく復号化されなかった旨をOTAサーバに通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・ライセンス失敗)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0092】
図15を参照するに、「パケット・テスト記述」メッセージの構造を記述している。このメッセージは、OTAサーバからOTAクライアントへ送信される。このメッセージを用いて、OTAサーバはOTAクライアントに対し、ダウンロードされた基本ソフトウェアを開始する前に実行すべきテストを指示する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・テスト記述)を識別する。
−OTAクライアントID:メッセージの宛先であるOTAクライアントを識別する。
−テスト・リスト:実行すべき各々のテストについて1個の要素を含み、これは更に以下のフィールドを含んでいる。
−テスト・ベクトル:テストの記述を含んでいる。
【0093】
再び図8を参照するに、「パケット・インストール成功」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功した旨を通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・インストール成功)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0094】
再び図8を参照するに、「パケット・インストール失敗」メッセージの構造を記述している。このメッセージは、OTAクライアントからOTAサーバへ送信される。このメッセージを用いて、OTAクライアントはOTAサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功しなかった旨を通知する。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(パケット・インストール失敗)を識別する。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
【0095】
基本ソフトウェアは、好適な実施形態において、例えば、以下に述べるBlockおよびAckと呼ばれる2種類の基本プロトコル・データ・ユニットすなわちPDUに基づいて公知の種類のウィンドウ・プロトコルを使用することにより、OTAサーバからOTAクライアントへ送信される。
【0096】
図16を参照するに、基本ソフトウェアが分割される無線ブロックBlockの構造を記述している。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:ブロック種別を識別する。
−ブロック番号:無線ブロックのシーケンス番号を識別する。OTAクライアントがこのシーケンス番号を用いて、基本ソフトウェア全体を再構成する。
−データ:基本ソフトウェア全体のいくつかの部分を含むフィールドである。
【0097】
図17を参照するに、端末の受信状態を示すために用いるメッセージAckの構造を記述している。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−メッセージ種別:送信されたメッセージの種別(Ack)を識別する。
−Ackビットマップ:基本ソフトウェアが分割された無線ブロックの総数に等しいサイズを有するビット・マスクである。各々の無線ブロックについて、当該ブロックが首尾よく受信された場合は「1」にセットされ、ブロックが受信されたものの損傷しているかまたは全く受信されなかった場合は「0」にセットされる。
【0098】
本発明の好適な実施形態が想定するRRプロトコルに対する変更は、OTAクライアントと端末MS側の無線リソースRRとの間にプリミティブを導入し、またOTAサーバと基地局コントローラBSC側の無線リソースRRとの間にプリミティブを導入することに基づいている。
【0099】
プリミティブおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。
【0100】
最初に、OTAクライアントと端末MS側の無線リソースRRとの間のプリミティブを記述する。
【0101】
プリミティブ「ダウンロード要求Ind」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0102】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:要求の実行対象であるOTAクライアントを識別する。
−要求されたダウンロード:この要素は、ネットワークにより要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。
【0103】
プリミティブ「ダウンロードAckInd」は、OTAクライアントにより端末MS側の無線リソースRRへ送信される。このプリミティブで提供されるフィールドには、以下のものがある。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAクライアント・チャレンジ番号:相互認証の第一ステップを実行すべく、OTAサーバが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
【0104】
プリミティブ「ダウンロードNackInd」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0105】
プリミティブ「認証Req」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0106】
このプリミティブで提供されるフィールドには以下のものがある。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAサーバ応答番号:相互認証の第一のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAサーバにより暗号化される番号である。
−OTAサーバ・チャレンジ番号:相互認証の第二ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
【0107】
プリミティブ「認証Rsp」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAクライアント応答番号:相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAクライアントにより暗号化される番号を識別する。
【0108】
プリミティブ「能力Req」は、MS側の無線リソースRRからOTAクライアントへ送信される。
【0109】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0110】
プリミティブ「能力Rsp」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0111】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント能力:端末の再設定可能性オプションを記述する。
【0112】
プリミティブ「ダウンロード記述Req」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0113】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−ダウンロード・リスト:各ダウンロードにつきOTAクライアントにより選択された1個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
−ダウンロード・ブロック番号:OTAクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
−支払請求基準:起こり得るダウンロード支払請求に関する基準である。
−インストール基準:ソフトウェアのインストールに関する基準である。
【0114】
プリミティブ「ダウンロード受理Cnf」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0115】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0116】
プリミティブ「ダウンロード受理Rej」は、OTA端末MS側の無線リソースRRへ送信される。
【0117】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0118】
プリミティブ「ライセンスReq」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0119】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0120】
プリミティブ「ライセンスRsp」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0121】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−復号化鍵:基本ソフトウェアを復号化するために用いられる鍵である。
【0122】
プリミティブ「ライセンスCnf」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0123】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0124】
プリミティブ「ライセンスRej」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0125】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0126】
プリミティブ「テスト記述Req」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0127】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−テスト・リスト:実行すべき各々のテストについて1個の要素を含み、これは更に以下のフィールドを含んでいる。
−テスト・ベクトル:テストの記述を含んでいる。
【0128】
プリミティブ「インストールCnf」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0129】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
プリミティブ「インストールRej」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0130】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0131】
プリミティブ「データInd」は、端末MS側の無線リソースRRからOTAクライアントへ送信される。
【0132】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−基本ソフトウェアが分割された無線ブロックのうちの1個。
【0133】
プリミティブ「データReq」は、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0134】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−Ackの無線ブロック。
【0135】
OTAサーバと基地局コントローラBSC側の無線リソースRRとの間で交換されるプリミティブについて以下に記述する。
【0136】
プリミティブ「ダウンロード開始Ind」は、OTAクライアントから基地局コントローラ機構BSC側の無線リソースRRへ送信される。
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:要求の実行対象であるOTAクライアントを識別する。
−要求されたダウンロード:この要素は、ネットワークにより要求されたダウンロードの記述ストリングおよび数値識別子を含んでいる。
【0137】
プリミティブ「ダウンロードAckInd」は、基地局コントローラ機構BSC側の無線リソースRRによりOTAクライアントへ送信される。
【0138】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAクライアント・チャレンジ番号:相互認証の第一ステップを実行すべく、OTAサーバが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
【0139】
プリミティブ「ダウンロードNackInd」は、基地局コントローラ機構BSC側の無線リソースRRからOTAクライアントへ送信される。
【0140】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0141】
プリミティブ「認証Req」は、OTAクライアントから基地局コントローラ機構BSC側の無線リソースRRへ送信される。
【0142】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAサーバ応答番号:相互認証の第一のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAサーバにより暗号化される番号である。
−OTAサーバ・チャレンジ番号:相互認証の第二ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばAESアルゴリズムを以って暗号化する乱数である。
【0143】
プリミティブ「認証Rsp」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0144】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−OTAクライアント応答番号:相互認証の第二および最後のステップを完了すべく、自身の鍵および例えばAESアルゴリズム等の適当な暗号化アルゴリズムを用いてOTAクライアントにより暗号化される番号を識別する。
【0145】
プリミティブ「能力Req」は、OTAクライアントから基地局コントローラBSC側の無線リソースRRへ送信される。
【0146】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0147】
プリミティブ「能力Rsp」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0148】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:メッセージを送信しているOTAクライアントを識別する。
−OTAクライアント能力:端末の再設定可能性オプションを記述する。
【0149】
プリミティブ「ダウンロード記述Req」は、OTAクライアントから基地局コントローラBSC側の無線リソースRRへ送信される。
【0150】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−ダウンロード・リスト:各ダウンロードにつきOTAクライアントにより選択された1個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
−ダウンロード・ブロック番号:OTAクライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
−支払請求基準:起こり得るダウンロード支払請求に関する基準である。
−インストール基準:ソフトウェアのインストールに関する基準である。
【0151】
プリミティブ「ダウンロード受理Cnf」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0152】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0153】
プリミティブ「ダウンロード受理Rej」は、基地局コントローラ機構BSC側の無線リソースRRからOTAクライアントへ送信される。
【0154】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0155】
プリミティブ「ライセンスReq」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0156】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0157】
プリミティブ「ライセンスRsp」は、OTAクライアントにより基地局コントローラBSC側の無線リソースRRへ送信される。
【0158】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−復号化鍵:基本ソフトウェアを復号化するために使用する鍵である。
【0159】
プリミティブ「ライセンスCnf」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0160】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0161】
プリミティブ「ライセンスRej」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0162】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0163】
プリミティブ「テスト記述Req」は、OTAサーバから基地局コントローラBSC側の無線リソースRRへ送信される。
【0164】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−テスト・リスト:実行すべき各々のテストについて1個の要素を含み、これは更に以下のフィールドを含んでいる。
−テスト・ベクトル:テストの記述を含んでいる。
【0165】
プリミティブ「インストールCnf」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0166】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0167】
プリミティブ「インストールRej」は、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0168】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
【0169】
プリミティブ「データReq」は、OTAサーバから基地局コントローラBSC側の無線リソースRRへ送信される。
【0170】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−基本ソフトウェアが分割された無線ブロックのうちの1個。
【0171】
プリミティブ「データInd」は、基地局コントローラBSC側の無線リソースRRからOTAサーバへ送信される。
【0172】
提供されるフィールドは、GSM/GPRSの場合、以下のうち少なくとも一組である。
−OTAクライアントID:プリミティブに関連するOTAクライアントを識別する。
−Ackの無線ブロック。
【0173】
図4、5を参照するに、OTAクライアントとOTAサーバとの間での手続き型の対話を、各々のRRが受信した各プリミティブについて、OTAクライアントまたはクライアント・コンテキストの状態に従う相対的な挙動を示すことにより記述している。
【0174】
OTAクライアントおよびOTAサーバの挙動はシステムから独立している。
【0175】
OTAクライアントまたはOTAサーバと、各々のRRとの間で交換されたプリミティブはシステムに依存しており、本例によればGSM/GPRSシステムを参照している。
【0176】
以下の記述において、タイマーの開始/停止動作は記述されていない。その理由は、先に述べたように、これらはエンティティの状態と関連付けられているためである。
【0177】
ここで図4を参照するに、OTAクライアントの挙動を記載している。
【0178】
一般に、OTAクライアントIDフィールドがプリミティブを受信しているOTAクライアントの識別子と合致しない場合、当該プリミティブは無視される。
【0179】
OTAクライアントがプリミティブ「ダウンロード要求Ind」を受信した場合、
−「アイドル」状態であれば、OTAクライアントは「ダウンロード開始」へ進む。
−「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−端末がダウンロードを実行することが可能ならば、
−乱数RNUMが抽出されて保存される。
−OTAクライアント・チャレンジ番号フィールド内に抽出された数RNUMの値を含むプリミティブ「ダウンロードAckInd」が送信される。
−端末がダウンロードを実行することが可能でなければ、プリミティブ「ダウンロードNackInd」が送信され、OTAクライアントは「アイドル」状態に戻る。
【0180】
OTAクライアントがプリミティブ「認証Req」を受信した場合、
−「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−保存された乱数RNUMが有効でなければ手続きは継続されない。
−OTAクライアントは状態「相互認証」へ進む。
−保存された乱数RNUMの値は、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵CIKにより暗号化される。
−前段階で暗号化された値がOTAサーバ応答番号フィールドの値と合致しない場合、OTAクライアントは「アイドル」状態に進み、手続きは継続されない。
−OTAサーバ・チャレンジ番号フィールドの値は、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵CIK(クライアント識別鍵)により暗号化される。
−プリミティブ「認証Rsp」は、OTAクライアント応答番号フィールド内の前段階で暗号化された値と共に送信される。
【0181】
OTAクライアントがプリミティブ「能力Req」を受信した場合、
−「相互認証」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアントは「能力要求」状態に進む。
−プリミティブ「能力応答」が送信される。
【0182】
OTAクライアントがプリミティブ「ダウンロード記述Req」を受信した場合、
−「能力要求」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアントは「ダウンロード受理」状態に進む。
−端末がソフトウェアをインストールすることが可能ならば、
−プリミティブ「ダウンロード受理Cnf」が送信される。
−端末がソフトウェアをインストールすることが可能でなければ、
−プリミティブ「ダウンロード受理Rej」が送信される。
−OTAクライアントは「アイドル」状態に進む。
【0183】
OTAクライアントがプリミティブ「ライセンスRsp」を受信した場合、
−「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−ダウンロードされたソフトウェアは、復号化鍵フィールドに示された鍵を用いて復号化される。
−復号化が成功した場合、
−プリミティブ「ライセンスCnf」が送信される。
−ダウンロードされた基本ソフトウェアが保存される。
−復号化が成功しなかった場合、
−プリミティブ「ライセンスRej」が送信される。
−手続きは「アイドル」状態に進む。
【0184】
OTAクライアントがプリミティブ「テスト記述Req」を受信した場合、
−「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアントは「現場テスト」状態に進む。
−受信されたテストは、先に保存された基本ソフトウェアに対して実行される。
−全てのテストが成功した場合、
−プリミティブ「インストールCnf」が送信される。
−新規の基本ソフトウェアがインストールされて開始される。
−少なくとも1個のテストが成功しなかった場合、
−インストールRejプリミティブが送信される。
−ダウンロードされた基本ソフトウェアがメモリから削除される。
−OTAクライアントは「アイドル」状態に進む。
【0185】
再び図5を参照するに、ここでOTAサーバの応答を記載している。
【0186】
一般に、受信されたプリミティブの各々についてOTAクライアントIDフィールドが分析され、前記識別子に関するOTAクライアント・コンテキストであると見なされる。受信された識別子に対するOTAクライアント・コンテキストが存在しない場合、当該プリミティブは無視される。
【0187】
OTAサーバがプリミティブ「ダウンロードAckInd」を受信した場合、
−OTAクライアント・コンテキストが「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「相互認証」状態に進む。
−乱数が抽出されて保存される。
−OTAクライアント・チャレンジ番号フィールドの値が、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵SIK(サーバ識別鍵)により暗号化される。
−プリミティブ「認証Req」が、前段階でOTAサーバ応答番号フィールド内の暗号化される値と共に、且つOTAサーバ・チャレンジ番号フィールド内の抽出された番号の値と共にOTAクライアントへ送信される。
【0188】
OTAクライアント・コンテキストがプリミティブ「ダウンロードNackInd」を受信した場合、
−OTAクライアント・コンテキストが「ダウンロード開始」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0189】
OTAクライアント・コンテキストがプリミティブ「認証Rsp」を受信した場合、
−OTAクライアント・コンテキストが「相互認証」状態でなければプリミティブは無視され、手続きは継続されない。
−保存された乱数の値が、選択された暗号化アルゴリズム、例えばAESアルゴリズムを用いて、内部鍵SIKにより暗号化される。
−前段階で暗号化された値がOTAクライアント応答番号フィールドの値と合致しない場合、OTAクライアント・コンテキストは「アイドル」状態に進み、継続されない。
−OTAサーバは「能力要求」状態に進む。
−プリミティブ「能力Req」が送信される。
【0190】
OTAクライアント・コンテキストがプリミティブ「能力Rsp」を受信した場合、
−OTAクライアント・コンテキストが「能力要求」状態でなければプリミティブは無視され、手続きは継続されない。
−プリミティブに含まれる能力が、ダウンロードされるソフトウェアと互換性を有していない場合、OTAクライアント・コンテキストは「アイドル」状態に進む。
−プリミティブに含まれる能力がダウンロードされるソフトウェアと互換性を有する場合、OTAクライアント・コンテキストは「ダウンロード受理」状態に進み、プリミティブ「ダウンロード記述Req」が送信される。
【0191】
OTAクライアント・コンテキストがプリミティブ「ダウンロード受理Cnf」を受信した場合、
−OTAクライアント・コンテキストが「ダウンロード受理」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「ソフトウェア・ダウンロード」状態に進む。
−ソフトウェアのダウンロードが開始される。
【0192】
OTAクライアント・コンテキストがプリミティブ「ダウンロード受理Rej」を受信した場合、
−OTAクライアント・コンテキストが「ダウンロード受理」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0193】
OTAクライアント・コンテキストがプリミティブ「ライセンスReq」を受信した場合、
−OTAクライアント・コンテキストが「ソフトウェア・ダウンロード」状態でなければプリミティブは無視され、手続きは継続されない。
−手続きは「インストール」状態に進む。
−復号化鍵を含む、プロトコル・プリミティブ「ライセンスRsp」が送信される。
【0194】
OTAクライアント・コンテキストがプリミティブ「ライセンスCnf」を受信した場合、
−OTAクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−プリミティブ「テスト記述Req」が送信される。
【0195】
OTAクライアント・コンテキストがプリミティブ「ライセンスRej」を受信した場合、
−OTAクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0196】
OTAクライアント・コンテキストがプリミティブ「インストールCnf」を受信した場合、
−OTAクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0197】
OTAクライアント・コンテキストがプリミティブ「インストールRej」を受信した場合、
−OTAクライアント・コンテキストが「インストール」状態でなければプリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「アイドル」状態に進む。
【0198】
データがOTAサーバからOTAクライアントへ転送されるウィンドウ・プロトコルの動作について以下に記述する。
【0199】
OTAサーバの観点から、ソフトウェアのダウンロードが開始された際に、基本ソフトウェアは、例えば、暗号化鍵および例えばAESアルゴリズム等、公知の種類の暗号化アルゴリズムにより暗号化される。
【0200】
暗号化された基本ソフトウェアは、例えば、1〜2kBytes等の限られたサイズを有するブロックに分割される。基本ソフトウェアが分割された無線ブロックの個数に等しい個数のビットを有するビット・マスクBITMASKが割当てられて、各々のビットに値「0」が設定される。マスクの各ビットは、無線ブロックに対応しており、その番号はビット位置に等しい。すなわち、第一ビットは第一無線ブロックに、第二ビットは第二無線ブロックに対応しており、以下同様である。基本ソフトウェアを構成する先頭のN個の無線ブロックBLOCKが送信される。タイマーT401が始動される。各メッセージAckを受信したならば以下が行なわれる。
−タイマーT401が再開される。
−メッセージAckのビットマップに存在する各々の値「1」に対して、対応する位置に割当てられたマスクBITMASKの値が「1」に設定される。
−未送信ブロックを最初に考慮して、マスクBITMASK内で値「0」に対応する高々先頭のN無線ブロック・ブロックが送信される。
−マスクBITMASKの全てのビットが「1」に等しい値になった時点でダウンロードが終了する。
【0201】
OTAクライアントの観点から、ソフトウェアのダウンロードが開始された際に、当該ソフトウェアが分割された無線ブロックの個数に等しいビット・マスクBITMASKが割当てられて、各々のビットに値「0」が設定される。マスクの各ビットは、無線ブロックに対応しており、その数はビット位置に等しい。すなわち、第一ビットは第一無線ブロックに、第二ビットは第二無線ブロックに対応しており、以下同様である。次いで、タイマーT400が始動される。各無線ブロックBLOCKを受信したならば以下が行なわれる。
−タイマーT400が再開される。
−受信した無線ブロックのブロック番号に対応するマスクBITMASKのビットが「1」に設定される。
−マスクBITMASKに対応するビットマップと共にメッセージAckが送信される。
−マスクBITMASKの全てのビットが「1」に等しい値になった時点でダウンロードが終了する。
【0202】
要約するに、上例によれば、OTAクライアントおよびOTAサーバの機能的な挙動は以下の通りである。
−ダウンロード・手続きは、例えば、MSC(移動スイッチングセンター)により基地局コントローラBSCへ送信されたプロトコル・メッセージ「ハンドオーバー・コマンド」を受信した時点で開始される。
−OTAクライアントとOTAサーバとの間の相互認証は、例えば、「チャレンジ応答」方式に従い生起する。
−ダウンロードされる基本ソフトウェアは、トラフィック・チャネル、例えばGPRトラフィック・チャネルへ送信される。
−ダウンロードされる基本ソフトウェアは、OTAサーバにより小さいサイズ(例:1または2キロバイト)のブロックに分割される。
−基本ソフトウェアの転送は簡単なウィンドウ・プロトコルにより管理され、その際にサイズ・ウィンドは基本ソフトウェアが分割されたブロックの個数と合致する。
−ダウンロードされた基本ソフトウェアは暗号化することができ、その場合、復号化およびインストールのために鍵が必要とされる。
−基本ソフトウェアを開始する前に、OTAクライアントは、例えばOTAサーバにより提案された適切なテストによりこれを検証する。
【0203】
図18を参照するに、標準に定義されている通り、回線呼に対するGSMからのUMTSへのシステム間ハンドオーバー手続きの適用可能な例を示しており、この中で端末MSを再設定可能な基本ソフトウェアのダウンロード・手続きが導かれている。
【0204】
図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」を受信して、「アイドル」状態に戻る。
【0205】
図19に開示した手続きは、基本ソフトウェアのダウンロード・手続きを示すものである。
【0206】
本手続きは、当業者には理解されるように、標準に定義された回線呼用のGSMからUMTSへのシステム間ハンドオーバー手続きに組込まれていてよい。
【0207】
特に、組込みは、MSCから基地局サブシステム・アプリケーション部(BSSAP)プロトコルの「ハンドオーバー・コマンド」メッセージを受信してから、MSへRRプロトコルの「システム間からUTRANへのハンドオーバー・コマンド」メッセージを送信する間に、RR層において行なうことができる。
【0208】
本発明は、現在の基準により定義されている全ての可能なシステム間ハンドオーバー手続きに一般化することができる。
【0209】
例えば、当業者には理解されるように、本手続きは、標準に定義の通り、回線呼用のUMTSからGSMへのシステム間ハンドオーバー手続きに組込むことができる。特に、組込みは、MSCから無線アクセス・ネットワーク・アプリケーション部(RANAP)プロトコルの「再配置コマンド」メッセージを受信してから、ユーザー設備(UE)へ無線リソース制御(RRC)プロトコルの「UTRANからのハンドオーバー・コマンド」メッセージを送信するまでの間に、無線リソース制御(RRC)層で行なうことができる。
【0210】
本発明はまた、未だ標準化されていないシステム間ハンドオーバー手続き、例えば、国際移動通信2000(IMT2000)およびWLANまたはIEEE802.16あるいはIEEE802.20システム間のシステム間ハンドオーバー手続きとして一般化することができる。
【0211】
当業者には明らかなように、本発明は、音声通話の場合、特に回線方式呼において、呼を中断することなく基本ソフトウェアのダウンロードの実行を可能にする。これは、例えば、1個以上のパケット・チャネル、例えばPDTCH GPRSチャネルを割当てることにより、回線通信に利用される回線方式チャネル、例えばTCH(トラフィック・チャネル)GSMチャネルと並行して、GSM/GPRSの場合に可能である。
【0212】
この特徴により、音声、データ、およびソフトウェアのダウンロードの間での優先順位付けを管理することができる。
【0213】
本発明は、GSM/GPRSシステムを参照するに、上述のシステムの無線チャネルを用いることにより開示されているが、当業者には理解されるように、本発明は例えば「汎用」チャネルを用いて適用されてもよい。
【0214】
「汎用」チャネルを用いることができる例として、文献に記載の通り、OTAサーバからOTAクライアントへの基本ソフトウェアのダウンロード手続きへの「汎用」チャネルの使用が挙げられる。
【0215】
システム間ハンドオーバーの場合、「汎用」チャネルを使用する実装方式により、例えば図18に開示した手続きを採用して、OTAサーバからOTAクライアントへの基本ソフトウェアのダウンロード手続きを上述の「汎用」チャネルを介して同時に利用しながら、例えばGSM/GPRSシステム等のアクティブなシステムの無線チャネルを介したアクティブな接続を維持することが予見できる。
【0216】
「汎用」チャネルは、基本ソフトウェアのダウンロード手続きの全体または一部、例えばOTAサーバからOTAクライアントへの基本ソフトウェアの送信、だけに利用することができる。
【0217】
「汎用」チャネルを部分的に利用する場合、基本ソフトウェアのダウンロード手続きの残りの部分は、アクティブなシステムの無線チャネルを用いて実装することができる。
【0218】
「汎用」チャネルを採用することにより、アクティブなシステムに関連付けられた無線リソースをより効率的にロードして、他のユーザーが利用できるようにして、基本ソフトウェアのダウンロード手続きをはるかに高速に実行することが可能になる。これは、「汎用」チャネルがこの種の動作専用のチャネルであるためである。
【0219】
本発明の更なる実施形態として、当業者には公知のように、例えば、端末が「アイドル」状態である場合に、GSM/GPRSからUMTSへ等、2種のシステム間でセル再選択手続きをも管理可能にすることである。
【0220】
先に述べたように、プリミティブおよび関連フィールドに名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。
【0221】
この拡張は、OTAクライアントと端末MS側の無線リソースRRとの間に以下のプリミティブを導入するものである。
−ダウンロード開始Req:このメッセージは、OTAクライアントから端末MS側の無線リソースRRへ送信される。
【0222】
GSM/GPRSの場合、このプリミティブに提供されるフィールドは少なくとも、
OTAクライアントID:要求を実行しているOTAクライアントを識別する
および、OTAサーバと基地局コントローラBSC側の無線リソースRRとの間の以下のプリミティブの組の一つである。
−要求ダウンロード開始Ind:このメッセージは、基地局コントローラBSC側の無線リソースRRからOTAクライアントへ送信される。
【0223】
GSM/GPRSの場合、プリミティブに提供されるフィールドは、以下のうち少なくとも一組である。
OTAクライアントID:要求を実行しているOTAクライアントを識別する。
【0224】
以下に、プリミティブ「要求ダウンロード開始Ind」を受信した際のOTAクライアント・コンテキストの端末MSに関するコンテキストの応答を示す。
−OTAクライアント・コンテキストが「アイドル」状態ではない場合、プリミティブは無視され、手続きは継続されない。
−OTAクライアント・コンテキストは「ダウンロード開始」状態へ進む。
−プリミティブ「ダウンロード開始Ind」は、各種の可能なダウンロードを示すと共に、OTAクライアントへ送信される。
【0225】
図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クライアントの識別子をローカルに保存する。
【0226】
本手続きは、図18に関して述べる手続きの第6番以降の段階を実行することにより継続される。
【0227】
GSM/GPRSシステムのアクセス・ネットワークを参照しつつ、本発明に従い記述されたアーキテクチャおよび方法を開示してきた。
【0228】
本発明はまた、UMTS、UTRAN(UMTS地上波無線アクセス・ネットワーク)その他の任意のアクセス・ネットワーク、例えばWLAN、IEEE802.16、IEEE802.20等のアクセス・ネットワークにも適用することができる。
【0229】
例えば、UTRANの場合、本発明はOTAクライアントとOTAサーバおよび関連手続き、プリミティブ並びにプロトコル・メッセージをUMTSシステムのRRC層に組込んで実装することができる。
【0230】
本発明を、アクセス・ネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を用いて開示してきた。本発明はまた、コア・ネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を用いて実装することもできる。この場合、例えばGSM/GPRSおよびUMTSシステムのパケット・スイッチ・コア・ネットワークを考慮すれば、本発明は、OTAクライアントとOTAサーバおよび関連手続き、プリミティブ並びにプロトコル・メッセージをコア・ネットワークの端末およびサービス提供GPRSサポート・ノード(SGSN)ノードの各々のGPRS移動管理(GMM)層に組込むことにより実装することができる。
【0231】
より具体的には、GSM/GPRSの場合、GPRS移動管理(GMM)層は、新規のプロトコル・メッセージを導入して関連フィールドをOTAサーバとOTAクライアントの間で交換することにより変更される。同じ方式をUMTSシステムに適用することもできる。
【0232】
本発明を、システム間ハンドオーバー手続きの実行中における1個の基本ソフトウェアのダウンロードおよび起動を考慮することにより開示してきた。
【0233】
当業者には明らかなように、当該基本ソフトウェアはインストールして直ちに動作させるのではなく、端末にダウンロードして保存してもよい。
【0234】
この更なる実施形態によれば、ネットワークまたはユーザーからの要求があれば、基本ソフトウェアをインストールして引き続き実行させることが可能である。無線端末UE/MSが十分なメモリおよび処理能力を有していれば、ダウンロードされた基本ソフトウェアを、現在動作中の既存システムと並行して保存およびインストールすることができる。
【0235】
このオプションは、端末UE/MSのマルチ・モード動作を可能にするために有用である。すなわち、このオプションにより、基本ソフトウェアをダウンロードする必要なしに、端末をある動作モードから別の動作モードへ切り替えることが可能になる。
【0236】
要約すれば、本発明により、少なくとも以下の利点が得られる。
−ノードまたは物理的なインターフェースが既存のものに一切追加されないため、第二および第三世代ネットワークに存在しているプロトコルおよびノードに対する影響が最小限に抑えられる。
−手続きのシグナリング・フェーズが標準で定義されたものと同一のシグナリング・チャネルを使用する一方、ソフトウェアのダウンロード手続き用途にのみデータ・チャネルが割当てられるため、無線リソースの占有が最小限に抑えられる。
−本発明は既存の第二および第三世代ネットワークを利用するため、従来技術で言及されているように将来的なIP利用UMTSのリリースを待たなくてもよい。
【0237】
特に、アクセス・ネットワークおよび、ネットワーク側と端末側の両方における対応プロトコル層を使用する場合、RR(無線リソース)プロトコルが、新規の基本ソフトウェアを端末がダウンロードできるようにする若干の変更と一体化されているため、ネットワークはソフトウェアのダウンロード手続きおよび関連する無線リソースを完全に制御することができ、これにより、例えば、GSM/GPRS、IS95、PDC(デジタル・セルラー電話)、あるいは例えばファミリIMT2000に属する第三世代セルラー方式等の第二世代のセルラー方式を実装することができる。
【図面の簡単な説明】
【0238】
【図1】従来技術による多モード端末を表わす図である。
【図2】本発明の一実施形態によるGSM/GPRシステムのネットワーク・アーキテクチャを示す図である。
【図3】図1のアークテクチャの再設定可能な端末を表わす図である。
【図4】無線端末側でクライアントにより実行されるプロトコル・ステップの状態遷移図である。
【図5】基地局コントローラ側でサーバにより実行されるプロトコル・ステップの状態遷移図である;
【図6】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図7】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図8】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図9】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図10】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図11】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図12】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図13】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図14】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図15】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図16】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図17】サーバとクライアントの間で交換されるプロトコル・メッセージの構造を示す図である。
【図18】回線呼に対するGSMからUMTSへのシステム間ハンドオーバー手続きを示す図である。
【図19】無線端末を再設定するソフトウェアのダウンロード手続きの詳細を示す図である。
【図20】セル再選択の場合における基本ソフトウェアのダウンロード手続きを示す図である。
【特許請求の範囲】
【請求項1】
少なくとも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)との間の地上波接続を管理することが可能な地上波ソフトウエア・モジュールが各々提供されていることを特徴とする通信ネットワーク。
【請求項2】
−前記サーバ・エンティティ(OTAサーバ)が、前記プロトコル層(RR、GMM)の少なくとも一組の変更されたメッセージを含み、
−前記クライアント・エンティティ(OTAクライアント)が、前記標準化されたプロトコル層(RR、GMM)の更に少なくとも一組の変更されたメッセージを含み、且つ
前記サーバ・エンティティ(OTAサーバ)および前記クライアント・エンティティ(OTAクライアント)に各々関連付けられた前記変更メッセージの組が、前記地上波接続を管理すべく設定されていることを特徴とする、請求項1に記載のネットワーク。
【請求項3】
−無線アクセス・ネットワーク(GERAN;UTRAN)およびコア・ネットワークを含み、且つ
−前記プロトコル層(GMM)が前記コア・ネットワークのプロトコル層であることを特徴とする、請求項1に記載のネットワーク。
【請求項4】
−無線アクセス・ネットワーク(GERAN;UTRAN)およびコア・ネットワークを含み、且つ
−前記プロトコル層(RR)が前記無線アクセス・ネットワーク(GERAN;UTRAN)のプロトコル層であることを特徴とする、請求項1に記載のネットワーク。
【請求項5】
−前記無線アクセス・ネットワーク(GERAN;UTRAN)が無線コントローラ(BSC、RNC)を含み、
−前記プロトコル層が前記無線コントローラ(BSC、RNC)のプロトコル層であることを特徴とする、請求項4に記載のネットワーク。
【請求項6】
前記無線アクセス・ネットワークが、第二世代ネットワーク(GERAN)に従って動作する、請求項3に記載のネットワーク。
【請求項7】
前記無線アクセス・ネットワークが、第三世代ネットワーク(UTRAN)に従って動作する、請求項3に記載のネットワーク。
【請求項8】
前記地上波接続が、前記通信ネットワークの汎用チャネルを介して確立されることを特徴とする、請求項1に記載のネットワーク。
【請求項9】
前記地上波接続が、前記通信ネットワークの無線チャネルを介して確立されることを特徴とする、請求項1に記載のネットワーク。
【請求項10】
前記通信システムが、音声通話、データ送信、および前記基本ソフトウェア・モジュールの前記少なくとも1個のモジュールのダウンロードの間での優先順位を管理すべく設定されていることを特徴とする、請求項1に記載のネットワーク。
【請求項11】
前記地上波ソフトウェア・モジュールが、音声通話の間に、前記基本ソフトウェア・モジュールの前記少なくとも1個のモジュールをダウンロードすべく設定されていることを特徴とする、請求項1に記載のネットワーク。
【請求項12】
前記基本ソフトウェア・モジュールの組が、更なる通信システムにより前記無線端末(MS)を少なくとも部分的に設定するのに適していることを特徴とする、請求項1に記載のネットワーク。
【請求項13】
−前記無線端末(MS)が、前記更なる通信システムに対して少なくとも測定を実行すべくプロトコル・スタック層を含んでいることを特徴とする、請求項12に記載のネットワーク。
【請求項14】
少なくとも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個のモジュールをダウンロードするステップとを含む方法。
【請求項15】
前記地上波接続の確立が、前記プロトコル層の変更されたプロトコル・メッセージを交換する前記プロトコル・ステップの各々を含む一組のプロトコル・ステップを含むことを特徴とする、請求項14に記載の方法。
【請求項16】
前記変更されたプロトコル・メッセージの交換が、
−以下のフィールドの組、すなわち
−メッセージの種類を識別する第一のフィールド(メッセージ種別)と、
−メッセージが示す無線端末(MS)を識別する第二のフィールド(OTAクライアントID)と、
−データ情報を含む第三のフィールドとを各々含むメッセージの交換を含むことを特徴とする、請求項15に記載の方法。
【請求項17】
前記プロトコル・ステップの組が以下のステップ、すなわち、
a)前記少なくとも1個の基本ソフトウェア・モジュールのダウンロード要求を実行するステップと、
b)前記クライアント(OTAクライアント)および前記サーバ(OTAサーバ)を相互に認証するステップと、
c)前記サーバ(OTAサーバ)から前記少なくとも1個のダウンロード可能な基本ソフトウェア・モジュールを前記無線端末(UE/MS)が受信する能力を調べるステップと、
d)ダウンロード・オプションに関する情報を提供するステップと、
e)前記少なくとも1個の基本ソフトウェア・モジュールをブロックに分割するステップと、
f)前記ブロックを前記サーバ(OTAサーバ)から、前記少なくとも1個の無線端末(UE/MS)へ送信するステップと、
g)前記少なくとも1個のモジュールをプロトコル・スタックの一組の要素により再設定すべく前記ブロックを再構築して、前記要素の組をテストするステップと、
h)前記要素の組を前記無線端末(UE/MS)にインストールするステップとを含むことを特徴とする、請求項15に記載の方法。
【請求項18】
前記プロトコル・ステップの組が、
前記無線端末(UE/MS)へダウンロードされた前記ブロックの構造を監視するステップを含むことを特徴とする、請求項17に記載の方法。
【請求項19】
前記プロトコル・ステップの組が、
地上波接続の実行に許される時間を制限する一組のタイマー(T100、T200、T300、T400、T500、T101、T201、T301、T302、T401、T501)を管理するステップを含むことを特徴とする、請求項17に記載の方法。
【請求項20】
前記プロトコル・ステップの組が、
−各々のプロトコル・ステップに対して少なくとも一対のタイマー、すなわち前記無線端末(UE/MS)により実行されるプロトコル・ステップを監視する第一のタイマーおよび前記サーバ(OTAサーバ)により実行されるプロトコル・ステップを監視する第二のタイマーであって、前記1個のプロトコル・ステップが開始された時点で開始され、前記プロトコル・ステップが完了した時点で停止される各々のタイマーを割当てるステップを含むことを特徴とする、請求項17に記載の方法。
【請求項21】
前記相互認証ステップが「チャレンジ応答」方式に基づいていることを特徴とする、請求項17に記載の方法。
【請求項22】
前記少なくとも1個のモジュールをブロックに分割する前記ステップが、1〜2kByteのサイズを有するブロックに分割するステップを含み、前記ブロックを送信するステップがウィンドウ・プロトコルを管理して、前記少なくとも1個の基本ソフトウェア・モジュールが分割されたブロックのサイズにウィンドウ・サイズを合致させるステップを含む、請求項17に記載の方法。
【請求項23】
前記無線端末に前記要素の組をインストールする前にライセンスが要求されることを特徴とする、請求項17に記載の方法。
【請求項24】
前記少なくとも1個の基本ソフトウェア・モジュールが、前記無線端末(UE/MS)にダウンロードされる前に、鍵により暗号化されることを特徴とする、請求項14に記載の方法。
【請求項25】
少なくとも二組の基本ソフトウェア・モジュールを前記再設定可能な無線端末(UE/MS)に保存するステップを更に含むことを特徴とする、請求項14に記載の方法。
【請求項26】
前記少なくとも1個のモジュールの組をダウンロードする前記ステップが、
−更なる通信システムにより前記無線端末(MS)を少なくとも部分的に設定するのに適した一組の基本ソフトウェア・モジュールをダウンロードするステップを含むことを特徴とする、請求項14に記載の方法。
【請求項27】
請求項14〜26のいずれかに記載の方法を実行することにより設定可能である、再設定可能な無線端末(UE/MS)。
【請求項28】
請求項14〜26のいずれかに記載の方法を実行することにより再設定可能な無線端末(UE/MS)設定するサーバ・エンティティ(OTAサーバ)を含むネットワーク・ノード。
【請求項29】
少なくとも1個のコンピュータのメモリにロード可能であって、請求項14〜26に記載のステップのいずれかを実行するソフトウェア・コード部分を含む、コンピュータ・プログラム生成物またはコンピュータ・プログラム生成物のコンピュータ・プログラムの組。
【請求項1】
少なくとも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)との間の地上波接続を管理することが可能な地上波ソフトウエア・モジュールが各々提供されていることを特徴とする通信ネットワーク。
【請求項2】
−前記サーバ・エンティティ(OTAサーバ)が、前記プロトコル層(RR、GMM)の少なくとも一組の変更されたメッセージを含み、
−前記クライアント・エンティティ(OTAクライアント)が、前記標準化されたプロトコル層(RR、GMM)の更に少なくとも一組の変更されたメッセージを含み、且つ
前記サーバ・エンティティ(OTAサーバ)および前記クライアント・エンティティ(OTAクライアント)に各々関連付けられた前記変更メッセージの組が、前記地上波接続を管理すべく設定されていることを特徴とする、請求項1に記載のネットワーク。
【請求項3】
−無線アクセス・ネットワーク(GERAN;UTRAN)およびコア・ネットワークを含み、且つ
−前記プロトコル層(GMM)が前記コア・ネットワークのプロトコル層であることを特徴とする、請求項1に記載のネットワーク。
【請求項4】
−無線アクセス・ネットワーク(GERAN;UTRAN)およびコア・ネットワークを含み、且つ
−前記プロトコル層(RR)が前記無線アクセス・ネットワーク(GERAN;UTRAN)のプロトコル層であることを特徴とする、請求項1に記載のネットワーク。
【請求項5】
−前記無線アクセス・ネットワーク(GERAN;UTRAN)が無線コントローラ(BSC、RNC)を含み、
−前記プロトコル層が前記無線コントローラ(BSC、RNC)のプロトコル層であることを特徴とする、請求項4に記載のネットワーク。
【請求項6】
前記無線アクセス・ネットワークが、第二世代ネットワーク(GERAN)に従って動作する、請求項3に記載のネットワーク。
【請求項7】
前記無線アクセス・ネットワークが、第三世代ネットワーク(UTRAN)に従って動作する、請求項3に記載のネットワーク。
【請求項8】
前記地上波接続が、前記通信ネットワークの汎用チャネルを介して確立されることを特徴とする、請求項1に記載のネットワーク。
【請求項9】
前記地上波接続が、前記通信ネットワークの無線チャネルを介して確立されることを特徴とする、請求項1に記載のネットワーク。
【請求項10】
前記通信システムが、音声通話、データ送信、および前記基本ソフトウェア・モジュールの前記少なくとも1個のモジュールのダウンロードの間での優先順位を管理すべく設定されていることを特徴とする、請求項1に記載のネットワーク。
【請求項11】
前記地上波ソフトウェア・モジュールが、音声通話の間に、前記基本ソフトウェア・モジュールの前記少なくとも1個のモジュールをダウンロードすべく設定されていることを特徴とする、請求項1に記載のネットワーク。
【請求項12】
前記基本ソフトウェア・モジュールの組が、更なる通信システムにより前記無線端末(MS)を少なくとも部分的に設定するのに適していることを特徴とする、請求項1に記載のネットワーク。
【請求項13】
−前記無線端末(MS)が、前記更なる通信システムに対して少なくとも測定を実行すべくプロトコル・スタック層を含んでいることを特徴とする、請求項12に記載のネットワーク。
【請求項14】
少なくとも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個のモジュールをダウンロードするステップとを含む方法。
【請求項15】
前記地上波接続の確立が、前記プロトコル層の変更されたプロトコル・メッセージを交換する前記プロトコル・ステップの各々を含む一組のプロトコル・ステップを含むことを特徴とする、請求項14に記載の方法。
【請求項16】
前記変更されたプロトコル・メッセージの交換が、
−以下のフィールドの組、すなわち
−メッセージの種類を識別する第一のフィールド(メッセージ種別)と、
−メッセージが示す無線端末(MS)を識別する第二のフィールド(OTAクライアントID)と、
−データ情報を含む第三のフィールドとを各々含むメッセージの交換を含むことを特徴とする、請求項15に記載の方法。
【請求項17】
前記プロトコル・ステップの組が以下のステップ、すなわち、
a)前記少なくとも1個の基本ソフトウェア・モジュールのダウンロード要求を実行するステップと、
b)前記クライアント(OTAクライアント)および前記サーバ(OTAサーバ)を相互に認証するステップと、
c)前記サーバ(OTAサーバ)から前記少なくとも1個のダウンロード可能な基本ソフトウェア・モジュールを前記無線端末(UE/MS)が受信する能力を調べるステップと、
d)ダウンロード・オプションに関する情報を提供するステップと、
e)前記少なくとも1個の基本ソフトウェア・モジュールをブロックに分割するステップと、
f)前記ブロックを前記サーバ(OTAサーバ)から、前記少なくとも1個の無線端末(UE/MS)へ送信するステップと、
g)前記少なくとも1個のモジュールをプロトコル・スタックの一組の要素により再設定すべく前記ブロックを再構築して、前記要素の組をテストするステップと、
h)前記要素の組を前記無線端末(UE/MS)にインストールするステップとを含むことを特徴とする、請求項15に記載の方法。
【請求項18】
前記プロトコル・ステップの組が、
前記無線端末(UE/MS)へダウンロードされた前記ブロックの構造を監視するステップを含むことを特徴とする、請求項17に記載の方法。
【請求項19】
前記プロトコル・ステップの組が、
地上波接続の実行に許される時間を制限する一組のタイマー(T100、T200、T300、T400、T500、T101、T201、T301、T302、T401、T501)を管理するステップを含むことを特徴とする、請求項17に記載の方法。
【請求項20】
前記プロトコル・ステップの組が、
−各々のプロトコル・ステップに対して少なくとも一対のタイマー、すなわち前記無線端末(UE/MS)により実行されるプロトコル・ステップを監視する第一のタイマーおよび前記サーバ(OTAサーバ)により実行されるプロトコル・ステップを監視する第二のタイマーであって、前記1個のプロトコル・ステップが開始された時点で開始され、前記プロトコル・ステップが完了した時点で停止される各々のタイマーを割当てるステップを含むことを特徴とする、請求項17に記載の方法。
【請求項21】
前記相互認証ステップが「チャレンジ応答」方式に基づいていることを特徴とする、請求項17に記載の方法。
【請求項22】
前記少なくとも1個のモジュールをブロックに分割する前記ステップが、1〜2kByteのサイズを有するブロックに分割するステップを含み、前記ブロックを送信するステップがウィンドウ・プロトコルを管理して、前記少なくとも1個の基本ソフトウェア・モジュールが分割されたブロックのサイズにウィンドウ・サイズを合致させるステップを含む、請求項17に記載の方法。
【請求項23】
前記無線端末に前記要素の組をインストールする前にライセンスが要求されることを特徴とする、請求項17に記載の方法。
【請求項24】
前記少なくとも1個の基本ソフトウェア・モジュールが、前記無線端末(UE/MS)にダウンロードされる前に、鍵により暗号化されることを特徴とする、請求項14に記載の方法。
【請求項25】
少なくとも二組の基本ソフトウェア・モジュールを前記再設定可能な無線端末(UE/MS)に保存するステップを更に含むことを特徴とする、請求項14に記載の方法。
【請求項26】
前記少なくとも1個のモジュールの組をダウンロードする前記ステップが、
−更なる通信システムにより前記無線端末(MS)を少なくとも部分的に設定するのに適した一組の基本ソフトウェア・モジュールをダウンロードするステップを含むことを特徴とする、請求項14に記載の方法。
【請求項27】
請求項14〜26のいずれかに記載の方法を実行することにより設定可能である、再設定可能な無線端末(UE/MS)。
【請求項28】
請求項14〜26のいずれかに記載の方法を実行することにより再設定可能な無線端末(UE/MS)設定するサーバ・エンティティ(OTAサーバ)を含むネットワーク・ノード。
【請求項29】
少なくとも1個のコンピュータのメモリにロード可能であって、請求項14〜26に記載のステップのいずれかを実行するソフトウェア・コード部分を含む、コンピュータ・プログラム生成物またはコンピュータ・プログラム生成物のコンピュータ・プログラムの組。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【公開番号】特開2012−53868(P2012−53868A)
【公開日】平成24年3月15日(2012.3.15)
【国際特許分類】
【出願番号】特願2011−172398(P2011−172398)
【出願日】平成23年8月5日(2011.8.5)
【分割の表示】特願2007−538272(P2007−538272)の分割
【原出願日】平成16年10月28日(2004.10.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
【出願人】(503148270)テレコム・イタリア・エッセ・ピー・アー (87)
【Fターム(参考)】
【公開日】平成24年3月15日(2012.3.15)
【国際特許分類】
【出願日】平成23年8月5日(2011.8.5)
【分割の表示】特願2007−538272(P2007−538272)の分割
【原出願日】平成16年10月28日(2004.10.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
【出願人】(503148270)テレコム・イタリア・エッセ・ピー・アー (87)
【Fターム(参考)】
[ Back to top ]