CN107113182A - 用于在服务层处支持协商服务的方法 - Google Patents

Abstract

本申请涉及一种用于协商服务层属性的计算机实现的装置。所述装置包括非暂时性存储器，所述非暂时性存储器包括针对协商服务层而存储在其上以用于协商服务属性的指令。所述装置也包括可操作地耦合到所述非暂时性存储器的处理器。所述处理器被配置成执行审查从受协商者接收到的可协商服务层属性的指令。所述处理器也被配置成执行基于所审查的属性来向所述受协商者发送协商请求的指令。所述处理器也被配置成执行从所述受协商者接收提供的建议的指令。本申请的另一方面涉及一种联网的系统，所述联网的系统包括计算机实现的受协商者和计算机实现的协商者以用于协商服务层属性。

Description

用于在服务层处支持协商服务的方法

相关申请的交叉引用

本申请要求2014年12月1日提交的美国临时申请No.62/086,102的优先权，其公开内容通过引用全部并入本文中。

背景技术

机器到机器(M2M)技术允许设备使用有线和无线通信系统来与彼此更直接地进行通信。M2M技术实现物联网(IoT)的进一步达成、唯一可识别对象的系统以及通过诸如互联网的网络彼此进行通信的这样的对象的虚拟表示。IoT可以促进与平常的日常对象——诸如食品杂货店中的产品或家庭中的器具——的通信，并且从而通过改进对这样的对象的知悉来减少成本和浪费。例如，商店可以通过能够与可能在库存中或可能已被出售的对象进行通信或者从可能在库存中或可能已被出售的对象获得数据来维护非常精确的库存数据。

M2M服务节点和应用目前依赖静态配置或预备置(preprovisioning)来从M2M服务层提供/访问服务。即，对于在不同的时间动态地请求特定服务的各个特征或功能性来说存在效率低的支持。例如，现有oneM2M不提供供中间节点(MN)公共服务实体(CSE)从基础架构节点(IN)-CSE动态地请求存储的机制。另外，IN-CSE不具有服务来管理IN应用实体(AE)可管理的设备的数目和/或IN-AE可向IN-CSE发出请求有多频繁。

静态配置直接地影响吞吐量。即，M2M服务器在向M2M应用提供服务时的灵活性是非常有限的。因此，预配置的服务对M2M服务器和/或M2M设备来说可能不是最佳选择。例如，需要的服务可能由于要求改变或场境(context)改变而改变，例如，M2M服务器具有更多的注册设备或者M2M设备移动到具有更多的通信约束的新位置。

发明内容

本发明内容被提供来以简化形式引入下面在具体实施方式中进一步描述的构思的选择。本发明内容不旨在限制所要求保护的主题的范围。在很大程度上通过针对用于改进M2M服务层处的协商服务并且提供用于动态地请求服务的能力的过程和系统的本申请来满足上述内容。

在本申请的一个方面中，描述了一种计算机实现的方法。所述方法包括审查从受协商者接收到的可协商服务层属性的步骤。所述方法还包括基于所审查的属性来向所述受协商者发送协商请求的步骤。所述方法也包括从所述受协商者接收提供的建议的步骤。在一个实施例中，所述方法包括在检查预定协商策略时选择所述提供的建议的步骤。在另一实施例中，所述方法包括所接收到的提供的建议对照所述受协商者的预定协商策略被检查的步骤。在另一实施例中，所述协商请求的步骤包括从服务id、用于作出建议的输入、提出的建议及其组合中选择的信息。根据另一实施例，所述提供的建议包括从建议、与另一受协商者协商的推荐、及其组合中选择的信息。根据另一实施例，发送所述协商请求的步骤是经由代理程序被发送到所述受协商者。根据另一个实施例，接收所述提供的建议的步骤是经由所述代理程序从所述受协商者接收。

在本申请的另一方面中，描述了一种计算机实现的方法，所述计算机实现的方法包括从受协商者接收用于协商可协商服务层属性的策略的步骤。所述方法也包括从协商者接收协商所述属性的请求的步骤。所述方法也包括确定所述请求是否遵守受协商者策略的预定准则的步骤。另外，所述方法包括向所述协商者发送提供的建议的步骤。在一个实施例中，所述方法包括从所述协商者接收协商确认并且向所述受协商者发送所述协商确认的确收(acknowledgement)的步骤。

在本申请的又一个方面中，描述了一种计算机实现的方法，所述计算机实现的方法包括从协商者接收对可协商服务层属性的协商请求的步骤。所述方法也包括定位具有所述属性的受协商者的步骤。所述方法也包括将所述协商请求发送到所述受协商者的步骤。而且，所述方法包括从所述受协商者接收针对所述可协商服务的提供的建议的步骤。根据一个实施例，所述方法包括将所述提供的建议发送到所述协商者、从所述协商者接收协商确认、并且向所述受协商者发送所述协商确认的确收的步骤。

根据另一方面，公开了一种计算机实现的装置。所述装置包括包含协商服务层的非暂时性存储器，所述非暂时性存储器具有存储在其上以用于协商服务属性的指令。所述装置也包括可操作地耦合到所述非暂时性存储器的处理器。所述处理器被配置成执行审查从受协商者接收到的所述属性的指令。所述处理器也被配置成基于所审查的属性来向所述受协商者发送协商请求。根据一个实施例，所述处理器还被配置成执行从所述受协商者接收提供的建议的指令。在一个实施例中，所述计算机实现的装置包括具有用户界面的显示器，所述显示器可操作地连接到所述非暂时性存储器和处理器。

在本申请的又一方面中，所述计算机实现的装置被描述为具有包括协商服务层的非暂时性存储器，所述非暂时性存储器具有存储在其上以用于协商服务属性的指令。所述装置也包括处理器，所述处理器可操作地耦合到所述非暂时性存储器并且被配置成执行以下操作的指令：(i)从受协商者接收用于协商所述属性的策略；(ii)从协商者接收协商所述属性的请求；以及(iii)确定所述请求是否遵守受协商者策略的准则。根据一个实施例，所述处理器还被配置成执行向所述协商者发送提供的建议的指令。在一个实施例中，所述非暂时性存储器存储从公共属性、创建、检索、删除、更新、执行、标签、代理程序、类型、用于作出建议的输入、用于选择建议的输入、开始、状态、目标、引用、提供的建议、选择的建议、输出参数、订阅及其组合中选择的协商资源。在另一实施例中，所述处理器使用所述协商资源来协商所述属性。在另一实施例中，所述存储器存储从公共属性、标签、协商类型、协商者、受协商者、条件、结果、选择规则、订阅及其组合中选择的策略资源。在另一个实施例中，所述处理器使用所述策略资源来协商所述属性。在又一个实施例中，所述存储器存储从公共属性、标签、客户端、当前协商代理程序、新协商代理程序、委托启用、开始时间、持续时间、结果、订阅及其组合中选择的委托资源。在又另一个实施例中，所述处理器使用所述委托资源来协商所述属性。

本申请的另一个方面描述一种计算机实现的网络。所述网络包括协商者和受协商者。所述协商者和受协商者中的每一个包括用于发送和接收数据的收发器。所述协商者和受协商者中的每一个也包括具有协商服务层的非暂时性存储器，所述非暂时性存储器具有存储在其上以用于协商服务层属性的指令。所述协商者和受协商者中的每一个也包括处理器，所述处理器可操作地耦合到所述非暂时性存储器，被配置来执行所述服务层属性的协商。根据一个实施例，所述协商者和受协商者的所述存储器包括从协商资源、策略资源、委托资源及其组合中选择的资源。

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

附图说明

为了促进对本申请的更鲁棒理解，现在对附图进行参考，在附图中相似的元件用相似的附图标记来引用。这些附图不应该被解释为限制本申请并且仅旨在为说明性的。

图1图示支持服务层的协议栈。

图2图示公共服务实体(CSE)和公共服务功能(CSF)。

图3A图示oneM2M服务层架构。

图3B图示oneM2M服务组件架构。

图4A图示机器到机器(M2M)或IoT通信系统的实施例。

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

图4C图示示例M2M设备的系统图的应用的实施例。

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

图5A图示根据本申请的一个方面的采用协商服务的动态服务的架构视图。

图5B图示根据本申请的一个方面的用于配置和显示协商策略的图形用户界面。

图6图示根据本申请的一个方面的用于单独的协商请求的服务协商协议。

图7图示根据本申请的一个方面的用于在受协商者处作出建议的决策查询。

图8图示根据本申请的一个方面的用于在协商者处选择建议的决策查询。

图9图示根据本申请的一个方面的、针对多个协商请求的服务协商的流程图。

图10图示根据本申请的一个方面的、针对在透明模式下的基于代理程序的服务协商的流程图。

图11图示根据本申请的另一方面的、针对作为用于协商的代理的基于代理程序的服务协商的流程图。

图12图示根据本申请的另一方面的、针对利用认证和授权协议的基于代理程序的服务协商的流程图。

图13图示根据本申请的另一方面的、针对采用协商请求的组合的基于代理程序的服务协商的流程图。

图14图示根据本申请的另一方面的针对基于代理程序的服务委托的流程图。

图15图示CSF位图的示例性实施例。

图16图示CSF特征位图的示例性实施例。

图17图示根据本申请的一个方面的包括协商服务(NGS)的oneM2M架构。

图18图示根据本申请的一个方面的oneM2M面向资源架构(ROA)中的NGS CSF。

图19图示根据本申请的另一方面的oneM2M ROA中的NGS CSF。

图20图示根据本申请的一个方面的oneM2M<ngtn>资源的结构。

图21图示根据本申请的一个方面的oneM2M<ngtnPolicy>资源的结构。

图22图示根据本申请的一个方面的oneM2M<ngtnDelegation>资源的结构。

图23图示根据本申请的一个方面的MN-CSE与IN-CSE之间的服务协商的示例性实施例。

图24图示添加到oneM2M面向服务架构(SOA)中的协商服务的示例性实施例。

具体实施方式

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

在本说明书中对“一个实施例”、“实施例”、“一个或多个实施例”、“一个方面”等的引用意指与该实施例结合来描述的特定特征、结构、或特性被包括在本公开的至少一个实施例中。而且，在本说明书中的各个地方处的术语“实施例”未必指代同一实施例。即，描述了可以由一些实施例而不由其它实施例所展示的各个特征。

本申请描述用于采用新功能的技术，所述新功能诸如服务层处的协商服务(NGS)，其帮助服务节点和应用从其它服务节点或应用动态地请求并调整服务。在一个实施例中，根据协商服务，协商者是发出协商请求的M2M实体，而受协商者是接收协商请求并且提供建议的M2M实体。受协商者作出建议并且协商者基于预配置的协商策略来选择建议。这些基于策略的协商过程很适合于各种服务可使用这样的基于策略的公共服务功能来协商的M2M系统。这样的功能包括作出建议以及选择适合于协商不同的服务的建议。

在一个方面中，协商者可主动地提出某些建议，该建议帮助加快协商过程并且减少协商开销，这对受约束M2M设备来说是特别有益的。此外，受协商者可在改进协商成功率并且也可以减少总体协商信令开销的协商过程期间推荐其它受协商者。受协商者也可组合来自多个协商者的请求，以作出更智能的建议以满足所有协商者。

在另一方面中，协商代理程序(Negotiation Broker)是可充当协商者和/或受协商者的代理的M2M实体。协商代理程序可在协商者与受协商者之间转发协商相关消息。这通过将协商任务卸载(offload)到协商代理程序来减轻受约束设备处的协商开销。根据一个实施例，描述了协商代理程序可以自动地选取对应的受协商者的透明模式。在透明模式下，协商代理程序可以帮助受约束M2M设备——即协商者——自动地选取受协商者。因此，受约束M2M设备不需要知道受协商者的身份。在透明模式下，协商代理程序可帮助受约束M2M设备——即协商者——自动地选取受协商者。因此，受约束M2M设备不需要知道受协商者。

在代理模式下，协商代理程序可充当受约束M2M设备的代理来执行协商任务，例如，作出建议并且选择建议。受约束M2M设备仅需要接收协商结果。所提出的基于代理程序协商途径帮助受约束M2M设备以较容易的方式执行协商。此方法可减轻到/来自受约束设备的通信开销。

在另一实施例中，描述了受协商者的代理，其中协商代理程序代表受协商者作出建议。在代理模式下，协商代理程序可充当受约束M2M设备的代理来执行协商任务，即，作出建议并且选择建议。

在另一实施例中，协商代理程序委托被提出以将协商功能从一个协商代理程序委托给另一协商代理程序。所提出的用于推荐受协商者的构思能可帮助改进协商成功率并且相应地减少开销。根据一方面，所提出的用于组合并处理多个协商请求的构思可联合地处理来自各个M2M应用的协商请求并且进而帮助改进协商成功率并且降低协商开销。

服务层

从协议栈观点看，服务层通常位于应用协议层上方并且向客户端应用提供增值服务。因此，服务层常常被分类为“中间件”服务。例如，图1示出IP网络栈与应用之间的示例性服务层。

M2M服务层是具体地针对为M2M类型设备和应用提供增值服务的一种类型的服务层的示例。近来，若干行业标准组织(industry standards body)(例如，oneM2M)一直在开发M2M服务层以解决与将M2M类型的设备和应用向诸如互联网/Web、蜂窝、企业、和家庭网络的部署中的整合相关联的挑战。

M2M服务层可提供应用和设备对由服务层支持的一批面向M2M的能力的访问。几个示例包括但不限于安全、计费、数据管理、设备管理、发现、备置、和连接性管理。可经由利用由M2M服务层定义的消息格式、资源结构和资源表示的API向应用提供这些能力。

OneM2M服务层架构

OneM2M是用于开发解决对公共M2M服务层的需要的技术规范的新标准，所述公共M2M服务层可被容易地嵌入在各种硬件和软件内，并且依靠所述公共M2M服务层来将在场中的各式各样的设备与全世界的M2M应用服务器连接在一起。

OneM2M公共服务层支持一组公共服务功能(CSF)，即，服务能力，如图2中所示。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，其可被托管在不同类型的网络节点——例如基础架构节点、中间节点、专用节点——上。OneM2M正在被称作图3A中所示的面向资源架构(ROA)和图3B中所示的面向服务架构(SOA)的两个架构途径中开发服务层。

如图3A中所示，资源是具有可经由诸如Create(创建)、Retrieve(检索)、Update(更新)、和Delete(删除)的RESTful方法操纵的表示的架构中的唯一可寻址元素。这些资源使用统一资源标识符(URI)变得可寻址。资源可以包含子资源和属性。子资源是与父资源具有包含关系的资源。父资源表示包含对其子资源的引用。子资源的生命期受父资源的生命期限制。每个资源支持存储资源的信息的一组“属性”。

SOA架构正被开发以考虑不基于RESTful的传统部署。如图3B中所示，它在很大程度上重用相同的服务层功能架构。该服务层包含各种M2M服务，并且可将多个服务分组成服务组件。除现有参考点之外，它引入了服务间参考点Msc。通过Msc参考点传递的M2M服务组件之间的通信利用web服务途径，例如Web服务消息交换模式(MEP)。

OneM2M CSF

当前在oneM2M中定义了可由诸如M2M服务器或端点M2M设备的CSE提供给其它CSE或AE的以下十二个CSF。这些被示出在图2中。

应用和服务层管理(ASM)：提供用于配置、故障诊断和升级CSE以及AE的功能的管理能力。

通信管理和递送处置(CMDH)：决策在什么时间将特定通信连接用于递送通信，例如，CSE到CSE通信，以及在需要且允许时，缓存通信请求以使得可在稍后的时间转发它们。

数据管理和存储库(DMR)：负责提供数据存储和居间处理(mediation)功能。它包括出于聚合大量数据的目的而收集数据、将此数据转换为指定格式、并且存储它以供分析和语义处理的能力。

设备管理(DMG)：提供对关于MN——例如M2M网关、ASN和ADN——例如M2M设备、以及驻留在M2M区域网络内的设备的设备能力的管理。

发现(DIS)：搜索包含在属性和资源中的关于应用和服务的信息。

组管理(GMG)：负责处置组相关请求。该请求被发送以管理组及其成员关系以及用于由该组支持的批操作。

位置(LOC)：允许AE为基于位置的服务获得节点——例如ASN、MN——的地理位置信息。

网络服务暴露、服务执行和触发(NSSE)：管理与用于通过Mcn参考点来访问网络服务功能的底层网络的通信。

注册(REG)：处理来自AE或另一CSE的用于向受理注册者(Registrar)CSE注册的请求以便允许已注册的实体使用由受理注册者CSE提供的服务。

安全(SEC)：包括诸如以下的功能：敏感数据处置、安全管控(securityadministration)、安全关联建立、包括识别/认证/授权的访问控制、以及身份管理。

服务计费和核算(SCA)：为服务层提供计费功能。它支持也包括在线实时信用控制的不同的计费模型。

订阅和通知(SUB)：提供与跟踪资源上的改变——例如资源的委托——的订阅有关的通知。

服务层协商

可在服务层协商中采用以下现有服务和/或协议：

协商请求核准：协商服务可基于相关场境以及过去的请求和协商结果的历史来决策是否接受来自请求者的协商请求。协商服务还可基于协商的紧迫度来设立请求的优先级。

协商方控制：协商服务可决策与谁执行协商。协商方可由请求者通知或者通过基于在可用IoT服务提供者上的发现结果的认知能力来确定等。

协商策略控制：协商服务可代表请求者选取协商策略。协商服务总是基于请求者的输入协商目标来考虑请求者的最佳利益。

协商适配：协商服务可能由于策略改变或场境改变而被适配。可基于如场境、软件定义设定和来自其它服务的输入这样的事情动态地适配协商服务策略。经由策略的动态适配，可进而动态地适配决策。场境感知服务可以动态地更新协商服务的相关场境以用于协商适配，或者协商服务可从场境感知服务中前摄性地检索相关场境。

协商泛化：协商服务能够作出从过去的协商过程概括的泛化和公共的协商策略，其可以由稍后的协商请求者使用，并且降低认知能力在为每个请求者决策协商策略时的过载。

协商订阅：对协商结果的订阅被提供以使得可向订户通知任何适配。此订阅机制使得能够实现自主适配。如果订户正在使用与其订阅的一个协商结果相同的协商结果，则对所订阅的协商结果的任何改变可触发该订户自动地适应它。在没有协商订阅的情况下，其它实体不能够重用和遵循协商结果。本公开也描述所提出的智能协商服务的组件以及对其它IoT服务、IoT实体和IoT应用的接口。

一般架构

图4A是可以在其中实现一个或多个公开的实施例的示例机器到机器(M2M)、物联网(IoT)、或物品万维网(WoT)通信系统10的图。一般地，M2M技术为IoT/WoT提供构件，并且任何M2M设备、网关或服务平台可以是IoT/WoT以及IoT/WoT服务层等的组件。

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

如图4A中所示，M2M/IoT/WoT通信系统10可以包括基础架构域和场域。基础架构域指代端到端M2M部署的网络侧，并且场域指代区域网络，通常在M2M网关后面。场域包括M2M网关14——诸如具有代理的SCS和终端设备18——诸如UE设备。将了解的是，可以按需在M2M/IoT/WoT通信系统10中包括任何数目的M2M网关设备14和M2M终端设备18。M2M网关设备14和M2M终端设备18中的每一个被配置成经由通信网络12或直接无线电链路来传送和接收信号。M2M网关设备14允许无线M2M设备——例如蜂窝和非蜂窝设备以及例如PLC的固定网络M2M设备——通过运营者网络——诸如通信网络12或直接无线电链路——来通信。例如，M2M设备18可以收集数据并且经由通信网络12或直接无线电链路将该数据发送到M2M应用20或M2M设备18。M2M设备18也可以从M2M应用20或M2M设备18接收数据。另外，可以经由M2M服务层22向M2M应用20发送数据和信号并且从M2M应用20接收数据和信号，如在下面所描述的。在一个实施例中，服务层22可以是PCE。M2M设备18和网关14可以例如经由包括例如蜂窝、WLAN、WPAN——例如Zigbee、6LoWPAN、蓝牙、直接无线电链路、和有线线路的各种网络进行通信。

参考图4B，场域中所图示的M2M服务层22为M2M应用20、M2M2网关设备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实现在web服务器中、在蜂窝核心网络中、在云中等。在一个实施例中，可以将协商服务包括在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’可以由一个或多个服务器、计算机、例如云/计算/存储群等的虚拟机等来实现。

还参考图4B，M2M服务层22和22’提供多种多样的应用和垂直元(vertical)可充分利用(leverage)的服务递送能力的核心集合。这些服务能力使得M2M应用20和20’能够与设备交互并且执行诸如数据收集、数据分析、设备管理、安全、计费、服务/设备发现、服务的协商等的功能。基本上，这些服务能力使应用免于实现这些功能的负担，由此简化应用开发并且减少成本和上市时间。服务层22和22’也使得M2M应用20和20’能够通过各个网络12和12’与服务层22和22’提供的服务结合来通信。

M2M应用20和20’可以包括各种行业中的应用，行业诸如但不限于运输、保健、联网家庭、能源管理、资产跟踪、以及安全和监督。如上面所提及的，跨系统的设备、网关、和其它服务器运行的M2M服务层支持诸如例如数据收集、设备管理、安全、计费、位置跟踪/地理围栏、设备/服务发现、以及遗留(legacy)系统集成的功能，并且将这些功能作为服务提供给M2M应用20和20’。而且，M2M服务层也可以被配置成与诸如如本申请中所讨论的且在附图中所图示的UE、SCS和MME的其它设备对接。

像本申请中所讨论来动态地请求服务的方法可以作为服务层的一部分被实现。服务层是通过一组应用编程接口(API)和底层联网接口来支持增值服务能力的软件中间件层。ETSI M2M和oneM2M两者使用可以包含控制并协调UE PSM模式的此方法的服务层。ETSIM2M的服务层被称为服务能力层(SCL)。SCL可以被实现在M2M设备内(在该处它被称为设备SCL(DSCL))、网关内(在该处它被称为网关SCL(GSCL))和/或网络节点内(在该处它被称为网络SCL(NSCL))内。OneM2M服务层支持一组公共服务功能(CSF)，例如服务能力。一个或多个特定类型的CSF的集合的实例化被称为公共服务实体(CSE)，诸如可以被托管在不同类型的网络节点——例如基础架构节点、中间节点、专用节点——上的SCS。另外，如本申请中所描述的在协商者与受协商者之间协商服务的方法可作为根据本申请来使用面向服务架构(SOA)和/或面向资源架构(ROA)来动态地请求服务的M2M网络的一部分被实现。

图4C是示例M2M设备30——诸如例如M2M终端设备18或M2M网关设备14——的系统图。如图4C中所示，M2M设备30可以包括处理器32、收发器34、发射/接收元件36、扬声器/麦克风38、小键盘40、显示器/触摸板/指示器42、非可移动存储器44、可移动存储器46、电源48、全球定位系统(GPS)芯片组50、和其它外围设备52。将了解的是，M2M设备40可以在保持与实施例一致的同时包括上述元件的任何子组合。此设备可以是将所公开的系统和方法用于感觉数据(sensory data)的嵌入式语义命名的设备。也可以与其它设备一起采用M2M设备30，所述其它设备例如包括如本申请中所描述的且如附图中所图示的LLN设备、骨干路由器和PCE。

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

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

此外，尽管发射/接收元件36在图4C中被描绘为单个元件，然而M2M设备30可以包括任何数目的发射/接收元件36。更具体地，M2M设备30可以采用MIMO技术。因此，在一个实施例中，M2M设备30可以包括两个或更多个发射/接收元件36——例如多个天线——以用于发射和接收无线信号。

收发器34可以被配置成对将由发射/接收元件36发射的信号进行调制并且对由发射/接收元件36接收到的信号进行解调。如上面所指出的，M2M设备30可以具有多模式能力。因此，例如，收发器34可以包括用于使得M2M设备30能够经由多个RAT——诸如UTRA和IEEE802.11——通信的多个收发器。

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

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

处理器32也可以耦合到GPS芯片组50，所述GPS芯片组50被配置成提供与M2M设备30的当前位置有关的位置信息，例如，经度和纬度。将了解的是，M2M设备30可以在保持与实施例一致的同时通过任何合适的位置确定方法来获取位置信息。

处理器32还可以耦合到其它外围设备52，所述其它外围设备52可以包括提供附加特征、功能性和/或有线或无线连接性的一个或多个软件和/或硬件模块。例如，外围设备52可以包括加速度计、电子罗盘、卫星收发器、传感器、数码相机(针对相片或视频)、通用串行总线(USB)端口、振动设备、电视收发器、免提头戴式送受话器、模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、互联网浏览器等。

图4D是例如可以实现图4A和图4B的M2M服务平台22的示例性计算系统90的框图。计算系统90可以包括计算机或服务器并且可以主要通过计算机可读指令来控制，所述计算机可读指令可以处于软件形式，而无论这种软件在何处或通过什么方式被存储或者访问。可以在中央处理单元(CPU)91内执行这样的计算机可读指令以使得计算系统90进行工作。在许多已知的工作站、服务器、和个人计算机中，中央处理单元91由被称作微处理器的单芯片CPU实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是区别于主CPU 91的执行附加功能或者协助CPU 91的可选处理器。CPU 91和/或协处理器81可以接收、生成、和处理与用于嵌入式语义命名的所公开系统和方法有关的数据，诸如利用嵌入式语义名称对感觉数据的查询。

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

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

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

由显示控制器96所控制的显示器86用于显示由计算系统90生成的视觉输出。这样的视觉输出可以包括文本、图形、动画图形、和视频。显示器86可以用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器、或触摸面板来实现。显示控制器96包括生成被发送到显示器86的视频信号所需要的电子组件。显示器86可以使用嵌入式语义名称来将在文件或文件夹中显示感觉数据。另外，计算系统90可以包含网络适配器97，所述网络适配器97可以用于将计算系统90连接到外部通信网络，诸如图4A和图4B的网络12。

根据本申请的一个方面，NGS使得M2M实体能够以更多的灵活性来动态地且有效率地请求服务。例如，图5A图示NGS可如何支持三个场景。NGS驻留在M2M设备和M2M服务器两者中以作为其服务层的新功能。在示出为“场景1”的示例性实施例中，M2M设备的NGS与M2M服务器的NGS交互以履行它们之间的服务协商。在示出为“场景2”的另一示例性实施例中，M2MApp A(或App B)与M2M服务器的NGS对话以协商由M2M App A(或App B)请求的服务。在示出为“场景3”的另外示例性实施例中，M2M App A和M2M App B经由M2M服务器与彼此协商服务。即，两个应用与M2M服务器的NGS对话，所述NGS进而帮助两个应用来执行服务协商。

在一个实施例中，如例如图5B中所示的图形用户界面(GUI)可用于在M2M设备、网关或服务器处配置/显示协商策略。例如，GUI可以包括包含用于显示协商策略的配置的文本框的区域。GUI也可以包括包含用于显示协商策略和结果的文本框的区域。在一个示例性实施例中，用户可经由触摸屏接口与GUI交互。

针对单独的协商请求的程序

根据一个实施例，图6图示针对单独的协商请求的服务协商过程。图6中的步骤中的每一个通过罗马数字来表示。受协商者A向协商者指示或者通知可协商服务。这里，可协商服务在其特征或配置可被动态地协商并且提供给不同的M2M实体的情况下被定义为任何服务。例如，如果可动态地协商和分配不同的M2M设备的存储大小和计费率，则由M2M服务器提供的数据管理服务是可协商的。然而，如果每个M2M设备总是需要使用相同的注册服务来与M2M服务器相关联，则由M2M服务器提供的注册服务可以不是可协商的。

协商者与受协商者A一起进行所提出的协商过程。在一个实施例中协商者可以协商一组服务。在另一实施例中，协商者可以协商特定服务的特征。根据此协商过程将存在两个结果：1)协商者和受协商者A达成一致；或者2)受协商者A无法满足协商者的要求并且推荐另一受协商者，例如，受协商者B。作为协商过程的一部分，协商者可以由受协商者A可选地认证，并且可选地，受协商者A可以由协商者认证。作为认证过程的一部分，可以使用预配置的凭证来对协商者和受协商者A进行认证。可以提供附加凭证，例如用于消息认证/完整性保护的密钥，其可以在协商者与受协商者A之间的将来消息交换期间被用于认证目的。确保密钥由协商者和/或受协商者拥有可以是一种形式的隐式认证。可选地，可以向协商者备置可用于访问所协商服务的授权凭证。

根据上面所讨论的替选实施例，如果协商者未与受协商者A达成一致，则它可以与如由受协商者A推荐的另一受协商者B执行协商。与协商者与受协商者A之间的认证过程或可选的互相认证过程类似，可以在协商者与受协商者B之间执行认证和授权过程。

图7中的步骤中的每一个通过罗马数字来表示。例如，在步骤0-1中，协商者向受协商者A发出“关于可协商服务的订阅”。结果，协商者将在服务变得可协商的情况下在步骤0-2中从受协商者A接收自动通知。这意指可动态地请求、改变、和/或配置其部分或全体特征/功能性。协商者可以在此步骤中包括各种订阅准则，诸如目标服务的列表。订阅准则也可以包括此刻可能不可协商的特征。替选地，协商者可向受协商者发送特定消息以例如使用RESTful RETRIEVE操作来发现或者检索受协商者A处的可协商服务的列表。因此，受协商者A将以它提供的可协商服务的列表来对协商者作出响应。

在某个稍后的实例处，如果其服务中的任一个在步骤0-1中变得可协商并且该变化满足订阅准则，则受协商者A向协商者发送“关于可协商服务的通知”消息。此消息的目的是向协商者通知受协商者A处的可协商服务的列表。此消息可以包含以下信息：

ListOfNegotiableService(可协商服务列表)：它包含每个可协商服务的名称、标识符、和/或描述，例如，ServiceID。对于每个可协商服务，受协商者A可以指示服务的哪些特征是可协商的并且该服务及其特征将有多久是可用的。受协商者A也可以针对每个可协商服务指定来自协商者的期望输入。

接下来，在步骤1中，协商者向受协商者A发送用于发起协商的“协商请求”消息。此消息可以包含以下信息：

ServiceID：待与受协商者A协商的服务的名称、标识符和/或描述。对于待协商的每个服务，协商者可以显式地请求对此服务的一个或多于一个的特征协商。协商者将能够从步骤0-2知道此信息。例如，ServiceID可以指示协商者想要获取更多的或更快的存储。

InputForMakeSuggestion(用于作出建议的输入)：协商者提供将由受协商者A充分利用来在步骤2中作出建议的必要输入。基本上，在此步骤中，受协商者A使用此参数来对照每个协商策略中的“条件(Condition)”参数进行比较以检查每个协商策略的适用性。协商者将能够从步骤0-2知道应该提供哪些输入信息。例如，如果Service ID指示协商者想要获取更多的和/或更快的存储，则InputForMakeSuggestion ID可以指示需要多少存储或者需要具有什么访问速度的存储。

ProposedSuggestions(提出的建议)：协商者可以向受协商者A提出某些建议，这可有助于简化受协商者A处的操作并且加快协商过程。基本上，ProposedSuggestions参数具有与维护在受协商者A处的每个协商策略中的“Result(结果)”参数相同的意义。ProposedSuggestions表示协商者将将其视为可接受的服务的示例。

然后在步骤2中，受协商者A取来自步骤1的信息作为输入以基于其它的本地策略作出建议。此步骤的输出是待在步骤3中发送到协商者的OfferedSuggestions(所提供的建议)。图7提供受协商者如何可以着手作出这些建议的程序。注意，受协商者A可以简单地接受来自协商者的ProposedSuggestions，而无需检查其策略或是否不存在任何适用的策略。

接下来，在步骤3中，受协商者A向协商者发送“协商响应”消息。此消息包含OfferedSuggestions。此参数可以包括给协商者的多个建议，或者向另一受协商者B简单地指示当前执行的协商回合的数目是否超过受协商者A处的预配置的阈值。注意，受协商者A和B可以驻留在同一服务域中。受协商者A也可以在它知道的情况下指示受协商者B处的ListOfNegotiableServices，例如，受协商者A和受协商者B可以在早期执行步骤0-1和步骤0-2并且知道彼此的可协商服务。如果OfferedSuggestions仅包含另一受协商者B，则协商者将暂停当前协商并且直接地与受协商者B开始新协商过程。在这种情况下，将跳过步骤4、步骤5和步骤6。

在接收到“协商响应”消息之后，协商者可以在它对OfferedSuggestions不满意的情况下重复步骤1以开始另一协商回合。否则，协商者在它对包含在OfferedSuggestions中的某些建议满意的情况下进行步骤4。在所重复的步骤1中，协商者可以为ServiceID、InputForMakeSuggestion和ProposedSuggestions提交新参数值。

在步骤4中，协商者基于它维护的协商策略来从OfferedSuggestions中选择适当的建议。注意，协商者可以简单地选取所接收到的OfferedSuggestions，而无需检查其策略或是否不存在任何适用的策略。在步骤5中，协商者向受协商者A发送“协商确认”消息。此消息包含来自步骤4的SelectedSuggestions(所选择的建议)和ServiceID。ServiceID能与步骤1中的ServiceID相同或者是步骤1中的ServiceID的子集。在步骤6中，受协商者A可以向协商者发送“确收(Acknowledgement)”消息。结果，协商者和受协商者A关于正在协商的服务达成一致。协商者可以为待重复的协商回合——即所重复的步骤1、2、和3——的最大数目设定阈值。替选地，受协商者A可以在重复的请求——即步骤1——的数目大于预配置的阈值的情况下拒绝协商者的请求。当执行的协商回合的数目超过此阈值时或者在在协商者与受协商者A(或B)之间仍然未达成任何一致的情况下，协商者可以停止协商过程或者改变其协商策略。根据另一实施例，设想了在用户正在作出确定的情况下不采用策略。

图7图示受协商者可以如何作出建议，例如，图6中的步骤2。受协商者使用基于策略的途径来作出建议。即，受协商者为所有可协商服务维护某些协商策略。每个协商策略可以具有以下信息或参数：

ServiceID：指示此协商策略适用于的服务的名称、标识符、和/或描述。

Condition：指示可应用此协商策略的情形。

Results：指示待在满足“Condition”的情况下作出的建议。

Negotiator(协商者)：指示此协商策略适用于的协商者的列表。在表1中给出了策略示例。作为示例，充当受协商者的M2M服务器可以维护这些策略以提供更灵活的设备管理服务。这些策略可由M2M服务器自身或者由特殊管理员应用来创建。

表1

以下步骤是受协商者作出建议所需的。受协商者取所接收到的“协商请求”中的参数值作为输入以与它的本地协商策略进行比较以获得所有潜在建议。如果策略是适用的，例如，“InputForMakeSuggestion”和策略中的“Condition”匹配，则策略的“Results”将是潜在建议。设想了尽管在图7中检查策略候选，然而受协商者可以可选地检查一定数目的策略候选。图7中的步骤中的每一个通过罗马数字来表示。

在步骤1中，受协商者取所接收到“协商请求”消息作为输入。注意，此消息包含三个参数：ServiceID、InputForMakeSuggestion、和ProposedSuggestions。在步骤2中，受协商者使用“ServiceID”来针对当前“协商请求”从它的本地协商策略数据库中定位策略候选。本地策略在其“ServiceID”涵盖包含在“协商请求”中的“ServiceID”的情况下变成策略候选。受协商者可以使用“Negotiator”信息来对策略进行过滤并且使策略候选列表变得更准确。此步骤的输出是包含潜在地适用于所接收到的“协商请求”的某些策略的策略候选集合。策略可以规定受协商者是否基于预备置的凭证对协商者进行认证。协商者可以可选地以类似方式对受协商者进行认证。

根据步骤3，受协商者检查是否在步骤2中找到任何策略候选。如果是，则可移动到步骤4；否则，前往步骤13。在步骤4中，受协商者将CurrentPolicy(当前策略)设定为如步骤2中所发现的策略候选集合中的第一策略。然后，将OfferedSuggestions设定为空。在步骤5中，受协商者检查CurrentPolicy，关于其对当前“协商请求”的适用性作出决策。在步骤6中，作出CurrentPolicy是否适用的检查。如果是这样的话，则受协商者前往步骤7以作出建议。否则，受协商者移动到步骤9以检查下一个策略，若任何策略可用。例如，候选策略可能变为过期或者对协商者来说是不允许的。

根据步骤7，受协商者基于CurrentPolicy作出建议。在步骤7.1中，NGS将InputForMakeSuggestion与CurrentPolicy的“Condition”进行比较。如果两者彼此匹配，则将应用CurrentPolicy；否则，CurrentPolicy对作出建议没有影响。“Condition”可以包含与受协商者的本地场境信息有关的某些信息。在这种情况下，受协商者也可以对照“Condition”来检查它的当前场境信息。

在步骤7.2中，将挑选CurrentPolicy的“Results”作为newSuggestions(新建议)。在步骤7.3中，将根据函数f(OfferedSuggestions,newSuggestion)来更新OfferedSuggestions，所述函数能简单地将newSuggestions添加到OfferedSuggestions。在步骤7.4中，不存在对OfferedSuggestions的改变。

接下来，在步骤8中，受协商者检查OfferedSuggestions是否包含来自协商者的“ProposedSuggestions”。如果是，则ProposedSuggestions将被设定为“OfferedSuggestions”(步骤13)。OfferedSuggestions和ProposedSuggestions的交集将被选取为针对协商者的最终OfferedSuggestions。

作出建议的过程结束。如果否，则步骤9检查其它策略候选。受协商者可以简单地忽视协商者的ProposedSuggestions。

在步骤9中，受协商者检查CurrentPolicy是否是策略候选集合中的最后策略。如果否，则策略候选集合中的下一个策略将被选取为CurrentPolicy(步骤10)。然后，过程回到步骤5。

如果是，则作出OfferedSuggestions是否为空的检查。如果否，则输出是所提供的建议(步骤12)。如果是，则受协商者发现策略中没有策略适用于所接收到的“协商请求”并且可以向协商者推荐另一受协商者(步骤14)。

在协商者处选择建议

图8图示由协商者进行的选择建议的细节。这与图6的步骤4有关。在本公开中提出了协商者使用基于策略的途径来选择建议。基本上，协商者维护某些协商策略。每个协商策略可以具有以下信息或参数：

ServiceID：指示此协商策略适用于的服务的名称、标识符、和/或描述。

Condition：指示可应用此协商策略的情形。例如，条件可以包括或者指示正在协商的服务使用什么协议。

Results：指示在满足“Condition”的情况下选择的建议。

Negotiatee(受协商者)：指示此协商策略适用于的受协商者的列表。

在表2中给出了几个策略示例。作为示例，作为协商者的M2M设备可以维护这些策略以请求更灵活的设备管理服务。这些策略可由M2M设备上的应用或者由特殊管理员应用来创建。协商者也可使用这些策略来通过遵循上面所讨论的类似程序来获得ProposedSuggestions。

表2

在图8中以下步骤是用于协商者选择建议所需的。协商者取所接收到的“协商响应”中的参数值作为输入以与其它的本地协商策略进行比较来选择适当的建议。如果策略是适用的，即“InputForSelectSuggestion(用于选择建议的输入)”和策略中的“Condition”匹配，则策略的“Results”将是潜在SelectedSuggestions。虽然在图8中检查所有策略候选，但是协商者可以可选地仅检查一定数目的策略候选。

在步骤1中，协商者取以下参数作为输入：

在来自受协商者的“协商响应”消息中接收到的ServiceID。

在来自受协商者的“协商响应”消息中接收到的OfferedSuggestions。

作为由协商者确定和维护的本地参数的InputForSelectSuggestion。注意，此参数是依赖于策略的。对于表2中的策略，InputForSelectSuggestion将是“待管理的设备的数目”。协商者使用此参数来对照每个策略候选的“Condition”进行比较以确定并选择适当的建议。

接下来在步骤2中，协商者使用“ServiceID”来从其本地协商策略数据库中定位策略候选。本地策略在其“ServiceID”涵盖步骤1中的“ServiceID”的情况下变成策略候选。此外，协商者可以使用“Negotiatee”信息来滤除更多不相关的策略。此步骤的输出是包含潜在地适用于所接收到的“协商响应”的某些策略的策略候选集合。

在步骤3中，协商者检查是否在步骤2中找到任何策略候选。如果是，则程序移动到步骤4，其中协商者将CurrentPolicy设定为步骤2中所发现的策略候选集合中的第一策略。然后，将SelectedSuggestions设定为空集合。否则，转向步骤11。

在步骤5中，协商者检查关于其对当前“协商响应”的适用性的CurrentPolicy。在步骤6中，如果CurrentPolicy是适用的，则协商者前往步骤7以基于CurrentPolicy来选择建议。

在步骤7.1中，NGS将InputForSelectSuggestion与CurrentPolicy的“Condition”进行比较。如果两者彼此匹配，则将应用CurrentPolicy。否则，CurrentPolicy对选择建议没有影响。“Condition”可以包含与协商者的本地场境信息有关的某些信息。在这种情况下，协商者也可以对照“Condition”来检查它的当前场境信息。在步骤7.2中，CurrentPolicy的“Results”将被选取为NewSelections(新选择)。在步骤7.3中，将根据函数f(NewSelections,SelectedSuggestions,OfferedSuggestions)来更新SelectedSuggestions，所述函数能简单地将NewSelections和OfferedSuggestions的交集添加到当前SelectedSuggestions。在步骤7.4中，不存在对SelectedSuggestions的改变。

如果来自步骤6的回答为否，则协商者移动到步骤8以检查下一个策略，若存在任何策略)。例如，候选策略可能过期或者对发送了“协商响应”的受协商者来说是不允许的。在步骤8中，协商者检查CurrentPolicy是否是策略候选集合中的最后策略。如果否，则程序移动到策略候选集合中的步骤9，其中下一个策略将被选取为CurrentPolicy。然后，它回到步骤5以检查CurrentPolicy。

如果来自步骤8的回答为是，则转向步骤10，其中协商者检查SelectedSuggestions是否为空。如果是，则程序移动到步骤12并且协商者发现策略中没有策略适用于所接收到的“协商响应”。SelectedSuggestions将是空的。协商者可以开始新协商回合。否则，如果来自步骤10的回答为否，则转向步骤11。这里，协商者在检查所有策略候选之后来到此步骤并且输出SelectedSuggestions。由协商者选取的SelectedSuggestions可以不是OfferedSuggestion的子集，即，在SelectedSuggestions与OfferedSuggestion之间不存在任何交集。在这种情况下，协商者将恢复重新发送新“协商请求”，即，图6中的步骤1，并且SelectedSuggestions会作为ProposedSuggestions被包含在新“协商请求”中。

针对多个协商请求的程序

如图6中所图示的，受协商者(A或B)独立地处理每个协商请求或协商者。实际上，通过联合地考虑来自不同协商者的多个请求，受协商者可以尤其针对多个协商者可以在逻辑上彼此相关联的场景而向协商者作出更好的建议，例如，从同一位置请求相同类型的服务、具有相同类型的设备、过去具有类似的协商历史和行为等。在一个示例中，能联合地考虑具有相同ServiceID的协商请求。受协商者可以缓存所接收到的协商请求以便执行这样的组合。受协商者可能已配置了仅当多个请求被联合地考虑时才适用的特殊策略。出于此目的，在图9中开发了针对基本服务协商的替选程序，其中受协商者通过联合地考虑来自两个协商者A和B的协商请求来作出建议。图9中的步骤中的每一个通过罗马标号来表示。

在步骤1A中，协商者A向受协商者发送“协商请求”。在步骤1B中，协商者B向受协商者发送“协商请求”。在步骤2中，受协商者考虑来自协商者A和B二者的请求来作出建议。受协商者可以首先针对协商者A和协商者B独立地进行图7中的程序以得到OfferedSuggestions的两个值。然后，最终OfferedSuggestions将是这两个值的交集。如果不存在交集，则受协商者可以只简单地建议两个OfferedSuggestions值(一个针对协商者A并且另一个针对协商者B)。

如果不存在交集，则受协商者可以取这两个OfferedSuggestions中的一个并且将它发送到两个协商者。如果不存在交集，则受协商者可以通知两个协商者改变它们的下一次协商请求，使得下一次有可能达成两个OfferedSuggestions的交集。

替选地，受协商者可以首先定位适用于协商者A和协商者B两者的策略。然后，它根据图7中的相同程序基于这些策略来作出建议。针对协商者A和协商者B的OfferedSuggestions取决于受协商者使用来确定OfferedSuggestions的策略而很可能不同。

在步骤3A中，受协商者向协商者A发送“协商响应”。在步骤3B中，受协商者向协商者B发送“协商响应”。

在步骤4A中，协商者A从步骤3A中的OfferedSuggestions中选择建议。在步骤4B中，协商者B从步骤3B中的OfferedSuggestions中选择建议。在步骤5A中。协商者A向受协商者发送“协商确认”。在步骤5B中，协商者B向受协商者发送“协商确认”。在步骤6A中，受协商者向协商者A发送“确收”。在步骤6B中，受协商者向协商者B发送“确收”。

基于代理程序的服务协商

用于作出建议或者选择建议的过程对受约束M2M设备来说可能太繁重。为了解决此问题，描述了基于代理程序的服务协商，其中协商代理程序代表受协商者帮助作出建议和/或代表协商者选择建议。协商代理程序也可被从一个代理程序委托给另一个代理程序。根据图10和图11，可在协商者与协商代理程序之间使用如图6中所示的步骤0-1和步骤0-2，使得协商者可得到关于协商代理程序可应对的可协商服务的列表的自动通知。

在透明模式下，协商代理程序不作出建议或者选择建议，但是帮助协商者找到适当的受协商者，例如，将请求转发到其列表适合请求的受协商者或者转发到具有轻负载的受协商者，并且在协商者与受协商者之间简单地转发协商相关消息。如图10中所示引入以下步骤。

在步骤1中，受协商者向协商代理程序发送“对协商请求的订阅”。该消息基本上告诉协商者代理程序受协商者能够对由ServiceID标示的服务执行协商。在步骤2中：协商代理程序向受协商者发送“响应”。对于每个服务，协商代理程序将维护对该服务感兴趣并且可为它提供协商的受协商者的列表。然后在步骤3中，协商者向协商代理程序发送“协商请求”。该步骤与图6中的步骤1相同。在步骤4中，协商代理程序使用包含在“协商请求”中的“ServiceID”来为所接收到的“协商请求”找到适当的受协商者。

根据步骤5，协商代理程序向对应的受协商者发送“通知”以作为对步骤1中的订阅的响应。此通知实际上将转发“协商请求”。在步骤6中，受协商者作出建议。进一步在步骤7中，受协商者经由协商代理程序向协商者发送“协商响应”。在一个实施例中，协商代理程序对照由协商者所设定的预备置的策略来检查所提供的建议。

协商者在步骤8中选择建议。在步骤9中，协商者经由协商代理程序向受协商者发送“协商确认”。在步骤10中，受协商者经由协商代理程序向协商者发送“确收”。

步骤1和步骤2可以发生一次或多次，因为可能存在多个受协商者。步骤1和2的每个集合是针对单独的受协商者的。步骤5、步骤6和步骤7可以发生一次或多次，因为可能存在多个受协商者。步骤5、步骤6和步骤7的每个集合是针对单独的受协商者的。

根据另一实施例，图11图示协商代理程序充当受协商者的代理的场景。在步骤1中，受协商者向协商代理程序发送“协商代理请求”。受协商者可以在此步骤中将其协商策略传递给协商代理程序。受协商者可以使用分离的程序来在其协商代理程序处创建其协商策略。

在步骤2中，协商代理程序向受协商者发送“协商代理响应”。注意，可以跳过此步骤并且步骤9将是对受协商者的最终响应。步骤1和2在受协商者已经被注册到协商代理程序或者与协商代理程序相关联的情况下可能不是需要的，并且在缺省情况下，协商代理程序将针对受协商者执行代理功能。可以通过受协商者与协商代理程序之间的发现和关联阶段来继续进行步骤1和2。作为关联阶段的一部分，协商代理程序和受协商者可以被备置有或者导出可以被用于稍后阶段处的认证的认证凭证。

接下来在步骤3中，协商者向协商代理程序发送“协商请求”。此步骤与图6中的步骤1相同。在发送“协商请求”消息之前协商者可以由协商代理程序来认证，或者替选地，协商者和受协商者可以基于建立的凭证来互相对彼此进行认证。替选地，可以在“协商请求”阶段期间执行认证/互相认证，其中使用密码程序将拥有正确凭证验证为“协商请求”消息的一部分。

在步骤4中，协商代理程序根据步骤1中发送的协商策略来代表受协商者作出建议。此步骤与图6中的步骤2相同。在步骤5中，协商代理程序向协商者发送“协商响应”。此步骤与图6中的步骤3相同。如果协商者对包含在步骤5中的OfferedSuggestions不满意，则可以重复步骤3、步骤4、和步骤5。

根据步骤6，协商者选择适当的建议。此步骤与图6中的步骤4相同。在步骤7中，协商者向协商代理程序发送“协商确认”。此步骤与图6中的步骤5相同。在步骤8中，协商代理程序向协商者发送“确收”。此步骤与图6中的步骤6相同。接下来，在步骤9中，协商代理程序向受协商者发送“协商通知”。此消息可以包含以下信息：(i)协商者的名称或标识符；(ii)正在协商的服务的名称、标识符、和/或描述；以及(iii)协商者的所选择的建议。进一步在步骤10中，受协商者向协商代理程序发送“确收”。

注意到，步骤1和步骤2可以发生多次，因为可能存在多个受协商者。步骤1和步骤2的每个集合是针对单独的受协商者的。同样地步骤9和步骤10可以发生多次，因为可能存在多个受协商者。步骤9和步骤10的每个集合是针对单独的受协商者的。

根据另一实施例，图12图示协商代理程序充当协商者的代理的场景，其中认证和授权功能被添加到所涉及的实体。在步骤1中，协商者向协商代理程序发送“协商代理请求”。协商者可以在此步骤处将其协商策略传递给协商代理程序。协商者可以使用分离的程序来在其协商代理程序处创建其协商策略。协商者可以请求某些安全机制和功能以便实现认证、授权和安全通信。替选地，对安全功能的设立的请求可以由协商代理程序在步骤2处执行。可以通过安全通信信道发送协商请求。

在步骤2中，协商代理程序向协商者发送“协商代理响应”。注意，可以跳过此步骤并且步骤10将是对协商者的最终响应。步骤1和2在协商者已经被注册到协商代理程序或者与协商代理程序相关联的情况下可能不是需要的，并且在缺省情况下，协商代理程序将针对协商者执行代理功能。

在步骤3中，协商者向协商代理程序发送“协商请求”。此步骤与图6中的步骤1类似。此外，协商者和协商代理程序可以互相对彼此进行认证。可选地，作为协商请求消息的一部分，协商者可以发送由受协商者或第三方实体备置给协商者的基于会话的授权参数。

在步骤4中：协商代理程序将协商请求连同授权参数一起转发到受协商者。从受协商者的观点看，它感觉此消息来自协商代理程序。在步骤5中，基于受协商者验证授权参数，受协商者然后作出建议。此步骤与图6中的步骤2类似。步骤6与图6中的步骤3类似。如果协商者代理程序对包含在步骤6中的OfferedSuggestions不满意，则可以重复步骤4、步骤5和步骤6。

根据步骤7，协商代理程序选择适当的建议。此步骤与图6中的步骤4类似。在步骤8中，协商代理程序向受协商者发送“协商确认”。此步骤与图6中的步骤5类似。此后在步骤9中，受协商者向协商代理程序发送“确收”。此步骤与图6中的步骤6相同。接下来在步骤10中，协商代理程序向协商者发送“协商响应”。此消息与图6中的步骤3类似。进一步在步骤11中，协商者向协商代理程序发送“确收”。上面所描述的安全机制(认证、授权和安全通信)和功能可以被使用并且适用于可能需要第三方信任的其它实施例。

根据如图13中所图示的另外的实施例，协商代理程序可以组合多个协商请求并且将组合的协商请求发送到受协商者以改进协商效率。尽管图13示出两个协商者，然而协商代理程序可组合来自多于两个的协商者的协商请求。请注意，图13未示出协商者与协商代理程序之间的“协商代理请求&响应”，这实际上与图12相同。以下步骤是针对图13而描述的。

在步骤1中，协商者A和B分别向协商代理程序发送协商请求。在步骤2中，协商代理程序通过将这两个协商请求放置在被发送到受协商者的所组合新协商请求中来组合两者。在步骤3中，受协商者作出建议。此步骤与图6中的步骤2类似。在步骤4中，受协商者向协商代理程序发送“协商响应”。此步骤与图6中的步骤3类似。接下来在步骤5中，协商代理程序代表两个协商者来选择建议。此步骤与图6中的步骤4相同。随后在步骤6中，协商代理程序向受协商者发送“协商确认”。此步骤与图6中的步骤5类似。

在步骤7中，受协商者向协商代理程序发送“确收”。此步骤与图6中的步骤6相同。根据步骤8，协商代理程序将两个“协商响应”分别发送至协商者A和协商者B。此步骤与图6中的步骤10相同。然后在步骤9中，协商者A和协商者B分别向协商代理程序发送“确收”。此步骤与图6中的步骤11类似。虽然图13未示出多个受协商者，但是可对协商代理程序与另一受协商者之间的交互应用步骤2至步骤7。

根据另一实施例，协商代理程序可以变得过载并且进而它可将其功能委托给另一协商代理程序。这样的代理程序委托能由协商者/受协商者(在协商者/受协商者能够知道当前协商代理程序需要被委托和/或能够确定新协商代理程序的情况下)发起或者由当前协商代理程序主动地发起。图14图示从当前协商代理程序A向新协商代理程序B的代理程序委托的程序。

根据步骤1，协商者(或受协商者)向当前协商代理程序A发送“代理程序委托请求”。此消息可以包括但不限于新协商代理程序B的地址、名称、和/或标识符。替选地，当前协商代理程序A可以为协商者/受协商者选取新协商代理程序。此步骤在代理程序委托由当前协商代理程序A主动地触发的情况下是可选的。

在步骤2中，当前协商代理程序A向新协商代理程序B发送“代理程序委托请求”。此消息可以包括但不限于以下信息：协商者/受协商者的地址、名称、和标识符。可用于验证当前协商代理程序A是否是协商者/受协商者的合法代理程序的认证信息。新协商代理程序B对协商者/受协商者生效的开始时间。新协商代理程序B充当协商者/受协商者的代理程序的持续时间。

在步骤3中，新协商代理程序B向当前协商代理程序A发送“代理程序委托响应”。如果新协商代理程序B拒绝委托请求，则将跳过以下步骤4和5并且代理程序委托不成功。根据步骤4，当前协商代理程序A向新协商代理程序B发送“协商场境传输”。此消息用于将诸如针对协商者/受协商者的协商策略的必要场境信息传输到新协商代理程序B。根据步骤5，新协商代理程序B向当前协商代理程序A发送“协商场境响应”。

接下来在步骤6中，当前协商代理程序A向协商者/受协商者发送“代理程序委托响应”。此消息可以包含以下信息：新协商代理程序B的地址、名称、和/或标识符。新协商代理程序B将充当协商者/受协商者的代理的开始时间和持续时间。进一步在步骤7中，协商者/受协商者使用如所描述的类似过程来与新协商代理程序B一起进行服务协商。

根据另一实施例，描述了用于协商者发起服务协商过程的各个触发器。例如，当M2M设备开始生成它可能不能够在本地存储所有数据的增加的数据量时，它可以发起与其M2M服务器协商过程以得到更多的存储。如果M2M设备发现它必须增加它上传数据的速率，则它可以再次与M2M服务器协商以请求对所存储的数据的更频繁的操作。

用于设备管理的M2M应用可以在新M2M设备被添加到系统中时开始与其M2M服务器协商以请求管理更多的M2M设备。M2M应用发现它自身与另一M2M应用之间的端到端延迟已增加。在一个示例性实施例中，通信由M2M服务器中继。M2M应用可能希望发起与M2M服务器的服务协商以减少用于将其请求消息缓存在M2M服务器处的时间。

可协商服务

公开了用于说明可在oneM2M架构的场境中协商哪些M2M服务并且以哪种方式协商的示例。基本上存在两个层级的服务协商：

在层级1中，M2M设备关于它需要使用的所期望的CSF而与M2M服务器协商。换言之，M2M设备可以请求使用由M2M服务器提供的CSF的子集。对于层级1服务协商，如图15中所示的16位CSF位图能由M2M设备充分利用来指示其偏好，并且由M2M服务器充分利用来指示所批准的CSF。每个位表示CSF并且最后四位被保留以用于将来使用。请注意，REG CSF是M2M设备必须选取以便使用其它CSF的缺省CSF。

在层级2中，M2M设备还可以关于每个单独的CSF的特征或功能性而与M2M服务器协商。对于层级2服务协商，每个CSF具有可被协商的不同的特征和功能性。例如，M2M设备可关于期望的DMG功能性而与M2M服务器协商，因为该M2M设备可能不需要使用由M2M服务器提供的所有DM功能性。在表3中给出了更多的示例和细节。与CSF位图的示例类似，图16图示CSF特征位图的示例，其中假定CSF具有M个特征并且需要M位，CSF的每个特征(例如，F1、F2)由一位来表示。

在场景1中，当M2M设备生成更多的数据时，它可以发起与M2M服务器的协商过程以得到更多的存储。稍后，如果M2M设备确定数据改变太快并且需要更频繁的数据更新，则它可以再次与M2M服务器协商以请求对所存储的数据的更频繁的操作。

表1

新CSF：协商服务(NGS)

图17示出用于基于当前oneM2M功能架构将所提出的协商服务实现为新CSF的示例性实施例。替选地，可将一些NGS功能作为DMG CSF的一部分来添加以执行可能在设备自举、设备固件上传等期间发生或者需要的设备管理相关协商。

在一个实施例中，可以将此NGS功能托管在由M2M节点——诸如M2M服务器、M2M网关、或M2M设备——托管的M2M服务层实例中。例如，NGS可以将单独的服务能力包括在M2M服务层实例内或者将其包括作为现有服务能力内的子功能。

如图18的实施例中所示，所提出的NGS CSF可驻留在MN-CSE、ASN-CSE、或IN-CSE中。NGS CSF将具有如上面所描述的协商者、协商代理程序、和/或受协商者的功能性。可以以下方式执行服务协商。

如果MN-CSE与IN-CSE直接地协商服务，则MN-CSE的NGS将是用于选择建议的协商者并且IN-CSE的NGS将是用于作出建议的受协商者。如果MN-CSE间接地经由IN-CSE与ASN-CSE协商服务，则MN-CSE的NGS将是用于选择建议的协商者。而且，IN-CSE的NGS将是透明模式下的协商代理程序。另外，ASN-CSE的NGS将是用于作出建议的受协商者。

如果IN-AE1经由IN-CSE间接地与MN-CSE协商服务，则IN-AE1将是协商者，IN-CSE的NGS将是用于选择建议的IN-AE1的协商代理程序，并且ASN-CSE的NGS将是用于作出建议的受协商者。

如果IN-AE2经由IN-CSE间接地与IN-AE1协商服务，则IN-AE2将是协商者，IN-CSE的NGS将是用于作出建议的IN-AE1和用于选择建议的IN-AE1两者的协商代理程序，并且IN-AE1将是受协商者。

图19示出ASN-CSE经由中间的MN-CSE与IN-CSE协商服务的另一示例性实施例。ASN-CSE的NGS将是协商者，MN-CSE的NGS将是协商代理程序，并且IN-CSE的NGS将是受协商者。

用于支持NGS CSF的新资源/属性

在另一实施例中，提出了用于支持NGS CSF服务的oneM2M资源结构增强功能。用于描述资源结构的oneM2M定义的图形表示是如下：(i)正方形框被用于资源和子资源；(ii)具有圆角的正方形框被用于属性；以及(iii)新资源<ngtn>。

<ngtn>资源被定义以供M2M实体发出协商请求并且接收/检索协商响应。每个<ngtn>资源对应于两个M2M实体之间的特定协商请求或响应。它维护如包含在如图6中所图示的协商请求和协商响应消息中的信息或参数。

<ngtn>具有如图20和表4中所示的几个属性和子资源。<ngtn>的父资源可以是<AE>、<CSEBase>、和/或<remoteCSE>。例如，IN-AE在其托管CSE——例如M2M服务器——上的其<AE>下创建<ngtn>资源，以发起与其托管CSE的协商。

例如，MN-CSE在其托管CSE——例如M2M服务器——上的其<remoteCSE>下创建<ngtn>，以发起与其托管CSE的协商。

替选地，来自IN-CSE和IN-AE的协商请求可全部紧接在它们的托管CSE下面创建。在这种情况下，<ngtn>将作为托管CSE的<CSEBase>的子资源被创建。

表4

根据甚至另一实施例，被称作<ngtnPolicy>的新资源——例如协商策略——用于指定1)受协商者(或其代理程序)如何基于该策略来作出建议，或者用于指定2)协商者(或其代理程序)如何基于该策略来选择建议。换言之，存在两种类型的策略：1)用于作出建议的策略和2)用于选择建议的策略。每个协商策略需要包含至少两条信息：Conditions和Results。即，如果满足“Conditions”，则“Results”将是策略的输出。因为存在两种类型的策略，所以“Results”可以是：1)待由受协商者或其代理程序作出的建议；或2)待由协商者或其代理程序选择的建议。

<ngtnPolicy>资源具有如图21和以下的表5中所示的几个属性和子资源。<ngtnPolicy>的父资源可以是<AE>、<CSEBase>、和/或<remoteCSE>。注意，在通过引用整体并入本文的oneM2M-TS-0001,oneM2M Functional Architecture-V1.1.0；August 2014中描述的内容中定义了<AE>、<CSEBase>、和<remoteCSE>。

表5

根据如下图22和表6中所示的另一个实施例，被称作“协商资源”(例如，<ngtnDelegation>)的新资源被提出以支持如本申请中上面所描述的协商委托代理程序功能。每个<ngtnDelegation>对应于协商代理程序委托请求。它可以是<AE>、<remoteCSE>、或<CSEBase>资源的子资源。

表6

新属性‘ngtnBroker’作为<AE>或<remoteCSE>资源的新属性被提出。注意，在通过引用整体并入本文的oneM2M-TS-0001,oneM2M Functional Architecture-V1.1.0；August2014中描述的内容中定义了<AE>、<CSEBase>、和<remoteCSE>。如果ngtnBroker是<AE>资源的属性，则它指示<AE>的协商代理程序。如果ngtnBroker是<remoteCSE>资源的属性，则它指示<remoteCSE>的协商代理程序。

属性	描述
		ngtnBroker	指示协商代理程序的名称、地址、和URI。

表7

CsfBitMap作为<AE>、<CSEBase>或<remoteCSE>资源的新属性被提出。注意，在通过引用整体并入本文的oneM2M-TS-0001,oneM2M Functional Architecture-V1.1.0；August 2014中描述了<AE>、<CSEBase>、和<remoteCSE>。如果csfBitMap是<AE>资源的属性，则它意指<AE>请求使用的CSF的列表和/或由<AE>的托管CSE所批准的CSF的列表。当AE向其托管CSE注册它自身时，AE可以将csfBitMap包含在应用注册请求消息中以指示它的期望CSF；进而，托管CSE可以返回批准的csfBitMap以指示所批准的CSF被分配给AE。

如果csfBitMap是<remoteCSE>资源的属性，则它意指<remoteCSE>请求使用的CSF的列表和/或由<remoteCSE>的托管CSE所批准的CSF的列表。当CSE向其托管CSE注册它自身时，CSE可以将csfBitMap包含在CSE注册请求消息中以指示它的期望CSF；进而，托管CSE可以返回批准的csfBitMap以指示所批准的CSF被分配给CSE。如果csfBitMap是<CSEBase>的属性，则它意指此CSE拥有的CSF的列表。

属性	描述
		csfBitMap	指示每个单独的CSF的状态

表8

用于支持NGS CSF的资源程序

下表9中所提供的协议被采用来创建<ngtn>资源。特别地，此程序将用于在托管CSE中创建特定<ngtn>资源。

表9

而且，表10中的协议将用于从现有<ngtn>资源中检索信息。

表10

下表11中的协议被采用来更新现有<ngtn>资源的信息。

表11

下表12中所提供的协议将用于删除现有<ngtn>资源。

表12

下表13中所提供的协议将用于在托管CSE上执行挂起协商请求<ngtn>。

表13

下表14中所提供的协议将用于在托管CSE中创建特定<ngtnPolicy>资源。

表14

下表15中所提供的协议将用于从现有<ngtnPolicy>资源中检索信息。

表15

下表16中所提供的协议将用于更新现有<ngtnPolicy>资源的信息。

表16

下表17中的协议将用于删除现有<ngtnPolicy>资源。

表17

下表18中的程序将用于在托管CSE中创建特定<ngtnDelegation>资源。

表18

下表19中的协议将用于从现有<ngtnDelegation>资源中检索信息。

表19

下表20中的协议将用于更新现有<ngtnDelegation>资源的信息。

表20

下表21中的协议将用于删除现有<ngtnDelegation>资源。

表21

下表22中的协议将用于在托管CSE上执行挂起协商代理程序委托请求<ngtnDelegation>。

表22

图23图示使用上面所描述的所提出的程序的服务协商的示例。每个步骤以例如001、002等的罗马数字格式提供。这里，MN-CSE是协商者，并且IN-CSE使受协商者。根据步骤1，MN-CSE发出CREATE请求。这与图6中的步骤1类似。接下来在步骤2中，IN-CSE处理CREATE请求。然后在步骤3中，IN-CSE向MN-CSE发送CREATE响应。此后，在步骤4中，MN-CSE发出特殊UPDATE请求以如上所述来执行所创建的<ngtn>。这与图6中的步骤1类似。随后在步骤5中，IN-CSE处理UPDATE请求以作出建议。这与图6中的步骤2类似。

在步骤6中IN-CSE向MN-CSE发送UPDATE响应。这与图6中的步骤3类似。在步骤7中，MN-CSE处理UPDATE响应以选择适当的建议。这与图6中的步骤4类似。然后在步骤8中，MN-CSE发出正常UPDATE请求以如上所述来更新<ngtn>/selectedSuggestions。这与图6中的步骤5类似。然后在步骤9中，IN-CSE处理UPDATE请求以确认所选择的建议。另外，在步骤10中：IN-CSE向MN-CSE发送UPDATE响应。这与图6中的步骤6类似。

图24图示如通过引用整体并入本文的oneM2M-TS-0007,oneM2M ServiceComponent Architecture-V-0.4.0(oneM2M服务组件架构)中所提供的oneM2M SoA架构中的提出的协商服务的实施例，其中协商服务作为新服务组件被插入。其它服务组件能通过Msc参考点来与协商服务进行通信。注意，NGS可被应用于Mca参考点并且此公开中的所提出的数据结构和消息也可被应用于SOA架构。

在根据本申请的一个适用的用例中，例如AT&T的M2M服务运营者部署由各种M2M服务器构成的智能传输M2M服务平台。每个M2M服务器为设备管理提供诸如DMG的一套服务。例如Hertz的汽车租赁公司已使用此平台来管理其车辆。现在，汽车公司想要将更多的新混合动力汽车投放到市场中。从设备管理观点看新混合动力汽车需要更多的诊断和监测功能。由于这个新要求和待管理的新汽车的数目，汽车公司的M2M应用关于所期望的DMG功能性——例如更高级的诊断功能、组设备管理、针对这些新汽车的更频繁的位置更新等——而与运营者协商。

在另一用例下例如Google的M2M服务运营者部署由云中的M2M服务器和客户家庭处的M2M网关——例如Google的NEST——构成的智能家庭M2M服务平台。M2M服务器和M2M网关两者为数据管理提供诸如DMR的一套服务。客户曾经使用M2M网关来在本地存储传感器数据，例如，来自安装在家里的相机。现在是夏令时间并且客户计划外出旅游并将离开家达一个月。客户需要经由他的智能电话并且比之前更频繁地访问相机数据。客户也想要在相机检测到任何异常的情况下从运营者的服务平台接收到自动通知。客户在他的智能电话上的M2M应用关于是否和如何存储/分析在云中而不是在家庭的M2M网关处的相机数据来与运营者的服务平台协商，以便满足他的新需要。要理解的是，可以以存储在M2M网络的节点(例如，服务器、网关、设备、或其它计算机系统)的存储器中并且在M2M网络的节点(例如，服务器、网关、设备或其它计算机系统)的处理器上执行的软件(即，计算机可执行指令)的形式实现NGS的功能性。

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

根据本申请的又一个方面，公开了用于存储计算机可读或可执行指令的非暂时性计算机可读或可执行存储介质。该介质可以包括诸如在根据图6至图14和图23的多个呼叫流程中上面所公开的一个或多个计算机可执行指令。计算机可执行指令可以被存储在存储器中并且由图4C和图4D中上面所公开的处理器来执行，并且被采用在包括M2M设备和服务器的设备中。在一个实施例中，公开了具有非暂时性存储器和可操作地耦合到其的处理器的计算机实现的UE，如上面图4C和图4D中所描述的。具体地，装置包括具有协商服务层的非暂时性存储器，所述非暂时性存储器具有存储在其上以用于协商服务属性的指令。

本申请的另一个方面描述计算机实现的联网的系统。该网络包括协商者和受协商者。协商者和受协商者中的每一个包括用于发送和接收数据的收发器。协商者和受协商者中的每一个也包括具有协商服务层的非暂时性存储器，所述非暂时性存储器具有存储在其上以用于协商服务层属性的指令。协商者和受协商者中的每一个也包括处理器，所述处理器可操作地耦合到非暂时性存储器，被配置成执行服务层属性的协商。根据一个实施例，协商者和受协商者的存储器包括从协商资源、策略资源、委托资源及其组合中选择的资源。

虽然已经就在目前被认为是特定方面的内容而描述了系统和方法，但是本申请未必限于所公开的方面。它旨在覆盖包括在权利要求书的精神和范围内的各种修改和类似布置，权利要求书的范围应当符合最广泛的解释，以便涵盖所有这样的修改和类似结构。本公开包括所附权利要求书中的的任何方面和所有方面。

Claims (22)

1.一种计算机实现的装置，包括：

非暂时性存储器，所述非暂时性存储器包括针对协商服务层而存储在其上以用于协商服务属性的指令；以及

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

审查从受协商者接收到的所述属性；

基于所审查的属性来向所述受协商者发送协商请求；以及

从所述受协商者接收提供的建议。

2.根据权利要求1所述的计算机实现的装置，其中，所述处理器还被配置成选择所提供的建议。

3.根据权利要求2所述的计算机实现的装置，其中，所述选择对照所述受协商者的预定协商策略而被检查。

4.根据权利要求1所述的计算机实现的装置，其中，发送所述协商请求的步骤是经由代理程序被发送到所述受协商者的。

5.根据权利要求4所述的计算机实现的装置，其中，接收所述提供的建议的步骤是经由所述代理程序从所述受协商者接收的。

6.根据权利要求1所述的计算机实现的装置，还包括：

显示器，所述显示器包括可操作地连接到所述存储器和所述处理器的图形用户界面，所述图形用户界面被配置成显示所述提供的建议。

7.根据权利要求1所述的计算机实现的装置，其中，所述显示器上的所述提供的建议包括从建议、要与另一受协商者协商的推荐、及其组合中选择的信息。

8.一种计算机实现的装置，包括：

非暂时性存储器，所述非暂时性存储器包括针对协商服务层而存储在其上以用于协商服务属性的指令；以及

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

从受协商者接收用于协商所述属性的策略；

从协商者接收协商所述属性的请求；以及

确定所述请求是否遵守所述受协商者策略的准则。

9.根据权利要求8所述的计算机实现的装置，其中，所述处理器还被配置成向所述协商者发送所提供的建议。

10.根据权利要求8所述的计算机实现的装置，其中

所述非暂时性存储器存储从公共属性、创建、检索、删除、更新、执行、标签、代理程序、类型、用于作出建议的输入、用于选择建议的输入、开始、状态、目标、引用、提供的建议、选择的建议、输出参数、订阅及其组合中选择的协商资源，并且

所述处理器采用所述协商资源来协商所述属性。

11.根据权利要求8所述的计算机实现的装置，其中

所述存储器存储从公共属性、标签、协商类型、协商者、受协商者、条件、结果、选择规则、订阅、及其组合中选择的策略资源，并且

所述处理器采用所述策略资源来协商所述属性。

12.根据权利要求8所述的计算机实现的装置，其中

所述存储器存储从公共属性、标签、客户端、当前协商代理程序、新协商代理程序、委托启用、开始时间、持续时间、结果、订阅、及其组合中选择的委托资源，并且

所述处理器采用所述委托资源来协商所述属性。

13.一种联网系统，包括：

计算机实现的协商者和计算机实现的受协商者，所述协商者和所述受协商者中的每一个包括：

收发器，所述收发器用于发送和接收数据；

具有协商服务层的非暂时性存储器，所述非暂时性存储器具有存储在其上以用于协商服务层属性的指令，以及

处理器，所述处理器可操作地耦合到所述非暂时性存储器，所述处理器被配置成执行所述服务层属性的协商。

14.根据权利要求13所述的联网的系统，其中，所述处理器被配置成执行以下操作的指令：

从受协商者接收用于协商所述属性的策略；

从协商者接收协商所述属性的请求；以及

确定所述请求是否遵守所述受协商者策略的准则。

15.根据权利要求13所述的联网的系统，其中

所述非暂时性存储器包括从协商资源、策略资源、委托资源及其组合中选择的资源。

16.一种计算机实现的方法，所述计算机实现的方法包括：

审查从受协商者接收到的可协商服务层属性；

基于所审查的属性来向所述受协商者发送协商请求；

从所述受协商者接收提供的建议；以及

选择所述提供的建议。

17.根据权利要求16所述的方法，其中

所接收到的提供的建议对照所述受协商者的预定协商策略被检查。

18.根据权利要求16所述的方法，其中

所述协商请求包括从服务id、用于作出建议的输入、提出的建议及其组合中选择的信息。

19.一种计算机实现的方法，所述计算机实现的方法包括：

从受协商者接收用于协商可协商服务层属性的策略；

从协商者接收协商所述属性的请求；

确定所述请求是否遵守所述受协商者策略的预定准则；以及

向所述协商者发送提供的建议。

20.根据权利要求19所述的方法，还包括：

从所述协商者接收协商确认；以及

向所述受协商者发送所述协商确认的确收。

21.一种计算机实现的方法，包括：

从协商者接收对可协商服务层属性的协商请求；

定位具有所述属性的受协商者；

将所述协商请求发送到所述受协商者；以及

从所述受协商者接收针对所述可协商服务的提供的建议。

22.根据权利要求21所述的方法，还包括：

将所述提供的建议发送到所述协商者；

从所述协商者接收协商确认；以及

向所述受协商者发送所述协商确认的确收。