数据资源传输的方法和设备的制作方法

文档序号:7611351阅读:228来源:国知局
专利名称:数据资源传输的方法和设备的制作方法
技术领域
本发明实施例涉及网络通信领域,并且更具体地涉及数据资源传输的方法和设 备。
背景技术
轻量级应用层协议(ConstrainedApplication Protocol,简称 “CoAP”)主要是 用于物联网(Machine to Machine,简称“M2M”)的场景中,比如家庭控制器、楼宇自动化、 智能能源、传感器网络等。在这样的环境中,这些机器的功能比较简单,一般处理器只有8 位,存储空间小,不支持复杂的传输协议,数据传输速率也较低。CoAP提供一种请求/响应 的交互模式,支持内嵌的资源发现,包括关键的网页概念,比如统一资源标识(URI)和内容 类型。CoAP可以很容易地翻译到超文本链接协议(HTTP),用于集成到网络中。基于CoAP 传输数据的传统方案中不计算数据资源的准确容量,无法评估分包的精确数目,因此无法 并发获取数据资源,造成传输效率低下。

发明内容
本发明实施例提供了一种数据资源传输的方法和设备,能够支持在CoAP中提高 传输效率。在本发明的实施例中,提出了一种在物联网系统中基于轻量级应用层协议提高传 输效率的方法,可以通过分片来传输节点的数据资源,包括获取节点的数据资源容量信 息,资源容量信息为待传输数据容量大小;向节点发送携带第一分片选项的请求消息,其中 第一分片选项包括推荐的分片容量;接收节点携带第二分片选项的响应消息,其中第二分 片选项包括确定的分片容量,确定的分片容量小于或等于推荐的分片容量;根据确定的分 片容量以及节点的数据资源容量信息,分片传输节点的数据资源。在本发明实施例中,提供了一种在物联网系统中基于轻量级应用层协议通过分片 传输节点的数据资源的方法,接收携带第一分片选项的请求消息,其中第一分片选项包括 推荐的分片容量;发送携带第二分片选项的响应消息,其中第二分片选项包括确定的分片 容量,确定的分片容量小于等于推荐的分片容量;根据确定的分片容量,传输节点的数据资 源。在本发明实施例中,提供了一种在物联网系统中基于轻量级应用层协议通过分片 传输节点的数据资源的客户端设备,客户端设备包括获取单元,用于获取节点的数据资源 容量信息;发送单元,用于发送携带第一分片选项的请求消息,其中第一分片选项包括推荐 的分片容量,接收单元,接收携带第二分片选项的响应消息,其中第二分片选项包括确定的 分片容量,确定的分片容量小于等于推荐的分片容量;传输单元,用于根据确定的分片容量 以及节点的数据资源容量信息,分片传输节点的数据资源。在本发明实施例中,提供了一种在物联网系统中基于轻量级应用层协议通过分片 传输节点的数据资源的服务器设备,服务器设备包括接收单元,用于接收携带第一分片选项的请求消息,其中第一分片选项包括推荐的分片容量,发送单元,用于发送携带第二分片 选项的响应消息,其中第二分片选项包括确定的分片容量,确定的分片容量小于等于推荐 的分片容量;传输单元,用于根据确定的分片容量,传输节点的数据资源。根据本发明实施例,可以获知需要传输的节点的数据资源的容量信息,并通过分 片容量协商确定传输数据时使用的分片容量,由此可以实现传输过程中错误率降低,并且 可以并发地传输数据。在本发明实施例中,提供了一种在物联网系统中基于轻量级应用层协议的节点的 数据资源传输方法,发送携带响应方式选项的请求消息,其中响应方式选项表示以下响应 方式至少其中一项一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟 的多个响应;接收根据响应方式选项生成的响应消息。在本发明实施例中,提供了一种在物联网系统中基于轻量级应用层协议的节点的 数据资源传输方法,接收携带响应方式选项的请求消息,其中响应方式选项表示以下响应 方式至少其中一项一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟 的多个响应;发送根据响应方式选项生成的响应消息。在本发明实施例中,提供了一种在物联网系统中基于轻量级应用层协议传输节点 的数据资源的客户端设备,包括发送模块,用于发送携带响应方式选项的请求消息;接收 模块,用于接收根据响应方式选项生成的响应消息。在本发明实施例中,提供了一种在物联网系统中基于轻量级应用层协议传输节点 的数据资源的服务器设备,包括接收模块,用于接收携带响应方式选项的请求消息;发送 模块,发送根据响应方式选项生成的响应消息。根据本发明实施例,可以对响应方式进行指示,并根据所指示的响应方式接收响 应消息,这样便于请求方进行会话处理,以提高传输效率,比如在指示延迟响应时间的情 况下,避免请求方一直等待响应消息,可以在指示的延迟时间过期后,提前结束会话;在请 求方指示立即响应时,如果在请求方自定义的超时时间内,不能接收到响应消息,也可以提 前结束会话;在指示延迟的多次响应时,请求方可以保存资源订阅的信息,以便于接收多个 推迟的响应。


为了更清楚地说明本发明实施例的技术方案,下面将对实施例或现有技术描述中 所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实 施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附 图获得其他的附图。在附图中图1是本发明一种实施例的传输数据的方法的流程图;图2是本发明一种实施例的网关从传感器获取数据资源的具体实现过程的流程 图;图3是本发明一种实施例中改进的分片选项的结构图;图4是本发明一种替代实施例的网关从传感器获取数据资源具体实现过程的流 程图;图5是本发明一种替代实施例中改进的分片选项的结构图6是本发明一种替代实施例的网关从传感器获取数据资源的具体实现过程的 流程图;图7是本发明一种替代实施例中改进的分片选项的结构图;图8是本发明一种实施例的网关向传感器发送数据资源的具体实现过程的流程 图;图9是本发明一种实施例的客户端设备的框图;图10是本发明一种实施例的服务器设备的框图;图11是本发明一种实施例的传输数据的方法的流程图;图12是本发明一种实施例的传输数据的客户端设备的结构图;图13是本发明一种实施例的传输数据的服务器设备的结构图。
具体实施例方式下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完 整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发 明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施 例,都属于本发明保护的范围。CoAP是基于用户数据报协议(User Datagram Protocol,简称“UDP”)进行传输, 是基于无连接的消息处理模式。其交互模式可以是同步的响应,也可以是异步的响应。消 息类型可以是需要确认的消息(Confirmable)、不需要确认的消息(Non-confirmable)、 确认消息(Acknowledgement)、重置消息(Reset)。可以通过消息标识(Message ID)来关 联一对请求和响应。CoAP支持的方法有四个获取资源(Get)、更新资源(Put)、创建资源(Post)和 删除资源(Delete)。资源通过表述性状态转移(ItepresentationalState Transfer,简称 “REST”) URI来识别。我们通常称资源的拥有方为节点或服务器,包括但不限于传感器、控制 器、端点(End-point)等,请求资源方为客户端,包括但不限于网关(Proxy)、网络侧设备。CoAP协议支持不同的选项(Option),用以解释CoAP消息体中数据的语义,比如 Block(分片),Location (位置)、T0ken (令牌)选项等,不同的选项支持不同的功能,并且 可以通过定义新的Option来扩展新的功能。CoAP支持分片选项(Block Option),主要用于将较大的资源进行分片传输,以适 应于低带宽传输的应用场景。Block选项可以为1个字节、2个字节或3个字节,依据分片 数目的容量所需要的长度进行选取。传统方案中不计算数据资源的准确容量,无法评估分包的精确数目,因此无法并 发获取。另外也不知道资源是静态的还是动态的。在以下描述中,通常称资源的拥有方为服务器,以传感器作为示例,请求资源方为 客户端,以网关作为示例。但是,传感器或者网关并不用作对服务器或者客户端的限制。由于不知道目标资源的精确容量,网关在<Get>命令中使用Block Option时,只 能按顺序来获取,即选获取Block 0,等Block O返回时,再获取Blockl,一直到最后一个 Block。不能并发地发送<Get>请求。Block选项的字段结构一般包括NUM字段,M字段和SZX字段,其中
NUM表示分片的顺序序号,可以是4 20位的无符号整型数字。0表示第一个分 片。M 用一个比特位来表示当前分片后面是否还有其他分片,其值为1表示后面还有 分片,为0表示后面没有分片,即为最后一个分片。SZX:用于表征分片容量,其计算公式为分片容量=2~(SZX+4),即2的(SZX+4) 次方。由于SZX由3个比特位来表示,其值可以为0 7,所以分片容量的取值范围2~4 2~11,g卩 16 2048。对于Block选项的使用说明如下在<Get>请求中,Block选项的NUM字段给出当前请求的分片的序号,并且当分片 序号为O时,SZX给出网关建议的每个分片的容量。在<Get>响应中或是<Put>/<P0st>请 求中,Block选项的NUM字段描述当前传输的分片的序号,M字段表明后面是否还有后续分 片。在<Put>/<Post>响应中,Block选项的NUM字段表明当前响应的分片序号。当网关使用<Get>方法获取第一个分片(Block)时,NUM被设置为0,并携带建议 的分片容量(即SZX),传感器节点可以选择同意建议的分片容量,或是选择一个比建议分 片小的分片,并在响应中返回,同时,在响应中返回第一个分片的数据。本发明考虑网关事先获知目标资源的精确容量,则网关可以选择是否用Block Option来发送资源获取的请求,也可以实现并发请求,即在请求BlockO的同时,也可以请 求Block 1,而不必等待。在请求Block的顺序上也可以灵活处理。简单设计方案中,Block Option有三个选择,可以是一个字节,可以是2个字节, 也可以是三个字节,依据资源的容量不同,分片(Block)的数量容量不同,所需要的长度也 不一样。协议规定,除了最后一个分片外,分片的容量必须相同,但每次传输中,还是每次都 需要携带M位(表明后面是否还有分片)和SZX (分片的容量)。每次在请求和响应中,M位和SZX位都需要传送,而实际上,除了最后一个分片外, M位和SZX的值每次都是相同的,重复的传输浪费传输资源。重复发送SZX的目的假定双方 都不保存协商后的SZX,第一次响应中携带的是协商后的SZX,网关从响应中获取并再次在 请求中发送,从而网关和传感器都不需要保存状态。在一次的请求响应回合中,共浪费一个 字节,如果分片数目很多时,浪费的字节就很多了,对于M2M设备,传输资源是受限的,这个 传输资源的浪费是很可观的。假设要传送的数据为64M的话,每个Block的负载(payload) 容量为IOMbyte则发送的block条目数为65536。则发送的Block选项按照字节来分的 个数为(1) 一个字节16 个(2)两个字节4080个(3)三个字节61440个如果M和SZX可以不发送,则请求加上响应能够节省的数据为65536字节(byte), 即64K数据。另外,如果这两个字段不要,则NUM字段可以用满所有位(bit),则需要发送的 数据包的数目变更为(1) 一个字节256 个(2)两个字节65280个
此时不需要发送3个字节的结构,因此还可以节省数据为6144(^2bytes, 即60K数据。则总共节省数据位1MK,节省数据率0.189%。头域节省百分比为 (16+4080*2+61440*3-256-65280*2) / (16+4080*2+61440*3) = 61680/192496 = 32%。节省数据量的公式T为总的Block数量,S为分片容量(Block Size),节省的流量的百分比(只比较 头域)T < 16时无节省;两者都是一个字节;16 < T < 256时1_T*1/(16*1+(T-16)拉),简单设计方案需要2个字节,优选方
案只需要一个字节;256 < T < 4096 时1_056*1+(Τ_256>2))/(16*1+(Τ_16>2),简单设计方案需 要2个字节,优选方案需要2个字节;4096 < T < 65256 时1_ (256氺 1+(4096 — 256)氺2+(Τ — 4096)氺3) ) / (256*1+ (Τ-256) *2),简单设计方案需要3个字节,优选方案需要2个字节。T > 65256时,无节省,本发明优选方案实施例和简单设计方案都需要3个字节。简单设计方案中,使用Put/Post命令时,分片容量协商缺乏效率。在Put/Post请 求中,对于第一个分片,需要发送第一个分片的数据和推荐的分片容量,如果传感器节点选 择不一样的分片容量,网关需要按照传感器的分片容量进行重新发送,则上次发送的分片 数据被浪费掉了。而且,网关在使用Put/Post请求基于分片选项发送容量大的资源时,事 先无法告知传感器资源容量信息,在传输过程中,传感器边接收,边缓存所接收的资源,如 果传感器发现存储空间不够,而资源又未传输完成时,只能发送回一个413的错误状态码, 表示请求的资源太大,结束此次传输。此前传输的部分资源则没用了,传输资源被浪费了。 如果网关能够在第一个分片消息中告知传感器所要传输的资源的容量信息,传感器则可以 比较资源容量信息与存储容量,如果容量不足,提前返回413 “请求的资源太大”的状态码, 来结束资源传输,以此来达到节省传输资源的目的。互联网上的断点续传,也就是要从文件已经下载的地方开始继续下载。网关在向 传感器请求数据的时候,要多加一条信息来表示请求下载数据的范围(Range),表明从哪里 开始。比如,网关用浏览器来传递请求信息给Web传感器,要求从2000070字节开始GET/down. zip HTTP/1. 0User-Agent :NetFoxRange :bytes = 2000070-Accept :text/html, image/gif, image/jpeg,氺;q = . 2,氺/氺;q = . 2其中,RANGE :bytes = 2000070-,这一行的意思就是告诉传感器down, zip这个文 件从2000070字节开始传,前面的字节不用传了。这种方案的缺点是,没有分片机制,不支持分片容量的协商,也不支持分片总数的 协商。本发明实施例考虑了在分片传输过程中,进行分片容量和/或分片总数的协商。为 此本发明提供了一种数据分片传输的方法,可以获取目标数据资源的精确容量,进行分片 容量的协商,获取分片总数,并根据分片总数进行数据资源传输。以下参照图1具体说明本发明一种实施例的流程。图1是本发明一种实施例的流程图。在SllO过程中,获取节点的数据资源的容量信息。如果是网关从传感器获取数 据,则节点的数据资源容量信息保存在传感器上。网关可以通过请求消息,向传感器获取节 点的数据资源的容量信息。如果是网关向传感器发送数据,则网关本地已经知道了节点的 数据资源的容量信息。获取节点的数据资源容量信息,是为下一步进行分片容量的协商并 确定分片总数做准备。接着,在S120的过程中,网关向传感器发送携带第一分片选项的请求消息,其中 所述第一分片选项包括推荐的分片容量。传感器在收到S120中发送的请求消息之后,根据 自身能力,确定本次数据资源传输过程中所使用的分片容量,并且传感器确定的分片容量 小于等于网关推荐的分片容量。在S130,网关接收携带第二分片选项的响应消息,其中所述第二分片选项包括确 定的分片容量,所述确定的分片容量小于等于所述推荐的分片容量。网关在接到确定的分 片容量之后,根据掌握的节点的数据资源容量信息,确定将要传输的节点的数据资源的分 片总数。然后,在S140,根据所述确定的分片容量以及所述节点的数据资源容量信息,分片 传输所述数据资源。根据本发明实施例,可以获知需要传输的数据资源的容量信息,并通过分片容量 协商确定传输数据时使用的分片容量,由此可以实现传输过程中错误率降低,并且可以并 发地传输数据。以下结合图2说明如图1所示实施例的具体实现过程。图2表示的是网关从传感 器获取数据的说明性示例,仅为说明本发明的构思,而不作为对本发明的限制。图2所示数据资源获取过程具体描述如下ES210 网关向传感器发送资源发现请求,即通过Get. /wellknown/core来获取传 感器上的资源列表。ES220 传感器向网关返回资源列表,以及资源指示信息;资源指示信息主要包括 资源的寻址信息(即URI)、资源名称、资源描述信息、内容类型等。本发明对资源指示信息 进行扩展,扩展的资源指示信息包括资源是动态资源还是静态资源的指示信息。ES230:网关根据传感器返回的资源列表,根据资源的指示信息,从中选择目标资 源,并根据识别标识(能唯一识别资源的信息,比如资源名称、URI等),获取目标资源。ESMO 传感器对目标资源容量进行判断,如果资源容量小于一个传输层消息包的 容量,则直接返回资源内容给网关;如果资源容量超过一个传输层消息包的容量,则返回资 源容量信息。可选地,传感器可使用分片选项,根据自身确定的分片容量,直接返回第一个 分片。后续客户端和传感器根据此确定的分片容量,使用分片选项传输如下的分片。在本发明一种替代实施例中,如果目标数据资源为动态数据资源,同时返回动态 数据资源指示给网关,并用413 “请求资源太大”的状态码指示网关使用Block选项来获取 资源。如果数据资源为动态资源,则指示信息中的资源容量表示的是当前的资源快照 (Snapshot)的容量信息,传感器需要缓存此快照数据;如果是静态资源,则指示信息中的 资源容量信息是精确的容量信息。本领域技术人员应该理解,如果数据资源为动态资源,则传感器可以发送资源快照的校验码,网关如果需要更新鲜的数据,可以后续再发送新的资 源获取请求。ES250:网关根据数据资源容量信息,判断需要使用分片选项,并发送携带分片选 项的请求消息,与传感器器进行分片容量协商,指示推荐的分片容量。ES260 传感器根据自身能力,确定分片容量,并将其返回给网关。可选地,传感器 同时返回分片总数。当然,由于网关已经获取了数据资源容量信息,分片总数也可以由网关 确定。需要说明的是,传感器确定的分片容量只能小于或等于网关推荐的分片容量。ES270 网关从1 一直到分片总数,依次向传感器发送请求,请求获取与分片序号 对应的数据资源的分片数据。ES280 传感器根据确定的分片容量,返回该分片序号及与该分片序号对应的数据 资源的分片数据,直到完全传输完毕。根据本发明的一种优选实施例,ES270中可以实现并行处理,即网关可以同时请求 获取多个分片消息,而不需要等待传感器返回对前一个分片请求消息的响应消息。ES210至ES240的代码例如为REQ =GET/. well-known/core-—发送请求到默认的URI,即根目录获取资源列表;RES :2000K-响应标识获取成功,并携带了 2组资源指示信息;</sensors/temp> ;ct = 41 ;n = ‘‘ TemperatureC",--温度资源,内容类型 41, 名禾尔为 TemperatureC ;</sensors/light> ;ct = 41 ;n = “ LightLux"—灯光资源,内容类型 41,名称 为 LightLux ;</sensors/firmware> ;ct = 52 ;η = “ firmware“ ;snapshot = 0__ 固件资源, 内容类型52,名称为firmware,非动态资源;</sensors/log> ;ct = 52 ;n = “ log" ;snapshot = 1—固件资源,内容类型 52, 名称为log,动态资源,当前数据为快照snapshot ;REQ :GET/sensors/firmware-请求固件资源RES 413 "Request Entity Too Large,,Size :88000. 413 状态码表明请求的资源 太大,其精确容量为88000字节。如果数据资源为动态资源,即数据资源在传输的过程会动态变化,例如可以采用 以下两种方案实施处理(1)在开始传送数据资源时,对该资源建立快照(Snapshot),即缓存此刻该数据 资源的容量信息,并传输这个容量信息,不管后续的变化;对应上述方案。(2)如果数据资源在传输过程中被修改,传感器可以在任意一个获取数据资源的 请求消息的响应消息中,返回错误码,指示数据资源已更改,网关需要重新获取。可选地,网关和传感器在消息交互中,增加认证信息。认证信息中可包含身份标识 (ID)、基于身份标识和密码(Password)算出来的密钥信息(Digest)。身份标识和密码可以 是预先配置给网关和传感器双方。配置过程例如,密钥的算法可以为Digest = MD5(ID :Password),即对ID和Password组成 的字符串使用MD5算法进行哈希(Hash),Hash的值为Digest。发送方发送ID和Digest, 接收方根据接收到ID和预先存储的I^assword,根据同样的算法得出Digest,与发送方发送的Digest进行比较,如果一致,则认证通过。网关从传感器获取数据资源时,如图2所示,需要知道数据资源容量信息。根据本 发明一种实施例,网关可以采用如下方案来获取存储于传感器的数据资源容量信息。(1)扩展链接格式(Link-format)关键字在Link-format中,扩展一个关键字,_sn,或-snapshot,用于在获取数据资源请 求的响应中,表明资源数据是否是快照数据。如果此参数不存在,或其值为0,表明是静态资 源,如果此参数的值为1,则表明是当前数据是动态资源,获取的数据是当前的快照。静态资 源是指一段时间内相对稳定的资源,即资源内容不会频繁更改。具体含义可以在标准中进 行定义。在本发明中,主要指资源的值不改变的情况。还扩展关键字-asz,表明资源的准确容量的信息。消息实例网关向传感器发送资源发现的请求REQ =GET/. well-known/core-—发送请求到默认的URI,即根目录获取资源列表传感器向网关发送资源的响应RES :2000K-响应标识获取成功,并携带了 2组资源指示信息</sensors/temp> ;ct = 41 ;η =〃 TemperatureC〃,--温度资源,内容类型 41, 名禾尔为TemperatureC</sensors/light> ;ct = 41 ;n = “ LightLux"—灯光资源,内容类型 41,名称 为 LightLux</sensors/firmware> ;ct = 52 ;n = “ firmware “ ;asz = 65000 ;snapshot = 0-固件资源,内容类型52,名称为firmware,非动态资源,精确容量为65000字节;</sensors/log> ;ct = 52 ;n = “ log" ;asz = 88000 ;snapshot = 1—
源,内容类型52,名称为log,动态资源,当前数据为快照snapshot,其精确容量为88000字 节;此响应消息是封装在CoAP消息的消息体中的,接收方(即网关)根据 Link-format标准中的规定进行解析。(2)增加状态码在收到网关的数据资源获取请求时,如果资源太大,一个包传送不下,传感器用状 态码来通知网关,用于表明,资源太大,需要用Block Option来请求。比如,可以规定状态码413,用于表明当前数据资源容量过大,指示网关在请求中 用Block选项。可以根据需要规定其他的状态码,以用于表示其他含义,用于其它目的。消息实例网关向传感器发送资源获取的请求GET/sensordata传感器向网关发送带状态码的响应ACK 413(状态码,表明数据资源容量太大)(3)在CoAP的头字段(Header)中增加一个表明容量(Size)的选项(Option)网关在请求中,可以用容量选项(Size Option)来指示传感器,让传感器返回数据 资源的容量;传感器在响应中,用Size Option来指明数据资源的容量。
或者是,即使网关没有Size Option的指示,传感器也在响应中用SizeOption指 明资源容量,尤其是资源比较大的情况下,传感器应该指示。如果资源较小,传感器直接在消息体(Body)中返回资源数据,则网关应该以资源 数据的实际容量为准,Size Option中表明的资源容量可以用于核对。如果资源较大,传感器不返回资源数据,只用Size Option返回数据的容量,同时 用状态码指示给网关,让网关发起新的请求,用Block Option来请求。Size Option的代码可以为16,数据类型为整型,数据长度为1 4个字节,数据 单位为字节。Size Option主要用于<Get>方法的响应中,<Put>/<P0st>方法的请求中,用 于表示资源的容量;如果是在<Get>方法的请求中,其值没有实际的意义,推荐置为0。消息实例网关向传感器发送资源获取的请求GET/sensordata传感器向网关发送带状态码的响应ACK+413+Size 51200 (50K 字节)以下结合图3说明如图1所示实施例的具体实现过程。图3表示的是网关向传感 器发送数据的说明性示例,仅为说明本发明的构思,而不作为对本发明的限制。当网关使用<Get>方法获取第一个分片(Block)数据时,NUM字段被设置为0,并 携带推荐的分片容量(即SZX),传感器可以选择同意推荐的分片容量,或是选择一个小于 等于推荐的分片容量的分片容量,并在响应中返回,同时,在响应中返回第一个分片的分片 数据。因此,在NUM字段为0时,<Get>请求有双重语义,一是获取第一个分片数据,二是进 行分片容量的协商。这样带来协议在处理上的二义性,而且无法携带数据容量等信息。本发明实施例对此进行了改进,在本发明的一种实施例中,网关在<Get>方法的 请求中使用Block Option时,如果NUM字段被设置为0,表示双方只进行分片容量的协商, 以及分片总数的协商。即传感器在响应中,使用NUM字段返回分片总数,使用SZX字段返回 传感器确定的分片容量。M字段可以去掉,节省一个Bit,用于NUM字段。因为请求方,例如 网关知道分片总数,所以从分片的NUM字段就可以知道该分片是否是最后一个分片,因此 就不需要再使用M字段。在这种情况下,如果请求获取第一个分片的分片数据,则将NUM设 置为1,依次类推。需要说明的是,如果网关发送第一个请求时,不知道数据资源的容量,所以Block Option可以使用一个字节,如果传感器的数据资源较大,分片数目较大,则传感器可以在响 应中使用二个字节或者三个字节来返回分片总数。当Block Option为2个字节时,其设计成SZX字段占用第二个字节的最后三位, 表示分片容量;NUM字段占用第一个字节加上第二个字节的前5位,表示当前分片序号;如 果是在NUM为0的请求对应的响应消息中,则表示分片总数。本领域技术人员理解,可以用 消息标识(Message ID)来关联请求与响应,即请求和响应中都携带唯一的事务标识,这样 传感器就能理解此响应消息是用于返回分片总数。以下举例说明分片容量协商过程,消息实例为网关向传感器发送资源获取的请求GET 00000101 (NUM为0,SZX为101,即5,表示分片容量为2的9次方,即512)
传感器向网关发送的响应ACK 10000100 (NUM为:10000,即总分片数为32,SZX为100,即4,表示分片容量为 2的8次方,即256)此设计省掉了一个比特位(Bit),即把M位给省掉了,技术优势是节省了数据流量 并且对现有设计的改动不大。在这种实施方式中,分片容量(SZX)字段每次仍然要发送。在现有技术中,分片容量(即SZX字段)每次都要发送,不管是在请求消息中还是 响应消息中,除了第一个分片和最后一个分片中使用的分片容量可能不一样之外,其他的 分片容量全部都是一样的。重复互相传输相同的NUM字段浪费了传输资源。在本发明实施例中,网关在<Get>方法的请求中使用Block Option时,如果NUM 被设置为0,表示双方只进行分片容量的协商,以及分片总数的协商。即传感器在响应中,使 用NUM字段返回总的分片数,使用SZX字段返回传感器确定的分片容量。并且网关和传感 器双方存储所确定的分片容量,用于之后的分片数据传输消息。除了最后一个分片数据之 外。网关在后续<Get>方法的请求中,只发送所请求的当前分片序号,而不发送已经确定并 保持不变的分片容量,而且传感器在响应消息中,也只发送当前的分片序号和与该分片序 号对应的分片数据,不再发送分片容量。在这种情况下,NUM为1时,表示请求第一个分片 的分片数据,依次类推。以采用<GET>命令从传感器获取数据资源为例,说明上述实施例,如图3所示,新的Block Option的设计如下其中结构(1)用于NUM为0的情况在<Get>请求中,NUM为0,SZX是第二个字节,表示分片容量,TotalNumber表示 分片总数,在请求时不使用,不需要携带;在<Get>响应中,NUM为0,SZX表示传感器确定的 分片容量,Total Number表示分片总数。在现有技术中,分片容量的间隔比较大,比如2048、1024、512,不够灵活。而实际 上,512对于一个Block来说,比较小,最好是刚好能够放到一个UDP包里,即1472个字节。 本发明对此进行了改进,在一种实施例中,对于SZX,可以采取新的公式,比如(SZX+1)*8, 则其范围可以为8 2048,但是递减间隔为8。图3中的结构(2)和结构(3)用于<Get>请求中NUM不为0的情况,即获取分片 数据时的情况当NUM小于256时,用一个字节来表示分片序号,即结构O);当NUM大于2的8次 方(即256),小于2的16次方(即65536)时,使用两个字节来表示分片序号,即结构(3)。由于结构(2)中的NUM必须大于0,结构(3)中的NUM字段的前一个字节也大于0, 因此可以与结构(1)区分开,对于<Get>响应,NUM字段的值与请求中一样,也可以区分开。以下举例说明,消息实例为网关向传感器发送资源获取的请求GET 00000000 00000101 (NUM 为 0,SZX 为 101,即 5,表示分片容量为 2 的 9 次方, 即 512)传感器向网关发送的响应ACK 00000000 00000100 00000000 00010000(NUM 为 0, Total Number 为 10000, 即分片总数为32,SZX为100,即4,表示分片容量为2的8次方,即256)。
通过对Block Option重新设计,可以在每个请求或响应中至少减少发送4个比特 位,在分片较多的情况下,可以极大地提高传输效率,节省传输资源,同时也提高了网关和 传感器双方的处理效率。图4示出了本发明的一种替代实施例。在图4所示实施例中,ES410至ES420与 图2所示实施例的ES210至ES240相同,不再重复描述。在图4所示实施例中,在ES450,网关向传感器发送<GET>请求,使用分片选项进 行分片容量协商,指示网关推荐的分片容量。在ES460中,传感器选择并确定合适的分片容 量,用于将资源进行分片,并将所有分片数据主动推送给网关,而不需要网关再发<GET>请 求。在图4实施例获取数据资源过程中,分片选项的设计如图5所示,其中结构(1)用于网关向传感器发送<GET>请求,SZX字段表示网关推荐的分片容量, 传感器最终选择并确定的分片容量小于等于网关推荐的分片容量,NUM为0表示网关请求 完整资源,NUM不为0表示网关请求具体第NUM个分片数据,NUM不为0时传感器只能使用 SZX字段所指示的分片容量。结构(2)和结构(3)用于传感器向网关返回完整资源的分片响应消息,如果针对 某个具体分片数据请求的应答,不需要携带分片选项,结构(2)和(3)中的M字段表示是否 为最后一个分片,如果是M字段为0则表示最后一个分片,为1表示不是最后一个分片,NUM 字段表示传感器所返回的是第几个分片。以下举例说明。消息实例为网关向传感器发送数据资源获取的请求CON GET 00000000 00000101 (NUM 为 0,SZX 为 101,即 5,表示分片容量为 2 的 9 次 方,即512)传感器向网关发送的响应ACK 200 00000011 (NUM为1,M为1,表示发送的第一个分片,并且不是最后一个分
片,分片容量为SZX字段指定的容量);传感器继续向网关发送CoAP响应CON 200 00000101 (NUM为2,M为1,表示发送的第二个分片,并且不是最后一个分 片,分片容量为SZX字段指定的容量);网关返回对CON的ACK响应;传感器向网关发送最后一个分片CON 200 00000110 (NUM为3,M为0,表示发送的第三个分片,并且是最后一个分
片,具体分片容量由实际读出数据算出)。根据图4所示的实施例,在网关从传感器获取完整的数据资源时,仅需完成分片 容量的协商,而不用发送大量的分片数据获取请求,大大节省了数据传输流量。图6示出了本发明的另一种替代实施例。在图6所示实施例中,ES610至ES640与 图2所示实施例的ES210至ES240相同,因此不再重复描述。图6与图2所示实施例不同之处在于,在ES650,网关向传感器发送<GET>请求,请 求获取资源,使用分片选项,指示网关推荐的分片容量,此时NUM字段填充的值为0,表示请 求获取最后一个分片;在ES660,传感器响应网关请求,返回确定的分片容量以及最后一个分片的序号及与之对应的分片数据。由于最后一个分片序号对应分片总数,所以在ES670, 网关就可以依次或者并发获取其他分片数据的请求。在ES680,传感器根据确定的分片容 量,返回该分片的序号及对应的分片数据。ES670和ES680可以多次进行交互,直至分片数 据传输完毕。图6实施例中采用的分片选项如图7所示,例如采用两个字节的分片选项,仅包括 NUM字段和SZX字段。以下结合图6和图7举例说明,消息实例为网关向传感器发送资源获取的请求CON GET 00000000 00000101 (NUM 为 0,表示要求获取最后一个分片,SZX 为 101, 即5,表示推荐的分片容量为2的9次方,即512)。传感器向网关发送的响应ACK 00000000 01000101 (NUM 为 1000 即为 8,表示返回的是第 8 个分片,SZX 为 101
即5,表示确定的分片容量为2的9次方,即512);根据第一次的返回信息,网关已经知道了一共有8个分片,并且得到了第8个分 片的数据,网关继续向传感器发送CoAP请求,可以依次获取也可以并发获取剩下的分片数 据。以下消息实例为请求获取第一个分片的分片数据CON GET 00000000 00001101 (NUM 为 1,表示要求获取第一个分片,SZX 为 101,即 5,表示分片容量为2的9次方,即512);传感器返回对CON的ACK响应,即第一个分片的数据;网关可以依次或并发请求所有剩余分片,直到获取完所有的数据。根据图6所示的实施例,可以在分片容量协商的同时,获取最后一个分片的分片 数据,在后续分片数据获取过程中,所使用的分片容量均相同,因此可以结合前述优选实施 例的描述,网关可以在发送获取分片数据的请求时,不再发送SZX字段,而仅发送NUM字段, 由此可以节省数据流量,提高传输效率。图8示出了使用分片选项向传感器发送数据,例如使用资源创建(Post)或更新 (Put)请求时的实施例。以下结合图8进行具体描述。图8所示详细的流程说明如下ES810 网关向传感器发送资源创建(Post)或更新(Put)请求消息,利用Size选 项发送资源的容量信息,利用分片选项指示推荐的分片容量及分片总数,此处所述的分片 总数是基于推荐的分片容量和待发送的数据资源的容量计算出的,请求消息体中不携带具 体的资源数据。ES820 传感器如果愿意接收此数据,则返回状态码例如为100(即指示客户端继 续发送),同时向网关返回确定的分片容量,所述确定的分片容量只能小于或等于网关推 荐的分片容量;如果传感器不愿意接收此数据,则返回错误码指示客户端不要继续发送数 据。比如,传感器的存储容量不足以存储所指示的资源容量的数据,则返回413 "Request Entity Too Large” 的返回码。ES830:网关根据传感器返回的确定的分片容量,判断是否与推荐的分片容量相 同,如果相同,则跳转到ES360;如果不相同,则根据传感器返回的确定的分片容量信息,并 根据数据资源容量,重新计算分片总数。
ES840 网关重新向传感器发送确定的分片容量和重新计算的分片总数。ES850 传感器返回确定的分片容量。ES860 网关从根据分片序号从1 一直到分片总数,依次向传感器发送与分片序号 对应的数据资源的分片数据,直到完全传输完毕。ES870 传感器返回确定接收的消息,其中包含接收到的分片序号。根据本发明的一种优选实施例,ES860中可以进行并行处理,即网关可以同时向传 感器发送多个分片数据,而不需要等待传感器返回对前一个分片消息的响应消息。可选地, 根据本发明的一种优选实施例,网关和传感器在消息交互中,增加认证信息。认证消息的配 置和交互方式可以采用参照图2所述的相同方式。为了提高传输效率,节省数据流量,根据本发明另一种优选实施例,如前面针对 <GET>方法所述地那样,在使用<Put>/<P0St>方法的请求中,当NUM为0是,不再是发送第 一个分片数据,而是告知传感器推荐的分片的容量和分片总数。传感器可以返回响应告知 网关是否继续发送数据。传感器在响应中,使用NUM字段返回总的分片数,使用SZX字段返 回传感器确定的分片容量。并且网关和传感器双方存储所确定的分片容量,用于之后的分 片数据传输消息。除了最后一个分片数据之外。网关在后续<Put>/<P0st>方法的请求中, 只发送所请求的当前分片序号,而不发送已经确定并保持不变的分片容量,而且传感器在 响应消息中,也只发送当前的分片序号和与该分片序号对应的分片数据,不再发送分片容 量。在这种情况下,NUM为1时,表示请求第一个分片的分片数据,依次类推。在此情况下,分片选项的设计以及使用方式均类似于图3所示,以下参照图3来说 明。在<Put>/<P0St>请求中,NUM字段为0,SZX字段是第二个字节,表示推荐的分片容量, Total Number表示待发送的分片总数数;在<Put>/<Post>响应中,NUM字段为0,SZX字段 表示传感器确定的分片容量,Total Number没用,不需要携带;如果网关接收到的SZX字段 与发送的不一致,需要用新的SZX再次发送<Put>/<P0St>请求,并携带重新计算的分片总 数,传感器再发回响应。以后<Put>/<P0st>请求和响应中,不再携带SZX字段。通过对分片选项重新设计,可以在每个请求或响应中至少减少发送4个比特位, 在分片较多的情况下,可以极大地提高传输效率,节省传输资源,同时也提高了网关和传感 器双方的处理效率。另外,现有技术在每次分片传输的请求中,都需要携带所请求资源的统一资源标 识(URI,Unified Resource Identifier),通常URI都要占十几到几十个字节,重复的传输 会浪费传输资源,本发明设计使用Token (令牌)来关联分片传输的多个请求,只在第一个 分片消息中传送URI,在后续的分片传输请求中,只需要携带Token即可,由于Token通常是 1 8个字节,因此可以节省一定的流量。图9是本发明一种通过分片传输数据资源的客户端设备的实施例。图9所示客户 端设备900包括获取单元910,用于获取数据资源容量信息;发送单元920,用于发送携带 分片选项的请求消息,其中所述分片选项包括推荐的分片容量,接收单元930,接收携带分 片选项的响应消息,其中所述分片选项包括确定的分片容量;和传输单元940,用于根据所 述确定的分片容量以及所述数据资源容量信息,分片传输所述数据资源。根据本发明的一种优选实施例,所述客户端设备可以进一步包括存储单元950,用 于保存所述确定的分片容量。以便在数据资源传输过程中,不需要每次均发送SZX字段。
根据本发明的另一种优选实施例,所述客户端设备可以进一步包括认证单元960, 用于发送和接收认证信息。图10是本发明一种通过分片传输数据资源的服务器设备的实施例。图10所示服 务器设备1000包括接收单元1010,用于接收携带分片选项的请求消息,其中所述分片选 项包括推荐的分片容量;发送单元1020,用于发送携带分片选项的响应消息,其中所述分 片选项包括确定的分片容量;和传输单元1030,用于根据所述确定的分片容量,分片传输 所述数据资源。根据本发明一种实施例,发送单元1020还用于发送携带数据资源容量信息的消 息,以便于传输单元1030根据所述确定的分片容量和所述数据资源容量信息,分片传输所 述数据资源。根据本发明一种实施例,在接收到一次请求时,传输单元1030可以主动地分片传 输数据,而不需要客户端设备针对每个分片数据进行请求。根据本发明一种优选实施例,所述服务器设备可以进一步包括存储单元1040,用 于保存所述确定的分片容量。以便在数据资源传输过程中,不需要每次均发送SZX字段。根据本发明的另一种优选实施例,所述服务器设备可以进一步包括认证单元 1050,用于发送和接收认证信息。根据本发明实施例,网关可以获知目标资源的容量信息,用于决策是否用分片的 方式来获取资源,这样避免了出错的可能性,也可以实现并发地请求分片,提高数据请求的 效率,而且得知资源的容量也便于分配存储空间,计算分片的数量。通过对分片选项重新设计,可以在每个请求或响应中至少少发送4个比特位,在 分片较多的情况下,可以极大地提高传输效率,节省传输资源,同时也提高了双方的处理效 率。在现有技术中,在收到来自于客户端的请求后,服务器可以立即发回响应,也可以 先发回一个Ack (Acknowledgement)响应消息,表明接收到了请求消息,正在处理中,后续 等处理完后,再发送响应消息,即推迟的响应。另外,客户端可以订阅一个资源的改变,服务 器在接受客户端对某个资源的订阅后,一旦资源信息发生变化,就向客户端发回通知消息。现有技术不能满足如下的需求1、客户端在请求中指示服务器,自己需要哪种方式的响应;2、客户端要求服务器在某个规定的时间内发回响应;3、在通知消息的传送过程中,由于网络传输能力不稳定,可能服务器先发出的通 知消息,比服务器后发出的消息,到达客户端的时间要晚。这样,客户端后收到的资源信息 实际上是陈旧的信息,客户端需要有一种机制能够探测多个通知消息的顺序。图11是本发明一种实施例的流程图。在图11所示实施例中,在S1110,客户端向 服务器发送请求消息,该请求消息携带响应方式选项,所述响应方式选项可以是推迟响应 (Deferred Response)选项或者是令牌(Token)选项,用来指示服务器,客户端是否接收推 迟的响应。例如,所述相应方式选项表示一次性的立即响应、推迟的一次性的响应、推迟的 多个响应和取消推迟的多个响应。然后,在S1120,客户端可以接收根据响应方式选项生成 的响应消息。在现有技术中,在收到来自于客户端的请求后,服务器可以立即发回响应,也可以先发回一个Ack,表明接收到了请求消息,正在处理中,后续等处理完后,再发送响应消息, 即推迟的响应。另外,客户端可以订阅一个资源的改变,服务器在接受客户端对某个资源的 订阅后,一旦资源信息发生变化,就向客户端发回通知消息。在本发明的一种实施例中,例如可以采用一个字节的延迟(Deferred)选项来指 示响应方式,其中,可以使用前两个比特位(Bit)来表示,用C来表示C = 00 表示一次性的立即响应;C = 01 表示推迟的一次性的响应;C = 10 表示推迟的多个响应,即订阅;C= 11 表示取消推迟的多个响应,即取消订阅。对于客户端发起的关于某个资源的订阅,可以由客户端取消订阅,也可以服务器 取消订阅,比如服务器发回给客户端一个需要确认的响应消息,客户端在预定的时间内未 能确认,则服务器可以认为客户端失去连接,从而取消订阅。由于一个字节是8个比特位,多余的后6个比特位(假设其值为T)可以用于表示 推迟的一次性的响应的推迟时间或者推迟的多个响应的截止时间,即超过此时间后,自动 取消订阅。当C为01时,T表示推迟的一次性响应的推迟时间;当C为10时,T表示推迟 的多个响应的截止时间;当T为00或11时,T没有意义,置为0。对于这6个比特位,可以表示0 63之间的数值,假设为T,可以用2的T次方,来 表明这个时间长度,以秒为单位,即可以表示1 2~63秒。比如0:2"0 = 1秒;1:2~1 = 2秒;2:2"2 = 4秒;3 2"3 = 8 秒4 2"4 = 16 秒;…63:2"63 秒。在现有技术中,MaX_Age字段用于表明某个响应可以被缓存的最大时间,即表明响 应的新鲜度。本发明扩展这一字段的含义,可以在请求中用MaX_Age字段表示多个响应之 间的时间间隔的限制,比如多个通知消息不得高于此时间间隔,或者是不得低于此时间间隔。对于多个响应的顺序,可以用消息标识(Message ID)来区分。比如,规定消息标 识必须根据通响应的顺序来递增地生成,接收方根据消息标识的大小来判断响应的先后顺序。根据本发明的另一种实施例,可以使用Token(令牌)选项来指示响应方式,如果 "Token值为0,来表示立即的响应,如果"Token值不为0,则表示可以接受推迟的响应。根据本发明的另一种实施例,可以替代地或另外增加时间戳(Timestamp)选项, 与延迟选项单独或者相结合地来指示响应方式。具体来说,客户端可以在请求中携带时间 戳选项,所述时间戳选项包括一个截止时间的值,要求服务器在指定的时间内返回响应;服 务器在响应消息中,携带时间戳选项,表明响应消息生成的时间,这样,客户端可以基于时 间戳选项来判断响应消息的顺序。
在本发明一种实施例中,所述时间戳选项的设计方案可以用1 6个字节来表示, 如果表示的时间短,则用一个字节,如果时间长,则用3个字节或6个字节。具体表示方法 例如以下两种(1)用年、月、日、时、分、秒来表示,第一个字节表示年、第二个字节表示月,第三个 字节表示日,第四个字节表示小时,第五个字节表示分钟,第六个字节表示秒,对于年份,例 如可以以2000年为基础,其值表明2000年之后的第几年,比如为0时,表明是2000年,为 1时,表明是2001年,最多可以表示2063年。(2)三个字节全部用秒来表示,最大可表示214-1秒,大约是136年。由此,客户端可以知道返回的响应消息的顺序,避免数据传输延迟导致的错误。图12是根据本发明的一种传输数据资源的客户端设备的实施例的框图,其中所 述客户端设备1200包括发送模块1210,用于发送携带响应方式选项的请求消息;和接收 模块1220,用于接收根据所述响应方式选项生成的响应消息。参照图11所述的本发明的实施例所描述的过程和特征均适用于图12所示的客户 端设备。具体来说,例如,发送模块1210发送的请求消息中携带的响应方式选项可以是推 迟选项,例如可以为一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推 迟的多个响应。根据一种实施例,发送模块1210发送的请求消息中携带的响应方式选项可以表 示推迟的一次性的响应的推迟时间或者推迟的多个响应的截止时间。根据一种实施例,发送模块1210发送携带时间戳选项的请求消息,该时间戳表示 接收响应的截止时间;接收模块1220接收携带时间戳选项的响应消息,该时间戳表示响应 消息的生成时间。接收模块1220根据接收到的响应消息中的时间戳所表示的时间确定响 应消息的顺序。图13是根据本发明的一种传输数据资源的服务器设备的实施例,其中所述服务 器设备1300包括接收模块1310,用于接收携带响应方式选项的请求消息;和发送模块 1320,发送根据所述响应方式选项生成的响应消息。参照图11所述的本发明的实施例所描述的过程和特征均适用于图13所示的服务 器设备。具体来说,例如,接收模块1310接收的请求消息中携带的响应方式选项可以是推 迟选项,例如可以为一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推 迟的多个响应。根据本发明的一种实施例,接收模块1310接收的请求消息中携带的响应方式选 项可以表示推迟的一次性的响应的推迟时间或者推迟的多个响应的截止时间。根据本发明的一种实施例,接收模块1310接收的请求消息中的推迟选项表示推 迟的多个响应和推迟的多个响应之间的时间间隔,而发送模块1320发送的响应消息中的 推迟选项表示取消推迟的多个响应。根据本发明的另一种实施例,接收模块1310接收的请求消息中可以携带时间戳 选项,该时间戳选项表示接收响应的截止时间,而发送模块1320发送的响应消息中也可以 携带时间戳选项,所述时间戳选项表示响应消息的生成时间。本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单 元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这 些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专 业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不 应认为超出本发明的范围。结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的 软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器 (ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域 内所公知的任意其它形式的存储介质中。尽管已示出和描述了本发明的一些实施例,但本领域技术人员应理解,在不脱离 本发明的原理和精神的情况下,可对这些实施例进行各种修改,这样的修改应落入本发明 的范围内。
权利要求
1.一种在物联网系统中基于轻量级应用层协议通过分片传输节点数据资源的方法,其 特征在于,包括获取节点的数据资源容量信息,所述资源容量信息为待传输数据容量大小;向所述节点发送携带第一分片选项的请求消息,其中所述第一分片选项包括推荐的分 片容量;接收所述节点携带第二分片选项的响应消息,其中所述第二分片选项包括确定的分片 容量,所述确定的分片容量小于或等于所述推荐的分片容量;根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传输所述节点的数 据资源。
2.如权利要求1所述的方法,其特征在于,所述获取节点的数据资源容量信息包括发送获取节点的数据资源的请求;接收所述节点的数据资源容量信息和/或指示所请求的节点的数据资源容量太大的 状态码。
3.如权利要求2所述的方法,其特征在于,该方法还包括接收指示静态资源或动态数据资源的指示信息,如果是动态资源,则以当前快照形式 表示所述节点的数据资源容量信息。
4.如权利要求1所述的方法,其特征在于,所述发送携带第一分片选项的请求消息包括发送携带第一分片选项的请求消息,其中所述第一分片选项还包括节点的数据资源容 M.fn 息。
5.如权利要求ι所述的方法,其特征在于,所述发送携带第一分片选项的请求消息包括发送携带第一分片选项的请求消息,其中所述第一分片选项包括仅协商分片容量的指 不信息;所述接收携带第二分片选项的响应消息包括接收携带第二分片选项的响应消息,其中所述第二分片选项仅包括确定的分片容量。
6.如权利要求1所述的方法,其特征在于,所述发送携带第一分片选项的请求消息中,还携带所请求资源的统一资源标识和用于 关联分片消息的令牌;所述分片传输所述节点的数据资源的消息中,仅传输关联分片消息的令牌。
7.如权利要求1所述的方法,其特征在于,所述根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传输所述节点 的数据资源包括根据所述确定的分片容量以及所述节点的数据资源容量信息,依次或并行地分片传输 所述节点的数据资源。
8.如权利要求1所述的方法,其特征在于,所述根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传输所述节点 的数据资源包括传输携带第三分片选项的资源传输消息,其中所述第三分片选项仅包括分片序号,并 且所述资源传输消息携带与所述分片序号对应的所述节点的数据资源的分片数据。
9.如权利要求1所述的方法,其特征在于,所述发送携带第一分片选项的请求消息包括发送携带第一分片选项的请求消息,其中所述第一分片选项包括获取最后一个分片的 数据的指示信息;所述接收携带第二分片选项的响应消息包括接收携带第二分片选项的响应消息,其中所述第二分片选项包括分片总数,并且所述 响应消息携带与最后一个分片对应的所述节点的数据资源的分片数据;所述根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传输所述节点 的数据资源包括根据分片容量和分片总数获取与其他分片序号对应的所述节点的数据资源的分片数据。
10.如权利要求1所述的方法,其特征在于,还包括 发送携带认证信息的请求消息;接收携带指示认证通过的信息的响应消息。
11.如权利要求1所述的方法,其特征在于,发送携带第一分片选项的请求消息,其中所述第一分片选项包括分片总数,或者 接收携带第二分片选项的响应消息,其中所述第二分片选项包括分片总数。
12.—种在物联网系统中基于轻量级应用层协议通过分片传输节点的数据资源的方 法,其特征在于,接收携带第一分片选项的请求消息,其中所述第一分片选项包括推荐的分片容量, 发送携带第二分片选项的响应消息,其中所述第二分片选项包括确定的分片容量,所 述确定的分片容量小于等于所述推荐的分片容量;根据所述确定的分片容量,传输所述节点的数据资源。
13.如权利要求12所述的方法,其特征在于,所述方法进一步包括所述发送携带第二分片选项的响应消息包括,携带节点的数据资源容量信息, 所述根据所述确定的分片容量,传输所述节点的数据资源包括 根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传输所述节点的数 据资源。
14.如权利要求12所述的方法,其特征在于, 所述接收携带第一分片选项的请求消息包括接收携带第一分片选项的请求消息,其中包括节点的数据资源容量信息, 所述根据所述确定的分片容量,传输所述节点的数据资源包括 根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传输所述节点的数 据资源。
15.如权利要求13所述的方法,其特征在于,根据接收的节点的数据资源容量信息进 行判断,如果节点的数据资源容量信息大于自身的存储容量,发送指示节点的数据资源容 量太大的状态码。
16.如权利要求12所述的方法,其特征在于, 所述接收携带第一分片选项的请求消息包括接收携带第一分片选项的请求消息,其中包括获取最后一个分片的数据的指示信息; 所述发送携带第二分片选项的响应消息包括发送携带第二分片选项的响应消息,其中所述第二分片选项包括分片总数,并且所述 响应消息携带与最后一个分片对应的所述节点的数据资源的分片数据;所述根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传输所述节点 的数据资源包括根据分片容量和分片总数发送与其他分片序号对应的所述节点的数据资源的分片数据。
17.如权利要求13所述的方法,其特征在于,所述根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传输所述节点 的数据资源包括传输携带第三分片选项的资源传输消息,其中所述第三分片选项仅包括分片序号,并 且所述资源传输消息携带与所述分片序号对应的所述节点的数据资源的分片数据。
18.如权利要求12所述的方法,其特征在于, 所述接收携带第一分片选项的请求消息包括接收携带第一分片选项的请求消息,其中所述第一分片选项包括仅协商分片容量的指 不信息;所述发送携带第二分片选项的响应消息包括发送携带第二分片选项的响应消息,其中所述第二分片选项仅包括确定的分片容量。
19.如权利要求12或13所述的方法,其特征在于,所述根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传输所述节点 的数据资源包括根据所述确定的分片容量以及所述节点的数据资源容量信息,依次或并行地分片传输 所述节点的数据资源。
20.一种在物联网系统中基于轻量级应用层协议通过分片传输节点的数据资源的客户 端设备,其特征在于,所述客户端设备包括获取单元,用于获取节点的数据资源容量信息;发送单元,用于发送携带第一分片选项的请求消息,其中所述第一分片选项包括推荐 的分片容量,接收单元,接收携带第二分片选项的响应消息,其中所述第二分片选项包括确定的分 片容量,所述确定的分片容量小于等于所述推荐的分片容量;传输单元,用于根据所述确定的分片容量以及所述节点的数据资源容量信息,分片传 输所述节点的数据资源。
21.如权利要求20所述的客户端设备,其特征在于,所述传输单元依次或并发地分片传输所述节点的数据资源。
22.如权利要求20所述的客户端设备,其特征在于,所述设备还包括 存储单元,用于保存所述确定的分片容量。
23.如权利要求20所述的客户端设备,其特征在于,所述设备还包括 认证单元,用于发送和接收认证信息。
24.一种在物联网系统中基于轻量级应用层协议通过分片传输节点的数据资源的服务 器设备,其特征在于,所述服务器设备包括接收单元,用于接收携带第一分片选项的请求消息,其中所述第一分片选项包括推荐 的分片容量,发送单元,用于发送携带第二分片选项的响应消息,其中所述第二分片选项包括确定 的分片容量,所述确定的分片容量小于等于所述推荐的分片容量;传输单元,用于根据所述确定的分片容量,传输所述节点的数据资源。
25.如权利要求M所述的服务器设备,其特征在于,所述发送单元用于发送携带所述节点的数据资源容量信息的消息, 所述传输单元用于根据所述确定的分片容量和所述节点的数据资源容量信息,分片传 输所述节点的数据资源。
26.如权利要求24所述的服务器设备,其特征在于,所述接收单元用于接收携带第二分片选项的请求消息,其中包括节点的数据资源容量 fn息,所述传输单元用于根据所述确定的分片容量和所述节点的数据资源容量信息,分片传 输所述节点的数据资源。
27.如权利要求M所述的服务器设备,其特征在于,所述传输单元用于根据所述确定的分片容量和所述节点的数据资源容量信息,主动地 分片传输所述节点的数据资源。
28.如权利要求M所述的服务器设备,其特征在于,所述服务器设备还包括 存储单元,用于保存所述确定的分片容量。
29.如权利要求M所述的服务器设备,其特征在于,所述服务器设备还包括 认证单元,用于接收和发送认证信息。
30.一种在物联网系统中基于轻量级应用层协议的节点的数据资源传输方法,其特征 在于,发送携带响应方式选项的请求消息,其中所述响应方式选项表示以下响应方式至少其 中一项一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响 应;接收根据所述响应方式选项生成的响应消息。
31.如权利要求30所述的方法,其特征在于, 发送携带响应方式选项的请求消息包括发送携带响应方式选项的请求消息,其中所述响应方式选项还包括推迟的一次性响应 的推迟时间或者推迟的多个响应的最大时间间隔或推迟性响应的截止时间。
32.如权利要求30所述的方法,其特征在于, 接收根据响应方式选项生成的响应消息包括接收根据响应方式选项生成的响应消息,其中所述响应方式选项包括响应消息生成时间,所述方法还包括根据所述响应消息生成时间确定响应消息的顺序。
33.一种在物联网系统中基于轻量级应用层协议的节点的数据资源传输方法,其特征 在于,接收携带响应方式选项的请求消息,其中所述响应方式选项表示以下响应方式至少其 中一项一次性的立即响应、推迟的一次性的响应、推迟的多个响应和取消推迟的多个响 应;发送根据所述响应方式选项生成的响应消息。
34.如权利要求33所述的方法,其特征在于,接收携带响应方式选项的请求消息包括接收携带响应方式选项的请求消息,其中所述响应方式选项表示推迟的一次性的响应 或者推迟的多个响应,并且所述响应方式选项包括推迟的一次性响应的推迟时间或者推迟 的多个相应之间的时间间隔。
35.如权利要求33所述的方法,其特征在于,接收携带响应方式选项的请求消息包括接收携带响应方式选项的请求消息,其中所述响应方式选项还包括推迟的一次性响应 的推迟时间或者推迟的多个响应的最大时间间隔或推迟性响应的截止时间。
36.如权利要求34所述的方法,其特征在于,接收携带响应方式选项的请求消息包括接收携带第一响应方式选项的请求消息,其中所述第一响应方式选项表示推迟的多个 响应和推迟的多个相应之间的时间间隔;发送根据所述响应方式选项生成的响应消息包括发送携带第二响应方式选项的响应消息,其中所述第二响应方式选项表示取消推迟的 多个响应。
37.如权利要求33所述的方法,其特征在于,接收携带响应方式选项的请求消息包括接收携带第三响应方式选项的请求消息,其中所述第三响应方式选项包括接收响应的 截止时间。发送根据所述响应方式选项生成的响应消息包括发送携带第四响应方式选项的响应消息,其中所述第四响应方式选项包括响应消息生 成时间。
38.一种在物联网系统中基于轻量级应用层协议传输节点的数据资源的客户端设备, 其特征在于,包括发送模块,用于发送携带响应方式选项的请求消息;接收模块,用于接收根据所述响应方式选项生成的响应消息。
39.如权利要求38所述的设备,其特征在于,所述发送模块发送的请求消息中携带的 响应方式选项包括以下至少其中一项一次性的立即响应、推迟的一次性的响应、推迟的多 个响应和取消推迟的多个响应。
40.如权利要求38所述的设备,其特征在于,所述发送模块发送携带第一响应方式选项的请求消息,所述第一响应方式选项包括接收响应的截止时间;所述接收模块用于接收携带第二响应方式选项的响应消息,所述第二响应方式选项 包括响应消息的生成时间,所述接收模块根据所述响应消息的生成时间确定响应消息的顺序。
41.一种在物联网系统中基于轻量级应用层协议传输节点的数据资源的服务器设备, 其特征在于,包括接收模块,用于接收携带响应方式选项的请求消息; 发送模块,发送根据所述响应方式选项生成的响应消息。
42.如权利要求41所述的设备,其特征在于,所述接收模块接收的请求消息中携带的 响应方式选项包括以下至少其中一项一次性的立即响应、推迟的一次性的响应、推迟的多 个响应和取消推迟的多个响应。
43.如权利要求42所述的设备,其特征在于,所述接收模块接收携带第一响应方式选项的请求消息,所述第一响应方式选项包括推 迟的多个响应和推迟的多个相应之间的时间间隔,所述发送模块发送携带第二传输选项的响应消息,所述第二传输选项包括取消推迟的 多个响应。
44.如权利要求41所述的设备,其特征在于,所述接收模块接收携带第一响应方式选项的请求消息,所述第一响应方式选项包括接 收响应的截止时间;所述发送模块用于发送携带第二响应方式选项的响应消息,所述第二响应方式选项包 括响应消息的生成时间。
全文摘要
本发明实施例提供了一种物联网系统中数据资源传输的方法和设备。在物联网系统中基于轻量级应用层协议通过分片传输节点的数据资源的方法包括获取节点的数据资源容量信息,资源容量信息为待传输数据容量大小;向节点发送携带第一分片选项的请求消息,其中第一分片选项包括推荐的分片容量;接收节点携带第二分片选项的响应消息,其中第二分片选项包括确定的分片容量,确定的分片容量小于或等于推荐的分片容量;根据确定的分片容量以及节点的数据资源容量信息,分片传输节点的数据资源。根据本发明实施例,可以获知需要传输的节点的数据资源的容量信息,并通过分片容量协商确定传输数据时使用的分片容量,由此可以实现传输过程中错误率降低,并且可以并发地传输数据。
文档编号H04L29/08GK102130954SQ201110064549
公开日2011年7月20日 申请日期2011年3月17日 优先权日2011年3月17日
发明者卞永刚, 李克鹏, 田林一, 陈显锋 申请人:华为技术有限公司
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1