(OMA-TS-DM-FUMO-V1_0-20060615-C)
一.简介
本规范描述基于OMA-DM的移动设备的固件升级相关的管理对象信息和管理对象的处理行为。同时被说明的还有同"Exec"命令和Generic Alerts相关的行为。
它解决的是移动设备的交互固件升级方案的缺陷。本规范为客户端和服务器端提供了一套接口来支持固件升级，这个方案由升级包下载、固件安装和状态（升级成功或失败）汇报三部分组成。
本规范为移动操作员、服务提供商、基础架构厂商、设备制造商和软件提供商来开发和部署交互式固件升级方案提供依据。
目标观众：提供固件升级方案和升级包下载方案的工程师。
二.固件升级管理对象(FUMO)
固件升级管理对象的基本结构如下：
x---|-----PkgName？ 〈--- Name of Update Package
|-----PkgVersion？ 〈--- Version of Update Package
|-----Download? 〈--- Node used by Exec to initiate download
|---PkgURL 〈--- Reference to target for Update Package
|-----Update? 〈--- Node used by Exec to initiate Update
|---PkgData 〈--- Reference to target for Update Package
|-----DownloadAndUpdate？〈------ Node used by Exec to initiate
| Download and Update
|---PkgURL 〈--- URL Location to get Update Package
|-----State 〈--- Current State of the device
|-----Ext？ 〈--- Hook for Vendor Specific Extensions
2.1固件升级管理对象参数
下面描述的是固件升级管理对象的节点。
2.1.1节点：x
这个内部节点作为一个占位符扮演着固件升级包唯一识别符的角色，其类型必须同第5部分指定的管理对象识别符相对应。厂商可以为x预创建一些永久节点，如果需要也允许通过升级包节点x创建，或者联合这两种方式。举例来说，永久节点可以在固件包加工的时候创建，其他节点作为新特征来增加。一个例子将可能包含标签节点FWPkg1,FWPkg2...FWPkgn。设备制造商提供的DDF文件指出了x节点被定位到了管理树的什么位置。
Occurrence：ZeroOrMore
Format：Node
Access Types：Get
Values：N/A
2.1.2节点：x/PkgName
这个可选节点指出了固件升级包的名称。
Occurrence：ZeroOrOne
Format：Chr
Access Types：Get
Values：N/A
2.1.3节点：x/PkgVersion
这个可选节点指定了固件升级包的版本信息，版本信息是设备制造商指定的并且可以容纳任意数据。
Occurrence：ZeroOrOne
Format：Chr
Access Types：Get
Values：N/A
2.1.4节点：x/Download
这个可选内部节点是为了初始化固件下载执行Exec命令的目标。
Occurrence：ZeroOrOne
Format：Node
Access Types：Exec，Get
Values：N/A
2.1.5节点：x/Download/PkgURL
这个节点指出了固件升级包或下载描述文件的目标URL，这个URL被用来作为可选的下载机制（譬如像HTTP Get[RFC2616]或者Descriptor Based Download[DLOTA]）。
Occurrence：One
Format：Chr
Access Types：Get，Replace
Values：N/A
2.1.6节点：x/Update
这个可选内部节点是为了初始化固件升级执行Exec命令的目标。
Occurrence：ZeroOrOne
Format：Node
Access Types：Exec，Get
Values：N/A
2.1.7节点：x/Update/PkgData
这个节点是当DM被用来直接提供二进制固件升级包数据时执行Replace命令的目标。
Occurrence：ZeroOrOne
Format：Bin
Access Types：Replace
Values：N/A
2.1.8节点：x/DownloadAndUpdate
这个可选内部节点是为了初始化固件下载和升级执行Exec命令的目标，这个升级必须在一旦下载完毕后发生。
Occurrence：ZeroOrOne
Format：Node
Access Types：Exec，Get
Values：N/A
2.1.9节点：x/DownloadAndUpdate/PkgURL
这个节点指定了固件升级包或者下载描述文件的位置URL，这个将接下来被用来下载和升级。这个URL被用来作为可选的下载机制（譬如像HTTP Get[RFC2616]或者Descriptor Based Download[DLOTA]）。
Occurrence：One
Format：Chr
Access Types：Get，Replace
Values：N/A
2.1.10节点：x/State
指明同这次固件升级关联的移动设备的当前状态。
Occurrence：One
Format：Int
Access Types：Get
Values：看下表
下面的状态表枚举了有效状态：
State Description Integer Value
Idle/Start No pending operation 10
Download Failed Download failed 20
Download Progressing Download has started 30
Download Complete Download has been completed 40
successfully
Ready to Update Have data and awaiting command 50
to start update
Update Progressing Update has started 60
Update Failed/Have Data Update failed but have 70
update package
Update Failed/No Data Update failed and no update 80
package available
Update Successful/Hava Data Update complete and data 90
still available
Update Successful/No Data Data deleted or removed 100
after a successful Update
2.1.11节点：x/Ext
这个节点是为了提供商特殊的扩展。
Occurrence：ZeroOrOne
Format：Node
Access Types：Get
Values：N/A
三.管理对象的行为
下面的图表展示了固件升级时终端的有效状态的转换，有些状态服务器是不知晓的。
典型的，开始状态是"Idle/Start"，结束状态是下面的一个：
- Update Failed / Have Data
- Update Failed / No Data
- Update Successful / Have Data
- Update Successful / No Data
- Download Failed
3.1Exec命令
Exec命令是必须被支持的。
服务器发出Exec命令来在客户端执行长时间运行的操作，譬如下载和升级。执行Exec命令的结果作为一个ResultCode被编码，然后随着操作的完成用一个Generic Alert返回。一个correlator如果伴随着Exec命令应用，也将在Generic Alert中返回。如果Exec命令被接受并进入后续处理客户端必须异步返回一个202状态。
当在Download节点上执行Exec命令，需要提示用户选择的时候，则服务器可以发出一个用户交互Alert(User Interaction Alert [DMPRO]).
如果采用OMA DM协议的large-object的方式执行升级包的下载，服务器首先用‘Replace’命令来执行下载，然后采用Exec命令来执行升级。
管理对象的State节点被用来表明相应的升级和下载执行后客户端的状态变化。
3.1.1下载时Exec命令的语义
服务器在x/Download节点上发出Exec命令。客户端根据服务器发出的x/Download/PkgURL节点标示的URL值初始化一个下载操作。当下载操作完成后，客户端发出一个Generic Alert来表明下载操作的结果。
3.1.1.1下载时Exec命令的示例
前置条件：下面的元素节点被设定为正确的值。
Exec命令的例子：
<Exec>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>x/Download</LocURI>
</Target>
</Item>
</Exec>
3.1.2升级时Exec命令的语义
服务器在x/Update节点上发出Exec命令，客户端利用的是前面Download所接收的升级包。升级操作完成后，客户端发出一个Generic Alert来表明升级操作的结果。
3.1.2.1升级时Exec命令的示例
前置条件：固件升级包必须在设备上已存在。
Exec命令的例子：
<Exec>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>x/Update</LocURI>
</Target>
</Item>
</Exec>
3.1.3下载升级时Exec命令的语义
服务器在x/DownloadAndUpdate节点上发出Exec命令，客户端根据服务器发出的x/DownloadAndUpdate/PkgURL节点标示的URL值初始化一个下载操作，当下载操作成功完成后，客户端在不需要服务器的干预下应用接收到的升级包。升级操作完成后，客户端发出一个Generic Alert来表明升级操作的结果。在这次事件流程中，当下载失败时，客户端发出一个Generic Alert来表明下载操作的失败。
3.1.3.1下载升级时Exec命令的示例
前置条件：下面的对象需要用正确的值来设定。
Exec命令的例子：
<Exec>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>x/DownloadAndUpdate</LocURI>
</Target>
</Item>
</Exec>
3.2通知中Generic Alert的使用
在3.1节中当Exec命令执行结束时，设备需要向DM服务器使用Generic Alert [DMPRO]发送一个通知。这个alert消息包含下面的数据：
- 一个整形的结果代码--被用来汇报结果状态
- 固件升级管理对象的URI--用来识别源
- 一个alert类型--用来识别操作
- Correlator--被服务器使用并作为Exec命令的一部分来传输
正在汇报错误或者失败的alerts也将在Meta信息的Mark域中除了汇报一般信息外还有严重性级别信息。
一旦操作完成后Generic Alert被发送到DM服务器，如果没有服务器的进一步干预，设备一定不能再次经由Exec命令发起上次操作。
注意：如果服务器需要检索额外的信息，譬如状态State，则服务器需要向客户端查询那些指定的节点。
3.2.1固件升级管理对象的URI
这个URI必须作为Generic Alert [DMPRO]消息的源source被发送，这个允许管理服务器来识别alert的原先来源。
3.2.2固件升级的alert类型
来源于管理对象的下面的alert类型必须被使用在Generic Alert [DMPRO]消息中。这个alert类型被用来识别到底在设备上Exec命令执行什么操作。
alert类型“org.openmobilealliance.dm.firmwareupdate.download”被用来回复下载操作的完成。
alert类型“org.openmobilealliance.dm.firmwareupdate.update”被用来回复升级操作的完成。
alert类型“org.openmobilealliance.dm.firmwareupdate.downloadandupdate”被用来回复下载升级操作的完成。
3.2.3Correlator
固件升级操作中在 Exec命令里如果服务器传输了一个correlator给客户端，客户端必须在Generic Alert [DMPRO]消息的correlator域返回相同的值给服务器。
固件升级操作中在 Exec命令里如果服务器没有传输correlator给客户端，客户端一定不要在Generic Alert [DMPRO]消息的correlator域返回一个correlator。
3.2.4结果代码
操作的结果代码必须作为一个整形值在GenericAlert [DMPRO]消息的Data元素中被发送。结果代码必须是下面定义值中的一个：
结果代码 含义 应用
200 成功 成功-请求成功
250-299 成功-厂商指定 厂商指定结果代码为成功
400 管理客户端错误 管理客户端错误-基于用户或设备行为
401 用户取消 当提示时用户选择不接受操作
402 损坏的固件升级包 没有正确的存储、发现，譬如在希望
的和真实的CRCs不匹配
403 固件升级包-设备不匹配 错误的升级包传到了设备上
404 固件升级包验证失败 数字签名验证失败
405 固件升级包不被接受 固件升级包不被接受
406 下载时验证失败 当下载升级包时，需要验证但验证失败
407 下载时Time-Out 客户端出现了下载时time-out
408 没有实现 设备不支持的请求操作
409 未定义错误 通过其他错误代码标明失败未定义
410 固件升级失败 设备上的固件升级失败
411 URL有问题 提供下载用的URL存在问题
412 连不上下载服务器 下载服务器不可得或没有响应
450-499 客户端错误-厂商指定 由厂商指定自己的结果代码
500 下载服务器错误 遇到了下载服务器错误
501 下载失败-由于设备内存不足 设备内存不足以保存下载的升级包
502 升级失败-由于设备内存不足 没有充足的内存来更新设备
503 下载失败-由于网络问题 网络或传输层错误导致下载失败
550-599 下载服务器错误-厂商指定 厂商自己制定的下载服务器错误代码
在上面的表格中，2xx序列标明成功结果，4xx和5xx标明失败的结果和原因。
3.3升级包下载和升级的支持
支持FUMO 1.0的客户端必须至少一种的升级包下载方式，这种下载机制必须是OMA DM下一种的传输和下载机制，譬如OMA Download
[DLOTA].另外，为了成功的执行一次固件升级，至少下面一个活动被支持：
- Exec on x/Update 节点
- Exec on x/DownloadAndUpdate 节点
4客户端发起的固件升级（标准的）
4.1概要
固件升级在设备上也有自己的独立性，所以这个对于客户端设备和服务器可以作为一个可选的特征。 这部分仅将定义客户端发起的消息格式和在什么样的环境下设备不发起。
这个通知时用Generic Alert格式，如果客户端发起的固件升级请求被实现，那么下面的客户端请求必须被支持。
4.1.1Generic Alert
消息必须遵循Generic Alert格式。
4.1.2Alert Type
设备发起的固件升级消息类型必须使用“org.openmobilealliance.dm.firmwareupdate.devicerequest”，用户发起的固件升级alert类型必须使用“org.openmobilealliance.dm.firmwareupdate.userrequest”。
4.1.3URI
如果指定了alert中的URI，则其必须指向在管理树中代表一单独固件升级管理对象的动态节点（譬如<x>）。当节点存在时，服务器就会检查管理对象表示的固件升级的有效性。如果不存在则会进一步被建议，服务器就会检查发起这次alert的终端相关的所有固件升级的有效性。服务器可以查询URI指明的管理对象的内容，只要有相关的升级被发现，服务器就应该发起一个固件升级。
4.1.4Data
Data元素是必须的。客户端厂商可以使用这个域来提供明确的实现数据。如果没有明确的实现数据，这个值需要被设定为空。
5 FUMO 应用（通常情况下）
5.1固件升级协议预览
固件升级协议指定了一系列标准命令（关联的参数和管理对象），也将在OTA固件升级中使用。OTA固件升级在处理发现、安全、下载、安装时需要特别的留意。
OMA DM在无线设备管理领域是最主要的标准。OMA Download [DLOTA]规范也为通常内容的下载提供了一套灵活的协议，仅仅通过一个分离的下载描述符来控制。下载过程是抽象的，即允许用户使用OMA DM（E.g., Add/Replace）也允许任何适合的下载机制（用OMA Download [DLOTA]下载协议描述的下载）。
为了获取OTA固件升级，协议必须支持下面的流程：
- 固件升级步骤1：固件升级开始
- 固件升级步骤2：设备信息交换
- 固件升级步骤3：固件下载
- 固件升级步骤4：固件安装
- 固件升级步骤5：固件升级的状态通知
5.1.1场景1：经由OMA DM Download（Replace）的固件升级--Large Object
下面的例子展示了如何使用OMA DM协议通过DM Replace命令来将固件的二进制包数据移动到终端设备上。
5.1.2场景2：经由可选下载机制方案的固件升级
下面的例子展示了OMA DM如何调用外部的二进制包数据，通过DM Replace命令来下载固件包：
5.1.2.1例子1：‘Exec’ on x/Download node + ‘Exec’ on x/Update node
服务器针对x/Download节点发出Exec命令，如果需要，服务器将在客户端发送下载通知给服务器后针对x/Update节点发出Exec命令。
5.1.2.2例子2：‘EXEC’ on x/DownloadAndUpdate node
服务器针对x/DownloadAndUpdate节点发出Exec命令，在DownloadAndUpdate操作完成后客户端发送一个最后的通知给服务器。
5.2协议定义
5.2.1固件升级步骤1：固件升级开始
为了开始任何一个固件升级，设备都需要打开一个到服务器的数据连接。下面的机制能被支持来开始一个固件升级流程：
用户发起的升级由于并不需要特殊的标准所以没有放到这个规范中，推荐的做法是通过设备上的菜单或是服务代码。用户发起的升级流程将简单的打开一个OMA DM会话。
对于网络发起的升级来说，OMA DM 管理端提供了一个框架通过发送一个Notification Initiation Alert”给客户端来触发客户端开启数据会话。It is the intent of the Firmware Update Protocol to leverage General Package#0 as specified in the OMA DM Notification Initiation Session document [DMNOTI].OMA DM 指定使用WAP Push并且制定一个可接受的格式来发起这个固件升级。
5.2.2固件升级步骤2：设备信息交换
为了让设备能够正确地做固件升级，一个最小集合的设备信息标准被客户端发送到了服务器。为达到固件升级的目的，这个最小集合的设备信息是对每一个OMA DM管理会话都是永久的DevInfo参数[在DMSTDOBJ, Section 5中指定]。
注意：下一部分描述的固件下载流程的安装必须在一个可选的用户交互以后进行信息交换。一个OMA DM “alert”命令将被用来传输用户确认信息。
5.2.3固件升级步骤3：固件下载
固件下载可以通过OMA DM Replace命令（Large Object）或者外部的数据包文件下载来开启。这两种方式各有利弊，所以依赖于软件提供商和设备制造商来共同决定选择一个首选的实现。协议建议两种方式都支持。
请参考附件D查看更进一步的细节信息。
5.2.4固件升级步骤4：固件安装
预期在市场上会有很多产品来在设备上进行固件升级。固件升级规范的目的是为了规范设备和无线网络解决方案的互操作性，所以这个规范并不处理独立于网络之外的固件升级的处理。换句话说，这个规范为固件安装提供需求来获取可以接受的用户经验。
5.2.4.1在OMA DM Download后的固件安装（Large Object）
下面的这个Exec命令在固件已经使用OMA DM Replace下载到Pkgdata元素的情况下发起这次升级流程：
<Exec>
<CmdID>3</CmdID>
<Item>
<Target>
<LocURI>.x/Update</LocURI>
</Target>
</Item>
</Exec>
5.2.4.2可选下载方式的固件安装（外部数据下载）
对于外部二进制固件升级包下载方式（像OMA v1.0 Download的描述符），推荐的方式是提供正确的安装参数要由于使用Exec命令发起下载操作。
当升级操作完成升级包不再需要的时候，升级包将从对象存储中删除。设备的管理客户端可以选择在升级成功或失败结束后立刻删除升级包，也可以不管什么时候服务器提示删除的时候删除。
5.2.5固件升级步骤5：固件升级状态的通知
在固件升级流程完成的时候，设备通知服务器固件升级的结果状态。这个是通过一个连续的客户端或者服务器发起的OMA DM会话来确保管理服务器被通知了这个结果状态。
客户端通过Generic Alert [DMPRO]提供一个结果代码给服务器。
OMA DM协议提供的Generic Alert [DMPRO]命令将被OMA-DM客户端用来通知给DM服务器结果代码的值。
5.2.5.1非致命的结果代码
对于非致命的升级失败，终端用户可以用一种可操作的模式提供失败指示和终端号码。
另外就像上面的结果代码表中列出的一样，./FwUpdate/x/State元素会提供更多的信息。
5.2.5.2致命失败
致命的失败将很可能导致设备不可操作，所以就不可能提示终端用户或是通知服务器这次失败。因为这个原因，实现并没有提供一个高层次的错误容错机制在这方面。
（完）
（附件信息请直接查看协议）
疑问：我们知道当升级完成后，设备会重新启动，然后设备上的客户端会开启一个新会话向服务器报告升级状态，我们知道这个alert是1226，其内容是
<Alert>
<CmdID>2</CmdID>
<Data>1226</Data> <!-- Generic Alert -->
<Correlator>abc123</Correlator>
<Item>
<Source><LocURI>./SyncML/Sample</LocURI></Source>
<Meta>
<Type xmlns="syncml:metinf">
Reversed-Domain-Name: org.domain.samplealert
</Type>
<Format xmlns="syncml:metinf">xml</Format>
<Mark xmlns="syncml:metinf">critical</Mark> <!-- Optional -->
</Meta>
<Data><!-- Client Alert Data Goes Here -->
</Data>
</Item>
</Alert>
这里面并没有地方标示我这个升级结果是针对哪次的升级，也就是如果两次升级同时完成，我怎么知道这个是通知的那一个升级呢？虽然上面已经说过使用一个连续的alert来通知，这种情况会极少出现，但是怎么也要考虑吧？
现在已经实施的SmartDM项目的做法是确保每次对一个终端（号码）只存在一个操作来解决，也就是从服务器端就杜绝了一个设备同时做两种或者两个操作的可能。
但是我在Bindu的培训中好像听说过，以后会在这个alert 1226中增加各自上次操作会话ID来区分到底是对那个操作的回复，这样就在客户端解决了这个问题，但是我现在在OMA DM 1.2的协议里面没有找到这个。
相关推荐
3d赛车游戏
OMA DM Protocol FOMU1.0文档
pythonrifa EL PROFE SE LA FUMO Y NOS PONE HACER COSAS QUE NO SE QUE SIGNIFICAN
4.2 协议介绍 3 4.2.1 OMA DM标准 3 4.2.2 FUMO标准 3 4.2.3 OMA Download标准 3 4.2.4 OMA CP标准 3 4.3 业务分类 3 4.3.1 按业务目标分类 3 4.3.2 按承载网络分类 4 4.3.3 按发起方式分类 4 4.4 业务使用 4 4.4.1 ...
研究结 果表明:结合超声雾化技术的液体除湿系统达到同样的除湿效果,液气比(即液体与气体的质量比)大大降低,是 Fumo填料塔式实验中液气比的1/5;推荐气液混合管道的长度为2~4 m,雾化颗粒粒径为20 μm左右;除雾器推 荐
Firmware Update Management Object 教程和架构，用于固件空中升级