本申请主张2015年8月28日提交的第62/211,471号美国临时专利申请的权益，该临时专利申请的公开内容特此以引用的方式并入本文中就好像全文陈述那样。
背景技术：
从协议栈角度来看，中间件服务层通常放置在现有网络协议栈之上并且向客户端应用以及其它服务提供增值服务。因此，服务层经常被分类为“中间件”服务层。例如，图1示出位于IP网络栈与应用之间的服务层102。请注意，另一个实例可涉及将服务层102直接放置在诸如TCP或UDP等传送协议上方或诸如SOAP(图1中未示出)等非RESTful协议上方。
图2中示出网络内的中间件服务层实例的示例性部署场景。在这个实例中，服务层实例部署在各种网络节点(网关和服务器)上并且正向网络应用、装置应用和网络节点本身提供增值服务。
M2M/IoT服务层102是专门针对于为M2M/IoT型装置和应用提供增值服务的一类中间件服务层的实例。最近，若干行业标准组织中所描述的ETSI M2M(例如，oneM2M功能架构中所描述的oneM2M、oneM2M功能架构-V-1.10.0中所描述的oneM2M-TS-0001、机器对机器通信(M2M)功能架构草案ETSI TS 102 690 1.1.1(2011-10)，以及OMA轻量M2M(LWM2M)技术规范草案版本1.0-2013年3月14日中所描述的OMA LWM2M)一直在开发M2M/IoT服务层以解决与将M2M/IoT类型的装置和应用集成到诸如互联网/Web、蜂窝式、企业和家庭网络等部署中相关联的挑战。
M2M服务层102可向应用和装置提供对服务层102所支持的M2M中心能力集合的访问。一些实例包括安全性、计费、数据管理、装置管理、发现、提供和连接性管理。经由利用M2M服务层102所支持的消息格式、资源结构和资源表示形式的API将这些能力提供给应用。
oneM2M的目的和目标是开发解决对能够容易嵌入在各种硬件和软件平台内并且能够被依赖以用于将现场多种多样的装置与世界范围的M2M应用服务器连接的公共M2M服务层102的需要的技术规范。
oneM2M服务层支持一组公共服务功能(CSF)(即，服务能力)。一组一个或多个特定类型CSF的实例化被称为公共服务实体(CSE)(即，服务层)，其能够被托管在不同类型的网络节点(例如，基础设施节点、中间节点、专用节点)上。这些公共功能经由Mca、Mcc和Mcn参考点来暴露，如图3所示。Mca参考点指定应用实体(AE)与CSE之间的通信流，而Mcc参考点指定相同M2M服务提供商域中的两个CSE之间的通信流。跨Mca和Mcc的通信经由配对的请求/响应消息发生，其中每个请求对托管在目标CSE上的资源执行特定RESTful操作(例如，创建、检索、更新和删除)。在位于不同M2M SP的基础设施域中的CSE之间使用Mcc’。在CSE与底层网络服务实体(NSE)之间针对除了传送和连接性之外的服务使用Mcn。
CSE被托管在称为“节点”的架构实体上。节点是包含a)一个CSE和零个或多个AE，或者b)一个或多个AE的功能实体。oneM2M架构支持各种类型的节点配置，如图4所示。
图5中示出oneM2M所支持的公共服务功能(CSF)的初始集合。特定CSE具体实施可能不支持每个功能，但完整具体实施将包括图示中的所有功能。
按照oneM2M RESTful架构，CSF被表示为一组“资源”。资源是架构中的能够唯一寻址的实体，其具有能够经由诸如创建、检索、更新和删除等RESTful方法操纵的表示形式。使得这些资源能够使用统一资源标识符(URI)来寻址。资源可包含子资源和属性。子资源是与父资源具有包含关系的资源。父资源表示形式包含对其子资源的引用。子资源的寿命由父资源的寿命限制。每个资源支持存储关于所述资源的信息的一组“属性”。
认证是验证服务层注册者的身份与可信凭证相关联的过程。如何执行认证过程将取决于所使用的认证机制。例如，在基于证书的认证的情况下，认证通常涉及核实数字签名。在对称密钥认证的情况下，认证通常涉及核实消息认证码(MAC)。相互认证是在注册者与其正在注册的服务层之间发生的双向认证。因此，相互认证是服务层验证注册者的身份以及注册者验证服务层的身份的过程。
服务层授权机制用以控制对托管在服务层中的资源和/或服务的访问。授权通常涉及基于静态提供的授权策略和指配角色来允许经过认证的注册者访问托管在服务层中的资源和服务。授权策略是定义给定服务层注册者是否被准许访问托管在服务层中的受保护资源或服务的一组规则。这些策略可基于不同机制。三种常见类型的授权策略是授权列表(ACL)、基于角色的授权(RBAC)和基于订阅的授权(SBAC)。
服务层ACL定义哪些服务层注册者被准许访问哪些资源和服务以及其被允许对给定资源或服务执行哪些操作。例如，注册者123被允许读取(而不是写入)资源ABC。
服务层RBAC基于指配给注册者的特定角色来定义对资源或服务执行特定操作的特权。例如，注册者123可具有作为“管理员”的角色，而注册者456可具有作为“用户”的角色。RBAC可定义“管理员”具有对特定资源的读取和写入访问两者，而“用户”仅具有读取访问。
服务层SBAC基于注册者的订阅级别来定义对资源或服务执行特定操作的特权。例如，注册者123可具有基于订阅的成本来使其有资格访问某些类型的服务而不能访问其它服务的订阅。
ACL、RBAC和SBAC特权可基于服务层订阅模型来预先提供(即，带外配置)。例如，基于注册者已经在其本身与服务层提供商之间预先确立的服务层订阅的类型，订阅可确定在注册者尝试访问服务层资源和服务时许可其的特权的类型。
M2M服务层(例如，oneM2M、ETSI M2M、OMA LWM2M)是支持诸如上述授权机制等授权机制的服务层的实例。
请注意，本公开的焦点是增强与服务层授权(不是识别和认证)相关联的授权功能性。
oneM2M定义支持所配置的特权集合的现有<accessControlPolicy>资源，如图6A所示。特权可配置有一组授权规则(即，策略)，其定义哪些经过认证的服务层注册者具有访问与<accessControlPolicy>资源相关联的资源的特权。一旦配置，从服务层的角度来看，这些特权便通常为静态的。服务层在运行中不会动态创建、更新或删除特权。
至今，oneM2M已经基于ACL策略来定义特权。oneM2M将这个ACL策略定义为能够存储在特权属性内的一组访问控制规则元组，其中每个元组由三个分量组成：AccessControlOriginators、accessControlOperations、accessControlContext。
accessControlOriginators–被授权访问与这个授权策略相关联的资源的服务层注册者的集合(例如，CSE-ID或AE-ID的列表)。
accessControlOperations–每个被授权服务层注册者被授权执行的操作的集合(例如，创建、检索、更新和删除)。
accessControlContext–oneM2M当前定义以下三种类型的授权上下文：
○accessControlTimeWindows-允许请求的时间窗口。在这个时间之外对与这个授权策略相关联的资源发生的请求将被拒绝。
○accessControlLocationRegions-服务层注册者被允许在访问与这个授权策略相关联的资源时所位于的位置的列表。来自于不在这个列表中的位置的服务层注册者的请求将被拒绝。
○accessControlIpAddresses-被允许访问与这个授权策略相关联的资源的服务层注册者的IP地址。来自于具有不在这个列表中的IP地址的服务层注册者的请求将被拒绝。
OAuth 2.0授权框架代表资源拥有者使得第三方客户端应用能够获得对HTTP资源的访问。OAuth规定用于资源拥有者授权第三方访问其资源而不共享其凭证的过程。专门设计来与超文本传输协议(HTTP)一起工作，OAuth基本上允许在资源拥有者同意下由授权服务器向第三方客户端应用发布访问令牌。应用接着使用访问令牌来访问资源服务器所托管的受保护资源，如图6B所示。
在图6B的步骤A中，客户端向资源拥有者请求授权。可直接向资源做出授权请求。
在图6B的步骤B中，客户端接收授权许可，其是表示资源拥有者的授权的凭证。
在图6B的步骤C中，客户端通过向授权服务器进行认证并且呈现授权许可来请求访问令牌。
在图6B的步骤D中，授权服务器认证客户端并且验证授权许可，并且如果有效，则发布访问令牌。
在图6B的步骤E中，客户端向资源服务器请求受保护资源并且通过呈现访问令牌来认证。
在图6B的步骤F中，资源服务器验证访问令牌，并且如果有效，则服务所述请求。
技术实现要素：
可扩展的基于策略的服务层动态授权框架可允许服务层确定许可还是拒绝注册者访问注册者当前缺少适当特权来访问的服务层所托管的资源或服务。这种方法还可使得服务层能够动态更新其静态配置的授权特权(通过利用其动态授权结果)，使得来自相同注册者并且去往相同资源和服务的将来请求不需要执行动态授权。
可使用一种用于允许服务层注册者针对其资源或服务指定基于咨询的动态授权策略的方法，服务层可接着使用基于咨询的动态授权策略来咨询注册者以确定向其他服务层注册者许可还是拒绝访问其资源或服务的特权。
可使用一种用于服务层注册者针对其资源或服务指定基于支付的动态授权策略的方法，服务层可接着使用基于支付的动态授权策略来支持对其他注册者的动态授权。其中基于其他服务层注册者愿意支付访问所述资源或服务的费率来许可或拒绝特权。
可使用一种用于服务层注册者针对其资源或服务指定基于互换的动态授权策略的方法，其中这些策略允许服务层代表想要以对其自己的资源或服务的访问作为交换来获得对其他注册者的资源和服务的访问的注册者动态进行互换。
可使用一种用于服务层注册者针对其资源或服务指定基于安全性评估的动态授权策略的方法，其中这些策略允许服务层动态评估想要获得对其他注册者的资源和服务的访问的注册者的安全性级别并且确定其安全性级别是否满足动态授权要求。
可使用一种用于服务层注册者针对其资源或服务指定基于声誉的动态授权策略的方法，其中这些策略允许服务层动态评估想要获得对其他注册者的资源和服务的访问的注册者的声誉级别并且确定其声誉是否满足动态授权要求。
描述用于基于oneM2M的系统的所提出的服务层动态授权特征的实施例。实施例包括oneM2M架构、资源级、消息传送级和过程级提议，其描述可如何在oneM2M系统中实现本公开所定义的服务层动态授权特征。
请注意，虽然取决于M2M/IoT服务层来描述本公开中所定义的方法和实施例，但这些想法还可应用于其它类型的服务层。
提供本发明内容来以简化形式介绍精选的概念，所述概念在下文中在具体实施方式中进一步描述。本发明内容既不希望识别所主张的主题的关键特征或基本特征，也不希望用于限制所主张的主题的范围。此外，所主张的主题不限于解决本公开的任何部分中所提到的任何或所有缺点的限制。
附图说明
可从以下描述获得更详细的理解，以下描述是结合附图借助于实例来给出的，其中：
图1是支持中间件服务层的协议栈的图。
图2是网络内的示例性中间件服务层部署的图。
图3是oneM2M架构的图。
图4是oneM2M架构配置的图。
图5是oneM2M CSF的图。
图6A是oneM2M<accessControlPolicy>资源的图。
图6B是OAuth 2.0授权框架的图。
图7是服务层本地执行的服务层动态授权的图。
图8是经由咨询执行的服务层动态授权的图。
图9是服务层动态授权功能的图。
图10是部署为服务层中的本地功能的SLDA 902的图。
图11是与服务层分开部署的SLDA 902的图。
图12是与服务层分开部署的SLDA 902的图。
图13是与服务层分开部署的SLDA 902的图。
图14是静态和动态策略管理的图。
图15是策略提供过程的图。
图16是针对资源创建和托管访问策略的图。
图17是客户端请求访问受控资源的图。
图18是使用推模型的资源访问的图。
图19是支付授权过程的图。
图20是基于拉模型的授权的图。
图21是基于推确认模型的授权的图。
图22是基于间接推模型的授权的图。
图23是集中部署在oneM2M MEF 2304、MAF 2302或CSE实体上的SLDA功能性的图。
图24是跨oneM2M MEF 2304、MAF 2302和CSE实体分布部署的SLDA功能性的图。
图25是<dynAuthPolicy>oneM2M资源的图。
图26是经由dynAuthPolicyIDs属性链接到<dynAuthPolicy>的图。
图27是作为<accessControlPolicy>的子资源的<dynAuthPolicy>的图。
图28是经由添加到<accessControlPolicy>的dynAuthPolicyIDs属性链接<dynAuthPolicy>的图。
图29是合并到<accessControlPolicy>中的<dynAuthPolicy>属性的图。
图30是<dynAuthRequest>虚拟资源的图。
图31是在CSEBase下实例化的<dynAuthRequest>的图。
图32是在<AE>资源下实例化的<dynAuthRequest>的图。
图33是<consult>虚拟资源的图。
图34是服务层动态授权策略的配置的图。
图35是自主服务层动态授权处理的图。
图36是显式服务层动态授权请求处理的图。
图37是基于咨询的服务层动态授权的图。
图38是基于支付的服务层动态授权的图。
图39是基于互换的服务层动态授权的图。
图40是基于安全性评估的服务层动态授权的图。
图41是基于服务层订阅核实的动态授权的图。
图42是基于声誉的服务层动态授权的图。
图43是一个实施例的图形用户界面的图。
图44A是包括通信网络的M2M/IoT/WoT通信系统的图。
图44B是场域中的所示M2M服务层的图，M2M服务层为M2M应用、M2M网关装置和M2M终端装置以及通信网络提供服务。
图44C是可用以实施本文所述的网络节点中的任一者的示例性装置的图。
图44D是可用以实施本文所述的网络节点中的任一者的计算机系统或服务器的框图。
具体实施方式
AAA 认证、授权和结算
ACL 访问控制列表
ACP 访问控制策略
AE 应用实体
API 应用编程接口
CSF 能力服务功能
CSE 能力服务实体
IoT 物联网
MAC 消息认证码
MAF M2M认证功能
MEF M2M登记功能
M2M 机器对机器
NSE 网络服务实体
PA 策略管理
PD 策略确定
PE 策略实施
PI 策略信息
RBAC 基于角色的授权
SBAC 基于订阅的授权
SLDA 服务层动态授权
SLSA 服务层静态授权
SP 服务提供商
URI 统一资源标识符
网络节点可为托管资源或服务的网络内的可寻址实体。网络节点可为网络中的物理实体(例如，装置、网关或服务器)或虚拟实体(例如，虚拟机)。
资源可为具有能够经由诸如创建、检索、更新和删除等RESTful方法操纵的表示形式的可寻址实体。
服务可为经由所支持的接口访问的相关软件功能性的集合(例如，数据存储服务)。
服务层102可为托管通过一组应用编程接口(API)和底层联网接口提供给服务层注册者的资源和服务的软件层。
服务层注册者可为向服务层注册的实体。例如，应用、各个服务或服务层的另一个实例。
在一个实施例中，服务层动态授权可包括1)许可还是拒绝用于访问请求者当前缺少适当特权来访问的服务层所托管的资源或服务的特权，以及2)是否使用动态授权结果更新静态授权特权，使得来自相同注册者并且去往相同资源和服务的将来请求不需要执行动态授权。
公共服务功能(CSF)是用于服务层所支持的服务的oneM2M术语。公共服务实体CSE是用于服务层的oneM2M术语。
现有服务层(例如，oneM2M功能架构中所描述的oneM2M、oneM2M功能架构-V-1.10.0中所描述的oneM2M-TS-0001、机器对机器通信(M2M)功能架构草案ETSI TS 102 690 1.1.1(2011-10)中所描述的ETSI M2M，以及OMA轻量M2M(LWM2M)技术规范草案版本1.0-2013年3月14日中所描述的OMA LWM2M)支持用于控制其准许其注册者(例如，M2M/IoT装置)访问哪些服务或资源以及注册者被允许对这些资源和/或服务执行的操作的类型的授权机制。然而，这些服务层授权机制通常被配置为在本质上为静态的(例如，预先提供的)并且因此具有以下缺点：
缺点#1–缺少对通过动态添加新权限来允许服务层注册者获得对其没有权限访问的资源进行访问的支持。因而，注册者被限于仅访问其已经静态预先提供授权策略进行访问的那些资源和/或服务。
缺点#2–缺少对先进授权机制的支持，该机制允许拥有或管理托管在服务层中的资源或服务的注册者指定关于咨询的授权，其是通过服务层对注册者执行，以确定注册者是否想要对尝试访问其资源或服务但没有适当特权来这样做的其他注册者许可还是拒绝访问。因而，注册者不能够检测是否/何时其他注册者对访问其资源或服务感兴趣并且继而是否针对此类请求动态授权访问。
缺点#3–缺少对允许拥有或管理托管在服务层中的资源或服务的注册者取决于请求注册者愿意支付来访问的费率/费用指定授权的先进授权机制的支持。因而，注册者不能够允许服务层基于其他注册者愿意支付来访问而向其动态授权访问。
缺点#4–缺少对允许拥有或管理托管在服务层中的资源或服务的注册者取决于请求注册者愿意同意的互换协定来指定授权的先进授权机制的支持。例如，注册者之间的其将许可对彼此资源的访问的双边协定。因而，注册者不能够互换并且使用其资源作为商品来动态获得对其他注册者的资源或服务的访问。
缺点#5–缺少对允许拥有或管理托管在服务层中的资源或服务的注册者取决于注册者必须满足的所需要安全性评估级别来指定授权的先进授权机制的支持。例如，注册者不能够配置服务层以基于其他注册者满足服务层动态执行的安全性级别评估(例如，平台满足某些安全性要求)来向之动态授权对其资源或服务的访问。
缺点#6–缺少对允许拥有或管理托管在服务层中的资源或服务的注册者取决于注册者必须满足以便被授权的所需要声誉评估级别来指定授权的先进授权机制的支持。例如，注册者不能够配置服务层以基于其他注册者满足声誉级别评估(例如，注册者满足某个满意度级别(诸如“5颗星中的4颗星”)的同行评审)来向之动态授权对其资源或服务的访问。
以下使用案例描述了服务层以及其增值能够如何支持服务层动态授权。在这个使用案例中，应用#1 202创建托管在服务层中的名为XYZ的资源。应用#1 202接着针对资源XYZ使用一组静态访问特权配置访问控制策略。静态访问特权定义规则，诸如被允许访问资源XYZ的其它应用的列表以及其可对之执行什么操作等。服务层使用这些特权来控制哪些应用被允许访问资源以及其被允许对资源执行哪些操作。应用#1 202可使用其知道并且其想要向之许可访问的已知应用配置这些特权。应用#1 202还可针对资源配置动态授权策略。这个策略定义服务层可用来支持动态创建、更新或删除静态访问特权的规则。这对支持新的/不同的应用尝试访问资源但应用#1 202先前不知道与这些应用的关系并且因此尚未配置静态特权来向其许可对资源的访问的情况特别有用。
在这个使用案例中，应用#2 204是应用#1尚未向之许可静态访问特权的应用的实例。应用#2 204执行对资源XYZ的请求。服务层首先检查静态访问特权并且发现应用#2 204尚未被许可特权。服务层102接着检查是否已经配置动态授权策略。如果是，则服务层102可支持用以评估是否更新静态访问特权并且向这些应用许可访问特权的功能性。动态授权功能性可由服务层102使用所配置的动态授权策略在本地执行，如图7所示。另选地，服务层102可支持向系统中的其它实体(例如，授权服务器)咨询以使其协助服务层102执行动态授权，如图8所示。
应当理解，执行图7至8所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图7至9所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图7至8所示的步骤。还应当理解，图7至8所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其执行的计算机可执行指令(例如，软件)的控制下执行。
服务层动态授权功能
所提出的框架由服务层动态授权(SLDA)功能902构成，如图9所示。这个功能支持服务请求以确定请求者是否应被许可对请求者尚未具有预先确立的访问特权的由服务层托管的所需资源或服务的访问特权。这个功能由以下四个子功能构成，也在图9中示出。
●策略管理功能(SLDA-PA)904–管理服务层动态授权策略。
●策略决定点(SLDA-PD)908–评定并且发布服务层动态授权决定。
●策略执行点(SLDA-PE)910–拦截对服务层资源或服务的请求并且执行SLDA-PD的决定。
●策略信息点(SLDA-PI)906–向SLDA-PD 908提供额外上下文信息，诸如安全性、支付、位置和声誉评估。
应当理解，图9所示的功能性可以存储在M2M网络的节点(例如，服务器、网关、装置或其它计算机系统)(诸如下文所述的图44C或44D所示的那些节点中的一者)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施。
服务层动态授权部署方案
SLDA功能902支持若干灵活部署方案。SLDA功能902可被部署为服务层的本地功能，在该情况下服务层可原生地支持动态授权功能性，如图10所示。
SLDA功能902还可与服务层分开地部署，如图11所示。在这种情况下，SLDA 902可被部署为网络中的独立功能或者可被部署为另一个实体(例如，安全性服务器)的子功能。
SLDA 902还可以集中式方式部署，在该情况下单个SLDA功能902可服务来自多个服务层实例以及应用的动态授权请求。在这个部署方案中，所有动态授权管理、决定以及执行由集中式SLDA 902执行，如图12所示。
相反，SLDA 902可以分布式方式部署，在该情况下SLDA 902或其子功能可分布在整个网络中。例如，SLDA-PI、SLDA-PA 904和SLDA-PD 908子功能可被部署在网络中的集中式节点上，而单独的SLDA-PE 910子功能可遍及网络本地部署在每个服务层实例内，如图13所示。在这个分布式方案中，动态授权策略信息、管理和决定可由集中式SLDA-PD 908做出，而这些决定的结果可由各个服务层的各个SLDA-PE针对其所处理的每个请求来执行。
应当理解，图10至13所示的功能性可以存储在M2M网络的节点(例如，服务器、网关、装置或其它计算机系统)(诸如下文所述的图44C或44D所示的那些节点中的一者)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施。
服务层动态授权过程
授权过程：该授权过程涉及：
●一般授权规则的提供
○向SLSA-PD 1406、SLSA-PE 1410和SLSA-PI 1412提供静态规则和参数
○向SLDA-PD 908、SLDA-PE 910和SLDA-PI 906提供动态规则和参数
○提供用以在静态规则与动态规则之间协调的逻辑/规则
●粒度资源特定的授权规则的创建
○用于资源访问的静态规则的创建
○用于资源访问的动态规则的创建
●向被授权实体提供对资源的访问涉及：
○向实体传达动态授权规则
○提供用于实体获得各种授权级别(AuthLevel)的机制
○提供各种类型的动态授权(以下一个或多个的组合)：
■经过认证(单因素、多因素)
■平台完整性
■应用或装置类型
■未经认证
■基于支付或订阅
■基于声誉
■基于互换(数据/资源的交换)
授权规则的提供
图14描绘了涉及静态策略和动态策略两者的策略管理(提供、决定和执行)框架。IoT服务提供商可具有现有静态访问策略管理，在引入动态授权的情况下，服务层策略协调功能(SL-PCF)1408能够处理动态策略与静态策略的协调以及那些策略的执行。SLDA-PA 904和SLSA(服务层静态授权)-PA 1404功能分别提供动态策略和静态策略。SLSA-PA 1404配置适当PD策略(在安全性服务器2处)以及相应实体(例如，安全性网关)处的PE策略。
应当理解，图14所示的功能性可以存储在M2M网络的节点(例如，服务器、网关、装置或其它计算机系统)(诸如下文所述的图44C或44D所示的那些节点中的一者)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施。
图15描绘策略提供过程，其中实施SLDA-PE 910、SLDA-PD 908和SLDA-PI 906功能的实体1502被提供适当的策略。下文提供详细的消息传送：
在任何适用之处并且在安全性为关键的地方，在一个实体与另一个实体之间发生的所有通信可经由安全通信信道(例如，使用TLS/SSL连接)发生并且以端对端方式保护。
在图15的步骤1中，实体1502请求检索与PE和PD相关的策略以及用于PI的参数的适当集合。检索过程可被周期性地触发或者由来自实施SLDA-PA 904的策略服务器1504的带内或带外信令触发。策略服务器1504可调用装置管理服务器的服务或可与之共同托管。实体1502通过包括标识资源的可选策略-id来发送对策略的请求。
在图15的步骤2中，SLDA-PA 904检查以查看是否存在授权实体1502获得策略的现有静态访问控制策略(S-ACP)。SLSA 1402/SLDA 902–PA检查与PA相关联的SAPD-PA 904(静态授权策略数据库)以检查实体1502是否已经被授权来被提供有PD/PE相关策略。如果针对实体1502存在条目并且倘若授权级别满足策略提供要求，则处理跳到步骤10。
在图15的步骤3中，如果在SAPD中不存在用于实体1502的条目，则PA查询动态授权策略数据库(DAPD)以便确定实体1502可如何能够被授权。
在图15的步骤4中，策略服务器1504接着请求实体1502执行包含动态授权规则(DAR)的动态授权请求(DARequest)消息。该规则可指示：
a.授权级别
b.显式授权机制(例如，认证、支付/订阅、平台验证/完整性检查等)
在图15的步骤5中，实体1502使用对应动态授权启用功能(DAEF)1802执行所需要的授权检查过程，这在稍后部分中详细描述。基于所实行的检查，实体1502从对应DAEF获得动态授权参数(DAP)，或者可由实体1502确定或生成。DAP可为被数字签名(例如，签名的授权令牌、访问令牌)、未被签名、消息传送(XML消息传送)、JSON数据等的密码凭证。DAP可包括含有各种授权检查的结果的参数，或者授权检查中的每一者可导致单独的DAP。
在图15的步骤6中，实体1502接着使用动态授权响应(DAResponse)消息向策略服务器1504/PA发送DAP。
在图15的步骤7中，策略服务器1504/DA核实DAP并且检查以确保已经满足DAR。
在图15的步骤8中，策略服务器1504更新静态策略(SAPD)以包括实体-id(Entity-id)、res-id、允许的操作(例如，检索)、标识DAP的DAP-Id以及所允许授权的持续时间。
在图15的步骤9中，SAPD-PA接着提供PE-规则、PA-规则和PI-数据以及批准的授权规则(AAR)。AAR可包含关于以下各项的信息：
a.所实现的授权级别(AuthLevel)
b.能够执行的操作的类型(创建/更新/检索/删除)
c.能够对其执行操作的资源/资源树
d.授权的长度(有效性/有效期)
e.必须被执行以增强AuthLevel的机制的列举
f.永远不能执行的资源/操作
应当理解，执行图15所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图15所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图15所示的步骤。还应当理解，图15所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
资源特定的授权规则的创建
实体(实体A 1602)(其可为资源生成者或拥有者)请求将数据托管到资源托管功能(RHF 1604)上。RHF 1604可实施SLDA功能性(PE、PD和PI)。此处假设，与关联于实体的授权规则相关的所有策略已经被预先提供并填充到SAPD上，并且基于6.3.1中所描述的机制来将动态策略提供到DAPD上。用于所示图16的消息传送细节如下：
在图16的步骤1中，请求资源(TempReading1)(具有相关联的资源-id(Resource-id))的托管/创建的实体连同相关联的静态ACP(S-ACP)以及动态ACP(D-ACP)被作为资源注册请求(RRRequest)消息的一部分发送到实施SLDA的RHF 1604。
在图16的步骤2中，RHF 1604基于使用SAPD执行的检查来检查以查看实体A 1602是否具有授权。如果存在条目，则消息传送跳到步骤9。
在图16的步骤3中，如果没有S-ACP匹配于来自实体的请求，则RHF 1604从DAPD获得动态授权规则。
在图16的步骤4中，RHF 1604使用动态授权请求(DAR)消息将规则(DAR)发送到实体A 1602。
在图16的步骤5中，实体A 1602基于从RHF 1604获得的DAR来执行各种授权检查。实体A 1602获得/生成担保授权检查的DAP。
在图16的步骤6中，实体A 1602使用DAResponse消息将DAP发送到RHF 1604。
在图16的步骤7中，RHF 1604对DAP执行检查并且核实其匹配DAR。
在图16的步骤8中，如果DAP被成功核实，则使用指示Entity-id、允许的操作、可访问的资源、DAP-Id、有效性等的适当值填充SAPD。
在图16的步骤9中，RHF 1604注册并创建实体A 1602资源，并且使S-ACP和D-ACP与实体A 1602资源相关联。
在图16的步骤10中，RHF 1604转发包含AAR的RRResponse。
应当理解，执行图16所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图16所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图16所示的步骤。还应当理解，图16所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
授权访问过程
图17描绘想要访问托管在RHF 1604上的资源的客户端1702。RHF 1604实施SLDA-PE 910、PI、PD功能，并且另外还托管PA功能。因此，系统管理员将能够借助于PA使用RHF 1604上的界面配置PE和PD策略。消息流程可被视为图16中所描绘并且6.3.2中所描述的先前流程的接续。消息传送细节如下：
在图17的步骤1中，客户端1702发送包含Resource-id(可选地，资源的名称和所请求的操作的类型)的资源访问请求(RARequest)消息。其还可显式地请求所述资源持续某个持续时间，这是可选的。
在图17的步骤2中，RHF 1604基于S-ACP确定客户端1702是否被授权。如果其被授权，则消息传送跳到步骤10。
在图17的步骤3中，如果客户端1702不被授权，则RHF 1604确定动态授权策略(D-ACP)并且创建DAR。如果在RARequest内存在“持续时间”值，则可定制D-ACP以满足“持续时间”值。如果持续时间“值”高于阈值，则可能必须执行更高级别的授权。
在图17的步骤4中，RHF发送包含DAR的DARequest。
在图17的步骤5中，客户端1702使用适当DAEF执行适当授权检查以便满足DAR。客户端1702获得或生成担保各种检查的DAP。
在图17的步骤6中，客户端1702使用包含DAP的DAResponse消息向RHF 1604发送DAP。
在图17的步骤7中，RHF 1604核实DAP并且与DAR进行比较。
在图16的步骤8中，如果DAP满足DAR的要求，则RFH可使用Client-Id、res-id、op、持续时间、DAP-Id更新SAPD。
在图17的步骤9中，RHF 1604发送包含资源和AAR的RAResponse消息。
应当理解，执行图17所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图17所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图17所示的步骤。还应当理解，图17所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
分布式策略实体和授权模型
关于图16和17，诸如PD和PE等策略功能被托管在相同实体(例如，RHF 1604)上。此处，我们提供多种机制，其中SLDA-PD 908/SLDA-PI可被托管在相同实体上，而SLDA-PE 910被托管在RHF 1604上。另外，探索支持各种授权模型的解决方案。
推模型
推模型可在RHF 1604为受约束实体而客户端1702被假定为不受约束或受较少约束的装置时适用。如先前提到，需要高度安全性的所有通信可经由受保护以实现机密性、完整性和认证的安全通信信道(例如，使用TLS/SSL)来传送。图18示出了使用推模型的资源访问。消息传送细节如下：
在图18的步骤0中，此处假设客户端1702发现资源和相关联的Resource-id以及可能够授权客户端1702以使得客户端1702能够访问资源的SLDA-PD 908。
在图18的步骤1中，客户端1702发送包含客户端-id(Client-Id)和资源id(Res-id)的DARequest。
在图18的步骤2中，SLDA-PD 908基于所提供的规则获得使得Client-Id所标识的客户端1702能够访问Res-id所标识的资源的动态授权策略。PD可在一些情况下必须基于Client-Id和Res-id来生成动态授权策略。
在图18的步骤3中，PD发送包含与每个DAEF 1802相关联的URI的列举并且还包含与每个授权检查相关联的授权级别(AuthLevel)的列举的授权检查请求(ACRequest)。下面提供AuthLevel的实例：
a.认证：AuthLevel＝高/中/低
b.平台完整性/验证：AuthLevel＝高/中/低
c.订阅：AuthLevel＝铂/金/银
d.声誉：AuthLevel＝高/中/低
在图18的步骤4中，客户端1702执行授权检查过程(ACProcess)，其在6.3.4.2中稍微详细地描述。客户端1702可基于所提供的DAEF1802列举和每个检查的相关联AuthLevel来使用多因素认证服务器、支付服务器、平台验证服务器等执行检查。这个过程可为带内过程或可在带外执行。基于场景和使用案例，有可能跳过认证，尤其是在请求匿名访问时。
在图18的步骤5中，作为ACProcess的结果，可生成许多授权检查值(ACV)，其是确认授权检查中的每一者的原始数据。额外地并且可能可选地，可针对每个授权检查创建DAP。DAP担保授权检查，其可被视为仅包含授权所需要的相关信息的ACV的压缩版本。客户端1702将ACV/DAP发送到PD。
在图18的步骤6中，一旦PD核实ACV/DAP的真实性、完整性和准确性，PD便可将所有DAP合并到被数字签名的单个C-DAP或者对每个DAP进行数字签名并且将其转发到客户端1702。
在图18的步骤7中，客户端1702创建包含Res-id、op和DAP的RARequest并且发送到RHF 1604。
在图18的步骤8中，由于客户端1702已经发送DAP，所以实施PE的RHF 1604推断在静态策略中可能不存在条目并且因此不检查SAPD-PE而是改为通过检查DAPD-PE中的D-ACP来检查DAP匹配与res-id相关联的动态授权策略的要求。
在图18的步骤9中，如果DAP满足授权要求，则PE使用Client-Id、res-id、op、持续时间、DAP-Id、可选地DAP来更新SAPD-PE。DAP可被分开存储，由DAP-Id标识，因为DAP的大小可能较大并且管理起来较繁琐。
在图18的步骤10中，RHF 1604将资源以及相关联的AAR发送到客户端1702。
应当理解，执行图18所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图18所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图18所示的步骤。还应当理解，图18所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
授权检查过程(ACProcess)
图19描绘涉及包含支付过程的过程的ACProcess。可有可能的是客户端1702不知道DAEF支付服务器，然而，客户端1702信任SLDA-PD 908，所述SLDA-PD 908信任DAEF支付服务器。消息传送细节：
在图19的步骤4a中，客户端1702向DAEF支付请求支付授权。客户端1702可由SLDA-PD 908重新定向或由SLDA-PD 908提供DAEF支付服务器的URI或由客户端1702发现。客户端1702执行支付请求(PaymentRequest)并且提供货币和支付额(例如，虚拟货币)、将交易与SLDA-PD ACRequest绑定的请求-Id(Request-Id)。
在图19的步骤4b中，DAEF 1802起始PaymentTransaction过程，其中客户端1702向DAEF 1802发送金额。
图19的步骤4c生成详细说明那个交易的ACV，并且可可选地生成提供支付和交易的核实的DAP。支付DAP可使用JSON数据、XML、CBOR数据、显式消息、JSON Web令牌等来表示。下面提供DAP支付的优选内容的列表：
●Transaction-id：542912379542395
●Request-Id：
●Redeemer-Id：SLDA-PD-URI
●日期：13/11/15
●时间：23:23
●发布者：DAEF支付URI
●发布到：客户端
●货币：比特币
●金额：100.00
●发布者的数字签名：D28B45BA234C452DB……
在图19的步骤4d中，DAEF 1802将DAP/ACV转发到客户端1702。可选地，DAEF支付向客户端1702仅提供DAP-Id。
在图19的步骤5中，客户端1702将包含DAP以及可选地ACV的ACResponse发送到SLDA-PD。这个消息可由DAEF 1802重新定向到SLDA-PD 908或由客户端1702发送。SLDA-PD 908登记Transaction-id、支付信息、Request-Id和其它相关信息，并且提供适当授权确认。SLDA-PD 908必须确保客户端1702不会重播支付DAP。如果客户端1702仅提供DAP-Id，则SLDA-PD 908必须从DAEF 1802取出DAP，并且一旦被核实，则使得交易为“被足”，这暗示着DAEF 1802认为支付已被偿还并且无法再次使用交易信用。
必须注意到，上文针对图19所描述的授权检查过程处理支付授权，然而，类似机制可用以执行其它授权检查(例如，多因素认证、平台验证、订阅等)。图19的步骤4b可用客户端与用以执行其它授权检查的对应DAEF之间的消息替换。还有可能的是通过利用诸如OpenID、OpenID连接、EAP、SAML等协议框架来执行授权检查并且将此处所描述的机制搭载在那些现有协议框架上方。
应当理解，执行图19所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图19所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图19所示的步骤。还应当理解，图19所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
拉模型
受约束客户端1702可请求对资源的访问并且执行RHF 1604所促进的授权。下文关于图20提供消息传送细节：
在图20的步骤1中，客户端1702使用RRRequest向RHF 1604请求Res-Id所标识的资源、op＝“检索”。RHF 1604实施SLDA-PE 910功能性。
在图20的步骤2中，RHF 1604通过检查静态SAPD-PE来检查S-ACP以核实客户端1702是否已被授权。如果客户端1702被授权对资源执行操作，则消息传送跳到步骤12。
在图20的步骤3中，SLDA-PE 910检查动态授权策略并且确定DAR。
在图20的步骤4中，SLDA-PE 910创建包含DAR、Client-Id和Res-Id的DARequest并且将其发送到SLDA-PD。另选地，PE提供授权检查ACList[]和预期实现的相关联AuthLevel[]的显式列表。
在图20的步骤5中，SLDA-PD 908确定将必须被联系以使得实行授权并且实现AuthLevel的DAEF。
在图20的步骤6中，SLDA-PD 908将包含Client-Id和相关联AAL的ACRequest发送到所述DAEF中的每一者。
在图20的步骤7中，客户端1702和每个DAEF针对授权检查(例如，支付、平台验证、认证等)中的每一者执行6.3.3中所描述的ACProcess。客户端1702与每个DAEF之间的消息传送可经由RHF 1604执行为带内或带外消息传送或通过其它装置以直接方式执行。
在图20的步骤8中，针对每个ACProcess，DAEF将ACV/DAP发送到SLDA-PD。
在图20的步骤9中，SLDA-PD 908核实每个ACV/DAP并且可选地创建合并DAP(C-DAP)，其包括来自每个DAEF 1802的各个DAP中的每一者中提供的信息并由SLDA-PD 908数字签名，并且使用DAResponse发送到RHF 1604。或者，SLDA-PD 908发送每个DAP而不合并或签名。
在图20的步骤10中，SLDA-PE 910核实DAP并且确保其匹配与资源相关联的D-ACP。
在图20的步骤11中，如果DAP匹配于要求，则SLDA-PE 910使用Client-Id、Res-Id、op、持续时间、DAP-Id、DAP(可选的)更新SAPD-PE 910中的静态访问策略。
在图20的步骤12中，SLDA-PE 910/RHF 1604将资源和AAR发送到客户端。
应当理解，执行图20所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图20所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图20所示的步骤。还应当理解，图20所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
推确认模型
推确认模型非常紧密遵循推模型。下文中提供消息传送细节，其反映所示图21：
在图21的步骤1中，客户端1702请求包含Res-Id、Client-Id、op的DARequest。
在图21的步骤2中，SLDA-PD 908基于Client-Id、Res-Id和op来确定D-ACP的正确集合。
在图21的步骤3中，SLDA-PD 908发送包含DAEF-URI[]和相关联AAL[]的列表的ACRequest。
在图21的步骤4中，客户端1702向每个DAEF并且基于与每个授权检查相关联的AAL来执行ACProcess。客户端1702被提供ACV-Id和/或DAP-Id，而不是ACV或DAP。
在图21的步骤5中，客户端1702使用ACResponse将ACV-Id和/或DAP-Id转发到SLDA-PD 908。
在图21的步骤6中，SLDA-PD 908向DAEF 1802中的每一者执行包含ACV-Id和/或DAP-Id的ACV请求。
在图21的步骤7中，DAEF使用ACV响应消息向对应ACV和/或DAP做出响应。
在图21的步骤8中，SLDA-PD 908借助于包含ACV[]和/或DAP[]的DAP生成请求(DAPGRequest)消息向DAP生成器功能(DGF)2102请求创建C-DAP。
在图21的步骤9中，基于ACV[]和/或DAP[]，DGF 2102生成C-DAP和相关联C-DAP-Id并且将其存储在DAP数据库(DAP-D)内。
在图21的步骤10中，DGF 2102将C-DAP-Id发送到SLDA-PD。
在图21的步骤11中，SLDA 902使用DAResponse消息将C-DAP-Id发送到客户端1702。
在图21的步骤12中，客户端1702向RHF 1604执行包含Res-Id、op、Client-Id、C-DAP-Id的RARequest。
在图21的步骤13中，RHF 1604使用DAPRequest消息将C-DAP-Id发送到DGF 2102。
在图21的步骤14中，DGF 2102可在向RHF 1604提供C-DAP之前核实其授权。
在图21的步骤15中，RHF 1604使用D-ACP核实C-DAP。
在图21的步骤16中，如果C-DAP满足授权要求，则RHF 1604使用Client-Id、Res-Id、op、持续时间、C-DAP-Id和C-DAP(可选)更新SAPD-PE。
在图21的步骤17中，RHF 1604将资源和AAR发送到客户端1702。
应当理解，执行图21所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图21所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图21所示的步骤。还应当理解，图21所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
间接推
图22中示出的是基于间接推模型的授权。消息传送细节如下：
图22的步骤1至4与在图21中相同。
在图22的步骤5中，客户端1702针对所执行的每个授权检查获得/生成ACV[]和/或DAP[]，并且将包含ACV和DAP的ACResponse发送到SLDA-PD 908。
在图22的步骤6中，SLDA-PD 908核实ACV[]和/或DAP[]，并且如果其为可接受的，则SLDA-PD 908生成C-DAP。
在图22的步骤7中，SLDA-PD 908将包含C-DAP的DAP提供(DAPProvisioning)消息发送到RHF 1604。基于客户端1702所提供的Res-Id来确定RHF 1604的URI。
在图22的步骤8中，RHF 1604(SLDA-PE)核实C-DAP并且确保C-DAP满足D-ACP的与资源相关联的要求。SDPA-PE将C-DAP存储到DAP-Db中。
在图22的步骤9中，如果授权的“持续时间”超过authorization_duration_threshold，则SLDA-PE 910向ACP数据库(SAPD-PE)中创建条目。因此，倘若授权持续时间非常大，则动态授权检查导致创建静态授权规则。
在图22的步骤10中，如果DAP是可接受的，则SLDA-PE 910发送包含“成功消息”的DAPResponse消息。
在图22的步骤11中，SLDA-PD 908将包含“成功”消息的DAResponse消息发送到客户端1702。
在图22的步骤12中，在从SLDA-PD 908接收到“成功”消息时，客户端1702发起包含Res-Id、op、Client-Id的RARequest。
在图22的步骤13中，SLDA-PE 910检查SAPD-PE中的静态S-ACP并且发现匹配。
在图22的步骤14中，RHF 1604将资源和AAR发送到客户端1702。
应当理解，执行图22所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图22所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图22所示的步骤。还应当理解，图22所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
oneM2M服务层动态授权实施例
以下子部分提出使得oneM2M系统能够支持本公开中所提出的SLDA功能性的架构、资源和过程级增强。
所提出的oneM2M增强的概述包括：
1)oneM2M系统内的SLDA功能性的架构级实施例，其示出可在哪些类型的oneM2M实体上托管SLDA功能性(例如，MEF 2304、MAF2302和CSE)。
2)一些对现有oneM2M定义<accessControlPolicy>资源提出的增强，以包括使得能够对特权的列表内的各个特权进行部分寻址的用于特权的列表内的各个特权的标识符，用于每个各个特权的期满时间，以及支持涉及基于支付、基于互换、基于声誉和基于安全性评估的动态授权的使用案例的新类型的授权上下文的定义。
3)用以支持服务层动态授权策略的配置的oneM2M<dynAuthPolicy>资源和属性的定义。
4)用以支持显式请求执行动态授权的oneM2M<dynAuthRequest>资源以及对应请求和响应消息格式的定义。
5)用以支持咨询显式请求执行动态授权的能力的oneM2M<consult>资源以及对应请求和响应消息格式的定义。
6)若干oneM2M过程的定义，其提供可如何在oneM2M系统内支持不同类型的动态授权功能性的消息序列级描述。
oneM2M服务层动态授权架构
本公开中所提出的SLDA功能902可可选地托管在各种oneM2M定义实体上，包括CSE、MEF 2304或MAF 2302，如图23所示。SLDA功能902可全部集中并托管在这些oneM2M定义实体中的一者上，或者，SLDA功能902可被分割为使得其子功能(SLDA-PA、SLDA-PD 908、SLDA-PE 910和SLDA-PI)可跨多个oneM2M实体以分布式方式托管，如图24所示。例如，SLDA-PI子功能可被托管在MEF 2304上，SLDA-PD 908和SLDA-PA 904子功能可被托管在MAF 2302上，并且SLDA-PE 910子功能可被托管在CSE上。当以分布式方式托管时，SLDA 902子功能可彼此协调以执行动态授权功能。
应当理解，图23至24所示的功能性可以存储在M2M网络的节点(例如，服务器、网关、装置或其它计算机系统)(诸如下文所述的图44C或44D所示的那些节点中的一者)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施。
oneM2M服务层动态授权资源
用于描述资源结构的图形表示如下：
●针对资源和子资源使用正方形框
●针对属性使用椭圆形
●利用“<”和“>”限定的资源名称指示在创建资源期间指配资源的名称
●突出显示的资源和属性是本公开提出以支持SLDA功能性的新资源和属性
<dynAuthPolicy>资源
图25所示的所提出的<dynAuthPolicy>资源可充当接口，用于使用动态授权规则配置SLDA功能902。这个资源可用以创建、检索、更新和删除SLDA 902策略。一旦配置有一个或多个<dynAuthPolicy>资源，SLDA功能902便可使用策略内定义的规则来执行动态授权决策制定。
可支持各种类型的动态授权规则，诸如但不限于本公开所定义的那些规则，包括基于咨询、基于支付、基于互换、基于安全性评估和基于声誉的策略。在以下子部分中更详细地进一步描述如何在oneM2M系统中表示规则中的每一者。
除了动态授权规则之外，<dynAuthPolicy>资源还可支持selfAccessControlPolicyIDs属性。这个属性可用以引用定义<dynAuthPolicy>资源本身的访问特权的访问控制策略。这些特权可用以控制允许哪些实体访问(例如，检索、更新或删除)<dynAuthPolicy>资源及其属性。
可选地，<dynAuthPolicy>资源还可支持accessControlPolicyIDs属性，其可使用指向SLDA功能902可使用这个<dynAuthPolicy>资源动态创建、更新或删除其静态特权的一个或多个<accessControlPolicy>资源的链接的列表来配置。
表1-<dynAuthPolicy>资源的属性
不是使用所提出的使用accessControlPolicyIDs属性来显式链接<accessControlPolicy>资源与<dynAuthPolicy>资源的显式方法，下文还经由使用若干使用案例实施例来定义隐式方法。
例如，如图26所示，可向现有oneM2M资源(例如，<container>资源)添加dynAuthPolicyIDs属性。这个属性可用于以与oneM2M当前支持使用accessControlPolicyIDs属性链接oneM2M资源与<accessControlPolicy>类似的方式链接oneM2M资源与<dynAuthPolicy>资源。SLDA功能902可继而通过简单利用oneM2M资源所支持的accessControlPolicyIDs和dynAuthPolicyIDs属性来确定哪些<accessControlPolicy>资源可由哪些<dynAuthPolicy>资源管理。例如，如果做出访问图26所示的<container>资源的请求，则可首先执行检查以确定容器(container)的accessControlPolicyIDs属性所引用的<accessControlPolicy>是否具有特权来允许请求者执行所需操作。如果是，则该请求可被允许继续进行并且将不需要动态授权。然而，如果请求者没有适当特权，则SLDA功能902可被触发尝试并执行动态授权。SLDA功能902可首先检查<container>资源是否具有被配置为链接到有效<dynAuthPolicy>资源的dynAuthPolicyIDs属性。如果是，则SLDA功能902可接着访问dynAuthRules属性并且使用其来确定向请求者许可还是拒绝特权。还可使用privilegeLifetime属性来确定仅针对这个请求还是还针对将来请求许可特权。如果将来请求，则可接着更新<container>所链接到的<accessControlPolicy>资源内的静态特权。SLDA功能902可通过更新容器的accessControlPolicyIDs属性所链接到的<accessControlPolicy>资源的特权来这样做。
作为另选方式，<dynAuthPolicy>资源可改为创建为<accessControlPolicy>资源的子资源，如图27所示。如果/当已经发现请求者没有足够特权来对目标资源执行所需操作，则SLDA功能902可接着检查对应<accessControlPolicy>资源是否具有<dynAuthPolicy>子资源。如果是，则SLDA功能902可接着基于<dynAuthPolicy>子资源所指定的规则来检查其是否能够向请求者动态许可适当特权。
作为另一个另选方式，dynAuthPolicyIDs属性可改为添加到<accessControlPolicy>资源，如图28所示。如果/当已经发现请求者没有足够特权来对目标资源执行所需操作，则SLDA功能902可接着检查对应<accessControlPolicy>资源是否已经配置dynAuthPolicyIDs属性。如果是，则SLDA功能902可接着参考对应<dynAuthPolicy>资源来基于<dynAuthPolicy>子资源所指定的规则检查其是否能够向请求者动态许可适当特权。
作为另一个另选方式，不是定义新<dynAuthPolicy>资源，所提出的属性可改为添加到现有<accessControlPolicy>资源。
<dynAuthRequest>资源
本公开还定义<dynAuthRequest>资源，如图30所示。这个资源可被定义为没有属性的虚拟资源(如图所示)，或其可被定义为具有属性的正常资源(未示出)。其可用以向SLDA功能902发布显式动态授权请求，以请求向附属于一个或多个所需资源或服务的<accessControlPolicy>特权动态添加特定类型的访问特权。这个资源可对于下述场景有用，请求者缺少对所需资源或服务的适当访问特权并且还缺少更新访问控制以许可其自己的特权。在这种情况下，请求者可使用<dynAuthRequest>资源来向SLDA功能902发送显式请求，以尝试并获得所需访问特权。如果成功，则SLDA功能902可更新目标资源或服务的访问控制策略以添加所请求的特权，并且将状态返回给请求者。如果成功，则请求者可此后发布用于访问所需资源或服务的请求并且其将具有适当特权来执行访问。
<dynAuthRequest>资源可在oneM2M资源树分级结构中在各种层级处实例化。在图31所示的一个实施例中，<dynAuthRequest>资源可在<CSEBase>资源下方实例化并且提供给具有访问特权来访问<CSEBase>资源的任何服务层注册者。这种类型的实施例可用以允许服务层注册者向尚未预先配置的CSEBase子资源中的任一者显式请求特权(即，在运行中动态请求特权而非依赖于预先配置的特权)。
另选地，在图32所示的另一个实施例中，<dynAuthRequest>资源可在诸如<AE>等其它oneM2M资源类型下方实例化。可针对诸如<container>、<subscription>或<accessControlPolicy>等其它现有oneM2M资源类型进行相同操作。这样做，动态授权请求的范围可限于对这些资源具有预先存在的访问特权的那些服务层注册者。例如，在这个实例中，仅对<CSEBase>/<AE>具有现有访问特权的服务层注册者能够向<CSEBase>/<AE>/<dynAuthRequest>发布动态授权请求，以尝试并获得对在<CSEBase>/<AE>下方的子资源的访问特权。
为了使用这个资源，本公开还定义动态授权请求和响应消息(即，oneM2M基元)，其具有如以下表2和表3中所定义的若干提出的参数。为了发起显式动态授权请求，请求者可通过基于其想要获得的访问特权的类型适当地初始化所定义的参数来形成请求。请求者可接着将请求消息发送到<dynAuthRequest>资源。在接收到请求后，SLDA功能902可即刻对其进行处理(即，将请求消息参数与其配置的同请求者想要获得特权的目标资源或服务相对应的<dynAuthPolicy>资源规则进行比较)。基于结果，SLDA功能902可确定是否按照请求修改访问控制特权。SLDA 902可接着形成具有定义许可哪些请求特权以及拒绝哪些请求特权的参数的响应。在不支持动态授权功能性(例如，不支持<dynAuthRequest>资源)或目标资源或服务没有适当配置的<dynAuthPolicy>资源的情况下，可返回错误。
表2-显式动态授权请求消息的参数
表3-显式动态授权响应消息的参数
<consult>资源
本公开还定义如图33所示的<consult>资源。这个资源可被定义为没有属性的虚拟资源(如图所示)或具有属性的正常资源(未示出)。这个资源的URI可用作SLDA功能902可在执行需要向网络中的另一个实体咨询的动态授权时使用的咨询联系点。例如，当<dynAuthPolicy>被配置有定义consultationContact的基于咨询的规则时，可使用<consult>资源的URI。<consult>资源可由各种oneM2M定义实体(诸如CSE、AE、MEF和MAF)托管。另外，这个资源还可由oneM2M尚未定义的其它类型的实体(诸如位置功能、声誉核实功能(例如，社交媒体服务器)、平台验证和评估功能、支付功能、安全性功能和服务订阅核实功能4102)托管。
为了使用这个资源，本公开还定义动态授权咨询请求和响应消息(即，oneM2M基元)，其具有如以下表4和表5中所定义的若干所提出的参数。为了执行咨询，SLDA功能902可构造咨询请求消息并且将这个消息指向系统内的实体所托管的<consult>资源。在接收到这个请求后，实体可即刻根据咨询类型来对其进行处理，使用咨询结果构造对应响应消息，并且将响应返回给SLDA功能902。
表4-咨询请求消息的参数
表5-咨询响应消息的参数
<accessControlPolicy>资源增强
如上文关于图6所描述，oneM2M当前支持具有基于ACL的一组定义特权(privileges)的<accessControlPolicy>资源。这个ACL是一组访问控制规则元组，其可被存储在privileges属性内，其中每个元组包括三个分量，其由1)accessControlOriginators、2)accessControlOperations和3)accessControlContext构成。
本公开提出下文所述的对<accessControlPolicy>资源的现有privileges属性的三个增强。
1)已经向privileges访问控制规则元组添加第四分量，称为accessControlPrivilegeID。这个第四分量可用以识别并且寻址各个privileges访问控制规则元组。这个标识符可在支持各个元组的更新或删除时有用。否则，各个元组的更新或删除需要更新整个privileges访问控制规则元组列表，这可能效率较低。
2)已经向privileges访问控制规则元组添加第五分量，称为accessControlExpirationTime。这个分量可用以定义与特定访问控制规则元组相关联的寿命。这使得访问控制规则元组能够具有相对于彼此不同的寿命，这可从特权角度来看提供更多灵活性。
3)本公开还已经定义四个额外类型的accessControlContext：
●accessControlPaymentTerms–在服务层注册者被允许访问与这个授权策略相关联的资源之前必须确立的支付条款的列表。
●accessControlReputationLevel–服务层注册者在被允许访问与这个授权策略相关联的资源之前必须具有的需要的声誉级别。
●accessControlBarterTerms–在服务层注册者被允许访问与这个授权策略相关联的资源之前必须确立的互换条款的列表。
●accessControlSecurityAssessment–服务层注册者在被允许访问与这个授权策略相关联的资源之前必须具有的需要的安全性级别。
oneM2M服务层动态授权过程
服务层动态授权策略的配置
动态授权策略可经由创建/更新/删除目标<dynAuthPolicy>资源的dynAuthRules属性来配置，如图34所示。一旦被配置，SLDA功能902便可利用这些策略来执行动态授权请求处理。
在图34的步骤1中，oneM2M实体3402(例如，AE)确定其想要配置的动态授权规则的类型和这个规则的对应值(诸如基于咨询的规则、基于支付的规则、基于互换的规则、基于安全性评估的规则和基于声誉的规则)。
在图34的步骤2中，oneM2M实体3402(例如，AE)发送指向托管SLDA功能902的第二oneM2M实体3404(例如，CSE、MEF 2304或MAF 2302)的请求。请求包含<dynAuthPolicy>资源表示，其中<dynAuthPolicy>资源的dynAuthRules属性可被配置有来自步骤1的动态授权策略规则。
在图34的步骤3中，托管在oneM2M实体3404上的SLDA功能902接收请求并且检查请求者是否具有适当特权来对目标<dynAuthPolicy>资源执行指定操作。通过确认请求者是否已经配置对应<accessControlPolicy>资源内的与目标<dynAuthPolicy>相关联的privileges来执行这个检查。如果是，则SLDA功能902继续处理请求，否则SLDA功能902向请求者返回错误，向请求者指示缺少特权来执行这个操作。
在图34的步骤4中，SLDA功能902处理请求并且基于操作针对目标<dynAuthPolicy>资源的dynAuthRules属性创建、更新或删除指定规则。
在图34的步骤5中，服务层向请求者返回响应，指示用于创建、更新或删除目标<dynAuthPolicy>资源的dynAuthRules属性中的指定规则的请求是否成功。
应当理解，执行图34所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图34所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图34所示的步骤。还应当理解，图34所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
自主服务层动态授权
服务层动态授权可由托管SLDA功能902的oneM2M实体3502自主地触发并执行，如图35所示。经由这个过程，SLDA功能902可支持在处理对访问请求者没有现有特权来访问的资源所做出的请求期间在运行中自主地许可或拒绝特权。通过支持这个过程，可从请求者移除负担，因为其不必针对其没有确立特权的资源显式请求访问特权。经由这个过程，可在请求者甚至不知道正在执行服务层动态授权的情况下执行服务层动态授权。这可减小对请求者的开销，尤其是针对涉及资源受约束装置(例如，托管在IoT装置上的传感器应用)的使用。
这个过程还可对服务层本身有益，因为其提供一种用于利用SLDA902结果在运行中动态创建或更新访问控制策略而非必须使网络中的外部管理实体事先使用一组特权静态预先配置访问控制策略的机制。事先预先配置访问控制策略可为繁琐的、不灵活的并且可扩展性并不好。
在图35的步骤1中，请求oneM2M实体3402(例如，AE或CSE)可向另一个oneM2M实体3502发布请求(即，创建/检索/更新/删除/订阅/发现)。
在图35的步骤2中，接收oneM2M实体3502(例如，CSE)检测对目标资源的访问。接收实体检查适用于目标资源的对应<accessControlPolicy>资源(如果有的话)以确定请求者是否具有被配置为允许其执行所需类型的访问的充足特权。在这个实例中，请求者缺少充足的访问特权。
在图35的步骤3中，不是立即向请求者返回“访问被拒”错误，接收实体3502触发由SLDA功能性执行动态授权处理，SLDA功能性可被托管在接收实体上或系统中的另一个实体上。SLDA功能性还可被拆分到多个实体，其中一些功能性被托管在接收实体上。
在图35的步骤4中，如果使用SLDA功能性启用，则接收实体3502开始执行动态授权处理。取决于接收实体是否自己托管SLDA功能性，将确定SLDA处理是否完全在本地执行，或者接收实体是否将与系统中的其它oneM2M实体(诸如实体3504和3506)通信以协助其执行SLDA 902。如关于图23和24所描述，针对以集中式或分布式方式托管SLDA功能性存在不同部署选项，允许不同类型的oneM2M实体(CSE、MEF 2304、MAF 2302)托管SLDA 902的全部或特定SLDA 902子功能。如果未找到SLDA功能性，则可停止SLDA 902处理并且可向请求者返回“访问被拒”错误。如果发现SLDA功能性被托管在接收实体和/或系统中的其它实体上，则这个功能性被触发以尝试定位适用于目标资源的<dynAuthPolicy>资源。如果无法找到<dynAuthPolicy>，则SLDA 902可中断动态授权处理并且向请求者返回“访问被拒”错误。如果找到一个或多个<dynAuthPolicy>资源，则SLDA功能性可针对所找到的每个资源使用dynAuthRules属性来对照请求者的请求进行评定并且确定是否可动态许可特权。
在图35的可选步骤5中，在评定适用<dynAuthPolicy>资源的dynAuthRules时，SLDA功能902可能需要取决于所指定的dynAuthRules的类型来向系统中的其它实体(诸如实体3504和3506)咨询。可能需要咨询来收集SLDA功能902确定向请求者许可还是拒绝访问特权所需要的适当信息。关于图37至42更详细地描述SLDA功能902可执行的某种提议类型的咨询。这个咨询可使用关于图33进一步详细描述的所提出的<consult>资源及其对应请求和响应基元来执行。
在图35的步骤6中，基于对照dynAuthRules评定请求并且有可能向系统中的其它实体(诸如实体3504和3506)咨询以获得其决策制定所考虑的额外信息的结果，SLDA功能性决定向请求者许可访问。因而，接收实体3502对目标资源执行请求并且向请求者3402返回成功响应。请求者3402不知道已经执行自主SLDA 902。其知道的只是其请求成功完成。
在图35的可选步骤7中，使用动态授权结果，SLDA功能902可以可选地选择更新<accessControlPolicy>资源内的与目标资源相关联的privileges属性以针对请求者添加访问控制特权。这个决定可经由<dynAuthPolicy>资源内定义的dynAuthRule来控制。例如，dynAuthRule可支持用以控制SLDA功能902是否添加或更新<accessControlPolicy>资源的静态特权，并且如果是的话，则控制这个特权的期满时间的规则(例如，特权寿命规则)。因而，SLDA功能902可使用这个规则来控制其是否更新或添加特权，并且如果是的话，则控制期满时间(例如，这可使用如上文提出的特权的accessControlExpirationTime分量来进行)。基于这些规则，SLDA功能902可确定是否添加/更新特权以及其相应寿命。通过选择更新特权，请求者可被许可对所述资源的访问并且执行相同操作而不必重复动态授权。
在图35的步骤8中，请求oneM2M实体3402(例如，AE或CSE)对相同oneM2M实体上的相同资源发布请求(即，创建/检索/更新/删除/订阅/发现)。
在图35的步骤9中，接收oneM2M实体3502(例如，CSE)检测对目标资源的访问。接收实体检查适用于目标资源的对应<accessControlPolicy>资源并且检测到请求者现在由于SLDA功能902已经作为步骤7的一部分添加这些特权的结果而具有充足访问特权。
在图35的步骤10中，接收实体3502对目标资源执行请求并且向请求者返回成功响应。
应当理解，执行图35所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图35所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图35所示的步骤。还应当理解，图35所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
显式服务层动态授权请求处理
这个部分定义用于使得请求者能够显式发布动态授权请求以尝试并获得所需特权来访问指定资源的过程。
在图36的可选步骤1中，请求oneM2M实体3402(例如，AE或CSE)可向另一个oneM2M实体3602发布请求(即，创建/检索/更新/删除/订阅/发现)。
在图36的可选步骤2中，接收oneM2M实体3602(例如，CSE)检测对目标资源的访问。接收实体3602检查适用于目标资源的对应<accessControlPolicy>资源(如果有的话)以确定请求者3402是否具有被配置为允许其执行所需类型的访问的充足特权。在这个实例中，请求者缺少充足的访问特权。
在图36的可选步骤3中，不是立即向请求者返回“访问被拒”错误，接收实体3602返回指向系统中的支持服务层动态授权的实体3502的链接。这个链接可为指向支持SLDA功能902的实体所托管的<dynAuthRequest>资源的链接。
在图36的步骤4中，请求oneM2M实体3402制定并发布显式服务层动态授权请求并且将请求指向网络中的SLDA功能902。这个请求可指向支持SLDA功能902的实体所托管的<dynAuthRequest>资源。请求可包括诸如requestType、requestdPrivileges、paymentInfo、barterInfo、credentialInfo、platformInfo、subscriptionInfo等信息，这些信息全部在上文中定义。
在图36的步骤5中，接收oneM2M实体3602在接收到这个请求时检查目标UTI并且检测到其指向<dynAuthRequest>资源。基于这点，实体知道触发SLDA功能902来处理请求。
在图36的步骤6中，SLDA功能902检查是否针对正被请求的特权存在<dynAuthPolicy>资源。这通过定位请求者正在请求其访问特权的资源来进行。一旦找到，SLDA功能902接着便检查这些资源是否具有附属于其的对应<dynAuthPolicy>资源。如果没有，则可向请求者返回错误响应。如果找到，则SLDA功能902可继续进行处理。SLDA功能902接下来检查附属于目标资源的每个<dynAuthPolicy>资源的dynAuthRules属性。首先将dynAuthRules与请求者在其请求中所包括的信息(例如，RequestType、requestdPrivileges、paymentInfo、barterInfo、credentialInfo、platformInfo、subscriptionInfo)进行比较以查看请求是否遵守规则。如果不遵守，则返回错误。否则，SLDA 902取决于以下步骤#7继续动态授权处理。
在图36的可选步骤7中，SLDA功能902检查其是否需要向系统中的其它功能执行任何咨询。SLDA 902通过检查指定SLDA功能902是否需要向支付、互换、安全性、订阅核实、声誉核实或授权功能咨询的dynAuthRules来确定这点。请注意，这可涉及与oneM2M系统中的托管这些功能的其它实体(诸如实体3604和3606)协调。可使用关于图37至42的过程来执行咨询。
在图36的步骤8中，SLDA功能902向显式动态授权请求者返回响应。在这个响应中，SLDA功能902可返回诸如dynAuthStatus、dynAuthCredentialID、dynAuthCredential、grantedPrivileges、deniedPrivileges、paymentTerms、barterTerms和subscriptionTerms等信息，这些信息在表2中定义。
在图36的可选步骤9中，使用动态授权结果，SLDA功能902可以可选地选择更新<accessControlPolicy>资源内的与目标资源相关联的privileges属性以针对请求者添加访问控制特权。这个决定可经由<dynAuthPolicy>资源内定义的dynAuthRule来控制。例如，dynAuthRule可支持用以控制SLDA功能902是否添加或更新<accessControlPolicy>资源的静态特权，并且如果是的话，则控制这个特权的期满时间的规则(例如，特权寿命规则)。因而，SLDA功能902可使用这个规则来控制其是否更新或添加特权，并且如果是的话，则控制期满时间(例如，这可使用如上文提出的特权的accessControlExpirationTime分量来进行)。基于这些规则，SLDA功能902可确定是否添加/更新特权以及其相应寿命。通过选择更新特权，请求者可被许可对资源的访问并且执行相同操作而不必重复动态授权。
在图36的步骤10中，请求oneM2M实体3402(例如，AE或CSE)可向另一个oneM2M实体发布请求(即，创建/检索/更新/删除/订阅/发现)。在该请求内，请求者可包括其从步骤8获得的动态授权凭证和/或标识符。
在图36的步骤11中，接收oneM2M实体3602(例如，CSE)检测对目标资源的访问。接收实体检查适用于目标资源的对应<accessControlPolicy>资源(如果有的话)以确定请求者是否具有被配置为允许其执行所需类型的访问的充足特权。在这个实例中，请求者缺少充足的访问特权。
在图36的步骤12中，不是立即向请求者返回“访问被拒”错误，接收实体3602检查请求是否包含动态授权凭证(例如，令牌)或其ID。如果不是，则返回“访问被拒”错误。
在图36的步骤13中，如果仅包括动态授权凭证ID而不包括实际凭证，则接收实体触发SLDA功能902查找与指定ID相关联的对应动态授权凭证。
在图36的可选步骤14中，接收实体3602形成咨询请求以访问动态授权凭证。请求被发送到SLDA功能902的<consult>资源或系统中的专用授权功能。这经由安全网络连接来进行。请求中包括有诸如表4中所定义的consultationInfo等参数。
在图36的可选步骤15中，在接收到请求后，SLDA功能902即刻检测到其是咨询请求，因为其指向<consult>资源。SLDA功能902解析该请求以检测其是什么类型的咨询请求(通过检查咨询类型参数)并且检测到其是动态授权凭证请求咨询。SLDA 902接着使用请求中所包括的动态授权凭证ID来查找对应凭证。接着将凭证返回给接收实体。
在图36的步骤16中，接收实体3602(或SLDA功能902)核实在请求中接收的或经由使用以上咨询步骤咨询获得的动态授权凭证。一旦核实，SLDA功能902便可接着选择向请求者许可所请求的访问特权。接收实体处理请求并且向请求者返回成功响应。
在图36的步骤17中，接收实体3602(或SLDA功能902)核实在请求中接收的或经由使用以上咨询步骤咨询获得的动态授权凭证。一旦核实，SLDA功能902便可接着选择向请求者许可所请求的访问特权。
在图36的可选步骤18中，使用动态授权结果，SLDA功能902可以可选地选择更新<accessControlPolicy>资源内的与目标资源相关联的privileges属性以针对请求者添加访问控制特权。这个决定可经由<dynAuthPolicy>资源内定义的dynAuthRule来控制。例如，dynAuthRule可支持用以控制SLDA功能902是否添加或更新<accessControlPolicy>资源的静态特权，并且如果是的话，则控制这个特权的期满时间的规则(例如，特权寿命规则)。因而，SLDA功能902可使用这个规则来控制其是否更新或添加特权，并且如果是的话，则控制期满时间(例如，这可使用如上文提出的特权的accessControlExpirationTime分量来进行)。基于这些规则，SLDA功能902可确定是否添加/更新特权以及其相应寿命。通过选择更新特权，请求者可被许可对资源的访问并且执行相同操作而不必重复动态授权。
应当理解，执行图36所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图36所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图36所示的步骤。还应当理解，图36所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
基于咨询的服务层动态授权
图37示出用于基于咨询的动态授权的过程。
在图37的步骤1中，通过显式请求(即，对<dynAuthRequest>资源的访问)或经由SLDA功能902本身(例如，经由检测到在现有<accessControlPolicy>静态特权上检查失败的请求)自主地触发SLDA功能902。
在图37的步骤2中，SLDA 902定位适用的<dynAuthPolicy>资源(如果有的话)并且评定dynAuthPolicy属性以确定已经配置什么规则。在这个实例中，dynAuthPolicy属性已经被配置有指定作为动态授权处理的一部分需要“基于咨询的授权”的规则。这个规则触发SLDA功能902向系统中的授权功能3702咨询以使其考虑向请求者许可还是拒绝其正请求或需要的访问特权。
在图37的步骤3中，SLDA功能902形成咨询请求消息。所述消息指向授权功能3702托管的<consult>资源。consultSubject被配置有正在对之执行动态授权的请求者的AE-ID或CSE-ID。请求的有效载荷被配置有请求者正在显式要求的所请求/所需要的特权，或SLDA功能902已经认为对请求者访问其正指向的资源或服务所必要的特权。
在图37的步骤4中，授权功能3702评估向请求者许可还是拒绝其正在请求的访问特权。如何做出这个决定的细节在本公开的范围之外，并且被视为特别针对于授权功能3702所支持的检查类型，检查类型可取决于部署使用案例而变化。接着将这个操作的结果以咨询响应的形式返回给SLDA 902。响应包含被许可和被拒绝的特权的列表。响应还可包含请求者可能感兴趣的一些其它资源或服务的特权。
在图37的步骤5中，SLDA功能性检查基于咨询的授权结果，并且将这个结果纳入其动态授权决策制定，以确定向请求者许可还是拒绝访问特权。
应当理解，执行图37所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图37所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图37所示的步骤。还应当理解，图37所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
基于支付的服务层动态授权
图38示出用于基于支付的动态授权的过程。
在图38的步骤1中，通过显式请求(即，对<dynAuthRequest>资源的访问)或经由SLDA功能902本身(例如，经由检测到在现有<accessControlPolicy>静态特权上检查失败的请求)自主地触发SLDA功能902。
在图38的步骤2中，SLDA 902定位适用的<dynAuthPolicy>资源(如果有的话)并且评定dynAuthPolicy属性以确定已经配置什么规则。在这个实例中，dynAuthPolicy属性已经被配置有指定作为动态授权处理的一部分需要“需要支付核实”的规则。这个规则触发SLDA功能902向系统中的支付功能3802咨询以使其核实请求者的支付信息。
在图38的步骤3中，SLDA功能902形成咨询请求消息。所述消息指向支付功能所托管的<consult>资源。consultSubject被配置有正在对之执行支付信息核实的请求者的AE-ID或CSE-ID。请求的有效载荷被配置有请求者的支付信息以及支付策略，其可包括诸如请求者的支付令牌和偏好以及策略的支付条款等信息。
在图38的步骤4中，支付功能3802评估支付信息以核实其为有效的并且还对照策略中的支付规则对其进行评估。接着将这个操作的结果以咨询响应的形式返回给SLDA 902。响应包含支付信息核实状态。
在图38的步骤5中，SLDA功能性检查支付信息核实结果并且将这个结果纳入其动态授权决策制定以确定向请求者许可还是拒绝访问特权。
应当理解，执行图38所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图38所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图38所示的步骤。还应当理解，图38所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
基于互换的服务层动态授权
图39示出用于基于互换的动态授权的过程。
在图39的步骤1中，通过显式请求(即，对<dynAuthRequest>资源的访问)或经由SLDA功能902本身(例如，经由检测到在现有<accessControlPolicy>静态特权上检查失败的请求)自主地触发SLDA功能902。
在图39的步骤2中，SLDA 902定位适用的<dynAuthPolicy>资源(如果有的话)并且评定dynAuthPolicy属性以确定已经配置什么规则。在这个实例中，dynAuthPolicy属性已经被配置有指定“所需要的互换条款”的规则，“所需要的互换条款”是请求者必须满足以被许可访问特权的互换要求的列表。这个规则触发SLDA功能902执行本地互换处理或向系统中的互换功能3902咨询以使其代表SLDA 902执行互换处理。
在图39的步骤3中，SLDA功能902形成咨询请求消息。该消息指向互换功能3902所托管的<consult>资源。consultSubject被配置有正在对之执行互换处理的请求者的AE-ID或CSE-ID。请求的有效载荷被配置有请求者的互换信息以及互换策略，其可包括诸如请求者必须愿意同意被许可访问特权的互换类型条款等信息。例如，以对请求者的资源和服务的访问交换由目标资源拥有者许可访问特权。
在图39的步骤4中，互换功能3902评估策略以及请求者定义的互换条款以确定请求者是否愿意同意这些条款。互换功能3902接着经由包含互换状态和同意条款列表的咨询响应将结果返回给SLDA 902。
在图39的步骤5中，SLDA功能性检查互换结果并且将这个结果纳入其动态授权决策制定以确定向请求者许可还是拒绝访问特权。
应当理解，执行图39所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图39所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图39所示的步骤。还应当理解，图39所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
基于安全性评估的服务层动态授权
图40示出用于基于安全性评估的动态授权的过程。
在图40的步骤1中，通过显式请求(即，对<dynAuthRequest>资源的访问)或经由SLDA功能902本身(例如，经由检测到在现有<accessControlPolicy>静态特权上检查失败的请求)自主地触发SLDA功能902。
在图40的步骤2中，SLDA 902定位适用的<dynAuthPolicy>资源(如果有的话)并且评定dynAuthPolicy属性以确定已经配置什么规则。在这个实例中，dynAuthPolicy属性已经被配置有指定“需要安全性评估”的规则。这个规则触发SLDA功能902执行本地安全性评估处理或向系统中的安全性功能4002咨询以使其代表SLDA 902执行安全性评估处理。
在图40的步骤3中，SLDA功能902形成咨询请求消息。该消息指向安全性功能4002所托管的<consult>资源。consultSubject被配置有正在对之执行安全性评估处理的请求者的AE-ID或CSE-ID。请求的有效载荷被配置有请求者的安全性信息(ID、凭证、所支持的接口安全性的类型、所支持的平台安全性、所支持的内容安全性等)。请求还可被配置有策略所定义的任何需要的安全性评估级别。
在图40的步骤4中，安全性功能4002对照策略中所定义的安全性要求评估请求者的安全性信息以确定请求者是否满足安全性评估要求。安全性功能4002接着经由包含安全性评估状态的咨询响应将结果返回给SLDA 902。
在图40的步骤5中，SLDA功能性检查安全性评估结果并且将这个结果纳入其动态授权决策制定以确定向请求者许可还是拒绝访问特权。
应当理解，执行图40所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图40所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图40所示的步骤。还应当理解，图40所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
基于服务层订阅核实的动态授权
图41示出用于基于服务层订阅的动态授权的过程。
在图41的步骤1中，通过显式请求(即，对<dynAuthRequest>资源的访问)或经由SLDA功能902本身(例如，经由检测到在现有<accessControlPolicy>静态特权上检查失败的请求)自主地触发SLDA功能902。
在图41的步骤2中，SLDA 902定位适用的<dynAuthPolicy>资源(如果有的话)并且评定dynAuthPolicy属性以确定已经配置什么规则。在这个实例中，dynAuthPolicy属性已经被配置有指定“需要服务订阅核实”的规则。这个规则触发SLDA功能902执行本地服务订阅核实处理或向系统中的订阅核实功能4102咨询以使其代表SLDA 902执行这个核实。
在图41的步骤3中，SLDA功能902形成咨询请求消息。该消息指向订阅核实功能4102所托管的<consult>资源。consultSubject被配置有正在对之执行所述核实的请求者的AE-ID或CSE-ID。请求的有效载荷被配置有可用的请求者的任何服务订阅信息(例如，服务层ID)以及服务订阅策略规则，其定义要求，诸如请求者必须具有以被许可访问特权的所需要的服务提供商和/或服务计划等。
在图41的步骤4中，订阅核实功能4102对照请求者的服务订阅评估策略所定义的订阅要求以确定请求者是否满足策略所定义的要求。订阅核实功能4102接着经由包含验证状态和已经满足的要求以及尚未满足的任何要求的列表的咨询响应将所述结果返回给SLDA 902。
在图41的步骤5中，SLDA功能性检查订阅核实结果并且将这个结果纳入其动态授权决策制定以确定向请求者许可还是拒绝访问特权。
应当理解，执行图41所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图41所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图41所示的步骤。还应当理解，图41所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
基于声誉的服务层动态授权
图42示出用于基于声誉的动态授权的过程。
在图42的步骤1中，通过显式请求(即，对<dynAuthRequest>资源的访问)或经由SLDA功能902本身(例如，经由检测到在现有<accessControlPolicy>静态特权上检查失败的请求)自主地触发SLDA功能902。
在图42的步骤2中，SLDA 902定位适用的<dynAuthPolicy>资源(如果有的话)并且评定dynAuthPolicy属性以确定已经配置什么规则。在这个实例中，dynAuthPolicy属性已经被配置有指定“需要的声誉级别”的规则，“需要的声誉级别”定义请求者的声誉必须满足以使其被动态许可访问特权的排名或级别。这个规则触发SLDA功能902执行本地声誉核实处理或向系统中的声誉核实功能4202咨询以使其代表SLDA 902执行这个核实。
在图42的步骤3中，SLDA功能902形成咨询请求消息。所述消息指向声誉核实功能所托管的<consult>资源。consultSubject被配置有正在对之执行核实的请求者的AE-ID或CSE-ID。请求的有效载荷被配置有可用的请求者的任何声誉相关信息(例如，服务层ID)以及声誉策略规则，其定义请求者必须具有以被许可访问特权所需要的最小声誉级别或排名。
在图42的步骤4中，声誉核实功能4202对照请求者的声誉评估策略所定义的声誉要求以确定请求者是否满足策略所定义的要求。这可使用诸如对接到经常跟踪此类信息的社交媒体出口等方法来进行。声誉核实功能4202接着经由包含核实状态和声誉级别或排名的咨询响应将结果返回给SLDA 902。
在图42的步骤5中，SLDA功能性检查声誉结果并且将这个结果纳入其动态授权决策制定以确定向请求者许可还是拒绝访问特权。
应当理解，执行图42所示的步骤的实体是可以存储在网络节点或计算机系统(诸如图44C或图44D所示的那些)的存储器中并且在其处理器上执行的软件(即，计算机可执行指令)的形式实施的逻辑实体。也就是说，图42所示的方法可以存储在网络节点(诸如图44C或图44D所示的节点或计算机系统)的存储器中的软件(即，计算机可执行指令)的形式实施，计算机可执行指令在由节点的处理器执行时执行图42所示的步骤。还应当理解，图42所示的任何传输和接收步骤可由节点的通信电路在节点的处理器和其所执行的计算机可执行指令(例如，软件)的控制下执行。
诸如图形用户界面(GUI)等界面可用以协助用户控制且/或配置与服务层动态授权相关的功能性。图43是示出允许用户进行以下操作的界面4302的图：启用服务层动态授权；选择将动态授权存储为静态授权的服务层动态授权周期；以及配置咨询服务器或应用。
界面4302可用以定义特定动态授权规则，如本公开的表1中的动态授权规则(见dynAuthRules)。界面4302可允许用户从可用规则列表勾选或手动输入规则。
应当理解，界面4302可使用诸如下文所述的图44C至44D所示的显示器等显示器来产生。
示例性M2M/IoT/WoT通信系统
本文所述的各种技术可结合硬件、固件、软件或在适当时其组合来实施。此类硬件、固件和软件可驻留在位于通信网络的各种节点处的设备中。所述设备可单独地或彼此组合地进行操作以实现本文所述的方法。如本文使用，可互换使用术语“设备”、“网络设备”、“节点”、“装置”和“网络节点”。
术语“服务层”是指网络服务架构内的功能层。服务层通常位于诸如HTTP、CoAP或MQTT等应用协议层上方并且向客户端应用提供增值服务。服务层还提供指向位于较低资源层(诸如控制层和传输/接入层)处的核心网络的接口。服务层支持多种(服务)能力或功能性，包括服务定义、服务运行时启用、策略管理、接入控制和服务聚类。最近，若干行业标准组织(例如，oneM2M)一直在开发M2M服务层以解决与将M2M类型的装置和应用集成到诸如互联网/Web、蜂窝式、企业和家庭网络等部署中相关联的挑战。M2M服务层可向应用和/或各种装置提供对服务层所支持的一批或一组上文提及的能力或功能性的访问，所述服务层可被称为CSE或SCL。一些实例包括但不限于各种应用通常可使用的安全性、计费、数据管理、装置管理、发现、提供和连接性管理。经由利用M2M服务层所定义的消息格式、资源结构和资源表示形式的API将这些能力或功能性提供给此类各种应用。CSE或SCL是可由硬件和/或软件实施并且提供向各种应用和/或装置(即，此类功能实体之间的功能接口)暴露的(服务)能力或功能性以便使其使用此类能力或功能性的功能实体。
图44A是可实施一个或多个所公开的实施例的示例性机器对机器(M2M)、物联网(IoT)或物联网(WoT)通信系统10的图。通常，M2M技术提供用于IoT/WoT的构建块，并且任何M2M装置、M2M网关、M2M服务器或M2M服务平台可为IoT/WoT的部件或节点以及IoT/WoT服务层等。通信系统10可用以实施所公开的实施例的功能性，并且可包括诸如服务层102、应用204和202、SLDA 902、SLDA-PA 904、SLDA-PI 906、SLDA-PD 908、SLDA-PE 910、SLSA 1402、SLSA-PA 1404、SLSA-PD 1406、SLSA-PI 1412、SLSA-PE 1410、SL-PCF 1408、实体1502、1602、3402、3404、3502、3504、3506、3602、3604、3606、策略服务器1504、RHF 1604、客户端1702、DAEF 1802和DAEF支付、DGF 2102、MAF 2302、MEF 2304、授权功能3702、支付功能3802、互换功能3902、安全性功能4002、服务层订阅核实功能4102、声誉核实功能4202等功能性和逻辑实体以及用于存储所公开的资源并对其进行操作的逻辑实体和用于产生诸如界面4302等界面的逻辑实体。
如图44A所示，M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可为固定网络(例如，以太网、光纤、ISDN、PLC等)或无线网络(例如，WLAN、蜂窝式等)或异构网络的网络。例如，通信网络12可包括向多个用户提供诸如语音、数据、视频、即时消息、广播等内容的多个接入网络。例如，通信网络12可采用一种或多种信道访问方法，诸如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。另外，通信网络12可包括其它网络，诸如核心网、互联网、传感器网络、工业控制网络、个人局域网、融合个人网络、卫星网络、家庭网络或企业网络。
如图44A所示，M2M/IoT/WoT通信系统10可包括基础设施域和场域。基础设施域是指端对端M2M部署的网络侧，并且场域是指区域网络，通常在M2M网关后面。场域和基础设施域均可包括多种不同网络节点(例如，服务器、网关、装置等)。例如，场域可包括M2M网关14和终端装置18。将了解，任何数量的M2M网关装置14和M2M终端装置18可根据需要包括在M2M/IoT/WoT通信系统10中。M2M网关装置14和M2M终端装置18中的每一者被配置为使用通信电路经由通信网络12或直接无线电链路发射和接收信号。M2M网关14允许无线M2M装置(例如，蜂窝式和非蜂窝式)以及固定网络M2M装置(例如，PLC)通过诸如通信网络12等运营商网络或者直接无线电链路来通信。例如，M2M终端装置18可经由通信网络12或直接无线电链路收集数据并且将所述数据发送到M2M应用20或其它M2M装置18。M2M终端装置18还可从M2M应用20或M2M终端装置18接收数据。另外，可经由M2M服务层22向M2M应用20发送以及从M2M应用20接收数据和信号，如下文所述。M2M终端装置18和网关14可经由包括(例如)蜂窝式、WLAN、WPAN(例如，Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线在内的各种网络进行通信。
示例性M2M终端装置18包括但不限于平板电脑、智能电话、医疗装置、温度和天气监视器、联网汽车、智能电表、游戏控制台、个人数字助理、健康和健身监视器、灯、恒温器、电器、车库门以及其它基于致动器的装置、安全性装置和智能插座。
参看图44B，场域中的所示M2M服务层22为M2M应用20、M2M网关装置14和M2M终端装置18以及通信网络12提供服务。通信网络12可用以实施所公开的实施例的功能性并且可包括诸如服务层102、应用204和202、SLDA 902、SLDA-PA 904、SLDA-PI 906、SLDA-PD 908、SLDA-PE 910、SLSA 1402、SLSA-PA 1404、SLSA-PD 1406、SLSA-PI 1412、SLSA-PE 1410、SL-PCF 1408、实体1502、1602、3402、3404、3502、3504、3506、3602、3604、3606、策略服务器1504、RHF 1604、客户端1702、DAEF 1802和DAEF支付、DGF 2102、MAF 2302、MEF 2304、授权功能3702、支付功能3802、互换功能3902、安全性功能4002、服务层订阅核实功能4102、声誉核实功能4202等功能性和逻辑实体以及用于存储所公开的资源并对其进行操作的逻辑实体和用于产生诸如界面4302等界面的逻辑实体。M2M服务层22可由一个或多个服务器、计算机、装置、虚拟机(例如，云/存储场等)等实施，包括(例如)下文所述的图44C和44D所示的装置。将理解，M2M服务层22可根据需要与任何数量的M2M应用、M2M网关14、M2M终端装置18和通信网络12通信。M2M服务层22可由网络的一个或多个节点实施，节点可包括服务器、计算机、装置等。M2M服务层22提供适用于M2M终端装置18、M2M网关14和M2M应用20的服务能力。M2M服务层22的功能可以多种方式来实施，例如作为web服务器、在蜂窝式核心网络中、在云中等。
类似于所示的M2M服务层22，在基础设施域中存在M2M服务层22’。M2M服务层22’向基础设施域中的M2M应用20’和底层通信网络12提供服务。M2M服务层22’还向场域中的M2M网关14和M2M终端装置18提供服务。将理解，M2M服务层22’可与任何数量的M2M应用、M2M网关和M2M装置通信。M2M服务层22’可通过不同服务提供商与服务层交互。M2M服务层22’可由网络的一个或多个节点实施，所述节点可包括服务器、计算机、装置、虚拟机(例如，云计算/存储农场等)等。
还参看图44B，M2M服务层22和22’提供不同应用和领域可利用的一组核心服务交付能力。这些服务能力使得M2M应用20和20’能够与装置交互并且执行诸如数据收集、数据分析、装置管理、安全性、结算、服务/装置发现等功能。基本上，这些服务能力使应用摆脱实施这些功能性的负担，因此简化应用开发并且减小成本和上市时间。服务层22和22’还使得M2M应用20和20’能够结合服务层22和22’提供的服务通过网络12进行通信。
本申请的方法可被实施为服务层22和22’的一部分。服务层22和22’是通过一组应用编程接口(API)和底层联网接口支持增值服务能力的软件中间件层。ETSI M2M和oneM2M两者使用可包含本申请的连接方法的服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可在M2M装置(其中其被称为装置SCL(DSCL))、网关(其中其被称为网关SCL(GSCL))和/或网络节点(其中其被称为网络SCL(NSCL))内实施。oneM2M服务层支持一组公共服务功能(CSF)(即，服务能力)。一组一个或多个特定类型的CSF的实例化被称为公共服务实体(CSE)，其可被托管在不同类型的网络节点(例如，基础设施节点、中间节点、专用节点)上。另外，本申请的连接方法可被实施为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问服务的M2M网络的一部分，诸如本申请的连接方法。
在一些实施例中，M2M应用20和20’可结合所公开的系统和方法来使用。M2M应用20和20’可包括与UE或网关交互的应用，并且还可结合其它所公开的系统和方法来使用。
在一个实施例中，诸如服务层102、应用204和202、SLDA 902、SLDA-PA 904、SLDA-PI 906、SLDA-PD 908、SLDA-PE 910、SLSA 1402、SLSA-PA 1404、SLSA-PD 1406、SLSA-PI 1412、SLSA-PE 1410、SL-PCF 1408、实体1502、1602、3402、3404、3502、3504、3506、3602、3604、3606、策略服务器1504、RHF 1604、客户端1702、DAEF 1802和DAEF支付、DGF 2102、MAF 2302、MEF 2304、授权功能3702、支付功能3802、互换功能3902、安全性功能4002、服务层订阅核实功能4102、声誉核实功能4202等逻辑实体以及用于存储所公开的资源并对其进行操作的逻辑实体和用于产生诸如界面4302等界面的逻辑实体可被托管在M2M节点(诸如M2M服务器、M2M网关或M2M装置)所托管的M2M服务层实例内，如图44B所示。例如，诸如服务层102、应用204和202、SLDA 902、SLDA-PA 904、SLDA-PI 906、SLDA-PD 908、SLDA-PE 910、SLSA 1402、SLSA-PA 1404、SLSA-PD 1406、SLSA-PI 1412、SLSA-PE 1410、SL-PCF 1408、实体1502、1602、3402、3404、3502、3504、3506、3602、3604、3606、策略服务器1504、RHF 1604、客户端1702、DAEF 1802和DAEF支付、DGF 2102、MAF 2302、MEF 2304、授权功能3702、支付功能3802、互换功能3902、安全性功能4002、服务层订阅核实功能4102、声誉核实功能4202等逻辑实体以及用于存储所公开的资源并对其进行操作的逻辑实体和用于产生诸如界面4302等界面的逻辑实体可包括位于M2M服务层实例内或作为现有服务能力内的子功能的各个服务能力。
M2M应用20和20’可包括各种行业(诸如但不限于交通运输、健康保健、联网家庭、能源管理、资产跟踪以及安全监督)中的应用。如上文提到，跨系统的装置、网关、服务器和其它节点运行的M2M服务层支持诸如数据收集、装置管理、安全性、结算、位置跟踪/地理围栏、装置/服务发现和遗留系统集成等功能，并且将这些功能作为服务提供给M2M应用20和20’。
通常，服务层22和22’定义通过一组应用编程接口(API)和底层联网接口支持增值服务能力的软件中间件层。ETSI M2M和oneM2M架构两者定义服务层。ETSI M2M的服务层被称为服务能力层(SCL)。SCL可在ETSI M2M架构的多种不同节点中实施。例如，服务层的实例可在M2M装置(其中其被称为装置SCL(DSCL))、网关(其中其被称为网关SCL(GSCL))和/或网络节点(其中其被称为网络SCL(NSCL))内实施。oneM2M服务层支持一组公共服务功能(CSF)(即，服务能力)。一组一个或多个特定类型的CSF的实例化被称为公共服务实体(CSE)，其可被托管在不同类型的网络节点(例如，基础设施节点、中间节点、专用节点)上。第三代合作伙伴计划(3GPP)还已经定义了用于机器类型通信(MTC)的架构。在那个架构中，服务层及其所提供的服务能力被实施为服务能力服务器(SCS)的一部分。无论是在ETSI M2M架构的DSCL、GSCL或NSCL中、在3GPP MTC架构的服务能力服务器(SCS)中、在oneM2M架构的CSF或CSE中还是在网络的某个其它节点中体现，服务层的实例可作为在网络中的一个或多个独立节点(包括服务器、计算机和其它计算装置或节点)上或者作为一个或多个现有节点的一部分执行的逻辑实体(例如，软件、计算机可执行指令等)来实施。作为实例，服务层或其部件的实例可以在具有下文所述的图44C或图44D所示的总体架构的网络节点(例如，服务器、计算机、网关、装置等)上运行的软件的形式来实施。
另外，诸如服务层102、应用204和202、SLDA 902、SLDA-PA 904、SLDA-PI 906、SLDA-PD 908、SLDA-PE 910、SLSA 1402、SLSA-PA 1404、SLSA-PD 1406、SLSA-PI 1412、SLSA-PE 1410、SL-PCF 1408、实体1502、1602、3402、3404、3502、3504、3506、3602、3604、3606、策略服务器1504、RHF 1604、客户端1702、DAEF 1802和DAEF支付、DGF 2102、MAF 2302、MEF 2304、授权功能3702、支付功能3802、互换功能3902、安全性功能4002、服务层订阅核实功能4102、声誉核实功能4202等逻辑实体以及用于存储所公开的资源并对其进行操作的逻辑实体和用于产生诸如界面4302等界面的逻辑实体可被实施为使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问本申请的服务的M2M网络的一部分。
图44C是诸如M2M装置18、M2M网关14、M2M服务器等M2M网络节点30的示例性硬件/软件架构的框图。节点30可执行或包括诸如服务层102、应用204和202、SLDA 902、SLDA-PA 904、SLDA-PI 906、SLDA-PD 908、SLDA-PE 910、SLSA 1402、SLSA-PA 1404、SLSA-PD 1406、SLSA-PI 1412、SLSA-PE 1410、SL-PCF 1408、实体1502、1602、3402、3404、3502、3504、3506、3602、3604、3606、策略服务器1504、RHF 1604、客户端1702、DAEF 1802和DAEF支付、DGF 2102、MAF 2302、MEF 2304、授权功能3702、支付功能3802、互换功能3902、安全性功能4002、服务层订阅核实功能4102、声誉核实功能4202等逻辑实体以及用于存储所公开的资源并对其进行操作的逻辑实体和用于产生诸如界面4302等界面的逻辑实体。装置30可为如图44A至44B所示的M2M网络的一部分或非M2M网络的一部分。如图44C所示，M2M节点30可包括处理器32、不可拆卸存储器44、可拆卸存储器46、扬声器/麦克风38、小键盘40、显示器、触控板和/或指示器42、电源48、全球定位系统(GPS)芯片组50和其它外围设备52。节点30还可包括通信电路，诸如收发器34和发射/接收元件36。将了解，在保持与实施例一致的同时，M2M节点30可包括前述元件的任何子组合。这个节点可为实施本文所述的SMSF功能性的节点。
处理器32可为通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心联合的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其它类型的集成电路(IC)、状态机等。一般来说，处理器32可执行存储在节点的存储器(例如，存储器44和/或存储器46)中的计算机可执行指令以便执行所述节点的各种所需功能。例如，处理器32可执行信号编码、数据处理、功率控制、输入/输出处理和/或使得M2M节点30能够在无线或有线环境中进行操作的任何其它功能性。处理器32可运行应用层程序(例如，浏览器)和/或无线电接入层(RAN)程序和/或其它通信程序。处理器32还可执行安全性操作，诸如认证、安全性密钥协商和/或密码操作，诸如在接入层和/或应用层处。
如图44C所示，处理器32耦接到其通信电路(例如，收发器34和发射/接收元件36)。通过执行计算机可执行指令，处理器32可控制通信电路，以便致使节点30经由其所连接的网络与其它节点进行通信。明确地说，处理器32可控制通信电路以便执行本文和权利要求书中所描述的发射和接收步骤。尽管图44C将处理器32和收发器34描绘为单独部件，但将了解，处理器32和收发器34可一起集成在电子封装或芯片中。
发射/接收元件36可被配置为向其它M2M节点(包括M2M服务器、网关、装置等等)发射信号或从其接收信号。例如，在一个实施例中，发射/接收元件36可为被配置为发射且/或接收RF信号的天线。发射/接收元件36可支持各种网络和空中接口，诸如WLAN、WPAN、蜂窝式等。在一个实施例中，发射/接收元件36可为被配置为发射且/或接收(例如)IR、UV或可见光信号的发射器/检测器。在又一个实施例中，发射/接收元件36可被配置为发射且接收RF和光信号两者。将了解，发射/接收元件36可被配置为发射且/或接收无线或有线信号的任何组合。
另外，虽然发射/接收元件36在图44C中被描绘为单个元件，但M2M节点30可包括任何数量的发射/接收元件36。更具体地说，M2M节点30可采用MIMO技术。因此，在一个实施例中，M2M节点30可包括两个或更多个发射/接收元件36(例如，多个天线)用于发射和接收无线信号。
收发器34可被配置为对将由发射/接收元件36发射的信号进行调制并且对由发射/接收元件36接收的信号进行解调。如上文提到，M2M节点30可具有多模式能力。因此，收发器34可包括多个收发器用于使得M2M节点30能够经由多个RAT(诸如UTRA和IEEE 802.11)通信。
处理器32可从任何类型的合适存储器(诸如不可拆卸存储器44和/或可拆卸存储器46)存取信息并且将数据存储在其中。例如，处理器32可在其存储器中存储会话上下文，如上所述。不可拆卸存储器44可包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其它类型的存储器存储装置。可拆卸存储器46可包括订户身份模块(SIM)卡、存储棒、安全数字(SD)存储卡等。在其它实施例中，处理器32可从不在物理上位于M2M节点30上(诸如位于服务器或家用计算机上)的存储器存取信息并且将数据存储在其中。处理器32可被配置为控制显示器或指示器42上的照明模式、图像或颜色以反映M2M服务层会话迁移或共享的状态或者从用户获得输入或向用户显示关于节点的会话迁移或共享能力或设置的信息。在另一个实例中，显示器可示出关于会话状态的信息。本公开在oneM2M实施例中定义了RESTful用户/应用API。图形用户界面(其可在显示器上展示)可放置在API之上以允许用户经由本文所述的底层服务层会话功能性交互地建立并管理E2E会话或者其迁移或共享。
处理器32可从电源48接收电力，并且可被配置为向M2M节点30中的其它部件分发且/或控制电力。电源48可为用于向M2M节点30供电的任何合适装置。例如，电源48可包括一个或多个干电池(例如，镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。
处理器32还可耦接到GPS芯片组50，其被配置为提供关于M2M节点30的当前位置的位置信息(例如，经度和纬度)。将了解，M2M节点30可借助于任何合适的位置确定方法获取位置信息，同时保持与实施例一致。
处理器32可进一步耦接到其它外围设备52，其可包括提供额外特征、功能性和/或有线或无线连接性的一个或多个软件和/或硬件模块。例如，外围设备52可包括诸如加速度计、生物计量(例如，指纹)传感器、电子罗盘、卫星收发器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其它互连接口、振动装置、电视收发器、免提耳机、蓝牙模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、互联网浏览器等各种传感器。
节点30可体现在其它设备或装置中，诸如传感器、消费型电子装置、可穿戴装置(诸如智能手表或智能服装)、医疗或电子健康装置、机器人、工业设备、无人机、交通工具(诸如汽车、卡车、火车或飞机)。节点30可经由一个或多个互连接口(诸如可包括外围设备52中的一者的互连接口)连接到此类设备或装置的其它部件、模块或系统。另选地，节点30可包括设备或装置，诸如传感器、消费型电子装置、可穿戴装置(诸如智能手表或智能服装)、医疗或电子健康装置、机器人、工业设备、无人机、交通工具(诸如汽车、卡车、火车或飞机)。
图44D是示例性计算系统90的框图，所述计算系统还可用于实施M2M网络的一个或多个节点，诸如M2M服务器、网关、装置或其它节点。计算系统90可包括计算机或服务器，并且可主要由在任何位置的软件形式的计算机可读指令或由存储或存取此类软件的任何装置控制。计算系统90可执行或包括诸如服务层102、应用204和202、SLDA 902、SLDA-PA 904、SLDA-PI 906、SLDA-PD 908、SLDA-PE 910、SLSA 1402、SLSA-PA 1404、SLSA-PD 1406、SLSA-PI 1412、SLSA-PE 1410、SL-PCF 1408、实体1502、1602、3402、3404、3502、3504、3506、3602、3604、3606、策略服务器1504、RHF 1604、客户端1702、DAEF 1802和DAEF支付、DGF 2102、MAF 2302、MEF 2304、授权功能3702、支付功能3802、互换功能3902、安全性功能4002、服务层订阅核实功能4102、声誉核实功能4202等逻辑实体以及用于存储所公开的资源并对其进行操作的逻辑实体和用于产生诸如界面4302等界面的逻辑实体。计算系统90可为M2M装置、用户设备、网关、UE/GW或包括(例如)移动照护网络的节点、服务层网络应用提供商、终端装置18或M2M网关装置14在内的任何其它节点。此类计算机可读指令可在处理器(诸如中央处理单元(CPU)91)内执行以致使计算系统90进行工作。在许多已知工作站、服务器和个人计算机中，中央处理单元91由称为微处理器的单芯片CPU实施。在其它机器中，中央处理单元91可包括多个处理器。协处理器81是执行额外功能或协助CPU 91的与主CPU 91相异的可选处理器。CPU 91和/或协处理器81可接收、生成并且处理与所公开的用于E2E M2M服务层会话的系统和方法相关的数据，诸如接收会话凭证或基于会话凭证进行认证。
在操作中，CPU 91提取、解码并执行指令，并且经由计算机的主要数据传送路径(系统总线80)将信息传送到其它资源以及从其它资源传送信息。此类系统总线连接计算系统90中的部件并且定义用于数据交换的媒体。系统总线80通常包括用于发送数据的数据线路、用于发送地址的地址线路以及用于发送中断和用于操作系统总线的控制线路。此类系统总线80的实例是PCI(外围部件互连)总线。
耦接到系统总线80的存储器包括随机存取存储器(RAM)82和只读存储器(ROM)93。此类存储器包括允许存储并且检索信息的电路。ROM 93通常包含无法容易修改的存储数据。存储在RAM 82中的数据可由CPU 91或其它硬件装置读取或改变。对RAM 82和/或ROM 93的存取可由存储器控制器92控制。存储器控制器92可提供在执行指令时将虚拟地址翻译成物理地址的地址翻译功能。存储器控制器92还可提供隔离系统内的进程并且将系统进程与用户进程隔离的存储器保护功能。因此，以第一模式运行的程序可仅存取其自己进程虚拟地址空间所映射的存储器；其无法存取另一个进程的虚拟地址空间内的存储器，除非已经设置进程之间的存储器共享。
另外，计算系统90可包含负责从CPU 91向外围设备(诸如打印机94、键盘84、鼠标95和磁盘驱动器85)传送指令的外围设备控制器83。
由显示器控制器96控制的显示器86用于显示计算系统90所生成的视觉输出。此类视觉输出可包括文本、图形、动画图形和视频。显示器86可使用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子的平板显示器或触控面板实施。显示器控制器96包括生成发送给显示器86的视频信号所需要的电子部件。
另外，计算系统90可包含通信电路，诸如网络适配器97，其可用于将计算系统90连接到外部通信网络，诸如图44A和图44B的网络12，以使得计算系统90能够与网络的其它节点进行通信。
用户设备(UE)可为最终用户用来通信的任何装置。其可为手持式电话、装配有移动宽带适配器的膝上型计算机或任何其它装置。例如，UE可被实施为图44A至44B的M2M终端装置18或图44C的装置30。
应了解，本文所述的任何或所有系统、方法和过程可以存储在计算机可读存储媒体上的计算机可执行指令(即，程序代码)的形式体现，所述指令在由机器(诸如M2M网络的节点，包括例如M2M服务器、网关、装置等)执行时执行且/或实施本文所述的系统、方法和过程。具体地说，上述步骤、操作或功能中的任一者，包括网关、UE、UE/GW或者移动核心网络的节点、服务层或网络应用提供商中的任一者的操作，可以此类计算机可执行指令的形式实施。诸如服务层102、应用204和202、SLDA 902、SLDA-PA 904、SLDA-PI 906、SLDA-PD 908、SLDA-PE 910、SLSA 1402、SLSA-PA 1404、SLSA-PD 1406、SLSA-PI 1412、SLSA-PE 1410、SL-PCF 1408、实体1502、1602、3402、3404、3502、3504、3506、3602、3604、3606、策略服务器1504、RHF 1604、客户端1702、DAEF 1802和DAEF支付、DGF 2102、MAF 2302、MEF 2304、授权功能3702、支付功能3802、互换功能3902、安全性功能4002、服务层订阅核实功能4102、声誉核实功能4202等逻辑实体以及用于存储所公开的资源并对其进行操作的逻辑实体和用于产生诸如界面4302等界面的逻辑实体可以存储在计算机可读存储媒体上的计算机可执行指令的形式体现。计算机可读存储媒体包括以任何非暂态(即，有形或物理)方法或技术实施以用于存储信息的易失性和非易失性、可拆卸和不可拆卸媒体，但此类计算机可读存储媒体不包括信号。计算机可读存储媒体包括但不限于RAM、ROM、EEPROM、闪存存储器或其它存储器技术、CD ROM、数字通用磁盘(DVD)或其它光盘存储装置、磁带盒、磁带、磁盘存储装置或其它磁性存储装置，或者可用于存储所需信息并且可由计算机存取的任何其它有形或物理媒体。
在描述本公开的主题的优选实施例时，如附图所示，为了清楚起见采用特定术语。然而，所主张的主题不打算限于如此选择的特定术语，并且应当理解，每个特定元件包括以类似方式操作以实现类似目的的所有技术等效物。
本书面描述使用实例来公开本发明，包括最佳模式，并且还使得本领域的任何技术人员均能够实践本发明，包括制造和使用任何装置或系统以及执行任何所并入的方法。本发明的可取得专利的范围由权利要求书定义，并且可包括本领域的技术人员想到的其它实例。如果此类其它实例具有不与权利要求书的字面语言不同的元件，或者如果其包括与权利要求书的字面语言无实质区别的等效元件，则此类其它实例预期属于权利要求书的范围内。