CN111357259A - 服务层操作的自适应控制机制 - Google Patents

服务层操作的自适应控制机制 Download PDF

Info

Publication number
CN111357259A
CN111357259A CN201980005684.5A CN201980005684A CN111357259A CN 111357259 A CN111357259 A CN 111357259A CN 201980005684 A CN201980005684 A CN 201980005684A CN 111357259 A CN111357259 A CN 111357259A
Authority
CN
China
Prior art keywords
service layer
layer entity
request
additional
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201980005684.5A
Other languages
English (en)
Other versions
CN111357259B (zh
Inventor
Q·李
W·R·弗林
D·N·希德
陈卓
M·F·斯塔西尼克
R·迪亚罗拉莫
C·M·米拉迪恩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Convida Wireless LLC
Original Assignee
Convida Wireless LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Convida Wireless LLC filed Critical Convida Wireless LLC
Publication of CN111357259A publication Critical patent/CN111357259A/zh
Application granted granted Critical
Publication of CN111357259B publication Critical patent/CN111357259B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/148Migration or transfer of sessions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0813Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0876Aspects of the degree of configuration automation
    • H04L41/0886Fully automatic configuration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051Service on demand, e.g. definition and deployment of services in real time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/34Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/66Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Environmental & Geological Engineering (AREA)
  • Automation & Control Theory (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)

Abstract

可以通过由服务器管理员以结构化但灵活的方式编程的一个或多个自适应规则来实现服务层自适应。作为将自适应控制集成到其操作中的一部分,服务层可被配置为提供以下能力:接收可以指定自适应规则的请求,通过返回给请求者的响应代码提供对服务层由于缩减功能状态而不能处理请求的指示,以及发送对更多服务器资源的请求或者将应用、服务或服务实例移动到另一平台。

Description

服务层操作的自适应控制机制
相关申请的交叉引用
本申请要求2018年1月9日提交的美国临时申请第62/615043号的权益,其全部内容通过引用合并于此。
背景技术
在物联网(IoT)系统中,服务层向与其通信的设备和客户端提供许多能力。这些能力是服务层提供的服务,并且可包括资源发现、订阅和通知服务、设备管理、重定向、组操作、语义查询等。此外,一些服务层可以代表设备和/或客户端来托管资源。这些资源的可用性可能需要附加服务,诸如资源管理、授权、访问控制、时间序列管理、事件检测、事务管理、互工作(interwork)等。图1示出了由服务层(诸如oneM2M公共服务实体(CSE))提供的一些服务的示例。
前述能力中的每个可能需要某些服务器资源,诸如CPU利用率、存储器、存储设备、带宽等。延迟或服务器执行特定任务所花费的时间也可能会影响服务层的整体操作。在服务器操作中会表现出各种形式的延迟,从处理请求到发送响应、数据库访问延迟、网络节点之间的延迟等。服务器资源的可用性和并发处理的数量可能会对服务层的操作产生影响。
发明内容
本文中公开了使得服务层能够自我监视关键服务层度量并且以自主方式自适应其操作的方法和系统。可以通过可以由服务器管理员以结构化但灵活的方式编程的一个或多个自适应规则来实现服务层自适应。在自适应期间,服务层可以返回新的响应代码,以向请求者通知它正在以缩减功能状态运行,并且提供有关何时重新提交请求的指导。公开了示例性oneM2M实施例,其示出了可以如何在服务层部署中利用所提出的方法和系统。作为将自适应控制集成到其操作中的一部分,服务层可被配置为执行以下操作中的一个或多个:
提供接收可以在其中指定自适应规则的请求的能力。自适应规则可以包括监视组件,该监视组件指定某些服务层度量与某个或某些设定的阈值的比较。自适应规则可以包括命令组件,以自适应服务层内的特定操作并且可选地达到某个设定的持续时间。可以创建一个或多个自适应规则以监视和自适应服务层操作;
通过返回给请求者的响应代码,提供对服务层由于缩减功能状态无法处理请求的指示。缩减功能状态可能是执行一个或多个自适应规则的结果。响应可以包括附加信息,以自适应请求者的操作,例如在以后的时间重新发送请求;以及
发送对更多服务器资源的请求,或者发送将应用、服务或服务实例移动到其他平台的请求。请求可以包括其他信息,诸如导致请求的状况、需要服务器资源的持续时间、未满足的延迟要求等。请求可以被发送到管理和编排(MANO)系统。
附图说明
为了促进对本申请的更稳健的理解,现在参考附图,在附图中,相同的元素用相同的附图标记表示。这些附图不应被解释为限制本申请,而旨在仅是示例性的。
图1示出了由服务层服务器提供的示例服务的框图;
图2示出了示例服务层服务器崩溃的流程图;
图3示出了创建自适应规则的示例过程的流程图;
图4示出了用于使用新响应代码的示例方法的流程图;
图5示出了在应用实体注册期间用户优先级级别的示例配置的流程图;
图6示出了包含用户优先级级别的示例请求的流程图;
图7示出了在CSE自适应期间响应代码反馈的示例的流程图;
图8示出了示例用户界面;
图9A示出了可以实现一个或多个所公开的实施例的示例机器对机器(M2M)或物联网(IoT)通信系统的示例系统图;
图9B示出了可以在图9A中所示的M2M/IoT通信系统内使用的示例架构的示例系统图;
图9C示出了可以在图9A中所示的通信系统内使用的示例M2M/IoT终端或网关设备的示例系统图;和
图9D示出了可以实施图9A的通信系统的各方面的示例计算系统的示例框图。
具体实施方式
服务层操作可能受到可用服务器资源和处理延迟的限制。如果组成员的数量很大,则服务层(SL)组操作可能需要分配大量存储器来处理许多并行请求。请求的延迟可能取决于外部设备或客户端对重定向的请求的响应。其他请求可能只需要从服务层检索资源,而不必依赖于外部实体或需要大量的服务器资源。这些请求可能需要最少的服务器资源以及最小的处理延迟。服务层可能具有分配给其许多能力的有限资源,并且可能会产生取决于所提供的SL服务的不同处理延迟。
服务层可能需要随时可用并且以某种自主的方式运行,而无需来自系统管理员的过多干预。服务层可能还需要处理来自设备和客户端的大量同时请求。一些请求也可能是时间关键的,并且期望的应用可能需要快速响应。因此,服务层的稳健操作对于使得IoT系统能够高效操作且没有中断至关重要。
在oneM2M规范内,设备配置功能(DCF)以及设备诊断与监视功能(DDMF)两者都可以为CSE提供一些监视能力(参见oneM2M TS-0001,功能架构,V3.7.0)。这些功能主要以CSE管理的设备为中心,并且仅关注于对设备进行配置和提供设备的状态。然而,这些能力并没有使用所提供的度量来自适应CSE的操作。
图2示出了服务层操作的示例,其中来自两个实体的请求可能导致服务器崩溃。如步骤1中所示,由于服务层运行缓慢且不可靠,因此服务层的操作可能已经出现问题。这可能指示服务层过载并且服务器资源正在减少。如步骤2中所示,SL设备执行组扇出操作以更新作为组成员的十个SL资源。当在步骤3中处理各个扇出操作时,在步骤4中触发三个订阅,以及生成通知并且将其发送给相应的接收者。如步骤5中所示,新请求被接收,其中SL应用想要执行语义查询。该新请求和待决的组请求加上服务层的过载状况,导致服务器变得无响应,如步骤6中所示,最后在步骤7中崩溃。应该意识到,这是可能导致SL无响应并且崩溃的许多场景之一。还应该意识到,图2中所示的SL应用和SL设备可以都是SL应用或都是SL设备。还应该意识到,问题可能不像服务器变得无响应并且崩溃那样严重。问题可能是SL确定它已过载,并且因此可能不接受新请求、拒绝新请求或者以不及时的方式来服务请求。
图2的示例突出显示了所有服务器操作的共同问题,而不仅仅是服务层。主要解决方案可能是增加服务器可用的硬件资源,从而可以避免崩溃。其他解决方案可能涉及安装监视软件,以警告服务器管理员采取如下预防性步骤:通过执行适当的维护来避免服务器过载。这些解决方案确实解决了服务器崩溃,但是它们涉及添加额外的硬件,这会产生成本,以及服务器管理员需要查看监视报告并且在需要时采取预防措施。
服务层具有定义良好的服务,服务层将这些服务提供给与服务层通信的设备和应用。这些服务各自对硬件资源和处理延迟有不同的要求。某些服务很简单,以及可能需要来自服务器的少量存储器并且需要访问数据库。其他服务可能会涉及更多并且需要更大量的存储器,可能涉及处理多个请求,以及可能涉及处理需要被路由到服务层控制之外的远程实体的请求。这样,这些服务可能会在服务层上产生更大的负载,并且如果服务器已经开始过载,甚至可能导致服务层的崩溃。
如果服务层有可用的机制来不仅监视其操作而且还基于所监视的度量来自适应其操作,则服务层可能能够延长其操作状态并且潜在地避免服务器崩溃。这些机制可以暂时挂起某些SL服务的操作,以防止服务器过载并且使得服务层能够以自主方式操作。所述机制的其他好处是服务层的扩展的操作状态,这允许服务器管理员有时间执行服务器维护或升级以防止服务器崩溃。
本文中公开的方法和系统可以使得服务层能够自我监视关键SL度量并且以自主方式自适应其操作。可以通过可以由服务器管理员以结构化但灵活的方式编程的一个或多个自适应规则来实现服务层自适应。在自适应期间,服务层可以返回新的响应代码,以向请求者通知它正在以缩减功能状态运行,并且提供有关何时重新提交请求的指导。公开了示例性oneM2M实施例,其示出了可以如何在服务层部署中采用所提出的方法和系统。
作为将自适应控制集成到其操作中的一部分,服务层可被配置为执行以下操作中的一个或多个:
提供接收可以在其中指定自适应规则的请求的能力。自适应规则可以包括监视组件,该监视组件指定某些服务层度量与某个或某些设定的阈值的比较。另外,自适应规则可以包括命令组件,以自适应服务层内的特定操作并且可选地达到某个设定的持续时间。可以创建一个或多个自适应规则以监视和自适应服务层操作;
通过返回给请求者的响应代码,提供对服务层由于缩减功能状态无法处理请求的指示。缩减功能状态可能是执行一个或多个自适应规则的结果。响应可以包括附加信息,以自适应请求者的操作,例如在以后的时间重新发送请求;以及
发送对更多服务器资源的请求,或者发送将应用、服务或服务实例移动到其他平台的请求。请求可以包括其他信息,诸如导致请求的状况、需要服务器资源的持续时间、未满足的延迟要求等。在一个实施例中,请求可以被发送到管理和编排(MANO)系统。
本文中公开了服务层操作的自适应控制方法。例如,提出了新的SL资源,其中将服务器的操作度量暴露给服务器管理员和授权用户。该资源可以提供描述服务层健康状况的度量的实时统计信息。将提供这些度量的示例,诸如CPU利用率、可用的存储器、所使用的存储器、处理延迟等。
另外,提出了如下机制,其中服务器管理员或授权用户能够基于所提供的操作度量或用户提供的优先级级别来控制服务层的操作。在这种情况下,控制是指特定SL服务或操作的挂起、延迟、继续、禁用或启用。该机制可以被实现为由服务器管理员或授权用户创建的一个或多个SL资源,以基于操作度量来控制服务层的操作。该机制将提出引入服务类型、资源级别和用户优先级的类别。还可以添加其他类别,以提供对服务层的更细粒度控制。然后,服务器管理员或授权用户可以使用服务类别、资源级别和优先级来配置新资源,以在一定持续时间内挂起、延迟、继续、禁用或启用服务,以最小化服务层崩溃的可能性。
最后,在SL自适应机制被激活的情况下,提出了新的响应消息,以向请求者传达服务层处于缩减功能状态。这些消息可提供如下指示:请求被验证,但由于服务或操作暂时不可用,服务层无法处理该请求。消息还可以向请求者通知稍后重试以便获得所期望的服务。如果有足够的服务器资源可用,则服务层甚至可以将请求排队以供未来处理。
作为新响应消息的补充或替代,服务层可以与管理和编排系统接口连接,以请求更多服务器资源。该请求可以指示处理该请求所需要的服务器资源的量、需要服务器资源的设定的持续时间,并且可能指示应用或服务向其他平台的迁移。
使用本文中公开的方法和系统,可以使服务层的稳健操作尽可能地可用,并且可以使服务层过载和崩溃的机会最小化。这些机制可以通过自适应于服务器状况的变化,使得服务层能够以自主方式操作。注意,在这种情况下,服务器可以指云服务器、网关或运行服务层的设备。通过延长服务层的操作状态,服务器管理员和授权用户可以有更多时间来解决影响服务器和用户的问题。例如,其他服务层和应用可能不太可能遇到操作问题。尽管所公开的方法和系统关注于oneM2M服务层操作,但是它们也可应用于其他SL架构。
为了提供对服务层的自适应控制,可能需要使用一些度量来提供对服务器操作行为的洞察。表1示出了服务层的一些示例度量。这些度量可以由服务层或由监视服务器资源的某个外部进程来提供。
表1:服务层度量的示例
Figure BDA0002487504920000071
Figure BDA0002487504920000081
表1中列出的操作度量可以被实现为具有与列出的度量相对应的关联属性列表的SL资源。该资源可以由服务层拥有,并且可以由服务器管理员或授权用户访问。每个度量可以提供与服务层在一段时间内的操作有关的底层测量或计算的实时状态。除了实时值之外,还可以呈现最大值和最小值,以用于将当前服务器操作与服务器生命周期期间的最好和最坏情况的操作度量进行比较。可以为每个度量提供附加的详细信息,例如,表示操作延迟的参数也可以提供有关查询的附加详细信息(请求者、查询详细信息等)。还应该意识到,该资源可以由不同的服务层来托管。例如,网关服务层可以创建该资源或将该资源通告给M2M服务器,以便M2M服务器上的应用或服务可以监视网关的资源利用率。然后,这些比较可用来自适应地控制SL服务,如下一节中所描述的。
为了使自适应控制运作,可能需要定义可以被控制的SL服务。这些定义可以被分组在一起作为服务类型,这些服务类型被组织为从关键服务到可选服务的级别。然而,可能需要某些SL服务以便使服务层操作,因此这些SL服务不能包含在可能被禁用的服务类型级别中。这些服务的示例可以是对现有SL资源的检索/更新/删除、安全服务、授权和访问控制检查等。
SL服务的分组可能取决于服务对服务器操作所具有的影响。诸如服务器资源要求(包括CPU和存储器使用率、数据库访问、远程操作、处理延迟等)之类的因素可以帮助服务器管理员和授权用户确定每个服务被分组到哪个服务类型级别中。表2列出了可以被定义并且可用于自适应控制的一些SL服务类型的示例。
表2:SL服务类型的示例
Figure BDA0002487504920000091
表2中呈现的示例服务类型被分组为五个级别。然而,可以添加更多级别,以对由服务层提供的各种服务进行更细粒度的控制。这些级别是按照服务对服务器操作的关键程度来组织的,其中更关键的服务首先被列出,因此可以最后被禁用。可以将更高级但可选的功能分组为与消耗大量服务器资源的服务一样不那么关键。这些服务的分组也可以随时间而改变,因为服务器管理员和授权用户可以根据用户要求来发现需要增加或减少服务的级别。
除了SL服务之外,创建或执行对某些SL资源的操作也可能会影响服务器操作。有时,对资源的请求可能要求某些服务进行操作,诸如对oneM2M扇出资源的请求触发服务层内的组操作。在其他时候,创建某些资源的请求可能涉及在以后的某个时间实例处触发SL服务。例如,创建订阅资源可能会在未来触发通知。类似地,创建应用资源可能要求在未来对一个或多个容器、订阅和/或内容实例(contentInstance)资源进行操作。对资源的某些请求可能仅影响SL可以管理的服务器内的操作,诸如创建oneM2M内容实例(contentInstance)资源,这主要要求数据库访问。SL资源的分组提供了辅助级别的自适应控制,其中如果SL在服务器资源中受到限制,则可以禁用创建或执行对于某些资源的操作。表3示出了如何对oneM2M资源进行分组以提供对服务层操作的更细粒度和自适应控制的一些示例。
表3:SL(oneM2M)资源级别的示例
Figure BDA0002487504920000101
如表3中所示并且类似于SL服务,SL资源可以被分组为多个级别,以用于服务器操作的自适应控制。可以按照与SL服务类似的方式来组织这些级别,其中最关键的SL资源首先被列出,并且具有较低的资源级别。这些资源(例如oneM2M的ACP和内容实例(contentInstance)资源)也可能对服务层的操作具有最小的影响。其他资源(例如oneM2M的AE和组资源)可能要求更多的服务器资源。在AE资源的情况下,创建资源在创建时具有最小的影响,但是影响可能会在未来实现,因为AE可能随后能够创建一个或多个容器、订阅甚至组资源。如果SL的服务器资源已经很低,则最好的做法可能是限制访问SL服务的用户(或AE)的数量。通过拒绝AE的请求,服务层可能能够专注于为已经在服务器上创建的AE提供服务。
服务类型级别和SL资源级别两者提供了在自适应服务层操作时使用的两个操作组件集合。然而,这些组件仅关注于服务层的两个方面--服务和资源。可以实现第三方面以考虑某些请求者可能比其他请求者具有更紧急需求的情况。例如,请求者可能更迫切需要获取通知,诸如,如果请求者是正在医院监视处于危急状况的患者的医生。另一方面,传感器设备可能最近已经升级以提供其中需要创建容器资源的新测量。在这种情况下,如果禁用了来自表3的资源级别3,则医生可能无法接收通知,而传感器可能能够创建用于新测量的容器。该第三方面考虑了服务层来处理用户优先级级别。在这样的情况下,具有第三操作组件可以提供甚至更细粒度的操作控制。根据需要,甚至可以添加更多的组件,并且这些组件是什么可以特定于部署或特定于服务器。除了用户优先级之外,其他组件可以基于与操作相关联的数据的重要性、与操作相关联的数据所需要的安全性以及自从与操作相关联的数据被更新或被访问起经过了多少时间。
使用在前面的表中提出的操作组件,可以设计结构化的表达式以形成用于服务层的自适应控制的基础。该表达式(在本文中被称为自适应规则)可以具有监视组件和控制组件,并且具有以下形式:
如果(度量)(运算符)(阈值)(时间窗口),→监视
(命令)[服务器操作]达到(持续时间)→控制
其中:
Figure BDA0002487504920000111
Figure BDA0002487504920000121
自适应规则的监视组件可以包括将度量的当前值与被确定为引起服务层的操作问题的阈值进行比较。附加地或替选地,可以将当前值与该度量的最小值或最大值进行比较。可以添加可选的时间窗口以限制何时执行比较--在窗口之内,启用监视;在窗口之外,不执行任何监视。阈值可以被更新以提供在创建比较时的灵活性。例如,在服务层的初始部署中,服务器管理员可以配置对特定度量具有积极性的初始阈值,以确保服务器可以支持尽可能多的用户。如果并且当服务器的性能以后受到大量用户的影响时,管理员可能需要降低阈值,以防止服务器崩溃的可能性。降低阈值还向服务器管理员提供预先警告,以使他们可以有更多时间来解决服务器操作中的任何潜在问题。
控制组件描述为自适应服务层的操作而可能需要执行的操作以及持续时间(如果有的话)。“(命令)”参数是确定响应于度量超过阈值而采取什么操作行为的命令。该命令可以是禁用、延迟、挂起、继续或启用服务层的特定操作。“[服务器操作]”参数指示受命令影响的服务和/或操作。该参数可以具有对将在以后描述的不同服务器操作的多个引用。最后,可选的“(持续时间)”参数确定命令在控制服务器操作时生效的持续时间。该参数可以被指定为所设定的持续时间,可以被指定为表示无限时段的空值,或者可以被指定为控制自适应的持续时间的操作度量。
“[服务器操作]”可以进一步被划分为子表达式,其中将不同的操作组件纳入到完整表达式中。例如,“禁用[ST3,not RL3,(UPL>5)]”可以被解释为禁用ST3(及以上)中列出的所有服务,但是不针对在级别3(及以下)中创建资源,并且仅针对大于5的用户优先级级别(UPL)。换句话说,ST3级别及以上级别(ST3至ST5)的所有服务和UPL大于5(UPL 6至10)的所有请求被禁用,但是在RL3级别及以下级别(RL1至RL3)创建资源被允许。注意,服务器操作的子表达式的组成和解释可以取决于实现方式,因为服务器的操作组件可能彼此不同。
用户优先级级别(UPL)是可以由服务层为系统中的所有请求者分配的级别。可以在诸如1到10之类的范围内指定这些优先级级别,其中一是最高优先级;并且可以将子范围分配给每个单独的请求者,例如7至10。可以将UPL分配为在设备的登录处理期间、设备的注册过程期间或其他某种服务订阅机制中的策略。可以细化该策略,其中为服务和资源分配了优先级级别。附加地或替选地,它可以不受约束,并且仅指示请求者可以在进行请求时使用的优先级级别的范围。
当组合在一起时,完整表达式描述了服务层中的状况,使得当它被检测到时,服务器的某些操作受到影响(可能达到所设定的持续时间)。表达式的监视组件可以检测感兴趣的服务器状况。当状况触发时,控制组件可以确定需要执行什么操作。例如,特定的服务或操作可以被挂起。最后,如果指定了持续时间,则挂起的服务可以在所设定的持续时间过去之后继续操作。
因此,整个表达式可以形成自适应规则,服务器管理员或授权用户可以使用所述自适应规则来配置SL如何自适应于SL资源利用率的变化。这些规则可以被配置为监视服务层的操作度量,并且通过根据需要禁用或挂起服务或者启用或继续服务来自适应对SL的操作的控制。然后,服务层的操作可以自适应于服务器资源的变化,从而避免操作缓慢或甚至服务器崩溃。该自适应可以确保服务层可用,但功能范围缩减。
可以根据服务层的需要,分别地并且在不同的时间创建自适应规则。当服务器管理员或授权用户了解服务器在某些状况下的行为时,可以添加更多规则。然后,这些规则可以共同地监视SL服务的所有方面,并且按规定来自适应SL服务的操作。自适应规则可以被实现为服务层内的资源,以允许服务器管理员和授权用户配置和更新规则以动态控制服务器操作的能力。
下面描述服务层可以在SL自适应期间如何响应来自其他服务层和应用的请求的示例方法,SL自适应是服务层的缩减功能状态。
利用适当地自适应服务层的操作的能力,可以添加机制以向请求者通知某些服务或操作暂时不可用,并且如果可能,指示可以在未来使该服务或操作可用的时间。该机制对于将服务根本不可用的情况(当服务层不支持特定服务时)与服务层确实支持服务但是已暂时挂起其操作的情况相区分开来说很重要。表4示出了服务层可以在响应消息中包括的一些示例响应代码,以提供对其缩减功能状态的指示。
表4:新SL响应代码的示例
Figure BDA0002487504920000141
Figure BDA0002487504920000151
每当服务层自适应生效并且所需要的服务或功能不可用时,可以使用表4中列出的每个响应代码。换句话说,表4中的响应代码可以通过激活一个或多个自适应规则来触发。在没有任何自适应的正常操作期间,可以不使用这些响应代码,因为所需要的服务可用来处理请求。
返回的响应代码取决于当请求正被处理时的服务层的状态。服务层的状态通过执行一个或多个自适应规则来确定。当处理请求所需要的特定服务已被禁用或挂起并且当前不可用时,可以返回响应代码SERVICE_TEMPORARY_UNAVAILABLE。如果禁用或挂起服务的自适应规则提供了持续时间,则该持续时间可以被包括在响应代码中,以指示何时重试该请求。如前所述,该响应代码可用来与服务层未实现服务的情况相区分。
每当自适应规则已经指定资源级别(RL)或其他SL操作组件已被挂起时,可以使用响应代码REQUEST_CANNOT_BE_PROCESS(请求无法被处理)。该响应代码可指示服务层处于缩减功能状态,并且无法处理请求。如果在自适应规则中指定了持续时间,则该值也可以被包括在响应中。最后,响应消息还可以包括有关什么阻止服务层处理请求的信息。
在服务层能够将请求排队但是直到稍后才能够处理该请求的情况下,可以将响应代码REQUEST_QUEUED_RESPONSE_LATER(请求被排队稍后响应)返回给请求者。可以将临时ID与响应代码一起返回,以用于请求-响应匹配。在一个实施例中,ID可以是URI,该URI指定响应将被存储在服务层中的位置以供以后检索。如果服务层具有有关何时可以返回响应的信息,则可以将该信息添加到响应消息。当服务层准备发送响应时,可以包括临时ID,以便请求者可以识别该响应是针对先前请求的。
对于返回了ACCESS_DENIED_PRIORITY_LEVEL(访问被拒绝的优先级级别)响应的情况,服务层可以指示由于没有对于请求的足够的用户优先级级别而无法处理该请求。可以从由服务层分配的策略中取得用户优先级级别,如先前所述的或在请求中明确指定的。无论哪种方式,所提供或所检索的优先级级别可能在服务层正在操作的当前自适应的优先级级别的范围之外。
在服务层处于非常有限的操作状态并且无法处理请求的情况下,可以返回SERVER_BUSY_TRY_AGAIN(服务器繁忙再次尝试)响应代码。该响应代码可以反映请求甚至未被验证的服务层操作的极端状态。该响应代码可以指示服务器管理员迫切需要在服务器崩溃之前解决服务层的问题。例如,如果服务层操作限于来自表2的ST1和来自表3的RL1,则可以返回该响应代码。通知也可以自动生成并且发送给服务器管理员,以指示服务层的问题的严重性。
下面描述如何通过与服务层的过程交互来使用所提出的方法和系统的示例。在部署时,服务层可能已将服务器的操作度量暴露为资源。然后,可以分别使用度量以及表2和表3中所示的服务类型和资源级别来创建自适应规则。此外,用户优先级级别1到10可用于分配给用户请求。服务层可以基于请求者的服务简档中的信息来分配这些UPL。替选地,可以向请求者分配用来进行请求的一系列UPL,并且可以根据特定请求的需要来使用不同的RPL。
一旦服务层被部署并且其操作度量可用,服务器管理员然后可以创建自适应规则,所述自适应规则根据需要来自适应服务器操作以帮助防止服务器崩溃。图3示出了示例过程,在该过程中,被实现为SL应用的服务器管理员在服务层上创建自适应规则。以下描述详细描述了图3的步骤。
在步骤1中,在部署时,可以将服务层的操作度量暴露为可寻址资源。该资源可包含表1中所示的属性中的一个或多个。
在步骤2中,充当服务器管理员角色的SL应用然后进行到在服务层上创建自适应规则。请求要创建的opControl(操作控制)资源可包含以下规则(注意,括号符号在表达式中用作分隔符):
如果(memUt>90%)(M-F 09:00,17:00),则挂起(ST4,RL3,UPL7)达30分钟
该表达式表示“如果存储器利用率大于90%,并且当前时间在每个工作日(即周一至周五)的上午9:00至下午5:00之间,则挂起服务类型4或更高、资源级别3或更高、以及用户优先级级别7或更大”。该特定规则仅与在正常工作周时间期间监视存储器利用率有关,并且仅在存储器使用率高时使用。要求表2中列出的ST4或更高的服务、或表3中的RL3或更高的资源、或用户优先级级别为7或更高中的一个的任何请求可被服务器拒绝服务。表示规则的替选方式如下:
如果(memUt>90%)(M-F 09:00,17:00),则挂起(ST>4,RL>3,UPL>7)达30分钟
在这种情况下,使用关系表达式明确地指定服务类型、资源级别和用户优先级级别。
在步骤3中,服务层验证请求以确保所有关系表达式具有匹配的数据类型。另外,服务层还可以将当前规则与现有规则进行比较,以确定是否存在任何冲突。
在步骤4中,将适当的响应从服务层发送到服务器管理员。服务层还可以包括规则ID或其他名称,以识别所创建的规则。如果与现有规则存在冲突,则服务层可以在响应中包括冲突规则的名称。
如果需要,管理员也可以更新自适应规则。该更新可以由用户报告服务层操作缓慢或者由服务器管理员或授权用户执行的测试来触发。规则本身可能是利用太大或太小的阈值来创建的。为了更新规则,服务器管理员或授权用户可能需要使用ID或资源名称发送针对该规则的请求,并且提供属性和对应的值。服务层可以检查现有规则,以确保不存在冲突。如果不再需要自适应规则,也可以将自适应规则删除。
一旦自适应规则被创建并且被激活,服务层就可以响应于无法被处理的请求而提供缩减功能的状态。这些新的响应代码可以在这样的自适应期间使用,以便请求者知道服务层能够处理请求,但是当前无法处理该请求。除了SERVER_BUSY_TRY_AGAIN响应代码之外,表4中列出的所有其他响应代码至少指示请求被验证并且准备好被处理。图4示出了这些新响应代码的三个使用示例。
以下描述详细描述了图4的步骤:
在步骤1中,服务层以自适应模式操作,其中表2的服务类型3-5、表3的资源级别3-4和大于7的用户优先级级别都被禁用。
在步骤2中,SL设备提交创建应用资源的请求。
在步骤3中,服务层处理请求,并且根据当前活动的自适应规则检查请求。服务层检测到该应用资源被列为RL4资源。结果,服务层向SL设备返回SERVICE_TEMPORARY_UNAVAILABLE(服务暂时不可用)响应代码。在这种情况下,服务层还向SL设备通知服务层可能能够在60分钟内处理请求。服务层还可以生成报告,诸如收费记录,以记录操作已被延迟或不被允许。可以将报告发送到MANO系统,以便MANO系统可以考虑将更多资源提供给服务层。
在步骤4中,SL应用正尝试执行设备管理(DM)操作以检索有关其感兴趣的设备的某些信息。该请求不是关键的,并且因此包括UPL值8。
在步骤5中,服务层然后评估请求,并且根据当前活动的自适应规则检查请求。在请求中找到UPL值,并且将其值与自适应规则进行比较,该自适应规则是由于服务器的操作状态而拒绝所有大于7的RPL的访问。结果,服务层将REQUEST_CANNOT_BE_PROCESS(请求无法被处理)响应代码返回给SL设备。与步骤3相似,服务层也向SL应用通知服务层可能能够在60分钟内处理请求。
在步骤6中,在接下来的60分钟期间,服务层能够恢复并且自适应其操作,以包括对处理ST3服务和RL3资源两者的支持。然而,服务层可能仍然只能处理UPL 7和更高优先级的请求。
在步骤7中,SL应用发送另一DM请求,但是这次,请求更为紧急,并且UPL设定为7。
在步骤8中,服务层处理该请求,并且根据当前活动的自适应规则检查该请求。该请求通过了自适应规则检查,但是服务器无法完全处理该请求。服务器将REQUEST_QUEUED_RESPONSE_LATER(请求被排队稍后响应)响应代码返回给SL应用,并且为该应用提供ID,以用于请求-响应匹配。当服务层能够发送响应时,它可以包括该ID以及所请求的信息。
在对请求的响应中提供了表4中列出的响应代码之一和持续时间的情况下,如果在所指示的持续时间之后发送请求,则服务层可以指示该请求可以被成功处理。SL设备应留意该指示,并且等待,直到经过了该持续时间,然后再次将相同的请求发送到服务层。如果SL设备在经过适当的时间之前发送了相同的请求,则服务层可以返回相同的响应,但是具有服务可能可用的缩短的持续时间。注意,在这样的情形下,服务层也可以降低分配给SL设备的用户优先级级别。
对于返回REQUEST_QUEUED_RESPONSE_LATER(请求被排队稍后响应)的情况,服务层可以指示请求已经被排队并且将在以后的时间被处理。返回的ID可用来识别由服务层处理请求所产生的响应。SL设备可能不需要采取进一步的动作--它只需要为了请求-响应匹配的目的而保存ID即可。附加地或替选地,ID可以是被返回以指示响应将被存储在服务层中的位置的URI。URI可以伴随有响应将可用的预期时间。
服务层可以通过不允许某些类型的操作、延迟某些类型的操作、和/或以不同的方式将特定用户优先化来处理过载状况。附加地或替选地,服务层可以采取其他或附加的动作来缓解拥塞情况。例如,服务层可以将请求发送到MANO系统,以指示需要更多的存储设备、更多的存储器、更多的CPU周期、更低延迟存储设备、和/或更低延迟存储器。服务层可以执行本文中所述的缓解动作,直到MANO系统指示可以提供所请求的资源为止。
从服务层到MANO系统的请求可以包括:需要什么类型的服务器资源,需要多长时间的服务器资源,什么原因导致请求(例如,当前资源利用率)等。来自MANO系统的响应可以指示:是否将要提供所请求的服务器资源,将要提供所请求的服务器资源的时间,将要提供所请求的服务器资源的时长,与服务相关联的成本,要存储在收费记录中以便以后可以关联收费记录的事务标识符,以及分配了多少特定服务器资源。
对MANO系统的请求还可以指示:应用、服务层或服务的实例当前未满足其延迟要求,并且因此应重新定位到不同的物理平台以满足其延迟要求。例如,本文中描述的过程可以用来检测两个端点之间的延迟是不可接受的,或者正在增加并且可能很快变得不可接受。对MANO系统的请求可以指示哪两个端点正在通信、它们的延迟要求是什么、以及可以重新定位哪些端点。响应于请求,MANO系统可以移动应用、服务或服务层的实例。例如,在一个小小区平台上托管的应用可以移动到在地理上更靠近于可以在设备上托管的其他端点(例如,应用)的另一小小区平台。移动应用、服务或服务层实例可能涉及MANO系统向服务层提供对于应用、服务或服务层实例的新访问点(PoA),并且服务层将PoA提供给其他端点(可能经由通知)。
下面描述示例实施例以演示如何将服务层操作的自适应控制应用于诸如oneM2MCSE的服务层之类的服务层(参见oneM2M TS-0001,功能架构,V3.7.0)。下面描述了应用于oneM2M标准的所提出的方法和系统的示例实施例。示出了新的oneM2M属性、资源和响应代码,以实现自适应CSE的操作的不同方面。
本文中提出的用户优先级级别可以被实现为<AE>或<CSE>资源的oneM2M属性。如果<AE>或<CSE>知道可能的值,则<AE>或<CSE>可以在注册时指定期望的优先级级别的范围。附加地或替选地,<m2mServiceSubscriptionProfile(m2m服务订阅简档)>资源可能能够提供这些优先级级别,并且CSE可以使用预先设置的值以在注册时将它们分配给AE和CSE。
用户优先级级别可以用来覆盖在做出请求时有效的某些SL自适应控制。<AE>或<CSE>资源的userPriorityLevels(用户优先级级别)属性可以在这样的自适应期间被请求者隐含地或明确地使用。例如,<AE>可具有被指定为“createContainer(创建容器)=5,multicast(多播)=10,notification(通知)=3”的userPriorityLevels(用户优先级级别)属性,其中用户优先级的范围是1到10,其中1是最高优先级。在这种情况下,当AE发送创建容器的请求时,CSE可以将5的UPL应用于该请求。这是UPL属性的隐含应用。在示例明确应用中,AE可以直接在请求中提供UPL。在这种情况下,CSE可以使用明确提供的UPL以代替<AE>资源中提供的UPL。
表5:所提出的oneM2M AE或CSE属性
Figure BDA0002487504920000221
CSE的操作度量可以被实现为新的oneM2M资源cseMetrics(cse度量)。该资源可以位于<cseBase(cse基础)>资源之下,位于与CSE相关联的<node(节点)>资源之下,或者位于CSE资源树内的另一位置。如果位于<node(节点)>资源之下,则cseMetrics(cse度量)可以是<mgmtObj>资源类型的专门化。于是,CSE的操作度量可以是cseMetrics(cse度量)资源的属性。表6示出了可用来量化CSE操作的状态的操作度量示例。这些属性可以具有只读(RO)访问权限,因为所呈现的值可能是由CSE本身生成的,而不能被外部用户修改。
表6:所提出的oneM2M cseMetrics(cse度量)资源属性
Figure BDA0002487504920000222
Figure BDA0002487504920000231
Figure BDA0002487504920000241
Figure BDA0002487504920000251
可以通过cseAdaptRule(cse自适应规则)资源实现对CSE操作的自适应控制。该资源可以与cseMetrics(cse度量)资源位于同一位置,例如,作为<node(节点)>的子资源,或作为cseMetrics(cse度量)资源的子资源。替选地,可以将属性添加到cseAdaptRule(cse自适应规则)资源以链接到cseMetrics(cse度量)资源,并且cseAdaptRule(cse自适应规则)可以位于资源树中的其他位置。可以创建一个或多个cseAdaptRule(cse自适应规则)资源,以指定用于控制CSE的不同自适应规则。表7示出了可以创建自适应规则的cseAdaptRule(cse自适应规则)资源的示例属性。表7:所提出的oneM2M cseAdaptRule(cse自适应规则)资源属性
Figure BDA0002487504920000252
Figure BDA0002487504920000261
Figure BDA0002487504920000271
Figure BDA0002487504920000281
提出将以下响应代码添加到oneM2M响应代码(参见oneM2M TS-0004,服务层核心协议,V2.5.0)。表8示出了新的响应代码,其被添加到接收器错误响应类别的5xxx系列代码。这些响应代码一起被分组到53xx子类别中,以区别于现有的响应代码。这些响应代码可用来指示CSE在缩减功能状态下运行。
表8:新的oneM2M响应代码
Figure BDA0002487504920000282
Figure BDA0002487504920000291
以下过程演示了可以如何利用本文中提出的方法和系统来实现oneM2M系统。CSE可具有CSEBase(CSE基础)名称“CSE01”,并且可以在部署期间在CSE基础之下创建cseMetrics(cse度量)资源。cseMetrics(cse度量)资源可以具有URI“/CSE01/cseMetrics”,并且可以向CSE管理员提供对cseMetrics(cse度量)的访问。cseAdaptRule(cse自适应规则)资源可以在“/CSE01”之下创建,或者替选地,cseAdaptRule(cse自适应规则)资源可以是cseMetrics(cse度量)资源的子资源。在这种情况下,可以省略表7中所示的cseMetricLink(cse度量链接)属性。
在AE注册期间,可以为AE配置用户优先级级别,并且在CSE注册期间类似地为CSE配置用户优先级级别。如果在启动过程期间为AE提供了策略,则AE可以在AE注册中包括userPriorityLevels(用户优先级级别)属性。附加地或替选地,CSE01可以从AE的<m2mServiceSubscriptionProfile(m2m服务订阅简档)>资源中获得用户优先级级别信息。
以下描述详细描述了图5的步骤:
在步骤1中,在AE注册期间,如果为AE2提供了对于userPriorityLevels(用户优先级级别)属性的策略,则AE2可以包括该策略。该策略可以提供用户优先级级别的范围,AE2可以使用所述用户优先级级别的范围来明确地进行请求。附加地或替选地,该策略可以更细粒度化,并且描述对于不同服务和资源请求的不同优先级级别。
在步骤2中,CSE01处理注册请求并且分配适当的用户优先级级别(如果可用的话)。在请求中缺少userPriorityLevels(用户优先级级别)属性的情况下,CSE01还可以从<m2mServiceSubscriptionProfile(m2m服务订阅简档)>或与AE2相关联的其他类似资源中获得策略。
在步骤3中,如果注册成功,则CSE01返回已分配给AE2的用户优先级级别的策略以及响应代码。
一旦配置了userPriorityLevels(用户优先级级别)策略,则AE2就可以在对CSE01的未来请求中使用所分配的用户优先级级别之一。如果策略提供了对于某些服务或资源的特定优先级级别,则未来请求可以使用指定用户优先级级别的隐含方法。CSE01可以检查在与AE2相关联的userPriorityLevels(用户优先级级别)属性中提供的策略,以评估对目标服务或资源的访问。AE2还可以明确地在请求中提供userPriorityLevels(用户优先级级别)。图6示出了操作中这两种情况的示例。
以下描述详细描述了图6的步骤:
在步骤1中,CSE01处于自适应控制之下,并且当前已禁用UPL大于7的处理请求。AE2先前已向CSE01注册,并且被提供有userPriorityLevels(用户优先级级别)策略,在该策略中,创建容器资源被分配7到10之间的UPL范围,默认值为9。默认UPL值被应用于未明确指定UPL的AE2的创建容器请求。然而,AE2可以通过在创建请求中包含7到10之间的UPL的userPriorityLevels(用户优先级级别)属性来覆盖该默认值。
在步骤2中,AE2发送没有提供UPL的创建容器请求。
在步骤3中,CSE01处理该请求,并且根据自适应的UPL来评估与AE2相关联的UPL。该比较示出:该请求(创建容器)的AE2的UPL为9,其大于自适应的大于7的UPL。结果,该请求被拒绝。
在步骤4中,CSE01在响应中返回ACCESS_DENIED_PRIORITY_LEVEL(访问被拒绝的优先级级别)代码。该响应还包括当前被CSE01禁用的优先级级别,并且可以包括在评估对AE2的请求时使用的默认UPL。
在步骤5中,AE2发送另一创建容器请求,但是这次的UPL为7。
在步骤6中,CSE01处理该请求,并且根据自适应的UPL检查所提供的UPL。验证成功,并且CSE01允许请求被处理以完成。
在步骤7中,CSE01返回所创建的响应。
注意,AE2可以被限制为在步骤5中指定如下UPL值,该UPL值在AE注册期间提供给其userPriorityLevels(用户优先级级别)属性的值的范围之内。指定在该范围之外的值将导致返回CONTENTS_UNACCEPTABLE(内容不可接受)响应代码。CSE还可以在响应中包括可接受的范围。在这种情况下,所提供的UPL值在提供给AE2的范围之外,并且因此请求的内容可能不可接受。
一旦CSE01处于自适应控制之下,它就可以提供何时可以继续正常操作的指示以及响应代码。图7示出了示例呼叫流程,其中CSE01向AE2通知可以继续正常CSE操作的预期时间。在这种情况下,CSE01处于自适应控制之下,其中组特征被禁用。注意,以下呼叫流程没有示出CSE01在评估请求时执行的所有检查,诸如消息验证和访问控制检查。
以下描述详细描述了图7的步骤。
在步骤1中,CSE01处于自适应控制之下,并且当前已禁用处理组请求。
在步骤2中,AE2发送创建组请求。
在步骤3中,CSE01处理请求,并且执行自适应控制检查,以确定是否允许该请求。
在步骤4中,CSE01返回具有REQUEST_CANNOT_BE_PROCESS(请求无法被处理)代码的响应以及将启用组处理特征的预期时间。在这种情况下,直到CSE01可以再次处理组请求之前剩余57分钟。
在步骤5中,在某个时间后,AE2发送另一创建组请求。
在步骤6中,CSE01处理该请求,并且执行自适应控制检查,以确定是否允许该请求。
在步骤7中,CSE01返回具有REQUEST_CANNOT_BE_PROCESS(请求无法被处理)代码的响应以及将启用组处理特征的预期时间。在这种情况下,直到CSE01可以再次处理组请求之前仅剩余2分钟。
在步骤8中,自适应控制时段结束,并且CSE01继续正常操作。
在步骤9中,AE2发送创建组请求。
在步骤10中,由于自适应控制已过期,因此CSE01允许请求被处理。
在步骤11中,如果请求被成功处理,则CSE01返回所创建的响应。
可以通过激活一个或多个自适应规则来触发CSE自适应。这些规则可以被实现为CSE管理员创建的cseAdaptRule(cse自适应规则)资源,以使CSE的操作自适应于变化的系统状况。这些自适应规则可以包含监视组件和命令组件,其自适应CSE的操作。监视组件可以取决于为CSE提供的操作度量。表9示出了可能在CSE中可用的操作度量的两个示例。hwMetrics(硬件度量)资源提供了以硬件为中心的度量(诸如CPU利用率),并且可以被表示为可用服务器资源的百分比。cseMetrics(cse度量)资源提供了描述CSE的负载的特定于CSE的度量。可以以[最小,当前,最大]的形式将每个度量表示为三元组。
表9:CSE的操作度量的示例
Figure BDA0002487504920000331
Figure BDA0002487504920000341
使用表9中示出的度量,CSE管理员可以创建自适应规则,所述自适应规则根据需要监视并且自适应CSE的操作。表10示出了示例cseAdaptRule(cse自适应规则)资源,其中CSE被编程以监视存储器使用率。将名称opRule1(操作规则1)给予给该资源,并且CSE将规则ID“rid01”分配给该资源。规则监视由hwMetrics(硬件度量)资源提供的memUtilization(存储器利用率)属性,并且指定如果当前存储器利用率超出最大存储器利用率达10%,则CSE应当挂起组扇出和语义查询服务两者。该监视仅在星期一至星期五每天7:00am至10:00pm的时间窗口内执行。此外,用户优先级级别大于8的所有请求都被拒绝访问,直到规则过期(其被配置为60分钟)。
表10:示例自适应规则1
Figure BDA0002487504920000342
Figure BDA0002487504920000351
表11示出了第二自适应规则示例,其中CSE正在监视:如果CPU和存储器利用率都高于90%,则CSE将自适应操作以挂起服务,诸如组扇出、远程操作、事务管理等。此外,对于创建或执行操作,为“资源”属性列出的oneM2M资源被拒绝访问;并且UPL值高于5的所有请求也被拒绝访问。该自适应是暂时的,并且具有5分钟的到期时间。所有挂起的服务、资源和UPL将在5分钟后继续操作。
表11:示例自适应规则2
Figure BDA0002487504920000352
Figure BDA0002487504920000361
自适应规则可以使用如表12中所示的多个度量资源。该规则使用由hwMetrics(硬件度量)和cseMetrics(cse度量)资源两者提供的度量。在这种情况下,所有属性名称必须彼此唯一。该规则监视4个度量,其中3个度量与数据库相关联,第四个度量监视请求处理延迟是否花费太长时间来处理传入请求。每个受监视的度量必须有效以便激活规则。最后,该规则具有对于持续时间属性的关系表达式,这表示opRule3(操作规则3)将在请求处理延迟小于50%时继续操作。
表12:示例自适应规则3
Figure BDA0002487504920000362
Figure BDA0002487504920000371
先前描述的所有规则演示了CSE内的服务或操作的暂时挂起。可以创建规则,使得服务或操作被明确地禁用,并且可能需要对应的规则来重新启用服务或操作。表13和表14示出了伴随规则,其中,如果CSE内的错误率超过50%,则禁用所有服务、操作和用户优先级级别。这种状况表示可能存在某些内部CSE问题,这些问题导致错误响应以比正常高的比率返回给用户请求。opRule4(操作规则4)是禁用CSE操作的规则,而opRule5(操作规则5)用来重新启用CSE操作。该机制可用来向CSE管理员给予对CSE操作的完全控制,以解决不存在解决的时间表(timeframe)的潜在内部服务器问题。opRule4(操作规则4)还可以用来在关闭实际硬件服务器电源之前温和地终止CSE操作。
表13:示例自适应规则4
Figure BDA0002487504920000372
Figure BDA0002487504920000381
表14:示例自适应规则5
Figure BDA0002487504920000382
在oneM2M架构中,上面针对与MANO系统的SL交互而描述的过程可以被映射到oneM2M Mcn参考点。例如,过程可以在诸如MPLS、OpenFlow、NETCONF、SNMP、CLI、PCEP、i2RS等协议上运行。
CSE的自适应规则可以容易地显示在用户界面中,以供CSE管理员监视当前是否有任何规则是活动的。图8示出了示例用户界面,该示例用户界面列出了在CSE上创建的所有自适应规则。用户界面可以具有一列单选按钮(radial button),以指示是否激活了特定规则。CSE管理员可以点击与规则相关联的规则ID,以获得有关该规则的更多信息。
执行图2-图7中所示的步骤的任何实体(诸如服务层、服务层设备、服务层应用、应用实体等)可以是可以以软件形式(即,计算机可执行指令)实现的逻辑实体,该软件存储在诸如图9C或图9D中所示的被配置用于无线和/或网络通信的装置或计算机系统的存储器中并且在处理器上执行。即,可以以存储在装置(诸如图9C或图9D中所示的装置或计算机系统)的存储器中的软件形式(即,计算机可执行指令)来实现图2-图7中所示的方法,所述计算机可执行指令在由装置的处理器执行时,执行图2-图7中所示的步骤。还应理解,图2-图7中所示的任何发送和接收步骤都可以在装置的处理器及其执行的计算机可执行指令(例如,软件)的控制之下,由装置/实体的通信电路来执行。
图9A是可以实现一个或多个所公开的实施例的示例机器对机器(M2M)、物联网(IoT)或物联万维网(WoT)通信系统10的图。通常,M2M技术为IoT/WoT提供了构建块,并且任何M2M设备、M2M网关、M2M服务器或M2M服务平台都可以是IoT/WoT的组件或装置、以及IoT/WoT服务层等。在图1至图8中的任一个中示出的任何实体可以包括通信系统的网络装置,诸如图9A至图9D中所示的那些。
服务层可以是网络服务架构内的功能层。服务层通常位于应用协议层(例如HTTP、CoAP或MQTT)之上,并且向客户端应用提供增值服务。服务层还提供与较低资源层(诸如,例如控制层和传输/访问层)处的核心网络的接口。服务层支持(服务)能力或功能的多个类别,包括服务定义、服务运行时启用、策略管理、访问控制和服务群集。近来,一些行业标准机构(例如oneM2M)已经在开发M2M服务层,以解决与M2M类型的设备和应用到诸如互联网/网络(Web)、蜂窝、企业和家庭网络之类的部署中的集成相关联的挑战。M2M服务层可以向应用和/或各种设备提供对由服务层支持的可以被称为CSE或SCL的上述能力或功能的组群(collection)或集合的访问。一些示例包括但不限于可以由各种应用共同使用的安全性、收费、数据管理、设备管理、发现、供应和连接性管理。经由API使这些能力或功能可用于这样的各种应用,这些API使用由M2M服务层定义的消息格式、资源结构和资源表示形式。CSE或SCL是可以由硬件和/或软件实现的功能实体,并且提供暴露给各种应用和/或设备的(服务)能力或功能(即,这样的功能实体之间的功能接口),以使它们使用这样的能力或功能。
如图9A中所示,M2M/IoT/WoT通信系统10包括通信网络12。通信网络12可以是固定网络(例如,以太网、光纤、ISDN、PLC等)或无线网络(例如,WLAN、蜂窝等)或各异构网络的网络。例如,通信网络12可以包括向多个用户提供诸如语音、数据、视频、消息传递、广播等内容的多个接入网络。例如,通信网络12可以采用一个或多个信道接入方法,诸如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)等。此外,通信网络12可以包括其他网络,诸如,例如核心网络、互联网、传感器网络、工业控制网络、个人局域网、融合个人网络、卫星网络、家庭网络或企业网络。
如图9A中所示,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设备18和网关14可以经由各种网络进行通信,这些网络包括例如蜂窝、WLAN、WPAN(例如,Zigbee、6LoWPAN、蓝牙)、直接无线电链路和有线。示例M2M设备包括但不限于平板计算机、智能电话、医疗设备、温度和天气监控器、联网的汽车、智能仪表、游戏机、个人数字助理、健康和健身监控器、灯、恒温器、电器、车库门以及其他基于致动器的设备、安全设备和智能插座。
参考图9B,所示出的现场域中的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服务层22类似,在基础设施域中存在M2M服务层22'。M2M服务层22'为基础设施域中的M2M应用20'和底层通信网络12提供服务。M2M服务层22'还为现场域中的M2M网关14和M2M设备18提供服务。将会理解,M2M服务层22'可以与任何数量的M2M应用、M2M网关和M2M设备进行通信。M2M服务层22'可以通过不同的服务提供商与服务层交互。M2M服务层22'可以由网络的一个或多个网络装置来实现,所述一个或多个网络装置可以包括服务器、计算机、设备、虚拟机(例如,云计算/储存场等)等。
还参考图9B,M2M服务层22和22'提供了各种应用和垂直行业都可以利用的服务交付能力的核心集合。这些服务能力使得M2M应用20和20'能够与设备进行交互,并且执行诸如数据收集、数据分析、设备管理、安全性、计费、服务/设备发现等功能。实质上,这些服务能力使应用免于实现这些功能的负担,从而简化了应用开发并且减少了成本和上市时间。服务层22和22'还使得M2M应用20和20'能够通过诸如网络12之类的各种网络与服务层22和22'提供的服务进行通信。
M2M应用20和20'可以包括各种行业中的应用,例如但不限于交通、健康和保健、联网的家庭、能源管理、资产跟踪以及安全和监控。如上所述,跨系统的设备、网关、服务器和其他网络装置运行的M2M服务层支持诸如例如数据收集、设备管理、安全性、计费、位置跟踪/地理防护、设备/服务发现和传统系统集成之类的功能,并且将这些功能作为服务提供给M2M应用20和20'。
通常,服务层(诸如图9B中所示的服务层22和22')定义了软件中间件层,该软件中间件层通过一组应用编程接口(API)和底层联网接口来支持增值服务能力。ETSI M2M和oneM2M架构两者都定义了服务层。ETSI M2M的服务层被称为服务能力层(SCL)。可以在ETSIM2M架构的各种不同节点中实现SCL。例如,服务层的实例可以被实现在M2M设备内(其被称为设备SCL(DSCL))、被实现在网关内(其被称为网关SCL(GSCL))和/或被实现在网络节点内(其被称为网络SCL(NSCL))。oneM2M服务层支持一组公共服务功能(CSF)(即服务能力)。一个或多个特定类型的CSF的集合的实例被称为公共服务实体(CSE),CSE可以托管在不同类型的网络节点(例如,基础设施节点、中间节点、专用节点)上。第三代合作伙伴计划(3GPP)还定义了用于机器类型通信(MTC)的架构。在该架构中,服务层及其提供的服务能力被实现为服务能力服务器(SCS)的一部分。无论是体现在ETSI M2M架构的DSCL、GSCL或NSCL中,体现在3GPP MTC架构的服务能力服务器(SCS)中,体现在oneM2M架构的CSF或CSE中,还是体现在网络的其他某个节点中,服务层的实例可以被实现为在网络中的一个或多个独立节点(包括服务器、计算机和其他计算设备或节点)上执行的逻辑实体(例如,软件、计算机可执行指令等),或者被实现为一个或多个现有节点的一部分。作为示例,服务层或其组件的实例可以以在网络装置(例如,服务器、计算机、网关、设备等)上运行的软件的形式来实现,该网络装置具有在下文中描述的图9C或图9D中所示的通用架构。
此外,本文中描述的方法和功能可以被实现为M2M网络的一部分,该网络装置使用面向服务的架构(SOA)和/或面向资源的架构(ROA)来访问服务。
图9C是网络的装置(诸如图1至图8中示出的实体之一)的示例硬件/软件架构的框图,该装置可以作为诸如图9A和9B中所示的M2M网络中的M2M服务器、网关、设备或其他网络装置进行操作。如图9D中所示,网络装置30可包括处理器32、不可移除存储器44、可移除存储器46、扬声器/麦克风38、小键盘40、显示器、触摸板和/或指示器42、电源48、全球定位系统(GPS)芯片组50和其他外围设备52。网络装置30还可以包括通信电路,例如收发器34和发射/接收元件36。将会理解,网络装置30可以包括前述元件的任何子组合,同时保持与实施例一致。该网络装置可以是实现用于本文中描述的服务层操作的自适应控制的方法(诸如关于图2-图7示出和描述的方法操作)的装置。
处理器32可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核相关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、任何其他类型的集成电路(IC)、状态机等。通常,处理器32可以执行存储在网络装置的存储器(例如,存储器44和/或存储器46)中的计算机可执行指令,以便执行网络装置的各种所需功能。例如,处理器32可执行信号编码、数据处理、功率控制、输入/输出处理、和/或使得网络装置30能够在无线或有线环境中操作的任何其他功能。处理器32可以运行应用层程序(例如,浏览器)和/或无线电接入层(RAN)程序和/或其他通信程序。处理器32还可以诸如例如在接入层和/或应用层执行安全操作(诸如认证、安全密钥协议和/或加密操作)。
如图9C中所示,处理器32耦合到其通信电路(例如,收发器34和发送/接收元件36)。通过执行计算机可执行指令,处理器32可以控制通信电路,以便使网络装置30经由其所连接的网络与其他网络装置进行通信。特别地,处理器32可以控制通信电路以便执行本文(例如,图2-图7中)和权利要求中描述的发送和接收步骤。尽管图9C将处理器32和收发器34描绘为分离的组件,但是将会理解,处理器32和收发器34可以一起集成在电子封装或芯片中。
发送/接收元件36可以被配置为向包括M2M服务器、网关、设备等的其他网络装置发送信号或从其接收信号。例如,在实施例中,发送/接收元件36可以是被配置为发送和/或接收RF信号的天线。发送/接收元件36可以支持各种网络和空中接口,诸如WLAN、WPAN、蜂窝等。在实施例中,发送/接收元件36可以是被配置为发送和/或接收例如IR、UV或可见光信号的发射器/检测器。在又一实施例中,发送/接收元件36可以被配置为发送和接收RF和光信号两者。将会理解,发送/接收元件36可以被配置为发送和/或接收无线或有线信号的任何组合。
另外,尽管在图9C中将发送/接收元件36描绘为单个元件,但是网络装置30可以包括任何数量的发送/接收元件36。更具体地,网络装置30可以采用MIMO技术。因此,在实施例中,网络装置30可以包括两个或多个用于发送和接收无线信号的发送/接收元件36(例如,多个天线)。
收发器34可以被配置为调制将要由发送/接收元件36发送的信号,并且对由发送/接收元件36接收的信号进行解调。如上所述,网络装置30可以具有多模式能力。因此,例如,收发器34可以包括用于使得网络装置30能够经由多个RAT(诸如UTRA和IEEE802.11)进行通信的多个收发器。
处理器32可以从任何类型的适当存储器(例如,不可移除存储器44和/或可移除存储器46)访问信息并且将数据存储在其中。例如,如上所述,处理器32可以将会话上下文存储在其存储器中。不可移除存储器44可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或任何其他类型的存储器存储设备。可移除存储器46可以包括订户身份模块(SIM)卡、存储棒、安全数字(SD)存储卡等。在其他实施例中,处理器32可以从物理上不在网络装置30上(例如在服务器或家用计算机上)的存储器访问信息并且将数据存储在其中。处理器32可以被配置为控制显示器或指示器42上的照明图案、图像或颜色以反映装置的状态,或者配置装置、特别是与网络装置通信的底层网络、应用或其他服务。在一个实施例中,显示器/指示器42可以呈现图9D中所示的并且在本文中描述的图形用户界面。
处理器32可以从电源48接收电力,并且可以被配置为向网络装置30中的其他组件分配和/或控制电力。电源48可以是用于向网络装置30供电的任何合适的设备。例如,电源48可以包括一个或多个干电池(例如,镍镉(NiCd)、镍锌(NiZn)、镍金属氢化物(NiMH)、锂离子(Li离子)等)、太阳能电池、燃料电池等。
处理器32也可以耦合到GPS芯片组50,GPS芯片组50被配置为提供关于网络装置30的当前位置的位置信息(例如,经度和纬度)。将会理解,网络装置30可以通过任何合适的位置确定方法来获取位置信息,同时保持与实施例一致。
处理器32可以进一步耦合到其他外围设备52,其他外围设备52可以包括提供附加特征、功能和/或有线或无线连接性的一个或多个软件和/或硬件模块。例如,外围设备52可以包括各种传感器,例如加速度计、生物特征(例如指纹)传感器、电子罗盘、卫星收发器、传感器、数码相机(用于照片或视频)、通用串行总线(USB)端口或其他互连接口、振动设备、电视收发器、免提耳机、
Figure BDA0002487504920000461
模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏播放器模块、互联网浏览器等。
网络装置30可以体现在其他装置或设备中,例如传感器、消费类电子产品、可穿戴设备(例如智能手表或智能服装)、医疗或电子保健设备、机器人、工业设备、无人机、车辆(例如汽车、卡车、火车或飞机)。网络装置30可以经由一个或多个互连接口(诸如可以包括外围设备52之一的互连接口)连接到这样的装置或设备中的其他组件、模块或系统。
图9C是示例计算系统90的框图,该示例计算系统90还可以用来实现网络的一个或多个网络装置(诸如在图1至图8中示出的并且在本文中描述的实体),其可以作为诸如图9A和9B中所示的M2M网络中的M2M服务器、网关、设备或其他网络装置进行操作。
计算系统90可以包括计算机或服务器,并且可以主要由计算机可读指令来控制,该计算机可读指令可以采用软件的形式,其中在任何地方、或通过任何方式来存储或访问这样的软件。这样的计算机可读指令可以在诸如中央处理单元(CPU)91之类的处理器内执行,以使计算系统90进行工作。在许多已知的工作站、服务器和个人计算机中,中央处理单元91由被称为微处理器的单芯片CPU来实现。在其他机器中,中央处理单元91可以包括多个处理器。协处理器81是与主CPU 91不同的可选处理器,协处理器81执行附加功能或辅助CPU91。CPU 91和/或协处理器81可以接收、生成和处理与所公开的用于E2E M2M服务层会话的系统和方法有关的数据,例如接收会话凭证或基于会话凭证进行认证。
在操作中,CPU 91获取、解码并且执行指令,以及经由计算机的主数据传输路径(系统总线80)将信息传输到其他资源并且从其他资源传输信息。这样的系统总线连接计算系统90中的组件并且定义用于数据交换的介质。系统总线80通常包括用于发送数据的数据线、用于发送地址的地址线以及用于发送中断和用于操作系统总线的控制线。这样的系统总线80的示例是PCI(外围组件互连)总线。
耦合到系统总线80的存储器包括随机存取存储器(RAM)82和只读存储器(ROM)93。这样的存储器包括允许信息被存储和检索的电路。ROM 93通常包含无法容易地被修改的所存储的数据。RAM 82中存储的数据可以由CPU 91或其他硬件设备来读取或改变。可以由存储器控制器92来控制对RAM 82和/或ROM 93的访问。存储器控制器92可以提供地址转换功能,该地址转换功能在指令被执行时将虚拟地址转换为物理地址。存储器控制器92还可以提供存储器保护功能,存储器保护功能将系统内的进程隔离并且将系统进程与用户进程隔离。因此,以第一模式运行的程序只可以访问由其自己的进程虚拟地址空间映射的存储器;除非已经设置了进程之间的存储器共享,否则它无法访问另一进程的虚拟地址空间内的存储器。
另外,计算系统90可以包含外围设备控制器83,外围设备控制器83负责将指令从CPU 91传递到外围设备,诸如打印机94、键盘84、鼠标95和盘驱动器85。
由显示控制器96控制的显示器86用来显示由计算系统90生成的视觉输出。这样的视觉输出可以包括文本、图形、动画图形和视频。显示器86可以利用基于CRT的视频显示器、基于LCD的平板显示器、基于气体等离子体的平板显示器或触摸面板来实现。显示控制器96包括生成视频信号所需的电子组件,该视频信号被发送到显示器86。显示器86与由CPU 91执行的计算机可执行指令结合可以生成和操作图9D及其随附的描述中示出和描述的图形用户界面。
此外,计算系统90可以包含通信电路(诸如例如网络适配器97),其可以用来将计算系统90连接到外部通信网络(例如图9A-图9D的网络12),以使得计算系统90能够与网络的其他装置进行通信。通信电路单独或与CPU 91结合可用来执行本文(例如,图2-图7中)和权利要求中所述的发送和接收步骤。
应当理解,本文中描述的任何或所有系统、方法和处理可以以存储在计算机可读存储介质上的计算机可执行指令(即程序代码)的形式来体现,这些指令在由机器(例如M2M网络的装置,包括例如M2M服务器、网关、设备等)执行时,执行和/或实现本文中所述的系统、方法和处理。具体地,可以以这样的计算机可执行指令的形式实现上述的任何步骤、操作或功能。计算机可读存储介质包括以用于存储信息的任何非瞬态(即,有形或物理)方法或技术实现的易失性和非易失性、可移除和不可移除介质,但是这样的计算机可读存储介质不包括信号。计算机可读存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储设备、磁盒、磁带、磁盘存储设备或其他磁性存储设备、或可用来存储期望的信息并且可由计算机访问的任何其他有形或物理介质。
以下是可能在以上描述中出现的与服务层技术有关的首字母缩写词的列表。除非另有说明,否则本文中使用的首字母缩写词是指下面列出的相应术语:
ACP 访问控制策略
AE 应用实体
CSE 公共服务实体
CSF 公共服务功能
DM 设备管理
GUI 图形用户界面
IoT 物联网
i2RS 路由系统接口
MANO 管理和编排
MPLS 多协议标签交换
M2M 机器对机器
NETCONF 网络配置协议
PCEP 路径计算元素协议
PoA 访问点
RL 资源级别
SL 服务层
SNMP 简单网络管理协议
以下是可能在以上描述中出现的与服务层技术有关的术语和定义的列表。除非另有说明,否则本文中使用的术语和定义是指下面列出的相应术语:
Figure BDA0002487504920000491
Figure BDA0002487504920000501
该书面描述使用示例来公开本发明(包括最佳模式),并且还使得本领域技术人员能够实施本发明,包括制造和使用任何设备或系统以及执行任何合并的方法。本发明的专利范围由权利要求书限定,并且可以包括本领域技术人员想到的其他示例。如果这样的其他示例具有与权利要求的字面语言没有不同的要素,或者如果它们包括与权利要求的字面语言没有实质性差异的等效要素,则它们旨在处于权利要求的范围内。

Claims (20)

1.一种在通信网络的服务层实体中实现的方法,所述方法包括:
在所述服务层实体处激活一个或多个自适应规则,所述一个或多个自适应规则用于基于所述服务层实体的一个或多个操作度量来修改所述服务层实体的一个或多个特性,其中,所述服务层实体的操作度量包括一个或多个服务层度量;
从与所述服务层实体通信的另一实体接收在所述服务层实体处执行操作的请求;
在所述服务层实体处并且基于所述一个或多个自适应规则,确定该操作不能由所述服务层实体执行;以及
由所述服务层实体发送对将要由所述服务层实体利用的附加资源的请求。
2.根据权利要求1所述的方法,其中,所述服务层度量包括以下各项中的一个或多个:资源发现延迟、语义查询延迟、数据库读取延迟、数据库写入延迟、请求处理延迟、吞吐量、错误率、待决请求数量、订阅资源数量和通知率。
3.根据权利要求1所述的方法,其中,对所述附加资源的请求包括以下各项中的至少一个:所需要的附加资源的类型的指示、需要所述附加资源的时长、以及请求所述附加资源的原因。
4.根据权利要求3所述的方法,其中,所述附加资源的类型包括以下各项中的一个或多个:附加存储设备、附加存储器、附加处理周期、更低延迟存储设备和更低延迟存储器。
5.根据权利要求1所述的方法,还包括接收指示以下各项中的一个或多个的响应:是否将要提供所述附加资源,将要提供所述附加资源的时间,将要提供所述附加资源的时长,以及与接收所述附加资源相关联的成本。
6.根据权利要求1所述的方法,还包括:接收指示所述服务层实体应当移动到不同物理平台的响应。
7.根据权利要求1所述的方法,其中,对所述附加资源的请求被发送到管理和编排系统。
8.一种包括处理器和存储器的装置,所述存储器存储计算机可执行指令,所述计算机可执行指令在被所述处理器执行时实现通信网络的服务层实体并且使所述服务层实体执行包括以下的操作:
在所述服务层实体处激活一个或多个自适应规则,所述一个或多个自适应规则用于基于所述服务层实体的一个或多个操作度量来修改所述服务层实体的一个或多个特性,其中,所述服务层实体的操作度量包括一个或多个服务层度量;
从与所述服务层实体通信的另一实体接收在所述服务层实体处执行操作的请求;
在所述服务层实体处并且基于所述一个或多个自适应规则,确定该操作不能由所述服务层实体执行;以及
由所述服务层实体发送对将要由所述服务层实体利用的附加资源的请求。
9.根据权利要求8所述的装置,其中,所述服务层度量包括以下各项中的一个或多个:资源发现延迟、语义查询延迟、数据库读取延迟、数据库写入延迟、请求处理延迟、吞吐量、错误率、待决请求数量、订阅资源数量和通知率。
10.根据权利要求8所述的装置,其中,对所述附加资源的请求包括以下各项中的至少一个:所需要的附加资源的类型的指示、需要所述附加资源的时长、以及请求所述附加资源的原因。
11.根据权利要求10所述的装置,其中,所述附加资源的类型包括以下各项中的一个或多个:附加存储设备、附加存储器、附加处理周期、更低延迟存储设备和更低延迟存储器。
12.根据权利要求8所述的装置,其中,所述指令在被执行时还使所述服务层实体执行包括接收指示以下各项中的一个或多个的响应的操作:是否将要提供所述附加资源,将要提供所述附加资源的时间,将要提供所述附加资源的时长,以及与接收所述附加资源相关联的成本。
13.根据权利要求8所述的装置,其中,所述指令在被执行时还使所述服务层实体执行包括以下的操作:接收指示所述服务层实体应当移动到不同物理平台的响应。
14.根据权利要求8所述的装置,其中,对所述附加资源的请求被发送到管理和编排系统。
15.一种存储计算机可执行指令的计算机可读存储介质,所述计算机可执行指令在被处理器执行时实现通信网络的服务层实体并且使所述服务层实体执行包括以下的操作:
在所述服务层实体处激活一个或多个自适应规则,所述一个或多个自适应规则用于基于所述服务层实体的一个或多个操作度量来修改所述服务层实体的一个或多个特性,其中,所述服务层实体的操作度量包括一个或多个服务层度量;
从与所述服务层实体通信的另一实体接收在所述服务层实体处执行操作的请求;
在所述服务层实体处并且基于所述一个或多个自适应规则,确定该操作不能由所述服务层实体执行;以及
由所述服务层实体发送对将要由所述服务层实体利用的附加资源的请求。
16.根据权利要求15所述的计算机可读存储介质,其中,所述服务层度量包括以下各项中的一个或多个:资源发现延迟、语义查询延迟、数据库读取延迟、数据库写入延迟、请求处理延迟、吞吐量、错误率、待决请求数量、订阅资源数量和通知率。
17.根据权利要求15所述的计算机可读存储介质,其中,对所述附加资源的请求包括以下各项中的至少一个:所需要的附加资源的类型的指示、需要所述附加资源的时长、以及请求所述附加资源的原因。
18.根据权利要求17所述的计算机可读存储介质,其中,所述附加资源的类型包括以下各项中的一个或多个:附加存储设备、附加存储器、附加处理周期、更低延迟存储设备和更低延迟存储器。
19.根据权利要求15所述的计算机可读存储介质,其中,所述指令在被执行时还使所述服务层实体执行包括接收指示以下各项中的一个或多个的响应的操作:是否将要提供所述附加资源、将要提供所述附加资源的时间、将要提供所述附加资源的时长、以及与接收所述附加资源相关联的成本。
20.根据权利要求15所述的计算机可读存储介质,其中,所述指令在被执行时还使所述服务层实体执行包括以下的操作:接收指示所述服务层实体应当移动到不同物理平台的响应。
CN201980005684.5A 2018-01-09 2019-01-09 服务层操作的自适应控制机制 Active CN111357259B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201862615043P 2018-01-09 2018-01-09
US62/615,043 2018-01-09
PCT/US2019/012845 WO2019139947A1 (en) 2018-01-09 2019-01-09 Mechanisms for the adaptive control of service layer operations

Publications (2)

Publication Number Publication Date
CN111357259A true CN111357259A (zh) 2020-06-30
CN111357259B CN111357259B (zh) 2024-06-28

Family

ID=65352100

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980005684.5A Active CN111357259B (zh) 2018-01-09 2019-01-09 服务层操作的自适应控制机制

Country Status (4)

Country Link
US (1) US11070426B2 (zh)
EP (1) EP3738294B1 (zh)
CN (1) CN111357259B (zh)
WO (1) WO2019139947A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114301817A (zh) * 2021-12-17 2022-04-08 中电信数智科技有限公司 基于Netconf协议的设备监测阈值设置方法和系统

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI760160B (zh) * 2021-03-26 2022-04-01 凌群電腦股份有限公司 降低伺服端運作壓力並提升回應時間之流量控制方法及其系統
US11677810B2 (en) * 2021-07-23 2023-06-13 International Business Machines Corporation Configuration tool for deploying an application on a server

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140259012A1 (en) * 2013-03-06 2014-09-11 Telefonaktiebolaget L M Ericsson (Publ) Virtual machine mobility with evolved packet core
US20160085594A1 (en) * 2013-05-08 2016-03-24 Convida Wireless, Llc Method and apparatus for the virtualization of resources using a virtualization broker and context information
US20170126578A1 (en) * 2015-11-03 2017-05-04 International Business Machines Corporation On-demand iot bandwidth allocation in response to a changing sensor population

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8688780B2 (en) * 2005-09-30 2014-04-01 Rockwell Automation Technologies, Inc. Peer-to-peer exchange of data resources in a control system
US20090100179A1 (en) * 2007-10-12 2009-04-16 Electronics And Telecommunications Research Institute Method of controlling resources using out-of-band signaling
US20140237070A1 (en) * 2013-02-19 2014-08-21 Lg Cns Co., Ltd. Network-attached storage management in a cloud environment
US10405159B2 (en) * 2015-01-12 2019-09-03 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for monitoring and managing resource usage in a communication network
US10454836B2 (en) * 2016-11-01 2019-10-22 At&T Intellectual Property I, L.P. Method and apparatus for dynamically adapting a software defined network

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140259012A1 (en) * 2013-03-06 2014-09-11 Telefonaktiebolaget L M Ericsson (Publ) Virtual machine mobility with evolved packet core
US20160085594A1 (en) * 2013-05-08 2016-03-24 Convida Wireless, Llc Method and apparatus for the virtualization of resources using a virtualization broker and context information
US20170126578A1 (en) * 2015-11-03 2017-05-04 International Business Machines Corporation On-demand iot bandwidth allocation in response to a changing sensor population

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114301817A (zh) * 2021-12-17 2022-04-08 中电信数智科技有限公司 基于Netconf协议的设备监测阈值设置方法和系统

Also Published As

Publication number Publication date
CN111357259B (zh) 2024-06-28
US11070426B2 (en) 2021-07-20
EP3738294A1 (en) 2020-11-18
EP3738294B1 (en) 2024-05-01
US20200374193A1 (en) 2020-11-26
WO2019139947A1 (en) 2019-07-18

Similar Documents

Publication Publication Date Title
US11711682B2 (en) Cross-resource subscription for M2M service layer
US11503446B2 (en) Service capability exposure at the user equipment
US11582306B2 (en) Subscription and notification service
CN109155789B (zh) 用于服务层中的请求处理的方法、装置和存储介质
US11057274B1 (en) Systems and methods for validation of virtualized network functions
KR20190134741A (ko) 정책 제어 방법, 네트워크 요소, 및 시스템
CN107615791B (zh) 用于添加m2m服务的装置和方法
CN111357259B (zh) 服务层操作的自适应控制机制
WO2018170391A1 (en) Distributed transaction management in a network service layer
JP7246379B2 (ja) 通信ネットワークにおけるサービス層メッセージテンプレート
KR20200009153A (ko) 서비스 계층 등록
EP3332513B1 (en) Service element host selection
EP3241363B1 (en) Resource link management at service layer
WO2019067817A1 (en) ENHANCED RESOURCE SHARING USING A RESERVATION
CN106416327B (zh) 一种根据策略提供服务的方法和系统
EP3912329A1 (en) Automated service layer message flow management in a communications network

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant