JP4668276B2 - 無線端末を設定するための方法及びネットワークアーキテクチャー並びにそのための無線端末、ネットワークノード及びコンピュータプログラムプロダクト - Google Patents
無線端末を設定するための方法及びネットワークアーキテクチャー並びにそのための無線端末、ネットワークノード及びコンピュータプログラムプロダクト Download PDFInfo
- Publication number
- JP4668276B2 JP4668276B2 JP2007538273A JP2007538273A JP4668276B2 JP 4668276 B2 JP4668276 B2 JP 4668276B2 JP 2007538273 A JP2007538273 A JP 2007538273A JP 2007538273 A JP2007538273 A JP 2007538273A JP 4668276 B2 JP4668276 B2 JP 4668276B2
- Authority
- JP
- Japan
- Prior art keywords
- ota
- client
- network
- reconfigurable
- download
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 85
- 238000004590 computer program Methods 0.000 title claims description 10
- 238000004891 communication Methods 0.000 claims abstract description 35
- 238000012360 testing method Methods 0.000 claims description 26
- 230000004044 response Effects 0.000 claims description 24
- 238000012545 processing Methods 0.000 claims description 4
- 238000012544 monitoring process Methods 0.000 claims 2
- 230000008859 change Effects 0.000 description 27
- 239000010410 layer Substances 0.000 description 19
- 238000009434 installation Methods 0.000 description 17
- 230000000875 corresponding effect Effects 0.000 description 10
- 230000006870 function Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 6
- 230000001413 cellular effect Effects 0.000 description 5
- 230000007704 transition Effects 0.000 description 5
- 239000013598 vector Substances 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000003491 array Methods 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 239000002346 layers by function Substances 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
- H04W8/24—Transfer of terminal data
- H04W8/245—Transfer of terminal data from a network towards a terminal
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Transfer Between Computers (AREA)
- Transceivers (AREA)
Description
一般に本発明は無線通信網及び無線通信網を使用する再設定可能な無線端末に関する。特に、本発明は再設定可能な無線端末の設定に関するものであり、この設定は、無線通信網から無線（ＯＴＡ）でダウンロードされた基本ソフトウエアを前記無線端末にインストールすることによって実行する。
文献（非特許文献１及び非特許文献２）から、端末、基地局及びネットワークノードなどの再設定可能なシステムは、動作機能を随意に再設定できる装置であることが知られている。例えば、ＧＳＭ／ＧＰＲＳ（Global System for Mobile communication/General Packet Radio Service）などの第二世代システム（２Ｇ）と共に動作し得る再設定可能な無線端末は、ＵＭＴＳ（Universal Mobile Telecommunication System）又はＣＤＭＡ ２０００（Code Division Multiple Access 2000）、又はＷＩ-ＦＩ（Wlrless Fidelity）又はＤＶＢ-Ｔ（Digital Video Broadcasting Terrestrial）システムなどのような第三世代システム（３Ｇ）と共に動作できるように再設定することができる。
「システム」とは、特定の機能（例えば、通信網として動作する機能）を実行するために所定の基準に従って相互に協調して働く（すなわち「規格」に従って協調して働く）複数の要素を意味する。
本明細書におけるシステムの例はＧＳＭシステム、ＧＰＲＳシステム、ＵＭＴＳシステム、ＷＬＡＮ（Wireless Local Area Network）システムなどであり、その各々は対応する規格に準拠している。
端末の再設定を実行するためには、端末の動作機能を再設定可能な技術を用いて実現する必要がある。このことに関し、再設定可能な端末又はデバイスは例えば、複数のＦＰＧＡ（Field Programmable Gate Array）、ＤＳＰ（Digital Signal Processor）及びマイクロプロセッサにより構成された再プログラム可能なハードウェアを備えており、最低水準であっても該デバイスの単一機能はソフトウェアコードにより実行される。よって、再プログラム可能なデバイスを再設定するためには、デバイス自体のハードウェアを管理する基本ソフトウエアを取り換えるだけで十分である。
本明細書において「基本ソフトウエア」なる用語は、例えばＧＳＭ／ＧＰＲＳ、ＵＭＴＳなどのような当該システムのプロトコルスタックの無線インターフェース又は下位層（例えばＬ１、Ｌ２、Ｌ３）と上位層（例えばＬ４〜Ｌ７）との両方を定義すると共にライブラリに編成されたソフトウェアを意味する。
知られているように、電気通信分野では、機能の分類をするために最も用いられている方法はＯＳＩモデル（Open System Interconnection）である。機能は層のスタック形式で表された機能面又は機能層に分類される。
各層は、直ぐ下の層により提供されたサービスの改善となっているサービスを直ぐ上の層に提供する。
一般に最下層（層１）は情報を物理的に送信することを目的とする。
一般に最下層（層１）は情報を物理的に送信することを目的とする。
ＯＳＩ仕様によると、標準的な層数は７であり、それぞれ物理層、接続層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層及びアプリケーション層である。各システム、例えばＧＳＭ／ＧＰＲＳ、ＵＭＴＳなどは、前記標準スタックの必要部分を実装する。
無線端末を考えると、再設定可能なハードウェアを使用する場合に得られる利点は多いが、１つの利点は明らかに即効的なものであり、無線端末を該端末が位置する領域（動作範囲）をカバーするシステムに従って再設定できることである。したがって、端末がＧＳＭ／ＧＰＲＳのような第二世代システムによりカバーされる領域内で使用される場合には、前記システムを受信可能にすべく端末を設定でき、同様に、ＵＭＴＳのような第三世代システムによりカバーされた領域内では、それに応じて端末を設定できる。
ソフトウェアコードを下記の少なくとも３つの異なる方法で端末に転送又はダウンロードできることが知られている。
- 無線モバイル端末の内部に挿入されるＳＩＭ（加入者識別モジュール）を用いることによりスマートカードを介する方法。
- 例えば赤外線／シリアル／ＵＳＢポートを介したパーソナルコンピュータとのリンクを用いることにより外部接続を介する方法。
- 特定の無線チャンネルを用いることにより無線又は無線（ＯＴＡ）[over-the-air]を介する方法。
- 無線モバイル端末の内部に挿入されるＳＩＭ（加入者識別モジュール）を用いることによりスマートカードを介する方法。
- 例えば赤外線／シリアル／ＵＳＢポートを介したパーソナルコンピュータとのリンクを用いることにより外部接続を介する方法。
- 特定の無線チャンネルを用いることにより無線又は無線（ＯＴＡ）[over-the-air]を介する方法。
ソフトウェアのダウンロードに関して、ソフトウェアを端末にダウンロードすることを管理可能にする一般プロトコルの基本的なステップは、ＳＤＲフォーラム（Software Defined Radio Forum）のフレームワークにおいて定義されている（ＵＲＬ：www.sdrforum.org）。
ＳＤＲフォーラムにより定義されたプロトコルはクライアント-サーバ型である。
ＳＤＲフォーラムにより定義されたプロトコルはクライアント-サーバ型である。
ダウンロードのプロトコル・ステップは以下の通りである。
- ダウンロード開始：ダウンロードすべきソフトウェアが存在するサーバに対して、端末がソフトウェアのダウンロードの意思を伝えるステップ。
- 相互認証：端末とサーバが互いに認証する。
- 能力相互通知：サーバがダウンロードすべきソフトウェアについての能力情報を伝え、端末がソフトウェアを端末メモリにロード、インストール、及び実行が可能であるか否かを検証する。
- ダウンロード受理：サーバが端末にダウンロード、インストール及び支払請求のオプションを伝える。端末はサーバにより示された指示が受理可能か否かを決める。
- ダウンロード及び完全性テスト：ソフトウェアのダウンロード中、受信したコードがテストされる。端末は間違って受信した無線ブロックの再送信を要求する。
- インストール：インストールステップ中、ソフトウェアの支払請求及びライセンシング条件がサーバから提供される。
- 現場テスト：ソフトウェアを開始する前に、端末はソフトウェアコードと共にダウンロードされたテストベクタを用いていくつかのテストを実行する。
- 否認防止相互通知：いったんソフトウェアコードがインストールされテストされると、端末はインストールが成功した旨をサーバに確認して例えば支払請求手順を開始する。
- ダウンロード開始：ダウンロードすべきソフトウェアが存在するサーバに対して、端末がソフトウェアのダウンロードの意思を伝えるステップ。
- 相互認証：端末とサーバが互いに認証する。
- 能力相互通知：サーバがダウンロードすべきソフトウェアについての能力情報を伝え、端末がソフトウェアを端末メモリにロード、インストール、及び実行が可能であるか否かを検証する。
- ダウンロード受理：サーバが端末にダウンロード、インストール及び支払請求のオプションを伝える。端末はサーバにより示された指示が受理可能か否かを決める。
- ダウンロード及び完全性テスト：ソフトウェアのダウンロード中、受信したコードがテストされる。端末は間違って受信した無線ブロックの再送信を要求する。
- インストール：インストールステップ中、ソフトウェアの支払請求及びライセンシング条件がサーバから提供される。
- 現場テスト：ソフトウェアを開始する前に、端末はソフトウェアコードと共にダウンロードされたテストベクタを用いていくつかのテストを実行する。
- 否認防止相互通知：いったんソフトウェアコードがインストールされテストされると、端末はインストールが成功した旨をサーバに確認して例えば支払請求手順を開始する。
従来技術、例えば非特許文献２から、無線又はＯＴＡを介したソフトウェアのダウンロードでは無線チャンネルを端末が使用することが予想される。また、ソフトウェアコードのダウンロードは無線チャンネルの類型に依存して下記の２つの異なる方式で実行できることが知られている。
- 「帯域外」方式：現在のシステムから独立した「ユニバーサル」チャンネルによる。例えば端末がスイッチオンされたとき、前記チャンネルに自動的にチューニングし、動作範囲内で動作しているシステムに対して基本ソフトウエアのダウンロードを実行する。
- 「帯域内」方式：第二世代及び第三世代（それぞれＧＳＭ／ＧＰＲＳ及びＵＭＴＳなど）の標準的なセルラーシステムの無線チャンネルを用いることによる。この方式では、既にこれらのチャンネルの１つで動作している端末が、現在使用されているシステムとは異なるシステムに関する基本ソフトウエアを受信する。例えば、ＧＳＭ／ＧＰＲＳなどの第二世代システムで動作している再設定可能な端末は、自身が動作している第二世代無線チャンネルを使用することによりＵＭＴＳなどの第三世代システムのダウンロードを実行できる。
- 「帯域外」方式：現在のシステムから独立した「ユニバーサル」チャンネルによる。例えば端末がスイッチオンされたとき、前記チャンネルに自動的にチューニングし、動作範囲内で動作しているシステムに対して基本ソフトウエアのダウンロードを実行する。
- 「帯域内」方式：第二世代及び第三世代（それぞれＧＳＭ／ＧＰＲＳ及びＵＭＴＳなど）の標準的なセルラーシステムの無線チャンネルを用いることによる。この方式では、既にこれらのチャンネルの１つで動作している端末が、現在使用されているシステムとは異なるシステムに関する基本ソフトウエアを受信する。例えば、ＧＳＭ／ＧＰＲＳなどの第二世代システムで動作している再設定可能な端末は、自身が動作している第二世代無線チャンネルを使用することによりＵＭＴＳなどの第三世代システムのダウンロードを実行できる。
「帯域外」ソフトウェアダウンロードの例は、例えば日本国特許出願第２００１０６１１８６号に記載されている。この文献には、ソフトウェアコンテンツを無線でダウンロードするためのシステム及び方法が記載されている。無線端末がスイッチオンされると、無線端末は動作範囲内の現在のシステムは何であるかをユニバーサルチャンネル上で探り、指示されたシステムに関するソフトウェアダウンロードを実行する。
「帯域内」ソフトウェアダウンロードの例は、例えば米国特許出願第２００３／０１６３５５１号に記載されている。この文献には、下記のものを用いることによりソフトウェアを無線でダウンロードするためのシステム及び方法が記載されている。
- サーバと端末との間での交渉ステップ（能力相互通知、認証、支払請求など）中における専用チャンネル、及び
- 利用可能な無線リソースに負担をかけることなく、できるだけ多くのユーザーにダウンロードサービスを同時に提供するために、ダウンロード手順中における共用共通チャンネル。
- サーバと端末との間での交渉ステップ（能力相互通知、認証、支払請求など）中における専用チャンネル、及び
- 利用可能な無線リソースに負担をかけることなく、できるだけ多くのユーザーにダウンロードサービスを同時に提供するために、ダウンロード手順中における共用共通チャンネル。
「帯域内」ダウンロード方式を考えると、非特許文献３には、基本ソフトウエアのダウンロードを管理できるように、いくつかのプロトコルといくつかのネットワークノード、例えば無線アクセスノード及び／又はコアネットワークノードを大幅に変更することが提案されている。
このような変更は設備製造業者及びネットワークオペレータに相当な努力を課するものであり、既存のセルラーシステムの規格に劇的な影響を与える。したがって、公知の技術が示す限界は、再設定可能な端末のための基本ソフトウエアのダウンロードの管理を既存のセルラーネットワーク（例えばＧＳＭ／ＧＰＲＳ又はＵＭＴＳ）に追加することが望まれるとき、プロトコル及びネットワークノードに対して大幅な変更が必要となることである。
帯域外の方式を考えると、従来技術によると、専用無線チャンネルを必要とし、よってその実装のためにネットワーク内に専用ネットワーク装置又はネットワークノードを実装する必要がある。
要するに、出願人は帯域内及び帯域外の両方のソフトウェアダウンロードの場合において公知の従来技術では再設定可能な無線端末を設定するためにいくつかのプロトコルといくつかのネットワークノードを大きく変更することに注目した。
日本国特許出願第２００１０６１１８６号
米国特許出願第２００３／０１６３５５１号
J.Mitola, 「The Software Radio Architecture」, IEEE Communications Magazine,１９９５年５月
E.Buracchini, 「The Software Radio Concept」, IEEE Communications Magazine,２０００年９月
AAVV,「Architecture of IP based Network Elements Supporting Reconfigurable Terminals」, SCOUT Workshop 16 September 2003
発明の概要
したがって本発明の目的はネットワークノードのアーキテクチャー及びプロトコルを変更することなく無線端末を再設定するために基本ソフトウエアのダウンロードを管理することである。
したがって本発明の目的はネットワークノードのアーキテクチャー及びプロトコルを変更することなく無線端末を再設定するために基本ソフトウエアのダウンロードを管理することである。
本発明の上記の目的は特許請求の範囲に記載の方法、ネットワークアーキテクチャー及びコンピュータプログラムプロダクトにより達成される。
本発明により、アーキテクチャー、方法及び関連のコンピュータプログラムプロダクト又はコンピュータプログラムプロダクトのセット（少なくとも１つのコンピュータのメモリにロード可能であり且つ該プロダクトがコンピュータ上で実行されるとき本発明の方法のステップを実行するためのソフトウェアコード部分を含む）が提供される。明細書においてこのようなコンピュータプログラムプロダクトというときは、本発明の方法の実行に協調するようコンピュータシステムを制御するための命令を含んだコンピュータ読取り可能な媒体を意味するものとする。「少なくとも１つのコンピュータ」といっているのは、明らかに本発明を分散モジュール式に実装する可能性を強調する意図である。
具体的には、本発明によると、好ましい態様において提供されるアーキテクチャー及び方法により、端末は無線を介して基本ソフトウエアのダウンロードを実行でき、該基本ソフトウエアによりモバイル無線端末を再設定でき、該アーキテクチャー及び方法は押しつけがましくない(not intrusive)。特に、ダウンロードは、第二世代（例えばＧＳＭ／ＧＰＲＳ、ＩＳ９５（Interim Standard 95）又はＰＤＣ（Phone Digital Cellular）など）、又は第三世代（例えばＩＭＴ ２０００（International Mobile Telecommunications 2000）ファミリーの無線アクセスシステム）に属し得る使用中のセルラー無線アクセスシステムに対してトランスペアレントに実装できる。
本発明によると、アーキテクチャーは、既存のネットワークプロトコルに影響を与えることなく基本ソフトウエアの無線ダウンロードを管理できるネットワークに接続されたノードを備える。
本発明の好ましい態様によると、コンピュータプログラムプロダクトは、第二世代システムと第三世代システムの両方によってサポートされたＴＣＰ／ＩＰ（Transport Control Protocol/Internet Protocol）プロトコルを利用する。
本発明によると、提案したプロトコルはＳＤＲフォーラムにより与えられた勧告に整合している。
本発明によると、無線（Over The Air）ソフトウェアダウンロードはアクセスネットワークとコアネットワークとにトランスペアレントである。
本発明によると、アーキテクチャーは当該システムから独立しており、第二世代システム（例えばＧＳＭ／ＧＰＲＳ）、第三世代システム（例えばＵＭＴＳ）、及びその他（例えばＤＶＢ、ＷＬＡＮ、８０２．１６）などのような任意の現在又は将来のシステムにおいて実装できる。
本発明によると、基本ソフトウエアが常駐しているサーバ型のノードが提供され、該サーバ型のノードはネットワークに接続されると共に、無線端末上で基本ソフトウエアのダウンロードを実行できる。また、本発明によると、無線端末を再設定するために用いられる方法は押しつけがましくなく、ネットワークがサポートするすべての特徴を利用できる。
以下、好ましいが限定するものではない本発明の態様についての添付図面に関して本発明を説明する。
すべての図面において、同じ構成要素か又は実質的に同じ機能を実装する構成要素を示す際には同じ符号を使用した。
すべての図面において、同じ構成要素か又は実質的に同じ機能を実装する構成要素を示す際には同じ符号を使用した。
発明の詳細な説明
図１には、第２世代（２Ｇ）及び第３世代（３Ｇ）システムにおいて実装された本発明の一態様が示される。特に、一般ＧＰＲＳ、一般ＵＭＴＳネットワーク（「ネットワーク」）及びサーバ（「ＯＴＡサーバ」）又はネットワークに接続されたノードを備えたネットワークアーキテクチャー又はアーキテクチャーが示されている。
図１には、第２世代（２Ｇ）及び第３世代（３Ｇ）システムにおいて実装された本発明の一態様が示される。特に、一般ＧＰＲＳ、一般ＵＭＴＳネットワーク（「ネットワーク」）及びサーバ（「ＯＴＡサーバ」）又はネットワークに接続されたノードを備えたネットワークアーキテクチャー又はアーキテクチャーが示されている。
このネットワークは、再設定可能な端末ＵＥ／ＭＳ（ユーザー装置/移動局）と、ＧＰＲＳシステムの無線アクセスネットワークＧＥＲＡＮ（GSM EDGE Radio Access Network）と、ＵＭＴＳシステムのＵＴＲＡＮ（UMTS Terrestrial Radio Access Network）と、例えばノードＳＧＳＮ（Serving GPRS Support Node）及びＧＧＳＮ（Gateway GPRS Support Node）により構成されたパケットドメインのコアネットワークとを更に備える。ノードＧＧＳＮは例えばサーバＰＲＯＸＹ（「プロクシ」）を介してインターネット型のネットワーク（「インターネット」）に接続される。
本発明の好ましい態様によると、端末ＵＥ／ＭＳはＯＴＡクライアントというソフトウェアアプリケーションを備え、このソフトウェアアプリケーションは、例えば、コアネットワークのノードＧＧＳＮに直接接続されたＯＴＡサーバからの基本ソフトウエアのダウンロードを管理することができる。当業者には理解されるように、ＯＴＡサーバはまた、例えば公知の種類の１以上の通信デバイスを介してコアネットワークに間接的に接続され得る。
ソフトウェアアプリケーションＯＴＡクライアント及び対応するノードＯＴＡサーバは、例えばトランスポートプロトコルＴＣＰ／ＩＰを利用する。
ＯＴＡサーバのアーキテクチャーはダウンロードセッションがアクティブである各ＯＴＡクライアントに対してコンテキストを与える。ソフトウェアアプリケーションが働くと、各ＯＴＡクライアントに対して、及びＯＴＡサーバにより管理されるクライアント・コンテキストとして定義された対応するコンテキストに対して状態図が与えられる。
ＯＴＡサーバのアーキテクチャーはダウンロードセッションがアクティブである各ＯＴＡクライアントに対してコンテキストを与える。ソフトウェアアプリケーションが働くと、各ＯＴＡクライアントに対して、及びＯＴＡサーバにより管理されるクライアント・コンテキストとして定義された対応するコンテキストに対して状態図が与えられる。
好ましい態様によると、機能するソフトウェアは１組の機能するソフトウェアモジュール、好ましくは複数のソフトウェアモジュールからなる。本発明では無線端末ＵＥ／ＭＳを再設定するために、ネットワークにおいて用いられるプロトコルスタックの少なくとも１つの要素セットを実装する基本ソフトウエアモジュールをダウンロードする。
当業者には分かるように、新しい機能の組み込み、更新又はバグの修正を目的として１以上のプロトコル層又はプロトコルスタックの特定層の一部を更新するために、１つの基本ソフトウエアモジュールをダウンロードすることもできる。
図２を参照するに、端末ＵＥ／ＭＳ（端末側）にインストールされたソフトウェアアプリケーションＯＴＡクライアントの状態図を示す。
状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
本発明の好適な実施形態によれば、ＯＴＡクライアントの状態および相対遷移は以下の通りである。
- 「アイドル」状態：アクティブなソフトウェア・ダウンロード手続きが存在しない場合、ＯＴＡクライアント又はクライアントはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、クライアントはこの状態に戻る。
- 「ダウンロード開始」状態：基本ソフトウェアのダウンロードを実行する必要があるとき、例えば、ユーザーがそれを要求するか、又はネットワークにより制御される場合、クライアントはこの状態に入ってタイマーＴ１００を起動する。状態変化が生じた場合にはタイマーＴ１００は停止される。状態変化の前にタイマーＴ１００が終了した場合、クライアントは「アイドル」状態に戻る。
- 「相互認証」状態：この状態で、クライアントはＯＴＡサーバとの相互認証を実行する。サーバから認証要求が来たならば、クライアントはこの状態に入る。クライアントはタイマーＴ２００を起動する。タイマーＴ２００は状態変化が生じた場合に停止される。状態変化の前にタイマーＴ２００が終了するか、または認証が失敗した場合、クライアントは「アイドル」状態に戻る。
- 「能力要求」状態：この状態で、クライアントはサーバに自身の能力を提示する。クライアントは、サーバが自身の能力を要求した場合にこの状態に入る。クライアントがタイマーＴ３００を起動する。タイマーＴ３００は、状態変化が生じた場合に停止される。状態変化の前にタイマーＴ３００が終了した場合、クライアントは「アイドル」状態に戻る。
- 「ダウンロード受理」状態：この状態で、クライアントは、サーバが受信した情報に従いダウンロードを続けるか否かを決定する。クライアントは、サーバから実行すべきダウンロード・プロファイルを受信したならばこの状態に入る。受信したプロファイルが拒否された場合、クライアントは「アイドル」状態に戻る。
- 「ソフトウェア・ダウンロード」状態：この状態で、クライアントは、ソフトウェアのダウンロードを実行する。ダウンロード・プロファイルが受理されたならば、クライアントはこの状態に入る。クライアントはタイマーＴ４００を起動する。タイマーＴ４００は、サーバから受信された各ソフトウェア・ブロックでリセットされて再開される。タイマーＴ４００は、状態変化が生じたならば停止される。状態変化の前にタイマーＴ４００が終了したか、またはダウンロードが失敗した、あるいはダウンロードされたソフトウェアが能力に適合していない場合、クライアントは「アイドル」状態に戻る。
- 「インストール」状態：この状態で、クライアントは、サーバに対しライセンス要求を送信して基本ソフトウェアをインストールする。クライアントは、ダウンロード終了時点でこの状態に入る。クライアントは、タイマーＴ５００を起動する。状態変化が生じた場合、タイマーＴ５００は停止される。状態変化の前にタイマーＴ５００が終了したか、またはライセンスが受理されなかった場合、クライアントは「アイドル」状態に戻る。
- 「現場テスト」状態：この状態で、クライアントは、サーバが受信したいくつかのテスト・ベクトルを用いて、ダウンロードされたソフトウェアに対していくつかのテストを実行する。基本ソフトウェアがインストールされたならば、クライアントはこの状態に入る。一旦テストが終了したならば、クライアントは「アイドル」状態に戻る。
- 「アイドル」状態：アクティブなソフトウェア・ダウンロード手続きが存在しない場合、ＯＴＡクライアント又はクライアントはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、クライアントはこの状態に戻る。
- 「ダウンロード開始」状態：基本ソフトウェアのダウンロードを実行する必要があるとき、例えば、ユーザーがそれを要求するか、又はネットワークにより制御される場合、クライアントはこの状態に入ってタイマーＴ１００を起動する。状態変化が生じた場合にはタイマーＴ１００は停止される。状態変化の前にタイマーＴ１００が終了した場合、クライアントは「アイドル」状態に戻る。
- 「相互認証」状態：この状態で、クライアントはＯＴＡサーバとの相互認証を実行する。サーバから認証要求が来たならば、クライアントはこの状態に入る。クライアントはタイマーＴ２００を起動する。タイマーＴ２００は状態変化が生じた場合に停止される。状態変化の前にタイマーＴ２００が終了するか、または認証が失敗した場合、クライアントは「アイドル」状態に戻る。
- 「能力要求」状態：この状態で、クライアントはサーバに自身の能力を提示する。クライアントは、サーバが自身の能力を要求した場合にこの状態に入る。クライアントがタイマーＴ３００を起動する。タイマーＴ３００は、状態変化が生じた場合に停止される。状態変化の前にタイマーＴ３００が終了した場合、クライアントは「アイドル」状態に戻る。
- 「ダウンロード受理」状態：この状態で、クライアントは、サーバが受信した情報に従いダウンロードを続けるか否かを決定する。クライアントは、サーバから実行すべきダウンロード・プロファイルを受信したならばこの状態に入る。受信したプロファイルが拒否された場合、クライアントは「アイドル」状態に戻る。
- 「ソフトウェア・ダウンロード」状態：この状態で、クライアントは、ソフトウェアのダウンロードを実行する。ダウンロード・プロファイルが受理されたならば、クライアントはこの状態に入る。クライアントはタイマーＴ４００を起動する。タイマーＴ４００は、サーバから受信された各ソフトウェア・ブロックでリセットされて再開される。タイマーＴ４００は、状態変化が生じたならば停止される。状態変化の前にタイマーＴ４００が終了したか、またはダウンロードが失敗した、あるいはダウンロードされたソフトウェアが能力に適合していない場合、クライアントは「アイドル」状態に戻る。
- 「インストール」状態：この状態で、クライアントは、サーバに対しライセンス要求を送信して基本ソフトウェアをインストールする。クライアントは、ダウンロード終了時点でこの状態に入る。クライアントは、タイマーＴ５００を起動する。状態変化が生じた場合、タイマーＴ５００は停止される。状態変化の前にタイマーＴ５００が終了したか、またはライセンスが受理されなかった場合、クライアントは「アイドル」状態に戻る。
- 「現場テスト」状態：この状態で、クライアントは、サーバが受信したいくつかのテスト・ベクトルを用いて、ダウンロードされたソフトウェアに対していくつかのテストを実行する。基本ソフトウェアがインストールされたならば、クライアントはこの状態に入る。一旦テストが終了したならば、クライアントは「アイドル」状態に戻る。
図３を参照するに、ＯＴＡサーバ（サーバー側）が管理するクライアント・コンテキストの状態図を示す。
先に述べたように、状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
クライアント・コンテキストの状態および相対遷移は以下の通りである。
- 「アイドル」状態：アクティブなソフトウェア・ダウンロード手続きが存在しない場合、ＯＴＡサーバが管理するクライアント・コンテキストはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、クライアント・コンテキストはこの状態に戻る。
- 「ダウンロード開始」状態：この状態で、クライアント・コンテキスト又はＯＴＡサーバはＯＴＡクライアントにダウンロードを実行するよう指示する。基本ソフトウェアのダウンロードを実行することが必要な場合（このダウンロードは例えばＯＴＡクライアントにより要求されるか、又は予定された周期的な更新に従って要求される）、クライアント・コンテキストはこの状態に入ってタイマーＴ１０１を起動する。状態変化の前にタイマーＴ１０１は停止される。状態変化の前にタイマーＴ１０１が終了した場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「相互認証」状態：この状態で、サーバは自身を認証し、ＯＴＡクライアントに対して自身を認証するよう要求する。クライアントからダウンロード確認を受信したならば、ＯＴＡサーバはこの状態に入る。ＯＴＡサーバはタイマーＴ２０１を起動する。タイマーＴ２０１は状態変化が生じた場合に停止される。状態変化の前にタイマーＴ２０１が終了するか、または認証が失敗した場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「能力要求」状態：この状態で、ＯＴＡサーバはＯＴＡクライアントに対しその能力の提示を要求する。認証が完了したならばＯＴＡサーバはこの状態に入る。ＯＴＡサーバがタイマーＴ３０１を起動する。タイマーＴ３０１は、状態変化が生じた場合に停止される。状態変化の前にタイマーＴ３０１が終了するか、または能力に起因してダウンロードが不可能な場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「ダウンロード受理」状態：この状態で、ＯＴＡサーバは、ダウンロード・プロファイルをＯＴＡクライアントに通知する。ＯＴＡサーバは、端末能力を受信して、当該能力が受理されたならばこの状態に入る。ＯＴＡサーバがタイマーＴ３０２を起動する。タイマーＴ３０２は、状態変化が生じた場合に停止される。状態変化の前にタイマーＴ３０２が終了するか、または提案されたダウンロードをＯＴＡクライアントが拒否した場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「ソフトウェア・ダウンロード」状態：この状態で、ＯＴＡサーバは、ＯＴＡクライアントへのソフトウェアのダウンロードを実行する。ダウンロード・プロファイルがＯＴＡクライアントにより受理された場合、ＯＴＡサーバはこの状態に入る。クライアントは、タイマーＴ４０１を開始する。タイマーＴ４０１はリセットされて、クライアントから受信された各々の肯定応答信号Ａｃｋで再開される。状態変化が生じた場合、タイマーＴ４０１は停止される。状態変化の前にタイマーＴ４０１が終了するか、またはダウンロードが失敗した場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「インストール」状態：この状態で、ＯＴＡサーバは、クライアントがダウンロードされたソフトウェアのインストールおよびテストを実行するまで、ライセンス条件をＯＴＡクライアントへ通知して待機する。ダウンロードが終了したならば、ＯＴＡサーバはこの状態に入る。ＯＴＡサーバがタイマーＴ５０１を起動する。状態変化が生じたならばタイマーＴ５０１は停止される。状態変化の前にタイマーＴ５０１が終了するか、またはライセンスがＯＴＡクライアントにより受理されなかった場合、ＯＴＡクライアントは「アイドル」状態に戻る。ＯＴＡサーバは、ＯＴＡクライアントによるインストールの成功に関する肯定応答信号を受信したならば、「アイドル」状態に戻る。
先に述べたように、状態を名付けるために用いる用語は単に指示用であり、記述されているように対応する動作が重要である。
クライアント・コンテキストの状態および相対遷移は以下の通りである。
- 「アイドル」状態：アクティブなソフトウェア・ダウンロード手続きが存在しない場合、ＯＴＡサーバが管理するクライアント・コンテキストはこの状態にある。手続きが正しく終了されたか、または不具合が生じた場合、クライアント・コンテキストはこの状態に戻る。
- 「ダウンロード開始」状態：この状態で、クライアント・コンテキスト又はＯＴＡサーバはＯＴＡクライアントにダウンロードを実行するよう指示する。基本ソフトウェアのダウンロードを実行することが必要な場合（このダウンロードは例えばＯＴＡクライアントにより要求されるか、又は予定された周期的な更新に従って要求される）、クライアント・コンテキストはこの状態に入ってタイマーＴ１０１を起動する。状態変化の前にタイマーＴ１０１は停止される。状態変化の前にタイマーＴ１０１が終了した場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「相互認証」状態：この状態で、サーバは自身を認証し、ＯＴＡクライアントに対して自身を認証するよう要求する。クライアントからダウンロード確認を受信したならば、ＯＴＡサーバはこの状態に入る。ＯＴＡサーバはタイマーＴ２０１を起動する。タイマーＴ２０１は状態変化が生じた場合に停止される。状態変化の前にタイマーＴ２０１が終了するか、または認証が失敗した場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「能力要求」状態：この状態で、ＯＴＡサーバはＯＴＡクライアントに対しその能力の提示を要求する。認証が完了したならばＯＴＡサーバはこの状態に入る。ＯＴＡサーバがタイマーＴ３０１を起動する。タイマーＴ３０１は、状態変化が生じた場合に停止される。状態変化の前にタイマーＴ３０１が終了するか、または能力に起因してダウンロードが不可能な場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「ダウンロード受理」状態：この状態で、ＯＴＡサーバは、ダウンロード・プロファイルをＯＴＡクライアントに通知する。ＯＴＡサーバは、端末能力を受信して、当該能力が受理されたならばこの状態に入る。ＯＴＡサーバがタイマーＴ３０２を起動する。タイマーＴ３０２は、状態変化が生じた場合に停止される。状態変化の前にタイマーＴ３０２が終了するか、または提案されたダウンロードをＯＴＡクライアントが拒否した場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「ソフトウェア・ダウンロード」状態：この状態で、ＯＴＡサーバは、ＯＴＡクライアントへのソフトウェアのダウンロードを実行する。ダウンロード・プロファイルがＯＴＡクライアントにより受理された場合、ＯＴＡサーバはこの状態に入る。クライアントは、タイマーＴ４０１を開始する。タイマーＴ４０１はリセットされて、クライアントから受信された各々の肯定応答信号Ａｃｋで再開される。状態変化が生じた場合、タイマーＴ４０１は停止される。状態変化の前にタイマーＴ４０１が終了するか、またはダウンロードが失敗した場合、クライアント・コンテキストは「アイドル」状態に戻る。
- 「インストール」状態：この状態で、ＯＴＡサーバは、クライアントがダウンロードされたソフトウェアのインストールおよびテストを実行するまで、ライセンス条件をＯＴＡクライアントへ通知して待機する。ダウンロードが終了したならば、ＯＴＡサーバはこの状態に入る。ＯＴＡサーバがタイマーＴ５０１を起動する。状態変化が生じたならばタイマーＴ５０１は停止される。状態変化の前にタイマーＴ５０１が終了するか、またはライセンスがＯＴＡクライアントにより受理されなかった場合、ＯＴＡクライアントは「アイドル」状態に戻る。ＯＴＡサーバは、ＯＴＡクライアントによるインストールの成功に関する肯定応答信号を受信したならば、「アイドル」状態に戻る。
以下、図４ａ〜４ｋに関して、ＯＴＡサーバとＯＴＡクライアントとの間で交換されるプロトコルメッセージの構造を詳しく説明する。
メッセージおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。
メッセージおよび関連フィールドを名付けるために用いる用語は単に指示用であり、記述されているように対応する定義が重要である。
図４ａを参照するに、「ダウンロード開始要求」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバに送信される。端末はこのメッセージを用いて、サーバに対してダウンロード・セッションを開始するよう要求する。一般に各ダウンロード・セッションはＯＴＡサーバにより制御される。
この場合に提供されるフィールドは、少なくとも以下のうち１組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード開始要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：要求を実行するＯＴＡクライアントを識別する。
図４ｂを参照するに、「ダウンロード要求」メッセージの構造を記述している。このメッセージはＯＴＡサーバからＯＴＡクライアントに送信される。このメッセージにより、サーバはクライアントに対してダウンロード・セッションを開始するよう命令する。この場合に提供されるフィールドは、少なくとも以下のうち１組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：要求の対象であるＯＴＡクライアントを識別する。
- 「利用可能なダウンロード」：可能なダウンロードのリストを含む。各要素は記述ストリングと数字識別子とを含む。このリスト中に存在する要素の数は可変である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード開始要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：要求を実行するＯＴＡクライアントを識別する。
図４ｂを参照するに、「ダウンロード要求」メッセージの構造を記述している。このメッセージはＯＴＡサーバからＯＴＡクライアントに送信される。このメッセージにより、サーバはクライアントに対してダウンロード・セッションを開始するよう命令する。この場合に提供されるフィールドは、少なくとも以下のうち１組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：要求の対象であるＯＴＡクライアントを識別する。
- 「利用可能なダウンロード」：可能なダウンロードのリストを含む。各要素は記述ストリングと数字識別子とを含む。このリスト中に存在する要素の数は可変である。
図４ｃを参照するに、「ダウンロードＡｃｋ」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントはＯＴＡサーバにダウンロード・セッションを開始する同意を通知する。
この場合に提供されるフィールドは、少なくとも以下のうち１組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロードＡｃｋ」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「選択されたダウンロード」：ユーザーが選択したダウンロードのリストからなる。各要素は記述ストリングと数字識別子とを含む。リスト中に存在する要素数は可変である。
- 「ＯＴＡクライアント・チャレンジ番号」：ＯＴＡサーバが相互認証の第１ステップを実行するために自身の鍵及び適当な暗号化アルゴリズム（例えばＡＥＳ（Advanced Encryption Standard）アルゴリズム）を用いて暗号化する乱数である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロードＡｃｋ」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「選択されたダウンロード」：ユーザーが選択したダウンロードのリストからなる。各要素は記述ストリングと数字識別子とを含む。リスト中に存在する要素数は可変である。
- 「ＯＴＡクライアント・チャレンジ番号」：ＯＴＡサーバが相互認証の第１ステップを実行するために自身の鍵及び適当な暗号化アルゴリズム（例えばＡＥＳ（Advanced Encryption Standard）アルゴリズム）を用いて暗号化する乱数である。
再び図４ａを参照するに、「ダウンロード拒否」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージを用いて、ＯＴＡクライアントはダウンロード・セッションを開始できない旨をＯＴＡサーバに通知する。
この場合に提供されるフィールドは、少なくとも以下のうち１組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード拒否」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード拒否」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
図４ｄを参照するに、「認証要求」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバは、自身の証明をＯＴＡクライアントに通知し、ＯＴＡクライアントにそれを確認することが要求する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「認証要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
- 「ＯＴＡサーバ応答番号」：相互認証の第１ステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡサーバにより暗号化される番号である。
- 「ＯＴＡサーバ・チャレンジ番号」：相互認証の第２ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばＡＥＳアルゴリズムを用いて暗号化する乱数である。
- 「メッセージ種別」：送信されたメッセージの種別（「認証要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
- 「ＯＴＡサーバ応答番号」：相互認証の第１ステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡサーバにより暗号化される番号である。
- 「ＯＴＡサーバ・チャレンジ番号」：相互認証の第２ステップを実行すべく、クライアントが自身の鍵および適切な暗号化アルゴリズム、例えばＡＥＳアルゴリズムを用いて暗号化する乱数である。
図４ｅを参照するに、「認証応答」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、既にサーバを認証した状態で、クライアントは自身の証明をＯＴＡサーバに通知する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「認証応答」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「ＯＴＡクライアント応答番号」：相互認証の第２および最後のステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡクライアントにより暗号化される番号を識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「認証応答」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「ＯＴＡクライアント応答番号」：相互認証の第２および最後のステップを完了すべく、自身の鍵および例えばＡＥＳアルゴリズム等の適当な暗号化アルゴリズムを用いてＯＴＡクライアントにより暗号化される番号を識別する。
再度図４ａを参照するに、「認証失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバ／ＯＴＡクライアントは、ＯＴＡサーバがＯＴＡクライアントを認証しなかった旨をＯＴＡクライアント／ＯＴＡサーバに通知する（その逆も同様）。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「認証失敗」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信／受信するＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「認証失敗」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信／受信するＯＴＡクライアントを識別する。
再度図４ａを参照するに、「能力要求」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡクライアントは、ＯＴＡサーバに対しその再設定可能性オプションを要求する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「能力要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「能力要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
図４ｆを参照するに、「能力応答」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントは、自身の再設定可能性オプションをＯＴＡサーバに知らせる。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「能力応答」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「ＯＴＡクライアント能力」：端末の再設定可能性オプションを記述する。
- 「メッセージ種別」：送信されたメッセージの種別（「能力応答」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「ＯＴＡクライアント能力」：端末の再設定可能性オプションを記述する。
図４ｇを参照するに、「ダウンロード記述」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバは、ダウンロードに関するデータをＯＴＡクライアントに報告する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード記述」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
- 「ダウンロード・リスト」：各ダウンロードにつきクライアントにより選択された１個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
- 「ダウンロード・ブロック番号」：クライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
- 「支払請求基準」：起こり得るダウンロード支払請求に関する基準である。
- 「インストール基準」：ソフトウェアのインストールに関する基準である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード記述」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
- 「ダウンロード・リスト」：各ダウンロードにつきクライアントにより選択された１個の要素を含む。当該フィールドは以下のフィールドを含んでいる。
- 「ダウンロード・ブロック番号」：クライアントへ送信される前に基本ソフトウェアが分割される無線ブロックの個数である。
- 「支払請求基準」：起こり得るダウンロード支払請求に関する基準である。
- 「インストール基準」：ソフトウェアのインストールに関する基準である。
再び図４ａを参照するに、「ダウンロード受理」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントは選択されたダウンロードを確認する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード受理」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード受理」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
再び図４ａを参照するに、「ダウンロード拒否」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントは選択されたダウンロードを拒絶する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード拒否」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード拒否」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
再び図４ａを参照するに、「ダウンロード失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ソフトウェアダウンロード手順において失敗がある旨を知らせる。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード失敗」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「ダウンロード失敗」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
再び図４ａを参照するに、「ライセンス要求」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、クライアントはサーバに対し、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵を要求する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ライセンス要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「ライセンス要求」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
図４ｈを参照するに、「ライセンス応答」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバはＯＴＡクライアントに対し、ダウンロードされた基本ソフトウェアを復号化およびインストールするための鍵を通知する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ライセンス応答」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
- 復号化鍵：基本ソフトウェアを復号化するために用いられる鍵である。
- 「メッセージ種別」：送信されたメッセージの種別（「ライセンス応答」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送信されるＯＴＡクライアントを識別する。
- 復号化鍵：基本ソフトウェアを復号化するために用いられる鍵である。
再び図４ａを参照するに、「ライセンス受理」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアが正しく復号化された旨を通知する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ライセンス受理」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「ライセンス受理」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
再び図４ａを参照するに、「ライセンス失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアが正しく復号化されなかった旨を通知する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「ライセンス失敗」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「ライセンス失敗」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
図４ｉを参照するに、「テスト記述」メッセージの構造を記述している。このメッセージは、ＯＴＡサーバからＯＴＡクライアントへ送信される。このメッセージにより、ＯＴＡサーバはＯＴＡクライアントに対し、ダウンロードされた基本ソフトウェアを開始する前に該基本ソフトウェアに実行すべきテストを指示する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「テスト記述」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送られるＯＴＡクライアントを識別する。
- 「テスト・リスト」：実行すべき各々のテストについて１個の要素を含み、これは更に以下のフィールドを含んでいる。
- 「テスト・ベクトル」：テストの記述を含んでいる。
- 「メッセージ種別」：送信されたメッセージの種別（「テスト記述」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージが送られるＯＴＡクライアントを識別する。
- 「テスト・リスト」：実行すべき各々のテストについて１個の要素を含み、これは更に以下のフィールドを含んでいる。
- 「テスト・ベクトル」：テストの記述を含んでいる。
再び図４ａを参照するに、「インストール成功」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功した旨を通知する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「インストール成功」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「インストール成功」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
再び図４ａを参照するに、「インストール失敗」メッセージの構造を記述している。このメッセージは、ＯＴＡクライアントからＯＴＡサーバへ送信される。このメッセージにより、ＯＴＡクライアントはＯＴＡサーバに対し、ダウンロードされた基本ソフトウェアのテストが成功しなかった旨を通知する。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「インストール失敗」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
- 「メッセージ種別」：送信されたメッセージの種別（「インストール失敗」）を識別する。
- 「ＯＴＡクライアントＩＤ」：メッセージを送信しているＯＴＡクライアントを識別する。
基本ソフトウェアをサーバからクライアントに送信するのに用いられるウィンドウ・プロトコルは、ＢｌｏｃｋおよびＡｃｋと呼ばれる２種類のプロトコル・データ・ユニットすなわちＰＤＵに基づいている。
図４ｊを参照するに、基本ソフトウェアが分割された無線ブロックＢｌｏｃｋの構造を記述している。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：ブロック種別を識別する。
- 「ブロック番号」：無線ブロックのシーケンス番号を識別する。このシーケンス番号は、ＯＴＡクライアントが基本ソフトウェア全体を再アセンブルするときに用いられる。
- 「データ」：無線ブロック中に含まれ、一般に１〜２キロバイトのサイズを有する。
- 「メッセージ種別」：ブロック種別を識別する。
- 「ブロック番号」：無線ブロックのシーケンス番号を識別する。このシーケンス番号は、ＯＴＡクライアントが基本ソフトウェア全体を再アセンブルするときに用いられる。
- 「データ」：無線ブロック中に含まれ、一般に１〜２キロバイトのサイズを有する。
図４ｋを参照するに、端末の受信状態を示すために用いるメッセージＡｃｋの構造を記述している。
この場合に提供されるフィールドは、以下のうち少なくとも一組である。
- 「メッセージ種別」：送信されたメッセージの種別（「Ａｃｋ」）を識別する。
- 「ビットマスク・クライアント」：基本ソフトウェアが分割された無線ブロックの総数に等しいサイズを有するビット・マスクである。各々の無線ブロックについて、当該ブロックが首尾よく受信された場合は「１」にセットされ、ブロックが受信されたものの損傷しているかまたは全く受信されなかった場合は「０」のままである。
- 「メッセージ種別」：送信されたメッセージの種別（「Ａｃｋ」）を識別する。
- 「ビットマスク・クライアント」：基本ソフトウェアが分割された無線ブロックの総数に等しいサイズを有するビット・マスクである。各々の無線ブロックについて、当該ブロックが首尾よく受信された場合は「１」にセットされ、ブロックが受信されたものの損傷しているかまたは全く受信されなかった場合は「０」のままである。
要約するに、上例によれば、ＯＴＡクライアントおよびＯＴＡサーバの機能的な挙動は以下の通りである。
- ダウンロード手続きは、例えば、ＯＴＡサーバにより開始され、ＯＴＡクライアントはダウンロード手順の始動を要求できる。
- クライアントとサーバとの間の相互認証は、例えば、「チャレンジ応答」方式に従い行われる。
- ダウンロードされる基本ソフトウェアは、例えば、サイズを縮小した（例えば、１〜２キロバイトの範囲）ブロックに分割される。
- 基本ソフトウェアの転送は例えば簡単なウィンドウ・プロトコルにより管理され、その際にウィンドウのサイズは基本ソフトウェアが分割されたブロックの個数と一致する。
- ダウンロードされた基本ソフトウェアは暗号化することができ、例えば、復号化およびインストールのために鍵が必要とされる。
- 基本ソフトウェアを開始する前に、クライアントは、サーバにより提案された適切なテストによりこれを検査できる。
- ダウンロード手続きは、例えば、ＯＴＡサーバにより開始され、ＯＴＡクライアントはダウンロード手順の始動を要求できる。
- クライアントとサーバとの間の相互認証は、例えば、「チャレンジ応答」方式に従い行われる。
- ダウンロードされる基本ソフトウェアは、例えば、サイズを縮小した（例えば、１〜２キロバイトの範囲）ブロックに分割される。
- 基本ソフトウェアの転送は例えば簡単なウィンドウ・プロトコルにより管理され、その際にウィンドウのサイズは基本ソフトウェアが分割されたブロックの個数と一致する。
- ダウンロードされた基本ソフトウェアは暗号化することができ、例えば、復号化およびインストールのために鍵が必要とされる。
- 基本ソフトウェアを開始する前に、クライアントは、サーバにより提案された適切なテストによりこれを検査できる。
以下、図５ａ〜５ｊに関し、ＯＴＡクライアントとＯＴＡサーバとの間での手続上の相互作用を、受信した各プロトコルメッセージについてＯＴＡクライアント又はクライアント・コンテキストの状態に従った相対的な挙動を示すことによって説明する。図５ａ〜５ｊは可能なすべての手続上の相互作用の例を示す。
理解を容易にするため、上述したように、タイマーはＯＴＡクライアント又はクライアント・コンテキストが１つの状態から別の状態に移ったときに開始／停止させることに留意する。
図５ａでは、操作が実行されていないとき、ＯＴＡサーバにより管理された当該ＯＴＡクライアントに対してＯＴＡクライアント及びクライアント・コンテキストは「アイドル」状態にある（ステップ１００）。
ユーザー又はネットワークが新しい基本ソフトウエアのダウンロードを実行することを決めると（ステップ１０２）、無線接続が開かれ（ステップ１０４）タイマーＴ１００をスタートさせる。無線接続については後で図６を説明するとき更に詳細に説明する。
この段階で、ＯＴＡクライアントは「ダウンロード開始要求」プロトコルメッセージをＯＴＡサーバに送信することによりソフトウェアダウンロード手順を始めることができ（ステップ１０６）、その識別子はメッセージ中に示されているＯＴＡクライアントを識別する。原則として、ＯＴＡクライアントＩＤがプロトコルメッセージを受信するＯＴＡクライアントの識別子に対応しないならば、メッセージは無視される。
次に、ＯＴＡサーバが「ダウンロード開始要求」メッセージを受信し（ステップ１０８）、クライアント・コンテキストの状態が「アイドル」でないならば（ステップ１１０）、メッセージは無視されて手順は停止し（ステップ１１２）、そうでなければクライアント・コンテキストが「アイドル」状態から「ダウンロード開始」状態に移り（ステップ１１４）、タイマーＴ１０１をスタートし、そして様々な可能なダウンロードを示す「ダウンロード要求」プロトコルメッセージをクライアントに送信する（ステップ１１６）。ＯＴＡクライアントは「ダウンロード要求」メッセージを受信し（ステップ１１８）、ＯＴＡクライアントの状態が「アイドル」であるならば（ステップ１２０）、ＯＴＡクライアントは「アイドル」状態から「ダウンロード開始」状態に移り（ステップ１２４）、そうでなければメッセージが無視されて手順が停止する（ステップ１２２）。
次に図５ｂを参照すると、「ダウンロード要求」メッセージ中に示された利用可能なダウンロードの選択がユーザーに提示される（ステップ１２６）。ユーザーが少なくとも１つのダウンロードを選ぶと（ステップ１２８）、ＯＴＡクライアントが乱数ＲＮＵＭ１を取り出して記憶し（ステップ１４２）、取り出した数ＲＮＵＭ１の値を「ＯＴＡクライアント・チャレンジ番号」フィールド中に含んだ「ダウンロードＡｃｋ」メッセージをＯＴＡサーバに送信する（ステップ１４４）。
ユーザーがどのダウンロードも選ばないならば（ステップ１２８）、ＯＴＡクライアントはクライアント・コンテキストに「ダウンロード拒否」メッセージを送り（ステップ１３０）、「アイドル」状態に戻る（ステップ１３２）。次にＯＴＡサーバは「ダウンロード拒否」メッセージを受信する（ステップ１３４）。クライアント・コンテキストの状態が「ダウンロード開始」でないならば（ステップ１３６）、メッセージは無視され手順が停止し（ステップ１３８）、そうでないならばクライアント・コンテキストは「アイドル」状態に戻る（ステップ１４０）。
ＯＴＡサーバが「ダウンロードＡｃｋ」メッセージを受信すると（ステップ１４６）、クライアント・コンテキストの状態が「ダウンロード開始」でないならば（ステップ１４８）、メッセージは無視され手順は停止し（ステップ１５０）、そうでなければクライアント・コンテキストはタイマーＴ２０１をスタートさせる一方でタイマーＴ１０１を停止させて「ダウンロード開始」状態から「相互認証」状態に移る（ステップ１５２）。
次にＯＴＡサーバにより乱数ＲＮＵＭ２が取り出されて記憶される（ステップ１５４）。「ＯＴＡクライアント・チャレンジ番号」フィールドの値は、例えばＡＥＳなどの選択された暗号化アルゴリズムを用いることによりＯＴＡサーバ内部鍵で暗号化される（ステップ１５６）。
ＯＴＡサーバは、ステップ１５６で暗号化され「ＯＴＡサーバ応答番号」フィールドに書き込まれた値及び「ＯＴＡサーバ・チャレンジ番号」フィールド中の取り出された数ＲＮＵＭ２の値と共に「認証要求」プロトコルメッセージをＯＴＡクライアントに送信する（ステップ１５８）。
ＯＴＡサーバは、ステップ１５６で暗号化され「ＯＴＡサーバ応答番号」フィールドに書き込まれた値及び「ＯＴＡサーバ・チャレンジ番号」フィールド中の取り出された数ＲＮＵＭ２の値と共に「認証要求」プロトコルメッセージをＯＴＡクライアントに送信する（ステップ１５８）。
次に、図５ｃでは、ＯＴＡクライアントが「認証要求」メッセージを受信し（ステップ１６０）、タイマーＴ１００を停止する。ＯＴＡクライアントが「ダウンロード開始」状態にないならば（ステップ１６２）、メッセージは無視され手順が停止し（ステップ１６４）、そうでなければ、ＯＴＡクライアントは「ダウンロード開始」状態から「相互認証」状態に移り（ステップ１６６）、タイマーＴ２００をスタートさせる。
記憶された乱数ＲＮＵＭ１が有効でないならば（ステップ１６８）、「認証失敗」メッセージがＯＴＡクライアントによりクライアント・コンテキストに送られ（ステップ１７０）、ＯＴＡクライアントが「相互認証」状態から「アイドル」状態に移り（ステップ１７２）、タイマーＴ２００が停止される。次にクライアント・コンテキストが「認証失敗」メッセージを受信し（ステップ１７４）、タイマーＴ２０１を停止し、クライアント・コンテキストが「相互認証」状態にあるならば（ステップ１７６）、クライアント・コンテキストは「相互認証」状態から「アイドル」状態に移り（ステップ１８０）、そうでなければ手順が停止する（ステップ１７８）。
記憶された値ＲＮＵＭ１が有効であるならば（ステップ１６８）、選択された暗号化アルゴリズム（例えばＡＥＳなど）を用いることにより記憶された乱数ＲＮＵＭ１の値をＯＴＡクライアント内部鍵で暗号化する（ステップ１８２）。ステップ１８２で暗号化された値が「ＯＴＡサーバ応答番号」フィールドに含まれる値と一致しないならば（ステップ１８４）、ステップ１７０に手順が戻り、既に説明したようにステップ１７０〜１８０が実行される。
ステップ１８２で暗号化された値が「ＯＴＡサーバ応答番号」フィールドに含まれる値に一致するならば（ステップ１８４）、選択された暗号化アルゴリズム（例えばＡＥＳなど）を用いることにより「ＯＴＡサーバ・チャレンジ番号」フィールドの値がＯＴＡクライアント内部鍵で暗号化される（ステップ１８６）。次にステップ１８６で暗号化された値を「ＯＴＡクライアント応答番号」フィールド中に含む「認証応答」メッセージがＯＴＡクライアントによりクライアント・コンテキストに送られる（ステップ１８８）。
次にＯＴＡサーバが「認証応答」メッセージを受信し（ステップ１９０）、図５ｄにて、クライアント・コンテキストの状態が「相互認証」でないならば（ステップ１９２）、メッセージは無視され手順が停止し（ステップ１９４）、そうでなければ選択された暗号化アルゴリズム（例えばＡＥＳなど）を用いることにより記憶された乱数ＲＮＵＭ２の値がＯＴＡサーバ内部鍵で暗号化される（ステップ１９６）。
ステップ１９６で暗号化された値が「ＯＴＡクライアント応答番号」フィールドの値に一致しないならば（ステップ１９８）、「認証失敗」メッセージがクライアント・コンテキストによりＯＴＡクライアントに送られ（ステップ２００）、クライアント・コンテキストが「相互認証」状態から「アイドル」状態に移る（ステップ２０２）。次にＯＴＡクライアントが「認証失敗」メッセージを受信し（ステップ２０４）、ＯＴＡクライアントが「相互認証」状態にあるならば（ステップ２０６）、ＯＴＡクライアントが「相互認証」状態から「アイドル」状態に移り（ステップ２１０）、そうでなければ手順が停止する（ステップ２０８）。
ステップ１９６で暗号化された値が「ＯＴＡクライアント応答番号」フィールドの値に一致するならば（ステップ１９８）、クライアント・コンテキストはタイマーＴ２０１を停止し、「相互認証」状態から「能力要求」状態に移り（ステップ２１２）、タイマーＴ３０１を始動させる。次に「能力要求」プロトコルメッセージがクライアント・コンテキストによりＯＴＡクライアントに送られ（ステップ２１４）、ＯＴＡクライアントにより受信され（ステップ２１６）、ＯＴＡクライアントがタイマーＴ２００を停止する。ＯＴＡクライアントの状態が「相互認証」でなければ（ステップ２１８）、メッセージは無視され手順が停止し（ステップ２２０）、そうでなければＯＴＡクライアントが「相互認証」状態から「能力要求」状態に移り（ステップ２２２）、一方タイマーＴ３００をスタートさせる。次にＯＴＡクライアントはクライアント・コンテキストに「能力応答」メッセージを送り（ステップ２２４）、クライアント・コンテキストがそれを受信する（ステップ２２６）。
図５ｅでは、クライアント・コンテキストの状態が「能力要求」でないならば（ステップ２２８）、メッセージは無視され手順が停止し（ステップ２３０）、そうでなければ、メッセージ中に含まれる能力がダウンロードされるソフトウェアに適合しないならば（ステップ２３２）、クライアント・コンテキストは「能力応答」状態から「アイドル」状態に移り（ステップ２３４）、タイマーＴ３０１が停止される。能力がダウンロードされるソフトウェアに適合するならば（ステップ２３２）、タイマーＴ３０１が停止され、クライアント・コンテキストが「能力要求」状態から「ダウンロード受理」状態に移り（ステップ２３６）、一方タイマーＴ３０２をスタートさせてＯＴＡクライアントに「ダウンロード記述」メッセージを送信する（ステップ２３８）。
次にＯＴＡクライアントは「ダウンロード記述」メッセージを受信し（ステップ２４０）、タイマーＴ３００を停止する。ＯＴＡクライアントが「能力要求」状態にないならば（ステップ２４２）、メッセージは無視され手順が停止し（ステップ２４４）、そうでなければＯＴＡクライアントが「能力要求」状態から「ダウンロード受理」状態に移る（ステップ２４６）。支払請求、インストールなどのダウンロードオプションがユーザーに提示される（ステップ２４８）。図５ｆでは、ユーザーがダウンロードを拒否するならば（ステップ２５０）、ＯＴＡクライアントは「ダウンロード拒否」メッセージをクライアント・コンテキストに送り（ステップ２５２）、「ダウンロード受理」状態から「アイドル」状態に移る（ステップ２５４）。また、クライアント・コンテキストが「ダウンロード拒否」メッセージを受信し（ステップ２５６）、クライアント・コンテキストの状態が「ダウンロード受理」でないならば（ステップ２５８）、メッセージは無視され手順が停止し（ステップ２６０）、そうでなければクライアント・コンテキストが「ダウンロード受理」状態から「アイドル」状態に移る（ステップ２６２）。
ユーザーがダウンロードを受理するならば（ステップ２５０）、ＯＴＡクライアントがクライアント・コンテキストに「ダウンロード受理」メッセージを送り（ステップ２６４）、ＯＴＡ-クライアントが「ダウンロード受理」状態から「ソフトウエア・ダウンロード」状態に移る（ステップ２６６）。
次にクライアント・コンテキストが「ダウンロード受理」メッセージを受信し（ステップ２６８）、タイマーＴ３０２を停止する。クライアント・コンテキストの状態が「ダウンロード受理」でないならば（ステップ２７０）、メッセージは無視され手順が停止し（ステップ２７２）、そうでなければクライアント・コンテキストが「ダウンロード受理」状態から「ソフトウエア・ダウンロード」状態に移り（ステップ２７４）、一方タイマーＴ４００をスタートさせ、ソフトウェアダウンロードが始まる（ステップ２７６）。
ソフトウェアダウンロードが成功でないならば（ステップ２７８）、ＯＴＡクライアント／クライアント・コンテキストがクライアント・コンテキスト／ＯＴＡクライアントに「ダウンロード失敗」メッセージを送り（ステップ２８０）、ＯＴＡクライアント／クライアント・コンテキストが「ダウンロード・ソフトウエア」状態から「アイドル」状態に移る（ステップ２８２）。ソフトウェアダウンロード（ステップ２７６）については後で詳しく説明する。
ダウンロードが成功ならば（ステップ２７８）、ＯＴＡクライアントが「ソフトウエア・ダウンロード」状態から「インストール」状態に移る（ステップ２８４）。図５ｇでは、ＯＴＡクライアントがクライアント・コンテキストに「ライセンス要求」メッセージを送り（ステップ２８６）、ＯＴＡサーバがそれを受信する（ステップ２８８）。クライアント・コンテキストの状態が「ソフトウエア・ダウンロード」でないならば（ステップ２９０）、メッセージは無視され手順が停止し（ステップ２９２）、そうでなければクライアント・コンテキスト手順が「ソフトウエア・ダウンロード」状態から「インストール」状態に移り（ステップ２９４）、一方タイマーＴ５００をスタートさせ、基本ソフトウエアを復号化するための鍵を含んだ「ライセンス応答」メッセージをＯＴＡクライアントに送信する（ステップ２９６）。
ＯＴＡクライアントは「ライセンス応答」メッセージを受信し（ステップ２９８）、ＯＴＡクライアントが「インストール」状態にないならば（ステップ３００）、メッセージは無視され手順が停止し（ステップ３０２）、そうでなければＯＴＡクライアントが「復号化鍵」フィールド中に示された鍵を用いることによりダウンロードされたソフトウェアを復号化する（ステップ３０４）。図５ｈでは、復号化が失敗ならば（ステップ３０６）、ＯＴＡクライアントが「ライセンス失敗」メッセージをクライアント・コンテキストに送り（ステップ３０８）、タイマーＴ５００を停止し、「インストール」状態から「アイドル」状態に移る（ステップ３１０）。また、クライアント・コンテキストが「ライセンス失敗」メッセージを受信し（ステップ３１２）、クライアント・コンテキストが「ソフトウエア・ダウンロード」状態にないならば（ステップ３１４）、手順が停止し（ステップ３１６）、そうでなければクライアント・コンテキストが「インストール」状態から「アイドル」状態に移る（ステップ３１８）。
復号化が失敗ならば（ステップ３０６）、ダウンロードされた基本ソフトウエアがクライアント又は端末中に記憶される（ステップ３２０）。
ＯＴＡクライアントが「ライセンス受理」メッセージをクライアント・コンテキストに送り（ステップ３２２）、ＯＴＡサーバがそれを受信し（ステップ３２４）、クライアント・コンテキストの状態が「インストール」でないならば（ステップ３２６）、メッセージは無視され手順が停止し（ステップ３２８）、そうでなければクライアント・コンテキストが「テスト記述」プロトコルメッセージをＯＴＡクライアントに送り（ステップ３３０）、ＯＴＡクライアントがそれを受信する（ステップ３３２）。ＯＴＡクライアントが「インストール」状態にないならば（ステップ３３４）、メッセージは無視され手順が停止し（ステップ３３６）、そうでなければＯＴＡクライアントがタイマーＴ５００を停止させて「インストール」状態から「現場テスト」状態に移り（ステップ３３８）、該状態において受信されたテストが前に記憶された基本ソフトウエア上で実行される（ステップ３４０）。
図５ｉでは、少なくとも１つのテストが失敗ならば（ステップ３４２）、ＯＴＡクライアントは基本ソフトウエアをメモリから消去し（ステップ３４４）、「インストール失敗」メッセージをクライアント・コンテキストに送り（ステップ３４６）、「現場テスト」状態から「アイドル」状態に移る（ステップ３４８）。また、クライアント・コンテキストは「インストール失敗」メッセージを受信し（ステップ３５０）、クライアント・コンテキストの状態が「インストール」でないならば（ステップ３５２）、メッセージは無視され手順が停止し（ステップ３５４）、そうでなければクライアント・コンテキストが「インストール」状態から「アイドル」状態に移る（ステップ３５６）。
基本ソフトウエア上で実行されるすべてのテストが成功ならば（ステップ３４２）、新しい基本ソフトウエアがＯＴＡクライアントにインストールされて開始される（ステップ３５８）。ＯＴＡクライアントは「インストール成功」メッセージをクライアント・コンテキストに送り（ステップ３６０）、「現場テスト」状態から「アイドル」状態に移る（ステップ３６２）。
ＯＴＡサーバは「インストール成功」メッセージを受信し（ステップ３６４）、クライアント・コンテキストの状態が「インストール」でないならば（ステップ３６６）、メッセージは無視され手順が停止し（ステップ３６８）、そうでなければクライアント・コンテキストが「インストール」状態から「アイドル」状態に移り（ステップ３７０）、それにより全体の手順を完了する（ステップ３７２）。
図５ｊでは、ステップ２７６のダウンロード手順をさらに詳細に説明する。基本ソフトウエアは、暗号化アルゴリズム、例えばＡＥＳによって暗号化鍵を用いて暗号化される（ステップ４００）。次に暗号化された基本ソフトウエアは、約１〜２キロバイトの大きさに縮小したブロックに分割される（ステップ４０２）。
ソフトウェアを分割して得た無線ブロックの数に等しい１ビットマスク「ビットマスク・サーバ」と１ビットマスク「ビットマスク・クライアント」が割り当てられ、各ビットマスクには「０」値が設定され、各マスクビットはビット位置に等しい数の無線ブロックに対応しており、すなわち、第１ビットは第１無線ブロックに対応し、第２ビットは第２無線ブロックに対応する等々（ステップ４０４及びステップ４０８）。
ステップ４０６では「ビットマスク・サーバ」が「ビットマスク・クライアント」の内容に従って更新される。特に、「ビットマスク・クライアント」のビットが１に設定されていたならば、「ビットマスク・サーバ」の対応するビットも同様に１に設定される（ステップ４０６）。ダウンロード手順を初めて実行するとき、「ビットマスク・クライアント」及び「ビットマスク・サーバ」の全ビットは０に設定されるのでこのステップは意味がない。
ステップ４１２では、ビットマーク「ビットマスク・サーバ」の全ビットが１に等しいか否かを調べる。肯定の場合には、基本ソフトウエアのダウンロードが終了し、すべてのブロックが成功裡に受信され（ステップ４１０）、そうでなければダウンロードはまだ終了せず、ＯＴＡサーバが「ビットマスク・サーバ」（ｉ）＝０であるすべてのブロックｉをＯＴＡクライアントに送信する（ステップ４１４）。明らかに、初めて手順を実行するとき、基本ソフトウエアを分割して得たＮ個すべてのブロックがクライアントに送られる。
次にＯＴＡクライアントがＮ個のブロックを受信し（ステップ４１６）、各ブロックの受信時にタイマーＴ４００を再スタートさせる。ブロックｉが正しく受信される度に（ステップ４１８）、ビットマスク「ビットマスク・クライアント」（ｉ）の対応するビットが１に設定される。Ｎブロックすべてが送られると、ＯＴＡクライアントは、正しく受信したブロックに対応するビットｉが１に設定されているビットマスク「ビットマスク・クライアント」を含んだメッセージＡｃｋをＯＴＡサーバに送信する。メッセージ「Ａｃｋ」を受信すると、タイマーＴ４０１を再スタートさせる。
次に手順をステップ４０６に戻し、「ビットマスク・サーバ」ビットマスクを更新する。
次に手順をステップ４０６に戻し、「ビットマスク・サーバ」ビットマスクを更新する。
所望の基本ソフトウエアをダウンロードし端末に記憶すると、それを直ぐにインストールし実行する代わりに、ネットワーク又はユーザーから来る要求に応じて逐次インストールし実行させることもできる。無線端末ＵＥ／ＭＳが十分なメモリと処理能力を有するならば、ダウンロードした基本ソフトウエアを、現在動作中の既存のシステムと併存して記憶しインストールできる。このオプションは、端末ＵＥ／ＭＳのマルチモード動作を可能にするのに有効であり、換言すれば、このオプションでは、基本ソフトウエアをダウンロードする必要なく端末が１つのオペレーティングモードから別のオペレーティングモードに切り替わることができる。
以下、図６に関して、ステップ１０４で実行した無線接続の開設について更に詳細に説明する。
端末においては、以下のモジュール：ＯＴＡクライアント・アプリケーション、ＴＣＰ／ＩＰプロトコル、非アクセス層ＮＡＳ（Non Access Stratum）モジュール及びアクセス層ＡＳ（Access Stratum）モジュールを考える。無線アクセスデバイスＧＳＭ／ＧＰＲＳ（ＧＥＲＡＮ）及びＵＭＴＳ（ＵＴＲＡＮ）はそっくりそのまま全体として考える。同じ議論がコアネットワークノードにも当てはまる。ＯＴＡサーバノードはコアネットワークに接続される。端末ＵＥ／ＭＳから来るダウンロード要求の場合の動作の詳細を以下に説明する。
- ＯＴＡクライアントがポートＸに接続をオープンするようプロトコルＴＣＰ／ＩＰに要求する。
- ＴＣＰ／ＩＰは、接続をオープンする前に無線チャンネルを必要とするので対応する要求を端末のプロトコルＮＡＳに送信する。
- 端末のプロトコルＮＡＳは端末のモジュールＡＳに対して無線接続の開設を要求する。
- 端末のプロトコルＡＳが無線アクセスネットワークＧＳＭ／ＧＰＲＳ（ＧＥＲＡＮ）又はＵＭＴＳ（ＵＴＲＡＮ）により無線接続をオープンし、ＮＡＳレベルでの開設を確認する。
- モジュールＮＡＳがＰＤＰコンテキストを起動する。
- ＵＭＴＳシステムの場合、コアネットワークがトランスポート用の無線アクセス・バリアＲＡＢ（Radio Access Bearer）を起動する。
- モジュールＮＡＳがトランスポートチャンネルの開設をＴＣＰ／ＩＰに確認する。
- プロトコルＴＣＰ／ＩＰが接続をオープンし、開設をＯＴＡクライアントに確認する。
端末においては、以下のモジュール：ＯＴＡクライアント・アプリケーション、ＴＣＰ／ＩＰプロトコル、非アクセス層ＮＡＳ（Non Access Stratum）モジュール及びアクセス層ＡＳ（Access Stratum）モジュールを考える。無線アクセスデバイスＧＳＭ／ＧＰＲＳ（ＧＥＲＡＮ）及びＵＭＴＳ（ＵＴＲＡＮ）はそっくりそのまま全体として考える。同じ議論がコアネットワークノードにも当てはまる。ＯＴＡサーバノードはコアネットワークに接続される。端末ＵＥ／ＭＳから来るダウンロード要求の場合の動作の詳細を以下に説明する。
- ＯＴＡクライアントがポートＸに接続をオープンするようプロトコルＴＣＰ／ＩＰに要求する。
- ＴＣＰ／ＩＰは、接続をオープンする前に無線チャンネルを必要とするので対応する要求を端末のプロトコルＮＡＳに送信する。
- 端末のプロトコルＮＡＳは端末のモジュールＡＳに対して無線接続の開設を要求する。
- 端末のプロトコルＡＳが無線アクセスネットワークＧＳＭ／ＧＰＲＳ（ＧＥＲＡＮ）又はＵＭＴＳ（ＵＴＲＡＮ）により無線接続をオープンし、ＮＡＳレベルでの開設を確認する。
- モジュールＮＡＳがＰＤＰコンテキストを起動する。
- ＵＭＴＳシステムの場合、コアネットワークがトランスポート用の無線アクセス・バリアＲＡＢ（Radio Access Bearer）を起動する。
- モジュールＮＡＳがトランスポートチャンネルの開設をＴＣＰ／ＩＰに確認する。
- プロトコルＴＣＰ／ＩＰが接続をオープンし、開設をＯＴＡクライアントに確認する。
一般に、アプリケーション層によりダウンロードされたソフトウェアの管理は、使用される無線システムがマルチキャスト又はブロードキャスト型であるような別の方法によっても実行できる。
特に、この変形は、例えば以下の様にして実装することもできる。
- 端末ＵＥ／ＭＳは、ブロードキャスト／マルチキャスト能力、例えば、３ＧＰＰ規格のリリース６に規定されたＭＢＭＳ（Multimedia Broadcast/Multicast Service）サービスを利用することによってＯＴＡ基本ソフトウエアのダウンロードを管理できるアプリケーションを備える。この場合、ネットワークのブロードキャスト／マルチキャスト能力を用いることにより、基本ソフトウエアを複数の端末にダウンロードすることができる。
- このアプリケーション層は３ＧＰＰ規格に従って認証を実行する。
- アクセスネットワーク及びコアネットワークの観点から、ソフトウェアのダウンロードサービスはトランスペアレントであり、例えば「ソフトウエア・ダウンロード」識別を有する何らかのＭＢＭＳサービスのように考えられる。
- 一定のダウンロード能力を保証するために例えばサービス品質（ＱｏＳ）などのような当該ネットワークの特徴をすべて利用できる。
- このアーキテクチャーは当該アクセスネットワーク（ＧＥＲＡＮ／ＵＴＲＡＮ）から独立している。
- ダウンロードの実行を望んでいるユーザーは、自身をサーバに登録することができる。
- ダウンロードは登録されたすべてのユーザーに向けて同時に行なわれる。
- 端末ＵＥ／ＭＳは、ブロードキャスト／マルチキャスト能力、例えば、３ＧＰＰ規格のリリース６に規定されたＭＢＭＳ（Multimedia Broadcast/Multicast Service）サービスを利用することによってＯＴＡ基本ソフトウエアのダウンロードを管理できるアプリケーションを備える。この場合、ネットワークのブロードキャスト／マルチキャスト能力を用いることにより、基本ソフトウエアを複数の端末にダウンロードすることができる。
- このアプリケーション層は３ＧＰＰ規格に従って認証を実行する。
- アクセスネットワーク及びコアネットワークの観点から、ソフトウェアのダウンロードサービスはトランスペアレントであり、例えば「ソフトウエア・ダウンロード」識別を有する何らかのＭＢＭＳサービスのように考えられる。
- 一定のダウンロード能力を保証するために例えばサービス品質（ＱｏＳ）などのような当該ネットワークの特徴をすべて利用できる。
- このアーキテクチャーは当該アクセスネットワーク（ＧＥＲＡＮ／ＵＴＲＡＮ）から独立している。
- ダウンロードの実行を望んでいるユーザーは、自身をサーバに登録することができる。
- ダウンロードは登録されたすべてのユーザーに向けて同時に行なわれる。
本発明の別の変形は、ユニバーサルチャンネルを用いてソフトウェアＯＴＡをダウンロードすることにある。この場合でも、前記ユニバーサルチャンネルを管理するネットワークアーキテクチャーを押しつけがましく変更することなく、基本ソフトウエアのダウンロードを実行するために本発明を適用できる。別法として、通信ネットワークの無線チャンネルを介してダウンロードが行われる。
第２世代及び第３世代システムについて本発明を詳しく説明してきたが、他の種類のネットワーク、例えば無線ローカルエリアネットワーク（ＷＬＡＮ）、ＤＶＢなどにおいても本発明を実装することができる。実際、本発明により提示された解決策では、使用中のシステムの外部のＯＴＡサーバが与えられ、よって使用中のシステムは変更されない。
また、本発明の好ましい態様によると、非常に多くのシステム又はネットワークにおいて広く使用されている周知のＴＣＰ／ＩＰプロトコルが用いられる。
本発明の別の態様によると、本発明のアーキテクチャーに影響を与えることなく、ＴＣＰ／ＩＰとは異なるトランスポートプロトコル、例えばＵＤＰ（User Datagram Protocol）などを用いることもできる。
Claims (30)
- 所定の通信システムに従って動作可能であると共に少なくとも１つの再設定可能な無線端末（ＵＥ／ＭＳ）を含んだ通信網を含むネットワークシステムであって、前記再設定可能な無線端末（ＵＥ／ＭＳ）は前記通信網に属すると共に前記所定の通信システムを用いることにより前記通信網内での情報の交換を管理するためのモジュールを含み、
- 前記通信網のコアネットワークに接続された少なくとも１つのノード（ＯＴＡサーバ）が、
- 前記再設定可能な無線端末（ＵＥ／ＭＳ）を設定するためのプロトコルスタックの少なくとも１つの要素セットを実装するように構成された基本ソフトウエアモジュールのセット、
を備えること、及び
- 前記再設定可能な無線端末及び前記ノードがそれぞれ無線ソフトウェアモジュールを備え、該無線ソフトウェアモジュールが、前記通信網を介した前記再設定可能な無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）との間の無線ダウンロードの一連処理を管理すると共に前記再設定可能な無線端末（ＵＥ／ＭＳ）を少なくとも部分的に設定するための前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールを前記通信網に対してトランスペアレントにダウンロードするよう構成されること、
を特徴とするネットワークシステム。 - 前記通信網が無線アクセスネットワークと前記コアネットワークからなることを特徴とする請求項１に記載のネットワークシステム。
- 前記無線アクセスネットワークが第二世代（ＧＥＲＡＮ）通信システムに従って動作することを特徴とする請求項２に記載のネットワークシステム。
- 前記無線アクセスネットワークが第三世代（ＵＴＲＡＮ）通信システムに従って動作することを特徴とする請求項２に記載のネットワークシステム。
- 前記コアネットワークがパケットドメインを含むことを特徴とする請求項２に記載のネットワークシステム。
- 前記パケットドメインが少なくとも１つのサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）と少なくとも１つのゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）とを含み、前記ノード（ＯＴＡサーバ）が前記少なくとも１つのゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）に直接接続されることを特徴とする請求項５に記載のネットワークシステム。
- 前記再設定可能な無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）との間の無線接続が前記通信網のユニバーサルチャンネルを介して確立されることを特徴とする請求項１に記載のネットワークシステム。
- 前記再設定可能な無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）との間の無線接続が前記通信網の無線チャンネルを介して確立されることを特徴とする請求項１に記載のネットワークシステム。
- 前記再設定可能な無線端末が少なくとも２つの基本ソフトウエアを記憶できるメモリを備えること、及び前記再設定可能な無線端末が前記少なくとも２つの基本ソフトウエア間で切り換えるためのマルチモード作動モジュールを備えることを特徴とする請求項１に記載のネットワークシステム。
- 前記再設定可能な無線端末がクライアント（ＯＴＡクライアント）として設定され、前記ノード（ＯＴＡサーバ）がサーバとして設定されることを特徴とする請求項１に記載のネットワークシステム。
- 前記情報が少なくとも前記基本ソフトウエアモジュールを含むことを特徴とする請求項１に記載のネットワークシステム。
- - 前記通信網がブロードキャスト／マルチキャスト能力を備え、
- 前記少なくとも１つの再設定可能な無線端末が前記ブロードキャスト／マルチキャスト能力を管理できるアプリケーションを備え、
そのために前記通信網が前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールを前記少なくとも１つの再設定可能な無線端末にマルチキャストダウンロードできるように構成されることを特徴とする請求項１に記載のネットワークシステム。 - 前記少なくとも１つの再設定可能な無線端末と前記ノードとの間で前記無線ダウンロードの一連処理を確立するためにプロトコルＴＣＰ／ＩＰが用いられることを特徴とする請求項１に記載のネットワークシステム。
- 前記基本ソフトウエアモジュールのセットが、別の通信システムを用いて前記無線端末（ＭＳ）を少なくとも部分的に再設定するのに適していることを特徴とする請求項１に記載のネットワークシステム。
- 所定の通信システムに従って動作する通信網に属する少なくとも１つの再設定可能な無線端末（ＵＥ／ＭＳ）を設定するための方法であって、無線端末（ＵＥ／ＭＳ）は前記所定の通信システムを用いることにより前記通信網内で情報を交換でき、
- プロトコルスタックの少なくとも１つの要素セットを用いて前記再設定可能な無線端末（ＵＥ／ＭＳ）を設定するための基本ソフトウエアモジュールのセットを備えた少なくとも１つのノード（ＯＴＡサーバ）を前記通信網のコアネットワークに接続するステップ；
- 前記通信網を介する前記再設定可能な無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）との間の無線（ＯＴＡ）ダウンロードの一連処理を確立するステップ；
- 前記再設定可能な無線端末（ＵＥ／ＭＳ）を少なくとも部分的に設定するための前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールを前記ノード（ＯＴＡサーバ）から前記再設定可能な無線端末（ＵＥ／ＭＳ）に前記通信網に対してトランスペアレントにダウンロードするステップ；
を特徴とする方法。 - 前記無線（ＯＴＡ）ダウンロードの一連処理を確立するステップが、プロトコルステップを表す下記ステップからなる少なくとも１セット、すなわち
- 前記少なくとも１つのモジュールをダウンロードするよう要求するステップ；
- 前記少なくとも１つの再設定可能な無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）とが相互に認証するステップ；
- 前記ノードからダウンロード可能な前記少なくとも１つのモジュールを受理することについて前記再設定可能な無線端末の能力を検査するステップ；
- ダウンロードオプションに関する情報を提供するステップ；
- 前記少なくとも１つのモジュールをブロックに分割するステップ；
- 前記ブロックを前記ノード（ＯＴＡサーバ）から前記少なくとも１つの再設定可能な無線端末（ＵＥ／ＭＳ）に送信するステップ；
- プロトコルスタックの１つの要素セットを用いて前記再設定可能な無線端末（ＵＥ／ＭＳ）を設定すると共に前記要素セットをテストするために前記少なくとも１つのモジュールを再構成すべく前記ブロックを再アセンブルするステップ；
- 前記要素セットを前記再設定可能な無線端末にインストールするステップ；
を実行することによりプロトコルメッセージを交換することを含むことを特徴とする請求項１５に記載の方法。 - 前記プロトコルメッセージを交換するステップが、
- 前記再設定可能な無線端末（ＵＥ／ＭＳ）にダウンロードされた前記ブロックの構造を監視するステップ；
を更に含むことを特徴とする請求項１６に記載の方法。 - 前記プロトコルメッセージを交換するステップが、
- 前記無線（ＯＴＡ）ダウンロードの一連処理の実行が可能な時間を制限するタイマーセット（Ｔ１００、Ｔ２００、Ｔ３００、Ｔ４００、Ｔ５００、Ｔ１０１、Ｔ２０１、Ｔ３０１、Ｔ３０２、Ｔ４０１、Ｔ５０１）を管理するステップ；
を更に含むことを特徴とする請求項１６に記載の方法。 - 前記プロトコルメッセージを交換するステップが、
- 各プロトコルステップに少なくとも１対のタイマーを割り当てるステップであって、前記１対のタイマーのうち第１のタイマーは前記再設定可能な無線端末（ＵＥ／ＭＳ）により実行されたプロトコルステップを監視し、第２のタイマーは前記ノード（ＯＴＡサーバ）により実行されたプロトコルステップを監視し、前記タイマーの各々は１つのプロトコルステップが開始されたときスタートさせ、前記１つのプロトコルステップが実行されたとき停止させる前記ステップ；
を更に含むことを特徴とする請求項１６に記載の方法。 - 前記相互認証ステップが「チャレンジ応答」方式に基づいていることを特徴とする請求項１６に記載の方法。
- 前記少なくとも１つの基本ソフトウエアモジュールをブロックに分割する前記ステップが、１〜２キロバイトの大きさのブロックに分割するステップを含み、前記ブロックを送信する前記ステップが、ウインドウの大きさが少なくとも１つの基本ソフトウエアモジュールを分割して得たブロックの大きさに一致するウインドウプロトコルを管理するステップを含むことを特徴とする請求項１６に記載の方法。
- 前記要素セットを前記再設定可能な無線端末にインストールする前にライセンスを要求することを特徴とする請求項１６に記載の方法。
- 前記少なくとも１つの基本ソフトウエアモジュールを前記再設定可能な無線端末にダウンロードする前に鍵を用いて暗号化することを特徴とする請求項１５に記載の方法。
- 前記少なくとも１つの再設定可能な無線端末（ＵＥ／ＭＳ）と前記ノード（ＯＴＡサーバ）との間の前記無線ダウンロードの一連処理を確立するためにＴＣＰ／ＩＰプロトコルを用いることを特徴とする請求項１５に記載の方法。
- 少なくとも２つの基本ソフトウエアを前記再設定可能な無線端末（ＵＥ／ＭＳ）に記憶する更なるステップを特徴とする請求項１５に記載の方法。
- 前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールをダウンロードする前記ステップが、
- 別の通信システムを用いて前記再設定可能な無線端末（ＭＳ）を少なくとも部分的に再設定するのに適した基本ソフトウエアモジュールのセットをダウンロードするステップ；
を含むことを特徴とする請求項１５に記載の方法。 - 前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールをダウンロードする前記ステップが、
- 前記再設定可能な無線端末（ＵＥ／ＭＳ）又は前記通信網から来る要求に応じて前記基本ソフトウエアモジュールのセットのうち少なくとも１つのモジュールをインストールし実行させるステップ；
を含むことを特徴とする請求項１５に記載の方法。 - 請求項１５〜２７のいずれか一項に記載の方法を実行することにより再設定可能な無線端末（ＵＥ／ＭＳ）。
- 請求項１５〜２７のいずれか一項に記載の方法を実行することにより再設定可能な無線端末（ＵＥ／ＭＳ）を設定するためのネットワークノード（ＯＴＡサーバ）。
- 少なくとも１つのコンピュータのメモリにロードできると共に、請求項１５〜２７のいずれか一項に記載の方法を実行するためのソフトウェアコード部分を含んだコンピュータプログラム又はコンピュータプログラムのコンピュータプログラムセット。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP2004/012168 WO2006045335A1 (en) | 2004-10-28 | 2004-10-28 | A method and a network architecture for configuring a radio terminal, radio terminal, network node and a computer program product therefor |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2008518529A JP2008518529A (ja) | 2008-05-29 |
| JP4668276B2 true JP4668276B2 (ja) | 2011-04-13 |
Family
ID=34959021
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2007538273A Active JP4668276B2 (ja) | 2004-10-28 | 2004-10-28 | 無線端末を設定するための方法及びネットワークアーキテクチャー並びにそのための無線端末、ネットワークノード及びコンピュータプログラムプロダクト |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US8081596B1 (ja) |
| EP (1) | EP1806016B1 (ja) |
| JP (1) | JP4668276B2 (ja) |
| KR (1) | KR101131520B1 (ja) |
| CN (1) | CN101077023B (ja) |
| AT (1) | ATE439747T1 (ja) |
| BR (1) | BRPI0419170A (ja) |
| DE (1) | DE602004022599D1 (ja) |
| ES (1) | ES2331999T3 (ja) |
| WO (1) | WO2006045335A1 (ja) |
Families Citing this family (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| BRPI0419170A (pt) | 2004-10-28 | 2008-03-11 | Telecom Italia Spa | arquitetura de rede, método para configurar pelo menos um terminal de rádio reconfigurável, terminal de rádio configurável, nó de rede e produto de programa de computação |
| US9031550B2 (en) | 2004-10-28 | 2015-05-12 | Telecom Italia S.P.A. | Method for configuring a radio terminal through a radio communication network, related network and computer program product therefor |
| KR101213285B1 (ko) * | 2006-01-04 | 2012-12-17 | 삼성전자주식회사 | 이동통신 시스템에서 아이들모드 단말기의 세션 설정 프로토콜 데이터를 전송하는 방법 및 장치 |
| CN100550766C (zh) * | 2006-01-24 | 2009-10-14 | 华为技术有限公司 | 预定任务执行方法和管理任务执行方法、及其终端设备 |
| US8437751B2 (en) | 2006-04-25 | 2013-05-07 | Core Wireless Licensing S.A.R.L. | Method, apparatus and computer program product for providing confirmed over-the-air terminal configuration |
| DE102006024634B4 (de) * | 2006-05-26 | 2012-08-23 | Audi Ag | Aktivierung der Empfangsbereitschaft eines Fahrzeugnetzwerks |
| JP2008035272A (ja) * | 2006-07-28 | 2008-02-14 | Canon Inc | 情報処理システム及び当該システムにおけるデータ通信方法 |
| US8776037B2 (en) * | 2007-01-04 | 2014-07-08 | International Business Machines Corporation | Apparatus and method to update multiple devices disposed in a computing system |
| KR100840904B1 (ko) * | 2007-06-22 | 2008-06-24 | 주식회사 케이티프리텔 | Ｏｔａ 서비스를 제공하기 위한 시스템 및 그 방법 |
| KR20080112914A (ko) * | 2007-06-22 | 2008-12-26 | 삼성전자주식회사 | 이벤트 메시지 수신 방법, 이벤트 메시지 전송 방법,피제어 장치 및 제어 포인트 |
| US8649783B2 (en) * | 2010-09-22 | 2014-02-11 | Nuance Communications, Inc. | No-cost mobile device messaging, such as for provisioning an application on a mobile device |
| CN102123146A (zh) * | 2011-03-02 | 2011-07-13 | 成都四方信息技术有限公司 | 移动支付交易密钥远程下载工作方法 |
| JP5632315B2 (ja) * | 2011-03-17 | 2014-11-26 | 株式会社オプティム | 端末のリモート操作システム、リモート操作方法 |
| CN102307362B (zh) * | 2011-09-06 | 2015-06-17 | 北京傲天动联技术股份有限公司 | 用于实现功能配置的终端设备和控制设备及其网络系统 |
| JP6001843B2 (ja) * | 2011-11-15 | 2016-10-05 | 任天堂株式会社 | 情報処理装置、情報処理システム、情報処理方法およびプログラム |
| US8873466B2 (en) | 2012-10-12 | 2014-10-28 | Freescale Semiconductor, Inc. | Timing event generation circuit for mobile communication device |
| WO2016195640A1 (en) * | 2015-05-29 | 2016-12-08 | Nokia Technologies Oy | Support of flexible radio protocol in 5g radio access network |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000513901A (ja) * | 1997-01-02 | 2000-10-17 | ノキア モービル フォーンズ リミテッド | 移動体通信 |
| JP2001186074A (ja) * | 1999-12-24 | 2001-07-06 | Toshiba Corp | 移動通信システムとその管理装置及び移動局装置 |
| JP2003110606A (ja) * | 2001-09-26 | 2003-04-11 | Toshiba Corp | 無線基地局、無線端末及び通信制御方法 |
| JP2003304235A (ja) * | 2002-04-10 | 2003-10-24 | Sony Corp | 無線通信装置、およびプログラム・ダウンロード方法、並びにコンピュータ・プログラム |
Family Cites Families (25)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6208627B1 (en) | 1997-12-10 | 2001-03-27 | Xircom, Inc. | Signaling and protocol for communication system with wireless trunk |
| US6463055B1 (en) | 1998-06-01 | 2002-10-08 | Telefonaktiebolaget L M Ericsson (Publ) | Integrated radio telecommunications network and method of interworking an ANSI-41 network and the general packet radio service (GPRS) |
| US6577614B1 (en) | 1999-05-27 | 2003-06-10 | Qwest Communications International Inc. | System and method for OTA over CDMA data channel |
| JP3669619B2 (ja) * | 1999-09-06 | 2005-07-13 | 富士通株式会社 | 無線端末装置のソフトウェア更新方法及びその装置 |
| FI109320B (fi) | 1999-11-02 | 2002-06-28 | Nokia Corp | Signalointimenetelmä |
| US20020012329A1 (en) | 2000-06-02 | 2002-01-31 | Timothy Atkinson | Communications apparatus interface and method for discovery of remote devices |
| US7035932B1 (en) | 2000-10-27 | 2006-04-25 | Eric Morgan Dowling | Federated multiprotocol communication |
| GB0028463D0 (en) | 2000-11-22 | 2001-01-10 | Univ Surrey | Reconfiguration management architectures |
| US6799203B2 (en) | 2000-12-29 | 2004-09-28 | Nokia Mobile Phones Ltd. | WTA based over the air management (OTAM) method and apparatus |
| GB0101205D0 (en) * | 2001-01-17 | 2001-02-28 | Koninkl Philips Electronics Nv | Telecommunications system and a method of operating the system |
| GB0103903D0 (en) * | 2001-02-16 | 2001-04-04 | Radioscape Ltd | An open digital interface between sdr baseband processors and rf |
| EP1257141B1 (en) * | 2001-05-10 | 2007-01-03 | Nortel Networks Limited | System and method for communication redirection between mobile telecommunication networks with different radio access technologies |
| US7215648B2 (en) | 2001-05-11 | 2007-05-08 | Varitek Industries, Inc. | Apparatus and method for efficient live webcasting and network connectivity |
| US20030084165A1 (en) * | 2001-10-12 | 2003-05-01 | Openwave Systems Inc. | User-centric session management for client-server interaction using multiple applications and devices |
| WO2003039175A1 (de) * | 2001-10-16 | 2003-05-08 | Siemens Aktiengesellschaft | Rekonfigurationsverfahren für mobile kommunikationsgeräte |
| US7054628B2 (en) * | 2001-12-07 | 2006-05-30 | Qualcomm Incorporated | Apparatus and method of using a ciphering key in a hybrid communications network |
| US7743115B2 (en) | 2002-02-27 | 2010-06-22 | Motorola, Inc. | Software content downloading methods in radio communication networks |
| US20040098715A1 (en) | 2002-08-30 | 2004-05-20 | Parixit Aghera | Over the air mobile device software management |
| EP1401224A1 (en) * | 2002-09-17 | 2004-03-24 | Motorola, Inc. | Software download to software definable radio by intermediate communication unit |
| US20040120281A1 (en) * | 2002-12-24 | 2004-06-24 | Gazzard Daryl R. | Remote node access in wireless telecommunication systems |
| CN1275480C (zh) * | 2003-07-31 | 2006-09-13 | 上海贝尔阿尔卡特股份有限公司 | 一种多标准软件无线电(sdr)基带处理方法 |
| US20050033829A1 (en) | 2003-08-04 | 2005-02-10 | Nokia Corporation | System and method for wireless multicast downloading |
| US8201191B2 (en) * | 2004-06-30 | 2012-06-12 | Time Warner Cable Inc. | Apparatus and methods for implementation of network software interfaces |
| US9031550B2 (en) | 2004-10-28 | 2015-05-12 | Telecom Italia S.P.A. | Method for configuring a radio terminal through a radio communication network, related network and computer program product therefor |
| BRPI0419170A (pt) | 2004-10-28 | 2008-03-11 | Telecom Italia Spa | arquitetura de rede, método para configurar pelo menos um terminal de rádio reconfigurável, terminal de rádio configurável, nó de rede e produto de programa de computação |
-
2004
- 2004-10-28 BR BRPI0419170-6A patent/BRPI0419170A/pt not_active Application Discontinuation
- 2004-10-28 US US11/666,439 patent/US8081596B1/en active Active
- 2004-10-28 JP JP2007538273A patent/JP4668276B2/ja active Active
- 2004-10-28 CN CN2004800445796A patent/CN101077023B/zh active Active
- 2004-10-28 EP EP04790941A patent/EP1806016B1/en active Active
- 2004-10-28 ES ES04790941T patent/ES2331999T3/es active Active
- 2004-10-28 WO PCT/EP2004/012168 patent/WO2006045335A1/en active Application Filing
- 2004-10-28 DE DE602004022599T patent/DE602004022599D1/de active Active
- 2004-10-28 AT AT04790941T patent/ATE439747T1/de not_active IP Right Cessation
- 2004-10-28 KR KR1020077011989A patent/KR101131520B1/ko active IP Right Grant
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2000513901A (ja) * | 1997-01-02 | 2000-10-17 | ノキア モービル フォーンズ リミテッド | 移動体通信 |
| JP2001186074A (ja) * | 1999-12-24 | 2001-07-06 | Toshiba Corp | 移動通信システムとその管理装置及び移動局装置 |
| JP2003110606A (ja) * | 2001-09-26 | 2003-04-11 | Toshiba Corp | 無線基地局、無線端末及び通信制御方法 |
| JP2003304235A (ja) * | 2002-04-10 | 2003-10-24 | Sony Corp | 無線通信装置、およびプログラム・ダウンロード方法、並びにコンピュータ・プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2006045335A1 (en) | 2006-05-04 |
| ATE439747T1 (de) | 2009-08-15 |
| KR101131520B1 (ko) | 2012-04-04 |
| US8081596B1 (en) | 2011-12-20 |
| DE602004022599D1 (de) | 2009-09-24 |
| EP1806016B1 (en) | 2009-08-12 |
| BRPI0419170A (pt) | 2008-03-11 |
| KR20070074643A (ko) | 2007-07-12 |
| CN101077023B (zh) | 2012-01-11 |
| EP1806016A1 (en) | 2007-07-11 |
| JP2008518529A (ja) | 2008-05-29 |
| CN101077023A (zh) | 2007-11-21 |
| ES2331999T3 (es) | 2010-01-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9031550B2 (en) | Method for configuring a radio terminal through a radio communication network, related network and computer program product therefor | |
| US11743061B2 (en) | Ethernet type packet data unit session communications | |
| US20220272620A1 (en) | Apparatus, system and method for enhancements to network slicing and the policy framework of a 5g network | |
| JP4668276B2 (ja) | 無線端末を設定するための方法及びネットワークアーキテクチャー並びにそのための無線端末、ネットワークノード及びコンピュータプログラムプロダクト | |
| CN111213397B (zh) | 用户设备(ue)处的策略供应 | |
| KR101049664B1 (ko) | 모바이크 프로토콜을 이용하여 이종무선망 간의 이동성 및 보안을 지원하는 클라이언트 장치 | |
| CN110710236B (zh) | 通信装置、服务器及通过无线电话和ip网络操作的方法 | |
| TWI396455B (zh) | 處理交遞程序的方法及其通訊裝置 | |
| CN108366369B (zh) | 一种数据安全传输的方法及接入网、终端、核心网设备 | |
| EP2385729A2 (en) | Control of electronic features in a network | |
| US11882105B2 (en) | Authentication system when authentication is not functioning | |
| KR101504389B1 (ko) | 모바이크 프로토콜을 이용하여 이종무선망 간의 이동성 및 보안을 지원하는 클라이언트 장치 | |
| JP5420604B2 (ja) | 無線通信ネットワークと関連ネットワークおよびそのコンピュータ・プログラム生成物を介して無線端末を設定する方法 | |
| WO2023277743A1 (en) | Bootstrapping a wireless communication device | |
| CN117062070A (zh) | 一种通信方法及通信装置 | |
| CN116634426A (zh) | 一种通信的方法及装置 | |
| WO2018111788A1 (en) | Providing concurrent connections to a subscriber using a mobile device having multiple transceivers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20090728 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20091217 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100318 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100617 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100625 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20100727 |
|
| RD04 | Notification of resignation of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7424 Effective date: 20100825 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100921 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20101214 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110112 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140121 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 4668276 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |