CN107852430B - 用于在局域网中形成网关的设备以及计算机可读存储介质 - Google Patents

Abstract

基于云的DNS‑SD架构可以将单独LAN链接在一起以从服务发现角度形成虚拟发现区域，包括与规则因特网DNS分离的基于云的DNS‑SD服务器，以及休眠节点处理等等。在实例中，基于云的DNS‑SD服务器与规则因特网DNS服务器分离。此云DNS‑SD服务器可以运行为专门用于虚拟发现区域中的服务发现的私有基础架构即服务(IaaS)。

Description

用于在局域网中形成网关的设备以及计算机可读存储介质

相关申请案的交叉参考

本申请案要求2015年7月6日提交的标题为“物联网的广域服务发现(Wide AreaService Discovery For Internet Of Things)”的第62/188,781号美国临时专利申请案的权益，该申请的内容在此以引用方式并入本文中。

背景技术

域名系统

域名系统(DNS)是关于连接到因特网的装置(还称为主机)的信息的分布式数据库。具体来说，DNS包含用于在人类可读名称(用作助记装置)与IP地址(用于因特网路由中)之间映射的信息：

·实例1：网站名称www.google.com映射到IP地址“74.125.224.72”

·实例2：电子邮箱地址john.smith@bestcompany.com映射到IP地址“208.49.79.242”

此信息存储在称为DNS资源记录(RR)的DNS数据库条目中。DNS服务器通过提供存储在DNS记录中的关于因特网连接装置(主机)的信息来响应客户端查询。最常见的查询是将名称转换为IP地址。此功能被称为DNS名称解析。从技术上讲，被解析的名称被称为FQDN。还存在本文将论述的其它类型的可能DNS查询。

DNS的半手动方案最初起作用，但是当连接到因特网的主机数目开始以指数方式增长时，该方案没有很好地扩展。随后进行调查以确定产生定义DNS的一系列重要IETF标准的更加自动和可扩展解决方案。参看以引用方式全文并入的RFC 1034和RFC 1035。

DNS如今是遍布全球许多计算机服务器的分布式数据库。数据库围绕域名的概念进行组织(例如，“.com”是域名的一部分，并且www.bestcompany.com是FQDN)。每个域名本质上是大的倒置树中的路径，称为域名空间(参看图1)。域是整个空间的子树。树结构的顶部具有单个(逻辑)根。树的深度限制为127层。树中的每个节点具有可以长达63字符的文本标签名。域名总是从叶节点朝向根读取，域名具有分隔路径中的名称的点。因此，例如对于FQDN“www.bestcompany.com”，“.com“将处于树的顶部并且称为顶级域名(TLD)。随后，“.bestcompany”将紧接在树下方，并且“www”将处于树的底叶处。

如先前所述，DNS数据库条目以称为RR的格式存储。RR通过域或特定域名(FQDN)组织。FQDN最终与物理网络装置相关联，而域(例如，“.com”)用于识别一组装置。存在通过与其包含的装置有关的信息类型分类的各种类型的RR。表1中列出一些示例性DNS RR。

表1：DNS资源记录(RR)的类型

DNS查询和响应通常直接通过端口53上的UDP包发送。TCP传输选项也存在，但不是用于通常相当短的事务的DNS查询/响应的所推荐选项。DNS定义具有如图2所示的三个组成部分的单个消息格式。

三个组成部分是报头部分105、问题部分107和回答部分109。关于标题部分105，存在固定的十二字节报头，报头具有描述消息的类型以及各个部分的大小的字段。问题部分107包含对发送到DNS名称服务器的信息的一个或多个查询。回答部分109包含三个子组成部分中的一个或多个RR作为对问题部分107中的查询/问题的回答，例如，回答111、授权112和附加113。回答111是直接回答问题的RR。授权112是指向可以用于继续解析过程的授权DNS名称服务器的RR。附加113是包含回答原始问题非严格必需的与查询相关的附加信息的RR。

图3说明通过用户执行网页浏览发起的DNS查找的典型消息序列图。在步骤121处，笔记本电脑130的用户想要阅读最新的谷歌商业新闻。此信息通过与笔记本电脑130的浏览器131相关联的用户界面输入。浏览器131随后认识到其需要获得“google.com”的IP地址。因此，浏览器131用此请求联系笔记本电脑130中的DNS客户端132。在步骤122处，在DNS客户端131获得请求之后，DNS客户端形成具有FQDN＝“google.com”的DNS消息查询。此查询通过因特网120发送到默认DNS服务器133。DNS服务器133的IP地址可以直接可用于DNS客户端132中。DNS服务器133的IP地址可能被预先提供在笔记本电脑中，或通过例如DHCP的协议在笔记本电脑开机过程中被检索到。

在步骤123处，DNS服务器133对步骤122的所检索查询进行行内部查找，并且确定“.com”域的服务器是DNS服务器134。因此，将DNS消息(包含RR)发送回DNS客户端132，以通知DNS客户端其应执行递归搜索并且使用相同查询联系DNS服务器134。在步骤124处，DNS客户端将具有步骤122的类似信息的DNS消息发送到DNS服务器134。在此实例中，DNS服务器134是授权域服务器，因此不需要进一步递归。在步骤125处，DNS服务器125将发送包含“A”RR的具有对步骤124的响应的DNS消息，所述“A”RR包含所请求“google.com”服务器的IP地址(74.125.224.72)。在步骤126处，DNS客户端132将“google.com”IP地址从DNS消息发送到浏览器131。在步骤127处，浏览器131将HTTP获取请求直接发送到“google.com”IP地址(74.125.224.72)，以检索其想要的内容，内容可以是最新商业新闻。在步骤128处，“google.com”服务器用具有合适的最新商业新闻内容的HTTP响应来进行响应。

DNS-SD

DNS服务发现(DNS-SD)是近年来添加到DNS中的相对新的功能。DNS-SD是指使用DNS来发现除了通常的名称解析功能之外的基于可用本地网络IP的服务。例如，查询本地网络中可以通过TP访问的可用打印机的DNS-SD。具体来说，给定客户端正查找的服务类型(例如，打印)，此机制允许客户端使用标准DNS查询发现给定域中的所需服务的装置(命名情况)的本地列表。对于IETF标准化解决方案的商业前体是通过苹果计算机公司进行的，并且被称为“AppleTalk”(有时也称为“Bonjour”)。参看以引用方式全文并入的RFC 676。

在IETF中，通过三条信息的组合识别IP“服务”，信息包括服务名称(例如，FTP、HTTP)、传输协议(例如，UDP、TCP)和传输协议的端口号。已知的因特网IP服务的广泛注册通过IETF在服务名称和传输协议端口号注册表中维持。查看以引用方式全文并入的http://www.iana.org/assignments/service-names-port-numbers/service-nam es-port-numbers.xhtml。

从技术上讲，DNS-SD由两个功能组成。第一功能被称为多播DNS(mDNS)。通过利用本地IP多播功能，mDNS能够在没有任何常规单播DNS服务器的情况下执行本地网络DNS操作。因此，装置可以本身直接回答本地IP多播DNS查询，而不需要专门的DNS服务器来响应查询(例如，打印机将直接回答查找打印服务的多播DNS查询)。mDNS还允许装置使用本地链路多播来预先通知其所支持/改变的服务。另外，mDNS指定DNS名称空间的一部分免费供本地使用(例如，新的“.local”域)，而不需要支付任何年费，也不需要设定授权或以其它方式配置常规DNS服务器来回答这些名字。参看以引用方式全文并入的RFC 6762。

第二功能本身(有点易混淆)被称为DNS-SD。第二功能在RFC6763(以引用方式全文并入)中进行描述并且指定用于支持服务发现查询的DNS记录结构内所需的改变(例如，配置DNS以比传统名称解析查询支持更多功能)。第二功能还可以通过单纯的单播模式用于查询给定域的特定服务。然而，此单播模式现在不用作通用服务发现功能。

当用于网络中的动态多播服务发现的场境中时，DNS-SD和mDNS的组合通常仅称为“DNS-SD”。服务的发现按需要直接通过客户端发送多播查询以及从支持基于所请求IP的服务的装置接收(单播)响应来完成。此服务发现适用于本地网络(例如，不能跨越多个LAN动态地发现服务)。

图4说明典型的DNS-SD消息流。在步骤141处，用户想要从文字处理器136打印彩色文档。文字处理器136认识到其需要获得彩色打印机(例如，彩色打印机139)的IP地址。因此，文字处理器136通过此请求将消息发送到笔记本电脑130中的DNS客户端132。在步骤142处，在DNS客户端132获得请求之后，DNS客户端确定其应形成指示DNS客户端正查找“彩色打印机”的DNS-SD(多播)消息查询。IP多播通过笔记本电脑130所连接的LAN 140发送此查询。IP多播机制将自动地将DNS-SD查询分配到连接到LAN 140的所有装置(消息不应超出LAN140)。与标准DNS查询(通过UDP端53发送)不同，多播DNS-SD查询通过UDP端5353发送。而且，多播DNS-SD域被指定为具有以“.local”后缀结束的FQDN，例如“ColorPrinter.local”。

在步骤143处，LAN 140中的多个装置接收DNS-SD多播查询，但是此处，仅彩色打印机139具有匹配服务类型。彩色打印机139发送DNS-SD消息(单播)响应，包括所请求服务服务器的IP地址(例如，192.168.0.11)。在步骤144处，笔记本电脑130的DNS客户端132将彩色打印机139的IP地址发送到文字处理器136。在步骤145处，文字处理器136将HTTP Post请求直接发送到彩色打印机139的IP地址以请求打印附件。在步骤146处，彩色打印机139用成功HTTP响应代码(201)进行响应以指示成功地打印附件。

如先前所述，DNS-SD主要用于发现本地网络中的基于IP的服务。DNS-SD使用三个标准DNS RR的组合来识别服务，通常包括指针记录(PTR)、服务定位器记录(SRV)和文字记录(TXT)。DNS-SD搜索涉及客户端发送DNS查询，DNS查询在搜索参数中指定用于查找在给定域的PTR记录中的具体服务类型。DNS-SD服务器随后返回一组零个或多个SRV/TXT对，SRV/TXT对提供目标装置(主机)名称和可以到达服务实例的端口(在SRV RR中)，以及辅助信息(在TXT RR中)。随后可以从相关联“A”或“AAA”记录中获得目标装置的IP地址。

混合DNS-SD代理

最新起草的基于混合单播/多播DNS服务发现提出利用混合代理来允许基于IP的服务的选择性广域发现。参看以引用方式全文并入的http://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00。具体来说，草案提出将使用mDNS来发现本地网络中的DNS-SD服务，聚合响应，并且在不同LAN中回答请求客户端的代理。这也将要求对DNS中的命名系统进行重要改变(这是相当有争议的，并且尚未在IETF中达成一致)。当前，DNS域名最终与如先前所描述的给定装置相关联。如果基于混合单播/多播DNS的服务草案被批准，则将允许LAN(例如，本地链路)，而不是个别装置也进行命名(例如，“4thFloor.Building1.companyX.com”)，使得可以查询搜索给定服务。

图5说明混合DNS-SD代理场景的示例性流。在步骤151处，需要将查询发送到特定“命名”LAN(例如，BestCompany的第三层)以搜索彩色打印机。在步骤152至154处，标准(单播)DNS查询机制将导致查询被转发到给定LAN 140(例如，BestCompany的第三层)的DNS-SD代理150。在步骤155至156处，DNS-SD代理150触发mDNS请求。LAN 140中的装置接收DNS-SD多播查询，但是将仅回答具有(彩色打印机的)匹配服务类型的彩色打印机139。彩色打印机139发送DNS-SD消息(单播)响应，包括所请求服务服务器的IP地址。在步骤157至158处，将具有IP地址的DNS响应转播回文字处理器136。在步骤159处，文字处理器136随后将HTTPPost请求直接发送到彩色打印机139的IP地址以请求打印附件。

DNS-SD目前可以发现和通知本地网络中的基于IP的服务(例如，打印机、传真等)，但需要一种跨越LAN工作的系统。

发明内容

本文公开一种基于云的DNS-SD架构，所述架构将单独LAN链接在一起以从服务发现角度形成虚拟发现区域，包括与规则因特网DNS分离的基于云的DNS-SD服务器，以及休眠节点处理等等。在实例中，基于云的DNS-SD服务器与规则因特网DNS服务器分离。此云DNS-SD服务器可以运行为专门用于虚拟发现区域中的服务发现的私有基础架构即服务(IaaS)。

IoT装置和IoT网关处理DNS-SD查询和响应(例如，用于休眠节点处理)，并且还区分其它类型的DNS查询(例如，标准DNS名称解析查询)。程序定义和配置虚拟发现区域和控制节点(例如，DSN-SD服务器、IoT网关)。在实例中，可以通过各个控制节点处的OAM程序来进行配置。在另一实例中，可以基于控制节点之间的信令通过动态网络自配置方法来进行配置。用户界面可以生动地显示虚拟发现区域。

方法、系统、计算机可读存储媒体或设备具有用于从第一LAN接收服务的DNS-SD查询；以及响应于接收DNS-SD查询，提供关于所述服务的信息的构件，所述服务处于第二LAN上。

方法、系统、计算机可读存储媒体或设备具有用于将请求提供到服务；以及接收对所述请求的响应的构件，所述响应包括关于与所述服务相关联的装置的休眠节点信息。

提供本概述以便用简化形式介绍将在以下详细描述中进一步描述的概念选择。本概述并非旨在标识所要求主题的关键特征或基本特征，也不旨在用于限制所要求主题的范围。此外，所主张的主题不限于解决本发明的任何部分中所提及的任何或所有缺点的限制。

附图说明

可以从结合附图借助于实例提供的以下描述中得到更详细理解，其中：

图1说明示例性DNS数据库结构；

图2说明具有三个组成部分的示例性单个消息DNS格式；

图3说明通过用户执行网页浏览发起的DNS查找的示例性消息序列图；

图4说明示例性DNS-SD消息流；

图5说明混合DNS-SD代理场景的示例性流；

图6说明示例性广域服务发现系统；

图7说明用于打印机在虚拟发现区域中的发现的示例性流；

图8说明可以用于系统启动的示例性方法；

图9说明用于系统操作的示例性方法；

图10说明自配置虚拟发现区域的示例性阶段；

图11说明自配置虚拟发现区域的另一示例性阶段；

图12说明可以并入休眠节点处理的示例性广域服务发现实施方案；

图13说明用于使用DNS RR处理休眠节点场景的示例性流；

图14说明与广域服务发现相关联的示例性用户界面；

图15A是可以实施所公开主题的示例性机器对机器(M2M)或物联网(IoT)通信系统的系统图；

图15B是可以在图15A中所说明的通信系统内使用的实例M2M/IoT终端或网关装置的系统图；

图15C是其中可以体现图15A的通信系统的各方面的实例计算系统的框图；以及

图15D说明可以在图15A中所说明的M2M/IoT通信系统内使用的示例性架构。

具体实施方式

本文公开一种超越IoT场景的本地网络工作的DNS服务发现(DNS-SD)。DNS-SD目前可以发现和通知本地网络中的基于IP的服务(例如，打印机、传真等)，但并不跨越LAN工作。然而，在许多IoT场景中，这是不够的。服务名称的实例将是“温度传感器”或“灯开关”或“门锁”。而且，本文关于RFC 7252中所述的传输协议(例如，使用CoAP的用于IoT服务的UDP)和端口号(例如，默认UDP CoAP端口是5683)论述其它服务。

下文论述常规DNS-SD技术的一些约束或限制。常规DNS-SD支持直接查询DNS服务器以搜索服务(例如，不需要mDNS)的严格单播方法，并且可以跨越LAN工作。然而，由于多种原因，这种单播方法不被视为通用服务发现方法。第一原因处理与搜索给定服务的客户端可以如何确定搜索哪个域相关联的问题。对于单播，需要知道搜索哪个域。搜索许多或所有域的强力方法会导致太多信号传递，更重要的是可能会导致显著延迟发现服务。如果服务未在此处注册，则搜索“当前”域的简单方法可能导致错过机会。

第二原因处理与装置可以如何通过关于其所支持服务的信息自动地更新DNS服务器相关联的问题。DNS RR的更新需要客户端与其正更新的DNS服务器之间具有相当复杂的安全关联。这种强安全关联通常不适用于简单的现成装置，例如打印机、IoT装置等，因为装置可能需要例如手动地配置安全证书。在许多情况下，由于服务和装置的规模以及预期动态性质，操作员手动地将所有此信息输入到DNS服务器中并不实际。

常规DNS-SD支持用于查询服务器的mDNS方法。与常规DNS-SD相关联的mDNS可以被认为在本地链路内很好地为服务发现工作，但是被明确地限制为不在本地链路之外工作。此限制的原因是mDNS功能通过IETF仅分配用于本地链路IP多播地址(参看RFC 6763的第22章)。通常，超越LAN的用于服务发现的多播预期会在许多场景下导致严重的网络拥塞，因此被IETF明确禁止。如本文所论述，本地链路通常等同于LAN或LAN的子部分。链路通常是具有连接到其的多个装置的共享传输媒体，例如，以太网或WiFi。链路通常转换成单个层2(广播)域(但可以通过桥接器等L2装置扩展)。本地链路通常不需要用于中继转发包的层3IP路由器。在此文档中，为了简单起见，术语“LAN”或“本地网络”与术语“本地链路”可互换地使用。

IoT是旨在描述当前主要专用M2M系统发展到可以使用标准化协议完全集成到整个因特网中的术语。本文公开一种使用DNS-SD，使得DNS-SD超越IoT场景的本地网络工作的方法(广域服务发现)。在需要超越本地网络的发现的许多IoT场景中，当前DNS-SD是不够的。例如，如果智能电网(例如，联网的电力公司)运营商在城市中部署IoT装置，则运营商想要跨越其整个部署(例如，跨越多个LAN)的共同服务发现，这是至今无法满足的需求。

标题为“可扩展DNS SD的扩展-WG章程(Extensions for Scalable DNS SD–Charter for WG)”的IETF文档明确指出此问题，提到“DNS-SD/mDNS协议组用于许多场景，包括家庭、校园和企业网络。然而，零配置mDNS协议由设计限制到链路本地的多播范围，因此无法用于发现远程链路上的服务”。参看以引用方式全文并入的http://datatracker.ietf.org/wg/dnssd/charter。

尝试解决上述问题的混合DNS-SD代理具有缺点，包括按需要发起频繁的mDNS多播业务。对于IoT环境，频繁多播无法很好地扩展，因为要到达更多装置或更多网络，这会导致更高的开销业务。而且，许多IoT装置可能通常处于休眠状态，因此可能错过许多多播DNS-SD查询。而且，混合DNS-SD代理不利用针对IoT部署优化的IoT特定架构(例如，RD)和IoT特定协议(例如，CoAP)，因此与这些IoT特定节点和协议相比，导致更高开销和低效率。

因此，可以显著改变常规DNS-SD服务发现方法以支持更有效的机制，该机制实现跨越彼此具有某种逻辑关系的多个LAN的服务发现(DNS-SD)(例如，在一些限制内的广域服务发现)。

本文所论述的广域服务发现可以利用资源目录(RD)。(RD)是托管在IoT环境的其它服务器上保持的资源的描述(例如，URI)的服务器。参看以引用方式全文并入的CoRE资源目录http://tools.ietf.org/html/draft-ietf-core-resource-directory-02(此处在CoRE资源目录之后)。资源目录允许对那些资源执行集中化查找。假定正常的谷歌类型网络搜索将无法在IoT环境中有效地工作。相反，RD支持RESTful CoAP接口，以允许装置注册其资源以及相关元数据。而且，可以存储装置的资源之间的关系。单独RESTful接口允许第三方客户端搜索RD，以找到(发现)满足其给定搜索标准的资源。在RD向第三方客户端提供搜索结果之后，第三方客户端可以直接地进入资源(URI)。

CoRE资源目录定义了RD字段和常规DNS-SD字段的简单映射，映射允许通过任何方式发现CoAP服务。具体来说，CoRE资源目录提出特定客户端首先可以从RD执行CoAP服务的标准RD查找。客户端随后可以接受响应，并且在常规DNS-SD中进行信息的单播注册。如上所述，这需要能够与DNS基础架构建立复杂安全关联的客户端。因此，客户端不可能是简单的IoT装置，但很可能是专用管理配置客户端。

图6说明示例性广域服务发现系统160。LAN 170、LAN 175和LAN 180分别包括网关171、网关176和网关181。每个LAN，例如LAN170可以包括与网关(例如，网关171)在本地以通信方式连接的IoT装置(例如，IoT装置172)，以及与因特网162以通信方式连接的网关。广域服务发现系统160中的网关，例如网关171可以支持CoAP RD或类似功能性。因特网162与DNS服务器161和IoT服务云166以通信方式连接。IoT服务云166可以包括大数据分析163、存储装置164和IoT DNS-SD服务器165，以及其它服务。在系统160的各个LAN中的IoT装置可以具有所有者或运营商(例如，公司、公用事业公司等)，所有者或运营商可以在由第三方IoT装置服务发现服务器(例如，IoT DNS-SD服务器165)管理的虚拟发现过程中合作。标准DNS名称解析仍可以通过因特网162的现有(“规则的”)DNS基础架构完成。LAN 170和LAN 180处于同一虚拟发现区域167内。

如本文中更详细地论述，DNS-SD查询可以在两步骤过程中完成。首先，尝试发现本地处于同一LAN内的服务。如果不成功，则可以将查询路由到IoT DNS-SD服务器165。此基于云的IoT DNS-SD服务器165可以对虚拟发现区域167中的IoT装置的服务发现查询作出响应。

如本文所论述，广域服务发现系统160启用建立在LAN之外的虚拟发现区域。在此实例中，LAN 170和LAN 180是一起连接到虚拟发现区域167中的两个物理上分离的(非连续的)LAN。在虚拟发现区域167中，可以在整个区域中的所有装置上启用服务发现。区域可以具有任意大小并且根据需要涵盖尽可能多的LAN。而且，图6中仅示出一个虚拟发现区域167，但是可以(并且通常将)存在所定义的多个虚拟发现区域。例如，尽管未示出，但是LAN175和LAN 180可以处于单独的虚拟发现区域中。

继续参考图6，服务未暴露用于给定IoT虚拟发现区域167之外的发现。虚拟发现区域可以重叠以及不重叠。因此，作为两个重叠区域的一部分的服务在那些区域中的每个区域中可发现。在另一实例中，给定虚拟发现区域可以涵盖多个传统mDNS域。传统mDNS域是单个子网或LAN。给定虚拟发现区域通常将涵盖多个LAN。

应理解，执行图7、图10、图11至图13以及其它图中所说明的步骤的实体可以是逻辑实体，逻辑实体可以用存储在装置、服务器或计算机系统(例如，图15C中所说明的那些)的存储器中以及在所述装置、服务器或计算机系统的处理器上执行的软件(例如，计算机可执行指令)形式实施。也就是说，图7、图10、图11至图13以及其它图中所说明的方法可以用存储在计算装置，例如图15C中所说明的装置或计算机系统的存储器中的软件(例如，计算机可执行指令)形式实施，当由计算装置的处理器执行时，所述计算机可执行指令执行图7、图10、图11至图13以及其它图中所说明的步骤。在实例中，下文关于M2M装置的交互进一步详细描述，图10的装置172可以驻留在图15A的M2M终端装置18上，而图10的IoT DNS-SD服务器165可以驻留在图15A的M2M网关装置14上。

图7说明用于打印机在虚拟发现区域中的发现的示例性流。在步骤191处，将DNS-SD查询从IoT装置182发送到网关181。IoT装置182可以是位于机动车中的计算装置。步骤191的查询可以是使用家庭办公室彩色打印机(例如，IoT装置172)的请求。在步骤192处，网关181搜索LAN 180并且未找到所请求服务。在步骤193处，网关181基于步骤192的结果确定其应查询IoT DNS-SD服务器165。网关181可以包括CoAP RD。在步骤194处，网关181将查询发送到IoT DNS-SD服务器165。查询本质上可以反映步骤191的查询。在步骤194的此查询中，可以请求IoT装置172(例如，家庭办公室处的彩色打印机)的位置。在步骤195处，IoTDNS-SD服务器165可以确定家庭办公室彩色打印机(IoT装置172)向IoT DNS-SD服务器165注册。在步骤196处，网关181接收DNS-SD响应，DNS-SD响应可以包括IoT装置172的IP地址或指示IoT装置172的可用性的信息。在网关181处接收到的IP地址可以是公共唯一IP地址。网关181可以通过网络地址转换(NAT)将公共IP地址转换成私有IP地址。可以使用常规NAT原理稍后请求(例如，步骤198)私有IP地址，以便启用装置之间的IP通信。预期其它常规IP通信场景。在步骤197处，网关181将在步骤196处接收到的IP地址发送到IoT装置182。在步骤198处，IoT装置182向IoT装置172数据发送打印所请求文档的请求。步骤198的请求可以是包括附件的CoAP POST请求。

图7的流可以与以下使用案例有关。汽车驾驶员晚上下班回家。她记得回家时需要查看重要的预算电子表格。驾驶员随后通过语音命令指示汽车计算机将文档从其电子邮件打印到“家庭办公室彩色打印机”。汽车计算机随后对“家庭办公室彩色打印机”发出标准DNS-SD发现查询。在汽车所连接到的LAN中未发现此打印机。(参看图7的191)。查询随后由汽车IoT网关通过蜂窝连接转发到IoT云DNS-SD服务器，因为汽车知道云DNS-SD服务器将知道连接到其虚拟发现区域的所有其它装置。(参看图7的步骤194)。在云DNS-SD服务器中，先前已注册家庭办公室彩色打印机，所以云DNS-SD服务器通过发送打印机的所需信息(包括IP地址)来成功地回答查询。(参看图7的步骤196和197)。汽车计算机随后立即将请求直接发送到家庭打印机以打印电子表格。(参看图7的步骤198)。

继续参考图7的论述，可以支持具有用于IoT装置172(例如，打印机)的私有地址的中间解决方案。在此情况下，将发现用于打印机的IP地址实际上被分配给家庭网关(网关171)并且向云服务器(IoT DNS-SD服务器165)注册。网关171(或类似装置)随后将从汽车接收打印请求(在步骤198处)，并且将所述打印请求转换成本地分配给打印机的内部(私有)IP地址。这利用网络地址转换(NAT)方法。例如，网关171可以知道该映射。其它装置可以认为网关171提供服务。

图7的使用案例将无法使用特别用于简单装置的常规DNS-SD技术有效地完成。例如家庭打印机的简单装置很少被输入到公共因特网DNS记录中，这是因为费用、房主的复杂性以及安全风险等。混合DNS-SD代理方法也是困难的，因为如果汽车驾驶员恰好指定“任何打印机”而不是“家庭打印机”，则从移动的汽车查询哪个DNS-SD代理将不是很明显。对于虚拟发现区域，域是整个区域。这意味着根据我们在图9中的解释，从当前LAN开始在整个区域内进行搜索。

图8说明可以用于系统启动的示例性方法200。在步骤201处，如上所述配置DNS-SD服务器。这可以由虚拟发现区域的所有者或运营商发起。虚拟发现区域可以与IoT本地网络相关联。例如，组合的图6的LAN 170和LAN 180可以是虚拟发现区域(例如，同一所有者或运营商)。在另一实例中，LAN 180和LAN 170可以形成虚拟发现区域，因为一组合作所有者(或运营商)相互信任并且想要共享IoT服务。合作的原因可能是因为业务关系。例如，所有者可以是房主、企业主或公共事业公司。云DNS-SD服务器本身可以在类似于Amazon^TM或Google^TM的云服务器提供商上运行。在实例中，云DNS-SD可以作为IaaS提供用于面向IoT消费者的云提供商。

在步骤202处，虚拟发现区域可以由IoT网络的运营商或所有者定义。这可以通过定义云DNS-SD服务器与网关组之间的关联来实现。例如，参考图6，虚拟发现区域1(未示出)＝{IoT DNS-SD服务器165、网关171和网关176}；并且虚拟发现区域2(例如，虚拟发现区域167)＝{IoT DNS-SD服务器165、网关171和网关181}。虚拟区域的定义可以通过用于IoT网络的常规OAM接口(例如，SNMP)来配置或编程。总之，通过OAM接口，DNS-SD服务器165和相关网关具有所定义的虚拟发现区域关系。在不同运营商之间的全面合作关系的情况下，每个节点可以由其相应的运营商配置。本文所论述的节点表示任何给定方框(例如，网关、装置、DNS服务器等)。作为此配置过程的一部分，网关(例如，网关171)可以被提供有云DNS-SD服务器(例如，DNS-SD服务器165)主机名和访问或写入云DNS-SD服务器所需的任何安全证书。应注意，由于DNS-SD服务器165在云中，因此DNS-SD服务器不必驻留在单个物理节点中。标准云功能可以按需要，例如用于负载平衡目的，分布DNS-SD服务器。这可以对网关(例如，网关171)和IoT装置(例如，IoT装置172)透明地完成。

在步骤203处，填充每个LAN段中的CoAP RD(其可以是网关的一部分)。LAN中的装置向RD注册它们的URI。参看以引用方式全文并入的RFC 6690中所论述的链路格式消息。URI和相关联信息随后可以通过如在CoRE资源目录的章节9中所论述的RD映射到其相关联DNS-SD RR格式中。应注意，RD可以存储关于基于HTTP和CoAP的服务的信息。

在步骤204处，每个网关(例如，网关171)将决定其想要将哪个DNS-SD记录导出到云DNS-SD服务器(例如，IoT DNS-SD服务器165)。在CoAP RD记录稳定(例如，在阈值时段内没有新的RD更新)之后，就可能发生前面的判定(sentence)。如果网关171的RD较小(例如，包含相对少量的记录)，则为了简单起见，网关171的RD可以决定将所有其记录导出到IoTDNS-SD服务器165。如果网关171的RD包含相对大量信息，则导出所有记录可能是低效的。在这种情况下，如果网关171具有其知晓的(例如，通过应用程序知识)、LAN 170之外的装置将感兴趣的一些关键服务，则网关171仅将这些特定记录导出到IoT DNS-SD服务器165。可以使用用于将记录从RD导出到DNS-SD服务器的常规过程，如在CoRE资源目录的章节9.6中所描述。IoT DNS-SD服务器165因此将填充有常规DNS RR以及本文所论述的新的RR。而且，如果在上述过程之后对RD的记录进行相关更新，则RD可以仅将新的RR导出到DNS-SD。

图9说明示例性系统操作阶段。与图8相关联的步骤可以保存在系统操作阶段中。出于说明性目的，在图6的场境中考虑以下步骤。在步骤211处，通过LAN 170的IoT装置172进行DNS查询。在步骤212处，网关171可以确定步骤211的查询是否是服务发现DNS查询。在步骤213处，如果步骤211的查询确定为常规DNS查询(例如，名称解析查询)，则对因特网上的DNS服务器161进行查询。

在步骤215处，如果步骤211的查询是服务发现DNS查询，则可以发生LAN 170内的本地查询。例如，此本地查询可以是对CoAP RD的搜索，或对LAN 170中的所有其它装置发起mDNS多播查询等等。在第一实例中，IoT装置172可以决定直接向LAN 170中的所有其它装置发起mDNS多播查询。在这种情况下，网关171除了用作正常IoT装置之外不必做任何事情，并且如果网关支持给定服务，则可能对mDNS查询作出响应。在第二实例中，IoT装置172可以决定执行单播DNS-SD查询。当网关171接收到单播DNS-SD请求时，其将拦截单播DNS-SD请求，并且将首先尝试查看是否可以在其本地CoAP RD数据库中找到服务。如先前所述，这是RD与DNS-SD记录之间的简单映射，如CoRe资源目录的章节9中所描述。哪个本地查询(例如，到RD的mDNS或单播DNS-SD)的选择由IoT装置172的应用逻辑作决定。

在步骤216处，确定是否在LAN 170内发现服务。在步骤217处，如果在LAN 170中找到在步骤211的查询中所请求的服务，则网关171或另一本地装置用DNS-SD响应对请求IoT装置172作出响应。在步骤219处，如果在LAN 170中未找到在步骤211的查询中所请求的服务，则网关171可以不立即对请求IoT装置172作出响应。相反，网关171可以将单播DNS-SD查询转发到IoT DNS-SD服务器165以查看是否可以在虚拟发现区域内其它地方(例如，在虚拟发现区域167内的LAN 180内)找到所请求服务。应注意，网关171可以属于若干重叠的发现虚拟区域。因此，当IoT DNS-SD服务器165接收步骤217的查询时，IoT DNS-SD服务器165将决定其希望此特定查询搜索哪个虚拟发现区域。此决定可以基于负载平衡、安全证书或其它因素。可以存在用于允许搜索重叠发现虚拟区域的IoT DNS-SD服务器165的默认配置。

在步骤221处，如果在虚拟发现区域167中的其它地方发现服务，则网关171从IoTDNS-SD服务器165接收DNS-SD响应并且将响应转发到请求IoT装置172。

在步骤223处，IoT装置172查看响应，并且通过查看具有休眠状态的返回的新RR记录来检查可以执行所请求服务的服务器目前在休眠还是唤醒(或将在相对短的时间内唤醒)，如本文所论述。如果服务器休眠，则IoT装置172通过网关171尝试在同一虚拟发现区域中的某处找到另一服务器。

在步骤219处，如果在区域中的任何地方不存在可用唤醒服务服务器，则IoT装置172可以触发网关171将DNS-SD请求发送到规则因特网DNS服务器161。应注意，IoT装置172可以基于其应用定时或其它要求来决定其想要触发各种DNS-SD请求的次数。在步骤225处，IoT装置172按需要接触服务服务器。

以下是与装置的休眠模式相关联的信令变化的讨论。如本文所论述，DNS的协议元素是RR的概念。这些RR描述DNS域以及个别装置的特征。例如，“A”记录提供装置(主机)的IPv地址，并且“MX”记录提供给定域的电子邮箱服务器名称。

下文提供可以适用于IETF标准的信令变化。表4中的通用DNS RR格式如下。查看从以引用方式全文并入的RFC 1035和http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml(下文称为DNS参数)获得的支持。

表4-DNS RR的通用格式

现在我们在如下表5和下文中定义新DNS RR(称为“IOTSLEEPINFO”)，以存储IoT装置休眠特征。

表5-称为IOTSLEEPINFO的新DNS RR的定义

其中：

1.RR类型＝IOTSLEEPINFO(其为新的RR类型)

2.当前休眠状态＝0(唤醒)，或1(休眠)。

3.休眠持续时间＝指示IoT装置可以休眠的时间间隔(例如，以秒为单位)的32位无符号整数(或另一长度的整数)。零值表示休眠持续时间未知。

4.休眠周期性＝指示休眠持续时间的启动之间的时间间隙(例如，以秒为单位)的16位无符号整数，零值可以表示休眠周期性未知。

5.种类＝因特网

上文所定义的新RR(IOTSLEEPINFO)可以存储在标准因特网DNS基础架构中或本文介绍的新的云DNS-SD服务器中。因此，新RR(IOTSLEEPINFO)对于传统的DNS基础架构以及新的云DNS-SD服务器两者都可能具有有效值。下文(例如，图13)存在关于处理休眠节点的额外论述。

下文是用于虚拟发现区域配置的替代方案。本文中，关于如何创建和配置虚拟发现区域提供基于OAM的方法。基于控制节点(例如，IoT DSN-SD服务器、IoT网关)之间的信令，替代方法可以用于如下所述的动态网络自配置(自动)方法。应注意，可以自动地完成本文论述的其它方法。图10说明参考图6的系统的自配置虚拟发现区域的示例性阶段。在步骤231处，可以动态地(自动地)形成LAN 170。例如，消防部门在火灾期间部署802.15温度传感器网络。在步骤232处，可以发送消息，例如，CoAP POST请求。例如，当创建新的IoT LAN 170时，其网关171可以将基于CoAP的应用消息自动地发送到IoT DNS-SD服务器165以向其通知LAN 170刚刚被创建。步骤232的消息可以包括向LAN 170分配虚拟发现区域167的请求，并且可以包括用于形成虚拟发现区域167的要求。步骤232的消息还可以包含关于LAN 170的信息，例如，其物理GPS坐标(例如，网关171坐标)以及由LAN 170内的IoT装置172和IoT装置173支持的关键服务。步骤232的消息还可以指示通过LAN 170的物理覆盖范围。物理覆盖范围可以与地理区域(例如，建筑物、gps坐标、城市、州等)相关联。CoAP RD(与网关171在同一位置)可以(在稍后的时间)发送另一基于CoAP的应用消息以填充关于装置(例如，其IP地址)以及在LAN 170内它们的资源或服务的信息。CoAP在本文中的使用是示例性的。替代方案将是使用HTTP消息来执行相同功能。

在步骤233处，IoT DNS-SD服务器165确定哪个虚拟发现区域将与LAN 170相关联。虚拟发现区域是LAN的逻辑分组，其中将存在一个共同DNS-SD服务发现区域。例如，可以根据LAN的GPS坐标决定将新的LAN分配到哪个区域。换句话说，云DNS-SD服务器(IoT DNS-SD服务器165)可以创建虚拟发现区域，以覆盖某个地理区域。还可以考虑其它因素，例如，访问许可、订阅的服务等。如果分配多个虚拟发现区域，则步骤234的消息可以包括多个标识符以及属于多个虚拟发现区域的每个虚拟发现区域的装置或服务列表。虚拟发现区域167的标识符可以通过IoT DNS-SD服务器165确定(尽管网关171可以在向IoT DNS-SD服务器165报告新创建的LAN 170的过程期间提出标识符)，标识符可以是GPS的散列，或例如，新LAN 170的其它坐标加上其服务。地理可以与LAN 170的单个装置、LAN 170的装置的平均或其它阈值地理(例如，LAN上的装置平均处于地理边界中)、主要由网关171组成的地理等相关联。以下是用于分配新创建的LAN的虚拟发现区域的几个实例。在第一实例中，每个虚拟发现区域可以与某一物理区域相关联。如果LAN位于其覆盖范围内，则新创建的LAN随后将分配有现有的虚拟发现区域。在第二实例中，IoT DNS-SD服务器可以将两个或更多个虚拟发现区域分配到新创建的LAN。分配多个LAN的原因可以与LAN的覆盖范围太大或是否存在一些隐私、安全或其它问题相关联。

在步骤234处，发送消息，例如，基于CoAP的应用消息。消息可以包括与其分配的虚拟发现区域(例如，分配到虚拟发现区域167)相关联的信息。步骤234的消息可以包括所分配的虚拟发现区域167的标识符。在步骤235处，LAN 170可以接受或拒绝虚拟发现区域167的分配。

图11说明自配置虚拟发现区域的另一示例性阶段。在步骤241处，可以确定拆除LAN 170(例如，在前一实例中，在火被扑灭之后几天)或以其它方式将LAN 170与虚拟发现区域167解除关联。在实例中，消防部门在火灾期间部署的802.15温度传感器网络不再被需要并且将被废弃。在步骤242处，网关171将消息，例如基于CoAP的应用消息发送到IoT DNS-SD服务器165。步骤242的消息包括将LAN 170与虚拟发现区域167解除关联的请求。在实例中：(应用数据：-请求将LAN170与虚拟发现区域167解除关联)。在步骤243处，如果消息具有正确许可，则IoT DNS-SD服务器165接收步骤242的消息并且适当地将LAN 170与虚拟发现区域167解除关联。在步骤244处，发送包括删除或其它考虑的确认的消息。步骤244的消息可以是CoAP DELETE响应。在步骤245处，网关171可以继续拆除LAN 170或与IoT DNS-SD服务器165解除关联所需的任何步骤。

继续参考图11，存在可以引起对现有的虚拟发现区域进行调整的若干情况。以下是几个实例。在第一实例中，当IoT装置172或其所支持装置变得不可用时，对应网关171(或CoAP RD)可以发送消息，例如基于CoAP的应用消息来更新IoT DNS-SD服务器165。因此，将从通过IoT DNS-SD服务器165保存的记录中去除IoT装置172或其服务。在第二实例中，当IoT装置172改变其休眠时间表时，网关171(或CoAP RD)将发送基于CoAP的应用消息，以向云DNS-SD服务器报告新的休眠信息。因此，云DNS-SD将更新其DNS-SD记录。在第三实例中，当被视为处于LAN 170内的网关171或IoT装置172改变其坐标或物理位置时，网关171(或CoAP RD)将发送基于CoAP的应用消息，以将新坐标发送到IoT DNS-SD服务器165。因此，IoTDNS-SD服务器165可以1)将当前虚拟发现区域167保持到网关171(例如，如果物理坐标变化不大)，2)将新的虚拟发现区域分配到网关171(例如，如果物理坐标的变化超过阈值)，3)合并到另一现有的虚拟发现区域(例如，如果新的物理坐标与另一现有的虚拟发现区域重叠)，或4)与另一现有的虚拟发现区域分离(例如，如果新的物理坐标与现有的虚拟发现区域重叠并且已存在太多装置)。LAN 170中的网关171或其它装置可以拒绝虚拟发现区域的分配。

图12说明可以并入有休眠节点处理的示例性广域服务发现实施方案。示例性场景可以涵盖智能电网运营商的休眠节点处理，其中城市范围的部署跨越多个LAN。或者，其可以是一组合作的智能电网运营商(每个拥有限制数目个LAN)，智能电网运营商一起合作用于城市范围的部署。如下文更详细地论述，图12的场境主要关注IETF相关信令，以及用于支持广域服务发现的节点内的相关联处理逻辑。

出于说明目的，在以下场景中考虑图12。LAN 170(例如，覆盖给定邻域的本地网络)中的家庭仪表(例如，IoT装置172)需要找到未休眠的(例如，唤醒的)电费(价格)服务器，以向服务器轮询当前电费(价格)信息。家庭仪表需要周期性地执行该操作，使得其可以向房主显示最新的费用信息。称为控制器(例如，控制器174或控制器183)的某些装置能够提供费用信息。

参考上述仪表控制器场景，图13说明用于使用上述称为“IOTSLEEPINFO”的DNS RR处理休眠节点场景的示例性流。在步骤251处，发送要求“费用信息服务器”的请求。在步骤252处，网关171检查RD并尝试找到LAN 170内的服务。在步骤253处，网关171发送提供费用信息在控制器174处的响应。响应还可以包括提供关于控制器174的休眠信息的DNS RR(例如，IOTSLEEPINFO-表5)。在步骤254处，IoT装置172(例如，家庭仪表)检查新的IOTSLEEPINFO RR，并且确定控制器174当前在休眠。在步骤255处，发送消息，该消息包括寻求“费用信息服务器”的请求。在步骤255处的请求可以类似于步骤251的请求。在步骤256处，网关171可以确定在步骤253处从RD提供响应，因此下一步骤是查询IoT DNS-SD服务器165。

继续参考图13，在步骤257处，发送消息，该消息包括对位于虚拟发现区域167中的“费用信息服务器”的请求。在步骤258处，IoT DNS-SD服务器165确定控制器183先前被注册为“费用信息服务器”。在步骤259处，发送消息，该消息包括另一“费用信息服务器”(例如，控制器183@74.125.224.72)的联系信息(例如，IP地址)。在步骤260处，将步骤259的信息转发到IoT装置172。在步骤261处，IoT装置172确定控制器183唤醒。此唤醒状态可能已通过检查伴随步骤260的消息的DNS RR被确定。在步骤262处，发送请求当前电费的消息。消息可以是CoAP GET请求。在步骤263处，IoT装置172可以接收指示来自262的消息。步骤263的消息可以包括具有当前电费数据的CoAP GET响应。

继续参考图12和图13，下文是前述仪表休眠场景的其它考虑。从家庭仪表(IoT装置172)到网关171的步骤251的请求(其可以是DNS-SD查询)导致被告知同一LAN 170中的控制器174支持提供费用信息的所需服务。然而，可以被包括在步骤253的消息中的“IOTSLEEPINFO”RR指示控制器174当前休眠并且将休眠比可接受阈值更长的时间。在步骤255处，可以对网关171作出另一请求(DNS-SD查询)。在步骤256处，考虑先前请求。网关171需要记录先前查询(在某一缓存时间段内)并知道其最近提供类似问题的回答。因此，假设先前回答不令人满意，因此现在查询IoT DNS-SD服务器165以在虚拟发现区域167中的别的某个地方找到另一费用信息服务器。或者，可以跳过步骤252至255，并且网关171可以直接检查合适的DNS RR(IOTSLEEPINFO)和其它偏好，以确定是否向另一控制器查询所请求费用信息。

当IoT DNS-SD服务器165在步骤258处接收步骤257的查询时，所述IoT DNS-SD服务器必须决定其希望哪个虚拟发现区域搜索此特定查询。这可以例如通过查看网关171的始发IP地址(其可以包含在携带步骤257的查询的消息中)来实现。在实例中，根据网关171的IP地址，IoT DNS-SD服务器165可以通过其将RR映射到虚拟发现区域的内部数据结构进行确定。如本文所述，虚拟发现区域被定义为网关(以及其对应装置)组与云DNS-SD服务器(例如，IoT DNS-SD服务器165)之间的关系。如图13中所说明，IoT DNS-SD服务器在步骤259处用不同LAN(LAN 180)中的另一费用信息服务器(例如，控制器183)回答。仪表可以看到，对于其IOTSLEEPINFO RR，此控制器180当前未休眠，因此能够直接地查询控制器并且获得正查找的费用信息。或者，如上所述，仪表(IoT装置172)可以不接收IOTSLEEPINFO RR，并且可以仅将其请求发送到由IoT DNS-SD服务器165提供的地址。

图14说明与本文所论述的广域服务发现相关联的示例性图形用户界面。显示器270(而且显示器42)可以允许用户对接IoT DNS-SD服务器165的OMA系统的一部分。显示器270可以是触摸屏并且允许IoT DNS-SD服务器165的提供商以图形方式显示器相关联的虚拟发现区域。在显示器270的272处，提供包含在例如图12、图6和其它图中所示的给定虚拟发现区域中的LAN的图形视图。在显示器270的271处，可以存在命令、变量、输入、输出、流、与如本文所论述的广域服务发现相关联的操作的成功和失败的文本表示。以下是实例：虚拟发现区域167＝{IoT DNS-SD服务器165、LAN 170、LAN 180}。虚拟发现区域可能已通过OAM或以另一种方式动态地创建。

而且，IoT DNS-SD服务器165的提供商还可以允许LAN的各个所有者远程查看虚拟发现区域。这些视图可以通过网络界面，LAN的所有者可以通过密码或其它安全证书从笔记本电脑或智能手机访问网络界面。在实例中，假设在类似于图12的场境中，个体LAN由不同的智能电网运营商(其正一起合作用于城市范围的部署)拥有。运营商A拥有LAN-1、LAN-2和LAN-3(未示出)并且运营商B拥有LAN-4和LAN-5。随后，运营商A或运营商B可以获得虚拟发现区域(类似于图12)或文本表示的图形视图。

图15A是可以在其中实施与广域服务发现相关联的一个或多个公开的概念(例如，图6至图14等等)的示例性机器对机器(M2M)、物联网(IoT)或物联万维网(WoT)通信系统10的框图。通常，M2M技术为IoT/WoT提供构建块，并且任何M2M装置或M2M网关可以是IoT/WoT的组成部分。

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

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

图15B是可以用于广域服务发现的实例M2M装置30，例如，M2M终端装置18或M2M网关装置14的系统图。如图15B中所示，M2M装置30可以包括处理器32、收发器34、发射/接收元件36、扬声器/麦克风38、小键盘40、显示器/触摸板42、不可移动存储器44、可移动存储器46、电源48、全球定位系统(GPS)芯片组50以及其它外围设备52。应了解，M2M装置30可以包括前述元件的任何子组合，同时保持与所公开的主题相一致。M2M装置30(例如，IoT装置172、控制器174、网关171、IoT DNS-SD服务器165等)可以是执行用于广域服务发现的所公开系统和方法的示例性实施方案。

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

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

另外，尽管发射/接收元件36在图15B中描绘为单个元件，但是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可以被配置成响应于本文描述的一些实例中的LMS是成功还是不成功(例如，IOTSLEEPINFO RR或到达LAN之外，但在虚拟发现区域内的装置)而控制显示器或指示器42上的照明模式、图像或颜色，或以其它方式指示虚拟发现区域或相关方法和组件的状态。显示器或指示器42上的控制照明模式、图像或颜色可以反映本文所说明或论述的图(例如，图6至图14等)中的方法流或组件中的任一个的状态。本文公开广域服务发现的消息和过程。可以扩展所述消息和过程以提供用户通过输入源(例如，扬声器/麦克风38、小键盘40，或显示器/触摸板42)请求广域服务发现相关的信息的接口/API，以及请求、配置或查询可以显示在显示器42上的广域服务发现信息等。

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

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

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

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

发射/接收元件36可以体现在其它设备或装置中，例如，传感器、消费类电子产品、例如智能手表或智能服装的可穿戴装置、医疗或eHealth装置、机器人、工业设备、无人机、例如汽车、卡车、火车或飞机的车辆。发射/接收元件36可以通过一个或多个互连接口，例如，可以包括外围设备52中的一个的互连接口连接到此类设备或装置的其它组件、模块或系统。

图15C是其上可以实施例如图15A的平台的示例性计算系统90的框图。计算系统90(例如，M2M终端装置18或M2M网关装置14)可以包括计算机或服务器，并且可以主要由计算机可读指令来控制，计算机可读指令可以采用软件的形式，无论何地或通过任何手段存储或访问此软件。此计算机可读指令可以在中央处理单元(CPU)91内执行以使计算系统90工作。在许多已知的工作站、服务器和个人计算机中，中央处理单元91通过称为微处理器的单芯片CPU实施。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU91不同的可选处理器，其执行附加功能或辅助CPU 91。CPU 91或协处理器81可以接收、产生和处理与用于广域服务发现的所公开系统和方法，例如接收DNS-SD查询有关的数据。

在操作时，CPU 91提取、解码和执行指令，并且通过计算机的主数据传送路径，即系统总线80往返于其它资源传送信息。此系统总线连接计算系统90中的组件并且定义用于数据交换的媒体。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线，以及用于发送中断以及用于操作系统总线的控制线。此系统总线80的实例是PCI(外围组件互连)总线。

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

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

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

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

参考图15D，在场域中的说明的M2M服务层22为M2M应用20(例如，IoT装置172的应用)、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的功能可以通过各种方式，例如作为网络服务器、在蜂窝核心网络中、在云中等实施。

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

还参考图15D，M2M服务层22和22'提供不同应用和行业可以利用的核心服务交付能力集合。这些服务能力使M2M应用20和20'能够与装置交互并且执例如数据收集、数据分析、装置管理、安全性、计费、服务/装置发现等功能。实质上，这些服务能力免除了应用实施这些功能的负担，由此简化应用开发并减少成本和上市时间。服务层22和22'还使M2M应用20和20'能够通过与服务层22和22’提供的服务连接的各个网络12和12’通信。

在一些实例中，M2M应用20和20’可以包括如文本所述与广域发现服务通信的所需应用。M2M应用20和20'可以包括各种行业中的应用，例如但不限于交通，健康和保健，联网家庭，能源管理，资产跟踪以及安全和监视。如上所述，在系统的装置、网关和其它服务器上运行的M2M服务层支持例如数据收集、装置管理、安全性、计费、位置跟踪/地理围栏、装置/服务发现和传统系统集成的功能，并且将这些功能作为服务提供给M2M应用20和20'。

本申请案的广域服务发现可以作为服务层的一部分实施。服务层是通过一组应用程序接口(API)和底层网络接口支持增值服务能力的中间件层。M2M实体(例如，例如在硬件上实施的装置、网关或服务/平台的M2M功能实体)可以提供应用或服务。ETSI M2M和oneM2M两者使用可以包括本申请案的广域服务发现的服务层。oneM2M服务层支持一组公共服务功能(CSF)(即，服务能力)。一组一个或多个特定类型的CSF的实例化被称为公共服务实体(CSE)，其可以托管在不同类型的网络节点(例如，基础架构节点、中间节点、专用节点)上。此外，本申请案的广域服务发现可以实施为使用面向服务的架构(SOA)或面向资源的架构(ROA)来访问服务，例如本申请案的广域服务发现的M2M网络的一部分。

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

应理解，本文所描述的任何或全部系统、方法和过程可以用存储在计算机可读存储媒体上的计算机可执行指令(即，程序代码)的形式来体现，所述指令在由例如计算机、服务器、M2M终端装置、M2M网关装置等的机器执行时执行或实施本文所描述的系统、方法和过程。具体来说，上述步骤、操作或功能中的任一个可以用此类计算机可执行指令的形式实施。计算机可读存储媒体包括以用于存储信息的任何方法或技术实施的易失性和非易失性、可移动和不可移动媒体，但是此类计算机可读存储媒体不包括信号。计算机可读存储媒体包括但不限于RAM、ROM、EEPROM、闪存存储器或其它存储器技术、CD-ROM、数字多功能光盘(DVD)或其它光盘存储装置、磁带盒、磁带、磁盘存储装置或其它磁性存储装置，或可以用于存储所需信息并可以由计算机访问的任何其它物理媒体。

在描述本发明的主题，即如图中所说明的广域服务发现的优选方法、系统或设备时，为了清楚起见采用特定术语。然而，所要求保护的主题不旨在限制于如此选择的特定术语，并且应理解，每个特定元件包括以类似方式操作以实现类似目的的所有技术等同物。应注意，本发明集中于使用IoT使用案例的所提出解决方案。然而，应明白本发明还可以适用于具有类似特性的非IoT场景。

本文所描述的各种技术可以结合硬件、固件、软件或者在适当的情况下其组合来实施。此硬件、固件和软件可以驻留在位于通信网络的各个节点处的设备中。设备可以单独地操作或彼此组合操作以实现本文所描述的方法。本文使用的术语“设备”、“网络设备”、“节点”、“装置”、“网络节点”等可以可互换地使用。

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

如本文所描述的方法、系统和设备等可以提供用于装置的广域服务发现的构件。方法、系统、计算机可读存储媒体或设备具有用于执行以下操作的构件：接收第一局域网上的第一消息，第一消息包括对服务的请求；确定服务不位于第一局域网上；响应于确定服务不位于第一局域网上，将第二消息提供到服务器，第二消息包括对服务的请求；以及接收第三消息，第三消息包括与服务相关联的信息。第一消息可以是包括对服务的请求的多个消息中的一个，多个消息可以通过多播DNS发送。服务器可以操作为DNS-SD的服务器。与服务相关联的信息可以包括服务的地址。与服务相关联的信息可以包括服务的可用性的指示。服务可以位于远程装置上并且远程装置可以位于第二局域网上。服务器可以位于广域网上。方法、系统、计算机可读存储媒体或设备具有用于将与服务相关联的信息提供到客户端装置的构件，客户端装置通过第一消息指示作为服务的请求方。第一消息可以是DNS-SD查询。第三消息可以是对第二消息的DNS-SD响应。方法、系统、计算机可读存储媒体或设备具有用于基于约束应用协议、CoAP、资源目录的查询确定服务不位于第一局域网上的构件。第二消息可以包括对虚拟发现区域的分配的请求。第三消息可以包括虚拟发现区域的分配。这个段落中的所有组合(包括步骤的移除或添加)都是以与详细描述的其它部分一致的方式来设想的。

方法、系统、计算机可读存储媒体或设备具有用于从第一LAN接收服务的DNS-SD查询；以及响应于接收DNS-SD查询，提供关于所述服务的信息的构件，服务处于第二LAN上。

方法、系统、计算机可读存储媒体或设备具有用于将请求提供到服务；以及接收对请求的响应的构件，响应包括关于与服务相关联的装置的休眠节点信息。

通过图示方式提供本文所描述的主题。在不遵循所说明和所描述的实例和应用程序(例如，跳过或添加步骤)的情况下以及在不脱离权利要求书中阐述的所公开主题的真实精神和范围的情况下，可以对本文所描述的主题进行各种修改和改变。

Claims (15)

1.一种用于在第一局域网中形成网关的设备，其包括：

处理器；以及

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

在第一局域网被创建时，在消息中向域名系统服务发现DNS-SD服务器请求分配虚拟发现区域；

从DNS-SD服务器接收虚拟发现区域的分配，所述虚拟发现区域是包括所述第一局域网在内的多个局域网的逻辑分组，所述逻辑分组具有共同DNS-SD服务发现区域，能够实现所述多个局域网的逻辑分组中的所有服务的服务发现，所述虚拟发现区域建立在所述多个局域网之外，所述多个局域网在物理上分离；

接收来自所述第一局域网上的第一装置的第一消息，所述第一消息包括对服务的DNS-SD查询；

确定所述服务不位于所述第一局域网上；

响应于确定所述服务不位于所述第一局域网上，将第二消息提供给DNS-SD服务器，所述第二消息包括对所述服务的DNS-SD查询；

接收来自DNS-SD服务器的第三消息，所述第三消息由DNS-SD服务器生成，并包括对所述第二消息的DNS-SD响应，所述第三消息包括与所述服务相关联的信息，该信息指示所述服务在虚拟发现区域中的其它地方被发现；以及

将所述第三消息转发给所述第一装置，

其中，所述第三消息进一步包括DNS资源记录，所述DNS资源记录提供托管所述服务的设备的休眠特征，所述休眠特征包括当前休眠状态、休眠持续时间或者休眠周期性。

2.根据权利要求1所述的设备，其中所述第一消息是包括对所述服务的请求的多个消息中的一个，所述多个消息通过多播域名系统发送。

3.根据权利要求1所述的设备，其中与所述服务相关联的所述信息包括所述服务的地址。

4.根据权利要求1所述的设备，其中与所述服务相关联的所述信息包括所述服务的可用性的指示。

5.根据权利要求1所述的设备，其中所述服务位于远程装置上，所述远程装置位于第二局域网上。

6.根据权利要求1所述的设备，其中所述DNS-SD服务器位于广域网上。

7.根据权利要求1所述的设备，其中所述DNS-SD服务器是基础架构即服务IAAS。

8.根据权利要求1所述的设备，其中确定所述服务不位于所述第一局域网上是基于约束应用协议CoAP资源目录的查询。

9.根据权利要求1所述的设备，其中所述第二消息进一步包括对所述虚拟发现区域的分配的请求。

10.根据权利要求1所述的设备，其中所述第三消息进一步包括所述虚拟发现区域的分配。

11.一种计算机可读存储媒体，包括当由计算装置执行时使所述计算装置执行操作的计算机可执行指令，所述操作包括：

在第一局域网被创建时，在消息中向域名系统服务发现DNS-SD服务器请求分配虚拟发现区域；

从DNS-SD服务器接收虚拟发现区域的分配，所述虚拟发现区域是包括所述第一局域网在内的多个局域网的逻辑分组，所述逻辑分组具有共同DNS-SD服务发现区域，能够实现所述多个局域网的逻辑分组中的所有服务的服务发现，所述虚拟发现区域建立在所述多个局域网之外，所述多个局域网在物理上分离；

接收来自所述第一局域网上的第一装置的第一消息，所述第一消息包括对服务的DNS-SD查询；

确定所述服务不位于所述第一局域网上；

响应于确定所述服务不位于所述第一局域网上，将第二消息提供给DNS-SD服务器，所述第二消息包括对所述服务的DNS-SD查询；

接收来自DNS-SD服务器的第三消息，所述第三消息由DNS-SD服务器生成，并包括对所述第二消息的DNS-SD响应，所述第三消息包括与所述服务相关联的信息，该信息指示所述服务在虚拟发现区域中的其它地方被发现；以及

将所述第三消息转发给所述第一装置，

其中，所述第三消息进一步包括DNS资源记录，所述DNS资源记录提供托管所述服务的设备的休眠特征，所述休眠特征包括当前休眠状态、休眠持续时间或者休眠周期性。

12.根据权利要求11所述的计算机可读存储媒体，其中所述第一消息是包括对所述服务的请求的多个消息中的一个，所述多个消息通过多播域名系统发送。

13.根据权利要求11所述的计算机可读存储媒体，其中与所述服务相关联的所述信息包括所述服务的地址。

14.根据权利要求11所述的计算机可读存储媒体，其中与所述服务相关联的所述信息包括所述服务的可用性的指示。

15.根据权利要求11所述的计算机可读存储媒体，其中所述DNS-SD服务位于远程装置上，所述远程装置位于第二局域网上。

Images