CN109155789A - 服务层中的请求处理 - Google Patents

Abstract

可以使用方法、系统和设备来支持请求的基于新鲜度的处理。基于新鲜度的处理可以包含：服务层检查其所托管的存储内容(例如，资源表示)的年龄，并确定其是否新鲜得足以满足具有指定新鲜度要求的检索或发现请求。如果不是新鲜的，则服务层可以联系应用以刷新内容。另外，基于新鲜度的处理还可以包含：服务层检查面向命令的更新请求的语义状态，以确定其状态是否相对于由服务层处理的先前命令是新鲜的。例如，服务层可以比较与控制特定应用(例如，门被锁)相关联的存储内容与更新请求(例如，解锁门)的语义内容，以确定它是相同(例如，陈旧)还是不同(例如，新鲜的)。如果是新鲜的，则服务层然后可以将更新请求重新定向到应用以使其执行命令(例如，解锁门)。

Description

服务层中的请求处理

对于相关申请的交叉引用

本申请要求在2016年3月4日提交的题为“Request Processing In The ServiceLayer(服务层中的请求处理)”的美国临时专利申请No.62/304,006的权益，其内容通过引用并入于此。

背景技术

正在开发的oneM2M标准(oneM2M-TS-0001 oneM2M Functional Architecture(oneM2M功能架构)-V2.6.0)定义了称为“公共服务实体(CSE)”的服务层。服务层提供可由不同“垂直”M2M系统和应用使用的“水平”服务。

CSE支持参考点，如图1所示。Mca参考点与应用实体(AE)接口。Mcc参考点与同一服务提供商域内的另一个CSE接口，并且Mcc的参考点与在不同服务提供商域中的另一个CSE接口。Mcn参考点与底层网络服务实体(NSE)接口。NSE为CSE提供底层网络服务，例如设备管理、位置服务和设备触发。

CSE包含称为“公共服务功能(CSF)”的多个逻辑功能，诸如“发现”和“数据管理和存储”。图2示出了当前由oneM2M Release 1定义的CSF。

oneM2M定义<container>资源，其表示要存储的内容实例的容器。oneM2M还定义<contentInstance>资源。<contentInstance>资源是<container>的子资源，并由应用用于在oneM2M服务层中存储内容。<contentInstance>资源支持creationTime属性，CSE在创建<contentInstance>时使用时间戳配置该属性。<container>资源还支持<latest>子资源，该资源可以使用RETRIEVE请求进行定位，以便检索存储在<container>中的最新<contentInstance>。

oneM2M定义<container>资源的<latest>子资源。当检索请求处理<latest>资源时，托管CSE将请求处理为对于在<container>资源的所有现有<contentInstance>资源中的最新<contentInstance>资源的检索。

oneM2M定义createdAfter过滤标准条件，其可以包括在检索或发现请求中以过滤检索或发现结果。例如，如果用于针对特定资源的检索请求，则具有比指定createdAfter时间晚的creationTime的此目标资源的子资源将在检索响应中包含其表示。类似地，如果用于针对特定资源的发现请求，则具有晚于指定createdAfter时间的creationTime的此目标资源的子资源将其URI包括在检索响应中。

参考图3，其示出了示例性的oneM2M AE pointOfAccess属性，oneM2M为<AE>资源类型定义了pointOfAccess。该属性被定义为用于经由底层网络提供的传输服务通过Mca参考点与注册的AE通信的地址列表。该属性被定义为xs:string的列表，其中，在列表中的每个pointOfAccess条目表示为包含基础传输协议方案的字符串(例如http://)以及IP地址和端口或完全合格的域名(FQDN)，例如myAE.com。例如，http://172.25.0.43：8000或http://myAE.com。

oneM2M重新定向包含：CSE生成或接收请求，评估请求的URI以确定其不针对由CSE托管的资源，然后将请求定向到另一实体(例如，AE或另一CSE)以被处理。oneM2M目前对可以重新定向到AE的请求类型有限制。oneM2M支持将以下三种类型的通知重新定向到AE：1)通知，用于验证AE可访问且能够接收通知。在创建新订阅期间并且如果AE被配置为接收订阅的通知但其不是创建订阅的AE，则这由CSE完成；2)通知，用于表示已检测到订阅的通知事件，并且AE被配置为接收给定订阅的通知；3)通知，用于表示AE已创建的订阅已被删除。

定义了用于通过定义被称为隧道锚点(TAP)的智能隧道机制来使不同的服务层技术彼此互通的方法。在一个示例中，可以通过使用诸如应用资源或容器资源之类的现有资源之一来在资源结构内支持TAP。可以为容器资源定义forwardingAddress属性。图4是与容器资源的转发地址属性相关联地使用ETSI M2M隧道接入点的示例性图示。

图5示出了示例性CoRE镜像服务器架构。CoRE Mirror Server-IETF draft-vial-core-mirror-server-01,2013年4月10日，定义了约束RESTful(CoRE)镜像服务器(MS)的概念。资源受限的IoT设备(接近睡眠的端点(Sleepy Endpoints)-SEP)可以在镜像服务器中存储和保持它们的资源的表示，并使用镜像资源表示代表它们获取镜像服务器服务请求。这可以防止物联网(IoT)设备被可能具有诸如耗尽设备的电池或拥塞局域设备网络的不利副作用的请求所淹没。

发明内容

本文公开了可用于使得能够支持请求的基于新鲜度的处理的方法、系统和设备。基于新鲜度的处理可以包含：服务层检查其所托管的存储内容(例如，资源表示)的年龄(age)，并确定其是否新鲜得足以满足具有指定新鲜度要求的检索或发现请求。如果不是新鲜的，则服务层可以联系应用以刷新内容。另外，基于新鲜度的处理还可以包含：服务层检查面向命令的更新请求的语义状态，以确定其状态是否相对于由服务层处理的先前命令是新鲜的。例如，服务层可以比较与控制特定应用(例如，门被锁)相关联的存储内容与更新请求(例如，解锁门)的语义内容，以确定其是否相同。如果是新鲜的，则服务层可以将更新请求重新定向到应用以使其执行命令(例如，解锁门)。

提供本发明内容以便以简化的形式介绍概念的选择，将在下面的具体实施方式中进一步描述这些概念。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。此外，所要求保护的主题不限于解决在本公开的任何部分中提到的任何或所有缺点的限制。

附图说明

可以从通过结合附图的示例给出的以下描述中获得更详细的理解，在附图中：

图1示出了示例性的oneM2M架构；

图2示出了示例性的oneM2M公共服务功能；

图3示出了示例性的oneM2M AE pointOfAccess属性；

图4示出了示例性ETSI M2M隧道接入点；

图5示出了示例性CoRE镜像服务器架构；

图6示出了用于基于新鲜度的内容检索的示例性网络；

图7示出了示例性的基于新鲜度的内容检索时间线；

图8示出了用于基于新鲜度的请求重新定向的示例性网络；

图9示出了示例性的基于新鲜度的请求重新定向消息流程；

图10示出了示例性的基于新鲜度的内容检索消息流程；

图11示出了示例性的基于新鲜度的资源发现消息流程；

图12示出了示例性的基于新鲜度的请求重新定向消息流程；

图13示出了OneM2M中的服务层新鲜度机制的示例性架构；

图14示出了示例性的OneM2M基于新鲜度的内容检索消息流程；

图15示出了示例性的OneM2M基于新鲜度的资源发现消息流程；

图16示出了示例性的OneM2M基于新鲜度的设备触发消息流程；

图17示出了示例性的OneM2M基于新鲜度的重新定向消息流程；

图18示出了示例性CoRE镜像服务器基于新鲜度的内容检索消息流程；

图19示出了示例性的oneM2M contentTimestamp属性；

图20示出了可以基于这里讨论的方法和系统生成的示例性显示(例如，图形用户界面)；

图21A是其中可以实现所公开的主题的示例机器到机器(M2M)或物联网(IoT)通信系统的系统图；

图21B是可以在图21A中所示的M2M/IoT通信系统内使用的示例架构的系统图；

图21C是可以在图21A中所示的通信系统内使用的示例M2M/IoT终端或网关设备的系统图；以及

图21D是其中可以包含图21A的通信系统的各方面的示例计算系统的框图。

具体实施方式

这里公开了例如可以用于服务层中的请求处理的方法、系统和设备。基于新鲜度的处理可以包含：服务层检查其所托管的存储内容(例如，资源表示)的年龄，并确定其是否新鲜得足以满足具有指定新鲜度要求的检索或发现请求。

传统的M2M/IoT服务层技术不能有效地使应用能够以考虑应用的内容新鲜度要求的方式发现或检索由服务层托管的内容。传统的M2M/IoT服务层技术也不有效地使应用能够以考虑请求的新鲜度的方式将请求从一个应用重新定向到另一个应用。这些缺点阻止服务层技术有效地支持这里讨论的用例类型等。缺乏支持可能导致物联网应用不得不做出牺牲并安排使用过时数据，或者更糟糕的是，在没有他们喜欢或需要的新鲜数据的情况下进行。对于增加数量的内容检索、内容发现以及其他类型的请求被启动或重新定向到设备的情况，这种缺乏支持也可能导致对于IoT设备的额外开销。

在下面讨论考虑到传统的M2M/IoT服务层技术的、可以使得更有效或能够实现的区域的更具体示例。在第一示例中，可能缺乏支持以允许内容源应用(下文称为内容源app)向服务层提供联系点信息。在服务层检测到对于服务于由内容请求应用(以下称为内容请求app)发出的传入内容检索或发现请求优选或所需的内容的新鲜版本的情况下，联系点信息可用于联系内容源app的目的。内容源app是通过创建服务层托管资源来提供内容的应用，而内容请求app是通过检索由内容源app创建的服务层托管资源来请求内容的应用。

在第二示例中，可能缺乏支持以允许请求接收应用(下文称为请求接收app)向服务层提供联系点信息，该联系点信息可用于将源自请求发起应用(以下称为请求发起app)并且被服务层确定为新鲜的请求重新定向到请求接收app的联系点。在没有这样的特征的情况下，请求接收app和请求发起app可以依赖于涉及多个服务层订阅和通知的间接通信方案，以便执行单个端到端请求和响应交换。请求接收app是可以通过服务层重新定向请求间接接收来自请求发起app的请求的应用，而请求发起app是经由服务层资源通过重新定向请求来向另一个应用发起请求的应用。

在第三示例中，可能缺乏支持以允许应用(即，App)订阅服务层资源并接收嵌入在来自该服务层的通知请求中的内容检索、内容发现或其他类型的请求。同样地，可能缺乏支持以允许App将相应的内容检索、内容发现或其他类型的响应返回到嵌入在通知响应内的服务层。在第四示例中，可能缺乏支持以允许服务层将接收的内容检索、内容发现或其他类型的请求重新定向到要服务的App，并且然后在接收到从App返回的响应时，创建和保持结果的本地副本，以帮助服务于未来的请求，并保持被处理的请求的历史记录和跟踪信息。在第五示例中，可能缺乏支持以允许服务层支持给定资源的重新定向策略，该策略定义规则，诸如被授权重新定向请求的实体、允许重新定向的请求类型、在允许重新定向请求时的预定时间以及允许包含在重新定向的请求中的资源的属性。

以下是可以帮助启用或提供更有效的服务层请求处理等的机制。第一示例性机制可以使内容源app能够向服务层提供联系点信息，该信息可以用于在服务层检测到期望新鲜版本的内容服务于内容请求app发出的传入内容检索或发现请求的情况下联系内容源app的目的。联系点可以以若干不同格式格式化，该若干不同格式例如是绝对URI、相对URI或oneM2M资源标识符等。第二示例性机制可以包括如下过程：其中，如果由服务层托管的版本太旧而不满足内容请求app发出的内容检索或发现请求中定义的指定新鲜度，则服务层将内容检索请求发送到内容源app以获得新鲜版本的内容。该请求可以直接检索内容，或者请求可以包含服务层希望刷新的服务层资源的地址，以及服务层要求或优选刷新的内容的优先级或预定时间。作为响应，内容源app可以在其可以向服务层提供新鲜版本的内容并执行对指定地址的更新时适当地调度和优先化。

继续参考可以帮助启用或提供更有效的服务层请求处理的机制，第三示例性机制可以使服务层能够通过在由底层网络设备触发器功能提供的服务层设备触发器请求中嵌入相应的信息元素来向App发送内容检索或其他类型的请求。第四示例性机制可以使App能够订阅服务层资源并接收嵌入在来自服务层的通知请求中的内容检索、内容发现或其他类型的请求。同样地，可能支持以允许App将相应的内容检索、内容发现或其他类型的响应返回到嵌入在通知响应内的服务层。第五示例性机制可以使请求接收app能够向服务层提供联系点信息，该信息可以用于将源自请求发起app并且被服务层确定为新鲜的请求重新定向到请求接收app的联系点。第六示例性机制可以使服务层能够将所接收的内容检索、内容发现或其他类型的请求重新定向到要服务的App，并且然后在接收到从App返回的响应时，创建和保持结果的本地副本以有助于服务于未来的请求，并保持被处理的请求的历史记录和跟踪信息。

继续参考可以帮助启用或提供更有效的服务层请求处理的本文公开的机制，第七示例性机制可以使服务层能够用作触发条件用于以非阻止方式为传入请求服务，例如检测到服务层需要将传入请求重新定向到App以进行处理(例如，获得新鲜版本的内容)。当以非阻止方式服务重新定向请求时，服务层可以向请求者提供包含在新鲜内容可用时的估计时间的确认。第八示例性机制可以使服务层能够支持给定资源的App重新定向策略，该策略定义规则，诸如被授权重新定向请求的实体、允许重新定向的请求类型、在允许重新定向请求时的预定时间以及允许包含在重新定向的请求中的资源的属性。

本文还公开了oneM2M示例，其可以帮助启用或提供更有效的服务层请求，诸如基于新鲜度的内容发现、内容检索和重新定向概念。另外，这里公开的是诸如用于基于新鲜度的内容发现、内容检索和重新定向概念的CoRE镜像服务器示例。

以下是对示例性用例的讨论，其可以提供关于用于与服务层相关联的请求处理的方法、设备或系统的附加见解。图6示出了用于基于新鲜度的内容检索的示例性网络。如图6所示，与医生相关联的App 121远程监测患者家中的患者的健康测量结果(例如，血液胰岛素、血压、脉搏血氧和心率)。这些测量结果由与患者相关联的一个或多个医疗设备123收集。医疗设备123可以佩戴在患者身上并且可以连接到患者家中的网关，并且网关可以连接到服务层122(例如，基于云的健康服务平台)，其收集来自各种患者网关和它们的连接设备的健康测量结果。App 121可以是基于web的应用，用于访问服务层122以检索医生的患者的健康测量结果。

托管在网关以及云服务平台上的可以是IoT软件服务。这些服务提供功能，例如提供查询和发现特定患者的健康测量结果的能力，确保患者的健康测量结果在网络上传输，以及将多个健康测量结果聚合到单个消息中，该消息可以通过网络更有效地发送和调度以最小化网络负载、拥塞和成本。

为了有效地监视他的患者，医生可能更喜欢查询和访问具有指定新鲜度的给定患者的健康测量结果的能力(例如，测量结果不得早于指定的时间段)。根据测量类型和特定患者，该新鲜期可能会有所不同。当使用传统系统时，医生可能仅限于访问其患者及其设备正在测量并上传到其网关或云的健康测量结果。当使用传统系统时，根据医生的新鲜度偏好，这些测量结果中的一些可能对于医生的需要而言过于陈旧，并且医生可能没有其他选择，只能等待进行并上传下一次安排的传感器测量。到这种情况发生时，来自其他患者传感器的其他测量数据可能变得陈旧，使得对患者数据的整体分析变得困难或不可靠。

为了给他的患者提供更好的护理质量并且允许他自己更好地管理他自己的时间，在这个用例中，医生更喜欢的是访问满足他的新鲜度偏好的健康测量结果而不是必须等待上传新测量结果。本文更详细地讨论了支持增强的IoT服务的机制，该服务触发特定的患者设备123或网关或两者，以便当在云中的测量结果已经不可用于医生的应用121访问时，向服务层122提供新鲜的健康测量结果，并且该服务满足他指定的新鲜度偏好。具有这种类型的功能允许医生有效地对他的患者的健康测量结果进行新鲜的按需访问，同时仍然利用在服务层122中托管健康测量结果的许多益处，例如可扩展性、可用性、成本等。当服务层122中的现有测量结果尚未满足特定请求的新鲜度标准时，通过触发设备或网关来提供新鲜的测量结果，可以节省需要通过网络发送的请求的数量，减少在网关或设备上的开销。相反，为每个请求提供测量结果的设备(例如，终端设备或网关设备)的传统触发可能导致通过网络发送更多的请求并在设备上增加开销。在涉及可能也是本质上资源受限的潜在大量设备的IoT类型部署中，最小化这种开销可能是重要的。IoT服务触发器通过下述方式允许一定程度的效率和优化：不将责任放在应用(例如，应用121)上来检测云中不可获得新读数的情况，并且继而针对具有后续请求的设备检索新读数。

图7示出了示例性的基于新鲜度的内容检索时间线。图7提供了一个示例，其更详细地突出了这种基于新鲜度的内容检索方案的潜在节省。在该示例中，医疗传感器设备131每三小时发布一次传感器读数，如顶行所示。如图所示的圆圈表示医疗传感器设备131的公布的传感器读数。然后，这些传感器读数由不同的app(App 132、App 133、App 134)检索。App 132和133周期性地每小时以稍微不同的偏移检索一次传感器读数，并具有新鲜度偏好，即传感器读数不能超过30分钟。图7中的三角形指示需要从医疗传感器设备131自身检索传感器读数的操作，因为没有在云中缓存的新鲜版本。图7中的方框指示不需要从医疗传感器设备131检索传感器读数的操作，而是可以从云获得足够新鲜的高速缓存的传感器读数。App 134可偶尔检索传感器读数并具有新鲜度偏好，即传感器读数不能超过十分钟。该示例突出显示了可以由托管在云中的传感器读数服务的检索请求(前述方框)对比需要访问传感器本身的检索请求(上述三角形)。从该示例中，26个读数中的17个可以由托管在云中的高速缓存的传感器读数来服务，并且26个中的9个由被访问的传感器服务，因为云中的高速缓存版本不够新鲜以服务传入请求。这说明了基于新鲜度的检索相对于每次读取直接访问传感器的好处。在没有基于新鲜度的检索的情况下，由于缺少满足传入请求的要求的新传感器读数，该示例中的若干请求将需要被服务(即，云)拒绝。因此，基于新鲜度的检索可以减少传感器和网络上的开销，同时为App提供他们喜欢的新鲜传感器读数。

图8示出了用于基于新鲜度的请求重新定向的示例性网络。如图8中所示，控制app141与服务层142通信连接。服务层142与建筑物网络143通信连接。建筑物网络143可以具有连接到诸如电子门、电子恒温器和传感器等的若干不同设备的网关146。控制app 141可用于远程控制建筑物网络143中的设备(例如，打开和关闭灯、控制恒温器以及锁和解锁门)。服务层142可以是基于云的建筑物管理系统，其使能建筑物网络143的设备的远程管理和控制。网关146以及服务层142可以托管高级IoT软件服务。这些服务可以提供功能，诸如提供查询和发现特定设备的能力、在网络上传输时的保护命令(例如，锁和解锁门命令)或者通过IoT软件服务处理的请求发给特定设备的命令的语义感知和含义。使用控制app 141(例如，基于web的控制App)，可以访问和控制建筑物网络143中的设备。例如，可以通过从控制app 141通过服务层142向下到建筑物网络143的网关并且最终到门锁致动器设备本身(未示出)发起命令来远程锁和解锁与建筑物网络143相关联的门。

继续参考图8，为了最小化网络上以及网关和设备上的开销，可能希望仅在请求将导致设备语义状态的变化(例如锁和解锁门或解锁锁住的门)的情况下将从控制app 141发起的请求向下发送到建立网络143的网关和设备。可能希望在服务层142内支持增强的IoT服务，其具有语义感知能力，并且能够处理传入的命令类型请求以从内容语义角度检测哪些是新鲜的，使得它们将导致设备状态的改变，并且仅将这些命令下转到建筑物网络143的网关和设备。本质上是陈旧的并且预期不会导致建筑物网络143的设备的状态改变的请求可以由服务层142内的物联网服务过滤，并且不被发送到建设物网络143的网关和设备。在涉及可能也是在本质上资源受限的潜在大量设备的IoT类型部署中，最小化这种开销可能是重要的。注意，对于其中IoT服务中的存储状态变得与建筑物网络143的实际设备的状态不同步的情况(例如，门被锁，但IoT服务表示它被解锁)，则可以具有覆写这种建议的基于新鲜度的过滤功能的机制。例如，如果服务层142接收到解锁门的5个连续请求，则服务层142可以将请求转发给设备，即使服务层中的存储状态指示命令不是新鲜的。例如，这可以基于对服务层142的特定类型请求的数量、自特定请求以来的时间段、覆盖消息或前述的组合来触发。

图9示出了示例性的基于新鲜度的请求重新定向消息流程。图9提供了一个示例，其更详细地突出了这种基于新鲜度的请求重新定向方案的潜在节省。在步骤149，与建筑物网络143通信连接的门处于锁状态。本地请求可能已将建筑物网络143的门置于锁状态。在步骤150，从建筑物网络143发送消息以指示建筑物网络143中的门的锁状态。换句话说，门锁的状态被发布到服务层142(例如，云)以保持门锁的状态和服务层142之间的同步。在步骤151，控制app 141向服务层142发送解锁建筑物网络143的门的请求。步骤151的请求被重新定向到网关和门锁以解锁门。这样做是因为请求被认为是新鲜的(在步骤152)，因为它正在请求解锁被锁住的门。在步骤153，基于步骤151的请求锁建筑物网络143的门。在步骤154，向服务层142发送消息以指示门被锁，并在步骤155保存在服务层142。在步骤154，控制app 141可以接收在步骤151中所请求的锁门的确认。在步骤155和步骤157，控制app 144和控制app 145分别请求锁建筑物网络143的门。在步骤156和步骤158，控制app 144和控制app 145分别接收指示步骤155和步骤157处的请求是陈旧的响应，因为它们试图解锁已经解锁的门。在这种情况下，保持门锁状态的服务层142过滤这些请求并且不将它们转发到建筑物网络143的网关或门锁。在步骤159，控制app 141发送锁建筑物网络143的门的请求。步骤159的请求被重新定向到网关和门锁以锁住解锁的门，因为该请求被认为是新鲜的(步骤160)。在步骤161，门被锁并且响应被发送到服务层142(在步骤162)，保存在服务层142，并且被转发到控制app 141。基于新鲜度的定向可以减少设备和网络上的开销，同时为控制app 141、控制app 144和控制app 145提供相同的功能，就像它们直接与建筑物网络143的设备通信并将请求发送到建筑物网络143自身的设备一样。

应理解，执行本文所示步骤(例如图9-图12和图14-图18)的实体可以是逻辑实体。这些步骤可以存储在诸如图21C或图21D所示的那些的设备、服务器或计算机系统的存储器中，并在其处理器上执行。在一个示例中，下面结合M2M设备的交互进一步详细说明，图10的内容源app 202或内容请求app可以驻留在图21A的M2M终端设备18上，而图10的服务层204可以驻留在图21A的M2M网关设备14或M2M服务平台22上。

图10示出了示例性的基于新鲜度的内容检索消息流程。该方法使得内容请求app206能够从服务层204检索满足内容请求app 206的指定新鲜度偏好的内容，即使对于服务层204不托管这样的内容的情况也是如此。图10的消息流程允许运行中(on-the-fly)机制以允许服务层204检测何时所请求的内容陈旧或不存在，并联系相应的内容源app 202以获得新鲜版本。在步骤210，内容源app 202和内容请求app 206认证并向服务层204注册。内容请求app 206然后发现可用的内容源app 202。

继续参考图10，在步骤211，内容源app 202将联系点信息(例如，URI)发布到服务层204。内容源app 202可以用一个或多个联系点配置服务层204。内容源app 202可以将个体联系点与由服务层204托管的一个或多个资源相关联。例如，服务层204可以允许内容源app 202在服务层204的资源内部配置联系点属性。内容源app 202定期向服务层204的资源发布特定类型的内容，例如传感器读数(例如，服务层204的资源可以是空气质量读数被发布到的容器资源)。在步骤212，将步骤211的联系点信息存储在服务层204上。服务层204可以使用联系点信息在不同场景下联系内容源app 202。例如，服务层204可以联系内容源app202以对于诸如服务层204接收来自内容请求app 206的请求以检索传感器读数的场景的情况获得新鲜内容实例(例如，传感器读数)，服务层204当前不具有该传感器读数的本地托管版本或者所有版本都太旧而不能满足内容请求app 206的新鲜度偏好。对于这样的场景，服务层204可以使用由内容源App 212提供的联系点信息来向其发送请求并获取新鲜内容。在步骤213，服务层204可以向内容源app 202发送响应以确认接收到步骤211的消息。

在步骤214，内容源app 202将一个或多个内容实例发布到由目标地址(例如，URI)指定的服务层204资源。每个接收的内容实例可以由服务层204存储(例如，步骤215)并通过响应确认(例如，步骤216)。内容源app 202还可以提供内容实例(例如，内容＝传感器读数)何时由内容源app 202生成或捕获的时间戳(例如，时间戳＝20160104T104017)。服务层204还可以向内容实例分配时间戳，用于指示内容实例存储在服务层204中的时间对比内容源app 202生成内容的时间。两个时间戳对于内容请求app 206基于不同时间戳搜索内容可能是有价值的。

在步骤217，内容请求app 206可以向服务层204发出请求以获取与内容源app 202相关联的特定类型的内容。内容请求app 206可以通过目标地址(例如，URI)指定内容源app202。请求中可以包括配置有时间和日期信息的指定新鲜度时间参数(例如，20160103T112032)，内容请求app 206使用该时间和日期信息指定它优选(或要求)不早于指定时间和日期的内容。

在步骤218，服务层204将步骤217的请求的新鲜度时间参数内的指定时间和日期信息与服务层204托管并且可通过在步骤217的请求中终端的目标地址访问的每个可应用内容实例的时间戳进行比较。从该比较，服务层204确定由服务层204托管的任何适用内容实例是否具有比指定新鲜度时间参数更新的时间戳。如果没有找到，则服务层204可以生成事件以从相应的内容源app 202发信号通知新鲜内容实例是优选的或需要的，以便满足该请求。反过来，该事件可以被服务层204用作触发器，以尝试并从内容源app 206获得新鲜内容实例，如框221的步骤中概述的过程所定义的那样。可以基于是否为内容源App 202配置了适用的联系点来限制触发器的生成。如果未配置联系点，则可以抑制触发。

在步骤219(在框220中)，如果服务层204发现具有比指定的新鲜度-时间参数更新的时间戳(即，在可接受的阈值时段内)的内容实例，则其可以向内容请求App 206返回包含内容实例的响应。在这种情况下，服务层204不需要启动刷新其本地存储的内容。注意，对于所请求的内容不太陈旧但很快将会如此的情况，服务层204仍然可以选择执行在框221内的步骤以获得新鲜内容实例。“不太陈旧”可能基于许多因素。可以基于过去的响应(例如，先前时段中存在或不存在“不太陈旧”的响应、连续响应等)来确定在这种情况下是否继续去执行框221的步骤。此外，对于所请求的内容最近变得陈旧的情况，服务层204对于内容源app 202不可用或者没有可用的内容的新鲜版本的情况仍然可以选择将内容返回到内容请求app 206。在这种情况下，服务层204可以向内容请求app 206提供内容不满足指定的新鲜度偏好但是是唯一可用内容的指示。

对于图10的框221中的步骤，如果服务层204没有找到具有比指定的新鲜度-时间参数更新的时间戳的内容实例，则它可以向内容请求app 206返回确认，使得内容请求app206不需要在服务层204尝试从内容源App 202获得新鲜内容实例时阻止和等待(步骤222)。步骤222的该确认消息可以包括指示该请求已被接收并且仍在被处理的状态，因为服务层204没有满足内容请求app 206的新鲜度偏好的本地托管的内容实例。步骤222的确认消息还可以包括服务层回调地址(例如，URI)，其可以由内容请求app 206用于在其变得可用时检索或订阅接收新鲜内容实例。该确认还可以包括相对于服务层204期望准备好内容的新鲜版本的时间的估计时间或延迟(例如，服务层204可能能够基于获得来自给定内容源app202的新鲜内容的过去历史来计算预期时间或延迟)。例如，内容请求app 206可以周期性地轮询或订阅该地址，并且当服务层204能够从内容源app 202获得新鲜的传感器读数时接收新鲜的传感器读数，或者如果服务层204未获得成功从内容源App 202读取新鲜的传感器读数，则接收错误条件。该确认也可以可选地包括内容的陈旧版本，使得它在等待新鲜内容时对内容请求App 206可能具有一些价值。对于内容请求app 206指定将来的新鲜度时间的情况，服务层204可以以非阻止方式处理该请求。服务层204可以等待直到指定的新鲜度时间过去，并且然后检查它是否托管内容以服务该请求。如果是，则服务层204可以用内容响应回内容请求App 206。否则，它可以执行步骤223和225-232。或者，服务层204可以选择以阻止方式处理请求，在这种情况下，它不会在该步骤中向内容请求app 206返回确认。相反，服务层204将阻止响应内容请求app 206，直到图10的步骤232。允许服务层204确定是否以阻止或非阻止方式处理请求的触发可以基于服务层是否具有足够新鲜的数据来处理该请求。在没有这样做并向内容源App 202发起请求的情况下，服务层204可以选择以非阻止方式处理该请求。否则，服务层204可以选择以阻止方式处理请求。或者，如步骤124所示，内容请求app 124可以在请求中明确指定服务层204是使用阻止还是非阻止。

继续参考图10，在步骤123，如果当服务层204尝试获得新鲜内容实例时不能通过服务层204的请求到达内容源app 202，则服务层204可以发起设备触发操作以使内容源app202重新建立到服务层204的连接，使得它可以获得新鲜内容实例。服务层204如何进行这种可达性确定的细节可以以例如服务层204支持内容源app 202的可达性状态信息的若干不同方式完成，所述设备更新该状态信息以指示何时可到达或不可达到服务层204，如oneM2M-TS-0001 oneM2M Functional Architecture-V2.6.0定义，其全部内容通过引用并入本文。服务层204可以基于诸如内容检索App 206是否被授权使用服务层204支持的新鲜度服务的策略来调节是否针对给定请求执行基于新鲜度的内容检索。

在图10的步骤225处，如果内容源app 202不可达，则服务层204可以生成设备触发请求以启动内容源app 202以重新建立其与服务层204的连接，使得其可以从服务层204接收请求。服务层204如何将设备触发传递给内容源app 202的细节可以以多种方式发生，例如，一种这样的传递方法可以是利用底层网络触发功能，例如基于3GPP SMS的触发。作为触发请求有效载荷的一部分，服务层204可以嵌入附加信息以向内容源app 202指示该触发的原因是用新鲜内容(例如，传感器读数)刷新服务层204。该附加信息可以包括以下中的一个或多个：触发类型参数(例如，“请求的内容”)；服务层内容标识符或地址参数，其指示刷新优选(或需要)的特定内容；优先级参数，其指示服务层204期望或需要所请求内容的紧迫性；新鲜度-时间参数，其指示在内容源app 202支持缓冲内容实例的情况下内容必须不早于指定日期和时间；或者，时间表参数，其指示服务层204优选内容源app202向其提供新鲜版本内容的日期和时间。对于优先级参数，服务层204可以基于传入请求的指定优先级、与内容请求App 206的订阅或帐户相关联的优先级、内容的年龄或陈旧性(例如，超过指定新鲜度-时间的相对时间)或内容的流行度或等级或兴趣(例如，有多少不同的内容请求app和对内容的请求的频率模式)来导出优先级。对于时间表参数，服务层204可以基于当前请求的指定新鲜度-时间来导出时间表(例如，使用将来的时间指定请求中的新鲜度时间)，或者可选地，导出的时间表可以基于对内容的请求的过去历史(例如，检测过去请求的模式并使用该模式来导出用于未来请求的估计时间表)。步骤124的消息可以包括以下信息：(type＝ContentRequest,addr＝URI,priority＝high,freshness-time＝20160103T112032,schedule＝20160103T112132)。

在步骤226，在接收到设备触发请求时，内容源app 202可以通过分析指定的触发类型参数来处理并检测其是对内容的请求。如果内容源app 202支持多于一种类型的内容，则它可以检查内容标识符或地址参数以检测服务层204正在请求哪种类型的内容。然后，内容源app 202可以检查优先级或时间表参数以确定何时其必须向服务层204提供新鲜内容。内容源app 202还可以检查新鲜度-时间参数以查看是否指定了内容的优选新鲜度日期或时间。如果指定了一个，则内容源App 202可以验证在该日期和时间之前没有生成它提供的任何内容实例。

在图10的步骤227，响应于由服务层204发起的设备触发请求，内容源app 202可以重新建立其与服务层204的连接并更新其可达性状态以通知服务层204它现在可以到达并且能够接收服务层204发起的请求。内容源app 202还可以在设备触发响应(如果可用)中包括新鲜版本的内容(例如，传感器读数)或者可选地包括指示此时新鲜版本不可用的状态。在这样做时，这可以通过保存单独的请求来优化整个过程。或者，内容源app 202可以发起对服务层204的单独请求(在设备触发请求和响应之后)以用新鲜内容(如果可用)或者可选地以指示新鲜的内容版本在此时间不可用的状态更新服务层204。内容源app202可以使用嵌入在设备触发请求中的地址信息作为该新请求的目标。步骤227的消息可以包括以下信息：(to＝URI,content＝sensor reading,timestamp＝20160105T091434))。

继续参考图10，在步骤228，如果内容源app 202是可到达的并且服务层204还没有通过另一机制(诸如本文描述的基于设备触发的机制)从内容源app 202接收到新鲜内容实例，则服务层204可以或者向内容源App 202发起单独的请求，明确地请求新鲜内容实例。可以使用若干不同类型的请求之一将该请求传递到内容源app 202。服务层204可以在步骤211到步骤213中发起针对由内容源app 202指定的联系点的检索请求。或者，服务层204可以向针对在先前订阅请求中配置的通知地址的内容源app 202或向在步骤211到步骤213中指定的联系点发起通知请求。在该通知内，服务层204可以包括在此(例如，步骤225到步骤227)讨论的触发请求中定义的类似类型的信息。步骤228的通知可以包括以下中的一个或多个：该通知(例如，内容刷新请求)的原因(例如，触发事件)；服务层内容标识符或地址参数，其指示刷新优选的特定内容；优先级参数，其指示服务层204期望或需要所请求内容的紧急程度；新鲜度-时间参数，其指示在内容源App 202支持缓冲内容实例的情况下必须不早于指定的绝对日期和时间或者自创建内容以来的相对时间创建内容；或，时间表参数，其指示在服务层204优选内容来源App 202向其提供新鲜版本内容时的日期和时间。对于优先级参数，服务层204可以基于传入请求的指定优先级、与内容请求App 206的订阅或帐户相关联的优先级、内容的年龄或陈旧性(例如，超过指定新鲜度-时间的时间)或内容的流行度或等级或兴趣(例如，有多少不同的内容请求app和对内容的请求的频率模式)来导出优先级。对于时间表参数，服务层204可以基于当前请求的指定新鲜度-时间来导出时间表(例如，以将来的时间指定请求中的新鲜度时间)，或者可选地，导出的时间表可以基于对内容的请求的过去历史(例如，检测过去请求的模式并使用该模式来导出用于未来请求的估计时间表)。步骤228的消息可以包括以下信息：(type＝ContentRefresh,addr＝URI,priority＝high,freshness-time＝20160103T112032,schedule＝20160103T112132)。

在图10的步骤229，在从服务层204接收到步骤228的请求时，内容源app 202可以处理和检测请求的类型(例如，检索或通知)。如果请求是检索，则内容源app202可以分析请求中的指定地址以确定正在请求哪个内容，并且进而准备其想要返回到服务层204响应(如果可用)的内容实例或者可选地指示目前还没有新鲜版本的的状态。如果请求是通知，则内容源app 202可以通过分析指定的通知类型参数来检测它是对内容的请求。如果内容源app202支持多种类型的内容，则它可以检查内容标识符或地址参数以检测服务层204正在请求哪种类型的内容。然后，它可以检查优先级或时间表参数以确定何时它必须向服务层204提供新鲜内容。它还可以检查新鲜度-时间参数以查看是否指定了内容的所需新鲜日期或时间。如果指定了一个，则内容源App202可以验证在该日期和时间之前没有生成它提供的任何内容实例。

在步骤230，内容源app 202可以以几种方法之一用新鲜内容实例或指示此时新鲜内容实例不可用的状态来更新服务层204。如果服务层204向内容源App 202发出请求新鲜内容实例的显式检索请求，则内容源App 202可以在检索响应中包括新鲜内容实例。如果服务层204向内容源app 202发出指示期望或者需要新鲜内容实例的通知，则内容源app 202可以在通知响应中包括新鲜内容实例，或者可选地，内容源app 202可以跟进用于在服务层204中创建新鲜内容实例的单独请求(例如，创建请求)。步骤230的消息可以包括以下信息：(to＝URI,content＝sensor reading,timestamp＝20160105T091434)。

继续参考图10，在步骤231，如果新鲜内容实例成功发布到服务层204，则服务层204可以存储新鲜内容实例的本地版本，使得它可以用于服务未来请求或用于诸如计费和分析的目的。服务层204还可以可选地分配相应的时间戳以跟踪内容实例何时被发布到服务层204。在步骤232，如果新鲜内容实例成功发布到服务层204，则它返回到内容请求app206，否则，如果新鲜内容不可用，则服务层204可以返回错误，或者可选地，它可以返回内容的最近(但陈旧)版本以及其陈旧性的指示(例如，它被创建的时间)，因为这仍然可能有一些用处。

图11示出了示例性的基于新鲜度的资源发现消息流程。即使对于服务层204不托管这样的内容的情况，内容请求app 206也发现来自服务层204的满足内容请求app 206的新鲜度偏好的内容。该过程定义了一种即时机制，以允许服务层204检测何时内容陈旧或在服务层204中不存在。当发生这种情况时，服务层204可以返过来联系相应的内容源app 202以使其刷新内容，使得服务层204在其返回到内容请求app 206的发现响应中包括对该内容的引用。

图11的框241中的步骤与图10的步骤210至步骤216相同地起作用。在图11的步骤242，内容请求app 106向服务层204发出请求以发现与内容源app 202相关联的特定类型的内容。请求中包括指定的新鲜度-时间参数，其配置有内容请求app 206使用来指定它希望发现不早于指定时间和日期的内容的时间和日期信息。步骤242的请求还可以包括其他发现过滤标准(例如，内容的类型)。

在步骤243，服务层204将步骤242的内容发现请求的新鲜度-时间参数内的指定时间和日期信息与服务层204托管的每个可应用内容实例的时间戳进行比较。从该比较，服务层204确定由服务层204托管的任何适用内容实例是否具有比指定新鲜度-时间参数更新(即，在可接受的阈值时段内)的时间戳。如果没有找到，则服务层204可以生成事件以从相应的内容源app 202发信号通知新鲜内容实例是优选的，使得服务层204可以在它向内容请求app 206发送的发现响应中包括对该内容的引用(例如，URI)，并且当内容请求app 206发送对于访问内容的后续请求时，该服务层204使内容准备好并可用。服务层204可以使用该事件作为触发器，以尝试并从内容源App 202获取新鲜内容实例，如图10的框221的流程和相应的描述所概述的。可以基于是否已经为内容源app 202配置了适用的联系点来限制触发器的生成。如果未配置联系点，则可以抑制触发器。服务层204可以支持访问控制策略以限制哪些内容请求app 206被允许利用步骤242所请求的并且在步骤243中处理的这种基于新鲜度的发现特征。内容请求app 206是否对于为给定的目标内容实例定义的基于新鲜度的发现具有权限可以用于限制服务层204随后是否向内容源app 202发起基于新鲜度的检索请求。

在框245的步骤244，如果服务层204发现具有比指定的新鲜度-时间参数更新的时间戳(即，在可接受的阈值时段内)的内容实例，则它可以返回对内容请求app 206的响应，其在发现响应中包括对此内容的引用(例如，URI)。在这种情况下，服务层204可以不启动刷新其本地存储的内容。然而，即使对于这种情况，服务层204也可以选择仍然刷新其内容。例如，如果内容接近变得陈旧，则服务层204可以检测到这种情况并选择主动刷新内容。步骤222至步骤231以及图10的伴随说明可以与图11的框247中的步骤相同。在步骤248，如果新鲜内容实例被成功发布到服务层204，则在发现响应中返回对该内容的引用(例如，URI)，否则可以返回错误。在步骤249，内容请求app 206处理发现响应，并且随后可以检索满足其新鲜度要求的一个或多个发现的内容实例(基于响应中的指定引用)。

图12示出了示例性的基于新鲜度的请求重新定向消息流程。请求接收app 203可以将服务层204配置为将其接收的针对给定资源的某些请求重新定向到要服务的请求接收app 203。该重新定向功能具有透明度，其允许请求和响应在请求发起app 205和请求接收app 203之间通过服务层204端到端地流动。没有这样的特征，请求接收app 203和请求发起app 205可以依赖于涉及多个服务层订阅和通知的不太有效或优选的间接通信方案，以便执行单个端到端请求和响应交换。

例如，可以使用图12的方法将服务层204接收的UPDATE请求重新定向到请求接收app 203。这对于请求接收app 203是致动器类型的设备(例如，灯开关)的场景可能是有用的。可以通过可编程服务层重新定向策略来配置期望被重新定向到请求接收app 203的请求的类型。其他类型的请求，例如CREATE(例如，创建子资源)、RETRIEVE、DELETE和SUBSCRIBE，也可以适用于如图12中所示的该过程，但未明确显示保持过程简洁。另外，当服务层204将请求重新定向到请求接收app 203时，其他策略可能合格。例如，服务层204可以支持对请求的过滤并且仅将请求的子集重新定向到请求接收app 203以用于给定的目标资源(例如，仅重新定向来自特定请求发起app 205的请求)。服务层还可以支持下述策略：控制在执行新鲜度过滤和重新定向时服务层204将(以及将不)分析资源表示中的哪些属性。该特征可以允许请求接收app 203配置服务层204以将其比较集中在对请求接收app 203具有重要性的属性上并且忽略其他属性。另一种类型的重新定向策略可以定义哪些属性将被包括在重新定向的请求中以及哪些属性不包括在重新定向的请求中。另一种类型的重新定向策略可以定义特定内容请求app 206，其具有将其请求重新定向到内容源app 202的权限。

服务层204可以执行的一种重新定向是基于新鲜度的重新定向。当接收到对目标资源的UPDATE请求时，服务层204将要更新的资源的当前表示与UPDATE请求中提供的表示进行比较。如果它们是相同的，则服务层204可以推断出当前资源是新鲜的并且是最新鲜的并且选择不将UPDATE请求重新定向到请求接收app 203，以便最小化请求的数量和请求接收app上的负荷。在这种情况下，服务层204可以向请求发起app 205返回状态码，以通知它这种情况。相反，如果比较的表示不相同，则服务层204可以将UPDATE请求重新定向到请求接收app 203以供其处理。此外，服务层204还可以更新其资源的本地版本以维持与请求接收app 203的表示的同步，并利用更新的版本用于潜在的未来请求。注意，可以作为可配置选项支持这种基于新鲜度的重新定向特征，如图12(以及图8-图9)所示，其可以对诸如涉及资源受限的IoT设备和可以随时间接收重复请求的网络的一些用例有价值。对于其中重复请求可能具有功能重要性的其他用例，可以禁用此特征。选择性地启用或禁用该特征的一种示例性方式是通过使用联系点(例如，如果没有联系点被配置为禁用重新定向)。选择性地启用或禁用该特征的第二示例性方式是通过使用重新定向策略。

在步骤261，请求接收app 203和请求发起app 205认证服务层204并向服务层204注册。请求发起app 205然后发现请求接收app 203。在步骤262，请求接收app 203发送消息，其包括针对给定资源的配置的联系人地址和在服务层204中的重新定向策略。步骤262的消息可以包括以下中的一个或多个:(to＝URI,point-of-contact＝App Addr Info,retargetPolicies＝policies)。在步骤263，服务层204为指定资源配置与请求接收app203相关联的联系点信息和重新定向策略。在步骤264，服务层204可以是可以确认接收到步骤262的消息的响应等。图12的步骤262到步骤264类似于在基于新鲜度的内容检索中定义的图10的步骤211-213，然而，另外，请求接收app 203还可以为给定资源配置重新定向策略。或者，重新定向策略可以由其他实体(例如，网络中的管理实体)配置。这些策略包括重新定向规则，例如：允许向请求接收app 203发出请求的请求发起app 205的列表；请求接收app 203将服务的允许的请求类型的列表；定义请求接收app 203可用并且愿意服务请求的时间的时间表；以及，请求接收app 203的感兴趣的请求相关属性的列表/掩码。

在步骤265，请求发起app 205向服务层204发出UPDATE请求，以更新与由目标地址(例如，URI)指定的特定请求接收app相关联的特定资源。在请求中包括可以要更新的资源的完整或部分表示。在该示例中，UPDATE用于将请求接收app 203支持的开关的状态改变为值“ON”。该消息可以包括以下中的一个或多个：(to＝URI,content＝‘ON’)。

继续参考图12，在步骤266，服务层204处理步骤165的UPDATE请求。总之，可以基于重新定向策略将目标资源的当前表示与请求中的内容进行比较，并确定它们是不同的，因此对请求接收app 203重新定向请求。进一步详细地，服务层104可以分析由请求发起app205的请求所针对的资源的重新定向策略。使用这些策略，服务层204可以执行检查，例如请求发起app 205是否被授权向请求接收app 203发出请求、请求是否是请求接收app 203支持的请求、确定何时缓冲以及继而基于指定的时间表或指定的条件将请求重新定向到请求接收app 203。然后，服务层204将存储在服务层204中的资源的当前表示(如果有的话)与包含在UPDATE请求中的表示进行比较。该比较可以考虑定义要比较(或不比较)的资源属性的子集的掩码，使得仅将某些属性彼此进行比较。如果比较得出没有不匹配，则服务层204可以决定不将UPDATE请求重新定向到请求接收app 203。然而，如果发现不匹配(如在该示例中)，则服务层204可以决定重新定向UPDATE请求。对于服务层204中的存储状态变得与请求接收app 203的状态不同步的情况(例如，灯“打开”但服务层状态指示它“关闭”)，则可能具有覆盖这种提出的基于新鲜度的过滤功能的机制。例如，如果服务层204接收到关闭灯的五个连续请求，则即使存储的状态指示UPDATE请求是不新鲜的，服务层204也可以将请求转发到请求接收app 203。

在图12的步骤267处，服务层204将UPDATE请求重新定向到请求接收app 203以被服务。该请求中可以包括来自请求发起app 205的原始请求中包括的要更新的资源的表示。步骤267的消息可以包括以下中的一个或多个：(to＝point of contact,content＝“Switch ON”)。在步骤268，请求接收app 203接收并处理来自服务层204的UPDATE请求。它可以通过更新其本地版本的资源来完成此操作。在该示例中，UPDATE用于将请求接收app203支持的开关的状态改变为值“ON”。在步骤269，请求接收app 203响应回服务层204，指示它成功更新了其本地版本的资源。在步骤270，服务层204对其本地版本的资源执行相同的更新(例如，将状态改变为值“ON”)，这可以响应于接收到步骤269的消息。在步骤271，服务层204向请求发起app 205发送消息，指示UPDATE请求被成功处理。

继续参考图12，在步骤272，不同的请求发起app 205(下文中称为第二请求发起app 205)发出与来自第一请求发起app(即，与请求265相关联)的UPDATE在语义上相同(例如，在请求有效载荷中包含相同资源表示)的UPDATE请求。在步骤273，服务层204执行与在步骤266中描述的类似的处理。服务层204检测到比较结果匹配(例如，“ON”的更新值与当前值相同)，并且确定不将UPDATE请求重新定向到请求接收app 203。在步骤274，服务层204可以更新其本地元数据以跟踪下述事实：来自第二请求发起app 205的UPDATE请求被处理，即使它没有被重新定向到请求接收app 203。这可以有益于跟踪请求发起app 205的请求历史，以用于诸如计费、分析和确定对请求的后续反应等目的。在步骤275，服务层204响应回第二请求发起app 205，指示UPDATE请求被成功处理。

以下是对本文讨论的一些方法、系统和设备的考虑。第一考虑是，当前的oneM2M架构似乎基于资源由CSE而不是AE托管的原则。因此，由AE托管的资源不是由oneM2M定义的，也不是用于访问AE托管资源的消息或过程。由oneM2M定义的可以以AE为目标的请求类型是NOTIFY请求。无法通过CREATE、RETRIEVE、UPDATE、DELETE、SUBSCRIBE或DISCOVER oneM2M请求来定位AE。因此，为了作为oneM2M系统的一部分起作用，AE必须向CSE注册并在CSE内发布或镜像其资源，以便CSE可以托管这些资源并使其可被其他AE发现和访问。

第二考虑是oneM2M当前不支持AE指定给定容器的联系点的能力。此外，不支持CSE将传入容器请求重新定向到要处理的相应AE而不是处理请求的CSE的能力。也不支持CSE检测到目标容器中的<contentInstance>资源过于陈旧而无法为传入请求提供服务并且从而从AE获取新鲜的<contentInstance>以满足请求的能力。

第三考虑是托管CSE限于仅使用它碰巧当前托管的最新<contentInstance>资源来服务于对于<latest>的检索。如果请求的发起者还指定了createdAfter过滤标准条件，该条件的时间戳晚于最新<contentInstance>的creationTime，则这将导致不匹配。oneM2M目前不支持在此场景中从AE获取新鲜的<contentInstance>资源的机制和过程。

第四考虑是，如果指定的createdAfter过滤标准条件导致不匹配，则oneM2M当前不支持从满足指定的createdAfter过滤标准的AE获得新鲜内容的机制和过程。第五考虑是oneM2M当前不支持为允许AE创建和使用的其他资源类型(例如，<container>、<flexContainer>、<mgmtObj>、<mgmtCmd>等)配置pointOfAccess。oneM2M进一步将CSE对pointOfAccess属性的使用仅限于CSE向AE发送通知的情况。oneM2M不允许AE配置其他地址信息，例如进入pointOfAccess的URI路径，因为在oneM2M中不支持可通过oneM2M寻址的AE托管资源。如果由AE配置多个pointOfAccess条目，则oneM2M也不定义CSE如何使用所述多个pointOfAccess条目。第六考虑是oneM2M当前不允许CSE向AE发起或重新定向除上面列出的那些以外的任何其他类型的请求。例如，CSE无法检索或更新存储在应用中的资源。第七考虑是可以处理应用服务层的传统系统没有定义如何使用forwardingAddress来支持请求的基于新鲜度的处理。第八考虑是CoRE Mirror Server–IETF draft-vial-core-mirror-server-01,April 10,2013不支持允许客户端在其对镜像资源的GET请求中指定新鲜度-时间的能力(例如，目标资源不能超过某个日期或时间)。此外，除了别的之外，CoRE MirrorServer–IETF draft-vial-core-mirror-server-01,April 10,2013不支持将其为镜像资源接收的GET请求在镜像资源过时(例如，镜像资源表示早于客户端GET请求中指定的指定日期或时间)的情况下有条件地转发到托管在SEP上的相应资源的能力。

以下公开的是可以考虑和应用本文所讨论的概念的oneM2M示例。图13示出了在OneM2M中的服务层新鲜度机制的示例性架构。新鲜度能力可以实现为CSE中的数据管理和存储CSF、发现CSF或订阅和通知CSF的特征。例如，可以将新鲜度能力添加到数据管理和存储CSF 280、发现CSF 281或订阅和通知CSF 282。

为了实现本文公开的新鲜度机制和过程，本文定义了对oneM2M资源的增强。

这里公开了一种pointOfContact公共资源属性，以使oneM2M资源能够被配置AE的寻址信息。针对给定资源的该属性的存在可以是对托管CSE(例如，图10的服务层204或图14的CSE 304)的指示：与该资源相关联的AE(例如，创建该资源的AE——内容源AE 302)支持服务被CSE发送给它的请求的能力。这些请求可以是CSE针对AE重新定向并且由其他实体(例如，其他AE或CSE)发起或者CSE自身发起(例如，以刷新陈旧资源表示)的请求。各种类型的oneM2M定义的资源可以支持该pointOfContact属性。例如，<container>、<flexContainer>、<mgmtObj>、<mgmtCmd>、<timeSeries>等资源类型。

所提出的pointOfContact属性可以支持相应AE的不同类型的地址信息。在一个示例中，pointOfContact属性可以配置有AE所托管的资源的绝对URI(例如，http://172.30.0.55:3478/temperature)。在这种情况下，CSE可以使用此pointOfContact作为向AE发送请求的完整地址。在第二示例中，pointOfContact属性可以配置有由CSE托管的AE的<AE>资源的oneM2M定义的resourceID。在这种情况下，CSE可以使用该resourceID来访问在<AE>资源的oneM2M定义的pointOfAccess属性内配置的AE的支持方案、FQDN或IP地址和端口。该信息又可以用于由CSE向AE发送请求(例如，http://172.30.0.55:3478)。在第三示例中，pointOfContact属性可以配置有AE托管的资源的相对URI(例如，/temperature)。在这种情况下，CSE可以使用此pointOfContact作为部分地址。然后，CSE可以支持通过使用与具有访问点属性的资源附属的父<AE>资源的pointOfAccess属性中配置的FQDN或IP/端口来形成完整地址。CSE可以使用pointOfContact相对URI(例如，/temperature)作为URI的路径部分，并使用pointOfAccess信息作为方案和主机部分(例如，http://172.30.0.55:3478)来形成绝对URI(例如，http://172.30.0.55:3478/temperature)。

表1提供了所公开的pointOfContact oneM2M公共属性的进一步细节。

表1：pointOfContact oneM2M公共属性

本公开提出了新的oneM2M通知事件和内容类型。这些可以使CSE能够支持这里公开的基于新鲜度的内容检索、内容发现和请求重新定向功能。除了检索之外，oneM2M通知内容类型特征还可用于支持从CSE到AE的其他类型请求(例如，创建、更新或删除)的重新定向。

为oneM2M订阅eventNotificationCriteria定义了新类型的通知事件。当检索订阅的<container>资源和<contentInstance>资源的最新<contentInstance>的尝试不存在或者其creationTime早于在检索请求的createdAfter filterCriteria中指定的时间时，可能会触发新事件。这在本文表2中示出。

为oneM2M通知定义了新类型的通知内容。新内容类型允许将以订阅的父资源(subscribed-to-parent resource)为目标的传入请求封装在通知中。这显示在下表3中。

这些新的通知事件和内容类型使得oneM2M订阅能够用于将来自CSE的请求重新定向到AE。AE可以使用这些来配置CSE以将它针对给定资源接收的请求重新定向到要服务的AE。当被触发时，新事件可以导致CSE生成并向由订阅的notificationURI属性定义的指定目标(例如，AE)发送通知请求。通知的内容可以包含最初以订阅到父资源为目标并且CSE重新定向的一个或多个嵌入请求。在接收到通知时，接收器(例如，AE)可以处理嵌入在通知的内容中的重新定向的请求，并且可以将响应返回到嵌入在通知响应的内容内的CSE。在接收到通知响应时，CSE可以处理通知响应并将嵌入在通知响应的内容中的响应重新定向回请求的发起者。

在另一示例中，为oneM2M订阅eventNotificationCriteria条件定义新类型的事件。这种新类型的事件使oneM2M订阅能够用于将来自CSE的请求重新定向到AE。AE可以使用这种新类型的事件来配置CSE以将其针对给定资源接收的请求重新定向到要服务的AE。当被触发时，eventNotificationCriteria可以导致CSE生成并向由订阅的notificationURI属性定义的指定目标(例如，AE)发送通知请求。通知的内容可以包含最初以订阅到父资源为目标并且CSE重新定向的一个或多个嵌入请求。在接收到通知时，接收器(例如，AE)可以处理嵌入在通知的内容中的重新定向的请求，并且可以将响应返回到嵌入在通知响应的内容内的CSE。在接收到通知响应时，CSE可以处理通知响应并将嵌入在通知响应的内容中的响应重新定向回请求的发起者。

表2：通知事件的类型

表3：通知内容的类型

这里公开了用于<contentInstance>资源类型的新鲜的oneM2M属性contentTimestamp，如图19中所示并且也参见表4。此属性使AE能够为其发布到CSE的内容配置AE定义的时间戳。这允许AE发布由AE创建内容的时间，该时间可以与AE实际发布并在CSE上创建内容的时间不同。这对于AE可以缓冲内容并在稍后的某个时间将其发布到CSE的用例可能是重要的。允许AE将此时间发布到CSE向请求访问此内容的其他AE提供了有关内容由原始AE实际生成或收集的时间对比它被发布到CSE的时间的附加信息。

表4：contentTimestamp属性

这里公开了对oneM2M<accessControlPolicy>资源的增强，以添加对新类型RETARGET操作的支持，该操作可以由<accessControlPolicy>资源的权限属性的oneM2M定义的accessControlOperations参数支持。表5捕获了新的RETARGET操作。该RETARGET操作可用于定义来自特定发起者的请求是否具有要被CSE重新定向的权限。如果在accessControlOperations列表中定义了RETARGET操作，则启用重新定向，否则将禁用其。如果启用，则CSE可以将请求重新定向到诸如AE的指定实体。如本文所讨论的，存在用于指定实体以接收重新定向的请求的若干方法。例如，pointOfContact属性为一个，并且notificationURI为另一个。

表5：accessControlOperations属性

为了帮助实现本文公开的所提出的新鲜度机制，定义了对oneM2M请求和响应消息的以下增强。oneM2M通知请求的结构可以由m2m:notification数据类型和相应的通知模式文件定义。

本公开讨论了将contentRequest、contentReference、freshTime、contentPriority和contentSchedule元素添加到m2m:notification数据类型和相应的通知模式文件，以支持向AE发送通知以使其向CSE提供新鲜内容，如由基于新鲜度的过程所定义的。可以经由通知响应将所请求的内容返回到请求CSE，或者可选地，AE可以跟进在请求CSE上更新或创建内容的单独请求。这里考虑contentSchedule可以包括预期内容的新鲜度的预期时段。例如，contentSchedule可以是周期性时间表(例如，以5分钟的间隔出现或发生)或非周期性时间表，例如特定时间和日期(例如，5月5日13:00，6月7日10:00，等等......)。CSE可以通过接收的请求模式(例如，分析从一个或多个内容请求应用到特定CSE或类似定位的CSE的请求中的多个新鲜度时段)来基于时间表(例如，阈值时段)确定它将需要从内容源应用接收新鲜的读数。这可以减少来自CSE的请求的数量，因为内容源应用将主动地基于时间表发送内容更新。该时间表可以导致增加或减少来自内容源(例如，内容源202)的更新频率。尽管讨论了内容源，但是这些原理也可以应用于涉及请求接收应用的情况(例如，图12，其可以涉及致动器)。

本文还讨论了添加createRequest、retrieveRequest、updateRequest、deleteRequest、discoverRequest和subscribeRequest元素以使CSE能够通过oneM2M通知请求对AE启动或重新定向创建、检索、更新、删除、订阅和发现请求，使得AE可以服务于这些请求，并通过oneM2M通知响应将响应返回给CSE。

表6：oneM2M通知请求消息增强

oneM2M当前在其版本1规范中定义了设备触发特征(oneM2M-TS-0001 oneM2MFunctional Architecture-V2.6.0，其全部内容通过引用并入)。然而，oneM2M尚未定义设备触发请求消息的消息格式，该消息从CSE被发送到由诸如3GPP的底层网络功能支持的设备触发功能。

类似于表6中定义的那些的元素也应当被视为新的设备触发请求元素。在这样做时，oneM2M设备触发请求可以用作使用对本公开中定义的基于新鲜度的内容检索和发现过程的检索或通知请求的另一替代方案。这可能特别适用于这样的用例，其中，基于新鲜度的内容检索或发现请求被优选(或需要)发起到托管在当前不可到达CSE的设备上的内容源AE。在这种情况下，CSE可以向内容源AE发起设备触发请求，并且同时在触发请求中嵌入基于新鲜度的内容检索元素。类似地，可以使用相同的功能将请求转发到请求接收AE。

为了实现所公开的新鲜度机制，参考图14定义了对oneM2M过程的以下增强。

可以增强oneM2M CSE(例如，CSE 304)以支持允许AE可选地指定给定资源的pointOfContact地址的能力。例如，AE可以配置<container>资源的pointOfContact属性。通过配置pointOfContact属性，AE可以向CSE 304指示它支持接收和服务与给定资源相关联的请求的能力。例如，AE可以接收为给定<container>资源创建新鲜的<contentInstance>的请求。

CSE 304可以支持不同的方法来确定向内容源AE 302发送请求以服务的时间对比CSE 304使用本地存储的目标资源的表示来服务请求本身的时间。一种这样的方法可以涉及使用oneM2M定义的createdAfter过滤器参数在检索请求内指定的新鲜度时间。使用此请求参数，请求者可以在请求中指定新鲜度时间戳。CSE 304可以将目标资源的一个或多个本地存储的表示的creationTime(和/或建议的contentTimestamp属性)与该createdAfter过滤器参数进行比较。如果发现creationTime比createdAfter时间戳更新(更接近或更及时)，则CSE 304可以在不涉及内容源AE 302的情况下服务请求本身。但是，如果creationTime较旧，则CSE 304可以向对应的内容源AE 202的pointOfContact发起请求，以试图获得服务于检索请求的资源表示的新鲜版本，并满足其指定的新鲜度偏好或要求。

图14示出了示例性的oneM2M基于新鲜度的内容检索消息流程。虽然使用oneM2M<container>和<contentInstance>资源类型显示此过程，但类似的过程也可用于其他oneM2M资源类型，例如<flexContainers>、mgmtObj、mgmtCmd等。

在步骤310，内容源AE 302和内容请求AE 306认证CSE 304并且然后向CSE 304注册。内容请求AE 306然后发现内容源AE 302。在步骤311-313，内容源AE 302创建<container>资源并配置其pointOfContact信息(例如，URI)。在步骤311，内容源AE 302发送创建<container>并配置pointOfContact消息，其可以具有以下中的一个或多个：(to＝<AE>,pointOfContact＝Source AE Addr Info)。在步骤312，CSE 204基于步骤311创建<container>资源并配置源AE的pointOfContact信息。在步骤313，CSE 304可以发送响应消息，该响应消息可以包括对请求的一般确认或请求的完成。

在图14的步骤314-316处，内容源AE 302在<container>资源内创建一个或多个<contentInstance>子资源。每个<contentInstance>由CSE 304创建和存储(步骤315)。内容源AE 302还可以提供内容实例(例如，传感器读数)何时由内容源AE 302生成或捕获的contentTimestamp。此外，CSE 304可以将creationTime分配给<contentInstance>，指示内容实例在CSE 304中创建的时间。

继续参考图14，在步骤317-319，每当尝试检索请求以检索订阅的<container>资源的最新<contentInstance>，并且<contentInstance>资源不存在或其creationTime早于检索请求的createdAfter filterCriteria中指定的时间时，内容源AE 302可订阅<container>以从CSE 304接收通知。为此，内容源AE 302可以按照本文定义的新格式配置订阅的通知eventType和内容类型。在步骤317，内容源AE发送消息以创建订阅，该订阅可以具有以下信息：(to＝<container>)。在步骤318，CSE 304(响应于步骤317)创建<subscription>资源。在步骤319，可以发送响应。

在图14的步骤320，内容请求AE 306向CSE 304发出请求以检索存储在内容源AE302的目标<container>中的最新<contentInstance>资源。请求中包括指定的createdAfter参数，其可以包括时间和日期信息。内容请求AE 306可以使用该参数来指定它需要不早于指定时间和日期的内容。在步骤321，CSE 304将请求的createdAfter参数内的指定时间和日期信息与存储在<container>资源内的最新<contentInstance>(如果存在)的creationTime(或contentTimestamp)进行比较。从该比较中，CSE 304确定<contentInstance>是否可用，并且如果如此，则确定其是否满足内容请求AE 306的新鲜度要求。在步骤322，在图14的框323内，如果CSE 304找到满足指定createdAfter需求的<contentInstance>，则它可以返回包含<contentInstance>的对内容请求AE 306的响应。在这种情况下，CSE 304不需要向内容源AE 302发起请求以获得新鲜的<contentInstance>。

继续参考图14，如果存储的内容实例不满足新鲜度偏好或要求，则进行到框324。在步骤325，如果CSE 304没有找到满足指定的createdAfter要求(即，阈值时段)的<contentInstance>，则CSE 304可以向内容请求AE 306返回确认(即，非阻止响应)，使得内容请求AE 306当CSE 304尝试从内容源AE 302获得新鲜的<contentInstance>时不需要阻止和等待。步骤325的该确认(即，非阻止响应)可以包括指示请求被接收并且仍在处理的状态，因为CSE 304没有满足内容请求AE 306的新鲜度要求的本地托管的<contentInstance>。步骤325的确认还可以包括CSE回调地址(例如，URI)，其可以由内容请求AE 306用于在其变得可用时来检索或订阅以接收新鲜的<contentInstance>。例如，内容请求AE 306可以周期性地轮询或订阅(参见步骤326)该地址，并且当CSE 304能够从内容源AE 302获得新鲜的<contentInstance>或者如果CSE 304不能成功地从内容源AE 302获得新鲜的<contentInstance>则获得错误条件时，接收新鲜的<contentInstance>。或者，CSE 304可以选择以阻止方式处理该请求，在这种情况下，它不会在该步骤325中向内容请求AE 306返回确认。相反，它将阻止响应内容请求AE 306直到该过程中的步骤331，如图14所显示。

在图14的步骤327，CSE 304向内容源AE 302发起请求新鲜<contentInstance>的请求。可以使用若干不同类型的建议请求之一将该请求传递到内容源AE 302。参考第一建议请求，CSE 304可以发起针对由内容源AE 302在步骤311中指定的pointOfContact的检索请求。该请求还可以包含createdAfter参数，该参数可以配置有与来自内容请求AE 306的原始请求中的时间戳相同的时间戳。或者，如果步骤317中描述的订阅请求是由内容源AE302执行的，则CSE 304可以向内容源AE 302发起通知请求。该通知可以包含诸如本文(例如，与表6相关的讨论)所公开的那些之类的元素。

在图14的步骤328，在从CSE 304接收到步骤327的请求时，内容源AE 302可以处理和检测请求的类型(例如，检索或通知)。如果步骤327的请求是检索，则内容源AE 302可以分析在请求中的指定的地址和createdAfter参数(如果存在)以确定正在请求哪个内容，并且继而准备<contentInstance>以在检索响应中返回到CSE 304。如果请求是通知，则内容源AE 302可以通过检查contentRequest元素是否存在并且被配置为TRUE来检测它是对内容的请求。如果内容源AE 302支持多于一种类型的内容，则它可以检查contentReference元素以检测CSE 304正在请求哪种类型的内容。然后，它可以检查contentPriority或contentSchedule元素以确定何时它必须向CSE 304提供新鲜的<contentInstance>。内容源AE 302还可以检查contentFreshness参数以查看是否指定了内容的所需新鲜日期或时间。如果指定了一个，则内容源AE 302可以确保在该日期和时间之前没有生成它提供的任何<contentInstance>。

在图14的步骤329，内容源AE 302可以用若干方法之一以新鲜内容实例更新CSE304。如果CSE 304向内容源AE 302发出请求新鲜的<contentInstance>的显式检索请求，则内容源AE 302可以在检索响应中包括新鲜的<contentInstance>。如果CSE 304向内容源AE302发出指示需要新鲜的<contentInstance>的通知，则内容源AE 302可以在通知响应中包括新鲜的<contentInstance>，或者可选地，内容源AE 302可以跟进单独请求(例如，创建请求)以在通知请求中的contentReference元素指定的<container>资源中创建新鲜的<contentInstance>。在步骤330，如果成功返回或创建了新鲜的<contentInstance>，则CSE304存储新鲜<contentInstance>的本地版本，使得它可以用于服务未来请求或用于诸如计费和分析之类的目的等等。CSE 304还可以可选地分配相应的时间戳以跟踪何时在CSE 304中创建<contentInstance>。在步骤331，如果新鲜的<contentInstance>成功发布到CSE304，则将其返回到内容请求AE 306，否则返回错误。

参考图15的以下内容通过添加所公开的基于新鲜度的内容发现方面来增强现有的oneM2M定义的资源发现过程。机制允许CSE 304检测内容请求AE 306感兴趣的<contentInstance>资源何时是陈旧的何时不是，并且联系相应的内容源AE 302以使其提供CSE 304然后可以在发现响应中引用的新鲜的<contentInstance>。图15示出了示例性的oneMM基于新鲜度的资源发现消息流程。虽然使用oneM2M<container>和<contentInstance>资源类型显示此过程，但类似的过程也可用于其他oneM2M资源类型，例如<flexContainers>、mgmtObj、mgmtCmd等。

图15的框340具有与关于图14所示和讨论的相同的步骤310-319。在图15的步骤341，内容请求AE 306请求CSE 304发现与特定<container>资源相关联的<contentInstance>资源。请求中包括的可以是指定的createdAfter参数，其配置有内容请求AE 306使用来指定其希望发现不早于指定时间和日期的内容的时间和日期信息。另外，该请求还可以包括其他发现过滤标准(例如，内容的类型)。在步骤342，CSE 304将内容发现请求的createdAfter参数内的指定时间和日期信息与CSE 304在目标<container>资源内托管的每个适用<contentInstance>资源的时间戳进行比较。从该比较，CSE 304确定任何适用的<contentInstance>资源是否具有比指定的createdAfter参数更新的creationTime或contentTimestamp。如果没有找到，则CSE 304可以生成事件以从相应的内容源AE用信号通知新鲜的<contentInstance>，使得CSE 304可以在其发送到内容请求AE 306的发现响应中包括对该内容的引用(例如，URI)，并且当内容请求AE 306发送访问<contentInstance>的后续请求时，CSE 304使内容准备就绪并可用。该事件继而可以被CSE 304用作尝试并从内容源AE 302获得新鲜的<contentInstance>的触发器，如在关于图14指定的oneM2M基于新鲜度的内容检索过程中的步骤325-330中概述的建议过程所定义的。可以基于是否已在目标<container>资源中配置了适用的pointOfContact属性来限制触发器的生成。如果未配置pointOfContact，则可以抑制触发器。

继续参考图15，在框344的步骤343，如果CSE 304找到满足createdAfter时间戳的<contentInstance>，则它可以返回对内容请求AE 306的响应，该响应在发现响应中包括对该内容的引用(例如，URI)。在这种情况下，CSE 304不需要启动刷新其本地存储的<contentInstance>资源。

当存储的内容实例不满足新鲜度偏好或要求时，框345发生，其可以启动按需刷新。框346包含与图14的步骤325-330相同的步骤。在步骤347，如果从内容源AE 302成功地将新鲜的<contentInstance>发布到CSE 304，则在发现响应中返回对该内容的引用(例如，URI)，否则返回错误。在步骤348，内容请求AE 306处理发现响应，并随后检索满足其新鲜度偏好或要求的一个或多个发现的内容实例(基于响应中的指定引用)。

参考图16的以下过程通过添加这里公开的基于新鲜度的内容检索方面来增强现有的oneM2M定义的设备触发过程。机制允许CSE检测内容请求AE感兴趣的<contentInstance>资源何时是陈旧的，并且继而联系相应的内容源AE 302(通过设备触发器)以使其提供新鲜的<contentInstance>，使得CSE 304可以完成其对检索请求的处理。尽管使用oneM2M<container>和<contentInstance>资源类型示出了该过程，但是类似的过程也可以用于其他oneM2M资源类型，例如<flexContainers>、mgmtObj、mgmtCmd等。图17的框350包括与图14和图15的非场景B框351步骤(例如，图14的步骤310-322)类似的步骤。

继续参考图16，在步骤352，CSE 304向内容源AE 302发起设备触发请求，请求新鲜的<contentInstance>。步骤352的设备触发请求可以从CSE 304发送到由底层网络(例如，3GPP MTC-IWF)支持的设备触发功能303。步骤352的设备触发请求消息可以包含如本文所公开的关于设备触发的元素。在步骤353，在接收到设备触发请求时，内容源AE 302可以处理它。内容源AE 302可以通过检查contentRequest元素是否存在并且被配置为TRUE来检测它是对内容的请求。如果内容源AE 302支持多种类型的内容，则它可以检查contentReference元素以检测CSE 304正在请求哪种类型的内容。然后，它可以检查contentPriority或contentSchedule元素以确定它何时必须向CSE 304提供新鲜的<contentInstance>。它还可以检查内容Freshness参数，以查看是否指定内容的所需新鲜日期或时间。如果指定了一个，则内容源AE 302可以确保在该日期和时间之前没有生成它提供的任何<contentInstance>。

在步骤355，内容源AE 302可以用若干方法之一以新鲜内容实例更新CSE 304。内容源AE 302可以在设备触发响应中包括新鲜的<contentInstance>，或者内容源AE 302可以跟进对CSE 304的单独请求(例如，创建请求)以在触发器请求中的contentReference元素指定的<container>资源中创建新鲜的<contentInstance>。在步骤357，如果成功返回或创建了新鲜的<contentInstance>，则CSE 304存储新鲜的<contentInstance>的本地版本，使得可以利用它来服务于将来的请求。图16的框259具有与图14的步骤331或图15的步骤247和248中指定的基于新鲜度的内容检索和发现过程中定义的相同的步骤。

参考图17的以下过程基于本文公开的重新定向功能等来增强现有的oneM2M定义的资源过程。机制允许CSE 304检测何时更新目标资源并将请求重新定向到相应的请求接收AE以使其更新其本地版本。虽然使用oneM2M<mgmtObj>资源类型显示此过程，但类似的过程也可用于其他oneM2M资源类型，例如<container>、<flexContainers>、<mgmtCmd>等。

继续参考图17，在步骤360，请求接收AE 307和请求发起AE 309认证CSE 304并然后向CSE 304注册。请求发起AE 309然后发现请求接收AE 307。在步骤361-363，请求接收AE307创建软件<mgmtObj>资源并配置其pointOfContact信息(例如，URI)及其accessControlPolicies。这些策略可以包括重新定向规则，例如允许向请求接收AE 307发出请求的请求发起AE 209的列表、允许重新定向的允许请求类型的列表、定义可以重新定向请求的时间的时间表。在步骤364-366，每当尝试UPDATE请求并且UPDATE改变请求接收AE307感兴趣(如在re-targetPolicies中指定)的<mgmtObj>资源属性之一的状态时，请求接收AE 307可以订阅<mgmtObj>以从CSE 304接收通知。为此，请求接收AE 307可以按照本文定义的新提议格式配置订阅的通知eventType和内容类型。在步骤367，请求发起AE向CSE304发出请求以将激活属性更新为<mgmtObj>资源中的值“TRUE”。

在图17的步骤368，CSE 304分析请求发起AE 309的请求所针对的资源的重新定向策略。使用这些策略，CSE 304可以执行检查，诸如请求发起AE 309是否被授权向请求接收AE 307发出请求，请求类型是否是被授权被重新定向的请求类型，以及基于指定的时间表确定何时将请求重新定向到请求接收AE 307，等等。然后，CSE 304将存储在服务层中的<mgmtObj>资源的当前表示与包含在UPDATE请求中的表示进行比较。该比较可以考虑定义要比较(或不比较)的资源属性的子集的掩码，使得仅将某些属性彼此进行比较。该比较由于激活属性的状态改变而导致不匹配。因此，CSE 304决定它需要将UPDATE请求重新定向到请求接收AE 307。

在图17的步骤369，CSE 304将UPDATE请求重新定向到请求接收AE 307以被服务。可以使用若干不同类型的建议请求之一将该请求传递到请求接收AE 307。在步骤361中，CSE 304可以发起针对由请求接收AE 307指定的pointOfContact的UPDATE请求。其次，如果在步骤364中描述的订阅请求是由请求接收AE 307执行的，则服务层(CSE 204)可以向请求接收AE 307发起通知请求。该通知可包含本文所公开的元素。第三，如果请求接收AE 307不可达，则CSE 304可以向请求接收AE 307发起设备触发请求。该设备触发请求可以包含诸如本文所公开的那些的元素。在步骤370，在从CSE 304接收到请求时，请求接收AE 307可以处理和检测请求的类型(例如，UPDATE或NOTIFY或DEVICE TRIGGER)。例如，如果请求是UPDATE，则请求接收AE 307可以分析指定的地址并执行对AE的本地<mgmtObj>的更新，并在UPDATE响应中向CSE 304返回响应。如果请求是NOTIFY或DEVICE TRIGGER，则请求接收AE307可以通过检查updateRequest元素是否存在并且被配置为TRUE来检测它是对UPDATE的请求。如果请求接收AE 307支持多种类型的内容，则它可以检查requestReference元素以检测CSE 304正在请求什么更新。

在图17的步骤371，请求接收AE 307可以以若干提出的方法之一响应CSE 304。如果CSE 304向请求接收AE 307发出明确的UPDATE请求，则请求接收AE 307可以用UPDATE响应进行响应。如果CSE 304向请求接收AE 307发出NOTIFY或DEVICE TRIGGER，则请求接收AE307可以分别以通知或设备触发响应响应回去。在步骤372，在从请求接收AE 307接收到响应时，CSE 304就对其资源的本地版本执行相同的更新(例如，将状态改变为值“ON”)。在步骤373，CSE 304响应回请求发起AE 309，指示UPDATE请求被成功处理。在步骤374，请求发起AE 309发送与第一UPDATE相同的第二UPDATE请求。在步骤375，CSE执行与步骤368中描述的类似的处理。CSE检测到比较导致匹配(“ON”的更新值与当前值相同)并且确定不将UPDATE请求重新定向到请求接收AE 307。在步骤376，CSE 304更新其本地元数据以跟踪来自请求发起AE 309的UPDATE请求被处理的事实，即使它没有被重新定向到请求接收AE 307。这对于跟踪请求发起AE 309的请求历史可能是有用的，以用于诸如计费和分析的目的。在步骤377，CSE 304响应回请求发起AE 309，指示UPDATE请求被成功处理。

图18示出了示例性CoRE镜像服务器基于新鲜度的内容检索消息流程，其中，基于新鲜度的内容发现、内容检索和请求重新定向想法被集成到CoRE镜像服务器(即，镜像服务器404)中。镜像服务器404可以支持基于新鲜度的内容发现和检索请求，其中，镜像服务器404可以使用镜像资源表示来服务这些请求，只要这些表示满足在GET请求中指定的新鲜度要求即可。否则，镜像服务器404可以发起对相应设备的GET请求以获得然后它可以使用来服务原始请求的目标资源的新鲜表示，如下面图18中捕获的过程所示。针对该实施例的一个提议的协议级增强包括新的新鲜度参数的定义(如步骤416所示)，其可以在GET请求内配置以指定它正在针对的资源表示的所需新鲜度(例如，日期和时间值)。新鲜度参数可以实现为可以包括在URI查询字符串中的查询字符串参数。或者，可以将新鲜度参数实现为新的CoAP头选项(或者如果镜像服务器404正在使用它，则可以将其实现为HTTP)。

继续参考图18，在步骤410，SEP 402向镜像服务器404注册并提供SEP 402本地托管并希望镜像服务器404代表其进行镜像的支持资源的列表。在步骤411，镜像服务器404创建SEP 402的资源的镜像版本，并且还保持由SEP 402本地托管的信息(例如，每个资源的URI)的目录。在步骤412，镜像服务器404响应于SEP 402并包括镜像资源的列表。在步骤413-415，SEP 402更新镜像服务器404上的一个或多个镜像资源。每个更新由镜像服务器404存储。SEP 402还可以提供何时由SEP 402生成或捕获内容(例如，传感器读数)的contentTimestamp。镜像服务器404还可以向镜像资源分配creationTime，指示在镜像服务器404处更新内容实例的时间。在步骤416，客户端406向镜像服务器404发出请求以检索镜像服务器404托管的镜像资源。包含在请求中的可以是配置有时间和日期信息的指定新鲜度参数。客户端406可以使用该参数来指定它需要不早于指定时间和日期的内容。

在图18的步骤417，镜像服务器404将请求的新鲜度参数内的指定时间和日期信息与镜像服务器404托管的镜像resourceA(如果存在)的creationTime(或contentTimestamp)进行比较。从该比较，镜像服务器404确定是否资源A可用，并且如果如此则确定其是否满足客户406的新鲜度要求。在框419内的步骤418，如果镜像服务器404找到满足指定新鲜度要求的resourceA，则它可以向客户端406返回包含resourceA的表示的响应。在这种情况下，镜像服务器404不需要向SEP402发起请求以获得resourceA的新鲜表示。

当镜像资源不满足新鲜度要求时，框420发生，其启动按需刷新。在步骤421，如果镜像服务器404没有找到满足指定的新鲜度要求的镜像资源A，则它可以可选地向客户端406返回确认，使得客户端406不需要在镜像服务器404尝试获得来自SEP 402的新鲜资源时阻止和等待。该确认可以包括指示请求已被接收并且仍在处理的状态，因为镜像服务器404没有满足客户406的新鲜度偏好或要求的本地托管的资源A的镜像版本。确认还可以包括镜像服务器404回调地址(例如，URI)，客户端406可以使用该回调地址(例如，URI)在其变得可用时接收新资源A。例如，当镜像服务器404能够从SEP 402获得新资源A时，客户端406可以周期性地轮询或观察该地址并接收新鲜资源A，或者如果镜像服务器404未能成功从SEP402获得新鲜资源A，则客户端406可以接收新鲜资源A。或者，镜像服务器404可以选择以阻止方式处理请求，在这种情况下，它不会在该步骤中向客户端406返回确认。相反，它将阻止响应客户端406直到该过程中的步骤426。

继续参考图18，在步骤422，镜像服务器404对于SEP 402发起请求，请求新鲜resourceA(资源A)。可以使用GET请求将该请求传递到SEP 402。镜像服务器404可以在步骤410中发起针对由SEP 402指定的URI的检索请求。该请求还可以包含可选的新鲜度参数，其可以配置有与来自客户端406的原始请求中的时间戳相同的时间戳。在步骤423，在接收到步骤422的请求时，SEP 402可以处理该请求。SEP 402可以分析指定的地址和新鲜度参数(如果在请求中存在)，以确定正在请求哪个内容，并进而准备resourceA以在检索响应中返回镜像服务器404。在步骤424，SEP 402可以用检索响应中的新鲜resourceA更新镜像服务器404。在步骤425，如果成功返回新鲜resourceA，则镜像服务器404存储新鲜resourceA的本地版本，使得它可以被利用来服务未来请求或者也用于诸如计费和分析之类的目的。镜像服务器404还可以可选地分配相应的时间戳以跟踪镜像服务器404中何时创建resourceA。在步骤426，如果新鲜resourceA成功发布到镜像服务器404，则它返回到客户端406，否则返回错误。

类似地，镜像服务器404可以支持基于新鲜度的请求重新定向，其中，镜像服务可以评估PUT或CREATE请求的有效载荷以确定语义资源表示是否与镜像资源表示相同。如果相同，则镜像服务器404可以将PUT或CREATE操作视为陈旧并且不将该请求重新定向到设备。如果不相同，则镜像服务器404可以认为该请求是新鲜的并且将其重新定向到所述设备以进行服务。

在不过度限制本文出现的权利要求的范围、解释或应用的情况下，以下是与在M2M/IoT环境中如何处理请求等相关联的本文公开的一个或多个示例的示例性技术效果。这里公开的一个或多个示例的技术效果可以是物联网设备上的减少的负载，因为当相应的内容请求app更喜欢比服务层中存储的版本更新鲜的资源的版本或请求发起app更愿意将请求重新定向到特定设备时，通常触发或通知托管内容源app或请求接收app的设备。本文公开的一个或多个示例的另一技术效果是，与传统实现相比，服务层可以提供对内容请求app本来不能访问的新鲜内容的增加的可用性。这消除了内容请求app仅可以访问存储在服务层中的内容的限制。这创建了更灵活和强大的服务层框架，以支持更多需要新鲜内容的用例。本文公开的一个或多个示例的另一技术效果是，与传统实现相比，可以允许托管内容源app或请求接收app的设备休眠，直到内容请求app或请求发起app想要访问当前未由服务层托管的新鲜内容，或将内容更新为与其当前状态不同的状态。缺乏对新鲜内容的需求使设备能够保持睡眠状态。

另一技术效果可以是通过减少消息的数量来节省网络带宽并且可以节省用于接收设备(例如，图8的致动或其他终端设备)的电池寿命，因为它不处理不必要的请求(例如，重复请求)。在一个例子中，如果有多个用户试图解锁同一扇门，那么其中只有一个需要解锁门，其他试图解锁门的请求实际上可以看作是重复的，而且它们实际上不是“新鲜的”，所以可以过滤它们。并且通过这样做，服务层提供了增值。可能存在过去命令的一些比较以及是否将请求转发或重新定向到致动器类型设备的确定。

图20示出了可以基于诸如基于新鲜度的内容检索服务的本文所讨论的方法和系统生成的示例性显示(例如，图形用户界面)。显示界面901(例如，触摸屏显示器)可以在框902中提供与请求处理相关联的文本，包括结果。当被选择时，框902的部分可以给出附加信息，例如表1到表6的参数。在另一个示例中，可以在框902中显示这里讨论的任何步骤的进度(例如，步骤的发送消息或成功)。另外，图形输出903可以显示在显示界面901上。图形输出903可以是请求处理中的设备的拓扑或这里讨论的任何方法或系统的进度的图形输出等。显示界面901可以被实现用于配置或编程从这里讨论的设备发现和检索的内容的所需新鲜度。例如，在参考图6的用例中，可以通过应用121向医生提供用户界面，该应用允许医生为特定患者指定血液胰岛素、血压、血氧和心率读数的优选或所需新鲜度，如图20所示。

图21A是示例性机器到机器(M2M)、物联网(IoT)或物品万维网(WoT)通信系统10的图，其中，一个或多个公开的概念与服务层的请求处理相关联(例如，图6-图20和随附的讨论)。通常，M2M技术为IoT/WoT提供构建块，并且任何M2M设备、M2M网关或M2M服务平台可以是IoT/WoT的组件以及IoT/WoT服务层等。

如图21A所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如，以太网、光纤、ISDN或PLC等)或无线网络(例如，WLAN或蜂窝等)或异构网络的网络。例如，通信网络12可以包括多个接入网络，其向多个用户提供诸如语音、数据、视频、消息或广播等的内容。例如，通信网络12可以采用一种或多种信道接入方法，例如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)和单载波FDMA(SC-FDMA)等。此外，通信网络12可以包括其他网络，例如核心网络、因特网、传感器网络、工业控制网络、个人区域网络、融合个人网络、卫星网络、家庭网络或企业网络。

如图21A所示，M2M/IoT/WoT通信系统10可以包括基础设施域和现场域。基础设施域是指端到端M2M部署的网络侧，并且现场域是指通常在M2M网关后面的区域网络。现场域包括M2M网关14和终端设备18。可以理解，根据需要，任何数量的M2M网关设备14和M2M终端设备18可以被包括在M2M/IoT/WoT通信系统10中。M2M网关设备14和M2M终端设备18中的每一个被配置为经由通信网络12或直接无线电链路发送和接收信号。M2M网关设备14允许无线M2M设备(例如，蜂窝和非蜂窝)以及固定网络M2M设备(例如，PLC)通过诸如通信网络12或直接无线电链路的运营商网络进行通信。例如，M2M设备18可以收集数据并经由通信网络12或直接无线电链路将数据发送到M2M应用20或M2M设备18。M2M设备18还可以从M2M应用20或M2M设备18接收数据。此外，如下所述，数据和信号可以经由M2M服务层22发送到M2M应用20并且可以从M2M应用20接收数据和信号。M2M设备18和网关14可以经由各种网络进行通信，各种网络包括例如蜂窝、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线线路。

参见图21B，所示的在现场域中的M2M服务层22(例如，服务层204)为M2M应用20(例如，请求接收app 203或内容源app 202)、M2M网关设备14以及M2M终端设备18和通信网络12提供服务。应当理解，M2M服务层22可以根据需要与任何数量的M2M应用、M2M网关设备14、M2M终端设备18和通信网络12通信。M2M服务层22可以由一个或多个服务器或计算机等实现。M2M服务层22提供应用于M2M终端设备18、M2M网关设备14和M2M应用20的服务能力。M2M服务层22的功能可以以各种方式实现，例如作为web服务器、在蜂窝核心网中、在云中等。

类似于所示的M2M服务层22，在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和底层通信网络12'提供服务。M2M服务层22'还为现场域中的M2M网关设备14和M2M终端设备18提供服务。将理解，M2M服务层22'可以与任何数量的M2M应用、M2M网关设备和M2M终端设备通信。M2M服务层22'可以通过不同的服务提供商与服务层交互。M2M服务层22'可以由一个或多个服务器、计算机或虚拟机(例如，云/计算/存储集群等)等实现。

还参见图21B，M2M服务层22和22'提供各种应用和垂直可以利用的服务递送能力的核心集。这些服务能力使M2M应用20和20'能够与设备交互并执行诸如数据收集、数据分析、设备管理、安全性、计费、服务/设备发现等功能。基本上，这些服务能力免除了应用的实现这些功能的负担，从而简化应用开发并减少上市的成本和时间。服务层22和22'还使M2M应用20和20'能够通过各种网络12和12'与服务层22和22'提供的服务相关联地进行通信。

在一些示例中，M2M应用20和20'可以包括使用请求处理等进行通信的期望应用，如本文所讨论的。M2M应用20和20'可以包括各种行业中的应用，例如但不限于运输、健康和保健、连接的家庭、能源管理、资产跟踪以及安全和监视。如上所述，在系统的设备、网关和其他服务器之间运行的M2M服务层支持诸如数据收集、设备管理、安全性、计费、位置跟踪/地理围栏、设备/服务发现和传统系统集成的功能，并将这些功能作为服务提供给M2M应用20和20'。

本申请的请求处理方法和系统可以实现为服务层的一部分。服务层(例如，服务层204)是中间件层，其通过一组应用编程接口(API)和底层网络接口来支持增值服务能力。M2M实体(例如，在硬件上实现的诸如设备、网关或服务/平台的M2M功能实体)可以提供应用或服务。ETSI M2M和oneM2M都使用可包含本申请的请求处理等的服务层。ETSI M2M的服务层称为服务能力层(SCL)。SCL可以实现在M2M设备(其中其被称为设备SCL(DSCL))、网关(其中其被称为网关SCL(GSCL))和/或网络节点(其中其被称为网络SCL(NSCL))内。oneM2M服务层支持一组公共服务功能(CSF)(即服务能力)。一组一个或多个特定类型的CSF的实例化被称为公共服务实体(CSE)，其可以托管在不同类型的网络节点(例如，基础设施节点、中间节点、应用特定节点)上。此外，本申请的请求处理方法和系统可以实现为M2M网络的一部分，该M2M网络使用面向服务的体系结构(SOA)和/或面向资源的体系结构(ROA)来访问诸如本申请的请求处理方法和系统之类的服务。

如本文所讨论的，服务层可以是在网络服务架构内的功能层。服务层通常位于诸如HTTP、CoAP或MQTT的应用协议层之上，并为客户端应用提供增值服务。服务层还提供到在诸如控制层和传输/接入层的较低资源层处的核心网络的接口。服务层支持多种类别的(服务)能力或功能，包括服务定义、服务运行时启用、策略管理、访问控制和服务集群。最近，诸如oneM2M的若干行业标准组织一直在开发M2M服务层，以解决与M2M类型的设备和应用集成到诸如因特网/Web、蜂窝、企业和家庭网络的部署中相关联的挑战。M2M服务层可以向应用或各种设备提供对由服务层(其可以被称为CSE或SCL)支持的上述能力或功能的集合或一组上述能力或功能的访问。一些示例包括但不限于安全性、计费、数据管理、设备管理、发现、供应和连接管理，其可以被各种应用共同使用。通过API使这些各种应用可以使用这些能力或功能，所述API利用由M2M服务层定义的消息格式、资源结构和资源表示。CSE或SCL是功能实体，其可以由硬件或软件实现，并且提供对各种应用或设备开放的(服务)能力或功能(即，这些功能实体之间的功能接口)，以便它们使用这样的能力或功能。

图21C是诸如M2M终端设备18或M2M网关设备14的示例M2M设备30的系统图。如图21C所示，M2M设备30可以包括处理器32、收发器34、发送/接收元件36、扬声器/麦克风38、键盘40、显示器/触摸板42、不可移动存储器44、可移动存储器46、电源48、全球定位系统(GPS)芯片组50和其他外围设备52。应当理解，M2M设备30在保持与所公开的主题一致的同时可以包括前述元件的任何子组合。M2M设备30可以是执行所公开的用于请求处理的系统和方法的示例性实现。内容源app 202、服务层204、内容请求app 206、请求接收app 203、请求发起app 205和控制app 141等可以驻留在具有诸如M2M设备30之类的特征的设备上。内容源app202、服务层204、内容请求app 206、请求接收app 203、请求发起app 205、控制app 141可以经常驻留在M2M终端设备18上。镜像服务器404、服务层204和CSE 304等可以经常驻留在M2M网关设备14上。

处理器32可以是通用处理器、专用处理器、传统处理器、数字信号处理器(DSP)、多个微处理器、与DSP内核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其他类型的集成电路(IC)和状态机等。处理器32可以执行信号编解码、数据处理、功率控制、输入/输出处理和/或使M2M设备30能够在无线环境中操作的任何其他功能。处理器32可以耦合到收发器34，收发器34可以耦合到发送/接收元件36。虽然图21C将处理器32和收发器34描绘为单独的组件，但是应当理解，处理器32和收发器34可以一起集成在电子封装或芯片中。处理器32可以执行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或通信。处理器32可以例如在接入层和/或应用层执行安全操作，例如认证、安全密钥协商和/或加密操作。

发送/接收元件36可以被配置为向M2M服务平台22发送信号或从M2M服务平台22接收信号。例如，发送/接收元件36可以是配置成发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，例如WLAN、WPAN和蜂窝等。在示例中，发送/接收元件36可以是发射器/检测器，其被配置为例如发送和/或接收IR、UV或可见光信号。在又一示例中，发送/接收元件36可以被配置为发送和接收RF和光信号。应当理解，发送/接收元件36可以被配置为发送和/或接收无线或有线信号的任何组合。

另外，尽管在图21C中作为单个元件描绘了发送/接收元件36，但是M2M设备30可以包括任何数量的发送/接收元件36。更具体地，M2M设备30可以采用MIMO技术。因此，在示例中，M2M设备30可以包括用于发送和接收无线信号的两个或更多个发送/接收元件36(例如，多个天线)。

收发器34可以被配置为调制将由发送/接收元件36发送的信号并且解调由发送/接收元件36接收的信号。如上所述，M2M设备30可以具有多模能力。因此，收发器34可以包括多个收发器，用于使M2M设备30能够经由诸如UTRA和IEEE 802.11的多个RAT进行通信。

处理器32可以从诸如不可移动存储器44和/或可移动存储器46的任何类型的合适存储器访问信息，并将数据存储在其中。不可移动存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其他类型的存储器存储设备。可移动存储器46可以包括用户标识模块(SIM)卡、记忆棒和安全数字(SD)存储卡等。在其他示例中，处理器32可以从物理上不位于M2M设备30上(例如在服务器或家用计算机上)的存储器访问信息，并将数据存储在其中。处理器32可以被配置为响应于本文描述的一些示例中的请求处理方法是成功还是不成功(例如，设备触发、新鲜度等)来控制显示器或指示器42上的照明图案、图像或颜色，或以其他方式指示请求处理系统和方法以及相关组件的状态。在显示器或指示器42上的控制照明图案、图像或颜色可以反映本文所示或所讨论的图中(例如，图9至图12和图14至图18等)的任何方法流程或组件的状态。这里公开了服务层相关请求处理的消息和过程。可以扩展消息和过程以为用户提供界面/API以经由输入源(例如，扬声器/麦克风38、小键盘40或显示器/触摸板42)请求与资源相关的资源并且请求、配置或查询服务层相关联的请求处理资源以及可以在显示器42上显示的其他内容。

处理器32可以从电源48接收电力，并且可以被配置为向M2M设备30中的其他组件分配电力和/或控制去往M2M设备30中的其他组件的电力。电源48可以是用于为M2M供电的任何合适的设备。例如，电源48可包括一个或多个干电池(例如，镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li-ion)等)、太阳能电池和燃料电池等。

处理器32还可以耦合到GPS芯片组50，其被配置为提供关于M2M设备30的当前位置的位置信息(例如，经度和纬度)。应当理解，M2M设备30可以在保持与本文公开的信息一致的同时通过任何合适的位置确定方法获取位置信息。

处理器32还可以耦合到其他外围设备52，其可以包括提供附加特征、功能或者有线或无线连接的一个或多个软件或硬件模块。例如，外围设备52可以包括各种传感器，诸如加速度计、生物识别(例如，指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其他互连接口、振动设备、电视收发器、免提耳机、蓝牙模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块和互联网浏览器等。

发送/接收元件36可以包含在其他装置或设备中，例如传感器、消费电子产品、诸如智能手表或智能服装的可穿戴设备、医疗或电子健康设备、机器人、工业设备、无人机、诸如汽车、卡车、火车或飞机的运输工具。发送/接收元件36可以经由一个或多个互连接口连接到这种装置或设备的其他组件、模块或系统，该接口例如是可以包括外围设备52之一的互连接口。

图21D是示例性计算系统90的框图，在该计算系统90上，例如，可以实现图21A和图21B的M2M服务平台22。计算系统90(例如，M2M终端设备18或M2M网关设备14)可以包括计算机或服务器，并且可以主要被存储或访问这些指令的任何装置通过计算机可读指令来控制。这样的计算机可读指令可以在中央处理单元(CPU)91内执行，以使计算系统90进行工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单芯片CPU实现。在其他机器中，中央处理单元91可包括多个处理器。协处理器81是与主CPU 91不同的可选处理器，其执行附加功能或辅助CPU 91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于请求处理(例如内容的新鲜度、重新定向和触发)的系统和方法有关的数据。

在操作中，CPU 91获取、解码和执行指令，并经由计算机的主数据传输路径，即系统总线80向其他资源传输信息和从其他资源传输信息。这样的系统总线连接计算系统90中的组件并定义用于数据交换的媒介。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线以及用于发送中断和用于操作系统总线的控制线。这种系统总线80的一个例子是PCI(外围部件互连)总线。

耦合到系统总线80的存储器设备包括随机存取存储器(RAM)82和只读存储器(ROM)93。这种存储器包括允许存储和检索信息的电路。ROM 93通常包含不容易修改的存储数据。存储在RAM 82中的数据可以由CPU 91或其他硬件设备读取或改变。存储器控制器92可以控制对RAM 82和/或ROM 93的访问。存储器控制器92可以提供地址转换功能，该地址转换功能在执行指令时将虚拟地址转换为物理地址。存储器控制器92还可以提供存储器保护功能，其在系统内隔离进程并将系统进程与用户进程隔离。因此，以第一模式运行的程序只能访问由其自己的进程虚拟地址空间映射的存储器；除非已设置在进程之间的内存共享，否则它无法访问在另一进程的虚拟地址空间内的存储器。

另外，计算系统90可以包含外围设备控制器83，其负责将来自CPU 91的指令传送到外围设备，例如打印机94、键盘84、鼠标95和磁盘驱动器85。

由显示控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可包括文本、图形、动画图形和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸板来实现。显示控制器96包括产生发送到显示器86的视频信号所需的电子元件。

此外，计算系统90可以包含网络适配器97，网络适配器97可以用于将计算系统90连接到外部通信网络，例如图21A和图21B的网络12。

应当理解，本文描述的任何或所有系统、方法和过程可以以存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式体现，该指令在由诸如计算机、服务器、M2M终端设备或M2M网关设备等的机器执行时执行和/或实现这里描述的系统、方法和过程。具体地，上述任何步骤、操作或功能可以以这种计算机可执行指令的形式实现。计算机可读存储介质包括以用于存储信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质，但是这种计算机可读存储介质本身不包括信号。从本文的描述中可以明显看出，存储介质应该被解释为法定主题。计算机可读存储介质包括RAM、ROM、EEPROM、闪存或其他存储技术、CD-ROM、数字通用盘(DVD)或其他光盘存储器、磁带盒、磁带、磁盘存储器或其他磁存储设备或者可用于存储所需信息并可由计算机访问任何其他物理介质。

在描述如图中所示的本公开的主题——在服务层中的请求处理——的优选方法、系统或装置中，为了清楚起见使用了特定术语。然而，所要求保护的主题并不旨在限于如此选择的特定术语，并且应当理解，每个特定元件包括以类似方式操作以实现类似目的的所有技术等同物。

可结合硬件、固件、软件或在适当时的其组合来实施本文中所描述的各种技术。这样的硬件、固件和软件可以驻留在位于通信网络的各个节点处的装置中。所述装置可以单独操作或彼此组合操作以实现本文所述的方法。如这里所使用的，术语“装置”、“网络装置”、“节点”、“设备”或“网络节点”等可以互换使用。另外，除非本文另有规定，否则通常包含性地使用词语“或”。

除了别的以外，新鲜内容可以是基于时间的或基于状态的。例如，基于时间的新鲜内容可以与服务层托管内容相关联，该服务层托管内容具有比在内容检索或发现请求中包括的新鲜度参数中指定的数据和时间更新的创建日期。基于状态的新鲜内容可以与将服务层托管内容更新为与其当前语义状态不同的语义状态的请求相关联。

如本文所述的方法、系统和装置等可以提供用于管理服务层的内容的新鲜度(服务层中的请求处理)的装置。一种方法、系统、计算机可读存储介质或装置具有装置，所述装置用于：接收来自请求应用的消息，所述消息包括获得与服务相关联的内容和与所述服务相关联的所述内容的新鲜期的请求；基于所述消息中的要求确定所述内容的新鲜期在可接受的阈值时段之外；以及，响应于确定所述内容的所述新鲜期是在所述可接受的阈值时段之外：1)向所述请求应用发送非阻止响应，以及，2)基于联系点信息向内容源应用发送请求消息，以获得在所述可接受的阈值时段内的所述服务的更新内容。该方法、系统、计算机可读存储介质或装置具有下述装置，所述装置用于：基于对与所述服务相关联的所述内容的所述新鲜期以及与多个其他服务相关联的内容的新鲜期的分析来确定需要由服务层设备更新所述内容的时间表。对所述内容源应用的所述请求消息包括需要由服务层设备更新所述内容的时间表。所述非阻止响应包括回调地址，所述回调地址由所述请求应用用于在所述内容变得可用时订阅以接收在所述新鲜期内的内容。对所述内容源应用的所述请求消息包括与所述新鲜期对应的创建后参数。该方法、系统、计算机可读存储介质或装置具有下述装置，所述装置用于：基于对所述消息中的所述内容的所述新鲜期以及与多个其他消息相关联的所述内容的新鲜期的分析，确定需要由所述装置更新所述内容的时间表。所述联系点信息包括统一资源标识符。以与详细说明的其他部分一致的方式来考虑在本段落中的所有组合(包括步骤的去除和增加)。

本书面描述使用示例来公开包括具体实施方式的本发明，并且还使本领域技术人员能够实践本发明，包括制造和使用任何设备或系统以及执行任何结合的方法。本发明的可专利范围由权利要求限定，并且可以包括本领域技术人员想到的其他示例(例如，跳过步骤、组合步骤或在本文公开的示例性方法之间添加步骤)。如果这些其他示例具有与权利要求的字面语言没有不同的结构元件，或者如果它们包括与权利要求的字面语言无实质差别的等效结构元件，则这些其他示例意图处于权利要求的范围内。

Claims (15)

1.一种用于管理服务层的内容的新鲜度的装置，所述装置包括：

处理器；以及

存储器，所述存储器与所述处理器耦合，所述存储器包括存储在其上的可执行指令，所述可执行指令在由所述处理器执行时使所述处理器实现操作，所述操作包括：

从请求应用接收消息，所述消息包括获得与服务相关联的内容和与所述服务相关联的所述内容的新鲜期的请求；

基于所述消息中的要求确定所述内容的所述新鲜期在可接受的阈值时段之外；以及

响应于确定所述内容的所述新鲜期在所述可接受的阈值时段之外：

向所述请求应用发送非阻止响应，以及

基于联系点信息向内容源应用发送请求消息，以获得在所述可接受的阈值时段内的所述服务的更新内容。

2.根据权利要求1所述的装置，所述操作还包括：基于对与所述服务相关联的所述内容的所述新鲜期以及与多个其他服务相关联的内容的新鲜期的分析来确定需要由所述装置更新所述内容的时间表。

3.根据前述权利要求中任一项所述的装置，其中，对所述内容源应用的所述请求消息包括需要由所述装置更新所述内容的时间表。

4.根据前述权利要求中任一项所述的装置，其中，所述非阻止响应包括回调地址，所述回调地址由所述请求应用用于在所述内容变得可用时订阅以接收在所述新鲜期内的内容。

5.根据前述权利要求中任一项所述的装置，其中，对所述内容源应用的所述请求消息包括与所述新鲜期对应的创建后参数。

6.根据前述权利要求中任一项所述的装置，所述操作还包括：基于对所述消息中的所述内容的所述新鲜期以及与多个其他消息相关联的所述内容的新鲜期的分析，确定需要由所述装置更新所述内容的时间表。

7.根据前述权利要求中任一项所述的装置，其中，所述联系点信息包括统一资源标识符。

8.一种用于管理服务层的内容的新鲜度的方法，所述方法包括：

从请求应用接收消息，所述消息包括获得与服务相关联的内容和与所述服务相关联的所述内容的新鲜期的请求；

基于所述消息中的要求确定所述内容的新鲜期在可接受的阈值时段之外；以及

响应于确定所述内容的所述新鲜期在所述可接受的阈值时段之外：

向所述请求应用发送非阻止响应，以及

基于联系点信息向内容源应用发送请求消息，以获得在所述可接受的阈值时段内的所述服务的更新内容。

9.根据权利要求8所述的方法，还包括：基于对与所述服务相关联的所述内容的所述新鲜期以及与多个其他服务相关联的内容的新鲜期的分析来确定需要由服务层设备更新所述内容的时间表。

10.根据权利要求8或9中任一项所述的方法，其中，对所述内容源应用的所述请求消息包括需要由服务层设备更新所述内容的时间表。

11.根据权利要求8至10中任一项所述的方法，其中，所述非阻止响应包括回调地址，所述回调地址由所述请求应用用于在所述内容变得可用时订阅以接收在所述新鲜期内的内容。

12.根据权利要求8至11中任一项所述的方法，其中，对所述内容源应用的所述请求消息包括与所述新鲜期对应的创建后参数。

13.根据权利要求8至12中任一项所述的方法，还包括：基于对所述消息中的所述内容的所述新鲜期以及在多个其他消息中关联的内容的新鲜期的分析，确定需要由服务层设备更新所述内容的时间表。

14.根据权利要求8至13中任一项所述的方法，其中，所述联系点信息包括统一资源标识符。

15.一种计算机程序产品，包括计算机可读介质，其上具有包括程序指令的计算机程序，所述计算机程序能够加载到数据处理单元中，并适于当所述计算机程序由所述数据处理单元运行时使所述数据处理单元执行根据权利要求8至14中任一项所述的方法步骤。