CN108141466A - 用于在服务层处启用途中资源发现的方法 - Google Patents

Abstract

本申请至少涉及一种联网设备。所述设备包括：非暂时性存储器，所述非暂时性存储器存储有用于处理对网络上的资源的发现请求消息的指令。所述设备还包括：处理器，所述处理器可操作地耦合至所述非暂时性存储器，所述处理器被配置成执行指令集。一种指令包括：接收来自发起方的包括过滤器判据的发现请求消息。另一指令包括：检查是否有任何资源匹配所述发现请求消息中的所述过滤器判据。进一步指令包括：准备发现响应。本申请还涉及一种用于处理网络上的资源的发现请求消息的方法。本申请进一步涉及一种用于执行公共服务实体的发现的设备和方法。

Description

用于在服务层处启用途中资源发现的方法

相关申请的交叉引用

本申请要求2015年8月13日提交的美国临时申请第62/204,546号的优先权，该申请的公开内容以引用的方式全部并入本文。

技术领域

本申请涉及资源发现架构和协议。更具体地，本申请描述了在服务层处的途中(en-route)资源发现协议。

背景技术

目前，将oneM2M发现请求从发起方-应用实体(AE)或者公共服务实体(CSE)发送至托管CSE。位于发起方与托管CSE之间的转接CSE仅能够转发发现请求。虽然这确保了发现的隐私，但是其不允许转接CSE参与发现过程。

当前发现机制还缺乏对转接CSE可以处理发现请求的部署/系统的支持。转而，发起方不能要求寻找任何匹配资源实例或者在转接CSE中寻找所有匹配资源。

此外，发起方不能基于两个或者更多个资源来进行有条件的发现请求。更进一步地，发起方无法找到最佳匹配资源，例如，可能存在具有匹配资源的另一个托管CSE，其中，匹配资源可以在针对服务层跳数更接近发起方或者具有更多处理能力以处理发现请求的CSE中。

这些缺点在本领域中呈现出以下问题。首先，存在从发起方至主CSE的不必要的服务层信令。其次，在发现匹配过滤器判据的资源时存在不必要的时延。此外，资源发现缺乏灵活性。即，包括原始资源和通告的资源两者的发现资源仅在发起方或者托管CSE处。

发明内容

提供本发明内容的目的在于按照简化的形式介绍对构思的选择，下面在具体实施方式中对这些构思进行了进一步描述。本发明内容不旨在限制所要求的主题的范围。在很大程度上，涉及用于促进在服务层处的途中资源发现的过程和系统的本申请满足上述需求。

在本申请的一个方面中，描述了一种联网设备。该设备包括：非暂时性存储器，该非暂时性存储器存储有用于执行资源的发现的指令。该设备还包括：处理器，该处理器可操作地耦合至非暂时性存储器。处理器被配置成至少执行生成发现请求消息的指令。处理器还被配置成执行以下指令：将发现请求消息发送至公共服务实体。进一步地，处理器被配置成执行以下指令：从公共服务实体接收发现响应。

在本申请的另一方面中，描述了一种用于在公共服务实体处执行发现的计算机实现的方法。该方法包括以下步骤：生成包括发现类型的发现请求消息(DRM)。该方法还包括以下步骤：将DRM发送至CSE。该方法进一步包括以下步骤：从CSE接收发现响应。

本申请的再一方面涉及一种联网设备。该设备包括：非暂时性存储器，该非暂时性存储器存储有用于处理资源的发现请求的指令。该设备还包括：处理器，该处理器可操作地耦合至非暂时性存储器。处理器被配置成执行以下指令：(i)从发起方接收包括过滤器判据的发现请求消息；(ii)检查是否有任何资源匹配消息中的过滤器判据；以及(iii)准备发现响应消息。

本申请的再一方面涉及一种用于在公共服务实体处执行发现的计算机实现的方法。该方法包括以下步骤：从发起方接收包括发现类型和过滤器判据的发现请求消息。该方法还包括以下步骤：检测是否有资源匹配消息中的过滤器判据。该方法进一步包括以下步骤：准备发现响应消息。

因此，已经相当广泛地对本发明的某些实施例进行了概述以可以更好地理解其详细描述，并且可以更好地了解对本领域的当前贡献。

附图说明

为了便于更全面地理解本申请，现在参照附图，在该附图中，类似的元件用类似的数字来表示。这些附图不应该被解释为限制本申请，而是仅仅旨在进行说明。

图1图示了在应用层、公共服务层以及网络服务层之间的关系。

图2图示了在应用实体、公共服务实体(CSE)以及底层网络之间的关系。

图3图示了在场域与基础架构域之间的关系。

图4图示了根据实施例的一般资源发现过程。

图5A图示了机器对机器(M2M)或者IoT通信系统的实施例。

图5B图示了M2M服务平台的应用的实施例。

图5C图示了示例M2M装置的系统示意图的应用的实施例。

图5D图示了示例性计算系统的框图的应用的实施例。

图6图示了示出了在发起方、多个转接CSE、以及托管CSE之间的关系的实施例。

图7图示了根据实施例的发现过程。

图8图示了根据另一实施例的发现请求过程。

图9图示了根据实施例的在转接CSE处的发现过程。

图10图示了根据另一实施例的多跳发现过程。

图11图示了根据另一实施例的发现请求过程。

图12图示了根据另一实施例的在转接CSE处的发现过程。

图13图示了根据实施例的条件发现过程。

图14图示了根据实施例的重定向发现过程。

图15图示了根据又一实施例的发现协议。

图16图示了根据另一实施例的公共服务实体(CSE)中的增强型发现协议。

图17图示了根据另一实施例的图形用户界面。

图18A和图18B图示了图形用户界面的示例。

具体实施方式

将参照本文中的各个附图、实施例和方面来讨论对说明性实施例的详细描述。虽然该描述提供了可能实施方式的详细示例，但是应该理解，细节旨在作为示例，并且因此不限制本申请的范围。

贯穿本说明书，对“一个实施例”、“实施例”、“一个或者多个实施例”、“方面”等的提及是指结合该实施例描述的特定特征、结构、或者特性包括在本公开的至少一个实施例中。此外，在贯穿本说明书的各个部分中的术语“实施例”不一定指相同的实施例。即，描述了可以由一些实施例而不是其它实施例实现的各种特征。

通常，oneM2M提供允许发起方在托管CSE处寻找匹配指定过滤器判据的资源的简单资源发现机制。通过预置配(provision)或者通过先前的发现操作来使发起方意识到托管CSE。过滤器判据允许发起方按照类型、创建时间、更新时间、大小、标签等来定制接收到的响应。托管CSE用匹配资源的地址列表来进行响应。这可能达到某一发起方指定的最大数量。随着发现请求到达托管CSE，托管CSE通常会遍历若干转接CSE。根据本申请，转接CSE配置有协议以协助发现过程并且启用增强型资源发现机制。

在一个实施例中，发起方可以发出发现请求(通过新的API)以允许选择增强型资源发现机制中的一种增强型资源发现机制，并且指定与这些机制有关的参数。发起方可以请求转接CSE执行多跳发现、条件发现、或者托管CSE重定向。利用多跳发现，发起方可以要求转接CSE对托管CSE执行服务层路由发现，或者寻找前“K”个匹配资源。单独地，在另一实施例中，利用条件发现，发起方可以要求特定CSE仅在满足预定条件时转发发现请求。在另一实施例中，利用托管CSE重定向，发起方可以要求转接CSE建议更好的托管CSE。

单独地，发起方可以接收发现响应，用信号通知条件发现、托管CSE重定向、和/或多跳发现的状态。对于多跳发现，响应可以用信号通知在发起方与托管CSE之间的转接CSE以及这些CSE的状态以便进行路由发现。例如，在条件发现中，响应可以用信号向发起方通知在CSE处的条件已经失败。在另一示例中，对于托管CSE重定向，响应可以用信号向发起方通知具有匹配资源的托管CSE列表。

通常，在下面更详细讨论的实施例中，在多跳发现期间，转接CSE处理发现请求并且准备未决发现响应。不立即发送该发现响应。另外，如果需要更多的匹配资源，则转接CSE转发发现请求，并且等待发现响应。在接收到发现响应之后，转接CSE提取匹配资源列表，并且在进行发送之前将该列表附加到未决发现响应。在条件发现中，转接CSE验证其是否需要检查条件。转接CSE仅在满足条件时转发请求。在托管CSE重定向期间，转接CSE确定其它托管CSE是否具有匹配资源。如果其它托管CSE具有匹配资源，则CSE连同度量集合将该信息提供至发起方。

定义和缩略词

下面表1中提供的是本申请中普遍使用的术语和短语的定义。表2进一步提供了本申请中使用的术语和短语的缩略词。

表1

缩略词	术语/短语
		ADN	应用专用节点
AE	应用实体
		App	应用
ASM	应用和服务层管理
		ASN	应用服务节点
CMDH	通信管理和递送处理
		CSE	公共服务实体
CSF	公共服务功能
		DIS	发现
DMR	数据管理和储存库
		eDis	增强型发现
IN	基础架构节点
		IoT	物联网
IP	互联网协议
		LOC	位置
M2M	机器对机器
		MN	中间节点
NSE	底层网络服务实体
		NSSE	网络服务公开、服务执行和触发
REG	注册
		ROA	面向资源的架构
SC	服务能力
		LOC	位置
SCA	服务计费和核算
		SEC	安全
SOA	面向服务的架构
		SUB	订阅和通知
UDP	用户数据报协议
		URI	统一资源标识符

表2

服务层可以是网络服务架构内的功能层。服务层通常位于应用协议层诸如HTTP、CoAP或者MQTT之上，并且向客户端应用提供增值服务。服务层还提供至在较低资源层诸如例如控制层和传输/接入层处的核心网络的接口。服务层支持多个类别的(服务)能力或者功能，包括服务定义、服务运行时间启用、策略管理、访问控制、和服务群集。最近，若干行业标准主体例如oneM2M已经开发了M2M服务层以解决与将M2M类型的装置和应用集成到诸如互联网/Web、蜂窝、企业、和家庭网络等的部署中相关联的挑战。M2M服务层可以向应用和/或各种装置提供服务层支持的上面提到的能力或者功能的类集或者集合的访问权限，该服务层可以被称为CSE或者SCL。一些示例包括但不限于：安全、计费、数据管理、装置管理、发现、置配、以及可以由各种应用共同使用的连接管理。经由利用由M2M服务层限定的消息格式、资源结构和资源表示的API来使得这些能力或者功能可用于这种各种应用。CSE或者SCL是可以由硬件和/或软件实施并且提供暴露于各种应用和/或装置的(服务)能力或者功能(即，在这种功能实体之间的功能接口)以便CSE和SCL使用这种能力或者功能的功能实体。

oneM2M公共服务层和公共服务功能

oneM2M已经开发了为在所有应用之间交换和共享数据限定单个水平平台的标准集合。这甚至包括不同行业类别的应用。OneM2M正在创建分布式软件层——如操作系统——该分布式软件层通过利用不同技术提供用于交互工作的框架来促进统一。该分布式软件层实施在位于M2M应用与提供数据传输的通信HW/SW之间的公共服务层中。例如，在图1中对此进行了图示。

公共服务层提供了按照功能性分组在一起组成公共服务功能(CSF)的服务集合。若干实例化的CSF组成了公共服务实体(CSE)。CSE接口具有：应用(应用实体或者使用oneM2MA命名法的AE)；其它CSE；和底层网络(网络服务实体或者使用oneM2M命名法的NSE)。

如在图2中示出的，通过这些接口的通信通过Mca参考点、Mcc(和Mcc’)参考点、和Mcn参考点。同样在图2中示出的是当前由oneM2M定义的12个CSF。下面简要描述每一个CSF。

应用和服务层管理CSF：提供对AE和CSE的管理。这包括对CSE的功能进行配置、故障排除和使其升级以及使AE升级的能力。

发现CSF：基于过滤器判据来搜索有关应用和服务的信息。

注册CSF：为AE(或者其它远程CSE)提供向CSE进行注册的功能。这允许AE(或者远程CSE)使用CSE的服务。

通信管理/递送处理CSF：提供与其它CSE、AE和NSE的通信。该CSF决定在什么时间和哪个通信连接用于递送通信，并且若必要并且允许，对通信请求进行缓冲，使得可以在稍后转发通信请求。

组管理CSF：提供对与组有关的请求的处理。使M2M系统能够支持有关多个设备、应用等的批量操作。

安全CSF：为服务层提供安全功能，诸如，包括识别、认证和授权的访问控制。

数据管理和储存库CSF：提供数据存储和调解功能(采集数据用于聚合、重新格式化数据，并且存储数据用于分析和语义处理)。

位置CSF：提供使AE能够获得地理位置信息的功能。

服务计费&核算CSF：为服务层提供计费功能。

装置管理CSF：提供对有关M2M网关和M2M装置的装置能力的管理。

网络服务公开、服务执行和触发CSF：利用用于访问网络服务功能的底层网络来管理通信。

订阅和通知CSF：提供允许订阅事件并且在该事件发生时得到通知的功能。

功能架构

oneM2M正在开发如在图3中示出的称为面向资源的架构(ROA)的服务层架构。

在ROA中，架构是围绕资源开发的。CSF对这些资源进行操作以执行其服务。资源是在具有可以经由RESTful方法(诸如，创建、检索、更新、和删除)来操纵的表示的架构中唯一可寻址的元素。通过使用统一资源标识符(URI)来使得这些资源可寻址。资源可以包含(多个)子资源和(多个)属性。子资源是与父资源具有包含关系的资源。因此，可以将资源视为源于基础资源的层次树。父资源表示包含对其(多个)子资源的引用。子资源的生命周期受父的资源生命周期的限制。每个资源支持存储资源的信息的“属性”集合。属性的集合对所有资源是通用的，而其它属性仅适用于特定资源。后者被称为“资源特定属性”。可以将位于一个CSE(称为托管CSE)处的某些资源通告给远程CSE，并且这些资源被称为通告的资源。该通告的资源可以包含原始资源的属性以及其自己的属性。托管CSE负责在原始资源与通告的资源之间的同步。

资源发现CSF

资源发现是以下过程：实体诸如例如发起方通过该过程搜索有关包含在属性和资源中的应用和服务的信息。资源发现的发起方可以是AE或者CSE，并且始终以在接收方CSE处的根资源(根资源是搜索开始的资源)为目标。搜索结果依赖于由发起方指定的过滤器判据&发现结果类型，并且受在接收方CSE处的访问控制策略的限制。即，发起方是否具有“发现”访问权限。发起方可以使用过滤器判据来限制返回的结果的数量，并且仅返回匹配特定搜索参数的结果，例如，基于资源类型、资源创建时间、资源大小等。在下面的表3中提供了搜索参数的完整列表。可以通过关系运算来组合这些参数以创建复合搜索判据。例如，当同时使用多个条件时，不同的条件应该使用“AND”逻辑运算，而相同的条件应该使用“OR”逻辑运算。

表3

发起方可以使用发现结果类型来向接收方CSE指示返回的结果的格式。两个选项可用。第一个选项是层次寻址，并且第二个选项是非层次寻址。通过使用检索方法来实施资源发现。为了使接收方CSE将资源发现操作与一般检索操作区别开来，发起方通过使用专用标志来用信号将其通知给接收方CSE。在图4中示出了一般资源发现过程。通过数字来表示每个步骤。首先，发起方向接收方CSE发出资源发现请求(步骤001)，以资源<CSEBase>/<app01>的特定子资源为目标。接收器CSE处理请求并且返回发现的资源的适当列表(步骤002)。接收方CSE可以根据发现的资源的发现特权来限制发现结果，并且可以根据其自己的本地策略来改变过滤器判据。如果无法返回发现的资源的完整列表，则接收方CSE将向发起方发出警告。警告可以例如带有标志。资源发现响应(步骤003)包括匹配过滤器判据的资源的地址列表。若需要，发起方负责检索地址所指向的资源。

服务发现

DNS–服务发现(DNS-SD)是已经在近几年添加至DNS的相对较新的特征。DNS-SD是指除了由DNS提供的常用名称解析功能之外还使用DNS来发现可用的基于本地网络IP的服务。例如，向DNS-SD查询本地网络中可以经由IP来访问的可用打印机。具体地，给定客户正在查找的服务的类型(例如，打印)，该机制允许客户通过使用标准的DNS-查询来在给定域中发现该期望的服务的装置(命名实例)的本地列表。IETF标准化解决方案的商业前身是Apple Computer，并且被称为“AppleTalk”(有时也称为“Bonjour”)。

一般架构

图5A是可以实施一个或者多个公开的实施例的示例机器对机器(M2M)、物联网(IoT)、或者万物网(WoT)通信系统10的示意图。一般而言，M2M技术为IoT/WoT提供构件块，并且任何M2M装置、网关或者服务平台都可以是IoT/WoT以及IoT/WoT服务层等的组件。

如在图5A中示出的，M2M/IoT/WoT通信系统10包括通信网络12。该通信网络12可以是固定网络(例如，以太网、光纤、ISDN、PLC等)或者无线网络(例如，WLAN、蜂窝等)或者异构网络的网络。例如，通信网络12可以由多个接入网组成，该多个接入网向多个用户提供内容，诸如声音、数据、视频、消息收发、广播等。例如，通信网络12可以采用一种或者多种信道接入方法，诸如，码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。进一步地，通信网络12可以包括其它网络，诸如，例如，核心网络、互联网、传感器网络、工业控制网络、个域网、卫星网络、家庭网络、或者企业网络。

如在图5A中示出的，M2M/IoT/WoT通信系统10可以包括基础架构域和场域。基础架构域指端对端M2M部署的网络侧，并且场域指局域网络，通常在M2M网关之后。场域包括M2M网关14诸如具有代理的服务能力服务器(SCS)、和终端装置18诸如UE装置。要了解，可以如期望的一样将任何数量的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、蓝牙、直接无线电链路、和有线网络。

参照图5B，所图示的在场域中的M2M服务层22为M2M应用20、M2M网关装置14和M2M终端装置18以及通信网络12提供服务。要理解，M2M服务层22可以如期望的一样与任何数量的M2M应用、M2M网关装置14诸如例如转接CSE、M2M终端装置18诸如托管CSE和发起方、以及通信网络12进行通信。可以由一个或者多个服务器、计算机等来实施M2M服务层22。M2M服务层22提供应用于M2M终端装置18、M2M网关装置14、和M2M应用20的服务能力。可以按照各种方式来实施M2M服务层22的功能。例如，可以将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’。

仍然参照图5B，M2M服务层22和22’提供多种应用和垂直可以利用的服务传送能力的核心集。这些服务能力使M2M应用20和20’能够与装置进行交互，并且执行诸如数据采集、数据分析、装置管理、安全、开账单、服务/装置发现等功能。本质上，这些服务能力使应用免于实施这些功能的负担，由此简化了应用开发并且减少了进入市场的成本和时间。服务层22和22’还使M2M应用20和20’能够通过各种网络12结合服务层22和22’提供的服务来进行通信。

M2M应用20和20’可以包括各个行业的应用，诸如但不限于，运输、健康与保健、联网家庭、能量管理、资产追踪、以及安全和监控。如上面提到的，跨系统的装置、网关、和其它服务器运行的M2M服务层支持如下功能：诸如，例如，数据采集、装置管理、安全、开账单、位置追踪/围墙、装置/服务发现、以及遗留系统整合，并且将这些功能作为服务提供至M2M应用20和20’。此外，M2M服务层还可以被配置成与其它装置诸如在本申请中讨论的并且在附图中图示的UE、SCS和MME接口连接。

服务层是通过应用编程接口(API)和底层组网接口集合来支持增值服务的软件中间件层。ETSI M2M的服务层称为服务能力层(SCL)。SCL可以实施在M2M装置(在该M2M装置中，SCL称为装置SCL(DSCL))、网关(在该网关中，SCL称为网关SCL(GSCL))和/或网络节点(在该网络节点中，SCL称为网络SCL(NSCL))内。oneM2M服务层支持公共服务功能(CSF)例如服务能力集合。一个或者多个特定类型的CSF的集合的实例化称为公共服务实体(CSE)，可以将该公共服务实体托管在不同类型的网络节点例如基础架构节点、中间节点、应用专用节点上。

图5C是诸如例如M2M终端装置18或者M2M网关装置14的示例M2M装置30的系统示意图。如在图5C中示出的，M2M装置30可以包括处理器32、收发器34、发送/接收元件36、扬声器/麦克风38、小键盘40、显示器/触摸板/指示器42、不可移动存储器44、可移动存储器46、电源48、全球定位系统(GPS)芯片集50、和其它外设52。要了解，M2M装置30可以包括上述元件的任何子组合且保持与实施例一致。M2M装置30还可以与其它装置一起使用，包括例如在本申请中描述的并且在附图中图示的发起方和托管/转接CSE。

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

发送/接收元件36可以被配置成将向M2M服务平台22传输信号或者从M2M服务平台22接收信号。例如，在实施例中，发送/接收元件36可以是被配置成传输和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口，诸如，WLAN、WPAN、蜂窝等。在实施例中，例如，发送/接收元件36可以是被配置成发送和/或接收IR信号、UV信号、或者可见光信号的发射机/检测器。在再一示例中，发送/接收元件36可以被配置成发送和接收RF信号和光信号两者。要了解，发送/接收元件36可以被配置成发送和/或接收无线信号或者有线信号的任何组合。

另外，虽然在图5C中将发送/接收元件36描绘为单个元件，但是M2M装置30可以包括任何数量的发送/接收元件36。更具体地，M2M装置30可以采用MIMO技术。因此，在实施例中，M2M装置30可以包括用于发送和接收无线信号的两个或者更多个发送/接收元件36例如多根天线)。

收发器34可以被配置成对待由发送/接收元件36传输的信号进行调制，并且对发送/接收元件36接收的信号进行解调。如在上面提到的，M2M装置30可以具有多模式能力。因此，例如，收发器34可以包括用于使M2M装置30能够经由多个RAT诸如UTRA和IEEE 802.11进行通信的多个收发器。

处理器32可以从任何类型的合适的存储器访问信息，并且可以将数据存储在任何类型的合适的存储器中，存储器诸如不可移动存储器44和/或可移动存储器46。不可移动存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘、或者任何其它类型的存储器存储装置。可移动存储器46可以包括用户身份识别模块(SIM)卡、记忆棒、安全数字(SD)记忆卡等。在其它实施例中，处理器32可以从存储器访问信息，并且可以将数据存储在存储器中，该存储器不是物理地位于M2M装置30上，诸如，位于服务器或者家庭计算机上。

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

处理器32还可以耦合至GPS芯片集50，该GPS芯片集50被配置成提供有关M2M装置30的当前位置的位置信息例如经度和纬度。要了解，在与实施例一致的情况下，M2M装置30可以通过任何合适的位置确定方法来获取位置信息。

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

图5D是其上例如可以实施图5A和图5B的M2M服务平台22的示例性计算系统90的框图。计算系统90可以包括计算机或者服务器，并且可以主要由计算机可读指令控制，该计算机可读指令可以是软件的形式，无论在何地或者无论通过何种方式都可以对这种软件进行存储和访问。可以在中央处理单元(CPU)91内执行这种计算机可读指令以使计算机系统90进行工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91通过称为微处理器的单芯片CPU来实施。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是可选的处理器，与主CPU 91不同，协处理器81执行另附加的功能或者协助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，该外围控制器83负责将来自CPU 91的指令传送至外设，诸如，打印机94、键盘94、鼠标95、和磁盘驱动器85。

由显示控制器96控制的显示器86用于显示由计算系统90生成的视觉输出。这种视觉输出可以包括文本、图形、动画图形、和视频。这可以包括：例如，多跳发现、条件发现和托管SE重定向的发现结果。可以用基于CRT的视频显示器、基于LCD的平板显示器、基于等离子气体的平板显示器、或者触摸面板来实施显示器86。显示控制器96包括生成发送至显示器86的视频信号所需的电子组件。显示器86可以通过使用嵌入式语义名称来在文件或者文件夹中显示感知数据。进一步地，计算系统90可以包含网络适配器97，该网络适配器97可以用于将计算系统90连接至外部通信网络，诸如，图5A和图5B的网络12。

途中资源发现

根据本申请的方面，提出的增强型发现CSF和途中处理向服务层提供了额外的益处。这包括：例如，多跳发现，由此转接CSE确定其是否具有匹配过滤器判据的任何资源。这还包括：条件发现，由此转接CSE确定在转发发现请求之前是否满足条件。这可以进一步包括：托管CSE重定向，其中，转接CSE意识到具有匹配过滤器判据的资源的替选托管CSE并且可以将发现请求重定向到这些替选托管CSE中的一个的替选托管CSE。

在如在图6中图示的一个实施例中，将假设典型的服务层部署。在图6中，发起方(AE或者CSE)610和托管CSE 630由多个转接CSE 620分开。在一个方面中，转接CSE中的一个或者多个转接CSE可以具有多个注册方CSE。

处理通常在发起方处开始。通常包括单个参数以指示要在每个实体处遵循哪个增强型发现过程(如果有的话)。将这种新参数Discovery Type(发现类型)包括在由发起方生成的发现请求消息中。Discovery Type可以包括以下类型的值中的一个或者多个值：(i)转发(无增强型发现过程)；(ii)多跳发现；(iii)条件发现；(iv)托管CSE重定向。替选地，发起方可以省略发现请求中的Discovery Type参数，并且依赖于在可以将Discovery Type参数的缺失视为不使用增强型发现过程(即，使用转发)的指示的CSE处的隐式行为。

在CSE处，可以采用新的discoveryType属性。此处，每个CSE可以可选地支持增强型发现过程中的一个或者多个增强型发现过程。可以将该信息包括在<CSEBase>资源的属性中，诸如例如discoveryType。该属性可以列出支持的发现过程。例如，对于转发(无增强型发现过程)，如果CSE是转接CSE，则CSE将发现请求转发至托管CSE。该属性的其它选项可以包括：例如，多跳发现、条件发现、和托管CSE重定向。

另外，discoveryType属性还可以指示CSE是否能够同时执行多个增强型发现机制。例如，discoveryType可以是多跳发现和条件发现。discoveryType属性允许实体发现CSE所支持的增强型发现过程。

根据另一方面，在每个CSE处的访问控制可以基于用于发现操作的现有访问控制规则。即，具有资源的发现特权的发起方具有增强型发现过程的自动特权。替选地，为了提供更多的灵活性，可以为每个增强型发现类型维持特定发现特权。这将允许单独的规则应用于多跳发现、条件发现、和托管CSE重定向。例如，可以定义三个附加的accessControlOperations：(i)DISCOVER_MULTIHOP是发现资源和转发请求的特权；(ii)DISCOVER_CONDITIONAL是有条件地发现资源的特权；(iii)DISCOVER_REDIRECT是对托管CSE进行重定向的特权。

接下来，将讨论如在图7中图示的在发起方、转接CSE、以及托管CSE之间的整体处理。通常，发起方负责指定期望的discoveryType。例如，如果发起方对在特定托管CSE处的特定资源感兴趣，则将可能发出不具有增强型过程的发现请求。替选地，如果需要增强型过程，则发起方可以使用若干选项。发起方可以指定被请求执行增强型发现的CSE类型。例如，发起方可以请求增强型发现只发生在以下CSE中：(i)MN-CSE(不是ASN-CSE)；(ii)特定等级或者特定级的CSE(我们假设CSE具有指定级或者等级类型)；(iii)具有大量处理(高内存、低活动等)的CSE；或者(iv)在提供的列表内的CSE。根据进一步实施例，在以下情况下，CSE将仅执行增强型发现过程：(i)其是发起方所请求的；(ii)CSE支持所请求的增强型发现过程；和(iii)发起方具有执行增强型过程的访问权限。

在多跳发现期间，发起方可以发出发现请求，该发现请求征求每个转接CSE(在针对托管CSE的每一跳处)检查其是否拥有匹配发现过滤器判据的任何资源，并且将结果返回至发起方。下面描述在每个受影响的实体处的处理。

图8图示了在发起方处处理多跳发现请求的操作。用罗马数字例如1、2等来表示每个步骤。在步骤1中，发起方发出发现请求。在示例性实施例中，通过检索方法来发送该请求。然而，可以通过专用方法或者通过更新、创建或者其它类似的方法来发送该请求。请求可以包括以下参数：

To：在托管CSE上发现开始的托管CSE根地址。

Filter Criteria：用于搜索和预期的返回结果的过滤器判据。

Discovery Result Type:返回的发现结果的可选格式。

discoveryType：要求转接CSE处理发现请求的多跳发现。

MultiHop Discovery SubType：通知转接CSE和托管CSE有关发起方的意图。

routeDiscovery：用信号通知发起方想要寻找至托管CSE的服务层路由路径。该服务层路由路径是遵循在发起方与托管CSE之间的注册链的特殊路由路径，并且在其遍历转接CSE时示出服务层跳，随后示出请求。例如，发起方向CSE1进行注册，CSE1向CSE2进行注册，并且CSE2向IN-CSE进行注册。服务层路由路径是发起方→CSE1→CSE2→IN-CSE。不需要转接CSE搜索匹配过滤器判据的资源，而是返回响应，使得发起方可以维持在自身与指定托管CSE之间的服务层路由路径。

findUptoKResourcesDiscovery：用信号通知发起方想要直至‘k’个匹配过滤器判据的资源，并且如果已经找到‘k’个资源则转接CSE应该停止转发发现请求。

findUptoNHopsResourcesDiscovery：用信号通知发起方想要在发起方的N服务层跳内寻找匹配过滤器判据的资源。处理第N跳的CSE应该停止转发发现请求。

findAllResourcesDiscovery：用信号通知发起方想要在托管CSE和在发起方与托管CSE之间的任何转接CSE中的匹配过滤器判据的所有资源。

Aggregated Response：设置为On/Off。如果设置为On，则通知转接CSE在将响应发送至发起方之前聚合发现结果。如果设置为Off，则如果转接CSE找到匹配过滤器判据的资源，通知转接CSE向发起方发送发现结果。

matchingResourceLimit参数(可以被包括在过滤器判据中)指定发起方正在查找的匹配资源的数量(如上面描述的'K'的值)。

hopLimit参数(可以被包括在过滤器判据中)指定发现请求的服务层跳的最大数量(如上面描述的N的值)。

根据在图8中的步骤2，发起方等待发现响应消息。如果将discoveryType设置为multiHopDiscovery并且将Aggregated Response设置为Off，则发起方可以接收多个响应消息(从转接CSE和托管CSE)。发起方使用请求标识符来根据初始发现请求对响应进行交叉引用。在步骤2a中，如果将MultiHop Discovery SubType设置为routeDiscovery，则发起方提取地址(或者在服务层处的ID)并且在自身与托管CSE之间创建CSE地址列表。然而，如在步骤2b中示出的，如果MultiHop Discovery SubType不是routeDiscovery，则发起方保留所有返回结果的更新列表。

接下来，在步骤3中，发起方可以基于以下内容来终止发现过程：(i)从托管CSE接收到响应；或者(ii)从转接CSE接收到参数matchingResourceLimitReached＝TRUE的响应。这用信号通知发起方已经找到期望数量的匹配过滤器判据的资源并且已经停止转发发现请求；(iii)从CSE接收到参数hopLimitReached＝TRUE的响应。这些用信号向发起方通知发现请求已经遍历了期望数量的跳。

在另一实施例中，发起方可以可选地保留两个单独的列表。一个列表用于原始资源，并且一个列表用于通告的资源。可以决定检索所有(或者选定数量)的通告的资源的原始资源地址。如果确定在通告的资源列表上的资源指向在原始资源列表上的资源，则可以将通告的资源标记为重复资源，或者可以决定删除通告的资源。

在转接CSE处用于多跳发现的过程

根据再一实施例，图9图示了对于聚合响应＝On的情况在转接CSE处的过程。这意味着不立即将在转接CSE处的发现请求响应消息发送回发起方。根据步骤1，检查MultiHopDiscovery SubType是否是routeDiscovery。如果是，则转接CSE在步骤2中准备发现响应消息，该发现响应消息包括但不限于以下参数：(i)至(To)：发起方的ID；(ii)来自(From)：转接CSE的ID；以及(iii)内容：目标CSE的CSE地址。可选地，转接CSE可以添加与该转接CSE有关的其它信息，例如，加载条件、访问控制等。随后在步骤17中，将消息发送至发起方。

另一方面，如果在步骤1中的查询被确定为是否定的，则转接CSE确定开始进行发现的本地根资源(步骤2)。可以将其设置为转接CSE根，例如，/CSEBase。接下来，转接CSE检查是否存在匹配过滤器判据的任何资源(步骤3)。如果对查询的响应为否，则转接CSE(CSE_A)将请求转发至托管CSE(如果转接CSE向托管CSE进行了注册)；或者将请求转发至转接CSE(CSE_A)向其进行了注册的另一转接CSE(CSE_B)(步骤6)。

另一方面，如果对查询的响应为是，则转接CSE确定要返回多少结果(步骤4)。此处，转接CSE检查Multihop Discovery SubType是否等于findUptoNHopResourcesDiscovery。如果是，则转接CSE基于跳计数(发现请求中的hopLimit＝＝1)来检查其是否是最后一个CSE(步骤5)。如果检查为假，则转接CSE准备具有以下参数的响应消息(步骤8)：(i)至：发起方的ID；(ii)来自：转接CSE的ID；(iii)内容：找到的资源的列表；和(iv)hopLimitReached＝FALSE。转接CSE通过使hopLimit递减1来修改发现请求消息。转接CSE然后将发现请求消息转发至托管CSE。此后，转接CSE继续进行步骤15，在该步骤15中，转接CSE等待要聚合的发现响应消息。

如果步骤5中对查询的回答为是，则转接CSE准备具有以下参数的响应消息(步骤9)：(i)至：发起方的ID；(ii)来自：转接CSE的ID；(iii)内容：找到的资源的列表；和(iv)hopLimitReached＝TRUE。此处，转接CSE不转发发现请求消息。转接CSE继续至步骤17，在该步骤17中，转接CSE向发起方发送发现请求响应消息。

另一方面，如果在步骤4中对查询的响应为否，则转接CSE检查MultiHopDiscovery SubType是findUptoKResourcesDiscovery还是＝findAllResourcesDiscovery(步骤10)。如果是前者，则转接CSE具有L个匹配资源的列表，并且在发现请求中指定的matchingResourceLimit为‘K’。转接CSE检查是否L<K(步骤11)。如果L<K(步骤12)，则转接CSE准备具有以下参数的响应消息：(i)至：发起方的ID；(ii)来自：转接CSE的ID；(iii)内容：L个找到的资源的列表；(iv)matchingResourceLimitReached＝FALSE。然后，转接CSE通过使matchingResourceLimit递减找到的资源的数量(matchingResourceLimit＝matchingResourceLimit–L)来修改发现请求消息。转接CSE将发现请求消息转发至托管CSE。然后，CSE等待要聚合的发现响应消息(步骤15)。

或者，如果步骤11中对查询的回答为否，则转接CSE准备具有以下参数的响应消息(步骤13)：(i)至：发起方的ID；(ii)来自：转接CSE的ID；(iii)内容：K个找到的资源的列表；以及(iv)matchingResourceLimitReached＝TRUE。转接CSE不转发发现请求消息，其可以继续向发起方发送发现响应消息(步骤17)。

如果步骤10中对查询的回答是findAllResourcesDiscovery，则转到步骤14。此处，转接CSE准备具有以下参数的响应消息：(i)至：发起方的ID；(ii)来自：转接CSE的ID；(iii)内容：找到的资源的列表；以及(iv)matchingResourceLimitReached＝FALSE。转接CSE继续将发现请求消息转发至托管CSE。然后，在步骤15中，转接CSE可以等待发现响应消息。在接收到发现响应之后，转接CSE使用请求ID来交叉引用对请求的响应(步骤16)。然后转接CSE从接收到的响应中提取结果，并且将该信息聚合到在步骤(7、8、12、或者14)中准备的发现响应。最后，转接CSE结束其处理(步骤18)。

在托管CSE处用于多跳发现的过程

根据如在图10中图示的另一实施例，描述了在接收到发现请求之后在托管CSE处的操作。在步骤1中，托管CSE检查MultiHop Discovery SubType是什么。如果其是RouteDiscovery，则操作转到步骤7，其生成具有参数的发现响应消息(具有托管CSE的地址)。该消息包括：至：发起方的ID；来自：托管CSE的ID；和内容：托管CSE的CSE地址。可选地，托管CSE可以添加与该托管CSE有关的其它信息，例如，加载条件、访问控制等。接下来，发送发现响应消息(步骤8)。此后，CSE结束其处理(步骤9)。

另一方面，通过步骤1，如果发现子类型是findAllResourcesDiscovery，则操作继续至步骤4。在步骤4中，托管CSE生成具有以下参数的发现响应消息：至：发起方的ID；来自：托管CSE的ID；和内容：匹配过滤器判据的所有资源的地址。然后，过程继续进行如上面讨论的步骤8。

替选地，通过步骤1，如果发现子类型是findUptoKResourcesDiscovery，则过程移动至步骤2，在该步骤2中，托管CSE检查是否存在匹配过滤器判据的任何资源。如果不存在，则过程转到如上面描述的步骤7。如果是，则确定要返回多少结果(步骤3)。具体地，托管CSE具有L个匹配资源的列表和在发现请求中指定的matchingResourceLimit。如果L<K，则过程继续至步骤5。在步骤5中，托管CSE准备具有以下参数的响应消息：至：发起方的ID；来自：托管CSE的ID；内容：L个找到的资源的列表；matchingResourceLimitReached＝TRUE。通过步骤5，如上所述，过程转到步骤8，并且然后，如上所述，进行步骤9.

替选地，如果来自步骤3的回答为否，则过程转到步骤6。在步骤6中，托管CSE准备具有以下参数的响应消息：至：发起方的ID；来自：托管CSE的ID；内容：K个找到的资源的列表；matchingResourceLimitReached＝TRUE。然后，过程继续进行步骤8。

多跳发现过程可以具有替选方案。发起方可以具体地列出需要执行多跳处理的转接CSE。如果转接CSE不在该列表上，则可以恢复回将发现请求转发至托管CSE。

多跳发现调用流

根据如在图11中示出的另一实施例，描述了在每个实体处的处理和在这些实体之间的信令。调用流假设发起方正在查找匹配指定过滤器判据的前3个资源。匹配该判据的资源位于转接CSE 2(2x)、转接CSE 3(2x)、和IN-CSE(1x)中。虽然未示出，但是假设发起方已经请求了聚合响应(聚合响应＝On)。

在步骤1中，发起方向IN-CSE发出发现请求，指定：Discovery Type＝multihopDiscovery；MultiHop Discovery SubType＝findUptoKResourcesDiscovery；matchingResourceLimit＝3。

在该实施例中，在步骤2中，在转接CSE1处，不存在匹配资源，所以，将发现请求转发至IN-CSE。在步骤3中，在转接CSE2处，存在两个匹配资源。转接CSE更新发现请求(将matchingResourceLimit减少到1)，并且将其转发至IN-CSE。此外，转接CSE2准备未决发现响应(具有两个匹配资源的地址)，并且然后等待发现响应。

在步骤4中，在转接CSE3处，存在两个匹配资源，但是请求只查找再多一个资源。转接CSE3准备发现响应(具有一个匹配资源的地址)，并且将发现请求发送至发起方，指定以下内容中的一个或者多个：内容＝匹配资源的地址；和matchingResourceLimitReached＝TRUE。注意，不将发现请求转发至IN-CSE。

在步骤5中，在转接CSE2处，将来自接收到的发现响应的结果附加到未决发现响应(来自步骤3)，并且将该未决发现响应发送至发起方。细节包括但不限于：内容＝匹配资源的地址(来自转接CSE2的2个地址和来自转接CSE3的1个地址)列表；和matchingResourceLimitReached＝TRUE。在步骤6中，在转接CSE1处，不存在未决发现响应，所以，将接收到的发现响应转发至发起方。

条件发现

根据本申请的另一方面，发起方可以向托管CSE发出发现请求。然而，如果满足对另一资源的条件，则可能只需要执行发现请求。在称为“条件CSE”的CSE处检查条件。虽然下面的描述适用于单个条件，但是可以将处理一般化为包括任何数量的条件。下面描述在每个受影响的实体处的处理。

在一个实施例中，作为先决条件，发起方知道要检查条件的资源的地址。这可能已经通过先前的发现过程实现了。根据步骤1，发起方发出发现请求。可以通过专用方法或者通过检索、更新、创建或者其它类似的方法来发送该发现请求。请求可以包括以下参数中的一个或者多个：(i)To：发现在托管CSE上开始的根地址；(ii)Filter Criteria：用于搜索和预期的返回结果的过滤器判据；(iii)Discovery Result Type：可选的，返回的发现结果的格式；(iv)Discovery Type＝conditionalDiscovery，其要求如果转接CSE是条件转接CSE则转接CSE处理发现请求；(v)ConditionedOn：应该检查条件的资源的地址；(vi)ConditionCriteria：用于要检查条件的资源的判据。该判据可以基于存储器大小、资源类型、电池状态等；和(vii)ConditionPersistence：条件转接CSE在放弃条件之前应该等待多长时间。值0指示应该仅在接收到发现请求时执行检查。非零值指示在转发发现请求之前允许条件转接CSE等待直到满足条件。允许CSE等待ConditionPersistence时间，或者直到发现请求届满。

根据步骤2，在该步骤2中，发起方等待发现响应消息。在从条件转接CSE接收到ConditionalDiscoveryStatus＝FAIL的响应之后，发起方可以终止发现过程。这用信号向发起方通知还未满足条件，并且不存在匹配条件发现的资源。如果从托管CSE接收到响应，则发起方也可以终止发现请求。这用信号向发起方通知满足条件，并且返回的结果匹配在托管CSE处的过滤器判据。

图12图示了在接收到发现请求之后在转接CSE处的操作。在步骤1中，CSE检查转接CSE是否是条件CSE(转接CSE与在发现请求中的ConditonedOn参数中的CSE对应)。如果是，则过程将转到步骤3。或者，过程转到步骤2以继续将请求转发至托管CSE。根据步骤2，如果转接CSE向托管CSE进行了注册，则转接CSE(CSE_A)将请求转发至托管CSE，或者替选地，将请求转发至转接CSE(CSE_A)向其进行了注册的另一转接CSE(CSE_B)。然后，过程继续至步骤10。

接下来，在步骤3中，过程针对发现请求的ConditonedOn参数所指向的资源检查是否满足ConditionCriteria(步骤3)。如果是，则过程移动至步骤2。或者，过程移动至步骤4。在步骤4中：检查ConditionPersistence是否为零。如果是，则移动至步骤5以准备具有以下参数的发现响应消息：(i)至：发起方的ID；(ii)来自：转接CSE的ID；和(iii)内容：emptyConditionalDiscoveryStatus＝FAIL。然后，过程转到步骤10，在该步骤10中，转接CSE处理结束。

通过步骤4，如果回答为否，则过程移动至步骤6以启动持久性定时器。该定时器表示在放弃请求的条件之前，转接CSE应该等待多长时间。替选地，转接CSE还可以将发现请求转发至托管CSE，但是参数ConditionalDiscoveryStatus＝FAIL。这在附图中未示出。

通过步骤6继续步骤7。此处，检查在ConditionPersistence时间期间是否满足条件。如果是，则移动至步骤8。此处，停止持久性定时器。然后，继续在步骤2以将发现请求转发至托管CSE。替选地，如果在步骤6中启动的持久性定时器届满，则移动至步骤5。替选地，如果发现请求届满，则移动至步骤9。

替选地，通过步骤7，如果发现请求届满，则停止持久性定时器(步骤9)并且然后移动至步骤5。进一步地，处理在步骤10中结束。

在实施例中，如果转接CSE是条件CSE，则其可以包括在转发至托管CSE的发现请求中条件成功的指示(未示出)。当满足条件时，条件CSE还可以向发起方发送发现响应(未示出)。发起方可以使用该发现响应作为来自其初始查询的发现响应正在进行的指示。

在托管CSE处用于条件发现的过程

在托管CSE处的过程如下所述。该过程假设条件转接CSE只有满足条件才转发发现请求。在这种情况下，在托管CSE处接收到的发现请求可以具有参数ConditionalDiscoveryStatus＝PASS。根据步骤1，托管CSE搜索匹配过滤器判据的资源。其基于搜索结果准备发现响应，并且继续至步骤2。此处，托管CSE发送发现响应消息。转到步骤5，这结束本过程。

替选地，如果假设托管CSE可以接收具有参数ConditionalDiscoveryStatus＝FAIL的发现请求，则在托管CSE处的过程如下所述。这暗示即使没有满足条件，条件转接CSE也将发现请求转发至托管CSE。这可能发生在以下情况中：(i)托管CSE想要对资源进行了多少次发现尝试的指示，或者(ii)转接CSE不被允许利用发现响应来对发现请求作出响应。在步骤1中，托管CSE检查发现请求是否是ConditionalDiscovery类型。如果不是，则过程继续至步骤2，在步骤2中：托管CSE搜索匹配过滤器判据的资源。托管CSE基于搜索结果准备发现响应，并且继续至步骤4。

或者，过程继续至步骤3，在该步骤3中，托管CSE检查ConditionalDiscoveryStatus。如果为PASS，则继续至步骤2。如果为FAIL，则准备具有以下参数的发现响应消息：(i)至：发起方的ID；(ii)来自：托管CSE的ID；(iii)内容：空。此后，托管CSE发送发现响应消息(步骤4)。然后，转到步骤5，这结束在托管CSE处的处理。

条件发现调用流

根据另一实施例，例如，如在图13中示出的，示出了在来自上面提到的实施例中的一个实施例的每个实体处的处理和在这些实体之间的信令的示例。调用流假设发起方正在查找匹配IN-CSE中的指定过滤器判据(资源大小高于1KByte)的资源，但是只有在资源1(节点1、转接CSE2)监视到在节点1处的可用内存小于1Kbyte(条件1→节点1/内存/可用内存<1KByte)时发生。

根据步骤1，发起方向IN-CSE发出发现请求。该请求可以指定以下内容中的一个或者多个：(i)Discovery Type＝conditionalDiscovery；(ii)ConditionOn＝/TransitCSE2/resource1；和(iii)ConditionCriteria：可用内存<1K字节。在步骤2中，转接CSE1不是条件CSE，所以，将发现请求转发至IN-CSE。在步骤3中，CSE2是条件CSE，所以，CSE验证是否满足ConditionCriteria。如果满足条件，则转接CSE2将发现请求转发至IN-CSE以进行进一步处理。如果不满足条件，则转接CSE2准备发现响应以返回至发起方，指定以下内容中的一个或者多个：(i)至：发起方；(ii)内容＝“空”；和(iii)ConditionalDiscoveryStatus＝FALSE。在步骤4中，转接CSE3不是条件CSE，所以，将发现请求转发至IN-CSE。进一步地，在步骤5中，发现请求到达托管CSE，这暗示条件成功。IN-CSE获取匹配过滤器判据的资源列表，生成发现响应并且将其发送至发起方。细节：(i)至：发起方；(ii)内容＝匹配资源的地址列表；和(iii)可选地，ConditionalDiscoveryStatus＝TRUE。

利用托管CSE重定向的发现

在本申请的再一方面中，发起方可以向托管CSE发出发现请求。同时，发起方可以查询转接CSE是否知道具有匹配过滤器判据的资源的替选托管CSE。下面描述在每个受影响的实体处的处理。第一协议在进行托管CSE重定向的发起方处。

在步骤1中，发起方发出发现请求。可以通过专用方法或者通过检索、更新、创建或者其它类似的方法来发送该发现请求。请求可以包括以下参数：(i)To：发现在托管CSE上开始的根地址；(ii)Filter Criteria：用于搜索和预期的返回结果的过滤器判据；(iii)Discovery Result Type：可选的，返回的发现结果的格式；(iv)Discovery Type＝hostingCSERedirect，其在如果转接CSE知道具有匹配过滤器判据的资源的替选托管CSE的情况下通知转接CSE进行访问。例如，目标CSE可以查看其托管的所有通告的资源以了解是否存在与发现搜索判据的匹配。替选地，如果转接CSE保留其已经处理/转发的所有先前发现响应的缓存，则可以查看该缓存以确定是否存在匹配过滤器判据的任何资源。

再一参数可以包括RequestedAction。如果转接CSE知道替选托管CSE，则这可以是待在转接CSE处执行的动作。可能选项包括notifyOriginator：通知发起方存在替选托管CSE。向替选托管CSE发送新的发现请求的最终决定留给发起方。这还可以包括动作takeAutonomousAction。这允许转接CSE自主地改变托管CSE(用于不要求太多隐私或者安全的服务或者应用)。

根据步骤2，发起方等待发现响应消息。发起方可以基于以下动作中的一个或者多个动作来终止发现过程。一个动作可以包括：从转接CSE接收潜在托管CSE以及可选地这些潜在托管CSE的度量的列表的响应。发起方然后可以(基于提供的度量)决定最佳托管CSE并且发出新的发现请求。另一动作可以包括从托管CSE接收响应。如果该托管CSE与发现请求中的托管CSE相同，则没有发生托管CSE重定向。如果该托管CSE与发现请求中的托管CSE不同，则用信号向发起方通知转接CSE已经自主地改变了托管CSE。替选地，发现响应可以包含discoveryRedirect参数。如果该参数被设置为TRUE，则用信号向发起方发通知已经对托管CSE进行了重定向。

在另一实施例中，在转接CSE处存在对托管CSE重定向的过程。例如，图14图示了在接收到发现请求之后在转接CSE处的操作。根据步骤1，执行以下检查：转接CSE是否知道具有匹配过滤器判据的资源的任何替选托管CSE。例如，可以通过对转接CSE的通告来实现该操作。如果是，则过程继续至步骤3。在步骤3中，执行以下查询：RequestedAction是否到notifyOriginator。如果是，则过程可以继续至步骤4以准备具有以下一个或者多个参数的发现响应消息：(i)至：发起方的ID；(ii)来自：转接CSE的ID；(iii)内容：潜在托管CSE的地址以及可选地，与这些CSE相关联的度量。一些度量可以包括：服务层参数例如业务负载、服务层跳，底层网络参数例如跳数、底层接入网的类型，和有关维持的资源的信息例如类型、一些基本语义等。进一步地，转接CSE不转发发现请求。然后，过程继续至步骤6。

替选地，如果来自步骤3的查询为否，则过程继续至步骤5。在步骤5中，选择最佳托管CSE。这可以基于至托管CSE的最低跳计数、至托管CSE的底层网络连接性等。如果选择的托管CSE与包括在发现请求消息中的托管CSE不同，则过程通过将“To”参数改变为匹配选择的托管CSE来修改发现请求消息。其包括这是重定向的发现请求的指示——(设置discoveryRedirect＝TRUE)。然后，过程将发现请求消息转发至选择的托管CSE。然后，过程继续至步骤6。替选地，目标CSE可以将发现请求扇出到所有替选托管CSE(或者基于一些度量(例如，较低的跳计数)的这些替选托管CSE的子集)。进一步地，过程结束(步骤6)。

更进一步地，如来自步骤1的查询为否，则过程继续进行步骤2以将请求转发至托管CSE。根据步骤2，如果转接CSE(CSE_A)向托管CSE进行了注册，则转接CSE(CSE_A)将请求转发至托管CSE。替选地，其可以将请求转发至转接CSE(CSE_A)向其进行了注册的另一转接CSE(CSE_B)。然后，过程可以继续至步骤6。

在再一实施例中，过程可以位于用于进行托管CSE重定向的托管CSE。根据步骤1，托管CSE搜索匹配过滤器判据的资源。托管CSE基于搜索结果准备发现响应，并且继续至步骤2。在步骤2中，托管CSE准备发现响应消息。该发现响应消息可以包括以下参数：(i)至：发起方；(ii)来自：托管CSE的ID；(iii)内容：匹配资源判据的资源列表；和(iv)discoveryRedirect：设置为发现请求消息中的discoveryRedirect参数的值。如果设置为TRUE，则向发起方指示该托管CSE不是包括在发现请求消息中的托管CSE。

根据另一实施例，将描述托管CSE重定向调用流。如在图15中示出的，调用流示出了在来自一个或者多个实施例的每个实体处的处理和在这些实体之间的信令的示例。在实体之间的粗体箭头表示注册关系。转接CSE2和转接CSE4都向转接CSE3进行注册。然而，转接CSE4不在从发起方到IN-CSE的注册路径上。为了体现这一点，将转接CSE4示出为红色。调用流假设发起方正在查找匹配指定过滤器判据的资源。发起方以IN-CSE中的资源发现为目标，但是如果目标CSE知道在其它CSE中的匹配资源，则发起方允许目标CSE自主地改变托管CSE。在提出的示例中，转接CSE3意识到在转接CSE4中的匹配资源(例如，由于在注册过程期间在转接CSE3中创建的远程CSE)。

根据步骤1，发起方向IN-CSE发出发现请求，指定以下内容中的一个或者多个：(i)至：IN-CSE；(ii)Discovery Type＝hostingCSERedirect；和(iii)RequestedAction＝takeAutonomousAction。在步骤2中，转接CSE1不知道任何其它潜在托管CSE，所以，将发现请求转发至IN-CSE。在步骤3中，转接CSE2不知道任何其它潜在托管CSE，所以，将发现请求转发至IN-CSE。在步骤4中：转接CSE3知道可以在转接CSE4处找到匹配过滤器判据的资源。其决定自主地改变发现请求的托管CSE。其修改发现请求，并且将请求转发至CSE4以便进行进一步处理。修改过的发现请求：(i)至：转接CSE4；(ii)Discovery Type＝hostingCSERedirect；和(iii)RequestedAction＝takeAutonmousAction。

在步骤5中，CSE4获取匹配过滤器判据的资源列表，生成发现响应并且将其转发至发起方。细节包括但不限于：(i)至：发起方；和(ii)内容＝匹配资源的地址列表。

实施例

如在表4中列出的那样对现有oneM2M<CSEBase>资源提出了新的属性。

表4

可以通过accessControlOperations对三个新支持的操作进行授权。在表5中列出了这些操作。

名称	描述
		DISCOVER_MULTIHOP	发现资源和转发请求的特权
DISCOVER_CONDITIONAL	有条件地发现资源的特权
		DISCOVER_REDIRECT	对托管CSE进行重定向的特权

表5

存在用于检索请求的新参数。这些新参数包括以下内容：

Discovery Type：适用于与发现有关的请求并且用于指示由发起方请求的增强型发现过程的可选参数。定义了Discovery Type的以下值：

multiHopDiscovery：转接CSE将按照本申请中在上面描述的那样遵循逻辑。

conditionalDiscovery：转接CSE将遵循如本申请中在上面描述的逻辑。

hostingCSERedirect:转接CSE将遵循如本申请中在上面描述的逻辑。

forwarding:转接CSE只转发发现请求。

发起方可以在其请求中指定多个Discovery Type，例如，multiHopDiscovery+conditionalDiscovery。替选地，如果不存在DiscoveryType，则转接CSE不应该处理请求，并且仅仅如在上面描述的那样转发请求，例如，回滚到当前发现。

MultiHop Discovery SubType：在Discovery Type＝multiHopDiscovery时适用于与发现有关的请求的可选参数。用于指示多跳发现的目的和转接CSE所需的逻辑。定义了MultiHop Discovery Type的以下值：

routeDiscovery：用信号通知发起方想要寻找至托管CSE的服务层路由路径。

findUptoKResourcesDiscovery:用信号通知发起方想要直至K个匹配过滤器判据的资源。

findUptoNHopResourcesDiscovery：用信号通知发起方想要在来自发起方的K个服务层跳内发现匹配过滤器判据的资源。

findAllResourcesDiscovery：用信号通知发起方想要所有匹配过滤器判据的资源。

RequestedAction：在Discovery Type＝hostingCSERedirect时适用于与发现有关的请求的可选参数。用于指示转接CSE是否可以自主地对发现请求进行重定向或者该操作是否待由发起方进行。定义了RequestedAction的以下值：

notifyOriginator：向替选托管CSE发送新的发现请求的最终决定留给发起方。

takeAutonomousAction：允许转接CSE自主地改变托管CSE。

ConditionedOn：在Discovery Type＝conditionalDiscovery时要包括进来的可选资源地址。这表示要验证条件的资源。

ConditionCriteria：在Discovery Type＝conditionalDiscovery时要包括的可选判据。这表示要对ConditionedOn资源进行测试的判据。

ConditionPersistence：在Discovery Type＝conditionalDiscovery时要包括的可选定时器值。这表示条件转接CSE将检测对ConditionedOn资源的条件的时间。如果为0，则条件转接CSE将在接收到发现请求时检查条件。如果为非零，则条件转接CSE将等待满足条件。在ConditionPersistence时间之后，或者在发现请求届满之后(以先到者为准)，条件转接CSE将放弃并且通知发起方条件失败。

另外，过滤器判据参数如在下面的表6中列出的一样具有专用于多跳发现的两个新条件。

条件标记	多重性	匹配条件
			:	:	:
Limit	0..1	将匹配资源的数量限制为指定值。
			matchingResourceLimit	0..1	发起方所需的匹配资源的数量
hopLimit	0..1	允许发现请求遍历的服务层跳数

表6

存在用于检索响应的新参数。这些新参数包括以下内容：

matchingResourceLimitReached：用于表示是否已经获得matchingResourceLimit的可选标志。

hopLimitReached：用于表示发现请求是否已经遍历了最大服务层跳数的可选标志。

ConditionalDiscoveryStatus：用于表示是否满足在ConditionedOn资源处的条件检查的可选标志。

discoveryRedirect：用于表示转接CSE是否已经将相关联的发现请求重定向到新的托管CSE的可选标志。

图16示出了用于基于当前oneM2M功能架构来针对现有发现CSF实施所提出的想法以形成增强型发现CSF的示例性实施例。可以在ASN-CSE、MN-CSE、和IN-CSE中找到增强型发现CSF。该新的增强型发现(eDIS)CSF使用发现请求中的信息(发起方提供的发现类型、过滤器判据、目的地/目标节点)来发现资源。

在接收到请求之后，eDIS CSF确定如何使用所提供的发现类型来处理请求。如果发现类型是多跳发现，则eDIS CSF基于请求的多跳发现子类型来采取动作–如果需要更多的匹配资源，则发现匹配资源并且将请求转发到其它MN-CSE或者IN-CSE。如果发现类型是条件发现，并且托管该eDIS CSF的节点是条件的目标，则eDIS CSF可以对条件进行评估，并且只在满足条件时将该请求转发至其它MN-CSE或者IN-CSE。如果发现类型是托管CSE重定向，则eDIS CSF首先确定其是否知道托管匹配过滤器判据的资源的任何其它CSE，并且如果是，则可以将请求重定向到这些其它CSE。

图17图示了如何可以经由GUI界面来显示所提出的想法：

(i)在作为发起方的节点上，和(ii)在运行服务层软件模块的中间节点上。由于在服务层参考点上存在提出的消息，因此，可以托管使用在节点之间的嗅探器工具来检测消息。可以使用GUI界面来向服务层软件提供配置，例如，设置在本申请中提出的参数/资源中的一些参数/资源。还可以使用GUI界面来显示在进行操作期间的参数/资源变化。在一个实施例中，显示器上的GUI可以包括匹配某些搜索参数的返回结果。搜索参数可以基于资源类型、资源创建时间、资源大小等。例如，可以在GUI上显示‘k’个匹配过滤器判据的资源。另外，显示服务层跳数。根据示例性实施例，可以将GUI显示为“ParkingFinder(停车查找器)”应用。该应用可以包括用户界面，由此用户可以输入信息诸如搜索参数。通过这样做，GUI输出指示可用空闲点的数量的结果。

发起方中的GUI可以允许用户生成发现请求并且发送至中间节点以随后在各种发现类型(多跳发现、条件发现、托管CSE重定向)下显示发现响应。中间节点中的GUI可以配置服务层以为各种发现类型(多跳发现、条件发现、托管CSE重定向)创建条件。例如，用户可以使用发起方中的GUI来生成具有将评估为FALSE的条件发现的发现请求。GUI可以显示发现响应。

处理器32可以被配置成：响应于在本文描述的一些示例中的学习管理系统是成功的还是是不成功的(例如，服务请求、场境检索或场境通知等)，来控制显示器或者指示器42上的照明模式、图像、或者颜色，或者以其它方式指示服务元件和相关联的组件的状态。控制在显示器或者指示器42上的照明模式、图像、或者颜色可以反映在本文图示的或者讨论的表或者附图(例如，图4和图7至图15)中的任何方法流或者组成的状态。本文公开的是服务元件的消息和过程。除了可以显示在显示器42上的其它事物之外，可以将该消息和过程扩展为提供接口/API以使得用户经由输入源(例如，扬声器/麦克风38、小键盘40、或者显示器/触摸板42)请求与资源有关的资源并且请求、配置、或者查询与服务元件相关联的信息。

根据本申请，要理解，可以按照存储在计算机可读存储介质上的计算机可执行指令例如程序代码的形式来体现本文描述的任何或者所有系统、方法和进程，该指令在由诸如计算机、服务器、M2M终端装置、M2M网关装置、转接装置等的机器执行时执行和/或实施本文描述的系统、方法和进程。具体地，可以按照这种计算机可执行指令的形式来实施在上面描述的任何步骤、操作或者功能。计算机可读存储介质包括按照用于存储信息的任何方法或者技术实施的易失性和非易失性可移动和不可移动介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括，但不限于，RAM、ROM、EEPROM、闪速存储器或者其它存储技术、CD-ROM、数字式多功能光盘(DVD)或者其它光盘存储装置、磁带盒、磁带、磁盘存储装置或者其它磁存储装置、或者可以用于存储所需信息并且可以通过计算机访问的任何其它物理介质。

根据本申请的再一方面，公开了一种用于存储计算机可读或者可执行指令的非暂时性计算机可读或者可执行存储介质。该介质可以包括诸如上面在根据图4和图7至图15的多个调用流中公开的一个或者多个计算机可执行指令。计算机可执行指令可以存储在存储器中并且由上面在图5C和图5D中公开的处理器执行，并且在包括UE、HSS和SCS的装置中使用。在一个实施例中，公开了一种具有非暂时性存储器和可操作地耦合至该非暂时性存储器的处理器的计算机实现的UE，如上面在图5C和图5D中描述的。具体地，发起方的非暂时性存储器存储有用于对位于该非暂时性存储器中的资源执行CSE发现的指令。处理器被配置成执行以下指令：(i)生成包括发现类型的发现请求消息(DRM)；(ii)将DRM发送至CSE；(iii)从CSE接收发现响应。

根据另一实施例，转接CSE的非临时性存储器存储有用于处理对资源的发现请求的指令。处理器被配置成执行以下指令：(i)从处理器接收发现请求。该请求可以包括发现类型和过滤器判据；(ii)检查是否有匹配消息中的过滤器判据的资源；以及(iii)准备发现响应消息。在示例性实施例中，处理器基于过滤器判据来确定要返回多少结果。

现实生活中的示例

上面提到的应用在现实生活环境中可能是有用的。这可以包括：例如，在具有多个层/楼层的停车场中对可用停车位进行定位。图18A图示了可用停车位的图形用户界面。即，每个楼层可以具有一个网关1801，并且在停车场中的每个停车位配备有与其最近的网关进行通信的传感器1804以提供关于每个停车位的状态(空闲/被占用)的指示。还可以包括停车位的细节(例如，停车位对于面包车而言是否足够大，停车位是否是轮椅停车位，停车位是否靠近电梯，以及来自停车位的视频馈源)。还将每个停车位的可用性与“ParkingFinder”服务提供商1802共享，该“ParkingFinder”服务提供商1802具有对该建筑物以及由该服务提供商管理的其它建筑物的所有停车位的通告。

在该示例中，汽车进入停车场，并且司机正在寻找任何可用停车位。汽车导航系统配备有自动连接至停车场的Wi-Fi网络的“Parking Finder”应用1803。“ParkingFinder”应用可以选择通告的免费停车位中的一个免费停车位，并且从服务提供商检索细节。替选地，“ParkingFinder”应用可以要求“ParkingFinder”服务提供商从楼层/层网关检索有关免费停车位的细节(例如：停车位对于面包车而言是否足够大，其被保留用于轮椅进入，停车位是否靠近电梯，该停车位的视频馈源等)。单独地，警车可以进入停车场，并且检查是否有人非法停放在保留停车位，例如，仅轮椅使用停车位。

另一示例涉及在图18B中的图形用户界面中示出的小型办公室中的安全。利用定期将其馈源报告给视频网关1805和MN-CSE传感器网关1804的摄像头来监视办公室入口。网关存储在每24小时周期内的所有视频馈源，并且对记录进行时间标记，使得可以有效地检索记录。当IT部门报告问题时(例如，某个未知用户试图登录到本地计算机)，办公室管理员需要进行故障排除以确定该情况是否是因为非法进入，或者由于某一其它原因。因此，管理员想要查看有关最新的接待处视频馈源的信息，但是只有在已经打开前门时发生。如果办公室管理员应用由办公室管理员触发(例如，需要进行故障排除的报告的问题)，则办公室管理员应用中继视频馈源的信息。

图18A和图18B图示了可以基于本文讨论的方法和系统来生成的示例性显示(例如，图形用户界面)。显示界面(例如，触摸屏显示器)可以提供与服务元件托管选择相关联的文本，诸如，表2至表6中的参数。在另一示例中，可以显示本文讨论的任何步骤的进展。另外，可以将图形输出显示在显示界面上。

虽然已经根据目前被认为是具体方面的内容描述了系统和方法，但是本申请不需要受所公开的方面的限制。其旨在覆盖包括在权利要求书的精神和范围内的各种修改和类似布置，该权利要求书的范围应该被赋予最广泛的解释以包含所有这种修改和类似的结构。本公开包括以下权利要求书的任何和所有方面。

Claims (24)

1.一种网络上的设备，其包括：

非暂时性存储器，其上存储有指令，所述指令用于处理所述对网络上的资源的发现请求消息；以及

处理器，所述处理器可操作地耦合至所述非暂时性存储器，所述处理器被配置成执行以下指令：

接收来自发起方的包括过滤器判据的所述发现请求消息；

检查是否有任何资源匹配所述发现请求消息中的所述过滤器判据；以及

准备发现响应。

2.根据权利要求1所述的设备，其中，所述处理器被配置成执行以下指令：基于所述过滤器判据和所述发现请求消息的发现类型来确定返回多少结果。

3.根据权利要求2所述的设备，其中，所述确定指令基于匹配资源‘L’少于匹配资源限制‘k’。

4.根据权利要求3所述的设备，其中，所述确定指令包括：

检查匹配所述过滤器判据的其它公共服务实体，以及

基于所述检查指令来更新托管公共服务实体。

5.根据权利要求1所述的设备，其中，所述处理器进一步被配置成执行以下指令：将所述发现请求消息转发至另一公共服务实体或者将所述发现响应消息发送至所述发起方。

6.根据权利要求1所述的设备，其中，所述处理器进一步被配置成执行以下指令：

接收第二发现响应消息；以及

基于来自所述第二发现响应消息的结果来更新所述发现响应。

7.根据权利要求1所述的设备，其中，所述发现请求消息包括从由以下内容组成的组中选择的发现类型：路由发现、多跳发现、条件发现、托管公共服务实体重定向以及其组合。

8.根据权利要求7所述的设备，其中，所述发现类型具有有条件的持久性或者替选公共服务实体重定向。

9.根据权利要求1所述的设备，其中，所述发现请求消息包括以下内容中的至少一个：寻找直至k个资源发现、寻找直至N跳资源发现、寻找所有资源发现、匹配资源限制和跳限制。

10.一种用于在网络上执行公共服务实体的发现的方法，其包括：

从发起方接收包括发现类型和过滤器判据的发现请求消息；

检查是否有资源匹配所述发现请求消息中的所述过滤器判据；

准备发现响应；以及

基于所述过滤器判据和所述发现类型来确定要在所述发现响应中返回多少结果。

11.根据权利要求10所述的方法，其中，所述确定步骤基于匹配资源‘L’少于匹配资源限制‘k’。

12.根据权利要求10所述的方法，其中，所述确定步骤包括：

检查匹配所述过滤器判据的其它公共服务实体；以及

基于所述检查步骤来更新托管公共服务实体。

13.根据权利要求10所述的方法，进一步包括：

将所述发现请求消息转发至另一公共服务实体或者将所述发现响应消息发送至所述发起方。

14.根据权利要求1所述的方法，其进一步包括：

接收第二发现响应消息；以及

基于来自所述第二发现响应消息的结果来更新所述发现响应。

15.一种网络上的设备，包括：

非暂时性存储器，其上存储有指令，所述指令用于执行所述网络上的资源的发现；以及

处理器，所述处理器可操作地耦合至所述非暂时性存储器，所述处理器被配置成执行以下指令：

生成发现请求消息；

将所述发现请求消息发送至所述网络上的公共服务实体；以及

从所述公共服务实体接收发现响应。

16.根据权利要求15所述的设备，其中，所述发现请求消息包括发现类型。

17.根据权利要求16所述的设备，其中，所述发现类型从由以下内容组成的组中选择：多跳发现、条件发现、托管公共服务实体重定向以及其组合。

18.根据权利要求17所述的设备，其中，所述多跳发现包括以下内容中的至少一个：路由发现、寻找直至k个资源发现、寻找直至N跳资源发现、寻找所有资源发现、匹配资源限制和跳限制。

19.根据权利要求15所述的设备，其中，所述发现请求消息包括从由以下内容组成的组选择的过滤器：用于执行请求的公共服务实体的类型、特定层的公共服务实体的类型、具有大量处理的公共服务实体的类型、列表内的公共服务实体的类型、以及其组合。

20.根据权利要求15所述的设备，其中，所述发现响应从由以下内容组成的组中选择：已经达到跳限制、已经达到匹配资源限制、以及其组合。

21.一种用于在网络上执行公共服务实体的发现的方法，包括：

生成包括发现类型的发现请求消息；

将所述发现请求消息发送至所述网络上的所述公共服务实体；以及

从所述公共服务实体接收发现响应，其中

所述发现类型从由以下内容组成的组中选择：多跳发现、条件发现、托管公共服务实体重定向以及其组合。

22.根据权利要求21所述的方法，其中，所述发现请求消息包括从由以下内容组成的组选择的过滤器：用于执行请求的公共服务实体的类型、特定层的公共服务实体的类型、具有大量处理的公共服务实体的类型、列表内的公共服务实体的类型、以及其组合。

23.根据权利要求21所述的方法，其中，

从至少两个公共服务实体接收所述发现响应，以及

删除从所述至少两个公共服务实体接收到的重复发现响应。

24.根据权利要求23所述的方法，其中，所述发现响应包括有关达到跳限制和达到匹配资源限制的信息。