公开/公告号CN101077024A
专利类型发明专利
公开/公告日2007-11-21
原文格式PDF
申请/专利权人 意大利电信股份公司;
申请/专利号CN200480044582.8
申请日2004-10-28
分类号
代理机构中国国际贸易促进委员会专利商标事务所;
代理人董莘
地址 意大利米兰
入库时间 2023-12-17 19:24:25
法律状态公告日
法律状态信息
法律状态
2011-08-10
授权
授权
2008-01-16
实质审查的生效
实质审查的生效
2007-11-21
公开
公开
技术领域
本发明一般涉及无线电通信网络和利用无线电通信网络可重新配置的无线电终端。
本发明尤其涉及一种可重新配置的无线电终端的配置，所述配置是通过在所述无线电终端中安装从无线电通信网络通过空中(over theair：OTA)下载的操作系统完成的。
背景技术
根据文献(J.Mitola“The Software Radio Architecture”IEEE通信期刊，1995年5月和E.Buracchini，“The Software RadioConcept”IEEE通信期刊，2000年9月)，已知类似终端、基站和网络节点的可重新配置的系统配备有其运行工作方式可以重新配置。例如，能够与如GSM/GPRS(全球移动通信系统/通用分组无线电业务)的第二代系统(2G)一同工作的可重新配置的无线电终端可以被重新配置以便变得能够与第三代系统，如UMTS(通用移动电信系统)或CDMA 2000(码分多址2000)，与DVB-T(地面数字视频广播)或者与WLAN(无线局域网)系统等等，一同工作。
根据本公开，“系统”意思是多个元素根据预先确定的准则在它们之间协同工作，即根据一个“标准”协同工作，以便执行例如始于通信网络的特定功能。
在本文档中，系统的实例是GSM系统、GPRS系统、UMTS系统、WLAN系统等等，它们中的每一个遵从相应的标准。
为了实现终端的重新配置，根据上述提及的文献，必须以可重新配置的技术实现终端的操作功能。考虑到这一点，可重新配置的终端或装置被配备以例如由多个FPGA(现场可编程门阵列)、DSP(数字信号处理器)和微处理器构成的可重新编程的硬件：该装置的信号功能性甚至在最低电平的时候也可通过软件代码来执行。结果，为了重新配置可重新编程的装置，应有能力替换管理装置自身的硬件的操作软件。
在本说明书中，术语“操作软件”意思是以库组织的软件，其既定义了所考虑的类似例如GSM/GPRS、UMTS等系统的协议栈的无线电接口(例如，L1、L2、L3)又定义了较上层(例如，L4一直到L7)。
如公知的，在通信领域中，使用最多的用于获得功能分组的方法是OSI(开发系统互连)模型。各功能性以协议栈的形式下表示的功能面来分组。
每一层为其直接的更上层提供服务，所述服务反之是由直接的较下层提供的服务的改进。
最下层(层1)通常用于物理传输信息。
根据OSI规范，标准的层数为7：分别为物理层、连接层、网络层、传输层、会话层、表示层和应用层。
每个系统，例如GSM/GPRS、UMTS等等，实现了OSI协议栈的必要的部分。
当考虑无线电终端时，当利用可重新配置的硬件时提供诸多的好处，但一个好处是直接显而易见的：无线电终端可以根据覆盖该终端所处区域(工作区域)的系统来重新配置。因此，如果终端在由第二代系统(如GSM/GPRS)覆盖的区域内使用，则可以重新配置终端以便能够接收所述系统；同样，在由第三代系统(如UMTS)覆盖的区域内，也可相应地配置终端。
根据文献(AA.VV.“Software Radio：The Challenges forReconfigurable Terminals”，通信年鉴-Jul/Aug 2002，GET Hermes和E.Buracchini的“The Software Redio Concept”)已知的是，软件代码可至少以三种不同的方式转移或下载到终端：
-通过将SIM(用户标识模块)插入到无线电移动终端经由智能卡；
-通过利用例如经由红外/串口/USB端口与个人计算机的链接经由外部连接；
-通过利用特定的无线电信道经由无线电或者通过空中(OTA)。
考虑软件下载，在软件定义的无线电论坛(SDR论坛)的框架内已经定义了允许管理下载软件到终端的一般协议的基本步骤，如通过URL：www.sdrforum.org可获得的。
如由SDR论坛定义的该协议是本身为已知的客户机-服务器类型的协议。
下载协议步骤如下：
-下载启动：在此步骤期间终端与将要下载的软件驻留于其上的服务器通信，该启动开始一个软件下载；
-相互验证：终端和服务器必须相互验证对方；
-能力交换：服务器传送有关将要下载的软件的能力信息，且终端核实软件是否能够被载入到终端存储器中、是否能够在其内安装并运行；
-下载接受：服务器通知终端下载、安装和记帐选项；终端决定服务器所提供的指示是否是可接受的；
-下载和完整性测试：在软件下载期间，所接收的代码必须被测试；终端请求重传接收不正确的无线电数据块；
-安装：在安装步骤期间，由服务器提供软件记帐和授予许可证条件；
-原地测试：在启动软件之前，终端在与软件代码一同下载的测试向量的帮助下执行一些测试；
-非否认交换：一旦软件代码已经被安装并且被测试，终端向服务器证实安装已经成功以便启动例如记帐程序。
根据现有技术，例如E.Buracchini，“The Software RadioConcept”，IEEE通信期刊，2000年9月，已知经由无线电或OTA的软件下载预见终端对无线电信道的使用。此外已知的是，根据上述提及的文献，依赖于无线电信道的拓扑，软件代码的下载可以以两种不同的方式完成：
-“带外”方式：借助于独立于当前系统的“通用”信道，当终端被接通时，其自动调谐到所述信道并执行有关运行在该工作区域内的系统的操作软件的下载；
-“带内”方式：通过分别利用如GSM/GPRS和UMTS的第二和第三代标准蜂窝系统的无线电信道，这种方式假定已经在这些信道的其中之一上运行的终端能够接收有关不同于当前使用的系统的操作软件；例如，通过利用终端根据其工作的第二代无线电信道，一个与如GSM/GPRS的第二代系统一同工作的可重新配置的终端能够执行如UMTS的第三代系统的下载。
“带外”软件下载的一个实例是例如在日本专利申请No.2001061186中描述的例子。该文档描述了一种用于通过空中下载软件内容的系统和方法。当无线电终端接通时，其在通用信道上搜寻工作区域中当前是什么系统并且执行相对所指示的系统的软件下载。
考虑“带外”模式，根据现有技术，需要实现专用的无线电信道以及由此网络中用于其的实现的专用设备。
“带内”软件下载的一个实例是例如在US专利申请No.2003/0163551中描述的例子。该文档描述了一种用于通过空中下载软件的系统和方法，其通过利用服务器和终端之间的协商步骤(能力交换、验证、记帐等等)期间的专用信道，以及利用下载过程期间的共享公共信道以便为尽可能多的用户同时提供下载服务而不对可用的无线电资源施以阻碍。
当考虑“带内”下载方式时，文献AA.VV.“Architecture of IPBased Network Elements Supporting Reconfigurable Terminals”，SCOUT专题研究组2003年9月16日以及IST-2001-34091 SCOUT，D4.1.1“Requirements on network and security architecture andtraffic management schemes for download traffic based on IPprinciples in cellular and ad hoc networks”建议大幅修改某些协议和某些网络节点，例如基于UMTS的版本5及后续版本的无线电接入节点和/或核心网络节点，其中该核心网络完全基于IP(网际协议)，以便有可能管理操作软件的下载。
这种修改隐含设备制造商和网络运营商的巨大努力并且对现有蜂窝系统的标准带来显著的冲击。
因此已知的“带内”技术显示出以下局限：当期望其向已经存在的蜂窝网络(例如GSM/GPRS或UMTS)增加用于可重新配置的终端的操作软件下载管理时，需要对协议和网络节点作重大的修改。
申请人注意到已知的现有技术在“带内”和“带外”方式的情况下都准备大幅修改某些协议和某些网络节点。
已知的现有技术的此外的问题是系统间切换的管理，根据当前标准，系统间切换定义为：
-从GSM/GPRS系统切换到UMTS系统；
-从UMTS系统切换到CDMA 2000系统；
-从UMTS系统切换到GSM/GPRS系统；
-从CDMA 2000系统切换到UMTS系统。
根据已知标准，系统间切换需要多模终端，即，通过利用ASIC(专用集成电路)终端支持每个蜂窝系统的全部协议栈。
参见例如图1，图1示出了一个多模终端，其包括称为RATGSM/GPRS的GSM/GPRS系统的全部无线电协议栈、称为RATUMTS的UMTS系统的全部无线电协议栈、以及称为RAT CDMA2000的CDMA 2000系统的全部无线电协议栈。
由于高功耗、大设备尺寸和高实现成本，已知的解决方案有一些缺点。
总之，申请人注意到已知的现有技术：
-不能在不极大地修改网络节点而解决下载软件的问题，例如增加新的节点和接口，以及修改根据标准定义的数据信令和传送协议，其可能隐含低效率的无线电资源的使用；以及
-不能使用可重新配置的终端用于管理系统间切换。
发明内容
因此，本发明的一个目的是一种无需网络节点和相关协议的极大修改而用于下载用于配置无线电终端的操作软件的方法和通信网络。
此外，本发明的还一个目的是用于通过利用可配置的终端实现系统间切换过程的方法和通信网络。
本发明发明的上述目的是通过如在此所附的权利要求书中要求的一种方法、通信网络实现的。
此外，本发明的各目的是通过计算机程序产品或计算机程序产品组实现的，该计算机程序产品或计算机程序产品组可载入至少一台计算机的存储器并包括当该产品在如要求的计算机上运行时用于执行本发明的方法的各步骤的软件代码部分。如在此使用的，参考这种计算机程序产品意欲等同于参考包含用于控制计算机系统以协调本发明的方法的执行的指令的计算机可读介质。参考“至少一台计算机”显然意欲突出本发明以分布式模块化方式实现的可能性。
在一个优选实施例中，用于重新配置无线电终端的操作软件的下载是通过提供单独修改相对于该标准的终端中的无线电协议栈的一个层和网络的至少一个节点实现的，该至少一个节点例如为类似网络的BSC(基站控制器)的无线电控制器或者RNC(无线电网络控制器)。
根据本发明，该提议的协议与SDR论坛提供的推荐标准一致。
根据本发明的优选实施例，可能从其下载操作软件的服务器驻留在网络的无线电控制器内，例如BSC或RNC。
在本发明的可能的优点之中：
-软件下载服务是透明的并且可由任何其它信令和业务数据流由网络查看到；
-充分利用了现有和未来标准的所有特征，由此允许无线电资源的有效和灵活使用；
-可能在例如电路呼叫期间建立分组连接以便下载操作软件而不中断该呼叫；
-有可能区分不同的数据流并管理它们(例如，语音、数据和软件下载)的优先级；例如，如果语音呼叫的优先级高于软件下载的优先级，则有可能临时中断软件自身的下载以接着继续所述下载。
此外，本发明提供终端的使用用于管理系统间切换。
事实上，根据本发明的优选实施例，在终端的物理层实现用于完成所支持的系统之上的测量的仅仅最少的功能性就已足够。
例如，让我们考虑配置用于与GSM/GPRS系统一同工作并准备好管理到UMTS系统的系统间切换的终端：根据本发明，配置以GSM/GPRS系统的无线电接口的全部协议栈，该终端被仅配备以最少的物理层功能性以便执行UMTS系统上的功率测量。
该系统间切换的管理是通过经由GSM/GPRS无线电信道下载全部的UMTS操作软件到终端中，通过根据UMTS系统重新配置该终端，以及通过最少的物理层功能性以便执行GSM/GPRS系统之上的功率测量。
附图说明
现在将参考本发明的优选但非限制性实施例的附图在下文中公开本发明，其中：
图1表示根据现有技术的多模终端；
图2为根据本发明的一个实施例举例说明GSM/GPRS系统的网络体系结构；
图3表示针对图1的体系结构的可重新配置的终端；
图4为由无线电终端一侧的客户机执行的协议步骤的状态图；
图5为由基站控制器一侧的服务器执行的协议步骤的状态图；
图6-17举例说明了在服务器和客户机之间交换的协议消息的结构；
图18举例说明了针对电路呼叫的从GSM到UMTS的系统间切换过程；
图19详细示意了用于重新配置无线电终端的软件下载过程；
图20举例说明了小区重选择情况下的操作软件下载过程。
贯穿所有的附图，同样的附图标记用于指示相等的或者实现基本上同等功能的组件。
具体实施方式
参考图2，已知GSM/GPRS系统的网络体系结构包括可重新配置的终端或移动台MS，基站收发信台BTS或BTS节点以及基站控制器BSC或BSC节点。
该网络进一步包括没有在图2中明显示出的例如诸如移动交换中心(MSC)和/或服务GPRS支持节点(SGSN)和/或网关GPRS支持节点(GGSN)。
终端MS通过无线电接口连接BTS节点，BTS节点连接到BSC节点。
根据本发明的优选实施例，终端包括称为OTA-客户机的第一实体和称为无线电资源协议RR的已知类型的第二实体；OTA-客户机与无线电资源协议RR位于同一协议级别或层并与之协作。
RR实体例如根据GSM/GPRS标准ETSI 04.18工作并且包括如在随后将公开的用于与基站控制器BSC中的OTA-客户机和RR相应实体通信的功能。
OTA-客户机包括能够完全管理从称为OTA服务器的基站控制器BSC中的OTA相应实体的完整或部分的操作软件的下载过程的软件模块。
BSC包括称为OTA-服务器的第一实体和称为无线电资源协议RR的已知类型的第二实体。
OTA-服务器与无线电资源协议RR位于同一协议级别并与之协作。
RR实体例如根据GSM/GPRS标准ETSI 04.18工作并且包括如在随后将公开的用于与移动终端MS中的OTA-服务器和RR相应实体通信的功能。
OTA-服务器包括能够完全管理下载完整或部分的操作软件到OTA-客户机的下载过程的软件模块。
OTA-服务器还包括操作软件或能够恢复操作软件。
如随后将公开的，OTA-服务器的体系结构为每个具有活动下载会话的OTA-客户机提供一个上下文，称为客户机上下文。
图3示出了根据本发明配置的终端MS的实例。
终端MS包括GSM/GPRS协议的较上层和较下层。
较下层称为RAT(无线电接入技术)GSM/GPRS并包括依照GSM/GPRS标准的OTA客户机、无线电资源RR以及物理层(L1)和DL(数据链路层)(L2)实体。
终端MS还包括依照另外的标准，例如UMTS标准的物理层(L1U)，包括至少用于执行与另外的标准相适应的层1测量。
如随后将公开的，可如公开的通过下载另外的标准的操作软件能够重新配置终端MS。
如在本发明的优选实施例中所考虑的，操作软件包括一组操作软件模块，优选根据预定的通信系统用于配置终端MS的多个软件模块。
本发明提供下载构成所使用的协议栈的所有操作软件模块以便依照例如进一步的预定的通信系统配置无线电终端MS。
如熟练技术人员能够理解的，根据本发明进一步的实施例，还可能下载单独构成对应于使用中或另外的通信系统的协议栈的一部分的软件模块。
这种进一步的实施例对于例如插入新功能到终端MS、更新或修理终端MS中的程序错误的目标是有用的。
参考图4，图4表示终端MS内的OTA-客户机的状态图。
用于命名各状态的术语是纯粹指示性的，就如同所述的相应行为那样有意义。
根据本发明的优选实施例，OTA-客户机的各状态和有关过渡如下：
-IDLE状态：当没有任何软件下载过程是活动的时候OTA-客户机或客户机处于这个状态；如果过程正确结束或者如果发生故障时OTA-客户机返回到这个状态；
-DOWNLOAD INITIATION状态：当网络需要启动一个操作软件下载过程时，OTA-客户机进入这个状态并且启动定时器T100；定时器T100在状态过渡的情况下停止；如果定时器T100在状态过渡之前到期，则OTA-客户机返回到IDLE状态；
-MUTUAL AUTHENTICATION状态：在这个状态中，OTA-客户机执行与OTA-服务器的相互验证；当从服务器到来一个验证请求时OTA-客户机进入这个状态；OTA-客户机启动定时器T200；定时器T200在状态过渡的情况下停止；如果在状态过渡之前定时器T200到期或者验证失败，则OTA-客户机返回到IDLE状态；
-CAPABILITY REQUEST状态：在这个状态中，OTA-客户机将其的能力提供给OTA-服务器；当OTA-服务器请求OTA-客户机的能力时OTA-客户机进入这个状态；OTA-客户机启动定时器T300；定时器T300在状态过渡的情况下停止；如果在状态过渡之前定时器T300到期，则OTA-客户机返回到IDLE状态；
-DOWNLOAD ACCEPTANCE状态：在这个状态中，OTA-客户机根据由OTA-服务器接收到的信息确定是否继续下载；当其从OTA-服务器接收到将被执行的下载简表时OTA-客户机进入这个状态；如果所接收的简表被拒绝，则OTA-客户机返回到IDLE状态；
-SOFTWARE DOWNLOAD状态：在这个状态中，OTA-客户机执行软件下载；如果下载简表被接受则OTA-客户机进入这个状态；OTA-客户机启动定时器T400；定时器T400在从OTA-服务器接收每一个软件块时被重置并重启动；定时器T400在状态过渡的情况下停止；如果在状态过渡之前定时器T400到期或者下载失败或者所下载的软件与能力不符，则OTA-客户机返回到IDLE状态；
-INSTALLATION状态：在这个状态下，OTA-客户机向OTA-服务器发送一个许可证请求并安装操作软件；OTA-客户机在下载结束时进入这个状态；OTA-客户机启动定时器T500；定时器T500在状态改变的情况下停止；如果在状态改变之前定时器T500到期或者许可证未被接受，则OTA-客户机返回到IDLE状态；
-IN-SITU TESTING状态：在这个状态下，OTA-客户机通过利用从OTA-服务器接收的一些测试向量针对下载的软件执行一些测试；当已经安装了操作软件时OTA-客户机进入这个状态；一旦测试结束，则OTA-客户机返回到IDLE状态。
参考图5，图5表示由OTA-服务器管理的客户机上下文的状态图。
如上述论及的，用于命名各状态的术语是纯指示性的，就如同所述的相应行为那样有意义。
客户机上下文的状态和有关过渡如下：
-IDLE状态：当没有任何软件下载过程是活动的时候由OTA-服务器管理的OTA-客户机上下文处于这个状态；如果过程正确结束或者如果发生故障时OTA-客户机上下文返回到这个状态；
-DOWNLOAD INITIATION状态：在这个状态下OTA-客户机上下文触发OTA-客户机执行下载；当需要执行操作软件的下载时，OTA-客户机上下文进入这个状态并且启动定时器T101；定时器T101在状态过渡之前停止；如果定时器T101在状态过渡之前到期，则OTA-客户机上下文返回到IDLE状态；
-MUTUAL AUTHENTICATION状态：在这个状态中，OTA-客户机上下文验证其自身并要求OTA-客户机识别自己；当其从OTA-客户机接收到下载确认时OTA-客户机上下文进入这个状态；OTA-客户机上下文启动定时器T201；定时器T201在状态过渡的情况下停止；如果在状态过渡之前定时器T201到期或者验证失败，则OTA-客户机上下文返回到IDLE状态；
-CAPABILITY REQUEST状态：在这个状态中，OTA-客户机上下文请求OTA-客户机的能力；当验证完成时OTA-客户机上下文进入这个状态；OTA-客户机上下文启动定时器T301；定时器T301在状态过渡的情况下停止；如果在状态过渡之前定时器T301到期或者该能力不允许下载，则OTA-客户机上下文返回到IDLE状态；
-DOWNLOAD ACCEPTANCE状态：在这个状态中，OTA-客户机上下文将下载简表传送给OTA-客户机；当其接收到终端能力并且所述能力被接受时OTA-客户机上下文进入这个状态；OTA-客户机上下文启动定时器T302；定时器T302在状态过渡的情况下停止；如果在状态过渡之前定时器T302到期或者OTA-客户机拒绝了所提议的下载，则OTA-客户机上下文返回到IDLE状态；
-SOFTWARE DOWNLOAD状态：在这个状态中，OTA-客户机上下文执行朝向OTA-客户机方向上的下载；如果OTA-客户机接受了下载简表则OTA-客户机上下文进入这个状态；OTA-客户机上下文启动定时器T401；定时器T401在从客户机接收到每一个确认信号Ack时被重置并重新启动；定时器T401在状态过渡的情况下停止；如果在状态过渡之前T401到期或者下载失败，则OTA-客户机上下文返回到IDLE状态；
-INSTALLATION状态：在这个状态中，OTA-客户机上下文向OTA-客户机发送许可证条款并且等待一直到OTA-客户机执行了安装和所下载软件的测试；当下载已结束时OTA-客户机上下文进入这个状态；OTA-客户机上下文启动定时器T501；定时器T501在状态过渡的情况下停止；如果在状态过渡之前定时器T501到期或者该许可证未被OTA-客户机接受，则OTA-客户机上下文返回到IDLE状态；如果OTA-客户机上下文接收到有关OTA-客户机成功安装的确认信号，则其返回到IDLE状态。
在GSM/GPRS的情况下，在本发明的优选实施例中，现在将参考图6-17详细描述通过引OTA-服务器和OTA-客户机之间交换的新的协议消息和有关字段修改RR协议。
在不同的系统的情况下，以如能够被熟练技术人员所理解的类似的方式修改无线电资源协议，例如UMTS系统中的RRC(无线电资源控制)。
下文中，用于命名各消息和相关字段的术语是纯指示性的，就如同所述的相应定义那样有意义。
参考图6，图6描述了Packet Download Request消息的结构。该消息是从基站控制器BSC一侧的无线电资源RR客户机发往终端MS一侧的无线电资源RR的。OTA-服务器利用这个消息指示OTA-客户机开始一个下载会话。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet DownloadRequest)；
-OTA-Client_ID：标识OTA-客户机，该请求向该OTA-客户机提出；
-PDCH(Packet Data Channel)：指定由在其上将执行软件下载的网络分配的信道；
-RRBP(Relative Reserved Block Period )：如已经在GPRS标准中定义的，指定在其上终端MS一侧的无线电资源RR应该应答的无线电数据块；
-Requested Download：这个元素包含由网络请求的下载的一个描述字符串和数字标识符。
参考图7，图7描述了Packet Download Ack消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机利用这个消息通知OTA-服务器同意开始一个下载会话。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet Download Ack)；
-OTA-Client_ID：标识发送该消息的OTA-客户机；
-OTA-Client_Challenge_Number：OTA-服务器将利用其自身的密钥和适当的密码算法，例如AES(高级加密标准)，加密的一个随机数，以便执行相互验证的第一步。
参考图8，图8描述了Packet Download Nack消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机利用这个消息通知服务器其不能开始一个下载会话。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet Download Nack)；
-OTA-Client_ID：标识发送该消息的OTA-客户机。
参考图9，图9描述了Packet Authentication Request消息的结构。该消息是从OTA-服务器发往OTA-客户机的。OTA-服务器利用这个消息将其的凭证传送给OTA-客户机并要求OTA-客户机识别自己。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet AuthenticationRequest)；
-OTA-Client_ID：标识该消息所发往的OTA-客户机；
-OTA-Server_Response_Number：由OTA-服务器利用其自身的密钥和适当的密码算法(例如AES算法)加密的一个数字，结束相互验证的第一步；
-OTA-Server_Challenge_Number：OTA-客户机将利用其自身的密钥和适当的密码算法(例如AES算法)加密的一个随机数，以便执行相互验证的第二步；
-RRBP：如已经在GPRS标准中定义的，指定在其上终端MS一侧的无线电资源RR应该应答的无线电数据块。
参考图10，图10描述了Packet Authentication Response消息的结构。该消息是从OTA-客户机发往OTA-服务器的。在已经验证了OTA-服务器之后，OTA-客户机利用这个消息将其的凭证传送给OTA-服务器。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet AuthenticationResponse)；
-OTA-Client_ID：标识发送该消息的OTA-客户机；
-OTA-Client_Response_Number：标识OTA-客户机利用其自身的密钥和适当的密码算法(例如AES算法)加密的一个数字，结束相互验证的第二步和最后一步。
参考图11，图11描述了Packet Capability Request消息的结构。该消息是从OTA-服务器发往OTA-客户机的。OTA-服务器利用这个消息请求OTA-客户机其的可重新配置性选项。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet CapabilityRequest)；
-OTA-Client_ID：标识消息被发往的OTA-客户机；
-RRBP：如已经在GPRS标准中定义的，指定在其上终端MS一侧的无线电资源RR应该应答的无线电数据块。
参考图12，图12描述了Packet Capability Response消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机利用这个消息将有关其的可重新配置性选项告知OTA-服务器。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet CapabilityResponse)；
-OTA-Client_ID：标识发送该消息的OTA-客户机；
-OTA-Client_Capability：描述终端的可重新配置性选项。参考图13，图13描述了Packet Download Description消息的结构。该消息是从OTA-服务器发往OTA-客户机的。OTA-服务器利用这个消息向OTA-客户机报告有关于下载的数据。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet DownloadDescription)；
-OTA-Client_ID：标识消息被发往的OTA-客户机；
-Download_list：对于OTA-客户机选择的每个下载包括一个元素，所述字段包括以下字段：
-Download_Block_Number：操作软件在被发送到OTA-客户机之前将被分段为的无线电数据块的数量；
-Billing_criteria：与可能的下载记帐有关的标准；
-Installation_criteria：与软件安装有关的标准。
-RRBP：如已经在GPRS标准中定义的，指定在其上终端MS一侧的无线电资源RR应该应答的无线电数据块。
再次参考图8，其描述了Packet Download Accept消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机利用这个消息确认下载。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet Download Accept)；
-OTA-Client_ID：标识发送该消息的OTA-客户机。
再次参考图8，其描述了Packet Download Reject消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机利用这个消息拒绝下载。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet Download Reject)；
-OTA-Client_ID：标识发送该消息的OTA-客户机。
再次参考图8，其描述了Packet License Request消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机利用这个消息向OTA-服务器请求用于解密所下载的操作软件和用于安装软件的密钥。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet License Request)；
-OTA-Client_ID：标识发送该消息的OTA-客户机。
参考图14，图14描述了Packet License Response消息的结构。该消息是从OTA-服务器发往OTA-客户机的。OTA-服务器利用这个消息向OTA-客户机传送用于解密所下载的操作软件和用于安装软件的密钥。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet License Response)；
-OTA-Client_ID：标识消息被发往的OTA-客户机；
-Decrypt_key：用于解密操作软件的密钥。
再次参考图8，其描述了Packet License Accept消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机利用这个消息向OTA-服务器指示下载的操作软件已经被正确解密。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet License Accept)；
-OTA-Client_ID：标识发送该消息的OTA-客户机。
再次参考图8，其描述了Packet License Failed消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机利用这个消息通知OTA-服务器下载的操作软件没有被正确解密。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet License Failed)；
-OTA-Client_ID：标识发送该消息的OTA-客户机。
参考图15，图15描述了Packet Test Description消息的结构。该消息是从OTA-服务器发往OTA-客户机的。OTA-服务器利用这个消息向OTA-客户机指示在启动下载的操作软件之前将针对软件执行的测试。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet Test Description)；
-OTA-Client_ID：标识消息被发往的OTA-客户机；
-Test_list：针对每一个将执行的测试包括一个元素，反之该字段包括：
-Test_vector：包括测试描述。
再次参考图8，其描述了Packet Installation Successful消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机利用这个消息向OTA-服务器指示已经成功执行了下载的操作软件的测试。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet InstallationSuccessful)；
-OTA-Client_ID：标识发送该消息的OTA-客户机。
再次参考图8，其描述了Packet Installation Failed消息的结构。该消息是从OTA-客户机发往OTA-服务器的。OTA-客户机通过这个通知OTA-服务器未能成功执行下载的操作软件的测试。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Packet InstallationFailed)；
-OTA-Client_ID：标识发送该消息的OTA-客户机。
如随后将描述的，在优选实施例中，操作软件是通过利用已知类型的窗口协议从OTA-服务器发送到OTA-客户机的，该窗口协议基于例如称为Block和Ack的两个基本协议数据单元或PDU。
参考图16，图16描述了操作软件已经被分段为的无线电数据块Block的结构。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识该数据块的类型；
-Block_Number：标识无线电数据块的序号，OTA-客户机使用这个序号重组整个操作软件；
-Data：这个字段包含整个操作软件的某些部分或全部。
参考图17，图17描述了用于指示终端接收状态的Ack消息的结构。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-Message_Type：标识发送消息类型(Ack)；
-Ack_Bitmap其为具有大小等于操作软件已经被分段为的无线电数据块的总数的位屏蔽；如果数据块已经被成功接收则针对每一无线电数据块设置其为“1”，并且如果数据块已经被接收但是被破坏或者根本就没有被接收则设置其为“0”。
本发明的优选实施例所预见的对RR协议的修改是基于终端MS一侧的OTA-客户机和无线电资源RR之间的原语的引入的，以及基于基站控制器BSC一侧的OTA-服务器和无线电资源RR之间的原语的引入。
用于命名各原语和相关字段的术语是纯粹指示性的，就如同所述的相应定义那样有意义。
首先，描述终端MS一侧的OTA-客户机和无线电资源RR之间的原语。
Download Request Ind原语从终端MS一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识OTA-客户机，该请求向该OTA-客户机提出；
-Requested Download：这个元素包含由网络请求的下载的一个描述字符串和数字标识符。
Download Ack Ind原语从终端MS一侧的无线电资源RR发送到OTA-客户机。这个原语中提供的各字段如下：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-OTA-Client_Challenge_Number：OTA-服务器将利用其自身的密钥和适当的密码算法，例如AES(高级加密标准)，加密的一个随机数，以便执行相互验证的第一步。
Download Nack Ind原语从OTA-客户机发送到终端MS一侧的无线电资源RR。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Authentication Req原语从终端MS一侧的无线电资源RR发送到OTA-客户机。
这个原语中提供的各字段如下：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-OTA-Server_Response_Number：由OTA-服务器利用其自身的密钥和适当的密码算法(例如AES算法)加密的一个数字，结束相互验证的第一步；
-OTA-Seryer_Challenge_Number：客户机将利用其自身的密钥和适当的密码算法(例如AES算法)加密的一个随机数，以便执行相互验证的第二步。
Authentication Rsp原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-OTA-Client_Response_Number：标识OTA-客户机利用其自身的密钥和适当的密码算法(例如AES算法)加密的一个数字，结束相互验证的第二步和最后一步。
Capability Req原语从MS一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Capability Rsp原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识发送该消息的OTA-客户机；
-OTA-Client_Capability：描述终端的可重新配置性选项。
Download Description Req原语从MS一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-Download_list：对于OTA-客户机选择的每个下载包括一个元素，该元素反之包括以下字段：
-Download_Block_Number：操作软件在被发送到OTA-客户机之前将被分段为的无线电数据块的数量；
-Billing_criteria：与可能的下载记帐有关的标准；
-Installation_criteria：与软件安装有关的标准。
Download Accept Cnf原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Download Accept Rej原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
License Req原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
License Rsp原语从终端MS一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-Decrypt_key：用于解密操作软件的密钥。
License Cnf原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
License Rej原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Test Description Req原语从终端MS一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-Test_list：针对每一个将执行的测试包括一个元素，反之该字段包括：
-Test_vector：包括测试描述。
Installation Cnf原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Installation Rej原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Data Ind原语从终端MS一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-操作软件已经被分段为的无线电数据块的其中之一。
Data Req原语从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-Ack的无线电数据块。
下面描述基站控制器BSC一侧的OTA-服务器和无线电资源RR之间的原语交换。
Download Initiation Ind原语从OTA-客户机发送到基站控制器BSC一侧的无线电资源RR。在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识OTA-客户机，该请求向该OTA-客户机提出；
-Requested Download：这个元素包含由网络请求的下载的一个描述字符串和数字标识符。
Download Ack Ind原语由基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-OTA-Client_Challenge_Number：OTA-服务器将利用其自身的密钥和适当的密码算法，例如AES(高级加密标准)，加密的一个随机数，以便执行相互验证的第一步。
Download Nack Ind原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Authentication Req原语从OTA-客户机发送到基站控制器BSC一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-OTA-Server_Response_Number：由OTA-服务器利用其自身的密钥和适当的密码算法(例如AES算法)加密的一个数字，结束相互验证的第一步；
-OTA-Server_Challenge_Number：OTA-客户机将利用其自身的密钥和适当的密码算法(例如AES算法)加密的一个随机数，以便执行相互验证的第二步。
Authentication Rsp原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-OTA-Client_Response_Number：标识由OTA-客户机利用其自身的密钥和适当的密码算法(例如AES算法)加密的一个数字，结束相互验证的第二步和最后一步。
Capability Req原语从OTA-客户机发送到基站控制器BSC一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Capability Rsp原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识发送该消息的OTA-客户机；
-OTA-Client_Capability：描述终端的可重新配置性选项。
Download Description Req原语从OTA-客户机发送到基站控制器BSC一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-Download_list：对于OTA-客户机选择的每个下载包括一个元素，该元素反之包括以下字段：
-Download_Block_Number：操作软件在被发送到OTA-客户机之前将被分段为的无线电数据块的数量；
-Billing_criteria：与可能的下载记帐有关的标准；
-Installation_criteria：与软件安装有关的标准。
Download Accept Cnf原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Download Accept Rej原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
License Req原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
License Rsp原语从OTA-客户机发送到基站控制器BSC一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-Decrypt_key：用于解密操作软件的密钥。
License Cnf原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
License Rej原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Test Description Req原语从OTA-服务器发送到基站控制器BSC一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-Test_list：针对每一个将执行的测试包括一个元素，反之其包括字段：
-Test_vector：包括测试描述。
Installation Cnf原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Installation Rej原语从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机。
Data Req原语从OTA-服务器发送到基站控制器BSC一侧的无线电资源RR。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-操作软件已经被分段为的无线电数据块的其中之一。
Data Ind原语从基站控制器BSC一侧的无线电资源RR发送到OTA-服务器。
在GSM/GPRS的情况下提供的各字段至少是下述的一组：
-OTA-Client_ID：标识与该原语有关的OTA-客户机；
-Ack的无线电数据块。
参考图4和5，下面将通过为各个RR接收到的每个原语指示根据OTA-客户机或客户机上下文所处状态的有关行为描述OTA-客户机和OTA-服务器之间的程序上的交互作用。
OTA-客户机和OTA-服务器的行为与系统无关。
OTA-客户机或OTA-服务器与各自的RR之间交换的原语依赖于系统，并且依照当前实例参考GSM/GPRS系统。
如之前所描述的，由于各定时器与各实体所处的状态相链接，在下面的描述中没有描述它们的启动/停止动作。
参考图4，现在描述OTA-客户机的行为。
通常，如果OTA-Client ID字段与接收原语的OTA-客户机的标识符不匹配，则所述原语被忽略。
当OTA-客户机接收到Download Request Ind原语时：
-如果状态为IDLE，则OTA-客户机转到DOWNLOADINITIATION；
-如果状态不是DOWNLOAD INITIATION，则该原语被忽略并且过程终止；
-如果终端能够执行下载：
-抽取并存储一个随机数RNUM；
-发送Download Ack Ind原语，其OTA-Client ChallengeNumber字段中包含所抽取的数字RNUM的值；
-如果终端不能执行下载，则发送Download Nack Ind原语并且OTA-客户机返回到IDLE状态。
当OTA-客户机接收到Authentication Req原语时：
-如果状态不是DOWNLOAD INITIATION，则该原语被忽略并且过程终止；
-如果存储的随机数RNUM无效，则过程终止；
-OTA-客户机转到MUTUAL AUTHENTICATION状态；
-通过利用所选择的密码算法(例如，AES算法)使用内部的密钥CIK解密存储的随机数RNUM的值；
-如果在前一阶段解密的值与OTA-Server Response Number字段的值不匹配，则OTA-客户机转到IDLE状态并且过程终止；
-通过利用所选择的密码算法(例如，AES算法)使用内部的密钥CIK(客户机身份密钥)解密OTA-Server Response Number字段的值；
-发送Authentication Rsp原语，其在OTA-Client ResponseNumber字段中具有在前一阶段解密的值。
当OTA-客户机接收到Capability Req原语时：
-如果状态不是MUTUAL AUTHENTICATION，则该原语被忽略并且过程终止；
-OTA-客户机转到CAPABILITY REQUEST状态；
-发送Capability Response原语。
当OTA-客户机接收到Download Description Req原语时：
-如果状态不是CAPABILITY REQUEST，则该原语被忽略并且过程终止；
-OTA-客户机转到DOWNLOAD ACCEPTANCE状态；
-如果终端能够安装软件：
-发送Download Accept Cnf原语；
-如果终端不能够安装软件：
-发送Download Accept Rej原语；
-OTA-客户机转到IDLE状态。
当OTA-客户机接收到License Req原语时：
-如果状态不是INSTALLATION，则该原语被忽略并且过程终止；
-通过利用Decrypt key字段中指示的密钥解密所下载的软件；
-如果解密成功：
-发送License Cnf原语；
-存储所下载的操作软件；
-如果解密失败：
-发送License Rej原语；
-过程转到IDLE状态。
当OTA-客户机接收到Test Description Req原语时：
-如果状态不是INSTALLATION，则该原语被忽略并且过程终止；
-OTA-客户机转到IN-SITU TESTING状态；
-针对之前存储的操作软件执行所接收的测试；
-如果所有的测试已经成功：
-发送Installation Cnf原语；
-安装并启动新的操作软件；
-如果至少一个测试失败：
-发送Installation Rej原语；
-从存储器中删除所下载的操作软件；
-OTA-客户机转到IDLE状态。
参考图5，现在描述OTA-服务器的行为。
通常，在每次接收到原语时分析OTA-Client ID字段并考虑相对于所述标识符的OTA-客户机上下文；如果不存在针对所接收的标识符的OTA-客户机上下文，则该原语被忽略。
当OTA-服务器接收到Download Ack Ind原语时：
-如果OTA-客户机上下文的状态不是DOWNLOADINITIATION，则该原语被忽略并且过程终止；
-OTA-客户机上下文转到MUTUAL AUTHENTICATION状态；
-抽取并存储一个随机数；
-通过利用所选择的密码算法(例如，AES算法)使用内部的密钥SIK(服务器身份密钥)加密OTA-Client Challenge Number字段的值；
-发送Authentication Req原语到OTA-客户机，其OTA-ServerResponse Number字段中具有在前一阶段加密的值且OTA-ServerChallenge Number字段中具有所抽取的数字的值。
当OTA-客户机上下文接收到Download Nack Ind原语时：
-如果OTA-客户机上下文的状态不是DOWNLOADINITIATION，则该原语被忽略并且过程终止；
-OTA-客户机上下文转到IDLE状态。
当OTA-客户机上下文接收到Authentication Rsp原语时：
-如果OTA-客户机上下文的状态不是MUTUALAUTHENTICATION，则该原语被忽略并且过程终止；
-通过利用所选择的密码算法(例如，AES算法)使用内部的密钥SIK解密存储的随机数的值；
-如果在前一阶段解密的值与OTA-Client Response Number字段的值不匹配，则OTA-客户机上下文转到IDLE状态并且过程终止；
-OTA-服务器转到CAPABILITY REQUEST状态；
-发送Capability Req原语。
当OTA-客户机上下文接收到Capability Rsp原语时：
-如果OTA-客户机上下文的状态不是CAPABILITYREQUEST，则该原语被忽略并且过程终止；
-如果该原语中包含的能力与将要下载的软件的不一致，则OTA-客户机上下文转到IDLE状态；
-如果该原语中包含的能力与将要下载的软件的一致，则OTA-客户机上下文转到DOWNLOAD ACCEPTANCE状态，并发送Download Description Req原语。
当OTA-客户机上下文接收到Download Accept Cnf原语时：
-如果OTA-客户机上下文的状态不是DOWNLOADACCEPTANCE，则该原语被忽略并且过程终止；
-OTA-客户机上下文转到SOFTWARE DOWNLOAD状态；
-开始软件下载。
当OTA-客户机上下文接收到Download Accept Rej原语时：
-如果OTA-客户机上下文的状态不是DOWNLOADACCEPTANCE，则该原语被忽略并且过程终止；
-OTA-客户机上下文转到IDLE状态。
当OTA-客户机上下文接收到License Req原语时：
-如果OTA-客户机上下文的状态不是SOFTWAREDOWNLOAD，则该原语被忽略并且过程终止；
-过程转到INSTALLATION状态；
-发送License Rsp原语；其包含解密密钥。
当OTA-客户机上下文接收到License Cnf原语时：
-如果OTA-客户机上下文的状态不是INSTALLATION，则该原语被忽略并且过程终止；
-发送Test Description Req原语。
当OTA-客户机上下文接收到License Rej原语时：
-如果OTA-客户机上下文的状态不是INSTALLATION，则该原语被忽略并且过程终止；
-OTA-客户机上下文转到IDLE状态。
当OTA-客户机上下文接收到Installation Cnf原语时：
-如果OTA-客户机上下文的状态不是INSTALLATION，则该原语被忽略并且过程终止；
-OTA-客户机上下文转到IDLE状态。
当OTA-客户机上下文接收到Installation Rej原语时：
-如果OTA-客户机上下文的状态不是INSTALLATION，则该原语被忽略并且过程终止；
-OTA-客户机上下文转到IDLE状态。
现在描述窗口协议的操作，数据依照该协议从OTA-服务器传送到OTA-客户机。
从OTA-服务器的观点看，当软件下载开始时，操作软件例如使用一个加密密钥以及使用一个已知类型的例如AES算法的加密算法被加密。
加密后的操作软件被分段为具有例如有限大小(例如1-2k字节)的块。其被分配了一个具有大小等于操作软件已经被分段为的无线电数据块的数量的位数的位屏蔽BITMASK，并且每个位的值被设置为“0”；位屏蔽的每一位对应于一个无线电数据块，该无线电数据块的编号等于该位位置，即第一位对应于第一个无线电数据块，第二位对应于第二个数据块等等。头N个构成操作软件的无线电数据块BLOCK被发送。启动定时器T401。在接收到每个消息Ack时：
-重新启动定时器T401；
-对于消息Ack的位图中现有的每个值“1”，设置对应位置中分配的位屏蔽BITMASK的值为“1”；
-首先考虑尚未发送的块，在最大值发送位屏蔽BITMASK中对应值为“0”的头N个无线电块BLOCK；
-当位屏蔽BITMASK的所有位的值都等于“1”时下载结束。
从OTA-客户机的观点来看，当软件下载开始时，其被分配了一个等于操作软件已经被分段为的无线电数据块的数量的位屏蔽BITMASK，并且每个位的值被设置为“0”；位屏蔽的每一位对应于一个无线电数据块，该无线电数据块的编号等于该位位置，即第一位对应于第一个无线电数据块，第二位对应于第二个数据块等等。然后启动定时器T400。在接收到每个无线电数据块BLOCK时：
-重新启动定时器T400；
-对应接收的无线电数据块的块编号的位屏蔽BITMASK的位被设置为“1”；
-发送具有对应于该位屏蔽BITMASK的位图的Ack消息；
-当位屏蔽BITMASK的所有位的值都为“1”时下载结束。
总之，根据该实例，OTA客户机和OTA服务器的功能行为如下：
-下载过程在当例如一旦接收到由MSC(移动交换中心)发送到基站控制器BSC的Handover Command协议消息时启动；
-根据例如“询问-应答”方法发生OTA-客户机和OTA-服务器之间的相互验证；
-在业务信道上发送将被下载的操作软件，例如GPRS业务信道；
-OTA-服务器分段将被下载的操作软件为例如具有缩减的大小(例如1或2k字节)的块；
-操作软件的传送通过其中窗口大小匹配操作软件已经被分段为的数据块的数量的简单窗口协议来管理；
-下载的操作软件可以被加密，并且在此情况下需要一个密钥用于其的解密和安装；
-在启动操作软件之前，OTA-客户机使用例如由OTA-服务器所建议的适当的测试来检验之。
参考图18，其举例说明了针对电路呼叫的从GSM到UMTS的系统间切换过程的应用实例，如根据标准所定义的，在该过程之内已经引入了能够重新配置终端MS的操作软件的下载过程。
参考图19，图19解释了所述软件下载过程是如何工作的，指出网络中存在的不同实体之间的交互作用。
1.有关所考虑的OTA-客户机以及在OTA-服务器中出现的OTA-客户机和OTA-客户机上下文处于IDLE状态。
2.当从移动交换中心(MSC)接收到Handover Command协议消息时，OTA-客户机上下文从IDLE状态转到DOWNLOADINITIATION状态，启动定时器T101并发送到Download_Initiation_Ind原语到无线电资源RR，同时指示所请求的下载。
3.无线电资源RR接收Download_Initiation_Ind原语。无线电资源RR向无线电资源管理程序RRM请求必要的下行链路资源用于使其可能执行该软件下载：
a.如果可以获得资源，则无线电资源RR在FACCH(快速相关控制信道)控制信道上发送Packet_Download_Request协议消息到终端MS的无线电资源RR，其在该协议消息中指示了终端将在其上执行下载的PDCH信道、相对保留的块周期RRBP以及所请求的下载。
b.如果不能获得资源，则无线电资源RR发送Download Nack Ind原语到OTA-客户机上下文。
4.终端MS的无线电资源RR接收到Packet_Download_Request协议消息，配置PDCH信道并发送Download_Request_Ind原语。
5.OTA-客户机接收Download_Request_Ind原语。如果终端能够执行该下载，则OTA-客户机从IDLE状态转到DOWNLOAD_INITIATION状态，启动定时器T100并发送Download_Ack_Ind原语，其在该原语中向无线电资源RR指定了其自身的标识符。无线电资源RR在本地存储OTA-客户机的该标识符。
6.无线电资源RR接收Download_Ack_Ind原语并在相对保留的块周期RRBP指定的时间在PACCH(分组相关控制信道)上发送Packet_Download_Ack协议消息到基站控制器BSC的无线电资源RR，其在该协议消息中指示了OTA-客户机的标识符。
7.基站控制器BSC的无线电资源RR接收Packet_Download_Ack协议消息并发送Download_Ack_Ind原语到OTA-客户机上下文，其在该原语中指定了OTA-客户机的标识符。
8.OTA-客户机上下文接收Download_Ack_Ind原语；OTA-客户机上下文停止定时器T101并从DOWNLOAD_INITIATION状态转到MUTUAL_AUTHENTICATION状态，同时启动定时器T201；发送Authentication_Req原语到无线电资源RR。
9.无线电资源RR接收Authentication_Req原语并在PACCH控制信道上发送Packet_Authentication_Request协议消息到终端MS的无线电资源RR，在该协议消息中指出了RRBP。
10.终端MS的无线电资源RR接收Packet_AuthenticationRequest协议消息并发送Authentication_Req原语到OTA-客户机。
11.OTA-客户机接收Authentication_Req原语，停止定时器T100并转到MUTUAL_AUTHENTICATION状态，同时启动定时器T200；在这个阶段执行OTA-服务器的验证：
a.如果未能验证OTA-服务器，则OTA-客户机停止定时器T200并返回到IDLE状态。
b.如果验证了OTA-服务器，则OTA-客户机发送Authentication_Rsp原语到无线电资源RR。
12.无线电资源RR接收Authentication_Rsp原语并在相对保留的块周期RRBP指定的时间在PACCH上发送Packet_Authentication_Response协议消息到基站控制器BSC的无线电资源RR。
13.基站控制器BSC的无线电资源RR接收Packet_Authentication_Response协议消息并发送Authentication_Rsp原语到OTA-客户机上下文。
14.OTA-客户机上下文接收Authentication_Rsp原语并核实OTA-客户机的验证：
a.如果未能验证OTA-客户机，则中断定时器T201并且OTA-客户机上下文返回到IDLE状态。
b.如果验证了OTA-客户机，则中断定时器T201并且OTA-客户机上下文转到CAPABILITY REQUEST状态，同时启动定时器T301。OTA-客户机上下文发送到Capability_Req原语无线电资源RR。
15.无线电资源RR接收Capability_Req原语并在PACCH控制信道上发送Packet_Capability_Req协议消息到终端MS的无线电资源RR，在该协议消息中指定了RRBP。
16.终端MS的无线电资源RR接收Packet_Capability_Req协议消息并发送Capability_Req原语到OTA-客户机。
17.OTA-客户机接收Capability_Req原语，停止定时器T200并转到CAPABILITY REQUEST状态，同时启动定时器T300；OTA-客户机发送到Capability_Rsp原语无线电资源RR。
18.无线电资源RR接收Capability_Rsp原语并在RRBP指定的时间在PACCH上发送Packet_Capability_Response协议消息到基站控制器BSC的无线电资源RR。
19.基站控制器BSC的无线电资源RR接收Packet_Capability_Response协议消息并发送Capability_Rsp原语到OTA-客户机上下文。
20.OTA-客户机上下文接收Capability_Rsp原语并核实终端的能力：
a.如果该能力与软件下载不一致，则中断定时器T301并且OTA-客户机上下文返回到IDLE状态。
b.如果该能力与软件下载一致，则中断定时器T301并且OTA-客户机上下文转到DOWNLOAD ACCEPTANCE状态，同时启动定时器T302并发送Download_Description_Req原语到无线电资源RR，在该原语中指示了与下载选项有关的信息(要下载的无线电数据块的数量，记帐、安装等等)。
21.无线电资源RR接收Download_Description_Req原语并在PACCH控制信道上发送Packet_Download_Description协议消息到终端MS的无线电资源RR，在该协议消息中指示了RRBP。
22.终端MS的无线电资源RR接收Packet_Download_Description协议消息并发送Download_Description_Req原语到OTA-客户机。
23.OTA-客户机接收Download_Description_Req原语，停止定时器T300并转到DOWNLOAD ACCEPTANCE状态；OTA-客户机核实所接收的信息：
a.如果没有接受该下载，则OTA-客户机发送Download_Accept_Rej原语到无线电资源RR并返回到IDLE状态。
b.如果接受了该下载，则OTA-客户机发送Download_Accept_Cnf原语到无线电资源RR并转到SOFTWAREDOWNLOAD状态，同时启动定时器T400。
24.无线电资源RR接收Download_Accept_Cnf原语并在RRBP指定的时间在PACCH上发送Packet_Download_Accept协议消息到基站控制器BSC的无线电资源RR。
25.基站控制器BSC的无线电资源RR接收Packet_Download_Accept协议消息并发送Download_Accept_Cnf原语到OTA-客户机上下文。
26.OTA-客户机上下文接收Download_Accept_Cnf原语，停止定时器T302并且OTA-客户机上下文转到SOFTWARE DOWNLOAD状态，同时激活定时器T400；OTA-客户机上下文启动下载并通过发送Data_Req原语到无线电资源RR开始传送将下载的软件的各个数据块。无线电数据块的传送是借助于常规的窗口协议发生的。无线电数据块在PDTCH信道(分组数据传送信道)上发送。
27.OTA-客户机通过从无线电资源RR接收Data_Ind原语接收每一个无线电数据块；在接收到每一数据块时，定时器T400被重新启动；OTA-客户机周期性通过发送Data_Req原语到无线电资源发送确认信号Ack到OTA-客户机上下文。无线电资源RR在相关的PACCH信道上发送该Ack。当OTA-客户机发送相对于最后一个将下载的无线电数据块时，停止定时器T400并转到INSTALLATION状态，同时启动定时器T500；发送License_Req原语到无线电资源RR。
28.OTA-客户机上下文通过从无线电资源RR接收Data_Ind原语接收各个Ack消息；在接收每一Ack时重新启动定时器T401。当OTA-客户机上下文接收到相对于最后一个无线电数据块的Ack时，停止定时器T401并转到INSTALLATION状态，同时启动定时器T501。
29.无线电资源RR接收License_Req原语并在相关PACCH控制信道上发送Packet_License_Request协议消息到基站控制器BSC的无线电资源RR。
30.基站控制器BSC的无线电资源RR接收Packet_License_Request协议消息并发送License_Req原语到OTA-客户机上下文。
31.OTA-客户机上下文接收License_Req原语并发送License_RSP原语到无线电资源RR，同时指示用于执行软件解密的密钥。
32.无线电资源RR接收License_Rsp原语并在相关PACCH控制信道上发送Packet_License_Response协议消息到终端MS的无线电资源RR。
33.终端MS的无线电资源RR接收Packet_License_Response协议消息并发送License_Rsp原语到OTA-客户机。
34.OTA-客户机接收License_Rsp原语并使用所接收的密钥解密软件：
a.如果解密操作成功，则OTA-客户机发送License_Cnf原语到无线电资源RR。
b.如果解密操作失败，则OTA-客户机发送License_Rej原语到无线电资源，停止定时器T500并返回到IDLE状态。
35.无线电资源RR接收License_Cnf原语并在相关PACCH控制信道上发送Packet_License_Accept协议消息到基站控制器BSC的无线电资源RR。
36.基站控制器BSC的无线电资源RR接收Packet_License_Accept协议消息，并发送License_Cnf原语到OTA-客户机上下文。
37.OTA-客户机上下文接收License_Cnf原语并发送Test_Description_Req原语到无线电资源RR，同时指示有关将要执行的测试的信息。
38.无线电资源RR接收Test_Description_Req原语并在相关PACCH信道上发送Packet_Test_Description协议消息到终端MS的无线电资源RR。
39.终端MS的无线电资源RR接收Packet_Test_Description协议消息并发送Test_Description_Req原语到OTA-客户机。
40.OTA-客户机接收Test_Description_Req原语，停止定时器T500并转到IN-SITU TESTING状态。OTA-客户机针对所下载的软件执行由OTA-客户机上下文指示的测试：
a.如果测试失败，则OTA-客户机发送INSTALLATION_REJ原语到无线电资源RR并返回到IDLE状态。
b.如果测试成功，则OTA-客户机发送Installation_Cnf原语到无线电资源RR，启动该新软件并返回到IDLE状态。
41.无线电资源RR接收INSTALLATION_CNF原语并在相关PACCH信道上发送Packet_Installation_Accept协议消息到基站控制器BSC的无线电资源RR，并重新配置终端MS的无线电接口。
42.基站控制器BSC的无线电资源RR接收Packet_Installation_Accept协议消息，发送Installation_Cnf原语到OTA-客户机上下文，启动如根据标准提供的资源释放过程，并且一旦所述过程已结束，其如根据标准所提供的继续该切换过程。
43.OTA-客户机上下文接收Installation_Cnf原语并返回到IDLE状态。
图19公开的过程称为操作软件下载过程。
如熟练技术人员能够理解的，该过程可被插入到如根据标准定义的针对电路呼叫的从GSM到UMTS的系统间切换过程。
特别地，该插入可以在从MSC接收基站子系统应用部分(BSSAP)协议的HANDOVER COMMAND消息，和发送RR协议的INTERSYSTEM TO UTRAN HANDOVER COMMAND消息到MS之间的RR层上完成。
本发明可以一般化到根据当前的标准指定的所有可能的系统间切换过程。
例如，如熟练技术人员能够理解的，该过程可能被插入如根据标准所定义的针对电路呼叫的从UMTS到GSM的系统间切换过程。特别地，该插入可以在从MSC接收无线电接入网应用部分(RANAP)协议的RELOCATION COMMAND消息，和发送无线电资源控制(RRC)协议的HANDOVER FORM UTRAN COMMAND消息到MS之间的无线电资源控制(RRC)层上完成。
本发明还可一般化到尚未标准化的系统间切换过程，例如国际移动电信2000(IMT 2000)和WLAN或IEEE 802.16或IEEE 802.20系统之间的系统间切换过程。
如对熟练技术人员显见的，在语音呼叫特别是电路类型的呼叫的情况下，本发明允许执行操作软件的下载而不中断呼叫；在例如GSM/GPRS的情形下，这通过以与用于电路通信的例如TCH(业务信道)GSM信道的电路类型的信道并行的方式分配一个或多个例如PDTCH GPRS信道的分组信道是可能的。
这种特征可以允许管理语音、数据和软件下载之间的优先级。
已经通过保持GSM/GPRS系统作为参考和使用上述系统的无线电信道公开了本发明，但是，如熟练技术人员能够理解的，可以利用例如“通用”信道应用本发明。
利用“通用”信道的一个可能的例子可能是如由文献定义的利用“通用”信道用于从OTA服务器到OTA客户机的操作软件下载过程。
在系统间切换的情况下，当在采用例如图18中所公开的过程的上述“通用”信道之上同时利用从OTA服务器到OTA客户机的操作软件下载过程的时候，利用“通用”信道的实现能够预见在例如GSM/GPRS系统的有源系统的无线电信道之上维持有源连接。
“通用”信道可用于整个操作软件下载过程或者仅仅其的一部分，例如从OTA服务器到OTA客户机的操作软件的传送。
在部分使用“通用”信道的情况下，可以通过利用有源系统的无线电信道实现操作软件下载过程的剩余部分。
由于“通用”信道是专用于这种类型的操作的信道，“通用”信道的采用允许以更为有效的方式载入与有源系统有关的无线电资源，将它们留下以对其它的用户可用并用于更快地执行操作软件下载过程。
如熟练技术人员已知的，当终端在例如从GSM/GPRS到UMTS的两个系统之间处于例如IDLE状态时，本发明的另外的实施例还提供了管理小区重选择过程的可能性。
如之前提及的，用于命名各原语和相关字段的术语是纯粹指示性的，就如同所述的相应定义那样有意义。
这种扩展为终端MS一侧的OTA-客户机和无线电资源RR之间的下述原语的引入作准备：
-Download Initiation Req：该消息从OTA-客户机发送到终端MS一侧的无线电资源RR。
在GSM/GPRS的情况下在这个原语中提供的各字段至少是下述的一组：
-OTA-Client_ID：标识执行该请求的OTA-客户机；
以及基站控制器BSC一侧的OTA-服务器和无线电资源RR之间的下列原语：
-Request Download Initiation Ind：该消息从基站控制器BSC一侧的无线电资源RR发送到OTA-客户机。
在GSM/GPRS的情况下在这个原语中提供的各字段至少是下述的一组：
-OTA-Client_ID：标识执行该请求的OTA-客户机。
下面指出了当接收Request Download Initiation Ind原语时相对于OTA-客户机上下文的终端MS的上下文的行为：
-如果OTA-客户机上下文的状态不是IDLE，则该原语被忽略并且过程终止；
-OTA-客户机上下文转到DOWNLOAD INITIATION状态；
-发送Download Initiation Ind原语到OTA-客户机，同时指示各种可能的下载。
参考图19，图19举例说明了小区重选择的情形下的操作软件的下载过程的工作方式，指出了网络中存在的不同的实体之间的交互。由于过程自身余下的部分与图18的描述一致，下文中详细描述了该过程的第一阶段的工作方式。
I.OTA-客户机和OTA-客户机上下文相对于所考虑的OTA-客户机处于IDLE状态。
II.一旦接收到来自物理层的小区重选择指令，OTA-客户机从IDLE状态转到DOWNLOAD INITIATION状态，启动定时器T100并发送Download_Initiation_Req原语，在该原语中其向无线电资源RR指示了其自身的标识符。
III.无线电资源RR接收Download_Initiation_Req原语。无线电资源RR在分组随机接入信道PRACH上发送根据标准提供的Packet_Channel_Request协议消息，在该协议消息中其指定了用户的操作软件下载请求以及OTA-信道的标识符。在由操作员安装的GPRS配置没有提供由分组广播控制信道PBCCH以及由分组公共控制信道PCCCH构成的主信道的情况下，通过将过程自身的最初的两个消息映射到GSM的随机接入信道RACH和接入授权信道AGCH之上而不是映射到如所描述的分组随机接入信道PRACH和分组接入授权信道PAGCH之上，所描述的过程仍然是有效的。
IV.基站控制器BSC的无线电资源RR接收Packet_Channel_Request协议消息。由于这被识别为软件下载请求，其发送Request_Download_Initiation_Ind原语到OTA-客户机上下文，在该原语中指定了通过所接收的消息阅读的OTA-客户机的标识符。
V.OTA-服务器接收Request_Download_Initiation_Ind原语并核实OTA-客户机上下文相对于所指示的OTA-客户机处于什么状态：
a.如果状态为IDLE，则OTA-客户机上下文转到DOWNLOADINITIATION，启动定时器T101并发送Download_Initiation_Ind原语到无线电资源RR，同时指示所请求的下载。
b.如果状态不是IDLE，则该消息被忽略。
VI.无线电资源RR接收Download_Initiation_Ind原语。无线电资源RR向无线电资源管理RRM请求必要的下行链路资源用于使其可能下载该软件：
a.如果可以获得资源，则无线电资源RR在PACCH控制信道上发送Packet_Download_Request协议消息到终端MS的无线电资源RR，其在该协议消息中指示了终端将在其上执行下载的PDCH信道、RRBP以及所请求的下载。
b.如果不能获得资源，则无线电资源RR发送Download Nack Ind原语到OTA-客户机上下文。
VII.终端MS的无线电资源RR接收到Packet_Download_Request协议消息，配置PDCH信道并发送Download_Request_Ind原语。
VIII.OTA-客户机接收Download_Request_Ind原语。如果终端能够执行该下载，则OTA-客户机发送Download_Ack_Ind原语，其在该原语中指定了其自身的标识符。无线电资源RR在本地存储OTA-客户机的该标识符。
该过程通过执行参考图18描述的从序号6开始的该过程的前面的各阶段而继续。
已经通过保持GSM/GPRS参考作为系统接入网络公开了根据本发明描述的体系结构和方法。
本发明也可以应用于UMTS、UTRAN(UMTS地面无线电接入网络)的接入网络或者任何其它的接入网络，例如WLAN、IEEE802.16、IEEE 802.20。
例如，在UTRAN的情况下，可以在UMTS系统的RRC层插入OTA客户机和OTA服务器以及相关的过程、原语和协议消息实现本发明。
已经通过利用接入网以及网络一侧和终端一侧中相应的协议层公开了本发明。
本发明也可通过利用核心网络以及网络一侧和终端一侧中相应的协议层来实现。
在此情况下，考虑例如GSM/GPRS和UMTS系统的分组交换核心网络，可以通过分别在核心网络的终端和服务GPRS支持节点(SGSN)的GPRS移动性管理(GMM)层插入OTA客户机和OTA服务器以及相关的过程、原语和协议消息实现本发明。
更为特别地，在GSM/GPRS的情况下，通过引入OTA-服务器和OTA-客户机之间交换的新的协议消息和相关字段修改GPRS移动性管理(GMM)层。该同样的实现方法可应用于UMTS系统。
已经通过考虑在系统间切换过程期间一个操作软件的下载和激活公开了本发明。
如对熟练技术人员显见的，操作软件可以被选择并存储到终端中，而不是被立即安装和运行。
根据这个进一步的实施例，有可能基于来自网络或来自用户的请求相继安装和运行操作软件。如果无线电终端UE/MS具有足够的存储器和处理能力，下载的操作软件可与已经存在并当前正运行的系统并发地被存储和安装。
这个选项有益于终端UE/MS的多态工作，换言之，这个选项授予终端无需下载操作软件即从一个操作模式切换到另一个操作模式的能力。
总之，多亏了本发明，有可能获得至少下述优点：
-由于没有向已经存在的那些网络增加任何节点或物理接口，使得对第二和第三代网络中现有的协议和节点的影响最小化；
-由于该过程的信令阶段使用了根据标准提供的同一信令信道同时仅为了软件下载过程分配数据信道使得对无线电资源的占用最小化；
-由于本发明是基于已经存在的第二和第三代网络的，故无需等待基于IP的未来的UMTS版本。
特别地，在利用接入网以及网络一侧和终端一侧中相应的协议层的情况下，由于RR(无线电资源)协议已经集成了一些允许终端下载新的操作软件的修改，网络可完全控制软件下载过程和有关的无线电资源，其可以实现例如类似GSM/GPRS、IS95、PDC(电话数字蜂窝)的第二代蜂窝系统或者例如属于IMT2000系列的第三代蜂窝系统。
机译： 通过无线电通信网络配置无线电终端的方法，相关网络及其计算机程序产品
机译： 通过无线电通信网络配置无线电终端的方法，相关网络及其计算机程序产品
机译： 通过无线电通信网络配置无线电终端的方法，相关网络和计算机程序产品参考
