CN106489144B - 针对资源目录的搜索引擎优化 - Google Patents

Abstract

一种演进型资源目录，所述资源目录可以将过滤且优先化的搜索结果提供给客户端对资源的搜索查询。例如，在包括服务器和资源目录的网络中，所述资源目录登记从所述服务器接收的多个URI。所述资源目录可以基于测量在所述多个URI中的每一个之间的交叉链路并且识别所述多个URI的上下文，来确定所述多个URI的初始排名。所述初始排名存储在排名数据库中。响应于客户端的搜索查询，所述资源目录可以确定存储在所述排名数据库中的所述多个URI的实时排名。可以基于检查每一个服务器的睡眠状态和/或通过部分地平衡所述服务器的流量负载来确定所述实时排名。基于所述实时排名和/或所述初始排名，所述资源目录随后可以生成所述过滤且优先化的URI的排名列表。

Description

针对资源目录的搜索引擎优化

背景技术

搜索引擎优化是当前用于“常规”(即，非IoT)互联网以影响web搜索引擎结果的常用方法。根据经验，已经发现，在大多数情况下，人类用户将仅仅从来自web搜索的前几个返回的统一资源标识符(在下文中统称为URI)中进行选择，即使返回的URI的总数可能大约有数以百计或者数以千计的URI(例如，谷歌搜索结果的许多页面)。即,用户通常仅选择在第一次返回的web搜索结果页面顶部的前几个URI，而所有其它的URI通常被忽略并且不会被点击。

针对常规互联网搜索，返回的URI是基于HTTP的。从技术上讲，这意味着URI的第一部分(即，方案)指定“http(s)”。例如，“http://www.bestcars.com”或者“http://mybank.com”是HTTP URI的示例。

人类用户将通常只关注来自web搜索的前几个返回的URI的事实与搜索引擎优化互为因果。即，人类用户已经习惯于现代搜索引擎正将最好的搜索结果隐式地放在返回的URI列表顶部的事实。搜索引擎优化涉及由网站开发者用来帮助确保搜索引擎使其网站排名相对较高的一组技术。

图1图示了通常称为交叉链接或者有时称为入站(inbound)链接的常用搜索引擎优化技术。该交叉链接技术是为了确保从其它网站指向该给定网站。搜索引擎将有大量交叉链路指向其的网站排名较高，这是因为交叉链接被认为是一种强有力的网站流行度衡量手段。通过web爬虫(crawler)来检测交叉链接，搜索引擎定期发出所述web爬虫以爬取(crawl)并且映射万维网。

另一常用搜索引擎优化技术是为了确保网络内容使用选择的关键字。这是因为搜索引擎将特定关键字在web页面中的频率和分布用作其排名算法的部分输入。同样，搜索引擎web爬虫检测这些关键字。

当前用于支持互联网资源搜索的IoT模型非常简单且不支持任何高级搜索引擎优化类概念。在当前IoT中，关键搜索节点是存储指向IoT资源的URI的资源目录。由IoT服务器直接地将这些URI推送到资源目录中，而不是如在常规互联网搜索引擎中那样通过web爬虫来发现这些URI。随后，正在查找特定IoT资源的客户端将所述资源目录用作搜索引擎。可以经由例如如在2013年12月11日更新的CoRE资源目录(CoRE Resource Directory)的互联网草案(http://tools.ietf.org/html/draft-ietf-core-resource-directory-01)中所公开的来自客户端的输入参数来调整搜索。然而，对于给定的客户端搜索请求，返回的URI列表是平面的、未过滤的、并且潜在地非常大的。

IoT的URI或者可以是如常规互联网一样的基于HTTP的，或者经常可以是基于受限应用协议(在下文中称为CoAP)的。例如，如2013年6月28日更新的受限应用协议(Constrained Application Protocol)的互联网草案(http://tools.ietf.org/html/draft-ietf-core-coap-18)中所公开的，CoAP是专门为受限设备设计的以其它方式但遵循了HTTP的具象状态转移(在下文中统称为RESTful)方法的优化型网络传输协议。RESTful指用于网络传输协议的通信的无状态请求/响应模型。

与HTTP方法相似，如果URI的第一部分(即，方案)指定“coap(s)”，那么可以识别到CoAP URI。例如，“coap://tempsensor.floor2.bldg6”或者“coaps://securitycamera.home”是CoAP URI的示例。同样，对于IoT，在RFC6690“受限RESTful环境链路格式(Constrained RESTful Environments Link Format)”(http://tools.ietf.org/html/rfc6690)中定义了URI的描述及其属性和关系，并且称为“CORE链路格式”。

下面的详细用例图示了当前资源目录如何工作及其一些缺点。假设大型工厂在建筑中分布有1000个温度传感器。图2图示了向资源目录登记了URI的温度传感器202、204、和206。如图2所示，传感器202、204、或者206中的每一个将开始向本地资源目录208登记(经由CoAP Post)其资源(URI)。这将允许资源目录构建URI数据库。在实践中，在范围上资源目录一般位于本地。例如，大城市可能会具有多个资源目录。然而，理论上，没有任何事物能阻止资源目录208在范围上全球化。资源目录的范围完全是一种实现和部署选择。

图3图示了客户端302向资源目录查询温度传感器列表的示例。如图3所示，在温度传感器202、204、和206向资源目录登记其URI之后，客户端发送搜索查询(经由CoAP GET)。搜索查询请求资源目录识别哪些URI将提供在工厂域中的温度读数。这是通过作为查询的一部分的搜索参数来指定的。

图4图示了在相同的示例中资源目录208如何响应于客户端搜索查询而返回未过滤的温度传感器列表。资源目录使用其已经登记在数据库中的1000个温度传感器URI的完整列表进行响应(经由CoAP GET响应)。

图5中图示了在该当前IoT模型中客户端所面临的挑战。根据响应于客户端的查询而返回的1000个温度传感器的列表，客户端应该尝试访问1000个URI中的哪些URI？基本假设是：由于时间、带宽、处理能力等的限制，客户端302访问所有1000个URI是不实际的。

作为附加背景信息，oneM2M(例如，如在“oneM2M Functional Architecture”oneM2M-TS-0001oneM2M Functional Architecture-V-0.42中所公开的)旨在指定可以容易地嵌入各种硬件和软件内以支持不同的M2M应用(诸如，联网汽车、智能健康等)的公共服务层。作为公共服务层，OneM2M基本上定义了公共服务功能集合，例如，发现公共服务功能。一种或者多种特定类型的公共服务功能的集合的实例化被称为公共服务实体。可以将公共服务实体托管在不同类型的网络节点(诸如，基础结构节点、中间节点、或者应用专用节点)上。

图6图示了oneM2M功能架构600，其中：1)应用实体(AE)602可以经由Mca接口访问并且利用在公共服务实体(CSE)604中的公共服务功能；2)公共服务实体604可以经由Mcc接口与另一公共服务实体606通信；3)公共服务实体604还可以经由Mcn接口利用来自基础网络的网络服务实体(NSE)608。例如，作为公共服务实体，M2M服务器具有发现公共服务功能，应用实体可以利用该发现公共服务功能来搜索维护在M2M服务器或者甚至在M2M有权访问的其它地方中的资源。

发明内容

由于多种原因，用于常规互联网中的高级搜索引擎优化的技术不能直接地用于IoT或者M2M。第一，许多搜索引擎优化技术是基于强大的搜索引擎(诸如，Google)的模型。在该模型中，搜索引擎在整个万维网中发出web爬虫以检测网站属性(例如，交叉链路、关键字等)。然而，IoT或者M2M模型的根本差异在于：虽然存在存储URI的资源目录，但这些URI是通过服务器直接地推送到资源目录的。另外，资源目录不发出任何类型的web爬虫来确定web空间的属性。在IoT或者M2M模型中，资源目录被正在查找特定资源(URI)的用户用作搜索引擎。

第二，在大多数IoT或者M2M情况中，无人参与IoT或者M2M搜索。与在常规互联网中的web搜索不同，在IoT或者M2M搜索中，人类不能对要从具有大量返回的URI的搜索结果选择哪个URI做出认知决策。相反，在IoT或者M2M搜索中，搜索结果通常返回至具有有限决策力和有限处理能力的受限设备。最后，将常规互联网网站假设为总是可用。然而，在IoT或者M2M中，许多服务器可能会频繁地进入睡眠模式，并且因此并非总是可用。当前在常规互联网web搜索结果中未考虑到该特性。

因此，需要向当前资源目录功能性增添将向IoT或者M2M提供最高效的搜索结果的更高级的搜索引擎优化。所述高级搜索引擎优化可以允许资源目录向客户端提供优化的结果，以选择最好的URI。

本文描述了用于在包括服务器和资源目录的网络中向资源目录提供搜索引擎优化的方法、设备、和系统。在示例实施例中，资源目录登记从服务器接收的统一资源标识符。资源目录可以基于测量在每一个统一资源标识符之间的交叉链路来确定统一资源标识符的初始排名。统一资源标识符越多地被另一个统一资源标识符交叉链接到，则所述统一资源标识符的排名越高。资源目录还可以基于识别统一资源标识符的上下文来确定初始排名。统一资源标识符的上下文可以包括：资源类型、域、地理定位、组播、以及单播。资源目录可以基于上下文，诸如相同的资源类型来选择一组统一资源标识符，并且将该一组统一资源标识符排名为高于未选择的统一资源标识符组。在确定初始排名时，资源目录可以生成存储初始排名的排名数据库。

响应于从客户端接收的搜索查询，资源目录可以确定存储在排名数据库中的统一资源标识符的实时排名。可以通过检查每一个服务器的睡眠状态来确定所述实时排名。例如，如果统一资源标识符在搜索时正处于睡眠，那么将所述睡眠的统一资源标识符排名为低于清醒的另一个统一资源标识符，或者将所述睡眠的统一资源标识符从搜索结果完全移除。还可以基于部分地平衡服务器的流量负载来确定实时排名。可以将已经多次排名较高或者已经检测为具有较高的流量流的统一资源标识符排名为低于其它统一资源标识符。在确定实时排名后，资源目录可以生成过滤且优先化的统一资源标识符的排名列表，并且将该排名列表返回至客户端。

提供该发明内容是为了以简化的形式介绍对于在下面的详细说明中进一步描述的概念的选择。该发明内容不旨在识别所要求的主题的关键特征或者必要特征，也不旨在限制所要求的主题的范围。此外，所要求的主题并不限于解决在本公开的任何部分中提到的任何或者全部缺点的限制。

附图说明

通过下文结合附图以示例的方式给出的说明书可以得到更详细的理解，所述附图中：

图1是图示了在常规(非IoT)互联网中与服务器-A的交叉链接的示例的系统图；

图2是图示了向资源目录登记其统一资源标识符的温度传感器的系统图；

图3是图示了客户端向资源目录查询温度传感器列表的示例的系统图；

图4是图示了资源目录返回未过滤的温度传感器列表的示例的系统图；

图5描绘了客户端所面临的从未过滤的统一资源标识符列表获取资源的挑战；

图6是图示了oneM2M服务层功能架构的系统图；

图7是图示了根据示例实施例的演进型资源目录架构的系统图；

图8是图示了根据示例实施例的总体资源目录过程的流程图；

图9是图示了根据示例实施例的用于交叉链接排名的子过程的流程图；

图10是图示了根据示例实施例的向资源目录登记其统一资源标识符的温度传感器的系统图；

图11是图示了根据示例实施例的向资源目录查询温度传感器列表的客户端的系统图；

图12是图示了根据示例实施例的返回过滤的温度传感器列表的资源目录的系统图；

图13是图示了根据示例实施例的仅从最高排名的统一资源标识符的集合取得资源的客户端的系统图；

图14是图示了根据示例实施例的在M2M/IoT服务层中具有搜索引擎优化的资源目录的系统图；

图15是图示了根据示例实施例的在oneM2M功能架构中的公共服务功能内的资源目录的系统图；

图16是图示了根据示例实施例的在公共服务功能内用于资源登记和资源查询的资源目录过程的流程图；

图17是图形用户界面的示意图；

图18A是可以实现一个或者多个公开的实施例的示例机对机(M2M)或者物联网(IoT)通信系统的系统图；

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

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

图18D是其中可以体现图18A的通信系统的方面的示例计算系统的框图。

具体实施方式

提供随后的详细说明是为了图示示例性实施例，并且不旨在限制本发明的范围、适用性、或者配置。在不脱离本发明的精神和范围的情况下，可以对元件和步骤的功能和布置做出各种改变。

在本公开中将使用下面的缩写和定义：

AE 应用实体

CoAP 受限应用协议

CORE 受限RESTful环境

交叉链路 在两个URI之间定义的关系。具体地，一个URI

指向(通向)另一个URI。

CSE 公共服务实体

CSF 公共服务功能

HTTP 超文本传输协议

IETF 互联网工程任务组

IoT 物联网

M2M 机对机

NSE 网络服务实体

RD 资源目录

资源 可以通过URI识别并且可以通过网络传输协议

访问的网络数据对象或者SW进程。

REST 具象状态转移

(用于网络传输协议的通信的无状态请求/响应

模型)

SEO 搜索引擎优化

URI 统一资源标识符

(用于识别CoAP或者HTTP资源的字符串。)

web搜索 设计为在web(互联网)上搜索包含期望信息的

URI的软件系统。

web传输协议 用于在web(互联网)中传输资源的协议。HTTP

和CoAP是IoT的关键协议。使用web传输协议

的应用可能各种各样。一个示例是web浏览器

(客户端)和内容服务器(例如，安全摄像机)。

另一个示例是温度传感器软件(客户端)和控制

服务器。

本公开的演进型RD可以将过滤且优先化的搜索结果提供给针对RD的客户端搜索查询。这可以允许客户端扫描优化的搜索结果，以为其正在查找的资源快速地选择最好的URI。在示例实施例中，关于初始地存储URI并且稍后对客户端搜索请求做出响应，RD的架构包括RD功能块和处理序列。RD功能块可以包括用于将最好的搜索结果提供给客户端的以下URI排名/过滤功能：

●睡眠节点处理：将在客户端搜索请求时刻当前正唤醒的服务器对应的URI的排名提高。与当前睡眠的客户端相关联的URI可以过滤掉或者将其排名降低。

●准负载平衡处理：将与具有较少感知负载的服务器对应的URI的排名提高。

●上下文处理：对URI进行过滤，以减少表示相同物理属性(例如，温度传感器)并且来自相同逻辑域(例如，子网络)的URI的数量。同样，将属于组播(multicast)组或者与提出请求的客户端处于相同地理定位的URI的排名提高。

●URI交叉链接处理：检查在URI(一般指示高值URI)之间的链路，并且将那些URI的排名提高。

在一个实施例中，可以改变现有的IETF协议以支持在从RD发送至客户端的搜索结果中指示URI的排名。而且，可选地，客户端可以在初始搜索请求查询中指示排名范围和客户端感兴趣的其它信息。

RD架构

图7图示了根据示例实施例的演进型RD架构700。具体地，示出了在RD 702中的信息流和处理块。下面是高级描述：

在图7的步骤1中，RD 702可以具有用于推送(登记)URI和拉取(查询)URI的单独的逻辑数据库。登记数据库704可以是从登记其CoAP资源的服务器接收的URI的原始数据库。处理后数据库706可以用于提供对查询的响应。

在图7的步骤2中，RD 702可以具有用于对URI进行初始排名的新处理块708。该新处理块可以包括测量交叉链接和/或识别上下文以确定初始排名。由于其独立于未来客户端搜索查询，这些初始处理块708可以离线执行或者作为后台处理而执行。

在图7的步骤3中，随后将初始排名的URI放入单独的URI的处理后数据库706中。注意，原始数据库704和处理后数据库706在逻辑上可以分开。原始数据库704和处理后数据库706可以实现在单个物理数据库中，或者可以实现在分离的的物理数据库中。

在图7的步骤4中，客户端搜索查询可以转到RD 702的处理后数据库706，该处理后数据库706拉取与客户端查询参数相应的初始排名列表。

在图7的步骤5中，实时处理块710可以用于睡眠状态和准负载平衡。RD 702可以基于在RD内可用的信息来执行实时检查，以确定选择的URI是否在当前正睡眠的服务器上。如果服务器当前正睡眠，那么可以从要发送回客户端的响应中完全过滤掉那些“睡眠”的URI。替选地，可以将睡眠的URI排名为最低。RD 702还可以基于在RD 702内的信息来执行准负载平衡以确保排名功能不总是将在网络中的相同URI(资源服务器)排名为最高而结束。准负载平衡也是实时进程。

在图7的步骤6中，将排名并且过滤的URI列表返回至客户端作为对其搜索请求的响应。最终排名可以是在不同处理(子排名)块上的加权平均，并且考虑到了URI的静态(即，初始排名)和动态(即，实时排名)的组合。

如上所述，在范围上RD 702一般位于本地。例如，大城市可能会在不同定位中具有多个RD。然而，理论上，没有任何事物能阻止RD 702在范围上全球化。RD 702的范围完全是一种实现和部署选择。假设在单个RD 702的范围内执行上文描述的SEO技术。

要理解，可以将图7中图示的功能性实现为存储在M2M网络的节点(例如，服务器、网关、设备、或者其它计算机系统)(诸如，下文描述的图18C和18D中图示的那些中的一个)的存储器中存储的、并且在所述节点的处理器上执行的软件(即，计算机可执行指令)的形式。

RD排名和过滤功能

图8图示了根据示例实施例的总体RD过程。在演进型RD 702中的总体RD过程可以包括如图7和图8图示的多种排名和过滤功能。图8中的总体RD 702过程的关键输出可以是URI列表，其中，在所述列表中的URI的每一个与将被用作对客户端搜索请求的响应的排名相关联。同样要注意，通常可以从RD过程的最终输出过滤掉一些或者许多URI，并且客户端可能看不见这些URI。

在图8的步骤802中，通过服务器801来登记URI。

图8的步骤804、806、808、和810形成用于处理URI的排名数据库的循环。在图8的循环中，步骤806用于测量URI的交叉链接，而步骤808用于识别给定URI的上下文。

在图8的步骤812中，处理URI的数据库。

图8的步骤814、816、818、和820示出了对来自客户端302的请求做出响应的RD702。

在图8的步骤814中，从客户端302接收搜索请求。

在图8的步骤816中，将最终排名且过滤的搜索提供给客户端302。

图8中示出的整个RD过程可能需要在来自客户端的相同搜索请求(即，具有相同输入参数的查询)之间重新运行。这主要是因为实时排名功能。随着时间的流逝，该部件可能会导致不同的排名输出。另外，RD过程的变型可以实现相同的排名结果。例如，首先可以将URI分成不同的组(例如，具有交叉链路的一组URI、和没有交叉链路的另一组)。随后，如图8所示，每次登记新URI时，可以不需要循环通过所有URI。

在一个实施例中，推荐与每一个URI相关联的排名参数是在(0-63)之间的绝对值。这可以在不会变得过大的情况下提供区分各个URI的足够的值。多个URI还可以具有相同排名值而结束。可以将给定URI的最终排名参数计算为不同排名子排名(例如，交叉链路、上下文等)的加权平均。例如：

·排名(Rank)＝(权重_1×排名_交叉链接+权重_2×排名_上下文+权重_3×排名_睡眠+权重_4×排名_准负载平衡)/4

其中，“权重”可以是在0到1之间的因子。例如，在负载平衡非常重要的系统中，应该将权重_4设置为1。替选地，例如，如果已知在网络(例如，仅有几个设备的家)中的总流量负载非常低，那么应该将权重_4设置为0.1。

排名值的分配和有关的处理可以是每一个RD 702的内部决策。然而，客户端仍然可以获得满足其输入搜索准则的URI的有价值且明确的排名输出列表。这可以遵循如用于当前常规互联网的相同方法，在这种方法中，每一个搜索引擎(例如，Google、Bing)可以针对相同的输入搜索参数返回不同的URI排名列表。例如，如果将“最好的披萨”键入到谷歌和必应，随后比较搜索结果，便可以容易地看出这点。然而，演进型RD 702对如何完成用于IoTRD的高效排名方案给出了不同的架构和详细的指导。

要理解，执行图8中图示的步骤的实体是可以被实现为存储在网络节点或者计算机系统(诸如，图18C或者18D图示的网络节点或者计算机系统)的存储器中、并且在该网络节点或者计算机系统的处理器上执行的软件的形式的逻辑实体。即，图8中图示的方法可以被实现为存储在网络节点(诸如，图18C或者图18D中图示的节点或者计算机系统)的存储器中的软件(即，计算机可执行指令)的形式，所述计算机可执行指令当由节点的处理器执行时执行图8中图示的步骤。还要理解，可以在所述节点的处理器及其执行的所述计算机可执行指令(例如，软件)的控制下，所述节点的通信电路执行图8中图示的任何传输和接收步骤。

1.URI交叉链接处理：

在IoT中，仍然将URI交叉链接视为很重要。在IoT中，交叉链路的最常见表达是URI与另一个URI具有定义的关系。有时，这也称为“类型链路(typed link)”，如在RFC6690“Constrained RESTful Environments Link Format(受限RESTful环境链路格式)”(http://tools.ietf.org/html/rfc6690)中描述的，其通过引用的方式并入本文使得所述公开在本文中被完整地阐述。

针对IoT的交叉链路的示例：如果出于冗余性目的，报警控制器服务器在另一个服务器上具有替选URI。服务器可以经由链路格式“主机”和“锚”参数向其URI指示有关的链路。具体地，这将在服务器向RD登记或者重新登记其资源(URI)时由服务器指示。该IoT交叉链接可以如下表示：

●示例场景：

o出于冗余性目的，报警控制器服务器(URI-1)想要指示替选服务器(URI-2)

■即，如果URI-1不可用，那么客户端可以转到URI-2

o因此，当服务器将URI-1登记在RD中时，其可以通过使用以下规约来如下指示URI-2的交叉链路：

■coap://home.alarm1/server1/alarm；

■anchor＝"coap://home.alarm2/server2/alarm"；

■rel＝"alternate"

因此，可以使用主机和锚作为交叉链接的措施。如在常规互联网中一样，可以将交叉链路假设为URI的“流行度”的指示。即，指向给定URI的交叉链路越多，则应该假设该给定URI越流行并且排名越高。

图9图示了根据示例实施例的交叉链接排名的子过程。例如，如图9所示，一旦服务器将URI登记到RD，则RD可以运行以下过程来检测交叉链接。

图9的步骤902、904、906和908循环通过登记在RD中的所有URI。

图9的步骤904和906计数(并且归一化)给定URI交叉链接至另一个URI的次数。该归一化是指排名参数可以具有预定义范围并且可能需要将交叉链路的计数映射到该范围的事实。例如，预定义范围在0到100之间，并且已经将给定URI计数为具有1000个交叉链路(最多的交叉链路)。RD可以将具有1000个交叉链路的URI映射至最高的排名(排名0)。如果给定URI仅仅具有20个交叉链路(最少的交叉链路)，那么RD可以将具有20个交叉链路的URI映射至最低的排名(排名100)。

将结果记录在反映与该URI的交叉链接的次数的排名_交叉链路参数中。

在示例实施例中，如果服务器曾经请求所述RD删除具有交叉链路的资源(即，URI)，那么该过程可以重新运行。同样，在要求填入任何未来客户端搜索查询将在此处进入RD的处理后URI数据库的所述客户端查询之前，该过程可以离线运行或者运行为后台处理。在另一示例实施例中，可以运行该过程的变型，从而实现测量交叉链接的相同结果。例如，或许能够标记具有锚参数的URI并且只检查那些URI，而不是如图9所示地浏览数据库中的所有URI。

要理解，执行图9中图示的步骤的实体是可以被实现为存储在网络节点或者计算机系统(诸如，图18C或者18D图示的网络节点或者计算机系统)的存储器中、并且在该网络节点或者计算机系统的处理器上执行的软件的形式的逻辑实体。即，图9中图示的方法可以被实现为存储在网络节点(诸如，图18C或者图18D中图示的节点或者计算机系统)的存储器中的软件(即，计算机可执行指令)的形式，所述计算机可执行指令在由所述节点的处理器执行时，执行图9中图示的步骤。还要理解，图9中图示的任何传输和接收步骤可以在所述节点的处理器及其所执行的计算机可执行指令(例如，软件)的控制下，所述由节点的通信电路执行。

2.睡眠节点处理

与常规互联网节点相比，IoT节点的其中一个关键特征在于：IoT节点可能经常被低供电，因此经常会进入“睡眠”。例如，IoT节点或者服务器可能是电池或者太阳能供电，并且当其需要节省电力时进入低功率模式。这对IoT节点或者服务器的可用性具有明显的影响。即，托管URI或者包含URI所指向的底层资源内容的服务器可能并不总是处于上电状态以实际地维护CoAP请求以访问这些URI。幸运的是，RD能够使用睡眠追踪机制来追踪困乏服务器。具体地，期望具有睡眠追踪机制的这些RD了解向其登记了URI的服务器的睡眠调度。这种基于RD的睡眠追踪机制确定目标资源是否位于困乏服务器上并且困乏服务器当前是否处于睡眠模式。

困乏服务器可以包括多个参数，例如：1)指示节点当前是否处于睡眠模式的睡眠状态；2)指示节点处于睡眠模式的最大持续时间的睡眠持续时间；3)指示节点已经处于睡眠的时间长度的睡眠时间；以及4)指示节点下一次将进入睡眠的下一次睡眠。困乏服务器的这些参数可以由RD存储并且由所有感兴趣的客户端访问。在2014年2月12日更新的“CoAP的增强型困乏节点支持(Enhanced Sleepy Node Supprot for CoAP)”的互联网草案(http://tools.ietf.org/html/draft-rahman-core-sleepy-05)中对本文提供的基于RD的睡眠追踪进行了描述，其通过引用的方式并入本文使得所述公开在本文中被完整地阐述。因此，如下所述，如果RD考虑在搜索响应中的URI的睡眠状态，那么对于客户端而言将非常有利。

如图7和图8所图示的，在对资源(URI)的搜索请求做出响应之前，但在执行初始排名功能之后，RD可以执行对存储的睡眠调度的内部实时查找，以判断任何选择的URI是否涉及当前正睡眠的服务器。RD可以顺序地查找在初始排名数据库中的每一个URI或者基于搜索查询中的条件而选择的一些URI。例如，如果在搜索查询中的条件将URI指定为特定资源类型，那么RD仅仅查找在初始排名数据库中具有特定资源类型的URI的睡眠状态。在这种情况下的“实时”指的是当客户端搜索请求进入RD时相同的物理(时钟)时间。这与在客户端搜索之前某些时间处进行的初始过滤不同。检查本身是比较已经包含在RD内的服务器睡眠调度，并且判断在当前时刻服务器是睡眠的还是清醒的。RD不需要访问在RD外部的任何信息以执行该实时检查。

可以按照两种替选方式中的一种来处理当前处于睡眠的URI的排名。一种替选方式是将“睡眠”的URI排名为较低的排名，因为其当前不可用。在未来当所述设备暂时清醒的一段时期内，所述睡眠的URI是可访问的。另一种替选方案是从返回至提出请求的客户端的搜索结果中彻底移除睡眠的URI。在该替选方案中，针对搜索结果给出的解释是其仅仅返回当前可访问的(清醒的)URI。

为了能够根据其睡眠调度而适当地同步在对URI的搜索请求和进入睡眠模式的服务器之间的时间，可以要求RD具有可用的准确实时时钟功能。注意，RD可以与在睡眠服务器中的时钟同步或者异步。在异步模式中，RD可以在提供搜索请求时包括一些安全缓冲时间，以确保不会由于在RD与服务器之间的时钟漂移而意外地假设当前睡眠的节点是清醒的。例如，如果存储的睡眠调度指示睡眠的服务器本应该在2秒前醒来，并且在RD与困乏服务器之间存在几秒的时钟漂移，那么RD可以保守地向睡眠调度添加5秒的睡眠，且判断服务器将再睡眠3秒。安全缓冲时间可以是乐观的或者悲观的。这意味着RD可以添加睡眠时间或者减少睡眠时间来确保不会将当前睡眠的节点意外地假设为是清醒的。替选地，RD可以接收服务器的睡眠调度或者睡眠状态的动态更新，这可以允许其定期地重新同步。

3.准负载平衡处理

IoT设备(诸如，传感器)通常在客户端和服务器模式两者中操作。例如，当传感器正在向RD登记资源(URI)时，所述传感器正在扮演客户端模式。这是因为在这种情况下客户端正在将CoAP/HTTP请求(例如，PUT)发送至充当服务器的RD。并且，随后，RD可以执行功能(即，存储URI)并且制定对客户端的响应。相反地，如果控制器查询传感器，那么传感器会充当服务器的角色。这是因为，在这种情况下传感器正在接收请求(例如，GET)并且将执行功能(即，测量温度)。并且随后，传感器可以制定对控制器的响应。因此，所述传感器被认为是服务器。

IoT服务器通常由于其本身性质而在其资源方面受限。单独服务器不超载请求很关键。例如，针对给定搜索输入，如果RD正好始终将单个服务器排名较高，由于很多客户端可能自然地选择该URI，这可能导致在该服务器上的负载问题。因此，RD基于预期的负载来针对给定搜索输入试图平衡将哪个服务器排名较高很重要。

可以以若干方式通过RD来估计负载。一种方式是记录过去的搜索结果，并且将此作为因素考虑到当前/未来搜索结果中。此处假设，如果给定URI已被多次排名为较高，那么其可能正在接收比较低排名的URI相对更多的流量。因此，作为间接地负载平衡该特定URI的方法，在未来的搜索中，应该将该特定URI排名为稍低。例如，第一搜索结果可以包括10个温度传感器，其中，传感器1的排名为0而传感器2的排名为1。在第二次请求相同的搜索时，第二次搜索结果可以与第一次搜索结果相同(并且排名可能是相同的)。然而，响应于第三次接收到相同的搜索结果，RD可以确定前两次进行搜索请求时已经将传感器1排名为较高，并且在该第三次时将传感器1排名为低于传感器2，以避免传感器1上的相对较高的流量。因此，在第三次搜索结果中，传感器2的排名可以为0而传感器1的排名可以为1。在另一示例实施例中，RD还可以考虑计时器作为因素。例如，如果搜索请求相隔几分钟或者几小时，并且在该几分钟或者几小时期间将特定URI排名为高于其它URI，那么RD可以确定在未来的搜索中应该将特定URI排名为较低以避免在该特定URI上的高流量。

另一种方法是记录进入所述URI的实际请求/流量。当RD与其中正通过流量的反向代理或者边界节点上物理地同定位时，这是b可能的。这意味着RD具有访问额外的非RD功能的权限。例如，在基于oneM2M的系统中的网关中实现的RD可以知道去到URI的实际请求或者流量，这是因为网关保持了对URI的请求或者流量的统计，并且RD可以访问该统计。而且，服务器本身可以提供有用的信息，诸如，服务器是否是由电池或者干线供电、其电池电量等。例如，在电池供电的服务器和干线供电的服务器中，RD可以选择将电池供电的服务器的排名降低以节省其电池。在另一示例中，RD可以将电池电量低的服务器排名为低于电池电量高的服务器以节省其电池。此外，这些信息可能来自带外信息源，诸如，RD在提供搜索结果时可以考虑的操作和维护系统(配置信息)的部分。在该功能与下文描述的上下文处理之间还可能存在较强的交互。

该准负载平衡功能可以给出部分但不完整的负载平衡解决方案。这是因为全负载平衡解决方案将需要在服务器中的实际负载(包括由服务器生成的流量)的更精确的知识。然而，这可能超出了SEO RD解决方案的范围。该准负载平衡主要基于来自内部RD评估的感知负载。

4.上下文处理

在这种情况下，上下文可指URI与其它有关URI的物理或者逻辑关系。示例可以包括：

●与其它相似的URI(例如，温度传感器)处于相同逻辑域(例如，子网络)的URI。

●属于给定IP组播组(例如，在四楼的所有灯)的URI。

●物理上(即，地理定位)接近其它相似的URI的URI。

●不属于任何组的URI(即，是单播)。

IoT场景通常涉及测量在有限地理区域(例如，建筑、场地、邻近区)内的相同物理属性(例如，温度、湿度等)的大量传感器。基于从登记信息接收的“资源类型(rt)”参数，RD知道传感器的特性。因此，一种有用的过滤方法可能是：RD选择具有相同资源类型并且属于相同“域”的传感器的子集，例如，如在2013年12月11日更新的CoRE资源目录(CoREResource Directory)的互联网草案(http://tools.ietf.org/html/draft-ietf-core-resource-directory-01)中定义的。例如，如果在相同域(例如，建筑子网络)中存在1000个温度传感器，那么RD可以基于所述传感器的各种上下文选择仅仅向客户端报告在搜索结果中的这些传感器的较小子集。还可以通过与如上所述的准负载平衡功能的交互来选择子集。替选地，可以向客户端报告所有传感器，但是选择的URI的子集可以具有高排名值，而剩余的传感器可以具有低得多的排名值。

IoT还可以支持URI的组通信模式，例如，如在2013年12月23日更新的“CoAP的组通信(Group Communication for CoAP)”的互联网草案(http://tools.ietf.org/html/draft-ietf-core-groupcomm-18)中公开的。在这种模式中，单个URI经由IP组播映射至一组服务器。目前在常规互联网中还不支持这种组通信模式。因此，另一种非常有用的排名准则是RD可以将正在映射至一组服务器的组播URI排名为高于单播URI。例如，尽管每一个组播URI可以具有相同的排名，但是它们会中的每一个的排名至少比单播URI高一个。这是因为底层组通信机制可以每个URI向客户端传送比单播URI更多的信息。即，单个CoAP组通信请求(例如，GET)可以返回多个响应，这是因为该请求经由IP组播分布到已经订阅该组的多个服务器。

根据场景，还可以基于各种其它准则来计算上下文。例如，如果在RD中地理定位特征可用，那么可以给予与最靠近提出请求的客户端的URI相关联的服务器较高的优先级。例如，在2014年2月12日更新的“用于定位事物的链路格式属性(A Link-Format Attributefor Locating Things)”的互联网草案(http://tools.ietf.org/html/draft-fossati-core-geo-link-format-attribute-03)中公开了该地理定位特征。这可以要求客户端按照对RD而言是标准化的方式将其自身定位信息包括在搜索请求中。

信令变化

可以改变与CoAP和HTTP有关的信令以支持演进型RD的SEO类功能。具体地，在实施例中，客户端可以通过在其搜索请求中指示其对特定数量的URI感兴趣和/或其对非困乏节点感兴趣来限制搜索响应的大小。来自RD的搜索响应可以将该输入纳入考虑，并且还在搜索响应中明确地指示每一个URI的排名。

在实施例中，可以更新CORE链路格式以支持在搜索响应中的“排名”的以下参数。可以结合CoAP或者HTTP协议使用CORE链路格式：

●在对客户端的查询响应(即，GET响应)中，RD可以通过新参数(即，“排名”)来指示返回的URI的排名。该排名可以优选地如下解释：

o推荐排名参数是在(0-63)之间的绝对值。然而，这是示例编码，并且也可以使用其它范围(例如，0-100)。关键准则可以是：排名范围应该在不会变得过大的情况下提供用于区分各种URI的足够的值。

o在推荐的排名编码中，可以将排名值“0”视为最高优先级URI。可以将排名值“63”视为具有最低优先级的URI。

o可以从第一个具有排名＝0的URI开始对返回的URI列表进行连续地排名。注意，多个URI可以具有相同的排名值而结束。

●下面的示例示出了客户端利用资源类型温度传感器(rt＝temperature_sensor)对所有端点执行查找。

o请求：GET coap://rd-lookup/ep？rt＝temperature_sensor

o响应：2.05内容

■<coap://sensorA.home>；ep＝”node_A”；rank＝0

■<coap://sensorC.home>；ep＝”node_C”；rank＝1

■<coap://sensorB.home>；ep＝”node_B”；rank＝2

■<coap://sensorD.home>；ep＝”node_D”；rank＝3

●注意，随着时间的流逝，发送至RD的给定的相同的查询请求可以导致排名的URI的不同响应。这可能主要是由于对URI排名的准负载平衡和困倦节点检查的影响，因为它们都与时间有关。

另外，可选地，在对RD的初始客户端查询(即，GEI请求)中，客户端还可以指示对CoAP协议和HTTP协议两者的以下偏好：

●在搜索结果中客户端可以接受的排名参数值的范围。例如，客户端可以指示其仅接受在范围(0-10)内的排名。因此，在这种情况下，RD可能需要另外过滤掉排名在范围(11-63)内的URI的任何内部搜索结果。

●客户端是否想要将困乏节点包括在搜索结果中。

例如，所述CoAP协议被公开在2013年6月28日更新的受限应用协议的互联网草案(http://tools.ietf.org/html/draft-ietf-core-coap-18)中，其通过引用的方式并入本文使得所述公开在本文中被完整地阐述。所述HTTP协议被公开在RFC2616“超文本传输协议-HTTP/1.1(Hypertext Transfer Protocol-HTTP/1.1)”(http://tools.ietf.org/html/rfc2616)中，其通过引用的方式并入本文使得所述公开在本文中被完整地阐述。

可以优选地包括信息(诸如，排名的范围、资源类型、和睡眠状态指示)作为CoAP/HTTP搜索请求的URI串的查询部分的一部分，如在RFC3986“统一资源标识符”(URI)：通用语法”(http://tools.ietf.org/html/rfc3986)中公开的，其通过引用的方式并入本文使得所述公开在本文中被完整地阐述。

●GET

coap://rd-lookup/ep？rt＝temperature_sensor&rank＝0&rank＝1&slee

py＝No

●其中，对RD的请求以查找如下URI：

■类型＝“温度传感器”

■并且排名＝(0或1)

■并且不应该将困乏节点包括在搜索结果中。

如上所述，上文定义的所有参数(即，排名、困乏节点指示)可以在IETF中标准化或者可以成为事实上的解释。同样存在第三种可能的模型，在该模型中，基于装置制造商和/或网络运营商的私人订阅和业务关系，所有这些参数都可能是专有信息。

示例

图10图示了根据示例实施例的向资源目录登记其统一资源标识符的温度传感器的示例。假设大型工厂在建筑中分布有1000个温度传感器。如图10所示，每一个传感器可以经由CoAP Post开始向本地RD 702登记其资源(URI)。这可以允许RD 702构建原始URI的数据库。RD 702随后可以基于其属性(诸如，如上所述的交叉链接、上下文等)来处理所有URI。随后将排名的URI存储在RD的处理后数据库中。

图11图示了根据示例实施例的向资源目录查询温度传感器列表的客户端。在初始排名的URI被存储在处理后数据库中之后，如图11所示，客户端可以经由CoAP GET发送搜索查询。该搜索查询可以请求RD 702识别哪些CoAP资源(URI)将提供工厂中的温度读数。即，该查询可以指定资源类型为“温度_传感器”，并且指定域是工厂建筑。此外，客户端可以指示其仅仅对排名在范围(0-10)内的URI感兴趣。同样，客户端可以指示其对当前处于睡眠模式中的服务器上的URI不感兴趣。

图12图示了根据示例实施例的返回过滤的温度传感器列表的资源目录。参照图12，RD 702可以经由CoAP GET响应，利用远低于1000个条目(即，少于传感器的总数)的优先级化的URI的列表来做出响应。这是因为初始排名和实时过滤可能已经消除了大量URI。由于客户端指令仅提供在排名(0-10)内的URI，且由于仅考虑当前未睡眠的URI，所以已经明显地消除了一些URI。可以通过RD，使用针对在RD 702的处理后数据库中的URI查找之后出现的与困乏节点有关的URI的实时检查来处理这种情况。

同样，在这种情况下，所述传感器可以具有相同的资源类型并且位于相同的域。因此，RD上下文识别功能可以消除来自搜索列表的大量URI，这是因为它们被假设为测量相似(温度)值。搜索结果列表较小的另一个原因是因为假设许多传感器当前正睡眠。

图13图示了根据示例实施例的仅从最高排名的统一资源标识符取得资源的客户端。参照图13，客户端随后可以容易且高效地仅请求在过滤的RD搜索结果中返回的最高三个URI。所请求的URI的最终数量可以取决于客户端应用。

为了清楚起见，本文描述的大部分示例示出了CoAP的使用。然而，一般地，可以利用HTTP来容易地实现等效的功能。同样，如例如2014年2月12日更新的HTTP-CoAP映射实现指南(Guidelines for HTTP-CoP Mapping Implementation)的互联网草案(http://tools.ietf.org/html/draft-ietf-core-http-mapping-03)中所公开的，HTTP和CoAP交互工作的混合网络也可以实现等效的功能，。

要理解，图10至图13中图示的功能性可以被实现为M2M网络(例如，服务器、网关、设备、或者其它计算机系统)(诸如，下文描述的图18C或者18D中图示的那些中的一个)的存储器中存储的、并且在所述M2M网络的节点的处理器上执行的软件(即，计算机可执行指令)的形式。

图14图示了具有在M2M/IoT服务层中实现的搜索引擎优化的资源目录的实施例。如上所述，RD的SEO类功能(例如，排名和过滤功能)可以拓展至IoT服务层，诸如在“oneM2MFunctional Architecture”oneM2M-TS-0001oneM2M Functional Architecture-V-0.4.2中公开的HTTP或者CoAP层上方的层，其通过引用的方式并入本文使得所述公开在本文中被完整地阐述。图14中图示了本实施例的示例，该示例具有下主要观点：

●服务器801可以驻留在IoT装置1402(例如，3GPP机器类型通信设备)中，而客户端可以是IoT应用的一部分。

●RD 702(包括如上所述的SEO类特征)可以实现为IoT网关1404或者IoT服务器的一部分。

●服务器801可以通过服务层接口来将资源登记到RD 702，而客户端同样可以通过服务层接口向RD 702发出查询。在IoT网关1404中的RD 702可以运行SEO类特征并且通过服务层接口向客户端302返回排名的URI的列表。

对于图14中示出的、RD 702是oneM2M网关的一部分的网络，RD 702的范围可以与网关域对应。即，在网关所服务的M2M区域网络中的所有装置(服务器)可以将其资源登记到RD 702。RD 702随后可以处理与这些资源对应的URI并且对所述URI进行排名。至RD 702的搜索查询随后可以来自或者网关域的内部或者来自外部网络域。RD 702随后可以返回具有涵盖了位于网关域内部的服务器的排名的URI的搜索结果。

如果如图14所示，SEO-RD在本地实现为oneM2M网关的一部分，那么RD 702可以容易地具有访问经由网关1404流向IoT装置/流出IoT装置的用户平面流量的统计的权限。这可以使RD实现上文描述的准负载平衡功能变得更容易。具体地，RD 702或许能够监测对位于网关边界内部的URI(资源)的外部请求(例如，CoAP GET)。这可以允许RD 702将负载指标作为因素纳入排名计算中，RD 702将该排名计算作为准负载平衡算法的一部分。

图15图示了根据另一示例实施例的在oneM2M功能架构中的RD CSF 1502。如图15所示，可以将上文描述的SEO类特征(例如，排名和过滤)实现为新oneM2M CSF(称为RD CSF1502)并且实现为oneM2M CSE的一部分。CSE1 1504可以是M2M/IoT网关或者服务器。RD CSF1502可以具有以下功能：

●RD CSF 1502可以接受来自AE或者CSE的资源登记并且维护所有登记的资源。

●RD CSF 1502可以根据上文描述的机制对登记的资源进行排名。

RD CSF 1502可以处理来自AE或者CSE的资源查询并且返回上文描述的过滤的资源列表。要理解，图14至15中图示的功能可以被实现为M2M网络(例如，服务器、网关、装置、或者其它计算机系统)(诸如，下文描述的图18C或者18D中图示的那些中的一个)的存储器中存储的、并且在该M2M网络的节点的处理器上执行的软件(即，计算机可执行指令)的形式。

图16基于图15示出的RD CSF 1502，图示了资源登记过程和资源查询过程。

在图16的步骤1中，请求者1 1602(例如，AE或者CSE)可以将资源登记请求消息发送至RD CSF 1502。该消息可以包含以下信息：1)待登记的资源的列表；2)如上文描述的每一个资源的属性，诸如，其URI、交叉链路、负载、上下文、定位、以及睡眠调度。

o注意，可以通过使用oneM2M中的现有资源宣告(Resource Announcement)来实现该步骤，但是可能需要对每一个宣告的资源添加额外属性(即，如上文描述的交叉链路、负载、上下文、定位、睡眠调度)。

在图16的步骤2中，RD SCF 1502可以将资源登记响应发送回请求者1 1602。

在图16的步骤3中，RD CSF 1502可以根据上文描述的方法对所有登记的资源进行排名。

在图16的步骤4中，请求者2 1604(例如，AE或者CSE)可以将资源查询消息发送至RD CSF 1502。该消息可以包含以下信息：1)如上文描述的搜索准则，诸如，期望的排名、期望的资源定位、期望的资源负载。

o注意，可以通过使用oneM2M中的现有Discovery CSF与新的如上文描述的准则(诸如，期望的排名)来实现该步骤。

在图16的步骤5中，RD CSF 1502可以根据上文描述的方法基于包含在步骤4中的准则来搜索其维护的资源。

在图16的步骤6中，RD CSF 1502可以将结果发送至请求者2(即，发现的资源的列表)。

AE或者CSE本身可能是一种资源。随后，可以将由AE或者CSE宣告的资源视作其交叉链路。结果，可以向具有更多宣告的资源(即，更多的交叉链路)的AE或者CSE分配较高的排名，并且其具有较高的可能性被发现并且被返回至请求者2。

同样要注意，在另一实施例中，替代于在新RD CSF中提供本公开的SEO类特征，可以将这些特征实现为对在oneM2M中的现有Discovery CSF的修改。在该替选实施例中，可以应用在图16中的相同过程(仅用修改的Discovery CSF替代RD CSF)。

要理解，执行图16中图示的步骤的实体是可以被实现为网络节点或者计算机系统(诸如，图18C或者18D图示的网络节点或者计算机系统)的存储器中存储的、并且在该网络节点或者计算机系统的处理器上执行的软件的形式的逻辑实体。即，图16中图示的方法可以被实现为网络节点(诸如，图18C或者图18D中图示的节点或者计算机系统)的存储器中存储的软件(即，计算机可执行指令)的形式，其中，计算机可执行指令在由节点的处理器执行时执行图16中图示的步骤。还要理解，图16中图示的任何传输和接收步骤可以在所述节点的处理器和其执行的计算机可执行指令(软件)的控制下由所述节点的通信电路系统执行。

可以使用界面(诸如，图形用户界面(GUI))可以来协助用户控制和/或配置与资源目录的搜索引擎优化有关的功能。图17是图示了允许用户查看对资源目录的搜索结果以理解搜索系统的操作的debug界面1702的示意图。图17还图示了用于调整在资源目录的搜索引擎中使用的搜索参数的界面1704。要理解的是，可以通过使用显示器(诸如，下文描述的图18C-18D示出的显示器)来产生界面1702和1704。

示例M2M/IoT/WoT通信系统

图18A是示例可以实现本文描述的演进型资源目录的SEO类功能的机对机(M2M)、物联网(IoT)、或者物流网(WoT)通信系统10的示意图。通常，M2M技术为IoT提供建筑块，并且任何M2M装置、网关、或者服务平台可以是IoT以及IoT服务层的部件等。

通常，M2M技术为IoT/WoT提供建筑块，并且任何M2M装置、M2M网关、M2M服务器、或者M2M服务平台可以是IoT/WoT以及IoT/WoT服务层的部件或者节点等。通信系统10可以用于实现所公开的实施例的功能性并且可以包括功能性和逻辑实体(诸如，资源目录208和702、传感器(诸如，传感器202、204、和206)、客户端302、AE 602、CSE 604、606和1504、NSE608、数据库704和706、初始排名功能708、实时排名功能710、服务器801、IoT装置1402、IoT网关(或者服务器)1404、RD CSF 1502、请求者1602和1604)、以及用于产生界面(诸如，界面1702和1704)的逻辑实体。

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

如图18A所示，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、蓝牙)、直接无线电链路、和有线)通信。

示例性M2M终端设备18包括，但不限于，平板、智能电话、医疗设备、温度和天气监测器、联网汽车、智能电表、游戏控制台、个人数字助理、健康和健身监测器、灯、恒温器、电器、车库门和其它基于驱动器的设备、安全设备、和智能插座。

参照图18B，在场域中图示的M2M服务层22向M2M应用20、M2M网关设备14、和M2M终端设备18以及通信网络12提供服务。通信网络12可以用于实现所公开的实施例的功能性并且可以包括功能和逻辑实体(诸如，资源目录208和702、传感器(诸如，传感器202、204、和206)、客户端302、AE 602、CSE 604、606、和1504、NSE 608、数据库704和706、初始排名功能708、实时排名功能710、服务器801、IoT设备1402、IoT网关(或者服务器)1404、RD CSF1502、请求者1602和1604)以及用于产生界面(诸如，界面1702和1704)的逻辑实体。可以通过一个或者多个服务器、计算机、设备、虚拟机器(例如，云/存储场(farm)等)等(包括例如下文描述的18C和18D中图示的设备)来实现M2M服务层22。要理解，M2M服务层22可以按照所期望的与任何数量的M2M应用、M2M网关14、M2M终端设备18、和通信网络12通信。可以通过网络的一个或者多个节点(可以包括服务器、计算机、装置等)来实现M2M服务层22。M2M服务层22提供适用于M2M终端设备18、M2M网关14、和M2M应用20的服务能力。可以采用各种方式(例如，作为网络服务器、在蜂窝核心网络中、在云中等)来实现M2M服务层22的功能。

与图示的M2M服务层22相似，在基础结构域中有M2M服务层22’。M2M服务层22’向在基础结构域中的M2M应用20’和底层通信网络12’提供服务。M2M服务层22’还向在场域中的M2M网关14和M2M终端设备18提供服务。要理解，M2M服务层22’可以与任何数量的M2M应用、M2M网关、和M2M设备通信。M2M服务层22’可以通过不同的服务提供商来与服务层交互。通过网络的一个或者多个节点的M2M服务层22’，该一个或者多个节点可以包括服务器、计算机、设备、虚拟机(例如，云计算/存储场等)等。

仍然参照图18B，M2M服务层22和22’提供不同的应用和垂直(vertical)可以利用的服务交付能力的核心集。这些服务能力使M2M应用20和20’能够与设备交互并且执行诸如数据收集、数据分析、设备管理、安全、开账单、服务/设备发现等的功能。本质上，这些服务能力使应用解除了实现这些功能性的负担，从而简化应用开发并且降低上市成本和时间。服务层22和22’还使M2M应用20和20’能够通过与服务层22和22’提供的服务相连接的各种网络12和12’通信。

本申请的方法可以实现为服务层22和22’的一部分。服务层22和22’是通过一组应用编程接口(API)和底层网络接口来支持增值服务能力的软件中间件层。ETSI M2M和oneM2M均使用可以包含本申请的连接方法的服务层。ETSI M2M的服务层称为服务能力层(SCL)。可以将SCL实现在M2M设备(在这种情况下，其称为设备SCL(DSCL))、网关(在这种情况下，其称为网关SCL(GSCL))、和/或网络节点(在这种情况下，其称为网络SCL(NSCL))内。OneM2M服务层支持一组公共服务功能(CSF)(即，服务能力)。将一个或者多个特定类型的CSF的集合的实例化称为公共服务实体(CSE)，可以将该公共服务实体托管在不同类型的网络节点(例如，基础结构节点、中间节点、专用应用节点)上。进一步地，可以将本申请的连接方法实现为使用面向服务架构(SOA)和/或面向资源架构(ROA)来访问服务(诸如，本申请的连接方法)的M2M网络的一部分。

在一些实施例中，M2M应用20和20’可以结合公开的系统和方法使用。M2M应用20和20’可以包括与UE或者网关交互的应用，并且还可以结合其它公开的系统和方法使用。

在一个实施例中，如图18B所示，逻辑实体(诸如，资源目录208和702、传感器(诸如，传感器202、204、和206)、客户端302、AE 602、CSE 604、606、和1504、NSE 608、数据库704和706、初始排名功能708、实时排名功能710、服务器801、IoT设备1402、IoT网关(或者服务器)1404、RD CSF 1502、请求者1602和1604)以及用于产生界面(诸如界面1702和1704)的逻辑实体可以托管在由M2M节点(诸如，M2M服务器、M2M网关、或者M2M设备)托管的M2M服务层实例内。例如，逻辑实体(诸如，资源目录208和702、传感器(诸如，传感器202、204、和206)、客户端302、AE 602、CSE 604、606、和1504、NSE 608、数据库704和706、初始排名功能708、实时排名功能710、服务器801、IoT设备1402、IoT网关(或者服务器)1404、RD CSF 1502、请求者1602和1604)以及用于产生界面(诸如界面1702和1704)的逻辑实体可以包括M2M服务层实例内的单独的服务能力或者作为在现有服务能力内的子功能。

M2M应用20和20’可以包括在各种行业(诸如，但不限于，运输、健康与保健、联网家庭、能源管理、资产追踪、以及安全和监督)中的应用。如上所述，跨越系统的设备、网关、服务器、和其它节点而运行的M2M服务层支持诸如例如，数据收集、设备管理、安全、开账单、定位追踪/地理围墙、设备/服务发现、和遗留系统集成的功能，并且将这些功能作为服务提供给M2M应用20和20’。

通常，服务层22和22’定义通过应用编程接口(API)和底层网络接口的集合来支持增值服务能力的软件中间件层。ETSI M2M和oneM2M架构均定义了服务层。ETSI M2M的服务层称为服务能力层(SCL)。可以将SCL实现在ETSI M2M架构的各种不同节点中。例如，可以将服务层的实例实现在M2M设备(在这种情况下，其称为设备SCL(DSCL))、网关(在这种情况下，其称为网关SCL(GSCL))、和/或网络节点(在这种情况下，其称为网络SCL(NSCL))内。oneM2M服务层支持公共服务功能(CSF)(即，服务能力)集合。将一个或者多个特定类型的CSF的集合的实例化称为公共服务实体(CSE)，可以将该公共服务实体托管在不同类型的网络节点(例如，基础结构节点、中间节点、专用应用节点)上。第三代合作伙伴计划(3GPP)还定义了用于机器类型通信(MTC)的架构。在该架构中，将服务层和其提供的服务能力实现为服务能力服务器(SCS)的一部分。不论是否体现在ETSI M2M架构的DSCL、GSCL、或者NSCL中、在3GPP MTC架构的服务能力服务器(SCS)中、在oneM2M架构的CSF或者CSE中、或者在网络的任何其它节点中，都可以将服务层的实例实现为或者在网络中的一个或者多个独立节点(包括服务器、计算机、和其它计算设备或者节点)上执行的、或者作为一个或者多个现有节点的一部分执行的逻辑实体(例如，软件、计算机可执行指令等)。作为示例，服务层或者其部件的实例可以被实现为在具有下文描述的图18C或者18D图示的通用架构的网络节点(例如，服务器、计算机、网关、设备等)上运行的软件的形式。

进一步地，可以将逻辑实体(诸如，资源目录208和702、传感器(诸如，传感器202、204、和206)、客户端302、AE 602、CSE 604、606、和1504、NSE 608、数据库704和706、初始排名功能708、实时排名功能710、服务器801、IoT设备1402、IoT网关(或者服务器)1404、RDCSF 1502、请求者1602和1604)以及用于产生界面(诸如界面1702和1704)的逻辑实体实现为使用面向服务架构(SOA)和/或面向资源架构(ROA)来访问本申请的服务的M2M网络的一部分。

图18C是M2M网络节点30(诸如，M2M设备18、M2M网关14、或M2M服务器等)的示例硬件/软件架构的框图。节点30可以执行或者包括逻辑实体(诸如，资源目录208和702、传感器(诸如，传感器202、204、和206)、客户端302、AE 602、CSE 604、606、和1504、NSE 608、数据库704和706、初始排名功能708、实时排名功能710、服务器801、IoT设备1402、IoT网关(或者服务器)1404、RD CSF 1502、请求者1602和1604)以及用于产生界面(诸如界面1702和1704)的逻辑实体。设备30可以是图18A至图18B示出的M2M网络的一部分或者非M2M网络的一部分。如图18C所示，M2M节点30可以包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、小键盘40、显示器、触摸板、和/或指示器42、电源48、全球定位系统(GPS)芯片集50、和其它外围设备52。节点30还可以包括通信电路系统，诸如收发机34和传输/接收元件36。要了解，M2M节点30可以在与实施例保持一致的同时包括前述元件的任何子组合。该节点可以是实现本文描述的SMSF功能性的节点。

处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心相关联的一个或者多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。通常，处理器32可以执行存储在节点的存储器(例如，存储器44和/或存储器46)中的计算机可执行指令，以便执行节点的各种要求的功能。例如，处理器32可以执行信号编码、数据处理、功率控制、输入/输出处理、和/或使M2M节点30能够在无线或者有线环境中操作的任何其它功能性。处理器32可以运行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或其它通信程序。处理器32还可以执行安全操作(诸如，认证、安全密钥协议、和/或加密操作)，诸如例如在接入层和/或应用层处。

如图18C所示，处理器32耦合至其通信电路系统(例如，收发机34和传输/接收元件36)。通过执行计算机可执行指令，处理器32可以控制通信电路系统，以使节点30经由其所连接的网络与其它节点通信。具体地，处理器32可以控制通信电路系统，以执行本文和权利要求书中描述的传输和接收步骤。尽管图18C将处理器32和收发机34描述为单独的部件，但是要了解，可以将处理器32和收发机34集成在电子封装或者芯片中。

传输/收发元件36可以配置为将信号传输至其它M2M节点，或者从其它M2M节点接收信号，所述其它M2M节点包括M2M服务器、网关、设备等。例如，在实施例中，传输/接收元件36可以是配置为传输和/或接收RF信号的天线。传输/接收元件36可以支持各种网络和无线接口，诸如，WLAN、WPAN、蜂窝等。例如，在实施例中，传输/接收元件36可以是配置为传输和/或接收IR、UV、或者可见光信号的发射机/检测器。在再一实施例中，传输/接收元件36可以配置为传输和接收RF和光信号两者。要了解传输/接收元件36可以配置为传输和/或接收无线或者有线信号的任何组合。

另外，尽管在图18C中将传输/接收元件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)的信息，并且将数据存储在该任何类型的合适的存储器中。例如，如上所述，处理器32可以将会话上下文存储在其存储器中。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘、或者任何其它类型的存储器存储设备。可移除存储器46可以包括用户识别模块(SIM)卡、记忆棒、安全数字(SD)存储器卡等。在其它实施例中，处理器32可以访问来自并未在物理上位于M2M节点30的存储器(诸如，在服务器或者家庭计算机上)的信息，或者将数据存储在该存储器中。处理器32可以配置为控制显示器或者指示器42上的照明模式、图像、或者颜色，以为了反映M2M服务层会话迁移或者共享的状态，或者为了获取来自用户的输入或者向用户显示关于所述节点的会话迁移或者共享能力或者设置的信息。在另一示例中，显示器可以示出针对会话状态的信息。当前公开在oneM2M实施例中定义了RESTful用户/应用API。可以在显示器上示出的图形用户界面可以层叠于API顶部，以允许用户经由本文描述的底层服务层会话功能交互地建立并且管理E2E会话或者其迁移或共享。

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

处理器32还可以耦合至配置为提供关于M2M节点30的当前定位的定位信息(例如，经度和纬度)的GPS芯片集50。要了解，M2M节点30可以在与实施例保持一致的同时通过任何合适的定位确定方法来获得定位信息。

处理器32可以进一步耦合至其它外围设备52，该外围设备52可以包括提供附加特征、功能性、和/或有线或者无线连接性的一个或者多个软件和/或硬件模块。例如，外围设备52可以包括加速度计、电子罗盘、卫星收发机、传感器、数码相机(针对照片或者视频)、通用串行总线(USB)端口、振动设备、电视收发机、免提耳机、

模块、调频(FM)无线电单元、数字音乐播放器、视频游戏机模块、互联网浏览器等。

图18D是还可以用于实现M2M网络的一个或者多个节点(诸如，M2M服务器、网关、设备、或者其它节点)的示例性计算系统90的框图。计算设备90可以包括计算机或者服务器并且可以主要由计算机可读指令控制，该计算机可读指令可以是软件的形式，所述软件可以在任何时间且以任何手段被存储或者访问。计算系统90可以执行或者包括逻辑实体(诸如，资源目录208和702、传感器(诸如，传感器202、204、和206)、客户端302、AE 602、CSE 604、606、和1504、NSE 608、数据库704和706、初始排名功能708、实时排名功能710、服务器801、IoT设备1402、IoT网关(或者服务器)1404、RD CSF 1502、请求者1602和1604)以及用于产生界面(诸如界面1702和1704)的逻辑实体。计算系统90可以是M2M设备、用户设备、网关、UM/GW或者包括例如移动护理网络的节点、服务层网络应用提供者、终端设备18、或者M2M网关设备14的任何其它节点。可以在处理器(诸如，中央处理单元(CPU)91)内执行这种计算机可读指令，以使计算系统工作。在许多已知的工作站、服务器、和个人计算机中，中央处理单元91由称作微处理器的单片机CPU来实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的、执行附加功能或者协助CPU 91的可选处理器。CPU 91和/或处理器81可以接收、生成、并且处理与所公开的针对E2E M2M服务层会话的系统和方法有关的数据，诸如，接收会话证书或者基于会话证书进行认证。

在操作中，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可以包含负责将指令从CPU 91传送到外围设备的外围设备控制器83，诸如，打印机94、键盘84、鼠标95、和磁盘驱动器85。

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

进一步地，计算系统90可以包括通信电路系统(诸如例如，网络适配器97)，所述通信电路系统可以用于将计算系统90连接至外部通信网络(诸如，图18A和图18B的网络12)，以使计算系统90与网络的其它节点通信。

要理解本文描述的任何或者所有系统、方法、和过程可以体现为存储在计算机可读存储介质上的计算机可执行指令(即，程序代码)的形式，所述指令在由机器(诸如M2M网络的节点，包括例如，M2M服务器、网关、设备等)执行时，执行和/或实现本文描述的系统、方法、和过程。具体地，上文描述的任何步骤、操作、或者功能(包括网关、UE、UE/GW、或者移动核心网络、服务层、或者网络应用提供商的任何节点的操作)可以按照这种计算机可执行指令的形式来实现。逻辑实体(诸如，资源目录208和702、传感器(诸如，传感器202、204、和206)、客户端302、AE 602、CSE 604、606、和1504、NSE 608、数据库704和706、初始排名功能708、实时排名功能710、服务器801、IoT设备1402、IoT网关(或者服务器)1404、RD CSF1502、请求者1602和1604)以及用于产生界面(诸如界面1702和1704)的逻辑实体可以体现为存储在计算机可读存储介质上的计算机可执行指令的形式。计算机可读存储介质包括实现在用于存储信息的非暂时性(即，有形的或者物理的)方法或者技术中的易失性和非易失性介质以及可移除和不可移除介质，但是这种计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于，RAM、ROM、EEPROM、闪速存储器或者其它存储器技术、CD-ROM、数字多功能光盘(DVD)或者其它光盘存储、磁带盒、磁带、磁盘存储或者其它磁性存储设备、或者可以用于存储期望的信息并且可以由计算机访问的任何其它有形的或者物理的介质。

在本公开的主题的优选实施例的描述中，如图所示，为了清楚起见采用了特定的术语。然而，所要求的主题不旨在限于所选择的特定术语，并且要理解，每一个特定元件包括以相似的方式操作以完成相似的目标的技术等效物。

该书面描述使用示例(包括最佳模式)来公开本发明，并且还使本领域的任何技术人员能够实践本发明(包括制作并且使用任何设备或者系统，并且执行任何并入的方法)。本发明的专利范围由权利要求书定义，并且可以包括本领域的技术人员能想到的其它示例。如果这些示例具有与权利要求书的文字语言并无不同的元件，或者如果这些示例包括与权利要求书的文字语言无实质性差异的等效元件，那么这种其它示例旨在落入权利要求书的范围内。

Claims (18)

1.一种在包括资源目录和多个物联网IoT服务器的IoT网络中使用的方法，在所述资源目录处执行所述方法，所述方法包括：

登记从所述多个IoT服务器接收的多个统一资源标识符URI；

基于测量在所述多个URI中的每一个之间的交叉链路，来确定所述多个URI的初始排名；

基于所述初始排名来生成排名数据库；

从客户端接收搜索查询；

基于所述搜索查询，为在所述排名数据库中的所述多个URI确定实时排名；以及

基于所述实时排名，生成所述多个URI的排名列表，

其中，基于检查所述多个IoT服务器中的每一个的睡眠状态和/或基于部分地平衡所述多个IoT服务器的流量负载来确定所述多个URI的所述实时排名。

2.根据权利要求1所述的方法，其中，测量在所述多个URI中的每一个之间的交叉链路进一步包括：

计算所述多个URI中的每一个被另一个交叉链接到的次数；

针对所述多个URI中的每一个，将所述次数映射到预定排名范围中；以及

基于所述映射，为所述多个URI确定交叉链路排名，所述交叉链路排名指示所述次数。

3.根据权利要求2所述的方法，其中，为所述多个URI确定交叉链路排名进一步包括：

在所述多个URI中确定第一URI，所述第一URI被交叉链接到的次数比所述多个URI中的第二URI更多；以及

将所述第一URI排名为高于所述第二URI。

4.根据权利要求1所述的方法，其中，基于识别所述多个URI的上下文来进一步确定所述多个URI的所述初始排名。

5.根据权利要求4所述的方法，其中，所述多个URI的所述上下文包括：资源类型、域、地理定位、组播、以及单播。

6.根据权利要求5所述的方法，其中，识别所述多个URI的上下文进一步包括：

基于所述上下文从所述多个URI选择一组URI；

将所述一组URI排名为高于所述多个URI中的未选择的URI组；以及

基于所述排名来确定所述多个URI的上下文排名。

7.根据权利要求6所述的方法，其中，基于逻辑域来选择所述一组URI。

8.根据权利要求6所述的方法，其中，基于所述资源类型来选择所述一组URI。

9.根据权利要求6所述的方法，其中，基于所述地理定位来选择所述一组URI。

10.根据权利要求6所述的方法，其中，基于组播组来选择所述一组URI。

11.根据权利要求1所述的方法，其中，所述搜索查询包括：资源类型、域、排名范围、以及睡眠状态指示器。

12.根据权利要求1所述的方法，其中，检查所述多个IoT服务器中的每一个的睡眠状态进一步包括：

将所述多个URI中的每一个的睡眠状态与从所述多个IoT服务器接收的睡眠调度进行比较；以及

基于比较睡眠状态，来确定所述多个URI的睡眠状态排名。

13.根据权利要求12所述的方法，其中，确定所述睡眠状态排名进一步包括：

如果在所述多个URI中的URI正睡眠，那么将所述URI排名为低于所述多个URI中的清醒的另一个URI。

14.根据权利要求12所述的方法，其中，确定所述睡眠状态排名进一步包括：

如果所述多个URI中的URI正睡眠，那么在所述排名列表中移除所述URI。

15.根据权利要求1所述的方法，其中，部分地平衡所述多个IoT服务器的流量负载进一步包括：

在所述多个URI中确定第一URI，所述第一URI已预定次数地被排名为比所述多个URI中的第二URI高；

将所述第一URI排名为低于所述第二URI；以及

基于所述排名，生成所述多个URI的准负载平衡排名。

16.根据权利要求1所述的方法，其中，部分地平衡所述多个IoT服务器的流量负载进一步包括：

在所述多个URI中确定第一URI，所述第一URI已经被检测为具有比所述多个URI中的第二URI高的流量负载；

将所述第一URI排名为低于所述第二URI；以及

基于所述排名，生成所述多个URI的准负载平衡排名。

17.根据权利要求1所述的方法，其中，基于交叉链路排名、上下文排名、睡眠状态排名、和准负载平衡排名的加权平均来生成所述排名数据库。

18.一种在包括资源目录和多个物联网IoT服务器的IoT网络中的系统，所述系统包括：

处理器；以及

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

登记从所述多个IoT服务器接收的多个统一资源标识符URI；

基于测量在所述多个URI中的每一个之间的交叉链路，来确定所述多个URI的初始排名；

基于所述初始排名，来生成排名数据库；

从客户端接收搜索查询；

基于所述搜索查询，为在所述排名数据库中的所述多个URI确定实时排名；以及

基于所述实时排名，生成所述多个URI的排名列表，

其中，基于检查所述多个IoT服务器中的每一个的睡眠状态和/或基于部分地平衡所述多个IoT服务器的流量负载来确定所述多个URI的所述实时排名。

Images