CN106471465B - 服务启用器功能 - Google Patents

Abstract

本申请描述了一种用于更新在网络的服务层功能中的服务的方法和设备。具体地，公开了一种用于添加服务的方法。首先，在位于所述服务层功能的服务启用器功能处接收对添加所述服务的请求。审查请求的所述服务的服务描述以理解其能力。向位于所述服务层功能的服务能力发送验证请求。进一步地，通知另一服务层功能或者应用启用了请求的所述服务。

Description

服务启用器功能

相关申请的交叉引用

本申请要求于2014年4月9日提交的名称为“Apparatus and Method for ServiceEnabler function”的美国临时专利申请第61/977,382号的优先权，其公开内容全部并入本文。

技术领域

本申请涉及用于在不影响系统的可操作性的情况下改进在服务层中的服务的设备和方法。更具体地，本申请涉及改进在采用服务启用器功能的中间件服务层上的服务。

背景技术

近来，用户已经习惯于从其服务提供商接收静态服务。当将新服务添加至系统时，在将服务平台与更新的能力和特征重新同步时发生静态服务。即，服务平台需要重新组织其资源并且重新配置其能力和特征以将新服务集成到系统中。而且，与服务平台合作的所有应用和其它服务平台也必须更新和/或重新设置其配置。例如，在M2M系统中添加新服务可能需要限定新类型的资源，这要求对规范进行修改。这些附加步骤导致用户的停机时间增加和效率低下。

而且，尽管现有装置管理(DM)协议包括软件管理功能，但是这些DM协议并不是服务感知的。换言之，这些DM协议仅仅被配置为支持将软件模块下载和安装到装置上，例如，软件启用。然而，这些DM协议对由软件模块提供的服务是透明的。同样，这些DM协议缺乏用于将服务配置/集成到服务层中以供该服务层的客户端使用的附加管理功能。

在一个应用中，例如，通用即插即用(UPnP)包括允许网络装置无缝地发现彼此并且建立功能网络服务的一组协议。通常理解的是，UpnP的重点在于应用层和IP层。UPnP包括关于在插入之后网络装置如何发现其它网络装置以及其它网络装置又如何发现该网络装置的方法。UPnP还包括如何将IP地址自动地分配给新插入的装置、新装置如何自动地设置配置、以及装置如何识别并且使用网络服务。然而，UpnP不能将新服务动态地集成到服务层中从而使所有网络客户端可以识别并且利用该新服务。

本领域需要的是一种用于将新服务配置并且集成到服务层中的设备和方法。

本领域还需要的是一种用于在不影响系统的可操作性的情况下在服务层处将服务动态地添加至系统的设备和方法。

本领域还需要的是一种用于在不影响系统的可操作性的情况下在服务层处动态地移除和/或禁用在系统中的服务的设备和方法。

本领域进一步需要的是一种具有用于管理服务API的管理功能的架构。

发明内容

该发明内容的提供是为了以简化的形式介绍在下面的详细说明中进一步描述的构思的选择。该发明内容不旨在限制所要求的主题的范围。在很大程度上，前述需要通过本申请来满足，本申请涉及用于在不影响系统互操作性的情况下动态地添加、启动、禁用、并且移除在服务层中的服务的进程和设备。

本申请的一个方面涉及一种用于在网络中的服务层处添加服务的方法。该方法包括在位于服务层的服务启用器功能处接收请求以添加服务的步骤。该方法还包括审查请求的服务的服务描述以理解其能力的步骤。接着，向位于服务层的服务能力发送验证请求。进一步地，通知其它服务层或者应用启用了请求的服务。在一个实施例中，服务描述选择自服务提供商ID、服务ID、依赖服务列表、唯一服务API、公共服务API、服务的位置、认证方法、授权与访问控制信息、软件模块信息、协议支持、服务兼容性、计费策略、以及它们的组合。

本申请的另一个方面涉及一种用于更新服务的位于网络的服务层的计算机实现的服务启用器设备。该设备包括服务协调功能(SCF)，所述服务协调功能(SCF)被配置为使处理和通信与在服务层、应用、或者其它服务层中的现有服务能力协调。该设备还包括服务状态管理和配置功能(SMCF)，该服务状态管理和配置功能(SMCF)被配置为管理在服务层处的服务的状态转变。进一步地，该设备包括服务API管理功能(SAMF)，所述服务API管理功能(SAMF)被配置为在更新服务时管理服务API。在一个实施例中，SCF、SMCF、和SAMF彼此通信。

因此，已经相当广泛地概述了本发明的特定实施例，以便可以更好地理解其详细说明，并且以便可以更好地了解对本领域的本贡献。当然，还存在将在下文描述的并且将形成随附权利要求书的主题的本发明的附加实施例。

附图说明

为了促进对本申请的更深刻的理解，现在参考附图，在附图中，类似的元件用类似的数字表示。这些附图不应该被解释为限制本申请，而仅仅旨在说明。

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

图1B图示了M2M服务平台的实施例。

图1C图示了示例M2M装置的系统图的实施例。

图1D图示了示例性计算系统的框图的实施例。

图2A图示了根据本申请的实施例的用于更新新服务的配置的用户界面。

图2B图示了在网络内的服务层的部署场景的实施例。

图3图示了一组一种或者多种特定类型的公共服务功能的实施例。

图4图示了服务层架构的实施例。

图5图示了在服务层处的服务启用器功能的实施例。

图6图示了服务的多种服务状态转变的实施例。

图7图示了服务的服务API的实施例。

图8图示了用于添加新服务的方法的实施例。

图9图示了服务启用器功能添加新服务的方法的实施例。

图10图示了用于在将新服务添加到服务层中时管理各个服务的服务API的实施例。

图11图示了用于从服务层移除服务的方法的实施例。

图12图示了用于禁用服务的方法的实施例。

图13图示了用于在添加、启动、禁用、或者移除在服务层中的服务时处理依赖性问题的方法的实施例。

图14图示了用于支持服务启用器功能的oneM2M功能架构的实施例。

图15图示了根据图14的服务描述资源的结构的实施例。

图16图示了用于将采用了所提出的服务启用器CSF的新服务添加至oneM2M服务层的方法的实施例。

图17图示了根据本申请的新服务资源的实施例。

图18图示了根据本申请的可扩展资源结构的实施例。

图19图示了在oneM2M服务部件中的服务启用器功能的架构的实施例。

图20图示了用于通过添加新服务来交换信息的方法的实施例。

图21图示了根据本申请的用于添加新服务的另一种方法的实施例。

图22图示了在服务提供商限定新服务时添加该新服务的方法的实施例。

图23图示了具有通过DM协议工作的服务启用器功能的架构的实施例。

具体实施方式

将参照本文的各个附图、实施例、和方面来讨论示例性实施例的详细说明。尽管本说明书提供了可能的实现方式的详细示例，但是应该注意的是，这些细节旨在作为示例，因此，并不限制本申请的范围。

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

本申请描述了在支持由服务层托管的服务的M2M/IoT网络内的服务启用器功能。服务启用器功能提供了在不影响系统互操作性的情况下动态地添加、启动、禁用、并且移除服务或者现有服务的版本的能力。换言之，服务启用器功能的重点在于启用在服务层处的服务，而不是限定和/或生成服务。

如将在下文中更详细讨论的，多种服务可存在于服务层处，该多种服务根据不同要求创建于不同时间。在不影响系统互操作性的情况下，应该能够动态地管理(例如，添加、启动、禁用、并且移除)这些服务。根据一个实施例，当前使用由服务层提供的服务的应用不受动态地安装的新服务或者更新的现有服务的影响。根据另一个实施例，支持服务的多个版本，从而使不同的客户端可以同时使用服务的不同版本。根据再一个实施例，在期望从系统移除的服务的版本尚未使用时，不要求任何动作。

以下提供了贯穿本申请将使用的一些公共术语：

网络节点：在网络内的网络可寻址实体。网络节点可以是物理实体(例如，装置、网关、或者服务器)或者在网络中的虚拟实体。

服务节点：托管支持一个或者多个服务能力的服务层的网络节点。

服务层：通过一组应用编程接口(API)和底层网络接口来支持增值服务能力的软件中间件层。

服务能力：由服务层支持的特定类型的服务

服务能力层：服务层的(ETSI)机器对机器(M2M)术语。

公共服务功能(CSF)：服务层的oneM2M术语

公共服务实体(CSE)：服务层的oneM2M术语

平台

本申请旨在涵盖平台功能并且支持应用启用平台(AEP)和连接的装置平台(CDP)。AEP包括应用启用层和包括万维网和互联网的服务层。应用启用层包括但不限于以下：(i)服务API，规则/脚本引擎；(ii)SDK编程接口；和(iii)企业系统集成。应用启用层还可以包括增值服务，包括但不限于，发现、分析、上下文、和事件。包括万维网和互联网的服务层可以包括，例如，分析、计费、原始API、网络服务接口、语义数据模型、装置/服务发现、装置管理、安全、数据收集、数据适配、聚合、事件管理、上下文管理、优化连接性和传输、M2M网关、以及寻址与识别。CDP可以包括连接性分析、使用分析/报告/警报、策略控制、自动提供、SIM启动/禁用、和订阅启动/禁用。

总体架构

图1A是可以实施一个或者多个所公开的实施例的示例性机器对机器(M2M)或者IoT通信系统10的示意图。通常，M2M技术为IoT提供构建块，并且任何M2M装置、网关、或者服务平台可以是IoT以及IoT服务层的部件等。

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

如图1A所示，M2M/IoT通信系统10可以包括M2M网关装置14和M2M终端装置18。要了解，若需要，可以将任何数量的M2M网关装置14和M2M终端装置18包括在M2M/IoT通信系统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服务平台22向M2M应用20、M2M网关装置14、M2M终端装置18、和通信网络12提供服务。要理解，若需要，M2M服务平台22可以与任何数量的M2M应用、M2M网关装置14、M2M终端装置18、和通信网络12进行通信。可以通过一个或者多个服务器、计算机等来实施M2M服务平台22。M2M服务平台22提供服务，诸如，对M2M终端装置18和M2M网关装置14的管理和监测。M2M服务平台22还可以收集数据，并且转换该数据，从而使得其可与不同类型的M2M应用20兼容。可以利用各种方式来实施M2M服务平台22的功能(例如，作为网络服务器实施、在蜂窝核心网络中实施、在云中实施，等等)。

参照图1B，在场域中图示的M2M服务层22向M2M应用20、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网关等中实施M2M服务层22。

仍然参照图1B，M2M服务平台通常实施提供不同的应用和行业可以利用的服务交付能力的核心集的服务层26(例如，网络服务能力层(NSCL))。这些服务能力使M2M应用20能够与装置交互并且执行功能，诸如，数据收集、数据分析、装置管理、安全、计费、服务/装置发现等。本质上，这些服务能力使应用免于实施这些功能的负担，从而简化应用开发并且降低成本和上市时间。服务层26还使M2M应用20能够通过与服务层26提供的服务有关的各种网络12进行通信。在一个实施例中，用户界面可以用于指示要在服务层处启用的新服务。在另一实施例中，用户界面可以用于指示已经在服务层处启用了的新服务。

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

仍然参照图1B，M2M服务层22和22’提供不同的应用和行业可以利用的服务交付能力的核心集。这些服务能力使M2M应用20和20’能够与装置交互并且执行功能，诸如，数据收集、数据分析、装置管理、安全、计费、服务/装置发现等。本质上，这些服务能力使应用免于实施这些功能的负担，从而简化应用开发并且降低成本和上市时间。服务层22和22’还使M2M应用20和20’能够通过与服务层22和22’提供的服务有关的各种网络12和12’进行通信。

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

根据本申请的方面，可以将管理注册的方法实施为服务层的一部分。服务层是通过一组应用程序接口(API)和底层网络接口来支持增值服务能力的软件中间件层。ETSIM2M和oneM2M都使用可以包含该方法的服务层。ETSI M2M的服务层称为服务能力层(SCL)。可以将SCL实施在M2M装置(在这种情况下，其称为装置SCL(DSCL))、网关(在这种情况下，其称为网关SCL(GSCL))、和/或网络节点(在这种情况下，其称为网络SCL(NSCL))内。oneM2M服务层支持一组公共服务功能(CSF)，例如，服务能力。将一组一种或者多种特定类型的CSF的实例化称为公共服务实体(CSE)，可以将该公共服务实体托管在不同类型的网络节点(例如，基础设施节点、中间节点、应用专用节点)上。进一步地，可以将如本申请描述的搜索和发现服务层的方法实施为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问与管理来自服务层的发现、注册、和注销的管理有关的服务的M2M网络的一部分。

图1C是示例M2M装置30(诸如，例如，M2M终端装置18或者M2M网关装置14)的系统图。如图1C所示，M2M装置30可以包括处理器32、收发器34、传输/接收元件36、扬声器/麦克风38、小键盘40、显示器/触摸板42、不可移除存储器44、可移除存储器46、电源48、全球定位系统(GPS)芯片集50、和其它外围装置52。要了解，M2M装置40可以在与实施例保持一致的同时包括前述元件的任何子组合。该装置可以是使用所公开的用于感测数据的嵌入式语义命名的系统和方法的装置。

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

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

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

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

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

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

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

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

图1D是可以在其上实施，例如，图1A和图1B的M2M服务平台22的示例性计算系统90的框图。计算系统90可以包括计算机或者服务器并且可以主要由计算机可读指令控制，在任何情况下，该计算机可读指令可以是软件的形式，或者可以通过任何手段存储或者访问这种软件。可以在中央处理单元(CPU)91内执行这种计算机可读指令，以使计算系统90工作。在许多已知的工作站、服务器、和个人计算机中，中央处理单元91由称作微处理器的单片CPU来实现。在其它机器中，中央处理单元91可以包括多个处理器。协处理器81是与主CPU91不同的、执行附加功能或者协助CPU 91的可选处理器。CPU 91和/或协处理器81可以接收、生成、并且处理与所公开的嵌入式语义命名的系统和方法有关的数据，诸如，对具有嵌入式语义名称的感测数据的查询。

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

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

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

由显示控制器96控制的显示器86用于显示由计算系统90生成的可视输出。这种可视输出可以包括文本、图形、动画图形、和视频。显示器86可以与基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器、或者触摸板一起实施。显示器控制器96包括生成发送至显示器86的视频信号所需的电子部件。显示器86可以通过使用嵌入式语义名称来显示在文件或者文件夹中的感测数据。进一步地，计算系统90可以包含可以用于将计算系统90连接至外部通信网络(诸如，图1A和图1B的网络12)的网络适配器97。

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

服务层

在一个实施例中，可以采用如图2A所图示的图形用户界面来启用新服务。新服务可以是，例如，Facebook或者eBAY应用。如图所示，服务启用策略或者服务描述可以启用新服务，例如，应用。在一个实施例中，用户界面可以实施为启用或者禁用限定新服务的特定特征。

在本领域中，服务层功能(又称简单服务层)通常理解为层叠在一个或多个应用下方且在应用协议层(例如，HTTP、COAP等)上方。服务层将增值服务提供给客户端应用。服务层通常分类为‘中间件’服务。根据实施例，图2B图示了系统200的部署场景，包括：在系统200的网络(网络服务域205)内的服务层210。服务层210部署在各种网络节点(网关215和服务器216)上，以将增值服务提供给网络应用、网络、互联网、运营商网络、云、装置应用以及网络节点本身。在图2B中，网关215可以包括蜂窝网络、WLAN/WPAN/WSN、RFID网络、和有线网络，诸如，PLC、xDSL和PON。服务器216可以包括目录服务器、应用服务器、存储服务器、管理服务器、和服务服务器。系统200还可以包括装置应用域(DAD)220，该装置应用域(DAD)220包括传感器、致动器、RFID标签、和虚拟对象。系统200可以包括网络应用域230，该网络应用域230包括应用和用户。

在一个实施例中，M2M/IoT服务层是专门针对向M2M/IoT类型装置和应用提供增值服务的一种类型的服务层的示例。多个行业标准机构(例如，ETSI M2M和oneM2M)一直在开发M2M/IoT服务层来处理与将M2M/IoT类型的装置和应用集成到部署(诸如，互联网/网络、蜂窝、企业、和家庭网络)中相关联的难题。

M2M服务层可以向应用和装置提供对由服务层支持的M2M中心能力集合的访问。一些示例包括安全、计费、数据管理、装置管理、发现、提供、和连接性管理。经由利用了由M2M服务层限定的消息格式、资源结构、和资源表示的API，使这些能力对应用而言是可用的。

OneM2M服务层

在另一实施例中，采用oneM2M来开发技术规范，该技术规范解决了对可以容易地嵌入各种硬件和软件内的公共M2M服务层的需要。另外，可以依赖oneM2M，来将在场中的各种装置与全世界的M2M应用服务器连接起来。如图3所示，OneM2M公共服务层支持一组公共服务功能(CSF)，例如，服务能力。将一组一种或者多种特定类型的CSF的实例化称为公共服务实体(CSE)301，可以将该公共服务实体(CSE)301托管在不同类型的网络节点(例如基础设施节点、中间节点、应用专用节点)上。如图所示，CSE 301托管在场域302和基础设施域303中。

根据另一实施例，oneM2M正在利用两种架构方法(面向资源的架构(RoA)和面向服务的架构(SoA))来开发服务层。在oneM2M RoA RESTful架构中，将CSF表示为一组“资源”。将资源定义为在架构中具有可以经由RESTful方法(诸如，创建、检索、更新、和删除)来操纵的表示的唯一可寻址元素。通过使用通用资源标识符(URI)来使这些资源可寻址。资源可以包含一个或多个子资源和一个或多个属性。子资源是与父资源具有包含关系的资源。父资源表示包含对其一个或多个子资源的引用。子资源的有效期受限于父资源的资源有效期。各个资源支持存储资源的信息的一组属性。

另一方面，SoA架构遗留部署不是基于RESTful的。相反，SoA架构遗留部署在很大程度上重复使用了如图4所示的同一服务层架构400。此处，CSE 301由虚线指示。CSE包括各种M2M服务，包括：例如，服务公开部件410、服务部件I 420、服务部件N 430、网络服务使用部件440、和远程服务公开部件450。除了现有参考点之外，CSE 301可以包括服务间参考点Msc 460。在M2M服务部件之间的通过Msc参考点传递的通信利用网络服务方法，例如，网络服务消息交换模式(MEP)。

通用即插即用

根据另一实施例，可将本申请容易地应用于通用即插即用(UPnP)架构。UPnP是允许联网装置(诸如，个人计算机、打印机、互联网网关、WiFi接入点、移动装置)无缝地发现彼此在网络中的存在并且建立用于数据共享、通信、和娱乐的功能网络服务的一组联网协议。UPnP主要针对没有企业级装置的住宅网络，并且重点在于用于动态地插入装置的IP层和应用层。UPnP使用常见的互联网技术。假设网络必须运行互联网协议(IP)，并且然后利用在IP顶部的HTTP、SOAP、和XML，以便提供装置/服务描述、动作、数据传输、和事件处理。UPnP联网包括多个步骤，诸如：IP寻址、发现、描述、控制、事件处理、和呈现。

装置管理(DM)协议

如在本领域中通常理解的，DM协议提供动态装置管理功能，诸如，在装置上的固件管理和软件模块管理。例如，OM ADM是由开放移动联盟设计的用于装置管理的协议。该协议广泛地用于移动装置的远程管理。该协议由若干规范(包括：协议、架构、底层网络绑定等)组成。在最常见的场景中，通过实施OMA DM规范，DM服务器能够对具有DM客户端的装置(诸如，例如，移动电话)进行远程管理。这些装置还可以包括传感器、致动器、和网关。随着管理对象和DM客户端的实施，DM服务器可以对装置执行远程管理。

另一DM协议是软件部件管理对象(SCOMO)。SCOMO启用在装置内的远程软件部件管理。管理可以包括，但不限于，诸如，一个或多个软件部件的库存的下载、安装、更新、移除、启动/禁用、和检索的功能。

再一DM协议是BBF TR-069。该协议在用户驻地设备(CPE)与自动配置服务器(ACS)之间限定了CWMP协议。ACS是在网络中的集中式服务器，而CPE可以包括家庭路由器、机顶盒、和端装置。CWMP管理一组CPE装置，包括但不限于，以下功能：(i)自动配置和动态服务提供；(ii)软件/固件图像管理；(iii)状态和性能监测；和(iv)诊断。软件模块管理启用模块化软件和执行环境的管理，包括，软件模块安装、更新、卸载、和通知。软件模块管理还具有以下能力：开始和停止在CPE上的应用、启用和禁用执行环境、和清点在装置上的可用软件模块。

再一DM协议包括在CSE中的装置管理(DMG)CSF。其负责提供对在中间节点(M2M网关)、应用服务节点、和应用专用节点(M2M装置)、以及在M2M区域网络内驻留的装置上的装置能力的管理。除了跨Mcc参考点的CSE管理之外，DMG可以利用现有的装置管理技术，例如，TR-069和OMA-DM。为了执行转换和适配功能，DMG具有称作管理适配器的功能部件。管理适配器在底层NSE中执行在DMG与管理服务器(或者管理客户端)之间的适配。

服务启用器架构

根据本申请的一个方面，如图5所图示，例如，存在在服务层500处的服务启用器功能510的架构视图。其可以提供以下高级功能：(i)检查模块认证；(ii)检查节点资源；(iii)检查与现有模块的互操作性；(iv)检查策略和权限以确定如何处理冲突，例如，不注册新模块或者注销现有的模块等；(v)注册新模块；(vi)由于新模块，将一个或多个新服务添加至服务列表；(vii)修改API支持以反映新服务能力；以及(viii)修改模块间通信以并入新模块。在一个实施例中，可以采用注册和安全服务来添加/启动/禁用/移除任何服务。SEF包括子功能和在参考点上的与网络实体(例如，服务能力、M2M应用、和M2M服务层)的通信。服务启用器功能包括在下文中更详细地描述的三种(3)主要子功能。

第一子功能是服务状态管理和配置功能(SMCF)511。SMCF的作用在于管理在服务层处的服务的状态转变并且配置服务的能力和特征。如果存在服务的多个版本，则SMCF负责管理服务的各个版本的状态和配置。

第二子功能是服务协调功能(SCF)512。SCF的作用在于，当服务启用器功能试图添加、启动、禁用、或者移除服务时，协调在服务启用器功能与服务能力、M2M应用和其它M2M服务层之间的进程和通信。另外，SCF与在服务启用器功能内的SMCF和SAMF合作。

第三子功能是服务API管理功能(SAMF)513。SAMF的作用在于，当添加、启动、禁用、或者移除服务时，动态地管理服务API。服务API意味着服务的功能和特征。客户端(诸如，例如，应用或者其它服务层)可以通过从服务API检索信息来识别服务，并且通过访问服务API来利用该服务。不同的服务可以具有不同的服务API，该服务API由提供服务的实体限定。在一个实施例中，由服务层而不是由服务API本身来执行访问服务API和确定服务API驻留在何处。

例如，基于SoA的温度报告服务的服务API可以被配置为将位置和时间作为参数来检索温度。另外，服务API还可以提供将起始时间和结束时间作为参数来计算平均温度并且返回最高/最低温度的功能。另一示例是基于RoA的位置服务，并且服务API提供资源列表，其中，访问控制属性限定出被允许检索位置信息的一组用户，而频率属性指示报告并且更新最新位置的频率。

下文的表1概述了在服务启用进程期间在不同参考点上交换的消息。服务启用进程是指在服务层处添加、启动、禁用、或者移除服务的进程。M2M应用、其它M2M服务层、和底层网络可以向服务启用器功能发送对触发服务启用进程的服务启用请求。注意，在底层网络触发服务启用进程的情况下，其可以直接地向服务启用器功能发送服务启用请求。可替代地，其还可以首先向装置管理SC发送服务启用请求，并且DM SC将该请求中继至服务启用器功能以发起服务启用进程。

表1

表2高亮了表1中限定的各个消息中的一些关键信息。在该表中，未指定服务ID和/或服务提供商ID，因为这些ID对所有类型的消息来说都是通用的。

表2

服务状态管理和配置功能(SMCF)

SMCF的其中一个主要作用在于管理在服务层处的服务的状态转变。图6描述了在服务层处的服务的4种主要状态和在这4种状态之中的状态转变。其中一种状态是‘添加’。在‘添加’状态中，将服务首次插入到系统中，但是并未准备好使用。根据本申请，添加是指服务的能力和特征可以由在服务层内的实体以及外部实体(诸如，应用或者其它服务层)识别/发现。服务层在添加了新服务之前(例如，在添加新服务的进程期间)可能都不会发现该新服务，或者服务层通过解析服务描述来获取对新服务的一些了解。添加新服务的请求可以来自外部实体，诸如，应用和第三方服务提供商。如果添加新服务的进程失败，则不为该新服务维持状态，因为该服务未成功添加并且无法被服务层识别。

另一种状态是‘活动’状态。在活动状态中，该服务已经准备好使用。对于‘启动’操作，服务的状态从‘添加’或者‘不活动’状态进入‘活动’状态。再一实施例是‘不活动’状态。在不活动状态中，服务已经处于系统中，但是由于一些原因尚未准备好使用。例如，将服务的较旧版本替代并且升级为新版本。可以采用较旧版本来进行备份和追踪目的。换言之，维持较旧版本的所有信息。对于‘禁用’操作，服务的状态从‘添加’或者‘活动’状态进入‘不活动’状态。再一状态是‘已移除’状态。在移除状态中，从服务层完全移除服务，这是指外部应用和服务层无法通过服务发现机制来发现该服务。对于‘移除’操作，服务的状态从任何上述3种状态进入‘已移除’状态。根据一个实施例，为了进行追踪和统计，可以将服务的状态和信息内部地维持在服务层处。

在另一实施例中，SMCF的主要作用可能在于描述服务并且配置服务的能力和特征，从而使该服务可以被客户端(例如，应用和其它服务层)识别并且利用。服务描述可以提供服务的重要信息。这可以与软件模块分开。服务描述可以包括一个或者多个以下属性：(i)服务提供商ID；(ii)服务ID；(iii)依赖服务列表(iv)服务API(唯一服务API或者公共服务API)；(v)服务的位置；(vi)认证方法；(vii)授权与访问控制信息；(viii)软件模块信息；(ix)协议支持；(x)服务兼容性；以及(xi)计费策略。下文提供了对各个属性的描述。

服务提供商ID：该属性指定何人拥有并且提供服务。例如，在oneM2M系统中，用M2M服务提供商标识符(M2M-SP-ID)来全球唯一地识别M2M服务提供商。这是分配给服务提供商的静态值。

服务ID：该属性指定服务的识别。服务ID是由M2M服务提供商或者应用提供的M2M服务的标识符，例如，通过提供服务的实体来限定服务ID。例如，服务ID可以由三段组成。段1指示限定服务的是应用还是服务提供商。段2指示应用ID或者服务提供商ID。段3指示服务的类别，诸如，社交网络、紧急情况、或者基于传感器的服务。

依赖服务列表：该属性指定该服务所依赖的服务/功能的列表、和该服务所兼容的这些服务的相应版本。

服务API：该属性指定将服务的服务API分成两部分。这在图7的实施例中进行了示出。这两部分是在服务层700中的公共服务API701和唯一服务API 702。公共服务API指定服务的一些公共能力和特征。‘公共’是指服务的这些能力和特征与其它服务的能力和特征相同或者相似，诸如，软件模块管理、计费、和安全。通常，公共服务API包括托管在服务层中的所有服务的能力和特征，并且应用使用公共服务API来了解并且利用服务。另一方面，唯一服务API指定服务的一些唯一能力和特征。各个服务可以具有其它服务所没有的一些唯一特征。例如，图像处理服务可以根据特殊技术来提供用于压缩图像的唯一特征。唯一服务API可以具有用于服务层的能力和特征，并且其还可以具有由底层协议层提供的能力和特征。例如，在oneM2M中，装置管理服务具有由在底层网络服务实体(NSE)中的DM协议提供的一些能力。通过在CSE中的DMG CSF来向服务层公开这些能力。

在一个实施例中，为了利用服务，客户端需要首先使用服务的公共服务API来检索一些信息，然后使用唯一服务API来访问和/或利用服务(若必要的话)。公共服务API可以包括客户端如何访问并且使用唯一服务API的方法或者链路。然而，在一些情况下，客户端不需要使用唯一服务API，因为唯一服务API可能包含服务消费者不关心的一些内部能力。在这种情况下，唯一服务API充当客户端的黑盒子。例如，图像处理服务的唯一服务API包括用于指示如何进行图像压缩的一些属性或者参数，但是使用服务的客户端不需要知道这些参数，所以他们将不会使用唯一服务API。在一些示例中，在服务层处的装置管理服务具有在底层DM协议中的唯一服务API，但是使用DM服务的装置不需要知道唯一服务API。

服务的位置：该属性指定在何处添加服务。该属性用于帮助客户端定位服务、进行服务发现、和利用服务。例如，在oneM2M系统中，可以将服务添加到基础设施节点或者中间节点中。

认证方法：该属性指定用于两个目的的认证方法。第一目的是想要使用该服务的客户端何时执行认证方法。第二目的是在启用或者禁用了服务时，服务层何时执行认证方法。

授权与访问控制信息：该属性为想要使用服务的客户端指定服务的授权方法与访问控制信息。

软件模块信息：该属性指定用于支持在服务层和/或底层协议层中的服务的软件模块的信息，诸如，软件模块ID、大小、版本、和用户指令。该属性用于版本控制与软件模块管理目的。

协议支持：该属性指定在服务层和底层网络处需要什么类型的协议来支持该服务，例如，在应用协议层处的HTTP/CoAP、在传输层处的TCP/UDP。

服务兼容性：该属性指定服务的版本关于先前版本的兼容性。

计费策略：该属性指定服务如何执行计费进程，诸如，计费模型、计费事件、和计费率。

服务协调功能(SCF)

根据实施例，在添加、启动、禁用、和移除服务的进程期间，服务启用器功能需要与现有服务能力、应用、和/或其它服务层通信。表1和2概述了在SCF与其它实体之间的在不同参考点上的消息交换。具体地，SCF负责驱动和协调以下关于在服务层中的服务的任何更新的通信。

SCF与服务状态管理和配置功能(SMCF)和在服务启用器功能内的服务API管理功能(SAMF)通信。例如，当存在对更新(例如，添加、启动、禁用、或者移除)服务状态的请求时，SCF发起与SMCF的通信，从而使SMCF可以更新服务的状态，并且配置服务的能力和特征。SMCF将配置和状态管理的结果返回至SCF，SCF使用该结果来发起下一步操作。

而且，SCF发起与SAMF的通信以更新针对更新(例如，添加、启动、禁用、或者移除)后的服务的服务API。SCF将服务信息发送至SAMF。SAMF依次相应地更新服务API。

在另一实施例中，还可以用在服务层内的现有服务能力来进行通信。目的在于确保状态更新遵循服务层的策略。而且，目的在于保证服务层启用并且支持了服务的能力和特征。例如，当存在新版本时，SCF联系安全功能/服务以验证由新版本使用的安全算法在服务层中受到支持。SCF还需要与软件模块管理通信，从而使得可以适当地使用服务来管理软件模块信息，并且将该软件模块信息与服务紧密联系。

在再一实施例中，SCF与利用服务层注册的应用和其它服务层进行通信。这样，它们变得知晓服务的更新。例如，当禁用服务以便进行维护时，SCF需要通知目前正在或者过去一直在使用特定服务的那些应用和其它服务层。

在又一实施例中，SCF与底层网络通信以便通知由服务启用器功能驱动的服务启用进程。例如，当添加新服务时，SCF通知底层网络。这样，在底层网络中的DM协议下载并且安装软件模块以支持新服务。

服务API管理功能(SAMF)

根据实施例，SAMF负责管理在服务层中添加、启动、禁用、或者移除的服务的服务API。通过管理服务API，可以识别/发现并且利用服务。例如，在RoA中，资源表示服务的能力和特征。同时，在SoA中，可以调用功能以检索服务的特征并且使用服务。

各个服务具有由提供服务的实体限定的不同服务API。如上文讨论的，服务API包含公共服务API和唯一服务API。SAMF负责管理服务的这两种类型的服务API，以便使服务对客户端可见。

SAMF可以具有用于管理服务API(公共和唯一服务API)的一种或者多种以下功能。根据一种功能，SAMF或许能够将服务API集成到服务层的总体API中。即，当将服务添加到系统时，应该将其公共服务API集成到服务层的总体公共API中并且由客户端使用，例如，应用、其它服务层等。例如，对于基于RoA的服务，服务API可以是资源。SAMF可以将资源链接到服务层的总体资源树中，并且提供访问资源的链路。同时，对于基于SoA的服务，SAMF可以修改由服务层维持的公共功能，从而使得服务的公共服务功能可以由公共服务层功能调用。集成还意味着将唯一服务API集成到服务层中，并且可以通过服务层至少对客户端可见。

根据另一功能，SAMF或许能够通过添加新功能来补充服务API。基于服务API，SAMF可以将新功能添加至不由服务本身支持而是由服务层支持或者服务层所需的服务API。例如，服务启用器功能可以将访问控制提供给其在本质上并不支持的服务。在示例性实施例中，对于基于RoA的服务，将访问控制添加至服务的资源。可以通过功能或者在该功能中的一些参数来实现访问控制。

根据另一功能，SAMF或许能够转换服务API。例如，可以在不同的环境中创建并且提供服务。当将服务集成到服务层中时，服务层可以转换服务API，从而使得服务API可与托管在服务层中的其它服务兼容。而且，该服务API可与正在使用在服务层中的服务的应用兼容。在示例性实施例中，可以存在多种类型的转换。例如，可以在基于RoA的资源与基于SoA的功能之间进行转换，由此，由服务层提供的公共API将在RoA中的服务资源转换成在SoA中的服务功能，反之亦然。还可以在RESTful资源与非RESTful资源之间进行转换，由此，服务层公共API将服务的RESTful资源转换成用于服务的非RESTful资源，反之亦然。各种上述功能都可以应用于由服务层托管的所有服务。例如，转换功能可以依据功能‘公共转换’，例如，服务API、原始格式、目标格式。这意味着公共转换功能按照‘原始’格式(例如，基于SoA的功能)将服务API转换成‘目标’格式(例如，基于RoA的RESTful资源)。

服务启用器方法

根据本申请的另一个方面，描述了用于在M2M/IoT网络内添加、启动、禁用、和/或移除服务的一种或者多种方法。如要在下文更详细地理解的，该方法采用上文描述的服务启用器功能的架构。

根据实施例，对用于将新服务添加到服务层中的方法进行了描述。具体地，服务启用器功能协调在服务层内的通信和与外部实体(诸如，例如，应用和其它服务层)的通信。这样，可以将新服务无缝地集成到服务层中。而且，新服务可以由客户端(诸如，应用和其它服务层)组织并且利用。

根据示例性实施例，图8阐释了如何相对于即时应用采用用于添加新服务的信息交换操作。在图8中的各个步骤用数字(例如，0、1、2等)来表示。在步骤0中，对可以触发服务启用进程的可能的源进行了描述。存在可以触发用于添加新服务的进程的2种情况。在步骤0a中，M2M应用想要限定并且提供新服务。在这种情况下，应用通过在图5中示出的参考点‘c’来向SCF发送服务启用请求，该服务启用请求可以包括所请求的动作以添加服务。在可替代实施例中，应用可以提供检索软件模块、任何协议或者实体(例如，DM协议)的链路，以便下载并且安装软件模块。

根据另一实施例，如步骤0b所示，代替步骤0a或者结合步骤0a，服务提供商限定新服务并且将该新服务提供给服务消费者。在这种情况下，SCF可以通过如图5所示的参考点‘b’从其它另一服务层得到服务启用请求。可替代地，SCF可以通过如图5所示的参考点‘d’从底层NSE得到服务启用请求。服务启用请求可以指示所请求的动作(例如，添加、启动、禁用、或者移除服务)，并且包含服务描述。

接着，在步骤1中，SCF从外部实体(例如，应用或者服务提供商)接收对添加新服务的请求。如果新服务由应用限定，则该应用需要将软件模块和服务描述都提供给服务启用器功能。如果新服务由服务提供商限定，则服务启用进程需要服务描述。服务提供商可能不需要将软件模块提供给服务层。

在步骤2中，SCF通过在如图5所示的服务启用器功能内的参考点‘In’来向SMCF发送请求消息。所请求的消息将服务状态更新请求和服务描述解析请求组合在一起。根据服务状态更新请求，SCF指示新状态。在这种情况下，将添加新服务。而且，服务描述解析请求包括新服务的服务描述。

在步骤3中，SMCF将新服务的状态更新为‘已添加’。SMCF然后解析服务描述以理解新服务的能力和特征。例如，SMCF通过解析服务ID属性来理解并且确定新服务是否是现有服务的更新版本。而且，SMCF通过解析授权与访问控制信息属性来解析软件模块信息和访问控制策略。

随后，在步骤4中，SMCF通过在服务启用器功能内的参考点‘In’(在图5中示出)来向SCF发送组合了服务状态更新响应和服务描述解析响应的单个响应消息。服务状态更新响应指示服务状态已经更新至所要求的状态(例如，‘已添加’)，并且服务描述解析响应包括新服务的能力和特征。

接着，SCF和服务能力根据步骤5通过在服务层内的参考点‘a’(在图5中示出)来交换服务能力验证请求和响应。SCF读取来自SMCF的信息，然后发起与不同服务能力(SC)的多个通信。根据一个实施例，通信可以包括服务层配置。此处，服务节点更新其在启用新服务时提供的功能的配置。可以从在服务描述中的几个属性提取该信息，诸如，服务ID和协议支持。

根据另一实施例，通信可以包括软件管理细节。此处，服务层可以维护软件模块信息，该软件模块信息支持新服务。该信息来自服务描述中的软件模块信息属性，该软件模块信息属性包含软件模块ID、大小、版本、用户指令中的一个或者多个。

根据又一实施例，通信可以包括安全细节。安全细节基于来源于认证方法和授权与访问控制信息的信息。此处，SCF联系安全SC以查看所要求的与安全有关的方法/算法是否受到支持，例如，关于新服务所需的敏感数据的安全算法是否受到支持、以及是否在服务层中启用了验证和授权方法。如果还没有启用任何这些方法或算法，则安全SC将启用所要求的方法，并且更新安全简档以指示已经启用了所要求的安全方法。

根据又一实施例，通信可以包括计费策略。计费策略属性包含大部分所要求的信息，诸如，计费模型、计费事件、和计费率。即，SCF向计费SC发送新服务的计费信息，从而使得计费SC可以记录信息，并且知道在服务消费者使用新服务时如何对其进行计费。

根据又一实施例，通信可以包括注册协议。即，最近启用的服务可能会对其它实体(例如，利用服务层注册的应用和管理实体)有潜在影响。例如，可以在从旧版本更新成新版本时通知应用，以提供新特征并且修复在先前版本中的一些漏洞。具体地，SCF确定在启用了新服务之后其应该通知哪些外部实体。SCF将向注册SC发送请求消息、以及包括在服务描述中的服务ID属性和服务列表属性的必要消息。注册SC检查向该服务层注册的实体的列表，以找出正在使用受到新服务影响的任何服务的实体。随后，其返回实体的列表以便进行通知。

根据又一实施例，通信可以包括DM协议。如果新服务由应用限定，则该应用将软件模块提供给服务层。然后，服务层可以将软件模块向下推送到底层DM协议以安装软件模块。服务启用器功能确定是否有必要与DM SC合作以启用新服务。在示例性实施例中，这可以通过解析在服务描述中的服务ID和软件模块信息属性以确定软件模块是否来自应用来执行。如果软件模块来自应用，则SCF将向DM SC发送服务ID和软件模块信息以及软件模块本身，以便安装软件模块。

针对图8的步骤6，SCF通过在服务启用器功能内的参考点‘In’(在图5中示出)来向SAMF发送服务API管理请求。即，在请求中，SCF将服务API传递给SAMF。SAMF将服务API集成到服务层中，从而使得服务可以由应用或者其它服务层识别并且利用。另外，SAMF可以转换服务API，从而使得服务API可与托管在服务层中的其它服务兼容。SAMF还可以添加由服务层但是并非由新服务本身支持的一些新功能。

接着，在步骤7中，SAMF通过在服务启用器功能内的参考点‘In’来向SCF发送服务API管理响应。SAMF完成对新服务的服务API管理，然后将服务API链路或者方法返回至新服务的SCF。在描述基于RoA的服务的示例性实施例中，响应包括用于表示新服务的资源列表的URI或者链路。在描述基于SoA的服务的另一示例性实施例中，响应包括接口或者公共功能，以调用具有用于描述由新服务提供的功能的参数的功能列表。

在步骤8中，SCF确定需要向哪些实体通知新服务。可以使用不同的判据来确定是否需要通知实体。这些判据可以包括，但不限于：(i)是否利用该服务层注册实体；(ii)是否利用该服务层注册实体，并且该实体是否潜在地使用新服务；(iii)如果将新服务添加至服务层，则实体是否订阅以接收通知。在这种情况下，订阅是特定于服务的。换言之，如果实体订阅针对不同服务的接收通知，则可以通知实体多次。

随后，SCF通过在步骤9中的其它服务层的参考点‘b’和通过应用的参考点‘c’(在图5中示出)来发送服务启用通知。通知可以包括由服务启用器功能执行的最新操作，例如，添加、启动、禁用、或者移除服务。例如，通知指示添加了新服务、和用于检索该新服务信息的链路/方法，从而使得应用和其它服务层可以识别并且利用该新服务。

根据另一实施例，如图8所示，可以交换关于新服务的更多信息(步骤10)。这在其它服务层的参考点‘b’和应用的参考点‘c’(在图5中示出)上发生。在得到关于新服务的通知之后，外部实体(例如，应用和其它服务层)可以具有与SCF的多轮通信，以请求更详细的信息。例如，如果应用确定要切换到服务的新版本，则其可以向SCF询问关于安全、计费、订阅等的更具体的信息。

根据另一实施例，如图8所示，可以将服务启用通知从服务启用器功能发送到NSE1(步骤11)。例如，在新服务由应用限定的情况下，该应用提供软件模块，服务启用器功能有必要与底层NSE通信以提供软件模块。可以提供软件模块或者用于检索软件模块的链路，从而使得底层NSE可以下载并且安装软件模块以启用在底层网络处的新服务。

如果在特定步骤中添加新服务的进程的事件失败，例如，用于支持新服务的软件模块安装失败，则SCF将向触发添加新服务的进程的实体报告。该报告将包括失败的原因。触发实体将采取进一步的步骤来确定是否再次添加新服务。根据应用，还设想服务启用请求正在请求一次添加、启动、禁用、或者移除多个服务或者服务的多个版本。可以在一次请求时重复在本申请中提出的方法和过程以处理一个服务或者服务的版本。

在本申请的实施例中，将服务启用器功能描述为驱动用于添加新服务的进程的主要功能。图9是用于服务启用器功能添加新服务的方法的示例性实施例。图9中的各个步骤用数字(例如，0、1、2等)来表示。首先，存在用于添加服务的触发器(步骤0)。接着，SCF将会是在服务启用进程的进程中触发的第一功能(步骤1)。SMCF解析服务描述并且理解新服务提供了什么能力和特征。SMCF从SCF得到服务描述(步骤2)。接着，确定新服务是否是现有服务的新版本(步骤3a)。如果新服务是现有服务的新版本，则SMCF将检索现有版本的信息，诸如，软件模块版本、能力和特征、和计费信息(步骤3b)。如果不是，则SMCF将进入下一步骤。具体地，为了确定新服务是否是新版本，SMCF可以参考服务描述属性，诸如，服务ID、软件模块信息、服务API。可以从现有服务API或者一些服务库检索旧版本的信息。接着，通过解析服务描述，SMCF生成新服务的能力和特征的配置(步骤4)。当新服务是现有服务的新版本时，服务启用器功能需要指示在新版本与一个或多个旧版本之间的主要差异，或者提供检索一个或多个旧版本的信息的方法/链路。SMCF然后向SCF发送新服务信息。随后，SCF与在服务层中的若干SC通信以检查在服务层中是否启用并且支持了新服务所需的方法、算法、或者模型(步骤5)。如果目前在服务层中不支持针对新服务的一些算法(例如，针对敏感数据的安全算法)，则服务启用器功能将更新服务层的能力的配置，以便将新服务集成到服务层中。然后，SAMF管理针对新服务的服务API(步骤6)。在将新服务添加至服务层之后，SCF利用新服务的服务API通知外部应用和其它服务层，从而使得可以识别并且利用新服务(步骤7)。例如，对于基于RoA的服务，SCF可以指示新服务的资源的链路。在另一方面，对于基于SoA的服务，SCF可以指定用于使用新服务的功能和参数。

用于管理服务API的方法

根据本申请的另一实施例，如图10图示的，呈现了用于在将新服务添加到服务层中时管理各个服务的服务API的方法。如上所述，该方法由在服务启用器功能内部的SAMF执行。具体地，SAMF从SCF接收服务API，该服务API是服务描述中的属性(步骤1)。接着，确定是否需要API转换(步骤2a)。如果需要，则SAMF基于由服务层支持的服务API和公共API来执行API转换(步骤2b)。如果不需要，则SAMF进入下一步骤。为了确定是否需要转换，SAMF首先确定服务是基于RoA的还是基于SoA的。其后，SAMF确定服务是否可与托管在服务层中的其它服务兼容。例如，如果服务是基于SoA的，但是服务层仅支持基于RoA的资源，则需要进行转换。在一个示例性实施例中，如果服务是RESTful服务，而服务层仅支持非RESTful服务，则可能需要进行转换。接着，确定是否需要一些新功能(步骤3a)。如果需要，则SAMF添加原始服务API不支持的一些新功能(步骤3b)。如果不需要，则SAMF进入下一步骤。即，一些功能在本质上不受服务支持，而是服务层所需的。在示例中，访问控制信息可以不由服务API指定，但是需要托管在服务层中的所有服务指定访问控制信息。如果访问控制不由原始服务API指定，则服务层将针对新服务使用默认的访问控制规则。进一步地，SAMF将服务API集成到服务层中，从而使得可以识别并且利用新服务(步骤4)。对于基于RoA的服务，可以将其资源链接至服务层的资源树。另一方面，对于基于SoA的服务，其功能可以由服务层的公共功能调用。

用于移除服务的方法

根据本申请的另一实施例，描述了负责从服务层移除服务的服务启用器功能。可能存在若干理由来移除服务。例如，该服务不能与新系统兼容。因此，客户端可能不会使用该服务。而且，该服务不遵循一些新的强制策略。进一步地，原始服务提供商决定移除该服务。出于本申请的目的，假设已经做出了移除服务的决定。因此，不需要检查服务层是否允许移除服务。

根据如图11所示的示例性实施例，对用于从服务层移除服务的过程进行了描述。在图11中的各个步骤用数字(例如，0、1、2等)来表示。具体地，SCF从一些实体接收对移除服务的要求，例如，服务能力、应用、或者服务提供商(步骤1)。为了准确地识别要移除什么服务和要移除哪些一个或多个版本，需要指定在服务描述中的一个或者多个以下属性：(i)服务提供商；(ii)服务ID；(iii)软件模块信息；以及(iv)服务API。接着，将服务状态更新请求从SCF发送至在服务启用器功能中的SMCF(步骤2)。这在图5所示的服务启用器功能内的参考点‘In’上发生。一旦已经接收到对移除服务的请求，则SCF向SMCF发送用于识别要移除什么服务和哪个版本的信息。接着，SMCF基于来自SCF的信息来管理已移除的服务的配置(步骤3)。具体地，如果服务要移除服务的版本，则SMCF将通过移除由该版本提供的那些能力和特征来更新服务的能力和特征的配置。如果完全移除了服务(例如，移除了所有版本)，则SMCF清除该服务的配置记录。在示例性示例中，服务层利用一些基本信息(诸如，服务提供商、版本号、和软件模块版本)来维持对已移除的服务的记录。如果服务未来添加了最新版本，则可以证明这是有用的。在该确认步骤之后，SMCF不需要向SCF确认，因为假设做出了移除服务的决定。SMCF也不需要向SCF给出反馈。即，SCF知道该步骤的操作和结果。在示例性实施例中，接着，SAMF从SCF接收对移除或者更新服务API的请求(步骤4)。在该请求中，SCF指定待移除的服务的信息，诸如，服务ID、服务API链路或者功能。如果移除的服务是版本，则SAMF将移除在服务API中针对特定版本的相应内容，并且维持在服务API中的其它内容。进一步地，SAMF遵循在移除和/或更新服务API的请求中的信息(步骤5)。可能需要SAMF移除和/或更新一个或者多个服务的若干版本。在本申请中，设想，如果SCF同时联系SMCF和SAMF，则步骤2和3可能分别与步骤4和5并行地发生。

接着，SCF发起与不同SC的若干通信，以通知移除了服务或者服务的一个或多个版本(步骤6)。根据图5，这在服务层内的参考点‘a’上发生。那些SC可以相应地更新其配置。更进一步地，SCF通知应用和其它服务层移除了服务。SCF需要通知可能会受到移除服务的影响的所有实体(步骤7)。这在其它服务层的参考点‘b’和应用的参考点‘c’(在图5中示出)上发生。

用于禁用服务的方法

在本申请的又一实施例中，对用于禁用服务的方法进行了描述。通常，相较于添加或者移除服务，禁用服务较为直接。即，除了在服务层中的服务的状态更新之外，禁用不需要任何改变。对于禁用服务，SMCF将服务状态改为‘不活动’，然后通知可能会受到禁用操作影响的那些外部实体。

在示例性实施例中，图12示出了用于禁用服务的过程。图12中的各个步骤用数字(例如，0、1、2等)来表示。首先，SCF接收对禁用服务的要求(步骤1)。该要求可以来自内部服务能力、外部应用、或者其它服务层。

可能存在触发服务禁用进程的多个事件。例如，如果服务发生故障，则禁用该服务。如果服务违反服务层的一些策略和规则(例如，位置服务通过透露客户端或者其它客户端的位置而违反服务层的隐私策略)，则同样可以禁用该服务。如果服务未由客户端使用并且仅是为了备份目的而维持，则同样可以禁用该服务。在步骤2中，SCF向SMCF发送对管理用于禁用服务的状态更新的请求。这在图5所示的服务启用器功能内的参考点‘In’上发生。

接着，SMCF将服务状态更新为‘不活动’(步骤3)。在该步骤之后，SMCF可能不需要与SCF确认。即，SCF知道该步骤的操作和结果。接着，将服务API管理请求从SCF发送至SAMF(步骤4)。SAMF依次更新已禁用的服务的服务API，诸如，可用性信息(步骤5)。SCF发起与不同SC的若干通信，以通知禁用了服务(步骤6)。根据图5，这在服务层内的参考点‘a’上发生。在步骤7中，SCF通知应用和其它服务层禁用了服务，例如，服务启用通知。根据图5，这在其它服务层的参考点‘b’和应用的参考点‘c’上发生。

根据实施例，当禁用服务时，触发实体可以指定禁用的持续时间。即，在指定的时间段之后，将启动并且准备好使用该服务。在这种情况下，启动服务的操作可以变得更简单，因为服务消费者知道服务将在何时变为活动。而且，当通知实体关于服务的禁用时，服务启用器功能可以推荐由服务层提供的一些相似的服务作为替代选择。如果禁用是永久的，则未来可以提供方法或者链路以检索服务的信息。

用于启动服务的方法

根据本申请的又一实施例，描述了用于启动服务的方法。启动服务遵循与上文针对禁用服务讨论的过程相似的过程。然而，将服务状态改为‘活动’。在一个实施例中，如果启动连同添加新服务一起发生(例如，添加新服务并且即刻启动该服务)，则可以将启动进程集成到添加新服务的进程中。在另一方面，如果在添加新服务之后在单独的进程中启动该新服务，则服务启用器功能将新服务的状态改为‘活动’，然后通知实体，例如，服务能力、应用、和服务层。

在可替代实施例中，现有服务的启动从禁用了的服务发生。此处，服务启用器功能将新服务的状态改为‘活动’，然后通知外部实体，例如，服务能力、应用、和服务层。

用于处理依赖性问题的方法

根据本申请的另一实施例，当添加、启动、禁用、或者移除在服务层中的服务时，在处理依赖性问题时，可能会发生问题。例如，要考虑依赖位置服务的加油站搜索服务。如果暂时禁用或者永久移除了位置服务，则应用可能无法提供附近的加油站的信息。在另一示例中，要考虑利用预设温度来自动控制房间温度的服务。服务依赖于自动报告房间中的当前温度的一组传感器。如果传感器停止感测并且报告温度，则控制温度的服务会存在问题。

甚至添加或者启动服务也可以会导致问题。例如，如果，除了温度之外，在温控型服务中的传感器还提供用于报告湿度的新服务，则控制温度的服务需要确定是坚持旧服务还是切换到新服务。根据本申请，可以确定服务所依赖的服务集合。

图13图示了用于在添加、启动、禁用、或者移除在服务层中的服务时处理依赖性问题的方法的示例性实施例。在附图中将各个步骤表示为步骤‘#’。一旦接收到添加、启动、禁用、或者移除了服务的通知，服务启用器功能便开始发现任何其它服务是否受到影响(步骤1)。为了发现依赖性问题，图5所示的服务启用器功能可以从通知提取信息。在一个实施例中，通知包含触发事件(例如，添加、启动、禁用、或者移除)和来自服务描述的一些属性，诸如，例如，服务ID和服务列表。在步骤2中，确定是否存在依赖性问题。即，服务启用器功能将基于触发事件(例如，添加、启动、禁用、或者移除服务)来确定进一步的动作。假设存在依赖性问题，则服务启用器功能检查该依赖性问题是否起因于移除服务。将在下文中更进一步地详细讨论在依赖性问题并非起因于服务时的方法。

根据步骤4，确定已移除的服务是否关键。‘关键的服务’是指其它服务可以暂时地依赖否则无法提供一些服务的服务。例如，计费服务是关键的服务。根据本申请的这个部分要理解，已经做出了‘移除服务’的决定。接着，如果确定已移除的服务是关键的，则服务启用器功能执行服务发现机制以查找可替代服务(步骤5)。在本申请中通常要理解，可以应用任何服务发现机制。进一步地，如果确定已移除/禁用的服务不是非关键的，则终止在受影响的服务与已移除/禁用的服务之间的关系(步骤6)。非关键是指，在不移除/禁用服务的情况下，也可以利用受影响的服务。

现在将对在依赖性问题并非起因于服务时(步骤3的否定回复)的方法进行讨论。即，检查依赖性问题是否起因于禁用服务(步骤7)。如果依赖性问题起因于禁用服务，则确定禁用是否是永久的(步骤8)。如果禁用是永久的，则服务启用器功能检查已禁用的服务是否是关键的(步骤9)。如果禁用不是永久的，则服务启用器功能等待直到启动了服务为止(步骤10)。在等待时间期间，如果已禁用的服务是关键的，则可以暂停受影响的服务，否则，在不禁用服务的情况下，可以提供受影响的服务。

根据另一实施例，服务启用器功能检查依赖性问题是否起因于添加或者启动了服务(步骤11)。如果是，则确定是否要使用最近添加的或者启动的服务。

OneM2M服务层实施例

根据本申请的另一方面，对oneM2M RESTful功能架构进行了描述。例如，图14图示了用于增强现有oneM2M功能架构以支持服务启用器功能的示例性实施例。如图所示，服务启用器功能可以是在CSE中的新CSF。CSF协调添加、启动、禁用、或者移除在CSE内的服务。CSF还分别与AE、其它CSF、和CSE通信。而且，图14示出的实施例提供在图5图示的oneM2M与通用架构之间的参考点映射。

新服务的发起方(例如，图14所示的AE2或者CSE1)向位于CSE1内的服务启用器CSF发送服务描述。发起方包括按照RESTful资源的格式限定新服务所需要的信息。将资源表示包括在服务启用请求消息中。具体地，图15示出了<serviceDescription>1500资源的结构。<serviceDescription>1500资源与上文讨论的通用服务描述对应。‘M2M-SP-ID’、‘M2M-CSF-ID’、‘protocolRequired’、和‘serviceCompatabilty’中的每一个都是属性。而且，<CommonServiceAP>、<UniqueServiceAPI>、<DependentServiceList>、<accessControlMethods>、<softwareModule>、<chargingPolicy>、和<serviceLocation>都是子资源。子资源可以由属性进一步限定。

在图16所示的实施例中，对将采用所提出的服务启用器CSF的新服务添加至图14图示的oneM2M服务层的技术进行了描述。如图所描绘的，新服务由AE发起。图16中的各个步骤用数字(例如，1、2等)来表示。首先，AE向服务启用器CSF发送服务启用请求(步骤1)。针对该消息，可以使用CREATE请求。CREATE请求包含新服务的<serviceDescription>资源表示。

在接收到该请求时，服务启用器CSF根据先前在本申请中提供的描述来操作。主要地，服务启用器CSF将解析服务描述(步骤2)。基于在服务描述中限定的信息，将能够找出关于新服务的关键信息，诸如，由新服务提供的服务能力、与该新服务有关的其它服务。服务启用器CSF将发起涉及其它CSF的一系列操作以启用新服务，如在以下步骤中描述的。与其它CSF的交互是经由CSF间参考点进行的。

基于提供的访问控制方法(诸如，认证方法、授权与访问控制信息)，服务启用器CSF可以联系安全CSF以认证新服务(步骤3)。安全CSF可以批准认证(步骤4)。接着，服务启用器CSF触发新服务的注册进程(步骤5)。接着，如在本申请中讨论的，可以创建新服务的资源，并且新服务的资源可通过使用现有的发现CSF来发现(步骤6)。其可以重复使用现有的注册进程(步骤7)。

服务启用器CSF基于在服务描述中提供的“有关的服务列表”信息，来发起与其它CSF的交互。例如，其可以与计费CSF交互以添加由新服务提供的新计费策略(步骤8)。计费策略资源由计费CSF更新(步骤9)。而且，成功地创建新服务的计费策略，并且将其中继回服务启用器CSF(步骤10)。根据步骤11，存在与其它CSF的交互。最后，在与其它CSF(例如DMGCSF、应用和服务层管理CSF)的交互成功完成时，服务启用器CSF返回服务启用响应消息以指示新服务已经添加并且成功地集成在服务层处(步骤12)。

根据另一实施例，图17图示了所提出的新<service>1700资源，该新<service>1700资源与本申请中描述的公共服务API对应。出于图示之目的，仅提供了属性。未示出oneM2M限定的公共属性。当正在创建新服务时，在服务层处生成<service>资源的新实例。如上文讨论的，在本申请中，服务状态指示状态信息。注意，出于例如追踪和统计等目的，“已移除的”服务在服务层处仍然可以具有实例。服务链路指向专用于新服务的资源或者数据结构。如在先前的调用流中提到的，可以将这种数据结构作为软件模块上传。当创建了<service>资源的新实例时，将由想要创建新服务的始发方提供的<serviceDescription>与该实例一起存储。

在再一实施例中，图18图示了用于可扩展资源结构的通用模板。该模板可以应用于oneM2M服务层的任何现有和未来的资源。此处，类型是<existingResourceType>1800。将两个指示符添加至资源结构作为公共属性。一个指示符指示属性是否已经改变。其他指示符指示子资源是否已经改变。默认情况下，将这些指示符设置为“否”。当存在由于新服务的添加而创建的新属性或者子资源时，在服务启用器CSF与现有CSF交互时，将指示符改为“是”。其它CSF、CSE、和AE可以订阅这些指示符以得到改为其感兴趣的任何现有资源的通知。一旦将这种指示符改为“是”，则应该执行新资源发现过程(可以使用oneM2M服务层支持的现有资源发现)，从而使得可以发现对属性和子资源的改变。

OneM2M服务部件(SoA)架构实施例

根据本申请的另一实施例，如图19所示，对在oneM2M服务部件架构中的服务启用器功能的两种潜在实现方式架构进行了描述。在一个实施例中，服务启用器功能保留在各个服务部件(例如，服务部件1和服务部件N)中作为其中的功能。这可能是由于服务部件是提供一种或者多种服务的实体并且因此与其它服务部件松散地耦合。通过这种方式，各个服务部件可以独立地执行添加、启动、禁用、和移除在服务部件内的服务的进程。在可替代实施例中，通过插入称作‘服务启用器部件’的单独服务部件，来实现服务启用器功能。如果任何服务部件想要添加、启动、禁用、和移除服务，则其需要通过参考点‘Msc’与服务启用器部件合作。

根据再一实施例，图20示出了用于通过在AE提供新服务时添加该新服务来交换信息的方法。各个步骤用数字(例如，1、2等)来表示。首先，AE向在CSE(服务层)处的服务启用器部件发送新服务(步骤1)。“新服务”包括服务描述和软件模块。接着，服务启用器部件将新服务添加至oneM2M系统，在oneM2M系统中，服务能力与服务部件对应，M2M应用与AE对应，并且服务层与CSE对应(步骤2)。该步骤是发生在服务层处的服务启用进程。服务描述包含关于新服务的所有信息，从而使得服务启用器部件可以解析服务描述，即使服务启用器部件之前并不知道该服务。在添加新服务之后，服务启用器部件将软件模块传递给DMG部件(步骤3)。进一步地，DM部件将新服务的软件模块转发至在底层NSE中的相关联的DMS(步骤4)。最后，在底层NSE中的DMS将新服务的软件模块安装到DM客户端中的oneM2M CSE，从而启用了新服务(步骤5)。根据该步骤，DMS完成如在DM协议中限定的软件启用进程，但是DMS并不知晓服务层信息，包括：例如，服务ID、服务的能力和特征、和服务资源。

在可替代实施例中，图21图示了用于添加由AE发起的新服务的不同技术。图21中的各个步骤用数字(例如，1、2等)来表示。将服务启用请求发送至服务启用器部件(步骤1)。然后，将新服务添加至oneM2M系统(步骤2)。与图20形成对比，在添加新服务的进程期间，AE只提供访问软件模块的链路/URI(步骤3)。在底层网络中的DMS利用该链路来获取软件模块(步骤4)，并且安装软件模块以支持新服务(步骤5)。

根据再一实施例，图22示出了关于在服务提供商限定新服务时添加该新服务的信息交换。图22中的各个步骤用参考数字(例如，1、2等)来表示。在这种情况下，在底层NSE中的DMS首先安装软件模块(步骤1)。这是因为服务提供商限定了新服务，并且首先联系DM协议。然而，DM协议对服务层信息是透明的，例如，DM协议无法读取服务描述并且无法理解新服务是什么。接着，DMS向在CSE中的DM部件透明地发送服务描述(步骤2)。这是因为DMS不关心服务描述，并且由服务提供商触发以发送至服务层。随后，DM部件将新服务的服务描述透明地转发到服务启用器部件(步骤3)。进一步地，服务启用器部件将新服务添加到oneM2M系统中(步骤4)。

基于oneM2M功能架构的DM

根据再一实施例，图23示出了通过DM协议和oneM2M系统工作的服务启用器功能的架构2300。具体地，在CSE中的不同实体中实现服务启用器功能的三种功能。例如，CSF 2305保留在DMG CSF 2310内部。在这个意义上，DMG CSF负责驱动并且协调添加、启动、禁用、或者移除服务的过程。而且，SMCF和SAMF是实施为启用器功能的一部分的功能。如果将服务启用器功能的三个子功能实施在不同的物理位置中，则参考点‘In’将用于在这些子功能之中的消息交换。

另外，将服务感知功能(SAF)2315插入底层DM协议的DMS 2320中。因为当前DM协议不是服务感知的，例如，从服务层的角度看，DM协议不知道关于服务的任何事情，所以SAF要求在DM消息中的新指示字段指示是否有必要触发在服务层处的服务启用器功能。当更新或者安装软件模块时，SAF将检查新指示字段，该新指示字段将由提供软件模块的实体设置。

根据本申请的再一方面，公开了一种用于存储计算机可读或者可执行指令的非暂时性计算机可读或者可执行存储介质。该介质可以包括一个或者多个计算机可执行指令，诸如，上面根据图8至13、16、和20至22的多个调用流所公开的。可以将计算机可执行指令存储在存储器中并且由在上面在图1C和1D中公开的处理器执行，并且在装置(包括服务器、网关、和OneM2M装置)中采用。在一个实施例中，如在上文图1C和1D中描述的，公开了一种具有可操作地耦合至其的非暂时性存储器和处理器的计算机实现的UE。具体地，非暂时性存储器具有存储在其上的指令，该指令用于更新(例如，添加)网络中的服务。处理器被配置为执行以下指令：(i)在位于服务层的服务启用器功能处接收对添加服务的请求；(ii)审查请求的服务的服务描述以理解其能力；(iii)向位于服务层的服务能力发送验证请求；以及(iv)通知应用或者另一服务层启用了请求的服务。

在另一实施例中，非暂时性存储器具有存储在其上的指令，该指令用于更新(例如，移除)网络中的服务。处理器被配置为执行以下指令：(i)在位于服务层的服务启用器功能处接收对移除服务的请求；(ii)识别待移除的服务；(iii)向服务状态管理和配置功能发送服务状态更新请求；以及(iv)通知应用或者另一服务层已经移除了请求的服务。

虽然已经根据目前被认为是具体方面的内容对方法、系统、和软件应用进行了描述，但是不需要将本公开局限于所公开的方面。本公开旨在涵盖在权利要求书的精神和范围内的各种修改和相似的布置，该权利要求书的范围应该符合最广泛的解释以便包括所有这种修改和相似的结构。本公开包括以下权利要求书的任何和所有方面。

Claims (20)

1.一种用于在网络中管理服务的计算机实现的方法，所述方法包括：

在位于服务层功能的服务启用器功能处接收请求以通过服务API管理所述服务；

审查请求的所述服务的服务描述以理解其能力；

向位于所述服务层功能的服务能力发送验证请求，其中所述服务能力是由所述服务层功能支持的特定类型的服务；

管理用于请求的所述服务的所述服务API；以及

通知应用或者另一个服务层功能请求的所述服务被启用，

其中管理所述服务API包括：

将所述服务API集成到所述服务层功能中，从而使得所述另一个服务层功能或者应用能够发现并且利用请求的所述服务。

2.根据权利要求1所述的方法，其中所述服务API是RESTful。

3.根据权利要求1所述的方法，其中，所述服务启用器功能将所述服务API转换成可与托管在所述服务层功能中的其它服务兼容。

4.根据权利要求1所述的方法，其中，所述服务描述选择自服务提供商ID、服务ID、依赖服务列表、唯一RESTful服务API、公共RESTful服务API、所述服务的位置、认证方法、授权与访问控制信息、软件模块信息、协议支持、服务兼容性、计费策略、以及它们的组合。

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

在所述服务启用器功能处确定所述服务是现有服务的更新版本还是新服务。

6.根据权利要求5所述的方法，其中，所述确定步骤由服务状态管理和配置功能执行。

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

从所述服务能力接收启用了新服务的响应。

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

在所述服务启用器功能处确定向所述另一个服务层功能或者所述应用中的哪一个通知关于请求的所述服务。

9.根据权利要求8所述的方法，其中，所述确定步骤由服务协调功能执行。

10.一种用于在网络中管理服务的移除的计算机实现的方法，所述方法包括：

在位于服务层功能的服务启用器功能处接收请求以通过服务API管理所述服务的移除；

识别待移除的所述服务；

向服务状态管理和配置功能发送服务状态更新请求；

管理用于请求的所述服务的所述服务API，以移除或更新所述服务API；以及

通知应用或者另一个服务层功能已经移除了请求的所述服务，

其中当请求的所述服务是版本时，管理所述服务API包括移除在服务API中针对该版本的相应内容，同时维持所述服务API中的其它内容。

11.根据权利要求10所述的方法，其中，所述请求包括服务描述属性，所述服务描述属性选择自服务提供商ID、服务ID、软件模块信息、RESTful服务API、以及它们的组合。

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

确定要移除所述服务的版本还是整个所述服务。

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

向服务API管理功能发送移除所述服务的所述服务API的请求。

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

通知所述服务层功能中的服务能力已经移除了所述服务。

15.一种网络上的计算机实现的设备，所述设备包括：

非暂时性存储器，所述非暂时性存储器包括用于通过服务API管理服务的可执行指令；以及

处理器，所述处理器可操作地耦合至所述存储器，所述处理器包括：

包括服务能力的服务层功能；以及

用于管理所述服务和所述服务能力的服务启用器功能，所述服务启用器功能包括：

服务协调功能，所述服务协调功能被配置为使所述服务的处理和通信与所述服务能力、应用或者另一个服务层功能协调；

服务状态管理和配置功能，所述服务状态管理和配置功能被配置为管理所述服务的状态转变；以及

服务API管理功能，所述服务API管理功能被配置为管理更新服务的服务API。

16.根据权利要求15所述的设备，其中，所述服务协调功能、所述服务状态管理和配置功能、以及所述服务API管理功能彼此进行通信。

17.根据权利要求15所述的设备，其中，所述服务启用器功能通过添加、启动、禁用、或者移除所述服务来管理所述服务。

18.根据权利要求15所述的设备，其中，所述服务状态管理和配置功能描述所述服务的所述能力以便由所述应用或者其它服务发现并且利用。

19.根据权利要求15所述的设备，其中，所述设备是网络节点。

20.一种联网系统，所述联网系统包括：

根据权利要求15所述的设备；以及

应用域。